1. 1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University

2. Outline 1. Introducing Tactics 2. Availability Tactics 3. Modifiability Tactics 4. Performance Tactics 5. Relationship of Tactics to Architectural Patterns 6. Architectural Patterns and Styles 7. Summary 2

3. Achieving Qualities Lecture: 4-5 3

4. 1. Introducing Tactics A Tactic is a design decision that influences the control of a quality attribute response  being in use of architects for years We call collection of Tactics an architectural strategy Each tactic is a design option for the architect For instance; to increase availability, one tactic is to introduce redundancy  A Tactic can refine other tactics  Pattern packages tactics 4

5. Introducing Tactics (Continue…) 5 How?

6. 2. Availability Tactics A failure occurs when the system no longer delivers a service that is consistent with its specification A fault (or combination of faults) has the potential to cause a failure Tactics can keep faults from becoming failure or at least bound the effects of fault and make repair possible Availability tactics involve some type of redundancy, some type of health monitoring to detect failure, and some type of recovery in case of a failure 6

7. Availability Tactics (Continue…) 7

8. Fault Detection  Ping/echo One process issues a ping and expected to receive back an echo within a periodic time Can be done among processes mutually responsible for a task Can also be used by client object to check if server and operating path are operational  Heartbeat (dead man timer) Components emits heartbeat message periodically If the heartbeat fails the originating component fails and repair mechanism is called upon Heartbeat can also carry data e.g. ATM machines 8

9. Availability Tactics (Continue…) Fault Detection (Continue…)  Exceptions Encounter an exception which is raised when one of the faults classes is recognized Usually exception is handled within same process that introduced the exception 9

10. Availability Tactics (Continue…) Fault Recovery (Preparation and Repair)  Voting Processes running on redundant processors each take equivalent input and compute a simple output and sent to voter If voter identifies deviant behavior from one of the processor, it fails it Voter can be implementing any algorithm like ‘majority rules’ or ‘preferred component’ etc.  Active Redundancy All redundant components respond to events in parallel Response from only one component is used and rest are discarded All components have latest state and failure using this tactic lasts for just milliseconds In some systems the redundancy may be in communication paths 10

11. Availability Tactics (Continue…) Fault Recovery (Preparation and Repair) (Continue…)  Passive Redundancy One (primary) component responds to an event and ask other (standby) components to update their state When failure occurs the system first ensure that backup state is fresh In case of failure recovery may take up to seconds  Spare A standby spare computing platform is configured to replace many different failed components It must be rebooted with required software configuration and its states be initialized when a failure occurs Making checkpoint of system state and logs of state change should be stored on persistent storage 11

12. Availability Tactics (Continue…) Fault Recovery (Reintroduction)  Shadow Operation A previously failed component may be run in “shadow mode” for some time to ensure that it mimics the behavior of working system  State Resynchronization The active and passive tactics require that state of failed components be upgraded before they return to service  Checkpoint/rollback A checkpoint is a recording of a consistent state either created periodically or to response to an event Sometimes system fails in unusual manner, with an inconsistent state hence previously saved consistent state can be restored in this case 12

13. Availability Tactics (Continue…) Fault Prevention  Removal from Service Removes a component of the system from operation to undergo some activities to prevent anticipated failure  Transactions A transaction is the bundling of several sequential steps If one of the steps fail 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 nonperforming process and then create a new instance of it 13

14. 3. Modifiability Tactics The goal of modifiability tactics is to control time and cost to implement, test and deploy changes The modifiability tactics are grouped according to their goals  Reducing number of modules that are directly affected (Localize Change)  Limiting modifications to localized modules (Prevent Ripple Effects)  Controlling deployment time and cost (Defer Binding Time) 14

15. Modifiability Tactics (Continue…) 15

16. Modifiability Tactics (Continue…) Localize Modifications  There is no precise relationship between number of modules affected by a change and cost to implement them  Reducing number of affected modules ‘generally’ reduce the cost  Aim of the tactics in this set is to assign responsibilities to modules so that affect of anticipated changes will be limited  Maintain Semantic Coherence: All of the module responsibilities work together without relying on other modules Semantic coherence should be measured against set of anticipated changes 16

