COSC 3461: Module 8

1. COSC 3461: Module 8 Model-View-Controller (MVC) Architecture

2. The “Traditional” Architecture • Applications are designed so that they will appropriately respond to the user’s • requests • queries • commands Input  Processing  Output These form the set of possible inputs …

3. An Alternative • The application: • has a model • provides views of the model, each of which has its controller • the actions that the user can perform depend on the view • We still have: Input  Processing  Output • Input done with respect to a view • Controller detect user actions and make changes to model • Model notifies views about changes • Views are updated by controllers • The controllers mediate between the views and the model

4. Advantages • Independence of the model and views • Can have multiple views simultaneously open • Can create additional views without modifying the model • Can create nested views without modifying the model • Can enhance and/or optimize model without changing the views • Easy to change “look and feel” of views

5. Advantages • Enforces Object Oriented (OO) approach • Ensures modularity of software components • Improves maintainability • Promotes code reuse

6. Disadvantages • Can be complex • Initial design of model is crucial

7. Design Principle • The basis for the architecture of an application should be its data (rather than on its user interface) • Rationale: • Modifications to the interfaces do not warrant changes to the underlying architecture • Entirely new interfaces can be developed on top of existing data models • The interface: • provides a way for the user to view of the data • affords the means to perform actions on the data (e.g., modify, update) , given a particular view …

8. Support for the Design Principle • Need a software architecture to support the separation of the application data and the application’s user interface • Types of architectures: • Model-View-Controller (MVC) architecture • Modified MVC architecture • Quasi-MVC architecture • Separable Model (SM) architecture

9. Historical Notes • The model-view controller (MVC) architecture was first introduced as the architecture for Smalltalk • The Smalltalk environment: • was used to create the first graphical user interfaces • provided support for multiple windows • was developed at the Xerox Palo Alto Research Center (“Xerox PARC”) • didn’t employ the traditional approach to application programs • provided an approach that was subsequently adopted by other designers (e.g., the Apple Macintosh)

10. Historical Notes • The modified model-view controller (MVC) architecture was developed by Swing developers • See: • Fowler, Amy. ”A Swing Architecture Overview: The Inside Story on JFC Component Design”

11. MVC Schematic Display View Model Controller Keyboard Mouse Etc.

12. Types of Models • GUI-data models (or GUI-state models) • the views of these models primarily concern look-and-feel of components and their states • Application-data models • quantifiable data that has meaning primarily in the context of an application • can be organized in various ways • e.g., lists, tables, trees • the views of these models can vary with respect to which subset of the data is shown and how • more than just look-and-feel

13. Examples of Models • GUI-data models (or GUI-state models) • the model for a button component (ButtonModel) or a slider (BoundedRangeModel) • model contains the set of attributes and their current states, also the look and feel • Application-data models • in a bank teller application: • The set of bank accounts open at a bank; • All of the information associated with each of the bank accounts • The set of account holders • in a digital circuit simulation application: • the set of all chips (e.g., OR, AND, XOR) • all the information about their interconnections

14. Tasks for the Model • Store and manage data elements • e.g., state information such as the current position of a slider, or whether a button is latched or not • Provide methods so that queries about its state can be performed • Provide methods so that various attributes of its state can be modified

15. Tasks for the Controller • Receive user inputs from mouse and keyboard • Consult the view to determine which objects are being manipulated by the user • Update the model accordingly • Example controller actions: • detects a mouse click; • determines that a button has been pressed and that pressing a button toggles a state; • informs the model that the button state has changed

16. Tasks for the Views • Implements a visual display of the model • Visual displays can vary • presented as text, in rows and columns • presented as a graphic (e.g., bar chart)

17. The Views • A model can have any number of views • the views subscribe to the model • Views can differ: • how they present information from the model • what operations the users can perform

18. Example of Views (1) • Bank teller application: • The bank teller view • The loan officer view • The bank machine view • Digital Circuit Simulation application: • The circuit view • The parts view

19. Example of Views (2) • A Check Box: • The Windows view • The Metal view • The Motif view • GUI Components: • can think of them as very small, limited applications • they have a model and views • the views differ with respect to “look-and-feel” (superficial differences)

20. Multiple Views View #1 Check Box Model View #2 View #3 Any number of views can subscribe to the model

21. Application-data Models in Swing • In Swing, models exist as interfaces • The interface is implemented in model classes • Usually there is a default model class that is automatically associated with a component

22. Types of Application-data models... • ListModel • implemented by AbstractListModel • JList uses DefaultListModel, JComboBox uses DefaultComboBoxModel (both extend AbstractListModel) • TableModel • implemented by AbstractTableModel • AbstractTableModel extended by DefaultTableModel • used by JTable • TreeModel • implemented by AbstractTreeModel • default model of JTree • Document • implemented by AbstractDocument • AbstractDocument extended by PlainDocument • default model of JTextField

