第2章 软件体系结构风格1 - 经典风格

24
分层系统
用户系统 基本工具 核心层 过程调用
各种构件
25
分层系统的特征

按层次结构组织软件系统，每一层为上层服务，并作为下 层客户，内部的层只对相邻的层可见 交互只在相邻的层间发生，同时，这些交互按照一定的协 议进行，连接件可以用层次间的交互协议来定义 这种风格允许将一个复杂问题分解成一个增量步骤序列的 实现。由于每一层最多只影响两层，同时只要给相邻层提 供相同的接口，允许每层用不同的方法实现，同样为软件 重用提供了强大的支持


数据交换的问题。有时数据可被一个事件传递，但另一些 情况下，基于事件的系统必须依靠一个共享的仓库进行交 互。在这些情况下，全局性能和资源管理便成了问题
32
黑板风格
计算 直接存取 知识源

知识源
黑板 （共享数据）
知识源

知识源
内存
在黑板风格中，有两 种不同的构件： 黑板数据结构，代表系 统当前状态； 知识源，是独立构件， 只通过黑板进行交互； 控制器，完全由黑板的 状态驱动，一旦黑板的 状态使某个知识源可用 ，知识源就会适时响应



支持并行执行，每个过滤器是作为一个单独的任务完成， 因此可与其它任务并行执行
21
管道和过滤器的缺点

导致过滤器的处理过程包含只能批量执行的若干操作。这 是因为，过滤器是独立的，设计者必须将每个过滤器看成 一个完整的输入到输出的转换，而不能将其中的操作分解 不适合处理交互的应用，当需要增量地显示改变时，这个 问题尤为严重 因为在数据传输上没有通用的标准，每个过滤器都增加了 解析和合成数据的工作，这样就导致了系统性能下降，并 增加了编写过滤器的复杂性
43
使用体系结构风格的好处

促进设计复用：体系结构风格在设计中得到复用 可以提高开发效率 促进代码复用：体系结构风格中的不变部分使得 部分实现代码可以共享 促进系统理解：如果采用惯例的结构，可以使相 关人员容易理解软件的组织结构，例如说明一个 系统是采用C/S风格的，不必给出设计细节，人 们就会明白系统是如何组织和工作的
13
常用的体系结构风格

数据抽象和面向对象的组织结构 事件驱动和隐式调用 分层系统（OSI七层协议） C/S, B/S ……
14
软件体系结构风格的四要素

一个体系结构风格定义一个词汇表和一组约束：
◦ 词汇表中包含一些构件（如客户机、服务器、层、数据库等）和 连接件（如过程调用、事件消息、协议等）类型 ◦ 这组约束指出系统是如何将这些构件和连接件组合起来的
34
黑板风格的优缺点
便于多客户共享大量数据，他们不用关心数据时
何时出现的、由谁怎样提供的
既便于添加新的作为知识源的应用程序，又便于
扩展共享的黑板数据结构
可重用的知识源
需要同步锁机制保证黑板数据结构的完整一致性
测试困难、低效、开发成本高
35
MVC 框架

模型 - 视图 - 控制器 (model-view-controller) 强调将用户输入、数据处理、数据表示方式分开 设计，一个交互式应用系统由模型、视图和控制

管道和过滤器实例
19
管道-过滤器的特性

过滤器是独立运行的构件
◦ 过滤器之间不共享状态 ◦ 过滤器自身无状态

过滤器对其处理上下连接的过滤器“无知”
◦ 仅需要对输入管道的输入数据流进行限制，并保证输出 管道的输出数据流有适合的内容，对相邻过滤器的实现 细节不施加任何限制

最终输出的正确性不依赖于过滤器运行的次序

此外，一个体系结构风格还包括：
◦ 一套语义解释规则，说明构件和连接件的组装是具有良定义的实
际意义的； ◦ 对基于这种风格的软件系统所进行的分析方法
15
讨论体系结构风格时要回答的问题

构件和连接件的类型是什么？

可容许的结构模式（包括构件、连接件、约束）
是什么？

风格的基本不变性是什么？
器等3个部件组成，分别对应于内部数据处理部
分、数据表示部分、输入/输出控制部分
36
基于Java的Web程序
37
MVC 示意图
38
MVC框架 之 模型

