1. Design Patterns-1
7 Hours

2. Agenda What is a pattern and what makes a pattern? Pattern categories
Relationships between patterns
Pattern description
Communication Patterns
Forwarder-Receiver
Client-Dispatcher-Server
Publisher-Subscriber.

3. What is a Pattern?
When experts work on a given problem, they recall a similar problem they have already solved and reuse that solution in present context.
They tend to map it to a Problem-solution pairs.
Abstracting problem-solution pair and taking out common factors leads to patterns.
Patterns expresses relation between a context, a problem and a solution.
Problem-solution pair holds true in the field of software architecture and software engineering.

4. Example: Model-View- Controller
Consider this pattern when developing human-computer interface.
User interfaces are prone to changes and they should not be tightly bound to core models.
To avoid these issues, divide the application into three areas: Model, View and Controller.

5. Properties of pattern It addresses recurring design problems.
It documents existing, well- proven design experiences.
It identifies and specifies abstractions that are above the levels of single class.
Provide common vocabulary and understanding for design principles.
Document software architecture.
Construction of software with defined properties.
Helps in building complex and heterogenous architectures.
Helps in managing software complexity.

6. What makes a pattern? Three-part schema
Context: a situation giving rise to a problem.
Problem: the recurring problem arising in that context.
Solution: a proven resolution of the problem.

7. Context: Describes the situation where problem occurs.
It can be general (developing software with a human- computer interface)
Or it can be specific (implementing change propagation mechanism of the model-view-controller triad).
Specifying the correct context is difficult (practically impossible to determine all situations).

8. Problem:
Describes the problem which arises repeatedly in the given context.
It is completed by a set of forces:
Requirements that the solution must fulfil.
Constraints that must be considered.
Desirable properties that the solution must have.
Example: MVC enforces 2 rules:
Easy to modify UI
Core should not be affected.

9. Solution
Solution part shows show to solve the recurring problem (how to balance the forces)
Two aspects of the solution:
Spatial configuration of elements (Divide the application into 3 areas: Processing, output and input)
Run-time behaviour (Controller receives events as input, events are translated to service requests, which are sent to model or view)

10. Pattern Categories Patterns can be grouped into three categories:
Architectural patterns
Design patterns
Idioms

11. Architectural Patterns
Expresses fundamental structural organization schema, provides set of predefined subsystems, responsibilities, relationships and rules.
Example: Model-View-Controller pattern.

12. Design Patterns
Subsystems of the architecture, usually consists of several smaller architectural units.
Design patterns provides a scheme for refining subsystems, relationships between them.
It describes commonly-recurring structure of component that solves a general design problem.
Example: Publisher-Subscriber problem.

13. Publisher-Subscriber Problem

14. Idioms
Idiom is a low-level pattern specific to a programming language.
Describes how to implement aspects of components, relationships using the feature of given language.
Example: Counted Body

15. Relationship between Patterns
A pattern may solve a given problem, but the solution may create another problem.
Each pattern depends on the smaller patterns it contains and on the larger patterns in which it is contained.
Patterns can combine in more complex structures (if it has more forces)
Example: Transparent peer-to-peer inter-process communication
Efficient, no delay
Should not affect others clients or servers
Communicate as if they were in the same process

16. 2 Patterns are used to satisfy the given forces
Forwarder-Receiver Pattern
Proxy pattern

17. Pattern Description
Patterns should be described uniformly, helps in comparison when we are looking for alternative solutions.
Add more description to the basic structure(context-problem- solution).
Name: Name and short summary
Also know as: Other names for the pattern
Example: A real world example demonstrating the existence of the problem and the need for the pattern.
Context: Situation

18. Problem: Problem that the pattern addresses.
Solution: Fundamental solution.
Structure: Structural aspects of the pattern.
Dynamics: Run time behaviour.
Implementation: Guidelines for implementation.
Example resolved: Imp. aspects for resolving the example that are not yet covered in the solution.
Variants: Description of variants.
Known uses: Examples of the use of pattern.
Consequences: Benefits and liabilities
See Also: References to patterns that solve similar problems.

19. Communication
Most of the devices in communication use network of computers and are distributed.
These systems should collaborate and needs a means of communication.
Communication mechanism is usually hardcoded in these devices. To free the devices from this strong coupling, we use abstract this layer.
Two patterns to address this issue.
The Forwarder-Receiver design pattern
The Client-Dispatcher-Server design pattern
To keep components in consistent state, we use
The Publisher-Subscriber pattern

