6.4.7. RFG and IR operations with BauhausTool (deprecated)¶

Warning

BauhausTool as well as the processline framework described in this chapter are deprecated. For creating new architecture analyses and additional RFG-based rules we recommend the new analysis framework system introduced with Version 7.0. This chapter is kept as a reference for as long as BauhausTool and processline are still supported within the Axivion Suite.

BauhausTool is a Python class that can be used for creating tools that process RFG files and/or inspect IR files. BauhausTool offers the possibility of easily specifying input arguments and return values, and other features like logging and delivering messages to the analysis database. The most prominent role of BauhausTool is as the foundation of tools that are used within a processline configuration. The return type of a tool created with BauhausTool can be chosen by the tool developer from a predefined list of return types. The class and its extensions also offer additional input types and sophisticated possibilities for logging and reporting warnings. The class BauhausTool supports basic input types like files, list of files, strings, etc. These types can be extended by using the routines with_rfg_types from the module bauhaus.rfg.rfgtool: Then input types like RFGs, views, and RFG nodes are also possible, and it is possible to return an RFG as a result. In this way, tools created using BauhausTool and bauhaus.rfg.rfgtool can return an RFG instance and can so be used as elements in a processline-configuration. Similarly, the routine with_ir_types from the module bauhaus.ir.irtool offers an input type for IR graphs. As we will see later, it is possible to use a tool having both RFG-related inputs and IR-related inputs.

6.4.7.1. An example using `BauhausTool`¶

We start with an example of a very simple tool named output_error.py, which simply outputs a user-defined error message, or, if explicitly specified, a warning message:

from bauhaus.shared import bauhaustool

INPUTS = {
    'output_warning' : { 'doc'    : 'output warning instead of error',
                         'type'    : 'boolean',
                         'default' : False,
                       },
    'message'        : { 'doc'     : 'output message',
                         'type'    : 'string',
                       },
   }
OUTPUT = 'void'

@bauhaustool.BauhausTool(INPUTS, OUTPUT)
def perform(**kwargs):
    output_warning   = kwargs['output_warning']
    message          = kwargs['message']
    if output_warning:
        perform.warning(message)
    else:
        perform.error(message)

if __name__ == '__main__':
    perform.execute_as_command_line_tool\
        (usage='%prog [options] <resultrfg>',
         description = 'Prints an error message.')

A decorator @bauhaustool.BauhausTool is used for routine perform, with two arguments:

a dictionary giving information about the inputs of the tool, and
a string specifying the expected output value.

In the example, the return type of the tool is void, stating that the tool does not return a value. Within the dictionary that specifies an individual input, the entry type gives the type of the input, the entry doc is used to specify a documentation string, and type specifies the type of the input parameter. Further, the optional entry default allows to specify a default value if no specific value for the input is provided. The decorator transforms perform into an instance of BauhausTool that is callable.

Within the code of the tool, the inputs can be accessed by kwargs[’input_name’]. The tool uses the methods warning resp. error to output messages. They are instance methods of perform (see section BauhausTool API for a more detailed description of the capabilities of BauhausTool instances for outputting messages).

For executing the tool from the command line, the method execute_as_command_line_tool of perform is used. If we start the tool with the command

rfgscript output_error.py --help

from an Axivion Command Prompt, we get the following help screen:

Usage: output_error.py [options]

Prints an error message.

Options:
  -h, --help            show this help message and exit
  --display_config_usage
                        display an example entry in a processline config file
  -d, --debug           output (detailed) debug information (default: False)
  --message=MESSAGE     output message.
  --output_warning      output a warning instead of an error (default: False)
  -v, --verbose         output verbose state information (default: False)

The command

rfgscript example1.py --message "Hello, world." --output_warning

gives the output

:0:0: warning: Hello, world. [routine perform in module __main__] (BauhausTool-Warning)

If we skip the --output_warning switch, an actual error is reported:

:0:0: error: Hello, world. [routine perform in module __main__] (BauhausTool-Warning)

6.4.7.2. An RFG-based example¶

