Domain-Specific Modeling Languages to improve framework instantiation

The Journal of Systems and Software 86 (2013) 3123–3139

Contents lists available at ScienceDirect

The Journal of Systems and Software journal homepage: www.elsevier.com/locate/jss

Domain-Specific Modeling Languages to improve framework instantiation Matheus C. Viana ∗ , Rosângela A.D. Penteado, Antônio F. do Prado Computing Department, Federal University of São Carlos, Rd. Washington Luis, Km 235, 13565-905 São Carlos, SP, Brazil

a r t i c l e

i n f o

Article history: Received 11 January 2013 Received in revised form 11 June 2013 Accepted 11 July 2013 Available online 20 July 2013 Keywords: Framework Domain-Specific Modeling Language Reuse

a b s t r a c t Frameworks are reusable software composed of concrete and abstract classes that implement the functionality of a domain. Applications reuse frameworks to enhance quality and development efficiency. However, frameworks are hard to learn and reuse. Application developers must understand the complex class hierarchy of the framework to instantiate it properly. In this paper, we present an approach to build a Domain-Specific Modeling Language (DSML) of a framework and use it to facilitate framework reuse during application development. The DSML of a framework is built by identifying the features of this framework and the information required to instantiate them. Application generators transform models created with the DSML into application code, hiding framework complexities. In this paper, we illustrate the use of our approach in a framework for the domain of business resource transactions and a experiment that evaluated the efficiency obtained with our approach. © 2013 Elsevier Inc. All rights reserved.

1. Introduction Developers are continually trying to find more efficient software development methods to follow market dynamics. In order to achieve this, one practice that has been commonly applied is reuse, because it reduces time spent in development process, since software is not developed from scratch, and increases software quality, since reusable artifacts were previously tested (Shiva and Shala, 2007). There are different levels of reuse. Copy and paste is the simplest one. Programming languages provide several mechanisms for reusing code units. Yet there are more sophisticated forms of reuse, such as frameworks, that provide reuse of code, design and experience (Frakes and Kang, 2005). Frameworks are reusable software composed of concrete and abstract classes that implement the functionality of a domain (Fayad and Schmidt, 1997; Fayad et al., 1999; Fayad and Johnson, 1999). Applications reuse the design and the implementation of a framework, adding their specific characteristics to its functionality. The process of application development reusing a framework is known as framework instantiation (Johnson, 1997). Some studies have highlighted the advantages obtained from framework reuse in application development (Srinivasan, 1999; Abi-Antoun, 2007; Durelli et al., 2010; Lopes et al., 2005).

∗ Corresponding author. Tel.: +55 1633518621. E-mail addresses: matheus [email protected], [email protected] (M.C. Viana), [email protected] (R.A.D. Penteado), [email protected] (A.F. do Prado). 0164-1212/$ – see front matter © 2013 Elsevier Inc. All rights reserved. http://dx.doi.org/10.1016/j.jss.2013.07.030

However, these studies also affirm that framework reuse is not easy, because it demands detailed knowledge about the domain, classes, interface, architecture and programming language of a framework. Moreover, framework complexity is proportional to its domain amplitude and variability. Even developers who are conversant about a framework can make mistakes while reusing it, developing applications that do not work properly and need maintenance. Consequently, the improvement in productivity and quality, expected due to framework reuse, is not achieved (Kirk et al., 2007). Antkiewicz et al. (2009) said that some solutions have been proposed to facilitate framework instantiation, such as manuals, tutorials, pattern languages, cookbooks and sample applications that were developed with the framework. However, these authors also remarked that such solutions are passive, because they act only as a guide to help developers to reuse a framework. The effective task of reusing framework classes is still performed by the developer who implements the application code. The number of defects inserted into application code due to incorrect framework reuse can be strongly reduced by using an application generator wizard (Braga and Masiero, 2003). The wizard takes the responsibility from the application developer to instantiate the framework. Consequently, the wizard reduces the number of defects inserted in application code and the time spent in the development process. However, application modeling is still necessary, even when a wizard is used, because developers have to fill up the application specifications twice, firstly in the model and again in the wizard forms. The main reason for this is that wizard forms are less intuitive than graphical models and they do not provide a visualization of the application structure.

3124

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

To provide an easier and more efficient method for framework instantiation, we propose an approach that guides the building of a Domain-Specific Modeling Language (DSML) of a framework and the use of this DSML to model and generate applications. To build a DSML, framework features are identified by analyzing its documentation, its code and the code of sample applications reusing it. Then, each feature is analyzed in order to identify what elements should be included in the DSML syntax and application generator. Application models created with this DSML are formed by graphical elements that represent framework features, which are more intuitive than those found in general purpose modeling languages and wizards. The implementation of application code reusing framework classes is performed by the DSML application generator. Moreover, DSMLs can contain constrictions and validation mechanisms that reduce the possibility of developers to insert incorrect and incoherent information in the application models, generating application code with defects. In this work, we used the Graphical Modeling Framework (GMF) (Gronback, 2009) to build the DSML syntax and Java Emitter Templates (JET) (The Eclipse Foundation, 2012) to implement the DSML application generator. However, our approach can be applied using other tools, e.g., Generic Modeling Environment (GME) (Institute for Software Integrated Systems, 2012) for building DSMLs and Acceleo (The Eclipse Foundation, 2012) for implementing application generators. The remainder of this paper is organized as follows: background concepts applied in our approach are discussed in Section 2; our approach for building and using DSML of frameworks is presented in Section 3; an example in which our approach is applied to build a DSML of a framework and use it to develop an application is presented in Section 5; some related works are discussed in Section 6; and concluding remarks and future works are commented in Section 7.

2. Background The proposed approach aims to build DSMLs to facilitate framework instantiation. Thus, concepts related to these two subjects are presented in this section.

