软件设计学习笔记1_架构

Posted 沧海行舸

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件设计学习笔记1_架构相关的知识，希望对你有一定的参考价值。

文章目录

前言

回顾几十年以来计算机应用软件的演变过程，应用程序逐渐由单层体系结构发展为多层体系结构。最初的应用软件只是在大型机上的单层应用，大都采用文件系统存储数据。20世纪70年，随着数据库的普及，原来的单层结构发展为双层结构，即应用层和数据库层，这种方式实现了数据存放与应用程序的分离。但是，负责用户界面交互的代码与业务逻辑混杂在一起，小的系统尚可维护，一旦上升到企业级应用，长期的维护就成了一件十分困难的事情。因此，三层体系结构应运而生，在三层结构中，把原来的应用程序层分成了视图层(UI)和业务逻辑层，数据库层保持不变，进一步解耦了应用程序开发工作。

今天的应用系统，正在产生、收集以及处理前所未有的不断增加的数据，它们正在应对高度复杂的处理流程，并且往往要在跨越典型组织界限的系统和设备之间集成。在这一背景下，一方面应用系统功能体系越发复杂，另一方面其对于可靠性、安全性、可扩展性(如服务器扩容)、可定制化(同一套软件，可根据用户群体的不同和市场需求的变化进行调整)、可伸缩(在新的技术出现时，一个软件应允许导入新的技术，从而对现有系统进行功能和性能扩展)、可维护性(排除现有错误，加入新的功能)、客户体验以及开发效率要求也在不断提升，单纯的层次结构已不能完全满足要求，一些全新的架构被设计出来，用以满足不同场景的软件设计需求，如事件驱动架构、微服务架构、云架构等。本文仅选择分层架构、事件驱动架构、微服务架构进行简要介绍与分析。

一、分层架构

分层架构，是最常见的软件架构。这种架构将应用分成若干个水平层，每一层都有明确的角色和分工，不需要知道其他层的细节，层与层之间通过API通信。

1.1基本模型

分层架构中，层数并没有明确的标准，但四层结构最为常见，如下图所示，从上到下依次为：

  • 表现层（presentation）：用户界面，负责视觉和用户互动
  • 业务层（business）：实现业务逻辑
  • 持久层（persistence）：提供数据，SQL 语句就放在这一层
  • 数据库（database） ：保存数据

    有的软件在逻辑层和持久层之间增加了一个服务层(service)，提供不同业务逻辑需要的一些通用接口。采用分层架构的软件在运行时，用户请求将依次通过4层，不能跳过其中任何一层。

1.2优缺点分析

优点

  • 结构简单，容易理解和开发
  • 不同技能的程序员可以分工，负责不同的层，天然适合大多数软件公司的组织架构
  • 每一层都可以独立测试，其他层的接口通过模拟解决

缺点

  • 一旦环境变化，需要代码调整或增加功能时，通常比较麻烦和费时
  • 部署比较麻烦，即使只修改一个小地方，往往需要整个软件重新部署，不容易做持续发布
  • 软件升级时，可能需要整个服务暂停
  • 扩展性差。用户请求大量增加时，必须依次扩展每一层，由于每一层内部是耦合的，扩展会很困难

二、事件驱动架构

对于事件驱动架构（event-driven architecture,EDA）事件的捕获、通信、处理和持久保留是解决方案的核心，这点和传统的请求驱动模型有很大不同。许多现代应用设计都是由事件驱动的，例如必须实时利用客户数据的客户互动框架。事件驱动应用可以用任何一种编程语言来创建，因为事件驱动本身就是一种编程方法。
事件是指系统硬件或软件的状态出现任何重大改变，而事件的来源可能是内部也可能是外部。事件可以来自用户(例如点击鼠标或按键)、外部源(例如传感器输出)或系统(例如加载程序)。

2.1基本模型

事件驱动架构分成四个部分。

  • 事件队列（event queue）：接收事件的入口
  • 分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元
  • 事件通道（event channel）：分发器与处理器之间的联系渠道
  • 事件使用者(事件处理器)（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作。

    事件驱动架构定义了事件发起者和事件使用者两个角色。事件发起者会检测或感知事件，将其加入事件队列，以消息的形式来表示事件，利用分发器判断使用者(根据使用者订阅信息)，并通过事件通道传输给事件使用者(事件处理器)，而事件使用者则会在该通道中以异步方式处理事件。事件发生时，事件使用者可能会处理事件，也可能只是受事件的影响。
    事件驱动架构可以最大程度减少耦合度，因为事件发起者并不知道哪个事件使用者在监听事件，也不知道事件引起的后续结果。

