UML图——用例图(机房收费系统)

前言:

   经过一段时间的学习,UML(Unified Modeling Language )中几种图基本上学完了,同时结合机房收费系统画出来部分自己理解的图,越来越发现光说不练是不行的,前期学习过UML视频,有个大致的了解,但是通过机房收费系统来画图,觉得自己所知道的真的是很少很少,看完视频时的感受是浅显的,通过UML画图文档这一实践,又知道了一点知识,下面就来说说我所了解的用例图(Use Case Diagram)。

正文:

   1.概念

     用例图(Use Case Diagram):用来显示处于同一系统中的参与者与用例之间的关系的图,可视化地帮助开发团队理解系统的功能需求,描述的是系统外部可见的部分,基于系统需求的用力视图驱动和约束着后续的开发。

   2.组成

 

 3.如何画机房收费系统的用例图?

  3.1 确定系统涉及的总体信息

      

3.2 确定系统的参与者

      参与者: 用户与系统在进行交互时能够担任的不同角色,是系统外部的一个实体,它以某种方式参与了用例的执行过程,代表了与系统交互的事物,在系统外部寻找

     分析使用该系统的主要功能部分的是哪些人——————学生~上下机

     谁将需要该系统的支持以完成工作——————操作员~记录学生上下机(卡)的使用情况以完成结账计费

     系统的维护者与管理者——————管理员~增删用户,登机记录,设定基本数据

     机房收费系统的参与者:一般用户(学生)、操作员、管理员

3.3 确定系统用例

     用例:描述的是一个系统做什么(WHAT)的信息,本质就是需求,我们需要从使用者角度考虑用户希望系统去做的事情,,同时也是某个参与者要做的事,它由参与者发起,这件事的执行结构对参与者来说是有意义的和可观测的,比如说用户登录可以获得身份认证和授权,这对于用户来说是有意义的,但是输入密码却不是用例。

   

         

3.4 确定用例之间的关系

     关联(Association)关系:表示参与者用例之间进行通信,不同的参与者可以访问相同的用例。

             

    包含(Include)关系:一般用户用例可以简单地包含学生用例具有的行为,并把它所包含的用例行为作为自身行为的一部分。

        

  扩展(Extend)关系:扩展用例被定义为基础用例的增量扩展,基础用例提供扩展点以添加新的行为,扩展用例提供插入片段以插入到基础用例的扩展点上。

       

       

    泛化(Generalization)关系:父用例也可以被特别列举为一个或多个子用例,子用例表示父用例的特殊形式,子用例从父用例处继承行为和属性,还可以添加行为或覆                   盖、       改变继承的行为。

             

3.5 使用画图工具(Ration Rose、EA、亿图等)绘制用例图

       一般用户用例图:

操作员用例图:


管理员用例图:


总结:

  用例图(Use Case Diragram)以可视的图形化表示方式描述了系统的外部实体与内部之间交互的过程,从参与者(使用者)的角度思考用例,真正的是用到了面向对象 OO(object-oriented)的软件开发思想,是软件需求分析到实现的第一步,在图中阐明的问题是谁是系统相关的用户,用户希望系统提供什么样的服务,用户需要系统提供的服务;便于用户理解,也便于系统开发人员实现。

 请大家多多指教,小编不胜感激!


    


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 46
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 46
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

奔跑的大白啊

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值