Synergizing Domain Expertise With Self-Awareness in Software Systems: A Patternized Architecture Guideline

To promote engineering self-aware and self-adaptive software systems in a reusable manner, architectural patterns and the related methodology provide an unified solution to handle the recurring problems in the engineering process. However, in existing patterns and methods, domain knowledge and engineers’ expertise that is built over time are not explicitly linked to the self-aware processes. This link is important, as knowledge is a valuable asset for the related problems and its absence would cause unnecessary overhead, possibly misleading results, and unwise waste of the tremendous benefits that could have been brought by the domain expertise. This article highlights the importance of synergizing domain expertise and the self-awareness to enable better self-adaptation in software systems, relying on well-defined expertise representation, algorithms, and techniques. In particular, we present a holistic framework of notions, enriched patterns and methodology, dubbed DBASES, that offers a principled guideline for the engineers to perform difficulty and benefit analysis on possible synergies, in an attempt to keep “engineers-in-the-loop.” Through three tutorial case studies, we demonstrate how DBASES can be applied in different domains, within which a carefully selected set of candidates with different synergies can be used for quantitative investigation, providing more informed decisions of the design choices.


I. Introduction
E NGINEERING software systems has been becom- ing increasingly complex, and labor-intensive due to the continuous changes in requirements, the underlying environments and the relevant data.Such complexity is prevalent when engineering self-aware and self-adaptive software systems-a category of systems that is capable of obtaining and maintaining knowledge on themselves and the environment, reasoning about this knowledge, and eventually adapting their operations to better cope with the changes.In this respect, engineers need some sets of high-level guideline that provides a clear overview of the software system to be built, based on which they are able to make better-informed decisions during the engineering process.Such a high-level guideline for engineering software systems can be represented in the form of architectural patterns and their methodologies.In essence, architectural patterns are particular solutions for common and recurring domain specific problems, culminating best practices, and described at high-level [1].A variety of architectural patterns and methodologies exist, each of which aims at a different context, e.g., distributed systems [2,3], service-oriented systems [4,5], self-adaptive systems [6,7], and more recently, self-aware and selfadaptive software systems [8,9,10,11,12] (a.k.a.selfawareness architectural patterns).
Unlike the other patterns, self-awareness architectural patterns particularly document the common primitives and different capabilities of self-awareness for obtaining and maintaining knowledge about different aspects, such as time, goals, or interactions between different nodes of software systems.While these patterns are abstract, they can be instantiated to meet particular needs for engineering a self-aware and self-adaptive software system, thereby providing more concrete guideline on how to align the capabilities of self-awareness with the requirements.Over the last few years, those patterns and the related methodology have proved to be promising when engineering self-aware and self-adaptive software systems, as evident by the fact that they have been referenced and used in various autonomic domains, such as cloud resource and configuration management [13,14,15], multi-processors systems scheduling [16], sensor network control [17] and multi-camera coordination [18].
Traditionally, engineering self-awareness in software systems have been primarily supported by various Artificial Intelligence (AI) algorithms, which serve as cheap and "black boxes" that can be directly applied with little specialization [19,20].However, as reviewed by Menzies [21], an emerging question in the application of AI algorithms to various engineering problems is the validity of the assumptions that underlie the creation of those algorithms.Therefore, the practice of applying standard AI algorithms as "black boxes", where researchers do not tinker with internal design choices of these algorithms with respect to their expertise on the problem is not ideal [21].Indeed, self-aware and self-adaptive software systems have never been created by non-experts.This means that software and systems engineers often accumulate domain expertise that is built over time.Such expertise, if captured and exploited, would provide an important added value to consolidate the self-awareness capability of the software system.Utilizing domain expertise to guide the processes of underlying AI algorithms, and thus the self-awareness, can bear additional benefit.In this way, the software system would be more controllable, which helps to monitor and avoid some abnormalities in behaviors, providing a foundation for keeping "engineers-in-the-loop".There existing many researches [22,23,24,25,26] that show superior results can be obtained by specializing AI algorithm to the particulars of engineering problem with domain expertise.
With this in mind, despite the successful applications of the existing architectural patterns and methodology for engineering self-awareness, the consideration of engineers' expertise, particularly on how they can be 'synergized' into the self-awareness capabilities, is weak, ad-hoc and left implicit.By the term synergy, we refer to the process of incorporating domain expertise, which involves the knowledge of the problem that is not naturally initiative (on contrary to, e.g., the range and type of parameters, various equality and inequality constraints) but can be extracted following engineering principles, into the underlying algorithms/techniques that realize self-awareness.Indeed, the lack of a holistic framework of patterns and methodology would inevitably create barrier for the domain information/knowledge to be maintained, reused and exploited to steer the design process, especially given a large variety of existing expertise representations and AI algorithms.This absence can eventually result in some strong domain expertise being overlooked, causing unncessary overhead and possibly misleading results [27,28].
To overcome such a gap, in this paper, we formalize a holistic framework that provides a principled guideline to perform difficulty and benefit analysis for synergizing domain expertise and self-awareness (hence dubbed as DBASES).Our aim is to elaborate and showcase how DBASES can support the "synergy" and reveal its importance, taking into account the self-awareness in software systems based on well-defined and widely used expertise representations, algorithms and techniques.It is indeed an ambitious plan, therefore we intend to be introductory rather than comprehensive.However, we hope that this work can spark a dialog about the diverse and representative research on combining domain expertise with selfawareness, and that some level of consensus on the design of such synergy will be achieved.
Specifically, our key contributions of the DBASES framework in the paper are: • We introduce general notions that captures the domain expertise of the engineers and their synergies with the concepts of self-awareness, providing intuitive, extracted and readily available information to enrich the self-awareness architectural patterns.Specifically, we contribute to the followings: -We present the notions of expertise representation with concrete examples, based on which we form a classification and the related rules that helps to capture the expertise knowledge.-Drawing on the expertise representation, we codify a taxonomy that describes their nature in terms of structurability and tangibility.-We then discuss their possible synergies with different capabilities of self-awareness, and present rules that classify different levels of synergies and the relative difficulty 1 , with respect to the structurability and tangibility of expertise representation.
• We illustrate, by means of examples, how the proposed notions can be used to enrich the well-defined self-awareness architectural patterns from the literature [8], and in what ways they can be instantiated to cope with different styles of synergies.• Supporting by the proposed notions and the enriched patterns, we present a practical, intuitive and step-bystep methodology that assists the engineers to analyze the difficulty and benefit for alternative synergies of domain expertise with self-awareness, revealing their importance.This would help the engineers to elicit the most preferred candidate(s) for further investigation, while ruling out some of the options that are clearly undesired, thus saving great effort in the development.
• We demonstrate three recent tutorial case studies [23,24,26], which relied on DBASES, that seek to build self-aware and self-adaptive software systems.
Through quantitative results, we show how DBASES can be applied to the engineering process for analyzing the difficulty and benefit of different synergy candidates, leading to a set of more promising ones for further investigation.
The remaining paper is organized as follows: we motivate the needs and discuss the related work in Section II, following by a brief overview of the capabilities of selfawareness and the existing self-awareness architectural patterns in Section III and IV.After such, in Section V, we present the notions and theoretical foundation that underpins DBASES.In Section VI, we illustrate how the existing self-awareness patterns can be enriched with DBASES.In Section VII, we present, as part of DBASES, a practical step-by-step methodology that assists the engineers in selecting the possible ways of synergies.Three tutorial case studies from different domains are drawn in Section VIII to demonstrate how DBASES can be practically applied.Finally, Section X concludes the paper with discussion on future work.

II. Preliminaries A. Problem Nature and Domain Expertise
As mentioned, self-aware and self-adaptive software systems have been increasingly relying on AI algorithms and techniques.Indeed, given the significant growth of the AI community, it is not uncommon to see that successful engineering of self-awareness is underpinned by several AI algorithms [29,30,31,32,23,33,26,34,35,36], which conducts learning, reasoning and problem solving.
In general, the application of standard AI algorithms and techniques may need to be combined with sufficient domain information, and thus they can better serve the purpose.Yet, it is important to note that domain information can be distinguished between the problem nature and the domain expertise.In fact, the former refers to the nature information of the problem, which is the basic elements required to appropriately apply the algorithm/techniques (e.g., the range of parameters) [27,28]; and the latter is the engineers' domain expertise, which is specifically related to the engineering problem to be addressed and is often deemed as optional, but desirable.In essence, what make the additional engineers' domain expertise differs from the basic problem nature is that, • Problem nature refers to commonly known properties and characteristics of the problem domain, such that the AI algorithms have to comply with in order to be used appropriately.This may, for example, include the range of parameters, sparsity of the values, various equality and inequality constraints, etc. Directly applying standard AI algorithms is often considered as exploiting only the problem's nature, due primarily to the generality of existing AI algorithms [21].• In contrast, the domain expertise is represented as or produced by typical software and system engineering methods, practices and models.Most commonly, the knowledge of domain expertise is not naturally intuitive form the problem context, but can be extracted through engineering practices, skills and tools, e.g., design models, formatted documents or even concepts.

B. Lessons from Applying Standard AI Algorithms in Engineering
In the software and system engineering community, there is an increasing recognition on the limitation of applying standard AI algorithms to various engineering problems.A very recent study, conducted by Agrawal and Menzies [32], on a wide range of software engineering problems have revealed the following fact: Our conclusion is that the algorithms which we call "general AI tools" may not be "general" at all.Rather, they are tools which are powerful in their home domain but need to be used with care if applied to some new domains like software engineering.Hence, we argue that it is not good enough to just take AI tools developed elsewhere, then apply them verbatim to software engineering problems.Software engineers need to develop AI tools that are better suited to the particulars of software engineering problems.
The conclusion delivers a very clear message that the standard AI algorithms combined with the necessary information of problem nature, including those that realize self-awareness [27,28], cannot fully meet the complex requirements of engineering software systems.It therefore calls for better specialization of these AI algorithms based on the domain expertise of engineers.
From the literature, it is not uncommon to see that greater benefits can be obtained by synergizing domain expertise.For example, there is a thread of research that seeks to synergize Feature Model, which represents domain expertise on requirement analysis, with evolutionary search to reason about behaviors of the self-aware and self-adaptive software systems [37].This is motivated by the fact that domain expertise on the requirement cannot be easily captured by simply applying the AI algorithms.Another example of "software/system engineering needs different AI algorithms" comes from the work of Hindle et al. [38], in which they stated that, unlike the common areas where AI was most originally applied, domain expertise in software engineering may suggest some important terms in the code which is used exponentially less frequent.This can provide useful information when model the software system with AI, enabling more accurate self-awareness of the faults.
The domain expertise of engineers can often serve as useful information to engineer self-aware and self-adaptive software systems, thus they should not be simply ignored.To this end, a better synergy between domain expertise and AI algorithms is required.Although in this case the AI algorithms may be made less general and pose extra difficulty, they are expected to work better under the given problem where the domain expertise lies, and more importantly, rendering the self-awareness more controllable.It is in fact part of our contributions in DBASES to provide better analysis on the trade-off between difficulty and benefit when designing different ways of synergy.

C. The Problems
As summarized in the recent surveys [27,28], majority of the work incorporates merely the necessary information of the problem nature with self-awareness in an ad-hoc manner, which is the direct application of the standard AI algorithms.This is because the problem nature can be easily obtained and the existing AI algorithms are designed to be as general as possible, such that they will cope with the basic properties of different domains.However, it is clearly difficult to perform the same for synergizing domain expertise without omission.The key issue is that there is a lack of general guideline that assists the engineers when engineering self-awareness into software systems with explicit consideration of the domain expertise.For example, it is not uncommon that engineers would have certain domain expertise represented as models, documentations, or even artifacts of a software systems, but how they may be related to self-awareness is unknown.Below, we illustrate some common, but difficult decisions and problem to deal with during the synergy process, together with what contributions in DBASES can help on each: • Which available domain expertise can be synergized into which aspect of self-awareness?-Answering such would require understanding on both the available domain expertise and which aspect of the self-awareness is required, e.g., time, goal or interaction [39].Clearly, there will be constraint that prevents certain synergies, e.g., a feature model cannot usually help in terms of interaction, as its notation does not embed any knowledge of it.In essence, the feasible synergies form the possible candidates for the engineers to make design decision.Yet, it is challenging to build the set of candidates for synergy in the absence of systematic guideline, especially when multiple forms of domain expertise and aspects of self-awareness exist.
Self-awareness architecture patterns with explicit synergy between domain expertise and self-awareness, as discussed in Section IV and VI.

