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

KeyboardMouse

Etc.Controller

View

Model

Display

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

Any number of views can subscribe to the model

CheckBox

Model

View #1

View #2

View #3

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

CONTROLLER

VIEW

MODEL1) Update

2) Notify4) Data

3) Request

Lightweight Notification

• 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 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)

CONTROLLER

VIEW

MODEL1) Update

2) Notify

33

• 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

Lightweight vs. Stateful Notification

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)

KeyboardMouse

Etc.Controller

View

Model

Display

Swing component

UI delegate

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