面向对象开发中的本质用例及其职责（4）

讨论

在本章中，将讨论几个与本质用例相关的面向对象设计主题，包括：

· 无界面系统（实时系统）设计；

· 定制界面系统的设计；

· 迭代和增量开发过程；

· 界面和应用的并行开发；

· 基于业务过程的面向对象设计。

1.无界面系统（实时系统）设计

在实时系统和软件引擎中，系统只与系统主角交互，并且没有传统的人机界面，那么，能否采用本质用例呢？答案是肯定的。本质用例同样适用于这类系统。

在这类系统中，有一个重要概念就是“外部世界（outside world）”。在任何系统中，都需要对系统的内部和外部进行明确的划分，从而确定系统的边界；确定系统交互的原则（无论是人还是机器）；设计交互方式。我们发现，在这样的系统中，本质用例同样有许多优点。在适当的抽象层次上，本质用例摆脱了表达和实现的具体细节的束缚，能够更准确的捕捉用户意图和系统职责的本质，它不受具体系统类型限制，简洁明了，易于理解，便于编辑，方便复审，可以实现分析和设计的无缝连接和平滑过渡。

系统常常有一些附加的非功能性约束，例如响应时间、交换速率、信息容量、可靠性等。因为用例着眼于交互的过程，所以不是发现和确定这类需求的理想工具。但是，它可以帮助记录和管理这类需求。在常规用例方法中，通常采用文字描述的方法，并与用例同步管理，且其管理过程与用例结构无关。本质用例也可以采用类似的方法。在以用为中心的设计中，这类指标往往与本质用例相关，因为它们对高性能的用户界面设计至关重要。

本质用例的系统职责、系统对象的职责以及中间对象的职责之间的可追溯性弥补了系统设计的不足，保证系统满足这类非功能性指标的要求。例如，用例级的系统约束可以分解到对象中，对象的性能又直接影响到用例职责。采用公共任务标签的办法可以调整最终设计，确保满足非功能性指标要求。

2.定制界面系统

本质用例同样适用于已经定义好界面的情形。在这种情况下，我们先对界面进行分析，然后描述交互过程的本质用例，并在此基础上进行面向对象的设计。这样，从系统交互和职责的本质着眼进行设计的中间系统更稳定，更能够适应界面细节的变化，同样具有本质用例方法的主要优点。

3.设计业务流程

长期以来，常规用例被认为是业务流程建模的好方法，它主要描述的是业务单元（人）之间的交互，而不是计算机系统和人之间的交互过程。

本质用例与技术无关，它描述用例之中抽象的意图和任务，因此，无论采用何种界面技术，都可以实现用例。例如，采用相同的一个呼叫中心的用例，既可以支持用桌面应用的方法实现，也可以支持用Web的方式实现。还可以支持采用交互的语音提示的方法实现。这就是说，本质用例与采用何种技术途径无关，需要的仅仅是最基本的计算支持。

使用本质用例的成功经验告诉我们：本质用例既适用于软件设计，也适用于业务流程设计，它们在抽象、对话和任务中具有相同的优点。

4.开发过程

本节主要描述我们建立的软件设计模型，并为模型构建的过程提供参考。非常重要的是，从本质用例到系统对象，然后到面向对象的中间设计描述是开发的抽象过程，而不是构建模型的具体步骤，并不是类似于瀑布的过程，先对本质用例进行“分析”，接着确认其“完整性”和“正确性”，然后进行设计等等。

我们希望这个过程是一个增量的、可迭代的过程：先有一个备选用例表和一个初步的领域模型；其中的关键用例首先被细化，按用户意图和系统任务编写到用例卡片中；然后进行初步的设计，划分对象任务，并对用例的措词进一步细化和调整。再细化其它的用例，获得更多的对象模型，这些工作可根据后续工作中情况进行必要的复查和调整。

本质用例有助于软件开发的迭代过程，其抽象层次、用例与模型间的通用词汇决定了迭代开发的过程更易于跟踪，具有更好的一致性，对象和用例之间具有更良好的可追溯性。当设计完成时，所有的用例和对象都使用相同的词汇表，所有的系统任务被设计划分成适当的中间对象，所有的用例都可以被对象模型执行，能够更方便地检验设计和系统任务的一致性。

5.并行开发

在以用为中心的设计中，使用本质用例同样可以产生用户界面。在这种情况下，基于本质用例采用面向对象设计方法进行中间设计具有更加显著的优点。它可以避免重复工作：它设计的用户界面可以直接在软件设计中重用，无须重新捕捉和进一步细化，使软件设计和界面设计可以同步进行，只要二者同时支持本质用例就可以保证良好的一致性。

