Software Product Lines (SPLs) typically provide a large number of configurations to cater to a set of diverse requirements of specific markets. This large number of configurations renders unfeasible to test them all individually. Instead, Combinatorial Interaction Testing (CIT) computes a representative sample according to criteria of the interactions of features in the configurations. We performed an empirical study using eye-tracker technologies to analyze the effectiveness of two basic visualization techniques at conveying test coverage information of ten case studies of varying complexity. Our evaluation considered response accuracy, time-on-task, metacognitive monitoring, and visual attention. The study revealed clear advantages of a visualization technique over the other in three evaluation aspects, with a reverse effect depending on the strength of the coverage and distinct areas of visual attention. • Study of visualization techniques for interaction testing of Software Product Lines. • Analysis of visual attention using eye-trackers for coverage testing tasks. • Scatter plots and Parallel dimensions plots offer different performance trade-offs.

Abstract Software companies commonly develop and maintain variants of systems, with different feature combinations for different customers. Thus, they must cope with variability in space. Software companies further must cope with variability in time, when updating system variants by revising existing software features. Inevitably, variants evolve orthogonally along these two dimensions, resulting in challenges for software maintenance. Our work addresses this challenge with ECSEST (Extraction and Composition for Systems Evolving in Space and Time), an approach for locating feature revisions and composing variants with different feature revisions. We evaluated ECSEST using feature revisions and variants from six highly configurable open source systems. To assess the correctness of our approach, we compared the artifacts of input variants with the artifacts from the corresponding composed variants based on the implementation of the extracted features. The extracted traces allowed composing variants with 99-100% precision, as well as with 97-99% average recall. Regarding the composition of variants with new configurations, our approach can combine different feature revisions with 99% precision and recall on average. Additionally, our approach retrieves hints when composing new configurations, which are useful to find artifacts that may have to be added or removed for completing a product. The hints help to understand possible feature interactions or dependencies. The average time to locate feature revisions ranged from 25 to 250 seconds, whereas the average time for composing a variant was 18 seconds. Therefore, our experiments demonstrate that ECSEST is feasible and effective.

Developers change models with clear intentions-e.g., for refactoring, defects removal, or evolution. However, in doing so, developers are often unaware of the consequences of their changes. Changes to one part of a model may affect other parts of the same model and/or even other models, possibly created and maintained by other developers. The consequences are incomplete changes and with it inconsistencies within or across models. Extensive works exist on detecting and repairing inconsistencies. However, the literature tends to focus on inconsistencies as errors in need of repairs rather than on incomplete changes in need of further propagation. Many changes are non-trivial and require a series of coordinated model changes. As developers start changing the model, intermittent inconsistencies arise with other parts of the model that developers have not yet changed. These inconsistencies are cues for incomplete change propagation. Resolving these inconsistencies should be done in a manner that is consistent with the original changes. We speak of consistent change propagation. This paper leverages classical inconsistency repair mechanisms to explore the vast search space of change propagation. Our approach not only suggests changes to repair a given inconsistency but also changes to repair inconsistencies caused by the aforementioned repair. In doing so, our approach follows the developer's intent where subsequent changes may not contradict or backtrack earlier changes. We argue that consistent change propagation is essential for effective model-driven engineering. Our approach and its tool implementation were empirically assessed on 18 case studies from industry, academia, and GitHub to demonstrate its feasibility and scalability. A comparison with two versioned models shows that our approach identifies actual repair sequences that developers had chosen. Furthermore, an experiment involving 22 participants shows that our change propagation approach meets the workflow of how developers handle changes by always computing the sequence of repairs resulting from the change propagation.

Autism Spectrum Disorder (ASD) is a neurodevelopmental condition characterized by social interaction and communication difficulties, along with narrow and repetitive interests. Being a spectrum disorder, ASD affects individuals with a large range of combinations of challenges along dimensions such as intelligence, social skills, or sensory processing. Hence, any computer-based technology for ASD ought to be customizable to fit the particular profile of each individual that uses it. The main goal of our survey is to collect and characterize the customization support that has been researched for these technologies, which we analyze along clinical and technological dimensions. Our survey revealed that despite its importance, customization support for these technologies remains a subject largely unexplored. Furthermore, we propose alternatives on how to address the limitations identified.

