第7章 设计构架

 

几乎在我们遇到的所有成功的面向对象系统中都具有但失败的系统中缺少 的两个特性是：存在一个强大的构架构想，应用管理良好的迭代式增量开发 周期.

                        -Grady Booch[Stikeleather 96]

现在我们把注意力转向构架的设计以及当构架逐渐形成时您能够做些什么。本章将讨 论如下4个主题：

 

•    生命期中的构架

 

•    设计构架

 

•    形成团队结构及其与构架的关系 

•    创建骨架系统

 

7.1生命期中的构架

把构架作为软件开发过程基础的任何组织都需要理解构架在其生命期中的位置。目前 有几个生命期模型，但把构架放在一个适当位置的模型是演变交付生命期模型，如图7.1 所示。该模型的意图是获得用户和客户反馈，并在发布最终版本前通过几个版本进行迭代。 该模型还允许在每次迭代中添加功能，并在开发了足够的特性集后，就交付该功能受到限制的版本。（关于该生命期模型的更多信息，消参见7.6节）。

 

何时可以开始设计

在生命期模型中，构架设计就是从初步的需求分析幵始逐步进行迭代。很显然，在了 解系统需要前，不能幵始设计构架。另一方面，刚开始进行设计时并小需要收集太多需求。

 

功能、质量和商业需求的某个集合“塑造’’ 了构架。我们把这些塑造霈求称为“构架 驱动因素"，案例分析中将给出•些示例。第3章所讨论的A-7E的构架由其可修改性和性能需求塑造。第6章所讨论的空中交通管制系统的构架由其可用性需求塑造。在第8章所 表述的飞行模拟器软件中，我们将看到一个由性能需求和可修改性潲求塑造的构架，等等。

 

为了确定构架驱动因素，需要识别优先级最高的业务目标。这样的业务目标应该很少。 用质量厲性场景或用例来表述这些业务目标。从该列表中，选择对构架影响最大的需求。 这些就是构架驱动因素，应该少于10个。第11章讲述的构架权衡分析方法将使用“效用树"把业务驱动因素转换为质量属性场景。

 

知道了构架驱动因素后，就可以开始构架设计了.于是，构架设计中产生的问题将会 影响需求分析过程——图7.1中所示的一个反向箭头。

 

7.2设计构架

本节将描述•个用于设计构架以满足质量需求和功能需求的方法。我们把这种方法称 为属性驱动的设计（Attribute Driven Design, ADD)。ADD把•组质徵属性场景作为输入， 并使用对质量厲性实现和构架之间的关系的了解，对构架进行设计。可以把ADD方法看 作是对大多数其他开发方法的扩展，如Rational统一过程„ Rational统一过程有几个进行 构架高层设计的步骤，但接着就进入了详细设计和实现阶段。将ADD集成到构架中包括 修改处理构架高层设计的步骤，然后遵循Rational所描述的过程。

 

属性驱动的设计

 

ADD是种定义软件构架的方法，该方法将分解过程建立在软件必须满足的质量属 性之I:。它址一个递归的分解过程，其中在每个阶段都选择战术和构架模式来满足一组质 fi属性场景，然后对功能进行分配，以实例化由该模式所提供的模块类型。在生命期中， ADD位于滞求分析之后，而且正如我们所说过的那样，在已经较为自信地知道了构架驱 动因素后，ADD就可以开始了。

 

ADD的结果是构架的模块分解视图和其他视图（在适当惝况下）的最初的儿个层次。 并不是视图的所有细节都是通过ADD得到的，系统被描述为功能和功能之间交互的-组 容器。这是设计过程中构架的第一个连接点（articulation),因此肯定是粗粒度的。尽管如 此，它对实现期望的质量属性来说还是非常关键的，并且它为实现功能提供了一个框架。

 

由ADD得到的构架和已经为实现做好准备的构架之间的区别是，需要做出更详细的设计 决策。例如.这些决策可能是使用具体的面向对象设计模式，或为其带来许多构架限制的某个特定的屮间件。根据ADD设计的构架可能会故意推迟该决策，直到具有更大的灵活 性为止.

 

可以使用第4章的-般场景和第5章的战术与模式创建许多不同的设计过程。关于如 何“粘连”设计工作以及设计过程的本质，每个过程都做了不同的假定。我们对ADD进 行了较为详细的讨论，以说明如何应用一般场景和战术，如何“粘连"工作，以及我们所 ;认定的设计过程的本质。

 

