用例图中的 CRUD?

发布于 2024-12-10 13:13:16 字数 871 浏览 5 评论 0原文

我的问题很简单。将 CRUD 引入用例图中的最佳方法是什么?它应该是。我知道,UML 有时是可自由裁量的,但您对此有何看法?

一些想法:

1 用例图

usecase1

  • 如果有一些 CRUD 对象,那么并不是真正的 DRY。

2 用例图

usecase2

  • 如果有一些 CRUD 对象,那么并不是真正的 DRY。

3 用例图

usecase3

  • 我更喜欢这个。

更新

4 用例图 (@Uffe)

在此处输入图像描述

  • 注意,当文档中描述时,也许不需要?

5 用例图 (@home @Uffe)

在此处输入图像描述

My question is quite simple. What is the best way to bring CRUD into a use-case diagram? It should be DRY. I know, UML is sometimes discretionary, but what do you think about it?

Some ideas:

1 use-case diagram

usecase1

  • Not really DRY, if there are a few CRUD objects.

2 use-case diagram

usecase2

  • Not really DRY, if there are a few CRUD objects.

3 use-case diagram

usecase3

  • I prefer this.

Update

4 use-case diagram (@Uffe)

enter image description here

  • Note maybe needless, when it is described in the documentation?

5 use-case diagram (@home @Uffe)

enter image description here

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

土豪 2024-12-17 13:13:16

其中,我想说#3实际上是最糟糕的,因为“CRUD”本身根本不是一个用例;你总是 CRUD 一些东西。不要将用例 <> 与类继承混淆。

选项 #2 也不是很好,因为运行“管理用户”用例并不意味着您执行所有四个 CRUD 操作。

如果你真的想在你的用例中如此明确,#1 有我的钱。但如果是我,我只会在其中放置一个“管理用户”用例。

由于用户(或其他)管理是一个很好理解的概念,“管理用户”用例实际上是不言自明的,不需要详细说明多个用例,除非有特定的原因这样做(例如,如果您正在分析其需求的系统是身份验证机制)。如果是这种情况,请使用#1。

Out of these, I would say #3 is actually the worst, because "CRUD" on its own is not a use case at all; you always CRUD something. Don't confuse use case <<extend>> with class inheritance.

Option #2 is not very good either, because running through a "manage user" use case does not mean you perform all four CRUD actions.

If you really want to be this explicit in your use cases, #1 has my money. But if it were me, I would just put a single "Manage Users" use case in there.

Since user (or something else) management is a well-understood concept, a "Manage Users" use case is actually pretty self-explanatory and doesn't need detailing into several use cases unless there are specific reasons to do so (for instance, if the system you're analyzing the requirements for is an authentication mechanism). If that is the case, use #1.

¢蛋碎的人ぎ生 2024-12-17 13:13:16

根据《Applying UML and Patterns-Craig Larman》一书,我们可以使用“管理用户”作为用例名称来展示用例中的CRUD操作。 4 是不错的选择,在这种情况下我们应该在场景中描述 CRUD 操作。在主要事件流中创建用户,在替代事件流中创建其他用户。

According to the book "Applying UML and Patterns-Craig Larman", we can use "Manage User" for use case name to show CRUD operation in use case. No 4 is good choice and in this case we shoud describe CRUD operations in scenario. Create user in main flow of events and the others in alternative flow of events.

又爬满兰若 2024-12-17 13:13:16

我会投票给三个,只要公司对 CRUD 的确切含义有隐式或明确的理解(即每个人都应该同意它只是意味着输入所有数据的基本形式,如果一个类需要更复杂的形式)输入过程,那么它应该被建模为一个单独的用例)。

I´d vote for three as long as there is an implicit or explicit understanding in the company of what exactly you mean by CRUD (i.e. everybody should agree that it simply means basic forms to enter all the data, if a class needs a more complex input process then it should be modeled as a separate use case).

昔梦 2024-12-17 13:13:16

我会在讨论中提出另一种选择,也许我会使用这个,让我们考虑第六种选择。
将这 4 个操作放在称为“CRUD 用户”的系统边界内,这也有帮助,因为并非所有用户始终都可以访问所有 CRUD 操作。

I would put another option in discussion and meybe I would use this one, lets consider number 6 alternative.
Put the 4 operations inside a system boundary called "CRUD User", it also helps because not all users always have access to all crud operations.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文