140 VISUAL FORMALISM, STATECHARTS, AND STATEMATE

5.1.2 Semantics

At the time of its development, Statecharts was purely a specification language with no underlying basis for formal analysis or verification. It was not associated with any logics or algebras, and hence was often regarded as a semi-formal specification language. More recently, [Harel and Naamad, 1996] presented a semantics for Statecharts.

The behavior of a Statechart can be defined by a simulation of the sequence of steps allowed. The start of a step can be triggered by one or more events. Given the current state, we select a maximal set of compound transitions to fire from the currently enabled set of transitions. A compound transition is a sequence of enabled and thus executable transitions. All the executions of a step or transition are performed in parallel. Statecharts uses the instantaneous broadcasting of events as the communication mechanism among states at any level.

5.2 ACTIVITY-CHARTS

The language activity-charts describes the functional decomposition of a system. It is a conceptual modeling language which graphically shows activities or functions with rectilinear shapes. Solid arrows indicate the flow of data items whereas dashed arrows represent the flow of control items. Basic (or atomic) activities cannot be decomposed into lower-level activities and may be described as code in a programming language such as C. The details within a higher-level activity are specified by its lower-level activities. An activity takes in input items and produces output items while it is active.

Data-stores represent buffers where databases or data structures can be stored in an activity. Control activities appear as empty boxes in an activity chart and show the behavioral view of the system. A control activity can control other related activities by sensing their statuses and giving commands to them. The language of Statecharts is used to describe the contents of these control activities.

5.3 MODULE-CHARTS

The language module-charts describes the system modules (the physical components), the environment modules (external to the system), and the flow of data and control signals among these modules. Therefore, module-charts provides a structural view of the system. Rectilinear shapes denote modules and rectangles with dashed lines signify storage modules. Environment modules are also represented by rectangles with dashed lines but they are outside the specified system. As in the states in Statecharts, submodules in module-charts may appear inside a module and several levels of encapsulation may exist. Labeled arrows and hyperarrows represent the flow of information between modules.

Figure 5.5 shows the module-chart of a simplified car. CAR is the main component, which is decomposed into several submodules, two of which are brake-system

142 VISUAL FORMALISM, STATECHARTS, AND STATEMATE

and engine-system. The brake-system module is further decomposed into three submodules: signal-processor, anti-lock-braking-unit, and normal-braking-unit. The brake-pedal, hand-brake, accelerator, and wheel-sensors are treated as external or environment modules.

5.4 STATEMATE

STATEMATE [Harel et al., 1990a] is the commercial specification tool for the designer to specify a system under development (SUD). The tool consists of the three graphical modeling languages described above (Statecharts, activity-charts, and module-charts) and the forms language.

5.4.1 Forms Language

For information that is not graphical in nature, STATEMATE provides a forms language to allow the designer to enter this information for specific elements of the specification. This information includes the actions associated with the entrance to and exit from a state, the type/structure of data items, and the definitions of compound events and conditions. For instance, the form for data item has fields for name, synonym, description, definition, “Consists of,” “Attribute Name,” and “Attribute Value.” The “Consists of” field is used to structure data items into components, and the “Attribute Value” field is used to associate the attributes with the data items.

5.4.2 Information Retrieval and Documentation

STATEMATE provides tools for retrieving information and for preparing documentation about the project. Both are needed for team/customer communication in large project developments in industry. The object list generator is a querying tool for accessing lists of elements satisfying a set of user-supplied criteria from the database. Reports called data dictionaries, textual protocols of states and activities, interface diagrams, N 2-diagrams, and tree versions of different hierarchies can be prepared. A document generation language allows the user to generate customized documents conforming to several document standards including the United States Department of Defense (US DoD) Standards DOD-STD-2167 and DOD-STD-2167A.

5.4.3 Code Executions and Analysis

Statecharts was first developed as a standard specification language to facilitate communication between customers, managers, engineers, and programmers in a design and development team. In 1987, the first version of STATEMATE incorporating the Statecharts language was completed and released by AD CAD. STATEMATE can execute a single step of the behavior of the specified system from the initial system state or any given system state. This is done by algorithmic procedures that follow the semantics of Statecharts, module-charts, and activity-charts. This stepwise exe-

cution is similar to the stepwise execution of a program by a typical program debugger. Therefore, this execution ability serves as a debugging mechanism for detecting errors or inconsistencies in the specified system.

