Fig 5 - uploaded by Oscar Díaz
Content may be subject to copyright.
Source publication
The promotion of a clear separation between artifact construction and artifact assembling is one of the hallmarks of software product lines. This work rests on the assumption that the mechanisms for producing products consider- ably quicker, cheaper or at a higher quality, rest not only on the artifacts but on the assembling process itself. This le...
Contexts in source publication
Context 1
... feature es_ES overrides the English locale of the base layer to the Spanish locale. The counterpart refinement is shown in figure 4. It includes extending <target name= “prebuild”> to copy appropriate resource files . Here the <xr:super-target/> constructor is used 10 . Both examples illustrate how refinements have been realized for Ant artifacts. Im- plementation wise, the composition operator for Ant is implemented using XSLT and XUpdate [13]. This operator can be integrated within AHEAD TS so that when build.xml artifacts are found, the composition process is governed by the Ant plug-in. Previous section focuses on Ant artifacts found within a layer. These artifacts describe the “ product-build process ” within a layer. By contrast, this section focuses on layer- composition processes that state how layers themselves should be composed. This com- prises the steps of the methodology being used. For AHEAD, these steps include: 1. feature selection. Output: a feature equation (e.g. “es_ES(Tomcat(base))”). 2. feature composition (i.e. layer composition in Batory’s parlance). Output: collective of artifacts that support an end product. 3. enactment of the build.xml associated with the end product. Output: end product ready to be used. Figure 5 illustrates the targets that realize previous steps ( the equation.name property holds the feature equation): – compose , which calls the AHEAD TS composer, – compose-build-xml , which supports the composition operator for build.xml artifact that AHEAD TS lacks, – execute-build-xml, which runs the Ant script supporting the production process of the end product, – produce , which performs the whole production. The enactment of this layer-composition script leads to an end product that exhibits the features of the input equation. AHEAD TS hard-codes this script. However, this work rests on the assumption that the mechanisms for producing products considerably quicker, cheaper or at a higher quality, rest not only on the arti- facts but on the assembling process itself. From this viewpoint, the inter-layer produc- tion process can accommodate important production strategies that affect the process rather than the characteristics of the final product. These strategies can affect the prod- uct costs, increase product quality, or improve the production process. Based on this observation, the previous base layer might be refined to account for distinct “process-features”. The example introduces two features which imply a refine- ment in this layer-composition process, namely – the version feature. Consider that security reasons recommend to version each new delivery of an end product. This implies that artifacts that conform the end product, should have appropriate backups. – the errorHandling feature. Errors can rise during the production process. How these errors are handled is not a characteristic of the product but depends on managerial strategies. Hence, the base process can be customized to support distinct strate- gies depending on the availability of resources or the quality requirements of the customer. Figure 7 shows how the base process can now be refined to account for the version feature, namely: – a new <target> is added to back up artifacts into the versioning system. For this purpose, Subversion is used 11 ...
Context 2
... equation versioning(base) leads to a “ product-specific plan” that supports the naive security policy of the organization. As further experience is gained, and stringent de- mands are placed, more sophisticated plans can be defined. Likewise, figure 5 shows the “substitution_eh” policy for error ...
Similar publications
Citations
... </copy> </target> <target name="copy-webpage" depends="create-folders"> <!--Copy webpages of Feature DownloadPaymentDetail --> <copy todir="${web-root.dir}"> <fileset dir="${core-webpage.dir}/${DownloadPaymentDetail}" /> </copy> </target> <project> Ant: An important class of configuration parameters was managed by Ant. [3] used Ant and configuration files to differentiate variability in process and variability in product. Lower layers always override the build.xml ...
Fudan Wingsoft Ltd. developed a product Line of Wingsoft Financial Management Systems (WFMS-PL) providing web-based financial services for employees and students at universities in China. The company used a wide range of variation mechanisms such as conditional compilation and configura- tion files to manage WFMS variant features. We studied this existing product line and found that most variant features had fine-grained impact on product line components. Our study also showed that different variation mechanisms had different, often complementary, strengths and weaknesses, and their choice should be mainly driven by the granularity and scope of feature impact on prod- uct line components. We hope our report will help companies evaluate and se- lect variation mechanisms when moving towards the product line approach.
... Recently, Wang et al. describe production " on the fly " where dynamic reconfiguration was used to support privacy in web applications[21]. Consider a typical production plan that implies the selection of product desired features in order to compose such selected features[9]. Then, when the raw compound product is obtained, it is necessary to create a binary (e.g., an executable, a JAR or a WAR). ...
Software product line is a paradigm to develop a family of software products with the goal of reuse. In this paper, we focus on a scenario in which different products from different product lines are combined together in a third product line to yield more elaborate products, i.e., a product line consumes products from third product line suppliers. The issue is not how different products can be produced separately, but how they can be combined together. We propose a service-oriented architecture where product lines are regarded as services, yielding a service-oriented product line. This paper illustrates the approach with an example for a service-oriented architecture of a web portal product line supplied by portlet product lines.
... As mentioned in [17], some knowledge management tools exist, but with little usage in the software architecture field. Diaz et al. tackle the variability of synthesis to deal with managerial strategies [8]. This work is the precursor to address such variability of synthesis at a higher abstraction level based on design decisions. ...
Software architectures represent the design of a system for describing its main relevant parts. Recently, recording and documenting architectural design decisions has attracted the attention of the software architecture community. Design decisions are an important piece during the architecting process that must be explicitly documented, but there is little evidence of successful reuse of this architectural knowledge. This work focuses on the reuse of design decisions in order to customize architectures. Specifically, we explore extensibility ideas from software product lines to show how architectures can be extended on the basis of design decisions. The documentation of synthesis architectures has received so far little attention, and particularly its reuse. This ongoing research describes an approach for product line synthesis architecture, where design decisions are introduced to promote its reuse.
... Application engineering focuses on reusing the software platform, and binding the variability as required for the different applications [21]. Details about using product-line techniques in a Web setting can be found at [1, 5, 8, 12, 22, 24]. These previous works introduce SPL as a means to reduce the time and costs of production and to increase the software quality by reusing elements which have already been tested and secured. ...
Portlets strive to play at the front end the same role that Web services currently enjoy at the back end, namely, enablers of application assembly through reusable services. However, it is well known in the component community that, the larger the component, the more reduced the reuse. Hence, the coarse-grained nature of portlets (they encapsulate also the presentation layer) can jeopardize this vision of portlets as reusable services. To avoid this situation, this work proposes a perspective shift in portlet development by introducing the notion of Consumer Profile. While the user profile characterizes the end user (e.g. age, name, etc), the Consumer Profile captures the idiosyncrasies of the organization through which the portlet is being delivered (e.g. the portal owner) as far as the portlet functionality is concerned. The user profile can be dynamic and hence, requires the portlet to be customized at runtime. By contrast, the Consumer Profile is known at registration time, and it is not always appropriate/possible to consider it at runtime. Rather, it is better to customize the code at development time, and produce an organization-specific portlet which built-in, custom functionality. In this scenario, we no longer have a portlet but a family of portlets, and the portlet provider becomes the “assembly line” of this family. This work promotes this vision by introducing an organization-aware, WSRP-compliant architecture that let portlet consumers registry and handle “family portlets” in the same way that “traditional portlets”. In so doing, portlets are nearer to become truly reusable services.
... XAK (pronounced " sack " ) is a tool for composing base and refinement artifacts in XML format. The need for XAK arose two years ago while developing SPLs for web applications using AHEAD [16] . An unusual characteristic of web applications is that a sizable fraction of their definition is not Java or Jak source, but rather XML specifications [16] (e.g., JSP, HTML, and Struts control flow files [2] ). ...
... The need for XAK arose two years ago while developing SPLs for web applications using AHEAD [16] . An unusual characteristic of web applications is that a sizable fraction of their definition is not Java or Jak source, but rather XML specifications [16] (e.g., JSP, HTML, and Struts control flow files [2] ). Thus, it is common for a feature of a web application to contain XML artifacts (base or refinements) and Jak source (base or refinements). ...
Abstract Feature refactoringis the process of decomposing a program into a set of modules, called features, that encapsulate increments in pro- gram functionality. Different compositions,of features yield differ- ent,programs. ,As programs ,are ,defined ,using ,multiple representations, such as code, makefiles, and documentation, fea- ture refactoring requires all representations to be factored. Thus, composing features produces consistent representations of code, makefiles, documentation, etc. for a target program. We present a case study of feature refactoring a substantial tool suite that uses multiple representations. We ,describe the key technical problems encountered, and sketch the tool support needed for simplifying such refactorings in the future. Categories and Subject Descriptors: D.2.7 [Distribution, Mainte-
... A FM can be defined as a compact representation of all possible products of an SPL. Furthermore, it is commonly accepted that FMs can be used in different stages of an SPL effort in order to produce other assets such as requirements documents [15,16], portlets–based applications [11,12] or even pieces of code [3,9,20]. Hence, FM becomes an important focus of research in the field of model transformation. ...
... Experiment 2 is the FM ofFigure 2 which represents a collaborative web based system. Experiment 3 is a medium size FM of a flight booking system based on the work done by [11,12] . Finally, we generated two larger FMs randomly (Experiments 4 and 5) with a double aim: representing more complex systems with a greater number of features and dependencies, and evaluating the solvers' performance in limit situations. ...
Feature Models are used in different stages of software development and are recognized to be an important asset in model transformation techniques and software product line development. The automated analysis of feature mod- els is being recognized as one of the key challenges for automated software de- velopment in the context of Software Product Lines. In our previous work we explained how a feature model can be transformed into a constraint satisfaction problem. However cardinalities were not considered. In this paper we present how a cardinality-based feature model can be also translated into a constraint satisfaction problem. In that connection, it is possible to use off-the-she lf tools to automatically accomplish several tasks such as calculating the number of possible feature configurations and detecting possible conflicts. In addition, we pr esent a performance test between two off-the-shelf Java constraint solvers. To the best of our knowledge, this is the first time a performance test is presented using solvers for feature modelling proposes
... Hence, layer equation is derived from feature selection making automatic product production possible. This is the case of web application-line production [7]. In this approach, layers are specified within the FM XML document. ...
... In the future we want to improve our tool support integrating our approach in XFeature using our reasoning framework [2]. Likewise, we are working in a prototype that allows the automatic generation of portal–based applications selecting features and transform them using the AHEAD tool [7]. ...
Feature Models (FM) are used to represent commonality and variabil-ity in Software Product Lines. Since the first proposal by Kang, the notation of FM has evolved in different ways: introducing cardinalities, using UML or XML notations, etcetera. In addition, the use of FMs is not only restricted to domain analysis because it is widely accepted that FMs can be used in different stages of SPL development in order to produce other assets such as requirements docu-ments, architectures, reasoning frameworks or even pieces of code. Hence, FMs turn into an important focus of research in the field of model transformation. In this context, two characteristics are needed: i) an agreed base faeture model and ii) a platform independent representation allowing extensions for specific needs. In this paper we propose an abstract feature model, providing an XML represen-tation and mechanisms to extend this model for a particular approach. Therefore, the contribution of this work is the modularization of the FM in order to cope with distinct development stages.
Product line approaches are well-known in many manufacturing industries, such as consumer electronics, medical systems and automotive [1]. In recent years, approaches with a similar background have rapidly emerged within Software Engineering, so called Software Product Line (SPL) approaches [2], [3]. As automotive manufacturers and suppliers design and implement complex applications, such as driver assistance [4], they strive for mechanisms that allow them to implement such functionality on integrated platforms. This offers the opportunity to build a variety of similar systems with a minimum of technical diversity and thus allows for strategic reuse of components. This has resulted in a growing interest in SPL approaches both in the software engineering and the automotive systems domain. This paper discusses the increasing importance that SPL approaches could play within the context of Automotive Systems Engineering. To accomplish this, we first provide an overview of the major challenges faced by Automotive Systems Engineering [5]. We then present a selection of SPL approaches, which could provide solutions for the described challenges. To complement this we make the case for empirical evaluation as a basis for well-founded decisions and selection of techniques. Finally, we present and in-depth discussion of how the approaches and techniques outlined can be used to address the identified challenges. The paper concludes with an overview of open research questions and expected benefits for the development of automotive systems.
Product Line Practice Initiative Unlimited distribution subject to the copyright.
