UML實用技術_介紹,用例、類圖、時序圖(開發(fā)流程)V11

1、Uml實用技術Unified Modeling Language 我們動手做做練習我們動手做做練習 UML幫助我們做需求幫助我們做需求簡單了解簡單了解UMLUML在設計階段如何發(fā)揮作用在設計階段如何發(fā)揮作用主題主題 我們動手做做練習我們動手做做練習 UML幫助我們做需求幫助我們做需求簡單了解簡單了解UMLUML在設計階段如何發(fā)揮作用在設計階段如何發(fā)揮作用主題主題軟件開發(fā)過程詳解 目前的現(xiàn)實是什么？業(yè)務建模 在這個現(xiàn)實下，開發(fā)系統(tǒng)是為了達到什么目標？愿景 為了達到目標，系統(tǒng)應對外提供什么樣的功能和性能？需求 為了提供這些功能，系統(tǒng)內(nèi)部應該有什么樣的核心業(yè)務機制？分析 為了滿足性能，系統(tǒng)的核心機制

2、如何在選定的架構上實現(xiàn)？設計找找到到問問題題解解決決問問題題UML三個主要作用使用可視化建模來獲取并表現(xiàn)商業(yè)邏輯和對象使用可視化建模來分析和設計計算機應用程序使用可視化建模來分析和設計計算機應用程序 理由一：理由一：UML是客戶、系統(tǒng)分析員和程序員之間的是客戶、系統(tǒng)分析員和程序員之間的“橋梁橋梁” 用例圖用例圖 活動圖活動圖 狀態(tài)圖狀態(tài)圖 時序圖時序圖 對象圖對象圖 部署圖部署圖 UML三個主要作用 理由二：理由二：UML從客戶的角度將復雜的系統(tǒng)整理清楚從客戶的角度將復雜的系統(tǒng)整理清楚UML三個主要作用software可移植可移植技術交互技術交互性能性能全面全面容量容量穩(wěn)定性穩(wěn)定性錯誤處理錯誤

3、處理容錯性容錯性功能需求功能需求成本成本兼容性兼容性 理由三：理由三：UML能使越來越復雜的軟件能使越來越復雜的軟件 系統(tǒng)架構更加合理和健壯系統(tǒng)架構更加合理和健壯系統(tǒng)模型可由“4+1”視圖展現(xiàn)邏輯視圖邏輯視圖場景視圖場景視圖系統(tǒng)功能系統(tǒng)功能分析設計結構分析設計結構系統(tǒng)并發(fā)工作情況系統(tǒng)并發(fā)工作情況實現(xiàn)視圖實現(xiàn)視圖實現(xiàn)模塊和代碼間的關系實現(xiàn)模塊和代碼間的關系部署視圖部署視圖 系統(tǒng)物理拓撲架構系統(tǒng)物理拓撲架構進程視圖進程視圖4+1視圖模型，從視圖模型，從5個不同的視角包括包括邏輯試圖、進程視圖、物理視圖、開發(fā)個不同的視角包括包括邏輯試圖、進程視圖、物理視圖、開發(fā)視圖、場景視圖來描述軟件體系結構。每一

4、個視圖只關心系統(tǒng)的一個側面，視圖、場景視圖來描述軟件體系結構。每一個視圖只關心系統(tǒng)的一個側面，5個試個試圖結合在一起才能反映系統(tǒng)的軟件體系結構的全部內(nèi)容圖結合在一起才能反映系統(tǒng)的軟件體系結構的全部內(nèi)容系統(tǒng)模型可由“4+1”視圖展現(xiàn) 邏輯試圖主要是用來描述系統(tǒng)的功能需求，即系統(tǒng)提供給最終用戶的服務. 在邏輯視圖中，系統(tǒng)分解成一系列的功能抽象、功能分解與功能分析，這些主要來自問題領域（Problem Definition)。 在面向?qū)ο蠹夹g中，通過抽象、封裝、繼承,可以用對象模型來代表邏輯視圖，可以用類圖（Class Diagram）來描述邏輯視圖。邏 輯 視 圖Logic View系統(tǒng)模型可由“

