Question

I am looking for an ideal example of a Use Case diagram which would explain most of the tricky places and be a good model for new Use Case diagrams.

It must have following things:

• abstract Use Cases
• concrete Use Cases
• “extends” relation
• “include” relation
• “inherits” relation that connects abstract and concrete Use Cases
• at least two concrete actors
• an abstract actor

And of course it should be

• syntactically correct (UML 2.x conform)
• semantically correct
• comprehensive
• not too complex

I searched myself and didn’t find any good example that would contain all the things.

Probably somebody has such an example and can share it. Thank you in advance!

Answer 1

Payment by VISA:

• abstract Use Cases – “user may pay bay VISA”
• concrete Use Cases – “user may pay from supermarket terminal”
• “extends” relation – “bank terminal has extended features (like a result balance printing)”
• “include” relation – “payment include authorization use-case”
• “inherits” relation that connects abstract and concrete Use Cases – it is more complex. But just imagine 2 side payment (when 2 users should deposit money before transaction done).
• at least two concrete actors – Let’s review use case “to see balance history”. Abstract permitted user can see history, concrete permitted user is a system-admin and card-holder

UPDATE

“extends” – really there are two UC there: (1) “user may pay by visa” (2) “pay by visa and get balance printed”.

“inherits” – let me clarify this UC: Inheritance is very similar to extends, with little difference that “extend” introduce some new activity, when “inheritance” change the way how system deal. In my example we still need to pay by VISA, but to confirm transaction this payment should be done by 2 participants. One pays and s/hes money are temporary frozen, second pays and s/hes money confirms entire payment. But from perspective of seller this use case is visible as simple payment operation. So we don’t change value of service (compare with “extend” from user perspective) but change the criteria of transaction done.

For example – should the abstract or concrete Use Case include the “authorization” Use Case

Very good question. Abstract may include “authorization” in 2 ways:

1. If you sure that there is only one possible way to authorize – then abstract SHOULD include.

2. If there are more than one way to authorize – then you need provide abstract use case “authorize” with all possible inheritance. So abstract UC will “include” abstract “authorize”.

I don’t see any