Systems Analysis and

Design
Object-Oriented
Analysis and Design
IMSE1013
Henry Lau OOAD

Object-orientation? Object-oriented methods

• A technique for system modelling
• What is Object-Orientation &
Object-Oriented (OO) Methods? • A technique to manage complexity
(C++, Java, Oracle??) inherent in analysis, design, and
implementation
• What is OO methods used for? • For the analysis and design of system
• What are the features of OO • Provide integrated view of hardware
methods? and software
• How are they different from • Provide a methodology for system
SSADM? development
 How? Is it any good?

• A system which is designed and modelled

“Using object- using an object-oriented technology is:
orientation as a base, • Easy to understand
• Directly related to reality - semantic gap
we model a system as
• Natural partitioning of the problem
a number of objects
• More flexible and resilient to change
that interacts.”
• Systems can be developed more rapidly
and at a lower cost

Qualities of OO Examples of using OO

• Enhanced understanding with • Object technology is key to re-

reduced semantic gap engineering business process at Xerox
• Modularity enhanced with • Space telescope uses OO technology
changes more localized and Booch Method to build interface to
• More suited to model real Hubble Database
systems • British Airways choose OO tools for
airline applications
 OO methods OO methods (cont.)

• Object-Oriented Design (OOD) - Booch • Object Modelling Technique (OMT)

(1983), pioneering but not quite scalable - Rumbaugh et al. (1991),
• Object-Oriented System Analysis (OOSA) entity/relationship modelling with
- Shlaer & Mellor (1988), essentially extension to model classes,
information analysis based on data inheritance and behaviour
modelling
• Hierarchical Object-Oriented
• Object-Oriented Analysis (OOA) - Coad &
Yourdon (1991), a method for developing Design (HOOD) - ESA (1989),
OO system model architectural design for Ada code

OO Methods (cont.) Object-oriented modelling

• Jacobson Use Case - Jacobson et al. • Attach the behaviour and
(1992), requirement modelling, analysis information that is important to
and design; also known as OOSE objects
• Unified Modelling Language (UML) - • Associate relations between
Booch, Rumbaugh, Jacobson object to describe the static and
(1997/2000), a method that provides a dynamic organisation and
united OO approach to system structure of real situation
development
 The basics An Object

• Objects • Some concept of reality

• Classes • A physical entity
• Relationships • It is characterised by:
• An Instance – a number of operations,

• Idea of encapsulation – a state which remembers the

effect of these operations

An object Relationships
• Operations:
– Work • Static:
– Dance
– relations existing over a long time
– Drive
– objects know about each other existence
– Jump
• Attributes:
• Dynamic:
– Height – relations which two objects communicate
– Eye colour
with each other
– Hair colour – object sending stimuli to other
– Weight – stimuli - events, messages
 ‘Creating’ objects Encapsulation
• Composition - structure object from • A concept of ‘Self-containing’
parts
• Information hiding - ‘internal’ structure
• Partition - into hierarchy (‘is a’) is hidden from their surroundings
• Consist of - build objects from others • Behaviour and information is
represented or implemented internally
• Aggregate - to join together (‘has a’)
• Functionality and behaviour
characterised by ‘interfacing’
operations

Class Key Concepts

• A class represents a template for several
objects and describes how these objects • Polymorphism – same
are structured internally object has different
• Objects of the same class have the same implementations
definition both for their operations and
their information structure • Inheritance – to adopt,
• Class is an implementation of objects permutate, and derive
from some generic objects
 Polymorphism Why Polymorphism

• A concept in type theory • A very strong tool for allowing system

• A common name may denote designers to develop flexible systems
instances of different classes • Designer only need to specify what
• One type of operation can be shall occur and not how it shall occur
implemented in different ways by • To add an object, the modification will
different classes only affect the new object, not those
using it
• Overloading in modern OO
language

Inheritance Inheritance

“If class B inherits class A,

Mannal
then both operations and the
information structure
described in class A will Man Dog

become part of class B”

soldier navy
 Why Inheritance? Limitations of SSADM
• Show similarities
• Treat data and function separately -
• Reuse common descriptions function/data oriented method
• ‘Software Reuse’ • More suited to classical hardware
• Easy modification of model by • More difficult to maintain and re-
performing modification in one place configure
• Method require more abstraction - not
• Avoid redundancy, leading to smaller too natural
and more efficient model, easier to
• Large semantic gap between external
understand
and internal view of a system

Object-Oriented
Object-Oriented Methods
Analysis & Design
• Advocate integral objects which encapsulate
both function and data
1. Finding objects
• Main activities include:
– Identification of objects, and 2. Organising objects
– Analysing their behaviour and information
• Uses object-oriented techniques and ideas:
3. Describing how objects interacts
– inheritance 4. Defining the operations of objects
– polymorphism
– function/data abstraction 5. Defining objects internally
 Finding Objects Object-Oriented Design
