Example of Using a Telephone

| iMatix home page
| Libero home page | Libero documentation
| << | < | > | >>

Libero
Version 2.32

Example of Using a Telephone

In a more technical example, we'll model the steps we take in using making a telephone call. By convention, the first state is After-Init. Another convention is to use Terminate-The-Program to halt the dialog.

After initialisation (I would recommend a good coffee or a decent beer, depending on the time of day), we pick-up the handset, and listen to the dialing tone.

After-Init:
    (--) Ok                          -> Want-Dialing-Tone
          + Pick-Up-Telephone-Handset
          + Listen-For-Dialing-Tone
    (--) Error                       ->
          + Terminate-The-Program

This leads us to the state Want-Dialing-Tone. Here we handle each of the possible events produced by Listen-For-Dialing-Tone. Let's look at these in detail:

Ok We have a dialing tone, so we can dial the number. This is the normal, expected event.
Silent, no tone The telephone exchange is having a hard day, or someone unplugged the phone. Or maybe a ninja attack team has cut the phone cables and is at this moment sneaking up the stairs and AAAARGH... In this simple example we loop forever; in a real program we would allow a limited number of attempts.
Voices on the line Some other member of the household is making the phone company richer. We apologise and forget it.
Modem noise - the young bro' is downloading some more bootleg GIF's.

We give each of these events a short snappy name and list them in a reasonable order. Like a 'case' statement, the actual order makes no difference to the machine, but helps the person reading the dialog. Typically we put the most frequent or expected events first, with the more bizarre ones at the end. Each event provokes one or more actions that correspond to modules of code. A module can be a function, procedure, subroutine, paragraph, etc., depending on the programming language. A module is where you do the real work.

Want-Dialing-Tone:
    (--) Ok                          -> Want-Ringing-Tone
          + Dial-Required-Number
          + Listen-For-Ringing-Tone
    (--) Silent                      -> Want-Dialing-Tone
          + Put-Down-Telephone-Handset
          + Pick-Up-Telephone-Handset
          + Listen-For-Dialing-Tone
    (--) Voices                      ->
          + Apologise-Telephone-Busy
          + Put-Down-Telephone-Handset
          + Terminate-The-Program
    (--) Modem                       ->
          + Put-Down-Telephone-Handset
          + Apologise-Cutting-Modem
          + Terminate-The-Program

Here we are waiting for a ringing tone. We can reuse some of the event names - Ok, Silence, Voices - from the previous state. This makes the generated code smaller, and is nice for the reader, since there are fewer names to remember:

Want-Ringing-Tone:
    (--) Ok                          -> Want-Answer
          + Listen-For-Answer
    (--) Silence                     -> Want-Dialing-Tone
          + Put-Down-Telephone-Handset
          + Pick-Up-Telephone-Handset
          + Listen-For-Dialing-Tone
    (--) Engaged                     -> After-Engaged
          + Put-Down-Telephone-Handset
          + Consider-Trying-Again
    (--) Voices                      -> Want-Dialing-Tone
          + Complain-Crossed-Connection
          + Put-Down-Telephone-Handset
          + Pick-Up-Telephone-Handset
          + Listen-For-Dialing-Tone

You get the picture. The remaining states map out the rest of the conversation. The next state has an event, Doorbell, that is not produced by any previous module, but that can happen at any time. We call this an exception event, and we add the handling for it in the state where it can happen:

Want-Answer:
    (--) Ok                          ->
          + Have-Conversation
          + Put-Down-Telephone-Handset
          + Terminate-The-Program
    (--) Wrong-Number                ->
          + Apologise-Wrong-Number
          + Put-Down-Telephone-Handset
          + Terminate-The-Program
    (--) Impatient                   ->
          + Put-Down-Telephone-Handset
          + Terminate-The-Program
    (--) Answering-Machine           -> Have-Answering-Machine
          + Consider-Leaving-Message
    (--) Modem-Or-Fax
          + Put-Down-Telephone-Handset
          + Terminate-The-Program
    (--) Doorbell                    ->
          + End-Conversation-Quickly
          + Put-Down-Telephone-Handset
          + Terminate-The-Program

After-Engaged:
    (--) Ok                          -> Want-Ringing-Tone
          + Dial-Required-Number
          + Listen-For-Ringing-Tone
    (--) Impatient                   ->
          + Put-Down-Telephone-Handset
          + Terminate-The-Program

Have-Answering-Machine:
    (--) Message                     ->
          + Leave-The-Message
          + Put-Down-Telephone-Handset
          + Terminate-The-Program
    (--) Impatient                   ->
          + Put-Down-Telephone-Handset
          + Terminate-The-Program

The Defaults state is special; we never come here explicitly. Rather, the state holds events that are implicitly valid in any other state. Here we say that whenever the Doorbell event strikes, we put the phone down and beat it doorwards. Note that the Doorbell event is handled explicitly in Want-Answer - the action in that state is a little different from the other states.

Defaults:
    (--) Doorbell                    ->
          + Put-Down-Telephone-Handset
          + Terminate-The-Program

Serious Stuff: Events and Names

Now I want to show how an action module 'produces' an event. Libero provides a standard variable called The-Next-Event. An event like 'Ok' is actually called Ok-Event in the program (Libero tacks-on '-Event' for you). This is how you would set The-Next-Event in various languages:

C/C++: the_next_event = ok_event;
80x86 assembler: mov the_next_event,ok_event
UNIX Korn Shell: the_next_event=$ok_event
Perl: the_next_event = $ok_event;
COBOL: MOVE OK-EVENT TO THE-NEXT-EVENT
Visual Basic: the_next_event = ok_event

Libero applies this rule: at least one of the action modules for an event must supply a value for The-Next-Event. If no value for The-Next-Event is supplied, the dialog halts with some kind of error message.

The names of events and action modules can take various forms, depending on the language and your preferences. For example, the C/C++ code could take any of these forms:

Plain style: the_next_event = ok_event;
Caps style: TheNextEvent = OkEvent;
Headline style: The_Next_Event = Ok_Event;
Title style: The_next_event = Ok_event;

Personally I prefer the first style, which is why it's the default.