《面向对象系统分析和设计》 第07章 笔记 + 习题.txt

C&C++论坛精华

作者：rick1126
email: [e-mail]
日期：8/24/2001 6:46:33 AM

第7章 对象责任: 服务和场景

【本章要求】

  . 定义商业谋略和过程, 并举例
  . 定义两种类型的服务
  . 描述识别服务的方法
  . 描述记叙性规格说明文档存在的典型问题
  . 定义和使用服务场景
  . 定义结构性英语, 用其记录商业过程
  . 定义判定表和判定树, 用其描述具有复杂设计逻辑的谋略
  . 描述状态转换图
  . 描述识别服务的原始类的方法

【本章笔记】
  
  7.1 对象的"'我'做什么"责任

  〖服务和事件〗

    . 服务(方法)
      - 信息系统为了达到目的必须执行的行动
      - 信息系统对于一个事件的反应
      - 信息系统的谋略

    . 事件
      - 在特定时间发生的事情
   
  〖商业目标和谋略, 信息系统目标和谋略及其过程〗

    . 服务 = 信息系统的谋略 --< 支持 >-- 信息系统目标 --< 支持 >-- 商业谋略 --< 支持 >-- 商业目标 --< 支持 >--公司的总体目的和使命

    . 商业谋略
      - 公司认为达到公司目标必须的方法和途径
      - 公司处理内部某些活动的一套规则

    . 过程
      - 执行谋略或完成任务的逐步执行的指示
      - 事件出现的反应步骤

    一旦决定了谋略和过程, 就成为信息系统目标的基础.

  〖服务类型〗

    . 所有类的基本服务
    . 依赖于问题域特定功能需求的服务

  〖基本服务〗

    特点: 
    . 基本服务经常不列在类符号的服务部分, 以使符号更简单
    . 基本服务是隐藏的, 并且对于每一个类自动存在
    . 基本服务的维护对象就是类本身和具体的商业问题域无关

    操作:
    . 创建/删除/查找对象
    . 获得和设置对象属性值
    . 添加和删除对象联结


  〖特定功能服务〗

    特点:
    . 服务在问题域和其中定义的类独有
    . 可以自由创建符合问题域需要的服务, 即服务应该完成特定的任务
    
    处理复杂性原则:
    . 信息隐藏(包装)原则, 即一个服务应该执行一个或者多个连续功能
    . 复用原则, 功能也是一致, 复用的可能性越大

    交互:
    . 一个服务经常要求信息系统中的同类或者不同类的对象提供服务支持
    . 在请求/响应过程中, 发出请求的服务称之为发送方服务, 接受请求的服务称之为接收方服务
    . 接收方服务有时需要进行处理并且返回结果, 但不是必须, 这提供了并行处理的可能, 只要对于处理问题域具有意义

  〖寻找和表示服务〗

    背景:
    . 寻找和表示服务因为至今没有成为一门专门研究的科学, 因此需要借助多种经验方法

    方法:
    . 事件角度
      - 事件贯串于寻找类, 寻找和表示模式, 寻找和表示属性等活动的前,中,后各个阶段
      - 使表示服务的最合适起点

    . 状态角度
      - 为了维护属性及其状态, 需要提供相应的服务

    . 消息角度
      - 消息是从发送服务向接收服务发出的执行服务请求
      - 所需的服务就是消息的名称

    . 服务细节
      - 服务细节就是针对服务之间协作关系寻找依赖性的其他服务及其所属类

    一般过程:
    . 罗列服务和事件
    . 为服务寻找原始类



  7.2 服务细节

  〖目的〗

    - 研究服务细节即逐步执行的行动细节是服务为了完整责任必须进行的行动
    - 分析阶段说明的细节应该足够详细


  〖记录和秘书服务细节的技术〗
    
    - 场景
    - 结构化英语或伪代码
    - 判定表和判定树
    - 状态转换图


  〖场景〗

    - 定义
      对象交互的特定时序, 完成信息系统的某个需要. 通常以人机交互(HI)开始或者结束, 便于开始和结束.
      因为场景表示的是一个类的服务与同类或者不同类的其他服务之间的相互关系, 因此对象模型的任何给定场景视图都比较复杂和庞大.

    - 组成
      发送方类和服务 + 接收方类和服务 + 激活服务的参数和数目


  〖结构化英语或者伪代码〗
    
    - 定义
      是英语的一种精简和面向行动的版本, 没有标准的方法, 重点是简洁
    
    - 使用原因
      <1> 与面向对象用户需求模型一样, 是系统分析员和用户之间的一个强有力的交流工具
      <2> 具体细节在项目早期应该尽量和运行无关, 在设计时根据运行硬件和软件平台的需要添加与运行有关的细节

  
  〖判定表〗

    - 目的
      针对服务内的判定情况十分复杂, 单靠结构化英语无法理解
    
    - 可以说明如下问题
      因为判定树和判定表从排列组合的角度看待由条件和规则得到的行动, 为此可以说明如下问题
      <1> 条件遗漏    <2> 条件冲突    <3> 遗漏行动
    
    - 判定表
      < 组成 >
        条件[秘书影响谋略或情况的因素或条件]
        行动[通过行动语句描述可能发生的行动或判定]
        规则[描述对于一个条件的集合采取什么样的行动]
      
      < 创建步骤 >
        1) 找到处理的特定谋略或者程序的所有条件
        2) 找到每一个条件的所有值
        3) 把每一个条件的可能值的个数相乘, 计算判定表的规则(列)的数目
        4) 找到谋略或程序采取的行动
        5) 建立规则表, 填入条件和行动, 即表中的行
        6) 建立规则列, 连续标号, 规则列总数由步骤3)决定
        7) 在每条规则下列出所有的条件组合
        8) 检查每个规则列的条件值, 在与该条件和值得组合有关的行动上做标记
        9) 找到遗漏条件, 遗漏行动和矛盾的或模糊的条件
        10)将步骤9)结果与用户讨论, 并修改判定表
      
      < 相关概念 >
        1) 条件
           条件通常是一个判词
        2) 条件值
           即对应条件的逻辑或者数字等类型的值

      < 相关技巧 >
        1) 取条件
           对于互斥的条件可以合并
        2) 寻找缺失的条件, 缺失的行动, 冲突或者含混的条件
           - 相同行动
	 - 除了一个条件外, 所有都具有相同的值
	 - 具有不同值得条件表示该条件的所有可能值


  〖判定树〗

      < 说明 >
        比较适合初学者的一种逻辑判定方式. 和判定表只是方式不同.

      < 概念 >
        中间节点 - 条件或者条件值, 而且按照层次深入的特点 --  下层中间节点就是上层节点值的逻辑推理结果
        叶子节点 - 判定点即行动


  〖状态转换图〗

      < 用途 >
        某些问题域和服务使用状态转换图有效地表达服务, 服务的一部分和服务之间交互的细节.

      < 适用 >
        表示具有时间性质的行为部件的信息系统的一部分, 实时系统

      < 符号 >
        方框 - 状态
        箭头 - 条件-行动, 同时需要附加描述
        

  〖把服务赋予类和消息联结〗

    如何把服务赋予类:
    - 根据服务名称找到所属类
    - 根据问题域的真实世界的具体人, 地点和事物, 考虑这些服务自然属于某个类以更好的表达真实世界
    - 根据服务所操作的类属性找到所属类

    添加服务细节和支持服务:


  〖从系统分析转入系统设计〗

    分析阶段的系统模型将进入设计阶段, 得到增强和扩展, 并且随着项目从设计进入实现, 也会加入其他类, 模式, 属性和服务.


