engineering of framework-specific modeling languages

TRANSACTIONS ON SOFTWARE ENGINEERING, SPECIAL ISSUE ON SOFTWARE LANGUAGE ENGINEERING, 2009 1

Engineering of Framework-Specific ModelingLanguages

Michał Antkiewicz, Krzysztof Czarnecki, Matthew Stephan

Abstract—Framework-specific modeling languages (FSMLs) help developers build applications based on object-oriented frameworks.FSMLs model abstractions and rules of application programming interfaces (APIs) exposed by frameworks and can express models ofhow applications use APIs. Such models aid developers in understanding, creating, and evolving application code.We present four exemplar FSMLs and a method for engineering new FSMLs. The method was created post-mortem by generalizing theexperience of building the exemplars and by specializing existing approaches to domain analysis, software development, and qualityevaluation of models and languages. The method is driven by the use cases that the FSML under development should support and theevaluation of the constructed FSML is guided by two existing quality frameworks. The method description provides concrete examplesfor the engineering steps, outcomes, and challenges. It also provides strategies for making engineering decisions.Our work offers a concrete example of software language engineering and its benefits. FSMLs capture existing domain knowledgein language form and support application code understanding through reverse engineering, application code creation through forwardengineering, and application code evolution through round-trip engineering.

Index Terms—framework-specific modeling language, domain-specific language, object-oriented framework, application programminginterface, API, feature model, framework-specific model, forward engineering, reverse engineering, round-trip engineering, evolution,code pattern, mapping

F

1 INTRODUCTION

O BJECT-ORIENTED frameworks are widely used todevelop applications in many domains. Frame-

works provide domain-specific concepts, which are genericunits of functionality. Developers create framework-based applications by writing framework completion code(also known as application code), which instantiatesthese concepts. For example, the framework underlyingEclipse’s workbench offers concepts such as views andeditors [1], [2]. Eclipse’s outline view and Java edi-tor are instances of these concepts. In order to createsuch instances, the developers perform implementationsteps, such as subclassing framework-defined classes,implementing framework-defined interfaces, and callingappropriate framework services. Concept instantiation isgoverned by the application programming interface (API)of the framework. The API specifies the programmingelements exposed to the user, e.g., the classes to subclassand the methods to call, and how they should be used.

Framework APIs are often complex and difficult touse. They may provide many concept variants and severalways of instantiating them. For example, an Eclipse edi-tor may be single- or multi-page. Furthermore, an actioncan be added to the editor’s toolbar directly or throughan action contributor mechanism. Some implementationsteps are different for a multi-page editor compared to

• M. Antkiewicz, K. Czarnecki, and M. Stephan are with the Department ofElectrical and Computer Engineering, University of Waterloo, Waterloo,ON, N2L 3G1, Canada.E-mail: {mantkiew, kczarnec, mdstepha}@gsd.uwaterloo.ca

a single-page one. In addition, the developers have torespect API-prescribed constraints on the implementationsteps, such as having to instantiate a multi-page actioncontributor for a multi-page editor rather than a regularaction contributor. Finally, the developers also have tofollow general rules of API engagement. For example,the callback methods that are called by Eclipse’s UserInterface (UI) framework API must not be blocking.

API documentation, sample applications, and wiz-ards, if available, offer some support in writing com-pletion code. Cookbook-style articles and tutorials canbe effective in demonstrating how framework-providedconcepts should be instantiated; however, their maindrawback is their passive nature, meaning that the devel-opers must still perform the necessary implementationsteps manually. Since steps implementing a particularconcept are often scattered across the application codeand tangled with steps implementing other concepts,writing and understanding completion code can stillbe challenging. This scattering and tangling is also thereason why sample application code may be difficult touse as an implementation guide. In addition, cookbook-style documentation is often partial and does not coverthe full range of concept variants. In contrast, API refer-ence documentation, such as that produced by Javadoc,is usually more complete; however, this form of docu-mentation describes only individual API elements, suchas interface methods, and does not explain the higher-level concepts whose instantiation involves multiple APIelements. Code generation wizards, as offered by someframeworks, are an active form of concept instantiationknowledge. Unfortunately, they usually cannot be re-


run with different settings once the generated code hasbeen modified by a developer. Also, they typically coveronly a few of the most used concept variants and theydo not provide traceability between the configurationparameters and the generated code.

We believe that the existing support for applicationdevelopers can be significantly improved by taking alanguage perspective on framework APIs. In essence,a framework’s API implicitly defines a domain-specificlanguage, whose concepts are implemented and exposedthrough the mechanisms of the framework’s program-ming language. The implementation is supplementedwith documentation in natural language whenever theprogramming language is insufficient. For example, theconcept of a Java Applet being a mouse listener [3] cor-responds to several Java Applet API elements, includingan API call to register a mouse listener and another callto deregister it. Whereas the API calls are representedby Java, the higher-level concept of an Applet being amouse listener is defined in the Applet API documenta-tion. The language-oriented perspective is based on thepremise that application developers think about thesehigher-level concepts when programming, even thoughthe concepts might not be explicitly represented by theprogramming language constructs.

Framework-specific modeling languages (FSMLs) [4], [5]are an explicit representation of the domain-specificconcepts provided by framework APIs. FSMLs are usedfor expressing framework-specific models (FSMs) of ap-plication code. Such models describe the instances offramework-provided concepts that are implemented inthe application code. In an FSM, each concept instanceis characterized by a configuration of features. Featuresare concept properties such as single- or multi-page inthe Eclipse editor example. Features correspond to codepatterns that implement them in the application, suchas classes implementing framework interfaces, calls toframework methods, and ordering of such calls.

We present our experience from building four FSMLs:Eclipse Workbench Part Interactions (WPI) FSML, JavaApplet FSML, Apache Struts FSML, and Enterprise JavaBeans 3 (EJB) FSML. The experience is presented asan FSML engineering method, which we devised post-mortem. Similar to the Unified Process of object-orientedsoftware development [6], the method is iterative and use-case-driven. FSML use cases are central to the methodsince they embody the value proposition of FSMLs.Thus, FSML scoping and design decisions are madewith respect to the use cases that the FSML underdevelopment should support. The method considers fivemain use cases in which FSMLs provide value to applica-tion developers: framework API understanding, completioncode understanding and analysis, completion code creation,completion code evolution, and completion code migration.The method divides the life cycle of an FSML into iter-ations, each further subdivided into four phases: incep-tion, elaboration, construction, and transition. Each phaseinvolves several development activities and activities are

subdivided into steps. The method adopts and extendsactivities from feature-oriented domain analysis [7]. Themethod description provides concrete examples for thedevelopment steps and the outcomes and challenges ineach activity based on the four FSMLs. It also providesstrategies for making engineering decisions, such asdeciding the language scope or the language structure.

We ground the FSML approach in the design scienceparadigm [8] and a semiotic framework of model qual-ity [9], [10]. Design science is a research paradigm inwhich “knowledge and understanding of a problemdomain and its solution are achieved in the building andapplication of the designed artifact” [8]. The semioticframework distinguishes between syntactic, semantic,and pragmatic qualities, and we apply it at the level ofFSMs, FSMLs, and the entire framework-specific modelingfoundation (FSMF). Some aspects of FSM and FSMLqualities must be considered separately for each FSML;others depend on the FSMF and, thus, are inherentto the FSML approach. The assessment of the FSML-dependent qualities is part of the method. The methoduses Cognitive Dimensions [11], [12] to asses the pragmaticquality of FSMLs.

The main contributions of this work are the fourFSMLs and the experience of building them, packaged asan engineering method. The four languages constitute aset of exemplars, i.e., representative examples, of FSMLs.These exemplars demonstrate the ability of the FSMLapproach to support code understanding, creation, evo-lution, and migration for practical Java frameworks.The method offers FSML developers concrete steps andguidelines and is a necessary step in the maturationof the FSML approach. We make no claims about thequality of the method; however, the four FSMLs wereevaluated as prescribed by the method.

The paper is organized as follows. We first describehow we applied the design science paradigm to de-velop the FSML approach (Section 2), followed by abrief overview of the key concepts and mechanisms ofthe approach (Section 3). We apply the model qualityframework and Cognitive Dimensions to the differentelements of the FSML approach in Section 4. We presentthe FSML engineering method in Section 5, followed bymethod justification in Section 6. We discuss the maturityof the different elements of the FSML approach andsuggest directions for future work in Section 7. Finally,we discuss the related work in Section 8 and concludethe paper in Section 9.

2 RESEARCH APPROACH

The FSML approach was developed according to thedesign science paradigm [8], [13], which seeks to createinnovations intended to solve a given problem usingtwo processes: build and evaluate. These processes aidresearchers in understanding the problem domain andin devising and checking feasibility of novel solutions.In contrast, the behavioural science paradigm, rooted in


natural science methods, takes a different approach:researchers develop theories, i.e., principles and laws, toexplain and predict existing phenomena and then seekto justify these theories. Thus, the main processes in be-havioural science are theorize and justify. Design scienceand behavioural science paradigms are complementaryand inseparable. On the one hand, a successful artifact,as shown by evaluation, created using the design scienceparadigm may be subjected to theorize and justify tofurther the artifact’s understanding. On the other hand,successful theories, as shown by justification, can beleveraged when building new artifacts in design science.

The design science paradigm categorizes artifacts asinstantiations, constructs, models, and methods. For a givensolution, instantiations are implementations of the ap-proach, constructs constitute the conceptual foundationof the approach, models explain relationships amongconstructs, and methods explain the process of creatingnew instantiations. Often, instantiations are created priorto constructs, models, and methods.

To address the challenges of framework API usage,we built four FSMLs, each for a different frameworkand purpose. These FSMLs are the instantiations of theapproach. The WPI FSML was built first and it wasmanually implemented. The Struts FSML was built next.It was also manually implemented, but it reused partsof the WPI FSML’s implementation. Common parts ofboth FSML implementations were then factored out andgeneralized into an FSML infrastructure, which allowedFSMLs to be specified declaratively. The Applet FSMLwas the first language specified fully declaratively ontop of the infrastructure. Eventually, all four languageswere specified declaratively and the infrastructure wasfurther generalized and refined during that process.Through that generalization, basic constructs and modelsof the FSML approach emerged. We refer to them as theframework-specific modeling foundation (FSMF). TheFSML engineering method is the final artifact required bythe design science paradigm; we present it in Section 5.

3 FRAMEWORK-SPECIFIC MODELING FOUN-DATION (FSMF)

The main constructs of the FSMF are shown in Fig-ure 1. The framework API (implicitly) provides a set ofdomain-specific concepts along with the constraints ontheir instantiations. The application code uses the API byimplementing instances of these concepts. A concept in-stance is implemented through code patterns that adhereto the rules and constraints of the API. Code patternscan be structural (e.g., subclassing a framework class)or behavioural (e.g., calling a framework method in thecontrol flow of an object, order of method calls) [14].

An FSML explicitly models the concepts and con-straints prescribed by the framework API as feature mod-els. Feature models represent concepts as hierarchies offeatures, which are distinguishing characteristics among

Fig. 1. Modeling framework API usage by FSMs

concept instances [7]. In particular, we use cardinality-based feature models [15], [16], which support multipleinstantiations of features, feature attributes (includingfeature reference attributes), additional constraints overfeatures (such as implies or excludes), and feature inher-itance. The distinction between a concept and a featureis a matter of focus: the root of the feature hierarchywithin the current scope of consideration denotes aconcept, whereas its children denote features of thatconcept. When the scope changes, a feature may becomea concept and vice versa [17, apdx. A]. Thus, any nodein a feature hierarchy can be seen as a concept for allof its descendents, and any node except the root can beseen as a feature of any of its direct or indirect parents.

Effectively, feature modeling is the abstract syntax def-inition formalism for FSMLs. Other choices such as classmodels or textual grammars are also possible; however,feature models are particularly well suited because oftheir ability to concisely represent commonalities andvariabilities and their wide use in domain analysis [7],[17, ch. 4]. The suitability of feature modeling to domainanalysis is important since a substantial part of FSMLengineering can be understood as domain analysis.

An FSM models the API usage of the application.It describes concept instances as feature configurations,which consist of feature instances configured according tothe constraints imposed by the FSML’s defining featuremodel. Each feature instance corresponds to one or morecode patterns that implement the feature instance inthe application code. An FSM can help application de-velopers answer questions such as how the applicationis using the framework, what concepts the applicationimplements, whether the application uses the frameworkcorrectly, and how the application should use the frame-work.

Importantly, features may represent both high-leveldomain concept properties, such as single- or multi-page for the Eclipse editor example, and low-level im-plementation variants, such as adding an action to theeditor’s toolbar directly or through a contributor. Thehigh-level features are usually defined by aggregatingor referencing lower-level features in the feature modelor both. Consequently, the code pattern implementing a


Fig. 2. Defining feature-instance-to-code-pattern corre-spondence using mapping definitions

high-level feature is a composition of the code patternscorresponding to the lower-level features that it aggre-gates or references.

Figure 2 illustrates how the correspondence betweenfeature instances and code patterns is established. Thefigure is divided into four parts, each representing adifferent artifact: application, FSM, FSML, and FSMLinfrastructure. A feature instance in an FSM representsone or more code patterns in the application. Instancesof the relationship between the code patterns and featureinstances are referred to as traceability links. The feature-instance-to-code-pattern correspondence is specified aspart of the FSML definition by attaching mapping def-initions to features. Each mapping definition containsa pattern expression that specifies the desired code pat-terns using a mapping type. Mapping types are genericand reusable specifications of feature-instance-to-code-pattern correspondences that are provided by the FSMLinfrastructure. For example, there are mapping types forspecifying the correspondence to Java classes that arecompatible with a given type, calls to methods witha given signature, or XML elements on a given path.Mapping types define parameters, such as the methodsignature or the XML element path, which are set inpattern expressions.

Since the mapping types are only specifications, theyare implemented by code queries for detecting the speci-fied code patterns in the application code and code trans-formations for adding the code patterns to or removingthem from the code. Effectively, code queries enablereverse engineering (RE), i.e., the automatic retrieval ofFSMs from application code by detecting feature in-stances in the code [14]. Code queries are executed forfeatures in the FSML’s metamodel. If a code pattern ismatched, an instance of the given feature is added to theFSM and a traceability link is established. Traceabilitylinks allow navigating from feature instances in themodel to code patterns and vice versa. Analogously,code transformations enable forward engineering (FE), i.e.,the generation of code from FSMs by successively exe-cuting, for each of their feature instances, the transforma-tions for code pattern addition. Finally, both code queries

and code transformations enable round-trip engineering(RTE), i.e., the ability to propagate modifications of theapplication code to its model and vice versa [18]. In RTE,a prescriptive FSM, i.e., a model of how an applicationshould use an API, is first compared with the descriptiveFSM, i.e., the FSM of how the current application codeactually uses the API. The descriptive model is obtainedthrough RE, and the comparison uses the last-reconciledmodel as a reference, i.e., we use a 3-way compare [19].The last-reconciled model records the common base ofthe prescriptive and the descriptive models from thetime of their last reconciliation. The reference allows usto determine whether a feature instance present onlyin one of the two models, i.e., the descriptive or theprescriptive one, was added to one them or removedfrom the other. After the comparison, the user can reviewthe differences and resolve conflicts, if any. As a laststep, the prescriptive model and the code are updated.The prescriptive model is updated by copying the newfeatures from the descriptive model and/or removingthe features that are not present in the descriptive model.The code is updated by executing code transformationsthat add, remove, or modify feature implementationsin the code. Currently, code transformations supportonly code addition. If the code transformations are notimplemented, RTE can still be used for comparing thecode and the model and incrementally updating themodel.

In general, the queries and transformations of themapping types for specifying behavioural patterns canonly be approximations of the respective mapping typesemantics. This limitation is due to the undecidability ofdynamic properties of programs. For code queries, ap-proximation means the possibility of false negatives, i.e.,feature instances undetected by the query but presentin the code; and false positives, i.e., feature instances de-tected by the query but absent from the code. The qualityof approximation can be measured using precision andrecall [20]. Precision is related to false positives: the fewerfalse positives, the higher the precision. Recall is relatedto false negatives: the fewer false negatives, the higherthe recall. A perfect approximation has both precisionand recall of 100%. Our previous work showed the fea-sibility of devising code queries that were able to detectall the behavioural features of three exemplar FSMLs ina large body of open-source application code with veryfew false negatives (high recall) and false positives (highprecision) [14]. The exemplars considered in that studywere the WPI, Applet, and Struts FSMLs. Code queriesand transformations may define additional parameters, i.e.,parameters that are needed in addition to those definedby the corresponding mapping types. These parametersmay be set as part of mapping definitions in order totune the behavior of the queries and transformations. Forexample, query parameters may determine the context-sensitivity of the code analysis, and transformation pa-rameters may specify the preferred location for a methodcall to be added.


Fig. 3. Overview of FSML Use Cases

The generic FSML infrastructure delegates the execu-tion of code queries and transformations to pluggablemapping interpreters. This mechanism simplifies the im-plementation of new mapping types that may be re-quired by a particular FSML and it allows support formultiple artifact types, such as Java, XML, and C/C++.The related Ph.D. thesis [5] contains details on the tech-nical aspects of the infrastructure: its architecture andimplementation.

The FSML approach was designed to support five usecases illustrated in Figure 3.

1) Framework API understanding (AU) throughmanual inspection of the concepts and mappingdefinitions of the FSML metamodel.

2) Completion code analysis and understandingthrough RE. This use case groups four more specificuse cases:

a) understanding (U) by inspecting the FSM andnavigating to code patterns through traceabil-ity links;

b) referential integrity checking (RIC) by evaluatingmodel queries over the FSM to check whetherconsistent values are used throughout thecode, possibly throughout multiple artifacts ofdifferent types such as Java and XML;

c) API constraint checking (ACC) by evaluatingcardinality and additional constraints over theFSM; and

d) model analysis (MA) by analyzing or transform-ing the FSM in order to retrieve informationneeded to achieve the language’s value propo-sition. The processing may range from simplemodel filtering to applying inference rules.

3) Completion code creation (C) by generating codefor an existing FSM through FE. Creation involvesincrementally adding new code patterns to theexisting code; however, it is the developer’s respon-sibility to manually resolve possible conflicts, such

as duplicate methods or classes. Manual conflictresolution is necessary because FE does not takeinto account existing code as RTE does.

4) Completion code migration (M) between frame-work versions or even different but conceptuallysimilar frameworks through RE and FE. In the firstcase, the migration requires detecting deprecatedfeatures and adapting their implementation to thenew API. In the second case, the migration can beachieved through applying RE to the code that usesthe source framework and executing specialized FEto produce the code that uses the target framework.Both frameworks need to be conceptually closesince a single model is used. Otherwise separatesource and target FSMLs with a model transfor-mation are required.

5) Completion code evolution (E) by independentlyevolving and synchronizing the completion codeand the FSM through RTE. Evolution of the codecan be observed by comparing FSMs extracted atdifferent points in time. The code can be evolvedby first changing its corresponding FSM and thenpropagating the changes to code using RTE. UnlikeFE, RTE first identifies feature instances that arealready implemented and only adds code patternsrelated to new feature instances.

We will provide concrete examples of feature models,mapping types, and mapping definitions in Section 5.

4 ARTIFACT QUALITIES IN THE FSML AP-PROACH