2.2简化模型

对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件发起者、事件代理和使用者(事件处理器)三部分。

2.3作用机理

事件驱动架构有两种实现模型：
1）发布/订阅模型
这是一种基于事件流订阅的消息传递基础架构。对于该模型而言，在事件发生或公布之后，系统会将相应的消息发送给需要通知的订阅用户。
2）事件流模型
借助事件流模型，事件将被写入日志。事件使用者无需订阅事件流。相反，它们可以从流的任何部分读取并随时加入流。
事件流有几种不同的类型：

  • 事件流处理。使用诸如 Apache Kafka 等数据流平台来提取事件并处理或转换事件流。事件流处理可用于检测事件流中有用的模式。
  • 简单事件处理。指事件立即在事件使用者中触发操作。
  • 复杂事件处理。需要事件使用者处理一系列事件以检测模式。

2.4优缺点分析

优点

  • 分布式的异步架构，事件处理器之间高度解耦，软件的扩展性好
  • 适用性广，各种类型的项目都可以用
  • 性能较好，因为事件的异步本质，软件不易产生堵塞
  • 事件处理器可以独立地加载和卸载，容易部署

缺点

  • 涉及异步编程（要考虑远程通信、失去响应等情况），开发相对复杂
  • 难以支持原子性操作，因为事件通过会涉及多个处理器，很难回滚
  • 分布式和异步特性导致这个架构较难测试

2.5评价

事件驱动架构是一种具有高可扩展性的架构，能够有效增加系统应变能力。此架构中，事件发布者和事件代理实际上构建了一个事件信息权威数据源平台，事件处理器以异步的方式从这个平台中获取所需要的数据并采取相关措施，实现业务目标。其优点是事件处理器可以相互解耦，稳定性高；企业可根据需求变化实时增加、删除、修改事件处理器，灵活性高。设计重点是需要支持高数据吞吐量，需考虑数据传输中出错的情况，需以极快的速度完成事件数据分发和处理降低系统延迟，因此分布式、容错、高容量和高速的事件代理是系统性能的关键。此框架适用范围很广，比如 物联网(IoT)、数字孪生体(DW) 等需数据实时获取、传递和分析处理的系统实现。

三.微服务架构

微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级，既是一种架构，也是一种软件构建方法。微服务采用分布式、松散耦合结构，各服务之间不会相互影响这对于动态可扩展性和容错能力都有一定的好处。

3.1基本模型

在此架构中，应用程序被拆分成最小的组件，彼此独立。其中每一个组件或流程都是一个独立的部署单元（separately deployed unit），互相解耦，通过远程通信协议（比如REST、SOAP）联系，并提供相应的功能服务。

3.2作用机理

  • RESTful API 模式：服务通过 API 提供，云服务就属于这一类
  • RESTful 应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部。
  • 集中消息模式：采用消息代理（message broker），可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群。

一个典型的网站微服务架构如下图所示

3.3优缺点分析

优点

  • 扩展性好，各个服务之间低耦合
  • 容易部署，软件从单一可部署单元，被拆成了多个服务，每个服务都是可部署单元
  • 容易开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级
  • 易于测试，可以单独测试每一个服务

缺点

  • 由于强调互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，性能也会不佳。
  • 一旦服务之间需要通信（即一个服务要用到另一个服务），整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类，一种解决方案是把它们拷贝到每一个服务中去，用冗余换取架构的简单性。
  • 分布式的本质使得这种架构很难实现原子性操作，交易回滚会比较困难。

3.4 评价

微服务与事件驱动框架有区别，但在我看来不明显。微服务与事件驱动框架都属分布式框架，具有低耦合、高容错的优势，事件驱动框架存在消息代理，通过消息流传递数据，典型微服务框架则没有消息代理，但实际应用中也有采用消息代理的情况，如3.2节中所述“集中消息”模式。

四. 总结

以上就是今天要讲的内容，本文简单介绍了三种典型应用软件框架的基本模型，并对其特点进行简析。必须注意到，应用架构既是软件设计方法，也是开发编程方法，一套应用程序可以采用一种架构作为主架构，但其中的功能模块也可根据实际需要采用不同的架构。
架构与应用开发目标，是形式与内容的关系，内容决定形式，形式反过来有利于内容更好地呈现。在实际开发中，当我们在决定新应用的架构或评估当前的架构时，首先一定要分析并确定我们的开发目标是什么，包括应用场景、市场环境、用户需求，设计团队能力边界等，然后再选择合适的应用架构，而不是先选择架构再尝试让应用来适应该架构。

