My Github

软考复盘：系统架构设计师核心考点总结

大家好，我是Edison。

去年（2022）复习备考参加了软考高级资格中的系统架构设计师考试。

在系统架构设计师考试中，软件架构设计这一部分绝对是重点中的重点。

这里，我总结了一下软件架构设计这一部分的关键内容，它们值得每个备考的人反复记忆甚至背诵。

考点汇总脑图

这个脑图里面的内容，上午综合知识选择题大户，下午案例和论文中，架构风格、架构评估是常客。

软件架构风格

（1）传统五大经典风格

  • 数据流风格

      • 风格特点：面向数据流，按照顺序执行

      • 代表风格：批处理序列、管道-过滤器

      • 典型应用：批处理典型应用有经典数据处理，程序开发和Windows下的bat程序；管道过滤器典型应用有Unix Shell编写的程序和传统编译器；

  • 调用/返回风格

      • 风格特点：构件之间存在互相调用的关系，一般是显示调用

      • 代表风格：主程序/子程序、面向对象、层次结构

  • 独立构件风格

      • 风格特点：构件之间是互相独立的，不存在显示调用，而是通过某个事件触发、异步的方式来执行

      • 代表风格：进程通信、事件驱动系统（隐式调用）

  • 虚拟机风格

      • 风格特点：自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配

      • 代表风格：解释器、基于规则的系统

  • 仓库风格

      • 风格特点：以数据为中心，所有操作都是围绕着建立的数据中心进行的

      • 代表风格：数据库系统、超文本系统、黑板系统

（2）深入层次架构风格

  • 两层C/S架构

      • 层次组成：表示层 和 逻辑层

      • 风格特点：客户端和服务器都有处理功能，现在已经不常用

  • 三层C/S架构

      • 层次组成：表示层、逻辑层 和 数据访问层

      • 风格特点：将逻辑处理功能独立出来，表示层和数据层变得更简单和纯粹，表示层在客户机上，逻辑层在应用服务器上，数据访问层在数据库服务器上。

  • 三层B/S架构

      • 风格特点：它是三层C/S架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的Web服务器。

  • 富互联网应用RIA

      • 风格特点：RIA是一种用户接口，比用HTML实现的接口更加健壮 且有可视化内容，本质上还是网站模式。

      • 风格优点：

          • RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性；

          • RIA简化并改进了B/S架构的用户交互；

          • 数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。

  • MVC架构

    • 组成部分：

        • Controller：应用程序中处理用户交互的部分。Controller负责从View读取数据，控制用户输入，并向模型发送数据。

        • Model：应用程序中用于处理应用程序数据逻辑的部分。Model对象负责在数据库中读取数据，Model表示业务数据和业务逻辑。

        • View：应用程序中处理数据显示的部分。View是依据模型数据创建的。

  • MVP架构

      • 组成部分：Model, View, Presenter

      • 与MVC的区别：避免了View和Model之间的耦合，降低了Presenter对View之间的依赖。在MVP中，View不直接使用Model，它们之间的通信是通过Presenter来进行的，所有的交互都发生在Presenter内部。

典型系统架构

（1）面向服务的架构（SOA）

  • 架构特点

      • SOA是一种粗粒度、松耦合的服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。

      • 在SOA中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。

      • SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可以直接管理开发人员所构建的相同服务。多个服务通过企业服务总线提出服务请求，由应用管理来进行处理。

  • Web Service

      • 服务提供者、服务注册中心（中介，可有可无）、服务请求者

      • 服务提供者将服务描述发布到服务注册中心，供服务请求者查找，查找到后，服务请求者将绑定查找结果。

  • 服务注册表

      • 服务注册：服务提供者在注册表中公布服务的功能；

      • 服务位置：服务使用者查询已注册的服务，寻找符合自身要求的服务；

      • 服务绑定：服务使用者利用检索到的服务接口来编写代码，所编写的代码将与注册的服务绑定，调用注册的服务，以及与它们实现互动；

  • 企业服务总线（ESB）

      • 定义说明：简单来说ESB就是一根管道，用来连接各个服务节点。其目的是为了集成不同协议的不同服务，ESB做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。

      • 组成部分：客户端（服务请求者）、基础架构服务（中间件）、核心集成服务（提供服务）

      • ESB特点：

        • SOA的一种实现方式，ESB在SOA架构中的作用是总线，将各种服务进行连接与整合；

        • 描述服务的元数据和服务注册管理；

        • 在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力；

        • 发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。

（2）特定领域软件架构（DSSA）

  • DSSA的三个基本活动

      • 领域分析：目的是为了获得领域模型（领域需求），通过识别信息源，分析领域中系统的需求，从而建立领域模型；

      • 领域设计：目的是为了获得DSSA，它描述了在领域模型中表示的需求的解决方案；

      • 领域实现：这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。

  • DSSA的四种角色人员

      • 领域专家：从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。

      • 领域分析人员：由具有知识工程背景的有经验的系统分析员来担任。

      • 领域设计人员：由有经验的软件设计人员来担任；

      • 领域实现人员：由有经验的程序设计人员来担任；

  • DSSA的三层次模型

      • 领域开发环境：领域架构师参与，决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具；

      • 领域特定的应用开发环境：应用工程师根据具体环境来将核心架构实例化；

      • 应用执行环境：操作员实现实例化后的架构。