Robust and effective support for the detection and management of software features and their interactions is crucial for many development tasks but has proven to be an elusive goal despite extensive research on the subject. This is especially challenging for variable systems where multiple variants of a system and their features must be collectively considered. Here an important issue is the typically large number of feature interactions that can occur in variable systems. We propose a method that computes, from a set of known source code level interactions of n features, the relevant interactions involving n+1 features. Our method is based on the insight that, if a set of features interact, it is much more likely that these features also interact with additional features, as opposed to completely different features interacting. This key insight enables us to drastically prune the space of potential feature interactions to those that will have a true impact at source code level. This substantial space reduction can be leveraged by analysis techniques that are based on feature interactions (e.g Combinatorial Interaction Testing). Our observation is based on eight variable systems, implemented in Java and C, totaling over nine million LoC, with over seven thousand feature interactions.

This extended abstract summarizes our article entitled "Teaching Software Product Lines: A Snapshot of Current Practices and Challenges" published in the ACM Transactions on Computing Education, vol. 18 in 2017 (http://doi.acm.org/10.1145/3088440). The article reports on three initiatives we have conducted with scholars, educators, industry practitioners, and students to understand the connection between software product lines and education and to derive recommendations for educators to continue improving the state of practice of teaching SPLs.

Education has a key role to play for disseminating the constantly growing body of Software Product Line (SPL) knowledge. In a sense, every researcher in SPL should think about how to teach SPL. This workshop aims to explore and explain the current status and ongoing work on teaching SPLs at universities, colleges, and in industry (e.g., by consultants). This third edition will continue the effort made at SPLTea'14 and SPLTea'15. In particular we seek to attract experience reports of teaching SPLs. We expect several lightning talks that report on traditional questions like: what is the targeted audience? What is the place in the curriculum? What is the material (slides, tools, books, etc) used? What are the benefits of teaching SPLs? What are the difficulties and barriers? We also welcome opinionated and provocative talks that encourage discussions about the topic. Another goal of the workshop is to populate an open repository of resources dedicated to SPL teaching: http://teaching.variability.io

Fast changing hardware and software technologies in addition to larger and more specialized customer bases demand software tailored to meet very diverse requirements. Software development approaches that aim at capturing this diversity on a single consolidated platform (i.e. software product lines [5]) often require large upfront investments of time and money. Alternatively, companies resort to developing one variant of a software product at a time by reusing as much as possible from already existing product variants (i.e. clone-and-own [2]). However, identifying and extracting the parts to reuse is an error-prone and inefficient task. Hence, more disciplined and systematic approaches are needed to cope with the complexity of developing and maintaining sets of product variants. Such approaches require detailed information about the product variants, the features they provide and their relations.

Software Product Line (SPL) migration remains a challenging endeavour. From organizational issues to purely technical challenges, there is a wide range of barriers that complicates SPL adoption. The workshop REverse Variability Engineering (REVE) aims to foster research about making the most of the two main inputs for SPL migration: 1) domain knowledge and 2) legacy assets. Domain knowledge, usually implicit and spread across an organization, is key to define the SPL scope and to validate the variability model and its semantics. At the technical level, domain expertise is also needed to create or extract the reusable software components. Legacy assets can be, for instance, similar product variants (e.g., requirements, models, source code) that were implemented using ad-hoc reuse techniques such as clone-and-own. More generally, the workshop attracts researchers and practitioners contributing to processes, techniques, tools, or empirical studies related to the automatic, semi-automatic or manual extraction or refinement of SPL assets.

Abstract Software product lines (SPLs) are families of related systems whose members are distinguished by the set of features they provide. Over 2 decades of research and practice can attest to the substantial benefits of applying SPL practices such as better customization, improved software reuse, and faster time to market. Software product line engineering (SPLE) refers to the paradigm of developing SPLs. Typical SPLE efforts involve a large number of features that are combined to form also large numbers of products, implemented using multiple and different types of software artifacts. Because of the sheer amount of information and its complexity, visualization techniques have been used for different SPLE activities. In this paper, we present an extended systematic mapping study on this subject. Our research questions aim to gather information regarding the techniques that have been applied, at what SPLE activities, how they were implemented, the publication fora used, the methods of empirical evaluation, and the provenance of the evaluation examples. Our driving goal is to identify common trends, gaps, and opportunities for further research and application.

