1.4.64. Migration to 7.0.0

Note

If you have C++ code and you want to migrate from old versions (particularly older than 6.6), it is highly recommended to first migrate to 6.9.x before migrating to 7.0.0.

Caution

Version 7.0.0 comes with some breaking changes in the configuration compared to previous versions. Therefore please read the following instructions carefully and follow the general guidelines, e.g. to evaluate it first on a test system.

Caution

Starting with version 7.0.0 we do no longer support 32-bit Intel x86 architecture.

Caution

When migrating to 7.0.0 you should first do the migration steps described here. The additional migration steps described in Migration to new Configuration System are optional for now. Please note that this is supported in version 7.0 to simplify the upgrade to the new version, but the old configuration files are deprecated now and a future release will drop support for them.

1.4.64.1. Automatic Migration

We provide a new tool migrate to help with the migration. For the minimal migration, use the migrate 7_0 subcommand. This automates some (but not all) of the steps in the following sections.

1.4.64.2. Python Scripting

One of the biggest changes is the support of Python 3 and the end of life of support for Python 2 in the Axivion Suite. We are now supporting all official Python 3.7 and 3.8 releases. Please make sure to have any Python 3.7.x or 3.8.x installed in the standard locations of your operating system. Note that from Axivion Suite 7.2.0 on, Python 3.9 is also supported.

Please make sure the variables BAUHAUS_PYTHON and BAUHAUS_PYTHON_LIB are not pointing to a Python version older than the 3.7.0 release.

Please also migrate your configuration files, custom rules and scripts to Python 3. Refer to https://docs.python.org/3/howto/pyporting.html or https://portingguide.readthedocs.io/en/latest/ for directions on porting your existing code to Python 3.

1.4.64.3. Java

The support of Java 7 for running the Axivion Suite Java tools has been removed. Now, Java 8 is the required minimum version.

The Axivion Suite Java tools now need a 64 bit JVM to run. Notable exceptions are the Axivion Eclipse Plugin and rpy2rfg to allow them to run in their host environment, even if Eclipse or Rhapsody are still 32 bit.

1.4.64.4. Stylechecks

The stylecheck tool will now validate that configuration options exist and that the assigned value has a compatible type.

Note

This means your existing configuration may fail now due to configuration errors which are detected with Axivion Suite 7.0. This can also happen for configurations being too broad, for example a loop like the following now fails if not all rules have the attribute:

Setting an attribute for all rules may fail now
for rule in RULES:
   rule.attribute = value

The solution for such a case is to check whether the rule actually has the attribute before attempting to set it:

Setting an attribute after checking that the attribute exists
for rule in RULES:
   if hasattr(rule, 'attribute'):
      rule.attribute = value

If you formerly used the justification_checker option of a rule, there is a small change now: The second parameter can be any issue type, not just a style violation.

Many configuration options that previously were of type list are now using type set. If you are calling .append() or operator += on the option’s default value, you will need to adjust your configuration to instead use .add() or operator |=. Assignments that replace the whole set with a list are still valid; the stylecheck framework will internally convert the assigned value to a set.

Rule names must be unique now. This was previously not enforced, but the new configuration system now requires and checks this constraint. This has an impact in case you formerly redefined the name of more than one rule to the same name in your configuration, like this:

Previously accepted, now rejected approach to use the same rule name
RULES['rule-1'].rulename = 'CommonName'
RULES['rule-2'].rulename = 'CommonName'

In these cases you will have to define a small composite rule instead of reconfiguring the rulename. Such a rule looks like the following (the required Python class names for the combined rules can be found by looking into the Python source code of these rules):

Composite rule to have two different rules report under the same name
from axivion import analysis
from rule1location import rule1 # replace with the proper Python module/package
from rule2location import rule2 # replace with the proper Python module/package

@analysis.rule('CommonName')
class CommonNameRule(analysis.CompositeRule):  # choose a class name
   _parts = [rule1.Rule1Rule, rule2.Rule2Rule] # use the Python class names
   title = '''The title for the composite rule'''

Renamed Rule Options

Some rule options were renamed. These need to be adapted as the stylecheck tool now validates the configuration and will report hard errors on unknown rule options.

Old option name

New option name

individual_includes

includes

individual_excludes

excludes

Options for individual rules

