OOAD(Object-Oriented Analysis and Design)介绍

OOAD方法论的定义:
 
   1) 面向对象是一种系统建模技术;
   2) 将系统描述为许多相互作用的有关系对象;
   3) 系统中相互作用的对象被组织成类;
   4) OO方法论由以下三部分组成：
      . 一个过程
      . 一个符号
      . 一系列规则

在一个OOAD软件开发过程，我们要完成二个不同的工作：
   1) 分析阶段我们主要： （要做什么？what to do?）
      . 建立一个清晰的商业问题的视图;
      . 概述系统必须执行的任务;
      . 建立商业问题描述的通用词汇;
      . 概述商业问题的最佳方案。
   2) 设计阶段我们主要：（怎么做？how to do?）
      . 解决商业问题;
      . 定义“how”代替“what”;
      . 介绍将使系统工作的支撑元素;
      . 定义系统的实现策略。

对象
   1) 是单个的、唯一确认的实体或项目;
   2) 作为面向对象的构建块被使用;
   3) 有身份、数据和行为;
   4) 可以是简单或复杂的;
   5) 可以是真实或想象的;
   6) 有属性和操作;
   7) 是一个类的动态实例;

类 ，多个相同对象的一种抽象，多个对象共性的抽取，对象都创建自类

面向对象编程的特征  (OOA,OOD,OOP)
   1) Abstraction(抽象):
      . 忽略细节，处理对象或实体本质的特征，抽取共性;
      . 简化功能以及信息;
      . 帮助用户和对象交互;
   2) Encapsulation(封装):
      . 控制对象的边界；
      . 控制对象对外的借口；
      . 隐藏对象的数据;
      . 处理每个对象的二种视图：
        a. 外部视图：显示一个对象做什么;
        b. 内部视图：显示对象如何完成它的任务;
   3) Association(关联)
      . 对象间交互的方式;
      . 对象间相互使用其功能;
      . 一个对象使用另一个对象的服务或操作另一个对象，这时候对象相互关联。
      . 一个对象通过另外一对象的引用来访问这个对象。（对象间的引用）
   4) Aggregation(聚合)
      . 定义一个对象是另一个对象的一个组成部分;
      . 是一种比较强的关联;
      . 一个对象是另外一个对象的组成部分（特殊的关联）。
      . 通过“Has A”关系可进行确认。一辆车有轮子、座椅以及门，它们是一部车的组成部分。假如你移除其间的任何一部分，车没有了相应的功能，但仍是一部车。
   5) Composition(合成)
      . 一个对象包含另一个对象（has a的关系）;
      . 是最强的关联形式;
      . 外部对象全程负责内部对象的生命周期（特殊的聚合）
      . 通过“contain”关系可进行确认。
      . 假设部件不存在，对象亦不存在。
   6) Inheritance(继承)
      . 是一种根据既存类定义新类的机制;
      . 通过“Is A”或者“Kind of”关系可进行确认;
      . 允许你组织相关类，这样这些类可共同地被管理以及重用。
   7) Cohesion(内聚)和Coupling(耦合)
      . 组件之间依赖关系的度量;
      . 内聚: 一个组件独立完成工作的能力;
      . 耦合: 组件之间依赖关系的度量;
      . 系统的耦合性越小越好，系统的内聚性越高越好。
   8)Polymorphism(多态)
      . 一种行为在不同的环境下所变现出来不同的行为；
      . 不同对象完成相同语义上的结果;
      . 基于继承或实现;
      . 多态功能的实现依赖于它应用的对象;
      . 举例：足球-扔-需二只手、网球-扔-只需一只手，同样是扔，有不同的实现。当你将不同的球给一个小孩子，他知道是用一只手还是二只手。小孩都知道多态。

