SUPERSEDE Tool-Suite and Components
SUPERSEDE can be integrated within a company as either a self-contained set of integrated services or as a set of add-ons to an existing tool set. In this page we first describe the self-standing version, than we will show how to introduce it in an environment that uses Atlassian JIRA as supporting tool for its software development processes.
The SUPERSEDE Toolsuite consists of a chain of five components that are active according to the context of use of the Toolsuite. The Toolsuite can either improve the Software Evolution Workflow (e.g. by improving the way how a release plan is created) or the Dynamic Adaptation workflow (e.g. by increasing the Quality of Experience of an online video player by monitoring its usage and and reacting instantly in case problems occur).
The components, which are available in GitHub (links to GitHub in the text), are described below:
|Project Result||Description||IP Owners and Percentage of Ownership||Links||License|
|Adaptability DSL||This DSL provides modeling capabilities to relate system configurations (i.e. feature configurations) to the adaptability space (i.e. variant model of the system), connected through AOM concepts such as pointcuts, jointpoints, advices and aspects||ATOS||Link||Apache v2|
|Hypervisor Enactor||This enactor interprets UML deployment models to inject changes in system configuration into the VMWare VShere ESX5.5i Hypervisor||ATOS||Link||Apache v2|
|SUPERSEDE Integration Framework||This framework mediates the secure communication between the SUPERSEDE services (i.e. components) themselves and the Big Data plaform and the front-end||ATOS||Link||Apache v2|
|Adapter||The Adapter is responsible for updating the models@runtime of a system considering the reconfiguration decisions suggested by decision-making. It is also in charge of invoking the Enactor with the new adapted model.||ATOS: 50%|
|Model Repository||The Model Repository is a centralized model storage used to store, index, search and retrieve the different models required to support the adaptation process.||ATOS: 70%|
|SUPERSEDE JIRA Plug-In||DELTA||Link||Apache v2|
|DMGame preference optimizer based on AHP algorithm||The component implements a collaborative requorements prioritisation technique based on the Analytic Hierarchy Process algorithm||DELTA: 50% FBK: 50%||Link||Apache v2|
|Decision-making planner||The component implements planning algorithms to optimise the sequence of decision-making activities to be performed towards a decision-making objective aggregating the different decsion-making activities supported by the different decsion-making components included in DMGame||DELTA: 50% FBK: 50%||Link||Apache v2|
|DMGame preference optimizer based on Genetic Algorithm||The component implements a collaborative requorements prioritisation technique based on Genetic Algorithms||DELTA: 50% FBK: 50%||Link||Apache v2|
|The SUPERSEDE Method Knowledge Base||Equally shared between UPC, FBK, FHNW, ATOS, DELTA and Jolita Ralyté||Link||Apache v2|
|FeedbackAnalysis||This component implements several techniques for analyzing user feedback, including speech-acts based feedback classification as well as clustering of similar user feedback.||FBK||Link||Apache v2|
|GermanFeedbackAnalysis||This component implements user feedback classification and sentiment analysis for user feedback expressed in the German language.||FBK||Link||Apache v2|
|DMGame similarity checker engine||This component has the objective to check the similarity between a set of sentences rpresenting either featrures or feedbacks; it is based on natural language processinf techniques||FBK||Link||Apache v2|
|Model transformation UML to Json||This model transformation takes a class diagram UML model as input to serializes it as JSON.||FBK||Link||Apache v2|
|Feedback gathering reconfiguration enactor||The feedback gathering enactor receives the decision to reconfigure the feedback-gathering tool, then serializes this decision as JSON and calls to the orchestrator using the JSON data. The orchestrator executes the reconfiguration on the feedback_gathering tool.||FBK||Link||Apache v2|
|Dynamic Adaptation optimiser||The component implements an optimisation algorithm based on Genetic Programming to support the search for a (set of) optimal configuration(s) to be used by the dynamic adaptation enactor for evolving the system configuration; the algorithm works on Feature models representation of a family of configurations||FBK: 70%, ATOS: 30%||Link||Apache v2|
|Feedback Repository||The Feedback Repository is a back-end component and responsible for temporarily storing and forwarding feedback to other components.||FHNW||Link||Apache v2|
|Feedback and Monitoring Orchestrator||The Orchestrator is responsible for managing feedback gathering and monitoring configurations. The orchestrator supports both initial configurations (set-up) and dynamic reconfigurations (at runtime). In this regard, it provides a RESTful interface that can be invoked with the (re)configurations to apply.||FHNW: 90%|
|Replan Dashboard||The main purpose of this component is to offer an easy to use user interface in order to facilitate the access to the main functionality of the tool. This component also allows to the end user to provide the additional information required by the tool (e.g., the resources available for each release).||Siemens||Link||Apache v2|
|Service composition enactor||This component enacts the service composition adaptations computed by Adapter to Hook. It transforms the UML activity diagram that represents the adaptation to the .xml Ptolmey model to be executedby Hook in the real system.||Siemens||Link||Apache v2|
|Service composition hook||This component executes the enacted service adaptations in the system as a response to the user requests. The Hook component is a REST-based service made using Java-Spark and it can store different enacted adaptationds and execute them on request.||Siemens||Link||Apache v2|
|Method Explorer and Configurator||Siemens||Link||Apache v2|
|Monitor Manager||This component manages the different configurations of the monitors. It receives the configurations from the Feedback Gathering and Monitoring Orchestrator and forwards them to the appropriate monitors to be invoked.||UPC||Link||Apache v2|
|Disk Monitor||Disk Monitor measures disk-consumption. It can measure the consumption of the whole disk or particular folders. Furthermore, it can also measure local disks or remote disks using SSH connection.||UPC||Link||Apache v2|
|Http Monitor||HTTP Monitor measures the response time and availability of HTTP-based applications (e.g. web pages, RESTful services).||UPC||Link||Apache v2|
|UserEvent Monitor||UserEvent Monitor collects at runtime the user events in a web application. It monitors the clickstream and navigation path of end-users accompanied with relevant metadata.||UPC||Link||Apache v2|
|AppStore Monitor||AppStore Monitor collects at runtime the reviews and ratings of Apps in the AppStore MarketPlace.||UPC||Link||Apache v2|
|GooglePlay Monitor||GooglePlay Monitor collects at runtime the reviews and ratings of Apps in the GooglePlay MarketPlace.||UPC||Link||Apache v2|
|Twitter Monitor||TwitterMonitor collects at runtime the tweets satisfying a specificic search criteria.||UPC||Link||Apache v2|
|Logs Monitor||Logs Monitor collects at runtime the logs generated in a Java Application.||UPC||Link||Apache v2|
|Meta Data Management System (MDM)||MDM allows to model and integrate an heterogeneous set of data sources (such as feedback or monitoring sources) into an ontology. It also allows to specify ECA and CEP rules over the ontology to raise alerts based on the input stream of data. MDM also allows to pose ontology-mediated queries over the ontology (representing the global schema of a federated system) which are automatically translated to the class of conjunctive aggregate queries (aggregations over conjunctive queries)||UPC||Link||Apache v2|
|RePlan Optimizer||The optimizer has the purpose of generating a release plan. It has been developed as a stateless web service that given all the required information generates a release plan that preserving the stated constraints optimizes the use of the company resources to develop the next release.||UPC||Link||Apache v2|
|RePlan Controller||The Replan controller component provides several REST interfaces for the other components to interact with the Replan tool.||UPC||Link||Apache v2|
|Model Repository Manager||The Model Repository Manager provides a RESTful interface to manage and interact with the Model Repository.||UPC||Link||Apache v2|
|Monitoring Executor||Monitoring Executor is responsible to execute monitoring reconfigurations (specified in JSON) by invoking the Feedback Gathering and Monitoring Orchestrator.||UPC||Link||Apache v2|
|Monitoring Enactor||The Monitoring Enactor transforms the adapted Model of a monitoring configuration to JSON and run the Monitoring Executor for its enactment.||UPC||Link||Apache v2|
|Adaptation Dashboard||The Adaptation Dashboard is a web front-end to visualize and manage the Dynamic Adaptation Platform. It is integrated with the SUPERSEDE web front-end Dashboard and provides the screens for suggested and enacted adaptations.||UPC: 75%|
|Sentiment Analysis||The Sentiment analysis component analyses the sentiment of incoming feedback.||UZH||Link||Apache v2|
|Keyword Search||The Keyword Search component allows to search for keywords in a text string.||UZH||Link||Apache v2|
|Feature Extraction||The Feature Extraction component allows to idenfify and extract features.||UZH||Link||Apache v2|
|Web Feedback Library||As a front-end component, which is directly integrated into a Web application and retrieves its configuration from the Orchestrator, the Web library allows an end-user to document her feedback with various feedback mechanisms without leaving the Web application.||UZH: 70%|
|Android Feedback Library||As a front-end component, which is directly integrated into a mobile Android application and retrieves its configuration from the Orchestrator, the Android library allows an end-user to document her feedback with various feedback mechanisms and without leaving the Android application.||UZH: 90%|
Some components are also displayed and described more in detail in a brochure, that can be downloaded >here<.
Using Supersede with JIRA
As mentioned above, SUPERSEDE can be used as a plugin, an extension to existing tools. In principle, its architecture allows it to be integrated in any environment. To date, a plugin for Atlassian JIRA has been developed that supports the software evolution workflow described below. The plugin allows to handle the alerts raised from the data analysis step and create JIRA issues from them, to invoke the decision making services on JIRA issues, and to call the release planner on those issues.
The plugin can be downloaded here.
If you want to install the plugin, we are happy to personally assist you in the installation steps. Please contact us for more information: info[AT]supersede.eu
Software Evolution Workflow
In the context of the SUPERSEDE project we consider a feedback-driven approach to software evolution of a given software application. That is why we envisage a software evolution process that includes the following tasks: end-user feedback and monitored data collection; data analysis; prioritization of requested “features” (e.g. new functional or non functional requirements, enhancement requests, as well as to requests for bug fixing); release planning.
The Two Software Evolution Workflows consist of 4 general processing steps, step 1” Feedback and data collection”(WP1), step 2 “Feedback and data analysis”(WP2), step 3” Decision making in software evolution and adaptation”(WP3) and step 4” Enacting the decisions”(WP4). The difference of the two workflows results from step 1 (WP1), in the first workflow feedback is gathered directly from software users (e.g. by giving suggestions of software improvements), in the second workflow feedback is gathered indirectly by monitoring user feedback in Social Media (e.g. by analyzing Tweets).
Dynamic Adaptation Workflow
In the context of the SUPERSEDE project we consider a feedback-driven approach to dynamic adaptation, such as software configuration (at deployment and execution time) and dynamic personalization. That is why we envisage a software dynamic adaptation process that includes the following steps: end-user feedback and monitored data collection; data analysis; identification and selection of adaptation actions; enactment of the selected adaptation actions. SUPERSEDE offers a set of tools to support each single step, a chain of steps or the whole process.
The identified Dynamic Adaptation Workflow consists of 4 general processing steps, step 1”Runtime data collection”(WP1), step 2 “data analysis”(WP2), step 3” Decision making in software evolution and adaptation”(WP3) and step 4” Enacting the decisions”(WP4).