面向对象设计类图设计.ppt

《面向对象设计类图设计.ppt》由会员分享，可在线阅读，更多相关《面向对象设计类图设计.ppt（57页珍藏版）》请在三一文库上搜索。

1、2019年3月13日,第1页,系统规划部 刘连庆,面向对象设计_类图设计,2019年3月13日,第2页,主要内容,类相关的基本概念 使用UML的类图设计 类图设计的一些问题分析 继承关系的分析 对象持久化与E-R模型的映射 类设计相关的一些设计模式 类图设计应用信息模型建模过程及方法,2019年3月13日,第3页,类相关的基本概念,迎接挑战，共创成功！,2019年3月13日,第4页,对象和类,对象（Object）：对象是指某个事物，大多对应于真实世界中的某个客观实体；但有些对象在真实世界中没有直接的对应物，是人们对某个事物的一种抽象描述。对象的基本特征可以归纳为对象的属性和行为两类。 类（Cl

2、ass）：类是指对一组具有相同特征的对象的抽象描述；任何对象都是某个类的实例。,2019年3月13日,第5页,例:客户类的表示,客户,姓名,单位,电话,Email,客户,姓名,单位,电话,Email,客户,付款(金额),客户,付款(金额),2019年3月13日,第6页,类图和对象图,类图描述系统中的类及其相互之间的各种关系，反映了系统中包含的各种对象的类型以及对象间的各种静态关系，主要是：关联和子类型。类图也可描述类的属性和行为以及对模型中各种成分的约束。 对象图是类图的实例，描述系统中各种对象(类的实例)以及对象之间的各种静态关系。,2019年3月13日,第7页,使用UML的类图设计,迎接挑

3、战，共创成功！,2019年3月13日,第8页,使用UML的类图设计,类设计的相关UML元素 类 属性 操作 接口 关联 聚合 继承（泛化） 包的使用,2019年3月13日,第9页,类,实体名称,实体方法,可见性,实体属性,类是对同一种类型的对象的抽象表示,2019年3月13日,第10页,属性,UML规定其语法为： 可见性 名称:类型 = 缺省值 约束特性 描述属性的元素 可见性：表示该属性对类外的元素是否可见。常用的有公有、受保护和私有三种。 名称：属性的名称， 是一个字符串。 类型：定义属性的种类(基本数据类型或用户自定义的类型)。 缺省值：属性的初始值。 约束特性：描述对属性的约束。,20

4、19年3月13日,第11页,操作,UML规定其语法为 可见性 名称(参数表):返回类型表达式约束特性 描述操作的元素 可见性：“+”表示公有操作，“#”表示受保护的操作，“-”表示私有操作。 名称：操作的名称，是一个字符串。 参数表：其语法与属性的参数相同，参数个数是任意的。 返回类型表达式(可选项)：依赖于语言的描述。 约束特性：用以描述对此操作的约束。,2019年3月13日,第12页,可见性,对“Public”、Private”和“Protected”等三个可见性标识符的含义，各种语言都有它自己的规定。UML的定义是： +(Public)：公有成员在程序的任何位置都是可见的，系统中的任何对

5、象都可以使用它。 -(Private)：私有成员仅可以由定义它的类使用。 #(Protected)：受保护的成员仅可以由定义它的类和该类的子类中的对象使用。,2019年3月13日,第13页,接口,接口和类不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。,2019年3月13日,第14页,关联,关联用于描述类之间的关系 每个关联有两个角色。例如，对于客户和订单之间的关联是：客户和订单。,关联名称,关联基数(Cardinality),关联基数(Cardinality),关联实体，描述关联的属性、方法,2019年3月13日,第15页,关联的分类,双向关联 单向关联 关联类 聚

6、合 基本聚合 组合聚合 自关联（反射关联）,2019年3月13日,第16页,双向关联,关联是两个类间的联接。在Rose中关联总是被假定是双向的；这意味着，两个类彼此知道它们间的联系，除非你限定一些其它类型的关联。,2019年3月13日,第17页,单向关联,在一个单向关联中，两个类是相关的，但是只有一个类知道这种联系的存在。下图显示单向关联的透支财务报告的一个实例。,2019年3月13日,第18页,关联类,在关联建模中，在一些情况下，需要包括其它类，因为它包含了关于关联的有价值的信息。对于这种情况，需要使用 关联类 来绑定你的基本关联。关联类和一般类一样表示。不同的是，主类和关联类之间用一条相交

7、的点线连接。,2019年3月13日,第19页,自关联,类自身的关联，当一个类关联到它本身时，这并不意味着类的实例与它本身相关，而是类的一个实例与类的另一个实例相关。,2019年3月13日,第20页,聚合,聚合是一种特别类型的关联，用于描述“总体到局部”的关系。聚合分为两种类型：基本聚合、组合聚合 基本聚合 在基本聚合关系中，部分类 的生命周期独立于整体类 的生命周期。 组合聚合 在组合聚合关系中，部分类的生命周期依赖于整体类的生命周期。,2019年3月13日,第21页,继承,在面向对象的设计中一个非常重要的概念，继承，指的是一个类（子类）继承另外的一个类（超类）的属性和方法，并增加它自己的属性

