Relevance, Integration and Classification of Specification ... - CiteSeerX

Relevance, Integration and Classification of Specification Formalisms and Formal Specification Techniques H. Ehrig, F. Orejas, J. Padberg Technical University of Berlin, Universitat Politecnica de Catalunya [email protected], [email protected], [email protected] August 1999

Abstract The purpose of this paper is to discuss the relevance of formal specification techniques versus informal and semi-formal techniques and to propose classification aspects for the great variety of specification formalisms. A formal specification technique is considered to be a specification formalism together with a possibly domain specific methodology for the software development process. For this purpose we first study basic formalisms for different views of systems, in a second step the integration of different basic formalisms and finally we propose a list of relevant classification aspects for specification formalisms. These classification aspects are intended to be a basis for the evaluation of the adequacy of formal specification techniques within specific application domains.

1 . Introduction Formal specification techniques for all kinds of software, communication-based and embedded systems have been developed during the last two decades and applied successfully in several projects. Although informal and semi-formal specification techniques are still dominant in industrial software development the relevance of formal techniques is certainly increasing (see [FM 99]). The relevance of formal methods in the application domain of train-control-systems has been discussed within the workshop FORMS’98 at TU Braunschweig (see [FORMS’98]). In a resolution it was proposed to build up a working group in order to achieve a consensus between developers (industry), users (German Railway, Deutsche Bahn AG) and the federal railway control agency (Eisenbahnbundesamt) concerning the use of formal specification techniques in this application domain. The main purpose of this paper is to give a general introduction to the area of formal specification techniques, to discuss the relevance of formal versus informal and semi-formal techniques, and to propose classification aspects for specification formalisms which later can be used to evaluate the adequacy of different formal specification techniques for the application domain of train-controlsystems.

-1-

In this paper we distinguish between specification formalisms, in the sense of formal notations for syntax and semantics of specifications, and formal specification techniques including specification formalisms and a methodology how to use these formalisms in the software development process for specific application domains. The purpose of this paper is to discuss mainly integration and classification aspects of specification formalisms and the relevance of formal specification techniques more or less independent of the application domain of train-control-systems. In a second paper [ES 99] the working group mentioned above proposes requirements for formal specification techniques in the area of train-control-systems which are intended to be the basis for the evaluation of different formal specification techniques. Of course, there is a close relationship between the classification aspects of this paper and the proposed requirements in [ES 99], which includes in addition all aspects concerning the methodology how to use formal specification techniques in this specific application domain. The problem of integration of formal specification techniques is also the main motivation for a focus area program of the German Research Council (DFG), where one of the main application domains are train-control-systems. An overview of this program is given in [EGK 98]. An integration paradigm for data type and process specification techniques has been proposed in [Ehr et al 96, EO 98a, EO 98b], which is reflected in sections 3 and 4 of this paper. Classification and integration aspects for the area of Petri nets as considered in the DFG-Researcher-Group on Petri net technology [BFG+ 98, DFG 99] have also influenced the concepts in this paper. In this paper we first discuss the relevance of formal specification techniques in general, especially the new perspectives of formal versus informal and semi-formal techniques. In section 3 we consider as basic views the data type and process view as well as time constraint and discuss basic specification formalisms for these aspects. The integration of basic formalisms is discussed in section 4 and in section 5 we propose classification aspects of specification formalisms from a general, methodological and structural point of view. Finally in section 6 we discuss further steps towards evaluation and classification of formal specification techniques.

2 . Relevance of Formal Specification Techniques It is common sense to use all kinds of diagrammatic and textual notations in the specification phases of software development. Roughly we can distinguish between informal, semi-formal, and formal notations and techniques. As pointed out before we distinguish between notations and techniques, where a technique is a notation together with a methodology how to use it in the software development process. A formal notation is required to have a formal syntax and semantics, a semi-formal notation has a formal syntax, but usually no formal semantics, while an informal notation has an intuitive syntax and semantics, where both are not formalized. Formal syntax and semantics in this context means that they are based on one or a combination of mathematical theories, like set theory, logic, algebra, or category theory. The advantage of informal notations is high flexibility and easy comprehensibility at least on an intuitive level of understanding.

-2-

The main disadvantage is lack of precision and ambiguity of interpretation, which especially does not allow automatic interpretation of automatic code generation. A semi-formal notation has higher precision and less ambiguity, which allows automatic treatment on the syntactical but not concerning the semantical level. The main aspects are summarized in table 1:

Syntax Semantics Comprehensibility Ambiguity Precision

Informal intuitive intuitive easy very high low

Semi-formal formal intuitive good high higher

Formal formal formal more difficult low high

Table 1: Informal, Semi-formal and Formal Notation It is well-know that the specification phases within the software development process become more and more important. Usually the starting point is a problem description in natural language, followed by a requirements analysis leading to a requirements specification and via some transformation steps to a design specification, which is the basis for coding. Traditionally all these specification phases and documents are presented using an informal or semi-formal notation. The main new perspectives to use formal techniques for software specification are the following: 2 . 1 Mathematical Precision and Semantical Foundation As pointed out already the main disadvantage of traditional techniques is the lack of precision and ambiguity of interpretation. A formal technique with mathematical syntax and semantics leads to mathematical precise specification documents with a well-defined mathematical semantics. Of course, it is important that the software engineer is able to understand and handle the formal technique in an appropriate way, which can be supported by suitable structuring and visualization techniques. 2 . 2 Analysis and Validation Mathematical precision and semantical foundation as discussed above are the basis for formal analysis of the specification, especially concerning safety and liveness properties. Moreover, the formal specification can be used for test case generation and tests not only on the program, but already on the specification level of the system. This is an important issue for system validation. 2 . 3 Executability of Specifications Since traditional specifications usually are not able to be executed, an early prototype has to be provided in addition to the specification. The new perspective of formal techniques is to come up with executable specifications which can be used already as early prototype of the corresponding systems. Of course, not every formal specification is executable. But in several cases it is possible to obtain an executable version via suitable transformations.

