《软件架构理论与实践》 —3.2.2　基于UML的建模方法

3.2.2　基于UML的建模方法

UML模型由多种模型组成，每种模型从不同角度和观点来描述系统。UML模型可通过用例图、类图、对象图、包图、活动图、合作图、顺序图、状态图、组件图和配置图来表示[29]。可用对象约束语言（Object Constraint Language，OCL）来扩展这些模型的语义。UML语义通过其元模型来严格地定义。元模型本身也是一种UML模型，它用来说明UML模型的抽象语法，这类似于用BNF范式来说明程序设计语言的语法。UML的扩展机制是UML的基本组成部分，它说明怎样用新的语义来定制、扩展UML的模型元素。UML的扩展机制包括类别模板（构造型）、约束和标记值。其中最重要的扩展机制是构造型，可适用于所有类型的建模元素。它是一种在已定义的模型元素的基础上构造新的模型元素的机制，构造的新的建模元素就称为构造型的建模元素，被扩展的元素称为基元素。构造型实际上是一组命名的约束和标记值，由OCL语句组成，可应用到其他模型元素中。因此构造型元素不能改变基元素的结构，但可扩充元素的语义。UML定义了一组丰富的模型元素以建模组件、接口、关系和约束。对于大部分架构构造，在UML中都可以找到相应的元素与之相对应。因此可以把UML看作一种架构建模语言。

UML旨在进行软件的细节设计，并不是专门为了描述软件架构而提出的，但是UML具有很强的架构建模特性，并且具有开放的标准、广泛的应用和众多厂商的支持。另外，UML 作为一个工业化标准的可视化建模语言，支持多角度、多层次、多方面的建模需求，支持扩展，并有强大的工具支持，确实是一种可选的架构描述语言。许多学者建议使用 UML 来描述架构。Booch 在他的一次题为“Software Architecture and the UML”的演讲中提出：可以将Kruchten的“4+1”视图[30]映射到UML图，其中，逻辑视图利用类图来形式化表示，过程视图映射成活动图，实现视图和配置视图分别映射为组件图和配置图，第五视图通过顺序图和协作图来表示。

Garlan等也曾提到使用UML来对软件架构进行建模的方法，主要思想是考虑如何利用类图和对象来构造组件以及如何利用UML组件对架构进行建模。在把现实世界的构造思想映射到 UML元素之前，必须确定和识别组成架构的构造元素，如组件、连接件、系统的属性和风格。2000年，软件工程国际会议（International Conference on Software Engineering，ICSE）纲要中也强调使用UML描述软件架构。

在UML图中也隐含了架构的元素。例如，用例图从概念上描述了系统的逻辑功能，类图反映了架构中的静态关系，顺序图反映了系统的同步与并行逻辑，活动图表现了一定的并发行为，组件图反映了系统的逻辑结构，部署图描述了物理资源的分布情况。

UML提供了对架构中组成要素建模的支持，具体体现在（见表3-1）：

1）UML的关系支持架构的连接件。

2）UML建模元素中的接口支持架构的接口。

3）UML的约束支持架构的约束。

4）UML结构元素中的类、组件、节点、用例以及组织元素中的包、子系统和模型相当于架构中的组件。

5）架构的配置可以由 UML的组件图、包图和配置图很好地描述。

6）UML用例模型和一些 UML预定义及用户自己扩展的构造型能够较好地表达架构的行为模型。

为了降低架构建模的复杂度，软件设计人员可以利用UML从多个不同的视角来描述软件架构：利用单一视图来描述框架的某个侧面和特性，然后将多个视图结合起来，全面地反映软件架构的内容和本质。

逻辑视图可以采用UML用例图来实现。UML用例图包括用例、参与者和系统边界等实体。用例图将系统功能划分成对参与者有用的需求。从所有参与者的角度出发，通过用例来描述他们对系统概念的理解，每一个用例相当于一个功能概念。

在开发视图中，用UML的类图、对象图和组件图来表示模块，用包来表示子系统，用连接表示模块或子系统之间的关联。

