In this section:
Overview
The Violations Explorer is an interface for systematically reviewing static violations and facilitating remediation. All static analysis violations widgets drill-down to the Violations Explorer.
Running static analysis on multiple branches using the same run configuration
When running static analysis on multiple branches using the same run configuration, the same instance of a violation will be reported across builds as a new violation. As a result, widgets that present changes in the number of violations will not be accurate. You can change this behavior by Configuring Static Analysis Settings.
The Violations Explorer is made up of four main parts:
- Search panel; See Searching for Violations.
- Search results panel; See Viewing Search Results.
- Sources panel; see Viewing Sources.
- Actions panel; see Addressing Violations, Viewing Flow Analysis Traces, and Viewing Duplicate Code Violations.
Searching for Violations
Violations stored in DTP are searchable by several parameters. Use the search area to hone in on specific types of violations. You can change the criteria in the search area to find violations throughout your development projects.
Click the Change Search button to open the search dialog and configure your search criteria. The following search criteria are available:
Filter Build | A filter and build ID are the minimum criteria for searching violations. By default, the latest build selected when you change the filter, but you can choose a different build from the drop-down menu. The build selected functions as a target build when a baseline build is selected. See the following sections for additional information: |
|---|---|
Baseline Build State | A baseline build is any historical build used for comparison with another build. Choose a baseline build from the drop-down menu to search for violations reported from the baseline build to the build selected with the filter. You can search for new, fixed, or existing violations by choosing a state from the State drop-down menu. |
| Severity | You can search by one or more severity levels. Severity is determined by the test configuration. You can customize the severity level associated with a rule by creating a rule map. See Configuring Code Analysis Rules for additional information. |
| Priority | You can search by one or more assigned priorities. Priorities can be customized through the REST API. |
| Author | You can search by one or more code authors. Authorship is determined from the settings in the code analysis tool. |
| Assignee | You can search by one or more assignees. |
| Action | You can search by one or more assigned actions. Actions can be customized through the REST API. |
| Type | You can search for regular violations, suppressed violations, or all violations. |
| Resource Groups | A resource group is a collection of resources (i.e., files and/or folders) defined by a set of one or more Ant file patterns. You can search by one or more resource groups. Resource groups can be defined in through the REST API. |
Include File Pattern Exclude File Pattern | You can specify Ant patterns to narrow or broaden the scope of your search. See Searching for Violations by File for details on configuring file patterns. |
| Risk/Impact | You can search by one or more risk/impact values. Risk/impact is the extent to which a violation impacts the business. Risk/impact can be customized through the REST API. |
| Reference Number | You can constrict your search to a specific reference number. Reference numbers can be added manually or automated through the REST API. |
| Category | You can search by one or more static analysis categories. Static analysis rules are organized into categories, but you can define or remap rules and categories by creating a rule map. See Configuring Code Analysis Rules for additional information. |
| Module | You can search by one or more specific modules. |
| Rule | You can search by one or more code analysis rules enabled in the test configuration. |
| Limit | You can set a limit for the number of violations shown in the Violations Explorer. |
Searching for Violations by File
You can search for a file and return the violations found in the file. The following table provides examples on how to set file paths.
| Value | Result |
|---|---|
| test | Returns all violations with file paths containing the string "Test", for example:
But not:
|
| com/ex | Returns all violations with file paths containing the string "com/ex", for example:
But not:
|
| com/parasoft/** | Returns all violations in the "com/parasoft" directory tree, for example:
But not:
|
| **/test/*.java | Returns all violations in files with the ".java" suffix under test directories from anywhere in the directory tree, for example:
But not:
|
Click on a violation in the search results table to view the violation as it exists in the code.
You can configure DTP to display sources from source control or from sources sent by connected Parasoft tools during code analysis and test execution. See Configuring Source Code Views for additional information on how sources are displayed in DTP.0
Viewing Search Results
The search results panel returns any violations found according the search parameters.
Click on a violation to view the content of the source file, details about the violation, and enable actions for remediation. When you make a selection in the violations table, the file name and the component that opened the file appears in the code panel.
You can also use the sorting mechanisms and customize the table to refine your view of the violation data. See Navigating Explorer Views for details.
By default, the maximum number of violations shown is 1000. You can change the limit by adding the &limit=[number] parameter to the URL. For example, the following URL would allow you to see up to 2000 violations:
[DTP_HOME]/grs/dtp/explorers/violations?filterId=11&limit=2000
You can set the limit parameter to any value, but changing the maximum number of violations shown to a large value may affect the performance of the Violation Explorer.
Viewing Sources
The sources panel allows you to view violation instances as they appear in the code. You must have permissions to view source code in Report Center explorer views (see Configuring User Permissions and Groups for additional information).
Mouse over the marker in the line number margin to view a tooltip of with the violation error message.
Mouse over the information icon to see where sources are being displayed from.
You can also see paths through the code leading to the violation in the code panel when you use the flow analysis trace feature.
See Viewing Flow Analysis Traces for additional information about viewing code in the Violations Explorer.
Addressing Violations
There are several tools in the Violations Explorer to help you address violations in a way that’s consistent with your organization’s policies, needs, and goals. You can put violations into a software quality workflow through the Prioritization panel.
Users must have permissions to prioritize violations, as well as view sources. Permission to prioritize violations can be granted for all violations or limited to violations owned by the user. The following table describes a project membership scenario and how permissions may be assigned (see Permissions for additional information):User Type Additional Permission Access Granted Admin Leader Member Non-member 1 No access Non-member 2 project Non-member 3 project, prioritizeOwner Non-member 4 project, viewSources
Creating an Issue in a Third-party System
You can connect a project in DTP to a project in one of the following requirements/issue tracking systems:
- codeBeamer ALM - see Integrating with CodeBeamer ALM
- Jira - see Integrating with Jira
- Polarion ALM - see Integrating with Polarion ALM
- TeamForge - see Integrating with TeamForge
- VersionOne - see Integrating with VersionOne
The integration enables you to create issues in the integrated ALM system from violations in the Prioritization panel.
- Select a violation in the search results area and click the Prioritization tab.
- Click the Create button and specify information about the work time you are creating:
Project The name of the ALM project in which the new issue will be created appears in the Project field. The association between a DTP project and the external ALM project is defined by your DTP administrator. See the following sections for details:
Type Choose the type of item to create from the drop-down menu. Terminology varies across ALMs, but DTP supports the following types of work items by default:
- For Jira and codeBeamer ALM, choose Bug or Task.
- For VersionOne, choose Defect or Issue.
- For Polarion ALM, choose Issue or Task.
- For TeamForge, choose Defect or Task.
Title/Summary By default, the violation header is used as the value for the issue title (VersionOne) or summary (Jira, Polarion ALM, codeBeamer ALM, TeamForge), but you can make any necessary changes.
Description Details about the violation, including File, Line, Message, Severity, etc., are added to the issue description by default, but you can make any additional changes. The description will also include a link back to DTP based on the Display URL field setting in the External Application configuration page. - Click Create.
An issue will be created in your external system that links back to the violation in DTP. Additionally, a link to the issue will appear in the Prioritization tab, create a bi-directional path between DTP and your external system.
Assigning Violations to Developers for Remediation
You can assign violations to other authors of violations or to a member of the Project associated with the Filter.
- Select violation(s) in the search results area; the file name appears in the code view panel.
- Click the Prioritization tab and click the Assigned To field.
- Enter an assignee user name. The form will auto-fill based on the users in the system.
- Make any other changes and click Apply. The Apply to All Branches option is enabled by default. Disable this option if you want to apply changes to only the selected instance of the violation; see Applying Changes to Violations.
About Assignees and Authors
When DTP receives a violation for the first time, the value of the Assignee field is copied from the Author field. The value of the Author field is determined from either the authorship settings configured in the tool's .properties configuration file or from the source control management (SCM) system. If authorship is not configured, then the Author is set to the user logged into the machine that executed the analysis. Refer to your tool documentation for additional information.
Authorship may be changed when another developer modifies the code containing the violation and the analysis is sent to DTP. The value of the Assignee field, however, remains consistent unless the violation is reassigned manually in the Violations Explorer view.
The Assignee can also be reset to null using the DTP REST API. Resetting the Assignee enables DTP to automatically set a new assignee it receives a new report containing the violation.
Resetting Violation Assignee with the REST API
Send a POST request to the /resetViolationMetadata endpoint to reset all prioritization metadata fields for a build to their default values. Authentication is required to use the API endpoint. The user must also have administrator privileges. The following cURL example shows how to call the endpoint:
curl -X POST -u <USERNAME>:<PASSWORD> "<PROTOCOL>://<HOST>:<PORT>/grs/api/v1.5/admin/staticAnalysis/resetViolationMetadata?buildId=<BUILD_ID>"
The Assignee field for violations in the build will be set to null in the database. You will not be able to make changes in the Prioritization tab until a user has been assigned to a violation. Users will automatically be assigned the next time Data Collector loads a report for the violations.
Adding Comments to Violations
- Select violation(s) in the search results area
- Click the Prioritization tab and enter a value in the Comments field.
- Make any other changes and click Apply. The Apply to All Branches option is enabled by default. Disable this option if you want to apply changes to only the selected instance of the violation; see Applying Changes to Violations.
Suppressing Violations
Parasoft supports several workflows for suppressing violations. DTP or "server-side" suppressions are applied from the in Prioritization tab of the Violations Explorer view. DTP suppressions are stored in DTP and do not affect the source code when violations are imported to a Parasoft tool user's IDE as findings.
- Select violation(s) in the search results area and click the Prioritization tab.
- Enable the Suppress the selected violations in subsequent analysis runs option and provide information about the suppression in the Reason text field. The suppression will be implemented in the next static analysis execution. You can release suppressed violations by disabling this option. Changes will be implemented during the next analysis run.
- Make any other changes and click Apply. The Apply to All Branches option is enabled by default. Disable this option if you want to apply changes to only the selected instance of the violation; see Applying Changes to Violations.
DTP suppressions differ from in-file and in-code suppressions, which are applied by the tool user and stored locally. Refer to the tool documentation for details about applying in-file and in-code violations.
Violations that have been suppressed using the in-code or in-file method will labeled in the Prioritization and Details tab. You can also add the Suppression Type column to the search results table. See Navigating Explorer Views for information on how to add and remove columns in explorer views.
Prioritizing Violations
- Select violation(s) in the search results area; the file name appears in the code view panel.
- Click the Prioritization tab and choose a priority from the drop-down menu.
- Make any other changes and click Apply; the Apply to All Branches option is enabled by default. Disable this option if you want to apply changes to only the selected instance of the violation; see Applying Changes to Violations.
Assigning Actions to Violations
An action is a string of metadata for defining how you choose to remediate a reported violation. DTP ships with set of pre-defined actions: None, Fix, Reassign, Review, Suppress, and Other. You can edit or remove the pre-defined action types (except for the None type) using the /staticAnalysisViolations/metadata API endpoint. For details on configuring actions, choose API Documentation from the Help drop-down menu in the Report Center navigation bar.
- Select violation(s) in the search results area
- Click the Prioritization tab and choose a value from the Action drop-down menu.
- Make any other changes and click Apply. The Apply to All Branches option is enabled by default. Disable this option if you want to apply changes to only the selected instance of the violation; see Applying Changes to Violations.
The Actions field is also a significant part of the machine learning functionality. See Using the Machine Learning Feature for details.
Assigning Violation Risk and Impact Levels
The Violations Explorer allows you to flag violations that pose a risk or have an impact on the policy goals associated with your application.
- Select violation(s) in the search results area.
- Click the Prioritization tab and choose a value from the Risk/Impact drop-down menu.
- Make any other changes and click Apply. The Apply to All Branches option is enabled by default. Disable this option if you want to apply changes to only the selected instance of the violation; see Applying Changes to Violations.
Assigning Due Dates to Violations
- Select violation(s) in the search results area
- Click the Prioritization tab and click the calendar icon in the Due Date field to choose a date.
- Make any other changes and click Apply. The Apply to All Branches option is enabled by default. Disable this option if you want to apply changes to only the selected instance of the violation; see Applying Changes to Violations.
Assigning Reference Numbers to Violations
- Select violation(s) in the search results area
- Click the Prioritization tab and enter a value in the Reference # field.
- Make any other changes and click Apply. The Apply to All Branches option is enabled by default. Disable this option if you want to apply changes to only the selected instance of the violation; see Applying Changes to Violations.
Applying Changes to Violations
When you update a violation, you can apply the change to single instance of the violation or apply the changes to the violation in all source control branches in which it occurs. A confirmation message appears when your changes are applied:
Reviewing Violation Information
All changes applied to violations can be viewed in the actions panel, which provides a detailed view of historical information associated with selected violations. Rule documentation for a selected violation is also available.
Modification History
Click the Modification History tab in the actions panel to view a summary of prioritization changes, such as re-assignments and impact level changes, for the violation. You can not view the modification history of two or more violations.
Enable the Only show comments option to hide all updates except for the comments log.
Violation History
Click the Violation History tab in the actions panel to view the static analysis runs and the dates in which the selected violation was detected. You can not view the violation history of two or more violations.
The tab also shows the source control history associated with the violation. The same violation may exist in multiple branches under different violation IDs. Choose a branch from the Violations in Branch drop-down menu to view the history of the selected violation in other branches.
The table in the Violation History will be refreshed if you switch to a different branch, but other areas of the Violations Explorer will continue to show information for the selected instance of the violation.
The violation history table will be empty if the build information was removed from DTP, i.e., during regular database pruning or manual deletion.
Traces
Click the Traces tab to view flow analysis results or CDD (code duplicate detection) analysis rules if either type of analysis was performed.
Viewing Flow Analysis Traces
If data flow analysis (dynamic analysis) has been performed, the path leading up to a violation appears under the Traces tab. Flow analysis can help you make decisions about how the code is structured, understand why the violation may have occured, and determine the significance of the violation.
Click on a trace to view the violation path in the code panel.
Users must have permissions to view source code. See Permissions for additional information.
If DTP received the flow analysis report from C/C++test, dotTEST, or Jtest version 10.4.1 or later, the flow analysis trace will include annotations, which provide additional information about the code in the trace. Annotations appear in green text and are marked with flow analysis trace icons and color-coded statements that provide specific information about the flow as it relates to the error:
Clicking on a point in trace shows the corresponding source code in the sources panel. The sources panel is also shows the annotations and color-coded highlights to provide a clear indication of how the code flow resulted in an error. For additional information, see the rule documentation for specific flow analysis violations.
Viewing Duplicate Code Violations
If violations were detected by CDD (code duplicate detection) analysis rules, then you can view them in the Traces tab. Duplicate code may indicate poor application design, as well as increase maintenance costs. Click on a CDD violation in the Violations Explorer search results panel to open the violation path.
This panel shows the file name, line number, and path to each instance of the duplicated code. DTP also shows the sources containing the duplicate code in the sources panel.
You must have permissions to view source code. See Permissions for additional information.
Click on entries in the Code Duplications Detected panel to view instances of the duplicated code.
You can perform normal violation remediation actions, such as setting a priority and assigning the violation to a developer. See Addressing Violations.
Documentation
Click the Documentation tab to view the static analysis rule that the code violates. You can not view the rule documentation for two or more violations.
Details
Click the Details tab in the actions panel to view current information about the location, owner, rule ID, and message associated with the selected violation.
The Violation ID field appears if a violation is selected in the search results table. The ID links directly to the violation and the selected filter. You can share this link so that others can directly access view the violation in DTP.
If the violation has been suppressed, the suppression information will also appear in the Details tab (also see Suppressing Violations).
Using the Machine Learning Feature
Determining the significance of static analysis violations and whether resources should be allocated to fixing them can slow down the software development lifecycle. The machine learning feature is an interface for teaching DTP how to recognize code analysis violations that should be fixed. This accelerates the violation remediation process by enabling DTP to predict which violations should be fixed as new code analysis data is reported.
This feature analyzes violations that have been classified as Fix and Suppress in the Actions field of the Prioritization tab (see Assigning Actions to Violations) and builds a predictive model based on patterns it detects. After the model has been built, DTP will predict which violations in the build should be assigned the Fix action. A balanced set of at least 20 violations must be classified as Fix and Suppress to build the predictive model. The model gradually improves as you continue to review violations and assign them actions.
Predictions are stateful
You will need to execute the prediction action for new violations sent to the build. Additionally, you will need to review and train DTP on the violations if you switch the filter.
Enabling Machine Learning
A license is required to use the machine learning functionality. Contact your Parasoft representative for additional information.
The machine learning interface is available for administrator users or team leaders. Refer to Team Membership for information about team and leader permissions.
Advanced Metadata
The machine learning feature analyzes code analysis reports using a set of criteria to determine which actions should be taken, but you can enable the code analysis tools to include additional metadata to enable advanced analysis. The additional metadata broadens the set features used to predict actions, resulting in more accurate predictions.
Advanced metadata is enabled in the test configuration. If you manage test configurations in DTP, you can enable the option in the test configurations editor (also see Configuring Test Configurations):
- Choose Test Configurations from the DTP settings (gear icon) menu.
- Choose a test configuration from the sidebar menu and click on the Static Analysis Settings tab
- Enable the Send advanced metadata to DTP for machine learning option and click Save.
You can also use the test configuration editor shipped with the tool to enable the advanced metadata option for local code analysis. Refer to your tool's documentation for details.
Using the Machine Learning Wizard
The wizard guides you through the following process:
- Classify violations. Classifying violations refers to setting a value for the Action field in the Prioritization tab (see Assigning Actions to Violations). The machine learning functionality requires at least 20 violations to be classified as Fix or Suppress to build a predictive model.
- Train the model. DTP will analyze the classified violations and build a predictive model based on several data points. This may take several minutes if a large number of violations (e.g., 1000) have been classified. The resulting model is assigned a health score. If the model has an unacceptable health score, the wizard will prompt you to review and classify additional violations.
- Predict actions. When the model has an acceptable health score (between Good and Excellent), you can apply the model to the unclassified violations in the filter. This significantly reduces the time required to review violations and enables the team to quickly begin working on remediating critical violations.
Classifying Violations
- Click the machine learning icon to launch the wizard.
- If this is your first time launching the wizard or if the existing model is not sufficient to predict actions, you will be prompted to classify violations. Click Next.
- DTP will analyze the existing builds in the filter and prompt you to build the model based on violations that have already been classified or to classify violations manually.
- Choose one of the following options and click Confirm:
- Enable the Classify violations based on history option and choose either All, 6 months, or 12 months from the Build history drop-down menu. DTP will search for violations that have already been fixed or suppressed and set the Action field to Fix or Suppress. See Expected Classification Outcomes for additional information.
- Enable the Classify violations manually option and DTP will present 20 violations from the current build for you to review and classify. See Assigning Actions to Violations for instructions on how to manually classify violations.
- When an adequate number of violations have been classified, you will be prompted to return to the main page of the wizard so that you can train the model (see Training the Model).
Expected Classification Outcomes
If the Classify violations based on history option is enabled, DTP will classify violations in the database that have been fixed or suppressed, resulting in one of the following outcomes:
- If an adequate number of violations have been classified, you will be prompted to return to the main page of the wizard so that you can train the model (see Training the Model).
- If no violations from your history have been fixed or suppressed, then DTP will not be able to automatically assign actions. You will be prompted to return to the main page of the wizard and restart the classification process. Choose Classify violations manually when prompted. DTP will present 20 violations from the current build for you to review and classify. See Assigning Actions to Violations for instructions on how to manually classify violations.
- DTP requires a balanced ratio of Fix and Suppress violations. If too many violations have been identified and classified as either Fix or Suppress, you will be prompted to manually classify additional violations until a more balanced ratio is achieved. See Assigning Actions to Violations for instructions on how to manually classify violations.
Training the Model
- If the wizard is not already open, click the machine learning icon to launch the wizard.
- Choose Train the model and click Next.
- Click Confirm when prompted to begin training the prediction model on how to classify violations. This may take several minutes if a large number of violations (e.g., 1000) have been classified.
- When the model is trained, you will be prompted to predict actions (see Predicting Actions).
A healthy prediction model is essential for DTP to make reliable predictions. If the classification process results in a Poor or Moderate model, then you should continue classifying violations until the model health improves. See About Prediction Health for additional information.
Predicting Actions
- If the wizard is not already open, click the machine learning icon to launch the wizard.
- Choose Predict actions and click Next.
- Click Confirm when prompted. DTP will use the machine learning model to make predictions about how to classify static analysis violations for the current build in the filter. The Predicted Action field in the Prioritization tab will be updated. See Predicted Actions for additional information. A prediction results summary screen will also appear.
- Review the actions predicted for the violations. You can either assign the predictions to the violations (see Assigning Actions to Violations) or ignore the predictions. See Predicted Actions for details about predicted actions.
Predicted Actions
After you have classified violations and trained and applied the predictive model, the Predicted Action field appears in the Prioritization tab. If DTP predicts that the violation should be fixed, a value of "Fix" will appear in the field, as well as a value indicating how confident DTP is that the predicted action is correct based on the model.
If the Fix action has not been predicted for the violation, the Predicted Actions field shows Not available.
You can add the Predicted Action column to the search results table so that you can sort violations according to DTPs recommendations.
By default, the column is not included in the table. Click on a vertical ellipses menu and choose Predicted Action from the Columns submenu.
You can drag the column to the position in the table that best suits your needs. Refer to the Navigating Explorer Views chapter for additional information about customizing the Violations Explorer view.
About Prediction Health
The health of the predictions DTP makes depends on the amount of violations you process and quality of the data you provide. DTP requires at least 20 violations to be assigned an action, but processing more violations will improve prediction health. If you have not provided enough data, DTP will not be able to make a prediction. The model informing DTP predictions also depends on the accuracy and consistency of the data you provide. DTP uses advanced algorithms to analyze the data associated with each violation, but it can only make quality predictions based on quality inputs. Assigning too many of one type of action also affects the prediction results. You should assign an equal number Fix and Suppress actions to facilitate prediction health.
Providing Machine Learning Feedback to Parasoft
You can help Parasoft improve the system by using the API to get Machine Learning data and sending the data to your Parasoft representative. Sensitive information, such as username and project name, is obfuscated in the response. Save the output from the following API endpoints are available to retrieve the Machine Learning data:
/classificationResultSets
This endpoint returns static analysis violations used to train the model and prediction results.
Authentication
Pass your user name and password as when sending the request. See Example.
URL
http:<host>:<port>/grs/api/v1.7/ml/staticAnalysis/classificationResultsSets
Method
GET
Parameters
The following table describes the parameters available for this endpoint.
| Parameter | Description | Type | Required |
|---|---|---|---|
sortOrder | Specifies the order in which the data is returned by ID. Data is assigned IDs in sequential order, so newer data has a larger ID number. You can specify the following values:
| string | optional |
limit | Specifies the maximum number of result sets to return. The default is no limit. | integer | optional |
| Specifies the number of result sets to skip in the response. Default is If the database has three result sets and the | integer | optional |
Example
curl -X GET -u username:password "http://dtp.mycompany.com:8443/grs/api/v1.7/ml/staticAnalysis/classificationResultSets?sortOrder=desc&limit=10" > myResultSets.json
/violationActionHistory
This endpoint returns actions assigned to the violations used to train the model.
URL
http:<host>:<port>/grs/api/v1.7/ml/staticAnalysis/violationActionHistory
Method
GET
Parameters
None.
Example
curl -X GET -u username:password "http://dtp.mycompany.com:8443/grs/api/v1.7/ml/staticAnalysis/violationActionHistory" > myViolationActionHistory.json
