Your SlideShare is downloading. ×



Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Escape from the Spaghetti Code Jungle Brian Foote University of Illinois at Urbana-Champaign 17 February 1998 SOOUG Winter ‘98
  • 2. UIUC Patterns Group Ralph Johnson’s Group
    • Smalltalk
    • Objects
    • Frameworks
    • Components
    • Refactoring
    • Evolution
    • Patterns
  • 3. Our Perspective
    • Objects, Patterns, Frameworks, and Refactoring really do work, and can lead to the production of better, more durable, more reusable code
    • To achieve this requires a commitment to tools, architecture, and software evolution, and to people with superior technical skills and domain insight
  • 4. Big Ball of Mud
    • The de-facto standard software architecture
    • Why is the gap between what we preach and what we practice so large?
  • 5. Where does Mud Come From
    • Throwaway Code
    • Legacy Mush
    • Urban Sprawl
    • Slash and Burn Tactics
    • Merciless Deadlines
    • Sheer Neglect
  • 6. Silver Buckshot
    • Objects
    • Frameworks
    • Patterns
    • Architecture
    • Process/Organization
    • Tools
  • 7. Objects
    • The revolution is over, and objects won
    • O-O Programming has become Programming
    • O-O Languages set the stage for the evolution of O-O Frameworks and Components
    • O-O Reuse works, but is not a panacea
  • 8. Frameworks
    • An Object-Oriented Framework is a collection of cooperating classes that together define a generic or template solution to a family of domain specific requirements.
    • Frameworks are often characterized by an inversion of control in which the framework plays the role of a main program in coordinating and sequencing application activity.
    • Frameworks embody design insight
  • 9. Notables on Frameworks
    • Interface design and functional factoring constitute the key intellectual content of software and are far more difficult to create or recreate than code
    • L. Peter Deutsch
    • A framework is the design for an application or subsystem
    • A set of abstract classes and the way objects in those classes collaborate
    • Ralph E. Johnson
  • 10. Framework Examples
    • Smalltalk-80 Model/View/Controller (MVC)
    • MacApp
    • InterViews ET++ OWL MFC
    • Taligent Frameworks
    • Choices
    • Battery Simulation
    • Accounts
  • 11. Object-Oriented Frameworks have made the GUI Revolution Possible
    • MVC begot
    • Lisa Toolkit begot
    • Macintosh Toolbox begot
    • MacApp begot
    • Interviews/ET++ begot
    • OWL/MFC begot AWT, etc.
    • The analysis and evolution underlying MVC
    • now permeates the industry
  • 12. Patterns
    • What’s New Here is that Nothing is New Here
    • Patterns are about what works
    • Patterns give us a way to talk about what works
    • Patterns distill experience
    • Patterns give us a concise design vocabulary
  • 13. Why Patterns
    • People do not design from first principles
    • People design by reusing things they’ve seen before
    • Same techniques appear over and over
    • Software industry needs to document what we do
  • 14. Alexander on Patterns
    • Patterns in solutions come from patterns in problems.
    • "A pattern is a solution to a problem in a context."
    • "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."
    • Christopher Alexander -- A Pattern Language
  • 15. The Gang of Four
    • Design Patterns : Elements of Reusable Object-Oriented Software
    • Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
    • Addison Wesley, 1995
    • A landmark book that changed the way programmers think about building object-oriented programs
  • 16. Composite
    • Context:
      • Developing OO software
    • Problem:
      • Complex part-whole hierarchy has lots of similar classes.
        • Example: document, chapter, section, paragraph.
    • Forces
      • • simplicity -- treat composition of parts like a part
      • • power -- create new kind of part by composing existing ones
      • • safety -- no special cases, treat everything the same
  • 17. Composite Idea: make abstract "component" class. Alternative 1: every component has a (possibly empty) set of components. Component Children Paragraph Chapter ... Problem: many components have no components
  • 18. Composite Component Container Children Composite Leaf
    • Composite and Component have the exact same interface.
      • • interface for enumerating children
      • • Component implements Children() by returning empty set
      • • interface for adding/removing children?
  • 19. Bird on Patterns
    • Learn the patterns and then forget ‘em
    • -- Charlie Parker
  • 20. Lehman and Belady
    • Lehman and Belady have studied the history of successive
    • releases in a large operating system. They find that the
    • total number of modules increases linearly with release number,
    • but that the number of modules affected increases exponentially with release number. All repairs tend to destroy the structure
    • to increase the entropy and disorder of the system.
    • Less and less effort is spent fixing original design flaws;
    • more and more is spent on fixing flaws introduced in earlier fixes.
    • As time passes, the system becomes less and less well ordered...
  • 21. Entropy
    • ...Systems program building is an entropy decreasing process,
    • hence inherently metastable.
    • Program maintenance is an entropy increasing process,
    • and even its most skillful execution only
    • delays the subsidence of the system into
    • unfixable obsolescence...
    • Maintenance, it would seem, is like fixing holes in a
    • failing dike. Eventually it fails, and must be
    • rebuilt. Only then are lessons learned during
    • its tenure exploited
  • 22. Iteration
    • Consider these two statements:
    • Iteration considered harmful
    • "Iteration" considered harmful
    • "Iteration" inspires visions of wheels spinning or dogs chasing their tails , or of money spinning down the drain ...
    • Most researchers who have examined where Reusable Objects come from have observed that they are the result of a highly iterative process
  • 23. Software Tectonics
    • Reconstruction
    • Major Upheaval
    • Throw it away
    • Incremental Change
    • Evolution
    • Piecemeal Growth
  • 24. Throwaway Code
    • Sometimes this is the right approach
    • There is the danger that such code will take on a life of its own
  • 25. Reconstruction
    • Atlanta’s Fulton County Stadium was built in 1966 and razed in 1997.
    • Two single purpose stadia, with skyboxes, are replacing it
  • 26. Sweep It Under the Rug
    • You may not know how to get rid of a problem, but at least you can cordon it off...
  • 27. Piecemeal Growth
    • Mir was designed to accommodate maintenance and growth
    • Core 1986
    • Kvant 1 1987
    • Kvant 2 1989
    • Kristall 1990
    • Spekter 1995
    • Docking 1995
    • Priroda 1996
  • 28. White-Box vs. Black-Box Frameworks
    • White-Box Frameworks
    • Are extended primarily via inheritance
    • Each method must abide by
    • the internal conventions of its superclasses
    • Are informally organized internally, yet encapsulated
    • "Permissive" scope rules allow structure to undergo experimentation
    • Are characteristic of the early , exploratory phases of a framework's
    • evolution
  • 29. Black-Box Frameworks
    • As a framework evolves
    • portions of the framework emerge as distinct components
    • Communication is in conformity with the components external protocol
    • Are indicative of a better, more mature understanding
    • of the structure of a system
    • Are a goal toward which framework designers should aspire
  • 30. The Fractal Model
    • Reusable object-oriented abstract classes, components and frameworks have lifecyles of their own that are distinct from those of the applications that incubate them
    • Objects evolve within and beyond the applications that spawned them
    • Structure emerges as objects evolve
    • Because the pattern in which they evolve is similar at each level, the overall pattern can be thought of as a fractal curve
    • Opportunistic , as opposed to driven by Risk
  • 31. Initial Design (Prototype) Phase
    • Usually a prototype (of sorts)
    • Informally structured
    • Employs expedient "code borrowing"
    • Constitutes a first pass at design
    • General design opportunities should be anticipated, where possible
    • Expedient design should never be mistaken for good design
  • 32. Exploratory (Expansionary) Phase
    • Occurs when a design is successful
    • Frequently occurs during the "perfective" maintenance phase
    • Characterized by the spawning of a number of specialized
    • variations on the original theme
    • Broad, shallow class hierarchies may develop
    • There is a risk of "mid-life" generality loss
    • These may be somewhat informally organized
    • A "white-box" phase
  • 33. Design Consolidation (Generalization) Phase
    • Where entropy reduction gets done
    • Class hierarchy is reorganized and refactored
    • Abstract classes that reflect structural regularities in the system emerge
    • Hierarchy comes to reflect the way you'd like to tell people you got it there
    • Refactoring at this point in a system's evolution allows the
    • designer to exploit the insights available from having specialized a design to suit a number of applications
    • Hindsight , which is now available, can be brought to bear on the redesign
    • A "black-box" phase
  • 34. Refactoring
    • Refactoring is the engine of Consolidation
    • Refactorings are program transformations that preserve program semantics, while improving structure
    • Refactoring has traditionally been done by hand, but tools are starting to emerge
    • Languages differ significantly in the degree to which they support refactoring
  • 35. Refactorings
    • Behavior Preserving Program Transformations
    • Move Method to Component
    • Promote Method to Superclass
    • Rename Instance Variable
  • 36. Maximal Diversity is Early
    • From Gould, Gilinsky, and German
    • Asymmetry of Lineages and the Direction of Evolutionary Time
    • Evolutionary groups generally concentrate diversity during their early histories
    • Any taxonomic group builds to maximum diversity, and declines to extinction
    • They suggest that their documented temporal asymettry
    • may display a fractal character of self similarity at all scales
    • [Early] asymmetry arises when an initial emptiness permits unusual opportunity for diversification
  • 37. Pottery and Headstones
    • Such patterns have been noted in the evolution of Egyptian pottery designs, New England headstones, and 19th century gas lanterns
    • ...the structural principles that fashion the molds
    • and set the constraints upon the pathways of change
    • be may more abstract, and therefore more common
    • to a broad range of disciplines wedded to
    • differing immediate mechanisms
  • 38. Architect-Builder
    • Architect also Builds -- Coplien
    • Deploy People along the Grain of the Domain
    • Intra- vs. Inter-cranial communication
    • Response to Le Corbusier
  • 39. Unfolding
    • Step-by-Step Adaptation
    • Feedback
    • Unpredictability
    • Awareness of the Whole
  • 40. Carriages and Locomotives
    • Locomotives were unprecedented, and evolved from crude forms driven by primary design considerations
    • Carriages evolved from stagecoach designs, and began as stagecoach frames on rolling stock
  • 41. Implications
    • Design pervades the lifecycle
    • Design pervades the organization
    • Emphasis is not so much on single applications as on developing the software infrastructure for solving a range of application requirements
    • If hindsight is so valuable , the perhaps current programmer deployment practices are backwards
    • Skilled designers may be most valuable during the design consolidation phase
    • Perhaps this perspective can lead to a
    • gentrification of maintenance
  • 42. Conclusions
    • Frameworks embody architecture
    • Patterns communicate design insight
    • Refactoring facilitates evolution
    • Architecture emerges as a domain is explored
    • Design pervades the lifecycle , and the organization
    • Tools can help. Better Tools are on the way
  • 43. Twain on Domain Knowledge
    • “ Do you mean to say I’ve got to know all the million trifling variations of shape in the banks of of this interminable river as well as I know the shape of the front hall at home?”
    • “ On my honor, you’ve got to know them better than any man did know the shapes of the halls in his own house.”
    • “ I wish I was dead!”
  • 44. Draining the Swamp
    • You can escape from the Spaghetti Code Jungle
    • Indeed you can transform the landscape
    • The key is not some magic bullet, but a long-term commitment to architecture , and to cultivating and refining quality artifacts for your domain
  • 45. Contact Information
    • Brian Foote
    • Dept. of Computer Science
    • 3253 DCL
    • 1304 W. Springfield
    • Urbana, IL 61801
    • (217) 328-3523
    • [email_address]