The document discusses several software design patterns including: - Model-View-Controller which divides an application into three components: the model, the view, and the controller. - Properties of patterns for software architecture such as addressing recurring problems and documenting proven solutions. - Categories of patterns such as architectural patterns, design patterns, and idioms. Specific patterns like Proxy, Command Processor, and View Handler are described.

1. Unit IV

2. Patterns
• The architect Christopher Alexander defines
the term pattern as follows:
– Each pattern is a three-part rule, which expresses
a relation between a certain context, a problem,
and a solution.
– As an element of language, a pattern is an
instruction, which shows how this spatial
configuration can be used, over and over again, to
resolve the given system of forces, wherever the
context makes it relevant.

3. Model-View-Controller
• User interfaces are prone to change requests
• when developing such an interactive software
system, you have to consider two aspects:
– Changes to the user interface should be easy, and
possible at runtime.
– Adapting or porting the user interface should not
impact code in the functional core of the
application.

4. • To solve the problem, divide an interactive
application into three areas: processing, output
and input:
– The model component encapsulates core data and
functionality.
– View components display information to the user. A
view obtains the data it displays from the model.
There can be multiple views of the model.
– Each view has an associated controller component.
Controllers receive input, usually as events that
denote mouse movement, activation of mouse
buttons or keyboard input.

6. Properties of patterns for software
architecture
• A pattern addresses a recurring design
problem that arises in specific design
situations, and presents a solution to it.
• Patterns document existing, well-proven
design experience.
• Patterns identify and specify abstractions that
are above the level of single classes and
instances, or of components

7. • Patterns provide a common vocabulary and
understanding for design principles
• Patterns are a means of documenting software
architecture
• Patterns support the construction of software
with defined properties.
• Patterns help you build complex and
heterogeneous software architectures.
• Patterns help you to manage somare complexity

8. What Makes a Pattern
• Context: a situation giving rise to a problem.
• Problem: the recurring problem arising in that
context.
• Solution: a proven resolution of the problem.

9. Pattern Categories
• Architectural patterns
• Design patterns
• Idioms

10. Architectural Patterns
• An architectural pattern expresses a fundamental
structural organization schema for software systems.
• It provides a set of predefined subsystems, specifies
their responsibilities, and includes rules and guidelines
for organizing the relationships between them.
• They specify the system-wide structural properties of
an application, and have an impact on the architecture
of its subsystems.
• The selection of an architectural pattern is therefore a
fundamental design decision when developing a
software system.

11. Design Patterns
• The subsystems of a software architecture, as
well as the relationships between them, usually
consist of several smaller architectural units. We
describe these using design patterns.
• Design patterns are medium-scale patterns.
• They are smaller in scale than architectural
patterns, but tend to be independent of a
particular programming language or
programming paradigm.

12. Idioms
• Idioms deal with the implementation of
particular design issues.
• An idiom is a low-level pattern specific to a
programming language.
• An idiom describes how to implement
particular aspects of components or the
relationships between them using the features
of the given language.
• Most idioms are language-specific

13. Relationships between Patterns
• The Document-View variant of the Model-View-
Controller pattern
– which unifies the view and controller functionality in a
single component, the view of the Document-View pattern
• Transparent peer-to-peer inter-process communication
– The inter-process communication must be efficient.
Spending time searching for the location of remote servers
is undesirable
– Independence from a particular inter-process
communication mechanism is desirable
– Clients should not be aware of, or dependent on, the name
and location of their servers.

14. Pattern Description
• Name
• Context
• Problem
• Solution
• Structure
• Dynamics
• Varients
• Known Uses
• Consequences
• References

15. Pattern and Software Architecture
• construction of specific software architectures
with defined properties
• Constructing Heterogenous Architectures
• Patterns versus Methods
• Implementing Patterns

16. Categories of Design Patterns
• Structural Decomposition: This category includes patterns that
support a suitable decomposition of subsystems and complex
components into cooperating parts.
• Organization of Work. This category comprises patterns that
define how components collaborate together to solve a
complex problem.
• Access Control. Such patterns guard and control access to
services or components.
• Management: This category includes patterns for handling
homogenous collections of objects, services and components
in their entirety.
• Communication. Patterns in this category help to organize
communication between components. Two patterns address
issues of inter-process communication

17. Structural Decomposition
• Subsystems and complex components are handled more
easily if structured into smaller independent components,
rather than remaining as monolithic blocks of code.
• The Whole-Part design pattern helps with the aggregation
of components that together form a semantic unit.
• An aggregate component, the whole, encapsulates its
constituent components.
• The Whole-Part pattern has wide applicability.
• Hierarchical structure with containment relationships are
especially suitable for the application of Whole-Part in one
of its variants.

18. • Ex: A computer-alded deslgn (CAD) system

20. • To implement a Whole-Part structure
– Design the public interface of the Whole
– Separate the Whole into Parts, or synthesize it
from existing ones
– Specifies the services of the Whole in terms of
services of the Parts.
– Implement the Parts
– Implement the Whole

