成为架构师课程系列怎样进行系统详细架构设计？

Posted 2023-03-03 禅与计算机程序设计艺术

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了成为架构师课程系列怎样进行系统详细架构设计？相关的知识，希望对你有一定的参考价值。

前言

如果一个项目的系统架构（包括理论基础）尚未定义，就不应该进行此系统的全面开发。-- Barry Boehm, 《Software Engineering》

如果选择视图的工作没做好，或者以牺牲气体视图为代价，只注重一个视图，就会掩盖问题以及延误解决问题。-- Grady Booch, 《UML用户指南》

从概念架构到详细架构，

先设计概念架构，构思关键问题的解决策略；

再进行详细架构的设计，以保证为开发提供足够的指导和限制。

这符合人类解决问题的规律，因此被广泛采用。

但在实际中，详细架构设计还存在很多差强人意之处，甚至经常被忽视。

详细架构和概念架构之间存在如下典型差异：

接口：在详细架构中接口占据非常核心的地位，而概念架构并不明确接口定义（只有抽象的组件和抽象的交互机制）。
子系统：详细架构重视通过子系统和模块来分割整个系统，并且子系统往往有明确的接口；而概念架构中只有抽象的组件，这些组件没有接口，只有职责，一般是处理组件、数据组件胡哦哦连接组件中的一种。当然，概念架构中也有“大组件分解成小组件”的设计决策，但并非子系统的含义。
交互机制：详细架构中的交互机制应是“实在”的，如基于接口编程、消息机制或远程方法调用等；而概念架构中的交互机制是“概念化”的。例如“A层使用B层的服务”就是典型的例子，这里的“使用”到了详细架构中可能基于接口编程、消息机制或远程方法调用等其中的一种。

当然，概念架构和详细架构都满足软件架构的定义--无论是“架构 = 组件 + 交互”，还是“架构 = 重要决策”。

方案的设定，为什么需要项目负责人、需求人员、架构师等功能参与呢？因为方案涉及的工作内容不仅仅是架构，还涉及项目管理和需求工作。

“方案”和“架构”的联系与区别如下：

方案包含一定的架构内容
方案涉及的架构基本在概念架构一级
架构设计的工作还远未完成

所以，架构师应记住：

方案 = “项目 + 需求 + 架构”的总览

方案 ≠ 架构的全部

办公室里的争论

故事：办公室里，争论正酣

办公室里，关于什么是软件架构，争论正酣。

程序员说，软件架构就要决定要编写哪些类，使用哪些现成框架(Framework)。

程序经理说，软件架构就是模块的划分和接口的定义。

系统分析员说，软件架构就是为业务领域对象的关键建模。

配置管理员说，软件架构就是开发出来的及编译后的软件到底是啥结构。

数据库工程师说，软件架构规定了持久化数据的结构，其他一切不过是对数据的操作而已。

部署工程师说，软件架构规定了软件部署到硬件的策略。

用户说，软件架构就是决定一个个功能子系统如何划分。

大家想了想说，这些架构视图好像我们都需要啊，软件架构师哭了。

探究：优秀的多视图方法，应贴近实践

上述争论可以总结为一句话：不同涉众看待软件架构的视角是不同的。

但是，实际工作中架构师的工作范围如此广泛，多视图方法能系统的涵盖吗？例如：

进程、线程的相关设计
接口的定义
子系统的划分
服务器的选型
（若你用C）结构化方法的模块设计“放”哪里？
考虑Layer（逻辑层）
考虑Tier（物理层）
（基于并行开发的需要）源程序目录结构的定义
数据分布与数据库Schema
(若没选RDBMS而选了文件方式)文件格式的定义
（嵌入式系统常将数据保存到Flash）Flash存储结构的定义
......

答案是：贴近实践的多视图方法，应将各项工作涵盖其中。

