【架构设计】作为架构师你应该掌握的画图技术

1.前言

• 大家知道，架构的过程其实就是建模的过程，那自然离不开架构图。
• 那么，我们先来看几个问题。

（1）什么是架构图？

架构图 = 架构 + 图，用图的形式把系统架构展示出来，配上简单的文案，不同的人开不同的架构图，比如业务架构图就是给老板和产品经理看的，技术架构是给研发人员看的，物理架构图是给部署运维的人员看的。

（2）如何判断架构图的好和坏？

• 业务抽象设计的合理性，是否满足高内聚、低耦合的要求，不能太宽泛，也不能太细粒度
• 层级划分目标系统边界，自下而上 或 由上而下，一般包括 基础设施、数据层、应用层、用户层四个层次
• 纵向分层 上层依赖于下层越底层，越是基础服务；横向并列关系，级别相同
• 理清架构图类型、业务要全面、专业术语一致、图形清晰美观、颜色类型划分合理

（3）什么是【 TOGAF】

• 全称 The Open Group Architecture Framework 企业架构标准
• 给企业架构专业人士之间的沟通提供一致性保障，设计上注重灵活性，可用于不同的架构风格。
• 不同架构视图承载不同的架构设计决策，支持不同的目标和用途

2.业务架构图

（1）什么是业务架构图

• 定义业务战略、企业治理、组织架构和关键业务流程。

• 是对业务需求的提炼和抽象，使用一套方法论对项目所涉及需求的业务进行业务边界划分

• 能比较清晰地看到系统的业务全貌，需求分析是否做到位，功能开发是否达到预期目标，都以此为依据

• 业务架构图中尽量不出现技术的字眼，不同架构图的读者是不同的，确保能看懂。

• 无技术背景人员可参与实现的讨论，向技术人员描述解决方案核心要做什么，必须实现的关键是什么

（2）怎么去画业务架构图

• 分层

  • 业务按照层级进行划分，各个层级属于独立的版块，下层为上层提供服务能力支撑。比如：laaS / PaaS / SaaS

• 分模块

  • 同层级中进行小归类，属于平行关系，可以独立存在

• 分功能

  • 独立功能划分出来，即业务入口，业务方重点关注的功能点，可以认为是微服务划分

3.技术架构图

（1）什么是技术架构图

• 应用架构本身只关心需要哪些应用系统，不关心在整个项目中你需要使用哪些技术
• 技术架构则是实现应用架构的承接方，识别技术需求，进行技术选型，描述技术之间的关系
• 解决的问题包括
  • 技术层面的分层、开发语言、框架的选择
  • 通信技术、存储技术的选择、非功能性需求的技术选择等

4.数据架构图

• 描述一个组织逻辑的和物理的数据资产和数据管理资源的结构
• 从数据视角，表达数据从产生到消费应用的全过程
• 比如做一个电商实时大屏，数据来源有哪些，经过哪些组件处理，最终存储和应用到哪里
• 常规里面不加具体的技术实现，但有时会方便沟通，则加入对应的技术实现

5.RUP4+1视图

（1）什么是RUP 4+1

• 全称Rational Unified Process，中文统一软件开发过程，是一个面向对象画图的方法论
• 在RUP中采用"4+1"视图模型来描述软件系统的体系结构
• 包括五种视图：场景视图、开发视图、逻辑视图、物理视图、处理试图

（2）分类

• 场景视图
  • 也叫用例视图，4+1中的1，是最核心的视图。在UML中通常由用例图表示并不限于使用UML的用例图进行设计，可以使用其他方法。
• 逻辑视图
  • 描述系统的功能需求，系统给用户提供哪些服务，比如扫码、登录、支付
  • 对系统职责的逐级划分，理清功能需求和系统边界，也叫系统架构、应用架构、技术架构
• 物理视图
  • 也叫部署视图，部署架构，对这个部署信息进行描述，包括服务器、虚拟机、终端设备分布等
