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

UML的9种图例的总结一、 用例图1、 定义用例定义：用例是对包括变量在的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果〔这是UML对用例的正式定义，可以这样去理解，用例是参与者想要系统做的事情，用例在画图中用椭圆来表示，椭圆下面附上用例名称〕用例图定义：由参与者〔Actor〕、用例〔Use Case〕以与它们之间的关系构成的用于描述系统功能的动态视图称为用例图2、 用途用例图〔User Case〕是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以与它们之间的关系，主要用于对系统、子系统或类的功能行为进展建模用例图主要的作用有三个：〔1〕获取需求；〔2〕指导测试；〔3〕还可在整个过程中的其它工作流起到指导作用3、 组成元素以与元素之间的关系说明用例图由参与者〔Actor〕、用例〔Use Case〕、系统边界〔用矩形表示—注明系统名称〕、箭头组成，用画图的方法来完成参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色因此参与者可以是人，可以是事物，也可以是时间或其他系统等等还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。

系统边界是用来表示正在建模系统的边界边界表示系统的组成局部，边界外表示系统外部系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略 箭头用来表示参与者和系统通过相互发送信号或消息进展交互的关联关系箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动元素之间的关系：用例图中包含的元素除了系统边界、角色和用例，另外就是关系关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系 角色之间的关系 ：角色之间的关系由于角色实质上也是类，所以它拥有与类一样的关系描述，即角色之间存在泛化关系〔泛化关系可以先简单理解为继承〕，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为 用例之间的关系： l 包含关系：根本用例的行为包含了另一个用例的行为根本用例描述在多个用例中都有的公共行为包含关系本质上是比拟特殊的依赖关系它比一般的依赖关系多了一些语义在包含关系中箭头的方向是从根本用例到包含用例在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。

在UML1.3以后的版本中用例之间是包含和扩展这两种关系 l 泛化关系：它的意思和面向对象程序设计中的继承的概念是类似的不同的是继承使用在实施阶段，泛化使用在分析、设计阶段在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义 l 扩展关系扩展关系的根本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规那么限制，根本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义与包含关系一样，扩展关系也是依赖关系的版型在扩展关系中，箭头的方向是从扩展用例到根本用例，这与包含关系是不同的 　　用例的泛化、包含、扩展关系的比拟一般来说可以使用“is a〞和“has a〞来判断使用那种关系泛化和扩展关系表示用例之间是“is a〞关系，包含关系表示用例之间是“has a〞关系扩展与泛化相比多了扩展点，扩展用例只能在根本用例的扩展点上进展扩展在扩展关系中根本用例是独立存在在包含关系中执行根本用例的时候一定会执行包含用例〔1〕如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个根本用例对另一个的引用〔2〕当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。

〔3〕当描述正常行为的变形希望采用更多的控制方式时，可以在根本用例中设置扩展点，使用扩展关系扩展关系比拟难理解，如果把扩展关系看作是带有更多规那么限制的泛化关系，可以帮助理解通常先获得根本用例，针对这个用例中的每一个行为提问：该步骤会出什么过失？该步骤有不同的情况吗？该步骤的工作怎样以不同的方式进展等，把所有的变化情况都标识为扩展通常根本用例很容易构造，而扩展用例需要反复分析、验证当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的局部从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系 用例之间的关系举例：包含：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以与修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，那么划分太细这时包含关系可以用来理清关系 扩展：系统中允许用户对查询的结果进展导出、打印对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的导入、打印和查询相对独立，而且为查询添加了新行为 泛化：子用例将继承父用例的所有结构、行为和关系子用例可以使用父用例的一段行为，也可以重载它。

父用例通常是抽象的4、 画法例子二、 类图1、 定义类图Class diagram通过显示出系统的类以与这些类之间的关系来表示系统类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响在系统分析阶段将类分成三种类型：实体类、边界类、控制类边界类用于描述外部参与者与系统之间的交互识别边界类可以帮助开发人员识别出用户对界面的需求实体类主要是作为数据管理和业务逻辑处理层面上存在的类别； 它们主要在分析阶段区分 实体类的主要职责是存储和管理系统部的信息，它也可以有行为，甚至很复杂的行为，但这些行为必须与它所代表的实体对象密切相关控制类用于描述一个用例所具有的事件流控制行为，控制一个用例中的事件顺序2、 用途类图的目的是显示建模系统的类型，描述组成系统的对象容与对象之间的关系3、 组成元素以与元素之间的关系说明类名类的 UML 表示是一个长方形，垂直地分为三个区，如图 1 所示顶部区域显示类的名字中间的区域列出类的属性底部的区域列出类的操作当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的〔当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的〕。

