java课件omt新04关系建模

第四章关系建模关联泛化依赖关系建模方法设计原则关系概述关系：描述元素之间的关系；而关系本身也是元素。主要有三种关系：关联association泛化generalization依赖dependence关联概述关联表示类间静态的结构关系。关联是一种关系，同时也是一种类元。关联的一个实例被称为一个链(link)，一个链是一个元组(tuple)。一个元组有两个以上的值，每个端(end)对应一个值，每个值都是关联端类型的一个实例。元组的多个端的组合是不重复的。关联确定了类型的实例之间的语义关系。一个关联至少有两个端，每个端连接到一个类型。一个关联的多个端可连接到同一个类型上。在一个端上，如果一个实例存在的话，要求被关联的另一端的零个或多个实例也必须存在。关联是一种非定向的关系，尽管关联可说明导向性。链与关联关联关系二元binary关联、n元(n-ary)关联语法：实线连接加说明命名：名称及方向，区分多个关联的性质(关联的角色)。角色role：关联中的一方对于另一方的职责的识别和命名多重性multiplicity：对象之间定量的结构关系。关联的多重性传统的多重性有3种形式：“1对1”、“1对多”、“多对多”。其中，“多对多”包含了“1对多”作为其特殊情形，而“1对多”包含了“1对1”作为特例。关联端的多重性可缺省，缺省情况下为“*”，即0个到多个，而且是不重复的。用术语可表示为一个Set集合。如何确定一个关联的多重性？对于二元关联<A,B>来说，先确定一端类元A的任意一个实例，然后断定所关联的另一端B可能有多少实例，表示为B端的多重性。尽可能确切描述，避免“多”的情形。多重性聚集（1）关联种类有3种：非聚集：无菱形共享聚集：空心菱形，各部分对象的生命期独立于整体复合聚集：实心菱形，各部分对象的生命期受限于整体聚集aggregation：一种特殊的关联，表示部分和整体关系，即has-a或has-many关系复合composite：整体对象负责其各部分对象的生存和存储区分两种聚集形式聚集（2）复合composite：一种“强”聚集aggregation形式，区分复合对象和部分对象；一个部分对象在特定时刻只能被包含在一个复合对象中；且该复合对象“独占”各部分。当整体对象撤销时，其各部分对象也撤销。有三种不同方式来表示复合关系。关联与性质关联导向性从一端能方便到达另一端可导向不可导向非确定自关联关联类（1）一个关联类(AssociationClass)是表示关联的一个类，它不仅连接一组类元，而且可定义关联自身的一组性质和操作。表示一个关联类：将该类与关联用虚线连接，而且使类名与关联的名字相同。关联类（2）把一个“多对多”关联类转换为一个普通类。两者语义大致相同，但并不完全相同。关联类的本质仍是二元组，有这样一个限制作用，同一个人加入同一个团体只能有1次，所以加入时间只能有1个值。而后者则没有这样的限制，同一个人可多次加入同一个团体，这导致可能有多个不同的加入时间。限定关联一个限定符包含了一个或多个属性，限定符的一个实例包含每个属性的一个值，称为限定符实例。给定一个对象(如一个Consortium对象)和一个限定符实例(一个SeqNo)，在关联的另一端的对象数量就受到限制(如Person)，其多重性通常为“0..1”。多元关联3元关联和一个关联类三元关联的一个实例是一个三元组。多重性如何确定？限定两方都唯一时，检查第三方关联端的修饰符{subsets<性质名>}说明该端是指定性质的一个子集。{redefines<端名>}说明该端是指定端的重定义/<端名>说明该端是一个派生的关联端，往往与{union}相关。{union}说明该端是其多个子集合构成的一个派生并集。{ordered}该端的多个元素是一个有序集合。{bag}该端表示一个集聚，其中同一个元素可出现多次。{sequence}或{seq}该端表示一个序列，即一个有序的bag。缺省情况下一个关联端的集聚类型是一个集合{set}。泛化概述较一般的元素(超类)和较特殊的元素(子类)之间的关系。语法：实线空心箭头从子类到超类语义：子类is-a-kind-of超类。子类对象可替代超类对象；子类继承超类特征且可增加新特征；子类操作的基调与超类相同时，子类可改写(override)超类的实现。根类/基类----叶子类单继承---多继承泛化的反义词是特化specialization泛化的表示特征的继承与扩展泛化的用途概念表述：要表述一个概念，往往要用“是一种什么”来说明。

