Results

Following, the main results attained in ARTIST are described. For each relevant result the same structure will be followed: objective and description of the tool, challenge solved and main innovations. All these results are integrated in one ARTIST Toolsuite and can be downloaded from: http://www.artist-project.eu/open-source-package and https://github.com/artist-project/ARTIST.

R1: Modernization Assessment Toolbox

Objective

Provide a set of tools that aid companies in the decision of whether to face a migration or not, by firstly, characterising its maturity; secondly, analysing its architecture, suggesting convenient migration strategies as well as providing an effort estimation based on its complexity (maintainability); thirdly, simulating the potential application business model and its enterprise context, providing an economic analysis on costs and benefits and the implications of selecting one pricing strategy versus another.

Description

The Modernization Assessment Toolbox is composed of three tools:

1) The Maturity Assessment Tool (MAT) focuses on the characterization of non-cloud applications from three points of view: technical, business and processes. The MAT in ARTIST is based on standards widely adopted in the industry, such as ISO 17789, OASIS TOSCA, ITIL, EFQM, CMMI-SVC, and so on. These standards propose best practices in all three dimensions and rank the possible solutions in terms of the most suitable alternatives for cloud-based solutions. The aim is therefore to analyse how compliant the application is now and in the future (e.g. once the migration has occurred) with respect to the interpretation of these industry-widely adopted standards. MAT is the first step in the overall ARTIST approach. Its main audience is managers for the business side and software architects for the technical side and thus, it must provide reports understandable for both profiles. MAT creates several reports: 1) End user report, which shows the questions and answers to the different questions presented to the user; 2) a Recommendations report, which advices the user on issues that need to be considered when modernizing the application; 3) several reports needed to trigger the ARTIST toolchain. One of these reports is the MPT report, which collects the users’ needs and has as main purpose to serve as input for the customization of the methodology. The second report is the Migration Goals report (MAT GML report), holding a set of high level of non-functional requirements that are refined throughout the ARTIST Toolchain; 4) an integrated Report or iReport that summarizes the results of the three tools that compose the Modernization Assessment Toolbox.

2) The Technical Feasibility Tool (TFT) has as main objective the offering of as much technical information as possible about the non-cloud application itself and about the technical tasks that need to be undertaken to migrate its components, as well as the associated complexity and the relevant non-functional requirements. TFT manages different inputs: i) the MAT GML report (i.e. the migration goals model and the suggested Cloud target environment) and ii) a high level PIM (i.e. component model) of the existing application obtained through the Model Understanding Toolbox. Inputs are selected by the user (i.e. the MAT report, the PIM representing the existing application). The TFT aims to provide this information in a user friendly way, but not only, as its results serve as input also for other ARTIST tools. TFT provides several GUI-based reports: 1) Inventory view, which presents a list of components that are present in the non-cloud application’s component model along with their owned classes and the migration strategies suggestions for each of them. These strategies are instantiated as migration tasks for each component marked for a migration, aiming at fulfilling the overall migration goals and the specific component migration requirements, addressing the Cloud target selection as well; 2) Migration goals view: migration goals are a set of constraints that should be accomplished during the migration phase and that can be related to the infrastructure preferred by the application owner (if the decision is already taken), the business model of the migrated application, or non-functional requirements (e.g. quality and performance characteristics). The main objective of the migration goals is to establish in a formal and shareable manner (representing formally the concepts and their relationships) the main constraints exposed from the application (or its owner) for the migration. The requirements for the migration that cannot be extracted from the non-cloud software itself are established by the migration goals and circulated over the other ARTIST tools (both at pre-migration phase and in through the other phases). A new language has been defined in the context of ARTIST for the modelling of non-functional properties. This language has been named GML (Goal Modelling Language); 3) Migration efforts, which presents information regarding the complexity and effort estimated for the migration of the whole application. Concretely, the data presented to the user are the component complexity, calculated by means of the maintainability metric, the overall migration complexity (how complex it would be to perform all the suggested migration strategies for that specific component) and the overall migration effort for each component considering the selected target platform. The TFT relies on several approaches such as the novel Cloud Migration Points, or the already established, MDRE. Both approaches have been extended, improved and customized for the problem domain of ARTIST and the TFT. In addition to that, several analysis of the quality of the source code and the models have been performed so as to discover its maintainability and potential code reusability considering both the origin and target platform. Finally, the tool has been supplied with intelligence by means of DSL-based heuristics, DROOLS rules and expert judgment.

3) The Business feasibility tool (BFT) offers means to estimate costs, benefits and operational risks of the migration to a cloud deployment scheme, based on an economic, strategic and analytic approach for evaluating and justifying Cloud migration projects. It uses simulation technologies to obtain estimations of the future value of the key variables describing the business models and the impact on the business processes. To achieve this, a Cost-Benefit Analysis is provided, where KPIs such as ROI and Payback are presented. Furthermore, the selection of a certain pricing strategy over another, affects the Profit and Loss account of a certain enterprise. Thus, with this aim, a simulation model of three SaaS pricing strategies (pay as you go, freemium, tiered) has been created. BFT also manages different inputs: i) the MAT report, ii) the TFT report (i.e. effort breakdown) and iii) business scenarios stored in the ARTIST repository. ARTIST BFT aims both at cloud service providers and cloud service consumers. For the first, it supports the decision maker in the objective to decide about costs, benefits and operational risks using a cloud deployment scheme (e.g. supporting self-servicing). For the latter, it supports the decision makers to decide about costs, benefits and operational risks of relying on cloud-based services (e.g. cloud storage services).

Challenge solved

The modernization assessment toolset supports decision makers in the decision of migrating to the cloud against other possibilities. To achieve that, it is necessary to understand both the technological constraints of the application to be migrated as well as the implications that a new business model and a new pricing strategy have in the context of an enterprise. The holistic modernization assessment performed in ARTIST serves as a unique entry point to understand the requirements that a migration imply. The information provided with this toolkit ranges from high level (end user report, iReport) to low level (all TFT reports, BFT reports), covering thus the decision value chain of most companies, in both the technical and business dimension, supplying them with enough information to take the most convenient decision for the sustainability of the company.

Main innovations

The main innovations of the modernization assessment process are:

  • Proposing a holistic pre-migration approach providing a complete approximation to the modernization problem, considering the technical, the business and the process dimensions of the problem and defining the “cloud compliant” term (as the collection of cloud good practices supported by several standards such as ISO 17789, TOSCA, ITIL or EFQM) as the basis for determining the maturity of software product and the company selling it, as well as the starting point of the feasibility analysis (both technical and business).
  • Providing a set of modernization decision support tools to facilitate the decision about Cloud migration, providing added value information about the required migration strategies and the effort needed to perform them (based on the complexity of the migration tasks and the complexity of the source code to be migrated) as well as simulation of the potential business models, pricing models and their KPIs.

R2: ARTIST Methodology and Methodology Process Tool (MPT)

Objective

Provide a modernization and migration methodology that covers a wide range of application types, regardless of the underlying technologies, business models, operational modes, etc. In order to practically support this methodology, a central component has been incorporated in the overall architecture: the ARTIST Methodology Process Tool, which allows the customization and instantiation of the methodology based on the specific application requirements.

Description

The ARTIST Methodology is one of main outcomes of the project as well as a fundamental concept which supports end-to-end the migration and modernization of a non-cloud application. To this direction, the methodology is specified in a formal way, following a predefined structure, so as not only to be uniquely interpreted by the ARIST customers, but to be also effectively consumed by the ARTIST tools. The ARTIST methodology covers the three areas that affect a company when cloudifying an application, namely, the technical aspect, the business aspect and the organizational process aspects. All three aspects are intertwined and a cloudification cannot be understood without having the three in mind. The ARTIST methodology has defined a set of tasks and activities as well as the recommended sequence for them, considering in this sequence, if adequate, the three aspects (business, process, technical), if they are mandatory or optional, manual or automatic, the stakeholder responsible for performing it, and the supporting tools (ARTIST or not) that realize that specific activity.

The objective of the ARTIST Methodology Process Tool (MPT) is to allow the customization and instantiation of the ARTIST Migration Methodology for end-users based on the Migration Assessment results of the particular migration project. The Methodology Process Tool, exploiting the results processed and obtained during the modernization assessment, defines a customized modernization process, tailored to the concrete non-cloud application needs. The tool shows the customized process in detail, its tasks broken down step-by-step, including hooks to invoke the tools required to accomplish each task acting as an umbrella for ARTIST tools and frameworks.

MPT uses reports generated during the early assessment phase, by the TFT and the BFT, since the technical and business feasibility assessment reports contains the required information to particularize the ARTIST methodology to each concrete migration project. These reports are loaded by the MPT from the common workspace. MPT can programmatically launch any required ARTIST tool to accomplish any of the tasks described in the tailored methodology blueprint. The direct integration of the MPT with other ARTIST tools as well as with the repository is a critical challenge that has been solved. The MPT can access and reference the work products (artefacts) produced and consumed by the tasks a methodology instance via the Eclipse workspace and the Eclipse repository client.

