Volume 26, Issue 5 p. 567-589
Open Access

Component-based specification, design and verification of adaptive systems

Bence Graics

Corresponding Author

Bence Graics

Department of Measurement and Information Systems, Faculty of Electrical Engineering and Informatics, Budapest University of Technology and Economics, Budapest, Hungary


Bence Graics, Department of Measurement and Information Systems, Budapest University of Technology and Economics, Műegyetem rkp. 3., H-1111 Budapest, Hungary.

Email: [email protected]

Search for more papers by this author
Vince Molnár

Vince Molnár

Department of Measurement and Information Systems, Faculty of Electrical Engineering and Informatics, Budapest University of Technology and Economics, Budapest, Hungary

Search for more papers by this author
István Majzik

István Majzik

Department of Measurement and Information Systems, Faculty of Electrical Engineering and Informatics, Budapest University of Technology and Economics, Budapest, Hungary

Search for more papers by this author
First published: 06 April 2023


Control systems are typically tightly embedded into their environment to enable adaptation to environmental effects. As the complexity of such adaptive systems is rapidly increasing, there is a strong need for coherent tool-centric approaches to aid their systematic development. This paper proposes an end-to-end component-based specification, design and verification approach for adaptive systems based on the integration of a high-level scenario language (sequence chart variant) and an adaptation definition language (statechart extension) in the open source Gamma tool. The scenario language supports high-level constructs for specifying contracts and the adaptation definition language supports the flexible activation and deactivation of static contracts and managed elements (state-based components) based on internal changes (e.g., faults), environmental changes (e.g., varying context) or interactions. The approach supports linking managed elements to static contracts to formally verify their adherence to the specified behavior at design time using integrated model checkers. Implementation can be derived from the adaptation model automatically, which can be tested using automated test generation and verified at runtime by contract-based monitors.


Many modern applications, for example, control systems in the automotive, railway and aerospace industries, are embedded into their dynamic environment and must satisfy requirements that may specify behavior depending on internal or external changes. Changes are not under the control of the application as they may occur unpredictably and autonomously. Such occurrences, however, may affect the application's ability to accomplish its goals and thus, the application must adapt its behavior (and potentially structure) accordingly.

Developing such adaptive systems is oftentimes ad hoc and fractured due to the wide spectrum of application types, adaptation aspects, and dynamic changing of goals, which can result in multiple, hardly compatible system components, encumbering evaluation as well as maintenance and extension.1, 2 Accordingly, the systematic design and verification and validation (V&V) of adaptive systems can be particularly challenging, especially in safety-critical domains3 as traditional systems engineering methods, for example, document-centric systems engineering, do not provide convenient means for managing this increased complexity.4 For example, such methodologies may propose the specification of functional system requirements using an informal language, whose automated utilization in later development phases, for example, V&V, is not feasible.

In order to tackle these issues, model-based systems engineering (MBSE) and component-based systems engineering (CBSE)5-10 put the focus on the application of models and components, considering them the main artifacts that provide the primary means of information exchange during system development. These artifacts can be utilized to support platform-independent, high-level design, the automated derivation of implementations to multiple platforms and automatic V&V both at design time and runtime with the potential utilization of formal methods.11 However, there is a lack of cohesive tools as well as methodologies for building adaptive applications12 and the employment of formal methods for V&V, for example, model checking, remains low.11 Thus, engineers generally struggle with incompatible techniques and tools to specify requirements, design and implement the adaptation logic and managed elements (e.g., adaptable components) and verify and validate the resulting application using integrated tools.

Consequently, there is a need for coherent tool-centric MBSE and CBSE approaches to aid the systematic development of adaptive systems along the entire development process, including (i) requirement specification, (ii) the design of adaptation logic and elements managed by it, (iii) formal verification and testing of the resulting behavior and (iv) automated derivation of implementation with monitoring support. As a solution, we propose an approach in the context of our open source Gamma Statechart Composition Framework1,13 which is an integrated modeling toolset for the semantically well-founded modeling and analysis of state-based reactive systems.14

Our approach offers a scenario language to specify contracts for adaptive behavior in terms of interactions (input and output events) and sequence chart15 constructs, for example, alternative, parallel and loop fragments. It also offers a design language, called adaptation definition language, based on the well-known statechart formalism16 to design the adaptation logic. The language supports the definition of adaptive application behavior based on configurations of activated and deactivated state-based components (managed elements). Moreover, the activation and deactivation of scenario contracts can also be defined by linking them to component configurations that shall satisfy these contracts. The created adaptation model can be formally verified against contract specifications in our integrated design environment by mapping these models into the inputs of model checker tools. We also provide methods for deriving implementation (source code) for the designed system, as well as generating test cases that can check the conformance of the implementation on a specific platform to the contracts. Runtime verification is supported by including monitoring support in the derived implementation based on the synthesis of contract-based monitors.

This work builds on and extends our contract-based specification and black-box test generation approach for adaptive systems, presented in its initial version in literature.17 Nevertheless, this approach did not support adaptation logic design (the definition of application behavior in system states) and thus, either formal verification of adaptive behavior against contract specifications or implementation derivation supporting monitoring. In this work, we extend the original approach and provide solutions to these missing features.

Accordingly, this paper presents an end-to-end CBSE approach for adaptive systems development seamlessly integrated in our modeling tool, Gamma, based on the following main features.
  • 1. A scenario language for contract specification and a statechart-like adaptation definition language that allows the definition of behavior changes in an adaptation model (adaptation logic) based on state-based components (managed elements). As a result, an adaptation model can capture component activation and deactivation triggered by environmental events (e.g., changes in context or communication), internal events (including error signals), or time delay. In addition, contract activation and deactivation are also supported, allowing linking components to contracts that are active in the same system state. The language supports history between component or contract activations. Components can be defined as statecharts and both synchronous and asynchronous communication among the components are supported.
  • 2. A verification method based on the linking of components to contracts in the adaptation model that carries out exhaustive formal verification at design time using integrated model checkers to check whether adaptive behavior satisfies the functional requirements in the model under all circumstances. The method can carry out optimizations based on historyless links by disregarding modeling details irrelevant to the particular link to mitigate the state space traversal problem.
  • 3. A test generation method supporting the automated derivation of positive and negative tests from static contracts using model checkers. The method encodes implementation-specific details into annotations in abstract tests that are realized in concrete execution platforms, greatly reducing the number of concrete tests altogether.
  • 4. The automated generation of implementation using the code generators of the Gamma framework. The implementation supports monitoring based on component-contract links in the adaptation model to indicate contract violations in the adaptive system at runtime.
By offering these features, our approach aids the component-based development of adaptive systems in a unique and effective way based on
  • 1. precise and high-level modeling languages for the specification of functional requirements and functional design, including the design of adaptation logic and managed components;
  • 2. language-based support to link component configurations to the changing of functional requirements; and
  • 3. automated formal verification, source code generation, test generation and runtime monitoring functionalities based on functional models; all integrated into a single open source and extensible framework.

In the development standards of safety-critical systems, for example in IEC 61508:2010,18 dynamic reconfiguration in the software architecture is not recommended as it may complicate the achievement of predictability, verifiability and testability. Adopting a state-based approach to design the adaptation logic and managed components opens a way to design predictable adaptation. The use of precise modeling languages (including scenario-based representation of requirements) allows for complete formal verification and test generation with respect to well-defined test coverage criteria.

The rest of the paper is structured as follows. Section 2 presents the motivation and basic concepts of our work in the context of an example smart house themed adaptive system, and positions our approach among existing solutions (related work). Section 3 overviews our proposed CBSE approach for adaptive systems in our Gamma tool. Section 4 describes how adaptive behavior can be modeled in our approach based on the example system presented in Section 2. Section 5 presents the model transformations enabling the formal verification, test generation and code generation supporting monitoring for adaptive models in Gamma. Section 6 presents experiments with the smart house themed example model. Finally, Section 7 concludes the paper and outlines plans for future work.


This section presents the motivation and background of our work. Section 2.1 introduces a motivating example, namely an adaptive smart house system, as well as basic concepts of adaptivity, in the context of which later sections present our CBSE approach. Section 2.2 covers related work and positions our solution in the state of the art based on the identified gaps in terms of adaptive systems development.

2.1 Motivating example and basic concepts of adaptivity

The motivating example builds on an adaptive smart house system2 presented in literature19, 20 and extends it with additional components and adaptation behaviors. With this example, in addition to presenting our approach, we also aim to enrich the set of models available for evaluating solutions focusing on the development of adaptive systems.

