doc/org.eclipse.epsilon.book/Conclusions.tex - epsilon/org.eclipse.epsilon - Git at Google

 \chapter{Conclusions and Further Work}
 \label{chp:Conclusions}

 This thesis addressed the following issues:

 \begin{itemize}
 	\item A Model Driven Engineering process typically involves a number of different model-related tasks such as model-to-model transformation, model comparison, model merging, model-to-text transformation, model validation and in-place model transformation.
 	\item Many different modelling languages/technologies may be used to capture models of interest in the context of the same Model Driven Engineering process.
 	\item Each model management task demonstrates specific characteristics and requirements which are typically best addressed by task-specific languages (as opposed to a general-purpose language that fits all the tasks).
 	\item To achieve usability and reuse, the different task-specific languages that are used in the context of the same process should be consistent with each other.
 	\item To enable integration and to manage complexity, it is essential that individual tasks can be seamlessly combined into complex workflows.
 \end{itemize}

 These issues were studied with respect to the following hypothesis, originally stated in Section \ref{sec:Analysis.Hypothesis}:

 \textit{Despite their individual requirements and characteristics, a wide range of task-specific modelling languages share a significant number of common features, and therefore, instead of developing each language separately, it is beneficial in terms of reuse, uniformity and interoperability to develop them atop a platform that provides a reusable set of commonly required features.}\\

 The objectives of the thesis were:

 \begin{enumerate}
 	\item To develop a platform atop which uniform, interoperable and reusable languages can be developed.
 	\item To use the platform to develop task-specific languages that address the, now unsupported, tasks of inter-model consistency checking, model comparison, model merging and in-place model transformation.
 	\item To use the platform to develop uniform task-specific languages for tasks that are already supported by existing languages (e.g. model-to-model transformation, model validation).
 	\item To develop an orchestration and coordination framework that enables composition of individual model management tasks implemented using languages of the platform into coherent workflows.
 \end{enumerate}

 This chapter summarizes the conclusions and findings of the research that was performed in order to assess the validity of this hypothesis. The rest of the chapter is organized as follows. Section \ref{sec:ReviewFindings} presents the findings of the background and literature review. Section \ref{sec:SolutionFindings} summarizes the contributions of the proposed solution and the findings obtained during the life-cycle of the prototype implementation. Finally, Section \ref{sec:Conclusions.FurtherWork} provides directions to further work both in the scope of the proposed solution and in a broader context.

 \section{Review Findings}
 \label{sec:ReviewFindings}

 In Chapter \ref{chp:LiteratureReview} a review of the background and existing work in the field of model management was performed. During the review, it was identified that a Model Driven Engineering process can involve a number of distinct model management tasks. A non-exhaustive list of the most commonly performed tasks follows:

 \begin{itemize}
 	\item Model-to-model Transformation
 	\item In-place model Transformation
 	\item Model Comparison
 	\item Model Merging
 	\item Model-to-text Transformation
 	\item Model Validation
 \end{itemize}

 The next step involved a review of existing mechanisms, tools and languages, that have been proposed for automating individual model management tasks. Through the review it was observed that each task demonstrates unique characteristics and requirements for which task-specific languages are better suited than general-purpose languages.

 In the sequel, a survey of existing task-specific model management languages was performed. Through this survey, a number of languages that support tasks such as model validation, model-to-model transformation and model-to-text transformation were identified. By contrast, no task-specific languages were identified for tasks such as interactive in-place model transformation, model comparison and merging.

 Another finding of the survey was that existing task-specific model management languages have been predominantly developed in isolation. Three particular shortcomings of this trend were observed:

 \begin{itemize}
 	\item Significant duplication exist between different languages.
 		\subitem Most typically re-implement a subset of OCL for model navigation and querying.
 		\subitem Each language re-implements technology-specific model-access features.
 	\item Languages for different tasks are inconsistent with each other and therefore prohibit reuse.
 		\subitem The subset of OCL they use is not consistent across different languages.
 		\subitem Commonly needed constructs, which are however not provided by OCL, (e.g. model modification constructs) are diversely implemented in different languages.
 	\item The inherent inconsistency also renders combining individual tasks implemented using different model management languages into complex workflows particularly challenging.
 \end{itemize}

 The yet unexploited potentials for reuse and uniformity identified during the field review were summarized in Chapter \ref{chp:Analysis} and the research hypothesis was stated.

 \section{Proposed Solution and Prototype Findings}
 \label{sec:SolutionFindings}

 In Chapter \ref{chp:Architecture} a high-level architectural plan of a platform of integrated task-specific languages for model management was outlined. The proposed platform contains five distinct layers which were further elaborated in Chapters \ref{chp:Infrastructure}, \ref{chp:TaskSpecificLanguages}, \ref{chp:Workflow} and \ref{chp:ReferenceImplementation}. The following sections summarize the intent of each layer and its contribution to the overall solution.

 \subsection{Model Connectivity Layer}

 Regardless of their task-specific characteristics, all model management languages need to access the contents of the models they operate on. To reduce coupling between specific model management technologies and model management languages, an abstraction layer (Model Connectivity Layer) layer was proposed in Section \ref{sec:Architecture.EMC} and elaborated in Section \ref{sec:Design.EMC}. The aim of this layer was to offer uniform model access services such as the retrieving all instances of a given type, checking for ownership, retrieving and setting the values of model element properties, and instantiating and managing transactions.

 \subsection{Common Navigation and Modification Language}

 Similarly, despite their differences and task-specific requirements, all model management languages include a mechanism for navigating, querying and (in most cases) modifying models. In existing languages, a custom subset of OCL has been traditionally re-implemented for this purpose, thus leading to the interoperability and uniformity issues discussed above. To overcome this issue, a feature-rich reusable OCL-based core language (the Epsilon Object Language) that offers features such as first-order logic expressions, model querying, navigation and modification, user-interaction was proposed in Section \ref{sec:Architecture.EOL} and further elaborated in Section \ref{sec:Design.EOL}.

 \subsection{Task-Specific Languages}

 A number of task-specific languages built on the infrastructure discussed above were also proposed in Section \ref{sec:Architecture.TaskSpecificLanguages} and were individually discussed in detail in Sections \ref{sec:ECL} - \ref{sec:EML}. By building on this common infrastructure, all task-specific languages inherit a number of features such as the ability to manage an arbitrary number of models of diverse metamodels and modelling technologies simultaneously, to interact with the user at runtime, to use native objects for delegating computationally expensive and otherwise out-of-scope tasks to the underlying platform. The following paragraphs provide a short summary of each task-specific language.

 \subsubsection{Epsilon Comparison Language (ECL)} ECL, discussed in detail in Section \ref{sec:ECL}, is a rule-based hybrid language for establishing correspondences between elements of an arbitrary number of input models. Similarly to ETL, ECL features rule and module-level inheritances as well as advanced concepts such as \emph{lazy}, \emph{abstract} and \emph{greedy} comparison rules.

 \subsubsection{Epsilon Validation Language (EVL)} EVL, discussed in detail in Section \ref{sec:EVL}, is a language that targets the task of model validation. EVL provides a number of novel features such as inter-model inconsistency detection, inconsistency repairing facilities, constraint dependency management and separation between critical and non-critical constraints.

 \subsubsection{Epsilon Transformation Language (ETL)} ETL, discussed in detail in Section \ref{sec:ETL}, is a rule-based hybrid model transformation language that can be used to transform an arbitrary number of source models into a number of target models. ETL features rule and module-level inheritance as well as advanced concepts such as \emph{lazy}, \emph{abstract} and \emph{greedy} transformation rules.

 \subsubsection{Epsilon Wizard Language (EWL)} EWL, discussed in detail in Section \ref{sec:EWL}, is a hybrid language for performing user-driven in-place model transformations such as model element creation or refactoring.

 \subsubsection{Epsilon Merging Language (EML)} EML, discussed in detail in Section \ref{sec:EML}, is a rule-based hybrid language for merging an arbitrary number of models based on identified correspondences (calculated using ECL or otherwise).\\\\

 Three task-specific languages have been proposed in this work for tasks that were previously unsupported (model comparison, merging and in-place transformation). Also, a model validation language (EVL) that improves the level of support for model validation in comparison to OCL by providing features such as inter-model consistency checking and automated inconsistency resolution mechanisms has been proposed. Finally, a model-to-model transformation language (ETL) that is of similar capabilities to the state-of-the-art model transformation languages has been proposed.

 Apart from the benefits of uniformity, consistency and interoperability, the layered architecture of Epsilon demonstrated another significant benefit. More specifically, due to the layered nature of the platform, features added to the core language (EOL) were immediately available from within the context of task-specific languages. For example, when user interaction features were added to EOL, all task-specific model management languages were instantly converted into interactive as it has been shown in Sections \ref{sec:InteractiveModelComparison} and \ref{sec:InteractiveModelTransformation}. A similar case was when support for accessing the underlying platform using native objects was added to EOL. This immediately made it possible to implement more sophisticated string comparison algorithms in ECL (as discussed in Section  \ref{sec:FuzzyComparison}).

 \subsection{Orchestration Workflow Layer}
 To coordinate the execution of model management tasks implemented using different model management languages, a workflow mechanism was proposed in Section \ref{sec:Architecture.Workflow} and elaborated in Chapter \ref{chp:Workflow}. The workflow provides facilities that enable seamless integration of individual model management tasks implemented using task-specific model management languages. The most important features of the workflow include a common model repository that is accessible by all the tasks participating in a workflow, a variable sharing mechanism that enables runtime communication between different tasks and the inherent ability - by building atop ANT - to integrate seamlessly with non-MDE tasks.

 \subsection{Development Tools Layer}
 To enable users to compose and execute Epsilon programs, Eclipse-based development tools have been constructed as part of the reference implementation of the platform. The Epsilon development tools, discussed in Section \ref{sec:Implementation.DevelopmentTools} include editors, outline viewers, launch configurations and delegates and an interactive console.

 \section{Evaluation Results}

 In Chapter \ref{chp:Evaluation}, the validity of the proposed hypothesis presented in Section \ref{sec:Analysis.Hypothesis} was confirmed. Evaluation was performed by demonstrating the practicality of the proposed platform through an externally defined case study and by assessing the fulfilment of the main objectives stated in Section \ref{sec:Analysis.Hypothesis}.

 In Section \ref{sec:Evaluation.Impact}, the impact of the proposed approach in the MDE community was assessed in terms of publicity, related publications and internal and external uses of Epsilon.

 In Section \ref{sec:Evaluation.Reuse}, the reuse achieved by the layered nature of the architecture was measured in terms of lines of code and the results demonstrated that significant amount of reuse (80\%) accross the execution engines and development tools of task-specific model management languages.

 \section{Further Work}
 \label{sec:Conclusions.FurtherWork}

 Several directions to further work have been identified as a result of this work. One direction is to investigate the need for additional model management tasks which can benefit from a task-specific language. Potential candidates in this category are model simulation and model synchronization.

 In terms of the Epsilon prototype, as discussed in Section \ref{sec:Evaluation.Limitations}, its design and implementation have been driven predominantly by modifiability and extensibility. However, this design decision has affected performance significantly. Thus, to enable large-scale industrial use, a direction for further work is to rework the tool-support with performance and scalability as primary concerns. To this end, compilers should be used instead of interpreters to delegate computationally expensive operations such as type and variable resolution to the compile-time -  instead of the runtime at which they are performed in the current implementation.

 Another interesting issue is to provide support in Epsilon for additional upcoming modelling technologies such as the Microsoft Domain Specific Languages Toolkit \cite{MSDSL}.

 This work also raises issues to be investigated in a broader context. Through this work it has been shown that an integrated family of programming languages can solve a wide range of problems by providing customized support to the requirements of each problem without however sacrificing much-desired qualities such as reuse, uniformity and interoperability. It would be of interest to investigate the usefulness of a similar approach to non-model-based software development with a family of inherently reusable and interoperable languages which address different software development tasks (e.g. data persistence and management, object management, presentation and deployment).
	\chapter{Conclusions and Further Work}
	\label{chp:Conclusions}

	This thesis addressed the following issues:

	\begin{itemize}
	\item A Model Driven Engineering process typically involves a number of different model-related tasks such as model-to-model transformation, model comparison, model merging, model-to-text transformation, model validation and in-place model transformation.
	\item Many different modelling languages/technologies may be used to capture models of interest in the context of the same Model Driven Engineering process.
	\item Each model management task demonstrates specific characteristics and requirements which are typically best addressed by task-specific languages (as opposed to a general-purpose language that fits all the tasks).
	\item To achieve usability and reuse, the different task-specific languages that are used in the context of the same process should be consistent with each other.
	\item To enable integration and to manage complexity, it is essential that individual tasks can be seamlessly combined into complex workflows.
	\end{itemize}

	These issues were studied with respect to the following hypothesis, originally stated in Section \ref{sec:Analysis.Hypothesis}:

	\textit{Despite their individual requirements and characteristics, a wide range of task-specific modelling languages share a significant number of common features, and therefore, instead of developing each language separately, it is beneficial in terms of reuse, uniformity and interoperability to develop them atop a platform that provides a reusable set of commonly required features.}\\

	The objectives of the thesis were:

	\begin{enumerate}
	\item To develop a platform atop which uniform, interoperable and reusable languages can be developed.
	\item To use the platform to develop task-specific languages that address the, now unsupported, tasks of inter-model consistency checking, model comparison, model merging and in-place model transformation.
	\item To use the platform to develop uniform task-specific languages for tasks that are already supported by existing languages (e.g. model-to-model transformation, model validation).
	\item To develop an orchestration and coordination framework that enables composition of individual model management tasks implemented using languages of the platform into coherent workflows.
	\end{enumerate}

	This chapter summarizes the conclusions and findings of the research that was performed in order to assess the validity of this hypothesis. The rest of the chapter is organized as follows. Section \ref{sec:ReviewFindings} presents the findings of the background and literature review. Section \ref{sec:SolutionFindings} summarizes the contributions of the proposed solution and the findings obtained during the life-cycle of the prototype implementation. Finally, Section \ref{sec:Conclusions.FurtherWork} provides directions to further work both in the scope of the proposed solution and in a broader context.

	\section{Review Findings}
	\label{sec:ReviewFindings}

	In Chapter \ref{chp:LiteratureReview} a review of the background and existing work in the field of model management was performed. During the review, it was identified that a Model Driven Engineering process can involve a number of distinct model management tasks. A non-exhaustive list of the most commonly performed tasks follows:

	\begin{itemize}
	\item Model-to-model Transformation
	\item In-place model Transformation
	\item Model Comparison
	\item Model Merging
	\item Model-to-text Transformation
	\item Model Validation
	\end{itemize}

	The next step involved a review of existing mechanisms, tools and languages, that have been proposed for automating individual model management tasks. Through the review it was observed that each task demonstrates unique characteristics and requirements for which task-specific languages are better suited than general-purpose languages.

	In the sequel, a survey of existing task-specific model management languages was performed. Through this survey, a number of languages that support tasks such as model validation, model-to-model transformation and model-to-text transformation were identified. By contrast, no task-specific languages were identified for tasks such as interactive in-place model transformation, model comparison and merging.

	Another finding of the survey was that existing task-specific model management languages have been predominantly developed in isolation. Three particular shortcomings of this trend were observed:

	\begin{itemize}
	\item Significant duplication exist between different languages.
	\subitem Most typically re-implement a subset of OCL for model navigation and querying.
	\subitem Each language re-implements technology-specific model-access features.
	\item Languages for different tasks are inconsistent with each other and therefore prohibit reuse.
	\subitem The subset of OCL they use is not consistent across different languages.
	\subitem Commonly needed constructs, which are however not provided by OCL, (e.g. model modification constructs) are diversely implemented in different languages.
	\item The inherent inconsistency also renders combining individual tasks implemented using different model management languages into complex workflows particularly challenging.
	\end{itemize}

	The yet unexploited potentials for reuse and uniformity identified during the field review were summarized in Chapter \ref{chp:Analysis} and the research hypothesis was stated.

	\section{Proposed Solution and Prototype Findings}
	\label{sec:SolutionFindings}

	In Chapter \ref{chp:Architecture} a high-level architectural plan of a platform of integrated task-specific languages for model management was outlined. The proposed platform contains five distinct layers which were further elaborated in Chapters \ref{chp:Infrastructure}, \ref{chp:TaskSpecificLanguages}, \ref{chp:Workflow} and \ref{chp:ReferenceImplementation}. The following sections summarize the intent of each layer and its contribution to the overall solution.

	\subsection{Model Connectivity Layer}

	Regardless of their task-specific characteristics, all model management languages need to access the contents of the models they operate on. To reduce coupling between specific model management technologies and model management languages, an abstraction layer (Model Connectivity Layer) layer was proposed in Section \ref{sec:Architecture.EMC} and elaborated in Section \ref{sec:Design.EMC}. The aim of this layer was to offer uniform model access services such as the retrieving all instances of a given type, checking for ownership, retrieving and setting the values of model element properties, and instantiating and managing transactions.

	\subsection{Common Navigation and Modification Language}

	Similarly, despite their differences and task-specific requirements, all model management languages include a mechanism for navigating, querying and (in most cases) modifying models. In existing languages, a custom subset of OCL has been traditionally re-implemented for this purpose, thus leading to the interoperability and uniformity issues discussed above. To overcome this issue, a feature-rich reusable OCL-based core language (the Epsilon Object Language) that offers features such as first-order logic expressions, model querying, navigation and modification, user-interaction was proposed in Section \ref{sec:Architecture.EOL} and further elaborated in Section \ref{sec:Design.EOL}.

	\subsection{Task-Specific Languages}

	A number of task-specific languages built on the infrastructure discussed above were also proposed in Section \ref{sec:Architecture.TaskSpecificLanguages} and were individually discussed in detail in Sections \ref{sec:ECL} - \ref{sec:EML}. By building on this common infrastructure, all task-specific languages inherit a number of features such as the ability to manage an arbitrary number of models of diverse metamodels and modelling technologies simultaneously, to interact with the user at runtime, to use native objects for delegating computationally expensive and otherwise out-of-scope tasks to the underlying platform. The following paragraphs provide a short summary of each task-specific language.

	\subsubsection{Epsilon Comparison Language (ECL)} ECL, discussed in detail in Section \ref{sec:ECL}, is a rule-based hybrid language for establishing correspondences between elements of an arbitrary number of input models. Similarly to ETL, ECL features rule and module-level inheritances as well as advanced concepts such as \emph{lazy}, \emph{abstract} and \emph{greedy} comparison rules.

	\subsubsection{Epsilon Validation Language (EVL)} EVL, discussed in detail in Section \ref{sec:EVL}, is a language that targets the task of model validation. EVL provides a number of novel features such as inter-model inconsistency detection, inconsistency repairing facilities, constraint dependency management and separation between critical and non-critical constraints.

	\subsubsection{Epsilon Transformation Language (ETL)} ETL, discussed in detail in Section \ref{sec:ETL}, is a rule-based hybrid model transformation language that can be used to transform an arbitrary number of source models into a number of target models. ETL features rule and module-level inheritance as well as advanced concepts such as \emph{lazy}, \emph{abstract} and \emph{greedy} transformation rules.

	\subsubsection{Epsilon Wizard Language (EWL)} EWL, discussed in detail in Section \ref{sec:EWL}, is a hybrid language for performing user-driven in-place model transformations such as model element creation or refactoring.

	\subsubsection{Epsilon Merging Language (EML)} EML, discussed in detail in Section \ref{sec:EML}, is a rule-based hybrid language for merging an arbitrary number of models based on identified correspondences (calculated using ECL or otherwise).\\\\

	Three task-specific languages have been proposed in this work for tasks that were previously unsupported (model comparison, merging and in-place transformation). Also, a model validation language (EVL) that improves the level of support for model validation in comparison to OCL by providing features such as inter-model consistency checking and automated inconsistency resolution mechanisms has been proposed. Finally, a model-to-model transformation language (ETL) that is of similar capabilities to the state-of-the-art model transformation languages has been proposed.

	Apart from the benefits of uniformity, consistency and interoperability, the layered architecture of Epsilon demonstrated another significant benefit. More specifically, due to the layered nature of the platform, features added to the core language (EOL) were immediately available from within the context of task-specific languages. For example, when user interaction features were added to EOL, all task-specific model management languages were instantly converted into interactive as it has been shown in Sections \ref{sec:InteractiveModelComparison} and \ref{sec:InteractiveModelTransformation}. A similar case was when support for accessing the underlying platform using native objects was added to EOL. This immediately made it possible to implement more sophisticated string comparison algorithms in ECL (as discussed in Section \ref{sec:FuzzyComparison}).

	\subsection{Orchestration Workflow Layer}
	To coordinate the execution of model management tasks implemented using different model management languages, a workflow mechanism was proposed in Section \ref{sec:Architecture.Workflow} and elaborated in Chapter \ref{chp:Workflow}. The workflow provides facilities that enable seamless integration of individual model management tasks implemented using task-specific model management languages. The most important features of the workflow include a common model repository that is accessible by all the tasks participating in a workflow, a variable sharing mechanism that enables runtime communication between different tasks and the inherent ability - by building atop ANT - to integrate seamlessly with non-MDE tasks.

	\subsection{Development Tools Layer}
	To enable users to compose and execute Epsilon programs, Eclipse-based development tools have been constructed as part of the reference implementation of the platform. The Epsilon development tools, discussed in Section \ref{sec:Implementation.DevelopmentTools} include editors, outline viewers, launch configurations and delegates and an interactive console.

	\section{Evaluation Results}

	In Chapter \ref{chp:Evaluation}, the validity of the proposed hypothesis presented in Section \ref{sec:Analysis.Hypothesis} was confirmed. Evaluation was performed by demonstrating the practicality of the proposed platform through an externally defined case study and by assessing the fulfilment of the main objectives stated in Section \ref{sec:Analysis.Hypothesis}.

	In Section \ref{sec:Evaluation.Impact}, the impact of the proposed approach in the MDE community was assessed in terms of publicity, related publications and internal and external uses of Epsilon.

	In Section \ref{sec:Evaluation.Reuse}, the reuse achieved by the layered nature of the architecture was measured in terms of lines of code and the results demonstrated that significant amount of reuse (80\%) accross the execution engines and development tools of task-specific model management languages.

	\section{Further Work}
	\label{sec:Conclusions.FurtherWork}

	Several directions to further work have been identified as a result of this work. One direction is to investigate the need for additional model management tasks which can benefit from a task-specific language. Potential candidates in this category are model simulation and model synchronization.

	In terms of the Epsilon prototype, as discussed in Section \ref{sec:Evaluation.Limitations}, its design and implementation have been driven predominantly by modifiability and extensibility. However, this design decision has affected performance significantly. Thus, to enable large-scale industrial use, a direction for further work is to rework the tool-support with performance and scalability as primary concerns. To this end, compilers should be used instead of interpreters to delegate computationally expensive operations such as type and variable resolution to the compile-time - instead of the runtime at which they are performed in the current implementation.

	Another interesting issue is to provide support in Epsilon for additional upcoming modelling technologies such as the Microsoft Domain Specific Languages Toolkit \cite{MSDSL}.

	This work also raises issues to be investigated in a broader context. Through this work it has been shown that an integrated family of programming languages can solve a wide range of problems by providing customized support to the requirements of each problem without however sacrificing much-desired qualities such as reuse, uniformity and interoperability. It would be of interest to investigate the usefulness of a similar approach to non-model-based software development with a family of inherently reusable and interoperable languages which address different software development tasks (e.g. data persistence and management, object management, presentation and deployment).