• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
368
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
    • AFC AWT JFC IFC
    • 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
    • http://www.laputan.org
    • [email_address]