0
votes

I'm currently looking at drawing up a use case diagram based off a scenario I've been given:

  • The system works in such a way that a customer emails their personal details to an administrator.

  • The administrator would then record these personal details onto a spreadsheet.

My current use case diagram has 'email personal details' as one use case for the customer, with 'record personal details' as an < includes > use case for the administrator.

Is this correct usage of < includes >? Or should 'record personal details' be a separate use case for the administrator, without the < includes >?

Here my use case diagram: enter image description here

2
Neither of the bubbles show use cases. Both are functions. Start reading Bittner/Spence to get a good understanding what it's all about. However, it seems you need to go to square one first.qwerty_so
See stackoverflow.com/questions/46692931/use-case-diagram-includes and stackoverflow.com/questions/1696927/… (though I'd rate some of the answers rather poor/incorrect since they use it for functional decomposition like you did).qwerty_so

2 Answers

2
votes

What is the user goal: to send an email to an administrator? Or to get registered to something?

Unless your system is an email software, the use case would probably be:

Customer ------------ Register to xxx ------------- Administrator

The user is the primary actor and wants to get registered, and the administrator is a supporting actor.

THe advantage of this goal-oriented approach is that you focus on the user and things that REALLY matter. The design of the system can then be creative: maybe it is an email with excel table; but maybe a chatbot connected to a backend system would event be better.

If you start to think about a sequence of use-cases in a given order, you probably are no longer in a use-case logic and are already working on a functional decomposition or an activity diagram: this is not the purpose of a use case.

1
votes

Includes is a rare relationship between use cases. In order for it to exist, the included use case needs to be standalone (i.e. it can be run independently) whereas the use case that includes it has to require performing of the included use case as its part.

In your specific case, if the two actors act independently (i.e. administrator can enter the data after let's say 1 hour not worrying about it) it seems more reasonable to create two separate use cases (also "send an e-mail" is questionable as a use case, at least from system perspective). If on the other hand, the strict cooperation is needed, then it will be a single use case with two actors. I don't see a candidate for inclusion here.

Note also, that especially people new to UML have strong tendency to decompose use cases on the uc diagram. It is not the right way of doing it. If you have lots of use cases without actors, and a web of inclusions and extensions, you are most probably doing it wrong (and we've all been there).