软件工程：UML建模之分析模型和设计模型.pdf

Hwadee华迪实训分析模型和设计模型华迪实训基地 Version:1.0Hwadee华迪实训 课程 授课形式 重点、难点 授课内容 习题思考 信息反馈Hwadee华迪实训受训对象软件类专业实训学生Hwadee华迪实训课程总课时:540分钟授课大纲：0:30分析模型_0:100分析类0:130 序列图0:170设计模型0:200 关联关系0:230聚合关系0:260泛化关系4Hwadee华迪实训0:300订阅关联关系0:340设计类0:400类图0:450用例实现0:540数据模型总课时：540分钟5Hwadee华迪实训重点、难点一、分析模型中实体类、边界类和控制类的建 立。二、时序图、用例实现和数据模型。6Hwadee华迪实训、分析模型分析模型：描述用例实现的对象模型，它是工件：设计模型的一个抽 象。分析模型包含用例分析的结果、工件：分析类的实例。分析模型 是可选工件。分析模型的目的：包含分析类和任何与之相关的工件。在分析模型演 进为设计模型的情况下，分析模型可以是一个临时工件。它也可以在 项目的部分或整个阶段中，或许在项目完成后继续存在，作为系统的 既令性；白勺总幺吉,常，：初差类”可直接演进为设计模型中的元素：某些分析类变为设 计类，其他分析类变为设计子系统。分析的目标是确定一种从所需行 为到系统中建模元素的初步映射。设计的目标是将此初步（且有些理 想化的）映射转换成可实施的模型元素集。结果，模型元素从分析阶 段演进到设计阶段后，细节和精度都得到精化。因此，“分析类”经常保 持非常高的非固定性和可变性，并且在设计活动中固化之前可做极大7Hwadee华迪实训、分析模型的改进。决定是否需要单独的分析模型时应考虑以下几点：需要设计在多目标环境下使用、带有独立设计构架的系统时，独舞疆琴辘理熊臂耀独翻的抽象或泛化关 由孟薛计的蓼杂性，因此在向新的司队成员介绍设计时就需要便 用简花而抽象的“设计，止k外，明确克文的构架可起到相同的祢/在考虑建立系统视图所带来的益处时，必须权衡为确保分析设计 模型保持一致性所需的额外工作，因为该系统只代表系统运行方 式的最重要的细节。保持分析模型和设计模型之间高真实度的成 本极其昂贵。一个折中的方法可以是分析模型仅具有设计中最重 詈咆领域类和关键的抽象概念。维护分析模型的成本随着其复杂 性增加而增加。一旦不再对分析模型进行维护，则其价值将迅速衰减。8Hwadee华迪实训八分析类从某种意义上说，如果它得不到维护，则它因为无法精确地反映系统的当前设计而将失去使用价值。决定不再维护分析模型也许是正确的（它可能已经达到其目的），但是这种决定应该是明智的。分析类：代表“系统中具备职责和行为的事物”的初期概念模型。这些概 念模型最终将演进为设计模型中的类和子系统。分析类的构造型分析类的构造型可分为以下几种：边界类 控制类 实体类除了为您在查找类时提供更为具体的流程指南外，为类区分构造型还 有助于建立一个强壮的对象模型，这是因为对模型进行的变更9Hwadee华迪实训八分析类往往只会影响某一特定部分。例如，用户界面的变更仅会影响边界类。控制流的变更仅会影响控制类。长期信息的变更仅会影响实体类。不 过，这些构造型的最大作用还是帮助您在分析和初期设计阶段中辨识 类。在设计阶段的后期，您可能要考虑使用一组略有不同的构造型，以便更好地将其与实施环境、应用程序类型等联系起来。边界类卜O边界类是一种用于对系统外部环境与其内部运作之间的交互进行建 模的类。这种交互包括转换事件，并记录系统表示方式（例如接口）中的o边界类对系统中依赖于环境的那些部分进行建模。实体类和控制类 对独立于系统外部环境的那部分进行建模。因此，如果更改GUI或通 信协议，将只会更改边界类，对实体类和控制类则毫无影响。10Hwadee华迪实训三、分析类由于明确了系统的边界，边界类能帮助人们更容易地理解系统。在设 计时，它们为确定相关服务提供了一个好的起点。例如，如果在设计 初期就确定了一个打印机接口，很快您即会发现您必须对打印输出的 格式也进行建模。常见的边界类有窗口、通信协议、打印机接口、传感器和终端。如果 在使用GUI生成器，您就不必将按钮之类的常规接口部件作为单独 的边界类来建模。通常，整个窗口就是最精制的边界类对象。边界类 还有助于获取那些可能不面向任何对象的API（例如遗留代码）的接 o应该根据边界类所表示的边界类型来对边界类建模。与其他系统进行 通信和与人员主角进行通信（通过用户界面）在目的上大有不同。在 用户界面建模中，最需要关注的是如何向用户显示界面。而在系统通 信建模中，最应关注的是通信协议。边界对象（即边界类的一个实例）的生存期可以比用例实例的生存期 11Hwadee华迪实训三、分析类更长。举例来说，边界对象必须在两个用例执行之间的一段时间显示 在屏幕上时就符合这种情况。但是，通常情况下二者的生存期一样长。查找边界类边界类帮助系统接口与系统外部进行交互。边界对象将系统与其外部 环境的变更（与其他系统的接口的变更、用户需求的变更等）分隔开,使这些变更不会对系统的其他部分造成影响。一个系统可能会有多种边界类：用户界面类-帮助与系统用户进行通信的类 系统接口类-帮助与其他系统进行通信的类 设备接口类-为用来监测外部事件的设备（如传感器）提供接口的类 查找用户界面类表示用户界面的边界类可能在用户界面建模活动期间存在；只要合适,就可在此活动期间重复使用这些类。如果尚未进行用户界面建模，那 么下面进行的讨论将有助于查找这些类。12Hwadee华迪实训三、分析类每个用例主角对都至少有一个边界类。可以认为此对象担负着协调与 主角之间的交互的职责。此边界对象有一些辅助对象，边界对象将它 的某些职责委派给这些辅助对象。这对于基于窗口的GUI应用程序 来说更是如此。在这些应用程序中，通常每个窗口或窗体都对应一个 边界类。制】用，界面原型的草图或者对之进行屏幕转储，借此来展示边界对 象的行为和外观。仅对系统的核心部分建模，不要对GUI中的每个按钮、列表和小部 件都建模。分析的目的是要大致了解系统是如何构成的，而不是要设 计每一个细枝末节。换句话说，您只需为系统中的一些现象或者在用 例实现的事件流中提及的一些事物确定边界类。查找系统接口类与外部系统通信的边界类负责管理与外部系统的对话，它为正在构建 的系统提供与该外部系统的接口。13Hwadee华迪实训三、分析类示例在自动柜员机中，提款必须通过ATM网络（一个主角）得到验证，然后该网络再通过银行会计系统对提款进行验证。我们可以确定让一 个称为ATM网络接口的对象来提供写ATM网络之间的通信。与现有系统的接口可能已有明确定义。如果是这样，即可从接口定义 中直接推导出职责。如果已经有一个正式的接口定义，则可对它实施 逆向工程，这样就不必在此正式界定它。只需记下这一点，说明现有 接口将在设计阶段中复用。查找设备接口类系统中有些元素的行为使它们看起来象是外部元素（没有受到系统中 任何对象的影响就自发地改变值），例如传感器装置。尽管可以用主 角来表示这类外部设备，但系统用户发现这样做会造成一些“混乱”，因为这很可能造成对设备和真人主角“等同”对待。但是，一旦我们不 再收集需求，我们就需要考虑所有外部事件的来源，并确保我们有办 14Hwadee华迪实训三、分析类如果在用例模型中用主角来表示设备，那么对使用边界类来帮助设备与系统通 信这种做法验证其合理性就很容易了。如果用例模型中没有这些“设备主 角”，那么现在正是添加它们的时机，同时还需在适当的地方对用例补充 说明进行更新。为每个“设备主角”创建一个边界类，用来获取该设备或传感器的职责。如果设 备已经有一个明确定义的接口，记下这一点，以便以后设计时引用它。控制类O控制类用于对一个或几个用例所特有的控制行为进行建模。控制对 象（控制类的实例）通常控制其他对象，因此它们的行为具有协调性 质。控制类将用例的特有行为进行封装。控制对象的行为与特定用例的实现密切相关。在很多场景下，您甚 至可以说是控制对象“掌握”着用例的实现。但是，如果用例任务之间联 系很紧密，有些控制对象就能参与多个用例实现。止匕外，不同控制类 的多个控制对象可以参与同一个用例。不是所有用例都需要控制对象。例如，如果某个用例的事件流与一个实体对象相关，那么边界对象就 15Hwadee华迪实训八分析类可能在该实体对象的协助下实现这个用例。您可以首先为每个用例实 现确定一个控制类，接着，在确定了更多的用例实现并发现更多的共 性后，再对其进行改进。因为控制类能够表示系统的动态行为，处理主要的任务和控制流，所 以它们可以帮助理解系统。当系统执行用例的时候，就产生了一个控制对象。控制对象经常在其 对应用例执行完毕后消亡。注意：控制类并不能处理用例需要执行的一切事务。相反，它协调其 他用来实施此功能的对象的活动。控制类将工作委派给已被指定负责 此项功能的对象。查找控制类捶制重用于在系统中协调行为。系统可以在没有控制对象的情况下执 行某些用例（仅使用实体对象和边界对象），尤其是那些只需对已存 储信息进行简单处理的用例。较复杂的用例一般都需要一个或多个控制类来协调系统中其他对象的 行为。控制对象的示例有：事务管理器、资源协调器和错误处理器。16Hwadee华迪实训三、分析类控制类有效地将边界对象与实体对象分开，让系统更能适应其边界内 发生的变更。这些控制类还将用例所特有的行为与实体对象分开，使 实体对象在用例和系统中具有更高的复用性。控制类所提供的行为具有以下特点：独立于环境（不随环境的变更而变更）。确定用例中的控制逻辑（事件顺序）和事务。在实体类的内部结构或行为发生变更的情况下，几乎不会变更。使用或规定若干实体类的内容，因此需要协调这些实体类的行为。不是每次被激活后都以同样的方式执行（事件流具有多种状态）。确定是否需要控制类用例的事件流决定了不同任务的执行顺序。首先，调查事件流是否 能由已确定的边界类和实体类进行处理。对于主要是为了输入、检索、显示或修改信息的简单事件流来说，通常不必单独使用一个控制类，将由边界类负责协调用例。17Hwadee华迪实训三、分析类如果事件流较复杂，而且包含一些可能会独立于接口（边界类）或系 统信息库（实体类）而变更的动态行为，则应该将该事件流封装在一 个单独的控制类中。通过封装事件流，同一个控制类就可能由具有不 同接口和信息库（或者至少基础数据结构不同）的各种系统重复使用。示例：管理任务队列可从库房管理系统的执行任务用例中确定一个控制类。该控制类处 理一个任务队列，保证任务按照正确的顺序来执行。一旦分配好运输 工具后，它就执行队列中的下一个任务。因此，系统可以同时执行多 个任务。如果将其对应的控制对象定义的行为分为两个控制类（Task Performer和Queue Handler）,那么说明此行为就会更加容易。Queue Handler对象将只处理队列顺序和对运输工具的分配。整个队 列只需一个Queue Handler对象。一旦系统要执行某个任务，它就会 产生一个新的Task Performer对象来执行该任务。所以，系统所执18Hwadee华迪实训三、分析类行的每个任务都需要一个Task Performer对象。这种划分的主要好处在于：我们将队列处理职责（许多用例中都有 的职责）从任务管理的特有活动（该用例所特有）中分离出来。这 使得理解类更加容易，而且更易于随着设计的成熟而进行修改。这 还有益于保持系统的负载平衡，因为只要有处理负载的需要，就可 以创建足够的Task Performer来处理工作量。将主事件流和备选/异常事件流分别封装在不同的控制类中为了简化变更，将主事件流和备选事件流封装于不同的控制类中。如果备选事件流和异常事件流完全独立，那么将它们也分开。这会 方便系统以后的扩展和维护。如果两个主角共享同一个控制类，则应划分控制类如果多个主角使用同一个控制类，那么可能也需要划分控制类。通 过这种方法，我们将一个主角需求的变更与系统的其他部分隔离开。如果变更成本很高，或后果非常严重，您就应该找出所有与多个 19Hwadee华迪实训三、分析类主角相关的控制类，并对它们进行划分。理想情况下，每个控制类应该最多 只与一个主角进行交互（通过一些边界对象）。示例：电话通话管理以用例市内电话为例。我们首先确定一个控制类来管理通话。A用户 市内电话 B用户8行为20Hwadee华迪实训三、分析类在市内通话中，有两个主角：拨打电话的A用户和接听电话的B用户。A 用户拿起话筒，听到拨号音，然后拨打电话号码。系统立即存储号码并进行 分析。系统接收到号码的所有数字后，将振铃音发往A用户，同时向B用 户发出振铃信号。B用户拿起话筒后，振铃音和振铃信号都停止，而这两个 用户间的通话就可以开始了。通话直到这两个用户都挂机时停止。有两种行为必须加以控制：A用户端行为和B用户端行为。出于这个原因，初始控制对象被分为两个控制对象：A行为和B行为。如果符合以下情况，您就不必划分控制类：有理由确信，与控制类对象有关的主角的行为绝不会变更或者变更微乎其微。控制类中某个对象对一个主角的行为与它对另一个主角的行为相比根本是无 关紧要的，单人对象就可包含所有行为。这种方式的行为组合对可更改性的 影响可以忽略不计。21Hwadee华迪实训三、分析类实体类9实体类是用于对必须存储的信息和相关行为建模的类。实体对象（实体类的 实例）用于保存和更新一些现象的有关信息，例如：事件、人员或者一些现 实生活中的对象。实体类通常都是永久性的，它们所具有的属性和关系是长 期需要的，有时甚至在系统的整个生存期都需要。一个实体对象通常不是某个用例实现所特有的；有时，一个实体对象甚至不 专用于系统本身。其属性和关系的值通常由主角指定。执行系统内部任务时 也可能要使用实体对象。实体对象的行为可以和其他对象构造型的行为一样 复杂。但是，与其他对象不同的是，这种行为与实体对象所代表的现象具有 很强的相关性。实体对象是独立于环境（主角）的。实体对象代表了开发中的系统的核心概念。银行系统中实体类的典型示例是 账户和客户。在一个网络处理系统中，典型的示例是节点和链接。如果您希望为之建模的现象未被其他类使用，您可以将其作为实体类的一个 属性进行建模，或者甚至作为实体类之间的关系进行建模。22Hwadee华迪实训八分析类另一方面，如果现象被设计模型中的其他类所使用，那么您必须将它作为类 来建模。实体类提供了理解系统的另一种角度，这样说是因为实体类显示了逻辑数据 结构，而此结构有助于您理解系统应给用户提供的内容。查找实体类实体类表示系统中的信息存储，它们一般用于表示系统所管理的核心概念。实体对象经常是被动和永久性的。它们的主要职责是存储和管理系统中的信 息。我们经常是从词汇表（在需求阶段制定）和业务领域模型（如果进行了业务 建模，则在业务建模阶段中建立）中找寻到实体类的。关联关系限制边界类限制23Hwadee华迪实训八分析类允许存在以下关联关系：两个边界类之间的关联关系，例如：说明某一个特定窗口与其他 边界对象之间存在什么关系。从边界类到实体类的关联关系，因为边界对象可能需要在这个边 界对象的各个操作之间对某些实体对象进行跟踪。应该避免以下关联关系：从边界类到控制类的关联关系，因为控制对象和边界对象的关系 一般延续时间很短，所以不必对此建模。控制类限制允许存在以下关联关系：控制类和实体类之间的关联关系，因为控制对象可能需要在这 个控制对象的各个操作之间对某些实体对象进行跟踪。24Hwadee华迪实训三、分析类应该避免以下关联关系：控制类和边界类之间的关联关系，因为控制类和边界类之间的关系延续时间 很短，所以不必对此建模。控制类之间的关联关系，因为它们之间的关系延续时间也很短，所以不必对 此建模。实体类限制实体类只应和其他实体类之间存在关联关系。实体类对象的生存期一般都很 长；而控制类对象和边界类对象的生存期则很短。正是由于这些类的生存期 相差如此之大，所以在这些类之间建立关联关系是不可取的。推行一致性发现一种新的行为后，检查现有的类中是否具有类似的职责。只要可能,就复用现有的类。只有在缺乏可执行该新行为的现有对象时，才创建新 类。25Hwadee华迪实训三、时序图确定类之后，对类进行检查，以确保它们的职责是一致的。如果某个类 的职责互不相关，则将该对象分为两个或者多个类。还应对协作图进行 相应的更新。如果某个类由于职责互不相关而被划分，则检查这个类所参与的协作，判断协作是否也需要更新。如果必要，可更新此协作。只有一项职责的类不存在什么问题，但它存在的必要性本身就值得怀疑。时刻准备对所有类的存在提出质疑并进行验证。序列可用序列图用于描述按时间顺序排列的对象之间的交互模式；它按照参与交 互的对象所具有的“生命线”和它们相互发送的消息来显示这些对象。使用序列图来阐明用例实现，即说明对象如何通过交互来执行全部或部 分用例的行为。可以用一个或多个序列图来阐明实现用例的对象交互过 程。在典型的组织结构中，主事件流将有一个序列图，而每个独立的用 例分支流都分别有一个序列图o2Hwadee华迪实训三、时序图序列图对设计人员特别重要，因为它们明确了对象在流程中的角色，因而 可以为确定类的责任和接口提供基本的输入。与协作图不同，序列图包括了时间顺序，但不包括对象关系。序列图和协 作图表述的是相似的信息，但表述的方式却不同。序列图显示了消息的明 确顺序，所以更适用于实时的规约和复杂的场景。序列图的内容在序列图中可以有对象和主角实例，以及说明它们如何交互的消息。序列图描 述了在参与交互的对象中所发生的事件（从激活的角度来说明），以及这些对 象如何通过相互发送消息进行通信。可以为用例事件流的各种不同形式制作序 列图。以下序列图描述了一个简单的电话交换机中的用例拨打本地电话的部分事件流。27A-subscr iber:目A Handler:o目接收第一位数字结束拨号音接收其余数字通知处理程序B如果找到订户B,将其标为忙并将 A和B连接到 网络为A设置振铃音，为B发出振铃信号Hwadee 华迪实训B-subscr iber:Networ k Handling:B Handler:digit()ICoor dinator:dialledDigit()notify()inectf)r ingsignal on()dialtone off()(ICoor dinator:dialledDigit()digit()r ingtone on()connect()JCoor dinator二 c。J28Hwadee华迪实训三、时序图对象对象被表示为叫做“生命线”的垂直虚线。生命线表示对象在特定时间的 存在。对象符号被描绘在生命线的顶端，所显示的对象及其类的名称 带有下划线，二者用冒号分隔：对象名：类名在序列图中，可以按以下方式使用对象：生命线可以表示对象或对象的类。因此，可以使用生命线来建立 类与对象行为的模型。但是，一条生命线通常表示某个类的所有 对象。可以不指定对象的类。通常，可以先用对象创建序列图，随后再 指定它们所属的类。可以给对象命名，但如果要区分同一个类的不同对象，则应给对象命名。29Hwadee华迪实训三、时序图 同一序列图中的几条生命线可以表示同一个类的不同对象；但是,如上所述，应当给对象命名，以便区分不同的两个对象。表示类的生命线可以与表示该类对象的生命线平行存在。可以将 表示类的生命线对象名设置为类的名称。主角作为交互的发起者，主角实例通常由序列图中的第一条（最左侧）生 命线来表示。如果在同一序列图中有多个主角实例，就应尽量使它们 位于最左侧或最右侧的生命线。消息消息是对象之间的通信，它在传达信息的同时期望活动随之发生；在 序列图中，消息被表示为从一个对象的生命线到另一个对象的生命线 的水平实线箭头。如果消息从一个对象发向该对象自身，箭头的开始 30Hwadee华迪实训三、时序图位置和结束位置就可能位于同一条生命线上。箭头通过消息名称及消 息参数来标记。为了显示消息在整个交互中的顺序，还可以用顺序号 来标记消息箭头。序列图中通常会省略顺序号，此时用箭头的物理位 置来表示相对顺序。消息可以是未被分配的，这意味着它的名称是描述消息总体意义的临 时字符串，而不是接收方对象的操作名称。可以在随后通过指定消息 目标对象的操作来分配消息。所指定的操作将替换消息的名称。脚本在序列图中，脚本以文字的形式描述事件流。应当将脚本放在生命线的左侧，以便从上到下阅读整个事件流（参见 上图）。可以将脚本附加在某个消息上，使脚本随着消息一起移动。31Hwadee华迪实训三、时序图在序列图中分布控制流对整个或部分事件流进行集中控制意味着将由几个对象通过与其他对 象收发消息来控制事件流。这些控制对象将决定用例中其他对象的激 活顺序。其余对象之间的交互无关紧要或根本不存在。示例在回收机系统中，用例Print Daily Report将跟踪（除其他操作之 外）已回收对象的数量和类型，并在收据上记录这些信息。控制对象 Report Generator则确定计算和书写合计数据的顺序32Hwadee华迪实训三、时序图用例Print Daily Report的行为结构集中于控制对象Report Generator。O Q Q Q:Report:Can:Bottle:CrateGeneratorX.”y、number of cans(Sum)7number of bottles(Sum)1111 1i 1 number of crates(SumJ I11,u 1.1丫 133Hwadee华迪实训三、时序图这是一个集中行为的示例。之所以要将控制结构集中，主要是因为事件流的 不同子事件阶段并不相互依赖。该方法的主要优点是，不必让每个对象都跟 踪下一个对象的信息记录。这样，要更改子事件阶段的顺序，只需更改控制 对象即可。例如，如果添加了一个新的回收物品类型，仍然可以很容易地添 加另一个子事件阶段。该结构的另一个优点是，由于行为顺序内置于对象中,因而可以很方便地在其他用例中复用各个子事件阶段。当参与交互的对象直接与对方通信（而不通过一个或多个控制对象来通信）时，就出现了分散控制。示例在用例Send Letter（发送信件）中，某人通过邮局将一封信邮寄到另一 个国家。首先，信件被发送到收件人所在的国家。到了收件人所在国后，信 件又被发送到具体的城市。然后，该城市将把信件发送到收件人的家中。344、时序图Hwadee 华迪实训:Countrvsend letter-1send letter I:Post Office:Post Office Customer:Addressee用例Send Letter的行为结构是分散的。35Hwadee华迪实训三、时序图用例行为是分散的事件流。各个子事件阶段相互结合。信件的发件人要求“把 信发送给某人。”他既不需要知道也不想知道信件在各个国家或城市中转寄的 细节。（如果某人将信件邮寄到他所在的国家，就可能不会进行其中的某些 转递。）所采用的控制类型取决于不同的应用情形。一般而言，应当尽量使对象独立,也就是说，要尽量把各项任务委托给最适合的对象去执行。使用集中控制的事件流将具有“叉形”序列图。另一方面，“梯形”序列图则表 明控制结构对于参与交互的对象来说是分散的。事件流中的集中控制结构产生了“叉形”序列图。分散的控制结构则产生了“梯形”序列图。大多数情况下，用例实现的行为结构由集中行为和分散行为混合组成。分散结构适用于以下情况：2形成了组成型或构成型分层结构，如国家州市;_36Hwadee华迪实训三、时序图集中式的控制结构分散式的控制结构37Hwadee 华迪实训 三、时序图 子事件阶段紧密耦合。也就是说，参与交互的对象：形成信息分层结构，如CEO 部门经理项目经理；表示固定的时间进度（子事件阶段的序列将始终按相同顺序执行），如广告 定单发票交货付款；形成概念性的继承分层结构，如动物哺乳动物猫。需要封装功能，因而要对功能进行抽象。这有利于那些总是需要使用全部功 能的人，因为，如果行为结构是集中的，功能就可能会变得不必要地难于掌 握。集中结构适用于以下情况：子事件阶段的执行顺序可能会发生变更。要使功能的各个部分成为独立的可复用片段。希望插入新的子事件阶段。38Hwadee华迪实训四、设计模型设计模型目TX I a目/日设计模型是一个描述用例实现的对象模型，它可作为对实施模型及其源代码 的抽象。从分析模型开始映射工件：分析类代表设计元素的实例所承担的角色；这些角色可以由一个或多 个设计模型元素来实现。止匕外，单个设计元素可以实现多个角色。下面将讨 论实现分析角色的可能方法：一个分析类可以成为设计模型中的单个类。一个分析类可以成为设计模型中某个类的一部分。一个分析类可以成为设计模型中的一个聚合关系类。（这意味着不能 在分析模型中直接建立此聚合关系类各部分的模型。）一个分析类可以成为设计模型中从同一个类继承而来的一组类。39Hwadee华迪实训四、设计模型 一个分析类可以成为设计模型中一组功能相关的类。一个分析类可以成为设计模型中的一个包（这意味着它可以成为一个构 件。）一个分析类可以成为设计模型中的一项关系。分析类之间的一项关系可以成为设计模型中的一个类。分析类主要处理功能性需求以及来自“问题”领域的模型对象；而设计类则处 理非功能性需求以及来自“解决方案”领域的模型对象。分析类可用来代表“我们希望系统支持的对象”，而不用决定用硬件支持分析 类的多少部分，用软件支持分析类的多少部分。因此，某个分析类的一部分 可以通过硬件来实现，根本不用在设计模型中建模。以上方法也可能会以任何组合的形式存在。映射到实施模型在设计开始以前就应确定设计模型*单类应如何与实施类相关；这一点在Hwadee华迪实训四、设计模型项目专用的设计指南中有所说明。设计模型可以或多或少地接近实施模型，接近程度取决于如何将它的类、包 和子系统映射到实施模型中的构件、包和子系统。在实施期间，经常要处理 一些与实施环境相关的战术性小问题，这些问题不应对设计模型产生影响。例如，在实施期间可以添加类和子系统，以处理平行开发或调整导入依赖关 系。应该有一种从设计模型到实施模型的一致映射。设计指南应定义这一映射，而且在整个设计模型中都应采用一致的抽象级别。优良设计模型的特征好的设计模型需具备以下特征：它能满足系统需求。它能经得住实施环境中的变更。与其他可能的对象模型以及与系统实施相比，它更易于维护._41Hwadee华迪实训五、关联关系它的实施方式很明确。它不包含那些应该记录在程序代码中的信息。它容易适应需求变更。关联关系关联关系表示不同类的对象之间的结构关系，它在一段时间内将多个类的实 例连接在一起（这与依赖关系不同，依赖关系表示两个实例之间的临时关联 关系）。可以使用关联关系表示对象了解其他对象。有时，对象必须相互引用才能实 现交互，例如互相发送消息。因此，在某些情况下，关联关系可以采用序列 图和协作图中的交互模式。关联关系名称多数关联关系是二元的（即只存在于两个类之间），在图中表示为连接类42Hwadee华迪实训五、关联关系符号对的实线路径。既可能是关联关系具有名称，也可能是各关联关系角色 具有名称。最好采用角色名称，因为它们能表达更多信息。如果只能给其中 一个角色命名，那么只要该关联关系将是单向的（即从与该角色名称相关的 对象引出），角色名称仍比关联关系名称更可取。关联关系通常是在分析过程中命名的，此时还没有足够的信息来对角色进行 适当的命名。如果使用关联关系名称，关联关系名称就应该反映该关系的目 的，并且应该是一个动词词组。关联关系名称应放置在关联关系路径上或其 附近。示例在ATM中，钞箱提供出钞模块需要的钱。为了使出钞模块能够出钞，它必 须随时能对钞箱对象进行引用。同样，如果钞箱中的现金被取尽，就必须通 知出钞模块对象，所以钞箱必须随时能对出钞模块进行引用。有一种关联关 系可对这种引用进行建模。43Hwadee华迪实训五、关联关系-提供德-出钞模块 钞箱出钞模块和钞箱之间的关联关系，其名称为提供现金。如果选择了不适当的关联关系名称，就会导致理解上的混乱和错误。以下是 对关联关系名称使用好坏的正反示例：好关联关系名称和坏关联关系名称示例44Hwadee华迪实训五、关联关系45Hwadee华迪实训五、关联关系角色关联关系的两端为角色，角色规定了类在关联关系中所起的作用。每个角色 都必须有名称，而且对应一个类的所有角色名称都必须是唯一的。角色名称 应该是一个名词，能够表达被关联关系对象的角色与关联关系对象之间的关 系。例如，在与教程的关联关系中，教师的合适角色名称就可以是讲师；应 避免使用“有”和“包含”之类的名称，因为它们不能提供有关类间关系的信息。注意，关联关系名称和角色名称的使用是互斥的：不能同时使用关联关系名 称和角色名称。角色名称通常比关联关系名称更可取，除非没有足够的信息 来正确命名角色（这常见于分析阶段中；在设计阶段中应始终使用角色名 称）。如果没有好的角色名称，通常都意味模型不完善或构建不合理。角色名称紧邻关联关系线的末端。以一个订单输入系统中各类之间的关系为例。客户可以使用两种不同地址：一个帐单发送地址和一些订货发送地址。结果，客户和地址之间存在两个关 联关系，如下所示。这些关联关系中标注了关联关系地址为客户担任的角色。46Hwadee华迪实训五、关联关系客户、地址和订单之间的关联关系，显示了角色名称和多重性。47Hwadee华迪实训五、关联关系多重性对于每个角色，都可以指定其类的多重性，即该类的多少个对象可以与另一 个类的一个对象相关联。多重性由角色上的文本表达式指出。表达式是一个 由逗号隔开的整数范围列表。一个整数范围由一个整数下限、两个圆点和一 个整数上限来表示。单个整数也是有效的范围，而符号，*,表示“许多”，即 对象的数量不受限制。符号，*,本身等价于即包括零在内的任何数;这是默认值。一个可选标量角色的多重性为0.1O示例上例中显示了订单和客户之间以及客户和地址之间关联关系的多重性。从该 图可看出，一份订单必然有一个关联关系的客户（客户的多重性为1.1）,但是客户却可能没有任何订单（订单的多重性为0,产）。止匕外，一个客户有 一人帐单发送地址，但是有一个或多个送货地址。为了减少符号带来的混乱,如果忽略多重性，就可以将它们假定为1.1O48Hwadee华迪实训五、关联关系导向性角色的导向性特征表示可以通过关联关系从关联类导向到目标类上。这可通 过多种方式来实施：直接引用对象、关联关系数组、散列表或其他任意一种 允许一个对象引用另一个对象的实施技术。导向性用一个开箭头表示，该箭 头置于关联关系线的目标端，紧靠目标类（即所导向的类）。导向性特征的 默认值为true。示例在订单输入示例中，订单与客户之间可以进行双向导航：订单必须知道是哪 位客户发出的订单，而客户必须知道他发出了哪一个订单。如果没有显示箭 头，则默认关联关系能够双向导航。在客户和地址之间的关联关系中，客户必须知道其地址，但是地址却并不知 道哪位客户（或其他类，因为许多事物都有地址）与该地址相关联。结果，关联关系中客户一端的导向性特征被关闭，图示如下：49Hwadee华迪实训五、关联关系更新后的订单输入系统类，显示关联关系的导向性。50Hwadee华迪实训五、关联关系自关联关系有时，一个类与其自身存在一种关联关系。这并不一定意味着该类的某个实 例与其自身存在关联关系，更多的情况下，它意味着该类的某个实例与该类 的其他实例之间存在关联关系。在自关联关系的情况下，角色名称对于区分 关联关系的目的非常重要。以涉及类雇员的自关联关系为例：在此示例中，一个雇员可能与其他雇员存 在关联关系；如果如此，那么该雇员为经理，而其他雇员则是此经理的属下。由于雇员知道他们的经理，而经理也知道他的属下，所以该关联关系能够双 向导航。51Hwadee华迪实训五、关联关系多重关联关系在相同对象关联关系两次的类之间做两个关联关系；一个指定对象可通过不 同的关联关系链接到不同的对象上。每个关联关系都是独立的，用角色名称 来区分。如上所示，一个客户能与同一个类的不同实例之间建立关联关系，而且每个关联关系都有不同的角色名称。角色排序如果关联关系的多重性大于1,则那些被关联关系的实例就可能会排序。角 色排序特征意味着参与关联关系的那些实例要进行排序。在默认情况下，它 们是并不进行排序。模型并未规定如何对排序进行维护；用于对排序后的关 联关系进行更新的操作必须规定更新元素的插入位置。链接一个关联关系的各个实例称为链接；一个链接就是实例间的关系。可以通过 链接发送消息，而且链接可以表示对象间的引用和聚合关系。52Hwadee华迪实训五、关联关系关联类关联类是一种关联关系，它具有类的特征（例如属性、操作和关联关系）。它用一条从关联关系路径到类符号的虚线表示，其中类符号包含此关联关系 的属性、操作和关联关系。这些属性、操作和关联关系适用于原始关联关系 本身。关联关系中的每个链接都有指定的特征。关联类最常见的用途是协调 多对多关系。原则上，关联关系和类的名称应该是一致的，但是在必要情况 下，也可使用不同的名称。一个退化的关联类只包含此关联关系的属性；在 这种情况下，可以忽略关联类名称，以弱化其独立性。借用并扩展前面的雇员示例。考虑一下一名雇员（职员）为另一名雇员（经 理）工作的情况。经理定期对职员进行评估，以反映出他们在一定时间内的 表现。评估不能作为经理或职员个人的属性，但是我们可以将评估信息与此关联关 系自身进行关联关系，如下所示：53Hwadee华迪实训五、关联关系关联类评估获取了与关联关系自身有关的信息。54Hwadee华迪实训五、关联关系限定关联关系可使用限定词进一步限定和定义一组与另外某个实例相关联的实例；一个对 象和一个限定词的值可以确定该关联关系的一组唯一对象，从而形成一个复 合关键字。限定通常会降低关联关系另外一端角色的多重性；多重性净值显 示相关类中有多少个实例与第一个类以及给定限定词的值相关联。限定词表 示为关联关系一端紧靠限定类的小框。他们是关联关系的一部分，而不是类 的一部分。一个限定词框可以包含多个限定词的值；限定以整个值列表为基 础。限定关联关系是关联关系属性的一种变体。示例考虑对明细分类项和产品之间的关联关系进行的以下改进：明细分类项与所 订购的产品之间存在关联关系。每个明细分类项引用且只涉及一件产品，而 一件产品则可以在多个明细分类项中订购。通过使用限定词产品代码对该关 联关系进行限定，我们还指出每个产品具有一个唯一的产品代码，而明细分 类项则是通过这个产品代码与产品相关联的。55Hwadee华迪实训五、关联关系Line ItemPr oductcode:UPCPr oduct descr iption:Str ing unit pr ice:Double明细分类项和产品之间的关联关系具有限定词产品代码。N维关联关系N维关联关系是指在三个或更多类之间的关联关系，其中单个类可以多次出 现。N维关联关系表示为一个大菱形，菱形上对应每个参与类都有一条关联 关系路径发出。这是关联关系的实体关系模型的传统符号。为简洁起见，二 元关联关系不用菱形表示，因为实际模型中大多数是二元关联关系。N维 56Hwadee华迪实训六、聚合关系关联关系相当少见，而且可以将他们晋升为类来建模。N维关联关系还可以 有关联类；这可用菱形到类符号的虚线来表示。角色可以有角色名称，但是 多重性更加复杂，最好是通过列出备选关键字来加以说明。如果给出了多重 性，那么它代表的实例数量对应于所指定的其他N-1个对象组。多数N维 关联关系都可以使用限定的关联关系或者关联类来消除。他们还可以被普通 类替代，尽管这会失去一种限制，即一个指定的参与对象元组只能有一个链 接。聚合关系是一种特殊的关联关系，它用于对聚合关系体与其组成部分之间的 关系进行建模。有许多组成关系的示例：图书馆包括大量的书籍，公司部门由雇员组成，计 算机由许多设备组成。如果对此进行建模，那么聚合关系体（部门）与其组 成部分（雇员）之间存在聚合关系关联关系。在关联关系路径上，用位于聚合