RULES['Generic-LineBreaks'].excluded_files: This option no longer exists. Please use the excludes option on the rule instead.

RULES['MisraC++-2.10.1'].distinguish_c_name_spaces: The default value changed from True to False. This usually results in additional violations. You may want to re-enable the option; or instead you might want to enable the new distinguish_type_names option, which is more suitable for C++ code.

RULES['AutosarC++*-A5.2.6'].require_postfix_epression, RULES['AutosarC++*-M5.2.1'].require_postfix_epression, RULES['MisraC++-5.2.1'].require_postfix_epression, RULES['MisraC-12.5'].require_postfix_epression : This option was renamed to require_postfix_expression to fix a typo in the rule option.

RULES['AutosarC++*-A7.1.1'].only_immutable_data: This option no longer exists. The clause in the Autosar specification is ill-defined, this rule now finds the same violations as MisraC++-7.1.1.

Package renaming of elementary rules

Note

Only relevant if you have custom rules implemented.

Internal/elementary stylecheck rules previously were accessible via the Python packages autosar, axivion, cert, generic, internal, misra, parallelism, and utils. If you have custom stylecheck rules that you implemented yourself, or were implemented for you by Axivion as part of a service agreement, imports in these rules have to be adapted to the new package structure. All packages were moved into the package bauhaus.rules, resulting in the following mapping:

Old package name

New package name

autosar

bauhaus.rules.autosar

axivion

bauhaus.rules.axivion

cert

bauhaus.rules.cert

generic

bauhaus.rules.generic

internal

bauhaus.rules.internal

misra

bauhaus.rules.misra

parallelism

bauhaus.rules.parallelism

utils

bauhaus.rules.utils

For custom rules that directly derive from bauhaus.style.Rule or bauhaus.style.AxivionCustomerRule, you can keep using your existing rule (with only minimal adjustments for Python 3 / other API changes). For custom rules that derive from other base classes (including all rules in the packages being renamed), your rule class will need to be adjusted to the new stylecheck framework, see Migrating additional stylechecks and metrics for more details.

Note

The migrate 7_0 command can help with porting custom stylecheck rules. It will automatically adjust imports of the package names in this section.

1.4.64.5. Code Annotations (Control Comments, Justifications)

If you’re using a custom analysis_config.py, check your import statements in it: imports of the form import actions have to be updated to be either from . import actions or from bauhaus.analysis_results.control_comments import actions.

1.4.64.6. IR

The misspelt attribute Catched_Type of LIR class CFG_Catch_Type now correctly reads Caught_Type. The same fix was made in other places (iranalysis scripting interface, stylecheck naming). If your code accesses these elements, you will have to correct the name in your code as well.

The classes Default_Constructor_Definition and Default_Constructor_Declaration were removed. Default constructors now use the same IR node type as other constructors. Use the special_routines.is_default_constructor(node.Logical) helper function to determine whether a constructor is a default constructor.

The representation of pragmas in the IR was changed: The node type Named_Pragma was removed; uses of it can be replaced with the base class Pragma. The pragma parameters are now stored in the original source code form in the Pragma.Text field; the old field Pragma.Parameters is no longer available.

1.4.64.7. Linker

The linker now distinguishes routine and variable type differences due to implicit-int rules from differences in explicitly provided declarations. This results in new message keys for the cases with an implicit function declaration or an implicit-int type selection. If you previously used message keys for type differences, you might now also have to use the new ones.

1.4.64.8. Database Tool

The tool database (in your build.conf) does not support the parameters

  • base_view

  • hierarchy_view

  • propagate_metrics

  • only_violations

anymore. They can be removed from your build.conf. They were needed for the import of metric violations and the metric propagation. Now, both is handled by the metrics itself, see Metrics migration.

1.4.64.9. Git Submodules

There is now native support for git submodules. If you have submodules configured in build.conf as independent VCS entries, these VCS entries will not be respected anymore and should be removed. Please note that paths into the submodules cannot be shown in the dashboard until a fresh analysis is run with the new version of Axivion Suite.

1.4.64.10. Metrics

Tools metric_rfg and metric_filter

The metric calculation and the filtering of the desired metrics with the tools metric_rfg and metric_filter were deprecated since Axivion Suite 6.5. These tools have been removed now.

