Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Domain-Specific Development Tools


Published on

Although software development entails many activities closely intertwined with the domain of the system under development, present-day IDEs offer mostly generic features targeting programming in general. In this talk we look at three different ways in which software development can be tailored to be more domain-specific, and thus, more effective.

First, we consider "agile tooling" -- how to rapidly create or adapt development tools to suit a given application domain; next, we consider "agile modeling" -- how to rapidly model complex and heterogeneous software with the help of a new approach to robust parsing; finally, we look at "architectural monitoring" by showing how a unified domain-specific architectural modeling language can serve as a front-end to a range of different kinds of architectural constraints and checking tools.

These activities are part of "Agile Software Assessment", a research project funded by the Swiss NSF.

This talk was given at INRIA Rennes in Dec. 2015.
It is a refresh of the Domain-Specific Tooling presentation given at INRIA Lille the year before.

Published in: Software
  • The food we eat - Sotry book for Baby, Tots and Preschool kids with emphasis on speech therapy and Child Development. ---
    Are you sure you want to  Yes  No
    Your message goes here
  • The Consultant's Big Book of Organization Development Tools : 50 Reproducible Intervention Tools to Help Solve Your Clients' Problems ---
    Are you sure you want to  Yes  No
    Your message goes here
  • Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum ---
    Are you sure you want to  Yes  No
    Your message goes here

