Tools2011 Keynote
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Tools2011 Keynote

on

  • 737 views

Keynote talk at TOOLS Europe 2011. http://toolseurope2011.lcc.uma.es/

Keynote talk at TOOLS Europe 2011. http://toolseurope2011.lcc.uma.es/

Statistics

Views

Total Views
737
Views on SlideShare
733
Embed Views
4

Actions

Likes
0
Downloads
16
Comments
0

1 Embed 4

http://www.linkedin.com 4

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • Roadmap\n
  • First we explore the nature of object-oriented programming and how it relates to modeling\n
  • Then we shall see that there are numerous gaps between models and code.\n
  • In the main part of this talk we explore various ways in which these gaps can be bridged, by surveying a number of past and ongoing research activities.\n
  • Finally we will attempt to draw some lessons and identify some interesting tracks for further work.\n
  • \n
  • Let us start by asking, what, exactly, is “the OO paradigm”.\nThink for a moment about what you have heard over the years, and what your own experience tells you.\n
  • One of the first promises was that objects (classes) could just be “reused by inheritance”. Inheritance was sold as an “incremental modification mechanism”.\nIt turns out that there is no free lunch, and reuse only comes as a side-effect of careful design.\n
  • Another early promise was that development would become simpler since the same concepts (objects) would be used in requirements, design and implementation. It would be “objects all the way down”. Although not entirely discredited, this is clear not the essence of OO.\n
  • Yet others emphasized the benefits of OO for encapsulation, data abstraction and information hiding. Although clearly important, these ideas developed independently of OO. Furthermore, they are, even today so poorly understood, that they are often confused and even equated as different terms for the same thing. (They aren’t. See, for example, William Cook’s recent essay.)\n
  • Yet another early characterization of the essence of OO was that the language had to support objects, classes and inheritance. If you were missing inheritance, say, you would only be “object-based”. The problem with this is that every language has slightly different semantics for these three concepts. With so many variants, this can hardly be the essence of OO.\n
  • This one is interesting, but somehow misses the point. Although we sometimes need to remind ourselves that everything in a OO program happens by sending messages, this does not tell us anything terribly useful or interesting about its design. \n
  • This is actually pretty cool, but doesn’t really help us any more than the previous point. Furthermore, in every OO language there are plenty of things that aren’t objects (even in Smalltalk), though you may have to search to find them.\n
  • None of these is the real OO paradigm, so, what is it?\n
  • The actual paradigm is: "Design your own Paradigm", ie "Programming is Modeling".\nAn OO program is a model — you design your own virtual world populated with interacting objects that spring from your imagination.\n\n
  • Another way to see it: "Every OO program is a DSL"\n
  • Why is this important?\nClosing the gap between programs and code facilitates change.\n
  • \n
  • Important aspects of the model are often missing in the code.\nThis makes it harder to make sure that changes are consistent.\nArchitecture and particularly architectural constraints are typically not explicit.\nThe programming language may get in the way — boilerplate code can obfuscate intent. Dependencies are often hidden, so it can be unclear what will be the impact of a change. Furthermore, the development context and project history is not part of the code at all.\n
  • Some features may be easy to find in the code, but others may be implemented by many components. Some features are inherently run-time abstractions. The IDE does not help, because it focuses on classes and other static abstractions. There is a missing link between the running application and the code.\n\n
  • In highly dynamic applications, reflection is needed to adapt behavior at run-time.\nUsually this is limited to introspection (examining the structure of objects), but often intercession is also supported (changing or extending structure or behavior).\nThe design of reflective features is often driven by implementation needs.\nAccessing or modifying the underlying VM or run-time is typically not possible, without developing a tailored VM.\n
  • Programming systems assume the world is consistent, but it isn’t.\nWe are used to moving between inconsistent contexts but programming systems don’t really support it.\nAs a consequence it is hard to track down bugs from a context that is no longer there, and it is hard to migrate from one running version to the next without shutting the system down.\n
  • \n
  • \n
  • \n
  • Moose is a platform for modeling software artifacts to enable software analysis.\nMoose has been developed for well over a decade. It is the work of dozens of researchers, and has been the basis of numerous academic and industrial projects.\n
  • The key to Moose’s flexibility is its extensible metamodel.\nEvery tool that builds on Moose is able to extend the metamodel with concepts that it needs, such as history.\n
  • The key to Moose’s flexibility is its extensible metamodel.\nEvery tool that builds on Moose is able to extend the metamodel with concepts that it needs, such as history.\n
  • The key to Moose’s flexibility is its extensible metamodel.\nEvery tool that builds on Moose is able to extend the metamodel with concepts that it needs, such as history.\n
  • The key to Moose’s flexibility is its extensible metamodel.\nEvery tool that builds on Moose is able to extend the metamodel with concepts that it needs, such as history.\n
  • The key to Moose’s flexibility is its extensible metamodel.\nEvery tool that builds on Moose is able to extend the metamodel with concepts that it needs, such as history.\n
  • The key to Moose’s flexibility is its extensible metamodel.\nEvery tool that builds on Moose is able to extend the metamodel with concepts that it needs, such as history.\n
  • System complexity - Clone evolution view\nClass blueprint - Topic Correlation Matrix - Distribution Map for topics spread over classes in packages\nHierarchy Evolution view - Ownership Map\n
  • System complexity - Clone evolution view\nClass blueprint - Topic Correlation Matrix - Distribution Map for topics spread over classes in packages\nHierarchy Evolution view - Ownership Map\n
  • System complexity - Clone evolution view\nClass blueprint - Topic Correlation Matrix - Distribution Map for topics spread over classes in packages\nHierarchy Evolution view - Ownership Map\n
  • System complexity - Clone evolution view\nClass blueprint - Topic Correlation Matrix - Distribution Map for topics spread over classes in packages\nHierarchy Evolution view - Ownership Map\n
  • System complexity - Clone evolution view\nClass blueprint - Topic Correlation Matrix - Distribution Map for topics spread over classes in packages\nHierarchy Evolution view - Ownership Map\n
  • System complexity - Clone evolution view\nClass blueprint - Topic Correlation Matrix - Distribution Map for topics spread over classes in packages\nHierarchy Evolution view - Ownership Map\n
  • System complexity - Clone evolution view\nClass blueprint - Topic Correlation Matrix - Distribution Map for topics spread over classes in packages\nHierarchy Evolution view - Ownership Map\n
  • System complexity - Clone evolution view\nClass blueprint - Topic Correlation Matrix - Distribution Map for topics spread over classes in packages\nHierarchy Evolution view - Ownership Map\n
  • Modern software systems are often built from a mix of technologies.\nThis makes it harder to understand the relation between models and code, and makes it more difficult to evolve the systems.\n
  • We extend the Moose meta-model with concepts relevant to J2EE applications, extract knowledge from various artifacts, and represent them in a common model.\n
  • Finally we can perform various analyses and visualize the results.\nHere we see a Transaction Flow diagram that visualizes the flow between application layers.\n
  • This tells us which transactions violate architectural constraints\n
  • Mondrian is a tool to script Moose visualizations using embedded domain-specific language. Essentially it is a component framework for visualization with a fluent interface.\n
  • Glamour is another such DSL, but for building dedicated model browsers.\n
  • Domain-specific languages help to maintain the link between models and code.\nUnfortunately such language extensions typically do not play well with the IDE.\nHere we see SQL and regexes as extensions to Smalltalk, with syntax highlighting integrated into the development tools.\n
  • Helvetia intercepts the compilation toolchain of Smalltalk to support both syntactic and semantic changes with low effort.\n
  • \n
  • In order to link source code with features, we represent code at run-time as structured objects (ASTs).\n\n
  • Bifröst is a framework that allows us to link the structure and behavior of objects to metaobjects that will intercede on their behalf.\nThe metaobjects can be shared, and they can also be composed to deal with multiple issues.\n
  • In this case, we exercise features, and the metaobjects “paint the trees” with annotations to track the correspondence.\n
  • This allows us to dynamically adapt which features to track at runtime, “grow” the features over time, and maintain the link between the source code in the IDE and the running system.\n
  • Hermion represents an early attempt to gather runtime information and exploit it to augment the Smalltalk IDE.\n
  • Hermion represents an early attempt to gather runtime information and exploit it to augment the Smalltalk IDE.\n
  • Hermion represents an early attempt to gather runtime information and exploit it to augment the Smalltalk IDE.\n
  • Hermion represents an early attempt to gather runtime information and exploit it to augment the Smalltalk IDE.\n
  • Senseo is an eclipse plugin that builds on the ideas of Hermion.\nUser studies suggest that this information helps developers solve maintenance tasks more quickly.\n
  • \n
  • Debuggers have severe limitations when trying to track down the source of bugs that do not immediately manifest themselves as errors.\nThe problem is that the run-time stack no longer contains the information which object was responsible for the error.\nOur approach is to track the flow of object references by means of first-class aliases.\nA debugger can then trace back through the aliases to the origin of any error.\n
  • Object Flow Analysis requires a modified VM that models references as objects. Every time a value is created or passed, a new “alias” is created, which also keeps track of the value of the object at the moment that the reference was passed. This effectively allows a debugger to travel “back in time”.\n
  • Pinocchio exposes the runtime to extensions by fully reifying it.\nObject flow analysis can be easily implemented by adapting the reified interpreter.\nTo avoid high runtime overhead, the extensions are being natively compiled (work in progress).\n
  • \n
  • We are used to think of source code evolving, but not running software systems.\nFor long-lived applications, it can be important to migrate the running code without stopping it.\nChangeboxes were an early prototype of this idea. A changebox-aware system could run multiple versions of the same code simultaneously.\nChanges to the development branch would not impact the deployed branch until changes are merged *in the running system*. Each changebox defines a context (or scope) consisting of classes defined in predecessor changebox, plus some new changes.\nThe problem is that contexts are not first-class entities, so tools need to be made changebox-aware.\n
  • We are used to think of source code evolving, but not running software systems.\nFor long-lived applications, it can be important to migrate the running code without stopping it.\nChangeboxes were an early prototype of this idea. A changebox-aware system could run multiple versions of the same code simultaneously.\nChanges to the development branch would not impact the deployed branch until changes are merged *in the running system*. Each changebox defines a context (or scope) consisting of classes defined in predecessor changebox, plus some new changes.\nThe problem is that contexts are not first-class entities, so tools need to be made changebox-aware.\n
  • We are used to think of source code evolving, but not running software systems.\nFor long-lived applications, it can be important to migrate the running code without stopping it.\nChangeboxes were an early prototype of this idea. A changebox-aware system could run multiple versions of the same code simultaneously.\nChanges to the development branch would not impact the deployed branch until changes are merged *in the running system*. Each changebox defines a context (or scope) consisting of classes defined in predecessor changebox, plus some new changes.\nThe problem is that contexts are not first-class entities, so tools need to be made changebox-aware.\n
  • Consider a highly available system in which the internal representation of certain objects changes. Not only the classes but the individual objects must be migrated, without disrupting the running system.\n
  • ActiveContext is research in progress built on top of Pinocchio.\nWhen classes change shape in long-lived systems, instances need to be migrated.\nInstead of requiring the system to reach a quiescent state, the system maintains first-class contexts.\nEvery object can potentially live in multiple contexts where threads are active.\nObject states are synchronized with the help of bidirectional transformations.\nWe are exploring ways to improve performance by using lazy transformations and garbage collecting unused contexts.\n
  • SCG postdocs and PhD students\n
  • \n
  • Simple languages can be better to work with than rich and complex ones.\nSimple visualizations can be more effective than complex ones.\n
  • To bridge the gap between models and code, make the boundaries explicit.\n- Explicit metamodels enable change (Moose, Bifröst)\n- First-class contexts enable migration (ActiveContext)\n- First-class interpreters enable runtime evolution (Pinocchio) \n
  • Link together static and dynamic views. Link together heterogeneous artifacts.\nBetter yet, keep them linked, rather than having to recover the links after the fact!\n
  • We are used to a sharp division between source code and run-time, but there is no productive reason to maintain this divide.\n
  • We need to better support change — what could this mean?\n\n
  • - A truly *object*-oriented IDE would link source code to run-time artifacts (cf Self’s Morphic UI framework and Seaside halos).\n\n
  • By toggling halos we can directly interact with objects of the application.\n
  • - A truly *object*-oriented IDE would link source code to run-time artifacts (cf Self’s Morphic UI framework and Seaside halos).\n\n
  • - We waste much time trying to trace back between various artifacts. The IDE should maintain the links between all artifacts.\n\n
  • - Once upon a time, FORTRAN was considered to be a high-level language from which *source code* was generated. Now we consider the HL language to *be* the source code. At some point we should start to think of the model as being the code.\n
  • - Once upon a time, FORTRAN was considered to be a high-level language from which *source code* was generated. Now we consider the HL language to *be* the source code. At some point we should start to think of the model as being the code.\n
  • The end\n

