UML複習

UML筆記

UML的主要內容就是畫圖和麪向對象的分析設計。

畫圖的過程當中咱們要注意每種圖的元素和每種圖的做用。

面向對象的分析設計中咱們要了解OA和OD的思想。

這些都是考試的重點

1. 用例圖

1.1 什麼是用例

用例是一個活動者（Actor）使用系統的一項功能時所進行的交互過程的一個文字描述序列。

用例的做用

1. 用例是軟件從需求分析到最終實現的最後一步，它顯示了用戶但願系統實現的功能，有利於用戶和軟件開發人員之間的溝通。
2. 用例可視化地表達了用戶的需求和系統功能，克服了純文字的說明性不足。
3. 用例是從外部定義系統，用戶不用關心繫統內部是如何實現各個功能的。

Actor的描述

Actor包括系統以外的須要使用系統與系統進行交互的事物，包括人、設備、外部系統等。

用例的讀者

開發人員、用戶、項目經理、測試人員等

用例中的關係

Actor與uc之間的關係

actor與use case之間是關聯關係，因此他們之間用直線鏈接

uc與uc之間的關係

1. 泛化
   泛化關係是父子關係，用空心三角箭頭表示。箭頭指向父uc
2. 包含
   包含關係是完成一個uc動做同時須要完成的動做，通常是多個uc作以前都須要完成這個動做咱們把它抽象爲一個包含關係，就是不少uc都包含這個uc。
   包含關係使用虛線箭頭表示，箭頭指向被包含的這個uc。
3. 擴展
   擴展關係是我在當前uc上擴展出新的uc，可是我不必定要作這個uc的關係。
   擴展關係也是用虛線箭頭表示，箭頭指向須要擴展的當前uc。

1.2 如何畫一個用例圖

肯定系統

用例圖自己就是爲系統設計的，通常我要作的這個東西就是系統。

肯定actors

識別活動者通常有如下幾個思路

1. 誰使用了系統的功能
2. 誰修改了系統的數據
3. 誰從系統處獲得信息
4. 誰須要對系統進行維護
5. 系統須要哪些硬件設備的支持？

肯定use case

用例實例

語法測試：【用戶】使用系統來【用例】

用例實例是在系統中執行的一系列動做，這些動做將產生活動者想要的價值結果。一個用例是由多個用例實例組成的。

避免CURD

肯定uc的時候很容易犯的錯誤是看到增長、修改、查閱和刪除等操做就把他們列爲use case，這樣會花費本身不少精力但得不償失。

1.3 案例：郵箱系統

目標：構建一個語音郵箱系統

郵箱系統描述：

語音郵箱系統中,能夠爲每一個系統用戶(郵箱主人)分配一個語音郵箱號碼.
進行留言時, 撥打語音郵箱系統的主號碼, 在聽到提示音「請輸入郵箱號」後,輸入語音郵箱號,聽到主人設定的問候語後,進行留言而後掛斷電話.
郵箱主人撥打語音郵箱系統的主號碼,在聽到提示音「請輸入郵箱號」後,輸入語音郵箱號,聽到主人設定的問候語後, 輸入密碼進行郵箱管理. 此時系統提供三種服務:1.接收信息; 2.更改問候語; 3.更改密碼.其中接收留言包括收聽新留言、存儲留言、刪除留言等。

肯定系統：

郵箱系統

肯定actor

郵箱主人和留言者

肯定use case

共同：

1. 撥打語音郵箱

郵箱主人：

1. 獲得語音郵箱號碼
2. 接受信息
3. 更改問候語
4. 更改密碼

留言人：

1. 給郵箱主人留言

畫出用例圖

這張圖很精妙，能夠看出上面3步走的時候遇到的一些問題和對use case之間關係的理解。

總結

use case不單純是動做，而應該是actor想要通過某一個操做達到某一個效果。（這句話有些彆扭，可是在理）。在郵箱系統案例中：

郵箱主人想完成的交互：

1. 接受信息
2. 更改問候語
3. 更改密碼