这里是参考文献
[link] https://www.redhat.com/zh/topics/cloud-native-apps/what-is-an-application-architecture
[link] https://www.cnblogs.com/doit8791/p/9343826.html

(软考笔记) ——系统架构设计师 - 软件架构设计笔记

文章目录

软件架构设计

软件架构的概念

架构的定义

     一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系。

     体系结构并非可运行软件，确切的说，它是一种表达，能够是软件工程师：

  1. 分析设计在满足规定需求方面的有效性；
  2. 在设计变更相对容易的阶段，考虑体系结构可能的选择方案；
  3. 降低与软件构造相关联的风险；

软件架构设计与生命周期

需求分析阶段

     从软件需求模型向 SA 模型的转换主要关注两个问题：

  1. 如何根据需求模型构建SA模型；
  2. 如何保证模型转换的可追踪性；

设计阶段

     设计阶段是SA研究关注的最早和最多的阶段，这一阶段的SA研究主要包括：

  1. SA模型的描述；
  2. SA模型的设计与分析方法；
  3. SA的设计经验的总结与复用

     有关 SA模型描述的研究分为三个层次∶

  1. SA的基本概念：即 SA 模型由哪些元素组成，这些组成元素之间按照何种原则组织。
  2. 体系结构描述语言(Architecture Description Language, ADL)： 支持构件、连接子极其配置的描述语言就是如今所说的体系结构描述语言。型的 ADL 包括 UniCon、Rapide、Darwin、Wright、C2 SADL、Acme、xADL、XYZ/ADL和 ABC/ADL 等。
  3. SA模型的多视图表示：从不同的视角描述特定系统的体系结构，从而得到多个视角，，并将这些视图组织起来用来描述整体的SA模型。

     学术界已经提出若干多视图方案，典型的多视图方案有：

  1. 4+1模型（概念视图、模块视图、执行视图、代码视图加上统一的场景）；
  2. CMU-SEI的 Views and Beyond模型（模块视图、构件和连接子视图、分配视图）；
  3. IEEE标准1471-2000（软件密集型系统体系结构描述推荐实践）；
  4. 开放分布式处理参考模型（RM-ODP）；
  5. 统一建模语言（UML）；
  6. IBM提出的Zachman框架；

实现阶段

     实现阶段的体系结构研究在以下几个方面：

  1. 研究基于SA的开发过程支持，如项目组织结构、配置管理等；
  2. 寻求从SA向实现过渡的途径，如将程序设计语言元素引入 SA 阶段、模型映射、构件组装、复用中间件平台等；
  3. 研究基于SA的测试技术；

     为了填补高层 SA 模型和底层实现之间的鸿沟，通过封装底层的实现细节，模型转换、精化等手段缩小概念之间的差距。典型的方法如下：

  1. 在 SA 模型中引入实现阶段的概念，如引入程序设计语言元素等；
  2. 通过模型转换技术，将高层的 SA 模型逐步精化成能够支持实现的模型；
  3. 封装底层的实现细节，使之成为较大粒度构件，在 SA 指导下通过构件组装的方式实现系统，这往往需要底层中间件平台的支持；

构建组装阶段

     在 SA 设计模型的指导下，可复用构件组装可以在较高层次上实现系统，并能够提高系统实现的效率。在构件组装的过程中，SA设计模型起到了系统蓝图的作用。研究内容包括∶

  1. 如何支持可复用的构件的互联，即对SA设计模型中规约的连接子的实现提供支持；
  2. 在组装过程中，如何检测并消除体系结构失配问题；

     中间件支持的连接子实现有如下优势∶

  1. 中间件提供了构件之间跨平台交互的能力，且遵循特定的工业标准， 可以有效地保证构件之间的通信完整性；
  2. 产品化的中间件可以提供强大的公共服务能力，这样能够更好地保证最终系统的质量属性；

     失配是指在软件复用的过程中，由于待复用构件对最线系统的体系结构和环境的假发（assumption〉与实际状况不同而导致的冲突。在构件组装阶段失配问题主要包括：

  1. 由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配；
  2. 由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配；
  3. 由于系统成分对全局体系结构的假设存在冲突引起的失配等，要解决失配问题。首先需要检测出失配问题，井在此基础上通过适当的手段消除检测出的失配问题；

部署阶段

     SA 对软件部署作用如下：

  1. 提供高层的体系结构视图描述部署阶段的软硬件模型；
  2. 基于 SA 模型可以分析部署方案的质量属性，从而选择合理的部署方案；

后开发阶段

     后开发阶段是指软件部署安装之后的阶段。这一阶段的 SA 研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。

