1. 程式人生 > >福大軟工1816 - 第八次作業(課堂實戰)- 專案UML設計

福大軟工1816 - 第八次作業(課堂實戰)- 專案UML設計

  • 團隊

成員 參與 貢獻比例
031602406 程曉巨集(臨時組長) 實體關係圖設計 11
031602501 蔡宇航 實體關係圖設計 8
051501124 王彬 類圖設計 8
031602438 葉一帆 類圖設計,泳道圖設計 13
031602407 何家健 活動圖設計 9
031602410 黃海潮 活動圖設計 9
031602429 王錦揚 狀態圖設計,時序圖設計 12
031602442 鄭孔宇 狀態圖設計 10
181600215 林翔宇 用例圖設計 10
031602421 林世傑 用例圖設計 10
  • UML圖

  • part1

  • 這裡描述的是系統哪部分?
    • 這部分主要描述系統後端,使用者、照片、評論和心情功能方面的內容
  • 這部分要面臨什麼樣的問題?
    • 各個功能的資訊交集比較多,存在資訊的冗餘
  • 以下設計解決了什麼問題?
    • 理清業務流程,降低後端耦合程度
  • 附:類圖

  • part2

  • 這裡描述的是系統哪部分?
    • 這部分主要描述使用者功能的選擇和跳轉。
  • 這部分要面臨什麼樣的問題?
    • 活動的進入、退出、跳轉。
  • 以下設計解決了什麼問題?
    • 理清功能分佈,更加直觀的展示功能的進入、退出、跳轉。
  • 附:狀態圖

  • part3

  • 這裡描述的是系統哪部分?
    • 這裡是旅遊記錄管理系統部分的用例圖
  • 這部分要面臨什麼樣的問題?
    • 這部分將面對如何管理使用者旅遊記錄和使用者如何編輯旅遊記錄的問題。
  • 以下設計解決了什麼問題?
    • 以下設計羅列了旅遊記錄的管理邏輯,使用者可以新增新紀錄和按文字,圖片,視訊這三個分類來檢視已有的記錄。關於新增記錄,支援新增文字,圖片和視訊。使用者編輯完後可以儲存,也可以刪除已有記錄。
  • 附:用例圖1

  • part4

  • 這裡描述的是系統哪部分?
    • 這裡是旅遊記錄分享系統部分的用例圖。
  • 這部分要面臨什麼樣的問題?
    • 這部分將面對使用者如何分享和分享後有哪些功能的問題。
  • 以下設計解決了什麼問題?
    • 以下設計列出了使用者生成分享內容的三種形式:使用者可以選擇一系列旅遊記錄生成旅遊故事,也可以把去過的地方連起來生成一張路線圖,或者把去過的地方標註出來生成旅遊版圖。使用者分享後,其他人可以點贊評論。
  • 附:用例圖 2

  • part5

  • 這裡描述的是系統哪部分?
    • 這裡是使用者中心及旅遊推薦系統部分的用例圖。
  • 這部分要面臨什麼樣的問題?
    • 這部分將面對使用者登入管理,使用者資訊維護和如何推薦旅遊地點的問題。
  • 以下設計解決了什麼問題?
    • 以下設計列出了基本的登入退出和使用者資訊維護功能。使用者可以檢視修改個人資訊,可以傳送反饋意見。關於旅遊地點推薦,可以選擇推薦附近的地點,或者根據以往的旅遊偏好,推薦下次旅遊地點。
  • 附:用例圖3

  • part6

  • 這裡描述的是系統哪部分?
    1. 檢視不同地圖版面以及個人資訊部分
    2. 記錄文字、照片、視訊及生成旅遊短故事部分
    3. 檢視使用者資訊和系統資訊以及提出反饋部分
    4. 生成各個時間段旅遊故事部分
    5. 分享不同版本線路圖部分
    6. 根據資訊生成附近及下次旅遊地點部分
  • 這部分要面臨什麼樣的問題?
    • 包含比較多部分的功能,以及各部分的功能都需進行細分,比較難以理清各個部分的流程以及各個功能的聯絡和各個部分的組合。
  • 以下設計解決了什麼問題?
    -設計完活動圖之後,能夠比較清晰和直觀的體現整個執行的活動流程,明白分割成不同的部分,及各個部分中所含有的具體功能和作用。
  • 附:活動圖

  • part7

  • 這裡描述的是系統哪部分?
    • 這部分主要描述資訊需求和儲存在資料庫中的資料資訊型別。
  • 這部分要面臨什麼樣的問題?
    • 理清現實實體之間關係並直觀描述實體屬性及實體之間聯絡。
  • 以下設計解決了什麼問題?
    • 方便需求分析,利於資料庫資訊儲存
  • 附:E-R圖

  • part8

  • 這裡描述的是系統哪部分?
    • 管理員、使用者、後端之間的關係。
  • 這部分要面臨什麼樣的問題?
    • 不同角色許可權、功能歸納
  • 以下設計解決了什麼問題?
    • 弄清楚角色關係,互動更安全方便
  • 附:泳道圖

  • part9

  • 這裡描述的是系統哪部分?
    • 功能的順序跳轉和返回。
  • 這部分要面臨什麼樣的問題?
    • 功能之間可能會出現混亂
  • 以下設計解決了什麼問題?
    • 解決了功能順序混亂的問題
  • 附:時序圖

工具選擇

我在第四組做狀態圖時選擇的是 Process On
-使用後對工具的評價
在網頁上可以直接製作很方便,而且我用到的功能都是不收費的。

PSP表格

PSP2.1 Personal Software Process Stages 預估耗時(分鐘) 實際耗時(分鐘)
Planning 計劃 10 15
· Estimate · 估計這個任務需要多少時間 100 180
Development 開發
· Analysis · 需求分析 (包括學習新技術) 10 10
· Design Spec · 生成設計文件 5 5
· Design Review · 設計複審 (和同事稽核設計文件)
· Coding Standard · 程式碼規範 (為目前的開發制定合適的規範)
· Design · 具體設計
· Coding · 具體編碼
· Code Review · 程式碼複審
· Test · 測試(自我測試,修改程式碼,提交修改)
Reporting 報告
· Test Report · 測試報告
· Size Measurement · 計算工作量
· Postmortem & Process Improvement Plan · 事後總結, 並提出過程改進計劃
合計 125 210
  • 給出本次換隊環節的感受
    我換到了第四組,這組的氛圍很好,就是在做UML設計的時候,其他隊還在討論的時候,我們已經確定好了分工,明確了自己的任務。行動力很強。臨時隊長和我原來的隊長相比的話,我沒有看到我原來隊長在這次專案中的表現,也不好下定論,兩個人都是做事認真負責又果斷。