软件架构

是有关软件整体结构与组件的抽象的描述，用于指导软件系统各方面的设计。

4+1架构视图

软件架构={元素， 形式， 关系/约束}

单一的视图无法完整的表达架构，因此需要具备完整的视图集。

• 逻辑视图（Logical View）, 设计的对象模型。
• 过程视图（Process View）, 捕捉设计的并发和同步特征。
• 物理视图（Physical View）, 描述了软件到硬件的映射，反应了部署特性。
• 开发视图（Development View）, 描述了在开发环境中软件的静态组织结构。
• 场景视图（Scenarios）, 描述用例场景。

逻辑视图

相关方：客户，用户，开发组织管理者。

视角：系统的功能元素，以及他们接口，职责，交互。

主要元素：系统，子系统，功能模块，子功能模块，接口。

用途：开发组织划分，成本/进度的评估。

开发视图

相关者：开发相关人员，测试人员。

视角：系统如何开发实现。

主要元素：描述系统的层、分区、包、框架、系统通用服务、业务通用服务、类和接口、系统平台和相关基础框架。

用途：指导开发组织设计和开发实现。

物理视图

相关者：系统集成商，系统运维人员。

视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置。

主要元素：物理节点以及节点的通信。

过程视图

相关者：性能优化，开发相关人员。

视角：系统运行时线程、进程的情况。

主要元素：系统进程、线程以及处理队列等。

场景视图

相关者：用户、设计和开发人员。

视角：概括了架构上最重要的场景（最典型或者最有风险）及其非功能性需求，通过这些场景的视线，阐明了架构的广度或众多架构元素运行的方式。

软件建模

什么是模型？

模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案，对他们的理解和认识都蕴涵在模型中。通常，开发一个计算机系统是为了解决某个领域待定问题，问题的求解过程，就是从领域问题到计算机系统的映射。

为什么要建造模型？

建造传统模型的目的：

• 为了证明某件事物能否工作
• 前提：建造模型的成本远远低于建造实物的成本

建造软件模型的目的：

• 为了与它人沟通
• 为了保存软件设计的最终成果
• 前提：除非模型比代码更说问题

何时、何处画图？

何时画图？

• 讨论、交流时
• 最终设计文档
  • 只保留少量的、重要的图
  • 避免涉及过多内容和实现细节

何处画图？

• 白板
• 绘图工具，如：Visio、Aastah、draw.io

UML简介

什么是UML?

• Unified Modeling Language, 或统一建模语言
• 以图形方式描述软件的概念

UML可用来描述：

• 某个问题领域
• 构思中的软件设计
• 描述已经完成的软件实现

UML图的分类

静态图

通过描述类、对象和数据结构以及他们之间存在的关系，来描述软件要素中不变的逻辑结构。

任何建模语言都以静态建模机制为基础，标准建模语言UML也不例外。所谓静态建模是指对象之间通过属性互相联系，而这些关系不随时间而转移。

类和对象的建模，是UML建模的基础。UML的静态建模机制包括：

• 用例图（Use Case Diagrams）
• 对象图（Object Diagrams）
• 类图（Class Diagrams）
• 组件图（Component Diagrams）
• 包图（Package Diagrams）
• 部署图（Deployment Diagrams）

动态图

通过描绘执行流程或者实体状态变化的方式，来展示软件实体在执行过程中的变化过程。

动态模型主要描述系统的动态行为和控制结构。动态行为包括系统中对象生存期内可能的状态以及事件发生时状态的转移，对象之间动态合作关系，显示对象之间的交互过程以及交互顺序，同时描述了为满足用例要求所进行的活动以及活动间的约束关系。

在动态模型中，对象间的交互是通过对象间消息的传递来完成的。对象通过互相间的通信（消息传递）进行合作，并在其生命周期中根据通信的结果不断改变自身的状态。

• 协作图（Collaboration Diagrams）：用于描述互相合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系。
• 序列图（Sequence Diagrams）：是一种交互图，主要描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例的行为。
• 活动图（Activity Diagrams）：着重描述操作实现中完成的工作以及用例实例或对象中的活动，活动图是状态图的一个变种。
• 状态图（State Diagrams）：状态图用来描述对象、子系统、系统的生命周期。

通用模型元素

可以在图中使用的概念统称为模型元素。模型元素在图中用其相应的视图元素（符号）表示，下图给出了常用的元素符号：类、对象、结点、包和组件等。

