Fig 1 - uploaded by Oscar Díaz
Content may be subject to copyright.
Source publication
Step-wise refinement is a powerful paradigm for developing a com- plex program from a simple program by adding features incrementally where each feature is an increment in program functionality. Existing works focus on object-oriented representations such as Java or C++ artifacts. For this paradigm to be brought to the Web, refinement should be rea...
Contexts in source publication
Context 1
... control-flow of a sample base application is realised through the struts-config document depicted in figure 1(b). The description so far accounts for the base con- troller. ...
Context 2
... is the purpose of the "xak:modularizable" attribute. Figure 1(a) shows the Struts schema now annotated with this attribute. The attribute in- dicates whether an element type is eligible to be a module or not. ...
Context 3
... our sample case, only "/converter" is a refinable <action>; whereas /convertNow and /cheatsheet can not be refined. Figure 1(b) illustrates this situation for our sample case. This moves the decision of what can be refined to the instance level. ...
Context 4
... and those that can not be refined (i.e. the implementation). To this end, the XAK namespace provides three attributes (see figure 1b), namely: @xak:artifact, which specifies the name of the document that is being incrementally defined; @xak:feature, which indicates the name of the feature being supported 2 ; and @xak:module, which identifies those elements that play the role of modules. Notice that the designer is not forced to turn into modules all elements of a modularisable type. ...
Context 5
... artifact is gradually defined as features are being composed. The base is shown in figure 1b where mForms, mActions and mButtons are set as modules. Customisation implies: (1) adding the customizeForm form-bean into the mForms module; (2) extending the mButton dis- patcher action to show the customise.jsp ...
Similar publications
Background
Coronary revascularization using imaging guidance is rapidly becoming the standard of care. Intravascular optical coherence tomography uses near-infrared light to obtain high resolution intravascular images. Standard optical coherence tomography imaging technique employs iodinated contrast dye to achieve the required blood clearance duri...
Citations
... Thus, as a composition technique, superimposition should be applicable to a wide range of software artifacts. While there are various tools that support superimposition of code artifacts [6], [9], [11]- [18] and noncode artifacts [6], [19]- [23], they appear all different, they are dedicated to and embedded individually in their respective host languages, and their implementation and integration require a major effort. Usually, the developers of languages and tools did not address (or realize) the general nature of superimposition. ...
... Although manifested and implemented differently, several languages provide support for superimposition of different kinds of artifacts, for example, Jiazzi [11], Classbox/J [14], Hyper/J [16] and Jak [6] for Java, FeatureC++ [17] for C++, Xak [19] for XML, and others [6], [9], [20]- [22], [53]. In turn, superimposition is based on a large corpus of work on extending objects and classes noninvasively, for example, mixins [54], traits [55], virtual classes [56], and object composition [57]. ...
Superimposition is a composition technique that has been applied successfully in many areas of software development. Although superimposition is a general-purpose concept, it has been (re)invented and implemented individually for various kinds of software artifacts. We unify languages and tools that rely on superimposition by using the language-independent model of feature structure trees (FSTs). On the basis of the FST model, we propose a general approach to the composition of software artifacts written in different languages. Furthermore, we offer a supporting framework and tool chain, called FEATUREHOUSE. We use attribute grammars to automate the integration of additional languages. In particular, we have integrated Java, C#, C, Haskell, Alloy, and JavaCC. A substantial number of case studies demonstrate the practicality and scalability of our approach and reveal insights into the properties that a language must have in order to be ready for superimposition. We discuss perspectives of our approach and demonstrate how we extended FEATUREHOUSE with support for XML languages (in particular, XHTML, XMI/UML, and Ant) and alternative composition approaches (in particular, aspect weaving). Rounding off our previous work, we provide here a holistic view of the FEATUREHOUSE approach based on rich experience with numerous languages and case studies and reflections on several years of research.
... Using FeatureHouse, we have been able to compose features written in various languages such as Java, C#, C, Haskell, and JavaCC. 7 Other researchers have shown that also other (non-code) languages such as grammar or markup languages align well with the constraints above [3,17]. Languages that do not satisfy these constraints are not "feature-ready", since they do not provide sufficient structural information. ...
... For example, XHTML is not feature- ready since most elements of an XHTML document do not have unique names. However, it may be possible to make such languages feature-ready by assigning names to elements explicitly or by extending the languages with an overlaying module structure, as Xak does for XML languages [3]. ...
... As mentioned previously, features are implemented not only by source code. Several tools support the feature-based composition of non-source code artifacts [2,3,17,26]. Our algebra is general enough to describe a feature containing non-code artifacts as long as their representations can be mapped to FSFs. ...
Feature-Oriented Software Development provides a multitude of formalisms, methods, languages, and tools for building variable, customizable, and extensible software. Along different lines of research, different notions of a feature have been developed. Although these notions have similar goals, no common basis for evaluation, comparison, and integration exists. We present a feature algebra that captures the key ideas of feature orientation and that provides a common ground for current and future research in this field, on which also alternative options can be explored. Furthermore, our algebraic framework is meant to serve as a basis for the development of the technology of automatic feature-based program synthesis and architectural metaprogramming.
... A feature implements a stakeholder's requirement and is typically an increment in program functionality [55,13]. Contemporary feature-oriented programming languages and tools such as AHEAD [13], Xak [2], CaesarJ [48], Classbox/J [14], FeatureHouse [9], and FeatureC++ [10] provide a variety of mechanisms that support the specification, modularization, and composition of features. A key idea is that a feature is implemented by a distinct code unit, called a feature module. ...
... A class declaration L declares a class with the name C that inherits from a superclass D and consists of a list C f; of fields and a list M of method declarations. 2 A refinement declaration R consists of a list C f; of fields and a list M of method declarations. A method m expects a list C x of arguments and declares a body that returns only a single expression t of type C. Using the modifier overrides, a method declares that it intends to override another method with the same name and signature. ...
... The advantage of this approach is that a feature's implementation can include, beside classes in the form of Java files, also other supporting documents, e.g., documentation in the form of HTML files, grammar specifications in the form of JavaCC files, or build scripts and deployment descriptors in the form of XML files [13]. To this end, feature composition merges not only classes with their refinements but also other artifacts, such as HTML or XML files, with their respective refinements [2,9]. ...
A feature-oriented product line is a family of programs that share a common set of features. A feature implements a stakeholder's requirement and represents a design decision or configuration option. When added to a program, a feature involves the introduction of new structures, such as classes and methods, and the refinement of existing ones, such as extending methods. A feature-oriented decomposition enables a generator to create an executable program by composing feature code solely on the basis of the feature selection of a user -- no other information needed. A key challenge of product line engineering is to guarantee that only well-typed programs are generated. As the number of valid feature combinations grows combinatorially with the number of features, it is not feasible to type check all programs individually. The only feasible approach is to have a type system check the entire code base of the feature-oriented product line. We have developed such a type system on the basis of a formal model of a feature-oriented Java-like language. The type system guaranties type safety for feature-oriented product lines. That is, it ensures that every valid program of a well-typed product line is well-typed. Our formal model including type system is sound and complete.
... InFigure 12, there are the two refinement declarations of feature Reverse that add fields and methods to the classes of feature Single. The result of composing the features Single and Reverse behaves like the code shown inFigure 6. Beside Jak, also feature-oriented language extensions were proposed for C++, called FeatureC++ [17], and for XML, called Xak [2]. Basically, feature-oriented languages rely on programming mechanisms such as mixins [38, 59] and collabora- tions [106, 116, 126], but also aspects and subjects became popular in FOSD [61, 96, 87, 90, 74, 12, 18]. ...
Feature-oriented software development (FOSD) is a paradigm for the construction, customization, and synthesis of large-scale software systems. In this survey, we give an overview and a personal perspective on the roots of FOSD, connections to other software development paradigms, and recent developments in this field. Our aim is to point to connections between different lines of research and to identify open issues.
... An FST captures the essential, hierarchical module structure of a given program or feature; superimposition merges two FSTs by merging their corresponding substructures based on nominal and structural similarities. While superimposition works well in many situations [5, 6, 7, 8], there are certain situations where a different kind of composition is more appropriate [9, 10]. In such situations, an extension a feature applies to a program is expressed more generically and declaratively than possible with superimposition. ...
Based on a general model of feature composition, we present a composition language that enables programmers by means of quantification and weaving to formulate extensions to programs written in different languages. We explore the design space of composition languages that rely on quantification and weaving and discuss our choices. We outline a tool that extends an existing infrastructure for feature composition and discuss results of three initial case studies. We found that, due to its language independence, our approach is less powerful than aspect-oriented languages but still usable for many implementation problems.
... However, superimposition imposes several constraints on the target language: (1) the substructure of a feature must be a hierarchy of modules, (2) every module (submodule, ...) of a feature must have a name, and (3) the name of a module must be unique in the scope of its enclosing module (that is, a module must not have two submodules with identical names). ically, these constraints are satisfied by most programming languages, but also other (non-code) languages like XML or grammars align well with them [10, 20, 14]. In the next section, we analyze whether and how superimposition is capable of being used for model composition, especially for the composition of UML models. ...
... The core of this approach is a theory based on category theory that relates transformations that stem from feature composition to transformations that stem from model refinement. In their case study, they use the Xak tool [20] to compose state machines written in a domain-specific language, which is related to FEATUREHOUSE but not language-independent. The package merge mechanism of UML is related to superimposition [32] . ...
In software product line engineering, feature composition generates software tailored to specific requirements from a common set of artifacts. Superimposition is a popular technique to merge code pieces belonging to different features. The advent of model-driven development raises the question of how to support the variability of software product lines in modeling techniques. We propose to use superimposition as a model composition technique in order to support variability. We analyze the feasibility of superimposition as a model composition technique, offer a corresponding tool for model composition, and discuss our experiences with three case studies (including one industrial study) using this tool.
... Thus, as a composition technique, superimposition should be applicable to a wide range of software artifacts. While there are various tools that support superimposition for code artifacts [4, 8, 9, 20, 28, 31, 32, 34, 37] and non-code artifacts [1, 8, 14, 16, 18, 21], they appear all different, are dedicated to and embedded differently in their respective host languages, and their implementation and integration requires a major effort. A reason is that, usually, the developers of languages and tools did not address (or realize) the general nature of superimposition. ...
... Although manifested and implemented differently, several languages provide support for superimposition of different kinds of artifacts, e.g., Jiazzi [28], Classbox/J [9], Hyper/J [34] and Jak [8] for Java, ContextL [15] for Lisp, FeatureC++ [4] for C++, Xak [1] for XML, and oth- ers [8, 10, 14, 16, 21, 37]. While it has been noted that there is a unique core of all composition mechanisms based on superimposition [8], researchers have not condensed the essence of superimposition into a general methodology and tool chain for software composition. ...
Superimposition is a composition technique that has been applied successfully in many areas of software development. Although superimposition is a general-purpose concept, it has been (re)invented and implemented individually for various kinds of software artifacts. We unify languages and tools that rely on superimposition by using the language-independent model of feature structure trees (FSTs). On the basis of the FST model, we propose a general approach to the composition of software artifacts written in different languages, Furthermore, we offer a supporting framework and tool chain, called FEATUREHOUSE. We use attribute grammars to automate the integration of additional languages, in particular, we have integrated Java, C#, C, Haskell, JavaCC, and XML. Several case studies demonstrate the practicality and scalability of our approach and reveal insights into the properties a language must have in order to be ready for superimposition.
... As an alternative for XSL and AspectXML, an engine that allows enhancing XML document by means of refinements is presented in [1]. Refinements refer to functions (or composed functions) which incrementally introduce or override new element into XML documents. ...
Web applications are used to fast and continuous evolution. In response to new or changing requirements, additional code is developed and existing one is properly modified. When new requirements are temporary, i.e., when they specify some volatile functionality that is expected to be online only for some time and then removed, the additions and changes are destined to be later rolled back. This way to proceed, apart from being time and effort demanding, by involving the intrusive editing of the application's source code, brings along the risk of polluting it and introducing mistakes. In this paper, we present an approach to deal with volatile functionality in Web applications at the presentation level, based on oblivious composition of Web user interfaces. Our approach, which is inspired by well- known techniques for advanced separation of concerns such as aspect-oriented software design, allows to clearly separate the design of the application's core user interface from the one corresponding to more volatile functionality. Both core and volatile user interfaces are oblivious from each other and can be seamlessly composed using a transformation language. We show that in this way we simplify the application's evolution by preventing intrusive edition of the user interface code. Using some illustrative examples, we focus both on design and implementation issues, presenting an extension of the OOHDM design model that supports modular design of volatile functionality.
... The contribution of this paper is to apply step-wise renement to model transformations. MOFScript-based model-to-text transformations are rened by using XAK [1]. We illustrate our ideas with a simplistic case study, which is inspired on the industrial cases we work with. ...
... 0 " p r o t e c t e d=" t r u e " /> 12 </ x a k : e x t e n d s> 13 < !−−Content omitted−−> 14 </ x a k : r e f i n e s> A renement can be deemed of as a function that takes an artifact as an input, and returns another similar artifact which has been leveraged to support a given feature [3]. XAK is a language for dening renements in XML documents and provides a composer tool for them [1]. We used it for representing and composing our MOFScript-based transformations. ...
... Instead, the mapping of software artifacts to features is established via containment hierarchies, as explained in Section 2. The advantage of this approach is that a feature's implementation can include, beside classes in the form of Java files, also other supporting documents, e.g., documentation in the form of HTML files, grammar specification in the form of JavaCC files, or build scripts and deployment descriptors in the form of XML files [10] . To this end, feature composition merges not only classes with their refinements but also other artifacts such as HTML or XML files with their respective refinements [2, 9]. Jiazzi and C# are two languages that are commonly not associated with FOP but that provide very similar mechanisms. ...
Feature-oriented programming (FOP) is a paradigm that incorporates programming language technology, program generation techniques, and stepwise refinement. In their GPCE'07 paper, Thaker et al. suggest the development of a type system for FOP to guarantee safe feature composition, i.e, to guarantee the absence of type errors during feature composition. We present such a type system along with a calculus for a simple feature-oriented, Java-like language, called Feature Featherweight Java (FFJ). Furthermore, we explore four extensions of FFJ and how they affect type soundness.