封装了核心功能和数据
◦ 业务逻辑（软件的核心）
◦ 数据以及访问它们的函数（视图组件使用）
◦ 执行特定应用程序处理的过程（控制器代表用户调用）

33
黑板风格

知识源的调用是通过黑板的状态激活的，因此， 实际的控制器或者实现在知识源中，或者实现在 黑板系统中，或者两者兼之 黑板风格类似于这样一种情形：有一群类似老师 的人会在黑板上记录下自己的想法或者对某件事 情的看法，老师同时可以对黑板上的不正确的东 西进行改进，从而不断更新黑板上的东西


是若干设计思想的综合

has known properties that permit reuse
具有已经被熟知的特性，并且可以复用

ths same to Software Architecture
12
软件体系结构风格的产生

软件体系结构设计的一个核心问题是： ◦ = 能否使用重复的体系结构模式

在很多工程领域，基于模式和设计风格的开发方法是非常
普遍的，一个设计良好的通用模式是一个工程领域技术成
熟的标志之一
2
从建筑风格说起 – 雅典
3
从建筑风格说起 – 罗马
4
从建筑风格说起 – 哥本哈根
5
从建筑风格说起 – 巴黎
6
卢浮宫的三件宝
7
从建筑风格说起 – 香港
8
从建筑风格说起 – 韩国
其使用的常见例子是什么？ 使用此风格的优缺点是什么？ 是否存在使用多种风格的软件系统？
16
经典的软件体系结构风格
1. 管道和过滤器
2. 数据抽象和面向对象组织 3. 分层系统 4. 基于事件的隐式调用 5. 黑板风格 6. MVC框架
17
管道和过滤器
管道
过滤器

每个构件（称为过滤器）都有一组输入和输出，构件从输 入源读入数据流，并在输出池产生输出数据流，构件对输 入流进行内部转换和增量计算，因此在输入数据流被全部 处理之前，输出就已经开始了 这种风格的连接件就象是数据流传输的管道，将一个过滤 器的输出传到另一过滤器的输入 18
中登记了对变更通知的需求 ◦ 模型状态的改变将触发变更-通知机制，每个在表中登 记的视图和控制器都会收到变更通知
42
讨论体系结构风格时要回答的问题

构件和连接件的类型是什么？

可容许的结构模式（包括构件、连接件、约束）
是什么？

风格的基本不变性是什么？
其使用的常见例子是什么？ 使用此风格的优缺点是什么？ 是否存在使用多种风格的软件系统？


28
分层系统的缺点

并不是每个系统都可以很容易地划分为分层的模 式，甚至即使一个系统的逻辑结构是层次化的， 出于对系统性能的考虑，系统设计师不得不把一 些低级或高级的功能综合起来

不必要的工作：如果低层执行的某些服务执行了 多余或重复的工作，而这些工作并非是高层需要 的，那么这对性能的影响是负面的
◦ 各过滤器在输入具备后完成自己的计算，完整的计算过 程包含在过滤器之间的拓扑结构中
管道和过滤器的优点

使得软构件具有高内聚、低耦合、易理解的特点，允许设 计者将整个系统的输入/输出行为看成是多个过滤器的行 为的简单合成 支持构件重用，只要提供适合在两个过滤器之间传送的数 据，任何两个过滤器都可被连接起来 系统维护和增强系统性能简单，新的过滤器可以添加到现 有系统中来；旧的可以被改进的过滤器替换掉 允许对一些如吞吐量、死锁等属性的分析
29
基于事件的隐式调用

构件不直接调用一个过程，而是触发或广播一个或多个事 件。其他构件中的过程在一个或多个事件中注册，当一个 事件被触发，系统自动调用在这个事件中注册了的所有过 程，这样，一个事件的触发就导致与其相关联的所有过程 的隐式调用 这种风格的主要特点是事件的触发者并不知道哪些构件会 被这些事件影响。这样，不能假定构件的处理顺序，甚至 不知道哪些过程会被调用，因此，许多隐式调用的系统也 包含显式调用作为构件交互的补充形式
26


分层系统的实例
27
分层系统的优点