5、4+1”視圖展現(xiàn) 開發(fā)視圖主要用來描述軟件模塊的組織與管理（通過程序庫或子系統(tǒng)）。服務于軟件編程人員， 方便后續(xù)的設計與實現(xiàn)。它通過系統(tǒng)輸入輸出關系的模型圖和子系統(tǒng)圖來描述。要考慮軟件的內(nèi)部需求：開發(fā)的難易程度、重用的可能性，通用性，局限性等等。開發(fā)視圖的風格通常是層次結構，層次越低，通用性越好（底層庫：Java SDK，圖像處理軟件包）。開 發(fā) 視 圖Development/Module View上升到組件概念上升到組件概念系統(tǒng)模型可由“4+1”視圖展現(xiàn) 進程試圖側重系統(tǒng)的運行特性，關注非功能性的需求（性能，可用性）。服務于系統(tǒng)集成人員，方便后續(xù)性能測試。強調(diào)并發(fā)性、分布性、集成性、魯棒性（

6、容錯）、可擴充性、吞吐量等。定義邏輯視圖中的各個類的具體操作是在哪一個線程（Thread）中被執(zhí)行。進程視圖 Process View現(xiàn)在公司里不再考慮功能能不能實現(xiàn)，而在于現(xiàn)在公司里不再考慮功能能不能實現(xiàn)，而在于PK性能，可擴展性等非功能性。性能，可擴展性等非功能性。系統(tǒng)模型可由“4+1”視圖展現(xiàn) 物理試圖主要描述硬件配置。服務于系統(tǒng)工程人員，解決系統(tǒng)的拓撲結構、系統(tǒng)安裝、通信等問題。主要考慮如何把軟件映射到硬件上，也要考慮系統(tǒng)性能、規(guī)模、可靠性等?？梢耘c進程視圖一起映射。 物理視圖(physical view)系統(tǒng)模型可由“4+1”視圖展現(xiàn) 場景用于刻畫構件之間的相互關系，將四個視圖有機地

7、聯(lián)系起來。可以描述一個特定的視圖內(nèi)的構件關系，也可以描述不同視圖間的構件關系。文本、圖形表示皆可。 n 小結 邏輯視圖、開發(fā)視圖，都主要是用來描述系統(tǒng)的靜態(tài)結構。 進程視圖、物理視圖，主要是用來描述系統(tǒng)的動態(tài)結構。 并非每個系統(tǒng)都必須把5個視圖都畫出來，而是各有側重。例如MIS系統(tǒng)側重于邏輯視圖、開發(fā)視圖，而實時控制系統(tǒng)則側重于進程視圖、物理視圖場景場景(Scenarios) 模型可由9個圖來展現(xiàn)Use CaseDiagramUse CaseDiagram用例圖用例圖ScenarioDiagramScenarioDiagram協(xié)作圖協(xié)作圖StateDiagramStateDiagram組件圖組

8、件圖ComponentDiagramComponentDiagram部署圖部署圖StateDiagramStateDiagram對象圖對象圖ScenarioDiagramScenarioDiagram狀態(tài)圖狀態(tài)圖Use CaseDiagramUse CaseDiagram時序圖時序圖StateDiagramStateDiagram類圖類圖活動圖活動圖模型模型墨綠色表示動態(tài)圖墨綠色表示動態(tài)圖粉紅色表示靜態(tài)圖粉紅色表示靜態(tài)圖（可把用例圖單列出來）（可把用例圖單列出來）功能功能靜態(tài)結構靜態(tài)結構物理架構物理架構動動態(tài)態(tài)行行為為用例圖，類圖，時序圖經(jīng)常用用例圖，類圖，時序圖經(jīng)常用UML9種圖 描述角色以

9、及角色與用例之間的連接關系。說明的是誰要使用系統(tǒng)，以及他們使用該系統(tǒng)可以做些什么。一個用例圖包含了多個模型元素，如系統(tǒng)、參與者和用例，并且顯示了這些元素之間的各種關系，如泛化、關聯(lián)和依賴。用例圖 類圖是描述系統(tǒng)中的類，以及各個類之間的關系的靜態(tài)視圖。能夠讓我們在正確編寫代碼以前對系統(tǒng)有一個全面的認識。類圖是一種模型類型，確切的說，是一種靜態(tài)模型類型。類圖 與類圖極為相似，它是類圖的實例，對象圖顯示類的多個對象實例，而不是實際的類。它描述的不是類之間的關系，而是對象之間的關系。對象圖 描述用例要求所要進行的活動，以及活動間的約束關系，有利于識別并行活動。能夠演示出系統(tǒng)中哪些地方存在功能，以及這些