The adaptive smart house system, whose thorough functional breakdown can be found in the Appendix, controls the ventilation in a room based on the number of present people. The system, as illustrated in Figure 1, comprises two sensors, a camera and a simple motion sensor (see Figures 3 and 4), responsible for detecting people, as well as two actuators (see Figures 5 and 6), a smart ventilator and a switch, for controlling the ventilation level in the room based on presence data – these are the components (managed elements) managed by the adaptation logic realized by a central controller (adaptation model – we will present it later in Figures 7 and 10 after introducing our adaptation definition language to make its adaptation-related features understandable). The adaptive nature of the system stems from the fact that these components can become unavailable (e.g., due to internal faults) or must be deactivated (e.g., due to external commands) to which the adaptation logic must react by component adaptation (reconfiguration), for example, activating the motion sensor after the failure of the camera (see an illustration in Figure 2), or the adaptation of parameters, for example, adjusting the frequency of communication between components based on presence data or energy consumption. Upon changing between component configurations, the requirements that the system must satisfy can also change, that is, the newly activated components may offer an extended functionality or can provide only a degraded system service, for example, in the case of the more complex camera and the simpler motion sensor components. History between the de- and reactivation of components may also have to be saved to support continuity after handling a certain external or internal event, for example, keeping the ventilation level in the room the same after handling a fault.

Details are in the caption following the image
Block diagram depicting the components of the adaptive smart house system.
Details are in the caption following the image
Illustration of a component reconfiguration in the adaptive smart house system triggered by the failure of the camera component.
Details are in the caption following the image
Camera component (sensor) in the adaptive smart house system.
Details are in the caption following the image
Motion sensor component (sensor) in the adaptive smart house system.
Details are in the caption following the image
Smart ventilator component (actuator) in the adaptive smart house system.
Details are in the caption following the image
Switch component (actuator) in the adaptive smart house system.
Details are in the caption following the image
Excerpt of the adaptation model (focusing on sensor handling) of the adaptive smart house system, in which operational states are linked with component configurations and scenario contracts.
Details are in the caption following the image
Model transformation chains and modeling languages of our CBSE approach for adaptive systems in the Gamma framework. CBSE, component-based systems engineering.
Details are in the caption following the image
Scenarios for the camera component and the whole adaptive smart house system, demonstrating the features of GSCL. GSCL, Gamma Scenario Language.
Details are in the caption following the image
Central controller (adaptation model) of the adaptive smart house system.

Regarding the detailed functionalities of the sensors, the motion sensor can detect only the moving of people in the room, whereas the camera can also identify the number of present people with image processing techniques, which can be used to adjust the ventilation level accordingly. The system wants to minimize internal event transmission between components to minimize power consumption by frequent communication and changes of ventilation level. Thus, the camera has an adjustable granularity parameter (variable) that sets the difference in the number of detected people that, compared to the last update, results in an update towards the actuators. The camera also has a battery that is drained when people are detected and can be recharged in an idle state. As a special feature, the motion sensor can count incoming motion events in a specified time interval and detect unexpected situations (i.e., too many events in a time interval), such as failures in the underlying hardware components or potentially malicious behaviors.

Regarding actuators, the switch can only turn off and on the ventilation at a predefined (default) level, whereas the ventilator can also adaptively set the ventilation level based on the number of present people (data received from the camera) and the time elapsed since the last received data (data becomes obsolete after a while).

As demonstrated in the description of the example system, there are special concepts for adaptation, which must be addressed during the functional breakdown of the system (requirement specification), as well as system design to ensure its correct functioning in case of different events. Accordingly, we explain the following concepts in detail, which are prevalent in the design of adaptive systems both in our approach and in the state of the art21: adaptation logic, component adaptation, parametric adaptation, changing of requirements and history.

2.1.1 Adaptation logic

Conceptually, the adaptation logic of an adaptive system is responsible for managing the system that comprises different managed elements to fulfill certain adaptation goals. The management is based on external and internal data acquired from the environment as well as the managed elements, and is generally realized in a separate entity implementing a feedback loop. In our approach, the adaptation logic is not divided explicitly into adaptation goals and a feedback loop. Instead, it can be defined in a single state-based model (see details in Section 3.1) that describes how the system reacts to external or internal events considering adaptation and system-level goals (see central controller in the example system description). Moreover, managed elements are modeled as state-based components and thus, we refer to them as managed components in the rest of the paper.

2.1.2 Component adaptation

Component adaptation allows for modifying the component configuration of the system, that is, components can be added, removed, or replaced by the adaptation logic in order to adapt the functionality of the application – we refer to this procedure as component reconfiguration in the rest of the paper (see the activation of the motion sensor after the failure of the camera in our example, illustrated in Figure 2). Our approach supports components with an event-driven behavior modeled using statecharts.

2.1.3 Parametric adaptation 

Parametric adaptation allows for the fine tuning of system behavior by changing the values of component parameters or variables (excluding potential structural parameters) and also supports inter-component communication between the adaptation logic and managed components. Our approach supports parametric adaptation based on shared variables and variable assignments controlled by the adaptation logic (see the adjustable granularity parameter of the camera in our example).

2.1.4 Changing of requirements

Requirements that the adaptive system must satisfy may change depending on external or internal events, which must be considered and tended to by the adaptation logic, for example, by component or parametric adaptation. For example, after a component failure, the system may enter a degraded functioning mode where a limited set of requirements must be satisfied; see the difference between the required functionalities of the ventilator and switch components in our example. Our approach supports the specification of functional requirements in the form of scenario contracts (sequences of expected interactions) that can be virtually activated and deactivated by external or internal events. Scenarios can be linked to and shall be satisfied by either the adaptation logic or component configurations.

2.1.5 History

During component reconfiguration, the state of the deactivated components and the linked contracts may have to be kept, and then, restored upon their next activation (component and contract history), for example, to handle interruptions during a continuous process. In our example, this adaptation concepts can be useful when the ventilator gets deactivated, and we want to ensure the same level of ventilation upon its reactivation.

2.2 Related work and gaps in the development of adaptive system

Many different aspects of adaptive systems development have been researched in the past22, 23 due to the wide spectrum of application types. Accordingly, many design solutions, for example, goal-based,24-26 rule-based,27 actor-based,28 service-based29 and model-based,30 as well as V&V solutions, for example, (runtime and probabilistic) formal verification,31-34 theorem proving27 and monitor-based runtime verification,35 have been presented. This section overviews adaptive systems development solutions related to ours that support (i) a MBSE/CBSE approach and (ii) the design time V&V of functional behavior as we consider these aspects the most relevant in our solution. The section also analyzes and emphasizes the functional gaps and potential needs in the development of adaptive systems that are poorly addressed by the state of the art.

The MUSIC framework36 proposes a software development methodology for self-adaptive applications based on the model-driven architecture (MDA) paradigm together with an integrated toolset supporting platform-independent modeling of application variability (e.g., compositional and parametric adaptation), context dependencies in a variability model and the heterogeneous service and context information in a domain model, as well as deriving implementation, validation and testing. The variability and domain models are transformed into code executable by the middleware to plan the adaptation. Nevertheless, MUSIC does not support developing application components (managed elements) as in the framework, they do not play an active role in the adaptation: component development is considered an orthogonal, well-understood issue37, 38 and as such, outside of the framework's scope. Accordingly, the framework does not allow the integral design of adaptation logic and component reconfiguration. MUSIC does not support expressing the changing of requirements and formal verification of adaptive behavior either.

In literature,20 authors describe a methodology for specifying and verifying adaptive systems based on the communicating sequential processes (CSP) formalism39 building on concepts laid down in literature,19, 40, 41 such as mapping model-based compositional designs into formal intermediate representations and using integrated model checkers. The approach supports the development of adaptive system through refinement chains of models with formally established relations among them that separate adaptation logic from functional behavior. In addition, adaptive CSP models can be exhaustively verified using process-algebraic mechanisms, as well as LTL model checking. The authors also present how adaptive CSP models can be used to derive implementations realizing the specified behavior; however, the derivation process is not fully automated. The main limiting factor in their methodology is that they do not support the description of adaptive behavior based on high-level requirement specification and state-based models, greatly hindering its application by systems engineers.

Authors in literature42 present a component-based modeling and verification method, integrated into the CompoSE framework, for adaptive embedded systems. The method builds on the foundations of nonhierarchical modeling concepts and analysis techniques for adaptation behavior, previously presented in literature.43, 44 The modeling approach supports grouping a composition of components together into a hierarchical component in which the set of possible compositional configurations is abstracted to a smaller set of hierarchical configurations. These configurations represent reasonable operational modes, reducing design complexity at each hierarchy level. In order to ensure the correctness of components, a formal model of computation is provided, allowing the automated formal verification of critical requirements using model checking based on CTL and LTL properties. A limitation of this solution in regard to an end-to-end systems development approach is that they focus on abstracting the compositional adaptation behavior of a large composition of components into a hierarchical model and not on capturing and verifying component behaviors with respect to changing requirement specifications.

In literature,45 authors propose a MBSE process for developing dynamically adaptive programs, focusing on formal behavioral modeling. The approach separates the model specifying the nonadaptive behavior from the one specifying the adaptive behavior, and uses global invariants to specify properties that should be satisfied by adaptive programs; such properties are checked using model checking. The modeling approach supports adaptation in the form of state transfers, transforming the source program (the program before adaptation) into the target program (the resulting program). The approach can be applied to several state-based modeling languages, including process algebras, Petri nets, UML state diagrams and model-based languages like Z, and supports the automated generation of executable prototypes. In summary, the approach addresses several concepts necessary for the development of adaptive systems; nevertheless, it does not consider the high-level specification and potential changing of requirements, and their conformance checking against the defined adaptive behavior.

