Unit- 3 QUALITY Presented by Sushma Narasimhan Asst. Professor,

Unit- 3 QUALITY Presented by Sushma Narasimhan Asst. Professor,
Computer Science Department Engineered for Tomorrow

Unit- III Understanding Quality Attributes Achieving Quality

Understanding Quality Attributes
Functionality and architecture Architecture and quality attributes System quality attributes Business qualities Architecture qualities

Functionality and architecture
In order to build a house, all the workers such as masons, electricians, plumbers, painters & carpenters have to work co-operatively. Similarly, a task requires that most of the system’s elements work in a co-ordinated manner to complete the job.

Definition What is functionality?
It is the ability of the system to do the work for which it was intended. Functionality and quality attributes are orthogonal. For complex functions such as manipulating graphical images or manipulating enormous database, the choice of architecture will determine the relative level of quality. Quality Functionality

Architecture & Quality Attributes
Architecture is critical for the realization of many system qualities such as performance, reliability, security. System qualities should be designed at the architectural level and evaluated at the architectural level only. Architecture by itself, is unable to achieve qualities. It provides the foundation for achieving quality, only if details are paid attention.

Classes of Quality Attributes
Qualities of the system. availability, modifiability, performance, security, testability, usability, scalability … Business qualities Time to market Cost and benefit Projected lifetime of the system Rollout schedule Qualities of the architecture itself Conceptual integrity, Correctness and completeness Buildability

Contd.. Business qualities (such as time to market) that are affected by the architecture. Qualities of the architecture itself E.g., conceptual integrity, they indirectly affect other qualities, such as modifiability.

System Quality Attributes
System Quality Attribute Problems Quality Attribute Scenarios System-specific scenarios : Availability Scenario Modifiability Scenario

System Quality Attribute Problems
From an architect’s perspective, there are 3 problems related to system quality attributes: Definitions are not operational. A focus of discussion is often on which quality a particular aspect belongs to. Is a system failure an aspect of availability, an aspect of security, or an aspect of usability? All three attribute communities would claim ownership of a system failure.

Contd.. Each attribute community has developed its own vocabulary.
performance community "events" security community  "attacks" the availability community  "failures" the usability community  "user input." All of these may actually refer to the same occurrence. Solution: use quality attribute ‘scenarios’ and unified language

Quality attribute scenarios
Quality attribute scenarios are a means of characterizing quality attributes.

Contd.. Quality attribute scenarios consists of six parts:
Source of stimulus- Some entity(human, computer system) that generated the stimulus. Stimulus- A condition that needs to be considered when it arrives at a system. Environment- Conditions where the stimulus occurs such as system overload or normal running of the system. Artifact- Some artifact is stimulated, which may be the whole system or parts of it. Response- Activity undertaken after the arrival of the stimulus. Response measure- The response should be measurable in some fashion, so that the requirement can be tested.

Example from Cars Response Measure: Deflection < N% Noise < M dB
… Artifact: Tires Stimulus: Bumps Environment: Highway driving Source of stimulus: Road Response: Control maintained Smooth ride Low noise

Availability scenario
Source of stimulus- The desired system response may be different, based on the source of response(internal or external). Stimulus - A fault of one of the following classes occurs. Omission- A component fails to respond to an input Crash- The component repeatedly suffers omission faults. Timing-A component responds but the response is early or late. Response- A component responds with an incorrect value.

Contd.. Artifact- Specifies the resource that is required to be available, Environment. The state of the system when the fault or failure occurs may also affect the desired system response Response- Possible reactions to a system failure are : logging the failure notifying selected users or other systems switching to a degraded mode with either less capacity or less function shutting down external systems, or becoming unavailable during repair.

Contd.. Response measure - Metric of success such as:
availability percentage time to repair available time interval degraded time interval

Sample availability scenario
By looking at the above scenario, the following can be concluded: An unanticipated external message is received by a process during normal execution of the system. The process informs the operator of the receipt of the message and continues to operate with no downtime.

Modifiability Scenario
Source of stimulus- Who makes the changes – e.g., developer, a system administrator, or an end user. Stimulus- What changes? Addition of a function, the modification of an existing function, deletion of a function; changing the qualities of the system Artifact- Specifies what is to be changed-the functionality of a system, its platform, its user interface, its environment, or another system with which it interoperates. Environment- When the change can be made-design time, compile time, build time, initiation time, or runtime. Response- Modifications are done without side effects. Response measure - Time and cost are the most desired response measures.

Sample Modifiability Scenario
By looking at the above scenario, the following can be concluded: A developer wishes change the user interface to make a screen’s background color blue. This change will be made to the code at design time. It will take less than 3 hours to make and test the change, with no side-effects.