It is often not practical to execute interactively the steps of interest, so STATEMATE provides a simulation control language (SCL) to specify programmed executions, that is, the user can specify the sequence of steps to take. Breakpoints can be specified so that the tool can stop after executing specified steps and wait for further instructions from the user. It is possible to restrict the scope of the simulated executions so that it is not necessary for the entire system to be completely specified before we can simulate steps in a specified part of the system. Results of the simulated executions are recorded in a trace database, and a number of simulation reports can be generated.

By carefully writing an SCL program, we can test parts of the specified program that may contain errors or inconsistencies. We can attach a watchdog statechart to the system being tested so that this watchdog statechart will enter a special state when a specified situation occurs. This is useful in finding states in which a specified condition is true. However, testing all scenarios is not practical even for small systems due to the state explosion problem, as noted by STATEMATE implementors. In fact, doing so would be equivalent to generating the entire FSM or reachability graph of the specified system, which is what Statecharts wants to avoid in the first place. Also, such exhaustive testing cannot be applied to a system with an infinite number of states. STATEMATE developers plan to provide the capability of verifying specification against a temporal logic formula, but so far the tool by itself does not have this formal analysis ability.

STATEMATE can automatically translate a specification into an Ada or C prototype code. If testing of the generated code detects errors, the corresponding specification can be revised and the code regenerated. This facility can move the prototype code closer to the final software by iterating through several of these model revisioncode generation steps. This procedure is known as incremental substitution.

5.5 AVAILABLE TOOLS

As a commercial product, STATEMATE (and hence Statecharts) has been used for more applications than experimental specification and analysis tools. One of the first and the most notable and widely publicized application is probably the missionspecific avionics system for the Israel Aircraft Industries’ Lavi fighter aircraft. Part of the avionics system is specified in Statecharts. Other published applications include cruise control, processing modeling, and communication protocols.

STATEMATE is a well-designed specification tool and has a convenient user interface. It is acceptable in small projects for testing and limited reachability analysis. It is better than less formal or semi-formal approaches but lacks the formal analysis and verification capabilities of newer approaches such as logicand algebra-based tools. This weakness limits STATEMATE’s usability as a specification tool in the early stages of system specification and design, for unambiguous communication

144 VISUAL FORMALISM, STATECHARTS, AND STATEMATE

between customers and developers about the system to be designed. However, new versions of the tool allow an interface between the Statecharts specification facility and temporal-logic-based model checkers. The tool is also useful in detecting inconsistencies or conflicts in the specification. More details about STATEMATE can be found at

http://www.ilogix.com

The current version of STATEMATE from I-Logix is called Statemate MAGNUM. It is a comprehensive graphical modeling and simulation tool for the rapid development of complex embedded systems. Using this tool, the user can create a complete specification, thus serving as a formal step between system requirements and system implementation. This specification may be executed or graphically simulated for exploring “what if” scenarios to determine if the behavior and the interactions between system elements are correct. Therefore, the user can detect and then correct errors resulting from ambiguous requirements early in the design process.

Another tool available from I-Logix is Rhapsody, an enterprise-wide visual programming environment incorporating a Statechart and activity-chart/diagram specification facility for designing and implementing real-time embedded systems and software applications. It is based on the Unified Modeling Language and is available in several language platforms, including C, C++, and J. Rhapsody thus combines both functional decomposition and object methods, allowing the graphic design of the behavior of objects. This environment provides real-time behavioral semantics, software packages, target real-time operating system support, model/code associativity, design-level debugging and validation, and production quality customized code generation. Therefore, Rhapsody helps the designer produce a model that is also the resulting application code with complete documentation. Rhapsody integrates the analysis, design, implementation, and test phases of the software design process. Its architecture is open and configurable to allow for future enhancements. Rhapsody comes with interfaces to commercial configuration management tools, requirement traceability tools, integrated development environments, testing tools, and human machine interface tools. Rhapsody shifts the focus of work from coding and debugging to design. Other Rhapsody features include model/code associativity, team-based development, system requirements through use cases, component collaboration and scenario analysis with sequence diagrams, architectural modeling with object modeling, and system-wide management and viewing.

With Rhapsody, the designer can develop and modify target application code as often as needed while completing and validating performance and behavioral characteristics of the graphical model, using the same diagrams for designing the model to debug the application at the desgin level. This is possible since the code is the real code written in one of the supported programming languages rather than a simulated model of the application. The tool allows the linking of design documentation and implementation throughout the design process.