軟工1816 · 作業（八）專案UML設計
阿新 • • 發佈：2018-11-08
團隊資訊
隊員姓名與學號
| 學號 | 姓名 | 部落格連結 |
|---|---|---|
| 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了。選取這款工具的原因有：
- 首先是免費。
- ProcessOn是一個線上的工具，只要開啟網頁就能用，這就非常的方便且高效。作為線上的工具有一個隱藏的好處就是跨平臺，例如Visio是一個微軟的軟體，如果使用Linux和Mac就無法實現移動辦公。
- ProcessOn功能強大。流程圖、各種UML、類圖都可以用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 | 計劃 | 20 | 20 |
| · Estimate | · 估計這個任務需要多少時間 | 20 | 20 |
| Development | 開發 | 220 | 235 |
| · Analysis | · 需求分析 (包括學習新技術) | 30 | 25 |
| · Design Spec | · 生成設計文件 | 20 | 15 |
| · Design Review | · 設計複審 | 20 | 15 |
| · Coding Standard | · 程式碼規範 (為目前的開發制定合適的規範) | 0 | 0 |
| · Design | · 具體設計 | 150 | 180 |
| · Coding | · 具體編碼 | 0 | 0 |
| · Code Review | · 程式碼複審 | 0 | 0 |
| · Test | · 測試（自我測試，修改程式碼，提交修改） | 0 | 0 |
| Reporting | 報告 | 20 | 25 |
| · Test Repor | · 測試報告 | 0 | 0 |
| · Size Measurement | · 計算工作量 | 5 | 5 |
| · Postmortem & Process Improvement Plan | · 事後總結, 並提出過程改進計劃 | 15 | 20 |
| 合計 | 190 | 280 |