【UML】— 用例图

9 篇文章 0 订阅

一.元素:

1.角色、用例(功能描述)、关系(泛化、依赖、关联、实现)

2.元素含义:

Actor

1. 可以是人、事、物
2. 分析角色考虑的因素:直接使用系统的人、维护人员、外设(人、打印机)、相连的系统
3.  参与用例的实现过程

3.       图符:

用例

1.       名称:要体现系统的功能

2.       图符:

关系

1.  4种关系:
关联—>     分为:双向和单向,参与者与用例之间的关系常为关联关系
依赖- - - -> 使用关系,如一个类使用另一个类的方法
泛化一个用例被特举出多个用例使用
2.  其它关系:
包含《include》一个用例的行为包含另外一个用例的行为
扩展《extend》(接口扩展)一个用例被定义为基础用例的增量扩展,扩展用例为
基用例添加新的行为

关系图说明:

关联:


依赖:

泛化:

包含:

扩展:


二.作用:描述用户的需求(强调功能、功能的执行者、正在使用的系统)


三.用例注意点

1.清楚地定义系统的边界(即判断哪些功能属于该系统)

2.防止用例过多(粒度)

3.从执行者的角度命名用例

4.描述正规程度

5.避免执行者的名字不一致

6.避免执行者和用例之间的关系太复杂(若过复杂,则添加新的执行者)

7.用例大小恰当

8.用例描述混乱


四:主要属性

 事件流

1.用例执行时角色与系统的交互过程;

2.分为基本流(用例中常规和预期路径的描述)和备选流(受影响后执行其它的路径)

前置条件

(执行的前提条件)什么条件下开始执行一个事件流

后置条件

用例结束后系统的状态


五:粒度

       在绘制一个系统的用例图时,到底画多少用例,多少用例比较合适那,往往在绘制一个系统的用例图时一层用例是不够的,往往需要画好几层,那么问题就来了,我这个用例到底画到第一层中,还是第二层中那,这时有一个判断标准——粒度,用例越多,粒度越大,一般用例在10——50个为宜。

        不同阶段使用的粒度不同:

                 1.业务建模阶段:一个用例能描述一个完整的事件流

                 2.用例分析阶段:一个用例能描述计算机与用户人员能完成一次成功的交互过程

                 3.用例的开发量的时间在一周左右为宜

六:范围

分为:概述级、用户目标级、子功能级

        两个用例同时用到同一个用例,表示这两个用例包含同样的关系,复用一个关系


七:产生阶段及使用用户

主要产生于系统分析阶段,用户描述用户的需求(功能),产生于需求分析报告中

使用人群:用户、系统开发、设计、测试人员、项目负责人


八:图例(以机房收费系统为例)

分析该系统的用户需求:本系统有3个角色,分别是管理员,操作员和一般用户,



评论 22
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值