软件设计·体系结构设计(Architectual Design)

学习目标：

1. 解释体系结构设计的定义和它的重要性
2.  解释在体系结构设计阶段必须做出的体系结构设计决策
3. 描述三种互补的体系结构设计风格，包括组织、控制和分解
4. 解释用来交流用的参考模型
5. 比较不同的体系结构 

一、体系结构定义

1.  如果我们把整个软件想象成一个房子，那么软件的体系结构就类似于房屋的平面图，它描述了房间的整体布局，比如说各个房间的尺寸大小，形状，相互连接的方式等等，也就是说，它为我们提供了软件的整体视图
2. 定义：程序或者系统的软件体系结构是指系统的一个或者多个结构，它包括了软件构件、构件的外部可见属性以及它们之间的相互关系
3. 体系结构设计是软件设计过程中的第一步，是设计和需求工程之间的桥梁，因为它可以识别系统的主要结构组件和它们之间的关系
4. 体系结构在具有相似的需求的系统之间进行互用，大多数应用系统都符合特定的领域和特定的类型，适合于这种类型的风格可能有一种或者多种
5. 体系结构设计的输出 ：体系结构模型，体系结构模型描述系统是如何由一组交互的组件组成的，也就是描述软件的体系结构(Software Architecture)

下图展示了一个打包机器人系统的系统体系结构的抽象模型，我们可以通过这个模型很清楚地看出这个机器人系统是如何进行工作的，系统内部的构件又是怎样交互，怎样处理各种输入输出，怎样进行数据传递的 

5. 我们可以把我们要构建的软件系统想象成一个用各种各样的积木搭建的城堡，在搭建之前，我们要想好我们需要哪些种类的积木，是圆柱形还是正方体，是红色还是白色，这些积木就相当于软件系统的构件，然后我们需要考虑怎么搭建，一个正方体上是放正方体还是圆柱？如果放圆柱的话放在正中心还是左上角？要不要嵌入？这其实就对应软件系统构件之间的相互关系

6. 对软件体系结构的描述/理解：

“一千个人眼中有一千个哈姆雷特”，同样，对于体系结构这个词的理解，每个人有每个人的理解，因为不同的参与者会从不同的角度理解体系结构，这个角度是由不同的关注点驱动的，换句话说，体系结构实际上是描述一组体现系统不同视图的工作产品(Different Views of the same architecture).

说得明白一点，对于一张设计项链的设计图，设计师可能觉得这是自己做好的工作产品或者说设计决策，在客户眼里这就是自己将要得到的项链的基本样子，对于工匠而言，他可能觉得这是今后工作的说明书

那么对于软件体系结构来说：

• 对于编写程序的程序员来说,软件体系结构更多的是一种蓝图(Blueprint)，蓝图就是一个详细的、各部分完全协调的计划或行动规划，对于开发人员来说，体系结构更多的是一种传递信息的工具,从体系结构分析师到设计师乃至生产系统构件的软件工程师之间都可以传递这种信息
• 对于拥有较高的用户视野的参与者，比如说管理者和市场专业人士，他们会将体系结构看成一种语言(Language)，侧重于将其视为不同角色人群之间进行沟通的工具
• 体系结构也可以看成基于成本、可用性、维护性、性能等属性进行权衡和取舍之后做出的决策(Decision).这些决策可能会影响到任务的排序和软件团队的组成
• 对于软件维护人员和关心构件和设计重用的项目相关人员来说，体系结构是一种文献(Literature),文献比喻对过往已经搭建完成的体系结构形成的方案文档

7. 体系结构的重要性：

• 体系结构提供了一种表示，有助于对于计算机系统开发感兴趣的所有利益相关者开展交流
• 体系结构突出了早期的设计决策，这些决策对随后的所有软件工程工作有深远的影响
• 体系结构"构建了一个相对小的、易于理解的模型，该模型描述了系统如何构成以及其构件如何在一起工作"

二、体系结构风格

体系结构风格其实是一种描述特定系统组织方式的惯例，强调了软件系统中通用的组织结构，它是一种施加在整个系统设计上的一种变换，目的是为了所有的构件设计一种结构

