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

net/publication/221189056

Scenario-Based Modeling And Its Applications.

Conference Paper · January 2002

DOI: 10.1109/WORDS.2002.1000060 · Source: DBLP

CITATIONS READS

22 11,611

5 authors, including:

Xiaoying Bai Wei-Tek Tsai

Tsinghua University Arizona State University
89 PUBLICATIONS 2,531 CITATIONS 491 PUBLICATIONS 10,248 CITATIONS

SEE PROFILE SEE PROFILE

Lian Yu
Beijing University of Technology
77 PUBLICATIONS 2,311 CITATIONS

SEE PROFILE

All content following this page was uploaded by Wei-Tek Tsai on 09 April 2020.

The user has requested enhancement of the downloaded file.

 Scenario-Based Modeling And Its Applications
Xiaoying Bai*, Wei-Tek Tsai*, Ray Paul+, Ke Feng*, Lian Yu*

*Department of Computer Science and Engineering

Arizona State University
Tempe, AZ 85287
+
Investment and Acquisition
Department of Defense
Washington, DC

Abstract function provided by the software; 2) Data View:

this identifies and organizes data and their
Use-oriented techniques are widely used in relationships. Data are analyzed and modeled
software requirement analysis and design. Use using concepts like inheritance and composition.
cases and usage scenarios facilitate system They are attached to scenarios as inputs, outputs,
understanding and provide a common language or intermediate, showing how they are used in
for communication. This paper presents a the system; and 3) Usage View: this identifies
scenario-based modeling technique and usages and processes by complex scenario. A
discusses its applications. In this model, complex scenario is formed by combining
scenarios are organized hierarchically and they scenarios or sub-scenarios using control
capture the system functionality at various constructs such as sequencing, conditioned,
abstraction levels including scenario groups, concurrent, and iterative. A complex scenario
scenarios, and sub-scenarios. Combining shows how multiple functions can collaborate to
scenarios or sub-scenarios can form complex implement specific application.
scenarios. Data are also separately identified, Use-oriented software engineering has gained
organized, and attached to scenarios. This wide attentions since early 1990s [4][7]. Use
scenario model can be used to cross check with cases are used to gather anticipated system
the UML model. It can also direct systematic usages without design considerations, and to
scenario-based testing including test case represent them in a common language to
generation, test coverage analysis with respect improve the communications among various
to requirements, and functional regression parties including customers, software analysts
testing. and software developers. A use case can be
instantiated into multiple scenarios, which
describe partial execution orders and message
1. Introduction flows through subsystem components. The
existing literature shows a diversity of methods
Software requirement specifications provide of defining and using use cases and scenarios,
the foundation for system comprehension, design, such as UML (Uniform Modeling Language) [3],
testing and maintenance. This paper proposes a UCM (Use Case Maps) [1], and MSC (Message
semiformal model for identifying and organizing Sequence Charts) [19]. UCM and MSC are
system requirements. developed for real-time systems, specifically
The model represents the system from three MSC is closely related to a state model, and
perspectives: 1) Functional View: this identifies UCM can be mapped to a system structure for
and organizes the desired functions and their analysis. In general, use cases are high-level
relationships. A scenario describes a function descriptions. As recommended by Jacobson, the
from the end user’ point of view. A scenario appropriate volume should be no more than 70-
group is a collection of functional related 80 use cases for large systems, that means 20-50
scenarios or scenario groups. A sub-scenario is a in general cases [7]. In contrast, scenarios are
decomposition of a scenario, representing a sub- detailed descriptions with detailed design
information incorporated. It is common for an

Proceedings of the Seventh International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS 2002)
1530-1443/02 $17.00 © 2002 IEEE
 integrated system to have thousands of scenarios. progressive system comprehension, and bridging
