I am trying to properly understand regions as well as fork and join pseudostates in UML State Machines.
All examples I find are quite simple and I am not quite sure what is legal and what is not.
The UML Superstructure Specification (15.3.14 Transitions) states
The tail of a compound transition may have multiple transitions originating from a set of mutually orthogonal regions that
are joined by a join point.
Does this mean, that a join may only be placed at the end of a compound transition?
Does this mean in consequence, that a join may only be followed by a state but not by a pseudostate?
It also states:
The head of a compound transition may have multiple transitions originating from a fork pseudostate targeted to a set of
mutually orthogonal regions.
Does this mean, that a fork may only be placed at the beginning of a compound transitions (i.e. directly following a state but not after a pseudostate)?
Chapter 15.3.8 Pseudostate does not help me answering these questions. Neither the Constraints section nor the Semantics section make it any clearer to me.
join vertices serve to merge several transitions emanating from source vertices in different orthogonal regions. The
transitions entering a join vertex cannot have guards or triggers."
If the incoming transitions don't have triggers: How do the transitions ever fire?
Example:
Composite state S1: in region one S11 is active, in region two S12 is active. S11 and S12 have transitions leading to a join. How does the join ever get reached?
Edit:
I stopped reading to soon. The answer to this one is "Through a completion event". These transitions are "completion transitions".
Also:
When "mutually orthogonal regions" are mentioned: Do these regions have to be the children of the same composite states?
More general: Can states only be concurrently active if they are placed in different regions of the same composite state or could - after a fork - multiple states be active that
are located in totally different composite states?
Fork and join stem from Petri nets. Along that net you have a virtual token that travels from node to node along the transitions. A fork will multiply an incoming token to as many outgoing transitions as there are. Only when all those tokens have reached the next join the machine will continue with a single token (unless this forks again with multiple transitions - but inside the fork line there will be one single token). You can imagine the line that represents a fork/join as a (1-dimension) box which momentarily holds a single token. This single token exists at the moment when all incoming transitions hold a token. This token is then multiplied for all outgoing transitions. Firing the new tokens takes no time. It happens instantly when the internal token has been created from the incoming tokens.
Unfortunately this concept is not well known and many modelers used it the wrong way. But I guess if you get the concept of the traveling (multiplied) tokens you will get the idea.
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.
I'm modelling an activity diagram for a project. Directly after initial node is it okay to use a decision node. I just google for it. But I fail to find similar examples even.
Eg:- imagine a person can Search for a dog name or Select the category animal, then dog likewise at the very beginning.......
One of my team mates mention that according to above example those are two different activities and we should create two activity diagrams for it.
This is allowed under condition.
The rules concerning the input flow(s) of a decision node are (formal 2017 § 15.3.3.6 Decision Nodes page 390) :
A DecisionNode shall have at least one and at
most two incoming ActivityEdges, and at least one outgoing ActivityEdge. ... If the DecisionNode has only one
incoming edge, then it is the primary incoming edge. If the primary incoming edge of a DecisionNode is a ControlFlow,
then all outgoing edges shall be ControlFlows and, if the primary incoming edge is an ObjectFlow, then all outgoing edges
shall be ObjectFlows.
Also knowing (§ 15.3.3.1 Initial Node page 387) :
The outgoing ActivityEdges of an InitialNode must all be ControlFlows.
that means in your case, and supposing there is no other input edge to the DecisionNode, all outgoing edges of the DecisionNode shall be ControlFlows, else this is not allowed
Your team mate isn't wrong. This is a design question which should have been clarified beforehand. Activities are functional parts inside of use cases. They represent scenarios like "sunny day", various error scenarios, etc. And again one step back the use cases represent the added value the system under consideration represents for its primary actor.
Now from your examples it's hard to tell what that system should be. Search for dog name could be a use case, but in which context? Is it to name a new dog or to search for an existing dog in a database? Same for Select animal category(and then dog?). Both do not make much sense as use cases. Once you come up with meaningful use cases you can tell exactly which steps the activities should have as actions. Only then you can have the need to decide. The decision which use case to actually use it outside the system and you wont see the steps done for it.
As a recommendation: Bittner/Spence have an excellent book about use cases which (unlike the UML specification) makes a lot of sense. There are also other well known authors teaching the same school (along Ivar Jacobson).
UML specs 2.5 says:
The effect of one ActivityNode on another is specified by the flow of
tokens over the ActivityEdges between the ActivityNodes.
But above definition is obscure; specially because tokens are not explicitly modeled in an Activity.
After reading 15.2.3.3 Activity Edges section of specifications, I think purpose of them is:
to capable the diagram to describe
it may wait for other token
or refuse flow
instead of entering next node immediately
Is it true? Also is it the only purpose of tokens? If it is true, why we do not use a decision node with a condition and a end flow node for showing refusing flow under that condition instead of token and guards? Or grouping information into larger objects node which carries all necessary data instead of using weight?
Activity diagrams and state machines are both derived from Petri nets. Giving a full description would blow this answer, so I try to boil it down.
A token is, so to say, a bit of information. It's atomic and can not be split. Rather it is created from a "big bang" out of an event which is defined in the context (shown usually by a large black dot). It travels along InformationFlow connectors (eventually blocked by guards where it has to wait) to nodes. Nodes have 1 to many InformationFlow connectors. A node becomes active when at all of its incoming InformationFlow connectors a token has arrived. When the node finalizes it sends single tokens along all its outgoing InformationFlow connectors (at least UML actions do so which is called implicit fork). There are special nodes like fork and merge which behave a bit different (see the specs). Finally tokens can fall in a sink (usually a circle with a fat dot inside) where they just vanish as they appeared.
So from a single token (not going to explain the details/issues of multiple start points here) emerging from a start node this token travels in the net, eventually creating other tokens all circulating until (usually) all tokens have gone to sinks. During that the net is said to be active.
tl;dr No, your assumption is not correct that way.
I was reading about statechart diagrams, which are diagrams that model the different states that one or more instances of one or more classes can be.
An object can go from one state to the other through a transition, which is represented using arrow with an event and eventually a action to that event over and respectively below it.
My problem now is that I don't understand exactly what are OR and AND decompositions in a statechart diagram. Could you please give me an explanation (since I've not found around any)?
I would really appreciate a concrete example with the corresponding picture or diagram.
The following picture is an example for an OR. Consider a token traveling from Initial to the Choice (diamond). Here the token travels either to the left or right guided by the constraints which test the condition checked in Choice. From then where they are they next transit through the following unnamed diamond to Continued. You might leave away the joining diamond and draw the transitions directly to Continued.
The AND condition looks like this:
The first Fork(the bar) duplicates the token and sends them to Either and Or. The Join behind these states waits for two tokens to arrive before it sends only one token further to Continued.
Fork and Join use the same symbol. They wait until all incoming tokens arrive and then send as many tokens as there are outgoing transitions. So they are actually some split personality. But mostly they are used the one or the other way.
I have the below UML activity diagram for a shopping cart use case. It has several decision and fork nodes but there are no corresponding join/merge nodes. Could you please show me:
how to correct the diagram by introducing the merge/join nodes.
how to modify the diagram so that a customer can repeat the process (of adding more products to the shopping cart).
Thank you.
You should look into the token concept. It is introduced in petri nets and also used in the UML activity diagram.
Decision nodes produce one token only, i.e. they follow just one outgoing path. To merge such paths, of which only was is followed, you can use a merge node. Which just looks like a reversed decision node and is able to consume exactly one token. A diamond with multiple incoming edges.
If you use a parallelization node to start concurrent execution paths, you have multiple tokens leaving the parallelization node. To merge these kind of paths, you can use a synchronization node, it looks like a reversed parallelization node and has to consume one token per incoming edge.
(source: amg at www.lcc.uma.es)
Do you have an initial activity element anywhere? Makes it a bit easier to read. To your question, the merge should be used as opposed to having multiple connectors coming into the same activity. For instance, "Acknowledge Msg" should have a merge above it that the other branches can flow into.
As for how to make it repeatable, you may want an "Add to Cart" action, and prior to a "Checkout" action, have a Decision with guards for "Shopping Complete" (which goes to the Checkout action) and "Continue Shopping" (which goes back to "Enter Product #").