See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221108561

Test ready UML statechart models

Conference Paper · January 2006

DOI: 10.1145/1138953.1138968 · Source: DBLP

CITATIONS READS
24 236

4 authors, including:

Pvr Murthy Anitha Pc

M S Ramaiah University of Applied Sciences Siemens
13 PUBLICATIONS   58 CITATIONS    8 PUBLICATIONS   60 CITATIONS   

SEE PROFILE SEE PROFILE

Rajesh Subramanyan
Siemens
25 PUBLICATIONS   483 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Requirements Engineering for New Product Development View project

All content following this page was uploaded by Rajesh Subramanyan on 04 June 2014.

The user has requested enhancement of the downloaded file.

 Test Ready UML Statechart Models
PVR Murthy PC Anitha M Mahesh Rajesh Subramanyan
CT, Siemens CT, Siemens CT, Siemens Siemens Corporate
84, Electronics City 84, Electronics City 84, Electronics City Research
Bangalore, India Bangalore, India Bangalore, India 755 College Road East
+91 80 25113674 +91 80 25113628 +91 80 25113605 Princeton, NJ 08540, USA
PVR.Murthy PC.Anitha M.Mahesh +1 609.734.3651
@siemens.com @siemens.com @siemens.com Rajesh.Subramanyan
@siemens.com

ABSTRACT For a valid date of flight, it may be important to test the

The dynamic behavior of systems is best described by Finite-state application with a date that corresponds to a leap year and
machines. Generation of executable tests from behavioral models February 29th. Thus, an extended UML Statechart model for
such as UML Statecharts offers benefits such as systematic testing testing purposes should allow a tester to model different
and test adequacy. We choose UML Statechart models of characteristics of events. We propose modeling events using data-
behavior as the basis for test generation. This paper attempts to flow graph nodes (data generator node, data selector node, data
lay a new foundation for UML Statechart based test generation by aggregate node). b) The test generator generates test cases as
introducing Test Ready UML Statechart models that can be used instances of paths in the extended UML Statechart model. If the
by testers in the testing phases just as the conventional UML event date of flight is modeled using a data selector node and is
Statecharts are required during the design and development attached to a state transition, the test generator may select one of
phases. In order to achieve the goal of automatic test generation the inlinks (say leap year) of date of flight data selector node
based on UML Statecharts, we identify what is required over and before proceeding with the generation of the rest of the path. The
above UML Statecharts for testers to specify so that the resulting test generator may encounter a guard condition along a
test ready models are amenable for automatic generation of subsequent state transition checking if an inlink that specifies leap
executable test scripts. The test generation problem from a Test year for the event date of flight has been selected. If the guard
Ready UML Statechart is solved by determining all the sentential condition is satisfied, the test generator proceeds with the rest of
forms derivable from an equivalent extended context free the path, otherwise, it backtracks to a suitable node and explores
grammar model. another path for test generation. Thus, specification of guard
conditions along state transitions is a powerful mechanism for the
Categories and Subject Descriptors test generator to select test scenarios that are coherent and c) in
D.2.5. [Software Engineering]: Testing and Debugging – Testing the extended UML Statechart model, test statements may be
Tools specified along state transitions or state nodes. Once a path is
generated which is a sequence of state transitions, test statements
General Terms along the state transitions and in the state nodes are concatenated
Algorithms, Reliability, Verification together to form an executable test case. d) The extended UML
Statechart model provides a framework for generation of tests for
Keywords any test execution environment. The test generator considers the
Model based Testing, UML Statecharts, Context-free grammar test statements as mere strings to be emitted in an order dictated
by a path generated.
1. INTRODUCTION
UML statecharts may be used to describe the behavior of event-
Finite-State machine model based testing has been studied
driven systems such as communication protocols or graphical user
extensively [1,2,4,5,6,15,16]. Automatic test generation from
interface systems. In Software Testing, a key requirement is to
SDL and Message sequence charts [7] has been attempted.
ensure test adequacy with respect to the features or requirements
However, our work differs from the previous work in the
of the Software Under Test (SUT). In model based testing
following ways: a) we suggest visual formalism for specifying
approaches, tests are derived automatically from models such as
events along state transitions. For example, to specify the event
UML statecharts. Confidence in Test Adequacy may be achieved
“entry of date of flight”, both invalid and valid dates of flight need
easily by ensuring that tests corresponding to different workflows
to be modeled for test generation.
or paths in a model are created or automatically generated
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are Section 2 discusses about Test Ready UML Statechart Modeling.
not made or distributed for profit or commercial advantage and that copies Section 3 presents a few examples of paths in the Test Ready
bear this notice and the full citation on the first page. To copy otherwise, UML Statechart model in Figure 1 and discusses about feasible
or republish, to post on servers or to redistribute to lists, requires prior paths and the test generation process. Section 4 presents the
specific permission and/or a fee. equivalent extended context free grammar model (of the Test
SCESM’06, May 27, 2006, Shanghai, China. Ready UML Statechart model in Figure 1). Section 5 presents the
Copyright 2006 ACM 1-59593-085-X/06/0005...$5.00 path generation algorithm. Section 6 discusses about how the user

