Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

CRUD in a use-case diagram?

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

like image 714
Robin Avatar asked Oct 14 '11 19:10

Robin


People also ask

What is CRUD in UML?

Main Description. CRUD is an acronym that refers to the following actions on an object (typically a data entity): Create - to create and store new data. Read - to retrieve and read data. Update - to change or modify then store the data.

What is the CRUD technique used for?

CRUD technique, an acronym for Create, Read or Report, Update, and Delete technique is used for identifying use cases. Here, the analyst checks the data the needs to be processed by the system, and creates use cases that create, report on, update, and delete the data items.

What's CRUD stand for?

CRUD is an acronym for: CREATE. READ. UPDATE. DELETE.

What are the 4 CRUD components?

CRUD Meaning: CRUD is an acronym that comes from the world of computer programming and refers to the four functions that are considered necessary to implement a persistent storage application: create, read, update and delete.


1 Answers

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.

like image 130
Uffe Avatar answered Oct 05 '22 18:10

Uffe