软件工程.

Presentation on theme: "软件工程."— Presentation transcript:

1 软件工程

2 第8章 进行体系结构设计

3 主要内容 软件体系结构 数据设计 体系结构风格和模式 体系结构设计 评估可选的体系结构设计 映射数据流到软件体系结构 小结

4 进行体系结构设计 体系结构设计描述了建立计算机系统所需的数据结构和程序构件。它需要考虑系统采取的体系结构风格，系统组成构件的结构、性质，以及所有体系结构构件之间的相互关系。

5 进行体系结构设计 尽管软件工程师能够设计数据和体系结构，但是在建造大型复杂系统的时候，数据和体系结构的设计往往由专家来完成。数据库或者数据仓库设计者为系统创建数据体系结构。”系统体系结构设计师“为系统工程和软件需求分析中导出的需求选择合适的体系结构风格。

6 进行体系结构设计 人们不能在没有图纸的情况下建房子，同样也不能通过勾画出房子的管道布局而开始绘制房屋的蓝图。在开始考虑细节之前，需要关注整体视图——房子本身。这就是体系结构设计需要做的事情——它为你提供整体的视图并保证得到正确的理解。

7 进行体系结构设计 体系结构设计始于数据设计，然后导出系统体系结构的一个或者多个表示。对可选的体系结构风格或模式进行分析，以导出最适合于客户需求和质量属性的结构。一旦选定，使用体系结构设计方法对体系结构进行精化。 在体系结构设计过程中，将创建一个包括数据架构和程序结构的体系结构模型。此外，还需描述构件的性质以及交互关系。

8 进行体系结构设计 设计通常被描述为一个多步过程，其主要任务是从需求信息中综合出数据的表示、程序结构、接口特征和过程细节。
设计是由信息驱动的。软件设计方法都是通过仔细考虑分析模型的三个域而得到的。因此，信息、功能和行为三个域是创建软件设计的指南。 体系结构设计是构建软件的初始蓝图。

9 软件体系结构 从第一个程序被划分成模块开始，软件系统就有了体系结构。同时，程序员已经开始负责模块间的交互和模块装配的全局属性。从历史的观点看，体系结构隐含了很多内容——实现的偶然事件或先前遗留系统。好的软件开发人员经常采用一个或者多个体系结构模式作为系统组织策略，但是他们只是非正式地使用这些模式，并且在最终系统中没有将这些模式清楚地体现出来。

10 什么是体系结构 一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系。
体系结构并非可运行软件。它是一种表达，使软件工程师能够：(1)分析设计在满足规定需求方面的有效性；(2)在设计变更相对容易的阶段，考虑体系结构可能的选择方案；(3)降低与软件构造相关联的风险。

11 什么是体系结构 在体系结构设计的环境中，软件构件可以简单到程序模块或者面向对象的类，也可以扩充到包含数据库和能够完成客户与服务器网络配置的“中间件”。 本教材中，软件体系结构的设计考虑了设计金字塔中的两个层次——数据设计和体系结构设计。数据设计使我们表示出传统系统中体系结构的数据构件和面向对象系统中类的定义，体系结构设计则主要关注软件构件的结构、属性和交互作用。

12 为什么体系结构如此重要 [BAS03]给出了软件体系结构之所以重要的三个关键原因：
软件体系结构的表示有助于对计算机系统开发感兴趣的各方开展交流。 体系结构突出了早期设计决策，这些决策对随后的所有软件工程工作有深远的影响，同时对系统作为一个可运行实体的最后成功有重要作用。 体系结构“构建了一个相对小的，易于理解的模型，该模型描述了系统如何构成以及其构件如何一起工作”。 体系结构设计模型和包含在其中的体系结构模式都是可以传递的，即体系结构的风格和模式可以被应用于其他系统的设计中，并且表示了一组使软件工程师能以可预见的方式描述体系结构的抽象。

13 数据设计 数据设计是把在分析模型中定义的数据对象转化成软件构件级的数据结构，并且在必要时转化为应用程序级的数据库体系结构。在某些情况下，必须为一个新系统专门设计和建立数据库。

