Generate Sequence Diagrams from Text Input

EventStudio System Designer 4.0

User’s Manual

Copyright © 2000-2007. EventHelix.com Inc. All Rights Reserved.

Table of Contents 1 Introduction..................................................................................................1

1.1 EventStudio System Designer ....................................................................................... 1 1.2 Features ......................................................................................................................... 1 1.3 What’s New in EventStudio 4.0...................................................................................... 3

2 Getting Started...........................................................................................10 2.1 Exploring the Templates .............................................................................................. 10 2.2 Exploring the Examples ............................................................................................... 10

Acme Inc Recruiting.............................................................................................................. 11 WebTaxi ................................................................................................................................ 11 SpacePort ............................................................................................................................. 11 Tutorial .................................................................................................................................. 11 Xenon Switching System ...................................................................................................... 11 AutoDrive .............................................................................................................................. 11 HelixStore ............................................................................................................................. 11 HelixRouter ........................................................................................................................... 11 IP Infrastructure .................................................................................................................... 11 TCP and Applications ........................................................................................................... 11 Zeta Corporation Orientation ................................................................................................ 11 Tutorial .................................................................................................................................. 11

2.3 Hands On With EventStudio ........................................................................................ 11 2.3.1 Creating HelloWorld.fdl ............................................................................................ 12 2.3.2 Creating Hello.scn Scenario Project ........................................................................ 12 2.3.3 Defining Basic Documents....................................................................................... 13 2.3.4 Generating and Viewing Documents ....................................................................... 14 2.3.5 Adding Multiple Scenarios ....................................................................................... 14 2.3.6 Adding More Documents ......................................................................................... 15

3 FDL System Design Language .................................................................17 3.1 Introduction to FDL....................................................................................................... 17 3.2 Call1.fdl: Introduction to the Language ........................................................................ 18

3.2.1 What are Modules, Processors and Objects? ......................................................... 19 3.3 Call2.fdl: Comments, Remarks and Issues.................................................................. 20 3.4 Call3.fdl: Object Management and Message Parameters ........................................... 21 3.5 Call4.fdl: Timer and Resource Management ............................................................... 23 3.6 Call5.fdl: Environment Interactions, States and Actions .............................................. 25 3.7 Call6.fdl: Defining Types for Modules, Processors and Objects.................................. 27 3.8 Call7.fdl : Case, If-Else-Endif and Page Break Statements......................................... 29 3.9 FDL Error Reporting..................................................................................................... 32

4 FDL Reference ...........................................................................................33 4.1 Action statement........................................................................................................... 33 4.2 Action Begin statement ................................................................................................ 34 4.3 Action End statement ................................................................................................... 35 4.4 Block Remark statement .............................................................................................. 36 4.5 Case statement ............................................................................................................ 37

4.5.1 Relation With If-Else-Endif Statement ..................................................................... 38 4.6 Chain statement ........................................................................................................... 39 4.7 Comment statement..................................................................................................... 40 4.8 Create statement.......................................................................................................... 41 4.9 Delete statement .......................................................................................................... 42 4.10 Dynamic Object declaration ......................................................................................... 43 4.11 Environment declaration .............................................................................................. 44 4.12 Eternal Object declaration............................................................................................ 45 4.13 Feature statement ........................................................................................................ 46 4.14 Goto and Label statements .......................................................................................... 47 4.15 Heading statement ....................................................................................................... 48

4.16 If-Else-Endif statement................................................................................................. 49 4.17 If-Endif statement ......................................................................................................... 50 4.18 Invokes and Returns statements.................................................................................. 51 4.19 Issue statement ............................................................................................................ 52 4.20 Leg statement............................................................................................................... 53 4.21 Message statement...................................................................................................... 55 4.22 Module declaration....................................................................................................... 57 4.23 Multicast statement ...................................................................................................... 58 4.24 Page Break statement.................................................................................................. 59 4.25 Preprocessor directives................................................................................................ 60 4.26 Processor declaration .................................................................................................. 61 4.27 Remark statement ........................................................................................................ 62 4.28 Resource Allocate statement ....................................................................................... 63 4.29 Resource Free statement............................................................................................. 64 4.30 State Change statement .............................................................................................. 65 4.31 Style declaration........................................................................................................... 66 4.32 Theme declaration........................................................................................................ 68 4.33 Timeout statement ....................................................................................................... 70 4.34 Timer Restart statement............................................................................................... 71 4.35 Timer Start statement................................................................................................... 72 4.36 Timer Stop statement................................................................................................... 73 4.37 Type declaration........................................................................................................... 74

5 FDL Errors and Warnings .........................................................................75 5.1 FDL Errors.................................................................................................................... 75 5.2 FDL Runtime Errors ..................................................................................................... 85 5.3 FDL Warnings .............................................................................................................. 89

6 Scenario Projects ......................................................................................91 6.1 Introduction to Scenario Projects ................................................................................. 91 6.2 Scenario Wizard........................................................................................................... 93 6.3 Document Wizard......................................................................................................... 94 6.4 Sequence Diagram....................................................................................................... 95 6.5 Interface Sequence Diagram ....................................................................................... 96 6.6 Interaction Sequence Diagram..................................................................................... 97 6.7 Message Filter Sequence Diagram.............................................................................. 98

6.7.1 Simple Message Filters............................................................................................ 98 6.7.2 Regular Expression Message Filters ....................................................................... 98

6.8 Unit Test Procedures ................................................................................................. 100 6.9 Summary Document .................................................................................................. 101 6.10 Statistics Document.................................................................................................... 102 6.11 Collaboration Diagram ............................................................................................... 103

6.11.1 Context Diagram................................................................................................ 103 6.12 Interface Collaboration Diagram ................................................................................ 104

6.12.1 Interface Context Diagram................................................................................. 104 6.13 Interaction Collaboration Diagram.............................................................................. 105

6.13.1 Interaction Context Diagram.............................................................................. 105 6.14 Message Filter Collaboration Diagram....................................................................... 106

6.14.1 Simple Message Filters ..................................................................................... 106 6.14.2 Regular Expression Message Filters................................................................. 106 6.14.3 Message Filter Context Diagram....................................................................... 107

6.15 Index Document ......................................................................................................... 108 6.16 Scenario Bar............................................................................................................... 109

7 How To … .................................................................................................110 7.1 How to Create a FDL File........................................................................................... 110 7.2 How to Create a Scenario Project.............................................................................. 111 7.3 How to Add a Scenario .............................................................................................. 112

7.4 How to Delete a Scenario .......................................................................................... 113 7.5 How to Add a Document ............................................................................................ 114 7.6 How to Delete a Document ........................................................................................ 115 7.7 How to Modify Document Options.............................................................................. 116 7.8 How to Generate and View Documents..................................................................... 117 7.9 How to Rename a Scenario or a Document .............................................................. 118 7.10 How to Reorder the Scenarios ................................................................................... 119 7.11 How to Open FDL Files from the Scenario Bar.......................................................... 120 7.12 How to Update Scenarios with FDL Case Changes .................................................. 121 7.13 How to Use Longer Module, Processor and Object Names ...................................... 122 7.14 How to Change Paper Size for PDF documents........................................................ 123 7.15 How to Move a Scenario Project to a Different Directory .......................................... 124 7.16 How to Generate Documents from the Command-Line............................................. 125 7.17 How to Export a Document to Microsoft Word........................................................... 126

7.17.1 Insert Pictures.................................................................................................... 126 7.17.2 Link to Pictures .................................................................................................. 126

7.18 How to Specify Fonts in a Document ......................................................................... 128 7.18.1 Specify the Font in a Style................................................................................. 128 7.18.2 Specify the Font as an Option ........................................................................... 128 7.18.3 Specify the Font in a Theme ............................................................................. 128

8 Appendix: Regular Expressions.............................................................129 8.1 Regular Expression Examples ................................................................................... 129 8.2 Regular Expression Rules.......................................................................................... 130

EventStudio System Designer 4.0 Sequence Diagram Based System Design Tool

1 Introduction

1.1 EventStudio System Designer 4.0 EventStudio is a CASE tool designed specifically for distributed system design. EventStudio can be used in the entire lifecycle of Distributed system development, starting from Use Case analysis to Unit Testing and System Integration.

1.2 Features • Generated Documents: EventStudio can generate a vast array of documents used in

Distributed system design. All the documents are generated from a single source file. Documents are generated in industry standard formats like PDF, Microsoft Word Picture (EMF) and HTML. A few of document types are listed below:

o Sequence Diagrams o Message Sequence Charts o Interface Sequence Diagrams o Unit Test Procedures

Page 1 Copyright © 2000-2007. EventHelix.com Inc. All Rights Reserved.


o Summary Documents o Statistics Documents o Collaboration Diagrams o Context Diagrams o Message Filter Collaboration Diagram

• Multiple Scenarios: EventStudio simplifies the definition of multiple legs that can be executed in a feature. The user can define all the possible success and error scenarios in a single file. So now defining ten scenarios for a feature will not mean ten different documents.

• Design Review: EventStudio can automatically review your design. It can catch resource leaks and other design problems. Keep in mind that these checks are performed for all the Scenarios, not just the few success cases of a feature. A few of the checks performed by EventStudio are:

o Have all the resources been freed? o Have all the timers been stopped? o Have all pending actions been completed?

• Semi Formal Development: In most systems code is the first formal description of the system. The design stage just consists of text documents with almost no formal component. EventStudio remedies this "impedance mismatch" between the design and coding stages by introducing a semi-formal design methodology that fits right between text based document and code. EventStudio gives you the freedom and flexibility of text documents while also adding a formal component to the design.



1.3 What’s New in EventStudio 4.0 EventStudio System Designer 4.0 is a major release. This release adds the following features: 1. Summary Sequence Diagrams

at Module and Processor Level The module and processor level sequence diagrams have been enhanced to extract high level diagrams from detailed low level diagrams. • Inter module interaction

sequence diagram is drawn at module level. The diagram completely hides the processor and object level detail.

• Inter processor interaction sequence diagram is drawn at processor level. The diagram completely hides the object level detail.

1. Add module and processor interaction sequence diagrams using the “Add Document” icon.

2. Use the “Generate All” documents to generate the interactions sequence diagrams.

2. Joint Actions Involving Multiple Objects The action statement has been enhanced to support actions involving multiple objects. The objects may spawn processor and module boundaries.

The syntax for the statement is: a, b, c take action "Joint action"

3. Bidirectional Interaction Support in Message Statement Bidirectional message interactions can now be depicted as double headed arrows.

The syntax for the statement is: Voice : a <-> b

4. Weighted Arrow in Message Statement Important message interactions can be represented with a thicker arrow.

The syntax for the statement is: Message : a => b Message : a <=> b

5. Message to Self Support Message to self is represented as an arrow pointing back to the object axis.

The syntax for the statement is: Message : a -> a

6. Object Method Interaction Modeling EventStudio now supports special statements for method level modeling. Method invocation and return can be modeled using the "invokes" and

A few examples are: CallManager invokes Call.HandleInvite(msg) Call takes action "Verify the Invite Message" Call invokes MessageHandler.Send(SIP_OK) MessageHandler.Send returns (true) Call.HandleInvite returns



"returns" statements. The method invocations are represented with UML style instance axis.

7. Forward Goto Statement EventStudio now supports forward goto statements to simplify definition of multiple scenarios.

case leg "No digits dialed": goto exit leg "All digits dialed" endcase case leg "Call routing successful": leg "Call routing failed": goto exit endcase label exit: [* call has ended. *]

8. Case statements can be

nested within if-else-endif statements EventStudio supports nesting of case statements inside if-else-endif statement. This simplifies the organization of case statements in a file.

if "Success" leg "Success3": case

leg "Failure3": exit goto endcase endif

9. Periodic Timer Support EventStudio now supports periodic timers. A periodic timer keeps running even after a timeout.

e starts periodic t42 /*…*/ timeout t42 /*…*/ timeout t42 /*…*/ e stops t42

10. Visual Ether Support Visual Ether is a new product from EventHelix.com Inc. Visual Ether allows you to generate Sequence diagrams and collaboration diagrams from Ethereal PDML files. EventStudio has been enhanced to support larger size sequence diagrams with a larger number of entries.

11. Style Support for Messages EventStudio supports style specification for message statements.

The style is specified as: module: m processor : p in m eternal : e in p, f in p style sip: color="1.0,0.0,0.0", font="Times New Roman-Bold", fontsize="15", linewidth="4", linepattern="- -", paramfont="Courier New", paramfontsize="4" feature "Testing" [sip] invite(caller, called): e -> f [sip] two_way_path : e <-> f



endfeature 12. Section Heading Support

A large sequence diagram may be subdivided into sections using the heading statement.

• The headings are displayed as a block remark.

• A bookmark to the headings is added in the left pane of a PDF sequence diagram file.

• Message numbering is reset when headings are encountered.

The syntax for headings is shown in the following example: heading "Conversation Mode"

13. Support for Wide Range of Font Sizes Any font size between 1 and 35 may be specified in the Tools->Options->Font Selection tab. The font size range has been expanded for:

• Sequence diagram message name font. • Collaboration diagram message name font. • Message parameter font • Action box font • Block remark font

14. Reverse Arrow Support in Message Statement Reverse arrows may be used in the message statements. This is convenient when dealing with acknowledgements and responses.

For example: "SIP INVITE" : Terminal -> SCSF "SIP OK" : Terminal <- SCSF

15. Hyperlink Support in "take action", "takes action" and message statements (unidirectional and bidirectional messages) Hyperlinks can be specified in single action and joint action statements. The hyperlinks may refer to files on the internet or a local path. Clicking on the link in the PDF sequence diagram opens the linked document in another window. Note: Hyperlinks are not supported in Microsoft Word Picture (EMF) documents.

The syntax is: obj takes action "Handover" <file://c:\Doc\handover.pdf> a, b take action "SIP Call" <http://rfc.net/rfc3261.html> Invite : src -> dst <file://c:\Doc\intf.htm#Msg>

16. Strings May be Used in Module, Processor or Object Names Strings may be used to denote module, processor or object names. This allows the developers to use terms like "I-

The syntax is: module: Customer, "IP Multimedia System" processor: "User Terminal" in Customer processor: "I-SCSF" in "IP Multimedia System" eternal : "192.168.20.45" in "User Terminal"



SCSF", "192.168.10.20".

17. Message Parameter May be Spread Over Multiple Lines The message parameters may be spread over multiple lines. This helps in documenting long parameter lists.

The syntax is: "My Message" (name="XYZ", DOB="1/1/2006", Address) : Dst <- Src

18. Light Weight Header A light weight header that lists the axis only for the lowest level entities. The light weight header does not include the page number and title. This makes the diagrams suitable for inclusion in other documents.

Select the light weight header from the Tools->Options menu and Customize tab

19. Style Support for Instance Axis Style specifications can now be added to the module, processor and object declarations. The styles allow you to define a color, line style and a font size for the instance axis.

• Object style specifications are used in regular sequence diagrams. When a light weight header is selected, the instance title, box and the axis are rendered using the style specifications.

• Processor style specifications are used when a processor containing no objects is used. The processor style is also used when processor interaction sequence diagram is generated.

• Module styles are used in module interaction diagrams. The style specification example is shown here: style pstyle: color="1.0,0.0,0.0" style cstyle: color="0.0,1.0,0.0" style rstyle: color="0.0,0.0,1.0" module : [pstyle] phone, bts, bsc processor: [cstyle] cpu in phone eternal: [rstyle] rlc_mac in cpu

20. Image Specification in Instance Style An image may be specified in the instance styles. JPEG images are supported. The image in a style is used if "Light weight header with image" is selected from the "Tools->Options->Customize tab".

The style specification with image is shown here: style pstyle: image="c:\phone.jpg" style cstyle: image="c:\xscale.jpg" style rstyle: image="c:\sphere.jpg" module : [pstyle] phone processor: [cstyle] cpu in phone eternal: [rstyle] rlc_mac in cpu

21. Optional Right Side Remarks

Use the "Tools->Options->Customize tab" to disable the right side remark column.



The remarks displayed on the right side may be disabled from the "Tools->Options->Customize tab".

22. Message Chain Statement Define a message chain to model a chain of messages that are triggered in a sequence. EventStudio attempts to draw all messages in a message in a single line.

The syntax is: chain [rstyle] msg : a -> b msg2(par1="one", par2): b -> c [talk] conversation: c <-> d endchain

23. Style Support in "take action", "takes action", "begin action", "end action", "allocates", "frees" and "state" statements The style statement gives you full control over the color, font and line style in the action, resource management and state related statements.

The syntax is: [my_style] obj1, obj2 take action "Joint action" [my_style] object1 takes action "Single action" [my_style] object1 begins action "Feed Dialtone" [my_style] object1 ends action "Feed Dialtone" [my_style] object1 allocates "Channel" [my_style] object1 frees "Channel" [my_style] object1 state = "Awaiting Digits"

#include "architecture.fdl" Include an FDL file located in the current directory. #include <theme.fdl> Include an FDL file from the paths specified in Tools->Options-Preprocessor tab. #ifdef UMTS_RELEASE_7 #else #endif Conditional compilation is supported with the #ifdef-#else-#endif statement.

24. FDL Preprocessor FDL has been enhanced to support a powerful preprocessor that is similar to the C preprocessor.

#define msg_ack(msg, a, b) "msg" : a -> b;\ (* msg from a to b*);\ "msg ack" : b -> a;\

(* b acks msg *);

Macros may be defined with multiple parameters. Macros may be nested.

25. Theme Support Themes provide an overall control over the document layout. Most Tools->Options commands can be overridden using themes.

A theme declaration consists of a theme name followed by a sequence of attribute-value pairs. The syntax is: theme MyTheme: blockRemarkFormatting="right-align",

paperSize="letter"

theme LeftAlign: blockRemarkFormatting="left-align"



A theme statement based on the current settings can be automatically copied to the clipboard using the Tools->Copy Options as Theme command.

Initial theme for a statement is specified as a modifier to the feature statement. The syntax is: {MyTheme} feature "a feature" endfeature Theme may be modified within the feature-endfeature block by placing the theme modifier on a line. For example: {MyTheme} feature "a feature" [* Right aligned block remark *] {LeftAlign} [* Left aligned block remark *] endfeature

26. Scenario Project Templates Scenario Project can now be defined from a predefined list of templates. You may also define your own templates.

Click on the "New" icon and then select the "Scenario Project From Template" option.

27. Joint State Transition, Action Begin/End, Allocate/Free Support The following joint statements are now supported:

• begin and end action • allocate and free • state

All joint action statements support style specification. [mystyle] A, B, C begin action "feed dial tone" A, B allocate "time slot" A, B free "time slot" [mystyle] A,B,C end action "feed dial tone" [mystyle] A,B,C state = "Conversation"

28. Auto Synchronize FDL files and PDF Documents EventStudio automatically synchronizes FDL files and open PDF document. If a PDF document is already open, a new version of the document will is reopened after the document generation has been completed.

• EventStudio also opens a PDF sequence diagram when a "Generate All" command is issued and no documents were open at that time.

• Command to generate a single document also opens the document automatically.

29. Single Click Document

Save, Generate and Display EventStudio greatly simplifies the process of editing FDL by providing instant feedback on the final sequence diagram. A single click or command saves all changes, generates the document and displays the output. The command works even when the document was already open.

Use any of the following to save, generate and display: • Control-Q • Click on the "Quick Save and Display" icon in

the toolbar. • Invoke the File->"Quick Save and Display"

menu item.



30. Hierarchically Assign Images to Modules, Processors and Objects EventStudio image header assignment algorithm has been enhanced as detailed in the diagram below:

Eternal/Dynamic Object Images