Following the design science paradigm, any novel ar-tifact built (constructs, models, methods, and instanti-ations) must be evaluated with respect to its goals. Inparticular, the quality of the FSMLs being engineeredneeds to be measured and such measurement needs tobe part of an FSML engineering method. This sectionpresents a framework for defining the quality of modelsand languages, which we use to define the quality ofFSMs, FSMLs, and the FSMF. The framework buildson prior work on model quality [9], [10] and CognitiveDimensions for evaluating notations [11], [12].

4.1 Model Quality

Lindland et al. proposed a general semiotic frameworkfor defining the quality of models [9]. Their basic as-sumption, rooted in semiotics (e.g., [21]), is that a modelis expressed in some language, represents some domain,and has some audience (cf. Figure 4). In this setting, threebasic types of model quality can be considered [9].

Syntactic quality is the extent to which the model iswell-formed with respect to the modeling language.

Semantic quality is the extent to which the model isvalid and complete with respect to the domain. Validitymeans that all statements made by the model are correctabout and relevant to the domain. Completeness means


Fig. 4. General Quality Framework [9]

that the model makes all the statements about the do-main that are correct and relevant. The relevancy of thestatements depends on the scope of the model: the real-world domain being modeled may contain propertiesthat are irrelevant and, thus, outside the scope of themodel.

Pragmatic quality is the extent to which the modelcan be constructed, comprehended, and modified byits audience. More precisely, the comprehension goal ofpragmatic quality is the complete and correct under-standing of the model by its interpreting audience. Fur-thermore, a model created or modified by an audienceshould completely and correctly reflect the intention ofthe audience. Pragmatic quality depends on many modelproperties that impact the ease of creation, comprehen-sion, and modification, such as visual appearance (e.g.,use of diagrams or text, meaningful icons and names,and quality of layout), conciseness, and closeness ofmapping (i.e., the extent to which the structure of thedomain is explicit in the model). These properties arehighly interdependent. For example, conciseness can beimproved at the cost of explicit structure by introducingshorthands.

Lindland et al. introduced the notion of feasibilityof quality goals [9]. Intuitively, feasibility means thatthe benefits of improving the quality with respect toa given goal should be greater than the drawbacks ofdoing so. For semantic quality, feasible validity is reachedwhen the benefits from removing an invalid statementfrom the model are less than the drawbacks; feasiblecompleteness is reached when the benefits of addingnew statements is less than the drawbacks. Drawbacksmay involve both economic issues and factors such asuser preference and ethics. For pragmatic quality, feasiblecomprehension is reached when the benefits from correctlycomprehending statements in the model that have notyet been considered or were misunderstood are less thanthe drawbacks. Similarly, feasible construction and feasiblemodification balance benefits and drawbacks by relaxingthe requirement that a newly constructed or modifiedmodel completely and correctly reflects the intention ofthe audience.

Lindland et al. also distinguish between qualities andthe means for improving the qualities. For example,syntactic quality can be improved by means of errorprevention (such as structured editing), error detection(syntax checking), and error correction (such as auto-matic correction proposals). In our setting, means forimproving semantic quality include model consistencychecking, RE, FE, and RTE. Finally, means for improving

Fig. 5. Quality framework applied at each of the threelevels of the FSML approach

pragmatic quality include visualization, filtering, expla-nation, animation and simulation, and refactoring.

In addition to these three basic qualities, we alsoconsider the organizational quality of a model, which isthe extent to which the model fulfills the goals of theorganization that is using it [10]. Organizational qualityreflects the ultimate value of a model to an organization.This quality depends on the syntactic, semantic, andpragmatic qualities of the model, but it also considerssocial aspects of an organization, such as the diversityof its members who use the model and the rules andpractices of the organization.

4.2 Quality of FSMs, FSMLs, and the FSM Founda-tion

We apply the model quality framework at three levels:FSMs, FSMLs, and the FSM foundation (cf. Figure 5). Thedomain of an FSM is a particular API usage that themodel represents. The primary audience for FSMs areapplication developers, but FSML developers and FSMLinfrastructure developers also need to read and createFSMs as part of their work (the primary audience of eachartifact is typed in bold face in Figure 5). As expected,the syntactic quality of an FSM is defined with respect toits FSML; the semantic quality is defined with respect tothe API usage it represents; and the pragmatic quality isdefined with respect to its audience. These three qualitytypes are defined along the same lines for an FSML,except that the domain is a set of API usages; the syntaxis defined by the specification of the FSM foundation;and the primary audience are FSML developers.

We distinguish between the pragmatic quality of theFSML extent, i.e., the set of valid FSMs, and the prag-matic quality of the metamodel, i.e., the FSML definition.The reason is that, in general, the same FSML extentcan be defined by many different metamodels, e.g., eachusing inheritance differently, and each such metamodelhas its own pragmatic quality. The pragmatic quality ofthe extent can be thought of as the cumulative pragmaticquality of the models in that extent. Given the seman-tics to be expressed, the language enables achieving a


certain level of pragmatic model quality. In general, if alanguage contains representational redundancy, i.e., if thereis more than one way to express the same semantics,a particular model may not achieve the best pragmaticquality, e.g., conciseness, that would be possible for thegiven semantics. In FSMLs, since the mapping from APIusages to FSMs is a function, there is no representationalredundancy: given a particular API usage, the pragmaticquality of the extent directly translates into the pragmaticquality of a given model. Obviously, the pragmatics ofthe metamodel and the pragmatics of the extent overlap.

The pragmatic quality of FSMLs can be assessed usingthe Cognitive Dimensions (CDs) framework [11], [12].The framework takes a whole-system view: it assessesthe quality of a system consisting of the notation and itsenvironment. The environment is essentially the meansused to manipulate representations in the notation, i.e.,the modeling means in our context. The frameworkdefines the following dimensions.

Abstraction Gradient reflects whether a notation disal-lows, allows, or even requires defining new abstractionswhen creating a new model. The notation is then referredto as abstraction-hating, abstraction-tolerant, or abstraction-hungry, respectively. Abstraction mechanisms add to theweight of a language in terms of learning and usage cost.In particular, abstraction hungry languages suffer from“delayed gratification” because the appropriate abstrac-tions must be defined before the programmer’s inherentgoals can be addressed [12]. FSMLs are abstraction-hating: an FSM instantiates only the language-providedabstractions (concepts and features) and no new abstrac-tions can be created as part of the FSM.

Closeness of mapping represents the similarity of thestructures in the domain to the structures in the model.In general, FSMLs can represent both hierarchies ofAPI-related application code elements and structuresthat cross-cut such hierarchies; however, closeness ofmapping needs to be assessed for individual FSMLs aspart of the FSML engineering method.

Consistency is related to the “guessability” of a nota-tion. When a subset of the language has been learnt,how much of the remainder can be inferred? For FSMLs,consistency translates into the use of consistent andmeaningful criteria for naming, nesting, and grouping offeatures in the FSML metamodel. This dimension needsto be assessed as part of the method.

Terseness is related to the number of model elementsneeded to express a meaning. FSMLs promote tersenesssince FSMs contain only concept and feature instanceswithout any superfluous syntax. Support for computingdefault feature selections can help improve this dimen-sion for FE and RTE by allowing the modeler to stateonly the features of interest explicitly.

Error-proneness is related to the question whether thenotation induces mistakes. It needs to be assessed forindividual FSMLs as part of the method.

Hard mental operations refers to the existence of men-tal operations at the notation level that are difficult

to perform, such as certain combinations of constructsbeing difficult to understand. For example, if a propertyof interest is represented by several features scatteredacross an FSM rather than a single feature, inferring thefeature may require resorting to paper and pencil. Thisdimension needs to be assessed for individual FSMLs aspart of the method.

Hidden dependencies are dependencies among modelelements that are implicit in the model and are difficultto uncover. The hierarchical structure of concepts isexplicit and most visible. Dependencies created throughfeature attributes referring to other features are lessvisible and require some means to support their traver-sal. The most hidden dependencies are incurred bythe additional constraints defined over two or morefeatures, such as implications and mutual exclusions.This dimension is assessed for each FSML as part of themethod. Interestingly, the vast majority of dependenciesin our four exemplar FSMLs were encoded in featurehierarchies, and only relatively few reference attributesand additional constraints were needed.

Premature commitment refers to situations where mod-elers have to make decisions before they have the in-formation they need, e.g., when information has to bespecified in a strict order. The natural construction orderfor concept instances in an FSM is top-down; however, afeature configuration interface can additionally supportbottom up configuration by choice propagation. Conse-quently, FSMLs do not require premature commitment.

Progressive evaluation refers to the ability to build amodel incrementally. FSMLs support the incrementalcreation of models. In particular, incremental code addi-tion and round-trip engineering allow testing the resultof adding new concept and feature instances.

Role-expressiveness refers to the ability to recognize therole of an element in a model and is related to self-describability of the notation. The role-expressiveness ofa vanilla FSM is relatively low since all elements areconcept or feature instances; however, this quality canbe improved by annotating concepts and features withfeature types indicating their roles, e.g., components,connectors, API constraints, high-level domain proper-ties, and implementation variants. Our exemplar FSMLimplementations use custom icons to make these rolesvisible in FSMs. Assessing this dimension is part of themethod.

Secondary notation refers to the ability to use layout,colour, or other cues to convey extra meaning above andbeyond the official semantics of the language. Supportfor comments and annotations can be easily provided.

Viscosity is related to the amount of effort required toperform a given change. The presence of global depen-dencies such as references and cross-cutting constraintsincreases viscosity. Viscosity can be reduced by improv-ing modularity, i.e., increasing cohesion and reducingcoupling. The exemplar FSMLs have low viscosity withrespect to feature re-configuration as they have only fewreferences and constraints. FE and RTE help reduce the


viscosity of FSMs in the presence of application code.Visibility is related to the ability to see all the relevant

information simultaneously (assuming a large enoughdisplay). Visibility can be improved by providing filter-ing facilities.

Some of the dimensions, such as abstraction gradient,are specific to the entire approach; other need to beassessed for individual FSMLs as part of the FSMLengineering method. The dimensions to be assessed onan FSML-basis are closeness of mapping, consistency,error-proneness, hard mental operations, hidden depen-dencies, role-expressiveness, viscosity, and visibility.

Finally, the quality of the entire approach dependson the quality of the FSM foundation (cf. Figure 5).For the sake of our discussion, we take the Platonicstance that an ideal FSMF exists and only waits to bediscovered and explicitly represented. This stance allowsus to consider the qualities of the FSMF specificationand implementation, such as the degree of formality (notshown in the figure), semantic correctness, and usability.

4.3 Quality of RE, FE, and RTE

The purpose of modeling means is to improve modelquality. Thus, we also need to consider the quality of thekey modeling means in our context, namely RE, FE, andRTE. These means rely on a set of algorithms which arepart of the foundation [5]. These algorithms have beentested using the exemplar FSMLs.

The RE algorithms are designed such that they canonly produce well-structured models modulo possibleviolations of cardinality and additional constraints. Suchviolations are allowed since RE should also be ableto produce models of applications that use an APIincorrectly. The semantic quality of RE depends on thecorrectness of the mapping definitions and code queriesimplementing the corresponding mapping types. Sincethe queries are approximations of the mapping defini-tions, our goal is to achieve feasible semantic quality.The mapping definitions and queries are tested for thepresence of false positives and false negatives on sampleapplications as part of the method and improved asneeded. The improvement may require modeling fea-tures differently, adjusting their mapping definitions, oreven implementing new queries. RE has no impact onthe model pragmatics since there is only one correctmodel for a given application.

FE relies on the mapping definitions and code trans-formations implementing the corresponding mappingtypes in order to create syntactically and semanticallycorrect code. Thus, the mapping definitions and thetransformations need to be tested for different inputmodels as part of the method. Depending on the ap-plication context, the generated code may or may notbe complete; thus, our goal is feasible completeness. Inaddition to syntactic and semantic correctness needed toachieve feasible validity, other qualities of the generatedcode, such as performance and readability, also need to

be assessed as part of the method. As a result of theassessment, the FSML may need to be refined, e.g., byadding new feature implementation variants.

RTE relies on the quality of the mapping definitionsand their queries and transformations in a similar wayas RE and FE do; however, RTE places additional re-quirements on the transformations, as they should beable not only to add implementations of concept andfeature instances to an existing application, but alsoremove or modify implementations. Currently, the FSMLinfrastructure provides only transformations for addingimplementations. That is, removals and modificationsneed to be done manually at the code level; however,the infrastructure eases this process by providing fulltraceability between the model and the code. Further-more, RTE relies on the quality of matching between thecurrently asserted prescriptive model and the descriptivemodel retrieved from the application code. The matchingrelies on the definition of concept and feature keys,which is part of the method.

4.4 Organizational Quality of FSMLs

The organizational quality of an FSML is the extent towhich the FSML fulfills its stated use case goals (cf.Figure 3). This quality relies on qualities of the involvedartifacts and means.

For framework API understanding, application de-velopers rely on the syntactic, semantic, and pragmaticquality of the metamodel.

For completion code understanding and analysis, ap-plication developers rely on the semantic completenessof the FSML (i.e., the ability to express all relevantinformation), the pragmatic quality of the FSML extent(for model comprehension), and the quality of RE (onlyfew false negatives and/or false positives).

For completion code creation, application developersrely on the semantic and pragmatic quality of FSMLs,the quality of code generation (FE), and the syntactic andsemantic quality of FSMs. Means such as editing assis-tance (e.g., auto-completion) and consistency checkingcan improve syntactic and semantic quality of FSMs.

For completion code migration, application developersrely on the same qualities as those for code understand-ing and analysis and for code creation.

For completion code evolution, application developersadditionally rely on the quality of model comparison andcode transformation.

FSML developers also rely on the pragmatic quality ofthe metamodel in order to evolve it.

Finally, application, FSML, and infrastructure devel-opers ultimately depend on the quality of the FSMF.

5 FSML ENGINEERING METHOD

This section presents the FSML engineering method. Themethod was constructed post-mortem by generalizing


Fig. 6. Inputs to method construction

the experience of building four FSMLs and by specializ-ing a set of well-established, general approaches (cf. Fig-ure 6): Feature-Oriented Domain Analysis (FODA) [7], [17,ch. 4], the model quality framework [9], the CognitiveDimensions framework [11], [12], and a few elementsof the Unified Process [6]. We refer to these generalapproaches as the base approaches of the method.

Constructing the method allowed us to elicit andorganize our experience in a systematic way. The baseapproaches provided the overall method structure andthe generic concepts and steps that were used to drivethe elicitation. FODA was selected as a basis for the do-main scoping and feature modeling activities. The modelquality and the Cognitive Dimensions frameworks wereused to establish the evaluation criteria for FSMLs asdescribed in Section 4. The overall iterative life cyclemodel and the idea of use-case driven development wereborrowed from the Unified Process. This choice wasmotivated by the fact that the exemplar FSMLs weredeveloped in an iterative and use-case driven fashion.

The exemplar FSMLs were developed outside of acontrolled environment since their development drovethe creation of the FSML foundation and infrastructureas described in Section 2. Thus, we relied on retrospec-tion and inspection of the current and past versions ofthe FSMLs to provide concrete examples of engineeringsteps and issues. The elicitation of these steps and issuesinvolved specializing the base approaches to the FSMLcontext, e.g., extending FODA to handle cardinality-based feature modeling and mapping definitions, whileidentifying corresponding examples in the FSML meta-models and recalling the issues that arose during theircreation.

Since the method embodies our experience with FSMLengineering, we make no claims about the method’scompleteness or generality. Instead, we justify the engi-neering steps with examples from the exemplar FSMLs.1

Furthermore, Section 6 provides more information onhow well the base approaches fit the actual experienceand how they had to be specialized and adapted. Sec-tion 6 also gives ideas of how the method may be

1. The complete metamodels of the FSMLs can be found else-where [5], [22].

specialized during its application.

5.1 OverviewThe design and implementation of FSMLs is an iter-ative and incremental process. In each iteration, newentities, such as concepts, features, mapping types anddefinitions, and implementations of code queries andtransformations are added and existing ones are evolved.

The overall structure of our engineering method wasinspired by the Unified Process for software develop-ment [6]. The life cycle of an FSML consists of multipleiterations, each having the following phases as shownon Figure 7. Each iteration has different focus and re-quirements and the goal of each iteration is to deliver aworking increment in functionality to the users.

Fig. 7. FSML life cycle: iterations and phases

1) Inception is the initial planning phase. It is focusedon resolving global questions such as determiningthe value proposition of the language and the usecases to be supported for the current iteration.

2) Elaboration is focused on identifying the main con-cepts and creating the overall structure of featuremodels.

3) Construction is a refinement phase in which the con-cepts are decomposed into features and mappingdefinitions are created. Additionally, new mappingtypes, code queries, and code transformations canbe added or existing ones can be refined.

4) Transition is focused on improving the quality ofthe language, verifying whether the language de-livers its value proposition, and preparing it for therelease to the users (application developers).

Within each phase, FSML developers perform severalactivities and activities consist of steps. Certain activitiesare dominant in certain phases, but each activity canpotentially be performed in any phase. For example,value proposition is usually defined in the inceptionphase, but it can also be redefined in the subsequentphases. Furthermore, activities are performed iteratively.For example, the identification of a concept is followedby the identification of its features, which may be fol-lowed again by the identification of another concept.

The following sections describe the phases and theirdominant activities. The activities and steps are pre-sented in the form of instructions that can be followeddirectly by FSML developers. These instructions aremarked by ! . We also mark questions that should beanswered by a step or activity by ? . The presentationuses a naming scheme whereby each activity is labeled


Fig. 8. FSML life cycle: phases and their dominantactivities in a single iteration

with the initial letter of the corresponding phase nameand its consecutive number in the activity list for thephase. Each step is labeled by its activity label andthe number representing its position within its activity.For example, I1 is the label of the first activity of theinception phase and I1.1 is the first step of that activity.Figure 8 illustrates the intensity of performing differentactivities in different phases of the FSML’s life cycle.The figure suggests that the activities and steps neednot be performed in the order of their presentation inthe method. Furthermore, not every step and activity areperformed in every iteration.

5.2 Inception

Inception takes as input a concrete framework for whichan FSML is to be designed or a framework and anexisting FSML to be refined. Table 1 shows informationrelated to the inception of the four exemplar languages.The first row shows the inception date in the firstiteration for each language. In this phase, the followingactivities are performed.

I1: Determine the purpose of the language.? What problem or problems should the language ad-

dress and what is the value proposition for this iteration?! Value proposition should justify the effort of perform-

ing the iteration.Table 1 summarizes the value propositions for the four

exemplar FSMLs. The main motivation for developingthe WPI FSML was that implementing Eclipse work-bench part interactions involves several implementationsteps that are usually highly scattered in the completioncode. Thus, determining the presence and the propertiesof interactions in the completion code was challengingfor application developers. Also, some necessary imple-mentation steps could be easily missed when implement-ing interactions. Consequently, the value proposition ofthe WPI FSML was to ease the understanding of theinteractions by providing a model and navigability tothe corresponding code fragments and to simplify thecreation of interactions by checking API constraints andby offering round-trip engineering.

The Struts FSML was initially developed to demon-strate the feasibility of automatic migration of Strutsapplications to the Java Server Faces (JSF) framework.Struts and JSF are two frameworks for developing web