14 体系结构级的数据设计 当今，大大小小的业务均充斥着数据，甚至一个中型规模企业拥有为多个应用系统提供服务的几十个数据库。问题在于如何从这样庞大的数据环境中提取有用的信息，特别当需要的信息是功能交叉时。 IT界开发出了数据挖掘技术，也称为数据库中的知识发现，该技术遍历现有的数据库以试图抽取出合适的业务级信息。另一种可选的解决方案称为数据仓库，它是一个独立的数据环境，但包含了某业务使用的所有数据。

15 构件级的数据设计 构件级的数据设计关注于那些被一个或者多个软件构件直接访问的数据结构的表示。[WAS80]提出了以下数据规格说明原则：
1.应用于功能和行为的系统分析原则也可应用于数据。同样应该开发和评审数据流和数据内容的表示，标识数据对象，还应该考虑其他可选的数据组织结构，评估数据模型对软件设计的影响。 2.标识所有数据结构及其完成的操作。设计一个高效的数据结构，必须考虑其上的操作。把属性和操作封装在一个类中满足这个原则。

16 构件级的数据设计 3.应该建立定义数据对象内容的机制，并且用于定义数据及其操作。类图定义包含在类中的数据项和应用到这些数据项上的方法。
4.低层的数据设计决策应该延迟到设计过程的后期。数据设计可以采用逐步求精的过程，所有的数据组织可以在需求分析阶段定义，在数据设计工作中精化，在构件级设计阶段刻画细节。

17 构件级的数据设计 5.只有那些直接使用数据结构内部数据的模块才能够看到该数据结构的表示。信息隐蔽概念以及相关的耦合概念为软件设计质量的评估提供了依据。 6.应该开发一个由有用的数据结构及其操作组成的库。类库即可实现这个目标。 7.软件设计和程序设计语言应该支持抽象数据类型的规格说明和实现。如果没有办法对所选用于实现的编程语言中的结构进行直接说明，那么复杂数据结构的实现将变得非常困难。

18 体系结构风格和模式 建筑师使用体系结构（建筑风格）作为描述机制，将该房子和其他风格的房子区分开来。但更重要的是，体系结构风格也是建筑的样板。必须进一步规定房子的细节，具体说明它的最终尺寸，进一步给出定制的特征，确定建筑材料等。实际上是建筑风格指导了建筑师的工作。

19 体系结构风格和模式 为计算机系统建造的软件也展示了众多体系结构风格中的一种。每种风格描述一种系统类别，包括：(1)一组构件完成系统需要的某种功能；(2)一组连接器，它们能使构件间实现“通信、合作和协调”；(3)约束，定义构件如何集成为一个系统；(4)语义模型，它能使设计者通过分析系统的构成成分的性质来理解系统的整体性质。

20 体系结构风格和模式 一种体系结构风格就是一种在整个系统设计上面的变换。它的目的就是为系统的所有构件建立一个结构。在对已有体系结构进行再工程时，强制采用一种体系结构风格会导致软件结构的根本性改变，包括对构件功能的再分配。

21 体系结构风格和模式 体系结构模式也对体系结构的设计施加一种变换。然而，体系结构模式与体系结构风格在许多基本方面存在不同：(1)体系结构模式涉及的范围要小一些，它更多集中在体系结构的某一局部而不是体系结构的整体；(2)模式在体系结构上施加规则，描述了软件是如何在基础设施层次上处理某些功能性方面的问题；(3)体系结构模式倾向于在系统结构的环境中处理特定的行为问题。模式可以与体系结构风格结合起来，用于建立整个系统结构的外形。

22 体系结构风格的简单分类 以数据为中心的体系结构。数据存储驻留在这种体系结构的中心，其他构件会经常访问数据存储，并对存储中的数据进行更新、增加、删除或者修改。图8-1描述了一个典型的以数据为中心的体系结构风格。在某些情况下存储库是被动的，即客户软件独立于数据的任何变化或其他客户软件的动作而访问数据。该方法的一个变种是将中心存储库变换成“黑板”，当用户感兴趣的数据发生变化时，它将通知客户软件。

23 体系结构风格的简单分类 图8-1以数据为中心的体系结构

