In today’s guest post, Marco Brambilla presents his work on bridging the gap between model-driven engineering and the social web. IMHO, this is a key aspect that has been largely ignored by MDE tools so far. Most applications integrate nowadays social components and we must be able to model (and “generate”) the relationship of our application with them. That’s why I got so excited when I learnt about Marco’s work but let him explain that. Enter Marco.
The Social Web: Did We Notice?
We are all experiencing how social technologies have transformed the Web to a place where users actively contribute to content production and opinion making, independently from their age, technical skills, job and living conditions.
That’s why as a Web engineer and model-driven addict I’m always appalled by the extremely low level of attention that the modeling community and the software engineering community at large are paying to this phenomenon.
Needs and Responses
Fortunately, new social applications are continuously requested, for both consumer and enterprise markets. From a software engineering perspective, these social-based applications exhibit specific requirements both in terms of development methods and design languages. That’s why we decided to address the problem by proposing a model-driven approach that is specifically focused on the development of Web applications that exploit social features.
In particular, we worked on a method that starts from a classification of typical social requirements, and maps them to model-driven design best practices both in terms of static and dynamic models.
In this context, we have developed a taxonomy of social requirements, a set of UML design patterns for addressing them, and an extension of the WebML notation (a Domain Specific Language designed to model Web applications), comprising a set of modeling concepts and design patterns describing the user interfaces and interactions with the social platforms.
The rest of this post shows a few excerpts of our work.
The first step of the work has been the study of the typical social networking requirements. In our analysis, we considered more than 30 social networking applications and we struggled to extract coarse and detailed features; in turn, these features have been reverse engineered to requirements and a complete mapping has been performed between the applications and those requirements. Just at the coarse level of detail, we identified 52 core features. In turn, each of them splits into 5 to 15 sub-features. We converted these features into requirements and we represented them in a goal diagram. Overall, the complete goal map would include more than 500 goals. The figure below shows the taxonomy of the top 52 goals and the zoomed view of one of the categories, namely the social content interaction needs, and the zoomed details of one specific goal of the 52 top level ones, namely the profile management goal.
This taxonomy represents a fairly complete view of the possible social requirements that a social platform may need to implement.
Social UML Patterns
The goal model that collect the subset of needs for the application to be implemented is fed into a model transformation that produces:
- a complete and coherent class diagram covering the design of all the predefined goals and their relations
- a detailed user interaction model specified in WebML
This represents a major advancement in terms of design productivity, as the designer gets automatically a large share of the design. This has been made possible thanks to the a-priori specification of a set of design models (namely, UML class diagrams and WebML navigation models) for all the known social requirements in the taxonomy.
For every category of requirements, all the mappings for the requirements are listed, together with thee modifiers that need to be applied to the patterns when merged with others.
The UML models have been designed so as to grant that the goal-to-class transformation can act as follows: if at least one goal has been selected in a category, the respective UML social pattern is picked; if two UML social patterns are picked, also the “bridge” UML models are picked. Furthermore, since the pattern would support all the
requirements of the category, the transformation takes care of:
- preserving the part of the pattern that is common to all the requirements of the category;
- stripping out all the parts of the pattern associated to non-selected goals.
Notice that besides our best attempt to cover these cases, there will always be the need of manual refinement.
A (simplified) example of class diagram produced out of the subset of requirement related to contents interaction the following.
Social WebML Extensions
In order to enable the design of social-enabled applications with our model-driven approach, traditional interaction modeling languages were not enough.
Thus, we extended the WebML notation by adding a set of components (called units in WebML parlance) that encapsulate the logic of the interaction with the social platforms. These units work as wrappers of the social platform APIs and hide the underlying complexity from the developer, reducing
the cost of designing new applications. The units are divided in three sets: cross-platform units, social platform-specific units, and collaboration platform units.
Besides designing the conceptual definition of the units, we also implemented their behavior within the WebRatio tool. Most of them have been made available on the online WebRatio store already and are available for download and use for free within WebRatio (a free edition of the tool is available too).
From a language design perspective, the critical problem was the following: while on one side we wanted to define units that were cross-platform (e.g., same component applying the same semantic operation on Facebook, Twitter, and others), we had to cope with the limitations of the APIs of the platforms, which were all different in syntax and semantics. This made it hard to generalize the units. But the struggle ended up in what we think is a good trade-off. Here are some of the units.
Social WebML Patterns
Starting from the goals specified in the requirements definition phase and from the designed WebML extensions, our analysis focused on identifying a set of social design patterns with the aim of covering the most common requirements that a social application must fulfill.
The most important patterns we identified are: Post, Comment, Send Message, Like/ Vote/ Rate, Login, Group Management, Event Management, Content Management, People Search, and Content Search.
Again, the critical problem related to pattern definition was that we wanted to define patterns that were cross-platform but we also had to cope with the limitations of the APIs. The resulting patterns are an interesting baseline for designs though. Some examples are reported here:
The Comment pattern reported above describes the interaction flow that is executed when a message is published as a comment to another content (e.g., a post) on a social network, namely on Facebook. In the Home page, the index unit Post List present to the user the list of posts from his Facebook wall, retrieved by the GetPosts operation unit. The user can select one post, write his comment in the Comment form, and submit and publish it with the Comment Post unit.
On the other hand, the Message pattern describes the user interaction flow that is executed when a message is sent to a limited set of selected and identifiable users, like in the case of a Twitter direct message. The image shows in the Home page the index unit Friend List shows to the user the list of his Twitter friends retrieved by the Get-Friends unit. The user can select a friend and compose the message through the form Send a message, which submits it through Message unit.
The upfront cost of requirement and design specification we took care of is quickly repaid when various applications need to be implemented. We tested our approach by implementing a few examples of social-enabled applications and we obtained encouraging results. Thanks to the broad reuse of artefacts at all the development stages, our approach allows for effort savings of more than 90% in requirement specification phase, 15% at design time, 14% at business logic implementation time, and 60% at UI implementation time. I think this is
a remarkable result.
If you want to know more, you need to go and read the papers or at least have a look at our summary video: