《UML面向對象需求分析與建模教程》主要介紹基于UML2.5 標準的系統建模基本理論？軟件分析與設計方法,《UML面向對象需求分析與建模教程》加強了軟件案例的UML 示例說明,以提高學生的軟件分析與設計水平,進一步拓展學生分析問題？解決問題的能力,達到培養"厚基礎？寬口徑？會應用？能發展"的人才培養宗旨？
《UML面向對象需求分析與建模教程》共13章,內容包括緒論,面向對象方法？統一建模語言？RUP 統一過程？工具？UML 更多細節,系統的需求獲取？分析？設計？實現和測試？UML高級課題,案例介紹等？每章均有工程實踐中的相關案例說明及實踐應用的創意思考和提示,書的后一章重點描述一個完整的UML 建模課程設計案例？
目錄
第1章 緒論 1
1.1 UML的發展史 1
1.2 日常生活中的應用 2
1.3 本課程學習中需要注意的問題 3
部分 建模理論概述
第2章 面向對象方法 6
2.1 了解面向對象產生的原因 6
2.2 面向對象方法基本概念與特征 8
2.2.1 面向對象的概念 8
2.2.2 面向對象的特征 9
2.2.3 面向對象的要素 10
2.3 面向對象方法學開發過程 11
2.4 面向對象下一步發展方向 12
第3章 統一建模語言 14
3.1 建模語言三個類別 14
3.2 UML特點 15
3.3 網絡教學系統案例UML簡單圖示 17
3.3.1 系統功能 17
3.3.2 系統的UML建模 18
第4章 RUP統一過程 26
4.1 RUP產生 26
4.2 基于統一過程的UML系統建模 28
4.3 二維開發模型 29
4.4 RUP開發過程 30
4.4.1 初始階段 30
4.4.2 細化階段 30
4.4.3 構造階段 31
4.4.4 交付階段 31
4.5 RUP核心工作流 31
4.5.1 商業建模 31
4.5.2 需求 31
4.5.3 分析與設計 31
4.5.4 實現 32
4.5.5 測試 32
4.5.6 部署 32
4.5.7 配置和變更管理 32
4.5.8 項目管理 32
4.5.9 環境 32
4.6 RUP的要素和經驗 32
4.6.1 RUP十大要素 32
4.6.2 RUP六大經驗 35
4.6.3 RUP的優勢不足 35
第5章 Rational Rose建模工具 37
5.1 常用的UML建模工具概述 37
5.1.1 Rational Rose 38
5.1.2 RSA 38
5.1.3 PowerDesingner 39
5.1.4 Visio 39
5.2 Rational Rose說明 39
5.2.1 基本操作步驟 39
5.2.2 具體操作說明 40
第6章 UML的進一步討論 46
6.1 UML更多細節 46
6.1.1 用例圖細節 46
6.1.2 類圖細節 48
6.1.3 對象圖細節 52
6.1.4 狀態圖細節 53
6.1.5 活動圖細節 55
6.1.6 順序圖細節 56
6.1.7 協作圖細節 56
6.1.8 組件圖細節 57
6.2 UML 2.0概述 58
6.3 相關行業標準協會OMG 59
第二部分 UML系統建模的過程
第7章 需求獲取 62
7.1 需求流概述 62
7.2 需求獲取的困難 63
7.2.1 軟件需求獲取面臨的困難 63
7.2.2 軟件需求獲取困難的原因 64
7.2.3 需求工程過程 64
7.3 需求獲取的方法 65
7.4 復雜系統的復雜網絡需求獲取方法 66
7.5 需求路線圖 70
7.6 需求案例 71
7.6.1 人事管理系統功能需求描述 71
7.6.2 系統的UML表示 73
第8章 需求分析 75
8.1 確定客戶需要什么 75
8.2 需求分析方法 77
8.2.1 面向對象分析方法 77
8.2.2 面向對象分析 78
8.2.3 建立邏輯模型 78
8.2.4 以銀行網絡系統為例尋找類并建立類模型 79
8.2.5 建立過程模型 82
8.3 路線圖 84
8.4 分析人事管理系統案例 84
第9章 設計 88
9.1 設計介紹 88
9.2 面向對象設計 89
9.3 路線圖 91
9.4 設計案例 92
9.4.1 系統結構設計 92
9.4.2 核心用例的組件圖 92
9.4.3 系統數據庫設計 93
第10章 實現 95
10.1 對象實現 95
10.1.1 程序設計語言 95
10.1.2 類的實現 96
10.1.3 應用系統的實現 96
10.2 實現人理管理系統案例 96
10.2.1 系統登錄界面 96
10.2.2 員工信息界面 98
10.2.3 假條信息界面 100
10.2.4 工資信息界面 100
10.2.5 用戶權限登錄 102
第11章 測試 105
11.1 測試流 105
11.2 面向對象測試模型 106
11.3 測試人事管理系統案例 110
第三部分 高級課題
第12章 UML的形式化 114
12.1 形式化方法介紹 114
12.2 UML與形式化方法的結合 115
12.2.1 直接對UML模型進行形式化語義定義 115
12.2.2 UML到形式化方法的轉換 116
12.3 形式化方法 116
12.3.1 形式化方法介紹 116
12.3.2 B方法 117
12.3.3 需求獲取形式化語言的表示 119
12.4 形式化的案例 119
12.4.1 免疫系統 120
12.4.2 免疫系統建模 120
12.4.3 系統模擬及結果分析 133
第四部分 實驗案例
第13章 綜合案例 136
13.1 通訊錄安卓版需求分析 136
13.1.1 基本功能需求 136
13.1.2 系統用例分析 136
13.2 總體設計方案 138
13.2.1 系統類圖 138
13.2.2 狀態圖 139
13.2.3 順序圖 141
13.3 詳細設計 142
13.3.1 開發環境 142
13.3.2 系統界面設計 142
13.3.3 程序設計 144
13.4 系統測試 147
13.4.1 系統測試的意義及目的 147
13.4.2 測試步驟 147
13.4.3 測試數據 147
參考文獻 149
中英文技術詞匯對照表 151
第1章 緒論
"UML系統建模"是一門與軟件開發密切相關的建模課程。1968年軟件工程產生后，軟件分析與設計的技術在20世紀80年代末至90年代中期出現了一個發展高潮，UML是這個高潮的產物。它不僅統一了Booch、Rumbaugh和Jacobson的建模表示方法，而且使其有了進一步的發展，并終統一為大眾所接受的標準建模語言(unified modeling language，UML)。
1.1 UML的發展史
工程師為什么要建造模型？航天工程師為什么要建造航天器的模型？橋梁工程師為什么要建造橋梁模型？建造這些模型的目的是什么？
工程師建造模型來查明他們的設計是否可以正常工作。航天工程師建造好了航天器的模型，然后把它們放入風洞中了解這些航天器是否可以飛行。橋梁工程師建造橋梁模型來了解橋是否穩固。建筑工程師建造建筑模型可以了解客戶是否喜歡這種建筑樣式。通過建立模型來驗證建造事物的可行性。
UML系統建模是一種與面向對象軟件開發密切相關的建模方法。各種面向對象的分析與設計方法都為面向對象理論與技術的發展作出了貢獻。這些方法各有自己的優點和缺點，同時在各自不同范圍內擁有自己的用戶群。各種方法的主導思想以及所采用的主要概念與原則大體上是一致的，但是也存在不少差異。這些差異所帶來的問題是，不利于面向對象方法向一致的方向發展，也給用戶的選擇帶來了一些困惑。為此，Rational公司的Booch和Rumbaugh決定將他們各自的方法結合起來成為一種方法，并于1995年10月了第1個版本，稱為"統一方法"(Unified Method 0.8)。此時OOSE的作者Jacobson也加入了Rational公司，于是也加入了統一行動。1996年6月了第2個版本UML 0.9。鑒于統一行動的產物只是一種建模語言，而不是一種建模方法(因為不包含過程指導)，所以自UML 0.9起，改稱"統一建模語言"。在此過程中，由Rational公司發起成立了UML伙伴組織。開始時有12家公司加入，共同推出了UML 1.0版，并于1997年1月提交到對象管理組織(OMG)申請作為一種標準建模語言。此后，又把其他幾家向OMG提交建模語言提案的公司擴大到UML伙伴組織中，并汲取意見對UML進一步作了修改，產生了UML 1.1版。該版本于1997年11月4日被OMG采納。此后UML還在繼續改進，目前的版本是UML 2.5(www.UML.org)。
OMG提交給國際標準化組織(ISO)的UML 1.4已經通過審核成為國際標準(ISO/IEC 19501：2005)。UML早期發展過程如圖1-1所示。
圖1-1 UML的發展史
1.2 日常生活中的應用
模型是用某種工具對某個系統的表達方式。模型從某一個建模觀點出發，抓住事物重要的方面而簡化或忽略其他方面。工程、建筑和其他許多需要創造性思想的領域中都使用模型。
表達模型的工具要便于使用。建筑模型可以是圖紙上所繪的建筑圖，也可以是用厚紙板制作的三維模型，還可以用存于計算機中的方程來表示。一個建筑物的結構模型不僅能夠展示這個建筑物的外觀，還可以進行工程設計和成本核算。
軟件系統的模型用建模語言來表達，如UML。模型包含語義信息和表示法，可以采取圖形和文字等多種不同形式。
霧霾的研究可以建造模型嗎？建造模型的好處有哪些？
UML的目標是以面向對象各種相關圖的方式來描述任何類型的系統。常用的是建立軟件系統的模型，但UML也可用來描述其他非計算機軟件的系統或者商業機構或過程，以下是UML常見的應用。
信息系統：向用戶提供信息的存儲、檢索、轉換和提交處理存放在關系或對象數據庫中大量具有復雜關系的數據。
技術系統：處理和控制技術設備，如電信設備、軍事系統或工業過程，它們必須處理設計的特殊接口，標準軟件很少，技術系統通常是實時系統。
嵌入式實時系統：在嵌入其他設備(如移動電話、汽車、家電)的硬件上執行的系統通常是通過低級程序設計進行的，需要實時支持。
分布式系統：分布在一組機器上運行的系統，數據很容易從一臺機器傳送到另一臺機器，需要同步通信機制來確保數據完整性，通常是建立在對象機制上的，如CORBA、COM/DCOM或Java Beans/RMI上。
系統軟件：定義了其他軟件使用的技術基礎設施，操作系統、數據庫和在硬件上完成底層操作的用戶接口等，同時提供一般接口供其他軟件使用。
商業系統：描述目標、資源、人、計算機規則、法規、商業策略、政策等，以及商業中的實際工作、商業過程。商業系統是面向對象建模應用的一個重要的領域，引起了人們極大的興趣，面向對象建模非常適合為公司的商業過程建模，運用全質量管理等技術，可以對公司的商業過程進行分析、改進和實現，使用面向對象建模語言為過程建模和編制文檔，使過程更易于使用。
UML具有描述以上這些類型系統的能力。
1.3 本課程學習中需要注意的問題
建模是計算機學科所特有的嗎？其他領域是否需要建模？設想造一幢摩天大廈，如果沒有圖紙將會是怎樣的結果？
教師可按照章節進行一步步的理論教學，實踐性的案例貫穿在相關章節中，有興趣的學生可主動按照案例進行模仿建模，探索學習，主動學習，理論聯系實際學習效果將更好。
(1)簡單的案例描述在第3章講述，主要引導學生觀察了解UML常用的9種圖的畫法及作用，圖形簡單易用，便于學習，可立即上手模仿實踐。
(2)中型案例在全書的第二部分按章節詳細講述，按照統一過程的各過程流在第二部分的每章結尾處展開說明。
圖1-2是按軟件RUP過程設置建模的知識點概況。
圖1-2 建模的知識點框圖
學期開始，學生可在老師的協助指導下明確一個感興趣的軟件案例作為學期學習目標，教師講理論的同時學生自己動手一步步完成案例。教師課上講解的時候，學生也可舉一反三，并結合自己所做案例思考自己的經驗和教訓。圖1-3是軟件人才的發展途徑。
圖1-3 軟件工程師發展途徑
(3)復雜的大型案例在第三部分高級課題中講述，大型軟件可能是涉及人身財產安全的系統，還有一些大型系統的需求很難說清或抽取，第12章用案例詳細講述了這種系統建模過程中的復雜網絡需求獲取方法和形式化方法技術的補充作用。
部分
建模理論概述
本部分介紹面向對象方法的產生、UML的發展、RUP統一過程的模型、Rose工具及UML的更多技術細節。
第2章 面向對象方法
軟件工程從1968年產生以來，經歷了傳統軟件工程階段并發展到現在的高級軟件工程階段，面向對象的方法(簡稱00方法)在傳統軟件工程方法的基礎上產生，因其一些顯著特點解決了一些軟件問題，是目前主流的軟件開發方法。有了面向對象的思想才產生了后面所要介紹的UML。
請回憶傳統軟件工程課上完成軟件案例作業的過程，完成情況如何？該過程中存在哪些問題？
本章知識要點
(1)面向對象產生的原因。
(2)面向對象的思考方式。
興趣實踐
現實生活中哪些軟件基于面向對象方法開發？試舉一例。
探索思考
計算機硬件有摩爾定律，為什么軟件沒有呢？
預習準備
復習傳統的結構化軟件工程方法的知識及面向對象程序語言相關的三個特性。
2.1 了解面向對象產生的原因
俗話說：天下大勢，分久必合，合久必分。計算機軟件技術的發展也是一個"分久必合，合久必分"的過程。
從1946年2月14日臺計算機誕生之日起，軟件應運而生。
起初軟件是手工作坊的生產方式，沒有標準化的過程、工具和技術，從而導致大量軟件錯誤。之后計算機專家提出了各種語言和方法，但還是不能避免錯誤的發生。小型軟件(5000行代碼以下的軟件)基本能正確地生產出來，但大中型軟件(5萬行代碼以上的軟件是大型軟件，其間的為中型軟件)項目就很難保障。到目前為止約1/3的軟件項目是失敗的。
20世紀60年代起隨著計算機硬件性能的不斷提高和價格的不斷下降，其應用領域也在不斷擴大。人們在越來越多的領域把更多、更難的問題交給計算機解決。這使得計算機軟件的規模和復雜性與日俱增，從而使軟件技術不斷受到新的挑戰。60年代軟件危機的出現就是因為系統的復雜性超出了人們在當時的技術條件下所能解決的程度。此后在軟件領域，從學術界到工業界，人們一直在為尋求更先進的軟件方法與技
