State Machine diagram

[Monique]

Hi

I am trying to create a state machine diagram for a dvd writer. I
currently have a class diagram with the following;
DVD WRITER
Load()
Open()
Close()
verify()
burn()
stop()

When the load option is chosen(to load the dvd) the dvd drawer opens
if it is closed and closes if it is open.

How can I illustrate the above line in a state machine diagram. I
currently have the state waiting,then a trigger 'choosing the load
option' however 2 states can result from this trigger depending on
whether the trigger is open or closed.

I would really appreciate if any of you can help me

Thanks again

regards

Monique

[H. S. Lahman]

Responding to Monique...

I am trying to create a state machine diagram for a dvd writer. I
currently have a class diagram with the following;
DVD WRITER
Load()
Open()
Close()
verify()
burn()
stop()

When the load option is chosen(to load the dvd) the dvd drawer opens
if it is closed and closes if it is open.

How can I illustrate the above line in a state machine diagram. I
currently have the state waiting,then a trigger 'choosing the load
option' however 2 states can result from this trigger depending on
whether the trigger is open or closed.
  

First, I am uncomfortable with the functional view. Actions are associated with states in an object state machine, but the state machine itself is about state-of-being and intrinsic sequencing constraints in the order in which the actions can be invoked. The actual actions are largely irrelevant. The important things are the conditions that must prevail in the object before executing those actions. Thus one can view an object FSM as an ideal vehicle for applying DbC.

Thus if there is an action associated with opening the drawer and an action associated with closing the drawer, then the FSM will capture the fact that it is never possible to execute the action associated with closing the drawer before executing the action associated with opening the drawer. But it really doesn't matter what the actions actually do. So one is much better off thinking about actions in terms of DbC preconditions and postconditions. The state represents the postcondition of the associated action. The transitions define the matching preconditions for executing the state's action. That is, you can't get to the state to execute its action unless the precondition for executing the action has been met and that will be conveniently implicit in the current state (postcondition of another object action having been executed) and the external context (what event is triggering the transition).

I think it would help if you named your states by the condition that prevails when the object is in that state. That is, by the postcondition resulting from the action that occurs when the action executes on entry to the state. Thus you would have states like Loaded, Open, Closed.

Then if an OpenDrawer event arrives it can trigger one of two valid transitions, depending on the current state of the object FSM:

[Closed]
    |
    | E1:OpenDrawer
    |
    V
 [Open] -------------+
    ^                |
    |                | E1:OpenDrawer
    |                |
    +----------------+

Alternatively, in the object STT the event might be ignored if the drawer is already open. (One of the bells & whistles that OO FSMs have over the theoretical FSAs from which they are derived is the ability to ignore an event when an object is already in the proper state.)

However, I have a push-back. What is this object's role in the overall system? Is it a low level hardware controller that processes signals from the hardware like the button being pressed and responds with register reads/writes? Or is this object supposed to be controlling the process of burning DVDs in a larger problem context (e.g., the user tells the UI to burn a DVD and your software needs to take it from there)?

