分析类：边界类、控制类、实体类

1、边界类：

2、控制类：

并非所有用例都需要控制对象。例如，如果用例中的事件流与一个实体对象相关，则边界对象可能在与实体对象的协作中实现用例。

控制对象的示例包括诸如事务管理器、资源协调程序和错误处理程序之类的程序。

控制类提供如下行为：

• 不依赖于环境（环境更改时不更改），
• 定义用例中的控制逻辑（事件顺序）和事务。
• 在实体类的内部结构或行为发生变化的情况下甚少变化，
• 使用或设置几个实体类的内容，并因此需要协调这些实体类的行为。
• 每次激活时并不是以相同的方法执行（事件流有几个状态）。

确定是否需要控制类

用例的事件流定义了不同任务的执行顺序。从检查是否可以由已确定的边界类和实体类来处理流程开始。对于简单的事件流（主要是输入、检索和显示或修改信息），通常不必单独使用一个控制类；边界类将负责协调用例。

如果事件流较复杂，而且包含一些可能会独立于接口（边界类）或系统信息库（实体类）而变更的动态行为，则应该将该事件流封装在一个单独的控制类中。通过封装事件流，同一个控制类就可能由具有不同接口和信息库（或者至少底层数据结构不同）的各种系统重复使用。

3、实体类：

 实体类代表系统中的信息存储；通常使用它们来表示系统管理的关键概念。实体对象通常是被动的和持久的。它们的主要职责是存储和管理系统中的信息。

实体对象可以拥有和其他对象构造型同样复杂的行为。但是，与其他对象不同的是，该行为与实体对象所表示的特殊现象密切相关。

限制摘要

注：预定关联

对象有时需要知道，事件在某个“目标”对象中何时发生，而“目标”不必知道在事件发生时要求得到通知的所有对象。预订关联是显示这一事件通知依赖关系的简单表示法，它允许我们简洁明了地表示这种依赖关系。

两个对象之间的预订关联表明，当预订的对象发生特定事件时，将会通知预订方对象。预订关联有一个条件，定义使订户得到通知的事件。

“预订的”对象通常是实体对象。实体对象通常被动地存储信息，其任何行为一般都与它们的信息存储职责相关。许多其他对象常常需要知道对象实体何时更改。预订关联使实体对象不必了解所有这些另外的对象 － 它们只“表示”对实体对象感兴趣，并会在实体对象更改时收到通知。