MODULARITY:aosd•13 Keynote Talk by Prof. Reiss

MODULARITY:aosd•13 Keynote Talk by Prof. Reiss

The keynote talk of MODULARITY:aosd•13 titled with "Motherhood and Apple Pie: Modularity in Modern Applications and Tools to Support It" by Steven P. Reiss http://aosd.net/2013/keynotes.html#Reiss

B0c380d80ff4b3c077aa562309a069e7?s=128

Yoshiki Sato

March 29, 2013
Tweet

Transcript

  1. 1.

    Motherhood and Apple Pie: Modularity in Modern Applications and Tools

    to Support it Steven P. Reiss Brown University 2013年 4月 1日 Page 1
  2. 2.

    Motherhood and Apple Pie 13/04/01 Page 2 Motherhood and apple

    pie :: (US) Principles or values with which few disagree.
  3. 3.

    What is Modularity Modularity is the ability to view everything

    related to a particular concern on one screen 13/04/01 Page 3
  4. 4.

    What is Modularity The division of a system into a

    set of independent modules Where modules Represents a set of related concerns Communicate in a loosely-coupled fashion 13/04/01 Page 4
  5. 6.

    Claim There are many (very) different concerns and attempting to

    be modular for any reasonable subset is not possible. 13/04/01 Page 6
  6. 9.

    Concern The squiggle is sometimes out of place after a

    character is typed 13/04/01 Page 9
  7. 10.

    Character Input •  Update editor buffer(s) •  For the character

    and other effects •  Compile and report errors •  Update underlying AST structure •  Repaint the screen •  Handle layout and reflow •  Handle reformatting 13/04/01 Page 10
  8. 11.

    Character Input 13/04/01 Page 11 Event Dispatch Update Selection Auto

    Indent Repaint Request Document Dispatch Auto Completion Update Other Editors Repaint Text Compute Layout Update Eclipse Eclipse AST Update Update Error Set Eclipse Errors Update Annotations Error Notification Update elements Update Elements
  9. 12.

    Squiggle Code On ProblemsUpdatedEvent •  Lock file { Update Problems

    } Unlock In update AST structure •  { Clear problems } Update tree { Update problems } Update Problems •  Maintain the set of active problems (incremental) •  Remove styles for nonexistent problems •  Add squiggle styles for new/cleared problems When drawing text w/ squiggle style •  Use squiggle paint to underline text 13/04/01 Page 12
  10. 14.

    Is This Modularity? The code is modular ? The dynamics

    of the code are not Which is more important? 13/04/01 Page 14
  11. 15.

    Modular View for Squiggle Source Code for relevant routines • 

    The code marked in red View of what happened at run time •  Where is succeeded •  Where it failed 13/04/01 Page 15
  12. 16.

    Obstructions to Modularity Black box code (Swing, Eclipse) Separate interacting

    processes Unknown control flow •  Multiple threads running at once •  Callback orders Our issues are dynamic •  We want modularity to reflect the dynamics 13/04/01 Page 16
  13. 18.

    Smart Sign Code 13/04/01 Page 18 Controller Picture Frame (?)

    Calendar Checker Arduino (C) Bluetooth (C) Arduino Monitor Event Adder Events (Data) Sign Creator
  14. 19.

    Is this Modular? In terms of code? Adding new events

    (NOTIN) was easy Adding calendar was so-so Adding a new sensor is messy 13/04/01 Page 19
  15. 20.

    Obstructions to Modularity Externally imposed modularity •  Multiple languages • 

    Multiple processes •  Multiple machines •  External code (calendar, obexftp, hcitool) Part of the program is data •  Passed between applications •  Representing the rule set 13/04/01 Page 20
  16. 23.

    Twitter Data Access 13/04/01 Page 23 Streamer Data Insertion Zip/District

    Encoder Web Server HTML Script CSS Data Database Twitter
  17. 25.

    Obstructions to Modularity Multiple programs Messages (data) are part of

    the system Database is a system component Web application has its own constraints •  Front end: HTML, JavaScript, CSS •  Back end: JavaScript (Node.JS) •  Communication (json via web sockets) 13/04/01 Page 25
  18. 29.

    Transforms Are Modular Easy to write •  Average 300 lines

    each (135-941) Independent •  Automatic configuration •  Automatic application/detection •  Adding a new transform is trivial 13/04/01 Page 29
  19. 31.

    Process Modularity We need heuristics to guide transforms •  While

    keeping transforms simple to write •  While keeping transforms independent •  While keeping it easy to add transforms We must modularize transform dynamics •  As well as their coding 13/04/01 Page 31
  20. 32.

    Obstructions to Modularity Transformation dynamics not explicit •  Encoded in

    individual transforms Heuristics are spread throughout •  Difficult to get a modular view •  Difficult to understand what is going on Conflicting modularity concerns 13/04/01 Page 32
  21. 34.

    What Have We Learned Modularity is in the eye of

    the beholder 13/04/01 Page 34
  22. 38.

    Multiple View Systems Modularity can be a function of the

    view rather than the code itself We can view a system in different modular ways 13/04/01 Page 38
  23. 43.

    Multiple View Systems •  Scott Myers: SPG-based representation •  CMU

    Sheets •  IBM Visual Age •  Grundy’s & Hosking’s Mviews •  Hon’s Fluid AOP •  Taivalsaari’s Multidimensional Browsing •  Microsoft’s Intentional Programming •  … 13/04/01 Page 43
  24. 44.

    These Don’t (and Won’t) Work Database View-Update Problem •  View

    updates are ambiguous in general •  No single representation supports all views Program View-Update Problem is worse •  More complex semantics •  More complex representations 13/04/01 Page 44
  25. 45.

    Multiple View Systems Severely restrict allowed editable views •  Predetermined

    set, strong restrictions Explicitly define editing operations •  Making view creation prohibitive Use read-only views •  Limiting their uses and applicability 13/04/01 Page 45
  26. 46.

    Virtual Modularity Construct a virtual view by displaying the subset

    of the original source relevant to a particular concern 13/04/01 Page 46
  27. 48.

    Code Bubbles Modularity Code Bubbles Working Sets •  Are static

    modular views of a system •  That can be build dynamically Modularization Techniques •  Show individual functions or components •  Use elision within the components •  Include all types of software artifacts •  Allow save/restore of working sets 13/04/01 Page 48
  28. 50.

    Challenges Paper titles for Modularity 201x •  Automatic creation of

    modular views •  Dynamic modularity •  Programmer-specified editable modular views •  Static views of a program’s dynamic behavior •  Behavioral modularity •  Dynamic modularity across threads •  Modular views of a multilingual web application •  Automatic creation of dynamic modular views 13/04/01 Page 50
  29. 52.

    What is Modularity? •  Modularity refers to the compartmentalization and

    inter-relation of the parts of a software package •  Modularity is designing a system that is divided into a set of functional units (named modules) that can be composed into a larger application. A module represents a set of related concerns. It can include a collection of related components, such as features, views, or business logic, and pieces of infrastructure, such as services for logging or authenticating users. Modules are independent of one another but can communicate with each other in a loosely coupled fashion. •  The use of individually distinct functional units, as in assembling an electronic or mechanical system. •  Modularity is a general systems concept, typically defined as a continuum describing the degree to which a system's components may be separated and recombined. •  Modularity is the property of computer programs that measures the extent to which they have been composed out of separate parts called modules. 13/04/01 Page 52
  30. 53.

    Defining Modularity •  What is a module? •  Source code,

    documentation, design notes, requirements, … •  What is a concern? •  Whatever we need to look at •  For coding, debugging, understanding, … 13/04/01 Page 53
  31. 54.

    Measuring Modularity •  Various measures of metrics for dependencies and

    relationships •  How much work to add, modify, or understand a concern •  Can you fit the code for one concern on one screen 13/04/01 Page 54
  32. 55.

    S6 Input Flow 13/04/01 Page 55 SVIWEB (GWT) Firewall XML

    Engine Request Servlet Test Builder Ant Script Test Prototype File Tester Output Generator Solution Set
  33. 56.

    Problem •  Adding a new input test feature •  Contracts,

    security constraints •  Requires Changing •  GWT code, XML, Servlet code, Request structure, Engine, Test builder, test prototype, Ant script 13/04/01 Page 56
  34. 57.

    Difficulties •  Modularity constrained by system •  Separate programs are

    needed •  Communications protocols are part of code •  Multiple languages •  Including non-languages (ant) •  Including data languages 13/04/01 Page 57
  35. 59.

    Solutions Modularity can be a function of the view rather

    than the code itself? 13/04/01 Page 59
  36. 61.

    Dynamic Software Visualization Visualization for Program Understanding •  Needs to

    be done in the programmer’s terms •  Needs to be done using proper abstractions Requires dynamic modular views 13/04/01 Page 61
  37. 67.

    Dynamic Visualizations Generic tools only solve generic problems •  They

    don’t solve specific problems •  Generic views aren’t modular 13/04/01 Page 67
  38. 71.

    Why This Doesn’t Work The set of thread states is

    not intuitive nor is the set of events. The whole process is too complex. 13/04/01 Page 71
  39. 72.

    Automating the Process Can we build these models automatically • 

    In general? For particular classes of problems •  Threads, Tasks, and Transactions 13/04/01 Page 72
  40. 73.

    Threads, Tasks, Transactions Automatically •  Find event handlers •  Find

    significant subtasks •  Find Threads and tasks •  Find Thread Queues •  Based on programmer’s problem definition Provide customized time-based views 13/04/01 Page 73