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-