UML作为典型的开发过程

创建

业务过程模型被用来定义发生在企业或组织内部的高级业务活动和业务过程，并且是建立用例模型的基础。一般来说比一个软件系统所能实现的更多（比如：业务模型包括人力和其他过程）。

映射到

以精确定义你要提供的功能，并且是站在业务用户角度考虑的。每增加一个用例时，将创建一个从适当的业务过程到该用例的可跟踪链接（如：一个实现链接）。这个映射清楚地表达新系统将提供什么样的功能来满足业务过程中所描述的业务需求。这种映射也确保系统中每个用例都是有用的。

完善用例

包括需求，约束、复杂程度、注释及情形。这些信息清楚地描述用例做什么，如何做以及执行时的相关约束。这个过程要保证用例始终满足业务过程的需求，包括每个用例的系统测试定义，该定义为该用例定义了接收标准。也包括了一些用户可接受的测试脚本：这些脚本定义了用户将如何进行测试和测试接收的标准。

 

构建领域模型、顺序图、协作图和用户接口模型

有了的输入与输出和用例的详细信息，就可以开始构建领域模型（高级业务对象）、顺序图、协作图和用户接口模型。这些图描述新系统中的要素以及这些要素之间的相互作用和用户执行用例时所需各种情形的接口。

建立

在领域模型、用户接口模型和情形图的基础上，开始建立。这是制定系统中对象的明确规范：数据、属性、行为和操作。使用继承机制，可将领域对象抽象为类层次结构。处理各种情形的消息一般被映射到类的操作。如果使用一个现存的框架或设计模式，则可能导入现存模型的元素到新系统中。为每一个类定义单元测试、集成测试和系统测试。测试目的：1）类的功能是否如所定义的，2）类与其它类及组件的交互是否如期望的。

构造组件模型

当开发类模型时，可能需要将它分解成包和组件。一个组件代表一个可使用的软件块，它是一个类或者多个类的数据和行为的结合，并严格定义一个对外提供服务的接口。所以，从的角度看，构造组件模型就是定义类的逻辑包。对于每一个组件，需要定义集成测试，以证实组件的接口满足规范要求，即与其它软件元素的关系。

 整理额外需求

　　在完成上述工作的同时，需要获取一些额外的需求并整理成文档。例如：非功能性需求，性能需求，安全需求，义务需求，发布计划等。将这些需求在模型内部进行整合并随模型的进展而更新。

8. 定义系统的物理架构

定义系统的物理架构。这个工作可以提前开始以便于掌握系统的物理结构特性-使用什么样的硬件、操作系统、网络规模、接口与支持软件，来构成新系统，和系统部署在那里，以及出现灾难性故障时的系统恢复，系统可靠性、系统备份与支持等方面所使用的参数。随着模型开发的不断进展，物理系统模型应该不断更新以反映所开发系统的实际情况。

 

构造系统　

构造系统：将模型的分散模块分配给一个或多个开发者。如果采用用例驱动的方法构造系统，这将意味分配一个用例给开发小组，让他们构造用户界面，业务对象，数据库表以及执行该用例所必须的相关组件。在构造每个用例时，应该同时完成单元测试、集成测试和系统测试。如果采用组件驱动的方法构造系统，则需将各个组件分配给开发小组。

查找设计缺陷

对照模型中的元素，跟踪查找出现在测试阶段的缺陷。如：查看针对用例的系统测试缺陷，查看针对对象类的单元测试缺陷等等，跟踪相关模型元素的修改以防止范围漫延。

评估每一次完善模型的结果

随着工作进展不断更新和完善模型-每次修改模型或完善模型，都要评价所做的修改或改善对后续工作的影响。在模块设计中使用反复式工作方法，评介当前构造的模块，新到达的需求，以及开发过程发现的任何问题

 

部署测试环境

将完整的，并经过测试的软件发送到测试生产环节。如果采用分阶段发送，那么这种软件生产方式需要从测试到生产的多次往复才能最终完成整个项目。

 

 

注意：上面描述的过程只是项目开发所必须经历的一个简要概述，还有很多没有提及。它不是告你应该如何工作，或者不遵循你已经采用的方法。它只给出如何用UML来支持软件开发项目的一个例子。