点击查看第一章
点击查看第二章

第3章　

软件架构模型
软件架构模型为软件架构提供了一种抽象、可视化或形式化的表示，为软件架构师、需求分析人员、软件工程师、潜在用户等提供了一个交流平台，并起到了从软件需求分析文档到软件详细设计和实现的桥梁作用。本章详细讨论软件架构的各种建模方法，包括各种图形可视化建模方法、UML建模方法、利用形式化语言的建模方法、数学建模方法和文本建模方法等。但是，至今没有一种建模方法能够满足软件架构建模的所有需求，所以本章讨论软件架构建模，旨在强调软件架构建模的意义和重要性，而统一的、能被业界普遍接受的软件架构建模方法仍然处于研究探索过程中。由于软件架构建模方法太多，无法将每种方法都展开介绍，本章只是向读者展现一个软件架构建模的路线图，有需要的读者可根据路线图寻找相关的建模方法以深入学习。另外，业界通常还会采用一些非常简单的方法，如盒线图方法、草图法等，由于它们的原理比较简单，而且没有系统和统一的语义基础，本章中就不一一介绍了。

3.1　引言

软件架构是一个系统概念，软件架构模型是捕捉部分或全部架构设计决策的人工产物，通过一个或多个角度对软件架构的各个侧面进行展示和说明，使得软件架构的不同利益相关者之间能够有效交流。软件架构建模是对架构设计决策的具象化和文档化[1]。
软件架构建模的意义在于，它能够将软件架构的某些关键或关注的方面剥离出来，使用统一的图形、文档和数据进行描述，达到直观便捷地理解、分析和交流的目的。
以时间为序，软件架构建模先后出现了五类方法：
1）基于非规范的图形表示的建模方法：在没有标准化架构建模的时候，人们通过线和框等结构来描述架构，具有较大的随意性，虽然便于记忆、富有启发性，但是不够精确。此类方法与架构利益相关者的经验习惯有关。在此过程中，还出现了一种基于模块连接语言的方法，该方法采用若干程序设计语言的模块的连接方式描述架构，直接与编程相关，易于理解和实现，但是抽象程度不够，难以处理高层次的架构元素。此类方法始于1981年[2]，止于1994年[3]，现已基本过时，本书不再做详细介绍。
2）基于UML的建模方法：UML是较为流行的软件建模方式，同时能够较为直接地应用到架构建模之中，特别是UML 2.0增加的组件描述方便了架构的图形建模[4]。UML建模主要属于可视化方法，但是也有研究利用其扩展机制进行形式化架构建模，后文中会详细讨论。
3）基于形式化的建模方法：与图形可视化方法不同，此类方法的重点不在于架构模型展示的直观性，而在于精确性，通过形式语言（包括OCL模型）对架构模型进行描述，具备严格的语义规范和一定的推理能力。
4）基于UML形式化的方法：该方法通过将UML的一些架构描述结构形式化处理，来提高UML描述软件架构的能力，包括正确性、一致性验证能力，克服了UML在描述软件架构方面的不足。
5）其他建模方法：在软件架构建模实践中，还出现了一些类似文本语言建模的方法，以便提高软件架构描述的通用性、易理解性和易变性，并进一步适应软件架构师的发散思维。

3.2　软件架构的可视化建模方法

3.2.1　基于图形可视化的建模方法

图形可视化是将软件架构按照图形的方式进行表达，强调便于利益相关者阅读、理解和交流，使之不会因图形过于复杂而难以把握软件架构的概况。
图形可视化方法可分为两类：正式图形表示和非正式图形表示。后者包括盒线图（Box-Line Diagram）、PowerPoint风格图形等，不具有严格的标准，较为随意，有一定的方便交流的作用。而正式图形表示需要有严格定义的结构，下面我们就从架构的三个基本要素（层次结构、组件关系和特性）来简单阐述软件架构的各种正式图形表示。
树形结构：树形结构是显示层次性软件架构的理想方式，简单易行。如图3-1所示的节点连接（node-link）表示。但是这种结构难以处理复杂的问题，鉴于当今软件的复杂层次关系，需要更完善的模型[4]。

树地图（TreeMap）：这种结构是由Johnson和Schneiderman提出的[5]，是展示整个软件层次架构的有效方法。这种技术的实质是一种空间填充方法，将层次信息作为嵌套的矩形集合显示。通常使用的是“花砖算法”（tiling algorithm），即对于每个层次，将相应的大盒子（box）分割为数个小盒子，这样迭代地进行水平和垂直分割，直至结束。在架构可视化方面，底层盒子往往用于表示方法，而组合盒子往往用于表示类。
改进的树地图：在树地图的基础上，有数种改进的架构可视化模型。文献[7]引入非正则形状（如泰森多边形、Voronoi）来代替矩形，以支持更多信息的显示。文献[8]研究了树地图中矩形的染色问题，以提高其表达能力。针对树地图主要显示的是软件架构的末端信息问题，文献[9]提出了圆形树地图，使用环来实现架构可视化，但是空间利用率不高。
冰块图（Icicle Plot）：冰块图中每一行代表树的一个层次，并且按照其子节点的数量进行分割[10]。冰块图有助于理解结构化的关系，如包可以用树根表示，而类和方法可以用树元素表示。但是对于大型系统的层次化架构，这种可视化技术的扩展性和导航性存在问题[8]。
旭日图（Sunburst）：这种模型最初由Stasko和Zhang提出，他们使用一个圆形或径向显示（而非矩形显示）来描述层次结构[11]。在这种图中层次结构呈放射状地与根铺设在中心，而更深层次则一步步远离这个中心。
与树地图相反但是与冰块图类似的是，旭日图的设计具有较好的弹性：图中元素的角度和颜色。研究结果表明，旭日图与树地图相比更易学习且更令人舒适[12]。
双曲树（Hyperbolic Tree）：在本质上，使用双曲空间比使用欧几里得空间有更多的显示空间，这种技术就称为双曲树显示。这种结构最初是在文献[13]中提出的，从本质上讲，它在双曲平面上列出了统一的层次结构，并将结构映射到欧几里得空间。由此产生的层次结构平铺在一个圆形的显示区域，可能会辅以焦点和上下文技术（如鱼眼变形[14]）。
双曲树能够带来一个更大的表示中心或集中区域，同时依然能够显示树的整体结构。当图过于庞大而无法有效呈现时，图中的节点可以聚在一起，并能够通过扩展来显示子树的结构。
在学术界和工业界都有许多可用的工具，以迎合利益相关者的各种需求[15-28]。在工业界，供应商开发了很多软件架构可视化商业工具，如Lattix、Enterprise Architect、NDepend、Klockwork Architect、IBM Rational Architect、Bauhaus 等。在学术界，研究团体也开发了大量的工具，如SHriMP、BugCrawler、DiffArchViz等。商业工具通常旨在被直接使用，而研究工具都是开源的，允许用户定制。

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个子步骤，分别是：①定义类接口，以表示架构中的主要组件元素—消息接口。这里使用<> 对接口建模。每个类对应一个组件输出接口。
②定义连接件类。连接件类与它们连接的组件实现相同的接口。每个连接件可以被认为是一个简单类，它将接收到的消息发送到合适的组件。③建立表示架构风格的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模型求解工具对导出的性能模型求解，进而可以根据求解结果评价和指导系统设计。

3.3　软件架构的形式化建模方法

软件架构建模通常采用非形式化方法，然而这种非形式化方法并不能很好地描述不同系统组成部分之间的一些特性，已经难以适应软件架构建模的进一步发展。同时形式化方法作为一种严格以数学为基础的方法，能够清晰、精确、抽象、简明地规范和验证软件系统及其性质，帮助发现其他方法不容易发现的系统描述的不一致、不明确或不完整，有助于增强软件开发人员对系统的理解。总之，形式化的建模方法能够极大地提高软件的非功能属性。
目前，在软件架构建模中，包含基于形式化规格说明语言的建模和基于UML形式化的建模两种软件架构形式化建模方法[47]。
1）基于形式化规格说明语言的建模：其基本思想是利用一些已知特性的数学抽象来为目标软件系统的状态特征和行为特征构造模型，如Z语言、B语言、VDM、Petri网等都是面向模型的方法。或者，它为目标软件系统的规格说明提供了一些特殊的机制，包括描述抽象概念并进行进程间连接和推理的方法，如CSP、CCS、CLEAR等都是代数方法。
2）基于UML形式化的建模：其基本思想是利用形式化与UML结合的建模方法研究成果，对UML图形赋予形式化语义，然后就可以利用已有的形式化语言和工具对UML模型进行推理验证。我们可以将UML相关图形转换成Z语言、B语言、XYZ/E、Petri网等不同的形式化语言，这提高了UML的准确性，为精确建模奠定了良好的基础。

