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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
satoyoshiki
yuukicammy
eumesy
hpprc
xtalent
satotaichi
.png){kind=avatar}
researchconf
tathi
masakat0
shinyorke
isayan
yuyay
destraynor
jennybc
andyhume
chriscoyier
orderedlist
cassininazir
ammeep
cromwellryan
holman
maggiecrowley
marktimemedia
paigeccino