目录
利用UML的大约20%就可以为大多数问题的80%部分建模。
使用基本结构事物（如类、属性、操作、用例、构件和包）以及基本结构关系（如依赖、泛化和关联）就足以建立许多种问题域的静态模型。再加上一些基本行为事物（如简单状态机和交互），就可以对系统动态的许多有用方面进行建模。只有当对遇到的更复杂的情况建模时（如对并发和分布建模时），才会用到UML的一些更高级特征。
1、事物
1.1、结构事物
结构事物是UML模型中的名词，包括类、接口、协作、用况、主动类、构件和结点。
1.2、行为事物
行为事物是UML模型的动态部分，包括交互和状态机。
1.3、成组事物
成组事物是UML模型的组织部分，包括包。
1.4、注释事物
注释事物是UML模型的解释部分，包括注解。
2、关系
2.1、依赖
依赖是两个事物之间的一种语义关系，其中一个事物（独立事物）的改变会影响另一个事物（依赖事物）的语义。
2.2、关联
关联是一种结构关系，它描述了一组链，链是对象之间的连接。
2.3、泛化
泛化是一般/特殊关系，其中特殊元素（子类）的对象可以替换一般元素（父类）的对象。
注意：子类指向父类
2.4、实现关系，一种特殊的泛化，用于接口实现表示
3、可扩展性
UML提供3种机制来扩展语言的语法和语义：
衍型（表现新的建模元素）<<>>
标记值（表现新的建模属性）赋值
约束（表现新的建模语义）大括号
4、图
图是一组元素的图形表示，通常表现为一些相互连接的顶点（事物）和弧（关系）。
图是对系统的投影。UML包括13种这样的图。
4.1、结构图
（1）类图。展示一组类、接口、协作以及它们的关系。
（2）对象图。展示一组对象以及它们的关系。
（3）构件图。展示构件的外部接口（包括端口）和内部组成。
（4）组合结构图。展示结构化类的外部接口和内部组成。把构件图和组合结构图一并讨论。
（5）部署图。展示一组结点、制品以及被表现的类和构件之间的关系。
（6）包图。展示如何把模型组织到包中。
4.2、行为图
（1）用例图。展示一组用例、参与者以及它们的关系。
（2）顺序图。展示一个交互，强调消息的时间顺序。
（3）通信图。展示一个交互，强调收发消息的对象的结构组织。
（4）状态图。展示一个状态机，强调由事件引发的对象行为。
（5）活动图。展示一个计算过程，强调从活动到活动的流。
（6）定时图。展示在特定时间带有消息的交互。
（7）交互概览图。结合了活动图和顺序图的内容。
混合型的图是允许的；建模元素之间没有严格的区别。
5、统一过程Rational
以体系结构为中心、迭代、模型的创建维护、用例驱动
强调持续的质量控制和风险管理
5.1、四个阶段
（1）初始（Inception）。为项目建立构想、范围和初始计划。
为系统建立构想，并限定项目的范围。这包括业务用况、高层的需求和初始的项目计划。项目计划包括成功准则、风险评估、所需资源的估测以及一个显示主要里程碑进度表的阶段计划。在初始阶段通常要建立一个用作概念验证的可执行原型。
（2）细化（Elaboration）。设计、实现、测试一个健全的体系结构并完成项目计划。
细化阶段的目标是分析问题域，建立一个健全的、合理的体系结构基础，精化项目计划，并消除项目的那些最高风险因素。
（3）构造（Construction）。建造第一个可工作的系统版本。
要迭代地、增量式地开发一个准备移交给用户团体的完整产品。
（4）移交（Transition）。把系统交付给它的最终用户。
为用户团体部署这个软件。注意，项目自始至终，包括演示、专题讨论会、α发布及β发布都要有用户的参与。
一次迭代（iteration）代表一个完整的开发周期，从分析中的需求捕获到实现和测试，产生一个可执行的发布版本。这样的发布不必包括商业版本的完整特征。
5.2、九个任务
（1）业务建模：描述用户组织的结构和动态特性。
（2）需求：用多种方法得出需求。
（3）分析和设计：描述多种体系结构视图。
（4）实现：考虑软件开发、单元测试和集成。
（5）测试：描述脚本、测试执行和缺陷追踪度量指标。
（6）部署：包括材料清单、版本说明、培训以及交付一个应用系统的其他方面
（7）配置管理：对项目制品和管理活动的完整性进行变化控制和维护。
（8）项目管理：描述对于一个迭代过程的不同工作策略。
（9）环境：包括开发一个系统所需要的基础设施。
在每个任务中所捕获的是一组相关的制品和活动。
制品（artifact）是一些可被产生、操作或消耗的文档、报告或可执行程序。
活动（activity）描述工作人员为创建或修改制品要完成的任务——思考步骤、执行步骤和复审步骤，以及用来执行这些任务的技术和准则，可能还包括使用帮助自动实现某些任务的工具。
5.3、制品
5.3.1、模型
模型是Rational统一过程中最重要的一种制品。一个模型是现实的一个简化，创建模型是为了更好地理解将要创建的系统。
（1）业务用例模型：建立组织的抽象。
（2）业务分析模型：建立系统的语境。
（3）用例模型：建立系统的功能需求。
（4）分析模型（可选）：建立概念设计。
（5）设计模型：建立问题的词汇及其解决方案。
（6）数据模型（可选）：为数据库和其他库建立数据表示法。
（7）部署模型：建立系统执行的硬件拓扑结构以及系统的并发和同步机制。
（8）实现模型：建立用于装配和发布物理系统的各部件。
视图是在模型上的一个投影。在Rational统一过程中，一个系统的体系结构是在5种连锁的视图中捕获的，这5种视图是：设计视图、交互视图、部署视图、实现视图和用况视图。
5.3.2、其他制品
（1）需求集合：描述系统必须做什么。
可能包括用例模型、非功能需求模型、领域模型、分析模型以及用户需求的其他表示形式，其他表示形式包括（但不限于）：试验模型、接口原型、规则约束等。
（2）分析和设计集合：描述系统是如何被构造的。
捕获关于系统如何被建造的决策，考虑到时间、预算、遗产系统、复用、质量目标等所有约束。
可以包括设计模型、测试模型以及系统特性的其他表示形式，这些其他表示形式包括（但并不限于）：原型和可执行的体系结构。
（3）测试集合：描述确认和验证系统的方法。
包括脚本、测试用例、缺陷追踪度量指标以及验收标准。
（4）实现集合：描述被开发的软件构件的组装。
用各种编程语言编写的源代码、配置文件、数据文件、软件构件等，还包括描述如何装配这个系统的信息。
（5）部署集合：提供用于可交付配置的所有数据。
聚集了软件被实际包装、运载、安装以及在目标环境中运行的所有信息。