A common task performed in model-driven software engineering is evolving models. This task is typically performed manually during the design or implementation phase of software projects and is known to cause inconsistencies. Despite extensive research on consistency checking, existing approaches either provide abstract (i.e., incomplete) repairs only, or they require manually predefined strategies on how to repair inconsistencies. In this paper, we present a novel approach that provides concrete (i.e., executable) repairs without the need of predefined repair strategies. Furthermore, our approach proposes functions which automate the generation of concrete repairs at runtime. An empirical assessment of the approach on six case studies from industry, academia and GitHub demonstrates its feasibility, and shows that the provided concrete repairs are relevant and can fix their corresponding inconsistencies automatically.

Software Product Line (SPL) engineering has emerged to provide the means to efficiently model, produce, and maintain multiple similar software variants, exploiting their common properties, and managing their variabilities (differences). With over two decades of existence, the community of SPL researchers and practitioners is thriving, as can be attested by the extensive research output and the numerous successful industrial projects. Education has a key role to support the next generation of practitioners to build highly complex, variability-intensive systems. Yet, it is unclear how the concepts of variability and SPLs are taught, what are the possible missing gaps and difficulties faced, what are the benefits, and what is the material available. Also, it remains unclear whether scholars teach what is actually needed by industry. In this article, we report on three initiatives we have conducted with scholars, educators, industry practitioners, and students to further understand the connection between SPLs and education, that is, an online survey on teaching SPLs we performed with 35 scholars, another survey on learning SPLs we conducted with 25 students, as well as two workshops held at the International Software Product Line Conference in 2014 and 2015 with both researchers and industry practitioners participating. We build upon the two surveys and the workshops to derive recommendations for educators to continue improving the state of practice of teaching SPLs, aimed at both individual educators as well as the wider community.

Fast-changing hardware and software technologies in addition to larger and more specialized customer bases demand software tailored to meet very diverse requirements. Software development approaches that aim at capturing this diversity on a single consolidated platform often require large upfront investments, e.g., time or budget. Alternatively, companies resort to developing one variant of a software product at a time by reusing as much as possible from already-existing product variants. However, identifying and extracting the parts to reuse is an error-prone and inefficient task compounded by the typically large number of product variants. Hence, more disciplined and systematic approaches are needed to cope with the complexity of developing and maintaining sets of product variants. Such approaches require detailed information about the product variants, the features they provide and their relations. In this paper, we present an approach to extract such variability information from product variants. It identifies traces from features and feature interactions to their implementation artifacts, and computes their dependencies. This work can be useful in many scenarios ranging from ad hoc development approaches such as clone-and-own to systematic reuse approaches such as software product lines. We applied our variability extraction approach to six case studies and provide a detailed evaluation. The results show that the extracted variability information is consistent with the variability in our six case study systems given by their variability models and available product variants.

Robust and effective support for the detection and management of features and their interactions is crucial for many software development tasks but has proven to be an elusive goal despite the extensive research and practice on the subject. Providing the required support becomes even more challenging with variable software whereby multiple variants of a system and their features must be collectively considered. An important premise to provide better support for feature interactions in variable systems is the need of a deeper understanding on how features interact at different levels starting from the source level. In this context, recent work has looked at feature interactions from different angles and for different purposes, for instance for developing performance models, extracting interfaces for maintenance or describing feature evolution patterns. However, there is a gap in understanding how features interact in fact at the source level in contrast with how features ought to interact according to variability models that describe the valid combinations of features in variable software systems. In this paper we perform an empirical study to explore this gap. We use seven case studies, implemented in Java and C, totalling over nine million LoC, and analysed over seven thousand feature interactions. Our study revealed important inconsistencies between how feature interactions occur at source level and how they are modeled, and corroborated that the majority of source level interactions involve less than three features. We discuss the implications of our findings and avenues for further research.

