面向對象的問題的處理的關鍵是建模問題。建模能夠把在複雜世界的許多重要的細節給抽象出。許多建模工具封裝了UML(也就是Unified Modeling Language™),這篇課程的目的是展現出UML的精彩之處。node
UML中有九種建模的圖標,即:程序員
本課程中的某些部分包含了這些圖的細節信息的頁面連接。並且每一個部分都有一個小問題,測試一下你對這個部分的理解。dom
爲何UML很重要?函數
爲了回答這個問題,咱們看看建築行業。設計師設計出房子。施工人員使用這個設計來建造房子。建築越複雜,設計師和施工人員之間的交流就越重要。藍圖就成爲了這個行業中的設計師和施工人員的必修課。工具
寫軟件就好像建造建築物同樣。系統越複雜,參與編寫與配置軟件的人員之間的交流也就越重要。在過去十年裏UML就成爲分析師,設計師和程序員之間的「建築藍圖」。如今它已經成爲了軟件行業的一部分了。UML提供了分析師,設計師和程序員之間在軟件設計時的通用語言。學習
UML被應用到面向對象的問題的解決上。想要學習UML必須熟悉面向對象解決問題的根本原則――都是從模型的建造開始的。一個模型model就是根本問題的抽象。域domain就是問題所處的真實世界。測試
模型是由對象objects組成的,它們之間經過相互發送消息messages來相互做用的。記住把一個對象想象成「活着的」。對象有他們知道的事(屬性attributes)和他們能夠作的事(行爲或操做behaviors or operations)。對象的屬性的值決定了它的狀態state。spa
類Classes是對象的「藍圖」。一個類在一個單獨的實體中封裝了屬性(數據)和行爲(方法或函數)。對象是類的實例instances。線程
用例圖設計
用例圖Use case diagrams描述了做爲一個外部的觀察者的視角對系統的印象。強調這個系統是什麼而不是這個系統怎麼工做。
用例圖與情節牢牢相關的。情節scenario是指當某我的與系統進行互動時發生的狀況。下面是一個醫院門診部的情節。
「一個病人打電話給門診部預定一年一次的身體檢查。接待員找出在預定記錄本上找出最近的沒有預定過的時間,並記上那個時間的預定記錄。」
用例Use case是爲了完成一個工做或者達到一個目的的一系列情節的總和。角色actor是發動與這個工做有關的事件的人或者事情。角色簡單的扮演着人或者對象的做用。下面的圖是一個門診部Make Appointment用例。角色是病人。角色與用例的聯繫是通信聯繫communication association(或簡稱通信communication)
角色是人狀的圖標,用例是一個橢圓,通信是鏈接角色和用例的線。
一個用例圖是角色,用例,和它們之間的聯繫的集合。咱們已經把Make Appointment做爲一個含有四個角色和四個用例的圖的一部分。注意一個單獨的用例能夠有多個角色。
用例圖在三個領域頗有做用。
類圖
類圖Class diagram經過顯示出系統的類以及這些類之間的關係來表示系統。類圖是靜態的-它們顯示出什麼能夠產生影響但不會告訴你何時產生影響。
下面是一個顧客從零售商處預約商品的模型的類圖。中心的類是Order。鏈接它的是購買貨物的Customer和Payment。Payment有三種形式:Cash,Check,或者Credit。訂單包括OrderDetails(line item),每一個這種類都連着Item。
UML類的符號是一個被劃分紅三塊的方框:類名,屬性,和操做。抽象類的名字,像Payment是斜體的。類之間的關係是鏈接線。
類圖有三種關係。
一個關聯有兩個尾端。每一個尾端能夠有一個角色名role name來講明關聯的做用。好比,一個OrderDetail實例是一個Order實例的項目。
關 聯上的方向性navigability箭頭表示該關聯傳遞或查詢的方向。OrderDetail類能夠查詢他的Item,但不能夠反過來查詢。箭頭方向同 樣能夠告訴你哪一個類擁有這個關聯的實現;也就是,OrderDetail擁有Item。沒有方向性的箭頭的關聯是雙向。
關 聯尾端的數字表示該關聯另外一邊的一個實例能夠對應的數字端的實例的格數,經過這種方式表達關聯的多樣性multiplicity。多樣性的數字能夠是一個 單獨的數字或者是一個數字的範圍。在例子中,每一個Order只有一個Customer,但一個Customer能夠有任意多個Order。
下面這個表給出了最廣泛的多樣性示例。
多樣性 | 意義 |
---|---|
0..1 | 0或1個實例. n..m符號表示有n到m個實例 |
0..* or * | 沒有實例格數的限制(包括沒有). |
1 | 只有一個實例 |
1..* | 最少一個實例 |
每一個類圖包括類,關聯和多樣性表示。方向性和角色是爲了使圖示得更清楚時可選的項目。
包和對象圖
爲了簡單地表示出複雜的類圖,能夠把類組合成包packages。一個包是UML上有邏輯關係的元件的集合。下面這個圖是是一個把類組合成包的一個商業模型。
dependencies關係。若是另外一個的包B改變可能會致使一個包A改變,則包A依賴包B。
包是用一個在上方帶有小標籤的矩形表示的。包名寫在標籤上或者在矩形裏面。點化線箭頭表示依賴
對象圖Object diagrams用來表示類的實例。他們在解釋複雜關係的細小問題時(特別是遞歸關係時)頗有用。
這個類圖示一個大學的Department能夠包括其餘不少的Departments。
這個對象圖示上面類圖的實例。用了不少具體的例子。
UML中實例名帶有下劃線。只要意思清楚,類或實例名能夠在對象圖中被省略。
每一個類圖的矩形對應了一個單獨的實例。實例名稱中所強調的UML圖表。類或實例的名稱多是省略對象圖表只要圖的意義仍然是明確的。
順序圖
類圖和對象圖是靜態模型的視圖。交互圖是動態的。他們描述了對象間的交互做用。
順序圖將交互關係表示爲一個二維圖。縱向是時間軸,時間沿豎線向下延伸。橫向軸表明了在協做中各獨立對象的類元角色。類元角色用生命線表示。當對象存在時,角色用一條虛線表示,當對象的過程處於激活狀態時,生命線是一個雙道線。
消息用從一個對象的生命線到另外一個對象生命線的箭頭表示。箭頭以時間順序在圖中從上到下排列。
協做圖
協做圖也是互動的圖表。他們像序列圖同樣也傳遞相同的信息,但他們不關心何時消息被傳遞,只關心對象的角色。在序列圖中,對象的角色放在上面而消息則是鏈接線。
對象角色矩形上標有類或對象名(或者都有)。類名前面有個冒號(:)。
協做圖的每一個消息都有一個序列號。頂層消息的數字是1。同一個等級的消息(也就是同一個調用中的消息)有一樣的數字前綴,再根據他們出現的順序增長一個後綴1,2等等。
狀態圖
對象擁有行爲和狀態。對象的狀態是由對象當前的行動和條件決定的。狀態圖statechart diagram顯示出了對象可能的狀態以及由狀態改變而致使的轉移。
咱們的模型例圖創建了一個銀行的在線登陸系統。登陸過程包括輸入合法的密碼和我的帳號,再提交給系統驗證信息。
登陸系統能夠被劃分爲四種不重疊的狀態:Getting SSN, Getting PIN, Validating, 以及 Rejecting。每一個狀態都有一套完整的轉移transitions來決定狀態的順序。
狀態是用圓角矩形來表示的。轉移則是使用帶箭頭的連線表示。觸發轉移的事件或者條件寫在箭頭的旁邊。咱們的圖上有兩個自轉移。一個是在Getting SSN,另外一個則在上Getting PIN。
初始狀態(黑色圓圈)是開始動做的虛擬開始。結束狀態也是動做的虛擬結束。
事件或條件觸發動做時用(/動做)表示。當進入Validating狀態時,對象並不等外部事件觸發轉移。取而代之,它產生一個動做。動做的結果決定了下一步的狀態。
活動圖
活動圖activity diagram是一個很特別的流程圖。活動圖和狀態圖之間是有關係的。狀態圖把焦點集中在過程當中的對象身上,而活動圖則集中在一個單獨過程動做流程。活動圖告訴了咱們活動之間的依賴關係。
對咱們的例子來講,咱們使用以下的過程。
「經過ATM來取錢。」
這個活動有三個類Customer, ATM和 Bank。整個過程從黑色圓圈開始到黑白的同心圓結束。活動用圓角矩形表示。
活動圖能夠被分解成許多對象泳道swimlanes ,能夠決定哪些對象負責那些活動。每一個活動都有一個單獨的轉移transition鏈接這其餘的活動。
轉移可能分支branch成兩個以上的互斥的轉移。保護表達式(在[]中)表示轉移是從一個分支中引出的。分支以及分支結束時的合併merge在圖中用菱形表示。
轉移也能夠分解fork成兩個以上的並行活動。分解以及分解結束時的線程結合join在圖中用粗黑線表示
組件與配置圖
組件component是代碼模塊。組件圖是是類圖的物理實現。
配置圖Deployment diagrams則是顯示軟件及硬件的配置。
下面的配置圖說明了與房地產事務有關的軟件及硬件組件的關係。
物理上的硬件使用節點nodes表示。每一個組件屬於一個節點。組件用左上角帶有兩個小矩形的矩形表示。
原文連接:http://dn.codegear.com/article/31863