UNIT 1:

AN OVERVIEW OF OBJECT_ORIENTED
SYSTEMS DEVELOPMENT
 Introduction

• OOD more than OOP.

• Written in 1991.
• Object Oriented Development was not widely accepted.
 Outline

• Object Oriented Concepts.

• Evaluation of Modeling Components.
• Evaluation Procedure.
• Object Oriented Methods.
• Review of Object Orientedness of Traditional Software
Development Methods.
• Conclusions.
 Object Oriented Concepts

• Three OOD principles that improve software design for

reliability, maintainability, and reusability.
• Abstraction: Objects are an abstraction of part of the real-
world. More maintainable and reusable.
• Encapsulation: Objects hide their internal contents from other
components to improve maintainability. (information hiding)
• Inheritance: Organizing objects in class hierarchies to
promote reuse. (subclass, superclass, hierarchical, multiple,
polymorphism)
 Object Oriented Model of Systems

• The Object Oriented Model of Systems is composed of a

network of objects communicating by messages.
• Each object specifies data and activity and may share
properties according to a classification hierarchy.
 Evaluation of Modeling
Components
• Objects vs. Traditional Concepts of Entities and Functions.
• ISO TC97: entity, propositions and events.
• Entity: Any concrete or abstract thing of interest including
association among things.
• Entities on three levels: Entity instance, entity type and entity
class.
• Propositions, rules, constraints which specify the behavior of
entities.
• Events: The fact that something has happened in either the
universe of discourse, or the environment, or the information
system.
 Evaluation of Modeling
Components – Cont.
• Events are modeled as messages passed within a network
of objects.
• Objects record state change resulting from events.
• Distinction between ISO TC97 and OOD: separation of
data structure and rules, entities do not possess
attributes, relationships are different.
• Object Orientation shares many of the ISO concepts but
by no means all. Main divergence point: separation of
activity and data specification.
 Evaluation of Modeling
Components – Cont.

• Objects could be classified as data-oriented and task-

oriented objects.
• Booch divides objects into actors (real-time systems),
servers (data retrieval systems), and agents.
Evaluation Procedure – Conceptual
Modeling
• Evaluation framework: a meta-model of OO development.
• The data and processing control parts of a system are modeled
in unit rather than separately.
• The method produces a network system model of objects
communicating by messages.
• The method explicitly models object types and instances.
• Classification of objects is supported with property
inheritance.
 Evaluation Procedure – Procedural
Guidelines

• The method should guide the analyst towards identifying

and describing objects.
• Guidance should be available for analysis, specification
and design phases.
 Evaluation Procedure –
Transformations and Products

 Design transformations should support change of OO

specifications into designs implementable in OOP
languages.
Evaluation Procedure – OO Meta-
model
 Review of Object Oriented and
Traditional Methods

• Goal: Highlight differences between OO and non OO

methods.
• Case study: Video renting system for hotels. Snapshots
of artifacts only.
 Object Oriented Methods

• Hierarchical Object Oriented Design (HOOD)

• Object Oriented System Design (OOSD)
• Object Oriented System Analysis (OOSA)
• Object Oriented Analysis (OOA)
• ObjectOry
 Object Oriented Methods – Hierarchical
Object-Oriented Design (HOOD)

• Scores well on OO properties.

• Encourages modeling of objects explicitly.
• Objects are modeled in a hierarchical manner.
• Strong emphasis on the object interface specification and
encapsulation.
• The OO model of systems is supported. Overall, incorporates many
OO properties.
• Uses Booch’s concepts (actors and servers)
• Supports object classes, but inheritance and reuse are not made
explicit.
• Real time-method -> data specification and associated inheritance
receive less attention.
 Object Oriented Methods – Object-
Oriented Systems Design (OOSD)
• Assumes analysis phase has been completed.
• Provides detailed notation for object classes and
management of inheritance.
• Inter-object communications (event/message types)
• Detailed notation for interface description and
encapsulation.
• No analysis advice is given.
Object-Oriented Systems Design (OOSD) –
Object Model Structure Chart
Object Oriented Methods – Object-Oriented
Systems Analysis (OOSA)

