查看原文
其他

假如你是架构师,你要做些什么

张飞洪 SpringForAll社区 2021-05-26
点击上方☝SpringForAll社区 轻松关注!
及时获取有趣有料的技术文章

本文来源:

https://www.cnblogs.com/jackyfei/p/12093951.html


很多做软件开发同学的梦想都是成为一名架构师,而架构师的核心工作就是做好软件设计。软件设计是软件开发过程中的一个重要环节,那么如何进行软件设计,其输出标准又是什么呢?软件设计过程中,如何和各个相关方沟通,使软件设计能同时满足用户的功能需求和非功能需求,并降低公司的开发成本? 


前期思考

  很多软件开发同学的职业规划都是架构师,试想这样一个场景,如果公司安排你做架构师,让你在项目开发前期进行了一些架构设计。

  • 你该如何开展你的工作?

  • 应该如何说出你的工作成果?

  • 你如何确定你的设计是否满足用户需求的?

  • 你是否有把握最后交付的软件是满足要求的?

  • 是否有把握让软件团队每个工程师清晰了解自己的职责范围,并有效的完成开发工作?

      架构师的核心工作就是做好软件架构设计,软件设计是软件开发过程中一个重要的环节。

  • 如何进行软件设计?

  • 软件设计的输出是什么?

  • 软件升级过程中如何和各个相关方沟通?

  • 软件设计如何既能满足用户的功能需求,又能满足用户的非功能需求,也能满足用户的成本要求?

  • 如何能够使开发工程师,测试工程师,运维工程师,理解软件的整体架构,主要模块划分,关键技术实现,核心领域模型,使他们能够做好自己的工作,从而使整个软件开发过程,处于一个可控的范围之内,并在软件开发之初,就对软件未来的蓝图有个清晰的认识?

      以上这些诉求可以说是软件开发管理与技术的核心诉求,这些问题搞定了,软件的开发过程和结果也就得到了保障。

核心关键点

两个客观存在

  我们再来看看,解决这些问题你需要理解的核心关键点,也就是说究竟如何做软件设计,解决方法就是软件建模,就是软件的抽象模型,这些模型之上配上文字说明,就形成了软件的设计文档。

  模型是对客观存在的抽象,在软件开发中有两个客观存在:

  一个是我们要解决的领域问题,比如我们要开发一个电子商务网站,那么客观的领域问题就是如何做生意,卖家如何管理商品,管理订单服务用户,买家如何挑选商品,如何下单,如何支付等等,对于这些客观领域问题的抽象就是各种功能及其关系,各种模型对象及其关系,各种业务处理流程。

  另一个客观存在就是最终开发出来的软件系统,这个软件系统也是客观存在的。

  • 软件有哪些主要组成?

  • 这些类如何组织成一个一个的组件?

  • 这些内核组件之间的依赖关系是如何的?

  • 运行期如何调用,需要部署多少台服务器?

  • 服务器之间如何通信?

      所以这两方面的客观存在的抽象就是我们的软件模型。

      一方面,我们要对领域问题和软件系统进行分析,设计抽象,另一方面,我们根据抽象出来的模型,进行软件开发,这就是软件开发的主要过程。

      

    img

      而对领域问题和软件系统进行分析,设计抽象,这个过程我们称它为软件建模与设计

UML工具

  软件建模工具很多,目前主要是统一建模语言UML。

  所谓的建模,就是对领域问题和软件系统进行抽象设计,一个工具完成前述软件开发过程中的两个客观存在的建模。

  而所谓的语言,一则用于沟通,满足设计阶段和各个相关方沟通的目的,一则用于思考,即使软件开发过程中不需要跟其他人沟通,或者还没有到了沟通的时候,依然可以使用UML建模,帮助自己进行设计思考。

  此外,语言还有个特点,就是有方言,就我观察不同公司,不同团队,都有自己的特点,并不需要拘泥于以往那样规范和语法,只要不引起歧义,在使用过程中对语法元素适当变通,这是UML的最佳实践。

  软件建模与设计过程又可以拆分成需求分析,概要设计,详细设计三个阶段,而软件建模的主要工具是UML,下面我们看一下使用方法包含了哪些软件模型,常用的有7种。