General scenarios v/s System-specific scenarios
A general scenario can be best understood as “A request arrives for functionality & the change must be made at a particular time within the development process within a specified period”. A system-specific version of this would be – “ A request arrives to add support for a new browser to a web-based system & the change must be made within two weeks. A single general scenario may have many system-specific versions.

General scenarios v/s System-specific scenarios
Engineered for Tomorrow General scenarios v/s System-specific scenarios A general scenario can be best understood as “A request arrives for functionality & the change must be made at a particular time within the development process within a specified period”. A system-specific version of this would be – “ A request arrives to add support for a new browser to a web-based system & the change must be made within two weeks. A single general scenario may have many system-specific versions.

Quality Attribute Scenarios in Practice
Engineered for Tomorrow Quality Attribute Scenarios in Practice Six most important system quality attributes are: Availability Modifiability Performance Security Testability Usability

Availability What is Availability?
Engineered for Tomorrow Availability What is Availability? Availability is concerned with system failure and its associated consequences. Availability of a system, is the probability that it will be operational when it will be needed. It is defined as : α = mean time to failure mean time to failure + mean time to repair 99.9% availability implies there is a 0.1% probability that the system will not be operational when needed.

How system failure is detected?
Engineered for Tomorrow Areas of concern: How system failure is detected? How frequently system failure may occur? What happens when a failure occurs? How long a system is allowed to be out of operation? When failures may occur safely? What kinds of notifications are required when failure occurs?

Contd.. What is the difference between failure & faults?
Engineered for Tomorrow Contd.. What is the difference between failure & faults? A system failure occurs when the system no longer delivers a service consistent with its specification. A fault becomes a failure if not corrected or masked. A failure is observable by the system’s user and a fault is not. Ex: A fault such as choosing the wrong algorithm can result in miscalculation, thus causing system failure.

Availability General Scenario Generation
Engineered for Tomorrow Availability General Scenario Generation Source of stimulus- The desired system response may be different, based on the source of response(internal or external).

Contd.. Stimulus - A fault of one of the following classes occurs.
Engineered for Tomorrow Contd.. Stimulus - A fault of one of the following classes occurs. Omission- A component fails to respond to an input Crash- The component repeatedly suffers omission faults. Timing-A component responds but the response is early or late. Response- A component responds with an incorrect value. Artifact - Specifies the resource that is required to be available, Environment - The state of the system when the fault or failure occurs may also affect the desired system response

Contd.. Response- Possible reactions to a system failure are :
logging the failure notifying selected users or other systems switching to a degraded mode with either less capacity or less function shutting down external systems, or becoming unavailable during repair. Response measure - Metric of success such as: availability percentage time to repair available time interval degraded time interval

Modifiability Modifiability of a system has two concerns:
Engineered for Tomorrow Modifiability Modifiability of a system has two concerns: What can change? Functions that the system computes Platform the system exists on Hardware Operating system Middleware Operational environment of the system Systems with which it inter-operates Communication protocols

Contd…. Qualities exhibited by the system performance reliability
Engineered for Tomorrow Contd…. Qualities exhibited by the system performance reliability future modifications Capacity of the system no. of users supported no. of simultaneous operations

2. When the change is made & who makes it?
Engineered for Tomorrow Contd.. 2. When the change is made & who makes it? Changes are made to the source code during : Compile time (by compile-time switches) Build-time(by system libraries) Configuration set-up(by techniques such as parameter setting) Execution time(by parameter setting) Changes are made by : Developer End-user System administrator

Modifiability General Scenario Generation
Engineered for Tomorrow Modifiability General Scenario Generation Source of stimulus- Who makes the changes – e.g., developer, a system administrator, or an end user. Stimulus- What changes? Addition of a function, the modification of an existing function, deletion of a function; changing the qualities of the system Artifact- Specifies what is to be changed-the functionality of a system, its platform, its user interface, its environment, or another system with which it interoperates.

Engineered for Tomorrow
Contd.. Environment- When the change can be made-design time, compile time, build time, initiation time, or runtime. Response- Modifications are done without side effects. Response measure- Time and cost are the most desired response measures.

Performance 1.What is performance?
Engineered for Tomorrow Performance 1.What is performance? Performance of a system is basically concerned with the how long it takes for a system to respond when an event occurs. Events can be interrupts, messages, requests from users, or passage of time). 2. What makes system performance complicated? Source of events Arrival pattern of events

Contd.. In a web-based financial system, source of events will be users. In an engine control system, requests arrive from passage of time. Event arrival patterns can be periodic or stochastic. For example, a periodic event may arrive every 10 ms. Stochastic events arrive according to some probabilistic distribution.

Contd.. Que: Suppose an user submits 20 requests in a period of time on System A. On System B, two users submit 10 requests each simultaneously. Will there be any difference in the performance between System A and System B? Ans: No, because what matters is the arrival pattern of the requests at the servers & dependencies between the requests.

