第9章面向对象系统设计.ppt

面向对象设计 全局设计 任务将在拟建系统的全局范围内，以分析活动的结果为出发点，将现有的“分析类”映射成模型中的“设计元素”，明确适用于拟建系统的“设计机制”，调整内容逐渐充实拟建系统的“构架”。 局部设计 任务是基于“全局分析”和“局部分析”的框架，利用“全局设计”提供的素材，在不同的局部，将分析的结果用“设计元素”加以“替换”和“落实”。 第一阶段 全局设计  责任人—依据—活动—结果 全局设计 1.确定核心设计元素 2.引入外围元素 3.优化组织结构 1.确定核心元素 在系统构架的中高层，以“分析类”为出发点，确定相应的“核心设计元素”—”设计类”和“子系统接口” 。 设计类：承担那些对应于独立构件的“分析类”责任集合； 子系统接口：定义了那些对应于复合构件的“分析类”之“责任”集合。明确定义责任，但不约束责任的承担者及承担方式。 确定核心元素步骤1 确定核心元素步骤2 全局设计 1.确定核心设计元素 2.引入外围元素 3.优化组织结构 ２、引入外围元素 例：“架构机制”映射及其使用者 描述“留存”机制 例、描述“留存”机制 例、描述“留存”机制 例、描述“留存”机制 例、描述“留存”机制 全局设计 1.确定核心设计元素 2.引入外围元素 3.优化组织结构 ３、优化组织结构 第二阶段 局部设计 任务是基于“全局分析”和“局部分析”的框架，利用“全局设计”提供的素材，在不同的局部，将分析的结果用“设计元素”加以“替换”和“落实”。 局部设计  责任人—依据—活动—结果 １实现需求场景 基本依据是“局部分析”任务中得到的“USE CASE 实现”（即用“分析类”协作关系转述的需求场景）；活动的结果是设计意义上的“USE CASE 实现” ,即用“全局设计”任务中得到的“设计元素”协作关系描述的“USE CASE 实现”。 “分析类”和“设计元素”的差异 在分析活动中，很多与应用逻辑不直接相关的技术问题细节可以用概要的方式描述或封装；在设计活动中，对大多数技术问题应当有一个明确的交待。 步骤1：用核心设计元素替换分析类 一方面，替换对应“子系统接口”的“分析类”。在“Use Case 实现”的“参与类图”中，用子系统接口表述特定子系统。在“Use Case 实现”的“序列图”中，如果特定子系统只接收消息，可以用相应“子系统接口”的实例表述特定子系统。如果特定子系统有可能向外发送消息，用《subsystem proxy》的实例替换相应的分析类实例。 另一方面，替换直接对应设计类的分析类，这种替换过程在Use Case实现的动态和静态图中没有显著的变化。 步骤2：落实“构架机制”的支撑作用 静态结构方面，绑定“构架机制”。根据“构架机制”的指导，针对 作为“构架机制”使用者的设计类，添加一些必要的操作和属性，建立并衔接必要的外围设计元素。 动态行为方面，描述“构架机制”在U se Case实现中的应用场景，针对“构架机制”使用者所参与的特定事件序列，将“构架机制”的特定应用场景在当前“Use Case实现”的相关序列图当中扩展 。 步骤一 用核心设计元素替换分析类 活动的结果是实现“子系统接口”要求的一组“设计元素”以及相关的静态和动态描述。 “子系统接口”就是对特定子系统提出的行为要求。可以看成是小型的“Use Case”。 例 用“核心设计元素”替换“分析类”—在 参与类图中替换。 144页 实现子系统接口 活动的结果是实现“子系统接口”要求的一组“设计元素”以及相关的静态和动态描述。 “子系统接口”就是对特定子系统提出的行为要求。可以看成是小型的“Use Case”。 实现子系统接口步骤 1、实现“子系统接口”定义的行为 首先，确定参与子系统行为的“设计元素”，可以是新建的，也可以是已经存在的。 然后，描述子系统的动态场景和静态结构。 2、明确子系统与外部设计元素的关系 如果参与实现子系统的“设计元素”全部新建于子系统对应的包中，那么该子系统对其他设计元素的依赖关系等同于相应“子系统接口”对其他设计元素的依赖关系。否则要说明子系统对其他设计元素的依赖关系。 步骤二 落实“构架机制”的支撑作用 下表给出设计类Claim_record应用“留存”机制时构造型《role》所对应的核心设计元素和衔接设计元素： 例:设计元素Claim_record使用RDBMS—JDBC的静态结构 例:Claim_record使用RDBMS-JDBC的“增”场景 例:Claim_record使用RDBMS-JDBC的“查”场景（P148） Thank you DBClaim_record 《role》DBClass Claim_recordList 《role》Persisten