边界类、控制类、实体类

《边界类、控制类、实体类》由会员分享，可在线阅读，更多相关《边界类、控制类、实体类（8页珍藏版）》请在金锄头文库上搜索。

1、边界类、控制类、实体类分析类的构造型可分为以下几种：边界类控制类实体类http:/ 壮的对象模型，这是因为对模型进行的变更往往只会影响某一特定部分。例如，用户界面的 变更仅会影响边界类。控制流的变更仅会影响控制类。长期信息的变更仅会影响实体类。不 过，这些构造型的最大作用还是帮助您在分析和初期设计阶段中辨识类。在设计阶段的后期, 您可能要考虑使用一组略有不同的构造型，以便更好地将其与实施环境、应用程序类型等联 系起来。边界类边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。这种交互 包括转换事件，并记录系统表示方式（例如接口）中的变更。边界类对系统中依赖于环境的那些部分进行建模

2、。实体类和控制类对独立于系统外部环 境的那部分进行建模。因此，如果更改GUI或通信协议，将只会更改边界类，对实体类和 控制类则毫无影响。由于明确了系统的边界，边界类能帮助人们更容易地理解系统。在设计时，它们为确定 相关服务提供了一个好的起点。例如，如果在设计初期就确定了一个打印机接口，很快您即 会发现您必须对打印输出的格式也进行建模。常见的边界类有窗口、通信协议、打印机接口、传感器和终端。如果您在使用GUI生 成器，您就不必将按钮之类的常规接口部件作为单独的边界类来建模。通常，整个窗口就是 最精制的边界类对象。边界类还有助于获取那些可能不面向任何对象的API（例如遗留代码） 的接口。您应该根据

3、边界类所表示的边界类型来对边界类建模。与其他系统进行通信和与人员主 角进行通信（通过用户界面）在目的上大有不同。在用户界面建模中，最需要关注的是如何 向用户显示界面。而在系统通信建模中，最应关注的是通信协议。边界对象（即边界类的一个实例）的生存期可以比用例实例的生存期更长。举例来说, 边界对象必须在两个用例执行之间的一段时间显示在屏幕上时就符合这种情况。但是，通常 情况下二者的生存期一样长。查找边界类边界类帮助系统接口与系统外部进行交互。边界对象将系统与其外部环境的 变更（与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其 他部分造成影响。一个系统可能会有多种边界类：用

4、户界面类-帮助与系统用户进行通信的类系统接口类-帮助与其他系统进行通信的类设备接口类-为用来监测外部事件的设备（如传感器）提供接口的类査找用户界面类 表示用户界面的边界类可能在用户界面建模活动期间存在;只要合 适，就可在此活动期间重复使用这些类。如果尚未进行用户界面建模，那么下面进行的讨论 将有助于查找这些类。每个用例主角对都至少有一个边界类。可以认为此对象担负着协调与主角之间的交互的 职责。此边界对象有一些辅助对象，边界对象将它的某些职责委派给这些辅助对象。这对于 基于窗口的GUI应用程序来说更是如此。在这些应用程序中，通常每个窗口或窗体都对应 一个边界类。制作用户界面原型的草图或者对之进行

5、屏幕转储，借此来展示边界对象的行为和外观。仅对系统的核心部分建模，不要对GUI中的每个按钮、列表和小部件都建模。分析的 目的是要大致了解系统是如何构成的，而不是要设计每一个细枝末节。换句话说，您只需为 系统中的一些现象或者在用例实现的事件流中提及的一些事物确定边界类。另请参见指南： 边界类（用户界面建模）。査找系统接口类与外部系统通信的边界类负责管理与外部系统的对话，它为正在构建的系统提供与该外部系统的接口。示例：在自动柜员机中，提款必须通过ATM网络（一个主角）得到验证，然后该网络再通过 银行会计系统对提款进行验证。我们可以确定让一个称为ATM网络接口的对象来提供与 ATM网络之间的通信。与

