UML中資料流圖，使用案例圖，類圖，對象圖，角色圖，活動圖表，順序圖表詳細講述儲存供參考

類圖，對象圖，角色圖：

一、UML中基本的圖範疇：

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

 

二、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..*的多重性描述；一個僱員可能不受任何其他僱員管理。

三、UML中的對象圖：

執行個體的記號和類一樣，但是取代頂端地區中僅有的類名，它的名字是經過拼接的:

Instance Name : Class Name 如 Donald : Person

因為顯示執行個體的目的是顯示值得注意的或相關的資訊，沒必要在你的模型中包含整個實體屬性及操作。相反地，僅僅顯示感興趣的屬性及其值是完全恰當的。 

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

四、UML中的角色圖：

建模類的執行個體有時比期望的更為詳細。有時，你可能僅僅想要在一個較多的一般層次做類別關係的模型。在這種情況下，你應該使用 角色 記號。角色記號類似於執行個體記號。為了建立類的角色模型，你畫一個方格，並在內部放置類的角色名稱及類名，作為實體記號，但是在這情況你不能加底線。

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

以下是：順序圖表

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

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

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

Java應用程式由許多類所構成，是Java實現物件導向應用程式的核心。類圖主要描述Java應用程式中各種類之間的相互靜態關係，如類的繼承、抽象、介面以及各種關聯。要利用UML設計Java應用程式，僅僅使用類圖來描述這些靜態關係，利用視覺化檢視，要實現Java應用程式的代碼自動產生，是遠遠不夠的。我們還必須描述各種類相互之間的協作關係、動態關係，如時間序列上的互動行為。其中UML順序圖表就是用來描述類與類之間的方法調用過程（或訊息發送）是如何?的。

一、UML中的新元素－架構：

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

除了提供一個圖形化邊框之外，用於圖中的架構元件也有描述互動的重要的功能, 例如順序圖表。在順序圖表上一個序列接收和發送訊息（又稱互動），能通過串連訊息和架構元件邊界，建立模型（ 2 所見到）。

對於順序圖表，圖的標籤由文字“sd”開始。當使用一個架構元件封閉一個圖時，圖的標籤需要按照以下的格式：圖類型 圖名稱。

UML 規範給圖類型提供特定的文本值。（舉例來說，sd代表順序圖表，activity代表活動圖表，use case代表使用案例圖）。

二、UML中的順序圖表：

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

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

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

順序圖表的主要目的是定義事件序列，產生一些希望的輸出。重點不是訊息本身，而是訊息產生的順序；不過，大多數順序圖表會表示一個系統的對象之間傳遞的什麼訊息，以及它們發生的順序。圖按照水平和垂直的維度傳遞資訊：垂直維度從上而下表示訊息/調用發生的時間序列，而且水平維度從左至右表示訊息發送到的對象執行個體。

1.生命線：

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

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

生命線名稱帶底線。當使用底線時，意味著順序圖表中的生命線代表一個類的特定實體，不是特定種類的實體（例如，角色）。順序圖表的執行個體名稱有底線，而角色名稱沒有。

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

2.訊息體：

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

返回訊息是可選擇的；一個返回訊息畫作一個帶開放箭頭的虛線，向後指向來源的生命線，在這條虛線上面，你放置操作的傳回值。為了要畫一個調用本身的對象，如你平時所作的，畫一條訊息，但是不是串連它到另外的一個對象，而是你把訊息串連回對象本身。

三、UML中的約束：

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

四、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)幾種關係。

共性：都是從現有的用例中抽取出公用的那部分資訊，作為一個單獨的用例，然後通後過不同的方法來重用這個公用的用例，以減少模型維護的工作量。 

1、包含(include)

 

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

   內含項目關聯性對典型的應用就是複用，也就是定義中說的情景。但是有時當某用例的事件流過於複雜時，為了簡化用例的描述，我們也可以把某一段事件流抽象成為一個被包含的用例；相反，用例劃分太細時，也可以抽象出一個基用例，來包含這些細顆粒的用例。這種情況類似於在過程設計語言中，將程式的某一段演算法封裝成一個子過程，然後再從主程式中調用這一子過程。　

   例如：業務中，總是存在著維護某某資訊的功能，如果將它作為一個用例，那建立、編輯以及修改都要在用例詳述中描述，過於複雜；如果分成建立用例、編輯用例和刪除用例，則劃分太細。這時內含項目關聯性可以用來理清關係。

2、擴充(extend)

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

對於一個擴充用例，可以在基用例上有幾個擴充點。   

例如，系統中允許使用者對查詢的結果進行匯出、列印。對於查詢而言，能不能匯出、列印查詢都是一樣的，匯出、列印是不可見的。匯入、列印和查詢相對獨立，而且為查詢添加了新行為。因此可以採用擴充關係來描述：

4、泛化(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.箭頭表示資料流。

　　資料流程圖中有以下幾種主要元素：
　　→：資料流。資料流是資料在系統內傳播的路徑，因此由一組成分固定的資料群組成。如訂票單由旅客姓名、年齡、單位、社會安全號碼、日期、目的地等資料項目組成。由於資料流是流動中的資料，所以必須有流向，除了與資料存放區之間的資料流不用命名外，資料流應該用名詞或名詞短語命名。 
　　□：資料來源（終點）。代表系統之外的實體，可以是人、物或其他軟體系統。
　　○：對資料的加工（處理）。加工是對資料進行處理的單元，它接收一定的資料輸入，對其進行處理，併產生輸出。
　　〓：資料存放區。表示資訊的靜態儲存，可以代表檔案、檔案的一部分、資料庫的元素等。