Simulation
and Example
Simulation
Simulation is used to study the
performance of a physical system by using
a physical, mathematical, or computer
model of the system
 Steps to take when you do simulation

◦ Algorithm
◦ Programming techniques and coding
◦ Testing
Simulation
Simulation is used to study the
performance of a physical system by using
a physical, mathematical, or computer
model of the system
 Steps to take when you do simulation

◦ Algorithm
◦ Programming techniques and coding
◦ Testing
Example

Write a program that simulates the operation of a busy
airport that only has one run way to handle takeoff and
landings. You may assume that each takeoff or landing takes
15 minutes to complete. One runway request is made during
each 5 minute time interval and the likelihood of a landing
request is the same as for a takeoff request. Priority is given
to planes requesting a landing. If a request can not be
honored, it is added to a takeoff or landing queue. This
program should simulate 120 minutes of activity at the
airport. Each request for runway clearance should be timestamped to the appropriate queue. The output from your
program should include the final queue contents, the number
of takeoffs completed, the number of landings completed and
the average number of minutes spent in each queue
Part 1: Determine Main Algorithm
Start
Clock =0
Total time = 120
Time done=0
Clock <
Total
time?
No
stop
Yes
Toss a coin
Head?
Clock += 5
Yes
Check landing
arrival
Serve the
next one
Yes
Current
serve done?
No
No
Check takeoff
arrival
Part 2: Determine main data
structure

Queue:
◦ Takeoff
◦ Landing

That queue has every attribute/action that a
normal queue has and the following special
attributes/actions
◦
◦
◦
◦
Number of takeoff or landing served
Total time wait
Check new arrival in landing or takeoff queues
Update statistics
Part 2: Determine main data
structure

Request:
◦ processingTime
◦ arrivalTime
◦ (may be requestID)
Part 3: Make the main algorithm
more specific

Check takeoff or landing arrival
Given an arrival time
Create a new request
Print status for each
queue
Part 3: Make the algorithm more
specific

Serve the next one
Landing queue
is NOT empty
Yes
No
Takeoff
queue is
NOT empty
No
The run way is idle now
Yes
currentRequest =
get the first
element in the
landing queue
Current
request = get
the first
request in the
takeoff queue
Timestamp = get
arrival time of
current request
Wait =current clock timestamp
TotalWait +=wait
Number of landing/takeoff served ++
Implementation

Classes:
◦ Queue (Using Lab3Queue with just a little bit
change in Lab1LinkedList)
◦ Request
◦ RunawayQueue (extends from Queue)
◦ AirportSim that actually starts the simulation
and contain the main algorithm.
Testing

Discussion:
◦ How can we test this simulation program:
◦ Criteria:
 Robustness: not crashing
 Accuracy: correctly computed
Testing

Unit test
◦ Make sure Queue is working, RunawayQueue
is working and Request is working correctly

Integration test
◦ Test if AirportSim is working correctly
 Leave a trace of execution by displaying the method
name as you enter it
 Display values of all input parameters upon entry to
a method
Testing Programs
There is no guarantee that a program that
is syntax and run-time error free will also
be void of logic errors
 The “best” situation is a logic error that
occurs in a part of the program that
always executes; otherwise, it may be
difficult to find the error
 The worst kind of logic error is one that
occurs in an obscure part of the code
(infrequently executed)

Chapter 2: Program Correctness and
Efficiency
13
Structured Walkthroughs




Most logic errors arise during the design
phase and are the result of an incorrect
algorithm
Logic errors may also result from
typographical errors that do not cause
syntax or run-time errors
One form of testing is hand-tracing the
algorithm before implementing
Structured walkthrough: designer must
explain the algorithm to other team
members and simulate its execution with
other team members looking on
Chapter 2: Program Correctness and
Efficiency
14
Levels and Types of Testing





Testing: exercising a program under controlled
conditions and verifying the results
Purpose is to detect program defects after all
syntax errors have been removed and the
program compiles
No amount of testing can guarantee the absence
of defects in sufficiently complex programs
Unit testing: checking the smallest testable piece
of the software (a method or class)
Integration testing: testing the interactions among
units
Chapter 2: Program Correctness and
Efficiency
15
Levels and Types of Testing
(continued)
System testing: testing the program in
context
 Acceptance testing: system testing
designed to show that the program meets
its functional requirements
 Black-box testing: tests the item based on
its interfaces and functional requirements
 White-box testing: tests the software
with the knowledge of its internal
structure

Chapter 2: Program Correctness and
Efficiency
16
Preparations for Testing
A test plan should be developed early in the
design phase
 Aspects of a test plan include deciding how
