架构文档

架构文档是架构师的主要交付产物，由主要描述架构元素以及架构元素间关系的架构视图组成，体现了软件设计阶段不同相关方的利益诉求。

架构视图

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

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

4+1 视图模型

由 IBM 提出的业界比较出名的架构设计方案

• 逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。

• 过程视图（Process View），捕捉设计的并发和同步特征。

• 物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。

• 开发视图（Development View），描述了在开发环境中软件的静态组织结构。

• 场景视图( scenarios),描述用例场景。

逻辑视图、过程视图、物理视图、开发视图围绕场景世视图展开。

逻辑视图

• 相关方: 客户,用户,开发组织管理者。

• 视角: 系统的功能元素,以及它们接口,职责,交互

• 主要元素: 系统,子系统,功能模块,子功能模块,接口。

• 用途: 开发组织划分成本进度的评估。

开发视图

• 相关者: 开发相关人员,测试人员。

• 视角: 系统如何开发实现。

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

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

物理视图

• 相关者: 系统集成商,系统运维人员。

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

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

过程视图

• 相关者: 性能优化,开发相关人员。

• 视角: 系统运行时线程,进程的情况。

• 主要元素: 系统进程,线程以及处理队列等。

场景视图

• 相关者: 用户,设计和开发人员。

• 视角: 概括了架枃上最重要的场景(最典型或者最有风险)及其非功能性需求,通过这些场景的实现,闻明了架构的广度或众多架构元素运行的方式

软件建模

什么是模型

模型是一个系统的完整的`抽象`。在落地之前对现实问题的考量，在系统产生之前表述是什么、要做什么，系统的设计就是在建模。

架构师的职责是在系统投产之前，对将要做的系统有一个认知，把自己的想法通过模型图画出来就完成了系统的设计。架构师的职责和产出是一致的，关键在于对现实问题的抽象。

为什么要建造模型

• 验证想法是否可行

• 与它人沟通

• 保存最终的设计结果

何时、何处画图

何时画图

• 讨论、交流时

• 最终设计文档

何处画图

• 白板

• 工具

UML

Unified Modeling Language, 统一建模语言

什么是 UML

以图形方式描述软件的概念

统一: 统一多种建模方式

语言: 建模工具，用于交流沟通，有利于思考。

语言有方言， UML 也是有方言的。不强制要求，重点在于传达思想。

UML 7 种常用图形

• 用例图

• 类图

• 组件图

• 时序图

• 活动图

• 状态图

• 部署图

架构文档

需求分析

• 用例图

• 活动图，关键的流程

• 状态图，核心状态，关键对象的状态转换

• 时序图,系统级的外部系统

概要设计

• 部署图

• 子系统级别的时序图

• 系统级的活动图

• 组件图

• 组件时序图

详细设计

• 类图

• 类时序图

• 方法的活动图

• 状态图

Reference

• https://www.ibm.com/developerworks/cn/rational/r-4p1-view/index.html
  

• https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/