10、功能和系統(tǒng)中其他組件的功能如何共同滿足前面使用用例圖建模的商務需求。活動圖 UML9種圖描述類的對象所有可能的狀態(tài)，以及事件發(fā)生時狀態(tài)的轉移條件。可以捕獲對象、子系統(tǒng)和系統(tǒng)的生命周期。他們可以告知一個對象可以擁有的狀態(tài)，并且事件(如消息的接收、時間的流逝、錯誤、條件變?yōu)檎娴?會怎么隨著時間的推移來影響這些狀態(tài)。一個狀態(tài)圖應該連接到所有具有清晰的可標識狀態(tài)和復雜行為的類；狀態(tài)圖 序列圖是用來顯示你的參與者如何以一系列順序的步驟與系統(tǒng)的對象交互的模型。順序圖可以用來展示對象之間是如何進行交互的。順序圖將顯示的重點放在消息序列上，即強調(diào)消息是如何在對象之間被發(fā)送和接收的。序列圖（順序圖） 和序列圖相

11、似，顯示對象間的動態(tài)合作關系?？梢钥闯墒穷悎D和順序圖的交集，協(xié)作圖建模對象或者角色，以及它們彼此之間是如何通信的。如果強調(diào)時間和順序，則使用序列圖；如果強調(diào)上下級關系，則選擇協(xié)作圖；這兩種圖合稱為交互圖。協(xié)作圖 描述代碼構件的物理結構以及各種構建之間的依賴關系。用來建模軟件的組件及其相互之間的關系，這些圖由構件標記符和構件之間的關系構成。在組件圖中，構件時軟件單個組成部分，它可以是一個文件，產(chǎn)品、可執(zhí)行文件和腳本等。構件圖 （組件圖）是用來建模系統(tǒng)的物理部署。例如計算機和設備，以及它們之間是如何連接的。部署圖的使用者是開發(fā)人員、系統(tǒng)集成人員和測試人員。部署圖 （配置圖）UML9種圖 用例圖：業(yè)

12、務建模、需求、測試 類圖：業(yè)務建模、分析、設計 對象圖：業(yè)務建模、分析、設計 組件圖：設計 部署圖：設計 順序圖：業(yè)務建模、分析、設計 協(xié)作圖：業(yè)務建模、分析、設計 狀態(tài)圖：需求、分析、設計 活動圖：業(yè)務建模、設計結結構構行行為為敏捷建模原則：需要時再添加敏捷建模原則：需要時再添加可互換可互換可互換可互換主要步驟 我們動手做做練習我們動手做做練習 UML幫助我們做需求幫助我們做需求簡單了解簡單了解UMLUML在設計階段如何發(fā)揮作用在設計階段如何發(fā)揮作用主題主題UML之用例圖需求分析中我們?nèi)绾握砗统橄笪覀儚挠脩裟堑玫降臉I(yè)務描述。用流程圖描述業(yè)務流程、用用例圖表達用戶業(yè)務工作識別執(zhí)行者執(zhí)行者要點

13、： 系統(tǒng)外必須和它交互 系統(tǒng)邊界直接與系統(tǒng)交互 有意義的交互屬于目標系統(tǒng)的責任 任何事物人、外系統(tǒng)、外部因素、時間識別執(zhí)行者抽象出執(zhí)行者的思路： 誰使用了系統(tǒng)的主要功能？ 誰改變了系統(tǒng)的主要數(shù)據(jù)？ 誰從系統(tǒng)獲取信息？ 誰需要系統(tǒng)的支持以完成日常工作任務？ 誰負責維護、管理并保持系統(tǒng)正常運行？ 系統(tǒng)需要應付（處理）哪些硬件設備？ 系統(tǒng)需要和哪些外部系統(tǒng)交互？ 誰（或什么）對系統(tǒng)運行產(chǎn)生的結果感興趣？ 有沒有自動發(fā)生的事件？識別執(zhí)行者責任類似或重疊抽象出執(zhí)行者UML之執(zhí)行者Actor之間也之間也有繼承關系。有繼承關系。且注意圖形且注意圖形表示。表示。識別用例用例的基本定義：用例實例是在系統(tǒng)中執(zhí)行的