2.2. Domain-Specific Model Languages In SPL, a Domain-Specific Modeling Language (DSML) can be more useful to model applications than general purpose modeling languages, such as UML. Since DSML elements represent features of the SPL domain, instead of generic logical units, the distance between the problem and the implementation of a solution is reduced. Moreover, since the basic functionality of the domain is known, it is easier to generate code from application models created with a DSML (France and Rumpe, 2007; Schmidt, 2006; Mellor et al., 2003). DSMLs are composed of two parts: abstract syntax and concrete syntax. Elements, relationships and rules of the DSML are defined in the abstract syntax. Concrete syntax specifies the DSML visual notation, such as graphical, textual, table-view, tree-view, etc. (Cuadrado and Molina, 2009). Usually, DSML tools provide metamodels for the definition of these syntaxes. Application generators can be constructed from templates that define application code structure (Gronback, 2009). Templates are implemented by using a transformation language. They are divided into: fixed parts, that remain unchanged regardless of the outcome application; and variant parts, consisting of commands that originate code according to information extracted from application models. In XML-based transformation languages, such as Java Emitter Templates (JET) (The Eclipse Foundation, 2012), the fixed parts consist of texts and the variant parts are tags defined by the languages. 3. Proposed approach Our approach is composed of two phases, as shown in Fig. 1. Structured Analysis and Design Technique (SADT) (Marca and McGowan, 1988) notation is used in this paper to illustrate the proposed approach. In Fig. 1 it can be seen that the DSML Engineering phase has a framework (documentation and source code) as input. This phase is executed by using DSML metamodels to create the DSML and a transformation language to implement the application generator. The tools used in this phase constitutes its Integrated Development Environment (IDE). In the Application Engineering phase, applications are developed by using the DSML to create models based on their requirements and generating the application code by executing the application generator.

2.1. Frameworks 3.1. DSML Engineering Frameworks act like skeletons that can be instantiated into applications (Johnson, 1997). According to the way frameworks are reused, they can be classified as: white box, when they are reused by class specialization; black box, when they work like a set of components; and gray box, when they can be reused by the two previous ways (Fayad and Schmidt, 1997; Fayad et al., 1999; Fayad and Johnson, 1999). Basically, frameworks are composed of two parts: frozen spots, which implements the common functionality of framework domain; and hot spots, which can be instantiated according to the specifications of the desired application (Fayad and Schmidt, 1997; Abi-Antoun, 2007). What differs one application to another is the way the hotspots were configured (Srinivasan, 1999). Framework classes embody an abstract design to provide solutions for a domain of applications (Fayad and Schmidt, 1997; Fayad et al., 1999; Fayad and Johnson, 1999). Thus, frameworks are not intended to support the development of a specific application, but a set of applications that share common features. For that reason, frameworks are often used as core assets in Software Product Lines (SPL) (Weiss and Lai, 1999) or in the implementation of common non-functional requirements, such as data persistence.

In DSML engineering phase, framework features are analyzed to model and construct the DSML. A framework, including its documentation and source code, is the input for this phase. The five steps that compose this phase are shown in Fig. 2: (1) Feature Identification, (2) Feature Analysis, (3) DSML Modeling, (4) DSML Construction and (5) Generator Construction. Framework features are identified in the Feature Identification step. Then, the other steps are performed in iterative and incremental cycles, treating one feature per iteration. All steps of the DSML Engineering phase are described in the following sections. 3.1.1. Feature Identification In this step the available documentation and framework source code are analyzed, so that all framework features and their dependencies can be identified. Sample applications might be helpful as well. To assist this identification, our approach make some considerations: • A feature is an entity of the framework domain and it can be identified from a framework class which can be directly reused by

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

3125

Fig. 1. Phases of the proposed approach.

Fig. 2. The five steps of the DSML Engineering phase.

• • • •

applications, whether by specialization (white box) or composition (black box); The main class of a feature is the framework class which identifies this feature; The main class of a feature and its super classes are the related classes of this feature; When an application class reuses the main class of a feature, this application class implements the feature; Features can depend on other features to be implemented. Feature dependencies can be identified from relationships and operations that refer to classes related to other features.

A design level class model of a hypothetic (H) framework is shown in Fig. 3. The A class combines attributes and operations that are common to B and C. A was created only for code improvement and therefore it is not a feature of the H framework. However, B, C

and D are identified as features, because they are directly reused by the applications. The sequence in which features should be treated is defined according to the dependencies between them. This sequence can be cataloged in a list, such as in Table 1, using the H framework as example. In this list, the B feature has its main class as its unique related class and it has no dependencies; the C and D features depend on the B feature because one of their related classes, A, has

Table 1 List of the features identified in the H framework. Id

Feature

Related Classes

Dependencies

1 2 3

B D C

B D, A C, A

– 1 1, 2

3126

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

Fig. 3. Class model of the H framework.

a relationship with a class in the B feature; and the C feature also depends on the D feature because its main class has a relationship with the main class of D. Optionally, other documentations, such as feature models, can also be created to provide a visualization of the framework domain. However, the DSML metamodel created in DSML Modeling step provides this kind of visualization. Moreover, this kind of documentation might have been previously created if the framework was developed in the context of a SPL. 3.1.2. Feature Analysis All framework features and their dependencies were known in Feature Identification step. Now in Feature Analysis, each feature is analyzed in detail to identify what information is necessary for reusing its main class. To do so, the following questions should be answered: • What properties can application classes have? Names, attributes and operations are frequent answers to this question. • Does the feature in analysis have dependencies? • What information is required by the operations of the classes related to the feature in analysis that may be invoked/overridden in application classes? These questions can be answered by analyzing the source code of the framework or of applications that reuses the framework. For example, in the H framework, the A feature has the operation getBClass. Application classes which implement this feature must override this operation, because it is abstract. Since this operation must return the application class which implements the B feature, this information is necessary for reusing the A feature. Table 2 lists the H framework features and the information required by them to be implemented. For example, all application classes can have a name, attributes and operations, therefore, all features require this information. The C feature must know what application class implements the D feature, because the getDClass operation must be overridden to return this class. Identifying the information required for framework instantiation is not an easy task. While mandatory information, usually

required by abstract operations, are recognized by compiler or IDE editor, others may not be clear because they depend on optional or variant features. Moreover, framework code may not be accessible. Thus, some tips can be followed: 1. If framework code is accessible, start analyzing the feature main class. Check for abstract operations and find out their possible implementations. Check for operations that set feature properties and the parameters of these operations. 2. Check on framework code, documentation or sample applications for the kind of information that each operation necessary to instantiate the framework requires and returns. In addition, check if there is a specific sequence to invoke these operations. 3. Check, in different applications, for classes implementing the feature in analysis. Analyze attributes, operations and annotations in these classes considering different arrangements of the other features. Verify if classes implementing other features are referenced in the class implementing the feature in analysis. We also recommend to implement applications reusing the framework before starting DSML engineering. Besides the knowledge that it will provide to developers, these applications will work as sample applications to be analyzed during DSML Engineering. 3.1.3. DSML Modeling The abstract and concrete syntaxes of the DSML are modeled in this step. These syntaxes define how the DSML is used to create models and how the application generator can access the information in these models to generate application code. The abstract syntax contain elements that represent framework features and the information required by them. The metamodel (abstract syntax model) of the H framework DSML is shown in Fig. 4. The first five metaclasses are properties commonly used in all application models: (1) Application is the root element of the models created with the DSML; (2) Feature is the abstract super metaclass for all metaclasses that represent framework features; (3) Attribute represents the attributes of application classes; (4) Operation represents the operations of application classes; and (5) Parameter represents operations parameters. Finally, B, C and