In the following we will describe the concepts in more detail, using an example tool which modifies RFGs: it appends a user-defined suffix string to the Source.Name attribute of a given node. We will develop the code of the tool step by step.

Since we want to use RFG-related inputs and outputs, we have to include the module bauhaus.rfg.rfgtool.

First we add the import statements

from bauhaus.shared import bauhaustool
from bauhaus.rfg import rfgtool

at the beginning of the script.

Specifying input and output parameters¶

Let us assume the routine carrying out the modifications is called perform. For being able to transform perform into a BauhausTool, it has to use the kwargs (keyword arguments) feature of python, which delivers arguments in form of a dictionary:

def perform(**kwargs):
    x = kwargs['an_argument'] # access an_argument
    # carry out modifications

For specifying the input arguments of perform, we use the decorator

bauhaustool.BauhausTool

in front of perform like in the following code fragment, and in addition the decorator

rfgtool.with_rfg_types

The latter allows us to use RFG-related input types:

@rfgtool.with_rfg_types
@bauhaustool.BauhausTool(
# definitions of inputs here
# definition of output here
)
def perform(**kwargs):
    # carry out modifications

The second decorator takes a dictionary as its first and a string as its second argument. The second argument specifies the type of the entities the tool returns. Since we want to return an RFG as a result, we use the type rfg as return type:

@rfgtool.with_rfg_types
@bauhaustool.BauhausTool({...},
                         'rfg'
                )
def perform(**kwargs):
   ...

The first argument specifies the input values: the keys of the dictionary are the names of the input values. Its values are also dictionaries, storing information like the type of the input and its description. For example, the user has to provide the suffix she wants to attach to the source name of the node, so we add an entry for a parameter suffix:

@rfgtool.with_rfg_types
@bauhaustool.BauhausTool({

   'suffix' : {
        'doc'      : 'the suffix to be added',
        'type'     : 'string',
        'default'  : ' (Modified)'
    },
    'rfg'
})
def perform(**kwargs):
   suffix = kwargs['suffix']

The entry doc is used to specify a documentation string, type specifies the type of the input parameter and default gives a default value if no specific value for suffix is provided.

For a list of admissible input types see section Admissible input types. In perform, we can access the given value by kwargs['suffix'].

Further, we have to specify the input rfg:

@rfgtool.with_rfg_types
@bauhaustool.BauhausTool
({
    ...
    'graph' : {
        'doc'       : 'the input rfg',
        'type'      : 'rfg',
        'switches'  : ['--graph', '-r', '--rfg_graph'],
    },
    'rfg'
})
def perform(**kwargs):
    graph = kwargs['graph']

The input graph is of type rfg. If the tool is used within the processline, this input (with name graph) has a special role: it denotes the RFG that is given each of the invoked tools in sequence. If the tool is later used within a processline sequence, the processline tool is providing the argument for parameter graph automatically. However, if the tool is directly called via command line (stand-alone), graph has to be provided as a command line option. For this we can specify command line switches using the switches key which takes a list of strings as values. If switches is not given, the name of the input is used as default command line switch (here this would be --graph). Within perform, kwargs[’graph’] then contains a bauhaus.rfg.Graph object corresponding to the RFG.

As a next step we require to get the view in which the node is located, given as input parameter view:

@rfgtool.with_rfg_types
@bauhaustool.BauhausTool
({
    ...
    'view' : {
        'doc'     : 'name of a view in the graph.',
        'type'    : 'existing_view',
        'graph'   : 'graph',
        'switches': ['--used_view']
    },
    'rfg'
})
def perform(**kwargs):
    view   = kwargs['view']

The type of view is existing_view, denoting a view within an RFG which is supposed to already exist. Since there might be more than one RFG specified as input value, another entry graph is given: its value (here graph) specifies in which RFG the view has to be located. If the view could be found in the specified graph, kwargs[’view’] contains a bauhaus.rfg.View object corresponding to the given view name within the RFG ’graph’.

Finally, the user has to specify the node whose attribute she wants to modify. By using rfgtool.with_rfg_types, the input type node_path is available: an object of this type is given by a sequence of strings (delimited by /), which correspond to the values of Source.Name attributes of nodes. E.g. Modules/Calculator corresponds to a node having Calculator as Source.Name attribute, which is enclosed within a node having Modules as Source.Name, which in turn is not enclosed within another node:

