点击刷新
- 类图
类图用于表示类的静态内容以及它们之间的关系，在其中可以显示出类的成员变量和成员函数，以及类之间的继承和引用关系。
类的UML表示是一个长方形，垂直地分为三个区，顶部区域显示类的名字，中间的区域列出类的属性，底部的区域列出类的操作。
- 分类
-
- 类
- interface
- utility
- abstract（斜体表示）
- 可见性
-
- + public
- # protected
- - private
- ~ package
- 类的属性
类的属性节在分隔线上列出每一个类的属性。属性节是可选择的，要是一用它，就包含类的列表显示的每个属性。在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的。然而用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的模型的类型之中。
|
-
-
- 属性关联类型
-
|
-
-
- 属性默认值
-
 |
- 类的操作
类的操作记录在类图长方形的第三个区域中，它也是可选择的。和属性一样，类的操作以列表格式显示，每个操作在它自己线上。操作使用下列记号表现
name(parameter list) : type of value returned
 |
- 继承关系
继承指的是一个子类继承一个父类的功能，并增加它自己的新功能。为了在一个类图上建模继承，从子类拉出一条闭合的单键头（或三角形）的实线指向父类。
在上图中，继承关系由每个父类的单独的线画出，这是在IBM Rational Rose和IBM Rational XDE中使用的方法。然而，有一种称为树标记的备选方法可以画出继承关系。当存在两个或更多子类时，除了继承线象树枝一样混在一起外，你可以使用树形记号。
- 关联关系
-
- 双向关联
关联是两个类间的联接。关联总是被假定是双向的；这意味着，两个类彼此知道它们间的联系，除非你限定一些其它类型的关联。
一个双向关联用两个类间的实线表示。在线的任一端，你放置一个角色名和多重值。Flight与一个特定的Plane相关联，而且Flight类知道这个关联。因为角色名以Plane类表示，所以Plane承担关联中的“assignedPlane”角色。紧接于Plane类后面的多重值描述0...1表示，当一个Flight实体存在时，可以有一个或没有Plane与之关联。也显示Plane知道它与Flight类的关联。在这个关联中，Flight承担“assignedFlights”角色；Plane实体可以不与flight关联或与没有上限的flight关联。
-
- 单向关联
一个单向的关联，表示为一条带有指向已知类的开放箭头的实线。如同标准关联，单向关联包括一个角色名和一个多重值描述，但是与标准的双向关联不同的时，单向关联只包含已知类的角色名和多重值描述。OverdrawnAccountsReport 知道 BankAccount 类，而且知道 BankAccount 类扮演“overdrawnAccounts”的角色。然而，和标准关联不同，BankAccount 类并不知道它与 OverdrawnAccountsReport 相关联。
-
- 关联类
-
- 聚合关系
聚合是一种特别类型的关联，用于描述“总体到局部”的关系。在基本的聚合关系中，部分类的生命周期独立于整体类的生命周期。
举例来说，我们可以想象，车是一个整体实体，而车轮、轮胎是整辆车的一部分。轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。在这个实例中，Wheel类实例清楚地独立地Car类实例而存在。然而，有些情况下，部分类的生命周期并不独立于整体类的生命周期，这称为合成聚合。举例来说，考虑公司与部门的关系。公司和部门都建模成类，在公司存在之前，部门不能存在。这里Department类的实例依赖于Company类的实例而存在。
-
- 组合关系
组合关系是聚合关系的进一步强化，子类实例的生命周期依赖于父类实例的生命周期。在图中，显示了Company类和Department类之间的组合关系，注意组合关系如聚合关系一样绘制，不过这次菱形是被填充的。在图中的关系建模中，一个Company类实例至少总有一个Department类实例。因为关系是组合关系，当Company实例被移除/销毁时，Department实例也将自动地被移除/销毁。组合聚合的另一个重要功能是部分类只能与父类的实例相关。
-
- 反射关系
类也可以使用反射关联与它本身相关联。起先，这可能没有意义，但是记住，类是抽象的。下图显示一个Employee类如何通过manager / manages角色与它本身相关。当一个类关联到它本身时，这并不意味着类的实例与它本身相关，而是类的一个实例与类的另一个实例相关。图描绘的关系说明一个Employee实例可能是另外一个Employee实例的经理。然而，因为“manages”的关系角色有 0..*的多重性描述；一个雇员可能不受任何其他雇员管理。
- 依赖关系
依赖关系是表示“使用”的语义，一个类依赖另一个类并且总是单向的，用带有箭头的虚线表示。可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用。
- 实现关系
实现关系是一个类定义声明，另一个类来实现它。一条带有闭合的单向箭头的点线意味着实现。
- 多重值和它们的表示
|
||||||||||||||||||||
- 实例
当一个系统结构建模时，显示例子类实例有时候是有用的。实例的记号和类一样，但是取代顶端区域中仅有的类名，它的名字是经过拼接的。
Instance Name : Class Name
|
因为显示实例的目的是显示值得注意的或相关的信息，没必要在你的模型中包含整个实体属性及操作。相反地，仅仅显示感兴趣的属性及其值是完全恰当的。
然而，仅仅表现一些实例而没有它们的关系不太实用；因此，UML也允许在实体层的关系/关联建模。绘制关联与一般的类关系的规则一样，除了在建模关联时有一个附加的要求。附加的限制是，关联关系必须与类图的关系相一致，而且关联的角色名字也必须与类图相一致。
- 角色
建模类的实例有时比期望的更为详细。有时，你可能仅仅想要在一个较多的一般层次做类关系的模型。在这种情况下，你应该使用角色记号。角色记号类似于实例记号。为了建立类的角色模型，你画一个方格，并在内部放置类的角色名及类名，作为实体记号，但是在这情况你不能加下划线。注意，你不能在纯粹类图中做类角色的建模，为了使用角色记号，你将会需要使用下面讨论的内部结构记号。
- 内部的结构
UML结构图的更有用的功能之一是新的内部结构记号。它允许你显示一个类或另外的一个分类器如何在内部构成。因为记号限制你只能显示一个类所拥有的聚合关系。内部的结构记号让你更清楚地显示类的各个部分如何保持关系。
让我们看一个实例。在图中我们有一个类图以表现一个Plane类如何由四个引擎和两个控制软件对象组成。从这个图中省略的东西是显示关于飞机部件如何被装配的一些信息。你无法说明，是每个控制软件对象控制两个引擎，还是一个控制软件对象控制三个引擎，而另一个控制一个引擎。
绘制类的内在结构将会改善这种状态。开始时，你通过用二个区域画一个方格。最顶端的区域包含类名字，而较低的区域包含类的内部结构，显示在它们父类中承担不同角色的部分类，角色中的每个部分类也关系到其它类。下图显示了Plane类的内部结构；注意内部结构如何澄清混乱性。
- 软件包
软件包使建模者能够组织模型分类器到名字空间中，这有些象文件系统中的文件夹。把一个系统分为多个软件包使系统变成容易理解，尤其是在每个软件包都表现系统的一个特定部分时。
© 著作权归作者所有
举报
相关热门文章
发表评论
0/200
