Transcript Model-View-Controller

Architectural Patterns
Yasser Ganji Saffar
[email protected]
1
What are patterns?





A pattern addresses a recurring problem that
arises in specific design situations and presents a
solution to it.
Patterns provide a common vocabulary and
understandings for design principles
Patterns are a means of documenting software
architecture
Patterns help you manage software complexity
Patterns help you build on the collective
experience of skilled software engineers.
2
Patterns Categories
Architectural Patterns
 Design Patterns
 Language Idioms

3
Architectural Patterns
An architectural pattern expresses a
fundamental structural organization
schema for software system.
 It provides a set of predefined subsystems,
specifies their responsibilities, and includes
rules and guidelines for organizing the
relationship between them.

4
Architectural Patterns Categories

From mud to structure




Interactive systems



Model-View-Controller (MVC)
Presentation-Abstraction-Controller (PAC)
Adaptable systems



Layers
Pipes and Filters
Blackboard
Microkernel
Reflection
Distributed systems

Broker
5
Pattern Specification




Name
Also Known As
Example
Context


Problem


A situation giving rise to
a problem
The recurring problem
arising in that context
Solution

Structure



Dynamics





Components
Relationships
Scenarios
Implementation
Variants
Known Uses
Consequences
6
Layers

Helps to structure applications that can be
decomposed into groups of subtasks in which
each group of subtasks is at a particular level of
abstraction
Useful System
Basic Utility
Core level
7
Layers

Example:

OSI 7-Layer Model
Application
Presentation
Session
Transport
Network
Data Link
Physical
8
Layers

Context:


A large system that requires decomposition
Problem:

A system whose dominant characteristic is a
mix of low and high level issues, where high
level operations rely on lower-level ones.
9
Layers

Solution


Structure your system into an appropriate
number of layers and place them on top of
each other
Start at the lowest level of abstraction and
move up to the top level of functionality
10
Layers

Structure
Class
Layer J
Collaborator
Layer J-1
Responsibility
Provides services
used by Layer J+1
Delegates subtasks to
Layer J-1
11
Layers

Variants

Relaxed layered system




More Performance & Flexibility
Less Maintainability
Can be used in infrastructure systems such as X
Window System that are modified less than
application systems and performance is more
important than maintainability
Layering through inheritance


A higher level inherits from a lower level
implementation
Higher levels can modify lower layer services
12
Layers

Known Uses

Information Systems

4 layer architecture:
 Presentation, Application logic, Domain layer, Database

Virtual Machines


e.g. JVM translates Java bytecodes to machinedependent codes
APIs


An API is a layer that encapsulates lower layers of
frequently-used functionality
e.g. C standard library on top of Unix Syscalls
13
Layers

Advantages


Portability
Modifiability


Understandability & Maintainability



Late source code changes do not ripple through the
system
Similar responsibilities are grouped
Reuse of layers
Support for standardization

Clearly-defined and commonly-accepted levels of
abstraction enable the development of standardized
tasks and interfaces
14
Layers

Disadvantages


Lower performance
Difficulty of establishing the correct granularity
of layers


Too few layers → Lower reusability, changeability and
portability
Too many layers → Complexity and overhead in the
separation of layers
15
Pipes and Filters
Provides a structure for systems that
process a stream of data
 Each processing step is encapsulated in a
filter component
 Data is passed through pipes between
adjacent filters

16
Pipes and Filters

Example

Compilers
Program text
Scanner
Token stream
Parser
Abstract syntax tree
Code Generator
Assembly code
Optimizer
Optimized code
17
Pipes and Filters

Context


Processing data streams
Problem




You want to build a system that must process
or transform a stream of input data
The system has to be built by several
developers
The requirements are likely to change
The global system task decomposes naturally
into several processing stages
18
Pipes and Filters

Solution




Divides the task of a system into several
sequential processing steps.
These steps are connected by the data flow
through the system
Each processing step is implemented by a filter
component
Data source, data sink and filters are
connected by pipes
19
Pipes and Filters

Structure
Class
Filter
Collaborator
Pipe
Responsibility
• Gets input data
• Performs a function
on its input data
•Supplies output data
20
Pipes and Filters

Structure
Class
Pipe
Responsibility
• Transfers data
Collaborators
Data Source
Data Sink
Filter
• Buffers data
• Synchronizes active
neighbors (FIFO buffer)
21
Pipes and Filters

Structure
Class
Data Source
Collaborator
Pipe
Responsibility
• Delivers input to
processing pipeline
22
Pipes and Filters

Structure
Class
Data Sink
Collaborator
Pipe
Responsibility
• Consumes output
23
Pipes and Filters

Variants

Tee and Join pipeline systems

Filters with more that one input and/or more that one
output
24
Pipes and Filters

Advantages


No intermediate files necessary
Flexibility



Reuse of filter components


By filter exchange
By recombination
Rapid prototyping
Efficiency by parallel processing

If each filter in a pipeline produces and consumes
data incrementally they can perform their functions
in parallel
25
Pipes and Filters

Disadvantages


Sharing state information is expensive or inflexible
Efficiency gain by parallel processing is often an illusion



Data transformation overhead


Some filters consume all their input before producing any
output
Context-switching between threads or processes is
generally an expensive operation on a single processor
machine
For example if our pipes can only transform ASCII data
Error handling