@rfgtool.with_rfg_types
@bauhaustool.BauhausTool({
    ...
    'node' : {

        'doc'     : ('prefix of path to node to be copied; '
                     'use \"/\" as delimiter'),
        'type'    : ('node_path', 'view'),
    },
    'rfg'
})
def perform(**kwargs):
    node   = kwargs['node']

kwargs['node'] contains a bauhaus.rfg.Node object corresponding to the given node path.

The actual routine¶

Within perform, we already saw that we can access the input parameter by accessing the dictionary kwargs. The routine should return the modified RFG if it completed its task successfully, and otherwise it should return None. In this case, if the tool has been invoked stand-alone at the command line, it will issue an error and abort without writing the result RFG; if it is invoked by processline, the remaining tools in the sequence will not be invoked, an error will be displayed, and processline will abort without writing the current RFG to the specified output RFG location. If an error in the tool should be ignored, it is possible to just return the original RFG in the case of an error occurring in the tool.

@rfgtool.with_rfg_types
@bauhaustool.BauhausTool({...},
                         'rfg')
def perform(**kwargs):

    graph   = kwargs['graph']
    view    = kwargs['view']
    node    = kwargs['node']
    suffix  = kwargs['suffix']

    if misc.get_attr_value(node, 'Source.Name', None) is None:
        perform.warning
        ('Warning: Node "%s" has no attribute "Source.Name" set.' % node,
         perform,
         export=False)
        return None
    else:
        node['Source.Name'] = node['Source.Name'] + suffix
        return graph

The routine perform.warning outputs warnings. By default, these messages are formatted in a way which can be imported into the analysis database via the teecap tool (so it is possible to display them within the dashboard, see also section BauhausTool API). However, in this case, the argument export is set to False, and so a standard warning will be issued, in a more readable format.

If we want to use the tool from the command line, we have to add the following lines of code at the end of the file:

if __name__ == '__main__':
    perform.execute_as_command_line_tool\
        (usage='%prog [options] <resultrfg>',
         description = 'Add suffix to source name of a specified node.')

perform.execute_as_command_line_tool creates a command-line parser for the given routine automatically, using the information from the decorator. The whole example, which we will name add_node_source_name_suffix.py, then looks as follows:

#!/usr/bin/env rfgscript

from bauhaus.shared import bauhaustool
from bauhaus.rfg import rfgtool
from bauhaus import rfg
from bauhaus.rfg import misc

@rfgtool.with_rfg_types
@bauhaustool.BauhausTool({

     'graph' : {
        'doc'       : 'the input rfg',
        'type'      : 'rfg',
        'switches'  : ['--graph', '-r', '--rfg_graph']
        },

    'suffix' : {
        'doc'      : 'the suffix to be added',
        'type'     : 'string',
        'default'  : ' (Modified)'
    },

    'view' : {
        'doc'     : 'name of a view in the graph.',
        'type'    : 'existing_view',
        'graph'   : 'graph',
        'switches': ['--used_view']
    },

    'node' : {
        'doc'     : ('prefix of path to node to be copied; '
                     'use \"/\" as delimiter'),
        'type'    : 'node_path',
        'view'    : 'view',
    },
}, 'rfg')
def perform(**kwargs):

    graph   = kwargs['graph']
    view    = kwargs['view']
    node    = kwargs['node']
    suffix  = kwargs['suffix']

    if misc.get_attr_value(node, 'Source.Name', None) is None:
        perform.warning
        ('Warning: Node "%s" has no attribute "Source.Name" set.' % node,
         perform,
         'NoSourceNameAttributeSet',
         False)
        return None
    else:
        node['Source.Name'] = node['Source.Name'] + suffix
        return graph

if __name__ == '__main__':
    perform.execute_as_command_line_tool\
        (usage='%prog [options] <resultrfg>',
         description = 'Add suffix to source name of a specified node.')

Invoking the tool¶

From the Command Line¶

