Mapping EXPRESS to Java (early binding)
for JSDAI v3.6.0

Last update 2004-02-09

Author: Lothar Klein, Raimundas Raciunas
(c) Copyright LKSoftWare GmbH

Introduction
Mapping of EXPRESS Data Types
Mapping of EXPRESS Entities
    Entity data types
    Complex entity data
    Partial complex entity data types
   An extended example
Aggregates
    Nested Aggregates
    Aggregates of Entity Data Types
    Aggregates of Simple Data Types and Enumerations
Mapping of Entity Attributes
    Attributes of Assignable Data Type
    Attributes of Aggregate Data Types
    Attributes and Aggregate Members of Select Data Types
Enumeration data types
Schema Class
Constants
Functions & Procedures
Global Rules
Local Rules in Entities
Local Rules in Defined Types

Introduction

The contents of this document is a compatible extension of ISO/TS 10303-27:2000, Industrial automation systems and integration -- Product data representation and exchange -- Part 27: Implementation methods: Java^TM programming language binding to the standard data access interface with Internet/Intranet extension. Readers of this document should be familiar with Java and the EXPRESS data modeling language as defined ins ISO 10303-11:1994 and its 2nd edition to be published in 2004.

The data types of EXPRESS are entity, simple (integer, real, number, boolean, logical, string, binary), aggregate, defined type, enumeration and select. Together with constants, functions, procedures and rules they are grouped in schemas which can be build on top of each other. The key objects for data integration and exchange are instances of (complex) entity data types , which are the focus of this document.

JSDAI^TM supports two native kinds of access to entity instances and their attributes, early binding and late binding access. In addition JSDAI provides a High Level Interface (HLI) to access the AIM data of STEP-APs on ARM level. This document focuses on the native early binding access only.

For early binding EXPRESS entities are mapped to corresponding Java classes and interfaces with access methods for individual entity attributes. This allows a natural programming in the Java environment and possible incorrect usage of entities and their attributes can be detected by the Java compiler. The Java classes and interfaces are created by the JSDAI ExpressCompiler as described below. Most applications like CAx-STEP translators are using early binding, since the EXPRESS schema(s) are known and programming is rather transparent and easy. Only for a few special applications where the underlying EXPRESS schema(s) is not know at compile time the more complex late binding access is needed. SdaiTerm and SdaiEdit are examples of such late binding applications.

Below you will find the mapping of the EXPRESS elements schema, entity, attribute, simple data types, defined type , and aggregate to Java as supported from JSDAI version 1.0 on. These are the elements, needed for the data representation, analysis and modification of the integration and exchange structure. The mapping of the other EXPRESS elements constant, function, procedure and rule to Java as supported from JSDAI version 4.0 on are given as well.

The EXPRESS examples of this document are taken from the extended ESTS-Schema, which is the basis of ISO/TS 10303-35, Conformance Testing Methodology and Framework: Abstract test methods for SDAI implementations.

Mapping of EXPRESS Data Types

The mapping of EXPRESS data types to Java is straightforward as defined in the following table:

EXPRESS data type	Java type	UNSET value
ENTITY	interface jsdai.lang.EEntity with extensions EXxx and class jsdai.lang.CEntity with subtypes CXxx	null
NUMBER	double	Double.NaN
REAL	double	Double.NaN
INT	long	Integer.MIN_VALUE
BOOLEAN	boolean	- internal only -
BINARY	class jsdai.lang.Binary	null
STRING	class java.lang.String	null
LOGICAL	int	0
ENUMERATION	int	0
AGGREGATES	interface jsdai.lang.Aggregate and specializations AXxx and A_xxx	null
SELECT	case a) for entity attributes overloaded methods in EXxx case b) for aggregate members overloaded methods in AXxx	-

JSDAI does not allow to invoke the set and get methods for unset values; an exception is thrown in such a case. Instead applications have to use the special test and unset methods. See below.

JSDAI supports both late binding and early binding in parallel. Late binding access is supported by the interfaces EEntity and Aggregate in package jsdai.lang. For early binding Java packages jsdai.SYyy are created for each EXPRESS schema yyy. These packages includes schema specific interfaces and classes jsdai.SYyy.EXxx, jsdai.SYyy.CXxx , jsdai.SYyy.AXxx. In addition a special class jsdai.SYyy.SYyy is provided for each express schema, representing the schema itself.

Mapping of EXPRESS Entities

Let's take a simple test schema with entities alpha , beta , gamma, delta.

alpha is not a subtype of any other entity
beta is a subtype of alpha
gamma is a subtype of alpha
delta is a subtype of beta and gamma

Here is the EXPRESS-G representation

And here is the same in EXPRESS

ENTITY alpha;
END_ENTITY;

ENTITY beta
SUBTYPE OF (alpha);
END_ENTITY;

ENTITY delta
SUBTYPE OF (beta,gamma);
END_ENTITY;

ENTITY gamma
SUBTYPE OF (alpha);
END_ENTITY;

The term "entity" is not very exact. EXPRESS distinguishes between the terms entity data type, complex entity data type and partial complex entity data types. Lets see how these are mapped into Java. For this it is important to understand how the Java inheritance mechanism works for classes and interfaces:

A class can inherit only from no or one other class
An interface can extend no, one or several other interfaces
A class can implement no, one or several interfaces

Entity data types

An entity data type is one of the "entities" above without its supertypes or any other type. It is mapped to a Java Interface witch name begins with "E" followed by the EXPRESS name. When mapping an EXPRESS name to Java the first character is always written in capital letters and all others - in lowercase letters.

entity data type	entity interface
alpha	EAlpha extends jsdai.lang.EEntity
beta	EBeta extends EAlpha
gamma	EGamma extends EAlpha
delta	EDelta extends EBeta, EGamma

If an entity has no supertypes, then the corresponding Java interface extends jsdai.lang.EEntity. Otherwise the Java interface extends one or several supertypes.

Complex entity data types

A complex entity data type is a valid combination of entity data types from which instances can exist. Depending on the sub-supertype tree and possible supertype constraints not every combination is valid. Entity instances can only be created for valid combinations. The complex entity data type is mapped to a Java class with the prefix "C", followed by the name of one or more of the "leave" entity data types for this particular complex entity data type. If there are more than one "leave" entity data type, then they are given in alphabetical order, separated by a "$".

Throughout this documentation we use the term entity for a single or complex entity data type with only one leave element. The term complex entity is used for a complex entity data type with more than one leave elements. A complex entity is the result of a AND or ANDOR combination of subtypes.

		entity interface
complex entity data type	entity class	EAlpha	EBeta	EGamma	EDelta
alpha	CAlpha	x
alpha&beta	CBeta	x	x
alpha&gamma	CGamma	x		x
alpha&beta&gamma	CBeta$gamma	x	x	x
alpha&beta&gamma&delta	CDelta	x	x	x	x

Some corresponding entity instances in a part21 file may look like this:

...
#11=ALFA(...);
#22=BETA(...);
#33=GAMMA(...);
#44=(ALFA(...)BETA(...)GAMMA(...));
#55=DELTA(...);
...

If the name of an entity class contains a "$", then instances of this complex entity data type appear in a part21 file always in the "external mapping" format (e.g. #44).

Please note that supertype constraints such as ONEOF, AND, ANDOR are not mapped to Java. It is the responsibility of the ExpressCompiler to determine the valid complex entity data types and generate the corresponding Java classes "C...". Even for entities defined to be abstract supertypes a corresponding Java class "CXxx" is generated, however it is not possible to create instances of such a class.

Partial complex entity data types

Like the complex entity data type, a partial complex entity data type is a combination of single entity data types. However because it is not a valid combination of entity data types no instances can be created from it. It is therefore not directly mapped to Java. There are a few cases when an application may wish to operate on on partial complex entity data tpes. For this the late binding class Value (from JSDAI version 4.0 on) may be used, which is able to represent values of any EXPRESS data type.

An extended example

The above mentioned sub-supertype tree in the ESTS-schema is in fact more complex. Together with the entities kappa, lamda and mu there exist several more valid complex entity data types that can be constructed:

		entity interface
complex entity data type	entity class	EAlpha	EBeta	EGamma	EDelta	EKappa	ELamda	EMu
alpha	CAlpha	x	-	-	-	-	-	-
alpha&beta	CBeta	x	x	-	-	-	-	-
alpha&gamma&kappa	CGamma	x	-	x	-	x	-	-
alpha&gamma&kappa&lamda	CGamma$lamda	x	-	x	-	x	x	-
alpha&gamma&kappa&lamda&mu	CGamma$mu	x	-	x	-	x	x	x
alpha&beta&gamma&kappa	CBeta$gamma	x	x	x	-	x	-	-
alpha&beta&gamma&kappa&lamda	CBeta$gamma$lamda	x	x	x	-	x	x	-
alpha&beta&gamma&kappa&lamda&mu	CBeta$gamma$mu	x	x	x	-	x	x	x
alpha&beta&gamma&delta&kappa	CDelta	x	x	x	x	x	-	-
alpha&beta&gamma&delta&kappa&lamda	CDelta$lamda	x	x	x	x	x	x	-
alpha&beta&gamma&delta&kappa&lamda&mu	CDelta$mu	x	x	x	x	x	x	x

Aggregates

SET, BAG, LIST, and ARRAY are the persistent aggregate types in EXPRESS used for entity attributes. The aggregate types GENERIC are used for functions and procedures. The type non-persistent list is used by various SDAI operations. The mapping to JSDAI does not distinguish among these different aggregate types; it distinguishes only by the base type of the aggregate (however there is a difference of the allowed operations depending of the kind of aggregate). The base type of an aggregate is either

another aggregate (nested aggregates)
an entity data type
a simple type such as INTEGER, REAL, BOOLEAN, LOGICAL, BINARY, STRING or an enumeration type
a defined type with an underlying type which is not directly or indirectly a select type. This is handled the same way as case 3)
a defined type with an underlying type which is directly or indirectly a select type. See

