UML中數(shù)據(jù)流圖介紹

1、 . ·單向關聯(lián)在一個單向關聯(lián)中，兩個類是相關的，但是只有一個類知道這種聯(lián)系的存在。一個單向的關聯(lián)，表示為一條帶有指向已知類的開放箭頭（不關閉的箭頭或三角形，用于標志繼承）的實線。如同標準關聯(lián)，單向關聯(lián)包括一個角色名和一個多重值描述，但是與標準的雙向關聯(lián)不同的時，單向關聯(lián)只包含已知類的角色名和多重值描述。簡單的說就是OverdrawAccountReport中包含了BankAccount屬性，而BankAccount中不需要包含OverdrawnAccountsReport對象6.聚合的表示：聚合是一種特別類型的關聯(lián)，用于描述“總體到局部”的關系。在基本的聚合關系中， 部分類 的生命

2、周期獨立于 整體類 的生命周期。舉例來說，我們可以想象，車 是一個整體實體，而 車輪 輪胎是整輛車的一部分。輪胎可以在安置到車時的前幾個星期被制造，并放置于倉庫中。在這個實例中，Wheel類實例清楚地獨立于Car類實例而存在。然而，有些情況下， 部分 類的生命周期并 不 獨立于 整體 類的生命周期 - 這稱為合成聚合。舉例來說，考慮公司與部門的關系。 公司和部門 都建模成類，在公司存在之前，部門不能存在。這里Department類的實例依賴于Company類的實例而存在。讓我們更進一步探討基本聚合和組合聚合。注意：聚合與普通的關聯(lián)的區(qū)別在于：普通的關聯(lián)可能只是一個簡單的“包含、引用”關系，關聯(lián)

3、和被關聯(lián)類之間在邏輯概念上不一定有緊密的聯(lián)系，而聚合則不同，它表示的是一種在關系緊密，相互依存，相互包含的概念，其中的一部分是構成另外一部分的不可或缺的成分。·基本聚合有聚合關系的關聯(lián)指出，某個類是另外某個類的一部分。在一個聚合關系中，子類實例可以比父類存在更長的時間。為了表現(xiàn)一個聚合關系，你畫一條從父類到部分類的實線，并在父類的關聯(lián)末端畫一個未填充棱形。圖中清楚的表明了類Car對象包含了另一類Wheel的4個實例，這兩者在概念上是密不可分的，其中的一個類是另一個類的構成成分。菱形表示“包含”，箭頭表示被包含的對象，數(shù)字4表示包含的數(shù)目。·組合聚合 組合聚合關系是聚合關系的

4、另一種形式，但是子類實例的生命周期依賴于父類實例的生命周期。注意:組合關系如聚合關系一樣繪制，不過這次菱形是被填充的。7.反射關聯(lián)的表示：類也可以使用反射關聯(lián)與它本身相關聯(lián)。起先，這可能沒有意義，但是記住，類是抽象的。當一個類關聯(lián)到它本身時，這并不意味著類的實例與它本身相關，而是類的一個實例與類的另一個實例相關。圖描繪的關系說明一個Employee實例可能是另外一個Employee實例的經(jīng)理。然而，因為“manages”的關系角色有 0.*的多重性描述；一個雇員可能不受任何其他雇員管理。三、UML中的對象圖：實例的記號和類一樣，但是取代頂端區(qū)域中僅有的類名，它的名字是經(jīng)過拼接的:Instanc

5、e Name : Class Name 如 Donald : Person因為顯示實例的目的是顯示值得注意的或相關的信息，沒必要在你的模型中包含整個實體屬性與操作。相反地，僅僅顯示感興趣的屬性與其值是完全恰當?shù)摹?#160;UML 2 也允許在實體層的關系/關聯(lián)建模。繪制關聯(lián)與一般的類關系的規(guī)則一樣，除了在建模關聯(lián)時有一個附加的要求。附加的限制是，關聯(lián)關系必須與類圖的關系相一致，而且關聯(lián)的角色名字也必須與類圖相一致。四、UML中的角色圖：建模類的實例有時比期望的更為詳細。有時，你可能僅僅想要在一個較多的一般層次做類關系的模型。在這種情況下，你應該使用 角色 記號。角色記號類似于實例記號。為了建