动态软件体系结构

     SA在运行时发生的变化包括两类：

  1. 软件内部执行所导致的体系结构的变化；
  2. 软件系统外部的请求对软件进行重新配置；

现阶段，动态软件体系结构研究可分为以下两个部分：

  1. 体系结构设计阶段的支持。主要包括变化的描述、根据变化如何生成修改策略、描述修改过程、在高抽象层次保证修改的可行性以及分析、推理修改所带来的影响等。
  2. 运行时刻基础设施的支持。主要包括系统体系结构的维护、保证体系结构修改在约束范围内、提供系统的运行时刻信息、分析修改后的体系结构符合指定的属性、正确映射体系结构构造元素的变化到实现模块、保证系统的重要子系统的连续执行并保持状态、分析和测试运行系统等。

体系结构的恢复与重建

     SA重建是指从已实现的系统中获取体系结构的过程。一般地，SA 重建的输出是一组体系结构视图。现有的体系结构重建方法可以分为 4 类∶

  1. 手工体系结构重建；
  2. 工具支持的手工重建；
  3. 通过查询语言来自动建立聚集；这类方法适用于较大规模的系统，基本思路是：在逆向工程工具的支持下分析程序源代码，然后将所得到的体系结构信息存入数据库，并通过适当的查询语言得到有效的体系结构显示。
  4. 使用其他技术，比如数据挖掘技术等；

软件架构的重要性

     软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。

  1. 架构设计能够慢慢组系统的品质；
  2. 架构设计使受益人达成一致的目标；
  3. 架构设计能够支持计划编制过程；
  4. 架构设计对系统开发的指导性；
  5. 架构设计能够有效地管理复杂性；
  6. 架构设计为复用奠定了基础；
  7. 架构设计能够降低维护费用；
  8. 架构设计能够支持冲突分析；

基于架构的软件开发方法

体系结构的设计方法概述

     基于体系结构的较件设计（Architecture-Based Software Desig，ABSD）方法。ABSD方法是体系结构驱动，即指构成体系结构的商业、质量和功能需求的组合驱动的。使用ABSD 方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求抽取和分析还没有完成（甚至远远没有完成），就开始了软件设计。ABSD 方法有三个基础：

  1. 功能的分解；
  2. 通过选择体系结构风格来实现质量和商业需求；
  3. 软件模板的使用；

     ABSD 方法是递归的，且迭代的每一个步骤都是清晰地定义的。因此，不管设计是否完成，体系结构总是清晰的，这有助于降低体系结构设计的随意性。

概念和术语

     ABSD的方法过程如下图所示 ：

在这里插入图片描述

  1. 设计元素：BSD 方法是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类；
  2. 视角与视图：考虑体系结构时，重要的是从不同的视角（perspective）来检查，这促使软件设计师考患体系结构的不同履性；
  3. 用例和质量场景： 用例已经成为推测系统在一个具体设置中的行为的重要技术，用例被用在很多不同的场合，用例是系统的一个给予用户一个结果值的功能点，用例用来捕获功能需求；

基于体系结构的开发模型

     传统的软件开发过程可以划分为从概念直到实现的若干过程：

  1. 问题定义；
  2. 需求分析；
  3. 软件设计；
  4. 软件实现；
  5. 软件测试；

     ABSDM（基于体系结构的较件设计模型）把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化6个子过程。如下图所示：

在这里插入图片描述

体系结构需求

     需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。体系结构需求过程如图所示：

在这里插入图片描述
需求获取

     体系结构需求一般来自三个方面，分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标。

标识构件

  1. 生成类图：生成类图的CASE工具有很多，例如Rational Rose 2000。
  2. 对类进行分组： 在生成类图的基础上，使用一些标准对类进行分组可以大大简化类图结构，使之更加清晰。
  3. 把类打包成构件。

架构需求评审

     审查的主要内容包括所获取的需求是否真实反映了用户的要求，类的分组是否合理，构件合并是否合理等。必要时，可以在"需求获取一标识构件一需求评审"之间进行迭代。

体系结构设计

     软件体系设计过程如图所示：

在这里插入图片描述

  1. 提出软件体系结构模型
  2. 把已经标识的构件映射到软件体系结构中去
  3. 分析构件的相互作用
  4. 产生软件体系结构
  5. 设计评审

体系结构文档化

     绝大多数的体系结构都是抽象的，由一些概念上的构件组成。文档是在系统演化的每一个阶段，系统设计与开发入员的通信媒介，是为验证体系结构设计和提炼或修改这些设计（必要时）所执行预先分析的基础。体系结构文档化过程的主要输出结果是体系结构规格说明和测试体系结构需求的质量设计说明书这两个文档。

