Docstoc

Object-oriented Design - PowerPoint

Document Sample
Object-oriented Design - PowerPoint Powered By Docstoc
					    Object-oriented Design
•   Brief History and Motivation
•   Foundations
•   Basic Concepts
•   Example of Notations
•   Contrived Examples of OO Code
•   OOAnalysis vs. OODesign
•   Advanced Concepts
•   Binding
•   Polymorphism
•   “Revolutionist” OOD Strategy
•   “Evolutionist” OOD Strategy
•   Strengths and Weaknesses
•   References for More Information
•   Summary
     Brief History and
        Motivation
• Grady Booch‟s Object-oriented
  Design for Ada originally published
  around 1984. Many other design
  methods followed in the late „80s
  and early 90‟s
• Object-oriented design is intended to
  capture the fundamental structure of
  an object-oriented program
• Object-oriented systems exhibit a
  higher level, more abstract structure
  which more accurately reflects how
  we think about systems
• Foundation: Mostly based on
  specific programming languages, no
  agreed-on formal theoretical
  foundation
      Big Bang Theory of
           Methods
                                                 1960?




                    ER                Function           State
                   Models              Models            Models




                                      IDEF-0 74
                                                                             SREM 76
 Chen 76       NIAM 75                                            PETRI 62
                                                 SD 72
                               SA 78

             MERISE 77                                                    SDL 77




    Booch 85
                                           Hatley-Pirbhai 86




Shlaer Mellor 88                                         Ward-Mellor 86


                                                                   Coad Yourdon 91
                   Booch 91

      OMT 89


                         UML 0.9 96                       OOSE 92
                                          UML 1.1 97
       Foundations

• Recall, these concepts are not
  themselves object-oriented, but
  they form the basis for
  understanding object-orientation
• Information Hiding
  – The interface and implementation
    of a program unit should be
    separate from each other.
  – The details of the implementation
    should be hidden from the
    customers, and only the interface
    should be visible
   Basic Concepts

• Class
• Object
• Service
• Method
• Message
• Reply
• Instance variable
Example of Notations
                                                                            Vat Level
                                                                             Sensor
             Area                                                   Read Level
                                           Vat Level
Start                                      Controller                       Vat Input
                                    Set Hold Level                           Valve
Stop
                                    Start                           Read Flow Rate
                                                                    Open
                                    Stop
                                                                    Close
           Filling
            Line
                                             Vat Ph                         Ph Control
Set Bottle Size                            Controller                         Valve
Start                               Set Ph Level                    Open
Stop                                Start                           Close
                                    Stop
                                                                            Ph Sensor

                                                                    Read Ph
                        Bottle
                                                    Filling
                        Loader
                                                    Station
        Load Bottle                                                         Bottle Fill
                                      Fill Bottle                            Valve
                                                                    Open
                                                Labeller            Close
             Position
             Contact                   Apply Label
 In Place?                       Release                               Scale
                                  Gate
                    Release                                   Read Weight
Contrived Examples of OO Code
 object VatInputValve;

 import
   InstrumentationInterface;

 service ReadFlowRate ( FlowRate );

 begin
   use InstrumentationInterface to get raw reading (0..255)
   convert raw reading to FlowRate (0..10 Gal/Min)
   return FlowRate
 end; { ReadFlowRate }

 service Open;

 begin
   use InstrumentationInterface to open the valve
 end; { Open }

 service Close;

 begin
   use InstrumentationInterface to close the valve
 end; { Close }

 end.   { VatInputValve }

 object FillingStation;

 import
   Labeller, Scale, BottleFillValve;

 service FillBottle ( BottleSize );

 begin
   FilledWeight := some function of bottle size;
   BottleFillValve.Open;
   repeat
     Scale.ReadWeight ( TotalWeight );
   until TotalWeight >= FilledWeight;
   BottleFillValve.Close;
   Labeller.ApplyLabel ( BottleSize );
 end; { FillBottle }
OOAnalysis vs. OODesign

 • Comparison
     • Both are based on object-
       oriented concepts
        – * Object, service, message, …

 • Contrast
     • What is being modeled
        – business policy / business
          process vs.
        – the structure of the automated
          solution
     • Character of dynamic
       connections
        – communication (net flow of
          information) vs. client-server
          relationships
   Advanced Concepts
• Class and Instantiation
      • An abstraction which represents a collection of
        objects that exhibit the same set of
        characteristics and that are subject to the same
        set of constraints, e.g.,
          – * Savings Account(s) as an abstract collection

• Instantiation
      • The act of creating a new object (occurrence) of
        a class, e.g.,
          –    X := SavingsAccount new.
          –    Y := CheckingAccount new.
          –    X open ( … ).
          –    Y open ( … ).

• Inheritance
      • A relationship between two or more classes
        where some classes (the subclasses) are partially
        defined in terms of, i.e., inherit the
        characteristics and constraints of, other classes
        (the superclasses), e.g.,
          – * Savings, IRA,401K, Money Market, … as
            subclasses of Interest Bearing Account
                     Binding
•   Definition
        • The act of associating attributes to a name. The name
          may refer to variables, functions, procedures, modules, or
          other program units. In particular, important attributes
          can be the type and location in the computer memory
          where the named element resides