7种软件模型

  下面我们讨论这7种模型图,如何在三个阶段使用。

类图

  

img

  类图是最常见的UML图形,用来描述类的特性和类之间的静态关系,一个类包含三个部分,类的名称,类的属性列表,类的方法列表之间有6种静态关系关联,关联,依赖,聚合,组合,继承,泛化,而相关的一组类及其关系,用一张图画出来就是类图,类图主要是在详细设计阶段化,如果内图已经设计出来了,那么开发工程师只需要按照内图实现代码就可以了,只要类的方法逻辑不是太复杂,不同的工程是实现出来的代码几乎是一样的,从而保证软件的规范统一。

  实践中通常不需要把一个软件所有的类都画出来,把核心的有代表性的,有一定技术难度的内画出来,一般就可以了,除了在详细设计阶段画类图,在需求分析阶段,也可以将关键的领域模型对象图,用例图画出来,这个阶段,关注的是领域对象的识别及其关系,所以通常用简化的类图来描述。

序列图

  

img

  序列图描述类之间的关系,描述参与者自己的动态调用关系,每个参与者有一条垂直向下的生命线,用虚线表示,而参与者之间的消息,也从上到下表示其调用的前后顺序关系。

  每个生命线都有个结果,只有在参与者活动的时候才是激活的,序列图通常用于描述对象之间的交互,这个对象可以是类对象,也可以是更大粒度的参与者,比如组件,比如服务器,比如子系统。总之,只要描述不同参与者之间的交互的,都可以使用序列图,也就是说,在软件设计的各个阶段,都可以画序列图。

组件图

  

img

  组件是更大粒度的设计元素,一个组件中通常包含多个类,组件图有时候和包的用途比较接近,组件可以描述逻辑上的组件,也可以描述物理上的组件,比如一个JAR,一个DLL的,因此组件图更灵活一点,实践中,用组件图而不是包图进行模块设计更常见一些。

  组件图描述中间之间的静态关系,主要是依赖关系,如果想要描述组件之间的动态调用关系,可以使用组件序列图,以组建作为参与者,描述组件之间的消息调用关系,因为组件的力度比较粗,通常用于描述设计软件的模块及其之间的关系,需要在设计早期阶段就画出来。

部署图

  

img

  他是描述软件系统的最终部署情况,需要部署多少台服务器?关键组件都部署在哪些服务器上?部署图呈现的是系统最终物理呈现的蓝图。

  • 根据部署图,所有相关者,客户,老板,工程师,都能够清晰的了解到最终运行的系统,物理上是什么样子?和现有系统服务器的关系,和第三方服务器的关系。

  • 根据部署图,还可以估算出服务器和第三方软件的采购成本。

      因此,部署图是整个软件设计模型中比较宏观的一张图,在设计早期就需要画的一张模型图。根据部署,各方可以讨论是否对这个方案认可,只有对部署图达成共识,才能够继续后面的细节设计,部署图主要用在概要设计阶段。

用例图

  

img

  主要在需求分析阶段,通过反映用户和软件系统之间的交互,描述软件的功能需求,图中小人物被称为角色,角色可以是人,也可以是其他的系统,系统的功能可能会很复杂,所以一个用例图,可能只包含其中一小部分功能,这些功能被一个巨型框框起来,这个巨型框被称为用力的边界,框里的椭圆,表示一个一个的功能,功能之间可以调用依赖,也可以进行功能扩展,因为用例图中功能描述比较简单,通常还需要对用例图配以文字说明,形成需求文档。

状态图

  