体系结构复审

     体系结构设计、文档化和复审是一个迭代过程。鉴于体系结构文档标准化，以及风险识别的现实情况，通常我们根据架构设计，搭建一个可运行的最小化系统用于评估和测试体系架构是否满足需要。是否在在可识别的技术和协作风险。

体系结构的实现

     所谓"实现"就是要用实体来显示出一个软件体系结构，即要符合体系结构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。体系结构的实现过程如图所示：

在这里插入图片描述

体系结构的演化

     体系结构演化的过程如图所示：

在这里插入图片描述

     体系结构的演化是使用系统演化步骤去修改应用，以满足新的需求，主要包括以下6个步骤：

  1. 需求变化归类；
  2. 指定体系结构演化计划；
  3. 修改、增加或删除构件；
  4. 更新构件的相互作用；
  5. 构件组装预测试；
  6. 技术评审

软件架构风格

     软件体系结构设计的一个核心目标是重复的体系结构模式， 即达到体系结构级的款件重用。

概述

     软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。

经典软件体系结构风格

管道和过滤器

     每个构件都有一组输入和输出，数据输入构件，经过内部处理，然后产生数据输出。

在这里插入图片描述

数据抽象和面向对象组织

     这种风格的构件是对象，或者说是抽象数据类型的实例：

在这里插入图片描述

事件驱动系统

     事件驱动系统风格是构件不直接调用一个过程，而是触发或广播一个或多个事件。

分层系统

     每一层为上层服务，并作为下客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。

在这里插入图片描述
仓库系统及知识库

     有两种不同的构件，中央数据结构说明当前状态，独立构件在中央数据存储上执行。一方面，若构件控制共享数据，则仓库是一传统型数据库;另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统;
在这里插入图片描述
C2风格

     C2 风格中的系统组织规则如下：

  1. 系统中的构件和连接件都有一个顶部和一个底部。
  2. 构件的顶部应该连接到某连接件的底部，构件的底部则应该连接到某个连接件的顶部。而构件与构件之间的直接连接是不允许。
  3. 一个连接件可以和任意数目的其他构件和连接件连接。
  4. 当两个连接件进行立直接连接时，必须由其中一个的地步连接到另一个的顶部。

     图中构件与连接件之间的连接体现了 C2 风格中构建系统的规则：

在这里插入图片描述
客户/服务器风格(C/S style)

     客户/服务器（C/S）计算技术在信息产业中占有重要的地位。

在这里插入图片描述
     C/S 体系结构主要由三部分组成：

  1. 数据库服务器
    1. 数据库安全性的要求；
    2. 数据库访问并发性控制；
    3. 数据库前端的客户应用程序的全局数据完整性规则；
    4. 数据库的备份与恢复；
  2. 客户应用程序
    1. 提供用户与数据库交互的界面；
    2. 向数据库服务器提交用户请求并接收来自数据库服务器的信息；
    3. 利用客户应用程序对存在于客户端的数据执行应用逻辑要求；
  3. 网络

     但随着企业规模的日益扩大，软件的复杂程度不断提商，C/S 体系结构逐渐暴露了以下缺点：

  1. 开发成本较高；
  2. 客户端程序设计复杂；
  3. 信息内容和形式单一；
  4. 用户界面风格不一；
  5. 软件移植困难；
  6. 软件维护和升级困难；

三层C/S结构风格

     在三层 C/8 体系结构中，增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。这种结构被称为"瘦客户机"。三层 C/S 体系结构是将应用功能分成表示层、功能层和数据层三个部分。结构如图所示：

在这里插入图片描述

  1. 表示层：表示层是应用的用户接口部分担负与应用逻辑间的对话功能。它用于用户从工作站输入的数据，并显示应用输出的数据。
  2. 功能层：功能层是应用的本体，它负责具体的业务处理逻辑，例如在制作订购合同时要计算合同金额。表示层和功能层之间的数据互交要尽可能简洁。
  3. 数据层：数据层通常是数据库管理系统，负量管理对数据库数据的读写。数据库系统必须能迅速执行大量数据的更新和检索。

浏览器/服务器风格(browser/server, B/S Style)

     浏览器/服务器（browser/server，B/S）风格就是上述三层应用结构的一种实现方式。其具体结构为浏览器/Web 服务器/数据库服务器。基于 B/8 体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块。

     与 C/S体系结构相比，B/ 体系结构也有许多不足之处，例如:

  1. B/S 体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；
  2. B/S 体系结构的系统扩展能力差，安全性较难以控制；
  3. 采用 B/S 体系结构的应用系统，在数据查询等响应速度上，要远远地低于 C/S 体系结构；
  4. B/S 体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理（online transaction processing，OLTP）应用。

     因此，应用系统常以 C/S 和 B/S 混合应用形式出现，如图所示:

