Architectural Patterns

Introduction
Architectural patterns express fundamental structural organization
schemas for software systems.
They provide a set of predefined subsystems, specify their responsibilities, and
include rules and guidelines for organizing the relationships between them
Architectural patterns represent the highest-level patterns in our pattern
system
Each architectural pattern helps to achieve a specific global system
property, such as the adaptability of the user interface
We group our patterns into four categories
1. From Mud to Structure
2. Distributed Systems
3. Interactive Systems
4. Adaptable Systems
 Introduction : From Mud to Structure
Allows controlled decomposition of an overall system task into cooperating subtasks.
Example: Layering, Pipes and Filters, Blackboard Architecture.

Layers
 The Layers architectural pattern 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.
Pipes an Filters
 The Pipes and Filters architectural pattern provides a structure for systems that process a stream of data.
Each processing step is encapsulated in a filter component.
 Data is passed through the pipes between adjacent filters.
 Recombining filters allows to build families of related systems.
Blackboard
 The Blackboard architectural pattern is useful for problems for which no deterministic solution strategies
is known.
 In Blackboard several specialized subsystems assemble their knowledge to build a possibly partial or
approximate solution.
 Introduction : Distributed Systems
Example: Broker pattern provides the complete infrastructure for distributed
applications.
Micro-kernel and Pipes and Filters are two other patterns referred to by this
category.

Broker
It can be used to structure distributed software systems with decoupled
components that interact by remote service invocations. A broker component is
responsible for coordinating communication, such as forwarding requests as well as
for transmitting results and exceptions.
 Introduction : Interactive Systems
It features human-computer interaction.
Example: MVC, Presentation-Abstraction Control Pattern.

Model-View-Controller
It divides an interactive application into three components. The model contains the core functionality
and data. Views display information to the user. Controllers handle user input. Views and controllers
together forms the user interface. A change propagation mechanism ensures consistency between the
user interface and the model.

Presentation-Abstraction-Control
It 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. This subdivision separates the human computer
interaction aspects of the agent from its functional core and its communication with the other agents.
 Introduction : Adaptable Systems
They support extension of applications and their adaptation to evolving technology.
Example: Reflection and Microkernel pattern.

Microkernel
This pattern applies to software systems that must be able to adapt to changing system requirements. It
separates a minimal functional core from extended functionality and customer-specific parts. The micro-kernel
also serves as a socket for plugging in these extensions and coordinating their collaboration.

Reflection
 This pattern provides a mechanism changing the structure and behavior of software systems dynamically.
 It supports the modification of fundamental aspects, such as type structures and function call mechanisms.
 In this pattern, an application is split into two parts.
 A meta level provides information about selected system properties and makes the software self-aware.
 A base level includes the application logic.
 Its implementation builds on the meta level. Changes to information kept in the meta level affect
subsequent base-level behavior.
Introduction : From Mud to Structure
Layered Architecture  It helps to structure applications that can be
decomposed into groups of tasks
Blackboard It is useful for problems for which no deterministic
solution is known
Pipes and Filters  It provides a structure for systems that process a
stream of data
Introduction : From Mud to Structure
Layers : The layers architectural pattern
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
Networking protocols are probably the
best-known example of layered
architectures
Introduction : From Mud to Structure
It organizes the system as groups of tasks
Each group of task is at a particular level of abstraction (layer)