The Java interface jsdai.lang.Aggregate contains late binding methods to read and modify the aggregate members. See the jsdai.lang.Aggregate documentation for more details of the available methods. The aggregate members can be accessed by:

test methods: testByIndex, testCurrentMember
get methods: getByIndex, getCurrentMember
set methods: setByIndex, setCurrentMember
add methods: addBefore, addAfter, addByIndex , addUnordered
special methods for nested aggregates: createAggregateAsCurrentMember , createAggregateAfter, createAggregateBefore, createAggregateByIndex , createAggregateUnordered, addAggregateByIndex

There exists many implementing classes of the Aggregate interface with more specialized access methods, some are pre-defined in package jsdai.lang, others are generated by the ExpressCompiler in the schema packages.

Instances of aggregate types can exist only as non-persistent lists or as possibly nested values of entity attributes with aggregate base types. Aggregates instances cannot be shared for different attributes. Therefore no setAaa methods are provided for aggregates. Instead they have to be created in place with createAaa methods.

Case 3) and

Nested Aggregates

Java classes for non-nested aggregates starts with the prefix "A". In the case of a double nested aggregate the prefix is "Aa", in the case of a triple nested aggregate "Aaa" and so on. The return type of the get and create methods of nested aggregates is the same type minus one hierarchy level.

Aggregates of Entity Data Types

For every entity a corresponding Java class representing an aggregate of this entity data type is created by the ExpressCompiler. Nested aggregates are only generated as needed in the Express schema(s). For a given entity xxx the class name are AXxx, AaXxx, AaaXxx ect.

For the non nested aggregate classes the return value of the get methods is EXxx.

Aggregates of Simple Data Types and Enumerations

For every simple data type a corresponding Java class for its aggregate including nested levels is available. These aggregate class names begin with the prefix "A_" followed by the name of the simple type. In the case of double nested aggregates the prefix is "Aa_", for triple nested aggregates - "Aaa_", etc..

EXPRESS type	Java type	single nested aggregate	double nested aggregate	trippel nested aggregate
NUMBER	double	jsdai.lang.A_double	jsdai.lang.Aa_double	jsdai.lang.Aaa_double
REAL	double	jsdai.lang.A_double	jsdai.lang.Aa_double	jsdai.lang.Aaa_double
INTEGER	int	jsdai.lang.A_integer	jsdai.lang.Aa_integer	jsdai.lang.Aaa_integer
BOOLEAN	boolean	jsdai.lang.A_boolean	jsdai.lang.Aa_boolean	jsdai.lang.Aaa_boolean
LOGICAL	int	jsdai.lang.A_enumeration	jsdai.lang.Aa_enumeration	jsdai.lang.Aaa_enumeration
BINARY	java.util.BitSet	jsdai.lang.A_bitset	jsdai.lang.Aa_bitset	jsdai.lang.Aaa_bitset
STRING	java.lang.String	jsdai.lang.A_string	jsdai.lang.Aa_string	jsdai.lang.Aaa_string
enumerations	int	jsdai.lang.A_enumeration	jsdai.lang.Aa_enumeration	jsdai.lang.Aaa_enumeration

Mapping of EXPRESS Attributes

Depending of the type of an attribute aaa the following access methods are provided in the corresponding Java interfaces and classes of the entity:

· testAaa, to test if the attribute has a value or if it is unset. In the case that the data type of the attribute contains a select type the return type is integer, indicating the actual select case. Otherwise the return type is boolean. The return values 0 respectively false indicate an unset value.

· getAaa to retrieve the actual value of the attribute. The return value depends on the type of the attribute. As needed several overloaded methods are provided in the case of a select type.