Processor Images Module Images Images Drawn in the Header

At least one eternal or dynamic object uses a style with image.

N/A N/A The eternal/dynamic objects that have associated images are drawn with the image.

No eternal or dynamic object has a style with an image.

Atleast one parent processor has a style with an image.

N/A Processor image is used. The image is centered between all eternal and dynamic objects within the processor.


No processor has a style with an image.

Atleast one module has a style with an image.

Module level images are used. The images are centered between all entities contained in a module.

31. Specify Custom Paper Sizes in EMF and PDF Documents Uses can now select custom paper sizes. The custom paper size may be selected from:

• Tools->Options dialog box • paperSize attribute in the theme (e.g. paperSize="5.5 inch 6.5 inch" or

paperSize="60 mm 70 mm"). • Paper length may range from 4 to 22 inches. • Paper width may range from 4 to 17 inches.

32. Other Enhancements • EMF file naming has been enhanced to include scenario names.



2 Getting Started 2.1 Exploring the Templates The best way to start with EventStudio is to use the predefined templates as the starting point. Just follow these quick steps to get started in a matter of minutes:

1. Invoke EventStudio System Designer 4.0 from the start menu.

2. Click on the "New" icon . 3. EventStudio will display a document selection dialog (Figure 2-1), 4. Select the "Scenario Project From Template" option. 5. EventStudio will display a new dialog listing several templates. 6. Select the most suitable template and click "Next". 7. EventStudio will display options to change the path or the document location. 8. For now, accept the defaults and click the "Finish" button.

Figure 2-1 New Document Selection Dialog

2.2 Exploring the Examples To get an idea of EventStudio's capabilities, just follow these simple steps to evaluate the examples:

1. Click on the "EventStudio Examples" shortcut on your desktop. 2. You will see the example folders. Click on an example folder.

3. Click on the Scenario Project (s) in that directory. (Scenario Project icon: ). 4. EventStudio will open the Scenario Project and a Scenario Bar will be displayed on the

left side of the screen.

5. Click on the "Generate All Documents" icon from the toolbar. 6. EventStudio will generate all the documents and notify you about completion. 7. Double-click on the Document icons in the Scenario Bar. Or click on the Document

Index icon .



Example Focus Area Description Acme Inc Recruiting

Business Process Documentation

Documents the recruiting processing at Acme Inc. Interactions between different departments in the company are clearly presented.

WebTaxi Web Based Development

This example covers the design of a web based taxi service. The service makes effective use of GPS and wireless internet to automate routine objects of taxi dispatch.

SpacePort Embedded System Design

A space based docking station is described here. Automatic docking and undocking of spacecrafts in supported.

Tutorial Introduction to FDL.

This example contains all the FDL files covered in the FDL tutorial in the following chapters.

Xenon Switching System

Telecom Message Sequence Charts. Call Processing Design.

This example describes detailed design of the Xenon Switching System that handles voice call switching. The Scenarios cover the V5.2 and ISUP signaling protocols. This example covers a very large and complex set of call processing scenarios.

AutoDrive Use Case Documentation

AutoDrive is an Automatic Vehicle Driving System that uses GPS based navigation.

HelixStore High Level System Design. Process Control.

HelixStore is a completely automated web store. The store uses web services to interact with other systems.

HelixRouter Detailed Design. Process Control.

HelixRouter is a package router in the HelixStore. It reads the bar code on the package and routes it to the appropriate output conveyor belt.

IP Infrastructure

Protocols Sequence Diagrams

Protocol Sequence Diagrams for ARP, BOOTP, DCHP and ICMP.

TCP and Applications

Protocols Sequence Diagrams

Protocol documentation for TCP slow start, congestion avoidance etc. TCP Application documentation for HTTP and Telnet.

Zeta Corporation Orientation

Slideshow Collaboration diagrams used (misused?) to present an animated slide show.

Tutorial Introduction to FDL

Different steps of the introductory tutorial have been bundled together as a Scenario Project.

2.3 Hands On With EventStudio This article will get you up and running with EventStudio in a matter of minutes. Please print this page and have it ready when evaluating EventStudio Just follow the steps outlined in the following sections. You will be guided through the complete development cycle starting from FDL files and ending with generation of Sequence Diagrams, unit test procedures and other documents.



• Creating HelloWorld.fdl • Creating Hello.scn Scenario Project • Defining Basic Documents • Generating and Viewing Documents • Adding Multiple Scenarios • Adding More Documents

2.3.1 Creating HelloWorld.fdl The following steps will guide you through creating your first FDL file:

1. Invoke EventStudio from the Start Menu or the desktop.

2. Click on the "New" icon . 3. EventStudio will display a dialog box, with "FDL File" and "Scenario Project" options. 4. Select the "FDL File" option and click ok. 5. EventStudio will open a file entitled "EventStudio1". 6. Enter the contents of HelloWorld.fdl as specified below.

7. Now click on the "Save" icon to save the file. 8. EventStudio will open the "Save As" dialog box. 9. Make sure you are in the right directory. Replace the default name EventStudio1 with

HelloWorld and click "Save". 10. HelloWorld.fdl has now been created.

11. Click on the "Review FDL" icon to review the FDL file. 12. The review should pass with no errors being reported. 13. We have just created a feature definition which involves tasks/objects a to e (e is not

currently used). These tasks/objects are contained on processors p and q. p and q are housed in module x and y respectively. (A module is nothing but a logical grouping of processors)

HelloWorld.fdl module : x, y processor : p in x, q in y eternal : a in p, b in p, c in q, d in q, e in q feature "Hello World!" [* HelloWorld.fdl *] HelloWorld : a -> b a starts HelloTimer HelloWorld : b -> c HelloWorld : c -> d d takes action "Hello World!" HelloWorldAck : d -> c (* Acknowledging Hello World *) HelloWorldAck : c -> b HelloWorldAck : b -> a a stops HelloTimer endfeature 2.3.2 Creating Hello.scn Scenario Project



EventStudio supports definition of multiple scenarios for a feature. These scenarios would cover different success and failure cases for the feature being developed. A Scenario Project keeps track of all the Scenarios that have been defined for a feature. In this section we will create a new Scenario Project for the "Hello World!" feature. The first scenario for the feature will also be defined.

1. Click on the "New" icon . 2. EventStudio will display a dialog box, with "FDL File" and "Scenario Project" options. 3. Select the "Scenario Project" option and click "OK". 4. EventStudio will launch the "Scenario Wizard" and it will prompt you to enter a scenario

name for the first scenario in the Scenario Project. 5. Enter the text "Success Scenario" (without the quotes!) and click "Next". 6. Scenario Wizard will then prompt you to enter the FDL file that will define this scenario, 7. Click on the "Browse ..." button. 8. Scenario Wizard will display the "File Dialog". Select "HelloWorld.fdl" and click "Open". 9. Now click the "Next" button. 10. Scenario Wizard will display that the scenario definition has been completed. Click on the

"Finish" button. 11. Since this is the first Scenario in a new Scenario Project, you will be prompted to specify

the name for the new Scenario Project. 12. Enter Hello in the dialog box and click "Save". 13. You have just created your first Scenario Project.

2.3.3 Defining Basic Documents We have already created our FDL file and Scenario Project. We will now define the documents that should be generated for this Scenario Project. The Document Wizard will be used to define the documents. Once we have defined the documents we will see how easy it is to generate all the documents by a single click. The following steps define one document of every type of documents supported by EventStudio. You can choose to just add a new document and move on to generating documents.

1. Click on the "Add Document" icon . 2. EventStudio will launch the Document Wizard. The Document Wizard will display a

menu, listing the type of documents that can be generated. 3. Select Sequence Diagram and click "Next". 4. The Document Wizard will display document generation options. You can fine tune these

options to control the content and format of the Sequence Diagram. For now we will accept the defaults by clicking "Next".

5. Document Wizard will now prompt you to name the document. A default name is also provided. We will accept the default name by clicking "Next".

6. Document Wizard has finished adding the document. Now you can choose between adding another document and exiting the Document Wizard. Click on the button "Add More Documents".

7. The Document Wizard will again display a menu listing types of documents. Select Collaboration Diagram and click "Next".

8. Now Click "Next" on the "Generation Options" and "Document Name" pages to accept the default options and name.

9. Now click "Finish" to exit the Document Wizard. 10. We have just finished defining the basic documents. You can see the document

definitions on the left side pane. The definitions are listed below the "Documents" tree entry.



2.3.4 Generating and Viewing Documents

1. Click on the "Generate All Documents" icon . 2. EventStudio will generate all the documents we have defined. 3. The documents have been generated in the same directory as HelloWorld.fdl and

Hello.scn files. 4. EventStudio will automatically open a PDF sequence diagram (if defined.) 5. You can open the documents by double clicking on the document icons in the

Scenario Bar on the left side. (Once a PDF document has been opened, subsequent "Generate All" commands will automatically update the open PDF document.)

6. All the generated documents can also be accessed by opening the document index.

(Click on the "Document Index" icon)

2.3.5 Adding Multiple Scenarios

1. Now edit HelloWorld.fdl to add the lines shown in bold in the new version of HelloWorld.fdl shown below.

2. Click on the "Save" icon to save the file. 3. When you save the file, EventStudio senses that a new case statement has been added

and the Scenario definition for the "Success Scenario" needs to be updated to reflect this change.

4. EventStudio will prompt you to make a selection for the "Success Scenario". EventStudio will display the legs for the case statement.

5. Select "d accepts Hello World" and click "OK". 6. Let's focus on the left side pane for the Scenario Project. Expand the "Success Scenario"

tree by clicking on the plus sign. 7. You will see that EventStudio has added an entry for the "d accepts Hello World". Double

clicking on this entry will take you directly to the definition of this leg. 8. Now expand the "HelloWorld" icon just under the "FDL Files" tree entry. 9. The tree entry will expand to show all the case legs in the FDL file. Double clicking on

any of the legs will take you directly to the corresponding leg statement.

10. We will now add a second scenario to our project. Click on the "Add Scenario" icon . 11. EventStudio will launch the Scenario Wizard. Scenario Wizard will prompt you to enter

the name for the new Scenario. 12. Enter the text "Failure Scenario" (without quotes) and click "Next". 13. Scenario Wizard will now prompt you to enter the FDL file which will be used to define the

Scenario. 14. Click on the "Browse ..." button and select HelloWorld.fdl. 15. Once the FDL file has been selected, click "Next". 16. Scenario Wizard will now prompt you to select between the two legs defined in the FDL

file. 17. Select the leg "d rejects Hello World" and click "Next" 18. Now click on the "Finish" button to exit the Scenario Wizard. 19. "Failure Scenario" has been successfully added to the Project. 20. Notice that EventStudio has added the Scenario definition to the left pane. The left pane

allows you to keep track of all the Scenarios defined in the Scenario Project. EventStudio allows you to rename and reorder the Scenarios.

21. Now click on the "Review All Scenarios" icon . 22. EventStudio will review all the Scenarios in the Scenario Project. The result will be

reported in the output pane at the bottom on the screen.



23. Now click on the "Generate All Documents" icon . 24. EventStudio will regenerate all the documents. This time all the documents will include

the "Success Scenario" as well as "Failure Scenario".

HelloWorld.fdl with Case Statement module : x, y processor : p in x, q in y eternal : a in p, b in p, c in q, d in q, e in q feature "Hello World!" [* HelloWorld.fdl *] HelloWorld : a -> b a starts HelloTimer HelloWorld : b -> c HelloWorld : c -> d case leg "d accepts Hello World": d takes action "Hello World!" HelloWorldAck : d -> c (* Acknowledging Hello World *) HelloWorldAck : c -> b HelloWorldAck : b -> a leg "d rejects Hello World": d takes action "Huh!" HelloWorldReject : d -> c (* Rejecting Hello World *) HelloWorldReject : c -> b HelloWorldReject : b -> a endcase a stops HelloTimer endfeature

2.3.6 Adding More Documents We have explored basic operation of EventStudio. Now we will examine the some other documents that EventStudio can generate.

1. Click on the "Add Document" icon . 2. EventStudio will launch the Document Wizard. The Document Wizard will display a

menu, listing the type of documents that can be generated. 3. Select Interface Sequence Diagram and click "Next". 4. The Document Wizard will again display a menu listing types of documents. Select

Interface Sequence Diagram and click "Next". 5. Document Wizard will prompt you to enter the "Interface Filter". The filter is used to

specify the module, processor or task for which the interface document has to be generated. We will just enter the text "a" (without the quotes). This specifies that we intend to generate an interface document for task "a" in HelloWorld.fdl. Click "Next" after entering "a".

6. Now Click "Next" on the "Generation Options" and "Document Name" pages to accept the default options and name.

7. Click "Add More Documents" after Document Wizard finishes adding this document. 8. Now select Interaction Collaboration Diagram from the Menu and click "Next".



9. Now select "Inter-module Interactions" and click "Next". This will specify a document that just displays inter module message interactions only.

10. Accept the defaults for the next two pages. Again click "Add More Documents" to define yet another document.

11. This time select Message Filter Sequence Diagram and click "Next". 12. Enter "Ack" (without quotes) as the message filter and click "Next". This will specify a

document that just lists message interactions where the message name includes the sub-string "Ack".

13. Accept the defaults for the next two pages. Again click "Add More Documents" to define yet another document.

14. Now select Unit Test Procedures from the menu and click "Next". 15. Enter "a" (without quotes). This will define a unit test procedures document for task "a".

Click "Next" to move to the next page. 16. Accept the default name and click "Next". 17. Now click "Add More Documents" to add another document. 18. We now select the final document in this tutorial. Select Summary Document and click

"Next". 19. The next page gives you an option to obtain summary for a subset of the document. We

will leave the option at "Summary for All" and click "Next". 20. Accept the default document name and click "Next". 21. Now click "Finish" to exit the Document Wizard. 22. You will now see these documents in the Scenario Bar.

23. Generate the documents by clicking on "Generate All Documents" .



3 FDL System Design Language 3.1 Introduction to FDL The software development involves the design state followed by coding. The design stage describes the system using informal methods like text documents, figures. The output of this stage cannot be verified for correctness by tools. The coding stage happens to be the first formal description of the system. The output of this stage can be verified by using compilers and linkers. This represents a sort of impedance mismatch between the two development processes. Design is largely informal while coding is completely formal. The Feature Description Language (FDL) tries to bridge this gap by introducing a semi-formal development system for design. It tries to incorporate features from both the stages:

• FDL documents allow the user to express the system even when all the details of the system have not been defined.

• FDL documents allow the user to review the correctness of the system design by running an automated review process.



3.2 Call1.fdl: Introduction to the Language A very simple FDL program is shown below. It shows modules and processors defined in the system. Message interactions between processors are shown enclosed in the feature-endfeature block. We will be building on this example as we go along with basic and advanced tutorials. The FDL file and documents generated at each stage are available in the Tutorial directory of the EventStudio installation. 1. module : customer, exchange 2. processor : phone in customer 2. processor : frontend in exchange, core in exchange 3. feature "Call Setup" 4. offhook : phone -> frontend dialtone : frontend -> phone digits : phone -> frontend setup_call : frontend -> core setup_complete : core -> frontend ringback : core -> phone endfeature

1. This program defines the message exchanges between a customer and a telephone exchange. The customer and the exchange have been declared with the module declaration.

2. The processor statements in the next two lines define different entities within the customer and the exchange. Here the customer contains a phone and the exchange contains a frontend and a core processor. This relationship is specified using the in keyword.

3. The feature-endfeature block follows the declarations in FDL. A title for the feature is included in the feature declaration. The feature…endfeature block encloses all the feature interactions between the customer and the exchange.

4. Message interactions have been enclosed within the feature-endfeature block. The first message interaction in the sequence sends an offhook message from the phone to the frontend processor. This is followed by other message interactions involved in call setup. Messages are represented as arrows from the source to the destination.

Note: FDL also supports a multicast statement for modeling message interactions where a single message is simultaneously received by multiple entities. This statement has not been covered in this tutorial. Examine the Tutorial.pdf file at this point to see the correspondence between the FDL file and PDF output.



3.2.1 What are Modules, Processors and Objects? FDL allows you to partition your system into a three level hierarchy. At the highest level are modules. The system consists of modules. Modules contain processors and processors contain eternal and dynamic objects. The selection of modules, processors and object is best explained with examples. Acme Inc. Recruiting Modules are Recruiters, Acme_Inc, Media, Other_Company etc. Processors contained in Acme_Inc are the various departments in the company, e.g. Finance, HR, IT. Objects contained in the HR department are HR_Secretary, Recruitment_Specialist. Highway System Modules are Highways, EntryRamp, TollBooth etc. Processors contained in Highway are Cars, Trucks, Motorbikes etc. Object contained in a Car are steering, brakes, engine etc.



3.3 Call2.fdl: Comments, Remarks and Issues This part of the tutorial introduces you to the various types of comments and remarks that are supported by FDL. The following comment types are supported:

• C-Type comments • Remarks • Block Remarks • Issue statement

Standard C-type comments are supported for programmer documentation. Remarks and Block Remark comments allow the user to explain the feature flow. There output will appear in the PDF documents. Issue statements are used to keep track of unfinished sections and review comments. Issue statements output appears in the PDF output as well as Output Window at the bottom of the screen. module : customer, exchange processor : phone in customer processor : frontend in exchange, core in exchange 1. /* Originating Call Setup */ feature "Call Setup" offhook : phone -> frontend 2. (* Subscriber lifts the phone to initiate a call *) dialtone : frontend -> phone digits : phone -> frontend setup_call : frontend -> core 3. issue "Call setup parameters have not been defined" setup_complete : core -> frontend

[* Setup completed, waiting for called subscriber to be rung *] 4. ringback : core -> phone endfeature

1. FDL supports C-type comments enclosed in /* comment */. Multi-line comments can be placed between any FDL statements. EventStudio will ignore these comments during the initial review. C-type comments have no impact of the FDL output documents.

2. FDL supports remarks enclosed in (* remark *). The remarks are always printed on the right side remark column of PDF documents. FDL associates remarks with the previous FDL statement. In this case, the remark corresponds to the message statement sending an offhook from the phone to the frontend. Remarks should generally be defined for almost every statement. This helps the reader in quickly understanding the feature.

3. An issue statement can be added whenever the author has some unresolved issues. These statements are printed in bold on in the remarks column. Issue statements are reported in the output window whenever the author reviews the document. This allows the author to quickly identify if any issues are unresolved. This statement may also be used to provide review comments on an FDL file.

4. FDL supports block remarks enclosed in [* block remark *]. Block remarks are always printed along the complete width of the PDF output page. The block remarks do not associate with any FDL statement. Use block remarks to show milestones in the execution of a feature. They may also be used to define large remarks that would not fit as a normal remark.

Notes:

• Block remarks [* block remark *] and remarks (* remark *) can be multi-line. • Block remarks also support division of text into multiple paragraphs.



3.4 Call3.fdl: Object Management and Message Parameters We have seen earlier that FDL allows the developer to describe the system by representing it in terms of modules and processors. FDL also supports definition of objects inside the processors. Objects could be eternal or dynamic. Eternal objects are created at system startup and they exist throughout the life of the system. Dynamic object on the other hand are created and destroyed dynamically. The system represents eternal objects with instance axis that runs from the beginning of the document to the end. The instance axis for dynamic objects runs from the creation time to the deletion time. In Call3.fdl we have added call_mgr and call objects to the frontend processor. Once objects are defined on a processor, all the messages should specify the objects on the processor. Thus references to the frontend processor have been replaced with references to call_mgr and call objects. In addition to this, definition of objects allows us to specify the detailed message handling on the frontend processor. Additionally, the tutorial also demonstrates how message parameters can be specified in FDL. Message parameters can be added to any message interaction. module : customer, exchange processor : phone in customer processor : frontend in exchange, core in exchange 1. eternal : call_mgr in frontend 2. dynamic : call in frontend /* Originating Call Setup */ feature "Call Setup" 3. offhook : phone -> call_mgr (* Subscriber lifts the phone to initiate a call *) 4. call_mgr creates call offhook : call_mgr -> call dialtone : call -> phone digits : phone -> call 5. setup_call(digits="1-800-433-444", mode=NORMAL) : call -> core setup_complete : core -> call [* Setup completed, waiting for called subscriber to be rung *] ringback : core -> phone onhook : phone -> call call_over : call -> call_mgr 6. call_mgr deletes call endfeature