Usually, one may generate many scenarios from the gap between use cases and scenarios.
a single use case. The next section presents the scenario model.
This paper proposes a scenario model to Section 3 observes the relationship between the
specify systems and to generate test cases as scenario model and UML mode. Section 4
shown in Figure 1. The key points are: (1) introduces the approach that the scenario model
Scenarios are derived from system requirements; can support for testing. Section 5 briefly
(2) The scenario model can cross check with the describes the supporting tool. And section 6
software design represented by the UML (section concludes the paper.
3); and (3) Systematic testing can be performed
using the scenario model including test scenarios 2. The Scenario Model
and cases generation (section 4.2), testing
analysis such as test coverage analysis with 2.1 Modeling Scenarios
respect to requirements (section 4.3), and
additional testing such as regression testing Figure 2 shows an example of the scenario
(section 4.4) [10][11][20]. model, in which the functions of a Banking
System are decomposed progressively into
Requirements
multiple levels of scenario groups, scenarios, and
Cross sub-scenarios.
checking
The UML Model The Scenario Model
Banking_Transactions
SG. ... Scenario group
SG1. Create_Account s. ... Scenario
Software Test Additional s11. Create_Saving_Account ss. ... Sub scenario
Design Validate Design Testing
Design s12. Create_Checking_Account

SG2. Deposit
Software Test Test
Implementation Verify Execution Analysis s21. Deposit_To_Saving_Account
Code
s22. Deposit_To_Checking_Account
Figure 1. Scenario-based testing process
SG3. Withdraw_Transactions
SG31. Checking_Account_Withdraw
This scenario model has following features. s31. Successful_Checking_Account_Withdraw
• Scenarios are hierarchically organized for ss311. Log in

better management. The hierarchical ss312. Authentication

ss313. Update_Account
organization reflects scenario functional
SG311. Failed_Checking_Account_Withdraw
dependencies and composition/decomposition s32. Failed_Due_To_Invalid_Password
relationships. (a) An atomic scenario represents a ......
SG32. Saving_Account_Withdraw
basic function; (b) Related scenarios can be ......
composed into scenario groups level-by-level; ......

(c) A scenario can be decomposed into sub- Figure 2. An example of modeling scenarios
scenarios level-by-level; and (d) Connected by
control constructs, scenarios can also be Scenarios
composed into complex scenarios. The A scenario, like s11 and s12, is specified
organization can also improve completeness and semi-formally using a template definition as
consistency checking (section 2.1). shown in Table 1.
• Scenario template specifications provide
information to improve analysis. Such detailed Scenario Groups
information allows scenario dependency analysis, Scenarios can be grouped hierarchically into
such as functional dependency, data dependency, multiple levels of scenario groups. For example,
and control dependency. Dependency analysis scenarios s11 and s12 are arranged into scenario
provides the basis for change management, group SG1, which is further grouped with SG2
ripple effect analysis [5][15][17][18] and and SG3 into super group SG0.
regression testing [8][14]. It is also useful for A typical way of identifying scenarios and
system comprehension such as to remove scenario groups is by functional decomposition.
redundancy and to identify critical parts. The overall functions of a system are first
• Scenario specifications can support divided into distinct features represented by
abstractions at various granularities, enabling high-level scenario groups, which can be

Proceedings of the Seventh International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS 2002)
1530-1443/02 $17.00 © 2002 IEEE
 decomposed level-by-level into sub-groups until • Path-identical: Two scenarios have the same