The MPT is offered by five pieces of software that work together as a unit as well as standalone. These are: 1) MPT Eclipse plugin, which includes the composite cheat sheets and extensions to the Eclipse Welcome page for helping and guiding the user throughout the ARTIST phases and corresponding tools. Furthermore, the MPT Eclipse plug-in facilitates the immediate connection to other Eclipse-based or web-based ARTIST tools, as required by each task of the methodology; 2) MPT Rule Engine, which offers the necessary libraries and a Java API to fire and collect the results of the customization rules defined in the context of MPT in order to modify the ARTIST methodology at runtime based on pre-migration analysis results; 3) ARTIST Methodology EPF plugin project, which aims to detach the output of the ARTIST Methodology from the EPF plugin project, which is in the form of simple static HTML pages, and enable their customization. By transforming these static pages into dynamic ones (XHTML) and integrating them inside the MPT Web App, the end user is able to view an online personalized version of the ARTIST Methodology in EPF via a web browser, without having to install and run the EPF composer; 4) MPT Web App, which allows the users to upload the pre-migration results and then use them to share a common view of the customized representation of the ARTIST Methodology in EPF either from an external Web browser, which connects to the web server that host the MPT, or within the Eclipse-based ARTIST Tooling, using the internal Eclipse Web Browser; and 5) SpikesTogether MPT application, which is complementary to the MPT Web App since the MPT Web App is oriented towards technical users, while SpikesTogether MPT application is more oriented towards business users. The so-called collaborative workflows in SpikesTogether facilitate communication and collaboration between the business users monitoring and managing the migration and the technical users doing the implementation work.

Challenge solved

The ARTIST methodology is, up to our knowledge, the first methodology that defines a step-wise procedure to modernize a non-cloud application to the cloud intertwining the three relevant aspects that a cloudification implies, namely, the technical / architectural changes, the business model re-definition and the organizational processes update. Literature, commercial methodologies and previous European projects had focused mainly on the technical aspects leaving aside the ones related to the enterprise context, key for cloud-based software providers.

Migration projects are most likely to differ from each other. Each application has its own architectural constraints and business model. Besides, the target platform, architecture, non-functional requirements and business model impose certain conditions that, in order to consider them all, need an automatic mechanism that allows the customization of the ARTIST methodology for that specific migration project. The ARTIST MPT solves that concrete challenge, by customizing and tailoring the methodology based on the results obtained in the modernization process. Furthermore, the ARTIST MPT solves the challenge of how to integrate all ARTIST tools and components, and hence serves as the glue and unique entry point to execute the ARTIST toolchain.

Main innovations

In general, the major innovations of the ARTIST methodology can be concluded as follows:

  1. It shows the relationship and dependencies of technical, business and process aspects of what it means to provide an application as a service.
  2. It presents an end-to-end solution. This can be easily seen by tracing the non-functional goals, which are defined at a very high level, during the pre-migration phase, updated and refined in the modernization phase, and verified in the post-migration phase.
  3. The ARTIST methodology is a tailorable solution, with optional and mandatory tasks. The execution of one task or not will greatly depend on the initial situation of a software provider and its application.
  4. It lists clearly the minimum set of artefacts necessary for a successful execution of the different tasks.
  5. It distinguishes tasks related to technical migration projects and to business migration projects.
  6. Technical tasks are classified following a distinct taxonomy.
  7. It considers the steps that an application provider, which has deployed the application on a commercial cloud provider, has to take in order to check if the cloud provider is complying with the defined SLAs in terms of availability. This occurs in the post-migration phase, when the application is provisioned.
  8. It takes into account the evolution of artefacts and its reusability. The reusable artefacts will be pushed into a repository and pulled during the migration phase, so as to ease the migration and reduce the migration efforts.
  9. It considers which organizational processes should be updated or re-defined and the steps to do so, in order to be able to provide an application as a service.
  10. It tailors existing business model definitions for the case of software as a service relating it to organizational processes and technical aspects.

Main innovations achieved through the MTP:

  1. The definition of rules for tailoring the generic ARTIST Methodology migrating non-cloud applications to Cloud environments, covering all the aspects of the migration process (technical, process as well as business).
  2. The implementation of suitable supporting tools for manifesting the ARTIST methodology and customizing it depending on the nature of the project to be migrated and the goals of the end user, using the results of the pre-migration analysis.
  3. Developing tools that offer step-by-step guidance through a customized ARTIST methodology, and also serve as one of the main integration drivers behind the ARTIST solution, bringing together all ARTIST tools in one coherent workflow.

R3: Model Discovery Toolbox

Objective

Provide a tool support allowing the generation of complete low-level models out of Java & C# existing source artefacts. Model Discovery consists in (semi-)automatically producing an initial base (i.e., low-level) and/or systematic models from the various artefacts composing the software system (e.g., source code, configuration files, data files, etc.).

Description

In the context of ARTIST, Model Discovery is the phase where initial low-level models are extracted from the existing software artefacts. The term low-level models is used when their level of abstraction is quite the same as the software artefact they are representing, that is, there is a direct systematic correspondence between software artefact elements and model elements. No further data or content analysis is realized at this step. For instance, a Java code model will represent every Java element in the code (statements, variables, classes, etc.), or a generic UML Class model will describe each Java package, class, attribute as corresponding UML elements.

ARTIST has defined a taxonomy, that is, a detailed classification of the main different types of legacy artefacts according to their corresponding characteristics and specific properties.. The taxonomy defined in ARTIST is based on several dimensions from which software artefacts can be considered. These dimensions allow evaluating the actual “type” of a legacy artefact and thus provide by default a better understanding of the elements composing the legacy system to be migrated. The purpose of this taxonomy was used as a base to guide the design and implementation of the Model Discovery Toolbox

From an architectural perspective, the ARTIST Model Discovery Toolbox (MDT) is globally composed of two main entities: the Java support (Eclipse-based) and the .NET support (Sparx EA-based). The Model Discovery toolbox is taking as inputs different kinds of legacy artefacts from both the Java EE and .NET worlds, and producing as outputs base models that can conform to UML or to (more specific) low-level metamodels. These models are so-called Platform-Specific Models (or PSM) according to the common MDE jargon and are then used as inputs of the ARTIST Model Understanding Toolbox. For the Java support, the integration of the different components (e.g., model discoverers) is realized notably via the Eclipse MoDisco framework. As dedicated to MDRE1 activities and intensively reused/enhanced in the context of ARTIST Reverse Engineering tasks, it is a perfect candidate. For the .NET world, a similar integration is performed via Sparx Enterprise Architect (components are actually Sparx EA add-ons), as a tool suite developed by one of the partners of the project.

The main functionalities and novelties provided by the MDT are summarized in the following paragraphs.

From Java code: 1) Extraction of a generic UML class diagram, structural part of the code – direct or via KDM, by means of a transformation chain in ATL, which allows producing an UML Class Diagram model from an initial Java source code (but only passing by an intermediate Java source code model). The obtained UML Class Diagram model also only covers the superstructure of the program and not the details of the expressions and statements (method bodies); 2) Extraction of a Generic UML activity diagram directly from the Java Code, to obtain the behavioural part of the application, which allows producing an UML Activity Diagram model from initial Java source code (only passing by an intermediate Java source code model). Complementary to UML Class Diagram models produced by other components, the obtained UML Activity Diagram model covers the behavioural aspects of the initial Java code by detailing the expressions and statements (as expressed inside method bodies); 3) Generation of a generic UML profile from APIs or libraries (JUMP): Profiles provide features complementary to the UML metamodel in terms of lightweight extensions. This powerful capability of profiles can also be exploited in terms of an annotation mechanism. This component focuses on both UML profile generation and profiled UML model generation. JUMP can be considered a specific model discoverer dedicated to extract annotation types from Java libraries in terms of UML profiles

From C# and .NET source code: 1) Extraction of a generic UML sequence diagram, at runtime execution, based on the Visual Execution Analyzer (and is now part of the Sparx Enterprise Architect standard provided features), which processes the structures and operations of the EA Model Driven Development Environment (MDDE); 2) Extraction of a generic UML Class diagram, both from Microsoft data libraries and DBML data files. In the case of Microsoft data libraries, this component is built on top of Enterprise Architect and now part of its standard provided features, and it is possible to reverse engineer the structural part of Microsoft libraries (i.e., DLL files), including notably C# ones as relevant in the context of ARTIST, and to create UML class diagrams for it. In the case of DBML data libraries, has as main target data oriented projects that involve a DBML specification, which actually is an XML document containing a description (schema) of the data in the application; 3) Extraction of a Sharepoint data mode. The migration of a SharePoint-based solution towards a SaaS solution (independent of SharePoint) requires us to extract the so-called features (custom data structures such as Site Columns, Content Types, List Instances and so on) that are persisted in the SharePoint database and move them towards a stand-alone database. The purpose of this component is to provide such a transformation chain for the List Instance data structure; 4) extraction of Solution and Syntax models from Microsoft Visual Studio solutions.

From XML-based artefacts, MDT offers an extension of a generic XML model discoverer through the XML model aggregator. This component offers both a generic metamodel (based on the XML Language Specification) and the Generic XML Model Discoverer. This latter allows obtaining complete XML models out of any set of XML document. The XML model represents all the content of the initial XML document, independently from the corresponding XML Schemas or DTDs.

From SQL source code, extraction of a SQL code model using Xtext, as well as the extraction of a UML Object Diagram. The first component offers both a SQL metamodel (partial, mainly covering the SQL “INSERT” instructions so far) and the corresponding model discoverer. This discoverer allows automatically obtaining SQL models out of any SQL source code. If this latter contains INSERT instructions, they are going to be fully represented within the generated SQL model. The second component allows producing a UML Object Diagram model from a SQL model (as produced by the SQL Model Discoverer) and a simple profiled UML Class model annotated with database information (currently produced and annotated manually).

Challenge solved