1. This statement declares an eternal object call_mgr running on the frontend processor. Use this statement to declare objects that are created at system startup and never die during the system operation (hence the name eternal)

2. A dynamic object is declared in this statement. Use this statement to declare objects that will be created and deleted dynamically by the system.

3. We have now defined two objects in the frontend processor. Thus all message interactions need to specify the object that will be receiving the message. In this case, the message destination has been changed from frontend processor to call_mgr eternal object.

4. A dynamic object needs to be created explicitly. Here a call object has been created. Use the create statement to create dynamic objects

5. This statement just adds more detail to the setup_call message. The message parameters digits and mode have been specified. Message parameters are printed below the message arrow. The message parameter values are specified as a string in



one case. Note that the message name, field name and the field value can all be defined as strings or identifiers. (Also note that specifying the parameter value is optional)

6. This statement shows the call_mgr deleting the call. Typically a dynamic object created in a feature should be deleted before the feature ends (EventStudio will warn you if you don't do so). Use the delete statement when a dynamic object needs to be deleted. The delete statement also allows a self delete (i.e. call deletes call)



3.5 Call4.fdl: Timer and Resource Management This section introduces the timer and resource management statements in FDL. FDL supports starting, stopping and timeout for timers by eternal and dynamic objects. Using the FDL timer management statements can help you identify stray timer problems (i.e. the timer was not stopped when it was supposed to). EventStudio issues a warning if it finds that timers have been left running at feature end. For dynamic objects, a warning will be issued if timers are left running at object deletion. Resource allocation and de-allocation can be carried out by eternal and dynamic objects. FDL resource management statements can help you catch resource leaks. EventStudio issues a warning when it finds that resources have not been de-allocated at feature end. For dynamic objects, a warning will be issued if all resources allocated by the object have not been freed at object deletion. 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" offhook : phone -> call_mgr (* Subscriber lifts the phone to initiate a call *) 1. call_mgr allocates "Subscriber Terminal" call_mgr creates call offhook : call_mgr -> call dialtone : call -> phone 2. call starts await_first_digit_timer digits : phone -> call 3. call stops await_first_digit_timer 4. call starts more_digits_timer 5. timeout more_digits_timer setup_call(digits="1-800-433-444", mode=NORMAL) : call -> core setup_complete : core -> call [* Setup completed, waiting for called subscriber to be rung *] ringback : core -> phone onhook : phone -> call call_over : call -> call_mgr call_mgr deletes call 6. call_mgr frees "Subscriber Terminal" endfeature

1. The Call Manager allocates a "Subscriber Terminal" resource before the call is started on that terminal. This demonstrates the resource allocate statement in FDL.

2. Here the start timer statement is used to start a timer. The Call object has just fed dialtone to the customer and it is will wait for a limited time for the subscriber to dial the first digit.

3. Some digits have been received from the subscriber, so the first digit timer is stopped. This is represented by the stop timer statement in FDL.

4. Call starts the more_digits_timer awaiting more digits from the customer. 5. The customer does not dial any more digits; this results in timeout of the

more_digits_timer. This is represented by the timeout statement. (Note that all timers should be stopped or they should result in a timeout. EventStudio will issue a warning if a



timer is left running when the feature ends. In addition to this EventStudio will issue a warning when timers are left running at the time of deleting a dynamic object)

6. The call has ended, so the "Subscriber Terminal" resource can now be freed up. This is accomplished by using the resource free statement in FDL.

Note: FDL also supports timer restart. This statement has not been covered in this tutorial.



3.6 Call5.fdl: Environment Interactions, States and Actions In this section we will cover the following topics:

• Message interactions with the Environment • State Change statement • Action statements

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" 6. call_setup_request : core -> env_r call_setup_response : env_r -> core setup_complete : core -> call



call state = "Awaiting Answer" [* Setup completed, waiting for called subscriber 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 right environment. The right environment is assumed to be at the right edge of the document.



3.7 Call6.fdl: Defining Types for Modules, Processors and Objects Many times in Embedded and Distributed 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 Sequence Diagrams. The main difference will be seen in definition of Interface Documents and Unit Test Procedures. 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:call_mgr in frontend1

eternal : call_mgr2:call_mgr 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 completed, waiting for called subscriber to be rung *] ringback : core -> phone1 hang_up : env_l -> phone1 onhook : phone1 -> call1

release_call : call1 -> call2 7. 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.



3.8 Call7.fdl : Case, If-Else-Endif and Page Break Statements Embedded and Distributed feature design involves considering multiple success as well as failure scenarios in the execution of a feature. Even for simple features, the total number of scenarios can be staggering, thus making it impractical to document all the scenarios. This results in the designer just focusing on the major scenarios in the execution of a feature. This lack of focus on other scenarios causes lot of system instability; often leading to unhealthy finger pointing sessions after the system fails to perform optimally. FDL solves the problems with multiple scenario definition by allowing designers to specify multiple scenarios in a single FDL file. Thus instead of defining multiple documents for each scenario, the designers just have to define multiple scenarios in a single file. In this section we will be covering how a single FDL file can store definitions of multiple scenarios. This is accomplished using the Case statement. Case statements are used to specify flow of the feature in different scenarios. The leg statements in the case statement correspond to different scenarios. Case statements can be nested; this allows definition of really complex scenarios. Once the Case statements have been defined in an FDL file, the Scenario Wizard is used to define multiple scenarios by selecting the case legs to be taken in each scenario. If this seems a bit complicated, look at the example below to understand how scenarios are defined. If-statements in FDL build upon the case statements. The if-statements are useful when a single scenario selection leads to flow changes at multiple places. The if-statements can use the scenario selection from a case statement to choose between two different flows. module : customer1:customer, exchange, customer2:customer processor : phone1:phone in customer1, phone2:phone in customer2 processor : frontend1:frontend in exchange, core in exchange processor : frontend2: frontend in exchange eternal : call_mgr1:call_mgr in frontend1

eternal : call_mgr2:call_mgr in frontend2

dynamic : call1:call in frontend1, call2:call in frontend2 /* Originating Call Setup */ feature "Call Setup" 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" 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 completed, waiting for called subscriber to be rung *] ringback : core -> phone1 1. case 2. leg "Called subscriber answers the call": pick_up_phone : env_r -> phone2 answer : phone2 -> call2 answer_received: call2 -> call1 [* Call is now in conversation mode *] 3. case leg "Called subscriber hangs up first": hang_up : env_r -> phone2 Clear_back : phone2 -> call2 Clear_back : call2 -> call1 leg "Calling subscriber hangs up first": endcase 4. leg "Called subscriber does not answer the call": leg "No answer and subscriber has voice mail service": issue "Voice mail call handling needs to be added" endcase hang_up : env_l -> phone1 onhook : phone1 -> call1 release_call : call1 -> call2

if "Called subscriber answers the call" 5. LogCall(status=METERED_CALL) : call2 -> core 6. else LogCall(status=UNMETERED_CALL) : call2 -> core stop_ring : call2 -> phone2 endif 7. pagebreak 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. The case statement is enclosed in the case and endcase keywords. The case statement defines different legs that can be taken by the feature at this point. When EventStudio encounters a Case statement, it expects an input on which leg of the case statement has to be selected. This input is usually provided by the Scenario definition in a Scenario Project.

2. This statement declares the first leg in the case statement. This leg defines the feature leg taken when the subscriber answers the call. The statements that follow a leg statement will be executed only if the leg has been selected.



3. Any FDL statement can be used after the leg statement. Here we have shown a nested case statement. This case statement specifies the differences in flow, depending on which subscriber clears the call first.

4. This is the next leg for the outer case statement. This also marks the end of flow for the leg statement described in step (2.). Note that this leg statement does not have any FDL statements specified after it. This means that for this leg no specific action is required.

5. This statement demonstrates the if-else-endif statement. The if-statement switches on a previously defined leg label. The if-leg will be taken if the corresponding case leg was selected in the case statement. The else leg will be taken if the corresponding leg was not selected in the case statement.

6. The else-endif block is specified here. This block is optional, i.e. an if-endif statement might also be used, if no specific flow needs to be specified in the else leg.

7. Here we show the pagebreak statement. This statement inserts a page break in a PDF file. Use this statement whenever you wish to start the output on a new page.



3.9 FDL Error Reporting FDL Errors are reported in the Output Window at the bottom on the screen. Errors and Warnings associated with a certain FDL file are listed under the FDL icon for that file. Double clicking on an error or warning opens the FDL file and moves the cursor to the appropriate line. EventStudio reports the following errors/warnings when FDL documents are reviewed:

• ERROR: An error was encountered while parsing the FDL file. • RUNTIME ERROR: A run time error is reported if EventStudio encounters an error after

parsing has been completed. • WARNING: EventStudio warns of a possible problem. The document review continues

even after a warning has been reported. • ISSUE: An issue is reported. The issue output is generated whenever an issue statement

is encountered. This allows the user to keep track of any unresolved design issues. This statement may also be used to add review comments to the FDL file. The document review continues even after an issue has been reported.

• STATUS: Status of the review is reported in the output window.



4 FDL Reference 4.1 Action statement This statement is used to show a specific action taken by a single object or a group of objects. The name of the object and the action must be specified. This statement may be used during detailed design phase. An action statement can be put only inside the feature-endfeature block in the FDL file. The output of an action statement is shown as a box with the action indicated inside it. The action statement font, color and line width may be changed by prefixing it with a style statement. The "action" statement also supports hyperlinks. The hyperlinks may be used to link to files on the Internet or your local drive. Note: The strings used in this statement should not contain any leading or trailing blanks. Also words within the string should not be separated by more than one blank. Examples call_mgr takes action "Obtain subscriber profile" Here, the call_mgr object is shown to perform the action of obtaining the subscriber profile. audit takes action "Check data consistency" Here, the audit object is shown to perform the action of checking data consistency. [act_style] client, server take action "Establish TCP Connection" Here, the client and the server take a joint action “Establish TCP Connection”. The statement also associates a style with the action statement. The style specifies the color, font, line width etc. for this action. bank, broker, customer take action "Close the Loan" The bank, the broker and the customer work together to close the loan. a, b take action "SIP Call" <http://rfc.net/rfc3261.html> Here the action box is also a hyper link pointing to the SIP RFC. bsc1, bsc2 take action "Handover" <file://c:\Doc\handover_diagram.pdf> The above statement links to a sequence diagram describing the handover in detail.



4.2 Action Begin statement This statement is used to show an action being started by a single object or a group of objects. The names of the objects performing the action and the action must be specified. This statement may be used during detailed design phase. An action begin statement can be put only inside the feature-endfeature block in the FDL file. Use action end statement to mark the end of an action. EventStudio issues a warning if an action that was started by an "action begin" statement is not completed by an "action end". The output of an "action begin" statement is shown as a box with begin as the title. The action is indicated inside the box. The action statement font, color and line width may be changed by prefixing it with a style statement. The "action begin" statement also supports hyperlinks. The hyperlinks may be used to link to files on the Internet or your local drive. Note: The strings used in this statement should not contain any leading or trailing blanks. Also words within the string should not be separated by more than one blank. Examples call begins action "Feeding Ring back tone" . . . call ends action "Feeding Ring back tone" Here, the call object is shown to initiate the action of feeding ring back tone. Later on, the call object ends feeding the ring back tone. The begin action is also hyperlinked to another document. [my_style] client,server begin action "Security Association" . . . [my_style] client,server end action "Security Association" The client and server objects jointly begin the action of setting up a "Security Association". Later on, the client and the server objects jointly end the "Security Association". The statement also associates a style with the action statement. The style specifies the color, font, line width etc. for this action.



4.3 Action End statement This statement is used to mark the end of an action initiated by action begin. The names of the objects completing the action and the action must be specified. An action end statement can be put only inside the feature-endfeature block in the FDL file. Use the "action begin" statement to mark the start of an action. EventStudio issues a warning if an action that was started by an "action begin" statement is not completed by an "action end". The output of an action end statement is shown as a box with end as the title. The action is indicated inside the box. The action statement font, color and line width may be changed by prefixing it with a style statement. The "action end" statement also supports hyperlinks. The hyperlinks may be used to link to files on the Internet or your local drive. Note: The strings used in this statement should not contain any leading or trailing blanks. Also words within the string should not be separated by more than one blank. Examples call . . .

begins action "Feeding Ring back tone"

call ends action "Feeding Ring back tone" <http://c:\dialtone.pdf> Here, the call object is shown to initiate the action of feeding ring back tone. Later on, the call object ends feeding the ring back tone. The "ends action" statement is hyperlinked to a file on the local drive. [my_style] client,server begin action "Security Association" . . . [my_style] client,server end action "Security Association" The client and server objects jointly begin the action of setting up a "Security Association". Later on, the client and the server objects jointly end the "Security Association". The statement also associates a style with the action statement. The style specifies the color, font, line width etc. for this action.



4.4 Block Remark statement This statement allows the user to explain the feature flow. FDL supports block remarks enclosed within [* and *]. FDL supports multi-line block remark statement. Block remarks are used to show milestones in the execution of a feature. They do not associate with any FDL statement. It should be noted that a block remark statement could be put only inside feature-endfeature block in the FDL file. Block remarks are printed along the complete width of the PDF output page. Block remarks support the following formatting options:

• The text can be divided between paragraphs by simply leaving a blank line between the two paragraphs.

• Block remark text alignment can be changed from the Tools->Options menu. Supported alignment options are:

o Left Align o Center Align o Right Align o Justify o Verbatim (Line breaks are preserved)

Examples routing_response : rout_mgr -> call_mgr ringing : call_mgr -> trm_call [* Call routing complete, terminating subscriber being rung, answer awaited *] Here, the block remark statement is not associated with any message statement. It indicates the milestone that the call is in ringing phase. [* This scenario describes call setup when the call is originated by a mobile subscriber. The document describes a detailed flow involving the base station, MSC, HLR and VLR. Note that this document corresponds to Release 05.00.77. Changes are needed to support the latest release. *] channel_setup : SubscriberTerminal -> BaseStation AGCH : BaseStation -> SubscriberTerminal

This block remark statement has been used to provide an introduction to the scenarios. Note how the text has been divided into two paragraphs. The output scenario diagrams will preserve the division into paragraphs.



4.5 Case statement This statement is used to specify multiple scenarios in the same FDL file. A case statement is enclosed within a case-endcase block. The legs for the case are included within the case-endcase block. Use the leg statement to define each scenario option. Nesting of case statements is also supported. A scenario determines the flow of a feature under certain conditions. To define a scenario, use the Scenario Wizard and select a leg from each case statement that is encountered in the feature flow. A case statement can be put only inside the feature-endfeature block in the FDL file. There is no output corresponding to the case statement. The leg selected for defining the scenario is displayed in bold in the right side remarks column in a sequence diagram. Examples case leg "Switchover fails": . . . leg "Switchover succeeds": . . . leg "Switchover aborted": . . . endcase Here, a simple case statement is shown where three legs have been specified. As a part of scenario definition, when Scenario Wizard encounters this case statement, it prompts the user to select a leg from the three options. case leg "Partial dialing": . . . leg "Complete dialing": . . . case leg "Routing failure": . . . leg "Routing successful": . . . case leg "Outgoing trunk congestion": . . . leg "Called party busy": . . . leg "No answer": . . . leg "Successful call": . . . endcase endcase endcase Here, a nested case statement is shown. As a part of scenario definition, when Scenario Wizard encounters this case statement, it prompts the user to select a leg from the outermost case statement. If the user selects "Partial dialing", the scenario definition would complete. If, however, the user selects "Complete dialing", Scenario Wizard will prompt the user to select another leg from the next nested case. If the user selects "Routing successful", the user is again prompted to select a leg from the innermost case statement. If the user selects "Successful call", the scenario definition for a successful call would complete.



4.5.1 Relation With If-Else-Endif Statement

• Any case leg traversed in the case-endcase may be used in an if-else-endif or if-endif statement.

• Case-endcase statements may be enclosed within an "if" or "else" part of an if-else-endif or if-endif statements.



4.6 Chain statement The Chain statement allows you to define a message chain to model a chain of messages that are triggered in a sequence. EventStudio attempts to draw all messages in a message in a single line. The statement is useful in modeling scenarios where a sequence of messages is to be depicted and the actual handling takes place when the sequence of messages terminates. By using the chain statement, the sequence of messages is depicted on a single line in a sequence diagram. This reduces the clutter in the diagrams. Multiple Message statements may be enclosed between the chain and endchain keywords: Example chain [rstyle] msg : a -> b msg2(par1="one", par2): b -> c [talk] conversation: c <-> d endchain

The chain statement shown above will be drawn in a single line if the message arrows do not result in an overlap.



4.7 Comment statement This statement is used to provide programmer documentation. FDL supports standard C-type comments enclosed within /* and */. FDL supports multi-line comment statement. EventStudio ignores the standard C-type comments and no output is produced corresponding to the comment. Examples /* V5.2 originating call setup */ feature "Call Setup" msg1 : phone -> call_mgr msg2 : call_mgr -> core endfeature

Here, the comment informs the programmer that the call setup feature for the v5.2 originating call is being covered.



4.8 Create statement This statement is used to create a dynamic object. The object that creates the dynamic object must be specified. A dynamic object create statement can be put only inside the feature-endfeature block in the FDL file. Use a dynamic declaration statement to declare a dynamic object. Use the delete statement when a dynamic object needs to be deleted. A dynamic object created in a feature must be deleted before the feature ends. The output corresponding to a create statement is shown as a dotted arrow from the creator object to the created object. Create is printed on the top of the arrow. And, the instance axis for the dynamic object starts just from the create arrow. Examples dynamic : call in frontend feature "Call Setup" msg1 : phone -> call_mgr call_mgr creates call dialtone : call -> phone . . . call_over : call -> call_mgr call_mgr deletes call endfeature

Here, a dynamic object call is declared inside the frontend processor. The Call Setup feature shows that the call_mgr object creates call object. Once the call is over, call_mgr deletes the call object.



4.9 Delete statement This statement is used to delete a dynamic object. The object that deletes the dynamic object must be specified. The delete statement also allows a self-delete. A dynamic object delete statement can be put only inside the feature-endfeature block in the FDL file. Use a dynamic declaration statement to declare a dynamic object. Use the create statement when a dynamic object needs to be created. A dynamic object created in a feature must be deleted before the feature ends. The output corresponding to a delete statement is shown as a big X mark. An arrow from the deleting object to the deleted object precedes the X mark if it is not the case of self-delete. Examples call_over : call -> ccall_mgr deletes call

all_mgr

Here, on receipt of the call_over message from call object, the call_mgr object deletes the call object. release_call : rocall deletes call

ut_mgr -> call

Here, on receipt of the release_call message from the rout_mgr, the call object deletes itself.



4.10 Dynamic Object declaration This statement is used to declare an object that will be dynamically created and deleted by the system. The processor on which the dynamic object resides must be specified. A dynamic object declaration statement can be put only inside the FDL declaration block at the beginning of the FDL file. Use the create statement to create a dynamic object. Use the delete statement when a dynamic object needs to be deleted. A dynamic object created in a feature must be deleted before the feature ends. The order of the object declaration statements determines the order of the columns assigned to the objects in the Sequence Diagrams. The instance axis of a dynamic object is displayed from the creation time to the deletion time. Dynamic object names can be specified as:

• Identifiers: Identifiers can contain alphanumeric characters and an underscore. The name should begin only with an alpha character. Also, the underscore characters used in the name are treated as separators. If the column assigned to print the name is too small, the name will be split at the underscore boundaries and will be displayed in multiple rows.

• Strings: Strings are encloses in "quotes". Blanks in the strings are treated as separators. Examples dynamic : call in frontend feature "Call Setup" msg1 : phone -> call_mgr call_mgr creates call dialtone : call -> phone . . . call_over : call -> call_mgr call_mgr deletes call endfeature

Here, a dynamic object call is declared inside the frontend processor. The Call Setup feature shows that the call_mgr object creates call object. Once the call is over, call_mgr deletes the call object. dynamic : call1:call in frontend1, call2:call in frontend2 Here, dynamic objects call1 and call2 are declared. The call1 object has been declared inside the processor frontend1 and call2 inside frontend2. Further, call1 and call2 have been declared to be of object type call. dynamic : "Originating Call" in "SIP Server", "Terminating Call" in "SIP Server" Dynamic objects declared as strings. dynamic : [call_sty] sip_call in client, [call_sty] h323_call in server Eternal objects have been declared with a style specification. The font, line width, line style, color and image specified in the style are used to draw the dynamic objects (For details refer to section 4.31 - Style declaration). Notes:

• It is recommended that light weight header (with or without image) be selected when dynamic object instance style is used (The light weight header can be selected from the "Tools->Options->Customize tab" menu selection).



4.11 Environment declaration 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. env_l and env_r are declared internally, thus there is no declaration statement for environments. env_l and env_r can be used in the message statement as source or destination of messages. Examples pick_up_phone : env_l -> phone Here, a pick_up_phone message is received from the left environment. This will be depicted as an arrow from the left edge of the document to the axis corresponding to phone. call_setup_request : core -> env_r Core sends a message to the right environment. This will be depicted as an arrow from the core axis to the right environment.



4.12 Eternal Object declaration This statement is used to declare an object that is created at system startup and exists throughout the life of the system. The processor on which the eternal object resides must be specified. An eternal object declaration statement can be put only inside the FDL declaration block at the beginning of the FDL file. The order of the object declaration statements determines the order of the columns assigned to the objects in the Sequence Diagrams. The instance axis of an eternal object is displayed from the beginning of the document to its end. Eternal object names can be specified as:


• Strings: Strings are encloses in "quotes". Blanks in the strings are treated as separators. Examples eternal : call_mgr in frontend Here, an eternal object call_mgr is declared inside the frontend processor. eternal : call_mgr1:call_mgr in frontend1 eternal : call_mgr2:call_mgr in frontend2 Here, eternal objects call_mgr1 and call_mgr2 are declared. The call_mgr1 object has been specified inside the processor frontend1 and call_mgr2 in frontend2. Further, call_mgr1 and call_mgr2 have been declared to be of object type call_mgr. eternal : "I-CSCF" in IMS, "S-CSCF" in IMS Eternal objects are declared as strings. eternal : [object_style] sip_call_manager in server Eternal objects have been declared with a style specification. The font, line width, line style, color and image specified in the style are used to draw the eternal objects (For details refer section 4.31 - Style declaration). Notes:

• It is recommended that light weight header (with or without image) be selected when eternal object instance style is used (The light weight header can be selected from the "Tools->Options->Customize tab" menu selection).



4.13 Feature statement This statement encloses all the message interactions for a feature. The feature-endfeature block follows the declarations in FDL file. A title for the feature should be specified in the feature declaration. A FDL file defines feature interactions for one feature. Hence there can be one feature-endfeature block in a FDL file. A theme may be associated with a feature-endfeature block. A theme specifies the layout options and the fonts. The feature title that is specified in the statement is displayed at the top, along the complete width of the output page of the Sequence Diagram. EventStudio performs various checks on the feature-endfeature block. It issues a warning if it finds that timers have been left running at feature end. A warning is issued if a dynamic object is not deleted before the feature ends. A warning is issued if resources have not been deallocated at feature end. Note: The strings used in this statement should not contain any leading or trailing blanks. Also words within the string should not be separated by more than one blank. Examples feature "Call Setup" msg1 : phone -> call_mgr msg2 endfeature

: call_mgr -> core

This feature-endfeature block encloses all the feature interactions for the call setup feature. {MyTheme} feature "Call Setup" msg1 : phone -> call_mgr msg2 : call_mgr -> core endfeature

Here a feature-endfeature block is shown with a theme specification for the feature. The theme specifies the layout options and the font sizes.



4.14 Goto and Label statements The Goto statement allows you to jump forward to a label defined at a later point in the FDL. Use this statement to exit the diagrams from error scenarios. The following restrictions apply: • A Goto statement can be used to jump forward only, i.e. jumping to a label defined before the

goto statement is not allowed. • A label cannot be defined within a case-endcase, if-endif or an if-else-endif block. Example Case leg "No digits dialed": goto exit leg "All digits dialed": endcase case leg "Call routing successful": leg "Call routing failed": goto exit endcase label exit: [* call has ended. *] A "goto" to the exit label is being used to end error scenarios in a call setup.



4.15 Heading statement A large sequence diagram may be subdivided into sections using the heading statement.

• The headings are displayed as a block remark. • A bookmark to the headings is added in the left pane of a PDF sequence diagram file. • Message numbering is reset when headings are encountered.

Examples The syntax for headings is shown in the following example: heading "Conversation Mode"



4.16 If-Else-Endif statement This statement is used to choose different feature flows from previously encountered leg statements. The string for the if-statement must have been defined as a leg of a previous case statement. When EventStudio encounters the If-Else-Endif statement, it transfers control to the "If block" if the leg corresponding to the "if string" has been chosen in a previous case statement. The control is transferred to the "Else block" if the leg corresponding to the "if string" has not been chosen. Look at the example given below to completely understand how this statement is used. There is no output produced corresponding to this statement. Examples case leg "DTMF dialing": . . . leg "Pulse dialing": . . . endcase . . . if "DTMF dialing" call frees "DTMF Receiver" celse

all takes action "Increment DTMF counter"

call takes action "Increment Pulse counter" endif

Here, a case statement defines the legs "DTMF dialing" and "Pulse dialing". Later on in the feature flow if statement checks if "DTMF dialing" leg was chosen. If "DTMF dialing" leg was taken, control is transferred to the "if block". Otherwise the control is transferred to the "else block". It may be noted that EventStudio remembers the leg selections and user is not prompted for an input when an "if statement" is encountered.



4.17 If-Endif statement This statement is used to choose different feature flows from previously encountered leg statements. The string for the "if statement" must have been defined as a leg of a previously defined case statement. When EventStudio encounters the If-Endif statement, it transfers control to the "If block" if the leg corresponding to the "if string" has been chosen in a previous case statement. Look at the example given below to completely understand how this statement is used. There is no output produced corresponding to this statement. Example case leg "DTMF dialing": . . . leg "Pulse dialing": . . . endcase . . . if "DTMF dialing" cendif

all frees "DTMF Receiver"

Here, a case statement defines the legs "DTMF dialing" and "Pulse dialing". Later on in the feature flow if statement checks if "DTMF dialing" leg was chosen. If "DTMF dialing" case leg was taken, control is transferred to the "if block". Otherwise the control is transferred to the statement following "endif". It may be noted that EventStudio remembers the leg selections and user is not prompted for an input when an "if statement" is encountered.



4.18 Invokes and Returns statements The "Invokes" statement is used to model a method invocation on an object. The return from a method is modeled by the "returns" statement. You can specify parameters for the "invokes" as well as "returns" statements. The parameter specification syntax is similar to message parameters. Invokes and returns statements may be nested. EventStudio catches design errors like:

• Method returns are placed out of order. EventStudio makes sure that the methods return are made in a LIFO fashion (Last In First Out).

• Message receive is being attempted when a method execution is still active. The method invocation is represented with an arrow similar to the message statement. Once a method is invoked, the axis is represented as a thin rectangular bar that lasts until method return. Examples CallManager invokes Call.HandleInvite(msg="My Invite", "bool send") Call takes action "Verify the Invite Message" Call invokes MessageHandler.Send(SIP_OK)

MessageHandler.Send returns (true) Call.HandleInvite returns

A nested method invocation along with returns statements is shown above. Call invokes Call.ProcessMessage(msg="My Invite", "bool send") Call.ProcessMessage returns

An object invokes its own method.



4.19 Issue statement This statement is used to indicate unresolved issues that may exist. Another use may be to provide review comments. An issue statement can be put only inside the feature-endfeature block in the FDL file. The output corresponding to an issue statement is shown in bold in the right side remarks column. Also, whenever a review document command is given, all the issue statements in the FDL file are reported in the output window. Note: The strings used in this statement should not contain any leading or trailing blanks. Also words within the string should not be separated by more than one blank. Examples issue "Call metering procedure to be defined" Here, an issue statement has been used to indicate that the call metering procedure is yet to be finalized.



4.20 Leg statement This statement is used to specify legs within a case-endcase block. The legs for the case are included within the case-endcase block. The leg statement defines each scenario option. A scenario determines the flow of a feature under certain conditions. To define a scenario, use the Scenario Wizard and select a leg from each case statement that is encountered in the feature flow. A leg statement can be put only inside the case-endcase block in the FDL. The leg selected for defining the scenario is displayed in bold in the right side remarks column in a sequence diagram. The leg selections are also available as bookmarks in PDF sequence diagrams. When a PDF sequence diagram is open, the leg selection bookmarks are shown on the left side of the screen. Clicking on the bookmarks will take you directly to the leg selection. Note: The strings used in this statement should not contain any leading or trailing blanks. Also words within the string should not be separated by more than one blank. Examples case leg "Switchover fails": . . . leg "Switchover succeeds": . . . leg "Switchover aborted": . . . endcase

Here, a simple case statement is shown where three legs have been specified. As a part of scenario definition, when Scenario Wizard encounters this case statement, it prompts the user to select a leg from the three options. case leg "Partial dialing": . . . leg "Complete dialing": . . . case leg "Routing failure": . . . leg "Routing successful": . . . case leg "Outgoing trunk congestion": . . . leg "Called party busy": . . . leg "No answer": . . . leg "Successful call": . . . endcase endcase endcase

Here, a nested case statement is shown. As a part of scenario definition, when Scenario Wizard encounters this case statement, it prompts the user to select a leg from the outermost case



statement. If the user selects "Partial dialing", the scenario definition would complete. If, however, the user selects "Complete dialing", Scenario Wizard will prompt the user to select another leg from the next nested case. If the user selects "Routing successful", the user is again prompted to select a leg from the innermost case statement. If the user selects "Successful call", the scenario definition for a successful call would complete.



4.21 Message statement This statement is used to represent message exchanges between the source and destination. The source and destination can be any of the following:

• Processor (i.e. processor without any other objects inside it) • Eternal object • Dynamic object • Left Environment (env_l) • Right Environment (env_r)

The message-statement also allows definition of message parameters of two forms:

• Message field • Message field with value

The message name may be in identifier format (CallRequest) or string format ("Call Request"). The message field and value can be in identifier or string format. Messages will be represented as arrows from source to destination. In Sequence Diagrams, message name is printed on the top of the arrow. Message parameters are printed below the arrow. The formatting of the message parameters is customizable (See the Tools->Options menu for details). Advanced Uses • Bidirectional message interactions can be succinctly represented using the bidirectional

form of the message statement. Bidirectional messages are represented with double headed arrows.

• Important messages may be represented using weighted arrows. These arrows are drawn with a thicker arrow.

• Self messages are specified by using the same entity as source and destination. Self messages are represented with arrows that return back to the originating axis.

• Message chains can be used to depict a sequence of message interactions. Examples Message1: src_proc -> dest_proc Message1 is being sent from src_proc to dest_proc processor "SYN" : client -> server "SYN+ACK" : client <- server "ACK" : client -> server The message sequence shown above demonstrates the use of the reverse arrow. Origination(subscriber_id, mode=NORMAL) : v5_mgr -> dtmf_proc Origination message with parameters subscriber_id and mode is sent from v5_mgr object to dtmf_proc processor. Here the mode variable has been given a value of NORMAL. Origination(subscriber_id, mode=NORMAL) : dtmf_proc <- v5_mgr This example uses a reverse arrow. The destination is on the left side of the reverse arrow. The source is on the right side of the reverse arrow.



Setup(call_id, phone_num, priority=HIGH, latency=LOW) : v5_mgr -> env_r

Here is an example of a message statement with parameters spread over multiple lines. The Setup message is being sent from the v5_mgr to the right environment. The following parameters are being sent in the message:

• call_id • phone_num • priority with a value of HIGH • latency with a value of LOW

"Interview Employee": "Human Resources" -> Department A string message name and source have been used in this example. HTTP_Get(url="http://www.EventHelix.com"): WebBrowser -> Internet A string parameter value is used in this example to represent the URL value. "Purchase Order" ("Order Number" = "01-033-56"): User -> Server In this example, the message name, parameter type and value are all strings. Advanced Examples VoicePath: Caller <-> Called A bidirectional voice path has been established between the caller and the called subscribers. VoicePath: Caller <=> Called A bidirectional voice path has been established between the caller and the called subscribers. This time represented with a thick arrow. "RTP Stream": Server => Client An RTP stream from the server to the client (represented with a weighted arrow). "End of Dialing": CallHandler -> CallHandler The call handler schedules an internal “End of Dialing” message. [sip_style] "Invite" : SIP_Phone -> SIP_Proxy A style, titled sip_style, is assigned to the "Invite" message. The message is formatted according to the style specification. PathSetup: src -> dst <http://www.messagedef.com/PathSetup.html> A message with a hyperlink specification is shown here. Clicking on the message name will open a browser window for the specified URL. chain "Call Setup": UT -> BTS "Call Setup": BTS -> BSC "Initial Call Message": BSC -> MSC endchain A chain statement enclosing messages is shown above. The chain messages are drawn in a single line.



4.22 Module declaration This statement declares the modules that will be used in the feature. This should be the first statement in the FDL declaration block at the beginning of the FDL file. All the modules that are being used in the processor declaration statements must be defined using the module declaration statement before it. The order of the module declaration determines the order of the columns assigned to the modules in the Sequence Diagrams. The modules are displayed at the top of the Sequence Diagrams along the full output page width, immediately below the feature title. Module names can be specified as:


• Strings: Strings are encloses in "quotes". Blanks in the strings are treated as separators. Examples module : customer, exchange Here, two modules customer and exchange have been declared inside the system. module : calling_party:customer, called_party:customer Here, two modules calling_party and called_party have been declared. Further, it is declared that both have a type customer. module : "HTTP Server", "Web Browser" String based module names. module : [intranet_style] intranet, [internet_style] internet Modules have been declared with a style specification. The font, line width, line style, color and image specified in the style are used to draw the modules (For details refer to section 4.31 - Style declaration). Notes:

• Module instance style is used in the "module interaction sequence diagrams". • It is recommended that light weight header (with or without image) be selected

when module instance style is used (The light weight header can be selected from the "Tools->Options->Customize tab" menu selection).



4.23 Multicast statement This statement is used to represent message sent from a given source to more than one destination at the same time. The source and destination can be any of the following:

• Processor (i.e. processor without any other objects inside it) • Eternal object • Dynamic object

The multicast-statement also allows definition of message parameters of two forms:

• Message field • Message field with value

The message name may be in identifier format (CallRequest) or string format ("Call Request"). The message field and value can be in identifier or string format. A multicast statement can be put only inside the feature-endfeature block in the FDL file. Messages will be represented as arrows from source to destination. In Sequence Diagrams, message name is printed on the top of the arrow. Message parameters are printed below the arrow. The formatting of the message parameters is customizable (See the Tools->Options menu for details). Examples src_proc multicasts Message1 to dest_proc1, dest_proc2 Message1 is being sent from src_proc to dest_proc1 and dest_proc2 processors v5_mgr multicasts Orig(subscriber_id, mode=NORMAL)to dtmf_proc,call_mgr Origination message with parameters subscriber_id and mode is sent from v5_mgr object to dtmf_proc processor and call_mgr object. Here the mode variable has been given a value of NORMAL. WebTaxiServer multicasts "Taxi Request" to Taxi1, Taxi2 A string message name has been used in this example. User multicasts "Purchase Order" ("01-033-56") to Server1, Server2 In this example, the message name, parameter type and value are all strings.



4.24 Page Break statement This statement inserts a page break in PDF and EMF files. Use this statement whenever you wish to force the PDF or EMF output to start from a new page. Note: This statement applies to only PDF and EMF files. It is ignored when generating HTML output. Example . . . pagebreak [* Call Release Processing. *] Here, a page break has been forced at the beginning of a new phase of a call.



4.25 Preprocessor directives FDL supports a powerful preprocessor that is similar to the C preprocessor. All preprocessor directives begin with a hash (#). The following preprocessor directives are supported: #include "architecture.fdl" Include an FDL file located in the current directory. Paths relative to the current directory may be used. #include <theme.fdl> Include an FDL file from the paths specified in Tools->Options-Preprocessor tab. Multiple include paths may be specified. They should be separated by a semicolon (;). #define msg_ack(msg, a, b) "msg" : a -> b;\ (* msg sent from a to b *);\ "msg ack" : b -> a;\ (* b acknowledges msg *); • Macros may be defined with multiple parameters. • Multiple statements may be defined in a single line by separating them with a

semicolon (;) • Macros may be split into multiple lines by using a semicolon-backslash-enter

(;\) pattern. • Macro parameter substitution is allowed in macro text, strings, remarks and

block remarks. • Macros may be nested. #define tone_feed(d,t, a) [* Feed d#t *];\ a takes action "Feeding d t"; • Token pasting operator hash (#) allows two macro parameters to be "pasted"

together. #ifdef UMTS_RELEASE_7 #else #endif Conditional compilation is supported with the #ifdef-#else-#endif statement. Symbols controlling the conditional compilation may be defined using a: • #define, or • Symbols defined in Tools->Options->Preprocessor. (Multiple symbols may be

specified. The symbols must be separated by semicolons). #ifdef UMTS_RELEASE_7 #endif Conditional compilation is supported with the #ifdef--#endif statement. Symbols controlling the conditional compilation may be defined using a: • #define, or • Symbols defined in Tools->Options->Preprocessor. (Multiple symbols may be

specified. The symbols must be separated by semicolons).