Table 2 List of the H framework features, including the information required by them. Id

Feature

Related classes

Dependencies

Required information

0 1 2 3

All B D C

– B D, A C, A

– – B B, D

Name, attributes and operations – The class which implements B The classes which implement B and D

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

3127

Fig. 4. Metamodel of the H framework DSML.

D metaclasses correspond to the H framework features. The information required to implement these features is represented by the relationships between these metaclasses. The concrete syntax defines the visual notation of the application models created with the DSML. Modeling the concrete syntax depends on the modeling tool adopted. For example, the GMF (Gronback, 2009) uses three types of models to define the concrete syntax of DSMLs: gmfgraph, gmftool and gmfmap. The graphical notation of the DSML are defined in a gmfgraph file. For example, in Fig. 5, a feature is graphically represented by a

rectangle composed of other rectangles with labels for class names, attributes and operations. Relationships are represented by solid lines. The menu bar of the DSML is defined in a gmftool file. For example, the menu bar of the H framework DSML contains seven menu items that represent the association relationship, the common properties (attributes, operations and parameters) and the features B, C and D, as it can be seen in the gmftool file shown in Fig. 6. In a gmfmap file, the features and their relationships defined in the abstract syntax are combined with their correspondent

Fig. 5. Defining the components of the graphical notation of the H framework DSML.

Fig. 6. Creating the menu bar of the H framework DSML.

3128

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

Fig. 7. Combining elements of both syntaxes of the H framework DSML.

Fig. 8. The main template of the H framework application generator.

graphical components and menu items. In Fig. 7, there is an example of this file combining the features and relationships in Fig. 4 with the graphical components in Fig. 5 and the menu items in Fig. 6. In this file, each feature is represented by a Top Node Reference containing a Node Mapping. Node Mappings for attributes and operations are added to the features through Child Reference and Compartment Mapping. Similarly, a Node Mapping is included to represent operation parameters. Finally, Feature Labels are included to allow the visualization and the editing of names and types of features, attributes, operations and parameters. 3.1.4. DSML Construction DSML source code is generated from its models. For example, when GMF is used, DSML source code is generated as plug-ins for the Eclipse IDE from the metamodels described in Section 3.1.3. DSML tools often create a validation mechanism based on properties and relationships of elements defined in the abstract syntax. It is then possible to verify, among other things, that all mandatory features of the framework are included in an application model. 3.1.5. Generator Construction In this step DSML application generator is constructed by using templates to define the application code structure. Usually, there must be one template specific for each framework feature. In addition, there must be a main template to start code generation

and invoke feature templates as they are found in application models. The main template of the H framework application generator, implemented in Java Emitter Templates (JET), is illustrated in Fig. 8. In this template, there is a loop (lines 1–17) iterating over all elements in the application models, to identify the features they represent (lines 4, 8 and 12) and to invoke the templates specific for each one (lines 5, 9 and 13). A piece of the template for application classes that implement the D feature of the H framework is shown in Fig. 9. In line 1, there are fixed parts of this template composed of Java key words for class declaration. There also is a variable part composed of a JET tag c:get, which accesses the feature name defined in the application model to use it as class name. Lines 2–5 define a loop to generate application class attributes and lines 6–9 are the commands to override the operation getBClass. In addition to the templates for generating application classes, others can also be implemented for generating unity tests, database scripts, help pages, documentation, etc. 3.2. Application Engineering Application Engineering phase is illustrated in Fig. 10. This phase includes the following steps: (1) Application Modeling and (2) Application Construction.

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

3129

Fig. 9. A piece of the template that generates subclasses of the D class.

Fig. 10. Application Engineering phase.

3.2.1. Application Modeling In Application Modeling, the framework DSML developed in the DSML Engineering phase is used to create application models. Instead of generic classes, the elements of this DSML correspond to framework features, facilitating the association of these elements with the application requirements. An example of application model created with the H framework DSML is shown in Fig. 11. Stereotypes («B», «C» and «D») identify the framework features that were used in the application. In addition, the links between the elements correspond to the relationships in the DSML metamodel (Fig. 4). For example, the Dapp class identifies the class that represents the B feature through the link between Dapp and Bapp.

One of the advantages of DSMLs over general purpose modeling languages is the fact that a DSML has knowledge about its domain rules. As cited in Section 3.1.4, a validation mechanism can be used to verify the presence of mandatory features, invalid relationships, repeated attributes and operations, etc. 3.2.2. Application Construction In this step DSML application generator is executed to generate application code. Since DSML was developed based on a framework, the generated code reuses this framework. The code generated from the combination of the template in Fig. 9 with the model in Fig. 11 is shown in Fig. 12.

Fig. 11. Example of an application model created with the H framework DSML.

3130

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

applications, such as clothing stores, mechanical workshops and veterinary clinics. The steps of the GRENJ framework DSML Engineering are described in Sections 4.1.1–4.1.5.

Fig. 12. Generated code for the Dapp class.

Tests can also be applied to verify that the application code works as expected. If templates were implemented to generate these tests, they can be executed in two moments: (1) as soon as the application code is generated and (2) as regression tests, in case the generated code has been manually modified. 4. Applying the proposed approach Our approach has been applied to build a DSML for the GRENJ framework (Abi-Antoun, 2007; Braga and Masiero, 2003) and use this DSML in the development of an application for medical clinics. DSML Engineering and Application Engineering phases of the GRENJ framework are described in Sections 4.1 and 4.2. 4.1. GRENJ framework DSML Engineering The GRENJ framework is a white box Enterprise Application Framework (EAF). It implements the domain defined by the pattern language Business Resource Management (BRM), which addresses the rental, purchase, sale and maintenance transactions of goods and services (Abi-Antoun, 2007; Braga and Masiero, 2003). This framework has already been reused in the development of some