6、立類的角色模型，你畫一個方格，并在部放置類的角色名與類名，作為實體記號，但是在這情況你不能加下劃線。注意：角色圖和對象圖的一個明顯區(qū)別就是：對象圖每個對象名稱下面都加了下劃線，而角色圖沒有以下是：序列圖序列圖主要用于按照交互發(fā)生的一系列順序，顯示對象之間的這些交互。很象類圖，開發(fā)者一般認為序列圖只對他們有意義。然而，一個組織的業(yè)務人員會發(fā)現(xiàn)，序列圖顯示不同的業(yè)務對象如何交互，對于交流當前業(yè)務如何進行很有用。除記錄組織的當前事件外，一個業(yè)務級的序列圖能被當作一個需求文件使用，為實現(xiàn)一個未來系統(tǒng)傳遞需求。在項目的需求階段，分析師能通過提供一個更加正式層次的表達，把用例帶入下一層次。那種情況下，用例

7、常常被細化為一個或者更多的序列圖。 組織的技術人員能發(fā)現(xiàn)，序列圖在記錄一個未來系統(tǒng)的行為應該如何表現(xiàn)中，非常有用。在設計階段，架構師和開發(fā)者能使用圖，挖掘出系統(tǒng)對象間的交互，這樣充實整個系統(tǒng)設計。 序列圖的主要用途之一，是把用例表達的需求，轉化為進一步、更加正式層次的精細表達。用例常常被細化為一個或者更多的序列圖。序列圖除了在設計新系統(tǒng)方面的用途外，它們還能用來記錄一個存在系統(tǒng)（稱它為“遺產(chǎn)”）的對象現(xiàn)在如何交互。當把這個系統(tǒng)移交給另一個人或組織時，這個文檔很有用。Java應用程序由許多類所構成，是Java實現(xiàn)面向?qū)ο髴贸绦虻暮诵摹ｎ悎D主要描述Java應用程序中各種類之間的相互靜態(tài)

8、關系，如類的繼承、抽象、接口以與各種關聯(lián)。要利用UML設計Java應用程序，僅僅使用類圖來描述這些靜態(tài)關系，利用可視化工具，要實現(xiàn)Java應用程序的代碼自動生成，是遠遠不夠的。我們還必須描述各種類相互之間的協(xié)作關系、動態(tài)關系，如時間序列上的交互行為。其中UML序列圖就是用來描述類與類之間的方法調(diào)用過程（或消息發(fā)送）是如何實現(xiàn)的。一、UML中的新元素框架：在 UML 2中，框架元件用于作為許多其他的圖元件的一個基礎，但是大多數(shù)人第一次接觸框架元件的情況，是作為圖的圖形化邊界。當為圖提供圖形化邊界時，一個框架元件為圖的標簽提供一致的位置。在 UML 圖中框架元件是可選擇的。除了提供一個圖形化邊框之

9、外，用于圖中的框架元件也有描述交互的重要的功能, 例如序列圖。在序列圖上一個序列接收和發(fā)送消息（又稱交互），能通過連接消息和框架元件邊界，建立模型（如圖 2 所見到）。對于序列圖，圖的標簽由文字“sd”開始。當使用一個框架元件封閉一個圖時，圖的標簽需要按照以下的格式：圖類型 圖名稱。UML 規(guī)給圖類型提供特定的文本值。（舉例來說，sd代表序列圖，activity代表活動圖，use case代表用例圖）。二、UML中的序列圖：序列圖主要用于按照交互發(fā)生的一系列順序，顯示對象之間的這些交互。在項目的需求階段，分析師能通過提供一個更加正式層次的表達，把用例帶入下一層次。那種情況下，用例常常被細化為一