模型元素与模型元素之间的连接关系也是模型元素，常见的关系有 关联（association）、泛化（generalization）、依赖（dependency）和聚合（aggregation）。这些关系的图示符号如图所示。

关联：连接（connect）模型元素及链接(link)实例。

依赖：表示一个元素以某种方式依赖于另一种元素。

泛化：表示一般与特殊的关系，即 ”一般” 元素是 “特殊” 关系的泛化。

聚合：表示整体与部分的关系。

用例建模

用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例的分析，使开发者能够有效地了解用户的需求。

用例模型描述的是外部执行者（Actor）所理解的系统功能。它描述了待开发系统的功能需求。它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML的各个模型。

用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在UML中，构成用例图的主要元素是用例和执行者及其它们之间的联系。

创建用例模型的工作包括：定义系统、确定执行者和用例、描述用例、定义用例间的关系、确认模型。

执行者（Actor）

执行者是指用户在系统中所扮演的角色。执行者在用例图中是用类似人的图形来表示，但执行者可以是人，也可以是一个外界系统。

注意：用例总是由执行者启动的。

如何确定执行者：

1. 谁使用系统的主要功能（住执行者）？
2. 谁需要从系统获得对日常工作的支持和服务？
3. 需要谁维护管理系统的日常运行（副执行者）？
4. 系统需要控制哪些硬件设备？
5. 系统需要与其它哪些系统交互？
6. 谁需要使用系统产生的结果（值）？

用例图描述了系统的功能需求，它是从执行者的角度来理解系统，用于捕获系统的需求，规划和控制项目；描述了系统外部的执行者与系统提供的用例之间的某种联系。

图中还有另外两种类型的连接，即《使用》和《扩展》关系，是两种不同形式的泛化关系。

《Use》表示一个用例使用另一个用例。

《Extend》通过向被扩展的用例添加动作来扩展用例。

例 项目与资源管理系统的Use case图

系统的主要功能是：项目管理，资源管理和系统管理。项目管理包括项目的增加、删除、更新。资源管理包括对资源和技能的添加、删除和更新。系统管理包括系统的启动和关闭，数据的存储和备份等功能。

• 分析确定系统的执行者（角色）
  • 项目管理员、资源管理员、系统管理员、备份数据系统。
• 确定用例
  • 项目管理，资源管理和系统管理。
• 对用例进行分解，画出下层的Use case图
  • 对上层的用例进行分解，并将执行者分配到各层次的Use case图中。

类与对象

面向对象的开发方法的基本任务是建立对象模型，是软件系统开发的基础。UM中的类图（Class Diagram）与对象图（Object Diagram）表达了对象模型的静态结构，能够有效地建立专业领域的计算机系统对象模型。

属性（attribute）

属性用来描述类的特征，表示需要处理的数据。

属性定义：

visibility attribute-name: type = initial-value {property-string}

可见性 属性：类型 = 缺省值（约束特性）

其中：可见性（visibility）表示该属性对类外的元素是否可见。

分为：

