Lecture 07 Tactics, Patterns and Modelling

Lecture 07 Tactics, Patterns and Modelling
CSCE 742 Software Architectures Lecture 07 Tactics, Patterns and Modelling Topics Chapter 12 Other Quality attributes Chapter 13 Tactics and Chapter 14 Usability May 31, 2017

Chapter 12 Outline Other Important Quality Attributes
Other Categories of Quality Attributes Software Quality Attributes and System Quality Attributes Using Standard Lists of Quality Attributes Dealing with “X-ability” Summary © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Outline Modeling Architectures to Enable Quality Attribute Analysis Quality Attribute Checklists Thought Experiments and Back-of-the-Envelope Analysis Experiments, Simulations, and Prototypes Analysis at Different Stages of the Life Cycle © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Modeling Architectures to Enable Quality Attribute Analysis
Some quality attributes, most notably performance and availability, have well-understood, time-tested analytic models that can be used to assist in an analysis. By analytic model, we mean one that supports quantitative analysis. Let us first consider performance. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Performance Models arrivals queue server results Scheduling algorithm Routing of messages Parameters: arrival rate of events, chosen queuing discipline, chosen scheduling algorithm, service time for events, network topology, network bandwidth, routing algorithm chosen © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Allocation Model for MVC
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