· setAaa to set the value of an attribute. No UNSET value is allowed. Values of an Aggregate type cannot be assigned with these methods; see createAaa below. As needed several overloaded methods are provided in the case of an select type.

· unsetAaa to unset the value of an attribute.

· createAaa to create an aggregate, assign it as value for the attribute and also to return it. As needed several overloaded methids are provided in the case of an select type.

· usedinAaa, static methods to follow an explicit attribute of some entity type in inverse order.

· attributeAaa, static methods to retrieve the corresponding dictionary object for that aggregate.

The first parameter of all testAaa, getAaa, setAaa , unsetAaa and createAaa methods are always of type EXxx with xxx be the name of the entity in which this attribute is declared. This parameter is only used for the (rare) case of name conflicts of attributes in a sub-supertype tree. In most cases applications provide only a simple null value for this parameter. Only in rare cases a casted null value is provided to distinguish the entity to which this attribute belongs to.

JSDAI does not support the ALIAS statements of EXPRESS attributes. In the case of an alias the original name of this attribute has to be used.

EXPRESS defines three kinds of attributes, explicit, derived and inverse. In addition attributes can be redeclared in subtypes. So we have the combinations of redeclared explicit, redeclared derived and redeclared inverse. In addition explicit attributes can be redeclared as derived.

For explicit but no redeclared attributes all methods as described above are provided. For redeclared explicit attributes no additional methods are defined in the subtype.

For derived attributes only the testAaa, getAaa and attributeAaa methods are available.

For inverse attributes only the getAaa and attributeAaa methods are provided.

Attributes of Assignable Data Types

The following table shows how the seven EXPRESS simple data types are mapped to Java. Also the valid range and the unset value are given.

EXPRESS primitive	Java type	value range	unset value
NUMBER	double	Double.MIN_VALUE ... Double.MAX_VALUE	Double.NaN
REAL	double	Double.MIN_VALUE ... Double.MAX_VALUE	Double.NaN
INTEGER	int	(Integer.MIN_VALUE+1) ... Integer.MAX_VALUE	Integer.MIN_VALUE
LOGICAL	int	1(FALSE), 2(TRUE), 3(UNKNOWN)	0
BOOLEAN	boolean	true, false	(internal)
STRING	java.lang.String	any	null
BINARY	java.util.BitSet	any	null

Let us use the primitive data types as direct base types for entity attributes. For this we have constructed entity omega. We did add an attribute to another entity iota. Here is the EXPRESS-G

And here is the EXPRESS

ENTITY iota;
END_ENTITY;

TYPE tau = ENUMERATION OF
(stigma, digamma, koppa, sampi);
END_TYPE;

TYPE xi = INTEGER;
END_TYPE;

ENTITY omega;
o0 : iota;
o1 : NUMBER;
o2 : REAL;
o3 : INTEGER;
o4 : LOGICAL;
o5 : BOOLEAN;
o6 : STRING;
o7 : BINARY;
o8 : tau;
o9 : xi;
END_ENTITY;

As explained, the corresponding Java interface EOmega and Java class COmega (and EIota and CIota) are created. In EOmega access methods to test, get, set and unset attributes are specified which are implemented in COmega. In this example all attributes are mandatory (not optional). For a valid entity instance all attributes must have values. Nevertheless, it is a valid state in JSDAI that these attributes may be unset. Therefore also test and unset methods are available not only for optional but also for mandatory attributes. Also, after creating a new entity instance all its attributes are unset.

Every public JSDAI method is able to throw SdaiExceptions. Depending on the kind of the method, there may be various reasons why to throw an exception. A reason for the attribute access methods is e.g. that the instance is invalid because the session was closed, the access to the SdaiModel was ended, etc. In this case an SdaiException with argument EI_NAVL (entity instance not valid) is thrown.

A test method checks whether an attribute has a value or not. It returns true if the value is set and false if it unset.

boolean testO0(EOmega type) throws SdaiException;
boolean testO1(EOmega type) throws SdaiException;
boolean testO2(EOmega type) throws SdaiException;
boolean testO3(EOmega type) throws SdaiException;
boolean testO4(EOmega type) throws SdaiException;
boolean testO5(EOmega type) throws SdaiException;
boolean testO6(EOmega type) throws SdaiException;
boolean testO7(EOmega type) throws SdaiException;
boolean testO8(EOmega type) throws SdaiException;
boolean testO9(EOmega type) throws SdaiException;

The get methods return the actual values of attributes. An SdaiException with the argument VA_NSET (value not set) is thrown if the attribute has an unset value.

