面向对象分析与设计(6)-设计模型1.ppt

1 面向对象分析与设计 设计模型 设计的目的地 2 分析和设计 分析侧重于理解问题功能需求系统结构行为 behavior 小模型 设计侧重于解决问题非功能性需求操作和属性对象的生命周期大模型 3 实现系统行为 分析行为用例分析活动把系统的行为分配给分析类 让分析类交互来完成系统的行为 设计构件用例设计活动把系统的行为分配给设计元素 子系统 类 子系统设计活动把子系统的行为分配给内部的设计元素类设计活动完成分配给每个类的行为 4 v v 分析模型和设计模型 一个项目可以建分析模型和设计模型两个模型 也可以只建设计模型 如果分析模型和设计模型的差别很大 那就要 建两个模型 如果分析模型和设计模型的差别不大 那就只 建设计模型 如果你只建了一个设计模型 最好能把分析后的结果作为一个版本保存 5 v 分析与设计 在分析中 焦点是创建系统的逻辑模型 该模型捕获系统为满足用户需求而必须提供的功能 v设计的目的是说明如何才能完全实现这一功能 整合解域的技术解决方案以提供实际上可实现的系统模型 设计模型 6 v 具体开发流程 应该由同一个团队负责从需求和设计 而不是采用一个分析师团队和一个独立的设计师团队 v设计模型建立在分析模型的基础之上 也 可以看作是分析模型的精化和细化 7 什么时候需要维护两套模型 v 庞大的 v复杂的v战略性的v受经常变更所支配的v期望长期运行的v外包的 8 v 分析模型的价值 介绍新人加入项目 v在交付几个月或几年后重新理解系统 v理解系统是怎样满足客户需求以及提供可 跟踪性 v计划维护和增强 v理解系统的逻辑构架v外包系统的构造 9 v 设计模型 设计模型内容 交互模型 设计类图 部署图 10 设计工作流 设计师用例工程师组件工程师 构架设计 设计用例 设计类 设计子系统 11 v 设计阶段的工作 将开发出一个基于面向对象的系统逻辑解决方案 这个解决方案的核心是要建立交互模型 它能够展示出为了满足系统需求各个对象相互之间如何进行通信 v在交互图建立之后 接着要建立设计类图 它对要实现的软件类 和接口 的定义进行总结 12 v v 浅析交互模型 在面向对象的视角里 整个系统是由一系列的对象 以及对象之间的交互与协作构成的 交互建模 正是要通过寻找对象之间的交互关系 从而进行 行为分配 IvarJacobson说 只有在所有的用例为所有事件进程建立了交互模型之后 才可以确定已经发现系统所需的每个对象所扮演的角色 以及它们的责任 13 v 交互模型表现方式 在UML规范中 交互模型包括两种不同的表现形式 一种是强调顺序的顺序图 Sequence diagram 读者可以从中可以很容易地看出事件发生的次序 另一种是强调组织的协作图 Collaboration diagram 它通过使用布局图指明了各个对象之间是如何静态相连的 14 v v 交互模型的步骤 引入实体对象 实体对象就是域模型 类图 中的某个分析类 的一个实例 引入边界对象和参与者 v引入控制对象 15 构建交互模型 新增书籍信息 vv 基本事件流1 图书管理员向系统发出 新增书籍信息 请求 2 系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类 3 图书管理员做出选择后 显示相应界面 让图书管理员输入信息 并自动根据书号规则生成书号 4 图书管理员输入书籍的相关信息 包括 书名 作者 出版社 ISBN号 开本 页数 定价 是否有CDROM 5 系统确认输入的信息中书名未有重名 6 系统将所输入的信息存储建档 扩展事件流5a 如果输入的书名有重名现象 则显示出重名的书籍 并要求图书管理员选择修改书名或取消输入 5a1 图书管理员选择取消输入 则结束用例 不做存储建档工作 5a2 图书管理员选择修改书名后 转到5 16 v 构建设计模型 在构建交互模型时 将会发现类应该具有的方法 也会在设计时找到一些新的属性 而这些东西将进一步地完善我们的静态模型 概念模型 17 v 设计类图的步骤 基于域模型的基础 结合分析 交互模型构建时所引入的分析 设计类 画出相应的设计类图 并且将这里所找到的属性 方法补充在类图中去 这样我们将获得一个较完整的类模型 18 v v 分析类到设计类转换 分析中的操作 是类所提供的一小部分功能的高级逻辑规格说明 v设计中的方法 是一个被完整地说明的可以 用源代码实现的功能 高级的操作实际上可以被分解成一个或多个可实现的方法 19 v 从分析类到设计元素 在设计活动中 分析类将细化为同样也是行为承担者的设计元素 通常两者间是多对多的影射关系 20 v 映射到设计元素的途径 一个分析类成为设计模型中的一个类 v一个分析类成为设计模型中一个类的组成 部分 v一个分析类成为设计模型中的一个聚集类 意味着聚集中的成员可能不在分析模型中显式地出现 v一个分析类成为设计模型中的一个继承树v一个分析类之间的关系成为设计模型中的 一个类 21 v 映射到设计元素的途径 一个分析类成为设计模型中的一组功能相关的类 设计包 v一个分析类成为设计模型中的一个子系统v一个分析类成为设计模型中的一个关系v一个分析类的组成部分可以被硬件实现 而根本不在设计模型中出现 v任何上述方式的组合 22 v 设计类图应完成的工作 在设计中 必须准确地说明类是如何履行它们的职责 必须完成以下事情 完整的属性集合 包括详细说明的名称 类型 可视性和一些默认值 可选的 将分析类指定的操作转化成一个或多个方法的 完整集合 23 v 设计类图 引入基础类 在着手开发之前 还有一件很重要的事要去完成 那就是引入基础类 不管使用什么开发工具进行代码编写 都将以 各种库函数 框架作为开发基础 例 如 NET J2EE CORBA等框架 MFC OWL BDE Swing JDBC等库函数 24 v 确定基础类的原则 首先要根据应用的需要选择相应的框架v然后再根据具体的局部需要还选择相应的 库函数 25 v 选择基础类举例 如果我们需要进行数据库操作 我们将可能使用ODBC JDBC ADO BDE等数据库访问引擎中的一种 v如果我们需要分布式地处理 就可能要从DCOM CORBA EJB WebServices中选择一种合适的技术 26 v 选择基础类举例 续 当我们需要进行网络操作时 我们可以从MFC中选择一个Socket的实现 也可能是从SUN提供的网络包中选择相应的类 v当我们需要进行用户界面设计时 我们可能使用MFC中提供的相关类 也可能使用Java中的AWT或Swing包来实现 27 v 学习开发知识的要点 应该花足够多的时间来了解各种基础框架 库函数的功能与特性 以便在设计时做出最优的选择 v另外 还应该对这些基础框架 库函数的类结构有一个清晰的了解 这样就可以最有效地找到基础类 最高效地使用 28 识别设计元素 vv 目的分析分析类的交互以识别设计模型元素细化构架 可能时结合复用识别通用设计问题的通用解决方案把构架相关的设计模型元素放到Logicalview部分输入 补充规约设计指南软件构架文档分析类设计模型 vv 输出 设计模型元素 设计类 接口 设计包 设计子系统 角色 构架设计师 29 v v v 设计元素 接口和包 vv 接口 接口是定义行为集 即操作集 的模型元素 该行为集由classifier模型元素 即类 子系统或component 提供 classifier可以实现一个或多个接口 一个接口可由一个或多个classifier实现 实现相同接口的那些classifier在系统中可以互换 每个接口应该是唯一且明确定义的操作集设计包 一个包中可以包含公有类 也可以包含私有类公有类可以与任何其他类相关联私有类只能与其所在包中包含的类相关联 包接口由包的公有类组成 包接口隔离并实施对其他包的依赖关系包耦合的原则 不应对包进行交叉耦合 即互相依赖 例如两个包不应互相依赖 较低层中的包不应依赖于较高层中的包 包只应依赖于同一层及下一层中的包 通常 依赖关系不应跳层 除非依赖行为在所有层之间都是共同的 30 v 设计元素 设计子系统 v 设计子系统 设计子系统是一种模型元素 它具有包 其中可包含其他模型元素 和类 其具有行为 的语义 子系统的行为由它实现的一个或多个接口来定义 子系统的行为由它所包含的类或其他子系统提供 子系统内部的元素对外不可见子系统的特点可以独立预定 配置或交付可以独立开发 只要接口保持不变 可以在一组分布式计算节点上独立部署可以在不破坏系统其他部分的情况下独立地进行更改可以将系统分为若干单元 以提供对关键资源的有限安全保护 可以在设计中代表现有产品或外部系统 31 v v v v v 设计元素 子系统和包的区别 子系统比包封装性好 子系统有接口 外部只能通过子系统接口访问子系统内部 v包没有接口 外部可以直接访问包中公共的类 子系统具有行为 而包没有 子系统是一种通过一个或多个它所实现的接口来提供行为的包 v而包并不提供行为它们只是用来容纳对象的容器 子系统依赖关系 子系统不应暴露自己的任何内容 子系统外部的元素都 不应依赖于子系统内部特定元素的存在 子系统只应依赖于其他模型元素的接口 因此它不直接 依赖于子系统外部的任何特定模型元素 例外情况 许多子系统共享一组类定义 因此这些子系统将 导入 包含公共类的包中的内容 这只能用于位于构架低层的包 并且原因只能是为了确保在子系统之间传递的公共类定义保持一致 32 v v v v v v 划分子系统和包的原因 可以更容易地了解模型的整体结构 可以在完成系统后将包和子系统用作订购 配置或交付单元 由于资源分配以及不同开发团队的能力不同 可能要求将该项目划分给处于不同位置的不同组 通过带有明确定义的接口的子系统 可以在各团队之间以有控制 有协调的方式划分工作 从而使设计和实施能够平行地进行 子系统可用于按照用户类型来建立设计模型的结构 许多变更需求都来自于用户 子系统可确保来自特定用户类型的变更需求只影响系统中与该用户类型对应的部分 在某些应用程序中 某些特定信息应该只能由少数几个人访问 子系统使您能够在需要保守秘密的地方保守秘密子系统用于代表系统所使用的现有产品和服务 例如COTS产品和库 33 v v v v 步骤识别类和子系统识别子系统接口识别复用机会修改设计模型的组织 v 评审 34 v v v v v 识别设计类和子系统 这个活动的主要目的还是根据分析类的交互识别出设计子系统或包 大部分设计类还是在用例设计和子系统设计中产生的 子系统的类型 控制子系统协调子系统 数据采集子系统 从外部环境采集数据 数据分析子系统 分析数据并负责报告和 或显示其他子系统采集的数据 Server子系统 其它子系统提供服务 用户界面子系统 提供用户界面 并且作为client向用户提供对一个或多个server提供的服务的访问 对于不同类型的用户 可能会有不同的用户界面子系统通常是由多个简单用户界面对象组成的组合对象 I O子系统 系统服务 35 v v v v 控制子系统控制子系统控制系统的特定方面控制子系统从外部环境接收输入并向外部环境提供输出 通常不需要人类干预控制子系统经常是依赖于状态的 这种情况下它至少含有一个依赖于状态的控制对象例如 CruiseControl子系统 该子系统从巡航控制杆 刹车和引擎接收输入 它的输出控制节流阀 对于节流阀要进行什么样的调整是依赖于状态的 并且在没有人类干预的情况下进行 CruiseControl MonitoringSystem CruiseControlSubsytem Monitoring 36 v v v v v 协调子系统 协调子系统负责协调控制子系统的动作 如果这些控制子系统之间完全独立的话 就不需要协调子系统 如果控制子系统相对来说比较简单 控制子系统可以自行协调动作 如果协调的工作相对复杂时 使用一个独立的协调子系统通常更好些 例如 电梯控制系统中的调度子系统 在这个系统中 所有的电梯内乘客的服务请求都是由该电梯处理的 但是 在电梯外某楼层的乘客发出服务请求时 必须要决定由哪部电梯来对应这个请求 这个决定由调度子系统来做 当调度子系统从楼层子系统接到服务请求时 它决定是否需要分配一部电梯到那个楼层 如果需要的话 它对选定的电梯子系统发出调度请求 37 v v v v Server子系统 Server子系统为其它子系统提供服务 对Client子系统提供的请求做出相应 并且 它并不发出任何请求 最简单的 一个server对象可以是一个实体对象 复杂的server对象由多个对象组成 它们包含实体 协调对象来处理client请求并决定哪个对象要来处理请求 还包括封装了业务逻辑的业务逻辑对象 经常地 server提供和一个或一组data repository相关的服务 或者它提供对数据库或者数据库中的关系的操作 另一方面 server可能会与I O设备相关 例如fileserver和lineprinterserver 38 v v 分包策略 将边界类打包 如果容易变化 就要单独组织成package如果不容易变化 而且与某个实体类或控制类联系紧密 就把这个接口类与相应的实体类或控制类组织成子系统 v如果边界类不容易变化 在功能上与任何实体类或控制类都不相关 应将它们和属于同一接口的边界类放置在单独的包中v如果某一边界类与一项可选服务相关 就要在单独的子系统中将此边界类与协同提供该服务的类归为一组 39 v v 分包策略 将功能相关的类打包 判断两个类功能相关的标准 按重要性递减顺序排列 一个类的行为和 或 结构的变化使得另一个类也必须相应地变 化 在某个类删除后出现了多余的类 这些类就和与已删除的类存在 一定的联系 两个对象进行大量的消息交互 或者以其他复杂的方式互相通信如果某个边界类的功能是显示一个特定的实体类 两个类与同一个主角进行交互 或受到对同一个主角更改的影响两个类之间存在某些关系 关联关系 聚合关系等 一个类可能与创建其实例的类在功能上相关 决定两个类不应该放在同一个package的策略 与不同主角相关的两个类 可选类和必选类 40 v v v v 从类协作中确定子系统为了确定子系统可以做合并的协作图 合并的协作图是所有usecase的协作图合成 但通常没有messagesequencenumber 合并协作图的过程中也可以验证系统的健壮性 做法usecase的执行有一个先后次序 协作图合成的顺序应该与usecase执行的顺序一致对于每个用例 从每个时序图中取出新的对象和新的消息交互加入到合成图中 多个协作图出现的对象和消息交互只表示一次如果一个对象向另一个对象发多个单独的消息 我们不必把所有的这些消息都画到图中 而是可以用一个组合消息来代替 v 确定子系统 如果几个类只是在相互之间进行交互 并且可生成一组定义明确的结果 就应将该这些类封装在一个子系统中 如果分析类很复杂 它体现的行为不应该由单独的一个类来承担 或者它的责任需要复用 那么这个分析类应该被设计成子系统 41 v 记录 v Rose中 对于每个子系统或包 在 DesignModel 包中建一个包 包的名是子系统名 或包名 如果是子系统 把包的stereotype设成 subsystem 把相关的类拖到这个包中 为每个子系统提供一个名称和一段简短说明 为每个子系统和包添加类图 可以v画一个只表示内部元素关系的类图 或者v画一个类图既有内部的元素 又包括上下文 与外部的依赖关系 v画一个类图表示内部的元素 一个类图表示上下文写一个从分析类到设计类的文档 42 v v v v v v v v 识别子系统接口目的 基于子系统的责任来识别子系统的接口 v 步骤 为所有子系统识别一系列候选接口子系统内部的类对子系统外提供的操作就是子系统的操作对每个接口要识别出输入和输出 从而决定参数和返回值按照操作的相关职责将这些操作分组 分成较小的组比分成较大的组更可取 寻找接口的相似性 必要时合并或加入新的接口 定义接口依赖如果接口操作的参数是实现某一特定接口的对象 则应定义该接口与它所依赖的接口之间的依赖关联关系 建立接口和子系统的映射为每个子系统的每个接口新建一个proxy类 为每个接口定义行为如果有必要 需要定义支持接口的设计元素的状态图 所有的子系统的接口放在一起 用package组织起来为了管理对接口的修改 应将接口分成一个或多个包 这些包由构架设计师拥有 43 接口说明 vvv 接口名 给接口的命名要能反映它在系统中扮演的角色 名字要简短 一个或两个单词就可以 不用包含 interface 的字样 因为它的类型已经用模型元素的类型标识了 接口名可以以 I 开头 如ICourseCatalogSystem接口描述 接口的描述要能表达它的责任 接口描述用几个句子就行了 接口描述不要只是重复接口名字的内容操作定义 每个接口都要提供一个唯一且定义良好的操作集 操作名要反映操作的结果 操作的描述要描述操作做什么 包括关键的算法和要返回什么值 同时要给参数命名并定义类型 44 v v 识别复用机会 vvv 策略 如果可能 就要尽量复用已经存在的组件步骤查找相似的接口修改新的接口以增强适合度用已经存在的接口代替备选接口把子系统映射到已存在的component复用来源 系统内部以前开发过的设计元素 系统外部 商业性的可用componentv以前开发过的应用中的component 45 v 识别复用机会 复用发生在现在系统的情况 已经建立了一个应用和一些通用部分 建立第二个应用时你发现你可以复用第一个应用中的 一部分 但是这部分没有设计成可复用 让需要复用的设计元素 类 包或子系统 可以复 用 这可能需要修改名字 让它们更通用 改善它们的文档 把它们挪到一个更通用的功能层等 现在你就可以在新的应用中使用这些元素了 当原来的应用升级的时候 应该用新的可复用的元素 46 v 修改设计模型的组织 向设计模型中加入新的设计元素 就要对设计模型中的元素重新分包v重新分包到达到这个目标 减少包之间的耦合度 增强包内部的内聚性 最根本的目标是可以独立的设计和开发不同的 包 完全的独立几乎是不可能的 但是松散的耦合 可以使开发大型复杂的系统变得更简单一些 47 检查点 vvv General 是否提供了不同包的服务的可理解的图形 你能发现可以在问题域更广泛使用的相似的结构化解决方案么 如果有 这就是设计模式 Layers 超过7层么 超过7层的结构需要重新考虑 一般不应该超过7层 包包的名字具有描述性么 包的描述与它包括的类的责任匹配么 包之间的依赖关系与包含的类之间的关系一致么 根据包决定的策略包中的类应该属于那个包么 存在包中的类和类的协作是否可以分割成另外一个包 包的数目与类的数目的比率适合么 48 检查点 vv 子系统 整个模型中子系统的划分有一个逻辑上的一致性么 类 每个类的名字是否清晰的描述了它所扮演的角色 类所有的部分功能上是否耦合 所有的类元素对于usecase分析都是必需的么 聚合和关联的角色名是否准确的描述了关系 关系的multiplicity正确么 49 子系统设计 vvvv 目的用所包含类的协作来定义在子系统接口中指定的行为记录子系统的内部结构定义子系统接口和包含类之间的实现关系确定对其他子系统的依赖关系角色 设计师输入 用例实现 具有接口定义的设计子系统 设计指南输出 用例实现 具有接口定义的设计子系统 设计类 50 v v v 子系统设计 v 目标 松耦合移植性好 具有即插即用的兼容性隔离变更独立的升级 v 强烈建议 不要暴露细节 而仅仅暴露接口子系统包括的任何元素都不应该具有 public 的可见性子系统外部的任何元素都不应该依赖与子系统内部某个元素的存在 只依赖与其它的接口 以便它不直接依赖与子系统外部的任何模型元素例外就是许多子系统共享一系列类定义 这些子系统要包括公用类的包 这种情况只能是当包处于接口低层次时才可能发生 一定要保证在子系统之间传递的类的公用定义是一致的 对子系统的依赖就是对接口的依赖 51 v 步骤 将子系统行为分配给子系统元素 v记录子系统元素 v说明子系统依赖关系 52 v v v v 将子系统行为分配给子系统元素 子系统的外部行为是通过它所实现的接口定义的 当子系统实现了某个接口时 它就保证支持该接口定义的每一个操作 操作可以按以下方法实现 让子系统包含的类来进行的操作 让所包含的子系统实现的接口来进行的操作 对子系统实现的接口进行的每一个操作都应当有一个或者多个记录序列图 该序列图属于子系统 并用来定义子系统的内部行为 如果子系统的行为高度依赖于状态 可以画状态图来说明子系统的行为 53 v 将子系统行为分配给子系统元素 此流程与 用例分析 中定义的流程相似 但我们使用接口操作而不使用用例 v用例分析的输出是用例实现 这个活动的 输出可以叫接口实现 v具体步骤 对于每个接口 决定参与接口实现的类或子系 统 必要时需要创建新的类以及子系统 让类和子系统交互来完成接口定义的行为 需 要结合构架机制 54 v v Step2 记录子系统元素 v 具体工作 描述类和子系统的责任 确定类和子系统的属性和关系 整合类和子系统小心避免在两个不同的子系统实际拥有同一个类 存在这样的类则意味着可能没有很好地规划子系统边界 所以要定期重新检查确定设计元素活动以重新平衡子系统职责要记录子系统的内部结构 要创建一个或者多个类图来表示子系统包含的元素以及它们相互之间的关联关系 虽然一个类图已经足够 但使用多个类图能降低复杂性并提高可读性 55 v v Step3 说明子系统依赖关系 当子系统包含的某个元素使用了另一个子系统中的某个元素行为时 实际上就在所属子系统间创建了依赖关系v创建依赖关系时 要注意 确保子系统包含的模型元素和其他子系统包含 的模型元素之间没有直接的依赖关系或者关联关系 而是依赖于接口 确保子系统和接口之间没有循环的依赖关系 子系统不能既实现一个接口而又依赖于该接口可以直接绘制子系统之间以及子系统和包之间的依赖关系 56 v 检查点 对于子系统提供的每个接口都有相应的实现关系么 v对于子系统使用的每个接口都有依赖关系v确保子系统内部的元素都不具有public可 见性 v子系统实现的接口的每个操作在交互图中都被文档化了么 如果没有 这个操作是不是只被一个类实现 以至于很容易的看出类操作和接口操作的简单的1 1的对应关系 57 v v 类设计类设计时 要考虑 实现和部署环境 需要让类去适应特定的产品 变成语言 分布 物理限制 例如 有限的内存 性能 组件环境 如COM或COBAR 以及其他的实现技术 如何用设计模式来帮助我们解决实现问题 vv 目的 确保类可为用例实现提供必需的行为 确保提供充足的信息来明确无误地实施类 处理和类有关的非功能性需求 包含用于类的设计机制角色 设计师 输入 补充规约 设计指南 用例实现 设计模型 n输出n设计类 58 类设计 v 步骤创建初始设计类定义类的可见性 定义操作定义方法定义状态确定属性定义依赖关系定义关联关系解决用例冲突处理一般的非功能性需求 59 v v v v Step1 创建初始的设计类做设计类的设计时 将没有分析类的类型 但是可以根据将要设计的分析类类型 采用不同的特定策略来创建初始设计类 v 需要多少类 大量的简单的类意味着每个类 封装了整个系统逻辑的很小的一部分v更容易复用v容易实现 少量的复杂的类意味着每个类 封装了整个系统逻辑的很大一部分v不容易复用v实现困难 注意Aclassshouldhaveasinglewellfocusedpurpose Aclassshoulddoonethinganddoitwell 60 边界类的设计策略 vv UI边界类 分析时识别出来了高层次的边界类 设计时需要创建更多的类来支持实际的GUII和外部系统交互 用户接口边界类的设计依赖与用什么UI开发工具 你只需要设计开发环境不能自己你创建的部分 用户界面的原型开发会使设计有一个良好的起点系统边界类 外部系统的接口通常有复杂的行为 所以通常模型化成子系统 如果接口不复杂 你可以用一个或多个设计类来表示 以后对于每个协议 接口或API使用一个单独的设计类 61 v v 实体类的设计策略实体对象经常是被动的和持久化的性能要求可能会导致返工 例如 如果我们有一个包括5个属性的类 一个属性实际上不是持久化的 只是运行时的记录 另外两个属性不常用 设计时 我们决定应该能立即查询常用的属性 而对于不常用的属性只有当有人请求时才去查询 我们不想为用户做一个复杂的设计 因此 从数据的角度看 我们把FatClass作为两个持久化数据类的代理 它被查询时它就会从数据库中查询FatClassDataHelper 而只有用户请求时才从数据库中查询FatClassLazyDataHelperFatClass2transientbookkeepingFatClass1 transientbookkeepingcommonUsedAtt1commonUsedAtt2rareUseAtt3rareUseAtt4 FatClassDataHelpercommonUsedAtt1commonUsedAtt2 FatClassLazyDataHelperrareUseAtt3rareUseAtt4 62 v v v 实体类的设计策略 确定永久类 必需在永久媒介上保存状态的类被称为 永久类 在分析的设计后 已经为永久类标记了 永久性 的分析机制 设计之前构架设计师应该已经选择了设计机制和实现 机制 提醒了数据库设计员要特别注意类的物理存储特征 告诉负责永久性机制的设计员 类的实例必需是永久 性的 设计永久类是要应用构架设计师选择的实现机制 63 v v 控制类的设计策略 如果控制类只是边界类和实体类的通路 就可以去掉 以下的控制类是必要的 封装了复杂的控制行为封装的行为可能会变化 性能必须分布在多个进程或处理器中需要事务管理 64 v Step2 定义类的可见性 公有 类可由它所在的包之外的类引用 v 私有 类 或类的可见性是 实施 只能由 同一包内的类引用 65 v v Step3 定义操作 v 操作来源 交互图中的message为与设计类相对应的分析类的每个责任定义一个操作v研究设计类参与的用例实现 看操作是如何被使用的细化操作 描述 返回值和参数v研究use case特定的需求 确保没有遗漏操作的隐含需求 其它是否存在一种生成类实例的方式v是否有判断两个类实例是否相等的需求v是否有创建类实例拷贝的需求v为了应用机制是否需要新的操作 66 v v v 定义操作 命名和说明操作 在命名操作 返回类型和参数及其类型时 应该使用实 现语言的命名约定 操作名应该简短 并可说明进行操作所得到的结果 从操作用户的角度为操作编写说明 定义操作可见性 属性和操作都有 Public Protected Private Scope 属性和操作都有 Instance 一个类实例对应一个属性或操作实例 Classifier 所有的类实例对应一个属性或操作实例 67 v v Step4 定义方法 方法说明了操作的实现 大多数情况下 方法是直接由编程语言实施的 如果实现操作需要采用特定算法 或需要操作说明之外的更多信息 则要采用单独的方法说明 v需要考虑 特殊的算法 使用的其他对象和操作 属性和参数如何被实现和使用 关系 relations 如何被实现和使用 68 v v Step5 定义状态 对于状态相关的设计类 可以画状态图来增加对类的理解 状态图中每一状态转移事件都与一个操作关联 关系 对象的操作根据状态可以具有不同的行为 所以定义方法的时候应该参照状态图v在处理一些异常事件时