Does contracted user case contain system borders? I mean: does it contain something like: machine doing biscuits, or just selling.
According to UML standard, every use case element MUST have at least one association with an actor element.
So, if you want to show something as border classes, i.e., elements that are connected to user and elements that are not connected to user, it is impossible. EVERY use case shown in UC diagram must be connected to user.
The UC diagram is not for showing inner, invisible for user behaviours. Its purpose is to define the subject (according to UML standard, the product you are working at) by defining all its external behaviours.
A system on UC diagram is shown as a rectangle. Its borders contain the use cases that belong to the system. The same for subsystems, components and packages on the UC diagram.
So, a machine whose functionalities only support other machines, but never works with Actor (human or external system), is NOT a subsystem in UC diagram terms. Its functionality is not a use case. If you'll try to show it somehow here, you'll get a very bad and unreadable UC diagram. Show it on component and deployment diagrams.
You have to depict the relevant use cases for each actor. So what are your actor(s) and does it make sense to associate them to "machine doing biscuit" or "selling" use cases?
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.
Im new in UML,
I am recently in charge of a web application, this application manages projects through a flow of states. There are multiple users within the application and each of them can intervene in the flow in a certain state.
Therefore I want to represent this information through a state diagram for me and for future developers do not have to ask the same question again.
My question is: How do I represent the different actors in the state diagram and their intervention in each of them?
Do I need to create a different state diagram for each actor?
Is there a diagram to do this that you do not know?
Thanks.
This is my example diagram and how an actor can pass from stateX to stateY
You try to oversimplify your model.
Each actor has certain system functionality that they can run. These single functionalities are called Use Cases (UC) and you present them on a Use Case diagram. This diagram shows which Actor can perform what Use Case but it does not show a relation to a state. While each Use Case can have pre-conditions defining what has to be true before the UC can be performed and post-conditions declaring what will be true if the UC ends successfully (which in your case would both probably be something like "System is in State A"), UC diagram does not support showing pre- and post-conditions. You can always add them in the notes attached to a UC.
To have a clear view of the system State Machine you can use two diagrams. One will be UC diagram, the other one will be State Machine Diagram or to be more specific Protocol State Machine. Then on State Machine you depict which UC causes what system State change while UC diagram provides information which Actor is eligible for running specific UC.
Finally you can use Sequence Diagram if you want to model how specific flow of interactions in the system impact changes of the system state. You can present states and actors on a single diagram here, but it is not designed, cannot and should not be used to depict all possibilities on a single diagram.
Disclaimer
Next part of my answer is opinion based
/Disclaimer
Most probably I would use UC diagram and SM diagram together according to information you've provided.
On the notation
A side note to your diagram - ovals are used only on UC diagram and represent Use Cases. They are not associated with each other, only with Actors.
States are presented as rectangles with rounded corners (both in State Machine Diagram and Sequence Diagram).
According to UML context diagram context diagram doesn't exists.
So my question is which one of UML diagrams is good to show something like this and how to paint this?
I've just found the following definition: http://en.wikipedia.org/wiki/System_context_diagram
That's probably what you need. :)
A context diagram defines a boundary between the system, or part of a system, and its
environment, showing the entities that interact with it.
There is no single diagram in UML that would map to this definition, but I have some good news - there are several diagrams (out of total of 14) that can show the frontier between the system and its surrounding world from different perspectives. This is much more flexible than only a context diagram.
First of all, I would mention a special UML element - a boundary. It can be used in any diagram type to show some kind of delimitation. You might want to optionally use it to visually delimit between the system and its environment, especially in situations when this is not explicit.
The following diagrams can show the boundary between the system and its environment:
Use case diagram (your example) support the context explicitly on the functional level. Use cases are elements of the system under development, while the actors are extern entities (systems or human users). Before mentioned boundary is often used to visually delimit between the system and its environment.
Component diagram is used to model some kind of software modules (applications, DBs, external systems, libraries, etc). You can use it to show both internal and external components and the way they interact. A boundary can be used to clearly draw the separation line.
Activity diagram can show your system/business/usage processes. Some activities can be performed internally, others externally. Here you don't need the boundary, but the so called swimlanes to depict who does what.
Sequence/collaboration diagrams are another option. They show the communication sequences between several objects. If you split those objects in internal and external ones and wrap them up with the boundaries, there is another context diagram. :)
UML is flexible, there are probably further options, but I think this is enough to get the idea.
Names of your association are services. UseCase in center of diagram is context of services definition. See usecase diagram:
It could be done with a use case
http://en.wikipedia.org/wiki/Use_case
EDIT:
Reconsidering it, use case diagram should be the next step once the operations are defined so first you shouls make a system sequence diagram.
http://en.wikipedia.org/wiki/System_sequence_diagram
If you're happy with going into the not complete superset of UML that is SysML, you can have proper Context diagrams there.
However, context diagrams in SysML are simply Block Diagrams showing system context… and Block Diagrams happen to be the same as UML2 Class diagram, where the classes are of stereotype «SysML::Block».
So you can define your context diagram in terms of aggregation of blocks to your system, with the relevant stereotypes, basing it on UML2 Class diagrams.
I tend to use collaboration diagrams for this. So for each major scenario of each use case, draw a collaboration diagram showing the actors, with the application as a single entity in the middle, and messages travelling around that show how the application interacts with the actors in order to fulfil the scenario.
(I don't put too much detail in the messages -- I only want to show that there is a delegation of responsibility and some kind of interaction, but I don't care about details of actual messages, views, data etc.)
I find the context diagram does have a particular appeal. It sits well with business users, showing them the scope & parties of a system in a very easy way. So, I tend to create a context diagram, even in contexts where UML is prevalent.
I have a equipment which I am representing with a class and there are two actors a remote and local operator who can put the equipment on or off. Both actors will use the functionality of the equipment. But How do I now represent them using sequence diagram, since if I draw an event from both local and remote its going to show at the equipment the one happened after the other but in reality two actors are using the same function and can invoke it any time. So how do I represent the two actors in the below sequence diagram.
P.S. The RAN40L is the equipment and CMS is remote operator and Simulator Operator is the local operator.
As it happens I have extensive experience from the defence industry, including naval CMS, so I am familiar with the domain.
The crucial question is, as always with UML, what you want to show in the diagram, which of course ties in with what you are showing in other diagrams. No diagram is ever read in isolation and you will never capture the entire radar functionality in a single sequence diagram.
Remember that a sequence diagram is intended to show things happening in a strict sequence. It is possible to show some rudimentary concurrency using the appropriate fragment, but if you want to show that the two actors do exactly the same thing, that the sequence is in fact one and the same in both cases, then the sequence diagram is the wrong place to show that.
Assuming that this sequence is intended as an elaboration of a use case, then the solution is to replace the two actors with a single actor, eg "Radar Controller". This actor can then be specialized into CMS and Simulator, which makes sense if the radar is unaware of, or unconcerned with, who is interacting with it in some (use) cases but not in others.
If the radar never makes the distinction, there shouldn't be two actors at all. The actors must make sense to the system they're interacting with, otherwise there's something wrong with your actor model.
So one solution is to structure the use cases as below.
http://sdedit.sourceforge.net/images/webserver.png
This is a good example where two actors are used. It is default to put one actor to the opposite the other (this is not done in the example).
Actor is considered to be just another object in the sequence diagram. You can plase arbitrarily many actors and use them just like any other object, no restrictions in this sense.
There are some stylistic guidelines though, most of all regarding Actors positioning on the diagram. It is a common practice to show the actores on the border of the diagram, keeping internal system objects inside. Moreover, human actors are typically shown on the left side, while system actors are kept on the right. Actors should not be "mixed" with system objects. Here is a simple example:
Everything in behavioral diagram is executed after behavior defined by diagram started.
If actors interacts individually, and their interaction are not moxed in single execution, you must draw diagram for each case.
I would say you need two diagrams, each for one actor.
Is This use case is correct/proper according to UML? if not please give some input to improve it..
The ways we can look on it as the boundary value "Use Cases" can be described something as "Release Phase 1"?
Writer Module/Reader Module should be proper Ator?
alt text http://img190.imageshack.us/img190/6708/usecaseh.jpg
This diagram is telling me that there is something external to the system you are developing called a "Writer Module". The Writer needs three Use Cases, for example Initialization.
Similarly another actor needs Check Status and StackUp.
If that is what you intended to say, then this diagram works. Do you really mean it? Does only the Writer module Initialise the system? Or does the system initialise itself? Can the Reader check whether the system has been initialised, before it has been initialised? Is there another Use Case?
Small improvement: make the Use Case names match in their parts of speech. Initialisation is a "Thing", Check Status is an "Action". Perhaps Initialize System might be better? "Stack Up" not "StackUp", be consistent.
Normally the reason you group the use cases using a box is to show what system is helping meet or realize the use case. It is formally known as a system boundry ("The system you are building". Normally the systems, modules, etc that are actors are more black box, existing, or use only. If there are many new or modified systems this definition gets confusing.
The other comments are semantics of what you are showing, but are not sytax, still important.
Page 103 of Martin Fowler has a diagram and discription that uses the system boundry concept and system actors.
To pick on an example: this diagram says that Check Status is a scenario with two participants, a Writer and a Reader. Is that what you want to say?
Also, I don't remember seeing boxes around (sets of) Use Cases in general.
Use cases are meant to show how someone uses a system to get something of value. Actors always represent persons, in the sense of an independent being who has goals and is capable of seeking something of value.
Actors are represented in one of several ways, either directly by name, or by inclusion through a role, or by proxy in the form of an agent acting on behalf of a person or role (the "system" actor). Regardless of the form, the actor is always independent, and always capable of "acting" upon the system to achieve its own ends.
The diagram you have here is NOT a use case diagram. "Modules" are not independent, goal-seeking entities, they appear to be simply components of some system. They are not capable of "seeking" anything, they are just implementation details.
The diagram you are probably looking for is the Deployment diagram (if you want to model how specific components are wired together), the Activity diagram (if you want to model application logic), or the Class diagram (if you want to model the formal relationships between components).