架构师是怎样炼成的 -1-2

用户头像
闷骚程序员
关注
发布于: 2020 年 06 月 10 日

1. 什么是软件架构?

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



2. 架构究竟是在做什么?

任何一个系统都有架构,架构是架构元素与元素间关系描述,并写入架构文档。架构文档是一组架构视图组成的。架构视图反应了相关方的一些关注点。架构是给相关方做的,要让相关方能看的懂。给老板做的架构文档和给测试、工程师看的一定是不一样的,可能最终描述的是同一个东西。架构要满足相关方的诉求



  1. 架构元素是什么?

系统最终由哪些服务器组成,需要哪些软件,开发哪些模块、组件,需要设计哪些类,这些叫做架构元素。

  1. 元素间关系是什么?

服务器间的调用关系,相互之间是如何交互的,是同步的还是异步的。类与类之间的关联关系,继承关系,调用关系。

  1. 相关方都哪些?

包含但并不局限于客户、老板、开发、测试、运维、产品、运营。

  1. 架构文档

元素间的关系是如何表现的?就是通过架构文档表现出来的。

  1. 架构视图

架构视图描述元素间的关系,架构视图组成了架构文档。反应了相关方的关注点。

  1. 系统是给谁做的?

系统是给相关方做的



作为架构师,就是要把上面的事情做好,满足相关方的利益诉求。



3. 今天讨论的重点内容:

  1. 架构元素究竟应该包含哪些东西?

  2. 元素间关系如何反应?

  3. 架构文档如何写作?

  4. 架构视图如何设计?



4. 4+1视图模型

4+1模型,是有IBM提出的一种架构设计方案。逻辑视图开发视图过程视图物理视图,都围绕着场景视图展开。



  1. 逻辑视图:

相关方:客户,用户,项目经理。

视角:说明开发的这个系统功能是什么样子的。关注的是功能元素,以及它们的接口,职责,交互。

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

用途:逻辑功能。



  1. 开发视图:

相关方:开发人员,测试人员。开发人员根据开发视图进行编码,把系统开发出来。

视角:系统如何实现,涉及到的是具体的东西了,到了这个层面,改确定的东西都已经确定了。比如:系统中要用到消息队列,那么在这里就要说明具体是使用哪个消息队列。

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

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



  1. 物理视图:

相关方:系统集成商、系统运维人员

视角:要多少服务器,服务器如何部署的,需要什么的网络节点

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



  1. 过程视图

相关方:性能优化,开发相关人员

视角:系统运行时线程、进程的情况。运行的过程是如何,调用关系是什么样子的,都经过哪些组件最终完成的。

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



  1. 场景视图

相关方:用户,设计和开发人员

视角:概括了架构上的重要场景,业务场景是什么样子的,功能及非功能性需求。如:用例图。



4+1视图的理念非常好,为什么不用一种视图完成架构设计呢? 一个东西,只有一面是平的,不立体的,没有根基的,不扎实的,一推就倒。4+1就是说一个系统有多个方面,不同的相关方关注点不同,每一种视图关注的面是不同的,要表达的信息也是不同的。开发者和老板客户关注的都是不同的。



5. 建模语言

使用uml进行建模。uml本身是很简单的,就那么一些语法,常用的模型。怎么用这个图来表达设计意图,这个是比较难的,如果脑子里面一片空白,那么uml是帮不了你的。

后面学习:用什么模型来表达设计意图,给什么人看。



  1. 什么是模型?

模型是一个系统的完整抽象。在开发之前如何把要做的系统表达出来,用到的就是模型。根据抽象变成现实。在系统还没开发出来之前,架构师脑子里就应该有一个完整的东西了,这个系统由哪些组件,哪些类。把脑子里面的东西画出来,就是系统的模型,系统的设计。