10、個或者更多的序列圖。序列圖的主要用途之一，是把用例表達的需求，轉化為進一步、更加正式層次的精細表達。用例常常被細化為一個或者更多的序列圖。序列圖除了在設計新系統(tǒng)方面的用途外，它們還能用來記錄一個存在系統(tǒng)（稱它為“遺產(chǎn)”）的對象現(xiàn)在如何交互。序列圖的主要目的是定義事件序列，產(chǎn)生一些希望的輸出。重點不是消息本身，而是消息產(chǎn)生的順序；不過，大多數(shù)序列圖會表示一個系統(tǒng)的對象之間傳遞的什么消息，以與它們發(fā)生的順序。圖按照水平和垂直的維度傳遞信息：垂直維度從上而下表示消息/調(diào)用發(fā)生的時間序列，而且水平維度從左到右表示消息發(fā)送到的對象實例。1.生命線：生命線畫作一個方格，一條虛線從上而下，通過底部邊界的中心

11、（圖 3）。生命線名字放置在方格里。UML 的生命線命名標準按照如下格式: 實體名:類名生命線名稱帶下劃線。當使用下劃線時，意味著序列圖中的生命線代表一個類的特定實體，不是特定種類的實體（例如，角色）。序列圖的實例名稱有下劃線，而角色名稱沒有。一個生命線能用來表現(xiàn)一個匿名的或未命名的實體。當在一個序列圖上，為一個未命名的實例建模時，生命線的名字采用和一個命名實例一樣的模式；但是生命線名字的位置留下空白，而不是提供一個例圖名字。 2.消息體：為了顯示一個對象（例如，生命線）傳遞一個消息給另外一個對象，你畫一條線指向接收對象，包括一個實心箭頭（如果是一個同步調(diào)用操作）或一個棍形箭頭（如果

12、是一個異步訊號）。消息/方法名字放置在帶箭頭的線上面。正在被傳遞給接收對象的消息，表示接收對象的類實現(xiàn)的一個操作/方法。返回消息是可選擇的；一個返回消息畫作一個帶開放箭頭的虛線，向后指向來源的生命線，在這條虛線上面，你放置操作的返回值。為了要畫一個調(diào)用本身的對象，如你平時所作的，畫一條消息，但是不是連接它到另外的一個對象，而是你把消息連接回對象本身。 三、UML中的約束：約束的符號很簡單；格式是: Boolean Test四、UML中的新元素組合碎片（變體方案、選擇項、循環(huán)）：一個組合碎片用來把一套消息組合在一起，在一個序列圖中顯示條件分支。1.變體：變體用來指明在兩個或更多的消息序列之間的、

13、互斥的選擇。一個變體的組合碎片元件使用框架來畫。單詞“alt”放置在框架的namebox里。然后較大的長方形分為 UML 2 所稱的操作元。操作元被虛線分開。每個操作元有一個約束進行測試，而這個約束被放置在生命線頂端的操作元的左上部。如果操作元的約束等于“true”，然后那個操作元是要執(zhí)行的操作元。圖 8作為一個變體的組合碎片如何閱讀的例子，顯示序列從頂部開始，即bank對象獲取支票金額和結余。此時，序列圖中的變體組合碎片接管。因為約束“balance >= amount”，如果余額超過或等于金額，然后順序進行bank對象傳遞 addDebitTransaction 和 storePho

14、toOfCheck 消息給account對象。然而，如果余額不是超過或等于金額，然后順序的過程就是bank傳遞addInsuffientFundFee 和 noteReturnedCheck 消息給account對象，returnCheck 消息給它自身。因為“else”約束，當余額不大于或者等于金額時，第二個序列被調(diào)用。在變體的組合碎片中，不需要“else”約束；而如果一個操作元，在它上面沒有一個明確的約束，那么將假定“else”約束。2.選擇項：一個選擇項用來為簡單的“if then”表達式建模。（例如，如果架上的圈餅少于五個，那么另外做兩打圈餅）。選擇項組合碎片符號與變體組合碎片類似，除

