Software Architecture Session6

570 views

Published on

Software Architecture

Published in: Software
  • Be the first to comment

  • Be the first to like this

Software Architecture Session6

  1. 1. UNDERSTANDING QUALITY ATTRIBUTES Session - 6 9/14/2014 1
  2. 2. An example: Modifiability • Goal: Control the time and cost to implement, test, and deploy changes – Localize modifications – Prevent the ripple effect – Defer binding time 9/14/2014 SEPS ZG651 Software Architectures 2
  3. 3. Modifiability Tactics 9/14/2014 SEPS ZG651 Software Architectures 3
  4. 4. Localize Modifications • There is not necessarily a precise relationship between the number of modules affected by a set of changes and the cost of implementing those changes, restricting modifications to a small set of modules will generally reduce the cost. • The goal of tactics in this set is to assign responsibilities to modules during design such that anticipated changes will be limited in scope. 9/14/2014 SEPS ZG651 Software Architectures 4
  5. 5. 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 – Examples of abstracting common services are the use of application frameworks and the use of other middleware software 9/14/2014 SEPS ZG651 Software Architectures 5
  6. 6. Prevent Ripple Effects • A ripple effect from a modification is the necessity of making changes to modules not directly affected by it. • For instance, if module A is changed to accomplish a particular modification, then module B is changed only because of the change to module A. B has to be modified because it depends, in some sense, on A. 9/14/2014 SEPS ZG651 Software Architectures 6
  7. 7. Prevent Ripple Effects • The various types of dependencies that one module can have on another. 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. 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. 9/14/2014 SEPS ZG651 Software Architectures 7
  8. 8. Prevent Ripple Effects 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 – 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 4. Identity of an interface of A. – 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). – 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. 9/14/2014 SEPS ZG651 Software Architectures 8
  9. 9. Prevent Ripple Effects 6. Quality of service/data provided by A – 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. • For example, data provided by a particular sensor must have a certain accuracy in order for the algorithms of B to work correctly. 7. Existence of A. – 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. – 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). 9/14/2014 SEPS ZG651 Software Architectures 9
  10. 10. Defer Binding Time • It allows non developers to make changes at the time of deploying • The tactics used at defer binding time are : – Runtime registration supports plug-and-play operation at the cost of additional overhead to manage the registration. Publish/subscribe registration, for example, can be implemented at either runtime or load time. – 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. 9/14/2014 SEPS ZG651 Software Architectures 10
  11. 11. Performance Tactics 9/14/2014 SEPS ZG651 Software Architectures 11
  12. 12. Performance Tactics • The goal of performance tactics is to generate a response to an event arriving at the system within some time constraint. • The event can be single or a stream and is the trigger for a request to perform computation. • It 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. 9/14/2014 SEPS ZG651 Software Architectures 12
  13. 13. Performance Tactics • After an event arrives, either the system is processing on that event or the processing is blocked for some reason. • This leads to the two basic contributors to the response time : – Resource consumption – Blocked time 9/14/2014 SEPS ZG651 Software Architectures 13
  14. 14. Resource consumption • Resources include CPU, data stores, network communication bandwidth, and memory, but it can also include entities defined by the particular system under design. – For example, buffers must be managed and access to critical sections must be made sequential. • Events can be of varying types, and each type goes through a processing sequence. – For example, a message is generated by one component, is placed on the network, and arrives at another component. 9/14/2014 SEPS ZG651 Software Architectures 14
  15. 15. Blocked time • A computation can be blocked from using a resource because of contention for it, because the resource is unavailable, or because the computation depends on the result of other computations that are not yet available. – Contention for resources : Shows events arriving at the system. – Availability of resources: Even in the absence of contention, computation cannot proceed if a resource is unavailable. – Dependency on other computation : A computation may have to wait because it must synchronize with the results of another computation or because it is waiting for the results of a computation that it initiated. • For example, it may be reading information from two different sources, if these two sources are read sequentially, the latency will be higher than if they are read in parallel. 9/14/2014 SEPS ZG651 Software Architectures 15
  16. 16. Resource Demand • Event streams are the source of resource demand. • Two characteristics of demand are the time between events in a resource stream and how much of a resource is consumed by each request. 9/14/2014 SEPS ZG651 Software Architectures 16
  17. 17. Resource Management • The demand for resources may not be controllable, the management of these resources affects response times. • Some resource management tactics are: – Concurrency – Maintain multiple copies of either data or computations. – Increase available resources 9/14/2014 SEPS ZG651 Software Architectures 17
  18. 18. Resource Arbitration • Whenever there is contention for a resource, the resource must be scheduled. • Processors are scheduled, buffers are scheduled, and networks are scheduled. • The architect's goal is to understand the characteristics of each resource's use and choose the scheduling strategy that is compatible with it. 9/14/2014 SEPS ZG651 Software Architectures 18
  19. 19. Resource Arbitration • Some common scheduling policies are: – First-in/First-out – Fixed-priority scheduling. • Fixed-priority scheduling assigns each source of resource requests a particular priority and assigns the resources in that priority order. – Dynamic priority scheduling • Round robin is a scheduling strategy that orders the requests and then, at every assignment possibility, assigns the resource to the next request in that order. • Earliest deadline first assigns priorities based on the pending requests with the earliest deadline. – Static scheduling. A cyclic executive schedule is a scheduling strategy where the pre-emption points and the sequence of assignment to the resource are determined offline. 9/14/2014 SEPS ZG651 Software Architectures 19
  20. 20. Performance Tactics 9/14/2014 SEPS ZG651 Software Architectures 20
  21. 21. Security Tactics 9/14/2014 SEPS ZG651 Software Architectures 21
  22. 22. Security Tactics • Tactics for achieving security can be divided into those concerned with – resisting attacks, – detecting attacks – recovering from attacks. 9/14/2014 SEPS ZG651 Software Architectures 22
  23. 23. Resisting Attacks • Authenticate users. • Authorize users. • Maintain data confidentiality • Maintain integrity • Limit exposure • Limit access 9/14/2014 SEPS ZG651 Software Architectures 23
  24. 24. Detecting Attacks • The detection of an attack is usually through an intrusion detection system. • Such systems work by comparing network traffic patterns to a database. • In the case of misuse detection, the traffic pattern is compared to historic patterns of known attacks. • In the case of anomaly detection, the traffic pattern is compared to a historical baseline of itself. 9/14/2014 SEPS ZG651 Software Architectures 24
  25. 25. Recovering From Attacks • Tactics involved in recovering from an attack can be divided into : – restoring state – attacker identification 9/14/2014 SEPS ZG651 Software Architectures 25
  26. 26. Security Tactics 9/14/2014 SEPS ZG651 Software Architectures 26
  27. 27. Testability Tactics • The goal of tactics for testability is to allow for easier testing when an increment of software development is completed. 9/14/2014 SEPS ZG651 Software Architectures 27
  28. 28. INPUT/OUTPUT • There are three tactics for managing input and output for testing. – Record/playback : It refers to both capturing information crossing an interface and using it as input into the test harness. – Separate interface from implementation: The implementation allows substitution of implementations for various testing purposes. – Specialize access routes/interfaces : It allows the capturing or specification of variable values for a component through a test harness as well as independently from its normal execution. • For example, metadata might be made available through a specialized interface that a test harness would use to drive its activities. 9/14/2014 SEPS ZG651 Software Architectures 28
  29. 29. Internal Monitoring • A component can implement tactics based on internal state to support the testing process. – Built-in monitors: The component can maintain state, performance load, capacity, security, or other information accessible through an interface. 9/14/2014 SEPS ZG651 Software Architectures 29
  30. 30. Testability Tactics 9/14/2014 SEPS ZG651 Software Architectures 30
  31. 31. Usability Tactics • It is concerned with how easy it is for the user to accomplish a desired task and the kind of support the system provides to the user. 9/14/2014 SEPS ZG651 Software Architectures 31
  32. 32. Usability Tactics 9/14/2014 SEPS ZG651 Software Architectures 32
  33. 33. Thank You 9/14/2014 SEPS ZG651 Software Architectures 33
  34. 34. SOFTWARE ARCHITECTURE IN PRACTICE Part Two: Creating an Architecture 9/14/2014 SEPS ZG651 Software Architectures34
  35. 35. Chapter 7: Designing the Architecture • Architecture in the life cycle • Designing the architecture • Forming the team structure & its relationship to the architecture • Creating a skeletal system 9/14/2014 SEPS ZG651 Software Architectures 35
  36. 36. Evolutionary Delivery Life Cycle 9/14/2014 SEPS ZG651 Software Architectures 36
  37. 37. Architectural Drivers • Shaping requirements: functional, quality, & business requirements • Find them by: 1 Identify the highest priority business goals (relatively few). 2 Turn these into quality scenarios or use cases. 3 Choose the ones that will have the most impact on the architecture. • These are the architectural drivers & should be < 10. 9/14/2014 SEPS ZG651 Software Architectures 37
  38. 38. Attribute Driven Design • An extension of other methods. • Bases the decomposition process on the quality attributes. • Recursive decomposition: – tactics & architectural patterns are chosen to satisfy a set of quality scenarios – functionality is allocated to instantiate the module types – results in course-grained architecture 9/14/2014 SEPS ZG651 Software Architectures 38
  39. 39. ADD Steps A. Identify an initial set of architectural drivers B. Choose the module to decompose (initially the entire system) C. Refine the module: 1. Choose the specific architectural drivers 2. Choose an architectural pattern that satisfies the drivers, based on the appropriate tactics. Identify child modules to implement the tactics. 3. Instantiate modules & allocate functionality: draw multiple views. 9/14/2014 SEPS ZG651 Software Architectures 39
  40. 40. ADD Steps, con’t 4. Define interfaces of the child modules. The decomposition provides modules & constraints on the types of module interactions. Document. 5. Verify & refine use cases & quality scenarios and make them constraints for the child modules. Verification & preparation for more decomposition or implementation. D. Repeat C for every module that needs further decomposition. 9/14/2014 SEPS ZG651 Software Architectures 40
  41. 41. Creating a Skeletal System • Provide an underlying capability to implement a system’s functionality in an effective order: – Implement execution & interaction. – Install the simplest of functions that instigates some rote behavior. • Result: a running system that sits & hums to itself. – Choose functionality: most problematic; available staff; initial deliverable. – Employ the uses structure to identify additional software to support chosen functionality. 9/14/2014 SEPS ZG651 Software Architectures 41
  42. 42. Skeleton, con’t • Benefits: – At no point is the integration & test overwhelming; easy to find incremental source of errors. – Budgets & schedules are more predictable with smaller increments, providing management & marketing with more delivery options. – Stubs adhere to the final version of interfaces: • help with understanding & testing interactions • producing hardcoded canned output or reading in output • can generate synthetic load that aids early understanding of performance, including interactions & bottlenecks. 9/14/2014 SEPS ZG651 Software Architectures 42
  43. 43. Skeleton, con’t • Potential problem: – The first development team to complete a portion of the system gets to define the interfaces for everyone. – This might be too simple, and penalize the complex parts of the system. – The effect would be to make they complex subsystems more complex. • So, first negotiate the interfaces. 9/14/2014 SEPS ZG651 Software Architectures 43
  44. 44. In Summary • Architectural design must follow requirements analysis, but should begin as soon as the architectural drivers are determined. • When a sufficient portion of the architecture has been designed (but not completed), start building a skeletal framework that is the basis of iterative development. 9/14/2014 SEPS ZG651 Software Architectures 44
  45. 45. Chapter 8: Flight Simulation • Among the most sophisticated software systems: – Highly distributed – Hard real-time performance requirements – Modifiability: changes in requirements, simulated vehicles & environment – Scalability: continuous improvement of the simulation of the real world 9/14/2014 SEPS ZG651 Software Architectures 45
  46. 46. Integrability • A driving concern in large systems • Those developed by distributed teams or separate organizations • Definition: the ease with which separately developed elements, including COTS, can be made to work together to fulfill the system’s requirements. 9/14/2014 SEPS ZG651 Software Architectures 46
  47. 47. Applicable Tactics • Keep interfaces small, simple, and stable. • Adhere to defined protocols. • Loose coupling or minimal dependencies between elements. • Use a component framework. • Use “versioned” interfaces that allow extensions while permitting existing elements to work under the original constraints. 9/14/2014 SEPS ZG651 Software Architectures 47
  48. 48. Pattern: a Structural Model • With the emphasis on: – Simplicity and similarity of system’s substructures – Decoupling of data- and control-passing strategies from computation – Minimizing module types – A small number of system-wide coordination strategies – Transparency of design 9/14/2014 SEPS ZG651 Software Architectures 48
  49. 49. Details, p. 181 • The pattern includes an object-oriented design to model the subsystems and controller children of the air vehicle. It marries real-time scheduling to this OOD as a mean of controlling the execution order of the simulation’s subsystems so that fidelity can be guaranteed. 9/14/2014 SEPS ZG651 Software Architectures 49
  50. 50. Highlights • Architectural solution: – reference model Fig 8.3 • Treatment of time: – Periodic Time Management (for real-time) – Event-based Time Management (non-RT) • Skeletal System: Architecture Prototype – Flight Simulator has 6 module types! – What are the benefits? 9/14/2014 SEPS ZG651 Software Architectures 50
  51. 51. Integrability • Both the data connections and the control connections have been minimized. – Integrating another controller has been reduced to a problem that is linear, not exponential. – Integrating two subsystems is again reduced to ensuring that the two pass data consistently. 9/14/2014 SEPS ZG651 Software Architectures 51
  52. 52. Cost/Benefit Ratio • The cost is that the subsystem controllers often act purely as data conduits, increasing complexity and performance overhead. • In practice (for applicable) systems, the benefits far outweigh the cost: – Architectural skeleton allows incremental development and easier integration. – Every project that has used structural modeling has reported easy, smooth integration. 9/14/2014 SEPS ZG651 Software Architectures 52

×