The metric computation is part of the tool stylecheck now. To configure the metric checks, use the tool metric in your build.conf and configure the metric rules in the file metric_config.py.

The removal of the tools metric_rfg and metric_filter caused the removal of several inputs of the database. See Database Tool migration to remove them if they are present.

In the old metric framework, all metrics were read from the same base view in the RFG. The default one is Code Facts. This caused missing metric violation of the metrics Metric.Lines.File.* because they are annotated on nodes in a different view. The new metric rules fix this bug: the metrics Metric.Lines.File.* work on the view Includes by default.

Some tools calculate metric values which are written to the RFG. The metric rules executed by metric need to read these metric values from the RFG. So it is best to do the metric computation directly before the tool database.

Example:

Old:

<action tool="metric_rfg" name="metric_rfg" />

<action tool="metric_filter" name="metric_filter" />

New:

<action tool="metric" name="metric" />

If you are using metrics in the default configuration (like the example above), the default configuration of the tool metric should compute the same result.

The selection which metrics are reported is done by the metric rules now. So no metric_filter is needed anymore. That means also that no metrics are deleted from the RFG anymore, while the dashboard still only shows the metrics you have selected.

If the following paragraph does not make sense to you, with very high probability you will not be affected by the change.
Formerly, metric propagation was done on the hierarchy view and the aggregated metric values were read from the base view to import them into the database (and finally show them in the dashboard). In the default configuration this resulted in only importing the aggregated values at the system node. In contrast, the new metrics do the propagation and the import of the aggregated metric values on the hierarchy view. This makes it possible to import all aggregated values into the database (but you are not able to view them in the dashboard). By default, only aggregated values at the root nodes of the hierarchy view are imported - which is the system node.

Tool metric

New baseclass for self-written metrics

A new base class for metrics (axivion.style.metric.MetricBase) replaces the old metric base class. If you wrote your own metric rules, you need to adapt them to the new base class. The example metric templates/projectconfig/generic/example_metric.py is updated accordingly. If you just want to read a metric from an RFG attribute, you can use the metric Metric-Template. It can be instantiated with axivion.config.get_analysis().copy to avoid cloning the code.

Deprecated metric rules

The rules Metric-Fan.In, Metric-Fan.Out, Metric-TokenFileMetric, and Metric-TokenMetric have been deprecated.

  • Metric-Fan.In is superseded by:

    • Metric-Fan.In.Call

  • Metric-Fan.Out is superseded by:

    • Metric-Fan.Out.Call

  • Metric-TokenFileMetric is superseded by:

    • Metric-TokenFileMetric.Check

    • Metric-TokenFileMetric.Debug

    • Metric-TokenFileMetric.Fixme

    • Metric-TokenFileMetric.Hack

    • Metric-TokenFileMetric.Todo

    • Metric-TokenFileMetric.XXX

  • Metric-TokenMetric is superseded by:

    • Metric-TokenMetric.Check

    • Metric-TokenMetric.Debug

    • Metric-TokenMetric.Fixme

    • Metric-TokenMetric.Hack

    • Metric-TokenMetric.Todo

    • Metric-TokenMetric.XXX

The old, now deprecated, metric rules were configured with a dictionary. Now, the configuration system allows to conveniently create new instances of rules. So the dictionary workaround is not necessary anymore. Instead, the new rules are configured directly.

TokenFileMetrics

Formerly, the TokenFileMetrics read their metric value from the RFG (e.g. Metric.TokenMetric.Todo) and reported them under a different name (e.g. Metric-TokenFileMetric.Todo) to the Dashboard. This caused problems with the metric propagation. Now, they also store the metric value with the new name into the RFG. The metric propagation only uses the new name.

Changed configuration options

The metric rules Metric-HIS.LEVEL, Metric-HIS.PATH, and Metric-HIS.VG allow to change the metric on which they are based. This was done with the configuration option alias_for—which is now removed. The configuration is now done with the options rfg_metric_name and alias_name. The new option alias_name specifies the name of the metric in the Dashboard. It is also used to copy the metric value to a node attribute with this name in the RFG. This is what rfg_metric_name did before. rfg_metric_name now specifies the metric on which the HIS metric is based (the metric which is read from the RFG)—this is what alias_for did before.

To sum up for this three rules:

  • If you did not configure rfg_metric_name or alias_for, nothing changes.

  • rfg_metric_name → alias_name

  • alias_for → rfg_metric_name

