C2-软件体系结构建模

软件体系结构

--第三章软件体系结构建模2内容概要3.1软件体系结构建模概述

3.2“4+1”视图模型3.3“4+1”视图模型案例分析3.4“4+1”视图模型补充知识3.5软件体系结构核心模型3.6软件体系结构生命周期模型研究软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模。根据建模的侧重点不同，可以将软件体系结构的模型分为5种：第3章软件体系结构建模3.1软件体系结构建模概述

◎结构模型◎框架模型◎动态模型◎过程模型◎功能模型32023/2/1

软件体系结构建模的种类

第3章软件体系结构建模3.1软件体系结构建模概述

◎结构模型

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

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

软件体系结构建模的种类

第3章软件体系结构建模3.1软件体系结构建模概述

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

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

软件体系结构建模的种类

第3章软件体系结构建模3.1软件体系结构建模概述

◎动态模型

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

软件体系结构建模的种类

第3章软件体系结构建模3.1软件体系结构建模概述

◎过程模型过程模型研究构造系统的步骤和过程。结构是遵循某些过程脚本的结果。72023/2/1

软件体系结构建模的种类

第3章软件体系结构建模3.1软件体系结构建模概述

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

功能模型可以看作是一种特殊的框架模型。82023/2/1

“4+1”模型概述

第3章软件体系结构建模3.2“4+1”视图模型以上五种模型各有所长，将五种模型有机的统一在一起，形成一个完整的模型来刻画软件体系结构更加合适。9

WHY：1、每个视图模型可看成对系统不同方面一个投影，一个构架的不同视图其实反映的是同一个系统。

2、各个不同的视图是可以融合在一起的，而且也只有将不同的视图融合在一起才能获得关于一个系统构架的全面信息。

“4+1”视图模型概述

第3章软件体系结构建模3.2“4+1”视图模型Rational公司的PhilippeKruchten在1995年提出了用于体系结构描述的“4十l”视图模型。该模型建立在体系结构的Perry＆Wolf定义和BerryBoehm定义的基础上。102023/2/1

逻辑视图进程视图开发视图物理视图最终用户：功能需求场景编程人员：软件管理系统集成人员：性能可扩充性、吞吐量等系统工程人员：系统拓扑、安装、通信等11*

软件架构视图Kruchten在其著作《Rational统一过程引论》中写道：一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。

软件架构的每个视图分别关注不同的方面，针对不同的目标和用途。第3章软件体系结构建模3.2“4+1”视图模型12*

关于视图气候学家关心的社会学家关心的引入视图的作用：世界地图的绘制者很难将不同的信息都绘制到同一幅图中；而看地图的人也希望有一幅地图是专门针对他的需要的。

同一事物的不同视图之间是有联系的。对比上面两幅图，除了南美洲之外基本都是降水量足的地方人口较密集。“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能够处理富于挑战性的、大规模的软件系统。“4+1”视图模型的不同视图之间也存在相互影响。

132023/2/1逻辑视图进程视图开发视图物理视图最终用户：功能需求场景编程人员：软件管理系统集成人员：性能可扩充性、吞吐量等系统工程人员：系统拓扑、安装、通信等

142023/2/1u逻辑视图

当采用面向对象的设计方法时，逻辑视图即是对象模型。u进程视图

描述系统的并发和同步方面的设计。u物理视图

描述软件到硬件之间的映射关系，反映系统在分布方面的设计。逻辑视图进程视图开发视图物理视图最终用户：功能需求场景编程人员：软件管理系统集成人员：性能可扩充性、吞吐量等系统工程人员：系统拓扑、安装、通信等

15u开发视图

描述软件在开发环境下的静态组织。u场景视图通过选择出一些用例对体系结构加以说明。这些用例称作场景。

