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

OOPSLA 2003 DSM Workshop

Diagram Definition Facilities Based on Metamodel Mappings

Edgars Celms, Audris Kalnins, Lelde LaceUniversity of Latvia, IMCS, Riga, Latvia

[email protected], [email protected], [email protected]


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


Metamodel structure

ControlFlowname:Stringguard:String

Activity

CallBehaviorActionBehaviorname:String

owner

edge

1

*target

incoming 1

*

sourceoutgoing 1

*

owner

action

1

*behavior

* 1

Domain package for Activities(part of UML metamodel):

DiagramCore

ActivityPresentation

ControlFlowLine

Box

ActionSymbol

Line

ActivityDiagram

Diagramoutgoingstart *

1

diagram line 1 *

diagram

symbol 1 *

incoming end * 1

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)


General Principles of Mapping

Presentation class Domain classdomain class

symbol class 1

0..1

mapping association

A B

AContainer BContainerACforBC

BCforAC 0..1

0..1

AforB

BforA 0..1

0..1

owner

contents

1

* contents

owner

*

1Scaffolding 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() ) andBCforAC->notEmpty() and

BCforAC.contents -> forAll (b | b.AforB->notEmpty() )

Local completeness:

Correctness rules:

Generic mapping:

Classes in presentation package are mapped to domain package


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

Symbol DomainElement

DomainDiagramDiagram

diagram

symbol

1

*

owner

element

1

*

diagram

mappedDiagram0..1

0..1

symbol

mappedSymbol0..1

0..1

ActivitySymbol

Activity

Behaviorname:String

ActivityDiagram

CallBehaviorAction

diagram

symbol

1

*

owner

action

1

*

diagram

mappedActivity0..1

0..1

behavior

*

1symbol

mappedAction0..1

0..1

Mapping for Activity symbol – actually the type is 1OTD (domain element with definition):

ActivityDiagram Activitydiagram

mappedActivity0..1

0..1

Mappings have types defined by schemas. There is a type library.


Mapping for Diagram Lines

Context Line inv:start=mappedLine.source.symbol andend= mappedLine.target.symbol

Diagram DomainDiagram

Symbol1 Element1

line

Symbol2 Element2

lineElement

diagramsymbol

1*

diagrammappedDiagram0..1

0..1

symbolmappedSympol0..1

0..1

symbolmappedSympol0..1

0..1

source

outgoing

1

*

target

incoming

1

*

start

outgoing

1

*

end

incoming

1

*

diagram

line

1

* linemappedLine0..1

0..1

owner

element1

1

*

owner

lineElement

1

*

owner

element2

1

*

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

1OTD

D

L1OT

Activity

CallBehaviorActionActionSymbol

ControlFlowLine

ActivityDiagram


diagramsymbol

1*

target

incoming

1

*

source

outgoing

1

*

end

incoming

1

*

start

outgoing

1

*

owner

action

1

*

owner

edge

1

*

diagram

line

1

*

diagrammappedActivity0..1

0..1

symbolmappedAction0..1

0..1

linemappedFlow0..1

0..1


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


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”


Alternative Mapping – ARIS eEPC

D

1OTD

1OT

Diagram Core Activity DomaineEPC Presentation

Diagram

Box

eEPCdiagram Activity

FunctionSymbol

Line

EventSymbol

Behaviorname:String

InEventLine

OutEventLine

CallBehaviorAction

L1LT


L1LT

ediagrammappedActivity0..1

0..1

diagram

symbol

1

*

end

incoming

1

*outgoing

start

*

1

diagram

line

1

*

behavior

*

1owner

action

1

*

source

outgoing

1

*

target

incoming

1

*

owner

edge

1

*

fSymbol

mappedAction

0..1

0..1

event

mappedFlow

0..1

0..1

linestart

startMap

*

1

linestartstartMap*

1

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)


Alternative Mappings in Action

Receive Order

Fill Order Ship Order

Close Order

Order Filled

[order accepted]

[order rejected]

Order shipped

Order accepted Fill Order Order Filled

Ship Order

Order shipped Close Order

Receive Order

Order rejected

Activity diagram fragment:

Equivalent eEPC diagram:


Simple application to MDA areaClass and Data Model diagram on a common domain - for round-trip engineering

D

1OT

L1OT

L1OT

1OT

D

Class diagram

AssociationLine

RelationshipLine

Class symbol

AssociationnamesourceRolesourceMultiplicitytargetRoletargetMultiplicity

Classnamekind=persistent

Packagename

Table

DataModelDiagram

AttributenametypeisPK

classSymbolmappedClass0..1

0..1

mappedAssocrelatLine0..1

0..1

diagram

symbol

1

1..*

start

outgoing

1

*

end

incoming

1

*

owner

class

1

1..*

cdiagrammappedPackage0..1

0..1

owner

attribute

1

1..*assocLinemappedAssoc

0..1

0..1

owner

assoc

1

*

mappedClasstableSymbol0..1

0..1

ddiagrammappedPackage 0..10..1

diagram

symbol

1

1..*

diagram

line

1

*

diagram

line

1

*

source

*

1target1

*PK 0..10..1FK 0..10..1

OrderItemitemNoorderIdproductIdquantity

ProductproductIdnamepricedescription

OrderorderIdcustomerdate

order

items1

1..* product

*

1

OrderItemPK:itemNo

orderIdproductIdquantity

OrderPK:orderId

customerdate

ProductPK:productId

namepricedescription

order

items{FK=orderId}

1

1..*

product

{FK=productId}

*

1


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

Documents

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