架构师知识梳理（十）：系统架构设计与评估

架构基本概念

软件架构：从需求分析到软件设计之间的过渡过程称为软件架构，软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成。

软件架构的职责：架构设计就是需求分配，将满足需求的职责分配到组件上。

软件架构的目的：解决好软件的复用、质量和维护问题

架构设计及生命周期

需求分析阶段

需求分析和SA设计面临的是不同的对象：一个是问题空间，另一个是解空间。
从软件需求模型向SA模型的转换主要关注两个问题：如何根据需求模型构建SA模型，以及如何保证模型转换的可追踪性。

设计阶段

这是SA研究关注的最早和最多的阶段。
研究内容包括：SA模型的描述、SA模型的设计与分析方法，以及对SA设计经验的总结与复用等。
有关SA模型描述的研究分为3个层次：SA的基本概念（构件和连接子）、体系结构描述语言ADL、SA模型的多视图表示。

实现阶段

最初SA研究往往只关注较高层次的系统设计、描述和验证。
实现阶段的体系结构研究表现在以下几个方面：
- 研究基于SA的开发过程支持，如项目组织结构、配置管理等。
- 寻求从SA向实现过渡的途径，如将程序设计语言元素引入SA阶段、模型映射、构件组装、复用中间件平台等。
- 研究基于SA的测试技术。

构件组装阶段

在SA设计模型的指导下，可复用构件的组装可以在较高层次上实现系统，并能够提高系统实现的效率。
在构件组装的过程中，SA设计模型起到了系统蓝图的作用。
研究内容包括如下两个方面。（注：图片内容在这里未完整，可能缺少具体的研究内容描述。）
如何支持可复用构件的互联，即对SA设计模型中规约的连接子的实现提供支持。
在组装过程中，如何检测并消除体系结构失配问题。
失配问题主要包括：由构件引起的失配、由连接子引起的失配、由于系统成分对全局体系结构的假设存在冲突引起的失配等。

部署阶段

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

后开发阶段

指软件部署安装之后的阶段。这一阶段的SA研究主要围绕维护、演化、复用等方面来进行。
典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。
动态软件体系结构：现实中的软件具有动态性，体系结构会在运行时发生改变。运行时变化包括两类：软件内部执行所导致的体系结构改变；软件系统外部的请求对软件进行的重配置。包括两个部分的研究：体系结构设计阶段的支持、运行时刻基础设施的支持。
体系结构恢复与重建：对于现有系统在开发时候没有考虑SA的情况，从这些系统中恢复或重购体系结构。从已有的系统中获取体系结构的重建方法分为4类：手工体系结构重建、工具支持的手工重建、通过查询语言来自动建立聚集、使用其他技术（如数据挖掘等）。

构件

什么是构件

在软件架构设计中，构件（Component）是指系统中的一个可替换、可封装的单元，它具有明确的职责和功能。构件通常被视为系统中的一个"构建块"，它可以独立开发、测试、部署和维护。构件之间通过定义良好的接口进行交互，这些接口隐藏了构件的内部实现细节，使得构件的替换和升级变得更加容易。

构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署，但它也能够被单独部署。

构件和原子构件之间的区别在于：

大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。
相反，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。

模块的概念：

一个模块是不带单独资源的原子构件。
一个单独的包被编译成多个单独的类文件，每个公共类都有一个。
模块是一组类和可能的非面向对象的结构体，比如过程或者函数。

常见构件及特点

构件的特性包括：

独立部署单元：构件可以作为一个单独的单元进行部署。
作为第三方的组装单元：构件可以被第三方使用，并作为组装更大系统的一部分。
没有（外部的）可见状态：构件对外不暴露其内部状态，保持封装性。

构件的概念在不同的架构风格中有不同的表现形式，以下是一些常见的构件类型和它们的特点

模块：在模块化的软件系统中，模块是常见的构件类型。模块通常封装了特定的功能，并且可以通过函数或方法调用来使用这些功能。
- 例如，在Java中，一个类可以被视为一个模块，它可以被实例化为对象，并且可以通过对象的方法来访问其功能。
服务：在服务导向架构（SOA）或微服务架构中，服务是作为构件存在的。服务通常通过网络调用，提供特定的业务功能。
- 例如，一个在线商店的购物车服务，它通过网络接口接收添加商品、删除商品和结算等请求。
库和框架：库和框架提供了一组可重用的代码，这些代码可以被多个应用程序或项目使用。
- 例如，jQuery是一个流行的JavaScript库，它提供了简化HTML文档遍历和操作、事件处理、动画和Ajax的函数。
插件：插件是一种特殊的构件，它可以添加到一个主应用程序中，以扩展其功能。
- 例如，Web浏览器经常支持各种插件，如Adobe Flash Player，这些插件可以增强浏览器的功能，使其能够播放视频或动画。
微服务：在微服务架构中，每个微服务都是一个独立的构件，它实现了特定的业务功能，并且可以独立部署和扩展。
- 例如，一个电子商务平台可能由多个微服务组成，如用户服务、产品目录服务、订单处理服务等。

