195 lines
8.5 KiB
Markdown
195 lines
8.5 KiB
Markdown
file:: [sle23-paper45_1692364245116_0.pdf](../assets/sle23-paper45_1692364245116_0.pdf)
|
||
file-path:: ../assets/sle23-paper45_1692364245116_0.pdf
|
||
|
||
- compare models using programs written in a rule-based model comparison languag
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: green
|
||
id:: 64df791f-c419-4205-86ed-a7ad61e45aad
|
||
- Our experiments demonstrate that the proposed model comparison approach delivers significant performance benefits in terms of execution time compared to the default ECL execution engine
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: purple
|
||
id:: 64df7945-7c06-41b6-9b9a-41a37db96fb0
|
||
- While there is increased adoption of Model-Driven Engineering (MDE) principles, tools and technologies in industry [1], going forward scalability of these tools remains one of the key challenge
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: green
|
||
id:: 64df796a-bf9b-45e0-a886-2a521239f604
|
||
- essential to make MDE tools and technologies scalable
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: green
|
||
id:: 64df7972-80c3-4eda-ab22-0f795de1d9ad
|
||
- Such model comparison can be computationally very expensive because each element of the first model needs to be traversed and compared to a corresponding element of the second model, which does not scale well
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: blue
|
||
id:: 64df79a5-b5f0-4440-b960-b860d9132d39
|
||
- In this paper, we introduce an efficient model comparison approach based on static program analysis and automated program rewriting.
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: purple
|
||
id:: 64df79ad-dbf7-4f3a-a90f-5981648d1e06
|
||
- The output of an ECL program is a match trace that contains all the established results of matches between elements of two models.
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: green
|
||
id:: 64df79f5-fe24-4e26-8179-76d06b73daca
|
||
- Our proposed approach has shown performance gains up to95% in terms of execution time in the experiments we have conducted.
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: purple
|
||
id:: 64df7a01-f3b2-4fa8-b957-2dee106bc18f
|
||
- Model comparison establishes correspondences between matching elements of two models [5].
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: green
|
||
id:: 64df7a6d-2621-4e88-885f-b06a2d3e9661
|
||
- identify matching elements before merging two models.
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: green
|
||
id:: 64df7a8d-2f9e-4198-93e0-04c52150fa03
|
||
- model comparison can be used in order to establish matching elements before calculating the differences between two models
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: yellow
|
||
id:: 64df7a98-9143-4d8c-8876-1e31a9aca768
|
||
hl-stamp:: 1692367514770
|
||
- ECL lets developers specify custom comparison algorithms in a rule-based script to identify matching elements between homogeneous and heterogeneous models.
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: green
|
||
id:: 64df7b3d-c275-4c03-9167-68c0e7794857
|
||
- The default execution engine of ECL will compare each instance of the left parameter (i.e., Lifeline) to all the instances of the right parameter (i.e., Class). The complexity of this rule here would be O(M×N), if there are M number of Lifelines and N number of Classes.
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: yellow
|
||
id:: 64df7dda-65cc-4e85-9f78-00669b2ecb38
|
||
- Classes so there will be 6 matches for the rule Lifeline2Class. In the rule Lifeline2Class, we can filter the Class instances only keeping ones where the name of the class is equal to the type of the Lifeline.
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: green
|
||
id:: 64df8011-ce6c-4df0-8e3a-49981219ddca
|
||
- compare : true
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: yellow
|
||
id:: 64df805a-a292-4387-a930-f9919c2dd942
|
||
- compare : true
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: yellow
|
||
id:: 64df805d-227e-4ee5-b73e-18a69ea0669d
|
||
- compare : true
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: yellow
|
||
id:: 64df8060-46c0-4296-b43f-b885b3ffe819
|
||
- optimise ECL matching programs automatically using program analysis
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: green
|
||
id:: 64df8108-5c9d-42a1-a914-0dbf6286f4d1
|
||
- This is because we do not compare all instances of left parameter to all instances of right parameter (which is done in existing ECL execution), rather we compare instances of left parameter to pre-filtered/pre-indexed instances of the right parameter
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: green
|
||
id:: 64df84b2-1c45-423c-8643-dfd9a95e481e
|
||
- his step identifies optimisable match rules along with the specific property name.
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: green
|
||
id:: 64df8505-52f9-4ad8-ad0e-72a3bac7d33f
|
||
- optimised program along with the new order of the match rules
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: yellow
|
||
id:: 64df8522-e60a-4ca4-a096-fa215ea8a83a
|
||
- This optimised comparison program will then be executed by the existing ECL engine. The resultant match trace would be a subset of the trace that would have been produced by the original comparison program. This subset trace would exclude the matches which would not satisfy the domain (an EOL expression to narrow the search space), while including all positive matches.
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: yellow
|
||
id:: 64df8565-febe-429f-a916-ed10fa6cffb5
|
||
- (1-3 and 5-7)
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: red
|
||
id:: 64df85f8-adbb-4970-83e1-c79a6bc74310
|
||
- Selective traceability for rule-based model-to-model transformations
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: green
|
||
id:: 64df8690-1ed4-4792-a05d-ecfc4a9c2831
|
||
- he reason for extracting the dependency graph is to reorder the rules in a way that if MRx is invoked by a rule MRy then MRy is scheduled before MRx.
|
||
ls-type:: annotation
|
||
hl-page:: 6
|
||
hl-color:: yellow
|
||
id:: 64df8769-f43c-429a-9916-8f4d192ee55f
|
||
hl-stamp:: 1692370794796
|
||
- his is the third step of the approach that takes in a typeresolved AST as an input with the aim to identify the rules which can be optimised
|
||
ls-type:: annotation
|
||
hl-page:: 6
|
||
hl-color:: green
|
||
id:: 64df8b88-f9cf-4e58-9fee-ca5d6bdc3272
|
||
- DOM
|
||
ls-type:: annotation
|
||
hl-page:: 6
|
||
hl-color:: yellow
|
||
id:: 64df8b9f-f391-467b-9feb-04095ce1d102
|
||
- Algorithm for Identifying optimisable rules
|
||
ls-type:: annotation
|
||
hl-page:: 6
|
||
hl-color:: yellow
|
||
id:: 64df90c9-d494-46ba-b375-0b9483158ac7
|
||
- MR1, MR2.., MRn along with the specific properties say p1, p2.., pn on the basis of which we are comparing the elements in the compare block.
|
||
ls-type:: annotation
|
||
hl-page:: 6
|
||
hl-color:: yellow
|
||
id:: 64df90f4-5d05-4d8b-aa04-17ee2e17617f
|
||
- execution time of the original ECL programs using the existing ECL engine with the rewritten ECL programs(also using the existing ECL engine).
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: green
|
||
id:: 64df9143-e7a8-4a8d-99e8-ac8890cd09a1
|
||
- parallel execution of ECL programs
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: yellow
|
||
id:: 64df9168-c16e-4b74-98fa-c434850b09c1
|
||
- dentifies the independent rules that can be executed in parallel
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: green
|
||
id:: 64df92b0-3755-461a-a516-a4cd3506e5bd
|
||
- object oriented (OO) models with database (DB) models
|
||
ls-type:: annotation
|
||
hl-page:: 8
|
||
hl-color:: green
|
||
id:: 64df92e8-0d41-446f-b418-4e7d375dd2c2
|
||
- Sega4biz: Model-driven framework for developing serious games for business processes
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: green
|
||
id:: 64df92fe-fc01-48c5-b212-a5b3cd2cdf14
|
||
- Figure 7. Comparison of Execution time in OO DB Comparison
|
||
ls-type:: annotation
|
||
hl-page:: 9
|
||
hl-color:: yellow
|
||
id:: 64df94b0-5588-4429-a20b-77e7d267c062
|
||
- This performance gain is achieved by reducing the search space needed for matching.
|
||
ls-type:: annotation
|
||
hl-page:: 9
|
||
hl-color:: blue
|
||
id:: 64df94e8-7bf1-4c2c-8e99-8da40b395056
|
||
- pre {2 var Class2TableMap = DB!Table.all.mapBy( param|param.name);3 var Attribute2ColumnMap = DB!Column.all. mapBy(param|param.name);4 }56 rule Class2Table7 match l : OO!Class8 with r : DB!Table9 from : Class2TableMap.get(l.name) ?: Sequence{} {10 compare : true11 }1213 rule Attribute2Column14 match l : OO!Attribute15 with r : DB!Column16 from : Attribute2ColumnMap.get(l.name) ?: Sequence{} {17 compare : true and l.owner.matches(r. table)18 } Listing 4. ECL rewritten program for OO-DB models
|
||
ls-type:: annotation
|
||
hl-page:: 8
|
||
hl-color:: yellow
|
||
id:: 64df94f4-add5-46f3-b38b-f1ad1e29ad56
|
||
- execute independent rules before those dependent on them, optimizing the comparison process by reducing the cost of jumping between comparison rules.
|
||
ls-type:: annotation
|
||
hl-page:: 10
|
||
hl-color:: yellow
|
||
id:: 64df9571-6094-4913-930e-5ebf28f578d7 |