UML中數據流圖，用例圖，類圖，對象圖，角色圖，活動圖，序列圖詳細講述保存供參考

這個文章，是我在急需的狀況下在園子裏搜索到的，原創做者是：DO-websoftware,爲了本身看方便，因此複製到個人空間，但願原創者不要介意哦~~~~很詳細的介紹，對個人幫助很大，謝謝哦。。。。

類圖，對象圖，角色圖：

1、UML中基本的圖範疇：

在 UML 2 中有二種基本的圖範疇：結構圖和行爲圖。每一個 UML 圖都屬於這二個圖範疇。結構圖的目的是顯示建模系統的靜態結構。它們包括類，組件和（或）對象圖。另外一方面，行爲圖顯示系統中的對象的動態行爲，包括如對象的方法，協做和活動之類的內容。行爲圖的實例是活動圖，用例圖和序列圖。

 

2、UML中的類圖：

1.類圖的表示：

類的 UML 表示是一個長方形，垂直地分爲三個區，如圖 1 所示。頂部區域顯示類的名字。中間的區域列出類的屬性。底部的區域列出類的操做。在一個類圖上畫一個類元素時，你必需要有頂端的區域，下面的二個區域是可選擇的（當圖描述僅僅用於顯示分類器間關係的高層細節時，下面的兩個區域是沒必要要的）。



描述：

頂部區域顯示類的名字。中間的區域列出類的屬性。底部的區域列出類的操做。當在一個類圖上畫一個類元素時，你必需要有頂端的區域，下面的二個區域是可選擇的（當圖描述僅僅用於顯示分類器間關係的高層細節時，下面的兩個區域是沒必要要的）。

·類名：若是是抽象類，則採用斜體

·類屬性列表：name : attribute type 如 flightNumber : Integer，這是最多見的表達形式

                 name : attribute type = default value  如 balance : Dollars = 0，這是帶有默認值的表達形式

·類方法列表：name(parameter list) : type of value returned

注意：

在業務類圖中，屬性類型一般與單位相符，這對於圖的可能讀者是有意義的（例如，分鐘，美圓，等等）。然而，用於生成代碼的類圖，要求類的屬性類型必須限制在由程序語言提供的類型之中，或包含於在系統中實現的、模型的類型之中。

2.繼承的表示：

爲了在一個類圖上建模繼承，從子類（要繼承行爲的類）拉出一條閉合的，單鍵頭（或三角形）的實線指向超類。




類名BankAccount和withdrawal操做使用斜體。這表示，BankAccount 類是一個抽象類，而withdrawal方法是抽象的操做。換句話說，BankAccount 類使用withdrawal規定抽象操做，而且CheckingAccount 和 SavingsAccount 兩個子類都分別地執行它們各自版本的操做。

3.接口的表示：

一個類和一個接口不一樣：一個類能夠有它形態的真實實例，然而一個接口必須至少有一個類來實現它。在 UML 2 中，一個接口被認爲是類建模元素的特殊化。所以，接口就象類那樣繪製，可是長方形的頂部區域也有文本「interface」。



注意：繼承用帶箭頭或三角形的實線表示，實現用帶箭頭或三角形的虛線表示

4.可見性的表示：

在面向對象的設計中，存在屬性及操做可見性的記號。UML 識別四種類型的可見性：public，protected，private及package。

UML 規範並不要求屬性及操做可見性必須顯示在類圖上，可是它要求爲每一個屬性及操做定義可見性。爲了在類圖上顯示可見性，放置可見性標誌於屬性或操做的名字以前。雖然 UML 指定四種可見性類型，可是實際的編程語言可能增長額外的可見性，或不支持 UML 定義的可見性。表4顯示了 UML 支持的可見性類型的不一樣標誌。

            UML 支持的可見性類型的標誌

標誌	可見性類型
+	Public
#	proteted
-	private
~	package

5.關聯的表示：

·雙向（標準）的關聯

