What are Modules in CAST AIP

Applications and Modules

The CAST Application Intelligence Platform (AIP) reports grades and metrics for each Application which is declared in the system. You'll be able to deliver incremental versions of the application source code, analyze each of them, and get a value for each metric of the CAST Assessment Model for that version. This is what is called a Snapshot of the application.

In order to obtain grades and metrics with a finer granularity, it is possible to define Modules within each application. Very simply, Modules are subsets of the application, i.e. pieces of it. AIP will calculate the grades and metrics for each of the existing Modules of the application, in addition to the default, application-level calculation.

AIP imposes few constraints on the way modules are configured. They can overlap, they don't have to cover the full application. The rest of this section will explain how the configuration of modules interacts with the other features in AIP.

Modules and application boundaries

In AIP, the Modules define what is called the Application Boundaries. That is, the union of all the modules will be considered as the perimeter to be measured in that Application. Parts of the Application which are not in any modules will not be considered for the application level metrics

• For quality measurements, violations on objects which are outside the boundaries are not included in the grades and metrics. In fact, the objects themselves are not considered, see this page for details on how the grades are computed.
• For AFP measurments, objects which are outside the boundaries will not be considered part of the set of Entry Points, Data Entities or End Points. However, they can still be considered as part of the transaction graph. See this page for details on the AFP calculation. 
• For AEP measurments, objects which are outside the boundaries will not be considered as part of the extended call graph, so changes to those objects will not count as enhancement effort. See this page for details on the AEP calculation.

Modules and grades

Since AIP 8.1, when using the default analysis parameters, there is no relationship between the grades of each module and the grade reported for the full application. Each are calculated independently, as described in this page.

AIP also supports alternative grades calculation modes, where the application grades are calculated as averages of the grades of its modules. These modes can be enabled in the CAST Management studio:

Visibility of Modules in the AIP Dashboards

The CAST AIP Dasboards leverage the split of each application module to offer better analytics and drill-down capabilities into the quality of the code.

The Health Dashboard (HD) has a dedicated "Modules treemap" screen, where each module is shown, colored according to one of the Health Factor (TQI, Security, Robustness ...), and sized according to one of the main sizing measures (Lines of Code, Function points ...). The metrics to be used for coloring and sizing can be changed at will.

The Health Dashboard also supports having a miniature version of that modules treemap as a tile in the Application Overview page:

In the Engineering Dashboard (ED), when analyzing the quality rule violations reported for the application in the Risk Investigation view, it is possible to restrict the current view to a given module of the application:

The Engineering Dashboard also supports a specific tile in the home page of each application, showing the modules with the most quality rule violations:

Modules and background facts

CAST AIP supports what is called "Background Facts". They are metrics like the other grades and measurements, but they are not calculated by AIP. Instead, you can manually inject the correct value in to each snapshot of the application. They can be used for external metrics such as development cost, headcount or number of defects. They will they shown in the AIP dashboards together with the regular grades, for easier interpretation.

Like the other AIP metrics, background facts can be given at the level of the application and for each module when modules are defined.

For more details, please refer to this page. 

How to configure Modules

This section will describe how to use the options available in Cast Management Studio for configuring modules. See also the CMS help "Define a User Defined Module" for more details and screenshots.

Simple Modules options

As noted above, the default analysis configuration considers the full application as a single module, called the "Full Application Module". Note that It is possible to keep the creation of this "Full application module", even when finer-grain modules are defined. It is one way to force the application boundaries to match the complete application.

AIP also has an option to automatically create a module for each Analysis Unit of the Application. It is a good way to get a module organization which is close to your project organization, since the analysis units are based on the structure of the source code, schema or build configuration. However, this will make the module definition unstable, since it becomes dependent on changes of the underlying source code. In big projects, it can also result in a huge number of modules.

Custom modules definition based on filters

Filtering options

The configuration of custom modules is based on Object Filters. Filters are a set of criteria which define the Primary Objects to be included in a custom module. Any object in the application model matching those criteria will be considered as a primary object.