这和其它的过程方法（特别是RUP过程）略有不同，不需要在早期就完成界面设计，可以在软件设计阶段进行，支持软件设计和界面设计的同步进行，不会因为界面设计没有完成而延宕工期，可以有效地缩短项目周期，特别是在用户界面设计要求高、数量多的项目中，可以为整个项目节约好几个月的时间。

并行设计特别适合于Web系统的开发，前端界面和后台服务软件可以独立设计，并有专门的技术支撑其实现。在这样的并行开发过程中，要求对迭代过程进行有效地管理，协调设计过程中用例的变更和实现，使二者保持良好的一致性和可追溯性。

与其它方法的比较

软件开发技术在不断地向前发展，也提出了许多其它的手段和方法。在此，我们着重介绍它们处理需求和设计之间关系的不同方法。

面向对象的软件工程（OOSE）对建立对象模型中对象和用例之间的关系提出了许多有用的建议。Jacobson等人用系统边界、控制和实体对象实现用例的方法来建立分析模型，但是在分配系统行为和产生类（class）的过程，要求有一个附加的翻译过程。与这种方法相比，我们使用的本质用例方法具有更好的可操作性。

还有一些更简单和直接的方法来组织需求和进行面向对象设计。例如，在第二章中提到，Jacobson等人介绍用例概念，以及Lockwood提出在用例界面设计中使用本质用例方法就是基于这样的思想。还有许多指导用例写作及其在软件开发中具体应用的书籍。例如，Cockburn最近就出版了一本详细介绍用例写作方法的书籍，并对各种风格的用例进行了介绍。Amour和Miller还讨论作了为需求搜集工作的一部分，如何发现和管理用例。但是，这些工作很少提及用例如何在分析和设计阶段的工作中反映，讨论用例和设计关系的工作在领域模型的开发中完成，把领域模型作为设计和开发的第一步。领域模型固然非常重要，但是，从需求到发现领域模型、领域模型满足需求之间还应该有大量的工作需要完成。

大量的文献都提到可追溯性的重要性。Pfleeger指出，可追溯性包括横向和纵向的可追溯性。纵向的可追溯性是指开发过程中模型内部的关系，横向的可追溯性是指模型与模型之间的关系。加强系统的可追溯性可以有效地提高开发过程的质量和降低维护成本。

我们致力于需求与设计横向可追溯性的工作，将二者的关系直接反映到任务的分配中，成为设计工作的一部分。

任何软件开发方法都伴随相应的过程。最近经常提到的过程是Rational（瑞理公司）统一过程，即RUP。RUP是用例驱动的软件开发过程，用例连接开发过程的各个阶段。在我们使用的本质用例方法中，本质用例在开发过程中具有同等重要的地位，只是在用例格式的选择上有所差异。事实上，本质用例方法与RUP方法中用例的描述没有任何矛盾，甚至可以认为本质用例是基于前文中指出的OOSE方法中分析和设计工作流的细化。

还有一种开放式的软件开发过程，准确地说，它是一种软件开发方法的框架，而我们只关注其过程部分。特别值得关注的是它的开放式工具技术，为不同职责的软件开发需求提供完整的技术支持。它提供从原始需求到设计模型的技术，包括：协作分析技术、CRC卡片建模技术、委托分析技术、领域分析技术、泛化和继承技术以及对象模型转换技术等。上述所有技术都可以和我们的研究联系起来，而我们的工作在指导操作和提供可追溯性方面做出了贡献。

最近，轻量级方法XP等大行其道。基于XP方法的设计要求功能需求尽量简化，在真正需要以前，不轻易增加别的功能。XP是带有独立“用户故事”的增量开发过程（与用例类似但完全固化），通过再分解现存的程序实现用例，达到增量的目的。我们的方法与XP的方法也有所类似，所有的设计都可以再生。但在XP的方法中，当需要扩展支持新的用例时就需要重新设计，而在我们的方法中，设计从完整的系统目标出发，以实现整个系统为目的，所有的再分解都维持了对象的任务，都可以在中间组件之间重新进行分配。

结论

用例适用于各种软件的开发，本质用例起源于用户界面设计的细化和描述。我们尝试在面向对象的系统开发中使用本质用例，并在本文中进行了总结。

本质用例能够简单快速地发现需求，支持通过角色扮演进行沟通，有助于发现系统边界。它简明扼要，易于学习，避开了繁琐的实现细节，支持快速开发。使用这种方法易于确定用例模式。它还同时支持界面和系统设计，可以实现二者的并行开发。

本质用例标识系统任务，将需求和面向对象的设计联系起来。在设计中，其职责启发分配协作对象之间的抽象行为。使用本质用例描述需求，采用职责驱动的方法进行设计，可以更好地为设计提供指导，使设计和需求具有良好的可追溯性。