14、一系列動作，這些動作將生成特定執(zhí)行者可見的價值結果。一個用例定義一組用例實例。Ivar Jacobson（RUP）通俗地講：執(zhí)行者通過系統(tǒng)達到某個有用目標通俗地講：執(zhí)行者通過系統(tǒng)達到某個有用目標步驟步驟路徑路徑目標目標識別用例設計用例要注意以下要點： 價值結果有意義的目標 系統(tǒng)執(zhí)行價值結果由系統(tǒng)生成 執(zhí)行者可見業(yè)務語言，用戶觀點注意：抽象一組用例實例時控制好用例的粒度識別用例有意義的目標：識別用例用戶觀點而非系統(tǒng)觀點：用戶觀點用戶觀點系統(tǒng)觀點系統(tǒng)觀點識別用例用例命名：執(zhí)行者視角動詞 （+賓語）狀語定語如：批量修改登錄記錄編號識別用例執(zhí)行者使用這個系統(tǒng)達到什么目標？語法測試：【執(zhí)行者】使用系統(tǒng)來

15、【用例】用例命名：慎用弱動詞、弱名詞30弱動詞：進行、使用、復制、加載、重復弱名詞：數(shù)據(jù)、報表、表格、表單、系統(tǒng)會掩蓋真正的業(yè)務識別用例識別用例識別用例討論：幾個登錄？或或注意角色的劃分和公共用例的定義要不把用戶抽象成三種，要不把用戶抽象成三種，或者把登錄抽象成三種。或者把登錄抽象成三種。識別用例用例的粒度：四輪馬車任何業(yè)務歸根到底都可以看作任何業(yè)務歸根到底都可以看作CURD，但光，但光CURD能為能為Actor提供價值嗎？提供價值嗎？ CRUD是是Create（創(chuàng)建）、（創(chuàng)建）、Read（讀?。?、（讀?。pdate（更新）和（更新）和Delete（刪除）縮寫（刪除）縮寫警惕警惕CURD泛

16、濫！泛濫！一般要避免全部使用，要抽象，公用一般要避免全部使用，要抽象，公用的，其它的不要，但默認有。的，其它的不要，但默認有。識別用例用例的粒度：在四輪馬車之前盡量細致另注：多個用例會操作同一項數(shù)據(jù)，即對一個數(shù)據(jù)項操作用例未必是同一個用例識別用例討論：登錄怎么處理？（確定用例之間的關系）用例有先后或前提關系時不要簡單認為是簡單的包含或者是擴展關系更進一步的精度用用例圖可以作用例文檔的例圖可以作用例文檔的總圖，進一步總圖，進一步的精度：有層次的的精度：有層次的文檔，文檔文檔，文檔中每一句話都有其價值中每一句話都有其價值通過關系整理用例用例的關系擴展：分離擴展路徑擴展：分離擴展路徑包含：提取公共步

17、驟，便于復用包含：提取公共步驟，便于復用泛化：同一業(yè)務目的的不同技術實現(xiàn)泛化：同一業(yè)務目的的不同技術實現(xiàn)大多數(shù)為包含關大多數(shù)為包含關系系include 是指用例中的包含關系，通常發(fā)生在多個用例中，有可以提取出來的公共部分（就象提取公因式一樣），例如 UseCaseA 中包括了 a 和 b 兩個流程，而 UseCaseC 中包含了 c 和 b 兩個流程。為了提高復用性，可以把 b 提取出來，形成另一個用例 UseCaseB，此時，UseCaseA include UseCaseB（表現(xiàn)為一條指向 UseCaseB 的虛線，箭頭在 UseCaseB 側），UseCaseC 也 include Us