20. Forwarder-Receiver
Provides transparent IPC for software system with peer-to-peer interaction model. Introduces forwarders and receivers to decouple peers from underlying communication mechanism.

21. Context: Peer-peer communication
Problem: To build a distributed application we make use of common IPC such as TCP/IP, sockets, etc. They introduce dependency in the OS and protocols., restricting portability, avoids heterogeneous network support.
Forces to balance:
System should allow exchangeability of communication mechanisms.
Cooperation of components, sender knows only names of receivers.
Communication should not have major impact on performance.

22. Solution
Peers collaborate to solve this problem. It may act as client, server, or both.
Underlying IPC mechanism is hidden by encapsulating system- specific-functionality. (mapping names to physical location, channel establishment, etc.)
Structure
Consists of 3 components: forwarders, receivers and peers.
Peers use applications and communicate with other peers (same machine or different machine).
It send messages using forwarder and receives using receiver.

23. Forwarder component sends messages across process boundaries.
Provides abstraction of IPC mechanism and includes functionality of marshaling and delivery of messages.
It identifies the physical location of recipient using name-to- address mapping.
Name of the peer is mentioned in the transmitted message.
Types of messages by forwarder:
Command messages (ex: change routing tables)
Information messages (Contain data)
Response messages (ack of the message)

24. Receiver component provides abstraction similar to forwarder for enabling IPC. Functionality: receive the message and unmarshal it.

25. Peer uses sendMsg of forwarder, passing message as argument.
Forwarder converts it and sends it to receiver (marshal and deliver)
When peer wants to receive a msg, it uses receiveMsg, which calls receive (IPC mechanism to receive).
receiveMsg calls unmarshal to convert from IPC format to peer understandable format

26. Dynamics P1 and P2 are two peers who want to communicate.
P1 uses a forwarder Forw1 and a receiver Recv1, similarly, P2 uses Forw2 and Recv2.
P1 is requesting some service from P2. It requests Forw1 and specifies name of P2.
Forw1 determines the physical location and marshals the message.
P2 would have requested Recv2 to wait for requests. Recv2 receives the message from Forw1.
Recv2 unmarshals and forwards to P2.

27. P1 calls Recv1 to wait for the response.
P2 performs the requested service and sends the result and name of P1 to the Forw2, which marshals and send it P1.
Recv1 receives the response from P2, unmarshals it and delivers to P1.

29. Implementation: Steps
Specify a name-to-address mapping. (name space)
Specify the message protocols to be used between peers and forwarders. (msg. structure between peer and forwarder)
Choose a communication channel. (depends on OS- TCP/IP, sockets)
Implement the forwarder. (public interface, marshaling and sending)
Implement the receiver.
Implement peers of the application.
Implement a start-up configuration.

30. Client-Dispatcher-Server
Client-Dispatcher-Server introduces an intermediate layer, the dispatcher.
Provides location transparency and hides the details of connection establishment.

31. Problem: Forces to balance
Context: A software system integrating a set of distributed servers (local and global servers).
Problem: Forces to balance
Use a service independent of location of the service provider.
Code used for implementation of core functionality should be separate from code used to establish connection.
Solution:
Provide a dispatcher component between clients and servers. It implements a name service that allows referring by names instead of physical locations.
It is responsible for connection establishment between clients and servers.

32. Structure:

33. Static Relationships

34. Dynamics

35. Implementation: Steps
Separate the applications into clients and servers.
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.

36. Variants: Known Uses: Distributed Dispatchers.
Client-Dispatcher-Server with communication managed by clients.
Client-Dispatcher-Server with heterogeneous communication.
Client-Dispatcher-Service.
Known Uses:
Sun’s Remote Procedure Calls.
OMG Corba (Common Object Request Broker Architecture)

37. Consequences Benefits Liabilities Exchangeability of servers.
Location and migration transparency.
Re-configuration.
Fault tolerance.
Lower efficiency through indirection and explicit connection establishment.
Sensitivity to change of the dispatcher.

38. Publisher-Subscriber
Also known as: Observer, Dependents.
Problem: Forces to balance
One or more components must be notified about change in a component.
The number and identities of dependents is not known a priori and may change over time.
Explicit polling by dependents is not feasible.
Publisher and dependents should not be tightly coupled.

39. Solution:
Publisher maintains a registry of currently-subscribed components.
When publisher changes state, it sends a notification to all its subscribers.
Push model – Publisher sends all the changed data when it notifies subscribers.
Pull model – Publisher sends minimal information, subscribers are responsible for retrieving the data.

40. Variants: Gatekeeper: Distributed systems.
Event Channel: Proxy publishers and subscribers.