• Abstract and Figures
• Public Full-text

Improving modularity of interactive software with the MDPC Architecture Stéphane Conversy, Eric Barboni, David Navarre, Philippe Palanque To cite this version: Stéphane Conversy, Eric Barboni, David Navarre, Philippe Palanque. Improving modularity of in- teractive software with the MDPC Architecture. EIS 2007, Engineering Interactive Systems Joint Working Conference, Mar 2007, Salamanca, Spain. pp 321-338, 10.1007/978-3-540-92698-6. hal- 01021985 HAL Id: hal-01021985 https://hal-enac.archives-ouvertes.fr/hal-01021985 Submitted on 4 Sep 2014 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Improving modularity of interactive software with the MDPC architecture Stéphane Conversy1,2, Eric Barboni2, David Navarre2 & Philippe Palanque 2 1 ENAC – Ecole Nationale de l’Aviation Civile 7, avenue Edouard Belin, 31055 Toulouse, France. [email protected] 2 LIIHS – IRIT, Université Paul Sabatier 118 route de Narbonne, 31062 Toulouse Cedex 4, France {barboni, conversy, navarre, palanque}@irit.fr http://liihs.irit.fr/{barboni, navarre, palanque} Abstract. The “Model - Display view - Picking view - Controller” model is a refinement of the MVC architecture. It introduces the “Picking View” component, which offloads the need from the controller to analytically compute the picked element. We describe how using the MPDC architecture leads to benefits in terms of modularity and descriptive ability when implementing interactive components. We report on the use of the MDPC architecture in a real application: we effectively measured gains in controller code, which is simpler and more focused. Keywords: MVC, interactive software, modularity, Model Driven Architecture 1 Introduction Modularity is an aspect of software engineering that helps improve quality and safety of software: once designed, implemented, and verified, modular components can be reused in multiple software so that such software can rely on their soundness. The advent of rich interaction on the web, and the advent of WIMP interaction in airplane cockpits [1][2] raise interest in interactive software architecture. The need to use, develop, and extend toolkits for interaction makes programmers eager to study this area. Similarly, a number of widgets have been formally described, so as to comply with important properties of interactive systems [14]. As a toolkit programmer point of view, reusing these components would ensure that his particular implementation complies with the same properties. Separation of concerns is a design principle that can help to achieve modularity: the idea is to break a problem into separate sub-problems and design software components that would handle each sub-problem. The Model-View-Controller (MVC) architecture is a well-known attempt to improve modularity of software [18] through separation of concerns (cf Fig. 1). In MVC, the Model encapsulates the data to be interacted with, the View implements the graphical representation and is updated when the Model changes, and the Controller translates actions from the user to operations on the Model. MVC has been successfully applied to high-level interactive components, though in this form it resembles more to the PAC architecture than its original description [6]. For example, frameworks to help develop interactive application, such as Microsoft MFC, organize the data structure in a document, and views on the document that are updated when the document changes. When applied to very low-level interactive components though, such as scrollbars, programmers encounter difficulties to clearly modularize the components so that the original goal of reusing components is reached: the View and the Controller components of the widget are so tightly coupled that it seems useless and a waste of time to separate them, as they cannot be reused for other interactive widgets1. Fig. 1: MVC: The controller queries the view to know which part of the view has been clicked in order to react accordingly. We argue in this paper that by externalizing the picking concern from the Controller, we can actually modularize a set of interactive widgets so that the Controller can be reused across different classes of Views of the same model. We first present the causes of the problem mentioned above. We then introduce the Model – Display view – Picking view – Controller (MDPC) architecture, and show with examples how to use it. We then report our experience at refactoring a real application with the MDPC model. 2 The need to externalize Picking At its lowest level, today's interactions usually involve a rasterized image (i.e. a digital/sampled/pixel-based image) and a pointer that the user controls to point at a given pixel. Rendering is the process of transforming a logical description or the conceptual model of an interactive component to a graphical representation or a perceptual model. Picking can be considered as the inverse process of rendering: 1 As stated by the designers of JAVA Swing: “We quickly discovered that this split didn't work well in practical terms because the view and controller parts of a component required a tight coupling (for example, it was very difficult to write a generic controller that didn't know specifics about the view). So we collapsed these two entities into a single UI (user-interface) object […]”.http://java.sun.com/products/jfc/tsc/articles/architecture/#roots Picking is the process of determining/querying the graphical primitives that colored/filled a given pixel, and in turn the corresponding conceptual entity. Usually, interactive systems use the pixel underlying the cursor, in order to react when the user clicks on an interactive component. Picking is also used during passive movements, for example to determine when the cursor enters an interactive component so as to highlight it. trough thumb arrow Fig. 2: a scrollbar and its parts For the remaining of this section, we take the scrollbar as an example (Fig. 2). A scrollbar is an instrument that enables a user to specify the location of a range by direct manipulation. For example, the user can use a scrollbar to modify the position of the view of a document too large to be displayed at once. Conceptually, a scrollbar is composed of four parts: a thumb to control the position of a range of values, a trough in which the user can drag the thumb, i.e. the position of the thumb is constrained inside the trough, and two arrows for decrementing/incrementing the position of the thumb by a fixed amount. if( (event.y > y_up_widget) and (event.y < y_bottom_widget) { // test if it is in the widget if (event.y < y_up_widget+harrow) { // scroll down by one line ... } else if (event.y<ythumb) { // scroll down by one viewing area } else //...and so on Fig. 3: An example of code using analytic picking In the original form of MVC, the Controller usually handles picking by receiving low-level events such as mouse clicks or mouse moves. For example, if the user clicks in the image of a scrollbar for a text editor document, the Controller computes which part of the view has been clicked on, and calls a particular method of the Model with a computed parameter: if the part is one of the arrows, the Controller sets the Model's value by decreasing or increasing it by an amount equivalent to that of one line. If the part is the space between the thumb and the arrows, the amount is equivalent to that of one viewing area. In order to determine the part that has been clicked on, the Controller must know the layout of the widget parts, i.e the location of parts that are displayed on the screen [15]. For example, with a vertical scrollbar, if the upper ordinate of the widget is ywidget, the height of an arrow is harrow, and the upper ordinate of the thumb is ythumb, a Controller can determine which part has been clicked on by using the code in Fig. 3. The code is embedded into the method that reacts to the click on the view. This prevents modularization of the controller: it is specially designed for one particular view, even if some of the values can be parameterized, such as the location of the whole widget. In particular, the relative layout of the different parts of the widget is often hard-coded, and is not a parameter of the widget. In fact, most interactive widgets are structured around parts that embody a spatial mode of interaction i.e. a same event in two different parts lead to two different behaviors of the widget. For example, clicking in an arrow triggers a different action than the one corresponding to clicking in the thumb. In a part, the action triggered by an event is the same regardless of the parameters of the event. Only the parameters of the action may depend on the dimensions of the event. What is important then to implement part-dependant code, is not the low level parameters of events such as the x and y coordinates, but the part on which the event took place. Thus, the Controller behavior must be dependant on parts below the cursor, and not the cursor’s x and y position, so that the code that describes it would resemble to code in Fig. 4. if( isin(event, scrollbar)) { // test if it is in the widget if (isin(event,uparrow)) { // scroll down by one line ... } else if (isin(event,thumb)) { // scroll down by one viewing area ..

Load more

  19

Copy Link