4.1.1. GRENJ framework Feature Identification The BRM pattern language has provided an overview of the GRENJ framework features and their relationships. Since the BRM patterns are in analysis level, they do not specify all GRENJ framework classes. Thus, this overview was complemented by consulting the source code of the framework to identify classes that do not appear in the BRM patterns but assist in the implementation of some features. For example, the class model of the first pattern of BRM can be seen in Fig. 13a. The classes in this model reveal two features: Resource, which represents goods and services that are involved in transactions; and Resource Type, which represents any classification that can be applied to resources. However, analyzing the GRENJ framework, as seen in Fig. 13b, Resource Type was divided into two features: Simple Type, representing absolute classifications; and Nested Type, representing classifications based on other classification. Besides, the main classes of these features extend classes of the framework that do not represent any feature, but implement common functionality. After identifying the features, it was necessary to define the sequence in which they should be included in the DSML. In this case, the sequence of the BRM patterns was taken in consideration. However, some alterations were made in this sequence because (1) some patterns revealed more than one feature and (2) some dependencies caused some features to exchange positions in the sequence. For example, the Resource feature, identified in the first pattern of BRM, depends on the Resource Quantification feature, identified in the second pattern. Thus, the Resource Quantification feature had to be treated before the Resource feature, despite the sequence of their patterns. As cited before, the GRENJ framework classes that implement the first pattern of BRM are presented. Three features were

Fig. 13. The GRENJ framework classes that implement the first pattern of BRM.

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

3131

Table 3 GRENJ framework features. Id

Feature

Related Classes

Dependencies

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Simple Type Nested Type Resource Quantification Resource Destination Party Source Party Executor Fine Rate Reservation Rental Trade Quotation Purchase Sale Delivery Maintenance Quotation Maintenance Transaction Item Payment Maintenance Task Part Maintenance Part

SimpleType, QualifiableObject, StaticObject NestedType, QualifiableObject, StaticObject SingleResource, InstantiableResource, QuantificationStrategy Resource, QualifiableObject, StaticObject DestinationParty, StaticObject SourceParty, StaticObject TransactionExecutor, StaticObject FineRate, NumberRangeCalculator, AbstractCalculator ResourceReservation, BusinessResourceTransaction ResourceRental, BusinessResourceTransaction BusinessResourceQuotation BasicPurchase, ResourceTrade, BasicNegotiation, BusinessResourceTransaction BasicPurchase, ResourceTrade, BasicNegotiation, BusinessResourceTransaction BasicDelivery, BasicNegotiation, BusinessResourceTransaction MaintenanceQuotation, BasicMaintenance, BusinessResourceTransaction ResourceMaintenance, BasicMaintenance, BusinessResourceTransaction TransactionItem Payment MaintenanceTask Part MaintenancePart

1, 2, 3 4, 5, 6, 7 4, 5, 6, 7, 8, 9 4, 5, 6, 7 4, 5, 6, 7, 11 4, 5, 6, 7, 11 4, 5, 6, 7 (12 or 13) 4, 5, 6, 7 4, 5, 6, 7, 15 4 (9, 10, 11, 12, 13, 14, 15 or 16) 8 (9, 10, 11, 12, 13, 14, 15 or 16) 7 (15 or 16) (15 or 16), 20

identified in this classes: Resource, Simple Type and Nested Type. Their main classes of these features are, respectively, Resource, SimpleType and NestedType. Considering only these three features, the Resource feature should be the last in the sequence because the Resource class references SimpleType and NestedType through the types relationship, inherited from QualifiableObject. NestedType also uses this relationship to reference subtypes, so the Nested Type feature was the second in the sequence. Although SimpleType also inherits the types relationship, this class does not uses it as typeFieldInitialize and typeClasses were overridden to prevent simple types from having subtypes. Thus, the Simple Type feature was the first in the sequence. In Table 3 all GRENJ framework features are listed in the sequence in which they should be treated. The first related class of each feature is its main class. Dependencies refer to feature Ids.

4.1.2. GRENJ framework Feature Analysis In this step, the GRENJ framework and some sample applications were analyzed to identify what information is required by its features. Since it is a white box framework, this information can be obtained from the operations that, optionally or mandatory, should be overridden in application classes that extend the main class of each feature. For example, while treating the Resource feature, the Resource class, its super classes and some application classes that implement this feature were analyzed in order to find out what information is necessary to do it. Two operations of the Class Resource are shown in Fig. 14: typeClasses, which is abstract and indicates application classes representing resource types, and insertFieldClause, which indicates database table columns for application-specific attributes. Both operations should be overridden in application classes that extend Resource. For example, the code of the Movie class,

Fig. 14. Examples of operations of the Resource class that should be overridden.

3132

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

Fig. 15. Part of the code of the Movie class.

partially shown in Fig. 15, was analyzed in order to facilitate the identification of the information necessary to extend the Resource class. This class belongs to a movie rental application that reuses the GRENJ framework. The typeClasses operation returns an array with the application classes representing resource types (Category and Genre, in this case). Similarly, insertFieldClause returns the names of the application-specific attributes of this class. The information required to instantiate the GRENJ framework is included in the list of its features, as shown in Table 4. From this table it is possible to notice that most part of this information come from feature dependencies. The other part correspond to attributes in framework classes. The related classes were omitted in Table 4 to facilitate visualization.

4.1.3. GRENJ framework DSML Modeling The GRENJ framework DSML was modeled using the GMF, so the same type of files described in Section 3.1.3 are presented in this section. The DSML abstract syntax metamodel of the GRENJ framework can be seen in Fig. 16. Its features were included following the sequence presented in Table 3. This metamodel reuses the auxiliary metaclasses shown in Fig. 4: Application, Attribute, Operation, Parameter and Feature. They are omitted in Fig. 16. However, all features directly or indirectly extends the Feature metaclass. The graphical notation model (gmfgraph file) used in the concrete syntax of the GRENJ framework DSML is the same shown in Fig. 5, because this kind of model is not domain-specific its graphical components can be reused by all features and relationships.

Table 4 The GRENJ framework features, including the information required to instantiate it. Id

Feature

Dependencies

Required Information

0 1 2 3 4

All Simple Type Nested Type Resource Quantification Resource

1, 2, 3

5 6 7 8 9 10 11 12 13 14 15 16 17 18

Destination Party Source Party Executor Fine Rate Reservation Rental Trade Quotation Purchase Sale Delivery Maintenance Quotation Maintenance Transaction Item Payment

4, 5, 6, 7 4, 5, 6, 7, 8, 9 4, 5, 6, 7 4, 5, 6, 7, 11 4, 5, 6, 7, 11 4, 5, 6, 7 (12 or 13) 4, 5, 6, 7 4, 5, 6, 7, 15 4 (9, 10, 11, 12, 13, 14, 15 or 16) 8 (9, 10, 11, 12, 13, 14, 15 or 16)

19 20 21

Maintenance Task Part Maintenance Part

7 (15 or 16) (15 or 16), 20