Performance General Scenario Generation
Engineered for Tomorrow Performance General Scenario Generation Source of Stimulus- can be internal or external. Here source is a collection of users. Stimulus- Stimuli are event arrivals, which can be periodic, sporadic or stochastic. Here stimulus is the stochastic initiation of 1000 transactions per minute. Artifact- It is always the system’s services.

Contd.. Environment- System can be in operational modes such as normal, overloaded or emergency. In this example, system is in normal mode. Response- The system must process the arriving events. In this example, transactions are processed. Response measure- This will be usually latency or deadline by which event must be processed, jitter, throughput, miss rate or data loss. In this example, transactions should be processed with an avg. latency of 2 sec.

What do you mean by Security?
Engineered for Tomorrow Security What do you mean by Security? Security is a measure of the system’s ability to resist unauthorized usage , while still providing its services to legitimate users. An attempt to breach security is called an attack(also known as threat).

Classification of Security
Engineered for Tomorrow Classification of Security 1. Non-repudiation - It is the property that transaction cannot be denied by any of the parties involved. This means you cannot deny that you ordered that item over the Internet if, in fact, you did. 2. Confidentiality - It is the property that data or services are protected from unauthorized access. This means that a hacker cannot access your income tax returns on a government computer. 3. Integrity - It is the property that data or services are being delivered as intended. This means that your grade has not been changed since your instructor assigned it.

Contd.. Assurance – It is the property that the parties involved in a transaction are who they intended to be. This means that, when a customer sends a credit card number to an Internet merchant, the merchant is who the customer thinks they are. Availability – It is the property that the system will be available for legitimate use. This means that a denial-of-service attack won't prevent your ordering of a book. Auditing – It is the property that the system tracks activities within it, at levels sufficient to reconstruct them. This means that, if you transfer money out of one account to another account, in Switzerland, the system will maintain a record of that transfer.

Security General Scenario Generation
Engineered for Tomorrow Security General Scenario Generation Source of stimulus- The source of attack may be either a human or another system. Stimulus- Stimulus is an attack by an unauthorized person or system, to display information, modify /delete information, access system services.

Contd.. Artifact- Target of the attack can be either services of the system or the data within it. In this example, target is data within the system. Environment- Attack can happen when the system is either online or offline, connected or disconnected from a network, behind a firewall or open to network. Response- System must authorize legitimate users and grant them access to data and services, at the same time rejecting unauthorized users and reporting unauthorized access. In this example, this is accomplished by an audit trail.

Contd.. Response measure- This includes the difficulty of mounting various attacks and the difficulty of recovering from and surviving attacks. In this example, the audit trail allows the accounts from which money was embezzled to be restored to their original state. But the embezzler still has the money & should be tracked down.

Testability 1. What is Testability?
Engineered for Tomorrow Testability 1. What is Testability? Software testability refers to the ease with which software can be made to demonstrate its faults through (typically execution-based) testing. In particular, testability refers to the probability that the software will fail on its next test execution, assuming that the software has atleast one fault.

Contd.. Q: What do you mean by a testable system? A: For a system to be testable, it must be possible to control each component’s internal state & inputs and then observe its outputs. Q: What is a test harness? A: A test harness is a specialized software designed to exercise the software to be tested. It may be as simple as a playback capability for data recorded across various interfaces or as complicated as a testing chamber for an engine. Q: Who performs the testing? A: Testing is done by developers, testers, verifiers or users.

Testability General Scenario Generation
Engineered for Tomorrow Testability General Scenario Generation Source of stimulus- Testing is performed by unit testers, integration testers, or the client. In this example, testing is done by a tester.

Contd.. Stimulus- Stimulus for the testing is that a milestone in the development process is met. completion of an analysis or design increment completion of a coding increment completed integration of a sub-system completion of the whole system. In our example, testing is triggered by completion of a unit of code. Artifact- A design, apiece of code, or the whole system is the artifact being tested. In this example, a unit of code is to be tested.

Contd.. Response measure - includes
Engineered for Tomorrow Contd.. Response measure - includes percentage of statements executed in some test length of the longest test chain estimating the probability of finding additional faults. In this example, percentage coverage of executable statements is measured. Environment- Testing can happen at design time, at development time, at compile time, or at deployment time. In this example, testing is done during development phase. Response- The desired response is that the system can be controlled to perform the desired tests and that the response to each test can be observed. In this example, the unit can be controlled and its responses captured.

Usability Usability is concerned with
Engineered for Tomorrow Usability Usability is concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides. It can be broken down into the following areas: Learning system features- If the user is unfamiliar with a particular aspect of the system, what can the system do to make the task of learning easier? Using a system efficiently- What can the system do to make the user more efficient in its operation?

