Getting Started with EventStudio Introduction to FDL Comments, Remarks and Issues Object Management and Message Parameters Timer and Resource Management State Machine Operations, Actions and Environment Defining Types for Modules, Processors and Objects Multiple Scenario Support Tutorial Sequence Diagram pdf

Home > EventStudio System Designer > Sequence Diagram Tutorial > State Machine, Actions and Environment
State Machine Operations, Actions and Environment

• State Machine Operations
• Action statements
• Message interactions with the Environment

FDL allows the user to depict message interactions with the external world. This can be done by sending messages to the left environment (env_l) or right environment (env_r). As the names suggest, env_l and env_r are assumed to be at the left and right edges of the document. Environment interactions can be very useful in clearly spelling out what is external to the system being designed.

State changes by eternal and dynamic objects can be represented in FDL. State changes are shown as boxes with angular bracket edges (i.e. < >). Use state change statements during the detailed design phase.

Action statements allow the designer to express specific actions taken by objects. The actions represent the internal operations carried out by the object like "updating a variable", "calling a routine". FDL can also be used to depict more complicated actions that involve a distinct action begin and end. This could be used to depict actions like "starting and stopping a motor", "feeding and removing a tone".

    module : customer, exchange
    processor : phone in customer
    processor : frontend in exchange, core in exchange
    eternal : call_mgr in frontend
    dynamic : call in frontend
    /* Originating Call Setup */
    feature "Call Setup"
1.     pick_up_phone : env_l -> phone
offhook : phone -> call_mgr
       (* Subscriber lifts the phone to initiate a call *)
2.     call_mgr takes action "Check Customer Privileges"
call_mgr allocates "Subscriber Terminal"
       call_mgr creates call
3.     call state = "Idle"
offhook : call_mgr -> call
4.     call begins action "Feeding Dialtone"
dialtone : call -> phone
       call state = "Awaiting Digits"
call starts await_first_digit_timer
       dial_digits : env_l -> phone
digits : phone -> call
5.     call ends action "Feeding Dialtone"
call stops await_first_digit_timer
       call starts more_digits_timer
       timeout more_digits_timer
       setup_call(digits="1-800-433-444", mode=NORMAL) : call -> core
       call state = "Awaiting Call Setup"
       call_setup_request : core -> env_r
       call_setup_response : env_r -> core
setup_complete : core -> call
       call state = "Awaiting Answer"
[* Setup complete, waiting for called susbcriber to be rung *]
       ringback : core -> phone
       hang_up : env_l -> phone
onhook : phone -> call
       call_over : call -> call_mgr
       call_mgr deletes call
       call_mgr frees "Subscriber Terminal"
    endfeature

1. This statement shows a message received from the left environment. The left environment is assumed to be at the left edge of the document.
2. Here the call_mgr takes a specific action. Use the action statement to show different actions taken by an object. The action statement allows you to add implementation details to the design document.
3. Here a call state change has been shown. Use the state change statement to specify the different states taken by the state machine implementing the object. State change statements have been added to partition the sequence of actions into individual states. State change statements have been introduced at multiple places in Call5.fdl
4. This statement shows an action being started by the object. This signifies that action "Feeding Dialtone" has been initiated. The action begin statement specifies the start of an action, while the action statement introduced in (2) specifies an action that can be completed in a single step.
5. The "Feeding Dialtone" action end is shown here. This marks the end of the action started in (4). The action end statement should be used to end all started actions that have been started with action begin. EventStudio will warn if an action end does not complete an action that was started.
6. This statement shows a message being sent to the to the right environment. The right environment is assumed to be at the right edge of the document.