8、和方法，或者覆盖父类的属性和方法,类名BankAccount和withdrawal操作使用斜体。这表示，BankAccount 类是一个抽象类，而withdrawal方法是抽象的操作。换句话说，BankAccount 类使用withdrawal规定抽象操作，并且CheckingAccount 和 SavingsAccount 两个子类都分别地执行它们各自版本的操作。然而，超类（父类）不一定要是抽象类。标准类作为超类是正常的。,2019年3月13日,第22页,泛化（Generalization),泛化(Generalization): 抽象化 特化(Specialization): 实例化 继承

9、(Inheritance): 泛化关系的一种实现机制,2019年3月13日,第23页,继承与泛化,继承是实现泛化的一种机制。在这种机制中，超类的任何一个子类都须具有其超类的所有行为：不仅要求其操作界面在文法上一致，而且要求其行为在语义上一致。 当子类中的一个操作重载其超类中相应的操作时，必须确保它提供与超类中的操作相同的服务(内容可以更多或更具体)。 如没有证明子类的行为是否与父类相同，就试图用继承来实现新类中的行为，当两者不一致时，会导致难以预测的错误。,2019年3月13日,第24页,包的引入,大系统将问题复杂化。“攻克”复杂问题的经典方法是“分而治之”。结构化方法采用功能分解来解决这个问

10、题，但传统的结构化方法将过程与数据分离。 面向对象技术解决这个问题的基本思路是将许多类集合成一个高内聚、低耦合的类的集合。UML把这种分组机制称为包。不仅类可以运用包的机制，任何模型元素都可运用包的机制。,2019年3月13日,第25页,类关系中的依赖性,UML指导将类组成包的原则是依赖性：设有两个元素X、Y，如果修改(语法的或语义的)元素X的定义引起对元素Y的定义的修改，则称元素Y依赖于元素X。 类之间的依赖关系： C inherits from R A variable in C is of class R A method of C receives an argument of cla

11、ss R A method of C sends a message that returns an argument of class R A method of C has a local variable of class R C is a “friend” of R,2019年3月13日,第26页,包图关系中的依赖性,包图显示类的包以及这些包之间的依赖关系。它们都是类图中的元素，因此包图是另一种类图。 如果两个包中的任意两个类之间存在依赖关系，则这两个包之间存在依赖关系。 但包的依赖是不传递的。如图示，订单获取应用包屏蔽了订单包的变化对订单获取界面包的影响。,2019年3月13日,第2

12、7页,类图设计的几点建议,在项目初始阶段，不要使用所有的符号，应从简单的概念开始。 不同的开发阶段应用不同的观点画类图：分析阶段用概念层类图；设计阶段用设计层类图。 不要为每个事物都画一个模型，应把精力放在关键的领域，画几张较为关键的图，经常使用，不断更新。 使用类图的最大危险是过早地陷入实现的细节，应将重点放在概念层。,2019年3月13日,第28页,类图设计的一些问题分析,迎接挑战，共创成功！,2019年3月13日,第29页,内容提要,使用继承的一些问题分析 对象的持久化，向E-R模型的映射,2019年3月13日,第30页,使用继承的一些问题分析,许多人将继承视为面向对象设计中最好的或最有

13、力的方法 因此在面向对象设计中，会尽量多的使用继承来解决问题 这会导致： 继承关系的不恰当使用 子类不恰当的获取父类的行为 类的层次结构不灵活(Awkward or rigid) 难于维护 下面列举一些没有正确使用继承关系的例子,2019年3月13日,第31页,继承的问题分析1,不正确的继承关系,将继承改为关联,2019年3月13日,第32页,继承的问题分析2,2019年3月13日,第33页,一个相似的例子,2019年3月13日,第34页,问题 在我们的应用中，房间是一个立方体 我们需要记录每个房间的长、宽、高 在我们的类库中已经有CUBOID类 设计为：,CUBOID,继承的问题分析3,20

14、19年3月13日,第35页,一种可行的设计 一种更为通用的设计,继承的问题分析3续,2019年3月13日,第36页,继承的问题分析4,2019年3月13日,第37页,对象模型向ER模型的映射,对于实体类，一般会选择关系数据库做数据的存储，因此会涉及对象模型如何向E-R模型转换的问题： 简单关联关系的映射 继承关系的映射 聚合关系的映射,2019年3月13日,第38页,简单关联关系的映射,2019年3月13日,第39页,继承关系的映射,2019年3月13日,第40页,三种方案的进一步分析,三种方案优缺点的进一步分析： 如果行数有限，那么优先考虑将应用程序与将来可能的改变隔离开来，提供一个更为健壮