Tools2011 Keynote Presentation Transcript

  • 1. SynchronizingModels and Code Oscar Nierstrasz Software Composition Group scg.unibe.ch TOOLS Europe 2011 Keynote
  • 2. g nizin de chro CoSyn and lsM ode or: Mind the Gap Oscar Nierstrasz Software Composition Group scg.unibe.ch TOOLS Europe 2011 Keynote
  • 3. Programming is Modeling
  • 4. Programming is Modeling Mind the gap
  • 5. Programming is Modeling Mind the gap Bridging the gaps
  • 6. Programming is Modeling Mind the gap Bridging the gaps Lessons learned ...
  • 7. Programming is Modeling
  • 8. What exactly is“the OO paradigm”? 9
  • 9. What exactly is“the OO paradigm”? Think about it ... 9
  • 10. 10
  • 11. Reuse 10
  • 12. 11
  • 13. Design 11
  • 14. 12
  • 15. Encapsulation 12
  • 16. 13
  • 17. Objects + Classes + Inheritance 13
  • 18. 14
  • 19. Programs = Objects + Messages 14
  • 20. 15
  • 21. Everything is an Object! 15
  • 22. So, whatʼs missing? 16
  • 23. 17
  • 24. “Design your own paradigm” 18
  • 25. Itʼs all about enabling change 19
  • 26. Mind the gap
  • 27. Does this change respect the architecture? What does thispart depend on? Why is this code the way it is?Gap between Model and Code 21
  • 28. What is the run-time architecture? Where is this feature?Gap between static and dynamic views 22
  • 29. Gap between application and runtime How do I getunder the hood? 23
  • 30. How do I migrate to a new, clean state? What codecaused this bug? Gap between past, present and future 24
  • 31. How to bridge these gaps? 25
  • 32. Bridging the gap
  • 33. Bridging Models and Code
  • 34. Moose is a platform forsoftware and data analysis www.moosetechnology.org 28
  • 35. Model repositoryThe Story of Moose, ESEC/FSE 2005 29
  • 36. Model repository Navigation Metrics Querying GroupingThe Story of Moose, ESEC/FSE 2005 29
  • 37. Model repository Navigation Metrics Querying Grouping SmalltalkThe Story of Moose, ESEC/FSE 2005 29
  • 38. ConAn Van Hapax ... CodeCrawler Model repository Navigation Metrics Querying Grouping SmalltalkThe Story of Moose, ESEC/FSE 2005 29
  • 39. ConAn Van Hapax ... CodeCrawler Extensible meta model Model repository Navigation Metrics Querying Grouping SmalltalkThe Story of Moose, ESEC/FSE 2005 29
  • 40. ConAn Van Hapax ... CodeCrawlerSmalltalk Extensible meta model Java Model repositoryCOBOL Navigation C++ Metrics … Querying Grouping Smalltalk The Story of Moose, ESEC/FSE 2005 29
  • 41. ConAn Van Hapax ... CodeCrawlerSmalltalk Extensible meta model Java Model repositoryCOBOL External CDIF Navigation Parser C++ Metrics … Querying Grouping XMI Smalltalk The Story of Moose, ESEC/FSE 2005 29
  • 42. System complexity 30
  • 43. Clone evolution 31
  • 44. Class blueprint 32
  • 45. Topic correlation matrix 33
  • 46. Distribution map(topics spread over classes in packages 34
  • 47. Hierarchy evolution view 35
  • 48. Ownership map 36
  • 49. 37
  • 50. The problem with heterogeneous systems 38
  • 51. Inheritance * * subclass superclass 0..1 implementation JEEBean Class 1 belongsTo * MethodEntity Session MessageDriven invokedBy candidate 1 Layer * * Invocation BelongsToData Business Presentation Service Logic 39
  • 52. Start an unnecessary Starts UnnecessaryStart a Transactions Start Transactions TransactionsInheritTransactions Transactions Inherit Transactions Supports Transactions Support TransactionsNo attributes defined No attributes DB Accessors Staring Data base accessorDB accessors Data base accessor a Transaction starting a transaction 40
  • 53. Start an unnecessary Starts Unnecessary Start a Transactions Start Transactions Transactions InheritTransactions Transactions Inherit Transactions Supports Transactions Support Transactions No attributes defined No attributes DB Accessors Staring Data base accessor DB accessors Data base accessor a Transaction starting a transactionRecovery and Analysis of Transaction Scope from Scattered Information in Java Enterprise Applications, ICSM 2010 41
  • 54. Mondrian: An Agile Visualization Framework, SoftVis 2006 42
  • 55. 43
  • 56. Embedding Languages without Breaking Tools. ECOOP 2010 44
  • 57. 45
  • 58. Bridging Static and Dynamic Views
  • 59. Live Feature Analysis with 47
  • 60. Live Feature Analysis with 48
  • 61. Live Feature Analysis with 49
  • 62. Live Feature Analysis with Modeling Features at Runtime, MODELS 2010 50
  • 63. Hermion — linking source code to runtime 518 3
  • 64. Hermion — linking source code to runtime instrumented methods 518 3
  • 65. Hermion — linking source code to runtime instrumented methodsnavigate to senders 518 3
  • 66. Hermion — linking source code to runtime instrumented methodsnavigate to senders navigate to receivers 518 3
  • 67. Hermion — linking source code to runtime instrumented methodsnavigate to senders navigate to receivers types bound to variables 518 3
  • 68. Exploiting Dynamic Information in IDEs Improves Speed andCorrectness of Software Maintenance Tasks, IEEE TSE, to appear 528 3
  • 69. Bridging the Application and Runtime
  • 70. Problem: some errors arise after the bug is already off the stack 54
  • 71. Object Flow Analysis adapts the VM Practical Object-Oriented Back-in-Time Debugging, ECOOP 2008. 55
  • 72. an extensible VM for dynamic languages Interpreter extension interpretMethod: aMethod | result | result := super interpretMethod: aMethod. ^ assignSlot: aSlot to:result) (ReturnAlias alias: anAlias overrides | alias unwrappedSelf | environment: environment. unwrappedSelf := currentSelf value. Interpreter alias := (FieldWriteAlias alias: anAlias) environment environment: environment. interpret: aClosure alias predecessor: (aSlot readFrom: unwrappedSelf). ^ self send: (Message new selector: #value) ^ aSlot assign: alias on: unwrappedSelf to: aClosure asAliased implements nativelyC Core natives Pinocchio: Bringing Reflection to Life with First-Class Interpreters, OOPSLA Onward! 2010 56
  • 73. Bridging Past, Present and Future
  • 74. Releasebranch bug fix 58
  • 75. merged Deployed branchReleasebranch bug fix 59
  • 76. merged merged Deployed branchReleasebranch bug fixDevelopment branch broken refactored mergedEncapsulating and Exploiting Change with Changeboxes, ICDL 2007 60
  • 77. First-class contexts enable dynamic updates 61
  • 78. First-class contexts enable dynamic updates bidirectional transformation d con text Ol Method Shared object Method has one identity aPage but two states … Method Method … w co ntext Ne ongoing ... 62
  • 79. SCG Present and Past 63
  • 80. Lessons learned ...
  • 81. Less is More
  • 82. Reify EverythingConAn Van Hapax ... CodeCrawler Extensible meta model Model repository Navigation Metrics Querying Grouping Smalltalk tex t O ld con Method Method Interpreter extension aPage … Method overrides Interpreter Method environment implements natively … ActiveContext xt conte C Core natives N ew
  • 83. Link complementary views
  • 84. You can change a running system n text Old co Method Interpreter extension Method aPage overrides … Method Interpreter environment Method implements natively … ActiveContext C Core natives xt ew conte N
  • 85. Closing thoughts
  • 86. Closing thoughts An object-oriented IDE
  • 87. Closing thoughts An object-oriented IDE
  • 88. Closing thoughts An object-oriented IDE
  • 89. Closing thoughts Maintain the links
  • 90. Closing thoughts Manipulate models, not code
  • 91. Closing thoughts Manipulate models, not code
  • 92. Thatʼs all, Folks! Focus on change Maintain the linksAn object-oriented IDE Manipulate models, not code http://www.slideshare.net/onierstrasz