统一软件开发过程
UP的几个核心概念，也可以说是最佳实践：用例驱动（所有的分析设计测试都是围绕用例展开），迭代（因此我们会不断地编写用例，绘制用例图，进行分析，设计，实现，部署和测试活动），基于组件（我们看到最后软件是由组件构成的），以架构为中心（分层架构，完整的对象模型，核心领域模型）
|
核心工作流
|
模型
|
过程
|
UML图
|
|
需求
|
用例模型
|
1 描述企业的业务流程，编写业务用例，然后以用例图来表示各个用例之间的关系（include/extend），及使用（use）该用例的参与者（Actor）
|
用例图
|
|
2 使用活动图来表示业务流程
|
活动图
|
|
3 根据业务流程，明确系统功能，编写系统用例，使用用例图表示各个用例之间的关系，及使用该用例的参与者。
|
用例图
|
|
4 使用系统顺序图描述系统事件与系统操作
|
顺序图
|
|
分析
|
分析模型
描述用例实现的对象模型，它是工件：设计模型的一个抽象。 分析模型包含用例分析的结果、工件：分析类的实例。
用例实现-分析
|
5 对于用例中的一个或多个场景进行分析，然后抽象出一些分析类（包括边界类，控制类和实体类），分析类将被映射为设计类（分析类代表角色，一个分析类可以由1或多个设计类实现）。分析类也可以称之为业务模型，或者是领域模型。分析类通常可跨越多个用例，其表示领域中的概念。
|
类图
|
|
6 分析类与分析类之间的交互，由协作图来表示。这样称之为用例实现。
|
协作图
|
|
以上两者再辅之以文本，可以用来描述用例实现，每个用例对应于一个用例实现。
|
|
|
设计
|
设计模型
用例实现-设计
|
7 设计类代表系统中完成功能的类。它受到分析类的启发或者是为了解决一些软件问题而被设计出来。
|
类图
|
|
8 用例实现。根据分析模型中的用例实现，来完成设计模型中的用例实现。
|
顺序图
|
|
可以使用包图来表示系统的分层架构。
|
|
|
10 某些设计对象是由状态决定的，也就是说根据其状态的不同，其会表现出不同的行为。状态图可以表示一个对象的状态转换关系及顺序，可以理解为对象状态流程图。
|
状态图
|
|
实现
|
实现模型
|
11 将系统抽象为组件，实现模型即由组件构成。这符合UP包含基于组件的思想。（Jacobson是组件开发之父）
|
组件图
|
|
实施
|
实施模型
|
12 实施模型根据相互连接的节点定义实际的系统架构。
|
实施图
|