Additionally, if you are using one of the metrics Metric-HIS.CALLING, Metric-HIS.CALLS or equivalently, Metric-Number_Of_Called_Routines or Metric-Number_Of_Calling_Routines together with ir2rfg’s option --consider_dynamic_calls_in_metrics: This option is now an option of the above-listed metrics and must be set in the metric configuration. It can now be set to different values for these metrics. As bugs have been fixed during the implementation of this change, there can be a difference now in the reported set of violations of these rules, especially for the number of incoming calls of methods in C++ programs.

Changing the display name of the issue count metrics

The configuration of the display names of the issue count metrics

  • Metric.Violations.Architecture

  • Metric.Violations.Architecture.disabled

  • Metric.Violations.Clone

  • Metric.Violations.Clone.disabled

  • Metric.Violations.Cycle

  • Metric.Violations.Cycle.disabled

  • Metric.Violations.Dead_Entity

  • Metric.Violations.Dead_Entity.disabled

  • Metric.Violations.Metric

  • Metric.Violations.Metric.disabled

  • Metric.Violations.Style

  • Metric.Violations.Style.disabled

via the Metrics.config has been deprecated. Please use the rules

  • Metric-IssueCount.Architecture

  • Metric-IssueCount.Clone

  • Metric-IssueCount.Cycle

  • Metric-IssueCount.Dead_Entity

  • Metric-IssueCount.Metric

  • Metric-IssueCount.Style

instead.

Tool csv2rfg

The tool csv2rfg has been deprecated and will be removed in the future. To import metric values from a CSV file into an RFG, you can use the rule RFG-ImportCSV.

Metric Metric-Lines.File.Comment

The default value of the max_value is now None, which means no upper limit. Previously, it was 800.

1.4.64.11. Dashboard Server

IPv6 Support

The Dashboard now supports IPv6 and defaults to binding on both IPv4 and IPv6 of all available interfaces instead of only their IPv4 addresses. This means, that with a default configuration network related behavior can change and you might need to adjust your firewall settings. If you want or need the dashboard to behave like before in this respect you can set the new dashboard2.config configuration option /dashboard2/EmbeddedTomcat/IPPreference to ForceIPv4.

Start Script

The Script dashserver.py is now available as an alternative to the script dashserver2.py. The old name is now deprecated and may be removed in a future version.

Windows Service

The Windows Service integration has changed fundamentally and thus a reinstallation of the service is necessary. If you haven’t done any special service configuration, the usual command sequence should be sufficient in an Axivion-Command-Prompt running as Administrator:

  • cd <dashboard-configuration-directory>

  • dashserver uninstall

  • dashserver install

This assumes that the service has been properly stopped, otherwise a reboot may be necessary before the install-command can succeed.

Note that the install-flag --forcejvm does not exist any more. Instead the service will now respect the dashboard2.config-option /dashboard2/EmbeddedTomcat/JreHome.

The two install-flags --prestartcommand and --poststopcommand have been removed as well in favor of the two dashboard2.config-options /dashboard2/PreStartCommand and /dashboard2/PostStopCommand. Also note that the commands are now executed with the Dashboard configuration directory as working directory and that the quoting rules have changed. Basically, they are now simpler and behave the same way as if you were typing the command directly into a cmd-shell. In most cases, the changed quoting rules should not make any difference.

Previously the dashboard service could be started with LOCAL SYSTEM user. This is discouraged and does not work any more. Please assign a specific “Log On” user account to the dashboard service.

Stricter CORS (security)

The server-side CORS-checking now also checks the protocol when comparing origins. This means, that the difference between http:// and https:// becomes relevant.

As a consequence you may be required to take action when running a http-Dashboard behind a https web-proxy. Note, that running a https-Dashboard behind a http web-proxy is not supported. We support the forwarding of the original origin both via the standardized Forwarded header or via the semi-standard X-Forwarded-Host and X-Forwarded-Proto headers. If your proxy was not setting the proto-part of the Forwarded-header or likewise it was not setting X-Forwarded-Proto but X-Forwarded-Host, you should adjust your proxy server configuration to include this configuration.

