用况驱动过程

统一过程的目标就是指导开发人员有效地实现并实施满足客户需求的系统。用况几乎普遍用于捕获软件系统的需求。但用况不只是捕获需求的工具，它们还能驱动整个开发过程。对于每一次迭代，用况驱动完成一整套工作，并把这些不同的工作结合在一起。

• 首先，开发人员捕获客户需求作为用况模型中的用况。
• 然后分析并设计系统来满足这些用况，这样便首先创建了一个分析模型，然后时设计模型和实施模型；进而在实现模型中实现该系统。
• 最后，开发人员准备一个cesium模型来验证系统是否能够提供用况中描述的功能。

所有模型通过跟踪依赖关系而互联关联。

用况驱动开发概述

需求捕获有两个目标：发现真正的需求并以适于用户、客户和开发人员的方式加以表示。

• 真正的需求：是指在实现时可以给用况带来预期价值的需求。
• 以适于用户、客户和开发人员的方式加以表示：主要时指对需求的最后描述必须能够让用户和客户理解。

一个系统通常有多种用户，每种用户表示为一个参与者。参与者在与用况进行交互时使用用况。用况时系统为了向参与者提供某些有价值结果而执行的动作序列。系统的所有参与者和用况构成用况模型。

用况模型作为输入来创建分析模型。用况模型中的每个用况都时限为分析模型中的用况实现。用况和用况实现的对偶性支持需求和分析之间的无缝可跟踪行。通过对用况进行处理，开发人员可以确定参与实现用况的类。开发人员将用况中定义的职责分配为类的职责。这样，我们能确保得到一个类的集合，这些类何在一起可以实现真正时用户所需要的用况。分析模型时需求的详细的规格说明，并可作为设计模型的切入点。开发人员使用该模型将用况精化为概念性类元间的协作，以便更准确地理解这些用况。分析模型还用于创建大量可重用构件的、健壮的柔性系统（包括架构）。分析模型与设计模型不同，它是一个giant模型而不是实现蓝本。分析模型的用况实现与设计模型中相应的用况实现之间存在一种无缝关系。分析模型中每个元素都可以哦那个实现它的设计模型的元素中跟踪到。分析模型和设计模型都是由类元和说明如何实现用况的用况实现集合组成的。UML具有很多种类元：子系统、类、接口、参与者、用况、构件和节点。

然后，开发人员设计类和用况实现，以便更充分地利用实现系统的产品和技术。按照子系统对射击类进行分组，并定义这些子系统间的接口。开发人员还要进一步建立实施模型，其中包括定义可计算节点上系统的物理结构和验证用况能够时限为可运行与这些节点上的构件。设计模型有一下特点：

• 设计模型时有层次的，但也包括跨越层次的关系。
• 用况实现时协作的构造型。协作表示类元在做某件友谊的事情时如何参与和充当角色。
• 设计模型还是实现的蓝图。在设计模型的子系统和实现模型的构件之间存在直接的映射关系。

然后，开发人员把设计好的类实现为实现模型中的文件构架集合，从中能够生产可自行代码。用况有助于开发人员决定实现和集成构件的顺序。

最后，在测试工作流期间，测试人员验证系统确实能够实现用况中所描述的功能和满徐系统需求。测试模型包含测试用例。测试用例定义了输入、运行条件和结果的集合。很多测试用例可以直接从用况中得到，因此，在测试用来和相应的用况之间存在跟踪依赖关系。测试可以在开发周期的初期进行规划。议案捕获到用况，就可以详细说明用况的测试（“黑盒”测试），并决定实现、集成和测试它们的次序。当用况在设计阶段实现后，可以进一步细化用况的测试（“白盒”测试）。每种执行用况的方式都是一个候选的测试用例。

为什么使用用况？

两个主要原因：

• 它们着眼于为用户增加价值，提供了一种捕获功能需求的系统而且直觉的方法。
• 它们可驱动整个开发过程。

为了捕获附件的需求上的价值

用况所提供的视角补充了软件工程的最终目标：创造的产品可以让客户做有用的工作。之所以如此有一下几个原因：

• 用况的构造有利于识别满足用户目标的软件，用况时系统向其用户提供的增值功能。用况使我们将注意力集中于理解系统怎样才能适用于每个用户，指导我们找出每个用户所需要的功能，它还有助于我们避免提出用户根本就不需要的多余功能。
• 用况很直观，这使它更易于阅读用况描述和提出修改建议。

