From now and then I have to create UML diagrams to model certain parts of software projects, especially for the University. Initially, creating UML models, may seem annoying but in fact they can be very useful if they are applied correctly. So for instance an
UML Use Case diagram can help a lot in explaining the main functionalities of a program, either to some other technical person or to the user itself (or even to create the diagram
with the user itself). On the other side, modelling a whole system with a class diagram may be completely nonsense. Creating class diagrams makes sense for the critical / most important parts of the system, s.t. all the developers can take it as a point of reference. Modelling the whole system will lead to a lot of work that nobody will ever look at and which will soon again be out of date.
So I'm currently creating an UML Use case diagram to describe the basic features of my application I'm planning to develop and it always happens again to me that I come to the point where I have to search the web about the details regarding the "extend" and "include" relationships. Just out of the head it seems to be clear: "extend" is some kind of specialization, a use case that extends the functionalities of its base case etc...while "include" is a use-case which will be called as a consequence of invoking another one. But still there are these doubts...should this new use case be one for itself or should it extend this other one here...the boundaries are not always very clear.
Well here I've found a documention from IBM Rational Architect that explains the difference quite good (I think):
The [...] figure illustrates an e-commerce application that provides customers with the option of checking the status of their orders. This behavior is modeled with a base use case called CheckOrderStatus that has an inclusion use case called LogIn. The LogIn use case is a separate inclusion use case because it contains behaviors that several other use cases in the system use. An include relationship points from the CheckOrderStatus use case to the LogIn use case to indicate that the CheckOrderStatus use case always includes the behaviors in the LogIn use case.
The "extend" relationship is explained as follows:
You are developing an e-commerce system in which you have a base use case called Place Online Order that has an extending use case called Specify Shipping Instructions. An extend relationship points from the Specify Shipping Instructions use case to the Place Online Order use case to indicate that the behaviors in the Specify Shipping Instructions use case are optional and only occur in certain circumstances.
So the key point in the extends relationship is
"optional"! It adds further functionality to the base use case which may be restricted by constraints. The
following diagram shows this:
Consider the "Order Wine" and "Serve Wine" use cases. The "Order Wine" extends the "Order Food", meaning that wine may be ordered by the customer, but not necessarily (optional). Therefore the use case "Server Wine" has a condition on its extend relationship: "if wine was ordered".
Another relationship is the "Specialization/Generalization" relationship. The notation is a arrow with a white triangle at the end, basically the same that is used for defining the inheritance (extends) relationship in the UML class diagrams. The figure below (taken from
Wikipedia) shows an example:
Questions? Thoughts? Hit me up
on Twitter