我们使用ADD方法为家庭信息系统中的车库门幵关器设计一个产品线构架，以对 ADD方法进行说明。开关器负责通过开关、远程控制或家庭信息系统来实现车门的举升 和下降。还可以通过家庭信息系统来诊断开关器的问题。

 

样本输入。ADD的输入是一组需求。与其他设计方法样，ADD把功能需求（一般表示为用例）和限制作为输入。然而.在处理质量需求时，ADD与其他方法不同,，ADD要求把质蛩需求表示为-组特定于系统的质量场景。第4孽所讨论的•般场景充当需求过 程的输入，并提供了一个在开发特定于系统的场景中所使用的检杳列表。应该把特定于系 统的场最定义到对该应用必需的详细程度。在我们的示例中.我们忽略了 •个完整的场景 的儿个部分，因为这几个部分对设计过程没有什么贡献。

 

对于我们的车库门示例，质量属性场景包括如下内容：

 

•    对于产品线中的各种产品来说，用于开门和关门的设备和控制装置是不同的，这 在文中己经提过。它们可以包括家庭信息系统中的控制装置。应该可以直接从产 品线构架中推导出-组特定控制装置的产品构架。

 

•    不同产品中使用的处理器不同。应该可以直接从产品线构架中推导出毎个特定处 理器的产品构架。

 

•    如果车库门在下降的过程中检测到个障碍物（人或物体），它必须在0.1秒内停 止（可选方式是重新打开)•

 

•    应该可以在家庭信息系统内使用特定于产品的诊断协议来诊断和管理车库门开关器。应该可以直接产生-•个反映该协议的构架。

 

开始ADD,,我们已经介绍了构架驱动因素.ADD依赖于对驱动因素的识别.确定了 所有的驱动因素后，ADD就可以开始了，当然，在设计中关键的构架驱动因素可能会发 生变化，或者是因为更好地理解了需求，或者是因为需求发生了变化。尽管如此，当比较 自信地知道了驱动因素需求时，该过程就可以幵始了。

 

下面将对ADD进行讨论。

 

ADD步骤..我们先简要介绍-下使用ADD方法设计构架时所执行的步骤，然后对各 个步骤进行详细讨论。

 

(1)选择要分解的模块。耍分解的模块通常是整个系统。该模块耍求的所有输入都 应该是可获得的（限制条件、功能需求和质量需求）。

 

(2)根据这些步骤对模块进行求精：

 

a.从具体的质量场景和功能需求集合中选择构架驱动因素。这•步确定出了对 该分解很重要的事物。

 

