面向对象讲义参考

面向对象开发培训参考讲义一.软件架构的组织原则:软件本质:我们的世界是模糊的、连续的、不精确的，但软件是精确的、离散的、形式化的，这就注定软件不能完全描述现实世界。所以我们要知道描述那些部分，忽略那些部分，这就是软件的本质问题。VRAPS模型（构想，节奏，预见，协作，简化）构架:为我们提供了整个系统的清晰的视角，对控制系统的开发是必要的。软件系统是一个单一的实体，但从不同视觉展示系统有助于更好的理解设计，这些视角被解释为系统的模型视图，视图合在一起构成了构架架构描述:用况模型视图，分析模型视图，设计模型视图实施模型视图实现模型视图测试模型视图对描述构架不起作用，他只是用来验证构架基线二.面向对象分析设计开发面向对象的分析是按照概念（对象）对软件问题进行分解，而不是像结构化分析哪样是按照功能对软件问题进行分解的。系统分析:理解并详细说明信息系统应该做什么的过程识别出问题域中不同概念并用概念模型将其存档系统设计:详细说明信息系统的许多特性在物理上是怎样实施的过程。面向对象的目标是开发能够反映现实世界某个特定片段的软件（或模型）.对象:a•定义为某一事物，即是可以看到、摸到或感觉到的一种实体。在计算机面向对象技术中，对象是系统的基本成分，是具有特殊属性（数据）和行为方式（方法）的实体.它应有唯一的名称，有表示对象行为的一组公共与私有操作。=（ID,DS,MS,MI）ID:标识或对象名DS:对象的数据结构MS:操作集MI:对外接口类:一个类描述了属于该类型的所有对象的性质，包括外部特征和内部实现。共享相似特性和行为的对象的集合。对象是某个类的一个元素。=（ID,INH,DD,OI,ITF）ID:标识或类名INH:类继承性描述DD:数据结构描述OI:操作集合描述ITF:对外接口类的属性:抽象：过滤掉对象的一部分特性和操作直到只剩下你所需的操作和属性，继承：对象继承了所属类的属性和操作，类同样也可以继承其他类的属性和操作。如何发现类之间的继承关系?在初始模型中，在类列表中找出两个或多个具有相同属性和操作的类，其中一个类有可能就是其它类的父类，或者可为这些类新建一个父类。子类型有额外的重要的属性，子类型有额外的重要的关联子类型以不同于父类型或其它子类型的重要方式被操作，操纵，反应或处理子类型描述的事物与超类型或其它子类型的行为方式不同多态:不同的类中可以有相同名称的操作且这个操作在每个类中都能以各自不同的方式执行，因此必须清楚这些同名操作之间的重要区别。封装:当一个对象执行自己的操作时，它对外界隐藏操作的细节，持久化框架:是一种可重用的，且通常可被扩展的类的集合，他可向持久化对象提供服务。如：存储数据时将对象转换成记录，在取回数据时需将记录转换成对象。消息传递：对象通过相互之间的消息传递协同工作关联:a在物理上或逻辑上是b的一部分a物理上或逻辑上依赖于ba被记录在b中管理原则:1．需要知道型关联：需要将概念之间的关系信息记忆一段时间的关联2．概念比关联重要3．太多关联使概念模型混乱4．避免关联之间的信息冗余以及减少派生关联聚集接口:是描述类的部分行为的一组操作，他也是一个类提供给另一个类的一组操作获取需求的基本原则:1.深入浅出以流程为主线获取需求的重点:1.平均频度:业务发生的频繁程度（即单位时间内发生的次数）频度越高，数据量就越大，对响应时间、易操作性等要求越高，在数据存储需充分考虑高峰期的频度:只有掌握此数据，在后面系统测试时，需要模拟高峰期的业务频度3.看单据::有那些数据，每页数据精度，计算生成方法，取值范围限定单击内容是进行数据结构设计的最基本依据取值范围与计算方法是数据完整性检测的依据4.生成单据或报表的时间（手工）:花费时间多，处理方法复杂的地方通常是最关键的地方，也是用户验收关心的地方，通常也是用户没有足够人力与时间处理才想到用计算机的地方5.单据或报表的来源:单据联数，每联用途，送交单位，送交时间6.有那些特殊情况，在某个作业环节出错时通过何种途径弥补：分析员可采用穷举的方法，假定每一个环节都出现失误，逐环节询问用户的处理方法，防止遗漏7.将来有何变化获得类的过程:让分析员使用客户所采用的术语和用户交流，可促使客户说出问题的细节。在谈话过程中应不时停下来作总结，测试一下你对问题的理解，熟悉和使用领域术语，并尽量使谈话气氛保持轻松愉快对不熟悉的领域术语，务必让对方解释清除。不必担心对方觉得你无知，谈话的目的是获得知识，学习领域术语。需经常从前面的回答中辨别新问题，集中注意力听对方对每个问题的解答，业务逻辑通常包含在对方对问题的解答中遇到业务逻辑时要作记录，还要整理和维护好这些记录以后可能用到若觉得业务过程某些部分过于复杂，应当暂时将其搁置，日后单独讨论。每个业务过程复杂度不宜过高，以容易绘制成模型图为宜。绘制出模型图的清晰性要比模型的复杂性更重要。征求被访者对活动图的反馈意见，根据对方意见修改活动图分析类的基本构造型:1.边界类:用于建立系统与其参与者（用户和外部系统）之间交互的模型，:通常把用户界面或通信接口变化隔离在一个或多个边界类中2.实体类：用于长效且持久的信息建模，实体类主要对诸如个体、实际对象或实际事物的某些现象或概念信息及相关行为建模。3.控制类：代表协调、排序、事务处理以及对其它对象的控制，经常用于封装与某个集体用况有关的控制，也可用于表示复杂的派生和演算识别概念策略:使用概念目录列表找出概念:物理的或实在的对象规格说明，设计或事物的描述地点，事务，人的角色，组织，事件，规则，策略，手册，书籍根据名词性短语找出概念:弱点在于自然语言的不准确性,如:班组，工区概念、属性区分:若概念在现实世界不仅仅是一些简单的数字或文字，那么最好将其作概念处理，而不是作为属性处理.类潜在的两组属性:传统的将之视为关系表中属性的属性：如:姓名,编号是客户全视之为类属性的属性:如：线杆的瓷瓶一个类可以有多个与之关联的属性，具有大量数据的类是不良的设计，比较好的设计是类具有50或更少的属性识别职责:知道型职责:知道自己私有的封装的数据，知道自己相关联的对象信息，知道自己派生出来或计算出来的事物做型职责：自己完成某件任务，发起其它对象执行动作，控制和协调其它对象内的活动。面向对象设计要点:为实际工作设计理解要实现的东西需求的重要性在现有任务中应用多个模型用例的重要性用力可大可小，但必须是对一个具体的用户目标实现的完整描述文档的重要性证明软件的设计在实践中是可行的应用已知的模式类的内聚性：一个类应有且仅有一个职责，否则可能由于多个不同原因引起该类发生变化充分考虑软件的可移植性：当使用os的特性，或利用某db专用语言写了存储过程，应将这些特性的实现细节封装在一个类中建立对象数据辞典：便于内部重用和共享，应建立电子化对象数据辞典，以便对象统一归类管理12.对接口编程:是面向对象设计的基本原则之一。对于所有完成相同功能的组件，应抽象出一个接口，他们都实现该接口。好的接口设计原则:隐藏实现细节只提供必要的功能不要对外部代码施加影响保持接口风格统一在同一层分配和释放资源在较低层检测错误，在较高层处理错误13.类的最高层是抽象类:在许多情况下，提供一个抽象类有利于做特性化扩展，抽象类的层次越高，代码就越有弹性，越容易适应变化.优先使用对象组合，而不是类继承：有助于保持每个类被封装，并且具有更多的灵活性增加参数的可读性尽量减少对变量的直接访问：对数据的封装原则应该规范化，不要把一个类的属性暴露给其它类，而是应通过访问方法去保护他们，这有利于避免波纹效应，若某个属性的名字改变，只需修改它的访问方法，而不是修改所有相关代码。面向对象的设计原则:单一职责原则:对于一个类而言，应该仅有一个引起它变化的原因，变化的轴线仅当变化实际发生时才具有真正的意义，否则应用它是不明智的b.开发－封闭原则:对于扩展是开放的（我们可以改变模块的功能）对于更改是封闭的（扩展时，无需改动源码或二进制代码）一般而言，无论模块多么封闭，都会存在一些无法封闭的变化，没有对于所有情况都贴切的模型设计人员必须对于他设计的模块应该对哪些变化封闭作出选择，他们必须先猜测出最有可能发生的变化种类，然后构造抽象类来隔离那些变化对于应用程序中每个部分都进行抽象不是一个好注意，正确的做法是，开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象，拒绝不成熟的抽象和抽象本身一样重要长方形，正方形是非is—a的，ood中is—a关系是就行为方式而言的liskov替换原则:子类型必须能够替换掉他们的基类型在重新声明派生类中的例程时，只能使用相等或者更弱的前置条件来替换原始的前置条件，只能用相等或者更强的后置条件来替换原始的后置条件.（例：传入％或具体单位值获得单位统计，只传单位）依赖倒置原则:高层模块不应该依赖于底层模块，二者都应该依赖于抽象抽象不应该依赖于细节，细节应该依赖于抽象接口隔离原则:不应该强迫客户依赖于他们不用的方法包的设计原则:内聚性原则重用发布等价原则不希望用户发现包中包含的类中，一些是他需要的，另一些他却完全不适