What parts in DBASES can address this?
• To what extent can a synergy be completed and what are the difficulties?-Synergies can often be done in different levels, e.g., whether the domain expertise can be directly incorporated into the algorithm/techniques or certain internal components need to be specialized [40,8].This is a crucial design decision to make and it should not be conducted without knowing the relative difficulty, which directly related to the cost of the engineering and maintenance process.However, without guideline, it would be difficult for the engineers to obtain a full picture of the possible extents of synergy and their difficulties.
Generic notions and categories of different synergy levels and their relative difficulties, as shown in Section V.

What parts in DBASES can help this?
• How to make decision taking into consideration the difficulty of synergy and the expected benefit?-The different candidates of alternative design options would inevitably lead to a decision space [41,42].As a result, it would be challenging to enable well-informed decision making without the support of quantifiable and intuitive metrics.In particular, given the potentially large number of alternatives, it would be nicer to intuitively understand which can be ruled out and what needs to be investigated further.
Methodological guideline and quantification metrics for visualizing possible candidates of synergies with respect to their difficulties and benefits, as elaborated in Section VII.

What parts in DBASES can improve this?
As a result, the lack of general guideline on how to exploit engineers' expertise when engineering self-awareness into software systems would hinder the benefits of domain expertise synergy, causing barrier to create more advanced and controllable self-awareness driven by the expertise of engineers.
This is what we seek to achieve in the paper with DBASES for engineering self-aware and self-adaptive software systems, in which we conduct the first attempt to propose a general, yet holistic framework to assist the engineers in making decisions of synergy, or at least a more concise set of options that are subject to further investigation.

D. Related Work on Architectural Pattern and Methods
Software and system architecture, as the highest level of abstraction for all software systems, serves as the framework for satisfying requirements; as the managerial basis for cost estimation and process management; and as an effective basis for reuse and dependency analysis [43].From the community of software and system engineering, architectural patterns and the related methods seek to abstract common features of architecture instances in a specific domain, which is known to serve as a useful guide to the engineers when designing software systems [43].Among others, Cost-Benefit Analysis Method (CBAM) [42] and Architecture Trade-off Analysis Method (ATAM) [41] are two most widely used methodologies that help to reason about different design options on architectures and their patterns.However, they were designed to deal with general software system and thus are irrelevant to the concept of self-awareness.
Over the past two decades of research for architecting self-aware and self-adaptive software systems, several architecture patterns and their methodologies have emerged.Among others, feedback loop based architecture pattern [44], whether as single loop or multiple loops, have been the most widely adopted approach.Such pattern merely assume that the software system can be monitored, and that it can be influenced after certain process is completed based upon the collected data.The reason behind its popularity is due to its simplicity and flexibility, such that there is no constraint on how and what should be architected in the patterns.Yet, as the software system becomes more complex, such simplicity turns into a barrier, as the software and system engineers require more specific guideline when designing the architecture which has been missing from the feedback loop based architecture pattern.
In light of these, the MAPE-K architecture pattern [6] and its design guidelines are proposed to provide more specific codification about what should be achieved within a feedback loop when engineering selfaware and self-adaptive software systems.In MAPE-K, the (K)nowledge component is shared by the (M)onitor, (A)nalyser, (P)lanner and (E)xecutor components, which provides primitives for expressing domain knowledge in K.This knowledge is used to reason about run-time adaptation.Two other patternized methods, which are sub-classes of MAPE-K but generic enough to be classified as representative styles with distinct qualities.The first is proposed by Oreizy et al. [45] such that the pattern consists of an adaptation layer and an evolution layer.Particularly, the adaptation layer is responsible for monitoring and adapting, while the evolution layer caters to ensuring changes in the running system are performed in such a way that the operation of the system is not disrupted.The second patternized method is Rainbow [7], which is explicitly designed for engineering rule-based adaptation in software systems.Since the above patterns assume a centralized scenario where there is only one instance of software system to be adapted, the MAPE-K is then further extended by Weyns et al. [46] into a decentralized version, such that they are specialized into contexts with different degree of decentralization that the software system encounters, with some guidelines.
Inspired by Gat's three layered architecture in the robotics domain [47], Kramer and Magee presented a conceptual three layered architecture patterns and methods [48] for self-adaptive software system.The three layer, namely goal layer, change layer and component control layer, work in a hierarchical way such that the goal layer provides change plans, which are then further translated into change actions by the change layer, and eventually those actions are run by the component control layer.The opposite of the direction would occur when data needs to be collected.
Alternative to the MAPE-K and the three-layer pattern, SEEC [49] is another set of architecture patterns and methods that claim self-aware capabilities.In a nutshell, SEEC relies on the basic (O)bserve-(D)ecide-(A)ct (ODA) loop [49].Here, the O and A components in ODA are equivalent to the M and E components in MAPE-K respectively, while analysis and planning tasks are subsumed in the Decide component.Another more recent effort, namely LRA-M loop [9], aims to capture the knowledge of selfawareness in terms of universal models, which can then be exploited by the reasoning.
However, all the above patterns and methods have focused on providing guideline about how to exploit the obtained knowledge to inform adaptation, but limited in modeling the knowledge at a coarse grain, without explicit distinction between knowledge concerns for different levels, e.g., at goals, time, or interaction.In 2014, we proposed a set of self-awareness patterns and method-olgoy [8,10,11,12] derived from the general concept of self-awareness [50] for engineering self-aware and selfadaptive software systems.Unlike others, we explicitly encode the pattern based on the fine-grained capability of self-awareness with respect to stimulus, goal, time, interaction and meta-self, considering their distinctions and interplays (we elaborate the patterns in Section III).Those patterns have been followed by a considerable amount of work from other research groups and have attracted a wide range of attentions.However, our experience with industrial partners when using those patterns and methods (together with the other state-of-the-art) is that they fail to capture how domain expertise, and more importantly how they can be combined with the AI algorithms that underpin self-awareness, which is now become the major barrier for them to follow.

III. The Capabilities of Self-Awareness in Software Systems
Self-awareness is certainly not new in the other disciplines, but it is challenging to model such a concept in the context of software systems.In this work, we use the term node to refer to a software system that can either work alone, or as one individual in a networked group of different systems.Drawing on Neisser's notions on the self-awareness from the psychology domain, different capabilities of computational self-awareness have been codified [50], which are what the DBASES framework based upon.As illustrated below, each self-aware capability captures distinct knowledge that a software system would need in order to perform self-adaptation and selfexpression at certain degree: • Stimulus-awareness: A software system is stimulusaware, if it has knowledge of stimuli.The software system is not able to distinguish between the sources of stimuli.It does not have knowledge of past/future stimuli, but enables the ability in a software system to respond to events.It is a prerequisite for all other capabilities of self-awareness.• Time-awareness: A software system is time-aware if it has knowledge of historical and/or likely future phenomena.Implementing time-awareness may involve the software system possessing an explicit memory, capabilities of time series modeling and/or anticipation.
• Interaction-awareness: A software system is interaction-aware if it has knowledge that stimuli and its own actions form part of interactions with other systems and the environment.It has knowledge via feedback loops that its actions can provoke, generate or cause specific reactions from the environment.It enables a software system to distinguish between other nodes of software systems and environments.Simple interaction-awareness may just enable a software system to reason about individual interactions.
More advanced interaction-awareness may involve the possessing knowledge of social structures such as communities or network topology.In this work, from the pattern's perspective, we strictly treat interaction awareness with respect to the different nodes of software systems and/or the environment, and thus the internal information about interactions between different elements within a single software system is not considered as knowledge of interaction.• Meta-self-awareness: A software system is metaself-aware if it has knowledge of its own capability(ies) of awareness and the degree of complexity with which the capabilities(ies) are exercised.Such awareness permits a software system to reason about the benefits and costs of maintaining a certain capability of awareness (and degree of complexity with which it exercises this capability).

IV. Self-Awareness Architectural Patterns
While the notions of self-awareness can be well conceptualized with respect to a software system, the presence of various requirements would still need more concrete guideline on how those concepts can be modeled within the needs.This urges a formal documentation of the selfawareness as architectural patterns when engineering selfaware and self-adaptive software systems.An architectural pattern refers to an architectural problem-solution pair for a given domain, which in the context of self-aware software systems, means that they are linked to the capabilities of self-awareness.Our previously proposed self-awareness architectural patterns [8,10,11,12] have been showing great potential in engineering self-aware and self-adaptive software systems.
In such context, different capabilities of computational self-awareness enable capability of the systems to obtain and react upon certain knowledge, which could be either about its own states or about the environment.The patterns provide a formal way to ensure that only relevant capabilities of self-awareness are included, and their inclusion justified by identified benefits.There is no need for a system to become unnecessarily complex, learning and maintaining self-awareness capabilities which do nothing to advance the outcomes for that system, generating only overhead.Each of the self-awareness architectural patterns is decentralized by design.That is, structurally they resemble a peer-to-peer network of interconnecting selfaware nodes, varying only in the number of the capabilities and the type of interconnection between them.Even with Fig. 1: The basic notations for self-awareness architectural patterns.
the decentralized expression, a centralized software system can be easily modelled by considering only one node.In this section, we provide an overview of these well-defined patterns with selected examples.

A. Notations
In general, an architecture of software system consists of two fundamental elements, the component and connector, which are described as below [8]: • Component: A smaller and more manageable part of a software system, which is often divided based on requirements, functionality and purpose.• Connector: A bridge that represents the possible interaction between components and the multiplicity involved.The uniqueness of the self-awareness architectural patterns is that, the component is replaced by the notion of capability of self-awareness, sensoring and actuating, in which case they are not necessarily to be a one-toone mapping.In other words, depending on the context, two or more capabilities may be combined and realized in one component; or one capability can be implemented in separate components.The basic notations used to describe the patterns are depicted in Figure 1.
In particular, the connectors are used to express the physical and logical interactions, which have different notations: • Physical connector: This means there is a direct interaction between the components, and each component is required to directly interact with the others.Notably, the physical connectors are further divided into two types.The first type, expressed red arrow, particularly refers to the interactions for different capabilities of the self-awareness (e.g., goal and timeawareness); in contrast, the second type, denoted by black solid arrows, represents the interactions for the self-awareness of the same capability (e.g., the interaction-awareness from different interacting software systems) • Logical connector: This does not require direct interaction, but rather the data or control in the interaction is sent/received through the sensors and actuators, which have the physical connector.For instance, self-expression and self-adaptation might be logically required to reach consensus amongst different nodes, but such interaction is physically realized through Sensors and Actuators.Note that the Sensors and Actuators can be either external or internal, where the former refers to the case that information/control is aimed for external nodes; while the latter means such data/control exchange only happen internally at the current node.The benefit of additionally introducing the logical connector is that, for example, when designing a capability of self-awareness where the communication protocol is not needed, the pattern can still illustrate that the software system needs to interact with the others.Thus, this provides the engineers with a more precise view on the architecture.
The multiplicity operators are used to represent how many concrete components (which may realize one or more capabilities of self-awareness), including those from different nodes of software systems, are involved in the interaction.In the self-awareness architectural patterns, there are three types of multiplicity operators (denoted as Mul_Op): • + expresses that the number of components that realize the same capability in the interaction is restricted to at least one.
• 1 indicates that one and only one component that realizes the same capability is permitted.• * indicates that zero, one or many components that realize the capability specified is permitted in the interaction

B. The Patterns
Drawing on the feasible combinations of the self-aware capabilities, we have previously documented eight welldefined patterns for engineering self-aware software systems [8].In a nutshell, these patterns are summarized in Table I.Noteworthily, the meta-self-awareness is considered as an optional capability, and thereby it is not explicitly coded into a particular given pattern.Each pattern was documented using standard pattern template [51] as follows.
• Problem/Motivation: A scenario where the pattern is applicable  different software development contexts in which that problem appears [52].
In other words, we provide a collection of architecture design decisions to realize the self-aware capability, parametrized by the level of knowledge available(which is behavioral in essence).The provided description is generic, providing template solution to a recurring problems.Level of knowledge can range from stimuli, time, goal, interaction and so the parameterization of the design decisions that invoke the self-aware capability.
In fact, codifying different structures has been commonly used as the way to patternize software architecture when engineering self-aware and self-adaptive systems [46].Our ways of formulating and describing the pattens were inspired by Weyns et al. [46], who propose patterns for selfadaptive systems with special focus on their interactions in a decentralized manner.It is worth noting that the pattern can be instantiated, such that a capability may be decomposed into more than one actual components.
Indeed, the key differences of the patterns are what combination of self-aware capabilities is involved, but they also exhibits different forms of interactions and multiplicity.This is important, as the combination of capabilities cannot be done arbitrarily.For example, all the patterns would need stimulus-awareness; stimulus-and goal-awareness cannot be the only capabilities to form a pattern, as merely obtaining information about the stimulus does little help to reason about goals.There are also examples where the combination of self-aware capabilities are the same, but differ on how they interact with each others, e.g., the Basic Information Sharing Pattern and Coordinated Decision-making Pattern.
In the following, we elaborate on two patterns as examples, the more comprehensive specification can be found in our handbook [8].
1) Temporal Knowledge Aware Pattern: Problem/-Motivation: The knowledge of timing enables the capability of proactive adaptation and potentially, better adaptation quality.However, the other capability of TABLE I: Self-Awareness Architectural Patterns.