3.3.1　基于形式化规格说明语言的建模方法

软件开发中的形式化建模方法主要是使用形式化规格说明语言来展示系统的架构，解析系统的特性。目前广泛应用的一些形式化描述方法有Z语言、Petri网、B语言、VDM、CSP等，这些形式化方法在功能上各有侧重，可以互补。
1. Z语言
Z语言是迄今为止应用最为广泛的形式化语言之一，软件企业在软件特别是大型软件的开发中经常采用Z语言进行需求分析、软件架构建模。Z语言是由英国牛津大学程序研究组（PRG）的Jean Raymond Abrial、Bernard Sufrin等人设计的一种基于一阶谓词逻辑和集合论的形式化规格说明语言，它采用了严格的数学理论，将函数、映射、关系等数学方法用于规格说明，具有精确、简洁、无二义性且可证明等优点。Z语言是一种功能很强的形式化规格说明语言，可以保证其书写的规格说明文档的正确性，同时还能保证有很好的可读性和可理解性。Z语言借助于模式（schema）来表达系统结构。模式有水平和垂直两种形式。一个模式由变量声明和谓词约束两部分组成，可用来描述系统的状态和操作，即“模式=声明+谓词”。声明部分引入变量，谓词部分表示了关于变量值的要求。
Z语言规范一般由四个部分组成：给定的集合、数据类型和常数；状态定义；初始状态；操作。在实际应用中，Z语言的一个规范（即语言文档）由形式化的数学描述和非形式化的文字解释或说明组成。形式化的数学描述由段落构成，这些段落按顺序给出各种构造类型描述、全局变量定义以及基本类型描述。具体描述时，一个段落可以给出一个或多个构造类型描述。根据段落的含义不同，段落的种类有基本类型、公理、约束条件、构造类型、缩写、通用构造类型、通用常量和自由类型。
Z语言作为一种广泛应用的形式化规格说明语言，在软件架构建模方面也得到了广泛关注。通过使用Z语言对软件架构进行形式化建模，软件开发者可以得到精确、严谨的架构描述。文献[48]中运用Z语言给出了管道–过滤器结构详尽的形式化描述的实例。该结构包括过程抽象和操作抽象。其中，过程抽象包括管道模式、过滤器模式、管线模式，用于描述管道–过滤器这一软件架构风格的静态性质；而操作抽象包括管道操作模式、过滤器操作模式、管线操作模式，详细地描述了管道–过滤器的动态行为。文献[49]以Z语言的形式化描述为基础，使用数据抽象和过程抽象，利用关系、函数、集合、序列、包等将数据从数据结构的表示细节中抽象出来，通过组件、连接件的添加及删除来实现准确描述软件架构的建模过程。
2. Petri网
Petri网是一种系统的数学和图形的建模和分析工具，适用于对具有并发、同步、冲突等特点的系统进行模拟和分析，并被广泛应用于复杂系统的设计与分析中[50]。 Petri网是用于表述分布式系统的众多数学方法之一，作为一种建模语言，它采用图形化方法将一个分布式系统结构表述为带标签的有向双边图。
Petri网的元素包括库所（place）、变迁（transition）、有向弧（arc）和令牌（token），其中有向弧存在于库所和变迁之间，令牌是库所中的动态对象，可以从一个库所移动到另一个库所。Petri网的规则是：有向弧是有方向的，两个库所或变迁之间不允许有弧，库所可以拥有任意数量的令牌[51]。
在软件架构领域，为了应对软件动态演化面临的挑战，应提高所建立的软件架构的动态演化性。利用Petri网及其扩展，对面向动态演化的软件架构进行建模能够有效提高所建立软件架构模型的动态演化性。因此，关于利用Petri网对软件架构建模的研究主要集中在描述软件架构的动态演化性方面。
经典的软件架构的Petri网描述是一个四元组，其形式化定义为L=（Cm，Ce，Rr，Ca），其中Cm为软件架构中的组件，Ce为软件架构中的连接件，Rr为软件架构中的角色，Ca为软件架构中的约束。Petri网形象地描述了软件架构的动态语义，通过变迁的发射Token从一个库所分配到另外一个库所，表明了资源或消息的传递，较好地说明了整个软件系统的流程。Petri网还可以用形式化的分析方法对软件系统的死锁和活性进行动态分析和验证，以进行早期的预防和检测，避免建模时的人为错误，同时可以利用相应的Petri网支持工具对软件架构模型进行模拟。
文献[52]提出了一种基于Petri网的软件架构—PSA（Petri-Software-Architecture）。PSA着眼于有关系统架构全局特性方面的问题，利用Petri网对系统元素间输入/输出以及系统静态、动态特性的描述能力，使用Petri网的可达标识图给出了一种计算组件贡献大小的方法，同时还给出了架构演化中组件删除、增加、修改以及合并与分解等各种变化引起的波及效应分析。通过系统 PSA的可达标识图（RMG）可以很容易界定某一组件变化所影响的其他组件，即组件对 SA 影响的大小（称为贡献或者贡献大小），比传统方法[53]中通过系统可达矩阵计算更加直观，而且组件变化后不一定需要每次重新计算，而可达矩阵方法需要在每次更新系统后重新计算其可达矩阵。
运用基于 PSA模型的可达标识图来分析软件架构性能，一方面能给系统架构师提供系统信息参考，如组件贡献大小可以帮助合适地改变系统架构，同时也可适当地更改原有系统可达标识图并快速分析变更后新系统的特性；另一方面，首次用 Petri 技术分析系统架构性能为软件架构研究提供了一个全新的思路。进一步的工作是利用 Petri 网辅助完成软件架构其他方面的设计，如辅助完成系统运行时的故障诊断与自校正设计。
文献[54]设计了一种面向动态演化的软件架构元模型，其选取Petri网作为软件架构建模的主形式化工具，使得模型在具有直观图形表示的同时，又具有精确且严格的语义。该软件架构元模型包括静态和动态两个视图。静态视图表达软件架构的静态结构，动态视图以静态视图为基础，反映系统行为导致的软件架构状态变化。其中，静态视图以Petri网的网结构表示，动态视图以网系统表示，组件之间的交互就相应地以Petri之间的交互和融合展示出来，软件系统的动态行为以Petri网中变迁点火引起的网系统的动态运行来展示。通过变迁的分类来映射稳定和易变需求，通过库所的分类来映射主动和被动需求，通过区分端口和接口来映射计算和交互的相对隔离等机制，在软件架构建模中继承和保持需求建模对动态演化的支持机制。
3. B语言
B方法用一种简单的伪程序语言来描述需求模型、规格说明，并进行中间设计和实现，这个语言就是B语言[55]。B语言支持规格说明的类型检测、动态验证、数学证明等以确保设计过程的正确性，同时分层次开发以降低大型软件开发的复杂性。分层次的方法可以将高层实现表示成低层的规范，一个完整的开发就是逐步实施的规范/实现过程。规范/实现过程在最低级的实现可以从预先实现的可重用的组件库中得到，高级的重用也可通过不断扩展新的组件库从而支持整个开发过程，每一层的实现过程是将规范翻译成可维护的独立编译的源代码和可执行指令的过程。同其他面向对象方法一样，B语言中的结构化机制增强了信息隐藏和数据封装特性，确保了大型开发中各个组件的独立开发。
B语言使用简单熟悉的符号表示法[56]。这种符号表示法用广义替换表示状态转换，从规格说明到编码，这种统一的形式减少了学习的难度和转换中的语法错误，这种“数学程序设计语言”可使人们使用一种非常具体的规格说明形式，而且对软件工程师来说也是极为有益的。B语言采用模块化构造，从规格说明到实现的模块化构造允许将规格说明和验证过程分解为多个子任务进行，相比其他类似的规格说明语言这个优点是非常突出的，而且比ADA和C++中的结构化构造更容易学习。B语言有大量实用的工具支持，它们支持了B方法中软件开发周期的所有阶段，甚至包括动画制作和文档生成等，其他形式化方法似乎还没有如此强大的类似集成工具。
作为一种较新的、基于模型范畴的形式化方法，B语言将程序和程序规格说明严格处于统一的数学框架下，采用基于Zermelo-Frankel集合论的符号表示法书写。B语言包含一种结构化机制（从需求规格说明到精化再到实现），以一种伪码语言即抽象机符号表示法（Abstract Machine Notation，AMN）构造需求模型并设计和实现，由于AMN支持规范说明的类型检测、动态验证，所以确保了设计过程的正确性。B语言在软件架构建模领域应用较多，文献[57]通过分析UML和B语言的优缺点，将二者结合，对UML模型图使用B语言进行形式化，定义映射规则，并使用B工具Atelier-B对所建模型进行自动检查与验证。文献[58]通过将UML转换为B AMN，利用Linux下的B语言工具集如BToolKit进行细化、实现及验证。
4. VDM
VDM是在1969年开发PL/1语言时由IBM公司维也纳实验室的研究小组提出的。VDM是一种功能构造性规格说明技术，它通过一阶谓词逻辑和已建立的抽象数据类型来描述每个运算或函数的功能。20世纪90年代初这种方法在欧美许多研究机构或大学得到了广泛的应用[59]。
VDM技术的基本思想是运用抽象数据类型、数学概念和符号来规定运算或函数的功能，而且这种规定的过程是结构化的，其目的是在系统实现之前简短而明确地指出软件系统要完成的功能。由于这种形式化规格说明中采用了数学符号和抽象数据类型，所以可使软件系统的功能描述在抽象级上进行，完全摆脱了实现细节，这样为软件实现者提供了很大的灵活性。此外，这种形式化规格说明还为程序正确性证明提供了依据。应用VDM技术进行系统开发包含了形式化规格说明、程序实现和程序正确性证明三个部分。
使用VDM定义形式化规格说明具有以下三个明显的优点：①只告诉计算机做什么；
②提供了程序正确性证明的依据；③使规格说明描述简练、精确。此外，使用VDM还可以使程序设计者牢固树立先抽象后具体的不断证明其正确性的逐步分解、自顶向下的开发思想，从而在整个程序开发的过程中用系统而严密的方法来保证所开发程序的正确性。文献[60]在VDM的基础上，使用其工具语言Meta-Ⅳ，通过抽象软件系统的语法域、语义域及语义函数来形式化表示软件架构的建模过程。文献[60]利用VDM的扩展语言—面向对象的VDM++，在RUP的分析和设计工作中将UML视图转换为相应的VDM++形式化规格说明，以规范软件架构的建模过程。同时通过VDM++形式化规格说明的每次静态检测与模拟执行，确定本次开发周期中所建模的规格说明满足评价标准的程度，以及在下一次开发周期中可做的改进，通过如此不断迭代的过程使得软件规范逐渐满足评价标准。
5. CSP
CSP即基于进程代数的描述语言，它以进程和进程之间关系的描述为基础，用来描述一个复杂并发系统的动态交互行为特性。CSP进程通过事件的有序序列来定义。在事件中，一个进程与它的环境相交互。一个进程的所有事件集合构成该进程的字母表。例如αP表示进程P的事件集合，即字母表。事件一般用小写字母表示，进程用大写字母表示。对字母表中的不同事件，进程将做出不同的动作，例如x:A→P(x)表示进程P的字母表A中的事件x发生后，进程P以x事件为初始事件继续进行。进程到某一时刻为止所处理的事件序列定义为进程的迹（trace）。针对复杂进程的描述，CSP允许进程的嵌套，一个大的进程可以由许多小的进程组成。CSP进程之间发送消息交互，进程之间的关系（即进程的组合方式）通过一些运算定义，如顺序、并发、选择、分支以及其他非确定性的交织等。另外，CSP定义了两个原语进程—Skip（正常终止）和Stop（死锁），用来终止一个进程。
CSP使用的符号子集包括以下元素[61]：进程和事件，进程描述了交互事件中的一个实体，事件可以是原子的，也可以包含数据，最简单的进程Stop表示没有事件；前缀，如果有e→P，则e为P的前缀；替代（alternative），即确定性选择，一个进程可以表现为P或Q，由它自己决定，表示为PΠQ；决定（decision），非确定性选择，一个进程可以表现为P或Q，且由它所处的环境（与其他过程的交互）决定，表示为P[]Q；命名进程（named process），进程名称可以与进程的表达式相关联。
CSP以事件为核心，通过事件集合实现进程及其关系的描述，并且通过失效/偏差模型对进程行为进行判别。失效由迹和拒绝集成对定义，拒绝集也是一个事件集合，它给出进程在指定迹上面可以拒绝的事件集合。偏差用于描述无法预测的环境。CSP的主要优点在于CSP规范的可执行特性，因此可以检查内在的一致性。此外，CSP还支持从规范验证到设计和实现的一致性，即如果规范是正确的，并且转换也是正确的，那么设计和实现也是正确的。CSP不仅可以用于建立刻画系统行为的模型，还可以用于建立推理的形式演算模型，研究者们发现CSP能够很好地描述软件架构模型的各种语义属性。文献[62]在CSP理论的基础上，对软件架构的形式语义和代数语义进行了分析，并对软件架构的元模型进行了描述，将元模型的每一层都描述为一个进程，然后利用CSP严密的语义特性表达能力和演算推理分析能力对整个模型进行良好的语义描述分析和检测。

