uml从系统的需求开始，一直可以贯穿整个项目的全过程中

UML建模与软件开发过程模型

现在谈到软件开发过程，大家可能也不会陌生，学过软件工程的人都能随口说上几个软件过程模型，现在要把这两种不同的模型拿到一起来讨论，一方面是软件开发的实际需要，另一方面也是UML建模工具要和其他面向对象开发模型结合的一种必然要求。

但是，OMG为了防止UML建模和某种开发过程模型结合过紧，导致其适应性降低，使统一性大打折扣，从而影响UML建模工具的普及和推广，只制定了语义规则和表示符号，对于一个实际问题怎样进行建模，并未制定象数据库设计范式那样的规范和原则，对于一个项目，应该先建什么模型，后建什么模型，也没有做什么限制。也就是说，没有规定UML建模的工作过程和方法，UML建模可以适应任何开发过程模型。

软件开发过程模型的理论定义比较简单，而把这一过程模型在实践中应用成功，却有许多制约因素，首先是软件的范围，一个大型分布式软件系统和一个单机版的个人软件系统在开发管理上肯定不同；其次软件的开发目的，一个为了提高浏览量而开发的网站和一个为密集计算而开发的的一个处理系统在开发过程管理上肯定不同。最后一点是团队，不同的团队在磨合度、个人能力、团队协作等方面各不相同，开发相同的项目使用相同的开发过程模型，开发结果完全不同的实例多得数不胜数。另外，软件复用是面向对象的一大特点，它不但与所选择的开发过程模型有关系，而且与企业文化和企业的做事方式有关。

上面这一些都说明，选择或设计一个好的，能够反映软件开发过程在什么时候做什么、如何作的过程模型并不是件容易的事。UML建模工具和统一过程（RUP）结合，是很多人熟知的理论，这很大程度上得益于UML三位主要创始人的功劳，因为它们曾共同出过一本关于UML与统一过程的书，另一方面是UML建模工具和统一过程的发源地都是 rational公司，也使人们误认为使用UML建模工具就得使用统一过程，事实上，UML自10版本以后，就归OMG所有，而RUP不是OMG发布的，只有OMG发布的信息，才能作为我们的行业标准。

一切先进的思想，往往是融合了先前其他人的先进思想，在介绍trufun的TUP建模过程之前，我们有必要回顾一下和UML建模结合的几种软件开发过程模型。

统一过程（UP）模型：统一过程模型在和UML建模结合时，采用以用例为驱动的方式，用用例连接所有活动，每个活动都建一组模型，如业务领域模型、责任领域模型、实现模型、测试模型，每组模型中又由多个不同的角色共同协作完成，比如具有专门进行用例建模的角色和组件建模的角色等等，采用增量迭代方式建立和完善用例，并对每一次建模进行评估，在项目的计划、监控等方面并非以建模为中心，而是把建模作为统一过程的一个小部分。该模型的主要缺点是周期长、人员要求多、建模工作量大。

迭代模型：它是采用较多的小迭代来实现最终的模型，也就是说，模型图是通过一系列步骤一步一步地建起来，每一次迭代都有新信息添加到模型中来，每一次迭代都要经过评估，都是下一次迭代的输入，迭代会使系统开发的活动（需求、分析、设计和测试）执行多次，并且每次都有新的内容增加进来。这个方法有一个缺点是在迭代的后期，仍然有新的需求增加进来。

增量模型：增量模型开发每次迭代都能产生一个可执行的结果，这个结果是一个可 “交付的”系统版本，每一次迭代要经过评估，并且增加了一些新的功能，增量模型主要包括分析、设计、实现、测试四个活动。该方法有一个很大缺点是到了项目迭代后期还要进行设计，会给系统带来很大的风险。

XP模型：又叫极限编程，它是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是，整个开发是以测试为驱动的，它属于小型方法，对于初级软件开发企业有效，无法站在软件过程的行列谈和UML建模结合的问题。

一 uml简介　uml（统一建模语言，unified modeling language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用uml来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，也是个人的理解，uml的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。

二 用例建模简介

　用例建模是uml建模的一部分，在我眼里，它也是uml里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。

　依我的理解用例建模可分为用例图和用例描述。用例图由参与者（actor）、用例（use case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。

　1 用例图

　参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时 间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

　　用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是uml对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。

　　系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。

　箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

2 用例描述

　用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。

　对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。下面说说各个部分的意思：

　简要描述：对用例的角色、目的的简要描述；

　前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；

　基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；

　其他事件流：表示这个行为或流程是可选的或备选的，并不是总要总要执行它们；

　异常事件流：表示发生了某些非正常的事情所要执行的流程；

　后置条件：用例一旦执行后系统所处的状态；

　三 用例图和用例描述设计实例

　这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。这个网站我用uml完整的分析一下，以下我提取了用例图和用例描述的部分。这个家教网站分为前台客户系统和后台管理系统。

　前台客户系统的用例图如下：

　　后台管理系统用例图如下：

　　对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。如下：

四 总结

　其实用例建模并不是这么简单，它涉及到的知识还有很多，我这里只是简单的介绍一下，希望对初学uml建模的同学有所帮助。

一 uml简介　uml（统一建模语言，unified modeling language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用uml来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，也是个人的理解，uml的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。

二 用例建模简介

　用例建模是uml建模的一部分，在我眼里，它也是uml里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。

　依我的理解用例建模可分为用例图和用例描述。用例图由参与者（actor）、用例（use case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。

　1 用例图

　参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时 间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

　　用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是uml对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。

　　系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。

　箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

　　一般用UML来画很多图，主要包括用例图、状态图、类图、活动 图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。

　　用例图（use case diagram）就是由主角、用例以及它们之间的关系构成的图。该图说明了用例模型中的关系。

　　可以将用例图组织到用例包中，并归用例包所有，让特定包中仅显示互为关联关系的内容。

　　用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。