關聯是兩個類間的聯接。關聯老是被假定是雙向的；這意味着，兩個類彼此知道它們間的聯繫，除非你限定一些其它類型的關聯。

一個雙向關聯用兩個類間的實線表示。在線的任一端，你放置一個角色名和多重值。圖 6 顯示Flight與一個特定的Plane相關聯，並且Flight類知道這個關聯。由於角色名以Plane類表示，因此Plane承擔關聯中的「assignedPlane」角色。緊接於Plane類後面的多重值描述0...1表示，當一個Flight實體存在時，能夠有一個或沒有Plane與之關聯（也就是，Plane可能尚未被分配）。圖 6 也顯示Plane知道它與Flight類的關聯。在這個關聯中，Flight承擔「assignedFlights」角色；圖 6 的圖告訴咱們，Plane實體能夠不與flight關聯（例如，它是一架全新的飛機）或與沒有上限的flight（例如，一架已經服役5年的飛機）關聯。

注意：關聯的一方關聯對象位於直線的上端，關聯數目位於同側的直線下端，另外一方則相反 

 

     多重值和它們的表示

可能的多重值描述
表示	含義
0..1	0個或1個
1	只能1個
0..*	0個或多個
*	0個或多個
1..*	1個或多個
3	只能3個
0..5	0到5個
5..15	5到15個

·單向關聯

在一個單向關聯中，兩個類是相關的，可是隻有一個類知道這種聯繫的存在。

一個單向的關聯，表示爲一條帶有指向已知類的開放箭頭（不關閉的箭頭或三角形，用於標誌繼承）的實線。如同標準關聯，單向關聯包括一個角色名和一個多重值描述，可是與標準的雙向關聯不一樣的時，單向關聯只包含已知類的角色名和多重值描述。

簡單的說就是OverdrawAccountReport中包含了BankAccount屬性，而BankAccount中不須要包含OverdrawnAccountsReport對象

6.聚合的表示：

聚合是一種特別類型的關聯，用於描述「整體到局部」的關係。在基本的聚合關係中， 部分類 的生命週期獨立於 總體類 的生命週期。

舉例來講，咱們能夠想象，車 是一個總體實體，而 車輪 輪胎是整輛車的一部分。輪胎能夠在安置到車時的前幾個星期被製造，並放置於倉庫中。在這個實例中，Wheel類實例清楚地獨立於Car類實例而存在。然而，有些狀況下， 部分 類的生命週期並 不 獨立於 總體 類的生命週期 -- 這稱爲合成聚合。舉例來講，考慮公司與部門的關係。 公司和部門 都建模成類，在公司存在以前，部門不能存在。這裏Department類的實例依賴於Company類的實例而存在。

讓咱們更進一步探討基本聚合和組合聚合。

注意：聚合與普通的關聯的區別在於：普通的關聯可能只是一個簡單的「包含、引用」關係，關聯和被關聯類之間在邏輯概念上不必定有緊密的聯繫，而聚合則不一樣，它表示的是一種內在關係緊密，相互依存，相互包含的概念，其中的一部分是構成另一部分的不可或缺的成分。

·基本聚合

有聚合關係的關聯指出，某個類是另外某個類的一部分。在一個聚合關係中，子類實例能夠比父類存在更長的時間。爲了表現一個聚合關係，你畫一條從父類到部分類的實線，並在父類的關聯末端畫一個未填充棱形。



圖中清楚的代表了類Car對象包含了另外一類Wheel的4個實例，這二者在概念上是密不可分的，其中的一個類是另外一個類的構成成分。菱形表示「包含」，箭頭表示被包含的對象，數字4表示包含的數目。

·組合聚合 

組合聚合關係是聚合關係的另外一種形式，可是子類實例的生命週期依賴於父類實例的生命週期。



注意:組合關係如聚合關係同樣繪製，不過此次菱形是被填充的。

7.反射關聯的表示：