basic the scenarios are identified. paths. In this case, they may share a certain
A scenario group can be defined using the set of attributes, such as conditions.
same template as scenario definition. In practice, • Path-independent: Two scenarios are said to
developers can defer the filling of the attributes be path-independent if they have completely
of a group to its child scenarios. And the different paths without any overlap.
definition of a scenario group should be Scenarios may also relate to each other with
consistent with specifications of its children. respect to conditions [11][13], and typical
condition relationships are:
Table 1. Scenario template definition • Independent: two conditions are independent
Attribute Explanation if one can happen regardless of the other.
ID
A globally unique identification of the • Trigger/trigger-by: One condition may
scenario that may be generated by system trigger the other condition to activate.
A user-defined identification. Certain
Name naming conventions can be used to
• Mutually exclusive: two conditions are
facilitate retrieval of scenarios mutually exclusive if they cannot exist at the
The circumstances under which the same time.
Context • Related: two conditions are related to each
scenario is used.
The linkage between the scenario other if they are used in the same scenario,
Reference definition and other software artifacts like or they are mutually exclusive.
code and documents Such relationships can assist in risk analysis.
The data, actions, and events required to A scenario may be risky if
Inputs
trigger the corresponding function 1) It contains the software component(s) who
The data, products and deliveries of the has a high probability to fail, and/or whose
Outputs
execution
failure may cause serious consequences.
Parent The scenario group it belongs to
Subs The sub-scenarios contained in it
2) It has a condition that has a high
The scenarios that should be executed probability of failure, and/or whose failure
Precedents can cause serious consequences.
prior to this one.
The scenarios that cannot execute unless 3) It locates on a path that covers many
Successors software components.
current scenario finishes
A brief summary of objectives and Relation analysis can facilitate the validation
Description
functions of the scenario of complex scenarios (section 2.3). It can also
help for dependency analysis such as execution
Sub-Scenarios dependency and condition dependency, and
Scenarios may share some functionalities regression testing [14].
provided by commonly used software
components. For example, “authentication” is Scenario Dependencies
required for all banking transactions. Sub- Dependency analysis is important for system
scenarios decompose a scenario into relatively change management. In this model, scenarios are
independent functional parts. For example, dependent in three ways:
scenario s31 is decomposed into sub-scenarios • Functional Dependency: Scenarios are
s311, s312, and s313. functional dependent if they belong to the
Sub-scenarios are identified with an insight same scenario group in which scenarios
into system high-level design, such as: represent the common function from
• Decomposed by layers different aspects, or they contain the same
• Decomposed by tiers sub-scenario(s) in which the rely on the
• Decomposed by configuration same services.
• Decomposed by service providers • Data Dependency: Scenarios are data
dependent with respect to their template
Scenario Relationships definitions. Two scenarios are
Scenarios may relate to each other with respect 1) Input dependent if they are triggered by
to their execution paths [11][13]: the same data, events, and actions.
• Path-contained: The execution path of a 2) Output dependent if they produce the
scenario can be a part of the path of another same results such as output data and
scenario. products.

Proceedings of the Seventh International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS 2002)
1530-1443/02 $17.00 © 2002 IEEE
 3) Execution dependent if they cover Data are represented and organized using the
common software components such as object-oriented (OO) approach. Each datum is
code modules and interfaces. attached with a form, specifying its ID, name,
4) Condition dependent if they are affected attributes, and purposes description. Data are
by the same conditions. related in two ways: 1) Inheritance, which
5) Reference dependent if they reference to identifies the generalization and specialization
common software artifacts such as relationship; and 2) Composition, which
document, code, and persistent data; identifies the part-of relationships. Related data
• Control Dependency: Two scenarios are are arranged into a hierarchical structure. Figure
control dependent if they are involved in the 3 shows part of an example data model for
precedent /successor relationships as defined payment and the data specification form.
in the template.
Payment ID DATUM_000
Name DiscoverCard
Completeness and Consistency Checking CreditCard
Attributes UserName, Type,
DiscoverCard
To avoid conflictions, duplications, and VisaCard
CardNum, ExpDate
Purpose Represent Discover
omissions, some generic C&C rules are as MasterCard Card Info.
follows: AmericanExpressCard

• Scenario groups are mutually exclusive. DebitCard