-3-

2 . 4 Automatic Code Generation In traditional software development specification and code generation are different phases, where code generation cannot be done automatically due to lack of precision of the specification. Since formal specifications are formal documents with well-defined semantics there is a good chance for automatic code generation by means of a compiler from the formal specification to a suitable programming language. 2 . 5 Verification of Design versus Requirement Specifications In traditional software development verification is often not possible in a rigorous mathematical way, although it is important especially for safety critical systems. Although the implementation of a system is a formal document it is usually very difficult to verify the implementation against the specification of the system. Since a rigorous mathematical verification of document A against document B requires to have a formal semantics of both documents, the new perspective is to verify the design specification against the requirement specification, provided that both are formal specifications. The additional advantage is to have verification already in an earlier stage of system development compared with verification of implementation against specification. 2 . 6 Compatibility of Structuring and Refinement Structuring and refinement in traditional software development are important techniques to master large systems, but it is often not clear in which way they are compatible with each other. Hence there is a high risk of inconsistencies in the software development process. For most of the formal specification techniques there are already concepts for structuring and refinement and it is possible to analyse in a mathematical way under which conditions structuring and refinement are compatible such that inconsistencies can be avoided. 2 . 7 Formal Parameterization and Reusability Generic software development is an important issue for reusability not only on the implementation but also on the specification level. In order to provide generic specifications we need a concept of parameterized specifications with formal parameters and instantiation of formal by actual parameters. Such a formal parameterization concept is available for most formal specification techniques and it is the basis for reusability of specifications with well-defined semantical compatibility between formal parameterized and actualized specifications. Another important aspect concerning reusability is to reuse formal design instead of code. Especially changes should be done on the specification level where usually the main part of the specification can be reused such that also formal analysis can be reused to a large extend. 2 . 8 Mastering of More Complex Systems All the aspects mentioned above allow to master more complex systems using formal compared with traditional specification techniques. This is especially important for complex communication based and embedded systems, where mastering means to have full control of the system behaviour.

-4-

3 . Basic Views and Classification of Specification Formalisms In order to obtain a first rough classification of specification formalisms we distinguish between basic formalism, concerning mainly one view of a system, and integrated formalisms taking care of different views and aspects. In this section we consider as basic views the data type and process view as well as time constraints and give an overview of corresponding basic specification formalisms within the framework of formal specification techniques. Let us point out that even basic specification formalisms can be used in different styles for the specification of different views of a system. However, most of them are especially useful for one particular view, which will be considered in our following classification. 3 . 1 Data Type View and Formalisms The following specification formalisms are especially useful to specify data types and hence the functional view of systems. We distinguish the following classes of data type specification formalisms: • algebraic / axiomatic approaches • state / model-oriented approaches • class-oriented approaches For each approach we give a general overview of formalisms and point out for a typical representative how it can also be used or extended in a process-oriented style. 3 . 1 . 1 Algebraic / Axiomatic Approach This class of data type specification formalisms includes especially all kinds of algebraic and logic specification formalisms, where the axioms are ranging from classical equations, via conditional equations and Universal Horn to first and higher order logical formulas. As typical representatives of this class we consider the (classical) algebraic approach based on algebraic specifications in the sense of [EM 85], and extensions of algebraic specifications, where states are defined by algebras as proposed in [DG 94], [AZ 94], and [GR 95, 97, 98], or processes are specified algebraically [Ehr et al 90]. 3 . 1 . 2 State / Model-Oriented Approaches This class of state / model-oriented specification formalisms includes techniques like VDM [Jon 86], Z [Spi 92], B [Abr 96], and abstract state machines [BH 98], formerly called evolving algebras [Gur 91]. As typical representative we consider Z. Data types are given by type definitions in Z. Data states are given by data state schemas, while data state transformations are given by operation schemas. Although Z has no specific features for processes we can also use Z in a dynamic style to define processes in layer 3 by state and operation schemas for reactive states. 3 . 1 . 3 Class-Oriented Approaches Class-oriented specification notations and formalisms are closely related to object-oriented modelling techniques, where TROLL [JSHS 96] and OBLOG [Ser 91] are examples of formal specification techniques and an algebraic approach is given in [PPP 91]. In the great variety of class-oriented specification approaches the universal modelling language UML

-5-

