1 / 16

Framework for Domain - Specific Visual Languages

Framework for Domain - Specific Visual Languages. http://www.isis.vanderbilt.edu/oopsla2k1/ Juha-Pekka Tolvanen, Steven Kelly, Jeff Gray, Kalle Lyytinen. Modelling in domain terms vs. modelling your code. Map to code, implement. Assembler. Map to code, implement. Code.

knox
Télécharger la présentation

Framework for Domain - Specific Visual Languages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Frameworkfor Domain-Specific Visual Languages http://www.isis.vanderbilt.edu/oopsla2k1/ Juha-Pekka Tolvanen, Steven Kelly, Jeff Gray, Kalle Lyytinen

  2. Modelling in domain terms vs. modelling your code Map to code, implement Assembler Map to code, implement Code Generate,Add bodies Map to UML UML Model No map! Generate callsto components DSVLModel Components DomainIdea FinishedProduct Solve problem in domain terms

  3. Converging research areas • Methods, CASE, metaCASE • 50% use no method, 25% standard method, 25% customised • Visual Programming Languages • Domain-specific approaches • Textual DSL, Visual DSVL • Product family engineering • Code generation • Generative & template programming • Models to code: mostly structural, behaviour from state charts • Components • Raise level of abstraction • Reuse by reference, not copy and paste

  4. Main benefits of DSVLs • Fundamental productivity improvements (3-10 times) • Shorter intervals: Fast • Lower costs: Cheap • Better quality: Good • Faster change responsiveness • Manage changes in domain instead of code • Allows developers to design products with domain terms • Apply familiar terminology • Solve the RIGHT problems! • Solve problems only ONCE! • Leverage expertise inside the team • Put the expert’s knowledge in a tool • “Hide” domain complexity (DSVL includes domain rules)

  5. DSL Case Study: USAF • Development of message translation and validation system (MTV)* • Declarative domain-specific language • + code generators and customisation of components Compared DSL against component-based development: • DSL is 3 times fasterthan code components • DSL leads to fewer errors: about 50% less • DSL gives “superior flexibility in handling a greater range of specifications” than components * Kieburtz et al., A Software Engineering Experiment in Software Component Generation, ICSE, 1996

  6. DSVL Case Study: Lucent • 5ESS Phone Switch and several DS(V)Ls * • Reported productivity improvements of about 3-10 times • From several cases • From several DSLs • DSVLs out-performed DSLs • Shorter intervals between product releases • Improved consistency across product variants • “DSL should be used always if more than 3 variants” * D. Weiss et al, Software Product-Line Engineering, Addison-Wesley, 1999

  7. DSVL Case Study: Nokia • DSVL and related code generators for mobile phone* • Order of magnitude productivity gains (10x) • "A module that was expected to take 2 weeks... took 1 day from the start of the design to the finished product" • Focus on designs rather than code • Domain-oriented method allows developers to concentrate on the required functionality • Training time was reduced significantly • “Earlier it took 6 months for a new worker to become productive. Now it takes 2 weeks” * MetaCase, Nokia case study, 1999

  8. How to implement a DSVL Done a few times before! Expert (few) DSVL metamodel Code generation Component library DomainIdea FinishedProduct Easy! Generate callsto components DSVLModel Normal (many) Components

  9. Steps for implementing a DSVL Rules Generators 3 4 1 2 Concepts Symbols

  10. 1. Design domain concepts • Map modeling concepts accurately to domain concepts • Concentrate on semantics! • Add extensions for software production later • Reflect to output (e.g. generated code)

  11. 2. Define domain rules • Define semantics and rules as they exist in the domain • Examples of rule types: • Bindings between concepts • Layering abstractions • Reusing rules • etc.

  12. 3. Draw symbols (notation) • Define symbols illustrating as well as possible the corresponding domain concepts’ natural ”visualization” • e.g end-users’ notation, customers’ notation

  13. 4. Implement generators • Cost of developing generators defrayed over a few users • Generate code – and more! • Component use – Configuration data • Code generation – Testing and analysis • Automated build – Reports that make reports • Documentation – Review

  14. Apply in software production • Develop applications using the DSVL infrastructure • Continuously evolve your DSVL • Domain & platforms evolve

  15. Further information: www.metacase.com/dsm.html • Related events: • OOPSLA’01: Workshop on Domain-Specific Visual Languages • HCC’01: IEEE Symposium on Human-Centric Computing Languages and Environments • ECOOP’00: Workshop on Model Engineering • Experience reports: • Honeywell • NASA • Nokia • Pecunet • DuPont • Lucent • USAF

  16. Thank you! Questions or comments? MetaCase Consulting Ylistönmäentie 31 FIN - 40500 Jyväskylä, Finland Phone +358 14 4451 400, Fax +358 14 4451 405 email: jpt|stevek@metacase.com http://www.metacase.com

More Related