软考 - 系统架构设计师（软件架构设计）

架构的定义

     软件架构仍在不断发展中，还没有形成一个统一的、公认的定义，这里仅举出几个较为权威的定义。

1. 软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。

2. 软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式的约束组成。

3. 软件架构是指一个系统的基础知识，它具体体现在：系统的构件，构件之间、构件与环境之间的关系，以及指导其设计和演化的原则上。（IEEE1471-2000）
   
   
   从技术角度看，软件架构的重要性：

   1. 项目关系人之间交流的平台

   2. 早期设计决策。从软件生命周期来看，软件架构是所开发系统的最早设计决策的体现。
      表现为： （1）架构明确了对系统实现的约束条件；（2）架构影响着系统的质量属性；（3）架构可以用来预测系统的质量；（4）架构为维护的决策提供依据；（5）架构有助于原型开发。

   3. 在较高层面上实现软件复用

   4. 架构对开发的指导与规范意义不容忽略

     基于架构的软件开发模型则明确地把整个软件过程划分为：架构需求、设计、文档化、评审（评估）、实现、演化等 6 个子过程。

架构的模型

最常用的是结构模型和动态模型。

1. 结构模型。这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件和其他概念来刻画结构，并力图通过结构来反应系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言。
2. 框架模型。框架模型于结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应问题的机构。
3. 动态模型。动态模型是对结构或框架模型的补充，研究系统“大颗粒”的行为性质。例如，描述系统的重新配置和演化。动态可能指系统总体结构的配置、建立或查出通信通道或计算的过程。
4. 过程模型。过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。
5. 功能模型。该模型认为架构由一组功能构件按层次组成，且下层向上层提供服务。它可以看做是一种特殊的框架模型。

“4+1”视图模型从 5 个不同的视角包括逻辑视图、进程视图、物理视图、开发视图、场景视图来描述软件架构。每一个视图只关心系统的一个侧面，5 个视图结合在一起才能反应系统的软件架构的全部内容。如下图所示：

视图名称	功能	关注点	关注人员
逻辑视图	主要支撑系统的功能需求	描述系统功能	用户
开发视图（模块视图、实现视图）	主要侧重于软件模块的组织和管理	描述系统配置、装配	编程人员
进程视图	侧重于系统的运行特性，一些非功能性的需求	描述系统性能、吞吐	系统集成人员
物理视图	主要考虑如何把软件映射到硬件上	描述系统安装、拓扑结构、通信等	系统工程师
场景视图（用例视图）	使四个视图有机得联系起来	描述人机互动的系统行为	分析人员和测试人员

软件质量属性

案例分析常考

属性	子属性	作用及要点	应对策略
性能		效率指标：处理任务所需时间或单位时间内的处理量	增加计算资源、减少计算开销、引入并发机制、资源调度
可靠性	容错	出现错误后仍能保证系统正常运行，且自行修正错误	主动冗余
	健壮性	错误不对系统产生影响，按既定程序忽略错误
可用性		正常运行时间比例	心跳、Ping/Echo、主动冗余、被动冗余、选举
安全性		系统向合法用户提供服务并组织非法用户的能力	侵入检测、用户认证、用户授权、追踪审计、限制访问
可修改性	可维护性	局部修复故障对架构的负面影响最小化	软件模块泛化、限制模块之间通信、使用中介和延迟绑定、运行时注册、接口实现分离、信息隐蔽
	可拓展性	因松散耦合更易实现新特性/功能，不影响架构
	结构重组	不影响主体进行的灵活配置
	可移植性	适用于多样的环境（硬件平台、语言、操作系统）
功能性		需求的满足程度	构建协作
可变性		总体架构可变	预先定义规则，作为相关产品基础
互操作性		通过可视化或接口方式提供更好的交互操作体验	交互作用
可测试性		软件发现故障并隔离，定位其故障的能力特性	记录回放

软件架构风格

这部分内容比较多，我又总结了另一篇文章
软考-系统架构设计师（软件架构风格）

层次系统架构风格

二层C/S架构

提出的原因：C/S架构是基于资源不对等，且为实现共享而提出来的