While some useful components of the MDT were already available before ARTIST and provided by the two base platforms, namely Eclipse-MoDisco and Enterprise Architect, they had to be put into practice and improved accordingly based on the received feedback. Several brand new components have been developed such as the initial version of the JUMP prototype that allows extracting automatically UML profiles out of Java libraries/APIs, which is quite novel. From the C#/.NET side, extending the support provided by Enterprise Architect, additional components have been developed such as the SharePoint data model discoverer. Such a model discovery component is not so frequently encountered in the .NET world, where explicit models are not really widespread and usually considered in development processes. Furthermore, the model exchange capabilities between Eclipse and Enterprise Architect have been significantly improved too with respect to what existed before the project started (via a new EMF model import/export feature between Eclipse and Enterprise Architect).

Main innovations

The main innovation of the proposed toolbox is that it is open and extensible. At the global level, the main innovative aspect of this ARTIST Model Discovery Toolbox is its objective of providing a somehow equivalent support/coverage for different heterogeneous technical environments, complementary to existing solutions usually targeting more specific technologies or scenarios. Notably in the context of ARTIST, the focus has been set on two main (major) worlds: Java/JEE and C#/.NET. The base support currently offered relies on a set of well-established IDEs and related capabilities: Eclipse Modeling project for the Java world and Sparx Enterprise Architect for .NET world. They have been reused and extended in order to design and build the new components implementing the required functionalities.

The component JUMP is quite innovative. Today's modeling tools offer profiles specific to platforms, such as Java, as they facilitate model-based engineering approaches. Manually developing a rich set of UML profiles demands a huge effort when considering the large number of possible annotations in Java. To automate the generation of UML profiles we have defined an effective conceptual mapping between the two languages based on which the JUMP tool has been implemented. The JUMP tool facilitates to automatically generate stereotypes from declared annotation types and to apply them in the context of a reverse-engineering scenario. Thus, it allows developers to "jump" from Java to UML, thereby exploiting UML Profiles to also capture Java annotations at the UML level.

The Java-to-UML Activity mapping has been implemented based on the recent OMG fUML specification, which is quite novel, too.

R4: Model Understanding Toolbox

Objective

Provide a toolset that allows the generation of high-level models to get an understanding of the system to be migrated. Thus, the Model Understanding Toolbox (MUT) considers the discovered models of the legacy systems as input and computes different views by considering different viewpoints on the system that are tailored to the concerns of certain stakeholders. By providing different viewpoints, the systems can be examined in a systematic manner concentrating on certain aspects.

Description

In ARTIST Model Understanding, is defined as the refinement of previously discovered models to obtain higher-level models needed for the following steps of the process, namely forward engineering. In this case, higher-level models represent digested information from the software artefact, thus usually requiring a change in the representation format and data/content analysis process. For instance, generic UML models could be processed to obtain UML Component model as higher-level models. Building such component models require a further transformation/analysis of the information contained in the previously discovered low-level models (e.g. using some heuristics or knowledge bases).

Multi-viewpoint modeling has been one of the major achievements in the research field of software modeling by applying the separation of concerns principle in the modeling process and may be seen as an orthogonal mechanism to the module concept in the broad sense for dealing with complexity. This modeling style allows specifying large systems that would be otherwise probably not realizable in the same quality by just using one single view.

The ARTIST Model Understanding Toolbox (MUT) is intended to provide a set of tools that allow exploring the existing applications without having to deal with all the details at once. Thereby, the main focus is on the realization of the four major components constituting the Toolbox: Model Tagging, Model Query, Model Slicing, and Model Viewing.

Model Tagging is the refinement of models with supplementary information. This is obtained thanks to two components, the UML profiler, the PIM Abstraction component and the JMS Abstraction component. The aim of the UML Profiler is the application of UML stereotypes throughout the reverse-engineering of UML models from Java code. From the perspective of the forward-engineering, UML stereotypes can be used to render UML models more specific. The PIM Abstraction component automates the generation of high level PIM views for different concerns specified by the modeler. In practice, this implies the selection of a PI profile that characterizes the target PI view (i.e. for instance, a data model view, a service model view, etc.). PIM abstraction is a key important concept in MDE. By raising the level of abstraction of PSM low level models, high level PIM views of the application are obtained. These PIM views remove any platform specific information, simplifying the model, making it more focused and facilitating a deeper understanding of the application, from different concerned perspectives. The JMS Abstractor can be used to detect all JMS dependent classes and to identify their functional behaviour. This aims to extract all communication relevant information in order to generate a JMS communication model.

Model Querying techniques enable modelers to identify concrete elements within models, such as classes or components, which fulfill concrete querying criteria with regards to different modeler’s concerns. Searching criteria expressing these concerns must be matchable to the information shipped within the models, such as architectural patterns, model element properties, associations, etc. From a functional point of view, model querying techniques enable modelers to: 1) Express querying criteria with high level of expressivity, supporting logical connections between the criteria statements, the reference of model elements and their properties, and the relationships between them, 2) Create collections of multiple querying criteria and apply them to different input models, 3) Execute selected querying criteria on selected models (using matchmaking engines) obtaining matching model elements that can be inspected and 4) Use matching model elements as input for further model transformation techniques. In MUT these techniques are realized by using ATL-based querying, EMF IncQuery-based queryingg and have been used in the PIM Abstraction and the Component Model Generator tools.

The purpose of Model slicing is basically to generate a valid sub model from a typically large base model. The idea of producing a model slice from a base model is to withdraw elements that are considered as not relevant for a certain scenario or task. Model understanding is facilitated by selecting and rejecting model elements from a given base model. Compared to the result of a query, a model slice generates a model that basically reflects the structure of the base model. Furthermore, a model slice is considered as a valid model that conforms to the metamodel of the base model. This conformity to the metamodel of the base model differentiates a model slice from a view on a base model. A view on a model may exploit a different representation compared to the base model. Furthermore, a view may also add elements that are not covered by the base model, whereas a model slice solely covers elements of the base model. In ARTIST MUT, the model Slicing Framework covers (i) the model types injected to selection step and extracted from the extraction step, (ii) the slicing criterion that captures the point of interest, and (iii) the slicing configuration that steers together with the slicing criterion the selection step. The result of the selection step is the base model to which annotations are applied as a basis to determine on the elements that need to be covered by the produced model slice. Based on the annotated base model, the model slice is extracted. The extraction step is dedicated to produce a new model from the annotated base model. This newly produced model is what it is called model slice.

Model Viewing: The purpose of a view on a model is to obtain a representation that facilitates a better understanding of the initial model. This means changing the viewpoint that allows us to focus on concerns that are not clearly identified in the initial model. In ARTIST MUT, this is realized through the component viewpoint and the control flow viewpoint. Component models are first class models defined in UML and provide in a glimpse a broad representation of the entire application (or a significant part of it) addressing the software management concerns of the application owner. Hence, these views are quite useful to obtain a high level comprehensive understanding of the application. The generation of these views used to be manual task that requires a deep knowledge of the application, problem now being solved through the component viewpoint. Nonetheless, from PSMs representations of the application, it is possible to develop generic and reusable model understanding strategies based on model querying techniques) that identifies concrete model elements that can be used to identify components (or parts of them). Control flow viewpoint has as main aim to bridge the gap between the visualization of the data flow and the control flow in the small and in the large. While models like UML models already provide a form of visualization of the data flow and the control flow in the small, i.e., within one diagram such as the UML activity diagram, there is currently a lack of support for visualizing the dataflow and the control flow in the large, i.e., between the complete set of diagrams which are describing the systems.

Challenge solved

Multi-viewpoint modeling has been one of the major achievements in the research field of software modeling by applying the separation of concerns principle in the modeling process. This modeling style allows specifying large systems that would be otherwise not realizable in the same quality by just using one single view. In MUT the aim is to exploit the same benefits as arising when designing systems by using multi-viewpoint modeling techniques.

Main innovations

The main innovations of the components that apply these techniques can be summarized as follows.

  • Tagging of Models. Tagging is considered as a lightweight technique to facilitate model understanding by adding supplementary information to the original model. In the MUT, the UML Profiler is included to produce annotated UML models from the existing application. The UML Profile facilitates to produce platform-specific models (PSM) where the platform information is captured by the stereotypes applied to the PSMs.
  • Querying of Models. Provision of systematic, generic, extendable and reusable querying-base model exploration techniques and their implementations compatible with the baseline of Eclipse Modeling framework. These common querying techniques have been applied to the detection of model elements for different kinds of application development technologies (e.g., RCP and Sharepoint) and at different levels of abstraction (PSM, PIM).
  • Slicing of Models. The purpose of model slicing is basically to generate a sub model from a base model to reduce the complexity of the base by withdrawing model elements that are considered as not relevant for a certain task or scenario. MUT provides a model slicing framework that deals with multiple viewpoints of UML.
  • Views on Models. Provision of systematic, generic, extendable and reusable techniques enabling the detection of structural components, their boundaries and relationships, detecting common technological patterns in the input models, using querying-base model exploration techniques described above. These approaches have been specialized to the detection of J2EE, RCP and .NET components. Furthermore, MUT aims to support visualizing the data flow and control flow of applications in the large, i.e., between the complete set of UML diagrams currently used to describe applications.

R5: Model Cloudification Framework (MCF)

Objective

Provide a set of tools that allow refining models to support the cloudification and optimization at model level and generate the corresponding source code.

Description

MCF provides four main components to support the identified cloudification concerns, namely, user interface, multitenancy, persistency and security. These cloudification concerns have been selected because they are considered as most urgent from the perspective of the ARTIST use cases, and also because they are considered as the basic aspects to be included when cloudifying an application.

A significant number of applications were designed according to desktop-based architectures. Typically, they are realized in terms of a thick UI-frontend. The migration of these thick UI-frontends is challenging because common desktop-based UIs are typically developed using technologies that are not designed to be cloud compatible. The cloudification of a non-compliant Cloud application GUI requires (in most cases) profound architectural changes in the original application, primarily for replacing the non-Cloud graphical framework used to build its GUI, with another one that is Cloud compliant. MCF completes the specification of the functionality of a UI Cloudification framework that automates the cloudification of desktop-based thick UIs to the cloud.

