Transformation of Applicative Specifications into Imperative ...

CHAPTER 9. IMPLEMENTATION OF THE TRANSFORMER
All this could have been avoided either by implementing the transformer
directly in Java or by extending and improving the RSL2Java tool.
9.8 Implemented Functionality
An overview of the functionality of the transformer is given below.
9.8.1 Check for Syntactical Constraints
The transformer does not check the syntax of the applicative RSL specification.
This means that the applicative specification should be syntax checked
using the RSL syntax checker before applying the transformer to the specification.
Furthermore, the lexer and parser do only parse constructs not mentioned
in the list of syntactical constraints in Chapter 4. If the user tries to
transform a specification containing e.g. extending class expressions the user
will be notified through error messages.
9.8.2 Check for Non-Syntactically Constraints
The presence of constraints mentioned in the list of non-syntactical constraints
in Chapter 4 are checked during the check for transformability. The
occurrence of such a construct in a specification given to the transformer will
result in an error message.
It is not checked whether overloading is used in the specification. This
means that it is possible to transform specifications containing overloading
but the result is probably not correct, which means that overloading should
be avoided.
9.8.3 Check for Transformability
Before the actual transformation of a given applicative specification it is
checked whether the specification is transformable according to the rules
given in Chapter 5. If the specification is not transformable it is reported to
the user and the specification is not transformed.
9.8.4 Transformable RSL Expressions
The following is a list of the RSL expressions that can be transformed if they
do not violate any of the constraints given in the lists in Chapter 4 and if
they are transformable in the sense explained in Chapter 5.
106