【文档说明】软件工程课件-第11章-面向对象设计-.ppt，共(51)页，383.012 KB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-44897.html

以下为本文档部分文字说明：

第十一章面向对象设计(Object-OrientedDesign)§1.OOD准则：优秀软件设计的一个重要特点是容易维护回顾：SD准则包括模块化抽象信息隐藏模块对于OOD有类似的准则：1、模块=对象§1.OOD准则过程抽象:在SD中已讨论数据抽象:Class即

是一种抽象数据类型。外界无须知道实现方法，按照类规格说明（即协议）可以使用合法的操作符，利用这些操作对类实例中包含的数据进行操作。参数抽象:将数据类型作为参数处理。2、抽象：抽出事物的本质特性,暂不考虑其细节，使设计从具体实现方法中超脱。§1.OOD

准则3、信息隐藏=对象的封装4、耦合:交互耦合(interactivecoupling):通过传递message发生要求降低参数个数和参数复杂性减少objects发送\接收message的个数aslooseaspossible

继承耦合(inheritancecoupling):要求ParentclassIS_Achildclassashighaspossible§1.OOD准则一般-特殊内聚（general-particularcohesion):Highg-pcohe

sionHighinheritancecoupling5、内聚：服务内聚(servicecohesion)：一个服务只完成一个功能。类内聚(classcohesion)：一个类只有一个用途，否则分解

之。6、可重用（Reusability）(详见§3)尽量使用已有的类设计新类时考虑将来的可重复使用性§2.启发式规则1、设计结果清晰易懂，应做到：①用词一致——按习惯用法命名。不同classes中相似的methods最好取同一名字。②使用已有的协

议。③尽量减少message模式的数目。④避免模糊定义。2、一般-特殊结构的深度应适当（约100个classes,则设计7±2层）§2.启发式规则3、设计简单的class（定义不超过一页纸或两屏）。应注意：①避免过多attributes；②能用简单的语句描述一个cl

ass的任务；③objects之间合作关系要简单；④避免过多methods(7个)。问题：设计出大量的classes，使结构复杂度增加。解决：划分主题，提高可理解性。4、使用简单的protocol，减少message

中传递的parameters5、使用简单的method(CASE可考虑用inheritance替代)。6、把设计变动减至最小。1、概念：知识重用（例如软件工程知识的重用）方法和标准重用（例如OO方法和国家规定的软

件开发规范的重用）软件成分的重用§3.软件重用(SoftwareReuse)知识工程•源码剪贴——无法溯源，无配置管理•Include——修改后所有包含了此段代码的程序都须重新编译。•Inheritance——无须改动原有代码想象一下，stdio

.h被改动之后……重用软件成分有三个级别：①代码重用：§3.软件重用②设计重用——当移植系统时③分析重用——当需求未变，而系统结构改变时2、重用效果的衡量：⑴额外代价：创建可重用成分的专门投资多花2~4倍时间测试以保证