我们可以将这个定义和现在使用的各种模版相对应，比如说PPT模版(包括了有哪些构件、构件之间怎么联系和摆放、有没有特殊意义…)，在做工作汇报的时候，为了节省时间同时得到更好的效果，我们会倾向于找一个自己满意的已经做好的模版，这个模版可能是简约风格，可能是可爱风格，任你选，但是因为每种风格描述一种系统类别，所以要根据具体的需求来选择，就像你不能用花里胡哨、流光溢彩的PPT模版来汇报工作一样

简单分类

1. 以数据为中心的体系结构(Data centered architecture):

数据存储位于中心，其他构件经常访问数据存储并对其中的内容进行增删查改​​​​​​​

2. 数据流体系结构(Data flow architecture)

当输入的数据经过一系列计算构件和操作构件的变换形成输出数据的时候，可以应用这种体系结构，管道-过滤器模式(数据库体系结构)拥有一组名为过滤器的构件，这些构件通过管道连接，管道将数据从一个构件传送到下一个构件

3. 调用和返回体系结构(call and return architecture)

该体系结构风格能够设计出一个相对易于修改和扩展的程序结构，比如说主程序/子程序结构，这种传统的程序结构将功能分解为一个控制层次，主程序调用一组程序构件，这些程序构件又去调用其他构件

4. 面向对象体系结构(Object-Oriented architecture)

系统的构件封装了数据和必须用于控制该数据的操作

5. 层次体系结构(Layered architecture)

这种体系结构定义了一系列不同的层次，每个层次各自完成操作，这些操作逐渐接近机器的指令集，在外层，构件完成建立用户界面的操作，在内层，构件完成建立OS（操作系统）接口的操作，中间层提供各种实用工具服务和应用软件功能，这种体系结构的典型应用有TCP/IP网络模型

         ​​​​​​​        ​​​​​​​        ​​​​​​​        ​​​​​​​        ​​​​​​​        ​​​​​​​        ​​​​​​​        ​​​​​​​        ​​​​   ​​​

三、设计系统体系结构的时候关注的因素：

因为非功能性需求和软件体系结构关系密切，所以我们为系统选择的特殊的体系结构和风格应该依赖于非功能系统需求 

包括：

1. 性能(Performance): 如果性能是关键性需求，那么体系结构设计就要定位在少数的几个组件上的一些关键操作上面，同时使用较大粒度的组件而不是小粒度的组件，以此来减少组件之间的通信次数，就比如说，你想告诉你的朋友，今天晚上的讲座你不去了，最快的方法当然是你直接打个电话，而不是你先打电话给A，A再告诉B，B再告诉C……
2. 信息安全性(Security):如果信息安全性是一个关键需求，那么体系结构就要使用分层结构，把重要的资源放在内层，并且在每层中采用更加严格的信息安全有效性验证，这就像是俄罗斯套娃一样，你要一层层打开，然后才能拿到最里面那个套娃装着的宝石，如果每一层都要开锁才能打开，可能小偷都会嫌麻烦吧
3. 安全性(Safety) : 如果安全是一个关键性的需求，那么系统体系结构的设计就要将与安全相关的操作集中在一个或者少数几个组件之中，这样可以减少成本和安全有效性验证方面的问题，而且有可能提供相应的保护系统，保证系统能够安全关闭系统
4. 可用性(Availability) : 如果可用性是一个关键的需求，那么系统的体系结构就要采用冗余组件以便能够在无需系统停止运行的情况下更新和替换组件，这就相当于你在考试时候换笔水，老师总是跟你说你考试之前要多带几只笔或者笔芯，不然一支笔用完了没有可以替换的东西，那还怎么考试呀
5. 可维护性(Maintainability) : 如果可维护性是一个关键性需求，那么系统体系结构设计就要使用小粒度的自包含组件以便于更换

显然这些体系结构的需求之间存在冲突，所以如果两个指标都是系统的关键性需求，那么我们就需要采取一个折中的方法

四、要点总结： 

1. 软件体系结构是有关软件系统如何组织的描述，系统的性质，如性能、信息安全性和可用性都受到所使用的体系结构的影响
2. 体系结构决策包括对应用类型的决策、系统分布的决策、所使用的体系结构风格的决策，以及对系统体系结构如何文档化和评估的决策
3. 系统结构模式是复用通用的系统体系结构知识的一种方法，描述体系结构的使用时机和优缺点
4. 应用系统体系结构的一般模型能够帮助我们理解应用的运作，比较相同类型的应用，应用设计程序设计的有效性并能达到对大粒度构件的复用