第7章-面向对象设计要点

第7章面向对象设计•面向对象设计过程与准则面向对象设计过程面向对象设计准则•基于UML的面向对象设计过程系统构架设计用例设计类设计数据库设计用户界面设计7.1面向对象设计过程与准则•面向对象设计的主要任务是在面向对象分析的基础上完成体系结构设计、接口设计、数据设计、类设计及构件设计。•面向对象分析和设计的界限是模糊的，从面向对象分析到面向对象设计是一个逐渐扩充模型的过程。分析的结果通过细化直接生成设计结果，在设计过程中逐步加深对需求的理解，从而进一步完善需求分析的结果。•分析和设计活动是一个反复迭代的过程。7.1.1面向对象设计过程•面向对象设计过程(1)建立系统环境模型。在设计的初始阶段，系统设计师用系统环境图对软件与外部实体交互的方式进行建模。下图给出了系统环境图的一般的结构。(2)设计系统体系结构。体系结构设计可以自底向上进行，如将关系紧密的对象组织成子系统或层；也可以自顶向下进行，尤其是使用设计模式或遗产系统时，会从子系统的划分入手。(3)对各个子系统进行设计。对于面向对象的系统，典型的子系统有问题域子系统、人机交互子系统和任务管理子系统。(4)对象设计及优化。7.1.1面向对象设计过程7.1.2面向对象设计准则•面向对象设计准则(1)模块化传统的面向过程方法中的模块通常是函数、过程及子程序等，而面向对象方法中的模块则是类、对象、接口、构件等。在面向过程的方法中，数据及在数据上的处理是分离的；而在面向对象方法中，数据及其上的处理是封装在一起的，具有更好的独立性，也能够更好地支持复用。7.1.2面向对象设计准则(2)抽象面向对象方法不仅支持过程抽象，而且支持数据抽象。类实际上就是一种抽象数据类型。可以将类的抽象分为规格说明抽象及参数化抽象:类对外开放的公共接口构成了类的规格说明，即协议。这种接口规定了外部可以使用的服务，使用者无需知道这些服务的具体实现算法。通常将这类抽象称为规格说明抽象。参数化抽象是指当描述类的规格说明时并不具体指定所要操作的数据类型，而是将数据类型作为参数。7.1.2面向对象设计准则(3)信息隐藏在面向对象方法中，信息隐藏通过对象的封装性实现。对于类的用户来说，属性的表示方法和操作的实现算法都应该是隐藏的。(4)弱耦合在面向对象设计中，耦合主要指不同对象之间相互关联的程度。如果一个对象过多地依赖于其它对象来完成自己的工作，则不仅使该对象的可理解性下降，而且还会增加测试、修改的难度，同时降低了类的可重用性和可移植性。对象不可能是完全孤立的，当两个对象必须相互联系时，应该通过类的公共接口实现耦合，不应该依赖于类的具体实现细节。7.1.2面向对象设计准则(5)强内聚设计类的原则是一个类的属性和操作全部都是完成某个任务所必须的，其中不包括无用的属性和操作。例如设计一个平衡二叉树类，该类的目的就是要解决平衡二叉树的访问，其中所有的属性和操作都与解决这个问题相关，其他无关的属性和操作在这里都是垃圾，应该清除。7.1.2面向对象设计准则(6)可重用•软件重用是提高软件开发生产率和目标系统质量的重要途径。•重用基本上从设计阶段开始。重用有两方面的含义：一是尽量使用已有的类(包括开发环境提供的类库，及以往开发类似系统时创建的类)；二是如果确实需要创建新类，则在设计这些新类的协议时，应该考虑将来的可重复使用性。7.2基于UML的面向对象设计过程•面向对象的系统设计主要活动是进行系统分解，并在此基础上定义子系统/构件之间的接口。为此，首先根据子系统可提供的服务来定义子系统，然后对子系统细化，建立层次结构。要求对子系统的分解尽可能做到高内聚、低耦合。7.2.1相关概念•子系统和类在大型和复杂的软件系统情形，首先根据需求的功能模型（用例模型），将系统分解成若干个部分，每一部分又可分解为若干子系统或类，每个子系统还可以由更小的子系统或类组成，如图所示。系统结构的类图7.2.1相关概念•服务和子系统接口子系统分层的目的是建立系统的层次结构。每一层仅依赖于它下一层提供的服务，而对它的上一层可以一无所知。下图给出了一个三层的系统结构的示例。7.2.1相关概念•服务和子系统接口如果在一个系统的层次结构中，每一层只能访问与其相邻的下一层，则称之为封闭体系结构；如果每一层还可访问比其相邻下一层更低的层次，则称之为开放体系结构。典型的封闭体系结构的例子就是开放系统互联参考模型（OSI模型），如图所示。7.2.1相关概念•服务和子系统接口开放体系结构的一个例子是Java的Swing用户接口包。它允许绕过高层直接访问低层接口以克服性能瓶颈。如图所示。7.2.2基于UML的面向对象设计过程•系统构架设计•用例设计•类设计•数据库设计•用户界面设计7.2.2.1构架设计•构架设计的目的是要勾画出系统的总体结构，这项工作由经验丰富的构架设计师主持完成。•该活动以用例模型、对象模型为输入。•输出：物理结构、子系统及其接口、概要的设计类。系统构架设计类用例模型补充需求分析模型构架描述构架设计子系统概要接口分析模型的说明设计模型和实施模型构架工程师7.2.2.1构架设计•第1步：构造系统的物理模型•首先用UML的配置图描述系统的物理构架•将需求分析阶段捕获的系统功能分配到这些物理节点上。•配置图上可以显示计算节点的拓扑结构、硬件设备配置、通信路径、各个节点上运行的系统软件配置、应用软件配置。•一个图书馆信息管理系统的物理模型如图示7.2.2.1构架设计联想A3000数据库服务器联想A2000WEB应用服务器借阅部PC数据库办公室PC采编部PC借还书预订/查询收费管理图书信息加工处罚交换机CiscoC2924M-XLSonicwall防火墙路由器远程读者PC机**《TCP/IP》《TCP/IP》《TCP/IP》图书查询图书预订图书查询图书预订……内部用户1内部用户2内部用户N交换机Cisco24M单位内部用户图书馆内部用户7.2.2.1构架设计•配置图中–考虑到图书馆内部用户如果也通过互联网使用系统，效率会受影响。–这个系统中设计了三种访问模式：一种是远程读者，通过Internet访问系统，实现查询图书、预借图书的功能；第二种是本单位其他部门的读者，通过单位局域网查询、预借图书；第三种是图书馆内部工作人员，在局域网上完成日常的借还书、采编、图书管理等工作。7.2.2.1构架设计第2步设计子系统•第2步：设计子系统•这步的主要任务是：划分各个子系统，定义各个子系统的接口，说明子系统之间的关系。•对于一个复杂的软件系统来说，将其分解成若干个子系统，子系统内还可以继续划分子系统或包，这种自顶向下、逐步细化的组织结构非常符合人类分析问题的思路。每个子系统与其它子系统之间应该定义接口，在接口上说明交互信息，注意这时还不要描述子系统的内部实现。•1）划分各个子系统•划分各个子系统的方式:按照功能划分，将相似的功能组织在一个子系统中;按照系统的物理布局划分，将在同一个物理区域内的软件组织为一个子系统;按照软件层次划分子系统，软件层次通常可划分为用户界面层、专用软件层、通用软件层、中间层和数据层，具体的表达方式见图7.2.2.1构架设计数据层中间件层通用软件层专用软件层数据库事务处理通用查询操作权限分配图书查询借书用户界面层图书查询界面借书界面还书界面……还书7.2.2.1构架设计•用户界面层是与用户应用有密切关系的内容，主要接受用户的输入信息，并且将系统的处理结果显示给用户。这部分变化通常比较大，所以建议将界面层剥离出来，用一些快捷有效的工具实现。7.2.2.1构架设计•专用软件层是每个项目中特殊的应用部分，它们被复用的可能性很小。在开发时可以适当地减小软件元素的粒度，以便分离出更多的可复用构件，减少专用软件层的规模。7.2.2.1构架设计•通用软件层是由一些公共构件组成，这类软构件的可复用性很好。在设计应用软件时首先要将软件的特殊部分和通用部分分离，根据通用部分的功能检查现有的构件库。如果有可用的构件，则复用已有的构件会极大地提高软件的开发效率和质量。如果没有可复用的构件，则尽可能设计可复用的构件并且添加到构件库中，以备今后复用。7.2.2.1构架设计•数据层主要存放应用系统的数据，通常由数据库管理系统管理，常用的操作有更新、保存、删除、检索等。7.2.2.1构架设计在图书馆图书信息管理系统层次划分：•系统层采用微软的Windows操作系统和SQLServer数据库。•数据层主要是建立应用数据库，包括数据库表、视图等。•中间层使用微软的ADO.NET，实现对数据库的插入、修改、删除的事务处理。•通用软件层实现权限管理、用户登录、通用查询类。•专用软件层实现读者查询、借书、还书、处罚、预订、通知等处理。•界面层实现查询界面、借书界面、还书界面、预订界面、通知界面等用户界面。7.2.2.1构架设计2）定义子系统之间的关系：•划分子系统后，要确定子系统之间的关系。子系统之间的关系：–“请求－服务”关系，“请求”子系统调用“服务”子系统，“服务”子系统完成一些服务，并且将结果返回给“请求”子系统。–平等关系，每个子系统都可以调用其它子系统。–如果子系统的内容相互有关联，就应该定义它们之间的依赖关系。在设计时，相关的子系统之间应该定义接口，依赖关系应该指向接口而不要指向子系统的内容。7.2.2.1构架设计•注意：如果两个子系统之间的关系过于密切，则说明一个子系统的变化会导致另一个子系统变化，这种子系统理解和维护都会比较困难。•解决子系统之间关系过于密切的办法基本上有两个：–重新划分子系统，这种方法比较简单，将子系统的粒度减少，或者重新规划子系统的内容，将相互依赖的元素划归到同一个子系统之中；–定义子系统的接口，将依赖关系定义到接口上;7.2.2.1构架设计3）定义子系统的接口。每个子系统的接口上定义了若干操作，体现了子系统的功能，而功能的具体实现方法应该是隐藏的，其他子系统只能通过接口间接地享受这个子系统提供的服务，不能直接操作它。7.2.2.1构架设计•第3步：非功能需求设计•分析阶段定义了整个系统的非功能需求，在设计阶段要研究这些需求，设计出可行的方案。非功能需求包括：–系统的安全性，错误监测和故障恢复，可移植性和通用性等等。•具有共性的非功能需求一般设计在中间层和通用应用层，目的是充分利用已有构件，减少重新开发的工作量。7.2.2.1构架设计7.2.2.2用例设计•根据分析阶段产生的高层类图和交互图，由用例设计师研究已有的类，将它们分配到相应的用例中。•检查每个用例功能，依靠当前的类能否实现，同时检查每个用例的特殊需求是否有合适的类来实现。•同时细化每个用例的类图，描述实现用例的类及其类之间的相互关系，其中的通用类和关键类可用粗线框区分，这些类将作为项目经理检查项目时的重点。•第1步：通过扫描用例中所有的交互图识别参与用例解决方案的类。•每个类的方法都可以通过分析交互图得到，一般地检查所有的交互图发送给某个类的所有消息，这表明了该类必须定义的方法。例如“借书控制”类向“读者”类发送“检查读者（读者编号）”消息，那么“检查读者”就作为“读者”类应该提供的方法。•第2步：添加类之间的关系，包括关联、依赖、继承。7.2.2.2用例设计7.2.2.3类设计：类的设计步骤•由构件工程师详细设计每个类的属性、方法和关系。•第1步定义类的属性。类的属性反映类的特性，通常属性是被封装在类的内部，不允许外部对象访问。•1）分析阶段和概要设计阶段定义的一个类属性在详细设计时可能要被分解为多个，减小属性的表示粒度有利于实现和复用。但是一个类的属性如果太多，则应该检查一下，看能否分离出一个新的类。•2）如果一个类因为其属性的原因变得复杂而难于理解，那么就将一些属性分离出来形成一个新的类。•3）通常不同的编程语言提供的数据类型有很大差别，确定类的属性时要用编程语言来约束可用的属性类型。定义属性类型时尽可能使用已有的基础类型，太多的自定义类型会降低系统的可维护性和可理解性等性能指标。•4）类的属性结构要坚持简单的原则，尽可能不使用复杂的数