CSC 335: Object-Oriented Programming and Design

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

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

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

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

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

Functional Decomposition main readData saveData mainMenu deleteRecord addRecord editRecord

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

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

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

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.

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

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

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

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

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

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

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

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)

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.

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

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

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

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

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

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.

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

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?

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

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

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)

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

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

CSC 335: Object-Oriented Programming and Design