15、了它只有一個操作元并且永不能有“else”約束以外（它就是如此，沒有理由）。要畫選擇項組合，你畫一個框架。文字“opt”是被放置在框架的 namebox 里的文本，在框架的容區(qū)，選擇項的約束被放置在生命線頂端上的左上角。 然后選擇項的消息序列被放在框架的容區(qū)的其余位置。注意：變體用于為if then else建模，選擇項用于為if then建模，因為只有一個分支，所以不能出現(xiàn)else 以下是：用例圖：用例圖主要用來圖示化系統(tǒng)的主事件流程，它主要用來描述客戶的需求，即用戶希望系統(tǒng)具備的完成一定功能的動作，通俗地理解用例就是軟件的功能模塊，所以是設計系統(tǒng)分析階段的起點，設計人員根據(jù)客戶的

16、需求來創(chuàng)建和解釋用例圖，用來描述軟件應具備哪些功能模塊以與這些模塊之間的調(diào)用關系，用例圖包含了用例和參與者，用例之間用關聯(lián)來連接以求把系統(tǒng)的整個結構和功能反映給非技術人員（通常是軟件的用戶），對應的是軟件的結構和功能分解。用例是從系統(tǒng)外部可見的行為，是系統(tǒng)為某一個或幾個參與者（Actor）提供的一段完整的服務。從原則上來講，用例之間都是獨立、并列的，它們之間并不存在著包含從屬關系。但是為了體現(xiàn)一些用例之間的業(yè)務關系，提高可維護性和一致性，用例之間可以抽象出包含(include)、擴展(extend)和泛(generalization)幾種關系。共性：都是從現(xiàn)有的用例中抽取出公共的那部分信息，作

17、為一個單獨的用例，然后通后過不同的方法來重用這個公共的用例，以減少模型維護的工作量。1、包含(include)     包含關系：使用包含（Inclusion）用例來封裝一組跨越多個用例的相似動作（行為片斷），以便多個基（Base）用例復用?；美刂婆c包含用例的關系，以與被包含用例的事件流是否會插入到基用例的事件流中?；美梢砸蕾嚢美龍?zhí)行的結果，但是雙方都不能訪問對方的屬性。    包含關系對典型的應用就是復用，也就是定義中說的情景。但是有時當某用例的事件流過于復雜時，為了簡化用例的描述，我們也可以把某一段事件流抽象成為一個被

18、包含的用例；相反，用例劃分太細時，也可以抽象出一個基用例，來包含這些細顆粒的用例。這種情況類似于在過程設計語言中，將程序的某一段算法封裝成一個子過程，然后再從主程序中調(diào)用這一子過程。   例如：業(yè)務中，總是存在著維護某某信息的功能，如果將它作為一個用例，那新建、編輯以與修改都要在用例詳述中描述，過于復雜；如果分成新建用例、編輯用例和刪除用例，則劃分太細。這時包含關系可以用來理清關系。2、擴展(extend)擴展關系：將基用例中一段相對獨立并且可選的動作，用擴展（Extension）用例加以封裝，再讓它從基用例中聲明的擴展點（Extension Point）上進行擴展，從而使

19、基用例行為更簡練和目標更集中。擴展用例為基用例添加新的行為。擴展用例可以訪問基用例的屬性，因此它能根據(jù)基用例中擴展點的當前狀態(tài)來判斷是否執(zhí)行自己。但是擴展用例對基用例不可見。對于一個擴展用例，可以在基用例上有幾個擴展點。   例如，系統(tǒng)中允許用戶對查詢的結果進行導出、打印。對于查詢而言，能不能導出、打印查詢都是一樣的，導出、打印是不可見的。導入、打印和查詢相對獨立，而且為查詢添加了新行為。因此可以采用擴展關系來描述：4、泛化(generalization) 泛化關系：子用例和父用例相似，但表現(xiàn)出更特別的行為；子用例將繼承父用例的所有結構、行為和關系。子用

20、例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。在實際應用中很少使用泛化關系，子用例中的特殊行為都可以作為父用例中的備選流存在。例如，業(yè)務中可能存在許多需要部門領導審批的事情，但是領導審批的流程是很相似的，這時可以做成泛化關系表示：     上面是我參考的一篇文章，覺得將三種關系的區(qū)別講得很清晰，在此基礎上結合自己的系統(tǒng)，對項目(在線購物系統(tǒng))的用例做了整體的描繪。    *    (1)系統(tǒng)整體用例圖       