运行架构
- 进程、线程的相关设计
逻辑架构
- 接口的定义
- 子系统的划分
- （若你用C）结构化方法的模块设计“放”哪里？
- 考虑Layer（逻辑层）
物理架构
- 服务器的选型
- 考虑Tier（物理层）
开发架构
- （基于并行开发的需要）源程序目录结构的定义
数据架构
- 数据分布与数据库Schema
- (若没选RDBMS而选了文件方式)文件格式的定义
- （嵌入式系统常将数据保存到Flash）Flash存储结构的定义

假设有一座漂亮的大房子，一个人站在房子的前面，一个人站在房子的后面，另外两个人分别站在房子的左右两侧。四个人看房子都有不同的视角，四个人都在争论自己看到的那一面是正确的一面，如果运用水平思考，那么这四个人就会绕房子一圈，分别看到房子前后左右四个面。-- 爱德华.德.博诺，《六顶思考帽》

总的来说，“架构”一词涵盖了软件架构的所有方面，这些方面紧紧的缠绕在一起，决定如何将之分割成部分和主题显得相当主观。既然如此，就必须引入“架构视点”作为讨论、归纳和理解大型系统架构的手段 -- Peter Herzum, 《Business Component Factory》

架构设计是一门解决复杂问题的实践艺术。于是，以分而治之为思想核心的多视图方法必不可少。

接下来主要介绍支持详细架构设计的整体思路--多视图方法。

什么是详细架构

详细架构是相对于概念架构而言的，它们是架构设计的两个层次，分别对应于“概念级”解决方案和“规约级”解决方案。需要注意的是，系统架构属于架构设计，不能和Detailed Design(详细设计)相混淆。

架构领域最喜欢将建筑设计的多视图方法与软件架构设计的多视图方法做类比，在此就不在进行赘述，而是举一个更贴近生活的例子：装修的多视图方法

功能视图
布线视图

通过运用装修的两视图法，你的装修设计摆脱在一个图里画来画去（想来想去）的困境。其中，装修设计的功能视图比较多的考虑：

家具
家电
灯
窗帘

而布线视图则集中考虑：

插座
网线
电话线
有线电视线

我们还发现，功能视图和布线视图是相互影响的，例如插座不能设计在大衣柜的后面，否则无法使用。这与软件架构设计的多视图方法中“兼顾多个视图设计之间的一致性”的要求是神似的，例如架构设计要考虑职责、程序单元、部署节点等要素之间的相互影响。

关于多视图方法的价值，Len Bass等专家在《软件架构实践（第2版）》一书中论述道：

神经科专科医生、整形医生、血液专家和皮肤科医生对人体结构有着不同的视图。眼科医生、心脏病专家和足病医生研究治疗的是身体的某个部分。运动学专家和精神病专家关注的是整个人体行为的不同方面。尽管这些视图是不同的并且具有差异巨大的属性，但它们都具有内在相关性：它们共同描述了人体的结构。

软件也是如此。现代系统非常复杂，很难一下领会。相反，在任何时刻，我们只能把注意力放在软件系统的一个或几个结构上。为了有意义的传达架构的信息，必须说明此刻正在讨论哪个或哪些结构--即采用的是架构的哪个视图。

所以，多视图方法有两个方面的实际意义：

利于思考（因为分而治之的思维方式）
便于交流（因为在一定程度上分类了涉众关注点）

业界现状

误认为多视图是`OO`方法分支

提问：Framework技术是OO的分支吗？不是，Framework本质上和面向对象无关，用C语言也可以编写Framework。更切切近本质的Framework的定义是：可以通过某种回调机制进行扩展的软件系统或子系统的半成品。

的确，OO方法太流行了，以至于很多技术都“变成”了OO的分支。

有同行也常常将多视图方法误认为是OO方法的分支。其实，无论是OO方法，还是结构化方法，都远未涵盖架构设计的全部。所以，只具有OO技能对架构师而言是不够的。

误将“视图”当成“阶段”

对架构设计方法而言，区分阶段和视图的概念是非常重要和必要的。

“左边”的观点--概念架构、逻辑架构、物理架构是3个不同的层次。其实这种观点不完全正确，因为逻辑架构和物理架构是架构设计同一阶段中须要同时考虑的两个方面--即二者是两个视图，而非两个阶段。

