Chapter 2

IFML in a Nutshell

Abstract

This chapter provides a bird's eye view of IFML. The chapters presents the main language concepts: ViewContainers, ViewComponents, Events, InteractionFlows, Parameters, ParameterBindings and Actions. IFML concepts are referred to the elements of the Model-View-Controller design pattern. These concepts are illustrated in a small, yet complete, example. The chapter also highlights the role and benefits of IFML in the application development cycle.

Keywords

Action; Development Cycle; IFML; Interaction Flow Modeling Language; Model driven engineering; MVC; Model-View-Controller; Parameter; View Component; View Container; User Experience; User Interaction; Software modeling IFML supports the platform-independent description of graphical user interfaces for applications deployed or accessed on systems such as desktop computers, laptops, PDAs, mobile phones, and tablets. The main focus is on the structure and behavior of the application as perceived by the end user. The modeling language also incorporates references to the data and business logic that influence the user's experience. This is achieved respectively by referencing the domain model objects that provide the content displayed in the interface and the actions that can be triggered by interacting with the interface. This chapter introduces the essential features of IFML: its scope, the design rules behind it, its main modeling elements, and its role in the development process. The chapter concludes with an initial example of the language.

2.1. Scope and Perspectives

To understand the aim and scope of IFML better, it may be useful to refer to the well-known Model-View-Controller (MVC) software architecture of an interactive application,1 shown in Figure 2.1. MVC distinguishes the application's internal status and business logic (Model), their representation in the user interface (View), and the rules governing the response to the user's interaction (Controller). IFML mainly describes the view (i.e., the content of the front end and the user interaction mechanisms available in the interface). More precisely, IFML covers various aspects of the user interface: View structure: It expresses the general organization of the interface in terms of ViewContainers, along with their nesting relationships, visibility, and reachability. View content: It specifies what ViewContainers actually contain in terms of ViewComponents (i.e., elements for content display and data entry). ViewComponents that display content are further characterized by a ContentBinding, which expresses the source of the published content. Events: They are the occurrences that affect the state of the user interface. They can be produced by a user's interaction, by the application itself, or by an external system.
Figure 2.1 The Model-View-Controller architecture of an interactive application. Event transitions: They specify the consequences of an event on the user interface, which can be a change of the ViewContainer, an update of the content on display, the triggering of an action, or a mixture of these effects. Parameter binding: It clarifies the input-output dependencies between ViewComponents, view containers, and actions. For the sake of conciseness, IFML condenses all these perspectives within only one diagram type called an Interaction Flow Diagram. This is in contrast to other modeling languages such as UML, which rely on multiple diagrams for conveying the various facets of an application. Besides describing the view part of the application, an IFML Interaction Flow Diagram also provides the hooks to connect it with the model and controller parts: With respect to the controller, IFML represents the effects of the user's interactions. It defines the events produced in the view and the course of action taken by the controller in response to them, such as triggering a business component and updating the view. With respect to the model, IFML describes the data binding between the interface elements and the objects that embody the state of the application, as well the actions that are triggered by the user's interactions. Figure 2.2 shows as an initial example the IFML model of a simple interface: the view structure consists of three ViewContainers ("ProductCategories," "ProductOfCategory," and "ProductInformation"), which reflect the top-level organization of the GUI in three distinct pages. The model shows the content of each ViewContainer. For example, the "ProductCategories" ViewContainer comprises one ViewComponent called "CategoryList." This notation represents the content of the respective page in the GUI (i.e., a list of product categories). Events are represented in IFML as circles. The "SelectCategory" event specifies that the "CategoryList" component is interactive. In the GUI, the user can select one of the categories to access a list of its products. The effect of the "SelectCategory" event is represented by the arrow emanating from it (called InteractionFlow in IFML), which specifies that the triggering of the event causes the display of the "ProductOfCategory" ViewContainer and the rendering of its "ProductList" ViewComponent (i.e., the list of products of the selected category). The input-output dependency between the "CategoryList" and the "ProductList" ViewComponents is represented as a parameter binding (the IFML ParameterBindingGroup element in Figure 2.2). The value of the "SelectedCategory" parameter, which denotes the object selected by the user in the "CategoryList" ViewComponent, is associated with the value of the input parameter "Category," which is requested for the computation of the "ProductList" ViewComponent.
Figure 2.2 Example of an interface and its IFML specification.

2.2. Overview of IFML Main Concepts

An IFML diagram consists of one or more top-level ViewContainers (i.e., interface elements that comprise components for displaying content and supporting interactions). Figure 2.3 contrasts two different organizations of the GUI: (a) an e-mail application (desktop or rich Internet application) consisting of a top-level container with embedded sub-containers at different levels, and (b) an e-commerce web site that organizes the user interface into different independent view containers corresponding to page templates. Each view container can be internally structured in a hierarchy of subcontainers. For example, in a desktop or rich Internet application, the main window can contain multiple tabbed frames, which in turn may contain several nested panes. The child view containers nested within a parent view container can be displayed simultaneously (e.g., an object pane and a property pane) or in mutual exclusion (e.g., two alternative tabs). In the case of mutually exclusive (XOR) containers, one could be the default container, which is displayed by default when the parent container is accessed. The meaning of a container can be specified more precisely by adding a stereotype to the general-purpose construct. For instance, a ViewContainer can be tagged as «window», as in the case of the "Mail" ViewContainer in Figure 2.4, to hint at the nature of its expected implementation.
Figure 2.3 Example of different top-level interface structures.
Figure 2.4 Example of mutually exclusive subcontainers. In Figure 2.4, the "Mail" top-level container comprises two subcontainers, displayed alternatively: one for messages and one for contacts. When the top level container is accessed, the interface displays the "Messages" ViewContainer by default. A ViewContainer can contain ViewComponents, which denote the publication of content (e.g., a list of objects) or the input of data (e.g., entry forms). Figure 2.5 shows the notation for embedding ViewComponents within ViewContainers. The "Search" ViewContainer comprises a "MessageKeywordSearch" ViewComponent that represents a form for searching; the "MailBox" ViewContainer comprises a "MessageList" ViewComponent that denotes a list of objects.
Figure 2.5 Example of ViewComponents within view containers. A ViewComponent can have input and output parameters. For example, a ViewComponent that shows the details of an object has an input parameter corresponding to the identifier of the object to display. a data entry form exposes as output parameters the values submitted by the user. and a list of items exports as output parameter the item selected by the user. A ViewContainer and a ViewComponent can be associated with events to express that they support user interaction. For example, a ViewComponent can represent a list associated with an event for selecting one or more items, a form associated with an event for input submission, or an image gallery associated with an event for scrolling though the gallery. IFML events are mapped to interactors2 in the implemented application. The way in which such...