构件技术

构件技术就是利用某种编程手段，将一些人们所关心的，但又不便于让最终用户去直接操作的细节进行了封装，同时对各种业务逻辑规则进行了实现，用于处理用户的内部操作细节。

目前，国际上常用的构件标准主要有三大流派：

EJB (Enterprise Java Bean) 规范由 Sun 公司制定，有三种类型的 EJB，分别是：
- 会话 Bean (Session Bean)
- 实体 Bean (Entity Bean)
- **消息驱动 Bean (Message-driven Bean)**EJB 实现应用中关键的业务逻辑，创建基于构件的企业级应用程序。
COM、DCOM、COM+：
- COM 是微软公司的。
- DCOM 是 COM 的进一步扩展，具有位置独立性和语言无关性。
- COM+ 并不是 COM 的新版本，是 COM 的新发展或是更高层次的应用。
CORBA 标准 主要分为三个层次：
- 对象请求代理 (ORB)
- 公共对象服务
- 公共设施最底层是对象请求代理 ORB，规定了分布对象的定义（接口）和语言映射，实现对象间的通讯和互操作，是分布对象系统中的"软总线"；在 ORB 之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务（交易）服务、安全服务等各种各样的服务；最上层的公共设施则定义了组件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。

面向构件编程（COP）

COP关注于如何支持建立面向构件的解决方案。面向构件的编程需要下列基本的支持：

多态性（可替代性）：允许在不知晓具体实现的情况下，使用一个构件替换另一个具有相同接口的构件。
模块封装性（高层次信息的隐藏）：构件应该能够封装其内部实现细节，只暴露必要的接口给外部环境。
后期的绑定和装载（部署独立性）：构件应该能够在运行时被绑定和装载，而不需要在编译时就确定所有依赖。
安全性（类型和模块安全性）：需要确保构件的类型安全，并且模块级别的安全性得到保障，防止未授权的访问和操作。

架构风格

架构风格定义

架构风格是描述某一特定应用领域中系统组织方式的惯用模式，架构风格反映了领域中众多系统 所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

架构风格

数据流风格

面向数据流，按照一定的顺序从前向后执行程序，代表的风格有批处理序列、管道-过滤器。

批处理序列

构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始。数据必须是完整的，以整体的方式传递。

代表系统有：传统的编译器，它由多个阶段组成，如词法分析、语法分析等，一个阶段的输出是另一个阶段的输入。

管道-过滤器

每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，产生输出数据流。前一个构件的输出作为后一个构件的输入，前后数据流关联。过滤器就是构件，连接件就是管道。

代表系统有：一个典型的例子是Unix管道，其中多个程序可以通过管道连接，前一个程序的输出成为后一个程序的输入。

二者的区别在于：

批处理序列中，前后构件不一定有关联，并且数据是作为整体传递的，即必须前一个执行完才能执行下一个。
管道-过滤器中，前一个构件的输出作为后一个的输入，前面执行到部分可以开始下一个的执行。

调用返回风格

构件之间存在互相调用的关系，一般是显式的调用，代表的风格有主程序/子程序、面向对象、层次结构。

主程序/子程序

单线程控制，把问题划分为若干个处理步骤。构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，充当连接件的角色。

面向对象

构件是对象，对象是抽象数据类型的实例。连接件是对象间交互的方式，对象是通过函数和过程的调用来交互的。

层次结构

构件组成一个层次结构，连接件通过决定层间如何交互的协议来定义。
每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。
修改某一层，最多影响其相邻的两层（通常只能影响上层）。

层次结构的优点：

支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。
不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高。
由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持。

层次结构的缺点：

并不是每个系统都可以很容易地划分为分层的模式。
很难找到一个合适的、正确的层次抽象方法。

构件风格

构件之间是互相独立的，不存在显式的调用关系，而是通过某个事件触发、异步的方式来执行，代表的风格有进程通信、事件驱动系统（隐式调用）。

进程通信

构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等。

事件驱动

构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册 ，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。

构件风格的主要优点是为++软件复用提供了强大的支持++，为构件的维护和演化带来了方便；