“4+1”的由来：四个视图反映的是同一个系统，之所以用了第五个视图，“+1”视图，因为它是由一系列重要的案例组成。用这些重要的案例将前面的四个视图联系到一起，从而组成第五个视图。逻辑视图进程视图开发视图物理视图最终用户：功能需求场景编程人员：软件管理系统集成人员：性能可扩充性、吞吐量等系统工程人员：系统拓扑、安装、通信等

162023/2/1对体系结构进行的描述是围绕着以上4个视图展开的。然后，通过选择出的一些用例对体系结构加以说明。这些用例被称作场景(scenarios)，它们构成了第5个视图。实际上，体系结构在某种程度上是由场景演化而来的。

逻辑视图进程视图开发视图物理视图最终用户：功能需求场景编程人员：软件管理系统集成人员：性能可扩充性、吞吐量等系统工程人员：系统拓扑、安装、通信等

17“４+１”视图模型的特征一：体系结构的概念在每个视图里面都可以独立应用，即可以在每个视图里面定义体系结构的各种组成元素，如构件、连接件等。对于不同的视图，还可以选择不同的体系结构风格，因此在同一个系统结构中可以使用多种风格。在每一种视图里，我们使用该视图特定的符号。这避免了符号用法和意义的混乱。

逻辑视图进程视图开发视图物理视图最终用户：功能需求场景编程人员：软件管理系统集成人员：性能可扩充性、吞吐量等系统工程人员：系统拓扑、安装、通信等

18“４+１”视图模型的特征二：“4十1”模型实际上使得有不同需求的人员能够得到他们对于软件体系结构想要了解的东西。系统工程师先从物理视图，然后从进程视图靠近体系结构。最终使用者、客户、数据专家从逻辑视图看体系结构；项目经理、软件配置人员从开发视图看体系结构。

逻辑视图进程视图开发视图物理视图最终用户：功能需求场景编程人员：软件管理系统集成人员：性能可扩充性、吞吐量等系统工程人员：系统拓扑、安装、通信等

19“４+１”视图模型的特征三：不是所有的软件体系结构都需要完整的“4十1”视图。没有用的视图在体系结构描述中可以被省略。例如对于非常小的系统，逻辑视图和开发视图有可能非常相似以至于没有必要把它们分开描述。场景视图在各种环境下都是有用的。

逻辑视图进程视图开发视图物理视图最终用户：功能需求场景编程人员：软件管理系统集成人员：性能可扩充性、吞吐量等系统工程人员：系统拓扑、安装、通信等2023/2/13.2.1逻辑视图：面向对象的分解

逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。

202023/2/13.2.1逻辑视图的符号表示法可以从Booch标记法中导出逻辑视图的标记法，只是从体系结构级的范畴来考虑这些符号，用RationalRose进行体系结构设计。

212023/2/1关联：表示两个类之间存在某种语义上的联系，真正含义由附加在横线上的短语说明。包含：实心圆一端表示整体，另一端表示部分。使用：空心圆一端连接在请求服务的类，另一端连接在提供服务的类。继承：箭头由子类指向基类。3.2.1逻辑视图的风格逻辑视图可以采用面向对象的风格。逻辑视图设计的主要准则是，要设法在整个系统中保持一个单一的、连贯的对象模型。

222023/2/1

232023/2/13.2.1逻辑视图的例子

左图显示了一个专用自动交换分机(ACS)的例子。专用自动交换分机用于在通信终端之间建立连接。通信终端可能是电话机、中继线(连接到中心室的线路)、专用线(专用自动交换分机和一般的交换分机之间的线路)、数据线、ISDN线等。不同的线路需要不同的线路接口卡的支持。终端对象负责维护终端的状态，并代表所在的线路提供通信服务。线路控制器对象负责译码：从线路接口卡接受信号，以及向它发送信号，并完成信号和一系列的事件(如开始、结束、计数等)之间的转换。控制器还必须受到严格的实时要求的约束。为了适应不同的接口，这个类有许多的子类。会话对象代表在一个对话中涉及的终端的集合。会话对象使用转换服务(逻辑地址和物理地址之间的映射、路由等)和连接服务建立两个终端之间的语音连接。242023/2/1

