An architecture with historical impact

1
Model-View-Controller

• An architecture with historical impact

2
Agenda

• Questions
• Layered versus Object architectures
• MVC basics
• Components
• Dynamics
• Related O-O design patterns
• PAC

3
Review

• Compiler mentality (layers)
• Lexical/Syntactic/Semantic
• Seeheim, ARCH
• Object mentality (cooperating agents)
• Interface as collection of objects
• PAC, MVC

4
MVC motivation

• The UI of an application is subject to many
  changes
• Change of UI for different users
• Same info can be shown in different windows
• Changes to underlying data should be reflected
  quickly everywhere
• Changes to UI should be easy, even at runtime
• Different look and feel should not affect
  functional core
• So separate processing, output, and input

5
MVC

• MVC divides application into
• Model of core functionality and data
• Views displaying information to user
• Controllers handling user input
• Views and Controllers comprise UI
• Change-propagation mechanism ensures consistency
  between Model and UI

6
MVC History

• Invented by Trygve Reenskaug and introduced into
  the Smalltalk-80 programming environment
  developed at Xerox PARC.
• Elements of MVC appear in many modern GUIs (MFC,
  Swing, )
• More info
• Buschmann et al. (1996) Pattern-Oriented Software
  Architecture. John Wiley Sons, pp. 125-143.

7
The MVC triad

• Each piece is an object

UI
8
Model

• Encapsulates application-specific data and
  functionality, providing
• methods to edit data, which Controller can call
• methods to access state, which View and
  Controller can request
• Maintains registry of dependent Views and
  Controllers to be notified about data changes

9
Model Examples

• text editor model is text string
• slider model is an integer
• spreadsheet collection of values related by
  functional constraints

10
View

• Mechanism needed to map model data to rendition
  (view / display)
• When Model changes, View is informed
• View requests relevant model information
• View arranges to update screen
• Declare damaged areas
• Redraw when requested

11
View Examples

• Slider text-field, line with bead, temp. gauge
• Spreadsheet
• Tabular representation
• Bar chart
• Histogram

12
Controller

• Accepts user input events
• Translates events into methods invoked on Model
• Activates/Deactivates UI elements (graying)

13
Controller Examples

• Textual commands
• Mouse (point and click) commands
• No input

14
MVC Dynamics

• 1. User input event routed by Window System to
  appropriate Controller.
• 2. Controller may require View to pick object
  of focus for event.

V
M
C
15
MVC Dynamics

• 3. Controller requests method of Model to change
  its state.
• 4. Model changes its internal state

V
M
C
16
MVC Dynamics

• 5. Model notifies all dependent Views that data
  has changed.
• 6. View requests from Model current data values.

V
M
C
17
MVC Dynamics

• 7. Model notifies all dependent Controllers that
  data has changed.
• 8. Controller requests from Model current data
  values.

V
M
C
18
MVC Dynamics

• 9. Controller informs View if elements are
  disabled.
• 10. View requests redraw

V
M
C
19
View Controller linking

• Controller almost always has to talk to view
• need geometry of output to interpret input (e.g.,
  picking)
• need to do feedback
• As a result, VC tend to be very tightly coupled,
  and considered as one
• M(VC)
• Tooks surface is a complex V-C

20
Multiple UIs

• Multiple View/Controller pairs can be attached to
  a single Model
• For explanation purposes, we depicted only one
  View/Controller pair.

21
MVC Pros and Cons

• Pro
• Multiple views of same model
• Synchronized views
• Pluggable V C and look and feel
• Con
• Complexity for simple interactors
• Potentially excessive updates/messages
• Tight coupling, in practice (V-C, VC-M)
• Lack of portability
• Some toolkits make MVC framework hard

22
Common OO Design Pattern

• MVC change-propagation mechanism should be
  familiar
• Observer pattern
• Publisher-Subscriber pattern
• Dependent objects loosely coupled
• Why Model only announces change to View and then
  View requests current values.

23
The PAC Model

• A hierarchy of cooperating agents, each
  responsible for a specific aspect of an
  application, consisting of
• Presentation
• Abstraction
• Control
• Coutaz, 1985 (see Bushman et al. 1996, pp.
  145-168)

24
The PAC triad
P VC
A M
User
C coordinates A-P and
25
The PAC Hierarchy
top element core app, no P
A
P
C
26
The PAC Hierarchy
A
P
C
middle element aggregate/coordinate
27
The PAC Hierarchy
A
P
C
bottom elements self-contained interactors