If adjusting your proxy server’s configuration in this way is not possible for some reason, you can also configure the proxy URL as an additional allowed CORS origin. Keep in mind though, that path, query and fragment of an URL is not considered for origin matching, which means that other sites proxied by the same proxy using the same domain might be able to read data from the Dashboard.

Dashboard API

The XML output format of the Dashboard JSON API has been removed and is no longer available. If you were still using it, please change your scripts in order to use the JSON output format which is completely analogous in its structure.

Dashboard Notifications

Analysis setups running with Axivion Suite 6.5.x or older will not be able to inform the Dashboard of new versions or trigger the sending of erosion notification mails any more. In this constellation the analysis results will still be visible in the Dashboard, but there may be a delay before the UI shows the new results.

Automatic Project Sorting By Name

Where applicable, new Dashboard configurations will show the project list automatically sorted by name. Existing configurations will need to explicitly enable this new behavior via a new option on the projects configuration page.

Auto-Generated Administrator Password

For newly created Dashboard configurations the default administrative account is not admin/password any more. The password is now randomly generated and only printed out once to the console. If you are programmatically generating Dashboard configurations, retrieving the administrative credentials or programmatically setting the administrator password is supported via the Dashboard Setup API.

1.4.64.12. Axivion Eclipse Plugin

The minimum required version to run the Axivion Eclipse Plugin is raised to 4.2 (Juno). The plugin will not run with 3.7 (Indigo) anymore.

1.4.64.13. Local Build

At the time of the local build, the current value of the environment variable BAUHAUS_PYTHON is stored. When a BAUHAUS_PYTHON variable is stored, the plugin will set it for the local Dashboard when the plugin starts the local Dashboard.

When doing an in-place upgrade from Axivion Suite 6.9 (requires Python 2.7.x) to Axivion Suite 7.0 (requires Pythoon 3.7.x or Python 3.8.x), the old value can prevent the start of the local Dashboard. Use local_build_config [--project PROJECT] [--version VERSION] python set "path/to/python.exe" to adjust the local build configuration.

This is only needed for already existing local builds. Another way to fix the local build is to just re-run it with the new Axivion Suite version.

1.4.64.14. Architecture Analysis - Rhapsody

Removed Tools

The tools

  • rhapsodyxmi_to_rfg

  • rpy_to_rfg

  • rhapsodyxmi2rfg

  • xmi2rfg4.py

have been removed. Please use the processline tool rpy2rfg to import a Rhapsody model into an RFG.

rpy2rfg

Installation/Start

The tool rpy2rfg now only runs as Rhapsody plugin. The option --no_plugin and the corresponding start mode have been removed. Please use the plugin mode to run rpy2rfg - which is used by default without additional arguments.

Furthermore, the files needed to install rpy2rfg via profiles have been removed. Starting from Rhapsody 8.2, rpy2rfg internally uses a Rhapsody command to make it known to Rhapsody. So no installation is needed anymore. If you already installed rpy2rfg, please have a look at Installation of the Rhapsody plugin.

Import Defaults

The Rhapsody API method IRPTransition.itsCompoundSource has been added to the list of methods ignored by default. This means that rpy2rfg will not import edges caused by this method anymore by default. Because these edges are not used in the architecture analysis, this should not affect the results. It they are needed nevertheless, they can be reenabled with the option --enable_rhapsody_methods. IRPTransition.itsCompoundSource has been disabled by default because of common problems with stackoverflows.

1.4.64.15. Architecture Analysis - Enterprise Architect

Importing an EA-based architecture can now be done by using the rule Architecture-EAImporter, and, for backwards compatibility, by using the processline tool eaxmi11_to_rfg. They use the same import functionality, so switching from the processline tool to the rule should not cause problems.

Removed Tools

The scripts/tools

  • eaxmi112rfg.py

  • saxeaxmi112rfg.py

  • eaxmi212rfg.py

  • xmi2rfg.py

  • xmi2rfg2.py

  • eaxmi2rfg.py

have been removed. Please use the rule Architecture-EAImporter respectively the processline tool eaxmi11_to_rfg to import an Enterprise Architect model into an RFG.

1.4.64.16. CafeSharp

The names of source code entities representing C# property and method accessors get, set, add, remove have been changed to get_XXX, set_XXX, add_XXX, remove_XXX (with property name XXX). This may cause periodic variations (wobbler) for stylechecks, metric violations, dead code and architecture violations.