对于规模更大的系统来说，体系结构级中包含数十甚至数百个类。左图是空中交通管制系统的顶级类图，该图包含了8个类种属（即类的分组）。3.2.1逻辑视图的例子

3.2.2进程视图：过程分解

进程视图（processview,也称过程视图）侧重于系统的运行特性，主要考虑的是一些非功能性的需求，诸如性能、可用性等。它所要面对的问题有并发，分布，系统的完整性，容错能力等。它还要考虑怎样把进程体系结构与逻辑视图体系结构的要点相适应——对某个对象的某个操作实际上是在哪个控制线程上发生的。

252023/2/13.2.2进程视图：过程分解

可以把进程体系结构分为几个抽象层次来描述，每个层次关注不同的方面。在最高层次上，进程体系结构可以看做是构成一个执行单元的一组任务通过进程视图可以估计出消息流和过程负荷，也可以从过程测量一个目标系统最终执行情况。

262023/2/13.2.2进程视图的符号表示法

通过扩展Booch对Ada任务的表示法，来表示进程视图。3.2.2进程视图的风格

有多种风格适合进程视图。例如管道和过滤器、客户／服务器及其变体(多客户／单服务器，多客户／多服务器)等。

3.2.2进程视图的例子（ACS系统局部进程视图）

282023/2/1（1）在图中，所有终端均由同一个终端进程进行处理，由其输入队列中的消息驱动。

（3）控制器对象在组成控制器进程的3个任务之一中执行。

292023/2/1（3）慢循环周期(200ms)任务扫描所有挂起的终端，把任何一个活动的终端置入快循环周期(10ms)任务的扫描列表。

（4）快循环周期任务检测任何显著的状态改变，并把改变的状态传递给主控制器任务。

302023/2/1（5）主控制器任务解释改变，通过消息与相应的终端进行通信。

（6）通过共享内存来实现在控制器进程中传递的消息。

312023/2/13.2.3开发视图：子系统分解

(1)开发视图也称为模块视图，侧重的是在软件开发环境中软件模块的实际组织和管理。软件被打包成可以由单个或少量程序员开发的各种小的部分：程序库或子系统。子系统被组织成层次化的体系结构，每一层为上一层提供一个严密的、明确定义的接口。

322023/2/13.2.3开发视图：子系统分解

（3）描述开发视图的原则是：分割、编组、可视。（3）开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。

332023/2/13.2.3开发视图的符号表示法开发视图的符号表示法采用Booch表示法的变体，并且只考虑对于体系结构有重要意义的元素，如图所示。在RationnalRose中，可以绘制模块层和子系统层的开发视图，还可以在反向工程中从已经开发的源代码(Ada或C十十)得出系统的开发视图。

342023/2/13.2.3开发视图的风格

对于开发视图，最好采用分层风格，定义4—6层的子系统。每一层都有明确责任。设计规则是，某一层的子系统只能依赖于本层或其下层的子系统。这样可以使每个层次的接口既完备又精练，避免了各个模块之间很复杂的依赖关系，并使得系统可以采用逐层的策略完成释放。设计时要充分考虑，对于各个层次，层次越低，通用性越强，这样，可以保证应用程序的需求发生改变时，所做的改动最小。

352023/2/13.2.3开发视图的例子

下图用5个层次表示了航空交通管制系统产品线的开发组织。此开发视图3－4中描述的逻辑视图相对应的。

362023/2/13.2.3开发视图的例子（1）第1层和第２层组成了一个领域无关的分布式基础结构，贯穿于整个产品线中。这两层独立于应用域，并将上层系统遮蔽起来，防止其受到与硬件平台、操作系统或数据库等变化的影响。

372023/2/13.2.3开发视图的例子（3）第3层增加了空中交通管制系统的框架，以形成一个用于特定应用领域的软件体系结构。

（3）第4层使用该框架构造了一个功能平台。