• Many heuristics for object identification and analysis, which help with
initial abstraction and object modeling.
• Data modeling approach (ER modeling)
• Models an object relationship network with subclasses.
• State-transition specifications are constructed for each object and
functions are modeled with data-flow diagrams.
• Produces a composite activity-data model (synthesis not clearly
specified)
• Lack of support for inheritance.
• Underspecified in the design phase.
 Object-Oriented Systems Analysis
(OOSA) – Object Relationship Model
Object Oriented Methods – Object-
Oriented Analysis (OOA)
• Covers all OO concepts, although analysis method
only.
• Classification and inheritance are modeled and
abstraction is helped by the structure layer (Subject,
Structure, Attribute, Service)
• Uses hierarchical inheritance.
• Specification of encapsulation and object interfaces
is not as detailed as OOSD, or HOOD.
• Overall, it does meet many OO criteria.
Object-Oriented Analysis (OOA) –
Object Model in the Service Layer
 Object Oriented Methods –
ObjectOry
• Developed by Jacobson.
• Supports OO concepts of classification, encapsulation and
inheritance.
• Abstraction is promoted by levels.
• Adds “use cases” to the OO approach.
• Composite data and activity definition is not strongly enforced and
services are also regarded as objects.
• Reuse is supported by component libraries.
• Guidance for analysis is less comprehensive.
• Target applications: like HOOD real-time systems and engineering
systems.
 Summary of Object Oriented Methods

• Variable and not all methods meet the necessary range of

criteria.
• HOOD and OOSD give comprehensive design notation but
weak on prescriptive guidance (analysis)
• HOOD supports most OO criteria, except property inheritance.
• OOSA produces an object model with fewer components as a
consequence of its data base modeling heritage.
• OOA is more likely to identify actor and server objects.
• No complete object oriented method exists.
 Traditional Methods

• Information Engineering (IE)

• Information systems activity and change analysis (ISAC)
• Structured Analysis/Structured Design (SASD)
• Structured Systems Analysis and Design Methods (SSADM)
• Structured Analysis and Design Technique (SADT)
• Jackson System Development (JSD)
• Nijssen’s Information Analysis Method (NIAM)
• Mascot-3
 Traditional Methods – Information
Engineering (IE)

• Uses data modeling.

• Functional specification uses process dependency
and action diagrams.
• Concepts of type-instance are supported.
• Encourages conceptual modeling of business
processes -> object orientation.
• Cannot be regarded as truly object-oriented
(separation of processing from data and emphasis on
functional decomposition)
 Traditional Methods – Information Systems
Activity and change analysis (ISAC)

• Advocates top-down functional decomposition in

separated specifications as activity and data
diagrams.
• Emphasis is placed on analysis phase.
• Type-instance and classification concepts are not
supported.
• More functionally oriented than object-oriented.
 Traditional Methods – Structured
Analysis/Structured Design (SASD)
• Top-down functional decomposition.
• Analyses system in terms of a network of processes
connected by data flow messages.
• Functional cohesion and low coupling.
• Does not support any OO concepts (separates data
and process specification)
• More recent versions have added state-transition
diagrams and bottom-up analysis driven by event
identification (more potential for OO specifications)
 Traditional Methods – Structured Systems
Analysis and Design Method (SSADM)

• Composite method derived from structured analysis,

structured design and data analysis.
• Process analysis is separated from data analysis ->
functionally related processing structures.
• Most of the views expressed about IE also apply to
SSADM.
 Traditional Methods – Structured Analysis
and Design Techniques (SADT)

• Uses top-down decomposition to analyze systems.

• Specification uses network diagrams of processes
connected by data flows, control messages, and
mechanisms.
• Encourages modeling of real world problems, but
constructs separate activity and data models.
• Does not support type-instance concepts.
• Separation of process specification from data makes it
unsuitable for an OO approach.
 Traditional Methods – Jackson
System Development (JSD)
• System models based on networks of concurrent
communication processes.
• Type-instance concept.
• Classification and property inheritance are not supported.
• System control is modeled in terms of time-ordering of actions
associated with entities.
• More recent versions have placed more emphasis on data
modeling -> object model that combines data and operations.
• Much in common with OO methods.
• No object classification, instead entity roles.
 Nijssen’s Information Analysis