Contd.. Minimizing the impact of errors
What can the system do so that a user error has minimal impact? Adapting the system to user needs How can the user (or the system itself) adapts to make the user's task easier? Increasing confidence and satisfaction What does the system do to give the user confidence that the correct action is being taken?

Usability General Scenario Generation
Engineered for Tomorrow Usability General Scenario Generation Source of stimulus- End user is always the source of the stimulus.

Contd.. Stimulus - Stimulus is that the end user
Engineered for Tomorrow Contd.. Stimulus - Stimulus is that the end user wishes to use a system efficiently learn to use the system minimize the impact of errors adapt the system feel comfortable with the system In our example, the user wishes to cancel an operation, thus minimizing the impact of errors Artifact- Artifact is always the system. Environment- The user actions occur at run-time or at system configuration time. In our example, the cancellation operation occurs at runtime.

Contd.. Response- The system should either provide the user with the features needed or anticipate the user’s needs. In our example, as the user wishes, cancellation takes place & the system is restored to its prior state. Response measure- Response is measured by task time no. of errors no. of problems solved user satisfaction gain of user knowledge ratio of successful operations to total operations amount of time/data lost when an error occurs. In this example, cancellation operation should occur in less than 1 sec.

Communicating Concepts using General Scenarios
Engineered for Tomorrow Communicating Concepts using General Scenarios Each attribute community has its own vocabulary; different terms can mean the same thing. The problem is for the architect to understand which stimuli represent the same occurrence, which are aggregates of other stimuli, and which are independent. Ex: a performance event may be atomic or an aggregate of other lower-level occurrences. Once the relations are clear, the architect can communicate them to various stakeholders using language that each comprehends.

Communicating Concepts
Each attribute community has its own vocabulary; different terms can mean the same thing. The problem is for the architect to understand which stimuli represent the same occurrence, which are aggregates of other stimuli, and which are independent. Ex: a performance event may be atomic or an aggregate of other lower-level occurrences.

Other System Quality Attributes
Engineered for Tomorrow Other System Quality Attributes 1. Scalability – It is the ability of a system, network, or process to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth. 2. Portability- Portability in high-level computer programming is the usability of the same software in different environments. 3. Interoperability- Interoperability is the ability of a system or a product to work with other systems or products without special effort on the part of the end user.

Engineered for Tomorrow Understanding Quality Attributes Functionality and architecture Architecture and quality attributes System quality attributes Business qualities Architecture qualities

Business qualities These are qualities related to the business environment in which the system or product is being developed. Time to market- If there is competitive pressure or a short period of opportunity for a system, marketing time becomes important. Cost and benefit- It is more expensive to build a highly flexible architecture than a rigid one. Projected lifetime of the system- If the system is intended to have a long lifetime, modifiability, scalability and portability become important. Targeted market- For general-purpose software, portability & functionality of the system play an important role. If large markets with a collection of related products are targeted, then a product line approach should be considered.

Contd.. Rollout schedule – If a product is to be introduced as base
Engineered for Tomorrow Contd.. Rollout schedule – If a product is to be introduced as base functionality, with many features released later, flexibility & customizability of the architecture are important. Integration with legacy systems - If the new system has to integrate with existing systems, appropriate integration mechanisms should be defined carefully.

Engineered for Tomorrow Understanding Quality Attributes Functionality and architecture Architecture and quality attributes System quality attributes Business qualities Architecture qualities

Architecture Qualities
Engineered for Tomorrow Architecture Qualities These are qualities related to the architecture of the system being developed. Conceptual integrity- The architecture should do similar things in similar ways. Correctness and completeness- If all of the system’s requirements and runtime resource constraints are met, then the architecture is correct and complete. Buildability- It allows the system to be completed by the available team in a timely manner and be open to changes as development progresses.

Unit- III Understanding Quality Attributes Achieving Qualities
Engineered for Tomorrow Unit- III Understanding Quality Attributes Achieving Qualities

Achieving Qualities Introducing Tactics Availability Tactics
Engineered for Tomorrow Achieving Qualities Introducing Tactics Availability Tactics Modifiability Tactics Performance Tactics Security Tactics Testability Tactics Usability Tactics Relationship of Tactics to Architectural Patterns Architectural Patterns and Styles

Introducing Tactics A tactic is a design decision that influences the control of a quality attribute response. A collection of tactics is called an architectural strategy. Tactics to Control Response Stimulus Response

A system design is a collection of decisions
Engineered for Tomorrow A system design is a collection of decisions Some ensure achievement of the system functionality Others help control the quality attribute responses (which we call the tactics) Tactics can refine other tactics – e.g., redundancy is a tactic in achieving availability and it can be refined into redundancy of data or redundancy of computation. Patterns package tactics – e.g., a pattern might package both redundancy and synchronization tactics (along with others).