24 体系结构风格的简单分类 以数据为中心的体系结构提升了可集成性，即现有的构件可以被修改而且新的客户构件可以加入到系统结构之中，而无需考虑其他的客户。另外，数据可以在客户间通过“黑板”机制传送，客户构件独立地执行过程。

25 体系结构风格的简单分类 数据流体系结构。当输入数据经过一系列的计算和操作构件的变换形成输出数据时，可以应用这种体系结构。管道和过滤器结构(如图8-2)拥有一组被称为过滤器的构件，这些构件通过管道连接，管道将数据从一个构件传送到下一个构件。每个过滤器独立于其上游和下游的构件而工作，过滤器的设计要针对某种形式的数据输入，并且产生某种特定形式的数据输出。然而，过滤器没有必要了解与之相邻的过滤器的工作。 如果数据流退化成单线的变换，则称为批序列。这种结构接收一批数据，然后应用一系列连续的构件(过滤器)变换它。

26 体系结构风格的简单分类 图8-2 数据流体系结构

27 体系结构风格的简单分类 调用和返回体系结构。该体系结构风格能够让软件设计师设计出一个相对易于修改和扩展的程序结构。存在两种子风格：
主程序/子程序体系结构。这种传统的程序结构将功能分解为一个控制层次，其中“主”程序调用一组程序构件，这些程序构件又去调用别的程序构件。图8-3描述了该种系统结构。 远程过程调用体系结构。主程序/子程序体系结构的构件分布在网络的多个计算机上。 面向对象体系结构。系统的构件封装了数据和必须应用到该数据上的操作，构件间通过信息传递进行通信与合作。

28 体系结构风格的简单分类 图8-3 主程序/子程序体系结构

29 体系结构风格的简单分类 层次体系结构。层次体系结构的基本结构如图8-4所示。其中定义了一系列不同的层次，每个层次各自完成操作，这些操作不断接近机器的指令集。在最外层，构件完成用户界面的操作；在最内层，构件完成与操作系统的连接；中间层提供各种实用程序服务和应用软件功能。 这些体系结构风格仅仅是软件设计师可用风格中的一小部分。一旦需求工程提示了待构建系统的特征和约束，就可以选择最适合这些特征和约束的体系结构风格或者风格的组合。在很多情况下，会有多种风格是适合的，需要对可选的体系结构风格进行设计和评估。

30 体系结构风格的简单分类 图8-4 层次体系结构

31 体系结构模式 如果建筑工人决定建构一个“殖民式中厅”，那么只能应用一种体系结构风格。风格的细节内容是可以酌情变动的，但是一旦确定了房子的整体体系结构，这个风格就会影响设计。 体系结构的模式有所不同。例如，房子采用一种Kitchen模式，这种Kitchen模式规定了厨房基本用具的放置、水池、橱柜等要求，如果可能的话，也规定了房间中与完成做饭流程相关的这些厨具的布置规则。另外，该模式还可能指明柜台面、灯、墙上的插座、中心岛、地板等要求。显然对厨房有不止一种的设计，但是每种设计都应该在Kitchen模式提供的解决方案环境下来构思完成。

32 体系结构模式 软件的体系结构模式定义了处理系统某些行为特征的方法。[BOS00]定义了一系列的体系结构模式域：
并发性：很多应用系统必须以一种模拟并行的方式来操作多个任务。在一个应用系统中有很多不同的方法处理并发性，而且每种方法都可以由不同的体系结构模式来呈现。例如，一种方法是使用“操作系统进程管理”模式，该模式提供了一些内置的操作系统特征，这些特征允许构件并发执行。这个模式同时还结合了操作系统中那些管理进程通信、调度的功能以及其他完成并发所需要的功能。还有一种方法是在应用层上定义一个任务调度器。“任务调度器”模式包括一组含有tick()操作的活动对象。调度器定期唤醒每个对象的tick()操作，该操作在控制权返回调度器之前完成它负责的功能，接着调度器唤醒下一个并发对象的tick()操作。