Each layer
… is client of the lower layer
… provides services to the upper layer
Introduction : From Mud to Structure
The protocol specifies agreements at a variety of abstraction levels,
ranging from the details of bit transmission to high-level application logic
A layered approach is considered better practice than implementing the
protocol as a monolithic block
Introduction : From Mud to Structure
Context: A large system that requires decomposition
Problem: Imagine that you are designing a system whose dominant
characteristic is a mix of low- and high-level issues, where high-level
operations rely on the lower-level ones.
Introduction : From Mud to Structure
Need to balance the following forces
Late source code changes should not ripple through the system
Interfaces should be stable. and may even be prescribed by a standards body
Parts of the system should be exchangeable.
Components should be able to be replaced by alternative implementations without
affecting the rest of the system
It may be necessary to build other systems at a later date with the same low-
level issues as the system you are currently designing
Introduction : From Mud to Structure
Similar responsibilities should be grouped to help understandability
and maintainability
There is no 'standard' component granularity
Complex components need further decomposition
Crossing component boundaries may impede performance
The system will be built by a team of programmers, and work has to be
subdivided along clear boundaries requirement that is often overlooked
at the architectural design stage
Introduction : From Mud to Structure
Solution
Introduction : From Mud to Structure
Solution
Introduction : From Mud to Structure
Solution
Introduction : From Mud to Structure
Dynamics :
Scenario I : A client Issues a request to Layer N. Since Layer N cannot
carry out the request on its own
Scenario II : illustrates bottom-up communication, chain of actions starts
at Layer 1, for example when a device driver detects input
Scenario III : situation where requests only travel through a subset of the
layers
Introduction : From Mud to Structure
Dynamics
Scenario IV : situation similar to Scenario III. An event is detected in Layer
1, but stops at Layer 3 instead of traveling all the way up to Layer N (re-
send request)
Scenario V : involves two stacks of N layers communicating with each
other
Introduction : From Mud to Structure
Implementation : step-wise refinement approach to the definition of a
layered architecture
This is not necessarily the best method for all applications-often a
bottom-up or 'yo-yo' approach is better.
Not all the following steps are mandatory-it depends on your application
Introduction : From Mud to Structure
Define the abstraction criterion for grouping tasks into layers
Determine the number of abstraction levels according to your abstraction criterion
Name the layers and assign tasks to each of them
Specify the services
Refine the layering
Specify an interface for each layer
Sstructure individual layers
Specify the communication between adjacent layers.
Decouple adjacent layers
Design an error-handling strategy
Introduction : From Mud to Structure
Introduction : From Mud to Structure
Variants:
Relaxed Layered System : less restrictive about the relationship between layers, UNIX operating
system or the X Window System
Layering Through Inheritance : object-oriented systems, lower layers are implemented as base classes

Known Uses:
 Virtual Machines  that insulates higher levels from low-level details or varying hardware.
 APIs  is a layer that encapsulates lower layers of frequently-used functionality
 Information Systems (IS)  Presentation, Application logic, Domain layer, Database
 Windows NT  System services, Resource management layer, Kernel, HAL and Hardware
Introduction : From Mud to Structure
Consequences:
The Layers pattern has several benefits
 Reuse of layers
 Support for standardization
 Dependencies are kept local
 Exchangeability

The Layers pattern also imposes liabilities:

 Cascades of changing behaviour
 Lower efficiency
 Unnecessary work
 Difficulty of establishing the correct granularity of layers
Introduction : From Mud to Structure
See Also:
Composite Message
A Microkernel architecture
The PAC architectural pattern

Credits:
Introduction : Pipes and Filters
 The Pipes and Filters architectural pattern 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. Recombining filters allows you to build families of
related systems
Introduction : Pipes and Filters
Context: Processing data streams
Problem: Imagine you are building a system that must process or transform a stream
of input data
Introduction : Pipes and Filters
Consider the following forces
 Future system enhancements should be possible by exchanging processing steps or by
recombination of steps, even by users.
 Small processing steps are easier to reuse in different contexts than large components.
 Non-adjacent processing steps do not share information.
 Different sources of input data exist, such as a network connection or a hardware sensor providing
temperature readings, for example.
 It should be possible to present or store final results in various ways.
 Explicit storage of intermediate results for further processing in files clutters directories and is
error-prone, if done by users.
 You may not want to rule out multi-processing the steps, for example running them in parallel or
quasi-parallel.
Introduction : Pipes and Filters
Solution:
The Pipes and Filters architectural pattern divides the task of a system into several sequential
processing steps. These steps are connected by the data flow through the system-the output data of a
step is the input to the subsequent step

