CS 124
Introduction to Software
Development
Course Notes
Winter 2004
All Sections
1. COURSE INFORMATION .................................................................................................................................... 1
1.1 THE COURSE PAGES ON THE WEB .................................................................................................................. 1
1.2 DISCLAIMER ...................................................................................................................................................... 1
1.3 COURSE TEXTS.................................................................................................................................................. 1
1.4 COURSE ENROLLMENT ..................................................................................................................................... 1
1.5 ABOUT THIS COURSE ....................................................................................................................................... 2
1.6 COURSE OBJECTIVES ........................................................................................................................................ 2
1.7 EXPECTATIONS FROM CS 123 .......................................................................................................................... 4
1.8 COURSE GRADE................................................................................................................................................. 4
1.9 LECTURES .......................................................................................................................................................... 4
1.10 PRACTICUMS ................................................................................................................................................... 5
1.11 COMPUTING RESOURCES ............................................................................................................................... 5
1.11.1
Course Accounts ............................................................................................................................... 5
1.11.2
Lab Descriptions ............................................................................................................................... 5
1.11.3
Lab Hours ......................................................................................................................................... 6
1.11.4
Lab Etiquette ..................................................................................................................................... 6
1.11.5
Access During Scheduled Lab Times ................................................................................................ 6
1.12 ASSIGNMENTS ................................................................................................................................................. 6
1.13 QUIZZES ........................................................................................................................................................... 8
1.14 GRADE RECORDING ........................................................................................................................................ 8
1.15 EXAMS.............................................................................................................................................................. 8
1.15.1
Exam Policies and Missed Examinations.......................................................................................... 8
1.16 OBTAINING HELP ............................................................................................................................................ 8
1.16.1
Office Hours / Consulting ................................................................................................................. 8
1.16.2
Electronic Mail ................................................................................................................................. 9
1.16.3
The Course Newsgroup ..................................................................................................................... 9
1.17 ACADEMIC OFFENSES .................................................................................................................................. 10
1.17.1
Cheating and the Student Academic Discipline Policy ................................................................... 10
1.17.2
Stealing Computer Time.................................................................................................................. 10
2. TESTING ............................................................................................................................................................... 12
2.1 BLACK-BOX TESTING ..................................................................................................................................... 13
2.2 WHITE-BOX TESTING ..................................................................................................................................... 15
2.3 THE TEST SUITE .............................................................................................................................................. 16
2.4 HOW MANY TESTS ARE ENOUGH? ................................................................................................................. 16
2.5 TEST REPORTS................................................................................................................................................. 17
3. WORKING IN SMALL GROUPS....................................................................................................................... 19
3.1 WHY WORK IN GROUPS? ............................................................................................................................... 19
3.2 SELECTING A PARTNER .................................................................................................................................. 19
3.3 DESIGNING YOUR PROJECT ........................................................................................................................... 20
3.4 SUBSEQUENT MEETING FORMAT .................................................................................................................. 20
3.5 DELEGATING WORK ....................................................................................................................................... 21
3.5.1 Responsibilities ......................................................................................................................................... 21
3.5.2 Rights ........................................................................................................................................................ 21
3.6 MAKING DECISIONS........................................................................................................................................ 21
3.6.1 Decision by Majority ................................................................................................................................. 21
3.6.2 Decision by Unanimous Consent .............................................................................................................. 22
3.6.3 Decision by Consensus .............................................................................................................................. 22
3.7 HOW TO AVOID PROBLEMS ........................................................................................................................... 22
3.8 COMMON PROBLEMS...................................................................................................................................... 23
3.9 ACKNOWLEDGMENTS..................................................................................................................................... 24
4. SELECTED OVERHEAD SLIDES ..................................................................................................................... 25
5. CODE OF ETHICS & STANDARDS OF CONDUCT
CS 124
25
Page i
1. Course Information
This section provides details on course personnel, the marking scheme,
textbooks, assignments, examinations, and tutorials.
1.1 The Course Pages on the Web
The Web homepage for CS 124 is located at
http://www.student.cs.uwaterloo.ca/~cs124/
From that starting point, you can find references to course topics,
organizational and administrative information, and up to the minute
information about assignments, solutions and testing. This is the primary
source for disseminating course material electronically.
1.2 Disclaimer
While we have tried to take reasonable precautions to ensure that all course
materials are error-free, there may be ambiguities or errors. We apologize in
advance for these. If you notice a problem, bring it to the attention of the
course personnel as soon as possible. When an error is discovered, we will take
steps to minimize its impact.
The course web page includes a link to Errata that will contain discovered
errors and ambiguities in the course materials and the textbook.
1.3 Course Texts
You will need the following printed materials for CS 124. These are available in
the University bookstore.

Data Abstraction and Problem Solving with Java: Walls and Mirrors, by Frank
M. Carrano and Janet J. Prichard (2001).