The script we developed in the preceding section can be called from the command line, by entering

rfgscript add_node_source_name_suffix.py --help

This results in showing the help screen:

Usage: add_node_source_name_suffix.py [options] <resultrfg>

Add suffix to source name of a specified node.

Options:
  -h, --help            show this help message and exit
  --display_config_usage
                        display an example entry in a processline config file.
  -d, --debug           output (detailed) debug information (default: False)
  -r GRAPH, --graph=GRAPH, --rfg_graph=GRAPH
                        the input rfg
  --node=NODE           prefix of path to node to be copied; use "/" as delimiter
  --suffix=SUFFIX       the suffix to be added (default: " (Modified)")
  -v, --verbose         output verbose state information (default: False)
  --used_view=VIEW      name of a view in the graph.

The switches --verbose, --debug, --display_config_usage, and --help are added automatically. A possible invocation is:

rfgscript add_node_source_name_suffix.py -r input.rfg
          --node "Model/Components/Calculator"
          --suffix=" (redundant)" --used_view Architecture output.rfg

Here the input RFG is input.rfg. The result RFG is saved to the location given as the single positional command line argument (which has to be given, since we specified rfg as return type). In this case, the resulting RFG is written to output.rfg.

From within a `processline` configuration file¶

An entry within the PROCESSLINE list of a processline config file could look as follows:

import add_node_source_name
...
PROCESSLINE = [

...

(add_node_source_name_suffix.perform, {
  'suffix' : ' (redundant)',
  'view'   : 'Architecture',
  'node'   : Model/Components/Calculator',
}),

...

]

Notice that an input value for graph does not need to be specified (and should not be given), since processline fills this special argument automatically.

For getting a template containing all inputs that can be given in a processline configuration, you can use the --display_config_usage switch:

rfgscript add_node_source_name_suffix.py --display_config_usage

gives the output

PROCESSLINE = [
    (
        __main__.perform,
        {
            'debug'   : <VALUE of type boolean>, # optional, default value is: False
                      # output (detailed) debug information

            'node'    : <VALUE of type node_path>, # required
                      # prefix of path to node to be copied; use "/" as delimiter

            'suffix'  : <VALUE of type string>, # optional, default value is:  (Modified)
                      # the suffix to be added

            'verbose' : <VALUE of type boolean>, # optional, default value is: False
                      # output verbose state information

            'view'    : <VALUE of type existing_view>, # required
                      # name of a view in the graph.

        }
    )
]

Here __main__ has to be replaced by the correct path to the tool Python module.

6.4.7.3. Tools having IR graphs as input¶

If the input of a tool includes IR graphs, the routine with_ir_types from the module

bauhaus.ir.irtool

can be used as additional decorator. It offers the input type ir for importing IR graphs. As an example we give a tool that emits a warning for each routine in a IR graph which has a pointer type as return value:

#!/usr/bin/env rfgscript

from bauhaus.shared import bauhaustool
from bauhaus.ir import irtool
from bauhaus import ir

@irtool.with_ir_types
@bauhaustool.BauhausTool({

    'ir' : {
        'doc'      : 'the IR graph',
        'type'     : 'ir',
    },
}, 'void')
def perform(**kwargs):

    ir_graph     = kwargs['ir']
    for node in ir_graph.nodes_of_type(ir.Logical.Routine):
        routine_name = node.Name if 'Name' in node.fields() else '?'
        pir_node = node.Physical
        return_type = node.Return_Type
        if return_type:
            return_type = return_type.skip_typedefs(True)
            if return_type.is_of_type('Pointer_Type'):
                perform.warning('Method "%s" uses a pointer type '
                                'as return type.' % routine_name,
                                export=True,
                                message_sloc=ir.MessageSLoc(pir_node))


if __name__ == '__main__':
    perform.execute_as_command_line_tool\
        (usage='%prog [options]',
         description = 'Outputs a warning for each method '
         'having a pointer return type.')

The tool uses the input type ir. It emits warnings in a format that can be imported into the analysis database during an analysis run, by setting export to True in the invocation of warning. The tool returns no value.

