1 / 12

Diagram Definition Facilities Based o n Metamodel Mappings

Diagram Definition Facilities Based o n Metamodel Mappings. Edgars Celms, Audris Kalnins , Lelde Lace University of Latvia, IMCS, Riga, Latvia Edgars.Celms@mii.lu.lv, Audris.Kalnins@mii.lu.lv, Lelde.Lace@mii.lu.lv. Business Modeling as DSM.

ryann
Télécharger la présentation

Diagram Definition Facilities Based o n Metamodel Mappings

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Diagram Definition Facilities Based on Metamodel Mappings Edgars Celms, Audris Kalnins, Lelde Lace University of Latvia, IMCS, Riga, Latvia Edgars.Celms@mii.lu.lv, Audris.Kalnins@mii.lu.lv, Lelde.Lace@mii.lu.lv OOPSLA 2003 DSM Workshop

  2. Business Modeling as DSM • 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 severalgraphicnotations simultaneously 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) OOPSLA 2003 DSM Workshop

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

  4. General Principles of Mapping Classes in presentation package are mapped to domain package Generic 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 Correctness rules: • Context AContainer inv: • contents -> forAll (a | a.BforA->notEmpty() ) and • BCforAC->notEmpty() and • BCforAC.contents -> forAll (b | b.AforB->notEmpty() ) Local completeness: OOPSLA 2003 DSM Workshop

  5. Simple Mapping Types Mappings have types defined by schemas. There is a type library. 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): OOPSLA 2003 DSM Workshop

  6. Mapping for Diagram Lines 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: Context Line inv: start=mappedLine.source.symbol and end= mappedLine.target.symbol L1OT Mapping for control flows in activity diagrams: In fact, all mappings for activity diagram are shown here OOPSLA 2003 DSM Workshop

  7. 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

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

  9. Alternative Mapping – ARIS eEPC 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) L1LT - one more type of mapping - line corresponds to a specified domain association from a given class (pointed to by startMap) OOPSLA 2003 DSM Workshop

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

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

  12. 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 OOPSLA 2003 DSM Workshop

More Related