面向对象系统设计.pptx

《面向对象系统设计.pptx》由会员分享，可在线阅读，更多相关《面向对象系统设计.pptx（53页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、会计学1面向对象系统设计面向对象系统设计第一页，编辑于星期二：十一点 一分。主要内容主要内容n n一、面向对象设计概述n n二、系统体系结构设计n n三、软件类的设计n n四、面向对象设计原则第1页/共53页第二页，编辑于星期二：十一点 一分。一、面向对象设计概述一、面向对象设计概述n n面向对象设计模型在面向对象分析模型和面向对象程序之间架起了一座桥梁；n n面向对象程序的基本概念是程序由一系列协同完成某一任务的一组程序对象组成，每个程序对象有程序逻辑和一些必要的属性，这些逻辑和属性封装在一个单元中；对象之间通过互相传递消息来协调工作，它们共同工作来完成主程序的功能。第2页/共53页第三页，

2、编辑于星期二：十一点 一分。n n从分析到设计n n分析的目标是做正确的事，理解问题域的重点目标、对象和相关规则；设计工作是正确地做事，从技术的角度灵活地设计解决方案；n n面向对象的分析和设计都基于相同的模型，一般认为没有严格的阶段性和很明显的界限。第3页/共53页第四页，编辑于星期二：十一点 一分。n n面向对象设计的目标n n设计软件体系结构，定义系统的高层划分，确定主要组件及其接口；n n详细设计软件类或接口，按照架构模式定义信息系统的边界类、控制类和实体类；n n设计数据库接口，解决面向对象模型到数据库模型的过渡。第4页/共53页第五页，编辑于星期二：十一点 一分。二、系统体系结构设

3、计二、系统体系结构设计n n体系结构设计概述n n层的设计n n包的设计第5页/共53页第六页，编辑于星期二：十一点 一分。n n体系结构设计概述n n系统体系结构也称为系统架构，是指一个或一组结构，它包含组成系统的软件元素、这些元素对外可见的性质以及它们之间的关系；n n系统架构是最高层次的系统分解，包括逻辑设计和物理部署两部分；逻辑架构通过系统的层、包、主要框架、类、接口和子系统的组织方式来描述，物理部署描述了进程分配和网络配置。第6页/共53页第七页，编辑于星期二：十一点 一分。n n层的设计n n在分解复杂的信息系统时，用的最多的技术之一就是分层；n n在采用分层架构时，下层组件负责对

4、上层组件提供服务，上层组件可以使用下层组件定义的服务，但下层组件对上层组件一无所知；n n层与层之间通常是不透明的，每一层都具有独立的职责。第7页/共53页第八页，编辑于星期二：十一点 一分。n n三层架构n n在信息系统领域，最常用的分层模型是三层架构模在信息系统领域，最常用的分层模型是三层架构模型：表现层、业务逻辑层、数据存储层；型：表现层、业务逻辑层、数据存储层；n n表现层：处理用户和信息系统之间的交互；表现层：处理用户和信息系统之间的交互；n n业务逻辑层：信息系统所有和问题领域相关的工作；业务逻辑层：信息系统所有和问题领域相关的工作；n n数据存储层：与数据交互，存储持久数据。数据

5、存储层：与数据交互，存储持久数据。第8页/共53页第九页，编辑于星期二：十一点 一分。第9页/共53页第十页，编辑于星期二：十一点 一分。n n对每个信息系统应用，以上三层是基本的层次结构，具体如何分离取决于问题的复杂程度；复杂一些的系统可以将三层行为分别封装在不同的包中；n n伴随着职责的分离，必须遵守一条关于层间依赖的普遍原则：业务逻辑层和数据存储层绝对不要依赖于表现层；n n多层架构：当业务逻辑变得越来越复杂时，可以根据系统的实际情况或设计需求，进行进一步的分解，基本的三层结构可以扩展为四层、五层或更多。第10页/共53页第十一页，编辑于星期二：十一点 一分。n n包的设计n n包是一种

