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)
对象之间的交互是通过相互发消息来实现的,箭头上面标出消息名,一个对象可以请求(要求)另一个对象做某件事件
消息从源对象指向目标对象,消息一旦发送便将控制从源对象转移到目标对象
消息的阅读顺序是【严格自上而下】
消息交互中的【实线+实心箭头:同步请求消息】
消息交互中的【实线+大于号:异步请求消息】
消息交互中的【小于号+虚线:响应返回消息】
自己调用自己的方法:反身消息