CS 124 Course Notes (these notes).
1.4 Course Enrollment
All students taking this course should be enrolled in three sections: a lecture
section (LEC), a practicum section (PRA), and a test (TST) section. Note that
instructors never authorize enrollment changes for any section. The
undergraduate advisors are the only people who may authorize such changes.
Please do not ask instructors to sign or initial course changes on your
schedule; they are directed not to do so.
CS 124
1. Course Information
Page 1
1.5 About This Course
CS 124 is a first course in computer science — that is, the discipline of
analyzing problems, specifying algorithmic solutions, implementing these
solutions, and evaluating the effectiveness of the implementations. Its
prerequisite is a solid background in programming, which may be obtained
through either CS 123 (a first course in programming at UW), or equivalent
experience. In contrast to CS 123 and most high school CS courses, which are
concerned with the mechanics of programming, CS 124 is concerned with the
concepts and principles underlying all of computer science.
Another difference between CS 124 and CS 123 is that CS 124 is less
structured. At university, students must gradually assume more and more
responsibility for their own education; the lecturers, tutors and TAs are present
to facilitate that process. The assignments may have shorter descriptions,
though they may require more work and lead to longer writeups. In general,
you will be offered less direction. Not all students learn in the same way, and
you are encouraged to think about which methods of learning work best for
you.
Information will be provided to you through lectures, practicums, readings in
the textbook, and assignments. Each of these is important. In particular, the
lectures do not rigidly follow the textbook; there will be information in the
lectures that you cannot find anywhere else, information that may be
necessary to complete an assignment or to answer questions on the midterm or
final. It will be important not only to attempt the assignments, but to
understand their complete solutions and to learn from your mistakes in case
you do not earn full marks. The tutors will discuss the solutions to past
assignments in the tutorials, and you are encouraged to attend these sessions.
The term work (and its evaluation) is a diagnostic procedure which is intended
to help you discover your weaknesses in this subject and to help you correct
them. It also provides you with an opportunity to work on larger problems and
to do more in-depth analysis than is possible in an examination.
1.6 Course Objectives
By the end of CS 124, you should be familiar with the concepts and tools of
algorithm and program design:
You should understand what assertions are, and the special uses of
preconditions and postconditions. You should be able to specify
preconditions and postconditions for any procedure or function that you
write.
You should understand the meaning and uses of O-notation. You should
be aware of the differences between O(1), O(log n), O(n), O(n2), and other
elementary functions that arise in the course. You should be able to
Page 2
1. Course Information
CS 124
analyze a simple code fragment to determine how many times a particular
operation is executed in the worst-case and in the best-case. You should
be able to decide whether a given code fragment runs in O(1), O(log n),
O(n) or O(n2) time.
You should be comfortable with the Java™ language constructs used to
support data abstraction: classes, interfaces, and inheritance. You should
be comfortable with using object-oriented techniques to implement
abstract data types, including the use of factory and iterator design
patterns. You should be comfortable with using lists to implement data
structures both at the algorithm design and program implementation
levels.
You should be familiar with the following sorting methods: selection sort,
insertion sort, mergesort, and quicksort. You should be able to describe
these algorithms at a high level and to write code for these algorithms. You
should be familiar with the worst-case and best-case complexity as well as
the practical strengths and weaknesses of each algorithm.
You should be comfortable with recursive definitions and algorithms:
You should be able to write recursive definitions. You should be able to
write recursive code to manipulate recursively defined objects. In
particular, you should be able to write recursive code for manipulating
arrays, linked lists, and trees.
You should appreciate the role of abstract data types in software design and
implementation, and you should be comfortable with several basic abstract
data types and their common implementations:
You should be able to precisely specify an abstract data type given either a
vague description or a situation in which an abstract data type might be
used. You should be able to implement a class given the description of an
abstract data type.
You should be familiar with the types “list”, “stack”, “queue”, “table”, and
“binary tree”, and their possible uses. You should be able to describe
several implementations of these types at a high level and write code that
fills in implementation details.
You should be familiar with several applications of simple data types, including
discrete event simulation, expression evaluation, and binary search trees, and
you should be able to write software that supports such applications.
You should be capable of discussing possible benefits and drawbacks of uses of
computer technology in real-world situations:
™
Java is a trademark of Sun Microsystems Corporation.
CS 124
1. Course Information
Page 3
You should have some understanding of the history of computer science
and how it has influenced the design of the hardware and software that
you use. You should be familiar with some applications that have
motivated advances in information technology.
You should appreciate that information technology can have an impact on
a community and understand the need for social responsibility.
1.7 Expectations from CS 123
We expect that in CS 123 or its equivalent you learned how to program in Java.
You should be able to take a high-level description (in English or in
pseudocode) of an algorithm or approach for solving a problem and write a
program that implements it. You should be familiar with classes, constructors,
and methods, and with data types such as arrays and Strings, and their uses.
You should be able to use classes and methods to structure your programs,
and you should be able to make effective use of a library of code. We will
assume that you know how to use a complete Java development environment
(such as JBuilder™), including debugging features, printing, input/output
to/from files, and simple graphic user interfaces (GUIs).
1.8 Course Grade
Final marks for the term will be computed using the following approximate
formula, with some possible adjustments to compensate for errors in
judgement. We will do our best to minimize such errors.
Component
Weight
Assignments
25%
Quizzes
20%
Final Exam
55%
Students must pass the test component (weighted average of quizzes and the
final exam) to pass the course.
1.9 Lectures
Material covered in lectures is the primary source of examination material.
Wherever possible, the text material will be supplemented by additional
examples given in lectures. Assignment and exam questions will often be
based on these examples. Indeed, some of the topics are not covered at all in
the textbook. Even though lecture attendance is not compulsory at the
University of Waterloo, regular attendance is highly advisable.
™
JBuilder is a trademark of Borland International, Inc.
Page 4
1. Course Information
CS 124
Students who miss a lecture are responsible for the missed material. It is your
obligation to properly familiarize yourself with the material covered and to find
out from other students about any announcements or other administrative
matters that were dealt with in class. If you know you are going to miss a
class, you are advised to arrange to have a friend go over that day’s material
with you later. Any handouts distributed in class can be claimed from the
tutors during their office hours.
1.10 Practicums
During the practicum sessions, previous assignments will be distributed and
they will be discussed. In addition, students will have the opportunity to ask
questions about upcoming assignments. Often, the tutorial instructor may give
further examples relating to material covered in lectures. Practicum sessions
are not compulsory. However, it is hoped that practicum sessions will be of
benefit to most students.
1.11 Computing Resources
All computer work for this course will be done using PC computers and the
Java programming language. If you have a computer at home and software
equivalent to that used in the lab (JBuilder) then you may use it to do your
labs. It is possible to transfer files between your home machines and the lab
machines; your tutor can explain the procedure.
1.11.1 Course Accounts
Course userids are issued solely for computing related to CS 124. Students are
not authorized to use course accounts for any other purpose, such as creating
resumés, typing essays or game playing.
Accounts on both UNIX and Nexus are automatically generated for people
registered in the course though it can take up to ten days from registration.
The userids will be your UW userid. The password for both accounts will be the
same, so if you already have a UNIX password then that will also be your
Nexus password. If you have not already set up your UNIX account then you
will need to visit the MFCF consultants in MC3011, who will set your password
and who will also be able to answer questions about using the accounts.
You will also need to purchase a CAS account from the CHIP (MC1052) in order
to be able to print your assignments.
1.11.2 Lab Descriptions
PC computers are located in MC3004, MC3005 and MC3027. Report any
difficulties you have with machines or software to any instructor in the lab or
any person on duty in the consulting centre located at MC4065. No food is
permitted in the labs at any time. Use nearby eating areas, never the labs.
CS 124
1. Course Information
Page 5
1.11.3 Lab Hours
The labs are open to you 24 hours a day, 7 days a week except when courses
have requested use of the lab. Scheduled requests are posted on the lab doors.
1.11.4 Lab Etiquette
Games are not to be installed or played on the computers. It is not fair to other
users who require the computer resources for legitimate course work.
Bothering others by sending them unwanted e-mail or playing music loudly is
not tolerated. Downloading files bigger than 1 Mbyte must not be done either,
as it slows down the server computer which others rely on.
Students who insist on misusing their computer account will find their account
suspended or terminated.
1.11.5 Access During Scheduled Lab Times
You may be permitted access during any lab period, at the discretion of the
staff member in charge of that session, provided that:
1. You obtain the permission of that staff member.
2. You do not disturb any students in the scheduled class.
3. You do not further disturb the staff member in charge for any reason.
4. You are prepared to vacate immediately if the workstation you are using is
required by a student officially registered in that lab section.
1.12 Assignments
All assignment submissions are due by 4:30 p.m. on the date specified on the
assignment; late submissions are not permitted.
The assignments give you some practice in implementing methods discussed in
class, and in adapting them to new situations. Occasionally, it may be
necessary to ask questions to clarify an assignment’s requirements.
Each assignment may be completed individually or in a group of up to 3
students. You should hand in only one submission per group. Be sure to
include the names and student IDs of all group members as indicated on the
project description. Read Section 3 carefully before the first assignment.
Marks will be allocated for:

documentation

pre/post conditions

correctly working code
Page 6
1. Course Information
CS 124

code design (modularity, parameters)

testing and testing documentation
1.12.1.1 Readability
It is always important to structure your program so as to communicate with
the people who may look at it: your future self, other programmers, other
users. In this course, your program must communicate with the person
marking your programming assignment. Markers have limited time in which to
assess your work.
A correctly-running program that is poorly organized is not likely to get full credit.
There are four important ways of improving the readability of programs:
1. Use white space to separate blocks (such as loops and methods).
2. Use a row of asterisks to separate subprograms
3. Use a monospaced font (such as Monaco or Courier) to align columns.
4. Use block-style documentation rather than inline comments
1.12.1.2 Documentation
All programs should contain proper internal documentation.

Author and student ID of programmer(s)

purpose of program

logical choice of identifiers (e.g. names of variables)

for each subprogram, include purpose, pre- and postconditions
The code in the textbook is a good example of appropriate style. You should
also refer to the Sample Project found on the course web page.
1.12.1.3 Testing
In the projects, you will be asked to design tests for your programs. Since this
course deals largely in abstract programming, black-box testing will be more
important than white-box testing (see Section 2).
The key point is that you must demonstrate that your program works. It is not
sufficient to simply run the tests; for each test (or set of tests), you must
describe:

what you are trying to test, (e.g., a boundary case, a typical case)

what data set(s) you chose, and