33 体系结构模式 持久性：如果数据从创建它的进程执行以来一直存在，则该数据是持久性存在的数据。持久数据被存储在数据库中或者文件里，并且可以在稍后的时间里被其他进程读取和修改。在面向对象的环境中，持久对象的概念对持久性概念做了一些扩展，所有对象属性的值、对象的状态以及其他的附加信息都被存储起来，以备今后的存取和使用。一般说来，可以采用两种体系结构模式获得持久性：一个是数据库管理系统模式，该模式将DBMS的存储和存取能力用于应用系统的体系结构中；另一个是应用级的持久模式，此种模式在应用体系结构中建立了持久性特征。

34 体系结构模式 分布性：分布性问题强调系统或系统中构件在一个分布的环境中相互通信的方式。分布性问题有两个元素：(1)实体间连接方式；(2)实体间通信的特性。解决分布性问题最普遍的体系结构模式是代理模式。代理在客户端构件和服务器构件之间充当“中间人”。客户端向代理发出一条信息（包含所有使通信有效的信息），代理完成（与服务器的）连接。 在选择一种体系结构模式之前，必须评估其对于应用和整个体系结构风格的适应性，即它的可维护性、可靠性、安全性和性能。

35 组织和求精 设计过程经常给软件工程师留下一系列可供选择的体系结构，建立一组用于评估所导出的体系结构设计的设计标准是非常重要的。[BAS98]提出的下面问题有助于对导出的体系结构风格提供深层次的考察。

36 组织和求精 控制：在体系结构中如何管理控制？是否存在一个不同的控制层次？如果是，构件在控制层次中担当什么角色？构件如何在系统中传递控制？构件间如何共享控制？控制拓扑结构（即控制呈现的几何形状）是什么样？控制是否同步或构件是否异步操作？

37 组织和求精 数据：构件间如何进行数据通信？数据流是否是连接的，或数据对象是否是零散地传递给系统？数据传递的模式是什么（即，数据是从一个构件传递到另一个构件，还是系统中构件可以全局共享数据）？是否存在数据构件（如黑板或中心存储库）？如果存在，它们的角色是什么？功能构件如何和数据构件交互？数据构件是被动的还是主动的（即数据构件是否主动地和系统中其他构件交互）？数据和控制如何在系统中交互？

38 体系结构设计 在体系结构设计开始的时候，软件必须放在所处环境进行开发，即，设计应该定义与软件交互的外部实体（其他系统、设备、人）和交互的特性。一般在分析模型阶段可以获得这些信息，而所有其他的信息都是在需求工程阶段获得的。一旦建立了软件的环境模型，并且描述出所有的外部软件接口，那么设计师就可以通过定义和求精实现体系结构的构件来描述系统的结构。这个过程不停地迭代，直到获得一个完善的体系结构。

39 系统的环境表示 系统环境图通过描述系统的出入信息流、用户界面和相关的支持处理等来实现对环境的建模。在体系结构设计层，软件架构师用体系结构环境图对软件与外部实体交互方式进行建模。图8-5给出了体系结构环境图的通用结构。

40 系统的环境表示 图8-5 体系结构环境图

41 系统的环境表示 与目标系统交互的系统可以表示为： 上级系统：这些系统把目标系统作为某些高层处理方案的一部分。
下级系统：这些系统被目标系统使用，并为了完成目标系统的功能提供必要的数据和处理。 同级系统：这些系统在对等的基础上相互作用。 参与者：是指那些通过产生和消耗必不可少的处理所需的信息，实现与目标系统交互的实体（人、设备）。 每个外部实体都通过某一接口（带阴影的小矩形）与目标系统进行通信。

42 SAFEHOME实例[32] 9-6 9-6

43 图8-6 SafeHome安全功能的体系结构环境图

44 定义原始模型 原始模型是一个类或者一个模式，描述了一个目标系统体系结构设计的核心抽象。一般来讲，只需要设计相对较小的原始模型集合，即使系统相对比较复杂。目标系统的体系结构由这些原始模型组成，这些原始模型表示体系结构中稳定的元素，但是这些元素基于系统行为可用多种方式加以说明。

45 SAFEHOME实例[34]

46 图8-7 SafeHome安全功能原始模型的UML关系图

