1 / 18

Do model mappings really map? On derived information in model management

This article explores the concept of model mapping and the handling of derived information in model management. It discusses the use of formal frameworks and the integration of derived elements in mappings, using examples such as model merges and translations. The article also addresses challenges and considerations related to automation, algebraic approaches, basic vs. derived elements, and normalization.

anordman
Download Presentation

Do model mappings really map? On derived information in model management

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. Do model mappings really map? On derived information in model management Zinovy Diskin School of Computing, Queen’s University Kingston, Canada

  2. Q: What is model mapping? Schema mappings are specifications that describe the relationships between schemas at a high level. These specifications are typically given in a logical formalism that captures the interaction between schemas at a logical level without spelling out implementation details relevant to the physical level. - Phokion Kolaitis. Invited Talk at ACM PODS’2005 • Mapping (in the math sense) between models? (early MMt papers, 2000-02) • Relation (math) between models? (2003-current) • Relation (math) between sets of instances of the models? (05-current) • Correspondence between models? • Anything talking about anything in-between models.

  3. Lewis Carroll about the issue: When I use a word,Humpty Dumpty said, in a rather scornful tone,it means just what I choose it to mean, neither more nor less. The question is, said Alice,whether you can make words mean so many different things. The question is, said Humpty Dumpty,which is to be master - that's all. <….> When I make a word do a lot of work like that, said Humpty Dumpty,I always pay it extra.

  4. “Humpty Dumpty” Syndrome Patients: model mapping, model management, association (in UML), semantics, formalization, … Etiology: informal/semi-formal interpretations with some elementary concepts missing. Treatment: build an adequate formal framework, disassemble complex notions into elementary units and accurately re-assemble them again

  5. Modeling: engineering and mathematical Structure of Engineering Models (models and operations/relations over them) M-modeling Structure of Mathematical Models E-modeling Model11 Model12 Model 1 Model13 Reality (say, a bridge) Model 2 Model22 Model21 … … E-mechanics M-mechanics

  6. Back to model mappings Practical situations of correspondence between models often involve derived info: elements of one model correspond to elements that can be derived over another model rather than immediately belong to it. How to model and manage such situation in an intelligent way?

  7. An early attempt to work with derived info(Bernstein, 2003) m1 m1 {name=l-name + f-name} { age= currentYear - b-date.year } The problem is how to compose mappings with annotated expressions

  8. Solution suggested by categorical algebra: • Place operation expressions in models rather than in mappings. In more detail, augment models with required derived elements and consider mappings between models augmented with derived elements (so called Kleisly mappings). • We will consider two examples. One is from model merge and the other is model translation.

  9. Model merge: a generic pattern Corresp. Model, R r1 (e1  f1) r12 (/e14 f12) Model B Model A r2 (/e4 f2) f1 f3 e3 e1 f12 f23 f2 [q] e2 /e14 /e4 Model derQAB Model derQBA e3 r1 /r12 f3 e2 f23 /r2 Model derQBA R derQAB

  10. Meta-schema of merge match matching merge [ join ] merge normalization normalization Color Legend: green means ‘heuristic’, blue means ‘automatic’

  11. Example: extracting ER-diagrams from SQL-tables(simplified)

  12. Model translation (MT): MT-programming (on the left) via PB (pull-back) (right) Source model S; Source metamodel MS; Target metamodel MT; Source model; Metamodel mapping, MTMS Transformation Engine Transformation Spec (rules), PB-algorithm Trace mapping Target model Trace mapping Target model

  13. MT in universal (not elementwise) terms(specification vs. implementation) m*’ T’ u!  ’ m* T S (1) Definition: (T,,m*) = PB(, m)   [ = ] MT MS m (2) Theorem [an elementwise implementation of def(1)] : T = {(e,y) S x MT | e.  = y.m } Th. (2) gives rise to a procedure implementing specification (1)

  14. MT-via-PB: separation of concerns Procedural part Declarative part m* derQS T S [PB] (retyping)   [ algExp] (query exec) Q MS derQMS MT m

  15. Does PB works? Yes, if we use proper (Kleisly) mappings to derived elements.

  16. How essential are derived elements? Relational metamodel augmented with derived elements to interpret ER-metamodel. Semantics of data is hidden in the application code.

  17. Delicate issues to be addressed: • automation (algebra) and heuristics in model management; • does algebra do what we really need? • basic-vs.-derived: a pseudo-conflict between views; • derived information and normalization.

  18. Summary • Kleisly mappings provide a convenient way to handle derived information issues in MMt • They appear quite naturally in model match, merge and translation tasks • They allow us to consider many seemingly different notions of model mapping in a unified and mathematically justified way.

More Related