Self-adaptive systems can be implemented as Dynamic Software Product Lines (DSPLs) via dynamically enabling or disabling features at runtime based on a feature model. However, the runtime (re)configuration may negatively impact the system's architectural qualities, exhibiting architectural bad smells. Such smells may appear in only very specific runtime conditions, and the combinatorial explosion of the number of configurations induced by features makes exhaustive analysis intractable. We are therefore targeting smell detection at runtime for one specific configuration determined through a MAPE-K loop. To support smell detection, we propose the Behavioral Map (BM) formalism to derive automatically key architectural characteristics from diferent sources (feature model, source code, and other deployment artifacts) and represent them in a graph. We provide identification guidelines based on the BM for four architectural smells and illustrate the approach on Smart Home Environment (SHE) DSPL.
uration’s architecture may be prone to other issues. It happens because the (re)configuration process combines Self-adaptive systems (SAS) operate in unpredictable, het- diferent architectural fragments or solutions via feature erogeneous environments, are prone to crashes and var- binding/unbinding at runtime. Thus, Architectural Bad ious other types of involuntary or required changes at Smells (ABS) may emerge, implying reductions in system runtime. Thus, such systems must adjust their struc- maintainability [4, 5]. Several authors [5, 6, 7] define ture or behavior, depending on environmental changes an ABS as a set of architectural design decisions that and (re)configuration plans to work in such environ- negatively impact system lifecycle properties, such as ments. Dynamic Software Product Line (DSPL) engi- understandability, testability, maintainability, extensibilneering implements SAS by dynamically binding or un- ity, and reusability. Also, it indicates possible design and binding features at runtime as prescribed by a feature implementation issues and helps improving the quality model [1]. A feature model represents commonalities of the system. and variabilities in a family of systems as well as rela- While ABS are well-studied for other type of systionships amongst features [2]. It thus describes which tems [4, 5, 6, 7, 8, 9], ABS in SAS are less explored [10, 11]. valid (re)configurations can be performed. DSPLs are To the best of our knowledge, the only studies targeting challenging to validate because the number of possible SAS search for ABS at design time: this may lead to smell configurations grows exponentially with the number of detection for invalid configurations (false positives) [ 10]. features, and this problem is worse if the DSPL can self- Additionally, some ABS may appear more frequently in a update (e.g., by downloading new features to interface specific configuration. Thus, we are interested in identifywith a sensor newly plugged into the system) [3]. ing ABS in SAS that may arise after the (re)configuration
Moreover, (re)configurations may also negatively af- process determined which configuration to deploy, alfect architectural qualities. Some specific feature inter- lowing to have access to all the necessary artifacts for a actions may not appear in the feature model (because more accurate smell identification. it does not capture data and control flows, only acces- In this paper, we introduce the Behavioral Map (BM) sible via source code analysis) or the resulting config- formalism: a directed graph capturing interactions deifned in the feature model but also capturing control and data flows interactions inferred from the candidate reconfiguration implementation. We describe the BM framework implementation and how to automatically build such a map from reconfiguration plans and actual code using static analysis techniques. We provide guidelines to identify four ABSs based on the inferred map. We exemplify our approach on SHE [12], a smart home DPSL. Our BM example and smell detection scripts are available on the companion website: https: //github.com/edilton-santos/BehavioralMapExample.
The remainder of the paper is as follows. Section 2 formally defines BM and presents the framework allowing them to build them automatically from a given DSPL.
Section 3 discusses the architectural bad smells identified through the BM and illustrates them on the Smart Home Environment (SHE) [12] case study. Section 4 presents the related work. Finally, Section 5 wraps up the paper.
between features (described in a feature model [2]) of a specific (re)configuration to be analyzed before it gets deployed [13]. Such configurations are produced within an adaptation loop. We rely on the well-known MAPE-K loop (Monitor, Analyze, Plan, and Execute over a shared Knowledge base) proposed by IBM in [14]. We depicted it left of Figure 1, though any type of control loop may interact with a BM. Thus, the BM needs to interact with the component responsible for defining the change plan used in the adaptation process at runtime and retrieving the configuration rules. We used the change plan selected by the self-adaptive system to create the map based on its configuration rules. Such a strategy was adopted because we assume that the system implements a MAPE-K loop [14] to manage the adaptation process at runtime according to the feature model. We thus avoid building a BM for an invalid configuration.
To build a BM, we follow the process described in Figure 1. The MAPE-K loop monitors continuously a set of managed resources and gathers the results in symptoms. Then the loop analyses symptoms and determines if an adaptation is necessary based on Knowledge (which in our case includes the DSPL feature model). If such an adaptation is necessary, it will issue a change request for the plan phase that will determine the appropriate configuration (a set of enabled and disabled features) to execute as prescribed by its change plan. The BM building process (right part of Figure 1) interacts with this change plan containing, besides the candidate configuration, a set of configuration rules noted CR. These rules contain information on the features and their dependencies (versions, imported and exported packages) obtained via extraction (see Section 2.3). The map building process comprises of Detection, Analysis and Map Building. In the following, we define the BM formalism and explain the BM building process.
control information about one configuration of the DSPL. Formally, a BM is a tuple:
= (, , , , , , , ), where: • is a configuration, i.e. a valuation of features
from the feature model, • ⊆ is a set of vertices, • = {Core, Controller, Sensor, Actuator, Presenter}, • : × ( ) ∖ ∅ is a function giving the types of a vertice. We suppose that a vertice/feature can have multiple types. For example, a feature can be core (i.e., present in all configurations) and also serves as a controller, • is a set of edges such as ∀ ∈ , = (, ′, ) where , ′ ∈ and ∈ = {Controls, Reads, Suppresses, Requires}, • is the set of all attributes, • : × {} is a function giving the value of all the attributes for a given vertice.
the right part of the figure 1. 2.2.1. Detection Detection determines interacting features using pairwise analysis [15] and their directed relationships based on the CR. Moreover, we assume that in the CR, there are all features and their configuration policy (including feature dependencies) used to answer a specific context at runtime. For example, the feature installation process used the constraints available in the manifest file used to describe the feature and its dependencies. Also, this process can use complementary information defined in the Change Plan. Such information is used to guide the installation, configuration, and adaptation process at runtime.
In this context, we will use the CR defined in the Change Plan to identify the features and directions of each relationship. Thus, the Detection process selects a feature in the CR and identifies its dependencies based on the configuration information of the feature. Let us consider a Feature A which requires to load a Feature B at runtime. This dependency is defined in the CR file and is used by the Detection process to create an arrow from feature A to feature B, indicating the direction of the relationship between the features. The process repeats for each feature until all interactions are detected and created on the map. 2.2.2. Analysis
During the analysis stage, we further refine the inter- map (createVerticesOnMap, line 2). The next step is actions identified during detection in categories. We to look for each created vertex (feature) and identify its identify several relationship types ( ) as relevant relationships in the Configuration Rules (table). Conseto highlight runtime interaction problems. The currently quently, we create three loops, as shown lines 3, 4, and supported types are: i) Controls: a relationship where a 6. The first loop selects a vertex on the map and then feature has control over another feature, but does not sup- looks for its information in the table using the second press its behavior; ii) Suppresses: a relationship where a loop. Line 5 checks for each row of the table whether feature suppresses the behavior of another one. Also, we it contains the selected vertex. Line 6 retrieves all relaconsider as suppressed the relationship between features tionships (row.getAllRelationships()) related to where one controlled feature needs to be uninstalled or the selected vertex on the map. For each relationship, unbound by its controlling feature; iii) Requires: a re- createEdge creates an edge in the map based on the lationship in which a feature is part of another feature’s following arguments: i) the vertex from which the edge implementation. In this relationship, there is no suppres- starts, ii) the relationship type represented by the edge, sion or control over the feature’s behavior that is part iii) the destination vertex (relation.featureName in of the main feature; iv) Reads: This type of relation- line 8). The loop on line 6 will repeats until and thus ship occurs when one feature reads data produced by edges are created. another feature, but there is no control or suppression of the feature’s behavior.
2.2.3. Map Building We conceived a framework to infer Behavioral Maps Based on interaction detection and analysis, we can build whose architecture is shown in Figure 2. The framework the BM for a configuration of the SAS. We represent this uses the Neo4J1 platform and its Cypher2 query language. map as a directed graph where features form the vertices The top-most layers, Map Builder, Analyzer, and Inand relationships form the edges. teraction Detector perform the processes defined in Section 2. In the following, we focus on the remaining elements of the framework. 1 table ← loadConfigurationRulesFile(CR); The Integration Layer (IL) serves as an interface be23 fvoerrteiacecshOvneMrteaxp i←n vecrrtiecaetsOeVneMratpicdeosOnMap(table); tween the DSPL and the map building components, re4 foreach row in table do ceiving the data used to build the map. Also, this layer 56 if rowf.noaremaec.heqruelaaltiso(nvienrtreoxw.n.gameteA)ltlhReenlationships() defines the CR file data type used to build the map as do follows: i) name is the feature name in the system; ii) 78 if relactiroena.rteelaEtdiognes(hviperitsexn,ot null then exported_packages lists the exported packages or serrelation.relationship_type, vices ofered via features; iii) imported_packages lists 9 end relation.featureName); the packages used by features to compose their func10 end tionality; iv) version represents the feature version; v) 11 end status defines if the feature is active or inactive; vi) type 1132 end end defines the feature type; vii) relationships is a collection composed of relationship types and associated feaAlgorithm 1: Behavioral Map algorithm. tures as describe as follows: a) relationship_type represents the relationship type, as defined in ; b)
The whole building process is summarized by Algo- feature_name is the feature name associated with the rithm 1. This algorithm begin from a table loaded by 1Neo4j - https://neo4j.com/product/ the loadConfigurationRulesFile procedure (line 1 2Cypher - https://neo4j.com/docs/cypher-manual/current/ at listing 1) and instantiates the vertices (features) on the introduction/ relationship_type field. The IL reads data via Data Ex- for assessing self-adaptive architecture as well as their tractor or CR file in formats XML, JSON, or CSV. level of support via the BM. For each of them, we briefly
The Data Extractor (DE) realizes the runtime integra- describe how they can be identified via the BM, and we tion between the Integration Layer and the Self-Adaptive provide a short discussion on their impact. Also, we system. The DE runs over the Plan function (see Figure provided a package in GitHub4 with a tutorial to do the 1), reading the Change Plan information at runtime and configuration of the Neo4J platform, two CR files, and relating the features and CR after the system triggers the scripts used to create the map and analyze the ABSs. the adaptation process. Hence, the DE identifies all features used and their relationships regarding the Change Table 1 Plan configuration to be deployed. Thereafter, the DE Selected Architectural Bad Smells for Self-Adaptive Systems. builds a CR file including all involved features and sends it to the Integration Layer. The DE component performs Smell Name Detection static analysis using the WALA API3. Static analysis al- Cyclic Dependency (CD) [16] Full lows to identify the dependency relationships among the Extraneous Connector (EC) [8] Full class hierarchy used by selected features or perform inter- Hub-Like Dependency (HL) [16, 10] Full procedural dataflow analysis and identify relationships’ Oppressed Monitors (OM)[11] Partial types. Also, manifest files, used to install each feature of the candidate configuration before its deployment, are exploitable. The DE component can be implemented for 3.2.1. Cyclic Dependency [16]: all types of adaptation processes because the data extract needs to receive as a parameter the features and their , the features implementation path in the packages, and Jar files. Also, we used these parameters to maps the relation between features and components that implements each feature.
Identification Guidelines. We determine cycles in the sub-graph of the BM formed by the features and the relationships of type Requires using a Depth-First traversal strategy.
Discussion. Based on relationship categories, other forms of cyclic dependencies that may be uncovered, such as control ones which may cause concurrent accesses to resources and/or deadlocks.
We applied our BM framework on SHE [12]: a smart home system that uses the MAPE-K loop to identify changes (such as a new sensor being plugged in) and make the appropriate changes to the dashboard (e.g., dis- 3.2.2. Extraneous Connector (EC) [8]: play data coming from that sensor). The SHE core is com- This smell happens when two connectors of diferent posed by Manager, Listener, Loader, Installer, and Presen- types are used to link a pair of components [8]. tation Layer. These layers are responsible for controlling Identification Guidelines. The automatic identifithe adaptation, communication, and data presentation cation of extraneous connectors proceeds by analyzing at runtime. Also, we included four optional features as paths between pairs of vertices in the BM. In a complefollows: i) Luminosity: used to read data from the lu- mentary way, a designer can visually identify EC smells minosity sensor; ii) Presence: used to read data from on the BM. The lampController (Figure 3) uses two types the presence sensor; iii) lampController: responsible of connectors to connect with the features Presence, Lumifor controlling Lamp feature’s behavior using the infor- nosity, and Lamp. The lampController uses the Listener mation read from Luminosity and Presence features; iv) (Publish-Subscribe client to implement the Reads edge) Lamp: an actuator used to switch on and of lights based and procedure call communication (represented by the on the lampController feature’s data. This configuration Requires edge) with Presence, Luminosity, and Lamp. of SHE is depicted Figure 3. Discussion. This smell increases the coupling between features of the DSPL, negatively impacting its 3.2. Identifying Architectural Bad Smells variability, and thus its adaptability [7]. However, a direct connection may be justified for concurrent operation While ABS catalogues exist in the literature [16, 8], their [8] and may increase the system’s resiliency in case of role in self-adaptive architectures is less known [10, 11]. failure of the publish-and-subscribe architecture. Table 1 presents a list of smells we believe to be relevant 3WALA - https://github.com/wala/WALA 4Behavioral Map example - https://github.com/edilton-santos/ BehavioralMapExample are controlled by the same controller, the map can help locating the features to look for this smell.
Discussion. In some cases, this smell is acceptable, especially when there are simple monitors with similar polling rates [11]. However, this smell limits the adaptability and resiliency of the system, which are important criteria for self-adaptive systems.
These examples illustrate the two complementary usages of the BM. First, the BM is a formal model amenable to automated detection of smells using graph algorithms.
Second, visual representations help designers and engineers to visualize runtime configurations.
outgoing) dependencies with a large number of other abstractions (e.g., other components) or concrete classes [16, 10].
Identification Guidelines. Thanks to its graph structure, the BM allows to automatically compute the in/outdegree (number of incoming or outgoing edges) for each vertex (feature). Features having high in/out-degrees are subjected to the HL smell. In Figure 3, we see that the Listener feature is subjected to the HL smell since it is involved in most of the Requires relationships of the BM.
Besides, if a feature has only many outgoing Requires edges, it is Hub type called Overreliant Class [16]. 4. Related Work
Discussion. The presence of the HL smell in the Listener feature is motivated by the publish-and-subscribe We found two works dedicated to the identification of architecture adopted by the SHE framework. The Listener ABS in self-adaptive systems. The first study [ 10] relies centralizes all the communication processes in this soft- on the Arcan [17] tool to identify ABS in 11 self-adaptive ware architecture and works as a communication broker. systems. Arcan creates a graph database with the strucIt is therefore acceptable in this case [16, 17]. However, ture of classes, packages, and dependencies of the anahubs form points of attention in case of failure. lyzed project, allowing the execution of algorithms on the graph to detect the ABS at design time. Our approach 3.2.4. Oppressed Monitors [11] (OM): also uses a graph for ABS detection, but there are two diferences: i) we create a map for each SAS configuraAccording to [11], this smell is characterized by a set of tion identified at runtime; and ii) we identify the ABS monitors (retrieving information from sensors) indepen- at the level of features defined in the system’s feature dent from each other that are managed with the same model. Thus, to analyze the architecture, we associate data polling rate and predefined execution order, yielding the features defined in the model with the structure of sub-optimal data acquisition and failure of subsequent classes, packages, and dependencies implemented in the monitors if one monitor in the sequence fails. source code. This process allows us to relate a feature to
Identification Guidelines. Fully identifying this its implementation. smell involves delving into the source code and getting The second study [11] presents two new ABSs specific information about polling rate since sequencing of sensor to self-adaptive systems: the Obscure Monitor and the calls is not present on the map. Yet, if several sensors Oppressed Monitors. Also, it defines the algorithms to identify each smell at design time. To validate the pro- exploratory study, in: Proceedings of the WICSA posed smells, the authors identified the proposed smells 2014 Companion Volume, 2014, pp. 1–6. in 8 SASs in the manual and discussed how to refactor [6] F. A. Fontana, P. Avgeriou, I. Pigazzini, R. Roveda, the system afected for those smells. We believe that our A study on architectural smells prediction, in: 2019 work on smells identification at runtime may uncover 45th Euromicro Conference on Software Engineernew ABS specific to SAS. ing and Advanced Applications (SEAA), IEEE, 2019, pp. 333–337. [7] J. Garcia, D. Popescu, G. Edwards, N. Medvidovic, 5. Concluding Remarks Toward a catalogue of architectural bad smells, in: International conference on the quality of software We defined behavioral maps ( BMs) to reason on architec- architectures, Springer, 2009, pp. 146–162. tural issues in self-adaptive systems. A BM is informed [8] J. Garcia, D. Popescu, G. Edwards, N. Medvidovic, by a feature model and by the considered configuration Identifying architectural bad smells, in: 13th Eubefore its runtime deployment. We implemented a flexi- ropean Conference on Software Maintenance and ble framework inferring BMs from heterogeneous infor- Reengineering, IEEE, 2009, pp. 255–258. mation sources, relying on static analysis to characterize [9] H. Mumtaz, P. Singh, K. Blincoe, A systematic interactions more finely than with a feature model. We mapping study on architectural smells detection, illustrated its application on a smart home dynamic soft- Journal of Systems and Software (2020). ware product line. As a work in progress paper, there [10] C. Raibulet, F. A. Fontana, S. Carettoni, A prelimis room for future work. First, we want to use the BM inary analysis of self-adaptive systems according to provide new smells specific to SAS architectures and to diferent issues, Software Quality Journal (2020) perform self-adaptive architecture assessments beyond 1–31. general ones [10]. Then, we envision other BM usages [11] M. A. Serikawa, A. d. S. Landi, B. R. Siqueira, R. S. such as test prioritization strategies, notably when new Costa, F. C. Ferrari, R. Menotti, V. V. De Camargo, features appear via hot-plugging mechanisms. Towards the characterization of monitor smells in adaptive systems, in: X Brazilian Symposium on Acknowledgments Software Components, Architectures and Reuse (SBCARS), IEEE, 2016, pp. 51–60.
Edilton Lima Dos Santos is funded by a CERUNA grant [12] E. Santos, I. Machado, Towards an architecture from the University of Namur. Sophie Fortz Sophie Fortz model for dynamic software product lines engineeris supported by the FNRS via a FRIA grant. Gilles Per- ing, in: IEEE International Conference on Informarouin is an FNRS Research Associate. tion Reuse and Integration (IRI), IEEE, 2018, pp. 31–38. [13] E. L. dos Santos, Stars: Software technology for References adaptable and reusable systems, in: Proceedings of the 25th International Systems and Software Prod[1] N. Bencomo, P. Sawyer, G. S. Blair, P. Grace, Dy- uct Line Conference (SPLC), ACM, 2021. namically adaptive systems are product lines too: [14] IBM, An architectural blueprint for autonomic comUsing model-driven techniques to capture dynamic puting, IBM White Paper 31 (2006) 1–6. variability of adaptive systems., in: SPLC (2), 2008, [15] L. R. Soares, J. Meinicke, S. Nadi, C. Kästner, E. S. pp. 23–32. de Almeida, Varxplorer: Lightweight process for dy[2] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, A. S. namic analysis of feature interactions, in: ProceedPeterson, Feature-oriented domain analysis (FODA) ings of the 12th International Workshop on Varifeasibility study, Technical Report, CMU-SEI, 1990. ability Modelling of Software-Intensive Systems, [3] N. Cardozo, I. Dusparic, Learning run-time com- 2018, pp. 59–66.
positions of interacting adaptations, in: Proceed- [16] U. Azadi, F. A. Fontana, D. Taibi, Architectural ings of the IEEE/ACM 15th International Sympo- smells detected by tools: a catalogue proposal, in: sium on Software Engineering for Adaptive and 2019 IEEE/ACM International Conference on TechSelf-Managing Systems, 2020, pp. 108–114. nical Debt (TechDebt), IEEE, 2019, pp. 88–97. [4] M. Lippert, S. Roock, Refactoring in large software [17] F. A. Fontana, I. Pigazzini, R. Roveda, M. Zanoni, Auprojects: performing complex restructurings suc- tomatic detection of instability architectural smells, cessfully, John Wiley & Sons, 2006. in: IEEE International Conference on Software [5] H. S. de Andrade, E. Almeida, I. Crnkovic, Archi- Maintenance and Evolution (ICSME), IEEE, 2016, tectural bad smells in software product lines: An pp. 433–437.