A homework question:
Use an appropriate UML diagram, to describe the process of using a self-service-checkout to purchase stuff from a shop.
The diagram should focus primarily on the required actions taken by the checkout software in completing the transaction.
I have chosen to do this as a activity diagram as it clearly shows the actions taken by the checkout software in completing the transaction.
Is this the correct approach? Any advice?
The requirement is to describe a process and focus on some actions. You can take this as a reflex: in UML, processes and process decomposition are best described with activity diagrams.
You can corroborate this conclusion, reasoning by elimination. Among all the UML diagrams, processes and actions are about behaviors of the system and not structure. So it's necessarily a behavioral diagram:
You can easily eliminate the use-case, because their focus is on objectives. Moreover there is no order between use-cases, which makes them a bad candidate to describe a flow of actions.
You can also eliminate the interaction diagrams, because the focus is on elements and their exchanges.
A state machine diagram can represent a flow of events or actions needed to complete some behavior. But the focus is more the state, and how the transition between the states is triggered. So it's more the opposite focus.
Related
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).
I know that an activity diagram is:
More simple;
More standardized;
Support concurrent flows.
compared to a flow chart.
But what are the possible reasons for using an activity diagram instead of a flow chart apart from those mentioned above?
An activity diagram is not simpler than a flow chart. A flow chart is a simpler (earlier) version of an Activity Diagram.
Flow charts were invented at least 20 years earlier and are commonly used by non-programmers to document workflows. Any business process where people have to make decisions can be described as a flow chart. So, for example, a clerk making decisions about how to file complicated information might have a flow chart on the wall.
Because a flow chart is a subset of an activity diagram, there's actually no decision to make. A flow chart naturally grows into an activity diagram if you need to add more complex descriptions.
Sparx have a good explanation of the range of things you can describe in an Activity Diagram
A UML Activity Diagram is a type of "flowchart" .. in UML, with bells and whistles. There is no such thing as a "UML Flowchart". If using UML it is an Activity Diagram. If using something else, then something else is being used.
[UML] Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency ..
.. Activity diagrams may be regarded as a form of flowchart.
For better or worse, UML is a standardization. This is nice because it is well, "standardized", but also means that it is not appropriate for all tasks: the chosen "flowchart" model (and extensions thereof) might be a better fit for a particular problem/domain.
An activity diagram assigns responsibilities to the objects involved in collaboration using swim lanes. So the diagram clearly shows the work to be done by each object in collaboration.
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.
As i read through UML specification superstructure that there is sequence diagram and there is a collaboration diagram
so,What is the differences between
sequence diagram and collaboration diagram?
Sequence and collaboration diagrams both aim at describing the dynamic interactions between objects.
The information you can describe are basically the same, but the two models have a different focus:
Sequence diagrams highlight more the temporal aspect, by showing invocation and responses along a (vertical) timeline and by explicitly showing the activation time of objects.
Sequence diagrams show how objects communicate with each other in terms of a temporal sequence of messages. The time flow is the most visible aspect in these diagrams, as messages are sequenced according to a vertical timeline and also the lifespan of objects associated to
those messages is reported. The figure below (taken from our book) shows an example of a sequence diagram describing 3 objects (instances of classes Shipment, Invoice and PartList) and the messages exchanged between each other. Interaction diagrams describe execution scenarios of the system.
Collaboration diagrams aim at showing the communications that happen between objects, by defining messages that flow between each other. They basically consist of superimposing the communication actions upon an object diagram. The temporal aspect can be shown here too, by numbering the interactions with sequential labels.
A collaboration diagram shows the interactions between objects or classes in terms of links (solid undirected lines connecting the elements that can interact) and messages that flow through the links. This describes at the same time some kind of static structure (links and nodes) and dynamic behavior (messages) of the system. An example is shown below.
UML1: These diagrams are the same, but present data from different points of view.
UML2: The Collaboration diagram is renamed to Communication diagram (there were misunderstanding since people thought that Collaboration diagram was used to show collaborations).
These diagrams are almost the same, but present the Sequence diagram has much more possibilities for visualization (for example, combined fragments, state invariants).
Sequence diagrams specify interaction in a time sequence manner which may be among objects and/or classes. These diagrams are created during early elaboration phase where each flow of the use case is defined in terms of sequences , i.e. after each step what is going to happen next. This kind of representation is very helpful to understand & discuss the use cases with the customer, where both can come out with all possible functional aspects.
On the other hand collaboration diagram provides a direct interaction among the object. These diagram seem to used more in the design phase of the development when you are designing the implementation of the relationship.
There is a difference between sequence diagrams and collaboration diagrams. Sequence diagrams shows object interaction in timely manner(so no need of numbering the messages). But collaboration diagram doesn't show object interaction in timely manner. (need to numbering the messages).
NOTE:
Now Collaboration diagrams are also called as communication diagrams.
A Sequence diagram is dynamic, and, more importantly, is time ordered. A Collaboration diagram is very similar to a Sequence diagram in the purpose it achieves; in other words, it shows the dynamic interaction of the objects in a system. A distinguishing feature of a Collaboration diagram is that it shows the objects and their association with other objects in the system apart from how they interact with each other. The association between objects is not represented in a Sequence diagram.
Link : http://www.developer.com/design/article.php/3102981/Collaboration-Diagram-in-UML.htm
Use sequence diagrams to show time and to emphasize the sequence or
the ordering of the interactions.
Use communication diagrams to emphasize the links among the
participants. Communication diagrams can be a helpful supplement
to the object diagrams.
I am really unable to understand the real difference between these 2 diagrams. I mean both of these deal is "states" but I am not sure what deals with what?
It might seems so, but the difference is, activity diagrams describe activities and state charts describe states. So those models are orthogonal - you might imagine there is an activity between two states (something that occurs during the transition) and you might say there is a state between two activities. This is rather a simplification, but I think it might suffice to explain the difference, which is primarily focus, both diagrams are for describing behaviours.
An activity diagram is a special case of a state chart diagram in which states are activities (“functions”).
Two types of states:
– Action state:
-- Cannot be decomposed any further.
-- Happens “instantaneously” with respect to the level of abstraction used in the model
– Activity state:
--Can be decomposed further
--The activity is modeled by another activity diagram
For examle an elevator ride.
State chart could contain states such as: entering, standing still, exit, arrived.
These state transitions are caused by activity diagram events.
And events in activity diagram could be:
Walk in to the elevator, push button to correct floor, walk out of the elevator.
I would say these two diagrams overlaps each other.
Activity diagram is used to document the logic of a single operation/method, a single use case or the flow of logic of a business process. It is equivalent to flowchart and data flow diagram from structured development.
The state diagram depict (show)the state of objects as their attributes change from state to the other state. State chart modeling is used to show the sequence of states that an object goes through, the cause the transition from one state to other and the action that result from a state change.
Activity diagram is flow of functions without trigger (event) mechanism, state machine is consist of triggered states.