Method (NIAM)

• Conceptual modeling method that concentrates

on data specification during early part of the
analysis life-cycle.
• Support data abstraction with conceptual
modeling -> encouraging OO.
• Type-instance concepts are supported.
• Possess some OO properties, not inheritance.
 Traditional Methods – Mascot-3

• Advocates functional decomposition of systems.

• Recent versions have introduced encapsulation and clearly
defined interfaces for system components.
• Type-instance concept.
• No classification of objects
• Little guidance during early analysis.
• Encourages a functionally oriented specification.
• Implementation does incorporate OO features.
 Summary of Traditional methods
evaluation

• Methods using functional decomposition encourage

identification of goal related components in systems.
• OO approach promotes system components more
compatible with data models.
• Functionally oriented analyst will identify different
modules from OO analyst.
• Current structured methods using an entity-
modeling and/or entity life history have potential to
evolve towards OO.
 Overview
Object-oriented programming (OOP) is a way to organize
and conceptualize a program as a set of interacting objects.

In the overview section, we will get an introduction to:

• Key Object-Oriented Systems concepts

• Software Lifecycle Basics
• OOA/OOD basic tools
 Module Map
• Key Object-Oriented Systems Concepts
• Objects and Classes
• Encapsulation
• Methods and Variables
• Inheritance
• Message Passing and Polymorphism
• Basic Software Lifecycle Concepts
• Introduction to OOA/OOD
 Object-Oriented Programming

Object-oriented programming (OOP) is a way to organize and

conceptualize a program as a set of interacting objects.

• The programmer defines the types of objects that will exist.

• The programmer creates object instances as they are needed.
• The programmer specifies how these various object will
communicate and interact with each other.
 What is an Object?
Real-world objects have attributes and behaviors.

Examples:
• Dog
• Attributes: breed, color, hungry, tired, etc.
• Behaviors: eating, sleeping, etc.
• Bank Account
• Attributes: account number, owner, balance
• Behaviors: withdraw, deposit
 Software Objects
Writing software often involves creating a computational model
of real-world objects and processes.

• Object-oriented programming is a methodology that gives

programmers tools to make this modeling process easier.
• Software objects, like real-world objects, have attributes and
behaviors.
• Your best bet is to think in terms as close as possible to the real
world; trying to be tricky or cool with your system is almost
always the wrong thing to do (remember, you can’t beat
mother nature!)
 Software Objects - Cont’d
In traditional programming languages (Fortran, Cobol,
C, etc)
•data structures and proceduresBank
In object-oriented are defined separately.
languages, they are defined
Account
together.
• An object is a collection Account

of attributes and the Account

behaviors that operate number:
on them.
• Variables in an object are balance:

called attributes. deposit()

• Procedures associated with withdraw()

an object are called methods.
 Classes

The definitions of the attributes and methods of an object are

organized into a class. Thus, a class is the generic definition
for a set of similar objects (i.e. Person as a generic definition
for Jane, Mitch and Sue)

• A class can be thought of as a template used to create a set of objects.

• A class is a static definition; a piece of code written in a programming
language.
• One or more objects described by the class are instantiated at runtime.
• The objects are called instances of the class.
 Classes - Cont’d

• Each instance will have its own distinct set of attributes.

• Every instance of the same class will have the same set of
attributes;
• every object has the same attributes but,
• each instance will have its own distinct values for those
attributes.
 Bank Example
class: Account

• The "account" class describes the number:

attributes and behaviors of bank
balance:
accounts.
• The “account” class defines two deposit()

state variables (account number and

withdraw()
balance) and two methods (deposit
and withdraw).
 Bank Example - Cont’d
Instance #1

number: 054

• When the program runs there will balance: $19

be many instances of the account
Instance #2
class.
• Each instance will have its own number: 712

account number and balance (object balance: $240

state)
• Methods can only be invoked . Instance #3

number: 036

balance: $941
 Encapsulation
When classes are defined, programmers can specify that
certain methods or state variables remain hidden inside the
class.
 These variables and methods are Visible Methods
accessible from within the class, but not
Hidden
accessible outside it. State
 The combination of collecting all the
