软件架构 (1)-- 架构方法
1、架构定义
1.1、什么是软件架构
软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
关于软件架构的定义，可以由一下八个部分组成(如图)：
系统、架构、架构元素、元素间关系、架构文档、相关方、架构视图、关注点。
软件及系统，既然是系统，必然就有架构。
架构由架构元素和元素间关系组成，架构元素包括各个组件、服务器，组件间可能存在依赖或调用关系，就是架构元素间关系。
每个架构都应该有架构文档，架构文档描述了架构元素和元素间关系，架构文档的关键信息就是架构视图，每个架构视图的关注点不一样。
架构文档是给相关方描述的，相关方包括老板、业务方、产品经理、工程师等。面向老板、业务方的架构文档，主要用作技术决策并期望方案得到认可，关注点在关键功能、性能等，应较为宏大的；面向产品经理、工程师的架构文档，主要用作指导架构开发落地，应较为细节的。
架构师重点在于，应当抓住相关人的关注点，提供给他们想要的信息，并让他们满意，然后推动架构开发落地，并对整个系统架构负责。
1.2、什么是架构师
架构师是做架构师、对系统架构负责的那个人。架构师是一顶帽子，而不是一把椅子；架构师是一个角色而不是一个职位。不管是工程师还是小组长还是团队负责人，谁能对系统架构负责，谁就是架构师。
1.3、架构师主要能力
编程能力
基础技术掌握能力
常用技术产品的理解与应用能力
性能优化与分析故障的能力
常用架构模式和框架的理解与应用能力
建模以及设计文档的方法和能力
业务理解与功能模块及非功能模块拆解能力
快速学习能力
沟通与领导能力
1.4、如何做软件架构
编写架构设计文档
开发编程框架
重构软件代码
设计系统架构
进行技术选型，解决技术应用中的问题
优化系统性能
模块分解与微服务架构重构
保障系统安全与高可用
大数据应用
技术创新
沟通管理
2、架构视图
2.1、4+1视图模型
架构文档主要包含架构视图，因为单一的视图无法完整的描述整个架构，因此需要具备完整的视图集。4+1视图模型不仅能完整表达架构设计和系统开发的方方面面，又能向不同的相关方提供其关注的内容。4+1视图模型主要包含以下几种架构视图：
逻辑视图（logical view），设计对象模型
过程视图（process view），捕捉设计的并发和同步特征
物理视图（physical view），描述了软件到硬件的映射，反应了部署特征
开发视图（development view），描述了在开发环境中软件的静态组织结构
场景视图（scenarios），描述用例场景
4+1视图模型中的1就是场景视图，其他4中视图都与场景视图相关联：
2.1.1、逻辑视图
相关方：客户，用户，开发组织管理者。
视角：系统的功能元素，以及它们接口，职责，交互。
主要元素：系统，子系统，功能模块，子功能模块，接口。
用途：开发组织划分，成本/进度的评估。
比如功能模块就是逻辑视图的一种：
2.1.2、过程视图
相关方：性能优化，开发相关人员。
视角：系统运行时线程，进程的情况。
主要元素：系统进程，线程以及处理队列等。
2.1.3、物理视图
相关方：系统集成商，系统运维人员。
视角：系统逻辑组件和物理组件之间的部署关系，和物理网络配置关系，是系统最终物理呈现的样子。
主要元素：物理节点以及节点的通信。
2.1.4、开发视图
相关方：开发相关人员，测试人员
视角：系统如何开发实现
主要元素：描述系统的层，分区，包，框架，系统通用服务，业务通用服务，类和接口，系统平台和相关基础框架。
用途：指导开发组织设计和开发实现
比如典型的类图，工程师根据类图开发出相关类：
2.1.5、场景视图
相关方：用户，设计和开发人员。
视角：概括了架构上最重要的场景（最典型或者最具风险）及其非功能都性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式。
典型的代表就是用例图：
3、UML统一建模语言
在实践中，一般并不是严格按照4+1视图模型去做架构视图，4+1视图模型提供了一个架构设计维度的启发和思考点，告诉我们需要关注这些方面，在具体设计的时候，更多的是用UML。
UML统一建模语言，统一也就是标准，早期有许多各种各样建模工具，经过时间整合加上历史原因，UML渐渐成为了业界的标准；建模也就是建造模型工具；语言是用来进行交流和沟通的，模型也是用来进行交流和沟通的，通过UML传递架构设计方案，并让工程师按照设计落地开发。使用统一的语言，才能更加有效的沟通，大家都说“普通话”，才能建立一致的沟通频道。
既然是建模工具，我们先来了解什么是模型，以及为什么要建造模型。
什么是模型？
模型是一个系统的完整抽象。人们对某个领域特定问题的求解及解决方案，对它们的理解和认知都蕴含在模型当中。
通常，开发一个计算机系统或软件是为了解决某个领域特定问题，问题的求解过程，就是从领域问题到计算机系统的映射。通俗理解就是系统设计到开发落地。
比如开发一个电子商务系统，会面对商务上的各种领域问题，包括商品、订单、交易、合同等。然后通过分析、抽取出关键核心的业务，抽象出相关领域模型和设计模型，最后再经过分析与设计得到最后的解决方案，这个解决方案也就是开发出来的软件。
模型就是软件架构设计的关键，如果没有对领域问题进行抽象出领域模型和设计模型，就无法把控最后开发出来的系统的样子，当系统日益庞大，最后只能看到一堆功能和逻辑，理不清系统全貌和组件间关系，走一步看一步有问题就改一点，天天996仍然bug不断，让人十分痛苦。
为什么要建造模型？
目的一：为了验证某个事物能否工作。
因为建造模型的成本远远低于实际建造实物的成本，不能说要系统开发出来才能验证这个事务是否正确。我们画架构图，做架构设计，其实就是在建模。
目的二：为了与它人沟通，为了保存软件设计的最终成功。
在没有代码和系统前，便是通过模型与他人进行沟通评估评审，看是否满足业务需求。保存软件设计的最终目标，保证即使开发过程人员变动，依然能保证目标不偏离。
何时、何处画图？
讨论、交流、思考时，可以在白板上画，也可以提前画好图，绘图工具如Visio、draw.io、Aastah。
最终设计文档
只保留少量的、重要的图
避免涉及过多内容和实现细节
3.1、UML软件架构建模的一般方法和工具
UML图主要分为静态图和动态图
静态图包括
用例图（Use Case Diagrams）
对象图（Object Diagrams）
类图（Class Diagrams）
组件图（Component Diagrams)
包图（Package Diagrams）
部署图（Deployment Diagrams）
动态图包括
协作图（Collaboration Diagrams）
序列图（Sequence Diagrams）
活动图（Activity Diagrams）
状态图（State Diagrams）
其中包图、对象图、协作图实践中较为少用，其余7中较为常用，重点讨论。
模型图中主要包含模型元素和模型元素间关系。
模型元素，常用元素符号有：类、对象、结点、包和组件等。
模型元素间关系，常见关系有关联(association)、泛化(generalization)、依赖(dependency)、聚合(aggregation)。
依赖与关联，关联关系比依赖关系更加紧密，比如成员变量一般是关联关系，而成员方法内的局部变量一般是依赖关系。
继承与实现，继承即继承一个父类，实现则是实现一个接口。
聚合与组合，两者都是表示整体与部分的关系，在聚合中当整体不存在是，部分仍可以存在，比如汽车与轮子，轮子还可以复用；而组合关系更强，当整体不存在，部分也没有了存在的意义，比如身体与四肢。
3.1.1、用例建模
用例图描述用户或子系统在用户边界内有哪些具体功能，通过用例分析，使开发者能够有效地了解用户的需求。方框外面是执行者(Actor)，执行者可以是人也可以是子系统，用例总是有执行者启动的；方框表示边界；椭圆表示具体功能。
需求分析阶段主要产生的就是用例图。
《Use》表示一个用例使用另外一个用例。
《Extend》通过向被拓展的用例添加动作来拓展用例。
这两种都是不同形式的泛化关系。
例：项目与资源管理系统的Use Case图
系统主要功能：项目管理、资源管理、系统管理。
分析确定系统的执行者（角色）
系统管理员、资源管理员、系统管理员、备份数据系统。
确定用例
项目管理，资源管理和系统管理
对用例进行分解，画出下层的Use Case图
对上层的用例进行分解，并将执行者分配到各层次的Use Case图中。
3.1.2、静态建模
任何建模语言都以静态建模机制为基础，所谓静态建模是指对象之间通过属性相互联系，而这些关系不随时间而移动。
类和对象的建模，是UML建模的基础。UML的静态建模机制包括：
用例图(Use case diagram)
类图(Class diagram)
对象图(Object diagram )
包图(Package diagram)
组件图(Component diagram)
部署图(Deployment diagram)
类与对象
面向对象开发的基本任务是建立对象模型，UML中的类图和对象图表达了对象模型的静态结构。
属性就是成员变量，操作就是方法或者函数。
例：
+ 公有的；- 私有的；# 受保护的。在详细设计阶段将主要类图画出来，
3.1.3、动态建模
动态模型主要描述系统的动态行为和控制结构。
包括以下四中类图：
状态图（State Diagrams）：状态图用来描述对象，子系统，系统的生命周期
活动图（Activity Diagrams）：着重描述操作实现中完成的工作以及用例实例或对象中的活动，活动图是状态图的一个变种。
时序图（Sequence Diagrams）：是一种交互图，主要描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例的行为。
协作图（Collaboration Diagrams）：用于描述相互合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系。
时序图
包括两组坐标轴：水平轴表示对象，垂直轴表示时间线。对象是广义的，粒度可大可小。
在需求分析阶段，可以画子系统之间的时序图；
在详细设计阶段，可以画服务器、组件、子系统、类的时序图；
活动图
UML中没有流程图，活动图就相当于流程图。
图中包含顾客、售货、库房三个泳道。一个泳道就是一个领域。泳道粒度可大可小。
在需求分析阶段，应该产出活动图。通过活动图分解出组件、功能模块、服务。通过泳道，分析服务设计是否合理，边界划分是否清晰。
状态图
描述对象状态的变迁。
合作图
也就是协作图，可以由时序图生成，相当于没有时序的时序图。
组件图
描述组件和组件间关系，确定合理的组件粒度大小。
组件对象可以是类对象，也可以是组件对象。
可以有下列类型的构件：源代码构件、二进制构件、可执行构件。
部署图
描述最终系统的部署情况，描述系统蓝图，通常是在概要设计阶段要画的图，也是软件设计的第一张图。
总结：
自顶向下的架构设计，在架构设计的开始，首先呈现的第一张图应该是部署图。然后在部署图描述了服务器和关键组件，组件图应运而生，通过组件时序图描述出组件间动态关系，然后再进一步画出组件的类图。
逐步细分，这些模型和视图就组成了架构设计文档。
注：高阶，指一些比较重要的类图，在概要设计就要体现出来。比如用户、商品、订单的信息，相当于领域分析。
3.2、架构设计文档
包含了UML建模的视图加上文字描述。
参考设计文档模板：https://pan.baidu.com/s/1T5PHIHu3k9Kq_hGTyc-Hrw 密码:fj6e
版权声明: 本文为 InfoQ 作者【Zeke】的原创文章。
原文链接:【http://xie.infoq.cn/article/ba51a5b7b1c4638ae7f81e07a】。文章转载请联系作者。
还未添加个人签名 2018.05.03 加入
还未添加个人简介
评论