用况模型用来与用户和客户在“系统应该为用户做什么”方面达成共识。可以认为i用况模型使所有可能使用系统的方式的完整的规格说明。用况模型通过定义系统必须为用户做的事情来界定系统。

为了驱动过程

用况不仅启动一个开发过程，而且将其结合为一个整体。

用况有助于项目精力规划、分配和监控开发人员所执行的多个任务。对于每个用况，项目精力可以表示出一些任务。表示、设计和测试每一个用况都分别是一个任务。项目精力可以估算这些任务需要的工作量和时间。根据用况确定的任务有助于项目精力顾及项目的规模和所需要的资源，然后把这些任务分配给该项目的开发人员。

用况使保证所有模型具有可跟踪性的一种重要机制。需求阶段的一个用况可以跟踪到在分析和设计阶段的实现，还可以跟踪到参与实现它的所有类、构件以及最后用来验证该用况的测试用例。这种可跟踪性使项目管理的一个重要方面。当用况发生变化时，必须对相应的实现、类、构件和测试用例进行核查以便更新。用况和其他模型元素之间的可跟踪性，可以更加容易地保持系统的完整性和保证系统与需求变更的一致性。

为了设计构架以及其他

用况有助于迭代开发。

用况有助于设计构架。在最初的几次迭代中，通过选择实现适当的用况集合，便可以用一个稳定额构架来实现那一个系统，该构架可以用于多个后续的开发周期。

用况还可作为编写用户手册的起点。

通过估计执行用况时通过不同路径的频度，可以估计那条路径需要最佳性能。可以用来衡量底层硬件的处理器能力或优化某类应用时的数据库策略。还可以用来获得良好的可用性。

捕获用况

在需求工作流期间，我们标识用户和客户的需要作为需求。将功能性需求表示为用况模型中的用况，其他的需求或者“附加到”与之相关的用况上，或者放到一个单独的列表中，或者以其他某种方式描述。

用况模型表示功能性需求

用况模型帮助客户、用户和开发人员在如何使用系统方面达成共识。大多数系统具有多种类型的用户。每类用户表示为一个参与者。参与者在与用况进行交互时使用系统。系统所有的参与者和所有用况组成用况模型。一张用看图描述部分用况模型，显示带有关联瓜西的用况和参与者的集合。

参与者时系统的环境

每个参与者在与系统交互时均充当一系列相应的角色。一个真正的用户可以作为一个或几个参与者，几个用户可以作为一个用户的不同出现而充当同一个参与者。

参与者在执行用况时通过向系统发送消息或从系统接受消息来与系统进行通信。当我们明确了参与者和用况应该分别做什么时，便可以在参与者的职责和系统的职责之间进行清晰划分，以便帮助我们限定系统的范围。

通过考虑哪些用户将使用该系统以及哪些其他的系统必须与该系统发生交互，就可以发现并详细说明所有的参与者。

用况确定系统

确定用况是为了满足用户在使用系统时的需要。

用况规定了一个动作序列（可以有多种实现），系统可以执行这些动作并产生出一个对于特定参与者有价值的可见结果。

通过考虑用户如何使用系统完成他们的工作来发现用况。每个能够对用户增值的系统使用方式就是一个候选用况。然后对这些候选用况进行消息说明、改变、划分为更小的用况或结合成更加完整的额用况。当以客户、用户和开发人员都能理解的方式正确地捕获了全部功能性需求时，用况模型便基本上完成了。当我们说规定和描述一个用况时，意味着规定和描述了实际上定位相同用况的各种路径。

用况还可以用来说明非功能性需求。

总之，所有的功能性需求确定为用况，非很多非功能性需求可以附加到这些用况上。

实现用况的分析、设计和实现

根据用况建立分析模型

对于每次迭代，选择一组在用况模型中描述的用况。我们将系统构造称为一些类元以及这些类元间关系的结构。我还要说明实现这些用况的协作关系，即用况实现。

可能以及存在一个构架来指导我们发现新的类元和宠用已有的类元。每个类元在一个用况实现中充当一个或几个角色。每个类元角色详细说明该类元参与实现某个用况的职责和属性等。

在分析模型中使用了关于类的三种不同构造型：

• 边界类：用于建立系统与其参与者间交互的模型。
• 控制类：通常用于表示协调、排序、事务处理以及其他对象的控制，并且它还经常用于封装与特定用况有关的控制。
• 实体类：一般用于建立长效且持久的信息模型。

