1、UML的9种图例的总结一、用例图1、定义用例定义：用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。（这是UML对用例的正式定义，可以这样去理解，用例是参与者想要系统做的事情，用例在画图中用椭圆来表示，椭圆下面附上用例名称）。用例图定义：由参与者（Actor）、用例（UseCase）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。2、用途用例图（UserCase）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。用例图主要的
3、者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。元素之间的关系：用例图中包含的元素除了系统边界、角色和用例，另外就是关系。关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。角色之间的关系：角色之间的关系。由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系（泛化关系可以先简单理解为继承），泛化关系的含义是把某些角色的共同行为提取出来表示为通用
4、的行为。用例之间的关系：l包含关系：基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML1.3以后的版本中用例之间是包含和扩展这两种关系。l泛化关系：它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。l
6、包含用例。（1）如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。（2）当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。（3）当描述正常行为的变形希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系。扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。通常先获得基本用例，针对这个用例中的每一个行为提问：该步骤会出什么差错？该步骤有不同的情况吗？该步骤的工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。通常基本用例很容易构造，而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时，
7、可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。用例之间的关系举例：包含：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。扩展：系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。泛化：子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可
9、流控制行为，控制一个用例中的事件顺序。2、用途类图的目的是显示建模系统的类型，描述组成系统的对象内容与对象之间的关系。3、组成元素以及元素之间的关系说明类名类的UML表示是一个长方形，垂直地分为三个区，如图1所示。顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。图1显示一个航线班机如何作为UML类建模。正如我们所能见到的，名字是Flight，我们可以在中间区域看到Flight类的3个属性：flight
10、Number，departureTime和flightDuration。在底部区域中我们可以看到Flight类有两个操作：delayFlight和getArrivalTime。图1:Flight类的类图类属性列表类的属性节（中部区域）在分隔线上列出每一个类的属性。属性节是可选择的，要是一用它，就包含类的列表显示的每个属性。如下格式：name:attributetypeflightNumber:Integer继续我们的Flight类的例子，我们可以使用属性类型信息来描述类的属性，如表1所示。表1：具有关联类型的Flight类的属性名字属性名称属性类型flightNu
11、mberIntegerdepartureTimeDateflightDurationMinutes在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。在类图上显示具有默认值的特定属性，有时是有用的（例如，在银行账户应用程序中，一个新的银行账户会以零为初始值）。UML规范允许在属性列表节中，通过使用如下的记号作为默认值的标识：name:attributetype=defaultvalue举例来说：balance:Doll
12、ars=0显示属性默认值是可选择的；图2显示一个银行账户类具有一个名为balance的类型，它的默认值为0。图2：显示默认为0美元的balance属性值的银行账户类图。类操作列表类操作记录在类图长方形的第三个（最低的）区域中，它也是可选择的。和属性一样，类的操作以列表格式显示，每个操作在它自己线上。操作使用下列记号表现：name(parameterlist):typeofvaluereturned图3显示，delayFlight操作有一个Minutes类型的输入参数-numberOfMinutes。然而，delayFlight操作没有返回值。1当一个操作有参数时
13、，参数被放在操作的括号内；每个参数都使用这样的格式：“参数名：参数类型”。图3：Flight类操作参数，包括可选择的“in”标识。当文档化操作参数时，你可能使用一个可选择的指示器，以显示参数到操作的输入参数、或输出参数。这个可选择的指示器以“in”或“out”出现，如图3中的操作区域所示。一般来说，除非将使用一种早期的程序编程语言，如Fortran，这些指示器可能会有所帮助，否则它们是不必要的。然而，在C+和Java中，所有的参数是“in”参数，而且按照UML规范，既然“in”是参数的默认类型，大多数人将会遗漏输入/输出指示器。继承在面向对象的设计中一个非常重要的概念，继承，指的是一个类
14、（子类）继承另外的一个类（超类）的同一功能，并增加它自己的新功能（一个非技术性的比喻，想象我继承了我母亲的一般的音乐能力，但是在我的家里，我是唯一一个玩电吉他的人）的能力。为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的，单键头（或三角形）的实线指向超类。考虑银行账户的类型：图4显示CheckingAccount和SavingsAccount类如何从BankAccount类继承而来。图4:继承通过指向超类的一条闭合的，单箭头的实线表示。在图4中，继承关系由每个超类的单独的线画出，这是在IBMRationalRose和IBMRationalXDE中
15、使用的方法。然而，有一种称为树标记的备选方法可以画出继承关系。当存在两个或更多子类时，如图4中所示，除了继承线象树枝一样混在一起外，你可以使用树形记号。图5是重绘的与图4一样的继承，但是这次使用了树形记号。图5:一个使用树形记号的继承实例抽象类及操作细心的读者会注意到，在图4和图5中的图中,类名BankAccount和withdrawal操作使用斜体。这表示，BankAccount类是一个抽象类，而withdrawal方法是抽象的操作。换句话说，BankAccount类使用withdrawal规定抽象操作，并且CheckingAccount和SavingsAc
16、count两个子类都分别地执行它们各自版本的操作。然而，超类（父类）不一定要是抽象类。标准类作为超类是正常的。关联当你系统建模时，特定的对象间将会彼此关联，而且这些关联本身需要被清晰地建模。有五种关联。在这一部分中，我将会讨论它们中的两个-双向的关联和单向的关联，而且我将会在Beyondthebasics部分讨论剩下的三种关联类型。请注意，关于何时该使用每种类型关联的详细讨论，不属于本文的范围。相反的，我将会把重点集中在每种关联的用途，并说明如何在类图上画出关联。双向（标准）的关联关联是两个类间的联接。关联总是被假定是双向的；这意味着，两个类彼此知道它们间的联系，除非你限定一些其它类
19、财务报告的一个实例。图7:单向关联一个实例：OverdrawnAccountsReport类BankAccount类，而BankAccount类则对关联一无所知。一个单向的关联，表示为一条带有指向已知类的开放箭头（不关闭的箭头或三角形，用于标志继承）的实线。如同标准关联，单向关联包括一个角色名和一个多重值描述，但是与标准的双向关联不同的时，单向关联只包含已知类的角色名和多重值描述。在图7中的例子中，OverdrawnAccountsReport知道BankAccount类，而且知道BankAccount类扮演“overdrawnAccounts”的角色。然而，和标准
21、套在一个大的长方形中开始的，如图8所示。但是建模者必须决定包的成员如何表示，如下：如果建模者决定在大长方形中显示软件包的成员，则所有的那些成员4需要被放置在长方形里面。另外，所有软件包的名字需要放在软件包的较小长方形之内（如图8的显示）。如果建模者决定在大的长方形之外显示软件包成员，则所有将会在图上显示的成员都需要被置于长方形之外。为了显示属于软件包的分类器，从每个分类器画一条线到里面有加号的圆周，这些圆周粘附在软件包之上（图9）。图8：在软件包的长方形内显示软件包成员的软件包元素例子图9：一个通过连接线表现软件包成员的软件包例子在UML2中，了解类图的基础更为重要。这
22、是因为类图为所有的其他结构图提供基本的构建块。如组件或对象图（仅仅是举了些例子）。在下面的部分中，会使用的类图的更重要的方面。这些包括UML2规范中的接口，其它的三种关联类型，可见性和其他补充。接口在本文的前面，我建议你以类来考虑分类器。事实上，分类器是一个更为一般的概念，它包括数据类型和接口。关于何时、以及如何高效地在系统结构图中使用数据类型和接口的完整讨论，不在本文的讨论范围之内。既然这样，我为什么要在这里提及数据类型和接口呢？你可能想在结构图上模仿这些分类器类型，在这个时候，使用正确的记号来表示，或者至少知道这些分类器类型是重要的。不正确地绘制这些分类器，很有可能将使你的结构图读者感
23、到混乱，以后的系统将不能适应需求。一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在UML2中，一个接口被认为是类建模元素的特殊化。因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”，如图10所示。5图10：Professor类和Student类实现Person接口的类图实例在图10中显示的图中，Professor和Student类都实现了Person的接口，但并不从它继承。我们知道这一点是由于下面两个原因：1)Person对象作为接口被定义-它在对象的名字区域中有“interface”文本，而且我们看到
24、由于Professor和Student对象根据画类对象的规则（在它们的名字区域中没有额外的分类器文本）标示，所以它们是类对象。2)我们知道继承在这里没有被显示，因为与带箭头的线是点线而不是实线。如图10所示，一条带有闭合的单向箭头的点线意味着实现（或实施）；正如我们在图4中所见到的，一条带有闭合单向箭头的实线表示继承。更多的关联在上面，我讨论了双向关联和单向关联。现在，我将会介绍剩下的三种类型的关联。（1）关联类在关联建模中，存在一些情况下，你需要包括其它类，因为它包含了关于关联的有价值的信息。对于这种情况，你会使用关联类来绑定你的基本关联。关联类和一般类一样表示。不同的是
25、，主类和关联类之间用一条相交的点线连接。图11显示一个航空工业实例的关联类。图11：增加关联类MileageCredit在图11中显示的类图中，在Flight类和FrequentFlyer类之间的关联，产生了称为MileageCredit的关联类。这意味当Flight类的一个实例关联到FrequentFlyer类的一个实例时，将会产生MileageCredit类的一个实例。（2）聚合聚合是一种特别类型的关联，用于描述“总体到局部”的关系。在基本的聚合关系中，部分类的生命周期独立于整体类的生命周期。举例来说，我们可以想象，车是一个整体实体，而车轮轮胎是整辆
29、*的多重性描述；一个雇员可能不受任何其他雇员管理。可见性在面向对象的设计中，存在属性及操作可见性的记号。UML识别四种类型的可见性：public，protected，private及package。UML规范并不要求属性及操作可见性必须显示在类图上，但是它要求为每个属性及操作定义可见性。为了在类图上的显示可见性，放置可见性标志于属性或操作的名字之前。虽然UML指定四种可见性类型，但是实际的编程语言可能增加额外的可见性，或不支持UML定义的可见性。表4显示了UML支持的可见性类型的不同标志。表4：UML支持的可见性类型的标志标志可见性类型+Public#Protected-
30、PrivatePackage现在，让我们看一个类，以说明属性及操作的可见性类型。在图15中，所有的属性及操作都是public，除了updateBalance操作。updateBalance操作是protected。图15：一个BankAccount类说明它的属性及操作的可见性UML2补充既然我们已经覆盖了基础和高级主题，我们将覆盖一些由UML1.x增加的类图的新记号。（1）实例（具体对象）是一个具体的对象当一个系统结构建模时，显示例子类实例有时候是有用的。为了这种结构建模，UML2提供实例规范元素，它显示在系统中使用例子（或现实）实例的值得注意的信息。实例的记
34、示类的各个部分如何保持关系。让我们看一个实例。在图18中我们有一个类图以表现一个Plane类如何由四个引擎和两个控制软件对象组成。从这个图中省略的东西是显示关于飞机部件如何被装配的一些信息。从图18无法说明，是每个控制软件对象控制两个引擎，还是一个控制软件对象控制三个引擎，而另一个控制一个引擎。图18:只显示对象之间关系的类图绘制类的内在结构将会改善这种状态。开始时，你通过用二个区域画一个方格。最顶端的区域包含类名字，而较低的区域包含类的内部结构，显示在它们父类中承担不同角色的部分类，角色中的每个部分类也关系到其它类。图19显示了Plane类的内部结构；注意内部结构如何澄清混乱
35、性。图20：Plane类的内部结构例子。在图20中Plane有两个ControlSoftware对象，而且每个控制二个引擎。在图左边上的ControlSoftware（control1）控制引擎1和2。在图右边的ControlSoftware（control2）控制引擎3和4。结论：至少存在两个了解类图的重要理由。第一个是它显示系统分类器的静态结构；第二个理由是类图为UML描述的其他结构图提供了基本记号。开发者将会认为类图是为他们特别建立的；但是其他的团队成员将发现它们也是有用的。业务分析师可以用类图，为系统的业务远景建模。4、画法例子三、对象图1、定义对象
37、系，合作图显示处于语境中的对象原型（类元角色）。对象图的用途如下：捕获实例和连接在分析和设计阶段创建捕获交互的静态部分举例说明数据/对象结构详细描述瞬态图由分析人员、设计人员和代码实现人员开发3、组成元素以及元素之间的关系说明表示法:对于对象图来说无需提供单独的形式。类图中就包含了对象，所以只有对象而无类的类图就是一个对象图。然而，对象图这条短语在刻画各方面特定使用时非常有用。对象图显示对象集及其联系，代表了系统某时刻的状态。它包含带有值的对象，而非描述符，当然，在许多情况下对象可以是原型。用合作图可显示一个可多次实例化的对象及其联系的总体模型，合作图包含对象和链的描述符（
38、类元角色和联系角色）。如果合作图实例化，则产生了对象图。对象图不显示系统的演化过程。为此目的，可用带消息的合作图，或用顺序图表示一次交互。类图与对象图的区别：类图对象图在类中包含三部分，分别是类名、类的属性和类的操作对象包含两个部分：对象的名称和对象的属性类的名称栏只包含类名对象的名称栏包含“对象名：类名”类的属性栏定义了所有属性的特征对象的属性栏定义了属性的当前值类中列出了操作对象图中不包含操作内容，因为对属于同一个类的对象，其操作是相同的类中使用了关联连接，关联中使用名称、角色以及约束等特征定义对象使用链进行连接，链中包含名称、角色类是一类对象的抽象，类不存在多重性对象可以具有多重性4、
40、换的组件来实现。但是，并不象在UML1.x中，现在，组件必须有严格的逻辑，设计时构造。主要思想是，你能容易地在你的设计中重用及/或替换一个不同的组件实现，因为一个组件封装了行为，实现了特定接口（可以理解为将接口的定义与实现封装在一起的明确使用范围的组合）。2、用途组件图的主要目的是显示系统组件间的结构关系。在以组件为基础的开发（CBD）中，组件图为架构师提供一个开始为解决方案建模的自然形式。组件图允许一个架构师验证系统的必需功能是由组件实现的，这样确保了最终系统将会被接受。除此之外，组件图对于不同的小组是有用的交流工具。图可以呈现给关键项目发起人及实现人员。通常，当组件图将系统的实现人
41、员连接起来的时候，组件图通常可以使项目发起人感到轻松，因为图展示了对将要被建立的整个系统的早期理解。开发者发现组件图是有用的，因为组件图给他们提供了将要建立的系统的高层次的架构视图，这将帮助开发者开始建立实现的路标，并决定关于任务分配及（或）增进需求技能。系统管理员发现组件图是有用的，因为他们可以获得将运行于他们系统上的逻辑软件组件的早期视图。虽然系统管理员将无法从图上确定物理设备或物理的可执行程序，但是，他们仍然欢迎组件图，因为它较早地提供了关于组件及其关系的信息（这允许系统管理员轻松地计划后面的工作）。3、组成元素以及元素之间的关系说明组件符号（NOTATION）在现在，组件图符号集使它
43、组件图的符号集。在维持它易于理解的条件下，UML2符号能够调节得更好，并且符号集也具有更多的信息。让我们依照UML2规范一步步建立组件图。（1）基础：现在，在UML2中画一个组件很类似于在一个类图上画一个类。事实上，在UML2中，一个组件仅仅是类概念的一个特殊版本。这意味着适用于类分类器的符号规则也适用于组件分类器。在UML2中，一个组件被画成堆积着可选择小块的一个立着的长方形。UML2中，组件的一个高层次的抽象视图，可以用一个长方形建模，包括组件的名字和组件原型的文字和/或图标。组件原型的文本是“component”，而组件原型图标是在左边有两个凸出的小长方
44、形的一个大长方形（UML1.4中组件的符号元素）。图2显示，组件可以用UML2规范中的三种不同方法表示。图2：画组件名字区的不同方法当在图上画一个组件时，重要的是，你总要包括组件原型文本（在双重尖括号中的那个component，如图2所示）和/或图标。理由呢？在UML中，没有任何原型分类器的一个长方形被解释为一个类组件。组件原型和/或图标用来区别作为组件元素的长方形。为组件提供/要求接口建模在图2中所画的Order组件表现了所有有效的符号元素；然而，一个典型的组件图包括更多的信息。一个组件元素可以在名字区下面附加额外的区。如前面所提到的，一个组件是提供一个或更多公共接口
45、的独立单元。提供的接口代表了组件提供给它的用户/客户的服务的正式契约。图3显示了Order组件有第二个区，用来表示Order组件提供和要求的接口。2图3：这里额外的区显示Order组件提供和要求的接口。在图3中的Order组件例子中，组件提供了名为OrderEntry和AccountPayable的接口。此外，组件也要求另外一个组件提供Person接口。3组件接口建模的其它方法UML2也引入另外一种方法来显示组件提供并要求的接口。这个方法是建立一个里面有组件名的大长方形，并在长方形的外面放置在UML2规范中称为接口符号的东西。这第二种方法在图4中举例说明。图4
46、:一种可选择的方法（与图3相比）：使用接口符号显示组件提供/要求的接口在这第二种方法中，在末端有一个完整的圆周的接口符号代表组件提供的接口-“棒棒糖”是这个接口分类器实现关系符号的速记法。在末端只有半个圆的接口（又称插座）符号代表组件要求的接口（在两种情况下，接口的名字被放置在接口符号本身的附近）。即使图4看起来与图3有很大的不同，但两个图都提供了相同的信息-例如，Order组件提供两个接口：OrderEntry和AccountPayable，而且Order组件要求Person接口。（2）组件关系的建模当表现组件与其它组件的关系时，棒棒糖和插座符号也必须包括一支依存箭
47、头（如类图中所用的）。在有棒棒糖和插座的组件图上，注意，依存箭从强烈的（要求的）插座引出，并且它的箭头指向供应者的棒棒糖，如图5所示。图5：显示Order系统组件如何依赖于其他组件的组件图图5显示，Order系统组件依赖于客户资源库和库存系统组件。注意在图5中复制出的接口名CustomerLookup和ProductAccessor。在这个例子中，这看起来可能是不必要的重复，不过符号确实允许在每个依赖于实现差别的组件中有不同的接口（和不同的名字）（举例来说，一个组件提供一个较小的必需的接口子类）。（3）子系统在UML2中，子系统分类器是组件分类器的一个特别版本。因
48、为这一点，子系统符号元素象组件符号元素一样继承所有的组件符号集规则。唯一的差别是，一个子系统符号元素由subsystem关键字代替了component，如图6所示。图6：子系统元素的一个例子UML2规范在如何区别子系统与组件方面相当含糊。从建模的观点，规范并不认为组件与子系统有任何区别。与UML1.x相比较，这个UML2模型歧义是新的。但是有一个理由。在UML1.x中，一个子系统被认为是一个组件包，而且这个组件包符号正对许多UML实践者造成困惑；因此，UML2中把子系统作为特殊的组件，因为这是最多的UML1.x使用者了解它的方式。这一改变确实把模糊
52、内部结构的这些描绘事实是嵌套在分类器（在我们的例子中是一个组件)里的协作图，因为协作图显示分类器中的实体或角色。在内部的组件之间建模的关系以UML称为的一个组合连接器表示。一个组合连接器绑定一个组件提供的接口到另外的一个组件的必需接口。组合连接器用紧紧相连的棒棒糖和插座符号表示。以这种方式画这些组合连接器使棒棒糖和插座成为很容易理解的符号。l结论组件图经常是一个架构师在项目的初期就建立的非常重要的图。然而，组件图的有用性跨越了系统的寿命。组件图是无价的，因为它们模型化和文档化了一个系统的架构。因为组件图文档化了系统的架构，开发者和系统可能的系统管理员会发现这一工作的关键产品有助于
53、他们理解系统。组件图也视为软件系统配置图的输入。l脚注在UML1.x中称为组件的实际项目，在UML2中称为产物。一个产物是一个物理单位，象一个文件，可运行的程序，脚本，数据库等等。只有一种产物依赖于实际的节点；类和组件没有“位置”。然而，一个产物可能显示组件和其他的分类器（例如类）。一个单一的组件可能通过多重产物显示，它们可能是在相同的或不同的节点上，因此，一个单一的组件可以间接地在多重节点上被实现。即使组件是独立的单元，它们仍然可能依赖于其他组件提供的服务。由于这一点，文档化一个组件的必需接口是很有用的。图3并不显示Order组件完整的上下文。在一个真实的模型中，OrderEnt
55、消息对应了一个类操作或状态机中引起转换的触发事件。2、用途序列图用于为使用方案的逻辑建模。使用方案恰如其名称所揭示的那样-描述使用系统的潜在方法。使用方案的逻辑可以是用例的一部分，可能是备选过程。它也可以是整个用例过程，例如由基本行动过程描述的逻辑，或者部分基本行动过程再加上一个或多个替代方案描述的逻辑。使用方案的逻辑也可以是几个用例中包含的逻辑。例如，一个学生在大学入学后，立即参加了三个研习班。序列图以可视方式为系统中逻辑的流程建模，能够让您记载和验证逻辑，这通常用于分析和设计目的。3、组成元素以及元素之间的关系说明（1）分类器横贯该图顶部的那些框表示的是分类器或它们的实例-通常是用例
56、、对象、类或参与者（往往用长方形表示，但它们也可以是符号）。因为既可以向对象发送消息，又可以向类发送消息（对象通过调用操作来响应消息，而类则通过调用静态操作来响应消息），所以有必要将它们都包括在序列图中。另外，因为参与者在使用方案中发起操作并占据主动地位，因此也要将他们包括在序列图中。对象的标签具有标准UML格式name:ClassName，其中的name是可选的。（在图中没有给出名称的对象称为匿名对象。）类标签的格式为ClassName，而参与者名的格式为ActorName-这些也都是UML标准。（2）生命线从各个框垂下来的虚线称为对象生命线，表示在对方案建模期间对象的生
57、命跨度。生命线上的细长框是方法调用框，表明正在由目标对象类执行处理，以完成消息。方法调用框底部的X是一种UML约定，表明对象已从内存中除去，这通常是接收到原型为的消息的结果。（3）为消息建模消息以带有标签的箭头表示。当消息的源和目标为对象或类时，标签是响应消息时所调用方法的签名。不过，如果源或目标中有一方是人类参与者，那么消息就用描述正在交流的信息的简要文本作为标签。例如，:EnrollInSeminar对象向Seminar的实例发送消息isEligibleToEnroll(theStudent)。请注意我是如何同时包含方法名和参数名的（如果有参数名，则传递给它）。示例中表明Student参与者通过标签为name（“姓名”）和stud