Application-specific name, attributes and operations. Subtype classes Quantification (single, instantiable or measurable) and the classes that implement resource types. Classes that implement its dependencies. Classes that implement its dependencies. Classes that implement its dependencies. Classes that implement its dependencies. Classes that implement its dependencies. Classes that implement its dependencies. Classes that implement its dependencies. Classes that implement its dependencies. Classes that implement its dependencies. Transaction class and payment strategy (cash, check, invoice, credit card, electronic transfer, money order). Classes that implement its dependencies. Classes that implement its dependencies.

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

3133

Fig. 16. DSML abstract syntax metamodel of the GRENJ framework.

However, the DSML menu bar model (gmftool file) and the mapping model (gmfmap file) are domain-specific. They contain one item for each non-abstract feature or relationship defined in the DSML abstract syntax model. The GRENJ framework DSML gmftool and gmfmap files are partially shown in Fig. 17. 4.1.4. GRENJ framework DSML Construction Because of GMF was used during DSML Modeling, the GRENJ framework DSML Construction generated four plug-ins for the Eclipse IDE. Three of them compose the abstract syntax and the other composes the concrete syntax. 4.1.5. GRENJ framework Generator Construction The templates that compose the application generator of the GRENJ framework DSML were implemented using JET. The fixed and variant parts of these templates were identified by analyzing the code of sample applications reusing the GRENJ framework.

Part of the template for Resource subclasses is shown in Fig. 18. Its fixed parts are formed by Java commands and key words, such as public class. The variant parts are formed by tags that generate class name, attributes and operations. The content of the typeClasses operation is based on the types reference inherited from the QualifiableFeature metaclass in Fig. 16.

4.2. GRENJ framework Application Engineering The GRENJ framework DSML has been used to support the development of an application for the Department of Medical and Odontological Care (DMOC) in our university. The requirements of this application are the following:

1. DMOC provide free medical and odontological care for academic community at our university, who are considered as patients by

3134

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

Fig. 17. Part of the files (a) gmftool and (b) gmfmap of the GRENJ framework DSML.

2.

3.

4.

5.

6.

7.

the application. The attributes of patients are: ID code, name, address, city, phone, email, and birth date. Patients are divided into categories, such as students, teachers, employees and so on. Each patient is also related to a department, which has a ID code, name and acronym. A department also is localized inside one of the university campus, which has ID code, name, address and city. Appointments with doctors can be scheduled by patients at DMOC. Each appointment has ID code, date, time, observations and type (medical or odontological). An attendant is responsible for registering appointments. About attendants, the application must register their ID code, name, address, phone and Doctors have the following attributes: ID code, name, type (physician or dentist), professional register, address, city, phone and Doctors must be record the diagnostics and the description of the treatments applied to patients during appointments. A nurse may help the doctor to perform treatments. About nurses, the application register the same type of information as doctors. Doctors must register in the application medications they can prescribe/apply to patients. About medications, it is necessary to register ID code, name, composition, indications (key words), contraindications, precautions, dosage and adverse reactions. Doctors must also register when they prescribe or apply

medications to a patient during a appointment. In case of drugs, the dosage indicated to the patient must be registered. 8. The application must return: a list of appointments of a patient during a period; a list (historic) of all medications and treatments prescribed/applied to a patient; a list of appointments that each doctor attended during a period; the quantity of each medication prescribed or applied to patients during a period; and a list of medications indicated to a treatment from a list of key words. 4.2.1. DMOC Application Modeling DMOC application model has been created with the use of the GRENJ framework DSML, as observed in Fig. 19. Some of the attributes that were specified in the application requirements are not added to this model, as the GRENJ framework already provides them. The stereotypes in the classes refer to the framework features/classes reused by the application.

4.2.2. DMOC Application Construction The application generator of the GRENJ framework DSML has been executed on the model shown in Figure 19 to generate the code of the DMOC application. Each class in the application model is transformed into a class which extends the framework class referred by its stereotype. For example, the Patient class extends the Resource class of the GRENJ framework.

Fig. 18. Part of the template for Resource subclasses.

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

3135

Fig. 19. Application model created with the GRENJ framework DSML.

Part of the code of the Patient class can be seen in Fig. 20. It was generated based on the information in the application model shown in Fig. 19 and the template presented in Fig. 18. The content of the operations defined in the application models, such as calcAppointments, must be typed in the implementation property of the Operation element. This property is not graphically visualized in the application models, though it can be accessed from the Properties tab in the Eclipse IDE.

5.1. Experiment planning The experiment followed all steps described by Wohlin et al. (2000) and it can be defined as: analyze framework instantiation supported by DSML, for the purpose of evaluation, with respect to efficiency (time) and easiness (problems), from the point of view of the developer, and in the context of undergraduate students of Computer Science and Computer Engineering. The planning phase was divided into the five steps described in the following subsections.

5. Evaluating framework DSML We have conducted a controlled experiment to analyze the advantages provided by the GRENJ framework DSML, as presented in Section 4.1, on the development of applications that reuse this framework. The GRENJ framework was used in this experiment because we had total detailed knowledge about it and access to its source code.

5.1.1. Context and subject selection The context of this experiment was multi-test within object study, since the experiment consisted of experimental tests executed by a group of subjects to study a single approach, which is framework instantiation supported by DSML. The experiment has been performed in laboratory of Computer Science at a university environment. Altogether, 26 undergraduate students of

Fig. 20. Part of the code of the Patient class.

3136

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

Computer Science and Computer Engineering voluntarily participated in the experiment. All of them had prior experience in software development using Java language and were selected according to convenience sampling (Wohlin et al., 2000). 5.1.2. Formulation of hypotheses The questions, metrics and hypotheses that were applied to this experiment were the following: Question 1 (Q1): Does DSML makes GRENJ framework instantiation more efficient when compared with manual instantiation? Metric 1 (M1): time (t) spent to instantiate the GRENJ framework into an application. Null Hypothesis (H10 ): tDSML = tmanual Alternative Hypothesis (H11 ): tDSML < tmanual Alternative Hypothesis (H12 ): tDSML > tmanual Question 2 (Q2): Does DSML reduce the number of mistakes made by the subjects during GRENJ framework instantiation? Metric 2 (M2): number of defects (e) found in the code of the applications developed by the participants with the reuse of the GRENJ framework. Null Hypothesis (H20 ): eDSML = emanual Alternative Hypothesis (H21 ): eDSML < emanual Alternative Hypothesis (H22 ): eDSML > emanual 5.1.3. Variables selection This experiment had the following independent variables: (1) the GRENJ framework; (2) Eclipse development environment version 4.2.1; (3) Java programming language version 6; and (2) the applications developed by the subjects, which were (2a) Library or (2b) Hotel. Both applications address rental transactions and have the same level of complexity. The dependent variables are the following: (1) efficiency, which is related to the time spent on the instantiation of the GRENJ framework into the Library and Hotel applications; and (2) the number of mistakes made by the participants of the experiment during the framework instantiation. 5.1.4. Design The design type of the experiment was one factor with two treatments paired (Wohlin et al., 2000). The factor is the approach used to develop a framework and the treatments are manual and DSML. The experiment followed the design of grouping the subjects in homogeneous blocks, avoiding that their experience level could directly impact in the results. We used a Participant Characterization Form to determine the experience level of each subject. In this form the subjects had to answer multiple-choice questions about their knowledge regarding: (1) Java programming, (2) Eclipse IDE, (3) software patterns and (4) frameworks. Each question had the following score: 0, when the participant had no knowledge; 1, when the participant had only theoretical knowledge; and 2, when the participant had practical knowledge. The subjects were also trained in the instantiation of the GRENJ framework, both manually and using its DSML. In the experimental planning stage, it was decided that the subjects would be divided into two blocks, B1 and B2, of 13 participants. Besides, each block would have approximately the same number of subjects with total scores in the ranges 0–2, 3–5 and 6–8. The following tasks would be performed by the participants of the blocks: Block 1 (B1): Development of the Hotel application reusing the GRENJ framework manually and the Library application reusing the GRENJ framework through DSML.

