CSC 335: Object-Oriented Programming and Design

1
CSC 335 Object-Oriented Programming and Design

• Object-Oriented Technology
• A Brief Historical Perspective

Rick Mercer Pictures from OOT A Managers Guide,
David A. Taylor
2
Object-Oriented Technology

• Outline
• Consider a few ways in which data is protected
  from careless modification
• Mention the key features object-oriented style of
  software development
• Consider why object-oriented technology is
  important

3
Chapter 1Beating the Software Crisis

• Corporations continue to become more dependent on
  information
• Their ability to manage data decreases.
• The problem is the software, not the hardware
• The Software crisis
• How often is software delivered on time, under
  budget, and does what its supposed to?
• The software is not flexible enough to handle
  rapid changes

4
How Software is Constructed

• Wanted
• robust large-scale applications that evolve with
  the corporation
• It isnt easy!
• Modular Programming (the past 40 years)
• Break large-scale problems into smaller
  components that are constructed independently
• Programs were viewed as a collection of
  procedures, each containing a sequence of
  instructions

5
Modular Programming

• Subroutine (1950s)
• Provided a natural division of labor
• Could be reused in other programs
• Structured Programming and Design (1960s)
• It was considered a good idea to program with a
  limited set of control structures (no go to
  statements, single returns from functions)
• sequence, selection, repetition, recursion
• Program design was at the level of subroutines
• functional decomposition

6
Functional Decomposition
main
readData
saveData
mainMenu
deleteRecord
addRecord
editRecord
7
A Problem with Structured Design

• Structured programming has a serious limitation
• Its rarely possible to anticipate the design of
  a completed system before its implemented
• The larger the system, the more restructuring
  takes place

8
And What About the Data?

• Software development had focused on the
  modularization of code,
• the data was either moved around between
  functions via argument/parameter associations
• or the data was global
• works okay for smaller programs or for big
  programs when there aren't to many global
  variables
• Not good when variables number in the hundreds

9
Dont use Global Variables

• Sharing data (global variables) is a violation of
  modular programming
• This makes all modules dependent on one another
• this is dangerous
• Global Data

10
Information (Data) Hiding

• An improvement
• Give each subroutine its own local data
• This data can only be touched by that single
  subroutine
• Subroutines can be designed, implemented, and
  maintained independently
• Other necessary data is passed amongst the
  procedures via argument/parameter associations.

11
Modularized Data

• Localize data inside the modules
• This makes modules more independent of one
  another.
• Local Data

12
Data Outside of Programs

• Small programs require little input and output
• Large programs work with the same data over and
  over again
• Inventory control systems
• accounting systems
• engineering design tools
• Store data in external files

13
External Data

• A program that accesses data stored outside of
  the program
• Data stored on an external file

14
Sharing Data

• Many people must access the same data stored on
  file
• This requires a data base management system
  (DBMS)
• Data protected by a DBMS

15
The Relational DBMS Model

• Relational data bases store data in tables
• Each table can have primary and secondary keys
• For example, there is one table with complete
  information on all customers.
• Each of these records has a primary key called
  custID.
• MillerR 123 W. Palm, Civino, CA
• MillerT 987 E. Orange, New York, NY
• Another table stores all orders.
• Each record stores all order information with a
  secondary key named customer ID.
• Icees 6/8/01 MillerR 5 6.00 30.00 1.80 31.80
• Then you only need to store customer data once

16
The Procedural Approach

• The procedural style of programming builds
  systems one subroutine at a time.
• This approach doesnt work well in large systems
• The result is defective software that is
  difficult to maintain
• There is a better way

17
Object-Oriented Style of Design and Programming

• Three Keys to Object-Oriented Technology
• Objects
• Messages
• Classes
• Translation for structured programmers
• Variables
• Function Calls
• Data Types

18
Introducing objects

• OOT began with Simula 67
• developed in Norway
• acronym for simulation language
• Why this new language?
• to build accurate models of complex working
  systems
• The modularization occurs at the physical object
  level (not at a procedural level)

19
Whats in the System

• Simula 67 was designed for system simulation (in
  Norway by Nygaard and Dahl)
• Caller and called subprogram had equal
  relationship
• First notion of objects including class/instance
  distinctions