b.选择满足构架驱动因素的构架模式。根据可以用来实现驱动因素的战术创建 (或选择）模式。确定实现这些战术所需要的子模块。

 

c.实例化模块并根据用例分配功能，使用多个视图进行表示。

 

d.定义子模块的接口。该分解提供了模块和对模块交互类型的限制。对于每个 模块，将该信息编写在接口文档中。

 

C.验证用例和质摄场景并对其进行求精.使它们成为子模块的限制。这一步验证重要的内容没有被遗忘.并使子模块为进一步分解或实现做好准备。

 

(3)对需要进一步分解的每个模块重复上述步骤，

 

(1)选择要分解的模块-下面是所有的模块：系统、子系统和子模块。分解通常 从系统开始.然后将其分解为子系统，再进一步将子系统分解为子模块。

 

在我们的示例中，车库门开关器是系统。在该级别的一个限制就足开关器必须能与家 庭信息系统互操作。

 

(2.a)选择构架驱动因素-正如我们已经说过的•样，构架驱动因素是功能和质 量需求的组合，它们“塑造” 了构架或考虑中的特定模块。我们将在该模块的高优先级需 求中发现这些驱动因素。

 

在我们的示例中，已经给出的4个场景就是构架驱动因素。在该示例所基于的系统中， 有许多质量场景。在对其进行分析的过程中，我们发现了对实时性能以及支持产品线可 修改性的需求。此外还发现了应该支持在线诊断的需求。所有这些滞求都必须在系统的最 初分解屮解决。

 

构架驱动因素的确定并不总是一个自上而下的过程。有时需要进行详细的调查.以理 解特定需求的结果。例如，为了确定对于某个特定的系统配置来说性能是否是一个问题， 可能黹要对系统的某•部分进行原型实现。在我们的示例中，确定该性能需求是否是构架 驱动因素要求分析车库门的结构以及可能的处理器的速度。

 

模块分解将根据构架驱动因素进行。其他需求也适用于该模块，但通过选择驱动因素， 我们把该问题简化为满足最重要的需求。我们并没有同等看待所有需求，而是在满足了最 重要的需求的条件下，才满足不太重要的需求。这是ADD和其他构架设计方法之间的 个重要差别。

 

(2.b)选择构架横式——正如在第5章所讨论的，对每一个质最厲性.都有可以用 在构架设计中来实现•个具体的质量属性的可识别的战术。每个战术都设计用来实现•个 或多个质量属性，但包含这些战术的模式对其他质量属性产生了影响。在构架设计中，使 用许多此类战术的组合来实现所要求的多个质量属性之间的平衡。在求精步骤中分析了质 量和功能需求的实现。

 

步骤2b的目标是建立-个由模块类型组成的总体构架模式。该榄式满足了构架驱动 因素，是通过组合选定的战术来构造的。两个主要的因素支配了战术的选择。第-个就是 驱动因素本身。第二个就是实现战术的模式对其他质量属性产生的副作用。

 

例如.实现可修改性的一个经典战术是使用解释程序。向系统中添加一种解释了的规

范语言以简化新功能的创建或对现有功能的修改。宏记录和执行就是解释程序的一个例 子。HTML是•种规定Web页外观与感觉的解释性语言。解释程序是用于在运行时实现 可修改性的一种出色技巧，怛它对性能有很大的负面影响。是否使用解释程序依赖于可修 改性与性能的相对重要性。可能会做出这样的•个决策：对总体模式的•部分使用解释程 序，对其他部分使用其他战术。

 

如果根据构架驱动因素分析第5章的可用战术.我们会把性能和可修改性看作是关键 的质最域性。可修改性战术是“局部化变更”、“防止连锁反应”以及“推迟绑定时间“。 而且，因为可修改性场景主要与将在系统设计期间出现的变更有关，因此，主要的战术就 是“局部化变更”。我们选择语义一致性和信息隐藏作为所采用的战术，并把它们结合起 来，为受影响的区域定义虚拟机。性能战术是“资源需求”和“资源仲裁”。我们分别为 其选择一个示例：“提高计算效率”和“选择调度策略”。这将会产生如下的战术：

 

•    语义一致性和信息隐藏，我们用单独的模块来处理用户接口、通信和传感器。我 们把这些模块叫做“虚拟机”，而且预计所有这3个模块都会变化，因为从该构 架将会得出不同的产品。还要将与诊断相关的责任分离开。

 

•    提高计算效率。应该使关键性能计算尽可能的高效.

 

•    精心调度。应该对关键性能计算进行调度.以确保时间紧迫的任务的实现。

 

图7.2（图中的虚线箭头表示消息传递）给出了结合使用这些战术所导出的构架模式。这并不是惟-可以导出的模式， 但是一个看上去似乎合理的模式。

(2.c)实例化模块并使用多个视图分配功能——在上-部分中.我们讨论了质量属性

构架驱动因素如何通过战术的使用确定了模块的分解结构。事实上，在那-步中我们定义 了分解步骤的模块类型。现在，我们说明一下如何实例化那些模块类型。

 

实例化模块。    在图7.2中，我们标识了一个运行在管理通信和传感器交互的虚拟机之 上的非关键性能计算（也就是说该非关键性能计算是运行在该虚拟机之 上的，该虚拟机是用来管理通信和传感器之间的交互的）。运行在虚拟机之上的软件通常是.个应用。在具体的系统中-般会 有多个模块。每个功能“组”都将有个模块，这些模块将是模式中所展示的类型的实例。用于分配功能的标准类似于在基于功能的设计方法中所使用的标准，如大多数面向对象的设计方法。

 

对于我们的示例，我们把管理障碍物检测和停止车库门升降的贵任分配给关键性能部 分，因为该功能有•个时限时间。正常的升降门管理没有时间期限，因此我们把它当作非 关键性能部分。诊断能力也是非关键性能部分。因此，图7.2中的非关键性能模块就被实 例化为图7.3中的沴断模块和升/降门模块„我们还标识了虚拟机的几个责任：通信和传感 器阅读以及激励器控制（激励器应该是指遥控器）。这产生了虚拟机的两个实例，请看图7.3（图中的虚线箭头表示消息传递）。

总结一下：图7-3中的用户接口、通信虚拟机、传感器阅读以及激励器虚拟机是按照功能分块进行划分的。而沴断模块和升/降门模块是属于非关键性能模块，把管理障碍物检测和停止车库门升降的贵任分配给关键性能部 分，这是按照质量需求进行划分的。

 

该步骤得到的结果是模块的一个似乎合理的分解。 下一步将验证该分解实现所要求的 功能的情况。

 

分配功能。应用与父模块相关的用例有助于设计师更详细地了解功能的分布情况。这 还可能导致增加或删除子模块，以实现要求的所有功能。最后，父模块的每个用例都必须 可以用子模块中的一系列责任来表示。

 

为分解结构中的子模块分配责任还会帮助发现必要的信息交换。这在这些模块之间产 生了 .个生产者/消费者关系，需要将这一关系记录下来。这时，定义交换信息的方式并不 重要。是否对信息进行了推或拉？是否将其作为消息或调用参数传递？这些都是在设计过程的后期需要回答的问题.此时，我们仅对信息本身以及生产者和消费者角色感兴趣。这 是ADD未能解决、需要在详细设计中解决的信息类型的个示例。

 

一些战术引入了模块类型之间的交互的特定模式。例如，使用发布-订阅类型的仲裁 者战术将引入用于其中-个模块的“发布”模式，以及用于其他模块的“订阅"模式。应 该记录这些交互的模式，因为对受影响的模块来说.它们转化成了责任。

 

这些步骤应该足以使我们确信系统可以提供所期望的功能。为了检查是否满足了期望 的质量属性，我们需要的不仅仅是到目前为止所分配的责任。还需要动态的和运行时部署 信息对质量厲性的实现进行分析，如性能、安全性和可靠性。因此.我们对额外的视图以 及模块分解视图进行了分析。

 

用视图表示构架。在第2章，我们介绍了大量不同的构架视图..根据使用ADD的经 验，我们可以从3组主耍视图（模块分解、并发和部署）中的某个视图展开讨论。方法本 身并不依赖所选择的特定视图，如果需要展示其他方面，如运行时对象，可以引入额外的 视阁现在，我们简要讨论•下ADD如何使用这3个常见的视亂

 

•    模块分解视图。上面的讨论展示了模块分解视图在发现责任时，如何为其提供容 纳贵任的容器。通过该图还确定了模块之间的主要数据流关系。

 

•    并发视图。在并发视图中，可以对系统的动态方而（如并行活动和同步）建模。建立该模型有助于确定资源争用问题、可能出现的死锁情况、数据一致性问题， 等等。对系统中的并发进行建模很可能会发现模块的新的责任，这记录在模块视 图中。它还可能会导致新模块的发现.如资源管理器，以解决对稀少资源的并发 访问等问题。

 

并发视图是组件-连接器视图中的一个。组件是模块分解视图中模块的实例， 连接器是“虚拟线程”的载体。虚拟线程描述了通过系统或系统的一部分的执行 路径。不应该将其与操作系统线程（或进程）混淆，后者暗含了其他像内存/处理 器分配这样的属性。在我们进行设计的层次上，这些并不是我们所关心的属性。 然而.在制定了关于操作系统的决策以及处理单元的模块部署决策后，必须把虚 拟线程映射到操作系统线程上，这是在详细设计期间完成的。

 

并发视图中的连接器就是那些处理诸如以下线程的连接器：“与……同步”、“开 始”、“収消”、“与……通信' 。并发视图展示了模块分解视图中模块的实例，这是 理解这两个视图之间的映射的手段。同步点位于一个特定的模块中，以能够在适 当的地点分配该责任，知道这一点非常重要。

 

为了理解系统中的并发，我们通过下面的用例对此进行说明：

 

•    两个用户同时做类似的事情。这有助于识别资源争用或数据完整性问题。在车库

门示例中，一个用户可能在远程关门，而另•个用户在用开关开门。

 

•    _个用户同时执行多个活动：这有助于揭示数据交换和活动控制问题。在车库门 示例中，-个用户可以在执行诊断的同时开门。

 

•    启动系统。（并发视图说明系统启动的过程）这为系统中永久运行的活动以及如何初始化它们提供了个良好的概 述。它还有助于确定初始化策略，如所有的•切都并行，所有的-切都串行或其 他的模型。在车库门示例中，车库门开关器系统的启动趄否依赖于家庭倌息系统 的可用性？车库门开关器系统总是工作，等待信号，还是随着每次的开门或关门 就启动和停止？

 

•    关闭系统，（并发视图说明系统关闭的过程）这有助于揭示清除问题，如实现并保存一致的系统状态„

 

在车库门示例中，我们可以看到传感器/激励器虚拟机中有-个同步点。该关键性能部分必须对传感器进行采样，就像升/降门部分必须对传感器所做的那样。当 为升/降门部分执行操作时.关键性能部分可能会中断传感器/激励器虚拟机。通 过分析关键性能部分的虚拟线程以及升/降门部分的虚拟线程，并观察到这两个线 程都涉及传感器/激励器虚拟机，我们看到需要•个用于传感器/激励器虚拟机的 同步机制。两个虚拟线程的交叉点说明应该采用某些同步机制。

 

并发可能也是一个变化点，第14章（软件产品线）将对其进行讨论„对某 些产品来说，按顺序进行初始化将会很好，而对于其他产品来说一切工作都应该 以并行方式进行。如果分解不支持使用技巧来改变初始化方法（例如通过交换组 件)，那么就应该对分解进行调整.，

 

