第2章软件体系结构风格1-经典风格概览.pptVIP

分层系统的特征 按层次结构组织软件系统，每一层为上层服务，并作为下层客户，内部的层只对相邻的层可见 交互只在相邻的层间发生，同时，这些交互按照一定的协议进行，连接件可以用层次间的交互协议来定义 这种风格允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件重用提供了强大的支持 * 分层系统的实例 * 分层系统的优点 支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解 支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层 支持重用，只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法 * 分层系统的缺点 并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来 不必要的工作：如果低层执行的某些服务执行了多余或重复的工作，而这些工作并非是高层需要的，那么这对性能的影响是负面的 * 基于事件的隐式调用 构件不直接调用一个过程，而是触发或广播一个或多个事件。其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册了的所有过程，这样，一个事件的触发就导致与其相关联的所有过程的隐式调用 这种风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样，不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式 * 基于事件的隐式调用实例 * IDE中的调试系统 当调试器在断点处停下后，它会发布一个事件，驱动已注册到该事件上的过程的自动执行，如：编辑器滚动到相应的代码行，变量监视器显示最新的变量值等 思考：哪些类型的事件会采用隐式调用的方式处理？ 基于事件的隐式调用的优点 为软件重用提供了强大的支持：将一个构件加入现存系统中时，只需将它注册到系统的事件中；用一个构件代替另一个构件时，不会影响到其它构件的接口 构件放弃了对系统计算的控制。一个构件触发一个事件时不能确定其它构件是否会响应它。而且，即使它知道事件被哪些构件中的过程所注册，它也不能保证这些过程被调用的顺序 数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题 * 黑板风格 在黑板风格中，有两种不同的构件： 黑板数据结构，代表系统当前状态； 知识源，是独立构件，只通过黑板进行交互； 控制器，完全由黑板的状态驱动，一旦黑板的状态使某个知识源可用，知识源就会适时响应 * 黑板风格 知识源的调用是通过黑板的状态激活的，因此，实际的控制器或者实现在知识源中，或者实现在黑板系统中，或者两者兼之 黑板风格类似于这样一种情形：有一群类似老师的人会在黑板上记录下自己的想法或者对某件事情的看法，老师同时可以对黑板上的不正确的东西进行改进，从而不断更新黑板上的东西 * 黑板风格的优缺点 便于多客户共享大量数据，他们不用关心数据时何时出现的、由谁怎样提供的 既便于添加新的作为知识源的应用程序，又便于扩展共享的黑板数据结构 可重用的知识源 需要同步锁机制保证黑板数据结构的完整一致性 测试困难、低效、开发成本高 * MVC 框架 模型 - 视图 - 控制器 (model-view-controller) 强调将用户输入、数据处理、数据表示方式分开设计，一个交互式应用系统由模型、视图和控制器等3个部件组成，分别对应于内部数据处理部分、数据表示部分、输入/输出控制部分 * 基于Java的Web程序 * MVC 示意图 * MVC框架 之 模型 封装了核心功能和数据 业务逻辑（软件的核心） 数据以及访问它们的函数（视图组件使用） 执行特定应用程序处理的过程（控制器代表用户调用） 模型对于用户来说是不可见的(M与C独立) 模型独立于特定输出表示或者输入方式(M与V独立) 用户只能通过控制器操作模型(C是M与V之间的桥梁) * MVC框架 之 视图 向用户显示信息 不同的视图使用不同的方法呈现信息 每个视图组件都有一个更新函数，这个函数被模型变更通知激活，使得视图重新和模型一致 在初始化阶段，视图向模型登记请求变更通知 从模型获得数据 通过状态查询函数实现 例如：定时刷新 * MVC框架 之 控制器 每个视图有一个相关的控制器组件(一一对应) 控制器组件接受事件，并翻译成输入 事件如何发送到控制器由用户界面平台决定 事件被翻译成为对模型或者视图的请求 如果控制器的行为依赖于模型的状态，那么控制