3.3.2　基于UML的形式化建模方法

由于软件架构建模的本质在于预先给出待建系统的模型并分析其各种行为和特征，因此如何精确地描述模型显然是非常重要的。尽管UML可以用于描述软件架构，对各种软件系统或离散型系统进行建模，并且通过相应支持工具的配合可进行架构的文档化和部分目标语言代码的生成，然而UML不是一种形式化的语言，不能精确地描述系统的运行语义。因此，非形式化描述方法不能支持在软件架构的抽象模型层面进行相关分析和测试，需要进一步采用形式化建模方法及其支持语言和工具。
形式化方法和UML存在很大的互补性，二者的结合研究对提高软件架构的建模质量有着非常重要的意义。形式化与UML结合的建模过程和UML统一建模过程有明显的不同，它的目标是直接构造出尽可能正确的系统。图3-2是形式化与UML结合的开发过程图。因为形式化与UML结合的建模过程和UML统一建模过程的目标不同，所以它们的开发模式也不一样。形式化与UML结合的建模过程的需求分析和设计阶段需要投入大量工作量，通常占到全部工作量的60%～70%，编码和测试工作则只占30%～40%。而UML统一建模过程的编码和测试所需工作量非常大，一般要占到60%～70%[63]。从这里可以看出形式化与UML结合的建模过程在需求分析和设计阶段所投入的工作量要远远大于UML统一建模过程，这主要是因为其在设计阶段使用了形式化描述与验证，保证了软件架构设计的一致性和可靠性，从而使得后期的编码和测试工作变得相对简单。
下面我们来看看如何将形式化方法与UML结合在一起，其中使用的形式化方法以Z语言为例，而UML中以常用的类图、用例图、状态图和顺序图为例。

1. UML类图的形式化
UML类图是由类、泛化和关联组成的。类包括属性和操作，其中操作包含一组有序的参数。泛化表示了子类和超类的关系。关联一般有两个关联端，每个关联端具有若干属性。UML类图的形式化可以转化为对类、关联、泛化的形式化描述[64]。
（1）类的形式化
在UML中，类是一组具有公共特性的对象的抽象。类有名称、属性和操作。其中，属性有名称、可见性、类型和多重性；操作有名称、可见性和参数，操作的每个参数有名称和类型。在定义图形元素之前，先定义几个集合：Name、Type和Expression。用Z语言表示为[Name, Type, Expression]。在属性中多重性表示属性数据取值的可能数目。在UML中可见性可以是私有的、公共的和保护的。如图3-3所示为类的属性和参数的形式化表示。
VisibilityKind::=private丨public丨protected

操作中的参数是一个序列，而且参数名必须唯一。如图3-4所示。

在类中定义的属性名应该不同，并且操作应该带有不同的参数。如图3-5所示。

（2）关联的形式化
在UML中，类之间的关系用关联来表示。在大多数情况下，类图中两个类之间的关联是二元的，而且聚集和组合总是二元关联。因此，我们只考虑二元关联。二元关联有一个关联名和两个关联端。每个关联端有一个角色名和一个多重性约束、一个描述导航性的属性和一个描述关系类型（聚集、组合）的属性。多重性约束描述的非负整数的范围表示该位置上可以有多少个对象，并且限制了一端的一个对象可以与另一端的多少个对象有关联。谓词部分的约束表示多重性不能为0，对组合而言，组合端的多重性至多为1。如图3-6所示为关联端的形式化表示。
AggregationKind::=none丨aggregate丨composite
二元关联有一个名称并且恰好有两个关联端。谓词部分的属性表示了关联的特性：每个角色名必须不同。对聚集和组合关联来说，应该只有一个聚集或组合端并且另一端是部分或者聚集值为none。假定e1是聚集或组合端，则关联的另一端的聚集值为none，并且属性名和角色名不重叠。如图3-7所示。

（3）泛化的形式化
在UML中，泛化描述了对象之间的分类关系，其中超类对象描述了通用的信息，子类对象描述了特定的信息。如图3-8所示约束表达式表示不允许循环继承。
（4）类图的形式化
UML类图是由类、关联和泛化组成的。约束表达式表示在类图中，类的名称是唯一的，并且关联和泛化涉及的类应该在同一个类图中。如图3-9所示。