• public(+) 公有的。
• private(-) 私有的。
• protcted(#) 受保护的。
• 默认（未声明）

操作

对数据的具体处理方法的描述则放在操作部分，操作说明了该类能做些什么工作。操作通常称为函数，它是类的一个组成部分，只能作用于该类的对象上。

操作定义：

visibility operating-name(parameter-list): return-type {property-string}

可见性  操作名（参数表）：返回类型{约束特性}

一个使用Visio绘制的类图

包图

一个最古老的软件方法问题是：怎么将大系统拆分成小系统。解决该问题的思路之一是将许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合。UML中这种分组机制叫包（Package）。引入包是为了降低系统的复杂性。

UML中的消息

简单消息（simple）: 表示控制流，描述控制如何从一个对象传递到另一个对象，但不描述通信的细节。

同步消息（synchronous）:  是一种嵌套的控制流，用操作调用实现。操作的执行者要到消息相应操作执行完成并回送一个简单消息后，再继续执行。

异步消息（asynchronous）: 是一种异步的控制流，消息的发送者在消息发送后就继续执行，不等待消息的处理。

时序图

时序图（Sequence Diagram）用来描述对象之间动态的交互行为，着重体现对象间消息传递的时间顺序。

时序图存在两个轴：

• 水平轴表示一组对象
• 垂直轴表示时间

时序图中的对象用一个带有垂直虚线的矩形表示，并标有对象名和类名。垂直虚线是对象的生命线，用于表示在某段时间内对象是存在的。

对象间的通信通过在对象的生命线之间消息来表示，消息的箭头类型指明消息的类型。

时序图的形式

有两种使用时序图的方式：一般格式和实例格式。

实例格式详细描述一次可能的交互。没有任何条件和分支或循环，它仅仅显示选定情节（场景）的交互。

而一般格式则描述所有的情节。因此，包括了分支，条件和循环。

活动图

活动图（Activity Diagram）的应用非常广泛，它即可用来描述操作（类的方法）的行为，也可以描述用例和对象内部的工作过程，并可用于表示并行过程。

活动图描述了系统中各种活动的执行顺序。刻化一个方法中所有要进行的各项活动的执行流程。

活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的变迁可能需要事件的触发）。

活动图的模型元素

构成活动图的模型元素有：活动、转移、对象、信号、泳道等。

活动

• 是构成活动图的核心元素，是具有内部动作的状态，由隐含的事件触发活动的转移。
• 活动的解释依赖于作图的目的和抽象层次，在概念层描述中，活动表示要完成的一些任务。在说明层和实现层中，活动表示类中的方法。
• 活动用圆角框表示，标注活动名。
• 模型元素有：活动、转移、对象、信号、泳道等。

• 活动还有其它的图符：初态、终态、判断、同步。

转移

• 转移描述活动之间的关系，描述由于隐含事件引起的活动变迁，即转移可以连接各活动及特殊活动（初态、终态、判断、同步线）。
• 转移用带箭头的直线表示，可标注执行该转移的条件，无标注表示顺序执行。

泳道

• 泳道进一步描述完成活动的对象，并聚合一组活动。活动图是另一种描述交互的方式，描述采取何种动作，做什么（对象状态改变），何时发生（动作序列），以及在何处发生（泳道）。
• 泳道也是一种分组机制。

对象流

• 活动图中可以出现对象，对象作为活动的输入/输出，用虚箭头表示。

控制图符

• 活动图中可以发送和接收信号，发送符号对应于与转移联系在一起的发送短句。接收符号也同转移联系在一起。

状态图

状态图（State Diagram）用来描述一个特定对象的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的转移。

状态

所有对象都具有状态，状态是对象执行了一系列活动的结果。当某个事件发生后，对象 的状态将发生变化。状态图中定义的状态有：

• 初态：状态图的起始点，一个状态图只能有一个初态 。
• 终态：状态图的终点，而终态则可以有多个。
• 中间状态：可包括三个区域：名字域、状态变量与活动域。
• 复合状态：可以进一步细化的状态称作复合状态。

协作图

协作图（Collaboration  Diagram）, 也称为合作图，用于描述互相合作的对象间的交互关系和链接（Link）关系。虽然顺序图和协作图都用来描述对象间的交互关系，但侧重点不一样。时序图着重体现交互的时间顺序，协作图则着重体现交互对象间的静态链接关系。

实现模型

实现模型描述了系统实现时的一些特性，又称为物理体系结构建模。包括源代码的静态结构和运行时刻的实现结构。

实现模型包括：

• 组件图（Component Diagram）显示代码本身的逻辑结构，它描述系统中存在的软件以及它们之间的依赖关系。
• 部署图（Deployment Diagram）描述了系统中硬件和软件的物理配置情况和系统体系结构。显示系统运行时刻的结构，部署图中的简单结点是指实际的物理设备以及在该结点上运行构建或对象。部署图还描述结点之间的连接以及通信类型。

组件图

组件定义：系统中遵从一组接口且提供其实现的物理的、可替换的部分。对系统的物理方面建模时，它是一个重要的构造块。

组件可以看做包与类对应的物理代码模块，逻辑上与包，类对应，实际上是一个文件，可以有下列几种类型的构件：

• 源代码构件
• 二进制构件
• 可执行构件

组件之间的依赖关系是指结构之间在编译、连接或执行时的依赖关系。用虚线箭头表示。

部署图

部署图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件，即系统运行时刻的结构。部署图可以显示计算机结点的拓扑结构和通信路径，结点上执行的组件，特别对于分布式系统，部署图可以清楚的描述系统中硬件设备的配置，通信以及在各硬件设备上各种软构件和对象的配置。因此，部署图是描述任何基于计算机的应用系统的物理配置或逻辑配置的有力工具，部署图的元素有节点和连接。

部署图中的结点代表某种计算机，通常是某种硬件。同时结点还包括在其上运行的软组件，软件组件代表可执行的物理代码模块。如一个可执行程序。结点的图符是一个立方体。