系统分析与设计 课件 第五章 对象交互设计与类的设计

含弘光大继往开来第五章对象交互设计与类的设计目录contents01020304系统操作契约Contract对象交互设计ObjectInteractionDesign类的设计ClassDesign小结Summary系统操作契约01

系统操作契约的核心部分是其前置条件（Pre-condition）和后置条件（Post-condition）。前置条件代表了系统操作执行之前，需要满足的基本假设条件。后置条件代表了系统操作执行完毕之后系统状态变化后的结果。

构建对象序列图最关键的步骤就是分析系统操作契约的后置条件，原因在于系统操作执行完毕之后需要满足的系统状态包含了三类情形：（1）对象被创建或销毁（2）对象的属性发生变更（3）对象之间的连接关系被创建或者销毁5/2/20264简要概括什么是对象序列图?以一种时间顺序的方式说明为了执行用例行为的关键部分而在对象之间进行的交互的图交互是使用消息的形式行为的责任分配给消息收件者箱或类构造型符号代表对象。

垂直虚线表示对象的生命周期。

细条代表时间控制，周期焦点，当对象行为（履行职责）。

标记水平线代表消息在对象之间传递。对象序列图的基本元素5/2/20266系统操作契约中的职责分配该契约后置条件包括两项职责：创建顾客对象并写入数据库创建商家对象并写入数据库这两项职责是“或”的关系，即系统在用户注册操作时会执行其中一项职责。设计过程中通过概念类图和对象序列图来确定哪个或哪些对象承担这些职责，以及它们如何通过交互来完成。对象交互设计025/2/20269

基于工业界及学术界过去数十年软件工程实践，有学者总结提出了一些用于解决职责分配过程中若干经典问题的设计模式，即：通用职责分配软件模式GRASP（GeneralResponsibilityAssignmentSoftwarePattern）。接下来会对最常用的几种模式加以探讨和举例：专家模式、创建者模式、控制器模式、高内聚模式、低耦合模式。GRASP模式5/2/202610专家模式构建步骤1分析用例系统操作契约的后置条件。明确：实现某个系统操作需要完成哪些职责？

当我们不确定某项职责应该分配给哪个对象时，通常会选择把职责分配给信息专家。因为信息专家往往具有实现这个职责所必需的信息。在这种情况下，就不需要更多的持有其他信息的对象参与进来，减少通信的开销。系统操作计算订单总额交叉引用订单结算管理(用例)前置条件1.订单对象已存在2.订单对象中包含一个商品列表，其由若干数量的商品组成，数量大于等于13.各商品价格已定后置条件1.根据订单中的商品，得到了订单的应付金额5/2/202611专家模式构建步骤2结合相关用例的概念类图分析出潜在承担者找到Order(只有它才知道交易商品的列表)，它将负责计算总额为了计算总额，需计算小计金额，找到SaleLineItem，只有它才知道订单中各商品数量。最后计算小计金额需要商品单价，于是找到ProductSpecification，只有它才知道各类商品的单价.5/2/202612专家模式构建步骤3根据上一步确定的职责绘制对象序列图与设计类图5/2/202613创建者模式

我们知道，某个对象创建了另一个对象，也就意味着两个对象构成了非常强的连接（依赖）关系。往往被创建者要等到创建者消除二者之间的连接，它才能够被销毁并被内存回收。

当需要创建某个对象时，究竟该由哪个对象来承担这个职责呢？创建者模式建议，当如下情形发生时（条件满足越多越好），最好选用B作为A的创建者：B”包含”或组成聚集AB记录AB直接使用AB具有A的初始化数据，并在创建A时会将这些数据传递给A5/2/202614创建者模式根据上述规则，应该由谁来创建顾客Customer的对象？不难看出，对上述四条规则符合最多的类是CustomerServiceImpl5/2/202615控制器模式

控制器模式用于明确首先接收和处理（或转发）系统操作的第一个对象是什么。

控制器模式建议，当如下情形发生时（条件满足越多越好），最好把该对象用作控制器对象：（1）代表整个“系统”、“根对象”、运行软件的设备或主要子系统，这些是外观控制器的所有变体。（2）代表用例场景，在该场景中发生系统事件，通常命名为<UseCaseName>Handler<UseCaseName>Coordinator或<UseCaseName>Session(用例或会话控制器)。5/2/202616控制器模式可以留意到MsegMapper类事实上是作为一个前置分类器，对来自外部的用户创建请求根据顾客、商家两种类别进行了分流。思考:CustomerController类和StoreServiceController类为什么没有MsegMapper适合？5/2/202617高内聚模式

内聚度用以刻画模块内部各部分之间相互关联的紧密程度。高内聚模式旨在促进设计过程中，模块业务功能最好只干一件/类事。根据以上原则,思考是否可以在MesgMapper中，直接根据系统操作“用户注册”的消息签名sign_up(tel:string,code:string,password:string,type:string)中的参数“类型（type:string）”作为控制开关，让它根据不同的参数，要么创建Customer要么创建Store?5/2/202618低耦合模式

耦合度用以刻画模块之间相互依赖的紧密程度。低耦合模式旨在促进设计过程中，模块业务功能上具有较高的完整性和独立性：单独能干好一件/类事。根据以上原则,再次从耦合度的角度来思考：是否可以让MesgMapper来创建Customer或者Store的对象？5/2/202619类的设计035/2/202621设计类图与概念类图面向对象方法最终的程序产出是程序（类的实现）。在获得程序类模型之前，需要得到其设计模型，即以设计类图形式表达的类；而在获得设计类模型之前，需要得到其分析类模型，即之前在需求分析阶段所构建的概念类图。较之概念类图，设计类图有以下特点：（1）设计类图中的类所含信息更全面（例如方法刻画）（2）设计类图中类的数量可能或多于概念类图中类的数量（3）设计类图中的类间关系可能会多于概念类图中的类间关系5/2/202622设计类图的构建

一旦得到了对象序列图，其与概念类图的结合，就容易推导出其设计类图。现根据对象序列图和概念类图，请构建出相应的预约宠物服务的设计类图:5/2/202623设计类图的构建5/2/202624代码骨架的构建

一旦得到了对象序列图和设计类模型，就可以方便地转换成代码框架。这是由于：根据设计类图，可以得知有哪些类存在，类的属性如何定义，类的方法如何定义根据对象序列图，可以得知某个方法体内部，与哪些对象发生过交互，交互时调用了哪些方法，以及调用的时间序。5/2/202625代码骨架的构建同学们可以自行尝试，给出简易的代码骨架。5/2/202626代码骨架的构建部分代码骨架实例小结04

本章从需求分析阶段的两个重要制品系统操作契约及概念类图出发，讨论了设计阶段最重要的工作，即对象序列图的开发过程；其中穿插了对GRASP职责分配设计模式的使用案例。此后，继续探讨了基于对象序列图的设计类图开发，以及基于对象序列图和设计类图的代码框架生成方法。你应该学会:理解系统操作契约后置条件的意义；理解对象序列图、设计类图的构