CS535: Intro Lecture

CS535 Object-Oriented Programming & Design
Fall Semester, 1996
Intro Lecture

[To Lecture Notes Index]
San Diego State University -- This page last updated Saturday, 31 August, 1996

Contents of Intro Lecture

                                                 Intro Lecture Page 1

References

Object-Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988
Reading
Through chapter 3 of Core Java by Thursday, Sept. 5

Read chapter 4 of Core Java by Tuesday, Sept. 10

                                                 Intro Lecture Page 2

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

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 Page 3

Other Languages
Java
Self
Python
Perl
Prograph
Modula 3
Oberon
Scheme
Smalltalk Venders
ParcPlace, Digitalk, Quasar
Prolog++
Ada 95
Object Pascal (Delphi)
Object X, X = fortran, cobal, etc.

                                                 Intro Lecture Page 4

Methodologies

Approach to developing software

Methodologies encompass

Step-by-step methods
Graphical notation
Documentation techniques
Principles, guidelines, policies

Object-Oriented Design (OOD)

Booch

Object-Oriented Systems Analysis (OOSA)

Shlaer & Mellor

Object Modeling Technique (OMT)

Rumbaugh et al.

Object-Oriented Analysis (OOA)

Coad & Yourdon

Hierarachial Object Oriented Design (HOOD)

European Space Agency, HOOD Working Group

Responsibility-Driven Design

Wirfs-Brock et al.

Object-Oriented Software Engineering (Objectory)

Jacobson

Fusion

                                                 Intro Lecture Page 5

What is the Big Deal?

Category	# of Programmers	Duration	Size (loc)
Trivial	1	1-4wks	500
Small	1	1-6mos	1-2K
Medium	2-5	1-2yrs	5-50K
Large	5-20	2-3yrs	50-100K
Very Large	100-1000	4-5yrs	1M
Extremely large	2000-5000	5-10yrs	1-10M

Need better ways to develop software

Need to develop better software

                                                 Intro Lecture Page 6

Meyer's Criteria for Evaluating for Modularity

Decomposability

Decompose problem into smaller subproblems
that can be solved separately

Example: Top-Down Design

Counter-example: Initialization Module

                                                 Intro Lecture Page 7

Meyer's Criteria for Evaluating for Modularity Composability

Freely combine modules to produce new systems

Examples: Math libraries
Unix command & pipes

                                                 Intro Lecture Page 8

Meyer's Criteria for Evaluating for Modularity Understandability

Individual modules understandable by human reader

Counter-example: Sequential Dependencies

                                                 Intro Lecture Page 9

Meyer's Criteria for Evaluating for Modularity Continuity

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 Page 10

Meyer's Criteria for Evaluating for Modularity Protection

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

Example: Validating input at source

                                                 Intro Lecture Page 11

Principles for Software Development

KISS Keep it simple, stupid
Supports:


Understandablity
Composability

Decomposability

Small is Beautiful
Upper bound for average size of an operation[1]

Language	Lines of Code
Smalltalk	8
C++	24

Supports:

Decomposability
Composability
Understandability

                                                 Intro Lecture Page 12

Applications of Principles
First program:

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

Grow programs

Start with working program

Add small pieces of code and debug

                                                 Intro Lecture Page 13

What is Object-Oriented Programming

Language Level Definition

Class

Object

Inheritance

Conceptual Level Definition

Abstraction

Encapsulation

Information Hiding

Hierarchy

                                                 Intro Lecture Page 14

Language Level Definition of OOP

Object

                                                 Intro Lecture Page 15

Language Level Definition of OOP Class

                                                 Intro Lecture Page 16

Language Level Definition of OOP Inheritance

                                                 Intro Lecture Page 17

Conceptual Level Definition of OOP

Abstraction
"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

Example

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 Page 18

Conceptual Level Definition of OOP Encapsulation

Enclosing all parts of an abstraction within a container

Example

                                                 Intro Lecture Page 19

Conceptual Level Definition of OOP Information Hiding

Hiding parts of the abstraction

Example

                                                 Intro Lecture Page 20

Conceptual Level Definition of OOP Hierarchy
Abstractions arranged in order of rank or level

Class Hierarchy

                                                 Intro Lecture Page 21

Conceptual Level Definition of OOP Hierarchy

Object Hierarchy

                                                 Intro Lecture Page 22

Stages of Object-Oriented Expertise [2]

Novice
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."

Apprentice
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 Page 23

Stages of Object-Oriented Expertise Journeyman
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."

Guru
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."

CS535 Object-Oriented Programming & Design Fall Semester, 1996 Intro Lecture

Contents of Intro Lecture

CS535 Object-Oriented Programming & Design
Fall Semester, 1996
Intro Lecture