21. Benefits
• Changeability of Parts
• Separation of concerns
• Reusability.

22. Master-Slave
• The Master-Slave design pattern supports fault
tolerance, parallel computation and
computational accuracy.
• A master component distributes work to identical
slave components and computes a final result
from the results these slaves return.
• Master-Slave applies the 'divide and conquer'
principle.
• Work is partitioned into several subtasks that are
processed independently.

23. • The Chain of Responsibility pattern avoids coupling the
sender of a request to its receiver by giving more than
one object the chance to handle the request.
• The Command pattern encapsulates a request as an
object, allowing you to parameterize clients with
different requests , to queue or log requests and to
support undoable operations.
• The Mediator pattern defines an object that
encapsulates the way in which a set of objects interact.
Mediator promotes loose coupling by preventing
objects from referring to each other explicitly, and
allows you to vary their interaction independently

24. Access Control
• The Proxy design pattern makes the clients of a
component communicate with a representative
rather than to the component itself.
• Can serve many purposes, including enhanced
efficiency, easier access and protection from
unauthorized access.
• more recent application of Proxy is the World
Wide Web , where it is used to implement the
proxy servers

25. • Two other patterns described in also belong to
this category-
– Façade:
• The Facade pattern provides a uniform interface to a set of
interfaces in a subsystem.
• Facade defines a higher-level interface that makes the
subsystem easier to use.
– Iterator:
• The Iterator pattern provides a way to access the elements
of an
• aggregate object sequentially without exposing its
underlying representation

26. • The traveling-salesman problem is well-known
in graph theory.

28. Create a Iterator interface which narrates navigation method and a Container
interface which retruns the iterator . Concrete classes implementing the
Container interface will be responsible to implement Iterator interface and use
it

29. Proxy
• The Proxy design pattern makes the clients of
a component communicate with a
representative rather than to the component
Itself.
• Introducing such a placeholder can serve
many purposes, including enhanced efficiency,
easier access and protection from
unauthorized access

31. • Example: Company engineering staff regularly
consult databases for information about material
providers, available parts. blueprints, and so on.
• Context: A client needs access to the services of
another component
• Problem :It is often inappropriate to access a
component directly.
– run-time-efficient,
– cost effective,
– safe

32. • Solution: Let the client communicate with a
representative rather than the component
itself. This representative-called a proxy.
• Structure: The client is responsible for a
specific task. To do its job, it invokes the
functionality of the original in an indirect way
by accessing the proxy

35. • Dynamics:

36. • Implementation: To implement the Proxy pattern
• Variants:
– Remote Proxy
– Protection Proxy
– Cache Proxy
– Synchronization Proxy.
– Counting Proxy
– Virtual Proxy
– Firewall Proxy

37. Communication
• Most of them use networks of computers
• Distributed systems allow better sharing and utilization
of the resources available within the network.
• Server machines may host central services such as
database management systems, while inexpensive
workstations can access these services remotely.
• Work within corporations is inherently distributed, and
therefore distributed software systems that implement
the business logic match this organization of work.

38. • present two patterns that address these topics
• Forwarder-Receiver design pattern provides
transparent inter-process communication for software
systems with a peer-to-peer interaction model.
(Encapsulation)
• Client-Dispatcher-Server design pattern introduces an
intermediate layer between clients and servers, the
dispatcher component.
• It provides location transparency by means of a name
service, and hides the details of the establishment of
the communication connection between clients and
servers

39. Forwarder-Receiver
• The Forwarder-Receiver design pattern
provides transparent interprocess
communication for software systems with a
peer-to-peer interaction model.
• It introduces forwarders and receivers to
decouple peers from the underlying
communication mechanisms.

40. • Context: Peer-to-peer communication
• Problem: TCP/IP
– exchangeability of the communication
mechanisms.
– needs to know the names of its receivers.
– should not have a major impact on performance.
• Solution: Distributed peers collaborate to
solve a particular problem
• Structure : forwarders, receivers, and peers

43. • Dynamics: Two peers pl and p2 communicate
with each other.
• Implementation:
– Specify a name-to-address mapping
– Specify the message protocols
– Choose a communication mechanism
– Implement the forwarder
– Implement the receiver
– Implement the peers of your application
– Implement a start-up configuration

44. • Variants: Forwarder-Receiver without name-
to-address mapping.
• Consequences:
– Efficient inter-process communication
– Encapsulation

45. Client-Dispatcher-Server
• The Client-Dispatcher-Server design pattern
introduces an intermediate layer between
clients and servers, the dispatcher
component.
• It provides location transparency by means of
a name service, and hides the details of the
establishment of the communication
connection between clients and servers.

46. Example

47. • Context: A software system integrating a set of
distributed servers, with the servers running
locally or distributed over a network.
• Problem: When a software system uses servers
distributed over a network it must provide a
means for communication between them.
– A component should be able to use a service
independent of the location of the service provider.
– The code implementing the functional core of a
service consumer should be separate from the code
used to establish a connection with service providers.

