UML建模案例分析-用例图如何处理“登录“

概念

用例图(Use Case Diagram)是用户与系统交互的最简表示形式,展现了用户和与TA相关的用例之间的关联关系。


问题

登录这个功能几乎所有系统都有,但如何建模,说法就比较多了。以会员下订单结算为例,具体需求如下:开发一个电子商务系统,会员可通过电子商务系统下订单购买商品。具体功能需求如下:会员通过系统下订单;请求结账时,系统验证会员的账户是否处于登录状态;系统验证订单是否完整以及各商品库存是否充足;最后,系统合计订单总价(订单总价=所有订单项价钱合计+税金+运费);

对于登录这个用例,它和其他用例的关系可以做很多理解:

  • 系统的任何用例执行之前都要先登录。这种理解下,登录和其他所有用例是包含关系,那就画成下面这样:

  • 会员登录系统后,可能执行其他各个用例。这种理解下,登录和其他所有用例就是扩展关系,那就画成下面这样:

  • 完全按上述理解机械地建模肯定不行,要理解建模的宗旨(描述客观事物的主要特征,忽略次要特征),还要会灵活处理。该例相对简单,如果遇到规模庞大的系统,登录和其他用例之间千篇一律的连线就是多余的,那要怎样处理?简单处理就行了。

  • 如果角色比较多,而且有的需要登录有的不需要,那就抽象出一个角色执行登录用例,能登录的用例从这个角色派生出来就行了。

总结

  • 要灵活处理
  • 体现关键核心的用例关系,忽略掉次要关系
  • 19
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值