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 > Object Type Definitions
Defining Types for Modules, Processors and Objects

Many times in Real-time System Design you would have come across scenarios where two instances of an object are performing different roles in the execution of a feature. To handle such cases we need to have a way to specify that the two instances belong to the same object. FDL accomplishes this with specification of types.

Consider our running example from the Basic tutorial; we have just defined the message interactions for one end of the call. The message interactions to notify the other subscriber have not been covered. This is remedied in the FDL given below. Another customer and frontend processor have been added. Also a second instance of a call and call_mgr objects have been defined. Type definitions have been used to declare that the newly introduced entities are really instances of the modules, processors and objects that we have already covered.

It may be noted that defining the types will have no visual impact on the PDF Message Sequence Charts. The main difference will be seen in definition of Interface Documents and Unit Testplans. For example, EventStudio can generate the following documents from the FDL file in our example:

• All interactions involving call object. The output file will include message interactions involving call1 or call2.
• All interactions involving call2 object. The output file will include message interactions involving call2. Message interactions involving call1 only will be excluded.
• All interactions involving frontend processors. This output file will include message interactions that involve frontend1 or frontend2.
• All interactions involving frontend1 processor. This output file will include message interactions that involve frontend1. Message interactions involving frontend2 only will not be included.

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

1. This statement extends the original module declaration to define types for customer1 and customer2. The statement declares that customer1 and customer2 are both of the type customer. Note that no type is specified for the exchange module, as there is only one instance of this module.
2. phone1 and phone2 processors are declared in this statement. Both the processors are of type phone.
3. Here is another example of processor type declaration. frontend1 processor is declared to be of type frontend. frontend2 declared on the next line is also of type frontend. (Note that the names frontend1 and frontend2 have been used just as a convention. You could equally well use orig_frontend and term_frontend or any other names. EventStudio will just look at the types to identify that both the processors are of the same type).
4. This line and the next line declare call_mgr1 and call_mgr2 eternal objects. Both objects are of the type call_mgr.
5. Types for dynamic objects can be specified in the same way. This line declares the call1 and call2 objects. Both the objects have a type call.
6. Most of this example has been changed a little to replace names like phone, customer, and call with phone1, customer1 and call1. The names phone, customer and call etc. are used to define the types.
7. New statements have been added to the FDL to specify the handling of the other end of the call.