It is possible to associate several object filters to a given module; objects matching any of the filters will be included (object filters are applied with a logical OR).

The following criteria are supported in the object filters:

• Technology: a list of technologies which the selected objects must match
• Analysis Unit: a list of Analysis Units which the selected objects must belong to. Note that if the analysis units are removed (e.g. an analysis unit created by DMT based on the project configuration, which disappears in a new version), the filter configuration will be updated automatically.
• Object Type: the list of mandated object types for the selected objects.
• Object Name: Possibility to filter on the object short name, full name or path (as stored in the Analysis Service schema). The filtering can be done using three modes: exact match, like (SQL operator) or using a regular expression. Several filtering patterns can be defined. Objects matching any of the naming patterns will be selected (name patterns are applied with a logical OR).
  • In particular, regexp pattern matching on the object path is this safest way to define modules bases on the code repository structure.

For a given object filter, each filtering criteria can be enabled individually. When several criteria are enabled (for instance, Technology and Name, or Analysis unit and Object type), only objects matching all the criteria will be included in the results of the object filter (criteria are applied with a logical AND).

Final content of a filter-based module

Object filters do not determine the complete module content, only the primary objects. All the objects from the application object model which are contained in one of the primary objects are also included in the module (these are the Secondary Objects). For instance, if a .NET namespace matches a filter, all the classes and functions defined in that namespace are included in the module. If a Java class matches a filter, all the variables and methods it contains are also included.

It is possible to preview the result of a module filter (primary and secondary object, so final the content of a module ) using the "Module content overview" option:

For this review to work, the application must have been analyzed at least once, and the preview will be based on the application object model produced by that analysis.

Unassigned objects module option

When defining custom modules, it is possible to configure AIP to automatically create an "Unassigned Object Module", which will contain all the objects which do not match the filtering criteria of the other modules. It is one way to force the application boundaries to match the complete application:

Explicit content modules

In case the possibilities offered by Object filters do not match your need, you can define a Custom module based on Explicit Content. You will need to provide an SQL query on the CAST AIP Analysis Service schema, which returns the objects which have to be included in the module. Note that in the case of an Explict content module, the concept of primary/secondary objects does not apply. Only objects returned by the query are included in the module.

The SQL query that needs to be inserted into this dialog box must use a CAST pre-defined format. The basic format is as follows and is already inserted into the query field:

Delete From CI_OBJECTS_SET Where SET_NAME = '$(ModuleName)'
Insert Into CI_OBJECTS_SET(SET_NAME, OBJECT_ID, ERROR_ID)
Select '$(ModuleName)', o.OBJECT_ID, 0 From §CDT_OBJECTS o
Where /*fill where clause here*/

This query essentially does the following:

1. Empties the CI_OBJECTS_SET table in the CAST Analysis Service of any existing entries pertaining to the current User Defined Module you are working on (this is determined automatically by the $(ModuleName) macro).
2. Inserts new data into the CI_OBJECTS_SET table that determines which specific objects must be included, based on:
   • the CDT_OBJECTS table in the CAST Analysis Service (a table that lists all objects that have been saved into the CAST Analysis Service as a result of analyses that have been successfully completed)
   • a WHERE clause that lets you extract specific items from the CDT_OBJECTS table

Example

To specify ALL objects in the CAST Analysis Service that are "SQL Tables", modify the standard Module Content template by adding the text in red in the WHERE clause:

Delete From CI_OBJECTS_SET Where SET_NAME = '$(ModuleName)'
Insert Into CI_OBJECTS_SET(SET_NAME, OBJECT_ID, ERROR_ID)
Select '$(ModuleName)', o.OBJECT_ID, 0 From §CDT_OBJECTS o
Where o.OBJECT_TYPE_STR = 'SQL Table'

Examples

Please refer to the following page for a few typical examples of the way modules can be defined in an application.