Computer Systems & Architecture Lesson 2 4. Achieving Qualities

Objectives Define the term tactics Describe the fault detection and fault recovery Explain the various tactics in order to achieve quality software

4.1 Introducing tactics What is it that imports portability to one design, high performance to another, and integrability to a third? The achievement of these qualities relies on fundamental design decisions. We will examine these design decisions, which we call tactics.

Recall the vocabulary for availability from chapter 3. A failure occurs when the system no longer delivers a service that is consistent with its specification; this failure is observable by the systems users. A fault has the potential to cause a failure. Recall also that recovery or repair is an important aspect of availability. 4.2 Availability tactics

Fault detection Three widely used tactics for recognizing faults are: –Ping/echo –Heartbeat –Exceptions

Fault recovery Fault recovery consists of preparing for recovery and making the system repair. Some preparation and repair tactics follow: –Voting –Active redundancy –Passive redundancy

Synchronization is the responsibility of the primary component, which may use atomic broadcasts to the secondaries to guarantee synchronization. –Spare –Shadow operation –State resynchronization –Checkpoint/rollback

Fault prevention The following are some fault prevention tactics: –Removal from service –Transactions –Process monitor

4.3 Modifiability tactics Recall from chapter 3 that tactics to control modifiability have as their goal controlling the time and cost to implement, test, and deploy changes. We organize the tactics for modifiability in sets according to their goals. One set has as its goal reducing the number of modules that are directly affected by a change. A second set has as its goal limiting modifications to the localized modules. We use this set of tactics to prevent the ripple effect.

Localize modifications Although there is not necessarily a precise relationship between the number of modules affected by a set of changes and the cost of implementing those changes, restricting modifications to a small set of modules will generally reduce the cost. We identify five types of tactics are: - Maintain semantic coherence - Anticipate expected changes - Generalize the module - Limit possible options

Prevent ripple effects A ripple effect from a modification is the necessity of making changes to modules not directly affected by it. For instance, if module A is changed to accomplish a particular modification, then module B is changed only because of the change to module A. B has to be modified because it depends, in some cases, on A. We begin our discussion of the ripple effect by discussing the various types of dependencies that one module can have on another. We identify eight types:

1.Syntax of - data and service 2.Semantics of - data and service 3.Sequence of - data and control 4.Identify of an interface of A. 5.Location of A 6.Quality of service/data provided by A 7.Existence of A 8.Resource behavior of A

Defer binding time The two tactic categories we have discussed thus far are designed to minimize the number of modules that require changing to implement modifications. Our modifications scenarios include two elements that are not satisfied by reducing the number of modules to be changed – time to deploy and allowing nondevelopers to make change.

Many tactics are intended to have impact at loadtime or runtime, such as the following: –Runtime registration supports plug-and-play operation at the cost of additional overhead to manage the registration. Configuration files are intended to set parameters at startup. Polymorphism allows late binding of method calls. Component replacement allows load time binding. Adherence to defined protocols allows runtime binding of independent processes.

4.4 Performance tactics Recall from chapter 3 that the goal of performance tactics is to generate a response to an event arriving at the system within some time constraint. The event can be single or a stream and is the trigger for a request to perform computation. After an event arrives, either the system is processing on that event or the processing is blocked for some reason. This leads to the two basic contributors to the response time: resource consumption and blocked time.

1.Resource consumption 2.Blocked time –Contention for resources –Availability of resources –Dependency on other computation

Resource demand Event streams are the source of resource demand. Two characteristics of demand are the time between events in a resource stream and how much of a resource is consumed by each request. One tactic for reducing latency is to reduce the resources required for processing an event stream. Ways to do this include the following. –Increase computational efficiency. –Reduce computational overhead.

Another tactic for reducing latency is to reduce the number of events processed. This can be done in one of two fashions. –Manage event rate –Control frequency of sampling –Class or generalization – In object-oriented design systems Other tactics for reducing or managing demand involve controlling the use of resources. –Bound execution time –Bound queue sizes

Resource management Even through the demand for resources may not be controllable, the management of these resources affects response times. Some resource management tactics are: –Introduce concurrency –Maintain multiple copies of either data or computations –Increase available resources

Resource arbitration 1.First in first out 2.Fixed priority scheduling –Semantic importance –Deadline monotonic –Rate monotonic 3.Dynamic priority scheduling: –Round robin –Earliest deadline first 4.Static scheduling

4.5 Security tactics Resisting attacks –Authentic users –Authorize users –Maintain data confidentiality –Maintain integrity –Limit exposure –Limit access Detecting attacks Recovering from attacks

4.6 Testability tactics Input/output –Record/playback –Separate interface from implementation –Specialize access routes/interfaces Internal monitoring –Built-in monitors

4.7 Usability tactics Runtime tactics –Maintain a model of the task –Maintain a model of the user –Maintain a model of the system Design-time tactics –Separate the user interface from the rest of the application

4.8 Relationship of tactics to architectural patterns We have presented a collection of tactics that the architect can use to achieve particular attributes. In fact, an architect usually chooses a pattern or a collection of patterns designed to realize one or more tactics. However, each pattern implements multiple tactics, whether desired or not.

4.9 Architectural patterns and styles An architectural pattern in software, also known as an architectural style, is analogous to an architectural style in buildings, such as Gothic or Greek Revival or Queen Anne. It contains of a few key features and rules for combining them so that architectural integrity is preserved. An architectural pattern is determined by:

A set of element types. A topological layout of he elements indicating their interrelationships. A set of semantic constraints. A set of interaction mechanisms that determine how the elements coordinate through the allowed topology.