軟工團隊 - UML設計

軟工團隊 - UML設計

分工

對於分工咱們沒有不是按「本身負責部分的核心模塊作練習」（每一個人對每一個圖的某一模塊來依次作完四個UML）的緣由，是在於畫這些圖並非都能完全分紅各個「本身負責部分」的，好比負責測試的、負責算法的同窗就不懂幹啥了。而且每一個UML都按這種粒度的劃分並非太合理，好比活動圖確實是可分紅比較獨立的多塊，而用例圖只要一兩我的足夠。

創建在團隊成員對各個模塊的業務邏輯都能對照原型比較熟悉地把控的基礎上，同時又爲避免分工混亂，咱們仍是選擇了把這四個UML分別分配給相應同窗，而後再由他們本身細化其中各模塊怎麼分工的這種方式。

UML

由於整個項目的邏輯並非太複雜，並且各個操做之間相對連貫，若是非要從哪裏斷層來畫的話，要否則就是太過簡單，要否則就是整個邏輯完整性很差。因此對於其中一部分UML圖，團隊選擇的方式是即便各人按模塊分工，但仍然是在一整張大圖上協同操做，最後整合導出來的圖仍是對整個系統的描述。

用例圖

• 面臨什麼問題：無
• 解決什麼問題：使各個參與者涉及到的功能一目瞭然

類圖

• 面臨什麼問題：無
• 解決什麼問題：能清楚系統中各個類及之間關係

狀態圖

• 面臨什麼問題：總感受怎麼畫都不對勁，畫着畫着又以爲本身在畫活動圖，返工N次
• 解決什麼問題：描述清楚各模塊對一系列觸發事件的狀態變化

活動圖

• 面臨什麼問題：無
• 解決什麼問題：清晰化整個系統的業務邏輯

（大圖地址）

工具

超級無敵好用一輩子推的 process on！

至於爲何選擇process on，是由於我本身入坑一年多，畫什麼都拿process on，越用越以爲真的是超級強大的工具。思惟導圖、UML、各類流程圖原型圖拓撲圖等等都有相應的模板。並且支持很是好用的多人協做功能，能夠實時地看到協做者在圖上的操做。整個操做是很是方便的，畫出來的效果徹底知足強迫症患者的需求，若是以爲很差用必定是沒有get到正確的打開方式（逃

---

對於此次做業...雖然道理都懂，可是在畫的過程當中仍是糾結於活動圖和狀態圖的區別究竟是什麼，而後看到某篇關於UML狀態圖和活動圖寫的很詳盡博客裏是這樣寫的：

活動圖可看做狀態圖的特殊形式。特殊性在於活動圖中的一個活動結束後將當即進入下一個活動而不須要事件觸發活動的轉移。

忽然以爲本身是作了多少冗餘的工做啊……

我的感受真正能解決做業博客裏提到的施工混亂問題，應該是一個相似這樣的表：

不過完成表的工做量巨大...還在施工中。