PerOpteryx Feature Exploration

Aus SDQ-Wiki

Peropteryx supports the evaluation of subsystems as degrees of freedom. Subsystems are modeled more coarse-grain than one single software component. Internally, they often contain many software components. Subsystem services are modelled with the help of a feature model. Finally, these features can be annotated to connectors at certain points on the system view-type of the target PCM model. PerOpteryx automatically includes the subsystems at the annotated locations.

Plugin usage

The extension is fully integrated in the PerOpteryx plugin. Further information on the installation of PerOpteryx can be found here. Pleas install the EMF Palladio Sirius Editor package as additional plugin.

Subsystem Model

The subsystem model consists mainly of the reference architecture for the subsystem and the feature model that defines the services of the subsystem. The reference architecture allows PerOpteryx to automatically exchange implementations of subsystems. This enables the automatic exploration of different solutions of a subsystem.

Reference Architecture

Three levels are relevant for modelling the subsystem model and the reference architecture:

  • Definition Type: On the definition type subsystem provided features and required services are modelled.
  • Refinement Type: The refinement type defines the actual reference architecture. Here, the feature completion components can be defined and their relationship to each other can be defined.
  • Solution Type: On the solution type the solution models realizing the subsystem can be annotated to the reference architecture.

The reference architecture is comprised of feature completion components that build logical blocks to be found in every solution of a subsystem. Further, the relations between the components (to be compared with software components) have to be defined. Please review our example subsystem model defining the subsystem Logging.

RefArchLogging.png

Feature Model

The feature model is used to describe the provided services of a subsystem. Features can be set in relation to each other such as XOR, AND relationships. Features are later used to define the perimeter providing interfaces of subsystems. Please review our example feature model of the Logging subsystem.

FeatureLogging.png

Applying the reference architecture

Applying the reference architecture to a subsystem solution model is comprised of x steps:

  1. Apply FeatureCompletionProfile to solution repository model
  2. Apply Stereotypes
    1. Transformation to Repository root element to define the weaving strategy (see paper)
    2. fulfillsComplementumVisnetis to interfaces or signatures of the solution model
      1. fulfillsComplementumVisnetis::fulfills to define the feature fulfilled by the interface or signature
    3. issolution for to relate feature completion components to corresponding software components

ApplyReferenceArchitecture.png

Developer quick start

Please review the general developer start guide from PerOpteryx. The feature exploration extension can be found on Gitlab. As starting point use the package edu.kit.ipd.are.dsexplore.featurecompletions.*

Publications

  • ICSAW'19: PerOpteryx: Automated Improvement of Software Architectures (PDF)
    • Overview on PerOpteryx and extensions
    • Also introduces general concepts of PerOpteryx
  • ECSA'19: Assessing the Quality Impact of Features in Component-based Software Architectures
    • Introduction on general concepts of feature weaving in target software architectures
  • MEMOCODE'17: Automatic Evaluation of Complex Design Decisions in Component-based Software Architectures (PDF)
    • Introduction on automatic weaving of software architectures
    • Basic concepts on how to integrate features in target software architectures
    • Formalized concepts of weaving based on triple graph grammars
  • CloudSPD'16: Modelling the Structure of Reusable Solutions for Architecture-based Quality Evaluation (PDF)
    • Introduction of the reference architecture
  • QoSA'16: Considering Not-quantified Quality Attributes in an Automated Design Space Exploration (PDF)
    • Introduction of concepts about using not-quantified quality attributes in a systematic process
    • Combination with quantified quality attributes