三、用例实现

　　目前我们已经把握了重点用例，现在则要“实现”用例。用例的实现指的是对每个用例所进行的详细系统过程的说明，在这个过程中，我们以UML的方法给出了类图设计、顺序图、状态图，甚至包括UI设计和E-R设计等等，目的是为系统进一步的详细设计提供概念上的依据和设计参照。

　　1、“创建订单”用例

图1： Stamp DIY Physical Object Model

　　图1中的业务关系类图，我们有如下描述：

　　a. 订单Order和订单行OrderDetail是组合关系。订单Order和OrderDetail构成上下级别的一对多关系，它们拥有着一致的生命周期。

　　b. 产品目录Catalog和目录项Catalogitem也是组合关系，拥有一致的生命周期。

　　c. 客户Customer和Order 形成关联类，二者构成强制关系， 即客户类Customer不存在的情况下，订单类Order是不存在的。

　　d. 客户Customer从本质上是一种角色Role，所以客户Customer可以视为Role角色的子类，Customer继承了Role的属性。

　　我们在设计域类通常会遵循一些基本的设计准则，如下：

　　封装——封装是一种设计准则，规定了数据和程序逻辑包含在一个独立的单元中。

　　导航可见性——是一种设计准则，指一个对象可以看到另一个对象并与之交互。

　　设计的任务之一是说明哪个对象对哪个对象有导航可见性，它可以是单向或双向的。如图1，一个Customer对象可以看见一个Order对象，它意味着Customer对象可以知道客户发出了哪些订单。在程序里，Customer类通常会用一个变量或数组来指向这个客户的一个或多个Order对象。在设计类图中，导航可见性用类之间的箭头表示，箭头指向可见的类。

　　耦合——它来自于导航可见性，如图一，Ｃustomer对Ｏrder是可见性的，则它们是耦合的，同样，Ｏrder对ＯrderDetail也具导航可见性，它们也是耦合的。

　　耦合是对设计类图中的类与类之间连接关系的紧密程度的定性的度量。一种比较容易理解耦合的方法是看设计了类图的导航箭头的个数，比如Customer对Order是耦合的，Order对OrderDetail是耦合的，这些是正常的设计。但如果把Customer加入到对OrderDetail的导航可见性则是强耦合的类型，这样的设计会降低系统的维护性。

　　通常，有经验的分析员会尽量简化耦合，并减低对新系统设计的影响。

　　聚合与任务分解——指的是一个类中各种功能的一致性，它是对一个类中目的单元或主题的定性度量。

　　我们需要的是高聚合的类设计， 因为低聚合的类不容易维护，重用度低。在图1中，我们把客户，订单和购物车分解成几个高聚合的类．为解决低聚合的类通常采用的分成几个高聚合类的方法是为任务分解，它是另一个面向对象设计的准则。

图2： DB Schema