Product Line Implementation using Aspect-Oriented and Model-Driven Software Development

The emerging Internet of Things (IoT) has facilitated an explosion of everyday items now augmented with networking and computational features. Some of these devices are developed using a Software Product Line (SPL) approach in which each device, or product, is instantiated with unique features while reusing a common core. The need to rapidly develop and deploy these systems in order to meet customer demand and reach niche markets first requires shortened development schedules. However, many of these systems perform roles requiring thorough verification, for example, securing homes. In these systems, the detection and correction of errors early in the development life cycle is essential to the success of such projects, with particular emphasis on the requirements and design phases where approximately 70% of faults are introduced. Tools such as the Architecture Analysis & Design Language (AADL) and its verification utilities aid in the development of an assured design for embedded systems. However, while AADL has excellent support for the specification of SPLs, current verification utilities for AADL do not fully support SPLs, particularly SPL models utilizing composition. We introduce an extended version of AGREE, a verification utility for AADL, with support for compositional verification of SPLs.

SIGTel is a SME aimed at developing WebGIS application. It has a portfolio of products which are a combination of Open GIS components and its own developed components. Although most of these products share a common architecture and common features, they have to be customized according to the user requirements. Now, this SME is working at the improvement of the software development process by introducing a Software Product Line (SPL) approach to automate the process of development and deployment based on that common architecture, as well as reduce time to market and improve quality. The first step has been taken, and KobrA approach has been chosen as the basic methodology to start working. Now, the on-going work is to perform the Domain Engineering, being the management of variability one of the first issues to be resolved. Here, we present a combination of KobrA containment tree and Orthogonal Variation Model (OVM), as the selected alternative to model the variability by using the architecture of our WebGIS SPL.

