用例图:
- 用于显示软件系统的所有功能
 - 软件系统与外部参与者之间的交互
 
基本元素(四个)
⬜系统边界:一个系统与系统外部事物的分界线(上方需要标注名字)
🔴用例:代表从外部可见的系统的一个功能(内部不可见)
🚶♀️:参与者:发起或参与一个用例的外部用户以及其他软件系统等角色
/ :关系:参与者和用例之间的关系(关联)以及用例与用例之间的(包含,扩展)的关系。
注意事项:
- 每一个用例至少要涉及一个参与者
 - 用例图是一个可视化的建模
 
用例图和DFD之间的区别:
| DFD | 用例图 | |
| ⬜ | 外部实体 | 边界 | 
| ⚪ | 加工 | 用例 | 
用例图的建立步骤:
1.寻找参与者:
- 系统开发完成后,有那些人会使用这个系统?
 - 系统需要从那些人或者其他的系统中获得数据?
 - 系统会为那些人或者其他系统提供数据?
 - 系统是由谁来维护和管理的?
 
思考:饮料自动售货机的参与者有哪些?答:顾客,供应商,收营员
2.寻找用例:
- 参与者为什么要使用该系统?
 - 参与者是否会在系统中创建,修改,删除,访问和存储数据?如果是,参与者又是如何来完成这些操作的?
 - 参与者是否会将外部的某些事件通知该系统?
 - 系统是否会将内部的某些事情通知参与者?
 
思考:Email客户端: A在北京发邮件给上海的B,系统体系B您有“新邮件”,B收邮件。
参与者A(发送者)执行的用例有哪些?
参与者B(接收者)执行的用例有哪些?
3.细化用例:
- 用例描述了为应对一个业务实践,由一个用户发起,并在一个连续时间段内完成的,可以增加业务价值的人物。
 - 不要将没有业务价值的商业信息告诉用户
 - 不要将没有价值的信息告诉**
 
用例图——关联关系: →
- 参与者与用例之间是关联关系
 
用例图——包含关系: – – – -《include》- – -> (虚线,上写《include》)
- 用例之间可以有包含关系。
 - 箭头方向由基本用例指向被包含用例
 - 执行基本用例是,每次都必须调用被包含的用例(如,吃饭前必须洗手)
 
用例图——扩展关系: – – – -《extend》- – -> (虚线,上写《extend》)
- 用例之间可以有扩展关系
 - 基本用例中将存在一个扩展点,只有当扩展点被激活时,扩展用例才会被执行。(不必须)
 - 建通方向从扩展用例指向基本用例
 - (例外的情况)肯定没有参与者指向扩展用例,因为扩展用例依赖于基本用例
 
如:在还书的情况下,只有例外条件(读者遗失书籍)的情况下,才会执行交罚款用例
用例规约
- 描述每一个用例的具体功能
 - 一个用例对应一个用例规约,描述用例的细节
 - 在底部建立一个表格,对用例进行描述,写上,参与者,触发条件,前置条件,后置条件,正常流程,扩展流程,特殊需求。
 
注意事项
- 围绕“交互”进行场景描述
 - 尽可能的不要设计界面,按钮,方法等软件系统的内部构造机制
 

0 条评论