Case study 1
In the simple case study with an account
object, we have specified the Account object with five states: open,
overdrawn, frozen, inactive and closed. The conditional transition from
a state to the next state is expressed with the associated precondition,
postcondition and invariant. For e.g., the precondition, balance = 0,
must be satisfied for this account object to transition to closed from
open state. We have used state-machines in passive illustrations for
the learner's viewing, and also with student centered learning through
active, interactive sessions. In 1998, the project leader's students
studying a subject titled Object-Oriented Programming Systems have learned
about OO testing using the case study on Accounts as the web-based interactive
teaching resource, in addition to standard classroom lectures. They
have taken part in formative evaluations of the material and completed
on-line quizzes to check their understanding. The students have very
positively received this material. This approach presents a new road
to self-paced learning by enabling learners in distributed locations
to follow the new ROAD - Read the on-line material, Observe the static
and animated O-O diagrams (Passive learning), Absorb, and Do (Active
learning). The interactivity features allow the learner to direct the
test paths taken by the system. The distributed environment also enables
the learner to learn at their pace and to assess their understanding
by doing an evaluation. The students also provide an evaluation of the
teaching material, and their feedback is being used to evolve the courseware.
Case
Study 2
Preamble and Requirement
Multimedia Vibes is a small software
business enterprise that specializes in building multimedia web applications
in Java for their clients. A local council has advertised in the local
press seeking interested software companies to submit bids for a web-based
system. The council plans to install a few of these "kiosk" systems
at the information centres situated near major tourist attractions in
the city. This is part of the council's strategy to promote their area
and to attract tourists to visit the beaches in the area. Multimedia
Vibes wants to win the contract by showing a number of incremental prototypes
built using Java's Multimedia image, animation and sound capabilities.
The system requirement is to build a set of user-friendly incremental
prototypes to enable the visitors (including the tourists) to use these
"kiosks" to interact with the Multimedia virtual beaches. The visitors
should be able to view the Sydney Beach Map from images given such as
the Sydney Beaches Map from Palm Beach to La perouse, and the images
of some of the beaches covered by the map. click on various beaches
and be taken across to the clicked beaches. The system should raise
exception handling if the beach images are not available. In the prototype
implementation, we select one beach and implement the following functionality.
Once the clicked beach is on the screen, the user should be able to
select from a sound file and/or a promotional commentary in text or
view trend statistics such as the number of visitors to the particular
beach over the past year, council parking spots that were vacant (available
for public parking) between 11 am - 3 pm next to the beach area over
the last week in the form of a spreadsheet.
Testing and Implementation
A Multimedia Beaches and Parking system
has been implemented in jdk1.1, with the testing process that incorporates
event based testing and applets. The testing process is illustrated
by visually representing the dynamics of Java applets at work with animation
of state diagrams, communicating state machines, threads and applets
for Beach Applets. Interactivity is used to learn how to test Java applets,
threads, and applet communication.
Case
study 3
An OO software system development is described which is meant to simulate
the functionality of a VCR. The system is used to verify the high level
design of the control program to be installed in the microcomputer unit
of a new model VCR.
We focus on the behaviours required by the VCR user to derive the two
scenarios.
The user triggers the Timer recording as follows: using the remote
control, switch the TV on, press channel 1, press Video, press TV/VCR
and press Menu; Menu appears on the TV monitor; set the timer as per
the given instructions. The built-in timer must activate the VCR to
record the program for the specified time interval. VCR's operation
such as load, eject, play, record, pause, fastforward, rewind, and so
on, and the TV Monitor's display and power are controlled by the hardware
controllers and the remote controller (Navigator).
We use the Unified Modeling Language (UML) to describe our OO testing process.
The VCR offers a number of functionalities such as timer recording, audio dubbing,
and tape dubbing that can be treated as separate use cases. We rank timer recording
as of the highest priority, and so, explore it as the first use case. We use
the first use case diagram to explore system testing and to validate that the
system behaves according to the definition in this diagram.
Fig 1. Use case diagram for the VCR system
The VCR system has a number of interacting
objects such as the VCR, TV Monitor and a Remote Control (Navigator).
In scenario 1 for setting timer details, the VCR system is required
to simulate the remote control operations by setting the timer operations
of the VCR. It uses the TV Monitor as the user interface medium while
setting the timer details.
In scenario 2, we require the remote control object to control the
VCR operations such as play, fast forward (ff), vol+ and others, and
display the video pictures on the monitor. We also require the monitor
surface for visualizing the state diagram that shows the interaction
between VCR & Monitor objects.
We have chosen to discuss test selection techniques for system level
testing for scenario 1, and unit level and integration level testing
for scenario 2. Integration tests use collaborative diagrams and sequence
diagrams to validate the interactions between objects.
Case study 4
TicTacToe Game has been implemented using CORBA (Java IDL ORB) and
JavaBeans (jdk1.2) to illustrate some of the important characteristics
of distributed objects. Here, we focus on event driven corba beans,
concurrency and communication between components. The testing process
is illustrated by visually representing the dynamics of Java Bean's
events at work, animation of deployment diagrams, message sequence diagrams,
state charts, and following synchronization points using activity diagrams,
and concurrent threads of control.
