=Paper=
{{Paper
|id=Vol-1723/5
|storemode=property
|title=Towards Concern-Oriented Design of Component-Based Systems
|pdfUrl=https://ceur-ws.org/Vol-1723/5.pdf
|volume=Vol-1723
|authors=Jörg Kienzle,Anne Koziolek,Axel Busch,Ralf Reussner
|dblpUrl=https://dblp.org/rec/conf/models/KienzleKBR16
}}
==Towards Concern-Oriented Design of Component-Based Systems==
https://ceur-ws.org/Vol-1723/5.pdf
Towards Concern-Oriented Design of
Component-Based Systems
Jörg Kienzle Anne Koziolek, Axel Busch, Ralf Reussner
McGill University Karlsruhe Institute of Technology
Montreal, Canada Karlsruhe, Germany
Email: joerg.kienzle@mcgill.ca Email: {koziolek, busch, reussner}@kit.edu
Abstract—Component-based software engineering (CBSE) is hidden behind well-defined interfaces. Since components can
based on defining, implementing and composing loosely coupled, be developed independently, developers can work on compo-
independent components, thus increasing modularity, analyzabil- nents according to their specific business or technical knowl-
ity, separation of concerns and reuse. However, complete sepa-
ration of concerns is difficult to achieve in CBSE when concerns edge, isolating them from the complexity and unrelated details
crosscut several components. Furthermore, in some cases, reuse of the remaining part of the application, and allowing them to
of components is limited because component developers make focus on the development tasks that they are experts in.
certain implementation choices that are incompatible with the Another advantage of CBSE is that thanks to the provided
non-functional requirements of the application that is being and required interfaces, replaceability is promoted. A required
built. In this paper we outline how to integrate CBSE and
concern-oriented reuse (CORE), a novel reuse paradigm that component can be replaced by other compatible ones that
extends Model-Driven Engineering (MDE) with best practices implement the same functionality in different ways. This in
from aspect-oriented software composition and Software Product turn increases maintainability, since component implementa-
Lines (SPL). Concretely, we outline how to combine the Palladio tions that are no longer suitable can be substituted easily.
Component Model (PCM) capable of expressing complex soft-
Furthermore, the explicit software architecture present in
ware architectures with CORE class and sequence diagrams for
low-level design. As a result, multiple solutions for addressing CBSE forms an additional layer of structuring that makes
concerns that might even crosscut component boundaries can be it possible to reason about software at a higher level of
modularized in a reusable way, and integrated with applications abstraction. In particular, model-driven engineering (MDE)
that reuse them using aspect-oriented techniques. Additionally, approaches can be applied at the software architecture level to
thanks to CORE, component developers can avoid premature
analyze, verify and predict desired properties of applications
decision making when reusing existing libraries during imple-
mentation. under development. For example, automated MDE-based ap-
proaches such as [4] can exploit the degrees of freedom that
I. I NTRODUCTION component substitution and flexible allocation strategies offer
With the ever increasing complexity of software, tradi- to perform multi-criteria design exploration.
tional approaches of building software from scratch become However, although CBSE constitutes an important step
more and more inefficient in terms of productivity and cost. forward, reuse in the context of CBSE is in practice not
Component-based software engineering (CBSE) [1] is a reuse- as straightforward. For example, substitutability and reuse of
promoting way of developing software that is based on defin- components, in particular COTS components, is sometimes
ing, implementing and deploying loosely coupled, independent difficult to achieve [1]. Even if the provided functionality and
components. Each component forms a modular and cohesive required dependencies match, the non-functional requirements,
unit and provides clearly defined functionality, encapsulated e.g., performance or memory/power consumption, can prevent
behind provided interfaces. In case the implementation of reuse in a particular application context. This is most often
the component depends on functionality provided by other due to the fact that bottom-up development approaches such
components, these dependencies are documented with required as CBSE force developers to make most implementation
interfaces. Ideally, when building an application with CBSE, choices at development-time when the requirements of the
only application-specific components have to be implemented reuse context are unknown.
from scratch, and general functionality is provided by reusing Moreover, separation of concerns is difficult to achieve in
existing components from the component repository. A run- CBSE when the concern does not align with the structure
ning application is obtained by selecting the appropriate com- imposed by the software architecture [5]. This is predomi-
ponents based on their interfaces, assembling them following nantly the case for concerns that are inherently distributed,
a well-defined software architecture, and deploying them onto as by their very nature their functionality crosscuts multiple
computational, communication and storage resources. computational resources. Since classic CBSE is designed in
CBSE has multiple advantages. For example, it promotes such a way that the unit of reuse is the component, concerns
modularity [2] and separation of concerns [3], as components that crosscut component boundaries can not easily be pack-
can be designed by different developers, potentially using aged. This hinders reuse, and additionally prevents the rigorous
different programming languages, and implementation details application of information hiding principles.
Last but not least, CBSE does not provide support for occur. Similarly, a bill should only be sent out after successful
explicitly expressing the fact that there are often many so- shipping.
lutions and possible software architectures to address specific The internal design of some components also needs to be
functional or non-functional development issues. As a result, updated. For example, somewhere within the functionality of
a software architect that wants to put together an application checkout, the payment processing needs to be invoked. This
by reusing components from the component repository might involves changing the internal behaviour of checkout, but also
directly select a specific solution, i.e., set of components and adding a required interface to checkout that needs to be linked
architecture, and oversee potential alternatives. to the component that provides payment processing.
In this paper we outline how to integrate CBSE and concern- While all third-party solutions for payment offer the main
oriented reuse (CORE), a novel reuse paradigm that extends functionalities outlined above, they do so in different ways,
Model-Driven Engineering (MDE) with best practices from with a varying number of components and interfaces, different
separation of concerns, goal modelling and Software Product control flows and dependencies on other components, and with
Lines (SPL). With its explicit variation, customization and different quality (e.g., performance, reliability, cost).
usage interfaces, advanced software composition based on Integrating CBSE and CORE would make it possible to
aspect-orientation, and support for delayed decision making, express the variability of available solutions, and for each
CORE has the potential to enhance CBSE to overcome the solution describe the architectural variations, if any, and design
shortcomings mentioned above. integrations, if any. For each solution, the concern would en-
The remainder of the paper is structured as follows. Sec- capsulate the architectural models and detailed design models
tion II illustrates the problem with a motivating example. specifying the solution, as well as how to apply the solution
Section III presents the most important concepts of CORE, within an application. The CORE reuse process would assist
compares CORE with CBSE, and outlines the main integration the software developer in choosing a solution, and ensure that
challenges. Section IV explains concretely how we envision to the solution is correctly and consistently integrated with the
integrate the Palladio Component Model (PCM) [6], a mod- application architecture and design. Why this is the case is
elling formalism capable of expressing complex software ar- explained in the following section, which presents CORE and
chitectures with performance, cost and reliability impacts, into how it relates to CBSE in more detail.
the existing CORE framework reference implementation that
III. CORE AND CBSE
supports low-level design with class and sequence diagrams.
The last section presents a perspective on the potential benefits A. Background on CORE
that a successful CORE/CBSE integration might provide in a In concern-oriented reuse (CORE), software development
long run. is structured around modules called concerns that provide
a variety of reusable solutions for recurring software devel-
II. M OTIVATING E XAMPLE opment issues. Techniques from Model-Driven Engineering
Let us assume a software architect develops a web store. The (MDE), SPL, and software composition (in particular aspect-
web store is comprised of four main components, namely a orientation) allow concerns to form modular units of reuse
store, a basket, checkout and shipping component. that encapsulate a set of software development artifacts, i.e.,
These components operate together when a customer processes models and code, describing relevant properties of a do-
an order: Store interacts with basket, while basket main of interest during software development in a versatile,
forwards its content to checkout (for payment). Finally, generic way [7]. Concerns decompose software into reusable
checkout triggers shipment. units according to some points of interest [3], [2] and may
Payment is a recurring issue in many commercial appli- have varying scopes, e.g., encapsulating several authentication
cations, and hence it is not surprising that multiple third choices, communication protocols, or design patterns. Con-
parties offer payment processing systems that can be integrated sequently, the models within a concern can span multiple
into component-based systems. Such systems provide essen- phases of software development and levels of abstraction (from
tial payment-related functionality, e.g., payment processing, requirements and analysis models, to design models to code).
which covers standard payment interactions and connection to The main premise of CORE is that recurring development
multiple payment solutions, i.e., credit cards, PayPal, payment concerns are made available in a concern library, which covers
verification, which keeps track of payment status and provides most recurring software development needs. Similar to class
reliable confirmation that payment was successful, and billing, libraries in modern programming languages, this library should
which creates and distributes customer bills. grow as new development concerns emerge, and existing
Including this functionality into the web shop application concerns should continuously evolve as alternative algorithmic
affects the software on multiple levels. The software ar- and technological solutions become available. Applications are
chitecture changes, since the payment system is constituted built by reusing existing concerns from the library whenever
of additional COTS components that need to be considered possible, following a well-defined reuse process supported
during deployment. Furthermore, these new components need by clear interfaces [8]. The same idea is applied to the
to be connected to the business components according to the development of concerns as well: high-level/more specific
new control flow that includes payment. For instance, after concerns can reuse low-level/more generic concerns to realize
checkout, but before shipping, payment verification needs to the functionalities they encapsulate. In the end, the software
architecture of software developed with CORE takes the in the reusing concern’s interface. This delays decision making
form of a concern hierarchy (directed, acyclic graph), thus to when more detailed requirements are known and further
supporting hierarchical modularity [9]. decisions can be made. To operationalize delayed decision
making, CORE relies on additive, aspect-oriented software
B. Comparing CORE and CBSE composition techniques that (re)compose concern realizations
While the description of CORE presented above shows whenever additional decisions are made [17].
many similarities with component-based development, one of Table I summarizes the CBSE and CORE comparison.
the fundamental differences is that the unit of reuse in CORE –
Standard CBSE Palladio PCM CORE
the CORE concern – is broader than the unit of reuse in CBSE
Interface for variation interface
– the component. Similar to SPLs, a CORE concern encapsu- expressing variability
no no
feature model
lates a variety of solutions for a specific domain of interest, performance
Support for variation interface
and expresses this variability explicitly in a variation interface expressing impacts
no reliability
impact model
(VI). The VI comprises a feature model [10], which describes cost
Interface for goarse grained goarse grained customization
the available functional- and implementation alternatives that customization required interface required interface interface
the concern encapsulates as well as their dependencies, if any. Interface for
provided interface provided interface usage interface
The feature model expresses the closed variability, i.e., the set functionality
of solutions that the designers of the concern have realized. Support for
no no yes
delaying decisions
Standard CBSE does not provide a means to group a set of
functionally equivalent components together, but extensions TABLE I
have been proposed to express variability within components, C OMPARISON OF CBSE AND CORE
e.g., [11], and modules, e.g., [12].
The CORE VI also describes the impacts that the different
solutions offered by the concern have on high-level stake- C. Integrating CORE and CBSE
holder goals, system qualities, and non-functional properties The CORE paradigm is general, and in theory any modelling
using a variant of the Goal-oriented Requirement Language or programming language can be used to describe properties
(GRL) [13]. Again, standard CBSE does not address non- of interest for a concern. Concretely, though, a modelling
functional properties, but extensions have been defined to language that wants to be usable as a realization language
address specific quality properties [14]. In particular, the within CORE must, for each model type it provides:
Palladio Component Model (PCM) [6] that is discussed in 1) clearly identify customization and usage interfaces, and
more detail in the next section supports detailed performance, 2) offer a homogeneous model composition operator.
reliability and cost analysis for software architectures.
Furthermore, if the modelling language is supposed to
In CORE, each solution within a concern must define a
be used in combination with other modelling languages to
customization interface (CI) that describes how the solution
describe the realization of a concern following a multi-view
can be adapted to a specific reuse context. Since each solution
approach, then consistency rules have to be specified between
is described as generally as possible to increase reusability,
the views, and compatibility of the composition operators must
some structural and behavioural elements are only partially
be ensured.
specified and need to be related or complemented with con-
crete elements from the reuse context. This enables open IV. PALLADIO I NTEGRATION
variability, similar to what is achieved at the programming Palladio [6] is a model-driven approach to CBSE comprised
level with generic or template classes. Standard components of the Palladio Component Model (PCM), a metamodel for de-
support coarse-grained open variability, as they can specify scribing component-based software architectures, and the Pal-
required interfaces for functionality that must be provided ladio Bench, an Eclipse-based modelling environment. What
by the reuse context. Application-specific functionality can sets Palladio aside from other component-based approaches is
then be integrated during assembly by connecting the required an extensive set of analysis tools for performance, reliability,
interface to an application component with a compatible pro- and costs evaluation, with includes PerOpteryx, a tool for
vided interface. Internal customization of components, while multi-criteria design space exploration.
provided by extended component models such as Fractal [15] This section outlines the steps involved in integrating Pal-
and BlueArX [16], is not supported by standard CBSE. In this ladio with the CORE framework. For each Palladio model
case, object-oriented customization techniques, e.g., generics, type, we discuss what would constitute the customization and
inheritance and call-backs, can be used for customization usage interface, and explain how we envision the design of a
purpose. homogeneous composition operator.
Last but not least, one important advantage of CORE is
that it does not require a concern user to commit to a specific A. Structural View: Component Repository and Assembly
solution variant at the moment of reuse. When reusing a Just like other component-based approaches, behaviours
concern, a developer only needs to decide on the reusable func- (i.e., operations) are modularized structurally in the PCM
tionality that is minimally needed to continue development, with signatures, which have a name, parameters and return
and can re-expose relevant alternatives of the reused concern type. Signatures are logically grouped within interfaces. The
unit of reuse in the PCM is the component. There are three For example, assume that the Logger component in our
increasingly detailed ways of specifying a component: the example above uses a Database component to store the logs.
Provides Type defines interfaces comprised of the signatures The provided interface of the Database component should
a component offers to be used by other components; the not be part of the usage interface for the Logging concern.
Complete Type extends the Provides Type with the interfaces Information hiding principles [2] dictate that internal design
that a component requires to realize the provided services. The decisions, in particular those that might change in the future,
Implementation Type goes further and provides an abstract should not be visible to the outside world to reduce complexity
behavioural description on the implementation of the signa- and increase maintainability by avoiding unnecessary depen-
tures of a component. Signatures, interfaces and components dencies. Hence, we propose that the architectural CORE usage
are specified in the system-independent component repository interface of a concern should be constituted of a subset of the
model. provided interfaces of the components encapsulated within the
The assembly model describes the inner structure, i.e., concern.
the conceptual architecture, of composite components and Structural Composition Operator: We envision the defi-
systems. In an assembly model, an assembly contexts stands nition of the composition algorithm that combines two struc-
for a component, from which it inherits the provided and tural architecture models to be straightforward. It essentially
required interfaces as defined in the component repository. constitutes a symmetric merge of two repositories and two
Assembly connectors link a required interface of one assembly assembly contexts. The specifics of the merge are highly
context to a provided interface of another assembly context. similar to what is done in the current CORE reference im-
plementation for merging class diagrams. Components need
Integration of Structural View with CORE to be treated just like classes, and assembly connectors just
Structural Customization Interface: As explained in sec- like associations. For details, the interested reader is referred
tion III, CORE concerns are broader units of reuse than com- to [18] for CORE class diagram composition.
ponents. It is therefore natural that a concern can encompass
multiple components, i.e., an entire, though maybe partial, B. Behavioural View: SEFFs and Usage Scenarios
software architecture. Some of the components encapsulated
in the concern will be basic Palladio components, i.e., they Palladio uses an abstract behavioural description, called
have provided and required interfaces, and their complete service effect specification (SEFF), for describing the internal
implementation is also contained inside the concern. However, behaviour of a component at a high level of abstraction.
in order to be able to capture architectural elements that SEFFs model the abstract control flow of the service provided
crosscut component boundaries, it should be possible to define by a signature of a component in terms of internal actions
partial components, interfaces and signatures that can later be (i.e., resource demands accessing the underlying hardware)
composed with the architecture of the reuse context. These and external calls (i.e., accessing functionality by invoking
elements comprise the architectural customization interface. signatures in provided interfaces of connected components).
For example, imagine a simple Logging concern. From an All control flow elements of activity diagrams, e.g., conditional
architecture point of view, it would be comprised of a standard execution, iterative execution, parallel execution and synchro-
Logger component that provides a Log interface that would nization, are supported. In order to support quality prediction,
allow any other component in the system to write log entries additional information is attached to SEFFs. For example, for
to a common storage. Having a Logger, though, is not enough. performance prediction, resource demands for internal actions
There must also be at least one component that make use (in terms of CPU instructions to be executed) can be specified.
of the Logger. Structurally, we don’t know much about the Cost and reliability prediction are supported as well.
components that use the Logger, apart from the fact that they In addition to the intra-component behaviour specified using
should require the Log interface, and that they need to be SEFFs, processing rates of hardware nodes can be specified.
connected to the logger. From an architectural point of view, Furthermore, domain experts can specify the interaction be-
the Logging concern should therefore also comprise a Logged tween certain user types and the system under development
partial component that must be composed with components in with a usage model, typically expressed using a variant of ac-
the system in order to augment their structure with the required tivity diagrams. Workload annotations can be supplied for each
Log interface and link them to the Logger component in the scenario definition that defines the number of occurrences of
assembly. The customization interface for the Logging concern a scenario within a certain time period in terms of probability.
therefore consists of the Logged partial component. The combined information from resource demands, processing
Structural Usage Interface: The provided interfaces of rates and usage models makes performance prediction of
Palladio components are the key to executing the component’s architectures possible.
functionality. It therefore makes sense to use them as the ar- Since usage scenarios focus on describing user interaction
chitectural CORE usage interface. However, as some provided and workload with entire systems, we currently believe that it
interfaces of components within a concern should never be does not make sense to include usage scenarios in concerns.
directly connected to components in the reuse context, only Concerns are meant to be reused in many systems, each subject
specifically selected provided interfaces should be part of the to their own usage scenarios. Therefore, the remainder of this
usage interface. subsection focuses solely on integrating SEFFs with CORE.
Integration of Behavioural View with CORE can be used as is to also compose the sequence diagrams with
In the current reference implementation of CORE, the additional quality estimation information. This is true because
behavioural design of a concern is modelled using a variant of the composition is solely based on the control flow.
sequence diagrams that can describe control flow at the same If SEFFs are kept separately from the sequence diagrams
level of detail as code, if desired. One single sequence diagram (IS1), then a separate composition operator for SEFFs needs
specifies an interaction that can involve many operations to be defined. Just like for any other behavioural modelling
provided by multiple objects. notation, the order and sequencing of model elements that
When integrating CORE and Palladio, a component imple- represent internal and external actions in SEFFs is important.
mentor would use CORE sequence diagrams to specify the Hence, the composition operator for SEFFs would have to
functionality of the component with an object-oriented design. support the composition of behaviour from one SEFF before,
In this case, SEFFs are simply a more abstract representation after, around or in parallel of some behaviour in the other
of the behaviour of a component that adequately represents SEFF. Since CORE is based on additive composition, complete
the low-level detailed design described using CORE sequence replacement of behaviour does not need to be supported.
diagrams. In other words, the SEFF view and the sequence Instead, a limited form of substitution has to be provided,
diagram view should be consistent. If they are not consistent, where the original behaviour is moved to some place within
then the Palladio quality estimation tools would not be able to the substituting behaviour. The details of how this can be
accurately predict performance, reliability and cost of a design. accomplished with CORE sequence diagrams are presented
Integration Strategy 1 (IS1):: One way of keeping SEFFs in [19], and for general sequence diagrams in [20].
and sequence diagrams consistent is to define consistency rules When implementing the SEFF composition operator, care
or model checking algorithms that the CORE tool would use must be taken that the composition is compatible with the
to verify consistency periodically. Whenever the consistency sequence diagram composition already present in the CORE
check fails, the modeller would be prompted to adjust the reference implementation. Otherwise, when composing two
models. Additionally, model transformations should be defined concerns one could end up with an output that has inconsistent
to create a SEFF skeleton from an existing CORE sequence SEFFs and sequence diagrams, even in the case where the
diagram, and vice versa. The former transformation would SEFFs and sequence diagrams of each input concern are
support bottom-up development, since it creates an abstract initially consistent. Since the SEFF control flow structures are
SEFF representation that is consistent with an already exist- a subset of the control flow structures available in sequence
ing design. The later transformation would support top-down diagrams, it should be fairly easy to create a compatible SEFF
development, since it generates a skeleton design that corre- composition operator by adapting the algorithm of the existing
sponds to the high-level behavioural description envisioned by sequence diagram composition operator.
a software architect and specified in a SEFF. SEFF Integration Strategy Discussion: From the consid-
Integration Strategy 2 (IS2):: Another way to ensure that erations above it seems like it would be easier to choose IS1,
SEFFs and sequence diagrams are consistent is to combine i.e., combine sequence diagrams and SEFFs into one model.
the information from SEFFs and sequence diagrams into one First, there would be no need to define a new composition
model. To this aim, we need to identify the information operator, since the existing sequence diagram composition
encoded in the SEFF metamodel that is not currently present operator suffices. Second, concern realization models would be
in the CORE sequence diagram metamodel. The control flow simpler, as there would not be two separate views describing
structures in CORE sequence diagrams are at least as expres- the same behaviour at different levels of abstraction that must
sive as the ones in SEFFs, so they can replace the SEFF be kept consistent.
control flow structures. Similarly, whether an invocation of However, one of the advantages of Palladio is that it
an operation of a class is a internal or external action can be enables rapid design exploration. During development, SEFFs
determined by checking in the architecture model whether the can be used to capture intended behaviour of architectural
operation is part of a class that belongs to the same component components at a high level of abstraction even before they
or not. On the other hand, performance, reliability and cost exist. In doing so, it is possible to predict quality properties of
information, e.g., resource demands and failure rates, are only the solution architecture under development before the detailed
present in SEFFs. The sequence diagram metamodel would design of each individual component has been elaborated. If
therefore need to be augmented so that the quality information we want to continue to use Palladio for this purpose, then
from SEFFs can be attached to the right model elements of SEFFs have to be supported in CORE independently of CORE
the sequence diagram. sequence diagrams.
SEFF Customization and Usage Interface: We believe
that the customization and usage interface of SEFFs, in anal- C. Deployment View
ogy with what is done for CORE sequence diagrams, should The Palladio deployment view covers the specification of
be inherited from the customization and usage interface of the the execution environment and the allocation of software com-
structural view. ponents on resources of this execution environment, e.g., pro-
SEFF Composition Operator: If SEFFs and sequence cessors, servers, hard disks, communication links. Resources
diagrams were integrated by combining them into one model are annotated with information used for quality prediction,
(IS2), then the current sequence diagram composition operator e.g., processing and failure rates. At the current state of
research we believe that it is not necessary to integrate the tion can be made once the requirements of the reuse context
Palladio deployment view into CORE. The reason for this is are known.
that currently, concerns only encapsulate software components. While the approach proposed in this paper has multiple
Integrating the structural and behavioural views of Palladio advantages, it is also rather heavyweight, mainly because
into CORE as described above allows developers to define MDE and/or aspect-oriented programming has to be used
reusable software architectures and implementations that can for the detailed design of all solutions encapsulated within
be composed with an application architecture to yield a final a concern. If MDE technology is going to be used exclusively
system with an architecture that includes the components at the architecture level for design exploration and quality
defined in the reused concern. Developers would then create a prediction purpose, a more lightweight approach consisting of
deployment view for this final system architecture, i.e., define introducing a new concern-like grouping unit into the Palladio
resources and deploy the components onto them. component model could be envisioned as outlined in [21].
Adding deployment models to CORE concerns could make
R EFERENCES
sense if a concern would also encapsulate reusable hardware.
In that case, resource specifications for these hardware compo- [1] C. Szyperski, D. Gruntz, and S. Murer, Component Software: Beyond
Object-Oriented Programming, 2nd ed. New York, NY: ACM Press
nents should be provided in the concern, and different ways of and Addison-Wesley, 2002.
allocating provided software components and functionality to [2] D. L. Parnas, “On the criteria to be used in decomposing systems into
these resources could be expressed with deployment models. modules,” Communications of the ACM, vol. 15, no. 12, pp. 1053–1058,
Dec. 1972.
[3] E. W. Dijkstra, A discipline of programming. Prentice-Hall Englewood
V. C ONCLUSION Cliffs, 1976, vol. 1.
[4] A. Koziolek, H. Koziolek, and R. Reussner, “PerOpteryx: automated
application of tactics in multi-objective software architecture optimiza-
This paper presented a road map on how we are planning tion,” in QoSA-ISARCS 2011. ACM, 2011, pp. 33–42.
to integrate two highly complementary modelling approaches, [5] P. Tarr, H. Ossher, W. Harrison, and S. M. Sutton, Jr., “N degrees of
Palladio and CORE. Palladio and the Palladio bench tools en- separation: Multi-dimensional separation of concerns,” in ICSE 1999.
IEEE, 1999, pp. 107 – 119.
able modellers to specify component-based software architec- [6] R. Reussner et al., Modeling and Simulating Software Architectures -
tures and predict their quality by means of abstract behavioural The Palladio Approach. MIT Press, 2016, to appear.
specifications annotated with performance, reliability and cost [7] O. Alam, J. Kienzle, and G. Mussbacher, “Concern-oriented software
design,” in MODELS 2013. Springer, 2013, pp. 604–621.
information. CORE, in particular the current CORE reference [8] J. Kienzle, G. Mussbacher, O. Alam, M. Schöttle, N. Belloir, P. Collet,
implementation, provides facilities for encapsulating a variety B. Combemale, J. DeAntoni, J. Klein, and B. Rumpe, “VCU: The Three
of design solutions, and modelling the detailed designs of the Dimensions of Reuse,” in ICSR 2016, ser. LNCS, no. 9679. Springer,
June 2016, pp. 122–137.
solutions with class and sequence diagrams. [9] M. Blume and A. W. Appel, “Hierarchical modularity,” ACM Trans.
By integrating the Palladio architecture model with the Program. Lang. Syst., vol. 21, no. 4, pp. 813–847, Jul. 1999.
CORE reuse mechanisms and low-level design models as [10] K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson, “Feature-
oriented domain analysis (FODA) feasibility study,” Software Engineer-
described in this paper, reuse of existing architectural solutions ing Institute, Carnegie Mellon University, Tech. Rep. CMU/SEI-90-TR-
is greatly simplified. First, different architectural solutions 21, November 1990.
to the same development issue are easier to find, as they [11] T. van der Storm, “Variability and component composition,” in Software
Reuse: Methods, Techn., and Tools. Springer, 2004, pp. 157–166.
are grouped within a concern and their variability expressed [12] C. Kästner, K. Ostermann, and S. Erdweg, “A variability-aware module
with CORE feature models. Furthermore, the Palladio quality system,” in OOPSLA ’12. ACM, 2012, pp. 773–792.
estimation tools for performance, reliability and cost, and the [13] M. B. Duran, G. Mussbacher, N. Thimmegowda, and J. Kienzle, “On
the reuse of goal models,” in SDL 2015, ser. LNCS. Springer, 2015,
CORE impact models for any other relevant non-functional vol. 9369, pp. 141–158.
qualities enable informed decision making and even tradeoff [14] I. Crnkovic, S. Sentilles, A. Vulgarakis, and M. R. V. Chaudron,
analysis between the proposed solutions. Once a specific “A classification framework for software component models,” IEEE
Transactions on Software Engineering, vol. 37, no. 5, pp. 593–615, 2011.
solution is chosen, the CORE customization interface clearly [15] J. Muskens and M. Chaudron, Prediction of Run-Time Resource Con-
designates the architectural and design elements of the solution sumption in Multi-task Component-Based SoftwareSystems. Springer,
that need to be connected to application-specific elements. 2004, pp. 162–177.
[16] J. E. Kim, O. Rogalla, S. Kramer, and A. Hamann, “Extracting, spec-
Once the developer specifies the mapping, the aspect-oriented ifying and predicting software system properties in component based
composition operators of CORE take care of composing the real-time embedded software development,” in ICSE-Companion 2009,
chosen concern with the application. This includes adding May 2009, pp. 28–38.
[17] J. Kienzle, G. Mussbacher, P. Collet, and O. Alam, “Delaying decisions
interfaces to application components and linking them to in variable concern hierarchies,” in GPCE 2016. ACM, 2016.
components provided by the reused solution, and modifying [18] J. Kienzle, W. Al Abed, and J. Klein, “Aspect-Oriented Multi-View
the internal application design to invoke the services provided Modeling,” in AOSD 2009. ACM Press, March 2009, pp. 87 – 98.
[19] M. Schöttle and J. Kienzle, “On the challenges of composing multi-view
by the solution at the appropriate places. Finally, thanks to models,” in GeMOC 2013, ser. CEUR Workshop Proceedings, vol. 1102,
CORE’s support for delayed decision making, the developers October 2013, pp. 1 – 6.
of reusable architectural concerns can internally reuse other [20] J. Klein, F. Fleurey, and J. M. Jézéquel, “Weaving multiple aspects in
sequence diagrams,” Transactions on Aspect-Oriented Software Devel-
architectural and design concerns without having to make opment, vol. LNCS 4620, pp. 167–199, 2007.
premature or default decisions regarding non-functional imple- [21] A. Busch, Y. Schneider, A. Koziolek, K. Rostami, and J. Kienzle,
mentation alternatives. Ultimately this will increase reusability “Modelling the structure of reusable solutions for architecture-based
quality evaluation,” accepted at CloudSPD 2016.
of the solutions, as the commitment to a specific implementa-