Pattern Self-Aware Capabilities Characteristics
Basic Pattern stimulus-awareness For cases where some actions need to be triggered in order to cope with emergent events and stimuli Basic Information Sharing Pattern stimulus-and interaction-awareness For cases where more nodes may be required with loosely shared data to meet the scalability requirement of the system Coordinated Decision-making Pattern stimulus-and interaction-awareness (with additional interactions to external nodes) For cases requiring consistent global decision making in a cooperative setting Temporal Knowledge Sharing Pattern stimulus-, interaction-and time-awareness For cases where timing of actions and availability of historical knowledge have an impact on the integrity of information sharing in the software system Temporal Knowledge Aware Pattern stimulus-and time-awareness For cases where timing of actions and availability of historical knowledge is required only at the local level Goal Sharing Pattern stimulus-, interaction-and goal-awareness For cases where goal reasoning and optimization is required with strong consensus Temporal Goal Aware Pattern stimulus-, time-and goal-awareness For cases where timing of actions and availability of historical knowledge are required for local optimization and reasoning of goal Fully Self-Aware Pattern stimulus-, interaction-, time-and goalawareness For cases where timing and historical knowledge is required for performing goal reasoning with strong consensus awareness, e.g., interaction, might not be a necessity, therefore it could affect the self-aware system as it is suffering unnecessary overhead.Solution: As shown in Figure 2, in this pattern, the knowledge of timing enables the capability of proactive adaptation and potentially, better adaptation quality, which is specifically supported via time-awareness.The Temporal Knowledge Aware pattern incorporates only time-awareness working in conjunction with stimulus awareness, which eliminate the unnecessary overhead introduced by the other capabilities of self-awareness, i.e., the goal, interaction and meta-self awareness may not be needed.
Consequences: When using this pattern, the key benefit is that the software system can be equipped with knowledge about historical data.The categories of data are vast, ranging from the internal states or the environment.However, this should not include data about the other nodes, as interactions has been omitted.It should be noted that this pattern does not cater for changing goals and their related reasoning.That is, it assumes that the goal of the software system is known at design-time and statically encoded in the system, without the opportunity to modify and reason about at run-time.
Example: A concrete example of where this pattern is applied could be for the cloud environment where resource is sharing via Virtual Machine (VM) on each node of software system.In this context, by leveraging the historical usage of resources, time-series prediction would be able to predict the demand of VMs on a node of software system for the near future, which assists proactive provisioning of resource and potentially, prevents requirements violation and/or resource exhaustion.
2) Temporal Goal Aware Pattern: Problem/Motivation: The knowledge of goals and time together might not necessarily to be shared amongst nodes, especially in cases where the optimization of local goals could lead to acceptable global optimum.Solution: As shown in Figure 3, in the temporal goal aware pattern, the goal-awareness provides explicit capability to reason about and even modify the goal at runtime, which offers further guarantee on the optimality of certain goals.However, the knowledge of goals and time might not necessarily to be shared amongst different software systems, especially in cases where the optimization of local goals could lead to acceptable global optimum.Specifically, in this pattern there is no notion of 'sharing' information as the software system is not aware of any interactions and, therefore, it does not aware of the presence of the other nodes.It is worth noting that the absence of interaction awareness does not mean there is no interaction-the software system and the environment could still interact with each other, but it merely does not aware of the details involved in the process.
Consequences: A key benefit of this pattern is that the knowledge of historical events can be used in conjunction with the ability to reason about goals.This often provides emergent adaptation behaviors [23,25].However, a major limitation is the removal of interaction awareness, especially when the goal-awareness is present, implies that different nodes of software systems could be in inconsistent state.The engineers should carefully verify that such situation would not result in violations of system requirements.In addition, the self-expression and self-adaptation on a software system could not use any information from others when making decisions.
Example: Example application domain of the pattern could be: for adaptive web application in a centralized mode, there is only a single software system exist, and thus no interaction is needed.Another more complex example is when orchestrating fully decentralized harmonic synchronization amongst different mobile devices, which requires each node of software system to aware of stimulus, time and goal but not necessarily interaction.In such case, each software system receives phase and frequency updates from the others or the environment, and reacts upon based on its own time and goal information.This is a typical example where there are occurrences of interaction, but no occurrences of interaction awareness; because a single software system only aware of the incoming phase and frequency updates but it has no knowledge of where they come from.

C. Guideline on Selecting Patterns and Underlying Algorithms/Techniques
In our handbook [8], we have codified a comprehensive guideline that assists the software engineers to select the self-awareness architectural patterns for a node, and the underlying algorithms/techniques2 that realize each capability.In a nutshell, the selection of patterns and algorithm/techniques follows the general processes of ATAM [41], which is a well-know methodology on design selection, such that the choice is made based on qualitative assessment and quantitative evaluation, supported by simulation and profiling.
Noteworthily, albeit that the patterns are alternative for a single node, different nodes can be based upon distinct patterns, or different instantiations of an identical pattern, under systems-of-system or distributed environment.Therefore, the patterns can be used in a composite manner.
As shown in Figure 4, the overall guideline is an iterative process, in which the selection of pattern and the underlying algorithms/techniques can be continuously refined based on the profiling results.The final outcome for each node, after a satisfied number of iterations, would be the instantiation of a selected self-awareness architectural pattern with chosen underlying algorithms/techniques for self-awareness.Due to limited space, we advice interested readers to our handbook [8] for detailed information.

A. Representations of Engineers' Domain Expertise
As mentioned in Section II-A, for domain information, it is important to distinguish between problem nature and domain expertise; the former is not necessarily equivalent to the latter.Domain expertise, particularly that from the software and system engineers, can be represented in various forms.For the simplicity of exposition, we use the following terminology to explain this concept in DBASES: • Expertise Representation: Expertise representation is generally abstract, which can be further refined and customized for expressing the domain expertise that captures domain knowledge for a specific case.These are often the general skills and tools that are familiar to a software and system engineer.For example, feature model is a representation of the expertise, which is commonly used by software and system engineers.It can be applied to a wide range of application domains within each of which the representation would be specialized into a particular design instance.
• Category of Expertise Representation: This refers to a group of expertise representations that share similar nature, e.g., feature model, UML models and goal model are all design models.Clearly, an expertise representation can be specialized into different instances that share the same structure, rules and semantics, but each can capture/be tailored to handle different knowledge about the domain.Drawing on the recent survey about what expertise knowledge has been considered in practically engineering self-awareness [27,28], DBASES is underpinned by a classification, as shown in Table II, to categorize the most commonly used expertise representations when engineering software systems 3 .Each of the categories are explained as follows.
Methodology: This refers to the systematic specification and analysis methods that are applied to abstract the expertise and represent it to aid the development

Category Example Expertise Representations
Methodology RUP [53], agile [54], SSADM [55], SCURM [56], ... Concept technical debt [57], code smell [58], software entropy [59], feature creep [60], ... Model feature model [61], goal model [62], UML [63], Markov model [64], Petri net [65], queuing model [66], I* [67], viewpoints model [68], design patterns [69], ... Documentation SLA [70], requirement documents [71], user manual, configuration files, API documents, software and system specifications, ... Program source code of one (or more) programming language, library invocation and dependency, ... Assumption past problem instances and experiences, insights from peer and users discussions, ... of software systems.An expertise representation can be considered in this category if all of the following criteria are met: -It covers all or nearly all the phases in engineering a software system.-It contains specific methods, rules, postulates, procedures, or processes to manage a software or system project.-It involves description about the roles of different stakeholders in the engineering process, e.g., analysts, designers and testers.Concept: This includes the intents, drivers/forces and motivations that derive the knowledge/expertise capture and representation.An expertise representation stands as a Concept if all of the following criteria are met: -It represents an abstract idea or generic notion in mind that captures some common and justifiable phenomena of different instances in software and system engineering.-It aims to describe an idea or notion in a "plain" way that is intuitive and close to the general understanding of human.-It is a widely recognized practice and truth in the engineering process.Model: This involves the standard for abstracting the expertise; it can systematically capture at least certain aspects of a software system, which are mainly utilized during the analysis and design phases.An expertise representation belongs to Model if all of the following criteria are met: -It contains a formal notation or language to describe how knowledge about the software system can be captured.-It can represent certain aspects of the software system and the relationships between them.-It is a more formal way of representing concept(s).
-It is often illustrated in a graphical manner.Documentation: This refers to artifacts that document and express the metadata for the representations of expertise, specifying scope, constrains, uses, anti-uses, etc., with an aim to be understandable for different stakeholders (e.g., end users, managers).An expertise representation belongs to Documentation if all of the following criteria are met: -It contains metadata provided on digital or analog media.
-It aims to illustrate data or represent agreement between parties for the software system.-It is entirely (or mostly) based on "plain" textual language of human.Program: This involves the expertise representations that actually enable the software system to run.An expertise representation is related to Program if the following criterion is met: -It is related to the source code that enables the execution of the software system.Assumption: This refers to the expertise representations that are directly derived from the subjective beliefs and experience of the software and system engineers, which may not be well-justifed.An expertise representation can be considered in this category if all of the following criteria are met: -It is a general belief about the software system derived from specific instances.-It represents the sense of expectation on certain aspects of the software system, which is not guaranteed to be true.The above classification in DBASES does not aim to be exhaustive, but they serve as a general guideline that covers majority of the cases, and thereby it can be flexibly extended.It may be possible that a given representations of expertise can fit more than one categories, in which case it is the engineer's decision on which one is more suitable.Similarly, it is also possible that a representation cannot be fitted into any category above.In such case, the representation can form an additional category (e.g., Other category), which can then be considered under the criteria of structurability and tangibility that we will elaborate below.

B. Structurability and Tangibility
The expertise representation expresses knowledge can be a result of one's experience, which would be in various forms.Therefore, it is also important to understand whether these representations is structural and tangible, as studied in human cognition research [72].In software and system engineering domain, it is not uncommon to see that more structural representations can be more beneficial [73] and more tangible ones are better tools to express knowledge [74].Therefore, given the variety of different expertise representations, explicitly recognizing their category in terms of structurability and tangibility is important.A structural representation means that the organization of its information follows specific rules, or semantics; otherwise, it is said to be non-structural.Specifically, a given representations of expertise is structural if all of the following criteria can be satisfied: -Its organization and arrangement of the internal elements (and their relations) form some repeatable patterns.-It can be specialized into as case dependent variants, which, although different, can still be derived from the same core.-It contains explicit, step-by-step information about how itself can be 'assembled'.A tangible representation refers to the expertise representation that is perceptible by directly interacting and/or observing; or otherwise it is non-tangible.Again, a representation of expertise is tangible if all of the following criteria can be satisfied: -It can be directly seen or touched to understand the information it holds.-It comes with a digital or analog media.
In Figure 5, we further taxonomize the aforementioned six categories of expertise representations depending on their nature with respect to the above criteria of structurability and tangibility, as part of DBASES.The taxonomy provides a more intuitive way for the engineers to understand how a category can be linked to these two properties.However, it is worth noting that any given expertise representation can be assigned using the above criteria.
It is clear that expertise representations in the category of Model and Program are both structural and tangible, as they can easily meet all the criteria mentioned above.On the other extreme, representations in the category of Assumption and Concept, as the name suggests, are both non-structural and non-tangible.Because they cannot be derived from the same pattern, and are difficult to be seen or interacted with directly, which have failed to meet the criteria for being structural and tangible.
Documentation contains expertise representations that can be directly seen and comes with a media, thereby they are tangible, but could be structural or non-structural.For example, Service Level Agreement (SLA) and API documents also satisfy the three criteria of being structural.In contrast, requirement documents and user manuals are non-structural, whose content is documented by natural language without specific rules.Thereby they fail to meet the criterion that there are variants which can be derived from the same common ground.
The category of Methodology would have expertise representations that are non-tangible as they cannot be directly observed.Yet again, they could be structural or non-structural.For instance, SSADM is a rather structural methodology and it satisfies all three criteria.In contrast, SCRUM , which is a form of Agile methodology, does not contain explicit, step-by-step information about its internal structure due to the need of being flexible.Therefore, SCRUM is said to be non-structural.