Tactics are ways to get the desired response in a scenario
Engineered for Tomorrow Tactics are ways to get the desired response in a scenario Tactic Artifact Response Stimulus Environment

Tactics to Control Availability
Engineered for Tomorrow Availability Tactics Tactics to control Availability are: i) Fault detection ii) Fault recovery iii) Fault prevention Tactics to Control Availability Fault Masked or Repair Made Fault Fig: Goal of availability tactics

Fault Detection Three widely used tactics for recognizing faults are:
Engineered for Tomorrow Fault Detection Three widely used tactics for recognizing faults are: 1. Ping/echo : One component issues a ping and expects to receive back an echo, within a pre-defined time, from the component under scrutiny. Used within a group of components mutually responsible for one task. Heartbeat(dead man timer): One component emits a heartbeat message periodically and another component listens for it. If the heartbeat fails, the originating component is assumed to have failed and a fault correction component is notified.

Contd.. 3. Exceptions: An exception is raised when a fault is discovered. This causes the exception handler to transform the fault semantically so that it can be processed.

Fault Recovery Fault recovery consists of preparing for recovery and repairing the system. Some of the tactics are: Voting - Processes running on redundant processors each take input and compute an output value that is sent to a voter. If the voter detects deviant behavior from a single processor, it fails it. Active redundancy(hot restart) - All redundant components that are in the same state, respond to events in parallel. Response from only one component is used and the rest are discarded.

Contd.. 3. Passive redundancy(warm restart/dual/triple redundancy) –
One component (the primary) responds to events and informs the other components (the standbys) of state updates they must make. When a fault occurs, the system must first make sure that the backup state is sufficiently fresh before resuming services. 4. Spare - A standby spare computing platform is configured to replace many different failed components, whenever a failure occurs.

Contd.. Shadow operation - A previously failed component may be run in “shadow mode” for a short period of time to make sure it mimics the behavior of the working components before restoring it to service. State re-synchronization - When components are disabled in either passive or active redundancy tactics, they must have their states upgraded before returning them to service. Checkpoint/rollback – A checkpoint is a recording of a consistent state created either periodically or in response to specific events. When a fault occurs the system can be rolled back to that state.

Fault Prevention Fault prevention tactics include the following:
Engineered for Tomorrow Fault Prevention Fault prevention tactics include the following: Removal from service – A component of the system is removed from operation to prevent anticipated failures. Ex: re- booting a component Transactions – Several sequential steps of an operation are bundled, so that the entire bundle can be undone at once. Process monitor – Once a fault in a process has been detected, a monitoring process can delete the non-performing process & create a new, properly initialized instance of it.

Summary of availability tactics
Engineered for Tomorrow Summary of availability tactics

Modifiability Tactics
Engineered for Tomorrow Modifiability Tactics Goal is to control the time and cost to implement, test, and deploy changes. Tactics to Control Modifiability Change Arrives Changes Made, Tested, and Deployed Within Time and Budget

Contd.. Specific modifiability tactics include:
Engineered for Tomorrow Contd.. Specific modifiability tactics include: 1) Localize modifications – reduces the no. of modules that are directly affected by a change. 2) Prevent ripple effects – modifications are limited to the localized modules. 3) Defer binding time – controls deployment time and cost.

Localize Modifications
Engineered for Tomorrow Localize Modifications Maintain semantic coherence – Semantic coherence refers to the relationships among responsibilities in a module. The goal is to ensure that all of these responsibilities work together without excessive reliance on other modules. Anticipate expected changes – By anticipating a set of expected changes, its possible to evaluate a particular assignment of responsibilities. Generalize the module – the more general the module is, the more likely changes can be accommodated with little or no change. Limit possible options – Restricting the possible options will reduce the effect of modifications in a product line.

Prevent Ripple Effects
Engineered for Tomorrow Prevent Ripple Effects If module A is changed to accomplish a particular modification, then module B also has to be changed only because it depends on module A, in some sense. This is called a ripple effect.

Contd.. There are 8 types of dependencies between modules which cause
Engineered for Tomorrow Contd.. There are 8 types of dependencies between modules which cause ripple effects: Syntax of : Data- for B to compile correctly, the type of data produced by A and consumed by B, must be consistent with the type of data assumed by B. Service- for B to compile & execute correctly, the signature of services provided by A and invoked by B must be consistent with the assumptions of B. Semantics of : Data- for B to execute properly, the semantics of data produced by A and consumed by B, must be consistent with the assumptions of B.

Contd.. service- for B to execute correctly, the semantics of the services produced by A and used by B must be consistent with the assumptions of B. 3. Sequence of : data- for B to execute correctly, it must receive the data produced by A in a fixed sequence. Control- for B to execute correctly, A must have executed previously with certain timing constraints. 4. Identity of an interface of A: A may have multiple interfaces. For B to compile & execute correctly, identity of the interface must be consistent with the assumptions of B.