•部署视图。如果系统中使用了多个处理器或专门的硬件，则从部署到硬件都可能 会出现额外的责任。使用部署视图有助于确定和设计支持实现期望的质量属性的 部署。部署视图导致了并发视图的虚拟线程，并发视图又分解为特定处理器中的 虚拟线程和在处理器间传输的消息。其中.这些消息会启动操作序列中的下一个 条目。因此，它是分析网络通信和确定潜在拥塞的基础（这里的它所指也包括部署视图）。

 

部署视图还有助于确定是否需要某些模块的多个实例（比如为实现高可用的冗余）。例如，可靠性需求可能会迫使我们在不同的处理器上复制关键的功能。还可以使用部署视图对专用硬 件的使用进行推断。

 

部署视图的导出不是任意的。与模块分解和并发视图一样，构架驱动因素有助 于确定组件到硬件的分配。诸如复制这样的战术通过在不同的处理器上部署复制 品，提供了一个实现高性能或可靠性的手段。诸如实时调度机制这样的战术实际 上阻止了在不同处理器上的部署。功能考虑亊项通常会指导并非由选择的战术所 预先确定的部分的部署。

 

虚拟线程从一个处埋器到另•个处理器的交叉为不同的模块产生了责任。它指出了处

理器之间的通信需求。某个模块必须负责管理通信：必须将该责任记录在模块分解视图中.

 