47 将体系结构精化为构件 当软件体系结构精化为构件时，系统的结构开始显现。但是，如何选择这些构件呢？体系结构设计师先从分析模型中所描述的类开始。这些分析类表示那些软件体系结构中必定涉及的应用（业务）领域内的实体。因此，应用领域是导出和精化构件的一个源泉。另一源泉是基础设施域。体系结构必须容纳很多基础设施构件使应用构件能够运作，但是这些基础设施构件与应用领域没有业务联系，例如，内存管理构件、通信构件、数据库构件和任务管理构件往往归并到软件体系结构中。

48 将体系结构精化为构件 体系结构环境图中描述的接口隐含着一个或者多个特定的构件，这些构件处理穿过接口的数据。在某些情况下，需要设计一个完整的包含众多构件的子系统体系结构。

49 SAFEHOME实例[36]

50 图8-8 带有高层构件的SafeHome整体体系结构

51 描述系统实例 至此所建立起来的体系结构设计依然处于比较高的层次。系统的环境已经表示出来了，预示问题域中重要抽象的原始模型也被定义出来，系统的整个结构已经显现出来，并且主要的软件构件也都定义出来了，然而，更进一步的精化仍然是必要的。 为了完成体系结构设计，要开发一个体系结构的实际实例，用意是将体系结构应用到一个特定的问题上，目的是证明结构和构件都是合理的。

52 SAFEHOME实例[38]

53 评估可选的体系结构设计 设计会导致多种可供选择的候选体系结构，其中每一种候选体系结构都需要评估，以确定哪种体系结构最适合要解决的问题。

54 体系结构权衡分析方法 SEI开发了一种体系结构权衡分析方法，该方法建立了一个迭代的软件体系结构评估过程。
1、收集场景。 2、诱导需求、约束和环境描述。 3、描述那些已经被选用于解决场景和需求的体系结构风格/模式。 4、通过孤立地考虑每个属性来评估质量属性。 5、针对特定的体系结构风格，弄清质量属性对各种体系结构属性的敏感性。 6、使用在第5步中进行的敏感性分析鉴定候选体系结构。 这6个步骤描述了第一次ATAM迭代。基于第5步和第6步的结果，某些候选体系结构可能被删除，剩余的一个或多个体系结构可能被修改和进一步细化，然后，ATAM步骤被再次应用。

55 体系结构复杂性 对体系结构的整体复杂性进行评估，一种很有用的技术是考虑体系结构中构件间的依赖关系，这些依赖关系是由系统中的信息/控制流驱动的。[ZHA98]建议了三种类型的依赖： 共享依赖表示在使用相同资源的消费者间或为相同消费者生产的生产者之间的依赖关系。 流依赖表示资源的生产者和消费者间的依赖关系。 约束依赖表示在一组活动间相关控制流上的约束。

56 体系结构描述语言 体系结构描述语言ADL为描述软件体系结构提供一套语义和语法。[HOF01]建议ADL应该使得设计者具有分解体系结构构件、将单独构件组合成大的体系结构块，以及描述构件之间的接口的能力。一旦体系结构设计使用的描述的、基于语言的技术被建立起来，那么很有可能随着设计的进化而建立起体系结构的有效评估方法。

57 映射数据流到软件体系结构 体系结构风格描述了本质上不同的体系结构，因此，并不存在一种能够实现从分析模型到各种体系风格转换的全面映射。
为了描述体系结构映射的方法，考虑“调用和返回”体系结构的映射技术——这种体系结构是非常常见的结构。这种映射技术使得设计者能够从分析模型的数据流图中导出相当复杂的“调用和返回”体系结构，这种技术也称为结构化设计。 结构化设计经常被刻画为面向数据流的设计方法，它提供了方便的从数据流图到软件体系结构的变换。信息流的类型决定了映射方法。

58 DFD的两种类型 为了实现从DFD到体系结构的映射(需求模型设计模型)，需要仔细区分DFD中数据流的性质，并分别学习相应的映射方法。

59 变换型结构（变换流）

60 变换型结构（变换流）

61 事务型结构(事务流)

62 事务型结构(事务流)

63 变换映射 变换映射是一组设计步骤，可以将具有变换流特征的DFD映射为某个特定的体系结构风格。

64 步骤1：评审基本系统模型 基本系统模型或者环境图把安全功能描述为一个单一的变换，描述了流入和流出安全功能的数据的生产者和消费者。图8-11刻画了一个0层模型，图8-12描述了初步精化后的安全功能数据流。