Each processing step is implemented by a filter component.

A filter consumes and delivers data incrementally-in contrast to consuming all its input before
producing any output-to achieve low latency and enable real parallel processing.

 The input to the system is provided by a data source such as a text file.
 The output flows into a data sink such as a file, terminal, animation program and so on.
 The data source, the filters and the data sink are connected sequentially by pipes.
 Each pipe implements the data flow between adjacent processing steps.
 The sequence of filters combined by pipes is called a processing pipeline.
Introduction : Pipes and Filters
Structure:
Filter components are the processing units of the pipeline

A concrete filter implementation may combine any of these three basic principles
The activity of a filter can be triggered by several events:
 The subsequent pipeline element pulls output data from the filter.
 The previous pipeline element pushes new input data to the filter.
 Most commonly, the filter is active in a loop, pulling its input from and pushing its output down the
pipeline.

The first two cases denote so-called passive filters, whereas the last case is an active filter. An active
filter starts processing on its own as a separate program or thread.
A passive filter component is activated by being called either as a function (pull) or as a procedure
(push)
Introduction : Pipes and Filters
Pipes denote the connections between filters, between the data source and the first
filter, and between the last filter and the data sink
Introduction : Pipes and Filters
 The data sink collects the results from the end of the pipeline. Two variants of the
data sink are possible
 An active data sink pulls results out of the preceding processing stage, while a
passive one allows the preceding filter to push or write the results into it
Introduction : Pipes and Filters
Introduction : Pipes and Filters
Dynamics:
Scenario I  shows a push pipeline in which activity starts with the data source. Filter activity is
triggered by writing data to the passive filters.
Introduction : Pipes and Filters
Dynamics:
Scenario II  shows a pull pipeline. Here control flow is started by the data sink calling for data
Introduction : Pipes and Filters
Dynamics:
Scenario III  shows a mixed push-pull pipeline with passive data source and sink. Here the second
filter plays the active role and starts the processing.
Introduction : Pipes and Filters
Dynamics:
Scenario IV  shows a more complex but typical behavior of a Pipes and Filters system
Introduction : Pipes and Filters
Dynamics:
Scenario IV  shows a more complex but typical behavior of a Pipes and Filters system
Introduction : Pipes and Filters
Implementation:
You can use a system service such as message queues or UNIX pipes for pipe
connections, or other options like the direct call implementation, as described in
steps 3 through 6 below
1. Divide the system's task into a sequence of processing stages
2. Define the data format to be passed along each pipe
3. Decide how to implement each pipe connection
4. Design and implement the filters.
5. Design the error handling
6. Set up the processing pipeline
Introduction : Pipes and Filters
Example resolved:
We did not follow the Pipes and Filters pattern strictly in our Mocha compiler by implementing all phases of
the compiler as separate filter programs connected by pipes
Introduction : Pipes and Filters
Variants:
Tee and join pipeline systems, The single-input single-output filter specification of the Pipes and
Filters pattern can be varied to allow filters with more than one input and/or more than one output
cat file I tee pipeA I sort -u I comm -13 - pipeB
Introduction : Pipes and Filters
Known Uses:
UNIX
CMS Pipelines
LASSPTools

Consequences:
The Pipes and Filters architectural pattern has the following benefits
1. No intermediate files necessary, but possible
2. Flexibility by filter exchange
3. Flexibility by recombination
4. Reuse of filter components
5. Rapid prototyping of pipelines
6. Efficiency by parallel processing
Introduction : Pipes and Filters
Applying the Pipes and Filters pattern imposes some liabilities
1. Sharing state information is expensive or inflexible
2. Efficiency gain by parallel processing is often an illusion
1. The cost for transferring data between filters may be relatively high compared to the cost of
the computation carried out by a single filter
2. Some filters consume all their input before producing any output, either because the task,
such as sorting, requires it or because the filter is badly coded
3. Context-switching between threads or processes is generally an expensive operation on a
single-processor machine
4. Synchronization of filters via pipes may stop and start filters often, especially when a pipe
has only a small buffer
3. Data transformation overhead
4. Error handling.
Introduction : Pipes and Filters
See Also:
The Layers pattern is better suited to systems that require reliable operation,
because it is easier to implement error handling than with Pipes and Filters

