【架构笔记之架构方法】架构师训练营第 1 期第 1 周
1. 架构师概述
什么是架构师?
架构师是做架构设计、对系统架构负责的那个人。
架构师是一顶帽子,而不是一把椅子;架构师是一个角色而不是一个职位。
1.1 架构师的主要职责(11大职责)
编写架构设计文档
开发编程框架
重构软件代码
设计系统架构
进行技术选型,解决技术应用中的问题
优化系统性能
模块分解与微服务架构重构
保障系统安全与高可用
大数据应用
技术创新
沟通管理
1.2 架构师的主要能力(9大能力)
编程能力
基础技术掌握能力
常用技术产品的理解与应用能力
性能优化与分析故障的能力
常用架构设计模式和框架的理解与应用能力
建模以及设计文档的方法和能力
业务理解与功能模块及非功能模块拆解能力
快速学习能力
沟通与领导能力
2. 模型概念的理解和表达
什么是模型?
模型是一个系统完整的抽象。人们对某个领域特定问题的求解及解决方案,对它们的理解和认识都蕴含在模型中。
为什么要建造模型?
建造传统模型的目的
为了证明某件事物能否工作
前提:建造模型的成本远远低于建造实物的成本(比如造飞机、造高楼)
软件建模的目的
为了与他人沟通
为了保存软件设计的最终成果
前提:模型比代码更能说清楚问题
何时、何处画图?
讨论、交流时画图
最终设计文档
只保留少量、重要的图
避免涉及过多内容和实现细节
画图工具目前选的语雀,有集成planUml
3. 4+1视图模型
软件架构={元素,形式,关系/约束}
单一的视图无法完整的表达架构,因此需要具备完整的视图集
逻辑视图(Logical View),设计的对象模型。
过程视图(Process View),捕捉设计的并发和同步特性。
物理视图(Physical View),描述了软件到硬件的映射,反映了部署特性。
开发视图(Development View),描述了在开发环境中软件的静态组织结构。
场景视图(Scenarios),描述用例场景。
3.1 逻辑视图
相关方
客户,用户, 开发组织管理者。
视角
系统的功能元素,以及他们的职责,接口,交互。
主要元素
系统,子系统,功能模块,子功能模块,接口。
用途
开发组织划分,成本/进度的评估。
3.2 开发视图
相关者
开发相关人员,测试人员
视角
系统如何开发实现
主要元素
描述系统的层,分区,包,框架,系统通用服务,业务通用服务,类和接口
用途
指导开发组织设计和开发实现
3.3 物理视图
相关者
系统集成商,系统运维人员
视角
系统逻辑组件到物理节点的物理部署和节点之间的网络配置
主要元素
物理节点以及节点间的通信
3.4 过程视图
相关者
性能优化 ,开发相关人员
视角
系统运行时线程,进程的情况
主要元素
系统进程,线程以及处理队列等
3.5 场景视图
相关者
用户,设计和开发人员
视角
概括了架构上最重要的场景(最典型或者最有风险)及其非功能性需求,通过这些场景的实现,阐明了架构的广度或众多架构元素的运行方式。
4. UML统一建模语言
4.1 UML概述
什么是UML?
Unified Modeling Language,或统一建模语言
以图形方式描述软件的概念
UML可用来描述
某个问题领域
构建中的软件设计
描述已完成的软件实现
UML图的分类
静态图:通过描述类、对象和数据结构以及它们质检存在的关系,来描述软件要素中不变的逻辑结构。
用例图(Use Case Diagrams)
对象图(Object Diagrams)
类图(Class Diagrams)
组件图(Component Diagrams)
包图(Package Diagrams)
部署图(Deployment Diagrams)
动态图:通过秒回执行流程或者实体状态变化的方式,来展示软件实体在执行过程中的变化过程。
协作图(Collaoration Diagrams)
序列图(Sequence Diagrams)
活动图(Activity Diagrams)
状态图(State Diagrams)
通用模型元素
可以在图中使用的概念统称为模型元素。
下图给出了常用的元素符号:类、对象、节点、包和组件等。
模型元素和模型元素之间的连接关系也是模型元素
常见的关系有关联(association)、泛化(generalization)、依赖(dependency)和聚合
(aggregation)。
关联:连接(connect)模型元素及链接(link)实例。
依赖:表示一个元素以某种方式依赖于另一种元素。
泛化:表示一般与特殊的关系,即“一般”元素是“特殊”关系的泛化。
聚合:表示整体与部分的关系。
如图所示。
4.2 UML静态建模
任何建模语言都以静态建模机制为基础,包含标准建模语言UML。
静态建模是指对象之间通过属性互相联系,而这些关系不随时间而转移、
类和对象的建模,是UML建模的基础。UML的静态建模机制包括:
用例图(Use case diagram)
类图(Class diagram)
对象图(Object diagram)
包图(Package diagram)
组件图(Component diagram)
部署图(Deployment diagram)
如下类图例子:
如包类图例子:
4.2.1 用例图
用例建模技术,用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例的分析,使开发者能够有效地了解用户的需求。
用例模型
用例模型描述的是外部执行者(Actor)所理解的系统功能。它描述了待开发系统的功能需求。
(个人理解:从角色维度提出用户故事,并用图形展示)
创建用例模型的工作包括:
定义系统
确定执行者和用例
描述用例
定义用例之间的关系
确认模型
执行者(Actor)
执行者是指用户在系统中扮演的角色。执行者在用例图中是用类似人的图形来表示,但执行者可以是人,也可以是一个外界系统。
下图中海油另外的两种连接类型:《Use使用》和《Extend拓展》关系,是两种不同形式的泛化关系。
示例:项目与资源管理系统的Use case图
确定系统的主要功能
分析确定系统的执行者(角色)
确定用例
对用例进行分解,画出下层的Use case图
4.2.2 组件图
组件(component)
组件定义:系统中遵从从一组接口且提供其实现的物理的、可替换的部分。对系统的物理方面建模时,它是一个重要的构造块。
组件可以看作包与类对应的物理代码模块,逻辑上与包、类对应,实际上是一个文件。
可以有下列几种类型的构件:
源代码构件
二进制构件
可执行构件
4.2.3 部署图
部署图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件,即系统运行时刻的结构。
部署图可以显示计算机节点的拓扑结构和通信路径,节点上执行的组件,特别对于分布式系统,部署图可以清楚的描述系统中硬件设备的配置,通信以及在各硬件设备商各种软构件和对象的配置。
因此,部署图是描述任何基于计算机的应用系统的物理配置的有力工具,部署图的元素有结点和,连接。
部署图中的结点代表某种计算机,通常是某种硬件。同时结点还包括在其上运行的软组件,软件组件代表可执行的物理代码模块。如一个可执行程序,结点的图符是一个立方体。
4.3 UML动态建模
动态模型主要描述系统的动态行为和控制结构。
包括四类图:状态图、活动图、时序图、合作图。
状态图(state diagram):状态图用来描述对象。子系统,系统的生命周期、
活动图(activity diagram):着重描述按操作实现中完成的工作以及用例实例或对象中的活动,活动图是状态图的一个变种。
时序图(sequence diagram):是一种交互图,主要描述对象之间的动态合作关系以及合作过程中的行为次序,常用来描述一个用例的行为。
合作图(collaboration diagram):用于描述相互合作的对象间的交互关系,它描述的交互关系是对象间的消息连接关系。
UML中的消息
4.3.1 时序图
顺序图的形式:
有两种使用顺序图的方式,一般格式和实例格式。
实例格式:详细描述一次可能的交互。没有任何条件和分支或循环,它仅仅显示选定情节(场景)的交互。
一般格式:描述所有的情节(场景)。因此包括了分支,条件和循环。
4.3.2 活动图
活动图(Activity Diagram)的应用非常广泛,它既可用来描述操作(类的方法)的行为,也可以描述用例和对象内部的工作过程,并可用与表示并行过程。
活动图描述了系统中各种活动的执行的顺序。刻画一个方法中所要进行的各项活动的执行流程。
活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的变迁可能需要事件的触发)。
活动图的模型元素
构成活动图的模型元素有:活动、转移、对象、信号、泳道等。
活动
转移
泳道
对象流
控制图符
4.3.3 状态图
状态图(State Diagram)用来描述一个特定对象的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的转移。
状态
所有对象都具有状态,状态是对象执行了一系列活动的结果。当某个事件发生后,对象的状态将发生变化。状态图中定义的状态由:
初态:状态图的起始点,一个状态图只能有一个初态。
终态:状态图的终点,终态可以有多个。
中间状态:可包括三个区域:名字域、状态变量与活动域。
复合状态:可以进一步细化的状态叫做复合状态。
4.3.4 合作图
合作图(Collaboration Diagram),也称协作图,用于描述相互合作的对象间的交互关系和链接(Link)关系。
虽然顺序图和合作图都是用来描述对象之间的交互关系,但侧重点不一样。
顺序图着重体现交互的时间顺序,合作图则着重体现交互对象间的静态链接关系。
5. 书籍推荐
评论