边界类控制类实体类.docVIP

边界类、控制类、实体类 分析类的构造型可分为以下几种： · 边界类 · 控制类 · 实体类 /info/programme-uml/list-1.html 除了为您在查找类时提供更为具体的流程指南外，为类区分构造型还有助于建立一个强壮的对象模型，这是因为对模型进行的变更往往只会影响某一特定部分。例如，用户界面的变更仅会影响边界类。控制流的变更仅会影响控制类。长期信息的变更仅会影响实体类。不过，这些构造型的最大作用还是帮助您在分析和初期设计阶段中辨识类。在设计阶段的后期，您可能要考虑使用一组略有不同的构造型，以便更好地将其与实施环境、应用程序类型等联系起来。 边界类 边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。这种交互包括转换事件，并记录系统表示方式（例如接口）中的变更。 边界类对系统中依赖于环境的那些部分进行建模。实体类和控制类对独立于系统外部环境的那部分进行建模。因此，如果更改 GUI 或通信协议，将只会更改边界类，对实体类和控制类则毫无影响。 由于明确了系统的边界，边界类能帮助人们更容易地理解系统。在设计时，它们为确定相关服务提供了一个好的起点。例如，如果在设计初期就确定了一个打印机接口，很快您即会发现您必须对打印输出的格式也进行建模。 常见的边界类有窗口、通信协议、打印机接口、传感器和终端。如果您在使用 GUI 生成器，您就不必将按钮之类的常规接口部件作为单独的边界类来建模。通常，整个窗口就是最精制的边界类对象。边界类还有助于获取那些可能不面向任何对象的 API（例如遗留代码）的接口。 您应该根据边界类所表示的边界类型来对边界类建模。与其他系统进行通信和与人员主角进行通信（通过用户界面）在目的上大有不同。在用户界面建模中，最需要关注的是如何向用户显示界面。而在系统通信建模中，最应关注的是通信协议。 边界对象（即边界类的一个实例）的生存期可以比用例实例的生存期更长。举例来说，边界对象必须在两个用例执行之间的一段时间显示在屏幕上时就符合这种情况。但是，通常情况下二者的生存期一样长。 查找边界类边界类帮助系统接口与系统外部进行交互。边界对象将系统与其外部环境的变更（与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他部分造成影响。 一个系统可能会有多种边界类： · 用户界面类 - 帮助与系统用户进行通信的类 · 系统接口类 - 帮助与其他系统进行通信的类 · 设备接口类 - 为用来监测外部事件的设备（如传感器）提供接口的类 查找用户界面类??? 表示用户界面的边界类可能在用户界面建模活动期间存在；只要合适，就可在此活动期间重复使用这些类。如果尚未进行用户界面建模，那么下面进行的讨论将有助于查找这些类。 每个用例主角对都至少有一个边界类。可以认为此对象担负着协调与主角之间的交互的职责。此边界对象有一些辅助对象，边界对象将它的某些职责委派给这些辅助对象。这对于基于窗口的 GUI 应用程序来说更是如此。在这些应用程序中，通常每个窗口或窗体都对应一个边界类。 制作用户界面原型的草图或者对之进行屏幕转储，借此来展示边界对象的行为和外观。 仅对系统的核心部分建模，不要对 GUI 中的每个按钮、列表和小部件都建模。分析的目的是要大致了解系统是如何构成的，而不是要设计每一个细枝末节。换句话说，您只需为系统中的一些现象或者在用例实现的事件流中提及的一些事物确定边界类。另请参见指南：边界类（用户界面建模）。 查找系统接口类??? 与外部系统通信的边界类负责管理与外部系统的对话，它为正在构建的系统提供与该外部系统的接口。 示例： 在自动柜员机中，提款必须通过 ATM 网络（一个主角）得到验证，然后该网络再通过银行会计系统对提款进行验证。我们可以确定让一个称为 ATM 网络接口的对象来提供与 ATM 网络之间的通信。 与现有系统的接口可能已有明确定义。如果是这样，即可从接口定义中直接推导出职责。如果已经有一个正式的接口定义，则可对它实施逆向工程，这样就不必在此正式界定它。只需记下这一点，说明现有接口将在设计阶段中复用。 查找设备接口类??? 系统中有些元素的行为使它们看起来象是外部元素（没有受到系统中任何对象的影响就自发地改变值），例如传感器装置。尽管可以用主角来表示这类外部设备，但系统用户发现这样做会造成一些“混乱”，因为这很可能造成对设备和真人主角“等同”对待。但是，一旦我们不再收集需求，我们就需要考虑所有外部事件的来源，并确保我们有办法让系统检测这些事件。 如果在用例模型中用主角来表示设备，那么对使用边界类来帮助设备与系统通信这种做法验证其合理性就很容易了。如果用例模型中没有这些“设备主角”，那么现在正是添加它们的时机，同时还需在适当的地方对用例补充说明进行更新。 为每个“设备主角”创建一个边界类