applications that are conceptually similar, with JSF pro-viding more advanced features. Later, the focus of theStruts FSML shifted toward visualizing page flow andchecking the referential integrity between Java comple-tion code and the corresponding XML configuration files.The latter aspect is important in Struts-based develop-ment since framework concept instances are representedboth in Java and XML and they are related by name. Thisnaming convention increases the possiblity of namingmistakes that are typically discovered only at runtimeand thus reducing productivity. The FSML allows de-tecting such mistakes at development time.

The Applet FSML was developed primarily as a ped-agogical example. It provides an overview of the mainfeatures of applets from the viewpoint of the Applet APIand supports full round-trip engineering. This languagewas the main example used when extending our FSMLinfrastructure with support for declarative mapping def-initions. It was also used to compare the FSML approachwith the design fragments approach, which documentsusage patterns for framework APIs [23]. We used thesame set of 56 applets as a benchmark for testing theFSML. Since the Applet API is relatively simple, theApplet FSML is particularly useful as an introductoryexample when learning the FSML approach.

The main motivation for the EJB FSML were chal-lenges caused by the introduction of Java annotations asan additional configuration mechanism in EJB 3.0. Thenew mechanism supplements the usual configurationthrough XML-based deployment descriptors. The EJB 3.0specification defines a set of complex rules governingthe merge and overriding of configuration informationspecified in Java and XML. As a result, tool supportis required in order to see the final configuration andto understand how it originated. The EJB FSML offersexactly such a tool. Furthermore, a secondary purposeof the FSML is to detect EJB antipatterns, such as BloatedSession or Fragile Links [24].

I2: Determine which use cases should be supported.? Which use cases are required to achieve the lan-

guage’s purpose in the current iteration?! Consider the use cases illustrated in Figure 3 and

described in Section 3.The use cases supported by each exemplar FSML are

specified in Table 1.Framework API understanding (AU). Since the Applet

FSML covers most of the scope of the Applet API, itcan be used to learn about Java applets. The remainingFSMLs focus on specific aspects of the correspondingframework API, such as areas that are difficult to under-stand in completion code, and they also can be used tolearn about these aspects.

Completion code understanding (U). All four exemplarssupport this use case.

Referential integrity checking (RIC). Struts FSML con-tains features that correspond to information from Javaand XML and features that correspond to the referentialintegrity constraints.


TABLE 1Inception of the exemplar FSMLs

WPI FSML Struts FSML Applet FSML EJB FSMLInception Fall 2005 Fall 2006 Fall 2006 Fall 2007Developers Michał Antkiewicz Michał Antkiewicz, Aseem P.

CheemaMichał Antkiewicz Matthew Stephan

Framework Eclipse Workbench 3.x Apache Struts 1.x Java 5.0 Applet Sun EJB 3.0Valueproposition

Provide (1) design-level overviewof the system, which containsworkbench parts and interactionsamong them; (2) navigability tothe crosscutting implementation;and (3) API constraints checking.Demonstrate feasibility of round-trip engineering.

Initial focus was on (1) semi-automatic completion code mi-gration from Struts to Java ServerFaces; later the focus changed to(2) referential integrity checkingbetween Java and XML and (3)visualizing web-page flow. Last(4) code creation was added.

(1) Drive the extension of the genericFSML infrastructure to support definingFSMLs declaratively; (2) Compare FSMLapproach to design fragments approachusing applets as benchmark. (3) Demon-strate feasibility of round-trip engineer-ing. (4) Provide an introductory FSMLexample.

Provide (1) an overallconfiguration viewmerging informationfrom Java anddeployment descriptorsand (2) supportdetection of EJBantipatterns.

Use cases U, ACC, C, E M, later U, RIC, last C AU, U, ACC, C, E U, RIC, ACC, MAHorizontalscope

editors, views, selection interac-tions, part life cycle interactions,adapter interactions

actions, forwards, messages,forms, XML declarations

applets, status, mouse listeners, threads,parameters

EJBs, businessinterfaces, Javaannotations, XMLdeclarations, overriderules

Artifacttypes

Java, plugin.xml Java, XML Java Java, XML

API constraint checking (ACC). All exemplars exceptStruts FSML support this use case (Struts FSML focusessolely on checking referential integrity).

Model analysis (MA). In EJB FSML, the analysis in-volves applying override rules to produce a run-timeview of the EJB configuration.

Completion code creation (C). WPI, Struts, and AppletFSMLs support incremental code creation. Support forthis use case was later added to Struts FSML since allcode transformations for the used mapping types werealready implemented.

Completion Code Migration (M). Both Struts and JSFframeworks have similar concepts but different ways ofimplementing them and therefore the completion codecan be automatically migrated [25]. The first version ofthe Struts FSML supported this use case.

Completion Code Evolution (E). WPI and Applet FSMLssupport RTE for all of their features.

I3: Determine the sources of knowledge about theframework and the domain.? Which sources provide information about the con-

cepts and features in the scope?! Consider the following items as possible sources of

framework knowledge: API documentation, tutorials,articles, expert knowledge, experience, sample appli-cations, and existing metamodels and XML schemasprovided with the framework.

Table 2 showcases the sources of knowledge that wereused in the design of the exemplar FSMLs and thedistribution of the FSML features over these sources.Each three-row block in the table provides the number offeatures (second row) originating from the given source(first row). The third row contains the percentage of thetotal number of features in the language that originatedfrom the given source. A summary of features originat-ing from all documents is given in the column ΣDoc.Features originating from non-documentation sourcesare presented in columns to the right of the columnΣDoc. The last column gives the total number of features

for each language.A significant percentage of the features in WPI and

Applet FSMLs were created from experience (Table 2).These statistics reflect the fact that the developer ofthese FSMLs had previous experience in using the cor-responding frameworks. In contrast, the developers ofthe Struts and EJB FSMLs did not have prior experi-ence with the frameworks; thus, the vast majority ofthe features were extracted from documentation. Thedistribution of features over their documentation sourcetypes largely depends on the availability and quality ofthe corresponding sources. For frameworks that haveextensive configuration schemas, such as Struts and EJB,the schemas were a significant source of knowledge,e.g., 28% of features for Struts and 18% of features forEJB. Such schemas can be viewed as metamodels ofthe artifacts they represent and can be, to some degree,incorporated into the FSML. For the sample FSMLs,only two features (for Applet FSML) were obtained fromexample applications (EA); however, their subfeatureswere later added based on API documentation. Also,the mapping definitions of many features were improvedbased on the analysis of example applications [14].

I4: Determine the scope of the language.? What concepts and features are in the scope of the

language?! Consider horizontal and vertical scope.

Horizontal scope is measured with respect to the cover-age of the API. The breadth of the horizontal scope canbe delineated early by deciding which top-level conceptsshould be included. The decision is guided by the valueproposition. For example, the purpose of the FSML couldbe to (1) enforce certain API constraints and good prac-tices and to detect typical errors or omissions, antipat-terns, or bad code smells or (2) support understandingand implementing features that are difficult to locate inthe code due to scattering and tangling. For each case,only the concepts and features involved in these areas ofdifficulty would be included. The horizontal scope is also


TABLE 2Distribution of features over sources of knowledge

Source kind API Tutorials Articles ΣDoc Other (non-doc) ΣF

WPI

Source DW [26] TW1 [1] AW1 [2] AW2 [27] AW3 [28] D* I E X F*Features 11 - 6 - 7 11 6 41 14 15 - 1 71Percentage 15.5% 8.5% 9.9% 15.5% 8.5% 57.8% 19.7% 21.1% 1.4% 100%

Stru

ts Source DS [29] SS [30] TS1 [31] AS1 [32] D* I X F*Features 3 13 14 - 8 - - 38 7 - - 2 47Percentage 6.4% 27.7% 29.8% 17.0% 80.9% 14.9% 4.3% 100%

App

let Source TA1 [33] TA2 [34] D* I E EA F*

Features - - 19 7 - - - 26 23 24 2 - 75Percentage 25.3% 9.3% 34.7% 30.7% 32.0% 2.7% 100%

EJB Source DE [35], [36] SE [37] TE1 [38] D* I F*

Features 21 13 27 - - - - 61 12 - - - 73Percentage 28.7% 17.8% 36.9% 83.5% 16.4% 100%

Source Descriptionf Letter indicating a framework. W - Eclipse Workbench, S - Apache Struts, A - Java Applet, and E - Sun EJB3.0Df Features from API documentation, such as Javadoc or other specifications, where f is the framework.Sf Features from schemas contained in the framework, where f is the framework.Tf i Features from the framework’s tutorials, where f is the framework and i is the identification number for the tutorial.Af i Features from articles, where f is the framework and i is the identification number for the article.D* All the features derived from any of documents.I Implied features. For example, every class has a name, so a feature name is implied.E Features from expert knowledge.EA Features example applications that use the framework.X Extra features added by FSML developer. These features were related to a view filtering capability of the FSM editor.F* All features of the FSML.

influenced by the kinds of stakeholders, their experience,and their viewpoints. For example, quality assuranceengineers are likely to be interested in detecting APIconstraint violations, whereas developers are likely tohave broader interests. The key concepts in scope ofthe exemplar languages and supported artifact types arelisted in Table 1.

Vertical scope refers to the depth of the feature models.The deeper the models, the more detailed and fine-grained features become. Usually, the leaves of the hier-archy correspond to the implementation steps stipulatedby the API, such as calling a framework method, orthe parameters of these steps, method call’s arguments.The vertical scope is usually impacted by the choiceof the use cases to be supported. In particular, addingsupport for forward and round-trip engineering to anexisting FSML that only supported reverse engineeringwill sometimes require deeper feature decomposition tomodel alternative implementation variants. Planning thehorizontal scope is the main goal of I4; the vertical scopewill more clearly emerge in later stages as the use casesare implemented.

Languages targeting API understanding are likely tocover the entire API. Their horizontal scope may em-phasize the most used areas and perhaps also the moretricky ones. The horizontal scope of the Applet FSML isfairly balanced. Languages for reverse engineering arelikely to focus on areas that are more difficult to under-stand, such as workbench part interactions for WPI. Lan-guages supporting integrity checking, e.g., Struts FSML,are quite selective in terms of their horizontal scope.Model analysis involves adding higher level concepts forrepresenting the results of the model analysis. Also, theextracted model is typically scoped toward the modelqueries that need to be executed, which is the case

for the antipattern detection in the EJB FSML. Addingsupport for incremental forward engineering and round-trip engineering typically requires deeper vertical scopethan reverse engineering. We observed this in WPI andApplet FSMLs. Adding support for these use casesrequired adding more detailed features, such as thoserepresenting method call arguments. Finally, migrationrequires determining the commonalities and differencesbetween the source and target domain of the migration.

5.3 Elaboration

E1: Identify framework-provided concepts in the scope(cf. Box 1).? Which concepts should be included in the current

iteration?! Use the identified sources of knowledge to find rele-

vant concepts.API documentation, tutorials, and articles. These sources

provide concepts and features representing the intendedAPI use as envisioned by the framework developers.

Experience and best practices. These sources provideconcepts and features on how expert developers use theframework. Note that experts often contribute articlesand tutorials.

Sample applications. Analysis of sample applications,both supplied with the framework and real-life appli-cations, may provide information about not only thetypical API uses, but also the unusual ones, which maynot be available from other sources.

Metamodels and XML schemas. These sources provideconcepts and features that are made explicit by frame-work developers. Note that various configuration di-alogs and wizards supplied together with the frameworkcan be based on these metamodels or schemas.


E1: Identify framework-provided concepts in the scope

The following fragments of the Java Applet Tutorial [33] are used as a runningexample. We identify a single concept: Applet.“An applet is a special kind of Java program that a browser enabled with Javatechnology can download from the internet and run.”

“An applet must be a subclass of the java.applet.Applet class, which pro-vides the standard interface between the applet and the browser environment.”

“Swing provides a special subclass of Applet, called javax.swing.JApplet,which should be used for all applets that use Swing components to constructtheir GUIs.”

“Life Cycle of an Applet: Basically, there are four methods in the Applet classon which any applet is built.

init: This method is intended for whatever initialization is needed for yourapplet. It is called after the param attributes of the applet tag.

start: This method is automatically called after init method. It is also calledwhenever user returns to the page containing the applet after visiting otherpages.

stop: This method is automatically called whenever the user moves away fromthe page containing applets. You can use this method to stop an animation.

destroy: This method is only called when the browser shuts down normally.”

“To draw the applet’s representation within a browser page, you use the paintmethod.”

“Parameters are to applets what command-line arguments are to applications.They allow the user to customize the applet’s operation. Applets get the user-defined values of parameters by calling the getParameter method.”

“You should also implement the getParameterInfo method so that it returnsinformation about your applet’s parameters.”

Box 1: An example for activity E1

E2: Determine kinds of concepts in scope (cf. Box 2).? What is the nature of the concepts?! Classify concepts as component-oriented, connector-

oriented, or port-oriented.Component-oriented concepts are those that do not re-

late other concepts with each other; rather, they aggre-gate other concepts and features. Component-orientedconcepts usually correspond to code components, suchas Java classes or XML documents.

Connector-oriented concepts model connections amongother concepts using references. Connector-oriented con-cepts can correspond to code components (e.g., classesimplementing listeners), but they can also correspond tocode patterns scattered across the components relatedby the connector, such as scattered method calls or XMLdeclarations.

Port-oriented concepts interface between the compo-nents and connectors, i.e., they enable connecting aconnector to a component. They often correspond to Javainterfaces.

E3: Define the overall structure of the feature model(cf. Box 3).? How should the feature model be organized?

A feature model of an FSML is a hierarchy of features.We represent the hierarchy using indentation, i.e., sub-features are indented further to the right.

E3.1: Define a model root. A model root is the containerof all concepts and features and it always correspondsto the entire application.

E3.2: Introduce features for grouping related con-cepts/features. A feature model can be divided into logicalparts that group related concepts or features. This stepmay require the introduction of new concepts or fea-

E2: Determine kinds of concepts in scope

The concept Applet is a component-oriented concept because it is a Java classand it does not reference other concepts.

The concept ViewPart in WPI FSML represents a graphical view in Eclipse. It isa component-oriented concept because it is a Java class and it does not referenceother concepts.

The concept AdapterRequestor in WPI FSML is a connector-oriented concept.It relates a part that requests an adapter with multiple AdapterProviders. Theconcept corresponds to an adapter request method call.

The concept BusinessInterface in EJB FSML is a port-oriented concept. Theconcept and all non-abstract concepts that inherit from it allow EJB clients toconnect to EJBs. Specifically, EJB clients connect to EJBs through a businessinterface by specifying the interface using Java annotations (@Local or @Remote)or through the XML deployment descriptor.

The characterization of the concepts is helpful in determining the structure of thelanguage, that is, which concepts should be main concepts and which conceptsshould be parts (subfeatures) of other concepts. In WPI FSML, the conceptViewPart was modeled as a separate concept so that it can be representedin the model once and referenced by other concepts. We also chose to model allconnector-oriented concepts in WPI FSML as separate concepts; however, theycould also be modeled as subfeatures of parts. In EJB FSML, explicit businessinterfaces are modeled as separate concepts and then are referenced, whereasderived business interfaces are subfeatures of other concepts.

Box 2: Examples for activity E2

tures whose only purpose is to group its children. Thegrouped elements could be related conceptually or basedon the source code artifact they represent.

E3.3: Characterize concepts as base or derived concepts.Instances of derived concepts correspond to the samecode patterns as instances of base concepts do. Codepatterns that instances of base concepts correspond toare specified directly in the metamodel using mappingdefinitions. In contrast, code patterns that instances ofderived concepts correspond to are specified using abase-concept reference, which can point to an instance ofthe base concept (cf. Box 3). The base-concept referencemechanism is useful in at least three ways. First, it helpsreduce redundancy in the metamodel because essentialfeatures of base concepts need not be copied to the de-rived concepts. Second, it allows for specifying derivedconcepts as standalone concepts rather than subfeaturesof their base concepts. Third, it supports composition ofmultiple FSMLs by allowing concepts in one languageto be derived from concepts of another language.! For derived concepts, create a base-concept reference

subfeature typed with the base concept.

5.4 Construction

In this phase, the feature model is refined into a completemetamodel and any additional required artifacts, such asqueries, transformations, and test suites, are created.

C1: Decompose the concepts into features.? How should the concepts be decomposed into fea-

tures?C1.1: Choose appropriate level of abstraction and granular-

ity (cf. Box 4).? Which features are important with respect to the value

proposition? Which features can be abstracted away?! Use the criteria below to decide which features are

potentially useful to include.


E3: Define the overall structure of the feature model

AppletModelApplet

overridesLifecycleMethods

The concept Applet is a child of the model root AppletModel. The featureoverridesLifecycleMethods is used for grouping features correspondingto the life cycle methods.

EJBApplicationInformationFromAnnotationsInformationFromDeploymentDescriptor

In EJB FSML, the feature InformationFromAnnotations is used for groupingsubfeatures related to Java annotations and the feature InformationFrom-DeploymentDescriptor is used for grouping subfeatures related to the XMLdeployment descriptor.

WorkbenchPartInteractionsPartViewPart -|> PartEditorPart -|> PartAdapterRequestor

requestor (Part) <baseConcept>

The concept Part is a base concept and the AdapterRequestor is a derivedconcept. The feature requestor is a base-concept reference of the conceptAdapterRequestor and it specifies that each instance of the concept Adap-terRequestor will correspond to the same code pattern that the referencedbase-concept instance corresponds to, which is an instance of the concept Partin this case. Note that instances of both ViewPart and EditorPart conceptscan be values of the requestor reference. Alternative designs (without the base-concept reference mechanism) are as follows:

Part PartAdapterRequestor ViewPart -|> Part

ViewPart -|> Part EditorPart -|> PartEditorPart -|> Part ViewAdapterRequestor -|> ViewPart

EditorAdapterRequestor -|> EditorPart

In the first case, the AdapterRequestor is not a standalone concept and in thesecond case, inheritance is used to make sure that the adapter requestor conceptsare views and editors. Both alternative designs are suboptimal and do not reflectmodeler’s intention. Additionally, the base-concept reference mechanism enablesseamless FSML composition. For example, the concept AdapterRequestorcould be defined in a different FSML.

Box 3: Examples for activity E3

Features corresponding to implementation steps. Any APIusage ultimately involves some implementation steps,such as subclassing a framework class, implementinga framework interface, implementing callback methods,invoking a framework service, placing a Java annota-tion, creating framework-stipulated XML declarations,or setting XML attribute values. Every FSML will includesome amount of these features.

Frequently used features. These features are likely toincrease the usefulness of the language.

Composite features. These features are defined in termsof other features. Higher-level abstractions are defined ascomposite features over features representing individualimplementation steps. Such higher-level features usuallyadd significant value to the language.

Features related to complex API constraints or dependen-cies. Including these features in the language will enablechecking these constraints in FSMs.

Features related to protocols. Ordering of framework-related calls is typically enforced by frameworks (call-back protocols); however, application programmers aresometimes required to follow protocols related to the lifecycle of framework components. These protocols incurconstraints such as that certain framework services mustbe invoked in conjunction and/or in a certain order. Such

C1.1: Choose appropriate level of abstraction and granularity

AppletModelApplet

extendsAppletoverridesLifecycleMethods

