1

Edit:

Final outcome based on suggestion given by @qwerty_so

final use case

This is my use case diagram for View Repository in Source Code Management System.

This system is part of Project Management System.

View Repository Use Case Diagram

The system is similar to GitHub, user can select project.

And it will display a list of repository for the project.

User can click a repository to view its details such as file tree and repository information.

Finally, user also can click the file in the tree to view its content.

Is my use of use case generalization correct?

Below use case is the previous version, I learnt that using use case diagram to model process is incorrect (Seidl et al., 2015, p. 37).

Incorrect Use Case

  1. Seidl, M., Huemer, C., Kappel, G., & Scholz, M. (2015). UML @ Classroom: An Introduction to Object-Oriented Modeling. Cham: Springer International Publishing.
wei
  • 937
  • 2
  • 14
  • 34

2 Answers2

1

Well, let me just ask a question: can you abstract added value? The only case where that is true is called franchise. So what you did is to introduce a new abstract bubble to connected three concrete use cases with your actor rather than connecting the concrete bubbles directly. What for? Where is the added value for "View repository"?

For the abstract actor it's similar. There is no need to make User abstract since it's already abstract. All actors denote roles, not real things. You can just leave that abstract keyword away and it would not change any semantics.

What often happens (and you are on that way) is that people start functional decomposition rather than synthesizing use cases. Use cases are about added value a system under consideration delivers to its actors. That's just it. Just present these added values. I know it's difficult for techies, but stick to that.

As always I recommend to read Bittner/Spence about use cases.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • I was thinking too much and the solution was that simple. You also right about the functional decomposition, I already did it like creating bubble for Enter Name. Thank you for your help. – wei Jul 17 '19 at 11:55
0

in my opinion, one use case is one scenario. since we have to make a scenario for every use case model drawn in the diagram, so one use case must have specific pre-condition and specific post-condition but only have one main or basic flow. Use case might have few alternative flows, that are illustrated in extends relationship. while include relationship is used to avoid repetition in several scenarios in main/basic flow of several use cases.

Syauqi Haris
  • 406
  • 5
  • 6