需求獲取：用例圖、活**
需求分析：類圖、物件圖和包圖
系統分析與設計：狀態圖、順序圖、協作圖、活**、元件圖
測試：單元測試用類圖；整合測試用部署圖；確認測試用用例圖
參與者、用例、關係
用例圖顯示了系統和系統外實體之間的互動。這些實體被引用為參與者。參與者代表角色，可以包括使用者、外部硬體和其它系統
用例是有意義的系統服務或功能單元
泛化、擴充套件、包含
用例和參與者之間存在著一定的關係，這種關係屬於關聯關係，關聯關係是雙向的一對一關係，表明參與者與用例之間的通訊。
用例描述一般包括：簡要描述（說明）、前置（前提）條件、基本事件流、其他事件流、異常事件流、後置（事後）事件條件等
在用例建模的過程中，先找出參與者，再根據參與者確定每個參與者相關的用例，最後細化每個用例的用例規約。
系統邊界——軟體系統需要處理的整個問題空間的範圍
任何乙個系統都有乙個邊界的問題
邊界問題就是確定系統和相鄰系統交接部分
定義系統邊界就是定義系統的範圍，即哪些元素屬於本系統，哪些元素屬於相鄰系統，明確系統目標範圍
物件導向與UML建模
模型是什麼？簡單地說，模型是對現實的簡化。模型提供了系統的藍圖。模型既可以包括詳細的計畫，也可以包括從高層次考慮系統的總體計畫。乙個好的模型包括那些有廣泛影響的主要元素，而忽略那些與給定抽象水平不相關的次要元素。每個系統都可以從不同的方面用不同的模型來描述，因而每個模型都是乙個在語義上閉合的系統抽象...
物件導向分析與設計 建模工具UML
用例圖 use case diagrame 描述了人們希望如何使用乙個系統，將相關使用者 使用者需要系統提供的服務以及系統需要使用者提供的服務更清晰的顯示出來，以便使系統使用者更容易理解這些元素的用途，也便於開發人員最終實現這些元素。之所以說用例圖至關重要，是由於使用者並不關心系統的實現和內部結構，...
UML建模 傳統需求分析問題
該 包含如下功能模組 不清楚的 新聞和業界資訊 企業資料管理 招聘求職 專案供需資訊管理另乙個版本 前台 檢視新聞和業界資訊 檢視企業資料 檢視職位資訊 檢視供需資訊 後台 管理新聞和業界資訊 管理企業資料管理 管理招聘求職資訊 管理專案供需資訊管理描述需求時常見的一些模式 從業務的角度劃分為若干功...