Contd.. 5. Location of A : For B to execute correctly, the run-time location of A must be consistent with the assumption of B. 6. The Quality of service/data provided by A: For B to execute correctly, quality of data or service provided by A, must be consistent with the assumptions of B. 7. Existence of A : For B to execute correctly, A must exist. 8. Resource behavior of A : For B to execute correctly, the resource behavior of A must be consistent with B’s assumptions.

Contd.. Tactics for preventing ripple effects are:
Engineered for Tomorrow Contd.. Tactics for preventing ripple effects are: Hide information - The responsibilities of a system are decomposed into smaller pieces make some information private and some public. Maintain existing interfaces – Interface stability can be achieved by separating the interface from the implementation. This can be achieved by patterns such as: adding interfaces adding adapter providing a stub

Contd.. 3. Restrict communication paths - This is achieved by reducing the modules with which a given module shares data. 4. Use an intermediary - If B has a dependency on A other than semantic dependency, then it is possible to insert an intermediary between B and A at manages activities associated with the dependency. The intermediaries are : Data(syntax) – Repositories act as intermediaries between the producer & consumer of data. Service(syntax) - Façade, bridge, mediator, strategy, proxy and factory patterns , provide intermediaries for converting the syntax of a service.

Contd.. Identity of an interface of A – A broker pattern can be used to mask changes in the identity of an interface. Location of A – A name server enables the location of A to be changed without affecting B. Resource behavior of A or resource controlled by A – A resource manager is an intermediary that is responsible for resource allocation. Existence of A – Dependency of B on the existence of A, is satisfied by actions of the factory pattern.

Defer binding time Whenever a modification is made by a developer, there will be a testing and distribution process, that determines the time lag between making change and availability of that change to the end-user. Deferring binding time means, that the system has been prepared for binding and all the testing and distribution steps have been completed.

Contd.. Tactics for deferring binding time are :
Engineered for Tomorrow Contd.. Tactics for deferring binding time are : Runtime registration – 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

Summary of modifiability tactics
Engineered for Tomorrow Summary of modifiability tactics

Performance Tactics Goal of performance tactics is to generate a response to an event arriving at the system within some time constraint. Tactics to Control Performance Events Arrive Response Generated Within Time Constraints

Contd.. Basically performance tactics are concerned about reducing the latency in the system response. Specific performance tactics include: Resource Demand Resource Management Resource Arbitration

Contd.. Basic contributors to response time:
Engineered for Tomorrow Contd.. Basic contributors to response time: Resource consumption – A message generated by one component will be transmitted to another component after undergoing the following phases: Placed in a buffer Transformed in some fashion(marshalling) Processed according to some algorithm Transformed suitably for output Placed in an output buffer Sent to another component or system

Contd.. 2. Blocked time - A computation can be blocked from using a resource because of the following reasons: Contention for resources Availability of resources Dependency on other computation

Resource Demand Event streams generate the demand for resources.
Engineered for Tomorrow Resource Demand Event streams generate the demand for resources. Two factors which influence this demand are: i) time between events in a resource stream ii) how much of a resource is consumed by each request

Contd.. Tactics for reducing latency are :
Engineered for Tomorrow Contd.. Tactics for reducing latency are : Reduce the resources required for processing an event stream Ways to accomplish this tactic are – Increase computational efficiency- use an efficient algorithm in critical areas Reduce computational overhead - use java classes instead of RMI Reduce the no. of events processed Manage event rate- by educing the sampling frequency Control frequency of sampling – sample queued requests at a lower frequency

Contd.. Tactics for reducing/managing resource demand are:
Engineered for Tomorrow Contd.. Tactics for reducing/managing resource demand are: Bound execution times – limit the execution time used to respond to an event Bound queue sizes – limit the size of the request queue

Resource Management Tactics for resource management are:
Engineered for Tomorrow Resource Management Tactics for resource management are: Introduce concurrency : By parallel processing of requests, block time can be reduced. Concurrency is introduced by processing different streams of events on different threads or by creating additional threads. Maintain multiple copies of either data or computations : The purpose of replicas is to reduce the contention that would occur, if all computations happened on a central server. This can be achieved by using caching.

Contd.. Increase available resources :
Engineered for Tomorrow Contd.. Increase available resources : Faster processors, additional processors, additional memory and faster networks all have the potential for reducing latency.

Resource Arbitration Resource arbitration is all about resolving the conflicts arising out of contention for a given resource. One way of achieving this is scheduling. Q: What is scheduled? A: Processors Buffers Networks

