SIMPLE (Source-related and Integrated Multiprocessor and -computer Performance evaluation, modeLing, and visualization Environment) is a tool environment designed and implemented for analysis of arbitrarily formatted event traces. It runs on UNIX and with limitations on MS-DOS systems. SIMPLE has a modular structure and standardized interfaces. Therefore it can easily be extended, and tools which were developed and implemented by others can be integrated into SIMPLE with little effort. The object-independence of SIMPLE is based on two principles (see also fig. 6).
First, all analysis tools of SIMPLE use the TDL/POET/FILTER interface for accessing and filtering event traces. This has several advantages: (i) the tools are independent of the trace format and can analyze event traces of arbitrary origin; (ii) all tools are adapted to a new trace format by writing one TDL description once; (iii) all tools have the same user interface concerning filtering event records. Once a filter description is specified, it can be used in all analysis tools; (iv) the tools can use the field names and interpretations, which are defined in the key file, for problem-oriented input and output, e.g. for labeling plots.
Second, the analysis tools are implemented in such a way that they do not rely on the semantics of the trace data, or at least try to avoid this as much as possible. Each tool provides a command and configuration language. The key words of this language represent the features of the tool. If a command contains a record field name, the analysis tool uses the contents of the corresponding record field for the execution of this command. All commands for one analysis task are stored in a command file. Once created, it can be used to analyze different event traces.
This procedure has also several advantages: (i) the tools can be adapted very easily to a new object system or application, as they are programmable; (ii) the tools can check whether the specified record field is defined for the trace and whether it has the right type for the current command. For the analysis tool, the specified names are just user-defined identifiers without any semantics, but as the names represent special semantics for the user, he has the impression of specifying problem-oriented and application-dependent commands.
The programmability of the tools has also a small disadvantage: it takes some time to make oneself acquainted with the tools, and the user should already have had some experience. Combined with object-independence however, programmability has another big advantage: it ensures that the tools can be used for realistic and complex applications and that experienced users want to use them also. On the other hand, a monitoring expert can adapt the tools to a new object system or application by simply writing the required description and configuration files. Calling the tools can then be hidden by a menu system, enabling a beginner to use them without difficulty. Later, if the analyses provided are not sufficient, they can be very easily changed or extended. This cannot be done with an object-dependent analysis system - at least not without great effort.
Often, the analysis tools can be implemented independently of the semantics of the trace data and therefore they are object-independent. Unfortunately, this is not always the case. Consider a tool which recognizes complex activities described by regular event expressions as in EDL [2]. It has to know in which record field the event identifications are stored. But many monitoring projects, which have been performed with SIMPLE during the last few years, have shown that in almost all cases only a very small amount of information about the semantics of the trace data is necessary. Not surprisingly, this is the knowledge of the event and the time and place it occurred. If a SIMPLE tool needs this special information, it uses one of the following predefined standard names to access the data:
the event. This time information is used
for ordering the event records according to increasing time.
Naming a record field with one of the predefined names in the TDL description indicates that this field has the defined semantics. Then the analysis tools can use this information accordingly. Of course, the enumeration of names above is based on our experience only. Someone else may want to extend this list.
It is also possible to standardize some interpretations of the EVENT record field, e.g. send and receive. This information could be used by a tool which visualizes the communication in computer systems. The only problem is that the semantics of the names must be specified accurately enough to allow the comparing of results obtained through analyses of traces of different origin.