二、软件体系结构建模

软件体系结构建模

软件体系结构建模的种类

根据建模的侧重点不同体系结构模型分5种：

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

研究结构模型的核心是体系结构描述语言。

2. 框架模型
   框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构

框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

3. 动态模型
   动态模型是对结构或框架模型的补充，研究系统的“大颗粒”的行为性质。例如，描述系统的重新配置或演化。

动态可以指系统总体结构的配置、建立或拆除通信通道或计算的过程。

4. 过程模型

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

5. 功能模型

功能模型认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。

功能模型可以看作是一种特殊的框架模型

“4+1"模型概述

Kruchten在1995年提出了“4+1”的视图模型。
它将上述5种模型有机地统一在一 起，形成一个
完整的模型。

“4+1”视图模型从5个不同的视角包括:逻辑
视图、进程视图、物理视图、开发视图和场景视
图来描述软件体系结构。如下页图所示:

每一个视图只关心系统的一个侧面，5个视
图结合在一起才能反映系统的软件体系结构的全
部内容。

逻辑视图

逻辑视图主要支持系统的功能需求，即系统提
供给最终用户的服务。

在逻辑视图中，系统分解成一系列的功能抽象 ，
这些抽象主要来自问题领域。这种分解不但可以用
来进行功能分析，而且可用作标识在整个系统的各
个不同部分的通用机制和设计元素。

在面向对象技术中，通过抽象、封装和继承，
可以用对象模型来代表逻辑视图，用类图来描述逻
辑视图。

开发视图

开发视图也称模块视图，主要侧重于软件模块的组织和管理。

开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。

开发视图通过系统输入输出关系的模型图和子系统图来描述。

常用符号：

在开发视图中，
最好采用4-6层子系统，
而且每个子系统仅仅能与同层或更低层的子系统通讯，这样可以使每个层次的接口既完备又精练，避免了各个模块之间很复杂的依赖关系。

设计时要充分考虑，对于各个层次，层次越低，通用性越强，这样，可以保证应用程序的需求发生改变时，所做的改动最小。开发视图所用的风格通常是层次结构风格。

进程视图

进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。例如:系统性能、可靠性等。

进程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。

进程视图可以描述成多层抽象，每个层分别关注不同的方面。在最高层抽象中，进程结构可以看作是构成一个 执行单元的一组任务。它可看成系列独立的， 通过逻辑网络相互通信的程序它们是分布的，通过总线或局域网、广域网等 硬件资源连接起来。

通过进程视图可以从进程测量一个目标系统的最终执行情况。
例如:基于网络的图书管理系统中，服务器需要对来自各个不同客户机的进程进行管理，决定某个特定进程的唤醒。启动、关闭等。

物理视图

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

场景视图

场景可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。在开发体系结构时，它可以帮助设计者找到体系结构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。
文本表示举例如下:

本地呼叫场景的文本表示如下:
(1)检测由挂机到摘机状态的转变，且发消息以唤醒终端对象;
(2)终端分配资源，通知控制器，发出拨号音;
(3)控制器接收所拨号码并传给终端;
(4)终端使用编号计划分析号码;
(5)当一个有效的拨号序列进入时，终端会打开一个会话。

软件体系结构的核心模型

1. 构件:是具有某种功能的可重用的软件模板单元。表示了系统中主要的计算元素和数据存储。构件分类:原子构件、复合构件
2. 连接件:是构件之间的交互。简单的连接件有:管道、过程调用、事件广播等;
   复杂的连接件有:客户/服务器通信协议、SQL连接等。
3. 配置:表示构件和连接件的拓扑逻辑和约束。
4. 端口:构件作为一个封装实体，只能通过接口与外部交互，接口由-组端口组成。端口可以是一个过程调用，也可以是一组过程调用。
5. 角色:连接件作为体系结构的主要实体，也有接口，它由一组角色组成。

软件体系结构的生命周期模型

软件开发过程：

1. 需求分析阶段:根据需求决定系统功能，调查、收集信息，得到(结果)是软件规格说明。
   体系结构的需求包括:需求获取→生成类图→对类分组→把类打包成构件→需求评审。
2. 建立体系结构阶段:从结构的角度对整个系统进行分析，选择恰当的构件、构件间相互关系及对它们的约束，最后得到一个系统框架。首先要选择一个合适的体系结构风格→将需求确认的构件映射到体系结构中，产生一个中间结构→对其进行细化。
3. 软件设计阶段:对系统进行模块化，并决定描述各个构件间的详细接口、算法和数据类型的选定。软件实现阶段:用编程语言实现。从构件库中查找符合接口约束的构件，或开发新的构件→通过组装工具将构件组装起来，完成系统的连接与合成。
4. 软件测试阶段:单个构件的功能测试;组装的整体功能和性能测试。

生命周期模型：

1. 体系结构的非形式化描述:将需求用自然语言描述。

2. 体系结构的规范描述和分析:对上面的描述进行规范定义并分析其性质。如无死锁性、安全性等。

3. 体系结构的求精及其验证:大型系统都是从抽象到具体逐步求精的。在每一步求精过程中需要对不同抽象层次的体系结构进行验证，以判断具体的体系结构与抽象的体系结构的语义是否一致。

4. 体系结构的实施:将求精后的体系结构实施与系统的设计中，并将构件和连接件有机的组织在起，形成系统设计框架。

5. 体系结构的演化和扩展:在实施过程中， 由于非功能性需求，如性能、容错、安全性、操作性和自适应性等影响软件体系统结构的扩展和改变，这称为演化。由于演化是因非功能性质的非形式化需求描述引起的，所以回到第1步。

6. 体系结构的提供、评价和度量:将体系结构实施于系统设计后，对系统实际运行情况进行评价和定量度量，以利于体系结构的重用和经验教训。

7. 体系结构的终结:经多次演化和修改，已变得难以理解，不能达到设计要求，说明已过时，应丢弃，用全新的取而代之。
   

软件体系结构的抽象模型

构件及其关系的抽象描述

在软件系统中，构件不是独立存在的，构件之间具有互操作性。这里把构件看成数据单元或计算单元，把构件之间的互操作抽象为代数运算，具体定义如下:
定义:构件是一个数据单元或一个计算单 元，它由构件的对象的集合、属性的集合、动作的集合和端口的集合组成。构件可抽象为: C=(0,A. X, P)。

其中:

0是组成构件的所有对象的集合;
A是构件属性的集合;
X是构件动作的集合;
P是构件端口的集合。

构件及其关系的抽象描述

定义：设C1、C2是软件系统S中的两个不同构件，若先执行构件C1的操作，再执行构件C2的操作，就称构件C1和C2之间的关系为顺序结构关系，简称为顺序结构或顺序运算，记作:C1|→C2
用图形表示如下图:

定义:设C1、 C2是软件系统$中的两个不同构件，若根据不同的条件选择性地执行C1或C2来完成某一功能，就称C1和C2之 间的关系为选择结构关系，简称为选择结构或选择运算，记作: C1▷C2
用图形表示如下图:

定义:设C1、C2是软件系统S中的两个不同构件，若在一定条件下重复执行构件C1和构件C2的功能，就称构件C1和C2之间的关系是循环结构关系，简称为循环结构或循环运算，记作: C1 <-> C2
用图形表示如右图: