Partial Domain Specific Models

1
Partial Domain Specific Models

• Jos Warmer Ordina
• Anneke Kleppe University of Twente

OOPSLA Workshop on Domain Specific Modeling,
22-10-2006
2
SMART-Microsoft Architecture
Users
Presentation layer
Utilities
User Interface components
Security
Operational Management
Communication
Ordina DSL Specific Frameworks
Ordina Core Framework
Data contract
User Processes
DTO
Business layer
View DTO
Service Interfaces
Business Workflows
Business Processes
Service Agents
Business Classes
Data layer
Data Access Logic Components
Data Service Agents
Data sources
Services
3
SMART-Microsoft DSL Overview
4
SMART-Microsoft DSLs
Generiek Framework
DSL Specifiek Framework
lt_at_Page /gt ltHTMLgt ltBODYgt Hello
World lt/BODYgt lt/HTMLgt
Class MyClass public string Hello()
return Hello world
DSL Specifiek Framework
Class MyClass public string Hello()
return Hello world
DSL Specifiek Framework
Class MyClass public string Hello()
return Hello world
ltMappinggt ltClassgt ltTablegt lt/Mappinggt
CREATE TABLE MyTable FIELD1 int FIELD2 varchar(50)
5
Problems with UML

• UML is a huge languag e
• 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

6
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

7
Small Models

• Multiple independent DSLs
• Multiple independent models per DSL

8
References Between Models

• References always by name

9
Extension to DSL Tools

• Support for
• code generation
• Cross model validation
• Intellisense in DSL
• Propagation of model changes

Ordina NDIP
Ordina Web Scenario Designer
Ordina DTO Designer
Ordina Service Designer
Ordina Class Model Designer
Output
Output
Output
Output
10
Maintaining References

• When referred element changes, what to do
• Do nothing
• Give warnings
• Automatically propagate changes
• Use explicit refactoring

11
DSLs

• 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 DSLs for different areas
• Many small models with references between them
• Model is the unit of version control, multiuser
  access, etc.

12
DSLs Future
13
How many levels are useful ?

• Extenstion both horizontal (WPF) and vertical
  (BOM)

Higher level DSL model
Higher level DSL model
Higher level DSL model
Higher level DSL model
Higher level DSL model
Low level DSL model
Low level DSL model
Low level DSL model
Low level DSL model
Code
Code
Code
Code
Code
Code
Code
Code
Code
Code
Code
14
Partial Models
15
Model Source Code

• 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