4.26 Processor declaration This statement declares processors that will be used in the feature. The module containing the processor should also be specified. A processor declaration statement can be put only inside the FDL declaration block at the beginning of the FDL file. There can be no processor declaration statement inside the feature-endfeature block in the FDL file. The order of the processor declaration determines the order of the columns assigned to the processors in the Sequence Diagrams. Module names can be specified as:


• Strings: Strings are encloses in "quotes". Blanks in the strings are treated as separators. Examples processor : proc1 in mod1, proc2 in mod2 Declares two processors, proc1 and proc2. proc1 resides in mod1 and proc2 resides in mod2. processor : xen1:xen in xenon, xen2:xen in xenon Declares xen1 and xen2 processors, both the processors are in xenon module. Further xen1 and xen2 are declared to be of the type xen. processor : "I-CSCF" in IMS, "S-CSCF" in IMS String based processor declaration. processor : [cstyle] client in intranet, [sstyle] server in internet Processors have been declared with a style specification. The font, line width, line style, color and image specified in the style are used to draw the processors (For details refer to section 4.31 - Style declaration). Notes:

• Processor instance style is used in the "processor interaction sequence diagrams".

• It is recommended that light weight header (with or without image) be selected when processor instance style is used (The light weight header can be selected from the "Tools->Options->Customize tab" menu selection).



