C2-软件体系结构建模

1、,1,2020/7/9,体系结构描述方法,软件开发过程中各种角色之间交流设计思想的媒介 进行上层分析的基础。此基础上可以验证体系结构设计方案，精炼或改变必要的方案 让别人理解系统的第一手资料,2,2020/7/9,假定你是Module Designer,你最近加盟一家公司，并被安排在一个新项目的开发组中。虽然你富有经验，但是对此项目所涉及的领域还是一个新手。系统的高层体系结构设计已经完成。 你的老板（项目经理）让你预计你将要完成的几个模块的开发时间。 你怎么办？,3,2020/7/9,假定你是Module Designer,你来开发A2和A3，怎么开始？,4,2020/7/9,与Module

2、Designer交流,基本想法是什么？ 我该做什么 (如，实现哪些需求) ？ 我该在哪做 (如，这项功能实现在哪里) ？ 我和谁交互？接口是什么？ 有什么可以重用的代码？ 必须遵从什么约定(质量目标、旧体系/接口、预算等)？ 有哪些硬性规定(设计、接口、约束等)？,5,2020/7/9,与顾问交流,体系结构的必要需求(driving requirement)是什么(如，performance,reliability, availability, security, modifiability, interoperability)？ 各种体系结构视图是如何描述的？ 抽象出来什么？ 功能怎样分解？

3、 功能怎样分配？ 使用什么硬件以及软件怎样布置在硬件上？ 采用了哪些体系结构风格？,6,2020/7/9,这是什么？,7,2020/7/9,上图的毛病,很多事情没有说： 组件类型 连接件类型 圆圈和箭头代表什么？ 这种布局的意义是什么？ 为什么CP要放在上层？ 只画出方框和线条不是体系结构，只是体系结构的开始,8,2020/7/9,好的体系结构描述的必要元素(1),需求陈述 商业环境、产品的背景、领域 描述环境 必须和什么系统交互、外部接口 使用体系结构图 用恰当的线框 简洁的说明,9,2020/7/9,好的体系结构描述的必要元素(2),考虑实现时的限制 仅在它们能影响体系结构设计的范围内 被

4、限定的下层结构、处理器需求 通常包含其他结构图 体系结构设计的原理 它怎样去符合需求与约束 其他的设计,10,2020/7/9,其他方面,风格/产品线问题 设计可变的尺度 体系结构的那个方面必须不被改变？ 管理问题 暗含开发团队的组织结构 体系结构评审情况 其他设计问题 代码重用、标准的运用 风险分析 运作、管理和维护,11,2020/7/9,好描述,线和框有不同的形状/颜色，并有图例说明 用表格总结方案选择等等各种问题 图并不试图去表达很多信息：把信息分散到需要表达它的各个视图中 每个体系结构视图必须在一页内完成 清晰地区分出哪些是体系结构视图，哪些不是,12,2020/7/9,坏描述,所有

5、的线看起来都一样 箭头不代表任何涵义 箭头代表很多涵义 实现与文档冲突 没有图例 太多的必要需求,研究软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模。根据建模的侧重点不同，可以将软件体系结构的模型分为5种：,第2章 软件体系结构建模,2.1 软件体系结构建模概述, 结构模型 框架模型 动态模型 过程模型 功能模型,13,2020/7/9,14,2020/7/9, 软件体系结构建模的种类,第2章 软件体系结构建模,2.1 软件体系结构建模概述, 结构模型 这是一个最直观、最普遍的建模方法。这种方法以体系结构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要

6、语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质等。 研究结构模型的核心是体系结构描述语言。, 软件体系结构建模的种类,第2章 软件体系结构建模,2.1 软件体系结构建模概述, 框架模型 框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。 框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。,15,2020/7/9, 软件体系结构建模的种类,第2章 软件体系结构建模,2.1 软件体系结构建模概述, 动态模型 动态模型是对结构或框架模型的补充，研究系统的“大颗粒”的行为性质。例如，描述系统的重新配置或演化。动态可以指系统总体结构的配置、建立或拆除通信通