• Ability to put code inside an instance to be
  executed
• The class concept was first used here
• In procedural programming, systems are modeled as
  a collection of procedures.
• In object-oriented programming, the system is
  modeled as a collection of interacting objects.

20
Inside Objects

• An object is
• a software package that contains a collection
  of related methods and data
• an entity stored in computer memory
• an excellent software module
• an instance of a class
• a bunch of bits in memory or on the wire
• We understand an object through
• the values the object stores (state) via
  attributes the
• operations that can be applied to that object
  (behavior) Booch 92.

21
Modeling an Automated Vehicle

• Consider how we would mode an automated guided
  vehicle (AGV)
• Behaviors
• move from one location to another
• loading and unloading contents
• Must maintain information about
• its inherent characteristic pallet size, lifting
  capacity, maximum speed, ...
• its current state contents, location, velocity,
  ...

22
One instance of a vehicle

• Every object has
• a name
• instance variables stored in computer memory
• methods-a.k.a. procedures, member functions, ...

23
Introducing messages

• Real-world objects exhibit many effects on each
  other.
• These interactions are represented in software as
  messages (a.ka. method or function calls).
• A message has these three things
• sender the initiator of the message
• receiver the recipient of the message
• arguments data required by the receiver

24
Example messages

• Smalltalk examples
• sender is the object sending the
  message--sender is not shown here
• vehicle104 moveTobinB7
• myAccount withdraw100.00
• Java examples
• vehicle104.moveTo( binB7 )
• myAccount.withdraw( 100.00 )
• An object-oriented program consists of objects
  interacting with other objects by sending
  messages to one another

25
Introducing Classes

• We often need many of the same objects within a
  program--many numbers, Strings, BankAccounts,
  Employees, InventoryItems, ...
• We need an efficient way to redefine the same
  thing many times
• The class mechanism provides a template to define
  the methods and instance variables of objects.
• Each object (or instance) of a class has its own
  state--the set of values for that instance.

26
One Class can Generate Many Objects

• We can create many instances (objects) of the
  same class.
• Every object has
• name (a reference to it)
• state (values)
• methods

27
Important OO languages

• Simula started it all
• Smalltalk was released in early 80s
• Xerox Palo Alto Research Center PARC Place
• Alan Kay, Adele Goldberg
• It is Pure
• C started in the mid 80s
• ATT (Bjarne Stroustrup)
• Added classes to the popular C language
• Hybrid -- both procedural and object-oriented
• Ada became OO in 95
• Java started in the mid 90s just another C
  extension?

28
The OOT mindset

• Traditionally, software was developed to satisfy
  a specific requirements specification.
• A billing system could not be made into something
  else even if were similar.
• Let the billing system handle mailings or
  ticklers
• OOT has a different mindset
• Instead of beginning with the tasks to be
  performed, OO design deals with the aspects of
  the real world that need to modeled in order to
  perform the tasks

29
The OO approach

• The OO approach is
• more flexible
• more understandable -- it models the real world
• more maintainable--later programmers understand
  it better
• Basic corporate operations change more slowly
  than the information needs--software based on
  corporate models have a longer life span

30
A Wish for Reuse

• Traditional software started from scratch
• easier than converting old code--specific task
• OOT stresses reuse
• objects are the building blocks
• majority of time spent assembling proven
  components ex. Graphical User Interface (GUI)
• Borland's OWL, MS's MFC, or Java Swing
• But reuse is hard to obtain!
• I used to predict what we might need in the
  future I was right 10 of the time Ron
  Jeffries, an eXtreme Programmer (XP)

31
The Promise of the Approach

• OOT offers
• techniques for creating flexible, natural
  software modules.
• systems that are much easier to adapt to new
  demands
• reuse shortens the development life cycle
• systems are more understandable and maintainable
• easier to remember 50 real world classes rather
  than 500 functions

32
For Next Class

• Depending on your Java background, skim and/or
  read Chapters 3 and 4 from Core Java Volume I
• reviews 127A and 217BB or C Sc 227
• Have your lab access cards
• Go to 737 Gould-Simpson today or tomorrow and
  apply for your accounts
• can telnet from home user apply password apply
• you don't get new card until you sign paperwork