Re: [henshin-dev] UML: deleting an ownedAttribute from a Class

[Vlad Acretoaie <rvac@xxxxxx>]

Hi Frank,

Thank you for the very quick answer. I'm glad that your explanation matches my initial understanding of the Henshin semantics.

I think I have identified the source of my confusion: executing the transformation programmatically from a Java application causes the Property to be completely removed from the target model. However, executing it using the Henshin GUI behaves as you describe (the Property is not removed, but the ownedAttribute edge is removed). 

I am not yet sure why the behavior differs in these two situations, but at least now I know it's not a conceptual misunderstanding.

Cheers,
Vlad

> -----Original Message-----
> From: henshin-dev-bounces@xxxxxxxxxxx [mailto:henshin-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Frank HERMANN
> Sent: Monday, October 20, 2014 3:43 PM
> To: Henshin developers mailing list
> Subject: Re: [henshin-dev] UML: deleting an ownedAttribute from a Class
> 
> Hi Vlad,
> 
> thank you for your questions and your example.
> The behaviour of Henshin you described is correct.
> The reasons for the behaviour you described are the following:
> 
> 1. "deletion" of preserved node: the node is still there, but not reachable any
> longer via the containment edges.
> Explanation:
> Your rule deletes an edge. The dangling condition is not affected, because
> the dangling condition restricts the deletion of nodes only.
> However, semantically, you are deleting a containment edge (diamond
> shape as arrow tip at the arrow head). This means that the child node
> (containment) cannot be reached any longer from the root object, because
> you usually iterate along the containment edges.
> This is standard behaviour of EMF. The child node "MyProperty:Property"
> is still there, but not reachable from the class.
> Thus, there is no problem from the theory point of view: the node is still
> there. Moreover, all edges connected to this node are
> 
> 2. dangling edge conditions prevents deletion of node:
> If you try to delete a node and you do not delete all adjacent edges, then the
> dangling edge condition prevents the rule application.
> 
> 3. Solutions for your goal: deletion of the node
> a) If you do not want to take care about adjacent edges, but you just want to
> delete the node and Henshin shall delete all adjacent edges, then:
> you delete the node in the rule and you set the dangling condition to false.
> You already described that you tested this solution.
> b) If you want to disconnect a subtree, then you can delete the containment
> edge without deleting anything else. However, this will cause that you may
> preserve references in your instance to garbage (disconnected subtree). If
> you want to prevent the latter, you should avoid alternative (b).
> 
> 
> Do my comments answer your questions?
> 
> 
> Best regards,
> 
> Frank
> 
> 
> 
> On 10/20/2014 2:15 PM, Vlad Acretoaie wrote:
> > Hi,
> >
> > I wrote a simple transformation for deleting an ownedAttribute from a
> UML class. While trying to get the transformation to run, I encountered an (in
> my opinion) unexpected behavior of the Henshin engine. I am attaching the
> transformation model and a test source model here.
> >
> > In short, the Henshin diagram contains a Class Node, a Property Node, and
> an ownedAttribute Edge connecting them. When the Action of the
> ownedAttribute Edge is set to <<delete>> and the Actions of the Class Node
> and the Property Node are set to <<preserve>>, the Property is removed
> from the source model. This is indeed the behavior I would like to achieve,
> but the fact that it occurs is somewhat surprising to me. Here's why: the
> Property Node is deleted although it appears in both the LHS Graph and the
> RHS Graph, and there is a Mapping between the corresponding Nodes in the
> two graphs. In my understanding of the Henshin semantics, this should not
> happen.
> >
> > To make things even more confusing, setting the Action of the Property
> Node to <<delete>> causes a runtime error. I suspect this is caused by a
> dangling edge, since setting the checkDangling flag to false avoids the error.
> But then why doesn't this error occur in the scenario described above, when
> the Property Node is also removed?
> >
> > Could anyone explain why the scenario I describe in the second paragraph
> deletes the Property, and why it doesn't cause a dangling edge error?
> >
> > Also, how can I mitigate against the dangling edge error? Without any hints
> on what edge is left dangling, I could only guess by looking at the UML
> metamodel, but so far my guessing has been unsuccessful.
> >
> > Cheers,
> > Vlad
> >
> >
> > Vlad Acretoaie
> >
> > PhD student
> >
> > DTU Compute
> >
> >
> >
> > Technical University of Denmark
> >
> > Department of Applied Mathematics and Computer Science
> >
> > Matematiktorvet
> >
> > Building 303B, Room 055
> >
> > DK - 2800 Kgs. Lyngby
> >
> > Denmark
> >
> > Direct +45 45253645
> >
> > rvac@xxxxxx<mailto:rvac@xxxxxx>
> >
> > www.compute.dtu.dk/~rvac<http://www.compute.dtu.dk/~rvac/>
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > henshin-dev mailing list
> > henshin-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/henshin-dev
> 
> _______________________________________________
> henshin-dev mailing list
> henshin-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit https://dev.eclipse.org/mailman/listinfo/henshin-dev