共同重用原则:一个包中的所有类应该是共同重用的，如果重用了包中的一个类，那么就要重用包中的所有类共同封闭原则:包中的所有类对于同一类性质的变化应该是共同封闭的，一个变化若对一个包产生影响，则对该包中的所有类产生影响，而对于其它的包不造成任何影响耦合性原则:无环依赖原则:若依赖关系图中存在环，就很难确定包创建的顺序解除环:使用依赖倒置原则创建新包，将两包依赖的类放置其中自顶向下设计稳定依赖原则:朝着稳定的方向进行依赖软件分层设计:界面层，业务逻辑层，数据接口层，数据层优点:良好的透明和封装，高内聚，低耦合，易于扩展，维护和重用，开发人员易于分工，提高开发效率缺点:效率降低，开发难度增大面向对象的数据库设计:一般编程设计有两种属性主导型:从归纳数据库应用的属性出发，在归并属性集合（实体）时，维持属性间的函数依赖关系实体主导型:先从寻找对数据库应用有意义的实体出发，然后定义属性来完善实体一般认为现实世界实体数量在属性1/10以下时，宜使用实体主导型设计方法面向对象的数据库设计从对象模型出发，属于实体主导型设计设计步骤:设计应用系统结构b.选择便于应用程序与dbms结合的dbms体系结构根据应用程序使用的环境平台，选择适宜的dbms和开发工具设计数据库，编写定义数据库模式的sql程序编写用户接口应用程序，录入数据注：此顺序不是瀑布模型，每一步可以反馈应用对象模型与rdbms模型的映射：a.RDBMS是以二维表为基本管理单元的，对象模型要由二维表及表间关系描述，对象模型向数据库概念模型的映射就是向数据库表的变换过程:一个对象类可以映射一个以上的库表，当类间有一对多的关系时，一a.个类也可对应多个类关系映射：一般映射为一个表单一继承泛化关系可对超类、子类分别映射表，也可让子类表拥有父类属性，也可让父类表拥有子类表属性对库表进行冗余控制调整，使之满足合理的关系范式三.敏捷软件开发:参考，慎用，不是最合理的软件方法个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划虽然右项也具有价值，但左项具有更大的价值martin文档第一定律:直到迫切需要并且意义重大时，才编制文档敏捷软件开发原则:我们优先要做的就是尽快的、持续的交付有价值的软件使客户满意初期交付的系统中包含的功能越少，最终交付的系统的质量就越高即使到了开发后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的间隔越短越好在整个开发期间，业务人员和开发人员必须在一起工作围绕被激励起来的个人来创建项目，给他们提供所需要的环境和支持，并且信任他们能够完成工作在团队内部，最具有效果且富有效率的传递信息的方法，就是面对面的交谈能工作的软件是首要的进度衡量标准敏捷软件开发过程提倡可持续的开发速度，责任人、开发者、用户应该能够保持一个长期的、恒定的开发速度（10盖女人不可能在一个月内生出小孩）不断的关注优秀的技能和好的设计会增强敏捷能力简单:使未完成的工作最大化的艺术，是根本的最好的构架，需求和设计出自于自组织的团队每隔一段时间，团队会在如何才能有效地工作方面进行反省，然后相应地对自己地行为进行调整注意事项:客户作为团队成员:当确实无法和客户工作在一起时，建议寻找能够在一起工作、愿意并能够代替真正客户地人结队编程:所有地产品代码都是由结队的程序员使用一台电脑共同完成的。结队成员中的一位控制键盘并输入代码，另一位观察输入的代码中的错误和可以改进的地方。结队的关系每天至少要改变一次，以便于每个程序员在一天中可以在两个不同的结队中工作.集体所有权:结队编程中的每一对都有拆出任何模块并对它进行改进的权利持续集成:程序员每天会多次拆入他们的代码并进行集成，规则很简单（第一个拆入的只要完成拆入即可，所有其它的人负责代码的合并工作）可持续的开发速度:不允许团队加班工作，在版本发布前的一个星期是该规则的唯一例外，若发布目标就在眼前且一蹴而就，则允许加班开发的工作空间:密歇根大学研究:在充满积极讨论的屋子里工作，生产率会成倍的提高计划游戏:本质是划分业务人员和开发人员之间的职责（业务人员和客户决定特性的重要性，开发人员决定实现一个特性所花费的代价）简单的设计:考虑能够工作的最简单的事情你将不需要它:只有在有证据，或者至少有十分明显的迹像表明现在引入这些基础结构比继续等待更加合算时，团队才会引入这些基础结构一次，并且只有一次不允许容忍重复的代码，无论哪里出现重复的代码，他们都会消除它们.（例外：性能差别很大时）消除重复最好的方法就是抽象，进一步减少代码间的耦合重构:是持续进行的，是我们每隔一个小时或者半个小时就要去做的事情。通过重构，我们可以持续地保持尽可能干净、简单且具有表现力的代码敏捷开发人员对待软件设计地态度和外科医生对待消毒地过程的态度是一样的:设计的臭味：a.僵化性:很难对系统进行改动脆弱性：对系统的改动会对系统中和改动地方在概念上无关的很多地方出现问题牢固性:很难解开系统的纠结粘滞性：做正确的事情比做错误的事情要困难不必要的复杂性f.晦涩性：不必要的重复

