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 11/15/2018

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 11/15/2018

Different types of composing and refining sequence diagrams structure time X A B Y X A B Y 11/15/2018

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. 11/15/2018

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. 11/15/2018

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

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

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

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. 11/15/2018

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/15/2018

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 11/15/2018

Three scenarios to be merged 11/15/2018

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. 11/15/2018 The same Fig.4 topologically

11/15/2018

11/15/2018

Example 2: High-level SD 11/15/2018

Example 2: Refinements 11/15/2018

Example 2: Merge 11/15/2018

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. 11/15/2018

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. 11/15/2018

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

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 11/15/2018