对现实的问题,进行分析、抽象形成概念模型。通过视图的方式表达出来,分析设计形成解决方案。一方面要抽象最后开发出来的系统,一方面要抽象现实中的业务问题。要设计的系统关系就是存在于现实之中的。如:电子商务,有买家,卖家,商品,订单这些都应该在模型里面。 如果设计的系统和现实是不一致的,那么开发的时候就会遇到问题。开发的时候要理解业务。





  1. 为什么要画出来呢?

一方面是自己看,自己验证一下模型是否合适。通过模型验证是否合理,最终的系统能不能达成预期的目标。

另一方面和别人进行沟通。



  1. 什么时候画图?

开会的时候,讨论交流时,用白板,白纸,软件画,然后方案就出来了。



  1. uml为什么叫统一建模语言?为什么叫语言呢?

语言就是交流和沟通的工具,画出来的图是为了给别人看的。重要的是表达设计意图,交流和沟通。



  1. uml分类

  2. 静态图

  3. 用例图、类图、组件图、部署图

  4. 动态图

  5. 序列图、活动图、状态图

  6. 通用的元素

  7. 类、状态、用例、组件

  8. 静态模型元素关系

  9. 依赖:相当于局部变量,或参数的依赖。有偶然性。关系弱一点

  10. 关联:一个类是另一个类的成员变量,关系强一点。

  11. 继承:继承了就能直接使用。

  12. 实现:要自己实现。

  13. 聚合:生命周期不一致,是聚在一起的,聚合出来的对象被销毁后,参与聚合的对象不会被销毁。

  14. 组合:类与类生命周期相同,同生共死。



  1. uml分类解读

用例建模:(用例图)

主要是功能需求描述,在宏观上给出一个中心轮廓。就是这个系统能做什么,都有什么样的功能,供哪些角色来使用,功能之间的关系是什么。

元素:角色(小人状),用例(椭圆状),要做的事情,边界(矩形的框)。这里面的每一个字都不是多余的。

边界:表示这个用例的边界,都包含了什么功能,有哪些角色,功能和功能之间的关系是什么(使用和扩展)

角色:可以是人,也可以是另一个系统。



使用场景:比原型更抽象,功能更聚焦,工作量也更少一点,一把般是在需求分析阶段,功能需求描述的时候使用。

用例图通常是有许多张的,用多个用例图来描述,一张图包含的元素不需要太多(十几二十个),如果描述不了,就用多张图描述。先来一个总的描述核心的关键功能 ,然后在往下细分成更多的图。





细化试例:



细化到什么程度?

细化到相关方能看懂为止。



类图:

主要是描述类之间的关系,继承,组合,聚合,实现,继承等关系,类包含了哪些方法。



场景:类图主要是在详细设计阶段,类名和方法名都有了。



uml中的消息:

简单消息、同步消息、异步消息



序列图:



任何阶段的可以使用时序图。描述任何对象之间的时序,调用关系。

需求分析阶段:画当前设计的系统和已有的系统之间的关系,调用某些功能,如调用支付系统完成支付功能。系统级的时序图。

概要设计阶段:画组件之间的交互组件时序图,组件和服务器之间的时序图。

详细设计阶段:方法之间的调用关系。

关注的是时序。



活动图:(流程图)



描述流程的。描述整个处理流程是怎么样完成的。使用永道工具,描述跨领域完成的流程。

关注的是流程。



使用场景:

需求分析:描述核心业务的完成流程,业务之间的处理流程。画业务的流程

概要设计:不同的模块,领域,子系统之间的处理流程是怎么样的

详细设计:画一个方法内部的处理流程。

状态图:

主要是描述状态变迁。在不同状态之间的变化关系。如:订单,创建,待支付,取消,待出货,已支付,配送中,已签收,待评价。状态图使用场景单一,效果倍棒。如果用文档描述容易产生分歧,特别是状态比较多的时候,状态变迁冲突。

下面这个是电梯的状态图:



使用场景:

需求分析:订单,创建,待支付,取消

详细设计:状态,假设用枚举表示状态,bool值的变迁。



组件图:

描述模块组件,模块的关系,边界。