缺点则是++放弃了对系统计算的控制++。

虚拟机风格

自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配，代表的风格有解释器、基于规则的系统。

解释器

通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，缺点是执行效率低。

基于规则的系统

包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。

仓库风格

以数据为中心，所有的操作都是围绕建立的数据中心进行的，代表的风格有数据库系统、超文本系统、黑板系统。

数据库系统

构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。

超文本系统

构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。是一种非线性的网状信息组织方法，它以节点为基本单位，链作为节点之间的联想式关联。通常应用在互联网领域。

黑板系统

包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中（信号处理、问题规划和编译器优化等）。

闭环-控制

当软件被用来操作一个物理系统时，软件与硬件之间可以粗略地表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态，适合于嵌入式系统，涉及连续的动作与状态。

C2风格

C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：

(1) 系统中的构件和连接件都有一个顶部和一个底部；

(2) 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；

(3) 一个连接件可以和任意数目的其它构件和连接件连接；

具体的系统架构

两层CS架构

客户端和服务器都有处理功能，现在已经不常用，原因有：开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一、软件移植困难、软件维护和升级困难、新技术不能轻易应用、安全性问题、服务器端压力大难以复用。

三层CS架构

将处理功能独立出来，表示层和数据层都变得简单。表示层在客户机上 ，功能层在应用服务器上，数据层在数据库服务器上。即将两层C/S架构中的数据从服务器中独立出来了。其优点下面四点：

各层在逻辑上保持相对独立，整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性；
允许灵活有效的选用相应的平台和硬件系统，具有良好的可升级性和开放性；
各层可以并行开发，各层也可以选择各自最适合的开发语言；
功能层有效的隔离表示层与数据层，为严格的安全管理奠定了坚实的基础，整个系统的管理层次也更加合理和可控制。

MVC架构

控制器(Controller) :是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

模型(Model) :是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。模型表示业务数据和业务逻辑。

视图(View) :是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，但是它并不进行任何实际的业务处理。

MVC分层有助于管理复杂的应用程序 ，因为您可以在一个时间内专门关注一个方面。例如，您可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。

MVC分层同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。

SOA架构

SOA（面向服务的架构）是一种设计理念，其中包含多个服务 ，服务之间通过相互依赖 最终提供一系列完整的功能 。各个服务 通常以独立的形式部署运行，服务之间通过网络 进行调用。

面向服务架构运作方式：

WEB Service

服务提供者、服务注册中心（中介，提供交易平台，可有可无）、服务请求者。服务提供者将服务描述发布到服务注册中心，供服务请求者查找，查找到后，服务请求者将绑定查找结果。如图

服务注册表

(1)服务注册:应用开发者（服务提供者）在注册表中公布服务的功能

(2)服务定位:服务使用者（服务应用开发者），帮助他们查询注册服务，寻找符合自身要求的服务。

(3)服务绑定:服务使用者利用检索到的服务接口来编写代码，所编写的代码将与注册的服务绑定，调用注册的服务，实现互动。

架构评估

软件架构评估在架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求，但不是单纯的确定是否满足需求。

质量属性

在架构设计中，质量属性（Quality Attributes）指的是系统在满足功能性需求之外的那些特性，它们定义了系统的性能和用户体验。质量属性通常与系统的非功能性需求相关。

性能

指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。

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

可靠性

是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF。

设计策略 ：心跳、Ping/Echo、冗余、选举。

可用性

是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。

设计策略 ：心跳、Ping/Echo、冗余、选举。

安全性

是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。

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

可修改性

指能够快速的以较高的人效性价比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。

设计策略 ：接口-实现分类、抽象、信息隐藏。

功能性

是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。

可变性

指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。

互操作性

作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。

质量属性场景

质量属性场景（Quality Attribute Scenarios, QAS）是一种用于识别、分析和优先级排序软件架构中的质量属性的方法。这种方法通过定义一系列与质量属性相关的场景，帮助架构师理解和评估系统在特定情境下的表现。

质量属性场景是一种面向特定质量属性的需求。它由6部分组成:

刺激源(Source):这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)。
.刺激(Stimulus):该刺激是当刺激到达系统时需要考虑的条件。
环境(Environment):该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
·制品(Artifact):某个制品被激励。这可能是整个系统，也可能是系统的一部分。
·响应(Response):该响应是在激励到达后所采取的行动。
·响应度量(Measurement):当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

可修改性质量属性场景描述实例:

