UML的9种图例的定义用途画法总结Word格式.docx

1、因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。系统边界是用来表示正在建模系统的边界。边界表示系统的组成局部，边界外表示系统外部。系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。 箭头用来表示参与者和系统通过相互发送信号或消息进展交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。元素之间的关系：用例图中包含的元素除了系统边界、角色和用例，

2、另外就是关系。关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。角色之间的关系 ：角色之间的关系。由于角色实质上也是类，所以它拥有与类一样的关系描述，即角色之间存在泛化关系泛化关系可以先简单理解为继承，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。用例之间的关系：包含关系：根本用例的行为包含了另一个用例的行为。根本用例描述在多个用例中都有的公共行为。包含关系本质上是比拟特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从根本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML1.3以后的版本中用

3、例之间是包含和扩展这两种关系。泛化关系：它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。扩展关系扩展关系的根本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规那么限制，根本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到根本用例，这与包含关系是不同的。用例的泛化、包含、扩展关系的比拟。一般来说可以使用“is a和“has a来判断

4、使用那种关系。泛化和扩展关系表示用例之间是“is a关系，包含关系表示用例之间是“has a关系。扩展与泛化相比多了扩展点，扩展用例只能在根本用例的扩展点上进展扩展。在扩展关系中根本用例是独立存在。在包含关系中执行根本用例的时候一定会执行包含用例。1如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个根本用例对另一个的引用。2当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。3当描述正常行为的变形希望采用更多的控制方式时，可以在根本用例中设置扩展点，使用扩展关系。扩展关系比拟难理解，如果把扩展关系看作是带有更多规那么限制的泛化关系，可以帮助理解。通常先获得根本用例，针对这个用例中

5、的每一个行为提问：该步骤会出什么过失？该步骤有不同的情况吗？该步骤的工作怎样以不同的方式进展等，把所有的变化情况都标识为扩展。通常根本用例很容易构造，而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的局部从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。用例之间的关系举例：包含：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以与修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，那么划分太细。这时包含关系可以用来理清关系。扩展：系统中允许用户对查询

6、的结果进展导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。泛化：子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。4、画法例子二、类图类图Class diagram通过显示出系统的类以与这些类之间的关系来表示系统。类图是静态的它们显示出什么可以产生影响但不会告诉你什么时候产生影响。在系统分析阶段将类分成三种类型：实体类、边界类、控制类边界类用于描述外部参与者与系统之间的交互。识别边界类可以帮助开发人员识别出用户对界面的需求。实体类主要是作为数据管理和业务逻

7、辑处理层面上存在的类别； 它们主要在分析阶段区分。 实体类的主要职责是存储和管理系统部的信息，它也可以有行为，甚至很复杂的行为，但这些行为必须与它所代表的实体对象密切相关。控制类用于描述一个用例所具有的事件流控制行为，控制一个用例中的事件顺序。类图的目的是显示建模系统的类型，描述组成系统的对象容与对象之间的关系。类名类的 UML 表示是一个长方形，垂直地分为三个区，如图 1 所示。顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的

8、。图 1 显示一个航线班机如何作为 UML 类建模。正如我们所能见到的，名字是 Flight，我们可以在中间区域看到Flight类的3个属性：flightNumber，departureTime 和 flightDuration。在底部区域中我们可以看到Flight类有两个操作：delayFlight 和 getArrivalTime。图 1: Flight类的类图类属性列表类的属性节中部区域在分隔线上列出每一个类的属性。属性节是可选择的，要是一用它，就包含类的列表显示的每个属性。 如下格式：name : attribute typeflightNumber : Integer继续我们的Fli

9、ght类的例子，我们可以使用属性类型信息来描述类的属性，如表 1 所示。表 1：具有关联类型的Flight类的属性名字属性名称属性类型flightNumberIntegerdepartureTimeDateflightDurationMinutes在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的例如，分钟，美元，等等。然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。在类图上显示具有默认值的特定属性，有时是有用的例如，在银行账户应用程序中，一个新的银行账户会以零为初始值。UML 规允许在属性列表节中，通过使用

10、如下的记号作为默认值的标识： attribute type = default value举例来说：balance : Dollars = 0显示属性默认值是可选择的；图 2 显示一个银行账户类具有一个名为 balance的类型，它的默认值为0。图 2：显示默认为0美元的balance属性值的银行账户类图。类操作列表类操作记录在类图长方形的第三个最低的区域中，它也是可选择的。和属性一样，类的操作以列表格式显示，每个操作在它自己线上。操作使用以下记号表现： name（parameter list） : type of value returned图3显示，delayFlight 操作有一个Min

11、utes类型的输入参数 - numberOfMinutes。然而，delayFlight 操作没有返回值。1当一个操作有参数时，参数被放在操作的括号；每个参数都使用这样的格式：“参数名：参数类型。图 3：Flight类操作参数，包括可选择的“in标识。当文档化操作参数时，你可能使用一个可选择的指示器，以显示参数到操作的输入参数、或输出参数。这个可选择的指示器以“in或“out出现，如图3中的操作区域所示。一般来说，除非将使用一种早期的程序编程语言，如Fortran ，这些指示器可能会有所帮助，否那么它们是不必要的。然而，在 C+和Java中，所有的参数是“in参数，而且按照UML规，既然“in

12、是参数的默认类型，大多数人将会遗漏输入/输出指示器。继承在面向对象的设计中一个非常重要的概念，继承，指的是一个类子类继承另外的一个类超类的同一功能，并增加它自己的新功能一个非技术性的比喻，想象我继承了我母亲的一般的音乐能力，但是在我的家里，我是唯一一个玩电吉他的人的能力。为了在一个类图上建模继承，从子类要继承行为的类拉出一条闭合的，单键头或三角形的实线指向超类。考虑银行账户的类型：图 4 显示 CheckingAccount 和 SavingsAccount 类如何从 BankAccount 类继承而来。图 4: 继承通过指向超类的一条闭合的，单箭头的实线表示。在图 4 中，继承关系由每个超类

13、的单独的线画出，这是在IBM Rational Rose和IBM Rational XDE中使用的方法。然而，有一种称为 树标记的备选方法可以画出继承关系。当存在两个或更多子类时，如图 4 中所示，除了继承线象树枝一样混在一起外，你可以使用树形记号。图 5 是重绘的与图 4 一样的继承，但是这次使用了树形记号。图 5: 一个使用树形记号的继承实例抽象类与操作细心的读者会注意到，在图 4 和 图5 中的图中,类名BankAccount和withdrawal操作使用斜体。这表示，BankAccount 类是一个抽象类，而withdrawal方法是抽象的操作。换句话说，BankAccount 类使用

14、withdrawal规定抽象操作，并且CheckingAccount 和 SavingsAccount 两个子类都分别地执行它们各自版本的操作。然而，超类父类不一定要是抽象类。标准类作为超类是正常的。关联当你系统建模时，特定的对象间将会彼此关联，而且这些关联本身需要被清晰地建模。有五种关联。在这一局部中，我将会讨论它们中的两个 - 双向的关联和单向的关联，而且我将会在Beyond the basics局部讨论剩下的三种关联类型。请注意，关于何时该使用每种类型关联的详细讨论，不属于本文的围。相反的，我将会把重点集中在每种关联的用途，并说明如何在类图上画出关联。双向标准的关联关联是两个类间的联接。关联总是被假定是双向的；这意味着，两个类彼此知道它们间的联系，除