Heys guys! Im have been study UML and im trying to to design the use case diagram of a problem.
Lets supose my app consists in this:
Two Requesites:
- create teams
- create players
This is the deal:
A user can create a team, and after create a team he can create players for that team(not required).
But in this app there are multiple users, and a user can create a team and other user can create players. The only constraint is that to create players must exist alreay a team.
I research and i end up a little confuse. If i get the concepts of relations on use case diagrams right, i think i should have the folowwing two use cases:
[use case - create team] <-------extends---- [use case - create player]
I need opinions,Is this the proper solution? or should i have two not related use cases?
Thanks in advance, and im sorry my english.
Generally you do not need to model dependencies like "A must be done before doing B" in a Use Case Diagram. Use Cases should represent a set of Szenarios to group them as a common case.
The "extends" dependency is used to specify a Use Case which is more special than the extended one. So, if you would like to express that creating a player is a special form of creating a team using "extend" would be fine. Bbut this does not match the situation described above.
If you would like to express that creating a playing always means to create a team as well, you can use an "include" dependency. This could match your case but imo does not entirely.
The final option is to draw an unspecified dependency (no << >> marker) the express that the use cases have something todo with each other.
My recommendation: don't use any dependency in this case.
Some more good explanations can be found here, btw.
There is a common problem with use cases: relations. We tend to use relations to describe the sequence of use cases. But this is a misconception. Here are some words from The UML User Guide about Use Cases and Flow of Events (part 4, chapter 17):
You can specify a use cases's flow of events in a number of ways
[...] informal structured text
[...] formal structured text
[...] states machines
[...] activity diagrams
The point is that, if the guide tends to say (implicitly) that relationships should not be used to specify flow of events, it does not say what the use cases relations should be used for. I think this is the reason why use cases are an important point of UML and UP but a tool very difficult to handle.
In your model, you should perhaps change the arrow and the term (simple suggestion, you are the analyst):
This should be represented on your diagram if you want to emphasize the constraint, but not as a representation of the sequence of operations (subtle distinction).
The extends terms is usually associated to generalization / specialization. And in my opinion this is not the kind of relationship you have between a team and a user creation. The example given by the guide is the following (part 4, chapter 18):
That said, modelling the specialization of use case is most of time of limited interest. But sometimes this is needed, it depends on the use cases description: if both are equal you don't, if not you do. An advised programmer knows that specialization does not imply equal assertions.
Related
Imagine that we are building a Library system. Our use cases might be
Borrow book
Look up book
Manage membership
Imagine that we can fulfill these use cases by a librarian person or a machine. We need to realize these use cases.
Should we draw different use case realizations for different flows?
If not, it is very different to borrow a book from a machine and a person. How can we handle it?
Moreover, what if we have updated version of library machines some day? (e.g. one with keyboard and the other is with touch screen) What should we do then? The flow stays the same, however the hardware and the software eventually be different.
What would you use to realize use cases and why?
It might be a basic question, but I failed to find concrete examples on the subject to understand what is right. Thank you all in advance.
There is no single truth or one way you "should" do it. I will give you my approach, based on the Unified Process.
The use case technique is primarily used to describe a dialog between a human user (actor) and an application. It is modeled as an ellipse and further specified as an activity diagram or just a list of steps: 1 The actor does A, 2 The system does B, 3 The actor does C etc. In this approach, the application is regarded as a black box.
A "use case realization" describes how the system performs its steps (white box), e.g. in terms of collaborating components, transparent to the user.
It is possible, but much less common, to have so-called business use cases. In that case, the "system" represents an enterprise or a business unit. In your case, it would be the library. The "actor" represents an external person or organization, e.g. a client or a supplier. In your case, it would be a client. With business use cases, the library is regarded as a black box. The steps are still in format "actor does A; system does B", but here, it is not specified which of the library's actions are performed by humans and which by applications. The system is the organization, interfacing with external actors, regardless of whether this is implemented by employees or by applications.
A "business use case realization" specifies how the system performs its steps (white box) and specifies which parts are done by employees and which parts by machines.
Now, let me answer you questions one by one.
Question 1.
If you have described your use case as a business use case, and it is at such a high level of abstraction that the steps for client-librarian interaction are the same as for client-machine interaction, then you will have one business use case "Borrow book" and two business use case realizations for this business use case.
However, it is more common practice to have only use cases for user-application interaction. If the client interacts with the system in the same way as a librarian would do on behalf of the client, then you will have only one use case "Borrow book", with actor "Person". This actor has two specializations: "Client" and "Librarian". There will be only one use case realization per use case.
Otherwise, you would have one use case "Borrow book online" describing the flow of events when a client interacts directly with the application, connected to actor "Client" and another use case "Borrow book for client" describing the flow of events when a librarian interacts with the application while talking to the client. The latter use case has "Librarian" as its actor. Again, there will be only one use case realization per use case.
You may choose to model the Client-Librarian interaction separately, or not at all, depending on the purpose of your model.
Question 2.
Let's take use case "Borrow book online". You may have two use case realizations for this use case: one for the keyboard machine and one for the touch screen machine. If these use case realizations are very similar, then I would just make only one use case realization and describe the fact that there are two possible input devices inside that single realization.
Question 3.
For a business use case realization, I would use BPMN 2.0 or a UML activity diagram. These are well suited for business workflow specification.
For a normal use case realization, I usually make a sequence diagram, where the lifelines in those diagrams refer to components defined in a common component diagram. In the left margin of the sequence diagrams, I usually write the steps of the use case in UML note symbols. The sequence diagram focuses on the interaction between components, using their interfaces. This gives a nice overview of the collaboration between components in the context of a particular use case.
For more information, please refer to my white paper Which UML models should we make?. The use case realization is described on page 19.
UML is method-agnostic. Even when there are no choices to make, there are different approaches to modeling, fo example:
Have one model and refine it succesfully getting it through the stages requirements, analysis (domain model of the problem), design (abstraction to be implemented), implementation (classes that are really in the code).
Have different models for different stage and keep them all up to date
Have successive models, without updating the previous stages.
keep only a high level design model to get the big picture, but without implementation details that could be found in the code.
Likewise, for your question, you could consider having different alternative models, or one model with different alternatives grouped in different packages (to avoid naming conflicts). Personally, I’d go for the latter, because the different alternatives should NOT be detailed too much. But ultimately, it’s a question of cost and benefits in your context.
By the way, Ivar Jacobson’s book, the Object advantage applies OO modeling techniques to business process design. So UML is perfectly suitable for a human solution. It’s just that the system under consideration is no longer an IT system, but a broader organisational system, in which IT represents some components among others.
UML has collaboration elements to show different implementations. The use cases are anchors since the added value for the actors does not change. However, you can realize these use cases in different ways. And that is where the collaborations come into play. A collaboration looks like a use case but has a dashed border. And you draw a realize relation from one or many collaborations towards a use case. Inside the collaborations you show how the different implementation's classes collaborate (hence the name).
P.213 of UML 2.5 in paragraph 11.7 Collaborations:
The primary purpose of Collaborations is to explain how a system of communicating elements collectively accomplish a specific task or set of tasks without necessarily having to incorporate detail that is irrelevant to the explanation. Collaborations are one way that UML may be used to capture design patterns.
A CollaborationUse represents the application of the pattern described by a Collaboration to a specific situation involving specific elements playing its collaborationRoles.
Edit:
Final outcome based on suggestion given by #qwerty_so
This is my use case diagram for View Repository in Source Code Management System.
This system is part of Project Management System.
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).
Seidl, M., Huemer, C., Kappel, G., & Scholz, M. (2015). UML # Classroom: An Introduction to Object-Oriented Modeling. Cham: Springer International Publishing.
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.
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.
I have a question about uml and extend notation of use-case.
How I can extend all use case.
For example if I created a connection down use case that extend almost all use case, but I don't want to connect all with the notation on the use case diagram cause is very orrible to see. How can I do?
First of all: the importance of Use Cases
Modeling Use Case Diagrams (Use Case Modeling) is SO important step in Software Analysis and Use Case Modeling should be performed by professional Analysts:
All estimations (Time, Budget, Resources and etc.) are performed based an Use Cases.
In some Use Case Driven Methodologies, all subsequent steps are based on Use Cases.
and etc.
Secondly: Knowing Use Case Modeling Traps.
In Use Case Modeling there are some traps that we need to conside related to your question:
(Trap #1: Use cases that users don't understand.) (see reference 1)
Use cases are a way to represent user requirements, which describe
what the user needs to be able to do with the product. Use cases
should focus on tasks a user needs to accomplish with the help of the
system, so they should relate to the user's business processes.
Your users should be able to read and review use cases to find
possible problems, such as missing alternative flows or incorrectly
handled exceptions. If users cannot relate to use cases, there's a
problem. Perhaps they're written too much from a technical, rather
than business, perspective.
(Trap #4: Describing specific user interface elements and actions) (see reference 1)
Write "essential" use cases that describe the interactions between the
user and the system at an abstract level, without incorporating
user interface specifics. The use case description should not include
a screen design, although simple user interface prototypes can be
valuable to facilitate the use case exploration.
(2. Not having clear business goals for every use case) (see reference 2)
(6. Specifying use cases in too much detail) (see reference 2)
Thirdly: Use Case Modeling is in the Requirement phage of methodologies.
We should not put common implementation methods in Use Cases. Common methods in implementation handled by other diagrams in next steps of methodology. (maybe in Design Model) So, if we put all common methods in Use Case Model, the number of use cases increases a lot. (and our estimation as mentioned in first part goes wrong)
You can't - and it's nonsense. A use case shows added value for an actor. Extensions to use cases are very rare. In most cases people try to apply functional decomposition and mistake a step of actions recurring in multiple use cases as "partial" use cases. They aren't! If you are trying to do what you describe you went the wrong path. You should instead think why and where your use case synthesis broke.
I strongly recommend reading Bittner/Spence to get the right idea what use cases are all about.
You can use use inheritance.
Something like this, use cases B and C are extended since this is inherited.
But as #Kilian said, it would be interesting that you explain why you need a such model.
hello, my first question is how I can place cases to better readability? I want to make this diagram fit on a A4-sized paper.
But I am aware that this diagram may be badly made, so I ask you to advice, maybe I should share on the smaller part?
You need to to connect a use case only to its primary actor. So eventually you have to create a common role where the UC is used by this common actor role. Then your specific actors inherit from this common one. Like in #Amir's example International Student inherits from Student.
I'd simply up-vote the latter example but it has <<include>>/<<extend>> which is no favorable with use case synthesis. Moreover it uses a generalization which is very bad practice with UCs since a UC represent an individual added value and inheritance from added value does not make sense (unlike in a class context).
I don't understood your language (In your use-cases). Generally most of time we have some common feature so You can use inheritance in UML diagram. For example if you have different kinds of students (or Actors) that have some common feature you can do something like below picture:
I think there is too many of use cases. I had the same problem. Try using CRUD - https://books.google.co.uk/books?id=gKHfVZn1CkgC&pg=PA367&lpg=PA367&dq=crud+use+cases&source=bl&ots=g7C2qnzunP&sig=F3OtpNWT29NFyqFvmO-MBtTG98k&hl=en&sa=X&ved=0ahUKEwjAmKifh9_OAhWpCsAKHV9pA344ChDoAQg4MAU#v=onepage&q&f=false
Also, you can divide your diagram into few use case diagrams for each actor. Or put all actors on the one side of the diagram and use cases on other. Hope this helps.
I completely agree with the given suggestions (CRUD, inheritance and responsibility by roles) and I additionally recommend not to try to create an overview about the whole universe. Instead, try to separate your use cases into groups based on similarities, differences etc. and explain your modeling on smaller pieces.
Avoid too complex structures and mutual/cyclic dependencies - they are almost always a sign of poor design. Remember, you have to implement and test every connection in your diagram somehow. Less connections, less effort, less errors.
On a Use Case diagram can you show things that an actor cannot do, for example because they won't have permissions to do it?
Or is it just implied due to the fact that they won't have a line joining them to the particular use case?
If the Use Case you are diagramming is the case where an actor attempts to do something that is not permitted and is then denied, then yes, I would show it.
Otherwise, I would stick to only including things that are actually part of the use case.
No. An Actor would be connected to everything that he can do. If the Actor can't do it, then it's not shown.
This is what alternate paths are for. The basic path (a.k.a. happy path) will show what happens when the correct Actor initiates the Use Case. In the alternate paths you can show what happens if the wrong Actor attempts to initiate it.
You might model Role actors that can do the task. You could then have another use case that has the original actor attempting to acquire the given Role.
IMHO this question and most of the answers give a wrong impression about the way use cases should be used.
Use case was intended as a requirements technique that uses natural language. It is most and quite effective that way.
It can be a thoroughly destructive technique when it is combined with too much UML/modeling. Structured modeling of use case texts for example by modeling main and alternative flows using UML Activity Diagrams is a tried and tested way for example to create Use Cases of Mass Destruction.
A use case diagram can be useful but we should remember the purpose of use case as a technique which is first and foremost to identify the user goals a system should support. Subsequently we can capture more details using natural language in use case texts using main flow, alternative flows etc.
Using diagramming tools we can visualize some simple information:
- For each user goal we can create model element type Use Case.
- Show system boundary using a box for the system with use case elements in it.
- Create a relationship between actor and use case to show the actor has a particular goal against the system.
Keeping an up-to-date list of actors mapped to goals is however of secondary importance. Doing a stakeholder analysis, drawing up lists of actors is a means to identify the users goals. After user goals have been identified it is strictly speaking not longer necessary to keep the lists of actors around.
If we are asking questions about how to put user permissions in a use case model we are most likely trying to capture too much information. We should abstract model elements away so that the model does not try to answer/capture these type of detailed design questions.