4.27 Remark statement This statement allows the user to explain the feature flow. The remarks are enclosed within (* and *). FDL supports multi-line remark statement. It should be noted that a remark statement could be put only inside feature-endfeature block in the FDL file. The remarks are displayed on the right side remark column of a sequence diagram. FDL associates remarks with the previous FDL statement. Examples routing_request(digits) : call_mgr -> rout_mgr (* Call manager sends the routing request to routing manager *) routing_response(destination_equipment_num) : rout_mgr -> call_mgr Here, the remark corresponds to the message statement sending the routing request message containing dialed digits from call manager object to routing manager object.



4.28 Resource Allocate statement This statement is used for allocating a resource by a single or a group of eternal and dynamic objects. The objects allocating the resource and the resource name must be specified. A resource allocate statement can be put only inside the feature-endfeature block in the FDL file. Use a resource free statement for deallocating a resource. EventStudio issues a warning when it finds that resources have not been deallocated at feature end. For dynamic objects, EventStudio issues a warning if the resources allocated by the object have not been freed before the object deletion. The output of a resource allocate statement is shown as a box with "allocate" as the title and the resource name inside it. Note: The strings used in this statement should not contain any leading or trailing blanks. Also words within the string should not be separated by more than one blank. Examples call_mgr allocates "Outgoing trunk" Here, the call manager object allocates an outgoing trunk resource for a call. [my_style] client,server allocate "Encryption Coprocessor" . . . [my_style] client,server free "Encryption Coprocessor" The client and server objects jointly allocate an "Encryption Coprocessor". Later on, the client and the server objects jointly free the "Encryption Coprocessor". The example also shows a style specification that can be prefixed to the resource allocate and free statements.



4.29 Resource Free statement This statement is used for deallocating a resource by a single or a group of eternal and dynamic objects. The resource must have been allocated earlier by the resource allocate statement. The objects deallocating the resource and the resource name must be specified in the statement. A resource free statement can be put only inside the feature-endfeature block in the FDL file. EventStudio issues a warning when it finds that resources have not been deallocated at feature end. For dynamic objects, EventStudio issues a warning if the resources allocated by the object have not been freed before the object deletion. The output of a resource free statement is shown as a box with "free" as the title and the resource name inside it. Note: The strings used in this statement should not contain any leading or trailing blanks. Also words within the string should not be separated by more than one blank. Examples [my_style] call_mgr frees "Outgoing trunk" Here, the call manager object frees the outgoing trunk resource allocated earlier for a call. The example also shows a style specification that can be prefixed to the resource allocate and free statements. client. . .

,server allocate "Encryption Coprocessor"

client,server free "Encryption Coprocessor" The client and server objects jointly allocate an "Encryption Coprocessor". Later on, the client and the server objects jointly free the "Encryption Coprocessor".



4.30 State Change statement This statement is used to represent state transitions of eternal and dynamic object state machines. State for a single or a group of objects may be specified. The name of the objects and the name of the state to which transition is taking place, must be specified. A state change statement can be put only inside the feature-endfeature block in the FDL file. This statement is used during detailed design phase. The output of a state change statement is shown as a hexagonal box with the name of state indicated inside it. Note: The strings used in this statement should not contain any leading or trailing blanks. Also words within the string should not be separated by more than one blank. Examples call state = "Collecting digits" Here, the state of the call object state machine has been specified to change to collecting digits. caller, called state = "Conversation" The caller and called subscribers have jointly entered the "Conversation" state. [my_style] "car dealership" state = "Awaiting Shipment" Here a style prefix is used to control the layout of a state statement. [my_style] customer, banker state = "Loan Closed" Here a style prefix is used to control the layout of a joint state statement.



4.31 Style declaration Style specifications allow you to specify the formatting for message statements. The style declaration allows you to specify:

• The color as red, blue and green components. • Font and font size for the message name text • Font and font size for the parameter text • Line pattern for the message arrow • Line width for the message arrow

The ranges for individual parameters are specified below. Note that not all values need to be specified in a style declaration. Message defaults are used for unspecified values. color Specifies the color to be used. The color is specified as a set of three

floating point numbers between 0.0 and 1.0. The first one denotes the red component, the second specifies the green component and the last one specifies the blue component. Millions of colors can be defined in terms of the individual color component values.

font Specifies the font of the message name. The following font strings are supported.

• "Arial" • "Arial Narrow" • "Courier New" • "Times New Roman" • "Arial-Bold" • "Arial Narrow-Bold" • "Courier New-Bold" • "Times New Roman-Bold"

fontsize Specifies the size of the message name font in points. linewidth Specifies the width of the message arrow in points. linepattern Selects the line pattern for the message arrow. The options are:

• "---" (Unbroken line) • "- -" (Dashed line)

paramfont Specifies the font for message parameters. The font strings are same as the message name font specification.

paramfontsize Specifies the size of the message parameter font in points.



image Specifies a JPEG image associated with the style. The image specification is used when styles

are applied to object, processor and module declarations. The image specified in the style is used in the column heading if "Lightweight header with column images" is selected from the "Tools menu->Options menu->Customize tab". The image selection in the header is based on the following rules:

Eternal/Dynamic Object Images

Processor Images Module Images Images Drawn in the Header

At least one eternal or dynamic object uses a style with image.

N/A N/A The eternal/dynamic objects that have associated images are drawn with the image.


Atleast one parent processor has a style with an image.

N/A Processor image is used. The image is centered between all eternal and dynamic objects within the processor.


No processor has a style with an image.

Atleast one module has a style with an image.

Module level images are used. The images are centered between all entities contained in a module.

Examples style sip: color="1.0,0.0,0.0", font="Times New Roman-Bold", fontsize="15", linewidth="4", linepattern="- -", paramfont="Courier New", paramfontsize="4" style server: color="0.0,1.0,0.0", font="Times New Roman-Bold", image="server.jpg" style mobile: color="0.0,0.0,1.0", font="Times New Roman-Bold", image="mobile.jpg" module: m processor : p in m eternal : [mobile] e in p, [server] f in p feature "Testing" [sip] invite(caller, called): e -> f [sip] two_way_path : e <-> f endfeature



4.32 Theme declaration Themes provide an overall control over the document layout. Most Tools->Options commands can be overridden using themes. • A theme declaration consists of a theme name followed by a sequence of attribute-value

pairs. The attribute-value pairs might be specified across multiple lines. The syntax is: theme MyTheme: blockRemarkFormatting="right-align", paperSize="letter" theme LeftAlign: blockRemarkFormatting="left-align"

• Initial theme for a statement is specified as a modifier to the feature statement. The attributes specified in the initial theme override the "Tools->Options" settings. The syntax is: {MyTheme} feature "a feature" endfeature

• Theme may be modified within the feature-endfeature block by placing the theme modifier on

a line. The modified theme overrides the attributes that have been specified for the modified theme. For example: {MyTheme} feature "a feature" [* Right aligned block remark *] {LeftAlign} [* Left aligned block remark *] endfeature

• A theme statement based on the current settings can be automatically copied to the clipboard

using the Tools->Copy Options as Theme command. Just issue a paste command to insert the theme statement at the desired location.

• The theme declaration supports the attribute-value pairs shown in the table below.

Attribute Possible values messageParameterFormatting "multiple-parameters-per-line-center-align"

"single-parameter-per-line-center-align" "single-parameter-per-line-left-align"

sequenceDiagramHeader "multi-tier-header" "single-tier-light-weight" "single-tier-light-weight-with-images"

blockRemarkFormatting "left-align" "center-align" "right-align" "justify" "verbatim"

assignSequenceNumbersInSequenceDiagrams "true" "false"

includeRemarkColumnInSequenceDiagrams "true" "false"

paperSize "letter" "legal" "B" "C" "A4" "A3"

1 e.g. paperSize="5.5 inch 6.5 inch" or paperSize="60 mm 70 mm".



"B4" "<width-in-inch> inch <height-in-inch> inch"

or "<width-in-mm> mm <height-in-mm> mm" 1

sequenceDiagramLayout "auto-choose-between-portrait-landscape" "landscape-only"

pageMarginPDF "small" "medium" "large"

pageMarginEMF "small" "medium" "large"

headingAndTitleFont "Arial" "Arial Narrow" "Courier New" "Times New Roman"

sequenceDiagramMessageNameFont "Arial" "Arial Narrow" "Courier New" "Times New Roman"

sequenceDiagramMessageNameFontSize "1" to "35" collaborationDiagramMessageNameFont "Arial"

"Arial Narrow" "Courier New" "Times New Roman"

collaborationDiagramMessageNameFontSize "1" to "35" messageParameterFont "Arial"


messageParameterFontSize "1" to "35" actionBoxFont "Arial"


actionBoxFontSize "1" to "35" remarkFont "Arial"


remarkFontSize "1" to "35" blockRemarkFont "Arial"


blockRemarkFontSize "1" to "35"



4.33 Timeout statement This statement is used to show the timeout of an existing timer started by an eternal or dynamic object. The timer name must be specified in the statement. A timeout statement can be put only inside the feature-endfeature block in the FDL file. Use the timer start statement for starting a timer. Use timer stop statement for stopping a timer. EventStudio issues a warning if it finds that a timer has been left running at feature end. For dynamic objects, EventStudio issues a warning if timers are left running at object deletion. A timer should either timeout or it should be explicitly stopped. The output for a timer timeout statement is shown as the end point of the downward timer axis. The timer name is displayed above a forward arrow at the timer timeout instant. Examples feature "Call Setup" offhook : phone -> call_mgr call_mgr creates call call starts await_first_digit_timer (* The calling subscriber does not dial any digit *) timeout await_first_digit_timer . . . endfeature

Here, the calling subscriber does not dial any digit and the await_first_digit_timer timeout happens.



4.34 Timer Restart statement This statement is used for restarting an already existing timer started by any eternal or dynamic process. The timer name and the object stopping the timer must be specified. A timer restart statement can be put only inside the feature-endfeature block in the FDL file. The output of a timer restart statement is shown as a continuation of a downward timer axis. The timer name is displayed on the top, at the timer restart instant. The timer axis is shown active unless the timeout happens or the timer is stopped. Example feature "Call Setup" offhook : phone -> call_mgr call_mgr creates call call starts await_digit_timer digits : phone -> call call restarts await_digit_timer timeout await_digit_timer . . . endfeature

Here, the await_digit_timer has been restarted on receipt of digits from the phone.



4.35 Timer Start statement This statement is used for starting a timer by an eternal or dynamic object. The timer name and the object starting the timer must be specified. Use the timer stop statement for stopping a timer. Use timer timeout statement for showing the timeout for a timer. EventStudio issues a warning if it finds that a timer has been left running at feature end. For dynamic objects, EventStudio issues a warning if timers are left running at object deletion. EventStudio supports one time and periodic timers. Only one timeout is permitted for "one time" timers. Periodic timers are allowed multiple timeouts. The output of a timer start statement is shown as a starting point of a downward timer axis. The timer name is displayed on the top, at the timer start instant. The timer axis is shown active unless the timeout happens or the timer is stopped. Examples feature "Call Setup" offhook : phone -> call_mgr call_mgr creates call call starts await_first_digit_timer digits : phone -> call call stops await_first_digit_timer . . . endfeature

Here, the call object starts the await_first_digit_timer (one time) timer to await first digit dialed by the subscriber. feature "Call Setup" offhook : phone -> call_mgr call_mgr creates call call starts periodic send_billing_pulse_timer . . . timeout send_billing_pulse_timer . . . timeout send_billing_pulse_timer . . . timeout send_billing_pulse_timer endfeature Here, the call object starts the send_billing_pulse_timer periodic timer. Multiple timeouts are depicted for the timer.



4.36 Timer Stop statement This statement is used for stopping an existing timer started by an eternal or dynamic object. The timer name and the object stopping the timer must be specified. A timer stop statement can be put only inside the feature-endfeature block in the FDL file. Use the timer start statement for starting a timer. Use timer timeout statement for showing the timeout for a timer. EventStudio issues a warning if it finds that a timer has been left running at feature end. For dynamic objects, EventStudio issues a warning if timers are left running at object deletion. The output of a timer stop statement is shown as the end point of the downward timer axis. The timer name is displayed above a dotted reverse arrow at the timer stop instant. Examples feature "Call Setup" offhook : phone -> call_mgr call_mgr creates call call starts await_first_digit_timer digits : phone -> call call stops await_first_digit_timer . . . endfeature

Here, the call object stops the await_first_digit_timer timer on receipt of the first digit dialed by the subscriber.



4.37 Type declaration FDL allows defining types for a module, processor, eternal object or dynamic object. This is used to specify that two or more different entities are really instances of the same entity type. A type declaration statement can be put only inside the FDL declaration block at the beginning of the FDL file. There can be no type declaration statement inside the feature-endfeature block in the FDL file. It may be noted that defining the types will have no visual impact on the PDF Sequence Diagrams. The main difference can be seen in the definition of Unit Test Procedures and Interface documents. If the user specifies the type for generating a document, EventStudio will include interfaces of all instances of the given type. Examples module : calling_party:customer, called_party:customer Here, two modules calling_party and called_party have been declared. Further, it is declared that both have a type customer. If the user specifies customer for generating an Interface document, the interfaces of calling_party and called_party will be included. The user still has the option of generating Interface documents for individual modules by specifying called_party or calling_party as the filter. processor : xen1:xen in xenon, xen2:xen in xenon Declares xen1 and xen2 processors, both the processors are in xenon module. Further xen1 and xen2 are declared to be of the type xen. If the user specifies xen for generating an Interface document, the interfaces of xen1 and xen2 will be included. The user still has the option of generating Interface documents for individual processors by specifying xen1 or xen2 as the filter. eternal : call_mgr1:call_mgr in frontend1 eternal : call_mgr2:call_mgr in frontend2 Here, eternal objects call_mgr1 and call_mgr2 are declared. The call_mgr1 object has been specified inside the processor frontend1 and call_mgr2 in frontend2. Further, call_mgr1 and call_mgr2 have been declared to be of object type call_mgr. If the user specifies call_mgr for generating an Interface document, the interfaces of call_mgr1 and call_mgr2 will be included. The user still has the option of generating Interface documents for individual processors by specifying call_mgr1 or call_mgr2 as the filter. In a similar fashion, the user can generate Unit Test Procedures for call_mgr. This would include test cases for call_mgr1 and call_mgr2. dynamic : call1:call in frontend1, call2:call in frontend2 Here, dynamic objects call1 and call2 are declared. The call1 object has been declared inside the processor frontend1 and call2 inside frontend2. Further, call1 and call2 have been declared to be of object type call. If the user specifies call for generating an Interface document, the interfaces of call1 and call2 will be included. The user still has the option of generating Interface documents for individual objects by specifying call1 or call2 as the filter. In a similar fashion, the user can generate Unit Test Procedures for call. This would include test cases for call1 and call2.



5 FDL Errors and Warnings 5.1 FDL Errors Error Number

Error Text Example Reason Solution

E002 could not open file This indicates that EventStudio is not able to open the input FDL file for review or for document generation.

Check if the FDL file has been accidentally deleted from the original directory.

E004 redeclaration of : <symbol>

This indicates that the given module, processor or process has been declared more than once.

Check the FDL file for symbol re-declaration.

E007 undefined module The parent module for the processor is undefined.

Define the parent module using the module declaration.

E008 <symbol> should be a module

The parent module specified for the processor is not a module.

Define the parent module using the module declaration.

E009 undefined processor The parent processor for the object is undefined

Define the parent processor using the processor declaration.

E010 <symbol> should be a processor

The parent processor specified for the object is not a processor.

Define the parent processor using the processor declaration.

E011 message exchange with self is not allowed

The multicast and bidirectional message interaction statements do not allow message exchange with self.

Make sure that the source and destination are different.

E012 undefined message sender

This indicates that an undefined sender has been used in the send message statement.

Define the sender processor/object symbol in the declaration section at the top of the FDL file.

E013 message sender is not an object, processor or environment.

The sender used in the send message statement should be an object, processor or environment. The given message sender is not valid.

Provide a message sender that is an object, processor or environment.



Error Number


E014 specify the sender object in <processor symbol>

The sender in the message statement is a processor. Since the given processor has objects inside it, the sender should be an object inside the given processor. Messages can be sent from a processor only if no objects have been defined in the processor.

Replace the parent processor with an object contained in the processor.

E015 undefined message receiver

This indicates that an undefined receiver has been used in the send message statement.

Define the receiver process/processor symbol in the declaration section at the top of the FDL file.

E016 message receiver is not an object, processor or environment

The receiver used in the send message statement should be an object, processor or environment. The given message receiver is not valid.

Provide a message receiver that is an object, processor or environment.

E017 specify the receiver object in <processor symbol>

The receiver in the message statement is a processor. Since the given processor has objects inside it, the receiver should be an object inside the given processor. Messages can be addressed to a processor only if no objects have been defined in the processor.


E018 should be on same processor for create

This indicates that the creator and child objects used in the create object statement are not on the same processor.

Provide creator and child objects that are on the same processor.

E019 undefined creator This indicates that the creator in the given create object statement has not been declared in the declaration section.

Declare the creator as an eternal or dynamic object inside the same processor as the one inside which the child has been declared.

E020 creator should be eternal or dynamic object.

This indicates that the creator in the given create object statement has not been declared as an eternal or dynamic object.

Declare the creator as an eternal or dynamic object. inside the same processor as the one inside which the child has been declared



Error Number


E021 undefined child object This indicates that the child in the given create object statement has not been declared in the declaration section.

Declare the child as a dynamic object inside the same processor as the one inside which the creator has been declared.

E022 object to be created should be dynamic

This indicates that the child in the given create object statement has not been declared as a dynamic process.

Declare the child as a dynamic object inside the same processor as the one inside which the creator has been declared

E023 object already created This indicates that the child in the given create object statement is being created for the second time.

Remove one of the object-create statements or insert an object delete statement before the second object create statement.

E024 should be on the same processor for delete

This indicates that the deleting object and the deleted objects used in the delete-object statement are not on the same processor.

Provide deleting object and victim objects that are on the same processor.

E025 undefined deleting object

This indicates that the deleting object in the given delete-object statement" has not been declared in the declaration section.

Declare the deleting object as an eternal or dynamic object inside the same processor as the one inside which the deleted object has been declared.

E026 deleting object should be eternal or dynamic object.

This indicates that the deleting object in the given delete-object statement has not been declared as an eternal or dynamic object.

Declare the deleting-object as an eternal or dynamic object inside the same processor as the one inside which the deleted object has been declared.

E027 undefined object This indicates that the deleted object in the given delete object statement has not been declared in the declaration section

Declare the victim as a dynamic object inside the same processor as the one inside which the deleting object has been declared.

E028 object to be deleted should be dynamic

This indicates that the victim in the given delete object statement has not been declared as a dynamic object.

Declare the deleted object as a dynamic object inside the same processor as the one inside which the deleting object has been declared.



Error Number


E029 case statement should have at least two legs

This indicates that a case statement is being defined with one leg.

Case statement is used to specify the differences between different legs of a feature. Thus you need to define at least two legs in the given case statement.

E030 too many case nestings

This indicates that a case statement with more than allowed maximum number of nestings is being defined.

Remove the innermost nesting from the nested case statement and use if-then-else statement to achieve the same effect.

