Does aspect-oriented modeling help improve the readability of UML state machines?

Abstract

Aspect-oriented modeling (AOM) is a relatively recent and very active field of research, whose application has, however, been limited in practice. AOM is assumed to yield several potential benefits such as enhanced modularization, easier evolution, increased reusability, and improved readability of models, as well as reduced modeling effort. However, credible, solid empirical evidence of such benefits is lacking. We evaluate the “readability” of state machines when modeling crosscutting behavior using AOM and more specifically AspectSM, a recently published UML profile. This profile extends the UML state machine notation with mechanisms to define aspects using state machines. Readability is indirectly measured through defect identification and fixing rates in state machines, and the scores obtained when answering a comprehension questionnaire about the system behavior. With AspectSM, crosscutting behavior is modeled using so-called “aspect state machines”. Their readability is compared with that of system state machines directly modeling crosscutting and standard behavior together. An initial controlled experiment and a much larger replication were conducted with trained graduate students, in two different institutions and countries, to achieve the above objective. We use two baselines of comparisons—standard UML state machines without hierarchical features (flat state machines) and standard state machines with hierarchical/concurrent features (hierarchical state machines). The results showed that defect identification and fixing rates are significantly better with AspectSM than with both flat and hierarchical state machines. However, in terms of comprehension scores and inspection effort, no significant difference was observed between any of the approaches. Results of the experiments suggest that one should use, when possible, aspect state machines along with hierarchical and/or concurrent features of UML state machines to model crosscutting behaviors.

Appendices

Appendix A: Models for elevator control system (ECS)

In this Appendix, we provide the description and models for one of the case studies that we used in the replication: the Elevator Control System (ECS). Note that we provide this information only for one crosscutting behavior EmergencyCall (Call) of ECS, to provide an idea of how the models developed using different modeling approaches look like and to demonstrate that these models are semantically equivalent. The crosscutting behavior EmergencyCall is an important robustness behavior of an elevator. Whenever the elevator is operating, an emergency call can be made at any time. When a call is made, it is dialed to the control room and if the call is successful, the person in the elevator can talk to a person in the control room. When the person in the elevator is done talking, he/she can disconnect the call from the control room. Notice that all these operations related to the emergency call are performed concurrently to the operation of the elevator. All the diagrams used in the experiments and shown in Figs. 3, 4, and 5 were drawn using IBM Rational Software Architect (RSA) [48] and therefore, the diagrams conform to the RSA graphical notations. In addition, the experiment participants were trained to understand these graphical notations.

Fig. 3

Base state machine for ECS

Fig. 4

Aspect state machine for EmergencyCall

Fig. 5

EmergencyCall modeled with the Hierarchical approach

The base state machine of ECS is shown in Fig. 3, which controls movements of an elevator in a building. The specification of the elevator is obtained from [11]. From the Idle state, call the RequestUp trigger (method of the ECS class), and then the elevator goes to the DoorClosingToMoveUp state representing the behavior of the system when the door is closing and moving up. Similarly, from the Idle state, when the RequestDown trigger is fired, the elevator goes to the DoorClosingToMoveDown state. From ElevatorAtFloor, if no trigger is fired within 5 s, the elevator state machine transits to the Idle state (modeled as a time event). Similarly, different states and transitions are modeled in the base state machine.

Aspect state machine for the EmergencyCall aspect is shown in Fig. 4. Stereotype $\ll$ Aspect $\gg$ is applied to the EmergencyCall state machine, indicating that it is an aspect state machine. The attributes for $\ll$ Aspect $\gg$ contain the following information: the name of the aspect state machine and the name of the base state machine (ElevatorControl in this example). State SelectedStates is stereotyped as $\ll$ Pointcut $\gg$, which shows that this state selects states from the base state machine. Stereotype $\ll$ Pointcut $\gg$ has two attributes: the name of the pointcut (SelectedStates in this case) and its type (SelectionType:All meaning that it selects all states of the base state machine). New transitions are added in the base state machine, with trigger named as EmergencyCallPressed stereotyped with $\ll$ Introduction $\gg$, from all the states of ElevatorControl to a newly introduced state named as DialingToControlRoom stereotyped with $\ll$ Introduction $\gg$. A new transition with trigger DialSuccessful is added from DialingToControlRoom to a newly introduced state Connected. Finally, from Connected, a newly introduced transition with trigger DisconnectCall is added to a newly introduced state DisconnectingFromControlRoom. Note that in Fig. 4, a new region is introduced: EmergencyCall, which is orthogonal to the normal operation of ElevatorControl.

The EmergencyCall behavior modeled using the Hierarchical approach is shown in Fig. 5. The behavior of ElevatorControl is modeled in a composite state (i.e., ElevatorControl) in Fig. 5. From the boundary of the ElevatorControl composite state, a transition with trigger EmergencyCallPressed goes to DialingToControlRoom. This means that from any of the states in ElevatorControl, whenever EmergencyCallPressed is pressed, the emergency call is made. An equivalent design of EmergencyCall using flat state machines is shown in Fig. 6.

Fig. 6

EmergencyCall modeled with the Flat approach

Appendix B: Comprehension questionnaire for replication

• 1. Explain the possible subsequent scenario when Saturn is in a videoconference with three endpoints and audio quality is within the allowed threshold value?

• 2. Explain the possible subsequent scenario when Saturn is Idle and audio quality is greater than the allowed threshold?

• 3. Explain the possible subsequent scenario when Saturn could not recover audio quality and is in a videoconference with one endpoint?

• 4. Explain the possible subsequent scenario when Saturn is connected to one endpoint and Do Not Disturb mode is turned On?

• 5. Explain the possible subsequent scenario when Saturn is in Do Not Disturb mode and is connected to two endpoints and two more endpoints are dialing to Saturn at the same time?

• 6. Explain possible subsequent scenario when Saturn is in Connected state for $m$ minutes?

• 7. Explain the possible subsequent scenario when Saturn is in StandbyOn and an endpoint dials to it?

• 8. Explain the possible subsequent scenario when Saturn is Idle and an endpoint dials to it with H254 videoconference protocol?

• 9. Explain the possible subsequent scenario when Saturn is in a videoconference with two endpoints with SIP protocol and a third endpoint dials to Saturn with H323 videoconference protocol?

• 10. Explain the scenario when Saturn is in a videoconference with six endpoints with SIP protocol and another endpoint dials to Saturn with H323 videoconference protocol?