在这里插入图片描述

特定软件领域的体系结构

     早在 20 世纪 70 年代就有人提出程序族、应用族的概念。特定领域软件体系结构的主要目的是在一组相关的应用中共享软件体系结构。

DSSA的定义

     （Domain Specific Software Architecture，DSSA）就是在一个特定应用领城中为一组应用提供组织结构参考的标准软件体系结构。对 DSSA研究的角度、关心的问题不同导致了对 DSSA 的不同定义。

     Hayes Roth 对DSSA 的定义如下∶"DSSA 就是专用于一类特定类型的任务（领域）的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。"

     Tracz 的定义为;“DSSA 就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考体系结构等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成。”

     通过对众多的DSSA 的定义和描述的分析，可知 DSSA 的必备特征如下∶

  1. 一个严格定义的问题和问题解域；
  2. 具有普遍性，使其可以用于领域中某个特定应用的开发；
  3. 对整个领域的构件组织模型的恰当抽象；
  4. 具备该领域固定的、典型的在开发过程中可重用的元素；

DSSA的基本活动

     实施 DSSA 的过程中包含了一些基本的活动。虽然具体的 DSSA方法可能定义不同的概念、步骤和产品等，但这些基本活动大体上是一致的。可以将其分为以下的三个阶段：

  1. 领域分析： 这个阶段的主要目标是获得领域模型。领域模型描述领域中系统之间的共同的需求，即领域模型所描述的需求为领域需求。
  2. 领域设计： 这个阶段的目标是获得 DSSA。DSSA 描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。
  3. 领域实现：这个阶段的主要目标是依据领城模型和 DSSA 开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。

     值得注意的是，以上过程是一个反复的、逐渐求精的过程。在实施领域工程的每个阶段中，都可能返回到以前的步骤，对以前的步聚得到的结果进行修改和完善，再回到当前步骤，在新的基础上进行本阶段的活动。

参与DSSA的人员

     参与 DSSA的人员可以划分为4种角色∶领域专家、领域分析师、领域设计人员和领域实现人员：

  1. 领域专家：领域专家可能包括该领域中系统的有经验的用户、从事该领城中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA 等领域工程产品等。领域专家应该熟悉该领域中系统的软件设计和实现、硬件限制、未来的用户需求及技术走向等。
  2. 领域分析人员：领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。领域分析人员的主要任务包括控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中，根据现有系统、标准规范等验证领域模型的准确性和一致性，维护领域模型。领域分析人员应熟悉软件重用和领域分析方法;熟悉进行知识获取和知识表示所需的技术、语言和工具;应具有一定的该领域的经验，以便于分析领域中的问题及与领域专家进行交互;应具有较商的进行抽象、关联和类比的能力; 应具有较高的与他人交互和合作的能力。
  3. 领域设计人员：领域设计人员应由有经验的软件设计人员来担任。领域设计人员的主要任务包括控制核个软件设计过程，根据领域模型和现有的系统开发出 DSSA，对 DSSA 的准确性和一致性进行验证，建立领域模型和 DSSA.之间的联系。领域设计人员应熟悉软件重用和领域设计方法;熟惑软件设计方法;应有一定的该领域的经验，以便于分析领域中的问题及与领域专家进行交互。
  4. 领域实现人员：领填实现人员应由有经验的程序设计人员来担任。领域实现人员的主要任务包括根据领域模型和 DSSA，或者从头开发可重用构件，或者利用再工程的技术从现有系统中提取可重用构件，对可重用构件进行验证，建立 DSSA 与可重用构件间的联系。领域实现人员应熟悉软件重用、领域实现及软件再工程技术;熟悉程序设计;具有一定的该领域的经验。

DSSA的建立过程

     DSSA 的建立过程分为 5 个阶段，每个阶段可以进一步划分为一些步骤或子阶段。每个阶段包括一组需要回答的问题，一组微要的输入，一组将产生的输出和验证标准。本过程是并发的（concurent）、递归的（recursive）、反复的（iterative）。或者可以说，它是螺旋模型（spiral）。完成本过程可能需要对每个阶段经历几遍，每次增加更多的细节：

  1. 定义领域范围： 本阶段的重点是确定什么在感兴趣的领域中以及本过程到何时结束。这个阶段的一个主要输出是领域中的应用需要满足一系列用户的需求。
  2. 定义领域特定的元素：∶本阶段的目标是编译领域字典和领域术语的同义词词典。在领域工程过程的前一个阶段产生的高层块翻将被增加更多的细节，特别是识别领域中应用间的共同性和差异性。
  3. 定义领域特定的设计和实现需求约束∶本阶段的目标是描述解空间中有差别的特性。不仅要识别出约束，并且要记录约束对设计和实现决定造成的后果，还要记录对处理这些问题时产生的所有问题的讨论。
  4. 定义领域模型和体系结构;本阶段的目标是产生一般的体系结构，并说明构成它们的模块酸构件的语法和语义。
  5. 产生，搜集可重用的产品单元∶本阶段的目标是为 DSSA 增加构件，使它可以被用来产生问题域中的新应用。

     SSA 的一个三层次系统模型：

