1. 1 Partial Domain Specific Models Jos WarmerOrdina Anneke KleppeUniversity of Twente OOPSLA Workshop on Domain Specific Modeling, 22-10-2006

2. OOPSLA Worskop on Domain Specifoc Modeling 2006 2 SMART-Microsoft Architecture Data sources Services Presentation layer Business layer Data layer Utilities Users User Interface components User Processes Service Interfaces Business WorkflowsBusiness Processes Data Access Logic Components Service Agents SecurityOperational ManagementCommunication Data Service Agents Business Classes Data contract DTO View DTO Ordina DSL Specific FrameworksOrdina Core Framework

3. OOPSLA Worskop on Domain Specifoc Modeling 2006 3 SMART-Microsoft DSL Overview

4. OOPSLA Worskop on Domain Specifoc Modeling 20064 SMART-Microsoft DSL’s Generiek Framework Class MyClass { public string Hello() { return “Hello world”; } Hello World Class MyClass { public string Hello() { return “Hello world”; } Class MyClass { public string Hello() { return “Hello world”; } CREATE TABLE MyTable FIELD1 int FIELD2 varchar(50) DSL Specifiek Framework DSL Specifiek Framework DSL Specifiek Framework

5. OOPSLA Worskop on Domain Specifoc Modeling 2006 Problems with UML  UML is a huge language UML as-is is not useable, need profiles Creating UML profiles is complex (i.e. needs to understand the UML2 metamodel  ) “Configuring” UML tools to validate the profiles is complex Code generation is complex UML modeling tools do not scale up easily Multi user modeling is horrifying Version control is complex Developers need to use two different tools with export /import 5

6. OOPSLA Worskop on Domain Specifoc Modeling 2006 PoC with Microsoft DSL Tools  Positive Stability very good Usability for the modeler good Good integration with VS2005 gives seamless developer experience Open environment, e.g. validation framework, VS2005 SDK  Problems No support for large models No support for references between models No support for views No repository 6

7. OOPSLA Worskop on Domain Specifoc Modeling 2006 Small Models  Multiple ‘independent’ DSL’s  Multiple ‘independent’ models per DSL 7

8. OOPSLA Worskop on Domain Specifoc Modeling 2006 8 References Between Models  References always by name

9. OOPSLA Worskop on Domain Specifoc Modeling 20069 Extension to DSL Tools Ordina Web Scenario Designer Ordina DTO Designer Ordina Service Designer Ordina Class Model Designer Ordina NDIP Output Support for code generation Cross model validation Intellisense in DSL Propagation of model changes

10. OOPSLA Worskop on Domain Specifoc Modeling 2006 Maintaining References 10  When referred element changes, what to do: Do nothing Give warnings Automatically propagate changes Use explicit refactoring

11. OOPSLA Worskop on Domain Specifoc Modeling 200611 DSL’s  Characteristics of our Domain Specific Models Everything in a model is used for code generation Not just documentation, same status as source code Modeling must be less work than coding Models are useable by Models must be extended by handwritten code Models are leading: never touch the generated code Handwritten extensions through defined extension points  Specific models for each area Many different DSL’s for different areas Many small models with references between them Model is the unit of version control, multiuser access, etc.

12. 12 DSL’s Future

13. OOPSLA Worskop on Domain Specifoc Modeling 2006 How many levels are useful ? 13 Low level DSL model Code Higher level DSL model Code Higher level DSL model  Extenstion both horizontal (WPF) and vertical (BOM)

14. OOPSLA Worskop on Domain Specifoc Modeling 2006 Partial Models 14

15. OOPSLA Worskop on Domain Specifoc Modeling 2006  View DSM as Source Code File A DSM is the unit of multi-user access A DSM is the unit of version control References by name only Refactoring like source code DSM is unit of reuse DSM is source for nightly builds The DSM is always leading Code generation per DSM Re-use per model Project tasks per model 15 Model ≈ Source Code