EIota getO0(EOmega type) throws SdaiException;
double getO1(EOmega type) throws SdaiException;
double getO2(EOmega type) throws SdaiException;
    int getO3(EOmega type) throws SdaiException;
    int getO4(EOmega type) throws SdaiException;
boolean getO5(EOmega type) throws SdaiException;
String getO6(EOmega type) throws SdaiException;
BitSet getO7(EOmega type) throws SdaiException;
    int getO8(EOmega type) throws SdaiException;
    int getO9(EOmega type) throws SdaiException;

The set methods set new values for attributes. In the case that an application tries to set a value outside the specified range above, e.g. the unset value, an exception VT_NVLD (value type invalid) is thrown.

void setO0(EOmega type,   EIota value) throws SdaiException;
void setO1(EOmega type, double value) throws SdaiException;
void setO2(EOmega type, double value) throws SdaiException;
void setO3(EOmega type,     int value) throws SdaiException;
void setO4(EOmega type,     int value) throws SdaiException;
void setO5(EOmega type, boolean value) throws SdaiException;
void setO6(EOmega type, String value) throws SdaiException;
void setO7(EOmega type, BitSet value) throws SdaiException;
void setO8(EOmega type,     int value) throws SdaiException;
void setO9(EOmega type,     int value) throws SdaiException;

Finally, an unset method is available for each attribute.

boolean unsetO0(EOmega type) throws SdaiException;
boolean unsetO1(EOmega type) throws SdaiException;
boolean unsetO2(EOmega type) throws SdaiException;
boolean unsetO3(EOmega type) throws SdaiException;
boolean unsetO4(EOmega type) throws SdaiException;
boolean unsetO5(EOmega type) throws SdaiException;
boolean unsetO6(EOmega type) throws SdaiException;
boolean unsetO7(EOmega type) throws SdaiException;
boolean unsetO8(EOmega type) throws SdaiException;
boolean unsetO9(EOmega type) throws SdaiException;

Looking for the first time at the test, get, set and unset methods, one may think that the set and unset methods are superfluous because this functionality could also be realized by the get and set methods. This is correct but there exist cases where an attribute is of a select data type (see below), which may lead to different Java types, e.g. double, and int.

Attributes of Aggregation Types

Knowing what happen with attributes based on simple entity data types we can continue with attributes based on aggregates of simple entity data types. Entity sigma has such attributes of various aggregation base types with different bounds.

ENTITY sigma;
s0 : SET [0:?] OF iota;
s1 : LIST [0:?] OF NUMBER;
s2 : BAG [0:?] OF REAL;
s3 : ARRAY [0:4] OF INTEGER;
s4 : SET [2:4] OF LOGICAL;
s5 : LIST [2:4] OF BOOLEAN;
s6 : BAG [2:4] OF STRING;
o7 : ARRAY [2:4] OF BINARY;
s8 : LIST [1:?] OF tau;
s9 : LIST [1:?] OF xi;
END_ENTITY;

Similar to the simple data types there are also test , get and unset methods for attributes of aggregation data types. But instead of set methods create methods are available. The create methods create aggregate instances in place. It is not possible to assign an aggregate as the value for an attribute. The test and unset methods look rather similar to the ones for the simple data types and are not repeated here. The set and also the create methods return the actual/new aggregate.

        AIota getS0(ESigma type) throws SdaiException;
       A_real getS1(ESigma type) throws SdaiException;
       A_real getS2(ESigma type) throws SdaiException;
    A_integer getS3(ESigma type) throws SdaiException;
A_enumeration getS4(ESigma type) throws SdaiException;
    A_boolean getS5(ESigma type) throws SdaiException;
     A_string getS6(ESigma type) throws SdaiException;
     A_binary getS7(ESigma type) throws SdaiException;
A_enumeration getS8(ESigma type) throws SdaiException;
    A_integer getS9(ESigma type) throws SdaiException;

The create methods create a new aggregate, set it as the actual value for the attribute and return also this value. The old value of the attribute becomes invalid.

        AIota createS0(ESigma type) throws SdaiException;
       A_real createS1(ESigma type) throws SdaiException;
       A_real createS2(ESigma type) throws SdaiException;
    A_integer createS3(ESigma type) throws SdaiException;
A_enumeration createS4(ESigma type) throws SdaiException;
    A_boolean createS5(ESigma type) throws SdaiException;
     A_string createS6(ESigma type) throws SdaiException;
     A_binary createS7(ESigma type) throws SdaiException;
A_enumeration createS8(ESigma type) throws SdaiException;
    A_integer createS9(ESigma type) throws SdaiException;