• Binding may occur at many different stages in the
  translation of the source code into the executing
  system
        • Early (or compile-time) binding means attributes are
          statically associated to the name. The compiler (or
          interpreter) does this to ensure that subsequent uses of the
          name are consistent with its attributes
             – * C, Pascal, Cobol, Ada
        • Late (or run-time) binding means that the attributes are
          dynamically associated and may be changed while the
          system is executing, e.g.,
             – * APL, Basic, most OO languages

• Early vs. Late binding impacts run-time
  performance, preventability of type mis-match
  errors, and flexibility (i.e., ability to support rapid
  prototyping) of the language
          Polymorphism
• Translation from Greek means “many shapes” or
  “many faces”
• Definition
        • Allowing several classes to each offer a service with the
          same name (more precisely, “signature”), and further
          allowing those classes to respond differently to those
          service requests
• Consider a software simulation of a Chess game.
  Classes for the various types of chess pieces could all
  offer a service “FindPossibleMoves”. However,
  Pawns find their possible moves differently than
  Knights, who find their possible moves differently
  than Bishops, who find their possible moves
  differently than Queens, …
• Run-time binding is the means to allow
  polymorphism. If X is a chess piece, the statement
•                 X FindPossibleMoves
• cannot be unambiguously resolved
  (FindPossibleMoves bound to a memory address) until
  run-time when the type of X is known.
• Polymorphism supports abstraction and rapid
  prototyping (flexibility) at the expense of not
  preventing type mis-match errors and slower run-time
  performance
“Revolutionist” OOD Strategy
 • Note: the original Smalltalk philosophy
   was
 • “Who needs design, anyhow?”
 • The most common “revolutionist”
   strategy is:
       •   Identify classes (nouns tend to become classes)
       •   Identify instance variables
       •   Identify services
       •   Define client-server relationships
       •   Elaborate details of classes, instance variables,
           services (and methods)
 • In general, there is no separation of
   business policy/business process from
   technology. Design (by our definition)
   starts on Day 1 with customer domain
   and technology domain classes side-
   by-side
      “Evolutionist” OOD
           Strategy
• General strategy:
     • Analyze the business policy/business
       process using:
        – * Classes and relationships (both associative
          and inheritance)
        – * Communications
        – * Attributes + Behaviors + Processes
     • Design the system‟s interfaces
     • Derive the “core” of the architecture from
       analysis:
        –   *   Classes + assoc. relationships -> Classes
        –   *   Communications -> Services
        –   *   Attributes -> Instance variables
        –   *   Behaviors + Processes -> Methods
     • Derive the I/O services from the interfaces
     • Optimize for performance
        – * Assoc. relationships -> handles/references
Deriving Detailed Designs
       (Evolutionist)

                   Analysis                                                      Design
                                                                 package Obj ect A
                    St at e 1                                    t ype
       Event 2                                                      Obj ect _Type i s r ecor d
       T. Pr oc2                  Event 1                              At t r 1: i nt eger
       T. Pr oc3                  T. Pr oc1                            At t r 2: r eal
                                                                       St at e: ( St at e1, St at e2)
                    St at e 2
                                                                 var
                                                                   The_Obj ect i s t ype Obj ect _Name;
  D1                D2                      D3
                                                                 pr ocedur e Event 1 ( i n D1)
                                                      D4            i f The_Obj ect . St at e i s St at e2
                                                                       t hen Pr oc1( D1)
       Pr oc1            Pr oc2              Pr oc3                          set The_Obj ect . St at e t o St at e1
                                                                       el se ???
                                                                 pr ocedur e Event 2 ( i n D2, D3 out D4)
                                                       St at e      i f The_Obj ect . St at e i s St at e1
                                                                       t hen Pr oc2( D2)
                                                                             Pr oc3( D3, D4)
                                                                             set The_Obj ect . St at e t o St at e2
                   At t r i but e 1                                    el se ???
                   At t r i but e 2
                   St at e At t r i but e                        f unct i on Get _St at e
                                                                    r et ur n The_Obj ect . St at e




 reference: Steve Tockey, “Deriving a Design from an Object-oriented Analysis
 Specification”, Proceedings of the 1991 Software Improvement Conference, Washington,
 DC, November 18, 1991

 see also: Rick Hill, “Object Oriented Design for Ada, A Transformational Approach
 Based on Object Oriented Analysis”, Proceedings of the Eleventh Structured
 Development Forum, San Diego, Ca., April 31-May 3, 1990.

 and: Rick Hill, “Implementing Object Oriented Analysis Models, A Spectrum of
 Alternatives”, Proceedings of the Twelfth Structured Development Forum, Portland, Or.,
 July 9-11, 1991.
     Strengths and
     Weaknesses
• Strengths
     • A higher level, more abstract
       structure which more accurately
       reflects how we think about systems
     • Tendency toward higher cohesion
       and looser coupling
     • Objects are natural units for
       concurrency
• Weaknesses
     • Much variation across different
       proposed methods
     • No agreed-on formal foundation
     • Methods have not yet reached
       “critical mass”
     • CASE tool support is weak
     • Marketing hype
     Summary of
Object-oriented Design
•   Brief History and Motivation
•   Foundations
•   Basic Concepts
•   Example of Notations
•   Contrived Examples of OO Code
•   OOAnalysis vs. OODesign
•   Advanced Concepts
•   Binding
•   Polymorphism
•   “Revolutionist” OOD Strategy
•   “Evolutionist” OOD Strategy
•   Strengths and Weaknesses
•   References for More Information
•   Summary

				
DOCUMENT INFO