E031 case statement cannot be nested inside if statement

This indicates that a case statement with at least one nesting is being defined inside an if-statement. This is an error.

Use case statement instead of an if-statement to achieve the same effect.

E032 timer starting object not defined

This indicates that the object starting the timer has not been declared in the declaration section.

Declare the timer starting object as eternal or dynamic in the declaration section at the top of the FDL file.

E033 timer starter should be an object.

This indicates that the object starting the timer has not been declared in the declaration section as an eternal or dynamic object. This is an error.

Declare the timer starting object as eternal or dynamic in the declaration section at the top of the FDL file.

E034 timer stopping object not defined.

This indicates that the object stopping the timer has not been declared in the declaration section.

Declare the timer stopping object as eternal or dynamic in the declaration section at the top of the FDL file.

E035 for timer stopping <symbol> should be an object

This indicates that <symbol> trying to stop the timer is not an object.

Declare the timer stopping object as eternal or dynamic in the declaration section at the top of the FDL file.

E036 action defined for undefined object

The object for which an action has been defined in an action statement, is not declared in the object declaration section at the top of FDL file.

Declare the object in the object declaration section at the top of the FDL file.

E037 <symbol> should be an object to take action

The symbol in the action statement is not an object. Actions cannot be defined for modules or processors.

Provide an object in the action statement. Declare the object in the object declaration section at the top of the FDL file.



Error Number


E038 the state changing object not defined

The object in the state change statement has not been declared in the object declaration section at the top of the FDL file.

Provide an object in the state change statement or declare the object in the object declaration section at the top of the FDL file.

E039 for state changing, the <symbol> should be an object or processor

The <symbol> in the state change statement is not an object or a processor. State changes are not allowed for modules.

Provide an object or a processor in the state change statement.

E040 specify the state changing object in <symbol>

The state change is for a processor. Since the given processor has objects inside it, the state change should be an object inside the given processor. State changes can be performed for a processor only if no objects have been defined in the processor.


E041 too many if nestings There are more than the maximum number of possible if nestings.

Remove the inner most if nesting.

E042 if condition should be a case leg

The string specified in the if-condition should be a valid leg string that has been used in a previous case statement.

Copy and paste the exact leg string from a previous case statement.

E043 if condition not found The string specified in the if-condition should be a valid leg string that has been used in a previous case statement.

Copy and paste the exact leg string from a previous case statement. Make sure that the string used in the leg statement and if-condition match exactly.

E044 resource allocating object not defined

The object allocating the resource in the resource allocate statement has not been defined.

Declare the object allocating resource in the object declaration section at the top of the FDL file.

E045 resource allocator should be an object

The symbol allocating the resource in the resource allocate statement should be an object.

Declare the symbol allocating the resource as an object in the object declaration section at the top of the FDL file.



Error Number


E046 resource freeing object not defined

The object freeing the resource in the free resource statement has not been defined.

Declare the object freeing resource in the object declaration section at the top of the FDL file.

E047 for resource freeing, symbol should be an object

The symbol freeing the resource in the free resource statement should be an object.

Declare the symbol freeing the resource as an object in the object declaration section at the top of the FDL file.

E049 too many modules The number of modules defined is greater than the maximum number of possible modules.

Decrease the number of modules.

E050 too many processors The number of processors defined is greater than the maximum number of possible processors.

Decrease the number of processors.

E051 too many objects The number of objects defined is greater than the maximum number of possible objects.

Decrease the number of objects.

E052 invalid type assignment

Same type has been assigned to entities of different class. E.g. a processor and an object have been assigned the same type.

Make sure that the specified type is used only for one of the following classes: modules, processors, eternal objects, dynamic objects.

E053 parse error EventStudio has detected an error in the use of FDL syntax.

Check for a typing mistake in the specified line or the previous line. Check FDL reference for the syntax of the FDL statement used on the specified line/previous line.

E055 unterminated string A string was started with a quote but the ending quote for the string was not specified.

Add an ending quote on the same line as the beginning of the string.

E056 unterminated comment

A comment was started with /* but the ending */ for the comment was not specified

Add */ at the point where the comment ends.



Error Number


E057 unterminated remark A remark was started with (* but the ending *) for the remark was not specified.

Add *) at the point where the remark ends.

E058 unterminated block remark

A block remark was started with [* but the ending *] for the block remark was not specified.

Add *] at the point where the block remark ends.

E059 string is of zero length A string must contain at least one character.

Change the string "" by adding character(s) between the begin and end quotes.

E060 string begins with blank

FDL does not permit strings that contain a blank as the first character.

Remove the blank from the beginning of the string.

E061 string ends with blank FDL does not permit strings that contain a blank as the last character.

Remove the blank from the end of the string.

E062 string contains consecutive blanks

FDL does not permit strings that contain words separated by more than one blank.

Remove the extra blank between the words.

E063 too many leg statements

The total number of leg statements allowed in a case statement has been exceeded.

Reduce the number of leg statements in the case statement by splitting it into multiple case statements.

E064 timer restarting object not defined.

This indicates that the object restarting the timer has not been declared in the declaration section.

Declare the timer restarting object as eternal or dynamic in the declaration section at the top of the FDL file.

E065 for timer restarting <symbol> should be an object

This indicates that the object restarting the timer has not been declared in the declaration section as an eternal or dynamic object. This is an error.

Declare the timer restarting object as eternal or dynamic in the declaration section at the top of the FDL file.

E066 env_l or env_r cannot be the source of a multicast

This indicates that the source of a multicast message is env_l or env_r. This is an error.

Change the source of multicast to a processor or eternal or dynamic object.



Error Number


E067 env_l or env_r cannot receive a multicast

FDL does not permit env_l or env_r to be the destination of a multicast.

Change the destination of multicast to a processor or eternal or dynamic object.

E068 Multicast duplicated to <destination>

The same object or processor has been used more than once as the destination of the multicast.

Make sure that all multicast destinations are unique.

E069 Source and destination processes for invokes statement should be on the same processor

Source and destination processes given the invokes statement are not on the same processor.

Provide source and destination processes on the same processor in the invokes statement.

E070 Source and destination processes for returns statement should be on the same processor

Source and destination processes given the returns statement are not on the same processor.

Provide source and destination processes on the same processor in the returns statement.

E072 <Called_task> or the invoked task can only take actions

A task other than the one invoked is participating in the given statement.

Modify the statement to contain the invoked task.

E073 <Called_task> or the invoked task is right now active; so no timeout processing is allowed

Timeout processing occurs while a task is invoked.

Remove the timeout statement from the invokes returns pair.

E074 <the given task> is not invoked right now

The task in the given statement is not the one that is invoked; so it cannot participate in any statement.

Provide a statement in which the invoked task is participating.

E075 Label inside a case statement is not allowed

Label statement inside a case statement has been given.

Provide a label statement outside a case statement or if statement.

E076 Label inside an if statement is not allowed

Label statement inside an if statement has been given.

Provide a label statement outside a case statement or if statement.

E077 env_l or env_r cannot perform joint action

FDL does not permit env_l or env_r to participate in a joint action.

Change the participants of a joint action to eternal or dynamic object.



Error Number


E078 joint action duplicated on <participant>

The same object has been used more than once in the joint action.

Make sure that all joint action participants are unique.

E079 Undefined style being used

Undefined style being used in message send statement or bidirectional condition statement.

Provide a style definition statement in the declaration section of the FDL file before using it in the given message statement or bidirectional statement.

E080 Invalid attribute type given style statement

Attribute type other than <font>,<fontsize>,<paramfont>, <paramfontsize>, <linewidth>, <color> or <linepattern> has been given in style declaration statement

Only attribute types supported in style should be given in style declaration statement

E081 Invalid color value format given in style statement

Color value format other than “r,g,b” has been given in the style statement where r, g and b are color components in the range 0.0 to 1.0.

Provide color value in proper format: value containing three color components separated by commas and the value of each color component; red, blue or green should be a floating point number between 0.0 and 1.0

E082 Invalid line width given in style statement

<linewidth> given in the style statement is not in the range 0.0 to 20.0.

Provide a <linewidth> value in the range 0.0 to 20.0.

E083 Source and destination cannot be same in a bidirectional condition statement.

Same source and destination tasks have been given in the bidirectional condition statement.

Provide different source and destination tasks in the bidirectional condition statements or use message statement.

E084 Invalid line pattern given in style

<linepattern> value other than "---" or "- -" has been given in the style definition statement.

Provide the value "---" or "- -" for <linepattern> attribute in the style definition statement.

E085 Invalid font or invalid parameter font given in style statement

"Arial", "Arial Narrow", "Courier New", "Times New Roman","Arial-Bold", "Arial Narrow-Bold" , "Courier New-Bold" or "Times New Roman-Bold" are the fonts that are supported in font or paramfont attribute in style definition statement. A value other than these has been given.

Provide a supported value in font and paramfont attributes in style definition statement.



Error Number


E086 Unterminated hyperlink

A hyperlink was started with a ‘<’ but the ending ‘>’ for the hyperlink was not specified.

Add an ending ‘>’ on the same line as the beginning of the hyperlink.



5.2 FDL Runtime Errors Error Number


E500 cannot write to file <file name>

EventStudio could not write to the output file.

Check if the specified file has been opened in Adobe Reader. Close this file and re-generate the document. This problem can also be caused by network drive problems or disk not having enough space to save the file.

E503 module: <module name> does not have any processors

A module has been declared without any processors. A module must contain at least one processor.

Declare processors in the specified module. Use the processor declaration and the specified module should be placed after the in keyword.

E504 message sender: <symbol> not created

The dynamic object sending the message has not been created.

Use the create statement to create the specified dynamic object. Make sure that the object is created before this statement.

E505 message receiver: <symbol> not created

The dynamic object receiving the message has not been created.


E506 creator object: <symbol> itself not created !

The dynamic object creating another object has itself not been created.


E507 cannot create: <symbol> again !

The create statement is attempting to create a dynamic object that has already been created.

Use the delete statement to delete the specified object before creating it again.

E508 deleting object: <symbol> not created!

The dynamic object deleting another object has not been created.


E509 cannot delete non-existent object: <symbol>

The object being deleted is not created.

Check if the create statement has been missed for the object being deleted.



Error Number


E510 timer starting object: <symbol> not created

The dynamic object starting a timer has not been created.


E511 timer stopping object: <symbol> not created

The dynamic object stopping a timer has not been created.


E512 timer: <symbol> not started.

Timer stop or restart is being attempted for a timer that was never started.

Use the timer-start statement to start timer. Make sure timer is started before this statement.

E513 invalid timer: <symbol> being stopped

Timer stop is being attempted for a symbol that is not a timer.

The timer stop symbol has been specified incorrectly. Check the timer start to verify symbol name.

E514 <timer symbol> was not started by <object symbol>

An object is trying to stop or restart a timer started by another object.

Make sure that the object stopping or restarting the timer is the same as the object starting it.

E515 timer: <symbol> not started

Timeout statement has been used for a timer that is not active.

Check if the create-statement for the timer was missed. Another possibility is that timer has been stopped before the timeout statement.

E516 invalid timer: <symbol> timeout

Timeout statement has been used for a symbol that is not a timer.

The timeout symbol has been specified incorrectly. Check the timer start to verify symbol name.

E517 timeout matures for non-existent object: <symbol>

Timeout refers to a timer start was started by a dynamic task that has already been deleted.

Make sure that the object starting the timer is not deleted before the timeout condition.

E518 state changing object: <symbol> not created

State change has been specified for a dynamic object that has not been created.


E519 action taking object: <symbol> not created

Action statement has been specified for a dynamic object that has not been created.




Error Number


E520 action beginning object: <symbol> not created

Action begin statement has been specified for a dynamic object that has not been created.


E521 action ending object: <name> not created

Action end statement has been specified for a dynamic object that has not been created.


E522 no active action found: <name>

Action end statement has been used for an action that was never started.

Check if the action-begin statement has been defined. If it has been defined, compare the action string for begin and end. The strings should match exactly.

E523 invalid action: <name> Action end was specified with an action string that does not correspond to an active action.

Match the action string for the action begin and action end statements.

E524 <name> action was not begun by <object>

Action end is being attempted by an object other than the action initiator.

Make sure that the object ending the action is the same as the object starting it.

E525 resource allocating object: <symbol> not created

Resource allocate statement has been specified for a dynamic object that has not been created.


E526 resource freeing object: <name> not created

Resource free statement has been specified for a dynamic object that has not been created.


E527 no allocates resource found: <name>

Resource free statement has been used for a resource that was never allocated.

Check if the resource-allocate statement has been defined. If it has been defined, compare the resource string for allocation and freeing. The strings should match exactly.

E528 invalid resource: <name>

Resource free was specified with a resource string that does not correspond to an allocated resource.

Match the action string for the action-allocate and action-free statements.



Error Number


E529 <name> resource was not allocated by <object>

Resource free is being attempted by an object other than the resource allocator.

Make sure that the object freeing the resource is the same as the object allocating it.

E540 timer restarting object : <object name> not created

The dynamic object restarting a timer has not been created.


E541 invalid timer: <symbol> being restarted

Timer restart is being attempted for a symbol that is not a timer.

The timer stop symbol has been specified incorrectly. Check the timer start to verify symbol name.



5.3 FDL Warnings Warning Number

Warning Text Example Reason Solution

W001 invalid selection: <symbol>

Summary document has been defined for an entity that is not a module, processor, object or a type.

Check if you mistyped the entity name when defining the document. If so, delete the document and create it again from the document wizard.

W002 selection not found: <symbol>

Summary document has been defined for an entity that does not exist. E.g. summary document was generated for call_handler module but call_handler is not a valid module name.

Check if you mistyped the entity name when defining the document. If so, delete the document and create it again from the document wizard. Note: If you have multiple FDL files in a scenario, you might get this warning because one of the selected files does not define the specified entity. This is normal.

W004 unit test procedures cannot be generated for: <symbol>

Unit test procedures have been defined for an entity that is not an object or valid object type. E.g. a unit test procedure has been requested for a module.

Check if you mistyped the entity name when defining the document. If so, delete the document and create it again from the document wizard. Note: If you have multiple FDL files in a scenario, you might get this warning because one of the selected files does not define the specified entity. This is normal.

W006 dynamic object, <symbol> active at feature end

The specified dynamic object has not been deleted at the end of a feature.

Provide the object delete statement for the given dynamic object before the feature end statement.

W007 <symbol> object did not stop all timers

The specified dynamic object did not stop all the timers, which it started, before its deletion. Or the specified eternal object did not stop all timers before feature end.

For a dynamic object: Provide stop timer statements for all timers before the object delete statement. For an eternal object:



Warning Number

Warning Text Example Reason Solution

Stop all the timers before the feature end.

W008 <symbol> object did not end all actions

The specified dynamic object did not end all the actions, which it started, before its deletion. Or the specified eternal object did not end all actions that it started before the feature end.

For a dynamic object: Provide end action statements for all started actions before the object delete statement. For an eternal object: Provide end action statement before the feature end.

W009 <symbol> object did not release all resources

The specified dynamic object did not release all the resources, which it allocated, before its deletion. Or the specified eternal object did not release all resources before the feature end.

For a dynamic object: Provide resource free statements for all allocated resources before the object delete statement. For an eternal object: Provide resource free statements for all allocated resources before the feature ends.

W021 No suitable printer driver found (installing a print driver will improve EMF output)

The quality of Word Picture (EMF) output improves when a printer can be used as a reference. If EventStudio finds that no printer is installed, it will generate this warning.

Use a machine with at least one printer driver installed.

W900 Issue statement FDL contains an issue statement. All issue statements are reported as warnings.

Issue statements are used to keep track of unresolved design issues. When the issue is resolved, remove the issue statement.



6 Scenario Projects 6.1 Introduction to Scenario Projects As we have seen earlier, FDL allows the user to embed multiple scenarios into a single FDL file. This is achieved with the case statement. A Scenario in a FDL file is a sequence of leg selections of the case statements encountered in the feature flow. A Scenario Project is a collection of Scenarios that have been logically grouped together. These Scenarios may have been defined from multiple FDL files. The Scenario Project also stores the specifications for the documents that need to be generated. Once a Scenario Project has been defined, EventStudio will keep track of changes in the FDL files contained in it. If new case statements are added to the FDL files, EventStudio will prompt the user for leg selections for the affected scenarios. Case and leg deletes will also be handled similarly. This ensures that the Scenarios in the project are always in sync with the FDL files. The contents of a Scenario Project are displayed in a Scenario Bar on the left side of the screen. Scenarios can be added to the Scenario Project by using the Scenario Wizard. Documents can be added by invoking the Document Wizard. Once all the Scenarios and Documents have been defined, use the "Generate All Documents" command to generate the PDF, Word Picture (EMF) and HTML documents. Example The relationship between FDL files, Scenarios, Scenario Projects and Documents can be better understood by considering the following example. The SpacePort Scenario Project contains the following Scenarios:

• Successful Spacecraft Docking and Undocking • Orbit Resource Not Available • Docking Resource Not Available

All these Scenarios have been generated from a single FDL file (SpacePort.fdl). The case outline for this file is: case leg "No Orbit Resource Available": . . . leg "Orbit Resource is Available": . . . case leg "No Docking Port Available": . . . leg "Docking Port is Available": . . . endcase endcase



The actual leg selections for the Scenarios are: Successful Spacecraft Docking and Undocking

• Orbit Resource is Available • Docking Port is Available

Orbit Resource Not Available

• No Orbit Resource Available

Docking Resource Not Available • Orbit Resource is Available • No Docking Ports Available



6.2 Scenario Wizard The Scenario Wizard is used to define Scenarios from FDL Case leg selections. The Scenario Wizard is invoked automatically whenever a new Scenario Project is created. Also, Scenario Wizard gets invoked when a new Scenario is added to an existing Scenario Project. Scenario Wizard guides the user in defining a Scenario. As the first step, the Wizard prompts the user for a Scenario name. Then it takes inputs about the FDL file and legs in a series of steps. When all the case legs have been covered for the feature flow, the Scenario will appear in the Scenario Bar.



6.3 Document Wizard The Document Wizard is invoked whenever the user adds a new document to the Scenario Project. The user is guided through several steps involved in document addition. These steps vary based on the type of document being added. The document Wizard supports the following document types: Document type Formats supported Sequence Diagram

PDF and Word Picture (EMF)

Interface Sequence Diagram


Interaction Sequence Diagram


Message Filter Sequence Diagram PDF and Word Picture (EMF) Unit Test Procedures

HTML

Summary Document

HTML

Statistics Document

HTML

Index Document

HTML

Collaboration Diagram


Interface Collaboration Diagram


Interaction Collaboration Diagram


Message Filter Collaboration Diagram


For more information about the document types and procedure for adding these documents to the Project, see the following sections. Once the documents have been defined, use the "Generate All Documents" or "Generate Document" to generate the documents. The documents will be generated in the same directory as the Scenario Project file. Use the Windows Explorer to view the documents.



6.4 Sequence Diagram Sequence Diagrams are PDF or Microsoft Word Picture (EMF) documents that represent the message sequence flow. Message interactions are represented as arrows between instance axes for processors and objects defined in the feature. The remarks are printed on the right side of the chart.

The following Document Wizard steps are involved in Sequence Diagram addition: 1. Select "Sequence Diagram" from the document type menu displayed by Document Wizard

and click "Next". 2. Document Wizard will then display document generation options. These options allow you to

control the level of detail you want to display in the output document. The options also allow you to select column and remark width and the "Graphics Format" (PDF or Microsoft Word Picture - EMF). Modify the options according to your requirements and click "Next".