2. UML用例图的形式化
用例图由角色、用例和系统三个部分组成，所以对用例图的形式化工作可转化为对这三种元素的形式化描述[64]。
（1）角色的形式化描述
角色是与系统交互的外部实体（人或事），代表的是一类能使用某个功能的人或事，所以它的形式化描述比较简单。假设类A和类B使用系统的功能时具有角色C，则角色C可以表示成“Actor C==AVB”。
（2）用例的形式化描述
利用Z语言可以将用例形式化为如图3-10所示格式。

其中，Use Case Name是模式名，Declarations是声明部分，Predicates是谓词不变式部分。对用例模式而言，声明部分是状态变量和输入/输出声明，谓词不变式是执行用例的功能时应满足的条件和执行用例的功能后引起的变化。用例模式的谓词不变式可以表示如下：
Predicates = Pre-Pred ∩ Post-Pred
不变式中的“∩”表示“并且”的关系，意思是Predicates由Pre-Pred和Post-Pred两部分组成。Pre-Pred表示执行用例的功能前状态变量和输入应满足的条件，即用例的前置条件；Post-Pred表示执行用例的功能后状态变量和输出应满足的条件，即用例的后置条件。
1）独立用例的形式化描述：这里的独立用例是指该用例与其他用例之间不存在use或extend关系。前面所介绍的用例模式可以用来表示独立用例的形式化，为了更清晰地描述用例模式的前置条件和后置条件，将其用例模式的谓词不变式部分分成两部分表示，表示方法如图3-11所示。

2）有关系的用例的形式化描述：这里有关系的用例指的是与其他用例之间存在扩展或使用关系的用例的形式化。图3-12是扩展关系和使用关系的用例图。由于在这两种关系的用例中，Use Case A均继承了Use Case B中的一些行为，因此把Use Case B看作父用例，Use Case A看作子用例。形式化描述具有扩展和使用关系的用例时，对于父用例（即Use Case B）将按照独立用例的形式化方法进行描述；而对于子用例（也就是Use Case A），则将其描述成包含父用例的模式，如图3-13所示。

相对于独立用例的形式化，具有扩展和使用关系的用例（子用例）的描述只需要在Declarations部分增加其所继承的用例的声明即可。
（3）系统的形式化描述
系统是用例图的另一个组成部分，它的形式化描述同样可以按照图3-13的格式给出，只不过将Use Case Name用System Name代替，如图3-14所示，图中System Name是系统的名称，Declarations是系统所提供的功能（即用例）的声明，Predicates是对用例的约束，主要用来表示各个用例之间的关系。

（4）用例图的形式化描述
用例图是由角色、用例和系统组成的，所以只要将角色、用例和系统的形式化描述组织起来，就可得到用例图的形式化描述。用例图的形式化描述如图3-15所示。图中，Declarations部分是角色、用例和系统的说明，Predicates部分用于表示角色和用例之间的关系，也就是说用来表示某个角色与哪些用例之间有关系，即使用了用例的功能。
3. UML状态图的形式化
UML状态图由状态和迁移组成，对应地，在形式化过程中我们分别定义了迁移模式和状态模式，状态模式之间的层次化结构机制用Z语言的模式运算来表示[65]。
（1）迁移模式
迁移模式表征一个迁移所引起的状态变化，关联迁移前的变量值与迁移后的变量值。迁移具有触发事件、迁移条件、动作、源状态和目标状态，在定义Z语言的模式之前，先定义几个集合：事件集EE、迁移条件集CE、动作集AE。
EE::={Request_Event, Transform_Event, Signal_Event, Time_Event}
CE::={Boolean_Expression}
AE::={Assignment,Call,Create,Destory,Rerurn,Send,Terminate,Uninterpreted}
EE中的事件是具有时间和空间位置的显著发生的某件事。事件带有参数，参数可用于迁移中的动作。事件可以划分为请求事件（Request_Event）、变更事件（Transform_Event）、信号事件（Signal_Event）和时间事件（Time_Event）[66]，如表3-2所示。

EE中的迁移条件是布尔条件表达式，它可能引用附属于该状态的对象的属性以及触发事件的参数。迁移条件在触发事件发生时被求值，如果表达式为真，则迁移被激发。AE中的动作在迁移被激发时执行，动作通常是赋值语句或单个的计算，还包括调用操作、设置返回值、创建和销毁对象以及其他指定的控制动作。迁移模式定义如图3-16所示，其中Name是标识符集合，name指迁移名，Source_state指迁移模式连接的源状态模式，TriggerEE指触发事件集，Object_state指迁移的目标状态模式。

（2）状态模式
状态模式包含变量声明和使用声明变量的谓词集，其动态属性由迁移模式描述，静态属性则由状态模式和操作模式来描述，定义如图3-17所示。
（3）层次化结构机制表示
为了支持大中型软件开发，Z语言引入了层次化结构机制，允许用成组框将相关的图元结合在一起，成组框可以嵌套，从而支持对目标软件系统功能的逐级分解。下面我们利用Z语言的模式运算来定义组合状态的状态模式，从而表示层次化结构机制。

状态模式之间的OR、AND、SAND三种关系可以分别使用操作符“‖”“&”“#”来定义，其语法为：Schema-Exp::=Schema-Exp op Schema-Exp（其中op为‖、&或#）。
这三个操作符都是二元操作符，操作数为模式表达式。模式运算定义为合并子模式的变量声明和断言以形成一个新的模式。对于‖和&操作符，两个模式必须类型兼容，#操作符用于描述顺序系统，要求两个模式共享的输入、输出变量的类型一致，它的操作效果是对于所有共享变量，第一个模式的输出值将作为第二个模式的输入值。在定义了迁移模式和基本状态模式S2、S3、S4、S5、S7、S8后，图3-18中的UML状态机示例可用模式运算表示为：
sub1::=S2#S3　sub2::=S4#S5　S6::=S7#S8　S1::=sub1&sub2
S::=S1||S6

另外S2、S3、S4、S5、S7、S8也可以是引用子状态机状态或者占位状态，可以在逐步求精中不断细化，外层的状态细化成多个内部状态，每个子状态继承父状态的迁移。
4. UML顺序图的形式化
UML顺序图用于描述对象间动态的交互关系，着重体现对象间消息传递的时间顺
序[67–68]。顺序图采用两个轴：水平轴表示不同的实例（其实是角色，每个角色代表一个特定的对象或一组对象的集合，以下称之为实例），垂直轴表示时间。两个实例生命线间带有箭头的线表示消息，消息的箭头形状表明了消息的类型是发送还是返回。消息按发生的时间顺序从上到下排列，每个消息旁边标有消息名，也可加上参数。图3-19 给出了顺序图的一个具体实例。

（1）实例的形式化描述
顺序图具有一定的抽象句法，也必须满足一些合式规则。这里使用Z 语言严格地对它们进行描述，规格说明使用了以下给定的类型：[INSTANCE, TYPE, NAME] ，其中INSTANCE、TYPE、NAME分别是所有实例、类型和名称的集合。
在顺序图中实例的生命线上发送或接收消息的点称为位置点，每个实例的生命线上存在着有限个离散的位置点。如图3-20所示的全程变量

l _max，表示系统所允许的最大位置点。实例生命线上的位置点用模式ILocation 描述，其中任意一个位置点均不大于l_max。
（2）消息的形式化描述
在每个位置点上可以有一个或多个消息发送给其他实例，或者接收从自身或其他实例发送过来的一个消息。每个消息上标记有消息的名称和对应的参数，其中消息的参数类型应与系统模型中类图给出的操作说明一致。为了区分相同发送实例和接收实例间激活相同操作的两个消息，每个消息还附带一个唯一的标识号。消息标识用模式MsgId描述，其中任意两个消息的标识号均不相同。如图3-21所示。
顺序图中可以使用返回标记，它表示从消息处理中返回，而不是一个新消息，所以返回标记与原来的消息具有相同的消息标识。通常情况下它带有一个返回值，其类型也与类图中的说明相一致。返回标记可以由模式ReturnId定义，如图3-22所示。
用S 和R 分别表示消息的发送和接收，则消息的发送接收标志MSRFlag 定义为：
MSRFlag ::= S丨R
顺序图中的每个消息与实例生命线上的两点相关，即发送消息的位置点和接收消息的位置点，可以用模式Message描述。如图3-23所示。

另外，用映射msg来描述顺序图中位置与消息之间的对应关系，定义函数source、target来描述消息与发送或接收该消息的实例之间的对应关系：
/msg：ILocation F Message
source,target: Message → F1 INSTANCE
顺序图可用模式WFSequenceDiagram描述，其中至少有一个实例和一个消息，并且对于任意的消息，其发送位置点与接收位置点应不同。如图3-24所示。

