[架构之路-133]-《软考-系统架构设计师》-软件工程-3-软件系统的建模与UML

前言：

第三章 软件工程

3.3 软件系统的建模

软件分析建模体现了软件设计的思想，在系统需求和系统实现之间架起了一座桥梁。

软件工程师按照设计人员建立的模型，开发出符合设计目标的软件系统，而且软件的维护，改进也基于软件分析模型。

随着软件工程理论研究的深入和软件技术的不断发展，软件分析建模也日益完善。尽管不同的软件分析建模平台的建模工作存在差异，但大体可以把软件分析建模分成3类，即业务建模、数据建模和应用程序建模。

3.4 UML

3.4.1 概述

统一建模语言(Unified Modeling Language，UML)是一种为面向对象系统的产品进行说明、可视化和编制文档的一种标准语言，是非专利的第三代建模和规约语言。UML是面向对象设计的建模工具，独立于任何具体程序设计语言。

UML作为一种统一的软件建模语言具有广泛的建模能力。UML是在消化、吸收、提炼至今存在的所有软件建模语言的基础上提出的，集百家之所长，它是软件建模语言的集大成者。UML还突破了软件的限制，广泛吸收了其他领域的建模方法，并根据建模的一般原理，结合了软件的特点，因此具有坚实的理论基础和广泛性。UML不仅可以用于软件建模，还可以用于其他领域的建模工作。 [1]

UML立足于对事物的实体、属性、关系、结构、状态和动态变化过程的全程描述和反映。UML可以从不同角度描述人们所观察到的软件视图，也可以描述在不同开发阶段中的软件的形态。UML可以建立需求模型、逻辑模型、设计模型和实现模型等，但UML在建立领域模型方面存在不足，需要进行补充。

作为一种建模语言，UML有严格的语法和语义规范。UML建立在元模型理论基础上，包括4层元模型结构，分别是基元模型、元模型、模型和用户对象。4层结构层层抽象，下一层是上一层的实例。UML中的所有概念和要素均有严格的语义规范。 大部分使用者不需要关心这些语法和语义规范。

UML采用一组图形符号来描述软件模型，这些图形符号具有简单、直观和规范的特点，开发人员学习和掌握起来比较简单。所描述的软件模型，可以直观地理解和阅读，由于具有规范性，所以能够保证模型的准确、一致。

3.4.2 UML视图概述

3.4.2.1 动静分类

截止UML2.0一共有13种图形（UML1.5定义了9种，2.0增加了4种）。分别是：用例图、类图、对象图、状态图、活动图、顺序图、协作图、构件图、部署图9种，包图、组合结构图、交互概览图3种。

• 用例图：从用户角度描述系统功能。

• 类图：描述系统中类的静态结构。

• 对象图：系统中的多个对象在某一时刻的状态。

• 状态图：是描述状态到状态控制流，常用于动态特性建模

• 活动图：描述了业务实现用例的工作流程

• 顺序图：对象之间的动态合作关系，强调对象发送消息的顺序，同时显示对象之间的交互

• 协作图：描述对象之间的协助关系

• 构件图：一种特殊的UML图来描述系统的静态实现视图

• 部署图：定义系统中软硬件的物理体系结构

• 包图：对构成系统的模型元素进行分组整理的图

• 组合结构图：表示类或者构建内部结构的图

• 交互概览图：用活动图来表示多个交互之间的控制关系的图

3.4.2.2 UML系统开发中有三个主要的模型：

功能模型：从用户的角度展示系统的功能，包括用例图。

对象模型（静态）：采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类别图、对象图。

动态模型（动态）：展现系统的动作行为。包括序列图，活动图，状态图。

3.4.2.3 UML视图

3.4.3.4 分阶段9种视图

3.4.3.5 极简的UML 4+1视图

3.4.3 UML视图详解

3.4.3.1 用例图：从用户角度描述系统功能。

用例图是编写需求说明时经常用到的需求表达方式，用于向开发、测试同事说明需求中用户与系统功能单元之间的关系。

用例图的三大组成元素：参与者、用例、参与者与用例之间的关系。

参与者与用例之间的关系（4种）：关联、归纳（泛化）、包含、拓展和依赖。

用例图主要回答了两个基本问题（用于需求分析阶段）

• 1、是谁用软件。

• 2、软件的功能。

从用户的角度描述了系统的功能，并指出各个功能的执行者，强调用户的使用者，系统为执行者完成哪些功能。

用例图中包含以下三种关系：

• 包含关系使用符号《include》，想要查看订单列表，前提是需要先登录。

• 扩展关系使用符号《extend》，基于查询订单列表的功能，可以增加一个导出数据的功能

• 泛化关系，子用例继承父用例所有结构、行为和关系。

3.4.3.2 类图：描述系统中类的静态结构。

用户根据用例图抽象成类，描述类的内部结构和类与类之间的关系，是一种静态结构图。

在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)。

各种关系的强弱顺序： 泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖

（1）【泛化关系】：

是一种继承关系，表示一般与特殊的关系，它指定了子类如何继承父类的所有特征和行为。

例如：老虎是动物的一种，即有老虎的特性也有动物的共性。　　　　

