A Vision to identify Architectural Smells in Self-Adaptive Systems using Behavioral Maps Edilton Lima dos Santos1 , Sophie Fortz1 , Gilles Perrouin1 and Pierre-Yves Schobbens1 1 Faculty of Computer Science, University of Namur, Namur, Belgium Abstract 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 character- istics from different 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. Keywords Architectural Smells, Dynamic Software Product Lines, Runtime Validation, Self-adaptive Systems 1. Introduction 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- different 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, extensibil- neering 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 sys- tionships 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 identify- with 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, al- fect 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 de- fined in the feature model but also capturing control CASA’21: Context-aware, Autonomous and Smart Architecture and data flows interactions inferred from the candi- Workshop, September 13–17, 2021, Växjö, Sweden date reconfiguration implementation. We describe the " edilton.limados@unamur.be (E. L. d. Santos); sophie.fortz@unamur.be (S. Fortz); gilles.perrouin@unamur.be BM framework implementation and how to automati- (G. Perrouin); pierre-yves.schobbens@unamur.be (P. Schobbens) cally build such a map from reconfiguration plans and  0000-0003-2231-3852 (E. L. d. Santos); 0000-0001-9687-8587 actual code using static analysis techniques. We pro- (S. Fortz); 0000-0002-8431-0377 (G. Perrouin); 0000-0001-8677-4485 vide guidelines to identify four ABSs based on the in- (P. Schobbens) © 2021 Copyright for this paper by its authors. Use permitted under Creative ferred map. We exemplify our approach on SHE [12], a CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings (CEUR-WS.org) smart home DPSL. Our BM example and smell detection 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. Figure 1: Behavioral Map (BM) process overview. 2.1. Behavioral Map Definition A BM is a hybrid structure, mixing structure, data, and control information about one configuration of the DSPL. scripts are available on the companion website: https: Formally, a BM is a tuple: //github.com/edilton-santos/BehavioralMapExample. 𝐵𝑀 = (𝐶, 𝑉, 𝑉 𝑇 𝑦𝑝𝑒𝑠, 𝑣𝑡𝑦𝑝𝑒, 𝐸, 𝐸𝑇 𝑦𝑝𝑒𝑠, 𝐴, 𝑣𝑎𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒𝑠), The remainder of the paper is as follows. Section 2 where: formally defines BM and presents the framework allow- • 𝐶 is a configuration, i.e. a valuation of features ing them to build them automatically from a given DSPL. from the feature model, Section 3 discusses the architectural bad smells identified through the BM and illustrates them on the Smart Home • 𝑉 ⊆ 𝐶 is a set of vertices, Environment (SHE) [12] case study. Section 4 presents the related work. Finally, Section 5 wraps up the paper. • 𝑉 𝑇 𝑦𝑝𝑒𝑠 = {Core, Controller, Sensor, Actuator, Presenter}, • 𝑣𝑡𝑦𝑝𝑒 : 𝑉 × 𝒫(𝑉 𝑇 𝑦𝑝𝑒𝑠) ∖ ∅ is a function giv- 2. Behavioral Map ing the types of a vertice. We suppose that a vertice/feature can have multiple types. For ex- The role of a Behavioral Map is to capture interactions ample, a feature can be core (i.e., present in all between features (described in a feature model [2]) of a configurations) and also serves as a controller, specific (re)configuration to be analyzed before it gets • 𝐸 is a set of edges such as ∀𝑒 ∈ 𝐸, 𝑒 = deployed [13]. Such configurations are produced within (𝑣, 𝑣 ′ , 𝑟) where 𝑣, 𝑣 ′ ∈ 𝑉 and 𝑟 ∈ 𝐸𝑇 𝑦𝑝𝑒𝑠 = an adaptation loop. We rely on the well-known MAPE-K {Controls, Reads, Suppresses, Requires}, loop (Monitor, Analyze, Plan, and Execute over a shared Knowledge base) proposed by IBM in [14]. We depicted • 𝐴 is the set of all attributes, it left of Figure 1, though any type of control loop may interact with a BM. Thus, the BM needs to interact with • 𝑣𝑎𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒𝑠 : 𝑉 × 𝑃 {𝐴} is a function giving the the component responsible for defining the change plan value of all the attributes for a given vertice. used in the adaptation process at runtime and retrieving the configuration rules. We used the change plan selected 2.2. Behavioral Map Building Process by the self-adaptive system to create the map based on its configuration rules. Such a strategy was adopted be- In the remaining, we describe the BM process shown in cause we assume that the system implements a MAPE-K the right part of the figure 1. loop [14] to manage the adaptation process at runtime according to the feature model. We thus avoid building a 2.2.1. Detection BM for an invalid configuration. Detection determines interacting features using pairwise To build a BM, we follow the process described in Fig- analysis [15] and their directed relationships based on ure 1. The MAPE-K loop monitors continuously a set the CR. Moreover, we assume that in the CR, there are of managed resources and gathers the results in symp- all features and their configuration policy (including fea- toms. Then the loop analyses symptoms and determines ture dependencies) used to answer a specific context at if an adaptation is necessary based on Knowledge (which runtime. For example, the feature installation process in our case includes the DSPL feature model). If such used the constraints available in the manifest file used an adaptation is necessary, it will issue a change request to describe the feature and its dependencies. Also, this for the plan phase that will determine the appropriate process can use complementary information defined in configuration (a set of enabled and disabled features) to the Change Plan. Such information is used to guide the execute as prescribed by its change plan. The BM build- installation, configuration, and adaptation process at run- ing process (right part of Figure 1) interacts with this time. change plan containing, besides the candidate configura- In this context, we will use the CR defined in the tion, a set of configuration rules noted CR. These rules Change Plan to identify the features and directions of contain information on the features and their dependen- each relationship. Thus, the Detection process selects a cies (versions, imported and exported packages) obtained 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. Figure 2: Behavioral Map Architecture overview. 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). Conse- to 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 rela- consider 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.3. Framework Implementation 2.2.3. Map Building We conceived a framework to infer Behavioral Maps whose architecture is shown in Figure 2. The framework Based on interaction detection and analysis, we can build uses the Neo4J1 platform and its Cypher2 query language. the BM for a configuration of the SAS. We represent this The top-most layers, Map Builder, Analyzer, and In- map as a directed graph where features form the vertices teraction Detector perform the processes defined in and relationships form the edges. 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 be- 2 verticesOnMap ← createVerticesOnMap(table ); 3 foreach vertex in verticesOnMap do tween the DSPL and the map building components, re- 4 foreach row in table do ceiving the data used to build the map. Also, this layer if row.name.equals(vertex.name) then defines the CR file data type used to build the map as 5 6 foreach relation in row.getAllRelationships() do follows: i) name is the feature name in the system; ii) if relation.relationship is not null then lists the exported packages or ser- 7 8 createEdge(vertex, exported_packages relation.relationship_type, vices offered via features; iii) imported_packages lists relation.featureName); 9 end the packages used by features to compose their func- 10 end tionality; iv) version represents the feature version; v) 11 end status defines if the feature is active or inactive; vi) type end 12 13 end defines the feature type; vii) relationships is a collec- tion composed of relationship types and associated fea- Algorithm 1: Behavioral Map algorithm. tures as describe as follows: a) relationship_type rep- resents 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 1 Neo4j - https://neo4j.com/product/ the loadConfigurationRulesFile procedure (line 1 2 Cypher - 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 fea- tures 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 This smell occurs when two or more components depend 𝑉 𝑇 𝑦𝑝𝑒𝑠, the features implementation path in the pack- on each other directly or indirectly [16]. Components ages, and Jar files. Also, we used these parameters to involved in a dependency cycle can hardly be released, maps the relation between features and components that maintained, or reused in isolation [17]. 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 3. BM-Based ABS Detection traversal strategy. Discussion. Based on relationship categories, other 3.1. Case Study: The SHE Framework forms of cyclic dependencies that may be uncovered, such as control ones which may cause concurrent accesses to We applied our BM framework on SHE [12]: a smart resources and/or deadlocks. 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 different 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 identifi- the 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 comple- follows: 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, Lumi- for 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 off 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 be- tween features of the DSPL, negatively impacting its 3.2. Identifying Architectural Bad Smells variability, and thus its adaptability [7]. However, a di- rect 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 4 Behavioral Map example - https://github.com/edilton-santos/ 3 WALA - https://github.com/wala/WALA BehavioralMapExample Figure 3: Behavioral Map (BM) for one SHE configuration. 3.2.3. Hub-Like Dependency (HL): are controlled by the same controller, the map can help locating the features to look for this smell. This smell appears when a component has (incoming or Discussion. In some cases, this smell is acceptable, outgoing) dependencies with a large number of other especially when there are simple monitors with similar abstractions (e.g., other components) or concrete classes polling rates [11]. However, this smell limits the adapt- [16, 10]. ability and resiliency of the system, which are important Identification Guidelines. Thanks to its graph struc- criteria for self-adaptive systems. ture, the BM allows to automatically compute the in/out- These examples illustrate the two complementary us- degree (number of incoming or outgoing edges) for each ages of the BM. First, the BM is a formal model amenable vertex (feature). Features having high in/out-degrees are to automated detection of smells using graph algorithms. subjected to the HL smell. In Figure 3, we see that the Second, visual representations help designers and engi- Listener feature is subjected to the HL smell since it is neers to visualize runtime configurations. 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 Lis- tener 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 struc- It is therefore acceptable in this case [16, 17]. However, ture of classes, packages, and dependencies of the ana- hubs 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 differences: i) we create a map for each SAS configura- According 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 affected 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 Engineer- new 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 Eu- before 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 prelim- is 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 different 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 engineer- is supported by the FNRS via a FRIA grant. Gilles Per- ing, in: IEEE International Conference on Informa- rouin 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 com- Using 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: Proceed- Peterson, Feature-oriented domain analysis (FODA) ings of the 12th International Workshop on Vari- feasibility 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 Tech- Self-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, Au- projects: 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.