I was wondering if you could help me clarify two aspects regarding multi-instance state machines.
First question
Consider an example state machine SM1 containing one state A:
On the left, transition start creates a new instance of the state machine. Transition stop terminates the instance.
There can be multiple instances of state machine SM1 running in parallel, e.g. 5 instances.
Now, what I want is a transition that would terminate ALL state machine SM1 instances that are running at the given time.
E.g. we create five state machines A and then transition stopALL would terminate ALL of them at once.
Is such behaviour permitted by UML specification? If yes, is there a graphical notation to unambiguously represent such a behaviour? I could not find the answer in the UML specification document.
Second question
Consider a multi-instance state machine SM2 with state A and one transition startStop:
The behaviour of the transition is as follows: upon firing, the transition creates a new instance of SM2 and terminates an existing one.
Is such behaviour permitted by the specification? Is there an unambiguous graphical way to express such a behaviour?
There is no special UML method but standard UML tools are absolutely sufficient. You need to broadcast a terminate signal (on state machine diagram you can represent it by behaviour on a transition that should terminate other instances). Then you just need to model that on terminate reception the state machine goes to final state.
Terminate All Example
Note that the behaviour after slash (/) is a behaviour invoked on a state transition i.e. when a state machine changes it's state into final the behaviour sendStopAllSignal is invoked which in turn should be described on a class diagram (with probably corresponding activity diagram)
Similarly you need to have a receiveStopAllSignal behaviour included in class diagram.
Terminate Existing At Start
This is similar situation - you need to have both sendStopSignal and receiveStopSignal modelled elsewhere.
Note however that such naming convention (sendAbcSignal for behaviour of sending/broadcasting signal Abc and receiveAbcSignal for behaviour as a reaction to Abc signal reception) is quite common, useful and self-explanatory (i.e. you probably won't model a separate action diagrams for those behaviours unless some extra logic is needed there).
Related
I am still new to SysML and UML and the simulation of those diagrams. I am using Cameo Systems Modeler 19.0.
Context: My problem concerns the continuous simulation of an activity diagram in which a state machine diagram is nested. In the activity diagram I have a Call Behaviour Action which calls the state machine diagram. After this call behaviour action there are other actions to be executed. When I simulate the activity diagram the simulation switches to the called state machine diagram without any problem. Also the simulation of this state machine diagram is fully functional.
Now onto my problem: When I finalize the simulation of the state machine diagram by choosing states, path and their triggers so that I get to the Final State Node, it terminates the simulation of the State Machine Diagram (as expected). But the simulation won't continue executing in the parenting activity diagram.
Am I doing something wrong? Are you not supposed to be able to simulate these kinds of diagrams nested like that? Am I expecting something of Cameo Systems Modeler, that this programm just can't do?
Thanks for your help! If my description is not sufficient, I will happily provide a .mdzip as a minimal example!
In UML and SysML state machines, reaching a termination pseudo state means that the scope to which the behaviour that is defined by the state machine is terminated (when it is on the top scope in the state machine diagram). This is treated in different tools diffently. Some tools use (by default or always) the state machines as mester for simulation and when the topmost state machine enters a termination pseudo state the simulation is stoped, even if it was triggered from an activity.
There is a further kind of end pseudo state for state machines, it is called an exit point. Exit points trigger that the current scope is left. And as you dont want to stop your simulation this is waht you could use. An exit point is denoted by a hallow circle with cross.
Thought: Plenty of tools deviate from whats defined in UML and SysML especially when simulating dynamic behaviours. So there might be some special options in Cameo that possibly need some consideration. One solution to some of the tools is that you create a master state machine, that triggers your master activity.
It definetely is a bug. I issued a problem and the support team identified it as such.
Update: it has been fixed
A common multi-threaded implementation is to have some class where Method_A() is running in a thread and sits blocked waiting for some signal/event member variable (e.g. WaitForSingleObject).
Interacting classes running in different thread will then call Method_B() which does some work, sets the signal/event variable, perhaps does some more work, then returns.
How do I represent this interaction on a Sequence Diagram?
Should I have two lifelines, one for each thread, even though they are operating on the same instance of the class? My modelling tool (Enterprise Architect 12) doesn't allow the same class to appear twice on a Sequence Diagram, so seems to discourage this.
Edit: Geert has noted that the Sequence Diagram should use instances, not classes, which is a fair comment. However the problem is the same: multiple lifelines would imply multiple instances, but in the question Method_A() and Method_B() are operating on the same instance, just from different threads. How can that be represented?
The approach I have decided to take is to add two lifelines for the same instance, then label one lifeline with the <<thread>> stereotype and add the thread it runs in to the name:
I realise this is probably not standard UML, but it seems to get across all the information I want to express in a clear manner, which is the most important thing, right?
Martin Fowler does mention a few times in his book that sometimes a non-normative diagram is actually clearer. So that's my excuse. :)
(Edit You can solve it by just using asynchronous messages as #sim points out. That will just do. The answer below is showing what is going on under the hood. So if you don't care about the details, go with that answer.)
You are asking more a design than an UML question. Namely, how do concurrent instances talk to each other. You said first
Method_A() is running in a thread and sits blocked waiting
which simply means that it can not accept anything since it is blocked. Now, guessing from the context of your question, I assume that you still want to communicate with that instance since
in different thread will then call Method_B()
So, in order to be able to accept a message the instance must be in an appropriate state. There are a couple of ways to achieve that. One simple is, if the according OS has support for that, to return to the scheduler and tell him that it's waiting for some message.
Now when method_b is being called you know inside Object1 that you are in some kind of idle state inside method_a and do appropriate (return-) action.
Another way would be to poll the scheduler for incoming messages and handle them.
You need to keep in mind that sending a message usually not directly deals with the instance but tells the system scheduler to interact with the appropriate instance (at least in most OSs).
I just remember from the Modula2 compiler I once wrote that it has a concept of coroutines which allows a concurrent thread to run within the compiled code. But basically that is just mapped to two independent threads running under the hood of a semi-single one and you'd depict that with two life-lines when going into detail.
N.B.: Rather than method it should be operation (since that is was is invoked by a message; while the method is what is implemented inside the operation). And as per common convention they should start with a lower case char.
And also: do NOT use classes in a SD. Unfortunately EA still allows that (why? Ask them!). Somewhere hidden in their docs there is a sentence that you must use instances. Else the model will break. A SD is always (!) a sample sequence of instances talking to each other. Classes do not talk, they are just blueprints for the instances.
You should never use classes in sequence diagrams, but instead use instances/lifelines that have your class as classifier.
If you hold the control down when dragging a class to a sequence diagram you can choose to drop is as instance instead of as class.
This way you can add as many as you want for the same class.
The notation you are looking for is an asynchronous message. You could theoretically express this using a single lifeline. But this wouldn't be readable. So a possibility would be having two instances of a threadclass in your class and show the interaction between the instances. But never show classes in a sequence diagram.
But why are you using a sequence diagram at all? For such internal behavour an activity diagram is most likely more appropriate. There you can use send and receive messages elements to express such a behavour per thread. Or if it shall be shown in one diagram, you can use fork.
As far as I know, UML state machines model the behavior of one element, for example the behavior of one class.
I wonder how to model state machines with two classes which interact.
The state of one class depends on the state of the other class and transition of one state machine may trigger transition of the other state machine.
Do I have to use UML effect? Could an UML effect of one state machine trigger a transition of another state machine?
You can send events between classes to trigger transitions, something like this, for example:
What happens in an UML state machine if the transition selection algorithm (TSA) finds two transitions that should both fire and the following holds true:
transition #1 ends directly in a state
transition #2 ends (intermediately) in a choice pseudostate
As both the transitions fire, they cannot be in conflict. Else they would not have been chosen by the TSA in the first place.
Now the following occurs:
As the choice is evaluated (after transition #2), it takes a path (transition) that would lead to the exit of an ancestor state of the source state of transition #2. Due to this exit of an ancestor state, a conflict with transition #1 occurs.
UML diagram showing such a situation
(improved according to the discussion with Thomas Kilian in comments to his (now deleted) answer)
... if Event_1 occurs and x < 0.
Questions
Is the state machine ill-formed or what is supposed to happen now?
Is it illegal for a transtions after a choice to exit a state? At least it doesn't play together well with the "transition execution sequence" (exit(s), transition behavior(s), enter(s)). As it would be exit, behavior, exit, behavior, enter(s) in that case. I could not find anything about that in the UML Superstructure Specification (chapter 15). But then everything about orthogonal regions is very vaguely described in that document...
Motivation
I am asking the question out of the perspective of a library implementer. So my focus is not on how to design this situation in a nicer manner. I need to figure out how to deal with this situation correctly (or I need to know that it is an illegal situation).
This is one reason why there is a "Precise Semantics of UML State Machine" at the OMG...
First, it is legal for most transitions to exit a state. There are a few restrictions in the UML spec, but none that would concern your design.
You should always have a single state that is potentially active within any state machine region. As it stand, you have an implicit region in your "StateMachine1" that contains both the "X" and"Y" states. This would mean that your state machine could be in both "StateMachine1::X" and "StateMachine1::Y" states at the same time! As you probalby already know, orthogonal states are there do deal with such a situation. Perhaps you need to bring "X" and "Y" within state StateMachine1::S' regions?
Also a warning that by default in UML, states have shallow history. This means that, as it stands, the initial transitons within StateMachine1::S' regions will only be taken once. If you try to get back into "S" (I know, you don't have a transition for that - just speculating), it will go back to the last states (one per region) before if left the state, which, after event1, would be "A" and "E".
It would be difficult to comment more without knowing what you are trying to model, but I hope this helps.
In UML, does an object's state machine define that object's lifecycle?
That is, do transitions from the initial state to an ordinary state create the object, and transitions to the final state dispose of that object?
Generally yes - at least that's probably the most common way of using them.
It's not mandated that way in the UML spec; it allows a more general use of state machines. For example, a Final State can be used to signify the end of a behaviour thread within a region if the state machine has >1 regions. Or a state machine can be used to define a protocol instead of an object's lifecycle.
Some variants (profiles) of UML do enforce the behaviour you describe, for example Executable UML.
I'd probably turn the question on its head and ask: would it be useful to you if the state machine did define the object's lifecycle? If so then just use it that way. If you need to formalise then you could define a profile. But it's equally fine to just agree informally in your team.
hth.