initdestroy

registersMouseListenerderegisters

parametername

ThreadInitializesThread!<1-1>

initializesThreadWithRunnableinitializesWithThreadSubclass

providesParameterInfoprovidesInfoForParameters

Implementation steps. Most of the features correspond to implementation steps.For example, in order to create an instance of the concept Applet, the developermust create a Java class which extends the framework class Applet, override lifecycle methods (e.g., init or destroy), register and deregister mouse listenersby adding calls to the appropriate methods, or retrieve values of parameters byadding a method call and specifying the name of the parameter (cf. Box 1).

Frequently used features. Examples of features that almost every applet has are thefeatures init and parameter.

Features involved in API constraints. The features parameter and provides-ParameterInfo are involved in a constraint providesInfoForParameters.The constraint asserts that if at least one parameter is used, the applet shouldprovide information about the parameters.

Features with variability. The feature Thread is an example of a feature withtwo functionally equivalent implementation variants. In Java, a thread can beinitialized in two ways: by instantiating the Thread class or subclassing theThread class. The choice is modeled using an exclusive-or feature group !<1-1>.

Scattered features. In our exemplar FSMLs most composite features are scatteredfeatures, for example the feature Thread.

StrutsApplicationStrutsConfig

ActionDeclpath

FormDeclForwardDecl

Composite features. The feature StrutsConfig is a composite feature because itgroups all features related to the action, form, and forward declarations in thestruts-config.xml file.

WorkbenchPartInteractionsSelectionListener

registersAs!<1-3>

globalSelectionListenerderegistersderegistersSameObject

registersBeforeDeregistersglobalPostSelectionListenerspecificSelectionListener

Features related to life cycle protocol. In our exemplar FSMLs, features related tolisteners have a life cycle because the listener has to be first registered and laterderegistered, when no longer needed. The feature globalSelectionListenercorresponds to the registration method call and the feature deregisterscorresponds to the deregistration method call. Furthermore, the featuresderegistersSameObject and registersBeforeDeregisters, specify thatthe same object must be used in both method calls and that the registration mustoccur before deregistration, respectively.

Features with variability. The feature registersAs is an example of a featurewith three alternative functional variants. A selection listener can be registeredas a global selection listener, a global post selection listener, or a specific selectionlistener. Registering a listener in different ways achieves different effects for thesame feature. The choice is modeled using an inclusive-or feature group !<1-3>instead of an exclusive-or one because a listener of each kind can be registeredsimultaneously.

Box 4: Examples for step C1.1

constraints are easy to violate in the code and thereforeincluding features that represent them in the languageshould be considered.

Features with variability. Features that have significantly


different functional or implementation variants are likelycandidates for inclusion in the language. Functional vari-ants achieve different functional effects, whereas imple-mentation variants are different ways of implementingthe same effect.

Scattered features. These features correspond to codepatterns scattered across the completion code. They cancorrespond to the scattered patterns directly or throughtheir subfeatures. The key value of supporting scatteredfeatures is that they can be localized in the modeland ease the access to and comprehension of the cor-responding code patterns that are scattered across thecode. Effectively, an FSM can represent alternative codedecompositions.

C1.2: Decide on feature nesting (cf. Box 5).? Which features should be parent features and which

should be subfeatures?! In general, feature nesting may follow partonomies,

taxonomies, and other dependencies [39]. Since featuresrepresent code patterns, a subfeature relationship be-tween a parent and a child feature may correspond topart-of, is-a, or other dependencies between the repre-sented code patterns. Use the criteria below to decideon feature nesting.

Code pattern nesting. Feature nesting may mirror syn-tactic nesting of the code patterns that the featurescorrespond to.

Code pattern subtyping. Feature nesting may mirrorsubtype relationship between the code patterns that thefeatures correspond to.

Other dependencies. Feature nesting may mirror otherdependencies, such as declaration-use, control-flow, ordata-flow dependencies, between the code patterns thatthe features correspond to.

C1.2: Decide on feature nesting

Code pattern nesting. The features corresponding to fields and methods are likelychildren of features corresponding to classes (cf. Box 4, the features Thread andinit are children of Applet). Also, features corresponding to XML attributesare children of features corresponding to XML elements (cf. Box 4, the featurepath is a child of ActionDecl).

AppletModelApplet

extendsAppletextendsJApplet

Thread...

initializesWithThreadSubclassoverridesRun

Code pattern subtyping. Features corresponding to being assignable to morespecific types (e.g., extendsJApplet) are children of features correspondingto being assignable to more general types (e.g., extendsApplet) because of thesemantics of type inheritance (extending JApplet implies extending Applet).

Other dependencies. The feature overridesRun specifying that a subclass of theclass Thread should override the method void run() only applies if the vari-ant with a subclass is used (the feature initializesWithThreadSubclass).


C1.3: Specify cardinality constraints (cf. Boxes 6, 7).? What should be the valid number of instances of

a feature in every feature configuration? Cardinalityconstraints of which features and feature groups areessential for an instance of their parent feature to exist?

! Choose between the kinds of cardinality listed below.Feature cardinality is an interval [m..n], m ≥ 0 ∧

(n ≥ m ∨ n = ∗), specifying how many instances ofa given feature (at least m and at most n) should bepresent as children of that feature’s parent in a featureconfiguration. In general, feature instances correspondto API-stipulated code patterns in the completion codeand the cardinality of a feature depends on the possiblenumber of patterns that can be matched.

Feature group cardinality is an interval <m-n>, 0 ≤m ≤ n ≤ k specifying how many instances of features ina feature group of size k should be present as childrenof that group’s parent feature in a feature configuration.Feature groups represent a choice over a number ofgrouped features. Feature groups with cardinality <1-1> model an exclusive-or choice, that is, that exactlyone instance of one of the grouped features should bepresent. Feature groups with cardinality <1-k>, wherek is the number of grouped features, model an inclusive-or choice, that is, that at least one instance shouldbe present. A feature group with cardinality <0-k> isequivalent to k optional features.

The semantics of a feature model is a set of legalfeature configurations, that is, configurations in whichall constraints (including cardinality constraints) are sat-isfied. We introduce the notion of essential constraintsto define a superset of the legal feature configurationsin which the essential constraints are never violated butin which other constraints can be violated. Essentialitycan be thought of as a modifier on feature and groupcardinality that specifies that both lower and upperbounds of the cardinality must not be violated. Knowingthat certain constraints will never be violated in anyconfiguration from that superset allows us to detect andreason about incorrect concept instances. Essentiality ofadditional constraints can be expressed by modelingthem as features (cf. C1.4) whose cardinality is essential.

Essential features. These features correspond to patternsthat are the minimum requirements to identify a conceptinstance. Without its essential features an instance can-not be considered an instance of a particular concept.Essential feature is a short form for essentially mandatoryfeature. We mark cardinality of essential features usingthe exclamation point (!), that is, ![1..1].

Essential feature groups. Often, several different essen-tial features are possible and more than one may or maynot be allowed to be present at the same time. Suchsituations can be modeled using essential feature groups!<m-n>.

Mandatory features. These features correspond to pat-terns that should be present according to the API butwhich are not essential. Mandatory features have cardi-nality [1..1].

Optional features. These features correspond to patternsthat may be present according to the API. Optionalfeatures have cardinality [0..1]. Optional features can begrouped in feature groups to capture certain constraintsamong them, such as that certain patterns are alternative


C1.3: Specify cardinality constraints

AppletModel[0..*] Applet![1..1] extendsApplet

[0..1] extendsJApplet[0..*] Thread![1..1] typedThread[1..1] InitializesThread!<1-1>

[0..1] initializesThreadWithRunnable[0..1] initializesWithThreadSubclass

[1..1] nullifiesThread[1..1] providesInfoForParameters

EJBProject[0..1] InformationFromAnnotations

[0..*] EJBClass[0..*] SessionBean -|> EJBClass[0..1] remoteInterfaceSpecification![1..*] remoteInterfaces (RemoteLocalInterface)

[1..1] interfaceName[0..*] StatelessEJB -|> SessionBean![1..1] statelessAnnotation

[0..1] InformationFromDeploymentDescriptor[0..*] DDStatefulEJB -|> DDSessionBean![1..1] sessionType

![1..1] isStatefulSessionType

Essential features. Essential features of component-oriented concepts maycorrespond to being assignable to a certain type (extendsApplet ortypedThread), being annotated with a Java annotation of a certain type(statelessAnnotation), or being declared as a component in an XMLconfiguration file (isStatefulSessionType). Essential features of connector-oriented concepts may correspond to method calls that attach the connectorto a component (cf. Box 7, requestsAdapter). Finally, an essential featureof port-oriented concepts may correspond to explicitly naming the port in aJava annotation of the component (remoteInterfaceSpecification andinterfaceName).

If an instance of the essential feature extendsApplet was missing, agiven class would not be considered an instance of the concept Applet.Similarly, a class will only be considered an instance of a stateless EJBin the annotation section of the language (that is, under the featureInformationFromAnnotations) if the class is annotated with a statelessannotation (the feature statelessAnnotation).

Essential feature groups. The feature group !<1-1> specifies that an instance ofInitializesThread cannot exist without an instance of at least one of thegrouped features.

Mandatory features. For example, the features initializesThread and nul-lifiesThread are required for the correct implementation of a thread but theyare non-essential since only the feature typedThread is required to determinethat a given field is a thread.

Often, mandatory features are used to model API constraints, so that a missinginstance of a mandatory feature indicates constraint violation. For example, thefeature providesInfoForParameters corresponds to an API constraint.

Optional features. For example, the feature extendsJApplet indicates that thedeveloper can optionally extend another API class. Examples of optional groupedfeatures are initializesThreadWithRunnable and initializesWith-ThreadSubclass.


(exclusive-or).Multiple features. These features correspond to pat-

terns that can be repeated in the code. We distinguishthree kinds of multiple features depending on the lowerbound of the feature cardinality: optional multiple, withcardinality [0..n]; mandatory multiple, with cardinality[m..n]; and essential multiple, with cardinality ![m..n],where m ≥ 1 ∧ (n > m ∨ n = ∗). Essential multiple is ashort form for essentially mandatory and multiple. Usually,concepts have cardinality [0..*] since there may be no ormany concept instances implemented in an application.

Prohibited features. These features correspond to pat-terns that should not be present in the code. Prohibitedfeatures have cardinality [0..0]. Prohibited features mayrepresent undesirable situations, such as API misuses,

C1.3: Specify cardinality constraints

WorkbenchPartInteractions[0..*] Part[0..*] EditorPart -|> Part

[0..0] extendsMultiPageEditor[0..*] SelectionListener

...[0..*] globalSelectionListener

[1..*] deregisters[0..*] AdapterRequestor![1..1] requestor (Part) <baseConcept>![1..*] requestsAdapter

Multiple features. The feature globalSelectionListener corresponds to theregistration method calls and it is an optional multiple feature. In the featureconfiguration, each instance of the feature will correspond to a single methodcall. The feature deregisters is a mandatory multiple feature because forevery registration method call there should be at least one deregistration call.The feature requestsAdapter is an essential multiple feature because a givenpart is an adapter requestor only if it requests at least one adapter by calling themethod getAdapter.

Prohibited features. For example, the feature extendsMultiPageEditor corre-sponds to an editor extending a deprecated API class MultiPageEditor.

Box 7: Examples for step C1.3 (cont’d)

code smells, or uses of deprecated API elements. Essen-tially prohibited features have the cardinality ![0..0].

C1.4: Specify additional constraints (cf. Box 8).? Which additional constraints are not captured by the

feature hierarchy?! Model additional constraints as features with attached

model queries.Not all constraints can be expressed by the feature

hierarchy or the cardinality constraints alone, e.g., globalconstraints involving features from different parts of thehierarchy. Such additional constraints can be modeledas features, each with an attached model query. Thesefeatures are usually mandatory, meaning that if theattached query evaluates to false or to an empty set, themodeled constraint is violated.

A special case of such global constraints are referentialintegrity constraints. These constraints model correspon-dences between concepts, such as “every instance of agiven concept with some property has a correspondinginstance of another concept with some other property.”Such a constraint can be modeled by a feature with a ref-erence attribute and an attached model query (cf. Box 8).The query retrieves the corresponding instances and the

C1.4: Specify additional constraints

StrutsApplication[1..1] StrutsConfig

[0..*] ActionDecl[0..1] type (String)[1..1] actionImpl (ActionImpl) <where attribute:

qualifiedName equalsTo: ../type>[0..*] ActionImpl

[1..1] qualifiedName (String)

The feature actionImpl models a referential-integrity constraint. The constraintimplies that every correct action declaration (ActionDecl) must have an actionimplementation (ActionImpl). To model this, actionImpl has a referenceattribute of type ActionImpl, that is, the feature represents a reference toan instance of ActionImpl. For each instance of ActionDecl, the attachedmodel query retrieves all instances of ActionImpl whose qualifiedName hasthe same value as type of the ActionDecl instance. Finally, the cardinalityof actionImpl specifies that there should be exactly one such instance ofActionImpl.

Box 8: An example for step C1.4


feature’s cardinality specifies the expected number of thecorresponding instances.

C1.5: Define features with reference attributes to connectconcepts (cf. Box 9).? Is the concept related to other concepts? For example,

connector-oriented concepts are related to the conceptsthey connect.! Define features with reference attributes that can point

to instances of other concepts. Use <baseConcept>annotation to define base-concept references (cf. E3.3) oruse model queries to locate instances of the concepts.

C1.5: Define reference features

WorkbenchPartInteractions[0..*] Part[0..*] AdapterProvider![1..1] provider (Part) <baseConcept>![1..1] providesAdapter

![1..*] adapters (String)[0..*] AdapterRequestor![1..1] requestor (Part) <baseConcept>![1..*] requestsAdapter

[1..1] adapter (String)[0..*] adapterProvider (AdapterProvider) <where

attribute: providesAdapter/adapterscontains: ../adapter>

AdapterRequestor is a connector-oriented concept. It references 1) a partthrough the requestor base concept reference and 2) multiple adapterproviders through the adapterProvider feature. The constraint specifiesthat the values of that reference should be all instances of the conceptAdapterProvider whose list of provided adapters contains the requestedadapter.

Box 9: An example for step C1.5

C2: Create mapping definitions for the features (cf.Box 10).? What code patterns should concept/feature instances

correspond to?! Create mapping definitions to specify the correspon-

dence between concept/feature instances and code pat-terns.

C2.1: Choose a mapping type.! Choose an existing mapping type that defines the

correspondence of the feature to code patterns. Definea new mapping type if needed.

Table 3 presents the mapping types that are used inthe examples in Box 10. The complete set of the 49mapping types used in the exemplar FSMLs can befound elsewhere [5], [22].

Each mapping type can have a number of param-eters. We categorize the parameters into core, reverse,and forward parameters. Core parameters define thecorrespondence, reverse parameters are used only bycode queries (cf. Table 4) to control code pattern match-ing, and forward parameters are used only by codetransformations (cf. Table 5) to control code patterncreation. Some parameters are optional; we present themin square brackets, and we show the default values forthese parameters following the bar symbol (|). In general,the parameters that are present in Table 4 but missing inTable 3 are reverse parameters. Similarly, the parameterspresent in Table 5 but missing in Table 3 are forwardparameters. Furthermore, parameters can be specifiedstatically, i.e., by providing their literal value in mapping

definitions, or dynamically, i.e., by having their valueretrieved from other features during RE, FE, or RTE.

C2.2: Specify static parameter values in the mapping defi-nition.! Specify literal values for parameters that should be

specified statically, such as the name of an interface thatthe feature should correspond to. Extend the mappingtype with new parameters if needed.

C2.3: Specify features for the retrieval of dynamic parametervalues.! For each parameter to be specified dynamically, decide

whether the value should be determined implicitly usingthe context mechanism (explained shortly) or explicitlyusing a path. Ensure that the appropriate parent featuresfrom which values will be retrieved using the contextmechanism exist. Adjust the order of features to makesure that the mapping definitions of features from whichvalues are retrieved are evaluated before the mappingdefinitions using these values are evaluated.

The context mechanism is a convenience mechanismthat obviates the need to explicitly specify the pathto a parent feature from which the value needs to beretrieved. The context mechanism will pick the closestparent feature instance that corresponds to a code pat-tern which is assignment-compatible with the type ofthe parameter. The code pattern is then assigned to theparameter. The context mechanism also allows for reuseof feature model fragments in different places in thehierarchy since explicit references to parent features donot have to be hardwired.

C2.4: Implement missing code queries and transformations.! Implement new queries and transformations for newly

defined mapping types. Extend existing queries andtransformations if they need to better approximate theirmapping types and handle additional code patterns.

Code queries are required for reverse and round-trip engineering. Code transformations are required forforward and round-trip engineering. Existing mappingtypes provide default implementations of code queriesand transformations. Tables 4 and 5 present code queriesand transformations for the mapping types in Table 3.

C3: Add key annotations (cf. Box 11).? How should instances of concepts/features be identi-

fied?Every concept/feature instance should be uniquely

identifiable in an FSM. In the current infrastructure,instances are considered matching if their keys match.Keys are required for RTE because the correspondencebetween the instances from the descriptive, prescriptive,and last-reconciled models is established based on theirkeys. Keys are also needed for establishing traceabilitylinks during RE.

By default, a key for every concept/feature containsthe concept’s/feature’s name; however, since there maybe many instances of the same concept or feature in asingle model, keys need to be enriched with additionalinformation. This enrichment is specified using key anno-tations which are interpreted by the FSML infrastructure


C2: Create mapping definitions for the features

AppletModel <project>[0..*] Applet <class>

[1..1] name (String) <fullyQualifiedName>![1..1] extendsApplet <assignableTo: ’Applet’>[0..*] parameter <callsReceived: ’String getParameter(String)’ location: ’void init()’>[0..*] name (String) <valueOfArg: 1>

[0..1] providesParamInfo <methods: ’String[][] getParameterInfo()’>[1..1] providesInfoForParameters <constraint: ../parameter implies: ../providesParameterInfo>

Table 3 presents selected mapping types used in the example above. Values of some mapping type parameters were specified statically. Some parameters were leftunspecified and their values will be retrieved using the context mechanism. For example, let’s consider the mapping definition <assignableTo: ’Applet’>that uses the assignableTo: mapping type. The mapping type defines two parameters: c and t. In the mapping definition, only the value of the parameter tis set to ’Applet’. The parameter c is left unspecified leaving the determination of its value to the context mechanism during the FSML execution. The contextmechanism will use the Java class that the closest parent feature corresponds to as the value of the parameter c. In our example, c will be set to the Java class thatthe concept instance Applet corresponds to. Analogously, the value of the parameter mc in the mapping definition <valueOfArg: 1> will be the method callthat the feature parameter corresponds to. Target features for the retrieval of the code patterns for dynamic parameters can be always explicitly specified usingpath expressions, such as, ../parameter.

The semantics of the above metamodel is as follows. The model root AppletModel always has to correspond to the entire application (project). Each instance ofthe concept Applet corresponds to a Java class. Value of the feature name is the fully qualified name of the Java class. Instance of the feature extendsApplet willbe present only if the Java class is assignable to the Applet class. Because the feature extendsApplet is an essential feature of the concept Applet, the instanceof the concept cannot correspond to a class that is not assignable to the class Applet. Each instance of the feature parameter corresponds to a method call togetParameter received by an object of the class. Each value of the subfeature name of parameter corresponds to the value of the first argument of the methodcall. An instance of providesParamInfo corresponds to an implemented or overridden method getParameterInfo by the class.