75
provides test statements along state transitions in a test ready conditions, tasks and test statements along state transitions.
UML Statechart model so that a test generator can generate Events are modeled as data-flow graphs or as an extended
executable tests. The user may import existing UML Statechart context free grammar. Guard conditions, along state transitions,
models from a tool such as IBM Rational Rose or create the UML are used to specify a boolean condition that must be satisfied to
Statechart models using a standalone editor. select the transition. Tasks and Test statements may be specified
in states. When the test generator selects a state transition, the
task specified along the transition is executed which may set user
2. TEST READY UML STATECHART variables introduced in the model. The extended UML Statechart
MODELING model is called test ready, as the model is amenable for test
generation.

Figure 1 provides a Test ready UML Statechart model to specify

the following ATM transaction behavior. Once a card is inserted
and PIN validated, the transactions deposit, withdrawal and
information display may be carried out. If invalid PIN entries are
made, there is a limit to the number of re-entries. To generate
executable tests from the UML Statechart model provided in
Figure 1, the events PIN, WithdrawalAmount and
ContinueTransaction are modeled as data-flow graphs as shown in
Figure 1. Test statements are specified along relevant state
transitions and in states. Guard conditions are placed along state
transitions (for example, [PIN ~ Invalid] along the state transition
from state ValidatePIN to Re-enterPIN). Note that the data
generator nodes ValidPIN and InvalidPIN generate a valid PIN
and an invalid PIN respectively(from a specified list of values). A
list of valid PIN entries may be associated with the node
ValidPIN by the tester. In a given path, either a ValidPIN or an
InvalidPIN is selected from the data selector node PIN. Similarly,
to model the event that a withdrawal amount less than the Balance
or, greater than or equal to the Balance may be input by the user,
the data selector node WithdrawalAmount is used.
ValidWithdraw and InvalidWithdraw are data generator nodes
each of which is modeled by the tester to generate a valid
withdrawal amount or invalid withdrawal amount respectively.
The tester introduces a variable called Balance into the model in
Figure 1. Each time a deposit is made into the account, the
variable Balance is updated (this is done through the execution of
a task specified along the state transition AcceptCheque ->
ContinueNextTransaction. In our tool Tasks are modeled as
methods in Java).

3. PATHS IN THE TEST READY UML