15、的数据库设计。因此方案1可能是最灵活的，但这个方案的性能是最差的（它涉及到许多连接）。 如果超类中属性数目与子类的数目相比较小，那么方案3可能是最谨慎的选择。它可以提供比方案1更好的性能，以后扩展模型时添加更多的类也较为容易。 如果子类中的数据量较少，那么方案2是最好的。该方案提供了最佳的性能，但其灵活性最差。,2019年3月13日,第41页,聚合关系的映射,在类图中，聚合关系表示的是两个类之间的整体与部分之间的关系。从本质上讲，聚合关系是类之间的关联关系的一种，在向E-R模型转换时，与简单关联关系的映射规则相同。 按照一对多的关系映射为E-R模型,2019年3月13日,第42页,类设计相关的

16、设计模式,迎接挑战，共创成功！,2019年3月13日,第43页,类设计相关的设计模式,模式是对特定环境下经常出现的有代表性的问题的通用核心解决方案，并且该方案可以被多次使用； 设计模式可以帮助复用和沟通，可以提高信息模型的质量，使模型的结构更为合理，具有良好的适应能力，能够可以提供可扩展的结构； 在信息模型中使用的设计模式主要有： 实体-实体规格分离模式 角色对象模式 模板模式 合成模式 实体属性规格/实体属性模式 实体/实体状态分离模式,2019年3月13日,第44页,实体实体规格分离模式,将实体的不变的、相对固定的特性和行为与其可变的特性、行为分开定义。通过规格的定义，将通用的规则、属性分

17、离出来单独定义，形成实体的模板。,记录某一类实体的通用属性,记录某一实体的属性,2019年3月13日,第45页,模板模式,将具有相同分类或特点的类中通用的属性、方法抽象出来，形成抽象类作为父类，子类继承和扩展父类的属性、方法。 在面向对象的建模中，抽象层次是非常重要的 关于继承 模板模式是基于继承的复用技术 采用继承的复用技术要比采用委托的复用技术耦合程度要高，使用继承关系要谨慎,2019年3月13日,第46页,模板模式的应用,将子类与其它类的关联关系中具有通用性的关联抽象到父类与其它类的关联，使实体之间的关联关系更具有通用型和扩展性,2019年3月13日,第47页,角色对象模式,问题的引出：

18、 一些业务实体，需要扮演多个角色，如某个人可以是企业的客户，同时又是企业的员工；某个公司可以是企业的客户，同时也是企业的代销商，也可以是企业的提供商，如何对这些关系进行建模，在信息模型中，采用实体、实体角色（角色对象）分离的模式来解决： 实体是相对固定的，实体扮演的角色是可以独立与实体灵活的变化和扩展,2019年3月13日,第48页,角色对象模式的应用,将与系统相关的个人、组织抽象成参与者，将参与者所扮演的角色用参与者角色表示，具体类型的角色使用子类来表示。,2019年3月13日,第49页,合成模式,合成模式又称为部分整体模式。合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模

19、式可以使客户端将原子元素与复合元素同等看待。合成模式有安全式和透明式两种。透明式的合成模式将原子元素与复合元素完全同等看待，定义同样的接口，缺点是不够安全；安全式的合成模式是将原子元素与复合元素区别对待，可以有不同的接口，缺点是不够透明。,2019年3月13日,第50页,合成模式的应用,变更服务规格是服务规格的一种，如新装、改名、过户等。可以是原子的，也可以是组合的，但是通过服务规格将他们同等处理。,2019年3月13日,第51页,实体属性规格/实体属性模式,问题的引出： 有些业务实体，如通信服务，不同的通信服务可以有不同的特性，如ADSL有上行速率、下行速率；专线有通信规程、接入方式等，而普

20、通电话则没有。在支持新的通信服务时，又可能增加新的特性，如何对变化的特性建模。在建模时引入属性实体：,2019年3月13日,第52页,实体/实体状态分离模式,对于有状态变化的实体，如果需要记录实体状态变化的过程，需要将状态单独分离出来，形成状态实体。 从资源管理的角度看，需要采用这种模式，以记录资源状态变化的历史，即所说的资源与资源状态分离。 像申请单、工单都有状态的变化，在设计时是采用了_handle表的方式来记录变化，也是这种模式的一种实现方式。,2019年3月13日,第53页,信息模型建模过程与方法,迎接挑战，共创成功！,2019年3月13日,第54页,生命周期和方法论,从业务的视角描述解决方案的概念设计,从系统的视角描述解决方案的概念设计,描述解决方案的实际实现,描述解决方案的实际部署,业务视图,技术中立,逻辑视图,技术相关,物理视图,部署视图,系统视图,实现视图,描述业务运营,运营商视图,描述业务的架构和实现,服务开发者视图,2019年3月13日,第55页,逐层分解的设计方法,2019年3月13日,第56页,根实体的引入,建立根实体是面向对象建模的方法 根实体是跨域的，引入根实体可以使这些通用的属性和行为能够跨域共享和复用 通过根实体的引入，确保多个域的概念能够保持一致 保持多个阶段模型的一致,2019年3月13日,第57页,讨论与交流,