SDSU CS 535: Object-Oriented Programming & Design
Fall Semester, 1997
Intro Lecture

To Lecture Notes Index
San Diego State University -- This page last updated 01-Sep-97

Contents of Intro Lecture

  1. References
  2. Introduction
    1. Methodologies
  3. Meyer's Criteria for Evaluating for Modularity
    1. Principles for Software Development
  4. What is Object-Oriented Programming
    1. Conceptual Level Definition of OOP
  5. Stages of Object-Oriented Expertise2


Object-Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988

Chapter 5 of The Java Programming Language by Thursday, Sept. 4

Chapter 6 of the Java Programming Language by Tuesday, Sept. 9

Intro Lecture Slide # 1


History and Languages

1967 Simula

1970 to 1983 Smalltalk

1979 Common LISP Object System

1980 Stroustrup starts on C++

1981 Byte Smalltalk issue

1983 Objective C

1986 C++

1987 Actor, Eiffel

1991 C++ release 3.0

199x Volume of OO books/articles
deforests Oregon

1995 Design Patterns

1996 Java

1983 to 1989 Language books with OO concepts

1989 to 1992 Object-oriented design books

1992 to present Object-oriented methodology books

Intro Lecture Slide # 2
Other Languages

Modula 3
Smalltalk Venders
ParcPlace, Digitalk, Quasar, Disney
Ada 95
Object Pascal (Delphi)
Object X, X = fortran, cobal, etc.

Intro Lecture Slide # 3


Approach to developing software

Methodologies encompass
Step-by-step methods
Graphical notation
Documentation techniques
Principles, guidelines, policies
Object-Oriented Design (OOD)

Object-Oriented Systems Analysis (OOSA)
Shlaer & Mellor

Object Modeling Technique (OMT)
Rumbaugh et al.

Object-Oriented Analysis (OOA)
Coad & Yourdon
Hierarchical Object Oriented Design (HOOD)
European Space Agency, HOOD Working Group

Responsibility-Driven Design (CRC)
Wirfs-Brock et al.

Object-Oriented Software Engineering (Objectory)


Intro Lecture Slide # 4
What is the Big Deal?
Category# of ProgrammersDuration Size (loc)
Very Large100-10004-5yrs1M
Extremely large2000-50005-10yrs1-10M

Need better ways to develop software

Need to develop better software

Intro Lecture Slide # 5

Meyer's Criteria for Evaluating for Modularity


Decompose problem into smaller subproblems
that can be solved separately

Example: Top-Down Design

Counter-example: Initialization Module

Intro Lecture Slide # 6
Meyer's Criteria for Evaluating for Modularity

Freely combine modules to produce new systems

Examples: Math libraries
Unix command & pipes

Intro Lecture Slide # 7
Meyer's Criteria for Evaluating for Modularity

Individual modules understandable by human reader

Counter-example: Sequential Dependencies

Intro Lecture Slide # 8
Meyer's Criteria for Evaluating for Modularity

Small change in specification results in:

Changes in only a few modules

Does not affect the architecture

Example: Symbolic Constants

const MaxSize = 100

Intro Lecture Slide # 9
Meyer's Criteria for Evaluating for Modularity

Effects of an abnormal run-time condition is confined to a few modules

Example: Validating input at source

Intro Lecture Slide # 10

Principles for Software Development

KISS Keep it simple, stupid


Intro Lecture Slide # 11
Small is Beautiful

Upper bound for average size of an operation[1]
LanguageLines of Code


Intro Lecture Slide # 12
Applications of Principles

First program:
   class HelloWorldExample 
      public static void main( String args[] ) 
         System.out.println( "Hello World" );

Intro Lecture Slide # 13

What is Object-Oriented Programming

Language Level Definition
Conceptual Level Definition

Intro Lecture Slide # 14

Conceptual Level Definition of OOP


"Extracting the essential details about an item or group of items, while ignoring the unessential details."
Edward Berard

"The process of identifying common patterns that have systematic variations; an abstraction represents the common pattern and provides a means for specifying which variation to use."
Richard Gabriel
Pattern:    Priority queue

Essential Details:   length 
   items in queue 
   operations to add/remove/find item

Variation:   link list vs. array implementation
   stack, queue

Intro Lecture Slide # 15
Conceptual Level Definition of OOP

Enclosing all parts of an abstraction within a container

Information Hiding

Hiding parts of the abstraction

Intro Lecture Slide # 16

Stages of Object-Oriented Expertise[2]


Duration: 3 to 6 months

"Novices spend their time trying to get their function-oriented heads turned around, so they can see the application object classes. They have a hard time finding the classes and write a lot of function-oriented code."


Duration: 3 to 6 months

"Apprentices begin to understand what object-orientation really means. They still prefer to work with others, who help foster an environment of discovery. Apprentices begin turning out good designs, although not consistently. Gurus and journeymen still need to keep an eye on apprentices."

Intro Lecture Slide # 17
Stages of Object-Oriented Expertise

Duration: varies greatly, a least a year

"Journeyman have internalized the OO paradigm and work independently. They can provide key inputs during the design reviews. They still have mental roadblocks that may require a guru to break through."


Duration: lifetime

"For gurus, OO development comes naturally. A guru automatically sees things in an OO perspective, moving quickly through the phases of development during rapid iterations. A guru can move the project over mental hurdles, causing others to see something clearly that eluded them before."

"There are very few gurus in the world today. The rest of us will have to rely on proven processes and methodologies."

"I've yet to see someone successfully make it past the novice stage and even consider thinking about software in other than OO terms."

Visitors since 03-Sep-97