Check
That is, for any pair of distinct scenario Cash
groups G and G’, if a scenario s belongs to
Figure 3. An example of modeling data
G, s must not belong to G’;
• There are no duplicate scenarios. That is, for The model integrates the data view with the
any two scenarios s and s’, they differ on at functional view by associating the identified data
least one of the attributes of inputs, outputs, with scenarios. Data are attached to scenario and
and execution path; sub-scenarios as inputs and outputs. Specially,
• There are no overlapping functionalities data that are inputs to a sub-scenario but not
between sub-scenarios within the same inputs to the parent scenario are intermediate
parent scenario. That is, each sub-scenario data to the scenario.
represents a separate part of the overall
function; and
2.3 Modeling Complex Scenarios
• For each scenario identifying expected
system behaviors with normal inputs, at A complex scenario is defined for two
least two corresponding scenarios exist purposes: 1) as a composition of atomic
identifying behaviors under abnormal inputs scenarios to model complex usages of the system
and exceptional conditions respectively. [12]; and 2) as a combination of sub-scenarios to
model the execution order among the sub-
2.2 Modeling Data scenarios belong to a scenario.
In a complex scenario, scenarios/sub-
A scenario is a process that accepts, scenarios are connected using control constructs
processes and transforms data, which may be such as 1) sequencing, to define the following
inputs from end users, internal representations, relationships; 2) looping, to define the repeated
or from persistent storage. Results are generated executions; 3) concurrent, to define the
and presented to user by output data. simultaneous executions; and 4) conditioned, to
Data are captured, specified, and organized add decisions to complex scenario. A pseudo
separately, and are associated with scenarios. code based expression is used to describe the
Data are captured from perspectives like complex scenario.
business object, product, document and message. Suppose there is a data D0 “user account”.
Business objects, such as user account and Taking following three scenarios in Figure 2:
paycheck, are the targets of operations and • s12 “Create_Checking_Account”;
functions. Product, such as coffee dispensed by a • s22 “Deposit_To_Checking_Account”; and
vending machine, is a major form of system • s31 “Successful_Checking_Account_Withdraw”.
outputs. Document, such as report and file, is Figure 4 gives an example of complex scenario.
another popular form of outputs. Message, such
as packed string and list, is a kind of lightweight
information that is passed though subsystems.

Proceedings of the Seventh International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS 2002)
1530-1443/02 $17.00 © 2002 IEEE
 s12; factored into sub-scenarios, the coherent
s22;
SW IT C H ( D 0 ) functional units.
C A SE less than 100: The use cases in UML can be mapped
B E G IN
s22; directly to scenarios or scenario groups. Related
END use cases can be arranged into the hierarchical
C A SE greater than 100:
B E G IN structure according to their relationships: (a) use
IF ( enough balance ) T H E N cases with no super-ordinate can be mapped to
BE G IN s31; E ND
ELSE the high-level scenario groups; and (b) the
BE G IN s22; E ND subordinators (e.g. generalized or included use
END
cases) to a use case can be mapped to the
children to the scenario group representing the
1. Create a user account use case.
2. deposit money to the created user account
3. If the account balance is less than 100, deposit money again In addition, the scenario model can be further
4. if the account balance is greater thatn 100 and has enough to expanded to explore scenarios and sub-scenarios
withdraw, execute the withdraw transaction
5. if the account balance is greater than 100 but has no enough in finer granularity, and to reflect the
credits, exercise the deposit transaction
requirements as completely and exactly as
Figure 4. An example of modeling complex scenario possible.
For example, the scenario model in Figure 2
Scenario relationship and dependency is an extension to the UML use case diagram in
analysis (section 2.1) can be used to check the Figure 5.
validity of a complex scenario. Some rules are:
• Scenarios that are connected via conditioned UML Use Case
Deposit_ Specification
operators, such like if_then_else, and Transactions
Checking_
switch_case, should be condition dependent Banking_ Account_
Transactions Withdraw
with respect to the condition.
• Scenarios that are connected via sequencing
Withdraw_
Transactions
Saving_
operators should be control dependent. Account_

