Skip to content
Chen Li edited this page Jun 22, 2017 · 4 revisions

Introduction

The DICE Anti-Patterns and Refactoring (APR) module is designed to achieve the following objectives:

  • Transforming UML diagrams annotated with DICE profiles to performance model for performance analysis.
  • Specifying the selected popular AP of DIAs in a formal way (e.g., executable codes).
  • Detecting the potential AP from the performance model.
  • Generating refactoring suggestions.

Architecture

A high-level overview of the APR module is given in the figure below:

Architecture of APR

The main processes of the APR module are as follows:

  • Modelling: this step is focused towards transforming the UML model to LQN model by using Tulsa. Tulsa will generate an XML format LQN model which follows the XML schema of LQN.
  • Analyzing: the LQN solver (e.g., LINE, lqns) will be used to solve the XML format LQN model and generate the analysis results, a XML format file as well.
  • Extracting: extracting the pre-defined the system constraints (e.g., the total number of server, budget) and performance thresholds indices (e.g., maximum Utilization) and setting the anti-patterns boundaries.
  • AP Defining: anti-pattern is defined as rules (i.e. trigger conditions) for AP detection.
  • Detecting: LQN model, solved model, anti-patterns boundaries and anti-patterns rules will be used for detection algorithms to check if there is AP in the current model. The refactoring suggestions will be provided if AP is detected.

Contact

If you notice a bug, want to request a feature or have a question or feedback, please send an email to the tool maintainer:
Giuliano Casale, Imperial College London: [email protected]

Licence

The code is published under the FreeBSD License.

Clone this wiki locally