382023/2/13.2.3开发视图的例子（4）第5层则依赖于具体客户和产品，包含了大部分用户界面和与外部系统的接口。

392023/2/13.2.4物理视图：从软件到硬件的映射

物理视图主要考虑如何把软件映射到硬件上，它通常要考虑到系统的非功能性的需求。如：可用性、可靠性(容错性)、性能(信息吞吐量)、规模和可扩展性。解决系统拓扑结构、系统安装、通讯等问题。

402023/2/13.2.4物理视图：从软件到硬件的映射

当软件运行于不同的处理节点上时，各视图中的构件（如网络、过程、任务和对象）都直接或间接地对应于系统的不同节点（需要被映射至不同的节点）；我们希望使用不同的物理配置：一些用于开发和测试，另外一些则用于不同地点和不同客户的部署。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。

大型系统的物理视图可能会变得十分混乱，因此可以与进程视图的映射一起，以多种形式出现，也可单独出现。

412023/2/13.2.4物理视图的符号表示法

TRW公司的UNAS（通用网络结构服务技术）允许使用者采用数据驱动的方式将进程体系结构映射到物理体系结构，并允许在不修改源代码的情况下对这种映射做出多种改动。

422023/2/1432023/2/1

ACS系统的物理视图3.2.4物理视图的符号表示法

上图显示了大型专用自动交换机（ACS）的一种可能的硬件配置。其中，C、F、K是3个不同容量的计算机类型，支持3个不同的可执行文件。下面是进程视图的两个不同的物理映射，分别对应一个小型的ACS和大型的ACS。具有进程分配的小型ACS系统的物理视图具有进程分配的大型ACS系统的物理视图3.2.5场景视图：汇总

通过使用一些重要场景，4个视图中的元素可以协调地共同工作。尽管这些场景是一个小集合，但是它们很重要。场景(scenario)是更通用的概念——用例(usecase)的实例。从某种意义上讲，场景是最重要的需求的抽象。相对于其他的4个视图，这个视图承担着两个目的：●在体系结构的设计中，将以此视图为驱动来发现体系结构的构件和它们之间的作用。●在体系结构设计结束后，此视图承担验证和描述的角色。它不仅用于书面记录，并且是体系结构原型测试的起始点。

452023/2/13.2.5场景视图的符号表示法

场景可以用文本表示，也可以用符号表示。场景视图的符号表示法中，构件的表示与逻辑视图非常相似，但是连接件的表示使用进程视图中的方法。注意，对象的实例用细实线表示。在工具的使用方面，和逻辑视图类似，可以使用RationalRose绘制和管理对象场景图。

462023/2/1

472023/2/13.2.5场景视图的例子①小王的电话的控制器检测到并证实了从挂起到取下的状态转变，并且发送了消息来唤醒相关的终端对象。②终端分配一定的资源，并告诉控制器发出拨号音。③控制器收到数字并将它们发送给终端。④终端使用编号计划来分析号码。⑤当一个有效序列的输入完成，终端打开一个对话。图场景的雏形—本地呼叫选择阶段482023/2/1

小结

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

案例分析：NAS—网络终端通讯服务系统

第3章软件体系结构建模3.3“4+1”视图模型案例分析

492023/2/1

需求描述：NAS可运行于网络中任一台终端上，可为终端用户之间提供短信通信服务；NAS在传输信息之前要求先进行加密处理，然后再以密文的形式发送；NAS接收到传输的密文后，要求再以明文方式显示给终端用户；

逻辑视图——线框图表示法第3章软件体系结构建模3.3“4+1”视图模型案例分析

502023/2/1

逻辑视图——ＵＭＬ表示法第3章软件体系结构建模3.3“4+1”视图模型案例分析

512023/2/1

逻辑视图——UML表示的NAS系统逻辑图第3章软件体系结构建模3.3“4+1”视图模型案例分析

522023/2/1

逻辑视图——UML表示的NASNetService构件的逻辑视图第3章软件体系结构建模3.3“4+1”视图模型案例分析

