In this work, we investigate the interplay between requirements and architecture in the context of adaptive systems. Furthermore, we propose the Multi-Level Adaptation for Software Systems (MULAS) framework. It is centred on the iterative and incremental refinement of a goal model, towards the creation of a design goal model, which can be used at runtime to drive adaptation on a system that is properly instrumented. Moreover, the framework includes a toolsupported process for generating statechart behavioural models from a design goal model.
Different approaches to support the development of self-adaptive systems have been
proposed in the literature. However, those are often restricted to a single aspect of
software development. For instance, the Zanshin framework [
On the other hand, Rainbow [
Requirements engineering and architectural design, while addressing the system
specification at different abstraction levels, comprise intertwined activities [
Approaches that only support requirements-based or architecture-based adaptation thus, lack relevant elements of the adaptation space. For instance, architecture-based Copyright © 2015 for this paper by its authors. Copying permitted for private and academic purposes. approaches might ignore stakeholders' goals and preferences, while requirements-based ones may not address concerns related to the system implementation, such as algorithms and components.
Hence, the investigation of how to support seamless adaptation mechanisms across the different phases of software development seems to be a promising venue to improve the development of self-adaptive software systems. In this paper we provide an overview of a design process centred on an extended goal model, which incorporate elements aiming to support requirements-based and architectural-based adaptation. To illustrate, we adopt a meeting scheduler exemplar.
The remainder of this paper is organized as follows. In Section 2, we present our process to design adaptive systems, focusing on behavioural specification. Section 3 discusses the limitations of this work. Later, we present ongoing and future work in Section 4. 2
The proposed process, which is a part of the Multi-Level Adaptation for Software Systems (MULAS) framework, comprises eight steps (Fig. 1). The first five steps are related to the refinement of design goal models: Identify design tasks, constraints and assumptions; Assign tasks; Define basic flows; Identify indicators, parameters and relations; and Specify adaptation strategies. The other three steps are related to statecharts: Generate base statechart; Specify transitions; and Include adaptation elements. While these steps may be followed mostly sequentially, waterfall-like, in realistic settings it is expected that the architect will go back and forth, by introducing additional refinements to already refined elements.
Identify design
tasks, constraints, and assumptions
Include adaptation elements +
Assign tasks
Define basic
flows Specify transitions
Generate base statechart
Identify indicators, parameters, and relations Specify adaptation strategies Start event
End event
Task + Subprocess
Repeatable process/task
Sequence
flow The first step, Identify design tasks, constraints and assumptions, supports the refinement of a goal model by including elements that are not initially required by stakeholders, but are relevant from the architectural point of view, expressed as design tasks, design constraints and design assumptions. The second step, Assign tasks, consists of assigning the responsibilities for the execution of tasks — e.g., tasks that will be performed by an external actor (human or otherwise). This assignment is helpful for defining the scope of the system.
In the next step, Define basic flows, the architect introduces possible flows for every sub-tree in the goal model. Roughly, these flows describe the order that the sub-elements are going to be fulfilled or executed, so that their parent element can be considered fulfilled or executed. These flows are expressed as alternative flow expressions, introduced as annotations to a goal model using a top-down, bottom-up, or middle-out strategy. These expressions are later used to automatically generate a statechart that represents the system’s behaviour.
The next two steps are related to the adaptation capabilities of the system: Identify
indicators, parameters and relations and Specify adaptation strategies. The former is
related to the addition, in the design goal model, of some elements proposed by Zashin
[
The second part of the process is related to system behaviour. The first step, Generate base statechart, makes use of derivation patterns to automatically create a statechart from the flow expressions previously defined. Although flow expressions are a useful intermediate abstraction between goal models and statecharts, they are not as expressive as statecharts. Thus, in the next step, Specify transitions, the transitions of the statechart are refined with their events and conditions, which are identified by analyzing when any given transition should take place.
An example of a resulting (Design) Goal Model is shown in Fig. 2, which is an
excerpt from a Meeting Scheduler system [
The tasks defined during architectural design (the so called design tasks) in this example are: Brute Force Algorithm, Heuristics-based Algorithm, and Select Date. The first two tasks define algorithms that can be executed to perform the scheduling, while Select Date is a task that must be performed once the algorithms find a set of possible dates. Additionally, the automatic scheduling presents two design constraints: it must be performed in less than ten minutes and it must be implemented with web-services. In particular, the selected web-service must be available at least 90 % of the time.
Besides goals, tasks, constraints and assumptions, the DGM also contains flow expressions, an extension of regular expressions that allow the definition of the execution flow of the system. Six constructs can be used in these expressions: alternative (vertical bar, |), optional (question mark, ?), sequence (blank space, ), repetition (star or plus symbol, * or +), parallelism (hyphen,–), and idle states (iX, where X is a natural number).
Each flow expression defines the behaviour for the element which it is on top of. For instance in Fig. 2, the (t15|t16) expression states that, when the system needs to Define Schedule, it may either perform Schedule Manually (t15) or Schedule Automatically (t16). Moreover, for the execution of Schedule Automatically, the expression is ((dt52|dt53) dt54), with this meaning: after performing either Brute Force Algorithm (dt52) or Heuristics-based Algorithm (dt53), the system will perform the Select Date task (dt54).
Lastly, the DGM defines what must be monitored during the system execution (the so called awareness requirements), and what can be modified in the system (the parameters). In our example, the AR1 awareness requirement, linked to the Schedule Automatically task, states that it must never fail. AR2, linked to the Rooms Available assumption, indicates that it should be false no more than twice a week (Max Failure 2, 7d). On the other hand, AR3 linked to the Availability of Service design constraint, defines that its success rate should not decrease for two days in a row (NotTrendDecrease 1d, 2).
As illustrated with the aforementioned example, the design goal model allows the integration of requirements and architectural concerns in a single model. Both requirements and architecture elements can be used to specify the system adaptation, with awareness requirements, parameters, relations, and adaptation strategies. In the next subsection we discuss some of the limitations of the proposed process and the design goal model. 3
This MULAS design process, as well as the design goal model, presents a series of limitations, regarding the following aspects: expressiveness of the design goal model, heuristics for selecting optimal flows, tool support, and compositional adaptation.
Expressiveness of the design goal model – The design goal model proposed in this
paper is based on goal model extension [
Heuristics for selecting optimal flows – In the MULAS framework, we propose the use of flow expressions to define the possible flows of the system. However, we do not provide any guidance that helps the architect in the decision of which flow may be best in different contexts and scenarios. Further investigation is required in order to identify heuristics, patterns, or techniques to facilitate such decision.
Tool support – A supporting tool was developed specifically to support the MULAS framework. Even though this tool is functional, more effort is required in order to make the tool suitable for public use, related not only to actual development but also to the creation of user documentation, such as user guides or tutorials.
Compositional adaptation – Parameterized adaptation is adaptation related to the
modification of variables. In contrast, compositional adaptation is related to modifying
structural parts of the system. While we have conducted early endeavours on the latter
[
This is an ongoing work, with early results presented in [
Through an experiment with 15 requirements engineering students, we were able to obtain evidence in favour of the feasibility of the framework. Nonetheless, further experimentation is required in order to properly evaluate and evolve the proposal, specifically in the context of large industrial system.
Another interesting line of research is to adapt the MULAS framework for
developing context-sensitive systems [
This work has been supported by the ERC advanced grant 267856 “Lucretius: Foundations for Software Evolution”, as well as by the following Brazilian institutions: FACEPE, CAPES and CNPq.