ANÁLISIS DEL SISTEMA ARQUITECTÓNICO

20 return null;

21 }

The difference between PHANtom and AspectJ based implementations for conflict are inherent to the dynamic vs. static features of each language. For this kind of conflict, it is necessary to unweave, or remove some aspectual func- tionality. If the implementation aspect language or platform does not allow for this, it is necessary to implement a workaround that simulates this “unweav- ing” feature. The Demo aspect captures conflicting aspects advices, so that their behavior can be skipped when Demo mode is enabled.

The result of this limitation in AspectJ is that aspects are installed even though they are not actually active. This is the case of our Demo aspect during a production run and Meters, Communcation Protocols, Program Resumpton and Game Recall during a demo run.

Alternatively, for static aspect oriented languages, another possibility is to have different “builds” of the system. Each build is an instance of the system containing a sound set of aspects. In this way a demo game will not contain, for example, a Program Resumption weaved into the system.

In our experience, certification laboratories requiere the sources and instruc- tions for the build, both in demo and production modes.

In AspectJ, aspects can be weaved in load time. In this case, a configuration file defines which aspects are weaved before the classes are loaded into the system. This allows to building a Demo configuration, which could exclude conflicting aspects, or a production build without Demo functionality.

Note: the last two alternatives require restarting the system in order to run in demo mode. These alternative also may seem fishy from the certifaction laboratory point of view.

6.4

On the Generic and Explicit Interaction Sup-

port

From our implementation experience, we observe that interaction implementa- tion is tangled with the functionality of our crosscutting concerns. For example, consider the case of the Demo aspect. It on the one hand, adds its core func- tionality (change the outcome of the SM), but on the other hand, it is also responsible for avoiding the execution of other aspects, such as G2S, program resumption or Game Recall. In fact, there is no clear way to distinguish the core functionality of the Demo aspect from interaction implementation. That is to say, interaction implementation is quite implicit. It can be argued that implementing the conflict resolution behavior in a separate aspect is a trivial improvement, but it is necessary to consider that adding conflict resolution in this way adds an extra dependency as our Demo aspect will depend on the existence of the conflict resolution aspect.

Besides the maintainability and evolvability problems this could pose, im- plicit information regarding interactions hinder other tasks such as testing. For example, consider the case of the dependency of G2S on Meters. If the Metering aspect is not correctly deployed, the G2S aspect will offer incon- sistent data to the server. At the testing phase, testers will connect this SM with a server, play and then observe that the SM keeps reporting wrong data.

This problem goes back to the programmers in the form of: “the SM reports incorrect data” bug report. At this point, some possible sources of this problem are:

1. The Metering aspect is not capturing (all) the relevant events (such as play). This happens if it was not deployed, among other possible causes. 2. The G2S protocol for some reason reports incorrect meters, for instance,

it takes the values from the wrong meters.

3. There is a bug in serialization so that meter values arrived corrupted. If the dependency is somehow made explicit in the code, the system would be able to give a warning announcing that the Metering aspect could not be deployed. The system then is able to stop the execution or continue but without G2S support. In this way, a lot of time is saved on testing and debugging. The same idea can be applied to semantic conflicts. If they are explicitily declared the weaver (at compile or run tinme) can raise an error indicating that incompatible behavior is being composed into the system.

These two implementations of interactions presents another drawback: each interaction resolution strategy has been implemented in an ad hoc manner. This lack of generality makes it harder to reuse previously applied solutions. We consider this not a major problem, as more interactions implementations need to be studied before a useful generic implementation can be written.

To summarize, the implementations lacks explicit information regarding in- teractions, it is not possible for the system to check if the system is consistent or not.

6.5

Discussion: PHANtom VS. AspectJ Imple-

mentation Results

In this section we summarize the significant differences and similarities found while implementing the interactions with the selected programming languages. Table 6.1 presents an excerpt of the comparison between both implementations. Table 6.1: Comparison of interaction implementation done using AspectJ and PHANtom.

Interaction PHANtom AspectJ

Dependency Reference + deploy check Reference + deploy check Reinforcement Ad-hoc logic (+ null ob-

ject)

Inter-type declaration forces considering rein- forcement

Mutex Dedicated aspect + inter-

ception of the JP

Dedicated aspect + inter- ception of the JP

Conflict Run-time (un)weaving +

interception

Ad-hoc (de) activation logic

6.5. IMPLEMENTATION RESULTS 105