常见软件系统模式.docVIP

软件常见系统模式 常见系统模式 层次体系结构模式 管道与过滤器模式 映像模式 Mvc体系结构模式 Pac体系结构模式 系统模式分析 层次体系结构 层次体系结构模式 机理：将系统分割为多个抽象的层次，例如Tcp/Ip网络 工作流程：每一层为上层提供服务，并作为下层的客户端。 风格：一般内部的层只对相邻层可见，层之间的连接器通过如何交互的协议决定 优点 支持基于抽象程度递增的系统设计：使设计者可以把一个复杂系统按递增的步骤进行分解 支持功能增强：因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层。 支持复用：只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样就可以定义一组标准的接口，而允许各种不同的实现方法。 可替换性。 缺点 更改行为的重迭：当对低层的修改由于某种原因影响了高层的时候，对低层的局部修改必须在多个层次上进行 降低了效率：上层到下层之间需要进行参数传递/转换等 不必要的工作：有事低层执行的动作并不全是高层需要的。那么这些多余动作将造成效率的降低。 难以认可层次的正确性粒度 管道与过滤器 管道与过滤器模式 机理：每个组件都有一组输入和输出，组件读数据流，经过内部处理然后产生输出数据流 工作流程：通过对输入流的变换及增量计算来完成，在输入被完全消费之前，输出便产生了——过滤器，这种风格的连接器——数据流传输的管道。将一个过滤器的输出传到另一过滤器的输入。 注意：特别重要的过滤器必须是独立的实体，它不能与其它过滤器共享数据，而且一个过滤器不知道它的上游和下游的标识。 特点：输出的正确性不依赖于过滤器增量计算过程的顺序。例如编译器 优点 不再需要中间文件，但是可以使用中间文件 通过过滤器增加了灵活性。过滤器组件的重用 流水线的快速原型 并行处理提高效率 缺点 共享状态信息或者昂贵，或者不灵活 并行处理获得的效率是一种假象 数据转换额外开销 错误处理 映像模式 映像模式 适用：动态改变软件系统的结构和行为提供机制。 机理：将一个应用程序分成两个部分：元层次，基本层次 元层次：提供所选系统属性的相关信息并使软件包含自述信息 包括了应用程序的逻辑 优点 可以不直接修改源代码而对软件的行为进行修改 可以更容易地更改软件 支持更多种类的修改 缺点 元层次修改时，可能会带来故障 增加了组件的数目 效率较低 并非所有现在的改变都会得到支持 并非所有的语言都支持这个模式 MVC体系结构模式 MVC体系结构 机理：强制性的使应用程序的输入、处理和输出分开。 核心部件:：模型（M）、视图（V）、控制器（V） 优点 同一模型的多个视图 同步化视图 可插入的视图和控制器 式样和感觉的可交换性 框架潜力，可以开发这个模式的应用程序框架 控制器和视图之间的联系非常紧密 缺点 增加了复杂性 潜在的过多的更新因素 视图和控制器与模型的紧密耦合 视图中数据访问的低效率 移植时对视图和控制器的修改是不可避免的 借用现代的用户接口工具使用MVC的困难性 PAC体系结构模式 PAC体系结构 机理：以合作agent的层次形式定义了交互软件系统的一种结构。每个agent负责应用程序功能的某一特定方面，并且由表示、抽象和控制三个组件构成。 特点：细分将agent的人机交互与其功能内核和它与其他agent的通信分隔开来。 优点 事务分离，不同的语义概念用独立的agent分别表示，每个agent提供它自己的人机交互，允许作为应用程序的每一个语义概念或任务独立于其他语义概念或者任务的数据模型或者用户接口。 支持变化和扩展 支持多任务 缺点 增加了系统的复杂性 复杂的控制组件，控制组件负责抽象组件和表示组件之间的通信媒介，也负责不同的agent之间的通信。控制组件的复杂任务使它的设计变得困难 Agent之间的见解通信使得系统的效率降低 可应用性，应用程序的原子语义概念越小，那么他们用户接口的相似性越多，模式的可应用性就越差