Plastic Partial Components: A Solution to Support Variability
in Architectural Components
Politécnica de Madrid,
Politécnica de Madrid,
Politécnica de Madrid,
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.
Last decade, new software development paradigms
emerged to increase the productivity of software
companies and to reduce time to market. Software
Product Line Engineering (SPLE)  is a widely used
paradigm by software companies. This is specially true
for those companies that develop products of the same
family or domain. SPLE is based on the idea that
applications of the same domain or family share a lot
of commonalities. Thus, these commonalities of a
family may be developed only once and reused by the
different products of the family. Commonalities and
variabilities of Software Product Lines (SPL)  are
identified during the Domain Engineering process .
It consists of identifying the commonalities of a family
of products and the variabilities of each product.
Feature-Oriented Analysis  has been extensively
used for modeling commonalities and variabilities of
SPL. For accountability purposes, feature models must
be traced throughout the development process of a
software product, i.e.,
The works of Garlan  and Perry  clearly
define that software architectures bridge the gap
between requirements and implementation. Therefore,
to realize the commonalities and variabilities of SPLs,
it is necessary to specify Product Line Architectures
(PLAs). As a result, 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 (components, connectors, connections, etc).
However, from our experience in SPL development
, it is not enough to trace the commonalities and
variabilities from requirements to the architecture.
Sometimes part of the component behavior is common
to the SPL and part of its behavior changes depending
on the product. As a result, it is also necessary to
specify variations inside components. In this paper, we
focus on addressing this need by providing
mechanisms to specify
In addition, it is important to take into account that
variability features can be realized in different ways at
the architectural level. They can be crosscutting or
non-crosscutting features of the architecture. In any
case, features must be specified using elements without
tangling their specification
components. To address this challenge, the definition
of Plastic Partial Component utilizes the Invasive
Software Composition principles . As a result, it
provides the advantages of the CBSD , Software
Architectures  and AOSD approaches .
from requirements to
variability points in
978-1-4244-4985-9/09/$25.00 c ?2009 IEEE
This contribution pursues to preserve the
traceability from requirements to implementation, and
to make the verification and validation of architectural
models possible. For this reason, our contribution is
based on models and provides the guidelines to be
deployed in a Model-Driven Development (MDD)
framework , .
Plastic Partial Components are an attempt to
support the internal variations of architectural
components. In addition, a three views model intended
to support the definition of PLAs is provided: Core
Architectural View, Variability Model View and
Product Architectural View. The Variability Model
View allows the specification of Plastic Partial
Components. They are specified by defining its
variability points, which allow the selection of features
(non-crosscutting features) and/or aspects (crosscutting
features). This component definition makes it possible
to flexibly compose pieces (aspects, features,
components) of software as if we were building a
puzzle and, therefore, improving the reuse and
traceability of software.
This contribution is illustrated using a SPL for
developing domain-specific validation environments.
Specifically, we present its application to two different
products: a validation environment for a digital TV
decoder system and a validation environment for a
networked slot machines system .
The structure of the paper is as follows: Section 2
presents the notion of Plastic Partial Component and its
metamodel specification. Section 3 details how Plastic
Partial Components are specified by defining an PLA
description of three views. Section 4 presents the case
study that is used to illustrate our contribution, and
exemplifies the use of Plastic Partial Components in
the PLA definition. Section 5 discusses related works
on PLA. Finally, conclusions and further work are
presented in section 6.
2. Plastic Partial Components
A Plastic Partial Component is a component that
part of its behavior corresponds to the core of the SPL
and part of its behavior changes depending on the
product. It is a kind of component that allows us to
specify variability inside it.
Plastic Partial Components are incompletely
specified in the core architecture. This is due to the fact
that they only participate in the core PLA definition
with the behavior that it is common to the family of
products. This is the reason why they are called partial
components. They are components that are partially
described in the core architecture and ready to be
extended in the product architecture. They are called
plastic components because their behaviour is easily
adapted to each product of the SPL.
After the Application Engineering , Plastic
Partial Components are completely specified with the
specific behavior of a selected product. To derive a
specific product, it is necessary to provide mechanisms
to specify the variability inside components. The
variability mechanisms of Plastic Partial Components
are based on Invasive Software Composition Principles
. Invasive Software Composition combines the
CBSD , and AOSD  approaches, and Software
Architectures . It defines components as fragment
boxes that hook a set of reusable fragments of code.
Specifically, these fragments of reusable code can be
aspects making components easier to be maintained
and by extension software architectures.
The variability of a Plastic Partial Component is
specified using variability points, which hook
fragments of software to the Plastic Partial Component.
These fragments of software are specific features of a
product, which can crosscut the software architecture
or not. For this reason, we classified these features
A crosscutting-feature is a common feature of the
software architecture, which is encapsulated into a
separate entity called aspect. Whereas, a non-
crosscutting-feature is the specific functionality of a
component, which is encapsulated into a separate
entity called feature. Therefore, variability points can
hook aspects or features to the Plastic Partial
Component. A Plastic Partial Component is defined by
specifying: (i) its variability points; (ii) the aspects
and/or features that are necessary to complete the
definition of the component for any product of the
family; and (iii) the hooks between the variatility
points and the aspects and/or features. As a result, the
complete definition of a Plastic Partial Component for
a specific product is done by means of the selection of
aspects and/or features through the variability points.
This component definition makes it possible to flexibly
compose pieces (aspects, features, components) of
software as if we were building a puzzle. These
reusable pieces can be easily added and removed to
derive the component to a specific product. In this
sense, our partial components are plastic for the
development of the product line.
2.1. Definition of Plastic Partial Components
Metamodels define models and establish their
properties in a precise way. For this reason, the
definition of Plastic Partial Components is provided by
means of a metamodel (see Figure 1). This metamodel
2009 IEEE/IFIP WICSA/ECSA
Figure 1. Metamodel of Plastic Partial Components
contains a set of inter-related metaclasses. These
metaclasses define a set of properties and services for
each concept considered in the model. Metaclasses,
their properties and their relationships define the
structure and the information that is necessary to
describe Plastic Partial Components. In addition, the
services of metaclasses allow us to develop models by
creating, destroying, adding or removing elements
which are compliant with the constructors of the
A Plastic Partial Component is a specialization of a
component. Both, components and Plastic Partial
Components are metaclasses of the metamodel, called
Component and PlasticPartialComponent, respectively
(see Figure 1). The complete definition of a component
is provided, since the PlasticPartialComponent
metaclass inherits all the properties and behavior of the
metaclass Component. A Plastic Partial Component is
characterized by the definition of a set of variability
points, i.e. the place where the different variants are
hooked to the Plastic Partial Component. This
relationship is modeled by means of an aggregation
called defines (see Figure 1), which relates the
metaclass PlasticPartialComponent with the metaclass
VariabilityPoint. A variability point of a Plastic Partial
Component is characterized by three properties: the
kind of variation, the type of variability point
depending on the variants that it offers to be selected
(i.e. crosscutting or non-crosscutting features), and the
weaving between variants and the component. Next,
they are described in detail. The metaclass
VariabilityPoint defines two attributes that permit to
name a variability point and to specify the kind of
variation. This kind of variation is based on the
variability management of software architectures that
Bachman and Bass set out . These kinds of
variation are specified as cardinality as follows:
- 0..1: optional and unique: when a product is applied
to the product line, it is optional to select the unique
variation of the variability point.
- 1..1: mandatory and unique: when a product is
applied to the product line, it is mandatory to select the
unique variation of the variability point.
- 0..n: optional and multiple: when a product is applied
to the product line, it is optional to select a variation
from the multiple variations of the variability point.
- 1..n: mandatory and multiple: when a product is
applied to the product line, it is mandatory to select a
variation from the multiple variations of the variability
- n..n: multiple and multiple: when a product is applied
to the product line, it is possible to select several
2009 IEEE/IFIP WICSA/ECSA
variations from the multiple variations of the
There are two types of variability points: (i) those that
permit the selection of variants that are crosscutting-
features (aspects); (ii) and those that permit the
selection of variants that are non-crosscutting features
(features). These types of variability points are
specified in the metamodel by means of the
metaclasses AspectVP and FeatureVP, respectively
(see Figure 1).
These two metaclasses are
specializations of the metaclass VariabilityPoint. In
addition, the metamodel defines these two kinds of
variants, aspects and features, by means of two
specializations of the metaclass Variant. Moreover, the
set of aspects, that an aspect variability point provides,
is specified in the metamodel through the relationship
links. And, the set of features, that a feature variability
point provides, is specified through the relationship
hooks (see Figure 1). Thereby, the relationship links
connects the metaclasses AspectVP and
whereas the relationship hooks links the metaclasses
Feature VP and Feature. As a result, an aspect
variability point can only offer aspects to be selected;
and a feature variability point can only offer features to
be selected. It is important to emphasize that both
aspects and features can be linked to more than one
variability point in order to be reused in the SPL.
Finally, variability points allow us to specify the
weaving between the plastic partial component and the
variant. The weaving principles of Aspect-Oriented
Programming (AOP)  provide the needed
functionality to specify where and when extending the
plastic partial components using variants. Therefore,
AOP weaving primitives (pointcuts, weavings and
aspects) are applied to weave a plastic partial
component with both, aspects and features.
The pointcut definition consists of defining where
to insert the code of the variant. An example of
pointcut could be calling a service that the Plastic
Partial Component provides.
The definition of the weaving operator consists of
establishing when to insert the code of the variant with
regard to the pointcut: before, after or instead of
(around). In our example, it will be before, after or
instead of the call of the service of the Plastic Partial
However, there are some differences between our
definition of aspects and weavings and those AOP
provides. It is important to notice that in our proposal
aspects and features only specify the behavior to be
inserted in the Plastic Partial Component, i.e, they do
not specify the pointcuts of the Plastic Partial
Component and do not establish the weaving operator
(after, before or around) as AOP does. The pointcut
Feature. They are
and the weaving operator are specified outside the
aspects and features. As a result, aspects and features
are unaware of the linking context, and they are
The Plastic Partial Component, the pointcut, the
weaving operator and the variant are the elements that
define a weaving. The weaving is defined as a
metaclass that specifies all this required information.
This metaclass is called Weaving. The pointcut and the
weaving operator are located in a weaving. Weaving
metaclass is related to the Plastic Partial Component
(metaclass PlasticPartialComponent) through the
relationship establishesPointcut, and to the variant
establishesAdvice. The metaclass Weaving has two
attributes to name the weaving and to specify the
weaving operator that it is applied to. The metaclass
weaving is part of the variability point because it
specifies the weaving between plastic partial
components and variants, and it is dependent of the
linking context. As a result, a variability point specifies
all the weavings between its variants and the Plastic
Partial Component that it belongs to. This relationship
is defined in the metamodel through the aggregation
This metamodel provides the primitives to model
software architectures that support not only variability
in the architecture, but also inside its components.
However, to use these primitives it is necessary to
define a graphical metaphor for modeling them. Next,
we present the graphical metaphor that supports the
modeling Plastic Partial Components.
Components are represented by rectangles that have
one pin for each of the ports associated to them (see
Figure 2. Graphical metaphor of a component
Plastic Partial Components are represented as
components with the difference that they have two
white triangles in both sides to denote that they are not
completely specified (see Figure 3).
Figure 3. Graphical metaphor of a Plastic Partial Component
Variability points are represented in the same way
as defined in  to use a common notation. But we
differentiate Aspect Variability Points from Feature
Variability Points by labeling the triangle with AVP
and FVP, respectively (see Figure 4).
2009 IEEE/IFIP WICSA/ECSA
Figure 4. Graphical metaphor of Variability Points
The aggregation defines of the metamodel (see
Figure 1) is represented by a semicircle joint to a line.
The semicircle is drawn in one the sides of the plastic
partial component; whereas the line is attached to one
of the vertexes the variability point (see Figure 5).
Figure 5. Graphical metaphor for linking Plastic Partial
Components and Variability Points
Aspects are represented by a horizontal rectangle;
whereas Features are represented by a vertical
rectangle. This is due to the fact that a horizontal
position symbolizes crosscutting and a vertical position
denotes the opposite (see Figure 6). They are
connected to the variability point with a line. The
cardinality of the variability point is also specified (see
Figure 6. Graphical metaphor for Variations
2.2. Plastic Partial Components in MDD
Model-Driven Development (MDD) is a software
development paradigm that has become very
widespread in the last few years . The OMG
Meta-Object Facility (MOF)  specification defines
a four-level “architecture” that is focused on MDD. Its
main purpose is the management of model descriptions
at different levels of abstraction. The upper layer (M3)
is the most abstract one (see M3 layer, Figure 7). This
layer defines the abstract language used to describe the
entities of the lower layer (metamodels). The MOF
specification proposes the MOF model as the abstract
language for defining all kind of metamodels, such as
UML or the model of Plastic Partial Components. The
metamodel layer (M2) defines the structure and
semantics of the models defined at the lower layer. The
metamodel of Plastic Partial Components is defined at
this layer (see M2 layer, Figure 7). The M1 layer
comprises the models that describe data. These models
are described using the primitives and relationships
described in the metamodel layer (M2). The Plastic
Partial Component Gateway of our case study (see
section 4) is placed in this layer (see M1 layer, Figure
7). The lowest level is the information layer (M0
layer), which comprises the data to be described, i.e.,
specific instances of a product (see M0 layer, Figure
Figure 7. Plastic Partial Components in MDD
Since the metamodel of Plastic Partial Components
is defined at the layer M2, this permits to construct
models at layer M1 using its primitives and
guaranteeing model correctness. In addition, it allows
that any architectural model, that has a metamodel
definition at the M2 layer, can easily introduce the
Plastic Partial Component concept by extending its
metamodel with the metamodel of Plastic Partial
3. Product-Line Architectural Views
The definition of Plastic Partial Component and the
rest of variations of a SPL must be specified without
mixing variability specifications with the software
architecture. This is important because the main
properties of software architectures must be preserved,
i.e., to describe the structure of a software system by
hiding the low-level details and abstracting the high
level important features . In addition, the black box
view of architectural elements must be preserved. As a
2009 IEEE/IFIP WICSA/ECSA
result, we propose three different views to define PLA
maintaining these properties.
3.1. Core Architectural View
The Core Architectural View specifies the core
architecture of the SPL. This architecture is composed
of two kinds of components: (i) the common
components of the family and (ii) components that part
of their behavior is common for all the products, and
the other part of their behavior is variable. These
components and their connections constitute the core
assets of the SPL. The former components are
specified as the common components that any ADL
provides. The latter components are specified as Plastic
Partial Components. These Plastic Partial Components
are incompletely specified because they only include
the behavior that is common for all the products of the
family. The core architecture is unaware of the
variability of each one of its products, i.e., it is a
common architecture specification without specifying
3.2. Variability Architectural View
The Variability Model View specifies the variability
of the architecture in terms of its configuration and its
components variations, i.e., the specification of Plastic
On the one hand, the necessary components and
connections that are variants of the family are specified
using common variability points (see the metaclass
VariabilityPoint, Figure 1). In this view, the core
architecture is extended by specifying these variability
points. This variability specification is out of the scope
of this paper, and we cannot detail it for space reasons.
But we can just mention that it consists of defining
variability points that allow us to select architectural
variants. These variants
connections between them.
On the other hand, Plastic Partial Components
should be specified by using aspect and feature
variability points and aspect and feature variants.
When a product architecture must be designed, the
application of the variability points that are defined in
this view must be applied to. It consists of selecting the
variants that are required for the product, i.e.: (i) to
reconfigure the core architecture by adding or
removing the components and connections; and (ii) to
complete the partial specification of Plastic Partial
Components by weaving aspects and/or features with
their core behavior.
It is important to emphasize that it is not necessary
to define a new language to specify the addition or
are components and
deletion of components and connections. This is thanks
to the fact that our proposal is framed in a MDD
approach and our metamodel provides these services at
the layer M2 of MOF. Therefore, these services can be
used to describe architectural models at the layer M1 of
the MOF four-level “architecture”.
3.3. Product Architectural View
The Product Architectural View specifies the
architecture of a given product by applying the
variability points that are required and by selecting the
variants of the product. This architecture extends the
core architecture by adding or removing components
and connections and by completing the specification of
Plastic Partial Components. This architecture is also
unaware of the variability specification, i.e., it is a
common architecture specification without specifying
variability points. It is the final result for a specific
4. Case Study
The case study consists of designing the PLA of
two validation environments, one to test TV decoders
systems and other to test slot machine systems. First of
all, we refer to validation environments as frameworks
for testing the behavioral requirements of systems.
This means, validation environments are used by test
engineers, experts in the final product, to determine
whether or not a system satisfies its acceptance criteria.
The test engineer knows in detail these Systems Under
Test (SUTs) and needs to perform the testing process
in a close way to what the system operation would be.
So, one of the most important features of the validation
systems is the domain-specific test language that the
engineer uses to test the SUT. This allows the test
engineer to test the system in a more friendly way.
Since the test language changes depending on the SUT,
the validation environment should be able to be self-
adaptable to each SUT. From our experience  we
have identified that the validation environments for
different software systems share a set of commonalities
and variabilities. From this identification, TOPEN 
has been currently improved and evolved towards a
PL. This work has extended the previous PLA of
TOPEN through the notion of Plastic Partial
Component. As a result, TOPEN current PLA
supports the internal variations of their components.
TOPEN Product Line: Domain
2009 IEEE/IFIP WICSA/ECSA
Commonalities and variabilities were analyzed with the aim of producing a product line for validation
Figure 8. TOPEN feature model
environments from which TV decoders systems and
slot machines systems could be derived. The product
line was represented in terms of features  as it is
shown in Figure 8, considering a feature as a logical
unit of behavior that is specified by a set of functional
and non-functional requirements . The identified
features were classified into common and variable.
Common features are those that will be reused (core
assets) and are represented by a continued rectangle.
Common features represented in Figure 8 are
Graphical User Interface, Test Case Execution, or
Persistent Storage among
requirements are those that are going to change
depending on the product and are identified by
discontinued rectangles or continued rectangles with
0..1 cardinality. Variable features, see Figure 8 are
SlotMachineSystem_DSL, or Natural Language. The
common and variable features, defined in Figure 8, are
described in detail below:
F1: A graphical user interface to define and run the test
cases and evaluate the results.
F1.1: A Test Procedure Interface that allows the test
engineer to define the test procedures (create, execute,
and controlling the test procedures). Two modes are
supported: command mode and procedure mode.
Languages as required are supported: a domain specific
language for TV decoder systems and a domain
specific language for slot machines systems.
F1.2: A SUT Interface that allows the test engineer to
configure the SUT in a graphical or textual way.
F2: Test cases execution support.
F2.2: Translation of test commands: translation from
domain specific languages to SUT language and
optionally translation from domain specific languages
to natural languages.
F2.3: Command execution.
F2.4: Results management.
F2.5: Notification management.
F3: Persistent storage of test procedures, notifications
F4: Support for communication with the SUT.
F4.1: SUT management: (F4.1.1) TV decoder systems
and (F4.1.2) slot machines systems.
F4.2: Protocols and drivers management supported by
the SUT. TV decoder systems support (F4.2.1) UPnP
protocol and slot machines systems support (F4.2.2)
F5: Distribution: distributed architecture (RMI or
WebServices) or local.
The next step was the design of the PLA for each
product, i.e., a TOPEN product for validating TV
decoders systems and a TOPEN product for validating
slot machines systems.
4.2 Variability Architectural View: The Plastic
Partial Gateway Component
From the previous feature analysis, it is possible to
identify the main components in the TOPEN
architecture (see Figure 9): the Graphical User
Interface, the TOPEN Engine, the Information System,
and the Gateway. This last component implements the
communication with the SUT and presents the large
part of the variability represented in Figure 8. This
2009 IEEE/IFIP WICSA/ECSA
variability is internal to the component; for that, we
focus on the component Gateway to illustrate the
Plastic Partial Component concept.
The component Gateway has a common part that is
independent from the product to be derived (a TOPEN
for validating TV decoders or a TOPEN for validating
slot machines), and a variable part that is specific for
the derived product. Common features (see Figure 8)
are the SUT Management (see section 4.1, F4.1), the
Drivers & Protocols Management (see F4.2), the
Management (see F2.4)
Management (see F2.5). This common part supports
the SUT devices (TV decoders, slot machines, a
master), manages the binding between SUT devices
and their specific drivers, and exports the commands,
responses, and notifications supported by the SUT. For
example, the TV decoders system support commands
such as turn on or shut down, return results of
commands executions and may notify events or
Figure 9. Main elements of a validation system
The variable part contains crosscutting features and
non-crosscutting features. A crosscutting feature (see
Figure 8) is the Distribution Type as the Gateway
component manages the interaction between the
TOPEN Engine and the SUT in distributed
architectures (see F5). Non-crosscutting features are
the support for the
TVDecoderSystem (see F4.1.1) or SlotMachineSystem
(see F4.1.2), and the support for the Protocol, UPnP
(see F4.2.1) or IP (see F4.2.2) supported by the system.
From the metamodel defined in Figure 1, we have used
the primitives to model the software architecture of a
product line of validation environments which are able
to test TV decoders and slot machines. Figure 10
applies the graphical metaphor defined in section 2.2 to
define the Plastic Partial Component Gateway. This
figure shows an Aspect Variability Point to implement
the aspect Distribution Type and two Feature
Variability Points to implement the features Protocol
The configuration of their respective variants will
allow us to specify the architecture for different
specific products: (i) a TOPEN product for validating
slot machines through IP protocol in a distributed
architecture, (ii) a TOPEN product for validating slot
machines through UPnP protocol in a distributed
architecture, (iii) a TOPEN product for validating TV
decoders through IP protocol in a distributed
architecture, (iv) a TOPEN product for validating TV
decoders through UPnP protocol in a distributed
architecture, (v) a TOPEN product for validating slot
machines, and finally (vi) a TOPEN product for
validating TV decoders in local.
Figure 10. Plastic Partial Gateway Component
5. Related Work
PLAs and architectural variability modeling has
become a challenge for product-line engineers. For this
reason, several approaches for PLAs have been
proposed to define SPLs at the architectural level.
An interesting comparison of the PLA design
methods is presented in . Some of them provide
graphical languages to represent variability in the
architectural design by adapting UML. However, these
extensions do not take into account the variability
inside components and do not consider the difference
between crosscutting and non-crosscuting features.
These approaches also apply views for PLA design, but
they do not pursue the separation of variability
specifications from PLA specifications.
The work of Bachman and Bass  is a reference
for the management of variability in software
architectures. In fact, our approach is based on their
work to define the kinds of variation. However, they
only consider variability
configuration of the architecture by adding or
removing components or connections. These kinds of
variations are the same that the works of Garg et al.
 or Razavian and Khosravi  consider, and that
Mae and x.ADL 2.0  provide. The Koala
Component Model  addresses the need of
specifying variability inside components. It provides
the primitive optional interface to vary the published
behaviour of the component. However, this solution
by modifying the
2009 IEEE/IFIP WICSA/ECSA
does not support the internal variability of behaviour
that is not published and let variants be reusable by
other components that can require them. In our
proposal, variants are specified as reusable aspects and
features, and variability specification is not constrained
to be published. In our proposal, variant services can
be published or not by the component by adding or not
new ports to the component.
A great number of approaches that combine AOP
and SPLs have been proposed. The Noda’s Aspect-
Oriented Modeling (AOM)  proposes a PL-ADL
where everything is an aspect, refusing the main
concepts of formal ADLs. This has the inconvenient
that the semantics of aspects and components is not
preserved. An aspect defines a specific behaviour of a
crosscutting-concern. However, in this approach
aspects are used to specify both crosscutting and non-
crosscutting concerns without distinction. In addition,
aspects cannot be used to specify components. This is
due to the fact that an aspect cannot provide
functionality of different concerns, whereas a
component can do it.
VML  is a Variability Modeling Language that
also provides mechanisms to express variability in
different architectural views (component, interaction
and deployment). However, our proposal is based on
the component view, which we divided into three
views to deploy PLAs: (i) preserving the properties of
abstraction and encapsulation (black boxes) of
software architectures, and (ii) providing the view of
the product architecture and core architecture. In this
approach, any variant is specified by using concerns
(aspects). Therefore, aspects are used to specify
crosscutting and non-crosscutting variants as Noda’s
AOM. In addition, VML creates new services to apply
the variants for a specific product, whereas in our
proposal, these services are not created from scratch,
they are provided by the metamodel following MOF
and the MDD approach.
The work of Batista et al.  is a MDD proposal for
developing SPL which is also based on aspects. At the
architectural level, it extends AspectualACME  for
describing PLAs. Since AspectualACME defines
aspects by means of aspectual connectors, it only
considers variability by modifying the configuration of
the architecture by adding components, aspectual
connectors or connections.
Finally, a work that is so close to the notion of
Plastic Partial Component is the proposal of Lee et al.
. They implement variable features that may
crosscut several modular units as aspects. These
aspects modify the internal behavior of the component
following an invasive composition. However, they do
not perform this invasive composition for non-
crosscutting features as Plastic Partial Components do.
In addition, this work is defined at the implementation
level using programming languages such as AspectJ
. But, the use of AspectJ makes their aspects
dependent on the linking context (i.e. the component).
Thus, they are not reusable.
6. Conclusions and Further Work
SPLE adoption requires to explicitly specify the
commonalities and variabilities of SPLs at the
architectural level. This implies not only to specify
variants for modifying the configuration of the
architecture, but also to define variations inside
components. This paper presents a solution to support
the internal variation of architectural components and it
is applied to the specification of a SPL for domain-
specific validation environments.
In this paper, we propose the notion of Plastic
Partial Component to support the internal variations of
architectural components. The specification of Plastic
Partial Components is performed using invasive
software composition techniques: components are
invasively composed of aspects and features. This
component definition allows us to flexibly compose
pieces of software improving the reuse and
maintenance of software. The metamodel that defines
the notion of Plastic Partial Component and the
graphical metaphor that allows its specification have
been described following a MDD perspective. In
addition, it is defined a model of three views to support
the definition of PLAs using Plastic Partial
Components: Core Architectural View, Variability
Model View and Product Architectural View.
The application of
development provides the following benefits: (i) to
support variability definition
architecture (configuration) and in their components
(internal variation); (ii) to provide a view of the
architecture core asset; (iii) to provide a view of the
product architecture; (iv) to preserve the encapsulation
and abstraction properties of software architectures in
the core and product views; (v) to avoid mixing the
definitions of the software architecture and their
variabilities by means of a variability view; (vi) to
satisfy the semantics of components and aspects
without modeling non-crosscuting concerns with
aspects and without modeling components using
aspects; (vi) to provide two reusable primitives, aspects
and features, for modeling crosscutting features and
non-crosscutting features, respectively; (vii) to
construct models using metamodeling primitives
guaranteeing the model correctness; (viii) easily
adoptability of the concept of Plastic Partial
Component by any architectural model, that has a
our proposal to SPL
in the software
2009 IEEE/IFIP WICSA/ECSA
metamodel definition; (ix) to be integrated in the MDD Download full-text
approach and the MOF infrastructure; (x) to offer a
friendly graphical metaphor to establish variability in
As future work, we plan to develop a framework to
support the specification and dynamic reconfiguration
of PLAs using this proposal. We also plan to define a
model, based on MDD, to trace variability from
requirements to implementation.
Acknowledgements. The work reported here has been
partially sponsored by the Spanish MICYT (FLEXI FIT-
340005-2007-37, ITEA2 6022), MEC (TIN2006-15175-C05-01,
and TIN2006-14840 OVAL/PM, UPM Grant Programme
(Jessica Díaz), and Conselleria d'Educació i Ciència
(Generalitat Valenciana) (C. Costa, FPI fellowship).
 U. Assmann, Invasive Software Composition, Springer-
Verlag, Heidelberg, 2003.
 P. P. Alarcón and J. Garbajosa, “Identifying application
key knowledge through system operations modeling”,
ICCI, IEEE, pp.256-254, 2007.
 P. P. Alarcón et al., “Automated integrated support for
requirements-area and validation processes related to
system development”, INDIN. IEEE, 2004.
 F. Bachmann, L. Bass, “Managing Variability in
Software Architectures”, SSR’01, Canada, May 2001.
 T. Batista et al., “A Marriage of MDD and Early
Aspects in Software Product Line Development”, 12th
SPLC, IEEE Computer Society, pp. 97-103, 2008.
 T. Batista et al., “Reflections on architectural
connection: Seven issues on aspects and ADLs. Early
Aspects (EA), pp. 3–9, May 2006.
 S. Beydeda, M. Book, and V. Gruhn, Model-Driven
Software Development, Springer, 2005.
 J. Bosch, Design & Use of Software Architectures:
Adopting and evolving a product-line approach.
Addison Wesley, 2000.
 P. Clements, L. Northrop, Software Product Lines:
Practices and Patterns, Addison-Wesley, Upper Saddle
River, NJ, 2002.
 E. Dashofy and A. van der Hoek, “Representing product
family architectures in an extensible architecture
description language”. 4th Workshop on Product Family
Engineering, pp.330-341,LNCS 2290, 2001.
 Garg, A et al., “An environment for managing evolving
product line architectures”. ICSM, 2003.
 D. Garlan, “Formal Modelling and Analysis of Software
Architecture: Components, Connectors, and Events”,
Formal Methods for Software Architectures, LNCS
2804, September 2003.
 K. C. Kang et al., “Feature-Oriented Domain Analysis
(FODA) Feasibility Study”,
CMU/SEI-90-TR-21, Software Engineering Institute,
Carnegie Mellon University, Pittsburgh, PA, 1990.
 K.C. Kang, L. Jaejoon, P. Donohoe, "Feature-oriented
product line engineering," Software, IEEE , vol.19, no.4,
pp. 58-65, Jul/Aug 2002
 G. Kiczales et al., “An Overview of AspectJ”, the 15th
ECOOP, LNCS 2072, Budapest, Hungary.
 K. Lee et al., “Combining Feature-Oriented Analysis
and Aspect-Oriented Programming for Product Line
Asset Development”, 10th SPLC, 2006.
 N. Loughran et. al, “Language Support for Managing
Variability in Architectural
Composition, Budapest Hungary, 2008.
 B. Magro, J. Garbajosa, J. Pérez, “The Development of a
Software Product Line for Validation Environments
Software”, Product Line Engineering, Ed. Taylor and
 M. Matinlassi, “Comparison of software product line
architecture design methods: COPA, FAST, FORM,
KobrA and QADA”, 26th ICSE, pp. 127 – 136, 2004.
 N. Noda and T. Kishi, “Aspect-Oriented Modeling for
Variability Management”, 12th SPLC, 2008.
 Object Management Group (OMG), Meta-Object
Facility (MOF) 1.4 Specification. TRformal/2002-04-03
 R. van Ommering et al., “The koala component model
for consumer electronics software”. IEEE Computer
33(3), pp.78–85, 2000.
 D. Perry and A. Wolf, “Foundations for the Study of
Software Architecture”, ACM Software Engineering
Notes, Vol. 17, No. 4, pp. 40-52, October 1992.
 K. Pohl, G. Böckle, F. van der Linder, Software Product
Line Engineering: Foundations,
Techniques, Springer-Verlag, 2005.
 M. Razavian and R. Khosravi, "Modeling variability in
the component and connector view of architecture using
UML", Intern. Conference on Computer Systems and
Applications (AICCSA), IEEE/ACS, pp.801-809, 2008.
 D.C. Schmidt, Model-Driven Engineering, IEEE
Computer Society, 2006.
 B. Selic, “The pragmatics
development”, IEEE Software, 20(5), Sept.-Oct. 2003.
 C. Szyperski, Component software: beyond object-
oriented programming, ACM Press and Addison
Wesley, New York, USA, 1998.
2009 IEEE/IFIP WICSA/ECSA