[RR 97] has become a quasi-standard already, but a formal semantics is still under development. In addition to the well-known static structure diagrams, including class and object diagrams, UML also includes use case, sequence, collaboration, statechart, activity and implementation diagrams supporting mainly the dynamic view of systems. For the purpose of data type specifications we consider as typical representative class-diagrams in the sense of UML, where a formal semantics is given in [Kla 99]. 3 . 2 Process View and Formalisms The process view of a system is concerned with the dynamic behaviour of the system, especially with the processes or activities of a system which realize the different scenarios. We distinguish the following classes of process specification formalisms: • Petri net approaches • process algebraic approaches • automata / statechart-oriented approaches • graph transformation approaches In each of these classes there are low level variants, where data types are only supported in a weak way by fixed data domains or alphabets, and also high level variants which are defined by integration with some data type specification technique. In the following we only consider the low level variants, which are the basic formalisms, while the high-level variants are discussed in section 4. 3 . 2 . 1 Petri Net Approaches In the classical Petri net approaches, like elementary and place / transition nets, there are no distinguished data elements, but only black tokens. These approaches are called low level in contrast to high level net approaches, where we have colored tokens representing different data elements from a given data type or domain. As typical representative of low level Petri nets we consider place / transition nets [Rei 85]. The dynamic behaviour of a place / transition net is based on the firing of transitions, where some token on the input places of a transition are removed and other ones are added on the output places. The system behaviour is given by all net processes, which can be realized by the net. 3 . 2 . 2 Process Algebraic Approaches The class of process algebraic approaches includes especially Hoare's CSP, Milner's CCS and ∏Calculus and all kinds of variants. As a typical representative we consider CCS [Mil 82]. CCS and similarily all the other basic approaches are based on a set of actions, process variables, expressions and equations leading to the definition of processes via a recursive set of process equations. The system behaviour and architecture is mainly given by parallel composition of processes, which is one of the main features of CCS. 3 . 2 . 3 Automata / Statechart-Oriented Approaches The class of automata / statechart-oriented specification techniques includes all kinds of automata, statecharts, transition systems and event structures which are suitable to model the process behaviour of systems. Similar to the process algebraic case the basic approaches are usually based on a set of actions or basic data types only. As a prominent example let us consider statecharts in

-6-

the sense of Harel [Har 87]. A statechart consists of states and transitions, where states are organized in a hierarchical way including parallel states. The dynamic behaviour is based on steps, where all enabled transitions are firing in parallel. 3 . 2 . 4 Graph Transformation Approaches The main idea of graph transformation approaches for system specification is to model system states by graphs and state transformations by graph transformations. There are several different approaches how to model a graph transformation step [Roz 97]. The system behaviour is defined by all possible graph transformation sequences or graph processes, which can be defined similarly to Petri net processes [CMR 96]. 3 . 3 Time Constraints of Process Specifications Time aspects of a system are important topics already on the level of the specifications of the process view. Time aspects can be distinguished into causal, relative or clock-based time structures [Obe90]. The first is given by causal dependencies alone. Relative and clock based time structures add to causal dependencies the possibility of time, either by relative observation or with respect to a given clock. Considering time with respect to the process view allows to distinguish: • Constraints within the Process View In this case relative and clock-based time structures are given explicitly in the process specification. Examples are discrete or stochastic time. • Constraints of the Implicit Time The process view provides an implicit notion of time due to the causal dependencies. Constraints of the process view, that are based on implicit time are given in addition to the process specification formalism. These constraints are formulated in some other formalism, e.g. timing diagrams or temporal logic. We consider the following classes of time formalisms: • Discrete and Stochastic Time • Timing Diagrams • Temporal Logic 3 . 3 . 1 Discrete and Stochastic Time Several process formalisms have been extended by suitable annotations concerning the time, which is needed before a single step or transition can be executed or the time which is needed for execution. This time can be given explicitly (discrete time) or by a probability distribution (stochastic time). Typical examples are timed automata [ABK+ 97], stochastic Petri nets [AMBC+ 95, CGL 94, Ger 98] or stochastic process algebras [GHR 94, Rib 95]. Discrete time is important to model and analyse explicit time constraint of system processes while stochastic time is especially useful for performance analysis of the system [LCGH 98, MBD 98, HHM 95]. 3 . 3 . 2 Timing Diagrams In order to model the time dependencies for the exchange of messages between different objects or components of a systems several notions of interaction or timing diagrams have been developed. Each object or component is represented by a vertical line modelling the local time and messages by arrows between specific points of these lines corresponding to send and receive time of the message. Typical examples of corresponding specification formalisms are sequence diagrams of

-7-

UML [RR 97], message sequence charts [Z 120], and life charts [DH 98]. 3 . 3 . 3 Temporal Logic In order to express safety or liveness properties of a system there are several specification formalisms, which are mainly variants of temporal logic [MP 92, HRH 91, Mes 92, Rei 89]. If the system behaviour can be represented by a labelled graph or transition system, then each run of the system corresponds to a path. Temporal logic allows to express that the states of the systemcorresponding to the nodes of the graph-satisfy certain properties at different points of time. Given a node of a path all predecessors correspond to system states in the past and all successors to system states in the future. This means that temporal logic can be used as a descriptive formal specification technique in its own or in connection with a process-oriented technique. In the latter case process specifications can be extended by formulas of temporal logic in order to express safety and / or liveness properties as discussed above.

