Chapter 13 - Patterns and Tactics Flashcards
what is a pattern?
it establishes a relationship between a context, a problem, and a solution
What is a pattern context?
a recurring, common situation in the world that gives rise to a problem
what is a pattern problem
the issue that arises in the given context
what is the pattern solution?
a successful architectural resolution to the problem appropriately abstracted
4 aspects that describe a pattern
- a set of elements
- a set of interactions
- a topological layout of components
- a set of semantic constraints
Layer Pattern: context
there is a need for a clear separation of concerns so that modules of a system may independently developed and maintained
Layer Pattern: problem
the SW needs to be segmented in a way such that modules can be evolved separately with little interaction among parts
Layer Pattern: solution overview
divide software into layers.Each layer contains a cohesive set of services. There is a unidirectional allowed-to-use relation among the layers
Layer Pattern: solution elements (1)
layer
Layer Pattern: solution relations (between elements)
allowed-to-use
Layer Pattern: solution constraints
- each piece of SW only in 1 layer
- must be at least 2 layers
- allowed-to-use relation cannot be circular
Layer Pattern: solution weaknesses
- the addition of layers adds up-front cost and complexity
- additional layers have a performance penalty
Broker Pattern: context
many system are a collection of distributed services. How do several system like this connect to each other and exchange info
Broker Pattern: solution problem
how to structure distributed software so that users do not need to know the nature and location of service providers
Broker Pattern: solution overview
it defines a broker that mediates communication between a number of clients and servers (all communication from client to server goes through broker)
Broker Pattern: solution elements (5)
client - requester of services
server - provider
broker - intermediary
client-size proxy- an intermediary that manages the communication from the clients and forwards that info to broker
server-side proxy- same as above but for server
Broker Pattern: solution relations
the attachment relation associates clients and servers with brokers
Broker Pattern: solution constraints
client and server call only attach to the broker
Broker Pattern: solution weaknesses (5)
- broker adds latency and can become a communication bottleneck
- broke can be single point of failure
- broker add up front complexity
- broker can be target of security attacks
- broker hard to test
Model-View-Controller: context
the UI needs to change often. as the user looks at data it should reflect that data’s current state
Model-View-Controller: problem
how to make interface functionality separate from application functionality and yet still be responsive to user input and/or changes to the data
Model-View-Controller: solution overivew
breaks the system functionality down into 3 components: a model, a view, and a controller
Model-View-Controller: elements
model- represents the app data or state and contains app logic
view - UI component
controller - translates user actions into changes in the model or changes to the view
Model-View-Controller: relations
the notifies relation
connects instances of model, view, and controller notifying elements of relevant state changes
Model-View-Controller: constraints (2)
need at least one model, view, and controller
model should not interact directly with controller (no method calls or events to controller from model)
Model-View-Controller: weaknesses (2)
- complexity not worth it for simple UI
- model, view, and controller abstractions may not be good for some UI toolkits
Pipe and Filter Pattern: context
many system need to repeatedly transform streams of discrete information.
Thus we want certain types of transformations to be reusable pieces
Pipe and Filter Pattern: problem
this kind of system needs to be divided into reusable loosely coupled components with simple, generic interaction mechanisms
Pipe and Filter Pattern: solution overview
the system is composed of pieces called filters that transform their inputs in some way and pass their outputs through a pipe to another component that uses those as inputs for some other transformation.
Pipe and Filter Pattern: elements
filter- a component that transforms inputted data to produce some output
pipe- a connector that takes data from the output of one filter and passes it as input to another filter
Pipe and Filter Pattern: relations
the attachment relation
associates the output of filters with input of pipes and vice versa
Pipe and Filter Pattern: constraints (2)
- pipes connect filter output ports to filter input ports
- connected filters must agree on the type of data being passed along the connecting pipe
Client-Server Pattern: context
there are shared resources and large numbers of distributed clients wish to access and that we want to control access to
Client-Server Pattern: problem
we want to improve scalability and availability by centralizing control of resources and services while they are distributed over many physical servers
Client-Server Pattern: solution overview
clients initiate interactions with servers invoking services as needed from those servers and waiting for the results
Client-Server Pattern: elements
client - a component that invokes services of a server component
server- a component that provides services to clients
request/reply connector- a data connector that is used by clients to invoke services on a server
Client-Server Pattern: relations
that attachment relation
associates clients with servers
Client-Server Pattern: constraint (2)
- clients are connected to servers through request/reply connectors
- server components can be clients to other servers
Client-Server Pattern: weaknesses (3)
- server can be a bottle neck
- server can be single point of failure
- decisions about where to locate functionality are complex and expensive to change later
Peer-to-Peer pattern: context
several equally important computational entities with all their own stuff need to cooperate to provide a service to distributed users
Peer-to-Peer pattern: problem
how are the equal computational entities to be connected via some common protocol so they can organize and share services
Peer-to-Peer pattern: solution overview
computation is achieved by cooperating peers that request service from and provide services to one another across a network
Peer-to-Peer pattern: elements
peer - an independent component running on a network node
request/reply connector- used to connect to the peer network, search for peers, and invoke services from peers
Peer-to-Peer pattern: relations
attachment relations associates peers with their connectors
Peer-to-Peer pattern: constraints (3)
- the number of allowable attachments to any given peer
- number of hops used for searching for a peer
- which peers know about which other peers
Peer-to-Peer pattern: weaknesses (2)
- managing security, data consistency, availability, backup, and recovery all more complex
- small system may not achieve performance and availability goals
Shared-Data Pattern: context
computational components need to share and manipulate large amounts of data
Shared-Data Pattern: problem
how to store data in away where multiple independent components can access it
Shared-Data Pattern: solution overview
communication between data accessors is mediated by a shared data store
Shared-Data Pattern: elements
shared-data store- concerns include types of data stored, performance properties, data distribution, and number of accesors permitted
data accesor component
data read/write connector
Shared-Data Pattern: relations
attachment
determines which data accesors are connected to which data stores
Shared-Data Pattern: constraints (1)
data accesors only interact with data stores
Shared-Data Pattern: weaknesses (3)
- shared data store can be a bottleneck
- data store a single point of failure
- producers and consumers may be tightly coupled
Map-Reduce Pattern: context
business have a need to quickly analyze HUGE volumes of data
Map-Reduce Pattern: problem
for HUGE data sets, organizing and analyzing the group data is sufficient. How do we efficiently do this and make it easy for the programmer
Map-Reduce Pattern: solution overview
an infrastructure that takes care of allocating software to hardware nodes in a massive parallel computing environment
Map-Reduce Pattern: elements
map: a programmer specified component that filters the data to retrieve those items to be combined
reduce: a programmer specified component that combines the results of the map
infrastructure: the framework for deploying the map and reduce instances and shepherding the data between them
Map-Reduce Pattern: relations
-the deploys on relation
between an instance of a map or reduce function and the processor on which its installed
-instantiate, monitor, and control relation between the infrastructure and the instances of map and reduce
Map-Reduce Pattern: constraints (3)
- the data to be analyzed must exist as a set of files
- map functions are stateless and don’t communicate
- maps communicate to reduce through pairs
Map-Reduce Pattern: weaknesses (3)
- too much overhead for smaller data sets
- data needs to be dividable for parallelism
- multiple reduces make it complex
Multi-Tier Pattern: context
often a need to distribute system’s infrastructure into distinct subsets
Multi-Tier Pattern: problem
how to split the system into distinct groups of software and hardware connected by some communications media
Multi-Tier Pattern: solution overview
the execution structures are organized into a set of logical groupings components called tiers
Multi-Tier Pattern: elements
tier: logical grouping of components
Multi-Tier Pattern: relations
is part of relation - groups components into tiers
communicates with relation- shows how components interact with each other
allocated to relation- shows how tiers are mapped to computing platforms
Multi-Tier Pattern: constraints (1)
a software component belongs to one tier
Multi-Tier Pattern: weaknesses (1)
substantial up-front cost and complexity
Why do we rarely use patterns straight out of the box?
because they have weaknesses with respect to other qualities that are important to us
what are tactic side effects
the undesirable effect of applying a tactic. its usually the worsening of some other quality attribute that’s inherent to the tactic
If every tactic has a side-effect and then we apply another tactic to combat that side effect how do we avoid an endless process?
eventually the side effects of applying more tactics become small enough to ignore