在这里插入图片描述

系统架构的评估

概述

     在体系结构评估过程中，评估人员所关注的是系统的质量属性，所有评估方法所普遍关注的质量属性有以下几个：

  1. 性能(performance)： 是指系统的响应能力，即要经过多长时间才能对某个事件作出响应，或者在某段事件内系统所能处理的事性的个数。
  2. 可靠性(reliability) ：） 是教件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性是最重要的软件特性，通常用它衡最在规定的条件和时间内，软件完成规定功能的能力。可靠性通常用平均失效等特时间（mean time to failure，MTTF）和平均失效间隔时间（mean time between failure，MTBF）来衡量。在失效率为常数和修复时间很短的情况下，MTTF 和MTBF 几乎相等。可靠性可以通过容错能力和健壮性来衡量。
  3. 可用性(availability)： 是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
  4. 安全性(security)： 是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或柜绝服务的能力。安全性是根据系统可能受到的安全威胁的类型来分类的。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。其中，机密性保证信息不泄露给未授权的用户、实体或过程，完整性保证信息的完整和准确，防止信息被非法修改;可控性保证对信息的传播及内容具有控制的能力，防止为养法者所用。
  5. 可修改性(modifiability)： ）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。可修改性包含以下4个方面：
    1. 可维护性（mainpainability）：这主要体现在间题的修复上;在错误发生后"修复"软件系统。为可维护性做好准备的软件体系结构往往能做局部性的修改并能使对其他构件的负面影响最小化。
    2. 可扩展性（extendibility）。这一点关注的是使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。为了实现可扩展性，软件系统需要松散耦合的构件。其目标是实现一种体系结构。它能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的体系结构中也是必要的。
    3. 结构重组（reassemble）。这一点处理的是重新组织软件系统的构件及构件间的关系，例如通过将构件移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计构件之间的关系。理想情况下，它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。
    4. 可移植性（portability）。可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植，需要按照硬件无关的方式组织软件系统，其他软件系统和环境被提取出。可移植性是系统能够在不筒计算环境下运行的能力，这些环境可能是硬件、软件，也可能是两者的结合。在关于某个特定计算环境的所有假设都集中在一个构件中时，系统是可移植的。如果移植到新的系统需要做些更改，则可移植性就是一种特殊的可修改性。
  6. 功能性（functionality）是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
  7. 可变性（changeability）是指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品（例如，软件产品线）的基础时，可变性是很重要的。
  8. 互操作性：作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性（inter-operation），软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件体系结构。

评估中的重要概念

     敏感点（sensitivity point）和权衡点（tradeoff point）。敏感点和权衡点是关键的体系结构决策。敏感点是一个或多个构件（和/或构件之间的关系）的特性。研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

     风险承担者（stakeholders）或者称为利益相关人。系统的体系结构涉及很多人的利益，这些人都对体系结构施加各种影响，以保证自己的目标能够实现。下表列出了一些系结构评估中可能涉及的一些风险承担者及其所关心的问题：

在这里插入图片描述

在这里插入图片描述

     场景（scenarios）在进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。为得出这些目标而采用的机制叫做场景。场景是从风险承担者的角度对与系统的交互的简短描述。在体系结构评估中，一般采用刺激（stimulus）、环境（environment）和响应（response）三方面来对场景进行描述。

主要评估方法

