面向对象设计第四话

四、需求和初始化分析
1、开始开发过程
   1) 分析最初的工作流;
   2) 收集信息;
   3) 创建一个问题的状态;
   4) 创建用例;
   5) 引介组件以及部署图;

2、收集信息
（1）你可从许多资源中收集信息，这些资源包括：
   . 用户的初始化需求详情 （需求说明书）
   . 顾客和用户 （需求会议）
   . 客户的管理人员
   . 市场信息
   . 以前类似项目的经验
   . 领域专家

（2）避免习惯性的假设
    你必须避免习惯性的假设，包括：
      . 用户是天真的，开发者最清楚
      . 需求是静态的
      . 一开始便能建立正确的方案
    记住项目的发展以及客户的需求均是变化的。
    为了避免这些假设，我们应该：
      . 明确用户的需求
      . 确保你的模型能适应不断变化的需求
      . 确保你能修改你的模型
   
（3）行业专家
    指某个特定商业领域的专家
    可大致细分为：
      . 行业专家
      . 特定应用程序行业专家以及当前商业领域专家
      . 相关业务领域专家
    没有行业专家，从其它领域抽象通用元素很困难

（4）问题声明
   1) 文档清楚地描述了客户和系统需求吗？
   2) 用户输入对于文档很重要
   3) 使用客户熟悉的语言词汇
   4) 句义清楚，不用行话
   5) 函盖项目范围内的细节
   6) 详细说明问题的背景
   7) 详细说明所知的约束
   问题声明提供了关于商业背景、范围以及计算机术语无关方面的约束。它用于作为确认问题范围的基础。

（5）对象和类的侯选值
   1) 可从问题声明中确定
   2) 给问题声明中的名词短语加下划线以建设对象和类侯选值列表
   3) 在接下去的分析阶段，你需要确定你系统中所需的对象和类的列表

（6）数据字典
   1) 描述了用于项目所有词汇的文档
   2) 通过和用户沟通积累所得的条款
   3) 用于整个项目和系统
   4) 在整个项目期间会不断地加入新的术语
   5) 帮助消除歧义
   6) 必须对所有项目组成员可用
   7) 数据字典对于大型项目中各团队沟通非常重要。这时，它既是商业文档也是系统文档。
  
3、创建用例
   1) 一个用例是用户和系统交互的图形化的表现形式;
   2) 是定义和理解系统需求和背景的工具;
   3) 是任何系统某一方面的简单印象。当你将所有印象收集在一块，你便拥有了系统的整个描述;
   4) 图形具体表现为实线的椭圆。

用例场景，用例场景中不包括条件，同一出发点，但有不同结果。

用例图中的“include”和“extend”
   1) “include”集中于包含关系，完成某个模块之前，你必须使用另一个模块;
   2) “extend”集中于扩展关系，也许或也许不基于某个模块，不是强制性的;

用例中的情节假设
   1) 用例从用户的角度显示了软件的功能。也许存在超过一种方式完成一指定功能。
   2) 一个假设情节指用例的一个实例——从开始到结束的一个逻辑路径。
   3) 情节假设不包括有条件的声明——因为它们描述了用户多个可能路径中的一种。
   4) 所有的情节假设从相同的方式开始，但结果却不同。
   5) 一个用例中成功或不成功的路径都应该显示出来——在一个ATM中，你必须考虑一些情节诸如用户个人身份号码输入不对或者金额不足。

用例表单
   1) 每个用例的摘要
   2) 用例表单不是UML的内容，但是建议完成它。
   3) 在这个表单中，包括以下项目：
      . 用例名称
      . 参与者
      . 优先权
      . 状态
      . 扩展内容部分
      . 预处理/假想情节
      . 提交条件
      . 事件流
      . 可选路径
      . 执行
      . 频率

活动图
   1) 创建用例图后，你可以使用图形说明活动或工作流
   2) 图形化了所有用例假想情节
   3) 显示活动、过程或工作流

风险评估和管理
   1) 有必要对项目进行风险评估
   2) 用例可以是风险评估的起点
   3) 高风险的用例应该在早期的迭代中开发
   4) 风险能出现在以下方面：
      . 需求风险
      . 技术风险
      . 技能风险
      . 资源风险
      . 政策风险     
     
需求风险
   1) 需求风险指没完全满足客户需求
   2) 你应该使工作于该系统的所有用户和管理者都参与进来

技术风险 ,记住已证实过的技术比未证实的技术所冒风险要小

技能风险 ,确信你有所需的全部技能

资源和政策风险
   1) 资源风险指超出时间和资金预算
   2) 政治风险指与现行的政治规则冲突

包图
   1) UML中存在符号以包装任何逻辑相关的UML元素(类、对象、用例等等);
   2) 就像Java一样，相关的类组织成不同的包;
   3) 这个符号像文件夹图标;
   4) 有助于降低复杂性;
   5) 包间可存在依赖关系;
   6) 包有助于：
      . 查看没有太多细节的大图;
      . 查看独立的小部分;
      . 创建部件中的一小部分;
      . 显示组件间的依赖性;
      . 组件图显示了代码物理组织形式，可以是一个类文件、Java源文件、jar文件、Java中的包、共享库、对象代码、RDB等等;
      . 当一个组件改变，它能影响其它——依赖性;
      . 组件应该有一个良好的接口，这样你可以使用其它实现该接口的组件去替换它。

部署图介绍
   1) 显示了硬件组件间的物理关系;
   2) 每个符号代表了一些硬件设备：服务器、工作站、个人PC、传感器、时钟、电话交换机等。
   3) 当你获得信息的时候可在任何阶段添加以及修正。
   4) 符号间的连接伴随着协议一起显示。

系统对象和类分析

分析阶段的理解
   1) 定义系统必须做什么;
   2) 避免描述和实现的问题;
   3) 专注于系统的组件;
   4) 分析阶段确定对象在运行时需要什么以确保系统正确的功能;
   5) 分析阶段在需求收集阶段和用例阶段之后，在系统设计阶段之前;
   6) 在确定哪些是类和对象的时候，你应该回答以下问题：
      . 什么对象组成了这个系统?
      . 什么是可能的类?
      . 每个对象或类的责任是什么？
      . 对象和类间是如何相联系的？
   7) 记住将所有新项目加入数据字典;

关键字的提取
   1) 当你定义组成系统的对象时，你应该创建一个满足系统功能对象的列表;
   2) 列表中的对象称为对象侯选值;
   3) 然后你可以为这个列表中最重要的对象准备一个子列表;
   4) 关键字代表了系统中主要或第一位的对象;

用UML表示对象和类
   1) 对象模型显示了逻辑和特理的静态视图;
   2) 对象模型有二种图：
      . 类图：显示了你必须创建一个系统所需的类。在运行时你可使用一个类创建许多对象。类图必须显示类间所有可能关系。
      . 对象图：代表了系统中真实的对象，描述了特定案例中外在关系。
   3) 你可以使用主键去创建类图和对象图。
   4) 类图在整个分析阶段都会被更新和修正。

属性和方法
   1) 对象包含了定义对象状态的属性;
   2) 方法定义了对象能执行的操作;
   3) 因此类必须定义这些属性和方法;
   4) 在类执行之前，你必须定义所有的属性和方法;
   5) 但是很多属性和方法到设计阶段才知道，加上所有你能加的先;
   6) 在设计阶段存在的属性和方法足够了，但是他们的类型和参数还不够。

属性和方法
二种类型的属性:
   . 普通属性：是一个类中固有的属性。一个普通属性将会存储对象中一些有意义的值。
   . 推导属性：可以通过类中其它属性推导得出。