质量构件库的建立与维护需要投资以上投资将分摊到重用这些构件的新系统成本中。重用次数越多，分摊成本越少。§3.软件重用记：Lt=Totallengthofcode(#oflines)Ln=Length

ofnewcodeLr=LengthofreusedcodeEt、En、Erarethecorrespondingefforts(#ofm-d)⑵重用率(Reusability)与生产率(Productivity)rnrn

ttEELLELProductivityReusability=trLL开发代码的生产率nnnELC重用新代码的生产率rrrELC)R/CC(11CPrnn§3.软件重用⑶重用技术：指利用可重用的构件开发软件的技术，及开

发可重用软件的技术。①软件组合技术：底层部件库法(Bottom-upcompositionalreuse)：从可重用的代码部件库(reuserepository)中选用部件，组合成软件。A：是，前提

条件为Cn<Cr,即重用比新开发效率高。Q：是否R越高P就越高？上层组合法：完整程序的组合§3.软件重用②软件生成技术：按照形式化的软件功能描述和一定的生成机理，由生成器系统(generatorsystem)自动生成目标程序。重

用的是generator的代码规则③OO重用技术：Classcomponent的重用（详见下文）⑷类构件(Classcomponent)：①可重用的软构件应具备的特点：独立、可塑、接口清晰（文档详尽）§3.软件重用②重用方式：实例重用(instance

reuse\black-boxreuse)：创建class的不同instances，通过messages完成不同的任务。是最基本的重用方式。用几个简单的objects创建出更复杂的class，是实例重用的另一种形式继承重用(inheritancereuse)

：是一种安全地裁剪已有的classcomponent的方式。多态重用(polymorphismreuse)：Parentclass与childclass有相同的对外接口，使消息连接的复杂度降低。§3.软件重用注意：有些操作可能会妨碍classcomponent的重用，如与表示方法有关的操

作与数据结构、大小有关的操作与外部设备有关的操作实现算法在将来可能会改进\改变的核心操作解决方法：将这些操作分离出来，作为适配接口(adaptiveinterface)，使class中其它操作通过调用AI而实现。在不同应用环境下，用户只须重新定义AI操作就可以重用cl

ass。§3.软件重用AdaptiveInterface还可进一步细分为转换接口(transitioninterface)：重用时必须重定义与表示方法、数据结构、硬件等有关的操作（例如C++中class里的purevirtualfunction）扩充接口(expansion

interface)：一个操作可由多种算法实现，若无新算法则继承老算法。§4.系统分解回顾SD：从DFD出发IPO面向对象设计模型，在逻辑上由四大部分组成。这四部分对应于组成目标系统的四个子系统：问题域子系统、人机交互子系统(HCI)、任务管理子系统和数据管理子系统。OO

D模型分解：问题域ApplicationDomain人机交互Human-ComputerInterface(HCI)任务管理TaskManagement数据管理DataManagementMethodAttributeStructureClas

s-&-ObjectCategory§4.系统分解与面向对象分析模型一样，它也由主题、类-&-对象、结构、属性、服务等五个层次组成，可以把这五个层次想象成整个模型的水平切片§4.系统分解1、子系统之间的交互方式(collaboration)①客户-供应商(client-superli

er)关系：②平等伙伴(peer-to-peer)关系：ClientsubsystemcontractSuppliersubsystemrequestcontractPeersubsystemcontractPeersubsyste

mrequestrequest§4.系统分解2、系统组织方案①层次组织：将系统组织成hierarchy，同一层中的objects相互独立，而上、下层间有client-supplier关系。一个client只能使用其相邻下层的

supplier提供的服务——封闭式(closed)一个client可使用其下任一层的supplier提供的服务——开放式(open)优点：高效；缺点：修改影响面广HCI典型应用系统的组织结构应用软件包操作系统计算机硬件人机对话控制仿真

软件包图形处理窗口图形屏幕图形象素图形§4.系统分解②垂直块组织：将系统垂直分解成若干独立的子系统，一个子系统相当于一块，每块提供一种类型的服务。§4.系统分解3、四种子系统的设计⑴问题域子系统：基于OOA建立的obje

ctmodel，进行补充修改。①调整需求②重用class：选出可用的class，标出与本问题无关的attributes和methods派生出childclass，标出继承的attributes和methods修改关联③组合class：通过引入rootclass完成，用于建

立publicprotocol。④调整inheritance。⑵HCI子系统：好的包装§4.系统分解①设计准则：一致性：术语、步骤、操作等始终一致。减少步骤：使完成一件任务所需敲键盘、点鼠标、下拉菜单等的次数都减至最少。及时提供反馈信息：提供hotkey操作

做一个体贴的statusbar提供撤销(undo)命令：无须记忆：不应要求用户记住某个窗口的信息，然后再用到窗口中——这是系统的责任而不是用户的任务。易学：提供HELP、联机参考等。富有吸引力§4.系统分解②设计策略设计HCI类：例如VC提供的MFC类库(MicrosoftFounda

tionClassLibrary)将用户分类（按技能、职务等）描述用户的类型、水平、使用目的、其它特征（如年龄、性别、习惯等），写出操作脚本设计命令层次：注意同用户熟悉的方式(如windows界面）尽量保持

一致.次序、深度、宽度调整适当§4.系统分解⑶任务管理子系统：基于OOA建立的dynamicmodel①分析并发性：若两个objects之间无交互行为，或它们同时接受events，则它们本质上是并发的(synchronous)考察eventflowdiagram，找出没有并

发对象的路径（称为控制线），每条对应一个任务(task，亦称process)不同的tasks对应必须同时发生的不同行为§4.系统分解②确定task类型，并分配给适当的软\硬件去执行事件驱动型(event-driven)

：主要完成通信工作。event=数据到达的interrupt时钟驱动型(clock-driven)：完成周期性工作。优先型(priority)：将highpriority或lowpriority的任务专门分离出来先做或后做。关键任务(k

eytask)：指关系系统成败的处理，要求高可靠性，应分离考虑，严格测试。协调任务(coordinator)：当系统中存在三个以上tasks时，应增设一个协调任务，用于封装不同tasks之间的协调控制。§4.系统分解⑷数据管理子系统：①选择管理模式文件管理

(filemanager)系统关系数据库(RelationalDataBase)管理系统面向对象数据库(OODB)管理系统②设计数据格式及相应的服务（请参阅教材p.268-269）§5.设计类中的服务——细化objectm

odel中的methods1、确立服务⑴从dynamicmodel出发：Eventflowdiagram(即状态图)中Event=message;接受message的object必有对应的method；Method改变status（即attribu

tes），并完成action。§5.设计类中的服务EventStatus1do:Action1Status2do:Action2……则算法应有DO_CASE型控制⑵从functionmodel出发：DFD的一般结构是IPO注意：Action（即算法）与stat

us有关。例如：不同status接受同一个event时，其action不同——InputFlowClass……ProcessI\OClass……Process§5.设计类中的服务若Process=从输入流中抽取一个值，则输入流就是目标对象IO

若和类型相同，而output实质上是input的另一个状态，则I\O是一类，有若则I1I2I3POOutputFlowClass……Process§5.设计类中的服务若则ProcessStorageStorageClass……Process对照DFD与Class-&-Object图，若一

个process涉及多个classes，则必须判断它属于哪一个class。例如：ActivatorReceiverProcess若Process改变了Receiver，则ReceiverClass……Process又如：从关联上看，process所

涉及的所有classes中，处于中心地位的class,一般拥有该process。§5.设计类中的服务2、设计实现方法⑴算法设计：要求做到易修改，并且复杂度低（即效率高）易理解，易实现。⑵数据结构设计：需要考虑具体的物理结构的选择。⑶新添用于存放内部处理中间结果的class；

引入新的低层操作，进一步细化。§6.设计关联1、单向关联例：雇员公司被雇用1+由雇员找其所属公司，则设雇主为其属性，即一单向指针雇员雇主公司由公司找其下属某一雇员，则有两种方法：方法1：遍历所有雇员，找雇主匹配且满

足特征的雇员。（省空间）§6.设计关联方法2：设公司的属性雇员为一指针集。（快速）雇员公司雇员指针集2、双向关联方法1：将上述两种单向关联结合使用雇员雇主公司雇员指针集雇员公司关联类雇主雇员工资方法2：另设关联类（特别适用于链属性）雇员公司find_skill雇用1

+技能具有技能1+1+§7.优化1、确定优先级：必须站在全局高度确定各项质量指标的优先级，在优化设计时制定折衷方案。切忌各子系统自以为是，导致最终优化目标对立。最常见的情况是在效率与清晰性之间的折衷。2、提高

效率的技术①增加关联（类）例：设某公司有2000名雇员，平均每名雇员会10种技能，其中有5人精通日语，现要查询公司中会讲日语的雇员是哪些人雇员公司精通语言1+语言1+§7.优化方法1：嵌套查询——遍历雇员20

00次，而对每个雇员遍历技能10次。命中率为1/4000。方法2：用HashTable实现技能，使“会讲日语”对应唯一的技能对象，则命中率上升为1/400。方法3：增加一个额外的限定关联“精通语言”，即可立刻查得结果。§7.优化②调整查询次序，优化算法例如公司有5名会日语的雇员，有

200名会法语的雇员。现要找日、法语均会的雇员，则应先找的雇员，再从中找的雇员。会日语会法语③保留内部中间过程产生的派生属性。3、调整继承关系①向上归纳②向下派生建立这样的索引必然多占空间，而且基关联改

变时也必须相应地修改索引。因此，应只给那些经常执行并且开销大、命中率低的查询建立索引。§7.优化例：实现Stack方法1：从List派生push=last+addpop=last+remove问题：Stack.first也是合法的。Listaddremovefirstl

astStackpushpopInheritance③利用委托(commitment)方法2：把List作为Stack的一个attribute，称为commitment。这种方法比较安全(Stack.first为非法)。Listaddremove

firstlastStackList1pushpopCommitment标准建模语言UMLUML概要TheUnifiedModelingLanguage(UML)•UML由OMG(ObjectManagementGroup)于1997年11月批准为标准建模

语言。•UML建立在当今国际上最有代表性的三种面向对象方法（Booch方法，OMT方法，OOSE方法）的基础之上。•UML是一种建模语言而不是一种方法，UML本身是独立于过程的。UML概要•UML可以用于问题可视化、说明和建立文档•UML图包括系统动态观点、静态观点、限制和形式化

•动态观点用usecases、活动图、交互图和状态图描述•静态观点用类图、包、配置描述•限制和形式化用OCL(ObjectConstraintLanguage)描述UML概要UML为人们提供了从不同的角度去观察和展示系统的各种特征的一种标准表达方式。在UML中，从任何一个角度对系统所作的

抽象都可能需要用几种模型图来描述，而这些来自不同角度的模型图最终组成了系统的完整模型。标准建模语言UML一般而言，我们可以从以下几种常用的视角来描述一个系统：•系统的使用实例：从系统外部的操作者的角度描述系统的功能。•系统的逻辑结构：描述系统内部的

静态结构和动态行为，即从内部描述如何设计实现系统功能。•系统的构成：描述系统由哪些程序构件所组成。•系统的并发性：描述系统的并发性，强调并发系统中存在的各种通信和同步问题。•系统的配置：描述系统的软件和

各种硬件设备之间的配置关系。标准建模语言UMLUML模型图（5类，10种）：•用例图•静态图（类图，对象图，包图）•行为图（状态图，活动图）•交互图（顺序图，合作图）•实现图（构件图，配置图）标准建模语言UMLUML

语义•元-元模型(Meta-metamodel)：建立元模型的基础体系结构，定义一种说明元模型的语言•元模型(Metamodel)：元-元模型的一个实例，定义一种描述模型的语言•模型(Model)：元模型的一个实例，定义一种语言来描述信息领域•用户对象(UserObjects)：模型的一个实例

，定义一个特定的信息领域标准建模语言UMLUML主要文件：•UML概要（UMLSummary）•UML语义（UMLSemantics）•UML表示法指南（UMLNotationGuide）•对象约束语言规约（ObjectCont

raintlanguageSpecification）：该文件定义并介绍了一种对象约束语言（OCL），其用途是用来说明在图形化的系统模型中不能充分表达的建模信息。它是一种形式化语言。http://www.rational.com/uml/index.jtmpl标准建模语言UML（用例

图）从本质上将，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用：•用例描述了用户提出的一些可见的需求；•用例可大可小；•用例对应一个具体的用户目标标准建模语言UML（用例图）用例图描述系统外部的执行者与系统的用例之间的某种联系。•所谓用例是指对系统提供的功能（或称系统的用途）的一种

描述；•执行者是那些可能使用这些用例的人或外部系统；•用例和执行者之间的联系描述了“谁使用哪个用例”。标准建模语言UML（用例图）•用例图着重于从系统外部执行者的角度来描述系统需要提供哪些功能，并且指明了这些功能的执行者是谁；•用例图在UML方法中

占有十分重要的地位，人们甚至称UML是一种用例图驱动的开发方法。标准建模语言UML（用例图）用例图中的图符：•用例•执行者•系统：用于界定系统功能范围，描述该系统功能的用例都置于其中，而描述外部实体的执行者都置于其外。•关联：连接执行者和用例，表示执行者所代表的系统外部实体与该用例

所描述的系统需求有关。标准建模语言UML（用例图）用例图中的图符：•使用：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能。•扩展：由用例A连向用例B，表示用例B描述了一项基本需求，而用例A

则描述了该基本需求的特殊情况。•注释体：对UML实体进行文字描述•注释连接：将注释体与要描述的实体连接，说明该注释体是针对该实体所进行的描述。«使用»«扩展»标准建模语言UML（用例图）设置边界风险分析交易估计进行交易超越边

界更新帐目评价贸易经理营销人员记帐系统销售人员«使用»«使用»«扩展»标准建模语言UML（用例图）用例模型的获取：•获取执行者•获取用例标准建模语言UML（用例图）获取执行者：•谁使用系统的主要功能（主要使用者）？•谁需要系统支持他们的日常工作？•谁来维护、管理系统使其能正常

工作（辅助使用者）？•系统需要控制哪些硬件？•系统需要与其他哪些系统交互？•对系统产生的结果感兴趣的是哪些人？