how the test case demonstrates that your program works.
CS 124
1. Course Information
Page 7
1.13 Quizzes
There will be four quizzes. They will be held during scheduled lectures. The
duration of each quiz will be at the instructor's discretion. Attendance is
mandatory. The quizzes will test your knowledge of course material which is
not easily evaluated by the programming assignments. They will give you an
indication of how well you understand the theory presented in lectures
throughout the term. Quiz questions should help you prepare you for the final
exam.
1.14 Grade Recording
During the term you will have an opportunity to review the marks recorded for
you. Please take this opportunity to check that we have properly recorded your
marks. Bring any improperly recorded marks to the attention of your tutor.
If you have any questions, comments or complaints concerning the marking of
an assignment, you should contact a course tutor.
1.15 Exams
1.15.1 Exam Policies and Missed Examinations
You are required to show your UW Student ID card at the final exam..
The final exam will be closed book. Calculators are not permitted.
If you are unable to write the exam due to illness:
 You must bring complete medical documentation or documentation of
family emergency to the Math Undergraduate Office (MC5115) as soon as
possible and no later than the first day of the following term.
 There will be no makeup exam. Normally you will receive an INC
(incomplete), and must write the final exam in a subsequent term.
1.16 Obtaining Help
1.16.1 Office Hours / Consulting
All instructors and tutors will schedule certain hours every week during which
they will be available to answer questions concerning course material. A
schedule of the office hours for the staff of instructors and tutors will be posted
on the course web page. We ask that you adhere to these hours. However, if
you have a conflict with the posted hours, you can usually arrange an
appointment at some different time. Instructors, teaching assistants, and
tutors can almost always be contacted by electronic mail, as described below.
A drop-in consulting centre is set up in MC4065. Hours are posted on the door
of that room.
Page 8
1. Course Information
CS 124
1.16.2 Electronic Mail
Electronic mail is the best means of communication between students and
course staff. All course staff are reachable via e-mail: your tutor will have an
account on the lab network; the course instructor and the graduate TAs will
typically use accounts on campus Unix systems.
The list of course personnel (which may not be finalized until a week or two
after the beginning of term), including e-mail addresses, will be made available
on the Web.
1.16.3 The Course Newsgroup
The newsgroup, uw.cs.cs124, is used as a forum for discussion and for
dissemination of up-to-date information. It is a good medium through which to
ask questions about your assignments and course material in public. It
enables you to learn from questions others have and thus avoid asking
questions that have already been answered. It also provides a forum for the
course personnel to make announcements and clarifications about course
related material.
Students are expected to read the course newsgroup on a regular basis.
1.16.3.1 Newsgroup Guidelines
Please remember that everything you post is public — everyone will be reading it.
In the past, several problems have arisen in relation to the newsgroup. As a
result, you should keep the following guidelines in mind when posting
messages:
1. Under no conditions should you verbally attack another individual,
whether a classmate, tutor, staff member, or faculty member, and
whether or not that person is associated with the course.
2. In any posts you make to the newsgroup, do not give away any details for
solving any of the assignments — this could be construed as cheating. If
you have questions about an assignment that require you to give specific
details of your solution, email the question to a tutor.
3. Keep posts to the news group course-related. As you are all expected to
read the group on a regular basis, and many of you are quite busy, you
shouldn't have to read irrelevant postings. Note also that the course
newsgroup is not for posting “test” posts. Such test posts should be sent
to uw.test.
4. Please read all questions and responses that are posted to the group
before asking a question, so that you are not wasting everyone's time. We
realize that there is a bit of a lag between the time something is posted
CS 124
1. Course Information
Page 9
and it appears in the group, so this is sometimes unavoidable. However,
try to avoid it as much as possible.
5. Please don't post messages to the group that give no useful information
to others. Posts like “I have the same question as this one posted,” or “I
agree with this comment” serve no useful purpose and waste people's
time.
6. Please keep complaints about the course out of the newsgroup. If you
have a concern about anything to do with the course, the best way to
deal with it, and get results, is to take it to a tutor or an instructor.
1.17 Academic Offenses
There are two general categories of academic offenses of which all students
should be aware: cheating and theft of computer time.
1.17.1 Cheating and the Student Academic Discipline Policy
We expect our students, as members of the university community, to adhere to
a code of honour in their various activities. Cheating on exams, quizzes, or
assignments is a serious violation of our code of honour, and it jeopardizes the
integrity and reputation of our academic programs.
Cheating on exams includes using unauthorized aids or communicating in any
way with others during an examination. The penalty for cheating on a test or
exam will range from suspension for one or more terms to expulsion from the
university.
Cheating on assignments includes copying another group's solution and
submitting it as your own, allowing another group to copy your solution,
collaborating excessively with another group, plagiarizing from published sources,
or falsifying program output. The standard penalty for cheating on an
assignment or project is as follows: a grade of -100% will be assigned for the
piece of work, with a minimum deduction of 5% from the final course grade.
All academic offences are reported to the Associate Dean for Undergraduate
Studies and are recorded in the student's file. A second academic offence will
lead to a more severe penalty, which will automatically include suspension or
possibly expulsion.
1.17.2 Stealing Computer Time
Stealing computer time is regarded as theft under the Criminal Code of
Canada. The University is prepared to take action to recover any damages
caused as a result of someone knowingly misusing one of its computers. Your
course account is for your personal academic use. Do not let anyone else
“borrow” it for any purpose, even for assignments in this course.
Page 10
1. Course Information
CS 124
To prevent others from using your accounts, change your password before
making major use of your account and change your password on a regular
basis if you suspect that someone other than you knows your password. The
best way to guard your password is to not tell anyone about it.
CS 124
1. Course Information
Page 11
2. Testing
adapted from CS 246 notes by Michael H. Coffin, et al.
In the projects, you will be asked to design tests for your programs. The
specification for each project (and each method within your solution) is given
by pairing preconditions with postconditions. The purpose of testing is to
demonstrate that meeting the precondition implies meeting the postcondition.
That is, any input to your program that satisfies the preconditions specified
must produce the desired output.
There will be some trade-offs in attempting to make your tests both complete
and concise. Part of the learning process is for you to decide what is important.
Note, for example, that you are not required to test data that is outside the
bounds of the precondition. You should refer to the Sample Project found on
the CS124 web page for an example of a good set of test data and explanations.
Where possible, test classes one at a time. Write small programs that
thoroughly exercise each method. A tried and proven system is to write a test
harness for each class. A test harness is an interactive program that lets the
tester throw arbitrary input at a module. For a data abstraction, this amounts
to a program that allows each method in the interface to be called with any
parameter. For example, a test harness for a List might read commands of the
form:
add
X
contains
X
remove
X
elements
size
isEmpty
clear
Upon reading an add command, the program would invoke the add method
with X as parameter. Upon reading a size command, the program would
invoke the size method and print the result.
It may seem like a waste of time to write a test module for every class, but it
does save time in the long run. It’s a lot easier to find an error in a program
that has one or two classes (including the harness and the target modules)
Page 12
2. Testing
CS 124
than one that has fifty. Also, writing test harnesses can be done very quickly
after a while, as most of the pieces can be scavenged from old test harnesses.
When you are testing a module using a test harness, remember that you are
testing the module, not the test harness. There is no need to make a test
harness bullet proof.
There are two basic strategies for finding test cases: black-box testing and
white-box testing.
2.1 Black-Box Testing
In black-box testing, you treat the program (or method) as a sealed unit and
write tests to see whether it meets its specification. Black-box testing ignores
the actual code  pretending that it is enclosed in a “black box”  and
attempts to ensure that the code meets the specification. For testing methods,
this amounts to testing the contract. The way to do that is to invoke the
method with input values that create true preconditions. (If the precondition is
simply TRUE (or omitted), no input is going to make it FALSE.) If the
precondition is compound  i.e., involves several predicates combined with
AND or OR  include test cases that exercise each part of the precondition.
But there are often many ways to make a condition true. Which ones should
be used to maximize the probability of finding errors? Experience shows that
when code fails, it often fails for boundary values  input values that make the
precondition “just barely true.” So you should check not only “normal” input
but also test boundary cases: for example, if a routine works on sequences, you
should test it on sequences of length 0, 1, on a sequence of “typical” length,
and on a sequence of maximum length (if there is a maximum).
Note that for purposes of determining boundary values, the types of input
values are implicit predicates. The following table shows some typical
examples of predicates and their associated boundary values.
a  x < b
x == a; x == b-1; a == b-1
String s
s == null; s.length() == 0; s.length() == 1
Object val
val == null
List c
c == null; c.size() == 0
c.contains(x)
c.size() == 1 and x is the only member
!c.contains(x)
c.size() == 0; c.size() == 1 and x is not
equal to the only member
CS124
2. Testing
Page 13
x s.t. 0x<m …
m  0 (i.e., empty set of values)
In addition to testing boundary cases, it’s important to test one “typical” case
for each part of the precondition, just to make sure that a silly error hasn’t
been made. A typical case is a case that makes the condition true, but isn’t a
boundary case. For example, a string of length 3 is a “typical” string  it isn’t
null or the empty string.
To do exhaustive black-box testing of a precondition that involves AND or OR,
you would need to test all possible combinations of special and typical cases for
each piece of the precondition. For example, consider the specification for
delete, as follows:
public int delete (Object [] multi, int count);
// pre: multi is non-null and 0  count
// post: replaces up to count copies of this in array multi by null (unbounded if count = 0)
//
and returns the number of copies replaced
Three cases arise from the declaration of multi and the precondition that it be
non-null:
1. multi.length == 0
2. multi.length == 1
3. multi.length > 1
Similarly, three cases apply to count:
1. count == 0
2. count == 1
3. count > 1
(the second of these because the postcondition indicates that 0 is a special
case, and therefore 1 is a boundary case).
Furthermore, we can determine several test cases related to the presence of a
value equal to “this” in the array multi:
1.
2.
3.
4.
5.
6.
this value does not occur at all
this value is the only one to occur
a mix of this and other values occur
this value occurs fewer than count times
this value occurs exactly count times
this value occurs more than count times
Page 14
2. Testing
CS 124
To do exhaustive black-box testing, one would have to test all combinations of
the cases above. The problem is that this quickly gets out of hand, even for
small examples. The number of tests implied by the three lists above is
336=54. That’s a lot of test cases for one trivial procedure. It helps
somewhat that some of the combinations are impossible or are repeats of
others  for example, you can’t simultaneously have “multi.length == 0” and
“this value occurs more than count times,” but in practical situations there
may still be many cases to test.
Moreover, testing all possible combinations is probably a lot of unnecessary
work. In many cases, the boundary conditions don’t interact, and testing all
possible interactions just tests the same pieces of code many times in almost
the same way. For example, if count == 1 works with typical mixtures of
values, and if arrays having all values identical work with typical counts, it is
unlikely that the combination of count == 1 and arrays with all values identical
will cause a problem. Exhaustive black-box testing is usually not an efficient
use of your time.
A compromise approach is to test each boundary condition in every list, but
only with a “typical” case from the other lists. For example, test a count of 1 (a
boundary condition), but only with a typical-length array (multi.length > 1) and
a typical mix of values . This approach ensures that each boundary condition
is tested, while drastically reducing the number of test cases. (The number of
test cases is the sum, instead of the product, of the number of cases in each
list.) However, in reducing the number of tests, we have ignored all
interactions between boundary conditions. To get back what we have lost, we
need to do additional testing.
2.2 White-Box Testing
Testing that uses the implementation to find good tests is called white-box
testing. In white-box testing, you look at details of the implementation and
attempt to “exercise” the code. For instance, if there is an important ifstatement, design two tests, one that causes the “if” part to be executed, and
one that causes the “else” part to be executed. For a while-loop, design tests
in which the body of the loop is executed 0, 1, and a “typical” number of times.
There are two reasons for doing white-box testing in addition to black-box
testing. The first reason is stated in the previous section: exhaustive black-box
testing can be too time consuming to be practical.
The second reason is more subtle. There are two kinds of errors in programs.
First, there are typographical errors: misspelled identifiers, wrong operators,
etc. Most typographical errors result in syntax errors, but those that do not
occur essentially randomly throughout the code. Since typographical errors
occur randomly, they are just as likely on rarely executed paths as on
CS124
2. Testing
Page 15
commonly executed paths. Second, there are logic errors. Logic errors are
more common on rarely executed paths. The “main line” of a program is
usually well understood; it is the little-used by-ways that are poorly thought
out and likely to contain errors. This is bad news for black-box testing
because, without examining the code, it is difficult to ensure that rarely
executed paths are taken. To test these paths, we must examine the code.
Here are some specific white-box testing strategies.
Branch testing: Make sure that each branch is taken, for each possible
reason. For example, if there is an if statement such as
if (a < b or a < c) { ... };
create tests that separately cause both conditions (a < b) and (a < c).
Loop testing: For each loop make sure there is a test that
1.
2.
3.
4.
exits before the first iteration,
makes one iteration and then exits,
makes a “typical” number of iterations, and
makes the maximum number of iterations (if there is a maximum).
Exit testing: Include a test that exercises each reason a loop can exit. For
example, if you have a loop
while (a < b or a < c) { ... };
include a test that exits because (a < b) fails and one that exits because (a < c)
fails. Similar considerations hold for loops with multiple exits.
Special cases: Include also tests for exceptions, such as division by zero.
Using white-box techniques usually produces a set of tests that overlaps the
set obtained by using black-box techniques. Obviously, there isn’t much
benefit to repeating the same test twice just because it arises in two ways.
2.3 The Test Suite
Don’t run a test program and then throw the results away. Keep the test
harness, the input you use to test the module, and the output once it is
correct. This is called a test suite. Later, you may have to modify and extend
the program; the test suite will come in handy. You can run the same input
through the test program and check to see if it matches the old output
2.4 How many tests are enough?
Testing can only prove that a program has an error; no amount of testing can
ever prove that a program is error-free. So how many tests should you make
Page 16
2. Testing
CS 124
before you ship the software or submit it for marking? Software testing is still
the subject of active research, so there isn’t a firm answer to this question.
However, there are several reasonable criteria for deciding whether “enough”
testing has been done.
First, you can follow the criteria above. This will catch most of the errors, but
some errors will probably remain. For example, some problems arise only after
a program has been run for days or weeks, or when something quite
exceptional happens: a disk becomes full or a computer somewhere else on the
network CAShes. Several criteria for when to stop testing have been proposed.
The rate at which testing reveals errors begins high and drops off sharply. This
is simply because easy-to-find errors are found quickly, while hard-to-find
errors take longer. One way to decide when to stop testing is to carefully
monitor the testing process. Measure the number of hours spent and the
number of errors found. When the number of errors detected per hour drops
below some threshold, stop testing.
What threshold to pick depends on how important the software is. A program
that operates an artificial life-support system needs much more rigorous
testing than one that plays solitaire. Also, there is a law of diminishing returns
at work. Hardware is not completely reliable; in fact, every piece of hardware
will fail eventually. One figure of merit for a system, hardware or software, is
the “mean time to failure.” This is the expected length of time before a failure
occurs. It doesn’t make much sense to spend a million dollars to increase the
mean time to failure of a program from ten years to twenty years if the mean
time to failure of the computer upon which it is executing is five years.
Another factor that influences testing is a rather strange phenomenon that
occurs in very large programs, especially programs that have been built by
large numbers of people over many years. Experience shows that, initially,
testing and fixing errors reduces the total number of errors, as you would
expect. However, after a while, the number of errors can actually begin to
increase! This happens because, when an error is fixed, there is some
probability that the fix itself will cause other parts of the program to fail. This
is particularly true if the person making the fix doesn’t fully understand the
ramifications of the change. (Often, with very large programs, no one person
understands the entire program.) The upshot of all this is that, if fixing an
error is likely to cause more trouble than the error itself, additional testing
doesn’t make much sense. Rewriting the program is probably called for.
2.5 Test Reports
One of the most important aspects of testing is record keeping. It is important
not only that your code works, but that you can convince other people that it
works. If you sell your software, people are going to want evidence that what
CS124
2. Testing
Page 17
they are buying is worth their money. If you work for a software company, you
will find that they have their own test-report requirements, usually quite strict.
To convince someone that your code works, you need some form of test report.
A test report is a record of tests that have been performed, along with the
results. A test report is often combined with a test suite  the test report
refers to tests in the test suite.
For purposes of this class, a test report will consist of a sequence of tests, each
with the following information:
1.
2.
3.
4.
the condition(s) being tested
the input data
the associated output data
an explanation of any deviations from specifications
The fourth component is vital to document interpretations you have made with
respect to your assignment, as well as explanations of errors you uncovered
but were unable to correct.
Page 18
2. Testing
CS 124
3. Working in Small Groups
by Jack Rehder
This document is intended to assist you in completing projects as a group. The
suggestions that are provided should enable you to have a positive group
experience, thereby improving your overall group performance.
The issues addressed include selecting a partner, organizing meetings, and
dealing with internal group problems.
Suggestions for improvements to this document are most welcome.
3.1 Why Work in Groups?
There are many advantages to working in a group on a project:







