guide to express{p

GUIDE TO EXPRESS{P Wolfgang Mueller Cadlab Bahnhofstr. 32 33102 Paderborn Germany

Winfried Felser Heinz Nixdorf Institut Warburgerstr. 100 33098 Paderborn Germany



Frank Buijs Cadlab Bahnhofstr. 32 33102 Paderborn Germany

Abstract

In this paper we present EXPRESS{P, an extension of EXPRESS for process modeling and monitoring. Our extension inherits concepts of the formal languages SDL (CCITT Standard), Estelle (ISO Standard), and GRAPES{86. EXPRESS{P comes with a graphical representation which covers the process modeling. The language is presented in syntactical detail. A nal example sketches the modeling of a client{server communication.

1 INTRODUCTION

EXPRESS [13] has been de ned as a data speci cation language for data exchange and representation within STEP (STandard for the Exchange of Product Model Data). Basically, EXPRESS follows the concepts of the classical Entity-Relationship approach enhanced by object-oriented features and by means for the speci cation of consistency rules (global/domain rules, derived attributes). As the data speci cation language EXPRESS has nally been accepted for International Standard (IS), the present EXPRESS standardisation eorts focus on an edition 2 of EXPRESS. A signi cant change for EXPRESS edition 2 will be the extension of the language for the explicit modeling of behavior. In this article we present EXPRESS{P, a pragmatic approach dedicated to process modeling and monitoring. Basically, EXPRESS{P is a combination of EXPRESS with the basic concepts of the CCITT Standard Z.100 SDL [3] and the ISO International Standard 9074 Estelle [12]. The graphical representation is inherited from GRAPES{86 [11]. The support of these process modeling concepts opens the application of EXPRESS{P to other domains like telecommunications, protocol speci cation, and general systems design. We have designed EXPRESS{P as a language fully compatible to the EXPRESS/IS and its instantiations by STEP Physical Files [14]. The remainder of this paper is organized as follows. Section 2 gives an overview of the related approaches and introduces the languages we inherited our concepts from. In Section 3 we introduce the language EXPRESS{P including the graphical means for EXPRESS{P (System and Process Diagrams). Additionally, the instantiation of an EXPRESS{P model is sketched. In Section 4 we give an example by modeling a simple client{server communication using EXPRESS{P. For an additional EXPRESS{P example, the reader is referred to [7, 8] which presents an injection molding process.  Published in:

Proceedings of the EUG'94, October 13{14, 1994, Greenville, SC, US Pro, Gaithersburgh, 1995

1

2 RELATED APPROACHES

The application of EXPRESS and extensions for behavioral modeling were frequently discussed. Several modelers from automotive, aerospace, and other industries require behavioral extensions in the next edition of EXPRESS. At present we can identify three major trends for such extensions. Firstly, there are works for an EXPRESS extension by the means of an C++{oriented approach [15, 10]. Secondly, in the context of database applications, the pragmatic approach EXPRESS{C [18, 17] has been developed in the PISA project. In contrast to these approaches, our extension comes as a concurrent process speci cation language based on the basic concepts of the CCITT Standard Z.100 SDL [3] and the ISO International Standard 9074 Estelle [12]. We found that these frequently used languages provide adequate and well{approved concepts for the process modeling domain since they provide means for the explicit representation of concurrent systems. The strong relationship of EXPRESS{ P to SDL, Estelle, and GRAPES{86 greatly supports the migrationof already existing SDL, Estelle, and GRAPES{86 models and thus opens the application of EXPRESS{P to other domains like telecommunications, protocol speci cation, and general systems design. In the remainder of this section we outline the basic concepts of these languages.

2.1 SDL (Speci cation and Description Language)

SDL has been de ned as a textual language (SDL-PR) which comes with a graphical counterpart (SDL-GR). SDL has already been used for de ning telecommunication standards but it is also well applicable for other domains such as electronic systems design. SDL is a state-oriented language de ning a system as a set of concurrently running sequential processes asynchronously communicating via shared channels. Dierent diagrams support dierent views of the system. Block Interaction Diagrams (BDs) represent a hierarchical structural view of the communicating objects, whereas Sequence Charts (SCs) and Process Diagrams (PDs) represent a behavioral view. SCs de ne the Input/Output behavior of a process. A PD speci es the imperative behavior of a process, i.e., sending, receiving messages, and performing actions. EXPRESS{P inherits its basic asynchronous communication concepts and basic behavioral concepts including timing from SDL. In addition to SDL, EXPRESS is enhanced by a non-blocking receive statement.

2.2 Estelle

Since an SDL object may have at most one interface de nition we inherit the more exible concepts de ning multiple interfaces for each object from Estelle1 . Since Estelle is very similar to SDL, the concepts of Estelle also compare well to the concepts of EXPRESS{P. Estelle is applied within the ISO for the de nition of ISO/OSI transport protocols.

2.3 GRAPES{86

GRAPES{86 [11] is a graphical description language for information systems. For a further introduction the reader is referred to [6]. The basic behavioral concepts of GRAPES{86 are mainly inherited from SDL. GRAPES{86 can be seen as the main contributor to the EUROMETHOD standardization eorts within the European standardization body CENELEC. Like EXPRESS{P, GRAPES{86 provides means for data and process speci cation. Data can be speci ed by the means of Data Diagrams (DDs) and Entity-Relationship Diagrams. Behavior 1 The concept of multiple interfaces (contracts) can also be found in the object-oriented design methodology of Wirfs-Brock et al. [19]

2

can be speci ed by Communication Diagrams (CDs) and Process Diagrams (PDs). CDs de ne a static communication structure of a system, i.e., objects and communication channels between these objects. A CD object may be recursively speci ed by the means of a CD or by a PD. A PD represents the local view of a sequential process sending and receiving synchronous and asynchronous messages from other processes. EXPRESS{P basically inherits the CommunicationDiagrams and Process Diagrams from GRAPES{ 86. The basic dierence between Communication Diagrams and the later introduced EXPRESS{P System Diagrams is that System Diagrams represent the communication structure between types and not between instances. This modi cation was necessary since in contrast to GRAPES{86 EXPRESS{P de nes dynamic communication structures.

3 EXPRESS{P

In this section we introduce the basic concepts, syntax, and graphical representation of EXPRESS{ P. We present the syntactical changes to EXPRESS which are required for our extension as well as the extensions themselves (see also Appendix A). The numbering of the grammar rules which are modi ed for the integration of EXPRESS{P is taken from one of the latest EXPRESS documents and should be close to the numbering of the nal EXPRESS/IS document. The syntactical rules newly introduced for EXPRESS{P are preceeded by P01{P48. In these rules the nonterminals which derive to keywords are emphasized by capital words without further derivation.

3.1 General Concepts

EXPRESS{P is an upward compatible extension of EXPRESS and therefore it is fully integrated into the concepts of EXPRESS and its related standards. In this paper we only concentrate on the syntax and the concepts of the extensions rather than on the concepts of EXPRESS. Thus, the reader should be familiar with EXPRESS. For an introduction to EXPRESS the reader is referred to the EXPRESS language reference manual [13] or to the introduction given by Schenck and Wilson [16]. While EXPRESS is mainly dedicated for structural speci cations and their associated data including constraints, EXPRESS{P additionally introduces the speci cation of hierarchical communication structures between processes as well as the basic behavior of a process, i.e., basically sending and receiving data. In EXPRESS{P, static entities may become dynamic entities representing a network of communicating sequential processes. In this context, a dynamic entity can be either a complex (sub)system or a basic process. Systems and processes may have interfaces in order to communicate with other systems or processes, respectively. A system speci es a communication structure. Within a system de nition entities are connected by communication channels performing an asynchronous communication. The channels can only be de ned between entities with a relationship to the entity representing the system. Since a relationship may be an aggregate and since operations on aggregates are de ned, EXPRESS{P covers the speci cation of dynamic communication structures, i.e., processes or subsystems can be dynamically created. A process de nes the behavior by sequential statements sending and receiving messages (signals) to/from other processes. EXPRESS{P supports the waiting (blocking) and non-waiting (nonblocking) receive of signals. These extensions are additionally assigned to an EXPRESS entity declaration. Syntactically, the entity body is extented by an additional behavioral section (behavior body): 3

Syntax: 194 entity_body = {explicit_attr} [derive_clause] [inverse_clause] [unique_clause] [where_clause] [behavior_body].

This extension covers the already discussed speci cation of interfaces, channels, or processes. The speci cation of a dynamic entity may include either a speci cation of communication channels or the speci cation of a single process. For the speci cation of local behavior some methods may be assigned to an entity. The methods are functions and procedures which follow the visibility rules of local attributes, i.e., they are not visible in the global scope of a schema.

Syntax: P01 behavior_body = [interfaces] [methods] [channels | process | explicit_reference].

In the following subsections we rst present the various lexical EXPRESS{P language constructs. Thereafter we introduce the complementary graphical notation for each construct, i.e., System Diagrams and Process Diagrams.

3.2 The EXPRESS{P Language 3.2.1 Methods

The method clause introduce functions and procedures which are only visible in the scope of the enclosing entity.

Syntax: P25 methods = {procedure_decl | function_decl}.

Methods may be inherited and redeclared corresponding to the general rules of EXPRESS attribute inheritance and redeclaration. For this the following EXPRESS grammar rules require a modi cation. Two further rules have to be added in order to permit a quali cation of function and procedure identi ers.

Syntax: 210 260 P32 P33

function_id = simple_id | qualified_function. procedure_id = simple_id | qualified_procedure. qualified_function = SELF group_qualifier '.' function_ref. qualified_procedure = SELF group_qualifier '.' procedure_ref.

For procedure and function calls the EXPRESS grammar has to be extented in order to allow the quali cation of procedures and functions. This requires the procedure call statement and the 4

derivation of quali ers to be modi ed.

Syntax: 207 function_call_stmt = (built_in_function | (function_ref | (referenced_attribute {qualifier})) [actual_parameter_list]. 251 procedure_call_stmt = built_in_procedure | (procedure_ref | (referenced_attribute {qualifier}) [actual_parameter_list]. 263 qualifier = func_proc_qualifier | attribute_qualifier | group_qualifier | index_qualifier. P12 func_proc_qualifier = '.' (procedure_ref | function_ref ).

Example Consider a procedure declared in entity e2. This procedure is accessible in the scope of entity e1 via the attribute a if a is of type e2. ENTITY e1; a : e2; ... a.p(0); ... END_ENTITY;

ENTITY e2; ... PROCEDURE p (arg1: INTEGER;); ... END_PROCEDURE; ... END_ENTITY;

3.2.2 Interfaces

All dynamic entities (systems and processes) may have a set of communication interfaces. An interface declaration is enclosed by the keywords "INTERFACES" and "END INTERFACES". An interface declaration de nes an interface identi er and a (possibly empty) set of signals which are receiveable via this interface. The input signals are enumerated following the keyword "WITH". Each signal may be speci ed as a carrier of data by specifying the data types or set of carried data types, respectively. The scope and the visibility of interface identi ers are equal to attributes. Thus, an interface identi er may be in con ict with an attribute identi er. Interfaces may be redeclared to the rules of attributes but neither a generalization nor a spezialization for this redeclaration is being de ned at present, i.e, the redeclaration overwrites the declared signals in any case. The scope and visibility of signals are local to the corresponding interface. The visibility of a signal is propagated by a channel declaration. A channnel declaration connects a pair of interfaces and makes the signals visible to each of the interfaces.

Syntax: P20 P19 P22 P23 P33 P39 P48

interfaces = INTERFACES interface {interface} END_INTERFACES ';'. interface = interface_decl [signal_decl] ';'. interface_decl = interface_id | qualified_interface. interface_id = simple_id. qualified_interface = SELF group_qualifier '.' interface_ref. signal_decl = WITH signal_id [type_spec] {',' signal_id [type_spec]}. type_spec = '(' base_type {',' base_type} ')'.

5

Example INTERFACES interface1 WITH interface2 WITH END_INTERFACES;

s1, s2(INTEGER); s1;

In this example the interfaces interface1 and interface2 are declared. Via these interfaces the entity in which scope this declaration is enclosed may receive three signals: s1 and s2 from interface1 and s1 from interface2. When receiving s2, this signal delivers an integer value. Since the identi ers of signals are local to the scope of the individual interface declaration statement, in the above example, the signal s1 in the rst declaration denotes a signal dierent from that of the second declaration.

3.2.3 Systems and Subsystems

Entities representing a system or a subsystem de ne the communication structure by de ning communication links (channels) between its subentities (related entities). Subentities are denoted by local attributes which shall evaluate to an entity type or to an aggregation of an entity type. The keyword "SELF" denotes a channel to an own interface, e.g. SELF.interface1.2 This is also denoted as an external interface in the remainder of the paper. The enumeration of channel declarations are enclosed by the keywords "CHANNELS" and "END CHANNELS".

Syntax: P06 P03 P05 P04 P31 P06 P21

channels = CHANNELS bundle {bundle} END_CHANNELS ';' . bundle = [bundle_id_def ':'] channel {',' channel} ';'. bundle_id_def = bundle_id | qualified_bundle. bundle_id = simple_id. qualified_bundle = SELF group_qualifier '.' bundle_ref. channel = interface_channel_ref direction interface_channel_ref. interface_channel_ref = (SELF | attribut_ref | qualified_attribute) '.' ( interface_ref | qualified_interface). P08 direction = '' | '->' | ' 0); INPUT SIGNAL Sinterface.suspended: count := count-1; END_INPUT; END_REPEAT; s_state:=nextState(s_state); END_REPEAT; END_PROCESS; -----------------------------------------END_ENTITY;

ENTITY: SERVER

PD

Sinterface.activate s_state count := HIINDEX(SYSTEM.C)

count > 0 false

s_state:=nextSstate(s_state)

true

Sinterface.suspended

count := count −1

15

4.2 Instantiation

As already indicated, an EXPRESS{P program is initialized by a STEP Physical File. A possible initialization of the presented example might be de ned by the following instances. #1 #2

= SYSTEM(#10,(#100, #101, #102)); = SYSTEM(#11,(#110, #111));

#10 #11

= SERVER(9999); = SERVER(8888);

#100 #101 #102 #110 #111

= = = = =

CLIENT(0); CLIENT(0); CLIENT(0); CLIENT(0); CLIENT(0);

These instances de ne two client{server systems, i.e., #1 and #2. The rst system associates server #10 with three clients whereas in the second system server #11 has two clients. The attribute of the rst server is initialized by 9999. The attribute of the second server is initialized by 8888. With respect to its compliance with the upcoming ISO 10303-21 standard interfaces, channels, and processes are not represented in the Physical File Format.

5 CONCLUSION

In this paper we presented EXPRESS{P. EXPRESS{P is an extension of ISO 10303-11 for process modeling compliant to ISO 10303-11 (EXPRESS) and ISO 10303-21 (Physical File Format). We have de ned the concepts of EXPRESS{P based on the well-established standard languages SDL and Estelle. The EXPRESS{P diagrams are inherited from GRAPES{86. An implementation of EXPRESS{P should be achievable with little eort since the same basic communication concepts are provided by PVM 3.2 [9]. PVM (Parallel Virtual Machine) is the present defacto standard for the portable implementation of distributed applications. It provides a high-level C and Fortran interface for applications on a parallel virtual machine supporting over 28 dierent types of machines. The close relationship of EXPRESS{P statements to PVM primitives results in a well-de ned semantics of the EXPRESS{P. That is, since a formal de nition for EXPRESS{P can be easily derived from the formal semantics of PVM de ned by Borger and Glasser [2] or by the formal semantics of Estelle de ned by Courtiat [4]. This makes formal analysis applicable to EXPRESS{P models. EXPRESS{P is a pragmatic approach for achieving a process modeling language from the data speci cation langauge EXPRESS. We already demonstrated in [7, 8] that the language provides an adequate extension of EXPRESS applicable for industrial application in the eld of manufacturing processes. Moreover, EXPRESS{P is applicable for general systems design and speci cation since most concepts are inherited from SDL or GRAPES{86, respectively. Nevertheless, the minimal extension presented in this paper is still open for further improvements. Some signi cant work on the clear de nition of the concepts of redeclaration, i.e., suitable generalization concepts, still have to be done. It is of further importance to think about exception handling concepts being introduced to EXPRESS{P.

16

ACKNOWLEDGEMENTS

We acknowledge the valuable comments received from Franz Rammig, Bernd Steinmuller as well as the members of the DIN/EXPRESS working group when reviewing this work. Uschi Hudson has reviewed the nal paper. We appreciate the contribution of Norbert Wiechers, Markus Eusterfelhaus, and Holger Aisch in the implementation of the EXPRESS{P language analyzer as well as the underlying EXPRESS ISO/DIS checker ICE. We gratefully acknowledge the funds received by the ESPRIT project #8370 ESIP (EDA Standards Integration and Promotion).

References

[1] Belina, F., Hogrefe D., and Sarma, A., \SDL with Applications from Protocol Speci cation," Prentice Hall Int., Hertfordshire, UK, 1991. [2] Borger, E., and Glasser, U., \A formal speci cation of the PVM architecture," in B. Pehrson and I. Simon, eds., IFIP 13th World Computer Congress 1994, Volume I: Technology/Foundations, Elsevier, Amsterdam, 1994. [3] CCITT Z.100, CCITT Recommendation Z.100: Speci cation and Description Language SDL (Blue Book, Volume X.1 -X.5). CCITT General Secretariat, Places des Nation, Geneva, Switzerland, 1988. [4] Courtiat, J.-P., \A PETRI NET BASED SEMANTICS FOR ESTELLE," in M. Diaz, J.-P. Courtiat, P. Azema, V. Chari, eds., THE FORMAL DESCRIPTION TECHNIQUE ESTELLE, North-Holland, Amsterdam, 1989. [5] Dangelmaier, W., Schneider, U., and Gerdes, K.-H., 1993, \F&QLS Modellierung einer Spritzgiefertigung," (in German) Working Paper, Heinz Nixdorf Institut, Paderborn, Germany, 1993. [6] Duschl, R., and Hopkins, N.C., 1992, \SSADM & GRAPES | Two Complementary Major European Methodologies for Information Systems Engineering," Springer-Verlag, Berlin, 1992. [7] Felser, W., and Mueller, W., \EXPRESS{P | Eine Erweiterung von ISO 10303-11 zur Verhaltensmodellierung," (in German) in Proceeding of the CAD94, Paderborn, March 17-18, 1994, Carl Hanser Verlag, Munich, Germany, 1994. [8] Felser, W., and Mueller, W., \EXPRESS{P | EXTENDING EXPRESS FOR PROCESS MODELING AND MONITORING", In the Proceedings of the 1994 ASME Computers in Engineering Conference, Minneapolis, MI, Sept. 11-14, 1994. [9] Geist, A. et al., \PVM 3.0 User's Guide Reference Manual," Technical Manual ORNL/TM-12187, Oak Ridge National Laboratory, Oak Ridge, Tennessee, Feb. 1993. [10] Genderka, M., and Schroeder, G., \EXPROO," (in German) Technical Report, Heinz Nixdorf Institut, Paderborn, Germany, Aug. 1994. [11] Held, G., \Sprachbeschreibung GRAPES," Siemens AG, Berlin, Germany, 1990. [12] ISO 9074, 1991, IPS - OSI - ESTELLE - A Formal Description Technique based on an extended state transition model - ISO 9074. ISO/TC97/SC21, 1991. [13] ISO 10303-11, \EXPRESS Language Reference Manual," Document N 151, ISO DIS 10303-11, National Institute of Standards and Technology, Gaithersburg, USA, 1992. [14] ISO 10303-21, \Product Data Representation and Exchange - Part 21: Clear Text Encoding of the Exchange Structure," ISO DIS 10303-21, National Institute of Standards and Technology, Gaithersburg, USA, 1993. [15] Salisch, A., and Beck, S., \EXPRESS and Object Orientation | An approach to a solution," Technical Report, FhG/IPK Berlin, Berlin, Dec. 1993. [16] Schenk, D.A., and Wilson, P.R., \Information Modeling the EXPRESS Way," Oxford University Press, 1994.

17

[17] Schonefeld, F., Staub, G., Maier, M., and Musto, A., \Multiple Class Membership and Supertype Constraint Handling { Concepts and Implementation Aspects", In the Proceedings of the 4th Annual EXPRESS User Group International Conference, Greenville, SC, Oct. 13-14, 1994. [18] Staub, G., \PISA Information Modeling Language: EXPRESS{C," Technical Report, RPK Karlsruhe, Karlsruhe, 1994. [19] Wirfs-Brock, R., Wilkerson, B., and Wiener, L., \Designing Object-Oriented Software," Prentice-Hall, Inc., Englewood Clis, NJ, 1990.

A EXPRESS{P Syntax

A.1 Modi cations in EXPRESS Grammar

177 built_in_constant = PI | CONST_E | SELF | '?' | NOW. 189 declaration = entity_decl | function_decl | procedure_decl | type_decl | external_behavior_decl. 194 entity_body = {explicit_attr} [derive_clause] [inverse_clause] [unique_clause] [where_clause] [behavior_body]. 207 function_call_stmt = (built_in_function | (function_ref | (referenced_attribute {qualifier})) [actual_parameter_list]. 210 function_id = simple_id | qualified_function. 239 local_decl = LOCAL (local_variable | timer_decl) {local_variable | timer_decl} END_LOCAL ';' . 251 procedure_call_stmt = built_in_procedure | (procedure_ref | (referenced_attribute {qualifier})) [actual_parameter_list]. 260 procedure_id = simple_id | qualified_procedure. 263 qualifier = func_proc_qualifier | attribute_qualifier | group_qualifier | index_qualifier. 291 stmt = alias_stmt | assignment_stmt | case_stmt | compound_stmt | escape_stmt | if_stmt | null_stmt | procedure_call_stmt | repeat_stmt | return_stmt | skip_stmt | input_stmt | output_stmt | timer_stmt | terminate_stmt.

A.2 Extensions to EXPRESS Grammar P01 P02 P03 P04 P05 P06 P07 P08 P09 P10 P11 P12 P13 P14 P15 P16 P17 P18 P19

behavior_body = [interfaces] [methods] [channels | process | explcit_reference ]. behavior_head = BEHAVIOR FOR entity_ref {',' entity_ref} ';'. bundle = [bundle_id_def ':'] channel {',' channel} ';'. bundle_id = simple_id. bundle_id_def = bundle_id | qualified_bundle. channel = interface_channel_ref direction interface_channel_ref. channels = CHANNELS bundle {bundle} END_CHANNELS ';' . direction = '' | '->' | '