Variables
and
attributes of an object into a single class Methods
definition, combined with the ability to hide
some definitions and type information Visible Variables
within the class, is known as
encapsulation.
Class
Definition
 Graphical Model of an Object
Instance balance()
variables

withdraw() theBalance deposit()

acctNumber

Methods
accountNumber()

State variables make up the nucleus of the object. Methods

surround and hide (encapsulate) the state variables from the rest
of the program.
 Instance Methods and Instance
Variables
The methods and variables described in this module so far are
know as instance methods and instance variables.

• These state variables are associated with the one instance of a

class; the values of the state variables may vary from instance
to instance.
• Instance variables and instance methods can be public or
private.
• It is necessary to instantiate (create an instance of) a class to
use it’s instance variables and instance methods.
 Class Methods and Class Variables

In addition to instance methods and instance variables, classes

can also define class methods and class variables.

• These are attributes and behaviors associated with the class as

a whole, not any one instance.
• Class variables and class methods can be public or private.
• It is not necessary to instantiate a class to use it’s class
variables and class methods.
 Class Variables
instance
variables

Account
class • A class variable defines an attribute of an entire class.
variable count: 3
• In contrast, num:
an instance
printCount bal: $19
054
variable defines
bal: $240
num: 036
num: 712 an attribute
bal: $941
of a
single instance of a class.
Class ()
method
 Inheritance

The advantage of making a new class a subclass is that it will

inherit attributes and methods of its parent class (also called
the superclass).

• Subclasses extend existing classes in three ways:

• By defining new (additional) attributes and methods.
• By overriding (changing the behavior) existing attributes and
methods.
• By hiding existing attributes and methods.
 Subclasses
When a new class is developed a programmer can define it to
be a subclass of an existing class.
• Subclasses are used to define special cases, extensions, or
other variations from the originally defined class.

Examples:
Generic Class for Terrier is
 Terrier can be defined as a Dog derived
With general from Dog
subclass of Dog. attributes and
Specific Class for
 SavingsAccount and
behaviors for all
dogs. Terrier
CheckingAccount can be With new attributes
and behaviors
derived from the Account specific to the
class (see following slides). Terrier breed.
 New Account Types - Cont’d
Suppose we define SavingsAccount and CheckingAccount
as two new subclasses of the Account class.

class SavingsAccount
class Account { extends Account {
method acctNum() method rate() {…}
{…} }
method balance()
{…}
class CheckingAccount
method deposit()
extends Account {
{…}
method withdraw() method withdraw()
{…}
{…}
}
}
 Account New Account
SavingsAccountTypes - Cont’d
CheckingAccount

acctNum() acctNum() acctNum()

balance() balance() balance()
deposit() deposit() deposit()
withdraw() withdraw() withdraw()

rate() withdraw()

No new code has to be written for deposit() and other

methods, they are inherited from the superclass.
 Messages
• Messages are information/requests that objects send to
other objects (or to themselves).
• Message components include:
• The name of the object to receive the message.
• The name of the method to perform.
• Any parameters needed for the method.

Manager Employee

Message
To: Employee
Method: getHired
Parameters: salary = $45,000, start_date =
10/21/99
 Benefits of Messages

Message passing supports all possible interactions between

two objects.

• Message passing is the mechanism that is used to invoke a method

of the object.
• Objects do not need to be part of the same process or on the same
machine to interact with one another.
• Message passing is a run-time behavior, thus it is not the same as a
procedure call in other languages (compile-time).
• The address of the method is determined dynamically at run-time, as the
true type of the object may not be known to the compiler.
 Polymorphism

Polymorphism is one of the essential features of an object-

oriented language; this is the mechanism of decoupling the
behavior from the message.

• The same message sent to different types of objects results in:

• execution of behavior that is specific to the object and,
• possibly different behavior than that of other objects receiving the same
message.
• Example: the message draw() sent to an object of type Square and an
object of type Circle will result in different behaviors for each object.
 Polymorphism – Cont’d

There are many forms of Polymorphism in object-oriented

languages, such as:

• True Polymorphism: Same method signature defined for different classes