过程视图可以采用UML的状态图、顺序图和活动图来实现。活动图是多目的过程流图，可用于动态过程建模和应用系统建模。活动图可以帮助设计人员更细致地分析用例，捕获多个用例之间的交互关系。

物理视图定义了功能单元的分布状况，描述用于执行用例和保存数据的业务地点，可以使用UML的配置图来实现。

另外，UML的合作图可以用来描述组件之间的消息传递及其空间分布，揭示组件之间的交互。

使用UML对软件架构建模的主要优点有：

1）具有通用的模型表示法、统一的标准，便于理解和交流。

2）支持多视图结构，能够从不同角度来刻画软件架构，可以有效地用于分析、设计和实现过程。

3）有效利用模型操作工具（支持UML 的工具集）可缩短开发周期， 提高开发效率。

4）统一的交叉引用（cross-referencing）模型信息的方法有利于维护开发元素的可处理性， 避免错误的产生。

虽然UML可以对软件架构进行较好的描述，但它只是针对特定的面向对象的架构，对架构缺少形式化的支持等。使用UML建模存在如下一些问题：

1）对架构的构造性建模能力不强，缺乏对架构风格和显式连接件的直接支持。

2）虽然UML使用交互图、状态图和活动图描述系统行为，但语义的精确性不足。

3）使用UML多视图建模产生信息冗余和不一致。

4）对架构的建模只能到达非形式化的层次，不能保证软件开发过程的可靠性，不能充分表现软件架构的本质。

1.基于UML的SA通用建模方法和过程

使用UML元模型可以捕获和表示各种视图（包括非UML标准视图）元素，为了保持与UML定义的一致性和获得UML工具的支持，一般选择不更改UML元模型，而是通过扩展机制在已有UML元素的基础上构造新元素，在不改变原有元素结构的同时扩充元素的语义并加以区分。

基于UML对软件架构建模的主要思路是使用UML构造型（stereotype）表示新概念并构造新的模型元素，使用OCL对约束规则进行描述，然后进行相应转换，最后在UML视图中表示出来。

构造型可以用于在预定义的模型元素基础上构造新的模型元素，提供了一种在模型层中加入新的模型元素的方法。这样定制出来的模型元素可看作原模型元素的一个子类，其在属性和关系方面与原模型元素形式相同，只是添加了新的语义，用途更为具体。

标记值是一对字符串，包括一个标记字符串和一个值字符串，值字符串存储有关元素的信息。标记值可以与任何独立元素相关，包括模型元素和表达元素。标记是建模者想要记录的一些特性的名字，值是给定元素的特性值。

约束是模型元素之间的一种语义关系，是对模型元素语义的限制。

使用UML 表示软件架构的具体实现如下：

1）软件架构仅由其组件元素构成。

2）每一个组件具有两个标记值（tagged value）。 其中kindofComponent表示它是原子组件或是组合组件，其中sub-Components表示子组件。

3）组件只能通过端口与其他连接件相关联，而不能直接与其他组件相关联。

4）组件不能没有端口。

5）组件在执行时可以有多个实例。

6）每一个连接件至少与两个组件相连，且组件和连接件不参加其语义范围以外的任何关联。

7）组合组件的子组件只能是由连接件连接起来的组合组件或原子组件。

8）原子组件不能再包含其他组件（原子组件或子组件）。

9）每一个端口至多能与一个连接件关联。

Medividovic比较系统地总结了用UML对架构进行建模的三种途径[31]：

1）不改变UML用法而是将UML看作一种软件架构描述语言并直接对架构建模。这种方法最简单，实质是利用现有的UML符号来表示软件架构。用户很容易理解所建立的软件架构模型，并可以用与UML兼容的工具对其进行编辑和修改。但现有的UML结构无法与架构的概念直接对应起来。例如，连接件和软件架构风格在UML中无直接对应的元素，其对应关系必须由建模人员来维护。

