初学UML之-------用例图

 本文转载至：http://blog.csdn.net/a649518776/article/details/7493148

一．UML简介

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

二．用例建模简介

用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。依个人理解用例建模可分为 用例图和用例描述。用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每一个用例，用文本文档来完成。

1． 用例图

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

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

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

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

2． 用例描述

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

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

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

前置条件：执行用例以前系统必需要处于的状态，或者要知足的条件；

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

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

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

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

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

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

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

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

 

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

用例名称：网站公告发布

用例标识号：202

参与者：负责人

简要说明： 负责人用来填写和修改家教网站首页的公告，公告最终显示在家教网站的首页上。

前置条件： 负责人已经登录家教网站管理系统

基本事件流： 1．负责人鼠标点击“修改公告”按钮 2．系统出现一个文本框，显示着原来的公告内容 3．负责人能够在文本框上修改公告，也能够彻底删除，从新写新的公告 4．负责人编辑完文本框，按“提交”按钮，首页公告就被修改 5．用例终止

其余事件流A1： 在按“提交”按钮以前，负责人随时能够按“返回”按钮，文本框的任何修改内容都不会影响网站首页的公告

异常事件流： 1．提示错误信息，负责人确认 2．返回到管理系统主页面

后置条件： 网站首页的公告信息被修改

注释：无

四． 总结

其实用例建模并非这么简单，它涉及到的知识还有不少，这里只是简单的介绍一下。

感谢:http://www.51cto.com 2006-01-13 10:10 出处:51CTO.com整理

 

---

补充:

用例之间也能够存在包含、扩展和泛化等关系：

　　（1）包含关系：用例能够简单地包含其余用例具备的行为，并把它所包含的用例行为作为自身行为的一部分，这被称做包含关系。

　　（2）扩展关系：扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。在如下几种状况下，可以使用扩展用例：

　　a.代表用例的某一部分是可选的系统行为（这样，您就能够将模型中的可选行为和必选行为分开）；

　　b.代表只在特定条件（如例外条件）下才执行的分支流； 

　　c.代表可能有一组行为段，其中的一个或多个段能够在基本用例中的扩展点处插入。所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。

　　图2.3给出了一个扩展关系的例子，在还书的过程当中，只有在例外条件（读者遗失书籍）的状况下，才会执行赔偿遗失书籍的分支流。

（3）泛化关系：用例能够被特别列举为一个或多个子用例，这被称作用例泛化。当父用例可以被使用时，任何子用例也能够被使用。如在图2.4中，订票是电话订票和网上订票的抽象。

------------------------------------------------------------

泛化、包含和扩展

泛化（Generalization）在面向对象的技术中无处不在，它的另外一个名字也许更为著名，就是“继承”。下图给出了一个使用泛化的用例图：

可知，在用例图中，角色和用例都可以泛化。角色的泛化/继承很容易理解，由于角色原本就是类（Class），它是一种版型（stereotype）为Actor的类，因此角色的继承直观而天然。可是用例的继承实际上分为两种状况，并非简单的使用泛化，而是使用扩展（extended）和包含（include）两种泛化的特例。

扩展用于子用例的动做步骤基本上和父用例的动做步骤相同，只是增长了另外的一些步骤的状况下。包含用于子用例包含了全部父用例的动做，它将父用例做为了本身的一个大步骤，子用例经常包含一个以上的父用例。以下图：