1 / 16

Object-oriented Design

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

adamdaniel
Télécharger la présentation

Object-oriented Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

  3. Big Bang Theory of Methods 1960? Function Models State Models ER Models IDEF-0 74 SREM 76 NIAM 75 PETRI 62 Chen 76 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

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

  5. Basic Concepts • Class • Object • Service • Method • Message • Reply • Instance variable

  6. Example of Notations

  7. Contrived Examples of OO Code

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

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

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

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

  12. “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

  13. “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

  14. Deriving Detailed Designs (Evolutionist)

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

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

More Related