• Scenarios that are connected via concurrent

Withdraw

operators should be input dependent with Figure 5. An example of extension

respect to particular triggering actions or
events. 3.2 Application to UML Static Model
For example, scenarios s12, s22, and s31 are
input dependent with respect to data D0. The UML class diagram provides a static view of
example complex scenario in Figure 4 may application concepts, in terms of classes and
become invalid if s22 is replaced by s21 “deposit their relationships including generalization,
money to saving account”. association, and dependency [3]. In the scenario
model, data are also modeled using OO concepts.
3. Relationship with UML Hence, one can derive the class diagram from the
data model, either directly or indirectly.
3.1 Application to UML Use Case
Model

UML provides a use case view to capture the

behavior of a system, a subsystem, or a class as it Account
CheckingAccount
appears to outside users [3][4]. A use case
SavingAccount
describes an interaction between the system and
its actors. A use case diagram describes the
relationships among use cases such as
association, extension, generalization, and
inclusion.
Scenarios and scenario groups represent the Figure 6. An example of data mapping
externally visible functionalities. A group can be
elaborated into simpler subgroups and scenarios Figure 6 gives an example of data mapping,
at various granularities, and a scenario can be in which the data identified in the scenario model
are mapped to the classes in UML, and their

Proceedings of the Seventh International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS 2002)
1530-1443/02 $17.00 © 2002 IEEE
 generalization relationships are mapped to the activity diagram models the relationships among
inheritance relationships between the classes. a set of sub-scenarios {ss320, ss321, ss322,
ss323, ss324, ss325}. Each sub-scenario in the
3.3 Application to UML Activity Model scenario model is represented by an activity in
the activity diagram. All the precedents of ss322
UML uses activity diagram to model are represented by activities that are
computations and workflows [3]. An activity synchronized before the activity representing
graph is made up of activities, objects, decisions, ss322, while those successor activities are
synchronizations, and swimlanes. An activity synchronized after it.
represents an execution of a task; an object
describes an input/output of an activity; a 4. Application to Testing
decision locates branches based on a guard
condition; a sync bar is the synchronization point 4.1 Test Design
for concurrent threads; and swimlanes separate
the workspace into distinct regions for Each scenario and sub-scenario can be used
organizations and assign activities to as a test scenario to test a subsystem or clusters
organization units. of integrated subsystems [13][20]. Complex test
An activity can be considered as a scenario or scenarios can be generated from complex
sub-scenario, and the presented scenario model is scenarios, by combining scenarios and sub-
an effective peer technique to verify the activity scenarios. In general, numerous complex test
diagram from following perspectives. scenarios can be derived based on various
• Complex scenarios can verify the control criteria such as path coverage, condition
flow of activity diagram, such as (a) whether coverage and loop coverage [13].
activities are modeled in the consistent sequence; While simple test scenarios verify system
(b) whether conditions in the complex scenarios correctness with individual functions, complex
are identified by guards in the corresponding test scenarios can test multiple functions
activity diagram and are placed at the right executed in different orders to reveal defects that
positions; and (c) whether selective logics like are hard or unable to be detected by single tests.
if_then_else and switch in complex scenario are After each scenario is separately tested and
represented by decisions in the activity diagram, approved, testing with complex test scenarios
and the branching conditions are specified can verify system stability, reliability,
correctly. recoverability, performance, and other non-
• Scenario input/output dependencies can functional requirements.
verify the data flow of the activity diagram. In some cases, one may need to develop test
• Scenario precedent/successor pairs can driver and stubs to set up the context and to clean
verify the synchronization of the activity up after execution.
diagram. If a scenario/sub-scenario is modeled Test cases can be generated via examining
as an activity after a synch point, all its the inputs and outputs of the scenario, based on
precedents should be represented by activities various testing techniques such as partition
before the point, and vise versa. testing, boundary value testing, random testing,
and equivalent partition [6][16].
s32. Checking_Account_Withdraw
Scenario
UML Activity Diagram
In most cases, each test scenario is associated
ss320. Start Services
LogIn Start Servic es
with multiple data and each data has multiple
ss321. LogIN

