這一系列特征的依據來自于對不同架構描述語言（如UML-RT [SR98], Acme [GMW97], 和 SDL [ITU02]）長期使用的經驗。這些語言的特點在于，它們通過相對簡單的像圖這樣的概念被描述：基本的結構性節點，也就是所謂的部件，他們可以有一個或多個端口，它們之間可以由被稱作連接器的通信通道進行連接（如圖3所示）。這些集合體可以被封裝成更高層的單元，依次類推，這些新封裝成的單元也可以有自己的端口以便于與其他更高層的單元合并成更高層的單元
圖 3. 復雜結構建模概念
從某種程度上來說，這些概念在UML 1 中對于協作的定義里可以找到，只可惜它們不能用于遞歸。為了允許遞歸，協作結構被嵌套到類的規范中。這就是說這個類的所有實例都將有一個由類定義的內部結構。例如，在圖3中，部件（part）/a:A 和/b:B 都被嵌套在部件（part）/c:C中，從而表現了這個復雜結構類C的一個實例。而這個類的其他實例都會有相同的結構模式（包括所有的端口，部件以及連接器）
這就證明了，你可以通過這三個簡單的概念，以及它們的遞歸應用，對任何復雜的軟件架構建模。
活動
在UML中，活動被用來對不同種類的流程建模：信號流或數據流，也有算法流或過程流。不用說，對于眾多的領域及應用而言，基于流的描述是最自然的表現方式了。對于業務過程建模者和那些想主要通過信號處理器瀏覽整個系統的系統工程師，這種形式更是特別受歡迎。不幸的是，在UML 1中，行為建模在流的類型方面有大量嚴格的限制，這些限制被提出了異議。這其中的很多限制都是由于在基本的狀態機的頂部行為被覆蓋了，所以，它們受限于狀態機的語義。
UML 2.0中用一個消除了這些限制的更泛化的語義基礎替代了狀態機的底層。此外，這些語義基礎也從很多行業標準和業務過程形式中得到靈感，其中包括BPEL4WS [BPEL03]——在基礎的形式上增加了一系列非常豐富并且非常精確的建模特征。這包括以下一些能力：
中斷的活動流復雜形式的并發控制多樣的緩沖配置這就形成了一個豐富的建模工具集，能廣泛地表示不同的流類型。
由于其復雜的結構，你可以對活動遞歸地進行分組并對流進行連接以形成更高的層，這種層次清晰地定義了輸入和輸出。你可以一次把這些活動與其他活動合并形成更復雜的活動，一直到最高的系統層。
交互
在UML1 中，交互性是由協作圖中序列消息的注釋或單獨的序列圖來表現的。不幸的是，這樣導致失去了兩個基本能力：
對序列進行重用的能力，也就是可以在更廣范圍（或更高層）的上下文序列中重復的能力。比如，在一個應用程序中，一個驗證密碼的序列很可能出現在多個上下文環境中。如果不能對這些重復的序列進行打包形成單獨的單元，你就得對它們進行多次的定義。這不僅需要在系統操作上增加，還使模型的維護更為復雜了。（例如，當序列需要修改時）對不同的復雜控制流充分建模的能力，在表現復雜系統的交互性方面很普遍。這包括序列的重復，執行路徑的選擇，并發和順序——獨立執行等。幸運的是，關于復雜的交互性問題在電信領域得到了廣泛地研究。在多年定義通信協議的時間過程中，形成了一個標準。這個標準被作為主要依據用在UML2.0的交互性描述上。
關鍵的創新就是把交互性作為單獨命名的建模單元進行引入。這樣的交互性表現在內部對象間任意復雜的通信。它甚至可以被參數化以用來描述上下文獨立的交互模式。
你也可以從更高層遞歸地調用這些打包了的交互活動，類似于宏調用（圖4）。就像你所希望的那樣，你可以在任意程度上去進行嵌套。此外，交互活動還能在諸如循環和選擇這樣的復雜控制的構造中提供操作數（例如，某個給定的交互活動可能需要重復某個具體的次數）。UML 2.0 定義了大量的這種類型的建模構造體，給你在分解后的任何層面上進行復雜的端對端建模，提供了非常大的便利。
圖4. 一個復雜交互模型的例子
圖4舉例說明了一個擴展的交互模型。在這個例子中，交互活動ATM的訪問首先調用另一個低層的叫CheckPIN的處理過程（整個交互活動的內容沒有在圖中顯示），注意到后一個交互活動有一個參數（這個例子中也就是，在處理被取消前，一個無效PIN能被輸入的次數）。之后，客戶端發送一個同步的消息說明需要哪種交互活動，基于這個具體的值——DispenseCash活動或PayBill活動，將被執行。
在UML 2.0中，交互性不僅由序列圖來呈現（如同上面的例子所展示），也通過其他類型的圖（包括在UML1中定義的基于協作的形式）來表現。甚至還有通過非圖形化的表格來體現。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
