OOPSLA 2003 DSM Workshop Diagram Definition Facilities Based on Metamodel Mappings Edgars Celms, Audris Kalnins, Lelde Lace University of Latvia, IMCS, Riga, Latvia

OOPSLA 2003 DSM Workshop Business Modeling as DSM The presented approach offers an efficient solution to this problem. The approach has been tested practically in the Generic Modeling Tool (University of Latvia, Exigen) business process modeling - an unstable area with lot of competing notations having quite similar semantics (UML Activity diagrams one of them) generic modeling approach well fit for the area specific requirements: graphical notations must be easily modifiable necessity to represent the same domain concepts via several graphic notations simultaneously

OOPSLA 2003 DSM Workshop Metamodel structure Domain package for Activities (part of UML metamodel): Diagram core (directed graph): Presentation package for Activity Diagrams: = “Domain diagram” There may be several presentation packages for the same domain package – alternative notations Metamodel is split into domain package (typically determined by domain standards) and presentation package (graphical syntax)

OOPSLA 2003 DSM Workshop General Principles of Mapping Scaffolding principle (relates new mapping to the existing one): Context A inv: BforA->notEmpty() implies owner.BCforAC = BforA.owner Context B inv: AforB->notEmpty() implies owner.ACforBC = AforB.owner Context AContainer inv: contents -> forAll (a | a.BforA->notEmpty() ) and BCforAC->notEmpty() and BCforAC.contents -> forAll (b | b.AforB->notEmpty() ) Local completeness: Correctness rules: Generic mapping: Classes in presentation package are mapped to domain package

OOPSLA 2003 DSM Workshop Simple Mapping Types Diagram mapping (type D): Mapping schema for the type 1OT – symbol to one domain class. Symbol mapping relies on diagram mapping (using scaffolding principle): Mapping for Activity symbol – actually the type is 1OTD (domain element with definition): Mappings have types defined by schemas. There is a type library.

OOPSLA 2003 DSM Workshop Mapping for Diagram Lines Context Line inv: start=mappedLine.source.symbol and end= mappedLine.target.symbol Mapping schema for the type L1OT – line to a class in domain. It is based on mappings for diagram and symbols. Additional constraint is required for this type: L1OT Mapping for control flows in activity diagrams: In fact, all mappings for activity diagram are shown here

OOPSLA 2003 DSM Workshop How it works in practice Steps to define a diagram: build the metamodel – domain and presentation packages for each presentation element find domain element(s) to which it maps (first diagram, then symbols, then lines) add mapping associations to the metamodel select the appropriate mapping type from the library (from ~20) specify mapping details using the Definition tool in GMT, i.e., which metamodel elements actually correspond to the mapping schema for lines, specify end symbol types and multiplicities (at presentation level) define via Definition tool how symbol and line texts (compartments) map to attributes of domain classes (one or more) if necessary, add necessary explicit OCL constraints define style, icons etc. for presentation elements

OOPSLA 2003 DSM Workshop Alternative Diagrammatic Representations provide several presentation packages per domain package – one for each diagram type define the mapping for each then the domain data can be modified through any of the diagram views - others are updated automatically the inverse mapping (consolidation) from domain to presentation is defined, to a significant degree automatically possible variations in representation: what is a symbol in one diagram may be line in another (or box nesting) one presentation class may map to several domain classes and vice versa but the domain must support all representations anyway the correspondence between representations must be “local”

OOPSLA 2003 DSM Workshop Alternative Mapping – ARIS eEPC L1LT - one more type of mapping - line corresponds to a specified domain association from a given class (pointed to by startMap) Part of ARIS eEPC (process) diagram mapped to the same Activity domain EventSymbol maps to the ControlFlow domain class (which was represented by line in Activity diagram)

OOPSLA 2003 DSM Workshop Alternative Mappings in Action Activity diagram fragment: Equivalent eEPC diagram:

OOPSLA 2003 DSM Workshop Simple application to MDA area Class and Data Model diagram on a common domain - for round-trip engineering

OOPSLA 2003 DSM Workshop Future Research - real MDA mappings and scaffolding principle may be used to define transformations between arbitrary metamodels - the proper QVT task arbitrary mappings can be defined as a set of ordered mapping rules a metamodel transformation language based on scaffolding principle currently under construction