加入时间：　月光软件站
61条面向对象设计的经验原则
　　“你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。”&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& & ----------Arthur J.Riel
　　(1)所有数据都应该隐藏在所在的类的内部。&& 　　(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。&& 　　(3)尽量减少类的协议中的消息。&& 　　(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。&&& 　　(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。
&　　如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。 & 　　(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。&& 　　(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。&&& 　　(8)类应该只表示一个关键抽象。&　　包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 . & 　　(9)把相关的数据和行为集中放置。&　　设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。 & 　　(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。&　　朝着稳定的方向进行依赖. & 　　(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。&& 　　(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。&& 　　(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。&　　规划一个接口而不是实现一个接口。 & 　　(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。&& 　　(15)对包含太多互不沟通的行为的类多加小心。&　　这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。 & 　　(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。&& 　　(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。&& 　　(18)从你的设计中去除不需要的类。&　　一般来说，我们会把这个类降级成一个属性。 & 　　(19)去除系统外的类。&　　系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。& & 　　(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。&& 　　(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。&& 　　(22)尽量减少类的协作者的数量。&　　一个类用到的其他类的数目应当尽量少。& & 　　(23)尽量减少类和协作者之间传递的消息的数量。&&&&&&&&&(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。&& 　　(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。&& 　　(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。&& 　　(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。& 　　(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。&　　当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。& & 　　(29)让系统功能在窄而深的继承体系中垂直分布。& 　　(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。& 　　(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。& 　　(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。& 　　(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。& 　　(34)类必须知道它包含什么，但是不能知道谁包含它。& 　　(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。& 　　(36)继承只应被用来为特化层次结构建模。& 　　(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。& 　　(38)基类中的所有数据都应当是私有的，不要使用保护数据。&　　类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。& & 　　(39)在理论上，继承层次体系应当深一点，越深越好。& 　　(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。& 　　(41)所有的抽象类都应当是基类。& 　　(42)所有的基类都应当是抽象类。& 　　(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。& 　　(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。&& 　　(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。&& 　　(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。&& 　　(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。& 　　(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。&& 　　(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。& 　　(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。& 　　(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。&& 　　(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。& 　　(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。& 　　(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。& 　　(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。& 　　(56)只要在面向对象设计中用到了继承，问自己两个问题：&&&&&&&&&&&&&&&&(1)派生类是否是它继承的那个东西的一个特殊类型？&&&&&&&&&&&&&&&&(2)基类是不是派生类的一部分？& 　　(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。& 　　(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。& 　　(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。& 　　(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。&& 　　(61)不要绕开公共接口去修改对象的状态。摘自：
相关文章：相关软件：
┊┊┊┊┊┊┊┊┊┊┊
┊┊┊┊┊┊┊┊┊┊┊
┊┊┊┊┊┊┊┊┊┊┊谈软件工程中的面向对象软件设计-软件工程-论文联盟
您好，游客
背景颜色：
谈软件工程中的面向对象软件设计
作者：宋爱宁
谈软件工程中的面向对象软件设计
　摘要 本文软件从工程学习的角度,概括的阐述了面向对象软件设计的特点、步骤、原则等方面的内容。 　　关键词 面向对象;软件设计;OOD 　　中图分类号TP311.5 文献标识码A 文章编号 10)22-0220-02 　　 联盟　　The Object-oriented Software Design in Software Engineering 　　SONG Ailin 　　Abstract From the view of software engineering learning, this paper generally introduce the characteristics of object-oriented software design, and it&s steps and principles, etc. 　　Keywords Object-OSoftware DOOD 　　 　　随着20世纪80年代末面向对象技术的兴起,传统设计方法不能满足现代软件工程的需要,学习软件工程必须要重视面向对象的软件设计。 　　1 面向对象设计概述 　　面向对象(OO, Objected Oriented)方法是1979年以后起来的,它是一种系统的软件方。有学者认为面向对象技术与方法包括面向对象分析、面向对象设计、面向对象编程、面向对象测试和面向对象维护5个阶段。 　　面向对象设计(OOD, Objected Oriented Design)并不是指用一种具体去直接编写代码,而是建立在前期的面向对象分析建模基础上,主要考虑&如何实现&问题,焦点从问题空间转到解空间,着重完成各种不同层次的模块设计。但是有一点与传统设计有很大区别,面向对象设计和分析没有明显的分界线,二者采用相同的符号表示,它们往往反复迭代地进行。设计对分析模型进行调整并补充与实现有关的部分,形成面向对象设计模型。 　　2 面向对象设计过程 　　2.1 系统设计 　　系统设计确定实现系统的策略和目标系统的高层结构,要将系统分解为若干子系统,在定义和设计子系统时应使其具有良好的接口,通过接口和系统的其余部分通信。主要步骤有:划分子系统,确定需要并发运行的子系统并分配处理器,描述子系统之间的通信,确定系统资源的和控制,确定人机交互构件,选择实现数据管理和任务管理的基本策略。 　　2.2 对象设计 　　面向对象设计阶段是扩充、完善和细化对象模型的过程,设计类中的服务、实现服务的算法是面向对象设计的重要任务,还要设计类的关联、借口形式及进行设计的优化。一般步骤是:对象描述,设计类中的服务,设计类的关联,链属性的实现,设计的优化。 　　2.3领域对象设计 　　OOD阶段的一个重要内容是实现角度对领域模型做补充或修改。例如,增添、合并或分解类对象,调整继承关系等等。领域对象设计一般包括:调整需求,复用已有的组建,引入父类、分组管理领域类,增添一般化类以建立协议,调整OOA模型,设计复审。 　　3 面向对象设计的原则 　　3.1 单一职责原则 　　就一个类而言,应该仅有一个引起它的变化的原因。最有效类的职责简单而且集中,避免相同的职责分散到不同的类之中,避免一个类承担过多的职责减少类之间的耦合当需求变化时,只修改一个地方。 　　3.2 开放封闭原则 　　包含两个要点:一种可变性不应当散落在代码的很多角落里,而应当被封装到一个对象里面。同一种可变性的不同表象意味着同一个继承等级结构中的具体子类。换言之,指当需求改变时设计人员扩展模块增加新功能,而不需要改动原来的代码。 　　3.3 Liskov替换原则 LSP 　　LSP是主要针对继承的设计原则,所有派生类的行为功能必须和客户程序对其基类所期望的保持一致。简单的说,如果一个软件实体使用的是基类的话那么也一定适用于子类,但反过来的代换不成立。 　　3.4 依赖倒置原则DIP 　　IDP原则规定:1)高层模块不应依赖于底层模块,两者都应该依赖于抽象;2)抽象不应该依赖于细节,细节应该依赖于抽象。 　　3.5 接口隔离原则&&ISP 　　从客户的角度来说:一个类对另外一个类的依赖性应当是建立在最小的接口上的。如果客户端只需要某一些方法的话,那么就应当向客户端提供这些需要的方法,而不要提供不需要的方法。提供接口意味着向客户端承诺,过多的承诺会给系统的维护造成不必要的负担。 　　4 面向对象设计的软件 　　4.1 设计软件概述 　　20世纪80年代以来,出现了几十种支持软件开发的面向对象方法。其中,Booch, Coad/Yourdon、OMT和Jacobson的方法在面向对象软件开发界得到了广泛的认可。目前主要使用的是统一建模语言UML(Unified Modeling Language)进行建模,该方法结合了Booch、OMT和Jacobson方法 的优点,统一了符号体系,并从其它的方法和工程中吸收了许多经过实际检验 的概念和技术。UML1.1版本于1997年被OMG接纳确定为基于面向对象技术的标准建模语言。 　　4.2 具体的设计模型 　　第一,用例模型,它是从用户的角度描述系统需求。一般先将用例按优先级分类,再区分用例在体系结构方面的风险大小,最后对用例所需的量进行估算。第二,静态模型,它是描述系统的元素,即元素间的关系,定义了类、对象和它们之间的关系及组件模型,可以使用用例图、类图、包图、对象图、构件图、部
欢迎浏览更多 →
相关文章 & & &
本栏目最新更新文章
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款
内容分类导航【图文】软件工程面向对象分析_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
软件工程面向对象分析
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢等级：书童 |
热门搜索：、、、
您现在的位置：&&&&&&&&&&&&&&&&&&&&文章内容
快捷导航：
软件工程：实践者的研究方法第19章面向对象的概念和原则
来源：233网校&&&【233网校：教育考试门户】&&&日
已有574人加入
　　类似的方法可以用于在SafeHome中定义每个对象，在对当前确定的每个对象的属性和操作的定义完成后，就已创建完一个OOA的初始模型。更详细的对分析模型(作为OOA的一部分而被创建)的讨论在第20章。
19.4面向对象软件项目的管理
　　如我们在本书第二部分所讨论的那样，现代软件项目管理可以被分解为如下活动：
　　1.建立项目的公共过程框架。
　　2.使用框架和历史度量信息来进行工作量和时间估算。
　　3.规定工作产品和里程碑，以使得进展可以被测度。
　　4.定义用于质量保证和控制的检查点。
　　5.管理当项目进展中不时发生的变化。
　　6.跟踪、监控和控制项目进展。
　　从事面向对象项目的技术管理者运用这6项活动，但是由于面向对象软件的独特性质，这些管理活动每个均有微妙的不同并必须以不同的思路来加以运用。
　　在下面几节中，我们考察对面向对象项目的软件项目管理，管理的基本原则是相同的，但是必须采用适当的技术来有效地管理OO项目。
19.4.1OO的公共过程框架
　　公共过程框架common process framework(CPF)定义了组织的软件开发和维护途径，它标识了用于建造和维护软件的软件工程范型以及需要的任务、里程碑和可交付的产品。它确立了用于不同种类的项目开发的管理严格程度。
　　CPF总是可以进行适应性的修改，使得它可以满足每个项目组的需要，这是它最重要的特征。
　　对OO项目的有效的CPF不是线性的顺序模型。线性顺序模型，即广为所知的生命期或瀑布模型，假定在项目的开始定义要求，并且工程活动以线性顺序的模式进展。就其本身性质而言，面向对象软件工程必须应用鼓励递进发表的范型，即，OO软件通过一系列循环周期而演进。用于管理OO项目的公共过程框架必须本质上是演进的，在19.1节中给出了一个OO过程模型。
　　Ed Berard[BER93]和Grady Booch[BOO91]建议使用“递归/并行模型”来进行面向对象软件开发，在本质上，递归/并行模型以如下方式工作：?进行足够的分析以分离出主要的问题类和联系。
　　?进行少量的设计以确定类和联系是否可以用实际的方式实现。
　　?从库中提取可复用对象建造大致的原型。
　　?通过测试发现原型中的错误。
　　?获取客户对原型的反馈。
　　?基于从原型、少量设计和客户反馈学到的知识来修改分析模型。
　　?精化设计以适应你的修改。
　　?开发特殊的对象(从库中得不到的)。
　　?用来自库中的和你新创建的对象组装新的原型。
　　?进行测试以发现原型的错误。
　　?获取客户对原型的反馈。
　　该方法一直继续，直至原型发展为可用的产品。
　　递归/并行模型和本章前面讨论的OO过程模型是非常相似的，即项目递进地进展，但递归/并行模型在下面两点认识上不同：(1)对OO系统模型的分析和设计不能在相同的抽象层次上进行；(2)可以对系统中相互独立的构件同时进行分析和设计。
　　Berard[BER93]以如下方式描述该模型：
　　?将问题系统地分解为高度独立的构件。
　　?对每个独立构件进一步进行分解(此即递归部分)。
　　?对所有构件的分解工作同时进行(此即并行部分)。
　　?继续此过程直至完成。
　　必须注意，当分析员/设计者认识到所需的构件或子构件在复用库中存在时上面的分解过程即不再继续。
　　为了控制递归/并行过程框架，项目管理者必须认识到进展要被增量式地计划和测度，即，项目任务和项目进度同每个“高度独立的构件”紧密联系的，要针对每个构件进行独立的进度测量。
　　递归/并行过程的每次递进需要计划、工程(分析、设计、类提取、原型开发和测试)和评估活动(如图19-11所示)。在计划阶段，对每个和独立程序构件相关联的活动进行计划、制定进度(注：针对每次递进，要进行同本次迭代的变化相适应的进度安排的调整)；为了分离出OO分析和设计模型中的所有重要元素，在工程的早期阶段要迭代地进行分析和设计工作；随着工程工作不断开展，产生软件的增补版本；通过评估、复审、客户评价和针对每个增补的性能测试，得到反馈信息，这将影响下一次计划和随后的增补。
19.4.2面向对象项目的度量和估算
　　传统的软件项目的代码行(LOC)或功能点(FP)的估算作为项目估算的基本元素。对OO项目而言，一个非常重要的目标是复用，所以代码行估算的意义就不是很大，但FP估算可以被有效地应用，因为所需的信息域计数可很容易地从问题陈述中得到。虽然FP分析可以运用于OO项目估算，但是当我们进行递归/并行范型的迭代时，FP测度没有提供进度安排和工作量调整所需的足够的粒度。
　　Lorenz和Kidd[LOR94]建议了下面一组项目度量：
　　场景脚本的数量。场景脚本是描述用户和应用间交互的详细的步骤序列，每个脚本被组织为如下形式的三元组：
｛initiator，action， participant｝(｛发起者、动作、参与者｝)
　　这里initiator是请求某种服务的对象(它启动一个消息)；action是请求的结果； participant是满足请求的服务器对象。
　　场景脚本的数量同应用的大小和当系统完成时必须开发的测试用例的数量直接相关。
来源:233网校-责编:水自流&&&
6月8日 16:36
2013上半年软考成绩什么时候出来啊
5月27日 17:0
马上加入【软考帮帮团】啦，考后来讨论2013年5月期货从业资格考试《期货法律法规》试题和答...
5月23日 17:25
有考程序员的同学吗？大家交流交流哦~
5月16日 8:48
低价出售。。。
4月16日 16:0
根据《2013年度专业技术人员资格考试计划及有关问题的通知》得知，2013年上半年软考时间...
状态：进行中
状态：进行中
状态：进行中
状态：进行中
状态：进行中
文件类型：
文件类型：
文件类型：
文件类型：
文件类型：