留言人想完成的交互：

1. 留言

這4個交互過程均可以抽象爲use case，可是主人和留言人想要完成以上4個交互的時候都須要在語音郵箱系統撥號，因此這就是一個多個uc抽象出來的帶有include屬性的use case。郵箱主人想要修改系統信息，還須要登陸系統。

以上」撥打郵箱號碼「，」登陸系統「就是分析過程當中漏掉的兩個use case

2. 類圖

2.1 介紹類圖

做用

1. 爲開發人員提供模仿現實世界的表達方式
2. 以用戶的術語與客戶進行交流，方便促使客戶說出須要解決的重要細節。

2.2 類與類之間的關係

1. 泛化
   泛化就是繼承關係。實線三角箭頭指向父類。
2. 接口
   interface嘛。虛線三角箭頭指向父類。
3. 組合
   總體由部分組成，部分能夠獨立於總體而存在。實心菱形箭頭指向總體類。
4. 聚合
   總體由部分組成，部分不能夠獨立於總體而存在。空心菱形箭頭指向總體類。
5. 關聯
   擁有的關係，一個類知道並能夠調用另外一個類的屬性和方法。
   雙向關聯：老師能夠有多名學生，而一個學生也能夠有多名老師。
   單向關聯：一個學生能夠有多門課程，可是課程是抽象類沒法擁有學生。
6. 依賴
   一個類的實現須要另外一個類的幫助。
   依賴關係用虛線箭頭表示。箭頭指向被依賴的對象。

2.3 類的版型

邊界類

邊界類是系統與外界的皎潔。如UI、窗體等類。

控制類

控制類用於體現應用程序的執行邏輯，提供相應的業務操做，將控制類抽象出來能夠下降界面和數據庫之間的耦合度。

控制類通常是由動賓結構的短語（動詞+名詞）轉化來的名詞，如增長商品對應有一個商品增長類，註冊對應有一個用戶註冊類等

實體類

實體類保存要放進持久存儲體（數據庫／文件等）的信息。通常咱們建立的類都是實體類，好比書類、計算機類等。

2.4 類圖的抽象層次

2.5 如何構造類圖

1. 尋找案例中的名詞
2. CRC原則（Class、Responsibility、Collaboration）

案例：圖書管理系統

2.6 對象圖

3. 順序圖和協做圖

3.1 順序圖

基本概念

順序圖顯示的是對象之間交互的圖，按照時間順序排列。時序圖是一個模型，用於描述對象如何隨着時間在某些行爲方面進行協做。

順序圖的命名

1. objectName:className
2. :className
3. objectName

因此看到奇怪的命名方式不要感到懼怕

構成要素

1. 對象
2. 生命線
3. 控制焦點

案例：圖書管理系統

案例描述：

課件裏的案例比較奇怪，邊界類比較少講可是在這個案例裏用了不少。會顯得比較亂。

常見問題

1. 消息循環發送
   *[i:= 1..n ]:Message2()
2. 消息條件發送
   1.[a>b]:message()
   2.使用文字說明
3. 類圖和順序圖中對象的關係
   須要相互參考、相互補充、相互協調

3.2 協做圖

概念

協做圖是表示對象間的交互圖，側重強調對象間的協做。

轉換成協做圖也比較容易，找到最開始的類，而後根據開始類延伸出一系列的類，相似畫腦圖同樣的方式畫出來就是協做圖了。

若是一個協做圖中的兩個對象之間的交互超過了兩個該怎麼畫這樣的協做圖？

答：一條狀態線上能夠有多個交互，也就是多個箭頭。➡️➡️

3.3 順序圖&協做圖

相同

1. 都支持全部的消息類型
2. 都肯定了發送者和接受者的責任
3. 都能在必定程度上衡量系統的耦合度

不一樣

1. 協做圖不能反映對象的建立、撤銷等操做
2. 順序圖強調的是時間順序上的交互，協做圖強調的是對象與對象之間的的交互
3. 協做圖必需要有消息的序列號

