Object Design--Lecture I

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

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

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

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

5. Design Criteria (goals for DinoSim Park • From requirements • Safety • Reuse • Reliability • Maintainability • Hard requirements • Scalability to 200 distinct robots • Plug and play

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

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

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

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

10. Message Invocation of Typical Large System “Spaghetti O’s” Rule of Thumb : don’t nest classes too deeply

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

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

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

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

15. Encapsulation Level O raw lines of code Level 1 the procedural module Level 2 class/object structure

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

17. 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”

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

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

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

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

22. Next time • More about components

23. Reading • Scan Chapter 10; Explore patterns for developing components (pp 672-688) • For Monday, review Chapter 3 • For Wednesday, Chapter 4