An example of a forward parameter is location, used in the mapping definition for the feature parameter. The parameter specifies that the code transformationshould create the method call in the body of the method init.

Box 10: Examples for activity C2

TABLE 3Selected and simplified mapping types for structural and behavioural code patterns in Java

Structural Pattern Expres-sion Structural Element(s) Matched

project matches a projectclass matches a Java classc fullyQualifiedName matches the fully qualified name of the class cc assignableTo: t matches if objects of the class c are assignable to the type tc methods: s matches methods with signature s that are implemented or overridden (but not inherited) by the class c

Behavioural Pattern Ex-pression Run-time Event Pattern(s) Matched

c callsReceived: s matches method calls to methods with the signature s received by objects assignable to the class cmc valueOfArg: i matches run-time values of the ith argument of the method call mc

TABLE 4Code queries for the mapping types from Table 3

Code Query Expression |Defaults Result

c getAssignableTo: t [con-crete: e] | e=true

True if the class c is assignable to the type t. In essential mode, set of classes assignable to the type t, limited to concreteclasses only if e=true. (The essential mode means executing the query for an essential feature. It is an optimization used to return onlyclasses that satisfy the essential feature and thus avoid checking all classes in the system [5, s. 2.5.2].)

c getFullyQualifiedName A fully qualified name of the class c.c getMethods: s A set of methods of signature s in the class c. The signature s may contain * for the method name.

c getCallsReceivedTI: sA set of method calls with the signature s, such that the receiver of each call is assignable to the type c. In the case whenthe type of the receiver is more general then the type c, the query traverses the receiver’s dataflow graph backwards to inferits more specific type.

mc getArgValConstantProp: i A set of values of the ith argument of the method call mc retrieved using interprocedural constant propagation limited inscope to the class that contains the method call.

when computing keys for instances.

! If a given concept/feature can only have a singleinstance in the entire model, do nothing. Otherwise,consider how the instances should be distinguished fromeach other by including keys or values of other instances.

If a value of a subfeature should be included in the key,put the annotation key on that subfeature. If the key ofthe parent instance should be included in the key, putthe annotation parentKey on the concept/feature. If theconcept/feature can be instantiated multiple times undera single parent instance, put the annotation indexKey

to include the index of the instance in the sequence of allinstances which are children of the same parent instance.

The annotation key should be used on features thatcontain distinguishing values, such as fully qualifiedname and field or method name. The annotationsparentKey and indexKey can be used in conjunction,if necessary.

C4: Add support for new use cases (cf. Box 12).? Which additional use cases can be added?

Usually, the evolution of mapping types, code queries,and transformations is driven by the need to achieve


TABLE 5Code transformations for the mapping types from Table 3

Code Transformation Expres-sion | Defaults Result

p addClass: n [in: q] | q=” Creates a compilation unit with a class declaration named n in package q. Retrieves values of the parameters n and q fromsubfeatures with mapping types className and qualifier or fullyQualifiedName.

c addAssignableTo: t [concrete:e] | e=true

If t is an interface, adds a c implements t superinterface declaration or adds t to the existing list of implemented interfaces.If t is a class, adds a c extends t superclass declaration. If e=true, adds implementations of the unimplemented methodsof the superinterface or an abstract superclass.

c addMethod: s [name: n]Adds a method declaration of signature s in the class c. If method name n is given, replaces the name from the signature swith n. If the signature contains * for the method name, the parameter n is mandatory. Retrieves the value of the parametern from a feature with the mapping type methods.

c addCallTo: s [receiverExpr: r]location: l [position: p] | r=”,p=after

Creates a method call to a method with the signature s with the receiver expression r in the method of signature l of theclass c at the position p ∈ {before, after}.

mc addArgVal: i [values: v] Adds values of the ith argument of the method call mc. Adds a literal for a single value. For multiple values creates avariable and multiple assignments with values v.

C3: Add key annotations

AppletModel[0..*] Applet

[1..1] name (String) |key|![1..1] extendsApplet |parentKey|

[0..1] extendsJApplet |parentKey|[0..*] parameter |parentKey,indexKey|[0..*] name (String)

By default, a key for every feature contains the feature’s name. According tothe key annotations, the key for Applet will also contain the applet’s fullyqualified name; for extendsApplet, it will contain the key of Applet; andfor parameter, it will contain the key of Applet and an index of the instancein the list of parameters.

The annotation indexKey should be used as rarely as possible because it makesthe key very sensitive to the position of the given feature in the list of instances.This position changes easily when the code is rearranged.

Box 11: An example for activity C3

the value proposition of a language. Often, however, itis possible to add support for new use cases with verylittle cost.

C4: Add support for new use cases

Initially Struts FSML was not required to support round-trip engineering; how-ever, since all required code transformations for the mapping types used in thelanguage were available, adding support for round-trip engineering amountedto setting forward parameters in mapping definitions.

Box 12: An example for activity C4

C5: Build a test suite (cf. Box 13).? What code patterns/feature configurations should the

language support?! Create completion code/feature configurations that

are in scope of the language. Use the test suite to testthe use cases.

The code should have both correct and incorrect pat-terns with respect to the mapping definitions. The formershould be matched by code queries and produced bycode transformations. The latter should be missed bycode queries.

Feature models typically have very large number ofpossible configurations and it is not possible to buildcode that tests each configuration; however, there issome degree of orthogonality in the feature models,meaning that not all features are related with eachother. This facilitates testing parts of the feature model

separately, thus, greatly reducing the number of config-urations that have to be tested.

5.5 TransitionIn Transition, the language is extensively analyzed,tested, and refined until the required quality and use-fulness are achieved. No more new concepts and fea-tures are added (i.e., feature freeze in Figure 7); however,modifications to the metamodel required for fixing errorsare allowed. The purpose of this phase is to deliver aworking end product of the iteration. The phase and theiteration end when the language can deliver the valueproposition established in the inception phase. We groupthis phase’s activities by the qualities they evaluate (cf.Section 4).

5.5.1 Syntactic qualityWe omit details of syntactic quality evaluation (activityT1) since it can be performed by the tools (e.g., syntaxchecks).

5.5.2 Semantic qualityThe semantic quality of an FSML is determined by thefeasible validity and completeness of the API usagesencoded in its metamodel with respect to the FSMLscope.

T2: Perform semantics evaluation.? Is the feature model satisfiable? Does the FSML com-

pletely and correctly model the relevant API usages? Isthe implementation of code queries and transformationscorrect? What is the precision and recall of the codequeries? Does the generated code compile? Is it com-plete or skeletal? Are the code patterns created by codetransformations matched by code queries?

T2.1: Check feature model satisfiability. Verify that the setof legal feature configurations is non-empty and thateach feature is instantiated in some configuration sat-isfying the essential constraints. The latter requirementacknowledges the possibility of features used only todetect incorrect API usages (prohibited features). Correctadditional constraints that may cause contradictions (cf.C1.4).


C5: Build a test suiteTest codepublic class MyApplet extends Applet {

public void init() {String color = getParameter("color");String paramName = "width";if (...)

paramName = "height";...String dim = getParameter(paramName);

}public void start() { ... }public String[][] getParameterInfo() {return ...;

}}

Framework-specific model[1] Applet

[1] name (’MyApplet’)[1] extendsApplet[1] lifecycleMethods[1] init[1] start

[1] parameter[1] name (’color’)

[1] parameter[1] name (’width’)[1] name (’height’)

[1] providesParamInfo[1] infoForParams

Generated code for the modelpublic class MyApplet extends Applet {

public void init() {getParameter("color");String param0 = "width";param0 = "height";getParameter(param0);

}public void start() {}public String[][] getParameterInfo(){return null;

}}

The above test code can be used for testing the reverse engineering use case of the Applet FSML. The FSM is a result of reverse engineering the test code. Themodel contains an instance of the concept Applet and instances of its features. The instances are created for the underlined code patterns matched by the codequeries.

The framework-specific model can be used for testing the forward engineering use case. The code generated for the model is the result of the execution of codetransformations for each feature instance.

Round-trip engineering use case can be tested by performing changes to the code or to the model and reconciling the differences. Round-trip engineering firstreverse engineers the descriptive model from the current code and compares it with the prescriptive model. Automatic reconciliation of changes is guided by theresult of the comparison and developer’s decisions.

Box 13: Examples for activity C5

T2.2: Check relevant API usages T2.3: Evaluate mapping definitions

AppletModel <project>[0..*] Applet <class>

[0..*] parameter <callsReceived: ’String Applet.getParameter(String)’ location: ’void init()’>[0..*] name (String) <valueOfArg: 1>

[0..*] Thread <field>[1..1] InitializesThread!<1-1>[0..1] initializesThreadWithRunnable <assignedNew: ’void Thread(Runnable)’ position: ’after’ loca-

tion: ’void init()’>[0..1] initializesWithThreadSubclass <assignedNew: initializer: true subtypeOf: ’Thread’>

[0..*] singleTaskThread <callsTo: ’void Thread(Runnable)’ statement: true>

During the evaluation of the precision and recall of code queries, we analyzed a large body of sample applications and noticed a few additional variants forimplementing features that were not included in the FSMLs.

For example, applet threads can also be initialized by subclassing the class Thread and directly overriding the method run (this variant is also explicitly mentionedin the API). We refined the Applet FSML by inserting a feature group <1-1> and adding new features starting with initializesWithThreadSubclass.

We also noticed, that some applets used single-task threads that were not assigned to a field but were simply instantiated in an individual statement (regularthreads are instantiated in the right hand side of an assignment to a field). To support single-task threads, we added new features, starting from the featuresingleTaskThread. We also had to extend the mapping type callsTo by introducing a new parameter statement that specifies whether only method/constructorcalls that are statements should be matched by the code query.

T2.4: Evaluate the implementation of code queries and transformations

Similarly, we refined code transformations to enable generating different variants. During code generation, certain additional decisions have to be made and theseare specified using the forward parameters of the mapping types.

For example, the code transformation for the mapping type assignNew creates an assignment to a field in which the right hand side is a constructor call of thegiven signature. Such an assignment can be created in two ways: as an individual statement in a method body or as a field initializer. The mapping definition of thefeature initializesThreadWithRunnable uses the first variant, and the assignment will be generated at the end of the method init. The mapping definitionof the feature initializesWithThreadSubclass uses the second variant by setting the value of the forward parameter initializer to true.

We first developed simple code queries for Java that employed simple approximations of behavioural code patterns. We then evaluated the precision and recallof those code queries [40]. Although the precision and recall were very high, we learned that the code queries can be improved without incurring a prohibitiveincrease in the execution time. We also implemented and evaluated the precision and recall of the new and more sophisticated code queries [14].

The feature models still had to be adjusted to support the more powerful code queries. For example, a simple code query for the mapping type argVal wasreturning a value of a method call argument only if the argument was a constant or a literal. Therefore, it was sufficient for the feature name to have the cardinality[0..1]. The new code query performs constant propagation if the argument of a method call is a variable. Because constant propagation may return multiple potentialvalues of the variable, the cardinality of the feature name had to be changed to [0..*].

Box 14: Examples for steps T2.2, T2.3, and T2.4

T2.2: Check relevant API usages (cf. Box 14). Createsample feature configurations and verify that all legalfeature configurations represent correct API usages andthat illegal feature configurations represent incorrect APIusages (validity). Verify that every relevant API usage isrepresented in the feature model (feasible completeness).Use the API definition, sample applications, and bestpractices to identify missing API usages. Extend thefeature models and mapping definitions as needed.

T2.3: Evaluate mapping definitions (cf. Box 14). Verify thatthe mapping definitions correctly represent the corre-spondence between feature instances and code patternsas required by the API usages in scope.

T2.4: Evaluate the implementation of code queries andtransformations (cf. Box 14). Refine code queries andtransformations to improve the semantic quality of theretrieved models (precision and recall) and the generatedcode (correctness and completeness). Adjust the feature


T3.1: Evaluate model/metamodel comprehension, creation, and

modification

Screenshot: concrete syntax of an FSM expressed using Applet FSML.

Examples of cognitive dimensions evaluation for exemplar FSMLs.

Closeness of mapping. The main purpose of the EJB FSML is to present a run-time configuration view by merging information from the Java code and theXML deployment descriptors, which is very difficult to see both in the codeand in an FSM reverse engineered using EJB FSML. Therefore, to improve thepragmatic quality of the retrieved EJB FSML models with respect to the closenessof mapping, we implemented a model transformation that applies inference rulesto the extracted model and computes a run-time configuration of the EJB projectand thus making the run-time configuration explicit [22].

Consistency. Different kinds of listeners in Applet FSML are similar in structure.Learning one kind of listener (e.g., mouse listener) allows the user to easily“guess” how to use other kinds of listeners (e.g., key listener).

Terseness. All FSMs are terse because they only contain information relevant totheir value proposition and abstract away unrelated information from the code.Still, the models can be large making it difficult to locate needed information.However, due to their hierarchical nature, FSMs can be explored top-down byexpanding certain branches of the tree while other branches remain collapsed.FSMs also do not contain all necessary information needed for code creationbecause some information is encoded in the mapping definitions as defaults.

Additionally, not all features are presented as a feature hierarchy. Features withattributes are presented as properties shown in a separate view (cf. screenshot,lower right) of the features shown in the hierarchy. Descriptive labels of hierarchyfeatures also contain values of the property features that are not visible in thehierarchy.

Error proneness. Our model editors are structured, which reduces error proneness.It is still, however, possible to construct an incorrect model. An automatic andgeneric model validation implemented in the infrastructure can be used to finderrors in the model, e.g. violations of additional constraints.

Hard mental operations. In FSMs in Struts FSML, it was difficult to find an actionimplementation (in Java) for a given action declaration (in XML). Therefore, areferential integrity constraint was introduced that allows a developer to quicklynavigate to the implementation or determining that it is yet missing.

Box 15: Examples for step T3.1

model to the refined queries and transformations. Ver-ify that the queries and transformations correctly useall mapping type parameters. Verify that code patternscreated by code transformations are matched by codequeries for the same mapping types.

5.5.3 Pragmatic quality

The pragmatic quality of an FSML needs to be evalu-ated at two levels: the level of FSMs and the FSML-metamodel level. Thus, the evaluation involves deter-mining the feasible comprehension, creation, and modi-fication of FSMs and the FSML metamodel.

T3: Perform pragmatics evaluation.? Is the model/metamodel easy to understand, create,

and modify?

T3.1: Evaluate model/metamodel comprehension, creation, and

modification

Hidden dependencies. The number of features representing constraints that crosscutthe feature hierarchy and referential integrity constrains is very low relatively tothe total number of features (WPI FSML: 5/71, Struts FSML: 5/47, Applet FSML:1/75, EJB FSML: 4/73) and therefore number of hidden dependencies is low.

Pragmatic quality of FSMs with respect to hidden dependencies is also improvedby offering traceability links (cf. screenshot, lower left part) between the modeland the code that allow the developer to immediately jump to code patterns thatimplement a given feature.

Role expressiveness. To improve role expressiveness (as compared to the genericfeature configuration from Box 13), we developed simple concrete syntaxes thatutilize descriptive labels for features and icons (cf. screenshot).

Viscosity. Removing or modifying features involved in constraints and referencedfrom other features may trigger constraint violations in remote parts of the model.In out FSM editors, model validator can be used to asses the impact of changes.Later, the changes can also be undone.

Since code pattern removal is not implemented, removal of a feature in the modelrequires manual removal of a corresponding code pattern.

Visibility. A model expressed using WPI FSML shows both local and externalworkbench parts. External parts are those visible in the class path of the projectand they cannot be modified. Therefore, to improve visibility when working withlocal parts, we implemented simple model filtering that hides all external parts.

Box 16: Examples for step T3.1 (cont’d)

T3.1: Evaluate model/metamodel comprehension, creation,and modification (cf. Boxes 15, 16). Evaluate closenessof mapping, consistency, error-proneness, hard mentaloperations, hidden dependencies, role-expressiveness,viscosity, and visibility dimensions for sample modelingtasks by asking questions similar to those included inthe Cognitive Dimensions questionnaire [41], e.g., “Whatkind of things are more difficult to see or find? Do somekinds of mistake seem particularly common or easyto make?” Use readily understood feature names. Useappropriate concrete syntax, e.g., characteristic icons andvisualization of relationships (designing concrete syntaxis outside of the scope of the current method). Considermodel filtering, transformation, and analysis to displaydifferent views of the model for different comprehensiontasks.

For the metamodel, evaluate the decomposition ofconcepts into features and metamodel modularity (e.g.,use of references and constraints). Detect redundanciesand use references and feature inheritance where appro-priate.

T3.2: Evaluate support for the required use cases (cf.Box 17). Verify that the language can be used to performthe required use cases. Use the test suite to execute therequired tasks.

5.5.4 Organizational qualityThe organizational quality of a FSM or a FSML is theextent to which the model or language fulfills the goalsof the users in an organization.

T4: Perform organizational evaluation (cf. Box 18).? Is the language fulfilling its purpose and providing

the value as expected? Is the retrieved model usefulfor application developers? Is the generated code usefulfor application developers? How much more work doapplication developers need to invest to get the codeworking?


T3.2: Evaluate support for the required use cases

We performed extensive evaluation of reverse engineering [14] and testedforward and round-trip engineering [5, ch. 5, 6]. We evaluated the precision andrecall of code queries by reverse engineering a large set of applications usingWPI, Struts, and Applet FSMLs, and manually identified false positives and falsenegatives of code queries for behavioural Java code patterns (code queries forstructural code patterns have 100% precision and recall). The results showedweighted average precision of 100% and recall of 96% for the behavioural codequeries.

Tests of forward engineering using WPI and Applet FSMLs showed that the codecreated using code transformations is correct with respect to the respective APIs.We verified that automatically by reverse engineering the generated code andcomparing the original and the extracted models, which were equivalent modulofeature ordering and inherited behaviour from superclasses.

Tests of round-trip engineering (RTE) using WPI and Applet FSMLs showedthat 1) the code created in multiple iterations using RTE was equivalent tothe code created using forward engineering; and 2) the model created inmultiple iterations using RTE was equivalent to the model created using reverseengineering.

All these evaluations also (indirectly) confirmed the correctness of reverse,forward, and round-trip engineering algorithms and infrastructure support.

Finally, Cheema tested migration by semi-automatically migrating a real-worldStruts-based application with 20 KLOC of Java to JSF [25]. The original codewas first reverse engineered using the first version of the Struts FSML. Next,a specialized migration code generator was used to produce JSF compliantcompletion code. The code generator was guided by the model and it was capableof migrating not only the completion code, but also the bodies of actions. Themigration did not include UI code.

Box 17: Examples for step T3.2

! Perform user studies to assess whether the languagedelivers its value proposition.

T4: Perform organizational evaluation

None of the exemplar FSMLs has been released to the public yet. Evaluationmethods such as controlled experiment, action research, or survey can be used toevaluate the organizational quality of FSMLs.