Credits:
This pattern relies on experience we gained when learning, using, and teaching
UNIX. Our thanks therefore go to the designers of the first versions of UNIX, and its
predecessors, who invented and established the use of pipes and filters
Introduction : Blackboard
 The Blackboard architectural pattern is useful for problems for which no
deterministic solution strategies are known.
 In Blackboard several specialized subsystems assemble their knowledge to build
a possibly partial or approximate solution
Introduction : Blackboard
Example: Software system for speech recognition
The input to the system is speech recorded as a waveform.
The system not only accepts single words, but also whole sentences that are
restricted to the syntax and vocabulary needed for a specific application, such as a
database query
The desired output is a machine representation of the corresponding English
phrases. The transformations involved require acoustic- phonetic, linguistic. and
statistical expertise
 Introduction : Blackboard

The input is the waveform at the bottom, and the output consists of the phrase ‘are any by Feigenbaum’
Introduction : Blackboard
Context:
An immature domain in which no closed approach to a solution is known or feasible

Problem:
The Blackboard pattern tackles problems that do not have a feasible deterministic solution for the
transformation of raw data into high-level data structures, such as diagrams, tables or English
phrases.
Vision, image recognition, speech recognition and surveillance are examples of domains in which
such problems occur
Introduction : Blackboard
The following forces influence solutions to problems of this kind
1. A complete search of the solution space is not feasible in a reasonable time
2. Since the domain is immature, you may need to experiment with different algorithms for the
same subtask
3. There are different algorithms that solve partial problems
4. Input, as well as intermediate and final results, have different representations, and the
algorithms are implemented according to different paradigms
5. An algorithm usually works on the results of other algorithms
6. Uncertain data and approximate solutions are involved
7. Employing disjoint algorithms induces potential parallelism. If possible you should avoid a strictly
sequential solution
Introduction : Blackboard
This type of expert system structure is inadequate for a speech recognition
system.

There are three reasons for this

1. All partial problems are solved using the same knowledge representation
2. The expert system structure provides only one inference engine to control the
application of knowledge
3. In a 'classical' expert system, control is implicit in the structure of the knowledge
base, for example in the ordering of the rules in a rule-based system
Introduction : Blackboard
Solution:
The Blackboard Architectural Pattern solves this problem by using a central shared
data structure called the 'blackboard', where different subsystems (knowledge
sources) post intermediate results, and collaborate iteratively to produce the final
speech recognition output.
Introduction : Blackboard
Solution:
The idea behind the Blackboard architecture is a collection of independent
programs that work cooperatively on a common data structure.
Each program is specialized for solving a particular part of the overall task, and all
programs work together on the solution

 During the problem-solving process, the system works with partial solutions that
are combined, changed or rejected
 The name 'blackboard’ was chosen because it is reminiscent of the situation in
which human experts sit in front of a real blackboard and work together to
solve a problem
Introduction : Blackboard
Structure:
Divide your system into a component called blackboard, a collection of knowledge sources, and a
control component

The blackboard is the central data store. Elements of the solution space and control data are stored
here
All elements of the solution space can appear on the blackboard.
For solutions that are constructed during the problem solving process and put on the blackboard,
we use the terms hypothesis or blackboard entry
A hypothesis usually has several attributes, for example its abstraction level, that is, its conceptual
distance from the input

It is often useful to specify relationships between hypotheses, such as 'part-of or 'in-support-of