Block 2 (B2): Development of the Hotel application reusing the GRENJ framework through DSML and the Library application reusing the GRENJ framework manually. To develop an application reusing the GRENJ framework manually, the subjects had to create a class model at design level (application classes extending GRENJ framework classes) and implement application code. To develop an application reusing the GRENJ framework through DSML, the subjects had to model this application using the DSML and execute the application generator. 5.1.5. Instrumentation The subjects received all necessary materials to assist them during experiment execution. These documents consist of: application requirements; application class model at analysis level (disregarding GRENJ framework); GRENJ framework cookbook; test units, which should be run by the subjects to verify the correctness of the outcome applications; and the Data Collection Form, in which the subjects had to report the time spent to develop the frameworks and the error messages returned by the tests units. 5.2. Experiment operation After defining and planning the experiment, its operation phase was carried out in two steps: (1) Preparation and (2) Execution. 5.2.1. Preparation Firstly, the subjects signed a Consent Form, stating the objectives and confidentiality of the experiment, and filled in the Participant Characterization Form, reporting their experience in the technologies utilized in the experiment. The subjects were also trained in the development of applications reusing the GRENJ framework both manually and using its DSML. 5.2.2. Execution In the next day, the subjects were positioned in their respective blocks, B1 and B2, based on their score in the Participant Characterization Form. B1 had 3 subjects with scores of 0–2, 7 subjects with scores of 3–5 and 3 subjects with scores of 6–8. B2 had 4 subjects with scores of 0–2, 5 subjects with scores of 3–5 and 4 subjects with scores of 6–8. In the first phase of experiment execution the subjects in B1 developed the Hotel application, instantiating the GRENJ framework manually and the subjects in B2 developed the same application, instantiating the GRENJ framework using the DSML. Each subject developed his/her application individually and clocked the time spent on it, from application modeling until all of the application code had been implemented/generated. After finishing the development of the application, the subjects had to stop the chronometer. Then they executed the test units to verify whether the framework was correctly instantiated or not. When the tests units returned error messages, the subjects had to wrote these messages in the Data Collection Form, fix these errors and measuring time spent to do it and execute the test units again until there were no more error messages. The second phase of experiment execution was carried out in the same way as the first one, except that: all subjects had to develop the Library application; the subjects in B1 instantiated the GRENJ framework using its DSML; and the subjects in B2 instantiated the GRENJ framework manually. 5.3. Analysis of data The subjects developed the tasks satisfactorily and the collected data was within the expected limits. It means that the treatments were properly executed and in accordance with the planning.

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

3137

Table 5 Average time spent in the development of the applications. Application

Framework instantiation strategy Manual programming

Library Hotel General AVG

DSML

Reduction (%)

Block

AVG

SD

Group

AVG

SD

B2 B1

60 min 31 s 44 min 14 s 52 min 53 s

18 min 59 s 14 min 21 s

G1 G2

6 min 28 s 5 min 32 s 6 min 00 s

1 min 23 s 38 s

The averages (AVG) and the standard deviations (SD) of the time spent by the subjects in the development of the Library and the Hotel applications are shown in Table 5. When the GRENJ framework was instantiated using its DSML, there was an average reduction of 88.48% in the time spent in the application development compared to the time spent in the development of the same applications when the instantiation of the framework was done manually. According to Table 5, the first question (Q1) of the experiment was answered as follows: Question 1 (Q1): Does the use of the GRENJ framework DSML make the reuse of this framework more efficient when compared with manual reuse? Answer: In the development of the Library and the Hotel applications, the time spent to instantiate the GRENJ framework using its DSML was less than the time spent to do it manually, so the alternative hypothesis H11 (tDSML < tmanual ) was accepted as true. We have also analyzed the error messages that were returned by the test units and written in the Data Collection Form by the subjects. These error messages were predefined when we implemented the test units. The number of times that each error message was returned considering all subjects is shown in Table 6. According to Table 6, the most common mistake made by the subjects during framework instantiation was to incorrectly implement operations required by the framework (13 times). The main reason for this kind of mistake is lack of knowledge about framework structure. In some cases the subjects did not understand the purpose of the operations or they did not know the structures that could be used to implement them. When the DSML was used, code generation provided a correct implementation of all methods because the templates were implemented by developers who knew the GRENJ framework in detail and the DSML application generator were tested before the experiment. The second most common mistake made by the subjects was to forget to implement some operations required by the framework. Eclipse IDE helped the subjects alerting when abstract operations of the GRENJ framework were not overridden in application classes. However, other operations of the framework classes had a default implementation and the Eclipse IDE could not know when they Table 6 Error messages returned by the tests executed by the subjects. Error message

Number of times they were returned Manual

DSML

The operation was incorrectly implemented. An operation is missing in an application class. Similar operations are inconsistent. A framework class was misused. An application class re-declares an attribute that its framework super class already provides.

13 8 6 2 3

0 0 0 2 4

Total

32

6

89.31 87.49 88.48

