Test Cases Generation from UML State Diagrams IEE Proceedings - Software, Vol. 146, No. 4, pp. 187-192, Aug. 1999 Y.G. Kim, H.S. Hong, S.M. Cho, D.H. Bae, and S.D. Cha Department of Computer Science Korea Advanced Institute of Science and Technology (KAIST) 373-1, Kusong-dong, Yusong-gu, 305-701, Taejon, Korea E-mail: fygkim,hshong,seung,bae,
[email protected]
Abstract
The paper discusses the application of state diagrams in UML to class testing. A set of coverage criteria is proposed based on control and data
ow in UML state diagrams and it is shown how to generate test cases satisfying these criteria from UML state diagrams. First, control ow is identi ed by transforming UML state diagrams into extended nite state machines (EFSMs). The hierarchical and concurrent structure of states is
attened and the broadcast communication is eliminated in the resulting EFSMs. Second, data ow is identi ed by transforming EFSMs into ow graphs to which conventional data ow analysis techniques can be applied.
software testing, speci cation-based testing, object-oriented programs, classes, Uni ed Modeling Languages, Statecharts
Keywords:
1 Introduction Classes encapsulate both data (attributes) and procedures (member functions, methods) and are the basic building blocks in object-oriented software development. In addition, a class is often regarded to be a basic unit of testing in object-oriented testing literature. Several research e orts have been made at the systematic testing of classes and many of them are speci cationbased using algebraic speci cations or model-based speci cations. They normally involve the generation of test cases as sequences of messages from the speci cations[5, 8, 10, 26, 34]. Recently, several researchers have proposed using nite state machines (FSMs) in class testing[16, 19, 20, 30]. This paper discusses the application of state diagrams in Uni ed Modeling Language (UML)[32] to class testing. UML combines the three popular approaches of Booch[4], Rumbaugh[29], and Jacobson[17] and has been accepted by the OMG as an industry standard for object-oriented analysis and design notation. It comprises a number of diagrams used to describe di erent aspects of a system including static, dynamic, and use-case views. Among them, this paper focuses on test cases generation from the state diagrams in UML. UML state diagrams are widely-used for specifying the dynamic behavior of classes and are substantially based on Statecharts[11] which have been successfully applied to reactive systems. They provide several concepts that distinguish UML state diagrams from conventional FSMs. These include the hierarchical and concurrent structure of states, the communication mechanism through events broadcasting, and the actions associated with states and transitions. An integral part of class testing is the construction of test cases as sequences of messages from a given speci cation. Because there exists an in nite number of possible sequences of messages, exhaustive testing is impossible to achieve and we need to have systematic coverage criteria which select a reasonable number of messages sequences satisfying certain conditions. In this paper, a method is presented that involves the application of conventional control and data ow analysis technique to the generation of test cases from UML state diagrams. After describing related work to class testing, we brie y review the syntax and semantics of UML state diagrams. As our main result, we show how UML state diagrams can be transformed into a form which conventional ow analysis techniques can be applied. A method is given that generates test cases based on control ow in UML state diagrams. We transform UML state diagrams into extended FSMs (EFSMs) in order to atten the hierarchical and concurrent structure of states and eliminate the broadcast communication in UML state diagrams. Control ow in UML state diagrams is identi ed in terms of the paths in the resulting EFSMs. We then transform EFSMs into ow graphs. All the associations between de nitions and uses employed in UML state diagrams can be identi ed in the resulting ow graphs. The transformation enables us to apply conventional data ow analysis techniques to the generation of test cases based on data ow in UML state diagrams.
1
2 Related Work Flow analysis has been extensively used in conventional program testing and analysis. Flow graphs are often used as a graphical representation of a program's structure. The nodes of a ow graph are a block of statements and the edges indicate possible ow of control between nodes. Based on ow graphs, control ow analysis encodes pertinent and possible program ow of control and data ow analysis ascertains and collects information about the possible modi cation, preservation, and use of variables in a computer program[13]. When applied to speci cations rather than programs, they can also provide useful information for the speci cations. In protocol conformance testing, several researchers have proposed the use of ow analysis for the systematic generation of test cases from FSM-based speci cations[2]. Recently, the idea of speci cation slicing, which is a generalization of program slicing, was introduced in [25] and re ned and extended in [6, 14]. In speci cation slicing, ow analysis is done on speci cations in order to identify dependencies among entities in the speci cations. All these applications show that ow information in speci cations can be e ectively used in validating and debugging speci cations, and generating test cases from speci cations. In the last two decades, a number of techniques have been proposed for class testing and many of them model classes using abstract data types using algebraic speci cations or model-based speci cations. Algebraic speci cations consist of signatures de ning the syntactic properties and axioms describing the properties of member functions. Model-based speci cations describe the pre-condition and post-condition of each member function using well-de ned mathematical models such as functions, sets, and sequences. In [5, 8, 10], test cases are generated as sequences of member functions based on the axioms in algebraic speci cations. Since member functions are treated as a mathematical mapping without side e ects in algebraic speci cations, interaction between attributes and member functions cannot be explicitly tested in these approaches. Zweben et al.[34] applied conventional ow graph-based testing techniques to class testing. In their approach, a ow graph is associated with each class using mode-based speci cations. A node in the ow graph represents a member function and an edge between node A and B means that it is permissible to invoke A followed by B. Determining whether an edge exists is based on the pre-condition and postcondition of each member function. Then test cases are generated based on control and data ow in the resulting ow graphs. Parrish et al.[26] extended Zweben et al.'s works so that a ow graph can be obtained with or without speci cations. When in the absence of speci cations, there exists an edge for every pair of nodes and thus all sequences of messages are assumed to be feasible. In general, FSM models of software abound in the testing literature[1]. Since Chow's proposal[7], various FSM-based testing techniques have been proposed especially in protocol conformance testing[2, 3]. Formal description techniques such as SDL, Estelle, and Lotos have been extensively used for specifying communication protocols and a great deal of attention has been given to the generation of test cases based on control and data ow in these spec2
i cations. However, the application of FSMs to class testing is a relatively new concept[15, 16, 19, 20, 30] The state-based approaches to class testing concentrate on the interaction occurring between the attributes and the member functions of classes. They show that FSMs can be e ectively used to test this interaction by representing the values of attributes as the states of FSMs and the member functions as the transitions of FSMs. In [15, 16, 20, 30], they considered state machines in which transitions are associated with an enabling predicate and an action and generated test cases based on control ow[20, 30] and data
ow[16]. This paper extends this work by applying UML state diagrams, wihch have several distinguishing features from FSMs (in addition to the FSm features), to class testing. Kung et al.[19] proposed a class testing technique using a variation of Statecharts, called object state model (OSD). They extract OSD directly from source codes and generate test cases by constructing a spanning tree from OSD. In contrast, we regard UML state diagrams as class speci cations and propose a hierarchy of coverage criteria for UML state diagrams based on control and data ow information.
3 UML State Diagrams The state diagrams in UML are used to show the states an object can have during its life, and the events that cause the state to change along with its responses. The notation and semantics of UML state diagrams are substantially based on Statecharts modi ed to include object-oriented features. Fig. 1 shows a UML state diagram for a simple co ee vending machine. The set of states in UML state diagrams represents both basic states and composite states which contain other states as substates. A composite state is classi ed as either an or-state or an and-state. An or-state has substates that are related to each other by an exclusive-or-relation. In Fig. 1, the state CVM consists of Off and On with Off as the default state. Being in CVM implies being in Off or in On, but not in both. An and-state has substates, called orthogonal components. Being in the and-state On implies being in Supply and Money simultaneously. States can have actions associated with them. Actions are performed in response to events received while the object is in the state, without changing the state. Three reserved events are used in the action compartment: entry, exit, and do. The entry event (resp. exit event) is used to specify actions that is performed at the entry of a state (resp. on exit from a state). The do event is used to specify an action performed while in a given state. For example, the state Busy has a1 , a2 , and a3 as entry, do, and exit actions, respectively. Transitions in UML state diagrams are represented by arrows between states and are labeled by event [guard] / action ^ send. We classify events into external events that are generated by the environment of an object, i.e., other objects, and internal events that are generated by the object itself. In Fig. 1, the event dec is assumed to be internal and all the other events are external. A special event, tm(interval), is used to represent the passage of a period of time. Guard 3
s
CVM
t1 : power-on/ money=0
On
Off
?
6
t2 : power-off
Supply
s
t : coffee[money>0]/dec 3
t4 : tm(3)
Idle
-
Busy
a1 : entry/light=on a2 : do/light=:light a 3 : exit/light=off
Money
t : inc/ s t : inc/money=1 money=money+1 - Empty t : dec[money=1]/money=0 NotEmpty t : dec[money>1]/ 6
5
8
7
money=money-1
Figure 1: An example of UML state diagrams is a boolean expression that must be satis ed for the transition to occur. Action is a list of operations executed as a result of the transition being taken and is assumed to be atomic. Send is a list of events generated when the transition is red. The semantics of UML state diagrams is based on the notion of steps. External events generated by the environment of an object are accepted by an events queue. The semantics assumes that the events in the queue are processed in sequence one at a time. Once an event is dispatched, one or multiple transitions may be enabled. The state machine selects and res a maximal set of enabled transitions that are mutually non-con icting. This basic transformation is called a step. Actions that result from taking a transition may cause events to be generated for this and other objects. Events for the object are broadcast within the present state diagram. After a previous step has completed, the next external event in the queue is dispatched to the state diagram. 4
We will use the following notations, largely based on [27]. Let States and Trans be the nite set of states and transitions in UML state diagrams, respectively. Let : States ! 2States be the hierarchy function which gives, for each state, the set of its substates. For a state s 2 States , (s) denotes the least set S States such that s 2 S and (s0 ) 2 S for all s0 2 S , and + (s) denotes the set (s) ? fsg. If s1 2 (s2 ), then we say that s1 is a descendant of s2 , and s2 is called an ancestor of s1 , and that s1 and s2 are ancestrally related. If, in addition, s1 6= s2 , then s1 is a strict descendant of s2 and s2 is a strict ancestor of s1 . There is a unique state r 2 States , such that (r) = States, called the root state. For a state s 2 States, we use entry(s), do(s), and exit(s) to denote the entry, do, and exit action associated with s, respectively. A con guration is the maximal set of states which a system can be in simultaneously. Precisely, C States is called a con guration if (i) C contains the root state; (ii) for every and-state s, either s and all substates of s are in C , or they are all not in C ; (iii) for every or-state s, either s and exactly one substate of s are in C , or s and all substates of s are not in C . The default completion of a set of states S 2 States , denoted by complete(S ), is de ned as the con guration C containing S such that, for every or-state s 2 C such that s is not a strict ancestor of S , the default substate of s is also in C . For a transition t 2 Trans, we use source(t) and target(t) to denote the source and target states of t, respectively. We use event(t), guard(t), action(t), and send(t) to denote the components of the transition's label. The scope of a transition t, denoted by scope(t), is de ned as an or-state such that scope(t) is a strict ancestor of all the states in source(t) [ target(t), and every such or-state is an ancestor of scope(t). We say that two transitions con ict if their scopes are ancestrally related.
4 Generating Test Cases Based on Control Flow To atten the hierarchical and concurrent structure of states and eliminate the broadcast communication in UML state diagrams, EFSMs are used as intermediate forms in the transformation. An EFSM is a tuple such that GStates is a set of global states. C0 2 GStates is the initial global state. GTrans is a set of global transitions. From a given UML state diagram, we identify an EFSM as follows. First, the set of global states GStates corresponds to the set of con gurations in UML state diagrams. For example, there are ve con gurations in Fig. 1 and these constitute the global states of the EFSM in Fig. 2. 5
s
-
-
?
C1 : CVM,
gt21 :
?
On, Supply,Idle Money,Empty
gt22 :
power-off
?
gt61 :
-
gt :tm(3)
6
/l=off
gt81 :
dec [m=1] /m=0
On, Supply,Busy Money,Empty
6
gt71 :
gt52:
gt :coffee [m >0]/l=on 32
-
gt :tm(3) 42
/l=off
inc /m=1
?
6
dec [m=1] /m=0
6
gt72 :
gt24 :
6
power-off /l=off
>
dec[m 1] /m=m-1
gta2 = (C5 , , true, l=:l, C5 )
Figure 2: An example of extended FSMs
gt82:
On, Supply,Busy Money,NotEmpty
inc /m=m+1
gta1 = (C3 , , true, l=:l, C3 )
6
C5 : CVM,
gt62 :
>
dec[m 1] /m=m-1
C3 : CVM,
41
On, Supply,Idle Money,NotEmpty
inc /m=m+1
gt :coffee [m >0]/l=on
C4 : CVM,
6
power-off /l=off 31
C2 : CVM,
inc /m=1
gt23 :
power-on /m=0
gt51 :
gt1 :
power-off
Off
For the formal description of global transitions, we adopt the following notations.
The greatest departing state of a transition t, denoted by gds(t), is a state s such that source(t) (s), target(t) 6 (s), and every such state is a descendant of s. The departing states of t, denoted by DS(t), is de ned as a set of states (gds (t)). The greatest arriving state of a transition t denoted by gas(t), is a state s such that source(t) 6 (s), target(t) (s), and every such state is a descendant of s. The arriving states of t, denoted by AS(t), is de ned as a set of states (gas (t)) \ complete(target(t)). For example, gds(t ) = Off, DS(t ) = fOffg, gas(t ) = On, and AS(t ) = fOn, Supply, Idle, Money, Emptyg. Let C be a con guration and e be an event. We say that a transition t is enabled in C with the event e, if source(t) C and event(t) = e. We say that a set of transitions T is enabled in C with the event e if every transition in T is enabled and no two transitions in T con ict. In addition, we say that T is maximal if every transition not in T but enabled in C con icts with some transition in T . A global transition in EFSMs is a tuple (C , e, g, a, C 0 ) such that C; C 0 2 GStates and there exists a set of transitions T Trans in UML state diagrams 1
1
1
1
satisfying:
T is enabled in C with the event e and is maximal. S S C 0 = (C ? t2T DS (t)) [ t2T AS (t) S g = t2T guard(t) S a = t2T A1 (t) [ A2 (t) [ A3 (t) S { A1 (t) = s2DS(t)^s2C exit(s) { A2 (t) = action(t) S { A3 (t) = s2AS(t)^s2C entry(s) where A1 (t) is the set of all exit actions executed by the occurrence of transition t. Similarly, A3 (t) is the set of all entry actions executed by the occurrence of transition t. We say that gt represent the set of transitions T in UML state diagrams. In0
tuitively, a global transition is a set of transitions that are executed by the occurrence of one event. For example, consider the event power-on and the con guration C1 = fCVM, Offg in Fig. 1. We have a global transition gt1 = (C1 , power-on, true, money=0, C2 ) in Fig. 2. For another example, consider the event power-off and the con guration C3 . We have a global transition gt23 7
= (C3 , power-off, true, light = off, C1 ) because t2 exists from the state Busy whose exist action is light = off. The entry and exist actions associated in UML state diagrams are included in the actions of global transitions in EFSMs. Now we introduce a special type of global transitions that represent the behavior of do actions in UML state diagrams. For each global state C , we have a global transition gta = (C1 , e, g, a, C2 ) such that C1 = C2 = C . e = , where is the null event. g = true. a = Ss2C do(s), i.e., where a is the set of all do actions in C . The global transition gta means that the set of do actions in a global state C is performed repeatedly as long as the class is in the global state. For example, we have two global transitions gta1 and gta2 for the global states C3 and C5 , because C3 and C5 include the state Busy whose do action is \light = :light". Remark 1. (Enabledness) When simulating or generating reachability graphs using UML state diagrams, the enabledness should be determined by the current values of the variables as well as the current con guration. However, we do not consider the values of the variables because our work centers on identifying possible control and data ow. Remark 2. (Ignoring broadcasting) When de ning global transitions, we eliminate the broadcasting through internal events by treating external and internal events in the same way. This elimination is conservative in the sense that the transformed EFSMs include all the possible execution sequences in UML state diagrams. Control ow in UML state diagrams is identi ed in terms of the paths in EFSMs. Let be an EFSM, and let gsi 2 GStates and gti = (Ci , ei , gi , ai , Ci0 ) 2 GTrans for 0 i n. A sequence (gs0 , gt0 ), (gs1 , gt1 ), ..., (gsn , gtn) is called a path if gs0 = C0 , and gsi = Ci and gsi+1 = Ci0 , for 0 i n ? 1. In general, there are in nitely many paths in EFSMs and hence it is impossible to cover all these paths. We explore the following coverage criteria out of a potentially in nite family of criteria. Let P be a set of paths.
P satis es path coverage if P contains all possible paths through EFSMs.
This is the strongest criterion and generally impossible to achieve. P satis es state coverage (resp. global state coverage) if P includes every s 2 States (resp. gs 2 GStates ). P satis es transition coverage (resp. global transition coverage) if P includes t 2 Trans (resp. gt 2 GStates ). Test cases satisfying these criteria can be constructed in terms of simple breadth or depth rst searches over EFSMs. The following shows a test cases 8
generation method for global state coverage by traversing EFSMs in the breadth rst order. We can similarly de ne the methods for generating test cases satisfying other coverage criteria. Let be an EFSM. make state coverage testing tree(TT ) begin if
all gs 2 GStates are visited then return; each gt = (Ci ; ei ; gi ; ai ; Ci0 ) 2 GTrans do begin 0 if Ci = TT and Ci is not visited then 0 make Ci as a child of TT ;
for
end for
each child cTT of TT do make state coverage testing tree(cTT )
end
For example, Fig 3 shows the testing tree constructed by the above algorithm in which the set of paths fp1, p2 g such that p1 = (C1 , gt1 ), (C2 , gt31 ) and p2 = (C1 , gt1), (C2 , gt51 ), (C4 , gt32 ) satis es global state coverage. The path p1 in the EFSM correspond to the message sequence of (power-on, co ee) in the UML state diagram of Fig. 1 and the path p2 corresponds to the message sequence (power-on, inc, co ee). By sending these message sequences to the class (more precisely, an object instantiated from the class), we can traverse all the global states of the co ee vending machine. In general, certain paths in EFSMs may be unexecutable or infeasible. For example, the path p1 = (C1 , gt1 ), (C2 , gt31 ) is infeasible because the value of money is set as 0 by gt1 and thus the condition money > 0 of gt31 cannot be satis ed. Of course, the selection of feasible paths is undecidable, thus making the application of these criteria undecidable.
C gt ? C gt ? @ gt ? @R C C gt ? C 1
1
2
31
51
3
4
32
5
Figure 3: An example of testing trees
9
5 Generating Test Cases Based on Data Flow Data ow in conventional programs is based on the notions of de nitions and uses of variables in the statements. In UML state diagrams, variables can be de ned and used in the actions of states and in transitions. A variable x is de ned (resp. used) in an action a of a state if a assigns a value to x (resp. references x). A variable x is de ned (resp. used) in a transition t if action(t) assigns a value to x (resp. guard(t) or action(t) references x). Table 1 shows the de nitions and uses of the variables in Fig. 1. Table 1: De nitions and uses of the variables in Fig.1
a1 a2 a3 t1 t2 t3 t4 t5 t6 t7 t8
De nitions light light light money
; ; ;
money money money money
Uses
;
light
; ; ;
money
; ;
money money money
Let be an EFSM. Let gt = (C , e, g, a, C 0 ) 2 GTrans such that represents a set of transitions T in UML state diagrams. Recall that g is the conjunction of the guards of the transitions in T and a is the union of the actions of the transitions in T and the entry and exit actions that are executed by T . We say that a variable x is de ned in gt 2 GTrans if x is de ned in at least one of the actions in a. We say that a variable x is used in gt 2 GTrans if x is used in at least one of the guards in g or the actions in a. In addition to variables, UML state diagrams introduce a new type of data
ow, which we call \data ow through states." In UML state diagrams, both states and variables can a ect the occurrence of transitions in the same way. That is, the pre-condition and post-condition of a transition are de ned in terms of its source and target states as well as the values of variables. Precisely, data
ow through states is de ned as follows: 10
A state s is de ned in a transition t if s is a descendant of scope(t), i.e., s 2 (scope (t)). A state s is used in a transition t if s is an ancestor of the source state of t, i.e., source (t) 2 (s). Table 2 shows the de nitions and uses of the states in Fig. 1. Consider the transition t3 in Fig. 1. Since scope(t3 ) = Supply, we say that Supply, Idle, and Busy are de ned by t3 . Intuitively, Supply and its children can be changed by t3 while the states outside Supply are not changed by t3 . We say that Idle, Supply, On, and CVM are used by t3 , because source(t3 ) = Idle. Intuitively, the source state and all of its ancestors are the pre-condition of transitions, i.e., they should be included in the current con guration for the transition to occur. Table 2: De nitions and uses of the states in Fig.1 Transitions
t1 t2 t3 t4 t5 t6 , t7 , t8
De nitions All the states in Fig. 1 All the states in Fig. 1 Supply, Idle, Busy Supply, Idle, Busy Money, Empty, NotEmpty Money, Empty, NotEmpty
Uses
Off, CVM On, CVM Idle, Supply, On, CVM Busy, Supply, On, CVM Empty, Money, On, CVM NotEmpty, Money, On, CVM
Let be an EFSM. Let gt be a global transition representing a set of transitions T in UML state diagrams. We say that a state s is de ned in gt 2 GTrans if x is de ned in at least one transition t 2 T . We say that a state s is used in gt 2 GTrans if x is used in at least one transition t 2 T . Now we transform EFSMs into ow graphs. A ow graph is a tuple such that
V is a set of variables and states in UML state diagrams. N = Ns [ Nt is a set of nodes. Each node in Ns is called a s-node and each node in Nt is called a t-node. E = Est [ Ets is a set of edges such that Est = f(s; t) j s 2 Ns ; t 2 Ntg and Ets = f(t; s) j t 2 Nt ; s 2 Ns g. def: N ! 2V identi es the variables and states de ned for each node. use: N ! 2V identi es the variables and states used for each node. 11
From a given EFSM , we identify the ow graph as follows: Ns = GStates, Nt = GTrans, For each global transition gti = (Ci , ei , gi , ai , Ci0 ) 2 GTrans, we have two edges e1 and e2 such that e1 = (Ci , gti ) 2 Est and e2 = (gti , Ci0 ) 2 Ets . For s 2 Ns , def(s) = ;. For t 2 Nt , def(t) is the set of all the variables and states de ned in t. For s 2 Ns , use(s) = ;. For t 2 Nt , use(t) is the set of all the variables and states used in t. Fig. 4 shows the part of the ow graphs which is identi ed by considering C2 , C3 , gt31 , and gta1 in Fig. 2.
gta1
6
-
C2 Nodes
C2 gt31
C3 gta1
gt31
def
-
?
C3
use
; flightg [
; fmoneyg [
fSupply, Idle, Busyg fIdle, Supply, On, CVMg ; ; flightg [ flightg [ fSupply, Idle, Busyg fBusy, Supply, On, CVMg Figure 4: A part of ow graphs
Now we can readily generate test cases based on data ow from UML state diagrams, by apply conventional data ow analysis techniques to the resulting
ow graphs. We can also reuse a number of coverage criteria that have been extensively studied and compared in the testing literature such as all-de nition, all-use, and all def-use paths coverage[9, 24]. By applying existing data ow techniques and coverage criteria, we can generate test cases as a set of paths that cover the associations between the de nitions and uses of each variable and state in UML state diagrams. For example, in Fig. 4 we can identify two def-use associations of light: (gt32 , gta2 ) and (gta2 , gta2 ). That is, the de nitions in 12
gt32 and gta2 can reach to the use in gta2 . A path (C1 , gt1 ), (C2 , gt51 ), (C5 , gta2 ), (C5 , gta2), which corresponds to the sequence of (power-on, inc, co ee, a2 , a2 ) in Fig. 1, can be used as the test case that covers these associations. Table. 3 shows all the def-use associations of light and money in Fig. 1. We can identify the def-use associations of money such as (gt1 , gt31) that occurs because of the hierarchical structure of states and (gt51 , gt32 ) that occurs because of the concurrent structure of states in UML state diagrams.
Table 3: Def-use associations the variables in Fig.1 Variables Defs Uses light
money
gt31 gta1 gt32 gta2 gt1 gt51 gt61 gt71 gt81 gt52 gt62 gt72 gt82
gta1 gta1 gta2 gta2 gt31 gt32 , gt61 , gt71 , gt81 , gt62, gt72 , gt82 gt32 , gt61 , gt71 , gt81 , gt62, gt72 , gt82 gt32 , gt61 , gt71 , gt81 , gt62, gt72 , gt82 gt31 gt61 , gt71 , gt81 , gt62 , gt72, gt82 gt61 , gt71 , gt81 , gt62 , gt72, gt82 gt61 , gt71 , gt81 , gt62 , gt72, gt82 gt31
6 Conclusion We have presented a speci cation-based approach to class testing using UML state diagrams. We have proposed a transformation method from UML state diagrams into ow graphs and ow graphs and showed that conventional ow analysis techniques can be applied to the test cases generation from UML state diagrams. Using the transformation we can atten the hierarchical and concurrent structure of states and eliminate broadcast communication, while preserving both control and data ow in UML state diagrams. The resulting set of test cases provides the capability of checking that classes are correctly implemented against speci cations written in UML state diagrams by testing whether class implementations establish the desired control and data ow speci ed in the speci cations. There are several areas that we are currently working on. In [23, 28], tool support for object-oriented testing is discussed including speci cation editing, test cases generation, and test cases execution and validation. This paper only 13
discusses a method for the generation of test cases and thus an automated environment would be needed in order to support the total process of class testing. In particular, when executing test cases and validating test results, we should revolve two technical issues of controllability and observability of class implementation states[33]. Second, this paper focuses on unit testing of classes and do not consider interrelationships between classes. In [18, 22], object-oriented integration testing techniques are discussed in which object-oriented testing is partitioned mainly into the following levels: classes, clusters, subsystems, and systems. In UML, state diagrams can be used as speci cations in all of the four levels. We are planning to extend the works here in order to support object-oriented integration testing using UML state diagrams. In addition, UML provides three diagrams to specify the communication between classes: sequence, collaboration, and activity diagrams. Testing techniques using these diagrams should be developed to complete the testing of dynamic behavior speci ed in UML. The nal issue involves the testing of generalization and specialization of classes through inheritance. In [21], McGregor and Dyer discussed how to incrementally build Statecharts-like speci cations for a class from the speci cations of its superclasses. In [12, 31], they exploited the hierarchical nature of the inheritance relation to test related groups of classes by reusing the testing information for a superclass to guide the testing of a subclass. Combining these works with our works together would provide a method appropriate for testing derived classes obtained by inheritance using UML state diagrams.
References [1] B. Beizer, Software Testing Techniques, Van Nonstrand Reinhold, 1990. [2] G.v. Bochmann and A. Petrenko, \Protocol Testing: Review of Methods and Relevance for Software Testing," in Proceedings of the 1994 International Symposium on Software Testing and Analysis, pp 109-124, 1994. [3] B. Bosik and M.U . Uyar, \Finite State Machine Based Formal Methods in Protocol Conformance Testing: from Theory to Implementation," Computer Networks and ISDN Systems, Vol. 22, pp. 7-33, 1991. [4] G. Booch, Object Oriented Design with Applications, Benjamin Cummings, 1991. [5] L. Bouge, N. Choquet, L. Fribourg, and M.C. Gaudel, \Test Sets Generation from Algebraic Speci cations Using Logic Programs," Journal of Systems and Software, Vol. 6, pp. 343-360. 1986, [6] J. Chang and D.J. Richardson, \Static and Dynamic Speci cation Slicing," in Proceedings of the Fourth Irvine Symposium on Software, 1994. [7] T. Chow, \Testing Software Design Modeled by Finite-State Machines," IEEE Transactions on Software Engineering, Vol. 4, No. 3, pp. 178-187, May 1978. 14
[8] R. Doong and P.G Frankl, \Case Studies on Testing Object-Oriented Programs," in Proceedings of the 4th Symposium on Software Testing, Analysis and Veri cation, pp. 165-177, 1991. [9] P.G. Frankl and E.J. Weyuker, \An Applicable Family of Data Flow Testing Criteria," IEEE Transactions on Software Engineering, Vol. 14, No. 10, pp. 1483-1498, 1988. [10] J. Gannon, P. McMullin, and R. Hamlet, \Data-Abstraction Implementation, Speci cation, and Testing," ACM Transactions on Programming Languages and Systems, Vol.31, No. 3, pp. 211-223, July 1981. [11] D. Harel, \Statecharts: A Visual Formalism for Complex Systems," Science of Computer Programming, Vol. 8, pp. 231-274, 1987. [12] M.J. Harrol, J.D. McGregor, and K.J. Fitzpatrick, \Incremental Testing of Object-Oriented Class Structures," in Proceedings of the 14th International Conference on Software Engineering, pp. 68-80, 1992. [13] M.S. Hecht, Flow Analysis of Computer Programs, Elsevier North-Holland, 1977. [14] M.P.E. Heimdahl and M.W. Whalen, \Reduction and Slicing of Hierarchical State Machines," in Proceedings of the Fifth ACM SIGSOFT Symposium on the Foundations of Software Engineering, Sept. 1997. [15] D. Ho man and P. Strooper, \ClassBench: A Framework for Automated Class Testing," Software Practice and Experience, Vol. 27, No. 5, pp. 573597, 1997. [16] H.S. Hong, Y.R. Kwon, and S.D. Cha, \Testing of Object-Oriented Programs Based on Finite State Machines," in Proceedings of Asia-Paci c Software Engineering Conference, pp. 234-241, 1995. [17] I. Jacobson, M. Christerson, P. Jonsson, and G. Overggard, Object-Oriented Software Engineering, Addision-Wesley, 1992. [18] P.C. Jorgensen and C. Erickson, \Object-Oriented Integration Testing," Communication of the ACM, Vol. 37, No. 9, pp. 30-38, Sept. 1994. [19] D. Kung, N. Suchak, J. Gao, P. Hsia, Y. Toyoshima, and C. Chen, \On Object State Testing," in Proceedings of Computer Software and Applications Conference, pp. 222-227, 1994. [20] J.D. McGregor and D.M. Dyer, \Selecting Functional Test Cases for Object-Oriented Software," in Proceedings of the Paci c Northwest Software Quality Conference, 1993. [21] J.D. McGregor and D.M. Dyer, \A Note on Inheritance and State Machines," ACM SIGSOFT Software Engineering Notes, Vol. 18, No. 4, pp. 61-69, Oct. 1993. [22] J.D. McGregor and T.D. Korson, \Integrating Object-Oriented Testing and Development Processes," Communication of the ACM, Vol. 37, No. 9, pp. 59-77, Sept. 1994. 15
[23] G.C. Murphy, P. Townsend, and P.S. Wong, \Experiences with Cluster and Class Testing," Communication of the ACM, Vol. 37, No. 9, pp. 39-47, Sept. 1994. [24] S.C. Ntafos, \A Comparison of Some Structural Testing Strategies," IEEE Transactions on Software Engineering, Vol. 14, No. 6, pp. 868-874, 1988. [25] T. Oda and K. Araki, \Speci cation Slicing in Formal Methods of Software Development," in Proceedings of the 17th Annual International Computer Software and Applications Conference, pp. 313-319, 1993. [26] A.S. Parrish, R.B. Borie, and D.W. Cordes, \Automated Flow GraphBased Testing of Object-Oriented Software Modules," Journal of Systems and Software, Vol. 23, pp. 95-109, 1993. [27] A. Pnueli and M. Shalev, \What is in a Step: On the Semantics of Statecharts," Proceedings of International Conference on Theoretical Aspects of Computer Science, Lecture Notes in Computer Science, Vol. 298, pp. 245-264, Springer-Verlag, 1991. [28] R.M. Poston, \Automated Testing from Object Models," Communication of the ACM, Vol. 37, No. 9, pp. 48-58, Sept. 1994. [29] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object Oriented Modeling and Design, Prentice Hall, 1991. [30] C.D. Turner and D.J. Robson, \The State-based Testing of Object-Oriented Programs," in Proceedings of Conference on Software Maintenance, pp. 302-310, 1993. [31] C.D. Turner and D.J. Robson, \The State-based Testing and Inheritance," Technical Report No. 1/93, School of Engineering and Computer Science, University of Durham, Apr. 1993. [32] UML Proposal to the Object Management Group Version 1.1, Rational Corporation, Sept. 1997. (http://www.rational.com/uml/) [33] B.W. Weide, S.H. Edwards, W.D. Heym, and T.J. Long, \Characterizing Observability and Controllability of Software Components," in Proceedings of the 4th International Conference on Software Reuse, pp. 62-71, 1994. [34] S. Zweben, W. Heym, and J. Kimich, \Ssytematic Testing of Data Abstractions Based on Software Speci cations," Journal of Software Testing, Veri cation, and Reliability, Vol. 1, pp. 39-55, 1992.
16