4 . Integration of Specification Formalisms In section 3 we have considered basic specification formalisms for the data type, process and time aspects of systems respectively. Now we discuss how to combine or integrate basic specification formalisms in order to handle combination and integration of different aspects. First we provide an integration paradigm for the data type and process view as proposed in our paper [EO 98a], then we discuss the combination with the time constraints and finally we sketch some general models for integration. 4 . 1 Integration Paradigm for Data Type and Process View As typical examples for the integration of data type and process specification formalisms we consider algebraic high-level nets [PER 95], an integration of algebraic specification and Petri nets, µSZ [BGK 98] an integration of Z and statecharts, and attributed graph transformation [ELO 95], an integration of algebraic specification and graph transformation. In all these and several other examples like LOTOS [ISO 89], an integration of algebraic specification and CCS, there is a common pattern how data type and process view are combined with each other. This common pattern has been formulated as an integration paradigm in [EO 98a,b] and consists of four layers which are organized in a hierarchical way. 4 . 1 . 1 Layers of Integration The first layer corresponds exactly to the data type view of the system. The following layers are integrated views of data type, data state and system architecture aspects, where each layer is based on the previous one. This hierarchical concept is different from a dimensions concept (see e.g. [Cor 98], [GKP 98]) where dimensions are considered to be independent and can be combined in different ways. Layer 1: Data Types Layer 1 provides the description of data values and operations on data values for the system. The corresponding data type can be considered as static within the system.

-8-

Layer 2: Data States and Transformations Layer 2 provides the description of data states and data state transformations. This includes all states and transformations, which in principle can occur in the system, even if the data states are non-realizable or non-reachable by the processes of the system. Layer 3: Processes Layer 3 provides processes based on layers 1 and 2. Processes are the activities of the system according to its aims. Especially they realize the scenarios which are required from the application point of view. Moreover, there are communication mechanisms for processes with each other and with the environment in the sense of concurrent systems. Layer 4: System Architecture The system architecture should provide a modular structure of the system in terms of components, where in general each component is given by data types and a set of communicating processes as defined on layer 3. Vice versa this means that there should be horizontal structuring mechanisms in each layer 1-3 leading to a module concept in layer 4 which allows to compose components with suitable notions of compositionality. A more detailed presentation of these layers together with several examples is given in [EO 98b]. In the following we classify our three integrated formalisms mentioned above and UML according to the levels of this integration paradigm (see table 2):

Specification Technique

Layer 1 Data Type

Layer 3 Layer 2 Processes Data States & Transformations

Algebraic HighLevel Nets

data token & algebras def by algebraic specification

marking of places by data token & firing

net processes

parameterization net transformations, union / fusion

Attributed Graph Transformation

attributes & algebras def by algebraic specification

attributed graphs & graph transformation

graph processes

parameterization, composition, modularization

type definition in Z

data state & operation schemas def in Z

statechart processes

configurations

basic data types def by class diagrams

classes, attributes & methods

object-oriented statechart processes

packages

µSZ

UML

Layer 4 System Architecture

Table 2: Integrated Data Type and Process Formalisms 4 . 1 . 2 Algebraic High-Level Nets In the integrated formalism of algebraic high-level nets [PER 95] the data type layer 1 is given by

-9-

algebras defined by algebraic specifications such that the token of high-level nets are no longer black token, but data token as elements of algebras. In layer 2 the data states are given by the markings of places by data token and the transformation of states by firing of transitions. In layer 3 we have net processes, which can be defined for high-level nets similar to those in the low-level case. In the system architecture level 4 we have well-known parameterization and modularization concepts for algebraic specifications [EM 85, EM 90], net transformations defined by rule-based transformation of nets, and the concepts of union and fusion to build up larger nets from smaller components. However, a suitable modularization concept including data type and net parts is still missing. 4 . 1 . 3 Attributed Graph Transformation Similar to algebraic high-level nets the specification formalism of attributed graph transformations [ELO 95] is based on algebraic specifications concerning the data type layer 1. Data states in layer 2 are given by attributed graphs, which are graphs attributed by data elements of algebras defined in layer 1. Transformation of data states in layer 2 is given by the concept of graph transformation applied to attributed graphs. The notion of processes has been extended from Petri nets to graph grammars [CMR 96] and in addition the concept of programmed graph transformations is useful for the concept of processes in layer 3. Concerning layer 4 we again have the well-known structuring concepts parameterization and modularization for algebraic specifications and several notions of composition and modularization for graph transformation systems are under development [EE 96], [HEET 99]. 4 . 1 . 4 µSZ The specification formalism µSZ [BGK 98] was developed in the ESPRESS-project for the specification of safety critical embedded systems. The main idea of µSZ is to integrate statecharts [Har 87] with Z [Spi 92] and to have a notion of configurations as modular structuring mechanism. This means that in the data type layer 1 we have type definition in Z. Data states and transformations in layer 2 are given by data state and operation schemas in Z notation. The processes in layer 3 are defined by statecharts and the system architecture in layer 4 is given by configurations of µSZ. 4 . 1 . 5 UML Last but not least let us consider UML [RR 97] which presently is mainly a collection of semiformal techniques. UML combines several diagram techniques for object-oriented modelling, where a semantical foundation and integration of all these techniques is still missing but under development in different projects. The data types in layer 1 are given by basic data types defined by class diagrams. Data states and transformations in layer 2 are given by classes defining the internal states by attributes and state transformations by methods. Processes in layer 3 are defined using object-oriented statecharts [HG 97]. The package concept is a first step towards a module concept for layer 4. For class diagrams [Kla 99] and object-oriented statecharts [MK 98] a formal semantics is given in the general framework of metamodeling (see [GKP 98]) based on Object-Z [DRS 94]. 4 . 2 Combination with Time Constraints In section 3.3 we have distinguished three different classes of time formalisms which can be

- 10 -