類也可使用反射關聯與它自己相關聯。起先，這可能沒有意義，可是記住，類是抽象的。當一個類關聯到它自己時，這並不意味着類的實例與它自己相關，而是類的一個實例與類的另外一個實例相關。



圖描繪的關係說明一個Employee實例多是另一個Employee實例的經理。然而，由於「manages」的關係角色有 0..*的多重性描述；一個僱員可能不受任何其餘僱員管理。


3、UML中的對象圖：

實例的記號和類同樣，可是取代頂端區域中僅有的類名，它的名字是通過拼接的:

Instance Name : Class Name 如 Donald : Person

由於顯示實例的目的是顯示值得注意的或相關的信息，不必在你的模型中包含整個實體屬性及操做。相反地，僅僅顯示感興趣的屬性及其值是徹底恰當的。 

UML 2 也容許在實體層的關係/關聯建模。繪製關聯與通常的類關係的規則同樣，除了在建模關聯時有一個附加的要求。附加的限制是，關聯關係必須與類圖的關係相一致，並且關聯的角色名字也必須與類圖相一致。


4、UML中的角色圖：

建模類的實例有時比指望的更爲詳細。有時，你可能僅僅想要在一個較多的通常層次作類關係的模型。在這種狀況下，你應該使用 角色 記號。角色記號相似於實例記號。爲了創建類的角色模型，你畫一個方格，並在內部放置類的角色名及類名，做爲實體記號，可是在這狀況你不能加下劃線。





注意：角色圖和對象圖的一個明顯區別就是：對象圖每一個對象名稱下面都加了下劃線，而角色圖沒有 

如下是：序列圖

序列圖主要用於按照交互發生的一系列順序，顯示對象之間的這些交互。很象類圖，開發者通常認爲序列圖只對他們有意義。然而，一個組織的業務人員會發現，序列圖顯示不一樣的業務對象如何交互，對於交流當前業務如何進行頗有用。除記錄組織的當前事件外，一個業務級的序列圖能被看成一個需求文件使用，爲實現一個將來系統傳遞需求。在項目的需求階段，分析師能經過提供一個更加正式層次的表達，把用例帶入下一層次。那種狀況下，用例經常被細化爲一個或者更多的序列圖。

組織的技術人員能發現，序列圖在記錄一個將來系統的行爲應該如何表現中，很是有用。在設計階段，架構師和開發者能使用圖，挖掘出系統對象間的交互，這樣充實整個系統設計。

 序列圖的主要用途之一，是把用例表達的需求，轉化爲進一步、更加正式層次的精細表達。用例經常被細化爲一個或者更多的序列圖。序列圖除了在設計新系統方面的用途外，它們還能用來記錄一個存在系統（稱它爲「遺產」）的對象如今如何交互。當把這個系統移交給另外一我的或組織時，這個文檔頗有用。

Java應用程序由許多類所構成，是Java實現面向對象應用程序的核心。類圖主要描述Java應用程序中各類類之間的相互靜態關係，如類的繼承、抽象、接口以及各類關聯。要利用UML設計Java應用程序，僅僅使用類圖來描述這些靜態關係，利用可視化工具，要實現Java應用程序的代碼自動生成，是遠遠不夠的。咱們還必須描述各類類相互之間的協做關係、動態關係，如時間序列上的交互行爲。其中UML序列圖就是用來描述類與類之間的方法調用過程（或消息發送）是如何實現的。

1、UML中的新元素－框架：

在 UML 2中，框架元件用於做爲許多其餘的圖元件的一個基礎，可是大多數人第一次接觸框架元件的狀況，是做爲圖的圖形化邊界。當爲圖提供圖形化邊界時，一個框架元件爲圖的標籤提供一致的位置。在 UML 圖中框架元件是可選擇的。