开发过程，软件开发过程的控制。
   1) 传统开发过程：
      . 瀑布式开发：需求->分析->设计->实现->测试。每个步骤完成和文档化后才进入下一个阶段。
      . 假设在后期阶段出现问题，很难返回到先前阶段。
      . 项目组成员花费大量时间和精力于每个阶段确保它是正确的.
      . 各阶段所用符号和术语均是变化的。完成的软件虽然正确，但与它所表现的商业逻辑相关甚少。
   2) OOAD开发过程
      . 典型的处理方式是将一个项目作为一系列的小项目;
      . UML(Unified Modeling Language)是一种符号，不是一个处理过程;
      . USDP(Unified Software Development Process)是迭代增量式的;
    初启->细化->构建->移交，每个阶段都有特定的目标
      . USDP和RUP(Rational Unified Process)都是流行的OOAD过程。

迭代增量式项目生命周期
   1) “迭代”指生命周期中每一个步骤;
   2) 迭代的结果便是整个项目功能完成的一步步增长;
   3) 在每个迭代的构建阶段，你应该：
      . 选择并分析相关的用例;
      . 使用选择的体系结构创建一个设计;
      . 用组件实现设计;
      . 检验组件满足用例。

迭代增量生命周期的主要阶段
   1) Inception(开始)阶段：
      . 这个阶段的增长集中在：
        a. 开始项目;
        b. 为这个项目建立起商业原则;
        c. 定义一个商业问题;
        d. 识别潜在的风险;
        e. 定义对问题更好理解的范围;
        f. 创建对商业问题的解释文档。
      . 每个循环包括一至多个反复，每个阶段的完成结果都是里程碑式的。
   2) Elaboration(细节)阶段：
      . 这个阶段的增长集中在：
        a. 高水平的分析和设计;
        b. 为项目建立一个架构体系的基线;
        c. 监测潜在的风险;
        d. 创建一个实现项目目标的构建计划;
   3) The Construction(构建)阶段：
      . 这个阶段的增长集中在软件项目日益成型;
   4) The Transition(跃迁)阶段:
      . 这个阶段的增长集中在:
        a. 发布产品给客户;
        b. 完成beta测试;
        c. 实现性能调整、用户培训以及接受度测试。

阶段期间的工作步骤
   1) 每个阶段由以下五个工作步骤组成：
      . 需求
      . 分析
      . 设计
      . 实现
      . 测试
   2) 不同的反复对每个工作步骤完成的程度不同;
   3) 早期的反复在深度上覆盖了第一个工作步骤，以后的反复在深度上覆盖了最后的工作步骤。
   4) 8/2原则：假如完成了80%, 即可进入下一个反复。

反复和工作步骤
   1) 在每个反复过程，根据需求你可以包括五个工作步骤中的任何一个。
   2) 早期的反复过程集中在靠前的工作步骤，后期的反复过程集中在靠后的工作步骤。
   3) 当你发现应该修改早先工作步骤中的某些错误，你可以：
      . 继续并在下一个反复过程中修正;
      . 继续并增加一个新的反复过程修正问题;
      . 假如时间允许，返回到当前的反复并修正这个问题。
   4) 不同的反复执行每个工作步骤于不同的程度。

迭代增量生命周期的好处
   1) 错误提早发现，降低成本;
   2) 对项目进度的更好保证;
   3) 对于开发团队而言开发速度更快;
   4) 便于适应用户需求的动态改变;

UML(Unified Modeling Language,统一的建模语言)介绍

UML定义 ：图形化的建模语言

   1) UML是一种图形化语言用于：
      . 说明;
      . 构建;
      . 肉眼观察;
      . 文档化系统原型;
   2) 在分析阶段，你创建类图以帮助你理解商业概念(还没有实现的细节);
   3) 在构建阶段，我们通过为相同的类图增加附加的细节——实现商业细节;

UML和蓝图的关系
开发OOAD程序——UML（程序的结构），蓝图——整体的规划

UML图形类型
   1) 静态模型：代表你正在建模的软件系统的基本结构;
   2) 动态模型：强调了系统的行为;

静态模型
   1) 构建以及文档化一个系统的静态方面;
   2) 反映了一个软件系统基本的、稳定的框架;
   3) 创建问题主要元素的代表;
   4) 由以下图形组成：
      . 用例图
      . 类图
      . 对象图
      . 组件以及部署图

