As mentioned in Sect. 2.2, we classified interactions using the taxonomy de- scribed by Sanen et al. (conflict, dependency, reinforcement and mutex). Based on our previous experience implementing software for SMs, we observed the exis- tence of these aspect interactions between the concerns identified in our domain. For example, there is a conflict between the Demo and Meters concerns, since Meters works correctly without Demo, but if Demo mode is active, activity in the machine must not be counted by Meters. An example of mutex is in the communication protocols: it is forbidden to have two protocols providing the same functionality at the same time. A dependency example is the relationship between Communications and Meters; the protocol needs to communicate the status of the SM, which is in part represented by the meters. Finally, a reinforce- ment is present between Error Conditions and Communications. The existence of error condition detection enables communication protocols to provide “extra” functionality, in this case real time error condition reporting.
Understanding how concerns interact with each other is key information that needs to be passed to designers and programmers. For example, in the case of
3.8. INTERACTIONS 33
a dependency, the dependent concern will be affected by design decisions upon the other. On the other hand, if there is a mutex relationship, architectural mechanisms should be provided to ensure that both concerns (or parts of them) will not be active at the same time.
Figure 3.4: Concern interactions in an ad-hoc notation. Regular arrows indicate crosscutting, dashed arrows indicate interactions between concerns, tagged with UML-like stereotypes.
Considering the concern division and the associated requirements, we have deduced the relationships between different concerns and identified their inter- actions. A representative selection of these is shown in Fig. 3.4, which uses an ad-hoc notation where Game is the base concern (represented by a square) and crosscutting concerns are represented by ovals. Different arrows are used to indicate crosscutting and interaction relationships. More in detail, the cross- cutting relationships are as follows:
1. Demo to Game: The demo requirements affect many of the definitions of the original requirements of Game in order to alter the Game’s behavior for testing purposes.
2. Game Recall to Game: Game Recall requirements affect many aspects of the Game’s behavior, it is used to log the activity for each play and other relevant events in order to solve disputes.
3. Meters to Game: Meters count activities of many functions defined in Game, for instance: game play, bill in, cashout, etc.
4. Program resumption to Game, Game Recall, G2S and Meters: Program resumption is analogous to persistence. It crosscuts all the places where important data, which needs to be restored, is changed.
5. G2S to Game: This concern cuts across many Game requirements, since several events in Game need to be reported, monitored and communicated to the reporting system.
6. SCP to Game: This refers to the other protocol used to monitor the game’s behavior.
7. Error Conditions to Game: The behavior associated with error conditions need to be woven into the game behavior. Requirements in Game that could raise an error condition vary: from a bill jam to a door opened. The are many interactions between these concerns. We highlight the the following:
8. Conflict between Demo and Program Resumption: The demo mode fires fake events that must not be counted nor restored after program interrup- tion.
9. Conflict between Demo and G2S : both concerns cannot be active at the same time because demo fires events that must not be reported to the monitoring system. The same conflict exists forbidden Demo and SCP, it is not added in the diagram to avoid clutter.
10. Dependency of G2S and SCP on Meters: Some data reported to the monitoring system is stored or can be derived from meters. Hence, commu- nication protocols need the meters to be up to date in order to accomplish their purpose.
11. Reinforcement of G2S with Error Conditions: As we discuss in Sect. 5.2.2, some parts of the G2S protocol are not mandatory for specific instances. When error conditions are tracked in the game, additional behavior is made available in G2S such as particular parts of real time event report- ing functionality.
12. Mutex between G2S and SCP : There is overlapping functionality defined in the requirements of both protocols. Recall that backends can configure the SM remotely (see Sect. 3.5). For example, both of them are used to keep the time in sync between the SM and the monitoring system. Having both protocols active, with monitoring systems out of sync, would render the time of the SM inconsistent. Therefore they cannot be active at the same time.
13. Conflict between Demo and Meters: Meters must not be affected by activity in Demo mode.
14. Reinforcement of SCP with Error Conditions: it is similar to 11, ad- ditional behavior in SCP is available when new error conditions are sup- ported.
This is only a selection of some representative interactions. There are many more that we do not include in Fig. 3.4 nor talk about in detail. For exam- ple: G2S and SCP depend on GameRecall as both protocols require to retrieve information of the last plays, and Program Resumption crosscuts SCP for the same reason as it crosscuts G2S. We effectively selected just one case of each interaction type to keep the discussion focused.
3.9. SUMMARY 35
3.9
Summary
In this chapter we have succinctly described the relevant characteristics of the domain in order to illustrate the intrinsic complexity of this kind of software. The concerns found on this domain are:
• Game • Meters • SCP Communication protocol • G2S Communication protocol • Game Recall • Program Resumption • Demo • ErrorConditions
Some of them are base concerns and others are crosscutting. These concerns present a number of interactions which can be classified according to Sanen et al.. [74] into: mutex, reinforcement, dependency and conflict. We selected the following interaction instances for this work:
• Conflict between Demo and Meters, Game Recall, Program Resumption and Communication protocols
• Dependency of Communication Protocols (SCP and G2S) on Meters. • Reinforcement of Error Condition on SCP and G2S communication pro-
tocols.
• Mutex between configuration features SCP and G2S communication pro- tocols.
These interactions have considerable impact on the game behavior. In our experience not having proper mechanisms for handling them has been the source of costly bugs in the past. Therefore, in the remainder of this work, we analyze how these interactions can be handled in each stage of the development cycle and how information about them can be traced along the development process.
Chapter 4
Interactions in Analysis
This chapter is based on our previously published work Express- ing aspectual interactions in requirements engineering: Experiences, problems and solutions [97].The first step in software development consists of understanding what the software should do. The input for this are system requirements. Requirement engineering is the process that produces the initial documents and models which are used as the basis for design and implementation. Therefore, we need to start modeling with requirements, concerns and their interactions.
This chapter presents requirement engineering with emphasis on the model- ing of aspect interactions. The following section provides details on the require- ments for SMs, and how two specific AORE approaches support the peculiarities of the SM requirements. In addition, it also presents the extensions we made to these approaches in order to handle SM requirements effectively and the experiments performed to validate their applicability.
The chapter is organized as follows: Sect. 4.1 presents an overview of AORE from the aspect dependencies and interactions perspective. Sect. 4.2 goes in more detail on the slot machine requirements and some relevant characteristics of their sources. The evaluated AORE approaches and the evaluation output are presented in Sect. 4.3, including the limitations found for each approach. In Sect. 4.4 we propose extensions to the original approaches in order to cope with the limitations found. Sect. 4.5 describes a user study carried out in order to validate the expressiveness of the extensions performed to MDSOCRE. Sect. 4.6 concludes the chapter. Two appendixes, (A and B), at the end of this thesis contain the complete models we produced for this stage, showing the results of applying the extensions to our setting.
4.1
Requirements Engineering and Aspect De-
pendencies and Interactions
In the requirements engineering community, interactions between requirements are a well-known (intra) traceability problem [67]. In the AOSD community, and hence when applying AORE techniques, this problem maps to what is known as dependencies and interactions with aspects [17]. Dependency and interaction
support is still an open issue for the AOSD community. Therefore, the focus of our work lies in assessing the support for expressing interactions between aspects or concerns, which, depending on the point of view, can be considered either a requirements traceability problem or a problem of dependencies and interactions with aspects.
Non-functional requirements approaches support conflict resolution, provid- ing algorithms to find the best trade-off for the stakeholders [24]. In these approaches, some requirements are not completely satisfied, in favor of other more relevant ones (according to contribution analysis). In our domain how- ever, all of the requirements need to be fulfilled (none can be discarded), and their fulfillment is verified during the certification process (see Sect. 3.6). In- stead of removing requirements, we need to deal with conflicts by not allowing the activation or execution of conflicting features during a single system run. In addition to this, it is interesting to note that most of our interacting cross- cutting concerns are functional ones. In conclusion, typical non functional requirements (NFR) approaches are not applicable in our scenario.
We elected to perform requirements engineering using two of the approaches presented in Sect. 2.2.1: The Theme/Doc approach [9] and the Multidimen- sional Separation of Concerns for Requirements Engineering (MDSOCRE) ap- proach [60], focusing on how these allow us to express and document aspectual dependencies and interactions. The choice of these two approaches was based on our perception of their maturity and of their acceptance in the AORE com- munity.
More concretely, Theme/Doc was selected, not only by its publication record, but also because a book is available that describes at a detailed level its appli- cation to a arguably complex example (which also demonstrates some degree of scalability) [26]. Moreover, it also discusses later phases of development, for ex- ample how to deal with conflicts in design documents when using Theme/UML. MDSOCRE was selected because it claims to explicitly support conflict resolu- tion and because of its flexibility due to the action/operator approach (discussed in more detail in Sect. 4.3.4) that allows us to express more than just crosscut- ting relationships.
Both of the approaches we evaluated enable us to partially express the re- quirements, but neither of them was entirely satisfactory. Theme/Doc lacks support for the kind of interactions we want to model, e.g. conflicts between aspects, and needs a finer granularity for expressing crosscutting relationships. MDSOCRE lacks explicit support for expressing interactions between concerns when they do not cross-cut each other. In this chapter, in addition to describing these drawbacks in more details, we also elaborate and validate extensions that address these issues. We propose new kinds of relationships to Theme/Doc for documenting interactions, and add new interaction information in MDSOCRE.