4. 狀態圖和活動圖

4.1 狀態圖

定義

狀態圖描述的是一個對象生命週期中的狀態序列，以及引發狀態變化的事件和伴隨狀態變化後的動做。

組成狀態圖的元素

1. 實心圓圈：初態
2. 實心圓圈外一個圈：終態
3. 圓角矩形：狀態
4. 箭頭：轉換。描述包括觸發事件、監護條件和動做等。turnOn[water exists]/boil water

細節

1. 能夠設置某個狀態進入和退出的時候執行什麼：
   entry/balabala和exit/balabala
2. H：
   表示歷史狀態

4.2 活動圖

定義

活動圖是描述系統行爲的模型，用來描述過程當中活動及其遷移。

活動圖中能夠包含多個對象，在圖中 有客戶、系統和供應商三個對象。

組成活動圖的元素

1. 實心圓圈：初態
2. 實心圓圈外一個圈：終態
   1. 橢圓矩形：活動節點
3. 菱形：分支與監護條件
4. 粗直線與箭頭：分岔與匯合
5. （泳道）（對象流）

4.3 狀態圖&活動圖

相同

1. 都是對系統的動態行爲建模。

不一樣

1. 狀態圖主要表示對象之間的交互關係，活動圖主要表示過程當中活動的交互關係。
2. 狀態圖中可以表現出併發

5. 構件圖與部署圖

5.1 構件圖&部署圖

構件圖用來建模系統的各個構件，包括源代碼文件、腳本文件、可執行文件等。它們是經過關係或者包的形式組織在一塊兒的。構件圖能夠幫助咱們了構件實現了軟件的哪些功能和構件位於軟件的什麼位置。

部署圖幫助咱們瞭解各個構件駐留在什麼硬件位置，以及硬件節點之間的交互關係。

5.2 構件圖

構件是系統中可更換的代碼模塊。

構件圖的解讀

1. 構件能夠由構件組成
2. 構件之間的關係主要是依賴：include、import和implement等。
   關係表示爲虛線箭頭上的文字
3. 構件還能夠和類圖中的對象產生聯繫。

5.3 部署圖

案例：web server

描述：

例 建模一個網上掃描系統的部署圖。其詳細的需求以下所示：

掃描儀經過內部的PCI總線鏈接到網卡。須要編寫代碼來控制掃描儀，代碼駐留在掃描儀內部。

掃描儀經過無線網卡與插入到Web服務器KONG的無線hub通訊，服務器經過HTTP協議向客戶PC機提供Web頁。

Web服務器安裝定製的Web服務器軟件，經過專用數據訪問構件與產品數據庫交互。

在客戶的PC機上將提供專用的瀏覽器軟件，它運行產品查詢插件，只與定製的Web服務器通訊。

畫部署圖的過程

1. 肯定節點

   注意案例中出現的硬件中網卡和無限模塊的關係。因此最後肯定下來的節點有：

   Scanner、NetworkCard、WirelessHub、KONG:WebServer和ClientPC。共5個

2. 添加通訊關係

   根據案例的描述很容易肯定通訊關係

3. 添加構件

   在硬件中有什麼軟件基本上就是須要尋找的構件。本案例中把DB做爲一個構件而不是一個硬件放在部署圖中，多是由於確實須要用到的地方實在比較小不做爲一個硬件。

4. 肯定關聯關係

   easy

6. GRASP原則

​ GRASP(General Responsibility Assignment Software Patterns)，中文名稱爲「通用職責分配軟件模式」，GRASP一共包括9種模式，它們描述了對象設計和職責分配的基本原則。

案例：購物車、商品

6.1 基本模式

信息專家（Expert）

通俗點來說，就是一個類只幹該乾的事情，不應乾的事情不幹。在系統設計時，須要將職責分配給具備實現這個職責所須要信息的類。信息專家模式對應於面向對象設計原則中的單一職責原則。

創造者（Creator）