21、60;   (商品用例圖)                   （購買信息用例）            (用戶資料用例)         按照先整體用例，后子系統(tǒng)用例來進行描繪的，歡迎大家提出好的建議

22、!轉：UML中擴展和泛化的區(qū)別          泛化表示類似于OO術語“繼承”或“多態(tài)”。UML中的Use Case泛化過程是將不同Use Case之間的可合并部分抽象成獨立的父Use Case，并將不可合并部分單獨成各自的子Use Case；包含以與擴展過程與泛化過程類似，但三者對用例關系的優(yōu)化側重點是不同的。如下：          泛化側重表示子用例間的互斥性；     

23、;     包含側重表示被包含用例對Actor提供服務的間接性；          擴展側重表示擴展用例的觸發(fā)不定性；詳述如下：        既然用例是系統(tǒng)提供服務的UML表述，那么服務這個過程在所有用例場景中是必然發(fā)生的，但發(fā)生按照發(fā)生條件可分為如下兩種情況：         無條件發(fā)生：肯定發(fā)生的； &

24、#160;       有條件發(fā)生：未必發(fā)生，發(fā)生與否取決于系統(tǒng)狀態(tài)；         因此，針對用例的三種關系結合系統(tǒng)狀態(tài)考慮，泛化與包含用例屬于無條件發(fā)生的用例，而擴展屬于有條件發(fā)生的用例。進一步，用例的存在是為Actor提供服務，但用例提供服務的方式可分為間接和直接兩種，依據(jù)于此，泛化中的子用例提供的是直接服務，而包含中的被包含用例提供的是間接服務。同樣，擴展用例提供的也是直接服務，但擴展用例的發(fā)生是有條件的。   &#

25、160;     另外一點需要提與的是：泛化中的子用例和擴展中的擴展用例均可以作為基本用例事件的備選擇流而存在。 以下是：活動圖UML 活動圖記錄了單個操作或方法的邏輯，單個用戶案例，或者單個業(yè)務流程的邏輯。在很多方面，活動圖是結構化開發(fā)中流程圖和數(shù)據(jù)流程圖 (DFD) 的面向?qū)ο蟮韧w,要創(chuàng)建一個 UML 活動圖，您需要反復執(zhí)行下列步驟。第一步，定義活動圖的圍首先應該定義您要對什么建模。單個用戶案例力？一個用戶案例的一部分？一個包含多個用戶案例的商務流程？一個類的單個方法？一旦您定義了您所作圖的圍，您應該在其頂部，用一個標注添加標簽，指明該圖

26、的標題和唯一的標示符。您有可能也想要包括該圖的時間甚至作者名。          第二步，添加起始和結束點每個活動圖有一個起始點和結束點，因此您也要馬上添加它們。在 UML 精粹(UML Distilled) (參見參考資料)，F(xiàn)owler 和 Scott 認為結束點是可選的。有時候一個活動只是一個簡單的結束，如果是這種情況，指明其唯一的轉變是到一個結束點也是無害的。這樣，當其他人閱讀您的圖時，他或她知道您已經(jīng)考慮了如何退出這些活動。第三步，添加活動如果您正對一個用戶案例建模，對每個角色(actor)所發(fā)出的主要步

27、驟引入一個活動(該活動可能包括起始步驟，加上對起始步驟系統(tǒng)響應的任何步驟)。如果您正對一個高層的商務流程建模，對每個主要流程引入一個活動，通常為一個用戶案例或用戶案例包。最后，如果您正對一個方法建模，那么對此引入一個活動是很常見的。 第四步，添加活動間的轉變我的風格總是應該退出一個活動，即使它是轉變到一個結束點。一旦一個活動有多個轉變時，您必需對每個轉變加以相應標示。第五步，添加決策點有時候，您所建模的邏輯需要做出一個決策。有可能是需要檢查某些事務或比較某些事務。要注意的是，使用決策點是可選的。第六步，找出可并行活動之處當兩個活動間沒有直接的聯(lián)系，而且它們都必需在第三個活動開始前結束，那它們是

