uml和模式01
1 UML
模型語言(Modeling Language 檢查ML)是一種設計語言，人們藉由設計語言來創造產品。 模型語言是人們用來設計系統模型(Model)的語言，其設計品是系統的模型，也就是產品的 藍圖。java
其實最先提出模式語言的是在建築界，建築師Christopher Alexander在20世紀70年代就已 提出模式語言的概念，模式語言含有建築師和居住人共同的表達方式，所以建築師和居住人 之間能相互瞭解和溝通，也能讓居住者瞭解建築師的創意。舉個例子，音樂家設計的曲譜， 也是一種模型。程序員
軟件系統方面的模型語言UML，用於軟件設計師創造軟件系統的藍圖，在創造過程當中設計師 將他的心意、情感和經驗融入模型中，程序員藉由UML和設計師溝通、心靈交匯，體會和理 解模型表達出來的內容，而後用擅長的程序語言表達成爲真實的軟件，同時因爲各個程序員 理解和水平關係，根據同一個uml藍圖設計編寫的軟件質量會有很大的差異。算法
UML應用於軟件需求分析時，其學習門檻將會大大下降!語法複雜度會下降，用戶不須要掌握 軟件開發的知識，只要清楚產品需求，認真學習和應用UML，就能夠和設計師經過UML在需求 分析階段達成共識。sql
咱們在用曲譜做爲例子，音樂家使用音樂模型語言(曲譜)，表達他的心意、情感和經驗，演 奏者經過音樂模型語言(曲譜)和音樂家溝通、心靈交匯，體會和理解模型表達出來的內容， 而後用擅長的樂器演奏出音樂。同時因爲各個演奏者理解和水平關係，根據同一個曲譜演奏 偶的音樂水平會有很大的差異。設計模式
UML有不少種圖，大致能夠分爲兩類，涉及到需求分析的是用例圖，類圖是最經常使用的UML圖， 後面咱們會重點描述。緩存
結構型的圖(Structure Diagram) 類圖(Class Diagram) 對象圖(Object Diagram) 構件圖(Component Diagram) 部署圖(Deployment Diagram) 包圖(Package Diagram) 行爲型的圖(Behavior Diagram) 活動圖(Activity Diagram) 狀態機圖(State Machine Diagram) 順序圖(Sequence Diagram) 通訊圖(Communication Diagram) 用例圖(Use Case Diagram) 時序圖(Timing Diagram)
2 用例圖
用例圖(Use Case Diagram)表達了系統提供給用戶那些服務，這些是用戶看得見的或感受得 到的，並且是用戶以爲有意義的、須要的功能，這些是系統需求的核心部分，因此是UML想 要表達的重點所在。bash
簡而言之，用例在系統的衆多功能當中，屬於直接提供用戶服務的部分，例如水利雲系統， 它具備"新建項目"、"項目緩存"、"項目編輯"、"文件轉換"、"要素輸出"、"數據讀取"、" 文件上傳"、"權限控制"、"地圖顯示"等等，其中只有一小部分是用戶能看到、感受到的， 又以爲有意義的服務，就是用例，而系統的其餘功能就不稱爲用例。就如黑客帝國第二集裏 先知所說："你看看那些鳥，有程序在控制它們，還有風、樹、日出、日落何有程序在負責它 們，着些程序你看不到，可是卻起關鍵做用。"，這些程序佔了系統的大部分，可是都不是 用例，它們屬於質量需求，對支持用例起了關鍵做用。架構
可是系統最終的目的是用例，給用戶提供有價值的服務，因此UML用例圖就特別凸顯系統受 益面的功能，因此期待在系統建立就能確保系統切中用戶的需求；就如蓋房子，在初期就要 和用戶明確房子的規格、面積、外觀、結構細節，若是房子改到通常，在作修改，這時房子 已將固化，很難再作改動了，只有推到重改；軟件也是同樣，在初期很是靈活，開發開始後， 就會逐漸固化，修改爲本加大，因此在初期用例分析很是重要。ide
UML用例圖用於表達用戶觀點下的系統功能需求，着重於系統的行爲需求，描述系統如何 (How)服務用戶，包括系統與用戶交互及對話的流程，確保用戶體驗。post
Use Case描述能更清楚的表達出系統的行爲需求，每一個用例皆表達了系統行爲的需求的一部 分，在用例圖中表示了用例的外觀行爲，在用例描述裏應詳細描述用戶使用系統的流程，例 如[註冊用戶]用例描述：
UC:註冊用戶
用戶行爲 系統響應
------------ ------------
1. 輸入登錄名 1.1 判斷合法性，只能使用數字、字母，長度大於2小於16
1.2 若是登錄名已註冊，給出提示
2. 輸入用戶名 判斷合法性，長度大於2小於16
3. 輸入密碼 判斷合法性，不能使用中文，長度大於6小於20
4. 輸入手機號 判斷合法性，不能使用數字，必須以13或15開頭，長度11位
5. 發送驗證碼 5.1 若是手機號空，不可發送驗證碼
5.2 若是手機號已註冊，給出提示
6. 註冊 6.1 若是有合法性錯誤，不可點擊註冊
6.2 若是沒有勾選《青清水利網站服務協議》，不可點擊註冊
6.3 若是驗證碼輸入錯誤，給出提示
6.4 若是驗證碼超時，給出提示
3 用例和類的關係
你必須仔細分辨用例(Use Case)、對象(Object)與系統(System)的不一樣，以及它們的相關性， 用例是描述系統的服務項，用例是系統的一個觀點(View)，是用戶(User)心裏對系統的期待， 因此UML用例圖表達了用戶心中期待系統給予的服務，也就是用戶對系統的需求，輸入系統 外觀，在用戶眼中，系統就像是青蛙眼中的池塘，用例就是青蛙眼中的荷葉，青蛙眼中的各 片荷葉之間沒有相連，也不關心各個荷葉在水下是如何鏈接在一塊兒的，至於架構師和設計師 則要關心水面下的根莖如何支撐水面的荷葉，水面下的許多子系統或對象，用於支持水面的 各片荷葉，不一樣的用例可要求同一個對象提供服務，一個用例可要求多個對象提供服務，用 例和對象之間是多對對關係。
類是面向對象的思惟，人們心中都有對象概念，而且系統就是一羣具備智慧、善於傳遞信息 的對象組成的，用戶心中的對象，是架構師心中的對象，亦是程序員心中的對象，容易達成 心心相印的境界，賦予對象人性，是面向對象的重要步驟，社會是由一羣有智慧、能溝通且 互助合做的我的組成，軟件則由一羣有智慧、善於傳遞信息的對象組成，這就是對象的人格 化。每一個對象都有本身的職責，就是對象的方法了，面向對象關鍵是劃分合適的對象，給每 個對象分配合適的職責，而後由這些活生生的對象互助合做完成任務。
4 類圖
這裏簡單介紹一下關係，類有繼承、實現、依賴、關聯、聚合、組合幾種關係，簡單介紹一 下：
[繼承]指的是一個類(稱爲子類、子接口)繼承另外的一個類(稱爲父類、父接口)的功能，相似於人類的父
親和兒子的關係
[依賴]能夠簡單的理解，就是一個類A使用到了另外一個類B，而這種使用關係是具備偶然性的、臨時性的、
很是弱的，可是B類的變化會影響到A，好比某人要過河，須要借用一條船，此時人與船之間的關係
就是依賴
[關聯]體現的是兩個類、或者類與接口之間語義級別的一種強依賴關係，好比我和個人朋友；這種關係比
依賴更強、不存在依賴關係的偶然性、關係也不是臨時性的，通常是長期性的，並且雙方的關係一
般是平等的、關聯能夠是單向、雙向的
[聚合]是關聯關係的一種特例，他體現的是總體與部分、擁有的關係，即has-a的關係，此時總體與部分之
間是可分離的，他們能夠具備各自的生命週期，部分能夠屬於多個總體對象，也能夠爲多個總體對象
共享；好比計算機與CPU、公司與員工的關係等
[組合]也是關聯關係的一種特例，他體現的是一種contains-a的關係，這種關係比聚合更強，也稱爲強聚合；
他一樣體現總體與部分間的關係，但此時總體與部分是不可分的，總體的生命週期結束也就意味着部分
的生命週期結束；好比你和你的大腦
說到類關係，就要說說設計模式了，軟件是人類心靈和智慧在虛擬空間的投射，軟件的性能 就是人類能力的擴展，它的活動就是人類心智活動的反映，然而，人類的軟件倒是問題多多， 面對變化的需求，軟件每每過於僵硬，過於脆弱，不易複用，難以維護，而軟件設計中出現 的問題，其實就是人類自身技術、能力、心智的不足，提升軟件能力的辦法，其中最重要的 就方法就是設計模式，就是類與類之間特定的關係組合，用於解決特定問題。
舉個例子：策略模式：策略模式針對一組算法，將每個算法封裝到具備共同接口的獨立的 類中，從而使得它們能夠相互替換。策略模式使得算法能夠在不影響到客戶端的狀況下發生 變化。策略模式把行爲和環境分開。環境類負責維持和查詢行爲類，各類算法在具體的策略 類中提供。因爲算法和環境獨立開來，算法的增減，修改都不會影響到環境和客戶端。
一個圍棋下的好的人知道，好的"形"對圍棋很是重要，形是棋子在棋盤上的幾何形狀的抽象 化，形就是模式，也是人腦把握和認識外界的關鍵，軟件比起圍棋更加複雜，因此形(模式) 更加劇要。咱們都知道風水，強調的是建築和環境的相互做用，認爲建築物與其環境是一個 和諧的總體，這個總體會給居住在其中的人帶來特定的體驗，對於一個軟件設計師來講，模 式就是軟件的風水，因此研究設計模式很是重要，研究類關係很是重要。