除了提供一個圖形化邊框以外，用於圖中的框架元件也有描述交互的重要的功能, 例如序列圖。在序列圖上一個序列接收和發送消息（又稱交互），能經過鏈接消息和框架元件邊界，創建模型（如圖 2 所見到）。




對於序列圖，圖的標籤由文字「sd」開始。當使用一個框架元件封閉一個圖時，圖的標籤須要按照如下的格式：圖類型 圖名稱。

UML 規範給圖類型提供特定的文本值。（舉例來講，sd表明序列圖，activity表明活動圖，use case表明用例圖）。

2、UML中的序列圖：

序列圖主要用於按照交互發生的一系列順序，顯示對象之間的這些交互。

在項目的需求階段，分析師能經過提供一個更加正式層次的表達，把用例帶入下一層次。那種狀況下，用例經常被細化爲一個或者更多的序列圖。

序列圖的主要用途之一，是把用例表達的需求，轉化爲進一步、更加正式層次的精細表達。用例經常被細化爲一個或者更多的序列圖。序列圖除了在設計新系統方面的用途外，它們還能用來記錄一個存在系統（稱它爲「遺產」）的對象如今如何交互。

序列圖的主要目的是定義事件序列，產生一些但願的輸出。重點不是消息自己，而是消息產生的順序；不過，大多數序列圖會表示一個系統的對象之間傳遞的什麼消息，以及它們發生的順序。圖按照水平和垂直的維度傳遞信息：垂直維度從上而下表示消息/調用發生的時間序列，並且水平維度從左到右表示消息發送到的對象實例。

1.生命線：

生命線畫做一個方格，一條虛線從上而下，經過底部邊界的中心（圖 3）。生命線名字放置在方格里。



UML 的生命線命名標準按照以下格式: 實體名:類名

生命線名稱帶下劃線。當使用下劃線時，意味着序列圖中的生命線表明一個類的特定實體，不是特定種類的實體（例如，角色）。序列圖的實例名稱有下劃線，而角色名稱沒有。

一個生命線能用來表現一個匿名的或未命名的實體。當在一個序列圖上，爲一個未命名的實例建模時，生命線的名字採用和一個命名實例相同的模式；可是生命線名字的位置留下空白，而不是提供一個例圖名字。

2.消息體：

爲了顯示一個對象（例如，生命線）傳遞一個消息給另一個對象，你畫一條線指向接收對象，包括一個實心箭頭（若是是一個同步調用操做）或一個棍形箭頭（若是是一個異步訊號）。消息/方法名字放置在帶箭頭的線上面。正在被傳遞給接收對象的消息，表示接收對象的類實現的一個操做/方法。



返回消息是可選擇的；一個返回消息畫做一個帶開放箭頭的虛線，向後指向來源的生命線，在這條虛線上面，你放置操做的返回值。爲了要畫一個調用自己的對象，如你平時所做的，畫一條消息，可是不是鏈接它到另外的一個對象，而是你把消息鏈接回對象自己。

3、UML中的約束：




約束的符號很簡單；格式是: 【Boolean Test】

4、UML中的新元素－組合碎片（變體方案、選擇項、循環）：

一個組合碎片用來把一套消息組合在一塊兒，在一個序列圖中顯示條件分支。

1.變體：

變體用來指明在兩個或更多的消息序列之間的、互斥的選擇。一個變體的組合碎片元件使用框架來畫。單詞「alt」放置在框架的namebox裏。而後較大的長方形分爲 UML 2 所稱的操做元。 操做元被虛線分開。每一個操做元有一個約束進行測試，而這個約束被放置在生命線頂端的操做元的左上部。 若是操做元的約束等於「true」，而後那個操做元是要執行的操做元。