Queuing Model for MVC Arrivals View sends requests to Controller
Users Generate Requests Controller Model 1 3 2 4 5 Arrivals View sends requests to Controller Actions returned to View Actions returned to model Model sends actions to View © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Parameters The frequency of arrivals from outside the system
To solve a queuing model for MVC performance, the following parameters must be known or estimated: The frequency of arrivals from outside the system The queuing discipline used at the view queue The time to process a message within the view The number and size of messages that the view sends to the controller The bandwidth of the network that connects the view and the controller The queuing discipline used by the controller The time to process a message within the controller The number and size of messages that the controller sends back to the view The bandwidth of the network from the controller to the view The number and size of messages that the controller sends to the model The queuing discipline used by the model The time to process a message within the model The number and size of messages the model sends to the view The bandwidth of the network connecting the model and the view © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Cost/benefit of Performance Modeling
Cost: determining the parameters previously mentioned Benefit: estimate of the latency The more accurately the parameters can be estimated, the better the predication of latency. This is worthwhile when latency is important and questionable. This is not worthwhile when it is obvious there is sufficient capacity to satisfy the demand. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Availability Modeling
Another quality attribute with a well-understood analytic framework is availability. Modeling an architecture for availability—or to put it more carefully, modeling an architecture to determine the availability of a system based on that architecture—is a matter of determining the failure rates and the recovery times of the components. Just as for performance, to model an architecture for availability, we need an architecture to analyze. Suppose we want to increase the availability of a system that uses the Broker pattern, by applying redundancy tactics. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Three different tactics for increasing the availability of the broker are: active redundancy (hot spare) passive redundancy (warm spare) spare (cold spare). © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Making Broker More Available
Key: process: message: © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Applying Probabilities to Tactics
Using probabilities to model different tactics When two events A and B are independent, the probability that A or B will occur is the sum of the probability of each event: P(A or B) = P(A)+ P(B). When two events A and B are independent, the probability of both occurring is P(A and B) = P(A) • P(B). When two events A and B are dependent, the probability of both occurring is P(A and B) = P(A) • P(B|A), where the last term means “the probability of B occurring, given that A occurs.” © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Passive Redundancy Assume
failure of a component (primary or backup) is independent of the failure of its counterpart assume failure probability of both is the same: P(F) Then probability that both will fail is: 1 - P(F)2 Can also estimate probability of failure given other tactics. Then given a cost of implementing appropriate tactic we can do cost/benefit analysis © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Calculated Availability for an Availability-Enhanced Broker
© Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Maturity of Quality Attribute Models
Intellectual Basis Maturity / Gaps Availability Markov models; Statistical models Moderate maturity in the hardware reliability domain, less mature in the software domain. Requires models that speak to state recovery and for which failure percentages can be attributed to software. Interoperability Conceptual framework Low maturity; models require substantial human interpretation and input. Modifiability Coupling and cohesion metrics; Cost models Substantial research in academia; still requires more empirical support in real-world environments. Performance Queuing theory; Real time scheduling theory High maturity; requires considerable education and training to use properly. Security No architectural models Testability Component Interaction Metrics Low maturity; little empirical validation. Usability © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Quality Attribute Checklists
A quality attribute checklist provides a means of: Checking requirements. Do the requirements capture all of the nuances of a particular quality attribute? Auditing. Does the design satisfy all of the aspects necessary for a certification process. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Security Checklists Security checklists are common.
Vendors who accept credit cards should conform to the PCI (Personal Credit Information) standard Electricity producers have security checklists to prevent attacks on critical infrastructure Checklists have both: Product requirements. E.g. the PCI checklist states that the security code on the back of the credit card should never be stored. Process requirements. E.g. patches should be applied promptly and there should be someone who has the organizational responsibility to ensure that they are. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Thought Experiments A thought experiment is mentally or verbally working through a particular scenario. Commonly done by the architect during design to explore alternatives. Also done during evaluation/documentation to convince third parties of the wisdom of particular design choices © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Thought Experiment Steps
Enumerate the steps of a use case At each step, ask {yourself, the architect} What mechanism is being implemented to support the achievement of which particular quality requirement? Does this mechanism hinder the achievement of other quality attribute requirements? Record problems for later deeper analysis or prototype building © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Back-of-the-Envelope Analysis
Analysis does not need to be precise or detailed. Rough analysis serves for many purposes. E.g. “the volume of traffic generated by this source should be well within the bounds handled by modern infrastructure” Only do deeper analysis for questionable areas or important requirements. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Experiments, Simulations, and Prototypes
Many tools can help perform experiments to determine behavior of a design Request generators can create synthetic loads to test scalability Monitors can perform non-intrusive resource usage detection. These depend on having a partial or prototype implementation. Prototype alternatives for the most important decisions If possible, implement prototype in a fashion so that some of it can be re-used. Fault injection tools can induce faults to determine response of system under failure conditions. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Simulations Event based simulators exist that can be used to simulate behavior of system under various loads Must create the simulation. Must have a variety of different loads and responses to check for. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Analysis During Requirements and Design
Different types of analysis are done at different stages of the life cycle Requirements: Analytic models/back of the envelope analysis can help capacity planning Checklists can help ensure capture correct set of requirements Design: Prototypes can help explore design options Analytic models or simulation can help understand potential bottlenecks Checklists can help determine if used a correct mechanism © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Analysis During Implementation or Fielding
Experiments and synthetic load tests can be used during the implementation process or after fielding Monitors can be used after fielding to determine actual behavior and find bottlenecks. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Analysis at Different Stages of the Lifecycle
Life-Cycle Stage Form of Analysis Cost Confidence Requirements Experience-based analogy Low Low-High Back-of-the-envelope Low-Medium Architecture Thought experiment Checklist Medium Analytic Model Simulation Prototype Medium-High Implementation Experiment Fielded System Instrumentation High © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Summary Analysis is always a cost/benefit activity
Cost is measure of creating and executing the analysis models and tools Benefit depends on Accuracy of analysis Importance of what is being analyzed Analysis can be done through Models for some attributes Measurement Thought experiments Simulations Prototypes © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Other Important Quality Attributes
Variability: is a special form of modifiability. It refers to the ability of a system and its supporting artifacts to support the production of a set of variants that differ from each other in a preplanned fashion. Portability: is also a special form of modifiability. Portability refers to the ease with which software that built to run on one platform can be changed to run on a different platform. Development Distributability: is the quality of designing the software to support distributed software development. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Scalability: Horizontal scalability (scaling out) refers to adding more resources to logical units such as adding another server to a cluster. Vertical scalability (scaling up) refers to adding more resources to a physical unit such as adding more memory to a computer. Deployability: is concerned with how an executable arrives at a host platform and how it is invoked. Mobility: deals with the problems of movement and affordances of a platform (e.g. size, type of display, type of input devices, availability and volume of bandwidth, and battery life). © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Monitorability: deals with the ability of the operations staff to monitor the system while it is executing. Safety: Software safety is about the software’s ability to avoid entering states that cause or lead to damage, injury, or loss of life, and to recover and limit the damage when it does enter into bad states. The architectural concerns with safety are almost identical with those for availability (i.e. preventing, detecting, and recovering from failures). © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Other Categories of Quality Attributes
Conceptual Integrity: refers to consistency in the design of the architecture. It contributes to the understandability of the architecture. Conceptual integrity demands that the same thing is done in the same way through the architecture. Marketability: Some systems are marketed by their architectures, and these architectures sometimes carry a meaning all their own, independent of what other quality attributes they bring to the system (e.g. service-oriented or cloud-based). © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Other Categories of Quality Attributes
Quality in Use: qualities that pertain to the use of the system by various stakeholders. For example Effectiveness: a measure whether the system is correct Efficiency: the effort and time required to develop a system Freedom from risk: degree to which a product or system affects economic status, human life, health, or the environment © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Software Quality Attributes and System Quality Attributes
Physical systems, such as aircraft or automobiles or kitchen appliances, that rely on software embedded within are designed to meet a whole other litany of quality attributes: weight, size, electric consumption, power output, pollution output, weather resistance, battery life, and on and on. The software architecture can have a substantial effect on the system’s quality attributes. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Standard Lists of Quality Attributes
ISO/IEC FCD Product Quality Standard © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Advantages: Can be helpful checklists to assist requirements gatherers in making sure that no important needs were overlooked. Can serve as the basis for creating your own checklist that contains the quality attributes of concern in your domain, your industry, your organization, your products, … © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Disadvantages: No list will ever be complete. Lists often generate more controversy than understanding. Lists often purport to be taxonomies. But what is a denial-of-service attack? They force architects to pay attention to every quality attribute on the list, even if only to finally decide that the particular quality attribute is irrelevant to their system. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Dealing with “X-ability”
Suppose you must deal with a quality attribute for which there is no compact body of knowledge, e.g. green computing. What do you do? Model the quality attribute Assemble a set of tactics for the quality attribute Construct design checklists © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Summary There are many other quality attributes than the seven that we cover in detail. Taxonomies of attributes may offer some help, but their disadvantages often outweigh their advantages. You may need to design or analyze a system for a “new” quality attribute. While this may be challenging, it is doable. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Chapter 13: Patterns and Tactics Outline
What is a Pattern? Pattern Catalogue Module patterns Component and Connector Patterns Allocation Patterns Relation Between Tactics and Patterns Using tactics together Summary © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

