Object Oriented Analysis and
Design
COM327 week 7
COM252 week 1
A summary so far.
• You should know about the following
–
–
–
–
–
–
–
Objects
Classes
Encapsulation
Abstraction
Message passing
Polymorphism.
Inheritance
Implementation
• You’ve tried all of those in C++
• Time to try and do the “high end” of the
lifecycle.
Topics to cover
• Notations
– diagramming techniques
• Process
– what to do and when
• Domain analysis
– finding out about a problem area
• Requirements analysis
– finding what a program is meant to do
• System design
– working out how it will do it.
Process
Process
Process =
Process - aims
• Produce a design which is implementable
• Need to know
–
–
–
–
–
–
classes in the problem
data members belonging to each class
function members belonging to each class
relationships between classes
data structures used
how the functions work
use-case
analysis
Requirements
Analysis
problem
statement
Domain
Analysis
object
spotting
CRC analysis
system
charter
What to build?
requirements
description
candidate
class list
Identify
data/functions/
relationships
CRC cards
class list
System
Design
Booch diagramming
Booch class
diagram
JSP diagramming
Decide on
data structures/
functionality
complete implement
C++
design
Stage 1 - Domain Analysis
• Starting point - The client
• FAMILIARIZE!
• Produce
– Problem Statement
– System Charter
– Requirements Description
Problem Statement
• What problem is the system trying to solve?
• If there is no problem, you don’t need a
system.
• Plain language description
• NOT what the system is going to do.
• Description of the problem area
Problem Statement -example
• Lecturers often miss appointments to see
students because they forget that their
availability slots have been booked. Their
slots can change on a day to day or week to
week basis making them difficult to
remember. Appointments are booked by
reception but not always communicated to
staff.
System Charter
• Description of how the system will solve
the problem.
• What will it be responsible for?
– Information
– Operations
• What will the system DO?
• What will it NOT do?
System Charter - example
• The system will keep track of staff
availability slots.
• The system will accept bookings of staff
availability slots by students and
automatically inform staff by sending an
email message at the time of booking and
10 mins before the appointment as a
reminder.
Requirements statement
• A list of individual things the system should
be capable of.
• often presented as series of use-cases
Use-case analysis
• Imagine the system is finished.
• Imagine you are a user.
• Describe how you would do one single
operation with the system:
– What options would you select?
– What data would you put in?
– What info would you get out?
Use-case analysis
• No “repeats” - only a single operation.
• No “ifs” - describe what it will do in any
given instance.
• Do the ordinary situations first, worry about
special cases 2nd.
• a.k.a. “Critical Path Analysis” ?
• Now do that for ALL possible operations.
• The set of use cases is your requirements
statement.
Use-case analysis - example
•
•
•
•
Start appointment system
enter lecturer name
see weeks availability slots
enter a booking
– enter time
– enter student name
– enter subject of appointment
• exit system
• You never get it right first time
– Iteration
• You never get all the details first
time
– refinement
• When you do the use-case you’ll
need to ask the client questions
– change the problem/solution
descriptions
Exercise - NOW!
• Produce the use-cases for the appointment
booking system.
• Ask me for clarification
•GO!
The End!