Authors in literature46 present a generic end-to-end MBSE methodology called ENTRUST for the engineering of trustworthy self-adaptive software systems and the dynamic generation of their assurance cases, that is, reports supporting specific claims about the system requirements. As a key aspect, the methodology disregards the modeling and verification of the controlled software system and focuses on its enhancement with self-adaptation capabilities via the addition of a high-level monitor-analyze-plan-execute (MAPE) control loop. The paper also overviews a tool-supported instance of the methodology, which includes methods for modeling such verifiable controllers for self-adaptive systems in addition to their simulation and formal verification based on UPPAAL and PRISM,47 both at design time and runtime. Even though the methodology offers a set of powerful functionalities, it does not support the modeling and V&V of the controlled system (managed components) from a component-based perspective using high-level modeling languages.

As demonstrated, the development of adaptive systems using MBSE/CBSE approaches, as well as design time V&V is a well investigated area with various powerful solutions. However, to the best of our knowledge, there is no single solution that proposes an end-to-end tool-centric CBSE methodology for developing adaptive systems based on high-level modeling languages that address the concepts of adaptation presented in Section 2, and automated V&V techniques. Accordingly, we offer a single open source framework in which all of the following functionalities are integrated seamlessly:
  • 1. thespecification of functional behavior (scenario contracts) using a high-level scenario language,
  • 2. the design of both component behavior, as well as the adaptation logic (component reconfiguration) linked to the changing of requirements (scenario contracts) based on high-level statechart languages,
  • 3. the formal exhaustive verification of the emergent system behavior with respect to manually defined system properties (like invariants), as well as scenario contracts,
  • 4. the synthesis of source code potentially to multiple execution environments,
  • 5. the generation of tests (positive and negative tests) based on scenario contracts, and
  • 6. monitor-based runtime verification.


This section presents our CBSE approach for adaptive systems. First, Section 3.1 overviews how our solution addresses the general concepts of adaptivity presented in Section 2. Next, Section 3.2 introduces the modeling languages supporting the approach, which is followed by the description of the design and internal transformation steps necessary from the designer (user) and the Gamma tool in the development workflow (see Section 3.3).

3.1 Proposed modeling strategy

In Section 2.1, we argued that the presented concepts of adaptivity must be addressed in a solution that aims to support the flexible and V&V-oriented design of adaptive systems. Accordingly, we describe how our approach addresses the above concepts with different modeling facilities. The relations and linking of these modeling facilities are demonstrated in a conceptual diagram in Figure 7 (explained in the sequel).

3.1.1 Adaptation logic

In our approach, the adaptation logic is captured in a statechart model, called adaptation model, which serves as the central controller of adaptivity (component and requirement management) in the system (see the middle statechart in Figure 7). The adaptation model can be built using high-level statechart constructs, such as ports, hierarchical states, parallel regions, variables and complex transitions. Essentially, states in the adaptation model represent adaptation-related operational modes; transitions between them can be triggered by internal and external events. Consequently, the adaptation logic is captured in a direct and verifiable way (compared to, e.g., declarative, rule-based solutions), providing a significant advantage in the case of critical systems in particular. As a special feature, adaptation models can contain additional adaptation models, supporting the hierarchical decomposition of central control. Altogether, the adaptation model can be regarded as the general representation of an adaptation mechanism that does not constrain the implementation and enables the verification of the adaptation logic (see Section 5.2).

3.1.2 Component adaptation

Component adaptation is captured by linking components to states in the adaptation model (see Camera and MotionSensor components in callouts in Figure 7) to define component configurations, that is, sets of components that are active in the same state of the adaptation model. Statechart components can be defined in Gamma's statechart language (see Section 4.3).

3.1.3 Parametric adaptation

Parametric adaptation is facilitated by port bindings and variable bindings that connect the ports and variables of managed components to the ports and variables of the adaptation model as well as other managed components. The port bindings and variable bindings are automatically handled (i.e., their endpoints are changed) according to the activated and deactivated components and allow for the bidirectional transmission of events and variable assignments to support the transmission of control events from the adaptation model to managed components, feedback events from managed components to the adaptation model and communication between managed components.

3.1.4 Changing of requirements

Similarly to component management, requirement changes can be described by linking scenario contracts to the (potentially composite) states of the adaptation model (see textual scenario snippets in callouts in Figure 7). Contracts can be linked to the adaptation model directly (as behavior specifications for the adaptation logic) or component configurations, that is, components that must be active in the same state as the contract (see Section 4.2).

The reason our approach supports linking component and contract configurations to states instead of modeling separate actions for their activation and deactivation, for example, on transitions of the adaptation model, stems from verification goals: this way, implicit links can be created between components (behavior realizations) and the contracts they must satisfy (behavior specifications), which can be used for the exhaustive formal verification of functional properties (see Section 5.3.1). Note that the example adaptation model in Figure 7 comprises a composite state containing two state simple states; a single statechart component is linked to each simple state, a scenario contract is linked to the composite state (also applied for the contained simple states), and two and one scenarios are linked to the simple states. Thus, five implicit component-contract links can be created: three in state UseCamera and two in state UseMotionSensor.

3.1.5 History

In addition to historyless reconfiguration, our approach supports both shallow history, that is, history only for the topmost regions in statechart components, and deep history, that is, history for all nested regions, during component and contract reconfiguration. In both cases, history considers internal variables. Shallow or deep history are not distinguished in the case of contracts as each contract represents scenarios of events without multiple levels of refinement.

3.2 Supporting modeling languages

The concepts of adaptivity presented in Section 3.1, as well as the services provided by our CBSE approach presented in Section 3.3 are supported by the following modeling languages:
  • 1. The Gamma Scenario Language (GSCL) is a configurable variation of the LSC15 (Live Sequence Chart) formalism supporting the high-level description of system behavior in terms of input and output events (interactions).
  • 2. The Gamma Statechart Language (GSL) is a configurable UML/SysML-inspired formal statechart16 language supporting different semantic variants of statecharts, for example, synchronous and asynchronous.48
  • 3. The Gamma Composition Language (GCL) is a composition language for the formal hierarchical composition of state-based components according to multiple execution and interaction semantics, that is, cascade and scheduled asynchronous, based on the binding of communication ports and their connection with channels.14
  • 4. The Gamma Adaptive Statechart Language (GASL)3 is a GSL extension that supports the definition of scenario contract as well as managed component activation and deactivation, allowing the definition of a state-based adaptation logic and thus, is also referred to as adaptation definition language.
  • 5. The Gamma Trace Language (GTL) is a high-level trace language for reactive systems, supporting the specification of execution traces, that is, reached state configurations, variable values and output events in response to input events, time lapse and scheduling from the environment, interpretable as abstract tests.

3.3 Supporting development workflow

Our CBSE workflow (depicted in Figure 8) comprises two parts. The first part (Step 1 to Step 3) includes the design of functional models capturing the adaptive behavior, that is, the specification of requirements as scenario contracts and the definition of the adaptation model, as well as the managed components. The second part (Step 4 to Step 8) comprises the model transformations of these models to support different V&V, code and test generation functionalities.

In Step 1 (see Section 4.1) of the approach, the user can specify contracts for the system in the form of GSCL scenarios. The language supports variables and high-level constructs to model system behavior, for example, alternative, optional, parallel and loop fragments, and configuration options for test generation, for example, allowed latency for expected output events. The language also supports references to other parameterized scenario descriptions (scenario reuse) and constraints to limit expected variable values.

Next, in Step 2 (see Section 4.2), the user can construct a state-based adaptation model, in which operational modes of the system – characterized by different contracts – are represented by states, and state changes are triggered by external or internal events. Adaptivity is introduced to the static contract descriptions by linking them to states, and thus their activation and deactivation may occur upon the change of states in the adaptation model. The language supports high-level constructs available in regular statecharts, such as hierarchical states and parallel regions (enabling the flexible combination of contracts), history, as well as complex transitions.

In Step 3 (see Section 4.3), the user can extend the adaptation model with the activation and deactivation of managed components that compose the configuration of the system in different states of the adaptation model and shall conform to the contract specifications linked to these states. The components are represented by statechart models defined in GSL. Due to the characteristics of GASL, the links between contracts and components (serving as a basis for formal verification in Step 5) can be established automatically based on the adaptation model.

Step 3 concludes the steps of requirement specification and the design of adaptivity (including adaptation logic and managed component behavior) from the user's point of view. The next steps include the automated internal transformations via which the framework supports formal verification, test generation and the derivation of implementation with monitoring support. These model transformations can be configured by the user with configuration files, for example, which model checker to use for formal verification or test generation.

In Step 4 (see Section 5.1), the contract scenarios are automatically mapped into automata modeled in GSL where execution paths represent the interaction sequences of scenarios. As these automata are modeled as regular Gamma statecharts, all Gamma functionalities can be applied to them, supporting the specification and verification of contracts in different contexts, for example, by carrying out model checking or deriving tests or runtime monitor implementations.

