7.2.1 Introduction
Applying DReAMT to a service API building process was done at Tam-pere University of Technology (TUT) under the research project MoDES in co-operation with an industry partner, Nokia Research Center (NRC).
The service API building process had been developed at NRC for building so called ReSTful web service APIs that follow the Representational State Transfer (ReST) [18] architectural style. DReAMT was used to develop a model transformation for one design phase of that process.
The original goal was to evaluate the DReAMT model transformation language and tool and study model transformation development. Addition-ally, the DReAMT model transformation development process was created and also evaluated. This application of DReAMT is described thoroughly in the included publication [IV].
The service API building process is illustrated in Figure 7.1, where the packages are models and the block arrows represent design phases. The Re-quirements note stands for informal requirements specification. The model Functional Spec is a functional specification, a formalization of the require-ments specification.
Information Model defines the main concepts and their relationships on a technology-independent level. Resource Model is a resource-oriented view of the conceptual model. It is a mapping of the concepts onto the ReST architectural style. The model represents the resources that are exposed through the API. DReAMT was used to develop a model transformation for the design phase between the information model and the resource model.
Service Spec specifies the service and contains the resource structure as an URI listing, HTTP-methods, links between resources, etc. Service is a service implementation, an actual executable service description.
7.2.2 Conducting the Study
There were four stakeholders with a different skill set, expertise and initial knowledge. The author of the service API building process (from NRC) knew the process inside out and was a ReST expert. He was also responsible for the development of one web service (Photo Service). An application developer (NRC) knew something about the process and ReST, but was not an expert.
He was responsible for another web service (Topic Service).
The author of this dissertation (from Tampere University of Technology (TUT)) knew DReAMT thoroughly and as a model transformation researcher had good knowledge of them. A programmer (TUT) had enough knowledge of the DReAMT transformation language and tool to be able to write model transformations. The former two had only very basic knowledge of model transformation issues and no knowledge of DReAMT, whereas the latter two were unfamiliar with the service building process and ReST. There was virtually no overlap in the two groups’ relevant knowledge.
The differences in the skill sets and the lack in the overlap can be seen clearly in Figure 7.2. The model transformation related skills are on the axes on the left: knowledge about foundations and theory of model trans-formations (MT), about the DReAMT approach and philosophy in general (Approach) and about the DReAMT model transformation language (Lan-guage), from bottom to top. ReST related skills are on the right: ReST in general (ReST), the ReSTful API development process (ReSTifying process) and the stakeholder’s web service (Service), from bottom to top. Each axis has a mark for basic, good and thorough understanding of the concept, in that order from the center outward. The skill levels of the stakeholders are rough estimations and not results of measurements.
Initially all the knowledge about the process and specifically of the design phase was tacit and in the head of the Design Phase Expert. Even the information and resource models’ form, or modeling language, was not clear, only what they needed to contain. Since both types of models deal with concepts and their relationships, class diagram was chosen as the modeling language for them and a profile was created for resource models. At first, two kinds of resources and two kinds of relationships were identified, and they were added in the resource model profile. Figure 7.3 shows an example of fragments of an information model and a resource model.
The Design Phase Expert identified the most important simple element structures that can appear in an information model and crafted 12 correspon-dence examples in the first iteration. One of them is shown in Figure 7.4.
Because both the information and the resource model are class diagrams, the two structures in the correspondence example are class diagram fragments.
(a) Design Phase Expert
(b) Application Designer
(c) Transformation Architect
(d) Transformation Programmer
Figure 7.2: Diagrams of the stakeholders’ knowledge
Figure 7.3: Example a) information and b) resource model fragments [IV, Fig. 3]
The information model structure is on the left and the resource model struc-ture on the right.
At the first glance, the correspondence example looks like a well-defined
Figure 7.4: A correspondence example for navigable associations with mul-tiplicity > 1 [IV, Fig. 4]
rule to transform the structure on the left into the structure on the right.
However, a closer look reveals ambiguities. For example, can the association between A and B be a composition or an aggregation? Do the classes A and B have to be distinct? Are all the elements on the right created by this rule or is there overlap with other rules?
The Design Phase Expert was confident that the examples were correct, i.e. that at least in some cases the solution is right. However, he was not able to say, whether the correspondence examples were consistent with each other, covered all important situations, contained all the necessary variation and worked independent of each other. In fact, when the Design Phase Ex-pert and the Transformation Architect created the transformational patterns, they discovered that some examples were conflicting while others were just compositions of simpler ones.
Because of the many discoveries at this early stage, first the correspon-dence examples and then the transformational patterns were revised without going through the rest of the development cycle. For the same reason, it was also done a third time. On the third time the need for a new type of a re-source, aprojection, was identified. The need was just written down and not pursued further and the resource type was not defined or described at this point. This led to changes in the modeling language for the target model.
The Transformation Architect created the transformation definition. It was quite simple because of the small number of patterns. The Transforma-tion Programmer created the transformaTransforma-tion implementaTransforma-tion, which was a straight-forward task, due to the direct correlation between the transforma-tional patterns and the tool implementation concepts. The transformation implementation was executed on the photo service’s information model and the Design Phase Expert evaluated the result.
The work between the Design Phase Expert and the Transformation Ar-chitect progressed in weekly meetings over the course of two months. If the schedules and other responsibilities of the participants had permitted, the in-tervals could have been much shorter. With such a sparse schedule, it helped to have the progress recorded in clear artefacts. Especially the boundary-objects, i.e. artefacts used for communication across roles, were useful.
7.2.3 Further Development
After the study was carried out the ReSTifying process was developed fur-ther at NRC independently, mostly during the year 2009 [29]. The biggest modification was changing the whole viewpoint to how the information model is crafted based on the functional specifications. In the old process the se-quence diagrams in the functional specification were refined iteratively, until they were detailed enough for synthesizing the information model. In the new process the ReST designer inspects the sequence diagrams and answers a questionnaire. The information model is created as a side-effect of the answers.
The role of the information model changed from an abstract conceptual model into a more detailed model containing some information that was pre-viously introduced to the process in the resource model. In a way the infor-mation model “moved towards” the resource model in purpose. This changed the relationship between the two models and therefore also the requirements for the model transformation. Some design decisions, for example choosing properties that uniquely identify an entity, were moved to the earlier phase, as part of the questionnaire.
The transformation from an information model to a resource became more mechanical than before. Also, the modeling language (UML profile) for the information model was modified. The modeling language for the resource model was changed, too, but only very little.
In early 2010, the author of this dissertation built one DReAMT model transformation between the new information and resource models and an-other from the resource model to the service specification. The service spec-ification was given using WADL [48]. The model transformations were built mostly by following the information in a report [29] detailing the two phases of the new process. The work took about four weeks of calendar time, in-cluding testing and debugging. The model transformations contained only a little interaction.
7.2.4 Observations and Conclusions
The DReAMT model transformation development process can be used to build a model transformation in parallel with the application development.
The iterative development updates the model transformation with short in-tervals. The interaction and ability for direct model modifications during the model transformation make the model transformation flexible and useful even when incomplete. The DReAMT model transformation language and DReAMT tool can be used to create a model transformation.
We think the ReSTifying process gives a realistic view of the problems typical at the beginning of a model transformation development process. The stakeholders have different expertise and knowledge, yet they need to commu-nicate and work together to specify and build the model transformation. The Design Phase Expert—indeed the author of the service building process!—
was not able to give precise rules or comment on the rule set’s completeness, coverage or consistency. The ReSTifying process, its use of models and mod-eling languages kept evolving all through the study and after it. We think this, too, is to be expected when the process is new.
We used transformational patterns to capture the requirements in the domain language. The Design Phase Expert and the Transformation Archi-tect were able to discuss, discover and document the requirements using the model transformation development artefacts. The concrete artefacts acted as boundary objects between stakeholders and made it easier to communicate even when there were a few weeks between iterations.
The correlation between the transformational patterns and the model transformation design and implementation artefacts limited the scope of changes and made iterative refinement of a pattern easier. Transformational patterns turned out to be a good unit for refinement. They are independent, but related, so adding and updating patterns does not greatly affect the other patterns or their implementations.
The research assistant acting as the Transformation Programmer did not know DReAMT before the study started. He learned the language and the tool quickly and was able to build the transformation implementation inde-pendently.