the software will be tested, when the tests
will occur, who will do the testing, and what
test data will be used
 If the test plan is developed early, testing can
take place concurrently with the design and
coding
 A good programmer practices defensive
programming and includes code to detect
unexpected or invalid data

Chapter 2: Program Correctness and
Efficiency
17
Testing Tips for Program Systems





Most of the time, you will test program systems
that contain collections of classes, each with
several methods
If a method implements an interface, its
specification should document input parameters
and expected results
Carefully document each method parameter and
class attribute using comments as you write the
code
Leave a trace of execution by displaying the
method name as you enter it
Display values of all input parameters upon entry
to a method
Chapter 2: Program Correctness and
Efficiency
18
Testing Tips for Program Systems
(continued)
Display the values of any class attributes
that are accessed by this method
 Display the values of all method outputs
after returning from a method
 Plan for testing as you write each module
rather than after the fact

Chapter 2: Program Correctness and
Efficiency
19
Developing the Test Data


Test data should be specified during the
analysis and design phases for the different
levels of testing: unit, integration, and system
In black-box testing, we are concerned with
the relationship between the unit inputs and
outputs
◦ There should be test data to check for all
expected inputs as well as unanticipated data

In white-box testing, we are concerned with
exercising alternative paths through the code
◦ Test data should ensure that all if statement
conditions will evaluate to both true and false
Chapter 2: Program Correctness and
Efficiency
20
Testing Boundary Conditions
When hand-tracing through an algorithm
or performing white-box testing, you
must exercise all paths
 Check special cases called boundary
conditions

Chapter 2: Program Correctness and
Efficiency
21
Why do Testing?

Normally testing is done by
◦ The programmer
◦ Other members of the software team who did
not code the module being tested
◦ Final users of the software product
Do not rely on programmers for testing as
they are often blind to their own oversights
 Companies also have quality assurance
organizations that verify that the testing
process is performed correctly
 In extreme programming, programmers
work in pairs where one writes the code
and the other writes the tests

Chapter 2: Program Correctness and
Efficiency
22
Stubs
It may be difficult to test a method or
class that interacts with other methods
or classes
 The replacement of a method that has
not yet been implemented or tested is
called a stub
 A stub has the same header as the
method it replaces, but its body only
displays a message indicating that the stub
was called

Chapter 2: Program Correctness and
Efficiency
23
Drivers
A driver program declares any necessary
object instances and variables, assigns
values to any of the method’s inputs, calls
the method, and displays the values of any
outputs returned by the method
 You can put a main method in a class to
serve as the test driver for that class’s
methods

Chapter 2: Program Correctness and
Efficiency
24
Using a Test Framework
A test framework is a software product
that facilitates writing test cases,
organizing the test cases into test suites,
running the test suites, and reporting the
results
 A test framework often used for Java
products is JUnit, an open-source product
that can be used in a stand-alone mode
and is available from junit.org

Chapter 2: Program Correctness and
Efficiency
25
Debugging a Program
Debugging is the major activity performed
by programmers during the testing phase
 Testing determines if there is an error,
debugging determines the cause of it
 Debugging is like detective work

◦ Inspect carefully the information displayed by
your program
◦ Insert additional diagnostic output statements
in the method to determine more
information
Chapter 2: Program Correctness and
Efficiency
26
Using a Debugger
Debuggers often are included with IDEs
 A debugger can execute your program
incrementally rather than all at once
 Single-step execution executes in
increments as small as one program
statement
 Breakpoints are used to traverse large
portions of code before stopping
 The actual mechanics of using a debugger
depend on the IDE that you are using

Chapter 2: Program Correctness and
Efficiency
27
Using a Debugger (continued)
Chapter 2: Program Correctness and
Efficiency
28
Reasoning about Programs:
Assertions and Loop Invariants
Assertions: logical statements about a
program that are claimed to be true;
generally written as a comment
 Preconditions and postconditions are
assertions
 A loop invariant is an assertion

◦ Helps prove that a loop meets it specification
◦ True before loop begins, at the beginning of
each repetition of the loop body, and just
after loop exit
Chapter 2: Program Correctness and
Efficiency
29
Efficiency of Algorithms


Difficult to get a precise measure of the
performance of an algorithm or program
Can characterize a program by how the
execution time or memory requirements
increase as a function of increasing input size
◦ Big-O notation

A simple way to determine the big-O of an
algorithm or program is to look at the loops
and to see whether the loops are nested
Chapter 2: Program Correctness and
Efficiency
30
Efficiency of Algorithms (continued)
Chapter 2: Program Correctness and
Efficiency
31