场景要素	可能的情况
刺激源	最终用户、开发人员、系统管理员
刺激	希望增加、删除、修改、改变功能、质量属性、容量等
环境	系统设计时、编译时、构建时、运行时
制品	系统用户界面、平台、环境或与目标系统交互的系统
响应	查找架构中需要修改的位置,进行修改且不会影响其他功能,对所做的修改进行测试,部署所做的修改
响应度量	根据所影响元素的数量度量的成本、努力、资金;该修改对其他功能或质量属性所造成影响的程度

敏感点

是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。

例如：

正确的索引可以显著提高查询性能，但过多的索引可能会降低更新表的性能。
使用缓存可以减少数据库访问次数，提高响应速度，但需要考虑缓存一致性和失效策略。
对敏感数据进行加密可以保护数据不被未授权访问，但加密和解密过程会增加系统开销。
适当的日志记录有助于故障诊断和性能监控，但过多的日志可能会影响性能并增加存储成本。

权衡点

是影响多个质量属性的特性，是多个质量属性的敏感点。

例如：

提高系统并发处理能力可以改善响应时间，但可能会导致资源竞争和更高的硬件成本。
增加认证因素可以提高安全性，但可能会降低用户体验，因为用户需要通过更多步骤来验证身份。

关于风险点与非风险点

不是以标准专业术语形式出现的，只是一个可能引起风险的因素，可称为风险点。某个做法如果有隐患，有问题，则为风险点；而如果某件事是可行的可接受的，则为非风险点。

架构评估方式

基于调查问卷（检查表）的方式：

类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。

基于度量的方式：

制定一些定量指标来度量架构，如代码行数等。要制定质量属性和度量结果之间的映射，要求评估人员对架构熟悉。

基于场景的方式：

主要方法。首先要确定应用领域的功能 和软件架构的结构 之间的映射，然后要设计用于体现待评估质量属性的场景（即4+1视图中的场景），最后分析软件架构对场景的支持程度。要求评估人员即对领域熟悉，也对架构熟悉。从三个方面对场景进行设计：刺激（事件）；环境（事件发生的环境）；响应（架构响应刺激的过程）。

中间件技术

中间件是在一个分布式系统环境中处于操作系统和应用程序之间的一类软件，可以在不同的技术之间共享资源，将不同的操作系统、数据库、异构的网络环境以及若干应用结合成一个有机的协同工作整体。

中间件位于客户机/服务器的操作系统之上，管理计算机资源和网络通信，有如下特点

中间件是一类软件，而非一种软件;
中间件不仅仅实现互连，还要实现应用之间的互操作;
中间件是基于分布式处理的软件，最突出的特点是其网络通信功能。

中间件的任务是使应用程序开发变得更容易，通过提供统一的程序抽象，隐藏异构系统和分布式系统下低级别编程的复杂度。

中间件分类

数据库访问中间件

通过一个抽象层访问数据库，从而允许使用相同或相似的代码访问不同的数据库资源。典型的技术如Windows平台的ODBC和Java平台的JDBC等。

远程过程调用(RPC)

是一种广泛使用的分布式应用程序处理方法。一个应用程序使用RPC来"远程"执行一个位于不同地址空间内的过程，从效果上看和执行本地调用相同。

面向消息中间件(MOM)

利用高效可靠的消息传递机制进行平台无关的数据交流，并可基于数据通信进行分布系统的集成。通过提供消息传递和消息排队模型，可在分布环境下扩展进程间的通信，并支持多种通信协议、语言、应用程序、硬件和软件平台。典型的产品如IBM的MQSeries。

分布式对象中间件

随着对象技术与分布式计算技术的发展，两者相互结合形成了分布式对象技术，并发展成为当今软件技术的主流方向。典型的产品如OMG的CORBA、Sun的RMI/EJB、Microsoft的DCOM等。

事务中间件

也称事务处理监控器(TPM)最早出现在大型机上。事务处理监控程序位于客户和服务器之间，完成事务管理与协调、负载平衡、失效恢复等任务，提高系统的整体性能。

开发方法

ABSD（基于架构的软件设计）

ABSD（Architecture-Based Software Design，基于架构的软件设计）是一种架构驱动的软件开发方法，它强调由业务、质量和功能需求的组合来驱动架构设计。ABSD方法有三个基础：功能分解、通过选择架构风格来实现质量和业务需求、以及软件模板的使用。ABSD方法是一个自顶向下，递归细化的方法，它以软件系统功能的分解为基础，通过选择架构风格实现质量和商业需求，并强调在架构设计过程中使用软件架构模板。

ABSD方法是架构驱动，++强调由业务、质量和功能需求的组合驱动架构设计++ 。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景 来描述需求。进一步来说，用例描述的是功能需求，质量属性场景描述的是质量需求(或侧重于非功能需求)。

