Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[henshin-user] parameterization of rules, require/preserve difference, time stopping

Hello,

 

While I worked on a project with Henshin I stumbled upon a few problems and hope someone here can help me out.

1.       Is there an option to parameterize rules in Henshin? Let's say I created a rule with Node A and Node B and they are connected through Edge C. Both Nodes have an Attribute 'ID' of the type int.  Now there are times where I want to find all combinations, where Node A has the ID 1 and then there are times when I want to find all combinations, where Node A has the ID 2.

In the bank example I saw that it is possible to parameterize units, now I hope there is a way to do the same with rules.

2.       My next problem is, that it seems to be impossible to create a rule where you only use <<require>> and <<forbid>> in combination. When I want Node A and Node B to exist (<<require>>) and the Edge C not to exist (<<forbid>>), the complete graph gets changed. As an example, just now it changed the annotation of Node A to <<forbid>> and the annotation of node B to <<delete>>.

This problem can only be fixed by using <<preserve>> instead of <<require>> (Or is there another way?). Could anyone tell me the reason behind that?

3.       This made me think about the matchmaking of Henshin, because there has to be a difference between <<require>> and <<preserve>>. Since I couldn't find documentation on how exactly the matching algorithm of Henshin works it would be great if someone here could clear that up for me. (If there is a documentation I missed, I would be grateful for a link)

4.       Finally I tried to stop the time the searching procedure needs in my project. I used a stopwatch attempt (saving the start time, run procedure, saving end time). Since I don't want to run the program 50 times and note down the times, ich wrote a loop, that runs the attempt 50 times in a row. The problem is, that the time goes down each iteration. The time starts with reasonable 70 to 80 ms and ends with 10 ms. Normally this time stopping approach works quite well. That's why I would like to know, if there is some reason for this behaviour.

 

Best regards,

Florian

 


Back to the top