第12章-体系结构案例研究课件

案例研究谢兄信息科学技术学院[e-mail]Parnas1972年的论文中提出下述问题上下文关键字KWIC（KeyWordinContext）检索系统接受有序的行集合；每一行是单词的有序集合；每一个单词又是字母的有序集合。通过重复地删除行中第一个单词并把它插入到行尾，每一行可以被“循环地移动”。KWIC检索系统以字母表的顺序输出一个所有行循环移动的列表。Parnas描述了两种解决方案：上下文关键字基于功能分解，可以共享访问数据表示；基于隐藏设计决策的分解。Parnas认为的变更包括：上下文关键字处理算法的变更：比如，输入设备可以每读入一行就执行一次行移动，也可以读完所有行再执行行移动，或者在需要以字母表的顺序排列行集合时才执行行移动；数据表示的变更：比如，行、单词和字母可以用各种各样的方式储存。类似的，移动循环情况也可以被显示地或者隐式地储存（使用索引和偏移量）。Garlan、Karser、Notkin考虑：上下文关键字系统功能的扩充：比如，修改系统使其能够排除以某些干扰单词（如a、an等）开头的循环移动，把系统变成交互式的，允许用户从初始列表中（或者从循环移动的列表中）删除某些行；性能：空间和时间。重用：作为可重用的实体，构件重用的程度。解决方案1：使用共享数据的主程序/子程序上下文关键字根据四个基本功能将问题分解为：输入、移动、按字母表排序、输出。所有计算构件作为子程序协同工作，并且由一个主程序顺序地调用这些子程序。构件通过共享存储区（“核心存储区”）交换数据。因为协同工作的子程序能够保证共享数据的顺序访问，因此使计算构件和共享数据之间基于一个不受约束的读写协议的通信成为可能。解决方案1：使用共享数据的主程序/子程序上下文关键字子程序调用直接内存存取系统输入/输出主控制输入循环移动按字母表排序输出字符索引按字母表索引输入媒介输出媒介KWIC:共享数据解决方案解决方案1：使用共享数据的主程序/子程序上下文关键字这种方案具有很高的数据访问效率，因为计算共享同一个存储区。不同的计算功能被划分到不同的模块中。解决方案1：使用共享数据的主程序/子程序上下文关键字在处理变更的能力上有许多严重的缺陷。数据存储格式的变化会影响到所有模块。整体处理算法的变更和系统功能扩充的问题也很难调和。这种分解方案不支持重用解决方案2：抽象数据类型上下文关键字将系统分解成五个模块。在这种情况下数据不再直接地被计算构件共享。每个模块提供一个接口，该接口允许其他构件通过调用接口中的过程来访问数据。解决方案2：抽象数据类型上下文关键字每个构件提供了一个过程集合，这些过程决定了系统中其他构件访问该构件的形式（p36页图3。2）解决方案2：抽象数据类型上下文关键字将系统在逻辑上分成几个处理模块，在设计变更时，比第一种具有一些优势。在一个独立的模块中算法和数据表示的改变不会影响其他模块。模块几乎不需要考虑与其交互的其他模块的情况，为重用提供了更好的支持。解决方案2：抽象数据类型上下文关键字不能很好地适合于功能扩展的情况向系统中加入一个新的功能时，实现者要么平衡其简明性和完整性而修改现存模块，要么添加新的模块而导致性能下降。解决方案3：隐式调用上下文关键字采用基于共享数据的构件集成的方式。（p37页图3.3）解决方案3：隐式调用上下文关键字与第一种方案相比：数据访问接口更加抽象，可以抽象地访问数据（比如作为表或集合），而不需要知道数据的存储格式。当数据被修改时，计算被隐式地调用，因而交互是基于“动态数据”模型的。例如，向行存储区添加一个新行的动作会激发一个事件，这个事件被发送到移动模块。移动模块然后进行循环移动（在一个独立的、抽象的共享数据存储区），这又会引起字母表排序程序被隐式地调用，字母表排序程序再对行进行排序。解决方案3：隐式调用上下文关键字这种解决方案很容易支持系统功能的扩展：通过注册，添加的模块很容易和系统整合，当发生数据交换事件时，这些添加的模块就会被调用。因为数据被抽象地访问，所以这种解决方案也将计算和数据表示分开。由于被隐式调用的模块仅仅依赖于某些外部的触发事件，所以这种方案也支持重用。解决方案3：隐式调用上下文关键字难以控制隐式调用模块的处理顺序由于隐式调用是数据驱动的，这种分解策略实现起来会比之前的方案占用更大的空间。解决方案4：管道过滤器上下文关键字采用管道的方式。有四个过滤器：输入、移动、按字母表排序、输出。每个过滤器处理完数据并把它发送到下一个过滤器。控制是分布式的：只要有数据通过，过滤器就会进行处理。过滤器间的数据共享严格地局限于管道中传输的数据。解决方案4：管道过滤器上下文关键字（p38页图3.4）解决方案4：管道过滤器上下文关键字它能够维持处理的自然流动。它支持重用，因为每个过滤器可以独立处理（只要上游过滤器产生的数据格式是过滤器所期望的格式）。通过在处理序列中的合适位置插入过滤器，新的功能很容易加入到系统中。既然每个过滤器和其它过滤器在逻辑上是独立的，那么每个过滤器也很容易替换或修改。解决方案4：管道过滤器上下文关键字不可能通过修改使其支持交互，如，删除一行可能需要一些持久性共享存储区，但这样就违反了这种方案的基本原则。空间使用的效率非常低，因为每个过滤器必须复制所有的数据到它的输出端口。各种方案的比较上下文关键字P39页图Tektronix公司的一个软件体系结构的工业发展仪器软件这项工程历时三年，是由Tektronix公司的几个产品部门和计算机研究实验室合作展开的。目的是为示波器开发一种可重用的系统体系结构。示波器是一个仪器系统，能对电信号取样，并在屏幕上显示电信号的图像（即踪迹）。示波器通常对信号进行测量，并将它们显示在屏幕上。Tektronix公司的一个软件体系结构的工业发展仪器软件现代示波器主要依靠数字技术并使用非常复杂的软件。现代示波器能够完成大量的测量，提供兆字节的内存，支持工作站网络和其它仪器的接口，并能提供完善的用户界面，包括带有菜单的触摸屏、内置的帮助工具和彩色显示。Tektronix公司面临的问题仪器软件几乎没有在不同示波器上可重用的软件组织结构。不同的示波器由不同的产品部门生产，每个部门都有自己的开发约定、软件组织结构、编程语言和开发工具，甚至在同一个部门内，每一个新的示波器通常也不得不重新设计来适应硬件性能的变化和用户界面的新需求。而硬件和界面需求变化速度越来越快也加剧了这种情况。开发“特殊的市场”的需要意味着必须为特殊的用户量身定做多种用途的仪器，比如病人监护或汽车诊断。Tektronix公司面临的问题仪器软件性能问题越来越严重，因为软件在仪器中不能被快速配置。由于根据用户的任务需要，示波器需要在不同的模式下配置。以前的示波器只需要简单地载入处理新模式的软件就能重新配置，软件的规模越来越大，导致了在用户的请求和仪器重新配置之间出现延迟。工程的目标仪器软件为示波器开发一种解决上述问题的体系结构框架，工程的结果是产生了一个特定领域的软件体系结构，这种体系结构将是下一代Tektronix示波器的基础。这个框架被扩展和修改来适应更广泛的系统种类，同时也是为了适应仪器软件的特殊需要。面向对象模型仪器软件开发一个可重用体系结构的最初尝试是开发一种面向对象的软件模型，这个模型阐明了在示波器中使用的对象类型：波形、信号、测量值、触发模型等。示波器对象波形最大-最小波形X-Y波形叠加波形面向对象模型仪器软件虽然是一个有益的实践，但是由于没有产生出期望的结果而失败了。尽管很多对象类型被确定，但是没有一个整体模型解释怎样结合这些对象类型，这将会导致功能划分的混乱。比如，量度是否应该与被测量的或者被外部表示的数据类型相关联？用户界面应该和哪些对象交互？分层模型仪器软件第二阶段尝试：分层模型硬件数字化波形处理可视化用户接口核心层提供信号处理功能，当信号进入示波器时使用这些功能过滤信号。这些功能通常通过硬件实现。分层模型仪器软件第二阶段尝试：分层模型硬件数字化波形处理可视化用户接口第二层提供波形采集功能。在这层中信号被数字化，并且被内部保存用于以后的处理。分层模型仪器软件第二阶段尝试：分层模型硬件数字化波形处理可视化用户接口第三层提供波形处理功能，包括测量、波形叠加、傅里叶转换等。分层模型仪器软件第二阶段尝试：分层模型硬件数字化波形处理可视化用户接口第四层提供显示功能，即负责将数字化的波形和测量值直观表示出来。分层模型仪器软件第二阶段尝试：分层模型硬件数字化波形处理可视化用户接口最外层是用户界面，这一层负责和用户进行交互，并决定在屏幕上显示哪些数据。分层模型仪器软件分层模型将示波器的功能分成一些明确定义的组，所以它具有显而易见的吸引力。对于应用领域，这种模型是错误的，主要的问题是层次间强加的抽象边界和各功能间交互的需要是相互冲突的。比如，这种模型提出所有用户与示波器交互必须通过显示层。但是，在实践中，真正的示波器用户需要直接和各层打交道，比如在信号处理层中设置衰减，在采集层中选择采集模式和参数，或者在波形处理层中制作导出波形。管道过滤器模型仪器软件第三种尝试产生的模型中，示波器功能被看成是数据的增量转换器。信号转换器用来检测外部信号。采集转换器用来从这些信号中导出数字化波形。显示转换器再将这些波形转换成可显示的数据。耦合采集To-XY裁剪触发子系统测量信号时间波形迹测量值管道过滤器模型仪器软件没有在功能划分中将各个功能孤立起来。比如，信号数据可以直接流入显示过滤器，而不会被其他过滤器干扰。从工程师角度看，模型将信号处理作为数据流问题是比较合适的；模型也允许在系统设计中硬件和软件构件的灵活混合和替换。没有清晰的说明用户怎样与其交互改进后的管道过滤器模型仪器软件解决了用户输入问题，即为每个过滤器添加一个控制界面，这个界面允许外部实体为过滤器设置操作参数。比如，采集过滤器具有某些参数用来确定采样频率和波幅。这些输入可作为示波器的配置参数。可以将这些过滤器想象成一个具有“控制面板”的界面，通过它我们可以控制在输入/输出界面上将要执行哪些功能。形式上，过滤器可以被模拟成函数，它的配置参数决定了过滤器将执行什么数据转换。改进后的管道过滤器模型仪器软件耦合采集To-XY裁剪触发子系统测量信号时间波形迹测量值耦合度种类、速率转换大小改进后的管道过滤器模型仪器软件控制界面的引入解决了很大一部分用户界面的问题。它提供了一系列设置，这些设置决定了示波器的哪些方面可以被用户动态地修改；它同时也解释了用户如何通过不断地调整软件来改变示波器的功能；控制界面将示波器的信号处理功能和实际的用户界面分离：信号处理软件不需要考虑用户实际设置参数的方式。反之，实际的用户界面仅仅通过控制参数来控制信号处理功能。设计者可以在不影响用户界面实现的情况下，更改信号处理软件和硬件的实现。改进后的管道过滤器模型仪器软件仍然存在问题管道过滤器计算模式的性能非常差，特别是波形数据占用了很大的内存容量，过滤器每次处理波形时都复制波形数据是不切实际的；不同的过滤器以完全不同的速度运行专用化模型仪器软件将模型进一步专用化，引进多种“颜色”的管道，而不只是使用一种管道。一种管道允许某些过滤器在处理数据时不必复制数据。另一种管道允许慢速过滤器在数据没有处理完时忽略新来的数据。这些附加的管道增加了风格词汇表并且可以根据产品的性能定制管道/过滤器的计算模式。总结仪器软件强调了这样的事实：不同的体系结构风格对于问题的解决有不同的效果。揭示了为工业软件设计体系结构时，必须将“纯”的体系结构风格改造成专用的风格来满足特定领域的需要。为满足一类产品族的需要而对一般风格进行改造非常重要。背景移动机器人移动机器人系统是用来操纵有人驾驶或部分地有人驾驶的交通工具，比如汽车、潜水艇、航空器。这类系统在诸