Object Oriented Analysis and Design

Overview

1
Syllabus
 This course is about understanding
and applying Object-Oriented
Analysis and Design (OOA&D),
expressed using the Unified
Modeling Language (UML)
 Main text is UML Distilled, 3E, by
Martin Fowler

2
Course Structure
 Overview
 Use Case Diagrams
 Class Diagram Basics
 Interaction Diagrams
 Class and Object Diagrams
 Activity Diagrams
 State Diagrams
 Package and Deployment Diagrams
 Other Diagrams
 Review

3
Course Scores
 Main exam (80 -70 mark)
 Lab work (20 - 30 mark)

4
More than Software – a Reminder
 The course is primarily focused on
software analysis and design
 Remember that your system will
probably ultimately involve other
things, such as:
 Hardware
 Users
 Training
 Documentation, etc.

5
Earlier A&D Methods
 Earlier analysis methods were
focused on process (such as a
Data Flow Diagram, or DFD) or
data (e.g. using an Entity
Relationship Diagram, or ERD)
 Traditional design creates entities
(data tables), and changes them
using scripts, procedures, macros,
or other techniques

6
What is Object Oriented?
 Object oriented (OO) methods blend
data and process into objects, and
focuses on how those objects
interact using methods (passing
messages)
 OOA&D creates objects from
classes, and applies them using
their methods or operations

7
 What is Object Oriented?
 The methods isolate the data, so
that it can’t be manipulated directly
 Only the methods can create, read,
modify, or delete data

Image from Apple, “Object-Oriented

Programming and the Objective-C Language”

8
What is Object Oriented?
 So the purpose of object oriented
analysis and design is to
 Define what classes need to exist
 Define the characteristics of those

classes (attributes or data fields)

 Define the methods each class

must have
 Define which classes need to see each

other (kind of like entity relationships)

9
Concepts of Object Oriented
 Objects: Objects represent an entity
and the basic building block.
 Class: Class is the blue print of an
object.
 Abstraction: Abstraction represents
the behavior of an real world entity.
 Process of identifying essential aspects
of an entity and ignoring unimportant
properties.

10
Concepts of Object Oriented
 Encapsulation: Encapsulation is the
mechanism of binding the data
together and hiding them from
outside world.
 Information Hiding
Separate external aspects of an object
from its internal details, which are
hidden from outside.

11
Concepts of Object Oriented
 Inheritance: Inheritance is the
mechanism of making new classes
from existing one.
 Polymorphism: It defines the
mechanism to exists in different
forms.

12
A Little History
 While object oriented programming
has existed since at least 1980
(Smalltalk), there were many ways
to describe and diagram an object
oriented system
 Everybody had their own notation –
Booch, Rumbaugh, Jacobson, etc.
 Finally unified in 1997 with UML

13
What’s UML?
 UML, the Unified Modeling Language,
Represents unification and evolution of
several OOAD methods, particularly:
 Booch method,
 Object Modeling Technique (OMT),
 Object-Oriented Software Engineering
(OOSE).
 Defined as “a standard language for
specifying, constructing, visualizing, and
documenting the artifacts of a software
system”.

14
Goals of UML
 Provide ready-to-use, expressive visual
modeling so users can develop and
exchange meaningful models.
 Be independent of particular
programming languages and
development processes.
 Encourage growth of object-oriented tools
market.
 Support higher-level development
concepts such as collaborations,
frameworks, patterns, and components.

15
UML Standard
 UML is defined by a standard from
the Object Management Group
(OMG!)
 Current version is 2.5, dated
June, 2015

16
Two Ways to Use UML
 UML can be used in two ways
 Sketch – UML can be used to outline the
purpose and structure of a system, and
leave the small details to the
developer’s discretion and creativity
 Blueprint – UML can create a detailed

blueprint to specify every aspect of a

system, leaving nothing to chance
 We’ll use the sketch approach

17
A Future Third Way to Use UML
 Eventually, it will be possible to use
UML as a programming language
 Diagrams are converted directly to
code automatically
 Model Driven Architecture (MDA) is

one method to use UML this way

 Another variant on this idea is

Executable UML, which uses MDA

18
What is an Object?
 “An entity with a well-defined
boundary and identity that
encapsulates state and behavior.
State is represented by attributes
and relationships, behavior is
represented by operations,
methods, and state machines. An
object is an instance of a class.”
(UML 1.5 spec)

19
Huh?
 Attributes are the data contained by an
object, if any
 Relationships describe which objects are
allowed to talk to each other
 The operations and methods describe the
ways objects can interact with each other
 So objects are a set of data which can
only be acted on in certain prescribed
ways

20
What is a Class?
 “A description of a set of objects
that share the same attributes,
operations, methods, relationships,
and semantics. A class may use a
set of interfaces to specify
collections of operations it provides
to its environment.” (UML 1.5 spec)
 Hence a class is a group of
similar objects

21
UML Diagrams
 Structural:
 class diagrams
 object diagrams
 component diagrams
 deployment diagrams.
 Behavioral:
 use case diagrams
 sequence diagrams
 collaboration diagrams
 State chart diagrams
 activity diagrams.

22
UML Diagrams
 The core one is the Class diagram
 Each box represents a class
 Lines between boxes represent

associations – what classes can

‘see’ each other

23
UML Diagrams
 Requirements are summarized in
the Use Case diagram
 Each bubble represents a use case
 Stick people or boxes represent actors

or external systems who interact with

the system
 Lines between them represent who

can use or call them

24
UML Diagrams
 The way classes are grouped, either
logically or physically, are in:
 Package diagram, for the smallest
logical grouping of classes
 Component diagram, for logical

structure of packages
 Deployment diagram, for physical

location of classes in ‘nodes’

25
UML Diagrams
 The ways classes or objects interact
to perform a given use case are
shown by
 Activity
diagram, a process flow chart
 Communication (collaboration)

diagram, to show messages passed

between objects
 Sequence diagram, also to show

messages passed between objects

26
UML Diagrams
 More interaction diagrams
 State machine or state transition
diagrams, to show how events change
the state of objects
 Timing diagram, to show interaction

between objects along a timeline

 Interaction Overview, a blend of the

sequence and activity diagrams

27
UML Diagrams
 And finally, to show what particular
objects exist at any particular time,
we have
 Object diagrams, which is similar to
the class diagram, but at one moment
in time
 Composite structure diagram, which

shows the decomposition of a class

28
“Exist at any particular time?”
 Yes, another key difference between
OO and relational systems
 Entitiesare essentially permanent –
they just have data added to or
removed from them
 Objects are created and destroyed
during use of an OO system
 A popup window to display an error
message is an object
 A report can be an object created before it

is either saved as a file, or deleted

29
Other Diagrams
 Keep in mind that describing a
system might want to include other,
non-UML diagram types, such as
 Screen flow diagram, to show
navigation in the user interface
 Decision table, to show business

process rules

30
UML for Requirements Analysis
 During requirements analysis, you
might want to use
 Use case diagram and the
corresponding use case descriptions
 High level, or conceptual class diagram

 Activity or state diagrams, to

understand how key processes work

31
UML for Design
 As the design is developed may use
A more detailed Design Class Diagram
 Sequence and communication

diagrams for key use cases

 Package and deployment diagrams to

capture logical and physical structure

32