Transcript Workshop - DSM Forum

The 4th OOPSLA Workshop on
Domain-Specific Modeling
Group reports
24 October 2004
Vancouver, Canada
1
Working groups
 Focus on a specific topic
 Parallel groups
1.
2.
3.
4.
DSM practice
MDA context
Tools
Transformations
 The goal of those groups is to
–
–
–
–
establish theoretical background
summarise past experience
investigate most interesting approaches
identify future research topics
 Groups present their results for discussion
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
2
Group 1
DSM Practice Group
3
DSM Practice Report


Background and basic assumptions
–
–
–
–
Extreme opposites agree that DSM is useful
Have good knowledge and definition of domain
Target output language is close to the domain
Agreement on abstractions and design flow
–
Share experiences
• Methodology is an ad hoc process
• Coming to a consensus can be difficult
• Measuring quality can be difficult
– Often there is no ”right” answer
Industry state of the art
• Language metamodeling for constructing DSME’s
• Few language designers and many framework/library developers
What has been done
–


Collect "hot topics" in DSMs
–
–
–
Language evolution and transformations
Defining the language development and evolution characteristics
Language Testing and Debugging
–
–
–
–
Going beyond boxes and arrows
Going beyond static structure/behavior
Verification and Integration
Development support
Future research topics
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
4
DSM Practices
 Why and when DSMs are chosen?
–
–
–
–
–
–
Domain complexity reduction
Lack of experts (in both domain and in programming)
Large user/usage base
Reduction of the learning curve
Single model but multiple targets
Legacy code/tool integration
 Organisational issues of DSM introduction
– Achieving a consensus on language design
– Getting management/user feedback and support
– Development time and cost/benefit analysis/justification
• productivity and quality improvements
 Is there some systematic methodological support for DSM
creation
– Over defining vs Under defining of the language
• adding vs pruning
– the ”to be” language vs the ”as is” language
– the development process
• user base (one user vs. thousands)
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
5
Group 2
DSM with MDA
6
Participants







Laurie Tratt, King's College London
Jerome Delatour, ESEO/TRAME
Grant Emanuel, University of North Dakota
Kim Jin, SolutionsIQ
Anna Gerber, DSTC
Robert France, Colorado State University
Andy Evans, Xactium
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
7
MOF:
 Abstract Syntax vs Concrete (graphical
syntax)
 EMOF or CMOF?
 Domain-specific meta-meta models?
 Do we need Meta-Meta models? To some
extent it doesn’t matter what meta-meta
model you use (if you don't believe in the 4
layer modelling hierarchy)
– You can create any meta-model you want
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
8
OCL
Little industry acceptance
OCL 2.0 is a monster - difficult to read and understand
What is the intention of using OCL here?
Specification of constraints is undervalued in industry
(constraints often implicit)
 Difficult to use to communicate with customer
 Constraints specification often not complete




The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
9
Constraints
 What is the role of constraints in meta-modelling?
– Good at capturing pre/post conditions and simple
constraints
– Class Diagram considered as a constraint
• but additional constraints necessary through
languages like OCL (or DSL, or natural language)
 Constraints are not enough
– Meta-model operations underused
• (perhaps because MOF does not specify how
operations are implemented, so they are not often
used)
• One use case: constraint enforcement through
operations
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
10
Constraints (continued)
 Is OCL a good choice?
– Expressive power not a problem
– Syntactic issues: too much effort to express
constraints
– Better tool support needed
– Unclear checking/execution semantics
 so no, not really…
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
11
Constraints (continued)
 So, how to represent constraints?
– Fix OCL
• Better syntax?
• Extension
– Functional programs?
– Other constraint languages:
• Alloy
• Domain-specific constraint languages?
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
12
UML
 UML is a one-size-fits-all approach
 Popular in industry
– Off the shelf solutions less intimidating than DomainSpecific solutions
 Extension Capabilities