6、逻辑分组的概念，可以取UML模型中的任何一种事物，将相关成分聚在一起，以构成更高层的组织单元；n n最常用的方法是将类以包为单位进行分组，例如可以将每一层的所有类组成一个包；n n一个包可以包含其他的包。第11页/共53页第十二页，编辑于星期二：十一点 一分。n n分包的原则n n共同封闭原则：一个包中的各个类应该是由于相似共同封闭原则：一个包中的各个类应该是由于相似的原则而改变，即将一组职责相似、但以不同方式的原则而改变，即将一组职责相似、但以不同方式实现的类归为一个包中，例如将所有处理交互界面实现的类归为一个包中，例如将所有处理交互界面的类放在界面包中，将所有处理业务逻辑的类放在的类放在界

7、面包中，将所有处理业务逻辑的类放在业务逻辑包中；业务逻辑包中；n n共同复用原则：一个包中的各个类应该一起被复用，共同复用原则：一个包中的各个类应该一起被复用，即包中包含了一组不同类型的类，它们之间通过相即包中包含了一组不同类型的类，它们之间通过相互协作实现一个意义更大的责任，对包中一个类的互协作实现一个意义更大的责任，对包中一个类的修改会影响到包中其他类，所以复用其中一个类可修改会影响到包中其他类，所以复用其中一个类可能需要同时考虑同一个包中的其他协作类。能需要同时考虑同一个包中的其他协作类。第12页/共53页第十三页，编辑于星期二：十一点 一分。n n在UML中，把包画为文件夹的形式：第1

8、3页/共53页第十四页，编辑于星期二：十一点 一分。n n设计包图n n包图用来描述包及其依赖关系；包图用来描述包及其依赖关系；n n包图的目标是用于标识一个完整系统的主要部分；包图的目标是用于标识一个完整系统的主要部分；n n在包图中只使用两个符号：一个包的标识符，一个在包图中只使用两个符号：一个包的标识符，一个虚线箭头，虚线箭头表示依赖关系，箭头的尾部表虚线箭头，虚线箭头表示依赖关系，箭头的尾部表示被依赖的包，头部是独立的包。示被依赖的包，头部是独立的包。第14页/共53页第十五页，编辑于星期二：十一点 一分。n n包依赖关系可以是直接的，也可以间接的，依赖关包依赖关系可以是直接的，也可以

9、间接的，依赖关系可以传递系可以传递;n n通过包图，开发人员能够估算某个包中类的复杂度，通过包图，开发人员能够估算某个包中类的复杂度，估算出重用一个包的难易程度。估算出重用一个包的难易程度。第15页/共53页第十六页，编辑于星期二：十一点 一分。第16页/共53页第十七页，编辑于星期二：十一点 一分。三、软件类的设计三、软件类的设计n n基本概念n n设计属性n n设计方法n n设计关系第17页/共53页第十八页，编辑于星期二：十一点 一分。n n基本概念n n软件类是设计阶段中讨论的类，也称为设计类，对应的分析阶段的类称为概念类或领域类；n n分析模型中的类通常是现实事物或概念的抽象，这些类

10、要转换为软件世界中的类；n n另外，为了完成用例所描述的功能，还必须添加一些计算机领域的软件对象的类。第18页/共53页第十九页，编辑于星期二：十一点 一分。n n边界类n n边界类的职责是完成系统与其参与者之间的交互。边界类的职责是完成系统与其参与者之间的交互。这种交互通常包括接收来自用户和外部系统的信息这种交互通常包括接收来自用户和外部系统的信息与请求，以及将信息与请求提交给用户和外部系统；与请求，以及将信息与请求提交给用户和外部系统；n n通常将用户界面或通信接口的变化封装在一个或多通常将用户界面或通信接口的变化封装在一个或多个边界类中；个边界类中；n n边界类的主要职责是接收用户的触发

