Object Design--Lecture I Elizabeth Bigelow School of Computer Science Software Engineering 15-413 Spring 2000.

Object Design--Lecture I

Elizabeth BigelowSchool of Computer ScienceSoftware Engineering 15-413Spring 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”“consumed resources like the Ebola Virus”

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

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

From requirements Safety Reuse Reliability Maintainability

Hard requirements Scalability to 200 distinct robots Plug and play

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

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

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

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

“Spaghetti O’s”Rule of Thumb : don’t nest classes too deeply

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

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

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 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 retentionObject identity--unique and permanent

identity independent of current state

Encapsulation

Level Oraw lines ofcode

Level 1the proceduralmodule

Level 2class/objectstructure

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

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

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

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

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

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

More about components

Reading

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

For Monday, review Chapter 3 For Wednesday, Chapter 4