结构：C/S结构将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与客户的交互任务。

优点：C/S软件架构具有强大的数据操作和事物处理能力，模型思想简单，易与人们理解和接受。

局限： （1）二层C/S结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或Internet；
            （2）软、硬件的组合及集成能力有限；
            （3）服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；
            （4）数据安全性不好。

三层C/S架构

结构：将应用功能分成表示层、功能层和数据层三个部分

• 表示层：是应用的用户接口部分，它负担着用户与应用间的对话功能。它用于检查用户 从键盘等输入的数据，并显示应用输出的数据。在变更用户接口时，只需修改显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。
• 功能层：相当于应用的本体，它是将具体的业务处理逻辑编入程序中。而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交互要尽可能简洁。
• 数据层：就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此，一般从功能层传送到数据层的要求大都使用 SQL 语言。

解决方案：对这三层进行明确分割，并在逻辑上使其独立。原来的数据层作为数据库管理系统已经独立出来，所以，关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。一般情况下是只将表示层配置在客户机中，如果将功能层也放在客户机中，与二层 C/S 结构相比，其程序的可维护性要好得多，但是其他问题并未得到解决。客户机的负荷太重，其业务处理所需的数据要从服务器传给客户机，所以系统的性能容易变差。如果将功能层和数据层分别放在不同的服务器中，则服务器和服务器之间也要进行数据传送。但是，由于在这种形态中三层是分别放在各自不同的硬件系统上，所以灵活性很高，能够适应客户机数目的增加和处理负荷的变动。

B/S 架构风格

使用技术：B/S 结构主要是利用不断成熟的 WWW 浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原本需要复杂的专用软件才能实现的强大功能，并节约了开发成本。

优点：基于 B/S 架构的软件，系统安装、修改和维护全在服务器端解决（零客户端），很容易在运行时自动升级。也可以更加充分利用网络上的各种资源，同时应用程序维护的工作量也大大减少。

不足：（1）B/S 架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；
           （2）采用 B/S 架构的应用架构，在数据查询等响应速度上，要远远地低于 C/S 架构；
           （3）B/S 架构的数据提交一般以页面为单位，数据的动态交互性不抢，不利于在线事务处理（OnLine Transaction Processing，简称 OLTP ）应用。

MVC架构风格

定义：全名是 Model ViewController，是模型（model）- 视图（view）- 控制器（controller）的缩写，分层架构的一种。

分工协作：

• Model 是对应用状态和业务功能的封装。Model 接受 Controller 的请求并完成响应的业务处理，在状态改变的时候向 View 发出相应的通知。
• View 实现可视化界面的呈现并捕捉最终用户的交互操作（例如鼠标和键盘的操作）。
• Controller 会根据需要控制原 View 或者创建新的 View 对用户交互操作予以响应。View 捕获到用户交互操作后直接转发给 Controller，后者完成相应的 UI 逻辑。如果需要涉及业务功能的调用，Controller 会直接调用 Model。

MVP架构风格

定义：全称为 Model-View-Presenter。MVP 是从MVC 演变而来。

与MVC的相同点：基本思想有相通的地方：Model 提供数据，View 负责显示，Controller/Presenter 负责逻辑的处理。

与MVC的不同点：MVC模式中元素之间“混乱”的交互主要体现在允许 View 和 Model 直接进行“交流”，这在MVP 中是不允许的。在 MVP 中 View 并不直接使用 Model，它们之间的通信是通过 Presenter （MVC中的Controller）来进行的，所有的交互都发生在Presenter 内部，而在 MVC 中 View 会直接从 Model 中读取数据而不是通过 Controller。

缺点：由于对视图的渲染放在了 Presenter 中，所以视图和 Presenter 的交互会过于频繁。还有一点需要明白，如果 Presenter 过多的渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么 Presenter 也需要变更了。

优点：（1）模型与视图完全分离，我们可以修改视图而不影响模型；
           （2）可以更高效的使用模型，因为所有的交互都发生在一个地方——Presenter 内部。
           （3）我们可以将一个 Presenter 用于多个视图，而不需要改变 Presenter 的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
           （4）如果我们把逻辑放在 Presenter 中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。