object design lecture i
Download
Skip this Video
Download Presentation
Object Design--Lecture I

Loading in 2 Seconds...

play fullscreen
1 / 23

Object Design--Lecture I - PowerPoint PPT Presentation


  • 66 Views
  • 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”

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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”
optimization
Optimization
  • 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
implications
Implications
  • 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
implications1
Implications
  • 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
encapsulation
Encapsulation

Level O

raw lines of

code

Level 1

the procedural

module

Level 2

class/object

structure

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
connascence
Connascence
  • 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
principles
Principles
  • 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
reading
Reading
  • Scan Chapter 10; Explore patterns for developing components (pp 672-688)
  • For Monday, review Chapter 3
  • For Wednesday, Chapter 4
ad