7、道或计算的过程。,16,2020/7/9, 软件体系结构建模的种类,第2章 软件体系结构建模,2.1 软件体系结构建模概述, 过程模型 过程模型研究构造系统的步骤和过程。 结构是遵循某些过程脚本的结果。,17,2020/7/9, 软件体系结构建模的种类,第2章 软件体系结构建模,2.1 软件体系结构建模概述, 功能模型 功能模型认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。 功能模型可以看作是一种特殊的框架模型。,18,2020/7/9, “4+1”模型概述,第2章 软件体系结构建模,2.2 “4+1”视图模型,以上五种模型各有所长，将五种模型有机的统一在一起，形成一个完整的模型

8、来刻画软件体系结构更加合适。,19,每个视图模型可看成对系统不同方面一个投影，一个构架的不同视图其实反映的是同一个系统。 各个不同的视图是可以融合在一起的，而且也只有将不同的视图融合在一起才能获得关于一个系统构架的全面信息。, “4+1”模型概述,第2章 软件体系结构建模,2.2 “4+1”视图模型,Rational公司的Philippe Kruchten在1995年提出了用于体系结构描述的“4十l”模型。该模型建立在体系结构的PerryWolf定义和Berry Boehm定义的基础上。 “4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。

9、每一个视图只关心系统的一个侧面，5个视图结合在一起才能够处理富于挑战性的、大规模的软件系统。,20,2020/7/9,21,2020/7/9,u逻辑视图 当采用面向对象的设计方法时，逻辑视图即是对象模型。 u进程视图 描述系统的并发和同步方面的设计。 u物理视图 描述软件到硬件之间的映射关系，反映系统在分布方面的设计。,22,u开发视图 描述软件在开发环境下的静态组织。 u场景视图 通过选择出地一些用例对体系结构加以说明。这些用例称作场景。 四个视图反映的是同一个系统，所以用了第五个视图，“+1”视图，它是由一系列重要的案例组成。用这些重要的案例将前面的四个视图联系 到一起，从而组成第五个视图

10、。,23,2020/7/9,对体系结构进行的描述是围绕着以上4个视图展开的。然后，通过选择出的一些用例对体系结构加以说明。这些用例被称作场景(scenarios)，它们构成了第5个视图。实际上，体系结构在某种程度上是由场景演化而来的。,24,体系结构的概念在每个视图里面都可以独立应用，即可以在每个视图里面定义体系结构的各种组成元素，如构件、连接件等。 对于不同的视图，还可以选择不同的体系结构风格，因此在同一个系统结构中可以使用多种风格。 在每一种视图里，我们使用该视图特定的符号。这避免了符号用法和意义的混乱。,25,2020/7/9,“4十1”模型实际上使得有不同需求的人员能够得到他们对于软件

11、体系结构想要了解的东西。 系统工程师先从物理视图，然后从进程视图靠近体系结构。最终使用者、客户、数据专家从逻辑视图看体系结构；项目经理、软件配置人员从开发视图看体系结构。,26,2020/7/9,不是所有的软件体系结构都需要完整的“4十1”视图。没有用的视图在体系结构描述中可以被省略。例如对于非常小的系统，逻辑视图和开发视图有可能非常相似以至于没有必要把它们分开描述。场景视图在各种环境下都是有用的。,27,2020/7/9,2.2 逻辑视图：面向对象的分解,逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不

12、但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。 在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。,28,2020/7/9,2.2.1 逻辑视图的符号表示法,可以从Booch标记法中导出逻辑视图的标记法，只是从体系结构级的范畴来考虑这些符号，用Rational Rose进行体系结构设计。,关联：表示两个类之间存在某种语义上的联系，真正含义由附加在横线上的短语说明。 包含：实心圆一端表示整体，另一端表示部分。 使用：空心圆一端连接在请求服务的类，另一端连接在提供服务的类。 继承：箭头由子类指向基类。,29,2020/

