enter image description here

I have an Employee who can view items . he also can checkout an item independently (regardless of manage items use-case ). The problem is that when an Employee view items he can choose to checkout one. So I think one of the following options is true :

  1. the 'extend' relation from view items to checkout an item is not needed and should be deleted
  2. the association between the Employee and the checkout an item use-case is not needed ( I doubt that one to be true )
  3. Options 1 and 2 are wrong . both the association and the 'extend' relation are true and should be there on the diagram.
  • Sounds like a homework problem to me. If I am right, please read this meta post first. – Doc Brown May 13 '18 at 11:38
  • It's not a homework. it's a question about the UML specification for the 'extend' relation . is it needed even if the actor is directly related to the extending use-case. – ghassen lassoued May 13 '18 at 12:02
  • Maybe because of the way I asked the question and the example I gave . I wanted my question to be simple. – ghassen lassoued May 13 '18 at 12:04

If a use case extends another is independent from the visible associations between actors and use cases. However, whenever there is an actor associated with a use case like "checkout items", it is clear this situation requires user interaction, which makes it mandatory to have a viewing feature part of that use case, not the other way round.

Therefore, I heavily recommend not to model "view items" as a use case on its own. An employee does not view items "just for fun", for real use cases, there should be a business purpose behind it. Some examples, which all will need this viewing feature:

  • checking some item properties for the purpose of quality assurance - then the use case is "quality assurance of items"

  • given those items have a price, then "paying an item" might be a use case

  • "checkout items" (whatever that means in your context, since "checkout" and "item" are generic terms with many different possible meanings)

UML use case notation is intended for describing usage scenarios mostly independend from the UI. This notation and the "extends" and "includes" relationships are designed for a higher level of abstraction. Even if the use case "checkout items" will be started at the user interface by viewing the items first, that is nothing I would try to express through the model, it is just an UI detail.

If you still feeel urged to model "view items" as a separate use case, maybe for exercising purposes, then I would recommend to draw an "includes" relationship from a use case like "checkout items" to "view items". However, it is IMHO obvious that most use cases involving user interaction with items need a viewing feature: users don't want to poke around with items blindly when operating on them.

  • 1
    An employee does not view items "just for fun" -- I always liked the boss test for deciding if a UC adds value. I.e., if you told your boss you spent the day "viewing items" (or "logging in", etc.), would she be happy with you? – Fuhrmanator May 15 '18 at 21:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.