什么是软件架构

每个系统有一个“架构”

“架构”是“架构元素”和“元素间关系”的描述

描述的结构是“架构文档”

“架构文档”是由“架构视图”组成的

“架构视图”体现的是“相关方”的“关注点”



图-1 软件架构元素关系图

！！！画重点

架构设计的文档写什么？

--> 文档给谁看? 明确相关方

--> 项目处于哪个阶段？ 明确各个阶段的相关方和自己的关注点

--> 视角是什么？ 想描写系统的哪个方面

本章核心点

• 架构元素都有哪些？

• 元素之间的关系如何反应？

• 架构文档如何写作？

• 架构视图如何设计？

架构视图模型(4+1视图)

逻辑视图

相关方：客户，用户，开发者

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

主要元素：系统、子系统、功能模块、子功能模块和接口

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

开发视图

相关方：开发相关人员，测试人员

视角：系统如何进行开发

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

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

物理视图

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

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

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

过程视图

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

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

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

场景视图

软件建模语言

每章一问：为什么4+1？ 

一个系统是有多个方面，相关方的关注点是不同的。

需要从不同角度去描述系统，总结后可以从 4+1 角度分析系统。

本章重点：

设计模型是表达什么意图？

需要表达什么内容？

在什么阶段需要什么方式表达？

什么是模型？(What)

模型是一个系统的完整抽象



图2-业务建模流程

思考

与 DDD 在头脑风暴中环节类似，主要都要分析业务的复杂度

并且根据业务的复杂度抽象具体的领域与业务模型

为什么建模？(Why)

建造传统模型的目的

• 为了证明某件事物是否可工作

• 前提：建造模型的成本远远低于建造实物的成本（飞机，大炮）

建造软件模型的目的

• 为了与他人沟通

• 为了保存软件设计的成果

• 把控整体系统落地后的效果

• 降本提效

• 前提：建模比代码更说明问题（简单模块或简单功能 --> SHOW ME THE CODE）

UML

分类

• 静态图

• 【重点】用例图

• 对象图

• 【重点】类图

• 【重点】组件图

• 包图

• 【重点】部署图

• 动态图

• 协作图

• 【重点】序列图

• 【重点】活动图

• 【重点】状态图

元素

• 类

• 对象

• 状态

• 用例

• 结点

• 接口

• 组件

• 包

常见关系

• 依赖：一个元素以某种方式依赖于另外一种元素

• 继承

• 实现

• 关联：连接模型元素及链接实例

• 聚合：整体与局部的关系

• 生命周期：聚合内元素会有各自的生命周期

• 组合：

• 生命周期：组合内的元素生命周期相同

模型视图

用例建模

主要用于描述系统的功能需求。在宏观上给出模型的整体轮廓

元素

人：角色(可以为人，也可以是系统)

椭圆：用例（动宾短语）

方框：边界

元素之间的关系

• 使用（<Uses>）

• 拓展（<Extends>）

使用阶段

• 需求设计阶段

类图

元素

类：包含成员变量，方法

接口：接口的定义

元素之间的关系

• 依赖

• 继承

• 实现

• 关联

• 聚合

• 组合

使用阶段

• 详细设计阶段

动态建模

UML中消息的传递方式

• 简单消息：明确调用关系

• 同步消息：调用者等待被调用者的返回【类之间消息同步方式】

• 异步消息：调用者无需等待被调用者的返回

时序图

描述动态调用关系

使用阶段

全部阶段都可以使用，但是在不同的阶段需要表明的内容不同。

活动图

描述流程关系

使用阶段

全部阶段都可以使用

状态图

描述状态变迁关系

使用阶段

在需求分析和详细设计阶段可以使用

可以了解有限状态机模型

实现模型

组建模型

描述组建之间关系

使用阶段

概要设计阶段

部署图

描述服务器之间的关系

使用阶段

概要设计阶段

架构设计步骤

• 需求分析：明确系统的功能、方向、场景、约束

• 概要设计：明确系统如何部署、系统模块、系统流程

• 详细设计：明确类之间的关系