軟工1816 · 作業（八）項目UML設計
阿新 • • 發佈：2018-10-21
進度 店鋪 泳道圖 描述 evel 評價 的確 階段 問題
以下設計解決了哪些問題
團隊信息
隊員姓名與學號
| 學號 | 姓名 | 博客鏈接 |
|---|---|---|
| 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在線版
選擇的理由
在線免安裝，方便簡潔且好看
使用後的評價
這個工具作為一個在線版即可編輯的工具還是很值得肯定的，省去了團隊成員安裝的時間，功能也挺強大的，還支持多人協作，是一個值得推薦的工具。
但也存在不足，例如格式刷只在思維導圖類別有，UML裏找不到，導致最後要上色的時候只能一個個圖標點擊——更改顏色——確定，有點繁瑣。
評估成員的貢獻分配
本隊“臨時隊長”給出的“課上”貢獻分評估；
| 姓名 | 完成部分 | 貢獻分評估 |
|---|---|---|
| 李恒達 | 用例圖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 | 計劃 | ||
| · Estimate | · 估計這個任務需要多少時間 | ||
| Development | 開發 | ||
| · Analysis | · 需求分析 (包括學習新技術) | ||
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計復審 | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合適的規範) | ||
| · Design | · 具體設計 | ||
| · Coding | · 具體編碼 | ||
| · Code Review | · 代碼復審 | ||
| · Test | · 測試（自我測試，修改代碼，提交修改） | ||
| Reporting | 報告 | ||
| · Test Repor | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 並提出過程改進計劃 | ||
| 合計 | 1650 |
本次換隊環節的感受
對臨時隊長：不管是臨時隊長還是原隊長都很給力，要點個贊，真的辛苦隊長。
對被換隊員：感覺有點對不起被換過來的新隊員吧，由於大家都不是很熟，所以分工和溝通都有點尷尬，最大的缺點就是不適應吧。
軟工1816 · 作業（八）項目UML設計