演示文档-软件体系结构-第二章-软件体系结构风格-应用实例

• Key Word In Context:上下文关键字
• 上下文关键字索引系统 :
• 接收多个字符行line组成的有序序列 • 每个行包含一系列的词组word word • 每个词包含一系列的字母character
• 输入的每一行被“循环移位”(circular shifting)并复 制输出:
• 将每行的第一词从行首去掉 • 将它连接到行末
• 不用另外的存贮位置
• “字母排序”模块: 从Text array（原字符行首字符）和 Word index（移位后首字符）中读取数据, 创建一个按 7 字母排序的索引（一系列下标）
这一设计方案的效果
• 算法上的改变（灵活性）:
• 可以轻微改变，因为数据结构已经限制了算法上可能的改变 • “你确定了数据结构，我就可以知道你的算法” – Fred Brooks的名言
• 是否很方便地进行改变，使系统实现交互性？
• 中等, 需要对“字母排序”部件单独进行修改
• 性能:
• 空间: 很好, 数据可以通过接口调用进行共享 • 时间: 很差，不可能实现并发
• 重用：
• 中等, 依赖于接口的定义
11
数据流风格
目标: 达到重用性（reuse）和可修改性（modifiability） Data-flow（数据库风格）
• 使用分层：
• 可以从更宏观、更全面的角度来进行系统全局的分 析和设计
17
10
这一设计方案的效果
• 算法上的改变:
• 容易实现, 数据访问是通过定义好的接口进行（可以不改变接口的情况下，改 变内部算法的实现） • 例如: “按字母排序” Alphabetizer部件可以实现这样的功能 如果我们在操作 过程中中断了KWIC的功能，可以在后面根据要求再次启动
• 在数据结构上的改变:
体系结构风格
• 一个体系结构风格包括:
• 一套 部件类型(component types) (例如,进程,处理过程) 它们在运行时完成特定的功能 • 一个显示部件间运行时关系拓扑结构 • 一套语义约束 (semantic constraints),例如,是什么是 • 一套连接(connectors) (例如,数据流,socket等) :它们是部 件之间通信的中介
• 输出是每个输入行及它们的各个循环移位的结果(按 字母顺序排列)
3
KWIC系统输入输出举例 系统输入输出举例
输入: bar sock car dog town fog 输出:
bar sock car dog dog car fog town sock bar town fog 四个步骤: Input Circular shift Alphabetize Output
• 数据结构上的改变（灵活性） :
• 很差, 因为部件间的接口已经定下了,就难以改变
• 附加属性的实现可能（可扩展性）: • 是否很方便地进行改变，以实现对一些在行首的虚词,不进 行循环移位?
• 很好, 在系统中很容易增加新的过滤器
• 是否很方便地进行改变，使系统实现交互性？
• 很差, 没有状态记录, 无关实现诸如删除某些输入、中止后重新启动处理等 交互功能
• 中等, 需要对“字母排序”部件单独进行修改
• 性能:
• 空间: 性能很好, 因为数据是共享的 • 时间: 性能很差, 因为这种体系结构下无法进行并发（必须等所有输入在 “Input”部件都完成后，才可以进行后面的处理，如“循环移位”部件）
• 重用:
• 很差, 因为这个系统中每个部件都依赖我们所设计的特定数据结构
6
注意这里箭头 的含义（实线 、虚线）
• “输入”模块:读取字符行，并存放在 Text array（一个 一维字符数组）中, 并将每一行在Text array中的起始位 置（一个下标）作为原字符行索引记录下来 • “循环移位”模块: 对每一行，记录每个词的起始位置（ 一个下标）, 并将其作为移位后字符行的索引记录到 Word index中（一系列下标）
• 容易实现, 数据隐藏在接口的后面 • 例如: Line storage部件可以把数据存放在磁盘上，而不仅是内存中，这对其它 模块一点影响都没有
• 附加属性的实现可能（可扩展性）: 这方面跟前一方案是一样的 • 是否很方便地进行改变，以实现对一些在行首的虚词,不进行循环移位 ?
• 中等, 需要对现有的部件进行修改
• 在连续的部件间进行数据的增量式传送/处理( 有一点数据就可以传送\处理)
• 过滤器转换数据时,不怎么考虑上下文,也不保存处 理状态 • 管理是无状态的(stateless),功能是在过滤器间转换 流数据(stream data) • 例如: 最典型的是数据加密系统、视频压缩/解压系 统(无状态,不考虑上下文)
Batch Sequential（批 处理序列） • 部件是独立程序 • 只有前一个部件完成了工作， 后一个才能开始工作 • 各个步骤间传递的数据是一个 整体（不可能只传送一部分） 经典的数据处理
12
Pipes and Filters管道－过滤器
管道－过滤器 管道－过滤器Pipe-Filter子风格 子风格
• 而对其它风格的部件，没有这种约束
9
• 对象：
• Line storage对象: 它的外部可见操作是读取或写入指 定位置的字符、词和行
• Circular shifter对象: 成员函数SHIFT(l,w,c)返回在 第l个移位中第w个词的第c个字符 • Alphabetizer对象: 成员函数iTH(i)在一个已按字 母顺序排列好的序列中返回第i行
• 用另外的内存进行存放 • 不另外存放(只保存循环移位所需的数据,例如每个词的)
• 附加特性:
• 是否对一些在行首的虚词,不进行循环移位? (例如“a”, “an”, “and”, 等). • 使系统变成一个交互式系统
• 例如: 允许删除某些输入,: 各个部件应该设计成一个多么独立的功能模块?
5
使用调用返回风格(Call-Return) 使用调用返回风格
• 目标: 使系统达到可修改modifiability 和可扩展scalability • 子风格:
• 主程序-子程序
• 程序的层次分解,每个子程序从其父部件获得控制权限
• 面向对象
• 下面是第一个体系结构设计方案：主 程序－子程序风格＋共享数据方案
• 一个最常见的例子：分层面向对象（例如J2EE）
• 用分层风格来划分系统的层次 • 每一层内部，用面向对象来进行分析和设计 • 避免超大规模软件系统在分析和设计时形成“对象的海洋 ”
• 不使用分层：
• 可能造成分析、设计的复杂度导致分析、设计的错 误：同一时刻，只能考虑少数几个类，容易造成设 计时考虑不全面
• 体系结构风格提供了一套我们可以借鉴来 进行体系结构设计的框架
From Chapter 5, Software Architecture in Practice, p. 94
1
体系结构风格分类
Today Today
Next Time
2
体系结构设计案例: 体系结构设计案例 KWIC系统 系统
• KWIC
循环移位位置(??): 1 5 10 14 18 23 Alphabetize: 1 10 14 23 5 18
4
设计考虑
• 算法上的可能选项:我们可以执行“行移位”…
• 在每一行被读入后立即进行本行的移位 • 在所有行都被读入后才进行各行的移位 • 当执行“字母排序”的部件要求提供新的移位行时
• 数据表示上的可能选项:循环移位数据可以…
8
抽象数据类型/面向对象子风格方案 抽象数据类型 面向对象子风格方案
• 面向对象风格的系统可以较易达到可修改 性,因为对环境(其它对象)而言,对象内部秘 密被封装了起来
• 这样,修改一个对象的内部特征(属性、私有/保 护方法)，不会影响其它类的代码
• 对对象的访问只能通过类方法 (一种受约束 的过程调用)
• 数据结构上的改变（灵活性） :
• 不可能, 因为Text Array等数据存储部件的结构已经对其它处理部件完全 可见
• 附加属性的实现可能（可扩展性）: • 是否很方便地进行改变，以实现对一些在行首的虚词,不进行循环 移位?
• 中等, 需要对现有的部件进行修改
• 是否很方便地进行改变，使系统实现交互性？
14
基于管道-过滤器风格的 基于管道 过滤器风格的KWIC方案 过滤器风格的 方案
• 每个部件(过滤器)创建实现的文本,并传到下一个 部件
• 输入串序列;移位后的序列;按字母排序后的序列;输出
• 设计简单,易于理解
15
这一设计方案的效果
• 算法上的改变（灵活性）:
• 很好, 因为部件间不需要有共享数据
• 过滤器之间没有共享数据，只通过管道传数据
• 管道的源端连接到过滤器的输出端口; 目的端连接到 过滤器的输入端口
13
管道－过滤器 管道－过滤器Pipe-Filter子风格 子风格
• 管道－过滤器系统不断地运行,直到再没有 数据要处理或传输
• 例如, 在Unix系统中遇到了EOF标志
+ 优点:简单,容易推理, 易于维护(易于修改和 升级), 易于重用(接入其它管道-过滤器系统 ), 易于通过并发和分布式处理来提高性能 - 缺点: 难于实现交互式系统, 过滤器难以集 合在一起去解决一个共同问题
• 性能:
• 空间: 很差，数据不共享，必须在各个过滤器之间不断复制 • 时间:
• 有可能好, 部件可以并发 • 有可能差, 复制数据需要大量时间
• 重用:
• 很好，唯一的限制是过滤器与管道间的接口 16
在体系结构设计中使用异种风格
• 异种：heterogeneity • 即在体系结构设计中使用了两种或以上的体系 结构风格