1 / 11
文档名称:

UML及面向对象设计思想.doc

格式:doc   大小:215KB   页数:11页
下载后只包含 1 个 DOC 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

UML及面向对象设计思想.doc

上传人:小博士 2018/11/15 文件大小:215 KB

下载得到文件列表

UML及面向对象设计思想.doc

文档介绍

文档介绍::..O类是面向对象技术的基础,是面向对象程序设计的基本单元。类图描述软件系统的静态结构。类图不仅定义了系统中的类,表示了类与类之间的关系(关联、依赖、继承),而II也描述了类的内部结构(类的属性和操作)。O类图描述的是系统的一种稳定的静态关系,在系统的整个生命期内都是有效的。O类可以进一步划分为实体类、边界类和控制类。■实体类保存系统中的信息。一个实体类的对象对应关系数据库中■边界S是系统与用户的接口。用户通过边界类与系统进行交互。■控制类协调和控制其他类的对象以实现用例规定的行为,它封装了实现用例行为所需要的事件流。O在系统分析阶段,主要考虑的是实体类。在设计和实现阶段,除了对实体类进一步细化之外,还要着重考虑边界类和控制类。UML中类的基本表示方法:类的封装性及其表示O封装性表现为类成员的可见性。可见性分为公开的(public)、受保护的(protected)和私有的(private)三种。O 在UML中分别用“+”,“#”和表示。“+”表示完全公开;“#”表示对同一个包中的类公开,对不同包中的类隐藏;表示对外完全隐藏,仅仅对定义该成员的类的内部可见。可见性也被分为:公开的,受保护的,默认的,私有的四类。其中“受保护的”对同一个包的其它类及不在同一个包的子类可见;“默认的”对同一个包的其它类可见。类之间的关系表示类之间的关系可以分为继承和关联,关联可以进一步分为组合、聚集和依赖。类之间关联关系的表示关联用于泛指两个类之间概念上的联系。例如公司类和雇员类之间就存在联系,雇员为公司工作,公司雇佣雇员。Employee-workfor-pany1..*1在关联关系的两端,可以标注关联约朿,还可以标注关联在数量上的对应关系(关联的多重性)。pany关联,pany因为雇佣而与Employee¥联,一个公司可以雇佣一个以上(1..*)的雇员。关联关系的细分关联关系^可以进一步划分为组合、聚集和依赖。O组合关系是一种紧密而稳定的关联关系。如公司与部门是一种组合关联关系,因为如果没有公司,部门也将不存在。有时组合关系也用于描述一个类的对象伍含另一个类的确定个数的对象作为成员,例如:一辆汽车包含一台发动机、四个轮胎,则汽车类与发动机类和轮胎类的关系是组合关联关系。O聚集(聚合)关系是一种较为松散的关系。例如:雇员与公司和部门之间的关系不是一种稳定的关系,因为即使公司或者部门不在了,雇员仍然存在,而且公荀中雇员的人数不是固定的,雇员可以在部门之间或者公司之间流动。所以雇员与公司和部门之间的关系是聚合关系。在面向对象的程序设计中,聚合关系表现为一个类屮声明另一个类的集合变量作为类成员。组合与聚合关系的表示O依赖关系是一种更为松散的关系。例如汽车和加油站的关系就是依赖关系。汽车类依赖加油站类,只有汽车加油时才会与加油站发生关联,而且在哪一个加油站加油也是不固定的。依赖关系中,被依赖的类的对象是依赖类的操作所要使用的一种工具。在面向对象的程序设计中,依赖关系表现为依赖类的某个方法或者函数的参数类型是被依赖类的类型。对象图O对象是类的实例,对象图描述在某一瞬间系统中存在的对象及对象间的关系。对象名:类名OUML中对象的表示car007:CarO对象阁示例collidingagainsttruck2013:Iruckcar007:Car设计过程中的权衡设计过程中,针对设计目标约朿冲突给出的非功能性需求判断准则。正确性:解的完全性和正确性;安全性;容错性处理能力;保密性和鲁棒性。资源:执行效率:时间复杂度、消息数、带宽要求等;空间消耗:包括存储单元、对象、线程、过程、通信通道。处理器等的使用情况;增加的资源,一些随选信息;动态策略,包括公正性、平衡性、稳定性等。结构:模块性:封装、耦合、独立性;可延展性:伍括子类、可协调性、发展性、可维护性等;可重用性、开放性、可组合性。便携性、可插入性;前后依赖性;互用性;等等。工程:可理解性、简革、高雅;执行中的容错性;与其他软件的共存性;系统可维护性:开发过程的影响:开发队伍结构及动态特性的影响:用户参与的影响:生产力、时间安排、成木的影响;等等。用法:使用规范;人为因素,如可学****性、恢复能力等;对不断变化的环境的适应性;艺术性;医学和环境的影响;社会、经济、政治的影响;等等。设计模式核心思想O核心思想原则:重点解决软件系统可维护性和复用性问题。>普遍的问题>基本的问题>重现的问题可维护性可维护性好的系统应有的性质:O可扩展性:容易加入新的性能O灵活性:代码修改尽量不波及其他模块O可插入性:容易抽出和加入类传统的复用:代码的剪贴复用;算法的复用;数据结构的复用可维护性和复用的矛盾传统的复用的风险:O影响可扩展性——过于僵