11、事件，并通过边界类的主要职责是接收用户的触发事件，并通过对界面中的各种图形元素进行编程来进行响应。对界面中的各种图形元素进行编程来进行响应。第19页/共53页第二十页，编辑于星期二：十一点 一分。第20页/共53页第二十一页，编辑于星期二：十一点 一分。n n建立用户界面原型建立用户界面原型n n设计阶段的任务是使所有的技术明朗化，其中之一就是尽设计阶段的任务是使所有的技术明朗化，其中之一就是尽早地建立用例的用户界面原型，即边界类的设计；早地建立用例的用户界面原型，即边界类的设计；n n通过界面原型可以进一步收集和明确需求，并为构件系统通过界面原型可以进一步收集和明确需求，并为构件系统正式的动

12、态模型做铺垫，为设计业务逻辑类的职责和方法正式的动态模型做铺垫，为设计业务逻辑类的职责和方法提供帮助；提供帮助；n n界面原型不需要描述太多细节，通常包含以下内容：界面原型不需要描述太多细节，通常包含以下内容：n n需要要用户输入到系统中的数据窗口或表格；需要要用户输入到系统中的数据窗口或表格；n n需要由系统执行的操作按钮；需要由系统执行的操作按钮；n n系统应及时做出回应的事件；系统应及时做出回应的事件；n n需要由系统输出给用户的数据窗口或消息。需要由系统输出给用户的数据窗口或消息。第21页/共53页第二十二页，编辑于星期二：十一点 一分。n n实体类n n实体类来源于领域模型中的类，多

13、数情况下对应于实体类来源于领域模型中的类，多数情况下对应于领域模型中的领域类；领域模型中的领域类；第22页/共53页第二十三页，编辑于星期二：十一点 一分。n n控制类n n控制类代表协调、排序、事物处理以及对其他对象控制类代表协调、排序、事物处理以及对其他对象的控制，经常用于封装与某个具体用例有关的控制的控制，经常用于封装与某个具体用例有关的控制流；流；n n控制类还可以用于表示复杂的派生与演算，但它们控制类还可以用于表示复杂的派生与演算，但它们与系统需要存储的任何具体持久信息没有关系；与系统需要存储的任何具体持久信息没有关系；n n根据分层原则，控制类并不封装与参与者交互有关根据分层原则，

14、控制类并不封装与参与者交互有关的问题，也不封装与系统处理的长效、持久信息有的问题，也不封装与系统处理的长效、持久信息有关的问题，这些问题分别是由边界类和实体类封装关的问题，这些问题分别是由边界类和实体类封装的，而控制类只对控制、协调、排序、事务处理以的，而控制类只对控制、协调、排序、事务处理以及某些复杂业务逻辑进行封装及某些复杂业务逻辑进行封装 。第23页/共53页第二十四页，编辑于星期二：十一点 一分。第24页/共53页第二十五页，编辑于星期二：十一点 一分。n n设计类的属性设计类的属性n n设计属性的类型和初值：属性的类型和默认的初始值应设计属性的类型和初值：属性的类型和默认的初始值应该

15、在设计模型中表示出来；该在设计模型中表示出来；n n设计属性的可见性：属性的可见性指定了该属性可以被其他类利设计属性的可见性：属性的可见性指定了该属性可以被其他类利用的程度用的程度,UML,UML定义了以下几种可见性：定义了以下几种可见性：n n（1 1）公有的（）公有的（publicpublic）定义为定义为“公有的公有的”属性，在其他属性，在其他任何类中都能访问到，使用任何类中都能访问到，使用“+”+”号做前缀来表示一个属性是号做前缀来表示一个属性是“公有的公有的”；n n（2 2）受保护的（）受保护的（protectedprotected）定义为定义为“受保护的受保护的”属性，该类属性，