（3）基于架构的软件开发（ABSD）

  • ABSD的基本活动

      • 架构需求：重在掌握标识构建的三步；

      • 架构设计：将需求阶段的标识构件映射成构建，进行分析；

      • 架构（体系结构）文档化：主要产出两种文档，即架构（体系结构）规格说明，测试架构（体系结构）需求的质量设计说明书。

      • 架构复审：由外部人员参加的复审；

      • 架构实现：用实体来显示出架构，实现构件，构件组装成系统；

      • 架构演化：对架构进行改变，按需求增删构件，使架构可复用。

软件架构评估

（1）质量属性

  • 性能：指系统的响应能力；

      • 指标：响应时间、吞吐量等；

      • 策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等；

  • 可靠性：指软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力；

      • 指标：MTTF、MTBF、MTTR；

      • 策略：心跳、Ping/Echo、冗余、选举；

  • 可用性：指系统能够正常运行的时间比例；

      • 指标：故障间隔时间；

      • 策略：心跳、Ping/Echo、冗余、选举；

  • 安全性：指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力；

      • 指标：保密性、完整性、不可抵赖性、可控性；

      • 策略：入侵检测、用户认证、用户授权、追踪审计；

  • 可修改性：指能够快速的以较高的性能价格比对系统进行变更的能力。

      • 指标：修改成本；

      • 策略：接口-实现分离、抽象、信息隐藏；

  • 功能性：指系统所能完成所期望的工作的能力；

    • 可变性：指体系结构经扩充或变更而成为新体系结构的能力；

    • 互操作性：指系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。

（2）架构评估方式

  • 敏感点：是为了实现某种特定的质量属性，一个或多个构件所具有的的特性；

  • 权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点；

  • 风险点与非风险点

    • 风险点即可能引起风险的因素，如某个做法如果有隐患，有可能导致一些问题，则为风险点；

    • 非风险点即某件事是可行的可接受的；

  • 软件架构评估

    • 时机：架构设计之后，系统设计之前；

    • 目的：为了评估所采用的的架构是否能解决软件系统需求；

    • 方式：

      1. 基于调查问卷（检查表）的方式：类似于问卷调查；

      2. 基于度量的方式：制定一些定量指标来度量架构；

      3. 基于场景的方式：最主要的应用方法，ATAM就是其中一个重要的分析法；

  • 架构权衡分析法（ATAM）

    • ATAM让架构师明确如何权衡多个质量目标；

    • 参与者：

      1. 评估小组

      2. 项目决策者

      3. 其他项目相关人员

    • 主要活动领域：

      1. 场景和需求收集

      2. 体系结构视图和场景实现

      3. 属性模型构造和分析、折中

    • 过程重点：

      • 强调以属性作为架构评估的核心概念，主要是针对质量属性进行评价和折中。

ATAM实例

架构权衡分析法又称ATAM，这里引用CSDN博客「JAVA前线」中的一个实例：足球运动员管理系统。

第一阶段是描述和介绍阶段，首先由架构师向大家介绍什么是ATAM方法，其次由产品经理介绍开发足球运动员信息管理系统商业动机，最后由架构师介绍系统整体架构，例如怎样划分领域，系统分为持久层、缓存层、中间件、业务中台、服务层、网关层、客户端和代理层等等。

第二阶段是调查和分析阶段，不同需求方均提出了相关需求，所涉及质量场景如下：

(1) 在100毫秒内响应用户请求

(2) 主数据库发生故障后，10秒内自动切换至从库

(3) 主机房发生故障后，5分钟内请求重定向至灾备机房

(4) 新增球员比赛和训练指标，开发工作在5人日内完成

(5) 使用包含SSL数字证书的HTTPS访问协议

(6) 球员信息管理界面要求简单易用

(7) 出现异常引导用户至错误页面，不能展示异常栈信息

(8) 对于球员信息配置功能的灵活度尚未达成共识，影响了系统可修改性

(9) 对于球员比赛实时收集响应时间的要求，影响了系统数据存储设计

(10) 主教练提出了训练指标新模式，影响了系统性能和可修改性

根据上述场景生成质量属性效用树，(1)属于性能，(2)(3)属性可用性，(4)属于可修改性，(5)属于安全性，(6)属于易用性，(7)属于可靠性：

我们再根据这些场景分析系统的风险点、敏感点、权衡点。风险点是指某些操作会给系统带来隐患和风险，(8)属于风险点。敏感点是指为了实现某个特定质量属性，一个或多个系统组件所具有的特性，(9)属于敏感点。权衡点是指某些操作会影响系统的多个质量属性，(10)属于权衡点。

第三个阶段是测试阶段，根据足球运动员信息管理系统特性，我们首先确定场景优先级，由高到低分别是：性能、可靠性、可修改性、安全性、可用性、易用性。

架构权衡分析方法所谓权衡在此得到了体现，质量属性每个都很重要，但是根据系统特点需要对质量属性有优先级排序，架构设计时需要所有权衡和折中。

确定了优先级之后，我们需要具体阐述针对每个质量属性系统采取了哪些方案，例如提升性能使用了缓存，提升可修改性使用了策略模式，提升可靠性使用了统一异常处理框架等等，具体方案可以参考互联网系统的一些常见方案。

第四个阶段是报告阶段，我们将评估过程和结果都汇总整理成文档，其中包括质量属性效用树、风险点、敏感点、权衡点和每次评估会议纪要，以及最终的架构决策。

参考资料

文老师软考教育，《系统架构设计师备考一本通》（强力推荐购买此书复习系统架构设计师考试）

希赛教育软考学院，《系统架构设计师教程第四版》（当做字典查阅）

CSDN博客，作者「JAVA前线」，架构权衡评估法（ATAM）

 

posted @ 2023-02-02 20:33  EdisonZhou  阅读(3006)  评论(1)  编辑  收藏  举报