圖 8做爲一個變體的組合碎片如何閱讀的例子，顯示序列從頂部開始，即bank對象獲取支票金額和賬戶結餘。此時，序列圖中的變體組合碎片接管。由於約束「[balance >= amount]」，若是餘額超過或等於金額，而後順序進行bank對象傳遞 addDebitTransaction 和 storePhotoOfCheck 消息給account對象。然而，若是餘額不是超過或等於金額，而後順序的過程就是bank傳遞addInsuffientFundFee 和 noteReturnedCheck 消息給account對象，returnCheck 消息給它自身。由於「else」約束，當餘額不大於或者等於金額時，第二個序列被調用。在變體的組合碎片中，不須要「else」約束；而若是一個操做元，在它上面沒有一個明確的約束，那麼將假定「else」約束。

2.選擇項：

一個選擇項用來爲簡單的「if then」表達式建模。（例如，若是架上的圈餅少於五個，那麼另外作兩打圈餅）。

選擇項組合碎片符號與變體組合碎片相似，除了它只有一個操做元而且永不能有「else」約束之外（它就是如此，沒有理由）。要畫選擇項組合，你畫一個框架。文字「opt」是被放置在框架的 namebox 裏的文本，在框架的內容區，選擇項的約束被放置在生命線頂端上的左上角。 而後選擇項的消息序列被放在框架的內容區的其他位置內。



注意：變體用於爲if then else建模，選擇項用於爲if then建模，由於只有一個分支，因此不能出現[else]

3.循環：

循環組合碎片表面很是相似選擇項組合碎片。你畫一個框架，在框架的 namebox 中放置文本「loop」。在框架的內容區中，一個生命線的頂部，循環約束被放置在左上角。而後循環的消息序列被放在框架內容區的其他部分中。在一個循環中，除了標準的布爾測試外，一個約束能測試二個特定的條件式。特定的約束條件式是寫做「minint = [the number]」（例如，「minint = 1」）的最小循環次數，或寫做「maxint = [the number]」（例如，「maxint = 5」）的最大循環次數。經過最小循環檢驗，循環必須運行至少指定次數，而循環執行次數不能達到約束指定的最大循環次數。

如下是：用例圖：

用例圖主要用來圖示化系統的主事件流程，它主要用來描述客戶的需求，即用戶但願系統具有的完成必定功能的動做，通俗地理解用例就是軟件的功能模塊，因此是設計系統分析階段的起點，設計人員根據客戶的需求來建立和解釋用例圖，用來描述軟件應具有哪些功能模塊以及這些模塊之間的調用關係，用例圖包含了用例和參與者，用例之間用關聯來鏈接以求把系統的整個結構和功能反映給非技術人員（一般是軟件的用戶），對應的是軟件的結構和功能分解。


用例是從系統外部可見的行爲，是系統爲某一個或幾個參與者（Actor）提供的一段完整的服務。從原則上來說，用例之間都是獨立、並列的，它們之間並不存在着包含從屬關係。可是爲了體現一些用例之間的業務關係，提升可維護性和一致性，用例之間能夠抽象出包含(include)、擴展(extend)和泛(generalization)幾種關係。

共性：都是從現有的用例中抽取出公共的那部分信息，做爲一個單獨的用例，而後通後過不一樣的方法來重用這個公共的用例，以減小模型維護的工做量。 

一、包含(include)

 

    包含關係：使用包含（Inclusion）用例來封裝一組跨越多個用例的類似動做（行爲片段），以便多個基（Base）用例複用。基用例控制與包含用例的關係，以及被包含用例的事件流是否會插入到基用例的事件流中。基用例能夠依賴包含用例執行的結果，可是雙方都不能訪問對方的屬性。 

   包含關係對典型的應用就是複用，也就是定義中說的情景。可是有時當某用例的事件流過於複雜時，爲了簡化用例的描述，咱們也能夠把某一段事件流抽象成爲一個被包含的用例；相反，用例劃分太細時，也能夠抽象出一個基用例，來包含這些細顆粒的用例。這種狀況相似於在過程設計語言中，將程序的某一段算法封裝成一個子過程，而後再從主程序中調用這一子過程。

   例如：業務中，老是存在着維護某某信息的功能，若是將它做爲一個用例，那新建、編輯以及修改都要在用例詳述中描述，過於複雜；若是分紅新建用例、編輯用例和刪除用例，則劃分太細。這時包含關係能夠用來理清關係。