532023/2/1

开发视图——UML表示法第3章软件体系结构建模3.3“4+1”视图模型案例分析

542023/2/1

开发视图——UML表示法第3章软件体系结构建模3.3“4+1”视图模型案例分析

552023/2/1

进程视图——UML表示法第3章软件体系结构建模3.3“4+1”视图模型案例分析

562023/2/1

物理视图——UML表示法第3章软件体系结构建模3.3“4+1”视图模型案例分析

572023/2/1

3.6.3视图间的交流不同视图之间并不是互相独立或互相正交的。视图中的元素遵循一定的规则和经验法则与其他视图中的元素形成联系。从逻辑视图（最终用户）到进程视图（系统集成人员）逻辑视图中认为每个对象都是主动的、并发的。定义进程体系结构时，将每个对象实现为独立的控制线程是不实际的（将导致巨大的开销）另一方面，多控制线程也是需要的

582023/2/1在确定并发程度及过程数目时，必须以潜在的物理目标体系结构集合为前提，可以参照以下两种策略。自内向外：从逻辑视图开始的策略自外向内：从物理体系结构开始的策略结果：类及其对象到进程体系结构的任务和过程集合的映射为达到可接受的设计结果，需要进行迭代

592023/2/13.从逻辑视图（最终用户）到开发视图（编程人员）一个类通常被实现为一个模块较大的类被分解为多个包一组相互联系紧密的类的集合，或称为类种属，构成子系统定义子系统时，必须考虑附加约束项目越大，逻辑视图和开发视图之间的距离越远3.从进程视图（系统集成人员）到物理视图（系统工程人员）为了测试和部署，过程和过程组以各种配置映射到可用的物理硬件上。

602023/2/1模型的迭代过程和软件过程1.迭代过程：场景驱动的方法采用“4+1”模型进行软件体系结构设计的一种推荐方法是：在完成原型、测试、度量、分析等步骤后，重新进入下一轮这样的步骤，构成迭代的过程系统最关键的功能以场景的形式得到。关键是指，功能上最重要，或是用频度上最高，又或存在必须克服的技术风险。初始的体系结构演化为最终的真实系统。在3～3次迭代后，体系结构本身有希望稳定下来。接下来就可以进行软件设计领域的工作了。

612023/2/13.软件文档体系结构设计阶段所形成的文档主要有：软件体系结构文档：基本按照4+1视图组织软件设计指导：描述为了维护系统的体系结构的一致性所必须遵守的重要设计决定。

622023/2/163

综合软件体系结构的概念，体系结构的核心模型由5中元素组成：

构件连接件配置端口角色其中，构件、连接件和配置是最基本的元素。3.3体系结构的核心模型软件体系结构配置连接件构件端口角色1:N1:N1:N原子构件复合构件：表示软件之间的交互表示构件和连接件的拓扑结构和约束：表示构件和外部环境的交互点：：定义了该连接件表示的交互的参与者3.3体系结构的核心模型3.3体系结构的核心模型652023/2/1

软件体系结构的核心模型由五种元素组成：构件、连接件、配置、端口和角色。其中构件、连接件、配置是最基本的元素。构件是具有某种功能的可重用的软件模板单元，表示了系统中主要的计算元素和数据存储。复合构件由其他复合构件和原子构件通过连接而成。原子构件是不可再分的构件。构件只能通过其接口与外部环境交互，构件的接口由一组端口组成，每个端口表示了构件和外部环境的交互点。通过不同的端口类型，一个构件可以提供多重接口。连接件表示了构件间的交互。连接件也有接口，其接口由一组角色组成，连接件的每一个角色定义了该连接件表示的交互的参与者，二元连接件有两个角色。配置表示了构件和连接件的拓扑逻辑和约束。需求分析建立体系结构测试实现设计662023/2/1

3.4体系结构的生命周期模型软件开发过程3.4体系结构的生命周期模型672