Mappers and Code generators: Python modules

The architecture selected for the code generators can be seen in Figure 5.1. It is basically split in (a) the frontend parsers (AADL and ASN.1) and (b) backend generators (for SCADE, ObjectGeode, etc).

Figure 5.1: Architecture of Code Generators

asn2dataModel directly parses the input ASN.1 grammar. aadl2glueC starts with parsing of the AADL system description. The AADL parser is fed in turn with each one of the input AADL files, and Data Modeling specific information is extracted. The AADL Data view, in particular, has been generated from asn2aadlPlus, and includes references to the ASN.1 grammars used. Each one of these ASN.1 grammar files is then passed to the ASN.1 parser (as is done for asn2dataModel.

At the end of these stages, two Abstract Syntax Trees (ASTs) contain the overall system information: The system AST and the data types AST. The system AST contains all the Data Modeling related information which is stored in the AADL files, while the data types AST contains all the ASN.1 specific information stored in the ASN.1 file referenced by the Data View.

What happens next (labeled in in Figure 5.1 as "Code Genesis") can be described in pseudocode like this:

  for each one of the AP Level Containers that need "glue" 
     identify the implementation language they are made of
     (e.g. Lustre/SCADE, SDL/ObjectGeode, manual C/Ada)
     Load the appropriate backend module for the language
     for each one of their input and output parameters
        call the loaded module's function
        for handling the specific parameter's ASN.1 type
        (e.g. OnBasic, OnSequence, OnSequenceOf, etc)

This allows for a completely modular architecture:

-

The backend module that will be loaded for a specific AP Level Container follows a simple naming convention: if the implementation language (Source_Language) is XYZ, then the module must be named either xyz_A_mapper.py (for mapping to tool-specific data types) or xyz_B_mapper.py (for the specification of the ``glue'' code genesis). The toolchain currently includes support for Lustre5, Lustre6+, MATLAB/Simulink, ObjectGeode, Ada and C mappers, in the form of ...

• lustre5_A_mapper.py and lustre5_B_mapper.py (for SCADE 5)
• lustre6_A_mapper.py and lustre6_B_mapper.py (for SCADE 6)
• simulink_A_mapper.py and simulink_B_mapper.py (for MATLAB/Simulink)
• og_A_mapper.py and og_B_mapper.py (for ObjectGeode)
• c_A_mapper.py and c_B_mapper.py (for manual C coding, or Rhapsody/C++)
• ada_A_mapper.py and ada_B_mapper.py (for manual Ada coding)

-

Each one of the backends includes a set of functions that describe what actions to take for each kind of ASN.1 construct:

• OnBasic handles all the basic ASN.1 types: INTEGER, REAL, BOOLEAN and OCTET STRING and its variants.
• OnEnumerated handles the ASN.1 ENUMERATED types
• OnSequence handles the ASN.1 SEQUENCEs (i.e. the structures of information)
• OnSequenceOf handles the ASN.1 SEQUENCE OFs (i.e. the arrays of a type)
• OnChoice handles the ASN.1 CHOICE OFs (i.e. the polymophic types)
• OnSet handles the ASN.1 SETs (i.e. the unordered structures of information)
• OnSetOf handles the ASN.1 SET OFs (i.e. the sets of a type)

-

The function arguments provide access to the ASTs, so that the developer of the backend can use whatever information he/she needs from the type (e.g. RANGE information on INTEGERs, options available in ENUMERATEDs, etc).

-

OnStartup and OnShutdown functions act as "constructors" and "destructors" (e.g. open the output files, etc). They are called for initialization and final work.

Notice that each parameter is of a specific ASN.1 type, which explains why all the OnXYZ functions take a nodeTypename string argument, as well as a node argument that provides them with access to the ASN.1 AST. Additional function arguments are also provided to offer ``shortcuts'' and additional information through the ASTs (see below).

The "Hello world" of type A backends (i.e. mappers to data types) is therefore this:

def Version():
    print "HelloWorld backend of type A (asn2dataModel), Version 1.0"

def OnStartup(modelingLanguage, asnFile, outputDir):
    print "Starting up processing..."

def OnBasic(nodeTypename, node, leafTypeDict):
    print nodeTypename

def OnSequence(nodeTypename, node, leafTypeDict):
...

def OnShutdown():
    print "Ending up processing..."

...while the "Hello world" of type B backends (i.e. ``glue'' generators) is this:

def Version():
    print "HelloWorld backend B (aadl2glueC), Version 1.0"

def OnStartup(modelingLanguage, asnFile, subProgram, sPrImpl, outputDir):
    print "Starting up processing..."

def OnBasic(nodeTypename, node, subProgram, sPrImpl, param, \
        leafTypeDict, names):
    print nodeTypename
    ...

def OnShutdown(modelingLanguage, asnFile, subProgram, \
        subProgramImplementation):
    print "Ending up processing..."

All mappers and ``glue'' generators of ASSERT are implemented under this scheme. Since the backends are real Python modules, they are amenable to static analysis (through PyChecker^6.1) and equally important, statement coverage^6.2.

Also note, that Appendix B [9] includes details on what kind of information is carried by the ASN.1 Abstract Syntax Tree (the node parameters in the callbacks shown above).