combined with basic or integrated formalisms for the data type and process views. Discrete and stochastic time formalisms are usually extensions of process formalisms, like timed automata [ABK+ 97], stochastic Petri nets [AMBC+ 95], or stochastic process algebras [GHR 94]. Timing diagrams, like message sequence charts, sequence diagrams and life charts, are usually used to present specific scenarios for the system behaviour, which have to be realized by the system. This means that the basic or integrated data type and process specification has to realize all the timing diagrams for the different scenarios. Hence the timing diagram formalism has to be related with the other formalism in order to give a precise meaning for “realization of a timing diagram by a data type and process specification”. The specification formalism of temporal logic is usually used to express safety or liveness properties of a system. If the system behaviour is given by some basic or integrated data type and process specification, we have to make sure that this behaviour can be represented by some labelled transition system, for which the formulas of temporal logic are defined (see 3.3.3). In this case we have a well-defined meaning for “satisfaction of a formula in temporal logic w.r.t. a data type and process specification”. In this way algebraic high-level nets and attributed graph transformation have been combined with temporal logic and µSZ with interval logic. 4 . 3 General Models for Integration of Specification Formalisms Our integration paradigm for the data type and process view can be considered as an informal model for integration of specification formalisms. This informal model was influenced by the semantical reference model in [Cor 98] where three different dimensions of distributed system specification are presented and integrated with each other in an orthogonal way. Another reference model is proposed in [GR 99], which is based on algebra transformation systems [GR 98]. The units of this framework comprise a syntactic and semantic part, where the syntactic part is open for instantiations, and the semantic part is given by labelled transition systems, where the labels are abstract data types and actions from some general data type specification and transformation framework. The concept of metamodeling is proposed in [GKP 98], [Gei 99] and [Kla 99] for the general definition and integration of specification formalisms, where statecharts and Z are integrated in [Gei 99], and specific object-oriented techniques, like class diagrams and an object-oriented programming language, are integrated in [Kla 99].

5 . Relevant Aspects of Specification Formalisms In the previous sections we have discussed the relevance of formal techniques versus semi-formal and informal techniques, we have given a rough overview of basic specification formalisms and discussed how to integrate them. In this section we want to discuss the relevant aspects of specification formalisms in view of practical applications in the software development process independent of specific application domains. We have classified these relevant aspects into general, methodological and structural aspects. 5 . 1 General Aspects 5 . 1 . 1 Mathematical Precision and Semantical Foundation According to our definition of specification formalisms in contrast to semi-formal and informal

- 11 -

notations we require to have a mathematical precise syntax and semantics of our specification formalism. This implies that specifications in this formalism are unambiguous and have a welldefined semantical meaning, which is the basis for several other relevant aspects. In addition to a well-defined semantics it is also important to have a theory for the semantical foundations, which allows to prove properties of the specification formalism in order to support the methodological and structural aspects discussed below. 5 . 1 . 2 Comprehensibility In general it might be expected that specifications given in a mathematical formalism are not as intuitive and easy to comprehense as corresponding ones in informal or semi-formal notation. Nevertheless it is important that the specification cannot only be processed by suitable machines but must also be comprehensible for all people involved in the specification process. Comprehensibility is supported by several other methodological and structural aspects like visualization, animation, modularization, abstraction and refinement which will be discussed below. 5 . 1 . 3 Tool Support and Automatic Code Generation Although specifications on one hand are required to be comprehensible for people it is on the other hand most important to have suitable tool support for all methodological and structural aspects listed below. Especially it is highly desirable to have automatic code generation from the formal specification, such that coding by hand can be avoided at all or at least to a large extend. 5 . 2 Methodological Aspects 5 . 2 . 1 System Views and Software Development Process The specification formalism must be suitable to support one or several views of the system (see section 3) and specific stages and steps in the software development process. In general a specification technique comprises several formalism or different variants of one formalism for different views and steps in the software development process. In this case it is important that the specification technique also includes transformations between these different variants or formalisms in order to support a smooth development process. This means that it is also important to have transformations between specification formalisms together with suitable correctness criteria in order to show consistency and semantical compatibility of the specifications in different development steps. 5 . 2 . 2 Executability, Visualization and Animation In order to support comprehensibility of specifications the specification formalism should allow executability, visualization and animation. Executability in the case of constructive specifications means interpretation or compilation of functions and processes. In the case of axiomatic descriptive specifications the main emphasize is on consistency checking of axioms and derivation of theorems from axioms which can be seen as a form of executability. Visualization means to have a visual representation of the specification based on suitable diagrammatic, graphical or pictorial representations. Animation means executability on the visual level of specifications. Although the general idea of visual specifications is to replace textual ones they may include also textual parts.

- 12 -

