物件導向的需求分析基於物件導向的思想，以用例模型為基礎。開發人員在獲取需求的基礎上，建立目標系統的用例模型。所謂用例是指系統中的乙個功能單元，可以描述為操作者與系統之間的一次互動。用例常被用來收集使用者的需求。
首先要找到系統的使用者，即用例的操作者。操作者是在系統之外，透過系統邊界與系統進行有意義互動的任何事物。"在系統之外"是指操作者本身並不是系統的組成部分，而是與系統進行互動的外界事物。這種互動應該是"有意義"的互動，即操作者向系統發出請求後，系統要給出相應的回應。而且，操作者並不限於人，也可以是時間、溫度和其他系統等。比如，目標系統需要每隔一段時間就進行一次系統更新，那麼時間就是操作者。
可以把操作者執行的每乙個系統功能都看作乙個用例。可以說，用例描述了系統的功能，涉及系統為了實現乙個功能目標而關聯的操作者、物件和行為。識別用例時，要注意用例是由系統執行的，並且用例的結果是操作者可以觀測到的。用例是站在使用者的角度對系統進行的描述，所以描述用例要盡量使用業務語言而不是技術語言。關於用例模型的詳細建立方法，本書的實踐部分會進行介紹。圖2-13所示為某圖書館資訊管理系統的用例圖。
確定了系統的所有用例之後，就可以開始識別目標系統中的物件和類了。把具有相似屬性和操作的物件定義為乙個類。屬性定義物件的靜態特徵，乙個物件往往包含很多屬性。比如，讀者的屬性可能有姓名、年齡、年級、性別、學號、身份證號、籍貫、民族和血型等。目標系統不可能關注物件的所有屬性，而只是考慮與業務相關的屬性。比如，在"圖書館資訊管理"系統中，可能就不會考慮讀者的民族和血型等屬性。操作定義了物件的行為，並以某種方式修改物件的屬性值。
目標系統的類可以劃分為邊界類、控制類和實體類，如圖2-14所示。
圖2-14 邊界類、控制類和實體類的圖符
邊界類代表了系統及其操作者的邊界，描述操作者與系統之間的互動。它更加關注系統的職責，而不是實現職責的具體細節。通常，介面控制類、系統和裝置介面類都屬於邊界類。
控制類代表了系統的邏輯控制，描述乙個用例所具有的事件流的控制行為，實現對用例行為的封裝。通常，可以為每個用例定義乙個控制類。
實體類描述了系統中必須儲存的資訊及相關的行為，通常對應於現實世界中的事物。
確定了系統的類和物件之後，就可以分析類之間的關係了。物件或類之間的關係有依賴、關聯、聚合、組合、泛化和實現。
依賴關係是"非結構化"的和短暫的關係，表明某個物件會影響另外乙個物件的行為或服務。
關聯關係是"結構化"的關係，描述物件之間的連線。
聚合關係和組合關係是特殊的關聯關係，它們強調整體和部分之間的從屬性，組合是聚合的一種形式，組合關係對應的整體和部分具有很強的歸屬關係和一致的生存期。比如，計算機和顯示器就屬於聚合關係。
泛化關係與類間的繼承類似。
實現關係是針對類與介面的關係。
明確了物件、類和類之間的層次關係之後，需要進一步識別出物件之間的動態互動行為，即系統響應外部事件或操作的工作過程。一般採用順序圖將用例和分析的物件聯絡在一起，描述用例的行為是如何在物件之間分布的。
最後，需要將需求分析的結果用多種模型圖表示出來，並對其進行評審。由於分析的過程是乙個循序漸進的過程，合理的分析模型需要多次迭代才能得到。物件導向需求分析的示意圖如圖2-15所示。
採用物件導向思想的需求分析技術概論
隨著軟體工程方 與工程技術的發展，需求工程的概念應運而生，這不僅體現出需求的重要性，而且其規範性得到長足發展。需求工程 旨在了解軟體系統設計的真實意圖，具體功用及限制條件，並精確定義上述因素與系統行為的關係及系統隨時間和產品線變化而發生的各種演變。需求工程的內容 主要目標最終建立乙個分析模型 基於場...
UML物件導向需求分析與建模（四）
需求獲取 用例圖 活 需求分析 類圖 物件圖和包圖 系統分析與設計 狀態圖 順序圖 協作圖 活 元件圖 測試 單元測試用類圖 整合測試用部署圖 確認測試用用例圖 參與者 用例 關係 用例圖顯示了系統和系統外實體之間的互動。這些實體被引用為參與者。參與者代表角色，可以包括使用者 外部硬體和其它系統 用...
物件導向學習筆記四 需求分析的階段劃分
一般說來，需求分析要經過業務建模，用例分析，系統建模三個階段才能完成需求工作。1 業務建模的的目標是通過用例模型的建立來描述使用者需求，需求規格說明書通常在這個階段產生。這個階段採用業務用例和業務用例例項兩種型別。2 用例分析是系統分析員採用oo方法來分析業務用例的過程，這個階段又稱為概念模型階段。...