D7032E – Software Engineering Lecture 12 – Architectural Patterns

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

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

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

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

Or more commonly “sidecars” Segmented layers

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

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

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

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

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

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

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

Or simply…

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

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

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

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 1605 Aug 23 07:35 macros -rw-rw-r-- 1 john doc 2488 Aug 15 10:51 intro -rw-rw-rw- 1 john doc 8515 Aug 6 15:30 ch07 -rw-rw-r-- 1 john doc 14827 Aug 9 12:40 ch03 . -rw-rw-rw- 1 john doc 16867 Aug 6 15:56 ch05 --More--(74%)

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

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

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

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

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

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

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

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.

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

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

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)

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))

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

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

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

Multi-Tier Layered Architecture UI tier Business services tier Data model tier

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

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