24 October 2004

1
The 4th OOPSLA Workshop on Domain-Specific
ModelingGroup reports

• 24 October 2004
• Vancouver, Canada

2
Working groups

• Focus on a specific topic
• Parallel groups
• 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

3
Group 1DSM Practice Group
4
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
• What has been done
• 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 DSMEs
• Few language designers and many framework/library
  developers
• Collect "hot topics" in DSMs
• Language evolution and transformations
• Defining the language development and evolution
  characteristics
• Language Testing and Debugging
• Future research topics

5
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)

6
Group 2DSM with MDA
7
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

8
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
  doesnt 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

9
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

10
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

11
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

12
Constraints (continued)

• So, how to represent constraints?
• Fix OCL
• Better syntax?
• Extension
• Functional programs?
• Other constraint languages
• Alloy
• Domain-specific constraint languages?

13
UML

• UML is a one-size-fits-all approach
• Popular in industry
• Off the shelf solutions less intimidating than
  Domain-Specific 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

14
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

15
When to change the metamodel (DSM) instead of
extend UML?

• When to re-use UML/MOF or create a new
  meta-model? (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

16
Group 3DSM Tools
17
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.

18
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

19
Group 3 Tools

• Versioning
• Source safe
• Metamodel evolution
• Versioning required
• Graph transformations model based on MM1 lt-gt
  model based on MM2
• A detailed classification of changes permitted to
  the metamodel is needed (e.g., additional
  attribute not a problem)

20
Group 4Transformations
21
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
• Vertical translation
• Translation, or synthesis, between layers of
  abstraction
• E.g., MIC interpreters, reverse engineering
• Transformation (specification)
• Automatic
• Manual
• Semi (a bit of both)
• Transformation (by artifact)
• Abstract Syntax/ Concrete/ Semantics

ComputePositionC
ComputePositionwith LockingC
NavDisplayC
22
Factoring Transformation for compilation/interpret
ation
Domain independent optimization
High-levelModel
Code gen

• Advantages of factoring
• Reuse/composition of transformations
• Modularity
• Easier to extend

CodeModel
code optimization
23
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 ??

24
Future Directions of Meta-Modeling with
Transformations

• Goal powerful modeling language that allows both
  modeling and meta-modeling
• Generation of models from specifications
• Composition of models under correctness-preserving
  conditions

25
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)