通常，我们从考察一些用况、为它们建立用况实现并确定类元的角色开始。然后对更多的用况重复同样的工作并确定新的类元角色。之后的一些角色可以认为时已确定类元的新的或变更的角色，而另一些角色需要新的类元。至此我们确定了一个系统结构。以及明确了所设计的类元的职责，并建立了类元之间的关系。我们以及创建了结构，但现在需要在结构上实现用况。

每个用况均对应一个用况实现，每个用况实现都包含一个充当不同角色的类元集合。俩就交互模型意味着要说明如何执行或运行一个用况实例。在分析中我们主要使用协作图来建立对象间交互的模型。作为对协作图的补充，开发人员还可以用文本来解释对象如何执行用况的事件流。

每个类必须履行其所有的协作角色

一个类的职责就是该类在所有用况实现中的角色的汇集。将角色集中起来并去掉其重叠的部分，就可以得到该类的所有职责和属性的规格说明。

复杂分析和实现用况的开发人员的责任时确定类的角色。复杂一个类的某个开发人员把这个类的所有角色汇集为该类的一个完整的职责集合，然后将它们集合成为一个一致的职责集合。

复杂分析用况的开发人员必须却博爱这些类能够恰当的实现用况。如果某个类发生了变化，该类的开发人员必须验证它仍然能够在用况实现中充当所要求的角色。如果用况实现中的某个角色发生了变化，用况开发人员必须将这种变化通知该类的开发人员。因此，角色可以帮助类的开发人员和用况的开发人员维持分析的完整性。

根据分析模型建立设计模型

设计模型是通过使用分析模型作为主要输入而被创建的，并应使它是哦那个与所选的实现环境。

与分析模型类似，设计模型也要定义类元、这些类元间的关系以及实现这些用况的协作。

分析模型中的用况实现可以跟踪到设计模型中的用况实现。

当设计分析类时，会确定和到处更多应用于实现环境的精化后的设计类。大多数设计类通常指跟踪一个分析类。所以由分析模型所定义的系统结构在设计期间自然保留下来。

主动类表示系统分布时由它组织其他类的工作过程。

在设计模型中，我们必须详细表示设计对象之间在实现用况时发生的交互。我们主要采用顺序图来建立设计过程中对象间交互的模型。

按子系统对类分组

如果类数量较多，可以按照子系统进行分组。子系统使对类或其他子系统在语义上有益的分组。子系统提供和使用一个接口的集合。这些接口定义了子系统的语境。

底层的子系统成为服务子系统，这是因为它们的类实现了一种服务。服务子系统构成了一个可管理的任选的功能单位。

子系统可以自底向上或自顶向下设计：

• 当自底向上进行处理时，开发人员基于已确定的类来考虑和设计子系统；他们所设计的子系统将这些类封装到明确定义功能的单元内。
• 自顶向下处理时，构架设计师在确定其他类之前首先要确定高层的子系统和接口。然后开发人员处理哥哥子系统的任务，确定并设计子系统内的类。

根据设计模型建立实现模型

在实现工作流期间，我们需要开发能够产生可执行系统的制品：可执行的构件、文件构件、表构建等。一个构件时系统中一个实际的且可替换的部分，它符合提供接口集合的实现。

实现模型由构件组成，包括所有的可执行体，以及其他类型的构件。

构件设定了一个由其接口定义的构架语境。

通常有一种简明的方式将设计模型中的一个服务子系统时限为可分配到实施模型中节点上的若干构件。

但是实现工作不只是开发源代码以建立一个可运行的系统。负责实现构件的开发人员在将它交付进行集成和系统测试之前还要完成单元测试。

用况的测试

在测试期间，需要验证系统是否正确实现其规格说明。建立一个包括测试用例和测试规程的测试模型，并执行测试规程以确保系统按照预期的方案工作。

• 测试用例时测试输入、运行条件和针对具体目标指定的预期结果的集合。
• 测试规程是寡欲如何对具体的测试用例进行设置、运行和评估结果的规格说明。

用况测试可以从参与者的角度来执行，此时将系统作为一个黑盒看待；或者从设计的角度执行，此时所构造的测试用例用来验证用况实现中涉及到的类的实例能够完成它们应该做的工作。

小结

用况驱动过程。

在需求工作流期间，开发人员可以将需求表示为用况，接着项目经理便可以根据开发人员确定的用况来规划项目。

在分析和设计期间，开发人员按照类或子系统来创建用况实现。

然后开发人员实现构件，并将构件集成到每次实现用况集合的增量结果中。

最后测试人员验证系统是否正确实现了用户的用况。

用况将所有开发活动连接成为一个整体，并驱动力开发过程。