0

I´m a mostly self thought developer and I’m trying to learn some concepts of how to design and plan a software project properly using UML and use case diagrams, class diagrams, etc. In this example of a use case diagram, I wanted to display the use case of creating an index card for an index card app. The epic for this is:

As a user I want to create and change index cards that contains a question and answer and when created they should be assigned to a category. Only when a question and an answer are created for the card the card can be saved and assign to a category. Also it should be possible to add attach a picture to the answer or question side of the index card.

This is my diagram I came up with:

enter image description here

My concerns are now that I don´t know how to display the condition that: “Only when a question and an answer is created for the card the card can be saved and assign to a category” in this diagram. It would be nice to get some advice on this “problem” and tips overall on how to get better at planning a software project.

EDIT: new Solution: I used the pre/postconditions for my example

enter image description here

bruno
  • 32,421
  • 7
  • 25
  • 37
Kamil Kirstein
  • 1
  • 1

2 Answers2

0

Warning, the behavior of an included UC is executed each time the including UC is executed. From formal/2017-12-05 § 18.1.3.3 Includes :

Include is a DirectedRelationship between two UseCases, indicating that the behavior of the included UseCase (the addition ) is inserted into the behavior of the including UseCase (the includingCase ). It is also a kind of NamedElement so that it can have a name in the context of its owning UseCase (the includingCase ). The including UseCase may depend on the changes produced by executing the included UseCase. The included UseCase must be available for the behavior of the including UseCase to be completely described.

The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common. As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the base UseCase depends on the addition but not vice versa.

All of the behavior of the included UseCase is executed at a single location in the included UseCase before execution of the including UseCase is resumed.

So in your case each time create index card is executed it is also the case of create a question and create an answer and assign to a new category or an existing one, and both of create a question and create an answer does attach a photo so that one is executed two times.

Of course it is the same for edit index card where included UCs are executed each time, and change or attach a photo is executed two times.

This is not what you want, all the UCs are executed separately (create a question is not done during create index card etc) and then all the includes must be removed.

Only when a question and a answer is created for the card the card can be saved and assign to a category

the fact the question and an answer must be already created are preconditions, they are not included UC as you did.

The pre/post conditions are part of the description of the UC, from formal/2017-12-05 § 18.1.3.1 Use Cases and Actors page 640 :

The behaviors of a UseCase can be described by a set of Behaviors (through its ownedBehavior relationship), such as Interactions, Activities, and StateMachines, as well as by pre-conditions, post-conditions and natural language text where appropriate.

