从用例到代码：用例分析(2)

　　整合所有的用例实现

　　建立跟踪机制

　　建立分析机制

　　对用例分析的结果进行评估

　　请注意这些步骤的次序不是一成不变的。 你实际所采用的次序取决于你对于分析的领域的理解程度、你对RUP或UML的经验、你所采用的模型、或者是你自己的确定分析类的属性的一种习惯方式。(例如，以职责为中心，以行为为中心，或者以数据为中心) 关键只在于你是否能够对问题建立一个准确的描述，而不是对我们的用例设计的准确描述--这将是本文的第二部分的内容)。我会遵循本文中的大多数(但不是全部)步骤，而且我会改变一些步骤的次序。在每个步骤的具体内容中，我会说明为什么这样做有助于RUP和OOAD的新手更好的学习OOAD。

　　如图3所示，一些步骤把编写用例和实现代码分隔开了。还列出了RUP中用例分析部分推荐使用的一些步骤。这张图将会指出在后面部分中，我们的前进方向。

　　图3：用例分析的步骤

　　用例分析第一步：建立一个用例实现

　　RUP中的用例分析过程的第一步是建立一个用例实现。在我们给出用例实现的定义之前，回过头来看一下，到底什么是用例?我们需要怎样来确认用例?我们写好的用例，是一个业务过程的描述，描述了顾客预约汽车的过程。它说明，我们会按照一些固定的步骤，按照固定的业务规则(例如在得到顾客的姓名之前不进行任何处理)，也不为顾客提供那些无法按照指定的时间地点供客户租用的汽车的信息。

　　由于我们是在设计一个面向对象的软件系统，我们的用例行为需要由我们系统中的一些对象和类来执行。但是迄今为止，我们还没有任何对象和类，因此我们需要从用例中去发现这些对象和类。还需要指定每个类要执行用例图中的哪些行为。

　　如图4所示，用例实现实际上是一组UML图，说明了我们都需要哪些类、它们的职责和它们的实例对象之间如何进行交互，来完成用例中的行为。

　　图4： 机票预订系统中的一个RUP用例实现

　　通常一个用例实现会由下面这些组成：

　　包括我们所关注的用例中出现的所有类的一个UML类图(有时也叫做合作类视图), 和描述交互的对象，以及它们之间的调用关系的一个或多个UML交互图 。UML定义了两种类型的交互图：顺序图 (如图4)，和协作图。都很有效。

　　看起来我们有很多事情需要处理，是这样吗?是的，而且当你使用诸如Rational Rose或Rational XDE这样的开发工具的时候，这项工作看起来更像一项家务管理工作，你只需要建立很多结构，存放你的用例实现。后面我们会完成实际的类和交互图。但是现在我们先来明确一下我们的目标：一个类图，一个或多个交互图。

　　用例分析第二步：补充用例描述

　　当你在进行分析的时候，你的用例描述只记录了从系统外面的用户角度来看，系统的行为是什么样子的。在概要的描述系统内部的一些不可见的操作的时候，这足够了，但是按照这样的描述，并不能完成具体的实现。

　　举一个例子，看看上面描述的第四步：系统列出在指定时间、地点和可用的所有符合条件的汽车。如果顾客需要某辆汽车的更详细的信息，系统也可以提供。在这里，我们有可供搜索汽车信息的数据库了吗?我们也许知道，汽车信息由CICS(客户信息控制系统)管理，存放在MVS主机上，通过LU6.2 APPC可以访问，但是我们不能确定这一点。让我们来把这些我们要做的事情，特别是在我们系统之外事情的细节，来清楚的确定下来，而不是只知道我们希望怎样做。下面是补充了这些信息的第四步，补充一个汽车数据库： 系统通过访问这个汽车数据库来查找汽车的位置信息，并列出在指定时间地点和可用的所有汽车。

　　这里我们给出了一个汽车数据库的信息，并且比较抽象的描述了如何用网页来访问它。这是一个很简单的例子，但是读者可以从中了解一些内容。

　　在RUP这样的迭代开发流程中，从分析阶段转移到设计阶段只用了很少的时间。对一个中等规模的，四周左右的项目来说，你可能第一周用来获取需求， 做你的分析和设计，然后后面3周都用来写代码和进行测试。你用于分析的用例会侧重于系统对外可见的行为，不过你可能需要细化这些用例的描述，增加更多的系统内部如何交互的描述。这样你的顾客和分析人员才能确认你没有遗漏一些重要的业务。请注意，只需要把用例描述细化到你可以很好的找出系统中的分析类的程度就可以了。 对于设计级别的类(诸如树、堆栈、队列、集合等等)可以在后面的阶段完成(如设计阶段)。

原文转自：http://www.uml.org.cn/Test/200904165.asp