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

　　UML 说明：UML中的类在图上分为三段，以Account类为例，如下图所示：

　　图8中的类图上展示了汽车租借的分析类、它们之间的关系以及每个类所拥有的一些基本的属性。这些属性是由类的职责推理得到的一些很明显的属性。请注意这些属性都没有表明数据类型，因为数据类型是设计阶段的问题。

　　图8： 类属性的起点

　　在当前这一步中，我们只需要表明顾客类具有一个叫做地址的属性就足够了。至于地址这个属性是什么样的，甚至需要不需要成为一个独立的地址类，会在后面的阶段中决定。你会发现汽车租借类还没有属性，它会变成系统的一个对外的接口。而汽车数据库需要哪些属性，则还根本没有决定。今后的阶段会解决这些问题。

　　用例分析第八步：验证分析机制

　　分析机制指的是高级的系统构建组件，它可以提供解决特定领域问题所需要的一些服务，而不是技术方面。例如，在保险领域，保单中的信息、声明和其它内容，在整个保险管理期间都是需要的。这个需求用分析机制来说，就叫做：持久化：无论程序是否运行，都一直维护数据的信息和状态。请注意我们并没有指定使用Oracle SQL，或是SQL Server这些特定的实现环境，我们只是列出了持久性，和我们后面会谈到的设计机制和实现机制。实现机制将会是与特定平台或者软件供应商相关的。

　　我们在表4中试着举例说明，分析、设计和实现机制之间的关系：

　　表4： 说明，分析、设计和实现机制之间的关系

　　一些通用的分析机制是：

　　持久性

　　通讯(进程之间，或是应用程序之间)

　　意外处理

　　事件通知机制

　　消息

　　安全

　　发布(也就是说，被发布的对象)

　　遗留的系统接口

　　在汽车租借系统中，我们需要为这些指定分析机制：

　　结论

　　在“从用例到代码”的第一部分中，我们从一个用例开始，迄今为止已经找出了用来实现用例的类，它们之间的关系，和它们需要的属性。我们还找出了一些分析机制，在今后的设计和实现中会用到它。

　　如果我们对另一个用例再一次重复这整个过程，我们会发现另一些分析类，定义它们的职责，它们之间的关系。也许还会发现一些新的分析机制，画出新的协作图或是顺序图，来说明这些类如何交互。这演示了RUP过程的递增的特点：每个任务，每次迭代，都是在前面工作的基础之上进行的。

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