什么是软件架构

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

-维基百科

软件架构关心的是整体和部分之间的关系。任何一个系统都应该有一个架构，这个架构是由架构元素和元素之间的关联关系组成。任何一个架构都应该有架构文档，架构文档是给相关方看的，因此在架构文档中为相关方关注的点所绘制的视图为架构视图，不同的相关方对于架构视图关注的点是不同的，不同的架构视图构成架构文档。软件设计的真正目的是降低开发人员的工作成本，开发人员可以不用关注与技术细节与原理，能够提高开发人员软件开发的效率。



如何说服大家

问题不在于如何说服大家，沟通的表象是在沟通，但是沟通的背后是你对事物规律的认知，只有正确的认识到事物背后规律，才能找到正确解决事物的途径，总之，看问题要找到问题的根本原因，学会透过现象看本质。

什么是架构师

架构师是真正做架构设计、对系统架构负责的人，而不是一个职位，能够通过架构设计理清系统的整体逻辑，把系统开发落地，解决期间的各种问题，能够帮助开发人员降低噪音，让开发人员只关注与业务实现，提高开发的效率和质量。



架构师要先有深度，才能有广度。



4+1架构视图

软件架构={元素，形式，关系/约束}，单一的视图无法完整的表达架构，因此需要具备完整的视图集。

• 逻辑视图： 设计的对象模型

• 过程视图：捕捉设计的并发和同步特征

• 物理视图：描述了软件到硬件的映射，反映了部署特性

• 开发视图：描述了在开发环境中软件的静态组织结构

• 场景视图：描述用例场景

4+1是因为场景视图跟其他四个视图是关联的，在不同的场景下，其他的四个视图会有不同的表现。

UML

什么是模型？

模型是一个系统的完整的抽象。人们对某个领域特问题的求解及解决方案，对他们的理解和认识都蕴涵在模型中。模型是软件设计的关键，而软件设计是软件架构的关键。

模型是对业务领域以及未来要开发的计算机系统的一个抽象，使这个抽象能够在计算机系统还未开发出来之前，我们就能够完整的对这个系统有个概念，从而对它进行评估评审讨论，在开发的过程中又能够指导开发。



为什么要建造模型？

• 为了与他人沟通

• 为了保存软件设计的最终成果

UML图的分类

静态图

用例图、对象图、类图、组件图、包图、部署图

动态图

协作图、序列图、活动图、状态图

10种图，常用的只有7种，其中对象图、包图和协作图不常使用。

通用模型元素

常用元素符号



常用连接关系

依赖和关联：关联关系更紧密一些，依赖关系更松散一些，比如：成员变量为关联关系，成员方法内的局部变量为依赖关系；

聚合和组合：组合相比于聚合是一种更强的关系。对象聚合在一起，当聚合关系不存在时，聚合的对象还可以存在，但如果是组合在一起，如果组合的关系不存在，那么对应的对象也不存在。

常用模型



用例图

用例图用于描述系统的功能需求，在宏观上给出模型的总体轮廓，使开发者能够有效的了解用户的需求。用例图可以自顶向下不断精化，抽象出不同层次的用例图，主要是在需求设计阶段。



类图

通过类图能够知道某一个功能某一模块的核心类有哪些，类的详细信息有哪些，类与类之间的关系是什么，主要是在详细设计阶段。

时序图

用描述对象之间动态的交互行为，着重体现对象间消息传递的时间顺序。

存在两个轴：

• 水平轴表示一组对象

• 垂直轴表示时间

活动图

泳道图是活动图中最长使用的视图。泳道进一步描述完成活动的对象。是一种分组机制，可以描述阔系统的交互互动。

状态图

状态图用来描述一个特定对象的所有可能的状态及其引起状态转移的事件。所有对象都具有状态，状态是对象执行了一系列活动的结果。

组件图

组件可以看作包与类对应的物理代码模块，逻辑上与包、类对应，实际上是一个文件。组件之间的依赖关系是指结构之间在编译、连接或执行时的依赖关系。

部署图

部署图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件，即系统运行时刻的结构。

小结

没有设计文档就没有软件设计，没有软件设计就没有技术进步。设计文档时团队中交流和协同开发的重要工具，是一项重要技能，设计文档能够考察出对系统的理解程度，对问题的抽象能力，要养成写设计文档的习惯。