Introduction : Blackboard
Key components of the Blackboard Architecture include:
• Blackboard: Shared data structure where subsystems post data.
• Knowledge Sources: Subsystems like Acoustic Processor, Phoneme Recognizer.
• Controller (optional): Manages the coordination between subsystems.
Introduction : Blackboard
Introduction : Blackboard
Knowledge sources are split into a condition-part and
an action-part.
 The condition part evaluates the current state of the
solution process, as written on the blackboard, to
determine if it can make a contribution.
 The action-part produces a result that may cause a
change to the blackboard's contents.
Introduction : Blackboard
 The control component runs a loop
that monitors the changes on the
blackboard and decides what action to
take next.
 It schedules knowledge source
evaluations and activations according
to a knowledge application strategy.
 The basis for this strategy is the data
on the blackboard.
Introduction : Blackboard
Introduction : Blackboard
Introduction : Blackboard
Introduction : Blackboard
Implementation:
Introduction : Blackboard
Introduction : Blackboard
Introduction : Blackboard
Introduction : Blackboard
Introduction : Blackboard
Introduction : Blackboard
Introduction : Blackboard
Introduction : Blackboard
Introduction : Blackboard
Introduction : Blackboard
Introduction : Blackboard
Introduction : Distributed Systems
Three patterns related to distributed systems
1. The Pipes and Filters pattern provides a structure for systems that process a
stream of data

2. The Microkernel pattern applies to software systems that must be able to adapt
to changing system requirements

3. The Broker pattern can be used to structure distributed software systems with
decoupled components that interact by remote service invocations.
A broker component is responsible for coordinating communication, such as
forwarding requests, as well as for transmitting results and exceptions
Introduction : Distributed Systems
Three groups of developers who can benefit by using the Broker
pattern:
1. Those working with an existing Broker system who are interested in
understanding the architecture of such systems.
2. Those who want to build 'lean' versions of a Broker system, without all the bells
and whistles of a full-blown OLE(Object Linking and Embedding) or CORBA (Common Object
Request Broker Architecture).
3. Those who plan to implement a fully-fledged Broker system, and therefore need
an in-depth description of the Broker architecture
Introduction : Distributed Systems
 The Broker Pattern is a design pattern used in software engineering to facilitate
communication and interaction between components or services in a distributed
system. In this pattern, a central component called the “broker” acts as an
intermediary or middleman, facilitating communication and coordination
between other components or services.

 The Broker receives requests from clients, processes them, and dispatches them
to the appropriate components or services based on predefined rules or criteria.

 This pattern helps to decouple components, simplify communication, and

improve system flexibility and scalability.
Introduction : Distributed Systems
Introduction : Distributed Systems

Context:
Your environment is a distributed and possibly heterogeneous system with independent
cooperating components

Problem:
Building a complex software system as a set of decoupled and inter-operating components, rather
than as a monolithic application, results in greater flexibility, maintainability and changeability
Introduction : Distributed Systems

Broker architecture to balance the following forces

 Components should be able to access services provided by others through remote, location-
transparent service invocations.
 You need to exchange, add, or remove components at run-time.
 The architecture should hide system- and implementation-specific details from the users of
components and services.
Introduction : Distributed Systems

To develop a City Information System

Introduction : Distributed Systems
Solution:
 Introduce a broker component to achieve better decoupling of clients and
servers
 Servers register themselves with the broker, and make their services available to
client's through method interfaces.
 Clients access the functionality of servers by sending requests via the broker.
 A broker's tasks include locating the appropriate server, forwarding the request
to the server and transmitting results and exceptions back to the client.

The Broker architecture is flexible, in that it allows dynamic change, addition,

deletion, and relocation of objects
Introduction : Distributed Systems
Structure:
The Broker architectural pattern comprises six types of participating components:
clients, servers, brokers, bridges, client-side proxies and server-side proxies
1. server implements objects that expose their functionality through interfaces that consist of
operations and attributes
2. Clients are applications that access the services of at least one server
3. Broker is a messenger that is responsible for the transmission of requests from clients to
servers, as well as the transmission of responses and exceptions back to the client
4. Client-side proxies represent a layer between clients and the broker
5. Server-side proxies are generally analogous to Client-side proxies. The difference is that they
are responsible for receiving requests, unpacking incoming messages, unmarshaling the
parameters, and calling the appropriate service
6. Bridges are optional components used for hiding implementation details when two brokers
interoperate
Introduction : Distributed Systems
Structure:
 The servers in our CIS example comprise WWW servers that provide access to
