CSTA Spring Conference

Introduction to Object-Oriented Analysis

and
Object-Oriented Design

Mitchel G. Fry
 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

1-2
 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

1-3
 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.

1-4
 What is an Object?
Real-world objects have attributes and behaviors.
behaviors

Examples:
 Dog

 Attributes: breed, color, hungry, tired, etc.

 Behaviors: eating, sleeping, etc.
 Bank Account
 Attributes: account number, owner, balance
 Behaviors: withdraw, deposit

1-5
 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!)
1-6
 Software Objects - Cont’d
In traditional programming languages (Fortran, Cobol, C, etc)
data structures and procedures are defined separately.
 In object-oriented languages,
languages Bank
they are defined together. Account
 An object is a collection of
Account
attributes and the behaviors
Account
that operate on them.
 Variables in an object are called number:
attributes.
attributes balance:
 Procedures associated with an
deposit()
object are called methods. withdraw()

1-7
 Classes
The definitions of the attributes and methods of an object are
organized into a class.
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.

1-8
 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.

1-9
 Bank Example
 The "account" class describes the
attributes and behaviors of bank class: Account
accounts.
 The “account” class defines two
number:

state variables (account number balance:

and balance) and two methods
deposit()
(deposit and withdraw).
withdraw()

1 - 10
 Bank Example - Cont’d
 When the program runs there will Instance #1
be many instances of the account number: 054
class.
 Each instance will have its own
balance: $19

account number and balance Instance #2

(object state) number: 712
 Methods can only be invoked .
balance: $240

Instance #3

number: 036

balance: $941

1 - 11
 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
1 - 12
 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.

1 - 13
 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.

1 - 14
 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.

1 - 15
 Class Variables
 A class variable defines an attribute of an entire class.
 In contrast, an instance variable defines an attribute of a

single instance of a class.

instance
variables

Account
class
variable count: 3 num: 036
num: 054 num: 712
bal: $19 bal: $240 bal: $941
printCount()
Class
method

1 - 16
 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.

1 - 17
 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 derived
 Terrier can be defined as a
Dog from Dog
subclass of Dog. With general
attributes and Specific Class for
 SavingsAccount and
behaviors for all Terrier
CheckingAccount can be dogs. With new attributes
derived from the Account and behaviors
class (see following slides). specific to the
Terrier breed.
1 - 18
 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() {…} }
method deposit() {…}
method withdraw() {…}
} class CheckingAccount
extends Account {
method withdraw() {…}
}

1 - 19
 New Account Types - Cont’d
Account SavingsAccount 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.

1 - 20
 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
1 - 21
 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.

1 - 22
 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.

1 - 23
 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.

1 - 24
 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.

1 - 25
 Module Map
 Key Object-Oriented Systems Concepts
 Basic Software Lifecycle Concepts

 Software Lifecycles
 Common Lifecyle Activities
 Common Lifecyle Flows
 Introduction to OOA/OOD

1 - 26
 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

1 - 27
 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,
Implementation
documentation. Results in deliverable product.
 Delivery: Configuration, training, maintenance, product
Delivery
evolution planning.
 Product end of life planning: Replacement

1 - 28
 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

1 - 29
 Analysis and Design Space

1 - 30
 Analysis and Design Space - Cont’d

1 - 31
 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

1 - 32
 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.

1 - 33
 Use Cases Diagrams

1 - 34
 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

1 - 35
 CRC Example
Class
Information
Methods and
Attributes
Collaborators

1 - 36
 CRC Card Layout
Class Name:
Parent Class: Subclasses:

Attributes: Collaborators (Sends Messages to):

Responsibilities:

1 - 37
 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.
1 - 38
 Sequence Diagrams

                                                                        

                   

1 - 39
 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

1 - 40
 Class Diagram

1 - 41
 UML Models

1 - 42
 OOA/OOD Exercise # 1
This exercise is to learn an object-oriented analysis and design
(OOA/OOD) methodology known as responsibility driven
design.
 Using the real world structure of a instant teller machine, model the
objects involved (attributes and behaviors) and their relationships (who
sends messages to whom).
 Each object is represented on a 3x5 note card.

 You focus on identifying the various responsibilities that are needed for

the operation of an instant teller system and who (what object) should
implement those responsibilities.
 This is much like laying out an organizational flow chart. Layout the

cards on the table or tape them on a wall. Re-arrange, add new cards
and throwaway cards until it looks and feels “right” to you.

1 - 43