1. UML基础

1.1 UML简介

1.1.2 UML背景

1970年期间，面向对象方法出现，1989-1994得 到大发展。不同的方法大发展，触使建立一个标准的、统一的建模语言。

1990年代，3个最流行的面向对象方法：++OMT(强分析弱设计)、Booch(强设计弱分析)、OOSE(强分析弱其它)++。

++统一建模语言UML (Unified Modeling Language)的出现++结束了符号方面的”方法大战“。UML统一了Booch、OMT、OOSE方法的符号，并采纳了其他面向对象方法的许多好概念。

1.1.2 UML发展

1.1.3 UML内容(定义,重要)

1. 元数据(描述数据的数据)
2. 语义(元模型的定义)
3. 表示法(UML符号表示方法)

适用范围(重要)

Unified Modeling Language (UML)又称统一建模语言或标准建模语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。

UML元数据(重要)

概念理解

1. 描述数据的数据，是一种抽象；
2. 描述数据的含义和性质，以便更好地理解、管理和使用数据的数据。

示例

数据：图书馆中的书籍

元数据：标题、作者、关键词、ISBN号

UML语义(重要)

UML语义给出了基于UML的精确的元模型定义。元模型为UML的所有元素在语法和语义上提供简单、一致、通用的定义性说明，使开发者在语义上取得一致。支持元模型的扩充定义。

UML表示法(重要)

UML表示法定义了UML符号的表示方法，为系统建模提供标准。表达应用级的模型，在语义上是UML元模型的实例。

1.1.4 UML主要特点

1. UML统一了Booch、OMT、OOSE和其他面向对象方法的基本概念和符号。
2. UML是一种先进实用的标准建模语言，其发展存在着一个进化过程。
3. UML是一种建模语言而不是一种方法。UML独立于过程，用户根据不同的需要选用不同的过程。UML是一种语言，独立于过程，最好应用于用例驱动的、以体系结构为中心的、迭代的、递增的过程。

1.1.5 UML功能(重要)

1. 为软件系统的产出建立可视化模型.利于交流、理解，系统结构直观、软件易维护。
2. 规约软件系统的产出.定义分析、设计和实现规格。
3. 构造软件系统的产出.支持模型到语言的前向工程，语言到模型的逆向工程。(是否支持软件的改进性、适用性与实用性？)
4. 为软件系统的产出建立文档.包括需求、体系结构、设计、源代码、项目计划、测试、原型、发布。(软件工程的全过程)

UML优点(重要)

1. UML具有定义良好的语义，不会引起歧义。
2. UML是可视化的建模语言，为系统提供了图形化的可视模型，使得系统的结构变得直观，易于理解。
3. 用UML为软件系统建模，不但利于交流，还有利于对软件的维护。

1.1.6 UML组成 (重要)

1. 元素
2. 关系
3. 图

元素(重要)

包括结构元素、行为元素、分组元素、注释元素。

1. 结构元素(静态)：类(Class)、接口(Interface) 、协作(Collaboration)、用例(UseCase) 、活动类(ActiveClass)、组件(Component)和节点(Node)。(协作实现用例)
2. 行为元素(动态)：交互作用和状态机。对象间交互：消息、动作序列、连接。
3. 分组元素(组织)：包。
4. 注释元素(解释)：注解。

关系(重要)

1. 依赖关系 (Dependency):调用关系，语义联系。
2. 关联关系 (Association):一对一，一对多，多对多。
3. 类属关系 (Generalization):类或对象间的继承和派生。
4. 实现关系 (Realization):接口与类。

图(重要)

1. 用例图：从用户角度描述系统功能(用户和操作)；
2. 静态图：描述类的静态结构，包括类图和对象图；
3. 行为图：描述系统的动态模型和系统对象间的交互关系，包括状态图和活动图；
4. 交互图：描述对象间的交互关系，包括时序图、协作图(信息交换，对象间的关系，对象组织)；
5. 实现图：描述代码组件的物理结构及各组件之间的依赖关系，包括组件图和配置图。

1.2 Rationa统一过程

1.2.1 RUP的发展(Rational Unified Process)

软件项目失败的原因(重要)