四.UML:每一种UML图都为你提供一种组成特殊视图的方式，采用多视点的目标是为了满足每一类风险承担人的需要。静态模型描述系统的结构特性动态模型描述系统的行为特性。类提供了系统的部分静态视图，描述的是系统的内部构成。用例提供了系统动态的行为视图，说明的是从外部看到的系统。类图:展示系统或者领域中的实体以及实体之间的关联关联:类之间的连接关联上的约束:关联上的约束or（或）约束关联类:关联有自己的属性和操作时，关联实际上是一个类继承与泛化（UML中称为泛化）：类a具有类b的所有特征，类a不同于类b,则类a继承类b子类型必须符合以下两个规则100％规则:超类型定义应该100％的可以被应用于子类型。子类型必须100％的符合超类型的属性和关联。Is-a规则:所有子类型集合的成员必须是它们的超类型集合的成员依赖:一个类使用了另一个类，这种关系叫做依赖-端11类5类6-特性1--端11类5类6-特性1-端5{0R}-端*-特性1+操作1+操作1（）1 5-端3-端411 -端9端10 1..*AssociationClassl-特性1+操作1()建立设计类图:通过分析交互图，识别出所有参与软件解决方案的类将它们在一个类图中绘出复制概念模型中的相关概念的属性到类图的类中通过分析交互图来为类图中的类添加方法为属性和方法添加类型信息在类图中添加关联，以支持必要的类之间的可见性在关联上添加导航箭头，来指明属性可见性的方向添加依赖关系连线，来指明非属性的可见性一个类的职责：就是该类在所有用况实现中所充当的汇集，将角色集中起来并去掉其中重叠的部分，就可得到该类的所有职责和属性的规格说明。用例图:一种用以显示不同的用户角色和这些用户角色如何使用系统的图用例分析的一个重要方面，是揭示出组成系统的构件。用例:由系统为使用该系统的用户完成的一个单一用途或功能从用户的观点对系统行为的一个描述。是能够帮助分析员和用户确定系统使用情况的UML组件。是系统的一组场景。每个用例图都有其自身的页，每个用例中的场景描述通常也至少占一页：每个用例的背后都隐藏一张顺序图.高层用例：是非常简洁的，通常是一个过程三两句话的描述用况名称：参与者：参与者列表，并注明用况发起者类型：a.主要，次要，可供选择的b.基本的，真实的主要:主要的过程；次要：不重要的或不常见的过程；可供选择：可以处理也可不处理的过程；基本：用一个完整格式表达，但很少涉及用况实现细节；真实：能具体描述用况过程的真实细节，以及具体的输入输出技术。描述：扩展用例：是描述一个过程的长篇叙述，可能含几百句话的描述。用况：参与者：目的：概述：类型：交叉引用：相关的用况或系统功能典型的事件发生过程：可供选择的事件发生过程：文档中描述的内容:发起用例的参与者用例的前置条件场景中的步骤场景完成后的后置条件从用例中获益的参与者。包含用例：《include》早期称使用(use)用例用例的重用技术扩展用例：《extends》对原用例的扩展技术参与者：系统用户扮演的一个角色是系统外部的一个实体，它以某种方式参与用况的执行过程。种类：人担当的角色，计算机系统，机械或电子设备场景：在用例中活动的一个特定顺序；一个用例可能有多个不同的场景.每个序列是由一个人，另一系统、一个硬件设备或某段时间的流逝发起的。系统边界：硬件设备或者计算机系统的硬件或软件边界一个组织中的部门整个组织定义系统边界的目的是为了能够识别出什么在系统之内及什么在系统之外，进