设计到底在设计什么? 就是把功能里面的模块拆分清除,关系缕清楚。关键点组件的大小,组件之间的依赖关系。通常是依赖,关联关系,调用关系。大的功能组件可以继续划分若干个逻辑组件,组件的粒度细化到一个人能开发的粒度。



组件图不光是描述了组件之间的依赖,也描述了开发的过程,开发者的职责分配,和分工,开发依赖关系(模块之间的依赖,就是开发依赖关系),重要的组件可以分配给资深的工程师,工期如何排, 底层依赖的先开发,顶层的后开发。



概要设计阶段画组件图,静态关系。动态关系用组件时序图画。



部署图:

主要是物理部署。

一个立方体表示一个服务器。主要是服务器之间的关系,主要是设计的系统最后要部署到哪些服务器上,有些是现有的服务器,新的系统和其它系统之间的依赖关系。



部署图也是架构设计文档里面的第一张图。



软件设计分3个阶段

  1. 需求分析

  2. 输出需求文档

  3. 概要设计

  4. 概要设计文档

  5. 详细设计、

  6. 详细设计文档



总结

需求分析阶段画的图



  1. 用例图:核心的用例图,描述功能、场景。

  2. 活动图:业务流程,画不同的领域模型内用例有哪些。描述关键业务流程,处理流程是什么样子的。

  3. 状态图:核心对象,核心的业务状态变迁,比如:订单状态,下单,取消,待支付,已支付,退款,超时未付款等状态的变迁。

  4. 时序图:当前系统与外部系统的时序图。(外部系统级的依赖关系)



把系统要做的事情,背景约束,其它系统之间的关系,作为需求的一部分,作为一种约束表达出来。



概要设计阶段画的图

  1. 部署图:最顶层的,体统是长什么样子的,整体的蓝图,包含了哪些子系统,它们之间的依赖关系是什么样子的。

  2. 服务器或子系统级别的时序图:描述服务器的调用关系,依赖关系。部署图可能比较简单,所以并不是一定要有时序图

  3. 子系统级的活动图:子系统级处理业务是什么样子的。

  4. 组件图:组件之间的关系,依赖。粒度:细化到一个人能开发。

  5. 组件时序图:组件一定要画时序图,描述组件之间是如何调用的,依赖的。

  6. 组件活动图:关键场景组件之间的流转过程。跟时序图差不多。



详细设计阶段画的图

  1. 类图:类的结构,各个类之间的依赖关系。如:组合聚合,依赖关联,继承实现。

  2. 类的时序图:

  3. 状态图:某场景实际的状态变迁,状态的枚举值,状态变迁bool值。

  4. 方法的活动图:方法以及的活动题,一个类内部方法的业务处理流程。



架构师的最终产出就是一些uml模型,给工程师通过代码实现完成架构设计,相关的架构设计文档。和其他架构师交流,和老板交流。



uml工具本身是比较简单的,关键是如何表达出自己的想法,在什么场景下画什么图,如何用好这个是比较难的。脑子里面有没有系统的雏形。



架构设计是跟场景有关的,在现实需求的约束下,头脑里面有一个系统的设计雏形,如何雏形表达出来,一方面给相关的人看(老板),我的这个设计是能达到你的要求的。另一方面落地,开发的时候开发的工程师,能够按照架构设计完成系统。



架构师:把握住整个系统的架构设计,以及过程中的工作人员安排(如何合理完成工作)。理解面对的问题是什么,理解了问题就理解了解决方案为什么是这样子的。架构师是团队的技术核心,负责整体的架构设计,对架构负责,以及架构的落地,落地的过程就是工程师的开发过程,如何保证开发工程师的职责是清晰的,进度是可控的,都是架构师的责任,在架构设计的时候就要考虑这些,还有其他的一些相关方,要考虑到做的事情相关方有哪些,如何对他们负责。



用户头像

闷骚程序员

关注

还未添加个人签名 2018.11.15 加入

还未添加个人简介

评论

发布
暂无评论
架构师是怎样炼成的-1-2