1. 混乱的需求管理(不要仅考虑新技术，更需考虑用户的实际要求，新旧技术的良好接口，合理地选择最合适的开发软硬件环境)；
2. 开发者之间以及开发者和用户不清晰的交流(没有统一标准，尤其是开发者和用户之间缺乏行之有效的沟通方式、手段)；
3. 架构不够坚固(与软件和硬件均有关系，尽可能地选择经过严格测试的工具进行开发，减少因开发平台不当造成开发失败的可能性)；
4. 没有发现需求、设计和实现中的不一致(硬件和软件两方面)；
5. 缺少有效的测试(单元测试、整体测试、用户测试、Beta发布测试，测试人员的素质不高，无实际开发经验无法做好测试工作，现代QoS测试贯穿于软件工程全过程)；
6. 对项目状态的主观估计(开发团队的经验，市场的正确估计，用户的充分参与，有效的单元测试与阶段性整体测试) ；
7. 没有正确地处理项目开发过程中的风险(风险预期不足，风险控制应对机制准备不足，技术储备不足，用户需求变化估计不足，市场变化估计不足，同类产品的发展估计不足，风险规避还是风险追求) ；
8. 没有对项目变更进行控制(严重影响软件开发质量和可维护性的一个因素，可能由开发人员流动产生，可能由用户需求变化产生，可能由市场变化产生，直接对项目文档变更造成重大困难，尤其是文档的实时行，内部环境变化) 。

1.2.2 什么是RUP

1. RUP是一个软件工程化过程。
2. RUP是由Rational软件公司开发和维护的过程产品。
3. RUP为如何有效地使用统一建模语言UML提供指导。
4. RUP说明了如何有效地使用成熟技术开发软件。
5. RUP是一个可配置的过程(软件可配置)。

1.2.3 过程概览(重要)

RUP的四个阶段(重要)

1.2.4 时间轴(各阶段工作,重要)

1. 起始阶段 (Inception)
2. 细化阶段 (Elaboration)
3. 构建阶段 (Construction)
4. 交付阶段 (Transition)

起始阶段

1. 明确说明项目规模，了解环境以及最重要的需求和约束(需求动态变化)，以便可以得出最终产品的验收标准；
2. 计划和准备商业理由，评估风险管理、人员配备、项目计划以及成本/进度/收益折衷的被选方案；
3. 综合考虑被选构架，评估构架；
4. 准备项目的环境(软硬件环境)，评估项目和组织，选择工具，决定流程中要改进的部分。(评估：风险、费用、人事、流程改进)

细化阶段

细化阶段的焦点是需求、分析和设计工作流。需求贯穿于软件工程全过程。

1. 标明用例模型中的用户和参与者，并且建立用例的描述文档，用例模型需完成80％；
2. 创建软件系统开发过程中的软件结构的描述文档(文档时间可能非常长，至数年)；
3. 创建可执行的系统原型(开发项目的积累) ；
4. 细化商业案例和风险列表(大型软件) ；
5. 创建整个项目的开发计划(针对公司实际与当前开发情况，并行完成项目) 。

构造阶段

1. 优化资源、避免不必要的报废和返工，使开发成本降到最低；
2. 尽快达到质量的要求；
3. 快速完成有用的版本，例如Alpha 版、Beta 版和其他测试发布版；
4. 完成所有功能的分析、开发和测试；
5. 迭代式、递增地开发随时可以发布的产品(降低开发风险，快速应对各种可预期和不可预期的变化)；
6. 确定准备好软件系统的外部环境。构建阶段的焦点是实现工作流。

交付阶段

1. 进行Beta版测试，按用户的要求验证新系统；
2. 替换旧的系统；
3. 对用户和维护人员进行培训；
4. 开始调整活动，例如调试、性能或可用性的增强(电信，银行，7X24方式维护)；
5. 与用户达成共识，配置基线与评估标准一致。
6. 交付阶段的焦点是实现和测试工作流。

1.2.5 迭代(反复多次)

RUP中的每个阶段可以进一步分解为迭代。

1. 吻合需求
2. 适应变化
3. 降低风险
4. 积累经验
5. 人员易安排
6. 保证质量
7. 用户真实意图挖掘

1.2.6 工作流(描述工作过程,重要)

过程分为核心过程工作流和核心支持工作流

RUP中有9个核心工作流，分为6个核心过程工作流（Core Process Workflows）和3个核心支持工作流（Core Supporting Workflows）。

6个核心过程工作流

1. 商业建模（Business Modeling）:理解系统的组织结构及其商业运作，确保所有参与人员对开发系统有共同的认识。确定系统功能和用户需要。
2. 需求分析（Requirements）:定义系统功能及用户界面，明确客户需要的系统的功能，开发人员理解系统的需求，为项目预算及计划提供基础。 注重功能性需求与非功能性需求相结合。

3. 分析与设计（Analysis and Design）:把需求分析的结果转化为实现规格。

   .考虑实现环境，可行的技术方案，周期可能很长，大大长于实现和测试时间。

