I am new to the world of UML and have so far learnt the basics of use case, activity and deployment UML diagrams. I have a requirement of where users interact with a system e.g. user sending an email, which is then processed by a system and then sent to an agent (person) who then responds and interacts once again with a system.
I am having a hard time picturing these requirements and whether it should be a combination of use case, activity or deployment. Can I intermingle them? What is standard practice?
As you know, use cases are used to capture requirements. When identifying and detailing use cases, you look at the problem from the perspective of users. Only focus on what an actor expects the system to do. First step is to identify the use cases and actors and then detail the use case flows.
1- Identify the use cases and actors
In your example send email could be a use case initiated by the end user (your actor). What happens next (e.g system sending a notification to the agent) could be modeled as part of the flow of this use case.
Another use case could be the agent actor handling what they have to do after receiving the notification from the system (a prerequisite of this use case could be that a notification has been received).
Note that you could combine these two use cases together and have the agent as a secondary actor (secondary actor interacts with the use case but does not initiate it). Whether you do this or not, is a modeler's choice and depends on the size of use cases, number of use cases and many other things.
2- Detail the use cases
After identifying use cases and actors, you should detail use cases. The most important part is to detail the use case flow (step by step interactions of actor and system). This can be written as text or drawn as an activity diagram.
So to answer your question: yes it is possible and very common to combine activity diagrams and use cases; that is an activity diagram drawn to show the flow of steps of a use case.
Deployment diagrams on the other hand are totally irrelevant to the requirement elicitation phase. They model the physical structure of the system and how hardware components and software components interact.
In fact, it is very odd that you have learned component diagrams before class diagrams, sequence diagrams, state diagrams and many other diagrams.
Related
I'm stuck and confuse if I need to identify Database as an Actor since the database is given in the scenario.
I tried first to make it as an actor since based on the scenario, the data needed is from database. I Also tried to create a use case for the whole scenario but not sure if correct.
Here is the link of the scenario: https://justpaste.it/7tljo
The Use Case Diagram I created:
Is the database an actor?
A database should in principle not be an actor in a use-case. Two reasons for that:
A database is in general a component used to implement a system, so it is part of the system's internals (even if it is bought from a third party and installed on a separate server). But actors must be external to the system.
Actors may represent separate systems that interact with the system. But some degree of autonomy is expected since they play a role in the case: either the system actor supports the use-case, like a human actor could do, or it uses the system for achieving its own goals.
More generally, some useful question to ask yourself about candidate system actors: does the business need to know? are users or business stakeholders interested in? is the system actor a system that would be useful if your system wouldn’t exist? could we imagine the same use case with a human user instead of a system actor?
Is the overall diagram ok?
Syntactically, the diagram looks ok. But it methodically break down features/functionality in smaller pieces. This is called functional decomposition: Although it is not forbidden by UML, it leads to complex and unreadable diagrams. This is why the use-case community recommends not to do this, and instead prefer to align use case on user goals.
Hint: if you start to think about workflows, order of operations or user interface components when you design your use-cases (e.g. review contract, approve contract), you probably should consider using an activity diagram instead.
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 a system in which there is a controller and a robot that interact to do something. The system is self sufficient, in the sense that once online and functioning, the entity that we called controller takes decisions on its own on what the robot should do, so every "use case" in the diagram is "made" by the controller. Since the actor in a use case diagram is, by definition, an external entity that interact with the system, what is the right way to model my system with this diagram? The controller cannot be an actor since it's part of the system, but then how can I model the functionalities?
If the system is really autonomous you can ask it: what is the added value you get? I bet it can't answer. So it's not autonomous on itself (like you hopefully are). It acts on behalf of its constructor or purchaser. And they will have an added value. So that's the one perspective.
Now you implement a system. This is intended to fulfill the added value. It does not matter whether this is done autonomously or not.
What you can do, is to detail the system and construct technical use cases. So to control visual perception you have sub-systems with own use cases. Or to sense something. But that is a different level and not to be mixed up with the business logic behind it all.
According to UML specification sensor can be treated as an actor.
Your system presumably is not a complete black box. It reacts on some external events (usually - timer first of all) triggered by some sources. Straightforward way is to introduce sources of those events (timer, accelerometer, valves, etc) as actors who are triggering scenarios.
In your case the only involvement of such actors could be potentially denoted to only triggering the scenarios. If so take a shortcut and do not introduce the actors, just write in the use case trigger: "pressure drops below ..."
You may or may not want to separate the system actor to the robot and the controller actors (i.e. establish System under Discussion one level lower). Who will be reader of your documentation? Customers are not interested in what's inside the black box, but two development team writing each of the pieces will push you to separate and define precise interfaces.
If you believe that a use case flow of events creates an actor, how would you model that?
I have a use case that creates a windows service, which (in my mind) is another system with its own set of use cases and actors.
At the moment it is not obvious from the use case diagram that an actor gets created as part of the flow of events.
Aidan.
Use case diagrams do not display a sequence of actions. There is no time dimension. As a result, it makes no sense to create or delete an actor.
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.