但是，OMG为了防止UML建模和某种开发过程模型结合过紧，导致其适应性降低，使统一性大打折扣，从而影响UML建模工具的普及和推广，只制定了语义规 则和表示符号，对于一个实际问题怎样进行建模，并未制定象数据库设计范式那样的规范和原则，对于一个项目，应该先建什么模型，后建什么模型，也没有做什么 限制。也就是说，没有规定UML建模的工作过程和方法，UML建模可以适应任何开发过程模型。
软件开发过程模型的理论定义比较简单，而把这一过程模型在实践中应用成功，却有许多制约因素，首先是软件的范围，一个大型分布式软件系统和一个单机版的个 人软件系统在开发管理上肯定不同；其次软件的开发目的，一个为了提高浏览量而开发的网站和一个为密集计算而开发的的一个处理系统在开发过程管理上肯定不 同。最后一点是团队，不同的团队在磨合度、个人能力、团队协作等方面各不相同，开发相同的项目使用相同的开发过程模型，开发结果完全不同的实例多得数不胜 数。另外，软件复用是面向对象的一大特点，它不但与所选择的开发过程模型有关系，而且与企业文化和企业的做事方式有关。
上面这一些都说明，选择或 设计一个好的，能够反映软件开发过程在什么时候做什么、如何作的过程模型并不是件容易的事。UML建模工具和统一过程（RUP）结合，是很多人熟知的理 论，这很大程度上得益于UML三位主要创始人的功劳，因为它们曾共同出过一本关于UML与统一过程的书，另一方面是UML建模工具和统一过程的发源地都是 rational公司，也使人们误认为使用UML建模工具就得使用统一过程，事实上，UML自1.0版本以后，就归OMG所有，而RUP不是OMG发布 的，只有OMG发布的信息，才能作为我们的行业标准。
一切先进的思想，往往是融合了先前其他人的先进思想，在介绍trufun的TUP建模过程之前，我们有必要回顾一下和UML建模结合的几种软件开发过程模型。
统 一过程（UP）模型：统一过程模型在和UML建模结合时，采用以用例为驱动的方式，用用例连接所有活动，每个活动都建一组模型，如业务领域模型、责任领域 模型、实现模型、测试模型，每组模型中又由多个不同的角色共同协作完成，比如具有专门进行用例建模的角色和组件建模的角色等等，采用增量迭代方式建立和完 善用例，并对每一次建模进行评估，在项目的计划、监控等方面并非以建模为中心，而是把建模作为统一过程的一个小部分。该模型的主要缺点是周期长、人员要求 多、建模工作量大。
迭代模型：它是采用较多的小迭代来实现最终的模型，也就是说，模型图是通过一系列步骤一步一步地建起来，每一次迭代都有新信息 添加到模型中来，每一次迭代都要经过评估，都是下一次迭代的输入，迭代会使系统开发的活动（需求、分析、设计和测试）执行多次，并且每次都有新的内容增加 进来。这个方法有一个缺点是在迭代的后期，仍然有新的需求增加进来。
增量模型：增量模型开发每次迭代都能产生一个可执行的结果，这个结果是一个可 “交付的”系统版本，每一次迭代要经过评估，并且增加了一些新的功能，增量模型主要包括分析、设计、实现、测试四个活动。该方法有一个很大缺点是到了项目 迭代后期还要进行设计，会给系统带来很大的风险。
XP模型：又叫极限编程，它是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密 的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求 是，整个开发是以测试为驱动的，它属于小型方法，对于初级软件开发企业有效，无法站在软件过程的行列谈和UML建模结合的问题。
本文转自 trufun 51CTO博客，原文链接：http://blog.51cto.com/trufun/295534，如需转载请自行联系原作者