13、7/9,2.2.2 逻辑视图的风格,逻辑视图也可以采用面向对象的风格。 逻辑视图设计的主要准则是，要设法在整个系统中保持一个单一的、连贯的对象模型，避免类和相关机制出现按照场地或处理器过早的分化。,30,2020/7/9,2.2.3 逻辑视图的例子,左图显示了一个专用自动交换分机(ACS)的例子。专用自动交换分机用于在通信终端之间建立连接。 通信终端可能是电话机、中继线(连接到中心室的线路)、专用线(专用自动交换分机和一般的交换分机之间的线路)、数据线、ISDN线等。不同的线路需要不同的线路接口卡的支持。终端对象负责维护终端的状态，并代表所在的线路提供通信服务。 线路控制器对象负责从线路接口卡

14、接受信号，以及向它发送信号，并完成信号和一系列的事件(如开始、结束、计数等)之间的转换。控制器还必须受到严格的实时要求的约束。为了适应不同的接口，这个类有许多的子类。 会话对象代表在一个对话中涉及的终端的集合。会话对象使用转换服务(逻辑地址和物理地址之间的映射、路由等)和连接服务建立两个终端之间的语音连接。,31,2020/7/9,对于规模更大的系统来说，体系结构级中包含数十甚至数百个类 。左图是空中交通管制系统的顶级类图，该图包含了8个类种属（即类的分组）。,2.2.3 逻辑视图的例子,32,2020/7/9,2.3 进程视图：过程分解,进程视图（process view,也称过程视图）侧重

15、于系统的运行特性，主要考虑的是一些非功能性的需求，诸如性能、可用性等。 它所要面对的问题有并发，分布，系统的完整性，容错能力等。它还要考虑怎样把进程体系结构与逻辑视图体系结构的要点相适应对某个对象的某个操作实际上是在哪个控制线程上发生的。,33,2020/7/9,2.3 进程视图：过程分解,可以把进程体系结构分为几个抽象层次来描述，每个层次关注不同的方面。 在最高层次上，进程体系结构可以被视为是一个逻辑网络的集合。 每个独立执行的逻辑网络都是由通信程序(即“过程”)构成的。这些逻辑网络分布在一个通过局域网或广域网连接起来的硬件资源集合上。 多个逻辑网络可能同时存在，并共享同样的物理资源。,34

16、,2020/7/9,2.3 进程视图：过程分解,通过进程视图可以估计出消息流和过程负荷，也可以从过程测量一个目标系统最终执行情况。 例如在以计算机网络作为运行环境的图书管理系统中，服务器对来自各个不同的客户机的过程管理，决定某个特定过程（如查询子过程、借还书子过程）的唤醒、启动、关闭等操作，从而控制整个网络协调有序地工作。,2.3.1 进程视图的符号表示法,在辅助工具的选择上，可以考虑使用TRW提供的UNAS(Universal Network Architecture Services)产品。它可用于把各种过程和任务构建并实现为过程的逻辑网络。UNAS里面包含的一个工具SALE(Softwa

17、re Architecture Lifecycle Environment)支持这样的符号表示法。SALE允许进程体系结构的图形化描述，包括对可能的任务间通信路径的规格说明。然后，从这种规格说明可以自动生成相应的Ada或C十十语言源代码。,36,2020/7/9,2.3.2 进程视图的风格 有多种风格适合进程视图。例如管道和过滤器、客户服务器及其变体(多客户单服务器，多客户多服务器)等。2.3.3 进程视图的例子（ACS系统局部进程视图）,37,2020/7/9,（1）在图中，所有终端均由同一个终端进程进行处理，由其输入队列中的消息驱动。 （2）控制器对象在组成控制器进程的3个任务之一中执行。

18、,38,2020/7/9,（3）慢循环周期(200ms)任务扫描所有挂起的终端，把任何一个活动的终端置入快循环周期(10ms)任务的扫描列表。（4）快循环周期任务检测任何显著的状态改变，并把改变的状态传递给主控制器任务。,39,2020/7/9,（5）主控制器任务解释改变，通过消息与相应的终端进行通信。（6）通过共享内存来实现在控制器进程中传递的消息。,40,2020/7/9,2.4 开发视图：子系统分解,(1) 开发视图也称为模块视图，侧重的是在软件开发环境中软件模块的实际组织和管理。软件被打包成可以由单个或少量程序员开发的各种小的部分：程序库或子系统。子系统被组织成层次化的体系，每一层为上

