Download - Object Design--Lecture I
![Page 1: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/1.jpg)
Object Design--Lecture I
Elizabeth BigelowSchool of Computer ScienceSoftware Engineering 15-413Spring 2000
![Page 2: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/2.jpg)
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”
![Page 3: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/3.jpg)
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
![Page 4: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/4.jpg)
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
![Page 5: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/5.jpg)
Design Criteria (goals for DinoSim Park
From requirements Safety Reuse Reliability Maintainability
Hard requirements Scalability to 200 distinct robots Plug and play
![Page 6: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/6.jpg)
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
![Page 7: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/7.jpg)
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
![Page 8: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/8.jpg)
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?
![Page 9: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/9.jpg)
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)
![Page 10: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/10.jpg)
Message Invocation of Typical Large System
“Spaghetti O’s”Rule of Thumb : don’t nest classes too deeply
![Page 11: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/11.jpg)
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
![Page 12: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/12.jpg)
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
![Page 13: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/13.jpg)
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
![Page 14: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/14.jpg)
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
![Page 15: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/15.jpg)
Encapsulation
Level Oraw lines ofcode
Level 1the proceduralmodule
Level 2class/objectstructure
![Page 16: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/16.jpg)
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
![Page 17: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/17.jpg)
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”
![Page 18: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/18.jpg)
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
![Page 19: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/19.jpg)
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
![Page 20: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/20.jpg)
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
![Page 21: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/21.jpg)
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
![Page 22: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/22.jpg)
Next time
More about components
![Page 23: Object Design--Lecture I](https://reader035.vdocuments.us/reader035/viewer/2022081603/5681592f550346895dc661d0/html5/thumbnails/23.jpg)
Reading
Scan Chapter 10; Explore patterns for developing components (pp 672-688)
For Monday, review Chapter 3 For Wednesday, Chapter 4