65 SAFEHOME实例[39] 图8-11 SafeHome的环境级DFD

66 图8-12 SafeHome安全功能的第一层DFD

67 步骤2：评审和精化软件的数据流图 对从分析模型获得的信息进行精化，以获得更多的细节。例如，检查第2层监控传感器的DFD(如图8-13)，并导出第3层数据流图(如图8-14)。在第3层，数据流图中的每个变换都展示了高内聚性，即变换所包含的过程完成单一的、清楚的功能，该功能可被实现为SafeHome软件中的一个构件。图8-14中的DFD包含了设计监控传感器子系统体系结构所需的细节信息，不需要再进一步精化。

68 SAFEHOME实例[41] 图8-13 精化“监控传感器”变换的第2层DFD

69 SAFEHOME实例[42] 图8-14 具有流边界的监控传感器的第3层DFD

70 步骤3:确定DFD是否含有变换流或事务流特征

71 步骤4:通过确定输入和输出流的边界，分离出变换中心
输入流被描述为信息从外部形式变换为内部形式的路径，而输出流是信息从内部形式变换为外部形式的路径。不同的设计人员在选择流边界时可能不尽相同。事实上，不同的流边界选择会导致不同的设计方案。尽管在选择流边界时要加以注意，但沿流路径若有一个泡泡的差异对最终程序结构的影响并不会太大。

72 步骤5:完成“第一级分解” 使用这个映射导出的程序体系结构导致了自顶向下的控制分布。分解的作用是得到一个程序结构，其中顶层模块做决策；低层模块完成大多数输入、计算和输出工作；中层模块既完成一部分控制，又完成适量的工作。 当遇到变换流时，DFD将被映射成一个能为信息的输入、变换和输出处理提供控制的特定结构。图8-15给出了对监控传感器子系统进行第一级分解的结果，主控制器（图中称为监控传感器输入控制器）位于程序结构的顶端，负责协调从属控制功能。

73 SAFEHOME实例[43] 图8-15 监控传感器的第一级分解

74 步骤5:完成“第一级分解” 输入信息处理控制器负责协调所有输入数据的接收。 变换流控制器负责管理内部形式的数据上的所有操作。
输出流信息处理控制器负责管理输出信息的产生。 虽然图8-15蕴涵了三叉结构，但是，大型系统的复杂数据流图可能会要求为上述每个类属控制功能提供两个或多个模块。第一层模块的数量应限定在既能完成控制功能又能维持良好的独立特征所要求的最少模块数。

75 步骤6:完成“第二级分解” 第二级分解是将DFD中的每个变换映射到程序结构中的相应模块。从变换中心的边界开始，沿输入路径和输出路径向外，将变换依次映射到软件结构的从属层。图8-16描述了第二级分解的一般方法。

76 SAFEHOME实例[44] 图8-16 监控传感器的第二级分解

77 步骤6:完成“第二级分解” 虽然图8-16描述了DFD变换和软件模块间的一对一映射，但其他的映射方式也经常采用。两个甚至三个变换可以合并在一起表示为一个构件，或者一个单独的变换也可以扩展成两个或者多个构件。现实考虑和设计质量的权衡决定着第二级分解的输出结果。评审和精化可能会导致这个结构的改变，但这个结构仍然应作为第一次迭代设计。

78 步骤6:完成“第二级分解” 对于输入流的第二级分解遵循同样的方式，从输入流一侧的变换中心边界开始向外移动。变换中心映射略有不同，DFD变换部分的每个代表数据转换或计算的变换都被映射为变换控制器的从属模块。图8-17给出了一个完整的第一次迭代的体系结构。 按以上方法映射出来的构件描述了软件体系结构的一个初始设计。虽然构件的名字已经可以体现其功能，但我们仍然需要为每个构件提供简要的处理叙述。

79 SAFEHOME实例[45] 图8-17 监控传感器第一次迭代后的结构