在车库门示例中.我们在车库门开关器系统和家庭信息系统之间的责任划分中发现了 部署问题。哪个系统负贵对远程请求进行验证，二者之间的通信协议是什么？

 

(2.d)定义子模块的接口——为了 ADD的目的，模块的接口展示了所提供的服务和 所要求的属性。这不同于签名。它对其他接口可以使用的服务和可以依赖的接口编写文档。

 

根据结构（模块分解视图）、活力（并发视图）和运行时（部署视图）对分解进行分 析并编成文档揭示了子模块的交互假定.应该在子模块接口中将其编成文档。

 

模块视图对 如下信息进行编档：

 

•    信息的生产者/消费者

 

•    耍求模块提供服务并使用它们的交互模式

 

并发视阁对如下信息进行编档：

 

•    线程间的交互，它们会导致提供或使用服务的模块接口

 

•    组件活动的信息——例如，自己的线程在运行

 

•    组件同步、序列化大概还有阻塞呼叫的信息

 

部署视图对如下信息进行编档：

 

•    硬件需求，如专用硬件

 

•    一些时间需求，如处理器的计算速度最少必须为10MIPS

 

•    通信需求，如毎秒钟更新信息的速度不能超过1次

 

模块的接口文档应该提供所有这些信息。

 

(2.6)验证并求精用例和质量属性场景（作为对子模块的限制）一到目前为止所

列举的步骤实际上就是对模块分解的建议。必须对该分解进行验证，并且必须使子模块为自己的分解做好准备。

 

功能需求。每个子模块都有一部分从分析功能需求的分解中得出的责任。可以把这些责任转换为该模块的用例。定义用例的另一种方法就是分离父用例并对其进行求精。例如， 把初始化整个系统的用例分解为子系统的初始化。因为分析人员可以遵循该求精，因此该 方法具有可跟踪性。

 

在车库门的例子中，车库门开关器的最初责任就是根据请求打开和关闭车库门，在本 地或以远程方式进行；在检测到障碍物时，在0.1秒内使车库门的动作停止：与家庭信息 系统交互并支持远程诊断。这些责任被分解为如下与模块相对应的功能组。

 

