标签：
在系统分析阶段将分析类分为三种类型：实体类、界面类、控制类。
实体类主要是作为数据管理和业务逻辑处理层面上存在的类别； 它们主要在分析阶段区分 实体类的主要职责是存储和管理系统内部的信息，它也可以有行为，甚至很复杂的行为，但这些行为必须与它所代表的实体对象密切相关
上述给出的实体类的定义是比较抽象的.类具有继承和递归的特点,实体类可以在抽象类的基础上进一步定义具体的类
实体类是用于对必须存储的信息和相关行为建模的类。实体对象（实体类的实例）用于保存和更新一些现象的有关信息，例如：事件、人员或者一些现实生活中的对象。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。
一个实体对象通常不是某个用例实现所特有的；有时，一个实体对象甚至不专用于系统本身。其属性和关系的值通常由主角指定。执行系统内部任务时也可能要使用实体对象。实体对象的行为可以和其他对象构造型的行为一样复杂。但是，与其他对象不同的是，这种行为与实体对象所代表的现象具有很强的相关性。实体对象是独立于环境（主角）的。
实体对象代表了开发中的系统的核心概念。银行系统中实体类的典型示例是账户和客户。在一个网络处理系统中，典型的示例是节点和链接。
如果您希望为之建模的现象未被其他类使用，您可以将其作为实体类的一个属性进行建模，或者甚至作为实体类之间的关系进行建模。另一方面，如果现象被设计模型中的其他类所使用，那么您必须将它作为类来建模。
实体类提供了理解系统的另一种角度，这样说是因为实体类显示了逻辑数据结构，而此结构有助于您理解系统应给用户提供的内容。
查找实体类
实体类表示系统中的信息存储，它们一般用于表示系统所管理的核心概念。实体对象经常是被动和永久性的。它们的主要职责是存储和管理系统中的信息。
我们经常是从词汇表（在需求阶段制定）和业务领域模型（如果进行了业务建模，则在业务建模阶段中建立）中找寻到实体类的。
实体类限制
实体类只应和其他实体类之间存在关联关系。实体类对象的生存期一般都很长；而控制类对象和边界类对象的生存期则很短。正是由于这些类的生存期相差如此之大，所以在这些类之间建立关联关系是不可取的。
推荐使用的不同类构造型之间的关联关系。
*用“订阅”关联关系取而代之，在这种关联关系中控制类订阅实体类对象中的某些特定事件。
推行一致性
1 · 发现一种新的行为后，检查现有的类中是否具有类似的职责。只要可能，就复用现有的类。只有在缺乏可执行该新行为的现有对象时，才创建新类。 2 · 确定类之后，对类进行检查，以确保它们的职责是一致的。如果某个类的职责互不相关，则将该对象分为两个或者多个类。还应对协作图进行相应的更新。 3 · 如果某个类由于职责互不相关而被划分，则检查这个类所参与的协作，判断协作是否也需要更新。如果必要，可更新此协作。 4 · 只有一项职责的类不存在什么问题，但它存在的必要性本身就值得怀疑。时刻准备对所有类的存在提出质疑并进行验证。
控制类用于描述一个用例所具有的事件流控制行为，控制一个用例中的事件顺序。
控制类用于对一个或几个用例所特有的控制行为进行建模。控制对象（控制类的实例）通常控制其他对象，因此它们的行为具有协调性质。控制类将用例的特有行为进行封装。
控制对象的行为与特定用例的实现密切相关。在很多场景下，您甚至可以说是控制对象“掌握”着用例的实现。但是，如果用例任务之间联系很紧密，有些控制对象就能参与多个用例实现。此外，不同控制类的多个控制对象可以参与同一个用例。不是所有用例都需要控制对象。例如，如果某个用例的事件流与一个实体对象相关，那么边界对象就可能在该实体对象的协助下实现这个用例。您可以首先为每个用例实现确定一个控制类，接着，在确定了更多的用例实现并发现更多的共性后，再对其进行改进。
因为控制类能够表示系统的动态行为，处理主要的任务和控制流，所以它们可以帮助理解系统。
当系统执行用例的时候，就产生了一个控制对象。控制对象经常在其对应用例执行完毕后消亡。
注意：控制类并不能处理用例需要执行的一切事务。相反，它协调其他用来实施此功能的对象的活动。控制类将工作委派给已被指定负责此项功能的对象。
查找控制类
控制类用于在系统中协调行为。系统可以在没有控制对象的情况下执行某些用例（仅使用实体对象和边界对象），尤其是那些只需对已存储信息进行简单处理的用例。
较复杂的用例一般都需要一个或多个控制类来协调系统中其他对象的行为。控制对象的示例有：事务管理器、资源协调器和错误处理器。
控制类有效地将边界对象与实体对象分开，让系统更能适应其边界内发生的变更。这些控制类还将用例所特有的行为与实体对象分开，使实体对象在用例和系统中具有更高的复用性。
控制类所提供的行为具有以下特点：
· 独立于环境（不随环境的变更而变更）。 · 确定用例中的控制逻辑（事件顺序）和事务。 · 在实体类的内部结构或行为发生变更的情况下，几乎不会变更。 · 使用或规定若干实体类的内容，因此需要协调这些实体类的行为。 · 不是每次被激活后都以同样的方式执行（事件流具有多种状态）。
用例的事件流决定了不同任务的执行顺序。首先，调查事件流是否能由已确定的边界类和实体类进行处理。对于主要是为了输入、检索、显示或修改信息的简单事件流来说，通常不必单独使用一个控制类，将由边界类负责协调用例。
如果事件流较复杂，而且包含一些可能会独立于接口（边界类）或系统信息库（实体类）而变更的动态行为，则应该将该事件流封装在一个单独的控制类中。通过封装事件流，同一个控制类就可能由具有不同接口和信息库（或者至少基础数据结构不同）的各种系统重复使用。
示例：管理任务队列
您可从库房管理系统的执行任务用例中确定一个控制类。该控制类处理一个任务队列，保证任务按照正确的顺序来执行。一旦分配好运输工具后，它就执行队列中的下一个任务。因此，系统可以同时执行多个任务。
如果将由其对应的控制对象定义的行为分为两个控制类（Task Performer 和 Queue Handler），那么说明此行为就会更加容易。Queue Handler 对象将只处理队列顺序和对运输工具的分配。整个队列只需一个 Queue Handler 对象。一旦系统要执行某个任务，它就会产生一个新的 Task Performer 对象来执行该任务。所以，系统所执行的每个任务都需要一个 Task Performer 对象。
复杂的类应按照类似职责进行划分
这种划分的主要好处在于：我们将队列处理职责（许多用例中都有的职责）从任务管理的特有活动（该用例所特有）中分离出来。这使得理解类更加容易，而且更易于随着设计的成熟而进行修改。这还有益于保持系统的负载平衡，因为只要有处理负载的需要，就可以创建足够的 Task Performer 来处理工作量。
将主事件流和备选/异常事件流分别封装在不同的控制类中 为了简化变更，将主事件流和备选事件流封装于不同的控制类中。如果备选事件流和异常事件流完全独立，那么将它们也分开。这会方便系统以后的扩展和维护。
如果两个主角共享同一个控制类，则应划分控制类 如果多个主角使用同一个控制类，那么可能也需要划分控制类。通过这种方法，我们将一个主角需求的变更与系统的其他部分隔离开。如果变更成本很高，或后果非常严重，您就应该找出所有与多个主角相关的控制类，并对它们进行划分。理想情况下，每个控制类应该最多只与一个主角进行交互（通过一些边界对象）。
示例：电话通话管理
以用例市内电话为例。我们首先确定一个控制类来管理通话。
用来控制电话系统中市内电话的控制类可以很快地分为两个控制类：A 行为和 B 行为，分别对应于各自的主角。
在市内通话中，有两个主角：拨打电话的 A 用户和接听电话的 B 用户。A 用户拿起话筒，听到拨号音，然后拨打电话号码。系统立即存储号码并进行分析。系统接收到号码的所有数字后，将振铃音发往 A 用户，同时向 B 用户发出振铃信号。B 用户拿起话筒后，振铃音和振铃信号都停止，而这两个用户间的通话就可以开始了。通话直到这两个用户都挂机时停止。
有两种行为必须加以控制：A 用户端行为和 B 用户端行为。出于这个原因，初始控制对象被分为两个控制对象：A 行为和 B 行为。
如果符合以下情况，您就不必划分控制类：
· 您有理由确信，与控制类对象有关的主角的行为绝不会变更或者变更微乎其微。
· 控制类中某个对象对一个主角的行为与它对另一个主角的行为相比根本是无关紧要的，单个对象就可包含所有行为。这种方式的行为组合对可更改性的影响可以忽略不计。
在系统分析阶段将分析类分成三种类型：实体类、边界类、控制类
边界类用于描述外部参与者与系统之间的交互。识别边界类可以帮助开发人员识别出用户对界面的需求。
边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。这种交互包括转换事件，并记录系统表示方式（例如接口）中的变更。
边界类对系统中依赖于环境的那些部分进行建模。实体类和控制类对独立于系统外部环境的那部分进行建模。因此，如果更改 GUI 或通信协议，将只会更改边界类，对实体类和控制类则毫无影响。
由于明确了系统的边界，边界类能帮助人们更容易地理解系统。在设计时，它们为确定相关服务提供了一个好的起点。例如，如果在设计初期就确定了一个打印机接口，很快您即会发现您必须对打印输出的格式也进行建模。
常见的边界类有窗口、通信协议、打印机接口、传感器和终端。如果您在使用 GUI 生成器，您就不必将按钮之类的常规接口部件作为单独的边界类来建模。通常，整个窗口就是最精制的边界类对象。边界类还有助于获取那些可能不面向任何对象的 API（例如遗留代码）的接口。
您应该根据边界类所表示的边界类型来对边界类建模。与其他系统进行通信和与人员主角进行通信（通过用户界面）在目的上大有不同。在用户界面建模中，最需要关注的是如何向用户显示界面。而在系统通信建模中，最应关注的是通信协议。
边界对象（即边界类的一个实例）的生存期可以比用例实例的生存期更长。举例来说，边界对象必须在两个用例执行之间的一段时间显示在屏幕上时就符合这种情况。但是，通常情况下二者的生存期一样长。
查找边界类边界类帮助系统接口与系统外部进行交互。边界对象将系统与其外部环境的变更（与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他部分造成影响。
一个系统可能会有多种边界类：
1 · 用户界面类 - 帮助与系统用户进行通信的类
2 · 系统接口类 - 帮助与其他系统进行通信的类
3 · 设备接口类 - 为用来监测外部事件的设备（如传感器）提供接口的类
查找用户界面类
表示用户界面的边界类可能在用户界面建模活动期间存在；只要合适，就可在此活动期间重复使用这些类。如果尚未进行用户界面建模，那么下面进行的讨论将有助于查找这些类。
每个用例主角对都至少有一个边界类。可以认为此对象担负着协调与主角之间的交互的职责。此边界对象有一些辅助对象，边界对象将它的某些职责委派给这些辅助对象。这对于基于窗口的 GUI 应用程序来说更是如此。在这些应用程序中，通常每个窗口或窗体都对应一个边界类。
制作用户界面原型的草图或者对之进行屏幕转储，借此来展示边界对象的行为和外观。
仅对系统的核心部分建模，不要对 GUI 中的每个按钮、列表和小部件都建模。分析的目的是要大致了解系统是如何构成的，而不是要设计每一个细枝末节。换句话说，您只需为系统中的一些现象或者在用例实现的事件流中提及的一些事物确定边界类。另请参见指南：边界类（用户界面建模）。
查找系统接口类 与外部系统通信的边界类负责管理与外部系统的对话，它为正在构建的系统提供与该外部系统的接口。
示例：
在自动柜员机中，提款必须通过 ATM 网络（一个主角）得到验证，然后该网络再通过银行会计系统对提款进行验证。我们可以确定让一个称为 ATM 网络接口的对象来提供与 ATM 网络之间的通信。
与现有系统的接口可能已有明确定义。如果是这样，即可从接口定义中直接推导出职责。如果已经有一个正式的接口定义，则可对它实施逆向工程，这样就不必在此正式界定它。只需记下这一点，说明现有接口将在设计阶段中复用。
查找设备接口类 系统中有些元素的行为使它们看起来象是外部元素（没有受到系统中任何对象的影响就自发地改变值），例如传感器装置。尽管可以用主角来表示这类外部设备，但系统用户发现这样做会造成一些“混乱”，因为这很可能造成对设备和真人主角“等同”对待。但是，一旦我们不再收集需求，我们就需要考虑所有外部事件的来源，并确保我们有办法让系统检测这些事件。
如果在用例模型中用主角来表示设备，那么对使用边界类来帮助设备与系统通信这种做法验证其合理性就很容易了。如果用例模型中没有这些“设备主角”，那么现在正是添加它们的时机，同时还需在适当的地方对用例补充说明进行更新。
为每个“设备主角”创建一个边界类，用来获取该设备或传感器的职责。如果设备已经有一个明确定义的接口，记下这一点，以便以后设计时引用它。
标签：
原文地址：http://www.cnblogs.com/wanlong/p/4881992.html