SAAM

     SAAM（Scenarios-based Architecture Analysis Method）是卡耐基梅隆大学软件工程研究所（SEIat CMU）的Kazman 等人于 1983年提出的一种非功能质量属性的体系结构分析方法，是最早形成交档并得到广泛使用的软件体系结构分析方法。

     最初它用于比较不同的软件体系的体系结构，以分析 SA 的可修改性，后来实践证明也可用子其他的质量属性如可移植性、可扩充性等，发展成了评估一个系统的体系结构。

  1. 特定目标： ∶SAAM 的目标是对描述应用程序属性的文档，验证基本的体系结构假设和原则。此外，该分析方法有利子评估体系结构固有的风险。SAAM 指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突，或仅从某一参与者的观点出发的不全面的系统设计。SAAM 不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。
  2. 评估技术;SAAM 所使用的评估技术是场景技术。场最代表了描述体系结构属性的基础，描述了各种系统必须支持的活动和将要发生的变化。
  3. 质量属性∶这一方法的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是 SAAM 分析的主要质量属性。
  4. 风险承担者∶SAAM 协调不同参与者所感兴趣的方面，作为后续决策的基础，提供了对体系结构的公共理解。
  5. 体系结构描述∶SAAM用于体系结构的最后版本，但早于详细设计。体系结构的描述形式应当被所有参与者理解。功能、结构和分配被定义为描述体系结构的三个主要方面。
  6. 方法活动∶SAAM 的主要输入问题是问题描述、需求声明和体系结构描述。下图描绘了SAAM 分析活动的相关输入及评估过程。
  7. 目前知识库的可重用性∶SAAM不考虑这个问题。
  8. 方法验证∶SAAM是一种成熟的方法，已被应用到众多系统中，这些系统包括空中交通管制、嵌入式音频系统、WRCS（修正控制系统）、KW IC【8】（根据上下文查找关键词系统）等。

在这里插入图片描述

ATAM

     体系结构权衡分析方法（Architecture Tradeof Analysis Method，ATAM）是在 SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

  1. 特定目标∶ATAM 的目标是在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件体系结构的能力的方法。对于特定的软件体系结构，在系统开发之前，可以使用 `ATAM 方法确定在多个质量属性之间折中的必要性。
  2. 质量属性;ATAM方法分析多个相互竞争的质量属性。开始时考虑的是系统的可修改性、安全性、性能和可用性。
  3. 风险承担者;在场景、需求收集有关的活动中，ATAM方法篮要所有系统相关人员的参与。
  4. 体系结构描述∶体系结构空间受到历史遗留系统、互操作性和以前失败的项目约束。在5 个基本结构的基础上进行体系结构描述，这5 个结构是从Kruchten 的4+1 视图源生而来的。其中逻辑视图被分为功能结构和代码结构。这些结构加上它们之间适当的映射可以完整地描述一个体系结构。
  5. 评估技术∶可以把 ATAM方法视为一个框架，该框架依赖于质量属性，可以使用不同的分析技术。它集成了多个优秀的单一理论模型，其中每一个都能够高效、实用地处理属性。该方法使用了场景技术。从不同的体系结构角度，有三种不同类型的场景，分别是用例（包括对系统典型的使用，还用于引出信息）、增长场景（用于涵盖与它的系统修改）、探测场景〈用于涵盖那些可能会对系统造成压迫的极端修改）。ATAM 还使用定性的启发式分析方法（Qualitative Analysis Heuristics），在对一个质量属性构造了一个精确分析模型时要进行分析，定性的启发式分析方法就是这种分析的粗粒度版本。
  6. 方法的活动∶ATAM 被分为 4 个主要的活动领域（或阶段），分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。下图描述了与每个阶段相关的步骤，还描述了体系结构设计和分析改进中可能存在的迭代。
  7. 领域知识库的可重用性∶领域知识库通过基于属性的体系结构风格（Atribute-Based Architectare Style）维护。ABAS有助于从体系结构风格的概念转向基于特定质量具性模型的推理能力。获取一组基-予属性的体系结构风格的目标在于要把体系结构设计变得更为惯例化、更可预测，并得到一个基于属性的体系结构分析的标准问题集合，使设计与分析之间的联系更为紧密。
  8. 方法验证∶该方法已经应用到多个软件系统，但仍处在研究之中。虽然软件体系结构分析与评价已经取得了很大的进步，但是在某些方面也存在一些间题。例如，体系结构的描述、质量特征的分析、场景不确定性的处理、度量的应用体系结构分析和评价支持工具等，这些都影响和制约着分析评估技术的发展。Clement 认为在未来的 5～10 年内，体系结构的分析是体系结构发展的 5个方向之一。

在这里插入图片描述

个人格言

用心去感受你自己需要坚持的生活，未来慢慢会给你答案的。

在这里插入图片描述

以上是关于软件设计学习笔记1_架构的主要内容，如果未能解决你的问题，请参考以下文章

构建之法阅读笔记01

《20170914-构建之法：现代软件工程-阅读笔记》

架构之道-软件构建的设计方法-读书笔记

架构之道-软件构建的设计方法-读书笔记

构建之法笔记1

架构整洁之道 7~12章读书笔记