二、擴展(extend)

擴展關係：將基用例中一段相對獨立而且可選的動做，用擴展（Extension）用例加以封裝，再讓它從基用例中聲明的擴展點（Extension Point）上進行擴展，從而使基用例行爲更簡練和目標更集中。擴展用例爲基用例添加新的行爲。擴展用例能夠訪問基用例的屬性，所以它能根據基用例中擴展點的當前狀態來判斷是否執行本身。可是擴展用例對基用例不可見。

對於一個擴展用例，能夠在基用例上有幾個擴展點。   

例如，系統中容許用戶對查詢的結果進行導出、打印。對於查詢而言，能不能導出、打印查詢都是同樣的，導出、打印是不可見的。導入、打印和查詢相對獨立，並且爲查詢添加了新行爲。所以能夠採用擴展關係來描述：





四、泛化(generalization)

 

泛化關係：子用例和父用例類似，但表現出更特別的行爲；子用例將繼承父用例的全部結構、行爲和關係。子用例可使用父用例的一段行爲，也能夠重載它。父用例一般是抽象的。在實際應用中不多使用泛化關係，子用例中的特殊行爲均可以做爲父用例中的備選流存在。

例如，業務中可能存在許多須要部門領導審批的事情，可是領導審批的流程是很類似的，這時能夠作成泛化關係表示： 




    上面是我參考的一篇文章，以爲將三種關係的區別講得很清晰，在此基礎上結合本身的系統，對項目(在線購物系統)的用例作了總體的描繪。

    *****************************************************************

    (1)系統總體用例圖

    


   
    (商品用例圖)

   
   
    
   
   
   （購買信息用例）
  
   

   
    (用戶資料用例)


   

   
   
按照先總體用例，後子系統用例來進行描繪的，歡迎你們提出好的建議!

轉：UML中擴展和泛化的區別 

         泛化表示相似於OO術語「繼承」或「多態」。UML中的Use Case泛化過程是將不一樣Use Case之間的可合併部分抽象成獨立的父Use Case，並將不可合併部分單獨成各自的子Use Case；包含以及擴展過程與泛化過程相似，但三者對用例關係的優化側重點是不一樣的。以下：
          ●泛化側重表示子用例間的互斥性；
          ●包含側重表示被包含用例對Actor提供服務的間接性；
          ●擴展側重表示擴展用例的觸發不定性；詳述以下：

        既然用例是系統提供服務的UML表述，那麼服務這個過程在全部用例場景中是必然發生的，但發生按照發生條件可分爲以下兩種狀況：
         ⒈無條件發生：確定發生的；
         ⒉有條件發生：未必發生，發生與否取決於系統狀態；

         所以，針對用例的三種關係結合系統狀態考慮，泛化與包含用例屬於無條件發生的用例，而擴展屬於有條件發生的用例。進一步，用例的存在是爲Actor提供服務，但用例提供服務的方式可分爲間接和直接兩種，依據於此，泛化中的子用例提供的是直接服務，而包含中的被包含用例提供的是間接服務。一樣，擴展用例提供的也是直接服務，但擴展用例的發生是有條件的。

         另一點須要說起的是：泛化中的子用例和擴展中的擴展用例都可以做爲基本用例事件的備選擇流而存在。

 

如下是：活動圖

UML 活動圖記錄了單個操做或方法的邏輯，單個用戶案例，或者單個業務流程的邏輯。在不少方面，活動圖是結構化開發中流程圖和數據流程圖 (DFD) 的面向對象等同體,要建立一個 UML 活動圖，您須要反覆執行下列步驟。