48. • Solution: Provide a dispatcher component to
act as an intermediate layer between clients
and servers.
– The dispatcher implements a name service that allows
clients to refer to servers by names instead of physical
locations, thus providing location transparency
– The dispatcher is responsible for establishing the
communication channel between a client and a server
– Clients rely on the dispatcher to locate a particular
server and to establish a communication link with the
server.

49. • Structure:

52. • Dynamics: A typical scenario for the Client-Dispatcher-Server
design pattern includes the following phases:
• A server registers itself with the dispatcher component.
• At a later time, a client asks the dispatcher for a communication
channel to a specified server.
• The dispatcher looks up the server that is associated with the name
specified by the client in its registry.
• The dispatcher establishes a communication link to the server.
• The client uses the communication channel to send a request
directly to the server.
• After recognizing the incoming request, the server executes the
appropriate service.
• When the service execution is completed, the server sends the
results back to the client.

53. • Implementation:
– Separate the application into servers and clients
– Decide which communication facilities are
required
– Specify the interaction protocols between
components
– Decide how to name servers.
– Design and implement the dispatcher
– Implement the client and server components

54. • Variants:
– Distributed Dispatchers
– Client-Dispatcher-Server with communication
managed by clients
– Client-Dispatcher-Server with heterogeneous
communication
• Consequences:
– Exchangeability of servers
– Location and migration transparency
– Re-configuration
– Fault tolerance

55. Management
• In well-structured software systems, separate
'manager' components are often used to handle such
homogeneous collections of objects.
• The Command Processor pattern separates the
request for a service from its execution.
– manages requests as separate objects,
– schedules their execution
– provides additional services eg. storing of request objects
• The View Handler pattern helps to manage views in a
software system.
– Allows clients to open, manipulate and dispose of views

56. Command Processor
• The Command Processor design pattern
separates the request for a service from its
execution
• Example: TEDDI (The program has to define
one or several callback procedures that are
automatically called for every human-
computer interaction)

58. • Context: Applications that need flexible and extensible user
interfaces, or applications that provide services related to
the execution of user functions, such as scheduling or
undo.
• Problem: You often need to implement services that go
beyond the core functionality of the system for the
execution of user requests.
– Different users like to work with an application in different ways.
– Enhancements of the application should not break existing
code.
– Additional services such as undo should be implemented
– consistently for all requests.

59. • Solution:

62. • Dynamics:
– The controller accepts the request from the user within its event
loop and creates a 'capitalize' command object.
– The controller transfers the new command object to the command
processor for execution and further handling.
– The command processor activates the execution of the command
and stores it for later undo.
– The capitalize command retrieves the currently-selected text from
its supplier, stores the text and its position in the document, and
asks the supplier to actually capitalize the selection.
– After accepting an undo request, the controller transfers this
request to the command processor.
– The capitalize command resets the supplier to the previous state,
by replacing the saved text in its original position

63. • Implementation:
– Define the interface of the abstract command.
– Design the command components for each type of
request
– Increase flexibility by providing macro commands
– Implement the controller component
– Implement access to the additional services of the
command processor
– Implement the command processor component

64. • Consequences
• Flexibility in the way requests are activated
• Flexibility in the number and functionality of
requests
• Programming execution-related services
• Testability at application level
• Potential for an excessive number of command
classes
• Efficiency loss

65. View Handler
• The View Handler design pattern helps to
manage all views that a software system
provides.
• A view handler component allows clients to
open, manipulate and dispose of views. It also
coordinates dependencies between views and
organizes their update.

66. EXAMPLE

67. • Context: A software system that provides
multiple views of application-specific data or
that supports working with multiple
documents.
• Problem: User often need additional
functionality for managing them.
• Users want to be able conveniently to open,
manipulate, and disclose of views, such as
windows and their contents.

68. • Managing multiple views should be easy from
the user's perspective and also for client
components within the system.
• Implementations of individual views should
not depend on each other or be mixed with
the code used to manage the view.
• View implementations can vary and
additional types of views may be added during
the lifetime of the system.

69. • Solution: Separate the management of views
from the code required to present or control
specific views.
• Structure:

73. • Dynamics:
– Scenario I shows how the view handler creates a new
view
– Scenario II illustrates how the view handler organizes
the tiling of views
• Implementation:
– Identify the views
– Specify a common interface for all views
– Implement the views
– Define the view handler

74. • Variants:
– View Handler with Command objects.
• Consequences:
– Uniform handling of views’
– Extensibility and changeability of views.
– Application-specific view coordination
– Restricted applicabilty

75. Idioms
• Name: Indented Control Flow
• Problem: How do you indent messages?
• Solution: Put zero or one argument messages
on the same lines as their receiver.

76. • Put the keyword/argument pairs of messages
with two or more keywords each on its own
line, indented one tab

77. • Name: Singleton (C++)
• Problem: You want to implement the
Singleton design pattern in C++, to ensure that
exactly one instance of a class exists at run-
time.
• Solution : Make' the constructor of the class
private. Declare a static member variable the
Instance that refers to the single existing
instance of the class.

78. • Example: