3

I can't figure out which relationship I should use in my use case. Let's say the actor is User who can Manage account:-Create; -Delete; -Update;

Any ideas whether I should make Manage Account as a use case and then link Create, delete, update to it - if yes - extend or include relationship? Or it would be better if I leave as separate use cases Create, Delete, Update?

Izumi
  • 571
  • 1
  • 7
  • 16

3 Answers3

2

I'm not a fan of "Manage-X" Use Cases. As your post suggests, 'Manage' is really a collective term for a number of alternate, independent tasks. The result is a Use Case body that doesn't look right:

If the User selects 'Create' then {...}
else if the User selects 'Update' then {...}

...etc.

Better show them individually. If your model gets big - and you need a way to organise - then create a package for related UCs, not a 'super UC'. So in your case, a package named Manage Account containing UCs Open Account, Update Account, etc.

hth.

sfinnie
  • 9,854
  • 1
  • 38
  • 44
0

If/Else statements don't belong in use cases.

Maintenance, or system management, functionality is generally considered system functionality and, other than on the use case model, usually shows up a little later in the game. Add to that the similarity of many of the maintenance functions and I've found it to be a good candidate for a use case with base maintenance flows extended by a few use cases that deal with specific needs. With a handful of use cases I can address a system's entire maintenance / system management needs. (Not counting security administration.)

Nanette Holkestad
  • 79
  • 2
0

If you create a single Manage Use Case and link others with it, it would look that the all users can manage (create, update, delete) accounts. It would be better to create separate uses cases for each and generalize users like admin and operator inherited from a general user and link related use cases to the specialized users e.g. delete account wont be linked with operator

bjan
  • 2,000
  • 7
  • 32
  • 64