Organizational quality can also be assessed using indirect measures, which arelikely less expensive to obtain than performing user studies. For example, toevaluate the claim that framework-specific models modularize each conceptsof interest as a single feature hierarchy and the corresponding code patternsare usually scattered over the completion code, we computed two metrics:concern diffusion over components (CDC) and concern diffusion over operations(CDO) [5, ch. 7], where each concern aggregates all features related to thesame Java class, one implementing a view, an editor, an applet, or an actionin our case. We computed the metrics on a large set of example applicationsand results showed that, indeed, the code patterns that implement the conceptsare highly scattered. 70% of Eclipse editors and views are implemented in twoor more components and 55% of them in three or more components, wherecomponents are individual classes and XML documents. 60% of Struts actionsare implemented in two or more components. Only 10% of Java applets areimplemented in two or more components; however, the Applet FSML does notconsider applet declarations in HTML files, which adds another component.Finally, at least 55% of all concerns are implemented in two or more operations.These indirect measures indicate that FSMLs can potentially reduce the effortof code comprehension by providing traceability to the scattered code patternsbecause framework-specific models present related features in a single hierarchyand thus provide an alternative to the way the code is decomposed.

Box 18: Examples for activity T4

6 METHOD JUSTIFICATION

We justify the presented method by tracing its origins tothe base approaches, which are well-established, and tothe actual experience of developing the four exemplarFSMLs (cf. Figure 6). Our discussion accounts for theorigin of each step and also gives insight on how thesteps were scheduled and executed during the actualFSML development. As expected, the reality of thatdevelopment was more complex and exploratory thanthe method communicates or needs to communicate [42];

however, this section gives a more complete picture ofthe actual development and it provides ideas of how themethod may be specialized when applied.

6.1 Division of the lifecycle into four phasesThe four lifecycle phases, Inception, Elaboration, Con-struction, and Transition, were borrowed from the Uni-fied Process. Each FSML had a clear Inception phase,in which the goals and the scope of the language weredefined. All goals of WPI and Applet were set at thebeginning of the development; the support for codecreation and evolution were only added later; however,the goals for Struts and EJB FSMLs shifted or wereexpanded during development (cf. Table 1). Thus, theInception phase was revisited for Struts and EJB FSMLsin later iterations.

The evaluation of the languages, particularly testingactivities, were done continuously after each changeto the metamodel or the infrastructure; however, therewere a few periods of extensive evaluation, such as thestudy of RE or evaluating EJB antipattern detection onopen-source applications. Major parts of these evaluationperiods can be viewed as Transition.

The distinction between Elaboration and Constructionwas more subtle, but it reflected the fact that some initialconstruction of the feature models took place beforecreating any mapping definitions and detailed features.We classified the creation of these initial feature modelsas Elaboration. These initial feature models were fairlyshallow, at most one or two levels below the modelroot. Some grouping features were created at level twoduring elaboration; additional ones were created later inConstruction as needed. The feature models were refinedand their mapping definitions were created later, and weclassified these activities as Construction.

6.2 Use-case-driven developmentSupport for use cases was added incrementally, as pre-scribed by the method. Code understanding (U) was theprimary use case for each exemplar FSML except forthe Struts FSML, which was initially built to supportmigration (M). Code creation (C) and code evolution(E) were considered for Applet and WPI FSMLs fromthe beginning, but the actual implementation of the usecases was sequenced. The FSML metamodel was firstbuilt for U and tested. Then it was refined for C andtested. Then it was further refined for E and tested. Thenecessary refinements were not extensive and they weremostly additive, such as providing additional parame-ters for code transformations in mapping definitions, oradding detailed features representing implementationsvariants. When transitioning from C to E, some keyshad to be verified and adjusted in order to achievethe desired model matching. Furthermore, some codetransformations needed adjustment and, consequently,additional parameters had to be provided in mappingdefinitions. The fact that these refinements were not


extensive and mostly additive is not surprising since themapping definitions define the semantics of the featuresregardless whether they are realized by queries for REor transformations for FE or RTE. For Struts, the initiallanguage designed for M was first redesigned to supportU because the focus of the language shifted. The supportfor referential integrity checking (RIC) was subsequentlyadded by mostly creating new features with referenceattributes and appropriate constraints. At last, supportfor C was added to Struts opportunistically, mostlybecause all the mapping types used by the languagewere already supported by existing transformations. TheEJB FSML development started with U, followed by RIC(similar to Struts) and API constraint checking (ACC).The support for model analysis (MA) was added last.Again changes to the EJB FSML through these iterationswere mostly additive.

6.3 Tracing activities and steps to the developmentof the exemplar FSMLsAll activities and steps presented in the previous section,except step T3.1 and activity T4, were performed duringthe development of the exemplar FSMLs as illustrated bythe examples in Boxes 1–17. Step T3.1 and activity T4,which require user studies, were added to the methodfor completeness as suggested by the model qualityframework. All of the performed steps were executedfor every exemplar FSML; however, the step execu-tion varied among the FSMLs. For example, E2 distin-guishes among component-oriented, connector-oriented,and port-oriented concepts. All exemplar FSMLs havecomponent-oriented concepts; only WPI, EJB, and StrutsFSMLs have connector-oriented concepts; and only EJBFSML has port-oriented concepts. Furthermore, steps re-lated to queries and transformations, i.e., C2.4 and T2.4,would be executed differently depending on whether thegiven FSML needed transformations to support forwardor round-trip engineering or not. In particular, all exem-plar FSMLs support forward engineering except the EJBFSML, which did not require this capability to achieveits value proposition.

6.4 Tracing activities and steps to the base ap-proachesAll of the steps in Inception and Elaboration can beseen as specializations of the generic steps given inthe Feature Modeling Process [17, ch. 4], which is anextension of FODA [7]. Some steps in Construction, suchas defining feature nesting (C1.2), specifying cardinalityconstraints (C1.3), and specifying additional constraints(C1.4), are specializations of generic feature modelingsteps to the FSML context; however, the steps in activitiesC2-C5 are specific to FSMLs and do not have theircounterparts in FODA. All of the steps in Transitionare classified according to the quality criteria derivedfrom the model quality framework and the CognitiveDimensions discussed in Section 4.

6.5 Iterative development and scheduling of activi-ties and steps

The FSMLs were developed iteratively. All of themexcept EJB were developed concurrently with the in-frastructure; thus, the actual development process wasmore complex and exploratory than what the methodsuggests.

We can distinguish five major periods in this develop-ment: 1) development of the first WPI FSML prototypeand later Struts FSML prototype with code reuse fromWPI; 2) development of Applet FSML with a fullydeclarative metamodel that was driving the develop-ment of the generic FSML infrastructure, followed bythe migration of WPI and Struts FSMLs to the infras-tructure; 3) the first RE evaluation for Applet, WPI, andStruts FSMLs [40]; 4) development of the EJB FSML andthe second RE evaluation for Applet, WPI, and StrutsFSMLs [14]; 5) the FE & RTE evaluation for Applet andWPI FSMLs [5].

Each of these periods involved multiple iterations.Iterations were not timeboxed: iterations involving in-frastructure construction and implementation of codequeries and transformations were longer; iterations in-volving mostly metamodel construction were shorter.The evaluation periods included both Construction andTransition phases since the FSMLs were refined in thecourse of the evaluations.

The development of the EJB FSML resembled closelythe process prescribed by the method since most ofthe required mapping types (including the queries andtransformations) and the infrastructure were alreadypresent. The EJB FSML development had five itera-tions: 1) development of an initial, basic version of thelanguage, which included the development of missingcode queries for Java 5 annotations; 2) adding supportfor XML deployment descriptors and extension of codequeries for XML; 3) broadening the horizontal scope tocover more cases related to override rules; 4) develop-ment of model analysis and adding features required bythe model analysis, and 5) development of EJB antipat-tern detection and adding required features.

In general, the iterations were not uniform as not everystep, every activity, not even every phase of the methodwere performed in each iteration. Usually, adding newfeatures was driving required extensions to the 1) algo-rithms and infrastructure; 2) mapping types; and 3) codequeries and transformations. These extensions requiredcontinuous testing.

Closely related concepts were added together, otherconcepts were added and decomposed in depth oneby one. Features were always added while keepingtheir mapping definitions in mind and specifying themlater: we found it difficult to consider features withoutthinking about their mapping definitions at the sametime. The reason was that mapping definitions oftenreferred to other features through the context mechanismor explicit paths, so we had to understand how to place


and decompose new features in relation to the existingones.

The evolution of the metamodel was continuous.There were a few significant refactorings of the meta-models that invalidated existing models; however, mostchanges were additive and existing models were au-tomatically migrated. The main reasons for metamodelevolution were 1) adding new feature groups and newimplementation variants; and 2) adjusting to new capa-bilities of code queries and transformations. In additionto continuous testing in Construction, the evaluationperiods involved review of metamodel structure andextensive testing of the mappings, queries, and trans-formations.

6.6 Development effortThe effort required to develop a new FSML dependsmostly on the availability of the required mapping typesand their implementations. Assuming that all requiredmapping types are implemented and the developer isfamiliar both with the framework and the FSML method,a new FSML can be built in the order of days thanks tothe declarative nature of FSML definition. Implementingnew code queries and transformations and any neces-sary infrastructure extensions can be time consuming;however, Master’s students without previous knowledgeof the target framework and without experience in theFSML approach were capable of building an FSMLwithin weeks, which included implementing missingmapping types. These students had access to the firstauthor to ask questions about the approach and theinfrastructure since a description of the method did notexist at that time.

7 DISCUSSION AND FUTURE WORK

In the spirit of the design science paradigm (cf. Sec-tion 2), we now turn to discuss the adherence of ourresearch approach to the paradigm and the maturityand limitations of the individual elements of the FSMLapproach.

Hevner et al. proposed seven guidelines that shouldbe followed when applying the design science (DS)paradigm [8]. We list these guidelines and briefly discussto what extent our research adheres to them.

Design as artifact. DS research must produce one or moreartifacts in the form of a construct, a model, a method, or aninstantiation. Our research led to the new construct ofFSMLs, four exemplar FSMLs as instantiations, and aFSML engineering method.

Problem relevance. The produced artifacts must addressan important and relevant problem with respect to a con-stituent community. Difficulties of framework API usagerepresent a practical problem [43], [44], and its relevanceis highlighted by a plethora of approaches designed toaddress it (cf. Section 8).

Design evaluation. The utility and quality of the artifactsmust be demonstrated through evaluation. We established

the criteria for evaluating FSMLs in Section 4. The exem-plar FSMLs were evaluated as prescribed, modulo userstudies. The FSML engineering method has not beenevaluated. We return to the topic of evaluation in thefollowing two subsections.

Research contributions. DS research must yield newcontributions related the artifacts, foundations, or methodolo-gies. We claim the exemplars and the FSMF as artifact-related contributions since they address the limitationsof other approaches as argued in Section 8; however,experimental comparison is future work.

Research rigor. DS requires the application of rigorousmethods in both artifact construction and evaluation. TheFSMF has been implemented in the form of a genericinfrastructure; the infrastructure has been extensivelytested using the exemplars; and the exemplars havebeen carefully evaluated, e.g., using precision and recall.The engineering method is based on well-establishedapproaches, which allowed us to systematically andthoroughly elicit the modeling patterns and strategiesused to construct the exemplars. A formalization of theFSMF, however, is still required.

Design as a search process. DS research is inherentlyiterative. FSMLs, FSMF, and the method were constructedand evaluated iteratively. The results of the evaluationswere used as feedback to improve the artifacts.

Communication of research. DS research must be com-municated to both technical and managerial audiences. Toaddress the needs of managerial audiences, we presentedexamples of use cases and value propositions and dis-cussed development effort. The artifacts are also docu-mented in sufficient detail to allow a technical audienceto recreate them [5], [14].

In the following sections, we elaborate on the thematurity of the different elements of the FSML approachand their limitations and suggest future work.

7.1 Exemplar FSMLs

The exemplar FSMLs target four widely used Java frame-works. The FSMLs are declaratively specified and theirmetamodels are interpreted by the infrastructure. Re-verse engineering was extensively evaluated for WPI,Struts, and Applet FSMLs [14]. Forward engineering andround-trip engineering were tested for WPI and AppletFSMLs [5]. Use cases U, RIC, ACC, MA, C, E, and Mwere tested by FSML developers, but the results were notpublished. The use case AU was performed by severalmembers of our research group who learned the FSMLapproach.

The key limitations of the exemplar FSMLs are asfollows.

Lack of user studies. The FSMLs need to be evaluatedin user studies. Ultimately, their usefulness needs to beconfirmed in practice. To this end, user communitiesfor these or additional languages should be established.The effectiveness of the languages could then be studiedusing surveys, case studies, or action research.


Limited generality of the exemplars. The exemplarFSMLs target widely used Java frameworks with differ-ent characteristics; however, the exemplar FSMLs willonly be representative for those API concepts of otherframeworks that can be modeled using the same map-ping types as the ones used in the exemplars. We willreturn to this issue shortly.

7.2 FSML engineering methodThe presented FSML engineering method was con-structed by specializing the base approaches to theFSML context and by generalizing from the experienceof building the four exemplars. The method was firstpresented in the related Ph.D. thesis [5] and significantlyrevised and extended in this paper, most importantly byapplying the model quality and Cognitive Dimensionsframeworks.

The key limitations of the method are as follows.Created by retrospection. Since we do not have a

detailed record of each language’s development history,we relied on retrospection and we might have missedsome details. We addressed this threat by looking at thecurrent [5] and past [40], [45] versions of the FSMLs.

Parallel infrastructure development. WPI, Struts, andApplet FSMLs were developed in parallel to the de-velopment of the FSML infrastructure; therefore, theirdevelopment might not be representative. We addressedthis threat by providing more detail on the actual de-velopment and justifying our method design in Sec-tion 6. Also, as the number of FSMLs built increases andthe foundation matures, the number of changes to theFSML infrastructure required to support new require-ments will likely decrease. We observed that effect inthe development of the four exemplars. In particular,the development of the EJB FSML required much fewerinfrastructure extensions than the previous exemplars.

Lack of user studies. The FSML engineering methodneeds to be tested by third-party users. To that end, weenvision conducting an exploratory experiment in whichsubjects would apply the method to a well defined partof a framework’s API. The goal of the experiment wouldbe to understand the questions and issues the subjectsfaced during the method application and how thesequestions and issues impact the quality of the producedFSMLs.

7.3 FSMFThe Framework-Specific Modeling Foundation (FSMF)was described elsewhere [5]. The generic FSML infras-tructure is the implementation of the foundation. Theinfrastructure implements the means used by the usecases and it supports the four exemplar FSMLs. Themapping types are implemented by code queries andtransformations as pluggable mapping interpreters.

The key limitations of the FSMF are as follows.Generality of the mapping types. The set of mapping

types we developed can be used to model a great variety

of API concepts, but it is certainly not exhaustive. Thus,the creation of new mapping types is considered as apart of the method. The set of mapping types that can besupported is limited by the ability to implement the cor-responding code queries and transformations. In partic-ular, implementing effective queries and transformationsfor highly dynamic code patterns, such as complex objectstructures typically required by graphical UI frameworks(e.g., Java Swing), may be difficult or infeasible. Codequeries for such code patterns may require sophisticatedstatic analyses, which would significantly increase thetime of RE and RTE or reduce the semantic quality (i.e.,precision and recall) of the retrieved models. Further-more, the existing mapping types only support Java andXML; however, mapping types for other languages, suchas C/C++ or Ruby, could be implemented.

Code pattern addition only. The current support forRTE is limited in the model-to-code direction to au-tomatic code pattern addition only. Manual additions,modifications, and removals in the code are automati-cally reflected in the corresponding FSMs upon synchro-nization. We experimented with automatic commenting-out of the code that corresponds to the concept andfeature instances removed from the related FSM; how-ever, this capability needs to be further developed andstudied. Similarly, automatic code modification, such asrefactoring one implementation variant into another oneto reflect the corresponding change in the related FSM,needs further investigation.

Fixed locations for code pattern addition. A challengein automatic forward and round-trip engineering is thechoice of the locations for code pattern addition, i.e., newcode patterns are added to code locations predefinedin mapping definitions, which may require applicationdevelopers to move code patterns to suitable locations.Lee et al. proposed and prototyped a number of newFSML-based means [46] to address this challenge. Thesemeans can be invoked directly in the source code, butwith an FSM hidden in the background or shown on theside. Framework-specific content assist can be used to addimplementations of new concept or feature instances di-rectly in the code; framework-specific keyword programmingprovides keyword-programming support [47] based onFSML feature names; framework-specific content outlinepresents an FSM of the currently opened source file; andframework-specific error highlighting marks API violationsdetected through an FSM directly in the source code.These new means required extensions to the FSML in-frastructure, such as reverse navigability from code toFSM, specialized FSML metamodel interpretation, andextensions to code transformations.

Support for existing code. The main difference be-tween FE and RTE, which both only add code patterns, isthat in FE the code is created from scratch and in RTE thecode is added to existing user’s code. In FE, the FSMLdeveloper can easily predict the resulting code since codetransformations will be executed for every feature. InRTE, some features may be already implemented in the


application and the added features must be seamlesslyintegrated. Currently, the same code transformations areused in both forward and round-trip engineering andtherefore the quality of the code created in RTE maybe lower than in FE. Also, the tests of RTE that weperformed [5] did not involve third party applications.

Tensions between use cases. Currently, the methodsuggests that a single FSML metamodel can be usedin many use cases, which is certainly the case withall exemplar FSMLs. In general, however, this approachmight not always work because achieving high qualityin one use case may conceivably reduce the qualityof another use case or even render the other use caseinfeasible. The method prescribes incremental additionof support for new use cases which may require somerestructuring of the metamodel. In our experience, thiswas never a problem since adding support for a new usecase typically required only additions to the metamodel.We always started with the RE capability that only hadfeatures required for code comprehension (U). AddingFE, needed for code creation (C), typically requiredadding new subfeatures with information required bycode transformations, such as field and method names.Adding RIC and ACC typically required adding featureswith reference attributes and features that represent con-straints. Adding model analysis (MA) required creatinga new metamodel for the view (i.e., the result of theanalysis) and implementing an external model transfor-mation. Adding migration (M) required implementinga specialized code transformation. Adding RTE afterFE, needed for evolution (E), only required adding keyannotations for instance matching, which is necessaryfor model comparison. Often, however, the required keyannotations were already present since they were neededfor establishing traceability links in RE. In general, differ-ent feature decompositions for different purposes couldbe provided as views as in the case of MA. Exploringeffective ways of defining such views is future work.

Lack of formalization. Another limitation is the lackof formalization of the FSMF. The semantics of an FSMLis specified as a semantic domain and a semantic map-ping [48]. The semantic domain is a set of static andbehavioral code patterns, and the semantic mappingis given by the mapping definitions. Although theseconcepts are currently not formalized, we have relatedmapping types to pointcut languages [40]. Thus, a for-malization of the FSMF could build on the existingwork on formal models of pointcut languages overstatic code patterns [49] and dynamic code patterns [50].The complete semantic mapping for an FSML is givencompositionally through the mapping definitions of itsfeatures. A formalization of this model is future work.

Furthermore, the use of code queries and transfor-mations need to be formalized is in order to betterunderstand the rules of their composition, such as pre-and post-conditions. Code query and transformationcomposition is important since the metamodel of anFSML can be understood as a compositional definition of