should be overridden or not. It is responsibility of the subjects to know it. This kind of mistake did not occurred when the DSML was used because, in this case, it is responsibility of the application generator to identify from application model when each operation should be implemented. Some operations must appear in several classes of a framework. For example, in the GRENJ framework, Resource, TransactionItem and all classes that represent a type of transaction has an abstract operation that indicates the quantification applied to the resource in the applications. Consequently, all instances of this operation in an application must to return the same quantification. However, some subjects implemented them returning different quantifications, so these operations are inconsistent. DSMLs prevent this kind of mistake, requiring each information only once. Thus, the application generator generates all code related to this information always in a consistent way. Whether using the DSML or not, application developer is responsible for identifying which framework class should be reused to implement an application requirement. Thus, to misuse a framework class is a kind of mistake that has the same probability to occur in both approaches. Another mistake that can occur regardless the use of the DSML is the re-declaration, in an application class, of an attribute that its framework super class already provides. For example, the Resource class has a String-type attribute named description. Some subjects did not reused this attribute when the application class needed an attribute named name. Other subjects re-declared existing attributes in classes that represent rental transactions. Although it did not happened in this experiment, the misuse of framework classes and the re-declaration of attributes provided by framework classes may cause operations not to be implemented or to be incorrectly implemented. It can happen even when a DSML is used, because some operations are implemented based on the elements included in application models. It can be seen in Table 6 that during manual framework instantiation the test units returned more error messages than during framework instantiation through DSML. Thus, the subjects made more mistakes while instantiating the framework manually. The reason for this is that, in manual framework instantiation, there is a greater risk for the subjects to mistype information, misuse the programming language, forget to implement operations required by the framework, implement operations incorrectly and so on. However, when the DSML is used, most of these mistakes cannot be made, as it prevents the insertion of invalid information, forces the insertion of mandatory information, avoid inconsistencies and generates all operations required for framework instantiation. According to Table 6, the second question (Q2) of the experiment is answered as follows: Question 2 (Q2): Does the use of the GRENJ framework DSML reduce the number of mistakes made by the participants during framework instantiation?

Answer: In the development of the Library and the Hotel applications, the number of mistakes (e) made by the subjects when he/she instantiated the GRENJ framework using its DSML was less

3138

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

than when he/she did it manually, so the alternative hypothesis H21 (eDSML < emanual ) is accepted as true. The fact that the applications took more time to be developed when the GRENJ framework was manually instantiated was expected, since application code is generated when the DSML is used. However, part of the time taken with framework instantiation was spent to fix the problems found by the test units in the applications. The more problems were found, the more time was spent to develop the applications. If DSML elements were not clear and intuitive, the DSML could induce the subjects to make more mistakes than they would with manual instantiation. 5.4. Weaknesses in the experimental validation Some constrictions and weaknesses in the experimental validation should be taken into consideration: • GRENJ framework DSML resulted in faster instantiation. However, the time spent on the DSML Engineering was not considered. Our approach is valid only when many the time spent in DSML Engineering is compensated by the time saved in the development of many applications using the DSML; • The implementation of functionality that is not foreseen by the framework in the application code was not verified in this experiment. The DSML only aids in framework instantiation and additional functionality can only be implemented manually; and • It may be said that the experiment is not completely valid because it was applied only in an academic environment. However, most of the resources used in the experiment are the same as those used in industrial and commercial environments. Moreover, the academic environment allows better control over the experimental variables. 6. Related works In this section, some works related to our approach are presented. Braga and Masiero (2003) proposed the use of application generator wizards for the instantiation of EAFs based on pattern languages. The developer creates a class model based on the application requirements and the pattern language of the framework. After that, he or she selects the forms of the wizard based on the classes modeled and generates the application code. In this process, the application model serves only as documentation. The wizard cannot extract the information from the application model, so the information about the application must be specified in the model and then again in the wizard. Consequently, there may be inconsistencies between the information in the model and in the wizard. In our approach, the application code is generated directly from the application model. Moreover, the work by Braga and Masiero focuses on EAFs whose domain is specified in pattern languages. There is no such restriction in our work. Oliveira et al. (2007) presented a systematic approach for framework reuse based on the Reuse Description Language (RDL). This language was created by these authors to register framework hot spots in XML files. In addition, the authors also developed a tool, RDL Execution Environment, that allows the creation of framework feature models. To develop an application reusing the framework, a developer uses the feature model in the tool to select the framework features that correspond to the application requirements. The tool combines the selected features with the XML file, where the hot spots of the framework are registered, to generate the application code. This approach is similar to ours, as there is an analogy between the feature model and the DSML and between the XML

file created with the RDL and the templates used in our approach. However, our approach is not dependent on a specific tool or language. Thus, in our approach, developers can use their favorite tools to model and construct the DSML and to implement the templates. Antkiewicz et al. (2009) described an approach for building framework DSMLs from analyzing the code of applications that reuse the framework. They also defined rules to verify the quality of the DSML and the models created with it in order to reduce the incidence of defects in the applications. However, these authors focused only on Middleware Integration Frameworks (MIFs), such as the Hibernate framework. They also did not specify in detail how they identify the framework features and construct the DSML. In this paper, we have explained how to identify the framework features and how to construct the DSML for any type of framework. Amatriain and Arumi (2011) proposed an approach in which the building of the DSML occurs in parallel to the development of the framework in iterative and incremental activities. The elicitation of the framework requirements is done in the same step as the DSML modeling and the implementation of the framework and the DSML also occurs in the same step. Both the framework and the DSML are implemented using general purpose programming languages. The approach proposed by these authors is complex because it depends on specific knowledge about compiler theory and parser libraries to implement the DSML, instead of using appropriate tools and languages for DSML development. Their approach also focuses on the development of frameworks with DSMLs and cannot be applied to frameworks previously developed by others.

7. Conclusions This paper has presented an approach for building framework DSMLs and for using them to support framework instantiation. In DSML Engineering phase, a DSML is built from the identification of the framework features and the information required to instantiate them. Then, in Application Engineering phase, this DSML is used to model applications and instantiate the framework by generating their code. DSML Engineering phase demands detailed knowledge about framework domain and structure. Framework documentation helps this process, but its source code should be analyzed to confirm specific details. In order to carry out this phase, it is divided into steps. Firstly, in Feature Identification step, all framework features are identified from its reusable classes. So developer gets a general overview of the framework domain and the other steps can be carried out incrementally, treating one feature per iteration: in Feature Analysis step, developer obtains the necessary knowledge for framework instantiation analyzing each feature individually; and in DSML Modeling, DSML Construction and Generator Construction steps all metamodel elements and templates created to represent a framework feature in an iteration can be tested as soon as they are implemented. Thus, these iterations help the scalability of our approach, making developers deal with one part of the problem at a time. Moreover, DSMLs can be used to develop applications even when they are covering part of the framework domain. Feature Identification and Analysis are the most important steps in DSML Engineering because the others depend on the knowledge gained in them. Besides, the other steps are supported by tools, accelerating their execution. However, if developers have previous knowledge about the framework, the difficulties to carry out Feature Identification and Analysis can be eased. If framework was developed to be a core asset of a SPL, framework DSML can be built by the developers involved in the SPL engineering. According to the experiment presented in this paper, DSMLs facilitate framework instantiation because they offer a more friendly interface to configure framework hot spots. Besides, they