Attributes and aggregate members of select data types

For attributes of SELECT types, multiple early binding methods getAaa and setAaa / createAaa methods for a single attribute may be available, one for each select case. The testAaa method returns an integer, indicating the actual select case.

Select case and select path are concepts, describing the complex mechanism with select data types, especially when they are nested and invoke other defied types which are not select types. There are three possible kinds of elements in a select list

entity types
defined types with an underlying select type, we call this a nested select type
defined types with an underlying type which is either another defined type, a simple type an aggregation type or an enumeration.

Case 3 get more complex if the underlying type of the underlying type is again a select type. These cases needs also special provisions in the Clear Text Encoding of the Exchange Structure, ISO 10303-21 (STEP-File)

The simple type of the run-time value (for example REAL) does not define the type of the select value sufficiently. More than one chain of defined and/or select types may lead to a REAL type. So the path through the select elements and their underlying types is needed to define the select value fully. We call such a chain a select path.

The actual value of an attribute or an aggregate member of a select type consists of two parts, the select path and the primitive value . The primitive value is either unset or one of: an entity instance or an aggregate instance, or an enumeration value or a value of a simple type. In the case of an unset value the select case is always 0. In the case of an entity instance the select case is always 1. In all other cases the ExpressCompiler generates the possible select paths and enumerates these select cases , starting from 2. This numbering is important, because early binding test method returns int value - the select case number of the current value, or 0 if unset.

For convenience of JSDAI application programmers, for each select case (except case 1) integer constants are present in entity interfaces for each attribute of select type.
The names of these constants are constructed in the following way: The name starts with the lowercase letter s followed by the name of the attribute, and further followed by the names of the defined types that form the select path for the select case. All the names are normalized: the first letter of each name is always in uppercase, the rest - in lowercase.

In early binding get and set/create methods, the select path is represented by a sequence of parameters, representing the used defined types through their interfaces.
The used algorithm is analog to the encoding specification in ISO 10303-21.
The nodes of a select paths include only those defined types, which do not have a select type as underlying type. So the nodes can only be defined types with the underlying type aggregates, enumeration, simple types or another defined type. However, in the case that several defined types where the underlying type is again a defined type are chained, only the first defined type is given as node.

This logic described above is rather complex and not easy to understand and to describe. However it is needed to fully support the mechanisms provided in EXPRESS. In practice people don't have to worry about this because all this is handled by the ExpressCompiler and people have only to look in the documentation, generated by ExpressDoc or in the generated Java code to see what to do.

The return type of the early binding get and create methods for entity attributes and aggregate members is the type of the primitive value. For attribute set methods the primitive value is given by the second parameter. For aggregate set methods the primitive value is given by the first parameter.

For each select case, a separate pair of overloaded get and set/create methods is available in the entity interface. The methods are distinguished by their signature, given by additional appended parameters, representing the nodes of the select path. An application has to pass casted null values for them. The methods for case 1, if present, do not have any additional parameters to define the select path. EEntity is used for return/value types to accommodate various entity types in select.

Here is entity epsilon, which has some attributes of select type.

The attribute e5 is of select type rho. It has 14 select cases. Here are constants and methods that are available for this attribute in the interface EEpsilon:

These constants are defined for SELECT attribute e5:

     int sE5Phi        = 2;
     int sE5Psi        = 3;
     int sE5Chi        = 4;
     int sE5Tau        = 5;
     int sE5Xi         = 6;
     int sE5Pie        = 7;
     int sE5OmicronPhi = 8;
     int sE5OmicronPsi = 9;
     int sE5OmicronChi = 10;
     int sE5OmicronTau = 11;
     int sE5OmicronXi = 12;
     int sE5OmicronPie = 13;
     int sE5Upsilon    = 14;

Methods for SELECT attribute e5:

int testE5(EEpsilon type) throws SdaiException;

EEntity getE5(EEpsilon type)                             throws SdaiException; // case 1
  AOmega getE5(EEpsilon type, EPhi node1)                 throws SdaiException; // case 2
AaOmega getE5(EEpsilon type, EPsi node1)                 throws SdaiException; // case 3
A_double getE5(EEpsilon type, EChi node1)                 throws SdaiException; // case 4
     int getE5(EEpsilon type, ETau node1)                 throws SdaiException; // case 5
     int getE5(EEpsilon type, EXi node1)                  throws SdaiException; // case 6
     int getE5(EEpsilon type, EPie node1)                 throws SdaiException; // case 7
  AOmega getE5(EEpsilon type, EOmicron node1, EPhi node2) throws SdaiException; // case 8