动态图
   1) 构建显示系统行为的图形;
   2) 由以下图形组成：
      . 时序图
      . 协作图
      . 状态图
      . 活动图

用例图 ：表示系统的功能，用户和系统之间的交互关系
   1) 显示谁或什么使用系统以及它的特征;
   2) 一个用例图中特征的用户称为“actors”;
   3) 用例用椭圆表示;
   4) 为使建模容易，用例图需区分先后顺序;
用例：表示系统功能的部分

类图：表示类之间的关系，和类的信息
   1) 代表一系列包含普通属性和特征的对象;
   2) 结构化的图形显示了一系列的类、接口、对象间的协作以及关系;
   3) 由一至多个描述了以下信息的矩形组成：
      . 类型(类名)
      . 可选择的属性
      . 操作部分
    private用"-"表示，public用"+"表示，protected用"#"表示，defult不用加符号。
    抽象类，抽象方法的方法名用斜体字表示。
    ________________
       |     class      |
       |________________|
       |    age:int     |
       |______属性______|
       | +getAge():int  |
       |______方法______|

对象图 ：表示对象关系的，对象的信息。
   1) 代表一个明确的对象
   2) 结构化的图形显示了一系列对象以及他们之间的关系
         ______________
        |    gergo:    |
        |______________|
        |    Person    |
        |____类型名____|
    |初始化属性的值|

组件图 ，显示软件组件间的关系 ，组件，是功能相同或相近的类组成的。

部署图 ，显示能用于部署软件应用程序的物理设备 ，表示物理设备的关系，网络的拓扑结构，以及物理设备上部署的软件，以及物理设备节点间信息交换的协议。

时序图：在时间上，表示系统组件或对象间相互调用或是相互发送信息的顺序。（表示单个用例的流程，或是详细的组件间、对象间的发送信息的顺序）。
   1) 不同对象一定时间范围发生的消息;
   2) 强调消息或组件间的调用的时间顺序

协作图 ：和时序图的逻辑一致，它主要表示组件或对象间的调用关系，可以清晰分辨系统的组织结构。
   1) 显示了使用消息期间对象间的协作;
   2) 强调发送和接收消息的结构化组织;

状态转换图 ，强调对象行为的事件顺序，主要是对对象状态进行描述，也可以在对象状态间加上状态转换条件 。

活动图：描述用例的流程
   1) 描述一项活动到另外一项间的流程
   2) 强调一项活动到另外一项间的流程

包的符号（包图）
   1) 指组织项目的一种方式
   2) 通常用于控制类的名域空间
   3) 在UML中使用包组织类、软件组件、硬件组件、其它包以及和你模型相关的任何其它东西

需求和初始化分析

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

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

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

问题声明
   1) 文档清楚地描述了客户和系统需求吗？
   2) 用户输入对于文档很重要
   3) 使用客户熟悉的语言词汇
   4) 句义清楚，不用行话
   5) 函盖项目范围内的细节
   6) 详细说明问题的背景
   7) 详细说明所知的约束
   问题声明提供了关于商业背景、范围以及计算机术语无关方面的约束。它用于作为确认问题范围的基础。
 
对象和类的侯选值
   1) 可从问题声明中确定
   2) 给问题声明中的名词短语加下划线以建设对象和类侯选值列表
   3) 在接下去的分析阶段，你需要确定你系统中所需的对象和类的列表

数据字典
   1) 描述了用于项目所有词汇的文档
   2) 通过和用户沟通积累所得的条款
   3) 用于整个项目和系统
   4) 在整个项目期间会不断地加入新的术语
   5) 帮助消除歧义
   6) 必须对所有项目组成员可用
   7) 数据字典对于大型项目中各团队沟通非常重要。这时，它既是商业文档也是系统文档。

创建用例
   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) 在设计阶段存在的属性和方法足够了，但是他们的类型和参数还不够。

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