When applying the concept of multitenancy in the cloud, a single instance of a deployed application serves multiple customers, where each of these customers is called a tenant. The idea is that tenants see the application as of their own: they are able to customize some parts of the application, store their own data, etc. The use of multitenancy helps saving costs, since the same software is shared by all tenants. The opposite is known as single-tenancy, where each tenant has its own instance of the software. In the ARTIST project we have focused mainly on multitenancy at the data level: only one table, one table per tenant, but in a form that it can be extended to other multitenancy levels and implementations.

Today’s cloud providers offer several different datastore solutions that are beneficial for specific scenarios. For instance, so-called NoSQL solutions are frequently used in order to support highly scalable applications. As a result, application back-ends and the pertinent data need to be migrated to be fully operable with novel advances of cloud environments. The component offered as part of the MCF allows generating Objectify-based application back-ends from UML class diagrams. Objectify is a framework for accessing the datastore of Google’s cloud environment.

With the advent of cloud paradigm, users typically need to work with multiple applications provided and hosted by different organizations and it is usually desirable that users do not have different credentials for each one, as this can lead to have several risks. A solution to these new arisen security problems is the adoption of federated identities, or even Single Sign On paradigms. Separating user authentication from the application code, and delegating authentication to a trusted identity provider, can considerably simplify development and allow users to authenticate using a wider range of identity providers while minimizing the administrative overhead. To achieve that, ARITST has created a centralized authentication enforcement that performs authentication of users and encapsulates the details of the authentication mechanism. The Authentication Enforcer pattern handles the authentication logic across all the actions within the Web tier and it assumes the responsibility for authentication and verification of user identity and delegates interaction with the security provider to a helper class.

For the .NET world, other components have been implemented. The DB Model to EDMX (to C# source code) and DB Model to Services component is the second part of a complete migration chain, i.e. forward engineer the platform independent Database model (obtained by the component part of MDT) into a platform specific Entity Framework model that is expressed in EDMX. This model can then be used as input for the final phase in which the actual code can be generated. This model mainly focuses on C#/.NET applications. In the context of migrating SharePoint list definitions towards a relational database schema, this component is the second part of a complete migration chain, i.e. forward engineer the platform independent Database model (obtained by the component part of MDT) into a platform specific Entity Framework model. This model can then be used to either generate the database schema (and consequently also the database) as well as generate the data access layer for performing CRUD operations on this database.

In addition to these cloudification concerns, optimization issues regarding non-functional properties (NFPs) of the migrated application have been taken into consideration. In the context of ARTIST, the focus is on patterns that are applied in order to optimize the NFPs of an application that is to be deployed on the cloud. In this sense, in ARTIST, it has been defined a Cloud Optimization Patterns Catalogue, where more than 30 patterns along with, among other aspects, the NFPs they improve (and may also worsen) are detailed. Out of these patterns, the most relevant ones have been implemented as concrete transformations and profiles. These include 1) Key Value Storage, 2) Caching, 3) Multitenancy, 4) Materialized View, 5) Circuit Breaker, 6) Cloudification of resource monitoring concerns, 7) Federated Identity.

Since ARTIST has focused right from the beginning in Java and C#, two code generators two code generators to reach these platforms from the ARTIST modeling approaches have been generated. Both code generators consider the UML class diagram language of the UML language family and follow the same design rationales: 1) Contract-based code generators; 2) Open, extensible, and configurable code generators; Semantic-preserving code generators; and 4) Understandable code generation outputs.

The UML2Java code generator extends the Acceleo-based code generator developed by Obeo Networks for the needs of the ARTIST use cases. First, generic support for UML profiles has been added. Thereby, UML profiles are considered as annotation mechanism. In this sense applied stereotypes at the modeling level are considered as Java annotations at the programming level.

The C# code generator adapted for ARTIST, is based on Enterprise Architect, EA’s code template framework and an additional model validation component and it consists of two components: First, a model validation component and, second, the code generator plug-in using the code template framework. In order to generate valid C# code, the model is validated before it is generated. During this validation process, violations are resolved automatically, semi automatically or manually.

A modernization scenario (from reverse engineering to forward engineering, including the generation of code) often requires carrying out several different transformations to ultimately gain the modernized software artefacts. These transformations need to be properly chained and maintained because typically a diverse set of transformations realized by different transformation languages need to be executed in an appropriate order in particular if there are dependencies between these transformations. For instance, a transformation may require models as input that is produced by another transformation as output. In such a case, the order in which they are executed is vital for the produced result. To achieve that, ARTIST has developed a dedicated language that allows multiple transformations to be composed into a transformation chain, thereby enabling their automatic execution if the chain becomes executed. Chaining transformations fosters reuse in the sense that existing transformations are loosely coupled by a more coarse-grained transformation.

The traceability between model and code in the context of code generation is a key aspect. In particular, for debugging purposes, this kind of tool support is of paramount importance as well as for change management when the code or the models have to evolve. An Eclipse-based tool has been developed allowing reusing the code of the system to be migrated in a non-intrusive way, i.e., without modifying the models generated all along the process. The Reusability trace tool (RTT) allows the user to set the criteria for selecting the code he/she thinks appropriate to reuse. After setting the criteria to be applied, an algorithm is executed. This algorithm uses quality – related metrics (e.g. maintainability) and, when finished, the user sees on a window the set of code snippets automatically proposed to be reused (class and method names). Through this result window, the user is able to decide whether to accept the automatic proposal or to make some changes by selecting/deselecting the corresponding method names (via check boxes). The finally selected method names are registered in a configuration file. Inside the MCF, it is implemented a mechanism that allows the user to rewrite the code generated with M2M and M2T transformations by accessing directly the source code and the list of reusable methods in the previously produced configuration file. The idea is to inject the original code directly on those parts of the application that cannot be generated through forward engineering techniques.

Overall, ARTIST aims for validation requirements for the code generators by establishing hard criteria which can be used for validation purposes. In particular, completeness and correctness of the generated code with respect to the UML models as well as the maintainability and understandability of the generated code are critical issues for ARTIST. For the first part, ARTIST employs a dedicated testing framework which is derived from the UML metamodel in order to guarantee that no concepts are missing as well as from formal semantic descriptions for UML. For the second part, ARTIST employs a formal metric framework which can be used for the generated code.

Challenge solved

Migrating non-cloud applications to the cloud involve profound changes in their architecture design. Cloud-based applications aim to share resources by making use of the multitenancy characteristic. This means that the user interface layer has to be changed so as to distinguish multitenancy and user, and security is more important than ever. In this case, for tenants not to access the resources of other tenants, a federated security is needed. Furthermore, in cloud applications, non – functional properties such as scalability are critical. A description of optimization mechanisms for cloud-based applications was not available in literature, and most importantly, they were not available following the MDA approach.

The last step in a model-driven modernization project is the generation of source code. Existing code generators are not yet prepared to generate source code ready to be deployed for the cloud. Thus, an extension of such code generators has been targeted by ARTIST and in both languages relevant for the project, namely C# and Java. Finally, to support the correctness, completeness and maintainability of the models and source code created by ARTIST, dedicated quality frameworks have been developed. Up to our knowledge, no such solutions exist.

Main innovations

The solution adopted in ARTIST to address the transformation of PIMs obtained in the reverse-engineering phase into cloudified PSMs (i.e., first step of the forward engineering phase) is addressed according to MDA principles. Following such principles, ARTIST defines a generic approach to obtain the PSMs. In particular, a generic model-to-model (M2M) transformation that serves as kind of template in order to cloudify the PSMs with different concerns is defined. This cloudification is achieved with the addition of UML stereotypes to the concepts of the PIM. They are applied on PIM models by extending the generic M2M transformation. These stereotypes are, in turn, part of UML profiles that represent different cloudification concerns. Furthermore, the use of the UML language with applied stereotypes is a novel way to represent domain-specific languages (DSL) for the cloud, as opposed to other approaches that aim for the definition of cloud DSLs from scratch. With the ARTIST approach, the models can be part of existing MDA processes and tools that consider the use and manipulation of UML models.

Since the cloud is a relatively recent concept, the literature is not as extensive as in other areas. This is also applicable to the definition of patterns in the cloud domain. As far as ARTIST is concerned, this is the first work that focuses on the identification of patterns targeted at the optimization of non-functional properties of systems that are to be migrated to the cloud. This means that, in order to make the most of the cloud environment, a user can apply these optimization patterns for satisfying several requirements that are expressed in the form of improving specific non-functional properties. Moreover, some of these optimization patterns are implemented following the MDE approach of the project, by making use of profiles for representing the patterns. Finally, the last innovation with respect to the optimization patterns is the definition of a conceptual categorization of these patterns. Thereby, seven categories in which our optimization patterns can be classified in the context of the ARTIST project have been defined. Up to our knowledge, such classification is new. Its main aim is to group the patterns according to the conceptual problem (without considering specific and technical details) that the patterns in each category try to address.

With regards to code generators, ARTIST has extended base code generators for Java and C#, the two leading programming languages target in the ARTIST project. In this regard, ARTIST has extended and configured existing code generators for particular cloud platforms. ARTIST has extended and applied the Acceleo-based code generator provided by Obeo Networks, since it provides an extension mechanism that allows specific templates to be plugged in a generic code generator. As for C#, ARTIST has dealt with the Enterprise Architect’s code generator framework. This code generator provides a set of templates that encode a mapping between the UML concepts and the programming languages concepts. As extension points, the generator allows the edition of the templates, so that we obtain the desired mapping.

