Issued by the WP1 Team. Prepared by. Georg Lehrenfeld, Paderborn University

Transcription

1 ESPRIT Project in Condence ESPRIT Project 2072 ECIP2 European CAD Integration Project Issued by the WP1 Team Prepared by Georg Lehrenfeld, Paderborn University Wolfgang Mueller, Cadlab Translation of EXPRESS to a Logical Programming Language Deliverable R-C A ECIP2/PU/013-2 August 24, 1992 (c) Copyright 1992 Bull S.A., International Computer Ltd, Siemens Nixdorf Informationssysteme AG, Nederlandse Philips Bedrijven B.V., Racal-Redac Ltd., Siemens AG, Thomson-CSF, Universitaet-GH Paderborn. This document and the information contained herein may not be copied, used or disclosed in whole or in part except with prior written permission of the partners as listed above. The copyright and the foregoing restriction on copying, use and disclosure extend to all media in which this information may beembodied, including magnetic storage, computer print-out, visual display, etc.. The document is supplied without liability for errors or omissions.

2 Title of Deliverable Translation of EXPRESS to a Logical Programming Language Deliverable No. R:C A Brief Description In this report a translation from STEP and EXPRESS to Prolog is given in order to get executable STEP/EXPRESS models. Partner(s) Responsible Cadlab - Paderborn University Estimated work content 1 man-month Date August 24, 1992 Workpackage Name of Review Comments Partner reviewer

3 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS... 1 Abstract Considering ISO two substandards are dened. Part 11 de- nes the EXPRESS language [1] whereas part 21 denes the STEP Exchange structure [2], a format to exchange instances of product data. In this report a method is described to translate EXPRESS as well as STEP denitions to a logical programming language, namely Prolog. This translation is the rst step towards the generation of executable models out of EXPRESS models so that instances can be checked against the according conceptual model. The method to translate EXPRESS and STEP to Prolog was developed with respect to generate readable code so that even users that have no Prolog knowledge may still keep the overview over the produced code. The programming language Prolog has been chosen since on the one hand Prolog is a language for rapid prototyping and on the other hand the main checks that have to be done by a model checker are solved best by using Prolog.

4 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS... 2 Contents 1 Introduction 3 2 Introduction to Prolog 4 3 Translating the STEP Exchange Structure Translation Rules : : : : : : : : : : : : : : : : : : : : : : : : : : : Examples : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 6 4 Translating the EXPRESS Language Translation Rules : : : : : : : : : : : : : : : : : : : : : : : : : : : Examples : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Aggregate Types : : : : : : : : : : : : : : : : : : : : : : : Types : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Entities : : : : : : : : : : : : : : : : : : : : : : : : : : : : Super/Subtype Relationships : : : : : : : : : : : : : : : : Rules : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Complete Example : : : : : : : : : : : : : : : : : : : : : : 11 5 Conclusion 12

5 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS Introduction The purpose of this report is to develop a technique to check conceptual models by their instances. The work was done with respect to the former results of WP1 [3] that have been achieved until 1990 Within the present context of WP1 this means to validate instances dened by the STEP Exchange Structure (ISO )[2] towards the according conceptual model dened by the EXPRESS language (ISO )[1]. This is, to check the consistency among instances and the completeness and the consistency of the conceptual model itself. A model checker supports the prototyping of conceptual models so that the models may be easily improved and enhanced. For further introduction the reader is referred to [2], [1], [4], and [5]. In order to achieve an executable specication out of the EXPRESS specication we translate both the EXPRESS language model and the product models to C-Prolog. We took C-Prolog since the C-Prolog interpreter is public domain software. The portation of the generated C-Prolog code to other Prolog dialects might be no problem. Running the generated code on an IF/Prolog 1 interpreter for instance means only to change the identiers of two predened predicates. We havechosen Prolog in general since we found that a lot of problems occurring during the validation are solved best by the use of a logic programming language. This is, because most of the properties that have tobechecked relate to the checking of set inclusions and logical relationships. Furthermore Prolog eases the implementation by the processing of symbolic data and meta programming. Using Prolog for prototyping means to focus the interest on the checking process rather than on the implementation. The mapping to Prolog we describe herein is in most parts nearly a most simple one to one mapping, so that the produced code is even readable by an user who has no knowledge about Prolog. The translation from EXPRESS to Prolog is in general only a restructuring of the EXPRESS model whereas the translation from STEP to Prolog is in most cases only a very simple one to one mapping exchanging single symbols only. This means, that cross-compilers for both of the two languages to Prolog are most easy to implement. The translation to Prolog is developed with respect to further implementation of a model checker that has to be implemented processing the mapped code and to give error reports for each consistency fail. In order to make the translated code understandable for non-prolog experts a brief introduction to Prolog will be given in the next chapter. In the further two chapters the mapping from STEP and EXPRESS to Prolog will be given by detailed examples. However, the process concerning the consistency check, i.e. to identify what properties have to be checked on the EXPRESS and STEP models, are not covered by this deliverable. It will be described in a further deliverable giving detailed examples [5]. 1 IF/Prolog is a Trademark of InterFace Computer GmbH