M.C. Viana et al. / The Journal of Systems and Software 86 (2013) 3123–3139

also provide constrictions and validation resources that reduces the chance of developers to made mistakes while instantiating the framework. However, the experiment also showed that Application Engineering still demands knowledge about framework domain. Otherwise, developers can choose a wrong framework feature to implement an application functionality or implement attributes and operations without knowing that they are already provided by the framework. Another advantage provided by framework DSMLs is the efficiency gained in application development, as developers do not need to manually implement code that reuses the framework. Another reason for this gain of efficiency is the reduction of time spent with application maintenances, since DSML reduces framework complexities. However, they can still modify the generated application code. Most of the application generators have resources to maintain manual modifications even when the code is generated again. Such as frameworks themselves, DSMLs are worthwhile only when many applications are intended to be developed by using them. Thus, all effort saved in the development of these applications, due to DSML, compensates the effort spent in DSML engineering. As further studies, we intend to evolve the approach as follows: (1) the first phase of the approach will include the use of feature models to generate frameworks and their DSMLs; (2) frameworks and applications developed with the approach will adopt serviceoriented architectures; and (3) applications developed with the approach will be multiplatform and functional on both desktops and mobile devices. Acknowledgements We would like to thank the students that have participated in the experiment presented in this paper. We also thank CAPES for financial support. References Abi-Antoun, M.,2007. Making Frameworks work: a project retrospective. In: Companion to the 22nd ACM SIGPLAN Conference on Object-Oriented Programming Systems and Applications, OOPSLA’07. ACM, New York, NY, USA, pp. 1004–1018. Amatriain, X., Arumi, P., 2011. Frameworks generate domain-specific languages: a case study in the multimedia domain. IEEE Transactions on Software Engineering 37 (4), 544–558. Antkiewicz, M., Czarnecki, K., Stephan, M., 2009. Engineering of framework-specific modeling languages. IEEE Transactions on Software Engineering 35 (6), 795–824. Braga, R., Masiero, P., 2003. Building a Wizard for framework instantiation based on a pattern language. In: Konstantas, D., L’eonard, M., Pigneur, Y., Patel, S. (Eds.), Object-Oriented Information Systems. Vol. 2817 of Lecture Notes in Computer Science. Springer, Berlin/Heidelberg, pp. 95–106.

3139

Cuadrado, J., Molina, J., 2009. A model-based approach to families of embedded domain-specific languages. IEEE Transactions on Software Engineering 35 (6), 825–840. Durelli, V.H.S., Borges, S.S., Penteado, R.A.D., Viana, M.C., 2010. An iterative reengineering process applying test-driven development and reverse engineering patterns. INFOCOMP Journal of Computer Science Special Edition (1), 1902–1929. Fayad, M.E., Johnson, R.E., 1999. Domain Specific Application Frameworks: Frameworks Experience by Industry. Wiley, New York, NY, USA. Fayad, M., Schmidt, D.C., 1997. Object-oriented application frameworks. Communications of ACM 40 (10), 32–38. Fayad, M.E., Schmidt, D.C., Johnson, R.E., 1999. Building Application Frameworks: Object-Oriented Foundations of Framework Design. Wiley, New York, NY, USA. Frakes, W.B., Kang, K., 2005. Software reuse research: status and future. IEEE Transactions on Software Engineering 31 (7), 529–536. France, R., Rumpe, B., 2007. Model-driven development of complex software: a research roadmap. In: Future of Software Engineering, 2007, FOSE’07, pp. 37–54. Gronback, R.C., 2009. Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit. Addison-Wesley, Boston, MA, USA. Institute for Software Integrated Systems, Generic Modeling Environment (April 2012). URL: http://www.isis.vanderbilt.edu/Projects/gme Johnson, R.E., 1997. Frameworks = (components + patterns). Communications of ACM 40 (10), 39–42. Kirk, D., Roper, M., Wood, M., 2007. Identifying and addressing problems in objectoriented framework reuse. Empirical Software Engineering 12 (3), 243–274. Lopes, S.F., Silva, C.A., Tavares, A., Monteiro, J.L., 2005. Application development by reusing object-oriented frameworks. In: International Conference on Computer as a Tool (EUROCON’05), pp. 583–586. Marca, D., McGowan, C., 1988. SADT: Structured Analysis and Design Technique, 3rd ed. McGraw-Hill, New York, NY, USA. Mellor, S., Clark, A., Futagami, T., 2003. Model-driven development—guest editor’s introduction, software. IEEE 20 (5), 14–18. Oliveira, T.C., Alencar, P.S.C., Lucena, C.J.P.D., Cowan, D.D., 2007. RDL: a language for framework instantiation representation. Journal of Systems and Software 80 (11), 1902–1929. Schmidt, D., 2006. Guest editor’s introduction: model-driven engineering. Computer 39 (2), 25–31. Shiva, S.G., Shala, L.A., 2007. Software reuse: research and practice. In: Fourth International Conference on Information Technology, 2007, ITNG’07, pp. 603–609. Srinivasan, S., 1999. Design patterns in object-oriented frameworks. ACM Computer 32 (2), 24–32. The Eclipse Foundation, Eclipse Modeling Project (October 2012). URL: http://www.eclipse.org/modeling/ Weiss, D.M., Lai, C.T.R., 1999. Software Product Line Engineering: A Family-Based Software Development Process. Addison-Wesley, Boston, MA, USA. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., Regnell, B., Wesslén, A., 2000. Experimentation in Software Engineering: An Introduction. Kluwer Academic Publishers, Norwell, MA, USA. Matheus C. Viana is a Ph.D. student at Federal University of São Carlos, in the city of São Carlos, SP, Brazil. His research includes software reuse, software patterns, frameworks, software maintenance and reengineering, model-driven engineering and software product lines. Rosângela A.D. Penteado is an associate professor at Federal University of São Carlos, in the city of São Carlos, SP, Brazil. Her research includes software reuse, software patterns, frameworks, software maintenance and reengineering, aspect programming, model-driven engineering and software product lines. Antônio F. do Prado is an associate professor at Federal University of São Carlos, in the city of São Carlos, SP, Brazil. His research includes software reuse, software patterns, frameworks, software architectures, service-oriented programming, model-driven engineering, ubiquitous computing and software product lines.