STATECHART MODEL
Consider the paths in the UML Statechart in Figure 1(curly braces
indicate cycles).
Path1: Start -> (event:InsertCard) ->CardInserted ->{AcceptPIN
-> (event: PIN) -> ValidatePIN -> guard condition: [PIN ~
Invalid] -> Re-enterPIN -> guard condition: [NoOfTrials <=
Limit]} -> guard condition: [NoOfTrials > Limit] ->
AbortTransaction
The sequence of state transitions in curly braces forms a cycle and
the cycle terminates through the state transition Re-enterPIN ->
AbortTransaction.
Path2: Start -> (event:InsertCard) -> CardInserted -> AcceptPIN
. Figure 1 – ATM Transactions ->(event:PIN) -> ValidatePIN -> guard condition: [PIN~Valid]
The extended UML Statechart shown in Figure 1 depicts ATM -> ATMTransactionBegin -> (event:Operation) ->
Transaction scenarios. OperationSelected -> guard Condition: [Operation ~ Information
Display] InformationDisplayed -> ContinueNextTransaction ->
Definition: A Test Ready UML Statechart Model is obtained by guardCondition: [ContinueTransaction~No] -> ReturnCard ->
annotating a UML Statechart model with events, guard End.

76
Test cases are instances of paths in the Test Ready UML model and also specifies a depth factor used as a limit to expand
Statechart Model. Note that an event modeled using a cycles, (b) The Test generator first generates paths that may have
combination of data selector node, data aggregate node and/ or a cycles and (c) for test case or test script generation, a cycle is
data generator node is an extended context free grammar. We expanded a random number of times limited by the depth factor.
refer to it as an extended context free grammar because guard Note that the cycle expansion step (c) is required only if a cyclic
conditions may be specified along the input links of data selector state transition is not guarded. If a cyclic state transition is
nodes. guarded as the cycle in Path 1 above, then cycle expansion is
carried out in step (b) above by the Test generator.
Definition of an Extended Context Free Grammar Model: A test
Ready UML Statechart model is an extended context free 4. EXTENDED CONTEXT FREE
grammar model. Events attached to state transitions are modeled
using a data selector node, a data aggregate node or a data GRAMMAR MODEL
generator node. A data generator node is a terminal in a CFG The variable Balance is initialized and it is updated whenever
(ValidPIN, InvalidPIN, ValidWithdraw, InvalidWithdraw, there is a deposit or a withdrawal by executing a task specified
NextTransaction, ExitTransaction), a data aggregate node is a along the respective transitions as shown below in the extended
non-terminal whose right hand side production consists of one or Context Free Grammar Model (of the Test Ready UML Statechart
more non-terminals and a data selector node is a non-terminal Model shown in Figure 1). The grammar below is a CFG
with alternate production rules (PIN, WithdrawalAmount, extended with guard conditions along state transitions (enclosed
ContinueTransaction, Operation). within square brackets), tasks and scripts along transitions or
alternate productions (for a detailed explanation about why a test
Definition of a Feasible Path: A feasible path is a path ready UML Statechart model is a CFG, refer to Section 3. Events
originating from the start node and terminating in a final state are shown in italics in the extended context free grammar below).
and for which all guard conditions along its state transitions are
satisfied during test generation. //ATM State Diagram Transitions
Start -> InsertCard CardInserted
The test generation problem thus reduces to determining feasible
CardInserted -> AcceptPIN
paths in the Test Ready UML Statechart model, which is an
AcceptPIN -> PIN ValidatePIN
extended context free grammar model, and creating instances of
ValidatePIN -> ATMTransactionBegin , if [Pin~Valid]
the paths. An event node (a data selector node which is a non-
-> Re-enterPIN , if [PIN~invalid]
terminal with alternate production rules) attached to a state
transition also contributes to a sub-path of a path from the initial
Re-enterPIN -> AcceptPIN, if [ NoOfTrials <= Limit]
state to a final state in the test ready UML Statechart model. The
-> AbortTransaction,
generation of paths starts from the start node with a state
if [NoOfTrials > Limit]
transition and exploring each one of the state transitions of the
ATMTransactionBegin -> Operation OperationSelected
next node, provided guard condition, if any, along a state
OperationSelected -> AcceptCheque, if [operation~Deposit]
transition is satisfied. Guard conditions are based on the input link
(Task: update var Balance)
(a grammar rule) selected for a data selector node (or a non-
-> AcceptAmount,
terminal). Or, a guard condition is a boolean condition on user
if [Operation ~ Withdraw]
variables introduced by the tester in the model such as Balance >
-> InformationDisplayed,
1000 and set by tasks, if specified, along state transitions. A guard
if [Operation~InformationDisplay]
condition may also be a combination of both the above forms. All
-> Exit, if [Operation ~ Exit]
guard conditions are evaluated during path generation. A depth-
first traversal over the graph, which is a combination of the UML
AcceptCheque-> ContinueTransaction ContinueNextTransaction
Statechart model and the event nodes represented as data-flow
graphs, is used in determining feasible paths. If a guard condition
InformationDisplayed ->
is not satisfied, backtracking may be required which initially starts
ContinueTransaction ContinueNextTransaction
by exploring other transitions or inlinks of the current node and if
none of them lead to a feasible path, then backtrack to the
AcceptAmount -> WithdrawalAmount CheckAmount
previous node and explore alternative state transitions or inlinks
of event nodes. If backtracking continues right upto the start node
CheckAmount -> InsufficientBalance ,
or root node without finding any feasible paths, the test generator
if [WithdrawalAmount >= Balance]
reports that it cannot find any more feasible paths.
-> DispatchAmount ,
Cycles are detected by maintaining a list of the nodes visited if [WithdrawalAmount < Balance]
already in the path formed so far and if the next node is already
present in the list of visited nodes of the path prefix, the cycle is InsufficientBalance -> AcceptAmount
marked. Once a state transition from the current node resulted in a
cycle with a node already visited, then an alternate transition from DispatchAmount->
the current node may terminate the path ending in a final state. ContinueTransaction ContinueNextTransaction
Such a path has one or more cycles marked. (Task: update var Balance)
The tool built based on Test Ready UML Statechart models has
three phases (a) Tester creates a Test Ready UML Statechart ContinueNextTransaction ->