with different behaviors (i.e. draw() for the Classes Circle and Square)
• Parametric Polymorphism: This is the use of the same method name within a
class, but with a different signature (different parameters).
• Overloading: This usually refers to operators (such as +,-,/,*, etc) when they
can be applied to several types such as int, floats, strings, etc.
• Overriding: This refers to the feature of subclasses that replace the behavior
of a parent class with new or modified behavior.
 OO Concepts Summary

• Object-oriented programming is a way of conceptualizing a program

as groups of objects that interact with one another.
• A class is a general template used to create objects.
• The combination of collecting all the attributes of an object into a
single class definition, combined with the ability to hide some
definitions within the class, is known as encapsulation.
• Classes can also define class variables and class methods which are
attributes and methods associated with the class as a whole.
• Inheritance allows classes to “inherit” attributes and methods from
their base (parent) class. This provides a clean mechanism for code
re-use and extension.
 Module Map
• Key Object-Oriented Systems Concepts
• Basic Software Lifecycle Concepts
• Software Lifecycles
• Common Lifecyle Activities
• Common Lifecyle Flows
• Introduction to OOA/OOD
 Software Lifecycles

Software lifecycles describe the evolution of a software

project from conception of the need for a software system to
the retirement or replacement of the resulting system.

Two key dimensions of a specific lifecycle are:

• The collection of activities to be done

• The flow or sequencing of those activities
 Common Lifecycle Activities

• Project Charter (definition): General description or problem statement,

top level business scenarios.
• Analysis: Systems level, low detail, problem space oriented. Results in
Requirements/Specification document.
• Design: Implementation level, high detail, solution space oriented.
Results in Software design/model document.
• Implementation: Coding, testing, UI, data design, documentation.
Results in deliverable product.
• Delivery: Configuration, training, maintenance, product evolution
planning.
• Product end of life planning: Replacement
 Common Lifecycle Flows

Lifecycle flows (there are just about as many of these as there

are software projects…) can generally be characterized as one
of the following types:

• Sequential
• Waterfall method, Structured Analysis & Design
• Iterative, Spiral and Recursive Methods
• There are a huge variety of these
• “Agile” or “LightWeight” Software Methods fit into this class
• Parallel Effort
• Unmanaged, Chaotic
Analysis and Design Space
Analysis and Design Space - Cont’d
 Module Map
• Key Object-Oriented Systems Concepts
• Basic Software Lifecycle Concepts
• Introduction to OOA/OOD
• Scenarios and Use Cases
• CRC’s
• Sequence Diagrams
• Class Diagrams
• UML Models
 Use Cases

Use cases describe the basic business logic of an application.

• Use cases typically written in structured English or Diagrams
• Represent potential business situations of an application
• Describes a way in which a real-world actor – a person, organization, or external system – interacts with
the application.

For example, the following would be considered use cases for a

university information system:
• Enroll students in courses
• Output seminar enrolment lists
• Remove students from courses
• Produce student transcripts.
Use Cases Diagrams
 Class Responsibility Collaborator Cards

• A CRC model is a collection of CRC cards that represent whole

or part of an application or problem domain
• The most common use for CRC models is to gather and define
the user requirements for an object-oriented application
• The next slide presents an example CRC model for a
shipping/inventory control system, showing the CRC cards as
they would be placed
• Note the placement of the cards: Cards that collaborate with
one another are close to each other, cards that don’t
collaborate are not near each other
 Class
Information
Methods and
Attributes
CRC Example
Collaborators
Class Name:

Parent Class:
CRC Card Layout
Subclasses:

Attributes: Collaborators (Sends Messages to):

Responsibilities:
 Sequence Diagrams

Traditional sequence diagrams show:

• The objects involved in the use case
• The messages that they send each other
• Return values associated with the messages

Sequence diagrams are a great way to review your work as

they force you to walk through the logic to fulfill a use-case
scenario and match the responsibilities and collaborators in
CRC cards.
Sequence Diagrams
 Class Diagrams

Class diagrams (object models) are the mainstay

of OO modeling
• They are used to show both what the system will be able to do (analysis)
and how it will be built (design)
• Class diagrams show the classes of the system and their
interrelationships
• Inheritance
• Aggregation
• Associations
Class Diagram
UML Models