16、该类的所有子孙类都可以访问该属性，而所有非子孙类则不能访问，的所有子孙类都可以访问该属性，而所有非子孙类则不能访问，使用使用“#”#”号做前缀来表示一个属性是号做前缀来表示一个属性是“受保护的受保护的”；n n（3 3）私有的（）私有的（privateprivate）定义为定义为“私有的私有的”属性，只能在该类中属性，只能在该类中使用，其他类都不能访问，使用使用，其他类都不能访问，使用“-”-”号做前缀来表示一个属性是号做前缀来表示一个属性是“私有的私有的”。第25页/共53页第二十六页，编辑于星期二：十一点 一分。n n对于属性的类型和初始值都应该在设计模型中描述出来。类型和属性名之间用冒号

17、隔开，等号之后写初始值。一个完整的属性定义如下：可见性 属性名：类型 初始值第26页/共53页第二十七页，编辑于星期二：十一点 一分。n n在进行属性设计时，可以参考以下一些指导原则：n n（1 1）仔细考虑分析类图中的属性，分析类的属性和）仔细考虑分析类图中的属性，分析类的属性和软件类的属性并不都是一一对应的，有时，分析类软件类的属性并不都是一一对应的，有时，分析类的一个属性隐含着软件类需要有一个或多个属性；的一个属性隐含着软件类需要有一个或多个属性；n n（2 2）当考虑属性的候选类型时，可以根据实际的编）当考虑属性的候选类型时，可以根据实际的编程语言来确定；程语言来确定；n n（3 3）

18、如果一个软件类因为其属性的原因变得复杂而）如果一个软件类因为其属性的原因变得复杂而难于理解时，可以视具体情况将其中的一些属性分难于理解时，可以视具体情况将其中的一些属性分离出来形成单独的类。离出来形成单独的类。第27页/共53页第二十八页，编辑于星期二：十一点 一分。第28页/共53页第二十九页，编辑于星期二：十一点 一分。n n设计方法n n设计阶段最为重要的任务是设计软件对象所要执行的操作；n n分析模型中已经大致勾画了对象行为的轮廓，在设计阶段需要对这些行为进行细化，结合用例模型和交互图来定义软件类的方法。第29页/共53页第三十页，编辑于星期二：十一点 一分。n n消息和方法 n n一

19、个类的操作需要支持该类在不同用例中所扮演的一个类的操作需要支持该类在不同用例中所扮演的所有角色，换句话说就是这个类应该承担起它应有所有角色，换句话说就是这个类应该承担起它应有的职责或义务；的职责或义务；n n职责的分配贯穿于交互图的整个生成过程，职责在职责的分配贯穿于交互图的整个生成过程，职责在UMLUML中通过消息的发送分配给不同的对象，消息的中通过消息的发送分配给不同的对象，消息的发送者需要某项服务，消息接收者就要提供相应的发送者需要某项服务，消息接收者就要提供相应的服务，即意味着接收者所要承担的职责，并最终转服务，即意味着接收者所要承担的职责，并最终转化为接收者的方法；化为接收者的方法；

20、n n很多消息发送之后，消息的接收对象会在响应后产很多消息发送之后，消息的接收对象会在响应后产生一些结果回传给发送者，这就是返回消息。生一些结果回传给发送者，这就是返回消息。第30页/共53页第三十一页，编辑于星期二：十一点 一分。n n具体方法：n n明确职责：软件类的方法就是一个对象应该执行的明确职责：软件类的方法就是一个对象应该执行的操作，称这些操作为对象的职责；操作，称这些操作为对象的职责；n n职责和交互图：职责在职责和交互图：职责在UMLUML中通过消息的发送分配中通过消息的发送分配给不同的对象，消息的发送者需要某项服务，接收给不同的对象，消息的发送者需要某项服务，接收者提供相应的

