【总结】架构师如何做架构

用户头像
张金峰
关注
发布于: 2020 年 06 月 10 日
【总结】架构师如何做架构

日拱一卒



架构师是什么

根据维基百科,对架构师有如下定义:

系统架构师System Architect,簡稱SASAr),是在信息系统研发中,负责依据需求来确定主要的技术选择、设计系统的主体框架结构,并负责搭建实施的人。他们(与系统分析师共同)确立系统的主体架构和实现方向,并负责指导软件工程师等开发人员的编码开发工作。

可以看到架构师贯穿了信息系统整个生命周期,从需求分析到上线实施,并需要对之负责的人。在实际工作中,架构师并不是一个位置,更多是一个角色。特别是在创业或小型公司中,并没有架构师这一职位,而是由技术经理承担这一角色,或产品经理和技术经理分摊了架构师的角色。并不是只有在大公司需要架构师帮助复杂系统进行架构,即使只有2-3个人的团队中,也是需要有“架构师”的。不管是大型系统还是单服务的系统都是需要进行架构工作,架构工作是对系统的需求分析,技术选择,组件抽象,部署实施等等工作综合,帮助系统从无到有,预先设计规划,起到蓝图的工作。拓展开来,架构师并不仅仅存在于信息领域,生活中方方面面,都有着架构师的存在,只不过他们叫其他名字,老师,公司老板,家长等等。比如:老师就是自己授课的“架构师”,老师需要确定课程的目的,组成部分,授课的方式,在课堂中以什么方式组织知识点能够帮助学生理解,让真正学会。他们都在做着“架构师”这个角色。

架构师主要职责

在信息领域,架构师的职责包括但不限于以下职责:

  • 编写架构设计文档

  • 开发编程框架

  • 重构软件代码

  • 设计系统架构

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

  • 优化系统性能

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

  • 保障系统安全与高可用

  • 大数据应用

  • 技术创新

  • 沟通管理

架构师的基本素质

架构师应该具备以下基本素质。

沟通能力

架构师的工作是贯穿整个信息系统周期的,在不同的阶段需要和不同的相关方合作,沟通。其中包括老板,产品经理,开发工程师,测试工程师和运维工程师等。这就决定了架构师在和各方沟通的时候,统一利益相关方的利益,让项目能够最终成功。我觉得这是最重要的。

技术深度和广度

架构师的工作需要一定的技术深度和广度。首先要有技术深度,最好是精通1-2个技术,然后对其他相关技术做到熟练掌握,所谓触类旁通,所以架构师首先需要是一个优秀的工程师。而且优秀技术可以在工程师和产品经理中形成影响力,而影响力是形成领导力的重要一环。架构师是团队中的技术权威。

领导能力

架构师能够推动整个团队的技术进展,能在压力下作出关键性的决策,并将其贯彻到底,这就需要架构师具有领导能力。架构师在团队中需要建立领导力,里面包括个人魅力、技术能力、知识传递等等。

抽象思维和分析能力

架构师需要有抽象思维和分析的能力,这是在进行系统分析和系统分解的基本素质。只有具备这样的能力,架构师才能看清系统的整体,掌控全局。

架构是什么

根据维基百科,对软件架构定义如下:

软件架构是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。

架构的表述

软件架构和各要素之间的关系可以用下图来表示:





  • 系统 需要有一个 架构

  • 架构 架构元素 元素间关系 组成

  • 架构 需要产出 架构文档

  • 系统 的生命周期中有很多 相关方

  • 架构文档 是为各 相关方 写的,不同的相关方重点及范围不同。重点是从对方的角度思考,让对方能够理解架构

  • 架构文档 中有各种 架构视图

  • 不同的 相关方关注点 是不同的

  • 架构视图 就是来解释 相关方关注点

架构视图

架构视图有多种表示方式,其中比较有名的有4+1视图模型和UML。

4+1视图模型

