1 / 44

Modeling Change as a First-Class Entity

Modeling Change as a First-Class Entity. Oscar Nierstrasz Software Composition Group, University of Bern http://www.iam.unibe.ch/~scg/. Roadmap. Kinds of change Piccola Traits Classboxes Persephone & Geppetto Object Flow Analysis & Unstuck Moose Changeboxes Conclusions. Roadmap.

arich
Download Presentation

Modeling Change as a First-Class Entity

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Modeling Change as a First-Class Entity Oscar Nierstrasz Software Composition Group, University of Bern http://www.iam.unibe.ch/~scg/

  2. EOS DUE — Cesena, 2007 Roadmap • Kinds of change • Piccola • Traits • Classboxes • Persephone & Geppetto • Object Flow Analysis & Unstuck • Moose • Changeboxes • Conclusions

  3. EOS DUE — Cesena, 2007 Roadmap • Kinds of change • Piccola • Traits • Classboxes • Persephone & Geppetto • Object Flow Analysis & Unstuck • Moose • Changeboxes • Conclusions

  4. EOS DUE — Cesena, 2007 Software inevitably changes … • … but programming languages and development environments go out of their way to inhibit change rather than to support it • Symptoms: • Assumption of global consistency • Static type systems • Design patterns • … Oscar Nierstrasz, Alexandre Bergel, Marcus Denker, Stéphane Ducasse, Markus Gaelli and Roel Wuyts, “On the Revival of Dynamic Languages,” Proceedings of Software Composition 2005

  5. EOS DUE — Cesena, 2007 Kinds of change • Configuration • Refactoring • New functionality • Run-time adaptation • Bug fixes • Versions and branches There is an urgent need for programming languages and environments to provide explicit support for encapsulating and manipulating change.

  6. EOS DUE — Cesena, 2007 Proposal: a mechanism to tame software change Changeboxes • Encapsulate change • Delimit the scope of change • Enable changes depending on context • Dispatch on dynamic context Oscar Nierstrasz, Marcus Denker, Tudor Gîrba and Adrian Lienhard, “Analyzing, Capturing and Taming Software Change,” In Proceedings of the ECOOP'06 Workshop on Revival of Dynamic Languages.

  7. EOS DUE — Cesena, 2007 Roadmap • Kinds of change • Piccola • Traits • Classboxes • Persephone & Geppetto • Object Flow Analysis & Unstuck • Moose • Changeboxes • Conclusions

  8. EOS DUE — Cesena, 2007 Problem: reconfigure applications (without changing everything) Solution: Applications = Components + Scripts • Separate stable components from flexible configurations • Components import and export services • Scripts plug together (not wire) components

  9. EOS DUE — Cesena, 2007 Piccola in a nutsehll • Composition style wraps components with plug and socket interfaces • Scripts plug together components using forms, agents and channels www.iam.unibe.ch/~scg/Research/Piccola

  10. EOS DUE — Cesena, 2007 Piccola — lessons learned • First-class namespaces enable flexible composition • Conveniently express objects, components, modules, mixins layers, sandboxes, dynamic scoping … • Conceptual gap between core and target models • Components, plugs and styles vs. agents, forms and channels • Hard to express dynamically changing behaviour • Context is fixed Franz Achermann and Oscar Nierstrasz, “Explicit Namespaces”, Proceedings of JMLC 2000

  11. EOS DUE — Cesena, 2007 Roadmap • Kinds of change • Piccola • Traits • Classboxes • Persephone & Geppetto • Object Flow Analysis & Unstuck • Moose • Changeboxes • Conclusions

  12. EOS DUE — Cesena, 2007 Problem: refactoring commonality (without introducing fragility) Solution • Factor commonalities into “traits” • Resolve conflicts locally

  13. Object ColoredCircle TColor TCircle TCircle area bounds diameter hash ... radius radius: center center: EOS DUE — Cesena, 2007 Traits in a nutshell Traits are parameterized behaviors • Traits provide a set of methods ( ) • Traits require a set of methods ( ) • Traits do not specify any state Class = Superclass + State + Traits + Glue Stéphane Ducasse, Oscar Nierstrasz, Nathanael Schärli, Roel Wuyts and Andrew Black, “Traits: A Mechanism for fine-grained Reuse,” ACM TOPLAS, March 2006

  14. EOS DUE — Cesena, 2007 Traits — lessons learned • Flattening property • No special semantics — traits can be “compiled away” • Composing class retains control • Key to overcoming fragility • Can be extended to include state • State is private, unless explicitly exposed • Missing means to package collaborating traits • Purely fine-grained components • Missing means to dynamically activate traits • Traits are purely static (due to flattening) Alexandre Bergel, Stéphane Ducasse, Oscar Nierstrasz and Roel Wuyts, “Stateful Traits,” Proceedings of the International Smalltalk Conference, 2006, LNCS, to appear.

  15. EOS DUE — Cesena, 2007 Roadmap • Kinds of change • Piccola • Traits • Classboxes • Persephone & Geppetto • Object Flow Analysis & Unstuck • Moose • Changeboxes • Conclusions

  16. EOS DUE — Cesena, 2007 Problem: extending functionality (without breaking anything) Solution • A class extension adds or refines features of existing classes • Restrict visibility of class extensions to well-defined scope

  17. import MorphCB NewMorphCB class extension Morph Morph ... self paint ... “new implementation” repaint paint paint Button Button Button new repaint Button new repaint EOS DUE — Cesena, 2007 Classboxes Extensions in classboxes are locally rebound Alexandre Bergel, Stéphane Ducasse, Oscar Nierstrasz and Roel Wuyts, “Classboxes: Controlling Visibility of Class Extensions,” Computer Languages, Systems and Structures, December 2005

  18. EOS DUE — Cesena, 2007 Classboxes — lessons learned • Dynamic classboxes • Run-time enabling of aspects with dynamic classboxes • Traits + classboxes • Packaging collaborations as classboxes • Missing semantics of extension • Additions, modifications or refactorings? Alexandre Bergel and Stéphane Ducasse, “Scoped and Dynamic Aspects with Classboxes,” L'Objet, November 2005 Alexandre Bergel and Stéphane Ducasse, “Supporting Unanticipated Changes with Traits and Classboxes,” Proceedings NODE'05

  19. EOS DUE — Cesena, 2007 Roadmap • Kinds of change • Piccola • Traits • Classboxes • Persephone & Geppetto • Object Flow Analysis & Unstuck • Moose • Changeboxes • Conclusions

  20. EOS DUE — Cesena, 2007 Problem: changing a running system (without anticipated hooks) Solution • Reflection on-demand • Runtime structural reflection • Unanticipated, partial behavioural reflection

  21. But … Bytecode is too low level EOS DUE — Cesena, 2007 First Idea: ByteSurgeon • Structural reflection on-demand • Transform bytecode at runtime • Inline Smalltalk code before / after a bytecode (Example>>#example) instrumentSend: [:send | send insertBefore: ‘Transcript show: ‘’sending #test’’ ‘. ] Marcus Denker, Stéphane Ducasse and Éric Tanter, “Runtime Bytecode Transformation for Smalltalk,” Journal of Computer Languages, Systems and Structures, July 2006

  22. EOS DUE — Cesena, 2007 Persephone: Reflective Methods • High level model of sub-method structure • Abstract Syntax Tree (AST) • Bytecode generation on demand • Annotations for AST nodes • Meta data for any node • CompilerPlugin provides optionally semantics Philippe Marschall, “Persephone: Taking Smalltalk Reflection to the sub-method Level”, Masters thesis, University of Bern, December 2006.

  23. EOS DUE — Cesena, 2007 Geppetto • Behavioural reflection on-demand • Uses annotations to link code to metaobjects • Reify language constructs • Message-sending • Variable access David Röthlisberger, Marcus Denker and Éric Tanter, “Unanticipated Partial Behavioral Reflection,” 14th International Smalltalk Conference, 2006

  24. EOS DUE — Cesena, 2007 Reflection on-demand — lessons learned • High-level reflection enables analysis • Applications to fast method wrappers, run-time tracing, test coverage analysis … • Reflection need not be expensive • On-demand = partial and unanticipated • Reflection should be scoped to relevant contexts • Need mechanisms to specify and trigger scoping Oscar Nierstrasz, Alexandre Bergel, Marcus Denker, Stéphane Ducasse, Markus Gaelli and Roel Wuyts, “On the Revival of Dynamic Languages,” Proceedings of Software Composition 2005

  25. EOS DUE — Cesena, 2007 Roadmap • Kinds of change • Piccola • Traits • Classboxes • Persephone & Geppetto • Object Flow Analysis & Unstuck • Moose • Changeboxes • Conclusions

  26. EOS DUE — Cesena, 2007 Problem: tracking down defects (when the offending context is already gone) Solution • Keep track of object flow • Maintain history of running application

  27. EOS DUE — Cesena, 2007 Object Flow Analysis • Track flow of object references by means of first-class aliases • Trace back flow from errors to code that produced the objects Adrian Lienhard, Stéphane Ducasse and Tudor Gîrba, “Object-Centric View on Dynamic Analysis”, submitted

  28. EOS DUE — Cesena, 2007 Unstuck — a back-in-time debugger Christoph Hofer, Marcus Denker and Stéphane Ducasse, “Design and Implementation of a Backward-In-Time Debugger,” NODE'06, 2006

  29. EOS DUE — Cesena, 2007 Object flow / Unstuck — lessons learned • Scoped reflection helps to control instrumentation • Don’t instrument the instrumentation infrastructure! • Instrument code only while running in relevant context • High cost of instrumentation and data analysis • Can significantly lower cost of development • Can scoped reflection help to further reduce cost?

  30. EOS DUE — Cesena, 2007 Roadmap • Kinds of change • Piccola • Traits • Classboxes • Persephone & Geppetto • Object Flow Analysis & Unstuck • Moose • Changeboxes • Conclusions

  31. EOS DUE — Cesena, 2007 Problem: understanding change (without reading all the code) Solution • Represent history as a first-class entity • Use simple visualizations to expose patterns

  32. EOS DUE — Cesena, 2007 The Evolution Matrix Michele Lanza, “The Evolution Matrix: Recovering Software Evolution using Software Visualization Techniques,” IWPSE 2001

  33. EOS DUE — Cesena, 2007 Hierarchy evolution view Tudor Gîrba, Michele Lanza and Stéphane Ducasse, “Characterizing the Evolution of Class Hierarchies,” CSMR'05

  34. Edit Takeover Monologue Familiarization Dialogue EOS DUE — Cesena, 2007 Ownership maps • Colour lines to show who “owns” an artifact • I.e., who wrote most lines of code Tudor Gîrba, Adrian Kuhn, Mauricio Seeberger and Stéphane Ducasse, “How Developers Drive Software Evolution,” IWPSE 2005

  35. Dyna Van Hapax ... Mondrian CodeCrawler SVN CVS Browsing Smalltalk Metrics Java External Parser MSE Querying Grouping C++ … EOS DUE — Cesena, 2007 Moose Extensible meta model Model repository Smalltalk (VW)

  36. EOS DUE — Cesena, 2007 Moose — lessons learned • Make your meta-model explicit • Helps to develop and integrate tools • Use a dynamic programming environment • Speeds development of new ideas • No artificial compile-time/run-time dichotomy! • Need change as a first-class entity • Capture semantics of change • Manipulate change • Reason about the impact of change Oscar Nierstrasz, Stéphane Ducasse and Tudor Gîrba, “The Story of Moose: an Agile Reengineering Environment,” ESEC/FSE 2005

  37. EOS DUE — Cesena, 2007 Roadmap • Kinds of change • Piccola • Traits • Classboxes • Persephone & Geppetto • Object Flow Analysis & Unstuck • Moose • Changeboxes • Conclusions

  38. EOS DUE — Cesena, 2007 Problem: changing a running system (without impacting clients) Solution • Treat change as a first-class entity

  39. EOS DUE — Cesena, 2007

  40. EOS DUE — Cesena, 2007 Changeboxes • Encapsulate change • Capture changes to methods, state, class hierarchy • Express semantics of refactoring and other changes • Delimit the scope of change • Restrict scope of changes to specific clients • Delay global impact • Enable changes depending on context • Dynamically extend the scope of changes • Manage system evolution • Dispatch on dynamic context • Dynamically apply or disable changes • Temporally or contextually scope changes

  41. EOS DUE — Cesena, 2007 Changeboxes — lessons learned • The world is inconsistent — deal with it! • Changeboxes enable inconsistent views • Need to capture higher-level semantics of change • Tools must be aware of meaning of change to record it • Need new metaphors for managing change • Missing tools to manipulate N-dimensional change Pascal Zumkehr, “Changeboxes — Modeling Change as a First Class Entity,” Masters thesis, University of Bern, January 2007.

  42. EOS DUE — Cesena, 2007 Roadmap • Kinds of change • Piccola • Traits • Classboxes • Persephone & Geppetto • Object Flow Analysis & Unstuck • Moose • Changeboxes • Conclusions

  43. EOS DUE — Cesena, 2007 Conclusions — Taming change with changeboxes • Directions • Capturing high-level semantics of changes • Refactoring transformations • Dynamic propagation of changes • Forking and merging of concurrent versions • Context-oriented programming • Multi-dimensional dispatch • Challenges • Suitable core language? • Reasoning about change? • More flexible forms of static typing? Questions? Comments?

More Related