【系统架构设计师】六、UML建模与架构文档化

在20世纪70年代，陆续出现了面向对象的建模方法，UML（统一建模语言）的出现，以融合了多种面向对象建模方法，简介的图形和符号，直观的表示和强大的表示能力，得到了工业界与学术界认可。它使用统一的表示法，使不同知识背景的领域专家、系统分析和开发人员以及用户可以方面地交流。

6.1 UML现状和发展

6.1.1 UML起源

1995年，Gray Booch和Jances Rumbaugh将他们面向对象建模方法统一为Unified Mathod V0.8；
1996年，Ivar Jacobson加入其中，共同将该方法统一为二义性较少的UML 0.9（这三位杰出的方法学家被称为“三友（Three Amigos）”）；
1997年1月，伙伴组织向OMG提交了最初的提案UML 1.0；
1997年9月，提出了最终提案UML 1.1；OMG特许成立UML修订任务组（Revision Task Forces，RTF）；
1997年11月，UML 1.1被OMG正式采纳为对象建模标准；
RTF提交了第一个主要产品编辑版本UML1.2：改编了规范，使之与其他OMG规范更为一致；
RTF提交了第二个主要产品技术版本UML1.3：修正和改善了UML1.1的遗留问题，并矫正了已发现的小错误；
1996年6月，RTF提交UML1.3最终报告并或批准；

6.1.2 UML体系结构演变

UML是用元模型来描述的，元模型是4层元模型体系结构模式中的一层。此模式的其他层次分别是元-元模型层、模型层和用户对象层。其中元模型层是由元-元模型层导出，UML的元-元模型层在OMG MOF的元-元模型中定义，而UML元模型中的元类是MOF元-元类的实例。

在元模型层，UML元模型又被分解为三个逻辑子包：基础包、行为元素包和模型管理包。

其中基础包由核心、扩展机制和数据类型三个子包构成，它是描述模型静态结构的语言底层结构，支持类图、对象图、构件图和部署图等结构图；
行为元素包是描述模型动态行为的语言上层结构，支持不同的行为图，包括用例图、顺序图、协作图、状态图和活动图；
模型管理包则定义了对模型元素进行分组和管理的语义，它描述了几种分组结构，包括包、模型、子系统。
行为元素包和模型管理包都依赖基础包。

UML 1.3是建模语言规范第一个成熟的发布，解决了UML1.1的遗留问题，也为UML2.0确立了路标。

6.1.3 UML的应用和未来

UML是在多种面向对象建模方法的基础上发展起来的建模语言，主要用于软件密集型系统的建模。OMG的采纳和大公司的支持把它推上了实际上的工业标准地位。它被广泛地用于应用领域和多种类型的系统建模，如管理信息系统、通信和控制系统、嵌入式实时系统、分布式系统和系统软件等。近几年还被运用于软件再生工程、质量管理、过程管理和配置管理等方面。还被应用于非软件系统，例如硬件设计、业务处理流程、企业或事业单位的结构与行为建模。

6.2 UML基础

6.2.1 概述

UML通过图形化的表示机制从多个侧面对系统的分析和设计模型进行刻画。它共定义了10种视图，并将其分为了4类：

用例图（use case diagram）
定义1：用例是对一个活动者（actor）使用系统的一项功能时锁进行的交互过程的一个文字描述序列；
定义2：用例是系统、子系统或类和外部的参与者（actor）交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。
编写用例涉及到的元素：
- 参与者：图标（Icom）形式、标签（Label）形式、修饰（Decoration）形式
- 用例间关系：用例与参与者的关联（association）、用例之间的泛化（generalization）、包含（include）、扩展（extend）等关系
- 用例图：显示一组用例、参与者以及它们之间关系的图
- 用例的描述：采用自然语言描述参与者与系统进行交互时双方的行为，不追求形式化的语言表达。
静态图
- 类图（class diagram）：
  类是具有相似结构、行为和关系的一组对象的抽象。在UML中类表示为划分为三个格子的长方形。
  一般来说，类之间的关系有关联、聚集、组合、泛化和依赖等。
  - 关联（association）：模型元素间的一种语义，它们是对共同的结构特性、行为特型、关系和语义的链（link）的描述。
  - 聚集（aggregation）：是一种特殊的关联。聚集表示类之间整体与部分的关系。在系统需求描述中的“包含”、“组成”、“分为…部分”等通常意味着存在聚集关系。
  - 组合（composition）：是一种也是的聚集。表示的也是类之间的整体与部分的关系，但组合关系中整体与部分具有同样的生存期。
  - 泛化（generalization）：定义了一般和特殊元素之间关系。从面向对象程序设计语言角度来说，类与类之间的泛化关系就是平常所说的类与类之间的继承关系。
  - 依赖（dependency）：如果元素（类）X定义修改会影响到元素（类）Y的定义，则我们认为元素（类）Y依赖与元素（类）X。