to
to
to
to
to
to
to
learn to plan and organize
learn to negotiate and compromise
practice decision-making skills
gain knowledge from another person
meet new people
lessen work for each individual
have fun
Finally, group work provides practical real-life experience. Few people will
obtain jobs that enable them to work in complete isolation; it is necessary to
learn how to work with other people, even if you would rather work alone!
3.2 Selecting a Partner
For projects, you may work in groups of 2 or 3. Experience shows that groups
of 2 are much more successful than groups of 3, due to a phenomenon known
as triangling (where two people gang up on a third).
In addition, it has been observed that self-selecting groups work best, so you
are encouraged to find your own partner.
Many people attempt to pair up with their best friends for group work; this is
not necessarily the best choice for a partner. When selecting a partner, you
should discuss the following:

which topic you would like to work on

work habits (procrastinators can be a problem!)

whether your potential partner likes to work during the day or at night
CS124
3. Working in Small Groups
Page 19

do your schedules coincide (will you have time to work together?)

whether there are personality conflicts (for example, two people with dominant personalities may have frequent arguments)
If any of the above issues appear to be a problem, choose another partner or be
prepared to deal with the situation.
3.3 Designing Your Project
Once you have selected your partner, it is time to set up a preliminary project
plan. First, you should obtain some information from your partner:

exchange full names, phone numbers, userids, addresses.

establish a method for contact (e-mail, phone, visit, meet in C&D) and a
time, particularly if one partner is hard to reach or lives out of town

spend some time getting to know each other

share any concerns you have about the course

share any concerns you have about group work — you may as well tell your
partner at the beginning if you have reservations or negative past
experiences
During the first (and possibly the second) group meeting for each project, you
should plan the design of the project, as outlined in the project description.
Some issues you should resolve are:

determine the data structures required

develop a solution technique

design a pseudocode mainline algorithm

determine subprograms required and develop a structure chart.

discuss each other's abilities and weaknesses — decide who should do what

assign workloads — make sure that the load is evenly distributed. Don't let
one person carry the load even though he/she may be more proficient, for
all members need to learn

set milestone dates for completion of major portions of the project
3.4 Subsequent Meeting Format
Your meetings need not follow a formal structure, but you should be sure to
cover the following in each of your meetings:

update each other on progress to date and update your progress chart

examine the project plan and revise if necessary
Page 20
3. Working in Small Groups
CS 124

analyze and redistribute work loads if necessary

set short-term deadlines/goals for next meeting

evaluate how well the group is functioning — are there problems that need
to be resolved?
In addition, you may want to consider the following:

exchange any problems that may have arisen with the individually assigned
tasks

