UML state chart diagram question
Angus
I have a question about representing a 3 state model where the 3rd
state is shared by both previous (parent) states.
It is modelling a telephone.
Base state is Idle phone.
events which trigger move to next state are new_call to trigger second
level state Inbound_call and offhook_action which triggers move to
Outbound_call level.
In Inbound_call there is ringing state. In Outbound_call level there
is dialing then ringback.
Both Ringing in Inbound_call and ringback in Outbound_call can
transition to Connected state. So I am thinking Connected should be in
another level in hierarchy? But if so, then do state charts support
this relationship. How would you draw this in an UML state chart?
Angus
rvirzi2000
It seems to me that the Connected state is the same whether you
reached from an Inbound or Outbound call. So the history of how you
got to it is lost once you arrive. The question then would be, why
link the Connected state to either Inbound or Outbound? Connected
should be an independent state.
If, on the other hand, you wish to distinguish between a connected
inbound call and a connected outbound call, then you would have two
types of connected states. One would be a child of Inbound, and one a
child of outbound.
H. S. Lahman
If you are not doing OOA/D for software design, then you can stop reading...
I have a question about representing a 3 state model where the 3rd state is shared by both previous (parent) states.
Any time an object's behaviors gets so complicated that Harel seems to be required, it almost always means there is a problem with the problem space abstraction producing the Class Diagram. IOW, the object has too many responsibilities and one needs to look for delegation in the problem space to distribute its behavior responsibilities among multiple entities.
It is modelling a telephone. Base state is Idle phone.
events which trigger move to next state are new_call to trigger second level state Inbound_call and offhook_action which triggers move to Outbound_call level.
<pre>
+-------- [Idle] ----------+
| |
| new call | off hook
| |
V V
[Inbound_Call] [Outbound_Call]
</pre>
I have a concern about the "new call" event. (See below).
In Inbound_call there is ringing state. In Outbound_call level there is dialing then ringback. Both Ringing in Inbound_call and ringback in Outbound_call can transition to Connected state.
<pre>
+------------- [Idle] --------------+
| ^ |
| new call | | off hook
| | |
V | V
[Inbound_Call] | [Outbound_Call]
| | |
| off hook | on hook | dialing complete
| | |
| | V
| | [Ringing]
| | |
| | |
+---------> [Connected] <-----------+
answered
</pre>
This assumes the [Outbound_Call] action performs the dialing. The [Inbound_Call] state is essentially just a wait state. Note that for an incoming call, the ringing doesn't matter -- nothing happens until the phone is taken off the hook. IOW, the ringing is a trigger for a human phone answerer.
The problem I have here is: where does the "new call" event get generated? All of the other events could be generated by the phone hardware or by some monitor that checks the phone line for special phone company signals. If so, I think a better solution would be for the "off hook" event to transition directly from [Idle] to [Connected].
In any event (sic), this state machine is pretty simple and it does not require Harel.
Caveat: There are no detailed requirements here, or even a general description of what the problem is. So my model is pure speculation based on my preconceptions of what the problem really is. IOW, this is not intended as a solution; it is mainly a demonstration that you don't need Harel in OOA/D.
For example, my model does not deal with there being no answer for an outgoing call, such as an "on hook" event from [Ringing] to [Idle]. There are other issues if this is a device driver for the phone itself that will also manage the answering machine. But that would be a situation where the device driver would have other objects that would interact with this object. Thus there would be a [Ringing] state for inbound calls and a transition to the answering machine facility triggered by a timeout event from an external [Timer] object. In fact, one would likely delegate the entire answering machine facility to another object that has its own state machine for the idle-message-record cycle.
-- Life is the only flaw in an otherwise perfect nonexistence -- Schopenhauer Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared. H. S. Lahman H.la...@verizon.net software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
Remy Fannader
Remy.
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
Peter Mueller
I think idle (i.e. waiting for inbound) and off-hook are
top level states. Both then have further childs. E.g. offhook
might have a children "line busy" or "speaking" etc.
Before thinking in states it is useful to start collecting triggers. What are the
triggers that can occur. Then what actions should happen. And last
how to organize the states.
Maybe you can design a state diagram and share it with us. Then
it is easer to discuss.
Nested states are no problem in general. Basically they help
to keep the drawings more compact. But you can transform every
hierarchical machine into a flat one without problems.
With best regards,
Peter
----
Code generation from state-charts made easy!
www.sinelabore.com
H. S. Lahman
Harel StateCharts have been used successfully for some time by smart people with good understanding of complex synchronization requirements. That's well beyond UML tutorials.
<aside>
Note that Harel is sometimes used in telcomm software because the requirements are commonly expressed in terms of Harel and Mealy state machines (which I regard as over-specification, but that 's another issue). But OO developers who blindly implement such state machines as-is in the software demonstrate a fundamental lack of understanding of OOA/D. When developing software, one uses the OO paradigm because maintainability is paramount and managing complexity with simple Moore machines results in applications that are more robust in the face of volatile requirements over time. In fact, if one wanted to invent a mechanism to enforce good OOA/D practice, event-based flow of control using simple Moore object state machines and "I'm done" announcement events would be it. It is almost impossible to break encapsulation or logical indivisibility and introduce excessive coupling if one follows that methodology.
</aside>
As far a synchronization is concerned, that is far easier to manage and maintain when it is handled by handshaking between small, individual state machines. In my decades of R-T/E development I've run into a lot of smart people who agree with that. I can honestly say that I only know of one serious R-T/E developer, Bran Selig, who uses Harel object state machines. They are just too difficult to get working initially and maintain over time.
You might find the chapters of my book, Model Based Development, that deal with state machines and handshaking of interest.
Thomas Mercer-Hursh, Ph.D.
deal with state machines and
> handshaking of interest.
But, only if one hadn't made up one's mind in another direction in
advance ...
Remy Fannader
Remy.
--
H. S. Lahman
> While tutorial principles like " Objects are supposed to be logically
> cohesive " or " [it] is far easier to manage and maintain when it is
> handled by handshaking between small, individual state machines " are
> helpful, some situations clearly require some more advanced constructs.
You may regard such things as helpful advice, but I regard them as
fundamental principles for software design.
I believe the conclusion of the last clause is far from clear. The
reason we have design paradigms and methodologies is to capture best
practices so that we don't repeat the mistakes of the past. IMO, the
notion that there are always some situations where fundamental
principles need to be violated is the same sort of NIH logic that led
people to seriously debate about special cases where GOTOs were useful
for a full decade after Djikstra's "GOTOs Deemed Harmful" note. Software
design is difficult enough without second guessing well-established
paradigms, methodologies, and good practices on a case-by-case basis.
Thomas Mercer-Hursh, Ph.D.
> Software design is difficult enough without second guessing
> well-established paradigms, methodologies, and good practices on a
> case-by-case basis.
I might timorously suggest that there is a big difference between:
1. Stating that something is a rule that one will always follow, but one
day finding oneself with a problem that one can't figure out how to
solve while following the rule and so deciding, just this once, to
violate it, but taking this as a personal failing because one didn't
figure out how to do it right.
and
2. Stating from the beginning that something is a rule except for some
cases when it is not.
The former is going to have one trying very hard to observe the rule.
The latter is going to have one deciding that this is one of the
exceptions every time things get even slightly tough.
--
======================================================================
Consulting in Architecture-Driven Modernization, Transformation,
Object-Orientation, OERA Architecture, and Best Practice
----------------------------------------------------------------------
Dr. Thomas Mercer-Hursh email: tho...@cintegrity.com
Computing Integrity, Inc. voice: 510-233-5400
60 Belvedere Avenue fax: 510-233-5446
Point Richmond, CA 94801-4023 url: http://www.cintegrity.com
======================================================================
Remy Fannader
On the contrary, I think that generalities which are always correct are not very helpful when different options are possible.
Remy.
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
H. S. Lahman
>> Software design is difficult enough without second guessing
>> well-established paradigms, methodologies, and good practices on a
>> case-by-case basis.
>
> I might timorously suggest that there is a big difference between:
>
> 1. Stating that something is a rule that one will always follow, but
> one day finding oneself with a problem that one can't figure out how
> to solve while following the rule and so deciding, just this once, to
> violate it, but taking this as a personal failing because one didn't
> figure out how to do it right.
Right. No methodology is perfect and eventually one encounters corners
where it simply doesn't work in a reasonable way. While the
methodologies are not perfect, they have evolved to the point where such
situations are quite rare.
>
> and
>
> 2. Stating from the beginning that something is a rule except for some
> cases when it is not.
>
> The former is going to have one trying very hard to observe the rule.
> The latter is going to have one deciding that this is one of the
> exceptions every time things get even slightly tough.
This is the one I have a problem with. It allows a host of motivations,
like elegance and saving keystrokes, to drive the design. Worse, it
allows converts to the OO paradigm to map antithetical principles onto
the paradigm. IOW, it invites bad OOA/D habits.
H. S. Lahman
> On the contrary, I think that generalities which are always correct
> are not very helpful when different options are possible.
That's pretty much my point. One should only look for different
<methodological> options when the fundamental principles do not provide
a viable one.