【本章习题】

  01. 定义面向对象编程的服务
  答: 信息系统为达到目的必须执行的行动, 也可以看出时信息系统对于一个事件的反应.

  02. 服务怎样与商业和信息系统的目标和谋略联系在一起
  答: 服务是信息系统的谋略, 支持信息系统目标. 而信息系统目标支持商业谋略, 商业谋略支持商业目标, 最后商业目标支持公司的总体目的和使命.

  03. 科德面向对象方法论的两种服务是什么?
  答: 基本服务和特定问题域的服务

  04. 列出并简要描述基本服务
  答: 基本服务就是为每一个类/对象类拥有的服务, 一般在图中不列出, 因为何信息系统的谋略无关, 是支持面向对象机制的. 基本服务一般包括: 长剑和删除对象, 查找, 获得和设置属性质, 添加和删除对象联结. 基本服务是处理对象, 对象联结合对象属性值得实际服务.

  05. 定义每种基本服务并举例
  答: 基本服务如下:
      创建对象服务		- 在类中长剑新的对象, 允许类创建新的对象实例
      查找服务		- 在类中查找特定对象
      获取和设置属性服务	- 取得设置属性和属性值
      添加和删除服务	- 添加联结用于把对象联系起来, 删除联结服务把对象互相分开
      删除对象服务		- 按照要求从类中删除对象

  06. 定义问题域特定服务并举例
  答: 问题域特定服务是问题域和其中定义的类独有的, 可以自由创建问题域需要的服务, 服务应该完成具体任务, 应该遵从处理复杂性的信息隐藏(封装)原则, 即一个服务应该执行一个或者几个更多连续功能. 一个服务经常要求信息系统中同类和不同类的其他服务的支持.

  07. 讨论类似劳动分工性质的服务特点
  答: 劳动分工性质的服务特点就是每一个服务完成特定的任务部分, 各个服务组合起来完成一个整体任务. 为此各个服务互相联系, 互为补充. 遵从复杂性处理原则, 可以互相通讯(发送方/接收方服务)和功能复用; 或者并行处理问题.

  08. 简要描述识别服务的技术
  答: 识别服务技术如下
      - 标识事件和相关服务
        可能是标识服务的最合适起点. 事件说到底是问题域中发生的能够被用户确认得事件, 该方法非常符合面向对象方法论. 而且事件在寻找类, 标识模式, 标识属性等面向对象任务之前, 之中, 之后都可以进行.
      - 标识要求的消息
        消息就是对象交互的方式, 通常可以得到发送方服务和接收方服务
      - 标识类的状态
        一般修改类的状态的就是类本身的服务, 这符合处理复杂性的消息封装原理
      - 说明服务的细节
        因为服务细节说明会发现完成任务的服务需要得到同类或不同类的其他服务的支持, 这时, 可能会发现其他支持服务, 这些服务添加到模型中支持其他服务.

  09. 通过说明服务细节来识别服务时, "走一遍"过程是什么意思? 这个活动能够得到什么?
  答: 即用户按照定义的步骤"走一遍"每一个用户定义的服务, 用户应该感觉到, 每一个服务能够完成指定功能, 是一个很好的检查和验证步骤, 属于需求决定活动的需求确认部分.

  10. 说明服务细节时, "书面语言"文档存在什么问题?
  答: 表意不规范, 不明确, 不简洁; 无法应用基本的逻辑控制流程.

  11. 定义服务场景, 并举例
  答: 服务场景是对象交互的特定时序, 完成信息系统的某个需要. 场景由对象模型中的场景试图协助开发. 举例如下: 
      节目编排场景就是获得节目列表, 按照播出时间编排, 检查编排, 确定编排.

  12. 使用结构化英语(伪码)描述服务细节有什么优势?
  答: 简洁, 而符合逻辑流程控制原理, 易于理解.

  13. 讨论判定表和判定树能够减轻的使用结构化英语带来的问题
  答: 遗漏条件, 冲突条件, 遗漏行动. 根本语言就是伪码仅仅涉及的逻辑控制不包含对于条件, 规则和行动的排列组合等判定.

  14. 创建判定表时, 怎样处理重复行动?
  答: 合并.

  15. 在什么情况下使用状态转换图?
  答: 表示具有时间性质的行为部件的信息系统的一部分.

  16. 定义并表示消息
  答: 消息是从发送方服务向接收方服务发出的执行服务请求.

  17. 消息的3个部分是什么? 它怎样联系?
  答: 发送方服务, 接收方服务, 请求参数. 发送方服务向接收方服务发送附带执行请求参数的消息, 接收方处理以后可以选择返回或者不返回.