a code query in reverse engineering and a compositionaldefinition of a code transformation in forward engineer-ing. A formalization of round-trip engineering wouldprovide insights into the properties of the approach,such as what exactly are the conditions of reconciliationand what are the limitations of instance identification(matching).

No guidance for concrete syntax. The method doesnot provide any guidance for building concrete syntaxesfor FSMLs. Effective concrete syntax improves pragmaticquality and it is a prerequisite for any studies involv-ing users. The creation of the concrete syntax couldbe driven by the concept kinds; e.g., FSMLs includingboth component-oriented or connector-oriented conceptsmay require a diagrammatic lines-and-boxes notation. Theconcrete syntax should ideally leverage results related tosupporting feature model configuration, constraint prop-agation, and supporting different configuration inter-faces, such as tree view and configuration wizards [51],[52], [53]. We developed simple concrete syntaxes forthe exemplar FSMLs that utilize a generic graphical treeeditor customized with icons and descriptive labels (cf.Box 15).

8 RELATED WORK

8.1 Engineering of domain-specific languages(DSLs)

DSLs for framework APIs. The idea of designing mod-eling languages for frameworks is not new. In 1996,Roberts and Johnson proposed that language tools, suchas visual builders, should be the last stage in the evolu-tion of black-box frameworks [54]. The FSML approachprovides a systematic method to building such lan-guages declaratively.

In their 2005 survey on DSLs [55], Mernik et al. iden-tify the following DSL development phases: decision,analysis, design, implementation, and deployment. Thesurvey mentions the creation of a “user-friendly” nota-tion for an existing library or a framework as a possiblemotivation for the creation of a DSL in the decisionphase. In the analysis phase, informal or formal domainanalysis is performed to capture domain concepts byusing implicit and explicit sources of knowledge, such asdocumentation, experience, and example code. Feature-oriented domain analysis (FODA) [7] is included as apossible analysis method. The authors further state thatno clear guidelines exist as to how a language couldbe designed from the results of domain analysis. In ourmethod, FODA is specialized and extended to supportthe complete definition and implementation of an FSML.Furthermore, our method gives specific guidelines onhow the concepts and features are obtained, scoped,structured, mapped to code, and evaluated.

Bravenboer and Visser present MetaBorg [56], amethod for embedding DSLs into general-purpose lan-guages. A program expressed in an embedded DSL is


included inside a host program written in a general-purpose language. During the assimilation phase, theembedded DSL program is translated into the hostlanguage. Bravenboer and Visser demonstrate their ap-proach by implementing a simple DSL on top of Swing,which is a Java framework for GUI programming. Theassimilation of DSL programs produces the frameworkcompletion code. Code generation in MetaBorg is lo-calized, i.e., it replaces the embedded DSL programwith the completion code within the host program. Incontrast, FSMs are external to the program using theAPI, and code generation for FSMs has global andincremental character with respect to the target program.Furthermore, assimilation is performed during compi-lation and the developer is not intended to customizethe generated code. In FSMLs, the generated code isintegrated into the source code and it may be customizedas needed thanks to round-trip engineering.

Domain-Specific Modeling Languages (DSMLs).DSMLs are specification-level DSLs for capturing re-quirements or designs. FSMLs can be viewed as a specialkind of DSMLs for expressing the design of framework-based applications in relation to the framework API.

Most DSML development approaches (e.g., [57], [58],[59]) are based on metamodeling using some form ofclass models (e.g., [60], [61], [62]) or entity-relationshipmodels [63]. The metamodeling notation for FSMLs iscardinality-based feature modeling [15], extended withreference attributes and inheritance. The expressivenessof the resulting notation is comparable with that of classmodeling [16]. The main advantage of feature modelingare its explicit constructs for variability constraints suchas feature groups. Furthermore, our metamodeling no-tation supports additional concepts such as essentialityand keys.

Kelly and Tolvanen present a process for designingDSMLs for 100% code generation [64]. They assumethe existence of a domain framework and give gen-eral guidelines for building and adopting a DSML forthat framework. They also assume that the frameworkis mature and complete such that the code generatedfrom a model never has to be manually modified. Thedevelopment process consists of the following activi-ties: selecting an appropriate domain, ensuring propertraining and management support, defining the DSML,pilot project, and deployment. The authors advocate usescenarios to drive the development of DSMLs. Theyalso provide guidelines on how to identify and definemodeling concepts, design concrete syntax, and developcode generators using scripting and a template-basedapproach. The approach targets languages that are closerto system requirements and normally require significantamount of generated code that is not intended to bemodified manually. In contrast, FSMLs target the useof frameworks and they usually are much closer to therespective framework APIs. They also support reverseengineering and round-trip engineering, which allowsmanual edits of the generated code. In contrast to DSMLs

with 100% code generation, FSMLs target model-supportedengineering, where models are optional since they can beretrieved from code at any time. In a sense, FSMLs followa single-source principle, where all relevant informationis stored in one place, which is source code of the appli-cation. FSMLs may also be of particular interest when theapplication domain of interest is not mature and stableenough to create a high-level DSML. FSMLs may havea lower adoption barrier, particularly in cases where anorganization would already use frameworks for whichFSMLs existed. Furthermore, due to the narrower scopeof FSMLs, we are able to give more detailed guidelinesand process for language development.

Quality of models and languages. Moody reviewed50 different proposals to evaluating quality of conceptualmodels [65]. Some of these approaches are specific toparticular notations such as UML or ER/EER. Onlyfew of these approaches were empirically evaluated.The framework by Lindland et al. [9], which we usein our work (cf. Section 4), is one of the few generalapproaches that were evaluated. It is important to notethat Lindland et al. also showed that other propertiesof models, such as correctness, minimality, traceability,consistency, and unambiguity are subsumed by theirframework [9]. In our application of the framework,we had to extend the definition of pragmatic quality tocover model creation and modification in addition to thealready addressed comprehension aspect. Furthermore,we apply this framework at three levels: FSMs, FSMLs,and FSMF.

SEQUAL [10] is a comprehensive semiotic qualityframework for models that grew out of the frameworkby Lindland et al. Additionally to syntactic, semantic,and pragmatic qualities, SEQUAL proposes four morekinds of qualities: empirical, perceived semantic, social,and organizational. Empirical quality is related to prop-erties that can be empirically perceived by just lookingat a model and without considering its syntax or se-mantics (e.g., use of colors, quality of layout, presenceof redundancy). Perceived semantic quality relates themodel semantics to what the audience already knowsabout the model domain and how that may influencetheir model understanding. Social quality is related tohow differently a given model may be interpreted bydifferent members of the audience. Furthermore, thequality is related to the ability to express such differencesand to support consensus building. Means to improvesocial quality include model comparison and modelmerging facilities. In this paper, we only consideredthe organizational quality. We chose not to considerempirical quality since we view it as highly overlappingwith the pragmatic quality. Furthermore, we feel thatthe concept of perceived semantic quality needs furtherelaboration and concretization to be readily applicablein our context; however, we recognize the relevance ofsocial quality to FSMLs, since FSMLs may have mul-tiple simultaneous users of different backgrounds, e.g.,application developers, architects, and quality assurance


engineers. We leave this aspect for future work.The Cognitive Dimensions (CDs) framework has been

previously used to assess the pragmatic quality of mod-eling languages (e.g., [66]) and DSLs (e.g., [67]). Black-well at al. [68] provided criteria for extending CDswith new dimensions. User studies with FSMLs maywell reveal that the CDs framework may need furtheradaptation and extension to the context of FSMLs.

8.2 Modularization of crosscutting concernsAspect-Oriented Programming (AOP). The goal of AOPis to modularize the implementation of crosscutting con-cerns [69]. Similar to AOP, FSMLs also address the issueof understanding and maintaining crosscutting concerns.In particular, FSMLs help to locate the implementationof framework-provided concepts and features that maybe scattered across the application code and tangled withthe implementation of other concepts. Interestingly, theFSML mapping types used for defining behavioural pat-terns are essentially pointcut language constructs. Someof the mapping types correspond to AspectJ constructsand other, such as data-flow related mapping types, gobeyond AspectJ [14].

In contrast to AOP languages such as AspectJ, FSMLsdo not separate the scattered code fragments into sep-arate aspect modules, but leave them inline and sup-port their localization through traceability links. Thisapproach is less invasive for existing applications that donot use an aspect language. Also, it can be argued thatnot all crosscutting code is appropriate to be separatedout [70]. A hybrid approach that either leaves the cross-cutting separated or inline and allows to freely switchbetween the two is also possible (e.g., [71]). Exploringsuch hybrid strategies in the context of FSMLs is futurework.

Feature-Oriented Programming (FOP). The goal ofFOP approaches such as AHEAD [72] is to allow ap-plications to be synthesized from different configura-tions of features. Features are increments in programfunctionality and FOP seeks to provide mechanisms toencapsulate features as first-class modules. FOP andFSMLs are similar in that they both use feature modelsto express the configurability of features and they bothconsider the mapping of features to code and otherartifacts such as XML configuration files; however, thereare two important differences. First, FOP specificallytargets product-line engineering and seeks to synthesizeentire applications in an application domain. That is,each application is fully described by a particular fea-ture configuration. In contrast, FSMs model only oneaspect of framework-based applications, namely how theframework-provided concepts and features are instanti-ated in the application code. In particular, applicationsare likely to contain significant amounts of code that isapplication-specific and is not reflected in their FSMs.Second, FOP focuses on the modularity and composi-tionality of features and it exploits their algebraic prop-erties in application synthesis and optimization. That

is, FOP helps to create highly modular application andproduct-line architectures. As a result, existing applica-tions need to be re-factored into appropriate features inorder to take advantage of FOP [73]. In contrast, FSMLsfocus on the ability to automatically reverse engineermodels from applications that use the framework forwhich the FSML was designed. Furthermore, both theapplication code and the FSMs can be freely editedand automatically kept in sync through round-trip en-gineering. Thus, FSMLs do not impose any architecturalconstraints on applications beyond what is required bythe corresponding framework. Nevertheless, both ap-proaches are complementary and exploring synergiesbetween them is future work.

8.3 Supporting framework-based application devel-opment

Documentation-oriented approaches. Early approachesto supporting framework instantiation focused on pro-viding API documentation in the form of cookbooks [74],which outlined development tasks and steps supple-mented with code examples. Pree et al. showed howcookbooks could be made active and how developmentsteps could automated [75]. Ortigosa et al. went furtherby using intelligent agent technology to interactivelyguide the user in making implementation choices basedimplementation recipes [76].

In 1992, Johnson proposed documenting frameworksusing patterns [77]. The patterns described the purposeand the design of a framework and common ways ofusing it.

Fontoura et al. proposed a special profile of the UMLlanguage for representing framework APIs called UML-F [78]. The profile defines annotations that can be placedon API elements to indicate their function. The usersspecialize a UML-F model to produce the design of theirapplication and a supporting tool transforms the modelinto code. The tool has the form of a wizard that can onlygenerate code, i.e., it cannot be used for maintaining theconsistency between the model and the code.

Pattern-based approaches. Hakala et al. proposed apattern-based approach to generating task-driven pro-gramming environments for frameworks [79]. In thisapproach, specialization patterns are used to describeextension points of frameworks. A tool called FRame-work EDitor (FRED) is used by application developersin the process of casting, i.e., instantiating the given spe-cialization pattern in the code. FRED supports iterativeand incremental casting which reflects the natural wayprogrammers work.

Tourwe proposed documenting framework’s designusing design patterns and then using such documenta-tion to provide active support in framework-based soft-ware evolution [80]. After manually identifying designpattern instances used in the framework, the associatedtool can support framework evolution and instantiationrelated to these pattern instances. The tool can create


subclasses of framework API classes and add emptymethod declarations in the application code to sup-port framework instantiation. Application developersare expected to provide implementation for the createdmethod bodies.

More recently, Fairbanks proposed encoding commonframework API usage patterns as design fragments [23].Such a design fragment has a name, a goal that canbe accomplished by implementing it, description ofclasses, methods, fields, and method and constructorcalls that need to be created to accomplish the goal,and description of the relevant parts of the framework’sAPI. Developers choose a design fragment they wish toimplement and manually bind it to their code allowingthe tool to check the correctness of the implementation.

The FSML approach differs from pattern-based ap-proaches by emphasizing a more conceptual view of theAPI as a language rather than focusing on individualAPI usage patterns. In particular, FSMLs can includehigher-level domain concepts, which are then decom-posed into individual implementation patterns. Similarlyto the pattern approaches, in which the patterns haveto be identified and specified manually, FSMLs have tobe built manually; however, FSMLs support automaticfeature instance location in the application code and theaddition of feature instance implementations to codeat the level of individual statements (rather than classskeletons only). Furthermore, through variability mecha-nisms, FSMLs can encode and organize many alternativeways of implementing a single concept, each of whichwould require a separate design pattern or fragment.

Framework API usage comprehension and patternmining. The pattern-based approaches discussed previ-ously assume that the patterns are identified and speci-fied manually. Manual identification of such patterns insample applications can be a difficult task because of thepotentially large amount of application code that needsto be processed. Several tool-supported approaches havebeen proposed to ease this task.

Specification mining is concerned with extracting APIcall protocols form application code. These approachesuse either dynamic analysis, e.g., [81], [82], [83], [84],or static analysis, e.g., [85], [86], [87], to extract APIcall sequences from sample applications, and then applymining techniques to generalize the sequences to genericprotocol specifications. Interestingly, these approachesmainly focus on library APIs rather than frameworkAPIs. The relevance of API protocols to libraries isobvious: library components, such as network connec-tions and cashes, require their users to observe lifecycleprotocols, such as those involving component creation,initialization, actual processing, tear-down, and destruc-tion. In contrast, frameworks tend to enforce protocolsthemselves using callbacks, and the framework APIusers only need to know which framework servicesshould be called in which callback. Therefore, protocolmining seems less useful for frameworks than libraries.

Several approaches deal with mining for specific

framework API usage patterns. For example, Prospec-tor [88] and PARSEWeb [89] mine for API call sequencesneeded to arrive at some API type (class or interface)given another API type. XSnippet [90] mines for codefragments instantiating a given API type. All these ap-proaches require the API user to issue a query, uponwhich one or more code fragments based on the sampleapplications is produced.

Strathcona [91] and FrUiT [92] also search existingsample code for API usages, but they obviate the needto state queries explicitly. Instead, they use the currentcode under development as a query. Strathcona locatesrelevant code in sample applications based on heuristi-cally matching the structure of the code under devel-opment to the example code, where structure coversinformation such as type hierarchies and method callgraphs. FrUiT mines sample code for frequent API usagepatterns as association rules, e.g., subclass A ⇒ call m,which is similar to the earlier CodeWeb approach [93].In contrast to CodeWeb, however, FrUiT uses such rulesto suggest implementation steps for a Java class underdevelopment.

FUDA [94], [95] allows developers to extract entireimplementation templates for concepts of interest. In-stead of specifying a code-oriented query, the developeruses a tracer to collect two execution traces of theconcept of interest, e.g., a context menu, from one ortwo applications. The traces can be optionally markedwith the beginning and the end of concept execution.Based on these traces, FUDA Analyzer generates a Java-like concept implementation template by intersectingthe traces and statically extracting further informationfrom the sample application code. A limitation of FUDAis its inability to detect implementation variants: theimplementation template is useful for implementing asingle variant of a concept.

FSML engineering can clearly benefit from tool sup-port to mine existing application code for API usagepatterns: such mining would allow the discovery of newconcepts and features for the FSML under construc-tion. During the development of the exemplar FSMLs,we used an existing FSML version to reverse engineersample code. We then followed the traceability linksfrom the extracted FSMs to code and also used Eclipse’ssearch capabilities to manually discover missed patterns.However, a proper pattern mining tool could make thisprocess more systematic by completely scanning theframework-application boundary and by organizing thediscovered patterns into feature models annotated withpattern occurrence statistics. Mining probabilistic featuremodels from sets of feature configurations obtained bystatic program analysis [96] is a step towards such toolsupport. Further exploration of API usage mining forFSML engineering is future work.

Framework API constraint checking. Hou andHoover proposed an approach to checking applicationsfor adherence to structural API constraints specified inStructural Constraint Language (SCL) [97], [98]. The ap-


proach was demonstrated for C++ and Java frameworks.In addition to basic program structure queries, SCL of-fers simple control-flow and data-flow-based constructs.Many of the API constraints present in the exemplarFSMLs could be written as SCL constraints. FSMLs gobeyond API constraint checking by representing and or-ganizing these constraints as a language and supportingforward and reverse engineering.

Framework API migration. Two categories of frame-work API migration can be distinguished: upgradingapplication code from an older API version to a newerone and migrating application code from one frameworkto a different one.

There has been recently a flurry of work in the firstcategory, e.g., recording API refactorings and replyingthem on the application code to be updated [99], in-ferring such refactorings by comparing different APIversions [100], or inferring them from already migratedapplications [101]. We have not encoded upgrades usingFSMLs; however, upgrades should be feasible using asingle metamodel since they require relatively simplecode changes.

In the second category, we already mentioned migra-tion from Struts to Java Server Faces using FSMLs [25](cf. Box 17). Another example of API migration betweendifferent frameworks is ajaxification, i.e., migration ofmulti-page web applications to Asynchronous JavaScriptand XML (AJAX) [102]. In AJAX, a web application isdisplayed on a single page whose parts can be reloadedindividually instead of reloading the entire page. Tohelp with such a migration, the authors proposed firstreverse engineering a multi-page web application into anavigation model and later clustering pages with similarURLs that could be included on a single page. Finally, theresulting single page UI model would be translated into animplementation for a particular AJAX framework. Thismigration process could be viewed as applying RE, MA,and FE. Exploring the above and additional migrationscenarios using FSMLs is future work.

9 CONCLUSION

The main contributions of this paper are four exemplarFSMLs and the experience of building these languagespresented in the form of an engineering method. Themethod provides FSML developers with a detailed andcomprehensive set of steps, guidelines, and examples.

The development of the FSML approach is groundedin the design science paradigm and the method repre-sents a necessary step in the maturation of the FSMLapproach. The method was constructed by specializ-ing well-established approaches: feature-oriented do-main analysis (FODA), the model quality framework ofLindland et al., the Cognitive Dimensions (CDs) frame-work, and some elements of the Unified Process. Spe-cializing these approaches to the FSML context allowedus to systematically elicit, structure, and document ourexperience. We have justified the method by tracing its

steps back to the development of the exemplar FSMLsand to the elements of the base approaches.

In the course of the method development, FODAhad to be extended to handle cardinality-based fea-ture models and the special FSML modeling constructssuch as essentiality, keys, and mapping definitions. Themodel quality framework was applied at three levels:framework-specific models, modeling languages, andthe modeling foundation, while distinguishing betweenthe pragmatic quality of a language extension and itsmetamodel (cf. Figure 5). The CDs framework was usedto evaluate the pragmatic quality of the exemplar FSMLs(cf. Box 6). Furthermore, the development of the ex-emplar FSMLs showed that a single FSML metamodelcan be used to support multiple use cases and thatmetamodel changes needed to support each additionaluse cases were mostly additive.

Future work includes performing user studies with theexemplar FSMLs and the method, extending round-tripcapabilities with code removal and refactoring capabili-ties, and formalizing the overall approach.

