边界类、控制类、实体类

边界类、控制类、实体类分析类的构造型可分为以下几种：

· 边界类

· 控制类

· 实体类

/info/programme-uml/list-1.html

除了为您在查找类时提供更为具体的流程指南外，为类区分构造型还有助于建立一个强壮的对象模型，这是因为对模型进行的变更往往只会影响某一特定部分。例如，用户界面的变更仅会影响边界类。控制流的变更仅会影响控制类。长期信息的变更仅会影响实体类。不过，这些构造型的最大作用还是帮助您在分析和初期设计阶段中辨识类。在设计阶段的后期，您可能要考虑使用一组略有不同的构造型，以便更好地将其与实施环境、应用程序类型等联系起来。

边界类

边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。这种交互包括转换事件，并记录系统表示方式（例如接口）中的变更。

边界类对系统中依赖于环境的那些部分进行建模。实体类和控制类对独立于系统外部环境的那部分进行建模。因此，如果更改 GUI 或通信协议，将只会更改边界类，对实体类和控制类则毫无影响。

由于明确了系统的边界，边界类能帮助人们更容易地理解系统。在设计时，它们为确定相关服务提供了一个好的起点。例如，如果在设计初期就确定了一个打印机接口，很快您即会发现您必须对打印输出的格式也进行建模。

常见的边界类有窗口、通信协议、打印机接口、传感器和终端。如果您在使用 GUI 生成器，您就不必将按钮之类的常规接口部件作为单独的边界类来建模。通常，整个窗口就是最精制的边界类对象。边界类还有助于获取那些可能不面向任何对象的 API（例如遗留代码）的接口。

您应该根据边界类所表示的边界类型来对边界类建模。与其他系统进行通信和与人员主角进行通信（通过用户界面）在目的上大有不同。在用户界面建模中，最需要关注的是如何向用户显示界面。而在系统通信建模中，最应关注的是通信协议。

边界对象（即边界类的一个实例）的生存期可以比用例实例的生存期更长。举例来说，边界对象必须在两个用例执行之间的一段时间显示在屏幕上时就符合这种情况。但是，通常情况下二者的生存期一样长。

查找边界类边界类帮助系统接口与系统外部进行交互。边界对象将系统与其外部环境的变更（与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他部分造成影响。

一个系统可能会有多种边界类：

· 用户界面类 - 帮助与系统用户进行通信的类

· 系统接口类 - 帮助与其他系统进行通信的类

· 设备接口类 - 为用来监测外部事件的设备（如传感器）提供接口的类

查找用户界面类表示用户界面的边界类可能在用户界面建模活动期间存在；只要合适，就可在此活动期间重复使用这些类。如果尚未进行用户界面建模，那么下面进行的讨论将有助于查找这些类。

每个用例主角对都至少有一个边界类。可以认为此对象担负着协调与主角之间的交互的职责。此边界对象有一些辅助对象，边界对象将它的某些职责委派给这些辅助对象。这对于基于窗口的 GUI 应用程序来说更是如此。在这些应用程序中，通常每个窗口或窗体都对应一个边界类。

制作用户界面原型的草图或者对之进行屏幕转储，借此来展示边界对象的行为和外观。

仅对系统的核心部分建模，不要对 GUI 中的每个按钮、列表和小部件都建模。分析的目的是要大致了解系统是如何构成的，而不是要设计每一个细枝末节。换句话说，您只需为系统中的一些现象或者在用例实现的事件流中提及的一些事物确定边界类。另请参见指南：边界类（用户界面建模）。

查找系统接口类与外部系统通信的边界类负责管理与外部系统的对话，它为正在构建的系统提供与该外部系统的接口。

示例：

在自动柜员机中，提款必须通过 ATM 网络（一个主角）得到验证，然后该网络再通过银行会计系统对提款进行验证。我们可以确定让一个称为 ATM 网络接口的对象来提供与ATM 网络之间的通信。

与现有系统的接口可能已有明确定义。如果是这样，即可从接口定义中直接推导出职责。如果已经有一个正式的接口定义，则可对它实施逆向工程，这样就不必在此正式界定它。只需记下这一点，说明现有接口将在设计阶段中复用。

查找设备接口类系统中有些元素的行为使它们看起来象是外部元素（没有受到系统中任何对象的影响就自发地改变值），例如传感器装置。尽管可以用主角来表示这类外部设备，但系统用户发现这样做会造成一些“混乱”，因为这很可能造成对设备和真人主角“等

同”对待。但是，一旦我们不再收集需求，我们就需要考虑所有外部事件的来源，并确保我们有办法让系统检测这些事件。

如果在用例模型中用主角来表示设备，那么对使用边界类来帮助设备与系统通信这种做法验证其合理性就很容易了。如果用例模型中没有这些“设备主角”，那么现在正是添加它们的时机，同时还需在适当的地方对用例补充说明进行更新。

为每个“设备主角”创建一个边界类，用来获取该设备或传感器的职责。如果设备已经有一个明确定义的接口，记下这一点，以便以后设计时引用它。

控制类

控制类用于对一个或几个用例所特有的控制行为进行建模。控制对象（控制类的实例）通常控制其他对象，因此它们的行为具有协调性质。控制类将用例的特有行为进行封装。

控制对象的行为与特定用例的实现密切相关。在很多场景下，您甚至可以说是控制对象“掌握”着用例的实现。但是，如果用例任务之间联系很紧密，有些控制对象就能参与多个用例实现。此外，不同控制类的多个控制对象可以参与同一个用例。不是所有用例都需要控制对象。例如，如果某个用例的事件流与一个实体对象相关，那么边界对象就可能在该实体对象的协助下实现这个用例。您可以首先为每个用例实现确定一个控制类，接着，在确定了更多的用例实现并发现更多的共性后，再对其进行改进。

因为控制类能够表示系统的动态行为，处理主要的任务和控制流，所以它们可以帮助理解系统。

当系统执行用例的时候，就产生了一个控制对象。控制对象经常在其对应用例执行完毕后消亡。

注意：控制类并不能处理用例需要执行的一切事务。相反，它协调其他用来实施此功能的对象的活动。控制类将工作委派给已被指定负责此项功能的对象。

查找控制类控制类用于在系统中协调行为。系统可以在没有控制对象的情况下执行某些用例（仅使用实体对象和边界对象），尤其是那些只需对已存储信息进行简单处理的用例。

较复杂的用例一般都需要一个或多个控制类来协调系统中其他对象的行为。控制对象的示例有：事务管理器、资源协调器和错误处理器。

控制类有效地将边界对象与实体对象分开，让系统更能适应其边界内发生的变更。这些控制类还将用例所特有的行为与实体对象分开，使实体对象在用例和系统中具有更高的复用性。

控制类所提供的行为具有以下特点：

· 独立于环境（不随环境的变更而变更）。