Course Revision: Themes A & C
In Stage 1, you learned how to write programs to solve small problems.
230, we teach programming “in the large”.
Large software systems have many stakeholders.
What will its users want?
Can we describe user requirements, accurately and succinctly?
Large software systems are very complex.
Can we describe the design of a complex software system, accurately and
Can we be sure that a complex system will do
it is designed to
not do anything unintended
230, you will learn some incomplete answers to these
I will also attempt to teach you how to “learn how to learn” the technical skills
you will need in the future
as a competent computer professional.
A. The object
oriented programming paradigm
oriented programming concepts and programming
because, for many important problems, OO design is a
convenient way to express the problem and its solution in software.
Inversion of control, AWT/Swing and JUnit
because many important “sub
problems” have already been solved: these solutions should be re
C. Software quality
Testing, inspection, documentation
because large teams are designing,
implementing, debugging, maintaining, revising, and supporting complex software.
level concurrent programming
Multithreading concepts, language primitives and abstractions
because even our
laptops have multiple CPUs. Dual
core smartphones are now available...
Theme A: The OO Design Paradigm
oriented programming concepts and
programming language constructs
because, for many important
problems, OO design is a convenient way to express the problem
and its solution in software
Topics (by lecture):
01: Software Construction
04: Class Diagrams
07: Java Implementation
(or learn for the first time?)
What is Object
behaviour. Instantiation. Comparison
procedural and data
architectural styles of programming.
Message passing by calls
Methods (for instances and classes)
Introduction to OO Design
what the stakeholders require,
a set of classes with objects which will meet these requirements
You learned two new languages:
case diagram, for requirements
Class diagram, for design
Object diagram, to explain
“what’s happening” in an implementation
emphasised, but may be very helpful for your
Use Case Diagrams
Learning goals for
Any student who passes
230 can accurately interpret
information presented in a use
case diagram or description.
Any student with a B
230 can draw
set of use cases from an informal
230 students are able to apply their course
knowledge in novel situations. For example, they could discuss
the strengths &
weaknesses of use case
as a methodology for requirements capture
Note: I cannot test a students performance on all topics, at all levels, in an hour.
The final exam has some questions that are focused at A
level, some at B
some at C
level. I won’t reveal the levels at which topics are tested.
Some topics won’t be tested at
all, but I won’t reveal which ones.
Such incomplete (and secret) coverage allows a limited range of quality
student who knows all important topics “at B level” will get a B.
level students will “get lucky”
they’ll also get a B.
Students who have only C
level knowledge will get a C.
t is impossible to write in a language if you can’t read it. You must be able to read & write in order to
express novel thoughts.
OOD & Class Diagrams
ability of a language (and a designer) to take a concept and create an
abstract representation of that concept within a program
well does this language, designer, and programmer hide an object’s
does this language let us treat related objects in a similar fashion?
a” relation: important for code
a” relations: ways to build complex classes from simpler
. (I’m emphasising only the most general case: the “association”.)
Interfaces and Abstract Classes
Important in practice, but not emphasised this semester.
ystem: Static & dynamic typing, conversions.
Very important in practice, rather difficult in theory.
Important in practice, but not emphasised this semester.
Important for readability, and an “easy” topic.
Java’s runtime system
A very “deep” topic. We skimmed over memory allocation.
Object identity, assignment, equality, copying, cloning
Very important in practice, with a straightforward theory after you understand
instantiation (which is moderately complex: object diagrams might help).
Theme C: Software Quality
Demonstrate a “theoretical understanding” (A
Discuss the role of testing in “famous failures” (
, LAS, INCIS)
Evaluate a test suite, with reference to Myers’
Competently perform some test
driven development tasks
exam questions: write a unit test, specify a test suite.
Homework, tutorials: some experience with JUnit and XT.
Demonstrate a basic
(by defining or
using) the fundamental concepts and standard terminology of
Validation testing, defect testing, unit test, component test, system test,
XT, XP, inspection,
Theories of Software Quality
Myers’ ten principles: don’t bother memorising these!
I’ll be testing your “working understanding” (not a rote
recital) of the
fundamentals of software testing. I’d say Myers’ theory is fundamental, and I
discussed some variations (which I’m not emphasising).
Myers’ definition of software quality
… does what it is supposed to do, and doesn’t do anything unintended…
XP is a method which is based on a theory or belief that…
Software quality is assured by a simple process which focusses on
communicating, testing, refactoring, seeking feedback.
XT is a method which is based on a theory or belief that …
Unit testing and acceptance testing are sufficient to assure quality, if testing is
done continuously and carefully within an XP process.
Theories are best tested at A
level, I believe.
include some C
level testing of your ability to read & remember
the basic concepts of these theories, i.e. how communication is handled in XP.
level) skills in Testing
box tests (from a specification)
box tests (from an implementation)
A point of confusion I noticed when marking the midterm:
Myers emphasises the importance of generating tests for unexpected
input. In a well
designed Java program, some (but not all!) of these tests
are infeasible in a JUnit test suite. I encouraged you to explore this issue
in Assignment 2; but many of you had difficulty with this on the midterm.
If you try to pass a String to a method that cannot accept a String, you’ll
(usually) get a compile
time error. Sometimes you’ll get a runtime error.
Defects in Java’s type
checking mechanisms are very rarely found, and are
quickly patched. You should not try to test for these defects, under
Best wishes, and please keep in touch!
I have enjoyed teaching this course.
I’d enjoy hearing from you in the future.
Please don’t hesitate to “volunteer yourself” to give a guest lecture to a