What is a Pattern? An architectural pattern establishes a relationship between: A context. A recurring, common situation in the world that gives rise to a problem. A problem. The problem, appropriately generalized, that arises in the given context. A solution. A successful architectural resolution to the problem, appropriately abstracted. The solution for a pattern is determined and described by: A set of element types (for example, data repositories, processes, and objects) A set of interaction mechanisms or connectors (for example, method calls, events, or message bus) A topological layout of the components A set of semantic constraints covering topology, element behavior, and interaction mechanisms © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Layer Pattern Context: All complex systems experience the need to develop and evolve portions of the system independently. For this reason the developers of the system need a clear and well-documented separation of concerns, so that modules of the system may be independently developed and maintained. Problem: The software needs to be segmented in such a way that the modules can be developed and evolved separately with little interaction among the parts, supporting portability, modifiability, and reuse. Solution: To achieve this separation of concerns, the layered pattern divides the software into units called layers. Each layer is a grouping of modules that offers a cohesive set of services. The usage must be unidirectional. Layers completely partition a set of software, and each partition is exposed through a public interface. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

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

Layer Pattern Solution
Overview: The layered pattern defines layers (groupings of modules that offer a cohesive set of services) and a unidirectional allowed-to-use relation among the layers. Elements: Layer, a kind of module. The description of a layer should define what modules the layer contains. Relations: Allowed to use. The design should define what the layer usage rules are and any allowable exceptions. Constraints: Every piece of software is allocated to exactly one layer. There are at least two layers (but usually there are three or more). The allowed-to-use relations should not be circular (i.e., a lower layer cannot use a layer above). Weaknesses: The addition of layers adds up-front cost and complexity to a system. Layers contribute a performance penalty. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Broker Pattern Context: Many systems are constructed from a collection of services distributed across multiple servers. Implementing these systems is complex because you need to worry about how the systems will interoperate—how they will connect to each other and how they will exchange information—as well as the availability of the component services. Problem: How do we structure distributed software so that service users do not need to know the nature and location of service providers, making it easy to dynamically change the bindings between users and providers? Solution: The broker pattern separates users of services (clients) from providers of services (servers) by inserting an intermediary, called a broker. When a client needs a service, it queries a broker via a service interface. The broker then forwards the client’s service request to a server, which processes the request. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

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