ss322. Authentication attributes. To generate test data, one can apply

Activity
ss323. Update_Account

ss324. Dispense_Money Synch Bar

Authentication different technique to different data and even to
ss325. Print_Reciept different attributes, and test cases are obtained
s. ...
ss. ...
Scenario
Sub scenario
Update
Acc ount
Print Reciept Despense
from various combinations.
Money
A B A is a precendent of B
Figure 8 is an example of test scenario
generation. The complex scenario is instantiated
into six sequences of scenarios, three for looping
Figure 7.An example of verification with 3 times and others for looping with 0 time.
On of the test scenario is then expanded to its
Figure 7 gives an example to illustrate the full definition in terms of setups, inputs, actions,
relationship between the scenario model and the and expected outputs.
UML activity model. In this example, the

Proceedings of the Seventh International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS 2002)
1530-1443/02 $17.00 © 2002 IEEE
 SWITCH (D0)
CASE cond1: BEGIN s1; END
Test Scenario • The percentage of high-risk scenarios
Process CASE cond2: BEGIN s2; END
<SETUP>
........
covered.
CASE cond3: BEGIN s3 ; END
Flow LOOP 0 TO 3
</SETUP>
• The percentage of often-used scenarios
BEGIN s4; END
<INPUT DATA>
........
covered.
</INPUT DATA>
Test s3; s2; s1; s1;
<ACTION>
Scenarios s4; s4; s4;
s2; ........ 4.3 Regression Testing
defined as s4; s4; s4; </ACTION>
list of s4; s4; s4;
s3;
sceniarios <OUTPUT> Change is inevitable and regression testing is
loop covered loop covered ........
with 3 times with 0 times </OUTPUT> important to ensure the correctness and integrity
Figure 8. An example of generating test scenarios of the modified system [8][15][21]. However,
most regression testing techniques are code
Figure 9 gives an example of test case based, such as program dependency graph and
generation using the decision table technique. In program slicing [5][18]. The scenario model
this example, two data, A and B, are attached to a enables scenario dependency and traceability
scenario, each of which has two attributes {a1,a2} analysis, which can be used for scenario slicing
and {b1,b2} respectively. Each of the attributes and ripple effect analysis [14].
can be further divided into two equivalent classes, Based on the generic REA (Ripple Effect
say {a11,a12}, {a21,a22}, {b11,b12}, and Analysis) process [17], Figure 10 shows the
{b21,b22}. In Figure 9, table (a) shows the iterative process of scenario-based regression
definition of the two data, table (b) shows the tests selection: (1) A change request is first
decision table to select values for each attribute mapped to a set of potentially affected scenarios;
and each data, and table (c) shows the decision (2) By traceability analysis, one can trace a
table to generate test cases by combining scenario to its associates and identify and
different data values. validate the set of other affected other software
artifacts; (3) By dependency analysis, one can
a. Data Definition

Datum Attributes
b. Decision Table Identify Data Values

A.a1=ap11 T T F F B.b1=bp11 T T F F
also identify other potentially affected scenarios
A
B
{a1,a2}
{b1,b2}
A.a1=ap12
A.a2=ap21
F
T
F
F
T
T
T
F
B.b1=bp12
B.b2=bp21
F
T
F
F
T
T
T
F
via performing with preferred slicing criteria;
A.a2=ap22
A
F
A1
T
A2
F
A3
T
A4
B.b2=bp22
B
F
B1
T
B2
F
B3
T
B4
and (4) Scenario identification and validation
c. Decision Table Identify Test Cases iterate until no more ripples exist.
A=A1 T T T T F F F F F F F F F F F F
A=A2 F F F F T T T T F F F F F F F F
A=A3 F F F F F F F F T T T T F F F F Change
A=A4 F F F F F F F F F F F F T T T T
Request
B=B1 T F F F T F F F T F F F T F F F
B=B2 F T F F F T F F F T F F F T F F
B=B3 F F T F F F T F F F T F F F T F
B=B4 F F F T F F F T F F F T F F F T Map to Tace to other Validate the affected Validate the
Test scenarios software artifacts software artifacts scenario
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 T16
case

