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

Team information

• 隊名： 彳艮彳亍團隊
• 各成員短學號、名:

學號：	姓名：	本次博客連接：
041602209	黃毓明（臨時隊長）	https://www.cnblogs.com/mingsonic/p/9820702.html
061600236	楊禮亮	http://www.cnblogs.com/YangLiLiang/p/9821082.html
031601124	蔣熊	https://www.cnblogs.com/jxdbky/p/9822930.html
031601123	黃志銘	http://www.cnblogs.com/zhimingfzu/p/9823028.html
031602219	柯奇豪	http://www.javashuo.com/article/p-mezkqnqe-dv.html
031602603	陳超星	https://www.cnblogs.com/ccxccx/p/9822698.html
041602204	丁水源	http://www.javashuo.com/article/p-wbsgrcgy-me.html
181600215	林翔宇

 

Division of labor

 

• 肯定 alpha 版本須要作哪些事情

模塊序號	模塊名	模塊具體內容
1	現場簽到	1）實現基本的簽到功能 2）改進簽到功能實現優化
2	發佈通知	1）實現基本的通知功能 2）實現通知欄提醒功能
3	投票	1）實現基本投票功能 2）結果數據的分析與返回
4	想法收集	實現基本的問答功能
5	文章共享	1）實現基礎的文本編輯功能 2）完成簡單的文本選擇註釋功能

 

                                       

• 各成員分工明細及 TODO list

 

• • 燃盡圖

 

UML  Design

 

Part1：（部署圖）

 • 這裏描述的是系統哪部分？

      這裏主要說明的是部署問題

• 這部分要面臨什麼樣的問題？
　　服務器及數據庫的搭建，先後端交互等。
• 如下設計解決了哪些問題？
　　解決的問題：
　　　　前端客戶操做返回給後臺服務器，後端服務器依照前端操做給出相應返回值，從數據庫中調用相應的數據。

 

 

 

 

Part2：（類圖）

 • 這裏描述的是系統哪部分？

      使用WeEdit小程序的功能方面內容。

• 這部分要面臨什麼樣的問題？
　　1）項目模塊定義不夠清晰；
       2）代碼未有統一格式；
• 如下設計解決了哪些問題？
　　解決的問題：
　　　　 經過統一參數，方便後續先後端工做的配合。

 

 

 

 Part 3：（狀態圖）

• 這裏描述的是系統哪部分？

      這部分UML描述了發佈簽到、發佈共享文檔、發佈投票功能可能的狀態以及其中狀態的具體活動

• 這部分要面臨什麼樣的問題？
　　每一個具體狀態轉化細化得不夠徹底、在實現中還需更近一步改進
• 如下設計解決了哪些問題？
　　解決的問題：
　　　　 體現了軟件須要的功能以及解決了軟件內部各功能實現的邏輯問題

 

 

 

 

 

 Part 4：（用例圖）

• 這裏描述的是系統哪部分？

       這裏是用戶在**WeEdit**系統上可以進行各項操做的部分，以及對操做內容的具體化。

• 這部分要面臨什麼樣的問題？
　　須要面臨功能如何按照用戶習慣排布的問題
• 如下設計解決了哪些問題？
　　解決的問題：
　　　　 各個功能模塊之間直觀的邏輯聯繫

 

 

 

Part 5：（活動圖）

• 這裏描述的是系統哪部分？

       描述了用戶具體選擇發佈通知，現場簽到，投票，想法收集和文章分享這幾大模塊。以及每一個模塊相對應的後續操做和結果。如進入現場簽到模塊後，能夠選擇簽到會議。

• 這部分要面臨什麼樣的問題？
　　不能防止同窗帶翹課的同窗的手機來簽到。
• 如下設計解決了哪些問題？
　　解決的問題：
　　　　 解決了用戶權限的問題。不一樣權限的用戶進入不一樣的界面，進行不一樣的操做，不會發生權限混亂形成文件出現錯誤。

 

 

 

 

Part 6：（時序圖）

• 這裏描述的是系統哪部分？

       展現對象之間交互的順序。它經過描述對象之間發送消息的時間順序顯示多個對象之間的動態協做。

• 這部分要面臨什麼樣的問題？
　　須要理清項目各模塊內的邏輯，按時間順序顯示各模塊內的動態協做。
• 如下設計解決了哪些問題？
　　解決的問題：
　　　　更加清晰地展現了各模塊內的交互邏輯、交互順序。

 

 

 

Part 7：（實體關係圖 ）（本人完成的部分~~~(*^_^*)~~~）

• 這裏描述的是系統哪部分？
 　　主要描述的是系統的概念結構設計的部分。
• 這部分要面臨什麼樣的問題？
　　實體的決定、實體屬性的決定、實體之間的關係（包括了一對一，一對多，多對一，多對多）
• 如下設計解決了哪些問題？
　　解決的問題：
　　　　1） 分配了七個實體：參與者、發起者、投票、現場簽到、文章分享、想法收集、發佈通知
　　　　2） 各實體屬性的決定。具體屬性可參照「實體關係圖」。
　　　　3） 各實體之間的關係。具體實體之間的關係可參照「實體關係圖」

（發起者）

（參與者）

Selected tool

• 選擇工具：   ProcessOn
• 選擇的緣由：  

            1）ProcessOn屬於線上的編輯軟件，無需額外下載，隨需隨用！

            2）ProcessOn操做界面整潔明瞭，極易上手，對新用戶的操做而言十分友好！

            3）ProcessOn功能豐富，可以解決許多圖形的繪製問題，額外功能十分豐富！

            4）ProcessOn集成了許多圖形的繪製，集成性強！

            5）同窗的推薦啦~~

Evaluation of the tool

            1）無需下載， very convenient！

            2）功能豐富，very convenient plus one！

            3）極易上手，very convenient plus two！

     

PSP Table

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

Individual Score

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

 

 

姓名	貢獻分+基礎分=總得分（%）
黃毓明	15+2=17
丁水源	14+2=16
楊禮亮	11+2=13
蔣熊	6+2=8
黃志銘	6+2=8
蘇路明	13+2=15
陳瀚霖	7+2=9
胡展瑞	12+2=14

 

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

 

 

給出本次換隊環節的感覺

• 首先呢，我以爲這種換隊環節在對相似的UML設計上是很能夠的，說說好處哈，其一就是新加入的隊員進行，做爲本隊隊員，咱們須要比原來更加認真地回答和思考問題，整理完思緒後再和交換的隊員描述，對於產品自己的定位以及可行性，能有交換隊員幫咱們也作詳細地參考；另外，在換隊過程當中，由於你們都不太熟悉，因此換隊過程當中，能夠提升你們的積極性，可以更好地完成項目的進行，再者，由於交換成員進來，使用的語言他們也會順便帶進來哈哈哈，因此不失爲更好地瞭解他們平時是怎麼分配工做以及進行的，anyway，真好！