若是符合下面的一個或者多個條件，則可將建立類A實例的職責分配給類B：

• B包含A；
• B聚合A；
• B擁有初始化A的數據並在建立類A的實例時將數據傳遞給類A；
• B記錄A的實例；
• B頻繁使用A。

此時，咱們稱類B是類A對象的建立者。若是符合多個條件，類B聚合或者包含類A的條件優先。

低耦合模式（Coupling）

耦合是評價一個系統中各個元素之間鏈接或依賴強弱關係的尺度

爲了下降改變帶來的影響和類與類之間的依賴，並提升重用性提出了低耦合的思想。

低耦合的基本原則

1. Don't Talk To Strangers

   不須要通訊的兩個類就誰也別理誰好了。

2. Transfer

   若是一個職能分配給A不合適（提升了耦合度或者不符合信息專家原則），能夠把這個職能分配給和A有鏈接的B

3. no connection between inner class

   兩個不一樣模塊的內部類之間不能直接鏈接

高內聚模式（Cohesion）

內聚是評價一個元素的職責被關聯和關注強弱的尺度。

在一個低內聚的類中會執行不少互不相關的操做，操做與操做之間沒有聯繫會顯得這個類很是雜亂，難以理解。

控制器模式（Controller）

問題：誰應該負責處理一個輸入系統事件？

分析：一個控制器是接受並處理系統事件的非圖形用戶界面的對象。一般一個控制器須要把接收的任務委託給其餘對象，它只負責控制和協調，自己不完成太多的功能。控制器不用包含太多的業務邏輯，因此一個系統能夠也應該設計多個控制器實現對不一樣模塊的控制。

6.2 拓展模式

多態（Polymorphism）

就是咱們學習的多態，能夠經過不一樣的子類實現不一樣的功能。

純虛構（Fabrication）

目的

純虛構模式用來處理低耦合與高內聚之間的矛盾。高內聚須要拆分出更多數量的類，可是對象之間須要協做來完成任務，這又形成了高耦合，反之亦然。

定義

和C++中的純虛函數相似，將實體類中的一部分功能抽象出來成爲純虛類。

中介模式（Indirection）

不影響耦合和狀況下把兩個類鏈接起來

受保護變化模式（Variation）

定義

預先找出不穩定的變化點，使用統一的接口封裝起來，若是將來發生變化的時候，能夠經過接口擴展新的功能，而不須要去修改原來舊的實現。也能夠把這個模式理解爲OCP(開閉原則)原則，就是說一個軟件實體應當對擴展開發，對修改關閉。

6.3 補充：單一職責原則

「就一個類而言，應該僅有一個引發它變化的緣由。」也就是說，不要把變化緣由各不相同的職責放在一塊兒，由於不一樣的變化會影響到不相干的職責。

案例：

圖形繪製程序和Area()之間沒有任何聯繫，違反了單一職責原則，應改成：

7. 面向對象設計原則

7.1 OO的原則

單一職責原則

應該只包含單一的職責，而且該職責被完整地封裝在一個類中。

就一個類而言，應該只有一個引發它變化的緣由。

開閉原則

軟件實體應該對擴展開放，對修改關閉。

軟件應該具備穩定的抽象層+靈活的具體層，找到系統的可變因素並將其封裝起來。

里氏替換原則

全部引用基類的地方必須可以透明地使用其子類的對象。

在軟件中將一個基類對象替換成它的子類對象，程序將不會產生任何錯誤和一異常，反過來則不成立。

我喜歡動物——>我喜歡狗

依賴倒轉原則

高層模塊不該該依賴低層模塊，他們都應該依賴抽象。

在程序中儘可能使用抽象層進行編程，而將具體類寫在配置文件中。

接口分離原則

客戶端不該該依賴哪些它不須要的接口。

當一個接口太大的時候，能夠將它分割成更小的接口。每個接口應該承擔一種相對獨立的角色，不應作的事情不要作。

7.2 其餘原則

合成複用原則

優先使用對象組合，而不是繼承來達到複用的目的。

