No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Experiences with Constructing and Evolving aSoftware Product Line with Delta-Oriented Programming
Software modernization is a common activity in software engineering, since technologies advance, requirements change, and business models evolve. Differently from conventional software evolution (e.g., adding new features, enhancing performance, or adapting to new requirements), software modernization involves re-engineering entire legacy systems (e.g., changing the technology stack, migrating to a new architecture style, or programming paradigms). Given the pervasive nature of software today, modernizing legacy systems is paramount to provide customers with competitive and innovative products and services, while keeping companies profitable. Despite the prevalent discussion of software modernization in gray literature, and the many papers in the literature, there is no work presenting a “big picture” of contemporary software modernization, describing challenges, and providing a well-defined research agenda. The goal of this work is to describe the state of the art in software modernization in the past 10 years. We collect the state of the art by performing a rapid review (searching five digital libraries), identifying potential 3,460 studies, leading to a final set of 127. We analyzed these studies to understand which strategies are employed, the driving forces that lead organizations to modernize their systems, and the challenges that need to be addressed. The results show that studies in the last 10 years have explored eight strategies for modernizing legacy systems, namely cloudification, architecture redesign, moving to a new programming language, targeting reuse optimization, software modernization for new hardware integration, practices to leverage automation, database modernization, and digital transformation. Modernization is triggered by 14 driving forces, with the most common ones being reducing operational costs, improving performance and scalability, and reducing complexity. In addition, based on the analysis of existing literature, we present a detailed discussion of research opportunities in this field. The main challenges are providing tooling support, followed by defining a modernization process and considering better evaluation metrics. The main contribution of our work is to equip practitioners and researchers with knowledge of the current state of contemporary software modernization so that they are aware of practices and challenges to be addressed when deciding to modernize legacy systems.
This paper presents SeamlessMDD – our open-source framework for a gradual and effortless transition from traditional development
to MDD (Model-Driven Development) that allows maintaining hand-
written and generated code intertwined without the need to adjust the web application architecture or the established way of work. We propose a novel workflow that is based on the following: (1) Incremental and iterative transformations derived from model versions comparison so that only code for affected model elements is generated or modified; (2) Integration of generated and hand-written code using API-based code generators, which operate on syntax trees of target programming languages; (3) Case-specific support for change propagation and conflict resolution (contrary to the VCS-based systems operating on the single line).
A product line is an approach for systematically managing configuration options of customizable systems, usually by means of features. Products are generated for configurations consisting of selected features. Product-line evolution can lead to unintended changes to product behavior. We illustrate that updating configurations after product-line evolution requires decisions of both, domain engineers responsible for product-line evolution as well as application engineers responsible for configurations. The challenge is that domain and application engineers might not be able to interact with each other. We propose a formal foundation and a methodology that enables domain engineers to guide application engineers through configuration evolution by sharing knowledge on product-line evolution and by defining automatic update operations for configurations. As an effect, we enable knowledge transfer between those engineers without the need for interactions. We evaluate our methodology on four large-scale industrial product lines. The results of the qualitative evaluation indicate that our method is flexible enough for real-world product-line evolution. The quantitative evaluation indicates that we detect product behavior changes for up to 55.3 % of the configurations which would not have been detected using existing methods.
Delta-oriented programming (DOP) is a flexible transformational approach to implement software product lines. In delta-oriented product lines, variants are generated by applying operations contained in delta modules to a (possibly empty) base program. These operations can add, remove or modify named elements in a program (e.g., classes, methods and fields in a Java program). This paper presents algorithms for refactoring a delta-oriented product line into monotonic form, i.e., either to contain add and modify operations only (monotonic increasing) or to contain remove and modify operations only (monotonic decreasing). Because of their simpler structure, monotonic delta-oriented product lines are easier to analyze. The algorithms are formalized by means of a core calculus for DOP of product lines of Java programs and their correctness and complexity are given.
Software product line adoption is a challenging task in software development organisations. There are some reports in the literature of how software product line engineering has been adopted in several companies using different variability management techniques and patterns. However, to the best of our knowledge, there are no empirical reports on how variability management is handled in companies that do not know about software product line methods and tools. In this paper we present an experience report observing variability management practices in a software development company that was unaware of software product line approaches. We briefly report how variability management is performed in different areas ranging from business architecture to software assets management. From the observation we report some open research opportunities for the future and foster further similar and more structured empirical studies on unaware software product line companies.
In model-based software development, models are primary artifacts which iteratively evolve and which have many versions during their lifetime. A clear representation of the changes between different versions of a model is the key to understanding and successfully managing the evolution of a model-based system. However, model comparison tools currently available display model differences on a low level of abstraction, namely in terms of basic graph operations on the abstract syntax graph of a model. These low-level model differences are often hard or even impossible to understand for normal tool users who are not familiar with meta-models. In this paper we present SiLift, a generic tool environment which is able to semantically lift low-level differences of EMF-based models into representations of user-level edit operations.
Diversity is prevalent in modern software systems to facilitate adapting the software to customer requirements or the execution environment. Diversity has an impact on all phases of the software development process. Appropriate means and organizational structures are required to deal with the additional complexity introduced by software variability. This introductory article to the special section “Software Diversity—Modeling, Analysis and Evolution” provides an overview of the current state of the art in diverse systems development and discusses challenges and potential solutions. The article covers requirements analysis, design, implementation, verification and validation, maintenance and evolution as well as organizational aspects. It also provides an overview of the articles which are part of this special section and addresses particular issues of diverse systems development.
Using a reactive software product line approach, Salion made the transition to software product lines with 2 person-months of effort, the
equivalent of 1% of the effort required to build its baseline enterprise software product. This is two orders-of-magnitude
less than the effort typically reported with proactive software product line transition efforts. Since the transition, Salion has achieved 90-day time-to-market intervals for seven
new commercial products in its software product line, with each new product deployment requiring only 10% of the effort required
to build its baseline enterprise software product. This report summarizes Salion’s experience with a reactive software product
line approach, some of the unique contributions of the experience, and generalizations that characterize how other organizations
may benefit from reactive product line techniques.
Delta modeling is a method for modeling software product lines (SPL), which supports the automated derivation of products. ABS is a recent modeling language and accompanying toolset that implements delta modeling as its core paradigm for developing variable systems. Due to its novelty, delta modeling has so far seen little practical application. However, only practical evaluation can indicate to what extent the delta modeling methodology is suited for the efficient and accurate modeling and implementation of SPLs. This paper reports on the development of an industrial scale product line in ABS following a workflow that guides the application of delta modeling in practice. By following the delta modeling workflow (DMW), we show how conflicting feature functionality can be systematically reconciled, and how DMW guides the implementation towards a globally unambiguous and complete product line. We further explain how this experience has been used to refine the workflow and its support by the ABS language.
The HATS project aims at developing a model-centric methodology for the design, implementation and verification of highly configurable systems, such as software product lines, centred around the Abstract Behavioural Specification (ABS) modelling Language. This article describes the variability modelling features of the ABS Modelling framework. It consists of four languages, namely, μ TVL for describing feature models at a high level of abstraction, the Delta Modelling Language DML for describing variability of the ‘code' base in terms of delta modules, the Product Line Configuration Language CL for linking feature models and delta modules together and the Product Selection Language PSL for describing a specific product to extract from a product line. Both formal semantics and examples of each language are presented.
This paper presents a case study of creating a software product line for the train signaling domain. The Train Control Language
(TCL) is a DSL which automates the production of source code for computers controlling train stations. By applying the Common
Variability Language (CVL), which is a separate and generic language to define variability on base models, we form a software
product line of stations. We discuss the process and experience of using CVL to automate the production of three real train
stations. A brief discussion about the verification needed for the generated products is also included.
Feature-oriented programming (FOP) implements software product lines by composition of feature modules. It relies on the principles
of stepwise development. Feature modules are intended to refer to exactly one product feature and can only extend existing
implementations. To provide more flexibility for implementing software product lines, we propose delta-oriented programming
(DOP) as a novel programming language approach. A product line is represented by a core module and a set of delta modules.
The core module provides an implementation of a valid product that can be developed with well-established single application
engineering techniques. Delta modules specify changes to be applied to the core module to implement further products by adding,
modifying and removing code. Application conditions attached to delta modules allow handling combinations of features explicitly.
A product implementation for a particular feature configuration is generated by applying incrementally all delta modules with
valid application condition to the core module. In order to evaluate the potential of DOP, we compare it to FOP, both conceptually
and empirically.
Software Product Lines (SPLs) are an approach for large-scale reuse for software families by means of variabilities and commonalities. We consider three dimensions of variability representing sources of software systems to behave differently: configuration as spatial variability, dependence on surroundings as contextual variability and evolution as temporal variability. The three dimensions of variability strongly correlate: Contextual variability changes the set of possible configurations in spatial variability. Temporal variability captures changes of spatial and contextual variability over the course of time. However, currently, there is no tool support for integrated modeling of these three dimensions of variability. In this paper, we present DarwinSPL, a tool suite supporting integrated definition of spatial, contextual and temporal variability. With DarwinSPL, spatial variability is modeled as feature models with constraints. Additionally, we are able to capture the current context and its impact on functionality of the SPL. Moreover, by providing support for temporal variability, DarwinSPL supports performing arbitrary evolutionary changes to spatial and contextual variability and tracking of previous evolution and planning future evolution of SPLs. We show the feasibility of DarwinSPL by performing a case study adapted from our industrial partner in the automotive domain.
Software product line implementation techniques are complementary. Thus, moving fluidly between them would be beneficial. Our tool PEoPL, a novel instantiation of the MPS language workbench, supports projecting a common variational AST into user-editable projections, each of which represents a different product line implementation technique. PEoPL supports FOP-like, annotative and product projections and allows developers to move fluidly between them. In this paper, we lay the foundation for future delta-oriented projectional editors. We use an example scenario to discuss a mapping of DeltaJ language concepts to the variational AST and operations employed in PEoPL. In a case study, we show that PEoPL is expressive enough to represent DeltaJ product lines, and at the same time supports all delta manipulations.
Software Product Line (SPLs) are an approach to reuse in-the-large that models a set of closely related software systems in terms of commonalities and variabilities. Design patterns are best practices for addressing recurring design problems in object-oriented source code. In the practice of implementing SPL, instances of certain design patterns are employed to handle variability, which makes these “variability-aware design patterns” a best practice for SPL design. However, there currently is no dedicated method for proactively developing SPLs using design patterns suitable for realizing variable functionality. In this paper, we present a method to perform generative SPL development with design patterns. We use role models to capture design patterns and their relation to a variability model. We further allow mapping of individual design pattern roles to (parts of) implementation elements to be generated (e.g., classes, methods) and check the conformance of the realization with the specification of the pattern. We provide definitions for the variability-aware versions of the design patterns Observer, Strategy, Template Method and Composite. Furthermore, we support generation of realizations in Java, C++ and UML class diagrams utilizing annotative, compositional and transformational variability realization mechanisms. Hence, we support proactive development of SPLs using design patterns to apply best practices for the realization of variability. We realize our concepts within the Eclipse IDE and demonstrate them within a case study.
Software Product Lines (SPLs) are an approach to reuse in-the-large that models a set of closely related software systems in terms of commonalities and variabilities. Design patterns are best practices for addressing recurring design problems in object-oriented source code. In the practice of implementing an SPL, instances of certain design patterns are employed to handle variability, which makes these "variability-aware design patterns" a best practice for SPL design. However, there currently is no dedicated method for proactively developing SPL using design patterns suitable for realizing variable functionality. In this paper, we present a method to perform generative SPL development with design patterns. We use role models to capture design patterns and their relation to a variability model. We further allow mapping of individual design pattern roles to elements of realization artifacts to be generated (e.g., classes, methods) and check the conformance of the realization with the specification of the pattern. With this method, we support proactive development of SPL using design patterns to apply best practices for the realization of variability. We present an implementation of our approach within the Eclipse IDE and demonstrate it within a case study.
Software Product Lines (SPLs) are an approach to reuse in-the-large that models a set of closely related software systems in terms of commonalities and variabilities. Design patterns are best practices for addressing recurring design problems in object-oriented source code. In the practice of implementing an SPL, instances of certain design patterns are employed to handle variability, which makes these "variability-aware design patterns" a best practice for SPL design. However, there currently is no dedicated method for proactively developing SPLs using design patterns suitable for realizing variable functionality. In this paper, we present a method to perform generative SPL development with design patterns. We use role models to capture design patterns and their relation to a variability model. We further allow mapping of individual design pattern roles to elements of realization artifacts to be generated (e.g., classes, methods) and check the conformance of the realization with the specification of the pattern. With this method, we support proactive development of SPLs using design patterns to apply best practices for the realization of variability. We present an implementation of our approach within the Eclipse IDE and demonstrate it within a case study.
Imprecise, frequently changing requirements and short time-to-market create challenges for application of conventional software methods in Web Portal engineering. To address these challenges, ST Electronics (Info-Software Systems) Pte. Ltd. applied a lightweight, reactive approach to support a Web Portal product line. Unique characteristics of the approach were fast, low-cost migration from a single conventional Web Portal towards a reusable "generic Web Portal" solution, effective handling of large number of functional variants and their dependencies, the ability to rapidly develop new Web Portals from the generic one, and to independently evolve multiple Web Portals without ever losing a connection between them and the "generic Web Portal". The initial Web Portal was built using state-of-the-art conventional methods. The Web Portal was not flexible enough to reap the benefits of new business opportunities that required the company to rapidly develop and further maintain many similar Web Portals. To overcome the limitations of the conventional solution, a reuse technique called XVCL was applied incrementally. Over a period of three weeks, the conventional solution was converted into a Web architecture capable of handling nine Web Portals from a base of code smaller than the original Web Portal. In the paper, we describe the process that led to building the above Web Portal product line. We explain the difficulties in building an effective generic Web solution using conventional techniques. We analyze our reuse-based solution in qualitative and quantitative ways.
When we attempted to introduce an extractive approach to a company, we were faced with a challenging project situation where
legacy applications did not have many commonalities among their implementations as they were developed independently by different
teams without sharing a common code base. Although there were not many structural similarities, we expected to find similarities
if we view them from the domain model perspective as they were in the same domain and were developed with the object-oriented
paradigm. Therefore, we decided to place the domain model at the center of extraction and reengineering, thus developing a
domain model-based extractive method. The method has been successfully applied to introduce software product line to a set-top
box manufacturing company.
Over six years ago, Cummins Engine Company established a software product line for its real-time embedded diesel engine controls. The engine controls product line requirements domain is very complex. As the world’s largest manufacturer of diesel engines over 200 horsepower, Cummins makes engines for a large, world-wide variety of applications, customers, original equipment manufacturers (OEMs), engine sizes, and engine configurations. The software product line program slashed development costs and cycle time across these highly varying products and launched many successful products over the past four years. Over these years, Cummins has crossed many hurdles and gained a great deal of experience developing, documenting and maintaining a software product line architecture. This paper describes the experience. It focuses on the development process and covers topics such as domain analysis, architectural views, and use of the Software Engineering Institute (SEI) practices and literature to guide the development approach. Also described are the architecture development process, the organizational challenges faced, and the lessons learned.
It is often believed that reusable solutions, being generic, must neces- sarily compromise performance. In this paper, we consider a family of Role- Playing Games (RPGs). We analyzed similarities and differences among four RPGs. By applying a reuse technique of XVCL, we built an RPG product line architecture (RPG-PLA) from which we could derive any of the four RPGs. We built into the RPG-PLA a number of performance optimization strategies that could benefit any of the four (and possibly other similar) RPGs. By comparing the original vs. the new RPGs derived from the RPG-PLA, we demonstrated that reuse allowed us to achieve improved performance, both speed and mem- ory utilization, as compared to each game developed individually. At the same time, our solution facilitated rapid development of new games, for new mobile devices, as well as ease of evolving with new features the RPG-PLA and cus- tom games already in use.
Feature models are used to specify members of a product-line. Despite years of progress, contemporary tools provide limited support for fea- ture constraints and offer little or no support for debugging feature models. We integrate prior results to connect feature models, grammars, and propositional formulas. This connection allows arbitrary propositional constraints to be defined among features and enables off-the-shelf satisfiability solvers to debug feature models. We also show how our ideas can generalize recent results on the staged configuration of feature models.
The genesis of HomeAway, Inc. was startup by accretion - eight companies in the web-based vacation home rental market were acquired and merged. The technical solution during the merger and acquisition phase was to assimilate the software functionality of each of the eight companies into a one-size-fits-all application that could be configured with runtime settings to support the look-and-feel of the original eight. When rapid growth and an aggressive business plan pushed the one-size-fits-all approach beyond its limits, HomeAway decisively applied the 3-tiered software product line (SPL) methodology and the gears unified SPL Framework to transition to a software product line practice. This case study explores how HomeAway leveraged the 3-tiered methodology and gears to make their transition, accelerate software development, reduce defect density, lower development overhead, and extend the scalability of its portfolio to better achieve its aggressive business goals - all within 60 days.