Broker Solution – 1 Overview: The broker pattern defines a runtime component, called a broker, that mediates the communication between a number of clients and servers. Elements: Client, a requester of services Server, a provider of services Broker, an intermediary that locates an appropriate server to fulfill a client’s request, forwards the request to the server, and returns the results to the client Client-side proxy, an intermediary that manages the actual communication with the broker, including marshaling, sending, and unmarshaling of messages Server-side proxy, an intermediary that manages the actual communication with the broker, including marshaling, sending, and unmarshaling of messages

Broker Solution - 2 Relations: The attachment relation associates clients (and, optionally, client-side proxies) and servers (and, optionally, server-side proxies) with brokers. Constraints: The client can only attach to a broker (potentially via a client-side proxy). The server can only attach to a broker (potentially via a server-side proxy). Weaknesses: Brokers add a layer of indirection, and hence latency, between clients and servers, and that layer may be a communication 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, under Creative Commons Attribution License

Model-View-Controller Pattern
Context: User interface software is typically the most frequently modified portion of an interactive application. Users often wish to look at data from different perspectives, such as a bar graph or a pie chart. These representations should both reflect the current state of the data. Problem: How can user interface functionality be kept separate from application functionality and yet still be responsive to user input, or to changes in the underlying application’s data? And how can multiple views of the user interface be created, maintained, and coordinated when the underlying application data changes? Solution: The model-view-controller (MVC) pattern separates application functionality into three kinds of components: A model, which contains the application’s data A view, which displays some portion of the underlying data and interacts with the user A controller, which mediates between the model and the view and manages the notifications of state changes © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

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

MVC Solution - 1 Overview: The MVC pattern breaks system functionality into three components: a model, a view, and a controller that mediates between the model and the view. Elements: The model is a representation of the application data or state, and it contains (or provides an interface to) application logic. The view is a user interface component that either produces a representation of the model for the user or allows for some form of user input, or both. The controller manages the interaction between the model and the view, translating user actions into changes to the model or changes to the view. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

MVC Solution - 2 Relations: The notifies relation connects instances of model, view, and controller, notifying elements of relevant state changes. Constraints: There must be at least one instance each of model, view, and controller. The model component should not interact directly with the controller. 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. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Pipe and Filter Pattern
Context: Many systems are required to transform streams of discrete data items, from input to output. Many types of transformations occur repeatedly in practice, and so it is desirable to create these as independent, reusable parts. Problem: Such systems need to be divided into reusable, loosely coupled components with simple, generic interaction mechanisms. In this way they can be flexibly combined with each other. The components, being generic and loosely coupled, are easily reused. The components, being independent, can execute in parallel. Solution: The pattern of interaction in the pipe-and-filter pattern is characterized by successive transformations of streams of data. Data arrives at a filter’s input port(s), is transformed, and then is passed via its output port(s) through a pipe to the next filter. A single filter can consume data from, or produce data to, one or more ports. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Pipe and Filter Example

