對於分工我們沒有不是按「自己負責部分的核心模組做練習」（每個人對每個圖的某一模組來依次做完四個uml）的原因，是在於畫這些圖並不是都能徹底分成各個「自己負責部分」的，比如負責測試的、負責演算法的同學就不懂幹啥了。並且每個uml都按這種粒度的劃分並不是太合理，比如活**確實是可分成比較獨立的多塊，而用例圖只要一兩個人足夠。
建立在團隊成員對各個模組的業務邏輯都能對照原型比較熟悉地把控的基礎上，同時又為避免分工混亂，我們還是選擇了把這四個uml分別分配給相應同學，然後再由他們自己細化其中各模組怎麼分工的這種方式。
因為整個專案的邏輯並不是太複雜，而且各個操作之間相對連貫，如果非要從**斷層來畫的話，要不然就是太過簡單，要不然就是整個邏輯完整性不好。所以對於其中一部分uml圖，團隊選擇的方式是即使各人按模組分工，但仍然是在一整張大圖上協同操作，最後整合匯出來的圖還是對整個系統的描述。
（大圖位址）
超級無敵好用一生推的process on！
至於為什麼選擇process on，是因為我自己入坑一年多，畫什麼都拿process on，越用越覺得真的是超級強大的工具。思維導圖、uml、各種流程圖原型圖拓撲圖等等都有相應的模板。而且支援非常好用的多人協作功能，可以實時地看到協作者在圖上的操作。整個操作是非常方便的，畫出來的效果完全滿足強迫症患者的需求，如果覺得不好用一定是沒有get到正確的開啟方式（逃
對於這次作業...雖然道理都懂，但是在畫的過程中還是糾結於活**和狀態圖的區別到底是什麼，然後看到某篇關於uml狀態圖和活**寫的很詳盡部落格裡是這樣寫的：
活**可看作狀態圖的特殊形式。特殊性在於活**中的乙個活動結束後將立即進入下乙個活動而不需要事件觸發活動的轉移。突然覺得自己是做了多少冗餘的工作啊……
個人感覺真正能解決作業部落格裡提到的施工混亂問題，應該是乙個類似這樣的表：
不過完成表的工作量巨大...還在施工中。
軟工團隊 選題報告
偏向公益性，追求使用者體驗，不內建廣告 使用者場景分析 user analysis 甲類使用者 乙類使用者 丙類使用者 丁類使用者 戊類使用者 真實使用者調研 user survey 問卷 情況 問卷資料分析 您的年齡是？您認為您記錄的內容被瀏覽 互動的方式中，哪種更好？您對心理學方面了解多少？您的...
專案UML設計（團隊）
隊名 日不落戰隊 隊員資訊及貢獻分比例 短學號名 本次作業部落格鏈結 此次作業任務 貢獻分配 備註501 安琪1.用例圖 2.部落格 20 隊長 532智慧型 狀態圖15 612章鵬 1.類圖 2.活 18 616 語懇狀態圖15 618煒坤 用例圖17 621少 活 15 模組序號 模組名模組具體...
專案UML設計（團隊）
標籤 空格分隔 軟工實踐 隊名 wonderland之k班小分隊 分組長 漢森205 組員 文航248 興桔123 作業的傳送門 processon傳送門 選擇理由 基本功能齊全,簡潔 知乎良心推薦 支援多人協作,靈活方便 alpha 討論ing.附 uml部落格用例圖 姓名漢森 文航興桔 貢獻25...