Object design lecture i
1 / 23

Object Design--Lecture I - PowerPoint PPT Presentation

  • Uploaded on

Object Design--Lecture I. Elizabeth Bigelow School of Computer Science Software Engineering 15-413 Spring 2000. Story of a conversion from C to C++. A major CAD software company no change in functionality resulted in “double footprint” “swap file the size of Minnesota”

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Object Design--Lecture I' - alika

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Object design lecture i

Object Design--Lecture I

Elizabeth Bigelow

School of Computer Science

Software Engineering 15-413

Spring 2000

Story of a conversion from c to c
Story of a conversion from C to C++

  • A major CAD software company

    • no change in functionality resulted in

      • “double footprint”

      • “swap file the size of Minnesota”

      • “consumed resources like the Ebola Virus”


  • No free lunch (TANSTAFL)

  • Optimization for one design goal will result in less optimal performance on another

  • Long lived systems spend 80% of total cost of ownership after development so optimizations that make things easier to understand (maintainable) will have greatest payback

Optimization continued
Optimization, continued

  • With “layers” of systems, optimization decisions become more difficult

  • Run time efficiencies will have relatively little payback unless volume is extremely high, processing resources scarce

Design criteria goals for dinosim park
Design Criteria (goals for DinoSim Park

  • From requirements

    • Safety

    • Reuse

    • Reliability

    • Maintainability

  • Hard requirements

    • Scalability to 200 distinct robots

    • Plug and play

Implications of design criteria beyond dinosim
Implications of Design Criteria beyond DinoSim

  • Because of mix of physical and simulated devices, federation has high potential for use as overall system for park outside of simulation

  • Federates may be reused by disparate federates beyond DinoSim

  • Components are easier to reuse than federates


  • Scalability -- 200 distinct robots; one implication is that the number of federates perhaps should be minimized when there are implementation choices

  • Reliability -- a well tested management component will help reliability; suggests that testing be built in


  • Component, federate design

    • Maximizing cohesion (keeping like things together) and minimizing coupling (minimizing dependencies, keeping interfaces to just those data elements required or returned) has to be traded off for maintainability

    • Plug and play (composibility) may conflict with strict coupling. Can you think how this can be overcome?

Implications continued
Implications, continued

  • Reliability -- reliability enhanced by reuse of certain key features

  • Maintainability -- common structural (architectural) designs of federates enhance maintainability by making federates easier to understand (but may be non-optimal for a particular federate)

Message invocation of typical large system
Message Invocation of Typical Large System

“Spaghetti O’s”

Rule of Thumb : don’t nest classes too deeply

Origins of object design and terminology
Origins of Object Design and Terminology

  • Object design evolved from

    • data design

    • procedural design

  • Terms from antiquity

    • cohesion -- how alike things are--how many external references/calls have to be made to achieve purpose of procedure

    • coupling -- how tightly “modules” are tied to one another; number and strength of connections between procedures

Object oriented characteristics
Object Oriented Characteristics

  • Encapsulation - packaging of operations and attributes representing state into an object type so that state is accessible or modifiable only via interface provided by encapsulation

  • Information/implementation hiding--use of encapsulation to restrict from external visibility certain information or implementation decision that are internal

Object orientation
Object Orientation

  • Messages--vehicle by which a sender object conveys to target object demand to apply one of its methods

  • Classes--think of as “stencil” to manufacture manufacture instances at run-time

  • Inheritance

Object orientation1
Object Orientation

  • Polymorphism --property where by an attribute or variable may point to objects of different classes at different times

  • Genericity -- construction of a class C so that one or more of the classes it uses internally is supplied only at run-time when the object of class C is instantiated

  • State retention

  • Object identity--unique and permanent identity independent of current state


Level O

raw lines of


Level 1

the procedural


Level 2



Higher levels of encapsulation
Higher Levels of Encapsulation

  • Level -3

    • Packages and components (groupings of classes with only some of their interfaces visible externally

  • Level -4

    • Compositions

  • Design trade offs become more complex as encapsulation becomes more complex

Golden rules
Golden rules

  • Minimize coupling; maximize cohesion

  • Make classes map to “real world things”--at first, as structure changed for implementation, encapsulate to eventually map back to “real world things”

New term connascence
New Term -- Connascence

  • Somewhat like coupling but has extra considerations

  • Exists between two software elements A and B if

    • that you can postulate some change to A that would require B to be changed (or carefully checked) to preserve correctness

    • that you can postulate some change that would require both A and B to be changed together to preserve overall correctness


  • Other varieties

    • position (assembler jump)

    • directional (inheritance of names)

    • nondirectional (use same algorithm)

    • name (especially across class library--multiple inheritance problems

    • type or class

    • convention

    • execution (sequential, adjacent, timing, value (arithmetic constraint), identity


  • For maximum reuse

    • Minimize overall connascence through encapsulation

    • If there is connascence that crosses encapsulation boundaries, minimize it

    • Maximize connascence within encapsulation boundaries

  • Examples of abuses in object oriented systems --friend function C++, Unconstrained inheritance, relying on accidents of implementation

Component versus class federate versus component
Component versus class;Federate versus component

  • How should guidelines be established?

    • Always strive for reuse, even on first implementation

    • Analyze diagrams for dependencies; after minimizing, see where components or classes would be useful

  • Non functional considerations

    • People versus things

    • Knowledge of likely things to be reused in real world (more about this next time)

    • Real world-- at beginning only a few people can have an overall view; degree to which design can be participative depends on degree of willingness of participants to inform themselves of all factors -- HLA or other ORB, Middleware; similar systems; total design

Next time
Next time

  • More about components


  • Scan Chapter 10; Explore patterns for developing components (pp 672-688)

  • For Monday, review Chapter 3

  • For Wednesday, Chapter 4