5 . 2 . 3 Correctness, Analysis and Verification Due to the semantical foundation of the specification formalism it is possible to formulate various correctness notions between different specification documents. Especially correctness of a specification w.r.t. mathematical model, correctness of a design w.r.t. a requirements specification, or correctness of an implementation w.r.t. a specification. Analysis techniques for specification include properties like consistency or completeness of a functional specification and deadlock freeness, liveness and fairness of process specifications. Verification means to prove correctness and to check analysis properties. It is most important that these techniques can already be applied on the specification level, which is often much easier to be done than on the implementation level. 5 . 3 Structural Aspects 5 . 3 . 1 Parameterization and Reusability The importance of parameterization and reusability of specifications has already been discussed in section 2 (see 2.7). On one hand this means that the specification formalism should allow specifications with formal parameters and an instantiation or parameter passing mechanism. In this case it is most desirable to study semantics and correctness for parameterized specification such that they can be derived for all instantiations. This allows to reuse parameterized specifications with different instantiations avoiding to a large extend repeated correctness, analysis and verification tasks for similar but not same specifications. On the other hand reusability should be supported in the sense of reusability of design as discussed in 2.7. 5 . 3 . 2 Modularization and Compositionality In order to handle larger application systems it is most important to have a suitable modularization concept for the specification formalism, which allows to build up large system specifications from smaller specification units. A specification module should have interfaces to connect them with each other and a body, which is not visible from outside. This is well-known from software engineering. In the case of formal specification techniques it is important to have formal semantics and compositionality for specification modules. Compositionality means that behaviour and semantics of a combined specification module can be composed from that of the parts. This should imply to have compositionality also for correctness, analysis and verification, which is most important for specification of application systems which are usually quite large. 5 . 3 . 3 Abstraction and Refinement It is most important that the specification formalism has suitable notions for abstraction and refinement, which are compatible with the semantics. It should be possible to give the system behaviour on a high level of abstraction first and than to refine it in several steps such that the refined version of the system specification is correct w.r.t. abstract version. In general abstraction and refinement should be special cases of a transformation concept for specifications with suitable verification conditions w.r.t. semantical correctness. 5 . 3 . 4 Compatibility of Structuring and Refinement The relevance of compatibility of structuring and refinement has already been discussed in section

- 13 -

2. The specification formalism should allow to show this compatibility on a syntactical level, which should imply semantical compatibility, or directly on the semantical level. If refinement is a special case of a transformation concept and structuring is given by modularization then it should be possible to show compatibility of modularization and transformation within the specification formalism. 5 . 3 . 5 Evolution and Migration Evolution and migration of systems is very important in most practical applications. The concept of continuous engineering [SG 96, Gri 98, MW 98] is going to be developed in order to find a systematic way to handle the corresponding problems. In this context reusability of design (see 2.7) is especially important. Moreover, old system components, which have no specification or at least not a formal one, have to be combined with or extended by new components. It is an open problem how to use formal specifications in this context in a satisfactory way. If the old system is given or can be provided with some formal specification (a posteori) the problem arises how to combine or integrate specifications based on different specification formalisms.

6 . Towards Evaluation and Classification of Formal Specification Techniques In the last section we have discussed a number or relevant aspects for specification formalisms in view of practical applications in the software development process. In fact, we have considered these aspects independent from a methodology how to use these formalisms in the software development process for a specific application domain. Taking into account a methodology for a specific application domain is important for evaluation and classification of specification formalisms in practice. According to our terminology we have to consider formal specification techniques, i.e. specification formalisms together with a domain specific methodology, for this purpose. The methodology is important to make clear in which way the specification formalism is used in different phases of the software development process. Especially it may be important to use different specification formalisms or at least different variants of one formalism in different phases of the process. In this case it is important to have also transformations between these specification formalisms and criteria to prove correctness and consistency between specifications in different development steps. Requirements for formal specification techniques in the area of train-control-systems are proposed in [ES 99]. In fact the relevant aspects in the last section are the basis for the requirements in [ES 99], where the requirements include in addition all aspects concerning the methodology how to use the formal specification technique in this application domain. An additional requirement in this domain is the separation between safety relevant and non-safety relevant functions. Moreover, it is required that the people in the federal railway control agency (Eisenbahnbundesamt) must be able to understand the basic concepts of the specification formalism and - at least in principle - be able to check specifications of complex systems even without tool support. In order to evaluate formal specification techniques concerning their suitability in this application domain it would be necessary to have different projects using different specification techniques and to check how far the criteria in [ES 99] are satisfied. On the basis of this evaluation it may be possible to give a first classification how far different formal specification techniques are suitable to be used in this application domain. Of course it would be even better to have for each formal

- 14 -

specification technique not only one but several projects where this technique is used and evaluated. Last but not least let us point out that the tool support for specification formalisms and formal specification techniques plays an important role for the acceptance in practice and hence also for evaluation and classification. But it would be important to separate the influence of tool support as far as possible.