– Hack the standard: cut and paste modelling
– UML 1.4 profiles of limited use, have problems
– UML 2.0 profiles based on composition
• Support light-weight extension
• Heavy-weight extension (ie new elements added)
using MOF, but the model is no longer UML
 Not suitable for DSM
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
13
DSM as CIM, PIM or PSM?
 Meaningless as absolute terms - relative
terms/roles only
– Hence DSMs can be PIMs or PSMs, depending on
the role they play in MDA
 CIM is just a type of PIM
 New MDA statement talks about levels of
abstraction instead of PIM/PSM
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
14
When to change the
metamodel (DSM) instead of
extend UML?
 When to re-use UML/MOF or create a new metamodel? (Extension or Instantiation)
– Extend UML if your DSM is very similar to UML (and you
only want to add to it)
– Extending UML provides advantage of being able to use
existing UML tools for visualisation/editing
– Defining a new MOF meta-model avoids issues with
having to ignore/change UML semantics
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
15
Group 3
DSM Tools
16
Group 3: Tools
 Classification:
– A CASE tool that supports a particular language
(instantiation of types defined in a metamodel)
– Tools for building such DS CASE tools
• Programmed from scratch (ad-hoc)
• Using frameworks
• Generate most of a DS CASE tool
• Generate everything for DS CASE tools
• CAME as an iterative process of defining a language
 What else than ”generating” model editors?
– Process models currently not supported. Do process
models make sense?
– Workflow-supported modeling.
– Balance between a creative process and the possibility to
check syntax / semantics.
– Checking every user action is not a good idea.
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
17
Group 3: Tools
 Generators
– Different approaches appropriate for different targets
(XML, Java, documentation)
– Dependent on the model traversal strategy
– Example-based code generation
 How many people should work on a metamodel?
– Just one?
– E.g., a metamodel with 600 element types
– Do XP principles apply to DS Metamodel development
(pair programming, test first, collective model ownership
 Is there a grand universal metametamodel?
– MOF, GOPPRL, MetaGME
– Defining a concrete syntax for a language is difficult in
MOF
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
18
Group 3: Tools
 Versioning
– Source safe
 Metamodel evolution
– Versioning required
– Graph transformations: model based on MM1 <-> model
based on MM2
– A detailed classification of changes permitted to the
metamodel is needed (e.g., additional attribute not a
problem)
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
19
Group 4
Transformations
20
Different-Dimensions of
Transformation/Translation
 Transformation (abstraction)
– Horizontal
• Transformation within the same level of
abstraction
• E.g., Model transformation, code refactoring, tool
integration, optimizations, evolutions
ComputePosition
– Vertical translation
C++
• Translation, or synthesis, between layers of
abstraction
• E.g., MIC interpreters, reverse engineering
ComputePosition
with Locking
C++
 Transformation (specification)
– Automatic
– Manual
– Semi (a bit of both)
 Transformation (by artifact)
– Abstract Syntax/ Concrete/ Semantics
NavDisplay
C++
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
21
Factoring Transformation for
compilation/interpretation
Domain independent optimization
High-level
Model
Code gen
code optimization
Code
Model
 Advantages of factoring
– Reuse/composition of transformations
– Modularity
– Easier to extend
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
22
What is the optimal formalism for
transformations/model compilers?







Pure General Purpose Language
GPL + Abstraction framework (API)
Proprietary scripting language
Graph grammars, transformations
Operational / Natural Semantics
Action Semantics
Other ??
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
23
Future Directions of MetaModeling with Transformations
 Goal: powerful modeling language that allows
both modeling and meta-modeling
 Generation of models from specifications
 Composition of models under correctnesspreserving conditions
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
24
Challenge Question
 In DSM, the metamodel seems to be (in
current practice) the primary artifact for
capturing evolution. How do we
correspondingly evolve all of the other
artifacts (e.g., model compilers, test cases,
instance models)
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04)
25