This paper describes the SDMLib solution to the FIXML case for the TTC2014 [9]. SDMLib provides Java code generation for class models / class diagrams. In addition, SDMLib provides a mechanism for learning class models from generic example object structures. Thus, for the FIXML case we just added an XML reader that reads an example file and creates a generic object structure reflecting its content. Our team at Kassel University found this case particularly interesting as we give a course on CASE tool construction where one assignment to the students is to learn a class diagram from an XML file containing object descriptions but without an explicit XML schema. Thus, the case looked quite familiar to us. In addition, our team has developed a software development process called Story Driven Modeling [3, 1]. Story Driven Modeling starts with textual scenarios that describe example situations and how they evolve through the execution of a certain user action. Next, the textual scenarios are extended with informal object diagrams modeling how the desired program might represent the described situations as object structures at runtime. Initially, the informal object diagrams may omit object types. The types are added in another design step that formalizes the object diagrams until a class diagram can be derived. This initial class diagram may be extended several times in order to support additional scenarios and in order to e.g. add support for certain design patterns like composite pattern or visitor pattern or strategies. Then, an implementation of the modeled classes may be generated using e.g. Fujaba [2] or UMLLab [8] or SDMLib [7]. To support Story Driven Modeling, SDMLib provides Generic Object Diagrams [5]. Generic Object Diagrams are able to represent untyped object structures, they allow to add type information at runtime and SDMLib is able to learn a class diagram from Generic Object Diagrams and to generate a Java implementation from it. This is discussed in Section 2. To address the FIXML case, we just used the standard Java XML parser and wrote a small transformation that translate the read XML data into a Generic Object Diagram. Then, we used the SDMLib mechanism to learn a class diagram and to generate a Java implementation, cf. Section 3.
. . .
G e n e r i c G r a p h g r a p h = new
G e n e r i c G r a p h ( ) ;
G e n e r i c O b j e c t b u i l d i n g = g r a p h . c r e a t e O b j e c t s ( " WilliAllee " , " Building " ) 5 . with ("name" , "WA73"); 6 7 GenericObject wa13 = graph . createObjects ("seFloor" , "Floor") 8 . with ("name" , "WA13" ). with ("level" , "1"); 9 10 graph . createLinks (). withSrc ( building ). withTgt (wa13 ). withTgtLabel ("has"); 11 12 GenericObject wa03 = graph . createObjects ("digitalFloor" , "Floor") 13 . with ("name" , "WA03" ). with ("level" , "0" ). with ("guest" ,"Ulrich"); 14 15 graph . createLinks (). withSrc ( building ). withTgt (wa03 ). withTgtLabel ("has"); 16 . . .
Using GraphViz [
Listing 2 shows the SDMLib algorithm for learning a class model from a generic object structure. First, line 4 loops through all generic objects and line 6 queries the class model for a class with a name corresponding to the type of the current generic object. Method getOrCreateClazz creates a new class, if the object type shows up for the first time. Then, line 8 loops through the generic attributes attached to the current generic object. For each attribute method getOrCreateAttribute retrieves an attribute declaration in the current class, cf. line 9. g A s s o c i a t i o n a s s o c = g e t O r C r e a t e A s s o c ( sourceType , s o u r c e L a b e l , t a r g e t T y p e , t a r g e t L a b e l ) ;
Learning the type of an attribute is done by method learnAttrType called in line 10 of listing 2. Basically, we retrieve the value of the current generic attribute. For our generic object model, attribute values are just strings. To learn more specific attribute types, we just try to parse the value string into an int, a double or a java.util.Date value. On success, we store the detected type in variable attrType. On different attribute values belonging to the same attribute declaration, this parsing step may compute different results. For example one generic object may have a num attribute with value 42 while the next generic object may have a num attribute with value 23.5. The first case results in an attribute type int while the second produce an attribunte od type double. To resolve this, we compare the type computed for the current value with the type of the attribute declaration that has been computed previously. If the new type is more general than the old type, we switch to the new type.
Next, the loop in line 14 of listing 2 is used to learn associations from generic links.
For each link we retrieve the types of the connected objects and the role labels for the Figure 2: Class link ends. Then, method getOrCreateAssoc searches the class model for a matching Model learned association or creates one, otherwise. Note, that this step is sensible to the direction from Generic of links, two similar links with swapped source and target roles might result in two Object Model associations with swapped roles instead of a single one. This is easy to fix but results in a more complicated learning algorithm and is thus omitted for lack of space.
Finally, we have to deal with association cardinalities. The most general approach is to use to-many cardinality for all association roles. To-many associations are able to store to-one relations, too, and thus to-many association would work in all cases. However, in many cases a to-one cardinality would suffice and might be more natural to the user. Thus, SDMLib starts with a to-one cardinality for all new associations and roles and we change the role cardinality as soon as there is an object with two similar links attached to it.
Once a class model has been learned, we use Graphviz to render it to the user as a class diagram, cf.
figure 2. In addition, the user has the possibility to refactor the learned class diagram e.g. via the SDMLib
API. From the resulting class model, SDMLib generates a Java implementation with one plain Java class
per model class with private attributes and public get and set methods for each attribute and with private
attributes with public access methods for each association role (the access methods of the two roles that
build an association call each other to achieve referential integrity of the pairs of pointers that represent
a link, to-many associations use special container to hold multiple pointers). For each model class like
Building we generate a BuildingSet class. These classes are used for to-many roles. In addition, these
set classes provide the same methods as the original model classes, e.g. FloorSet::getName(). In a
set class, methods like getName() are applied to each contained element, the results are collected and
then returned. Thus, for a variable mainBuilding of type Building the call mainBuilding.getHas()
delivers the set of floors of that building and mainBuilding.getHas().getName() delivers a list of names
of these floors. We also generate model specific classes like BuildingPO that are used to represent pattern
objects in model transformations. For more details see [
For the FIXML case, we just developed an XML reader that turns the example input data into generic object structures. Then, the SDMLib techniques are used to learn a class model and to generate Java code for it. Our solution to the FIXML case first learns one separate class model for each sample XML file. Then, we use all sample files to learn one common class model that covers all cases. As the class model learning algorithm for each generic object, attribute, and link first looks whether it has already an appropriate declaration, you can also start with a class model learned from other cases and add more examples later.
Once we have learned a class model and we have generated its Java implementation, SDMLib also allows to convert generic object structures into model specific object structures. This is done using the reflective access layer generated for the model. Once the generic object structure has been transformed into a model specific object structure, you may program model specific algorithms based on the generated Java implementation leveraging static type checking and compile time consistency checks. Then you may load XML files, convert them to model specific objects and run your algorithm. Your algorithm may also utilize the set based model layer generated by SDMLib or even the model transformation layer. As simple example for the set based layer you may write currentOrder.getOrdqty().getQty().sum(). This looks up the set of OrdQty objects attached to the current order. Then we look up the qty attribute of these objects. Generally, attribute values are collected in list to allow multiple occurences of the same value. For lists of numbers, SDMLib provides some special operations like min, max, and sum. The latter computes the sum of the numbers of the list.
Thus, SDMLib does not only generate a Java implementation for the example XML files. It also provides a mechanism to load XML files to a model specific object structure and SDMLib allows to run complex algorithms and model transformations on that data. Overall, the FIXML case was made for us. SDMLib provides a lot of functionality for generic object structures, learning class models, and generating Java code.