References [Abr 96] Abrial, J. R.: The B-Book, Cambridge University Press, 1996 [ABK+ 97] Asarin, E., Bozga, M., Kerbat, A. et al.: Data Structures for the Verification of Timed Automata. Hybrid and Real-Time Systems HART’97, Springer LNCS 1201 (1997) [AMBC+ 95] Ajmone Marsan, M., Balbo, G., Conte, G., Donatelli, S., Francschinis, G.: Modelling with Generalized Stochastic Petri Nets. J. Wiley, 1995 [AZ 94] Astesiano, E., Zucca, E.: D-oids: A Model for Dynamic Data Types. MSCS 5 (1995), pp. 257-282 [BFG+ 98] Borusan, A. Fricke, O., Gajewsky, M., Kindler, E., Lembke, S., Padberg, J., Vesper, T., Weber, H., Weber, M.: Foundation Concepts of the “Petri Net Baukasten”, 1998. http://www.informatik.hu-berlin.de/PNT/pnt-public.html [BGK 98] Büssow, R., Geisler, R., Klar, M.: Specifying safety - critical embedded systems with statecharts and Z, A Case Study, Springer LNCS 1382 (1998), pp. 71-87 [BH 98] Börger, E., Huggins, J.K.: Abstract State Machines 1988-1998; Commented ASM Bibliography, Bull. EATCS 64 (1998), pp. 105-127 [CGL 94] Ciardo, G., German, R., Lindemann, C.: Characterization of the stochastic process underlying a stochastic petri net. IEEE Trans. Software Engineering, 20(7):506-515, July 1994 [CMR 96] Corradini, A., Montanari, U., Rossi, F.: Graph Processes. Fundamenta Informatica (1996) [Cor 98] Cornelius, F.: A Semantical Reference Model for the Integration of Different Dimensions of Distributed System Specifications, PhD-thesis, TU-Berlin, 1998 [DFG 99] DFG-Forschergruppe PETRI NET TECHNOLOGY. Initial realization of the Petri Net Baukasten. Technical Report, 1999. To appear [DG 94] Dauchy, P., Gaudel, M.G.: Algebraic Specifications with Implicit State. Techn. Report, Univ. Paris-Sud, 1994 [DH 98] Damm, W., Harel, D.: Breathing Life into MSC’s. Technical Report, Weizmann Institute, Rehovat, 1998 [DRS 94] Duke, R., Rose, G., Smith, G.: Object-Z: a Specification Language for the Description of Standards. Technical Report 94-45, Software Verification Research Centre, Department of Computer Science, University of Queensland, Queensland 4072, Australia, 1994 [EE 96] Ehrig, H., Engels, G.: Pragmatic and Semantic Aspects of a Module Concept for Graph Transformation Systems, Springer LNCS 1073 (1996), pp. 137-154 [EGK 98] Ehrig, H., Geisler, R., Klar, M.: DFG-Schwerpunktprogramm ab 1998: Integration von Techniken der Softwarespezifikation für ingenieurwissenschaftliche Anwendungen. Informatik Forsch. Entw. (1998), 13, pp. 43-46

- 15 -

[Ehr et al 90] Ehrig, H., Parisi-Presicce, F., Boehm, P., Rieckhoff, C., Dimitrovici, C., GroßeRhode, M.: Combining Data Type and Recursive Process Specifications Using Projection Algebras, TCS 71 (1990), pp. 347-380 [Ehr et al 96] Ehrig, H., Bardohl, R., Cornelius, F., Geisler, R., Große-Rhode, M., Padberg, J.: A New Integration Paradigm for Formal Specification of Safe Software Systems, Proc. 10th Japan-Germany on IT, Kloster Seeon [ELO 95] Ehrig, H., Löwe, M., Orejas, F.: Dynamic Abstract Data Types Based on Algebraic Graph Transformations, Springer LNCS 906 (1995), pp. 236-254 [EM 85] Ehrig, H., Mahr, B.: Fundamentals of Algebraic Specification 1. Equations and Initial Semantics. EATCS Monographs on Theoretical Computer Science, Vol. 6, SpringerVerlag (1985) [EM 90] Ehrig, H.; Mahr, B.: Fundamentals of Algebraic Specification 2. Module Specifications and Constraints. EATCS Monographs on Theoretical Computer Science, Vol. 21, Springer-Verlag (1990) [EO 98a] Ehrig, H., Orejas, F.: Integration Paradigm for Data Type and Process Specification Techniques, Bull. EATCS 65 (1998), pp. 90-97 [EO 98b] Ehrig, H., Orejas, F.: Integration and Classification of Data Type and Process Specification Techniques, Techn. Report, TU Berlin, No. 98-10, 1998 [ES 99] Einer, S., Schnieder, E. (Editors): Formale Techniken für die Eisenbahnsicherungstechnik, TU Braunschweig, 1999 [FORMS 98] Schnieder, E. (Editor): Workshop on Formal Specification of Train Control Systems in Europe. Institut für Regelungs- und Automatisierungstechnik, TU Braunschweig, 1998 [FM 99] Bjorner, D. (Editor) FM’99: The World Congress on Formal Methods, Toulouse, 1999 [Gei 99] Geisler, R.: Formal Semantics for the Integration of Statecharts and Z in a MetamodelBased Framework, PhD-Thesis, Techn. University Berlin, Jan. 1999 [Ger 98] German, R.: Markov regenerative stochastic petri nets with general execution policies: supplementary variable analysis and a prototype tool. LNCS: Coputer Performance Evaluation, 1469:255-266, 1998 [GHR 94] Götz, N., Herzog, U., Rettelbach, M.: Multiprocessor and Distributed System Design: The Integration of Functional Specification and Performance Analysis Using Stochastic Process Algebras. In Tutorial Proc. of the PERFORMANCE’93, Rome, volume 729 of LNCS. Springer-Verlag, 1994 [GKP 98] Geisler, R., Klar, M., Pons, C.: Dimensions and Dichotomy in Metamodeling, Techn. Report, TU Berlin, FB 13, No. 98-05 (1998) [GR 95] Große-Rhode, M.: Specification of Transition Categories - An Approach to Dynamic Abstract Data Types, Ph.D.Thesis, 1995, and Extended Abstract in: The Algebraic Specification Column, EATCS Bulletin No. 55, 1995, pp. 121-128 [GR 97] Große-Rhode, M.: Transition Specifications for Dynamic Abstract Data Types, APCS5:pp. 265-308, 1997 [GR 98] Große-Rhode, M.: Algebra Transformation Systems and Their Composition, Springer LNCS 1382 (1998), pp. 107-122 [GR 99] Große-Rhode, M.: On a Reference Model for the Formalization and Integration of Software Specification Languages. Bull. EATCS 68 (1999), pp. 81-89