3. Document Wizard will now prompt you to enter the document name. A default document name is also provided. Supply the appropriate document name and click "Next".

4. Document Wizard has now completed document addition. Click "Finish" to exit the Wizard.



6.5 Interface Sequ eenc Diagram Interface Sequence Diagrams are PDF or Microsoft Word Picture (EMF) documents that display the interfaces for a specified filter entity. The entity could be any one of the following:

• Module: Only interactions within the specified module and all interactions with other modules will be included in the Interface Sequence Diagram.

• Module Type: Only interactions within the modules with the specified type and all interactions with other modules will be included in the Interface Sequence Diagram.

• Processor: Only interactions within the specified processor and all interactions with other processors will be included in the Interface Sequence Diagram.

• Processor Type: Only interactions within the processors with the specified type and all interactions with other processors will be included in the Interface Sequence Diagram.

• Objects (Eternal and Dynamic): Only interactions of the specified object with other processors/objects will be included in the Interface Sequence Diagram.

• Object Type (Eternal and Dynamic): Only interactions of objects with the specified type with other processors/objects will be included in the Interface Sequence Diagram.

• env_l or env_r: Only interactions involving the specified environment will be included in the Interface Sequence Diagram.

• env: If the entity is specified as env, only interactions involving env_l or env_r will be included in the Interface Sequence Diagram.

Note that the filter names are case sensitive. The names specified here should exactly match the declarations in the FDL files. The following Document Wizard steps are involved in Interface Sequence Diagram addition: 1. Select "Interface Sequence Diagram" from the document type menu displayed by Document

Wizard and click "Next". 2. Document Wizard will prompt you to enter the document interface filter. Enter an interface

filter that meets the filter requirements specified above. 3. Document Wizard will then display document generation options. These options allow you to






6.6 Interaction Sequence Diagram Interaction Sequence Diagrams are PDF or Microsoft Word Picture (EMF) documents that display message interactions at any of the following levels:

• Inter Processor Interactions: Only message interactions between processors will be included in the document. Intra processor message interactions will not be displayed.

o Inter processor interaction sequence diagram is drawn at processor level. o The diagram completely hides the object level detail.

• Inter Module Interactions: Only message interactions between modules will be included in the document. Intra module message interactions will not be displayed.

o Inter module interaction sequence diagram is drawn at module level. o The diagram completely hides the processor and object level detail.

• Environment Interactions: Only message interactions with the environment (env_l and env_r) will be included in the document.

The following Document Wizard steps are involved in Interaction Sequence Diagram addition: 1. Select "Interaction Sequence Diagram" from the document type menu displayed by

Document Wizard and click "Next". 2. Document Wizard will prompt you to select the interaction type. Select the interaction type

based on the above specifications. 3. Document Wizard will then display document generation options. These options allow you to






6.7 Message Filte6.7 Message Filter Sequence Diagram r Sequence Diagram Message Filter Sequence Diagrams are PDF or Microsoft Word Picture (EMF) documents that filter message interactions based on the message name. You can specify a message filter when prompted. All messages that match the filter string will be included in the output. All other message interactions will be excluded.

Message Filter Sequence Diagrams are PDF or Microsoft Word Picture (EMF) documents that filter message interactions based on the message name. You can specify a message filter when prompted. All messages that match the filter string will be included in the output. All other message interactions will be excluded.

6.7.1 Simple Message Filters 6.7.1 Simple Message Filters For example, if the message filter is specified as Resp, the document will include the following message interactions: For example, if the message filter is specified as Resp, the document will include the following message interactions:

• MsgResponse • MsgResponse • ActivationResp • ActivationResp • RespondNow • RespondNow

6.7.2 Regular Expression Message Filters 6.7.2 Regular Expression Message Filters

The above example just demonstrated a very simple message filter. EventStudio supports powerful message filters using regular expressions. A few examples here should introduce you to the power of regular expression based message filters. (For more details, see the appendix on regular expressions)

The above example just demonstrated a very simple message filter. EventStudio supports powerful message filters using regular expressions. A few examples here should introduce you to the power of regular expression based message filters. (For more details, see the appendix on regular expressions) Message Filter Regular Expression Message Filter Regular Expression Meaning Meaning Docking Matches all messages containing "Docking" anywhere in the

message, e.g. ReadyForDocking, DockingCommand ^Docking Matches all messages beginning with "Docking", e.g.

DockingCommand, DockingRejected \cundocking Matches all messages containing "undocking". Case is ignored

in the comparison, e.g. UndockingAllowed, tawait_undocking_finished

Response$ Matches all messages ending with "Response", e.g. OrbitDeallocResponse, EndDockingResponse

{Request}|{Response}$ All message ending with "Request" or "Response" e.g. OrbitRequest, OrbitAllocResponse

^.r Matches all messages with "r" as the second character, e.g. OrbitAllocRequest, ProceedForUndocking

^[DU] Matches messages beginning with D or U. e.g. DockingRequest, UndockingRequest

^[^DU] Matches messages not beginning with D or U. e.g. ReadyForDocking, OrbitRequest

<Act Matches message containing words beginning with Act. e.g. ActivateSession, "Demand Action"

ion> Matches messages containing words ending with ion. e.g. "Demand Action", "Spread ion message"

^.[0-9] Matches messages that have a digit in the second character. e.g. M1Request, "Q2 Report"

\s Matches message that contain white spaces. e.g. "Demand Action", "Invoke Call Request"