繼承複用實現簡單、易於拓展，可是破壞了系統的封裝性。組合／聚合的耦合度較低，能夠有選擇性地調用對象的操做。

迪米特法則

一個軟件實體應當儘量少於其餘實體發生相互做用來下降耦合度。

不要和陌生人說話就是迪米特法則的內容。

8. 面向對象的分析設計

OOA的主要構成

如何使用OOA進行分析

OOD的方法

7.1 爲何須要面向對象的分析設計？

因爲現實世界中的問題一般較爲複雜，分析過程當中的交流又具備隨意性和非形式化等特色，每每客戶對軟件的需求是站在用戶的角度，而做爲軟件構架的工程師要按照軟件的角度來分析客戶的需求。爲了保證軟件需求規格說明的正確性、完整性和有效性就須要進一步驗證，咱們須要有一套完整而且具備至關可信力的分析設計體系，以便及時加以修正。所謂分析就是理解客戶腦子中的概念，跟客戶來溝通，分析出專業術語。設計就是對分析出來的專業術語進行概括，讓程序員可以思路更加清晰、更加順利進行軟件的開發活動。

7.2 OOA（Analysis）

面向對象分析方法（Object-Oriented Analysis，OOA），是在一個系統的開發過程當中進行了系統業務調查之後，按照面向對象的思想來分析問題。OOA所強調的是在系統調查資料的基礎上，針對OO方法所須要的素材進行的歸類分析和整理。

OOA的主要部分

OOA的主要部分分爲需求模型、基本模型、輔助模型和模型規約。

需求模型的主要表現方式就是咱們使用作多的用例圖，這是咱們進行面向對象分析的起點，咱們設計人員根據客戶的需求來建立和解釋用例圖，用來描述軟件應具有哪些功能模塊以及這些模塊之間的調用關係，用例圖包含了用例和參與者，用例之間用關聯來鏈接以求把系統的整個結構和功能反映給客戶，最終咱們會獲得軟件的結構和功能分解。

基本模型的主要表現方式是咱們常常用到的類圖，而基本模型能夠分爲3個層次：對象層、特徵層和關係層。對象層給出全部問題域和系統責任有關的對象，用對象類表示。特徵層定義每一個對象類的屬性與服務。關係層經過必定義的關係描述對象類之間的關係。

輔助模式的主要表現方式包括交互圖、活動圖、狀態圖和包圖等。這些圖都可以幫助咱們更好地理解和分析整個系統開發的業務和邏輯。

模型規約對模型中的全部元素進行詳細說明。

OOA方法的基本步驟

首先肯定需求和系統。系統是指事物的整體概貌和整體分析模型，對系統進行大體的規劃是開始系統分析的第一步。

而後捕捉系統系統中的對象。這裏所說的對象是對數據及其處理方式的抽象，它反映了系統保存和處理現實世界中某些事物的信息的能力。同時咱們須要將捕捉到的對象進行分類爲系統和系統以外的，分離出用戶、用例並畫出用例圖。

以後劃分類和類的屬性。類是多個對象的共同屬性和方法集合的描述，它包括如何在一個類中創建一個新對象的描述。屬性就是數據元素，可用來描述對象或分類結構的實例，可在類圖中給出，並在對象的存儲中指定。

最後識別對象間的關係。結構是指問題域的複雜性和鏈接關係。類成員結構反映了泛化-特化關係，總體-部分結構反映總體和局部之間的關係。

若是有特殊須要，還能夠創建詳細說明，對模型中的成分進行規範的定義和文字說明，能夠集中進行，也能夠分散在各個活動中。

OOA的主要原則