6 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS Introduction to Prolog The basic data structure of Prolog is a term. A term may be either an atom, an integer, a variable, a list, or a predicate. An atom is either a sequence of characters starting by alower case letter or any string included by the character " ' ".For example, tom and 'TOM' are atoms but TOM is not an atom. An integer is any sequence of digits, e.g. 123 and 007 are integers. A variable is a sequence of characters starting by an upper case letter or an underline. For example, Tom and tom are variables. A predicate has the following form: functor(term 1,..., Term n ), where functor has to be an atom. A list is an enumeration of terms separated by a comma included by brackets: [Term 1,..., Term n ]. A Prolog program is a nite set of Horn Clauses. A Horn Clause is also called a rule in Prolog and has the following form: H :, B 1 ; :::; B n : H is called the head of the rule and the B i are called the body goals - or just body - of the rule. H and the B i both have to be predicates. A rule with no body goals is called a fact: H:. To initiate a computation the user has to specify a question to the Prolog system. This question only species the body goals that have to be fullled. This is, a rule with no head: :- B. Note, that several Prolog interpreters got a question mode where the ':-' is automatically given by the ssystem, if the user is permitted to enter a new question. In some systems the ':-' then is replaced by '?,'. If the user enters a question the system tries to proof this question applying the given rules and facts by unication and backtracking.

7 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS Translating the STEP Exchange Structure In this section rst a translation of the basic STEP terms is given before the general translation rules are explained. Thereafter we will give some examples how to apply these rules. 3.1 Translation Rules Since STEP is structured in a very simple way translating basic STEP terms to Prolog nearly means to exchange single symbols as it is shown by the following table. STEP Prolog Integer Real real(9.432) String 'ABC' 'ABC' Boolean.F.,.T. e F e, e T e, Logical.F.,.T.,.U. e F e, e T e, e U e Binary "2EC" binary('2ec') Enumerations.BLONDE. e BLONDE e Optional value $ Instance Id #3 id(3) Name abcd abcd List (a1, A2, a3) [a1, a2, a3] Delimiter ;. For the translation of the general format each STEP instance is translated to one Prolog fact. The most practical way to save the instance identier is to take it as a rst argument in each Prolog fact. Scoped instances are simply represented by one fact containing a list of the particular instances. Inherited attributes are represented in STEP by so-called external and internal mappings. Applying an internal mapping means that the attributes of an entity are concatenated to the inherited attributes recursively. This is, how inheritance of ONEOF relationships should be represented. Applying an external mapping means that inherited attributes are represented as instances of the entity type they are inherited from but not indicated by a separate instance identier. The externally mapped inherited attributes are then gathered in a set indicated by one unique identier only, e.g. #34 = ( PERSON(... ) FEMALE(... )); External mappings are applied if the subtypes are related by AND and ANDOR.