Because pipeline components do not share any global data
error handling is hard (stderr in Unix)
26
Model-View-Controller





Divides an interactive application into three
components.
Model contains core functionality.
View displays information to the user.
Controller handle user input.
View and Controller together comprise the user
interface.
27
Model-View-Controller

Context


Interactive applications with a flexible humancomputer interface
Problem


Changes to the UI must be easy
Supporting different “look and feel” standards
or porting the UI should not affect code
28
Model-View-Controller

Solution






Model encapsulates core data and functionality. It is
independent of specific output representation or input
behavior
View component obtains the data from the model and
displays them to the user.
There can be multiple views of the model.
Each view has an associated controller component.
Controllers receive inputs (from mouse, keyboard,…)
and translates them to service requests for model or
view
When a user changes the model state via the controller
of one view, all other views should reflect the changes
29
Model-View-Controller

Structure
Class
Model
Responsibility
Collaborators
View
Controller
• Provides functional
core of the application
• Registers dependent
views and controllers
• Notifies dependent
components about data
changes
30
Model-View-Controller

Structure
Class
View
Responsibility
Collaborators
Controller
Model
• Creates and initializes
its associated controller
• Displays information
to the user
• Implements the
update procedure
• Retrieves data from
the model
31
Model-View-Controller

Structure
Class
Controller
Responsibility
Collaborators
View
Model
• Accepts user input as
events
• Translates events to
service requests for the
model or display
requests for the view
• Implements the
update procedure if
required
32
Model-View-Controller
33
Model-View-Controller

Variants

Document-View



Relaxes the separation of view and controller
Sacrifices exchangeability of controllers
Document = Model in MVC
34
Model-View-Controller

Known Uses



MFC in Visual C++
User interface framework in Smalltalk
ET++
35
Model-View-Controller

Advantages



Multiple views of the same model
Synchronized views
Pluggable views and controllers


UI objects can even be substituted at run-time
Portability

Exchangeability of “look and feel”
36
Model-View-Controller

Disadvantages




Increased complexity
Not all views are interested in every change propagated
by the model
Intimate connection between view and controller
Close coupling of views and controllers to a model



Changes to model’s interface impact all views and
controllers
Inefficiency of data access in view
Difficulty of using MVC with modern UI tools

Many high level tools define their own flow of control and
handle some events internally
37
Presentation-Abstraction-Control
PAC defines a structure for interactive
software systems in the form of a
hierarchy of cooperating agents.
 Every agent is responsible for a specific
aspect of the application’s functionality
and consists of three components:
presentation, abstraction and control.

38
Presentation-Abstraction-Control

Context


Development of an interactive application with
the help of agents
Problem

Interactive systems can often be viewed as a
set of cooperating agents.




Agents
Agents
Agents
Agents
for human-computer interaction
that maintain the data model
for error handling
for communicating with other systems
39
Presentation-Abstraction-Control

Solution

Structure the interactive application as a tree-like
hierarchy of PAC agents.






Top-level PAC agent
Intermediate-level PAC agents
Bottom-level PAC agents
Presentation component of agents provides the visible
behavior of them
Abstraction component maintains the data model
Control component connects the Presentation and
Abstraction components and provides the functionality
for the agent to communicate with other PAC agents
40
Presentation-Abstraction-Control
Data repository
Access to data
Spreadsheet
Top-level PAC agent
View coordinator
Intermediatelevel PAC agent
Bottom-level PAC agent
Bar chart
Pie chart
Bottom-level PAC agent
41
Presentation-Abstraction-Control

Structure
Class
Top-level Agent
Responsibility
• Provides the
functional core of the
system
Collaborators
Intermediate-level
agent
Bottom-level agent
• Controls the PAC
hierarchy
42
Presentation-Abstraction-Control

Structure
Class
Intermediate-level Agent
Responsibility
• Coordinates lowerlevel PAC agents
Collaborators
Top-level agent
Intermediate-level
agent
Bottom-level agent
• Composes lower-level
PAC agents to a single
unit of higher
abstraction
43
Presentation-Abstraction-Control

Structure
Class
Bottom-level Agent
Responsibility
• Provides a specific
view of the software or
a system service,
including its associated
human-computer
interaction
Collaborators
Top-level agent
Intermediate-level
agent
44
Presentation-Abstraction-Control

Variants

PAC agents as active objects


By using multi-threading all the agents can be active
the same time
PAC agents as processors

Agents located on different processes or on remote
machines
45
Presentation-Abstraction-Control

Advantages

Separation of concerns


Support for change and extension


Different semantic concepts in the application domain
are represented by separate agents
Changes within the presentation or abstraction
components of a PAC agent do not affect other
agents in the system.
Support for multi-tasking

Agents can be distributed easily to different threads,
processes or machines
46
Presentation-Abstraction-Control

Disadvantages

Low efficiency


Overhead in agents communication
Increased system complexity

Implementing every semantic concept with an agent
 A sea of agents

Complex control component

Its interface must be independent of internal details
47
References
Buschmann F., et. al, “Pattern – Oriented
Software Architecture”, John Willey &
Sons, 1996
 Brown K., “Crossing Chasms: The
Architectural Patterns”
 Shaw M., “Patterns for software
architecture”, First annual conference on
the pattern languages of programming,
1994
 Schmidt D., “Inside Patterns”, 2000

48
THE END
49