From organizational issues to purely technical challenges, there is a wide range of barriers that complicates Software Product Line (SPL) adoption. This workshop aims to foster research about making the most of two main inputs for SPL migration: 1) domain knowledge and 2) existing legacy assets. Domain knowledge, usually implicit and spread across an organization, is key to define the SPL scope and to validate the variability model and its semantics. At the technical level, domain expertise is also needed to create reusable software components. Regarding legacy assets, they use to be similar product variants (e.g. requirements, models, source code etc.) that were implemented using ad-hoc reuse techniques such as clone-and-own. These assets can be leveraged in extractive SPL adoption processes. The workshop REverse Variability Engineering (REVE) attracts researchers and practitioners contributing processes, techniques, tools, or empirical studies related to the automatic, semi-automatic or manual extraction or refinement of SPL assets.

Software Product Lines (SPLs) are families of related systems whose members are distinguished by the set of features they provide. To effectively evolve and maintain SPLs it is vital to understand how features are implemented and how they interact at different levels from source code to runtime. However the large number of features and the complex nature of interactions in typical SPLs make maintenance and evolution tasks challenging, and demand robust tool support for the software engineers to carry out these tasks. In this paper we present the first results of our ongoing work to address this need. We put forward four visualizations that focus on features and their interactions at source code level, evaluate them with four case studies, and sketch our future work.

Software Product Lines (SPLs) are families of related systems whose members are distinguished by the set of features they provide. Over two decades of research and practice can attest to the substantial benefits of applying SPL practices such as better customization, improved software reuse, and faster time to market. Typical SPLs involve large number of features which are combined to form also large numbers of products, implemented using multiple and different types of software artifacts. Because of the sheer amount of information and its complexity visualization techniques have been used at different stages of the life cycle of SPLs. In this paper we present a systematic mapping study on this subject. Our research questions aim to gather information regarding the techniques that have been applied, at what stages, how they were implemented, and the publication fora employed. Our goal is to identify common trends, gaps, and opportunities for further research and application.

To effectively cope with increasing customization demands, companies that have developed variants of software systems are faced with the challenge of consolidating all the variants into a Software Product Line, a proven development paradigm capable of handling such demands. A crucial step in this challenge is to reverse engineer feature models that capture all the required feature combinations of each system variant. Current research has explored this task using propositional logic, natural language, and search-based techniques. However, using knowledge from the implementation artifacts for the reverse engineering task has not been studied. We propose a multi-objective approach that not only uses standard precision and recall metrics for the combinations of features but that also considers variability-safety, i.e. the property that, based on structural dependencies among elements of implementation artifacts, asserts whether all feature combinations of a feature model are in fact well-formed software systems. We evaluate our approach with five case studies and highlight its benefits for the software engineer.

Software reuse has become mandatory for companies to compete and a wide range of reuse techniques are available today. However, ad hoc practices such as copying existing systems and customizing them to meet customer-specific needs are still pervasive, and are generically called clone-and-own. We have developed a conceptual framework to support this practice named ECCO that stands for Extraction and Composition for Clone-and-Own. In this paper we present our Eclipse-based tool to support this approach. Our tool can automatically locate reusable parts from previously developed products and subsequently compose a new product from a selection of desired features. The tools demonstration video can be found here: http://youtu.be/N6gPekuxU6o.

Education has a key role to play for disseminating the constantly growing body of Software Product Line (SPL) knowledge. Teaching SPLs is challenging; it is unclear, for example, how SPLs can be taught and what is the material available. This workshop aims to explore and explain the current status and ongoing work on teaching SPLs at universities, colleges, and in industry (e.g., by consultants). This second edition will continue the effort made at SPLTea'14. In particular we seek to design and populate an open repository of resources dedicated to SPL teaching.

Variability management of a product family is the core aspect of Software Product Line Engineering. The adoption of this mature approach requires a high upfront investment before being able to automatically generate product instances based on customer requirements. However, this adoption costs and risks could be reduced with an incremental approach, which mines existing assets and then transitions to full product line engineering. Those existing assets can be for instance similar product variants that were implemented using ad-hoc reuse techniques such as clone-and-own. Hence, there is a great need of bottom-up approaches that extract variability from the artifacts (across all the life cycle) of the legacy product variants and manage the consolidated variability. The REVE workshop series aims to bring together the Reengineering and Software Product Line Engineering communities to address this gap.

