• No se han encontrado resultados

CAPÍTULO 1.FUNDAMENTACIÓN TEÓRICA

1.9 IDEs para C Sharp(C#)

Eclipse is a “community of tools, projects and collaborative working groups” [95]. It consists of several projects in the context of software development, which rely on the Eclipse framework. This framework provides a rudimentary core application that can be extended by plugins according to the Hollywood principle “Don’t call us, we’ll call you” [61]. A popular set of tools for the software development with Java is provided in the Eclipse Integrated Development Environment (IDE) for Java Developers [94].

The Eclipse Modeling Framework (EMF) is a project extending the Eclipse platform with modeling capabilities [90]. It provides concepts and tools for defining models based on a meta-metamodel called Ecore, which is further explained in subsection 2.3.1. The purpose of EMF is the unification and integration of models into the software development process as primary artifacts [90, p. 15].

EMF provides graphical tree-based editors for creating and modifying metamodels based on Ecore. Based on these metamodels, Eclipse plugins that provide unified graphical tree-based editors for the instances of these metamodels can be generated. Furthermore, EMF provides a code generation for Ecore based metamodels. This code generation transforms the metamodels into Java code, which represents the metaclasses as Java classes and the relations between metaclasses as object references. The generic model element interface, which all available and generated model elements implement, is theEObject. Certainly, the code generation is more elaborate and, for example, hides the model instantiation through a factory implementation for a better exchangeability of the metamodel realization, but those aspects are not relevant for this thesis.

Several tools have been developed for or based on EMF and especially the contained Ecore meta-metamodel. They cover different aspects of model-driven software develop-ment, such as the comparison and validation of models. Several model transformation languages are implemented for EMF, for example, QVT [72], ATL [52], and the more

Java-2.3 The Eclipse Modeling Framework aligned Xtend, which is explained in subsection 2.3.3. The development of DSLs and textual editors for them can be conducted with Xtext, which is introduced in subsection 2.3.2.

2.3.1 Essential Meta-Object Facility and Ecore

The Essential Meta Object Facility (EMOF) is a self-describing meta-metamodel and is part of the MOF [73], defined by the OMG. It is contained within the Complete MOF (CMOF), which provides the full capability of the MOF standard. EMOF is “designed to match the capabilities of object oriented programming languages” [73, p. 3] and thus provides a reduced meta-metamodel in contrast to CMOF.

The EMOF meta-metamodel defines types, properties and operations. Types can in turn be data types or classes, properties belong to classes and reference other classes or data types, and operations belong to classes. Obviously, the EMOF elements are aligned with object-oriented programming languages, which is due to the intended usage of EMOF in that context.

Ecore is the meta-metamodel that ships with EMF. It is conform to EMOF, which means that Ecore-based models can be converted into EMOF-based models without information loss. One relevant difference between EMOF and Ecore is the distinction of properties into attributes and references in Ecore. In contrast to EMOF, Ecore has a concrete implementa-tion in EMF and can be seen as a reference implementaimplementa-tion of EMOF.

The MOF, and as a result also EMOF, use the XML Metadata Interchange (XMI) for-mat [76] for persisting model data. XMI specifies a generic, XML-based forfor-mat for persist-ing and interchangpersist-ing models. EMF uses XMI for persistpersist-ing Ecore-based models as well, which allows all EMF tools to rely on this persistence format.

2.3.2 Textual Domain-Specific Languages with Xtext

Xtext is an EMF-based framework that supports the implementation of textual DSLs [24]

and is developed by the itemis AG. The specification of a DSL in Xtext consists of three parts. The first part is the specification of the abstract and concrete syntax of the language in a special editor. Secondly, Xtext provides different extension points, based on the abstract syntax, for specifying the static semantics of the language. The third part is the specification of a transformation of the abstract syntax into another model with defined semantics for determining the dynamic semantics of the language.

The Xtext framework provides an editor in which a concrete textual syntax for the language can be specified in an EBNF-like notation. From this specification, it automatically generates an EMF-based metamodel that represents the abstract syntax of the language, a parser that extracts the abstract syntax from a textual model representation according to the specified concrete syntax, and an editor with syntax highlighting, code completion, error checking and further features improving its usability. The editor also allows to specify some static semantics of the language, for example, through references to other elements of the language.

From the syntax specification of the language, an Ecore-based metamodel and several classes for defining the validation, scoping, linking and other semantics are generated.

These classes extend predefined implementations for the different aspects that can be

reused. As an example, namespace-aware scoping implementations are provided and ease the access management to variables based on namespaces, like in the Java programming language.

To define the dynamic semantics of the specified language, Xtext provides the possibility to implement a generator that takes a model according to the specified language and transforms it into another model. The mechanism aims to transform the model into textual program code that can be executed.

To ease the code generation for languages that are similar to Java code, Xtext also provides a mechanism to convert the model into a Java code model instead of a textual code representation. The transformation is automatically performed by Xtext and only requires the specification of mappings between the model elements and Java language constructs. This also allows to reuse scoping and validation mechanisms of the Java language. Mapping a language construct to a method in the Java code model automatically provides access to the defined method parameters and to fields of the containing class, and requires the return type to fit to the specified method return type.

All developed artifacts are automatically integrated by Xtext to a complete language setup, which performs the validation and code generation for given models and also the parsing for textual representations. Furthermore, Xtext generates an editor for the language, which evaluates scoping and validation rules while editing the document and performs the code generation whenever the document is saved. The language developer can implement further extensions for this editor, such as an outline specification that represents the document structure.

DSLs that are defined with Xtext can be reused in other Xtext-based DSLs because Xtext provides a mechanism for extending and using already existing languages. One language that is shipped with Xtext and is predestined for being reused is Xbase. Xbase is an expression language, related to Java, and thus can be used within a DSL for allowing the definition of imperative code without having to implement a language with correct syntax, validation and scoping. In the following, the Xbase language is explained in more detail.

2.3.3 Reusable Programming Languages Xbase and Xtend

Xbase is an expression language that is shipped with Xtext [25]. It is tightly integrated with the Java type system and can be inherited by Xtext-based DSLs to provide Java-like expressions within a DSL. Xbase provides a parser for generating a model for textual nota-tions in that language, validation specificanota-tions for the expression language and a compiler that generates Java code for given Xbase expressions. The editors that are generated for Xtext languages also inherit the scoping specification from the Xbase language definition, which provides a Java-like variable scoping within Xbase expressions.

In addition to the concepts of Java, Xbase also provides several extensions. A type inference mechanism allows to declare a variable asvarto make it changeable, or asval if it shall be final, omitting the concrete variable type. Operator overloading allows to redefine operators for specified classes. A method can be declared as extension, which attaches the method to the type of the first parameter of the method. Finally, a dynamic dispatching mechanism allows to define overloaded methods that are selected by the

Documento similar