福大軟工 · 第八次做業（課堂實戰）- 項目UML設計（團隊）

團隊信息

隊名：爸爸餓了

隊員姓名與學號

學號	姓名	博客連接
124	王彬（組長）	點擊這裏
206	趙暢	點擊這裏
215	胡展瑞	點擊這裏
320	李恆達	點擊這裏
131	佘嶽昕	點擊這裏
431	王源	點擊這裏
206	陳文垚	點擊這裏
209	陳志煒	點擊這裏
225	林煌偉	點擊這裏

本次做業連接

點擊這裏

團隊分工

alpha 分而治之：（做者：志豪）

alpha版本須要作的事情

模塊序號	模塊名	模塊具體內容
1	學生用戶模塊	1.學生用戶登入 2.選擇口味界面 3.推薦展現界面 4.推薦評價頁面 5.查看美食地圖 6.推薦店鋪位置指引
2	商家用戶模塊	1.商鋪用戶登入 2.查看食客評論與回覆界面 3.提交菜品和菜單數據界面 4.會員充值界面
3	後臺管理模塊	1.食堂店鋪與店鋪菜品增刪改查操做 2.推薦算法 3.對會員和充值系統的管理

成員具體分工及TODO list

負責人	分工明細	TODO List
王彬	負責項目任務分配、進度跟蹤推動、原型製做	1.完成原型的開發 2.文檔撰寫與彙總
趙暢	數據庫搭建、數據庫接口編寫	1.配合後端小組完成程序後端的開發 2.完成菜品量化，搭建數據庫
胡展瑞	負責項目各個部分的測試編寫	1.編寫測試用例幫助先後端把控質量
李恆達	前端模塊（普通用戶端）實現	1.完成前端口味選擇功能 2.完成推薦結果評價功能
陳志煒	前端模塊（普通用戶端）實現、推薦算法設計	1.完成美食地圖功能 2.完成店鋪位置指引功能
陳文垚	前端模塊（普通用戶端）實現	1.學生端登入入口 2.完成推薦結果展現功能
林煌偉	前端模塊（商鋪用戶端）實現	1.商鋪用戶登入功能 2.商鋪用戶查看食客評論與回覆功能 3.商鋪提交菜單和菜品數據功能
佘嶽昕	後端模塊實現	1.先後端交互接口（學生用戶端）設計與實現 2.先後端交互接口（商鋪用戶端）設計與實現
王源	後端模塊實現	1.菜品推薦算法設計與實現 2.後端與數據庫接口定義與實現

燃盡圖

UML

【part1】用例圖

描述的部分？

• 描述的是系統的項目需求部分。

面臨的問題？

• 用戶需求的變化是多樣性的，將來仍須要盡善盡美。

解決的問題？

• 直觀的表達了不一樣用戶的不一樣需求。
• 解決了項目的需求分析,爲接下來更詳細的任務做鋪墊。

【part2】類圖

描述的部分？

• 描述了系統中的各個類、接口以及它們之間的靜態結構和關係

面臨的問題？

• 主要面臨系統中的功能邏輯接口混亂問題

解決的問題？

• 如下設計解決了系統的靜態視圖設計，執行功能的描述，以及各個類之間的關係和協做

【part3】活動圖

描述的部分？

• 描述的是系統執行的活動部分，從活動到活動的流程

面臨的問題？

• 程序運行流程和模塊調用不清晰

解決的問題？

• 實現了整個客戶端使用週期各個活動的確認

【part4】狀態圖

描述的部分？

• 描述的是客戶端App 的整個狀態過程。
• 以及商家Web客戶端的整個狀態過程。
• 對整個應用的狀態進行一個描述。

面臨的問題？

• 面臨狀態的缺漏，沒有描述到全部的狀態。

解決的問題？

• 解決了整個客戶端使用週期各個狀態的確認。

【part5】實體關係圖

描述的部分？

• 描述了數據庫中各個實體及其屬性和各實體之間的關係

面臨的問題？

• 主要面臨數據庫中實體關係混亂、存在冗餘的問題

解決的問題？

• 如下設計解決了數據庫系統中各實體的設計問題，描述了各實體的屬性以及實體之間的關係

【part6】泳道圖 選作

描述的部分？

• 泳道圖是特殊的活動圖，因此描述的是也系統執行的活動部分

面臨的問題？

• 面臨各個活動歸屬不清晰，職責不明確的問題

解決的問題？

• 明確流程環節所屬的階段
• 可以將模型中的活動按照職責組織起來，清晰體現出某個動做發生在哪一個組織