17. Modifiability Tactics (Continue…) Localize Modifications (Continue…)  Anticipate Expected Changes Considering the set of envisioned changes provides a way to control modifiability cost This tactic concerns with minimizing the effects of changes Usually used in conjunction with semantic coherence  Limit Possible Options Modifications, especially within a product line may be far ranging and hence affect many modules Restring possible options will reduce the effect of these modifications Product line may allow for a change of a processor  Restring processor changes to members of the same family limits the possible options 17

18. Modifiability Tactics (Continue…) Prevent Ripple Effects  A ripple effect from a modification is the necessity of making changes to modules not directly affected by it e.g. module B has to be changed just because it depends on module A, which is modified  Modules can have eight possible dependencies among them 1. Syntax of  data. For B to compile (or execute) correctly, the type (or format) of the data that is produced by A and consumed by B must be consistent with the type (or format) of data assumed by B  service. For B to compile and execute correctly, the signature of services provided by A and invoked by B must be consistent with the assumptions of B 18

19. Modifiability Tactics (Continue…) Prevent Ripple Effects (Continue…) 2 Semantics of data. For B to execute correctly, the semantics of the data produced by A and consumed by B must be consistent with the assumptions of B 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. For example, a data packet's header must precede its body in order of reception (as opposed to protocols that have the sequence number built into the data) control. For B to execute correctly, A must have executed previously within certain timing constraints. For example, A must have executed no longer than 5ms before B executes 19

20. Modifiability Tactics (Continue…) Prevent Ripple Effects (Continue…) 4 Identity of an interface of A 4 A may have multiple interfaces. For B to compile and execute correctly, the identity (name or handle) of the interface must be consistent with the assumptions of B 5 Location of A (runtime) 4 For B to execute correctly, the runtime location of A must be consistent with the assumptions of B. For example, B may assume that A is located in a different process on the same processor 6 Quality of service/data provided by A 4 For B to execute correctly, some property involving the quality of the data or service provided by A must be consistent with B's assumptions. E.g. data provided by a particular sensor must have a certain accuracy in order for the algorithms of B to work correctly 20

21. Modifiability Tactics (Continue…) Prevent Ripple Effects (Continue…) 7 Existence of A 7 For B to execute correctly, A must exist. For example, if B is requesting a service from an object A, and A does not exist and cannot be dynamically created, then B will not execute correctly 8 Resource behavior of A 7 For B to execute correctly, the resource behavior of A must be consistent with B's assumptions. This can be either resource usage of A (A uses the same memory as B) or resource ownership (B reserves a resource that A believes it owns) 21

22. Modifiability Tactics (Continue…) Prevent Ripple Effects (Continue…)  Hide Information Decomposition of the responsibilities for an entity into smaller pieces and choosing which information to make private and public Goal is to isolate changes within one module and prevent changes from propagating to others  Maintain existing interfaces If B depends on the name or signature of an interface of A, maintaining this interface and its syntax allow B to remain unchanged Creating abstract interfaces can ensure interface stability and mask variation This tactic will not work if B has semantic dependency on A 22

23. Modifiability Tactics (Continue…) Prevent Ripple Effects (Continue…)  Restrict communication paths Restrict the modules with which a given module shares data Reduce the number of modules that consume data produced by the given module and the number of modules that produce data consumed by it  Use an intermediary If B has any type of dependency on A other than semantic, it is possible to insert an intermediary between B and A that manages activities associated with the dependency  location of A (runtime): A name server enables the location of A to be changed without affecting B  A is responsible for registering its current location with the name server  B retrieves that location from the name server 23

24. Modifiability Tactics (Continue…) Defer Binding Time  “Localize Change” and “Prevent Ripple Effect” help minimizing the number of modules that require changing to implement modifications  There are two other elements that are not satisfied by reducing the number of modules to be changed Time to deploy Allowing non-developers to make changes  Deferring binding time supports both of those scenarios at the cost of requiring additional infrastructure to support the late binding 24

