Lecturer |
Jan Newmarch |
Office / Phone |
11A9 / (6201) 2422 |
|
jan@ise.canberra.edu.au |
Extension of the Object oriented paradigm (design / implementation). The emphasis will be on the construction of quality software using the OO paradigm. By this we mean software that is
Topics include
Lecturer |
Point of Sale Terminal |
lectures |
Students |
Bus Tours |
tutorials |
Computers and Programming G
Intro to Information Systems, Software Analysis and Design G
Two lectures, each 1 ½ - 2 hours
4:30 Mon, 4:30 Wed
One tutorial, 1 hour
Teams of 3-4
Must be within a tutorial
Will be determined in first tutorial
Start in week 2
Work in teams in tutorial
Attendance is compulsory
If you are not allocated to a tutorial, enter your preference(s) on the sheet.
Tutorials will be sorted out this week.
2 assignments (teams), 1 report (individual), final exam.
Each piece of assessment is given a grade.
All members of team get the same grade for assignments.
Individual grades for report and final exam.
Necessary to pass all 4 items of assessment.
Provided grade >= Pass for all pieces of assessment, grade for ITP will be average grade of assignments, report and final exam.
Java
Applying UML and
Patterns, by Craig Larman
we will be following this closely.
Other books
OO analysis
UML Distilled, Fowler & Scott
OO Design
OO Software Construction, Meyer
Design
Patterns,
Gamma, Helm Johnson & Vlissides
Language books (as required)
Java - an Introduction to Computer Science and Programming Walter Savitch
http://pandonia.ise.canberra.edu.au/itp/
simple O/O language
Familiar syntax to C/C++ programmers
supports good software engineering
Popular
1. Find the average of some numbers.
2. Simulate a bank for a day,
or file update program
3. Create an application to assist in designing crossword puzzles.
4. Create a spreadsheet.
As we go down the list, the complexity of the problem increases.
It is coping with increasing complexity that is our central problem, or rather the production of quality software in increasingly complex applications.
The software
industry, as indeed most human activity, has found that a separation
of concerns is an effective way of dealing with complexity.
Dijkstra: "I have a small mind and can only comprehend one thing at a time". |
Gries: "When faced with any large task, it is usually best to put aside some of its aspects for a moment and concentrate on others". |
In the functional approach, what is focused upon is the subtasks.
Simulate a 1-teller bank for a day, collecting statistics
Watch for
initialise(Event list, Teller, Cust Q, Stats) while Event list not empty get next event (Event list, Event) if Event is an arrival process arrival(Event, Cust Q, Teller, Stats) else if Event is a departure process departure(Event, Cust Q, Teller, Stats) endif end while write final report(Stats)
Emphasis is on tasks.
There is a main control module which controls everything.
Data is passed from module to module.
It leads to systems that are very difficult to maintain when the requirements change - e.g. in the bank simulation, allow customers to get fed up waiting and leave without being served.
World is seen as a set of interacting objects.
Software system
made up as a set of interacting objects.
Objects interact by
sending each other messages.
Internal details of
objects are hidden.
Only the public (exported) behaviour of a
module is visible.
Defined by how it behaves.
Two types of behaviour, commands and queries.
Constraints on behaviour:
Defined by the set of commands and queries the object offers. This set defines the features of an object.
Maintain state about the object.
Should be publically readable, but not publically changeable
Allow you to
Analysis |
Design / implementation |
operation |
setX(...) |
query |
getX() |
A method is
defined by the way it connects to the outside world.
Called the
signature of the feature.
· the name of the routine
· the number of formal arguments
· the types of the formal arguments
· the return type if the routine is a function
float sqrt(float x)
Behaviour is defined on classes of objects; and individual objects are instances of their class.
eg Borrower is a class, features may include
name, address,
finesOutstanding, payFines
"David Clark" is an instance of Borrower.
An OO system is written by defining the set of classes needed in the system, and creating instances of the classes when the system is executed.
The program text only contains classes At run time, only objects exist |
A class is an
implementation of an ADT encapsulation of data + methods |
But different models, different notations.
There has to be a translation from the notation of one phase to the notation of the next.
The advantage of the waterfall model is that you know when each phase is ended.
The disadvantage is that you need omniscient requirements specification and omniscient analysis.
It leads to systems that are very difficult to maintain when the requirements change - e.g. in the bank simulation, allow customers to get fed up waiting and leave without being served.
Presentation |
GUI, console, Web |
Problem domain |
books, borrowers, ? |
service objects |
interface to DB |
storage |
persistent storage |
computerised system to record sales and handle payments
retail store
hardware (computer, bar code scanner) + software
Requirements ? OOA ? OOD ? Implementation
Identify and document what is required
overview
customers
goals
system functions
system attributes
The purpose of the project is to create a point of sale terminal system to be used in retail sales
OOSD lecturer and tutor
fast checkout
fast sales analysis
automatic inventory control
"This system should do X"
|
|
hidden |
eg save information |
frill |
optional |
record current sale |
evident |
calculate current sale total |
evident |
capture purchase price of item from bar code scanner or manually |
evident |
reduce inventory quantities |
hidden |
log completed sales |
hidden |
cashier must log in with id and password |
evident |
provide persistent storage mechanism |
hidden |
provide communication mechanisms to other processes and systems |
hidden |
display description and price of sales items |
evident |
handle cash payments and calculate change |
evident |
handle credit card payments |
evident |
handle cheque payments |
evident |
log payments to accounts receivable |
hidden |
|
|
|
|
|
|