UML用例图

原文地址： http://blog.csdn.net/zhuojiajin/article/details/8657853

 

　　看过了UML视频，觉的UML里的内容其实看的挺明白的。在开始画图的时候才发现，纯粹是老师讲到好。听的明白或者说觉的本身明白了只是一种错觉。对于UML里的图仍是理解上不够透彻，固然如今要求本身就透彻也是痴人说梦。虽然是一种错觉吧，好赖也让我看视频的时候感受的痛快。再者这种错觉确定仍是以必定的“明白”为根据的。因此这种错觉我喜欢！这篇博客开始对UML中的9种图作个总结，这一篇先讲用例图。

　　那么用例图是UML用来描述一个软件系统中人和功能之间，即角色和用例之间的关系的一种图形化的表达。能够清晰的反应出角色的权限，角色的对应的功能之间的关系。它是从软件系统的外部用户的角度来描述系统、子系统或者类的行为的。用例模型是有开发者和用户共同达成的某种共识。用例模型用若干个用例图描述。用例图必须包含：功能的描述、角色、而且角色和功能对应关系。

 

　　角色（actor）：

软件系统中的角色，是与系统、子系统、或类交互的外部人员、进程或事物的理想化。一个活动这能够对应一个或多个用例。只要是和软件系统有互动的外部对象均可是角色，例如：人员、其余系统、外部服务器、数据库等。UML中用小人图形表示。在画图时，角色相对来讲仍是比较好找的。

--能够激活系统交互信息；

--能够对系统进行输入；

--能够从系统被动的接受信息。

角色：角色既能够是人也能够是物

寻找执行者的几个原则：

-谁使用系统的功能；

-谁须要系统支持平常工做；

-谁来维护关系系统；

-系统须要操纵那些硬件-须要与系统交互的其余系统；

-对系统产生的结果感兴趣的人或事物。

　　用例（usecase）：

用例是软件系统中一个个的功能单元，用例的目的是定义清晰的行为块而不是解释系统的结构。一个用例包括了它所具有的全部行为：主线（理想功能）、行为的不一样变形、行为的异常条件、以及所需的响应。其实就是一个完整的功能，能够是一个大的功能模块，也能够是系统菜单上的每个功能。

　　关系（assosciation）：

用于描述角色和功能之间的关系，有四种：关联、泛化、包含、扩展。

　　用例图中的主要属性：事件流、前置条件、后置条件、粒度、范围

　　事件流：简单的说就是一个用例要作什么的问题，描述的是用例在执行时执行者和系统之间交互的过程。包括基本流（用例中常规和预期的路径的描述：如登陆）和备选流（用例出现特殊状况时执行的其余路径如错误处理）

　　--基本流--对用例中常规和预期路径的描述

　　--备选流--因为受到其余因素影响，用例执行了其余的路径。

　　前置、后置条件：即用例执行时须要知足的条件和结束时的处理结果。应该是相似于DO while循环的两种状况。 

　　前置条件：该用例执行的前提条件，用来描述条件下能够开始执行一个事件流。

　　后置条件：说明用力结束时系统的状态。

　　粒度和范围：是评价一个用例图的优劣的属性。描述了用例图的宽度和离散程度吧。

　　UML用例图的粒度与范围：用例的多少、概述级、用户目标级、子功能级。设计时要重要考虑的方面，一开始粗略的设计用例图，而后慢慢细化。用例图的粒度不该太粗或太细。

 

用例注意点：

◆应该清晰的定义系统边界

◆防止用例过多

◆应该从执行者的角度来命名用例

◆用例描述的正规程度

◆避免执行者的名字不一致

◆避免执行者和用例之间的关系

◆注意用例的大小是否恰当（粒度）

◆避免用例描述混乱

◆区分用力分解和功能分解

◆避免客户不能理解用例的状况

◆有些场合，用用例来描述不适合 

 

　　下面来一个例子吧：自动售货机销售货物功能，这里个过程当中涉及的人员有：顾客 用例有：按钮，指示灯，投币槽，退币槽。用例图以下：