永1**永2永3主角1系统名-端2-端永1**永2永3主角1系统名-端2-端1ds〉〉<<extenses〉〉用况用况名：参与者：目的：概述：类型：交叉引用：典型的事件发生过程：参与者的动作 系统响应可供选择的过程用况的使用要依赖于至少部分地理解了系统需求，并用需求规格说明文档很好地表达出了这些需求。用况展示和体现出了其描述地过程中的需求情况。用况常见错误:把用况当成单独的步骤、操作或事务。用况是相对较大的由起点到终点的过程的描述。用况模型必须满足:是否已将所有必需的功能性需求捕获为用况每个用况的动作序列是否正确、完整、易于理解是否已经确定了一些价值很少或根本没有价值的用况，若有则应重新考虑这些用况识别用况的步骤:基于参与者的方法识别与系统或组织有关的参与者对每个参与者，识别出他们发起或参加的执行过程基于事件的方法识别出系统必须响应的外部事件把事件与参与者联系起来识别用况的准则:有价值的结果:每个可成功执行的用况都应对参与者提供某些价值。此准则应针对最初的参与者，有助于避免确定太小的用况具体的参与者:通过确定向真正的用户提供有价值的用况，可以确保用况不会太大用况的优点:用况着眼于为用户增加价值，提供一种捕获功能需求的系统而且直接的方法用况可驱动整个开发过程，因为大部分活动如分析、设计、测试都是

从用况开始执行的。交互图:能够展示出类模型中实例之间的消息交互，UML中定义了两种交互图：顺序图，协作图顺序图强调的是交互的时间顺序，按照时间顺序布图协作图强调的是交互的语境和参与的对象的整体组织。协作图按照空间组织布图协作图:使用图表或者网格展示了对象之间的交互它是一种用以显示对象如何被协调在一起以执行用例的图.协作图消息1消息1类1 ►顺序图:一种用以显示用例对象之间消息顺序的图，采用一种类似于围栏的格式展示对象之间的交互。生命线:在顺序图的一个对象下面的竖线，用以显示这个对象的时间阶段.消息:用例内部的对象之间的通信激活：顺序图消息激活：顺序图消息1消息2I"■_消息3状态图:一种用以显示对象在生命周期和转换期情况的图。只是对单个对象建立模型。描述了一个对象所处的可能状态以及状态之间的转移并给出了状态变化序列的起点和终点。信号:在接收对象的状态图中，能够触发一个状态转移的消息子状态:状态处在单个状态之中，称之为子状态。顺序子状态，并发子状态

活动图::展示出对象执行某种