（1）抽象：從許多事物中捨棄個別的、非本質的特徵，抽取共同的、本質性的特徵，就叫做抽象。抽象是造成概念的必須手段。抽象是面向對象方法中使用最爲普遍的原則。抽象原則包括過程抽象和數據抽象兩個方面。過程抽象是指，任何一個完成肯定功能的操做序列，其使用者均可以把它看做一個單一的實體，儘管實際上它多是由一系列更低級的操做完成的。數據抽象是根據施加於數據之上的操做來定義數據類型，並限定數據的值只能由這些操做來修改和觀察。數據抽象是OOA的核心原則。它強調把數據（屬性）和操做（服務）結合爲一個不可分的系統單位（即對象），對象的外部只須要知道它作什麼，而沒必要知道它如何作。

（2）封裝：把對象的屬性和服務結合爲一個不可分的系統單位，並儘量隱蔽對象的內部細節。

（3）繼承：特殊類的對象擁有的其通常類的所有屬性與服務，稱做特殊類對通常類的繼承

（4）分類：就是把具備相同屬性和服務的對象劃分爲一類，用類做爲這些對象的抽象描述。分類原則其實是抽象原則運用於對象描述時的一種表現形式。

（5）聚合：又稱組裝，其原則是：把一個複雜的事物當作若干比較簡單的事物的組裝體，從而簡化對復瑣事物的描述。

（6）關聯：是人類思考問題時常常運用的思想方法：經過一個事物聯想到另外的事物。能令人發生聯想的緣由是事物之間確實存在着某些聯繫。

（7）消息通訊：這一原則要求對象之間只能經過消息進行通訊，而不容許在對象以外直接地存取對象內部的屬性。經過消息進行通訊是因爲封裝原則而引發的。在OOA中要求用消息鏈接表示出對象之間的動態聯繫。

（8）粒度控制：通常來說，人在面對一個複雜的問題域時，不可能在同一時刻既能縱觀全局，又能洞察秋毫。所以須要控制本身的視野：考慮全局時，注意其大的組成部分，暫時不詳察每一部分的具體的細節；考慮某部分的細節時則暫時撇開其他的部分。這就是粒度控制原則。

（9）行爲分析：現實世界中事物的行爲是複雜的。由大量的事物所構成的問題域中各類行爲每每相互依賴、相互交織。

7.3 OOD（Design）

OOD（Object Orient Design）是一種解決軟件問題的設計範式，一種抽象的範式。抽象能夠分紅不少層次，從很是歸納的到很是特殊的都有，而對象可能處於任何一個抽象層次上。另外，彼此不一樣但又互有關聯的對象能夠共同構成抽象：只要這些對象之間有類似性，就能夠把它們當成同一類的對象來處理。

OOD設計

OOD的主要工做是使用OOA的結果，將OOA得出的問題，給予設計方案解決。這一階段須要作的是對軟件系統的設計和規劃，包含的工做爲：

①問題域部分的設計；

對OOA的對象和類的模型進行細緻修改，詳細考量類的屬性、刪除沒必要要的類、抽象須要的繼承層次、組織對象的包含結構、對象間消息的傳遞方式和總體消息順序安排；

②人機交互與應用控制部分的設計；

交互界面子系統的設計:與界面有關的類及類間結構的設計,以及有關算法的設計；

交互界面子系統和應用之間接口的設計；

應用控制部分的設計:這部分對象主要完成應用的驅動工做。這部分對象不一樣於從現實世界中抽象出來的對象，在現實世界和問題域中沒有原型，它們同界面子系統中的對象及問題對象發生做用，控制系統的運行。

OOD階段就須要細緻到軟件的具體實現，而後是人機交互方面，如何使UI合理的提供交互，是否便於後續的功能擴展等。

OOD的目標

OOD的目標是管理程序內部各部分的相互依賴。爲了達到這個目標，OOD要求將程序分紅塊，每一個塊的規模應該小到能夠管理的程度，而後分別將各個塊隱藏在接口的後面，讓它們只經過接口相互交流。好比說，若是用OOD的方法來設計一個服務器-客戶端應用，那麼服務器和客戶端之間不該該有直接的依賴，而是應該讓服務器的接口和客戶端的接口相互依賴。

OOA和OOD的區別

OOA重點在於業務需求的分析，而OOD需在前述的問題基礎上設計軟件結構。