特征重用：子类的对象继承其超类的性质和操作，但子类并不重复描述这些特征。子类中仅描述扩展的新特征，而超类中的特征能被其所有子类共享和重用。

抽象设计：基于泛化关系的多态性是抽象设计的基础。抽象设计与具体设计对立，在高层的抽象的级别上建立行为特征和行为规范，为低层的具体的设计提供一个统一的框架。主要是两方面的多态性：引用类型的多态性和操作调用的多态性。关系环在两个类之间是否可同时存在泛化和关联两种关系？关系环的例子泛化集一个泛化集包含一组泛化关系，针对同一个一般性类元，提供了一种分类方式，得到了一组子类型划分泛化集的属性一个泛化集有两个重要属性：isDisjoint和isCoveringoverlapping&disjoint：相交&不相交，缺省相交plete&complete；不完全&完全，缺省不完全泛化集的例子单继承和多继承如果一个子类只有一个直接的超类，这就是一个单继承。反之，如果一个子类具有多个直接的超类，就是一个多继承，也称为多重继承。C++语言允许类之间有多重继承，即一个子类可有多个直接的超类。Java语言不允许类的多重继承，但支持接口的多重继承。UML支持类的多重继承。如何将多继承转变为单继承？依赖概述两个命名元素之间的一种定向关系；一个是依赖元素作为client，另一个是独立元素作为supplier；依赖元素取决于独立元素的规范或实现；若独立元素改变，则依赖元素也需随之改变使用一种常见的依赖关系，表示client元素为其完整的实现或操作而需要supplier元素提供部分实现或操作。最常见的形式是类A的某个操作的形参类型是类B，那么A依赖B。使用关系通常采用构造型«use»来表示使用的标准构造型«call»表示一个操作调用另一个操作。在表示时，这种关系往往扩大到包含操作的类：一个“源”操作调用一个“目标”操作，表示为一个“源”类中的一个操作调用了“目标”类中的某个操作。«create»说明client类元创建supplier类元的实例。«instantiate»说明在client中的某个操作创建supplier类元的实例。«responsibility»说明一个元素对其他元素提供某种约定或义务。«send»表示一个源操作发送一个信号，源是一个操作，目标是一个信号。实现概述一种特殊的抽象关系，supplier端是一组建模元素作为规范，而client端表示规范的一种实现。实现主要用于对逐步细化、优化、转换、模板、模型合成、框架复合等进行建模。注意，实现的含义并没有严格定义，而只是隐含着某建模语境更细化或更详细的描述。如何表示实现关系？一般不用构造型，而采用虚线和三角箭头，从实现元素指向被实现的规范元素。类型类和实现类UML模型中，被实现的规范不一定都是接口，一个类也可描述规范。«type»类被称为“类型类”，指定某一领域的一组对象，也包括作用于这些对象上的一组操作，也可定义属性和关联，但未定义这些对象的物理实现。«implementationClass»类被称为“实现类”，以某种编程语言实现，如C++、Java。对于一个类元(一般是类型类)，如果一个实现类提供了该类元定义的所有操作，而且具有类元操作所规范的相同行为，该类就实现了这个类元。一个实现类可实现多个不同的类型。类型类与实现类对依赖的讨论假设类A是类B的泛化，两者之间是否可能还有依赖关系？假设类A与类B之间存在关联关系，两者之间是否可能还有依赖关系？关系建模方法确定泛化关系最重要，因为它是建立概念的基础。区分泛化和特化的不同目的。泛化的目的是提取抽象，自下而上建立一般性的概念；特化的目的是具体化，自上而下建立特殊性的概念。对泛化建模在一组类中，分析两个和两个以上的类的共同职责、性质和操作；抽象为一个更一般的类，并确定泛化关系；确定一般类的性质和操作。对于特化关系，一般按照以下步骤进行分析和建模：在已有的一组类中寻找最具体的一个类作为其一般类；建立该类的一个子类；确定子类特有的性质和操作；确定需要重定义的性质和操作。对关联建模数据驱动：如果两个类的对象之间有导航，则建立关联。行为驱动：如果一个类需要与其它类交互，而且这种关系在交互之前就存在，则建立关联。说明关联的名字、关联端的角色名字、以及多重性。若关联的一端有明显的整体结构，而另一端是其组成部分，则建立聚集关系。进一步确定关联端的导向性、关联类、限定符，以及其他修饰符。对依赖建模类A中的某操作有一个形参类型为类B，那么A依赖B。注意：依赖和泛化都是有方向的，而关联不同。关系建模提示仅当被建模的关系不是关联或泛化关系时，才考虑依赖关系。仅当表示“is-a-kind-of”或者“isa”关系时，才使用泛化关系。如果两个类之间已存在泛化或关联关系，隐含着存在依赖关系，而且不需要表示。避免可能的多重继承，一般可用聚集来替代避免泛化的循环。因为泛化关系是有向无环图。描述对象间的结构关系应以关联为主。不良设计的7种现象僵硬：很难加入新功能，新加入的模块会波及其他，而且范围越来越大，最后不得不放弃。脆弱：与僵硬共存，修改某个地方却导致不相关的其他地方发生故障，而且难以预料。低复用：发现某个模块希望能被复用，进一步却发现要依赖一大堆没用的或不明确的东西，以至于很难把可复用部分隔离开来，最后还得放弃复用。高粘度：对设计的更改违背了原始设计的意图和框架，仅考虑眼前利益，只做权宜之计，缺乏长远打算，最终导致设计方案难以经受长久考验而失败。无端复杂性：即过度设计。设计人员试图预测将来可能的变化，从而设计了过多的当前无用的元素，这些偶然性的元素却导致不必要的复杂性，使软件难以维护。无端复制：团队中多人出于自己的目的复制了相同的代码，而后各自修改一部分，使大量代码重复但略有差别，当在一个地方发现bug而其它地方也存在相同bug时，却难以集中修复。晦涩：即难以理解，不能明确表达其意图。开始的设计往往清晰易懂，但随着工程进行，不断添加新功能，越来越难以理解，使软件难以维护。面向对象设计的5个原则SOLIDSRP：TheSingleResponsibilityPrinciple，单一职责原则。一个类应仅有一个改变的理由。OCP：TheOpen/ClosedPrinciple，开闭原则。不应修改已有的类，而应扩展一个类。LSP：TheLiskovSubstitutionPrinciple，里氏替换原则。子类对象能随时随地替换其超类。ISP:TheInterfaceSegregationPrinciple，接口分离原则。一个客户程序只需关注自己所需要的接口。DIP:TheDependencyInversionPrinciple，依赖倒置原则。依赖抽象而不依赖细节。单一职责原则SRP“一个设计元素只做一件事”。当你要改变一个类时，只能有一个理由开/闭原则OCP“模块应对扩展开放，对更改关闭”“对扩展开放”。这意味着模块的行为可扩展。当需求改变时，我们可对模块进行扩展，使其具有满足那些改变的新行为，使软件具有适应性和灵活性。“对更改关闭”。对模块行为进行扩展时，不应改动已有模块，使软件具有一定的稳定性和延续性。总之，当我们需要扩展新功能时，应编写新的代码，而不应更改已有的代码。开/闭原则OCP（2）对于OCP原则，抽象是关键。对可变性进行封装的原则(PrincipleofEncapsulationofVariation，简称EVP)。其核心思想是“找到系统中的可变因素，将其封装起来”。EVP有两个要点：一种可变性不应散落在代码的很多角落，而应封装到一个对象中。一种可变性与另一种可变性不能混杂在一起。里氏替换原则LSPLSP专门针对泛化关系设计的合理性。“派生类通过其基类的接口必须可用，而用户无需知其差别”。子类型的对象必须能随时随地替换其基类型接口分离原则ISP为客户程序提供尽可能“小”的单独的接口。依赖倒置原则DIP细节应依赖抽象，而抽象不应依赖细节小结（1）关系建模是结构建模中的难点和重点。UML模型中的基本关系包括关联、泛化和依赖。一个关联是一组链(link)的抽象，每一个链都是一个二元组或多元组，其中每一个值都是特定类型的一个实例。关联的命名表示了作为类元的抽象，关联端的名字表示了关联中各端所扮演的不同角色。关联的多重性表示了对关联端的定量约束。聚集是表示整体和部分概念