C. Relation Between Expertise Representations and Capabilities of Self-Awareness
Expertise representations can be possibly synergized to inform, enrich and/or refine the capabilities of selfawareness depending on the domains, and guided by the specific design of expertise representations.Drawing on the work reviewed by recent survey on engineering selfawareness [27,28] and our understandings form the EPiCS project 4 [50], in Table III, we illustrate some examples of the possible synergies with respect to the categories presented previously.
Given the openness of certain categories of expertise representations (e.g., Methodology and Assumption), the domain expertise can be potentially synergized to benefit all the possible capabilities of self-awareness.For example, the SCURM methodology can help to better understand the engineering process of the algorithms that realize certain self-awareness.In addition, the methodology also covers the management between incremental development and operation phase.This, for instance, can assist the meta-self-awareness to collect suitable data about the applicability of other self-awareness as the software system runs, and thereby providing readily available information to be discussed again in the next phase of incremental development.
For other cases, on the other hand, domain expertise knowledge can be only useful to certain capabilities.For example, domain knowledge expressed using feature models would be useful for stimulus-, time-and goalawareness, but can be of limited help for interaction and meta-self-awareness.This is because it neither expresses information on the interactions between nodes of software systems, nor provides foundations to reason about the needs of different self-awareness capabilities.
Another example is related to the goal modeling.In particular, goal modeling and its various refinements can be synergized with the benefit of goal-awareness.The aim, for example, is to dynamically analyze the satisfaction of 4 http://epics.uni-paderborn.de/

Assumption
past problem instances and experiences stimulus-, time-, interaction-, goal-and meta-self-awareness insights from peer and users discussions stimulus-, time-, interaction-, goal-and meta-self-awareness ... ... that goal, areas and traces within the model that requires refinements and further elaboration to meet the goal.This can be supported by synergizing the goal model with the stimulus-and time-awareness which would enable better goal reasoning.However, the goal model itself does not often express information on interaction.As mentioned, capturing and modeling the knowledge, expressed via domain expertise can take forms of structured or unstructured and tangible or non-tangible, which is heavily influenced by the available representations of domain expertise for the engineering of the self-aware and self-adaptive software system.Arguably, the structured and tangible expertise representations are often more systematic means and disciplined approaches, while unstructured and non-tangible ones can be naturally flexible for probing, learning and cross-fertilisation of expertise.In this regard, the structurability and tangibility can largely affect the design and maintenance difficulty of synergy, as we will discuss in Section V-F.
It is worth noting that the examples here are merely for guideline on the possible synergies in DBASES, they do not mean to restrict one to follow a specific synergy if both the expertise representation and the related capability of self-awareness are available.Whether a synergy is needed, as well as the level and form of such synergy (as we discuss in the following) are highly domain dependent.

D. Levels of Domain Expertise Synergy
Generally, the information possessed by an expertise representation can be synergized with a capability of self-awareness at different extents.However, given the complexity of expertise representation, as well as the underlying algorithms/techniques for self-awareness, the synergy of expertise with self-aware software system may required to be automatic depending on the level.
In DBASES, we propose and distinguish four hierarchical levels of expertise synergy with a self-aware capability, which can be flexibly selected and reasoned about given the requirements.The hierarchical levels are derived from our experience on working with industry practitioners form the EPiCS project [50], together with the work in recent survey on engineering self-awareness [27,28].It is known that hierarchical analysis is highly beneficial for classifying concepts in engineering software systems, especially when dealing with requirements of the engineering problems [75].Specifically, inspired by the work from Berry et al. [76], we describe each level according to the aspects listed as below: • Motivation: A scenario where the level is required • Criteria: A set of criteria classifies the synergy to a particular level.• Description: A general elaboration of the characteristics of the level • Example: An instance where the level has been used The levels are structured in an incremental way, i.e., level 2 would retain all the properties of level 1 and level 0.
1) Level 0 of Synergy: Motivation: This is the level such that there is no actual domain expertise synergy, but could merely utilize the necessary information about the problem nature to achieve the most basic specialization of the AI algorithms.This is often the case when standard AI algorithms are directly applied.
Criteria: Since this is the most basic level of synergy (i.e., no synergy at all), and thus there are no criteria for this level, as in essence, any realization of the selfawareness is at least level 0.
Description: Here, the engineers may not (or only trivially) reason about the problem and thus there may be no expertise representations.The underlying algorithm and technique that realize a capability of self-awareness does not use any information derived from the domain expertise.At this level, the synergy is a manual process.
Example: Considering a distributed system, where there is a machine learning algorithm that learns what are the important nodes to be tuned, but if the nodes are simply taken from whatever nodes that are currently running, then here, information of the problem nature (the available nodes) is used in stimulus-awareness.However, there is a lack of human reasoning involved (thus no domain expertise).Therefore, in such case, we still have level 0 of domain expertise synergy.
2) Level 1 of Synergy: Motivation: Apart from the problem nature, which is often naturally intuitive with the problems, software and system engineering involves many cases where the detailed information is not obvious, which can only be made available through the expertise of engineers together with various tools and methods.
Criteria: Specifically, the synergy is at level 1 if the following criterion is met: -The expertise representation is specialized through indepth reasoning according to the software system to be built.Description: This is the most common level where there is a limited synergy between domain expertise and self-awareness.Here, the engineers do reason about the problem and there are certain expertise representations.However, there is no, or only trivial, machine reasoning on the reasoned expertise representation that aims to extract more meaningful information for a capability of self-awareness (and the underlying algorithm/technique), which is the key step to sufficiently synergize the expertise.At this level, the synergy can be either a manual or automatic process.
Example: For example, the produced feature model design is a representation of expertise after careful human reasoning, but if the goal-awareness simply embed all the features form the model to optimize, then it is clearly a level 1 of domain expertise synergy, as some information about the human reasoning is used (the features) while there is no further, non-trivial reasoning about the feature model itself.
3) Level 2 of Synergy: Motivation: The expertise representation produced by extensive human reasoning is likely to be complicated and large, which may be an inevitable result for the software system that is built and evolved over years.In such case, the useful information contained in the expertise representation is blur and difficult to be used directly.

Criteria:
The synergy is at level 2 if all of the following criteria are met: -The expertise representation is specialized through in-depth human reasoning according to the software system to be built.-There is a non-trivial automatic process that extracts information from the expertise representation for the software system.Description: In this level, the engineers are required to reason about the problem and produce certain representations of their expertise.There is also a need of further automatic machine reasoning, which extracts and synergizes the useful information of the reasoned expertise representation with the underlying algorithm and techniques for realizing self-awareness.However, the underlying algorithms and techniques do not need to be aware of the information about the expertise; they may operate as if there is no such information.
Example: For example, an engineer may reason about and produce a feature model, then, the model would be further reasoned and extracted, such that the irrelevant features for optimizing the software system are ruled out in the capability of goal-awareness.However, from the perspective of the search algorithm, it does not aware that the given features to tune have been tailored by the experts' specialized knowledge; it would merely operate as if those features were selected arbitrarily.
4) Level 3 of Synergy: Motivation: While most algorithm/techniques would work without changing their internal structure, it is often the case that when their internal components are tailored specifically with the extracted domain expertise, the expected results can be largely improved.Such a process is not essential, but desirable.
Criteria: In particular, the synergy is at level 3 if all of the following criteria are met: -The expertise representation is specialized through in-depth human reasoning according to the software system to be built.-There is a non-trivial automatic process that extracts information from the expertise representation for the software system.-The internal components of the algorithm are tailored, such that it can actively and directly exploit the information extracted from the expertise representation.Description: This is the highest level of domain expertise synergy.Here, both human reasoning and automatic machine reasoning on the representation of expertise are needed.In addition, the underlying algorithm and technique for realizing self-awareness need to be tailored in a way that they can be aware of the experts' specialized knowledge, and thus promote more explicit reactions and exploitation of the expertise.This often implies a nontrivial consolidation to the internal components of the algorithm and techniques, which would make them less general but being more specific to the given problem.
Example: Considering a queuing model, which is analyzed and designed by the engineers, used to syner-gize with a tailored machine learning algorithm to offer better awareness of goal.In this case, the queen model has some parameters that can be tuned automatically.More importantly, the machine learning algorithm is aware of the expertise expressed in the model, such that the training and updating mechanism can be tailored by the queuing model, which will clearly influence the accuracy of learning.
It is worth noting that for all levels, self-awareness and self-adaptation are still achieved through the underlying algorithms and techniques, but their behaviors are guided by varying the amount of information about the engineers' domain expertise, as constrained by the corresponding level of domain expertise synergy.

E. Benefit Score on Synergy
Generally, it is expected that a higher level of synergy would lead to better quality of self-awareness, and eventually better results of self-adaptation.This is because the underlying algorithm and technique can be guided, or even consolidated, with the information of domain expertise to fit with the domain problem better.To support quantitative reasoning on the potential benefit for different levels of synergy in DBASES, each level can be assigned a numeric score as below: • Level 0: benefit score=1.25 • Level 1: benefit score=1.5 • Level 2: benefit score=1.75 • Level 3: benefit score=2 where the value are normalized into the range between 1 and 2 to assure numeric stability.Noteworthily, the scores are fairly flexible as they serve as indication on the relative rank between different levels.Hence, the above scores are default settings in DBASES where the margin between different levels are equivalent.It is however perfectly acceptable to ask the stakeholders and engineers to assign the relative benefits score depending on the needs, similar to what have been done in CBAM [42], as long as the ranking remains unchanged.For example, if one consider that level 3 is likely to obtain much higher benefits than the others, then one may assign the benefit scores from level 0 to level 3 as: 1.1, 1.2, 1.3 and 2, respectively.Indeed, the proficiency would have a definite impact on the likely benefit, as immature expertise, e.g., that from a naive or inexperienced engineer, would likely to mislead the algorithms and techniques for self-awareness and selfadaptation.To reflect on this, within the methodology we introduce in Section VII, the engineers are asked to weight the proficiency on the expertise representation and the underlying algorithms for self-awareness, based on which a more informed-decision of the synergy can be made.

F. Difficulty Score on Designing Synergy
In DBASES, the design of the synergizing domain expertise with a self-aware capability can be of either specific or general forms.In the specific case, one needs to analyze and reason about a particular instance of (c) level 3 Fig.6: Design difficulty and the related score of expertise synergy with respect to the levels, structurability and tangibility.(w denotes the weight (w ∈ [1,2]) that distinguishes the difficulty between general and specific form of synergy for all cases.level 0 always has a difficulty score of 1) expertise representation (e.g., a design of feature model), and synergize it with a specific algorithm/technique (or any algorithms/techniques of the same type) that realizes self-awareness and self-adaptation.In the general case, the synergy needs to operate on different instances of expertise representation, e.g., it works on any design instance of the feature model, and any algorithms/techniques of the same type.Undoubtedly, these forms do not applied on the level 0 of synergy.
It is clear that designing the general synergy would impose greater difficulty than the specific one, as wider range of the possible instances under the expertise representation needs to be considered.Here, the difficulty also serves as a general indicator of the cost in terms of labour, time and resource for both implementation and maintenance, therefore it is a crucial factor to consider when synergizing domain expertise.Within each of the two forms of synergies, the relative degrees of design difficulty varies depending on the levels of expertise synergy, as well as the structurability and tangibility of the expertise representation involved.Depending on different situations, the relative level of difficulty and the associated numeric scores have been illustrated in Figure 6 5 .Note that the design difficulty for level 0 of synergy is constantly set as 1, i.e., they are at most as hard as level 1 synergy even considering different forms, since there is no actual synergy at all.More specifically, in Figure 6, the difficulty is ranked in a way that it is consistent with the general understanding.
At level 1, the synergy shares similar design difficulty regardless to the structurability and tangibility, because at this level the main difficulty is related to the human reasoning of the domain knowledge, which is part of the tasks that the engineers have to do regardless whether there is a synergy.In particular, the algorithms and techniques for realizing self-awareness and self-adaptation are directly exploited to the domain, rendering the actual synergy relatively straightforward.At level 2, the synergy becomes more difficult in general.Particularly, the design difficulty becomes higher as the related expertise representation turns into a non-structural form, but remain unchanged with respect to the tangibility.This is because here, the underlying algorithms and techniques do not required to be aware of the domain expertise, thus the tangibility is less important.However, machine reasoning on the given expertise representation is necessary, therefore the domain expertise needs to be made structural for the automatic reasoning and synergy to take place.Such an extra processing of structuring could impose additional design difficulty.Finally, at level 3, the expertise representation needs to be both structural and tangible, and thereby for expertise representation that belongs to the category of Assumption or Concept, additional efforts need to be conducted on both structuralization and tangibilization, rendering it as the most difficult case of synergy.Relatively, structuralization is more complex and difficult than tangibilization, as the former often requires in-depth and high proficiency on the expertise representation, while the latter, can be as simply as translating and documenting the concepts.
Based on the ranking, each case is assigned a numeric score to add quantitative values in the design process.The scores have been normalized into the range between 1 and 2, which can be used directly in the methodology discussed in Section VII.w is the normalized weight (between 1 and 2) that distinguishes the difficulty between general and specific form of synergy (e.g., 2 for general and 1.5 for specific) as provided by the engineers.Such a weight is applied to all possible synergy under consideration when engineering a self-aware and self-adaptive software system.
Noteworthily, similar to the benefit scores, the default margin between the difficulty scores of different cases are almost identical.However, it is perfectly possible that if one consider a case to be more difficult than the others and hence amend the margin, as long as the ranking is preserved.
Indeed, the actual synergy approach is highly domain dependent, relying on the selected underlying algorithms/techniques for self-awareness, the expertise representation that is available and the other constraints as well as requirements.Nevertheless, given the information about the expertise representation and the expected level of domain expertise synergy, the degree of design difficulty offers the engineers with intuitive guidelines and information on the likely barriers, in addition to the likely benefits.This arises the opportunity for them to rethink and even refine the level of expertise synergy at the design stage, considering the trade-off between efforts and the expected quality.To demonstrate such in details, in Section VIII, we elaborate examples of the synergy approaches within the contexts of three diverse case studies.
VI. Enriched Self-Awareness Patterns in DBASES We now illustrate how the notions of domain expertise representations and their synergies in DBASES's foundation can be embedded with the capabilities of selfawareness, which are collectively expressed using the selfawareness patterns.