Pipe and Filter Solution
Overview: Data is transformed from a system’s external inputs to its external outputs through a series of transformations performed by its filters connected by pipes. Elements: Filter, which is a component that transforms data read on its input port(s) to data written on its output port(s). Pipe, which is a connector that conveys data from a filter’s output port(s) to another filter’s input port(s). A pipe has a single source for its input and a single target for its output. A pipe preserves the sequence of data items, and it does not alter the data passing through. Relations: The attachment relation associates the output of filters with the input of pipes and vice versa. Constraints: Pipes connect filter output ports to filter input ports. Connected filters must agree on the type of data being passed along the connecting pipe. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Client-Server Pattern
Context: There are shared resources and services that large numbers of distributed clients wish to access, and for which we wish to control access or quality of service. Problem: By managing a set of shared resources and services, we can promote modifiability and reuse, by factoring out common services and having to modify these in a single location, or a small number of locations. We want to improve scalability and availability by centralizing the control of these resources and services, while distributing the resources themselves across multiple physical servers. Solution: Clients interact by requesting services of servers, which provide a set of services. Some components may act as both clients and servers. There may be one central server or multiple distributed ones. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Client-Server Example

Client-Server Solution - 1
Overview: Clients initiate interactions with servers, invoking services as needed from those servers and waiting for the results of those requests. Elements: Client, a component that invokes services of a server component. Clients have ports that describe the services they require. Server: a component that provides services to clients. Servers have ports that describe the services they provide. Request/reply connector: a data connector employing a request/reply protocol, used by a client to invoke services on a server. Important characteristics include whether the calls are local or remote, and whether data is encrypted. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Client-Server Solution- 2
Relations: The attachment relation associates clients with servers. Constraints: Clients are connected to servers through request/reply connectors. Server components can be clients to other servers. Weaknesses: Server can be a performance bottleneck. Server can be a single point of failure. Decisions about where to locate functionality (in the client or in the server) are often complex and costly to change after a system has been built. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Peer-to-Peer Pattern Context: Distributed computational entities—each of which is considered equally important in terms of initiating an interaction and each of which provides its own resources—need to cooperate and collaborate to provide a service to a distributed community of users. Problem: How can a set of “equal” distributed computational entities be connected to each other via a common protocol so that they can organize and share their services with high availability and scalability? Solution: In the peer-to-peer (P2P) pattern, components directly interact as peers. All peers are “equal” and no peer or group of peers can be critical for the health of the system. Peer-to-peer communication is typically a request/reply interaction without the asymmetry found in the client-server pattern. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Peer-to-Peer Example © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Peer-to-Peer Solution - 1
Overview: Computation is achieved by cooperating peers that request service from and provide services to one another across a network. Elements: Peer, which is an independent component running on a network node. Special peer components can provide routing, indexing, and peer search capability. Request/reply connector, which is used to connect to the peer network, search for other peers, and invoke services from other peers. In some cases, the need for a reply is done away with. Relations: The relation associates peers with their connectors. Attachments may change at runtime. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Peer-to-Peer Solution - 2
Constraints: Restrictions may be placed on the following: The number of allowable attachments to any given peer The number of hops used for searching for a peer Which peers know about which other peers Some P2P networks are organized with star topologies, in which peers only connect to supernodes. Weaknesses: Managing security, data consistency, data/service availability, backup, and recovery are all more complex. Small peer-to-peer systems may not be able to consistently achieve quality goals such as performance and availability. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Service Oriented Architecture Pattern
Context: A number of services are offered (and described) 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: How can we support interoperability of distributed components running on different platforms and written in different implementation languages, provided by different organizations, and distributed across the Internet? Solution: The service-oriented architecture (SOA) pattern describes a collection of distributed components that provide and/or consume services. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Service Oriented Architecture Example

