CSC 335: Object-Oriented Programming and Design

Object-Oriented Technology: A Brief Historical Perspective

Rick Mercer Pictures from OOT: A Manager’s Guide, David A. Taylor 1

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

Chapter 1: Beating 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 it’s supposed to? The software is not flexible enough to handle rapid changes 1-3

How Software is Constructed

   Wanted:  robust large-scale applications that evolve with the corporation It isn’t 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 1-4

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

Functional Decomposition

readData main mainMenu addRecord editRecord saveData deleteRecord 1-6

A Problem with Structured Design

 Structured programming has a serious limitation:  It’s rarely possible to anticipate the design of a completed system before it’s implemented  The larger the system, the more restructuring takes place 1-7

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

Don’t 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 1-9

Information (Data) Hiding

  An improvement:  Give each subroutine it’s 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.

1-10

Modularized Data

  Localize data inside the modules This makes modules more independent of one another.  Local Data 1-11

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

External Data

 A program that accesses data stored outside of the program  Data stored on an external file 1-13

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

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

The Procedural Approach

  The procedural style of programming builds systems one subroutine at a time.

  This approach doesn’t work well in large systems The result is defective software that is difficult to maintain There is a better way 1-16

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

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) 1-18

What’s 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.

1-19

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

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

One instance of a vehicle

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

1-22

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

Example messages

 Smalltalk examples sender is the object sending the message--sender is not shown here

vehicle104 moveTo:binB7 myAccount withdraw:100.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 1-24

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.

1-25

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

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   AT&T (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?

1-27

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

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

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) 1-30

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

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