首页 > 代码库 > 类图和对象图教程-类(Class)、接口(Interface)、协作(collaboration)、依赖关系(Dependency)、泛化关系(Generalization)、关联关系(Association)以及实现关系(Realization)
类图和对象图教程-类(Class)、接口(Interface)、协作(collaboration)、依赖关系(Dependency)、泛化关系(Generalization)、关联关系(Association)以及实现关系(Realization)
类图的概念一、概述 类图(Class Diagram)是描述类、接口、协作以及它们之间关系的图,用来显示系统中各个类的静态结构。类图是定义其他图的基础,在类图基础上,可以使用状态图、协作图、组件图和配置图等进一步描述系统其他方面的特性。 类图包括7个元素:类(Class)、接口(Interface)、协作(collaboration)、依赖关系(Dependency)、泛化关系(Generalization)、关联关系(Association)以及实现关系(Realization)。 二、类 类定义了一组有着状态和行为的对象。其中,属性和关联用来描述状态。属性通常用没有身份的数据值表示,如数字和字符串。关联则用有身份的对象之间的关系表示。行为由操作来描述,方法是操作的实现。对象的生命期则由附加给类的状态机来描述。 1、 名称:类的名称是每个类中所必有的构成元素。 2、 属性(Attribute) (1) 可见性:类中属性的可见性主要包括公有(public)、私有(Private)和受保护(Protected)。在UML中,公有类型的用“+”表达, 私有类型用“-”表达,而受保护类型则用“#”表达。UML的类中不存在默认的可见性,如果没有显示任何一种符号,就表示没有定义该属性的可见性。 (2) 属性名:按照UML的约定,单字属性名小写。如果属性名包含多个单词,这些单词要合并,且除了第一个单词外其余单词的首字母要大写。 (3) 属性字符串。属性字符串用来指定关于属性的其他信息,例如某个属性应该是永久的。任何希望添加在属性定义字符串值但又没有合适地方可以加入的规则,都可以放在属性字符串里。 (4) 类属性。属性也可以作为一个类属属性来定义,这就意味着此属性被该类的所有对象共享。在类图中,类属性带有一条下划线。 3、 操作。类的操作是对类的对象所能做的事务的抽象,相当于一个服务的实现。 4、 职责:在操作部分下面的区域,可以用来说明类的职责。职责是类或其他元素的契约或义务。类的职责是是自由形式的文本,写一个短语,一个句子等。在UML中,把职责列在类图底部的分隔栏中。 5、 约束。说明类的职责是消除二义性的一种非形式化的方法,形式化的方法是使用约束。约束指定了该类所要满足的一个或多个规则。在UML中,约束是用一个花括号括起来的自由文本。 三、接口 接口包含操作但不包含属性,且它没有对外界可见的关联。 四、类之间的关系 类之间的关系最常见的有四种:依赖关系、泛化关系、管理关系、实现关系。 1、 依赖关系(Dependency) 依赖表示两个或多个模型元素之间语义上的关系。它表示了这样一种情形,对于一个元素(提供者)的某些改变可能会影响或提供消息给其他元素(客户),即客户 以某种形式依赖于其他类元。根据这个定义,关联、实现和泛化都是依赖关系,但是它们有更特别的语义。在UML中,依赖用一个从客户指向提供者的虚箭头表 示,用一个构造型的关键字来区分它的种类。 UML定义了4种基本依赖类型,分别是使用(Usage)依赖、抽象(Abstraction)依赖、授权(Permission)依赖和绑定(Binding)依赖。 (1)、使用依赖。使用依赖都是非常直接的,通常表示客户使用提供者提供的服务以实现它的行为。以下列出了5种使用依赖关系. (2)、抽象依赖。抽象依赖用来表示客户与提供者之间的关系,依赖于在不同抽象层次上的事物。 (3)、授权依赖。授权依赖表示一个事物访问另一个事物的能力。提供者通过规定客户的权限,可以控制和限制对其内容访问的方法。 (4)、绑定依赖。绑定依赖是较高级的依赖类型,用于绑定模板以创建新的模型元素。 2、泛化关系(Generalization) 泛化关系是一种存在于一般元素和特殊元素之间的分类关系,它只使用在类型上,而不是实例上。在类中,一般元素被称为超类或父类,而特殊元素被称为子类。在UML中,泛化关系用一条从子类指向父类的空心三角箭头表示 3、关联关系(Association) 关联关系是一种结构关系,它指明一个事物的对象与另一个事物的对象之间的联系。也就是说,关联描述了系统中对象或实例之间的离散连接。在UML中,关联关系用一条连接两个类的实线表示 关联关系有6种对应的修饰,它们分别是:名称、角色、多重性、聚合、组合和导航性。 (1)、名称(Name)。名称用来描述关联的性质,通常使用一个动词或动词短语来命名关联。名称以前缀或后缀一个指引阅读的方向指示符以消除名称含义上可能存在的歧义,方向指示符用一个实心的三角形箭头表示。 (2)、角色(Role)。角色是关联关系中一个类对另一个类所表现出来的职责。角色名称是名词或名词短语,以解释对象是如何参与关联的。 (3)、多重性(Multiplicity)。约束是UML三大扩展机制之一,多重性是其中使用最广泛的一种约束。关联的多重性是指有多少对象可以参与该关联,多重性可以用来表达一个取值范围、特定值、无限定的范围或一组离散值。 (4)、聚合(Aggregation)。聚合关系表示整体和部分关系的关联。聚合关系描述了“has a”的关系。在UML中聚合关系用带空心的实线来表示,其中头部指向整体。 (5)、 组合关系(Composition)。组合关系是聚合关系中的一种特殊情况,是更强形式的聚合,又被称为强聚合。在组合中,成员对象的生命周期取决于聚合 的生命周期,聚合不仅控制着成员对象的行为,而且控制着成员对象的创建和析构。在UML中,组合关系用带实心菱头的实线来表示,其中头部指向整体。 (6)、 导航性(Nevigation)。导航性描述的是一个对象通过链(关联的实例)进行导航访问另一个对象,即对一个关联端点设置导航属性意味着本端的对象可 以被另一端的对象访问。可以在关联关系上加箭头表示导航方向。只在一个方向上可以导航的关联称为单向关联(Unidirection Association),用一条带箭头的实线来表示。在两个方向上都可以导航的关联称为双向关联(Bidirection Association),用一条没有箭头的实线来表示。另外使用导航性可以降低类之间的耦合度,在也是好的面向对象分析与设计的目标之一。 4、实现关系(Realization) 实现是规格说明和其实现之间的关系,它将一种模型元素与另一种模型元素连接起来,比如类和接口。 泛化和实现关系都可以将一般描述与具体描述联系起来。泛化将同一语义层上的元素连接起来,并且通常在同一模型内。实现关系则将不同语义层内的元素连接起来,通常建立在不同的模型内。 实现关系通常在两种情况下被使用:在接口与实现该接口的类之间;在用例以及实现该用例的协作之间。 在UML中,实现关系的符号与泛化关系的符号类似,用一条带指向接口的空心三角箭头的虚线表示。下图所示的是实现关系的一个示例,描述的是Keyboard保证自己的部分行为可以实现Typewriter的行为 实现关系还有一种省略的表示方法,即接口表示为一个小圆圈,并和实现接口的类用一条线段连接,如图 类图建模技术一、对简单协作建模 类不是单独存在的,而是要与其他类协同工作。协作是动态交互在静态视图上的映射,协作的静态结构通过类图来描述。 对协作建模要遵循如下策略 1、识别要建模的机制。一个机制描述了正在建模的部分系统的一些功能和行为,这些功能和行为是由类、接口和一些其他元素的相互作用产生的。 2、对每种机制,识别参与协作的类、接口和其他协作,并识别这些事物之间的关系。 3、用协作的脚本检测事物,通过这种方法可以发现模型中被遗漏的部分和有明显语义错误的部分。 4、把元素和它们的内容聚合在一起。对于类,首先平衡好职责,随着时间的推移,将它们转换成具有的属性和操作。 二、对逻辑数据库模式建模 通用的逻辑数据库建模工具是“实体-关系(E-R)”图,传统的E-R图只针对数据,而UML的类图还允许对行为建模。在物理数据库中,类图一般要把逻辑操作转化成触发器或存储过程。 对模式建模要遵循如下策略: 1、在模型中识别的类,其状态必须超过其应用系统的生命周期。 2、创建包含这些类的类图,并把它们标记为永久(persistent)。对于特定的数据库细节,可以定义自己的标记值集合。 3、展开这些类的结构性细节,即详细描述属性的细节,并注重于关联和构造类的基数。 4、观察系统中的公共模式(如循环关联、一对一关联和n元关联),它们常常造成物理数据库设计的复杂化。 5、考虑这些类的行为,扩展对数据库存储和数据完整性来说重要的操作。一般情况下,与对象集的操作相关的业务规则应该被封装在永久类的上一层。 三、正向工程和逆向工程 1、正向工程(Forward Engineering) 正向工程是通过实现语言的映射把模型转换为代码的过程。由于UML中描述的模型在语义上比当前的任何面向对象语言要丰富,所以正向工程会导致一定信息的损失,这也是需要模型的原因。 对类图进行正向工程,要遵循如下的策略 (1)、识别映射到所选择的实现语言的规则 (2)、根据所选择的语言的语义,可能会限定一些对UML特性的使用 (3)、用标记值详细描述目标语言,若需要精确的控制,该操作可以在单个类的层次上进行,也可以在较高的层次(如协作或包)上进行 (4)、使用工具对模型进行正向工程 2、逆向工程(Reverse Engineering) 逆向工程是通过从特定实现语言的映射,把代码转换为模型的过程。逆向工程会导致大量的冗余信息同时逆向工程又是不完整的。 对类图进行逆向工程,要遵循如下的策略 (1)、识别从实现语言或所选的语言进行映射的规则 (2)、使用工具,指向要进行逆向工程的代码,用工具生成新的模型或修改以前进行正向工程时已有的模型。 (3)、使用工具,通过查询模型创建类图。 对象图一、概述 对象图(Object Diagram)描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图可以被看作是类图在某一时刻的实例。 在UML中,对象图使用的是与类图相同的符号和关系,因为对象就是类的实例。下图显示了对象图的模型。其中节点可以是对象也可以是类,连线表示对象之间的关系: 二、类图和对象图的区别
对象图建模技术一、对对象结构建模 对系统的设计视图建模时,可以使用一组类图完整地描述抽象的语义以及它们之间的关系。但是使用对象图不能完整地描述系统的对象结构。对于一个个体类,可能 存在多个实例,对于相互之间存在关系的一组类,对象间可有的配置可能是相当多的。所以,在使用对象图时,只能在一定意义上显示感兴趣的具体或原型对象集。 这就是对对象结构建模,即一个对象图显示了某一时刻相互联系的一组对象。 对对象结构建模,要遵循以下策略: (1)、识别将要使用的建模机制。该机制描述了一些正在建模的部分系统的功能和行为,它们由类、接口和其他元素的交互而产生。 (2)、对于各种机制,识别参与协作的类、接口和其他元素,同时也要识别这些事物之间的关系。 (3)、考虑贯穿这个机制的脚本。冻结某一时刻的脚本,并且汇报每个参与这个机制的对象。 (4)、按照需要显示出每个对象的状态和属性值,以便理解脚本。 (5)、显示出对象之间的链,以描述对象之间关联的实例。 二、正向工程和逆向工程 1、正向工程 对对象图工程进行正向工程在理论上是可行的,但是在实际上却是受限制的。 2、逆向工程 对对象图进行逆向工程是非常困难的。当对系统进行调试时,总要依靠开发人员或工具来进行。 |
类图和对象图教程-类(Class)、接口(Interface)、协作(collaboration)、依赖关系(Dependency)、泛化关系(Generalization)、关联关系(Association)以及实现关系(Realization)