cosc 3461: module 8
DESCRIPTION
COSC 3461: Module 8. Model-View-Controller (MVC) Architecture. 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. …. - PowerPoint PPT PresentationTRANSCRIPT
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