Considering this situation:
...when an order is placed there is a check for availability, if is passed the preparation will start else the order is refused.
If the customer decides to pay with a credit card before starting the preparation the price of the order is locked on the credit card.
When the preparation is completed the order is delivered and if more than 30 minutes from the placement of the order have passed there is a discount of 50%.
My doubt is how to model the if condition in a state machine diagram, I would model it in the following way but I'm not sure it's the right way:
How should I model if conditions in a state machine diagram?
On a UML state machine diagram, conditionals are associated with transitions. The transition has a 3-part label in the form of "trigger-signature [guard]/activity". Guard is the conditional and must evaluate to true in order for the transition to be taken. All 3 parts of the transition label are optional.
From your problem description, I might define 3 states named "Waiting for Order", "Preparing Order", and "Delivering Order". There is a transition from "Waiting for Order" to "Preparing Order" and that transition could be labeled "order placed [order is available] /". I opted to leave off the activity because, from the problem description, I don't see any activity associated with this transition. You could maybe draw another transition labeled "order placed [order is unavailable] / refuse order". However, this transition would start from "Waiting for Order" and return to "Waiting for Order" because we don't change states when the order is refused. In this transition I included the refuse order activity because I assume there is some actual activity associated with refusing an order.
Alternately, I have seen transitions drawn which include a decision diamond where the arrow leading into the diamond is labeled with the trigger, one arrow out of the diamond is labeled with [guard] / activity and the other arrow out of the diamond is labeled with [else] / activity. I'm not sure whether this is technically correct UML though.
I think that the conditionals that you put in the entry activities for your Preparation and Delivery states are pretty good the way they are. Because those conditionals seem like they are associated with the activity that occurs upon entry into those states rather than any state transition.
In an UML state diagram, an if-condition should be modeled as a choice element, represented by a diamond-shaped symbol. The outgoing transitions must be marked with the corresponding conditions ("guards" in UML terminology) in square brackets. A trigger (event) and a behaviour (action) may be additionally given as described by kkrambo.
Example:
This and this gives some good advice on choices (and state diagrams in general).
This diagram (taken from here) might help:
So to answer your question, you didn't do it wrong, it's just a matter of style and readability. As far as I know, UML doesn't really define a standard way to represent conditionals. So just go with what looks best and makes sense.
It is not possible to define conditions inside of state element of state machine. Review you diagram. I think , you should some information put on diagram. For example, use choice element to define alternative transition paths. Or draw detailed diagram for "prepare order" and "payment" behaviors from Preparation and Delivery states.
It is not always possible to put all information on the exactly one diagram.
Related
What are the differences and similarities between the state machine diagram and flowchart?
So far I found that the state diagram shows us the actual change in the state, not the process or commands like in the flowchart.
In a state diagram, the nodes are states and the arrows correspond to something that happens that triggers a change of state.
In a flow chart, the nodes are actions or decisions, and the arrows correspond to the flow of control, i.e. what happens next. Flow chart are not UML. The closest UML diagram is an activity diagram that allows you to meodell more precisely everything you can model with a flow-chart and more (since the arrows can also represent an object flow).
Both can be complementary: an action/decision in a flow-chart could trigger events that cause changes of state. But it's not necessarily one for one: an action may cause several state changes without any evidence in the flow-chart that these may happen.
Short and simplified example:
Imagine an Order object. It may have the state received, delivey in preparation, delivery complete, invoiced. Each of these state tells what can happen next with the order. That'll be a topic for astate diagram.
Imagine a flowchart. These are different actions happening in sequence: Get an order from customer, Pick items of the orders from the inventory, Send items to the customer, Are all items sent?, if yes, Prepare and send invoice, if no, Find missing items and then go back to Pick items ... and continue from there.
As you see: both can tell the same story, but from a different angle with different details.
As you mentioned, a State Machine Diagram focus on display from which state to which state the execution goes based on the input.
Although a State Machine can be handled as a specialized form of a flow chart / activity chart.
My requirement : I want to come up with a suitable UML diagram based on the case which is described below. I need to know which UML will best suit this condition.
The case : Two object A and B in the form of "Application Forms" interacts with each other.Certain event in object A triggers a state change of object B.Both object interacts with each other for a Use Case.
I tried using State Diagram but it fails as here 2 object interact with each other to change the state of one object, whereas State diagram is suitable to depict state change of one object only without showing interaction with another object which is causing state change.
My requirement is to show both interaction and state change together in the same diagram.Is it possible?
Any suggestion on this which UML diagram is suitable for this?
UML uses two different diagrams for each behavior, one for State (State Machine Diagram) and one for Interaction (could be the communication diagram or the sequence diagram).
Since the Interface of a class doesn't change when it's state changes (by applying the State Pattern for example), the interaction should not really change from the perspective of the caller, sure, internally all kinds of things might be going on, but that should not really matter.
The way I'd model this is to describe which states your objects are in and which scenario will play out. That will result in a few interactions and possibly state changes. Then pick a new scenario, either using the end-state of the previous one as a starting point, or describing a new starting state.
That way each scenario is clearly defined, the interaction diagram shows how the objects interact, and multiple State Diagrams with the active state highlighted can show the changes in state and thus behavior of the different objects.
There is no diagram that gracefully combines both, since one (the state machine) is a static diagram, showing all possible options, while the other describes the interaction.
Sure you could play around with creative naming, as suggested (ObjectA/State) as your different objects in the interaction type diagrams, but it would not result in a very clear picture. What you're trying to describe here is a story, a sequence of events and how those events impact the different states of the objects. So your scenario's are the story on a high level, the communication diagrams the stories on a much more detailed level and the state machine diagram the snapshots of specific situations.
Model your states in the state diagram as such: (Object / ObjectState).
For example:
States (A/uninitialized) , (A/initialized), ...
Should work then.
State diagram, sequence diagram, communication diagram and the whole answer by #jessehouwing is fine, but I think there is an easier and more natural way:
(1) http://agilemodeling.com/style/activityDiagram.htm, Figure 3. Submitting expenses
Note that this is UML 1.4 activity diagram. Current UML notation is slightly diferent. Dashed lines represent Object flow : Chapter 3.90.2.2 Object flow ...Objects that are input to or output from an action may be shown as object symbols. A
dashed arrow is drawn from an action state to an output object, and a dashed arrow is drawn from an input object to an action state. The same object may be (and usually is) the output of one action and the input of one or more subsequent actions...
and (2) http://www.uml-diagrams.org/document-management-uml-activity-diagram-example.html
show an examples of how you can combine object states and UML activity diagram. The pictures are activity diagrams and the orange rectangles highlight points where objects with states (the part in [some state]) are shown. The purple rectangles show authors who were robbed.
i am currently doing an dynamic model for my ojt project. but i am stuck on a particular problem, my idea of a solution just seems overly complex.
to explain it in a different context, lets say i have 2 classes: customer and salesperson. the customer is buying something from the customer. but before everything is settled, they have to undergo a series of activities. after each activity, both the customer AND the salesperson have to chance to back out of the transaction. put in a diagram it looks like this:
is this correct? how about when i have like 50 possible activities? then that diagram will become very unreadable. what is a good way to solve this?
If you look at InterruptibleActivityRegion in the UML spec (section 12.3.33 of UML 2.4.1 superstructure ), it gives a similar example of cancelling an order at any point before the transaction is agreed. Within the interruptible region, which is notated as a dashed rounded rectangle with a Z shaped arrow coming out of it, all the activities may be interrupted by the event associated with the arrow - in your case backing out - and end up in the interruption handling activities.
You should use interruptible activity region. For a quick reference, see this sample diagram:
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.
When drawing state diagrams, how do you know which states get put in boxes and which states are for the transition arrows? I noticed that transitions are states too.
I'm looking at figure 1 on this page:
Transitions are NOT states. Transitions are the events that move an object from one state to the next. States are defined by the value of variables in the object and by the behaviour of the object. Take for instance a Student object that has a value "new-waiting for approval" value. That student is not allowed to register for or attend classes. But the same student may be allowed to register for and attend classes if the value changes to "approved". What's the difference? The student object actually has two states.
What causes the Student object to move from one state to the next? The event "Approval Arrives" maybe. So Approval Arrives go on the arrow between two states.
'Transition arrows' in the diagram are not states, they are "TRANSITION/ACTION/HAPPENING". For e.g. in the mentioned figure, "Scheduled" is the state, open is action after which it goes to "Open for enrollment" state. This "open" transition can be replaced more verbose with "is being opened"
Unfortunately, the transition actions like scheduled/open are very easily confused for a state as well, but that is not the intent.
At first you need to identify objects in your system. Among those objects, You need to select objects which have probability of change over the time.Then You need to draw state diagrams for all those selected objects separately.Boxes represent the states of that object and arrow represents the activity which causes to change the state of particular object.
I agree of one point, in specification , on some example, transitions looks like state.
For me "selectAmount" is not exactly a state name ...