支持基于抽象程度递增的系统设计，使设计者可 以把一个复杂系统按递增的步骤进行分解 支持功能增强，因为每一层至多和相邻的上下层 交互，因此功能的改变最多影响相邻的上下层 支持重用，只要提供的服务接口定义不变，同一 层的不同实现可以交换使用。这样，就可以定义 一组标准的接口，而允许各种不同的实现方法
模型对于用户来说是不可见的(M与C独立)
模型独立于特定输出表示或者输入方式(M与V独立) 用户只能通过控制器操作模型(C是M与V之间的桥梁)
39
MVC框架 之 视图

向用户显示信息
◦ 不同的视图使用不同的方法呈现信息 ◦ 每个视图组件都有一个更新函数，这个函数被模型变更 通知激活，使得视图重新和模型一致 ◦ 在初始化阶段，视图向模型登记请求变更通知

用户仅仅通过控制器与系统交互
41
MVC框架 之 变更通知机制

一个模型可对应多个视图（维护数据的一致性）
◦ 如果用户通过一个视图的控制器改变了模型中的数据，
那么依赖于该数据的其他视图也应该反映出这样的变化 ◦ 一旦模型的数据发生了变化，模型需要通知所有相关的 视图做出相应的变化

工作原理
◦ 模型维护了一个表，所有视图还有一些控制器在这个表
9
从建筑风格说起 – 土耳其
10
从建筑风格说起 – 美国
11
建筑风格（Style）具备如下特点

describes a class of architectures
描述了一类建筑的总体结构 在实践中被多次设计、应用

is found repeatedly in practice is a package of design decisions
44


实验作业：MVC风格综合实践
30

基于事件的隐式调用实例


IDE中的调试系统
当调试器在断点处停下后，它会发布一个事件，驱动已注 册到该事件上的过程的自动执行，如：编辑器滚动到相应 的代码行，变量监视器显示最新的变量值等

思考：哪些类型的事件会采用隐式调用的方式处理？
31
基于事件的隐式调用的优点

为软件重用提供了强大的支持：将一个构件加入现存系统 中时，只需将它注册到系统的事件中；用一个构件代替另 一个构件时，不会影响到其它构件的接口 构件放弃了对系统计算的控制。一个构件触发一个事件时 不能确定其它构件是否会响应它。而且，即使它知道事件 被哪些构件中的过程所注册，它也不能保证这些过程被调 用的顺序
22


数据抽象和面向对象组织结构
对象 对象

这种风格的构件是对
象，或者说是抽象数 据类型的实例。对象
对象
抽象数 据类型
是一种被称作管理者 的构件，因为它负责 保持资源的完整性。 对象是通过函数和过 程的调用来交互的
23
对象
对象
过程调用
数据抽象和面向对象的优缺点

因为一个对象对其它对象隐藏了它的具体实现，所以可以 改变一个对象的实现，而不影响其它的对象 继承、封装、多态 为了使一个对象和另一个对象通过过程调用等进行交互， 必须知道对象的标识。只要一个对象的标识改变了，就必 须修改所有其他明确调用它的对象Leabharlann Baidu必须修改所有显式调用它的其它对象，并消除由此带来的 一些副作用。例如，如果A使用了对象B，C也使用了对 象B，那么，C对B的使用所造成的对A的影响可能是料想 不到的

从模型获得数据
◦ 通过状态查询函数实现 ◦ 例如：定时刷新
40
MVC框架 之 控制器

每个视图有一个相关的控制器组件(一一对应) 控制器组件接受事件，并翻译成输入
◦ 事件如何发送到控制器由用户界面平台决定
◦ 事件被翻译成为对模型或者视图的请求 ◦ 如果控制器的行为依赖于模型的状态，那么控制器也需 要向模型登记请求变更通知
◦ = 能否达到体系结构级的软件重用
◦ = 能否在不同的软件系统中使用同一个体系结构

软件体系结构风格是描述某一特定应用领域中，系统组织 方式的惯用模式 (idiomatic paradigm)，反映了该领域 中众多系统所共有的结构和语义特性，并指导如何将各个 模块或子系统有效的组织成一个完整的系统
第三章 软件体系结构风格

3.1 经典的软件体系结构风格 3.2 C/S、B/S类架构
3.3 分布式对象技术
3.4 其他软件体系结构风格
1
为什么形成了不同的风格

风格是带有倾向性的模式。针对同一个问题，可以有不同 的解决方案或模式，但我们根据经验和问题特征，通常会
强烈倾向于采用特定的模式，这就是风格