假如你是架构师，你要作些什么

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

前期思考

　　不少软件开发同窗的职业规划都是架构师，试想这样一个场景，若是公司安排你作架构师，让你在项目开发前期进行了一些架构设计。

• 你该如何开展你的工做？
• 应该如何说出你的工做成果？
• 你如何肯定你的设计是否知足用户需求的？
• 你是否有把握最后交付的软件是知足要求的？
• 是否有把握让软件团队每一个工程师清晰了解本身的职责范围，并有效的完成开发工做?

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

• 如何进行软件设计？
• 软件设计的输出是什么？
• 软件升级过程当中如何和各个相关方沟通？
• 软件设计如何既能知足用户的功能需求，又能知足用户的非功能需求，也能知足用户的成本要求？
• 如何可以使开发工程师，测试工程师，运维工程师，理解软件的总体架构，主要模块划分，关键技术实现，核心领域模型，使他们可以作好本身的工做，从而使整个软件开发过程，处于一个可控的范围以内，并在软件开发之初，就对软件将来的蓝图有个清晰的认识？

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

核心关键点

两个客观存在

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

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

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

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

• 软件有哪些主要组成？
• 这些类如何组织成一个一个的组件？
• 这些内核组件之间的依赖关系是如何的？
• 运行期如何调用，须要部署多少台服务器？
• 服务器之间如何通讯？

　　因此这两方面的客观存在的抽象就是咱们的软件模型。

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

　　

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

UML工具

　　软件建模工具不少，目前主要是统一建模语言UML。

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

　　而所谓的语言，一则用于沟通，知足设计阶段和各个相关方沟通的目的，一则用于思考，即便软件开发过程当中不须要跟其余人沟通，或者尚未到了沟通的时候，依然可使用UML建模，帮助本身进行设计思考。

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

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

7种软件模型

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

类图

　　

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

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

序列图

　　

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

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

组件图

　　

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

　　组件图描述中间之间的静态关系，主要是依赖关系，若是想要描述组件之间的动态调用关系，可使用组件序列图，以组建做为参与者，描述组件之间的消息调用关系，由于组件的力度比较粗，一般用于描述设计软件的模块及其之间的关系，须要在设计早期阶段就画出来。

部署图

　　

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

• 根据部署图，全部相关者，客户，老板，工程师，都可以清晰的了解到最终运行的系统，物理上是什么样子？和现有系统服务器的关系，和第三方服务器的关系。
• 根据部署图，还能够估算出服务器和第三方软件的采购成本。

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

用例图

　　

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

状态图

　　

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

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

活动图

　　

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

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

总结

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

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

需求分析

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

　　核心领域对象，能够经过简化的类图进行模型领域抽象，并描述核心领域对象之间的关系。

　　若是某些对象内部有复杂的状态变化，好比用户，订单这些，能够用状态图进行描述。

概要设计

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

详细设计

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

来源：http://www.javashuo.com/article/p-ciajrhcf-er.html 欢迎关注公众号 【码农开花】一块儿学习成长 我会一直分享Java干货，也会分享免费的学习资料课程和面试宝典 回复：【计算机】【设计模式】【面试】有惊喜哦