CSC 335: ObjectOriented Programming and Design - PowerPoint PPT Presentation

Loading...

PPT – CSC 335: ObjectOriented Programming and Design PowerPoint presentation | free to view - id: 528d2-NTg5M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

CSC 335: ObjectOriented Programming and Design

Description:

Designing OO Software, Rebbeca Wirfs-Brock, Wilkerson, Wiener ... Pictures from OOT: A Manager's Guide, David A. Taylor. Outline ... – PowerPoint PPT presentation

Number of Views:80
Avg rating:3.0/5.0
Slides: 41
Provided by: rickmercer
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: CSC 335: ObjectOriented Programming and Design


1
CSC 335 Object-Oriented Programming and Design
  • 27/Aug/02
  • Syllabus
  • Introduce Section Leaders
  • Introduce JBuilder
  • Object-Oriented Technology A Brief Historical
    Perspective

2
About this course
  • Read Syllabus
  • Check out the web page
  • There are only two required books
  • I'll ask you to read most chapters (days)
  • I will enhance this material from many textbooks
    that should be of interest
  • See recommended reading list on next slide

3
A few sources of lecture enhancements during this
semester
  • Computing Fundamentals with Java, Rick Mercer
  • 127A book plus GUIs, events, Exceptions, IO,
    designing an inheritance Hierarchy
  • Design Patterns Explained, A New Perspective on
    Object-Oriented Design, Alan Shalloway and James
    Trott
  • Abstract view of how design patterns can improve
    software quality
  • Refactoring, Improving the Design of Existing
    Code
  • Why making small changes to code results in
    better code
  • Extreme Programming Explained, William Lake
  • Concrete examples of what master programmers
  • Object-Oriented Design Heuristics, Arthur Riel
  • 60 guidelines to help write OO software
  • Designing OO Software, Rebbeca Wirfs-Brock,
    Wilkerson, Wiener
  • Responsibility-driven design using CRC cards

4
Reading List continued
  • Object-Oriented Technology OOT A Managers
    Guide, Taylor
  • Good introduction to object-oriented technology
    for IT managers. Also source for the outline and
    pictures in the remaining slides.

5
335 Section Leaders, Fall 2002
Section Section Leader Location Time 1
Jacob Pitts BIO E 307 800am
2 Shauna Eggers BIO E 307 900am 3H
Joshua Louie PAS 416 1100am 4
Armand Navabi BIO E 307 1200pm 5
Gergely Kota BIO E 307 100pm 6 Tom
Slattery HAURY 219 200pm 8 Cullen Linn
HARV 303 400pm 9 Charlie Chi HARV
303 500pm
6
Break
  • 5-minute break
  • We're available for questions now.
  • If you need to add or switch sections, see Rick
    now

7
Object-Oriented Technology Pictures from OOT A
Managers Guide, David A. Taylor
  • 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

8
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 its supposed to?
  • The software is not flexible enough to handle
    rapid changes

9
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

10
Modular Programming
  • Subroutine (1950s)
  • Provided a natural division of labor
  • Could be reused in other programs
  • Structured Programming and Design (1960s)
  • SPD 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

11
SPD Used Functional Decomposition
main
readData
saveData
mainMenu
deleteRecord
addRecord
editRecord
12
A Problem with SPD
  • 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

13
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

14
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

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

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

17
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

18
External Data
  • A program that accesses data stored outside of
    the program
  • Data stored within external files

19
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

20
The Relational DBMS Model
  • Data in a relational data base are stored in
    simple 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
  • OO Systems still talk to relational data bases

21
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

22
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

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

24
Whats in the System
  • Simula 67 was designed for system simulation (in
    Norway by Kristen Nygaard and Ole-Johan 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 functions and procedures that
    pass data all over the place
  • In object-oriented programming, the system is
    modeled as a collection of interacting objects
    where the data is encapsulated with the methods
    that need them

25
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
  • We understand an object through
  • the values the object stores (state) via
    attributes (instance variables
  • the operations that can be applied to that object
    (behavior) Booch 92.

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

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

28
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

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

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

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

32
Inheriting Class Information
  • Imagine we need several classes of similar
    automated Vehicles, BankAccount, or Employee
    objects.
  • We can derive new classes from existing ones
    through the inheritance mechanism.
  • The "top" class is called the superclass (or base
    class in Java).
  • The new class in called a subclass (or derived
    class in Java).

33
Inheritance
  • The superclass should pull together the common
    characteristics
  • The subclasses inherit methods and data
  • Derived classes can also add new data and methods
  • Derived classes can also override some methods to
    give the method new meaning
  • In Java you have overridden these Java methods
  • toString
  • equals

34
Inheritance Hierarchies
  • Classes can be extended to any degree.
  • Each new derived class accumulates the data and
    behavior (methods) of it ancestors
  • Much human knowledge is structured in this manner
    (insects, parts, lendables in a library)
  • We use software models of real world objects
  • The base class captures common data and behavior

35
Two Small Class Hierarchies
In UML
Software needed to control these AVs
36
Programming with Objects
  • 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
    (ugly stuff)
  • Ada became OO in 95
  • Java started in the mid 90s just another C
    extension?
  • C makes improvements to Java
  • int, double, char are true objects (not something
    different

37
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

38
The OO approach The Good
  • More natural -- models the real world, not the
    computer
  • More flexible
  • More maintainable
  • later programmers understand it better
  • touch as few self-contained classes as possible
  • More reliable can perform unit testing
  • Can build reusable modules (classes)
  • Extensible
  • Easier to add new functionality and offer
    alternatives
  • Accomplished through inheritance and polymorphism

39
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 A Ron
    Jeffries quote during the first Birds of a
    Feather on Extreme Programming (OOPSLA 1998)
  • Some frameworks have been successful
  • MacApp, ET, Interviews, Microsoft's MFC, Java's
    RMI

40
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
About PowerShow.com