SynchronizingModels and Code       Oscar Nierstrasz  Software Composition Group         scg.unibe.ch         TOOLS Europe ...
g         nizin de    chro CoSyn and      lsM ode  or:               Mind the Gap                         Oscar Nierstrasz...
Programming is Modeling
Programming is Modeling                          Mind the gap
Programming is Modeling                                        Mind the gap                          Bridging the gaps
Programming is Modeling                                Mind the gap   Bridging the gaps                          Lessons l...
Programming is   Modeling
What exactly is“the OO paradigm”?                     9
What exactly is“the OO paradigm”?          Think about it ...                               9
10
Reuse        10
11
Design         11
12
Encapsulation                12
13
Objects + Classes + Inheritance                              13
14
Programs = Objects + Messages                            14
15
Everything is an Object!                           15
So, whatʼs missing?                      16
17
“Design your own paradigm”                             18
Itʼs all about enabling change                                 19
Mind the gap
Does this change respect                        the architecture? What does thispart depend on?                  Why is th...
What is the run-time                         architecture?       Where is this        feature?Gap between static and   dyn...
Gap between                   application                  and runtime  How do I getunder the hood?                       ...
How do I migrate to                   a new, clean state?   What codecaused this bug?            Gap between past,        ...
How to bridge these gaps?   25
Bridging the gap
Bridging Models and Code
Moose is a platform forsoftware and data analysis                   www.moosetechnology.org                               ...
Model repositoryThe Story of Moose, ESEC/FSE 2005                                29
Model repository            Navigation             Metrics            Querying            GroupingThe Story of Moose, ESEC...
Model repository            Navigation             Metrics            Querying            Grouping            SmalltalkThe...
ConAn    Van     Hapax     ...            CodeCrawler          Model repository            Navigation              Metrics...
ConAn       Van    Hapax        ...               CodeCrawler          Extensible meta model            Model repository  ...
ConAn       Van    Hapax        ...                           CodeCrawlerSmalltalk                      Extensible meta mo...
ConAn       Van    Hapax        ...                                             CodeCrawlerSmalltalk                      ...
System complexity                    30
Clone evolution                  31
Class blueprint                  32
Topic correlation matrix                           33
Distribution map(topics spread over classes in packages   34
Hierarchy evolution view                           35
Ownership map                36
37
The problem with heterogeneous systems                                     38
Inheritance                                                             *            *                                    ...
Start an unnecessary                        Starts UnnecessaryStart a Transactions Start Transactions                     ...
Start an unnecessary                                            Starts Unnecessary                    Start a Transactions...
Mondrian: An Agile Visualization Framework, SoftVis 2006                                                       42
43
Embedding Languages without Breaking Tools. ECOOP 2010                                                     44
45
Bridging Static and Dynamic Views
Live Feature Analysis with                             47
Live Feature Analysis with                             48
Live Feature Analysis with                             49
Live Feature Analysis with                        Modeling Features at Runtime, MODELS 2010                               ...
Hermion — linking source code to runtime                                           518                                    ...
Hermion — linking source code to runtime                                       instrumented methods                       ...
Hermion — linking source code to runtime                                                      instrumented methodsnavigate...
Hermion — linking source code to runtime                                                       instrumented methodsnavigat...
Hermion — linking source code to runtime                                                                         instrumen...
Exploiting Dynamic Information in IDEs Improves Speed andCorrectness of Software Maintenance Tasks, IEEE TSE, to appear   ...
Bridging the Application and          Runtime
Problem: some errors arise after the bug is already off the stack   54
Object Flow Analysis adapts the VM     Practical Object-Oriented Back-in-Time Debugging, ECOOP 2008.                      ...
an extensible VM for                                                             dynamic languages   Interpreter extension...
Bridging Past, Present and Future
Releasebranch          bug fix                   58
merged Deployed  branchReleasebranch                     bug fix                              59
merged               merged  Deployed   branchReleasebranch                                                            bug...
First-class contexts enable dynamic updates                                              61
First-class contexts enable dynamic updates                                bidirectional                                tr...
SCG Present and Past                       63
Lessons learned ...
Less is More
Reify EverythingConAn       Van    Hapax        ...             CodeCrawler        Extensible meta model          Model re...
Link complementary views
You can change a running system                                                     n  text                               ...
Closing thoughts
Closing thoughts  An object-oriented IDE
Closing thoughts  An object-oriented IDE
Closing thoughts  An object-oriented IDE
Closing thoughts   Maintain the links
Closing thoughts Manipulate models, not code
Closing thoughts Manipulate models, not code
Thatʼs all, Folks!                         Focus on change                                                    Maintain the...
Tools2011 Keynote
Upcoming SlideShare
Loading in...5
×

Tools2011 Keynote

629

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
629
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \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

    1. 1. SynchronizingModels and Code Oscar Nierstrasz Software Composition Group scg.unibe.ch TOOLS Europe 2011 Keynote
    2. 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. 3. Programming is Modeling
    4. 4. Programming is Modeling Mind the gap
    5. 5. Programming is Modeling Mind the gap Bridging the gaps
    6. 6. Programming is Modeling Mind the gap Bridging the gaps Lessons learned ...
    7. 7. Programming is Modeling
    8. 8. What exactly is“the OO paradigm”? 9
    9. 9. What exactly is“the OO paradigm”? Think about it ... 9
    10. 10. 10
    11. 11. Reuse 10
    12. 12. 11
    13. 13. Design 11
    14. 14. 12
    15. 15. Encapsulation 12
    16. 16. 13
    17. 17. Objects + Classes + Inheritance 13
    18. 18. 14
    19. 19. Programs = Objects + Messages 14
    20. 20. 15
    21. 21. Everything is an Object! 15
    22. 22. So, whatʼs missing? 16
    23. 23. 17
    24. 24. “Design your own paradigm” 18
    25. 25. Itʼs all about enabling change 19
    26. 26. Mind the gap
    27. 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. 28. What is the run-time architecture? Where is this feature?Gap between static and dynamic views 22
    29. 29. Gap between application and runtime How do I getunder the hood? 23
    30. 30. How do I migrate to a new, clean state? What codecaused this bug? Gap between past, present and future 24
    31. 31. How to bridge these gaps? 25
    32. 32. Bridging the gap
    33. 33. Bridging Models and Code
    34. 34. Moose is a platform forsoftware and data analysis www.moosetechnology.org 28
    35. 35. Model repositoryThe Story of Moose, ESEC/FSE 2005 29
    36. 36. Model repository Navigation Metrics Querying GroupingThe Story of Moose, ESEC/FSE 2005 29
    37. 37. Model repository Navigation Metrics Querying Grouping SmalltalkThe Story of Moose, ESEC/FSE 2005 29
    38. 38. ConAn Van Hapax ... CodeCrawler Model repository Navigation Metrics Querying Grouping SmalltalkThe Story of Moose, ESEC/FSE 2005 29
    39. 39. ConAn Van Hapax ... CodeCrawler Extensible meta model Model repository Navigation Metrics Querying Grouping SmalltalkThe Story of Moose, ESEC/FSE 2005 29
    40. 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. 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. 42. System complexity 30
    43. 43. Clone evolution 31
    44. 44. Class blueprint 32
    45. 45. Topic correlation matrix 33
    46. 46. Distribution map(topics spread over classes in packages 34
    47. 47. Hierarchy evolution view 35
    48. 48. Ownership map 36
    49. 49. 37
    50. 50. The problem with heterogeneous systems 38
    51. 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. 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. 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. 54. Mondrian: An Agile Visualization Framework, SoftVis 2006 42
    55. 55. 43
    56. 56. Embedding Languages without Breaking Tools. ECOOP 2010 44
    57. 57. 45
    58. 58. Bridging Static and Dynamic Views
    59. 59. Live Feature Analysis with 47
    60. 60. Live Feature Analysis with 48
    61. 61. Live Feature Analysis with 49
    62. 62. Live Feature Analysis with Modeling Features at Runtime, MODELS 2010 50
    63. 63. Hermion — linking source code to runtime 518 3
    64. 64. Hermion — linking source code to runtime instrumented methods 518 3
    65. 65. Hermion — linking source code to runtime instrumented methodsnavigate to senders 518 3
    66. 66. Hermion — linking source code to runtime instrumented methodsnavigate to senders navigate to receivers 518 3
    67. 67. Hermion — linking source code to runtime instrumented methodsnavigate to senders navigate to receivers types bound to variables 518 3
    68. 68. Exploiting Dynamic Information in IDEs Improves Speed andCorrectness of Software Maintenance Tasks, IEEE TSE, to appear 528 3
    69. 69. Bridging the Application and Runtime
    70. 70. Problem: some errors arise after the bug is already off the stack 54
    71. 71. Object Flow Analysis adapts the VM Practical Object-Oriented Back-in-Time Debugging, ECOOP 2008. 55
    72. 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. 73. Bridging Past, Present and Future
    74. 74. Releasebranch bug fix 58
    75. 75. merged Deployed branchReleasebranch bug fix 59
    76. 76. merged merged Deployed branchReleasebranch bug fixDevelopment branch broken refactored mergedEncapsulating and Exploiting Change with Changeboxes, ICDL 2007 60
    77. 77. First-class contexts enable dynamic updates 61
    78. 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. 79. SCG Present and Past 63
    80. 80. Lessons learned ...
    81. 81. Less is More
    82. 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. 83. Link complementary views
    84. 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. 85. Closing thoughts
    86. 86. Closing thoughts An object-oriented IDE
    87. 87. Closing thoughts An object-oriented IDE
    88. 88. Closing thoughts An object-oriented IDE
    89. 89. Closing thoughts Maintain the links
    90. 90. Closing thoughts Manipulate models, not code
    91. 91. Closing thoughts Manipulate models, not code
    92. 92. Thatʼs all, Folks! Focus on change Maintain the linksAn object-oriented IDE Manipulate models, not code http://www.slideshare.net/onierstrasz
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×