Service Oriented Architecture Solution - 1
Overview: Computation is achieved by a set of cooperating components that provide and/or consume services over a network. Elements: Components: Service providers, which provide one or more services through published interfaces. Service consumers, which invoke services directly or through an intermediary. Service providers may also be service consumers. ESB, which is an intermediary element that can route and transform messages between service providers and consumers. Registry of services, which may be used by providers to register their services and by consumers to discover services at runtime. Orchestration server, which coordinates the interactions between service consumers and providers based on languages for business processes and workflows. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Connectors: SOAP connector, which uses the SOAP protocol for synchronous communication between web services, typically over HTTP. 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. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Relations: Attachment of the different kinds of components available to the respective connectors Constraints: Service consumers are connected to service providers, but intermediary components (e.g., ESB, registry, orchestration server) may be used. 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. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Publish-Subscribe Pattern
Context: There are a number of independent producers and consumers of data that must interact. The precise number and nature of the data producers and consumers are not predetermined or fixed, nor is the data that they share. Problem: How can we create integration mechanisms that support the ability to transmit messages among the producers and consumers so they are unaware of each other’s identity, or potentially even their existence? Solution: In the publish-subscribe pattern, components interact via announced messages, or events. Components may subscribe to a set of events. Publisher components place events on the bus by announcing them; the connector then delivers those events to the subscriber components that have registered an interest in those events. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Publish-Subscribe Example

Publish-Subscribe Solution – 1
Overview: Components publish and subscribe to events. When an event is announced by a component, the connector infrastructure dispatches the event to all registered subscribers. Elements: Any C&C component with at least one publish or subscribe port. The publish-subscribe connector, which will have announce and listen roles for components that wish to publish and subscribe to events. Relations: The attachment relation associates components with the publish-subscribe connector by prescribing which components announce events and which components are registered to receive events. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Publish-Subscribe Solution - 2
Constraints: All components are connected to an event distributor that may be viewed as either a bus—connector—or a component. Publish ports are attached to announce roles and subscribe ports are attached to listen roles. Weaknesses: Typically increases latency and has a negative effect on scalability and predictability of message delivery time. Less control over ordering of messages, and delivery of messages is not guaranteed. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Shared-Data Pattern Context: Various computational components need to share and manipulate large amounts of data. This data does not belong solely to any one of those components. Problem: How can systems store and manipulate persistent data that is accessed by multiple independent components? Solution: In the shared-data pattern, interaction is dominated by the exchange of persistent data between multiple data accessors and at least one shared-data store. Exchange may be initiated by the accessors or the data store. The connector type is data reading and writing. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Shared Data Example © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Shared Data Solution - 1 Overview: Communication between data accessors is mediated by a shared data store. Control may be initiated by the data accessors or the data store. Data is made persistent by the data store. Elements: Shared-data store. Concerns include types of data stored, data performance-oriented properties, data distribution, and number of accessors permitted. Data accessor component. Data reading and writing connector. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Shared Data Solution - 2 Relations: Attachment relation determines which data accessors are connected to which data stores. Constraints: Data accessors interact only with the data store(s). Weaknesses: The shared-data store may be a performance bottleneck. The shared-data store may be a single point of failure. Producers and consumers of data may be tightly coupled. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Map-Reduce Pattern Context: Businesses have a pressing need to quickly analyze enormous volumes of data they generate or access, at petabyte scale. Problem: For many applications with ultra-large data sets, sorting the data and then analyzing the grouped data is sufficient. The problem the map-reduce pattern solves is to 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. Solution: The map-reduce pattern requires three parts: A specialized infrastructure takes care of allocating software to the hardware nodes in a massively parallel computing environment and handles sorting the data as needed. A programmer specified component called the map which filters the data to retrieve those items to be combined. A programmer specified component called reduce which combines the results of the map © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

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

