Runtime representations of requirements have recently gained interested to deal with uncertainty in the environment and the term requirements at runtime has been established. Runtime representations of requirements support reasoning about the requirements at runtime and adapting the configuration of a system according to changes in the environment. Such systems often called self-adaptive systems. Core part of respective approaches in the field is a requirements monitor. That is, an instance which is able to observe the system's environment and to decide whether a requirement is broken, based on assertions. The problem addressed in this paper is how to generate the applicationspecific parts of a requirements monitor. Such a monitor consists of some goal model for decisions at runtime, assertions connected to the goal model, and parameters on which assertions are defined. We present in this paper a model-driven approach to enhance requirements documents by goal models, assertions, and parameters in a way which is (1) understandable to requirements engineers and (2) a sucient basis for generating the requirements monitor. The contribution is an integrated view on requirements for self-adaptive systems and a concept for code generation.
Today’s software-intensive systems are faced with anticipated and unanticipated
variations in their operating context. Runtime representations of requirements
have recently gained interested to deal with changing end-user requirements,
operating context conditions, and resource availability [
Reasoning in the presence of uncertainty is a classic field of Artificial
Intelligence (AI) research and some RE approaches make use of AI techniques for
instance of Fuzzy logic [
To our experience, the term adaptivity in relation to requirements needs
explanation. First, the development time and runtime view of adaptivity should
be separated. Considering runtime first, a system typically fulfills a set of goals.
These goals are related to functions of the system. One approach to adaptivity is
to enable a system to learn new functions from analyzing its usage, for instance
by employing machine learning techniques [
Another approach is to see changes in the requirements, context, and
resources as forming a new problem to be solved [
Requirements monitoring has been researched for while. Core part of the approaches is a requirements monitor, which observes the environment, decides whether a requirement is broken, and computes a new system configuration based on runtime requirements (see Section 5).
Problem. We propose in this paper an approach for generating a requirements monitor, because a monitor contains application-specific parts that must be implemented for each new system, e.g. assertions. Thus, such a generator eases the development of self-adaptive systems.
As Figure 1 shows, in our approach a requirements monitor consists of a rule engine, which observes a set of assertions, and an impact analyzer, which analyzes the e↵ect of a broken rule with the help of the runtime requirements (e.g., goal model). Finally, the requirements monitor releases a new configuration of the system with fits best to the changed situation. Probes are added to the application to monitor variables, which are of interest to the assertions. We add a goal model, assertions, and variables to the development time representation, in order to be able to generate a runtime requirements monitor.
Probes, assertions, and the goal model in the runtime representation are specific to the respective application and thus must be produced by the generator. The application itself results from typical software development activities and is, thus not subject of this work.
Contribution. First, we propose a metamodel which defines the additional requirements artifacts which allow to generate a requirements monitor. Second, we outline a generator for a requirements monitor. The benefit is an integrated view of the di↵erent views on the requirements for self-adaptive systems and a significant decrease of e↵ort in building an adaptive system.
Structure. The remainder of this paper is organized as follows. Section 2 outlines the background of our research. Section 3 discusses the metamodel and Section 4 describes the generator. Section 5 reviews the related work. Section 6 concludes with a summary and an overview on our future work. The focus of our work is in particular on embedded systems, which impose heavy constraints on software. As these systems are mass-produced, the capabilities of the hardware are optimized to the purpose of the respective system. That is, the power of the CPU and the memory size are limited. Constraints on energy consumption prohibit more powerful hardware, since many embedded systems run on batteries. Many embedded systems act autonomously, that is they make decisions without the confirmation of a human operator. The software cannot be easily maintained or tuned to changing conditions manually. Therefore, there is a need for adaptivity. However, adaptivity conflicts with other design goals such real-time behavior, safety considerations, and the resource constraints mentioned above.
A self-adaptive system has the ability to dynamically and autonomously
reconfigure its behavior in order to respond to changing environmental conditions
[
For the development time representation, a semi-formal requirements language
is required for the generator in order to parse the requirements. DOREF (“do
requirements first”) is an education and research framework for requirements
engineering [
All concepts of the language are organized in a single tree. Figure 2 shows the general structure of the tree. The root node is called World, it is a system, which composed of subsystems. A System is related to a project and a Project results in a set of documents from a product perspective. A Document contains TextualElements like requirements and Models. Activities are used to describe the RE process.
We extend DOREF to cover variables, optional requirements, and i* goal
models [
In this section we describe the metamodel of our approach, which is a refinement of the development time artifacts shown in Figure 1. The metamodel (cf. Figure 3), shows on the upper side the textual requirements of DOREF, on the lower side a subset of concepts of an i* goal model, and how assertions are connected to the i* model and the textual requirements.
The goal is to generate the requirements monitor shown in Figure 1. It
consists of two components: (1) a rule engine and (2) an impact analyzer. In the
following, we explain briefly the interaction of the components (for details see
[
The rule engine monitors assertions. Assertions are Boolean conditions describing assumptions about the environment, which usually should be fulfilled. If an assertion fails, a requirement may be violated and the impact analyzer is invoked. The impact analyzer assesses which parts of the goal model are a↵ected and whether a change in the model is really necessary. If a change is necessary, a new configuration is computed and the system switches to that new configuration eventually.
In the following subsections we describe the parts of the metamodel and their role in generating a requirements monitor. 3.1
As mentioned before, the textual requirements are written in DOREF (see Section 2.2), Listing 1.1 shows an example. Figure 4 shows the generated PDF requirements document. We extended the requirement with an optional property, which indicates whether a function that is related to a requirement is active under consideration of the environment and the current configuration of the system. The requirements Clean at night (SRS-29) and Clean when empty (SRS-30) have an optional property. The function associated to Clean at night (SRS-29) is not activated in the current configuration.
Listing 1.1. Textual Requirements with DOREF 1 Req("Clean at night", 2 "The robot shall clean the apartment at night.", 3 {’Optional’: "False", 4 ’Conflict’: ["/*/Clean when empty"]}) 5 Req("Clean when empty", 6 "The robot shall clean the apartment when nobody is inside", 7 {’Optional’: "True", 8 ’Conflict’: ["/*/Clean at night"]}) 9 Req("Power", 10 "The suction power must not exceed ${suction_power}.", 11 {’Priority’: 1, 12 ’ConceptRefs’: ["/*/Concept/*/Suction Power"]}) 13 Req("Silence", 14 "The operation of the vacuum cleaner should be as silent as possible.", 15 {’Priority’: 2})
Textual requirements are semi-formalized by means of parameters, input and output variables. These variables are marked with the annotation ${name} (see Listing 1.1 line 10) in the textual requirements. Every variable has an unique ID,
Fig. 4. Textual Requirements with DOREF a type and a default value. The requirement Power (SRS-31) has a parameter maxSuction.
An Input variable describes an environmental quantity, which is monitored by the system. An Output variable describes an environmental quantity, which is controlled by the system. A Parameter is used to tune a function, e.g., to adapt a particular threshold.
The information for the parameters and variables are identified during requirements elicitation with stakeholders, they result from variable characteristics in the domain of the system. One simple example in the automotive domain is a windshield wiper. It has parameters for calibrating a rain sensor and the speed of the wiper.
On the upper side of Figure 3 the Requirements class is shown. Figure 4 shows that it contains a unique ID, a Name and a short Summary. A requirement can have di↵erent Properties. For example Type, E↵ort or a reference like ConceptRefs (see Listing 1.1 line 12). For the requirements monitor we add an Optional property. The property indicates if the function associated to the requirement is active or not. 3.2
We use the goal-orientated modeling language i* [
A simple implementation of i* is provided by the openOME1 tool. We use its meta model, which is defined based on the Eclipse Modeling Framework2 (EMF). For a better view on our metamodel (see Figure 3) we only show those parts of this model, which are related to the extension, but not the full i* metamodel.
The relevant parts are the Intention/ i*-Elements, the Softgoal and the ContributionLink. Every Intention (Goal, Task, Resource and Softgoal) can be related to a requirement. This relationship is build over References in the properties, for example RelatedTo in Listing 1.2 line 8.
Figure 5 shows an i* model of the previously mentioned vacuum cleaner case study. Listing 1.2 is a textual representation of this i* model using DOREF. The task Clean at night is related to the requirement Clean at night, see line 8.
Listing 1.2. i* model of the vacuum cleaner in DOREF
For the following subsection discuss how an assertion is connected to a Softgoal or a ContributionLink. 3.3
A softgoal is an element whose satisfaction is depending on components or events inside the system and its environment. A contribution link has a type (for example make, help, etc.) which is also depending on the situation of the system and its environment. To determine the satisfaction or the type of a link, the requirements engineer states assertions about the required situation of the system and its environment.
An assertion can be seen as a kind of a test case to prove if a requirement can be fulfilled at runtime. Thus, a requirements engineer derives an assertion from a requirement.
Listing 1.3. Assertion with DOREF 1 SGAssertion("/*/Minimize noise level", 2 ["maxSuction", "suction"], 3 "suction < maxSuction", 4 "Satisfied", "Denied")
Because a requirements engineer needs to describe assertions, we added a textual description for the assertions to DOREF, see Listing 1.3. Figure 6 shows an assertion which is related to a softgoal with the ID SOFTGOAL-54 and two variables suction and maxSuction (Listing 1.3 line 2). The parameter maxSuction can be also found in Figure 4.
The structure and relationship between an intention and the assertions are shown in Figure 3. We define two kinds of assertions, one to handle the softgoal satisfaction and one for the contribution link type.
An example SoftgoalAssertion is shown in Listing 1.3 and Figure 6. The ID SRS-33 is generated by the framework. The rule is a Boolean condition defined over the related Variables, which is evaluated by the rule engine inside the requirements monitor. The Boolean condition employs Java Boolean expressions. That is, it evaluates to false or true and uses Boolean operators, like ==, &, !, etc. If an assertion is broken, the related softgoal satisfaction changes from the Default Value to the New Value. In example above, it would change from Satisfied to Denied. 3.4
As shown in Figures 4 and 6 and Listing 1.1, 1.2 and 1.3 there is a direct connection between the requirements model and the i* model by means of assertions. This allows to define consistency checks on requirements models. We have identified four consistency rules: – Every task must be related to a requirement. – Every requirement, which is related to a task, must have an optional property. – For every requirement with variables inside the textual description, at least one assertion must be defined. – For every root softgoal (i.e., the softgoal only has incoming contribution links) or for one of the incoming contribution links an assertion must be defined.
Rule 1 and 2 are checking the relationship between tasks and requirements. Every goal can be achieved over di↵ erent alternatives. These alternatives are described by tasks, which reflect possibly conflicting functional requirements. So these requirements can only be fulfilled if the task is satisfied. This requirements need the optional property to show if they are fulfilled. Rule 3 ensures that the rule engine checks all defined variables. As mentioned in Section 3.3 the satisfaction of a softgoal depends on the environment and state of the system. Rule 4 ensures that every softgoal can be defined. 4
This section describes the generation of the requirements monitor using the presented metamodel (see Figure 3). Our first step was to identify components, which are application-specific, and thus need to be generated. The impact analyzer is the only component which does not require generation. The analyzer gets its inputs from the goal model and every information for changing and computing the model from the rule engine and the integrated assertions. The evaluation process does not depend on the application. The other components are application-specific and will be described in the remainder of this section. 4.1
The goal model is the runtime representation of the requirements and describes the alternative realization strategies of the system. This component must be generated. As described in Section 3.2, we use an i* model for representation of the requirements. This model is developed by a requirements engineer using DOREF. Inside the requirements monitor the Eclipse Modeling Framework (EMF) is used to access the i* model. The underlying source code for accessing the model is generated by EMF. The information for creating an i* model can be exported from DOREF and imported by the requirements monitor. 4.2
The monitor component owns a rule engine, which checks the assertions. To implement the rule engine we use Roolie3, a framework that supports defining, changing and checking rules at runtime. The required information for generating the application-specific parts of the rule engine is inside our metamodel.
The Rule inside the assertion is used for the Boolean condition of the rule inside the rule engine, see Listing 1.4. The rules use rule arguments RuleArgs (see line 1) to check the condition. A rule also have the following information of a connected i*-Element: ID, satisfaction, or type of contribution link. If a rule breaks, the required information about the i*-Element is sent to the impact analyzer, which computes all satisfactions of the i*-Elements inside the model.
Listing 1.4. Implementation of a Rule with Roolie 1 int maxSuction = ruleArgs.getMaxSuction(); 2 boolean passes = currentSuction < maxSuction;
The assertions are related to variables. The variables are stored as rule arguments (RuleArgs) inside the rule engine. If a variable in the system changes, the monitor set the related RuleArg with a new value. The rule engine checks every connected assertion. The variable ID is used for the RuleArg, see Listing 1.5. The default value is used as initial value of the RuleArg.
Listing 1.5. Implementation of RuleArgs with Roolie 1 public enum ArgField { 2 MaxSuction, Suction; 3 }; 4 public void setMaxSuction(int MaxSuction) { 5 setInt(ArgField.MaxSuction, MaxSuction); 6 } 7 public int getMaxSuction() { 8 return getInt(ArgField.MaxSuction); 9 } 10 public void setSuction(int Suction) { 11 setInt(ArgField.Suction, Suction); 12 } 13 public int getSuction() { 14 return getInt(ArgField.Suction); 15 } 4.3
For checking the assertions the monitor has to communicate with the application and set the current value of the variables/ RuleArgs inside the rule engine. The monitor can register at an interface of the application to receive the parameter information. If a connection is established the application sends messages with new Parameter values ( Suction::40).
The monitor has to receive and analyze this messages and set the RuleArgs. Listing 1.6 shows the result of the generation process.
Listing 1.6. Monitor
ruleEngine.getRuleArgs().setSuction(Integer.parseInt(msg[
The message is split and the parameter ID is used to set the right RuleArg. 5
Requirements engineering for self-adaptive systems has gained a lot of interest
as a recently published survey has shown [
The environment is usually attached to a goal model using domain
assumptions [
Because we work in the area of embedded systems we have to handle resource
constraints as mentioned in Chapter 2. The approaches in [
This paper proposes a way of augmenting a requirements specification with
additional information so that a requirements monitor can be generated. A concept
for such a generator is outlined. The result is geared towards our approach of
representing a self-adaptive system described in [
This is an important step towards our goal of providing feedback to requirements engineers and users about changes made to the requirements during runtime. The key is to be able to build adaptive systems without significant overhead during development time. Especially embedded systems are interesting, as a human operator is often not available to give a confirmation to a system’s decision. Thus the system must decide autonomously. Moreover, model-driven development is already widely used in practice.
We suggested in this paper a concept for making adaptivity explicit in development time artifacts. Nevertheless, discrete adaptivity can also be programmed directly into an application. The benefits of an explicit documentation of adaptivity are similar to the benefits of an explicit documentation of variability in case of software product lines: understanding and communication are improved.
Our future work addresses the communication of the changes to the users and the formalization and monitoring of further aspects of requirements. Regarding embedded real-time systems in particular, execution times, violations of deadlines, etc. are of interest. This information can also be collected at runtime and feed back to engineers.