6、现有系统的接口可能已有明确定义。如果是这样，即可从接口定义中直接推导出职责。 如果已经有一个正式的接口定义，则可对它实施逆向工程，这样就不必在此正式界定它。只 需记下这一点，说明现有接口将在设计阶段中复用。査找设备接口类 系统中有些元素的行为使它们看起来象是外部元素（没有受到系统 中任何对象的影响就自发地改变值），例如传感器装置。尽管可以用主角来表示这类外部设 备，但系统用户发现这样做会造成一些“混乱”，因为这很可能造成对设备和真人主角“等 同”对待。但是，一旦我们不再收集需求，我们就需要考虑所有外部事件的来源，并确保我 们有办法让系统检测这些事件。如果在用例模型中用主角来表示设备,那么对使用

7、边界类来帮助设备与系统通信这种做 法验证其合理性就很容易了。如果用例模型中没有这些“设备主角”，那么现在正是添加它 们的时机，同时还需在适当的地方对用例补充说明进行更新。为每个“设备主角”创建一个边界类，用来获取该设备或传感器的职责。如果设备已经 有一个明确定义的接口，记下这一点，以便以后设计时引用它。控制类控制类用于对一个或几个用例所特有的控制行为进行建模。控制对象（控制类的实例） 通常控制其他对象，因此它们的行为具有协调性质。控制类将用例的特有行为进行封装。控制对象的行为与特定用例的实现密切相关。在很多场景下，您甚至可以说是控制对象 “掌握”着用例的实现。但是，如果用例任务之间联系很紧密，

8、有些控制对象就能参与多个 用例实现。此外，不同控制类的多个控制对象可以参与同一个用例。不是所有用例都需要控 制对象。例如，如果某个用例的事件流与一个实体对象相关，那么边界对象就可能在该实体 对象的协助下实现这个用例。您可以首先为每个用例实现确定一个控制类，接着，在确定了 更多的用例实现并发现更多的共性后，再对其进行改进。因为控制类能够表示系统的动态行为，处理主要的任务和控制流，所以它们可以帮助理 解系统。当系统执行用例的时候，就产生了一个控制对象。控制对象经常在其对应用例执行完毕 后消亡。注意：控制类并不能处理用例需要执行的一切事务。相反，它协调其他用来实施此功能 的对象的活动。控制类将工作委

9、派给已被指定负责此项功能的对象。査找控制类 控制类用于在系统中协调行为。系统可以在没有控制对象的情况下执行 某些用例（仅使用实体对象和边界对象），尤其是那些只需对已存储信息进行简单处理的用 例。较复杂的用例一般都需要一个或多个控制类来协调系统中其他对象的行为。控制对象的 示例有：事务管理器、资源协调器和错误处理器。控制类有效地将边界对象与实体对象分开，让系统更能适应其边界内发生的变更。这些 控制类还将用例所特有的行为与实体对象分开，使实体对象在用例和系统中具有更高的复用 性。控制类所提供的行为具有以下特点：独立于环境（不随环境的变更而变更）。确定用例中的控制逻辑（事件顺序）和事务。在实体类的内

10、部结构或行为发生变更的情况下，几乎不会变更。使用或规定若干实体类的内容，因此需要协调这些实体类的行为。不是每次被激活后都以同样的方式执行（事件流具有多种状态）。确定是否需要控制类 用例的事件流决定了不同任务的执行顺序。首先，调查事件流 是否能由已确定的边界类和实体类进行处理。对于主要是为了输入、检索、显示或修改信息 的简单事件流来说，通常不必单独使用一个控制类，将由边界类负责协调用例。如果事件流较复杂，而且包含一些可能会独立于接口（边界类）或系统信息库（实体类） 而变更的动态行为，则应该将该事件流封装在一个单独的控制类中。通过封装事件流，同一 个控制类就可能由具有不同接口和信息库（或者至少基础

