软考高级之系统架构师系列之软件架构设计
概述
软件架构设计
层次：
- 架构模式：软件设计中的高层决策，C/S结构就属于架构模式，架构模式反映开发软件系统过程中所作的基本设计决策
- 设计模式：主要关注软件系统的设计，与具体的实现语言无关；
- 惯用法：最低层的模式，关注软件系统的设计与实现，描述如何实现构件及构件之间的关系，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系，例如引用-计数就是C++语言中的一种惯用法。
风格
软件架构风格是描述某一特定应用领域中的系统组织方式和惯用模式，反映领域中众多系统所共有的结构和语义两个方面的特征，主要包括架构定义、架构词汇表和架构约束。
架构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
架构风格描述一类软件架构的特征，它独立于实际问题，强调软件系统中通用的组织结构选择。垃圾回收机制是Java语言管理内存资源时常用的一种设计模式。
软件架构设计的一个核心问题是能否使用重复的架构模式，即能否达到架构级的软件重用。也就是说，能否在不同的软件系统中，使用同一架构。基于这个目的，学者们开始研究和实践软件架构的风格和类型问题。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件架构风格定义用于描述系统的术语表和一组指导构件系统的规则。
实战
对于语音识别、知识推理等问题复杂、解空间很大、求解过程不确定的这一类软件系统，通常会采用黑板架构风格，以知识为中心进行分析与推理。
对于因数据而驱动，数据到达某个构件，经过内部处理，产生数据输出的系统通常采用管道-过滤器体系结构风格。
调温器需要实时获取外界的温度信息，与用户定义的温度进行比较并做出动作。根据该系统的应用领域和实际需求，是一个典型的过程控制架构风格的应用场景。
用户会注册自己的兴趣，系统也会把新闻按兴趣分类，如果某个新闻事件发生，可以通过事件来触发推送动作，将新闻推送给对其感兴趣的用户。典型的事件驱动系统应用场景。
Windows操作系统在图形用户界面处理方面采用的是典型的事件驱动架构风格，首先注册事件处理的是回调函数，当某个界面事件发生时，系统会查找并选择合适的回调函数处理该事件。
现代编译器主要关注编译过程和程序的中间表示，围绕程序的各种形态进行转化与处理。这种情况下，可以针对程序的各种形态构建数据库，通过中心数据库进行转换与处理，数据共享风格最符合要求。
Java语言是一种解释型语言， 在JVM上运行，这从架构风格上看是典型的虚拟机风格，即通过虚拟机架构屏蔽不同的硬件环境。
规则系统体系结构风格是一个使用模式匹配搜索来寻找规则并在正确的时候应用正确的逻辑知识的虚拟机，其支持把频繁变化的业务逻辑抽取出来，形成独立的规则库。这些规则可独立于软件系统而存在，可被随时地更新。它提供一种将专家解决问题的知识与技巧进行编码的手段，将知识表示为条件-行为规则，当满足条件时，触发相应的行为，而不是将这些规则直接写在程序源代码中，规则一般用类似于自然语言的形式书写，无法被系统直接执行，故而需要提供解释规则执行的解释器。 扫地机器人系统适用于规则系统体系结构风格。
需求
软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件，并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件三步。软件架构需求并不应该包括设计构件的过程。
失配
失配是指在软件复用的过程中，由于待复用构件对最终系统的体系结构和环境的假设（assumption）与实际状况不同而导致的冲突。在构件组装阶段失配问题主要包括：
- 由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配
- 由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配
- 由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。
建模
应用架构建模中要绘制的第一个物理数据流图（PDFD）是网络架构DFD，它们不显示单位时间的数据流量，需要显示的信息包括服务器及其物理位置；客户端及其物理位置；处理器说明；传输协议。
生命周期
软件架构贯穿于软件的整个生命周期，但在不同的阶段对软件架构的关注力度并不相同。其中需求分析阶段主要关注问题域；设计阶段主要将需求转换为软件架构模型；软件实现阶段主要关注将架构设计转换为实际的代码；软件部署阶段主要通过组装软件组件提高系统的实现效率。其中设计与实现阶段在软件架构上的工作最多，也最重要，因此关注力度最大。
DSSA
特定领域软件架构，Domain Specific Software Architecture，以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，其目标是支持一个特定领域中多个应用的生成。在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。
DSSA通常是一个具有三个层次的系统模型：领域开发环境、领域特定应用开发环境和应用执行环境。
其中应用工程师主要在领域特定应用开发环境中工作。
基本活动包括：
- 领域分析：主要目的是获得领域模型，领域模型描述领域中系统之间共同的需求，即领域需求；
- 领域设计：主要目标是获得DSSA，DSSA描述领域模型中表示需求的解决方案；
- 领域实现：主要目标是依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。
参与DSSA的人员可以划分为4种（有说5种）角色：
- 领域专家：提供关于领域中系统的需求规约和实现的知识
- 领域设计人员：根据领域模型和现有系统开发出DSSA，并对DSSA的准确性和一致性进行验证
- 领域实现人员：
- 领域分析师：
- 领域分析者：控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中
C2
C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。
C2风格中的系统组织规则如下：
- 系统中的构件和连接件都有一个顶部和一个底部
- 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的
- 一个连接件可以和任意数目的其他构件和连接件连接
- 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部
ABSD
基于软件架构的开发，Architecture BasedS oftwareD evelopment，强调由商业、质量和功能需求的组合驱动软件架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。用例描述的是功能需求，质量属性场景描述的是质量需求（或侧重于非功能需求）。
ABSD方法有三个基础：
- 功能分解，在功能分解中使用已有的基于模块的内聚和耦合技术
- 通过选择体系架构风格来实现质量和商业需求
- 软件模板的使用
ABSD方法主要包括架构需求等6个主要活动：
- 架构复审：目标是标识潜在的风险，及早发现架构设计中的缺陷和错误；
- 架构演化：针对用户的需求变化，修改应用架构，满足新的需求。
软件架构文档应该从使用者的角度进行书写，针对不同背景的人员采用不同的书写方式，并将文档分发给相关人员。架构文档要保持较新，但不要随时保证文档最新，要保持文档的稳定性。架构文档化的主要输出结果是架构规格说明书和架构质量说明书。
使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，并且设计活动的开始并不意味着需求抽取和分析活动可以终止，而是应该与设计活动并行。ABSD方法是一个自顶向下，递归细化的过程，软件系统的架构通过该方法得到细化，直到能产生软件构件的类。
架构复审是基于架构开发中一个重要的环节。架构设计、文档化和复审是一个迭代的过程。从这个方面来说，在一个主版本的软件架构分析之后，要安排一次由外部人员 （用户代表和领域专家）参加的复审。架构复审过程中，通常会对一个可运行的最小化系统进行架构评估和测试。架构复审的目标是标识潜在的风险，及早发现架构设计的缺陷和错误。
质量属性
软件质量属性通常需要采用特定的设计策略实现，设计策略会对其他质量属性产生影响。
不同策略主要针对一个或多个软件质量属性：
- Ping/Echo（心跳机制）主要提高系统的可用性（可靠性），其他策略：主动冗余、被动冗余、选举等架构
- 限制访问主要提髙系统的安全性，其他策略：入侵检测、用户认证、用户授权、追踪审计、信息隐藏
- 运行时注册主要提高系统的可修改性，其他策略：接口-实现分离，信息隐蔽（高内聚低耦合？），
- 队列调度（优先级队列）主要提高系统的性能，其他策略：增加计算资源、减少计算开销、 引入并发机制
- 记录-回放主要提高系统的可测试性
SAAM
基于场景的架构分析方法，Scenarios-based Architecture Analysis Method。卡耐基梅隆大学软件工程研究所的Kazman等人于1983年提出的一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法。
SAAM的主要输入：问题描述、需求说明和架构描述；
其分析过程主要包括场景开发、架构描述、单个场景评估、场景交互和总体评估。
ATAM
架构权衡分析方法，Architecture Tradeoff Analysis Method。主要关注系统的需求说明。该方法强调对软件的质量属性进行分析、分类和优先级排序等工作，在此基础上构建质量属性效用树对质量属性描述进行刻画和排序，并对风险点、非风险点、敏感点和权衡点进行识别和分析。
在SAAM基础之上发展起来的一种系统架构评估方法，主要对软件体系结构的设计结果进行评估。评估是软件系统详细设计、实现和测试之前的阶段工作，因此评估不涉及系统的实现代码和测试，因为评估是考査软件体系结构是否能够合适地解决软件系统的需求，并不对软件需求自身是否准确进行核实，而软件需求是否准确是需求评审阶段的工作。ATAM并不是一种精确的评估方法，该方法表现的主要形式是评审会议。
主要包括 场景和需求收集、架构视图和场景实现、属性模型构造和分析、属性模型（架构决策）折中 等4个阶段。
ATAM方法要求在系统开发之前，首先针对 性能、可用性、安全性和可修改性 等质量属性进行评价和折中。
整个评估过程强调以属性作为架构评估的核心概念。
4点
识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程。
风险是某个存在问题的架构设计决策，可能会导致问题：非风险与风险相对，是良好的架构设计决策； 敏感点是一个或多个构件的特性；权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，可称为风险点。
敏感点是一个或多个构件（和/或构件之间的关系）的特性。研究敏感点可使设计入员或分析员明确在搞清楚如何实现质量目标时应注意什么。
权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。
其中敏感点是实现一个特定质量属性的关键特征，该特征为一个或多个软件构件所共有。系统权衡点会影响一个或多个属性，并对于多个属性来说都是敏感点。
【改变业务数据编码方式会对系统的性能和安全性产生影响】是对权衡点的描述；
【改变加密的级别可能会对安全性和性能都产生显著的影响】是对系统权衡点的描述；
【假设用户请求的频率为每秒1个，业务处理时间小于30毫秒，则将请求响应时间设定为1秒钟是可以接受的】是对非风险的描述
【系统需要支持的最大并发用户数量直接影响传输协议和数据格式】描述敏感点