福大軟工 · 第八次作業
目錄
分工參考
UML
用例圖
描述的部分：
- 描述了我們軟體必須完成的任務，定義了必須完成的軟體功能；
- 基本呈現使用者與用例之間的具體關係；
- 基本表達系統的基本功能；
- 基本表達系統的具體**行為*。
面臨的問題：
- 如何具體對用例進行分類，使得用例更加具體；
- 如何對使用者與不同用例之間的關係詳細分析。
解決的問題：
- 初步獲取使用者的需求；
- 指導測試；
- 在整個過程中對其他工作流起到指導作用。
狀態圖
【part1】
描述的部分：
- 描述了使用者登入及未登入使用的狀態。
面臨的問題：
- 面臨使用者賬號管理及雲備份的問題。
解決的問題：
- 解決了使用者使用雲備份功能的問題。
- 解決了使用者註冊登入流程的問題。
- 解決了使用者找回密碼的問題。
附圖：
【part2】
描述的部分：
- 描述了使用者新建自定義備忘的狀態。
面臨的問題：
- 面臨使用者新增自定義備忘條目選填資訊較多的問題。
解決的問題：
- 使用者只需新增標題便可新建備忘，選填資訊個性化新增。
附圖：
【part3】
描述的部分：
- 描述了備忘資訊的狀態。
面臨的問題：
- 備忘錄的備忘錄事項狀態較多，如何分類、組織的的問題。
解決的問題：
- 使用者可清晰瞭解備忘錄事項的各種狀態。
附圖：
【part4】
描述的部分：
- 描述了所有備忘展示的狀態。
面臨的問題：
- 備忘資訊分類方式不同及備忘資訊展示形式比較多對於使用者較複雜。
解決的問題：
- 方便使用者切換檢視備忘資訊的分類方式，如按時間順序與事務型別。
- 方便使用者選擇備忘資訊展示的形式。
附圖：
活動圖
描述的部分
- 備忘錄生成過程。
- 個性化桌布設計。
- 使用者自定義備忘錄設定。
面臨的問題
- 面臨賬戶管理問題。
- 使用者自定義設計問題。如何使使用者獲得喜愛的簡潔實用的備忘錄桌布。
解決的問題
- 提供使用者行為分析功能，對使用者娛樂，遊戲方面進行時間監控。
- 提供智慧分析功能，智慧讀取快遞資訊和訂單資訊，將有效資訊轉化成備忘錄。
- 提供智慧提醒功能，在備忘錄自定義提醒時間之前進行簡訊提醒，並提供天氣提醒附加功能。
- 提供桌布生成功能，使用者自定義桌布樣式，字型顏色及字號，完成個性化特色桌布設計。
附圖
類圖
描述的部分：
- 描述了我們軟體必須完成的類、介面以及它們之間的靜態結構和關係；
- 類的部分：使用者、備忘錄、備忘錄分類夾、桌面控制元件、鎖屏桌布、圖片、音訊、備忘詳情、智慧分析、快遞資訊、訂單資訊、天氣資訊；
- 關係部分：關聯、聚合、泛化；
面臨的問題：
- 繪製類圖軟體的選擇和該軟體在類圖繪製上的使用方法；
- 類的定義（如屬性和方法）和個數比較不明確；
- 各種類之間的關係比較模糊；
解決的問題：
- 1確定使用StarUML進行類圖繪製並搜尋相關部落格教程學習使用StarUML繪製類圖；
- 2 與其他負責後端任務的組員討論交流溝通，確定主要的類的屬性、方法和個數；
- 3與組內負責前端、原型設計和其他UML圖繪製的組員反覆溝通；
附圖：
部署圖
描述的部分：
- 描述伺服器內部構建
- 描述軟體物理構架示意圖
- 描述軟體與硬體元件之間的物理關係以及處理節點
面臨的問題：
- 我們無法提供24小時開機的主機，只能進行租借與託管
解決的問題：
- 解決了開發者對於物理構架的巨集觀理解
- 提供了科學可實現的物理框架構建
附圖：
例項圖
描述的部分：
- 描述使用者和軟體之間、軟體各個部分之間的聯絡
- 描述軟體的邏輯結構
- 描述實體與其屬性的聯絡，是用來描述現實世界的概念模型。
面臨的問題：
- 1.具體實際功能要與後端商議，進行一定修改
解決的問題：
- 1.明確了各個部分的具體功能
- 2.具體解決了資料庫的設計
附圖：
物件圖
描述的部分：
- 軟體執行中的靜態時刻，描述物件之間關聯的例項；
- 描述某一個應用情景；
面臨的問題：
- 具體的應用情景需求；
- 資料流圖的設計；
- 抽象語義的視覺化描述；
解決的問題：
- 可以直觀表示出系統在某一個時刻（情景）一組類的實體之間的關係；
- 通過檢視某個時刻不同類之間的關係，思考歸納資料流圖；
- 對系統的設計檢視建模時，可以使用一組類圖完整地描述抽象的語義以及它們之間的關係；
附圖：
雲備份
描述的部分
- 這裡描述了系統的雲備份部分
面臨的問題
- 要面臨雲搭建的，以及訪問的問題
解決的問題
- 設計幫助後端成員理解這一過程
附圖
登陸系統：
描述的部分
- 這裡描述了使用者登陸系統時遇到的情況
面臨的問題
- 面臨與資料庫連線訪問和與現有資訊匹配的問題
解決的問題 - 幫助編碼人員分析登陸時遇到的情況
附圖
備忘錄管理：
描述的部分
- 這裡描述了使用者對備忘錄進行操作時遇到的情況
面臨的問題
- 面臨對備忘錄的內容進行增刪改的問題
解決的問題
- 幫助編碼人員分析錄入備忘錄時遇到的情況
附圖
備忘錄類別：
描述的部分
- 這裡描述了使用者對備忘錄類別進行操作時遇到的情況
面臨的問題
- 面臨對備忘錄的類別進行增刪改的問題
解決的問題
- 幫助編碼人員分析修改備忘錄類別時遇到的情況
** 附圖**
桌布系統：
描述的部分
- 這裡描述了使用者設定時遇到的情況
面臨的問題
- 面臨如何使用備忘錄生成桌布的問題
解決的問題
- 幫助編碼人員分析如何生成桌布的情況
附圖
智慧分析：
描述的部分
- 這裡描述了備忘錄軟體進行智慧分析時遇到的情況
面臨的問題
- 面臨如何對使用者行為進行分析和根據簡訊進行識別的問題
解決的問題
- 幫助編碼人員分析進行智慧分析時遇到的情況
附圖
包圖
描述的部分：
- 基本表達系統的基本功能
- 描述了軟體大致需要實現的功能
面臨的問題：
- 如何對於相關的類進行整合使之成為更加簡練的包
- 對於相關包之間的關係如何顯示比較好
解決的問題：
- 大致瞭解整個軟體的使用過程
- 對於繁雜的類實現相當於資料夾的功能，看起來更加簡潔
- 實現了uml的附加功能之一
附圖
通訊圖
【part1】
描述的部分
- 描述的是使用者登陸註冊流程。
面臨的問題
- 面臨使用者賬號管理以及雲備份的問題。
解決的問題
- 解決使用者註冊登入的問題
- 解決了使用者使用雲備份的問題
- 解決使用者找回密碼的問題。
附圖
【part2】
描述的部分
- 描述的備忘錄的生成以及刪除的問題。
面臨的問題
- 面臨備忘錄自動生成和使用者自行建立的問題。
解決的問題
- 解決使用者自動撰寫備忘錄的問題，解決根據手機簡訊生成備忘錄提醒的問題，解決備忘錄雲備份的問題。
附圖
【part3】
描述的部分
- 這裡是根據使用者手機上其他APP的使用頻率自動生成分析圖表的部分
面臨的問題
這部分要面臨應用使用頻率的獲取問題，生成分析圖表的問題，生成訊息提醒的問題。
解決的問題
自動獲取應用使用頻率，自動生成分析圖表，自動傳送訊息提醒。
附圖
貢獻分評定
分工參考：
福大軟工 · 第八次作業
團隊內部一致交流後，大致分為以下三個模組：任務工作量、任務完成效率、反饋度。貢獻分評定不應當僅僅侷限於工作量，而應該綜合考慮所有對團隊發展的因素。具體理由分析：
任務工作量：如構建之法中所說，在軟體行業中，如何衡量工作量這本身就是一個大問題。但是工作量卻並不能因為其難以衡量便不予以考慮，我們會採取團隊重複討論投票形式比較精確、公平的決定工作量佔比。比如：在還未開始時進行投票哪個模組的難度最大，工作量最多，這樣不夠全域性自然也會存在偏差，因此我們還會在實現過程中中途繼續進行討論對初始工作量、難度的投票結果進行一定程度的更改使之更為精確。儘量避免出現：“明明有效的只有十行程式碼，卻因為其中加了許多的冗餘程式碼甚至是空行使其程式碼量看上去較多”這類誤判情況。因此我們相信在我們團隊中評定出的較為合理的工作量作為貢獻分佔比的重要參考資料可以使團隊更良好的發展，相互良性競爭。
任務完成效率：團隊並非一個人，而是許多個成員之間的整體，多個模組功能組成的集合，相互之間的影響是很大的，產品的進度很可能會受其中某一個模組而停滯不前。比如產品釋出時出現前後端有一個模組還有一半未完成的現象那對整個專案的影響也非常大。因此任務完成效率也是一個重要衡量貢獻分佔比的資料。
反饋度：團隊想要良好的發展，就應當每一個成員都儘量保持較高的熱情和動力，這樣團隊才會持久的具有活力和潛力。因此將反饋作為一項重要參考資料決定貢獻分，防止出現因為個別成員懈怠導致整個團隊缺乏活力，專案完成自然也受到影響。
考慮到本次工作的臨時性，既要考慮到貢獻分評定的公平性，又要考慮要計算的快速性，故採用以下方式
- 臨時貢獻分評定 ：個人任務量 45%+完成度45%+反饋情況10%
- 要求：組裡總共11個人，分數加起來為100分
- 每個人結束前，對臨時隊內的每個人進行評定，彙總給PM，PM對每個人的給分進行平均，得出最後貢獻分