8 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS... 6 The general translation rules can be summerised by the following table. Instance! Prolog fact Instance identier! rst argument of the Prolog fact Attribute list! Prolog list Scoped instance! Prolog fact External mapping! same instance identier 3.2 Examples The above translation rules are explained by the following examples. By rst two instances (#2, #4) a simple mapping of attribute values is shown. The translation of instance #6 explains the translation of scoped instances whereas instance #100 explains how external mappings may be represented in Prolog. STEP Prolog #2=MALE('W.P.',(11,10,60), male(2,'w.p.',[11,10,60],.white.,(#4)); e white e, [id(4)]). #4=MALE('Phil',(25,5,89),$,()); male(4,'phil',[25,5,89],, []). #6 =&SCOPE entity1(6, scope(export([61]), #61=ENTITYA('A1',$,()); [entitya(61,'a1',,[]), #62=ENTITYB('B2',$,()); entityb(62,'b2',,[]), #63=ENTITYC('C3',$,()); entityc(63,'c3',,[]) ENDSCOPE /#61/ ]), ENTITY1(#61,#62,#63); id(61), id(62), id(63)). #100=( FIRST('ABC',25) First(100, 'ABC',25). SECOND('DEF', 27)); Second(100, 'DEF',27).

9 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS Translating the EXPRESS Language 4.1 Translation Rules In this section we describe how to translate EXPRESS denitions to Prolog. The most problematical part translating full EXPRESS denitions to Prolog is denitely the translation of executable EXPRESS statements. These are, function/procedure declarations as well as the statements that are dened in the local and global rules. The problem is that obviously not a simple mapping can be applied to translate imperative statements to a logical programming language whereas the declarative parts as well as some predened EXPRESS predicates are much more easier to translate as it will be shown by an example in section Base types are translated by a simple one to one mapping to Prolog. The EX- PRESS keyword 'optional' is simply translated to a Prolog predicate as it is shown by the following table. EXPRESS Prolog Base types string string integer integer real real boolean boolean logical logical boolean boolean binary binary Dened types mytypeidentier mytypeidentier Optional optional optional (... ) Aggregates and enumerations are translated to predicates over the lower/upper bound and the according type name or the enumerations of the type names, respectively. Each type denition is mapped to one Prolog fact. Each EXPRESS entity denition is separately mapped to two Prolog predicates. One predicate is gathered in a list called list of ids whereas the other one is gathered in a second list: list of types. The rst predicate preceded by the entity type name is an enumeration of the attribute identier in the same sequence as they are dened in the EXPRESS entity denition. The second predicate represents the according enumeration of the attribute types. To each entity predicate an additional rst argument has to be added in order to keep the instance identier for checking purpose applying a checking program. The instance identier is of type integer. Therefore the rst argument of each entity predicate that is inserted in list of types is integer. For each entity one additional Prolog fact named supertype rule is generated to describe the supertype relationship. The general translation rules are summerised by the following table.

10 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS... 8 Dened type! one Prolog fact Entities! gathered in 2 lists Subtype relationship! one Prolog fact for each entity 4.2 Examples Aggregate Types Each aggregate type is translated to a corresponding predicate. The rst two arguments represent the lower and upper bound. The third argument denotes the type. EXPRESS Prolog OPTIONAL ARRAY[1:3] OF REAL optional(array(1,3, real)) LIST[0:5] OF ARRAY[1:3] OF INTEGER SET[1:3] OF point list(0,5,array(1,3,integer)) set(1,3, entity(point)) BAG[0:?] OF bag type bag(0,'?', bag type) Types Enumeration and select types are mapped to one predicate each. In principle this is nearly a one to one mapping. In the last row of the following example the translation of a full EXPRESS type denition is shown. The rst argument represents the name of the type the second argument denotes the type it is composed of. EXPRESS Prolog ENUMERATION OF (blonde, enum([e blonde e, brown, e brown e, black) e black e]) SELECT(type1, type2) select([type1, type2]) TYPE date=array[1:3] OF INTEGER; END TYPE; type(date,array(1,3,integer)) Entities As already described above each entity denition is separated by attribute types and attribute identiers in the sequence as the attributes appear in the EX- PRESS denition. The separated denitions are collected in two lists in two

11 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS... 9 dierent Prolog facts: list of ids and list of types. To ease the implementation of a STEP/EXPRESS checker an additional predicate is added to each entity predicate to keep instance identiers. Therefore the rst argument of each predicate in list of ids is id and in list of types is integer. EXPRESS Prolog ENTITY entity1; list of ids( type11 : OPTIONAL INTEGER; [entity1(id,type11,type12), type12 : entity3; entity2(id,type2), entity3(id,type3) ]). ENTITY entity2; list of types( type2 : SET[0:?] OF entity1; [entity1(integer, optional(integer), entity(entity3)), ENTITY entity3; entity2(integer,set(0,'?', type3 : my type; entity(entity1))), entity3(integer,my type) ]) Super/Subtype Relationships For each entity one additional Prolog fact named supertype rule has to be generated to describe the supertype relationship. The rst argument represents the identier the rule refers to. An additional predicate indicates whether there may exist instances of this entity type (abstract) or not. The second argument denotes the according subtypes and how the instances are related (oneof, and, andor). If there does not exist any subtypes the second parameter is simply set to nil. EXPRESS ENTITY root ABSTRACT SUPERTYPE OF (ONEOF(sub1, sub2)); ENTITY sub1 SUBTYPE OF (root); ENTITY sub2 SUBTYPE OF (root); Prolog supertype rule(entity(abstract(root)), oneof(entity(sub1), entity(sub2))). supertype rule(entity(sub1), nil). supertype rule(entity(sub2), nil).

12 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS Rules Since translating the executable parts (local/global rules, derived attributes) of EXPRESS means already to implement the checker we only give a brief example in this section to indicate that the translation to Prolog makes sense for the logical parts within the executable statements. In the following example a local rule dening only logical relationships between attributes is translated to Prolog. This example shows that in this case the code produced from EXPRESS rules is not easy to understand for non-prolog experts though it is only a simple EXPRESS example and there is a direct relationship between the EXPRESS and the Prolog code as it is indicated by underlining. This example also shows that the problem of the mapping of executable parts of EXPRESS needs further investigation if some general translation rules should be developed. The rst Prolog rule retrieves a list L of all instances of entity type female. All instances in L are checked one by one by the rule check w1 list then. The predicate arg(3,inst,arg1) gets the third eld of the instance (maiden name) in variable Arg1 whereas arg(2,inst,arg1) gets the second eld (husband) of the instance. The logical relationship (NOT EXISTS(maiden name) OR ( EXISTS(maiden name) AND EXISTS(husband))) is simply described by the following Prolog part: (var(arg1);(not(var(arg1)),..., not(var(arg2)))) The logical OR is translated to the Prolog ; whereas the logical AND is translated to a comma. EXPRESS Prolog ENTITY female; check w1:- findall(female(a,b,c), female(a,b,c), w1: ( NOT EXISTS(maiden name) L), OR check w1 list(l). (EXISTS(maiden name) AND check w1 list([]). EXISTS(husband)) check w1 list([inst Ls]):- ); arg(3,inst,arg1), (var(arg1); (not(var(arg1)), arg(2,inst,arg2), not(var(arg2))), check w1 list(ls).

13 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS Complete Example In order to get an overview over the complexity of the generated Prolog code we lastly give a translation of a complete example. EXPRESS Prolog TYPE supertype rule(entity(person), hair type = ENUMERATION OF oneof(entity(male), (blonde,black); entity(female))). END TYPE; supertype rule(entity(female),nil). supertype rule(entity(male),nil). ENTITY person SUPERTYPE OF type(hair type, (ONEOF(male,female)); enum([e blonde e, name: STRING; e black e])). birth date: ARRAY[1:3]OF INTEGER; hair: hair type; list of ids([ children: SET [0:?] of person; person(id,name, birth date, hair, ENTITY male children), SUBTYPE OF (person); female(id,maiden name), wife: OPTIONAL female; male(id,wife) ]). list of types([ ENTITY female person(integer,string, SUBTYPE OF (person); array(1,3,integer), maiden name: OPTIONAL STRING; hair type, set(0,'?',entity(person))), female(integer, optional(string)), male(integer, optional(entity(female))) ]).

14 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS Conclusion The main purpose of this paper was to show how to generate executable specications out of STEP/EXPRESS models that can be processed by further tools. In order to get a rst quick implementation Prolog has been taken as an ideal language for prototyping. The method to translate STEP/EXPRESS to Prolog shows that a most natural mapping to a logical programming language can be performed. This translation can even be done manually without having detailed Prolog expertise. Nevertheless, the implementation of tools to generate the Prolog code would not be very costly. On this base an implementation of the two cross-compilers to translate EXPRESS as well as STEP models would probably take less than 1 manmonth provided that an EXPRESS compiler front-end is already available. First experiments have shown that it would be easy to implement the main parts of an EXPRESS/STEP checker based on the generated code. Note, that the processing of all the executable parts of EXPRESS is not solved by the translation provided in this report. The major disadvantage building up a Prolog system is on the one hand the runtime and on the other hand the required main memory processing huge sets of data. First tests have shown that the C-Prolog interpreter required about 60MB (!) main memory to load STEP instances. Nevertheless, this is a way toachieve a rst executable model that can be directly processed working well for some important checks suitable for small amount of data. Based on this rst implementation the process of checking STEP/EXPRESS models can be studied in detail and validated if the dened EXPRESS model fullls the requirements. References [1] ISO 10303, EXPRESS Language Reference Manual, Release Draft, Document N 14, ISO TC184/SC4/WG5/P3, April 29, [2] ISO CD , Product Data Representation and Exchange - Part 21: Clear Text Encoding of the Exchange Structure, ISO TC184/SC4/WG5, March 25, [3] ECIP.PH.104(3), A Guide to the ECIP Conceptual Model of Electronic Products and Product Design Process, ECIP2 Workpackage 1, July 17, [4] ECIP2/CADLAB-UNIHAGEN/D , Comparison of Concepts of the existing ECIP notation with EXPRESS, ECIP2 Workpackage 1, February 28, 1991.

15 ECIP2/PU/013-2 Esprit in Condence Translation of EXPRESS [5] R:C C, Validation of EXPRESS Models, ECIP2 Workpackage 1, (to be delivered in March, 1993).