Achieving Qualities Software Architecture Jay Urbain, PhD urbain@msoe.edu Credits: • Len Bass, Paul Clements, Rick Kazman, 3 rd Ed. • http://en.wikipedia.org/wiki/Web_service • Relationship to the World Wide Web and REST Architectures". Web Services 1 Architecture.W3C. Retrieved 2014-04-22.
System Design Quality attribute (QA) : Measureable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders, i.e., the functionality of the system. Think of QA as measuring the “ goodness ” of a product along some dimension of interest to a stakeholder. 2
Types of Requirements Functional: • What the system must do or how the system must react to some stimuli. Quality attributes (non-Functional): • Qualifications of functional requirements or the whole product. Constraints: • Design decision with zero degrees of freedom. • Typically a decision that has already been made. • Are constraints a good thing? 3
System Design Set of architectural decisions: • Achievement of system functionality • Controlling the quality attribute response 4
Architecture & Requirements • What is the response of architecture to each of these kinds of requirements? – Functional requirements – QA requirements 5
Architecture & Requirements • What is the response of the architecture to each of these kinds of requirements? – Functional requirements are satisfied by assigning an appropriate sequence of responsibilities to software elements through the design. – QA requirements are satisfied by the various structures designed into the architecture , and the behaviors and interactions of the elements that populate those structures. 6
Tactics • A tactic is a design decision that influences the control of a quality attribute response. • A collection of tactics is an architectural strategy. • Interested in the tactics used by the architect to create a design including: – architectural design patterns, or architectural strategies. 7
Tactics Example: • Introduce redundancy to increase the availability of the system. • Consequence: – the need for synchronization. 8
Organizing Tactics Ramifications • Tactics can refine other tactics – Organize tactics for each quality attribute in a hierarchy • Use patterns to package tactics 9
Tactics Review tactics for the following quality attributes: • Availability • Interoperability • Modifiability • Performance • Security • Testability • Scalability • Usability 10
Availability Tactics • Failure occurs when the system no longer delivers a service that is consistent with its specification. • Recovery/repair is an important aspect of availability. • All approaches to maintaining availability involve some type of redundancy . • Categorize tactics: fault detection, fault recovery, and fault prevention. 11
• Availability Tactics 12
Detect Faults • Ping/echo – determine if pinged component is reachable or alive. • Monitor – component monitors health of the system. • Heartbeat – periodic message from process being monitored and system monitor. Flip responsibilities from ping/echo. • Time stamp – detect proper sequences of events (especially for distributed systems). Establish proper sequence by assigning state of logical clock to the event. • Sanity checking – check validity of operations or outputs, e.g., validate information flow. • Condition monitoring – check conditions within component, e.g., checksum. • Voting – Triple modular redundancy – have 3 components due the same thing and vote on proper output. • Exception detection – exception capture. • Self-test – periodic self-test. 13
Recover from Faults • Preparation and repair • Reintroduction 14
Recover from Faults - Preparation and repair • Active redundancy – hot spare – All nodes in a protection group receive and process identical inputs in parallel. – Redundant spares maintain synchronous state with the active nodes. • Passive redundancy – warm spare – Only active members of protection group process input traffic; provide redundant spares with periodic state updates, e.g., check pointing. – Loose coupling • Spare – cold spare – Redundant spares remain out of service until a failure occurs. Level of “ warmth ” determined by quality attribute response. 15
Recover from Faults – Preparation and repair • Exception handling – Tactics to manage exception when it occurs. • Rollback – Revert to previous known/good state. – Can reinitiate. • Software upgrade – In-service software upgrades. • Retry – Assume fault is transient, e.g., dropped packet, system busy. • Ignore faulty behavior – May just ignore spurious messages, e.g., denial of service attack. • Degradation – Maintain most critical system components, fail gracefully. • Reconfiguration 16 – Recover from component failures by reassigning responsibilities
Recover from Faults – Reintroduction • Shadow – Operate previously failed or in-service component mode in a “ shadow mode ” for a predefined duration of time prior to reassuming active role. • State resynchronization – Activate partner in active and passive redundancy – Re-synch states of active and standby components. • Escalating restart – Support multiple levels of restart based on severity of fault. E.g., level 0 = restart process, level 1 = re-initialization, level n = restart system, etc. • Non-stop forwarding – From router design – Functionality split into two parts: supervisory/control plane, and data plane. – If a failure occurs in a supervisor component, can still forward packets along known routes (can ’ t determine new routes). 17
Recover from Faults – Prevent faults • Removal from service – Mitigate failure by placing component out of service. • Transactions – ACID properties • Predictive model – Combine model with monitor to predict health of system. • Exception prevention – Prevent system exceptions from happening. • Increase competence – When a component generates an exception it is outside of its competence level, e.g., divide by zero. Handle divide by zero. 18
Interoperability Tactics • Degree to which two or more systems can usefully exchange meaningful information. – Ability to exchange data ( syntax ) – Ability to interpret data ( semantics ) • Need to identify with whom, with what, and under what circumstances (context); and quality of service! 19
Interoperability: Reasons • System provides a service to be used by a collection of unknown systems. – E.g., Google Maps, IMDB, Yahoo Stock Quoter • Constructing capabilities from existing systems. – E.g., HealthCare.gov orchestrates insurance coverage using multiple component systems: FBI background check, IRS income verification, insurance provider EDI, etc. – E.g., one system may sense the environment, another system is responsible for processing the raw sensor data. – Software as a Service (SaaS) paradigm. – Promotes cohesion of service purpose, loose coupling of services facilitates flexibility. 20
Aspects of Interoperability • Discovery – The consumer of a service must discover (possibly at runtime, or prior to runtime) the location , identity , and the interface of the service. • Handling of response – distinct possibilities: – The service reports back to the requester with the response. – The service sends its response on to another system . – The service broadcasts its response to any interested parties 21
Systems of Systems (SoS) • Directed – SoS objectives, centralized management, funding, and authority for the overall SoS are in place. Healthcare.gov? – Systems are subordinate to the SoS. • Acknowledged – Systems retain their own management, funding, and authority in parallel with the SoS. Saber reservation system provided to airlines. – Maintain high degree of autonomy, service level agreement (SLA). • Collaborative – There are no overall objectives, centralized management, authority, responsibility, or funding at the SoS level. – Systems voluntarily work together to address shared or common interests. – E.g., Google Maps. Google provides it s own management and funding, various organizations collaborate. • Virtual – Like collaborative, but systems don ’ t know about each other. – Large systems must interoperate but no central management authority, 22 – E.g., p2p file sharing, electric utilities
General Interoperability Scenario • Source of stimulus: – System initiates a request to interoperate with another system. • Stimulus: – Request to exchange information. • Artifacts: – The systems (and system components) that wish to interoperate. • Environment: – Systems that wish to interoperate are discovered at runtime or are known prior to runtime; operating environment. • Response: – Request to interoperate results in the exchange of information. Info is understood or rejected • Response measure: – % of info exchanges correctly processed or % of info exchanges correctly rejected. 23
Recommend
More recommend