A. Capabilities of Self-Awareness in the Patterns with Explicit Domain Expertise
The proposed self-awareness architectural patterns, as discussed in Section IV, can be enriched based on the proposed synergy framework in Section V. Figure 7 shows the general capabilities of self-awareness, which underpins the self-awareness architectural patterns, with explicit links to different expertise representations.Such a general enrichment can be instantiated into diverse instances, depending on the available expertise representation, the selected pattern and the required synergy.Clearly, for a particular domain, there can be more than one expertise representation (from the same or different categories), but only one specialized instance of an expertise representation exists at a time.Those expertise representations, depending on their categories, may or may not undergo structuralization and tangibilization.Importantly, an expertise representation needs to be synergized with at least one capability of self-awareness (e.g, time, goal) and its underlying algorithm/technique.On the other hand, there is no cap on the maximum number of self-awareness capabilities that it can synergize with; it is possible that an expertise representation may be synergized with all the capabilities of self-awareness.According to Figure 6, each synergy expresses the expected level involved, as well as the form and the design difficulty, which are separated by semicolon.Noteworthily, it is important to distinguish level 0 of synergy and no domain information is required.The former has no synergy but the information of the problem nature may still be used.The latter refers to no information is used in a self-aware capability at all.With the enriched pattern, level 0 is still expressed, but without showing the selection of form and the difficulty level.This becomes much more intuitive when instantiating the enriched selfawareness pattern with explicit domain expertise, which we elaborate in the following section.

B. Examples of Instantiating the Patterns with Explicit Domain Expertise
In Figure 8, we illustrate an example where the Information Sharing Pattern and the related algorithms and techniques have been chosen.Then, following the general pattern from Figure 7, the Information Sharing Pattern can be instantiated with explicit domain expertise and the related synergies in different ways, among which Figure 8 is one candidate.In this example, the expertise representation is a design of the Petri net that contains rich domain expertise about the concurrency and transitions between conditions etc.This is particularly useful for the interaction-awareness and the underlying algorithm/technique, which enables a level 2 synergy between domain expertise and self-awareness.Specifically, the actual synergy can vary, for example, suppose a machine learning algorithm underpins the interaction-awareness to learn the likely under-utilized node for assigning more workloads.Here, the designed Petri net provides strong domain expertise about the features (conditions), which can be further parsed automatically to form a more relevant set of features.Finally, the resulted feature set is learned by the machine learning algorithm.This is clearly a level 2 of synergy, as there are both human and machine reasoning on the expertise representation, yet the machine learning algorithm itself does not know the fact that the given feature set was derived from domain expertise.There is no link between a design of the Petri net and stimulus awareness, which means no information has ever been used for stimulus.As expressed in the figure, the form of synergy is specific, which means only a design of Petri net needs to be synergized with the capability of self-awareness.Given that the Petri net belongs to the category of Model which is both structural and tangible (as seen from Figure 5), there is no additional structuralization and tangibilization.The design difficulty of synergy is therefore 'easy' according to Figure 6.In contrast, if the expected level of domain expertise synergy was level 1 or level 3, then the design difficulty would becomes 'very easy' or 'moderate', respectively.
Figure 9 shows a slightly more complicated example, in which the Goal Sharing Pattern and the related algorithms and techniques have been selected.In this example, the Goal Sharing Pattern can be instantiated with two aspects of domain expertise that are of different expertise representations and from distinct categories.Again, there could be different ways of synergies depending on the form and level, within which Figure 9 illustrates only one candidate.Specifically, the design of queuing model is clearly a type of model while the requirement document belongs to the Documentation category.There are three synergies of domain expertise, each of which belongs to a different level.At the simplest form, the queuing model can create a level 1 of synergy with stimulus-awareness.This can be, for example, the feature components of the model serves directly as the detection points of any stimulus from the software systems, and therefore no extra reasoning and analysis conducted on the produced queuing model.Another synergy is between the queuing model and the goal-awareness, which can be of level 2. Here, certain parameters in the designed queuing model may be changed dynamically, either by a deterministic or machine learning algorithm.The tailored model, in turn, acts as the function to evaluate an adaptation solution within a search algorithm that optimizes toward the optimality of a goal.Such extra reasoning conducted on the queuing model has promoted the synergy to level 2.
In this example, the requirements document requires a relatively more complex, level 3 synergy with the goalawareness.For example, the negotiated requirement document may be further analyzed using techniques for natu-ral language processing, then, the results are synergized with the internal structure of a search algorithm, e.g., to form tailored operators.In this way, the synergized expertise is fully awared by the underlying algorithm that realizes goal-awareness, which can explicitly react to the knowledge of expertise.This is aligned with the criteria of level 3. Again, those missing links between an expertise representation and a capability of self-awareness implies that there is no information to be used at all.
In this case, the queuing model can be linked with specific form of synergies while the requirements document requires the general form, in which case any given formats and designs of the requirements document needs to be synergized with the self-awareness capability, and thus it is relatively harder.The relative design difficulty for all three synergies can be distinguishable using Figure 5 and 6.A queuing model is both structural and tangible, and thus no extra processes are needed, therefore the level 1 synergy has a design difficulty of 'very easy' while the level 2 one is classified as 'easy'.The synergy related to the requirements document is more complex, as it belongs to the Documentation category and it is tangible but nonstructural.As a result, given the required synergy of level 3, the relative design difficulty is 'very hard'.Note that since the requirements document requires general forms for its two synergies, they are likely to be more difficult than the specific one for the queuing model.

VII. Methodological Analysis in DBASES
Drawing on the aforementioned notions and enriched patterns, in this section, we codify a detailed methodology, as part of DBASES, that can assist the quantitative design on the synergy when engineering self-aware and selfadaptive software systems.In a nutshell, the methodology contains the steps below, whose details will be explained in the following sections: Step

A. Patterns and Algorithms
The first step is to determine which is the suitable architectural pattern for self-awareness and the underlying algorithms/techniques6 that realize the self-aware capabilities.As mentioned in Section IV, we have proposed a handbook, together with a comprehensive guideline to guide the engineer to make such selections.A more thorough explanation and case studies can be found in the handbook [8].

B. Representations of Expertise
The actual representation of domain expertise is highly depending on the case, and thus their diversity can vary.However, arguably any given software and system engineering would require at least one formal representation of expertise.In this step, we ask the engineers to create a list of all available representation of the expertise based on their existing knowledge, some of which could be taken from the examples in Table II.

C. Candidates Creation
According to the available representations of expertise identified in step 2, this step aims to answer the following questions for each of these representations: 1) Which category does the expertise representation belong to? (using the criteria in Section V-A) 2) If such a representation structural? is it tangible?(using the criteria or classification in Section V-B) 3) The expertise representation can be synergized with which algorithm/technique that realizes the selfaware capability?What are the possible levels of synergy?(using the criteria in Section V-D) 4) What is the possible form for each synergy?5) What is the difficulty level for each synergy?(using the Figure 6) Noteworthily, the different synergies of expertise representations and their combinations form the possible alternative instantiations of the enrichment for the selected pattern, as shown in Section VI.In this way, step 3 aims to create a candidate set of instantiations for the enriched patterns with information about all possible ways of synergies.For example, suppose that there are two expertise representations and the chosen pattern is Information Sharing Pattern, which has two self-aware capabilities.If both representations need to be synergized with all self-aware capabilities while the synergy can be at all levels and under both forms, then considering all possible combinations, the outcomes of step 3 would be 2 × 4 4 = 512 candidates.The final selection would be made based on the quantitative scores on both the difficulty and benefits for all the alternative candidates.

D. Difficulty and Benefit Scores
In this step, we aim to visualize the difficulty and benefits score for all the candidates identified from step 4 using the synergy framework.In particular, the overall difficulty of a candidate C n that has a total of n synergies is calculated as: whereby d i is the original difficulty score for synergizing the corresponding expertise representation in the ith synergy.As mentioned in Section V-F, the original difficulty score has been pre-defined according to the structurability and tangibility of the representation.The w is a normalized weight given by the engineers and it is applicable to all other synergies.p i is the proficiency on the ith synergy (normalized between 1 and 2), which covers both the expertise representation and the underlying algorithms/techniques that realize the corresponding self-aware capability.The higher proficiency, the less difficulty for achieving the synergy.
The overall expected benefit of a candidate C n can be computed as: where b i is the original expected benefit score for the ith synergy, as discussed in Section V-D.Again, w and p i is the actual form (i.e., general or specific) of the synergy and the proficiency, respectively.The higher proficiency, the larger the expected benefit.As mentioned, the value of w and p i are entirely depends on the domain, and therefore it is difficult to draw any general guidelines.However, their relative settings can be discussed case by case.For example, the relative w between general or specific form of synergy may be small for structural and tangible expertise representation, as it is more straightforward to generalize it from specific cases; in some situations, the w may be identical as the two forms may not differ too much, such as queuing model.In contrast, for non-structural and/or non-tangible expertise representations, their margin of w can be amplified.As regards to p, the category of domain expertise representation and the selected algorithms, together with the engineer's own experience, can provide indication about how its value for different synergies can be relatively set.For example, an engineer who works on software variability management and machine learning algorithms for years would likely to rank a high proficiency for the synergy between feature model and learning algorithm, but for other synergies, the proficiency can be given a relatively low value.

E. Further Investigation
As we can see from the example of benefit/difficult plot in Figure 10, each candidate is an instantiation of the selected and enriched patterns with a particular way of synergizing domain expertise.While some of the candidates are clearly dominated by the others, there can be a trade-off between the difficulty and the expected benefit.Indeed, to physically validate whether the achieved benefits and incurred difficulty (in terms of both implementation and maintenance) by the candidates are truly acceptable, it is an ideal case that if all the candidates can be subject to further investigation and profiling, i.e., the actual implementation, profiling and evaluation.However, given the time/resource constraint in real-world software and system development scenario, it is often the case that only a handful of them can be prototyped [42].This is in fact what we seek to provide with the engineers: an intuitive and principled guideline to extract the candidates for further investigation.In DBASES, the intuitive visualization of benefit/difficult plot provides the necessary foundation for the engineers to select only the most desirable ones, ruling out those that are clearly unneeded and thus saving the valuable human efforts in investigating them.As an example, Figure 10 shows three selected candidates for further investigation.
Noteworthily, despite that there may be more than one way to implement the prototype of a particular candidate, it is generally possible to use a representative in the comparison process during further investigation, as what has been done in the domain of architecture profiling [42].
After further investigation, the final selection for production would inevitably involve not only the engineers, but also other stakeholders of the software systems.However, the methodology in DBASES, supported by the framework about synergy between domain expertise and self-awareness, their levels of difficulty and the enriched patterns, have enabled a more intuitive and quantitative visualization of all the possible alternatives in the trade-off.This, in turn, provides better informed decision making when synergizing domain expertise with the selfawareness in software systems.

VIII. Case Studies: Practical Applications of DBASES Framework
In this section, we illustrate the practical applications of DBASES framework on three tutorial case studies, each of which is recent research effort that seeks to engineer selfawareness into different types of software systems.Those studies are the collaborations in a team of researchers and engineers from China and UK, under the funding grants from their research councils.
As part of the methodology in DBASES, for all case studies, a set of desirable and representative candidates was selected for further investigation.This includes the actual prototype implementation of these candidates, deploying the resulted self-aware and self-adaptive system(s), running them and measuring their behaviors according to various quality indicators with real-world benchmarks.Eventually, the most promising one with the verified results would be chosen for production.
Each case study covers a type of software systems that may be applied to different scenarios, e.g., a highly constrained software system may run as a web-based systems or service-based systems.Therefore, for the candidates that are subject to further investigations, their prototypes were run on one or more scenarios.All the quantitative experiments are done in real environments, using the actual software system that fit under a given scenario.The data and source code used for all three case studies are publicly available on GitHub 7 .