18、eCaseB。因而，當有 include 關系時，被 include 的用例通常會被兩個以上的其他用例 include（否則就不需要重用，也就不需要提取出來了），用例圖如下：通過關系整理用例通過關系整理用例通過關系整理用例包含關系的誤用extend 則恰好相反。假設 UseCaseA 的功能描述為“發(fā)送一條通知”，可是，發(fā)送通知的方式可能有許多種，例如通過郵件發(fā)送、通過短信發(fā)送等。在需求分析階段，可能無法明確到底有多少種方式，在用例分析階段，UseCaseA 需要留出擴展接口，然后把已知的發(fā)送方式作為擴展用例給出，例如 UseCaseB 是“通過短信發(fā)送”，而 UseCaseC 是“通過郵件發(fā)

19、送”，此時，UseCaseB 和 UseCaseC extend 了 UseCaseA，表現(xiàn)為兩根虛線，箭頭指向 UseCaseA，用例圖如下：通過關系整理用例通過關系整理用例如果兩個用例之間，一個要調(diào)用另一個時，怎么辦？”（有可能是混淆了用例和模塊的關系），那么，首先要區(qū)分概念，用例就是用例，用例不是模塊，也不是組件（雖然一個用例能發(fā)展成為“一個或多個”模塊或組件）；其次，從用例分析的角度來看，如果用例 A 確實要調(diào)用到用例 B，那么，可以進一步分析：A 是調(diào)用了 B 的所有流程呢，還是其中一部分流程？（1）如果是調(diào)用了一部分，此時可以把 B 中的那部分流程提取出來，形成用例 C，然后 A

20、和 B 都 include C；（2）如果是調(diào)用了所有流程，那么，A 直接 include B 即可；（3）如果 A 沒有調(diào)用 B 中的任何流程那自然不用畫兩者的關系了通過關系整理用例通過關系整理用例通過關系整理用例用例間不存在用例間不存在“角色與用例角色與用例”的關系！的關系！泛化關系：子用例和父用例相似，但表現(xiàn)出更特別的行為；子用例將繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。在實際應用中很少使用泛化關系，子用例中的特殊行為都可以作為父用例中的備選流存在通過關系整理用例通過關系整理用例書寫用例文檔用例的內(nèi)容v 用例編號：用例名用例編號

21、：用例名v 執(zhí)行者執(zhí)行者v 前置條件前置條件v 后置條件后置條件v 涉眾利益涉眾利益v 基本路徑基本路徑v1XXXXv2XXXXv3XXXXv 擴展擴展v2a.XXXXv 2a1.XXXXv 字段列表字段列表v 業(yè)務規(guī)則業(yè)務規(guī)則v 非功能需求非功能需求v 設計約束設計約束v 待解決問題待解決問題書寫用例文檔涉眾利益利益的沖突利益的沖突銀行的銀行的用戶的用戶的法律的法律的誰的？誰的？書寫用例文檔涉眾利益v誰關心這個系統(tǒng)誰關心這個系統(tǒng), 會涉及到他的什么利益會涉及到他的什么利益? 對于同一件事情對于同一件事情, 不同的人看的視角可能不同的人看的視角可能各不相同各不相同, 而不同的視角則是基于不同的

22、而不同的視角則是基于不同的利益利益 。v探索系統(tǒng)的需求探索系統(tǒng)的需求, 就是探索不同的涉眾之就是探索不同的涉眾之間的利益的最佳平衡點間的利益的最佳平衡點 。v涉眾的位置不同涉眾的位置不同, 利益會有所不同利益會有所不同, 開發(fā)人開發(fā)人員要從最前排的涉眾員要從最前排的涉眾(老大老大)的利益為出發(fā)的利益為出發(fā)點點, 否則會影響需求必須明確否則會影響需求必須明確, 涉眾的利益涉眾的利益是不會輕易改變的是不會輕易改變的, 穩(wěn)定的利益關系穩(wěn)定的利益關系書寫用例文檔路徑交互步驟的描述v只寫只寫“可觀測的可觀測的”v使用主動語句使用主動語句v句子必須以執(zhí)行者或系統(tǒng)作為主語句子必須以執(zhí)行者或系統(tǒng)作為主語v每一