Software product lines provide a systematic means of managing variability in a suite of products. They have many benefits but there are three major barriers that can prevent them from reaching their full potential. First, there is the challenge of scale: a large number of variants may exist in a product line context and the number of interrelationships and dependencies can rise exponentially. Second, variations tend to be systemic by nature in that they affect the whole architecture of the software product line. Third, software product lines often serve different business contexts, each with its own intricacies and complexities. The AMPLE (http://www.ample-project.net/) approach tackles these three challenges by combining advances in aspect-oriented software development and model-driven engineering. The full suite of methods and tools that constitute this approach are discussed in detail in this edited volume and illustrated using three real-world industrial case studies.

The extractive adoption of Software Product Lines (SPL) relies on the reuse of the already developed systems, employing a reengineering process. However, due to the diversity of options found in the daily practice of SPL development, rigorous planning of scenarios is critical to perform SPL reengineering. This diversity is the result of different organizational aspects, such as team experience and product portfolio. Hence, a proper planning process must consider technical and organizational aspects, however, most existing studies in the field do not take into account organizational aspects of the companies. In this work, we present SPLReePlan, an automated framework to aid the SPL reengineering planning taking into account technical and organizational aspects. Our framework is supported by a web-based tool, ready to be used in the industry. To investigate how flexible is SPLReePlan to support the SPL reengineering planning in diverse situations, we extracted eight different scenarios from the SPL literature, which are used as input for the evaluation of SPLReePlan. The results indicate that SPLReePlan can be satisfactorily customized to a variety of scenarios with different artifacts, feature retrieval techniques, and reengineering activities. As a contribution, we discuss the lessons learned within the evaluation, and present challenges that were faced, being a source of information for tool builders or motivating new studies.

Software Product Line (SPL) development is a new approach to software engineering that aims at the development of a whole range of products. One of the problems which hinders the adoption of that approach is related with the management of the products of the line. Additionally, the scope of a software product line is determined by the bounds of the capabilities provided by the collection of products in the product line. This introduces new challenges related to the scope problem. One of the main three different forms of scoping is the Product Portfolio Scoping (PPS). PPS aims at defining the products that should be developed as well as their key features. While this has an impact on the actual reuse opportunities, it is usually driven from marketing aspects. Defining a product portfolio by considering costumers satisfaction and cost aspects is a NP-hard problem. This work presents a hybrid approach, which combines fuzzy inference systems and the multi-objective metaheuristics NSGAII to support product management by generating portfolios of products, based in segments of users and the development cost of the assets of the SPL. Fuzzy inference systems are used to generate development cost of an asset by using coupling, number of code lines and cyclomatic complexity and also to estimate the quality of the products generated by the optimization module of our approach. The NSGA-II metaheuristic is used to search for products minimizing the cost and maximizing the relevance of the candidate products. The results show that the proposed approach is effective in proposing the best products in terms of relevance and cost of the assets.

Managing the business of software product line: An empirical investigation of key business factors

The demand of new Social Networking Service (SNS) is high because the SNSs have been popular these days. In order to deliver various SNSs as early as possible, software product line (SPL) approach can be useful. By using the state of the practices of SPL, this paper shows how to manage commonalities and variabilities of SNS. Specifically, to make an architecture design, presented practices include: understanding relevant domains, requirements engineering, architecture definition. The strengths and weaknesses of Face book architecture are evaluated with the Architecture Tradeoff Analysis Method (ATAM). As a result of applying a framework for SPL practice, layered view and component-based view are illustrated along with variabilities represented by Product Line UML-based Software Engineering (PLUS) and Orthogonal Variability Model (OVM). Based on the analysis of requirements of SNS, additional services such as file sharing and instant messaging are represented as optional components. In case of Face book, three key quality attributes, i.e., availability, scalability, and privacy are analyzed by using quality attribute utility tree. We identified that Face book employs client-server architecture. Through ATAM, Peer-to-Peer (P2P) approach promoting privacy is explained.

Managing the evolution of system families in space and time, i.e., system variants and their revisions is still an open challenge. The software product line (SPL) approach can support the management of product variants in space by reusing a common set of features. However, feature changes over time are often necessary due to adaptations and/or bug fixes, leading to different product versions. Such changes are commonly tracked in version control systems (VCSs). However, VCSs only deal with the change history of source code, and, even though their branching mechanisms allow to develop features in isolation, VCS does not allow propagating changes across variants. Variation control systems have been developed to support more fine-grained management of variants and to allow tracking of changes at the level of files or features. However, these systems are also limited regarding the types and granularity of artifacts. Also, they are cognitively very demanding with increasing numbers of revisions and variants. Furthermore, propagating specific changes over variants of a system is still a complex task that also depends on the variability-aware change impacts. Based on these existing limitations, the goal of this doctoral work is to investigate and define a flexible and unified approach to allow an easy and scalable evolution of SPLs in space and time. The expected contributions will aid the management of SPL products and support engineers to reason about the potential impact of changes during SPL evolution. To evaluate the approach, we plan to conduct case studies with real-world SPLs.

Trusted Product Lines

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.

AOSD (Aspect Oriented Software Development) is an emerging discipline in Software Engineering. It focuses on the separation of concerns of the ’70s, aiming at improving modularity, to ensure maintainability in the sense of extensibility, changeability and reuse, towards an evolutionary software product responding to a more dynamic environment. The AOP (Aspect Oriented Programming) paradigm of the ’90s focuses on the separation of the crosscutting concerns, which are in general non functional requirements (quality requirements). It is now of general agreement that the entanglement and scattering of concerns must be handled early in the software life cycle. However, these aspects are inherent to all the stages of software development, from requirements elicitation to code implementation. Many concepts and mechanisms have been proposed to handle properly these issues; however terms are in general semantically slightly dierent in each discipline where they have been formulated and used, causing misunderstanding and confusion. This paper presents an AOSD UML core for early aspects (requirements, analysis and design disciplines), constructed gathering dierent modelling elements found in the literature, focusing particularly on the AOSD ontolgy document of the Common Foundation for AOSD of the European Community, and dierent

The design of mechatronic products requires cooperation and coordination of the involved disciplines. To analyze the dynamic behavior of the product’s subsystems and their components, multiple dynamic behavior models (DBM) are developed in different levels of detail (modeling depths) and domains. However, in order to simulate the complex interactions and dependencies between them, models of the whole system are needed, which fit the varying modeling objectives and analysis goals. These comprehensive models are often extensive and the manual construction presupposes deep insight in the specific model approaches and modeling tools. Furthermore, consistency needs to be ensured. The paper describes a way to automatically configure simulation models of the system adopting a Software Product Line (SPL) approach. With the use of feature models, SPL approach provides a structured method for managing variability. The particular focus of this paper is on handling of components in different tools with more than one level of detail through deployment of feature modeling. Also, it presents the concept of a multifunctional model client (MMC), which facilitates integration of solution and system knowledge.

Code cloning remains a significant challenge in modern software development, particularly within the Object-Oriented paradigm and advanced methodologies such as the Software Product Line (SPL) approach. In this context, code smells and refactoring can be seen as two sides of the same coin—one representing the symptoms of poor design, and the other offering systematic strategies for improvement. Among the various software quality attributes, maintainability stands out as a critical factor in determining the long-term success of SPL-based systems. However, the presence of cloned code directly impacts this maintainability, making the detection and mitigation of such clones an essential concern. Although multiple quality models exist to assess the relationship between code cloning, refactoring, and maintainability, most lack the granularity to accurately capture the specific effects of code cloning within SPL environments. This research undertakes a systematic literature review to consolidate and analyze findings from existing surveys, with a particular focus on identifying software metrics capable of evaluating the impact of refactoring on SPL maintainability. Refactoring serves as a deliberate means to eliminate code smells, and numerous tools and techniques have been developed to support this process. By synthesizing the current body of knowledge, this study provides a foundation for researchers and practitioners to better understand, select, and apply effective practices and tools to reduce code smells, improve maintainability, and ultimately enhance the overall quality of SPL-based software systems

The management of software evolution as well as the maintenance of its complexity is of two most important problems to be solved by software engineering. Several solutions have been considered, one of them being the separation of concerns. These concepts have been extended along the life cycle of software development and thus, aspect oriented software development (AOSD) arose and shed new light on software evolution problems. In this paper we focus on the seamless integration of AOSD and software architecture to support dynamic software evolution in architecture level. Thus we propose an incremental aspect-oriented (AO) architecture modeling approach. In the approach we introduce a unified formal model, namely aspect weaving connector (AWC), to formalize the underlying mechanisms of aspect dynamic weaving in architecture level. Meanwhile, we introduce a simple and seamless extension of ACME ADL to support the modular representation of architectural aspects, components, AWC and their composition forms. For the unified connector model has been applied in our implemented framework for dynamic software architecture, a case study on adaptive JPS (Java pet store) is illustrated to show the advantages of this approach and the unified model.

This report explains the challenges experienced as Overwatch Textron Systems transitioned to a software product line approach. Overwatch Textron Systems provides both software products and custom software development in the domain of intelligence planning, collection and analysis to the U.S. Government and its allies. This report: a) Describes the approach taken to transition Overwatch Textron Systems to a product line organization. b) Provides an overview of the Overwatch Textron Systems software product line; the Overwatch Intelligence Center. c) Describes the product line architecture that is key to the Overwatch Intelligence Center software product line. d) Provides a summary of the lessons learned during the transition.