UML与Z结合的建模过程是在目前软件规模和复杂性不断增大的情况下提出的，它对现在工业界软件架构建模过程做了一些改进，并提出了一些新的思路和构想。不只是Z语言，其他形式化方法也可以将非形式化的UML图形转换为具有精确语义的形式化规格说明，在非形式化的图形表示与形式化定义之间建立映射关系。UML中的类图、用例图、状态图以及顺序图较适合形式化描述，用形式化描述方法其他图反而使得描述过程更加复杂，容易降低效率。

3.4　其他建模方法

3.4.1　文本语言建模方法

文本语言建模即通过文本文件描绘架构[69-70]。文本文件通常需要符合某些特殊的句法格式，就像.c和.java文件分别需要符合C语言和Java语言规范一样。（当然，架构决策也可以用自然语言进行文档化，这种情况下建模需要受到该语言的语法和拼写规则等的限制。）
针对只由一个组件—Web浏览器构成的Web客户机，图3-25和图3-26显示了两种对其架构进行描述的方法。其中图3-25使用了xADL本身的XML文本建模，图3-26使用了xADLite文本建模。这是一个应用不同文本建模方法来描述同一模型的例子。使用XML文本建模方法具有易读性和易操作性，并且可以用XML工具进行句法验证。而xADLite文本建模方法在描述同一模型时，在阅读性方面做了优化。

使用文本语言建模有如下优势：它可以在单个文档中描述整体架构，并且存在众多文本编辑器以方便用户与文本文档的交互。由于对结构化文本的语法分析、处理和编辑等相关技术的研究已经持续数年，当使用一种元语言（如BNF（Backus-Naur Form））来定义文本的句法时，许多工具能够生成程序库来对使用该语言的文本文档进行句法分析和检查。许多编辑器附带额外的开发支持工具，如当用户输入时可实现自动补全或语法检查等。

然而文本语言建模也有如下问题：文本符号可以很好地描述线性和层次结构（例如在C语言和Java语言中，线性顺序可用从上至下的行表示，层次结构可用括号和缩进表示），然而用文本语言建模方法表示类图结构不易理解。另外，文本编辑器通常限于显示连续满屏的文本，很难以其他方式组织文本（也有一些环境允许代码折叠，使得用户可以将某个文本块限制在一行之内）。
文本语言建模方法不仅要能够描绘模型，也要方便用户与模型之间的互动，如编辑、修改等，一般来说可使用一个普通的文本编辑器或字处理器，也可使用专门的工具或平台。为了使文本更易阅读和理解，原始的方法是使用分隔符、空白符和换行符等使得程序结构更加突出。另外还有一些装饰方法，如可以使用不同的字形、字体和颜色（例如，关键字用粗体表示，评论用斜体表示，不同字体大小表示不同的嵌套等级等），还可以使用表格或提纲。文本语言建模方法中一些先进的机制有语法高亮显示、文本的静态检查、自动补全、代码折叠等。
1.语法高亮显示
语法高亮显示是文本编辑器在显示文本尤其是显示源代码时的重要特性之一，它根据不同类型显示不同的颜色和字体[69]。这一特性使得编写结构化语言如程序语言或标记语言时，其结构错误和语法错误能够明显区分开来。高亮不会影响文本本身的含义，它仅仅方便相关人员的阅读和编辑。
2. 文本的静态检查
静态程序分析是指在不实际执行程序的情况下对计算机软件进行分析（在执行程序过程中的分析被称为动态分析）[70]。大多数情况下是通过源代码进行分析，然而在某些情况下也会根据目标代码进行分析。该术语通常指自动化工具的分析，人工分析被称为程序理解或代码审查。
3. 自动补全
许多工具，如Web浏览器、电子邮件程序、搜索引擎接口、源代码编辑器、数据库查询工具、文字处理软件、命令行解释器等，都提供自动补全这一功能。一般的文本编辑器也逐渐集成这一功能。自动补全需要程序在用户没有完全输入时已能够预测用户想要输入的单词或短语。当可以根据输入记录来预测当前输入的词语时，这一特性是非常有效的，如只有有限个可用的或常用的短语（常出现在电子邮件程序、Web浏览器或命令行的解释器等情况中），或输入的文本是高度结构化并易于预测的语言（例如在源代码编辑器中）。文本编辑器可根据一种或多种语言的单词列表进行预测。许多自动补全程序在用户输入某个单词若干次后会自动学习。许多自动补全的程序都能够在学习新单词后（如用户写了几次之后），基于个人用户的学习习惯提出其他建议。自动补全或单词预测均可加快书写速度，非常适合使用环境中的人机交互。
4.代码折叠
代码折叠是文本编辑器、源代码编辑器以及集成开发环境（IDE）的一个特殊功能，允许用户选择性地隐藏和显示当前编辑的文件的某些部分。它允许用户在任意时刻管理大量文本的同时只需要关注那些相关文本。这一特性有利于开发人员管理源代码文件。区别于文本折叠，代码折叠还需要遵循相关标记语言或程序语言的句法。

3.4.2　模型驱动的架构建模方法

软件架构是软件开发的重要手段。现阶段与软件架构相关的技术中有两个特别值得注意：开发驱动架构（Development Driven Architecture）与模型驱动架构（Model Driven Architecture, MDA）[71]。软件架构原则集中于通过抽象和分离关注点来降低复杂性。它形成了成功的软件密集型系统的骨干，且被认为是系统设计和建模的一级元素。架构是一个软件系统的质量属性（如性能或可靠性）的主要载体。
模型驱动架构（MDA）是OMG于2001年正式提出的一个框架规范。不同于OMG颁布的另一个框架规范OMA，MDA不是一个实现分布式系统的软件架构，而是一个利用模型技术进行软件开发的方法。与传统的软件开发方法相比较，MDA致力于将软件开发从以代码为中心变为以模型为中心，使模型不仅被作为设计文档和规格说明来使用，更成为一种能够自动转换为最终可运行系统的重要软件制品。
MDA将模型区分为平台无关模型（Platform Independent Model，PIM）和平台相关模型（Platform Specific Model，PSM）。PIM是一个系统的形式化规格说明，它与具体的实现技术无关，PSM则是基于某一具体目标平台的形式化规格说明（这里的平台指的是使用特定的技术）。模型不再仅仅是描绘系统、辅助沟通的工具，而是软件开发的核心和主干。它的核心思想是抽象出与实现技术无关、完整描述业务功能的平台独立模型，针对不同实现技术制定多个映射规则，并通过这些映射规则及辅助工具将PIM转换成与具体实现技术相关的平台模型PSM，最后将PSM转换成代码[72]。
PIM与PSM这两种模型是MDA架构中对于一个系统的不同视角的模型描述，它们之间是抽象和求精的关系。与具体实现技术无关，PIM可以被多种实现技术重用，当技术平台发生变迁时，PIM不必做改动；PIM可以更加精确地体现系统的本质特征，对跨平台互操作问题进行建模非常容易。因为使用与平台无关的通用术语，语义表达会更加清晰。PIM与PSM两个模型之间通过模型映射机制相互映射，从而保证了模型的可追溯性，这也体现了MDA软件开发过程是一个自顶向下、逐步求精的过程。MDA的一个目标是简化分析模型的重用。由于平台的相关性，同样的分析模型可以用在许多不同的平台环境下。
以架构为中心和模型驱动的范式组合可以方便地用于自动化改造过程中，也可以实现MDA方法的重用。基于此，文献[73]提出了ArchMDE，其主要思想就是在任何平台上实现软件架构的独立性。因此，独立于平台的架构问题必须在PIM层次处理。出于这个原因，文献[5]将PIM分为两个层次：架构独立模型（AIM）和架构具体模型（ASM）。AIM和ASM都是不包含任何具体实施技术的系统模型。作为一个分析模型，AIM表现出一定的架构独立性，使其适用于大量不同的架构设计。 ASM结合了AIM中的规格，可以指定该系统如何使用一个特定风格的架构细节。既然已经将PIM分为AIM和ASM两层，自然允许集中架构设计决策，以改善架构特性的清晰度。AIM及其适应性使得可重用性得以增加。而在从PIM到PSM的转换中，ASM使得这种转换独立于执行平台。
面向MDA的建模和映射技术主要包括元对象机制（Meta Object Facility, MOF）、统一建模语言（UML）、公共仓库元模型（Common Warehouse Meta Model，CWM）[74]。
MOF是OMG提出的一个对元模型进行描述的规范的公共抽象定义语言。MOF是一种元–元模型，即元模型的元模型。MDA中的UML、CWM元模型均以MOF为基础。MOF标准的建立确保了不同元模型之间的交换。作为一个描述建模语言的标准语言，MOF标准避免了将来由于建模语言不同而产生建模语言间相互理解与转换的障碍[75]。
CWM为数据仓库和业务分析领域最为常见的业务与技术相关元数据的表示定义了元模型[76]。CWM实际上提供了一个基于模型的方法来实现异构软件系统之间的元数据交换。这样，对于依据CWM建立的数据模型，尽管它们存储于不同的软件系统中，但可以很便利地被整合和集成，进而确保数据挖掘等应用可以跨越企业数据库的边界。
模型驱动软件架构不仅能够用标准的符号表示这些开发模型，还能够定义模型间的转换来获得最终的软件产品。如果模型遵循MOF规范，以及MOF2.0的查询/视图/转换（Query/View/Transformation，QVT）语言，就能够形式化定义这些转换。模型驱动架构最大的好处在于只需要较少的时间和精力来开发整个系统，从而提高了生产率。此外，模型驱动架构还能为系统的演化、集成、互操作性、轻便性、适应性和重用性提供支持。
目标系统的需求由公共信息模型（CIM）定义，根据 CIM生成与平台无关的模型（PIM），接着再根据不同的平台和技术，将PIM自动转换成与特定平台相关的模型（PSM），最后根据PSM生成代码，得到最终的软件架构。

