3

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!

Andrej
  • 1,679
  • 1
  • 26
  • 40

2 Answers2

5

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

enter image description here

Dewfy
  • 23,277
  • 13
  • 73
  • 121
  • Thank you! But I am not happy :-) IMO it is still quite hard to understand. In "extends" example you gave only one Use Case (there must be at at least two...). The "inherits" relation I didn't get at all (are there two actors or one? etc.). Other examples were OK. However the interplay of the examples is also not clear. For example - should the abstract or concrete Use Case include the "authorization" Use Case? And I was also looking for a visual representation of the diagram (I don't see any). Probably I should try to put your examples in a diagram myself and then check it with someone. – Andrej Apr 23 '12 at 23:08
  • Thank you very much! Your additional explanations made the thing more clear. But I still got some questions... :-) "Pay by visa and get balance printed" - can you please put this UC in the diagram and connect with the actor? (IMO it is slightly different from "Pay from bank"). Can you please also add links from Actors on the "Two side payment"? Why you don't have a link from an actor to the "Pay from bank" UC? Thank you! – Andrej Apr 24 '12 at 12:18
  • @Andrej (1) "Pay by visa and get balance printed" - is more appropriate for sequence diagram, that clarify why "Pay from bank" is <> but not inherit. (2) You don't need extra links because "Card holder" already references to "Pay By VISA" - it is enough to understand that "Two side payment" and "Pay from bank" also are used by it actor. – Dewfy Apr 24 '12 at 13:20
  • Thank you! Last question:-) Did I understand correctly that "extend" relation implies that extension UC is available for the actor which has access to the base UC? It is a little bit confusing, for example one could be denied to pay from bank... Actually the another answer from Murat Ünal shows diagram, where it is clear, that only international students use security check. Can you please clarify this? – Andrej Apr 24 '12 at 15:38
  • @Andrej when you create UC diagram you should keep in mind that you write it for human, so if you think that <> is not clear for your customer you have to clarify it with extra linkage or notes. – Dewfy Apr 25 '12 at 08:00
2

I figured out some bookmarks from my delicious. You might want to check. Especially second article may help you figure out the inheritance use cases.

1)From Topcoder

2)Reuse in Use-Case Models

3)Introduction to Use-Case Models

Student University Enrollment Use Case

Murat Ünal
  • 396
  • 2
  • 11
  • Thank you for links. BUT IMO the diagram itself is not very comprehensive. Also it is not clear why a line goes from Student and an arrow goes from International Student? "Enroll in Seminar" normally is not obligatory when you enroll in University. Also the diagram makes you think, that "Perform Security Check" is the main action that International Student wants to do and "Enroll in University" is only additional thing... – Andrej Apr 24 '12 at 12:03
  • @Andrej, i get you point. IMO, you think too complex. Just relax. This diagram is the requirements of the drawers, not yours. So Enroll in Seminar might be necessary after enroll in University. At least, it is in my country. – Murat Ünal Apr 24 '12 at 16:14
  • @Andrej The arrow-head line shows us that International student should start from the pointed use case, looking at the example, performing a security check, which extends spesific sequence steps of "Enroll in Univesity". Let's say, maybe in USA, a student may just enroll in University by giving a identity number and declaring an address. However, a foreigner may give papers of why he/she came to America, where lives, what is his/her income etc.etc... – Murat Ünal Apr 24 '12 at 16:14
  • @Andrej The arrow-head also is used for the actors where she/he appears for the spesific use case. I hope those also help – Murat Ünal Apr 24 '12 at 16:17
  • Thank you for your explanations. I still don't understand the difference between association (just line between Actor and UC) and directed association (an arrow from Actor to UC)... – Andrej Apr 24 '12 at 16:50
  • @Andrej I wish i could speak better English. However, you may check it from here. http://www.agilemodeling.com/artifacts/useCaseDiagram.htm "Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to indicate the primary actor within the use case. The arrowheads are typically confused with data flow and as a result I avoid their use." – Murat Ünal Apr 24 '12 at 19:33