UML 2.x - Raising Events on Transition (State Machine / Effect)
Kirsten
I have a (for me) very important question about UML (2.x) state
machines, and I am really despairing of the following topic for
several weeks now. As my research topic is about visual DSLs (not that
close to UML, but now I have to deal with its metamodel), I do not
search for a practical solution, but a good discussion with people who
have a good knowledge about the UML metamodel and tools supporting the
generation of code out of UML state machine diagrams.
My question:
How can I create a transition within a UML state machine which fires a
state transition within another UML state machine (note: of course by
sending a message/event to another object/instance which has this
state machine as "Classifier Behavior").
In scientific papers, some presentations, etc., I sometime find a
notation like this
State A ----> State B
Transition: SomeTrigger [SomeGuard] /
^AnObject.AnotherTriggerEventEtc()
or
Transition: SomeTrigger [SomeGuard] / send
AnObject.AnotherTriggerEventEtc()
(a nice example can be found here on page 5:
http://www.pst.ifi.lmu.de/veroeffentlichungen/knapp-merz-rauh:2002.pdf
)
However, this is not the only example I found.
Please correct me, if I am wrong, but this is not correct UML (at
least 2.x), isn't it?
Now I need the same thing, and I think that many people need such
"asynchronous signal mechanism" (just to name it). And because of my
tools, my field of research, model transformations based on the UML
metamodel, I need the way, how to do it "CORRECTLY" with UML 2.x.
Maybe someone knows the following Eclipse UML tools and knows how to
model the "asynchronous signal mechanism":
Papyrus
UML2Tools
Topcased
(not Eclipse, but I also checked "Sparx Systems - Enterprise
Architect"...)
As far as I know, all these tools (except EA) are generated (with some
additional metainfo, of course) by using the UML metamodel resp. its
EMF-based implementation, so the tools are able to produce correct UML
models according to its spec.
In each editor I am able to set one "effect" for each "Transition",
whereas "effect" is of type "Behavior".
"Behavior" - Hierarchy (excerpt):
"StateMachine" is a "Behavior"
"OpaqueBehavior" is a "Behavior"
"Activity" is a "Behavior"
"Interaction" is a "Behavior"
I digged into each direction... but I could not find a solution.
So... which way do I have to choose to "raise an event"?
Thanks a lot!
Regards,
Kirsten.
P.S.: A second question: maybe you know the "," notation, if multiple
effects should be applied when a transition is fired. How do realize
that? Obviously, only ONE effect can be set for each transition (see
OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, page
586, http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ ).
H. S. Lahman
If you are looking to use state machines in some other context than OO
development, you can stop reading. I suspect you are not interested in
OO development, though you might still find the comments on
implementation implications below interesting.
> My question:
> How can I create a transition within a UML state machine which fires a
> state transition within another UML state machine (note: of course by
> sending a message/event to another object/instance which has this
> state machine as "Classifier Behavior").
>
I'm afraid that is not the way interacting FSMs work, at least as far as
OOPL code generation is concerned. Actions associated with states or
transitions in an object state machine generate events and send them to
the outside world as messages. That message simple announces something
the sender did. Those events are pushed onto an event queue that is part
of the architectural infrastructure. At some later time the event is
popped and directed to the target object of the collaboration. That
object looks up the {event ID, current state} in a static (class-level)
STT jump table and passes the event data packet to the correct state
action where the internal current state is updated for the transition.
IOW, the event queue completely decouples the sender object state
machine from receiver state machine during collaborations. Other than
knowing who the target object of the collaboration is (which one gets
from navigating a relationship within the action), the sending object's
state machine knows nothing at all about the receiving object's state
machine. So there is no notion of one state machine firing a transition
in another state machine; that is a completely personal matter for the
receiving object. Among other things, the current state responsibility
is a private attribute of the receiving object so it is not even visible
to external clients. Consequently no external entity can know what
transition to trigger.
Note that from an implementation perspective, an object with a state
machine differs from other objects in only two respects: it has a
current state attribute and there is a static jump table for the STT. In
fact, when full code generators implement object state machines in
purely synchronous environments, they will often optimize away the event
queue and use a direct call to a static method to do the STT lookup. In
that case the collaboration between objects looks exactly like a
collaboration between objects without state machines. IOW, objects
collaborate with peer-to-peer messages whether they have state machines
or not so supporting object state machines and an asynchronous
communication model is a matter of internal object implementation and
message passing infrastructure rather than explicit OOA/D specification
(e.g., you will never see an EventQueue object in a UML OOA/D model for
managing routine collaborations).
If you look at the true abstract action languages (AALs) used by
translation environments where one does full code generation, there will
invariably be a statement syntax something like
target = this -> R1 -> R2; // navigate Class Diagram relationship
path to target object of collaboration
GENERATE myEvent TO target WITH <some data>
within the sending state machine's action. (Even the augmented OOPLs
used in round-trip tools will have preprocessor syntax of a similar
ilk.) As you can see, the sender state machine knows nothing about the
receiver state machine because the event queue decoupling is completely
hidden by the infrastructure.
Perhaps more to the point here, one does not need special UML syntax to
describe this. The relationship path is already explicit in the Class
Diagram. One would represent sending the event to the target object in
an Interaction Diagram just like a synchronous CALL; the event is just
another message.
> (a nice example can be found here on page 5:
> http://www.pst.ifi.lmu.de/veroeffentlichungen/knapp-merz-rauh:2002.pdf
> )
>
It is interesting that the authors here are poles apart from OO
philosophy. The primary goal of the OO paradigm is to provide
maintainable applications in the face of volatile requirements over
time. Hence the abstraction and decoupling of collaborations through an
event queue. In contrast, the authors here have provided a tool for
verifying state machine interactions in initial development that
requires tight coupling between the state machines (i.e., the message
sender must know all about the receiving state machine and there isn't
much notion of object encapsulation). The contrast strikes me as very
similar to the contrast between OO and FP development.
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
Kirsten
I am neither interested in OO development directly nor any code
generation (executable UML, etc.), but your explanations are still
very interesting.
As I said, I expected that there is no "send message to other SM"
notion as presented in many papers and tutorials, because they are all
incompatible with the UML metamodel.
However, I am still wondering how to describe "send message to other
SM" in real UML 2.x. In my opinion, this is a very basic and important
use case in many domains.
Fact is that behavior, e.g. a method M_A, can be executed on state
transition in state machine SM_A (of object O_A, class C_A). Such
behavior could include the call of the method M_B of another obect O_B
(class C_B, state machine SM_B). Finally, M_B could trigger the state
transition in SM_B.
Is this way of proceeding the correct one?
How is this modeled correctly in UML?
Can it be modeled? Or, are such construct unintended by UML, OMG,
modelers in general?
What is the state-of-the-art for modeling this use case in UML
correctly? (and as I said, I expect that this is a basic use case)
H. S. Lahman
> However, I am still wondering how to describe "send message to other
> SM" in real UML 2.x. In my opinion, this is a very basic and important
> use case in many domains.
>
In an OO context the SM would implement an object and it would be the
objects that collaborated. So one would model that message sending in an
Interaction Diagram. One would describe the message generation and
relationship navigation either in an AAL or with analogous fundamental
processes in an Activity Diagram for the state action.
However, yours is not an OO context and your SMs seem to exist as
first-class entities that communicate directly. That is an entirely
different context and I don't can't help you there because I pretty much
ignore everything in UML that is not included in the MDA profile for
building translation OOA models. B-( Even worse...
> Fact is that behavior, e.g. a method M_A, can be executed on state
> transition in state machine SM_A (of object O_A, class C_A). Such
> behavior could include the call of the method M_B of another obect O_B
> (class C_B, state machine SM_B). Finally, M_B could trigger the state
> transition in SM_B.
>
This gets back to the philosophical differences I alluded to previously.
From my OOA/D bias this sort of thing makes me shudder because it
produces a rat's nest of flow of control dependencies. IOW, OO behavior
responsibilities (aka object SM actions) should be self-contained and
represent intrinsic activities so they should never have any dependence
on other object SMs. The containing objects collaborate rather than the
method implementations, messages (events) are announcements, and one
wants to deal with flow of control at a higher level of abstraction like
a UML Interaction Diagram (i.e., connecting the dots between
announcements and whoever cares about what happened). So at the level of
abstraction of state machine action implementations, one has no
knowledge of outside context (i.e., one does not know about transitions
in other object state machines). All that is designed to minimize the
implementation dependencies among behaviors that led to the legendary
Spaghetti Code.
To do that one must decouple the implementation of SM_A from any
knowledge of SM_B. One does that by having it generate a event
announcing what it did. Once SM_A has been implemented, one can step
back and decide what other object (SM) cares about what SM_A did and
direct the message (event) to that object. It is then up to that object
to use its internal STT to route the event to the correct transition.
[It is also up to the developer to provide handshaking protocols,
serialized by the event queue, between the objects to ensure the
receiver will be in the correct state to process the event. But that is
external to the design of SM_A.] In fact, there is a rigorous DbC
technique one can use to connect those dots _after all object SMs have
be been defined_. Thus addressing the event is pretty much an
afterthought rather than something one needs to worry about when
designing actions.
<aside>
As a further demonstration our philosophical rift, most translation
methodologies only use Moore FSMs for object state machines. That's
because the Mealy model links actions to the transition and from there
it is only a very short step to linking them directly to the triggering
event. IOW, Mealy can be a very procedural Do This view where the event
generation context has an expectation about exactly what will happen.
Thus Moore is a much better fit to the OO I'm Done approach because the
action is tied only to the receiver's state, which is intrinsic to the
receiver, so there is no temptation to expect what will happen next when
designing the sender implementation (i.e., one doesn't know what
transition will be triggered so one doesn't know what state will prevail).
Note that one of the reasons FSMs are used in OOA/D is that they enforce
a lot of fundamental OO principles. For example, the rules of FSAs
mandate that a state action cannot know what the last state was or what
the next state will be. Therefore a state action is literally prohibited
from knowing what will happen next in its own SM, much less what will
happen in other SMs. If one were assigned the task of developing a
mechanism to enforce OO fundamentals, the FSM would be that mechanism.
Consequently, in the OOA/D methodology I use any object with behavior
responsibilities *must* have a SM.
</aside>
Bottom line: I'm afraid somebody else is going to have to address your
concerns. B-(
Kirsten
> > However, I am still wondering how to describe "send message to other
> > SM" in real UML 2.x. In my opinion, this is a very basic and important
> > use case in many domains.
>
> In an OO context the SM would implement an object and it would be the
> objects that collaborated. So one would model that message sending in an
> Interaction Diagram. One would describe the message generation and
> relationship navigation either in an AAL or with analogous fundamental
> processes in an Activity Diagram for the state action.
>
> However, yours is not an OO context and your SMs seem to exist as
> first-class entities that communicate directly. That is an entirely
> different context and I don't can't help you there because I pretty much
> ignore everything in UML that is not included in the MDA profile for
> building translation OOA models. B-( Even worse...
object.
> > Fact is that behavior, e.g. a method M_A, can be executed on state
> > transition in state machine SM_A (of object O_A, class C_A). Such
> > behavior could include the call of the method M_B of another obect O_B
> > (class C_B, state machine SM_B). Finally, M_B could trigger the state
> > transition in SM_B.
>
> This gets back to the philosophical differences I alluded to previously.
> From my OOA/D bias this sort of thing makes me shudder because it
> produces a rat's nest of flow of control dependencies. IOW, OO behavior
> responsibilities (aka object SM actions) should be self-contained and
> represent intrinsic activities so they should never have any dependence
> on other object SMs.
can only build a working (class) model, if classes/objects have
relationships. If a state machine is embedded within the context of an
object, it is ok, that it knows all about the current relationships of
"its object", e.g. "object A (a worker) is related to (employed by)
object B (a company)". Therefore, it should be possible that the state
machine or one of its transition's effects sends a message to a "known
object". I cannot see a real dependency to another state machine
here... object B can do everything with the message, e.g. causing a
transition in its state machine.
> Bottom line: I'm afraid somebody else is going to have to address your
> concerns. B-(
discussion. In my eyes, it is a flaw in UML that my question cannot be
answered simply and decisivly.
Here is some more (old) material which shows what I want to do:
- http://www.sts.tu-harburg.de/teaching/ws-99.00/OOA+D/StateDiagrams.pdf
(<<send>> notation)
- http://www.ait.unl.edu/siau/mgmt456/Booch-chpt21.ppt (just some text
that states that raising events is possible)
Is all this meterial incorrect (even the paper in the beginning)?
I simply have NO idea how these obvious concepts can be modeled using
the current (and valid) UML meta-model (2.1.2).
H. S. Lahman
However, yours is not an OO context and your SMs seem to exist as first-class entities that communicate directly. That is an entirely different context and I don't can't help you there because I pretty much ignore everything in UML that is not included in the MDA profile for building translation OOA models. B-( Even worse...Sorry, maybe you got me wrong. My SM is within the context of a class/ object.
Fact is that behavior, e.g. a method M_A, can be executed on state transition in state machine SM_A (of object O_A, class C_A). Such behavior could include the call of the method M_B of another obect O_B (class C_B, state machine SM_B). Finally, M_B could trigger the state transition in SM_B.This gets back to the philosophical differences I alluded to previously. From my OOA/D bias this sort of thing makes me shudder because it produces a rat's nest of flow of control dependencies. IOW, OO behavior responsibilities (aka object SM actions) should be self-contained and represent intrinsic activities so they should never have any dependence on other object SMs.In my opinion, there is no avoidable dependency. As we all know, we can only build a working (class) model, if classes/objects have relationships. If a state machine is embedded within the context of an object, it is ok, that it knows all about the current relationships of "its object", e.g. "object A (a worker) is related to (employed by) object B (a company)". Therefore, it should be possible that the state machine or one of its transition's effects sends a message to a "known object". I cannot see a real dependency to another state machine here... object B can do everything with the message, e.g. causing a transition in its state machine.
Bottom line: I'm afraid somebody else is going to have to address your concerns. B-(I am very frustrated that many people avoid getting into this discussion. In my eyes, it is a flaw in UML that my question cannot be answered simply and decisivly.
The way one models object behavior collaborations is for the action of a state machine to generate an event to announce something it did. That event generation is specified in either an AD or AAL for the sender's state action. It involves fundamental architectural processes for the event generation and basic relationship navigation. (The MDA profile for the design methodology defines that a Signal Event must be generated and pushed onto an event queue in the architecture.) But it does not involve any syntax to describe what transition will be triggered in the receiving object. That is a private matter for the receiving object's Statechart and <private> currentState attribute that will <usually> be implemented with a static jump table for the Statechart's STT.
This enables the implementation of the message sender in the collaboration to be completely decoupled from knowing anything at all about the implementation of the receiving object.
<aside>
Purists would argue that one should not even address the event in the action. One should simply identify the event and provide a data packet. The event would then be addressed by syntax outside the object at a higher level of abstraction (e.g., an Interaction Diagram). One problem is that specifying relationship navigation can sometimes be complicated by the need for a WHERE clause to select a specific object from a * set and that may be based on object attribute values rather than identity. Any notation to describe that would be clumsy at the Interaction Diagram level but it is trivial to define as one line in a text-based AAL in the sender's action.
So at least some methodologists recommend that one insert the AAL for relationship navigation and event generation into state actions after all of the objects and their state machines have been defined. IOW, one makes a second pass to actually connect the flow of control dots after all of the behaviors have been defined, just like one might do in an Interaction Diagram. This preserves the I'm Done concept of announcement messages to prevent any expectation of what will happen when specifying behavior responsibilities. More important, it clearly separates What must be done from When it should be done.
</aside>
Here is some more (old) material which shows what I want to do: - http://www.sts.tu-harburg.de/teaching/ws-99.00/OOA+D/StateDiagrams.pdf (<<send>> notation)
- http://www.ait.unl.edu/siau/mgmt456/Booch-chpt21.ppt (just some text that states that raising events is possible)
One can build an OOA/D model that uses Call Events for accessing behavior but that severely restricts the implementation context. Since synchronous processing is a special case of asynchronous processing, one can always implement an asynchronous OOA/D model in a synchronous environment without change. However, one cannot always implement a synchronous OOA/D model in an asynchronous execution environment without change. Thus an asynchronous behavior communication model for OOA/D ensures good design reuse across any execution environment (i.e., you can unambiguously implement the OOA/D model anywhere as-is).
More to the point here, if one uses Call Events, there is no need to use object state machines because the sequencing of operations is "hard-wired" in the model. The value of object state machines lies in the ability to use static structure to dynamically enforce problem space constraints on the sequencing of object behavior responsibilities in an asynchronous execution environment. So his suggestion that Call Events can trigger state machine transitions is, at best, irrelevant.
<aside>
There are a number of state machine implementations around that employ the GoF State pattern to implement state machines. IMO that is a terrible way to do it because of the huge amount of static infrastructure bloat since each state must have its own class. But it is also a bad idea because it is an inherently synchronous approach where one loses the versatility benefits of an asynchronous architecture. IOW, this would be the sort of situation where one triggers a transition with a Call Event via a very convoluted implementation.
</aside>
Is all this meterial incorrect (even the paper in the beginning)? I simply have NO idea how these obvious concepts can be modeled using the current (and valid) UML meta-model (2.1.2).
At the UML level OO collaborations are quite simple. One object sends a message to another object and the receiver <usually> does something in response. That view of collaboration prevails whether one is using object state machines or not. Methodologically the OO paradigm insists that the message sender know as little as possible about the receiver and should have no expectations at all about what the receiver will do, if anything, in response to the message. So we abstract the message passing in the model to achieve that decoupling.
In the sender one navigates a relationship path to address the message to the right object and then simply sends a message consisting of {message ID, data packet}. That's all the sender does. It is up to the OOP designer to implement a message passing mechanism that is consistent with the OOA/D MDA profile and the UML execution semantics. The OOA/D MDA profile will restrict the OOP designer's options because it will insist that knowledge accesses be implemented as Call Events while behavior accesses be implemented as Signal Events. The OOP designer then goes to the UML meta model's execution semantics for those elements to determine how to make the OOPL code consistent with them. Enter stage left, dancing: infrastructure like event queues, static class STTs, and currentEvent attributes.
The important thing to realize here is that when creating a UML OOA/D model, one does not directly specify any of that. One just defines a message, addresses it, and sends it off. Obviously it would be a real good idea if the OOA/D modeler understood the specific MDA OOA/D profile in play and its implications. But that just provides conceptual context for connecting the dots of the design. The design itself is expressed in UML at a higher level of abstraction than Call Events, Signal Events, event queues, and STT jump tables. And determining what transition is triggered in the receiving state machine is determined solely and quite privately by the receiver.
[And the OOA/D modeler needs to understand asynchronous processing to ensure there is a proper handshaking protocol between the interacting object state machines to ensure the receiver is in the right state when the event is popped from the queue. But I think I mentioned there is a rigorous DbC technique to ensure that when things get tricky.]
Kirsten
I think, I am very close to the answer I needed ;)
> >>> Fact is that behavior, e.g. a method M_A, can be executed on state
> >>> transition in state machine SM_A (of object O_A, class C_A). Such
> >>> behavior could include the call of the method M_B of another obect O_B
> >>> (class C_B, state machine SM_B). Finally, M_B could trigger the state
> >>> transition in SM_B.
> >> This gets back to the philosophical differences I alluded to previously.
> >> From my OOA/D bias this sort of thing makes me shudder because it
> >> produces a rat's nest of flow of control dependencies. IOW, OO behavior
> >> responsibilities (aka object SM actions) should be self-contained and
> >> represent intrinsic activities so they should never have any dependence
> >> on other object SMs.
> > In my opinion, there is no avoidable dependency. As we all know, we
> > can only build a working (class) model, if classes/objects have
> > relationships. If a state machine is embedded within the context of an
> > object, it is ok, that it knows all about the current relationships of
> > "its object", e.g. "object A (a worker) is related to (employed by)
> > object B (a company)". Therefore, it should be possible that the state
> > machine or one of its transition's effects sends a message to a "known
> > object". I cannot see a real dependency to another state machine
> > here... object B can do everything with the message, e.g. causing a
> > transition in its state machine.
>
You really try hard to tell me that I am doing something wrong ;)
However, please note that I don't try closly couple SMs etc. My
question has a practical background. And, I am aware of loose
coupling, etc.
> All the message sender needs to
> know to send a message is the relationship path to the target object. It
> has no need to know anything at all about the how the receiving object
> is implemented.
anything else.
I just need a message passing mechanism and how it is technically
noted in UML.
Sender-Side: I write on the transition of a state machine that a
message is sended.
Receiver-Side: I write on the transition of a state machine that a
message is received.
Until here, no coupling! There is a message, that is sent, and a
message (class/object) that is received.
The real implementation (c++/java/whatever) / code generation / MDA is
not really what I am interested in (I know that there has to be a
message queue, etc.)
I have no problem with the "receiver side". I know from the UML meta
model how a trigger and the related event/message can be added to the
state machine / model.
The problem I have is the "sender side". How to send an event/message/
signal? (extended question: can a message be sent by a state machine?
how can this be modelled according to the meta model?)
Basically, I have repeated my first post now, sorry ;)
> At the UML level OO collaborations are quite simple. One object sends a
> message to another object and the receiver <usually> does something in
> response. That view of collaboration prevails whether one is using
> object state machines or not. Methodologically the OO paradigm insists
> that the message sender know as little as possible about the receiver
> and should have no expectations at all about what the receiver will do,
> if anything, in response to the message. So we abstract the message
> passing in the model to achieve that decoupling.
what I want to do! However, I want to model this "behavior" within a
state machine, because the message passing shall be initiated if
certain state changes.
Both object must not know anything about each other! No expectations.
The only thing which must be known: who is the receiver?
> >> Bottom line: I'm afraid somebody else is going to have to address your
> >> concerns. B-(
> > I am very frustrated that many people avoid getting into this
> > discussion. In my eyes, it is a flaw in UML that my question cannot be
> > answered simply and decisivly.
>
> The simple and decisive answer if you are in an OO context is: Don't Do
> That! B-) It completely trashes encapsulation and creates very tight
> coupling.
Don't do what? In my understandings, what I want to do is exatcly what
you are explaining (whithout telling how to model that in UML).
In addition, I cannot see the tight coupling in my idea?
There is object A, object B, and message C. Object A does not need to
know anything about object B, not even interfaces (they are just
related to each other, but this is, as you also said, a basic OO
concept).
> The way one models object behavior collaborations is for the action of a
> state machine to generate an event to announce something it did.
> That
> event generation is specified in either an AD or AAL for the sender's
> state action.
> It involves fundamental architectural processes for the
> event generation and basic relationship navigation.
> (The MDA profile for
> the design methodology defines that a Signal Event must be generated and
> pushed onto an event queue in the architecture.) But it does not involve
> any syntax to describe what transition will be triggered in the
> receiving object.
H. S. Lahman
Note that your description here describes how /objects/ are related, not the state machines that implement them.That's what I tried to explain. You really try hard to tell me that I am doing something wrong ;)
<pre>
How can I create a transition within a UML state machine which fires a state transition within another UML state machine (note: of course by sending a message/event to another object/instance which has this state machine as "Classifier Behavior"). In scientific papers, some presentations, etc., I sometime find a notation like this State A ----> State B Transition: SomeTrigger [SomeGuard] / ^AnObject.AnotherTriggerEventEtc() or Transition: SomeTrigger [SomeGuard] / send AnObject.AnotherTriggerEventEtc() </pre>
Your description explicitly said. "... create a transition within a UML state machine [the collaboration sender in hand] which fires a state transition within another UML state machine [AnObject]..." I assumed that State A and B with in the state machine in hand and you wanted to link that transition to another object state machine via the syntax provided when specifying the sender state machine in hand. If that is actually what you meant, then I am, indeed, saying you are trying to do something very wrong. B-( It would violate not only OOA/D practice, but the rules of finite state automata. The only specification two state machines can share is that of an event that one generates and the other consumes.
If that isn't what you meant, then I have been responding to the wrong context. B-((
All the message sender needs to know to send a message is the relationship path to the target object. It has no need to know anything at all about the how the receiving object is implemented.That's totally fine... I agree and want to note that I never tried anything else. I just need a message passing mechanism and how it is technically noted in UML. Sender-Side: I write on the transition of a state machine that a message is sended.
Receiver-Side: I write on the transition of a state machine that a message is received.
Similarly, the event queue is an infrastructure element that the OOP developer must provide, so it does not appear in the UML OOA/D model. What does appear in the UML model is an Interaction Diagram that says that the event, identified as Event ID, goes from the Sender-Side object to the Receiver-side object.
The link between a transition in the Sender-side object and the Receiver-side object that you wanted to express in your original question resides solely in the OOA/D designer's head. That designer has a holistic view of the overall solution to define the model elements and link them together. The UML OOA/D model is the result of that design process; it just records how the pieces of the final puzzle fit together. To do that all the designer needs to specify is:
- the Sender-side and Receiver-side object state machines via Statecharts
- an event specification whose Event ID is mapped to a transition in the Receiver-side Statechart
- a behavior responsibility (action) in the Sender-side object to generate the event
- a Class Diagram to specify the relationship path
- an Interaction Diagram to show the routing of the event
At that point the OOP developer has everything needed to unambiguously create correct 3GL code for the solution. Thus the message passing mechanism is describe abstractly at the UML OOA/D level when Event ID is created in a Sender-side state action, directed to a specific object in an Interaction Diagram via a Class diagram relationship path, and associated with a transition in the Receiver-side Statechart. That's all you need at the UML level.
OTOH, at the OOP level things may be complicated far beyond simply providing infrastructure like event queues and static STTs. For example, the objects may be in different tasks on different network nodes. So one needs an infrastructure to pass the event in a distributed context (e.g., a simple address for the Receiver-side object won't work). Or the implementation may be concurrent and one needs to play games with how events are popped from the queue. One also needs to manage nonfunctional requirements; designing Event identification strategy to be efficient with STT lookup and reusable across applications is nontrivial. But none of that stuff gets specified in the UML OOA/D model; all you need at that level are the five things above to describe the message passing.
The problem I have is the "sender side". How to send an event/message/ signal? (extended question: can a message be sent by a state machine? how can this be modelled according to the meta model?)
<pre>
...
receiverRef = THIS -> R1 -> R2 WHERE (...) // navigate to the Receiver-side object
GENERATE EventID TO receiverRef WITH <data> // send event to it
...
</pre>
GENERATE would be a fundamental process in an Activity diagram if one described the action that way. It basically hides all the infrastructure stuff for the message passing. For object state machines, it just pushes the event onto the <hidden> event queue. Other infrastructure would handle the eventual popping of the event and dispatching it to the target object for consumption. As indicated above, the actual code for all that infrastructure can get complicated, which is why designers of full code generators for UML models get the Big Bucks. But as an application developer you don't care about any of that any more than you care how a Java compiler/VM works. You just specify the AAL fragment above and let a different trade union worry about the details.
You said: one object sends a message to another object. That's exactly what I want to do! However, I want to model this "behavior" within a state machine, because the message passing shall be initiated if certain state changes. Both object must not know anything about each other! No expectations. The only thing which must be known: who is the receiver?
But all that is part of getting Class Diagrams, Statecharts, Interaction Diagrams, and object behavior responsibilities to play together properly. IOW, the designer has to figure out how to define solution elements so they will play together properly in the designer's vision of the solution. Once the designer has done that, the five things I listed earlier for the designer to specify are sufficient to provide an unambiguous solution specification for the OOP developer.
So even though the developer might "see" that transitions in two state machines are clearly linked together and must transition in lockstep, that isn't how things are specified in the model. Instead the developer daisy-chains message sequences and defines handshaking protocols that ensure the transitions will be in lockstep for all problem contexts. To facilitate that the developer relies on general principles of asynchronous processing and the UML meta model to connect the all dots properly.
I am very frustrated that many people avoid getting into this discussion. In my eyes, it is a flaw in UML that my question cannot be answered simply and decisivly.The simple and decisive answer if you are in an OO context is: Don't Do That! B-) It completely trashes encapsulation and creates very tight coupling.Hmh, I don't get your point here.
The way one models object behavior collaborations is for the action of a state machine to generate an event to announce something it did.How is this done?
There are many possible ways to implement it at the 3GL level. For example, in C++ one might have something like
<pre>
class EventQueue;
extern EventQueue* eventQueue;
class Sender {
public:
void doIt ();
...
private:
OtherClass* myReceiver; // implement relationship
...
};
void Sender::doIt() {
eventQueue->push (47, myReceiver, NULL); // push event w/o data packet
// and EventID = 47
};
</pre>
The real issue here, though, is that whatever code the OOP developer provides must be consistent with the UML meta model's execution specification and the relevant MDA profile. In this case the OOA/d MDA profiles requires the use of a Signal event. An event queue is the most common way to implement the Signal Event semantics defined in the UML execution meta model. In addition, there will be other rules for how the event gets popped (e.g., events between the same two objects should be popped in the same order they were pushed) that must be honored in the OOP implementation. A lot of that stuff comes for free as soon as one decides to use an event queue, which is why it is a common approach.
The key idea here is that the UML meta model and MDA profile are inputs for both the OOA/D model developer and the OOP implementer. But they are interpreted by each somewhat differently. The model developer only needs a general understanding of them while the OOP developer uses them to precisely map the model into the computing space. But both are interpreting them. Thus the modeler does not explicitly say that transition X in the Sender SM should be synchronized with transition Y in the Receiver SM. However, that will be implied when the OOP developer looks at all of the model elements. So if the model developer puts the model together consistently with the MDA profile and UML meta model, the OOP developer will be able to map them to a specific implementation that will Just Work through the semantics of the UML meta model and MDA profile.
Sorry, but I don't know what AD or AAL is?
AAL = Abstract Action Language. Today the preferred venue for describing behaviors, mainly because it is much easier to modify in the primarily algorithmic context of behavior rules and policies.
It involves fundamental architectural processes for the event generation and basic relationship navigation.Just on implementation / MDA side, right?
MDA (Model Driven Architecture) provides a rigorous semantic framework for mapping different models of basically the same thing into one another. It is primarily of interest to tool vendors who need a consistent view of things for plug & play and activities like code generation. I only mentioned it here because UML has become so large and complex that one needs a formal statement of which model elements are relevant and how they should be interpreted in a particular modeling context. Thus a Class Diagram in UML superficially looks the same for OOA/D and Data Modeling, but it is constructed using very different methodologies and must be interpreted quite differently for those two contexts.
RJB
eventA[condition]/objectB.eventB(data)
in a state machine for objects in Class A to indicate
that objectB (in class B perhaps?) must respond to its eventB.The
/objectB.eventB(data)
can be in a state as well.
In a well designed system class B will have a public method called
eventB and abjectB will be in a state that
has a transition coming out of it labeled
eventB(data)..../....
We often talk about objectA sending a message eventB to objectB.
So I tried to find this in the UML Superstructure Specification, v2.2
(my latest download).
I found the syntax in section 15.3.14 ok.
and then I found this
"The behavior-expression is executed if and when the transition fires.
It may be written in terms of operations, attributes,
and links of the context object and the parameters of the triggering
event, or any other features visible in its scope. The
behavior expression may be an action sequence comprising a number of
distinct actions including actions that explicitly
generate events, such as sending signals or invoking operations. The
details of this expression are dependent on the action
language chosen for the model."
Which ducks the issue in my humble opinion.
The standard goes on to a graphic notation for sending and receiving
messages (events).
I hope this helps
RJB.
H. S. Lahman
This is directed more at the OP than at you. It raises a Hot Button for
me because I think there is a lot of bad advice is floating around in
today's OO books. That's because a lot of developers converted to OO
from procedural development in the '90s. In doing so they jumped
directly to writing OOPL code and they desperately sought a mapping to
things familiar. So they overlaid procedure design principles on their
OOPL without properly grasping OOA/D, resulting in strongly typed C and
COBOL programs. Unfortunately a lot of those people are now writing
books about OO development, even when they move up to UML modeling.
> It is not uncommon in text books to show something like this
> eventA[condition]/objectB.eventB(data)
> in a state machine for objects in Class A to indicate
> that objectB (in class B perhaps?) must respond to its eventB.The
> /objectB.eventB(data)
> can be in a state as well.
That might be fine for a modeling context other than OOA/D so UML may
well need to support it. But IMO in an OOA/D context that is poor
practice. One should think about the routing of collaboration messages
(i.e., connecting the dots of overall flow of control) at a higher level
of abstraction, like an Interaction Diagram, rather than in object
behavior implementations.
When the transition of another object is specified in a behavior
implementation that reflects carnal knowledge of the other object that
the behavior in hand has no business knowing. One way that is manifested
is that if one changes the Statechart of the other object, one will also
have to change the behavior implementation in hand.
Another problem is that it restricts what the other object can do. It is
not uncommon for the same event to trigger two or more transitions in
the other state machine, depending on the current state of the other
state machine. For example, one might have a Traffic Light object where
the same Toggle event triggered transitions among Red -> Green -> Yellow
states. One sacrifices that versatility when "hard-wiring" the specific
transition in another object's method.
However, I think the worst problem is that one loses one of the benefits
of OO development. In a well-formed OO application one can often deal
with requirements changes by simply re-routing collaboration messages
(IME about 10-20% of the time) without touching the implementations of
the objects (i.e., rules and policies of behavior responsibilities). In
those cases one would have to touch the behavior implementation because
it will have explicit code that depends upon a particular Statechart
that will have to be modified. If one is into defect prevention, that is
important because it introduces an opportunity for inserting a defect.
And from a more aesthetic viewpoint...
> In a well designed system class B will have a public method called
> eventB and abjectB will be in a state that
> has a transition coming out of it labeled
> eventB(data)..../....
When defining interactions for object state machines it is more
conventional to publicly identify the events the object will accept
while keeping the actual behavior responsibility methods for the state
actions private and attaching them to the Statechart. In fact, many
modelers will separate events from public synchronous services for
knowledge access by attaching an <<event>> stereotype to the events. (Or
they will use a separate Interface model element to provide the mapping.)
The main reason for this is that it hides the implementation of the
object from the clients. IOW, the object has a public responsibility to
respond to particular events and it has an intrinsic suite of behavior
responsibilities (whether object state machines are used or not).
However, the mapping of how the object responds to the event is a
private matter that should be decoupled from the clients. In this sense
the Statechart can be viewed as a mapping function that <privately>
links events the object will respond to with its own behavior
responsibilities.
> We often talk about objectA sending a message eventB to objectB.
That can represent a very procedural view of Do This where the sender
has an expectation of what will happen next elsewhere in the solution.
To avoid that temptation one should think of events as simple
announcements of something the sender did. Then one has no immediate
expectations about the solution context and can design the behavior
(state action) as a truly intrinsic and self-contained responsibility.
Then one can route the event to someone who cares about what happened in
an entirely separate design step at a higher level of abstraction (e.g.,
an Interaction Diagram).
But either way, apropos of the point above, all one needs to know about
the collaboration to do that routing is what object will consume the
event, not what transition within that object will be triggered. The
receiver's transitions should be completely encapsulated and the
collaboration should be peer-to-peer between objects.
> I found the syntax in section 15.3.14 ok.
>
> and then I found this
> "The behavior-expression is executed if and when the transition fires.
> It may be written in terms of operations, attributes,
> and links of the context object and the parameters of the triggering
> event, or any other features visible in its scope. The
> behavior expression may be an action sequence comprising a number of
> distinct actions including actions that explicitly
> generate events, such as sending signals or invoking operations. The
> details of this expression are dependent on the action
> language chosen for the model."
> Which ducks the issue in my humble opinion.
I think this is a different problem. When one tries to use the same
notation for many different contexts there will inevitably be semantic
conflicts about what the model element means. A classic example is OO
generalization and Data Modeling subclassing. In Data Modeling each
subclass is instantiated individually while in OO generalization the
entire tree is instantiated in a single object. That is a fundamental
conflict in the semantics of instantiating a relational tuple. So how
does one resolve that? One way is to dumb down the meta model semantics
of the model element to the point where it doesn't matter (e.g., simply
don't address instantiation in the semantic description). But that
leaves one hanging because one no longer knows what the element actually
represents when looking at the model, which is your concern here. So one
cops out with an MDA profile for the particular modeling context, which
essentially becomes an extension of the UML meta model.
In some sense I think the issue here is really about OO design practice
being effectively an MDA profile. In an OO context one wants to think
about messages as announcements, peer-to-peer object collaboration,
implementation hiding, and multiple levels of abstraction for design
activities. So the OO design paradigm dictates the model elements to
use, how one should interpret them, and how to use them. That may be
quite different from other modeling contexts like Data Modeling or
Structured Design.
If UML is to realize OMG's goal of being a general purpose modeling
language there will inevitably be usage conflicts and the meta model
will have to be dumbed down to avoid inconsistencies. That will lead to
models of the same thing being constructed quite differently.
Consequently they will be describe quite differently, such as thinking
procedurally in terms of Do This rather than the OO alternative of I'm Done.