使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成，就开始了软件设计。ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，有助于降低架构设计的随意性。软件系统的体系结构通过该方法得到细化直至产生软件构件和类。

补充：4+1视图

4个视图：

逻辑视图（Logical View）：这个视图关注系统的功能需求，即系统对外提供的功能服务。它通过识别系统中的关键抽象，如类、对象等，来展示系统的组件结构和数据结构。在面向对象的设计中，逻辑视图通常使用UML类图来表示，展示类之间的关系，如继承、关联和依赖。

开发视图（Development View）：也称为实现视图，这个视图关注软件在开发环境下的静态组织结构。它描述了软件如何被分解为模块或包，以及这些模块如何组织和构建。开发视图有助于开发人员理解系统的开发和部署结构。

物理视图（Physical View）：这个视图描述了软件如何映射到硬件上，反映了系统的物理部署和分布式特性。它关注软件的物理部署，包括软件组件如何在不同的节点上分布，以及它们之间的通信方式。

进程视图（Process View）：这个视图关注系统的动态运行时特征，包括进程、线程、对象等的并发和同步问题。它描述了逻辑视图中的组件如何在进程中执行，以及它们之间的交互和通信。

1个场景：

场景视图（Scenarios View）：作为补充视图，场景视图通过用例或场景来综合解释和说明其他四个视图。它关注系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计。场景视图有助于将其他视图联系起来，提供一个全面的系统行为视图

ABSD的基础

ABSD方法有三个基础。

第一个基础是功能的分解，使用已有的基于模块的内聚和耦合技术；
第二个基础是通过选择架构风格 来实现质量和业务需求；
第三个基础是软件模板的使用，软件模板利用了一些软件系统的结构。

ABSD的过程

基于架构的软件开发过程主要分为6步：即体系结构需求、体系结构设计、体系结构文档化 、体系结构复审、体系结构实现 、体系结构演化

体系结构需求

架构需求的核心在于掌握标识构件 ，所谓标识构件主要是生成类图 、对类进行分组 、把类打包成构件，架构需求的输出主要是构件标识

体系结构设计

主要是将需求阶段产生的标识构件转为真实构件，主要步骤为提出整体架构模型，进行构件映射，分析构件关系，生成架构，评审。

体系结构文档化

主要产出两种文档，即架构（体系结构）规格说明，测试架构（体系结构）需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败。

体系结构复审

也就是评审，外部人员（独立于开发组织之外的人，如用户代表和领域专家等）参加的复审，复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化，再复审。

体系结构实现

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

体系结构演化

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

DSSA（特定领域软件架构）

DSSA（Domain Specific Software Architecture，特定领域软件架构）是针对特定领域的软件开发，提出的一个软件架构方法论。DSSA侧重于该领域内软件系统的共性和可复用性，通过定义通用的框架、组件和模式，来指导和简化该领域内软件的开发过程。它的目的是提高软件的开发效率、质量和可维护性，同时减少开发成本。

DSSA的基本活动

参与DSSA的角色有，领域专家、领域分析人员、领域设计人员、领域实现人员，而主要的活动包括：

领域分析

这个阶段的主要目标是获得领域模型（领域需求） 。识别信息源，即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。

领域设计

这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求DSSA。

补充：

DSSA通常包括以下组成部分：

领域模型：描述特定领域中的概念和关系。

参考需求：定义特定领域中的通用需求和约束。

参考架构：提供一个通用的架构模板，指导系统的设计和实现。

在领域设计阶段，开发者会基于领域模型和已识别的领域需求，设计出DSSA，确保它能够满足领域内广泛共享的需求，并具备足够的灵活性以适应特定系统的独特需求。这个过程中可能会涉及到架构风格的选择、组件和模块的设计、服务和接口的定义等。

领域实现

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

DSSA的过程

定义领域范围 ：领域中的应用要满足用户一系列的需求。
定义领域特定的元素 ：建立领域的字典，归纳领域中的术语，识别出领域中相同和不相同的元素。
定义领域特定的设计和实现需求的约束：识别领域中的所有约束，这些约束对领域的设计和实现会造成什么后果。
定义领域模型和架构：产生一般的架构，并描述其构件说明。
产生、搜集可复用的产品单元：为DSSA增加复用构件，使可用于新的系统。

DSSA的三层模型

领域开发环境 ：领域架构师决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具。
领域特定的应用开发环境 ：应用工程师根据具体环境来将核心架构实例化。
应用执行环境 ：操作员实现实例化后的架构。