23、句都要朝目標邁進每一句都要朝目標邁進v分支和循環(huán)分支和循環(huán)v不要涉及界面細節(jié)不要涉及界面細節(jié)書寫用例文檔字段列表v+ 數(shù)據(jù)序列數(shù)據(jù)序列v 可選項可選項v* 多個多個v | | | 可能取值可能取值vA=B 把把B的結構賦給的結構賦給A可以用自然語言，也可以用表達式可以用自然語言，也可以用表達式書寫用例文檔字段列表v注冊信息注冊信息=公司名公司名+聯(lián)系人聯(lián)系人+電話電話+聯(lián)系地址聯(lián)系地址*v聯(lián)系地址聯(lián)系地址=州州+城市城市+街道街道+郵編郵編v保存信息保存信息=注冊信息注冊信息+注冊時間注冊時間v客房狀態(tài)客房狀態(tài)=空閑空閑|已預定已預定|占用占用|維修中維修中書寫用例文檔可用性v系統(tǒng)應易于使用系

24、統(tǒng)應易于使用v第一次使用時第一次使用時30分鐘內(nèi)能學會添加員工（任務時間）分鐘內(nèi)能學會添加員工（任務時間）v5次擊鍵能完成客人入住服務，不需要使用鼠標（操作次次擊鍵能完成客人入住服務，不需要使用鼠標（操作次數(shù)）數(shù)）v80%的用戶認為系統(tǒng)易學，并且使用效率高（用戶調(diào)查）的用戶認為系統(tǒng)易學，并且使用效率高（用戶調(diào)查）v系統(tǒng)界面應如系統(tǒng)界面應如XX附件所示的屏幕圖像（小心）附件所示的屏幕圖像（小心）可用性需求的表達可用性需求的表達？書寫用例的書面格式其他簡單視圖活動圖 之流程圖其他簡單視圖活動圖 之泳道圖泳道用于對于多個用戶泳道用于對于多個用戶一起完成一個過程，非一起完成一個過程，非常有用。常有用。

25、其他簡單視圖狀態(tài)圖 我們動手做做練習我們動手做做練習 UML幫助我們做需求幫助我們做需求簡單了解簡單了解UMLUML在設計階段如何發(fā)揮作用在設計階段如何發(fā)揮作用主題主題系統(tǒng)詳細設計主要目的詳細設計的目的是在具體編寫代碼前，在代碼結構層面上的一次設計，構層面的意思是只要表達出代碼的主要屬性和方法命名就可以，不必編寫方法體代碼。將系統(tǒng)架構實現(xiàn)的功能所涉及到的代碼結構都設計出來，這樣的做法能夠幫助開發(fā)人員明確開發(fā)思路，且能夠較為清楚的了解系統(tǒng)全局結構，作出相應的調(diào)整，避免代碼開發(fā)過程中再去調(diào)整代碼結構造成的開發(fā)資源的浪費。另一個主要的目的是，將系統(tǒng)的代碼結構清晰、直觀的描述成文，便于其他開發(fā)人員、維

26、護人員對系統(tǒng)的擴展與維護。Uml語言類圖基本畫法1.類設計簡單的講，就是創(chuàng)建一個類然后定義類中的屬性和方法。2.類間關系的設計，包括兩個層次包關系設計及類關系設計，兩個層次間可以認為是總與分的關系。具體的做法，根據(jù)各類間的應用或調(diào)用的方式不同明確其之間的關系，類間關系一般分成關聯(lián)、依賴、累計關系。3.關系確定規(guī)則見以下實例（包關系與類關系基本一致包關系有包中類關系決定）類中常見的繼承表達1繼承通過指向超類的一條閉合的，單箭頭的實線表示繼承通過指向超類的一條閉合的，單箭頭的實線表示類中常見的繼承表達2一個使用樹形記號的繼承實例一個使用樹形記號的繼承實例 類中常見的接口與實現(xiàn)表達Professor

27、類和類和Student類實現(xiàn)類實現(xiàn)Person接口的類圖實例接口的類圖實例 類中常見的關聯(lián)關系表達兩個類間的雙向關聯(lián)兩個類間的雙向關聯(lián) 一個類知道另一個類的屬性和方法，前者具有取得一個類知道另一個類的屬性和方法，前者具有取得后的方法，則形成了單向關聯(lián)，反之亦然。后的方法，則形成了單向關聯(lián)，反之亦然。類中常見的關聯(lián)關系表達兩個類間的單向關聯(lián)兩個類間的單向關聯(lián) 單向關聯(lián)關系，前者能向后者發(fā)送消息取得他的屬性單向關聯(lián)關系，前者能向后者發(fā)送消息取得他的屬性類中常見的關聯(lián)關系表達 描述兩個或多個類的結構性關系。 一個完整的關聯(lián)定義包含三部分，分別是類之間的關聯(lián)直線和兩個關聯(lián)端點 主要特性：角色，多重性，