28、可以并行運行的。     下面的活動圖描述了大學新生第一次將如何辦理入學的商業(yè)邏輯。 · 實心圓表示活動圖的起點，實際上是一個占位符，帶邊框的實心圓表示終點。 · 圓角矩形表示執(zhí)行的過程或活動。在該圖中，雖然您會注意到“登記研習班”用例將多次調(diào)用“登記研習班”活動，但這些活動卻相當緊密地映射到用例?；顒涌梢约氈碌枚?，特別在選擇記錄方法邏輯，而不是高級商業(yè)過程時。 · 菱形表示判定點，雖然在此示例中判定點只有兩種可能結果；但即使有更多可能結果，它也同樣容易。 · 箭頭表示活動之間的轉換，各種活動之間的流動次

29、序。 · 箭頭上的文字表示繼續(xù)轉換所必須滿足的條件，總是使用格式“條件”來描述。我猜想，在 UML 的將來版本中，我們將會看到使用 UML 約束表示法（如“condition”）記錄的條件。 · 粗線條表示可能會并行進行的過程的開始和結束；在大學里成功入學后，必須參加指定的概況介紹，還要至少登記一個研習班并交付一部分的學費。 退出活動可能有幾種方法，如您看到的“填寫入學表”活動的那樣。如果正確填寫了表格，那么可以繼續(xù)進行大學的入學手續(xù)。但是，如果表格不正確，那么必須獲得幫助（可能從注冊員獲得幫助）以正確填寫它們。圖 1. 第一次入學的 UML活動圖這個活動圖非常有趣，因為它

30、省掉了中標識的幾個用例的邏輯。用例模型沒有很好地表達處理的順序是件好事。例如，雖然 中顯示的用例圖為您清楚地描述了該系統(tǒng)所執(zhí)行的功能類型，但是它沒有明確地表達這些用例可能發(fā)生的順序。但是， 的活動圖做到了這一點。總之，不同模型的優(yōu)缺點各有不同。圖 2 中標識的幾個用例的邏輯。用例模型沒有很好地表達處理的順序是件好事。例如，雖然圖 2 中顯示的用例圖為您清楚地描述了該系統(tǒng)所執(zhí)行的功能類型，但是它沒有明確地表達這些用例可能發(fā)生的順序。但是，圖 1 的活動圖做到了這一點?？傊煌Ｐ偷膬?yōu)缺點各有不同。  圖 2. 大學的用例圖 泳道 將模型中的活動按照職責組織起來通常很有用。例

31、如，可以將一個商業(yè)組織處理的所有活動組織起來。這種分配可以通過將活動組織成用線分開的不同區(qū)域來表示。由于它們的外觀的緣故，這些區(qū)域被稱作泳道。 圖 72 表示了泳道。 圖 72 泳道和對象流 · 2. 對象流活動圖能表示對象的值流和控制流。對象流狀態(tài)表示活動中輸入或輸出的對象。對輸出值而言，虛線箭頭從活動指向?qū)ο罅鳡顟B(tài)。對輸入值而言，虛線箭頭從對象流狀態(tài)指向活動。如果活動有多個輸出值或后繼控制流，那么箭頭背向分叉符號。同樣，多輸入箭頭指向結合符號。 圖 72 表示一個活動和對象流狀態(tài)都被分配到泳道中的活動圖。 · 活動和其他圖活動圖沒有表示出計算處理過程中的全部細節(jié)容。它們表示了活動進行的流程但沒表示出執(zhí)行活動的對象?；顒訄D是設計工作的起點。為了完成設計，每個活動必須擴展細分成一個或多個操作，每個操作被指定到具體類。這種分配的結果引出了用于實現(xiàn)活動圖的對合協(xié)的設計工作。以下是數(shù)據(jù)流圖DFD：研究了一下DFD:     結構化分析是