Table of Contents 
Previous Chapter 2 Introduction to SDT
This chapter contains a brief introduction to the SDT tool and its functionality.
After reading this chapter, you may want to familiarize yourself with SDT: starting the SDT tools, proceeding with a small example, and reading about what is new in SDT in comparison to earlier versions.
SDT is developed and marketed by Telelogic. Our company has been a firm supporter of SDL for a long time, and cooperates with ITU in the ongoing work of improving the language and with ETSI in defining international standards in the field of communication protocols.
We initiate and participate in international research programs on how to use the language in different application areas (such as the European Community programs RACE, ESPRIT and EUREKA, as well as the Swedish national IT program).
Our experience and know-how in these areas is put to practice when we develop software engineering tools that support the languages.
A tool for a specification language must be able to create, maintain, and verify a specification with respect to the language syntax and semantics. It is also fundamental that the tool can simulate, validate and generate application code to other high level languages.
The tool should be able to export and import information from other SDL tools. Major documentation standards or de-facto standards should be supported.
The tool should provide an intuitive, consistent, object-oriented graphical user interface which reduces learning time and makes it easy to work with the tool. Besides the graphical user interface, a batch facility should allow to process a large amount of information without user interaction.
A powerful, context-sensitive Help facility should be provided, freeing the user from time-consuming browsing through user documentation in search for the topic of interest.
SDT can do all of this, and much more.
Figure\x11 6 : Overview of SDT.Figure legend: Click on a symbol for more
information.
-----
(fig)
-----
SDT consists of a number of separate tools that process the information. The tools are integrated using a selective broadcast integration mechanism, making it possible to design a highly integrated system from separate tools. This approach also makes it possible to add new tools without creating any conflicts with the existing tools. In addition, the integration between two separate tools can be easily enhanced, and tools can communicate with each other over a network.
The interface that ties the tools in SDT is called The SDT PostMaster. The parts of the Postmaster interface that are of interest for the users of SDT are documented so that you can integrate your own tools with SDT.
The SDT Batch Facilities are commands that you type from the OS prompt. These facilities take advantage of the Postmaster and pass messages to the SDT Tools, ordering the individual tools to process information as required. The batch facilities support the following operations:
- Printing (to file or to printer)
- Analyzing (typically syntactic and semantic check of an SDL system)
- Making (for instance building an application for target environment).
The Software License Server controls the licensing of the tools included in SDT. This is performed through a floating license mechanism based on a third party software, FlexLM\xaa (1). The current license numbers along with a key are stored on a text file, which is distributed at installation of the software. This provides a flexible way of upgrading licences and adding new license agreements, as well as allowing you to keep track of the actual usage of the tools you have purchased.
FlexLM supports multiple tools (even from different tool manufacturers) share the same license server, so SDT should not cause any problems when installing it into your computer environment.
The following build up the SDT Base tools:
- The SDT Organizer; the tool features a graphical view of the SDL hierarchy and assists you in keeping track of your work with SDL diagrams. The Organizer also administrates the Message Sequence Charts you are working with so that they are treated as an integrated part of your documentation.
Furthermore, the Organizer manages the other tools in SDT, taking advantage of their respective functionality when needed and thus providing the feeling of a truly integrated tool set.
- The SDL Editor is used for creating, editing and printing specifications and descriptions using the graphical SDL notation. The SDL Editor also performs various syntax checks at editing time.
- The Print Utility supports printing of all the information that is managed by the SDT tools. Various options allow to customize the printouts so that they fit in your documentation environment. The Print Utility supports the generation of PostScript, encapsulated PostScript, as well as the documentation formats FrameMaker\xaa and Interleaf\xaa .
- The Type Viewer visualizes the impact of the inheritance and specialization mechanisms in your SDL-92 system. The Type Viewer produces a graphical tree that is of great assistance to understand and take full advantage of the SDL types(2) that you have defined in an SDL system. Of course, the graphical tree can be printed and included as a part of the documentation of your system.
- The Search List Manager is used to set up the user environment by allowing you to create and edit search lists, which designate a number of directories as your work environment. The Search List Manager can also present detailed information about the SDL and MSC diagrams stored in your environment and can function as a shell between the diagrams managed by SDT and the operating system.
- SDT On-Line Help is a fully context-sensitive help facility. It provides access to help on tools, windows and commands, as well as help buttons in dialogs. SDT takes advantage of FrameMaker\xaa or an HTML viewer such as NCSA Mosaic(3) to display the manual pages, featuring graphical presentation, hypertext links and navigation support. The PostScript files that were used when printing this manual are enclosed in the SDT distribution. You are free to produce additional hard-printed copies of the manual pages that are of interest.
- The Preference Manager allows you to set up or change the behavior of the SDT tools by customizing the default values. SDT lets you specify whether a customized behavior should be projectwide or even companywide, or if an individual user should be allowed to customize some behavior.
- The Analyzer performs several functions. It performs syntactic and semantic analysis of your SDL descriptions. It generates error reports and warnings in appropriate cases, and has the ability to produce information about definitions and cross references in an SDL system. The Analyzer also converts SDL information from the Graphical Representation (SDL-GR) to the textual Phrase Representation (SDL-PR). The reverse conversion is also possible, allowing you for instance to import PR files from other tools than SDT.
- The Cross Reference Viewer presents listings of definitions and cross-references in a clear and easy-to-understand graphical notation. The Cross-Reference Viewer is provided with filtering and navigation functions, with a trace-back to the source SDL diagrams.
- The Coverage Viewer is a test coverage and profiling tool that displays the results of a simulation as a graphical transition or symbol tree. The tool can present an overview of the system coverage or a detailed view on a part of the system.
The additional tools available in SDT consist of the following:
- The MSC Editor supports creating, editing and printing of Message Sequence Charts using the graphical notation defined in the standard Z.120. Also, it can serve as a powerful graphical trace tool when simulating and validating a system specified in SDL. MSCs can also be verified for consistency with an SDL system using the SDT Validator.
- The C Code Generator
transforms your SDL system into a number of "C" files that are compiled and linked with a runtime library. The "C" files can be used for multiple purposes, depending on what libraries are available in your configuration. The C Code Generator exists as a C-Basic code generator and a C-Advanced code generator.
- With The Simulator library, you can build an executable program, a simulator, which helps you to understand and debug the behavior of a system specification. In the external view of a system specification, you are interested in the signal interface. In the internal view, you are interested in the internal behavior of a system specification. The execution of a simulator can be traced in a graphical mode in the source SDL diagrams and can be logged graphically in terms of Message Sequence Charts. Target simulation is also supported.
- With The Validator library, the C code can be linked to build a validator. A validator is an advanced "self-exploring" simulator that may be used for finding errors and inconsistencies in an SDL system and to verify that a system is consistent with a Message Sequence Chart.
- Application libraries allow generation of C code indented for Building an Application for host or target environments, directly from your SDL diagrams.
- We support most of the commercially available real-time operating systems. You can also build applications where the C Code Generator runtime library schedules the system and sets the real-time pace. Building applications require the
C-Advanced code generator and The Master Library.
- The Performance Library library allows you to create a performance model of your SDL system that you run on your host computer. The library is optimized with respect to performance, so that a large amount of statistical data can be produced during a reasonable execution time. (SDT does not, however, provide any means to analyze statistical data.)
- The ADT Library (library of Abstract Data Types) features a number of general ADTs that provide the basic services that are often needed when designing an SDL system. The ADT library is distributed in source code so you can tailor the ADTs to fit your specific requirements, if needed.
- The Cmicro Generator is designed to meet the needs of small to mid-range microcomputer controlled applications. It is an extension to the C Code Generator with highly optimized and compact "C" code. The Cmicro Generator is part of the Cmicro Package which in addition consists of The Cmicro Library and The Cmicro Tester.
The Cmicro Package is developed and marketed in cooperation with Telelogic's German distributor, S&P Media, and is to be ordered separately.
- The Cmicro Library is the "virtual SDL machine" needed to build an executable from the generated Cmicro Code.
- The Cmicro Tester allows testing and debugging of the generated SDL system while it is running on a target. A prerequisite is a communications link to a host system. The Cmicro Tester is an optional part of the Cmicro Package.
- The SDL-TTCN Link provides a means to check the consistency between an SDL system managed by SDT and a test specification, expressed in TTCN(4) and managed by Telelogic's TTCN tool ITEX. With the SDL-TTCN Link, you can generate the static parts of the test specification automatically, with direct access to the system specification (SDT) from the test development (ITEX).
- The SDL to CHILL Translator is used for translating your SDL specifications into CHILL code, which you use for building applications. The generation of simulations is, however, not possible with this tool. Our Norwegian distributor and technical partner, Kvatro A/S, can provide you with their highly performant CHILL development environment, CHIPSY\xaa .
In order to properly use SDT, you need to understand the basics for how the information is organized.
SDT primarily handles SDL information in the graphical representation, SDL-GR. The major advantage that follows this approach is that you are free to apply any graphical styleguide to your diagrams since SDT lets you position symbols and shape lines the way you like.
Each SDL diagram consists of a number of diagram pages. An SDL diagram page may contain references to other SDL diagrams. This allows you to build a hierarchical structure which adheres to the SDL syntax rules. See Figure 7.
Figure\x11 7 : Organization of SDL information.
-----
(fig)
-----
Each diagram (SDL and MSC) is stored on its own individual file. An SDL structure is built up from a number of these SDL files. These files are logically tied together by SDT, using a System File, in order to constitute a coherent SDL structure. This process is managed by the tool.
You may also include SDL-PR files into an SDL-GR structure.
Of course, transformation of SDL-GR to SDL-PR and vice versa is supported.
Message Sequence Charts are mainly handled in the graphical representation, MSC-GR.
In contrast to SDL diagrams, MSCs are not paginated.
MSC diagrams may be managed as entities of their own. SDT also supports including MSCs in an SDL structure using the Associated Documents concept.
SDT allows reading and writing of MSCs expressed in the textual form, MSC-PR. Both the instance-oriented and event-oriented forms are supported, according to the recommendation.
SDT has the ability to read and write SDL and MSC textual files, SDL-PR and MSC-PR. The primary purpose is to enable importing and exporting of SDL and MSC information, rather than to provide an alternative storage format, since the layout and exact appearance of a diagram is lost when storing it in PR format and reading it back again.
The tools included in SDT also use the PR formats as temporary storage formats when processing information.
Once SDT is up and running, you may work on individual diagrams, regarding them as individual objects of their own. However, this requires that you keep track of each individual file.
When the amount of diagram increases, this process tends to become rather complicated, in particular when introducing inheritance and specialization between diagrams.
To cope with this problem and as a means to ensure the consistency of an SDL structure managed by SDT, the system file is introduced.
The system file holds the information about the SDL structure and also keeps track of the file bindings, i.e. what file a particular diagram is stored on. When working on your SDL diagrams, SDT keeps track of the changes you apply and updates the system file accordingly.
SDT uses a graphical approach in order to display the contents of the system file in an easy to understand way. An SDL-like notation is adopted as long as feasible.
Figure\x11 8 : The Graphical Presentation of a System File.
-----
(fig)
-----
Note that, in addition to using the system diagram as root diagram (as in Figure 8), it is also possible to define any diagram as root diagrams.
You may also add objects to the system file that are not part of your SDL diagram structure, but that may be related in some way or that you would like to keep track of. These objects are added as associated documents.
Figure\x11 9 : Associated Documents.
-----
(fig)
-----
In addition to the properties mentioned above, the system file may store information about what options you have set up for the structure that is managed by the system file. Typically, analysis and code generation options would be stored in the system file.
Since SDT operates on files, you may use any revision handling system for checking out work copies of your SDL diagram files to your work directory (this task needs to be performed outside SDT).
SDT may also be configurated to manage multiple versions of your source SDL-GR and MSC-GR diagrams, by binding a diagram to any suitable file in your file system. This file binding mechanism may either designate a particular file or may use a search list.
A search list is basically an arbitrary number of directories that SDT will scan through on demand in order to search for a file which contents match the diagram type and name. Once a file has been located, the diagram-file binding is established until you order a new binding.
Figure\x11 10 : A Search List, Specifying Four Directories.
-----
(fig)
-----
SDT provides mechanisms for an easy rebinding of diagrams. These file binding mechanisms allow you to keep track of multiple versions of your source diagrams with a minimum of efforts.
Virtually all of the output information that is produced with SDT consists of files, most of them are use a text-based format (for instance SDL-PR files and C files).
You may specify default locations for files that are generated with SDT. Also, you may specify the level of granularity, allowing you to generate multiple files or one file only.
Furthermore, SDT features an SDL-Make mechanism that minimizes the turnaround time, by computing the passes the tool must run in response to a modification of a source diagram.
On workstations, the SDT tool set is implemented as X Window applications, using the Motif widget set.
The tools included in the SDT Base Tools are available on PCs as a set of Microsoft Windows applications. In addition, The MSC Editor is also available on PCs.
Since SDT is supported on different systems, there may be slight differences in the appearance of each tool between environments. However, the functionality is identical as long as the underlying system and the OS allow it.
All SDT graphical applications follow the same style guide, The SDT Graphical User Interface.
Full compatibility between SDT on PCs and SDT on workstations ensures that a future upgrading of your computers towards workstations is possible, and allows heterogenous network solutions with, for instance, PCs connected to a UNIX\xaa based file server.
On workstation environments, the following architectures and operating systems are supported:
- SUN SPARCstation (SUN OS(5))
- HP 9000/300-400 and 700-800 series (HP-UX)
- IBM RS/6000 (AIX)
- DECstation (ULTRIX)
For more information about the supported platforms, see chapter 2, System Prerequisites, in the volume SDT 3.02 Installation Guide.
The main divergencies between SDT and the ITU recommendations (see references [1] and [2] in chapter 1, Introduction to SDL, MSC, TTCN and ASN.1) are:
- The concept of a generic system is only partially supported.
- Macro calls are only allowed within flowchart diagrams.
- The names of diagrams and diagram pages must conform to the lexical rules of SDL, except that spaces are not allowed.
The SDT Message Sequence Chart Editor fully supports basic MSCs as defined in the Z.120 recommendation (see reference [3] in chapter 1, Introduction to SDL, MSC, TTCN and ASN.1).
Footnotes
- (1)
- FlexLM stands for Flexible License Manager.
- (2)
- The SDL term type corresponds to the term class, used in many OO notations
- (3)
- NCSA Mosaic is an Internet information browser and World Wide Web client. NCSA Mosaic was developed at the National Center for Supercomputing Applications at the University of Illinois, Urbana-Champaign.
- (4)
- TTCN stands for Tree and Tabular Combined Notation. It is an ISO standard that is used to describe a test specification.
- (5)
- Including Solaris.
Table of Contents 
Next Chapter 