test each other's work, or arrange a mechanism to do this (e.g. mail files to
each other)

discuss internal matters such as which sorting algorithm to use
3.5 Delegating Work
Each member has certain rights and responsibilities once work is delegated.
3.5.1 Responsibilities
 The member assigned to the task has the responsibility to meet the
interfaces agreed upon, unless he/she first notifies the other partner(s) of
his/her intentions

The member assigned to the task has the responsibility to meet the
mutually established deadlines

The member assigned to the task has the responsibility to research and
choose the best method to implement the task, for example, finding the best
sorting algorithm for the application.
3.5.2 Rights
 The right to make decisions regarding matters related to own work, e.g. if
Kelly likes blue and decides to use it for her graphic, then Terry has no right
to question this decision (unless it violates a previous mutual decision).
3.6 Making Decisions
In any group situation, it is highly unlikely that all members will agree 100% of
the time. There are three major decision-making strategies when group
members disagree:
3.6.1 Decision by Majority
In Decision by Majority, a vote is taken and the majority rules. This strategy
obviously will not work for groups of two people. Moreover, in a majority
decision, the "election losers" do not agree with the decision, are not happy
with it, and so may try to sabotage the project. At the very least, the "losers"
will not likely be satisfied with the outcome of the project. Making decisions by
majority is not recommended.
CS124
3. Working in Small Groups
Page 21
3.6.2 Decision by Unanimous Consent
Unanimous consent occurs when everyone truly agrees on the course of action
to be taken. If unanimous consent can be achieved, it is ideal. However,
achieving unanimous consent may require an extremely large investment of
time.
3.6.3 Decision by Consensus
Consensus occurs when each person in the group feels that he/she has had a
fair chance to influence the decision. Every member may not necessarily agree
with the decision, but understands the final decision and is willing to support
it.
Consensus is most easily achieved by compromise. Whenever there is a
disagreement, no single member should expect to get everything his/her way.
Each member must decide what is most important, and be willing to give in on
other issues.
Making decisions by consensus is the recommended course of action. It is a
more efficient means of making decisions than by unanimous consent, and is
much more likely to result in overall satisfaction than making decisions by
majority.
3.7 How to Avoid Problems
There are problems that may arise in a group situation. Statistics show that
up to 25% of groups have some problems. Many group problems can be
avoided by discussing important issues early on; see the section entitled
Selecting a Partner. Other techniques for successful group work are presented
below.
Be open
Be willing to praise each other; criticize constructively
when necessary.
Communicate
Listen carefully, don't interrupt, ask for clarification if
you don't understand, and feel free to disagree.
Get acquainted
Discover each person's likes and dislikes, strengths and
weaknesses, work habits, and motivation.
Encourage
Elicit the opinion of a silent member.
Compromise
Make decisions by consensus, not unanimous consent;
this involves compromise.
Page 22
3. Working in Small Groups
CS 124
Stay on schedule
This puts less pressure on the group. Where there is less
tension, there is less conflict.
Make time
Schedule times to meet and work both together and
separately. Block out the time in your schedule.
3.8 Common Problems
In spite of your efforts to avoid problems, you may still find some difficulties
working with your group. Some very common problems are listed below, along
with a number of possible solutions.
If you encounter any problems with your group members, you must not hesitate
to discuss them. If you don't discuss small problems right away, they only
become larger problems later on.
Problem: One group member is late for a meeting, or does not arrive at all.

