1 24 october 2004 vancouver, canada the 4th oopsla workshop on domain-specific modeling group...
Post on 04-Jan-2016
213 Views
Preview:
TRANSCRIPT
1
24 October 2004Vancouver, Canada
The 4th OOPSLA Workshop on Domain-Specific Modeling
Group reports
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 2
Working groups
Focus on a specific topic Parallel groups
1. DSM practice2. MDA context3. Tools4. 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
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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 DSME’s• 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– Going beyond boxes and arrows– Going beyond static structure/behavior– Verification and Integration– Development support
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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 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) 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
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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…
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 12
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) 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
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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.
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 19
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)
20
Group 4Transformations
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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
NavDisplayC++
ComputePositionC++
ComputePositionwith Locking
C++
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 22
Factoring Transformation for compilation/interpretation
Advantages of factoring– Reuse/composition of transformations– Modularity– Easier to extend
High-levelModel
CodeModel
Code gen
Domain independent optimization
code optimization
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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 ??
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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
The 4th OOPSLA workshop on Domain-Specific Modeling (DSM’04) 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)
top related