【问题标题】:UML use case diagram for note saving application笔记保存应用程序的 UML 用例图
【发布时间】:2021-04-12 01:15:15
【问题描述】:

我是系统建模的新手,我在将我的想法表达到图表中时遇到了一些问题,尤其是在用例图中,因为缺少动态交互。

前提条件:用户必须连接

规格
用户将能够查看他的所有笔记(在主页中)。
用户可以通过更改其标题或正文或两者来检查特定注释并对其进行修改。
用户可以从主页访问创建笔记。
他必须添加标题和正文以及至少一个标签。
用户可以从创建笔记页面和主页访问创建标签。
保存并返回主页面时,系统应将便笺保存到后端。
创建标签时,用户必须输入标签并指定颜色。

问题:
1-这是一个有效的用例图吗?
2- 我应该在后端和创建注释和创建标签之间添加关联吗?

【问题讨论】:

    标签: oop uml modeling use-case


    【解决方案1】:

    不,这不是一个真正有效的 UC 图表。 UC 是关于附加值的。你开始了功能分解(就像大多数人在开始使用 UC 时尝试的那样)。 UC 代表正在考虑的系统向其参与者之一提供的单一附加值。在这里你有一个你有 CRUD 的注释。不幸的是,这已经让人很痛苦了。附加值是一般Manage X 还是Show 和编辑之间有根本区别?这取决于上下文,对此没有一般性的答案。但是,您不会将您采取的步骤(操作;例如enter xy)或各种场景(活动)描述为单个用例。你需要在单个 UC 中尝试尽可能多地综合,以显示附加值。这对技术人员来说很难。

    根据经验:如果您的 UC 图表类似于蜘蛛网,那么您的设计可能会损坏。

    我一如既往地建议阅读 Bittner/Spence 关于用例。

    【讨论】:

    • 感谢您的帮助,我只是不明白您所说的不要将各种场景描述为单个用例是什么意思。
    • UC 的目标可以通过多种方式实现。至少有“晴天”场景是自我解释的。然后,您可能会在其他(相应命名的)场景中描述一些失败/偏离路径。其中每一个都将由一个活动来表示,该活动从头到尾保存动作(步骤)。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-01-06
    • 1970-01-01
    • 2010-11-08
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多