学习笔记---UML（二）

1 OOAD详解

1.1 uml工具

    staruml，小巧，用的比较多，还有一款类似的软件，叫jude，用的也比较多。

1.2 面向对象

• 面向对象是一种系统建模技术，Object-Orientation，简称OO。
• 面向对象编程是一种使用OO的方法学来开发程序的过程，Object-Orientation Programming，简称OOP。
• 通过分析系统内对象的交互来描述或建模一个系统。
• 交互的对象最终以类的形式组织。
• OO的方法由三部分组成：过程，标识，规则。

1.3 对象

• 是一个客观存在的、唯一的实体。
• 是OOP过程中分析与解决问题的出发点和基础。
• 拥有自己的标识、数据与 行为。
• 可以简单或复杂。
• 可以抽象或具体。
• 在OOP中是一个类的动态实例。

1.4 类

• 类是对象的模板。
• 对象通过类实例化产生。
• 一个类可以创建多个对象。

1.5 OOAD

• Object-Orientation Analysis and Design，是根据OO的方法学，对软件进行分析和设计的过程。
• OOA，分析阶段。
• OOD，设计阶段。
• 理想的，实际中往往需要反复去做。

1.5.1 OOA阶段

• 分析阶段主要解决一下问题：

　　　　① 建立针对业务问题域的清晰视图。

　　　　② 列出系统必须要完成的核心任务。

　　　　③ 针对问题域建立公共词汇表。

　　　　④ 列出针对此问题域的最佳解决方案。

• 此阶段要解决的核心问题是：What to do？

1.5.2 OOD阶段

• 设计阶段主要解决一下问题：

　　　　① 如何解决具体的业务问题。

　　　　② 引入系统工作所需的支持元素。

　　　　③ 定义系统的实现策略。

• 此阶段解决的核心问题是：How to do？

1.6 OOP的主要特征

• 抽象 abstract
• 封装 encapsulation
• 继承 inheritance
• 多态 polymorphism
• 关联 association
• 聚合 aggregation
• 组合 composition
• 内聚与耦合 cohesion and coupling

1.6.1 抽象

• 忽略掉一个对象或实体的细节而只关注其本质特征的过程。
• 简化功能与格式。
• 帮助用户与对象交互。

1.6.2 封装

• 隐藏数据和实现。
• 提供公共的方法供用户调用功能。
• 对象的两种视图：

　　　　外部视图：对象能做的工作。

　　　　内部视图：对象如何完成工作。

1.6.3 继承

• 通过存在的类型定义新类型的机制。
• 通常在两个类型之间存在 is a 或 kind of 这样的关系。
• 通过继承可以实现代码的重用，另外继承也是多态的基础。

1.6.4 多态

• 一个名称，多种形式。
• 基于继承的多态。
• 调用方法时根据所给对象的不同选择不同的处理方式。

1.6.5 关联

• 对象之间交互时的一种引用方式。
• 当一个对象通过对另一个对象的引用去使用另一个对象的服务或操作时，两个对象之间就产生了关联。

1.6.6 聚合

• 关联关系的一种，一个对象成为另一个对象的组成部分。
• 是一种较强的关联。
• 两个对象之间存在 has a 这样的关系，一个对象作为另一个对象的属性存在，在外部对象产生时，可由客户端指定与其关联的内部对象。

1.6.7 组合

• 当一个对象包含另一个对象时，外部对象负责管理内部对象的生命周期的情况。
• 关联关系中最为强烈的一种。
• 内部对象的创建由外部对象自己控制。
• 外部对象不存在时，内部对象也不能存在。

1.7 域模型

• 域模型是面向对象的，在面向对象术语中域模型也可以成为设计模型。
• 域模型由一下内容组成：

　　　　① 具有状态和行为的与对象。

　　　　② 域对象之间的关系：

• 关联 Association，
• 依赖 Dependency，
• 聚集 Aggregation，
• 一般化（泛化）Generalization

1.7.1 关联关系

• 一对多和多对一本质是一样的，只是参照不一样。
• 一对一，如人与身份证。
• 多对多，如学生与课程。

1.7.2 依赖

• 在BusinessService中访问Customer类的方法，并且构造Customer类的对象。

1.7.3 聚集

• 聚集指的是整体与部分之间的关系，在实体域对象之间很常见。

1.7.4 泛化

• 泛化指的是类之间的继承关系。

1.8 内聚与耦合

• 内聚：度量一个类独立完成某项工作的能力。
• 耦合：度量系统内或系统之间依赖关系的复杂度。
• 设计原则：高内聚、低耦合

1.9 开发过程概述

• 传统开发过程：瀑布模型
• 统一软件开发过程（USDP）

1.10 OOAD开发过程

• 大项目分解为一些子项目。
• 使用UML工具。
• 统一软件开发过程是一个迭代的、递增的开发过程。

1.10.1 迭代、递增项目生命周期

• 项目是迭代、递增的。
• 迭代指生命周期中的一个步骤。
• 迭代导致“递增”或者整个项目的增长。
• 大项目分解为子项目。
• 在每一个迭代的阶段，应该做以下工作：

　　　　① 选择并分析相关用例

　　　　② 根据所选架构进行设计

　　　　③ 在组件层次实现设计

　　　　④ 验证组件满足用例的需要

• 当一次迭代满足目标后，开发进入下一个迭代周期。

 

• Inception --- start up
• Elaboration --- refine
• Construction --- implement
• Transition --- promotion

 

• 每一个周期包含一次或多次迭代。
• 一个阶段的结束称之为里程碑（milestone）。

过程图：

 

1.10.2 初始化阶段

• 该阶段的增量集中于：

　　　　① 项目启动

　　　　② 建立业务模型

　　　　③ 定义业务问题域

　　　　④ 找出主要风险因素

　　　　⑤ 定义项目需求的外延

　　　　⑥ 创建业务问题域的相关说明文档

1.10.3 细化阶段

• 本阶段的增量集中于：

　　　　① 高层的分析与设计

　　　　② 建立项目的基础框架

　　　　③ 监督主要的风险因素

　　　　④ 制定达成项目目标的创建计划

1.10.4 构建阶段

• 本阶段的主要增量集中于：代码及功能的实现

1.10.5 移交阶段

• 本阶段的增量主要集中于：

　　　　① 向用户发布产品

　　　　② beta测试（alpha测试是内部测试，beta测试是用户测试）

　　　　③ 执行性能调优，用户培训和接受测试（对于性能问题，我们开发项目时经常会遇到一个性能瓶颈，但是，项目开始时没有必要就一直挂念性能问题，性能应该是在后阶段考虑的，如果一开始就把性能当做一个重要指标，会影响开发进度，也许一开始考虑的性能问题根本不存在，性能的调优是一个很深的学问，应该是根据大量测试和数据说话，只根据经验或者是查看代码是不靠谱的）

1.10.6 迭代工作流

• 每一次递增都由5部分工作流组成：

　　　　① 需求与初始分析

　　　　② 分析

　　　　③ 设计

　　　　④ 实现

　　　　⑤ 测试

• 每一次迭代执行工作流的深度不同
• 早期的迭代在深度上覆盖初始工作流，后期迭代在深度上覆盖后期工作流。
• 80/20原则

迭代工作流：

 

1.10.7 迭代、递增优势

• 降低成本
• 便于更好的维护项目进度
• 便于团队的协作开发
• 便于适应用户需求的动态变化