Energy-awareness Evolution Impact

The Observer and Visitor pattern ensure a high degree of modularity and decoupling. The design choices where made to maximise reuse, decoupling and modularity. To test

the system’s evolvability energy-awareness functionality is introduced. By introducing energy-awareness functionality the number of observable and visitable components is increased. Figure 11 shows all new observable and visitable classes. Blue classes are newly introduced classes, red classes need modification to satisfy the new requirements.

Figure 11: Modification to the base system

Figure 11 shows the voltage and ampere fields (both data fields in the battery class modelled as a separate class) as two of the new observable classes (blue). These classes are introduced because before energy can be considered we need to measure voltage and current. With voltage and current known at a given moment in time, power (formula 2) can be calculated for that moment in time. Evolution scenario’s V1,V2, E3 and E4 adapt the behaviour of the robot. Because of this the navigator will need additional adaptations; new visitors must be declared to add additional adaptation functionality. Recall that the robot should be able to notice when it is running out of energy; the robot should return to the base station as soon as it is running low on energy. A new route must be calculated to navigate from the current position back to the base-station.

These newly introduced observable classes affect the monitor interface; new event han- dlers must be created to handle each new observable class. This will not only affect the monitor but also the analyser and planner components of the control loop architecture. Each of these classes must handle the new event, for which they need a handler. The same applies to new visitable components, which need new adaptation handlers. Figure 12 illustrates the ripples caused by evolution for the Visitor pattern.

Figure 12: Ripples due to interface change visitor example

Each extension of the visitor interface by a new visitable class results in modifica- tions of all existing concrete visitors. In this case the visitors are the concrete executor components of the control loop architecture. All concrete executors must make the new method to visit the new visitable class concrete. This means all concrete executor classes suffer from the introduction of newly introduced visitable classes.

Figure 13: Scenarios for introducing new events.

All concrete monitor, analyser and planner components suffer from the introduction of newly introduced observable components. They must implement the new event handlers defined by the respective interfaces. The new event handlers influence the planner class the most, the state space must be extended by new events and actions (adaptations). The scenarios to introduce new events in this case study are given in figure 13. New events can affect existing transitions (figure 13(a)) but they also can form new transitions to new states (figure 13(b)). Another option is a transition from a new state to an existing state (figure 13(c)). A final possibility is that a new event forms a transition from one existing state to another existing state. This option is not shown in figure 13 because it is unlikely to happen; only if the initial state space was incomplete or badly modelled this option is possible. We do not consider this scenario as evolution impact but as a result of poor design of the state space.

Figure 14: Introduction of new states and events.

State space evolution of the planner leads to rewriting the state space context. The generic impact of state space evolution is shown in figure 14. New state fields and event handlers must be introduced to existing contexts. New event handlers affect the context interface. In our case the planner class is the context; therefore new event handlers must be added to the planner interface. This means that every concrete planner must make the new event handler concrete.

All MAPE-K components suffer from evolution; the Monitor, Analyser and Planner components suffer from the introduction of new events handlers, whereas the Executor class suffers from the introduction of new adaptation handlers. If we look at the control loop design as a whole as depicted in figure 15 it can be seen that it almost breaks down completely after energy is introduced.

As can be seen in figure 15, all control loop components are affected when energy- awareness functionality is introduced. Interface changes force concrete classes to make new events or adaptation handlers concrete.

Conclusion The main problems the OO design suffers from are all related to the in- troduction of new events. The base system must be adapted to be able to notify the event to the control system. The control system interface needs modification with each newly introduced event. New events lead to state space evolution of the planner class of the control loop architecture. State space evolution results in rewriting the state space context. New states apply new forms of adaptation through the Visitor pattern. New visitable base system classes must accept visitors and the visitor interface must be extended with a handler for each of these classes.