We believe that the paper provides a strong case forthe benefits of modeling framework APIs as modelinglanguages by showing how such languages can supportAPI understanding and completion code understand-ing, analysis, creation, evolution, and migration. TheFSML approach can be categorized as model-supportedengineering, in which models are supporting artifacts.This is in contrast to model-driven engineering, wheremodels are the primary source artifacts. FSMs can al-ways be extracted using RE and discarded if no longerneeded. Furthermore, FSMs can be always kept up-to-date through RTE, regardless whether the code orthe language definition has changed. In the latter case,after adding new features to the FSML, existing FSMscan simply be updated with instances of these newfeatures matched in the code through RTE. Therefore,incremental development of FSMLs as prescribed by themethod also supports incremental adoption of such lan-guages in practice with minimal changes to the existingdevelopment processes.

ACKNOWLEDGMENTS

The authors would like to thank Herman Lee for imple-menting the XML mapping interpreter used by the Strutsand EJB FSMLs and Henry Lau for implementing someof the code transformations for mapping types related toJava. We also thank the anonymous reviewers for theirvaluable comments. This research was supported by IBMCenters for Advanced Studies in Ottawa and Toronto,the Natural Sciences and Engineering Research Councilof Canada, and the Ontario Research Fund.

REFERENCES

[1] Eclipse documentation - Version 3.3: Editors, Eclipse Foundation,http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/editors.htm.


[2] D. Springgay, Creating an Eclipse View, November 2001, http://www.eclipse.org/articles/viewArticle/ViewArticle2.html.

[3] Java Tutorials, Lesson: Applets, Sun Microsystems, http://java.sun.com/docs/books/tutorial/deployment/applet/index.html.

[4] M. Antkiewicz and K. Czarnecki, “Framework-specific modelinglanguages with round-trip engineering,” in MoDELS, ser. LNCS,vol. 4199, 2006, pp. 692–706.

[5] M. Antkiewicz, “Framework-specific modeling languages,”Ph.D. dissertation, University of Waterloo, 2008, http://hdl.handle.net/10012/4030.

[6] I. Jacobson, G. Booch, and J. Rumbaugh, The unified softwaredevelopment process. Addison-Wesley Longman Publishing Co.,Inc., 1999.

[7] K. Kang, S. Cohen, J. Hess, W. Nowak, and S. Peterson, “Feature-oriented domain analysis (FODA) feasibility study,” SoftwareEngineering Institute, Carnegie Mellon University, Tech. Rep.CMU/SEI-90TR -21, 1990.

[8] A. R. Hevner, S. T. March, J. Park, and S. Ram, “Design sciencein information systems research,” MIS Quarterly, vol. 28, no. 1,pp. 75–105, 2004.

[9] O. I. Lindland, G. Sindre, and A. Sølvberg, “Understandingquality in conceptual modeling,” IEEE Softw., vol. 11, no. 2, pp.42–49, 1994.

[10] J. Krogstie, G. Sindre, and H. Jørgensen, “Process models rep-resenting knowledge for action: a revised quality framework,”Eur. J. Inf. Syst., vol. 15, no. 1, pp. 91–102, 2006.

[11] T. R. G. Green, “Cognitive dimensions of notations,” in Peopleand Computers V, A. Sutcliffe and L. Macaulay, Eds., 1989, pp.443–460.

[12] T. R. G. Green and M. Petre, “Usability analysis of visual pro-gramming environments: A ’cognitive dimensions’ framework,”J. Vis. Lang. Comput., vol. 7, no. 2, pp. 131–174, 1996.

[13] S. T. March and G. F. Smith, “Design and natural science researchon information technology,” Decis. Support Syst., vol. 15, no. 4,pp. 251–266, 1995.

[14] M. Antkiewicz, T. Tonelli Bartolomei, and K. Czarnecki, “Fastextraction of high-quality framework-specific models from ap-plication code,” J. Autom. Soft. Eng., vol. 16, no. 1, pp. 101–144,Mar. 2009.

[15] K. Czarnecki, S. Helsen, and U. Eisenecker, “Formalizingcardinality-based feature models and their specialization,” Soft-ware Process Improvement and Practice, vol. 10, no. 1, pp. 7–29,2005, special issue on Software Variability: Process and Manage-ment.

[16] M. Stephan and M. Antkiewicz, “Ecore.fmp: A tool for edit-ing and instantiating class models as feature models,” ECE,Univeristy of Waterloo, Tech. Rep. #2008-08, 2008, http://gp.uwaterloo.ca/tr/2008-stephan-ecore-fmp.pdf.

[17] K. Czarnecki and U. W. Eisenecker, Generative programming:methods, tools, and applications. Addison-Wesley Publishing Co.,2000.

[18] M. Antkiewicz and K. Czarnecki, “Design space of heteroge-neous synchronization,” in GTTSE, ser. LNCS, vol. 5235, 2008,pp. 3–46.

[19] S. Khanna, K. Kunal, and B. C. Pierce, “A formal investigationof diff3,” in FSTTCS, 2007.

[20] J. Makhoul, F. Kubala, R. Schwartz, and R. Weischedel, “Per-formance measures for information extraction,” in Proceedings ofDARPA Broadcast News Workshop, 1999, pp. 249–252.

[21] W. Noth, Handbook of Semiotics. Bloomington: Indiana UniversityPress, 1996.

[22] M. Stephan, “Discovery of Java EE 5 EJB antipattern instancesusing framework-specific models,” Master’s thesis, University ofWaterloo, 2009, in preparation.

[23] G. Fairbanks, D. Garlan, and W. Scherlis, “Design fragmentsmake using frameworks easier,” in OOPSLA, 2006, pp. 75–88.

[24] B. Dudney, S. Asbury, J. Krozak, and K. Wittkopf, J2EE AntiPat-terns. Wiley, 2003.

[25] A. P. Cheema, “Struts2JSF - framework migration in J2EE usingFramework-Specific Modeling Languages,” Master’s thesis, Uni-versity of Waterloo, 2007, http://hdl.handle.net/10012/3031.

[26] Javadoc for Package org.eclipse.ui.part, Eclipse Foundation,2007, http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ui/part/package-summary.html.

[27] C. Pandit, Make your Eclipse applications richer with view linking,2005, http://www-128.ibm.com/developerworks/opensource/library/os-ecllink/.

[28] M. R. Hoffmann, Eclipse Workbench: Using the SelectionService, April 2006, http://www.eclipse.org/articles/Article-WorkbenchSelections/article.html.

[29] Struts Javadoc, Apache Software Foundation, 2006, http://struts.apache.org/1.3.5/apidocs/index.html.

[30] “Struts 1.35 dtd,” Apache Software Foundation, July 2006, http://struts.apache.org/1.3.5/dtds/struts-config 1 3.dtd.

[31] Struts 1.35 User Guide, Apache Software Foundation, jul 2006,http://struts.apache.org/1.3.5/userGuide/introduction.html.

[32] A Walking Tour of the Struts MailReader Demonstration Application,Apache Software Foundation, http://svn.apache.org/viewvc/struts/struts1/trunk/apps/mailreader/src/main/webapp/tour.html?revision=481833.

[33] Lesson: Applets, Sun Microsystems, Inc., February 2008,http://java.sun.com/docs/books/tutorial/deployment/applet/index.html.

[34] Processes and Threads, Sun Microsystems, Inc., February2008, http://java.sun.com/docs/books/tutorial/essential/concurrency/procthread.html.

[35] JavaTM Platform Enterprise Edition, v 5.0 API Specifications, SunMicrosystems, Inc., 2007, http://java.sun.com/javaee/5/docs/api/.

[36] L. DeMichiel, EJB Core Contracts and Requirements, Sun Microsys-tems, Inc., May 2006.

[37] “Enterprise JavaBeans deployment descriptor schema,” SunMicrosystems, Inc., May 2006, http://java.sun.com/xml/ns/javaee/ejb-jar 3 0.xsd.

[38] E. Jendrock, J. Ball, D. Carson, I. Evans, S. Fordin, and K. Haase,The Java EE 5 Tutorial, Sun Microsystems, Inc., September 2007,http://java.sun.com/javaee/5/docs/tutorial/doc/index.html.

[39] K. Lee and K. C. Kang, “Feature dependency analysis for productline component design,” in ICSR, ser. LNCS, no. 3107, 2004, pp.69–85.

[40] M. Antkiewicz, T. Tonelli Bartolomei, and K. Czarnecki, “Auto-matic extraction of framework-specific models from framework-based application code,” in ASE, 2007, pp. 214–223.

[41] A. Blackwell and T. Green, “A cognitive dimensions ques-tionnaire,” February 2007, http://www.cl.cam.ac.uk/∼afb21/CognitiveDimensions/CDquestionnaire.pdf, last accessed Feb.20, 2009.

[42] D. L. Parnas and P. C. Clements, “A rational design process:How and why to fake it,” IEEE Trans. Softw. Eng., vol. 12, no. 2,pp. 251–257, 1986.

[43] D. Hou, K. Wong, and H. J. Hoover, “What can programmerquestions tell us about frameworks?” in IWPC, 2005, pp. 87–96.

[44] F. Shull, F. Lanubile, and V. R. Basili, “Investigating readingtechniques for object-oriented framework learning,” IEEE Trans.Softw. Eng., vol. 26, no. 11, pp. 1101–1118, 2000.

[45] M. Antkiewicz and K. Czarnecki, “Framework-specific modelinglanguages; examples and algorithms,” ECE, U. of Waterloo, Tech.Rep. 2007-18, 2007.

[46] H. Lee, M. Antkiewicz, and K. Czarnecki, “Towards a genericinfrastructure for framework-specific integrated developmentenvironment extensions,” in DSPD, 2008.

[47] G. Little and R. C. Miller, “Keyword programming in Java,”Automated Software Engineering, vol. 16, no. 1, pp. 37–71, march2008.

[48] D. Harel and B. Rumpe, “Meaningful modeling: What’s thesemantics of ”semantics”?” Computer, vol. 37, no. 10, pp. 64–72,2004.

[49] P. Avgustinov, E. Hajiyev, N. Ongkingco, O. de Moor, D. Sereni,J. Tibble, and M. Verbaere, “Semantics of static pointcuts inaspectj,” SIGPLAN Not., vol. 42, pp. 11–23, 2007.

[50] C. Allan, P. Avgustinov, A. S. Christensen, L. Hendren, S. Kuzins,O. Lhotak, O. de Moor, D. Sereni, G. Sittampalam, and J. Tibble,“Adding trace matching with free variables to AspectJ,” inOOPSLA, 2005, pp. 345–364.

[51] M. Antkiewicz and K. Czarnecki, “FeaturePlugin: feature model-ing plug-in for eclipse,” in Eclipse Technology eXchange Workshop,2004, pp. 67–72.

[52] K. Czarnecki and P. Kim, “Cardinality-based feature modelingand constraints: A progress report,” in Proceedings of the Interna-tional Workshop on Software Factories, OOPSLA, 2005.


[53] K. Czarnecki and A. Wasowski, “Feature diagrams and logics:there and back again,” in SPLC, 2007, pp. 23–34.

[54] D. Roberts and R. Johnson, “Evolving frameworks: A patternlanguage for developing object-oriented frameworks,” in PLoP,1996.

[55] M. Mernik, J. Heering, and A. M. Sloane, “When and how todevelop domain-specific languages,” ACM Comput. Surv., vol. 37,no. 4, pp. 316–344, 2005.

[56] M. Bravenboer and E. Visser, “Concrete syntax for objects:domain-specific language embedding and assimilation withoutrestrictions,” in OOPSLA, 2004, pp. 365–383.

[57] T. Stahl and M. Voelter, Model-Driven Software Development,1st ed. Wiley, May 2006.

[58] T. Clark, P. Sammut, and J. Willans, Applied Metamodeling. AFoundation for language driven development, 2nd ed. Ceteva, 2008.

[59] J. Greenfield, K. Short, S. Cook, and S. Kent, Software Factories:Assembling Applications with Patterns, Models, Frameworks, andTools. Wiley, 2004.

[60] “Meta object facility (mof) core specification v. 2.0,” Object Man-agement Group, Inc., January 2008, http://www.omg.org/mof/.

[61] F. Budinsky, S. A. Brodsky, and E. Merks, Eclipse ModelingFramework. Pearson Education, 2003.

[62] S. Cook, G. Jones, S. Kent, and A. C. Wills, Domain-SpecificDevelopment with Visual Studio DSL Tools. Addison-WesleyProfessional, 2007.

[63] K. Smolander, “GOPRR: a proposal for a meta level model,”1993, University of Jyvaskyla, Finland.

[64] S. Kelly and J.-P. Tolvanen, Domain-Specific Modeling: EnablingFull Code Generation. Wiley-IEEE Computer Society Press, 2008.

[65] D. L. Moody, “Theoretical and practical issues in evaluating thequality of conceptual models: current state and future direc-tions,” Data Knowl. Eng., vol. 55, no. 3, pp. 243–276, 2005.

[66] M. Kutar, C. Britton, and T. Barker, “A comparison of empiricalstudy and cognitive dimensions analysis in the evaluation ofUML diagrams,” in Workshop of the Psychology of ProgrammingInterest Group, 2002, pp. 1–14.

[67] C. A. Austin, “Renaissance: a functional shading language,”Master’s thesis, Iowa State University, 2005.

[68] A. F. Blackwell, C. Britton, A. L. Cox, T. R. G. Green, C. A.Gurr, G. F. Kadoda, M. Kutar, M. Loomes, C. L. Nehaniv,M. Petre, C. Roast, C. Roe, A. Wong, and R. M. Young, “Cognitivedimensions of notations: Design tools for cognitive technology,”in CT, 2001, pp. 325–341.

[69] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes,J.-M. Loingtier, and J. Irwin, “Aspect-oriented programming,” inECOOP, 1997, pp. 220–242.

[70] S. Apel and D. Batory, “When to use features and aspects?: acase study,” in GPCE, 2006, pp. 59–68.

[71] C. H. P. Kim, K. Czarnecki, and D. Batory, “On-demand mate-rialization of aspects for application development,” in SPLAT,2008, pp. 1–6.

[72] D. Batory, J. N. Sarvela, and A. Rauschmayer, “Scaling step-wiserefinement,” in ICSE, 2003, pp. 187–197.

[73] J. Liu, D. Batory, and C. Lengauer, “Feature oriented refactoringof legacy applications,” in ICSE, 2006, pp. 112–121.

[74] G. E. Krasner and S. T. Pope, “A cookbook for using the model-view controller user interface paradigm in Smalltalk-80,” J. ObjectOriented Program., vol. 1, no. 3, pp. 26–49, 1988.

[75] W. Pree, G. Pomberger, A. Schappert, and P. Sommerlad, “Activeguidance of framework development,” Software - Concepts andTools, vol. 3, no. 16, 1995.

[76] A. Ortigosa and M. Campo, “Smartbooks: A step beyond active-cookbooks to aid in framework instantiation,” in TOOLS, 1999,p. 131.

[77] R. E. Johnson, “Documenting frameworks using patterns,” inOOPSLA, 1992, pp. 63–76.

[78] M. Fontoura, W. Pree, and B. Rumpe, “UML-F: A modelinglanguage for object-oriented frameworks,” in ECOOP, 2000, pp.63–82.

[79] M. Hakala, J. Hautamaki, K. Koskimies, J. Paakki, A. Viljamaa,and J. Viljamaa, “Generating application development environ-ments for java frameworks,” ser. LNCS, vol. 2186, 2001, pp. 163–176.

[80] T. Tourwe, “Automated support for framework-based softwareevolution,” Ph.D. dissertation, Vrije Universiteit Brussel, 2002.

[81] G. Ammons, R. Bodık, and J. R. Larus, “Mining specifications,”in POPL, 2002, pp. 4–16.

[82] J. Yang, D. Evans, D. Bhardwaj, T. Bhat, and M. Das, “Perracotta:Mining temporal API rules from imperfect traces,” in ICSE, 2006,pp. 282–291.

[83] D. Lo, S.-C. Khoo, and C. Liu, “Efficient mining of iterativepatterns for software specification discovery,” in KDD, 2007, pp.460–469.

[84] S. Sankaranarayanan, F. Ivanci, and A. Gupta, “Mining libraryspecifications using inductive logic programming,” in ICSE,2008, pp. 131–140.

[85] A. Wasylkowski, A. Zeller, and C. Lindig, “Detecting objectusage anomalies,” in FSE, 2007.

[86] M. Acharya, T. Xie, J. Pei, and J. Xu, “Mining API patternsas partial orders from source code: From usage scenarios tospecifications,” in FSE, 2007.

[87] M. K. Ramanathan, A. Grama, and S. Jagannathan, “Path-sensitive inference of function precedence protocols,” in ICSE,2007, pp. 240–250.

[88] D. Mandelin, L. Xu, R. Bodık, and D. Kimelman, “Jungloidmining: Helping to navigate the API jungle,” in PLDI, 2005, pp.48–61.

[89] S. Thummalapenta and T. Xie, “PARSEWeb: A programmerassistant for reusing open source code on the web,” in ASE, 2007,pp. 204–213.

[90] N. Sahavechaphan and K. Claypool, “XSnippet: Mining forsample code,” in OOPSLA, 2006, pp. 413–430.

[91] R. Holmes and G. C. Murphy, “Using structural context torecommend source code examples,” in ICSE, 2005, pp. 117–125.

[92] M. Bruch, T. Schafer, and M. Mezini, “FrUiT: IDE support forframework understanding,” in ETX, 2006, pp. 55–59.

[93] A. Michail, “Data mining library reuse patterns using general-ized association rules,” in ICSE, 2000, pp. 167–176.

[94] A. Heydarnoori, “Supporting framework use via automaticallyextracted concept-implementation templates,” Ph.D. disserta-tion, University of Waterloo, Canada, 2009.

[95] A. Heydarnoori, K. Czarnecki, and T. Tonelli Bartolomei, “Sup-porting framework use via automatically extracted concept-implementation templates,” in ECOOP, 2009, submitted for re-view.

[96] K. Czarnecki, S. She, and A. Wasowski, “Sample spaces andfeature models: There and back again,” in SPLC, 2008, pp. 22–31.

[97] D. Hou and H. Hoover, “Using SCL to specify and check designintent in source code,” IEEE Tran. Soft. Eng., vol. 32, no. 6, pp.404–423, June 2006.

[98] D. Hou, “FCL: Automatically detecting structural errors inframework-based development,” Ph.D. dissertation, Universityof Alberta, 2004.

[99] D. Dig and R. Johnson, “The role of refactorings in API evolu-tion,” in ICSM, 2005, pp. 389–398.

[100] Z. Xing and E. Stroulia, “API-evolution support with Diff-CatchUp,” IEEE Tran. Soft. Eng., vol. 33, pp. 818–836, 2007.

[101] T. Schafer, J. Jonas, and M. Mezini, “Mining framework usagechanges from instantiation code,” in ICSE, 2008, pp. 471–480.

[102] A. Mesbah and A. van Deursen, “Migrating multi-page webapplications to single-page AJAX interfaces,” CSMR, pp. 181–190, 2007.

Michał Antkiewicz is a Postdoctoral Fellow at the University of Water-loo.

Krzysztof Czarnecki is an Associate Professor at the University ofWaterloo.

Matthew Stephan is a MASc. Candidate at the University of Waterloo.

engineering of framework-specific modeling languages

Documents