AaOmega getE5(EEpsilon type, EOmicron node1, EPsi node2) throws SdaiException; // case 9
A_double getE5(EEpsilon type, EOmicron node1, EChi node2) throws SdaiException; // case 10
     int getE5(EEpsilon type, EOmicron node1, ETau node2) throws SdaiException; // case 11
     int getE5(EEpsilon type, EOmicron node1, EXi node2) throws SdaiException; // case 12
     int getE5(EEpsilon type, EOmicron node1, EPie node2) throws SdaiException; // case 13
     ANu getE5(EEpsilon type, EUpsilon node1)             throws SdaiException; // case 14

    void setE5(EEpsilon type, EEntity value)                         throws SdaiException; // case 1
  AOmega createE5(EEpsilon type, EPhi node1)                         throws SdaiException; // case 2
AaOmega createE5(EEpsilon type, EPsi node1)                         throws SdaiException; // case 3
A_double createE5(EEpsilon type, EChi node1)                         throws SdaiException; // case 4
    void setE5(EEpsilon type, int value, ETau node1)                 throws SdaiException; // case 5
    void setE5(EEpsilon type, int value, EXi node1)                  throws SdaiException; // case 6
    void setE5(EEpsilon type, int value, EPie node1)                 throws SdaiException; // case 7
  AOmega createE5(EEpsilon type, EOmicron node1, EPhi node2)         throws SdaiException; // case 8
AaOmega createE5(EEpsilon type, EOmicron node1, EPsi node2)         throws SdaiException; // case 9
A_double createE5(EEpsilon type, EOmicron node1, EChi node2)         throws SdaiException; // case 10
    void setE5(EEpsilon type, int value, EOmicron node1, ETau node2) throws SdaiException; // case 11
    void setE5(EEpsilon type, int value, EOmicron node1, EXi node2) throws SdaiException; // case 12
    void setE5(EEpsilon type, int value, EOmicron node1, EPie node2) throws SdaiException; // case 13
     ANu createE5(EEpsilon type, EUpsilon node1)                     throws SdaiException; // case 14

void unsetE5(EEpsilon type) throws SdaiException;

Mapping of Enumeration Types

For each defined type xxx whose underlying type is an enumeration type a corresponding "static" Java class with the name EXxx is created. No objects are going to be creates of this class since it is only used to provide the enumeration elements for easy early binding handling.

Example: The EXPRESS definition

    TYPE tau = ENUMERATION (
        stigma, digamma, koppa, sampi ) ;
    END_TYPE; -- tau

results into this Java class:

    public final class ETau {
        static final int STIGMA = 1;
        static final int DIGAMMA = 2;
        static final int KOPPA = 3;
        static final int SAMPI = 4;
        static String[] values = {"STIGMA", "DIGAMMA", "KOPPA", "SAMPI"};
        static int toInt(String str) static String toString(int value);
    }

Schema class

For each express schema, the express compiler generates a special schema class. It is located in the generated java package for the schema as a public class, and with the the same as the package. Example, if the name of the schema is ESTS, then the name of the package is jsdai.SEsts , and the name of the special schema class in the package is also SEsts . To the full name is jsdai.SEsts.SEsts.

The schema class itself is used as a parameter for the following public JSDAI methods:

· in class jsdai.lang.SdaiRepository

public SdaiModel createSdaiModel(String model_name, Class schema) throws SdaiException {...}

public SchemaInstance createSchemaInstance(String name, Class schema) throws SdaiException {...)

· in class jsdai.lang.SdaiSession

public Class getComplexEntityClass(Class[] types, Class schema) throws SdaiException {...}

static public EData_type findDataType(String name, Class schema) throws SdaiException {...}

The schema class also contains public static fields for all defined data types, specified locally in this schema. For a defined type with the name some_type, the following method is present in the schema class:

public static jsdai.dictionary.EDefined_type _some_type;

The schema class contains also public static fields for types, such as aggregates, that are not explicitly declared in express as defined data types, but still are types of attributes, parameters or local variables and are needed in the implementation of expressions. Their names are constructed to reflect the type, including aggregate names and bound values.

Examples

SET [1:2] OF LIST [0:3] OF INTEGER

maps to

public static jsdai.dictionary.EData_type _set_1_2_list_0_3_integer;

ARRAY OF BAG OF GENERIC

maps to

public static jsdai.dictionary.EData_type _array___bag___generic;

For the identification when the classes and interfaces where generated by the JSDAI ExpressCompiler and by which version, the schema class contains fields like these:

public static final String time_stamp = "2002-11-22 T01:41:39";

