【系统架构设计师】六、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个视图。
  

6.4.2 逻辑结构

逻辑架构主要支持功能性需求，即在为用户提供服务方面系统所应该提供的功能。

6.4.3 进程架构

进程架构考虑一些非功能性的需求，如性能和可用性，它解决并发性、分布性、系统完整性、容错性的问题，以及逻辑视图的主要抽象如何于进程结构相配合在一起。

6.4.4 开发架构

开发架构关注软件开发环境下实际模块的组织。软件打包成小的程序块（程序库或子系统），它们可以由一位或几位开发人员来开发。子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。

6.4.5 物理架构

物理架构主要关注系统非功能性的需求，如可用性、可靠性(容错性)、性能（吞吐量）和伸缩性。软件在计算机网络或处理节点上运行，被识别为各种元素（网络、过程、任务和对象），需要被映射至不同节点；软件至节点的映射需要高度的灵活性和对源代码产生最小的影响。

6.4.6 场景

4种视图的元素通过数据比较少的一些重要场景（更常见的事用例）进行无缝协同工作，我们为场景描述响应的脚本（对象之间和过程之间的交互序列）。在某种意义上，场景是最重要的需求抽象。

6.4.7 迭代过程

在进行文档化时，提倡一种更具有迭代性质的方法------架构先被原型化、测试、估量、分析，然后在一系列的迭代过程中被细化。

情景驱动的方法：系统大多数关键的功能以场景（或use cases）的形式被捕获。关键意味着：最重要的功能，系统存在的理由，或使用频率最高的功能，或体现了必须减轻的一些重要技术风险。

1）开发阶段

• 基于风险和重要性为某次迭代选择一些场景。
• 形成"稻草人式的架构"
• 将所发现的架构元素分布到四个蓝图中
• 实施、测试、度量该架构
• 捕获经验教训

2）循环阶段

• 下一个迭代过程开始进行
• 重新评估风险
• 扩展考虑的场景选择板
• 选择能减轻风险或提高结构覆盖的额外的少量场景
• 在原先的架构中描述这些场景
• 发现额外的架构元素，或必要的重要架构变更
• 更新4个主要视图（逻辑、进程、开发和物理视图）
• 根据变更修订现有的场景
• 升级实现工具（架构原型）来支持新的、扩展了的场景集合
• 测试
• 评审5个视图来检测简洁性、可重用性和通用性的潜在问题
• 更新设计准则和基本原理
• 终止循环

为了实际的系统，初始的架构原型需要进行演进。较好的情况是经过两次或三次迭代之后，结构变得稳定：主要抽象都已被找到；子系统和过程都已经完成，以及所有的接口都已经实现。

接下来则是软件设计的范畴，这个阶段可能也会用到相似的方法和过程。