Another innovation is the validation of code generators by reasoning about completeness and correctness of the generators as well as the non-functional properties of the generated code such as readability and maintainability. For this, ARTIST employs a dedicated testing framework that is derived from the UML metamodel in order to guarantee that no concept is missing as well as from formal semantic descriptions for UML and a formal metric framework that can be used to measure the quality of the generated code.

In order to obtain the cloudified application architecture and its source code, ARTIST relies on a chain of transformations. The Transformation composition language, created in the ARTIST project, allows multiple transformations to be composed into a transformation chain, thereby enabling their automatic execution if the chain becomes executed and the reuse of them in the sense that they are loosely coupled by a more coarse-grained transformation.

R6: Deployment Toolbox

Objective

Provide a generic tool-supported approach that allows the user to select an appropriate cloud provider and guide the developer through this complex decision making process; to model the concrete deployment requirements and topology for their application components and to generate target-specific deployment descriptors from the former models.

Description

The Deployment toolbox is composed of four components: CloudML@ARTIST, the cloud target selection tool, the modelling of the deployment and the actual deployment tool.

CloudML@Artist meta-model has been created in order to respond to two existing needs at ARTIST project level. On one side, modelling cloud providers in order to select the most appropriate, depending on the specific service needs of an application. On the other side, modelling the deployment characteristics and values of an application in a concrete cloud provider, once it has been selected. To accomplish this, CloudML@Artist is composed of an extensible set of UML profiles through which it is possible to model the main features of cloud providers, as well as modelling capabilities to describe services that can be offered under the SaaS model. These same profiles can be used also to specify values related to concrete deployments. CloudML profiles include: 1) core profile: containing generic stereotypes and data types that can be applied to characterize entities belonging to different cloud providers. The core profile is also divided into three sub-profiles representing the core characteristics of IaaS, PaaS and SaaS providers; 2) pricing profile, which can be applied to any cloud provider to model pricing related aspects; 3) Availability profile, that permits to model cloud provider availability related aspects, as these are expressed in the SLAs; 4) Security profile, which is used to specify security related characteristics at provider level; 5) Benchmark profile, which can be included when modelling a cloud provider to specify results of benchmark tests, when attached to specific service instance types. In addition to these profiles, three cloud providers have been modelled. These are Windows Azure, Amazon EC2 and Google App Engine.

Selecting the cloud platform where onto deploy the application is not an easy task. The Cloud Target Selection tool aims at guiding the user through the complex process of making the final decision for the target platform of the migration of their application or application components. This tool targets developers who have a good insight of the application's technical and functional needs, but little knowledge about the services or the benefits coming from the cloud platform providers. The cloud target selection tool consumes the cloud providers’ models created with CloudML@ARTIST.

The deployment topology is modelled in ARTIST through the Cloud Application Modelling Language (CAML) that enables cloud-based deployment topologies to be represented directly in UML and their refinement towards a concrete cloud environment. Features of existing cloud environments are captured by dedicated UML profiles. Thereby, a clear separation is achieved between cloud-environment independent-, and cloud-environment specific deployment models which is in accordance with the PIM/PSM concept. In ARTIST’s case, the “platform” refers to the cloud environment.

The Deployment Tool follows a two-step process. It first generates a model (PSM) for deploying the application in a selected target Cloud provider. This model contains all the information required to generate the deployment artefacts for the selected target Cloud provider. In the second step, the Deployment Tool based on the application deployment model (PSM), it obtains the target specific deployment descriptors. Additionally, the Deployment Tool can pack these descriptors with the migrated compilation units (provided as input) to generate deployment units. Besides, a similar technique can be used to generate target-specific deployment scripts.

Challenge solved

The selection of the most appropriate cloud provider is a time consuming task for a software developer. The DT aims to solve this issue by providing the user with means (information in a human consumable format) to decide which cloud provider is in principle the most suitable for him with respect to a set of requirements established by him.

Current cloud modelling approaches address the diversity of cloud environments by introducing a considerable set of modelling concepts in terms of novel domain-specific languages. At the same time, general-purpose languages, such as UML, provide modelling concepts to represent software, platform and infrastructure artefacts from different viewpoints where the deployment view is of particular relevance for specifying the distribution of application components on the targeted cloud environments. The generic nature of UML's deployment language calls for a cloud-specific extension to capture the plethora of cloud services at the modelling level, solved by CloudML@ARTIST / CAML.

The existence of a plethora of Cloud providers, with their offerings and services, imposes a diversity of deployment approaches, interfaces and services. Initiatives to harmonize this diversity, offering a common deployment interface have focused mainly on supporting the Cloud infrastructure, but only recently standardization initiatives to harmonize the deployment on the platform have started. The modelling language supporting deployment specifications (UML combined with CloudML@ARTIST) defined in ARTIST can be exploited to generate the required deployment descriptors for a selection of Cloud providers.

Main innovations

The most relevant innovative elements are related to the capacity offered by CloudML@Artist to model the SLA offered by providers in terms of availability and performance. Furthermore, the metamodel defines the necessary structure, in order to directly insert performance information of Cloud offerings in a variety of application types, through the use of relevant benchmarks. This structure includes also the workload under which the test was performed. In addition, placeholders have been included in order to keep historical information on availability statistics of the Cloud offerings, either in the form of generic availability measurements (e.g. performed through the CloudSleuth web site) or adapted to each provider’s definition, which is an indication of how frequently SLAs are violated by each respective provider for the specific offering.

The main innovation of the Cloud Target Selection tool lies on the challenge of exploiting the CloudML@ARTIST model structure. To achieve that, a fully extensible mechanism has been created which supports the filtering of the information contained within the meta-models and providing it to the end user in a human-consumable format through a user-friendly environment. From the extensibility point of view, extensions can be easily made in order to support even more perspectives of the existing underlying models, or extensions of them. E.g. legal aspects, and benchmark results. The information exchange taking place through the interaction with the user does not require but a minimum set of knowledge about the elements described and defined in the meta-models. This means that, in the future, potential changes in the cloud providers’ descriptions or even in the definitions of general cloud environments in the context of CloudML@ARTIST meta-model, will not result in non-compatibility with the tool. On the contrary, new features can automatically be detected and take their place in the equation solving the problem of selecting the cloud target. Finally, it allows the user to express their requirements against the target cloud environments, thus fully utilizing and exploiting all the benefits coming from the construction of CloudML@ARTIST modelling language. The users’ expression of cloud requirements immediately and automatically result in reports and suggestions about the best matching supported provider. Otherwise, this task, even with the use of the same meta-models, would take a lot of time and effort while it would absolutely require a good level of modelling knowledge in general and in particular about the specific meta-models in use.

The Cloud Application Modelling Language (CAML), developed as part of CloudML@ARTIST, has as main aim to enable cloud-based deployments to be specified directly in UML. This is especially beneficial for migration scenarios where reverse-engineered UML models are tailored towards a selected cloud environment as it is advocated by ARTIST.

The existence of a plethora of Cloud providers, with their offerings and services, imposes a diversity of deployment approaches, interfaces and services. To solve that challenge, ARTIST has created a novel common modelling language supporting deployment specifications (UML combined with CloudML@ARTIST) can be exploited to generate the required deployment descriptors for a selection of Cloud providers (i.e. Google App Engine, Microsoft Azure), by developing model-to-model transformations, which convert deployment models, compliant to UML-CloudML@ARTIST into those compliant to the specific Cloud meta-models describing those descriptors. A set of model-to-text serializers, also developed in this work, generate the descriptors. This approach is generic, and can be extended to support the deployment into any other Cloud provider, with low effort.

R7: Repository and Marketplace of Reusable Artefacts

Objective

Provide a unique central point where developers can publish and consume reusable artefacts (e.g. models, transformations) that aid them in the activities of their migration project, and that fosters artefact reuse in order to reduce project cost and risk. In addition to that, provide support for artefact evolution.

Description

During a migration project, a considerable number of artefacts are being produced in the reverse engineering process (as result of the application of MUT and MDT) and in the forward engineering phase (as result of the use of the Cloudification Modeling Toolbox and the V&V toolbox). Some of these artefacts are application specific but others deal with concepts on a higher level of abstraction and can potentially be reused across different migration projects. These artefacts for example describe technologies (by means of a meta-model) or enable a mapping between different technologies (via transformations). While these artefacts are expensive to create and require a lot of technical and domain knowledge, their application independence makes them reusable across many migration projects. The key factor to leverage this reuse potential is developer support via a reuse infrastructure like the ARTIST Repository, the web-based ARTIST Marketplace and their Eclipse integration.

The central component of the reuse infrastructure is the ARTIST Repository server that offers services to manage MDA artefacts like models, meta-models or transformations produced during migration projects. It organises artefacts in projects and packages and allows describing them with meta-data like structured text, images, categories and tags. Artefacts can be retrieved either by browsing the structure, category hierarchy or tag list or by searching the meta-data. Interaction with the users is supported by user comments and ratings. Since the repository can potentially contain IPR sensitive information, security and access control are provided by OAuth2 authentication and entity-level authorization.

The second component is the ARTIST Marketplace, which is a web-based platform backed by the repository. It is available to the MDA community, promotes the publicly available reusable artefacts produced in the ARTIST project and offers users the opportunity to publish and promote their own work or to provide their feedback to the existing content. The ARTIST Marketplace brings producers and consumers of MDA artefacts together, fosters reuse and creates added value for both of these groups. Once such an artefact has been produced, the creator can benefit from his efforts by publishing the artefact on the ARTIST Marketplace. Then she can get feedback from the community to improve the artefact, improve his reputation by demonstrating competence or good will for the community and can potentially generate additional revenues by selling the artefact over the marketplace. On the other hand, developers can save time and effort by reusing artefacts from the marketplace.