19、一层提供一个严密的、明确定义的接口。,41,2020/7/9,2.4 开发视图：子系统分解,（2）开发视图通过系统输入输出关系的模型图和子系统图来描述。描述开发视图的原则是：分割、编组、可视。 （3）开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。,42,2020/7/9,2.4.1 开发视图的符号表示法,开发视图的符号表示法采用Booch表示法的变体，并且只考虑对于体系结构有重要意义的元素，如图所示。在Rationnal Rose中，可以绘制模块层和子系统层的开发视图，还可以在反向工程中从已经开发的源代码(Ada或C

20、十十)得出系统的开发视图。,43,2020/7/9,2.4.2 开发视图的风格,对于开发视图，最好采用分层风格，定义46层的子系统。每一层都有明确责任。设计规则是，某一层的子系统只能依赖于本层或其下层的子系统。这样可以使每个层次的接口既完备又精练，避免了各个模块之间很复杂的依赖关系，并使得系统可以采用逐层的策略完成释放。 设计时要充分考虑，对于各个层次，层次越低，通用性越强，这样，可以保证应用程序的需求发生改变时，所做的改动最小。,44,2020/7/9,2.4.3 开发视图的例子,下图用5个层次表示了航空交通管制系统产品线的开发组织。此开发视图24中描述的逻辑视图相对应的。,45,2020/

21、7/9,2.4.3 开发视图的例子,（1）第1层和第2层组成了一个领域无关的分布式基础结构，贯穿于整个产品线中。这两层独立于应用域，并将上层系统遮蔽起来，防止其受到与硬件平台、操作系统或数据库等变化的影响。,46,2020/7/9,2.4.3 开发视图的例子,（2）第3层增加了空中交通管制系统的框架，以形成一个用于特定应用领域的软件体系结构。 （3）第4层使用该框架构造了一个功能平台。,47,2020/7/9,2.4.3 开发视图的例子,（4）第5层则依赖于具体客户和产品，包含了大部分用户界面和与外部系统的接口。,48,2020/7/9,2.5 物理视图：从软件到硬件的映射,物理视图主要考虑如

22、何把软件映射到硬件上，它通常要考虑到系统的可用性、可靠性(容错性)、性能(信息吞吐量)和可扩展性。 解决系统拓扑结构、系统安装、通讯等问题。,49,2020/7/9,2.5 物理视图：从软件到硬件的映射,当软件运行于不同的节点上时，各视图中的构件（如网络、过程、任务和对象）都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。 大型系统的物理视图可能会变得十分混乱，因此可以与进程视图的映射一道，以多种形式出现，也可单独出现。,50,2020/7/9,2.5.1 物理视图的符号表示法,TRW公司的UNAS允许使用者采用数据驱动的方

23、式将进程体系结构映射到物理体系结构，并允许在不修改源代码的情况下对这种映射做出多种改动。,51,2020/7/9,ACS系统的物理视图,2.5.1 物理视图的符号表示法,上图显示了大型专用自动交换机（ACS）的一种可能的硬件配置。其中，C、F、K是3个不同容量的计算机类型，支持3个不同的可执行文件。,下面是进程视图的两个不同的物理映射，分别对应一个小型的ACS和大型的ACS。,具有进程分配的小型ACS系统的物理视图,具有进程分配的大型ACS系统的物理视图,53,2020/7/9,2.6 场景视图：汇总,通过使用一些重要场景，4个视图中的元素可以协调地共同工作。尽管这些场景是一个小集合，但是它们

24、很重要。场景(scenario)是更通用的概念用例(use case)的实例。从某种意义上讲，场景是最重要的需求的抽象。场景的设计使用对象场景图(object scenario diagram)和对象交互图来表示。 相对于其他的4个视图，这个视图是多余出来的(所以称为“4十l”)，但是它承担着两个目的： 在体系结构的设计中，将以此视图为驱动来发现体系结构元素。 在体系结构设计结束后，此视图承担验证和描述的角色。它不仅用于书面记录，并且是体系结构原型测试的起始点。,54,2020/7/9,2.6.1 场景视图的符号表示法,场景视图的符号表示法中，构件的表示与逻辑视图非常相似，但是连接件的表示使用