28、導航性 角色：當一個類處于關聯(lián)的某一端時，該類就在這個關系中扮演了一個特定的角色；角色是關聯(lián)中靠近它的一端的類對另外一端的類呈現(xiàn)的職責。類中常見的關聯(lián)關系表達 多重性：關聯(lián)角色的多重性是說明一個關聯(lián)的實例中有多少個相互連接的對象。 導航性：給定兩個類的關聯(lián)，從一個類的對象能夠?qū)Ш降搅硪粋€類的對象，導航可以是雙向的。UniversityProfessor0.n10.n1Exactly oneZero or moreOne or moreZero or OneSpecified rangeMultiple, disjoint ranges10.*1.*0.12.42, 4.6類中常見的關聯(lián)關系表達

29、具體表現(xiàn)關聯(lián)關系是使用實例變量來實現(xiàn)現(xiàn)實例子比如客戶和訂單，每個訂單對應特定的客戶，每個客戶對應一些特定的訂單；再例如公司和員工，每個公司對應一些特定的員工，每個員工對應一特定的公司代碼表現(xiàn)public class Employeepublic void startWorking() public class Companyprivate Employee employee;public Employee getEmployee()return employee;public void setEmployee(Employee employee)this.employee = employee

30、;/公司運作 public void run()employee.startWorking();類中常見的依賴關系表達方式依賴關系中依賴關系中flight中沒有中沒有customer屬性，因此要用屬性，因此要用其他方法查找其他方法查找coustomer。如果。如果customer是全局的（包是全局的（包含靜態(tài)方法），則含靜態(tài)方法），則flight知道他的存在。如果知道他的存在。如果coustomer作為參數(shù)傳遞到作為參數(shù)傳遞到flight的方法中，則的方法中，則flight能夠引用到它，能夠引用到它，最后，如果最后，如果customer事例化為事例化為flight方法中的本地變量，方法中的本地

31、變量，則則flight就引用到了它的存在，在依賴關系中，必須采用三就引用到了它的存在，在依賴關系中，必須采用三種方法之一種方法之一類中常見的關聯(lián)關系表達具體表現(xiàn) 依賴關系表現(xiàn)在局部變量，方法的參數(shù)，以及對靜態(tài)方法的調(diào)用現(xiàn)實例子 比如說你要去擰螺絲，你是不是要借助(也就是依賴)螺絲刀(Screwdriver)來幫助你完成擰螺絲(screw)的工作代碼表現(xiàn) public class Person /* 擰螺絲 */ public void screw(Screwdriver screwdriver) screwdriver.screw(); 類中常見的聚合關系和組合關系類中常見的聚合關系和組合關系

32、聚合：指的是整體與部分的關系。通常在定義一個整體類后，再去分析這個整體類的組成結構。從而找出一些組成類，該整體類和組成類之間就形成了聚合關系。例如一個航母編隊包括海空母艦、驅(qū)護艦艇、艦載飛機及核動力攻擊潛艇等。需求描述中“包含”、“組成”、“分為部分”等詞常意味著聚合關系。組合：也表示類之間整體和部分的關系，但是組合關系中部分和整體具有統(tǒng)一的生存期。一旦整體對象不存在，部分對象也將不存在。部分對象與整體對象之間具有共生死的關系。聚合和組合的區(qū)別在于：聚合關系是“has-a”關系，組合關系是“contains-a”關系；聚合關系表示整體與部分的關系比較弱，而組合比較強；聚合關系中代表部分事物的對象與代表聚合事物的對象的生存期無關，一旦刪除了聚合對象不一定就刪除了代表部分事物的對象。組合中一旦刪除了組合對象，同時也就刪除了代表部分事物的對象。類中常見的聚合關系和組合關系我們用淺顯的例子來說明聚合和