- 对象图（object diagram）：
- 包图（package diagram）：
行为图
- 交互图（interactive diagram）：用来描述对象之间以及对象与参与者之间的动态协作关系以及协作过程中行为次序的图形文档。交互图包括顺序图和协作图两种形式：顺序图着重描述对象按照时间顺序的消息交换，协作图着重描述系统程序如何协同工作。
  - 顺序图（sequence diagram，也称时序图）：
    定义：顺序图时显示对象之间交互的图，这些对象是按时间顺序排列的。
    顺序图中显示的是参与交互的对象及对象之间消息交互的顺序。
  - 协作图（collaboration diagram）：
    定义：协作图是用于描述系统的行为是如何由系统的成分协作实现的图，协作图中包括的建模元素有对象、消息、链等。
- 状态图（statechart diagram）：
  状态图主要用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件（event），以及因状态转移而伴随的动作（action）。
  一般可以用状态机地一个对象的生命周期建模，状态图是用来显示状态机的，重点在于描述状态之间的控制流。
- 活动图（active diagram）：
  活动图可以用于描述系统的工作流程和并发行为，活动图其实可以看作状态图的特殊形式，活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的转移可能需要事件的触发）。
  活动图的几个概念：
  - 活动（activity）：表示的是某个流程中的任务执行，可以表示某算法过程中语句的执行；
  - 泳道（swimlane）：活动图中的区域划分，根据每个活动的职责对所有活动进行划分，每个泳道代表一个责任区。
  - 分支（branch）：在活动图中，对于同一个触发事件，可以根据不同的警戒条件转向不同的活动，每个可能的转移就是一个分支。
  - 分叉（fork）和汇合（join）：如果要表示系统或对象中的并发行为，可以使用分叉合汇合。分叉表示两个或多个控制流经过分叉后，这些控制流并发进行；汇合正好与分叉相反。
  - 对象流：活动图中对象流表示活动和对象之间的关系，如一个活动创建对象（作为活动输出）或使用对象（作为活动的输入）等。
实现图
- 构件图（component diagram）：
  构建是系统中遵从一组接口且提供其实现的物理的、可替换的部分。构建图则显示一组构建以及它们之间的相互关系，包含编译、链接和执行时构件之间的依赖关系。
- 部署图（deployment diagram）：
  部署图也称为配置图、实施图，它可以用来显示系统中计算节点的拓扑结构和通信路径与结点上运行的软构建等。一个系统模型只有一个部署图，部署图常用于帮助理解分布式系统。

6.3 基于UML的软件开发过程

6.3.1 开发过程

UML是独立于软件开发过程的，即UML能够在几乎任何一种软件开发过程种使用。迭代的渐进式软件开发过程包含4个阶段，即初启、细化、构建和部署。

初启：初步的可行性分析和经济效益分析；
细化：初步的需求分析、初步的高层设、部分的详细设计、部分的原型构造；需用使用到UML语言机制：
- 描述用户需求的用例及用例图
- 表示领域概念模型的类图
- 表示业务流程处理的活动图
- 表示系统高层结构的包图
- 表示用例内部实现过程的交互图
构建：通过一系列的迭代完成对所有用例的软件实现工作，在每次迭代中实现一部分用例，通过迭代方式可以让用户及早参与对已实现用例的实际评价，并提出改进意见；每个迭代过程由针对用例的分析、设计、编码、测试和集成5个子阶段构成；需要使用到的UML语言机制：
- 用例和用例图
- 类图
- 交互图
- 状态图
- 活动图
- 包图
- 构件图
- 部署图
部署：将构建阶段获取的软件系统部署到用户实际工作环境中试运行。

6.3.2 基于UML的需求分析

利用用例及用例图表示需求；利用包图及类图表示目标软件系统的总体框架结构。
基于UML的需求分析过程大致可分为以下步骤：

生成用例
用活动图表示用例
生成用例图
建立顶层架构
- UML包图
- 顶层架构设计：流程处理模式、客户服务器模式等
建立概念模型

6.3.3 面对对象的设计方法

面向对象的软件设计过程：

设计用例实现方案
- 提取边界类、实体类和控制类
- 构造交互图
- 根据交互图精华类图
设计技术支撑方案
设计用户界面
精化设计模型

6.4 系统架构文档化

6.4.1 模型概述

软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而系统主要功能和性能要求，并满足其他非功能性需求，如可靠性、伸缩性、可移植性和可用性。
软件架构={元素，形式，关系/约束}
软件架构涉及到抽象、分解和组合、风格和美学。我们可以由多个视图或视角组成的模型来描述它。
为了最终处理大型的、富有挑战性的架构，该模型包含5个主要的视图：

逻辑视图（logical view）：设计的对象模型
过程视图（process view）：捕捉设计的并发和同步特征
物理视图（physical view）：描述了软件到硬件的映射，反映了分布式特性
开发视图（development view）：描述了在开发环境中软件的静态组织结构
架构的描述，即所做的各种决定，可以围绕着这4个视图来组织，然后由一些用例（use case）或场景（scenarios）来说明，从而形成了地5个视图。