HTML (Hypertext Markup Language) pages.
 In the context of the Broker pattern, the clients are the available WWW
browsers. They are not directly connected to the network
 A broker in our CIS example is the combination of an Internet gateway and the
Internet infrastructure itself. Every information exchange between a client and a
server must pass through the broker
 In our CIS example the WWW browsers and httpd servers such as Netscape
provide built-in capabilities for communicating with the gateway of the Internet
provider, so we do not need to worry about proxies in this case
 Bridges are not required in our CIS example, because all httpd servers and WWW
browsers implement the protocols necessary for remote data exchange such as
http
Introduction : Distributed Systems
Introduction : Distributed Systems
Introduction : Distributed Systems
Introduction : Distributed Systems
Introduction : Distributed Systems
Introduction : Distributed Systems
Dynamics:
Scenario I illustrates the behavior when a
server registers itself with the local broker
component
Introduction : Distributed Systems
Dynamics:
Scenario II illustrates the behavior when a client
sends a request to a local server.
 In this scenario we describe a synchronous
invocation, in which the client blocks until it
gets a response from the server.
 The broker may also support asynchronous
invocations, allowing clients to execute
further tasks without having to wait for a
response
Introduction : Distributed Systems
Dynamics:
Scenario III illustrates the interaction of
different brokers via bridge components:
Introduction : Distributed Systems
Implementation:
To implement this pattern, carry out the following steps
1. Define an object model, or use an existing model
2. Decide which kind of component-interoperability the system should offer.
3. Specify the APIs the broker component provides for collaborating with clients and servers
4. Use proxy objects to hide implementation details from clients and servers
5. Design the broker component in parallel with steps 3 and 4
1. Specify a detailed on-the-wire protocol for interacting with client-side proxies and server-side proxies
2. A local broker must be available for every participating machine in the network
3. When a client invokes a method of a server, the Broker system is responsible for returning all results and exceptions
back to the original client
4. If the proxies (see step 4) do not provide mechanisms for marshaling and unmarshaling parameters and results, you
must include that functionality in the broker component
5. If your system supports asynchronous communication between clients and servers, you need to provide message
buffers within the broker or within the proxies for the temporary storage of messages
6. Include a directory service for associating local server identifiers with the physical location of the corresponding
servers in the broker
7. When your architecture requires system-unique identifiers to be generated dynamically during server registration,
the broker must offer a name service for instantiating such names
8. If your system supports dynamic method invocation (see step 3), the broker needs some means for maintaining
type information about existing servers
6. Develop IDL compilers
Introduction : Distributed Systems
Example Resolved:
CIS system offers different kinds of services. so we decide to provide this data on a single workstation. Every
hotel can connect to the workstation and perform updates

Variants:
 Direct Communication Broker System
 Message Passing Broker System
 Trader System
 Adapter Broker System
 Callback Broker System

Known Uses:
 CORBA
 IBM SOM/DSOM
 Microsoft's OLE 2.x
 The World Wide Web
 ATM-P
Introduction : Distributed Systems
Consequences:
 Location Transparency  clients do not need to know where servers are located
 Changeability and extensibility of components  If servers change but their interfaces remain
the same, it has no functional impact on clients
 Portability of a Broker system  The Broker system hides operating sys- tem and network
system details from clients and servers by using indirection layers such as APIs, proxies and
bridges
 Interoperability between different Broker systems  Different Broker systems may interoperate
if they understand a common protocol for the exchange of messages
 Reusability  When building new client applications, you can often base the functionality of
your application on existing services

