I’m working on a USE CASE diagram but I’m having problems modeling the following:
A user wants to inquire his balance, but he can do it by phone, SMS or IVR. How should I represent the different ways? Each one has different flows. Should I model just one use case for each one, or should I represent the different ways as extended use case.
If the three cases share flow to a huge extent (say >70%) I would model them as one use case. Otherwise it would be better to model three different use cases.
The point here is understandability. Cramming three different things into one is confusing, repeating the same three times is confusing as well (although probably less).
There is no right or wrong answer to your question. UML allows the same situation to be modeled differently. It depends mainly on the level of abstraction you choose for your use case diagrams.
You'd have a common use case with 3 extensions. You'd then detail each extension with sequences diagrams.
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.
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.
Is the diagram correct? Can more use cases be added in this diagram? Is there a need for include and extend functionalities?
The diagrams look ok and you can add more use cases at your wish. But for clarity sake it's advisable to split them into sub-domains where you can focus on a couple of somehow related use cases. Do this by creating different diagrams or using boundaries to split the sub-domains.
Avoid <<include>> and <<extend>>. Use cases undergo a synthesis an not an analysis. There are only very rare cases where one could use those relations in a useful way.
Can more use cases be added in this diagram?
This should not be your goal, therefore I daresay you don't want to ask this question. At least not anyone!
Instead, try to model the fewest possible UML entities without losing valuable information. Simplifying and splitting up diagrams into simpler parts is often way more challenging than modeling new entities.
The question is: Which information is required? You'll need to work that out with your stakeholders. Remember: YAGNI.
I'm using PowerDesigner and I have a use case diagram with one actor and 28 use cases, I'm looking for the best way to represent it in one paper.
I tried the vertical center alignment of use cases, but it takes a lot of space.
Can I split them in two or three packages or something like that ?
I have a use case with one actor and 28 use cases
What do you mean by this? A use case "with" 28 use cases?
In UML it is not valid for a use case to "contain" other use cases. If you did it like this, simply convert the containing UC into a Package with the same name.
Are these 28 UC maybe included in the first one ("include" relationship)? If so, this already seems to be strange. We should know more in order to eventually fix this.
There are several ways you can visually simplify similar modelling situations. In general, you should not have more then 6-8 elements (UCs) in one diagram, simplicity reasons.
Make several diagrams and show only related use cases on each one, with corresponding (in this case always the same) actor
Are all use cases on the same level of abstraction? If not, consider restructuring them in terms of converting high-level ones into packages which would in turn contain corresponding low-level use cases
Are use cases maybe too atomic (too low-level)? If so, group several related ones in a higher-level use case. This would reduce the total of UCs
Do you have some relationships between them?
If you post your current diagram, we could probably help you further.
i've been created the following diagram for forums system but i'm not sure if the relation between use cases and actors is correct.
so i want to know if my diagram is correct or if i've added too much complexity to my diagram. did i got my use cases relation with the actors correctly? well to better say, is it correct at all?
any help is really appreciated.
Not a bad effort for a first attempt, but I'd say it is a bit over complex. When you do analysis, using use cases or some other method, you really do want to keep it simple and avoid going into design mode, which is when you start thinking about relationships between things.
In my opinion, your actors should not be generalizations of one another. A "person who posts" on a forum is not a a more specific type of a "person who reads posts": they are different roles which the same person might take on at different times, not expansions on one another. So I'd advise you to drop those generalizations.
The same goes for the use cases themselves. Normally, use cases relate to one another by way of either the <<extend>> or <<include>> relationship, but generalizations or not normally used. Use cases aren't like classes and don't really have the option of being abstract, so the "manage" use cases need to make sense on their own, and they don't really do that. Your "concrete" use cases, on the other hand, make perfect sense.
In order to group related use cases together, it's a better idea to use separate diagrams and / or gather the use cases into packages called "post management", "site administration", etc. There is nothing which says you have to put all your use cases into a single diagram.
I support your method of use case diagrams. I struggled with this very issue a while back. To show each association from one use case to each of the actors was getting messy. By generalizing the actors, it consolidated the associations into a nice, easily readable format. Thus, the information is easier for others to consume.