极客大学架构师训练营 听课总结 - 架构视图，设计文档 -- 第二课
说明
如何画架构视图，如何写出设计文档
讲课老师 – 首席架构师李智慧
4+1 视图模型
架构视图有很多种，不同的人给不同的架构视图。
架构师不能只用一种视图解决所有问题。
软件开发的本质是什么？如何进行软件架构设计？
备注：4+1架构模型，4+1架构视图 在工业上不常用，了解即可。
4+1 架构视图
软件架构 = {元素， 形式， 关系/约束}
单一的视图无法完整的表达架构，因此需要具备完整的视图集。
- 逻辑视图（Logical View），设计的对象模型。
- 过程视图（Process View），捕捉设计的并发和同步特征。
- 物理视图（Physical View），描述了软件到硬件的映射，反映了部署特性。
- 开发视图（Development View），描述了在开发环境中软件的静态组织结构。
- 场景视图（Scenarios），描述用例场景。
逻辑视图
- 相关方：客户、用户、开发组织管理者。
- 视角：系统的功能元素，以及它们接口，职责，交换。
- 主要元素：系统，子系统，功能模块，子功能模块，接口。
- 用途：开发组织划分，成本/进度的评估。
开发视图
- 相关者： 开发相关人员，测试人员
- 视角： 系统如何开发实现
- 主要元素：描述系统的层，分区，包，框架，系统通用服务，业务通用服务，类和接口，系统平台和相关基础框架。
- 用途：知道开发组织设计和开发实现。
物理视图
- 相关者：系统集成商，系统运维人员。
- 视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置。
- 主要元素：物理节点以及节点的通信。
过程视图
- 相关者：性能优化，开发相关人员。
- 视角：系统运行时线程，进程的情况。
- 主要元素：系统进程，线程以及处理队列等。
场景视图
- 相关者：用户，设计和开发人员。
- 视角：概括了架构上最重要的场景（最典型或者最优风险）及其非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式。
软件建模语言
如何使用UML进行软件架构设计与建模？
重点：表达什么样的设计意图？给什么人看？
使用什么UML图，达成什么样的设计意图？
在这里插入代码片
什么是模型？
模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案，对他们的理解和认识都蕴含在模型中。
通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，就是从领域问题倒计算机系统的映射。
在还没工程师之前，架构师要有系统的抽象，对现实业务的抽象。
需要考虑有哪些模型，哪些模块，哪些类，怎么交互的？
领域问题： 开发的时候，要理解业务。
概念模型：要有抽象能力，想象最终产品的样子。
系统需求：前瞻性地抽象出系统需求。
解决方案：提前列出关键问题的解决方案。
为什么要建造模型？
建造传统模型的目的
- 为了证明某件事物能够工作
- 前提： 建造模型的成本远远低于建造实物的成本
☞ 造飞机
☞ 建高楼
建造软件模型的目的
- 为了与TA人沟通
- 为了保存软件设计的最终成果
- 前提：除非模型比代码更能说明问题
何时、何处画图？
何时画图？
- 讨论、交流时
- 最终设计文档
☞ 只保留少量的、重要的图
☞ 避免涉及过多内容和实现细节
何处画图？
- 白板
- 绘图工具， 如：StarUML、Gliffy Diagrams、Visio、Aastah
- draw.io
UML 简介
什么是UML?
- Unified Modeling Language, 或统一建模语言
- 以图形方式描述软件的概念
可用来描述：
- 某个问题领域
- 构思中的软件设计
- 描述已经完成的软件实现
UML图的分类 - 静态图
静态图 - 通过描述类、对象和数据结构以及它们之间存在的关系，来描述软件要素中不变的逻辑结构。
- 用例图（Use Case Diagrams）
- 对象图（Object Diagrams）
- 类图（Class Diagrams）
- 组件图（Component Diagrams）
- 包图（Package Diagrams）
- 部署图（Deployment Diagrams）
UML图的分类 - 动态图
动态图 - 通过描述执行流程或者实体状态变化的方式，来展示软件实体在执行过程中的变化过程。
- 协作图（Collaboration Diagrams）
- 序列图（Sequence Diagrams）
- 活动图（Activity Diagrams）
- 状态图（State Diagrams）
通用模型元素
可以在图中使用的概念统称为模型元素。模型元素在图中用其相应的视图元素（符号）表示，下图给出了常用的元素符号：类、对象、结点、包和组件等。
模型元素和模型元素之间的连接关系也是模型元素，常见的关系有接口实现（Interface Realization）、继承泛化（Generalization）、依赖（Dependency）、关联（Association）、聚合（Aggregation）和组合（Composition）。这些关系的图示符合如图所示。
- 实现 Interface Realization：接口的实现。
- 继承/泛化 Generalization：表示一般与特殊的关系，即“一般”元素是“特殊”关系的泛化。类上表示继承的关系。
- 依赖 Dependency：表示一个元素以某种方式依赖于另一种元素。一般表示方法内的局部变量，或者参数。
- 关联 Association：连接（connect）模型元素及链接（link）实例。一般表示类的属性。
- 聚合 Aggregation：表示整体与部分的关系。整体的生命周期结束，部分不一定。
- 组合 Composition：表示整体与部分的强关系。整体与部分的生命周期一致。
弱关系：接口实现、依赖、聚合。
强关系：类继承、关联、组合。
用例建模
用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型泳衣的分析，使开发者能够有效地了解用户的需求。
用例模型描述的是外部执行者（Actor）所理解的系统功能。它描述了待开发系统的功能需求。
它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和 UML 的各个模型。
用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在 UML中，构成用例图的主要元素是用例和执行者及其它们之间的联系。
创建用例模型的工作包括：定义系统、确定执行者和用例、描述用例、定义用例间的关系、确认模型。
执行者（Actor）
执行者是指用户在系统中所扮演的角色。执行者在用例图中是用类似人的图形来表示，但执行者可以是人，也可以是一个外界系统。
注意：用例总是由执行者启动的。
如何确定执行者：
- 谁使用系统的主要功能（主执行者）？
- 谁需要从系统获得对日常工作的支持和服务？
- 需要谁维护管理系统的日常运行（副执行者）？
- 系统需要控制哪些硬件设备？
- 系统需要与其它哪些系统交互？
- 谁需要使用系统产生的结果（值）？
用例图描述了系统的功能需求，它是从执行者的角度来理解系统，用于捕获系统的需求，规划和控制项目；描述了系统外部的执行者和系统提供的用例之间的某种联系。
图中还要另外两种类型的连接，即《使用》和《扩展》关系，是两种不同形式的泛化关系。
《Use》表示一个用例使用另一个用例。
《Extend》通过向被扩展的用例添加动作来扩展用例。
例 项目与资源管理系统的 Use case 图
系统的主要功能是：项目管理，资源管理和系统管理。项目管理包括项目的增加、删除、更新。资源管理包括对资源和技能的添加、删除和更新。系统管理包括系统的启动和关闭，数据的存储和备份等功能。
- 分析确定系统的执行者（角色）
☞ 项目管理员、资源管理者、系统管理员、备份数据系统。 - 确定用例
☞ 项目管理，资源管理和系统管理。 - 对用例进行分解，画出下层的 Use Case 图
☞ 对上层的用例进行分解，并将执行者分配到各层次的 Use Case 图中。
静态建模
任何建模语言都以静态建模机制为基础，标准建模语言 UML 也不例外。所谓静态建模是指对象之间通过属性互相联系，而这些关系不随时间而转移。
类和对象的建模，是 UML 建模的基础。 UML 的静态建模机制包括：
- 用例图（Use Case Diagram）
- 类图（Class Diagram）
- 对象图（Object Diagram）
- 包图（Package Diagram）
- 组件图（Component Diagram）
- 部署图（Deployment Diagram）
类与对象
面向对象的开发方法的基本任务是建立对象模型，是软件系统开发的基础。UML 中的类图（Class Diagram）与对象图（Object Diagram）表达了对象模型的静态结构，能够有效地建立专业领域的计算机系统对象模型。
属性（Attribute）：属性用来描述类的特征，表示需要处理的数据。
属性的定义： visibility attribute-name :type = initial-value {property-string}
可见性 属性名： 类型=缺省值{约束特性}
其中：可见性（visibility）表示该属性对类外的元素是否可见。
分为：
- public (+) 公有的。
- private (-) 私有的。
- protected (#) 受保护的。
- 默认 (未声明)
操作
对数据的具体处理方法的描述则放在操作部分，操作说明了该类能做些什么工作。操作通常为函数，它是类的一个组成部分，只能作用于该类的对象说。
操作定义：
visibility operating-name(parameter-list): return-type {property-string}
可见性 操作名(参数表)； 返回类型{约束特性}
一个使用 Visio 绘制的类图
包图
一个最古老的软件方法问题是：怎样讲大系统拆分成小系统。解决该问题的思路之一是将许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合。UML 中这种分组机制叫包(Package)。引入包是为了降低系统的复杂性。
动态建模
动态模型主要描述系统的动态行为和控制结构。动态行为包括系统中对象生存期内可能的状态以及事件发生时状态的转移，对象之间动态合作关系，显示对象之间的交互过程以及交互顺序，同时描述了满足用例要求所进行的活动以及活动间的约束关系。
在动态模型中，对象间的交互是通过对象间消息的传递来完成的。对象通过相互间的通信（消息传递）进行合作，并在其生命周期中根据通信的结果不断改变自身的状态。
动态模型
动态模型主要描述系统的动态行为和控制结构。
包括四类图：状态图、活动图、时序图、合作图。
- 状态图（State Diagram）：状态图用来描述对象，子系统，系统的生命周期。
- 活动图（Activity Diagram）：着重描述操作视线中完成的工作以及用例实例或对象中的活动，活动图是状态图的一个变种。
- 时序图（Sequence Diagram）：是一种交互图，主要描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例的行为。
- 合作图（Collaboration Diagram）：用于描述相互合作的对象间的交互关系。
UML 中的消息
- 简单消息（Simple）：表示控制流，描述控制如何从一个对象传递到另一个对象，但不描述通信的细节。
- 同步消息（Synchronous）：是一种嵌套的控制流，用操作调用实现。操作的执行者要到消息响应操作执行完并会送一个简单的消息后，再继续执行。注意：方法间的调用都是同步消息，异步处理是方法内的处理机制。
- 异步消息（Asynchronous）：是一种异步的控制流，消息的发送者在消息发送后就继续执行，不等待消息的处理。
时序图
时序图（Sequence Diagram）用来描述对象之间动态的交互行为，着重体现对象间消息传递的时间顺序。
时序图存在两个轴
- 水平轴表示一组对象
- 垂直轴表示时间
时序图中的对象用一个带有垂直虚线的矩形框表示，并标有对象名和类名。垂直虚线是对象的生命线，用于表示在某段时间内对象是存在的。
对象间的通信通过再对象的生命线之间消息来表示，消息的箭头类型指明消息的类型。
顺序图的形式
有两种使用顺序图的方式：一般格式和实例格式。
实例格式详细描述一次可能的交互。没有任何条件和分支或循环，它仅仅显示选定情节（场景）的交互。
而一般格式则描述所有的情节。因此，包括了分支，条件和循环。
活动图
活动图（Activity Diagram）的应用非常广泛，它既可用来描述操作（类的方法）的行为，也可以描述用例和对象内部的工作过程，并可用于表示并行过程。
活动图描述了系统中各种活动的执行的顺序。刻画一个方法中所要进行的各项活动的执行流程。
活动图中一个活动结束后将进入下一个活动（在状态图中状态的变迁可能需要事件的触发）。
活动图的模型元素
构成活动图的模型元素有：活动件、转移、对象、信号、泳道等。
活动：
- 是构成活动图的核心元素，是具有内部动作的状态，由隐含的事件触发活动的转移。
- 活动的解释依赖于作图的目的和抽象层次，在概念层描述中，活动表示要完成的一些任务；在说明层和实现层，活动表示类中的方法。
- 活动用圆角框表示，标注活动名。
- 模型元素有：活动、转移、对象、信号、泳道等。
- 活动还有其它的图标符号：初始状态、终止状态、判断、同步线。
转移
- 转移描述活动之间的关系，描述由于隐含事件引起的活动变迁，即转移可以连接各活动及特殊活动（初始状态、终止状态、判断、同步线）。
- 转移用带箭头的直线表示，可标注执行该转移的条件，无标注表示顺序执行。
泳道
- 泳道进一步描述完成活动的对象，并聚合一组活动。活动图是另一种描述交互的方式，描述采取何种动作，做什么（对象状态转移），何时发生（动作序列），以及在何处发生（泳道）。
- 泳道也是一种分组机制。
对象流
- 活动图中可以出现对象，对象作为活动的输入/输出，用虚箭头表示。
控制图符
- 活动图中可发送和接收信号，发送符号对应于与转移联系在一起的发送断句。接收符号也同转移联系在一起。
状态图
状态图（State Diagram）用来描述一个特定对象的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的转移。
状态
所有对象都具有状态，状态是对象执行了一系列活动的结果。当某个事件发生后，对象的状态将发生变化。状态图中定义的状态有：
- 初态 - 状态图的起始点，一个状态图只能有一个初态。
- 终态 - 是状态图的终点，而终态则可以有多个。
- 中间状态 - 可包括三个区域：名字域、状态变量与活动域。
- 复合状态 - 可以进一步细化的状态称作复合状态。
合作图(不常用，相当于没有时间顺序的时序图)
合作图（Collaboration Diagram），也称为协作图，用于描述相互合作的对象间的交互关系和链接（Link）关系。虽然时序图和合作图都用来描述对象间的交互关系，但侧重点不一样。时序图着重体现交互的时间顺序，合作图则着重体现交互对象间的静态链接关系
实现模型
实现模型描述了系统实现时的一些特性，又称为物理体系结构建模。包括源代码的静态结构和运行时刻的实现结构。
实现模型包括：
- 组件图（Component Diagram）显示代码本身的逻辑结构，它描述系统中存在的软件构件以及它们之间的依赖关系。
- 部署图（Deployment Diagram）描述了系统中硬件和软件的物理配置情况和系统体系结构。显示系统运行时刻的结构，部署图中的简单节点是指实际的物理设备以及在该接点上运行构件或对象。部署图还描述节点之间的链接以及通信类型。
组件图
组件（Component）：系统中遵从一组接口且提供其实现的物理的、可替换的部分。对系统的物理方面建模时，它是一个重要的构造块。
组件可以看作包与类对应的物理代码模块，逻辑上与包，类对应，实际上是一个文件，可以有下列几种类型的构件：
- 源代码构件
- 二进制构件
- 可执行构件
组件之间的依赖关系是指结构之间在编译，连接或执行时的依赖关系。用虚线箭头表示组件图符：
部署图
部署图用来描述系统硬件的物理拓扑结构以及在此机构上执行的软件，即系统运行时刻的结构。部署图可以显示计算机结点的拓扑结构和通信路径，结点上执行的组件，特别对于分布式系统，部署图可以清楚的描述系统中硬件设备的配置，通信以及在各硬件设备上各种软构建和对象的配置。因此，部署图是描述任何基于计算机的应用系统的物理配置或逻辑配置的有力工具，部署图的元素有结点和连接。
部署图的结点代表某种计算机，通常是某种硬件。同时结点还包括在其上运行的软组件，软件组件代表可执行的物理代码模块。如一个可执行程序。结点的图符是一个立方体。
保险系统的部署图
部署图个结点之间进行交互的通信路径称为连接，连接表示系统中的结点存在着联系，用结点之间的连线表示连接，在连接的连线上标注通信类型。
推荐书籍：
UML 精粹 - Martin Fowler
UML Distilled - Martin Fowler
注意：以上信息如有侵权，请联系作者删除，谢谢。