In this paper, we describe evolution problems of typical software, concentrating on history sensitivity. We start with a basic Object-Oriented design for a simple game. Then, history sensitivity problem is introduced gradually as evolution scenarios. If two different history sensitivity concerns are semantically related, the problem of orthogonally restricting aspects occurs. We elaborate on several solution approaches, namely object-oriented design approach, aspect-oriented design approach, and composition of events and actions approach to tackle the history sensitivity evolution problems in a modular and reusable manner.
Software systems are not static. They continuously evolve. In due time bugs are corrected and new features are added. Software systems have to cope with evolution. In order to cope with evolution various programming languages were introduced. They provided mechanisms to provide several quality factors such as reusability, reliability, maintainability, etc. For example, introducing “class” concept in objectoriented programming (OOP) enabled higher reusability. The mechanisms like inheritance and polymorphism in the object-oriented programming languages provided higher reusability and maintainability. But, the usage of these languages for years showed that existing mechanisms and hierarchy in the object-oriented programming may cause some side effects that decrease the modularity of the software systems.
The aim of evolution is to implement new changes. But, the new software may not be final and may continue to evolve. During evolution process, many features might be added to the current software due to new requirements. The new features to be added may require changes in the design and can cause side effects. As the software evolves the complexity of it grows unless there is a better solution available to solve these issues.
Preserving design modularity is another important issue. It is preferable that software is resilient to possible evolution. If the design is not modular, implementing several quality factors such as reusability and maintainability might be difficult in the evolution scenarios. In order to cope with evolution the system shall be decomposed into proper modules. If the modularity is not proper than the complexity may increase and evolution may require a lot of work.
Also, some features are difficult to add. For example: Adding history sensitivity. Generally, adding history sensitivity results in redefinitions. Also it may cause changes in software design. If you add several history sensitive objects the number of redefinitions increases. The problem becomes even worse if multiple history sensitive extensions somehow affect each other.
Usually, adding history sensitivity with OOP requires many redefinitions and results in tangling and scattering. Then, reusability and maintenance of the software becomes a problem in the future evolution scenarios.
Aspect Oriented Programming (AOP) languages can be used to implement history sensitivity in evolution scenarios. Using the AOP one can try to overcome difficulties faced within the object-oriented languages such as redefinitions. If the aspects can be defined independently, AOP might be a modular solution. However, in the case of semantically related (orthogonally restricting) aspects, AOP may also result in tangled and scattered code.
Composition Filter Model (CFM) and Events, Actions, and Composition Model (EACM) can be used to overcome tangling and scattering problem. EACM is an extension to CFM. CFM aims to provide better modularization and composition mechanisms with respect to object-oriented methodologies. In CFM method calls are processed by filters which are grouped as filter modules. A superimposition selector chooses a set of classes. A query language (such as Prolog) can be used to construct special filters and these filters can be applied on modules.
EACM is an extension of CFM introducing event filters, action filters, and highlevel events. On contrary to event filters, action filters have side-effects on programs. Both of these filters may trigger high-level events as the result of their computation. Than these high level events can be processed by high-level filters. These mechanisms provide a hierarchy of events and filters such that resulting filters and filter modules are parametric.
In this paper we investigate the effects of adding history sensitivity to computer software that is already developed with the object-oriented methodology. As the case study we worked with a simplified computer game. We assumed that the computer game does not have any history sensitive features initially. Our first evolution scenario is adding history sensitive features to the current game. Then we assumed that these history sensitive features affect each other. In both cases we tried to investigate the effects of history sensitivity. We try to find solutions to avoid tangling and scattering in the evolution scenarios at the same time trying to minimize the number of redefinitions. We would like to evaluate modularization and composition techniques to provide better concepts and mechanisms to separate concerns suitably.
The paper is organized as follows. Section 2 defines the object-oriented design of our case without history sensitivity. In Section 3, the problem statement is given in detail. We add history sensitivity to the object-oriented model and investigate the effects of it. We first discuss the required redefinitions in the Object-Oriented model. Then we investigate the problem when Aspect Oriented Programming is used comparing the number of redefinitions. We discuss the orthogonally restricted aspects if the aspects do affect each other. In Section 4, the notion of state machine design for composing several concerns is given. In Section 5, our solution approach for orthogonally restricting aspects problem is explained. We summarize the related work in Section 6. In Section 7, we evaluate the presented design approaches. Finally, section 8 concludes the paper.
We defined a simplified computer game to illustrate the problems. The case study is a war game consisting of vehicles, weapons, and buildings, each of which has specific behavior to perform the scenarios given below.
Player moves a vehicle. Player fires a weapon to destroy the buildings. Vehicle is destroyed if it hits a building.
Object-oriented design of the war game that realizes the above scenarios is given in Fig. 1. For instance, Vehicle class shown in the figure encapsulates the following behavior. Its move methods update the position of the Vehicle by updating xPosition and yPosition attributes. When a Vehicle is shot, shot method is called and its isShot attribute is set to true. We assume that after the Vehicle is shot, it cannot move. The following code snippet shows an example implementation of Vehicle class. public class Vehicle { private int xPosition = 0; private int yPosition = 0; private boolean isShot = false; public void moveUp() { if (isShot == false)
// update position in the up direction } } } } public void moveDown() { if (isShot == false)
// update position in the down direction public void moveLeft() { if (isShot == false)
// update position in the left direction public void moveRight() { if (isShot == false)
// update position in the right direction public void shot() {
isShot = true; }
}
After the first version of the game is released, following evolution scenarios are required to be implemented in the next versions of the game. According to evolution scenarios, history sensitivity is added to the game for graceful degradation. Wear/tear of systems is introduced as given below.
Vehicle runs out of fuel (fuel history): When a vehicle moves, its fuel level decreases. If there is no fuel, the vehicle cannot move. Vehicle is destroyed gracefully as it gets shot (damage history for vehicle): Vehicle has a damage level and is destroyed gradually. If it touches the buildings, the damage level of the vehicle increases. If the damage level reaches its maximum value, its isShot attribute is set to true. Weapon runs out of battery (battery history): Weapon has a battery and as long as the user fires the weapon, the battery level decreases. If there is no energy left in the battery, weapon cannot fire. Building is destroyed gracefully as it gets shot (damage history for building): Buildings have damage levels as well. If a building is shot, the damage level increases. If damage level of the building reaches its maximum value, its isShot attribute is set to true.
These evolution scenarios have consequences to the operational behavior of the software. In the following section, the problems that arise due to reimplementation of the initial design, realizing the evolution scenarios, are discussed.
In the next version of the game, it is required that history sensitivity information is added to the game as described in the previous section. First, basic object-oriented design techniques are used to update the initial design. Then, aspect-oriented design approach is considered without changing the initial OO design. These approaches and the problems of them are discussed in the sequel.
First, we investigate the object-oriented techniques for adding the history sensitivity to our initial design. Generalization is one of the OO techniques that can be used to evolve each of the related classes according to the given evolution scenarios. Fig. 2 shows the updated design.
Although, existing classes of the initial OO design can be re-used by generalization, most of the methods of the super class have to be redefined. For instance, move methods of Vehicle class must be re-implemented by VehicleWithFuelHistory class as shown in the following code snippet. Before related move method of Vehicle class is called, fuel level must be controlled. If there is enough fuel for movement, then the related move method of Vehicle is called. Otherwise, (if there is no fuel) the related move method is not called.
public class VehicleWithFuelHistory extends Vehicle { // set the fuel level to its maximum private int fuelLevel = 100; public void moveUp() { if (fuelLevel > 0) { // call moveUp method of Vehicle super.moveUp(); // decrease fuel level fuelLevel = fuelLevel – 1; }
} }
Damage history can be added to vehicle in a similar way. A new class, called VehicleWithDamageHistory is inherited from VehicleWithFuelHistory as shown in Fig. 2. This inheritance has the same problem: in order to add damage history we should redefine move methods of VehicleWithFuelHistory class and the shot method of Vehicle class. Similarly, damage level must be controlled before the related move method of VehicleWithFuelHistory class is called. If damage level is not equal to its maximum then the related move method is called. Each shot increases the damage level. While the damage level is less than its maximum, shot method of Vehicle class is not called. If damage level reaches its maximum, shot method is called and isShot attribute is set to true. After isShot attribute is set to true, vehicle cannot move. The following code illustrates an example implementation of VehicleWithDamageHistory class.
public class VehicleWithDamageHistory extends VehicleWithFuelHistory { private int damageLevel = 0; private static int MAX_DAMAGE_LEVEL = 10; public void moveUp() { if (damageLevel < MAX_DAMAGE_LEVEL) { // call moveUp method of VehicleWithFuelHistory super.moveUp();
Redefinition problem also exists for WeaponWithBatteryHistory and BuildingWithDamageHistory classes. fire and shot methods have to be redefined in WeaponWithBatteryHistory and BuildingWithDamage classes, respectively. The number of redefinitions introduced by the evolution scenarios in the OO design is given in Table 1.
Until now, we assumed that the introduced history sensitivity features do not affect
each other. Now, assume that some of the defined history sensitivity features are
semantically related. For instance, fuel and damage history can affect each other such
that damage level changes fuel consumption rate and fuel level changes damage rate.
Fuel consumption rate and damage rate are defined as 1 in the previous code snippets.
As an OO technique, multiple inheritance can be applied as stated in [
In this section, aspect-oriented design techniques are investigated to solve the redefinition problem. For each of the evolution scenarios, a new aspect is defined. BuildingDamageAspect and VehicleDamageAspect are introduced to add damage history to the Building and to the Vehicle classes of the base design, respectively. VehicleFuelAspect is defined to add fuel history to the vehicle class and WeaponBatteryAspect is defined to add battery history to the weapon class. These aspects are illustrated in Fig. 3.
VehicleDamageAspect and VehicleFuelAspect are defined in the following code snippets. Moreover, OrderingAspect have to be defined to declare the precedence ordering between these two aspects since both of them catch the same join points which are calls to the move methods.
public aspect VehicleDamageAspect { private int damageLevel = 0; private int MAX_DAMAGE_LEVEL = 100; pointcut triggerShot(): call (* Vehicle.shot(..)); void around(): triggerShot() { } } } }
} } damageLevel = damageLevel + 1; if (damageLevel > MAX_DAMAGE_LEVEL) proceed(); Using aspect-oriented techniques instead of object-oriented techniques solves the redefinition problem. Considering the aspects described above, the number of redefinitions vanishes as given in Table 2. Note that, each aspect is considered as a new class.
When the OO design and the AO design approaches are compared with respect to the number of redefinitions, AO design seems superior. We see that AO approach solves the redefinition problem if the aspects are semantically unrelated, where aspects do not affect each other. However, AO approach may also have problems if they are semantically related, or in other words, orthogonally restricting aspects, as discussed in the following section.
If several aspects are defined independently and affect each other semantically, we
call this problem orthogonally restricting aspects anomaly. This definition is adopted
from orthogonally restricting specifications, which is defined in [
According to this scenario, VehicleDamageAspect and VehicleFuelAspect affect each other semantically. Fuel Level (FL) must be adjusted considering the Damage Level (DL) of the vehicle, that is fuel consumption rate (FCR) increases proportionally with damage level. Damage level of the vehicle is adjusted considering the fuel level of the vehicle, that is Damage Rate (DR) increases as fuel level increases. The interrelation between the two orthogonally restricting aspects are shown in Table 3.
We can define only one aspect to control both damage and fuel. This aspect has two new attributes for damage rate and fuel consumption rate. When fuel level is updated, damage rate is also updated according to fuel level. Similarly, when damage level is updated, fuel rate is also updated according to damage level. This approach has three drawbacks. The first drawback is that, two different concerns (damage and fuel) are defined in the same aspect so tangling occurs. The second one is that it does not use previously defined two aspects so it is not a modular extension. The last drawback is that, long if-else blocks are used to update fuel rate and damage rate as shown in the following code snippet: public aspect VehicleDamageFuelAspect { private int damageLevel = 0; private int MAX_DAMAGE_LEVEL = 10; private int damageRate = 1; private int fuelLevel = 100; private int MIN_FUEL_LEVEL = 0; private int fuelRate = 1; pointcut triggerShot(): call (* Vehicle.shot(..)); void around(): triggerShot() { damageLevel = damageLevel + damageRate; // update the fuel rate according to damage level updateFuelRate(); if (damageLevel > MAX_DAMAGE_LEVEL) proceed(); } } } } } … } } } … // update the damage rate according to fuel level updateDamageRate(); if (fuelLevel > MIN_FUEL_LEVEL) proceed(); void updateFuelRate() { if (damageLevel >= 8 && damageLevel < 10) {
// update fuel rate according to this condition } else if (damageLevel >= 6 && damageLevel < 8) {
// update fuel rate according to this condition
We have introduced the problem of orthogonally restricting aspects, where Fuel Aspect and Damage Aspect are co-related in the previous sections. These two aspects have to be composed in a modular way for re-use, to implement the history sensitivity concern. We have discussed that such a modular composition is not possible. A logical solution that comes to mind is to write a new aspect that implements both damage and fuel history sensitivity concerns. This approach causes more and more tangling with if-else statements to express these concerns in the same aspect.
Here, we argue that one can try to remove the undesired if-else blocks for different concerns using a state-machine in the new aspect, toward a more flexible and reusable design. In the sequel, we discuss that this is not a proper solution for orthogonally restricting aspects problem. However, it helps us recap the notion of events and actions, and introduce a different way of separation and composition of concerns.
Considering our case, we tackle the tangling problem of the new aspect by building
a state-machine as in Fig. 4. Instead of checking the damage level in fuel aspect, or
checking the fuel level in damage aspect, we use this state machine with the events
“move” and “shot” that trigger the actions to be taken in the states. Such a state
machine can be implemented as a finite state machine (JavaFSM) or a regular
expression (JavaERE) facilitated by JavaMOP [
stm stateDiagram Game Start «V=7» D3F3 [shot] «V=4» D2F3 [shot] «V=1» D1F3 [move] [move] [move] «V=8» D3F2 [shot] «V=5» D2F2 [shot] «V=2» D1F2 «V=9» D3F1 [shot] «V=6» D2F1 [shot] «V=3»
D1F1 [move] [move] [move] [shot]
[shot] Fig. 4. State-machine, events and actions. [move] [move] [move] [shot]
Game Over
In our case, damage level influences fuel consumption rate and the fuel level influences the damage rate. Thus, the effects of “move” and “shot” events, as given in Fig. 4, are not independent. That is, the current state “D3F3” has to be changed to the next state “D3F1” when a “move” event happens since the damage level is high and the vehicle consumes more fuel when it moves. Similarly, we have to by-pass the state “D2F3” when a “shot” event occurs in state “D3F3” since the vehicle gets more damage when fuel level is high. In such an orthogonally restricting events-actions case, the state-machine solution is not well-structured, hence not scalable. Furthermore, the number of states may explode if higher resolution is required or more dimensions are introduced.
In the next section, we discuss a modular solution approach based on the events and the composition of the events that trigger the corresponding actions. 5
In the previous section, we discussed AOP and the state-machine approaches which work only if the concerns are independent. However, for the orthogonally restricting aspects problem, neither presents a modular or re-usable extension mechanism. In this section we present a modular extension framework that tackles the conflicting aspects problem.
Composition of events has been introduced in [
Action1
Action2
Action12 e1 event1
e2 event2
e1&e2
If we consider our case, game with history sensitivity problem, event1 and event2
stand for the move() method and shot() method calls. Respectively, action1 and
action2 stand for modifying the FuelLevel and the DamageLevel. The composition of
semantically related concerns are discussed further in [
The composition of events and actions approach is extensible, where further events
are defined on top of the actions. This approach is based on event-action-composition
model (EACM) presented in [
As explained in the previous sections, damage level affects fuel level and fuel level affects damage level. These effects can be expressed by writing long if-else structures or by introducing new variables. For our case, two new variables are introduced. Fuel consumption can be added as a new variable. While a vehicle moves, it decreases its fuel level according to its fuel consumption. In the initial version of the game, there is no fuel level. In the next version of the game, fuel level history is implemented but it is not affected by damage level such that each move operation decreases the fuel level by 1. Actually, each move operation decreases the fuel level by fuel consumption at that time. If we introduce a new variable called FuelConsumption and this variable is used directly in move operations, the only remaining problem is setting the fuel consumption. Damage level affects the fuel consumption. Damage level is changed when shot operation is called. When damage level changes, fuel consumption should also be changed. Damage rate can also be added as a new variable. While a vehicle is shot, it increases its damage level according to its damage rate. In the initial version of the game, there is no damage level. In the next version of the game, damage level history is implemented but it is not affected by fuel level such that each shot operation increases the damage level by 1. Actually, each shot operation increases the damage level by damage rate at that time. If we introduce a new variable called DamageRate and this variable is used directly in shot operations, the only remaining problem is setting the damage rate. Fuel level affects the damage rate. Fuel level is changed when move operation is called. When fuel level changes, damage rate should also be changed.
Action11: Update DR e11:FL is set
Action1: FL=FL-FCR e1:move() is called
Action21: Update FCR e21: DL is set
Action2: DL=DL+DR e2:shot() is called
This scenario shows that actions can cause other events and these events results in other actions. Fig. 6 illustrates this case.
Event1: move operation is called Action1: FuelLevel is decreased by FuelConsumptionRate Event11: Changing the FuelLevel Action11: May change DamageConsumptionRate Event2: shot operation is called Action2: DamageLevel is increased by DamageRate Event21: Changing the DamageRate Action21: May change FuelConsumptionRate
In [
Although Object Oriented Programming (OOP) solves many problems of
Procedure Oriented Programming (POP), many OOP techniques are not sufficient to
capture some of the important design decisions that the developer must implement
bringing scattered and tangled code [
Aspect Oriented Programming (AOP) is a methodology to improve the modularity
of the software when the software has crosscutting concerns. AOP claims that change
from POP to OOP is not complete and programmers need more dimensions [
AOP may solve many problems related with the object oriented programming.
AOP aims to make the design and the code more modular. This means localizing
concerns instead of scattering them. But on the other hand, superimposing aspects on
software modules may cause side effects. New techniques are required to cope with
this problem [
In [
Akşit et. all [
Composition Filters (CF) uses the conventional object model and considers an
object as an entity that performs some assigned functions [
Events, Actions, and Compositions Model (EACM) is introduced as an extension
to Composition Filter Model (CFM). In this model event filters and action filters are
introduced both of which can trigger higher level events. Since filters and filter
modules can be parametric they can be passed as arguments. The E-Chaser language
is proposed to adopt EACM. Events, actions, and compositions are the first class
linguistic constructs in this language. E-Chaser can be used in implementing runtime
enforcement systems. Although it is based on CFM, E-Chaser provides dedicated
constructs to define filter modules, filters and superimposition selectors which are
defined as Prolog rules. Since it is possible to develop generic filter modules using
parametric filter modules and filters, the codes can be evaluated free of tangling and
scattering enabling software reuse and maintainability [
First, we evaluate object-oriented extension. We investigate OO techniques for
adding history sensitivity to our initial object-oriented design in Section 3.1.
Generalization technique is applied to re-use the previously developed classes.
However, it is shown that generalization causes many redefinitions. As given in Table
1, 11 methods have to be redefined when 4 new classes are added. If we further
assume that the added history sensitivity features affects each other, then the problem
gets even worse. As an OO technique, multiple inheritance can be applied as stated in
[
In order to overcome redefinition problem, AOP techniques are investigated. Each new history sensitivity feature is defined as a new aspect instead of inherited classes. If these features are semantically unrelated, redefinition problem is solved by AOP. As shown in Table 2, AOP causes no redefinitions. However, if we assume that if some of the introduced features affect each other, a new problem called orthogonally restricting aspects problem occurs. If we define all semantically related history sensitivity features only as one aspect, several drawbacks occur such as tangling and long if-else blocks.
State machine based approach requires defining the each case as a new state,
instead of writing long if-else blocks. State machines can be implemented by OO
design or AO design. A state machine can also be written as a separate specification
as stated in [
Our proposed solution to overcome orthogonally restricting aspects anomaly is
based on event compositions and events on actions [
Evolution of software is irresistible. Main problem is how to design a software system that is flexible to accommodate the required extensions, minimally altering the base design. This flexibility is not possible with the existing object-oriented design methods since concerns or aspects cannot be expressed as first class entities in OOP. A better solution is to have modular extension mechanisms that do not tangle the base code, and that supports reliable integration of the new modules.
In this paper, we considered history sensitivity problem that is introduced on top of an existing object-oriented solution for a simple game. First, it is shown that objectoriented design techniques cannot undertake the history sensitivity based evolution scenarios without redefining the original code. Then, an aspect-oriented solution for modular adaptation of the evolution scenarios is given. As more scenarios are introduced, the problem of orthogonally restricting aspects occurs. Aspect-oriented solution loses its modularity and reusability, causing further tangling and scattering, hence breaking the principle of separation of concerns due to the mixed structure of events (pointcuts) and actions (advises) in the aspects.
As a modular and reusable extension mechanism, a state-machine approach is investigated in order to implement several concerns in the same module (aspect). State-machines do not provide standard extension mechanisms when new concerns are added as new dimensions of events and state. However, if such extensions grow in a well-structured way, regular expressions or finite-state automata can be used for extensions, reusing the original state-machine design.
Finally, the idea of separation of events and actions is discussed where events and actions are defined independently. Composition of events that trigger corresponding actions, and events on actions methods are discussed as a modular and more reusable way of supporting unavoidable evolution requirements.