A. Self-Awareness and Self-Adaptation for Highly Constrained Software Systems
Context: Self-adaptive software systems often have several non-functional quality attributes ( e.g, latency and throughput), which are difficult to manage due to the changing environment, such as workload.Those software systems are centralized, but structurally complex, i.e., there is a large number of features and complex dependency constraints.A typical example could be the multilayered web applications, in which the actual software is often rely on a stack of third party libraries and frameworks, each of which own different adaptable features that can interplay together to influence the behaviors of the entire software system.
Problem: The aim of the first case study is, at runtime, to achieve more effective multi-objective optimization on the non-functional qualities of software systems.Clearly, in such context, self-awareness offers stronger capability for a software system to conduct more informed optimization and reasoning.
Challenges: The challenges here are two-folds: (i) it is difficult to effectively and systematically convert the design of self-adaptive systems, expressed as a feature model, to the context of a search algorithm while considering the right encoding of features in the solution representation.This is even more complex in the presence of feature dependency constraints, e.g., the cache size can only be adapted when the cache feature has been 'turned on', or, the size of a thread pool needs to be equal or greater than the number of spare threads in the pool.(ii) Optimizing multiple conflicting objectives and managing their tradeoffs are complex and challenging in self-adaptive systems, especially at run time.This is attributed to the huge number of alternative adaptation solutions that can vary with their quality for the said requirements.Moreover, the dynamic and uncertain nature of self-adaptive systems further complicates the conflicting relations between objectives, rendering the trade-off surface difficult to explore.
1) Patterns and Algorithms: After analyzing the requirements and following the handbook [8], it has been identified that there is no need to have knowledge about  the interactions.This is because the target software system was not aimed for distributed environment, and that it is considered as satisfactory to optimize the local goal for a single self-adaptive system.Further, the environment is not expected to actively react on the adaptation of the software system, and thus no interaction between it and the environment.There is also no need for a meta-selfawareness, because the extra overhead on reasoning about the different capabilities of self-awareness is unnecessary, as the requirements on the capabilities are clear.In contrast, goal-awareness is the essential part as it permits capability to reason about goal and search toward an optimal (or near-optimal) solution.Time-awareness is also important in the modeling of goal, which consolidates the capability to thoroughly evaluate, and even predict, the effectiveness of a solution during the optimization process.As a result, these have led to the conclusion that the Temporal Goal Aware Pattern is the most appropriate pattern for the design.The pattern has been illustrated in Figure 3.The primary goal is to optimize non-functional quality, and thus a vast of search algorithms are available.However, there may be an explosion of the search space for the self-adaptive system, which renders the problem as intractable.Further, it is difficult, if not possible, to obtain a precise understanding on the nature of the optimization problem beforehand and there are often multiple conflicting quality to be optimized.Drawing on these and as guided by the handbook [8], it has been concluded that the metaheuristic algorithms, particularly the evolutionary algorithms, are promising to realize the capability of goalawareness in the software systems.However, given the wide range of possible domains, it is expected that the solution does not tie to a specific evolutionary algorithm, rather, it should support a diverse set of evolutionary algorithms.In addition, machine learning algorithms and other modeling techniques can be used to support the knowledge of time, which form the objective model that is essential in the reasoning of goal.Finally, stimulus-awareness, which is the simplest capability of self-awareness, can be realized by periodic detection.A complete list of the algorithms and techniques that realize the capabilities of self-awareness involved are show in Table IV.
2) Representations of Expertise: In this case, the only available representation of expertise is the feature model [77], which is expressed as the tree structure.Such a model is widely used for software and system engineers to represent the functional variability of a software.In the context of self-adaptive software systems, the inherited concept of a feature model allows it to define the extent to which the software system is able to adapt at runtime (i.e., a range of variations that the software system can achieve).
In particular, there is no definite constraint about the level that the feature model can cover, i.e., the features define the prominent or distinctive aspects between different variations of a software system [61], which range from highlevel architectural elements (an entire component) to lowlevel configurations (a specific parameter).Figure 11 shows an example of the feature model, where there are four inbranch dependencies and two cross-branch dependencies: • Optional refers to the feature that might be 'turned off'.• Mandatory denotes core features that cannot be 'turned off'.• XOR represents the feature in a group such that exactly one group member can be 'turned on'.
• OR means a group in which at least one group member needs to be 'turned on'.• F i require F j means the former can only be 'turned on' if the latter is 'turned on'.• F i exclude F j denotes two features that are symmetrically mutually exclusive.
3) Candidates Creation: At this step, all the possible ways of synergy can be created by instantiating the enriched self-awareness architectural pattern.In particular, answers to the questions presented in Section VII are shown as follows: 1) Which category does the expertise representation belong to? -Answer: Feature model belongs to the Model category.
2) If such a representation structural? is it tangible?-Answer: It is both structural and tangible.
3) The expertise representation can be synergized with which algorithm/technique that realizes the selfaware capability?What are the possible levels of synergy?-Answer: It needs to be synergized with all three self-aware capabilities in the enriched Temporal Goal Aware Pattern.However, the synergy can only be at level 1 to the stimulus awareness but level 1 and level 2 are allowed for time awareness.For goal awareness, all levels except level 0 are possible, but level 2 and level 3 would required the synergy with time awareness to be at level 2 .4) What is the possible form for each synergy?-Answer: Only the synergy with goal awareness can be of both specific or general form.The others are to be realized in a general form.5) What is the difficulty level for each synergy?-Answer: According to Figure 6, the difficulty level ranges between very easy to moderate.The above answers have led to six different candidates of synergizing domain expertise represented as the enriched Temporal Goal Aware Pattern.
4) Difficulty and Benefit Scores: For all the six candidates, their overall scores with respect to both the difficulty and benefit are illustrated in Figure 12.In particular, the w between specific and general form of synergy is set as 1.2 and 1.4, respectively, the proficiency is set as 1.8 for all synergies in a candidate.

5) Further Investigation:
As shown in Figure 12, after discussions, three candidates have been selected for further investigation, as they are either desirable or serve as representatives for the others.Briefly, each of the candidates is specified as below: 13a, the candidate automatically extracts only important features to create synergies in time-and goal-awareness, at level 2 and level 3, respectively.In particular, dependency constraints are also injected and synergized with the evolutionary algorithms that underpins the goal-awareness.No machine reasoning is required for stimulus-awareness, which senses directly on the features at level 1 of synergy.13b, achieves the synergy of the feature model with goal-awareness at level 2 (general form), such that the evolutionary algorithm does not aware of the dependency constraints; all the other synergies remain the same as that of C 1 .13c illustrates the candidate in which the feature model is synergized with time-and goal-awareness at level 1 (general form), i.e., all possible features are selected to be tuned without further parsing of the feature model, and no dependency constraint is captured by the evolutionary algorithm.All the other synergies remain the same as that of C 1 .More technical details on the actual synergy approaches  can be found in [23].6) Further Investigation Setup: Since all the synergies are in general form, the candidates are evaluated on two different real subject software systems, namely RUBiS [78] (a web system) and SOA [33] (a service system), under two distinct categories of evolutionary algorithms, i.e., Nondominated Sorted Genetic Algorithm II [79] (NSGA-II) and Indicator-Based Evolutionary Algorithm [80] (IBEA), for realizing goal-awareness that optimizes different conflicting quality objectives.The details of the two subject software systems can be found in Table V.Given that the optimization occur at runtime, the setup of both algorithms have been carefully tuned, such that the mutation rate is 0.1 and crossover rate to be 0.9, with 100 population size for 10 generation.Each experiment is repeated 100 tuns to cater for the stochastic nature of the optimization.For the time-awareness, machine learning model [13,81,82] is used for RUBiS and the analytical model [33,25] is adopted for SOA.The results are statistically significant as confirmed by the Wilcoxon Signed Rank test (p <0.05) with non-trivial effect sizes, following the guideline provided by Kampenes et al. [83].
The quality indicators for benefit and difficulty are shown in Table VI.As can be seen, the benefits are assessed by various performance attributes, which are scenario dependent, as well as the percentage of valid solutions found for adaptation.The difficulty is evaluated by using Lines-Of-Code (LOC) of the implemented prototypes for the candidates, as it is a common metric to measure the complexity in software engineering.A higher LOC implies higher complexity in implementation and maintenance, hence higher difficulty 8 .7) Results: As shown in Figure 14 and 15, clearly, we see that for all cases, in contrast to C 3 , C 2 finds more solutions that are condensed to the bottom-left (top-left for SOA) corner of the objective space.This means that more advanced synergy helps to enable more promising results in the optimization.When comparing C 1 and C 2 , the solutions are even more condensed to the ideal corner under C 1 , and is of particular significance in the case of SOA due to its stronger extents of conflicts.This proves that allowing the underlying algorithm for goal-awareness to be aware of the domain expertise, although impose higher design difficulty, can be very beneficial in terms of the results.
Figure 16 illustrates the mean percentage of valid solutions found, and we see that the C 1 achieves 100% valid solution as the evolutionary algorithm is aware of the expertise about the dependency during the evolution, which promotes the ability to actively repair the solutions that violate dependency.C 2 , on the other hand, do not have such benefits but it is more likely to result in valid solutions than that of C 3 .This is because C 2 encodes a set of automatically extracted and more elitist features to be tuned.C 3 , in contrast, encodes all the features in the feature model, which can hardly find valid solutions given the high number of features in the subject software systems.
For the difficulty shown in Table VII, as expected, C 1 has the highest LOC which implies higher difficulty in implementation and maintenance.C 2 is ranked the second but its differences to C 3 is small, which suggests that the difficulty related to automatically extracting the important features is considerably low.
According to the verified results from the further investigation, the team has decided that C 1 is a more preferred and promising choice for production.

B. Self-Awareness and Self-Adaptation for Change Expensive Software Systems
Context: Self-adaptive software systems may subject to financial contracts with respect to its performance and resource consumption to perform adaptation.For example, a software system deployed on the Cloud Computing platform are charged on the amount of resources it consumes, and it may incur monetary penalty (or reward) for violating (or exceeding) some agreed threshold of performance.In particular, the adaptations in the target self-adaptive software systems are often expensive, or the reasoning process related to the adaptation is resource consuming, and therefore in certain cases, it could be more beneficial to not adapting.
Problem: In the second case study, the aim is to dynamically determine when and whether to adapt those critical software systems for which adaptations can impose expensive cost.This again exhibits a strong requirement of self-awareness.

Challenge:
The key challenge is how to model and reason about the dynamic and uncertain cost-benefit between adapting the software system and not adapting it, then deciding on when and whether to adapt.It is required to measure the software systems not only on the achieved quality of non-functional attributes, but also, in terms of the monetary values that it generates, or carry as debts.
1) Patterns and Algorithms: After analyzing the requirements and following the handbook [8], it has been concluded that there is no interaction awareness required, as the target software system was not aim for distributed environment, and that it is considered as satisfied to optimize the local goal for a single self-adaptive system.Further, the environment is not expected to actively react on the adaptation of the software system, and thus no interaction between it and the environment.There is also no need for a meta-self-awareness, because the requirements on the required capabilities is clear and that the problem itself aims to reduce the extra computations involved in TABLE VIII: The algorithms and techniques that realize the capabilities of self-awareness for the second case study.

