研究软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模。根据建模的侧重点不同，可以将软件体系结构的模型分为五种：结构模型、框架模型、动态模型、过程模 型和功能模型。

在这五个模型中，最常用的是结构模型和动态模型。

（1）结构模型。这是一个最直观、最普遍的建模方法。这种方法以体系结构的构件、连接件 （connector）和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配 置、约束、隐含的假设条件、风格、性质等。研究结构模型的核心是体系结构描述语言。

（2）框架模型。框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结 构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

（3）动态模型。动态模型是对结构或框架模型的补充，研究系统的“大颗粒”的行为性质。例 如，描述系统的重新配置或演化。动态可以指系统总体结构的配置、建立或拆除通信通道或计算的 过程。这类系统常是激励型的。

（4）过程模型。过程模型研究构造系统的步骤和过程，因而结构是遵循某些过程脚本的结果。

（5）功能模型。功能模型认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。 它可以看作是一种特殊的框架模型。

“4+1”视图模型 软件体系结构的五种模型各有所长，将五种模型有机地统一在一起，形成一个完整的模型来刻 画软件体系结构更合适。例如，Kruchten在1995年提出了一个“4+1”的视图模型。“4+1”视图 模型从五个不同的视角（逻辑视图、进程视图、物理视图、开发视图和场景视图）来描述软件体系 结构。每一个视图只关心系统的一个侧面，五个视图结合在一起才能反映系统的软件体系结构的全 部内容。“4+1”视图模型如下图所示。

逻辑视图

逻辑视图（logic view）主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能 分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中，通 过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图（class diagram）来描述逻辑视 图。可以从Booch标记法中导出逻辑视图的标记法，只是从体系结构级的范畴来考虑这些符号，用 Rational Rose进行体系结构设计。下图是逻辑视图中使用的符号集合。

类图用于表示类的存在以及类与类之间的相互关系，是从系统构成的角度来描述正在开发的系统。一个类的存在不是孤立的，类与类之间以不同方式互相合作，共同完成某些系统功能。关联关 系表示两个类之间存在着某种语义上的联系，其真正含义要由附加在横线之上的一个短语来予以说 明。在表示包含关系的图符中，带有实心圆的一端表示整体，相反的一端表示部分。在表示使用关 系的图符中，带有空心圆的一端连接在请求服务的类，相反的一端连接在提供服务的类。在表示继 承关系的图符中，箭头由子类指向基类。

逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问题是要保持一个单 一的、内聚的对象模型贯穿整个系统。例如，下图是某通信系统体系结构（ACS）中的主要类。

ACS的功能是在终端之间建立连接，这种终端可以是电话机、主干线、专用线路、特殊电话线、数据线或ISDN线路等，不同线路由不同的线路接口卡进行支持。线路控制器对象的作用是译码 并把所有符号加入到线路接口卡中。终端对象的作用是保持终端的状态，代表本条线路的利益参与 协商服务。会话对象代表一组参与会话的终端，使用转换服务（目录、逻辑地址映射到物理地址， 路由等）和连接服务在终端之间建立语音路径。

对于规模更大的系统来说，体系结构级中包含数十甚至数百个类，例如，图2-4是一个空中交通 管制系统的顶级类图，该图包含了8组类。

开发视图

开发视图（development view）也称模块视图（module view），主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织，这样，对于一个软件系统，就可以由不同的人进 行开发。开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要 充分考虑由于具体开发工具的不同而带来的局限性。

开发视图通过系统输入输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元 素之后描述完整的开发角度，也可以在确定每个元素之前，列出开发视图原则。

与逻辑视图一样，可以使用Booch标记法中某些符号来表示开发视图，下图所示。