第一步，定義活動圖的範圍首先應該定義您要對什麼建模。單個用戶案例力？一個用戶案例的一部分？一個包含多個用戶案例的商務流程？一個類的單個方法？一旦您定義了您所做圖的範圍，您應該在其頂部，用一個標註添加標籤，指明該圖的標題和惟一的標示符。您有可能也想要包括該圖的時間甚至做者名。

     第二步，添加起始和結束點每一個活動圖有一個起始點和結束點，所以您也要立刻添加它們。在 《UML 精粹》(UML Distilled) (參見參考資料)，Fowler 和 Scott 認爲結束點是可選的。有時候一個活動只是一個簡單的結束，若是是這種狀況，指明其惟一的轉變是到一個結束點也是無害的。這樣，當其餘人閱讀您的圖時，他或她知道您已經考慮瞭如何退出這些活動。

第三步，添加活動若是您正對一個用戶案例建模，對每一個角色(actor)所發出的主要步驟引入一個活動(該活動可能包括起始步驟，加上對起始步驟系統響應的任何步驟)。若是您正對一個高層的商務流程建模，對每一個主要流程引入一個活動，一般爲一個用戶案例或用戶案例包。最後，若是您正對一個方法建模，那麼對此引入一個活動是很常見的。 

第四步，添加活動間的轉變個人風格老是應該退出一個活動，即便它是轉變到一個結束點。一旦一個活動有多個轉變時，您必需對每一個轉變加以相應標示。

第五步，添加決策點有時候，您所建模的邏輯須要作出一個決策。有多是須要檢查某些事務或比較某些事務。要注意的是，使用決策點是可選的。

第六步，找出可並行活動之處當兩個活動間沒有直接的聯繫，並且它們都必需在第三個活動開始前結束，那它們是能夠並行運行的。

 

    下面的活動圖描述了大學新生第一次將如何辦理入學的商業邏輯。

• 實心圓表示活動圖的起點，其實是一個佔位符，帶邊框的實心圓表示終點。
• 圓角矩形表示執行的過程或活動。在該圖中，雖然您會注意到「登記研習班」用例將屢次調用「登記研習班」活動，但這些活動卻至關緊密地映射到用例。活動能夠細緻得多，特別在選擇記錄方法邏輯，而不是高級商業過程時。
• 菱形表示斷定點，雖然在此示例中斷定點只有兩種可能結果；但即便有更多可能結果，它也一樣容易。
• 箭頭表示活動之間的轉換，各類活動之間的流動次序。
• 箭頭上的文字表示繼續轉換所必須知足的條件，老是使用格式「[條件]」來描述。我猜測，在 UML 的未來版本中，咱們將會看到使用 UML 約束表示法（如「{condition}」）記錄的條件。
• 粗線條表示可能會並行進行的過程的開始和結束；在大學裏成功入學後，必須參加指定的概況介紹，還要至少登記一個研習班並交付一部分的學費。

 

退出活動可能有幾種方法，如您看到的「填寫入學表」活動的那樣。若是正確填寫了表格，那麼能夠繼續進行大學的入學手續。可是，若是表格不正確，那麼必須得到幫助（可能從註冊員得到幫助）以正確填寫它們。

圖 1. 第一次入學的 UML 活動圖

這個活動圖很是有趣，由於它省掉了圖 2 中標識的幾個用例的邏輯。用例模型沒有很好地表達處理的順序是件好事。例如，雖然圖 2 中顯示的用例圖爲您清楚地描述了該系統所執行的功能類型，可是它沒有明確地表達這些用例可能發生的順序。可是，圖 1 的活動圖作到了這一點。總之，不一樣模型的優缺點各有不一樣。

中標識的幾個用例的邏輯。用例模型沒有很好地表達處理的順序是件好事。例如，雖然 中顯示的用例圖爲您清楚地描述了該系統所執行的功能類型，可是它沒有明確地表達這些用例可能發生的順序。可是， 的活動圖作到了這一點。總之，不一樣模型的優缺點各有不一樣。