img

  用来展示单个对象生命周期的状态变更,业务系统中,很多重要的领域对象对于比较复杂的状态变迁,比如账号,有创业状态,激活状态,冻结状态,欠费状态等等各种状态,因此,用户订单商品红包这些常见的领域模型,都有多种状态,这些状态的变迁描述,可以在用例图中用文字描述,随着角色的各种操作而改变,但是这种描述方式,状态散落在各处,做开发的时候容易搞错,就是产品经理自己在设计的时候,也容易搞错对象的状态变迁,状态图可以很好的解决这一问题。

  一张状态图描述一个对象生命周期的各种状态及其变迁的关系。

活动图

  

img

  主要用来描述过程逻辑,业务流程。UML中没有流程图,很多时候人们用活动图代替流程图,活动图和早期流程图的图形元素也很接近.

  实心圆代表流程开始,空心圆代表流程结束,圆角矩形表示活动,菱形表示分支判断,此外,引入了一个重要的概念,泳道。可以根据活动的范围,将活动根据领域,系统角色的,划分到不同的泳道中,使流程边界更加清晰明了。

总结

  模型图本身并不复杂,几分钟的时间就可以学习一个模型图的画法。难的是如何在合适的场合下用正确的UML模型,表达自己的设计意图,从而形成一套完整的软件模型,进而组织起一个言之有物,层次分明,可以指导开发,在团队内部达成共识的设计文档。

  我们从软件设计的不同阶段这一维度重新梳理一下,如何使用正确的模型进行软件建模。

需求分析

  在需求分析阶段,主要是通过用例图描述系统的功能与使用场景;对于关键的业务流程,可以通过活动图描述。如果在需求阶段,就提出要和现有的某些子系统整合,可以通过时序图,描述新系统和原来的子系统的调用关系。

  核心领域对象,可以通过简化的类图进行模型领域抽象,并描述核心领域对象之间的关系。

  如果某些对象内部有复杂的状态变化,比如用户,订单这些,可以用状态图进行描述。

概要设计

  在概要设计阶段,通过部署图,描述系统最终的物理蓝图,通过组件图以及组件时序图,设计软件主要模块及其关系,还可以通过组建活动图,描述组件之间的流程逻辑。

详细设计

  在详细设计阶段,主要输出的就是类图和类的时序图,直到最终的代码开发,如果某个类方法内部,有比较复杂的逻辑,那么可以画方法的活动图进行描述,UML的工具可以是很复杂的,收费的,比如EA这样的大型软件工具。也可以使用processon在线的免费的工具。对于一般的开发者,建议从简单的用起,因为那个建模可以很复杂,也可以很简单,简单掌握类图,时序图,组件图,部署图,用例图,状态图,活动图。在7种模型图,灵活的在需求分析,概要设计详细设计阶段,根据场景的不同,绘制对应的模型图,可以实实在在的做好软件建模,搞好系统设计,作为一个掌控局面,引领技术团队的架构师。


● 微服务划分的姿势

● Java IO模型之NIO模型

● MongoDB 集群构建:分片+副本+选举

● Fork-Join框架

● Spring Boot实现动态增删启停定时任务

● MongoDB - 用户与权限

● SpringForAll社区,2019年文章精选10篇

● 高并发系统中的限流应该如何做?

● 经验:一个秒杀系统的设计思考!

● 如何设计缓存系统:缓存穿透,缓存击穿,缓存雪崩解决方案分析

● 微服务 2.0 技术栈选型手册

● 你需要的大厂在用的分库分表方案,都在这里!

● 拜托,面试别再问我数据库的分库分表!

 Spring Boot实战:逐行释义HelloWorld

 Spring Boot的自动配置、Command-line Runner

● SpringRetry重试机制

● 高性能的零拷贝技术原理你真懂吗?

● Java 文件处理 Paths & Files

● Spring Boot 应用 - 静态视频资源实时播放新姿势

● 面试 Spring Boot 再也不怕了,答案都在这里了!

● Spring Boot 默认的指标数据从哪来的?

● 技术人面对裁员的终极解决方案-反脆弱


    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存