我正在写一份报告,我有一些问题要问。
我很确定这
authentication
不是一个用例,但我可以将它用作图中包含的用例。我的问题是:描述这个“用例”并制作他的系统序列图(SSD)是否正确?例如,当我有一个用例“管理配置文件”时,我是否必须描述所有子用例?(添加、修改、删除、查看)还是其中之一?
在DSS中,将所有场景都写在图中是否正确?(可选的和替代的)还是我必须只写名义场景?
对不起我的英语很差!谢谢你。
我正在写一份报告,我有一些问题要问。
我很确定这authentication
不是一个用例,但我可以将它用作图中包含的用例。我的问题是:描述这个“用例”并制作他的系统序列图(SSD)是否正确?
例如,当我有一个用例“管理配置文件”时,我是否必须描述所有子用例?(添加、修改、删除、查看)还是其中之一?
在DSS中,将所有场景都写在图中是否正确?(可选的和替代的)还是我必须只写名义场景?
对不起我的英语很差!谢谢你。
谢谢你。我删除了 UC 的描述authentication
,以及 SSD 中的所有“无用”细节,例如“搜索单词、成功/失败过程......”。我想知道这样说是否正确:This use case manage x is composed by 4 sub use cases: view x, add x, modify x, delete x
,我制作图表 actor/4 sub UC 并且每次我描述子用例及其 SSD 因为每个子 UC 都需要它的场景。或者,没用?
1.是的,你是对的,你需要指定依赖于authentication
使用<<include>>
的案例,但有些案例不只是属于authentication
,例如用户已经登录,但他无权访问某个案例(authorization
也请关注) .
1.1:通常工程师不会为常见的业务提供SD(时序图),除非技术(不是业务)流程真的很复杂。通常这些步骤由 SDS 文档提供给开发人员。
2.用例图不需要看很详细,不需要查看/删除/更新/等...
3.没有必要深入研究SD,除非(正如我所说)过程有点复杂,或者替代路径在这里非常重要,但通常SD用于描述功能的过程,其中所有(想象/预期的)数据都是正确的,没有错误和异常。