UML统一建模语言-知识点2.1用例图

2.1用例图

用例图包括:参与者、用例、依赖泛化和关联关系;
参与者(actor ,有些书翻译成“角色”)是一种特殊的类,是系统外部的一个实体,这个实体可以是任何的人或物,它以某种方式参与了用例的执行过程。参与者用一个人形的图案表示 。具体是:人、外部设备、外部系统。
注意:参与者是一个集合概念。一个具体的外部实体仅代表同一类参与者的一个实例 :在一个银行业务系统中,可能会有以下参与者
客户:在银行业务系统中办理了账户的居民。他们通过银行业务系统进行金融交易
管理人员:负责银行业务系统具体操作事务的办事人员。他们为客户办理存款、取款等金融交易
Mail系统:负责银行业务系统向个人发送电子邮件的软件系统
例如:

  1. 寻呼台系统。用户如果预定了天气预报,系统每天定给他发天气消息;如果当天气温高于35度,还要提醒用户注意防暑。
  2. 商品销售系统。顾客通过网络下单之后,系统计算出总计金额,税金,运费,并将数目传递给一个外挂的会计系统,该系统是另外购买的。

概念
UseCase: 用例(UseCase)是对一组序列动作的描述,系统执行这些动作将对用例的参与者产生可以观察的结果。是参与者可以感受到的系统服务或功能单元。在图形上,用例用实线的椭圆表示。

用例应描述系统该做什么,而不是如何做
用例应采取参与者的视点 
用例应对参与者有价值 
用例描述的时间流应是一个完整场景 
所有的参与者、用例都应有相应的关联用例或关联参与者 
计算用例的数量,控制用例的数目 

用例之间抽象出包含(include)、扩展(extend)和泛化(generalization)这几种关系
泛化关系(generalization)
在这里插入图片描述
包含关系(include)
在这里插入图片描述
在进行用例A、B时必须先进性用例C;
扩展关系(extend)
在这里插入图片描述
包含用例与扩展用例的区别
相对于基础用例,扩展用例是可选的;包含用例则不是。
如果缺少扩展用例,基础用例还是完整的;缺少包含用例,则基础用例就不完整了。
扩展用例的执行需要满足某种条件;包含用例不需要。
扩展用例的执行会改变基础用例的行为;包含用例不会。
性质:因为基本用例的行为被包含用例或扩展用例的行为延伸了,所以基本用例的行为依赖于包含用例或扩展用例的行为。所以,包含关系和扩展关系都是依赖关系的特例

分析题 某在线会议审稿系统:
用户在初始使用系统时,必须在系统中注册,称为作者。
作者登录后提交稿件和浏览稿件审阅结果。
在这里插入图片描述
答案:
A1是用户,A2是作者子类指向父类
U1是注册,U2是登录,U3是提交稿件(或浏览稿件审阅结果),U4是浏览稿件审阅结果(或提交稿件)
R1是<>,R2是<>或<>,R3是<>
用户注册成为作者、作者有可能会登录,注册和登录之间存在着扩展关系; 作者浏览稿件,浏览稿件的前提必须是登录,浏览稿件和登录之间存在扩展关系; 作者浏览稿件审阅结果,提交稿件是作者可以登录也可以不登陆,因此登录和提交稿件之间是扩展或者包含关系
泛化关系:一般参与者与特殊参与者之间的关系
作用:有效地减少了参与者与用例之间的关联关系的个数,简化了用例模型

  • 1
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值