0

I am trying to create a use case diagram. In the diagram, I have two actors that have access to the same use case (View Properties) but they have different functions related to the use case. Can anyone please let me know which one of the diagrams below is correct? Should I keep one "View Properties" use case or should I add two "View Properties" use case with different extends?

Use case diagram 1: Use case diagram 1

Use case diagram 2: Use case diagram 2

Thanks in advance :)

3
  • (1) Is "view properties" a true use case? That is, would one of these actors use the system to view properties and not carry out one of the other actions? Is there value if you were to deliver a system where you could only view properties? (2) Is the relationship truly an "extend" relationship and not an "include" relationship? Consider Martin Fowler's comments on ignoring extend relationships and the general uselessness of use case diagrams. (3) What would happen if you connected your actors to the more specific use cases?
    – Thomas Owens
    Commented Jun 15, 2022 at 1:05
  • @ThomasOwens Yes, it is a true use case. I have just removed all of the other use cases form the diagram to make it simpler. From what I have read, I believe this is indeed an extend relationship. The actors can use the use cases mentioned in extend if they want to. but it isn't compulsory to use them. They can just view the properties if they want. Status includes "Unsold, Sold". This is for a school project so I'm going to have to add the extend relationship and I also have to create the use case diagram because the project requires it.
    – EagleRex
    Commented Jun 15, 2022 at 5:36
  • @ThomasOwens As for connecting the actors directly to the specific use cases, I'm not sure about that. If I connect the actors to the specific use cases under the extend relationship, would they also get access to the "View Properties" use case?
    – EagleRex
    Commented Jun 15, 2022 at 5:41

1 Answer 1

1

It's incredibly difficult to talk about use case diagrams because they don't contain sufficient information to be useful or to have a meaningful discussion beyond conformance to the specification. For example, in this particular example, I can't tell you if the Extend or Include relationship is correct because I cannot see if the behavior defined in Update Status can truly be inserted into the View Properties use case at at least one extension point. This information would be captured somewhere else, probably using one of the textual or tabular use case templates.

If what you are trying to show is indeed an Extend relationship and the View Properties use case has the appropriate extension points documented, then if I were to draw a use case diagram, I would probably draw it like this:

UML 2.5 Use Case Diagram demonstrating the Extends relationship

Although it has a lot of lines on it, the diagram makes it clear to a reader that there are going to be conditional extension points within the View Properties use case where actors of different types can split off into different paths and perform additional actions or functions. The reader would then go to the View Properties details to understand more about how that works.

However, my normal caveats apply:

Since it appears this is a school project, you should ask your instructor what they are looking for.

In the real world, you may need to balance following the UML specification and creating a perfectly valid and compliant model with creating a model that is readable and communicates the intent to others who use it in the future.

I totally agree with Martin Fowler that Use Case diagrams are often a waste. They add very little value for the time spent creating and maintaining them. A table of contents of well-written use case titles is often more useful and easier to generate and maintain.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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