本节向大家学习一下UML用例建模方面的知识，用例建模是UML建模的一部分，它也是UML里最基础的部分。用例描述用来具体描述用例图中每个用例，用文本文档来完成。
简述UML用例建模的慨念和应用
一．UML简介
UML（统一建模语言，UnifiedModelingLanguage）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。
二．UML用例建模简介
用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。依我的理解用例建模可分为用例图和用例描述。用例图由参与者（Actor）、用例（UseCase）、系统边界、箭头组成，用画图的方法来完成。用例描述用来具体描述用例图中每个用例，用文本文档来完成。
a．用例图
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注重的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的治理员，他参与图书馆治理系统的交互，这时他既可以作为治理员这个角色参与治理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
b．用例描述
UML用例建模中用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有具体的说明，这样就可以让别人对这个系统有一个更加具体的了解，这时我们就需要写用例描述。
对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。
下面说说各个部分的意思：
简要描述：对用例的角色、目的的简要描述；
前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；
基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；
其他事件流：表示这个行为或流程是可选的或备选的，并不是总要总要执行它们；
异常事件流：表示发生了某些非正常的事情所要执行的流程；
后置条件：用例一旦执行后系统所处的状态；
三．UML用例建模中用例图和用例描述设计实例
这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。这个网站我用UML完整的分析一下，以下我提取了用例图和用例描述的部分。这个家教网站分为前台客户系统和后台治理系统。
对于用例描述，篇幅有限，我在这里只列了后台治理系统中的网站公告发布这个用例的描述。如下：用例名称：网站公告发布用例标识号：202参与者：负责人简要说明：
负责人用来填写和修改家教网站首页的公告，公告最终显示在家教网站的首页上。
前置条件：负责人已经登陆家教网站治理系统基本事件流：
1．负责人鼠标点击“修改公告”按钮
2．系统出现一个文本框，显示着原来的公告内容
3．负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告
4．负责人编辑完文本框，按“提交”按钮，首页公告就被修改
5．用例终止其他事件流A1：
在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的公告异常事件流：
1．提示错误信息，负责人确认
2．返回到治理系统主页面后置条件：
网站首页的公告信息被修改
【编辑推荐】