圖 2. 大學的用例圖

 泳道 
將模型中的活動按照職責組織起來一般頗有用。例如，能夠將一個商業組織處理的全部活動組織起來。這種分配能夠經過將活動組織成用線分開的不一樣區域來表示。因爲它們的外觀的緣故，這些區域被稱做泳道。 圖 7–2 表示了泳道。

圖 7–2 泳道和對象流

· 2. 對象流 

活動圖能表示對象的值流和控制流。對象流狀態表示活動中輸入或輸出的對象。對輸出值而言，虛線箭頭從活動指向對象流狀態。對輸入值而言，虛線箭頭從對象流狀態指向活動。若是活動有多個輸出值或後繼控制流，那麼箭頭背向分叉符號。一樣，多輸入箭頭指向結合符號。

圖 7–2 表示一個活動和對象流狀態都被分配到泳道中的活動圖。

· 活動和其餘圖

活動圖沒有表示出計算處理過程當中的所有細節內容。它們表示了活動進行的流程但沒表示出執行活動的對象。活動圖是設計工做的起點。爲了完成設計，每一個活動必須擴展細分紅一個或多個操做，每一個操做被指定到具體類。這種分配的結果引出了用於實現活動圖的對合協的設計工做。

如下是數據流圖DFD：

研究了一下DFD:

    結構化分析是面向數據流開展需求分析工做的一種有效方法。通常採用自頂向下，逐層分解的演義分析法來定義系統的需求，即先把分析對象抽象成一個系統，而後自頂向下的逐層分解，將複雜的系統分解成簡單的、可以清楚地被理解和表達的若干個子系統，如圖1（逐層分解的數據流程圖）所示。這樣就能夠分別理解系統的每一個細節、先後順序和相互關係，找出各部分之間的數據接口。在結構化分析方法所採用的工具備數據流程圖（DFD）、數據字典（DD）、結構化語言、斷定樹、斷定表等。

結構化分析的核心是數據流程圖，數據流程圖是以圖形的方式表達在問題中信息的變換和傳遞過程。它把系統當作是由數據流聯繫的各類概念的組合，用分解及抽象手段來控制需求分析的複雜性，採用分層的數據流程圖來表示一個複雜的系統。

     數據流圖：簡稱DFD，就是採用圖形方式來表達系統的邏輯功能、數據在系統內部的邏輯流向和邏輯變換過程，是結構化系統分析方法的主要表達工具及用於表示軟件模型的一種圖示方法。

基於計算機的信息處理系統由數據流和一系列的加工構成，這些加工將輸入數據流加工爲輸出數據流

數據流圖描述數據流和加工

數據流圖用圖形符號表示數據流、加工、數據源及外部實體

數據流圖具備層次結構，支持問題分解、逐步求精的分析方法

它是數據驅動的數據流圖既能夠表示基於計算機的系統，也能夠表示軟件

數據流圖能夠用來抽象地表示系統或軟件。它從信息傳遞和加工的角度，以圖形的方式刻畫數據流從輸入到輸出的移動變換過程，同時能夠按自頂向下、逐步分解的方法表示內容不斷增長的數據流和功能細節。所以，數據流圖既提供了功能建模的機制，也提供了信息流建模的機制，從而能夠創建起系統或軟件的功能模型。

數據流圖的基本符號的意思： 

1.矩形表示數據的外部實體；

2.圓角的矩形表示變換數據的處理邏輯； 

3.少右面的邊矩形表示數據的存儲； 

4.箭頭表示數據流。

數據流程圖中有如下幾種主要元素：
→：數據流。數據流是數據在系統內傳播的路徑，所以由一組成分固定的數據組成。如訂票單由旅客姓名、年齡、單位、身份證號、日期、目的地等數據項組成。因爲數據流是流動中的數據，因此必須有流向，除了與數據存儲之間的數據流不用命名外，數據流應該用名詞或名詞短語命名。