Keywords

1 Introduction

The software development process is a refinement loop that iteratively transforms requirements into a final product. Iteration is fundamental to address incomplete, loosely defined, or rapidly changing requirements. In web and mobile applications development, the wide range of device screens and coding platforms makes the ability to rapidly evolve and evaluate new releases even more critical.

In Web applications, UI development demands a sharp division between structure (HTML) and style (CSS) for easy adaptation to various devices and clients capabilities [2]. Complexity of UI layout and styling is shifted from HTML, which describes the structure and semantics of the content, to CSS. While this scenario enables advanced use-cases, in practice it may not achieve a real separation of concerns in all cases. To obtain advanced layout and styling effects, the CSS rules often become dependent on the HTML structure, which increases complexity, maintenance cost, and code duplication.

In the past years, coding practices shifted towards an effective compromise between separation of concerns and development costs. Modern CSS frameworks, such as BootstrapFootnote 1, Zurb FoundationFootnote 2, Materialize CSSFootnote 3, and many others, have shown how sharing layout concerns between HTML and CSS layers can enhance re-usability and eventually reduce development time. The same trend can be seen in the field of Mobile Applications with Framework7Footnote 4, FlutterFootnote 5 and many others. This compromise blurs the line between structure and styling making more and more difficult for M2T transformations to avoid conflicts at code level.

In this demo, we showcase IFMLEdit.org [1], an open-source on-line tool for rapid prototyping of web and mobile applications that starts from a standard OMG MDA language (IFML) and implements a lightweight environment for developers to specify web and mobile applications and instantly generate their code. In the demo, attendees will use the on-line tool to specify their requirements in IFML, validate their model with in-browser emulation, generate and deploy the code for a web application or cross-platform mobile application, manually evolve the generated code by introducing details like styling or back-end service endpoints, introduce new requirements at the model level and integrate the newly generated code into the code-base preserving the manually applied changes.

2 Background: The Interaction Flow Modeling Language

IFML (Interaction Flow Modeling Language [3]) is an OMG standard that supports the platform-independent description of graphical user interfaces (UIs) for devices such as desktop computers, laptops, mobile phones, and tablets. IFML focuses on the structure and behavior of the application as perceived by the end user, and references the data and business logic aspects insofar they influence the users experience, i.e., the domain objects that provide content displayed in the interface and the actions triggered from the interface. IFML allows developers to specify the following aspects of an interactive application:

  • The view structure and content: the general organization of the interface is expressed in terms of ViewElements, along with their containment relationships, visibility, and activation. Two classes of ViewElements exist: ViewContainers, i.e., elements for representing the nested structure of the interface, and ViewComponents, i.e., elements for content display and data entry. ViewComponents that display content have a ContentBinding, which expresses the link to the data source.

  • The events: the occurrences that affect the state of the user interface, produced by the users interaction, the application, or an external system.

  • The event transitions: the consequences of an event on the user interface, which can be the change of the ViewContainer, the update of the content on display, the triggering of an action, or a mix of these effects. Actions are represented as black boxes.

  • The parameter binding: the input-output dependencies between ViewElements and Actions.

3 Work-Flow of the Demo

The demo will allow attendees to experience all the operations required to generate a prototype application. As a starting example, we have prepared a multimedia player application; its model is shown in Fig. 1a and comprises a single page, with three components: a list, which shows the available songs, and two details that represent the media player status and allow the user to start and stop the selected song.

Fig. 1.
figure 1

Model editing and generated code customization

Full size image

IFML Model Editing. During the demo, users will compose the model of Fig. 1a, or a model of their choice, using the integrated editor. IFML elements are inserted in the model by means of drag&drop from a palette on the left side.

Code Generation. The developer can generate a fully functional prototype launching a model-to-code transformation. Figure 1b shows the generated web prototype, run on top of a client emulator inside the browser. In-browser emulation allows the developer to test the current web or mobile release of the prototype without installing any web server and also in absence of the Internet connection. The developer can evaluate different application structures (e.g., single vs multiple pages) and interaction approaches (e.g., update on object selection vs explicit update events) before the final code download.

Manual Code Editing. Once the generated code is downloaded, the developer can modify it in order to: (1) connect data sources to existing data provisioning service endpoints; (2) introduce business logic, editing the code that implements the Actions skeletons generated from the IFML model; (3) achieve the desired look and feel by customizing the HTML template files and introducing custom CSS rules. Figure 1b shows the difference between the generated code (upper left, white background) and the customized code (bottom right, black background).

Fig. 2.
figure 2

Model evolution and automatic conflict resolution

Full size image

Model Evolution. After a new requirement, the developer needs to change the original IFML model to introduce new features or change/remove existing ones. Figure 2a shows a possible evolution of the base model with the introduction of a new list that allows the users to filter the songs by author.

Model and Text Co-evolution. The developer can generate a new prototype launching the model-to-code transformation. ALMOsT-Git, an automation tool based on GitFootnote 6, will reapply the previously introduced changes using the new prototype as a starting point. If changes alter the application structure drastically, manual conflict resolution by the developer may be required. Figure 2b shows the result of the procedure.

4 Conclusion

The demo allows attendees to explore the problems of MDD forward engineering, when manual and automatic code updates occur in parallel. IFMLEdit.org, an online tool for the modeling and rapid prototyping of web and Mobile applications based on IFML allows Attendees to try out an application development cycle that allows them to evaluate different variations of an application in a short amount of time, by rapidly modifying the application model and generating realistic prototypes, easily turned into deployable applications.