The layered architecture of the repository allows external tools (like the other ARTIST tools) to access the repository functionality on three levels making it open for integration into other systems: via the REST-based web service provided by the server, via the Java-based service API provided by the server and the API client, and via the Eclipse Client Plugin. The open interfaces where used to create a Repository Client for Microsoft Visual Studio that integrates the repository services into the .NET world.

For a marketplace to have success in the market, it needs to contain an initial set of reusable artefacts. The ARTIST Marketplace contains on one hand, general-purpose artefacts in MDE (meta-models, UML profiles, mode-to-model transformations or model-to-text transformations), both generic (e.g. a UML meta-model) and domain-specific (e.g. a J2EE profile or a model-to-model transformation applied to a certain environment), and on the other hand, general-purpose MDE artefacts that have been created in response to the needs of the different ARTIST use cases to apply ARTIST migration techniques in their concrete domains. Repository and marketplace contain about 60 reusable artefacts produced in the project.

As time goes by, artefacts evolve and the repository may contain multiple versions of the same artefacts. The ARTIST Evolution Service and the ARTIST Artefact Context Explorer aim to provide support for different aspects of artefact evolution. The focus of the Evolution Service is on so-called intra-artefact evolution that means that is creates high level descriptions of artefact changes by looking inside different versions of an artefact. To record the changes that have occurred in an artefact, a dedicated Change Description Language (CDL) has been defined. The Evolution Service has been integrated into the ARTIST Repository. The aspect of inter-artefact evolution is covered by the Artefact Context Explorer that detects and visualizes relevant relationships between artefacts for search and impact analysis. Thus it provides support for maintenance and evolution by making dependencies between different MDA artefacts explicit and visible.

Challenge solved

During a migration project, a considerable amount of information is captured from the reverse engineering process and produced in the forward engineering process in form of various MDA artefacts. It is essential for the success of the project to count on tools that help to manage and organize these artefacts as well as support their efficient reuse. This tool is provided in the context of ARTIST, in the form of a repository, which makes available and accessible the knowledge (e.g. meta-data) contained in it. The challenges that this tool solves include: 1) to foster reuse of modelling artefacts such as model, meta-models and transformations. (marketplace), 2) improve comprehensibility and manageability for large numbers of artefacts (repository) and 3) Support the evolution of artefacts by tracking and evaluating changes produced in them (evolution service).

Another challenge solved is related to the number of artefacts that the repository holds. Even though a few artefacts required by the use cases have been obtained externally through the initial survey on the state-of-the-art, most artefacts have been either developed from scratch or by extending some of those artefacts already provisioned by the state-of-the-art survey. This approach for provisioning new required artefacts, by extending (or customizing) existing ones, shows best practices for attaining a sustainable repository of community-maintained MDE artefacts.

Main innovations

Provision of a collection of reusable, extendable, general-purpose and domain/platform-specific MDE artefacts required for the materialization of the ARTIST use cases by means of a repository. The repository manages artefacts that are being produced and processed tools during a modernization project and it provides the foundations for a reuse infrastructure based on the following features: 1) Immutable artefact versions: Old artefact versions remain unchanged and are still accessible; 2) Search by classification, tags, full text or content meta-data allows finding suitable artefacts; 3) Browser based marketplace: Reusable artefacts can be published to the web based Marketplace to promote their availability for future reuse; 4) Community interaction and user feedback via comments and ratings; and 5) Fine grained access control to protect potentially IPR sensitive information.

In the Eclipse community there exist a number of tools that can compute the differences of model versions and variants These tools are targeted to a specific modelling technology (mostly EMF/Ecore), require a local installation in a development environment that provides all necessary software (including dependencies) and produce difference models formulated in the underlying modelling technology. The ARTIST Evolution Service is provided as a standalone Software as a Service and therefore can be used independent of a specific development environment. Its extensible architecture based on pluggable processors makes it possible to extend the differencing functionality to different modelling technologies. Furthermore, the dedicated Change Description Language is not tied to EMF or any other specific technology and so provides a technology agnostic way of describing model changes. These factors make the Evolution service applicable in both the Java and the .NET world which is something that up to our knowledge has not been done before.

The Artefact Context Explorer detects relationships and dependencies between MDA artefacts and links them to versioning information gathers from source control systems and to task information obtained from bug trackers. Its main innovation is that it relates these information items to the respective artefacts and visualizes all information in a graphical way that allows for exploring and browsing the physical and logical context of MDA artefacts.

R8: Verification and Validation Toolbox

Objective

Provide a set of tools where application developers can verify that the migrated application behaves equally to the non-cloud application, considering both at model level and end user testing, and also can verify that the desired non-functional properties established by the user in the beginning of a migration, have been successfully achieved.

Description

The V&V Toolbox is composed of three approaches and the corresponding components: test-case based approach, end-user based tester and the verification of non-functional properties and migration goals.

The ARTIST test-case based approach focuses on checking the functional equivalence at model level, and it is complemented with the end-user based approach, executed after the migrated application has been deployed.

The ARTIST model-based tester follows a six-step process, which are: 1) Build a model of the system under test (SUT) from a specification: this so-called test model represents the intended behaviour and is later used to derive concrete test cases. It is also possible to derive a test model from the existing development model or code instead of using a specification, but in such a case it is possible that errors are propagated from the existing system or development model into the test cases; 2) Choose test selection criteria to specify the testing purpose, namely, structural coverage, data coverage, requirements coverage, ad-hoc test-case coverage, fault-based criteria and stochastic and random. Each of these criteria will guide the generation of test cases in the testing tool; 3) Create a test case specification based on these criteria, that is, transform the given test case selection criteria into the necessary specification internally; 4) Generate test cases to satisfy the test case specification: To create test cases, a generator takes the formal test case specification and the test model as input and produces a test suite (a set of test cases). Several techniques (e.g. random generation of tests, search-based tests) are used for this; 5) run the test cases against the SUT: When making abstract test cases executable, it is often necessary to concretize the input for the SUT and abstract the output from the SUT to be able to compare them. While the abstract test cases can be independent from the programming language and execution environment of the SUT, the concrete test cases must be specific to the programming language and execution environment; and 6) analyze the results of the test cases: Each test case runs against the SUT and yields a verdict after it has been performed. This verdict can either be a pass in case of a positive result, a fail in case of a negative result and inconclusive if the result cannot be determined.

The behavioural comparison performed with the ARTIST approach is realized at model level. In particular, both the original and migrated applications are needed in order to have their behaviour represented as UML activity diagrams. The ARTIST approach aims at defining and providing generic test cases with the component that can then be used in any application. In fact, the idea is that after the user uses his/her knowledge to map the concepts of such test cases with the concrete applications, the test cases are automatically included in the application.

The goal of applying end user-based testing (EUBT) in ARTIST is to test the behavioral equivalence of the migrated software with respect to the original software by having the user generate real world test cases. The methodology followed for the EUBT is divided into five consecutive steps. The first two steps are used to bring both, the migrated software and the original software, into the same state by executing the same request. The last three steps are concerned with retrieving the execution traces, the abstraction of the traces, and the comparison of the traces. Each step is described in the following sections. The ARTIST EUBT methodology is concerned with automatic verification of the behavioral equivalence between the original system and the migrated system and that therefore new features (e.g., operations that cannot be traced back to the original application) not covered in the original system must be checked manually or by providing additional information.

The approach followed for the verification of non-functional properties is as follows. First the migration success criteria can be defined in terms of non-functional properties of the existing and the migrated application. Secondly, different evaluation strategies are introduced in order to measure a selected set of properties on model-level. Thirdly, an iterative process has been defined that supports the selection of optimization patterns to improve the properties of interest during the migration phase. And finally, the overall migration success is evaluated based on the measurements taken by the evaluation strategies and the optimization patterns applied.

Therefore, to trigger the verification of the migration goals, the user needs to be able to express non-functional properties of interest for the migration. In ARTIST, the user is supported in this task by providing a domain-specific language (DSL) to create so called property catalogues which group a set of properties together. Based on the properties defined in property catalogues, the user can then define the migration success in terms of goals, i.e., conditions or constraints on those properties. All user-defined migration goals are collected in a so-called goal model which conforms again to a dedicated DSL defined for ARTIST. This goal model serves then as one of the central artefacts in the overall migration process. Specifically, it may be used to guide the optimization of the application through instantiated optimization patterns (see MCF) and serves as basis for the evaluation of the migration success. The second main component consists of three evaluation strategies that are able to evaluate the properties of interest specified in the goal model through different techniques. Specifically, three strategies that target different properties have been developed: 1) Evaluation of performance-related properties through model simulation based on fUML; 2) Static model analysis techniques to evaluate the complexity and maintainability of the application; and 3) Re-use of the benchmarking values to estimate cloud provider-specific properties. The next step is to consider the optimization of the application through optimization patterns and how those patterns can be applied to improve the properties the user has goals defined upon. The approach proposed is as follows. In the first phase, a preliminary set of promising solutions, i.e., pattern configurations, is computed using a genetic algorithm and in the second phase, this set of solutions is evaluated in more detail using the evaluation strategies such as the model simulation based on fUML. During the search, each candidate solution is evaluated in how close they are to fulfilling the migration goals. Finally, we evaluate the migration success based on the optimization patterns that have been applied and the measurements that have been taken. Specifically, we perform impact analysis to consider the influence of optimization patterns and we calculate the distance between the measurements of the improved properties and the user-defined goal values to evaluate the migration success.

