系统架构师（九）软件架构设计（二）

竟未曾年少轻狂

已于 2022-09-07 11:30:10 修改

阅读量834

点赞数

分类专栏： # 章节学习文章标签：系统架构软件工程

于 2022-08-29 15:09:01 首次发布

本文链接：https://blog.csdn.net/weixin_47203903/article/details/126540765

版权

章节学习专栏收录该内容

17 篇文章 15 订阅

订阅专栏

架构设计

软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。需要注意的是，软件架构设计与系统需求是直交的，两者并无必然联系。

软件架构设计能够满足系统的性能、安全性、可维护性等品质；
软件架构设计能够帮助项目干系人（Stakeholder）更好地理解软件结构：
软件架构设计能够有效地管理系统的复杂性，并降低系统维护费用；
软件架构设计对系统开发具有指导性：
软件架构设计为系统复用奠定的基础；
软件架构设计能够支持冲突分析。

1．演变交付生命周期

在生命周期模型中，架构设计就是从初步的需求分析开始逐步进行循环迭代。即：一方面在了解系统需求前，不能开始设计架构；另一方面，刚开始进行设计架构时并不需要等到全部需求都收集到。

2．属性驱动设计法

ADD是一种定义软件架构的方法，该方法将分解过程建立在软件必须满足的质量属性之上。ADD 的输入为：功能需求（一般表示为用例）、限制条件和质量需求（一组特定于系统的质量场景）。

3．按架构组织开发团队

每个模块都构成自己的小领域（专门知识或专门技术），并与其他模块的接口清晰，不同的模块分到不同的开发小组中，减少沟通成本

4．开发骨架系统

以架构为指导，开发一个可运行的原型（骨架系统）；在其上进行增量开发，直到软件开发完成。

5．利用商用构件进行开发

例如使用 J2EE/EJB 进行开发面向对象的分布式系统。

软件架构文档化

记录软件架构的活动就是架构编档过程，也就是架构的文档化。它包含两个方面：一是过程，编档过程能促使架构设计师进一步思考，使得架构更加完善；二是结果，描述架构的文档将作为架构开发的成果，供项目关系人使用

1．架构文档的使用者

架构的主要用途是充当项目关系人之间进行交流的工具，文档则促进了这种交流

2．合理的编档规则

（1）从读者的角度编写文档。
（2）避免出现不必要的重复。
（3）避免歧义。
（4）使用标准结构。
（5）记录基本原理。
（6）使文档保持更新，但更新频率不要过高。
（7）针对目标的适宜性对文档进行评审。

3．视图编档

视图的概念为架构设计师提供了进行软件架构编档的基本原则。架构文档化就是将相关视图编成文档，并补充多个视图的关联关系。

视图概述：对系统进行概括性的描述，包含视图的主要元素和元素间的关系。主要表示可用多个形式：图形、表格、文本，通常用图形形式，使用 UML 语言来描述。
元素目录：对主要表示中所描述的元素及其关系进行详细描述，包括：元素及属性、关系及其属性、元素接口、元素行为。
上下文图：用图形展示系统如何与其环境相关。
可变性指南：描述架构的可变化点，如各系统要做出选择的选项、做出选择的时间。
架构背景：为架构的合理性提供足够的、令人信服的论据。包括：基本原理、分析结果及设计中所反映的假定。
术语表：对文档中每个术语进行简要说明。
其他信息：描述不属于架构方面的必要信息，如管理信息（创作者、配置控制数据及变更历史）。

4．跨视图文档：对文档进行一个整体的“打包”工作

5．使用 UML：在视图文档的组织结构中，UML 主要用于表示元素或元素组的行为。

6．软件架构重构：反向工程之一，用于文档丢失时

由以下活动以迭代方式进行：

（1）信息提取（View Extraction）。可以使用各种工具进行信息提取，如解析器、语法分析器等；
（2）数据库构造（Database Construction）：将提取的信息转化为标准的形式，并置于数据库中。
（3）视图融合（View Fusion）：将数据库中的信息组合在一起，生成该架构的一个内聚的视图。
（4）重构（Reconstruction）：构建数据抽象和各种表示以生成架构表示，主要由两个活动组成：可视化和交互、模式定义和识别。最后生成需要的架构文档（Documentation）。

架构描述语言：