25. Modifiability Tactics (Continue…) Defer Binding Time (Continue…)  Runtime Registration Supports plug-and-play operations on the cost of additional overhead to manage the registration  Configuration Files Allows administrators and users to set various configuration parameters at startup  Polymorphism Allows late binding of method calls 25

26. 4. Performance Tactics Generate a response to an event arriving at the system within some time constraint An event can be the arrival of a message, the expiration of a time interval, the detection of a significant change of state in the system’s environment The system processes the event and generates the response Performance tactics control the time within which a response is generated 26

27. Performance Tactics (Continue…) Two main contributors that effect the response time; 1. Resource consumption Resources include CPU, memory, data stores, network communication channel etc. Event can be of varying types and each type goes through a processing sequence  e.g. a message generated by a component returns after utilizing various resources like buffers, bandwidth channels, CPU etc. 2. Blocked time A computation can be blocked from using a resource because of  Contentions for it  Resource is unavailable  Computations depends upon the results of other computations that are not yet available 27

28. Performance Tactics (Continue…) 28

29. Performance Tactics (Continue…) Resource Demand  Event streams are the source of resource demand  Two characteristics of demand are Time between events in a source stream How much of a resource is consumed by each request  Increase Computational Efficiency Processing of an event generally require application of an algorithm Improving an algorithm in critical areas will decrease latency Sometimes one resource can be traded for another  Intermediate data can be kept in a repository or may be regenerated depending on time and space resource availability 29

30. Performance Tactics (Continue…) Resource Demand (Continue…)  Reduce Computational Overhead If there is no request for a resource, processing needs are reduced The use of intermediaries (recall Modifiability) increases the resources consumed in processing an event stream, so removing them reduces latency  Classic Modifiability/Performance tradeoff  Manage Event Rate If it is possible to reduce the sampling frequency at which environmental variables are monitored, demand can be reduced Sometimes high sampling rate is found because of the fact that the systems are overenginered 30

31. Performance Tactics (Continue…) Resource Management  Introduce Concurrency If requests can be processed in parallel, the blocked time can be reduced Concurrency can be introduced by processing different streams of events on different threads or new threads can be created  Maintain Multiple Copies of Either Data or Computations Clients in the client-server pattern are replicas of computation The purpose of replicas is to reduce the contention that would occur if all computation took place on a central server Caching is a tactic in which data is replicated either on speed repositories or on different repositories  Replicas should be consistent and synchronized 31

32. Performance Tactics (Continue…) Resource Management (Continue…)  Increase Available Resources Faster processors, additional processors, additional memory, and faster networks all have the potential for reducing latency Cost is usually a consideration in the choice of resources 32

33. Performance Tactics (Continue…) Resource Arbitration  Whenever there is contention for a resource, the resource must be scheduled Processors, buffers, network channels and so on  An architect must understand characteristics of each resource and use scheduling scheme accordingly  Scheduling policy conceptually has two parts A priority assignment and Dispatching  Variety of criteria for selecting scheduling policy Optimal resource usage, Request importance, Minimizing the number of resources used, Minimizing latency, Maximizing throughput and so on 33

34. Performance Tactics (Continue…) Resource Arbitration (Continue…)  First-in/First-out Treats all requests for resources as equals and satisfy them in turn  Fixed Priority Scheduling Assigns each resource request a particular priority and assigns resources according to the request priority  Semantic Importance, Deadline Monotonic, Rate Monotonic  Dynamic Scheduling Round Robin: it orders requests and then assigns the resource to the next request in order  Static Scheduling The pre-emption points and the sequence of assignment to the resource are determined offline 34

35. 5. Relationship of Tactics to Architectural Patterns An architect usually chooses a pattern or a collection of patterns to realize one or more tactics Each pattern implements multiple tactics whether desired or not Any implementation of pattern also makes choice about tactics  e.g. client-server pattern; server should be available An architect needs to understand all the tactics embedded in an implementation  making a judicious choice of what combination of tactics will achieve system goals 35

36. 6. Architectural Patterns and Styles An architectural pattern also knows as architectural style An architectural pattern is determined by  A set of element types  A topological layout of the elements  A set of semantic constraints  A set of interaction mechanisms 36

37. 37 Summary Any Questions?