设计一个方案

随后的阶段是用例分析，对于内部元素是如何交互来满足系统的功能需求，以及它们是如何相关，这个阶段提供了一个初始的、高级别的定义。这个分析需要进行反复的试验，直到产生满意的解决方案。“Analysis classes（分析类）”的行为通常是通过自然的语言描述的，比较抽象，在这个分析阶段中，它是一个有用的工具。分析类通常都不在软件中实现，虽然我们可以做到这一点，实际上，在总体设计过程中，分析类才会转换为精确定义的设计类和子系统。

　　我们首先要精心地制造顺序图，以便它们可以揭露出系统的内部运作，我们并不是通过展示角色和一个系统的交互来分析系统，而是将系统分解成独立的分析对象。系统的职责被分解到分析级别的对象中，以便可以得到一个更好的顺序图。在这里我们要介绍三种分析对象：

．边界对象

　　 边界对象代表系统的内部工作和它所处环境之间的交互。它包括有一个用户通过图形界面的交互，与其它角色的交互（例如代表其它系统的角色），和设备的交互等。边界对象将系统的其它部分和外部的相关事物隔离和保护起来。简单地说，每一个角色-用例交互对映射到一个边界对象。

. 实体对象

　　 实体对象代表系统的重要信息。在一个很长的时间内，它们都是持久和存在的。它们的主要目的是表达和管理系统中的信息。在模型中，系统中的关键概念以实体对象来表现。

. 控制对象

　　 控制对象是用来模型化系统中的行为的。控制对象并不需要实现这个行为，它可能是与其它对象协作以实现用例的行为。它的想法是为了将行为和模型下层的信息隔离开来，这样在处理以后的改变时就比较容易。

　　UML提供了stereotype符号，它表示为放在一个双角括号中的文本，以便和不同类型的类区别开来。在Rational Rose中，你可以很容易地创建分析类，只需将类的stereotype字段分别修改为< >, < >和< >就可以了。这些都可以作为创建分析级框图的基础。

　　付款用例顺序图的一个更新版本如图3所示，这里系统被分解为分析对象。在这个图中，使用图标来代表边界、控制和实体对象（分别以一个T、带箭头的圆圈和一个带切线的圆表示）。

　　当然，类通常都参与到几个用例中，因此为确保系统的一致性，理解它们的静态关系也是同样重要的。对于捕捉不同结构元素的静态模型，UML类图是很有用的。

　　首先，我们标识和放置用例中所有的类到一个类框图中。我们已经将用例的行为分布到对象中，所以要分析每个类的操作就变得相对简单了。要注意的是，这些是分析的操作，这意味着随着我们不断地进行分析和设计，这些操作将会不断地需要细化。

　　Rational Rose可让你很简单地在顺序图中的分析类上定义新的操作，你只要选择现有的信息，并且在菜单上选择 就可以了（如图3所示）。如果你已经定义了一个类的操作，你可以简单地由列表上选择现有的操作。

****图3：带有分析对象的精确顺序图****

　　这是Rational Rose中的一个典型方法，它可以提高用户的生产力，并且确保整个模型的一致性和质量，另一个类似的有用特性包括有查询模型哪个类和消息是没有解释的（例如在模型中没有映射到真正的类或者操作）。

　　还有一个方面是需要标识每个类的属性。属性代表的信息，可能是其它类需要的，也可能是类自身为履行自己的职责需要的。在这个分析阶段，应将属性标识为普通的类型，例如数字、字符串等。

　　要完成用例的类图，你还需要标识类间的关系。在这个阶段中我们特别感兴趣的关系是关联、依赖和继承。

　　在分析完所有的用例和为每个用例创建类框图后，我们就需要接合各种不同的分析类来得到一个统一的分析模型。这是一个重要的活动，因为我们需要得到一个最小集合的类，并且为了避免在最后的分析模型中出现不必要的冗余。

　　这个阶段的主要任务是标识在用例间重复出现的类或者只有很小改变的类。例如，对于跨用例间拥有类似行为或者表示同样概念的控制类，我们应该将它们合并。拥有同样属性的实体类也应该被合并，它们的行为也合并为一个类。

　　图4展示了一个初步分析级的类框图（这是根据图1的用例得到的）。由于我们现今只是关系类间的关系，所以我们使用Rational Rose的显示过滤能力来过滤掉每个类的细节（通过不勾选Format>Show all attributes和Format>Show all operations就可以了）。

**********图4************
初步分析级的类框图