[笔记] 系统分析师 第十二章 软件架构设计（分析师主要工作）
文章目录
- 前言
- 12.1 软件架构概述
- 12.1.1 软件架构的意义
- 12.1.2 软件架构的发展史
- 12.2 软件架构建模
- 12.3 软件架构风格
- 12.3.1 软件架构风格概述
- 12.3.2 数据流体系结构风格
- 1.批处理体系结构风格
- 2.管道-过滤体系结构风格
- 12.3.3 调用/返回体系结构风格
- 1.主程序/子程序风格
- 2.面向对象体系结构风格
- 3.层次型体系结构风格
- 4.客户端/服务端体系结构风格
- 二层架构
- 三层C/S架构
- 12.3.4 以数据为中心的体系结构风格
- 1.仓库体系结构风格
- 2.黑板体系结构风格
- 12.3.5 虚拟机体系结构风格
- 1.解释器体系结构风格
- 2.规则系统体系结构风格
- 12.3.6 独立构件体系结构风格
- 1.进程通信体系结构风格
- 2.事件体系结构风格
- 12.3.7 面向服务的架构风格
- 1.SOA概述
- 基本服务结构
- SOA设计原则
- 服务构建与传统构建
- 2.SOA关键技术
- UDDI
- WSDL
- SOAP
- REST
- 3.SOA实现方法
- ＷebService
- 服务注册表
- 企业服务总线ESB
- 12.4 软件架构标准
- 12.5 软件架构实现
- 12.5.1 体系结构需求
- 1. 需求获取
- 2. 标识构建
- 3. 架构需求评审
- 12.5.2 体系结构设计
- 12.5.4 体系结构复审
- 12.5.5 体系结构实现
- 12.5.6 体系结构的演化
- 12.6 软件架构质量属性
- 12.6.1 质量属性概念
- 1.开发期质量属性
- 2.运行期质量属性
- 12.6.2 面向架构评估的质量属性
- 1.性能
- 2.可靠性
- 3.可用性
- 4.安全性
- 5.可修改性
- 6.功能性
- 7.可变性
- 8.互操作性
- 12.6.3 质量属性场景描述
- 1.可用性质量属性场景
- 2.可修改性质量属性场景
- 3.性能质量属性场景
- 4.可测试性质量属性场景
- 5.易用性质量属性场景描述
- 6.安全性质量属性场景
- 总结
前言
学者们提出了软件架构(SofwareArchitecture)的概念，并试图在软件需求与设计之间架起一座桥梁，·重点解决系统结构和需求向实现平坦过渡的问题。
12.1 软件架构概述
-
软件架构研究的主要内容涉及软件架构描述、软件架构风格、软件架构评估和软件架构的形式化方法等。
-
解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。
12.1.1 软件架构的意义
- 架构是项目干系人进行交流的手段
- 架构是早期设计决策的体现
- 架构明确了对系统实现的约束条件
- 架构决定了开发和维护组织的组织结构
- 架构制约着系统的质量属性
- 架构使推理和控制更改更简单
- 架构有助于循序渐进的原型设计
- 架构可以作为培训的基础
- 架构是可传递和可复用的模型
12.1.2 软件架构的发展史
纵观软件架构技术的发展过程，从最初的无架构设计到现行的基于架构的软件开发。
经历了4个阶段:
- 无架构设计阶段。以汇编语言进行小规模应用程序开发为特征。（20世纪70年代以前）
- 萌芽阶段。出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征。（20世纪70年代中后期）
- 初级阶段。出现了从不同侧面描述系统的结构模型，以 UML为典型代表。（20世纪80年代—90年代中期）
- 高级阶段。以描述系统的高层抽象结构为中心，不关心具体的建模细节，划分了架构模型与传统软件结构的界限。（20世纪90年代以后）
12.2 软件架构建模
软件架构设计的首要问题是如何表示软件架构，即如何对软件架构建模。
根据建模的侧重点不同，可以把软件架构的模型分为5种，分别是：
- 结构模型
- 框架模型
- 动态模型
- 过程模型
- 功能模型
“4+1”：视图模型从5个不同的视角来描述软件架构，每个视图只关心系统的一个侧面，5个视图结合在一起才能反映软件架构的全部内容：
- 逻辑视图（静态结构）
- 开发视图（静态结构）
- 进程视图（动态结构）
- 物理视图（动态结构）
- 场景：可以用文本表示，也可以用图形表示
例如，图12-2是一个小型电话呼叫系统场景片段的图形描述，相应的文本表示如下：
12.3 软件架构风格
12.3.1 软件架构风格概述
- 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
- 体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件体系结构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。
12.3.2 数据流体系结构风格
1.批处理体系结构风格
2.管道-过滤体系结构风格
12.3.3 调用/返回体系结构风格
1.主程序/子程序风格
2.面向对象体系结构风格
3.层次型体系结构风格
4.客户端/服务端体系结构风格
二层架构
表示层：表示层是系统的用户接口部分，担负着用户与系统之间的对话功能。
数据层：负责对 DBMS 进行管理和控制。
三层C/S架构
- 表示层：表示层是系统的用户接口部分，担负着用户与系统之间的对话功能。它用于检查用户从键盘等输入的数据，显示输出的数据。
- 功能层：功能层也称为业务逻辑层，是将具体的业务处理逻辑编入程序中。
- 数据层：数据层相当于二层 C/S 架构中的服务器，负责对 DBMS 进行管理和控制。
与传统的二层 C/S 架构相比，三层CS 架构具有以下优点:
- 允许合理地划分三层的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统的可维护性和可扩展性。
- 允许更灵活、有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层，并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
- 系统的各层可以并行开发，各层也可以选择各自最适合的开发语言，使之能并行且高效地进行开发，达到较高的性能价格比。对每一层的处理逻辑的开发和维护也会更容易些。
- 利用功能层可以有效地隔离表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段非法访问数据层，这就为严格的安全管理定了坚实的基础。但是，若三层C/S架构各层间的通信效率不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。
此外，设计时必须慎重考虑三层间的通信方法、通信频度和数据量，这是三层 C/S 架构设计的关键问题。
B/S层架构：
- 浏览器/服务器(Browser/Server，B/S)架构是三层C/S架构的一种实现方式，其具体结构为“浏览器/Web服务器/数据库服务器”。B/S架构利用不断成熟的WWW浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能,并节约了开发成本。从某种程度上来说，B/S架构是一种全新的软件架构。
B/S层架构优点：
- 在B/S架构中，除了数据库服务器外，应用程序以网页形式存放于Web服务器上，用户运行某个应用程序时，只需在客户端的浏览器中键入相应的网址，调用 Web服务器上的应用程序，并对数据库进行操作，完成相应的数据处理工作，最后将结果通过浏览器显示给用户。
- 基于 B/S架构的软件，系统安装、修改和维护全在服务器端解决。
- 用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。
B/S层架构缺点，与C/S架构相比，B/S架构也有许多不足之处，例如：
- 缺乏对动态页面的支持能力，没有集成有效的数据库处理功能;
- 安全性难以控制
- 采用B/S架构的系统在数据查询等响应速度上远远低于 C/S 架构
- B/S 架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于 OLTP 应用。
12.3.4 以数据为中心的体系结构风格
1.仓库体系结构风格
2.黑板体系结构风格
12.3.5 虚拟机体系结构风格
1.解释器体系结构风格
2.规则系统体系结构风格
12.3.6 独立构件体系结构风格
1.进程通信体系结构风格
2.事件体系结构风格
12.3.7 面向服务的架构风格
面向服务的架构(Service-Oriented Architecture，SOA)
1.SOA概述
基本服务结构
SOA设计原则
服务构建与传统构建
2.SOA关键技术
UDDI
WSDL
SOAP
REST
REST是一种只使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。它的简单性和缺少严格配置文件的特性，使它与SOAP很好地隔离开REST从根本上来说只支持几个操作(POST、GET、PUT和DELETE)，这些操作适用于所有的消息。
REST提出了如下一些设计概念和准则:
- 网络上的所有事物都被抽象为资源。
- 每个资源对应一个唯一的资源标识
- 通过通用的连接件接口对资源进行操作。
- 对资源的各种操作不会改变资源标识。
- 所有的操作都是无状态的。
3.SOA实现方法
ＷebService
服务注册表
企业服务总线ESB
12.4 软件架构标准
软件架构标准要素之间的关系，具体分为5个层次:
- 任务
- 环境
- 利益相关者
- 关注
- 关注点库、模型
12.5 软件架构实现
传统软件开发模型存在开发效率不高、不能很好地支持软件重用等缺点。基于架构的软，件开发模型(ABSDM)把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化等6个子过程，
12.5.1 体系结构需求
1. 需求获取
2. 标识构建
- 生成类图
- 对类进行分组
- 把类打包成构建
3. 架构需求评审
组织一个由不同代表(如分析人员、客户、设计人员、测试人员)组成的小组，对体系结构需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的要求，类的分组是否合理，构件合并是否合理等。必要时，可以在“需求获取一标识构件一需求评审”之间进行迭代。
12.5.2 体系结构设计
- 提出体系结构模型
- 映射构件
- 分析构件间的相互作用
- 产生体系结构
- 设计评审
12.5.4 体系结构复审
-
体系结构设计、体系结构文档化和体系结构复审是一个迭代过程。从这个角度来说，在分析一个主版本的软件体系结构之后，要安排一次由外部人员(用户代表和领域专家)参加的复审。
-
鉴于体系结构文档标准化，以及风险识别的现实情况，通常我们根据架构设计，搭建一个可运行的最小化系统用于评估和测试体系架构是否满足需要，是否存在可识别的技术和协作风险。
-
复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误，包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等。
12.5.5 体系结构实现
12.5.6 体系结构的演化
12.6 软件架构质量属性
12.6.1 质量属性概念
软件系统质量属性(Quality Attribute)是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者(Stakeholders)需求的程度。
基于软件系统的生命周期，可以将软件系统的质量属性分为开发期质量属性和运行期质量属性两部分。
1.开发期质量属性
2.运行期质量属性
12.6.2 面向架构评估的质量属性
1.性能
2.可靠性
3.可用性
4.安全性
5.可修改性
6.功能性
7.可变性
8.互操作性
12.6.3 质量属性场景描述
1.可用性质量属性场景
2.可修改性质量属性场景
3.性能质量属性场景
4.可测试性质量属性场景
5.易用性质量属性场景描述
6.安全性质量属性场景
总结
参考：
10种常见的架构风格，你用过几种
关于博主
wx/qq：binary-monster/1113673178 （添加时注明来意，否则不予通过）
wxgzh: 二进制怪兽
CSDN：https://blog.csdn.net/qq1113673178
码云：https://gitee.com/shiver
Github: https://github.com/ShiverZm
个人博客：https://www.binary-monster.top