Domain-Specific Development Tools

  1. 1. Oscar Nierstrasz Software Composition Group Rennes — 2015-12-03 Domain-Specific Development Tools
  2. 2. 2
  3. 3. 3 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.
  4. 4. Roadmap Agile Modeling Moldable Tools Architectural Monitoring
  5. 5. Moldable Tools
  6. 6. 6 Build a new assessment tool in ten minutes Challenge Custom analyses require custom tools. Building a tool should be as easy as writing a query in SQL or a form-based interface.
  7. 7. 7 Conventional debuggers just offer an interface to the run-time stack.
  8. 8. 8 Specific Models Mind the abstraction gap Generic Debugger Domain-specific Debuggers The Moldable Debugger Debugging Widget Debugging Action * Activation Predicate Andrei Chis et al. The Moldable Debugger: A Framework for Developing Domain-Specific Debuggers. SLE 2014. DOI: 10.1007/978-3-319-11245-9_6 Classical development tools like browsers, debuggers and inspectors are generic and do not address the needs of specific domains. The Moldable debugger can be easily adapted to different domains, such as event-driven computation, GUI construction and parser generation. Moldable Tools
  9. 9. PetitParser identifier letter , (letter / digit) * letter * , / letter digitPetitParser is a PEG-based framework for developing parsers composed of objects.
  10. 10. 10 IdentifierParser new parse: 'aLong32Identifier'
  11. 11. 11 The conventional debugger knows nothing about the parsing domain.
  12. 12. 12 A moldable PP debugger knows which objects are parsers, knows where we are in the input, and can show us which parser object is currently active.
  13. 13. Domain specific-extensions Debugging Widget Debugging View Debugging Action Debugging Session Debugging Predicate Primitive Predicate HighLevel Predicate ** * Activation Predicate Moldable debuggers are built up from debugging widgets and debugging actions. The moldable debugger uses activation predicates to know which debuggers can currently be activated, allowing the developer to switch between debuggers without starting a new session.
  14. 14. Next production Next parser Production(aproduction) Next failure Stream position(anInteger) Stream position changed 14 Debugging widgets Debugging actions The parts from which the PP debugger is built.
  15. 15. Petit Parser Events SUnit Glamour 15 Moldable debuggers have been built for several different domains already.
  16. 16. New debuggers are cheap Although some expertise is required to build a new debugger, the development effort for a new debugger is tiny.
  17. 17. The Moldable Inspector The moldable inspector extends these ideas to object inspectors. Here is a moldable inspector for PostGres databases. We are exploring other kinds of moldable tools …
  18. 18. 18 Demo
  19. 19. Agile Modeling
  20. 20. 20 Smalltalk Navigation Metrics Querying Grouping Smalltalk Java C++ Python … Extensible meta model Model repository Moose is a powerful tool once we have a model … Roassal Orion DSM ...BugMap Nierstrasz et al. The Story of Moose. ESEC/FSE 2005. DOI: 10.1145/1095430.1081707 Moose is a platform for software and data analysis, but the bottleneck is the development of importers for different languages to the FAMIX metamodel. Development can take weeks or months.
  21. 21. 21 Load the model in the morning, analyze it in the afternoon Challenge The key bottleneck to assessment is creating a suitable model for analysis. If a tool does not already exist, it can take days, weeks or months to parse source files and generate models.
  22. 22. Ideas Grammar Stealing Hooking into an existing tool this phase will be a model of the Ruby software system. As the meta-model FAME compliant, also the model will be. Information about the ClassLoader, instance responsible for loading Java classes, is covered in section 4.7. The Fame framework automatically extracts a model from an instance of an ipse AST. This instance corresponds to the instance of the Ruby plugin AST resenting the software system. Automation is possible due to the fact that defined the higher level mapping. Figure 2.1 reveals the need for the higher pping to be restored. In order to implement the next phase independently m the environment used in this phase we extracted the model into an MSE . ure 2.1: The dotted lines correspond to the extraction of a (meta-)model. e other arrows between the model and the software system hierarchy show ich Java tower level corresponds to which meta-model tower element. 3 Model Mapping by Example phase r previously extracted model still contains platform dependent information d thus is not a domain specific model for reverse engineering. It could be d by very specific or very generic reverse engineering tools, as it contains concrete syntax tree of the software system only. However such tools do exist. In the Model Mapping by Example phase we want to transform the del into a FAMIX compliant one. With such a format it will be easier to use several software engineering tools. The idea behind this approach relies on Parsing by Example [3]. Parsing Example presents a semi-automatic way of mapping source code to domain 9 Recycling Trees Parsing by Example Evolutionary Grammar Generation The final part is reproduction, i.e. to generate a new generation from the surviving pre- vious generation. For that purpose an evolutionary algorithm usually uses two types of genetic operators: point mutation and crossover (We will refer to point mutations as mutations, although crossover is technically also a mutation). Mutations change an individual in a random location to alter it slightly, thus generating new information. Crossover1 however, takes at least two individuals and cuts out part of one of them, to put it in the other individual(s). By only moving around information, Crossover does not introduce new information. Be aware that every modification of an individual has to result in a new individual that is valid. Validity is very dependent on the search space - it generally means that fitness function as well as the genetic operators should be applicable to a valid individual. A schematic view is shown in fig. 3.1. generate new random population select most fit individuals generate new population with genetic operators fit enough? mutation crossover Figure 3.1: Principles of an Evolutionary Algorithm There are alternatives to rejecting a certain number of badly performing individuals per generation. To compute the new generation, one can generate new individuals from all individuals of the old generation. This would not result in an improvement since the selection is completely random. Hence the parent individuals are selected 1Crossover in biology is the process of two parental chromosomes exchanging parts of genes in the meiosis (cell division for reproduction cells) 22 Grammar Stealing was introduced by Verhoef and Lämmel. The other approaches we have tried, but they all have limitations …
  23. 23. 23 Agile Modeling Lifecycle Build a coarse model Build a custom analysis Refine the model We don’t need a full parser; just enough to start analysis. Then we can refine the model to extract more details.
  24. 24. 24 Idea: use island grammars to extract coarse models 'class' ID (method / . {avoid})* 'end' method? method . {avoid} class Shape int x; int y; method draw() … end end method main() … end Island grammars allow us to extract just parts of the information from source code that interest us at the moment.
  25. 25. 25 Problem: island grammars lead to shipwrecks class Shape method end 'class' ID (method / !'end' !method)* 'end' method? Tweaking island grammars till they work is not an option … Unfortunately island grammars are very difficult to get right because the rules for water depend on the islands. If the islands of interest change, the water must change too.
  26. 26. 26 A Bounded Sea searches for an island in a bounded scope 'class' ID (~method~)* 'end' method? ~method~ method ~method~ Bounded seas essentially eliminate the need to write special rules for water, since the boundaries are inferred from the islands. We are now starting to explore how well this works for real languages … Jan Kurš, et al. Bounded Seas. Computer Languages, Systems & Structures 44, 2015. DOI: 10.1016/
  27. 27. 27 Further experiments … Keyword heuristics Exploit structure Classify languages
  28. 28. Architectural Monitoring
  29. 29. 29 Challenge “What will my code change impact?” Large software systems are so complex that one can never be sure until integration whether certain changes can have catastrophic effects at a distance. Ideas: Tracking Software Architecture; exploiting Big Software Data
  30. 30. 30 Problems Diverse views of SA SA is not in the code
  31. 31. What is SA in the Wild? Andrea Caracciolo, et al. How Do Software Architects Specify and Validate Quality Requirements? Software Architecture 2014. DOI: 10.1007/978-3-319-09970-5_32 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. 31
  32. 32. 32 Impact of SA constraints 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 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.
  33. 33. Automated Validation is not Prevalent naming conventions file location hardware infrastructure software update recoverability dependencies signature software infrastructure data structure event handling availability communication accessibility meta-annotation code quality visual design data integrity authentication data retention policy response-time throughput authorization 0% 25% 50% 75% 100% Avg: 40% As we see, on average, QRs are automatically tested only 40% of the time.
  34. 34. Formalization is not Prevalent software update hardware infrastructure accessibility recoverability software infrastructure authentication data retention policy throughput response-time availability file location code metrics visual design communication data integrity authorization event handling naming conventions meta-annotation data structure signature dependencies 0% 25% 50% 75% 100% Avg: 20% ER, UML + profile Regex, BNF annotations … On average QRs are formally specified only 20 % of the time. Practitioners use different formalisms: from UML+profile to regex
  35. 35. Architectural Rules “Repository interfaces can only declare methods named find..()” “Only Service classes are allowed to throw AppException” “The rendering operation has to be completed in less than 4ms” Naming Conventions Dependencies Performance AC: “One year ago I had the chance to talk to various professionals working in the area where I study. What I noticed was that part of an architectural specification consists of constraints and guidelines on how a system should behave and be implemented” 35
  36. 36. Rule Validation xml java uml Limited functionality Poor usability What we typically do is to test these rules using the most appropriate tool. 36
  37. 37. Dicto — a unified ADSL Andrea Caracciolo, et al. Dicto: A Unified DSL for Testing Architectural Rules. ECSAW '14. DOI: 10.1145/2642803.2642824 We have a single unified spec. language which can be used to define a wide range of rules and can exploit off-the-shelf tools for verifying them. We call this language Dicto. 37
  38. 38. Dicto Rules … MyService : Website with url=“” MyService must HandleLoadFrom("10 users") MyService cannot HaveResponseTimeLessThan(“1000 ms") MyService can only HandleSOAPMessages() … DICTO looks like this. Two types of statements: 1. entity definition: used to identify concrete elements of the system 2. rules: express the condition that we want to test through one of the supported tools 38
  39. 39. Rule Examples Website response time Website load testing Dependencies Code clones Deadlock freeness File Content grep At the moment we have a working implementation that supports these kinds of rules … 39
  40. 40. Evaluation 40 Medium size company various - Java EE / .NET
 100 employees Open source project LMS - PHP (1.8M LOC)
 12 service providers, 900’000+ users Large size company B2B - Java EE (50K LOC)
 1’000 employees 40
  41. 41. Conclusion Current IDEs offer developers only primitive support for software assessment Developers need support for moldable tools, agile modeling, and architectural monitoring