Some liabilities:
 Restricted efficiency  slow in application
 Lower fault tolerance  server or a broker fails, unable to continue successfully
Introduction : Distributed Systems
See also:

The Forwarder-Receiver pattern

The Proxy pattern
The Client-Dispatcher-Server pattern
The Mediator design pattern

Credits:
Introduction : Interactive Systems
We describe two patterns that provide a fundamental structural organization for interactive
software systems

 The Model-View-Controller pattern (MVC) divides an interactive application into three

components. The model contains the core functionality and data. Views display information to
the user. Controllers handle user input. Views and controllers together comprise the user
interface. A change-propagation mechanism ensures consistency between the user interface and
the model

 The Presentation-Abstraction-Control pattern (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
Introduction : Interactive Systems
Model-View-Controller:

The Model-View-Controller architectural pattern (MVC) divides an interactive application into three
components.
 The model contains the core functionality and data.
 Views display information to the user.
 Controllers handle user input.
 Views and controllers together comprise the user interface.
 A change-propagation mechanism ensures consistency between the user interface and the model
Introduction : Interactive Systems
Model-View-Controller:

Example:
A Simple Information System for political elections with proportional representation
Introduction : Interactive Systems
Model-View-Controller:

Context:
Interactive applications with a flexible human-computer interface

Problem:

Building a system with the required flexibility is expensive and error prone if the
user interface is tightly interwoven with the functional ore.
Introduction : Interactive Systems
Model-View-Controller:

The following forces influence the solution

 The same information is presented differently in different windows, for example, in a bar chart or
pie chart.
 The display and behavior of the application must reflect data manipulations immediately.
 Changes to the user interface should be easy, and even possible at run-time.
 Supporting different 'look and feel' standards or porting the user interface should not affect code
in the core of the application.
Introduction : Interactive Systems
Model-View-Controller:
Solution :
MVC divides an interactive application into the three areas: processing, output, and input

 The model component encapsulates core data and functionality.

 The model is independent of specific output representations or input behavior
 View components display information to the user.
 A view obtains the data from the model.
 There can be multiple views of the model
Introduction : Interactive Systems
Model-View-Controller:
Structure :
Introduction : Interactive Systems
Model-View-Controller:
Structure :
Introduction : Interactive Systems
Model-View-Controller:
Structure :
Introduction : Interactive Systems
Model-View-Controller:
Dynamics :
Scenario I shows how user input that results in changes to the model triggers the change-propagation
mechanism
Introduction : Interactive Systems
Model-View-Controller:
Dynamics :
Scenario II shows how the MVC triad is initialized. This code is usually located outside of the model, views and
controllers, for example in a main program. The view and controller initialization occurs similarly for each view
opened for the model
Introduction : Interactive Systems
Model-View-Controller:
Implementation :
Steps 1 through 6 below are fundamental to writing an MVC-based application.
Steps 7 through 10 describe additional topics that result in higher degrees of freedom
1. Separate human-computer interaction from core functionality
2. Implement the change-propagation mechanism
3. Design and implement the views
4. Design and implement the controllers
5. Design and implement the view-controller relationship
6. Implement the set-up of MVC
7. Dynamic view creation
8. Pluggable controllers
9. Infrastructure for hierarchical views and controllers
10. Further decoupling from system dependencies
Introduction : Interactive Systems
Model-View-Controller:
Variants :
Document-View

Known Uses:
Smalltalk
MFC
ET++
Introduction : Interactive Systems
Model-View-Controller:
Model-View-Controller has several benefits:
1. Multiple views of the same model
2. Synchronized views
3. 'Pluggable' views and controllers
4. Exchangeability of 'look and feel'.
5. Framework potential

The liabilities of MVC are as follows

1. Increased complexity
2. Potential for excessive number of updates
3. Intimate connection between view and controller
4. Close coupling of views and controllers to a model.
5. Inefficiency of data access in view
6. Inevitability of change to view and controller when porting
7. Difficulty of using MVC with modern user-interface took