21、服务，即意味着接收者所要承担的职者提供相应的服务，即意味着接收者所要承担的职责，并最终转化为接收者的方法；责，并最终转化为接收者的方法；n n遍历所有的交互图，发送给某个对象的所有消息的遍历所有的交互图，发送给某个对象的所有消息的集合就表明了该对象必须定义的大多数方法。集合就表明了该对象必须定义的大多数方法。n n除了从消息得到方法外，还应该注意另外一种方法属性访问方法。第31页/共53页第三十二页，编辑于星期二：十一点 一分。第32页/共53页第三十三页，编辑于星期二：十一点 一分。第33页/共53页第三十四页，编辑于星期二：十一点 一分。第34页/共53页第三十五页，编辑于星期二：十一点

22、一分。遍历所有有“入库单”对象参与的用例，结合用例的事件流描述和用例的顺序图，依次找出“入库单”对象的职责，进而形成“入库单”类的方法。例如，根据“入库登记”用例可以确定“入库单”类的一个create（创建）方法，依次类推，可以确定“入库单”类的如下方法：create（创建）、find（查找）、auditing（审核）、associate（关联码单）、reckoning（平帐）、delete（删除）等。第35页/共53页第三十六页，编辑于星期二：十一点 一分。n n定义方法 n n和属性一样，类的方法也可以定义可见性；和属性一样，类的方法也可以定义可见性；n n在在UMLUML图中，一个方法按

23、如下格式进行标识：图中，一个方法按如下格式进行标识：可见性可见性 方法名（方法参数列表）：类型表达式方法名（方法参数列表）：类型表达式 第36页/共53页第三十七页，编辑于星期二：十一点 一分。n n设计关系n n类之间的关系主要有三种：依赖关系、泛化关系和关联关系，因此关系的设计也主要从这三种关系的设计入手；n n设计依赖关系n n将被依赖的类的实例作为依赖于它的另一个类的某将被依赖的类的实例作为依赖于它的另一个类的某个方法的参数；个方法的参数；第37页/共53页第三十八页，编辑于星期二：十一点 一分。class Personvoid Work(Screwdriver tool);class

24、 Screwdriver;第38页/共53页第三十九页，编辑于星期二：十一点 一分。n n设计泛化关系n n一般在面向对象语言中使用继承来实现泛化关系，一般在面向对象语言中使用继承来实现泛化关系，继承机制实现了子类拥有父类特性的这一过程。继承机制实现了子类拥有父类特性的这一过程。n n设计关联关系 n n在关联的源类中声明一个实例属性来保存对目标类在关联的源类中声明一个实例属性来保存对目标类的实例的引用，这种属性称为关联属性或引用属性。的实例的引用，这种属性称为关联属性或引用属性。classStackingList/码单类码单类private:/其他属性其他属性ReciverList&reci

25、ver;/相关联的入库单编号相关联的入库单编号;第39页/共53页第四十页，编辑于星期二：十一点 一分。四、面向对象设计原则四、面向对象设计原则n n单一职责原则 n n所谓职责，可以定义为“变化的原因”，单一职责原则描述的就是：对于一个类而言，应该仅有一个引起它变化的原因；n n换句话说，一个类的功能要单一，只做与它相关的事情。第40页/共53页第四十一页，编辑于星期二：十一点 一分。interfaceModempublicvoiddial(stringpno);publicvoidhangup();publicvoidsend(charc);publicvoidrecv();interfa

26、ceDataChannelpublicvoidsend(charc);publicvoidrecv();interfaceConnectionpublicvoiddial(stringpno);publicvoidhangup();第41页/共53页第四十二页，编辑于星期二：十一点 一分。n n开放封闭原则 n n“变化才是不变的真理”，我们阻止不了需求的改变，但可以通过设计使得系统能够适应改变又能保持相对稳定；n n开放封闭原则的应用就是要在模块本身不变动的情况下，通过改变模块周围的环境达到修改目的；n n开放封闭原则是指：软件实体（类、模块、函数等）应该是可以扩展的，但是不可以修改的；第4

