UML及面向对象设计思想.docx
《UML及面向对象设计思想.docx》由会员分享，可在线阅读，更多相关《UML及面向对象设计思想.docx（16页珍藏版）》请在冰豆网上搜索。
UML及面向对象设计思想
类图
¢类是面向对象技术的基础，是面向对象程序设计的基本单元。
类图描述软件系统的静态结构。
类图不仅定义了系统中的类，表示了类与类之间的关系（关联、依赖、继承），而且也描述了类的内部结构（类的属性和操作）。
¢类图描述的是系统的一种稳定的静态关系，在系统的整个生命期内都是有效的。
¢类可以进一步划分为实体类、边界类和控制类。
⏹实体类保存系统中的信息。
一个实体类的对象对应关系数据库中的一条记录。
⏹边界类是系统与用户的接口。
用户通过边界类与系统进行交互。
⏹控制类协调和控制其他类的对象以实现用例规定的行为，它封装了实现用例行为所需要的事件流。
¢在系统分析阶段，主要考虑的是实体类。
在设计和实现阶段，除了对实体类进一步细化之外，还要着重考虑边界类和控制类。
UML中类的基本表示方法：
类的封装性及其表示
¢封装性表现为类成员的可见性。
可见性分为公开的（public）、受保护的（protected）和私有的（private）三种。
¢在UML中分别用“+”，“#”和“-”表示。
“+”表示完全公开；“#”表示对同一个包中的类公开，对不同包中的类隐藏；“-”表示对外完全隐藏，仅仅对定义该成员的类的内部可见。
可见性也被分为：
公开的，受保护的，默认的，私有的四类。
其中“受保护的”对同一个包的其它类及不在同一个包的子类可见；“默认的”对同一个包的其它类可见。
类之间的关系表示
类之间的关系可以分为继承和关联，关联可以进一步分为组合、聚集和依赖。
类之间关联关系的表示
关联用于泛指两个类之间概念上的联系。
例如公司类和雇员类之间就存在联系，雇员为公司工作，公司雇佣雇员。
在关联关系的两端，可以标注关联约束，还可以标注关联在数量上的对应关系（关联的多重性）。
上图说明Employee是因为工作而与Company关联，任何一个雇员只为一个公司工作；Company因为雇佣而与Employee关联，一个公司可以雇佣一个以上（1..*）的雇员。
关联关系的细分
关联关系可以进一步划分为组合、聚集和依赖。
¢组合关系是一种紧密而稳定的关联关系。
如公司与部门是一种组合关联关系，因为如果没有公司，部门也将不存在。
有时组合关系也用于描述一个类的对象包含另一个类的确定个数的对象作为成员，例如：
一辆汽车包含一台发动机、四个轮胎，则汽车类与发动机类和轮胎类的关系是组合关联关系。
¢聚集（聚合）关系是一种较为松散的关系。
例如：
雇员与公司和部门之间的关系不是一种稳定的关系，因为即使公司或者部门不在了，雇员仍然存在，而且公司中雇员的人数不是固定的，雇员可以在部门之间或者公司之间流动。
所以雇员与公司和部门之间的关系是聚合关系。
在面向对象的程序设计中，聚合关系表现为一个类中声明另一个类的集合变量作为类成员。
组合与聚合关系的表示
¢依赖关系是一种更为松散的关系。
例如汽车和加油站的关系就是依赖关系。
汽车类依赖加油站类，只有汽车加油时才会与加油站发生关联，而且在哪一个加油站加油也是不固定的。
依赖关系中，被依赖的类的对象是依赖类的操作所要使用的一种工具。
在面向对象的程序设计中，依赖关系表现为依赖类的某个方法或者函数的参数类型是被依赖类的类型。
对象图
¢对象是类的实例，对象图描述在某一瞬间系统中存在的对象及对象间的关系。
¢UML中对象的表示
¢对象图示例
设计过程中的权衡
设计过程中，针对设计目标约束冲突给出的非功能性需求判断准则。
正确性：
解的完全性和正确性；安全性；容错性处理能力；保密性和鲁棒性。
资源：
执行效率：
时间复杂度、消息数、带宽要求等；空间消耗：
包括存储单元、对象、线程、过程、通信通道。
处理器等的使用情况；增加的资源，一些随选信息；动态策略，包括公正性、平衡性、稳定性等。
结构：
模块性：
封装、耦合、独立性；可延展性：
包括子类、可协调性、发展性、可维护性等；可重用性、开放性、可组合性。
便携性、可插入性；前后依赖性；互用性；等等。
工程：
可理解性、简单、高雅；执行中的容错性；与其他软件的共存性；系统可维护性；开发过程的影响；开发队伍结构及动态特性的影响；用户参与的影响；生产力、时间安排、成本的影响；等等。
用法：
使用规范；人为因素，如可学习性、恢复能力等；对不断变化的环境的适应性；艺术性；医学和环境的影响；社会、经济、政治的影响；等等。
设计模式核心思想
¢核心思想原则：
重点解决软件系统可维护性和复用性问题。
Ø普遍的问题
Ø基本的问题
Ø重现的问题
可维护性
可维护性好的系统应有的性质：
¢可扩展性：
容易加入新的性能
¢灵活性：
代码修改尽量不波及其他模块
¢可插入性：
容易抽出和加入类
传统的复用：
代码的剪贴复用；算法的复用；数据结构的复用
可维护性和复用的矛盾
传统的复用的风险：
¢影响可扩展性——过于僵硬
修改多个软件成分中的复用源代码时，需要独立地修改检测每一拷贝。
很难在一个软件系统里加入一个新功能。
¢影响灵活性——过于脆弱
对一个地方的修改会导致另一个地方发生故障，难以跟踪代码的变异和使用。
模块A和B同时使用模块C的功能。
那么当A需要C增加一个新的行为的时候，B有可能不需要、甚至不允许C增加这个新行为。
¢影响可插入性——粘度过高
代码、函数、模块对系统的依赖，改动意味着破坏原始意图和框架。
面向对象的可维护性复用
¢面向对象设计的重要语言特性
Ø数据抽象
Ø继承
Ø封装
Ø多态性
实现了概念和定义的复用，促进系统的可维护性。
基本概念——接口、类
接口（interface）：
对象的操作（对象可以处理的所有请求）的特征（操作的名称、参数和返回值）的集合。
类：
声明对象的类型（Type）
包括：
Ø变量及其类型的声明
Ø方法及其参量的类型声明
Ø方法的返还类型声明
Ø方法的实现等
接口和类的区别：
¢接口——只描述方法的特征，而不给出方法的实现，接口把方法的特征和实现分割开来。
¢类——不仅给出方法的特征，面且给出方法的实现。
接口常常代表一个角色（role），它包装与该角色相关的操作和属性，而实现这个接口的类使是扮演这个角色的演员。
一个角色可以由不同的演员来演．而不同的演员之间除了扮演一个共同的角色之外，并不要求有任何其他的共同之处。
类、类型和对象之间区别和联系:
¢类（class）——定义了一类对象的共性实现，即对象的内部数据与其操作的实现。
¢类型（type）——只涉及接口（即对象能作出反应的请求的集合）。
¢类定义了一类对象可执行的操作，也定义了对象的类型。
¢一个对象是一个类的实例，这个对象支持该类定义的接口。
同一种类型的对象共享接口部分
同一类型接口的对象可以有不同实现，即不同类的对象可以有相同的类型。
一个角色可以由不同的演员来演。
一个对象可以有多种类型。
一个类可以同时实现几个接口。
一个演员可以演不同的角色。
子类型包含（继承）了超类型的接口。
接口是实现构件可插入性的关键。
基本概念——抽象类和具体类
抽象类
——为子类定义通用接口。
接口的实现由子类定义的操作完成。
——可以有实例变量，以及一个或多个构造子（函数、方法）。
——构造子不能被调用来创建实例，抽象类不可以实例化。
——构造子可以被子类调用，所有子类都可以有共有的实现
¢抽象类通常代表一个抽象概念
¢提供一个继承的出发点。
¢由于抽象类不可以实例化，因此一个抽象类一定是用来继承的。
抽象类和接口的区别
¢抽象类：
允许实现所有派生类公共的状态和行为。
是一种相关实体聚集的方式。
关注如何设计实现并封装这些具体实体（规定派生类的接口并提供公共的实现），而又可以避免与某些特定于实现的细节相耦合（抽象类的抽象部分）。
¢接口：
关注派生类或实现类的对象的使用。
派生类或实现类的对象为了完成其功能应该有什么样的接口。
没有实例变量和构造子（函数）。
抽象类的作用：
用较少的冗余实现一组具有公共状态或行为的对象
¢设计一个接口
¢找出已定义对象的公共状态或行为
¢用一个抽象类实现该接口
¢从这个抽象类派生具有公共状态或行为的对象
优点：
使实现类更简单，更容易维护。
具体类
非抽象的类称为具体类，实现由自身完成。
¢具体类可以实例化，给出一个有逻辑实现的对象模版。
¢具体类不是用来继承的。
（可以继承）
假设蛋代表抽象，而鸡代表具体。
蛋决定鸡的性状，鸡是蛋的“实现”，蛋的类型决定了鸡的类型。
从这个角度来讲，先有蛋，后有鸡。
（鸡继承蛋）
基本概念——接口继承
类继承和接口继承:
继承：
一个类是另一个类的子类
类继承（实现继承）：
——根据某个原有对象的实现来定义另一个新的对象的实现。
——从已有类继承必要的需求。
——共享编码和表示方法。
接口继承：
——是一个类实现了另一个类的一个接口
——可用一个对象替换另一个对象。
——共享类型。
——只继承抽象类。
[问题]：
加入一个新的类,与现有具体类行为有不同的实现——动态的具体类可插入性问题
1.使用超类继承：
¢在类结构中增加一个超类,声明出子类要提供的行为
¢为这个抽象超类提供多个具体子类，以不同的方法实现了超类所声明的行为。
¢客户端动态地决定使用哪一个具体子类。
¢单继承的语言，一个类只能有一个超类。
¢当具体类已经有一个超类，则不可能加上新的超类。
¢加新的超类到已有的超类上面，形成超超类。
¢或者继续向上移动，直到类等级结构的最顶端。
2.使用接口概念
Ø在一个类等级结构中的任何类都是实现一个接口
Ø这个接口会影响到此类的所有子类，但是不会影响到此类的任何超类。
Ø此类将实现这个接口所规定的方法，而其子类则可以从此类自动继承到这些方法，
Ø子类可以选择置换其中的某一些方法或所有方法。
这时候，子类就具有了可插入性。
关联的可插入性
关联：
一个对象知道其他对象。
针对接口的关联：
¢不是针对具体类
¢任何实现这个接口的类都可以满足关联要求。
¢可以动态地将关联从一个具体类转换到另一个具体类
调用的可插入性-对象调用其他对象的方法。
针对接口的调用：
¢不是针对具体类,而是一个接口。
¢任何实现这个接口的类都可以被当前对象调用。
¢可以动态地决定当前对象调用哪一个具体类的实例
接口提供了方法调用上的可插入性。
软件系统的规模越大，生命周期越长，接口的重要性就越大。
接口使得软件系统在灵活性、可扩展性和可插入性上得到保证。
基本概念——多态性（多形性）
多态：
相同接口具有不同的实现，对象的行为具有多种形态的特性。
¢简化了客户定义。
使客户对象除了支持特定接口外，不做其他设定。
¢相同接口的对象具有了可替换性。
复用对象的实现和应用
基本概念——面向对象的两种基本复用机制：
继承与对象合成
继承：
⏹根据一个类定义另一个类。
⏹在编译时静态定义，直接被程序设计语言支持，使用直接。
⏹便于修改正在复用的实现。
继承是一种白盒复用
“白盒”指可见性，通过继承，父类的内部可被子类所见。
继承产生的问题：
1）实际运行时不能改变在编译时所定义继承的执行过程
2）子类依赖父类：
•继承把父类执行过程的细节暴露给子类，破坏了封装。
•子类的物理表示、执行过程与父类有密切关系
•父类执行过程的任何改变都会强迫子类发生改变。
这种依赖性限制了适应性，最终也限制了可复用性。
对象合成：
在一个对象中包含对其他对象的引用
引用是一种动态连接：
在运行时将请求连接到一个对象和该对象的一个操作上。
——意味着请求不需指定特定的实现。
任何有适当接口的对象都可以接收请求。
相同接口的对象可以互相替换。
对象合成：
通过组合对象得到新的更复杂的功能。
但要求被组合对象有定义良好的接口。
特点：
•对象合成在运行时动态地通过对象请求访问其他对象。
•组合要求对象考虑相互的接口，精心设计接口。
•任何一个对象都可在运行时被另一个有相同的类型对象替代。
对象组合是一种黑盒复用—对象的内部细节不可见，对象像一个黑盒。
对象合成的优点：
¢对象只能由其接口访问，不破坏封装。
¢对象的实现根据接口编写，依赖性减少。
¢有助于类的封装，使每个类集中于一个任务。
¢容易组合运行时的行为，改变行为组合的方式。
对象合成的缺点：
¢系统的行为不是在本类中定义，而依赖于对象的相互关系。
¢更难理解、运行效率降低。
采用对象合成优于采用类继承（合成/聚合复用原则）。
委托（delegation）：
对象合成的特例。
一个控制请求的执行：
继承方法：
子类将请求交给父类执行。
委托方法：
接收操作的对象把操作委托给它的代理对象。
接收操作的对象把自己本身也传给委托者，以使被委托操作指向接收对象。
[例]窗口类的实现
继承方法：
使窗口类成为矩形的子类，继承其操作。
窗口类将请求交给矩形父类执行
代理方法：
¢产生一个矩形实例，并代理复用矩形的行为
¢窗口将请求传给此矩形实例
¢把操作委托给矩形实例
¢把自己本身也传给矩形实例，以使被委托操作指向接收对象
¢让窗口好像是一个矩形
在运行中用圆实例代替矩形实例就适用圆形窗口
窗口类对矩型类实例的引用
基本概念——参数化类型（泛型）
参数化类型：
定义类时不规定它所用的数据元素类型。
这些类型在使用时作为参数提供。
[例]：
列表类—将元素的类型提供给列表的类型参数，实现时为列表类建立每种元素的可定制形式。
整数列表—把类型“整数”作为参数。
字符串列表—类型“字符串”作为参数。
设计模式——面向对象的可维护性复用
设计模式：
更高的层次上的可复用性（宏观逻辑的抽象层次复用）
可以帮助解决以下问题：
1．合适的对象（类）的寻找
2．对象（类）粒度的确定：
如何分解粒度合适的类
3.对象（类）接口的确定：
如何定义类接口和继承体系
4．对象（类）实现的确定
5.复用机制的处理：
如何建立类（类）的关键联系
6．运行结构和编译结构的处理
7．设计中变动的处理
1．寻找合适的对象
系统分解为对象的困难：
¢需要兼顾多种矛盾因素：
•封装、粒度、依赖关系、灵活性、性能、系统演化、可重用性。
¢难以确定多种分解对象方法的优劣。
一些方法：
（1）问题陈述→找出名词和动词→构造相应的对象和操作；
（2）集中考虑系统中的协作和职责；
（3）构造现实世界模型，把分析得到的对象转换到设计中。
¢设计的结果并不能完全来自于现实世界
•通常是：
现实世界的类+非现实世界的类（如数组、抽象类等）。
设计模式可以帮助确定设计抽象的对象。
（如strategy把算法抽象成类）
2．确定对象的粒度
设计模式帮助按照需要确定对象的大小。
Façade模式：
用一个对象描述完整的子系统
Flyweight模式：
支持大量最小粒度的对象
3.确定对象的接口
设计模式帮助确定：
（1）接口定义。
识别关键元素和由接口取得的数据的类型。
（2）规定接口间的关系和接口限制。
4．确定对象实现
对象的实现由它的类来定义。
a.类的表示——抽象类/具体类/混合类
b.类的实现——类继承/接口继承
5.处理复用机制
¢理想情况下，应该只通过对象合成来得到所需的功能。
¢但限于可用部件的集合不够丰富。
继承和对象合成可以互相补充。
三种复用技术的特点：
继承——允许提供操作的缺省实现并允许子类超越父类操作。
对象合成——允许运行时改变被组合的行为，但间接完成，效率不高。
参数化类型——允许改变一个类可用的类型。
但不能在运行中改变（如：
泛型是在编译时确定的）。
哪种方法最好取决于设计和实现约束。
6．运行结构和编译结构
编译结构（代码结构）——编译时即被冻结，由具有固定继承关系的类组成。
编译结构代码不能显示出一个系统工作的全部情况。
运行结构——由迅速变化的通信对象网组成。
系统运行结构的优劣主要由设计者设计的对象及其类型之间的关系来决定，而不是由语言来决定的。
[例]：
运行结构和编译结构
聚集（aggregation）和关联（acquaintance）关系。
聚集：
对象包含另一个对象或对另一对象负责，或为另一个对象的一部分，具有相同生命期。
关联：
一个对象只知道另一个对象。
关联对象之间可互相请求操作，但不对对方负责。
是比聚集弱的联系，提供了对象间的松耦合。
——聚集和关联的运行结构不同
聚集和关联常用相同的方法编译实现：
在Smalltalk中：
都是其他对象的引用。
聚集和关联没有区别。
在C++中：
都用指针和引用来实现。
——聚集和关联的编译结构相同
由此可见：
•关联和聚集关系主要由设计含义决定，而不是由语言机制决定。
•在编译结构中，关联和聚集之间的差别小，在源代码中难以辨认。
•差别：
聚集关系往往会比关联关系少而更稳定。
关联关系出现频繁，有时只在一个操作持续的时间中存在。
动态性更强。
7．通过良好的设计支持变化
达到最大复用程度的关键：
在设计时预先考虑生命期内新需求和现有需求的变化。
包括：
¢类的重定义和重新实现、
¢客户修改和重新测试。
设计模式的作用：
¢确保系统只用特定的方式发生改变。
¢允许系统结构的某些部分的变化独立于另外部分，因此有较高的健壮性。
（策略是封装变化）
三种使用设计模式的软件
应用系统、工具包、框架
设计难度:
应用系统＜工具包＜框架
（1）设计模式在应用系统中的作用：
设计模式的松散耦合，封装使操作、算法、和表示的依赖性减少，提高了对象类与其他类互操作的可能性。
——增加了内部复用可能。
减少对平台依赖性。
——系统的可维护性变强。
利用类继承关系和对象合成，使类耦合减少，一个类不依赖于其他类。
——提高可扩展性。
（2）设计模式在工具包中的作用：
工具包
——类库中预先定义的相关的可复用的类的集合，面向对象的子程序库。
——只为应用系统提供某些通用功能。
如列表、联合表、栈等，C++的I/O流库等。
——强调代码复用，没有特定的设计要求。
工具包的设计特点：
比应用系统的设计难。
¢要在多种应用系统中工作。
¢设计者不知应用系统情况和特殊要求。
要求：
避免假设和依赖性，依赖性会限制工具包的适应性，进而限制可利用性和效率。
设计模式有助于提高工具包的适用性。
框架——为开发特定要求的软件而构建的可复用的设计。
框架强调设计复用而不仅是代码复用。
框架被认为是面向对象系统获得最大复用的方式。
特定应用的框架是框架抽象类的特定应用子类：
包括：
——一个特定的领域中的一组相互协作的类；
——常用于该应用领域的设计决策；
[框架实例]：
图形编辑器框架：
可以帮助建立各种图形编辑器
语言编译器框架：
帮助建立不同程序设计语言的编译器
应用系统模型：
帮助建立各种应用系统。
框架设计要求:
——应能为某领域的所有应用系统工作。
——框架定义的结构应灵活和可扩展。
——框架接口要求松散耦合。
框架的参数：
应用系统的总体结构
类和对象的划分
类和对象的关键责任
类和对象合作
控制线索
框架和工具包复用特点：
设计模式对框架的支持
1）设计模式的应用有助于提高框架的适用性
——达到更高水平的设计复用和代码复用。
2）设计模式的应用有助于提高框架自身的可维护性
——提高了一致性,便于维护。
3）设计模式的应用及相关文档可以提高框架的可理解性;
使用框架的缺点:
¢应用系统的设计者失去了表现创造性的自由（因为许多设计决策已由框架的设计者确定了）。
¢丧失一些灵活性
设计模式和框架关系：
1）设计模式比框架更抽象。
框架——用程序设计语言代码体现，能直接学习、执行和复用。
模式——代码只体现模式的实例，设计模式只能在每次被使用时执行。
2）设计模式是比框架更小结构元素。
框架可以包括若干设计模式，反之不成立。
3）设计模式比框架有更广泛的意义。
框架针对特定的应用领域（图形编辑器框架用于CAD）
设计模式可用于几乎所有的应用。
升级会员 