Challenge solved

When migrating an application, the behaviour of the new one must be equal to the behaviour of the old one. A one dimension solution for this may not be enough. Furthermore, performing verification activities at code level may impose several risks. The ARTIST approach for behavioural equivalence follows a two dimension approach. Firstly, a test-case based approach at model level, which allows the simulation of the behaviour application, without having to deploy it. Detecting errors at model level, before the system is deployed on production, reduces time and costs for the design-development-deployment-testing life-cycle and, more importantly, it improves the quality of systems on production. Secondly, the end user based testing approach, allows to perform parallel behaviour equivalence testing on two distinct applications, by simulating the users’ requests in the application.

Cloud-based applications have often non-functional constraints that other applications do not have. Furthermore, the evaluation of a cloud migration success in terms of non-functional properties in an automated way is still to be found. Moreover, how to optimize the application by means of optimization patterns and in which order to achieve the set of migration goals is not a trivial task.

Main innovations

In the case of the model-based tester following the test-case based approach, the knowledge of the user about the application that is being migrated is a central aspect. In this sense, and due to the lack of test cases in the applications of the use case providers in the ARTIST project, the user also takes part on the testing process. Another important aspect of the ARTIST approach is that artefacts are used at model level as the sole specification of the expected behaviour of the migrated models and the migrated software, since the original software is in fact a valid implementation of the reverse-engineered models. Another reason to stay at this level is that it may not be feasible to provide a running instance of the original system due to some reasons such as its age, so there may be a lack of engineers with the expertise to deploy or execute such systems. For this reason, representing the software as models allows to use model simulation techniques to simulate the behaviour of the system.

The use of models also allows to avoid the problem of the state space explosion. In fact, since the test generation is performed via criteria specified by the user, ARTIST focuses only on testing the important aspects of the system. Furthermore, detecting flaws at model level, before the system is deployed on production, reduces the time and costs for the design-development-deployment-testing life-cycle and, more importantly, it improves the quality of systems on production. On the other hand, detecting flaws in production may have a strong negative impact on the business.

For the EUBT, the complementing approach in the testing of the behavioural equivalence, the main innovation is represented by the architecture that has been developed and includes the execution of a novel grey-box testing technique that allows to perform parallel behaviour equivalence testing on two distinct applications by taking into account their migration trace. Furthermore, while the prototypical implementation proves the feasibility of the approach, it also shows that the architecture could potentially be used in a large set of scenarios. This means that not only SOAP web service applications, but other kinds of applications (e.g., REST web services or even desktop GUI applications), could be tested on behavioural equivalency by developing a solution based on the proposed architecture.

With respect to the verification of non-functional properties, the main innovation lies on the provision of a set of novel languages to define the necessary migration artefacts in terms of models. This set includes most importantly a way to express software properties in a concise way, re-using existing and standardized type definitions, and a language the user can use to define migration goals based on those properties. Furthermore, three novel evaluation strategies are introduced. These can evaluate both static and dynamic properties on model level. And finally, we have developed an innovative framework that applies search-based software engineering techniques to find an optimal sequence of model transformations in order to reach the user-defined migration goals as closely as possible.

R9: 3Alib

Objective

Provide means to measure the availability of services using an abstracted approach, regardless of the supported provider on which they are deployed. Such library will be able to calculate the actual levels of availability as defined in the respective providers SLA.

Description

The 3ALib Java library is an abstracted way of taking measurements regarding the availability of services, regardless of the supported provider on which they are deployed. Furthermore, the library is able to calculate the actual levels of availability as defined in the respective providers SLAs. 3ALib is implemented as a Java library, which uses Apache Jclouds API as a means to abstract from the specificities of Cloud providers APIs and data format. Furthermore, it implements specific drivers for each provider, in order to enforce the specific preconditions that are mentioned in their respective SLAs and the specific calculation of availability followed by each provider

Challenge solved

Each cloud provider has a definition for term availability in their SLAs. When a user suspects that the availability level of a provider, as defined in their SLAs, is not being fulfilled, he needs to provide proves that the cloud provider is breaking a contract. With that aim the 3ALib has been created. The goals and challenges that the library aims to solve are: 1) inform users on why their services do not adhere to the SLA; 2) keep detailed logs of the availability of services and 3) calculate availability levels based on the providers definition and be used for compensation claims (together with the aforementioned logs).

Main innovations

The Abstracted Availability Auditor Library (3ALib) innovations can be summarized as follows:

  • It is an abstracted library, meaning that a single method is exposed to the user to utilize for measuring the SLA levels of their services independent from the used provider, while hiding in the backend the differences between provider APIs, through the use of Apache JClouds library. This enables its ease of use.
  • It adapts to each provider’s definition of the SLA, a very important aspect for someone to claim compensation from the respective provider. These definitions have significant differences and preconditions, which are checked per provider in the library, through the implementation of respective drivers.
  • It logs the availability samples that are needed as forensic evidence by the providers for the acknowledgement of the violation and calculates the availability levels (according to the provider’s definition) from the samples.
  • It can instruct users as to whether their current usage/application deployment of Cloud services is actually eligible for an SLA, and can consult on what is needed for this to be realized.
  • It can be used to centrally gather statistics from multiple users regarding the behaviour of Cloud services, thus enabling accumulated statistics and potentially exploitation scenarios through Business Intelligence analytics.

R10: Benchmarking Suite

Objective

Provide a homogeneous, consistent toolkit for measuring the performance of cloud services, while automating the tests as much as possible.

Description

A framework for managing the execution and storage of data of benchmarking tools. The modular and flexible architecture allows to incrementally add new tools and automation scripts in the repository extending the coverage of benchmark tests offered by the ARTIST Benchmarking Suite.

The Benchmarking Suite is a set of selected third-party benchmarking tools (e.g. YCSB, DaCapo, FileBench, Dwarf, CloudSuite, DataCaching) packaged and delivered thorough the ARTIST Repository, along with a newly developed benchmarking controller and a GUI. One of the extensions ARTIST contributes to the CloudML@ARTIST meta-model is the possibility of modelling performance aspects of services offered by cloud providers. Along with the extensions defined in the meta-model, in order to ease the collection of performance data, ARTIST provides also a tool to configure, execute tests and collect results, based on a set of third party benchmarking tools, in order to evaluate performance values that will be added to the cloud provider models.

Challenge solved

Existing benchmarking tools are very heterogeneous concerning their distribution methods, installation, configuration, and execution, as well as their approach to collecting and formatting their results. In addition to that, they are mostly manual. However, the automation aspect is very important in this context because benchmarking tools provided by ARTIST are meant to be executed several times on all the infrastructures modelled also to capture variation in the performance values. We believe that making it possible to manage execution and collection of data automatically saves a lot of time to users and produces better quality results.

Main innovations

The most innovative aspect of the Benchmarking Suite is in the management of the benchmarking process. In fact, the Benchmarking Suite is a fully automated solution that, through connectors, is able to provision cloud resources, install and execute benchmarking tools, retrieve results and, eventually, destroy provisioned resources.

Compared to other available bench marking solutions for Cloud, the ARTIST Benchmarking Suite drastically reduces the manual intervention in the benchmarking process allowing massive and large-scale tests.

Such suite allows carrying out tests and getting performance metrics in a homogeneous and independent way (without regards to those published by the providers). Metrics can then be used to collect, over time, quantitative information about the performances offered and constitute the baseline for the selection of Cloud services during the optimization of the whole business process.

These results will be eventually directly injected into the Artist models representing providers, thereby enriching the modelling capabilities of the meta-model and covering a significant lack existing until now.

R11: Profiling and Classification Toolbox

Objective

Provide tools and methods that can highlight performance aspects of a running application component and the way it utilizes underlying resources.

Description

The Profiling and Classification toolbox classifiy an arbitrary application component to a predefined and known benchmark application category and then matches the application component (which is based on the aforementioned classification) with a cloud service offering (VM instance type). The correlation occurs by selecting the VM instance type which provides the best performance score for the detected benchmark profile in combination with the respective service offering cost. The goal of this tool is to suggest to the Application Developer the most fitting solution based on specific user interests (such as performance and cost) during the migration of an application to the Cloud.

The main purpose is to provide the appropriate tools to users in order to characterize the applications to the predefined stereotype and identify the type of the computational profile the components have. The process includes the profiling and classification phase that is automated through the development of suitable tools. At first, the user has to download the tools locally, install them and create VM’s with the benchmarks and the application components respectively. The Benchmarking Controller component (from the Benchmarking Suite) automates the downloading and the execution of benchmarks. After the execution the user by implementing the profiling and Classification tools reveals the application’s type based on performance measurements. The combination of information supports in the deployment process in order to identify the optimal selection of the target infrastructure or platform.

Challenge solved

For many application components the runtime behaviour and usage of resources may not be known, mistakenly considered or altered due to structural changes during the software migration. Thus a mechanism is necessary for identifying the computational nature of a software component, in a black box manner. The scope of this toolbox is to present such a mechanism that can acquire system usage information of a running component and then classify the latter to a list of well-known computational patterns.

Main innovations

The Profiling tool innovations can be summarized as follows:

  • It provides an automated way for identifying both application and benchmark computational profiles.
  • It Implements the basic mechanism for handling control and synchronization issues among all the tasks executing concurrently during the profiling process.
  • It offers two different usage modes of the Profiling tool: the application profiling and the benchmark profiling (significant difference in the level of automation between them).
  • Once the profiling process is completed, the results of the Tshark and Pidstat monitoring tools are transformed in the appropriate format in order to be used as input in the next phase which is the classification process.

