I'm trying to create a Use Case Diagram of Order System. But I'm curious if the 'send notification' and 'add order' is connected since before ordering, the inventory will check for the stock. I'm thinking of connecting the two using 'extend'. What do you think?
Whenever you wonder if use-cases are related because of some sequential or causal relationship, you are no longer in use-case analysis, but in one of the following situations:
Functional analysis: you’re doing functional decomposition, i.e. breaking down a functionality in more elementary functions (e.g. the includes for Ship order): this is not forbidden but leads to very complex diagrams that are difficult to read and use in practice due to unnecessary details and mixed levels of abstraction.Solution: don’t! Simplify your diagram and focus on user’s goals.
Designing a flow of activities: this is wrong, since there shall be no order/sequential relationship between use-cases, and use-cases shall not be confused with events or preconditions(e.g. item is not out of stock) Solution: go for an activity diagrams, which are meant for exactly this kind of modelling.
misusing use-cases for user-interface design (suspicion that all the generate xxx corresponds to windows to show data to the actor): this usually leads to bad user-interfaces and incomplete analysis of the user’s goals.
I think your (impressive and comprehensive) diagram corresponds to the first two situations. I recommend to simplify, focus on the user goals, and for each use case that is more complex, make an activity diagram for the flow.
I am very concerned when I see in the table “use-case(process)”, and it appears that this is an exercise you are trying to do. This is plain wrong: a use case is an actor’s goal and not a process. Processes are typically modelled with activity diagrams. If this comes from an UML tutorial, then immediately change tutorial!
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.
I have this kind of situation where I have multiple actors which share the same use case.
I cannot figure out from which point of view I should write the flow of events and describe the sequence diagram of this specific use case, having more than one single actor.
You: I have multiple actors which share the same use case.
... from which point of view I should write the flow of events
Use-cases are goal-oriented. They are not supposed to be a functional decomposition nor a sequence of actions. It's not me, but Ivar Jacobson, the inventor of use-cases, in Use-Case 2.0:
A use case is all the ways of using a system to achieve a particular goal for a particular user. (Page 4)
So use-cases are meant to provide the big picture. Your use-case diagram should identify these independent goals. Of course, behind each use case, you have some narrative that describe the interaction between the actors and the use-case:
The purpose of a use-case narrative is to tell the story of how the system and its actors work together to achieve a particular goal. (...)
Use-case narratives can be developed at different levels of detail ranging from a simple outline, identifying the basic flow and the most important variants, through to a comprehensive, highly detailed specification(Page 47)
One way of describing this flow, is how Geert Bellekens explained in the comments: describing the scenario telling who does what in which order. A variant of this presentation is a tabular form: a column for the actor actions and a column for the actor actions.
Now, if you're at the beginning of the design, and especially if you have several actors, this kind of UC description forces you to make a decision about the way you design the interactions. A more creative variant is to describe essential use-cases: instead of describing the flow of event, you make a table describing mapping more in detail the intents (i.e. intentions) of the actors (in one or n columns) to the corresponding responsibilities of the system (in a separate column).
You can then start to think about possible sequences, but also about alternative sequences that could provide a better user experience or a more optimal flow of information. The flexibility is so high that you could even design voice-driven or NLP driven interfaces in which the sequence is not predetermined but could be different for each use-case execution.
I have a small UML assignment due Monday; it doesn't seem too complicated, and I'm not asking this site to solve it for me -- I'm just asking for clarification over a couple doubts of mine.
I'm just telling parts of the assignment because its content is probably not so relevant.
We're provided a basic use case where the actors "officer" (e.g. police officer) communicates with the actor "correspondent" in order to report an emergency. The use case is expressed in the form:
Use case name: Report emergency
Participating actors: Officer, correspondent
Flow of events: ...
Preconditions: ...
Postconditions: ...
Then we're given three scenarios that "refine" the use case. I say "refine" because they turn it upside-down: they involve team leaders, respondents, incident handling -- nothing that was even mentioned in the flow of events described by the very basic use case given.
On top of these scenarios we're given ten "events" (i.e. they basically chunk the three scenarios into ten easily recognizable sentences). The assignment asks us to make one collaboration diagram for each of these events.
I know that collaboration diagrams describe the behaviour of the system, i.e. how the different parts of the systems interact with each other. So I thought that, even with these "creative" scenarios given, I could make something out of them. But then this part comes:
"Collaboration diagrams should make use of controller, boundary, domain objects and other new fabricated software objects (e.g. data structure components) necessary to completely handle each event."
And then:
"Your assignment will be evaluated in terms of the quality of your design (i.e. modularity: low coupling, high cohesion)"
My questions are:
1) Are scenarios supposed to present so much new information compared to the basic use case?
2) Do I just have to draw ten simple collaboration diagrams? Using which classes?
3) Why are things like low coupling, high cohesion, domain objects, mentioned? What do they have to do with all of this?
1) A scenario is a detailed description of a use case. There can be several scenarios based on constraints. The use case itself just describes the sunny day scenario in a condensed format. The meat is in the scenarios.
2) Classes related to the UC can be extracted when going through the scenario. You will find text parts that tell certain functions need to be performed. Take these classes and place them in the collaboration diagram and connect them with the right message.
3) These are general design rules. Low coupling/high cohesion means good design (and vice versa). The domain objects are those which are in the center of the system and the sum of all use cases will deal with the sum of all domain objects.
Firstly, I'm still quite new to UML; but, highly interested and am attempting to learn as much about it as I can.
With that said, I’m in a situation where I’m directed to assemble a ‘Context Diagram’. I feel as though I understand the concept of what a context diagram is and how to create one, so I think I’m ok there. Basically it is identifying the system and the components or actors it will interact with. It applies the focus on the system, and not the actors. Kind of like a Use case diagram, but not focusing on the actors. If I’m wrong, please tell me.
I read somewhere that Context Diagrams are not actually part of UML. I also read, somewhere, that, if you use a Context Diagram, it falls into the Component side of things. When I read about Domain models, it seems like it should be there.
For my current situation, I know a simple answer is to simply create the diagram and move on, as that is all that is required. But, for my interest to better understand and leverage UML, I know there is a right way and a wrong way. If I were in a case of a bigger project, what would be the right way?
Now here is where my question begins. I’m using Enterprise Architect, create my project, and start to create a model. Does it belong in a Domain Model or Component Model? What is the difference between these two? Or even more. As it is an aide to help identify requirements, should it go there? Or does is just simply depend on what and how I want to convey it?
The Domain Model is where you standardize the vocabulary that everyone on the project will use to communicate in a consistent manner. The development team are experts at software development, but they may not have any experience in the domain (e.g. banking, air traffic control, healthcare) in which they are being asked to work. So you get domain experts and modelling experts together to build a model that describes the domain, answering important questions like "how are account fees calculated?" and "how does a pilot know what route to follow?" and then this model is then passed to the development team to provide them with the important domain knowledge that they will need. I would use UML class diagrams to create a domain model.
A Context Diagram shows the system being modeled in relationship to external systems. It could show data flowing in from and out to external systems, modeled by a data flow diagram (not part of UML). It could show behavioral interactions between the system and external "actors", modeled by a UML use case diagram. It could show the system's physical connections to other systems, modeled by a SysML block diagram. Whichever you choose, it will be on page 1 of your design document, so choose wisely!
You (can) create context diagram by making any element composite. Then drag the element itself onto that diagram as link (not instance!) and highlight it by making the border a bit thicker. Finally insert related elements from the context menu (differs from EA version to version). Layout the diagram and now you have your element in the context.
A domain model is usually a class diagram showing the (business) domain on a higher abstraction level.
As you have said, Context Diagrams per se are not part of the UML spec. There are plenty of ways to do a context diagram, but the UML way is to use a Use Case diagram, with or without supporting narratives and scenarios. Start with this, which is a broad overview of different types of Context Diagrams. Then, investigate use case diagrams, use case narratives, and activity diagrams. If you need to go into more detail than a use case narrative can easily do, get into use case scenarios and sequence diagrams. Here is a pretty good use case narrative template (feel free to leave out sections such as "scope and level" if they are more than you need, and consider adding information about what triggers the use case and where you go when you finish it--these two are required for scenarios if you go that far).
Keep in mind that use case narratives and use case scenarios are often confused. (Some people will say that I am the confused one; I will invite you to judge the matter for yourself.) A narrative is an explanation of an entire (single) use case, and may be supported with an activity diagram. A scenario is an explanation of a single path through a single use case, and may be supported with a sequence diagram.
For example, a use case will generally have a basic flow of events, along with a number of alternate flows. The narrative describes the entire process. The basic flow and each alternate flow would each be a separate use case scenario.
I suspect that it's unlikely that you will have to get down to the level of use case scenarios. You will probably want to put a use case diagram together, and possibly prepare narratives and activity diagrams for each of the use cases in the diagram.
I'm learning UML by trying to simulate how a car service garage works with diagrams and documentation. One problem I have is with postcondition (or rather, GOTO) statements.
Is the dashed line << include >> relationship only for preconditions? Can Use-case bubbles connect to eachother and follow a logic path?
So this is what I have so far..
1) Is the 'Settle Payment' bubble in the wrong place? Should it have been << include >>ed to the other bubbles?
2) Should I associate the 'request service' bubbles to the technician too as he will be the one fixing the car?
Image
Use Cases are like classes. They have inheritance (extends) and relationships like includes and uses.
Preconditions are common relationship constraints. Some of us write the preconditions and postconditions in the text of the use case. You can draw it, but it isn't required.
Do not try to sequence the use case bubbles. That's what activity diagrams and sequence diagrams are for. That's what narrative text is for. That's something the users already know.
Also, don't waste a lot of time treating the use cases as a super-high-level programming language. Remember, the actors already know what they're doing; they don't need help sequencing things.
You need to focus on capturing the actors, the use cases, and basic "extends", "uses", "includes" among the use cases. Use Case models are not programming. The use case diagram is knowledge capture of "who" and "what".
Think of it as more like a security model that defines what the actors can do. Order, sequence, and other details don't matter as much as what the actors do.
When you have Actor associated with actor (like Technician and Front Desk), you're saying that the actors interact outside the system. You're saying that the tech never logs in to the system to do get their work or log their time.
If the technician actually will log in to get work and record time, then the technician participates in some use cases.
Use cases aren't programming. They're things actors do. Use cases are connected by virtue of being built in a big, common piece of software. You don't need to draw data flow or logic arrows among the use cases. They can all be largely independent.
When you design the system, you'll implement UI features and database features that connect the use cases in some sequence.