Imagine you have 2 use case A and B.
To execute case B, A has to be already done ( A is precondition of B), but when you execute A you dont need to execute B
Like this?
User -> A
User -> B -> include A
-
3Have a look here: batimes.com/articles/…– Robert HarveyCommented Aug 29, 2017 at 3:19
Add a comment
|
2 Answers
Preconditions in UML are represented with a constraint. You are allowed to express it in natural language.
Nevertheless, an UML use case diagram intends to give an overview of the main objectives/intents that an actor can achieve with the system under consideration. And your preconditions are a level of detail that should rather belong to the specification of the use case (be it expressed with an UML activity diagram or textual narratives like Cockburn's ones).
Also the constraint is ambiguous: Is it a constraint linked to the state of the system (i.e. A should be executed at least once before B) ? Or is it a sequencing (i.e. Every single time you want to execute B you first have to go over A) ? In the latter case, you could consider B with a larger scope, so that it includes A and show this include-relationship in the diagram.
answered Aug 29, 2017 at 6:43
-
Thenk you, its like your second case, like firt you need to "log in" and then you can "send text" or "put profule pic". I understand with what you have said that it is with include- relationship– difeguiCommented Aug 29, 2017 at 14:30
-
Customers don't usually buy a system to "log in". This is of no value to the user. A constraint "user must be logged in" or rather adding a logged in user actor (child of unregistered user actor) would be preferable. See this other question.– PiovezanCommented Apr 27, 2020 at 2:07
Two alternative thoughts on this, for a Use Case diagram or description.
If A is an optional part of Use Case B, use an "Extend" relationship between them. In this case, that is the purpose of that relationship.
If A may be initiated outside of Use Case B, then I would use a "Dependency" relationship between them. You might need to add an appropriate label describing the nature of the dependency
In some cases, you might be best adding a higher-level use case that includes B and is extended by A. This would be a situation where A and B are only related by a process decision, not because they are inherently related. This helps differentiate between the inherent complexity and the accidental/incidental complexity.
-
You seem to start functional decomposition with that approach. No good. The OP is asking about constraints.– user188153Commented Apr 17, 2020 at 11:10