Uml学习-用例建模简介

用例建模简介 

用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。用例图重点描述用户需求。 它描述需求、用户和主要组件之间的关系。 它不会详细描述用户需求；在可连接到每一个用例的其余关系图或文档中可详细描述这些需求。用例图是UML的九个图中较为重要和经常使用的一种图。经常用于软件开发的需求分析阶段，也能用于软件的系统测试阶段。简单的来讲，用例图是描述系统的外部视图，为了搞清某个项目的大概需求，咱们每每要问两个问题，

1．  这个系统有什么用？有哪些人参与?

2．  这些人经过这个系统能作些什么事？

经过这两个问题，通常就能比较清楚地表达系统的需求了，用例图就是用来回答这两个问题的，它能从比较清晰的角度来表达系统的需求，并且不涉及到技术用语。

 

用例建模可分为用例图和用例描述。

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

用例描述用来详细描述用例图中每一个用例，用文本文档来完成。 

1．  参与者(Actor)

在一个系统开发前，咱们一定首先要肯定系统的用户，系统的用户就是系统的参与者。除此之外，咱们还会想一想咱们开发的系统与其余的系统有什么关联？所以，系统的参与者可分为两类，一类是人，包括系统的使用者、维护者等，另一类是其余系统。

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

 

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

 

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

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

 

一：用例之间的关系

1角色的继承

 

 

2： 用例的包含(Include) 包含关系指用例能够简单地包含其余用例具备的行为，并把它所包含的用例行为做为自身行为的一部分。在UML中，包含关系是经过带箭头的虚线段加<<include>>字样来表示，箭头由基础用例(Base) 指向被包含用例(Inclusion)

         在处理包含关系时，具体的作法就是把几个用例的公共部分单独的抽象出来成为一个新的用例。主要有两种状况须要用到包含关系：

A） 第一，多个用例用到同一段的行为，则能够把这段共同的行为单独抽象成为一个用例，而后让其余用例来包含这一用例。

B） 第二，某一个用例的功能过多、事件流过于复杂时，咱们也能够把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。

 

3: 扩展关系 在必定条件下，把新的行为加入到已有的用例中，得到的新用例叫作扩展用例(Extension) ，原有的用例叫作基础用例(Base) ，从扩展用例到基础用例的关系就是扩展关系。一个基础用例能够拥有一个或者多个扩展用例，这些扩展用例能够一块儿使用。

 

二． 用例描述  

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

下面是一个用例描述模板：

编号	[用例编号,如 UC-01]	名称	[用例名称,即用例图中用例的描述]
执行者	[用户，角色等]
描述	[简单的描述本用例，重点说明执行者的目标]
前置条件	[列出执行本用例前必须存在的系统状态，如：必须录入什么数据，须选实现其余什么用例等。注意除非状况特殊，不要写相似”登陆系统”等每一个用例几乎都须要具有的前置条件。]
基本流程	[说明在“正常”的状况下，最经常使用的流程，一般是执行者和系统之间交互的文字描述]
结束状态	[列出在“正常”结束的状况下的用例的结果]
可选流程1	[说明 和基本流程不一样的其余可能的流程]
可选流程N	[说明 和基本流程不一样的其余可能的流程]
异常流程	[说明出现错误或其余异常状况时和基本流程的不一样之处]
说明	[对本用例的补充说明，如：业务概念，业务规则等]

 

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

这里以以前的那个考勤系统为例来简单分析一个用例图的画法。

经分析系统中涉及的角色有以下： 普通员工、行政部员工、财务部员工、部门经理、总经理。

角色的继承关系以下：

 

 

普通员工的用例：

 

下面是关于普通员工的”提出请假申请”的用例描述

编号	1.1	名称	提出请假申请
执行者	普通员工
描述	普通员工录入请假的信息，能成功提出请假申请
前置条件	无
基本流程	1: j显示请假申请表单。 2：填写请申请单，选择请假类型 3：提交申请 4:显示成功提交的申请信息并返回列表。
结束状态	系统保存请假申请数据，并提示成功提交申请的信息
可选流程1	3：取消请假申请 4：返回列表
异常流程	2：填写请申请单，选择请假类型为”年假” 3：提交申请 4：提示可休年假不足，显示相应信息。 5： 修改请假申请单，或取消请假申请.
说明	请假申请单有如下内容：申请者，开始时间，结束时间，请假事由，请假类别。 申请假默认为当前的用户，不可修改。 请假的类别为：事假，病假，婚 嫁，产假，年假，只能并且必须选其一

 其它的用述描述再也不赘述。

 

 以上内容来自于 【火球UML大战需求分析】中，做为学习笔记记录一下