Map-Reduce Solution - 1 Overview: The map-reduce pattern provides a framework for analyzing a large distributed set of data that will execute in parallel, on a set of processors. This parallelization allows for low latency and high availability. The map performs the extract and transform portions of the analysis and the reduce performs the loading of the results. Elements: Map is a function with multiple instances deployed across multiple processors that performs the extract and transformation portions of the analysis. Reduce is a function that may be deployed as a single instance or as multiple instances across processors to perform the load portion of extract-transform-load. The infrastructure is the framework responsible for deploying map and reduce instances, shepherding the data between them, and detecting and recovering from failure. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Map-Reduce Solution - 2 Relations:
Deploy on is the relation between an instance of a map or reduce function and the processor onto which it is installed. Instantiate, monitor, and control is the relation between the infrastructure and the instances of map and reduce. Constraints: The data to be analyzed must exist as a set of files. 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, under Creative Commons Attribution License

Multi-Tier Pattern Context: 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? Solution: The execution structures of many systems are organized as a set of logical groupings of components. Each grouping is termed a tier. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

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

Multi-Tier Solution Overview: The execution structures of many systems are organized as a set of logical groupings of components. Each grouping is termed a tier. Elements: Tier, which is a logical grouping of software components. Relations: Is part of, to group components into tiers. Communicates with, to show how tiers and the components they contain interact with each other. Allocated to, in the case that tiers map to computing platforms. Constraints: A software component belongs to exactly one tier. Weaknesses: Substantial up-front cost and complexity. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Relationships Between Tactics and Patterns
Patterns are built from tactics; if a pattern is a molecule, a tactic is an atom. MVC, for example utilizes the tactics: Increase semantic coherence Encapsulation Use an intermediary Use run time binding © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Tactics Augment Patterns
Patterns solve a specific problem but are neutral or have weaknesses with respect to other qualities. Consider the broker pattern May have performance bottlenecks May have a single point of failure Using tactics such as Increase resources will help performance Maintain multiple copies will help availability © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Tactics and Interactions
Each tactic has pluses (its reason for being) and minuses – side effects. Use of tactics can help alleviate the minuses. But nothing is free… © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Tactics and Interactions - 2
A common tactic for detecting faults is Ping/Echo. Common side-effects of Ping/Echo are: security: how to prevent a ping flood attack? performance: how to ensure that the performance overhead of ping/echo is small? modifiability: how to add ping/echo to the existing architecture? Tactic is fine grain adjustment of quality attributes within a pattern © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

System Ping/Echo Add to system Ping flood Performance overhead Tactic is fine grain adjustment of quality attributes within a pattern © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

A tactic to address the performance side-effect is “Increase Available Resources”. Common side effects of Increase Available Resources are: cost: increased resources cost more performance: how to utilize the increase resources efficiently? Tactic is fine grain adjustment of quality attributes within a pattern © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

System Ping/Echo Add to system Ping flood Performance overhead Increase Available Resources Cost Resource Utilization Tactic is fine grain adjustment of quality attributes within a pattern © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

A tactic to address the efficient use of resources side-effect is “Scheduling Policy”. Common side effects of Scheduling Policy are: modifiability: how to add the scheduling policy to the existing architecture modifiability: how to change the scheduling policy in the future? Tactic is fine grain adjustment of quality attributes within a pattern © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

System Ping/Echo Add to system Ping flood Performance overhead Increase Available Resources Cost Resource Utilization Scheduling Policy Modify policy Tactic is fine grain adjustment of quality attributes within a pattern © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

A tactic to address the addition of the scheduler to the system is “Use an Intermediary”. Common side effects of Use an Intermediary are: modifiability: how to ensure that all communication passes through the intermediary? Tactic is fine grain adjustment of quality attributes within a pattern © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

System Ping/Echo Add to system Ping flood Performance overhead Increase Available Resources Cost Resource Utilization Scheduling Policy Modify policy Use an Intermediary Ensure usage Tactic is fine grain adjustment of quality attributes within a pattern © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Tactics and Interactions – 10.
A tactic to address the concern that all communication passes through the intermediary is “Restrict Communication Paths”. Common side effects of Restrict Communication Paths are: performance: how to ensure that the performance overhead of the intermediary are not excessive? Note: this design problem has now become recursive! Tactic is fine grain adjustment of quality attributes within a pattern © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