• 处理视图
  • 流程图，描述系统中的动态信息，最常见的是逻辑架构元素之间的交互关系
  • 比如支付下单的功能是怎末实现的，在UML中通常用时序图和流程图表示
• 开发视图
  • 描述在开发环境中软件的静态组织结构，关注软件开发环境下实际模块的组织

6.场景视图

• 场景视图也叫用例视图，4+1中的1，是最核心的是视图，在UML中通常由用例图表示，用例视图并不限于使用UML的用例图进行设计,可以使用其它方法。
• 用例图主要分3个部分
  • 参与者
    • 代表系统外部与系统发生交互的人或事物
    • 事物可以是一个应用程序或者特殊进程
  • 用例：系统外部可见的一个功能单元，由参与者启动，比如观看课程
  • 参与者与用例的关系
    • 关联：以一条直线相连，比如用户登录系统
    • 归纳（泛化）
      • 指一个父用例可以形成多个子用例，父用例和子用例之间的关系就是泛化关系
      • 泛化关系通过一个三角箭头从子用例指向父用例来表示
      • 箭头表示参与者与参与者之间、用例与用例之间的关系；
      • 账号登录与微信登录，可归纳为登录系统
    • 包含：表示用例与用例之间的关系，用带有“包含”的箭头表示，箭头从基础用例指向包含用例
    • 拓展：用带有“拓展”的箭头表示，由拓展用例指向基础用例，如登录时忘记密码，是可选的，缺少不会影响用例的完整性

7.物理视图

• 物理视图也叫部署视图，部署架构，对这个部署信息进行描述，包括服务器、虚拟机、终端设备分布等
• 描述系统软件到物理硬件的映射关系，反映出系统的组件是如何部署到一组可计算机器节点上
• 用于指导软件系统的部署实施过程，通常要考虑到解决系统的可靠性和可伸缩性要求
• 没有统一标准格式，核心是清晰列出部署架构，能让运维方能看懂即可
• 更多是综合的图形工具

8.开发视图

• 描述在开发环境中软件的静态组织结构
• 主要是系统模块的划分和组成，细化到内部包的组成设计，技术开发人员角度看系统的逻辑组成

• 关注程序包，应用框架，引用的类库、SDK和中间件，以及工程和包的划分规则等，规范、约束开发环境的结构
• 常规就是 类图，组件图

9.处理视图

• 描述系统中的动态信息，最常见的是逻辑架构元素之间的交互关系
• 比如 微信扫码支付下单功能是如何实现的
• 在UML中通常由时序图和流程图表示
• 什么是时序图
  • 是一种UML交互图，描述了对象之间传递消息的时间顺序, 用来表示用例中的行为顺序, 是强调消息时间 顺序的交互图; 又名序列图、顺序图
  • 通俗解释：就是交互流程图 (把大象装冰箱分几步)
  • 时序图包括四个元素
    • 对象(Object)
      • 时序图中的对象在交互中扮演的角色就是对象，使用矩形将对象名称包含起来, 名称下有下划线
    • 生命线(Lifeline)
      • 生命线是一条垂直的虚线, 这条虚线表示对象的存在, 在时序图中, 每个对象都有生命线
    • 激活(Activation)
      • 代表时序图中对象执行一项操作的时期, 表示该对象被占用以完成某个任务，当对象处于激活时期, 生命线可以拓宽为矩形
    • 消息(Message)
      • 对象之间的交互是通过相互发消息来实现的，箭头上面标出消息名，一个对象可以请求（要求）另一个对象做某件事件
      • 消息从源对象指向目标对象，消息一旦发送便将控制从源对象转移到目标对象
      • 消息的阅读顺序是【严格自上而下】
      • 消息交互中的【实线+实心箭头：同步请求消息】
      • 消息交互中的【实线+大于号：异步请求消息】
      • 消息交互中的【小于号+虚线：响应返回消息】
      • 自己调用自己的方法：反身消息