3.5　软件架构建模方法的发展趋势分析

20世纪80年代出现的面向对象技术是软件技术的一次革命，系统分析人员开始借助面向对象技术对将要建造的软件系统建模。这些模型元素几乎与代码元素相同，所以从模型生成代码成为可能。而且用模型代替代码使得开发人员可以在更高的抽象层次上讨论问题，避免了对代码语法不必要的纠缠。随着软件架构建模技术的发展，建模领域也出现了一些问题：工具开发商不得不耗时费力地在同一个工具里支持大量不同的图形、符号、表示法，而软件开发人员面对众多的方法、工具则显得无所适从。若要解决这些问题，需要提出一个完备的、灵活的、精确的、可扩展的架构建模解决方案，这也是学术界和工业界共同的奋斗目标。下面我们来分析架构建模技术是如何向这一奋斗目标发展的。
在软件开发过程中有一个模型成熟度级别（Modeling Maturity Level，MML）的概念[77]，用来衡量模型的效率和模型的层次级别。通过这种衡量，可构建出更加优良的模型，从而提高软件开发的效率，减少人力成本。MML有六层示意图，分别如下：
□第0层：没有标准，模型存在于开发者的头脑中。
□第1层：文本表达，用自然语言描述想法。
□第2层：文本和图，用自然语言以及一些图形来描述想法。
□第3层：模型和图，用建模语言描述的图来表达模型，用自然语言加以辅助。
□第4层：精确的模型，用一致而又连贯的文本/图来精确地描述模型，它们是没有歧义的，可以直接映射到编程语言。
□第5层：只有模型，此时的模型是对系统的完备、一致、详细和精确的描述。它足以完成全部代码的生成工作，生成的代码无须任何改动即可运行。
这里结合MML的层次概念来分析软件架构建模技术的发展趋势。从原始的文本建模（第1层）到目前广泛应用的UML建模（第3层），技术的发展核心都是如何让架构模型能够更完备地反映出架构的设计决策，重心在模型本身。从第4层开始，人们的关注点转移到如何将模型精确、完备地转换成代码，这里应用了形式化的建模技术，重心在于模型到代码的转换过程。第5层是人们的一种设想，模型取代程序代码成为软件开发过程中的产品，建立精确的模型后可以直接生成全部代码，无须修改即可交付。这里的层次只是一种方法论的划分，软件架构建模技术并不是顺序地从一个层次发展到下一个层次，而是各个层次上的技术都在不断进步、共同发展。图3-27是软件架构建模的技术发展路线。

3.5.1　第1层：文本模型

第1层是文本模型，从原始的自然语言文档化到以XML为代表的有固定规范、结构的文档化，都是通过文本文件来描述软件架构。由于对结构化文本的语法分析、处理和编辑等相关技术的研究已经持续数年，当使用一种元语言来定义文本的句法时，许多工具能够生成程序库来对使用该语言的文本文档进行句法分析和检查。文本符号可以很好地描述线性和层次结构，但是描述类图结构时不易理解。

3.5.2　第2层：图形可视化模型

第2层是图形可视化模型，其实UML也是一种图形可视化的建模方法，但由于其地位重要、应用广泛，将UML单独作为第3层来分析[78]。图形可视化是将软件架构按照图形的方式进行表达，需要便于利益相关者阅读、理解和交流，使之不致因图形过于复杂而难以把握软件架构的概况。

3.5.3　第3层：UML模型

第3层是UML模型，UML模型之所以能够得到学术界和工业界的广泛支持，是因为其可以使用单一的集成表示法来对系统的多个方面进行建模，模型范畴包括系统的静态结构和动态行为特征、系统的逻辑功能和物理部署。

3.5.4　第4层：形式化模型

第4层是形式化模型。在目前通用的软件架构建模方法中，通常还是非形式化方法。然而这种非形式化方法并不能很好地描述不同系统的组成部分之间的一些特性，已经难以适应软件架构建模的进一步发展。因此，在软件架构的建模过程中必须要有具备精确描述能力的形式化方法和研究工具。目前在软件架构建模领域，形式化方法的关注热点主要集中在使用形式化规格说明语言进行建模和基于UML形式化建模这两方面。表3-3对这两个研究热点进行了比较分析。

形式化建模的理论基础是形式化规格说明语言，这种语言采用数学的形式描述系统将要“做什么”，用带有精确定义的形式语言来描述程序的功能，它是设计与实现程序的出发点，也作为验证程序是否正确的依据。关于形式化规格说明语言的研究主要分为以下两类：
1）基于模型的方法：其基本思想是利用一些已知特性的数学抽象来为目标软件系统的状态特征和行为特征构造模型。如Z语言、B语言、VDM、Petri网等都是基于模型的方法。每一种基于模型的方法都会提出一套自己的规范，然后采用数学方法来说明规范，但是规范所使用的数学工具并不能保证规范是正确的。当然也可以使用证明技术来辅助确认，但这也只能简单地缩短形式化方法与现实世界之间的距离，并不能消除它。
2）代数方法：它为目标软件系统的规格说明提供了一些特殊的机制，包括描述抽象概念并进行进程间连接和推理的方法。如CSP、CCS、CLEAR等都是代数方法。代数方法对开发人员的要求很高，对于架构的描述往往难以理解，导致架构只能为“小众”服务，同时代数方法可扩展性差，对架构进行修改后需要重新进行代数计算和验证，代价很大。
由于形式化建模方法本身的局限性，研究人员逐渐把视线转移到UML模型的形式化上。鉴于UML建模的龙头地位，基于UML模型的形式化无论在理论上还是应用上都较易普及。UML的语法结构采用形式化规格说明，是精确的；但是其语义部分采用自然语言描述，缺乏精确性，使得不能对UML模型进行分析和论证。目前，对UML语义的形式化研究主要有以下三种思路：
1）对UML核心语法进行形式化，使得UML成为精确的语言：其目标是运用浅显的数学知识将UML发展为一种精确的（形式化的）建模语言[79]。这种方法通过对UML核心语法进行形式化，使得UML符合形式化规格说明语言的要求。它是在元模型层次上进行的，可保证在此基础上建立的UML模型层和用户对象层有可靠的数学模型基础，为构造、操纵和细化UML模型提供一种通用的办法。在此基础上建立的UML模型具有可靠的数学基础，便于细化和验证，但这种思路的实现难度较大，而且核心语法进行形式化处理后，存在与现有的各种UML图形不匹配的问题。
2）约束语言方法：此方法的思想是通过设置一个好的约束来消除语义歧义性，比如扩展OCL以加强其约束能力而达到精确性，但这种方法经常需要获取难以得到的元模型数据。
3）形式化转换方法：利用形式化语言在不丢失或者少丢失信息的前提下，把对象模型转换为具有一致性管理过程和强有力的工具支持的形式注释[80]。可以将UML相关图形转换成Z语言、B语言、XYZ/E、Petri网等不同的形式化语言，以提高UML的准确性，为精确建模提供良好的基础。由于前两种方法难度极大或要获得难以得到的元模型数据，因而进行研究的学者和机构比较少，取得的成果也非常少，现在研究最多的是第3种方法。

3.5.5　第5层：未来模型