The Classification tool innovations can be summarized as follows:

  • It provides users with an automated and simple way to identify the computational nature of an arbitrary component, map it to a known benchmark application category and rank cloud services according to the aforementioned procedure.
  • The ranking of the cloud offerings provided by the Classification tool is based on the Service Efficiency metric that calculates, in an understandable way to the users, the performance ability of a service offering according to specific user interests with relation to cost and performance.
  • Interacts with the local Raw DB and calculates the normalized values for both cost and performance and returns the normalized scores for Service Efficiency in order to have a more generic rating of cloud services.

It provides a decoupled architecture that allows the rest of the components to remain completely independent of the KNN classifier component. Thus, it facilitates the incorporation of various implemented classifiers.

R12: Certification Model

Objective

Provide a model to assess and certify service-based software application providers against an interpretation of existing standards (e.g. ISO 17789, ISO 2700x, OASIS TOSCA and so on), best practices and recommendations (e.g. IBM) and improvement models (e.g. EFQM, ITIL, CMMI-SVC) in order to create consumers’ confidence in software applications offered as service (SaaS).

Description

Traditional software vendors need to transform their current business and technology model in order to remain competitive. Software-as-a-Service (SaaS) is seen as the most promising way to achieve this change. The ARTIST project has proposed a software migration approach covering, in ad dition to the modernization of the application, the pre-migration and post-migration phases. In the post-migration phase, ARTIST aims at certify SaaS providers.

SbSp (Service-based Software providers) is the certification model that has been developed in ARTIST. SbSp aims to create consumer’s confidence in software applications offered as services.

The certification model is structured into four areas: Business, Process, Legal and Technology. The business area aims to analyse the financial stability and soundness of the business in order to assess the potential for continuity and sustainability. The process area aims to ensure the quality of the process of delivering the IT service to the end customer. The technology area aims to establish a high level of security and transparency for both customers and providers of dedicated SaaS applications. The Legal area is a specific category referring to the legal compliance of the application.

A certification model needs to have an associated certification method. A certification method is the procedure through which a third independent party evaluates the practices of a company providing a cloud application, in order to ensure that the system fulfils a specified level (Gold, Silver or Bronze).

The ARTIST complete certification method is structured in 3 phases:

1) Self-evaluation through online questionnaires.

SaaS providers respond to web-based questionnaires of self-diagnosis which assess business and technical issues. The evaluation report includes an approximation of the level of certification (Gold, Silver or Bronze).

2) Analysis of evidences - Silver or Bronze Certification.

The main activity of this phase is the receipt and analysis of evidences to support the answers to the questionnaires completed in the previous phase, in order to achieve the Silver or Bronze level.

3) On-site Evaluation - Gold Level Certification.

An assessment is carried out based on interviews and review of evidences at the location of the SaaS provider. On-site evaluation is necessary to obtain the Gold level accreditation.

Finally in order to support the certification process, four questionnaires have been developed: “Business Evaluation Questionnaire”, “Process Evaluation Questionnaire”, “Technology Evaluation Questionnaire” and “Legal Evaluation Questionnaire”. Overall, thirty-six categories (36) are revised in nearly 300 questions.

Challenge solved

Current standards and improvement models such as the ones mentioned beforehand focus solely on one dimension of the problem (except for ISO 17789 that presents three dimensions, business, process and technology) or on the support for provision of services, but not on the provision of software as a service, with the special characteristics that such software – based service possesses (e.g. SaaS are deployed often on a third party infrastructure as a service, legislation, architectural constraints to scale when necessary, a business model to ensure the continuity of the service, etc.).

Furthermore, certification schemes such as the ones listed on ENISA’s Cloud Certification Schemes List focus mainly in all three layers of the cloud stack, while the SbSp has as main target the SaaS providers of the cloud stack. This allows focusing and digging deeper in the main issues that concern the provision of SaaS (technology best practices, organisational processes, business continuity, legal compliance).

The already existing models, as the ones cited previously, are widely applied all over the world but do not cover the concerns of SaaS. This is the major challenge solved in ARTIST SbSp: address the specific concerns and characteristics of the provision of a SaaS application and the organisation providing it.

In order for a certification to be uptaken, the certification procedure should be light. This is especially critical in SMEs, which do not have the resources or structure to carry out costly (in time and effort) evaluations. The certification procedure proposed in ARTIST follows a lightweight approach, based on self-assessments and remote evaluations for the lower levels, and on-site short evaluations for the high level.

Main innovations

Key innovations of the SbSp Certification include:

  • Focused on certifying SaaS providers and their applications from different perspectives: Business, process, technology and legal, based on the interpretation of existing standards and best practices to support the specific characteristics of the SaaS industry.
  • The certification process, which is composed of three phases.
    • Self-evaluation through online questionnaires. The organisation gets an approximation of certification level
    • Analysis of evidences - Silver or Bronze Certification. After analysing the received evidences for supporting the certification level of the questionnaire, the Silver level or Bronze level will be granted
    • On-site Evaluation - Gold Level Certification. On-site evaluation is necessary in order to obtain the Gold level accreditation

Availability of Results

All project results are available for free to the public and most of them (addressed to software developers) under open source licenses (mainly EPL, although Apache, GPL and MIT have been also used). Only three of twenty four ARTIST tools are not being delivered under an open source license but offered for free use. They are the Maturity Assessment Tool (MAT), the Certification Model and the Business Feasibility Tool (BFT). The three tools are addressed to business consultants, respectively for analyzing the gap between the non-cloud application/business and the desired cloud complaint application/business; for certifying the compliance with the cloud of the migrated application; and for simulating several potential business scenarios according to the desired migration business goals. The value of these tools lies in the logic behind them rather than in the code itself, and they can be integrated with the ARTIST methodology, so they do not prevent the overall exploitation and sustainability of the ARTIST ecosystem.

All project publications are available at http://www.artist-project.eu/publications

All public deliverables are available at http://www.artist-project.eu/documents

All software tools are available at http://www.artist-project.eu/open-source-package

Potential Impact of the results

The ARTIST project has made a large and tangible contribution to the state of the art. Software systems are growing in complexity and expanding to have an ever greater role in daily life (e.g. IoT). As the hardware technology (e.g. Cloud and HPC) advances, systems are applied to ever larger problems and the ability to design, program and maintain them must keep up. One issue that is frequently neglected is that system retirement. Software cannot be eternal - patching and add-ons can only extend the lifetime to a limited extent. Ultimately the legacy applications must be retired and replaced, or modernised. This is a historical, current and future problem. The ARTIST project researched the feasibility of using MDE techniques to manage the modernisation and reduce the time and cost of doing so through automated features and reusable artefacts.

This research and its results are backed up by the scientific community in over 40 articles and journals published in high impact peer-reviewed conferences (e.g. MODELS, CSMR), keynote speeches given by members of the project (e.g. in MESOCA and MODELS) and workshops organized to present the project approach and results (e.g. Industrial Focus Groups, SummerSOC, Cloudscape). All assets of the ARTIST value chain have been presented in such scientific dissemination activities and validated by the community due to its novelty and high research interestThe project tested existing concepts in an industrial setting, developed new concepts and gained significant experience in the limits and bottlenecks of applying MDE techniques to this problem. This research will go forward and as MDE is applied to the development of modern systems and the ARTIST approach to modernisation of further legacy projects, the knowledge gained will be used to further reduce and optimise the process. The foundations established by ambitious projects such as ARTIST are pivotal to the future because what is pioneered today becomes the standard of the future. The issue of legacy software cannot be ignored in a digital economy and a digital society otherwise the systems they are built upon become the limiting factor of their growth.

In addition the project partners are showing a strong impact at individual level. The industrial partners expect returns on the investment through various channels. Firstly several partners see ARTIST contributing to existing modernisation and modelling solutions. This ranges from adding to the toolbox used to optimise and harmonise entire application portfolios (where modernisation is used in about 10% of applications), to specific additions to software modelling solutions. Secondly the specific to-cloud modernisation process can be used as part of cloud offering of providers. It is a unique selling point to not only migrate to the cloud but also to optimise for the cloud. Thirdly the open source results and the ARTIST Club (see below) provide ample opportunities for consultancy services around the results. Fourthly there is potential for commercialisation of specific components outside of the end-to-end ARTIST solution, and plans for at least one spin-off are underway. Finally the partners with use cases have shown quantifiable benefits in their modernised applications and are considering applying the same techniques to other parts of their portfolio.

Academic partners also see a healthy return from the project participation. Partners report strong benefits in terms of the positioning of both the research field and their organisations within the international scientific community. Teaching has been improved and both undergraduate and postgraduate courses have been updated to reflect the state of the art. The research departments have been able to expand both in terms of capacity, but also the depth and breadth of the research conducted. Carrying out the research, its dissemination and related project activities such as community events, as well as the nature of collaborative research in itself has led to many of the project participants striking up bilateral research, consultancy, teaching and knowledge-sharing agreements with partners internal and external to the consortium. These relationships surpass both the temporal and thematic boundaries of the ARTIST project.

The results have been released in their majority, as open source results and contributed to multiple communities, including OW2, Eclipse and MoDisco. As these results are maintained, updated and expanded, further opportunities for academic and commercial exploitation will appear. In order to foster and incubate the identified and emerging exploitation and research opportunities of the ARTIST project, the partners have entered into a contractual agreement which governs a forum for developing and cross-fertilizing business opportunities and technology transfer, as well as governing and steering the evolution of the Open Source results according mutual interest, sharing development, maintenance and promotional costs. This is called the ARTIST Club. The Club is open to third party participation and expects to lead to the creation of end-to-end commercial modernisation solutions based on ARTIST as well as the increased efficiency of the process. Interested parties can seek further information at the below URL.