时间: 2021-07-30 11:28:28 人气: 8 评论: 0
本文主要结合实际使用,介绍UML用例图的画法以及用例的说明方式。希望对你有所启发。
用例图是编写需求说明时经常用到的需求表达方式,用于向开发、测试同事说明需求中用户与系统功能单元之间的关系。但是很多刚接触用例的新人,在准备用例说明时并不清楚参与者与用例之间应该如何表达,网上教程五花八门,但感觉部分用例图不够规范,因此对用例图及用例说明梳理总结。
考虑到用例图的作图规范,使用Visio的UML用例组件,对用例中的各种关系进行说明。
用例图的结构主要分为三个部分:参与者、用例、参与者与用例之间的关系,具体说明如下:
顾名思义,代表系统外部与系统发生交互的人或事物;需要注意,人指的是参与者与系统发生交互时的角色,不代指具体的人。
事物指的是某一个应用程序或者特殊进程;例如微信登录,通过跳转微信确认登录信息,微信对系统产生输入时,可以把微信作为参与者;而设定时间,强制退出账号时,时间这一特殊进程对系统产生输入,因此时间也可以作为参与者。
2.2.1 用例的说明
用例是系统外部可见的一个功能单元,是某一个参与者在系统中做某件事从开始到结束的一系列活动的集合,以及结束时应该返回的可观测、有意义的结果,其中还包含可能的各种分支情况;具体用例在用例属性中说明。
2.2.2 用例的特征
角色与用例之间的关系主要包括关联、归纳(泛化)、包含、拓展和依赖。
2.3.1 关联关系
图1 参与者与用例之间的关联关系
2.3.2 归纳(泛化)关系
图2 用户之间、用例之间的归纳关系
2.3.3 包含关系
图3 用例与用例之间的包含关系
2.3.4 拓展关系
图4 用例与用例之间的拓展关系
2.3.5 依赖关系
图5 用例与用例之间的依赖关系
2.3.6 注释
对于部分有特殊条件支撑的用例,也可以添加注释加以说明,例如**用户与普通用户登录系统后,可查看的菜单、数据甚至对系统的操作都是不一样的,此时可以在对应用例上加以注释,以强调此用例的特殊需求。
图6 对用例进行注释
2.3.7 子系统
关系说明:用于强调某部分用例的强关联性,例如门户包含系统登录、首页信息展示等。
图7 子系统与用例之间的关系
2.3.8 各关系的对比
为了对包含、拓展和归纳(泛化)关系更好的区分,以图7为例说明各种关系之间的差别:
1)用例的使用条件
包含用例与归纳(泛化)的子用例,都没有限定的使用条件;例如用户登录系统时,直接选择输入账号密码登录系统,或者通过微信登录系统;而忘记密码是在用户账号登录时遗忘密码才**发生的用例,是有特定条件下才**发生的用例。
2)直接、间接提供服务
归纳(泛化)的子用例与拓展用例为参与者直接提供服务,例如用户登录系统时,**直接选择账号登录或微信登录,而账号登录或微信登录直接为参与者提供登录服务;而包含关系的用例,为参与者提供间接服务,例如账号登录时,需要输入账号、输入密码等,这些用例直接鼓舞于账号登录这个用例,间接为参与者提供登录服务。
3)其余说明
完成了用例图,实际上工作只完成了一半,更重要的是对每个用例进行具体的说明;包括说明用例之间的关系、参与者身份角色以及用例从开始至结束过程中的条件及分支情况等;具体用例说明形式可参考下表:
用例的描述针对不同业务系统,描述的重点可能**存在差异,因此用例描述的重点在于清晰表达用例需求,不必拘泥于表达形式。
不管用例图与表格画得多么酷炫,最终目的也是为了团队同事可以用最短的时间及精力完成对需求的理解。因此扎实的文档能力是产品的基础要求,希望这份总结能给到对用例说明无从下手的童鞋一点帮助。
如有错误,希望各位指正;共勉!
本文由 @庞庞 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议