Identify the
Figure 9. An example of generating test cases affected
scenarios

4.2 Test Coverage Analysis Yes More

scenarios?
No
In most existing testing techniques, coverage
Prepare for
is evaluated with respected to the program design, test exectuion

such as statement coverage, condition coverage, Figure 10.The scenario-based REA process
and method/class coverage. The scenario model
enables coverage analysis with respect to
5. Tool Support
requirements represented by scenarios. It also
allows for coverage analysis combined with risk
A tool is developed to support the
analysis and usage analysis [13]. Metrics that
construction of the scenario model. The tool uses
may be used include:
MVC (Model/View/Controller) architecture and
• Number of scenarios used/Total number of supports a GUI as shown in Figure 11:
scenarios.
• At the view part, it supports visual modeling
• Number of scenario groups used/Total using MS Visio 2000;
number of scenario groups.
• At the model part, the graphic presentation
• The coverage of scenarios in each scenario is stored in Visio Shape Sheets, and diagram
group. semantics are stored in test database; and

Proceedings of the Seventh International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS 2002)
1530-1443/02 $17.00 © 2002 IEEE
 • At the controller part, applications are Engineering: A Use Case Driven Approach,
developed in MS Visual Basic to monitor Addison Wesley, Reading, MA, 1992.
user activities and to ensure the consistency [5] J. K. Joiner and W. T. Tsai, Ripple Effect
Analysis, Program Slicing and Dependency
between model and view.
Analysis, TR-93-84, Computer Science
The tool can also export the model in certain Department, University of Minnesota, 1993.
standard data format such as XMI/XML, and [6] P. C. Jorgensen, Software Testing: A Craftsman’s
exchange data and integrate with other products Approach, CRC Press, 1995.
[9]. [7] D. Kulak and E. Guiney, Use Cases:
The scenario model are stored in the database Requirements in Context, Addison Wesley,
and exported into a tree structure in Java. In this Reading, MA, 2000.
way, the tool is being integrated with the End-to- [8] A.K. Onoma, W.T. Tsai, M. Poonawala, and H.
End testing tool [2], which aims to support Suganuma, “Regression Testing in an Industrial
Environment”, Communications of the ACM,
testing management in a distributed environment.
Vol. 41, No. 5, May 1998, pp. 81-86.
Application Programming
[9] R. Paul, W.T. Tsai, B. Li, and X. Bai, “XML-
Based Test Assets Management”, Proc. of IEEE
ER2001, Yokohama, Japan, 2001.
Scenario
Diagram
Presented
Withdraw
d-O
nV
B Option Explicit
Dim ActiveShape As Visio.shape
[10] R. Paul, “End-to-End Integration Testing:
Ad
in Visio
Checking Saving
Dim InData As Recordset
Dim db As Database Evaluating Software Quality in a Complex
Account Account Preivate Sub cmdAdd_Click

Successful Failed
Set Indata=db.OpenRecordset
System”, Proc. of Assurance System Conference,
withdraw withdraw
ShapeSheet Tokyo, Japan, 2001, pp. 1-12.
Actions Action Menu
Login Authorization
Update
Account 1 RUNADDON"compile"
Custom Properties
="Compile" Diagram
Presentation
[11] R. Paul, “End-to-End Integration Testing”, Proc.
Label Value
Prop.Name Name Sequence of IEEE APAQS, 2001.
OD