• 用户接口。识别用户请求，并把它们转换为升/降门模块所期望的形式。

• 升/降门模块。控制瀲励器来实现门的上升或下降当门达到全开或全关状态时， 使门停止运动。

 

• 障碍物检测。当检测到障碍物时，或者停止门的下降，或者使其上升。

 

•通信虚拟机。管理与家庭信息系统的所有通信，

 

•传感器/激励器虚拟机。管理与传感器和激励器的所有交互。

 

•调度程序。保证障碍物检测器将满足其时限时间要求。

 

•诊断。管理与要进行诊断的家庭信息系统的交互。

 

限制。可以用如下一种方式满足父模块的限制。

 

•分解满足了该限制。例如，可以通过将某个操作系统定义为子模块来满足使用该 操作系统的限制。该限制得到了满足，就不需要做更多的工作。

 

•该限制由单个子模块来满足。例如，使用一个专门协议的限制可以通过为该协议 定义一个封装子模块来满足。该限制被指定为一个子模块。它是否得到了满足取 决于子模块的分解情况。

 

•该限制由多个子模块来满足。例如，使用Web要求用两个模块（客户机和服务器〉 来实现所必需的协议.该限制是否得到了满足取决于分配了该限制的子模块的分 解和协调。

 

在车库门示例中，一个限制就是维持与家庭信息系统的通信。通信虚拟机将识别该通 信是否不可用，因此通过使用一个子模块满足了该限制。

 

质量属性场景。还必须对质量厲性场景进行求精，并将其分配给子模块。

 

•可以通过分解完全满足质量属性场景，且不会产生任何其他影响。然后可以将其 标记为已满足。

 

•可以通过当前对子模块有限制的分解来满足质量厲性场景。例如，使用层可以满 足一个具体的可修改性场景，这反过来又将限制子模块的使用模式。

 

•关于质量属性场景，分解可以是中性的。例如，易用性场景属于用户接口部分， 然而它却不是该分解的一部分。应该把该场景分配给一个子模块。

 

•质量属性场景可能不满意当前的分解。如果该场景很重要，就应该重新考虑分解； 否则的话，必须把不支持该场景的分解的理由记录下来。这通常是与其他质量厲性场景进行权衡的结果，可能是优先级更高的场景。

 

在车库门示例中，用如下方式来满足确定为构架驱动因素的质量属性场景，或对其进 行求精：

•对于产品线中的不同产品来说，用于幵门和关门的设备和控制装置是不同的。它

们可能包括来自家庭信息系统的控制装置。该场景被委派给用户接口模块。

 

•    在不同产品中使用的处理器是不同的。对于每个产品来说，应该可以直接从产品 线构架中得出特定于产品的构架。将该场景委派给所有的模块。每个模块都不能 使用标准编译器不支持的特定于处理器的特性。

 

•    如果个车库门在下降过程中检测到了障碍物（人或物体)，则门必须在0.1秒停止

 

(也可以重新打开)。该场景被委派给调度程序和陣碍物检测模块。

 

•    应该可以使用特定于产品的诊断协议，从家庭信息系统中诊断和管理车库门开关 器。该场景在诊断和通信模块之间进行了职责划分。通信模块负责用于与家庭信 息系统进行通信的协议，诊断模块负责管理涉及诊断的其他交互。

 

在本步骤结束时，模块被分解为其子模块，其中每个子模块都有一个责任的集合；并 拥有了一组用例、接口、质量属性场景以及限制集合。这足以开始分解的下一轮迭代。

 

请注意在该示例中，在一次迭代中取得了多少进展（或儿乎没有取得进展)：我们获 得了一个模块及其贲任的词汇：分析了各种用例和质量属性场換，并理解了它们的一些结 果。我们确定了模块及其交互的信息需要。应该在设计基本原理中捕获该信息，这将在第 9章进行讨论。然而，我们还没有确定大多数的细节。我们不知道用户接口模块和升/降门 模块之间进行交流的语言。我们不知道执行障碍物检测的算法。在任何细节上，我们都不 知道关键性能部分如何与非关键性能部分通信。

 

我们所做的工作已经进行了充分的定义，因此，如果设计大型系统，就可以分配工作 组，并授权他们进行管埋。如果设计小型系统（如车库门开关器），就可以直接进行下一 个迭代并确定这些问题的答案。