23. Views • A data model can have any number of views • A view subscribes to the model • if the model changes, all subscribing views automatically update themselves • Views can differ: • which subset of the data is presented • how the data is presented • what operations are available to the users to perform

24. Example of Views (1) • Bank teller application: • The data model is a database of all the bank’s customers and the accounts or services used by each customer • The bank teller view: • user can view accounts of any person; can modify the balance of any account. • The loan officer view: • user can view all accounts, can retrieve credit history, can open a new account (loan, line of credit), can transfer amounts between accounts. • The bank machine view: • user can view account information for a particular person; can deposit, withdraw, transfer for that person’s account

25. Example of Views (2) • Digital Circuit Simulation: • The data model is a list of all of the chips in the circuit and the connections (wires) between them • The circuit view: • the user sees a graphical layout of the entire circuit; can add, change, or remove chips; can change the wire connections • The parts view: • the user sees a list of all the different types of chips (and a count for each one) and an estimate of the amount of wire the circuit, if implemented, would use; can print the list out

26. Multiple Simultaneous Views Each view must ensure that its appearance reflects the state of the model. The controllers mediate between the views and the model

27. Table Models and Their Views • An instance of a TableModel has: • cells, arranged in columns and rows • the values of the cells are instances of Object • An instance of a JTable has: • an underlying data model, an instance of a TableModel • an instance of a TableModelListener, which is installed on the instance’s TableModel • NOTE! There is nothing to stop you from (1) creating another instance of a JTable, and (2) assigning it’s data model to be the same instance of TableModel above

28. Custom Table Models • Suppose we create an instance of a customized TableModel • instances of JTable that uses that instance as its data model • This is done in example DemoTableModel.java • Note: • The JTable’s data model is an instance of OurCustomTableModel • when we modify a cell of the JTable, the setValueAt method of OurCustomTableModel is invoked • THIS CAUSES THE DATA MODEL TO BE UPDATED • Also, setValueAt causes a TableModelEvent to be generated • The TableModelListener that is associated with the JTable (and is installed on OurCustomTableModel) receives this event, the tableChanged method is invoked • THIS CAUSES THE VIEW TO BE UPDATED

29. Example DemoTableModel.java

30. Subscribe-Notify • Suppose the model changes… How does the system ensure that all the other views reflect the updated model? • The application follows the subscribe-notify protocol. • The model notifies each subscribed view that it has changed. • Two types of notification: Lightweight, Stateful • Each view then has the opportunity to update itself.

31. Lightweight Notification 3) Request CONTROLLER VIEW 4) Data 1) Update 2) Notify MODEL • Controller detects user action • Controller tells the Model to change (1) • Model says “I changed” • The notification doesn’t say how • Model notifies each View of this (2) • Views that need to update ask the Model for data (3) • The Model sends the data to the requesting Views (4)

32. Stateful Notification CONTROLLER VIEW • Controller detects user action • Controller tells the Model to change (1) • Model says “I changed, and I changed in this way” • The notification includes all necessary information for the View to update itself. • Model notifies each View of this (2) 1) Update 2) Notify MODEL

33. Lightweight vs. Stateful Notification • Lightweight notification • A single event instance can be used for all notifications • Desirable when notifications are frequent • Stateful notification • A different event instance for each notification • Desirable for complex models

34. MVC and Swing • Swing designers found it difficult to write a generic controller that didn’t know the specifics about the view • They collapsed the view and controller into a single user interface object • UI delegate • UI Object • UI delegate object • Delegate object • The UI is delegated to this object

35. MVC and Swing (2) Swing component Display UI delegate View Model Controller Keyboard Mouse Etc.

36. How to Ignore Models • Many applications need not worry about models • Most component classes provide the model API directly • Example from code that implements JSlider class:public int getValue() { return getModel().getValue(); } • Applications that use JSlider can simply:JSlider slider = new JSlider(); int value = slider.getValue();

37. Recall Data Model Validation DemoInputValidation3.java JTextField’s default data model is PlainDocument. We can create a custom data model for a JTextField by creating our own data model and substituting it for PlainDocument

38. Multiple Views DemoTwoViews.java

39. Example: Radio Button • The attributes of a Radio Button are defined in ButtonModel • It is an interface defined in Swing • It has a default implementation: DefaultButtonModel

40. Example: Radio Button • Did you notice? • the ButtonModel (the model of a Radio Button) doesn’t say anything about how the radio button should appear! • The Swing code for JRadioButton and JRadioButtonMenuItem take care of the appearance of DefaultButtonModel • Swing components, in general, take care of the appearance of their corresponding, underlying data models

41. Example: Radio Button • The instances of JRadioButtonMenuItem are “interested parties” • if the ButtonModel changes, they want to know about it • e.g., if the state changes to selected, then appearance of models needs to be updated • The Swing components take responsibility for hooking up the appropriate listeners and for repainting themselves when the model changes • The ButtonModel doesn’t know anything about the entities that are interested in it • It only knows that there are interested parties • Keeps a list of listeners that are interested in knowing when its state has changed