- 16 -

[Gri 98] Griffel, F.: Componentware - Konzepte und Techniken eines Softwareparadigmas. dpunkt Verlag, 1998 [Gur 91] Gurevitch, Y.: Evolving Algebras, A Tutorial Introduction. Bull. EATCS 43 (1991), pp. 264-284 [Har 87] Harel, D.: Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8:231-274, 1987 [HEET 99] Heckel, R., Engels, G., Ehrig, H., Taentzer, G.: Classification and Comparison of Modularity Concepts for Graph Transformation Systems. In Handbook of Graph Grammars and Computing by Graph Transformation, Vol. 2, World Scientific, 1999 [HG 97] Harel, D., Gery, E.: Executable Object Modelling with Statecharts. IEEE Computer, 30(7):31-42, 1997 [HHM 95] Herrmanns, H., Herzog, U., Mertsiotakis, V.: Stochastic Process Algebras as a Tool for Performance and Dependability Modelling. In Proc. IEEE Int. Comp. Performance and Dependability Symp. Erlangen, Germany, 1995 [HRH 91] Howell, R.R., Rosier, L.E., Chun Yen Hsu: A taxonomy of fairness and temporal logic problems for petri nets. TCS, 82(2):341-372, 1991 [HU 79] Hopcroft, J.E., Ullman, J.D.: Introduction to Automata Theory, Languages and Computation, Addison-Wesley, Reading, Ma, 1979 [ISO 89] ISO. Information processing systems - Open Systems Interconnection - LOTOS - A formal description technique based on the temporal ordering of observational behaviour. International Standard ISO 8807, ISO, 1989 [Jon 86] Jones, C.: Systematic Program Development Using VDM, Prentice Hall, 1986 [JSHS 96] Jungclaus, R., Saake, G., Hartmann, T., Sernadas, C.: TROLL - A Language for Object-Oriented Specification on Information Systems. ACM Transact on Inf. Syst., 14(2), pp. 175-211, 1996 [Kla 99] Klar, M.: A Semantical Framework for the Integration of Object-Oriented Modeling Languages, PhD-thesis, Techn. Univ. Berlin, July 1999 [LCGH 93] Lindemann, C., Ciardo, G., German, R., Hommel, G.: Performability modeling of an automated manufacturing system with deterministic and stochastic petri nets. In Proc. 1993 IEEE Int. Conf. on Robotics and Automation, Atlanta, GA, pp. 576-581. IEEE Press, May 1993 [MBD 98] Marsan, M. A., Bobbio, A., Donatelli, S.: Petri nets in performance analysis: An introduction. Vol. 1491, pp. 211-256, Springer-Verlag, 1998 [Mes 92] Meseguer, J.: Conditional rewriting logic as a unified model of concurrency. TCS, 96:73-155, 1992 [Mil 89] Milner, R.: Communication and Concurrency, Prentice-Hall, 1989 [MK 98] Mann, S., Klar, M.: A metamodel for object-oriented statecharts. Proc. 2nd Workshop on Rigorous Object-Oriented Methods, ROOM 2, Bradford, May 1998 [MP 92] Manna, Z., Pnueli, A.: The Temporal Logic of Reactive anc Concurrent Systems, Specification. Springer-Verlag, 1992 [MW 98] Müller, H., Weber, H., editors: Continuous Engineering of Industrial Scale Software Systems. IBFI, Schloss Dagstuhl, Dagstuhl Seminar Report # 98092, 1998 [Obe 90] Oberweis, A.: Zeitstrukturen für Informationssysteme. PhD-thesis, Univ. Mannheim, 1990

- 17 -

[PER 95]

Padberg, J., Ehrig, H., Ribeiro, L.: Algebraic High-Level Net Transformation Systems, MSCS 5 (1995), pp. 217-256 [PPP 91] Parisi-Presicce, F., Pierantonio, A.: An Algebraic Approach to Inheritance and Subtyping. Proc. ESEC 1991, Springer LNCS 550, 1991, pp. 364-379 [Rei 85] Reisig, W.: Petri Nets. EATCS Monographs in TCS 4, Springer Verlag, 1985 [Rei 89] Reisig, W.: Linear time and branching time logic for partial order semantics. In REXSchool, Nordwijkerhout, vol. 354 of LNCS, pp. 603-627. Springer-Verlag, 1989 [Rib 95] Ribaudo, M.: On the Relationship between Stochastic Petri Nets and Stochastic Process Algebras. PhD-thesis, Univ. of Torino, 1995 [Roz 97] Rozenberg, G. (ed.): Handbook of Graph Grammars and Computing by Graph Transformation, World Scientific, 1997 [RR 97] Rational Rose Software Corporation. UML Notation, Version 1.1. 1997 [Ser 91] Sernadas, A. et al.: OBLOG - Object-oriented Logic: An Informal Introduction. Techn. Report, INESC, Lisbon, 1991 [SG 96] Shaw, M., Garlan, D.: Software Architecture - Perspectives on an Emerging Discipline. Prentice Hall, 1996 [Spi 92] Spivey, J.M.: The Z Notation: a Reference Manual. Prentice Hall, 1992 [Z 120] Z.120.ITU-TS Recommendation Z120: Message Sequence Chart (MSC). ITU-TS, Geneva, 1996

- 18 -