public static final String version = "3.5, 2002-10-10";

The schema class also is the place for express constants; see below.

The methods implementing domain rules in defined types are also locaded in the schema class.
See Local Rules in Defined Types.

Furthermore the schema class also plays an important role in the internal mechanism of JSDAI and holds several non-public methods and data fields..

Constants

The schema class contains public methods implementing express constants. For a constant with the name some_constant, the following method is present in the schema class:

public static Value cSome_constant(SdaiContext _context) throws SdaiException {...}

Functions & Procedures

An express function xxx with parameters parameter_1, ..., parameter_n, is mapped to the public java class FXxx with
the public method

public static Value run(SdaiContext context, Value parameter_1, ..., Value parameter_n)
throws SdaiException {...}

The type of the parameters and the return type is Value, even though FXxx is early binding representation of the function
xxx. In JSDAI, evaluation of expressions is always based on Value..

Express functions usually are used in expressions to calculate derived attribute values or constraints in rules, and their arguments are also expressions so everything fits together nicely. However, functions can also be used directly in JSDAI applications if necessary. In that case, an instance of SdaiContext must be provided as the first parameter by the JSDAI application. Otherwise, it is provided automatically as long as SdaiContext is set in the SdaiSession.

Likewise, an express procedure yyy with parameters parameter_1, ..., parameter_n is mapped to the public java class FYyy with the public method

public static void run(SdaiContext context, Value parameter_1, ..., Value parameter_n)
throws SdaiException {...}

Express VAR parameters are supported in procedures.
Type labels are supported in functions and procedures for generic types but not for aggregates or aggregate members.

Global Rules

An express global rule xxx is mapped to the public java class RXxx. This class contains methods for validation of all domain rules in the global rule,
for example, for domain rule WR1 the following method is available:

public int rWr1(SdaiContext context) throws SdaiException {...}

The return type of the method is int, representing an Express LOGICAL value.

Also a single method to validate all the domain rules in a global rule is provided:

public int run(SdaiContext _context, A_string violations) throws SdaiException {...}

The A_string parameter is provided to accumulate the information about violations of domain rules.
The labels of failed domain rules are added to the instance of A_string supplied via this parameter.
The return value is logical AND of return values of the methods of all the domain rules.

Local Rules in Entities

For each local rule (for each domain rule in WHERE clause) in express entity xxx, a special method is available in the corresponding java class CXxx,
for example, for domain rule WR1, the following method is present:

public int rWr1(SdaiContext context) throws SdaiException {...}

The return type of the method is int, representing an Express LOGICAL value.

Local Rules in Defined Types

For each domain rule in a defined type, the corresponding static method is provided in the schema class of the schema where the type is defined.
The name of the method is constructed in the following way: "r" + "The_name_of_the_type" + "The_label_of_the_domain_rule".
So, for the domain rule "WR1" in type "dimension", the following method is provided:

public static int rDimensionWr1(SdaiContext _context, Value self) throws SdaiException {...}

The return value is java int representing express LOGICAL, as in similar methods in global rules and in entities. The Value parameter is used to pass a specific value which conformance to the domain rules of the type are to be checked. It corresponds to express built-in constant SELF used in domain rules of types.

For each defined type which has domain rules or which underlying type (or, possibly, chained underlying types) has(have) domain rules, a special method to validate all the domain rules is also provided in the schema class of the schema where the type is defined. For example, for the above type "dimension" the following method would be present:

public static int runDimension(SdaiContext _context, Value self, A_string violations) throws SdaiException {...}

Here, Value parameter is the same as in the methods for separate domain rules, representing express SELF.

A_string parameter is used to accumulate information about violations.
It contains all the failed domain rules in the form "type_name.domain_rule_label"

The return value of the method is logical AND of return values of the methods of all the domain rules of the type and of its (chained) underlying type(s).
The underlying types may be defined in other schemas, in that case, their corresponding domain rule metohds would not be present in the schema class of the current schema, but their return values would still participate in the logical AND.
If the underlying type is an aggregate, the domain rules of the types of elements of the aggregate are not validated, they should be validated separately.
Likewise, if the underlying type is SELECT, the domain rules of the types of elements of the select type are not validated in this method.

Validation of domain rules of defined types is usually invoked from other JSDAI methods, such as for validation of attributes, therefore, an application programmer does not have to concern himself with parameters of Value type.

JSDAI is a registered trademark of LKSoftWare GmbH
Java is a registered trademark of Sun Microsystems

Mapping EXPRESS to Java (early binding) for JSDAI v3.6.0

Contents