第5层是一种设想，这一设想中只有模型，是学术界和工业界的共同奋斗目标。这一奋斗目标的达成需要前四层技术都发展到相当成熟的阶段。高层次的方法虽然在方法论上较先进，但是在某些实际应用中并不一定比低层次的建模方法更优秀。Werner Heijstek等人设计了一项实验[81]，以比较图形化方式和文本化方式在软件架构设计决策交流方面哪个更为有效，其中图形化方式采用的是UML，而文本化方式采用的是自然语言描述，参与者是来自工业界和学术界的47名成员。研究结果表明，以UML为主导的方法和以自然语言为主导的方法都不能被证明是更为有效的对软件架构设计决策进行交互的方法，并且对于母语非英语的参与者，这种图形化方式并不能消除其在文档中提取信息的困难。Soni等人在1995年对11家工业系统进行调查发现，非形式化和半形式化的技术被结合用来描述软件架构[82]，其中非形式化的图表和自然语言可以用来描述很多形式化图表也不能描述的架构。他们指出，即使用形式化符号表达，但辅以非形式化和一些图表也可增强对形式化模型的理解。只有将各个层次的先进技术结合在一起，才能建立完备、精确的模型，才能利用模型直接生成全部代码。

3.6　本章小结

本章详细讨论了软件架构建模的各种方法，包括图形可视化建模方法、UML建模方法、形式化建模方法，以及文本建模方法等。但是，至今没有一种建模方法能够满足软件架构建模的所有需求，所以本章讨论软件架构建模，旨在强调软件架构建模的意义和重要性，而一种统一的、能被业界普遍接受的软件架构建模方法仍然处于研究探索过程中。已有的资料表明，目前UML建模和形式化建模是两种主流的建模方法。

思考题

3.1　软件架构建模的本质问题是什么？
3.2　为什么很难提供一种统一的软件架构建模方法？
3.3　请讨论软件架构建模的意义。
3.4　简述软件架构可视化建模的主要不足。
3.5　简述软件架构形式化建模的主要不足。
3.6　请比较一下各种软件架构建模方法的优缺点。
3.7　为什么Medvidovic等人认为UML不是一种软件架构建模语言？
3.8　什么是软件架构的功能建模和性能建模？如何进行软件架构功能建模和性能建模？
3.9　针对软件架构建模，未来你能做的事情有哪些？

参考文献