In Step 5 (see Section 5.3.1), the adaptation model along with the linked component and scenario descriptions with integration steps in GCL (Section 5.2) are transformed into input languages of integrated model checkers (currently UPPAAL,49 Theta50 and SPIN51 are supported) to allow the (i) formal verification of the adaptation logic and the individual components against state reachability and temporal (e.g., safety or liveness) properties, (ii) the formal verification of the joint adaptive behavior against contract descriptions, and (iii) test generation (see Step 7). For test generation, formal reachability properties that control the traversal of the adaptation model are also generated depending on the selected (configurable) coverage criteria, for example, state, transition, out-event or interaction coverage.

In Step 6 (see Section 5.3.2), implementation supporting monitoring is derived based on the integrated adaptation model comprising the linked component and scenario descriptions using Gamma's code generators. As a result, monitor implementations are integrated to the component implementations and can indicate the violation of a contract at runtime. Currently, the generation of Java code is supported.

In Step 7 (see Section 5.3.3), abstract test cases are derived using model checking, which computes paths in the adaptation model to the activation of certain scenario contracts based on the generated reachability properties (see Step 5). These contracts are then interpreted further using additional model checking runs to derive test inputs, delays and expected outputs in that adaptive state (derivation of positive and negative tests). Abstract test cases are formed as the sequential combination of the steps returned by the two model checker runs.

As a last step (see Section 5.3.3), abstract test cases are customized to concrete execution environments, that is, they are mapped into sequences of concrete calls to provide test inputs, schedule system execution, and then retrieve and evaluate outputs. Currently, JUnit4 is supported as a concrete execution environment.


This section presents the modeling languages of our approach for modeling functional behaviors of adaptive systems in the context of the example smart house system presented in Section 2.1. The section features static scenario contracts (see Section 4.1) that can be made adaptive in a state-based adaptation model (Section 4.2), as well as state-based components (see Section 4.3) that can realize behaviors to conform to the contract specifications in different adaptation states.

4.1 Specifying scenario contracts

