The TTC 2017 Family to Persons Case asks for bidirectional transformations between a Family model and a Persons model. Each model provides informations that is not contained in the other model. Thus, the case asks to keep some kind of correspondences between the elements of the two models. In addition, the case asks for incremental handling of model changes. Figure 1 shows the SDMLib class model for this case. SDMLib comes with its own code generation, i.e. we do not use the EMF class model nor the EMF code generation. SDMLib class models do not provide aggregation as this is an unusual concept within a graph like object model. Thus, the four associations between Family and FamilyMember are modeled as bidirectional associations with explicit roles at the Family side. To deal with these four associations easily, FamilyMember provides the additional method getFamily() that looks up all four associations in order to nd the corresponding family. To maintain the correspondences between the two model parts, we have added a famReg{persReg association between FamilyRegister and PersonRegister. In addition we use a cp{cfm association connecting FamilyMember objects with corresponding Person objects. Adressing the incremental requirement, we use unidirectional changed links between the register objects and their FamilyMember and Person objects, respectively. The set methods mark changed objects with c links, as a side e ect. Furthermore, the cp{cfm association has a life-dependency semantics: if one object is explicitly destroyed, the corresponding partner is deleted as well. Again, this is implemented via side e ects in the corresponding removeYou() methods.
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 g g i f ( p . g e t C l a s s ( ) != gender ) f try f
Person newP = ( ( Person ) gender . newInstance ( ) ) . w i t h R e g i s t e r ( p . g e t R e g i s t e r ( ) ) . withBirthday ( p . g e t B i r t h d a y ( ) ) . withCfm ( p . getCfm ( ) ) . withName ( p . getName ( ) ) ; p . removeYou ( ) ; p = newP ; g catch ( I n s t a n t i a t i o n E x c e p t i o n j I l l e g a l A c c e s s E x c e p t i o n e ) f
e . p r i n t S t a c k T r a c e ( ) ; g g S t r i n g fullName = S t r i n g . format ( "s, s " , f . getName ( ) , fm . getName ( ) ) ; p . withName ( fullName ) ; return true ;
Listing 1: Example Graph Query in Java
The Families to Persons case requires that the mother and the daughters of a Family shall map to an object of type Female within the PersonRegister. The father and the sons shall map to an object of type Male. As a FamilyMember might have changed e.g. from the sons role of one family to the mother role of another family, the corresponding Person object needs to change from type Male to type Female. As Java objects are not able to change their type, lines 10 to 12 of Listing 1 simply create a new Object of the appropriate gender and copy all attributes and references from the old object. Finally, method ensureNameAndGender() assigns the current full name to the Person object.
The second case is handled by the second optional subpattern of Figure 2. The second subpattern contains a negative application condition shown as a solid blue box with a forbidden sign in its upper left corner. This negative application condition again looks for an old corresponding Person if there is no match the negative application is not violated and the surrounding pattern continues its matching. In our case, the second optional subpattern just creates a new object of type Person. As discussed, we actually need an object either of type Female or of type Male. This is again handled by calling method ensureNameAndGender() within the pseudo condition shown below pattern object newP.
Figure 3 shows our backward transformation rule. Pattern matchin starts with the PersonRegisterPO pattern object pr shown in the up right corner. The match for pr is provided as parameter. The rule rst looks for a Person p that is marked as changed via a c link. This c link is destroyed (as indicated by the red color). The backward transformation rule now handles two cases: there is an old corresponding FamilyMember or not. The rst case is handled by the optional subpattern shown at the bottom of Figure 3. The pattern object oldFM matches a FamilyMember that has a cfm (corresponding family member) link to our Person p. Next pattern object oldF looks up the corresponding Family. This uses method getFamily() which tries motherOf, fatherOf, daughterOf, and sonOf links to navigate from a FamilyMember to its Family. Now there are two conditions. Condition 1 is a pseudo condition that actually assigns the given name of the current person to the current FamilyMember. After that, the second condition checks, whether the current Family has the right name. The second condition holds, if the current Family's does not match current person's family name. In that case, we need to look for another Family with a matching name. This is done by the second subpattern of our rule. Thus, in case of a con ict with the family name, the rst subpattern matches (all conditions) and it is executed, i.e. the oldFM object is destroyed. (Causing the second subpattern to create a new FamilyMember object, see below). If the family name matches, the second condition fails and the pattern is not executed but the oldFM object survives. In that case, the rst pseudo condition has already adjusted the given name and the case of an old existing FamilyMember is handled, completely.
The second optional subpattern of our backward transformation rule creates a new FamilyMember object that corresponds to our Person p. This is done by the pattern object fm. The pseudo condition below fm assigns the given name. We also need a Family f for the new FamilyMember. The Family is derived from the FamilyRegister fr via the path expression getOrCreate(p.getFamilyName()). This operation searches our FamilyRegister for a matching Family. If there is no Family with the right name, a new Family object is created. Actually, the getOrCreate() methods also respects the Decisions parameter required by the case description and creates always a new Family, if required. Now, we have to add our new FamilyMember to its Family. This is done using the pseudo condition f.addToFit(fm). Method addToFit() just looks for the gender of the current person and whether the corresponding parent role is still vacant and whether it should be used or whether the new FamilyMember should become a daughter or a son, respectively. Note, method addToFit() might easily have been modeled as a model transformation rule, but the cases are pretty straight forward and thus we just programmed it in plain Java. 3
[SDMLib] SDMLib - Story Driven Modeling Library www.sdmlib.org May, 2017.