UML&開發過程
UML學習
學習UML的三個階段，就是要解決三個問題：
1. 如何使用UML畫圖？（How）
2. 爲什麼要使用UML？（Why）
3. 什麼時候使用UML？（When）
三個問題對應三個階段（Stage）：
Stage1：學習UML的基本語法，包括各種UML的大圖適用情形。目標是能夠看懂UML圖，理解模型所表達的意思，能夠使用UML工具表達簡單的建模思想。
Stage2：深入學習UML語法，理解UML建模的功能特徵，體會UML建模給軟件設計及開發過程帶來的好處。目標是能夠在實際應用中靈活地擴展和修改它。
Stage3：深入學習UML和開發過程，將UML與開發過程結合起來。目的是找到UML發揮威力的地方施展開來。
開發過程方法學（Methodology）就是開發過程中經歷的步驟的結構和性質。
開發過程方法學：
1. 瀑布模型(waterfall)
四個階段：分析Analysis，設計Design，編碼Coding，部署Deployment
缺點：信息共享少，過程不能回溯到早期階段，不利於問題的逐步理解
2. 現代開發過程
1） 強調階段的無縫集成
2） 項目由多人協作完成，按角色分工
系統分析員：與客戶交流，理解業務領域問題；
系統架構師：設計問題的解決方案；
程序設計人員：將解決方案編製成代碼，交付可執行的目標系統；
系統工程師：將目標系統部署到硬件上運行；
項目經理：監控開發過程進度以及形成職責跟蹤的工作產品，向客戶報告項目的最新進展；
3） GRAPPLE（Guidelines for Rapid APPLication Engineering）快速應用工程指導原則，一個自適應的、靈活的開發思想。
五個段（Segment）組成一個過程RADDD（或RAD3）：
1. 需求收集（Requirements Gathering）
2. 分析（Analysis）
3. 設計（Design）
4. 開發（Development）
5. 部署（Deployment）
每個段有一些動作（Action）組成，每個動作產生一個工作產品，每個動都是其特定執行者（Player）的職責。
|
段 |
動作 |
工作產品 |
執行者 |
參與者 |
|
需求收集 |
發現領域過程 |
1.業務領域詞彙 |
系統分析員 |
目標系統的使用者 |
|
領域分析 |
1.深刻理解業務領域概念 |
系統分析員 |
目標系統的使用者 |
|
|
識別協助系統 |
1.發現依賴的老系統 |
開發組成員 |
企業IT管理員 |
|
|
發現系統需求 |
1.JAD session(Joint Application Development session)會議記錄 |
開發組成員 |
客戶組織決策者 |
|
|
提交結果給客戶 |
1.整理並提交上述工作產品給客戶 |
項目經理 |
客戶 |
|
|
分析 |
理解系統用法 |
1.一組用例圖（高層用例分析） |
用例分析人員 |
客戶 |
|
充實用例 |
1.JAD session會議記錄 |
用例分析人員 |
用戶 |
|
|
細化類圖 |
細化的類圖 |
對象建模者 |
用戶 |
|
|
分析對象狀態變化 |
狀態圖 |
對象建模者 |
用戶 |
|
|
定義對象之間的交互 |
1.序列圖 |
對象建模者 |
開發組成員 |
|
|
分析與協作系統的集成 |
1.詳細的系統部署圖 |
系統工程師 |
開發組成員 |
|
|
設計 |
開發和細化對象圖 |
1.對象圖 |
程序設計人員 |
開發組成員 |
|
開發構件圖 |
構件圖 |
程序設計人員 |
開發組成員 |
|
|
制定部署計劃 |
部署圖（明確節點中的構件） |
系統工程師 |
|
|
|
設計和開發用戶界面原型 |
1.紙質GUI原型 |
程序設計人員 |
開發組成員 |
|
|
測試設計 |
依據用例構建測試腳本 |
測試專家 |
開發組成員 |
|
|
編制文檔 |
1.設計文檔 |
文檔專員 |
開發組成員 |
|
|
開發 |
編制代碼 |
代碼 |
程序員 |
|
|
測試代碼 |
測試結果 |
程序員 |
|
|
|
構建GUI和GUI帶代碼的連接及測試 |
帶GUI的功能系統 |
程序員 |
|
|
|
完成文檔 |
開發和測試文檔 |
程序員 |
|
|
|
部署 |
編制備份和恢復計劃 |
備份和恢復計劃 |
系統工程師 |
開發組成員 |
|
在硬件中安裝系統 |
完全部署好的計算機系統 |
系統工程師 |
開發組成員 |
|
|
測試安裝後的系統 |
測試結果 |
開發組成員 |
|
|