Aesop：支持体系结构风格的应用；
MetaH：为设计者提供了关于实时电子控制软件系统的设计指导；
C2：支持基于消息传递风格的用户界面系统的描述；
Rapide：支持体系结构设计的模拟并提供了分析模拟结果的工具；
SADL：提供了关于体系结构加细的形式化基础；
Unicon：支持异构的构件和连接类型并提供了关于体系结构的高层编译器；
Wright：支持体系结构构件之间交互的说明分析；

架构描述语言（ADL） 是一种为明确说明软件系统的概念架构和对这些概念架构建模提供功能的语言。ADL主要包括以下组成部分：组件、组件接口、连接件和架构配置。ADL对连接件的重视成为区分ADL和其他建模语言的重要特征之一。

软件架构评估

软件架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它也可以灵活地运用于对软件架构进行评审等工作中。

评估方法所关注的质量属性：

性能： 指系统的响应能力
代表参数：响应时间、吞吐量
设计策略：优先级队列、资源调度
可用性： 系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
代表参数：故障间隔时间
设计策略：冗余、心跳线、Ping/Echo、选举
安全性： 指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
设计策略：追踪审计、限制访问
可修改性： 指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。
主要策略：运行时注册、接口-实现分离、信息隐藏
可靠性：是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。主要考虑两个方面：容错、健壮性。
代表参数：MTTF、MTBF
设计策略：冗余、心跳线
功能性：是系统所能完成所期望的工作的能力，一项任务的完成需要系统中许多或大多数构件的相互协作。
可变性：是指体系结构经扩充或变更而成为新体系结构的能力。
互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。

记录-回放主要提高系统的可测试性

质量评估的概念

风险点：指架构设计中潜在的、存在问题，给架构决策所带来的隐患。
敏感点：是为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
非风险点：用户提出的XX要求，是可以接受的。

软件架构评估的方法

（1）基于调查问卷或检查表的方式：其缺点是在很大程度上依赖于评估人员的主观推断。

（2）基于场景的方式： 通过分析软件架构对场景（也就是对系统的使用或修改活动）的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。

软件架构分析法（SAAM）：最初用于分析架构的可修改性，后扩展到其它质量属性。
- SAAM的过程包括五个步骤，即场景开发、体系结构描述、单个场景评估、场景交互和总体评估。
- SAAM的主要输入问题是问题描述、需求声明和体系结构描述。
架构权衡分析法（ATAM）：主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。主要关注系统的需求说明，强调以属性作为架构评估的核心概念，通常采用效用树对质量属性的描述进行刻画与排序。
- 第一阶段：场景和需求收集
- 第二阶段：描述架构视图和场景实现；
- 第三阶段：属性模型构造和分析；特定属性分析（优秀的单一理论）
- 第四阶段：折中；
成本效益分析法（CBAM）：CBAM 在 ATAM 结束时开始

（3）基于度量的方式：它是建立在软件架构度量的基础上的，能提供更为客观和量化的质量评估，但它对评估人员及其使用的技术有较高的要求。ATAM 中也使用了度量的思想（度量效用）。

首先需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的质量属性；
然后从软件架构文档中获取度量信息；
最后根据映射原则分析推导出系统的质量属性。

构件及其复用

构件的定义：软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
构件组装成系统的过程：定制、集成、扩展

构件的特性：

独立部署单元
作为第三方的组装单元
没有（外部的）可见状态。
一个构件可以包含多个类元素，一个类元素只能属于一个构件

面向构件的编程（COP）关注于如何支持建立面向构件的解决方案。基于一般OOP风格，面向构件的编程需要下列基本的支持：

多态性（可替代性）
模块封装性（高层次信息的隐藏）
后期的绑定和装载（部署独立性）
安全性（类型和模块安全性）。

CORBA（公共对象请求代理架构）

伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求。
对象适配器（Object Adapter）：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。
对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。

基于构件的开发模型

基于构件的开发模型： 利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。基于构件的开发模型由软件的需求分析定义、体系结构设计、构件库建立、应用软件构建以及测试和发布5个阶段组成。

在基于构件的开发中，构件包含并扩展了模块化程序设计中子程序、面向对象系统中对象或类和系统模型中包的思想，它是系统设计、实现和维护的基础。构件定义为通过接口访问服务的一个独立可交付的功能单元。

在基于构件的软件开发中，逻辑构件模型用功能包描述系统的抽象设计，用接口描述每个服务集合，以及功能之间如何交互以满足用户需求，它作为系统的设计蓝图以保证系统提供适当的功能。物理构件模型用技术设施产品、硬件分布和拓扑结构，以及用于绑定的网络和通信协议描述系统的物理设计，这种架构用于了解系统的性能、吞吐率等许多非功能性属性。