25、进程视图中的方法。注意，对象的实例用细实线表示。在工具的使用方面，和在逻辑视图类似，可以使用Rational Rose绘制和管理对象场景图。,55,2020/7/9,2.6.2 场景视图的例子, 小王的电话的控制器检测到并证实了从挂起到取下的状态转变，并且发送了消息来唤醒相关的终端对象。 终端分配一些资源，并告诉控制器发出拨号音。 控制器收到数字并将它们发送给终端。 终端使用号码规划来分析数字流。 当一个有效序列的输入完成，终端打开一个对话。,图 场景的雏形本地呼叫选择阶段,56,2020/7/9, 小结,逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。 对于不同

26、的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。,57,2020/7/9,2.6.3 视图间的交流 不同视图之间并不是互相独立或互相正交的。视图中的元素遵循一定的规则和经验法则与其他视图中的元素形成联系。 从逻辑视图（最终用户）到进程视图（系统集成人员） 逻辑视图中认为每个对象都是主动的、并发的。 定义进程体系结构时，将每个对象实现为独立的控制线程是不实际的（将导致巨大的开销） 另一方面，多控制线程也是需要的,在确定并发程度及过程数目时，必须以潜在的物理目标体系结构集

27、合为前提，可以参照以下两种策略。 自内向外：从逻辑视图开始的策略 自外向内：从物理体系结构开始的策略 结果：类及其对象到进程体系结构的任务和过程集合的映射 为达到可接受的设计结果，需要进行迭代,58,2020/7/9,2. 从逻辑视图（最终用户）到开发视图（编程人员） 一个类通常被实现为一个模块 较大的类被分解为多个包 一组相互联系紧密的类的集合，或称为类种属，构成子系统 定义子系统时，必须考虑附加约束 项目越大，逻辑视图和开发视图之间的距离越远 3. 从进程视图（系统集成人员）到物理视图（系统工程人员） 为了测试和部署，过程和过程组以各种配置映射到可用的物理硬件上。,59,2020/7/9,

28、模型的迭代过程和软件过程 1.迭代过程：场景驱动的方法 采用“4+1”模型进行软件体系结构设计的一种推荐方法是： 在完成原型、测试、度量、分析等步骤后，重新进入下一轮这样的步骤，构成迭代的过程 系统最关键的功能以场景的形式得到。关键是指，功能上最重要，或是用频度上最高，又或存在必须克服的技术风险。 初始的体系结构演化为最终的真实系统。在23次迭代后，体系结构本身有希望稳定下来。接下来就可以进行软件设计领域的工作了。,60,2020/7/9,2. 软件文档 体系结构设计阶段所形成的文档主要有： 软件体系结构文档：基本按照4+1视图组织 软件设计指导：描述为了维护系统的体系结构的一致性所必须遵守的

29、重要设计决定。,61,2020/7/9,2.3 体系结构的核心模型,62,2020/7/9,软件体系结构的核心模型由五种元素组成：构件、连接件、配置、端口和角色。其中构件、连接件、配置是最基本的元素。 构件是具有某种功能的可重用的软件模板单元，表示了系统中主要的计算元素和数据存储。复合构件由其他复合构件和原子构件通过连接而成。原子构件是不可再分的构件。构件只能通过其接口与外部环境交互，构件的接口由一组端口组成，每个端口表示了构件和外部环境的交互点。通过不同的端口类型，一个构件可以提供多重接口。 连接件表示了构件间的交互。连接件也有接口，其接口由一组角色组成，连接件的每一个角色定义了该连接件表示的交互的参与者，二元连接件有两个角色。 配置表示了构件和连接件的拓扑逻辑和约束。,需求分析,建立体系结构,测试,实现,设计,63,2020/7/9,2.4 体系结构的生命周期模型,软件开发过程,2.4 体系结构的生命周期模型,64,2020/7/9,SA的非形式化描述 一种SA在其产生时，其思想