Download Human-Computer Interactive and more Lecture notes Human-Computer Interaction Design in PDF only on Docsity!
IT86A-HUMAN COMPUTER INTERACTION
Page | 103 INTERACTIVE SYSTEME DEVELOPMENT FRAMEWORK Topic:
1. Model, View, and Controller (MVC)
a. Model
b. View
c. Controller
d. View/Controller
Learning Outcomes:
• Discuss the principle of MVC.
• Demonstrate interactive application development using MVC.
Introduction Obviously, a complete application consists not only of UI objects, but those for the core functions of the application as well. How do we effectively develop the larger interactive programs with two such parts (i.e., UI and internal functional core)? It is a good idea to follow an established development framework or methodology suited for highly interactive systems. A development framework refers to a modular approach for interactive program development where the core computational and interface parts are developed in a modularized fashion and combined in a flexible manner. Such a development framework is often based on the UI toolkit, which provides the abstraction for the interface parts. The framework allows the concept of plugging in different interfaces for the same model computation and easier maintenance of the overall program. In addition, such a practice also promotes the productivity as well as easier and less costly post maintenance. MVC (model, view, and controller) is one such major framework. **Content
- Model, View, and Controller (MVC)** The MVC approach was first proposed as a computational architecture for interactive programs (rather than a methodology) by the designers of the programming language called SmallTalk, which is one of the first object-oriented and modular languages [2]. The modular nature of the MVC architecture naturally shaped the interactive program development style or
IT86A-HUMAN COMPUTER INTERACTION
Page | 104 methodology. With the MVC framework, the application is divided into three parts: (a) model, (b) view, and (c) controller, as illustrated in Figure 7.1. The model part of the application corresponds to the computation (e.g., realized as objects) that deals with the underlying problem or main information or data of the application. For all practical purposes, once in place, a model of the application tends to be stable and unchanging. For instance, in an interactive banking application, the model will be parts of the program that maintain the balance, compute the interest, make wire transfers, etc. The model has no knowledge of how the central information will be presented to the user (output/presentation) or how the transactions (input) are made. 2) View The view part of the application corresponds to the implementation for output and presentation of data. In modern GUI-based interfaces, the implementation will typically consist of widgets. For instance, views might be windows and widgets that display the list of transactions and the balance of a given account in a banking application, or they might play a background audio clip depending on the score level for a game. As a whole, there may be multiple views for a single application (or model). For instance, there could be different view implementations for different display platforms or user groups (e.g., 17 - in. monitor, 10 - in. LCD, HD resolution display, display with vibrotactile output device, young users, elderly users). Note that the output display does not necessarily have to be visual. Anytime the model is changed, the view of that model must be notified so that it can change the visual representation of the model on the output display. The region/portion of the
IT86A-HUMAN COMPUTER INTERACTION
Page | 106 (view/controller) for the same core functional model. This is based on a famous software engineering principle: the separation of concern. Example of MVC Implementation 1: Simple Bank Application We illustrate a very simple object-oriented implementation for an interactive banking application. In this simple application, the model maintains the balance for a user who can make deposits or withdrawals through a computer UI. Figure 7.2 shows the overall structure of the application according to the MVC architecture. In Figure 7.2, as for the model part, a class called Account maintains the customer name, balance, and two views/controllers (one for displaying the balance and realizing the UI for making deposits, and the other for withdrawal). The model has two core methods for maintaining the correct balance when a deposit (Account::Deposit) or withdrawal (Account::Withdrawal) is made. These two methods use the Notify_depositVC and Notify_withdrawalVC to notify the corresponding view to update the balance in the display. In this particular example, the View and Controller parts are merged into one class, called the AccountViewController, which has a pointer to the corresponding model object (as the recipient of the notifications and model change queries). This class is a subclass of a more general UIObject that is capable of housing constituent widgets and reactive behavior to external input. It is also the superclass for subclasses, the DepositViewController and WithdrawalViewController, which implement the two views/controllers for the given model.
IT86A-HUMAN COMPUTER INTERACTION
Page | 107 The subclasses, among others, implement three important virtual methods: Init_ui_display, Update_ui_display, and Handle_ui_event (Figure 7.2). Each of these is responsible for creating and initializing the display and UI objects within the view/controller, updating the display (invoked by the notification method from the model, as seen in Figure 7.3) and handling the user input. Figure 7.4 shows the Handle_ui_event method of the DepositViewController that interprets the user input (e.g., textual input of digits into integers) and invokes the model method, for example, to make a deposit by calling my_model-
Deposit(deposit_amount). Understand that this will eventually change the model, and the view/controller will be notified to change its display (e.g., to show the proper amount of balance after the deposit). Although not shown, the WithdrawalViewController would be coded in a similar manner.
IT86A-HUMAN COMPUTER INTERACTION
Page | 109 Example of MVC Implementation 2: No Sheets As a second example, we will illustrate parts of the implementation code for the No Sheets application introduced in Chapter 4, as shown in Figure 7.5. The core of the model is music information, a list-based data structure that contains the chord information for a piece of music that is read from a user-selected file. Aside from the music information itself, there may be other model variables such as the music file name, tempo value, etc. Thus, the model information is updated by and read from the view/controller objects.
IT86A-HUMAN COMPUTER INTERACTION
Page | 110 The view/controller is composed of several Activity (screen interface) objects. The SmartChordActivity represents the main front-end interface, which allows the user to apply certain major actions such as selecting/loading the music file, selecting the tempo, playing the chosen music file, and other miscellaneous functions. It will access information from the model—for instance, the name of the current file and current tempo—and show them in the interface. FileActivity represents the file-selection interface screen, which presents the user with a list of available music files. The user makes a selection, and the FileActivity will construct the internal chord-event list and update the model. Likewise, TempoActivity allows the user to select the tempo and update the model accordingly. Finally, the PlayActivity accesses the event-list data structure of the model and presents the musical information at a given tempo (no model updating is carried out). Self-Assessment Question:
- Visit the Link below: https://www.youtube.com/watch?v=Q1ulPB4A6dM&pbjreload=
- Watch the tutorial and create your first ASP.NET MVC using Visual Basic & VS2019. Summary In this chapter, we have studied one interactive application development methodology called the MVC, which is based on the principle of the separation between the UI and core computational functionalities of a given application. Such a separation of concerns allows for the two to be mixed and matched (for exploring different combinations of a proper set of functions and corresponding UIs) and lends itself to easier code maintenance. However, sometimes it is not very clear whether a given application can be cleanly separated into two parts, namely, the core function and UI. For example, suppose one is to implement several different “views” for different user groups for the same banking application, and yet another view for changing and selecting the views themselves. In this situation, it seems that the change-of-view functionality is one of the core functions and features of the application, yet in theory, the “view change” seems to belong to the View rather than the Model.