Software Product Lines (SPLs) are families of related software products, each with its own set of feature combinations. Their commonly large number of products poses a unique set of challenges for software testing as it might not be technologically or economically feasible to test of all them individually. SPL pairwise testing aims at selecting a set of products to test such that all possible combinations of two features are covered by at least one selected product. Most approaches for SPL pairwise testing have focused on achieving full coverage of all pairwise feature combinations with the minimum number of products to test. Though useful in many contexts, this single-objective perspective does not reflect the prevailing scenario where software engineers do face trade-offs between the objectives of maximizing the coverage or minimizing the number of products to test. In contrast and to address this need, our work is the first to propose a classical multi-objective formalisation where both objectives are equally important. In this paper, we study the application to SPL pairwise testing of four classical multi-objective evolutionary algorithms. We developed three seeding strategies — techniques that leverage problem domain knowledge — and measured their performance impact on a large and diverse corpus of case studies using two well-known multi-objective quality measures. Our study identifies the performance differences among the algorithms and corroborates that the more domain knowledge leveraged the better the search results. Our findings enable software engineers to select not just one solution (as in the case of single-objective techniques) but instead to select from an array of test suite possibilities the one that best matches the economical and technological constraints of their testing context.

Software Product Lines (SPLs) are families of related software systems, which provide different feature combinations. Different SPL testing approaches have been proposed. However, despite the extensive and successful use of evolutionary computation techniques for software testing, their application to SPL testing remains largely unexplored. In this paper we present the Parallel Prioritized product line Genetic Solver (PPGS), a parallel genetic algorithm for the generation of prioritized pairwise testing suites for SPLs. We perform an extensive and comprehensive analysis of PPGS with 235 feature models from a wide range of number of features and products, using 3 different priority assignment schemes and 5 product prioritization selection strategies. We also compare PPGS with the greedy algorithm prioritized-ICPL. Our study reveals that overall PPGS obtains smaller covering arrays with an acceptable performance difference with prioritized-ICPL.

To keep pace with the increasing demand for custom-tailored software systems, companies often apply a practice called clone-and-own, whereby a new variant of a software system is built by coping and adapting existing variants. Instead of a single and configurable system, clone-and-own leads to ad hoc product portfolios of multiple yet similar variants that soon become impossible to maintain effectively. Clone-and-own has widespread industrial use because it requires no major upfront investments and is intuitive, but it lacks a methodology for systematic reuse. In this work we propose ECCO (Extraction and Composition for Clone-and-Own), a novel approach to enhance clone and-own that actively supports the development and maintenance of software product variants. A software engineer selects the desired features and ECCO finds the proper software artifacts to reuse and then provides guidance during the manual completion by hinting which software artifacts may need adaptation. We evaluated our approach on 6 case studies, covering 402 variants having up to 344KLOC, and found that precision and recall of composed products quickly reach a near optimum (>95% reuse).

Software engineering methods for analyzing and managing variable software systems rely on accurate feature-to-code mappings to relate high-level variability abstractions, such as features or decisions, to locations in the code where variability occurs. Due to the continuous and long-term evolution of many systems such mappings need to be extracted and updated automatically. However, current approaches have limitations regarding the analysis of highly-configurable systems that rely on different variability mechanisms. We present a novel approach that exploits the synergies between program analysis and doffing techniques to reveal feature-to-code mappings for highly-configurable systems. We demonstrate the feasibility of our approach with a set of products from a real-world product line in the domain of industrial automation.

Software Product Lines (SPLs) have gained popularity in industry as they foster the reuse of artifacts, such as code, and reduce product development effort. Although some SPLs ensure that only valid products are configurable, those products are not necessarily optimal. For instance, they may include code that is not necessary for providing the desired functionality -- often because of erroneous traceability between features and code. Such unnecessary code may be disallowed in safety critical domains, it may lead to losses in runtime performance, or it may lead to errors during later SPL evolution. In this paper, we present an approach for automatic and incremental product optimization. Our approach leverages product functionality tests to ensure that configured products do not include unnecessary artifacts -- an automatic re-optimization of products after SPL evolution is performed incrementally. The evaluation results show that such a re-optimization takes only milliseconds.