11、数据结构不同）的各种系统重复使 用。示例：管理任务队列您可从库房管理系统的执行任务用例中确定一个控制类。该控制类处理一个任务队列， 保证任务按照正确的顺序来执行。一旦分配好运输工具后，它就执行队列中的下一个任务。 因此，系统可以同时执行多个任务。如果将由其对应的控制对象定义的行为分为两个控制类（Task Performer和Queue Handler），那么说明此行为就会更加容易。Queue Handler对象将只处理队列顺序和对运 输工具的分配。整个队列只需一个Queue Handler对象。一旦系统要执行某个任务，它就 会产生一个新的Task Performer对象来执行该任务。所以，系统

12、所执行的每个任务都需要 个 Task Performer 对象。复杂的类应按照类似职责进行划分这种划分的主要好处在于：我们将队列处理职责（许多用例中都有的职责）从任务管理 的特有活动（该用例所特有）中分离出来。这使得理解类更加容易，而且更易于随着设计的 成熟而进行修改。这还有益于保持系统的负载平衡，因为只要有处理负载的需要，就可以创 建足够的Task Performer来处理工作量。将主事件流和备选/异常事件流分别封装在不同的控制类中 为了简化变更，将主事 件流和备选事件流封装于不同的控制类中。如果备选事件流和异常事件流完全独立，那么将 它们也分开。这会方便系统以后的扩展和维护。如果两个主角共

13、享同一个控制类，则应划分控制类如果多个主角使用同一个控制类，那么可能也需要划分控制类。通过这种方法，我们将一个主角需求的变更与系统的其他 部分隔离开。如果变更成本很高，或后果非常严重，您就应该找出所有与多个主角相关的控 制类，并对它们进行划分。理想情况下，每个控制类应该最多只与一个主角进行交互（通过 一些边界对象）。示例：电话通话管理以用例市内电话为例。我们首先确定一个控制类来管理通话。用来控制电话系统中市内电话的控制类可以很快地分为两个控制类:A行为和B行为， 分别对应于各自的主角。在市内通话中，有两个主角：拨打电话的A用户和接听电话的B用户。A用户拿起话 筒，听到拨号音，然后拨打电话号码。

14、系统立即存储号码并进行分析。系统接收到号码的所 有数字后，将振铃音发往A用户，同时向B用户发出振铃信号。B用户拿起话筒后，振铃 音和振铃信号都停止，而这两个用户间的通话就可以开始了。通话直到这两个用户都挂机时 停止。有两种行为必须加以控制：A用户端行为和B用户端行为。出于这个原因，初始控制 对象被分为两个控制对象：A行为和B行为。如果符合以下情况，您就不必划分控制类：您有理由确信，与控制类对象有关的主角的行为绝不会变更或者变更微乎其微。控制类中某个对象对一个主角的行为与它对另一个主角的行为相比根本是无关紧要 的，单个对象就可包含所有行为。这种方式的行为组合对可更改性的影响可以忽略不计。实体类实

15、体类是用于对必须存储的信息和相关行为建模的类。实体对象（实体类的实例）用 于保存和更新一些现象的有关信息，例如：事件、人员或者一些现实生活中的对象。实体类 通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期 都需要。一个实体对象通常不是某个用例实现所特有的；有时，一个实体对象甚至不专用于系统 本身。其属性和关系的值通常由主角指定。执行系统内部任务时也可能要使用实体对象。实 体对象的行为可以和其他对象构造型的行为一样复杂。但是，与其他对象不同的是，这种行 为与实体对象所代表的现象具有很强的相关性。实体对象是独立于环境（主角）的。实体对象代表了开发中的系统的核心概念。银行系统中实体类的典型示例是账户和客 户。在一个网络处理系统中，典型的示例是节点和链接。如果您希望为之建模的现象未被其他类使用,您可以将其作为实体类的一个属性进行建 模，或者甚至作为实体类之间的关系进行建模。另一方面，如果现象被设计模型中的其他类 所使用，那么您必须将它作为类来建模。实体类提供了理解系统的另一种角度，这样说是因为实体类显示了逻辑数据结构，而此 结构有助于您理解系统应给用户提供的内容。査找实体类实体类表示系统中的信息存储，它们一般用于表示系统所管理的核心概念。实体对象经常是被动和永久性的。它们的主要