bruno
  • 32,421
  • 7
  • 25
  • 37
  • Thank you for your fast answer. So when I get it right an included UC is always executed when I use it and in my case, this is wrong because the create question and create answer are not use-cases by itself but an element of the create index card UC..? And also as you mentioned the creation of a valid card (with question and answer) is a precondition for the assignment of that card to a category. I came up with a new solution. I will post here in a min. – Kamil Kirstein Apr 10 '21 at 10:56
  • @KamilKirstein an included UC is an UC, the problem is not here, if I well understand your UCs must be executed separately, I mean at a moment an index card is created, at an other one (before or after) a question is created etc, and this is not possible with the includes (more the UCs executed two times). The only constraint is a card is saved and assigned to a category after a question and answer was created, and to say that you have to use preconditions – bruno Apr 10 '21 at 11:04
  • I edited my question with a new diagram, based on your tips. I hope I got it right ... and you helped me very much because you introduced me to the concept of pre-and postconditions so thank you very much :) – Kamil Kirstein Apr 10 '21 at 12:30
  • @KamilKirstein for me the UC create question etc must exist,you have to reintroduce them, but without the includes – bruno Apr 10 '21 at 12:36
  • 1
    I don't agree with your statement **the behavior of an included UC is executed each time the including UC is executed** Why can't an include be conditional (e.g. only included in one scenario, and not in another scenario)? I don't see anything in the UML specs that exclude that. – Geert Bellekens Apr 10 '21 at 16:50
  • @GeertBellekens you are wrong, an extend can be conditional ([formal/2017-12-05](http://www.omg.org/spec/UML/2.5.1) page 641 : *If the condition of the Extend is missing or evaluates to true at the time the first ExtensionPoint is reached during the execution of the extended UseCase, then all of the appropriate behavior fragments of the extending UseCase will also be executed. If the condition is false, this does not happen.*, ... – bruno Apr 10 '21 at 16:59
  • @GeertBellekens ... [formal/2017-12-05](http://www.omg.org/spec/UML/2.5.1) page 647 : *condition : Constraint [0..1]{subsets Element::ownedElement} (opposite A_condition_extend::extend) References the condition that must hold when the first ExtensionPoint is reached for the extension to take place. If no constraint is associated with the Extend relationship, the extension is unconditional.*). But there is nothing like that for an include ([formal/2017-12-05](http://www.omg.org/spec/UML/2.5.1) Figure 18.1 UseCases), an include is then unconditional. – bruno Apr 10 '21 at 16:59
  • @bruno so because of a phrase in the description about «extend» you come to the this conclusion about «include»? Feels very *circumstantial* to me. – Geert Bellekens Apr 10 '21 at 17:07
  • @GeertBellekens no, I speak about extend to show the difference. Again look at the figure 18.1 UseCase of http://www.omg.org/spec/UML/2.5.1 : there is no condition => unconditional. Of course the behavior of the included UC can start by a test, but that changes nothing about the fact the inclusion is unconditional – bruno Apr 10 '21 at 17:10
  • @bruno again, that says something about «extend». The fact that that is not there for «inlcude» doesn't mean it will *always* be executed. It's perfectly valid to include a use case that will only be executed in some scenario's, and not in others. But since scenarios are not part of UML I guess they didn't make that option explicit. How else would you model a use case that needs to validate a card payment only if the payment was done using a card. You can't use extend here since the main use case needs the results of the included "validate card" use case – Geert Bellekens Apr 10 '21 at 17:22
  • @GeertBellekens **no** ! An extend can be conditional thanks to *condition* (multiplicity `0..1`), but an include **does not have a condition**. Furthermore the textual description of *extend* clearly speak about the fact the extend can be under condition, but there is nothing about that in the textual description of *include* even the description of *include* is given with details (see the beginning of my answer). The standard is clear, there is no condition => unconditional – bruno Apr 10 '21 at 17:31
  • @GeertBellekens perhaps your confuse the fact the behavior of the included UC is inserted unconditionally and the fact that behavior can contains conditional parts, there are two different things – bruno Apr 10 '21 at 17:56
  • The specification is not very clear about the semantics of "inserting a behavior". One hint could be, that "behavior" is written in lower case. That means it is used in a colloquial sense and not in the sense of an UML *B*ehavior. So it is more a "description of a behavior" that is inserted and the including use case is unconditionally not complete without this description. It may, however, have alternative flows, where the included behavior is not used. In my practice, this is fairly common. – Axel Scheithauer Apr 13 '21 at 15:55
  • I usually recommend to distinguish between result and postcondition. The result is observable by the primary actor and the postconditions are other conditions that need to be fulfilled at a successful completion of the use case. – Axel Scheithauer Apr 13 '21 at 16:00
0

I think you fell in the trap of functional decomposition. Drawing ellipses around all the functions you can think of leads not to a good use case model.

The second solution is much better. Each use case now has a goal, that is of value for the stakeholder or actor. Maybe except for Assign Category. In your first solution this was part of Create Index Card, where it probably belongs to.

The real value of use case analysis is in helping you to find functions, that you didn't think of in the first place. None of these functions are shown in the use case diagram. They are described textually, as you have done in the second solution. Other authors use some kind of Behavior diagram. Preconditions could be shown there as conditions on decision nodes for example.

Conditions can be shown on the extend relationship between use cases, but I strongly advise against using this feature. Yes, with them alternative flows could be shown on a use case diagram, but there are diagrams better suited for describing this.

In alternative flows the interesting functions are usually found. What happens if the printer is out of index cards. Is it OK to abandon the goal in this case? Or does your system need a detect paper refill function, so that it can start printing the card as soon as paper is detected.

Axel Scheithauer
  • 2,758
  • 5
  • 13