Education has a key role to play for disseminating the constantly growing body of Software Product Line (SPL) knowledge. Teaching SPLs is challenging and it is unclear how SPLs can be taught, what are the possible benefits, or what is the material available. This workshop aims to explore and explain the current status and ongoing work on teaching SPLs at universities, colleges, and in industry (e.g., by consultants). Participants will discuss gaps and difficulties faced when teaching SPLs, benefits to research and industry, different ways to teach SPL knowledge, common threads, interests, and problems. The overall goal is to strengthen the important aspect of teaching in the SPL community.

Variability management of a product family is the core aspect of Software Product Line Engineering. The adoption of this mature approach requires a high upfront investment before being able to automatically generate product instances based on customer requirements. However, this adoption costs and risks could be reduced with an incremental approach, which mines existing assets and then transitions to full product line engineering. Those existing assets can be for instance similar product variants that were implemented using ad-hoc reuse techniques such as clone-and-own. Bottom-up approaches to automatically extract variability management related artifacts could be proposed, applied, validated and improved in this domain therefore the REVE workshop aims to fill the gap between the Reengineering and Software Product Line Engineering communities.

Lopez-Herrejon, R. E., Chicano F., Ferrer J., Egyed A., & Alba E. (2013). Multi-objective Optimal Test Suite Computation for Software Product Line Pairwise Testing. 2013 IEEE International Conference on Software Maintenance, Eindhoven, The Netherlands, September 22-28, 2013. 404–407.

Many companies offer a palette of similar software products though they do not necessarily have a Software Product Line (SPL). Rather, they start building and selling individual products which they then adapt, customize and extend for different customers. As the number of product variants increases, these companies then face the severe problem of having to maintain them all. Software Product Lines can be helpful here - not so much as a platform for creating new products but as a means of maintaining the existing ones with their shared features. Here, an important first step is to determine where features are implemented in the source code and in what product variants. To this end, this paper presents a novel technique for deriving the traceability between features and code in product variants by matching code overlaps and feature overlaps. This is a difficult problem because a feature's implementation not only covers its basic functionality (which does not change across product variants) but may include code that deals with feature interaction issues and thus changes depending on the combination of features present in a product variant. We empirically evaluated the approach on three non-trivial case studies of different sizes and domains and found that our approach correctly identifies feature to code traces except for code that traces to multiple disjunctive features, a rare case involving less than 1% of the code.

Software Product Lines (SPLs) are families of related software products. SPL practices have proven substantial technological and economical benefits such as improved software reuse and reduced time to market. Software testing is a key development activity in SPLs, and it is uniquely challenging because of the usually large number of feature combinations present in typical SPLs. Pairwise testing is a combinatorial testing technique that aims at selecting products to test based on the pairs of feature combinations such products provide. Our previous work on evolutionary approaches for SPL testing and their comparative analysis has yielded a large amount of data that prompted us to explore ways by which to convey and represent this information. In this paper we present our early results in this effort. We describe three basic visualization applications to pairwise testing and highlight some of the open questions that we foresee. But most importantly, our driving goal is both to raise the awareness of the visualization problems in this area and to spark the interest of the software visualization community.

Design models must abide by constraints that can come from diverse sources, like their metamodels, requirements, or the problem domain. Software modelers expect these constraints to be enforced on their models and receive instant error feedback if they fail. This works well when constraints are stable. However, constraints may evolve much like their models do. This evolution demands efficient constraint adaptation mechanisms to ensure that models are always validated against the correct constraints. In this paper, we present an idea based on constraint templates that tackles this evolution scenario by automatically generating and updating constraints.

Developing high quality systems depends on developing high quality models. An important facet of model quality is their consistency with respect to their meta-model. We call the verification of this quality the conformance checking process. We are interested in the conformance checking of Product Line Models (PLMs). The problem in the context of product lines is that product models are not created by instantiating a meta-model: they are derived from PLMs. Therefore it is usually at the level of PLMs that conformance checking is applied. On the semantic level, a PLM is defined as the collection of all the product models that can be derived from it. Therefore checking the conformance of the PLM is equivalent to checking the conformance of all the product models. However, we would like to avoid this naïve approach because it is not scalable due to the high number of models. In fact, it is even sometimes infeasible to calculate the number of product models of a PLM. Despite the importance of PLM conformance checking, very few research works have been published and tools do not adequately support it. In this paper, we present an approach that employs Constraint Logic Programming as a technology on which to build a PLM conformance checking solution. The paper demonstrates the approach with feature models, the de facto standard for modeling software product lines. Based on an extensive literature review and an empirical study, we identified a set of 9 conformance checking rules and implemented them on the GNU Prolog constraints solver. We evaluated our approach by applying our rules to 50 feature models of sizes up to 10000 features. The evaluation showed that our approach is effective and scalable to industry size models.