How Does This Process End?
Each use of tactic introduces new concerns. Each new concern causes new tactics to be added. Are we in an infinite progression? No. Eventually the side-effects of each tactic become small enough to ignore. © Len Bass, Paul Clements, Rick Kazman, 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. Tactics are simpler than patterns Patterns are underspecified with respect to real systems so they have to be augmented with tactics. Augmentation ends when requirements for a specific system are satisfied.

Quality Attribute Modeling and Analysis
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Quality Attribute Modeling and Analysis Outline
Modeling Architectures to Enable Quality Attribute Analysis Quality Attribute Checklists Thought Experiments and Back-of-the-Envelope Analysis Experiments, Simulations, and Prototypes Analysis at Different Stages of the Life Cycle © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Modeling Architectures to Enable Quality Attribute Analysis
Some quality attributes, most notably performance and availability, have well-understood, time-tested analytic models that can be used to assist in an analysis. By analytic model, we mean one that supports quantitative analysis. Let us first consider performance. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Performance Models arrivals queue server results Scheduling algorithm Routing of messages Parameters: arrival rate of events, chosen queuing discipline, chosen scheduling algorithm, service time for events, network topology, network bandwidth, routing algorithm chosen

Allocation Model for MVC

Queuing Model for MVC Arrivals View sends requests to Controller
Users Generate Requests Controller Model 1 3 2 4 5 Arrivals View sends requests to Controller Actions returned to View Actions returned to model Model sends actions to View © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Parameters The frequency of arrivals from outside the system
To solve a queuing model for MVC performance, the following parameters must be known or estimated: The frequency of arrivals from outside the system The queuing discipline used at the view queue The time to process a message within the view The number and size of messages that the view sends to the controller The bandwidth of the network that connects the view and the controller The queuing discipline used by the controller The time to process a message within the controller The number and size of messages that the controller sends back to the view The bandwidth of the network from the controller to the view The number and size of messages that the controller sends to the model The queuing discipline used by the model The time to process a message within the model The number and size of messages the model sends to the view The bandwidth of the network connecting the model and the view © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Cost/benefit of Performance Modeling
Cost: determining the parameters previously mentioned Benefit: estimate of the latency The more accurately the parameters can be estimated, the better the predication of latency. This is worthwhile when latency is important and questionable. This is not worthwhile when it is obvious there is sufficient capacity to satisfy the demand. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Another quality attribute with a well-understood analytic framework is availability. Modeling an architecture for availability—or to put it more carefully, modeling an architecture to determine the availability of a system based on that architecture—is a matter of determining the failure rates and the recovery times of the components. Just as for performance, to model an architecture for availability, we need an architecture to analyze. Suppose we want to increase the availability of a system that uses the Broker pattern, by applying redundancy tactics. © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Three different tactics for increasing the availability of the broker are: active redundancy (hot spare) passive redundancy (warm spare) spare (cold spare). © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Making Broker More Available
Key: process: message: © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Applying Probabilities to Tactics
Using probabilities to model different tactics When two events A and B are independent, the probability that A or B will occur is the sum of the probability of each event: P(A or B) = P(A)+ P(B). When two events A and B are independent, the probability of both occurring is P(A and B) = P(A) • P(B). When two events A and B are dependent, the probability of both occurring is P(A and B) = P(A) • P(B|A), where the last term means “the probability of B occurring, given that A occurs.” © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Passive Redundancy Assume
failure of a component (primary or backup) is independent of the failure of its counterpart assume failure probability of both is the same: P(F) Then probability that both will fail is: 1 - P(F)2 Can also estimate probability of failure given other tactics. Then given a cost of implementing appropriate tactic we can do cost/benefit analysis © Len Bass, Paul Clements, Rick Kazman, under Creative Commons Attribution License

Calculated Availability for an Availability-Enhanced Broker