这一系列特征的依据来自于对不同架构描述语言（如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中定义的基于协作的形式）来表现。甚至还有通过非图形化的表格来体现。
文章来源于领测软件测试网 https://www.ltesting.net/
