1. D7032E – Software Engineering
Lecture 12 – Architectural Patterns

2. Architectural Patterns
Deals with how to design systems
To be easy to understand
To be modular, flexible, modifiable, etc.
Think “Design for Quality attributes”

3. Overview Layer Pattern Broker Pattern Model-View-Controller Pattern
Pipe and Filter Pattern
Client-Server Pattern
Peer-to-Peer Pattern
Service Oriented Architecture Pattern
Publish-Subscribe Pattern
Shared-Data Pattern
Map-Reduce Pattern
Multi-Tier Pattern

4. Layer Pattern Context: Problem:
the system need a clear and well-documented separation of concerns,
modules of the system may be independently developed
Problem:
The software needs to be segmented
modules can be developed and evolved separately
little interaction among the parts
supporting portability, modifiability, and reuse.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

5. Layer Pattern Example
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

6. Or more commonly
“sidecars”
Segmented layers

7. Why and when?
What benefits would this have for designing your architecture?
When is it good to use this?

8. Layer Pattern Solution
Relations: Allowed to use.
Constraints:
Every piece of software is allocated to exactly one layer.
There are at least two layers
The allowed-to-use relations should not be circular
Weaknesses:
The addition of layers adds up-front cost and complexity
Layers contribute a performance penalty.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

9. Broker Pattern Context: Problem:
collection of services distributed across multiple servers.
how the systems will interoperate
how they will connect to each other
how they will exchange information
Problem:
How do we structure distributed software
service users should not need to know the nature and location of service providers
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

10. Broker Example
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

11. Broker Solution Weaknesses: Brokers add latency, may be a bottleneck.
The broker can be a single point of failure.
A broker adds up-front complexity.
A broker may be a target for security attacks.
A broker may be difficult to test.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

12. Model-View-Controller Pattern
Context:
User interface software are frequently modified
Users often wish to have different views of the same data
Problem:
How can user interface functionality be kept separate from application functionality?
How can multiple views of the user interface be created, maintained, and coordinated?
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

13. MVC Example
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

14. Or simply…

15. Why and when? When is it good to use the MVC pattern?
When is it not good to use the MVC pattern?

16. MVC Solution Weaknesses:
The complexity may not be worth it for simple user interfaces.
The model, view, and controller abstractions may not be good fits for some user interface toolkits

17. Pipe and Filter Pattern
Context:
A system is required to transform streams of discrete data items
Many types of transformations occur repeatedly in practice
Problem:
How to divide into reusable, loosely coupled components
Simple, generic interaction mechanisms
Flexibly combined with each other.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

18. Unix Pipe and Filter example
The following pipe consists of the commands ls, grep, and sort:
$ls -l | grep "Aug" | sort +4n | more
-rw-rw-r-- 1 carol doc Aug 23 07:35 macros
-rw-rw-r-- 1 john doc Aug 15 10:51 intro
-rw-rw-rw- 1 john doc Aug 6 15:30 ch07
-rw-rw-r-- 1 john doc Aug 9 12:40 ch03 .
-rw-rw-rw- 1 john doc Aug 6 15:56 ch05
--More--(74%)

19. Pipe and Filter Example
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

20. Why and when? Why would you use the Pipe & Filter pattern?
When would you use the Pipe & Filter pattern?

21. Pipe and filter Constraints
Connected filters must agree on the type of data being passed along the connecting pipe.

22. Service Oriented Architecture Pattern
Context:
A number of services are offered by service providers and consumed by service consumers.
Service consumers need to be able to understand and use these services without any detailed knowledge of their implementation.
Problem:
interoperability of distributed components
running on different platforms
written in different implementation languages
provided by different organizations
distributed across the Internet (or other networks)
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

23. Service Oriented Architecture Example
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

24. Why and when?
When is it good to use SOA?

25. Service Oriented Architecture Solution
Connectors:
SOAP connector, which uses the SOAP protocol for synchronous communication between web services, typically over HTTP.
Defines messaging framework
REST connector, which relies on the basic request/reply operations of the HTTP protocol.
Asynchronous messaging connector, which uses a messaging system to offer point-to-point or publish-subscribe asynchronous message exchanges.
SOAP: Simple Object Protocol, REST : Representational state transfer
(WSDL : Web Services DescriptionLanguage)
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

26. Service Oriented Architecture
Weaknesses:
SOA-based systems are typically complex to build.
You don’t control the evolution of independent services.
There is a performance overhead associated with the middleware, and services may be performance bottlenecks, and typically do not provide performance guarantees.

27. Map-Reduce Pattern
Context: Businesses have a pressing need to quickly analyze enormous volumes of data
at petabyte scale.
Problem: efficiently perform a distributed and parallel sort of a large data set and provide a simple means for the programmer to specify the analysis to be done.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

28. Map-Reduce Example
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

29. Scenario Key-value pair files, imagine 5 files
Temperature, task to find highest temp:
Toronto, 20
Whitby, 25
New York, 22
Split into 5 processes (one per file)
(Toronto, 18) (Whitby, 27) (New York, 32) (Rome, 37)(Toronto, 32) (Whitby, 20) (New York, 33) (Rome, 38)(Toronto, 22) (Whitby, 19) (New York, 20) (Rome, 31)(Toronto, 31) (Whitby, 22) (New York, 19) (Rome, 30)
Merge results and reduce the result (highest temp per town)
(Toronto, 32) (Whitby, 27) (New York, 33) (Rome, 38)

30. function Map is
input: integer K1 between 1 and 1100, representing a batch of 1 million social.person records
for each social.person record in the K1 batch do
let Y be the person's age
let N be the number of contacts the person has
produce one output record (Y,(N,1))
repeat
end function
function Reduce is
input: age (in years) Y
for each input record (Y,(N,C)) do
Accumulate in S the sum of N*C
Accumulate in Cnew the sum of C
let A be S/Cnew
produce one output record (Y,(A,Cnew))

31. Map-Reduce Solution Constraints:
Map functions are stateless and do not communicate with each other.
The only communication between map reduce instances is the data emitted from the map instances as <key, value> pairs.
Weaknesses:
If you do not have large data sets, the overhead of map-reduce is not justified.
If you cannot divide your data set into similar sized subsets, the advantages of parallelism are lost.
Operations that require multiple reduces are complex to orchestrate.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

32. Multi-Tier Pattern Context: Problem:
In a distributed deployment, there is often a need to distribute a system’s infrastructure into distinct subsets.
Problem:
How can we split the system into a number of computationally independent execution structures—groups of software and hardware—connected by some communications media?
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

33. Multi-Tier Example
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

34. Multi-Tier Layered ArchitectureUI
tier
Business services
tier
Data model
tier

35. Multi-Tier Solution
Constraints: A software component belongs to exactly one tier.
Weaknesses: Substantial up-front cost and complexity.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

36. Summary An architectural pattern
is a package of design decisions that is found repeatedly in practice,
has known properties that permit reuse, and
describes a class of architectures.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License