RUP 4+1视图

在软件架构发展史上，4+1视图方法具有重大贡献。

1995年，Philippe Kruchten发表了题为《The4+1 View Model of Architecture》的论文，标志着4+1视图方法的诞生。后来，Philippe Kruchten加入Rational公司，4+1视图演化为下图所示的模样。

RUP4+1视图方法有几个重要特点：

重视OO方法
Use Case驱动
强调模型的重要性

对应于上述3个特点，架构师在实践中应注意：

OO可以指导逻辑架构视图的设计，但是OO方法对物理视图等的设计指导很弱。另一方面，即使逻辑架构的设计，也未必都是以OO方法为指导的。例如，大量嵌入式软件系统和系统软件仍以C语言为主要开发语言，其逻辑架构设计还会以结构化方法为指导。
用例不是架构设计本身工作。4+1视图中的“4”是架构设计，“+1”是驱动因素。
建模切忌穷兵黩武。如果一个模型建立中没有启发思维，首次建立后从不修改，那么就要慎重考虑是不是“过度建模”了。

SEI 3视图

SEI的Len Bass等专家在《软件架构实践（第2版）》中阐述了“3视图”的观点，他们认为架构设计的工作应该包含3类视图：

模块视图：此处的元素是模块，它们是实现单元。模块表示一种考虑系统的基于代码的方法。模块被分配功能职责区域。这不怎么强调所开发出来的软件如何在运行时表现自己。模块结构能够回答诸如此类的问题：分配给每个模块的主要功能职责是什么？允许模块使用的其他元素是什么？它实际使用的其他软件是什么？什么模块通弄个泛化或特化（继承）关系与其他模块相关？
组件-连接器视图：此处的元素为运行时组件（它们是计算的主要单元）和连接器（它们是组件间通信的工具）。组件-连接器结构回答了诸如此类的问题：we和你们是主要执行组件？它们如何交互？什么是主要的共享数据存储？复制系统的那些不法？数据在系统中经过了哪些地方？系统的哪些部分可以并行运行？在系统执行时，其结构可能会发生怎样的变化？
分配视图：分配结构展示了软件元素和创建并执行软件的一个或多个外部环境中的元素之间的关系。它们回答了诸如此类的问题：每个软件元素在什么处理器上执行？在开发、测试和系统构建期间，每个元素都存储在什么文件中？分配给开发小组的软件元素是什么？

来源：《Software Architecture in Practice》

总的来说，SEI 3视图方法没有RUP 4+1视图方法影响大，但也值得架构师研究和体会的。

例如：

映射视图对实践很有启发。以源码为核心的开发单元要分配给开发人员；而目标单元要和吴磊节点有映射关系，通过安装、部署、烧写等时候藕断完成。
“架构 = 组件 + 交互”是业界的基本认识，应该在架构的每个视图都有自己关心的“组件”。

实践要领

一种优秀的多视图方法，应该能够比较完善的覆盖架构设计的各项哦工作内容，且将每项工作内容明确的、有理有据的、一目了然的规划到不同架构视图中去。

我们来介绍一下5视图方法的怨气，并用两幅画来说明5视图方法的主要思想：落错有致的将众多技术关键点划分成“群落”，“群落”高内聚，“群落”之间松耦合。所以，应用5视图方法，有利于架构师设计思维的“有序”展开。

缘起：5视图方法的提出

多视图方法是业界广泛认同的一种架构设计思路，具体的多视图方法繁多：

SEI的3视图方法。涉及视图为：模块视图、组件-连接器视图、分配视图。
西门子的4视图方法。涉及视图为：概念视图、模块视图、代码视图、执行视图。
RUP的4+1视图法。涉及视图为：用例视图、逻辑视图、开发视图、进程视图、物理视图。
联邦企业架构框架（Federal Enterpriese Architecture Framework）。涉及视图为：技术架构视图、信息架构视图、应用架构视图、业务架构视图。
其他......

其中，无疑是由Philippe Kruchten于1995年首次提出的4+1视图方法的影响最大。