77
 ATMTransactionBegin, if [ContinueTransaction~Yes] transition, pathPrefix#transition) detects the alternate transition(s)
from the node through which a final state can be reached. The
ContinueNextTransaction -> function considers different paths that may arise, if multiple state
ReturnCard, if [ContinueTransaction~No] transitions from node participate in cycles.

ReturnCard -> End The path generation algorithm is based on depth-first traversal.

//Events used in ATM example and their grammar Rules PathGen(node, pathPrefix )

PIN -> validPIN begin

-> InvalidPIN if (transition = getNextTransition(node)) then
nextNode = transition.destn
WithdrawalAmount -> ValidWithdraw else
-> InvalidWithdraw begin
backtrack(node, transition)
ContinueTransaction -> NextTransaction return
-> ExitTransaction end

Operation -> Deposit if nextNode is a finalStateNode then

-> Withdraw if guardCondition(transition) then
-> InformationDisplay begin
-> Exit executeTask(transition)
appendPath(pathList)
The next section presents a path generation algorithm that we use end
based on depth-first traversal. else
begin
backtrack(node, transition)
5. PATH GENERATION ALGORITHM return
The function PathGen(node, pathPrefix) is initially invoked on the
end
start or the root node of the extended Context Free Grammar (start
node of the Test Ready UML Statechart Model). Initially,
else if ( nextNode not present in pathPrefix) then
pathPrefix is set to null as it indicates the portion of the path
if guardCondition(transition) then
traversed so far. The function getNextTransition(node) checks if
begin
there is a transition from node through which a path is not yet
executeTask(transition)
explored, each time a node is visited (it basically checks the set of
PathGen(nextNode, pathPrefix#transition )
transitions from node minus the set of transitions from node
end
explored so far). The function guardCondition(transition) returns
else
true if the test generator determines after evaluation that the guard
begin
condition specified along the transition is true. If no guard
backtrack(node, transition)
condition is specified, then the guard condition is assumed to be
return
true. The function executeTask(transition) executes the task
end
specified along the transition. Execution of tasks may set Test
else
Ready Model variables. The function backtrack(node) in a given
if guardCondition(transition) then
state maintained by the test generator checks if there is an
begin
alternate transition from node that is not yet explored. If all
executeTask(transition)
transitions from node are already explored and no path could be
expandCycle(node, transition)
generated, then the test generator backtracks to the previous node.
genSuffixPathsExcluding
The state maintained by the test generator consists of the state
TransitionLeadingToCycle(node,
transitions explored so far from the current node, the path prefix
transition,
generated so far and the parent node. In addition, the state of
pathPrefix#transition)
variables in the Test Ready Model is also maintained so that
end
whenever there is backtracking, the user variables are reset to the
else
values that they should hold at the backtrack point which may be
begin
a previous node or an alternate state transition, or an alternate
backtrack(node, transition)
inlink of a data selector event node. The function
return
expandCycle(node, transition) expands the cycle as many times as
end
required , if the cyclic sub-path consists of guard conditions.
Otherwise, the cyclic subpath is just marked as a cycle. When test
end
scripts are generated, the cycle is expanded limited by the depth
factor specified by the user. The function
genSuffixPathsExcludingTransitionsLeadingToCycle(node,

78
6. TEST SCRIPT GENERATION IsAtmAwaitingPinEntry(). These boolean functions provide an
Consider the path access to the current state of the running ATM Software. The test
execution environment may be visualized as consisting of a thread
Start -> (event: InsertCard) -> CardInserted -> {AcceptPIN -> running ATM Software itself and another running a test case (the
(event: PIN) -> ValidatePIN -> guard condition: [PIN ~ Invalid] synchronization code is not shown).
-> Re-enterPIN -> guard condition: [NoOfTrials <= Limit]}
-> guard condition: [NoOfTrials > Limit] -> AbortTransaction //---------Start of TestCase1----------
A test case is an instance of a path in the model. The tester class TestCase1
provides along a state transition in the Test Ready UML {
Statechart model in Figure 1 just the portion of the test case or TestCase1()
script that should be emitted, if the state transition is a part of the {
path from which the test case under construction is instantiated. It try
may be noted that a state transition may be a part of two or more {
paths, for example, Start ->CardInserted, or, ValidatePIN -> int NoOfTrial=1;
ATMTransactionBegin. Test statements (say in Java) may be int limit=3;
specified along only chosen state transitions or as a part of chosen int balance=10000;
states to validate if the software under test reaches an expected
state on the occurrence of a specified event. The tester, however, if(!atmProbeFunction.IsAtmInInitialState())
should have a coherent view of the snippets of code specified {
along state transitions so that the part of the test code specified throw new Exception("Atm not initialized : failed");
along a state transition is coherent with the following test code in }
subsequent state transitions in a path. If a state transition is a part
of multiple paths, the tester has to ensure that the test statements if(!atmProbeFunction.AtmAwaitingCardInsertion())
provided along the common state transition are coherent for all {
paths containing the state transition. throw new Exception("Card not inserted: failed");
}
In state based testing, it is essentially state sequencing that is //Set Card ID
checked. The testing problem for each test scenario is to consider
the sequence of events specified by the corresponding path in the if(!atmProbeFunction.IsAtmAwaitingPinEntry())
Test ready UML Statechart Model (behavioral diagram) and {
verify that as each event occurs, the ATM Software reaches the throw new Exception("Pin entry : failed");
next state as specified by the Statechart. In general, a snippet of }
test code along a state transition checks if the Software Under
Test (ATM Software) has not reached the expected state. If for an if(NoOfTrials<=limit)
event that triggers a state transition, the Software Under Test does {
not reach the expected state, the implementation does not conform NoOfTrials++;
to the UML Statechart model. When a test is run, the test }
statements specified along a state transition throw an exception or
generate an error message under the condition that the Software if(!atmProbeFunction.IsAtmAwaitingPinEntry("2345"))
Under Test does not reach the expected state condition on the {
occurrence of the event along the state transition. throw new Exception("Pin entry : failed");
Consider the path }

Start -> (event: InsertCard) -> CardInserted -> {AcceptPIN -> if(NoOfTrials<=limit)
(event: PIN) -> ValidatePIN -> guard condition: [PIN ~ Invalid] {
-> Re-enterPIN -> guard condition: [NoOfTrials <= Limit]} NoOfTrials++;
-> guard condition: [NoOfTrials > Limit] -> AbortTransaction }

For the path shown above, the ATM Software implementation if(!atmProbeFunction.IsAtmAwaitingPinEntry())
may deviate from the expected behavior if it does not reach an {
expected state condition along anyone of the state transitions in throw new Exception("Pin entry : failed");
the path on the occurrence of the corresponding event. The ATM }
Software passes a test case instance of the above path only if the
implementation successfully satisfies all the conditions of the if(NoOfTrials<=limit)
intermediate states as per the model and finally reaches the {
condition satisfied by the state AbortTransaction. NoOfTrials++;
A sample test case in Java emitted as an instance of the above path }
is given below. To carry out model based testing based on State if(NoOfTrials>limit)
diagrams, the Software Under Test must be testable. For {
testability, the ATM Software provides a number of probe
functions such as IsATMAboutToAbortTransaction() or if(!atmProbeFunction.IsATMAboutToAbortTransaction())

79
 { already instantiated, tasks and / or test scripts along state
throw new Exception("Atm has not reached AbortTransaction : transitions. Alternatively, a tester may create a UML
failed"); statechart/test ready UML statechart from scratch for testing
} purposes instead of relying on the model used during the
else development cycle. Our methodology has been found effective in
{ creating test ready UML statechart models for modeling
commercial applications such as bank transactions or an event-
System.out.println("ATM Passed test"); driven system such as the audio system in a car. We have also
} seen that Test Ready UML Statechart models can be used to
} describe the behavior of Graphical User Interface systems and
} generate test scripts automatically that can be executed by GUI
catch(Exception e) Capture play-back tools without user intervention. Our future
{ research work shall focus on generation of tests from test ready
System.out.println(e.getMessage()); UML statecharts that use concurrency. A state diagram that has
} nested states is flattened before path or test generation.
}
}
10. ACKNOWLEDGEMENTS
The authors would like to thank Juergen Kazmeier, Marlon Vieira
//----------End of TestCase1----------
of Siemens Corporate Research, Princeton and Mukul Saxena of
Corporate Technology, India for their valuable support.
7. REGRESSION TESTING
For a new version of the software under test, if its dynamic
behavioral model changes, then the UML Statechart model
11. REFERENCES
[1] Chow,T.S. Testing Software design modeled by Finite-state
changes and hence the test ready UML Statechart model also
machines. IEEE Transactions on Software Engineering SE-
changes. A diff of the ECFG models provides information about
4, 3 (1978), 178-187.
the set of the paths that are not present in the previous Test Ready
UML Statechart model. [2] J.A.Whittaker and M.G.Thomason: “A Markov Chain
Model for Statistical Software Testing”, IEEE Transactions
on Software Engineering, 20(10): 812-824, October 1994.
8. COVERAGE
The concepts of structural coverage based on code exercised are [3] Khaled L.Fakih, Nina Yevtushenko, Gregor Von Bachmann:
well studied, for example, statement coverage, branch coverage FSM-based Incremental Conformance Testing Methods,
and path coverage. We state that path coverage in a test ready IEEE Transactions on Software Engineering. Vol 30,
UML statechart model is achieved if tests corresponding to all the Number 7, 425-436.
paths or sentential forms in the corresponding ECFG model are [4] Robert V Binder. Testing Object-Oriented Systems: Models,
generated. Wherever there are cycles present, we consider (base) Tools and Patterns, Addison-Wesley, 2000.
path coverage is achieved if each and every cycle in the paths of
[5] Teradyne TestMaster, http://www.teradyne.com
the state model is traversed or exercised at least once in the tests
generated. [6] Friedman G., Hartman A., Nagin K.,Shiran T., Projected
State Machine Coverage for Software Testing, Proceedings
of ISSTA 2002 International Symposium on Software Testing
9. DISCUSSION and Analysis (July 2002).
UML Statechart models are used in practice by designers and
developers for describing the dynamic behavior of event-driven [7] Baker P., Bristow P., Jervis C., King D., Mitchell B.,
systems. Test scenarios based on UML statechart models can be Automatic Generation of Conformance Test From Message
visualized as instances of paths in the model. However, for test Sequence Charts, 3rd SAM Workshop - "Telecommunication
generation purposes, what is required is event generation and Beyond The broader applicability of SDL and MSC",
capability that can capture different variations or characteristics of Aberystwyth, UK. 24-26th June 2002.
events. Just as there are tools being used by developers to create [8] Bassanieri F., Bertolino A., and Marchetti E., The Cow Suite
UML statechart models to describe the dynamic behavior of approach to planning and deriving test suites in UML
systems during the development cycle, there is a need for projects, Proceedings of the Fifth International Conference
corresponding models, methodologies and tools for testers. To on the Unified Modeling Language - the Language and its
address this need, we have defined a Test Ready UML Statechart applications UML 2002, LNCS 2460, Dresden, Germany,
model, which indicates the model is ready with information for a September 30 - October 4, 2002, p. 383-397.
test generator to be able to generate test scripts automatically from
[9] Supaporn Kansomkeat., Wanchai Rivepiboon., Automated-
it.
Genearting Test Case Using UML statechart diagrams, ACM
A tester may import UML Statechart models from a developer’s International Conference Proceeding Series; Vol 47,
tool such as IBM Rational Rose into the visual editor of our UML Proceedings of the 2003 annual research conference of the
Statechart test generation tool and then add necessary information South African institute of computer scientists and
or attributes such as event nodes, guard conditions along state information technologists on Enablement through
transitions based on the properties of the event nodes that are technology.

80
 [10] Basanieri, F., Bertolino, A., Marchetti, E., Ribolini, A., [14] Offutt, J., and Abdurazik, A. 1999. Generating test cases
Lombardi, G., And Nucera, G. 2001. An Automated Test from UML specifications. In Proceeding of the 2nd
Strategy Based on UML Diagrams. In Proceeding of the International Conference on the Unified Modeling Language
Ericsson Rational User Conference, October 10-11, 2001, (UML99), Fort Collins, CO, October 1999.
Upplands Vasby Sweden. [15] Kim, Y.G., Hong, H.S., Cho, S.M., Bae, D.H., and Cha,
[11] Hartmann, J., Imoberdof, C., and Meisenger, M. 2000. S.D. 1999. Test cases generation from UML state diagrams.
UML-Based Integration Testing. In ISSTA 2000, Portland, In IEEE Software, 146(4): 1999, 187-192.
August 2000. [16] Pretschner A., Slotosch.O, Aiglstorfer.E., and Kriebel.S.
[12] Lionel C. Briand , Yvan Labiche, A UML-Based approach to March 2004. Model Based Testing for real--The inhouse
System Testing, Proceedings of the 4th International card case study in Journal of Software Tools for Technology
Conference on the The Unified Modeling Language, Transfer, ©Springer-Verlag 5(2-3): 140-157.
Modeling Languages, Concepts, and Tools , October 01-05,
2001, pp.194-208,
[13] Offutt, J., and Abdurazik, A. 2000. Using UML collaboration
Diagrams for Static Checking and Test Generation. In UML
2000, University of York, UK, 2-6 October 2000.

81

View publication stats