27、2页/共53页第四十三页，编辑于星期二：十一点 一分。n n遵循开放封闭原则设计出的模块具有两个主要特征：n n“对于扩展是开放的对于扩展是开放的”：这意味着模块的行为是可：这意味着模块的行为是可以扩展的。当应用的需求改变时，在模块上进行扩以扩展的。当应用的需求改变时，在模块上进行扩展使其具有满足那些改变的新行为；展使其具有满足那些改变的新行为；n n“对于更改是封闭的对于更改是封闭的”：这意味着当对模块进行扩：这意味着当对模块进行扩展时，不必改动模块的源代码或二进制代码。展时，不必改动模块的源代码或二进制代码。第43页/共53页第四十四页，编辑于星期二：十一点 一分。图形（Shape）类根据

28、ShapeType来说明图形类型，再根据不同的图形类型采用不同的公式来计算面积。当每增加一种图形时，都需要修改Shape类中的计算方法，因此Shape类对于更改就不是封闭的，这样的设计就不符合OCP原则。第44页/共53页第四十五页，编辑于星期二：十一点 一分。将所有图形的共性抽取出来，将图形类设计成一个抽象类，定义一个抽象方法getArea，具体的圆、矩形等图形类继承于图形类，并分别实现getArea方法，从而实现计算各自面积。抽象的这一部分内容就是封闭的，扩充新的图形也不需要修改Shape类的任何内容，只需派生一个新类，并实现getArea方法就能达到扩展的目的，也就符合OCP原则 第45

29、页/共53页第四十六页，编辑于星期二：十一点 一分。n n依赖倒置原则 n n在传统的结构化编程中，最上层的模块通常都要依赖下面的子模块来实现，也称为高层依赖低层；n n依赖倒置原则就是要逆转这种依赖关系，让高层模块不要依赖低层模块：n n高层模块不应该依赖于低层模块，二者都应该依赖高层模块不应该依赖于低层模块，二者都应该依赖于抽象；于抽象；n n抽象不应该依赖于细节，细节应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。第46页/共53页第四十七页，编辑于星期二：十一点 一分。ToggleSwitch（开关）类依赖于Light类，当Light类发生变化时，势必会影响到ToggleSw

30、itch类，例如对于不同的灯会有不同的开关方式，ToggleSwitch就要随着Light的变化而变化，这样就没有实现依赖倒置原则。第47页/共53页第四十八页，编辑于星期二：十一点 一分。将Light设计成一个抽象类或者一个接口，让ToggleSwitch依赖于该抽象类（或接口），让具有不同开关方式的灯继承于该抽象类（或实现该接口），这样，ToggleSwitch类就不会随着灯泡类型的改变而发生变化，同时，这样的设计还满足了封闭开放原则。第48页/共53页第四十九页，编辑于星期二：十一点 一分。n nLiskov替换原则 n nLiskov原则提供了一种解决方案来设计最佳的继承层次，使得不违

31、反开放封闭原则。n nLiskov替换原则的核心思想可以解释为：子类型必须能够替换掉它们的基类型。通俗一些的理解就是，基类的方法都要在子类中实现或者重写，不允许子类出现基类所没有定义的方法。第49页/共53页第五十页，编辑于星期二：十一点 一分。考虑到正方形是一种长方形，所以如图的继承设计是合乎逻辑的。第50页/共53页第五十一页，编辑于星期二：十一点 一分。正方形的长宽相等，因此它继承的itsWidth和itsHeight两个属性产生了冗余，是一种浪费。另外，Square类同时拥有setWidth和setHeight两个方法也不合适。第51页/共53页第五十二页，编辑于星期二：十一点 一分。voidresize(Rectangler)Whiel(r.getHeigth=r.getWidth)r.setWidth(r.getWidth+1);修改完成后，在一般情况下使用Square类时不会出现错误了，但我们考虑如下一段代码：在这个例子中，子类型（正方形类）就不能替代它的基类型（长方形类），因此这个设计就违反了Liskov替换原则。第52页/共53页第五十三页，编辑于星期二：十一点 一分。