搜索
1UML的9种图例的总结一、用例图1、定义用例定义：用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。（这是UML对用例的正式定义，可以这样去理解，用例是参与者想要系统做的事情，用例在画图中用椭圆来表示，椭圆下面附上用例名称）。用例图定义：由参与者（Actor）、用例（UseCase）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。2、用途用例图（UserCase）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。用例图主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。3、组成元素以及元素之间的关系说明用例图由参与者（Actor）、用例（UseCase）、系统边界（用矩形表示—注明系统名称）、箭头组成，用画图的方法来完成。参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界2的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。元素之间的关系：用例图中包含的元素除了系统边界、角色和用例，另外就是关系。关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。角色之间的关系：角色之间的关系。由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系（泛化关系可以先简单理解为继承），泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。用例之间的关系：包含关系：基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML1.3以后的版本中用例之间是包含和扩展这两种关系。泛化关系：它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。扩展关系扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。用例的泛化、包含、扩展关系的比较。一般来说可以使用“isa”和“hasa”来判断使用那种关系。泛化和扩展关系表示用例之间是“isa”关系，包含关系表示用例之间是“hasa”关系。扩展与泛化相比多了扩展点，扩展用例只能在基本用例的扩展点上进行扩展。在扩展关系中基本用例是独立存在。在包含关系中执行基本用例的时候一定会执行包含用例。（1）如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。（2）当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。（3）当描述正常行为的变形希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系。扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。通常先获得基本用例，针对这3个用例中的每一个行为提问：该步骤会出什么差错？该步骤有不同的情况吗？该步骤的工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。通常基本用例很容易构造，而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。用例之间的关系举例：包含：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。扩展：系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。泛化：子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。4、画法例子4二、类图1、定义类图Classdiagram通过显示出系统的类以及这些类之间的关系来表示系统。类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响。在系统分析阶段将类分成三种类型：实体类、边界类、控制类边界类用于描述外部参与者与系统之间的交互。识别边界类可以帮助开发人员识别出用户对界面的需求。实体类主要是作为数据管理和业务逻辑处理层面上存在的类别；它们主要在分析阶段区分。实体类的主要职责是存储和管理系统内部的信息，它也可以有行为，甚至很复杂的行为，但这些行为必须与它所代表的实体对象密切相关。控制类用于描述一个用例所具有的事件流控制行为，控制一个用例中的事件顺序。2、用途类图的目的是显示建模系统的类型，描述组成系统的对象内容与对象之间的关系。3、组成元素以及元素之间的关系说明类名类的UML表示是一个长方形，垂直地分为三个区，如图1所示。顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。图1显示一个航线班机如何作为UML类建模。正如我们所能见到的，名字是Flight，我们可以在中间区域看到Flight类的3个属性：flightNumber，departureTime和flightDuration。在底部区域中我们可以看到Flight类有两个操作：delayFlight和getArrivalTime。5图1:Flight类的类图类属性列表类的属性节（中部区域）在分隔线上列出每一个类的属性。属性节是可选择的，要是一用它，就包含类的列表显示的每个属性。如下格式：name:attributetypeflightNumber:Integer继续我们的Flight类的例子，我们可以使用属性类型信息来描述类的属性，如表1所示。表1：具有关联类型的Flight类的属性名字属性名称属性类型flightNumberIntegerdepartureTimeDateflightDurationMinutes在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。在类图上显示具有默认值的特定属性，有时是有用的（例如，在银行账户应用程序中，一个新的银行账户会以零为初始值）。UML规范允许在属性列表节中，通过使用如下的记号作为默认值的标识：name:attributetype=defaultvalue举例来说：balance:Dollars=0显示属性默认值是可选择的；图2显示一个银行账户类具有一个名为balance的类型，它的默认值为0。6图2：显示默认为0美元的balance属性值的银行账户类图。类操作列表类操作记录在类图长方形的第三个（最低的）区域中，它也是可选择的。和属性一样，类的操作以列表格式显示，每个操作在它自己线上。操作使用下列记号表现：name(parameterlist):typeofvaluereturned图3显示，delayFlight操作有一个Minutes类型的输入参数--numberOfMinutes。然而，delayFlight操作没有返回值。1当一个操作有参数时，参数被放在操作的括号内；每个参数都使用这样的格式：“参数名：参数类型”。图3：Flight类操作参数，包括可选择的“in”标识。当文档化操作参数时，你可能使用一个可选择的指示器，以显示参数到操作的输入参数、或输出参数。这个可选择的指示器以“in”或“out”出现，如图3中的操作区域所示。一般来说，除非将使用一种早期的程序编程语言，如Fortran，这些指示器可能会有所帮助，否则它们是不必要的。然而，在C++和Java中，所有的参数是“in”参数，而且按照UML规范，既然“in”是参数的默认类型，大多数人将会遗漏输入/输出指示器。继承在面向对象的设计中一个非常重要的概念，继承，指的是一个类（子类）继承另外的一个类（超类）的同一功能，并增加它自己的新功能（一个非技术性的比喻，想象我继承了我母亲的一般的音乐能力，但是在我的家里，我是唯一一个玩电吉他的人）的7能力。为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的，单键头（或三角形）的实线指向超类。考虑银行账户的类型：图4显示CheckingAccount和SavingsAccount类如何从BankAccount类继承而来。图4:继承通过指向超类的一条闭合的，单箭头的实线表示。在图4中，继承关系由每个超类的单独的线画出，这是在IBMRationalRose和IBMRationalXDE中使用的方法。然而，有一种称为树标记的备选方法可以画出继承关系。当存在两个或更多子类时，如图4中所示，除了继承线象树枝一样混在一起外，你可以使用树形记号。图5是重绘的与图4一样的继承，但是这次使用了树形记号。8图5:一个使用树形记号的继承实例抽象类及操作细心的读者会注意到，在图4和图5中的图中,类名BankAccount和withdrawal操作使用斜体。这表示，BankAccount类是一个抽象类，而withdrawal方法是抽象的操作。换句话说，BankAccount类使用withdrawal规定抽象操作，并且CheckingAccount和SavingsAccount两个子类都分别地执行它们各自版本的操作。然而，超类（父类）不一定要是抽象类。标准类作为超类是正常的。关联当你系统建模时，特定的对象间将会彼此关联，而且这些关联本身需要被清晰地建模。有五种关联。在这一部分中，我将会讨论它们中的两个--双向的关联和单向的关联，而且我将会在Beyondthebasics部分讨论剩下的三种关联类型。请注意，关于何时该使用每种类型关联的详细讨论，不属于本文的范围。相反的，我将会把重点集中在每种关联的用途，并说明如何在类图上画出关联。双向（标准）的关联关联是两个类间的联接。关联总是被假定是双向的；这意味着，两个类彼此知道它们间的联系，除非你限定一些其它类型的关联。回顾一下Flight的例子，图6显示了在Flight类和Plane类之间的一个标准类型的关联。9图6：在一个Flight类和Plane类之间的双向关联的实例一个双向关联用两个类间的实线表示。在线的任一端，你放置一个角色名和多重值。图6显示Flight与一个特定的Plane相关联，而且Flight类知道这个关联。因为角色名以Plane类表示，所以Plane承担关联中的“assignedPlane”角色。紧接于Plane类后面的多重值描述0...1表示，当一个Flight实体存在时，可以有一个或没有Plane与之关联（也就是，Plane可能还没有被分配）。图6也显示Plane知道它与Flight类的关联。在这个关