搜索
面向对象分析设计Object-OrientedAnalysis&Design谭火彬第09章面向对象的设计（构件设计）Object-OrientedDesign—DesignComponents-3-学习路线图OOUMLOOPDP…Case-Study…学习路线图::……………………12345678910-4-关于构件设计任务基于“构架分析”和“用例分析”的框架，利用“构架设计”提供的素材，在不同的局部，将分析的结果用“设计元素”加以“替换”和“实现”主要活动实现需求场景(用例设计)实现子系统接口(子系统设计)明确类的实现细节(类设计)-5-内容安排用例设计子系统设计类设计数据库设计-6-内容安排用例设计子系统设计类设计数据库设计-7-用例设计用例设计(Use-CaseDesign)目标利用交互图改进用例实现改进对设计类的操作需求改进对子系统和它们的接口的操作需求输入用例实现(分析)设计元素输出用例实现(设计)-8-用例设计步骤将设计应用于用例1.结合设计元素，定义设计对象间的交互2.利用子系统简化交互图3.描述与持久化相关的行为4.改进用例实现的事件流5.评价类和子系统-9-1.应用交互图：职责分配利用设计元素，进行类的职责分配，完成用例实现的交互图需要遵循相关的设计原则和模式职责分配模式：GRASP模式信息专家、创建者、高内聚、低耦合、控制者、多态、纯虚构、中介、受保护变化单一类职责原则(SRP)保持类职责的单一性，设计高内聚的类-10-用例分析与用例设计用例分析与用例设计的差别表现在类的职责和操作的差别用例分析阶段定义类的初步职责用例设计阶段则需要定义具体的操作来实现这些职责发送到设计类的消息，对应该类的操作发送到子系统的消息，对应其接口的操作分析中主要的业务职责集中在控制类中，因此设计的重点就是控制类职责的实现臃肿的控制器（BloatedControllers）-11-臃肿的控制器臃肿的控制器：低内聚、缺乏重点并且处理过多的职责区；即违背面向对象设计的相关原则：高内聚、低耦合SRP解决方案加入更多的控制器（更多的分层）将部分职责委托给其它对象-12-用例设计-改进用例实现步骤确定参与用例流的每个对象用设计元素取代分析类在交互图中描绘每一个参与对象遵循相应的设计原则和模式，利用交互图完成职责分配过程递增地并入可适用的构架机制引入所需的设计机制(设计模式)，调整和完善交互图-13-在交互图中表示子系统接口代表任何实现该接口的模型元素不能发出任何消息代理类为每个子系统定义一个代理类，代表特定的子系统可以发送和接收消息×√-14-实例：引入子系统接口-15-实例：引入子系统接口之前(分析)-16-实例：引入子系统接口之后(设计)-17-实例：引入子系统接口(VOPC)-18-使用构架机制在用例分析过程中确定了预约挂号控制类AppointRegisterServlet运行分布机制在构架设计过程中决定采用Servlet技术来实现Web访问在用例设计过程中运用该机制来实现分布访问-19-实例：引入Servlet机制后VOPC-20-引入Servlet机制后交互图(片断)-21-2.利用子系统封装交互交互可以在几个级别进行描述子系统交互可以在其自己的交互图内部描述利用子系统提高抽象的级别-22-何时将子流封装为子系统封装一个子流为子系统，当该子流：出现在多个用例实现中有潜在的重用性复杂却容易封装是一个人或团队的职责产生一个明确的结果被封装在一个单独的实施模型构件中-23-指南：利用子系统封装交互子系统应当由交互图上的接口来描述到子系统的消息模型化为到子系统接口的消息到子系统的消息符合子系统接口的操作子系统发出的消息模型化为代理类发出的消息子系统内部的交互在子系统设计中完成-24-利用子系统封装交互的优点利用子系统封装交互提高了用例实现事件流的抽象级别用例实现较少混乱，尤其是在某些子系统内部很复杂时在创建子系统内部设计之前可以创建用例实现，以利于并行开发用例实现变得更加通用，也更容易变化（子系统是可替代的）-25-3.说明持久性相关行为在用例设计阶段，说明持久性相关行为需要考虑事务建模写持久对象删除持久对象修改持久对象读持久对象-26-事务建模事务原子操作调用“全部或全都不”提供一致性建模方法：文本方式（脚本）明确消息错误条件回滚、失败模式可能需要单独的交互图-27-4.改进用例实现的事件流对交互图中的消息添加必要的细节-28-5.评价类和子系统在全局对每个用例实现进行综合评价元素的名称应当说明模型元素的功能合并相似的模型元素使用继承来抽象模型元素保持模型元素和事件流一致-29-内容安排用例设计子系统设计类设计数据库设计-30-子系统设计子系统设计(SubsystemDesign)的目标用所包含设计元素和外部子系统/接口的协作来定义在子系统接口中指定的操作记录子系统的内部结构定义子系统接口和包含类之间的关系确定对其他子系统的依赖关系输入：具有接口定义的设计子系统输出更新后的接口定义子系统内部设计模型-31-指南：子系统设计目标松耦合可移植性，即插即用性能隔离变化独立进展建议不要陈述细节，而只陈述接口只依赖其它接口关键是抽象和封装-32-子系统建模约定接口在子系统外部代理类在子系统内部接口子系统代理类-33-子系统设计步骤1.将子系统行为分配给子系统元素2.描述子系统内部元素3.定义子系统间的依赖关系-34-子系统职责接口操作定义子系统的职责对接口的操作实现进行建模接口操作可以由以下实现内部类的操作内部子系统的操作-35-分配子系统职责步骤确定新的或者重用已有的设计元素将子系统职责分配给设计元素合并可适用机制（如持久性，分布）记录接口实现中的设计元素协作每个接口操作一个或多个交互图包含必需的设计元素关系的类图重新进行“确定设计元素”如果需要，调整子系统边界和依赖关系-36-建模方法：子系统交互图-37-实例：PaymentSystem子系统建模-38-运用构架机制：持久性接口IPayment提供了操作makePaymet(进行费用支付)，即子系统PaymentSystem需要实现该操作为简化处理，并说明持久性构架机制的应用，现假设支付是直接在某个费用数据库中进行插入操作需要引入构架机制：持久性:JDBC对该机制的写操作机制进行建模-39-接口操作实现的交互图-40-2.描述子系统内部元素-41-3.定义子系统间的依赖关系子系统与子系统之间依赖关系子系统与包之间依赖关系(小心使用)-42-实例：PaymentSubsystem子系统依赖关系-43-内容安排用例设计子系统设计类设计数据库设计-44-类设计类设计(ClassDesign)目标确保类可为用例实现提供必需的操作确保提供足够的信息可明确无误地实现处理和类相关的非功能需求输入用例实现(设计)输出设计类-45-设计类设计类设计模型的构造块设计类是已经完成了规格说明并且达到能够被实现程度的类来源于问题域和解域通过分析类的精化得到的问题域—添加实现细节解域，提供了能够实现系统的技术工具-46-设计类剖析在分析中，只要尽量捕获系统需要的行为，而完全不必考虑如何去实现这些行为在设计中，则必须准确地说明类是如何履行它们的职责完整的属性集合，包括详细说明的名称、类型、可视性和一些默认值将分析类指定的职责转化成一个或多个操作的完整集合-47-良好的设计类类的公共方法定义它和类用户之间的契约要从类用户的角度去评估类的目的基本特征完整性和充分性原始性高内聚低耦合-48-类设计的主要内容1.创建初始设计类2.定义操作3.定义方法和状态4.定义属性5.定义关系6.处理其它问题-49-1.创建初始设计类创建初始设计类，需要考虑类构造型边界控制实体可适用的设计模式构架机制持久性分布…-50-边界类的设计策略用户界面（UI）边界类使用什么用户界面开发工具哪些界面可以用开发工具直接创建外部系统接口边界类通常建模为子系统-51-实体类的设计策略实体对象通常是被动的和持久性的性能需求可能要对实体类进行重构持久性构架机制影响实体类-52-控制类的设计策略如何处理控制类是否真正地需要它们？它们应当被分开吗？下列情况下，控制类可能变为真正的设计类封装非常重要的控制流行为封装的行为很可能变化必须跨越多个进程或处理器进行分布封装的行为要求一些事务管理-53-调整控制类调整控制类的基本策略多个用例若有同样活动的控制类，将其整合起来，把相同部分作为一个新的控制类把一些简单的由边界类委托的职责交给实体类之后，删除没有进行场景控制的实体类用例的控制流程过于复杂，则可以考虑根据不同的控制业务分解成多个控制类2.定义操作操作是类的行为特征，描述了该类对于特定请求做出应答的规范同一个类的每个操作都具有唯一签名，通过描述操作的签名完成类操作的定义UML中的四种可见性公有（+）、私有（-）、保护（#）和包（~）-54-可见性操作名(参数方向参数名称:参数类型[多重性]=缺省值,…):返回类型[多重性]-55-发现操作显示在交互图中的消息其它独立功能的实施自身的管理功能(构造、析构等)类复制的需要(测试类是否相等，创建类副本等)其它操作机制的需要(垃圾收集、测试等)示例：定义类的操作-56--57-3.定义方法和状态方法(Method)是指操作的具体实现算法详细说明操作实现的细节可采用UML活动图对方法进行建模考虑的内容特殊算法要使用到其它对象和操作属性和参数如何实现和使用关系如何实现和使用方法的实现往往受对象的状态影响-58-状态对象的状态(State)反映于现实世界的一系列特征，这些特征影响该对象的实现目标明确一个对象的状态如何影响其行为利用状态机图进行建模要考虑的问题哪些对象有重要的状态如何确定一个对象可能的状态如何将状态机图映射到模型的其它部分-59-状态机图状态机图(StateMachinediagram)是一由状态和转移组成的有向图描述了一个对象的发展历史State1State2Event(args)[guardcondition]/action-60-两个特殊状态初始状态当一个对象创建时所进入的状态必须的只能有一个初始状态最终状态显示一个对象生命的结束可选的可能有多个-61-确定状态重要的、动态的属性申请的大人人数确定关联的存在和不存在转移转移（transition）是从一个源状态到一个目标状态之间的一个有向关系，包括三个要素事件(event)：事件发生时转移才有可能发生守卫条件(guardcondition)：当事件发生时，守卫条件为真，则发生转移；否则忽略该事件动作(action)：当转移发生时所执行的动作，该动作应当是原子操作。-62--63-增加活动和动作活动(Activities)关联于一个状态在进入状态时开始要花费时间完成可中断的动作(Actions)关联于一个转移花费很少量的时间完成是不可中断的-64-实例：申请对象的状态机图-65-哪些对象需要进行状态建模需要进行状态建模的对象其职责由状态转移所阐明的对象复杂的状态受控的用例以下对象不需要进行状态建模直接映射到实现的对象非状态受控的对象只有一个状态的对象-66-状态机图影射到模型的其它部分事件可以映射到操作方法应当使用状态特定信息来更新状态常常使用属性来表示4.定义属性指定名字、类型、可见性和可选的缺省值visibilityattributeName:Type=Default遵循编程语言和项目的命名约定类型应当