Information Technology Project

Lecturer

Jan Newmarch

Office / Phone

11A9 / (6201) 2422

email

jan@ise.canberra.edu.au



Aim of the unit

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

Correct
Exactly performs its tasks, according to specification
Robust
Function even in abnormal conditions
Extendible
Can be adapted to change in specifications
Reusable
Components can be reused in new applications

OOSD: Application oriented subject

Topics include

Lecturer

Point of Sale Terminal

lectures

Students

Bus Tours

tutorials
assignment


Prerequisites

Computers and Programming G

Intro to Information Systems, Software Analysis and Design G

Class Contact

Two lectures, each 1 ½ - 2 hours
4:30 Mon, 4:30 Wed

One tutorial, 1 hour


Teams

Teams of 3-4

Must be within a tutorial

Will be determined in first tutorial


Tutorials

Start in week 2

Work in teams in tutorial

Attendance is compulsory

Tutorial allocation

If you are not allocated to a tutorial, enter your preference(s) on the sheet.

Tutorials will be sorted out this week.


Assessment

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.



Language

Java


Books

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

Web page

http://pandonia.ise.canberra.edu.au/itp/


Languages


Java

simple O/O language

Familiar syntax to C/C++ programmers

supports good software engineering

Popular


Consider the following (computing) problems:

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.


Typical program using functional approach

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)

Programs using functional approach

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.



Object oriented paradigm

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.


Object

Defined by how it behaves.

Two types of behaviour, commands and queries.

Constraints on behaviour:


Behaviour

Defined by the set of commands and queries the object offers. This set defines the features of an object.

Attributes

Maintain state about the object.
Should be publically readable, but not publically changeable

Methods

Allow you to


Analysis

Design / implementation

operation
(change state)

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)

Classes

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
(abstract data type)

encapsulation of data + methods


Traditional Structured Design

But different models, different notations.

There has to be a translation from the notation of one phase to the notation of the next.



Object vs Function oriented analysis & design



Object Oriented Approach




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.




classic 3 tier architecture


Architectural layers


Presentation

GUI, console, Web

Problem domain

books, borrowers, ?

service objects

interface to DB

storage

persistent storage



Case study

Point of Sale Terminal (POST)


Requirements ? OOA ? OOD ? Implementation



requirements

Identify and document what is required


overview

The purpose of the project is to create a point of sale terminal system to be used in retail sales

customers

OOSD lecturer and tutor

goals

fast checkout

fast sales analysis

automatic inventory control


system functions

"This system should do X"


evident


hidden

eg save information

frill

optional



basic functions

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


payment functions

handle cash payments and calculate change

evident

handle credit card payments

evident

handle cheque payments

evident

log payments to accounts receivable

hidden



system attributes (characteristics)

  • ease of use

  • fault tolerance

  • response time

  • interface metaphor

  • retail cost

  • platforms