Prop.template Number 2
BC

Database
[12] W.T. Tsai, X. Bai, L. Yu, and R. Paul,
Withdaw
Checking Account
InputData : Table
Shape ID
Condition
D1
Scenario
: Table
open
OpenAccount
Account
InputData
Password
amount
“Generation of Composite Test Scenarios and
Scenario
Tree
Saving Account
Failed Withdraw
Shape
D2
D3C1
C2
DnShape
ID
Scenario : Table
Scenario
open
OpenAccount
ID Scenario
Account
Scenario
: Table
Condition
amount
SSN
Reference
Test Cases Based on End-to-End Testing
Presented C3 Open Account
Withdraw Diagram
in Java Successful Withdraw
Login
JDBC Cn
S1
S2
S3
S4
Deposit
Checking Account
Summarize
Saving Account
Withdraw
Failed Withdraw Balance
Content
Specification”, Department of Computer Science
Authorization
Updata Account
S5
S6
S7
Successful withdraw
Login
Authorrization
and Engineering, Arizona State University.
S8 Update Account
[13] W.T. Tsai, X. Bai, R. Paul, W. Shao, and V.
Agarwal, “End-to-End Integration Testing
Figure 11.The structure of the supporting tool Design”, Proc. of IEEE COMPSAC, 2001, pp.
166-171.
6. Conclusion [14] W.T. Tsai, X. Bai, R. Paul, and L. Yu, “Scenario-
Based Functional Regression Testing”, Proc. of
IEEE COMPSAC, 2001, pp. 496-501.
The model proposed in this paper improves [15] W.T. Tsai, X. Bai, R. Paul, G. Devaraj, and V.
the scenario-based technique by enforcing the Agarwal, “An Approach to Modify and Test
hierarchical definition and organization of Expired Window Logic”, Proc. of IEEE APAQS,
scenarios modeling at various abstraction levels. 2000, pp. 99-108.
It can serve as a central model to direct the [16] W. T. Tsai, Y. Tu, W. Shao and E. Ebner,
lifecycle process of software development, from “Testing Extensible Design Patterns in Object-
requirements comprehension to testing. It can Oriented Frameworks through Hierarchical
also integrate with other techniques and products Scenario Templates”, Proc. of IEEE COMPSAC,
1999, pp. 166-171.
to improve modeling capabilities. [17] W.T. Tsai, R. Mojedehbakhsh, F. Zhu, “Ensuring
System and Software Reliability in Safety-
References Critical Systems”, Proc. of IEEE ASSET, 1998,
pp. 48-53.
[1] D. Amyot, “Use Case Maps as a Feature [18] Y. Wang, W.T. Tsai, X.P. Chen and S.
Description Notation,” Fireworks Feature Rayadurgam, “The Role of Program Slicing in
Constructs Workshop, UK, 2000. Ripple Effect Analysis”, Proc. of Software
[2] X. Bai, W.T. Tsai, R. Paul, T. Shen and B. Li, Engineering and Knowledge Engineering, 1996,
“Distributed End-to-End Testing Management”, pp. 369-376.
Proc. of IEEE EDOC, 2001, pp. 140-151. [19] MSCs: ITU-T Recommendation Z.120: Message
[3] G. Booch and T. Quatrani, Visual Modeling With Sequence Chart (MSC), ITU-Y, Geneva, 1996.
Rational Rose and UML, Addison-Wesley, [20] DoD OASD C3I I&A, End-to-End Integration
Reading, MA, 1998. Testing Guidebook, 2001.
[4] I. Jacobson, M. Christerson, P. Jonson, and G. [21] DoD OASD C3I I&A, Repairing Latent Year
Overgarrd, Object-Oriented Software 2000 Defects Caused by Date Windowing, 2000.

Proceedings of the Seventh International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS 2002)
1530-1443/02 $17.00 © 2002 IEEE
View publication stats