Talk about the situation at the earliest possible moment. Find out why they
weren't there — they may have had a very good reason.

Proceed with your part of the work as scheduled.

Confirm meetings the day before the scheduled meeting.

Reschedule the meeting if time is inconvenient for the other group member.

Explain that the group member should call if he/she cannot attend.

Schedule an additional meeting as soon as possible — don't let the work
suffer.

If one group member has an answering machine, use that as a central
repository for messages.
Problem: Other person doesn't do work on time.

Assess workload. Offer to assist or redistribute workload if you feel your
partner is overworked.

Assess group members' progress at each meeting — make sure no one falls
behind.

Remind group members of their expectations prior to each meeting.
Problem: Group members can not seem to agree.

Determine if the decision is important enough to argue over.

Make decisions by consensus, not unanimous consent; this involves
compromise.

Resort to third party arbitration; consult other students or instructors.
CS124
3. Working in Small Groups
Page 23
Problem: Two passive people may have problems making decisions.

Take turns at decision-making. For example at today's meeting I will make
decisions (as long as you don't strongly object).
Problem: A bright student does all the work because he/she can do it quicker.

The other students should explain that they want to help and want to learn.
They should not let the other one take over.

The bright student must be willing to accept a delay (tolerable within the
schedule) in order to allow the other members to learn the concepts.
Problem: One group member is too critical of your work.

Review the rights and responsibilities of delegation of work with your partner.

Consider the possibility that the other person's criticisms are valid! Get a third
person's opinion.

Decide if you have followed guidelines set out.

For the future, discuss interfaces and guidelines more explicitly.

The problem may be a result of a communication problem. Make sure that
everyone is clear. You may use a technique such as, "I tell you, you repeat it
back to me" to make sure that everyone is clear.
Problem: One group member is not doing his/her share of the work.

The member may be overloaded. Review the delegation of work and possibly
assign more to the other partners.

Discuss the situation with the course instructor.
3.9 Acknowledgments
I wish to thank Bill Shalinsky and the other members of the TRACE office for
their invaluable assistance.
Page 24
3. Working in Small Groups
CS 124
4. Selected Overhead Slides
Lectures in CS 124 will be delivered using a combination of overhead slides,
blackboard work, and spoken words. We have noticed in the past that when
an overhead slide with a lot of text is put up, students spend most of their time
copying it down and do not listen to what is being said. Since you also have to
take notes on what is being said, this can lead to imperfect or incomplete
understanding.
To alleviate this problem, we have reproduced selected overhead slides here.
These are not complete.
The instructor may choose to prepare more slides, or to fill in extra information
on these slides when they are used in class. Even if they were complete, they
would not include the material presented on the blackboard, and they would
not include the verbal discussion that accompanies the slides when used in
class. This is not a substitute for regular class attendance. If you miss class,
you cannot “make do” with just the information here; you should contact
someone who was present to find out what you missed.
CS 134
5. Selected Overhead Slides
Page 25