在开发视图中，最好采用4-6层子系统，而且每个子系统仅仅能与同层或更低层的子系统通讯，这样可以使每个层次的接口既完备又精练，避免了各个模块之间很复杂的依赖关系。而且，设计时 要充分考虑，对于各个层次，层次越低，通用性越强，这样，可以保证应用程序的需求发生改变 时，所做的改动最小。开发视图所用的风格通常是层次结构风格。例如，下图表示的是空中交通管 制系统的五层结构图。 

第1层和第2层组成了一个领域无关的分布式基础设施，贯穿于整个产品线中，并且与硬件平台、操作系统或数据库管理系统等无关。第3层增加了空中交通管制系统的 框架，以形成一个领域特定的软件体系结构。第4层使用该框架建立一个功能平台，第5层则依赖于 具体客户和产品，包含了大部分用户接口以及与外部系统的接口。

进程视图

进程视图（process view）也称为并发视图，侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力，以及 从逻辑视图中的主要抽象如何适合进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个 线程（thread）中被执行的。

进程视图可以描述成多层抽象，每个级别分别关注不同的方面。在最高层抽象中，进程结构可 以看作是构成一个执行单元的一组任务。它可看成一系列独立的，通过逻辑网络相互通信的程序。 它们是分布的，通过总线或局域网、广域网等硬件资源连接起来。通过进程视图可以从进程测量一 个目标系统最终执行情况。例如在以计算机网络作为运行环境的图书管理系统中，服务器需对来自各个不同的客户机的进程管理，决定某个特定进程（如查询子进程、借还书子进程）的唤醒、启动、关闭等操作，从而控制整个网络协调有序地工作。

通过扩展Booch对Ada任务的表示法，来表示进程视图，从体系结构角度来看，进程视图的标 记元素如下图所示。

有很多风格适用于进程视图，如管道和过滤器风格、客户/服务器风格（多客户/单服务器，多客户/多服务器）等。下图是ACS系统的局部进程视图。

在图中，所有终端均由同一个终端进程进行处理，由其输入队列中的消息驱动。控制器对象在组成控制器进程的三个任务之一中执行，慢循环周期（200ms）任务扫描所有挂起（suspend） 终端，把任何一个活动的终端置入快循环周期（10ms）任务的扫描列表，快循环周期任务检测任何 显著的状态改变，并把改变的状态传递给主控制器任务，主控制器任务解释改变，通过消息与相应 的终端进行通讯。在这里，通过共享内存来实现在控制器进程中传递的消息。

物理视图

物理视图（physical view）主要考虑如何把软件映射到硬件上，它通常要考虑到系统性能、规模、可靠性等。解决系统拓扑结构、系统安装、通讯等问题。当软件运行于不同的节点上时，各视 图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活 性，当环境改变时，对系统其他视图的影响最小。

大型系统的物理视图可能会变得十分混乱，因此可以与进程视图的映射一道，以多种形式出现，也可单独出现。下图是物理视图的标记元素集合。

下图是一个大型ACS系统的可能硬件配置，图2-11和图2-12是进程视图的两个不同的物理视图映射，分别对应一个小型的ACS和大型的ACS，C、F和K是三个不同容量的计算机类型，支持三个 不同的可执行文件。

具有进程分配的小型ACS系统的物理视图

具有进程分配的大型ACS系统的物理视图

场景

场景（scenarios）可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种

意义上说场景是最重要的需求抽象。在开发体系结构时，它可以帮助设计师找到体系结构的构件和 它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何 相互作用的。场景可以用文本表示，也可以用图形表示。例如，图2-13是一个小型ACS系统的场景 片段，相应的文本表示如下：

（1）小王的电话控制器检测和验证电话从挂机到摘机状态的转变，且发送一个消息以唤醒相应 的终端对象。

（2）终端分配一定的资源，且通知控制器发出某种拨号音。

（3）控制器接收所拨号码并传给终端。

（4）终端使用编号计划分析号码。

（5）当一个有效的拨号序列进入时，终端打开一个会话。

本地呼叫场景的一个原型

从以上分析可知，逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说， 比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视 图和物理视图来描述系统。