图 1 显示一个航线班机如何作为 UML 类建模正如我们所能见到的，名字是 Flight，我们可以在中间区域看到Flight类的3个属性：flightNumber，departureTime 和 flightDuration在底部区域中我们可以看到Flight类有两个操作：delayFlight 和 getArrivalTime图 1: Flight类的类图类属性列表类的属性节〔中部区域〕在分隔线上列出每一个类的属性属性节是可选择的，要是一用它，就包含类的列表显示的每个属性 如下格式：name : attribute typeflightNumber : Integer继续我们的Flight类的例子，我们可以使用属性类型信息来描述类的属性，如表 1 所示表 1：具有关联类型的Flight类的属性名字属性名称属性类型flightNumberIntegerdepartureTimeDateflightDurationMinutes在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的〔例如，分钟，美元，等等〕然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。

在类图上显示具有默认值的特定属性，有时是有用的〔例如，在银行账户应用程序中，一个新的银行账户会以零为初始值〕UML 规允许在属性列表节中，通过使用如下的记号作为默认值的标识：name : attribute type = default value举例来说：balance : Dollars = 0显示属性默认值是可选择的；图 2 显示一个银行账户类具有一个名为 balance的类型，它的默认值为0图 2：显示默认为0美元的balance属性值的银行账户类图类操作列表类操作记录在类图长方形的第三个〔最低的〕区域中，它也是可选择的和属性一样，类的操作以列表格式显示，每个操作在它自己线上操作使用以下记号表现： name(parameter list) : type of value returned图3显示，delayFlight 操作有一个Minutes类型的输入参数 -- numberOfMinutes然而，delayFlight 操作没有返回值1当一个操作有参数时，参数被放在操作的括号；每个参数都使用这样的格式：“参数名：参数类型〞图 3：Flight类操作参数，包括可选择的“in〞标识。

当文档化操作参数时，你可能使用一个可选择的指示器，以显示参数到操作的输入参数、或输出参数这个可选择的指示器以“in〞或“out〞出现，如图3中的操作区域所示一般来说，除非将使用一种早期的程序编程语言，如Fortran ，这些指示器可能会有所帮助，否那么它们是不必要的然而，在 C++和Java中，所有的参数是“in〞参数，而且按照UML规，既然“in〞是参数的默认类型，大多数人将会遗漏输入/输出指示器继承在面向对象的设计中一个非常重要的概念，继承，指的是一个类〔子类〕继承另外的一个类〔超类〕的同一功能，并增加它自己的新功能〔一个非技术性的比喻，想象我继承了我母亲的一般的音乐能力，但是在我的家里，我是唯一一个玩电吉他的人〕的能力为了在一个类图上建模继承，从子类〔要继承行为的类〕拉出一条闭合的，单键头〔或三角形〕的实线指向超类考虑银行账户的类型：图 4 显示 CheckingAccount 和 SavingsAccount 类如何从 BankAccount 类继承而来图 4: 继承通过指向超类的一条闭合的，单箭头的实线表示在图 4 中，继承关系由每个超类的单独的线画出，这是在IBM Rational Rose和IBM Rational XDE中使用的方法。

然而，有一种称为 树标记的备选方法可以画出继承关系当存在两个或更多子类时，如图 4 中所示，除了继承线象树枝一样混在一起外，你可以使用树形记号图 5 是重绘的与图 4 一样的继承，但是这次使用了树形记号图 5: 一个使用树形记号的继承实例抽象类与操作细心的读者会注意到，在图 4 和 图5 中的图中,类名BankAccount和withdrawal操作使用斜体这表示，BankAccount 类是一个抽象类，而withdrawal方法是抽象的操作换句话说，BankAccount 类使用withdrawal规定抽象操作，并且CheckingAccount 和 SavingsAccount 两个子类都分别地执行它们各自版本的操作然而，超类〔父类〕不一定要是抽象类标准类作为超类是正常的关联当你系统建模时，特定的对象间将会彼此关联，而且这些关联本身需要被清晰地建模有五种关联在这一局部中，我将会讨论它们中的两个 -- 双向的关联和单向的关联，而且我将会在Beyond the basics局部讨论剩下的三种关联类型请注意，关于何时该使用每种类型关联的详细讨论，不属于本文的围相反的，我将会把重点集中在每种关联的用途，并说明如何在类图上画出关联。

双向〔标准〕的关联关联是两个类间的联。