Contd.. Competing criteria for scheduling include:
Engineered for Tomorrow Contd.. Competing criteria for scheduling include: Optimal resource usage Request importance Minimizing the number of resources used Minimizing latency Maximizing throughput Preventing starvation to ensure fairness Possible preemption options are as follows: Can occur anytime Can occur only at specific pre-emption points Executing processes cannot be pre-empted

Contd.. Some common scheduling policies are: First-in/First-out(FIFO):
Engineered for Tomorrow Contd.. Some common scheduling policies are: First-in/First-out(FIFO): FIFO queues treat all requests for resources as equal and grants them resources on a first come first serve basis. Fixed - priority scheduling: assigns a particular priority to each source of request and assigns the resources in that priority order. Three common prioritization strategies are: Semantic importance- domain characteristic of the task is the priority Deadline monotonic- high priority to streams with shorter deadlines Rate monotonic – high priority to streams with short periods

Contd.. 3. Dynamic priority scheduling:
Engineered for Tomorrow Contd.. 3. Dynamic priority scheduling: Round robin – A fixed quantum of time will be assigned to every request. Resource will be allocated to each request for that quantum, then moved to the next request. Earliest deadline first – Assigns priorities based on the pending requests with the earliest deadline. 4. Static scheduling: The pre-emption points and the sequence of assignment to the resource are determined offline.

Summary of performance tactics
Engineered for Tomorrow Summary of performance tactics

Security Tactics Tactics for achieving security are concerned with 3 aspects: Resisting attacks Detecting attacks Recovering from attacks Fig: Goal of Security Tactics Tactics to Control Security System Detects, Resists, or Recovers from Attacks Attack

Resisting Attacks Security is characterized by non- repudiation, confidentiality, integrity and assurance. The following tactics are used to achieve these goals: Authenticate users – Authentication makes sure that the user or remote computer is actually, who it is intended to be. Authorize users – Authorization is ensuring that an authenticated user has the required rights to access and modify either data or services.

Contd.. 3. Maintain data confidentiality – Data is protected from unauthorized access by applying some form of encryption to data & communication links. 4. Maintain integrity – Data should be delivered as intended. 5. Limit exposure – Architect can design the allocation of services to host, in such a manner, that only limited services are available to each host. 6. Limit access – Access will be restricted based on message source or destination port. This is achieved using Firewall and DMZ.

Detecting Attacks Detecting attacks is possible through an intrusion detection system. An intrusion detection system, works in the following manner : It compares the network traffic patterns to a database. In case of misuse detection, traffic pattern is compared to historic patterns of known attacks. In case of anomaly detection, traffic pattern is compared with a historical baseline of itself.

Contd.. An intrusion detector system comprises of the following components: A sensor to detect attacks Managers to do sensor fusion Databases for storing events for later analysis Tools for offline reporting and analysis A control console for modifying the intrusion detection actions

Recovering from Attacks
Engineered for Tomorrow Recovering from Attacks Tactics for recovering from attacks can be divided into two concerns: i) restoring the system state ii) identifying the attacker

Contd.. Tactics used for restoring the system state from inconsistent to consistent are: Voting Active redundancy Passive redundancy Spare Shadow operation State resynchronization Checkpoint/rollback

Contd.. Tactic for identifying an attacker is to maintain an audit trail. An audit trail is a copy of each transaction applied to the data in the system, along-with identification information. Audit information can be used to trace the actions of an attacker, support non-repudiation & system recovery.

Summary of Security Tactics
Engineered for Tomorrow Summary of Security Tactics Security Resisting Attacks Detecting Attacks Recovering from an Attack Intrusion Detection Authenticate Users Authorize Users Maintain Data Confidentiality Maintain Integrity Limit Exposure Limit Access System Detects, Resists, or Recovers from Attacks Attack Restoration Identification Refer Availability Audit Trail

Testability Tactics Goal of tactics for testability is to allow for easier testing, whenever a software increment is completed. Tactics to Control Testability Completion of an Increment Faults Detected

Contd.. Tactics for testing are divided into following categories:
Engineered for Tomorrow Contd.. Tactics for testing are divided into following categories: 1. Providing input and capturing output 2. Internal monitoring of the system Tactics for managing input and output for testing are: 1. Record/playback – It refers to both capturing information crossing an interface and using it as input into the test harness. 2. Separate interface from implementation – This makes of use of stubs which replace implementations, so that the component being replaced acts as a test harness.

Contd.. 3. Specialized access routes/interfaces – Having specialized
Engineered for Tomorrow Contd.. 3. Specialized access routes/interfaces – Having specialized testing interfaces allows, variable values for a component to be specified through a test harness as well as from normal execution. Tactics used for internal monitoring of a system are: 1. Built-in monitors – These maintain the state, performance load, capacity, security or other information accessible through an interface. 2. A common technique is to record events, when monitoring states have been activated.

