Download full chapter Structured Object Oriented Formal Language And Method Third International Workshop Sofl Msvl 2013 Queenstown New Zealand October 29 2013 Revised Selected Papers 1St Edition Shaoying Liu pdf docx
Download full chapter Structured Object Oriented Formal Language And Method Third International Workshop Sofl Msvl 2013 Queenstown New Zealand October 29 2013 Revised Selected Papers 1St Edition Shaoying Liu pdf docx
Download full chapter Structured Object Oriented Formal Language And Method Third International Workshop Sofl Msvl 2013 Queenstown New Zealand October 29 2013 Revised Selected Papers 1St Edition Shaoying Liu pdf docx
https://textbookfull.com/product/formal-aspects-of-component-
software-10th-international-symposium-facs-2013-nanchang-china-
october-27-29-2013-revised-selected-papers-1st-edition-jose-luiz-
fiadeiro/
https://textbookfull.com/product/brain-inspired-computing-
international-workshop-braincomp-2013-cetraro-italy-
july-8-11-2013-revised-selected-papers-1st-edition-lucio-
grandinetti/
https://textbookfull.com/product/citizen-in-sensor-networks-
second-international-workshop-citisens-2013-barcelona-spain-
september-19-2013-revised-selected-papers-1st-edition-alex-pardo/
https://textbookfull.com/product/information-security-and-
cryptology-icisc-2013-16th-international-conference-seoul-korea-
november-27-29-2013-revised-selected-papers-1st-edition-hyang-
sook-lee/
https://textbookfull.com/product/ad-hoc-networks-5th-
international-icst-conference-adhocnets-2013-barcelona-spain-
october-2013-revised-selected-papers-1st-edition-zayneb-trabelsi-
Shaoying Liu
Zhenhua Duan (Eds.)
LNCS 8332
Structured Object-Oriented
Formal Language and Method
Third International Workshop, SOFL+MSVL 2013
Queenstown, New Zealand, October 29, 2013
Revised Selected Papers
123
Lecture Notes in Computer Science 8332
Commenced Publication in 1973
Founding and Former Series Editors:
Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen
Editorial Board
David Hutchison
Lancaster University, Lancaster, UK
Takeo Kanade
Carnegie Mellon University, Pittsburgh, PA, USA
Josef Kittler
University of Surrey, Guildford, UK
Jon M. Kleinberg
Cornell University, Ithaca, NY, USA
Alfred Kobsa
University of California, Irvine, CA, USA
Friedemann Mattern
ETH Zurich, Zürich, Switzerland
John C. Mitchell
Stanford University, Stanford, CA, USA
Moni Naor
Weizmann Institute of Science, Rehovot, Israel
Oscar Nierstrasz
University of Bern, Bern, Switzerland
C. Pandu Rangan
Indian Institute of Technology, Madras, India
Bernhard Steffen
TU Dortmund University, Dortmund, Germany
Demetri Terzopoulos
University of California, Los Angeles, CA, USA
Doug Tygar
University of California, Berkeley, CA, USA
Gerhard Weikum
Max Planck Institute for Informatics, Saarbruecken, Germany
Structured Object-Oriented
Formal Language and Method
Third International Workshop, SOFL?MSVL 2013
Queenstown, New Zealand, October 29, 2013
Revised Selected Papers
123
Editors
Shaoying Liu Zhenhua Duan
Hosei University Xidian University
Koganei-shi, Tokyo Xi’an
Japan People’s Republic of China
Both formal methods and conventional software engineering techniques face various
challenges; they must be properly integrated to establish more effective technologies
for future software engineering. The development of the Structured Object-Oriented
Formal Language (SOFL) over the last two decades has shown some possibilities of
achieving effective integrations to build practical formal techniques and tool support
for requirements analysis, specification, design, inspection, review, and testing of
software systems. SOFL integrates: Data Flow Diagram, Petri Nets, and VDM-SL to
offer a graphical and formal notation for writing specifications; a three-step approach
to requirements acquisition and system design; specification-based inspection and
testing methods for detecting errors in both specifications and programs; and a set of
tools to support modeling and verification. Meanwhile, the Modeling, Simulation and
Verification Language (MSVL) is a parallel programming language developed over
the last decade. Its supporting tool MSV has been developed to enable us to model,
simulate, and verify a system formally. The two languages complement each other.
Following the success of the second SOFL workshop held in Kyoto in 2012, the 3rd
International Workshop on SOFL?MSVL (SOFL?MSVL 2013) is jointly organized
by the Shaoying Liu research group at Hosei University, Japan, and the Zhenhua Duan
research group at Xidian University, China, with the aim of bringing industrial,
academic, and government experts and practitioners of SOFL or MSVL to commu-
nicate and to exchange ideas. The workshop attracted 22 submissions on formal
specification, specification-based testing, specification pattern, modeling checking,
specification animation, simulation, application of SOFL, and supporting tools for
SOFL or MSVL. Each submission is rigorously reviewed by two Program Committee
members on the basis of technical quality, relevance, significance, and clarity, and 13
papers were accepted for publication in the workshop proceedings. The acceptance
rate is approximately 59 %.
We would like to thank the ICFEM 2013 organizers for supporting the organization
of the workshop, all of the Program Committee members for their great efforts and
cooperation in reviewing and selecting papers, and our postgraduate students for their
help. We would also like to thank all of the participants for attending presentation
sessions and actively joining discussions at the workshop. Finally, our gratitude goes
to Alfred Hofmann and his team for their continuous support in the publication of the
workshop proceedings.
Program Co-Chairs
Program Committee
SOFL Tools
1 Introduction
Given a formal specification S and an implementation P , how to verify whether P
satisfies S (or P is correct with respect to S) in practice still remains a challenge.
Formal verification (or proof) based on Hoare logic (also Flody-Hoare logic) [1]
provides a possibility to establish the correctness for programs, but due to the
difficulty in deriving appropriate invariants for iterations and the difficulties in
managing side effect, complex data structures, and invocations of subroutines
(methods, functions, or procedures) in programming languages, formal proof for
realistic programs is impractical.
On the other hand, specification-based testing (SBT) is a practical technique
for detecting program errors. A strong point of SBT superior to formal correct-
ness verification is that it is much easier to be performed, even automatically if
This work is supported by NII Collaborative Program, SCAT research foundation,
and Hosei University.
S. Liu and Z. Duan (Eds.): SOFL+MSVL 2013, LNCS 8332, pp. 3–16, 2014.
DOI: 10.1007/978-3-319-04915-1 1,
c Springer International Publishing Switzerland 2014
4 S. Liu and S. Nakajima
formal specifications are adopted [2,3], but a weak point is that existing errors
on a program path may still not be uncovered even if it has been traversed using
a test case. Liu’s previous work on combining Hoare Logic and SBT presented a
novel technique for formally proving the correctness of all of the traversed pro-
gram paths [4], which shows the potential of strengthening testing by applying
Hoare logic. In spite of the great potential of improvement of this technique,
there still exists a difficulty when testing encounters crash or non-termination in
running the program. Another practical technique that is likely to perform bet-
ter in some circumstances than testing is software inspection [5], but inspection
usually heavily depends on human decisions and therefore lacks repeatability [6].
We believe, as many others do, that each of these three approaches is difficult to
do a satisfactory job, but they complement each other when they come together
in an appropriate manner.
In this paper, we propose an approach to verifying programs by combining
the specific SBT we have developed before with the Hoare logic and a formal
specification-based program inspection technique. This new approach is known
as testing-based formal verification (TBFV). The essential idea is first to generate
a test case from each functional scenario, derived from the formal specification
using pre- and post-conditions, to run the program, and then repeatedly apply
the axiom for assignment in Hoare logic to formally verify the correctness of the
path that is traversed by using the test case. When such a proof is impossible to
conduct due to complex data structures or other reasons, the inspection method
will be applied. As described in Sect. 2, any pre-post style formal specification
can be automatically transformed into an equivalent disjunction of functional
scenarios and each scenario defines an independent function of the corresponding
program in terms of the relation between input and output. A test case can be
generated from each functional scenario and can be used to run the program
to find a traversed path, which is a sequence of conditions or statements, but
the correctness of the path with respect to the pre-condition and the functional
scenario is unlikely to be established by means of testing. This deficiency can be
eliminated by repeatedly applying the axiom for assignment in Hoare logic or by
specification-based inspection when Hoare logic is hard to apply. The superiority
of our approach to both SBT and formal verification is that it can verify the
correctness of all traversed paths and can be performed automatically because
the derivation of invariants from iterations is no longer needed.
Our focus in this paper is on the explanation of the new idea in combining
specification-based testing with Hoare logic. Therefore, we deliberately choose
small examples to explain the principle, which is expected to facilitate the reader
in understanding the essential idea. The feasibility of applying the new technique
to deal with a realistic program system has been demonstrated in our case study.
The rest of the paper is organized as follows. Section 2 gives a brief intro-
duction to both the functional scenario-based testing (FSBT) and the formal
specification-based inspection method. Section 3 describes the essential idea of
our TBFV approach. In Sect. 4, we give an example to illustrate the TBFV
approach systematically. Section 5 elaborates on how method invocation is dealt
Combining Specification-Based Testing 5
with in TBFV. Section 6 discusses the potential challenges to the proposed app-
roach. Section 7 gives a brief overview of the related work. Finally, in Sect. 8, we
conclude the paper and point out future research direction.
2.1 FSBT
FSBT is a specific specification-based testing approach that takes both the pre-
condition and post-condition into account in test case generation [3]. Applying
the principle of “divide and conquer”, the approach treats a specification as a
disjunction of functional scenarios (FS), and to generate test sets and analyze
test results based on the functional scenarios. A functional scenario in a pre-post
style specification is a logical expression that tells clearly what condition is used
to constrain the output when the input satisfies some condition.
Specifically, let S(Siv , Sov )[Spre , Spost ] denote the specification of an opera-
tion S, where Siv is the set of all input variables whose values are not changed by
the operation, Sov is the set of all output variables whose values are produced or
updated by the operation, and Spre and Spost are the pre- and post-conditions
of S, respectively. The characteristic of this style specification is that the post-
condition Spost is used to describe the relation between initial states and final
states. We assume that in the post-condition, a decorated variable, such as ˜x,
is used to denote the initial value of external (or state) variable x before the
operation and the variable itself, i.e., x, is used to represent the final value of
x after the operation. Thus, ˜x ∈ Siv and x ∈ Sov . Of course, Siv also contains
all other input variables declared as input parameters and Sov includes all other
output variables declared as output parameters.
A practical strategy for generating test cases to exercise the behaviors
expected of all functional scenarios derived from the specification is established
based on the concept of functional scenario. To precisely describe this strategy,
we first need to introduce functional scenario.
The decorated pre-condition ˜Spre = Spre ˜(σ/σ) denotes the predicate result-
ing from substituting the initial state ˜σ for the final state σ in pre-condition
Spre . We treat a conjunction ˜Spre ∧ Ci ∧ Di as a scenario because it defines
an independent behavior: when ˜Spre ∧ Ci is satisfied by the initial state (or
intuitively by the input variables), the final state (or the output variables) is
defined by the defining condition Di . The conjunction ˜Spre ∧ Ci is known as
the test condition of the scenario ˜Spre ∧ Ci ∧ Di , which serves as the basis for
test case generation from this scenario.
To support automatic test case generation from functional scenarios, the
vital first step is to obtain an FSF from a given specification. A systematic
transformation procedure, algorithm, and software tool support for deriving an
FSF from a pre-post style specification have been developed in our previous work
[7]. Generating test cases based on a specification using the functional scenario-
based test case generation method is realized by generating them from its all
functional scenarios. The production of test cases from a functional scenario is
done by generating them from its test condition, which can be divided further
into test case generations from every disjunctive clause of the test condition. In
the previous work [3], a set of criteria for generating test cases are defined in
detail. To effectively apply FSBT, the FSF of the specification must satisfy the
well-formed condition defined below.
The specification states that the input a (standing for age) must be greater
than 0 and n_f (normal_f are) must be greater than 1. When a is greater than
12, the output a_f (actual_f are) will be the same as n_f ; otherwise, a_f will
be 50 % discount on n_f .
According to the algorithm reported in our previous work [7], three functional
scenarios can be derived from this formal specification:
(1) a > 0 and n_f > 1 and a > 12 and a_f = n_f
(2) a > 0 and n_f > 1 and a <= 12 and a_f = n_f − n_f ∗ 0.5
(3) a <= 0 or n_f <= 1 and anything
where anything means that anything can happen when the pre-condition is
violated.
Assume the formal specification is refined into the following program
(a Java-like method):
with side effect or complex data structures, such as arraylist of objects in Java,
the axioms in Hoare logic may not be applied successfully. In this case, the formal
specification-based inspection method can be applied to replace the formal proof.
3 Principle of TBFV
TBFV proposed in this paper provides a specific technique for verifying the
correctness of traversed program paths identified using FSBT. The principle
underlying the technique includes the following three points:
– Using FSBT to generate adequate test cases to identify all of the represen-
tative paths in the program under testing; each path is traversed by using at
least one test case. A representative path is formed by treating an iteration as
an if-then-else construct to ensure that the body of the iteration is executed
at least once and the iteration terminates, and by treating all of the other
constructs as same as their original form.
– Let ˜Spre ∧ Ci ∧ Di (i = 1, ..., n) denote a functional scenario and test case t
be generated from the test condition ˜Spre ∧ Ci . Let p = [sc1 , sc2 , ..., scm ] be
a program path in which each scj (j = 1, ..., m) is called a program segment,
which is a decision (i.e., a predicate), an assignment, a “return” statement,
Combining Specification-Based Testing 9
{˜Spre } p {Ci ∧ Di } .
where ˜Spre (˜x/x), ppre (˜x/x) and Ci ∧ Di (˜x/x) are a predicate resulting
from substituting every decorated input variable ˜x for the corresponding
input variable x in the corresponding predicate, respectively. These substitu-
tions are necessary to avoid confusion between the input variables and the
internally updated variables (which may share the same name as the input
variables).
Finally, if the implication ˜Spre (˜x/x) => ppre (˜x/x) can be proved, it
means that no error exists on the path; otherwise, it indicates the existence
of some error on the path.
The axioms for the other relevant statements or decisions are given below.
{Q}S{Q} [1],
{S∧Q}S{Q} [2],
4 Example
We have conducted a case study to apply our TBFV approach to test and verify
a simplified version of the IC card system for JR commute train service in Tokyo.
Our experience shows that the approach is feasible and can be effective in general
but also faces some challenges or limitations that need to be addressed in the
future research, as elaborated in Sect. 6. The system we used is designed to offer
the following functional services: (1) Controlling access to and exit from a railway
station, (2) Buying tickets using the IC card, (3) Recharging the card by cash or
through a bank account, and (4) Buying a railway pass for a certain period (e.g.,
for one month or three months). Due to the limit of space, we cannot present all
of the details, but take one of the internal operations used in the system, which
is ChildF areDiscount mentioned above, as an example to illustrate how TBFV
is applied to rigorously test the corresponding program. The program contains
three paths, it is necessary to formally verify all of the three paths. Since the
process of the verification is the same for all the paths, we only use the path
[(1)(2)≤ (4)(5)] that is traversed by using the test case {(a, 5), (n_f, 2)} as an
example for explanation.
Combining Specification-Based Testing 11
where ˜a > 0 and ˜n_f > 1 is the result of substituting ˜a and ˜n_f for
input variables a and n_f , respectively, in the pre-condition of the program,
and ˜a <= 12 and a_f = ˜n_f − ˜n_f ∗ 0.5 is the result of completing the
similar substitution in the post-condition.
Secondly, we repeatedly apply the axiom for assignment or the one for non-
change segment to this path triple, starting from the post-condition. As a result,
we form the following path, known as asserted path, with derived internal asser-
tions between two program segments:
{˜a > 0 and ˜n_f > 1}
{˜a <= 12 and
˜n_f ∗ ∗2 − ˜n_f − ˜n_f ∗ 0.5 = ˜n_f − ˜n_f ∗ 0.5}
a > 0 && n_f > 1
{a <= 12 and ˜a <= 12 and
n_f ∗ ∗2 − n_f − n_f ∗ 0.5 = ˜n_f − ˜n_f ∗ 0.5}
a <= 12
{˜a <= 12 and
n_f ∗ ∗2 − n_f − n_f ∗ 0.5 = ˜n_f − ˜n_f ∗ 0.5}
a_f := n_f ∗ ∗2 − n_f − n_f ∗ 0.5
{˜a <= 12 and a_f = ˜n_f − ˜n_f ∗ 0.5}
return a_f
{˜a <= 12 and a_f = ˜n_f − ˜n_f ∗ 0.5}
where the assertion ˜a <= 12 and˜n_f ∗∗2−˜n_f −˜n_f ∗0.5 = ˜n_f −˜n_f ∗
0.5, the second from the top of the sequence, is the result of substituting ˜a for a
and ˜n_f for n_f in the derived assertion {˜a <= 12 and ˜a <= 12 and n_f ∗
∗2 − n_f − n_f ∗ 0.5 = ˜n_f − ˜n_f ∗ 0.5. As explained previously, this is
necessary in order to keep consistency of the input variables a and n_f in the
original pre-condition (appearing as ˜a and ˜n_f ) and the derived pre-condition.
Thirdly, we need to judge the validity of the implication ˜a > 0 and ˜n_f >
1 => ˜a <= 12 and ˜n_f ∗ ∗2 − ˜n_f − ˜n_f ∗ 0.5 = ˜n_f − ˜n_f ∗ 0.5. Using
the test case {(˜a, 5), (˜n_f, 8)}, we can easily prove that the implication is false
(the evaluation detail is omitted due to space limit).
From this example, we can see that sometimes testing can be even more
efficient than formal proof in judging the validity of the implication when an
error exists on the path, but if the path contains no error, testing will be almost
impossible to give a firm conclusion in general. In that case, the specification-
based inspection can be applied to check whether the path correctly implements
the corresponding functional scenario. The inspection can also be valuable if the
path cannot be formally proved for the reasons as mentioned previously.
12 S. Liu and S. Nakajima
5.1 Iteration
Let us take a while loop, while B do S, as an example. When using a test case
to run the program that entails running of this loop, a subpath generated by
executing the loop will be traversed. Assume the subpath is as follows:
[B, S, B, S, B, S, not B],
since this is a single program path, the same method explained in the previous
section can be applied to derive a pre-condition, and the same principle of using
formal proof or testing can also be used to determine the correctness of the path.
Because there is no new technique involved in dealing with iterations, we omit
the further discussion.
class F areDiscount {
int tem; //instance variable
(6)], and [(1)(2)≤ (7)], where segment (1) is a subpath [(1.1)(1.2)](n_f /x), denot-
ing the path resulting from substituting actual parameter n_f for formal para-
meter x in the subpath [(1.1)(1.2)]. Thus, [(1)(2)(3)≤ (5)(6)] for example, actually
means the path after inserting the traversed path in Discount into the traversed
path in ChildF areDiscount1, which is simply represented by [(1.1)(1.2)(2)(3)≤ (5)
(6)]. Selecting the same test case {(a, 5), (n_f, 2)} as before to run the program,
we make the path [(1.1)(1.2)(2)(3)≤ (5)(6)] traversed. We then form the asserted
path as follows:
a <= 12
{˜a <= 12 and
n_f ∗ ∗2 − n_f − tem = ˜n_f − ˜n_f ∗ 0.5}
a_f := n_f ∗ ∗2 − n_f − tem
{˜a <= 12 and a_f = ˜n_f − ˜n_f ∗ 0.5}
return a_f
{˜a <= 12 and a_f = ˜n_f − ˜n_f ∗ 0.5}
where the subpath [r := n_f ∗ 0.5, tem := r] is the result of substituting actual
parameter n_f used in the method invocation Discount(n_f ) for
formal parameter x used in the method definition in the original subpath [r :=
x ∗ 0.5, tem := r]. Similarly, we can easily use testing to prove that the implica-
tion ˜a > 0 and ˜n_f > 1 => ˜a <= 12 and ˜n_f ∗ ∗2 − ˜n_f − ˜n_f ∗ 0.5 =
˜n_f − ˜n_f ∗ 0.5 is false, indicating that an error is found on the path.
6 Potential Challenges
While our experience in the case study mentioned above shows that applying
TBFV to practical systems is feasible and can be effective, we have also learned
two major potential challenges or limitations. One is that if the expression E in
the assignment x := E has a side effect (e.g., in addition to returning a value,
it also modifies some state or has an observable interaction with calling func-
tions), the axiom for assignment in Hoare logic is no longer valid. TBFV inherits
this limitation from Hoare logic, but how to automatically resolve the side effect
without affecting the semantics of the original expression remains a topic for
14 S. Liu and S. Nakajima
7 Related Work
Research on integration of Hoare logic and testing seems to mainly concentrate
on using pre- and post-assertions in Hoare triple for test case generation and
test result analysis, but none of them takes the same approach as our TBFV to
solve the same problem in specification-based testing.
One of the earliest efforts is Meyer’s view of Design By Contract (DBC)
implemented in the programming language Eiffel [12,13]. Eiffel’s success in check-
ing pre- and post-conditions and encouraging the DBC discipline in programming
partly contributed to the development of the similar work for other languages
such as the Sunit testing system for Smalltalk [14]. Cheon and Leavens describe
an approach to unit testing that uses a formal specification language’s run-
time assertion checker to decide whether methods are working correctly with
respect to a formal specification using pre- and post-conditions, and have imple-
mented this idea using the Java Modeling Language (JML) and the JUnit testing
framework [15]. Gray and Microsoft describe another approach to testing Java
programs using Hoare-style specifications [16]. They show how logical test speci-
fications with a more relaxed post-condition than existing restricted Hoare-style
post-condition can be embedded within Java and how the resulting test spec-
ification language can be compiled into Java for executable validation of the
program. There are many other similar results in the literature, but we have to
omit them due to the space limit.
References
1. Hoare, C.A.R., Wirth, N.: An axiomatic definition of the programming language
PASCAL. Acta Inf. 2(4), 335–355 (1973)
2. Khurshid, S., Marinov, D.: TestEra: specification-based testing of Java programs
using SAT. Autom. Softw. Eng. 11(4), 403–434 (2004)
3. Liu, S., Nakajima, S.: A decompositional approach to automatic test case gen-
eration based on formal specifications. In: 4th IEEE International Conference on
Secure Software Integration and Reliability Improvement (SSIRI 2010), Singapore,
9–11 June 2010, pp. 147–155. IEEE CS Press (2010)
4. Liu, S.: Utilizing Hoare logic to strengthen testing for error detection in programs.
In: Proceedings of the Turing Centenary Conference, June 2012. EPiC Series,
Manchester, UK, pp. 229–238 (2012)
5. Parnas, D.L., Madey, J., Iglewski, M.: Precise documentation of well-structured
programs. IEEE Trans. Softw. Eng. 20(12), 948–976 (1994)
6. Aurum, A., Petersson, H., Wohlin, C.: State-of-the-art: software inspections after
25 years. Softw. Test. Verification Reliab. 12(3), 133–154 (2002)
7. Liu, S., Hayashi, T., Takahashi, K., Kimura, K., Nakayama, T., Nakajima, S.:
Automatic transformation from formal specifications to functional scenario forms
for automatic test case generation. In: 9th International Conference on Software
Methodologies, Tools and Techniques (SoMet 2010), Yokohama City, Japan, Sep-
tember 29–October 1 (page to appear). IOS International Publisher (2010)
8. Liu, S.: Formal Engineering for Industrial Software Development Using the SOFL
Method. Springer, Heidelberg (2004). ISBN 3-540-20602-7
9. Liu, S., Chen, Y., Nagoay, F., McDermid, J.: Formal specification-based inspection
for verification of programs. IEEE Trans. Softw. Eng. 38(5), 1100–1122 (2012)
10. Liu, S., Nakajima, S.: A “Vibration” method for automatically generating test
cases based on formal specifications. In: 18th Asia-Pacific Software Engineering
Conference (APSEC 2011), HCM city, Vietnam, 5–8 December 2011, pp. 73–80.
IEEE CS Press (2011)
11. Liu, S., McDermid, J.A., Chen, Y.: A rigorous method for inspection of model-
based formal specifications. IEEE Trans. Reliab. 59(4), 667–684 (2010)
12. Meyer, B.: Applying design by contract. IEEE Comput. 25(10), 40–51 (1992)
13. Meyer, B.: Eiffel: The Language. Object-Oriented Series. Prentice Hall, Upper
Saddle River (1991)
14. Castellon, M.C., Molina, J.G., Pimentel, E., Repiso, I.: Design by contract in
smalltalk. J. Object-Oriented Program. 9(7), 23–28 (1996)
16 S. Liu and S. Nakajima
15. Cheon, Y., Leavens, G.T.: A simple and practical approach to unit testing: the
JML and JUnit way. In: Magnusson, B. (ed.) ECOOP 2002. LNCS, vol. 2374, pp.
231–234. Springer, Heidelberg (2002)
16. Gray, K.E., Mycroft, A.: Logical testing: Hoare-style specification. In: Chechik, M.,
Wirsing, M. (eds.) FASE 2009. LNCS, vol. 5503, pp. 186–200. Springer, Heidelberg
(2009)
Theory of Test Modeling Based on Regular
Expressions
1 Introduction
Software testing is a critical activity to assure software quality [1]. However, earlier
studies have shown that software testing can consume more than fifty percent of the
development costs [2]. Therefore automating software testing as a long-term goal has
been highlighted in the industry for many years. Model-based testing [3–5], as a
method of automatic test, has been widely studied to generate abstract test sequences.
The finite state machine (FSM [6, 7]), a formal notation for describing software
behaviors, is often employed for test modeling and test generation, forming a series of
test generation methods [8–10].
For a concurrent system, however, it is hard to build a model by FSM due to the
limitation of the expressive power of FSM. Therefore the other modeling methods
have been suggested for modeling concurrent systems. For example, Petri nets [11,
12] was used for modeling software behaviors and generating test cases for accessi-
bility test [13]. However, Petri nets easily causes the state-space explosion problem
[14] when the system is complex. Regular expressions are also used to build the model
of distributed systems, such as path expressions [15], behavior expressions [16] and
S. Liu and Z. Duan (Eds.): SOFL+MSVL 2013, LNCS 8332, pp. 17–31, 2014.
DOI: 10.1007/978-3-319-04915-1_2, Springer International Publishing Switzerland 2014
18 P. Liu and H. Miao
extended regular expression [17]. Garg et al. [16, 18] proposed an algebraic model
called concurrent regular expressions for modeling and analysis of distributed sys-
tems. However, this algebraic model is suitable for model checking and not for test
generation because it lacks of the essential path information, which consists of the
initial node, the terminal node and path sequences. Ravi et al. [19] proposed a novel
methodology for high-level testability analysis and optimization of register-transfer
level controller/data path circuits based on regular expressions. Qian et al. [20] pre-
sented a method to generate test sequences from regular expressions describing
software behaviors. This method firstly uses the FSM to build the model of software
behaviors. And then the FSM is converted into a regular expression according to three
construction rules. Finally, test sequences are obtained from this regular expression.
However, the suggested expression model does not have the capability for describing
concurrent operations because regular expressions are derived from FSM.
In this paper, we suggest constructing the test model by regular expressions for
software behaviors. Referring to the modeling theories of concurrent regular
expressions in [16, 18] and that of FSM in [7, 21], we set up an expression algebraic
system. And some examples are employed for illustrating our modeling approaches.
The rest of this paper is organized as follows. Section 2 presents the expression
algebraic system. Section 3 introduces the method of test modeling by regular
expressions. Some examples of test modeling are presented in Sect. 4. Section 5
discusses the advantages and disadvantages between the traditional test generation
method and our test generation method. Section 6 concludes the whole paper.
Before we introduce the expression algebraic system, the definition of FSM needs to
be introduced so that we can build the bridge between the regular expression and
FSM.
A finite-state machine (FSM) [22, 23] M ¼ \S; I; O; f ; g; s0 [ consists of a finite
set S of states, a finite input alphabet I, a finite output alphabet O, a transition function
f that assigns to each state and input pair a new state, an output function g that assigns
to each state and input pair an output, and an initial state s0. According to the defi-
nition of FSM, we give the definitions of both transition and transition sequence.
Definition 1 (transition): A transition of FSM is defined by t ¼ ðs1 ; i=o; s2 Þ, where
f ðs1 ; iÞ ¼ s2 ; i 2 I; gðs1 ; iÞ ¼ o; o 2 O; s1 is the pre-state of t, s2 is the next-state of t,
i is the transition condition of t and o is the output result of t.
Definition 2 (transition sequence): For any transition a, the syntax of the transition
sequence ts can be defined via Backus-Naur form:
ts :: ¼ e j a j a:ts j ts:a j ts:ts;
Where e denotes the empty and ts is any transition sequence.
Let R be a nonempty set of transition sequences in FSM, and e ¼ a0 for any a 2 R.
Let #ts denote the number of transitions in ts.
Theory of Test Modeling Based on Regular Expressions 19
In Defintion 3, the descriptions of four operators |,., * and ? refer to the statements
in [16, 20]. We set the priority of operators high to low: (), *, ? and a,., and ||, |.
Definition 4 (expression algebraic system): An expression algebraic system con-
sists of both R and the operators |, +,., *, a (), , and ||, denoted as \ R, |, +,., *, a (), ,
|| [ , and e is the identity element of this system.
3 Test Modeling
In this section, we do not take account of the inputs and outputs on transitions and all
transitions are directly labeled on the edges of the graphs.
t1 t2
s0 s1 s2
t1 t2
s0 s1 s2
t3
s3
or t2 is executed in accordance with the different inputs on s1. The choice operator
satisfies the following properties:
(1) 8a; b 2 R ajb ) a _ b:
(2) 8a; b 2 R ajb ¼ bja ðCommutativityÞ
(3) 8a; b; c 2 R ajbjc ¼ ðajbÞjc ¼ ajðbjcÞ ðAssociativityÞ
(4) 8a 2 R aje ¼ eja ¼ a
(5) 8a 2 R aja ¼ a ðIdentityÞ
(6) 8a; b1 ; b2 ; . . .; bn 2 R a:ðb1 jb2 j. . .jbn Þ ¼ a:b1 ja:b2 j. . .ja:bn ðDistributivityÞ
(7) 8a1 ; a2 ; . . .; an ; b 2 R ða1 ja2 j. . .jan Þ:b ¼ a1 :bja2 :bj. . .jan :b ðDistributivityÞ
t2
t1 t3
s0 s1 s2
t2 t4
t1 t3
s0 s1 s2
t5
Fig. 4. The software behavior model with the positive closure.
3.5 Alpha-closure
Let a be the alpha-closure, which denotes a maximum cycle times. E.g., ba denotes
that the transition b is executed repeatedly a times. The model of an online bank login
system is shown in Fig. 5. If the user types the wrong username or password for three
t1
t2
s0 s1
t3
s2
times, the system will be automatically locked for 24 h. The symbols in this model
denote as follows:
– s0 denotes the login page,
– s1 is the main page,
– s2 denotes the locked page,
– t1 denotes the self-check on s0,
– t2 denotes the login success,
– t3 denotes the login failure.
According to the above description of system, there exists a ¼ 3 and this system
can be described by t13 :t3 jt2 jt1 :t2 jt12 :t2 . The alpha-closure satisfies the following
Properties:
a
zfflfflffl}|fflfflffl{
(1) 8a 2 R aa ¼ a:a. . .a
(2) 8a 2 R a:aa ¼ aa :a ¼ aa
(3) ai 2 R ^ 1 i n ða1 ja2 j. . .jan Þa ¼ aa1 jaa2 j. . .jaan ðDistributivityÞ
(4) 8a 2 R ða Þa ¼ ðaa Þ ¼ aa ðAbsorptionÞ
8a 2 R ðaþ Þ ¼ ðaa Þþ ¼ aa
a
(5) ðAbsorptionÞ
(6) ea ¼ e
t1
s0 s1
t2
Fig. 6. The software behavior model with the synchronous operator.
Another random document with
no related content on Scribd:
Apollo
One of the favorite Greek stories has been that of Orpheus, who
went down to Hades to bring his dead wife whom he adored, back to
earth, and about whom Peri, Gluck, and others wrote operas. He was
son of Apollo and of Calliope, the Muse of Epic Poetry, and became
such a fine performer on all instruments, that he charmed all things
animate and inanimate. He tamed wild birds and beasts, and even
the trees and rocks followed him as he played, the winds and the
waves obeyed him, and he soothed and made the Dragon, who
guarded the Golden Fleece, gentle and harmless.
On the cruise of the Argo in search of the Golden Fleece, Orpheus
not only succeeded in launching the boat when the strength of the
heroes had failed in the task, but when they were passing the islands
of the Sirens, he sang so loudly and so sweetly that the Sirens’ songs
could not be heard and the crew were saved.
Music in Their Daily Life
When a people have legends about music you may know that they
love it. Such was the case with the Greeks. They did not call their
schools high schools and colleges but Music schools, and everything
that we call learning they included under the name of music. Every
morning the little Greek boy was sent to the Music school where he
was taught the things that were considered necessary for a citizen to
know. Here he learned gymnastics, poetry, and music. At home too,
music was quite as important as in school, and we know that they
had folk songs which had to do with the deeds of ordinary life, such
as farming and winemaking and grape-picking, and the effect and
beauty of the seasons of the year. (See Chap. IX.) They can well be
divided into songs of joy and songs of sorrow, and seem to have
existed even before Homer the Blind Bard. If you ever have tried to
dance or do your daily dozen without music, you will understand at
once how much help music always has been to people as they
worked.
Harvest Songs
All harvest songs in Greece had the name of Lytiersis. Lytiersis was
the son of King Midas, known as the richest king in the world.
Lytiersis was a king himself but also a mighty reaper, and according
to Countess Martinengo-Cesaresco who has written a book called
Essays in the Study of Folk-Songs it was his “habit to indulge in
trials of strength with his companions and with strangers who were
passing by. He tied the vanquished up in sheaves and beat them. One
day he defied an unknown stranger, who proved too strong for him
and by whom he was slain.” The first harvest song was composed to
console King Midas for the death of his son. We can make a fable
from this story which means that Nature and Man are always
struggling against each other.
The harvest festivals founded in Greece led to others in Brittany,
France, North Germany and England. So does the deed of one race
affect other races.
The Liturgies
Among the taxes, or five special liturgies, that the Greeks had to
pay, was the obligation for certain rich citizens to supply the Greek
tragedies with the chorus. Every Greek play had its chorus and every
chorus had to have its structures; a choregic monument to celebrate
it; one or more flute players, costumes, crowns, decorations, teachers
for the chorus and everything else to make it succeed. This cost,
which would equal many thousands of dollars, was undertaken as a
duty quite as easily as our men of wealth pay their income taxes. You
can see a greatly enlarged copy of a choregic monument, the Soldiers’
and Sailors’ monument at 89th Street and Riverside Drive, in New
York City, and also one at the Metropolitan Museum.
In old Greece the musicians were also poets. Homer, Hesiod,
Pindar, Æschylus, Sophocles, Sappho, Euripides, Plato, not only
wrote their dramas but knew what music should be played with
them. In fact no play was complete without its chorus and its music
and its flute-player. You have heard of the Greek chorus. Don’t for a
moment think it was like our chorus. It consisted of a group of
masked actors (all actors in those days wore masks), who appeared
between the acts and intoned (chanted) the meaning of the play and
subsequent events. In fact the chorus took the place of a libretto,
—“words and music of the opera,” for it explained to the audience
what it should expect. It spoke and sang some of the most important
lines of the play and danced in appropriate rhythms. So it brought
together word, action and music, and was a remote ancestor of
opera, oratorio and ballet.
Festivals
Besides the occupational songs and those for the drama festivals,
the Greeks had the great game festivals where in some, not only
competitions in sports took place but also flute playing and singing.
The oldest of these festivals was the Olympic games, first held in 776
B.C. and every four years thereafter. These games played so important
a part in the lives of the Greeks that their calendar was divided into
Olympiads instead of years. While music was evident in the Olympic
games, music and poetry were never among the competitions.
The Pythian games were chiefly musical and poetic contests and
were started in Delphi, 586 B.C., where they were held every nine
years in honor of the Delphian Apollo whose shrine was at Delphi.
The Isthmian and Nemean games were also based on poetic and
musical contests. Warriors, statesmen, philosophers, artists and
writers went to these games and took part in them. Maybe some time
we will realize the power of music as did the Greeks nearly one
thousand years before the birth of Jesus.
The Greek Scales
When the second tetrachord began on the tone above the fourth
tone of the first tetrachord, he calls it the breaking method, thus:
By using the join and the break with each of the three modes,
Dorian, Phrygian and Lydian, you can see to what a great variety of
scales and names this would lead. The Greeks spoke of their scales
from the top note down, instead of from the lowest note up, as we do.
The first kithara was supposed to have been an instrument of four
strings that could be tuned in any of these different ways, with the
half-step either between the first and second strings, or between the
second and third, or between the third and fourth. Two instruments
tuned differently formed the complete scale, but it did not take long
to add strings to their lyres and kitharas so that they could play an
entire scale on one instrument.
The little Greek boy was taught in school to tune the scale
according to the fourth string of his lyre, which was the home tone or
what we should call tonic. Our tonic falls on the first degree of the
scale, but in the primary modes of the Greeks, the tonic fell on the
fourth degree, and was called the final. When the final was on pitch
all the other strings had to be tuned to it.
These tetrachords are supposed to have been perfected by
Terpander, in the six hundreds before Christ. His melodies were
called nomes and were supposed to have had a fine moral effect on
the Spartan youth in giving him spirit and courage. The Greeks
thought that all music and that every one of their modes had a
special effect on conduct and character.
After the Messenian war, Sparta was in such a state of upheaval
that the Delphian oracle was consulted. The answer was:
“When Terpander’s Cithar shall sound
Contention in Sparta shall cease.”
The Greeks were the first to write down their music, or to make a
musical notation whereby the singers and players knew what tones to
use. Their system was their alphabet with certain alterations. They
had names describing each tone not unlike our use of the word tonic
for the first degree of the scale, and dominant for the fifth and so on.
Of course they did not have the staff and treble and bass clefs as
we have, but they were groping for some way of recording music in
those far away days.
Pythagoras as far back as 584–504 B.C., not only influenced the
music in the classical Greek period (400 B.C.), but down to and
throughout the Middle Ages to the Renaissance (1500s). To this day
music is based on his mathematical discovery. He worked out a
theory of numbers based on the idea that all nature was governed by
the law of numbers and modern scientists have proven that he was
correct in many of his ideas. In fact our orchestras and pianos are
tuned in accordance with his theories.
He invented an instrument called the monochord which consisted
of a hollow wooden box with one string and movable fret. He
discovered that when he divided the string exactly in half by means
of the fret, the tone produced was an octave higher than the tone
given out by striking the entire string; one-third of the string
produced the interval of a fifth above the octave; one-fourth the
length of the string produced a fourth above the fifth; one-fifth
produced a third (large or major) above the fourth; one-sixth
produced a third (small or minor); one-seventh produced a slightly
smaller third and one-eighth produced a large second, three octaves
above the sound of the entire string:
The truth of Pythagoras’ theory of tone relationship has been
proven by an experiment in physics showing that all of the above
tones belong to the same tone family. An amusing experiment can be
made by pressing silently any one of the tones marked 2, 3, 4, 5, 6, or
8, and striking the fundamental tone sharply, the key you are
pressing silently will sound so that you can distinctly hear its pitch.
The Greeks seem to have had no harmony (that is, combining of
two or more tones in chords) outside of the natural result of men’s
voices and women’s singing together. But they had groups of singers
answering each other in what is called antiphony (anti-against,
phony-sound). Even our American Indians have their song leader
and chorus answering each other.
Greek rhythm followed the rhythm of the spoken word and was
considered a part of their poetic system.
Greek Instruments
The Romans, law givers, world conquerors and road builders, gave
little new to music, for they did not show a great talent for art. They
were influenced by Greek ideals and Greek methods. They were
warlike by nature, and from defenders of their state they became
conquerors. As they grew nationally stronger and more secure, they
learned music, oratory, architecture and sculpture from Greek
teachers. Many Romans well known in history were singers and
gifted players on the Greek kithara, lyre, and flute (aulos).
The Romans seemed to have cared more about the performing of
music than for the composing of it, and “offered prizes to those who
had the greatest dexterity, could blow the loudest or play the fastest.”
(Familiar Talks on History of Music.—Gantvoort.)
As they come to America today the musicians of other lands
flocked to Rome, especially those who played or sang, because they
were received with honor and were richly paid.
The Romans, among them Boethius (6th century B.C.), wrote
treatises on the Greek modes, were very much interested in the
theory of music, and built their scales like the Greeks. To each of the
seven tones within an octave they gave the name of a planet, and to
every fourth tone which was the beginning of a new tetrachord, the
name of a day of the week which is named for the planet.
B C D E F G A
Saturn Jupiter Mars Sun Venus Mercury Moon
Saturday Sunday Monday
B C D E F G A
Saturn Jupiter Mars Sun Venus Mercury Moon
Tuesday Wednesday
B C D E F G A
Saturn Jupiter Mars Sun Venus Mercury Moon
Thursday Friday
The days of the week in French show much more clearly than in
English the names of the planets, in the case of Tuesday—mardi,
(Mars); Wednesday—mercredi (Mercury); Thursday—jeudi,
(Jupiter); Friday—vendredi, (Venus).
The Greeks brought their instrument, the kithara, to Rome, and
with it a style of song called a kitharoedic chant, which was usually a
hymn sung to some god or goddess. The words, until three hundred
years after the birth of Jesus, were in the Greek language; the Latin
kitharoedic songs like those of the poets Horace and Catullus were
sung at banquets and private parties, Cicero too, was musical.
Courtesy of the
Metropolitan
Museum of Art.
Chinese
Instruments.
Fig. 5.—Trumpets.
Fig. 6.—Te’ch’ing—sonorous stone.
Fig. 7.—Yang-Ch’in or Dulcimer.
Fiddles from Arabia (Fig. 8, Rebab); Japan (Fig. 9, Kokin);
Corea (Fig. 10, Haggrine) and Siam (Fig. 11, See Saw Duang).
The Koto-Player.