80 步骤7:使用提高软件质量的设计启发式方法，精化第一次迭代得到的体系结构
应用功能独立性概念，能够精化第一次迭代得到的体系结构。对构件进行外爆或内爆，可以得到合理的分解、好的内聚性、低的耦合性，最重要的是获得易于实现、可系统性测试和易于维护的程序结构。 求精是在前述的分析和评估方法以及现实考虑和常识等指导之下进行的。例如，有时输入数据流的控制器完全没有必要，有时需要在一个从属于变换控制器的构件中完成输入处理，有时全局数据的存在使得高耦合性不可能避免，有时不能达到优化结构特征，软件需求加人工判断是最终依据。

81 SAFEHOME实例[46] 图8-18 监控传感器精化后的程序结构

82 事务映射 在许多软件应用中，单独的数据项会触发多条信息流中的一条，这些数据流将实现该数据项隐含的功能。这个数据项被称为事务。
考虑SafeHome安全功能的用户交互子系统。该子系统的第1层数据流如图8-12所示。对此图数据流进行精化，得到第2层数据流图，如图8-19所示。数据对象“用户命令”流入系统，沿三条动作路径之一产生其他信息流，单个数据项“命令类型”引发数据流从中心向外扇出，因此，整个数据流的特征是面向事务的。 值得注意的是，沿着三个动作路径中的两条路径上的信息流可以满足额外的输入流。每个动作路径都流入单个变换“显示消息和状态”。 事务映射的设计步骤与变换映射的步骤相类似，甚至在某些情况下是相同的。主要区别在于DFD到软件体系结构的映射。

83 SAFEHOME实例[47] 图8-19 用户交互子系统的第2级DFD

84 事务映射 步骤1：评审基本系统模型 步骤2：评审和精化软件的数据流图
步骤3：确定DFD含有变换流还是事务流特征。图8-19给出的DFD具有典型的事务流特征，但从变换“调用命令处理”发出的两条动作路径上的流具有变换流的特征，因此必须为这两种流建立流边界。 步骤4：标识事务中心和每条动作路径上的流特征。事务中心的位置可以从DFD上直接识别出来，事务中心位于几条动作路径的起始点上。输入路径（接收事务的流路径）和所有的动作路径都必须被隔离出来，评估每条动作路径，以确定它们自己的流特征。

85 事务映射 步骤5:将DFD映射到一个适合于事务处理的程序结构上。事务流被映射到一个包含输入分支和调度分支的程序结构上。输入分支结构的开发与变换流映射方法相类似，从事务中心开始，沿输入路径的变换都被映射成模块。调度分支结构又包含一个调度器模块，它控制下面所有的动作模块。DFD的每一个动作流路径都被映射成与其自身的流特征一致的结构。图8-20描述了该过程。

86 事务映射 图8-20 事务映射

87 事务映射 考虑用户交互子系统的数据流,步骤5的第1级分解如图8-21所示.变换”读用户命令”和”激活/关闭系统”可以直接映射到程序结构中,无需中间的控制模块。事务中心“调用命令处理”直接映射成同名的调度器模块；建立系统配置和密码处理的控制器，如图8-21所示。

88 SAFEHOME实例[48] 图8-21 用户交互子系统的第2级DFD

89 事务映射 步骤6:分解并精化事务结构和每条动作路径的结构。数据流图的每条动作路径都有自己的信息流特征，它可以是变换流也可以是事务流。与动作路径相关的“子结构”可以根据本节和上节讨论的设计步骤进行开发。 步骤7:使用提高软件质量的设计启发式方法，精化第一次迭代得到的体系结构

90 SAFEHOME实例[49] 图8-22 用户交互子系统的第一次迭代体系结构

91 精化体系结构设计 在讨论设计求精之前，应首先遵循这句话：“记住，不能工作的‘优化设计’是很值得怀疑的。“基于设计度量和启发式方法，软件设计人员应该始终考虑开发一个满足所有功能和性能需求以及值得信任的软件表示。 应该鼓励在设计早期阶段就对软件体系结构进行精化。对选择的体系结构风格导出、精化和评估以达到”最好“。这种优化方法也是开发软件体系结构表示的一个重要收益。 重要的是注意，结构上的简单往往反映出程序的优雅和高效。设计求精应在满足模块化要求的前提下尽量减少构件的数量，在满足信息需求的前提下尽量减少复杂的数据结构。

92 小结

93 作业 P193页