4+1视图模型是有IBM总结提出的架构视图模型(具体模型)。该模型包含五个主要的视图:

  • 逻辑视图(Logical View),设计的对象模型(使用面向对象的设计方法时)。

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

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

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

架构的描述,即所做的各种决定,可以围绕着这四个视图来组织,然后由一些用例 (use cases)或场景(scenarios)来说明,从而形成了第五个视图。之间的关系如下图:

4+1视图模型传递出一个非常好的理念:针对不同的相关方,需要有不同层次的视图,来解释架构师脑中关于系统各个方面的思考,从而让各相关方能够很好的理解将要建设的系统。

UML

视图分类

现在,架构师更加常用的视图建模工具是UML。其中表述系统元素间静态关系的视图有如下视图,其中黑色为重要视图,是经常使用的。

  • 用例图 是从用例的角度描述系统的功能需求,它是系统预期功能(用例)及其环境(参与者)的模型。用例使您能够将系统需要与系统如何满足这些需求相关联。

  • 对象图 是实例 (Instance) 的表达,包括对象和数据值。静态的对象图是类图的一个实例,它是系统在某个时间点的详细状态的快照,不同之处在于类图表示了一个由类及其关系组成的抽象模型,而对象图则表达了特定时刻的实例。

  • 类图 是一切面向对象方法的核心建模工具。该图描述了系统中对象的类型以及它们之间存在的各种静态关系。

  • 组件图 描绘了组件如何连接在一起以形成更大的组件或软件系统。它展示了软件组件的体系结构以及它们之间的依赖关系。

  • 包图 是 UML 一種用以显示包和包之间的依赖关系的结构性图表。模型图能显示系统的不同视图,例如,多层应用程序。

  • 部署图 有助于模拟面向对象软件系统的物理方面。它是一个结构性图表,显示了软件产出于系统架构内如何被分发至指定目标。

表述动态关系的视图有:

  • 协作图 与序列图类似,协作图也用于模拟用例的动态行为。与序列图相比,协作图更侧重于显示对象的协作而不是时间顺序。

  • 序列图 根据时间序列展示对象如何进行协作。它展示了在用例的特定场景中,对象如何与其他对象交互。

  • 活动图 描述了目标系统的控制流程,比如探索复杂的业务规则和操作,描述用例和业务流程。在统一建模语言中,活动图旨在模拟计算和组织过程(即工作流程)。

  • 状态图 是 UML 中用来描述基于 David Harel 的状态图概念的系统行为的一种图表。状态图描绘允许的状态和转换以及影响这些转换的事件,它有助于可视化对象的整个生命周期,从而更好地理解以状态主導 (State-based) 的系统。

元素间关系

元素间重要的关系有如下:

  • 依赖  依赖关系是五种关系中耦合最小的一种关系。类A要完成某个功能引用了类B,则类A依赖类B。依赖在代码中主要体现为类A的某个成员函数的返回值、形参、局部变量或静态方法的调用,则表示类A引用了类B

  • 关联 关联关系比依赖要强。发生关联关系的两个类,类A成为类B的属性,而属性是一种更为紧密的耦合,更为长久的持有关系。

  • 实现 实现关系是类元与提供的接口之间的私有类型的实现关系。

  • 继承 指的是一个类(称为子类、子接口)继承另外的一个类(称为父类、父接口)的功能,并可以增加它自己的新功能的能力,继承是类与类或者接口与接口之间最常见的关系

  • 聚合 聚合用来表示集体与个体之间的关联关系。例如班级与学生之间存在聚合关系。

  • 组合 组合用来表示个体与组成部分之间的关联关系。例如学生与心脏之间存在复合关系。

视图使用阶段

在软件设计的三个阶段中,分别需要如下视图来帮助理解:

需求分析:用例图、状态图、时序图、活动图

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

详细设计:类图、类时序图、状态图、方法活动图



发布于: 2020 年 06 月 10 日 阅读数: 42
用户头像

张金峰

关注

还未添加个人签名 2017.11.23 加入

还未添加个人简介

评论

发布
暂无评论
【总结】架构师如何做架构