Self-Awareness
Algorithms and Techniques stimulus awareness periodic detection time-awareness machine learning the self-adaptation process.Therefore the overhead produced by meta-self-awareness, which could be potentially high, should be better avoid.Indeed, the self-adaptive software system itself is often goal-aware due to the need of explicitly reasoning on the goals and objectives.However, for the problem that should be dealt with (i.e., when and whether to adapt), extensive reasoning on the goals is not the key purpose; rather, it is more related to track and make a binary decision: to adapt or not to adapt, drawing on insights about their time-varying cost-benefits.As a result, these have led to the conclusion that the Temporal Knowledge Aware Pattern as the appropriate pattern for the design.The pattern has been illustrated in Figure 2.
In this case study, the primary goal is to model the time-varying cost-benefit on the decision of adapting and not adapting the software system.Therefore, by following the steps in the handbook [8], machine learning algorithm has been identified as the promising way to handle the problem.This is because they are often effective in producing fast prediction in acceptable time, given that sufficient amount of past samples.Since there are only two decisions to model, the problem can be rendered as a binary classification problem, where, given a set of features, (e.g., software system status, environment changes, etc) the model aims to predict whether it is better to adapt or not.Again, given the generality of the target software system, the solution should not be specific to a particular machine learning algorithm, and thus it should support a wide range of the types, allowing for better flexibility on customization.As for the stimulus-awareness, it can be easily realized by periodic detection.A complete list of the algorithms and techniques that realize the capabilities of self-awareness involved are show in Table VIII.
2) Representations of Expertise: Here, there are two representations of expertise, namely the Service Level Agreement (SLA) and the technical debt concept.In general, SLA is a formal legal binding negotiated between the software company and the end users before the software system is built [84].An example fragment of the typical SLA, derived from the well-known WS-Agreement [85], is shown in Figure 17, which states the rate of reward and penalty on the mean latency ($/s) and rate of CPU time of planning ($/s) for a software system.Specifically, the SLA states that the rate for the cost of adaptation is $0.345 per CPU second; and an adaptation that utilizes 2s would lead to a total cost of $0.69.Similarly, the SLA may contain a penalty rate of mean latency violation as $0.043/s for a requirement of 2s.Therefore, if there is a mean latency of 2.5s for a period, then the penalty for it would be (2.5 − 2) × 0.043 = $0.0215.
Technical debt for software engineering was coined by Cunningham [57], to help deciding whether to improve the software, considering the costs and benefits of improvement versus that of not improving it.In general, when software faces bugs or requires improvement, the engineers have two options: (i) improve the software, in which case the quality of the software may be improved, but extra rework cost would needs to be paid for the human and resources spent, or (ii) leave it as it is, and thereby the software remain as flawed, which could accumulate the interests incurred by the bugs.The benefit of technical debt concept is that it offers an intuitive way for software and system engineers to make decision about whether to improve or not, and to track the debt over time.
3) Candidates Creation: At this step, the team creates all the possible ways of synergy by instantiating the enriched self-awareness architectural pattern.In particular, they answer the questions presented in Section VII as follows: 1) Which category does the expertise representation belong to? -Answer: SLA belongs to the Documentation category but technical debt belongs to the Concept.2) If such a representation structural? is it tangible?-Answer: SLA is both structural and tangible while technical debt is neither structural nor tangible.
3) The expertise representation can be synergized with which algorithm/technique that realizes the selfaware capability?What are the possible levels of synergy?-Answer: SLA needs to be synergized with both self-aware capabilities in the Temporal Knowledge Aware Pattern, but information and expertise related to technical debt needs to be used with the time awareness only.The synergy between SLA and stimulus awareness needs to be at level 1, while for time awareness, it can be of any level (including level 0 ).Similarly, the technical debt can be synergized with time awareness at any level (including level 0 ).4) What is the possible form for each synergy?-Answer: All the synergies need to be realized in a general form.5) What is the difficulty level for each synergy?-Answer: According to Figure 6, the difficulty level ranges between very easy to challenging.The above answers produce 16 different candidates of synergizing domain expertise represented as the enriched Temporal Knowledge Aware Pattern.
4) Difficulty and Benefit Scores: For all the 16 candidates, their overall scores with respect to both the difficulty and benefit are shown in Figure 18.In this context, the w between specific and general form of synergy is set as 1.2 and 1.4, respectively.For each candidate, the proficiency is set as 1.8 for all synergies related to SLA and 1.5 for those related to technical debt.5) Further Investigation: Two candidates, as illustrated in Figure 19a, have been selected due to its superiority on the expected benefit over most other candidates, while causing an acceptable degree of difficulty.In a nutshell, they are discussed as follows: More technical details on the actual synergy approaches can be found in [24].
6) Further Investigation Setup: The candidates are evaluated using RUBiS (detailed in Table V) as the subject software system deployed and run in the real Cloud environment, with the negotiated SLA shown in Table IX.Two distinct machine learning algorithms are run in parallel, i.e., Naive Bayes [86] (NB) and Multilayer Perceptron [87] (MLP), each of which is of different complexities.The goal is to optimize the latency and power of the cloud-based software system, and thus both Multi-Objective Planner (MOP) and Single-Objective Planner (SOP), in which all objectives are combined in an equally weighted aggregation, are applied.The actual objective function to be optimized is trained based on machine learning [13,81,82].However, it is worth noting that optimization is not a concern of the designed software system that is self-aware, as it is not part of selected the pattern.The number of repeated runs is 100 for  the experiments, based on which the mean is reported.
The results are confirmed by Wilcoxon Signed Rank test (p <0.05), following the effect sizes categorization in [83].
Similar to the previous case study, the quality indicators used to assess both benefit and difficulty are shown in Table X.
7) Results: From Table XI, we see that for all cases, the C 1 under all algorithms outperforms the C 2 on both quality attributes, with statistical significance and nontrivial effect size on at least one attribute.In Figure 20, we also observe that C 1 has led to less debt, meaning that the monetary value generated by the software system, after synergizing the domain expertise with automatic machine reasoning, is higher than the case when the synergy is limited.We can also note that such benefit is achieved by using remarkably smaller amount and cost of adaptation.
To gain a better understanding about the total debt, we plot the debt throughout for an entire run.Figure 21a shows the cumulative distribution of debt for different levels of synergy, when using multi-objective planner.We can see clearly that, in contrast to others, C 1 with the two machine learning algorithms reduces the debt quicker as their slopes are much steeper than the C 2 .Yet, the superiority of C 2 on debt reduction is much more obvious when the debt is greater than about $9. Figure 21b compares the cumulative debt of approaches when using single-objective planner.Here, we see that C 1 is again significantly outperforms the case when there is no actual synergy, with faster reduction on the debt.
The difficulty in terms of LOC is shown in Table XII.As can be seen, C 1 requires higher LOC than C 2 , which implies higher difficulty in implementation and maintenance.This is predictable based on the benefit/difficult plot.However, we did not expected that the margin is as little as 3,672 lines, suggesting that the difficulty difference is in fact negligible given the much better benefits brought by C 1 .According to the verified results from the further investigation, C 1 is deemed as more suitable and thus it is chosen for production.

Final choice for the second case study:
C. Self-Awareness and Self-Adaptation for Rapidly Composed Software Systems Context: Service systems, unlike the others, do not have the actual implementation.Instead, they have a set of abstract services, each of which can be adapted to select different concrete services published in the Internet, according to a given workflow with different predefined connectors (sequential or parallel) [33,88,25,89].Such a process, namely service composition, is the key to enable rapid realization and integration of different functionalities that are required by the stakeholders.This is also a benefit of service systems, such that they share some similarities which make the exploitation of past problem instances and experiences possible.
Problem: In the third case study, the aim is to conduct multi-objective optimization for rapidly composing self-adaptive service systems at runtime, leveraging the benefits from the capabilities of self-awareness.

Challenge:
The challenge here is that there is often a large number of services to fulfil the same functional requirement, but come with different levels on some possibly conflicting non-functional Quality-of-Service (QoS) attributes, e.g., latency, throughput and cost.Thereby optimizing and finding the good service composition plans, i.e., a set of selected concrete services, and their tradeoffs becomes a complex and challenging problem which is known to be NP-hard [90,33].In addition, given the potentially rapid needs of composing the services, the optimization requires fast convergence to ensure the effectiveness of the optimized composition plan.
1) Patterns and Algorithms: Following the procedures from the handbook [8], it has been concluded that the requirements in this case study do not involve interaction awareness, because there is no way to know in advance what are the concrete services available, thus there is often a service broker that act as a centralized point to compose a service system.Further, the environment is not expected to react on the adaptation of the software system, hence no interaction between it and the environment.The metaself-awareness has been ruled out as the requirements on the required capabilities is clear, and no need to introduce extra overhead.goal-awareness is again essential in the optimization and time-awareness is also crucial for selfadaptive service systems, because the currently available concrete services, as well as their QoS values, could change over time, and thereby requiring a model that cope with such a change.As a result, these have led to the conclusion that the Temporal Goal Aware Pattern as the appropriate choice for the design.The pattern has been illustrated in Figure 3.
Given the NP-hard problem with an explosion of the search space and the nature of multi-objectivity for the self-adaptive services systems, the handbook [8] has suggested that the metaheuristic algorithms, particularly the evolutionary algorithms, are promising to realize the capability of goal-awareness in the software systems.Yet, given the high diversity of the workflow structures, it is expected that the solution does not tie to a specific evolutionary algorithm, rather, it should support a wide range of evolutionary algorithms.The time-awareness is supported by an analytical model, which tracks the available set of concrete services and their QoS values, and is capable of evaluating the aggregated QoS value for the workflow.The stimulusawareness can be realized by event driven detection, such that the stimulus is captured through passive detection.A complete list of the algorithms and techniques, with respect to the capabilities of self-awareness involved, are show in Table XIII.
2) Representations of Expertise: There are two fundamental representations of the expertise in this case: the workflow structure of the service composition and past problem instances/experience about the optimization when composing services.
As shown in Figure 22, where we can see that the workflow is represented as a graph and each vertex represents an abstract service.The edge denotes the connector TABLE XIII: The algorithms and techniques that realize the capabilities of self-awareness for the third case study.

Self-Awareness
Algorithms and Techniques stimulus awareness event driven detection time-awareness analytical model goal-awareness evolutionary algorithm Fig. 22: An example model of workflow structure for a service composition.
between vertices, e.g., they can be either sequential where the users' requests are proceed in strict order or parallel such that different users' requests are handled by simultaneously.
Another important representation of expertise is past problem instances and experience about the service composition.In the context of service composition, adaptation is required when change occur, e.g., the QoS of concrete services changes or some concrete services becomes unavailable.These changes, albeit can occur rapidly, often occur in relatively small extents.As a result, past problem instances and experience can still provide useful information for the scenario after changes occur.For example, changes on the QoS for a few concrete services may not affect the search and objective space significantly.Further, composition plans for service composition with similar workflow structure can also be rather useful.
3) Candidates Creation: At this step, the team considers all the candidates of synergy by instantiating the enriched self-awareness architectural pattern.In particular, they answer the questions as presented in Section VII as follows: 1) Which category does the expertise representation belong to? -Answer: Workflow structure belongs to the Model category but past problem instances/experience belongs to the Assumption.2) If such a representation structural? is it tangible?-Answer: Workflow structure is both structural and tangible while past problem instances/experience is neither structural nor tangible.
3) The expertise representation can be synergized with which algorithm/technique that realizes the selfaware capability?What are the possible levels of synergy?-Answer: The workflow structure needs to be synergized with both stimulus-and time-awareness at level 1 ; its synergy with goal-awareness is also required, but can be at any level except level 0.
The past problem instances/experience needs to be synergized with goal-awareness only, at all levels, including level 0. 4) What is the possible form for each synergy?-Answer: The workflow structure can be synergized with goal awareness in either specific or general form.All other synergies need to be realized in a general form.5) What is the difficulty level for each synergy?-Answer: According to Figure 6, the difficulty level ranges between very easy to challenging.The above answers produce 24 different candidates of synergizing domain expertise represented as the enriched Temporal Goal Aware Pattern.
4) Difficulty and Benefit Scores: For all the 24 candidates, their overall scores with respect to both the difficulty and benefit are shown in Figure 23.Here, the w between specific and general form of synergy is set as 1.3 and 1.5, respectively.For each candidate, the proficiency is set as 1.8 for all synergies related to workflow structure and 1.3 for those related to past problem instances/experience.
5) Further Investigation: After discussion with the team, two candidates, as shown in Figure 24a, are selected since they appear to achieve a relatively good balance between the likely difficulty and the expected benefit.In brief, each of them are discussed as follows:  realizes goal-awareness, supported by the time aware analytical model, without any additional information on the past problem instances and experiences.All the other synergies remain the same as those of C 1 .More technical details on the actual synergy approaches can be found in [26].

6) Further Investigation Setup:
The investigation is conducted by using the real-world WS-DREAM dataset [91], which contains QoS values for 4,500 services.Four distinct workflow structures of the software systems are randomly generated, each with 5, 10, 15 and 100 abstract services, respectively.As shown in Table XIV, the number of concrete services and their QoS values on latency, throughput and cost 9 are randomly selecting form the data set, resulting a range between 510 and 12,200 possible concrete services with a search space over one million.NSGA-II [79] and IBEA [80] are used as the underlying evolutionary algorithm for goal-awareness, which are set a mutation rate of 0.1 and a crossover rate of 0.9, with 100 population size for 50 generation (300 generations for the case of 100 abstract services).As mentioned, for time-awareness, standard analytical models for service compositions are used [90].All experiments were repeated 30 times and the mean values are reported.Again, the quality indicators used to assess both benefit and difficulty are shown in Table XVI.