[1]　R N Taylor, N Medvidovic, E M Dashofy. Software architecture: foundations, theory, and practice[C]. Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering-Volume 2. ACM, 2010: 471-472.
[2]　J L Archibald. The external structure: Experience with an automated module interconnection language[J]. Journal of Systems and Software, 1981, 2(2): 147-157.
[3]　T R Dean, D A Lamb. A theory model core for module interconnection languages[C]. Proceedings of the 1994 conference of the Centre for Advanced Studies on Collaborative research. IBM Press, 1994: 13.
[4]　T Khan, H Barthel, A Ebert, er al. Visualization and evolution of software architectures[C]. Proceedings of IRTG 1131 on Visualization of Large and Unstructured Data Sets Workshop 2011: 25-42.
[5]　A Telea, L Voinea, H Sassenburg. Visual tools for software architecture understanding: A stakeholder perspective[J]. IEEE software, 2010, 27(6): 46-53.
[6]　B Johnson, B Shneiderma. Tree-maps: A space-filling approach to the visualization of hierarchical information structures[C]. Proceedings of the IEEE Conference on Visualization, 1991 (IEEE Visualization'91), 1991: 284-291.
[7]　M Balzer, O Deussen, C Lewerentz. Voronoi treemaps for the visualization of software metrics[C]. Proceedings of the 2005 ACM symposium on Software visualization. ACM, 2005: 165-172.
[8]　S Ducasse, S Denier, F Balmas, et al. Visualization of Practices and Metrics[J]. Squale project Workpackage, 2009, 1.
[9]　W Wang, H Wang, G Dai, et al. Visualization of large hierarchical data by circle packing[C]. Proceedings of the SIGCHI conference on Human Factors in computing systems. ACM, 2006: 517-520.
[10]　T Barlow, P Neville. A comparison of 2-d visualizations of hierarchies[C]. Proceedings of the IEEE Symposium on Information Visualization 2001 (INFOVIS’01), 2001: 131-138.
[11]　W Randelshofer. Visualization of large tree structures [EB/OL]. http://www.randelshofer.ch/blog/2007/09/visualizing-large-tree-structures/. 2007-09-24.
[12]　J Stasko, E Zhang. Focus+Context Display and Navigation Techniques for Enhancing Radial, Space-Filling Hierarchy Visualizations[C]. Proceedings of the IEEE Symposium on Information Visualization. IEEE, 2000.
[13]　J Lamping, R Rao, P Pirolli. A focus+context technique based on hyperbolic geometry for visualizing large hierarchies[C]. Proceedings of the SIGCHI conference on Human factors in computing systems, CHI ’95, 1995:401-408.
[14]　T A Keahey , E L. Robertson. Nonlinear magnification fields[C]. Proceedings of the IEEE Symposium on Information Visualization. IEEE, 1997: 51-58.
[15]　S Duszynski, J Knodel, M Lindvall. Save: Software architecture visualization and evaluation[C]. Proceedings of the European Conference on Software Maintenance and Reengineering. IEEE, 2009: 323-324.
[16]　D Zeckzer. Visualizing software entities using a matrix layout[C]. Proceedings of the 5th international symposium on Software visualization. ACM, 2010: 207-208.
[17]　N Sangal, E Jordan, V Sinha, et al. Using dependency models to manage complex software architecture[C]. Proceedings of the 20th Annual ACM Sigplan Conference on Object-Oriented Programming, Systems, Languages, and Applications, Aan Diego, CA, USA, 2005, 40(10): 167-176.
[18]　D Holten. Hierarchical edge bundles: Visualization of adjacency relations in hierarchical data[J]. IEEE Transactions on visualization and computer graphics, 2006, 12(5): 741-748.
[19]　M Balzer, O Deussen. Level-of-detail visualization of clustered graph layouts[C]. Proceedings of the 2007 6th International Asia-Pacific Symposium on Visualization, 2007( APVIS'07). IEEE, 2007: 133-140.
[20]　M Termeer, C F J Lange, A Telea, et al. Visual exploration of combined architectural and metric information[C]. Proceedings of the 3rd IEEE International Workshop on Visualizing Software for Understanding and Analysis. IEEE, 2005.
[21]　H Byelas, A Telea. Visualizing metrics on areas of interest in software architecture diagrams[C]. Proceedings of the IEEE International Conference on Visualization Symposium, IEEE, 2009: 33-40.
[22]　S Alam, P Dugerdil. Evospaces visualization tool: Exploring software architecture in 3d[C]. Proceedings of the 14th IEEE Working Conference on Reverse Engineering, IEEE, 2007: 269-270.
[23]　M Balzer, O Deussen. Hierarchy based 3D visualization of large software structures[C]. Proceedings of the IEEE Conference on Visualization, IEEE, 2004.
[24]　Telea, D Auber. Code flows: Visualizing structural evolution of source code[C]. Proceedings of the IEEE Conference on Computer Graphics Forum. Oxford, UK: Blackwell Publishing Ltd, 2008, 27(3): 831-838.
[25]　Collberg, S Kobourov, J Nagra, et al. A system for graph-based visualization of the evolution of software[C]. Proceedings of the 2003 ACM symposium on Software visualization. ACM, 2003.
[26]　M Lanza. The evolution matrix: Recovering software evolution using software visualization techniques[C]. Proceedings of the 4th international workshop on principles of software evolution. ACM, 2001: 37-42.
[27]　G Langelier, H Sahraoui, P Poulin. Exploring the evolution of software quality with animated visualization[C]. Proceedings of the IEEE Conference on Visual Languages and Human-Centric Computing, IEEE, 2008: 13-20.
[28]　M Pinzger, H Gall, M Fischer, et al. Visualizing multiple evolution metrics[C]. Proceedings of the 2005 ACM symposium on Software visualization. ACM, 2005: 67-75.
[29]　Steven Hovater. 在您的开发项目中使用 IBM Rational Software Modeler 和IBM Rational RequisitePro 可视化跟踪能力[EB/OL]. http://www.uml.org.cn/requirementproject/200805132.asp, 2008-05-13.
[30]　P Krunchten. Architectural blueprints—The “4+1” view model of software architecture[J]. Tutorial Proceedings of Tri-Ada, 1995, 95: 540-555.
[31]　N Medvidovic, D S Rosenblum, D F Redmiles, et al. Modeling software architectures in the Unified Modeling Language[J]. ACM Transactions on Software Engineering and Methodology (TOSEM), 2002, 11(1): 2-57.
[32]　G P Gu, D C Petriu. From UML to LQN by XML algebra-based model transformations[C]. Proceedings of the 5th international workshop on Software and performance. ACM, 2005: 99-110.
[33]　H Gomaa, D A Menascé. Design and performance modeling of component interconnection patterns for distributed software architectures[C]. Proceedings of the 2nd international workshop on Software and performance. ACM, 2000: 117-126.
[34]　S Balsamo, M Marzolla. Performance evaluation of UML software architectures with multiclass Queueing Network models[C]. Proceedings of the 5th international workshop on Software and performance. ACM, 2005: 37-42.
[35]　D'Ambrogio. A model transformation framework for the automated building of performance models from UML models[C]. Proceedings of the 5th international workshop on Software and performance. ACM, 2005: 75-86.
[36]　D C Petriu, X Wang. From UML descriptions of high-level software architectures to LQN performance models[C]. Proceedings of the IEEE Conference on International Workshop on Applications of Graph Transformations with Industrial Relevance. Springer, Berlin, Heidelberg, 1999: 47-63.
[37]　D C Petriu, H Shen. Applying the UML performance profile: Graph grammar-based derivation of LQN models from UML specifications[C]. Proceedings of the International Conference on Modelling Techniques and Tools for Computer Performance Evaluation. Springer, Berlin, Heidelberg, 2002: 159-177.
[38]　李传煌, 王伟明, 施银燕. 一种UML软件架构性能预测方法及其自动化研究[J]. 软件学报, 2013(7): 1512-1528.
[39]　D A Menasce, H Gomaa. A method for design and performance modeling of client/server systems[J]. IEEE transactions on software engineering, 2000, 26(11): 1066-1085.
[40]　G P Gu, D C Petriu. XSLT transformation from UML models to LQN performance models[C]. Proceedings of the 3rd international workshop on Software and performance. ACM, 2002: 227-234.
[41]　M Woodside, D C Petriu, D B Petriu, et al. Performance by unified model analysis (PUMA)[C]. Proceedings of the 5th international workshop on Software and performance. ACM, 2005: 1-12.
[42]　L G Williams, C U Smith. Performance solutions: a practical guide to creating responsive, scalable software[M]. Addison Wesley Longman, 2002.
[43]　V Cortellessa, R Mirandola. Deriving a queueing network based performance model from UML diagrams[C]. Proceedings of the 2nd international workshop on Software and performance. New York, NY, USA: ACM, 2000: 58-70.
[44]　A Alsaadi. A performance analysis approach based on the UML class diagram[J]. ACM Sigsoft Software Engineering Notes, 2004, 29(1): 254-260.
[45]　C U Smith, C M Lladó, V Cortellessa, et al. From UML models to software performance results: An SPE process based on XML interchange formats[C]. Proceedings of the 5th international workshop on Software and performance. New York, NY, USA: ACM, 2005: 87-98.
[46]　黄玉麟, 赵瑞莲. 一种基于顺序图的软件性能分析方法[J]. 北京化工大学学报(自然科学版), 2007, 34(s1): 89-92.
[47]　M Shaw, D Garlan. Software Architecture: Perspectives on an Emerging Discipline[J]. Prentice Hall, 1996, 24(1): 129-132.
[48]　郭广义, 李代平, 梅小虎. Z语言与软件体系结构风格的形式化[J]. 计算机技术与发展, 2009, 19(5): 140-142.
[49]　段玉春, 朱小艳. 软件体系结构动态演化的Z描述语言扩展方法[J]. 兰州理工大学学报, 2013, 39(1): 88-91.
[50]　于振华, 蔡远利. 基于面向对象Petri网的软件体系结构描述语言[J]. 西安交通大学学报, 2004, 38(12): 1236-1239.
[51]　沈军. 软件架构[M]. 南京: 东南大学出版社, 2012: 182-322.
[52]　吴小兰, 王忠群, 刘涛, 等. 基于Petri网的软件架构演化波及效应分析[J]. 计算机技术与发展, 2007, 17(12): 99-102.
[53]　王映辉, 张世琨, 刘瑜, 等. 基于可达矩阵的软件体系结构演化波及效应分析[J]. 软件学报, 2004, 15(8): 1107-1115.
[54]　谢仲文，李彤，代飞，等. 基于Petri网的面向动态演化的软件体系结构建模[J]. 计算机应用与软件, 2012(10): 36-39.
[55]　J R Abrial, M K O Lee, D S Neilson, et al. The B-method[C]. Proceedings of the International Symposium of VDM Europe. Berlin, Heidelberg: Springer, 1991: 398-405.
[56]　邹盛荣, 郑国梁. B语言和方法与Z、VDM的比较[J]. 计算机科学, 2002, 29(10): 136-138.
[57]　杨丽丽. 基于B Method的软件建模方法研究[D]. 长春: 东北师范大学, 2012.
[58]　周欣, 魏生民. 基于B语言的UML形式化方法[J]. 计算机工程, 2004, 30(12): 62-64.
[59]　柳西玲. 一种大型系统软件开发方法VDM介绍[J]. 计算机科学, 1986, 13(4): 21-27.
[60]　王新苏, 罗文坚, 毛晨晓, 等. 基于RUP和VDM++的软件形式化开发方法的研究[J]. 计算机工程与应用, 2005, 41(26): 100-103.
[61]　D Garlan. Formal modeling and analysis of software architecture: Components, connectors, and events[C]. Proceedings of the International School on Formal Methods for the Design of Computer, Communication and Software Systems. Berlin, Heidelberg: Springer, 2003: 1-24.
[62]　张昂. 基于CSP的软件演化过程描述及研究[D]. 昆明: 云南大学, 2010.
[63]　祝义, 张永常, 张广泉, 等. UML与Z结合的建模过程及其应用[J]. 计算机科学, 2007, 34(5): 273-276.
[64]　韦银星, 张申生, 曹健. UML类图的形式化及分析[J]. 计算机工程与应用, 2002, 38(10): 5-7.
[65]　张文静. 基于UML和形式化方法的软件体系结构研究与应用[D]. 保定：华北电力大学, 2006.
[66]　李桂, 苏一丹. UML状态图的形式化[J]. 广西大学学报(自然科学版), 2003, 28(4): 318-321.
[67]　J Rumbaugh, I Jacobson, G Booch. Unified Modeling Language Reference Manual[M]. Addison-Wesley Professional, 2010.
[68]　李景峰, 李琰, 陈平. UML序列图的Z形式规范[J]. 西安电子科技大学学报(自然科学版）, 2002, 29(6): 772-776.
[69]　J D’Anjou, S Fairbrother, D Kehn, et al. The Java developer's guide to Eclipse[M]. Addison-Wesley Professional, 2005.
[70]　B A Wichmann , A A Canning , D W R Marsh , et al. Industrial perspective on static analysis[J]. Software Engineering Journal, 2002, 10(2): 69-75.
[71]　N Elleuch, A Khalfallah, S B Ahmed. Software Architecture in Model Driven Architecture[C]. Proceedings of the International Symposium on Computational Intelligence & Intelligent Informatics. Agadir, Morocco: IEEE, 2007.
[72]　张天, 张岩, 于笑丰, 等. 基于MDA的设计模式建模与模型转换[J]. 软件学报, 2008, 19(9): 2203-2217.
[73]　Y Singh, M Sood. Models and Transformations in MDA[C]. Proceedings of the First International Conference on Computational Intelligence. Indore, India: IEEE Computer Society, 2009: 253-258.
[74]　张德芬, 李师贤, 古思山. MDA中的模型转换技术综述[J]. 计算机科学, 2006, 33(10):228-230.
[75]　梁正平, 毋国庆, 肖敬, 等. 基于模型驱动的软件体系结构[J]. 计算机应用研究, 2002, 19(11): 44-46.
[76]　J Poole, D Chang, D Tolbert, et al. Common warehouse metamodel[M]. John Wiley & Sons, 2002.
[77]　H St?rrle. Models of software architecture[J]. Design and Analysis with UML and Petri-nets, Ludwig-Maximilians-Universit at München, 2000.
[78]　Janvlug Unified Modeling Language[EB/OL]. http://en.wikipedia.org/wiki/Unified_Modeling_Language,2018-10-24.
[79]　A Evans , R France, K Lano, et al. Meta-Modelling Semantics of UML[M]. Springer US, 1999.
[80]　A Idani , Y Ledru. Dynamic graphical UML views from formal B specifications[J]. Information and Software Technology, 2006, 48(3): 154-169.
[81]　W Heijstek, T Kuhne, M R V Chaudron. Experimental analysis of textual and graphical representations for software architecture design[C]. Proceedings of the Experimental Software Engineering and Measurement (ESEM). Banff, AB, Canada: IEEE, 2011: 167-176.
[82]　D Soni, R L Nord, C Hofmeister. Software Architecture in Industrial Applications[C]. Proceedings of the International Conference on Software Engineering. Eattle, Washington, USA: IEEE, 1995: 131-138.