Model-driven engineering has become a popular methodology in software engineering. Most available modeling tools support the creation of models based on a fixed metamodel. Typically, tool users cannot change the metamodel to reflect domain changes or newly emerged requirements. As a consequence, an updated version of the tool with an evolved metamodel must be developed and models as well as constraints that ensure model consistency have to be co-evolved, often manually, to conform to the new metamodel. Both, tool evolution and the necessary co-evolutions, are time consuming and error prone tasks. Furthermore, common tools often restrict the number of metalevels that can be modeled and force modelers to use workarounds to express certain facts. To overcome these issues we present the Cross-Layer Modeler (XLM), a modeling tool that supports multilevel modeling and allows co-evolution of metamodels and models. The XLM automatically performs co-evolution of constraints and gives instant feedback about model consistency. We illustrate the novel modeling approach of our tool and discuss its main capabilities.

More and more frequently successful software systems need to evolve into families of systems, known as Software Product Lines (SPLs), to be able to cater to the different functionality requirements demanded by different customers while at the same time aiming to exploit as much common functionality as possible. As a first step, this evolution demands a clear understanding of how the functional requirements map into the features of the original system. Using this knowledge, features can be refactored so that they are reused for building the new systems of the evolved SPL. In this paper we present our experience in refactoring features based on the requirements specifications of a small and a medium size systems. Our work identified eight refactoring patterns that describe how to extract the elements of features which were subsequently implemented using Feature Oriented Software Development (FOSD) a novel modularization paradigm whose driving goal is to effectively modularize features for the development of variable systems. We argue that the identification of refactoring patterns are a stepping stone towards automating Feature-Oriented Refactoring, and present some open issues that should be addressed to that avail.

Aspect-oriented programming is a promising paradigm that challenges traditional notions of program modularity. Despite its increasing acceptance, aspects have been documented to suffer limited reuse, hard to predict behavior, and difficult modular reasoning. We develop an algebraic model that relates aspects to program transformations and uncovers aspect composition as a significant source of the problems mentioned. We propose an alternative model of composition that eliminates these problems, preserves the power of aspects, and lays an algebraic foundation on which to build and understand AOP tools.

Keeping students alert and responsive during lectures is a challenge even for experienced teachers in small group settings. Research has shown the importance of student participation and involvement in the learning process. Many ideas and strategies have been proposed to promote these two vital education elements [5]. Among them is the use of interactive technology where the instructor asks a question to the class and each student answers individually. These answers are tallied and the professor can get immediate, quantitative, and real-time feedback information that can be used to detect and address comprehension problems and to adapt the lecture plan accordingly. In this paper we report our experiences using a wireless interactive system named the Classroom Performance System (CPS) [9] in a fast-paced, short but comprehensive Java programming course. We present the challenges we faced and the lessons we learned in designing and delivering lectures using this type of technology.

GenVoca is a methodology and technology for generating product-lines, i.e. building variants of a program. The primitive components from which applications are constructed are refinements or layers, which are modules that implement a feature that many programs of a product-line can share. Unlike conventional components (e.g., COM, CORBA, EJB), a layer encapsulates fragments of multiple classes. Sets of fully formed classes can be produced by composing layers. Layers are modular, albeit unconventional, building blocks of programs. But what are the building blocks of layers? We argue that facets is an answer. A facet encapsulates fragments of multiple layers, and compositions of facets yields sets of fully formed layers. Facets arise when refinements scale from producing variants of individual programs to producing variants of multiple integrated programs, as typified byproduct families (e.g., MS Office). We present a mathematical model that explains relationships between layers and facets. We use the model to develop a generator for tools (i.e., product family) that are used in language-extensible Integrated Development Environments (IDEs).