7) Results:
From Table XV, clearly, C 1 leads to at least the same results for a quality objective when comparing to the case of C 2 .In particular, it has also resulted in better 9 The cost values are generated in a way that a concrete service with better latency would also have higher cost.Fig. 25: The changes of mean HV (y-axis) when using NSGA-II on all runs with respect to the number of evaluations (x-axis) under further investigated candidates.
Hypervolume (HV) value 10 [92].All the comparisons, except those equivalent ones, are statistically significant according to the Wilcoxon Signed Rank test (p <0.05), with non-trivial effect sizes.In particular, the improvement tends to be amplified as the number of abstract services increases, implying that the more complex the scenario, the better benefit that the domain expertise on past problem instances can offer when combined with the self-awareness.In Figure 25 and 26, we see that on all cases, C 1 achieves higher HV value than that of the C 2 throughout, meaning that it exhibits faster convergence.Again, the improvement is more obvious under more complex scenarios, e.g., when there are 100 abstract services.In Figure 27, the team examines how the behaviors of the software systems change when the underlying algorithm that realizes self-awareness is simplified.To this end, the crossover operator in NSGA-II is omitted, based on which the results can be compared to the cases when it is present for both approaches.Clearly, we see a considerable reduction on the HV values when the crossover operator is removed, suggesting that a simplified version of the underlying algorithm that realizes self-awareness may negatively affect the performance.Further, the more complex the service system, the greater the reduction.However, we  see that C 1 is more resilient than C 2 , which again proves that the domain expertise of past problem instance can be beneficial in guiding the algorithm that achieves selfawareness for even better results.
As shown in Table XVII, C 1 requires higher LOC than C 2 , which is as anticipated.Yet, their margin of difficult is remarkably small (635 lines) and hence it is wiser to choose C 1 for the actual deployment.
According to the verified results from the further investigation, the team has decided that C 1 can better fit the needs.

Final choice for the third case study:
IX. Discussion A. How DBASES can Help?
In summary, there are three aspects based on which DBASES can help to engineering synergy between domain expertise and self-awareness in a principled way, as it: • Encapsulates various notations and classification that helps to understand, analyze and reason about the information and knowledge that the engineers have for achieving self-awareness.• Visualizes the possible synergies, in a form of the enriched self-awareness architectural patterns, to provide intuitive understanding of the candidates.• Provides a methodology, building on the above tow points, that offers step-by-step guidance on how to engineering self-awareness with explicit consideration of domain expertise.It is worth noting that, although DBASES aims to help the engineers to finally select a single candidate of synergy, within the engineering process, it is by no mean that we restrict them to select only one nor to choose all of the possible candidates.In this respect, DBASES is similar to CBAM [42], which is a successful architecture selection methodology that also helps to reveal and quantify the cost, benefit and risk of design options in software development.CBAM also provides some visualisations similar to the way we do, but it is irrelevant to the explicit categories of domain expertise and their synergies to selfawareness.In fact, the precise description of which synergy candidate(s) chosen for implementation is irrelevant to the point of the framework and the message of this work.Our key point is that we have given the engineers a principled, repeatable method for making architectural choices of candidate(s), and understanding the consequences of these choices in terms of difficult and benefit, This method has been successful in that it guided the engineers to consider many ways of synergy that they would have otherwise overlooked, for two reasons: • Taking the difficult/benefit plot in Figure 10 as an example, some candidates have extremely high benefits scores whilst relatively easy to realize and hence bear some of the highest desirability.• Some candidates have relatively low benefit scores but are still quite difficult to realize, primarily due to low proficiency.Therefore, they can be ruled out from consideration.It is perfectly normal that more than one candidates are selected for further investigation and profiling, as what we have done in the tutorial case studies.But our framework provides such opportunity to intuitively localize which are the prefer ones and which candidates should be ruled out, thereby saving the valuable human effort in investigating them.

B. Threats to Applicability
When the number of possible candidate increase, the engineers are likely overwhelmed with identifying and discussing them all.However, the fact that there are many combinations is not uncommon when making architectural design decisions [41]; this is in fact a more general problem in Operational Research that how can one makes proper trade-off decision when there is a large number of alternatives.Visualisation and quantification seem to be a promising solution, which is what DBASES provides.In this way, a designer can have more intuitive information on the relative difficulty and benefits on the alternative, and thus making informed decision.
Of course, when the number of points are too many to conduct analysis visually, it is possible to improve DBASES by incorporating some forms of preferences so that only a particular region of points that is of interest can be focused.This is however subject to future work.

C. Threats to External Validity
It is known that methodological work is extremely difficult to be evaluated and ensure its generality.The reported case studies, as the name suggested, aim to replicate what would have happen when DBASES is used in a diverse scenarios, in which case it is likely that only some desirable ones can be selected for further investigation while ruling out the others which are of no interests.This is the reason why we have chosen a subset of the candidates in the experiments.Of course, it is indeed possible to evaluate all of the synergy candidate, but this would consume a large amount of time/resource, which we plan to investigate as part of future work.
Another threat is related to whether the industry practitioners will find that the DBASES is practical enough at a real-world industrial scale.Indeed, while this is important, it cannot be achieved without expensive surveying process, which will be extremely time-consuming.Therefore, we see this work as a first step to promote engineering synergy between domain expertise and self-awareness, and a more thorough evaluation with industrial stakeholders is part of our ongoing research.

X. Conclusion and Future Work
Architectural patterns and methodology for selfawareness have proven to be effective in guiding the systematic design, knowledge representation and reasoning for software systems that demand self-adaptation.However, when domain expertise needs to be synergized with the capabilities of self-awareness, current patterns and methods lack of guidelines about which domain expertise can be synergized, the extents of synergy and what are the trade-offs involved.
This paper is the first attempt that highlights the importance of synergizing domain expertise with the selfawareness in software systems, relying on well-defined underlying approaches.As part of the contributions, we present a holistic framework, dubbed DBASES, that offers a principled guideline for the engineers to perform difficulty and benefit analysis for synergizing domain expertise and self-awareness, Using three tutorial case studies from distinct domains, we describe how DBASES can help to assist in making design decision on the synergy of domain expertise with self-aware capabilities, particularly on selecting candidates for further investigation with quantitative profiling.
The notion of synergy in DBASES is a genuine attempt towards keeping domain experts and architects in the loop, a branch of a larger vision that relate to keeping "engineers-in-the-loop" for self-adaptive software systems, in which human (i.e., software and system engineers for our case) can control the behaviors of the underlying algorithms and techniques that realize the self-awareness at least to certain extents.This will consequently offer greater intuition and transparency into the awareness processes of the self-adaptive software system, improving its interpretable and explainable appeal.
Drawing on the foundation provided in this work, future research shall investigate how exactly the human can be placed into the loop with DBASES, considering the timeliness and reliability of the their expertise.Those problems will open up a full range of new research directions, drawing on the findings and proposals derived from this the work.This is one of our ongoing research investigation that is evolving into a specialized topic by its own for the discipline of engineering self-aware and self-adaptive software systems.

Fig. 4 :
Fig. 4: The guideline of selecting self-awareness architectural pattern and the underlying algorithms/techniques.

Fig. 5 :
Fig. 5: Confusion matrix on the taxonomy of the expertise representations with respect to structurability and tangibility.

Fig. 7 :
Fig. 7: The possible capabilities of self-awareness in the self-awareness architectural patterns with explicit synergy between domain expertise and self-awareness.

Fig. 8 :
Fig. 8: Instantiating Information Sharing Pattern with synergy between Petri net and self-awareness.

[level 1 ;Fig. 10 :
Fig. 10: Example of visualizing the difficulty and benefit scores for all candidates.

Fig. 12 :
Fig. 12: Difficulty and benefit scores for all candidates in the first case study.

C 3 Fig. 13 :
Fig. 13: Possible candidates selected for further investigation in the first case study.

Fig. 16 :
Fig. 16: Mean percentage of valid solutions found under further investigated candidates over all runs.

Fig. 18 :C 2 Fig. 19 :
Fig. 18: Difficulty and benefit scores for all candidates in the second case study.

Fig. 20 :Fig. 21 :
Fig. 20: The total debt, number and cost of adaptation under further investigated candidates over all runs.

Fig. 23 :
Fig. 23: Difficulty and benefit scores for all candidates in the third case study..

Fig. 26 : 2 Fig. 27 :
Fig.26:The changes of mean HV (y-axis) when using IBEA on all runs with respect to the number of evaluations (x-axis) under further investigated candidates.

Tao
Chen received his Ph.D. from the School of Computer Science, University of Birmingham, United Kingdom, in 2016.He is currently a Lecturer (assistant professor) in Computer Science at the Department of Computer Science, Loughborough University, United Kingdom.He has broad research interests on software engineering, including but not limited to performance engineering, self-adaptive software systems, search-based software engineering, data-driven software engineering and computational intelligence.As the lead author, his work has been published in internationally renowned journals and conference such as IEEE Transactions on Software Engineering, ACM Transactions on Software Engineering and Methodology, IEEE Transactions on Services Computing, ACM Computing Surveys and IEEE/ACM International Conference on Software Engineering.Among other roles, Dr. Chen regularly serves as a PC member for various conferences in his fields and is an associate editor for the Services Transactions on Internet of Things.He is a member of the IEEE.Rami Bahsoon received the Ph.D. degree in software engineering from University College London for his research on evaluating software architecture stability using real options and he attended London Business School for MBAlevel studies in technology strategy and dynamics.He is a Senior Lecturer of software engineering (associate professor) and leads the software engineering for/in the Cloud Interest Group, University of Birmingham, Birmingham, United Kingdom.The group's research aims at developing architecture and frameworks to support and reason about dependable complex software systems, where the investigations span cloud computing architectures and their economics.He published extensively in the area of economics driven software engineering, cloud software engineering, and utility computing and co-edited a book on Software Architecture and Software Quality and another on Economics-Driven Software Architecture (published by Elsevier).He is a member of the IEEE.Xin Yao (F'03) received the B.Sc. degree from the University of Science and Technology of China (USTC), Hefei, China, in 1982, the M.Sc.degree from the North China Institute of Computing Technologies, Beijing, China, in 1985, and the Ph.D. degree from USTC in 1990.He is a Chair Professor of Computer Science at the Southern University of Science and Technology (SUSTech), Shenzhen, China, and a part-time Professor of Computer Science at the University of Birmingham,Birmingham, United Kingdom.His current research interests include evolutionary computation, machine learning, and their real world applications, especially to software engineering.He was a recipient of the prestigious Royal Society Wolfson Research Merit Award in 2012, the IEEE Computational Intelligence Society (CIS) Evolutionary Computation Pioneer Award in 2013 and the IEEE Frank Rosenblatt Award in 2020.His work won the 2001 IEEE Donald G. Fink Prize Paper Award, the 2010, 2016, and 2017 IEEE Transactions on Evolutionary Computation Outstanding Paper Awards, the 2011 IEEE Transactions on Neural Networks Outstanding Paper Award, and many other best paper awards.He was the President of IEEE CIS from 2014 to 2015 and the Editor-in-Chief of IEEE Transactions on Evolutionary Computation from 2003 to 2008.He is an IEEE fellow since 2003 and was a Distinguished Lecturer of IEEE CIS.

TABLE II :
Classification of the Representations on Domain Expertise with Possible Examples.

TABLE III :
Possible Synergies between Expertise Representation and Self-Aware Capabilities.

TABLE IV :
The algorithms and techniques that realize the capabilities of self-awareness for the first case study.

TABLE V :
The real subject software systems for the experiments of the first case study.

TABLE VI :
The quality indicators for benefit and difficulty for the first case study

TABLE VII :
The LOC for the first case study

TABLE IX :
The cloud-based software system for the experiments of the second case study.
01): As shown in Figure19a, the candidate automatically converts the technical debt concept into structural and tangible knowledge, which can be synergized with timeawareness at level 2. The SLA has also been parsed to extracted meaningful information to consolidate understanding regarding time as level 2 of synergy.The stimulus-awareness, however, directly use the information from SLA without additional machine reasoning at level 1 of synergy.•C 2 (» C 2 = 11.235,½C 2 = 2.86): For the candidate in Figure 19b, the synergy of domain expertise on the SLA and technical debt concept with the timeawareness are realized at level 1.

TABLE X :
The quality indicators for benefit and difficulty for the second case study

TABLE XI :
Benefits in terms of latency and power, their statistical significance and effect sizes (ES) over all runs.

TABLE XII :
The LOC for the second case study

TABLE XIV :
The subject service-based systems for the experiments of the third case study.
* AS denotes abstract services; CS denotes concrete services; Env.denotes environment; Space denotes search space.

TABLE XV :
Benefits under further investigated candidates over all runs.

TABLE XVI :
The quality indicators for benefit and difficulty for the third case study

TABLE XVII :
The LOC for the second case study