（2）【实现关系】：

是一种类与接口的关系，表示类是接口所有特征和行为的实现。

（3）【关联关系】：

是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

【代码体现】：一个类是另一个类的成员变量

（4）【聚合关系】：

是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。

聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

【代码体现】：类的成员变量通过指针指向另一个类。

　（5）【组合关系】

是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门。

　组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

　　　　【代码体现】：类的成员变量，直接是另一个类

　　　　【箭头及指向】：带实心菱形的实线，菱形指向整体

　（6）【依赖关系】：

是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖.

【代码表现】：局部变量、方法的参数或者对静态方法调用了另一个类。

【箭头及指向】：带箭头的虚线，指向被使用者

　（7）各种类图关系

3.4.3.3 对象图：系统中的多个对象在某一时刻的状态。

用于描述某一时刻的一组对象及它们之间的关系。

对象图的组成元素：对象、链。

对象图经常被拿来和类图做比较。对象图可以视作类图的实例，用来表达各个对象在某一时刻的状态

3.4.3.4 状态图：是描述状态到状态控制流，常用于动态特性建模

• 概念】状态机图对一个单独对象的行为建模，指明对象在它的整个生命周期里，响应不同事件时，执行相关事件的顺序。

• 【目的】用来表示指定对象，在整个生命周期，响应不同事件的不同状态。

状态机图描述一个对象在其生命周期中的各种状态以及状态的转换。

状态机主要由状态、转换、事件、动作、活动5部分组成。

顺序图、通信图：描述多个对象间的交互。 状态机图：描述单个对象的状态及引起状态变化的原因。

用一个简化的图来表示三者的差别就是：

3.4.3.5 活动图：描述了业务实现用例的工作流程

活动图描述活动的顺序，展现从一个活动到另一个活动的控制流，它本质上是一种流程图。

组成元素：起点、终点、活动名称、判断条件、分支与合并、接收信号、发送信号、泳道（其实和流程图很相像）

• 【概念】描述了具体业务用例的实现流程。

• 【目的】用来表示用例实现的工作流程。

图中描述了，门在其生命周期内所经历的状态。

3.4.3.6 顺序图：对象之间的动态合作关系，强调对象发送消息的顺序，同时显示对象之间的交互

顺序图，又名序列图、时序图。用于描述对象之间的传递消息的时间顺序（包括发送消息、接收消息、处理消息、返回消息等）。

顺序图的组成元素：对象、生命线、消息，其中消息又分为同步消息、异步消息、返回消息、自关联消息。

• 【概念】序列图根据时间序列展示对象如何进行协作。它展示了在用例的特定场景中，对象如何与其他对象交互。

• 【目的】通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。

图中展示的是支付宝条码支付场景的序列图。

其中，loop是循环，alt是选择，序列图的其他关系这里就不介绍了。

3.4.3.7 协作图/通信图：描述对象之间的协助关系

通信图描述的是对象和对象之间的调用关系，体现的是一种组织关系。

通信图组成元素：对象、链接、消息。

通信图和时序图有点类似。但时序图着重于时间顺序，而通信图则关注的是对象之间的组织关系，通信图中的时间顺序可以从消息序号中获得。在语义上这两个图是等价的可以互相转换而不会丢失信息。

• 【概念】描述了收发消息的对象的组织关系，强调对象之间的合作关系而不是时间顺序。

• 【目的】用来显示不同对象的关系。

协作图：是压缩后的时序图，对对象为中心的时序图。

3.4.3.8 构件图/组件图：一种特殊的UML图来描述系统的静态实现视图

• 【概念】描绘了系统中组件提供的、需要的接口、端口等，以及它们之间的关系。

• 【目的】用来展示各个组件之间的依赖关系。

订单系统组件依赖于客户资源库和库存系统组件。中间的虚线箭头表示依赖关系。另外两个符号，表示组件连接器，一个提供接口，一个需要接口。

3.4.3.9 部署图：定义系统中软硬件的物理体系结构

• 【概念】描述了系统内部的软件如何分布在不同的节点上。

• 【目的】用来表示软件和硬件的映射关系。

部署图是用来显示系统中软件和硬件的物理架构。

使用部署图不仅可以显示运行时系统的结构，还能够传达构成应用程序的硬件和软件元素的配置和部署方式。

部署图的组成元素：结点、构件（因此部署图也经常和构件图一起使用）、接口、连接。

3.4.3.10 包图：对构成系统的模型元素进行分组整理的图

包图通常用于描述系统的逻辑架构——层、子系统、包等。

层可以建模为UML包。UML包用一大一小两个矩形组合而成。如果内部显示了其成员，则包名称标在上面的小矩形内，否则可以标在包内。

包拥有的元素：类、接口、组件、节点、协作、用例、图以及其他包。包的可见性用来控制包外界的元素对包内元素的可访问权限。这种可见性它分为3种，即公有访问、保护访问和私有访问。

包之间可以有两种关系：依赖、泛化。

3.4.3.11 组合结构图：表示类或者构建内部结构的图

3.4.3.12 交互概览图：用活动图来表示多个交互之间的控制关系的图