If the tool should be able to also process RFG-related inputs and outputs, the routines irtool.with_ir_types and rfgtool.with_rfg_types can be combined, as we will see in the following example. The example tool emits the same warning as the former one. Additionally, it takes the RFG derived from the given IR graph as input and copies the nodes of routines with pointer return type into a new view, given by the input pointer_routines_view. The modified RFG is then returned. The tool can also serve as part of a processline configuration.

#!/usr/bin/env rfgscript

from bauhaus.shared import bauhaustool
from bauhaus.ir import irtool
from bauhaus.rfg import rfgtool

from bauhaus import ir

@irtool.with_ir_types
@rfgtool.with_rfg_types
@bauhaustool.BauhausTool({

    'graph' : {
        'doc'      : 'the RFG graph',
        'type'     : 'rfg',
    },
    'ir' : {
        'doc'      : 'the IR graph',
        'type'     : 'ir',
    },
    'pointer_routines_view' : {
        'doc'      : 'view that will contain all routines '
        'having a pointer return type',
        'type'     : 'new_view',
        'graph'    : 'graph'
    },

}, 'rfg'))
def perform(**kwargs):

    rfg_graph             = kwargs['graph']
    ir_graph              = kwargs['ir']
    pointer_routines_view = kwargs['pointer_routines_view']

    ir_graph.connect(rfg_graph)

    for node in ir_graph.nodes_of_type(ir.Logical.Routine):
        routine_name = node.Name if 'Name' in node.fields() else '?'
        pir_node = node.Physical
        return_type = node.Return_Type
        if return_type:
            return_type = return_type.skip_typedefs(True)
            if return_type.is_of_type('Pointer_Type'):
                perform.warning('Method "%s" uses a pointer type '
                                'as return type.' % routine_name,
                                export=True,
                                message_sloc=ir.MessageSLoc(pir_node))
                rfg_node = node.rfg()
                if rfg_node:
                    pointer_routines_view.insert(rfg_node)
                # find the node
    ir_graph.disconnect()
    return rfg_graph

if __name__ == '__main__':
    perform.execute_as_command_line_tool\
        (usage='%prog [options] <resultrfg>',
         description = 'Outputs a warning for each method '
         'having a pointer return type, and creates '
         'a view containing all such methods')

6.4.7.4. BauhausTool API¶

In the following we describe the routines and class methods offered by the modules

bauhaus.shared.bauhaustool,
bauhaus.ir.irtool, and
bauhaus.rfg.rfgtool.

Module bauhaus.shared.bauhaustool¶

The class BauhausTool is the main component of bauhaus.shared.bauhaustool.

Class BauhausTool¶

The BauhausTool class offers different options for logging purposes and invoking the tool from the command line.

error(self, message,
export=True,
errortype=’Error’,
ruleclass=’BauhausTool’,
message_sloc=None,
argument_dict=None)

Outputs an error, specified by the string message. If export is set to true, the format of the message will be in a format that the tool teecap is capable to process as error message and therefore the message will be inserted into the analysis database if the tool is used within a CI run. By using the optional arguments errortype and ruleclass, specific error types and rule classes can then be given. Additionally, a source location (of type bauhaus.shared.MessageSLoc or a subtype thereof) can be given by the argument message_sloc. If export is set to false, the message will be outputted as a logging message of level ERROR using the Python logging module. In this case, it is possible to also give the argument argument_dict=None, to support debugging: all elements and keys in argument_dict are then printed after the error message.

warning(self, message,
export=True,
errortype=’Warning’,
ruleclass=’BauhausTool’,
message_sloc=None)

Similar to error, but prints a warning message (resp. logging message of level WARNING) instead of an error message. In contrast to error, no argument argument_dict can be given.

info(self, message,
export=False,errortype=’Warning’,ruleclass=’BauhausTool’,
message_sloc=None)

Similar to error, but prints an info message (resp. logging message of level INFO) instead of an error message, where printing a logging message is the default. If export is false, a warning will only be printed if the verbose mode is enabled (by setting the input verbose to true). In contrast to error, no argument argument_dict can be given.

debug(self, message,
export=False,
errortype=’Warning’,
ruleclass=’BauhausTool’,
message_sloc=None)

