You say model, I say program — let's call the whole thing off


Published on

Invited Talk at the Second International Workshop on Combined Object-Oriented Modeling and Programming Languages, July 1, 2013

Published in: Technology
1 Comment
1 Like
  • Positively awesome title :)
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

You say model, I say program — let's call the whole thing off

  1. 1. You say program, I say model (let’s call the whole thing off) Oscar Nierstrasz Software Composition Group
  2. 2. Roadmap 1. Programming vs Modeling 2. The IDE 3. Architecture 4. Evolution
  3. 3. 1. Programming vs Modeling
  4. 4. Problems Gap between models and code - Gap between models and code: features vs code? architecture vs code? - UML is of limited use due to the difficulty of keeping code and models in sync - MDE is largely static, is applicable only in limited settings, and is costly to set up M3 M2 M1 M0 Synchronizing models and code meta-meta model meta-model model "the real world" MDE’s limited applicability
  5. 5. What exactly is “the OO paradigm”? Let us start by asking, what, exactly, is “the OO paradigm”. Think for a moment about what you have heard over the years, and what your own experience tells you. Think about it ... 5
  6. 6. “Design your own paradigm” Another way to see it: "Every OO program is a DSL" 6
  7. 7. API = Metamodel = DSL Configuration = Model = Script 7
  8. 8. How to make tools understand DSLs? Domain-specific languages help to maintain the link between models and code. Unfortunately such language extensions typically do not play well with the IDE. Here we see SQL and regexes as extensions to Smalltalk, with syntax highlighting integrated into the development tools. Renggli et al., Embedding Languages without Breaking Tools. ECOOP 2010 8
  9. 9. Helvetia Helvetia intercepts the compilation toolchain of Smalltalk to support both syntactic and semantic changes with low effort. 9
  10. 10. A Moldable Debugger Stack Announcement receiver Subscriptions Announcement source Chiş et al, Towards a Moldable Debugger, DYLA 2013 10
  11. 11. Challenges Domain-aware tools Visual DSLs Multiple views
  12. 12. 2. The IDE
  13. 13. Problems Gap between objects and classes Developers spend more time reading than writing code Especially with OO, where the code does not reflect run time behaviour well, more time is spent reading than writing, to understand code and to understand impact of change. IDEs do not well support this reading activity, since they focus on PL concepts, like editing, compiling and debugging, not architectural constraints, or user features. IDEs are code-centric
  14. 14. Hermion Hermion represents an early attempt to gather runtime information and exploit it to augment the Smalltalk IDE. instrumented methods navigate to senders types bound to variables navigate to receivers 14
  15. 15. Senseo Senseo is an eclipse plugin that builds on the ideas of Hermion. User studies suggest that this information helps developers solve maintenance tasks more quickly. Röthlisberger, et al. Exploiting Dynamic Information in IDEs Improves Speed and Correctness of Software Maintenance Tasks. IEEE TSE 2011 15
  16. 16. Linking applications to the IDE A truly *object*-oriented IDE would link source code to run-time artifacts (cf Self’s Morphic UI framework and Seaside halos). By toggling halos we can directly interact with objects of the application. cf. Smith & Maloney’s Morphic framework 16
  17. 17. Challenges “Live” programming Linking the IDE and the runtime
  18. 18. 3. Architecture
  19. 19. Problems Architecture is not in the code Checking architecture is hard
  20. 20. What is Software Architecture? Constraints govern Components/ Connectors enable Properties/ Analyses SA is more than just boxes and arrows diagrams. According to Shaw and Garlan, SA consists of a vocabulary of design elements (eg layers, components & connectors etc.), constraints over how these are composed, and a set of properties (or analyses) that these constraints enable. 20
  21. 21. What is SA in the Wild? The theory seems to suggest that SA is mainly about structure and dependencies. Our experience with actual projects suggested that the truth might be different. We carried out a couple of empirical studies, first a qualitative one to understand what is SA in the wild, and then a second, quantitative one to see to what extent various kinds of constraints appear in practice. 21
  22. 22. Impact of SA constraints In the quantitative study we asked developers how important different kinds of architectural constraints were for their projects. Interestingly, in the top ten, there were significantly more user constraints, like availability (in green) than developer constraints (in blue). Dependencies were only halfway down the list. constraint Impact (1-5) availability 4.2 response-time 4.0 authorization 3.9 authentication 3.6 communication 3.4 throughput 3.4 signature 3.4 software infrastructure 3.3 data integrity 3.3 recoverability 3.1 dependencies 3.1 visual design 3.0 data retention policy 3.0 hardware infrastructure 2.9 system behavior 2.9 data structure 2.9 event handling 2.9 code metrics 2.7 meta-annotation 2.6 naming conventions 2.6 file location 2.5 accessibility 2.5 software update 2.2 22
  23. 23. if . co de re vi bl ew ac kb ox w te h it st eb ox to ol te st ot h er o ve r For most architectural constraints, few dedicated tools are available. Dependencies have a disproportionately high number of tools available. Many constraints are not verified at all. availability response-time authorization authentication communication throughput signature software infrastructure data integrity recoverability dependencies visual design data retention policy hardware infrastructure system behavior data structure event handling code metrics meta-annotation naming conventions file location accessibility software update n Tool support constraint 0.35 0.06 0.23 0.06 0.10 0.19 0.11 0.14 0.33 0.08 0.17 0.17 0.05 0.23 0.38 0.18 0.15 0.03 0.13 0.25 0.38 0.16 0.03 0.06 0.16 0.34 0.21 0.13 0.08 0.08 0.16 0.10 0.35 0.06 0.26 0.06 0.15 0.33 0.11 0.07 0.07 0.26 0.31 0.19 0.12 0.12 0.08 0.19 0.14 0.19 0.22 0.22 0.08 0.14 0.48 0.05 0.19 0.05 0.00 0.24 0.14 0.39 0.03 0.00 0.22 0.22 0.07 0.14 0.43 0.04 0.04 0.29 0.16 0.24 0.32 0.18 0.08 0.03 0.50 0.13 0.13 0.00 0.06 0.19 0.08 0.28 0.32 0.12 0.08 0.12 0.16 0.42 0.16 0.00 0.16 0.11 0.23 0.35 0.15 0.12 0.12 0.04 0.19 0.19 0.03 0.06 0.39 0.13 0.14 0.33 0.14 0.14 0.19 0.05 0.27 0.51 0.03 0.00 0.11 0.08 0.41 0.29 0.18 0.00 0.00 0.12 0.21 0.07 0.43 0.00 0.00 0.29 0.44 0.22 0.11 0.11 0.00 0.11 23
  24. 24. Moose is a platform for software and data analysis Moose is a platform for modeling software artifacts to enable software analysis. Moose 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. 24
  25. 25. ConAn Van Hapax ... CodeCrawler Smalltalk Extensible meta model Java COBOL C++ … Model repository External Parser MSE Navigation Metrics Querying Grouping Smalltalk The key to Moose’s flexibility is its extensible metamodel. Every tool that builds on Moose is able to extend the metamodel with concepts that it needs, such as history. Nierstrasz et al. The Story of Moose. ESEC/FSE 2005 25
  26. 26. Here are a number of different visualizations developed over the years. System complexity - Clone evolution view Class blueprint - Topic Correlation Matrix - Distribution Map for topics spread over classes in packages Hierarchy Evolution view - Ownership Map 26
  27. 27. Transaction scope in JEE Transactions have to extracted from multiple file types and integrated into a common metamodel. Here we see a Transaction Flow diagram that visualizes the flow between application layers. Start a Transactions Start Transactions InheritTransactions Inherit Transactions No attributes defined No attributes DB accessors Data base accessor Start an unnecessary Starts Unnecessary Transactions Transactions Support Transactions Supports Transactions DB Accessors Staring Data base accessor a Transaction starting a transaction 27
  28. 28. Start a Transactions Start Transactions InheritTransactions Inherit Transactions No attributes defined No attributes DB accessors Data base accessor This tells us which transactions violate architectural constraints Start an unnecessary Starts Unnecessary Transactions Transactions Support Transactions Supports Transactions DB Accessors Staring Data base accessor a Transaction starting a transaction Perin, et al. Recovery and Analysis of Transaction Scope from Scattered Information in Java Enterprise Applications, ICSM 2010 28
  29. 29. Challenges Expressing NFRs in code Architectural monitoring
  30. 30. 4. Evolution
  31. 31. Problems PLs impede, not enable, evolution It’s hard to change a running system
  32. 32. Software inevitably changes … But our programming languages and development tools and methods pretend the world is frozen! Few, if any mechanisms enable change Types, modules, namespaces all assume a frozen, unchanging snapshot of the world 32
  33. 33. Changeboxes Deployed branch merged merged We are used to think of source code evolving, but not running software systems. For long-lived applications, it can be important to migrate the running code without stopping it. Changeboxes were an early prototype of this idea. A changebox-aware system could run multiple versions of the same code simultaneously. Changes 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. The problem is that contexts are not first-class entities, so tools need to be made changebox-aware. Release branch bug fix Development branch Denker, et al. Encapsulating and Exploiting Change with Changeboxes. ICDL 2007 broken refactored merged 33
  34. 34. First-class contexts enable dynamic updates Page Html Page Title Body ... 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. 34
  35. 35. First-class contexts enable dynamic updates Ol bidirectional transformation text con d Method Method aPage … Shared object has one identity but two states Method Method … ActiveContext is research in progress built on top of Pinocchio. When classes change shape in long-lived systems, instances need to be migrated. Instead of requiring the system to reach a quiescent state, the system maintains first-class contexts. Every object can potentially live in multiple contexts where threads are active. Object states are synchronized with the help of bidirectional transformations. We are exploring ways to improve performance by using lazy transformations and garbage collecting unused contexts. Ne ntext w co Page Html Page Title Body ... Wernli, et al. Incremental Dynamic Updates with First-class Contexts. TOOLS Europe 2012 35
  36. 36. Challenges Support for context Assessing the impact of change
  37. 37. Conclusions Gap between models and code Architecture is not in the code Gap between runtime and code Need support for context and change