Plastic Partial Components: A Solution to Support Variability in Architectural Components

Conference Paper (PDF Available) · September 2009with35 Reads
DOI: 10.1109/WICSA.2009.5290808 · Source: DBLP
Conference: Joint Working IEEE/IFIP Conference on Software Architecture 2009 and European Conference on Software Architecture 2009, WICSA/ECSA 2009, Cambridge, UK, 14-17 September 2009
Abstract
Software product line engineering is becoming widely used due to the improvement it means when developing software products of the same family. The commonalities and variabilities of software product lines (SPL) are identified during the domain engineering process and then, they are realized in the software architecture. Therefore, mechanisms to explicitly specify the commonalities and variabilities of SPLs at the architectural level are required. Most of the current mechanisms specify variations on the architecture by adding or removing architectural elements. However, it is also necessary to specify variations inside components. In this paper, we propose the notion of plastic partial components to support internal variations. The specification of these components is performed using invasive software composition techniques and without tangling the core and product architectures of the SPL. This contribution is illustrated through a SPL for developing domain-specific validation environments.

Figures

Figure
Figure
    • "In [30], Van der Storm defines variable components, but only proposes solving techniques for checking compatibility among them. Plastic partial components [29] also propose to handle variability in model-driven software architectures through components equipped with several variable interfaces and implemented internally with aspect-oriented techniques. Our contribution differs from these two propositions by being dedicated to concerns and by handling definition and composition of open variable parts in the reusable units. "
    [Show abstract] [Hide abstract] ABSTRACT: Concern-oriented reuse (CORE) proposes the concern as a new unit of model-based reuse encapsulating software artefacts pertaining to a domain of interest that span multiple development phases and levels of abstraction. With CORE, a concern encapsulates multiple reusable features, while allowing its generic models to be customized to problem-specific contexts. We report on our experience of designing a family of crisis management systems (CMS) with the help of reusable concern libraries. The collected metrics show a considerable amount of reuse in our CMS design. The study provides encouraging evidence that CORE's vision to create large-scale, generic and reusable entities that are expressed with the most appropriate modelling formalisms at the right level of abstraction is feasible. We present our experience in the design of the CMS and elaborate on the advantages as well as the efforts required to adopt CORE in an industrial setting. Copyright
    Full-text · Article · Nov 2016
    • "Figure 6 shows a comparison between FX-MAN and component models that define parametrised architectural templates . These models include: ADLARS [6], MontiArch HV [18], ΔMontiArc[19], KobrA [5], Mae [30],Plastic Partial Components [28], xADL2 [13], Koala [35], Com [27], and Kumbang [4]. Some of these models do not define variation points explicitly, and express variability by other means. "
    [Show abstract] [Hide abstract] ABSTRACT: In software product line engineering, the construction of an ADL architecture for a product family is still an outstanding engineering challenge. An ADL architecture for a product family would define the architectures for all the products in the family, allowing engineers to reason at a higher level of abstraction. In this paper, we outline a component model that can be used to define architectures for product families, by incorporating explicit variation points.
    Full-text · Article · Apr 2016
    • "Figure 6 shows a comparison between FX-MAN and component models that define parametrised architectural templates . These models include: ADLARS [6], MontiArch HV [18], ∆MontiArc[19], KobrA [5], Mae [30],Plastic Partial Components [28], xADL2 [13], Koala [35], Com [27], and Kumbang [4]. Some of these models do not define variation points explicitly, and express variability by other means. "
    Full-text · Conference Paper · Apr 2016 · ACM Transactions on Software Engineering and Methodology
Show more