工具選擇

選擇的工具和理由

咱們本組都選用了ProcessOn做爲繪圖工具。大一下C++課上畫類圖就開始用ProcessOn了。選取這款工具的緣由有：

1. 首先是免費。
2. ProcessOn是一個在線的工具，只要打開網頁就能用，這就很是的方便且高效。做爲在線的工具備一個隱藏的好處就是跨平臺
3. ProcessOn功能強大。流程圖、各類UML、類圖均可以用ProcessOn來繪製，這款繪圖工具包含了豐富的圖形和各類元素。而且操做十分簡便，基本上上手就能夠直接用。
4. 具備相似於石墨文檔的在線共同編輯功能。保存到本地也十分方便。

使用後的評價

我是負責畫類圖的。ProcessOn會根據你往一個類裏添加字段、方法的多少自動適配類圖的大小，這點很是親民。在對類圖進行合理的位置編排和佈局時，ProcessOn的拖動很是方便。繪製箭頭也只須要鼠標輕鬆一拉。使用體驗很是不錯，之後也還會繼續用。

評估成員的貢獻分配

本隊「臨時隊長」給出的「課上」貢獻分評估；

姓名	完成部分	貢獻分評估
李恆達	用例圖1	14%
趙暢(臨時隊長)	博客寫做，佈置任務，類圖	12%
林煌偉	類圖	12%
朱志豪	分而治之alpha版本事項，用例圖2	14%
志煒	狀態圖兩份	12%
文垚	實體關係圖	12%
佘嶽昕	泳道圖，活動圖	10%
張傑	泳道圖，活動圖	12%
陳超星	泳道圖，活動圖	2%

本隊「原隊長」給出的「課後」貢獻分評估；

姓名	完成部分	貢獻分評估
王彬	博客編寫、alpha任務分配	10%
李恆達	用例圖	12%
趙暢(臨時隊長)	博客寫做，佈置任務，類圖	14%
林煌偉	類圖	12%
胡展瑞	獲取其餘組的完成狀況	7%
王源	獲取其餘組的完成狀況	7%
志煒	狀態圖兩份	13%
文垚	實體關係圖	12%
佘嶽昕	泳道圖，活動圖	13%

PSP

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	10	10
· Estimate	· 估計這個任務須要多少時間	10	10
Development	開發	310	320
· Analysis	· 需求分析 (包括學習新技術)	30	30
· Design Spec	· 生成設計文檔	10	20
· Design Review	· 設計複審	30	30
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	0	0
· Design	· 具體設計	240	240
· Coding	· 具體編碼	0	0
· Code Review	· 代碼複審	0	0
· Test	· 測試（自我測試，修改代碼，提交修改）	0	0
Reporting	報告	10	10
· Test Repor	· 測試報告	0	0
· Size Measurement	· 計算工做量	5	5
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	5	5
	合計	330	340

本次換隊環節的感覺

我做爲沒有被換走的原隊伍成員，此次做業中擔任了第一組的臨時組長。首先昨天晚上做業佈置以後，咱們小組內及時進行了積極的討論，由於有提到爲了公平不容許私自開始工做，我就初步肯定今天過來先進行分工。

進行了分工，認領了工做以後，咱們就有條不紊地開始了繪圖製做。因爲是線下聚會，因此交流起來也很方便。繪製的各類UML圖就在線上工具交付。團隊的氛圍和積極性也不錯，彷佛換人沒有形成負面影響。

我認爲要在換人這個階段達成有效的成果，原來的團隊和還來的同窗須要作出共同的努力。首先做爲接納新同窗的團隊，首先多給予一點他們的幫助，我就把一些參考資料的連接發給了他們，以及上一次做業的立項文件，讓他們瞭解咱們的項目。在分工上，能夠照顧一下剛換過來的同窗，例如志豪一開始分到的是時序圖，然而時序圖對於不太瞭解咱們項目的他有些複雜，我就給他換成了alpha版本的分而治之圖。還有把超星、張傑這兩位新換來的同窗和一位原有成員三人共完成兩份圖，這樣壓力也不算太大。

其次，就是做爲被換出的同窗，他們的主動性是很重要的。其中超星同窗在前一天晚上就詢問咱們的分工，這個主動性要點個贊。週六一早進行分工時就很是順利。志豪同窗作完了一個部分以後還主動詢問我還有沒有別的能夠作的。因此他作了兩個圖，在此對他表示感謝。

氛圍我自我感受仍是不錯的，可是看同組同窗反映可能仍然存在溝通不充分的問題，須要之後繼續改進並適應。