The reason I ask is because I am concerned this object may be somewhat schizophrenic in that it may be trying to capture two very different levels of abstraction. There may be a need for low-level hardware control at the register level and one might need to capture the sequencing constraints of fundamental operations (e.g., one can't start burning until the door is closed and a DVD is in the tray) in a very fundamental handshaking protocol with the hardware. In that case the hardware is providing most of the events (e.g., Button Pressed, Tray Extended, Door Closed, DVD Engaged, etc.), except the Burn and Stop events. Perhaps more to the point, when the hardware does something like announce a DVD is engaged, this object would very likely simply tell somebody else who cared about that by generating an event to that object. IOW this object would just "translate" the hardware announce into other application context terms.

OTOH, there may be a Big Picture at the application level where the user is doing something like drag/drop a file onto a burner icon. At that level you might have to tell the user through the UI to load a DVD into a particular drive. Or one might be primarily concerned with connecting up the right stream input to the burn process. That is a much higher level of abstraction and the sequencing constraints might be quite different (e.g., loading is a monolithic operation that includes opening and closing doors).

Life will be simpler if those levels of abstraction are not mixed. That is, those views of control are captured in different objects, perhaps in different subsystems. [There will still have to be synchronization between the two views, but the tie-points should be clear. Thus both views are clearly going to have some kind of notion that the DVD Writer is ready to actually burn a DVD so one will notify the other of that.]

-- 
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

[Björn Nilsson]

Here is one (of many) ideas of a state machine for a DVD Writer.

I've inserted a substate machine in the waiting state. It enters the closed state by default but manages open/close using a single trigger.
You can only burn when the drawer is closed, while burning it does not respond to the event evLoad and finally when the burn process is ready it enter the open-state and ejects the DVD.

This could also be done using parallel states.

I have only modeled signals, I assume you generate the signal evLoad to the statemachine once the Load() is called and so on.
This solution would be rather easy to implement, then there are of course other aspects regarding modeling and UML.

Best regards Björn N


-----Ursprungligt meddelande-----
Från: UMLf...@googlegroups.com [mailto:UMLf...@googlegroups.com] För Monique
Skickat: den 5 maj 2009 20:21
Till: UML Forum
Ämne: [UML Forum] State Machine diagram

[Yiming]

Hi, Monique

I think this is a kind of event-driven application, it can be
organized in a state machine. I draw a state chart with StateChart
(http://www.intelliwizard.com/products.htm) as below:

http://www.intelliwizard.com/down/case/dvd/DVD_State.JPG

The StateTree is as blow:

DVD_State Machine
-> Closed
----> Stop
----> Burn
-> Open

The state machine structure with state transitions is as blow with
StateWizard. The source code is available at http://www.intelliwizard.com/down/case/dvd/dvd.zip
.

SME_BEGIN_ROOT_COMP_STATE_DEF(DVD_State,DVD_StateEntry,DVD_StateExit)
SME_ON_INIT_STATE(SME_NULL_ACTION,DVD_StateInitChild)
SME_END_STATE_DEF

SME_BEGIN_SUB_STATE_DEF_P(Closed)
SME_ON_EVENT(E_OPEN_DRAWER,OnClosedE_OPEN_DRAWER,Open)
SME_END_STATE_DEF

SME_BEGIN_LEAF_STATE_DEF_P(Open,OpenEntry,OpenExit)
SME_ON_EVENT(E_OPEN_DRAWER,OnOpenE_OPEN_DRAWER,Open)
SME_END_STATE_DEF

SME_BEGIN_COMP_STATE_DEF(Closed,DVD_State,ClosedEntry,ClosedExit)
SME_ON_INIT_STATE(SME_NULL_ACTION,ClosedInitChild)
SME_END_STATE_DEF

SME_BEGIN_LEAF_STATE_DEF_P(Burn,BurnEntry,BurnExit)
SME_ON_EVENT(E_STOP,OnBurnE_STOP,Stop)
SME_END_STATE_DEF

SME_BEGIN_LEAF_STATE_DEF_P(Stop,StopEntry,StopExit)
SME_ON_EVENT(E_BURN,OnStopE_BURN,Burn)
SME_END_STATE_DEF


Sate machine applications may operate with lower layer software
modules or hardware interfaces, which are called service providers. A
service is formally specified by a set of primitives (operations)
available to service users (applications). These primitives tell the
service to perform some action or report on an action taken by a peer
component/entity. The service primitives are classified into four
categories:

* Request
* Indication
* Response
* Confirm

[Computer Networks, Andrew S.Tanenbaum]. The request and confirm
primitives can be implemented in form of service calls. The indication
and response primitives can be implemented in form of external event
posting.

You may refer the following page for more information:

http://www.intelliwizard.com/doc/State_Machines_and_Applications.htm

Wish these information is helpful for you.

Jerry Ding

StateWizard: http://www.intelliwizard.com

> the drawer. But it really doesn't matter what the actions actually /do/.

> H.lah...@verizon.net
> software blog:http://pathfinderpeople.blogs.com/hslahman/index.html

[H. S. Lahman]

Responding to Nilsson...

Caveat. I assume below we are talking about modeling a DVD hardware device driver that handles mundane details like hardware register reads/writes. In that case one wants an operational model of how the hardware works rather than an operational model of getting DVDs burned in some problem context.

Here is one (of many) ideas of a state machine for a DVD Writer.

I've inserted a substate machine in the waiting state. It enters the closed state by default but manages open/close using a single trigger.
You can only burn when the drawer is closed, while burning it does not respond to the event evLoad and finally when the burn process is ready it enter the open-state and ejects the DVD.
  

Alas, I see a couple of problems. First you can only burn if the drawer is closed AND there is a DVD in the tray. IOW, I think another state is necessary that is entered when the hardware verifies that there is a DVD in the tray. It is only from that state that evBurn would be valid.

The second is that I don't see anything for the Waiting state to manage. The hardware does not care if that drawer has a DVD in it when it is opened and closed. That semantics is only relevant to the broader context of how the DVD hardware is used. So the model of the DVD device driver needs to accommodate opening and closing the drawer w/o a DVD in the tray. Finally, opening and closing the drawer is handled the same way; that is, it is always a toggle like pressing the button. So one intrinsically needs the same event to trigger both operations.

Thus one might have something like:
   
                                                  evDetectedDVD
+------------> [Closed] -------------------> [Loaded] --------------+
|                  |                             |                  |
| evOperateDrawer  | evOperatedrawer             | evOperateDrawer  | evBurn
|                  |                             |                  |
|                  |  +--------------------------+                  |
|                  |  |                                             |
|                  V  V           evOperateDrawer                   V
+---------------- [Open] <------------------------------------- [Burning]

Note that this works equally well whether evOperateDrawer is generated by the hardware (i.e., a button press) or it is generated from the application as an instruction to the device driver. That segues to another issue related to the notion of managing things.

I think one wants to keep things simple and model the driver with very basic responsibilities. Opening the drawer and removing the burned DVD has nothing to do with driving the DVD hardware. The hardware just burns the DVD and doesn't care if the DVD is removed immediately or next Wednesday. When the DVD is retrieved is an issue for the application where burning a DVD is just one step in the overall problem solution. So I don't think the problem intelligence for when the DVD should be removed should be in the DVD device driver model.

By separating the concerns of how the DVD hardware works from the concerns of when and why one needs a DVD burned and what one wants to do with it afterwards will generally lead to a more robust application. [The price one pays is that collaboration between the hardware and the problem solution become more fine-grained and additional handshaking is required for synchronization because the operations are so fundamental. Thus the problem solution must wait until it receives and acknowledgment from the [Loaded] state that the DVD has been successfully loaded prior to sending the evBurn message.]

As a practical matter the application solution is likely to have an object somewhere with a state machine that closely parallels the device driver state machine and those two state machines will exchange handshaking events to ensure synchronization. But the states will probably be different in detail (e.g., the state action that generates the evOperateDrawer event after the burn is completed will probably put up a dialog to the user suggesting that the DVD be removed). That is, that solution object's state machine will be tailored to the problem context rather than the DVD hardware. It is even possible that different objects in the solution will collaborate with the device driver object (e.g., setting up the DVD and initiating the burn may be done elsewhere in the solution from recovering and disposing of the burned DVD). That versatility is why it is important to separate the concerns.

--
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

H. S. Lahman