Engineered for Tomorrow Unit 3 QUALITY Engineered for

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

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

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

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

Engineered for Tomorrow Definition Quality 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. Functionality

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

Engineered for Tomorrow Architecture & Quality Attributes 1) 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. 2) Architecture by itself, is unable to achieve qualities. Ø It provides the foundation for achieving quality, only if details are paid attention.

Engineered for Tomorrow 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 8

Engineered for Tomorrow 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. 9

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

Engineered for Tomorrow System Quality Attributes • System Quality Attribute Problems • Quality Attribute Scenarios • System-specific scenarios : Ø Availability Scenario Ø Modifiability Scenario

Engineered for Tomorrow 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. 12

Engineered for Tomorrow 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

Engineered for Tomorrow Quality attribute scenarios • Quality attribute scenarios are a means of characterizing quality attributes.

Engineered for Tomorrow 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.

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

Engineered for Tomorrow 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.

Engineered for Tomorrow 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. 18

Engineered for Tomorrow Contd. . • Response measure - Metric of success such as: Ø availability percentage Ø time to repair Ø available time interval Ø degraded time interval

Engineered for Tomorrow 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.

Engineered for Tomorrow 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. 21

Engineered for Tomorrow 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.

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.

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.

Engineered for Tomorrow Quality Attribute Scenarios in Practice Six most important system quality attributes are: 1. Availability 2. Modifiability 3. Performance 4. Security 5. Testability 6. Usability

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 repair • 99. 9% availability implies there is a 0. 1% probability that the system will not be operational when needed.

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?

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.

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

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

Engineered for Tomorrow 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

Engineered for Tomorrow Modifiability of a system has two concerns: 1. 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

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

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

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.

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

Engineered for Tomorrow 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.

Engineered for Tomorrow 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.

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.

Engineered for Tomorrow 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.

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

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.

Engineered for Tomorrow Contd. . 4. 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. 5. Availability – It is the property that the system will be available for legitimate use. This means that a denial-ofservice attack won't prevent your ordering of a book. 6. 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.

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.

Engineered for Tomorrow 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.

Engineered for Tomorrow 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.

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

Engineered for Tomorrow 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.

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.

Engineered for Tomorrow 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.

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.

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?

Engineered for Tomorrow 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?

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

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.

Engineered for Tomorrow 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.

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.

Engineered for Tomorrow 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. 59

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

Engineered for Tomorrow 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.

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

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.

Engineered for Tomorrow Unit- III 1) Understanding Quality Attributes 2) Achieving Qualities

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 and Styles

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

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

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

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 and Styles

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

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. 2. 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.

Engineered for Tomorrow 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.

Engineered for Tomorrow Fault Recovery Fault recovery consists of preparing for recovery and repairing the system. Some of the tactics are: 1. 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. 2. 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.

Engineered for Tomorrow 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.

Engineered for Tomorrow Contd. . 5. 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. 6. 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. 7. 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.

Engineered for Tomorrow Fault Prevention Fault prevention tactics include the following: 1. Removal from service – A component of the system is removed from operation to prevent anticipated failures. Ex: rebooting a component 2. Transactions – Several sequential steps of an operation are bundled, so that the entire bundle can be undone at once. 3. 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.

Engineered for Tomorrow Summary of 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 and Styles

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

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.

Engineered for Tomorrow Localize Modifications 1. 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. 2. Anticipate expected changes – By anticipating a set of expected changes, its possible to evaluate a particular assignment of responsibilities. 3. Generalize the module – the more general the module is, the more likely changes can be accommodated with little or no change. 4. Limit possible options – Restricting the possible options will reduce the effect of modifications in a product line.

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.

Engineered for Tomorrow Contd. . There are 8 types of dependencies between modules which cause ripple effects: 1. 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. 2. 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.

Engineered for Tomorrow 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.

Engineered for Tomorrow 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.

Engineered for Tomorrow Contd. . • Tactics for preventing ripple effects are: 1. Hide information - The responsibilities of a system are decomposed into smaller pieces make some information private and some public. 2. 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

Engineered for Tomorrow 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.

Engineered for Tomorrow 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.

Engineered for Tomorrow 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.

Engineered for Tomorrow Contd. . Tactics for deferring binding time are : 1. Runtime registration – plug and play operation at the cost of additional overhead, to manage the registration 2. Configuration files- are intended to set parameters at startup 3. Polymorphism- allows late binding of method calls 4. Component replacement- allows load time binding 5. Adherence to defined protocols- allows runtime binding of independent processes

Engineered for Tomorrow Summary of modifiability 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 and Styles

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

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

Engineered for Tomorrow Contd. . Basic contributors to response time: 1. 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

Engineered for Tomorrow 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

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

Engineered for Tomorrow Contd. . • Tactics for reducing latency are : 1. 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 2. Reduce the no. of events processed Ways to accomplish this tactic are – • Manage event rate- by educing the sampling frequency • Control frequency of sampling – sample queued requests at a lower frequency

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

Engineered for Tomorrow Resource Management • Tactics for resource management are: 1. 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. 2. 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.

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

Engineered for Tomorrow 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

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

Engineered for Tomorrow Contd. . Some common scheduling policies are: 1. 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. 2. 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

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.

Engineered for Tomorrow Summary of performance 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 and Styles

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

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

Engineered for Tomorrow 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.

Engineered for Tomorrow 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.

Engineered for Tomorrow 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

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

Engineered for Tomorrow 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

Engineered for Tomorrow 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.

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

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 and Styles

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

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.

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.

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

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 and Styles

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

Engineered for Tomorrow 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.

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. User Request Tactics to Control Usability User Given Appropriate Feedback and Assistance

Engineered for Tomorrow 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 mixedinitiative are used to describe, which of the human-computer pair takes the initiative in performing certain actions & how the interaction proceeds.

Engineered for Tomorrow 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.

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

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

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 and Styles

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

Engineered for Tomorrow 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

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)

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

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

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

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

Engineered for Tomorrow