2）利用UML支持的扩展机制约束UML的元模型以满足软件架构建模的需求。UML是一种可扩展的语言，人们可通过扩展机制增添新的结构而不改变现有的语法或语义。这种方法能显式地表示软件架构的约束，所建立的软件架构模型仍然可用标准的UML工具进行操纵，UML用户理解起来也比较容易。然而，对OCL约束进行检查的工具还不是很多。

3）对UML的元模型进行扩充，增加架构模型元素，使其直接支持软件架构的概念。该方法使UML中包含各种 ADL 所具有的优良特性，并且使其具有直接支持软件架构建模的能力。然而，扩展的概念不符合UML标准，因而与UML工具不兼容。

在用于软件架构建模时，UML缺少分析架构所需的语义。UML的模型元素与ADL的元素在结构上并无太大差异，但在语义上有较大的差别，因此必须用UML的扩展机制对其语义进行扩充，使之与ADL 的语义相符。结合这两种方法的优点并充分利用UML工具，对软件系统的开发具有很大价值。

（1）将UML模型转换为架构模型

该类方法直接使用UML建模，并将其转换为架构模型[32]。该方法的关键是保证UML中的应用设计兼具UML中的建模属性和ADL的强制约束（也可能是潜在的架构风格规则）。该方法的主要步骤如下：

1）建立基于UML的应用领域模型。

2）建立非形式化的架构图，如C2图。架构图对于领域模型中的类和架构图中的组件之间的转换很重要。这个步骤类似于DSSA。转换的目的是要表达UML中无法有效支持的连接件、组件消息接口等架构元素。

其中步骤2又分为4个子步骤，分别是：①定义类接口，以表示架构中的主要组件元素—消息接口。这里使用<<interface>> 对接口建模。每个类对应一个组件输出接口。

②定义连接件类。连接件类与它们连接的组件实现相同的接口。每个连接件可以被认为是一个简单类，它将接收到的消息发送到合适的组件。③建立表示架构风格的UML类图，主要描述类之间的接口关系。该步主要是建立精化的类图。④使用协作图描述类的实例，表达拓扑内容。

然而，UML没有为架构制品建模提供专门的构造型，也没有提供相应的工具集支持相应的转换。

（2）通过扩展机制对UML进行约束

该方法利用扩展机制对UML进行约束，使用OCL约束UML元模型中已有的元类：

从UML元模型中选择一个或者多个已有的元类，满足ADL建模构造或者建模能力。

定义一种可以应用在这些元类实例中的构造型，目的是将它们的语义约束到相关的ADL属性中。

以C2风格架构建模为例，具体的方法如下：

1）在UML中表示C2消息：UML元类的操作和C2的消息规约相匹配。利用UML创建C2消息规约时需要定义一种构造型，包含标记值以及对于操作的定量约束。为了对C2消息规约进行建模，需要添加一个标签来区分通知和请求，还要约束操作，使其没有返回值。

2）在UML中表示C2组件：UML元类Class和C2的组件符号比较接近。不过，UML中的操作是一种过程抽象的规约（可选前置和后置条件，方法是过程体），而C2中的组件只提供操作，而不是方法，这些操作是组件所提供的接口的一部分。

3）在UML中表示C2连接件：C2连接件受到很多C2组件的约束。不过连接件和组件在架构组合规则上是有区别的。另外，连接件可能不定义自己的接口，而是由与它们相连接的组件所确定。可以使用构造型《C2Connector》来对C2连接件进行建模，这与构造型《C2Component》类似。首先定义三种构造型，用于对组件和连接件的附件进行建模。这些附件是确定组件接口所需要的。

上面的构造型解决了UML通常不考虑的关联序列问题。这对于架构的拓扑信息编码是必需的。其中《C2Attach》可以根据与模型元素相关联的构造型指定约束。以后需要定义《C2Architecture》构造型来保证当定义C2架构拓扑时C2构造型使用的一致性和完整性。

4）在UML中表示C2架构：这一步是对系统架构中的组件和连接件的整体组合。一个定义良好的C2架构包含组件和连接件，组件的顶端和底部都有一个连接件，连接件的顶端（或底部）连接另外一个连接件的底部（或顶端）。UML和C2都通过消息传递来交互。

