第一周:架构方法 - 架构师如何做架构学习总结

用户头像
DZ
关注
发布于: 2020 年 06 月 11 日

1. 如何成为架构师

1.1 架构的思维方式

业务千差万别,同一个系统在一个公司能成为银弹,在另一个公司却有可能成为累赘。做架构首先要看到问题在哪里,看到问题本质是什么,清楚解决问题的思路是什么,用哪些方法可以解决。一旦拆解出问题的本质,就可以突破业务界限,灵活运用各种技术做出一个合理的架构。业务不是共通的,但是技术是可以共通的。

1.2 架构师的主要职责

编码:

  • 开发编程框架

  • 重构软件代码

设计:

  • 设计系统架构

  • 进行技术选型,解决技术应用中的问题

  • 大数据应用

  • 模块分解与微服务架构重构

  • 编写架构设计文档

保障,优化与创新:

  • 优化系统性能

  • 技术创新

  • 保障系统安全与高可用

沟通:

  • 沟通管理



1.3 架构师主要能力

  • 编程能力

  • 基础技术掌握能力

  • 常用技术产品的理解与应用能力

  • 性能优化与分析故障的能力

  • 常用架构模式和框架的理解与应用能力

  • 建模以及设计文档的方法和能力

  • 业务理解与功能模块及非功能模块拆解能力

  • 快速学习

  • 能力沟通与领导能力



1.4 什么是软件架构

  • 系统会有架构

  • 架构由架构元素和元素间关系组成的

  • 架构元素:指系统由什么组成,按照不同维度,可以为服务器,模块,组件,类等等。

  • 元素间关系:

  • 静态关系:组合,聚合,关联,依赖,继承,实现等等

  • 动态关系:类和类如何交互,组件与组件如何交互,子系统与子系统如何交互,服务器之间如何交互,架构要把这些交互关系表达出来

  • 架构设计的输出为架构文档

  • 系统有一些相关方,每个相关方都有一些关注点,架构文档就是为相关方服务

  • 架构文档由一些架构视图组成,不同架构视图有不同的关注点,对应不同的相关方



核心:相关方

系统的架构能否落地取决于相关方,取决于你输出的架构文档是否包含相关方的关注点,能否满足相关方诉求。



2. 如何构建架构视图

2.1 4+1架构视图

为什么用4+1种视图,不是一种?因为各个相关方关注点不一样,需要从多个方面,不同视角,不同维度描述系统,对系统的描述由平面到立体。



分类:以场景视图为中心

  • 逻辑视图(Logical View) ,设计的对象模型。

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

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

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

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

  • 过程视图(Process View) ,捕捉设计的并发和同步特征。

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

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

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

  • 物理视图(Physical View) ,描述了软件到硬件的映射,反映了部署特性

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

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

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

  • 开发视图(Development View) ,描述了在开发环境中软件的静态组织结构

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

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

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

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

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

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

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

2.2 UML建模

2.2.1 什么是模型

完整的抽象,即是对业务的抽象,也是对系统的抽象。先对现实中业务进行抽象,通过对业务进一步分析,得到系统的抽象。

2.2.2 UML分类

  • 静态图:

  • 用例图(Use Case Diagrams)

  • 对象图(Object Diagrams )

  • 类图(Class Diagrams)

  • 组件图(Component Diagrams)

  • 包图(Package Diagrams)

  • 部署图(Deployment Diagrams)

  • 动态图:

  • 协作图(Collaboration Diagrams)

  • 序列图(Sequence Diagrams)

  • 活动图(Activity Diagrams)

  • 状态图(State Diagrams)

常用7种:用例图,类图,组件图,部署图,序列图,活动图,状态图



2.2.3 模型元素与元素关系

  • 模型元素:可以在图中使用的概念统称为模型元素,比如类、对象、结点、包和组件等

  • 元素间关系:依赖,继承,实现,关联,聚合,组合等



2.2.4 UML使用

  • 用例图:

  • 用途:系统能做什么,描述系统功能

  • 元素:角色,用例,系统边界,线条

  • 使用阶段:需求分析

  • 粒度:细化到相关方可以理解即可



  • 类图:

  • 用途:表达对象模型的静态结构

  • 元素:类,关系(常见关系: 泛化, 实现,关联,聚合,组合,依赖)

  • 使用阶段:详细设计

  • 粒度:细化到开发人员可以理解即可



  • 时序图:

  • 用途:描述对象之间的动态合作关系以及合作过程中的行为次序

  • 元素:简单消息,同步消息,异步消息,对象,生命线,激活

  • 使用阶段:需求分析(系统之间交互),概要设计(服务器和组件之间交互),详细设计(类之间交互)

  • 粒度:画出核心逻辑



  • 活动图

  • 用途:描述流程与顺序,一种流程图

  • 元素:活动、转移、对象、信号、泳道等。

  • 使用阶段:需求分析(业务流程),概要设计(不同领域,模块,子系统流程顺序),详细设计(一个方法内部的执行顺序)

  • 粒度:细化到相关方可以理解



  • 状态图

  • 用途:描述一个特定对象的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的转移。用于有复杂状态变迁的场景。

  • 元素:状态、转移和事件

  • 使用阶段:主要为需求分析(比如业务订单状态),详细设计(状态枚举值,对应逻辑与变量变更触发状态变化可以写在线上)

  • 粒度:细化到相关方可以理解



  • 组件图(组件图设计里面最重要的图,组件动态关系用组件时序图)

  • 用途:表达对象模型的静态结构

  • 元素:组件、接口、依赖关系

  • 使用阶段:主要在概要设计阶段,表述静态关系

  • 粒度:概念上的组件是可复用的物理意义上的组件,比如一个jar包。一个物理组件又可以分为若干个逻辑组件。在组件图中,可以拆分至差不多一个人能负责一个组件的开发。图中组件之间的依赖关系以及调用关系需要明细,因为描述组件之间的关系,也能体现工程师之间的关系,体现谁先开发,谁后开发等工程师之间的依赖关系



  • 部署图(作为设计文档里的第一张图)

  • 用途:物理部署,服务器之间的关系,承担什么职责

  • 元素:物理节点(节点内部可以包含软件组件)、关系

  • 使用阶段:概要设计阶段

  • 粒度:细化到相关方可以理解

2.2.5 UML使用场景总结

  • 需求分析:用例(核心),时序(和外部系统调用关系),活动(业务流程),状态(关键业务对象变迁)

  • 概要设计:部署图,子系统级时序图,组件时序图,组件图,活动图

  • 详细设计:类图,时序图,状态图,方法的活动图



用户头像

DZ

关注

还未添加个人签名 2018.01.24 加入

还未添加个人简介

评论

发布
暂无评论
第一周:架构方法-架构师如何做架构学习总结