Similar to error, but prints a debug message (resp. logging message of level DEBUG) instead of an error message, where printing a logging message is the default. If export is false, a warning will only be printed if the verbose mode or the debug mode is enabled (by setting the input verbose resp. debug to true). In contrast to error, no argument argument_dict can be given.

execute_as_command_line_tool(self,usage,description)

Performs the following steps:

Creates a command line parser using a usage string describing the syntax of its command line arguments and a description string stating the purpose of the tool,
parses command line arguments,
transforms them into arguments for a call of self (recall that an instance of BauhausTool is callable),
executes the tool with the computed arguments, and
processes a potential return value.

Returns the result of the invocation of the tool if successful, None otherwise.

Module bauhaus.ir.irtool¶

The module bauhaus.ir.irtool exposes the following routines:

with_ir_types(tool)

Allows a tool tool (of type or subtype BauhausTool to use IR-related input types. For an example see section Tools having IR graphs as input.

Module bauhaus.rfg.rfgtool¶

The module bauhaus.rfg.rfgtool also exposes the following routines:

with_rfg_types(tool)

Allows a tool tool (of type or subtype BauhausTool to use RFG-related input and output types.

6.4.7.5. Admissible result types¶

Currently, the only return types supported by BauhausTool are

void: The tool is expected to return nothing (or always None)
rfg (if with_rfg_types is used): The tool is expected to return a RFG object.

6.4.7.6. Admissible input types¶

Input type “boolean”¶

Contained in: BauhausTool, RFGTool, IRTool.

Example declaration:¶

'use_recursive':  {
    'doc'      : 'Do the transformation recursively',
    'type'     : 'boolean',
    'switches' : ['--transform_recursively'],
    'default'  : False,
}

Command line usage:¶

A boolean value, given by supplying the command line switch, e.g --transform_recursively.

Config file usage:¶

A Python bool value, e.g. True.

Resulting argument:¶

A Python bool value, e.g. True.

Input type “existing_view”¶

Contained in: rfgtool.with_rfg_types.

For an input of type existing_view the following dependent input values have to be specified: graph of type rfg.

Example declaration:¶

'processed_view' : {
    'doc'      : 'Name of the processed view',
    'type'     : ('view', 'graph')
    'switches' : ['--processed_view'],
    'default'  : ['Entries'],
}

Command line usage:¶

The name of an already existing view in an RFG file, e.g. –processview=”Architecture”.

Config file usage:¶

The name of a RFG view in an RFG file as Python string, e.g. 'Architecture'.

Resulting argument:¶

A Python object of type bauhaus.rfg.View.

Input type “existing_views”¶

Contained in: rfgtool.with_rfg_types.

For an input of type existing_views the following dependent input values have to be specified: graph of type rfg.

Command line usage:¶

The names of already existing views in an RFG file, e.g. --old_views="A" --old_views="B".

Input type “file”¶

Contained in: BauhausTool, RFGTool, IRTool.

Example declaration:¶

'xmifile' : {
    'doc'      : 'The input XMI file',
    'type'     : 'file',
    'switches' : ['--xmifile'],
}

Command line usage:¶

A filename, e.g. --switch /path/to/file.

Config file usage:¶

A filename string, e.g. '/path/to/file'.

Resulting argument:¶

A Python object of type file.

Input type “filename_list”¶

Contained in: BauhausTool, RFGTool, IRTool.

Example declaration:¶

'dirs' : {
    'doc'      : 'Directories in which to look for XMI files',
    'type'     : ('filename_list_by_dirs', 'xmi_endings')
    'switches' : ['--dir'],
    'default'  : [],
}

Command line usage:¶

A sequence of directory paths, e.g. --dir /projects/alpha --dir /projects/beta.

Config file usage:¶

A sequence of directory paths as strings, e.g. ['/projects/alpha', '/projects/beta'].

Resulting argument:¶

A Python object of type list of string, containing all the file names contained recursively within one of the directories, having a file ending corresponding to the first given argument of the input parameter.

Input type “filename_list_by_dirs”¶

Contained in: BauhausTool, RFGTool, IRTool.

For an input of type filename_list_by_dirs the following dependent input values have to be specified: extensions of type string_list.

Example declaration:¶

'dirs' : {
    'doc'        : 'Directories in which to look for XMI files',
    'type'       : 'filename_list_by_dirs',
    'extensions  : 'xmi_extensions',
    'switches' : ['--dir'],
    'default'  : [],
}

Command line usage:¶

A sequence of directory paths, e.g. --dir /projects/alpha --dir /projects/beta.

Config file usage:¶

A sequence of directory paths as strings, e.g. ['/projects/alpha', '/projects/beta'].

Resulting argument:¶

A Python object of type list of string, containing all the file names contained recursively within one of the directories, having a file ending corresponding to the first given argument of the input parameter.

Input type “filename_list_by_response_files”¶

Contained in: BauhausTool, RFGTool, IRTool.

Example declaration:¶

xmi_files' : {
    'doc'      : 'XMI files given in form of response files',
    'type'     : 'filename_list_by_response_files',
    'switches' : ['--response_file'],
    'default'  : [],
}

Command line usage:¶

A sequence of filenames of response files, e.g. --response_file first.rsp --response_file /path/to/second.rsp.

Config file usage:¶

A sequence of filenames as strings, e.g. ['first.rsp', '/path/to/second.rsp'].

Resulting argument:¶

A Python object of type list of string, containing all the file names given within the response files.

Input type “integer”¶

Contained in: BauhausTool, RFGTool, IRTool.

Example declaration:¶

'attempts' : {
    'doc'      : 'Number of attempts',
    'type'     : 'integer',
    'switches' : ['--attempts'],
    'default'  : 2,
}

Command line usage:¶

An integer value, given as string, e.g --attempts 1.

Config file usage:¶

An integer value, e.g. 1.

Resulting argument:¶

A Python int object.

Input type “ir”¶

Contained in: irtool.with_ir_types.

Example declaration:¶

'graph' : {
    'doc'      : 'The input IR file',
    'type'     : 'ir',
    'switches' : ['--ir', '--ir_graph'],
}

Command line usage:¶

A filename of an IR file, e.g. --ir /path/to/ir.

Config file usage:¶

IR file given as a filename string, e.g. '/path/to/ir'.

Resulting argument:¶

A Python object of type bauhaus.ir.Graph.

Input type “new_view”¶

Contained in: rfgtool.with_rfg_types.

For an input of type new_view the following dependent input values have to be specified: graph of type rfg.

Example declaration:¶

'processed_view' : {
    'doc'      : 'Name of the processed view',
    'type'     : ('view', 'graph')
    'switches' : ['--processed_view'],
    'default'  : ['Entries'],
}

Command line usage:¶

The name of a new view in an RFG file, e.g. --processview="Architecture".

Config file usage:¶

The name of a RFG view in an RFG file as Python string, e.g. 'Architecture'.

Resulting argument:¶

A Python object of type bauhaus.rfg.View.

Input type “node_path”¶

Contained in: rfgtool.with_rfg_types.

For an input of type node_path the following dependent input values have to be specified: view of type existing_view.

Example declaration:¶

'root' : {
    'doc'      : 'Root node of the architecture',
    'type'     : ('node_path', 'architecture_view')
    'switches' : ['--root_node'],
    'default'  : ['Architecture/Model'],
}

Command line usage:¶

A string denoting the source names from a root node to an existing node delimited by /, e.g. --root_node "Architecture/Model1/Components/Sensor".

Config file usage:¶

A Python string denoting the source names from a root node to an existing node delimited by /, e.g. --root_node "Architecture/Model1/Components/Sensor".

Resulting argument:¶

A Python object of type bauhaus.rfg.Node.

Input type “rfg”¶

Contained in: rfgtool.with_rfg_types.

Example declaration:¶

'graph' : {
    'doc'      : 'The input rfg',
    'type'     : 'rfg',
    'switches' : ['--graph', '-r', '--rfg_graph'],
}

Command line usage:¶

A filename of an RFG file, e.g. --graph /path/to/rfg.

Config file usage:¶

RFG file given as a filename string, e.g. '/path/to/rfg'.

Resulting argument:¶

A Python object of type bauhaus.rfg.Graph.

Input type “string”¶

Contained in: BauhausTool, RFGTool, IRTool.

Example declaration:¶

'suffix' : {
    'doc'      : 'Suffix for newly created nodes',
    'type'     : 'string',
    'switches' : ['--suffix'],
    'default'  : '',
}

Command line usage:¶

A string value, e.g --suffix simple.

Config file usage:¶

A Python string value, e.g. 'simple'.

Resulting argument:¶

A Python string object.

Input type “string_list”¶

Contained in: BauhausTool, RFGTool, IRTool.

Example declaration:¶

{
    'xmi_endings' : {
    'doc'      : 'Possible endings of XMI file names',
    'type'     : 'string',
    'switches' : ['--xmi_ending'],
    'default'  : ['xmi', 'xml'],
}

Command line usage:¶

A sequence of strings, e.g. --xmi_ending first --second.

Config file usage:¶

A list of strings, e.g. ['first', 'second'].

Resulting argument:¶

A Python object of type list of string.

Input type “view”¶

Contained in: rfgtool.with_rfg_types.

For an input of type view the following dependent input values have to be specified: graph of type rfg.

Example declaration:¶

'processed_view' : {
    'doc'      : 'Name of the processed view',
    'type'     : ('view', 'graph')
    'switches' : ['--processed_view'],
    'default'  : ['Entries'],
}

Command line usage:¶

The name of a RFG view in an RFG file, e.g. --processview="Architecture".

Config file usage:¶

The name of a RFG view in an RFG file as Python string, e.g. 'Architecture'.

Resulting argument:¶

A Python object of type bauhaus.rfg.View.

6.4.7. RFG and IR operations with BauhausTool (deprecated)¶

6.4.7.1. An example using BauhausTool¶

6.4.7.2. An RFG-based example¶

Specifying input and output parameters¶

The actual routine¶

Invoking the tool¶

From the Command Line¶

From within a processline configuration file¶

6.4.7.3. Tools having IR graphs as input¶

6.4.7.4. BauhausTool API¶

Module bauhaus.shared.bauhaustool¶

Class BauhausTool¶

Module bauhaus.ir.irtool¶

Module bauhaus.rfg.rfgtool¶

6.4.7.5. Admissible result types¶

6.4.7.6. Admissible input types¶

Input type “boolean”¶

Example declaration:¶

Command line usage:¶

Config file usage:¶

Resulting argument:¶

Input type “existing_view”¶

Example declaration:¶

Command line usage:¶

Config file usage:¶

Resulting argument:¶

Input type “existing_views”¶

Command line usage:¶

Input type “file”¶

Example declaration:¶

Command line usage:¶

Config file usage:¶

Resulting argument:¶

Input type “filename_list”¶

Example declaration:¶

Command line usage:¶

Config file usage:¶

Resulting argument:¶

Input type “filename_list_by_dirs”¶

Example declaration:¶

Command line usage:¶

Config file usage:¶

Resulting argument:¶

Input type “filename_list_by_response_files”¶

Example declaration:¶

Command line usage:¶

Config file usage:¶

Resulting argument:¶

Input type “integer”¶

Example declaration:¶

Command line usage:¶

Config file usage:¶

Resulting argument:¶

Input type “ir”¶

Example declaration:¶

Command line usage:¶

Config file usage:¶

Resulting argument:¶

Input type “new_view”¶

Example declaration:¶

Command line usage:¶

Config file usage:¶

Resulting argument:¶

Input type “node_path”¶

Example declaration:¶

Command line usage:¶

Config file usage:¶

Resulting argument:¶

Input type “rfg”¶

Example declaration:¶

Command line usage:¶

Config file usage:¶

Resulting argument:¶

Input type “string”¶

Example declaration:¶

Command line usage:¶

Config file usage:¶

Resulting argument:¶

Input type “string_list”¶

Example declaration:¶

6.4.7.1. An example using `BauhausTool`¶

From within a `processline` configuration file¶