2.基于UML的性能模型

性能模型又称作面向分析的模型，是指为了进行性能或其他非功能性属性分析所建立的模型[33-46]。

传统的软件开发方法通常只关注软件的功能性需求，一般在软件生命周期的后期阶段才引入性能问题。它往往是在经过系统测试之后，才确定该设计是否真正满足系统功能、性能和可靠性方面的需求，若不满足系统的性能需求则重新设计软件系统，而这将会导致整个项目成本急剧增加。如果在软件开发早期就对软件模型的性能进行研究，则可通过对现有的软件架构设计方案进行定量的预测和评价，以及对各种设计决策进行比较，选择更优的软件架构设计方案，并指导整个设计过程。

UML是目前常用的架构描述方式，它侧重于描述系统的功能性行为。为了使UML模型能够描述系统性能需求，一种称为SPT性能文档的扩展语言已经被OMG组织采纳并定为规范。SPT性能文档通过构造型（stereotype）和标记值（tagged value）扩展了UML语言，以反映系统的性能需求，为设计时评估系统性能提供了方便。该扩展标准由一系列子扩展标准组成。扩展标准的核心是由一系列子扩展标准表示的通用资源模型框架。它为所有分析提供了一个公共的基础。

性能分析只需要其中的PAprofile、RTtimeModeling、RTresourceModeling扩展标准包。

1）通用资源建模：通用资源模型（GRM）是任何UML模型定量分析的基础。它由两个视图组成：一个是领域视图，即在实时系统和实时系统分析方法方面的结构和规则，GRM的这部分主要独立于UML元模型扩展而来；另一个视图是UML视图，其定义如何将领域模型的元素在UML中实现，由一系列UML扩展组成（构造型、标记值、约束）。它包含7个子包：

核心资源模型包是通用资源模型框架的基础，它定义了资源和QoS的基本准则，包含两个基本元素，一个是资源、提供的服务、服务的性能特性的描述符，另一个是与其相关的具体实例。

因果模型包基于UML 1.4的动态语义，但它具有更多的细节，在某些情况下也更精确。

资源利用模型包是核心资源模型包的补充。

动态使用模型包表示为一个场景实例，由预定义的一系列执行动作组成。

资源类型包用于将资源划分为若干类型。

资源管理包负责管理资源的访问控制策略，以及通过资源控制策略和资源本身创建和保持资源。

实现模型包又称为部署模型包，用于定义一系列资源服务及其能够提供的QoS值和其他QoS值。

2）通用时间建模：通用时间模型描述了如何将软件系统中的响应时间和时间相关机制进行适当的模型化。时间领域视图定义了一系列时间相关原则和语义，分别包括：

时间和时间值模型化原则。

时间事件和时间相关信号模型化原则。

时间机制模型化原则。

时间服务模型化原则。

3）性能分析领域建模：性能分析领域模型定义了一个通用的性能规则模型框架。

性能上下文（PerformanceContext）用来描述系统在各种情况下的性能特征，它由场景（PScenario）、资源（PResource）和负载（Workload）组成。

场景用来描述系统的执行细节，它由一系列有序的步骤组成，每个步骤代表一个相应的系统动作。它定义了系统的响应路径，附带有响应时间、吞吐量等QoS需求。场景由多个场景步骤通过顺序、循环、分支等结构组成。一个场景步骤既可以是最小粒度的基本操作，也可以是由多个基本步骤组合而成的子场景。

负载用来体现在执行一个特定的场景时该场景对相关资源的需求强度，用响应时间来描述。

资源表示执行场景步骤、提供服务使步骤得以完成的实体。资源可以分为处理资源和被动资源两种。处理资源包括处理器、接口设备、存储设备等物理设备。被动资源指有访问控制的资源，被多个并发资源操作共享。

在给性能模型指定参数方面，可以利用SPT性能文档在UML活动图中标记性能信息，比如执行时间、访问频率或资源需求等，然后利用LQN模型求解工具对导出的性能模型求解，进而可以根据求解结果评价和指导系统设计。