We develop the input of the CTL models based on a simple banking scenario:
There are two accounts A and B with original balances of $100 and $200 respectively.
Let Tr
1
and Tr
2
be two transactions where Tr
1
transfers $20 from A to B, and Tr
2
trans-
fers $40 from B to A. The consistency constraint is that the total amount, A + B,
should always be $300, which is expressed in SPEC 1. If every transaction eventually
ends in committing or aborting states after starting, the system is both deadlock free
and starvation free. SPEC 2 states this behavioral property in CTL. Both models
shown in Figure 2 satisfy SPEC 1. However, SPEC 2 turns out to be false in POM
4.1.3’s model. As mentioned earlier, this is caused by the starvation problem. After
version 4.1.4 adds the new transition, SPEC 2 is satisfied, which effectively verifies
the corrective maintenance activities in software evolution. Since Prothos is purely an
agile framework, a genuine Web application, Hermes [1], has been used to faithfully
reflect our investigation and further show the validity of the case study.
Fig. 2. State transition models
AG( (A_value + B_value) = 300 ) (SPEC 1)
AG( (tr1.state=starting)
Æ
(AF (tr1.state=committing | tr1.state= aborting) ) ) &
AG( (tr2.state=starting)
Æ
(AF (tr2.state=committing | tr2.state= aborting) ) ) (SPEC 2)
We have proposed a model checking process to effectively verify evolving agile
software frameworks by capturing behavioral changes at an architectural level. From
our experience applying this approach in the case study, we feel that it has rich value
in helping practitioners control software evolution and understand framework’s appli-
cation domain. More empirical studies need to be taken in a systematic way. Further-
more, techniques that permit round trip synchronization between models and source
code deserve further investigation. Whether and how to leverage formal methods in
software development and maintenance have been controversial for decades. Based on
our work, we feel that formal methods can help software engineers gain some insight-
ful comprehension about the system. But they are by no means a panacea.
Acknowledgments. We thank Jim Hoover and Kenny Wong for taking part in the
study of Prothos and their extensive help in improving the presentation of this paper.
References
1. Niu, N.: Formally Understanding the Behavior of a Framework’s Transaction Management.
Master’s Thesis, Department of Computing Science, University of Alberta, 2003.
>> starting
requesting
waiting
issuing
aborting*
executing
releasing
committing*
>> Start State * Accept State Transition New Feature Added by POM 4.1.4
Legend:
117