1 / 22

Scenario Integration via Higher-Order Graphs * )

This talk explores the use of higher-order graphs for integrating data in scenario integration, focusing on the formalization of sequence diagrams and the merging of different scenarios. Delicate issues, future work, and potential applications will also be discussed.

kobrien
Download Presentation

Scenario Integration via Higher-Order Graphs * )

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. Scenario Integration via Higher-Order Graphs *) Zinovy Diskin, Juergen Dingel and Hongzhi Liang School of Computing, Queen’s University Kingston, ON, Canada *)Supported by the Natural Sciences and Engineering Research Council of Canada (NSERC), OCE Centre for Communications and Information Technology (CITO), and IBM Software Lab in Ottawa, Canada the speaker

  2. Data integration: just to give a notion Data set 2 Virtual Integrated Data set Data set 1 Schema 2 Schema 1 map2 map1 map3 Data set 3 Schema 3

  3. Different types of composing and refining sequence diagrams structure time X A B Y X A Y B

  4. Summary of the introduction The general motto: complex scenarios are assembled/composed from simple pieces. There are different composition mechanism, and not all of them are captured by ordinary Interaction Overview Diags. What we need is a general scenario model management mechanism. Our goals: • To formalize syntax of UML2 SeqDiags in a way facilitating their management: -- comprehensible, -- amenable for algebraic manipulations, -- mathematically sound. • To look at how well this formalization could work for scenario integration.

  5. Content of the talk • Generic pattern of model merge • Formalization of Sequence Diagrams • Example of scenario merge (not entirely trivial) • Another example (if we have time) – very simple • Discussion: • some delicate issues in model/scenario merge; • future work; • some speculations.

  6. 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 [q] e2 /r12 f3 f23 /r2 Model derQBA R derQAB

  7. Meta-schema of merge (merge overview diagram): algebra vs. heuristic match matching merge [ join ] merge normalization normalization Color Legend: green means ‘heuristic’, blue means ‘automatic’

  8. 2 1 SD  G2  G1  G0 Formalization of sequence diagrams via graphs:_________________________________ Defining mapping 2 Why higher-order graphs? Graph G2: Event & msg occurrences /::close 2 /close = deal + pay /:close = :deal + :pay s:Seller /live={exec|wait}* 1 Graph G0: Classes and dynamic associations (message types) Graph G1: Objects and dynamic links (occurence types)

  9. Metamodels for higher-order graphs In diagrams (a1.a2,a3), rectangles denote sets and arrows are set mappings. In diagram (b), rectangles are objects (sets, graphs, higher-order graphs) and arrows are their morphisms. Bold/ordinary arrow tails denote, resp., totally/partially defined mappings.

  10. Requirements for merge: a Brokered Sale is a composition of two Sales, called the Wholesale (wSale) and the Retail Sale (rSale), such that the folowing conditions hold: • Both sales deal with the same item:Product. • The buyer of the Wholesale is the seller of the Retail sale, and is called the retailer for the entire Brokered sale interaction. • In general, the retail sale follows after the whole sale but (3.1) the retailer obeys the rule to pay to the whole-seller after getting the payment from the retail buyer, (3.2) in-between the two sales, the retailer needs to perform a special procedure called thinking, and also needs to do some banking.

  11. Merging structural bases /:close=:deal +:pay /:close = :deal + :pay :pay Two collaboration graphs to be integrated Green edges are new elements in the Retailer scenario

  12. Three scenarios to be merged

  13. Topology of scenario merge Legend: stadiums with vertical shading denote interactive behavior (Seq. diags, MSCs or the like) presented by typed graphs; rectangles with horizontal shading are structural bases (collaboration graphs) of the behaviors over them; block grey arrows denote (partially defined) mappings between models (i.e., typed graphs mappings), and grey line arrows are their components showing some details of these mappings; green items in Connector model specify new information not contained in the original models. The same Fig.4 topologically

  14. Example 2: High-level SD

  15. Example 2: Refinements

  16. Example 2: Merge

  17. Delicate issues • automation (algebra) and heuristics in model management; • hidden correspondences between views • does algebra do what we really need? • universal definitions and algebraic algorithms, • semantic meaning of merge? • derived information and normalization.

  18. Future work • Formalization of nested (concurrent) executions for the same agent/object • Adding more type/structure discipline to scenario specifications: • “return” 2-arrows, • …. , • constraints (graphs + constraints = sketches); • Topological pre-merge (tools); • Inconsistency between views. • Partial rather than linear semantics.

  19. Questions to discuss: • How interesting is this sort of scenario composition/management? • Formalization of nested executions over the same object/agent. • Partial order semantics?

  20. References Diskin, Dingel and Liang. Scenario integration via higher-order graphs. Technical Report, 2006-517. School of Computing, Queen’s University, 2006 Diskin. Mathematics of generic specifications for model management. In Encyclopedia of Database Technologies & Applications, Eds. L. Rivero, J. Doorn and V. Ferraggine, Idea Publishing Group, 2005

More Related