^{Setup}|{Release}_([a-z]#)_([0-9]#)$ Matches messages that begin with "Setup" or "Release" and contains lower case word followed by a number. e.g. Setup_call_53, Release_message_23, Setup_request_1

^{Error}(_0x[0-9A-F]#)#$ Matches messages starting with Error and followed by hex numbers. e.g. Error_0xAA_0x01_0x555, Error_0xAB



The following Document Wizard steps are involved in Message Filter Sequence Diagram addition: 1. Select "Message Filter Sequence Diagram" from the document type menu displayed by

Document Wizard and click "Next". 2. Document Wizard will prompt you to enter the message filter. Enter the message filter based

on the above specifications. If you are entering a regular expression check the regular expression box displayed on the page.

3. Document Wizard will then display document generation options. These options allow you to control the level of detail you want to display in the output document. The options also allow you to select column and remark width and the "Graphics Format" (PDF or Microsoft Word Picture – EMF). Modify the options according to your requirements and click "Next".





6.8 Unit Test Procedures Unit Test Procedures are HTML documents that derive the test procedures from the FDL definition. Unit Test Procedures are organized as a series of steps that should be executed to test out a particular object. This document could also be used as a checklist for code reviews.

The Unit Test Procedures are organized as a table with the following columns:

• Num: This column contains the serial number for the test • Action: This column defines that action to be taken by the unit tester. • Result: This column describes the expected result of the action specified in the previous

column. • Status: The status of the test (PASS/FAIL) should be specified here. The Unit Testing

status should be marked next to "UT:" The Code Review status should be marked next to "CR:"

Unit Test Procedures can be generated for the following entities:

• Eternal Object • Dynamic Object • Eternal Object Type • Dynamic Object Type

If an object type is selected, the Unit Test Procedures will include tests for all the objects that have the specified type. The following Document Wizard steps are involved in Unit Test Procedure definition: 1. Select "Unit Test Procedures" from the document type menu displayed by Document Wizard

and click "Next". 2. Document Wizard will prompt you to enter the object for which the Unit Test Procedures have

to be generated. Enter the object name or object type as specified above. 3. Document Wizard will now prompt you to enter the document name. A default document

name is also provided. Supply the appropriate document name and click "Next". 4. Document Wizard has now completed document addition. Click "Finish" to exit the Wizard. Note: Since the document is in HTML format, it can be easily edited in Microsoft Word or other word processors supporting HTML. The document can then be saved in the word processors native format using the "Save As" command.



6.9 Summary Document Summary documents present a component wise summary in HTML format. The summary document includes a point wise summary of the actions taken by all the specified objects and processors. By selecting the "Summary for All" option, a summary document can be

generated for all the objects and processors in the feature. Select the "Summary for" option if you wish to restrict the entities for which the summary should be generated. When the "Summary for" option is selected, Document Wizard will prompt you to enter the name of the entity. Specify the entity name as follows:

• Module Type • Module • Processor Type • Processor • Eternal Object Type • Eternal Object • Dynamic Object Type • Dynamic Object

The following Document Wizard steps are involved in Summary Document addition: 1. Select "Summary Document" from the document type menu displayed by Document Wizard

and click "Next". 2. Document Wizard will prompt you to choose between "Summary for All" and "Summary for".

If the "Summary for" option is selected, enter the entity name as specified above. 3. Document Wizard will now prompt you to enter the document name. A default document




6.10 Statistics Document Statistics document generates message interaction statistics in HTML format. The statistics are generated as a table, specifying source to destination message interactions. The source nodes are specified as rows and the destination nodes are shown as columns. The statistics tables are generated at three levels:

• Inter Module Message Interactions • Inter Processor Message Interactions • Inter Object Message Interactions

Message Statistics documents can be very useful in getting a preliminary idea of system performance by just looking at the statistics. The statistics document will give a quick idea of message communication, thus helping the system designers keep a tab on excessive message interactions that can lower system performance. Another benefit of statistics documents is that managers can get a quick idea of what modules, processors and objects are involved in certain feature. This could help them plan resource allocations in accordance with the features. Also, this document can also give a quick idea on which groups need to work more closely. This can be achieved by just looking at the relative number of interactions between two modules. The following Document Wizard steps are involved in Statistics Document addition: 1. Select "Statistics Document" from the document type menu displayed by Document Wizard

and click "Next". 2. Document Wizard will now prompt you to enter the document name. A default document




6.11 Collaboration Diagram Collaboration Diagrams are PDF or Microsoft Word Picture (EMF) documents that represent a message sequence flow with less emphasis on the time dimension. Message interactions are displayed as curved arrows between entities. The display here is more 2-dimensional and tdocument is useful for obtaining a bird’s eye view of the whole featu

his re.

e following Document Wizard steps are involved in Collaboration Diagram addition: ent Wizard

2. will then display document generation options. These options allow you to

3. ent

4. e Wizard.

.11.1 Context Diagram

ou can choose between Collaboration Diagrams and Context Diagrams from the "Document

ith collaboration diagrams, individual instances of messages are re

ontext diagrams focus on types of interactions. Individual instances of

only a

not show the time seque

Th1. Select "Collaboration Diagram" from the document type menu displayed by Docum

and click "Next". Document Wizardcontrol the level of detail you want to display in the output document. The options also allow you to select column and remark width and the "Graphics Format" (PDF or Microsoft Word Picture – EMF). Modify the options according to your requirements and click "Next". Document Wizard will now prompt you to enter the document name. A default documname is also provided. Supply the appropriate document name and click "Next". Document Wizard has now completed document addition. Click "Finish" to exit th

6 YGeneration Options" menu.

Wshown and messages are numbered by the time sequence. The figuon the left side shows a collaboration diagram for digit handling. Here individual digit and ack messages are shown with a sequence number giving an indication of the time sequence of messages.

Cmessages are not shown. Duplicate message interactions are not shown. The figure on the left side depicts a context-diagram that corresponds to the same digit handling flow covered above. Here single digit and ack message have been shown. Also, the diagram does nce of interactions.



6.12 Interface Collaboration Diagram Interface Collaboration Diagrams are PDF or Microsoft Word Picture (EMF) documents that display the interfaces for a specified filter entity. The entity could be any one of the following:

• Module: Only interactions within the specified module and all interactions with other modules will be included in the Interface Collaboration Diagram.

• Module Type: Only interactions within the modules with the specified type and all interactions with other modules will be included in the Interface Collaboration Diagram.

• Processor: Only interactions within the specified processor and all interactions with other processors will be included in the Interface Collaboration Diagram.

• Processor Type: Only interactions within the processors with the specified type and all interactions with other processors will be included in the Interface Collaboration Diagram.

• Objects (Eternal and Dynamic): Only interactions of the specified object with other processors/objects will be included in the Interface Collaboration Diagram.

• Object Type (Eternal and Dynamic): Only interactions of objects with the specified type with other processors/objects will be included in the Interface Collaboration Diagram.

• env_l or env_r: Only interactions involving the specified environment will be included in the Interface Collaboration Diagram.

• env: If the entity is specified as env, only interactions involving env_l or env_r will be included in the Interface Collaboration Diagram.

Note that the filter names are case sensitive. The names specified here should exactly match the declarations in the FDL files. The following Document Wizard steps are involved in Interface Collaboration Diagram addition: 1. Select "Interface Collaboration Diagram" from the document type menu displayed by

Document Wizard and click "Next". 2. Document Wizard will prompt you to enter the document interface filter. Enter an interface

filter that meets the filter requirements specified above. 3. Document Wizard will then display document generation options. These options allow you to

control the level of detail you want to display in the output document. The options also allow you to select column and remark width and the "Graphics Format" (PDF or Microsoft Word Picture – EMF). Modify the options according to your requirements and click "Next".


6.12.1 Interface Context Diagram

Interface Context Diagram can be generated by first selecting Interface Collaboration Diagram and then changing the diagram type to Context Diagram.



6.13 Interaction Collaboration Diagram Interaction Collaboration Diagrams are PDF or Microsoft Word Picture (EMF) documents that display message interactions at any of the following levels:

• Inter Processor Interactions: Only message interactions between processors will be

included in the document. Intra processor message interactions will not be displayed. • Inter Module Interactions: Only message interactions between modules will be included

in the document. Intra module message interactions will not be displayed. • Environment Interactions: Only message interactions with the environment (env_l and

env_r) will be included in the document.

The following Document Wizard steps are involved in Interaction Sequence Diagram addition: 1. Select "Interaction Collaboration Diagram" from the document type menu displayed by

Document Wizard and click "Next". 2. Document Wizard will prompt you to select the interaction type. Select the interaction type

based on the above specifications. 3. Document Wizard will then display document generation options. These options allow you to

control the level of detail you want to display in the output document. The options also allow you to select column and remark width and the "Graphics Format" (PDF or Microsoft Word Picture – EMF). Modify the options according to your requirements and click "Next".



6.13.1 Interaction Context Diagram

Interaction Context Diagram can be generated by first selecting Interaction Collaboration Diagram and then changing the diagram type to Context Diagram.



6.14 Message Filte6.14 Message Filter Collaboration Diagram r Collaboration Diagram Message Filter Collaboration Diagrams are PDF or Microsoft Word Picture (EMF) documents that filter message interactions based on the message name. You can specify a message filter when prompted. All messages that match the filter string will be included in the output. All other message interactions will be excluded.

Message Filter Collaboration Diagrams are PDF or Microsoft Word Picture (EMF) documents that filter message interactions based on the message name. You can specify a message filter when prompted. All messages that match the filter string will be included in the output. All other message interactions will be excluded.

6.14.1 Simple Message Filters 6.14.1 Simple Message Filters For example, if the message filter is specified as Resp, the document will include the following message interactions: For example, if the message filter is specified as Resp, the document will include the following message interactions:

• MsgResponse • MsgResponse • ActivationResp • ActivationResp • RespondNow • RespondNow

6.14.2 Regular Expression Message Filters 6.14.2 Regular Expression Message Filters



Message Filter Regular Expression Message Filter Regular Expression Meaning Meaning Docking Matches all messages containing "Docking" anywhere in the

















The following Document Wizard steps are involved in Message Filter Collaboration Diagram addition: 1. Select "Message Filter Collaboration Diagram" from the document type menu displayed by

Document Wizard and click "Next". 2. Document Wizard will prompt you to enter the message filter. Enter the message filter based

on the above specifications. If you are entering a regular expression check the regular expression box displayed on the page.

3. Document Wizard will then display document generation options. These options allow you to control the level of detail you want to display in the output document. The options also allow you to select column and remark width and the "Graphics Format" (PDF or Microsoft Word Picture – EMF). Modify the options according to your requirements and click "Next".


5. Document Wizard has now completed document addition. Click "Finish" to exit the Wizard. 6.14.3 Message Filter Context Diagram

Message Filter Context Diagram can be generated by first selecting Message Filter Collaboration Diagram and then changing the diagram type to Context Diagram.



6.15 Index Document Index Document is a document containing hyperlinks to all the documents generated from a given Scenario Project. This document is automatically generated whenever the user issues the "Generate All Documents" command. The document name is derived from the name of the Scenario Project. For example, the index document for Scenario Project ABC would be "Index for ABC.htm". This document can be very useful in keeping track of all the documents generated for a Scenario Project. The document also helps in maintaining an intranet website for all documents for a project. You can open this document by clicking on the Document Index icon. The document will be opened in the default web browser. Note: This document does not need to be defined through the Scenario Project. The document will be generated automatically. Note: Since the document is in HTML format, it can be easily edited in Microsoft Word or other word processors supporting HTML. The document can then be saved in the word processors native format using the "Save As" command.



6.16 Scenario Bar The Scenario Bar is docked on the left side of the screen. It contains all the information about the currently active Scenario Project. The Scenario Bar allows the user to make changes to all aspects of a Scenario Project. The Scenario Bar can be divided into three sections. Each section is represented by a tree node. These sections are:

• Scenario List • FDL Files • Documents

Scenario List This is the first section in the Scenario Bar tree. The section lists out all the Scenarios that have been defined in the Scenario Project. Clicking on the plus sign next to a Scenario will expand its contents. The Scenario tree node contains the following sub-nodes:

• Name of FDL file that forms the basis of this Scenario. Double clicking on the FDL file icon will open the FDL file and take you to the top of the FDL file.

• Leg selections that define the Scenario. There will be several leg selection sub-nodes. Double clicking on a leg selection icon will open the FDL file and take you directly to the corresponding leg statement.

This section gets updated when new Scenarios are added or deleted. The Scenarios in the section are automatically updated when a change in the FDL case statements affects the Scenario. FDL Files This is the second section in the Scenario Bar tree. The section lists out all the FDL files that have been used in Scenario Project definition. Clicking on the plus sign next to a FDL icon will expand its contents. The FDL tree node contains the following sub-nodes:

• FDL Top Reference. Double clicking on the FDL Top icon will open the FDL file and take you to the top of the FDL file.

• FDL Case Tree. The complete FDL case tree is represented here. This gives a bird’s eye view of the case-leg structure of the FDL file. The FDL leg icons are grouped according to case statements. Nested cases can be accessed by clicking on the plus sign next to a leg selection icon. Double clicking on a leg selection icon will open the FDL file and take you directly to the corresponding leg statement.

Updates to this section are completely automatic. EventStudio will always list the FDL files that are currently being used in Scenario definitions. The FDL Case Tree also gets updated automatically when case or leg statements are added or deleted. Documents This is the third section in the Scenario Bar tree. This section lists out all the documents that have been defined for this Scenario Project. The section is automatically updated when documents are added or deleted. Double clicking on the document icons will open the documents.

• Adobe Acrobat will be invoked for PDF documents. • The default web browser will be invoked for HTML documents. • Windows Explorer will be invoked for Word Picture (EMF) documents.



7 How To … 7.1 How to Create a FDL File

1. Click on the "New" Icon (Ctrl+N) 2. EventStudio displays the New dialog box with two options:

• FDL File • Scenario Project

3. Select the FDL File option and click OK. 4. EventStudio will open an editor window. 5. Start entering the FDL file’s contents. 6. When it is time to save, click the "Save" Icon (Ctrl+S) 7. EventStudio displays the "Save As" dialog box. 8. Select the appropriate directory and enter the desired file name and click the "Save"

button. 9. A new FDL file has been created and saved.



7.2 How to Create a Scenario Project

1. Click on the "New" Icon (Ctrl+N). 2. EventStudio displays the New dialog box with two options:

• Scenario Project from Template • Scenario Project • FDL File

3. Select the "Scenario Project from Template" option and click OK. 4. EventStudio will display a dialog with multiple template specifications. 5. Select a suitable template and click Next. 6. EventStudio will select default FDL file names and Project location. 7. Modify the FDL file names and project location as desired. 8. Click "Finish". 9. EventStudio will create the scenario project and automatically generate the initial version

of the documents.



7.3 How to Add a Scenario

Open the Scenario Project 1. Click the "Open" icon (Ctrl+O). 2. EventStudio will display Open dialog box. Choose the file type as Scenario Projects. 3. Choose the desired Scenario Project from the list of Scenario Projects and click "Open"

button. 4. EventStudio will display the contents of the Scenario Project in the Scenario Bar. Add a Scenario 5. Click on "Add Scenario" button (Ctrl+R). 6. EventStudio will open Scenario Wizard: Scenario Name dialog box. 7. Enter the desired name for the Scenario and click the "Next" button. 8. EventStudio will display Scenario Wizard: Select FDL dialog box and will prompt you to

select the FDL file from which the Scenario will be defined. 9. Click the "Browse" button. EventStudio will display Open dialog box. 10. Select the appropriate directory and then the FDL file to be used. Then, click the "Open"

button. 11. EventStudio will display the Scenario Wizard: Select FDL dialog box. Click on "Next"

button. 12. EventStudio will review the FDL file that was selected. If there are no errors, it will display

all the legs of the first case statement found in the FDL file. 13. Choose the leg to be taken for the Scenario and click "Next" button. 14. The sequence of points 12 and 13 is repeated for all the case statements in the FDL file. 15. After the leg has been chosen from the last case statement, EventStudio will display

"Finish" button instead of "Next". To allow adding more Scenarios to the Scenario Project, it also displays the "Add More Scenarios" button. For each Scenario to be added, follow the sequence from point 6 to point 15.

16. Select the "Finish" button. 17. A Scenario using the FDL file has been added to the Scenario Project.



7.4 How to Delete a Scenario Open the Scenario Project 1. Click the "Open" icon (Ctrl+O). 2. EventStudio will display Open dialog box. Choose the file type as Scenario Projects. 3. Choose the desired Scenario Project from the list of Scenario Projects and click "Open"

button. 4. EventStudio will display the contents of the Scenario Project in the Scenario Bar. Delete a Scenario 5. Normally, "Delete Scenario" icon is disabled. Select the Scenario to be deleted. Then

EventStudio will enable "Delete Scenario" button. 6. Click the "Delete Scenario" icon. EventStudio will inform that the selected Scenario will

be deleted permanently. 7. Click the OK button. The selected Scenario and its associated FDL file have been

deleted. The contents of the Scenario Project in the Scenario Bar are modified to display this.



7.5 How to Add a Document Open the Scenario Project 1. Click the "Open" icon (Ctrl+O). 2. EventStudio will display Open dialog box. Choose the file type as Scenario Projects. 3. Choose the desired Scenario Project from the list of Scenario Projects and click "Open"

button. 4. EventStudio will display the contents of the Scenario Project in the Scenario Bar. Add a Document 5. Click the "Add Document" icon (Ctrl+D). 6. EventStudio will display Document Wizard: Document Type. 7. Select the type of Document to be generated from the displayed list of Document types.

Then click "Next" button. 8. EventStudio will display Document Wizard: Select Generation Options dialog box. 9. Select the desired options from the displayed list of options. Also select the "Graphics

Format" of the document as "Adobe PDF" or "Word Picture EMF". Then, click the "Next" button.

10. EventStudio will display Document Wizard: Document Name dialog box. 11. Enter the desired name of the Document. Then click "Next" button. 12. At this point, EventStudio may prompt you for additional information about the document

that needs to be generated. 13. EventStudio will display Document Wizard: Adding Document dialog box. To allow adding

more Documents to the Scenario Project, it displays "Add More Documents" button. For each Document to be added, follow the sequence from point 6 to point 13.

14. Click the "Finish" button. The Document that was input has been added to the selected Scenario Project.



7.6 How to Delete a Document


button. 4. EventStudio will display the contents of the Scenario Project in the Scenario Bar. Delete a Document 5. Select the Document to be deleted. EventStudio will enable the "Remove Document"

icon. 6. Click the "Remove Document" icon. EventStudio will display a dialog box to confirm the

delete. 7. Click OK to proceed with the deletion.



7.7 How to Modify Document Options


button. 4. EventStudio will display the contents of the Scenario Project in the Scenario Bar. Modify Document Options 5. Normally, Document Options icon is disabled. Select the Document to be modified. Then,

EventStudio will enable the Document Options icon. 6. Click the Document Options icon. EventStudio will display a dialog box with options to

change the document. 7. Change the relevant options and Click the OK button. 8. Document Options have been changed. Use Generate Documents command to

regenerate the documents.



7.8 How to Generate and View Documents Open the Scenario Project 1. Click the "Open" icon (Ctrl+O). 2. EventStudio will display Open dialog box. Choose the file type as Scenario Projects. 3. Choose the desired Scenario Project from the list of Scenario Projects and click "Open"

button. 4. EventStudio will display the contents of the Scenario Project in the Scenario Bar. Generating and Viewing Documents 5. Click the "Generate All Documents" icon (Ctrl+G). 6. EventStudio will display an hourglass when the Document generation is in progress. 7. When all the defined Documents for the Scenario Project have been generated,

EventStudio will inform the user. Click the OK button. 8. Double click on the Document icons in the Scenario Bar. 9. EventStudio will invoke Adobe Acrobat (PDF documents), the Web Browser (HTML

documents) or Windows Explorer (Word Picture - EMF documents) to display the documents.

Note: The Documents are generated in the same directory as the Scenario Project. The Documents are in PDF or HTML format. In addition to these Documents, an HTML Index Document is also generated in the same directory. Documents can be viewed without invoking EventStudio: • To view a Document, double click on its icon in the Windows Explorer. • Alternatively, open the Document Index by clicking on the "Document Index" icon.



7.9 How to Rename a Scenario or a Document Open the Scenario Project 1. Click the "Open" icon (Ctrl+O). 2. EventStudio will display Open dialog box. Choose the file type as Scenario Projects. 3. Choose the desired Scenario Project from the list of Scenario Projects and click "Open"

button. 4. EventStudio will display the contents of the Scenario Project in the Scenario Bar. Rename a Scenario 5. Select the title of the Scenario (icon: ) to be renamed. 6. Right click the selected icon and then select "Rename Scenario" on the context menu.2 7. The title will appear in a small edit box. Modify the title as desired. 8. Then, click somewhere outside the edit box. 9. The Scenario has been renamed and will be displayed in the Scenario Bar. Rename a Document 10. Select the title of the Document (icon: , or ) to be renamed. 11. Right click the selected icon and then select "Rename Document" on the context menu.3 12. The title will appear in a small edit box. Modify the title as desired. 13. Then, click somewhere outside the edit box. 14. The Document has been renamed and will be displayed in the Scenario Bar.

2 This can also be accomplished by clicking on the Scenario icon and then waiting for a few seconds. 3 This can also be accomplished by clicking on the Document icon and then waiting for a few seconds.



7.10 How to Reorder the Scenarios Open the Scenario Project 1. Click the "Open" icon (Ctrl+O). 2. EventStudio will display Open dialog box. Choose the file type as Scenario Projects. 3. Choose the desired Scenario Project from the list of Scenario Projects and click "Open"

button. 4. EventStudio will display the contents of the Scenario Project in the Scenario Bar.

Reorder the Scenarios 5. EventStudio supports the reordering of Scenarios by drag-and-drop operation. 6. Select the Scenario to be moved. Then, move the mouse with the left button pressed to

the new location. 7. EventStudio will display the Scenario being dragged. 8. Release the left mouse button at the desired location. 9. As a rule of thumb, EventStudio will place the dragged Scenario just below the drop

point. Thus, to move the dragged Scenario to the first position, just drop it at the Scenario Project name.

Note that the actual drag and drop operation of a Scenario is much more intuitive than it might appear from the above description!



7.11 How to Open FDL Files from the Scenario Bar Open the Scenario Project 1. Click the "Open" icon (Ctrl+O). 2. EventStudio will display Open dialog box. Choose the file type as Scenario Projects. 3. Choose the desired Scenario Project from the list of Scenario Projects and click "Open"


Open FDL Files 5. EventStudio allows opening a FDL file by double clicking on Scenario legs from the

Scenario. This involves the following steps. a. Click on the plus sign on the left of the Scenario icon. b. EventStudio will display the legs of the Scenario. It will also display a Top icon. c. Clicking on the Top icon will open the FDL file corresponding to this Scenario and

will move the cursor to its beginning. d. Clicking on any of the leg icons will open the FDL file corresponding to this

Scenario and will move the cursor directly to that leg. 6. EventStudio also allows opening a FDL file by double clicking on legs from the FDL file.

This involves the following steps. a. Click on the plus sign on the left of the FDL icon. b. EventStudio will display the tree of the case legs in the FDL file. It will also

display a Top icon. c. Clicking on the Top icon will open the FDL file and will move the cursor to its

beginning. d. Clicking on any of the leg icons will open the FDL file and will move the cursor

directly to that leg.



7.12 How to Update Scenarios with FDL Case Changes



Update FDL Case Changes 5. Edit the FDL file as desired. The user may freely add or delete Case statements and/or

Case legs. 6. When the user saves the FDL file, Scenario Bar is appropriately modified to display the

Case changes. For the Scenarios getting modified, EventStudio senses the Case changes and asks minimum number of Case leg selection queries.



7.13 How to Use Longer Module, Processor and Object Names Names longer than the column width need to be broken down at word boundaries to fit into the available space. Thus long names should be broken at word boundaries. This can be accomplished in three ways:

• Use underscores (_) to separate different parts of a long name. e.g.:

module : air_traffic_control, aircraft processor : mpx_radar in air_traffic_control processor : control_panel in aircraft eternal: radar_controller in mpx_radar

• Use Hungarian Notation to separate different parts of a long name. e.g:

module : AirTrafficControl, Aircraft processor : MpxRadar in AirTrafficControl processor : ControlPanel in Aircraft eternal: RadarController in MpxRadar

• Use blanks in string based names to separate different parts of a long name. e.g:

module : "Air Traffic Control", "Aircraft" processor : "Mpx Radar" in "Air Traffic Control" processor : "Control Panel" in "Aircraft" eternal: "Radar Controller" in "Mpx Radar"

If the column is not wide enough, EventStudio will automatically break the name into multiple lines. The names will be broken at underscore, blank or Hungarian Notation word boundaries. For example, the module column in the underscore case would be represented as:

air

traffic control

aircraft

When using Hungarian Notation, it will be represented as:

Air Traffic Control

Aircraft

Notes

• In PDF and Word Picture documents, underscores will always be replaced with blanks • If the individual word segments in a word are too long, EventStudio will have to clip the word

segment to fit it in the allocated space.



7.14 How to Change Paper Size for PDF documents 1. Click on the Options item from the Tools menu 2. EventStudio displays the options dialog box. 3. Select the Page Layout tab. 4. Select the desired paper size and click OK (You may also define a custom paper size). 5. Now click on the Generate All Documents icon. 6. Now double click on the document icon in the left pane. 7. EventStudio launches Adobe Acrobat Reader. 8. Adobe Acrobat loads the PDF document. 9. Click on the Page Setup item from the Adobe Acrobat Reader File menu. 10. Adobe Acrobat Reader displays the Print Setup dialog box. 11. Select the Paper Size (Make sure that the size selected here matches the Paper Size that

has been selected in EventStudio). 12. Click OK on the dialog box and initiate print using the Print menu item. Note: Paper size can also be changed for Word Picture (EMF) document.



7.15 How to Move a Scenario Project to a Different Directory

Copy the Scenario Project and all the associated FDL files to the desired directory(s) so that the relative path of the Scenario Project and the FDL files does not change. Consider the example where the original paths of the files are:

• C:\Doc\MyScenarioProject.scn • C:\Doc\Call\MyFDL1.fdl • C:\Doc\Call\Setup\MyFDL2.fdl • C:\Doc\Maint\MyFDL3.fdl

These files can be moved to a completely different path as long as the relative paths don't change. The following is a valid destination for these files:

• F:\Destin\New\MyScenarioProject.scn • F:\Destin\New\Call\MyFDL1.fdl • F:\Destin\New\Call\Setup\MyFDL2.fdl • F:\Destin\New\Maint\MyFDL3.fdl



7.16 How to Generate Documents from the Command-Line

1. Invoke the "Start->Run" command. Type "cmd" in the text box and click "OK" to invoke the command-line shell.

2. Add EventStudio into the default search path. See the help for your version of Windows for the exact command. On Windows NT/2000/XP, the following command sets the PATH for EventStudio:

PATH = %PATH%;" C:\Program Files\EventHelix.com\EventStudio System Designer 4.0" 3. Once the path has been set you can issue the following command to Generate All

documents for a Scenario: start/wait evstudio ScenarioName.scn /GenerateAll 4. Verify that all the documents have been generated. 5. You can add the command-line into a batch file to generate documents for multiple

scenarios. For example: start/wait evstudio Examples/XenonProject.scn /GenerateAll start/wait evstudio Examples/SpacePortProject.scn /GenerateAll start/wait evstudio Examples/WebTaxiProject.scn /GenerateAll Note: The command-line mode can be invoked without the "start/wait" command. For example: evstudio Examples/XenonProject.scn /GenerateAll The only problem with this approach is that the command-line shell does not wait for the document generation to finish before returning to execute the next command. Needless to say, this approach is not suitable for scripting.



7.17 How to Export a Document to Microsoft Word

First, generate the document to be exported by following the steps given in the following sections. • How to Add a Document. Be sure to select "Graphics Format" of the document as "Word

Picture EMF". • How to Generate and View Documents. (Note that EventStudio has generated a separate

EMF file for every page in the document. You can export the generated Word Picture (EMF) files to Word in two different ways:

• Insert pictures. Here the EMF files are inserted into the document and there is no dependency on external files. The advantage of this approach is that the document is completely contained in a single Word document.

• Link to pictures. A link to the EMF files is inserted. Microsoft Word loads the EMF files when the document is opened. The advantage of this approach is that the Word document is always "in sync" with the generated EMF files. You just need to link the Word Picture files once, any changes to these files will be automatically reflected in the Word document.

Both the schemes are described below. 7.17.1 Insert Pictures

1. Open the Microsoft Word document in Microsoft Word into which you want to insert the "Word

Picture EMF" files. 2. Position the cursor in the document where you want to insert the "Word Picture EMF" files. 3. If the images to be inserted are in landscape format, change the page to "Landscape" from

the "File->Page Setup" menu in Microsoft Word. 4. Select "Insert" from the toolbar. Click on "Picture" followed by "From File" 5. A file dialog box will appear. 6. Set the path to the directory where the EMF files have been generated. (See the notes

below). 7. Select all the files in the directory and click the "Insert" button. 8. Microsoft Word will now automatically insert all the pictures in the correct sequence, creating

a new page for every picture. 7.17.2 Link to Pictures 1. Make sure that you locate the Scenario Project in the same directory as the Word document

that will contain the EMF files generated by EventStudio (This will ensure that the generated EMF files are at a relative path to the Word document).

2. Open the Microsoft Word document in Microsoft Word into which you want to insert the "Word Picture EMF" files.

3. Position the cursor in the document where you want to insert the "Word Picture EMF" files. 4. If the images to be inserted are in landscape format, change the page to "Landscape" from

the "File->Page Setup" menu in Microsoft Word. 5. Select "Insert" from the toolbar. Click on "Picture" followed by "From File" 6. A file dialog box will appear. 7. Set the path to the directory where the EMF files have been generated. (See the notes

below). 8. Select all the files in the directory. 9. Click on the little downward arrow on the right side to the "Insert" button to select "Link to file". 10. Microsoft Word will now automatically link all the pictures in the correct sequence, creating a

new page for every picture. • Changes made to the EMF files will be automatically reflected in the Word document.



• When sending the document via e-mail simply zip the contents of the entire directory. This way the EMF files and the Word document will be available to the recipients.

Notes: • The document in "Word Picture EMF" graphics format is generated as a directory of the

name same as that of the document in the path where the scenario project is present. • The document is actually created as a set of files in this directory. Each page of the

document is represented by a file. The files are named as four digit number starting from 0001 with "0001 <Scenario Name>.emf" representing the first file.

Example Consider a Scenario Project "C:\MyDoc\ScenerioProject.scn" with "Docking" and "Undocking" scenarios. The document "Spaceport Collaboration Diagram Word" is generated in the directory "C:\MyDoc\Spaceport Collaboration Diagram Word\" where the files are sequentially defined as 0001_Docking.emf, 0002_Docking.emf, 0003_Undocking.emf and so on.



7.18 How to Specify Fonts in a Document EventStudio supports three different ways of specifying a font:

• Specify the font in a style • Specify the font in a theme • Specify the font as an option

7.18.1 Specify the Font in a Style

1. Define a style with the font, fontsize, paramfont and paramfontsize attributes. 2. Use the style prefix with the statements where the font change is desired. 3. Use the style prefix with the object definition to specify the font for an instance axis

(applicable to light weight headers only.)

7.18.2 Specify the Font as an Option

1. Click on "Tools" from toolbar followed by "Options". 2. "Options Page" dialog box will appear. Select "Font Selection" tab. The dialog box allows

you to define font-type and font-size for the following regions of the document: • Heading and Title font • Sequence Diagram Message Name font • Collaboration Diagram message name Font • Message Parameter Font • Action Box Font • Remark Font • Block Remark Font

Choose one of the following fonts:

• Arial • Arial Narrow • Courier • Times Roman

Font sizes 1 to 35 are available for all fonts.

After selecting the fonts, click the OK button. 1. Now click on the Generate All Documents icon. 2. Now double click on the document icon in the left pane.

7.18.3 Specify the Font in a Theme

1. Change the font options as specified in previous section (7.18.2). 2. Invoke the "Tools->Copy Options as Theme" menu. EventStudio will copy a theme

declaration with the updated fonts on to the clipboard. 3. Issue a Paste (Ctrl+V) command the paste the theme statement into an FDL file. 4. Use the theme in an issue statement.

8



Appendix: Regular Expressions 8.1 Regular Expression Examples Message Filter Regular Expression Meaning Docking Matches all messages containing "Docking" anywhere in the

















8.2 Regular Expression Rules ^ Match the beginning of line $ Match the end of line . Match any character [ ] Match characters in set [^ ] Match characters not in set ? Match previous pattern 0 or 1 times (greedy) | Match previous or next pattern @ Match previous pattern 0 or more times (non-greedy) # Match previous pattern 1 or more times (non-greedy) * Match previous pattern 0 or more times (greedy) + Match previous pattern 1 or more times (greedy) { } Group characters to form one pattern ( ) Group and remember \ Quote next character (only of not a-z) < Match beginning of a word > Match end of a word \x## Match character with ASCII code ## (hex) \N### Match ASCII code ### (dec) \o### Match ASCII code \a Match \a \r Match 0x13 (cr) \b Match \b \t Match 0x09 (tab) \f Match \f \v Match \v \n Match 0x10 (lf) \e Match escape (^E) \s Match whitespace (cr/lf/tab/space) \S Match nonwhitespace (!\S) \w Match word character \W Match non-word character \d Match digit character \D Match non-digit character \U Match uppercase \L Match lowercase \C Match case sensitively from here on \c Match case ignore from here on


Generate Sequence Diagrams from Text Input

Documents

Transcript of Generate Sequence Diagrams from Text Input