術語匯編 UML順序圖簡介
本節向大家介紹一下UML順序圖，和合作圖、活動圖一樣，UML順序圖是一種動態建模方法，那么它有什么特別之處呢，通過本節的介紹你就會知曉，下面讓我們一起來看一下有關UML順序圖的詳細介紹吧。
UML建模風格之UML順序圖
和合作圖、活動圖一樣，UML順序圖(Rumbaugh、Jacobson、和booch,1999)是一種動態建模方法。UML順序圖一般用于：確認和豐富一個使用情境的邏輯。一個使用情境就是系統潛在的使用方式的描述，也就是它的名稱所要描述的。一個使用情境的邏輯可能是一個用例的一部分，或是一條備選線路；一個貫穿單個用例的完整流程，例如動作基本過程的邏輯描述，或是動作的基本過程的一部分再加上一個或多個的備用情境的邏輯描述。或是包含在幾個用例中的流程，例如一個學生注冊入學之后，立即就要在三個班級注冊。
研究你的設計，因為它們為你提供了一種方式，你可以使用這種方式來可視化的調用類定義的操作。檢測面向對象的設計中的瓶頸。通過觀察什么消息被發送給一個對象，以及通過概略的觀察運行被調用的方法需要花費多長時間，你很快就能了解那里的設計需要變化，以達到在系統內部平衡負荷的目的。實際上某些CASE工具甚至能夠讓你模擬軟件這些特征。
使你能夠感覺到你的應用程序的那個類將會變得復雜的，這是個信號，意味著你需要為那些類畫狀態圖了。
通用準則
盡力保持消息的順序是從左到右排列的。
一個UML順序圖的消息流開始于左上方，消息乙的位置比消息甲低，這意味著消息乙的順序比消息乙要遲。因為西方的閱讀習慣是從左到右，你應該盡量按照和描述消息流一樣的方式，從左至右排列分類器（角色、類、對象，和用例）。在圖１中你可以看到分類器已經按照這種方式排列好了，如果Seminar對象在controller的左邊，那排列方式就不是標準的了。注意有時候消息流從左到右的排列是不可能的，例如一對對象彼此調用操作的情形。
將分類器分層
分層是一個通用的面向對象設計的方法，系統通常來說，總是組織成userinterface、process/controller、business、persistence、和system層(Ambler2001)。當系統是以這種方式設計的時候，通常會加強同屬于一層的分類器合作，而降低不同層的分類器的耦合度。因此按類似的方式對你的順序圖進行分層是有意義的。就這個使用情境的例子來說，一種分層的方法就是先注明人類角色，然后是表示情境的邏輯的controller類，然后是userinterface類，接著是business類，***是相關的技術類，它封裝了對數據庫和系統資源的訪問。以這種方式對你的順序圖分層，會使得順序圖更容易閱讀，也更容易發現分層的邏輯問題。圖１就采取這種方法。
圖⒈一次學生的注冊。
用和你的用例圖一致的名稱命名角色。
當你在對一個使用情境建模時，你的順序圖一般會涉及一個或多個角色。為了保持一致性，顯示在順序圖中的角色的名稱應該和用例圖上的相同。
用和你的類圖一致的名稱命名類。UML順序圖中的類和類圖中的類是相同的，因此它們應該有相同的名稱。
一個角色的名稱可以和類的名稱相同。
在圖１你可以看到一個命名為學生的角色和一個命名為學生的類。這樣做是合理的，因為這兩個分類器表示兩個不同的概念，角色表示在現實中的學生，而類則表示你正在構建的商業應用程序中的學生。
包含一個邏輯的敘述性描述。
圖１可以很難理解－－特別是對于不熟悉閱讀UML順序圖人來說－－因為它是很接近于實際的源程序。在你模型中包含一個業務邏輯的描述是很常見的，特別當該順序圖描述一個使用情境時，就像在在圖⒉的左邊看到的，這可以增加圖的可理解性，并且Rosenberg和Scott（1999）指出，這也為跟蹤用例和順序圖間的信息提供了重要的信息。
圖⒉在線定單付款。
在圖的最左邊放置人和組織角色。
對業務應用軟件來說，在大多數的中，主要的角色是一個人或一個組織。這些角色經常是該情境的發起人，同時也是UML順序圖的閱讀焦點，因此它們應該放在模型的"可看見的開始之處"。
在圖的最右邊放置反應系統角色。
反應系統角色是那些你與之交互的系統，應該放在圖的最右邊。因為在許多的業務應用軟件中，這些角色經常被當做"backendentities"，也就是那些你的系統通過存取技術交互的系統，例如CAPIs、CORBAIDL、消息隊列、或webservice。換句話說，把后端的系統放在圖***的位置。
在圖的最左邊放置系統角色。
先導系統角色是那些與你的系統交互的系統，根據力爭從左到右排列消息和分類器層的原則，應該放在圖的最左邊。
避免建模對象Destruction
雖然內存管理是很重要的的問題，特別是對象在適當的時候的銷毀，許多建模者不愿意在UML順序圖上建模對象的銷毀操作，而是在activation條（就是表示對象生命周期的那個豎條）的底部使用一個"Ｘ"符號，或使用一個帶<>版型的消息。比較圖１和圖２，注意圖1中引入了對象的銷毀，沒帶來明顯的好處，卻弄亂了圖的布局。而圖２則沒有注明對象銷毀。記住遵循敏捷建模(AM)的實踐簡單的描述模型。
這項指南的意義在于兩個理由∶首先，很多種語言都擁有稱作垃圾收集的技術，實現自動的內存管理，例如Java和Smalltalk。其次，在那些你需要明確的管理內存的語言中，例如C++，你的程序員一般地都能夠了解該怎么做，并不需要模型中的這些附加信息。注意在實時系統中，內存管理通常是一個關鍵性問題，你可能需要建模對象的銷毀操作。請期待下節有關UML順序圖的介紹。
【編輯推薦】