• Naturally occurring entities - physical
• The objects found are to be implemented
• A concept of some abstract ideas - conceptual
• Once objects for a system are identified, they
• Should be stable are refined, organised and related
• Classes of objects • Classes that define the implementation are
– active/passive structured and consolidated
– temporary/permanent/persistent
• Classes are refined with implementation
– part/whole
details (e.g. OS, language, hardware, etc.)
– generic/specific
– private/public
• Classes are coded

Organising Objects Object Interactions

• Classification • Identify how objects fit into a

system
• Similar objects - inheritance: ‘is
a’ • Use of scenarios - unique
situations
• Interactions/relationships
between objects • Objects’ communication

• Whole/Part relationship: ‘has a’ • Objects’ interfaces

• Refined relationships
 Object’s Functionality Object Implementation
• The specification of CLASSES
• Operations performed by an • Define information that an object
object encapsulates - ATTRIBUTES and METHODS
• Behaviour of an object
Automobile
• Specification of interfaces, Colour
Made
external and internal functions Travel
SoundHorn
• Objects with complex functionality OpenSunRoof

should be partitioned into simpler

objects

Object Implementation Testing of Objects

• METHODS: • Similar to SSADM
– Specify external functions
• Unit/Integration/System tests
– Specify internal functions that are not
seen or usable by others objects • Validation and verification
1. Cross references
• Languages: C++, Smalltalk, Ada,
Eiffel, Modula-2, Simula, Java++ 2. Object diagrams
3. Simulation of classes
OO Methods - Some Advantages

• Reduce semantic gap between domain

Jacobson Use Case
(the actual) and model (the design)
• Closer to reality e.g. classification of
Method
objects close to how human understand
surroundings
• Easier to understand and maintain
• Easier to modify (e.g. polymorphism)

The Jacobson Use Case Method Model Building with JM

• An OO methodology that
emphases on the identification
of objects - requirement
analysis ANALYSIS CONSTRUCTION TEST

• Based on 3 techniques: Requirement Model Design Model Test Model

Analysis Model Implementation Model
1. Conceptual modeling
2. Block design
3. Object-oriented programming
Jacobson Method System Development

• The development cycle is

organized into five models: Requirement (Use Case) Model

1. Requirement model Structured by Realised by Implemented by Tested in

2. Analysis model
3. Design model Classes OK

OK

4. Implementation model Failed

5. Test model Analysis Model Design Model Implementation Model Test Model

Requirement -
Requirement Model
Use Case Model
• Capture the functional and non-
functional requirements uses
uses

Actor3
• Formalize the requirement Actor1 Use Case1

• Identify and document essential

Use Case2
system entities
uses
• Identify and document essential System

system behaviors
Actor2
 Requirement Model Requirement Model

• Actors: • System - define the

boundary
– Essential system entities Use Case1
from an user view point • Use Cases:
– Interacts with system – System scenarios
Use Case2
– System behaviors
– Changes system behavior
– Unique transaction
Actor1 – Control system between actors and the
System
functionality system
– User point of view

Analysis Model Design Model

• Structure a system
• Refine the object structure to the
independently to the
Data2
chosen implementation
actual implementation
environment
Control1
• Capture information,
Interface1
• Objects are consolidated into
behavior and
‘blocks’ - abstracted classes
presentation
• Blocks interactions are also
Interface2
Data1
• Specify objects
documented using interaction
diagrams
 Implementation Model Class Diagrams - Inheritance
Class A
• The blocks in the design model are Type

implemented using classes CheckStatus()

persistent

• Class diagrams are used to express

relationships between classes
Class B
Type
• Class specifications
CheckStatus
GenerateReport()
• Annotated source code (pseudo-code) persistent

for methods and attributes of classes

Class Diagram - Aggregation Class Diagram - ‘Uses’

Class A
Type
Class A
Type
'has a' CheckStatus()
CheckStatus()
persistent
persistent
1
1

0..N
1..N 1
Class C GUI
Class D
Class Diagram - An Example Object Diagrams
GUI

0..N

GUI
1
FMC Workstation
L 1: Load NC Program
2: Start checking
1
1
4: Ready to Operate
1

3: Status OK
1 1 1
L
Machine Centre A
Robot Mechine Centre NC Machine

System Analysis and Design

Test Model
with Jacobson
• States the method and result of
testing
1. Requirement Analysis
• Test specification describe how
classes and system are to be 2. Functional Analysis and Design
tested
• Test results document outcome
of the tests executed
• Verification and validation
 Requirement Analysis Functional Analysis & Design

• Generate requirement model with • Structure system functionality into

actors, and use cases identified objects
• To distribute the behavior of the use
• STEP 1: System context diagram
cases among objects - analysis model
• STEP 2: Identify principal actors • Create objects that are common to
(external and internal) actors or use cases
• STEP 3: Construct use cases • Identify the responsibilities of objects
• STEP 4: Represent actors and use • Identify the relationships between
cases with a use case actor diagram objects

Analysis and Design

• STEP 1: Identify scenarios from use cases
• STEP 2: Associate actors and use cases to
scenarios
• STEP 3: Produce event lists for scenarios
• STEP 4: Identify primary object types
• STEP 5: Consolidate objects into control, entity
and interface
• STEP 6: Identify and represent relationships