Scenarios can be defined in GSCL, which is a Live Sequence Chart (LSC)15 variant building on formal semantics with restrictions and extensions to support test generation. Such scenarios can describe mandatory, forbidden and possible executions of reactive systems in terms of interactions. The constructs of the language are demonstrated in Figure 9 with scenario examples that specify interaction sequences for the camera component and the whole adaptive smart house system. For a more thorough description of the language, we direct the reader to literature.52, 53
  • 1. DelayThenMotion specifies that after a certain time (specified by the TIMEOUT_TIME constant) if the camera receives a motion event via its Camera port, it has to transmit it via its Motion port (towards the actuators).
  • 2. MotionThenMotion specifies that after the camera receives a motion event via its Camera port, and then receives another one in a specified time interval (timeoutTime parameter), it must not transmit it via its Motion port (to save battery).
  • 3. MotionThenDelayThenMotion specifies that after the system (specified from the central controller's point of view) receives a motion event either via its Camera or MotionSensor port, and then receives another one after a specified time (TIMEOUT_TIME constant), it has to adjust the ventilation level (Ventilation port) to a specified value (BASE_VENTILATION constant).

As shown in Figure 9, GSCL scenarios support the specification of interactions for a single lifeline (a component, see Lines 5, 14 and 22) communicating with its environment. Interactions are defined in a sequential order, representing behaviors in consecutive execution cycles. Atomic interactions are events received (Line 11) or sent (Line 12) via a specific port. Hot and cold modalities distinguish between mandatory (hot) and optional (cold) atomic interactions. In order to support synchronous processing of batches of events (i.e., in execution cycles), GSCL supports interaction sets, consisting of atomic interactions that need to occur at the same time/cycle (Lines 28–32). In an interaction set, the direction and modality of the contained interactions must be the same. Atomic interactions and interaction sets can be negated to specify the absence of interactions (Line 19). In addition, parameters (Line 15) and variables can be declared (Line 24) for scenarios. Moreover, the language supports time delays with a lower and potentially a higher bound (Lines 10 and 17), check expressions (Line 30) to specify additional constraints for interactions (parameter and variable values) and assign statements (Line 32) to assign values to variables. Note that these constructs must be used in conjunction with atomic interactions (directly or indirectly) in an interaction set. GSCL also supports scenario calls to reuse interaction sequences defined in other scenarios (Line 25).

GSCL supports optional, alternative, unordered, parallel and loop fragments (composite interactions) to describe complex behavior. Each combined fragment type contains one or more interactions as operands. An optional fragment describes an interaction that may or may not occur. An alternative fragment describes a set of interactions out of which exactly one must occur (Lines 35–39). An unordered fragment describes a set of atomically handled (potentially composite) interactions that can occur in an arbitrary order. A parallel fragment describes a set of non-atomically handled interactions that can occur in parallel, that is, interleaving between the interactions can occur. A loop fragment describes the iteration of an interaction based on a minimum and a maximum bound that can be infinite.

Based on a GSCL scenario, an observed interaction sequence is (i)inconclusive if an interaction violates (i.e., does not match) a cold interaction specification or does not cover the entire scenario; (ii)invalid if an interaction violates a hot interaction specification, meaning that it contradicts the expected behavior; (iii)valid if it is neither inconclusive nor invalid.

GSCL supports test generation with configuration options for (1) specifying constraints for system response and (2) categorizing unspecified system behavior.

Option 1 handles the issue of not knowing the exact latency between inputs and reactions in an implementation. For example, Lines 11 and 12 specify that the system must respond to an incoming motion event with a motion event on the respective output port. Depending on the implementation, this may take several execution cycles. Therefore, GSCL introduces an annotation (Line 8) that specifies the accepted range of latency in terms of execution cycles. If the response does not arrive within the specified interval, a violation occurs. Note that this kind of uncertainty does not apply to events received by the system, because they do not depend on the system implementation.

Option 2 allows the different interpretation of unspecified events sent by the system during test execution. As explained above, after receiving a motion event (Line 11) the system may have “time” to respond, during which it may send unspecified events, too. GSCL offers annotations (Line 7) to decide whether this behavior is permitted (permissive mode) by ignoring that event or treated as a violation of the interaction expecting the response (strict mode).

4.2 Designing the adaptation model linked with changing scenario contracts

As detailed in Section 2.1 (see changing of requirements), the functional requirements that adaptive systems must satisfy may change depending on external or internal events, for example, the failure of a component or an external command prescribing the reconfiguration of components to better handle a certain need. Therefore, a modeling language is required to support the description of adaptivity with respect to scenario contracts.

GASL is a statechart language16 extension to support the definition of adaptive contracts, that is, the activation and deactivation of static scenario contracts upon specific events. It builds on GSL, the built-in formal statechart language of Gamma,48 and supports powerful constructs, such as composite states, parallel regions, history states, variables, and complex transitions, such as merge, choice, fork and join. It also supports semantic variation points, for example, synchronous or asynchronous communication, conflict resolution between transitions of different hierarchy (region) levels, priorities between transitions with the same source or the execution of parallel regions.

As a key feature, GASL supports linking a set of GSCL scenarios to the states of the adaptation model (GASL statechart), thus scenario management can also benefit from the high-level features of statecharts (see adaptation logic and changing of requirements in Section 2.1). During execution, the current state configuration indicates the active scenario configuration (scenarios linked to the active states). When processing incoming events, the GASL statechart has priority over the active scenarios. When a state configuration is left, the scenarios linked to the left states get deactivated and the ones linked to the newly entered states get activated. In addition, history can be set in the scenario links: if history is set, upon activation, the examination of behavior starts at the first still unexamined interaction of the activated scenario; otherwise, it always starts at the beginning of the scenario.

Figure 10 shows an excerpt of the adaptation model (CentralController) of the adaptive smart house system. Note that the adaptation model uses GSL constructs, such as parameters, ports (for event reception and transmission), variables and parallel regions with (pseudo)states along with transitions, to capture the adaptation logic. Contracts can be linked to states using the @Contract annotation in the context of which history (history keyword) or its absence (no-history keyword – default) can be specified (see history in Section 2.1) along with the potential parameter values. GASL also supports the linking of scenarios directly to the adaptation model using the self keyword, indicating that they disregard any potentially linked state-based component behavior (see Section 4.3) in that particular state or directly to component configurations with the component keyword. A contract link (i.e., the linked contract) is considered historyless if it (i) does not specify history and (ii) it is not linked to the adaptation model.

4.3 Extending the adaptation model with configurations of state-based components

In addition to scenarios, GASL supports linking statechart components to states, allowing the description of adaptive component configuration management (see component adaptation in Section 2.1). During execution, linked components are handled in the same way as scenarios in terms of activation/deactivation. Nevertheless, the language offers additional constructs for the integration of component models (graphical models for the sensor and actuator controllers can be seen in Figures 3-5 and 6) as demonstrated in Figure 10.

Similarly to scenarios, components can be linked to states using the @Component annotation, which supports the definition of history and parameter values for a parameterized component. As highlighted the need in Section 2.1, GASL supports binding adaptation model ports to component ports and binding adaptation model variables to component variables (see parametric adaptation). In the case of a port binding, all events received on the adaptation model port are transmitted to the port of the component, and all the events sent via the component port are transmitted to the adaptation model port. Port bindings facilitate bidirectional communication among the adaptation model and managed components as well as among different managed components based on internal ports, which enable the transmission and reception of the same event on the same port. Likewise, in a variable binding, all assignments to an adaptation model variable are conducted on all bound component variables, and vice versa; all assignments to a component variable are conducted on all bound component and adaptation model variables. Variable bindings allow for the fine-tuning of component behavior via parameter (variable) value changes and inter-component communication based on shared variables. A component link (i.e., the linked component) is considered historyless if it does not specify (i) history or (ii) any variable bindings.

The application of the presented constructs for adaptivity regarding scenario contracts and state-based components are utilized in the context of the central controller (GASL model) of the adaptive smart house system (see Figure 10) to achieve the following goal: the system shall provide the necessary ventilation level for the present people in the room while consuming as little energy as possible and adapting to external and internal changes, that is, user commands, component failures and battery drain. Accordingly, the central controller has two parallel top regions for managing person detection (sensors) and ventilation (actuators) with two states that represent the usage of the camera and motion sensor as well as the ventilator and switch components, and one state representing their inactivity. Reconfiguration can be triggered by transitions entering the AdaptationLogic pseudostates, which represent the initial nodes of the complex transitions realizing the reconfiguration logic. By default, the central controller relies on the camera and ventilator (initial states of the top regions) and can reconfigure to use the motion sensor and switch in case the default components become unavailable (unavailability events on the respective component-related ports). In case the default components become available again, they get reactivated by the central controller. In addition, the ventilator is used only if the camera is available as it relies on the person counting functionality and gets deactivated otherwise using the internal deactivate event. If both components of the person detection or ventilation functionalities become unavailable, the central controller enters a stand-by state in both top regions and sets the ventilation level to a default value while waiting for their availability. The central controller also manages the granularity parameter (variable) of the camera based on its battery parameter and can put it on recharge if necessary. This functionality is described in a subregion of the UseCamera state and defines three states with parameterizable granularity settings (low, medium and high) to manage battery. The central controller uses the camera only if the battery is above a certain level (is BatteryLow function) and puts it on recharge otherwise.


This section presents the internal model transformations in Gamma that facilitate the formal verification (see Section 5.3.1), implementation derivation supporting monitoring (see Section 5.3.2) and test generation (see Section 5.3.3) for the adaptive system based on derived composite models that integrate scenario contracts, the adaptation model and state-based components (see Section 5.2). In order to support these functionalities, as a first step, observer automaton models are derived from scenarios (Section 5.1).

5.1 Mapping scenarios into observer automata

Scenario models are transformed into automata in two steps. First, as a preprocessing step, a simplified scenario model is created where (i) every scenario call is inlined with the given parameter values and (ii) every unordered and parallel fragment is mapped into a combination of alternative fragments using Heap's algorithm54 to describe the possible interaction sequences. These simplified scenario models with only loop, optional and alternative combined fragments in addition to atomic interactions are then transformed into observer automata capable of classifying interaction sequences as inconclusive, invalid and valid. The transformation slightly differs if the resultant model is used for monitoring or test generation; the latter is detailed in literature.52, 53 Figure 11 shows the GSL observer automaton generated from the DelayThenMotion scenario with comments indicating different variation points in the transformations.

Details are in the caption following the image
Superset GSL observer automaton with possible variation points generated from the DelayThenMotion scenario. GSL, Gamma Statechart Language.

An observer automaton can have the following states associated with the classification of an observed interaction sequence: cold violation, hot violation and (one or more) accept. In case the transformation is configured to monitoring, the cold violation and accept states are removed and their incoming transitions are targeted to the initial state to support continuous execution. In addition, the entry action list of the initial state is extended with assignments resetting the declared variables.

An atomic interaction is mapped into a source state and three transitions (see outgoing transitions of state _2 in Figure 11) targeting (i) the source state of the next interaction if the specified behavior is matched or the (final) accept state if it is the final interaction (accepting transition), (ii) a violation state based on the modality of the interaction if the specified behavior is not matched by the environment in the case of received, and by the component in the case of sent events (violation transition triggered by the unmatching events) and (iii) the cold violation state if an unexpected event is received or sent in case the transmission or the reception of an event is expected, respectively (cold violation transition triggered by events from an unexpected direction). The lower and upper bounds (if any) of delays are mapped into timeout triggers and added to the triggers of accepting and violation transitions. Check expressions and assign statements are directly mapped into transition guards and assignments on the accepting transition.

In the case of monitoring, the above construction is used both for event reception and transmission. In turn, for test generation, event reception is modeled using a single transition targeting the source state of the next interaction while event transmission is modeled as above. Note that this construction introduces determinism to event reception (triggered by the test execution environment in a testing context) in interaction sequences while the behavior of the system (the system implementation in a testing context) remains to be considered in a nondeterministic way. Moreover, the mapping for test generation in strict mode in the case of synchronous models involves extending the trigger of the accepting transition with the negated disjunction of every unexpected event that can be sent by the system; note that this is unnecessary in asynchronous systems as events are processed one by one. The configuration options for test generation (allowed latency and strict/permissive mode) are also saved in the model as annotations to support test concretization in a later step (see Section 5.3.3).

Regarding combined fragments, alternative fragments are mapped into choice transitions that target the source state of the mapped interaction operands. Optional fragments are also mapped into complex choice transitions where one target is the source state of the mapped interaction operands, and the other one is the source state of the next interaction after that. Loop fragments are mapped into an integer iteration variable (shared by different consecutive loop fragments) and complex choice transitions that target (i) the source state of the first contained interaction operands with a guard describing that the value of the iteration variable is less than the maximum bound as well as an action incrementing the iteration variable and (ii) the source state of the next interaction with a guard describing that the value of the iteration variable is greater than or equal to the minimum bound (note the possibility for nondeterministic behavior). In the case of test generation, infinite maximum values are replaced by the value minimum + 2 $ {\it minimum} + 2$ to avoid infinite paths.

In the case of monitoring, the resultant automaton is determinized using the powerset construction method,55 considering potentially overlapping check expressions and loop unrolling. As a result, the monitor model can classify a sequence in one pass. Note that this is unnecessary for test generation as we aim to generate multiple test cases from the automaton's execution paths, that is, it is enough that the automaton can simulate the described behavior.

5.2 Creating models for formal verification and monitoring

With the scenario models mapped into observer automata according to the selected functionality (monitoring or test generation, see Section 5.1), the next step is to integrate the adaptation, component and contract models in GCL for formal verification and monitoring. Three types of models are created to support different functionalities. T-1 is a “merged” adaptation model that handles the managed components and represents the possible component configurations. T-2 is a composite model that integrates the observer automata with the T-1 type adaptation model to check the violations of behaviors specified in contracts. Finally, T-3 composite models integrate historyless observer automata with historyless managed components to formally verify their adherence to the specified behavior.
  • T-1  During the creation of the T-1 model, managed statechart components are merged into the adaptation model's states as parallel subregions (formed by the top regions of the managed components). A region's entry state is changed to an initial, shallow history or deep history state in accordance with the history setting. In case no history is specified, the action list of the transition leaving this entry state is extended with assignments resetting the unbound variables of the component. In addition, bound ports and bound variables of the managed component are removed and the references are set to the corresponding ports and variables of the adaptation model in accordance with the port bindings and variable bindings. Note that this step is done iteratively until all port bindings and variable bindings are handled, as adaptation models can contain additional adaptation models (see adaptation logic in Section 2.1).
  • T-2  These models handle and integrate the observer automata to the created T-1 model based on the following (de)activation facilities. An activation port with a single activation event is created in every observer automaton, which contains a boolean parameter (active) indicating activation/deactivation. Moreover, a new top region is introduced that contains two states, Active and Inactive (initial state) with (de)activating transitions between them triggered by the activation event and guarded by the active parameter. The original top region of the observer automaton is moved into the Active state as a subregion. The T-1 model is also extended with activation ports for each linked contract (observer automaton) in addition to introducing entry and exit actions in each state with linked contracts raising the respective activation events with the corresponding true/false parameter values. The T-1 model and observer automata are integrated via channels in GCL that connect their respective ports in a scheduled asynchronous or cascade composite component depending on whether the models are asynchronous or synchronous. The execution of the resultant T-2 composite model comprises three steps: (1) the observer automata are executed (to process potential environmental events), (2) the T-1 model is executed and (3) the observer automata are executed (to process potential events sent by the T-1 model).
  • T-3  Such composite models are created only if (i) historyless contracts are linked to historyless non-parallelly managed components (i.e., there are no components linked to states in parallel regions) in the adaptation model or (ii) the user explicitly links the contracts to component configurations for formal verification. In the adaptation model, in every state, for each linked historyless contract, every linked managed component is retrieved (considering parent states): the models are integrated and executed as T-2 models; the difference is that potentially more than one component is executed in the 2nd step. The raison d'etre of this composite model is to facilitate the formal exhaustive verification of managed component behavior with respect to the contracts in a context-independent way: as these links are historyless, the adaptation model and other managed components can be ignored, mitigating the state space traversal problem when looking for violating behavior of a certain component configuration.

As a special feature, the approach also supports the integration of user-defined environment models (arbitrary Gamma components) to the above composite models in place of the (implicitly considered) fully nondeterministic environment that can send every possible input event with every possible parameter value. This way, it is possible to restrict input sequences, for example, based on additional component integration knowledge, during formal verification (see Section 5.3.1).

5.3 Formal verification, implementation derivation and test generation

Formal verification (see Section 5.3.1), implementation derivation (Section 5.3.2) and test generation (Section 5.3.3) can be conducted automatically by directly inputting the original adaptation (Section 4.2) and contract (Section 5.1) models or the derived composite models (Section 5.2) to the inbuilt transformations of the Gamma framework.

5.3.1 Formal verification of adaptive behavior

The approach supports the exhaustive verification of adaptive behavior based on T-1, T-2 and T-3 models in two ways. Both ways rely on the automated transformations of the created models into the input formalism of an integrated verification back-end in Gamma (UPPAAL, Theta or SPIN) and the back-annotation of the results, so the user can interpret them in the adaptation model's context. The resultant analysis models are semantically equivalent regardless of the target formalism; the differences are in the verification algorithms, for example, UPPAAL supports timed behavior, Theta supports abstraction-based symbolic techniques whereas SPIN excels at parallel behavior checking with partial order reduction techniques. They also support different property specification languages, for example, UPPAAL supports restricted CTL, Theta supports reachability whereas SPIN supports LTL,56 providing a good portfolio for model checking.

Model checking of T-1 models is trivial and automated based on the workflow presented in literature:14 one just has to specify a property in accordance with the selected verification back-end in the property language of Gamma. Nevertheless, we can expect high execution times or even the unmanageability of such models as the exponential number of configuration options will pose a great challenge to every model checker. This problem could be mitigated by T-2 and T-3 models as they introduce implicit requirements based on contract models from which formal properties can be derived automatically: the hot violation states must not be reached. These contracts may restrict the number of configuration options and thus, the traversal of the state space, resulting in lower execution times. In case the hot violation states cannot be reached, then the adaptive behavior satisfies the functional requirements specified by the contracts under all circumstances. For T-3 models, the model checking process can be expected to be orders of magnitudes faster compared to T-2 models as the managed component and contract links are historyless and taken out of their original context. As a result, in case the components satisfy the requirements in T-3 models (while considering a fully nondeterministic environment model), then the property holds regardless of context, that is, in every adaptation model (T-2 model). In turn, in case of violation, the violating behavior may not be present in the adaptation model as it can restrict valid input event sequences for active components and thus, component behaviors. Consequently, the interpretation of the results in case of violations can be more difficult for the user. Note that in the case of T-3 models created based on explicit user-defined component-contract links, the results cannot be generalized even when the requirement is satisfied.

5.3.2 Implementation derivation for adaptive behavior supporting monitoring

Deriving implementation that supports monitoring can be conducted using the automated code generators of Gamma14 on T-2 models as input with a minor extension: all automaton models are extended with a port containing a violation event that is raised as an entry action in hot violation states. The ports are then led out to the environment using port bindings in the containing composite component, allowing the identification of violations at runtime. Currently, Gamma supports code generation for Java and provides a flexible reflective Java API for state-based implementations designed for simulation and testing. The API supports the input of scheduling calls and input events from the environment in addition to retrieving raised output events, variable values and state configurations of the underlying implementations to show internal state.

5.3.3 Contract-based black box test generation for adaptive behavior

The approach supports black box test generation based on the original (unprocessed) adaptation and contract models using the model checking functionalities of the Gamma framework. Currently, only historyless contract links are supported. As a general idea, in a testing context, an execution trace derived during model checking as a witness for satisfying a property can be considered as an abstract test case for the property based on which it is generated, representing a test target.57 Thus, with the goal of generating tests, we control model checkers in a way that they generate execution traces (abstract test cases) to cover test targets specified as formal properties, for example, in the case of state coverage as a test target, state reachability properties. Such abstract test cases then can be customized to concrete test environments according to various aspects.58

Test generation comprises two steps: generating paths in the adaptation model to activate contract models and traversing the activated contract models. The traversal of the adaptation model can be configured using various coverage criteria, including state, transition, out-event or interaction coverage. Based on the configured criteria, reachability properties are generated automatically and then passed to the selected model checkers along with the adaptation model, which return execution traces (paths) represented in GTL to state configurations with linked contracts. The observer automaton models derived from these contracts are then traversed to derive positive or negative tests using Theta as it is the only integrated back-end supporting the retrieval of all paths from the initial state to a certain state in acyclic models. For positive tests, every path (possible interaction sequence) from the initial state to the accept states is retrieved in the contract model as the implementation must conform to at least one of them. Note that there are a finite number of paths from the initial state due to the employed constructs (see Section 5.1). For negative tests, paths from the initial state to the hot violation state are retrieved out of which all must fail. As a post-processing step, the parameter values of sent events referenced from check expressions (if any) are handled in the retrieved paths to consider the potentially nondeterministic behavior of the system: as the model checker returns concrete values, they have to be replaced by the referencing check expressions (guard expressions of the corresponding accepting transition – see Section 5.1) to accept every valid value.

In literature,17 test generation based on static contracts was conducted using graph traversal algorithms. Introducing model checking to this phase made the process faster and more flexible compared to the previous algorithms as (i) the model checkers are optimized for model traversal, and thus, the efficient exploration of paths between the initial and accept/violation states and (ii) all statechart elements used in the automata model are inherently supported during the process due to the internal model transformers of Gamma.

Abstract test cases are created as the sequential combination of paths activating particular contracts in the adaptation model and paths in the contract models. In addition, test configuration options present in the contract models, that is, allowed latency and permissive/strict mode, are saved to support test concretization in the next step.

As a last step, abstract test cases are customized to execution environments, that is, they are mapped into sequences of concrete calls to provide test inputs and time delays as well as schedule system execution, and then retrieve and evaluate outputs. The test configuration options in the concretized tests are handled with a simple auxiliary method used in conjunction with output evaluations as depicted in Figure 12. Currently, JUnit is supported as a concrete execution environment and the test calls target the methods of the implementation's reflective Java API (see Section 5.3.2).

Details are in the caption following the image
Auxiliary method handling the test configuration options in the concretized tests.


This section presents experiments with the adaptive smart house system (see Section 2.1) in the context of our approach. First, Section 6.1 introduces the scenario contracts for the adaptive smart house system and their linking to the adaptation model based on which we conduct our experiments. Next, Section 6.2 presents complexity statistics of the managed components, adaptation model and scenario contracts as well as the derived T-1 model and their implementations to provide a basis for the interpretation of results detailed later in the section. Finally, Sections 6.3 and 6.4 detail the results of formal verification and test generation.

6.1 Scenario contracts for the adaptive smart house system

We defined 11 scenario contracts5 based on the functional requirements of the system presented in the Appendix, which specify system and component behavior from different aspects. Two scenarios (S1 and S2) describe behaviors of the entire system whereas the remaining ones capture the behaviors of managed components (S3 to S11). S1 and S2 specify how the system must control the ventilation level in the case of motion sensing and timeouts when the ventilator component is active. S3, S4 and S5 capture the common behavior of the camera and motion sensor components focusing on motion sensing and internal event transmission (see DelayThenMotion and MotionThenMotion scenarios in Figure 9). S6 specifies person detection based on the granularity parameter and timeouts for the camera component (an extension of the MotionThenDelayThenMotion scenario in Figure 9), whereas S7 specifies how too many events in a certain time interval must be handled by the motion sensor. S8 describes how ventilation must be turned on and off by the ventilator and switch components based on received motion sensing events. Finally, S9, S10 and S11 specifies smart ventilation control for the ventilator based on events that describe motion sensing, the number of present people and timeouts.

The scenario descriptions utilize the expressive element set provided by GSCL (see Section 4.1). In addition to event receptions and transmissions batched in interaction sets, the scenarios extensively use delays, check expressions and assign statements as well as a few optional, alternative and loop fragments. In addition, some scenarios rely on scenario calls to reuse interaction sequences defined in other scenarios. In turn, the system does not exhibit parallel behavior and thus, parallel and unordered fragments are not used. As a key characteristic, the scenarios are parameterizable (see how this affects verification in Section 6.3) as they use parameter declarations, and reference and reuse constant declarations (e.g., for timeouts) and function declarations (e.g., to calculate granularity, battery drain and person number delta in the camera) used by the adaptation and component models.

In the adaptation model, contracts for the camera are linked to the UseCamera state, for the motion sensor to the UseMotionSensor state, for the ventilator to the UseVentilator state and for the switch to the UseSwitch state. In addition, the contracts for the camera are also explicitly linked to the component to enable deriving T-3 models for formal verification as they would not be derived automatically due to the variable bindings in the component link.

6.2 Complexity statistics of models and implementations

Table 1 presents the number of input and output events, states, transitions, and variables and timeout variables of the camera, motion sensor, ventilator and switch components (managed components), the central controller (adaptation model) and the derived T-1 model as well as the 11 observer automata derived from scenario contracts introduced above. As can be seen, the T-1 model is indeed created by merging the central controller and the managed component models. Regarding the complexity of the generated implementations, the last two columns describe the number of lines and branches in the generated Java code of all models responsible for the reactive behavior (runCycle method in the component-specific classes). Note that we do not include statistics separately for the derived T-2 and T-3 models as they can be calculated based on the composed components by summing the number of elements in the respective observer automaton and managed component or T-1 model – apart from the number of events, which is specified by the managed component or T-1 model in every model.

TABLE 1. Complexity of the models and the generated implementations in the adaptive smart house system.
Model #Events (I/O) #States #Transitions #Variables (V/T) #Lines #Branches
Camera 2/2 5 12 3/2 60 11
Motion sensor 1/2 5 11 2/3 48 8
Ventilator 2/2 5 11 1/3 69 10
Switch 2/2 2 3 0/0 18 3
Central controller 12/7 12 33 3/1 322 49
T-1 model 12/7 29 70 6/12 747 103
S1 12/1 6 13 0/1 61 12
S2 12/1 6 13 0/2 62 12
S3 2/1 5 10 0/1 50 9
S4 2/1 10 26 1/1 47 9
S5 2/1 9 22 0/12 62 12
S6 2/1 5 10 0/2 113 28
S7 1/1 6 13 0/2 141 21
S8 2/1 6 13 0/0 60 12
S9 2/1 5 10 0/1 50 9
S10 2/1 7 16 0/1 83 15
S11 2/1 10 26 2/2 118 27

6.3 Formal verification based on the derived composite models

This section summarizes our findings of formal verification in our approach based on the derived T-2 and T-3 composite models. First, we overview how formal verification scaled on the presented models. Then, we conclude how formal verification supported managing model parameterizations and semantic variants.

6.3.1 Scalability

Formal verification based on every derived T-3 model with every possible parameterization was carried out under two seconds using the integrated model checker back-ends of Gamma both in case the derived safety property did or did not hold. In turn, formal verification of T-2 models succeeded only when the property did not hold and a relatively short counterexample (comprising at most 7-8 execution cycles) could be given. We got similar results for the T-1 model and manually defined (Gamma-supported) safety and liveness properties. This is the result of the large state space generated by the many adaptation and configuration options in the model (see input events for T-1 model in Table 1). Typically, having unconstrained combinations and sequences of input events is not a practical goal for verification; realistic behavior can be restricted with user-defined environment models. Therefore, we experimented with environment models that restricted error and recovery events. In particular, we specified in an environment model that (i) only one component could become faulty and (ii) could recover only once, which resulted in the verifiability of the safety property in T-2 models under a minute. Naturally, these results cannot be generalized to the original model with a fully nondeterministic environment. In summary, we can conclude that T-3 models indeed significantly restricted the state space and made exhaustive verification viable in cases T-2 could not be managed, as implied in Section 5.2. Note that the extensive measurement of the scalability of formal verification is beyond the scope of this paper; measurement results for the scalability of model checking, which serves as the basis for formal verification and test generation, on different characteristic models can be found in literature.14, 59

6.3.2 Parameterizations

The correct parameterization of an adaptive system is a challenging task since the cross-relations and mutual effects of different parameter values are difficult to assess manually. As our approach supports the experimentation with parameter values in a flexible way, formal verification was able to detect the following problems of incorrect parameterizations:
  • 1. Unexpected states and (the lack of) reactions in components due to inconsistent transitions and parameters that specify timeouts. Namely, the iterative decrease of the ventilation level and its turn off in the ventilator component (as a reaction to the lack of person detection events) were controlled by timeout parameters. In turn, the camera did not consider timeouts while counting persons (CountPersons state). Thus, after a certain time delay, the ventilator could enter the VentilationOff state and could not react to person detection events received from the camera in accordance with the specified scenarios. Another timeout-related issue in the ventilator component stemmed from ignoring person detection events in the FixVentilation state, which led to unexpected timeouts followed by entering the DecreasingVentilation state as well as transmitting unexpected ventilation control events. The problems could be solved by introducing the missing transitions in the respective states.
  • 2. Robustness issues caused by improper parameters in guard conditions. In particular, the computation of ventilation level in the ventilator yielded unrealistic values in case a negative or an extremely high value was received as the number of present people.

After eliminating such problematic cases, the correctness of a coherent parameterization was proven by formal verification for scenarios S3–S11 and the respective component models based on the derived T-3 models.

6.3.3 Semantic variations

Gamma offers multiple semantic variation options for statechart components, for example, transition priority and region execution. We discovered interesting corner cases in the system caused by the synchronous semantics, according to which statecharts must react to potentially multiple events as their execution is initiated by a global clock.14 For example, if a component is in a state that can be left upon a (i) received event or an (ii) internal timeout, the outcome can be different based on the applied variation option if both of them occur in the same execution cycle, that is, the outcome in the statechart can be nondeterministic or deterministic according to transition priorities. Such inconsistencies could be recovered with ease using the T-3 models and resolved in scenarios using the extensive element set of GSCL (namely, using sequences of interactions for deterministic behavior or alternative fragments for nondeterminism) or different variation options (transition priority settings) in the statechart models.

The verification results of T-3 models based on (i) historyless components and (ii) with a fully nondeterministic environment model are generalizable (see Section 5.3.1). Accordingly, the verification of the T-3 models of the motion sensor, ventilator and switch components implies the satisfaction of safety requirements regardless of context. However, the results are not generalizable for T-3 models derived based on explicit component-contract links, that is, for the camera in this example. Nevertheless, aspects that are independent of the bound variables can still be analyzed exhaustively with this method. A general solution can be achieved with T-2 models, but as our experiment shows, their exhaustive verification may not always be viable due to the large state space caused by the many adaptation options – a problem that can be mitigated by environment models.

6.4 Test generation based on the adaptation model and observer automata

As presented in Section 5.3.3, test generation can target managed components linked to the adaptation model in a historyless way, that is, the motion sensor, ventilator and switch components in this example, excluding the camera component. Recall that this is due to the two separate phases of the process: the first phase is conducted on the adaptation model based on coverage criteria whereas the second one is conducted on the observer automata linked to the states with managed components. In this experiment, we used state and transition coverage criteria in the first phase as output events are not sent by the adaptation model and interactions are not interpreted within a single component.59 Table 2 summarizes the results in terms of the number of distinct generated execution traces ending in states with linked historyless contracts, and the median and maximum number of steps in these traces. Note that in this example, the maximum number of traces depend on the (i) initial value of the battery parameter of the camera, (ii) how fast it is drained/charged in an execution cycle as well as (iii) at what battery percentages the granularity parameter of the camera is changed. For this experiment, we used the (i) 50%, (ii) 1% and 1%, and (iii) 20% (high granularity) and 80% (low granularity) values, respectively. The whole generation of traces was carried out under 30 and 90 seconds for the state and transition coverage criteria.

TABLE 2. Results of the adaption model traversal phase of test generation in the adaptive smart house system.
Criterion #Execution traces #Steps (med/max)
State 6 2/34
Transition 23 3/35

As the table shows, the number of generated execution traces is considerably higher for transition coverage due to the large number of manageable events (e.g., component failure and recovery, and battery drain) and configuration options. In contrast, for state coverage, only different states (i.e., active components and the battery managing states) must be distinguished. Regarding the number of steps, the longest traces were generated for covering the low granularity control state and its outgoing transition, as they required the charging of the battery above 80% (charging the battery from 50% to 80% requires at least 30 steps with the defined parameterization). The rest of the states and transitions could be covered with a median of two and three steps.

In the second phase, in order to generate positive and negative tests, the algorithm traversed the observer automata that were linked to states in which the generated execution traces ended. Table 3 summarizes the number of generated execution traces and the median and maximum number of steps in these traces considering every linked observer automaton for positive and negative tests for the motion sensor, ventilator and switch components. The generation of such traces was carried out under ten seconds for each automaton.

TABLE 3. Results of the observer automaton traversal phase of test generation in the adaptive smart house system.
Positive Negative
Component #Execution traces #Steps (med/max) #Execution traces #Steps (med/max)
Motion sensor 4 3.5/12 4 3.5/12
Ventilator 7 4/7 26 4/8
Switch 1 4/4 2 3/4

The number of generated traces in an automaton depends on the number of distinct paths between the initial and the accept states for positive tests, determined by the optional and alternative fragments (branchings) of the scenario. For negative tests, in addition to the number of distinct paths between the initial and the hot violation states, the number of hot modality interactions is also a determining factor. As Table 3 shows, there were no branchings and there was a single hot modality interaction in the automata for the motion sensor component; thus, the numbers of generated traces and steps were the same for both positive and negative tests. Note that the relatively large number of steps stemmed from an automaton counting incoming events using a loop with 10 iterations (S7). The automata for the ventilator component contained an optional fragment and many hot modality interactions, hence the large difference between the number of traces for positive and negative tests. Finally, a single automaton was linked to the switch component that contained four interactions out of which two were of hot modality.

The abstract test cases were created as the sequential combination of respective traces of the first and second phases, resulting in 24 and 127 positive, and 64 and 456 negative tests, based on the state and transition coverage criteria, respectively. The abstract test cases were concretized to JUnit tests using the strict mode with the 0..2 allowed latency interval (see Section 4.1) as the component models were not supposed to send unexpected events and needed at most two execution cycles to send expected events after the received events. All tests passed on the generated Java implementation within less than five seconds altogether; as expected, since both the analysis models for model checking and the Java code are derived from the same low-level internal representations of Gamma. Nevertheless, in general, the large number of tests could be used for the thorough examination of integrated implementations produced by 3rd party code generators or manual coding.


In this paper, we introduced an end-to-end component-based specification, design and V&V approach for adaptive systems in the open source Gamma tool. The approach supports requirement specification in the form of high-level scenarios whose adaptive activation and deactivation can be defined in a high-level state-based adaptation model. The adaptation model can also manage configurations of statechart components to fully capture adaptive behavior and create implicit links between behavior specifications (contracts) and their realizations (components). The resultant adaptation models can be exhaustively analyzed based on user-defined formal properties or the implicit component-contract links using the automated transformations and integrated model checker back-ends of Gamma. Implementation derivation supporting monitoring and contract-based black box test generation for the adaptation model are also supported with the utilization of Gamma's code generation and model checking functionalities.

Our experiments show that the approach is applicable in an extended adaptive house automation system, first presented in literature.19, 20 Adaptive behavior can be adequately modeled using the proposed modeling languages, and the satisfaction of functional requirements specified as scenarios can be formally verified based on component-contract links and the employment of optimization techniques that reduce irrelevant context details. Nevertheless, adaptive models with many adaptation options, as expectable, can pose a great challenge to model checkers if optimization is not employed. In general, this problem could be addressed by extending the formal verification capabilities of Gamma by integrating additional model checkers more tailored to these models along with abstraction and reduction techniques. Also, implementation with monitoring support can be automatically derived and then tested using the generated test sets.

Subject to future work, we plan to extend our approach to allow the management of composite components in order to support a system modeling approach based on compositional variation points and application variants.36 We intend to realize the extension based on the generalization of the integration and (de)activation facilities for observer automata presented in Section 5.2. Moreover, we aim to extend our scenario language to support inter-component communication (multiple lifelines). We also plan to extend our approach by introducing the modeling and verification of extra-functional properties based on literature60 and support the automatic deployment of adaptive functionality to computation nodes.


We would like to express our gratitude to Benedek Horváth for his initial contributions to the GSCL metamodel and Dénes Lendvai for his implementation efforts regarding the model transformations between scenario and automaton models, as well as test generation from static scenario contracts. This work was partially supported by New National Excellence Program of the Ministry for Innovation and Technology, ÚNKP-20-3-I and ÚNKP-22-3-II, as well as NRDI Fund of Hungary under the 2019-2.1.1-EUREKA-2019-00001 funding scheme (EMBrACE project) and Grant TKP2021-EGA-02.

New National Excellence Program of the Ministry for Innovation and Technology, Grant/Award Numbers: ÚNKP-20-3-I-BME-42 and ÚNKP-22-3-II-BME-223; National Research, Development and Innovation Fund of Hungary,Grant/Award Numbers: 2019-2.1.1-EUREKA-2019-00001 and TKP2021-EGA-02


    This section introduces the breakdown of the presented adaptive smart house system in terms of functional requirements. We organize the functional requirements as follows: first, we present the high-level functional requirements of system behavior, which are followed by the requirements referring to the functionalities of the integrated system components (sensors and actuators). Finally, the section concludes with adaptivity-related requirements of the system. Note that these requirement specifications are deliberately high-level and partly ambiguous; this way, they can (and must) be refined to the concrete environment, e.g., by concretizing the values of the described system attributes.

    High-level functional requirements of the system's joint behavior:
    • RQ-1.1: The system shall control the ventilation of a room using sensor data and actuators based on the number of present people.
    • RQ-1.2: The system shall use a camera and a motion detector (sensors) to retrieve data about the presence of people in the room.
    • RQ-1.3: The system shall use a smart ventilator and switch (actuators) to set the ventilation level of the room.
    Functional requirements related to the sensor components:
    • RQ-2.1: The camera shall detect the presence or absence of people in the room.
    • RQ-2.2: The camera shall be able to detect the exact number of people present in the room and transmit this data (functioning state).
    • RQ-2.3: The camera shall have a battery that drains in the functioning state, and can be recharged in an idle state.
    • RQ-2.4: The camera shall have a granularity attribute that specifies the difference in the number of people present in the room that triggers the transmission of new data.
    • RQ-2.5: The motion detector shall detect the presence or absence of people in the room (functioning state).
    • RQ-2.6: The motion detector shall identify inappropriate functioning, that is, internal (e.g., underlying hardware component) failures or potentially malicious behaviors, and handle it by entering an idle state.
    Functional requirements related to the actuator components:
    • RQ-3.1: The smart ventilator shall be able to turn off and on the ventilation.
    • RQ-3.2: The smart ventilator shall set the ventilation level adaptively based on incoming data of the number of present people (functioning state).
      • RQ-3.2.1: The lack of incoming data shall specify the setting of the ventilation to a predefined (default) level.
      • RQ-3.2.2: An incoming greater value shall specify a greater ventilation level and vice versa.
      • RQ-3.2.3: An incoming value shall become obsolete over time, that is, the lack of incoming data shall specify the gradual setting of ventilation level to the predefined level.
    • RQ-3.3: The switch shall be able to turn off and on the ventilation.
    • RQ-3.4: The switch shall always set the ventilation to a predefined (default) level (functioning state).
    Functional requirements related to adaptivity in the system (central controller):
    • RQ-4.1: The system shall use at most one sensor and one actuator at a time.
    • RQ-4.2: The system shall adapt to external and internal changes in the system, that is, component failures and recoveries, as well as battery drain in the camera.
    • RQ-4.3: The system shall examine which sensor and actuator to use whenever one of them leaves or enters their functioning state.
      • RQ-4.3.1: The system shall use the camera as the source of sensor data whenever it is in a functioning state.
      • RQ-4.3.2: The system shall use the motion detector as the source of sensor data if it is in a functioning state and the camera is not in a functioning state.
      • RQ-4.3.3: The system shall use the smart ventilator as an actuator if it is in a functioning state and the camera is in use.
      • RQ-4.3.4: The system shall use the switch as an actuator if it is in a functioning state and the smart ventilator is not to be used.
      • RQ-4.3.5: The system shall enter a stand-by state if neither of the sensors or the actuators are in a functioning state and set the ventilation to a predefined level.
    • RQ-4.4: The system shall set the granularity attribute of the camera based on its battery.
    • RQ-4.5: The system shall put the camera in the idle state and start recharging it if its battery is low.


    • image

      Bence Graics is a research assistant at the Budapest University of Technology and Economics (BME), Hungary under the supervision of Dr. István Majzik. He earned his M.S. degree in computer engineering at BME in 2019. He joined the Critical Systems Research Group (ftsrg) during his undergraduate studies at BME and has been the main developer of the open source Gamma Statechart Composition Framework since the start of the project in 2016. His main research interest lies in the model-based design and verification of reactive systems using formal methods. As a visiting researcher, he spent several months at the National Institute for Space Research of Brazil (INPE) in the context of the H2020 ADVANCE EU project. He presented his work at conferences, such as ICSE, MODELS, and DepCoS, and in the Software and Systems Modeling (SoSyM) journal.

    • image

      Vince Molnár is an assistant professor at the Budapest University of Technology and Economics. His main research field is model-based development and formal methods, with the primary focus on concurrent, distributed and safety-critical systems. He is the leader of the development of the Gamma Statechart Composition Framework, coordinates the development of the Theta Verification Framework and contributed to the development of PetriDotNet as well. He has been participating in several successful and ongoing EU projects such as EMBrACE or ADVANCE, and various industrial cooperations. He worked several months in research visits or project secondments, including a research visit to the McGill University in Canada, to the National Institute for Space Research of Brazil (INPE), and a project secondment at CERN during which he developed the architecture of PLCverif2. As a member of the SysMLv2 Submission Team, he works mainly on the execution semantics of the new systems modeling language. He serves regularly in program committees of international conferences and was PC co-chair of the 25th Brasilian Sysmposium on Formal Methods.

    • image

      István Majzik is associate professor at the Budapest University of Technology and Economics. His fields of research and education include construction, evaluation and verification of dependable and safety-critical computer systems, he is a co-author of more than 90 scientific papers. He is regular program committee member of international conferences in the field, among others he was general co-chair of the 35th IEEE Symposium on Reliable Distributed Systems (SRDS). He participated in several European research projects in the area of dependable embedded systems, model-based testing, and formal verification.


    The data that support the findings of this study are openly available in the gamma repository at https://github.com/ftsrg/gamma/tree/master/examples/hu.bme.mit.gamma.smarthome.casestudy.