Summary of Testability Tactics
Engineered for Tomorrow Summary of Testability Tactics Testability Manage Input / Output Internal Monitoring Completion Of an Increment Faults Detected Record/Playback Separate Interface from implementation Specialized Access Routes/Interfaces Built-in Monitors

Usability Tactics Usability is concerned with:
Engineered for Tomorrow Usability Tactics Usability is concerned with: i)how easy it is for the user to accomplish a desired task ii)kind of support, the system provides to the user

Contd.. Based on the types of users, usability tactics can be classified as: 1. Run-time tactics – which supports the user during system execution. 2. Design-time tactics – is based on the iterative nature of user interface design and supports the interface developer at design time.

Contd.. 1. Run-time Tactics :
Engineered for Tomorrow Contd.. 1. Run-time Tactics : Once a system is executing, usability is enhanced by giving the user feedback as to what the system is doing and by providing the user with the ability to issue usability-based commands. Tactics to Control Usability User Request User Given Appropriate Feedback and Assistance

Contd.. When the user takes the initiative, the architect designs the responsibilities of the system as a response to user command. When the system takes the initiative, architect should identify the models used by the system, to predict either its own behavior or the user’s intention. Terms such as user-initiative, system-initiative and mixed-initiative are used to describe, which of the human-computer pair takes the initiative in performing certain actions & how the interaction proceeds.

Contd.. Each model requires various types of input to accomplish its initiative. Some of them are: Maintain a model of the task Maintain a model of the user Maintain a model of the system 2. Design-time tactics : User interfaces(UI) are typically revised frequently during the testing process. The usability engineer will give instructions for change of user-interface to the developers.

Contd.. This results in the following tactic:
Engineered for Tomorrow Contd.. This results in the following tactic: Separate the user interface from the rest of the application – Since the UI is expected to change frequently, maintaining the UI code separately will localize changes to it. The software architecture patterns developed to implement this tactic are: Model-View-Controller Presentation- Abstraction- Control Seeheim Arch/Slinky

Summary of Run-time Usability Tactics
Engineered for Tomorrow Summary of Run-time Usability Tactics Usability Separate User Interface Support User Initiative Support System Initiative User Request User given Appropriate Feedback & Assistance User Model System Model Task Model Cancel Undo Aggregate

Relationship of Tactics to Architectural Patterns
Engineered for Tomorrow Relationship of Tactics to Architectural Patterns An architect may choose a pattern or collection of patterns to realize one or more tactics. Active Object design pattern : It decouples method execution from method invocation to enhance concurrency & simplify synchronized access to objects that reside in their own control thread. This pattern consists of six elements – 1. A proxy – provides an interface that allow clients to invoke publicly accessible methods

Contd.. 2. A method request – defines an interface for executing the methods of an active object 3. An activation list – maintains a buffer of pending method requests 4. A scheduler – decides what method requests to execute next 5. A servant – defines the behavior & state modeled as an active object 6. A future – allows the client to obtain the result of the method invocation

Contd.. Tactics implemented by the Active Object pattern are:
Engineered for Tomorrow Contd.. Tactics implemented by the Active Object pattern are: Concurrency(performance) Information hiding(modifiability) Intermediary(modifiability) Binding time(modifiability) Scheduling policy(performance)

Architectural Patterns and Styles
Engineered for Tomorrow Architectural Patterns and Styles Analogous to architectural styles in buildings An architectural pattern is determined by: A set of element types (e.g., a data repository) A topological layout of the elements indicating their interrelationships A set of semantic constraints A set of interaction mechanisms (e.g. subroutine calls) that determine how the elements coordinate through the allowed topology Tactics are the building blocks of design from which architectural patterns are built.

A Small Catalog of Architectural Patterns
Engineered for Tomorrow A Small Catalog of Architectural Patterns Independent Components communicating processes event systems implicit invocation explicit invocation

(Contd...) Data Flow batch sequential pipes and filters Data-centered
Engineered for Tomorrow (Contd...) Data Flow batch sequential pipes and filters Data-centered repository blackboard

(Contd..) Virtual Machine interpreter rule-based system Call/Return
Engineered for Tomorrow (Contd..) Virtual Machine interpreter rule-based system Call/Return main program and subroutine object-oriented layered

Unit- 3 QUALITY Presented by Sushma Narasimhan Asst. Professor,

Similar presentations

Presentation on theme: "Unit- 3 QUALITY Presented by Sushma Narasimhan Asst. Professor,"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Unit- 3 QUALITY Presented by Sushma Narasimhan Asst. Professor,

Similar presentations

Presentation on theme: "Unit- 3 QUALITY Presented by Sushma Narasimhan Asst. Professor,"— Presentation transcript:

Similar presentations

About project

Feedback