Dear reader of Juri's TechBlog,
I moved my blog to a new domain and a new hosting solution as well. I'm now blogging on

UML Use Case "extend" and "include" relationships

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:
Another source of interest may be

Posts you might also be interested in..

Credits: Hoctro | Jack Book


Anonymous said...

Thank you very much for this post. Made the difference between include and exclude a lot clearer for me!

Anonymous said...

Thanks for taking the time to explain this in a concise way for us noobs!

Anonymous said...

very useful...gr8 job!!!

Anonymous said...

Thank you!Very helpful post.

Saurabh Mahajan said...

Thank you very much today my concepts are clear Again thank you very much.... this article helps me a lot

Kasun Weerasinghe said...

Are u sure about the side where the arrows are pointed in the and relationships ...
we r bit confused after looking at other online resources :S

Juri Strumpflohner said...

What exactly creates your confusion?

Anonymous said...

In the above example, process transaction includes validate user usecase alo. so when we draw class diagram for those usecases, do we need to draw two individual diagrams for those two cases or should we include both of them in one class diagram? i have a similar kind of situation and unable to understand.

Juri Strumpflohner said... really depends on your specific situation as I don't yet know how many classes the "Process Transaction" use case will include. By instinct I'd say to draw two different ones where some classes of each use cases might appear in the respective class diagrams.

Anyway, I never had the need to draw a class diagram so far other than for using it for discussion during some meeting (and then threw it away).

NextTrak said...

Its good effort to educate others regarding UML use case.
One get good idea about the subject.

NextTrak Pakistan

Post a Comment