4. 实现(Implementation):定义代码的组织结构、实现代码、单元测试、系统集成。 同时修正分析与设计的结果。
5. 测试（Test）:验证各自子系统的交互与集成。质量管理，贯穿于软件工程的全过程。单元测试，整体测试。
6. 配置(Deployment):打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。制定并实施beta测试。

3个核心支持工作流

1. 配置和变更管理（Configuration and Change Management）:跟踪并维护系统所有产品的完整性和一致性。 工作量大，技术要求高，大量行业经验的积累， 企业知识的积累。
2. 项目管理（Project Management）:为计划、执行和监控软件开发项目提供可行性的指导；为风险管理提供框架。工作人员的经验，管理规范与动态适应性，开发 团队与管理。
3. 环境（Environment）:为组织提供过程管理和工具的支持。软件和硬件的管理与支持。

1.2.7 微过程的划分(细化，粒度依软件规模而定)

商业建模：RUP为软件工程师和商业工程师提供共同的语言和过程，在商业模型和软件模型之间创建并保持直接的可跟踪性，使两方面对需要被支持的商业过程达成共识。

需求分析：描述系统做什么，使开发人员和用户达成共识。抽取用户的需求，识别系统参与者和用例。使用文字对每个用例进行详细描述，包括非功能性描述。用例贯穿于整个系统开发周期，是一条主线，同一用例将被用在需求捕捉、分析、设计和测试阶段。

分析：对问题域进行分析，确定系统问题域中的类

确定类(静态结构)有两种途径:

(1) 阅读规格说明、用例、寻找系统问题域中的类及类间关系类来分析问题域。

(2) 与用户和领域专家讨论，识别出所有关键类及类之间的相互关系。

设计：任务是综合考虑技术限制，扩充和细化分析阶段产生的模型。目的是确定易转化为代码的设计方案，细化分析阶段的抽象类，并增加新类以处理如数据库、通信、硬件等技术领域问题。

分为两个部分：

(1) 结构设计：高层设计，划分子系统，确定子系统之间的依赖性和关联性。

(2) 详细设计：细化子系统，清晰地描述类。

实现：目的在于定义代码的组织结构；以组件的形式实现类和对象；对开发出的组件进行单元测试；将开发人员或小组开发的软件集成为可执行系统。

测试：目的在于验证对象间的交互作用、软件组件的正确集成、所有需求的正确实现、确保BUG的处理。

测试类型：

(1) 单元测试：使用规格说明测试单独类或一组类。

(2) 集成测试：使用组件图和协作图测试组件间协作。

(3) 系统测试：使用用例图测试系统需求满足度。

(4) 验收测试：用户测试满意度。

配置：将软件分发给最终用户。早期阶段的工作为后期的软件发布做准备。配置图描述系统的物理结构，说明设备之间的关系，节点与可执行软件单元的对应关系。

项目管理：平衡冲突目标，管理风险，克服各种限制以同时满足用户费用要求和系统要求。

配置和变更管理：控制同一项目组不同成员的大量产出物。

避免冲突：

(1) 更新同步：小组成员的系统软件版本保持一致。

(2) 有限通知：通知小组成员项目组软件的最新进展，防止错误理解和重复劳动。

(3) 多版本：保证系统多个版本之间的一致性。一个大系统中，必须进行版本管理和版本跟踪，对版本的更新、成员更新信息等要有详细的记载。

环境：为软件开发组织提供软件开发环境。开发环境的选择最好是最适合于当前项目的开发，对当前项目开发有最多的各方面支持。

静态建模：创建并建立一个系统的静态特征

1. 用例图：描述系统功能及功能的使用者.
2. 类 图：表现系统里实体的关系,责任,类和类之间的关系，属性及方法.
3. 对象图：当类图不能完全显示关系时用对象图.描述对象的属性,对象名,方法.

4. 组件图：对类功能的封装,一个组件包含多个类.

   虚线：表示依赖关系.

5. 部署图：描述系统中的物理结构.

   实线：表示连接

动态间模：用来展示系统的行为

1. 时序图：描述对象的交互过程.以时间为参考(强调的是时间顺序).

   虚线：(生命线)表示对象的生命周期.

   实线：对象消息.

   虚线：返回消息.

   长方形：活动(激活).

   叉：对象消亡.

2. 协作图：跟时序图一样,但强调对象的连接关系.
3. 状态图：描述对象的自身的状态(一个对象的类型不同可能行为很古怪,行为变化很大).
4. 活动图：(类似于流程图)描述一个环境中的交互顺序.