Lecture Two: Design and Arch - PDF

Lecture two Architectural System requirements Quality Attribute Scenarios Architectural Tactics Architectural Patterns By Destaye A.  Architectural System requirements System requirements can be categorized into three as Functional requirements (FR) what the...

Lecture two Architectural System requirements Quality Attribute Scenarios Architectural Tactics Architectural Patterns By Destaye A.  Architectural System requirements System requirements can be categorized into three as Functional requirements (FR) what the system should do to meet user needs. Non-functional requirements (NFR) o Quality attribute (QA) requirements o Operational Requirements they need to be properly elicited and analyzed as they are vital to a system Constraints – represent the limitation or boundaries within witch the system must operate.  Quality attribute  Functionality has a strange relationship to architectures That is, functionality and quality attributes are orthogonal This doesn’t mean functional and non-functional requirements are unrelated but In fact , they may related tightly FR – submit order NFRs – Availability: 7-5 mon-fri non functional have no purpose or context without function  QA QA Considerations If a functional requirement is "when the user presses the green button the options dialog appears” how quickly the dialog will appear - a performance how often this function will fail, and how quickly it will be repaired - availability how easy it is to learn this function - usability  QA  There are two problems with previous discussions of quality attributes Untestable definitions - It is meaningless to say that a system will be “modifiable”. Overlapping concerns - Is a system failure due to a denial of service attack an aspect of availability, performance, security, or usability? Solution The first two of these problems is to use quality attribute scenarios as a means of characterizing quality attributes  Quality Attribute Scenarios  QAS are used to specify all quality attribute requirements  It is a framework used to software architecture to evaluate and understand how different quality attributes. impact a software system It has six parts: 1. Source of stimulus –is some entity or component (a human, a computer system, or any other that case a change in the system’s behavior and that generated the stimulus. 2. Stimulus - is a condition or action or event that requires a response when it arrives at a system. 3. Environment – system conditions (overload condition or in normal operation, or some other relevant state) when a stimulus occurs  QAS 4. Artifact - may be a collection of systems, the whole system, or some piece or same part of software system. 5. Response - is the activity undertaken as the result of the arrival of the stimulus. 6. Response measure - when the response occurs, it should be measurable in some fashion so that the requirement can be tested. QAS  QAS  QAS can be: General quality attribute scenarios - are system independent and can, potentially, pertain to any system concrete quality attribute scenarios - are specific to the particular system under consideration , QAS QAS  Features of Concrete Scenarios  A collection of concrete scenarios can be used as the QA requirements of a system.  When eliciting requirements, discussions of general scenarios are organized by QAs.  If the same scenario is generated by two different attributes, one can be eliminated.  As use cases are for FRs Concrete scenarios are for NFRs Features of Concrete Scenarios  Con..  QA requirements should be obtained during requirements elicitation, but in practice it is seldom done. It is the architect’s task to ensure that this is accomplished by generating concrete quality attribute scenarios, Quality-attribute-specific tables are used to create general scenarios, as appropriate, and from them concrete scenarios are specified. Example General scenario - "A request arrives for a change in functionality, and the change must be made at a particular time within the development process within a specified period." Specific scenario - "A request arrives to add support for a new browser to a Web based system, and the change must be made within two weeks."  Quality Attributes: Availability  Availability is concerned with system failure and its consequences. Areas of concern: How the system failure is detected? Frequency of failure? What happens when a failure occurs? How long a system is allowed to be out of operation? When failures may occur safely? How failures can be prevented? What kinds of notifications are required when a failure occurs? Differentiate between failures and faults. fault may become a failure if not corrected or masked. Once a system fails, we must consider the time it takes to repair it. Availability is defined as the probability that it will be operational when needed, typically, (mean time to failure) / (mean time to failure + mean time to repair) GQAS ,Attributes: Availability  Availability: Sample Concrete Scenario Example : The heartbeat monitor determines that the server is nonresponsive during normal operations. The system informs the operator and continues to operate with no downtime  Performance: Performance is about timing - how long it takes the system to respond when an event occurs.  That is events (interrupts, messages, requests from users, or the passage of time) occur, and the system must respond to them in a reasonable time.  Events can arrive from user requests, from other systems, or from within the system.  Performance is complicated because of the number of event sources and arrival patterns. An arrival pattern can be: Periodic – a periodic event may arrive every 10 milliseconds Stochastic - events arrive according to some probabilistic distribution Sporadic – events recurring in scattered and irregular or unpredictable instances. Performance: General Scenario  Performance: Sample Concert Scenario  Example : Users initiate transactions under normal operations. The system processes the transactions with an average latency of two seconds Other QA…  Architectural Tactics  a collection of design decisions that affect how the system implement one or more quality attribute requirement.  Some ensure achievement of the system  Others help control the QAs responses (which we call them tactics) and influences their.  Architectural Tactics Tactics to Control Stimulus Response Response  An architectural tactic : satisfying a quality-attribute- response measure by manipulating some aspect of a QA model through architectural design decisions.  Availability Tactics  A fault has the potential to cause a failure  Recovery/repair is an important aspect of availability.  Availability is about reliability and recovery  The tactics will keep faults from becoming failures or at least bound the effects of the fault and make repair possible. Fault Tactics Fault Masked or to Control Repair Made Availability  Three categories of availability tactics are  Fault Detection  Fault Prevention (Preparation & Repair, Re-introduction)  Fault Recovery  Fault Detection Tactics  Ping/echo : One component issues a ping and expects to receive back an echo within a predefined time, from the component. Failure to receive the echo indicates the presence of a fault  Monitor:  A component used to monitor the state of health of other parts of the system: processors, processes, I/O, memory, and so on  A system monitor can detect failure in the network or other shared resources, such as from a denial-of-service attack.  Heartbeat:  one component emits a heartbeat periodically and another component listens for it. Failure to receive a heartbeat by a listener shows the failure of the component.  For example, an ATM can periodically send the log of the last transaction to a server. This message not only acts as a heartbeat but also carries data  Fault Detection Tactics  Condition Monitoring: checking conditions in a process or device, or validating assumptions made during the design.  Voting: to check that replicated components are producing the same results. E.g. triple modular redundancy (TMR) - employs three components that do the same thing, each of which receives identical inputs, and forwards their output to voting logic, used to detect any inconsistency among the three output states  Comes in various flavors: replication, functional redundancy, analytic redundancy  Self-test: procedure for a component to test itself for correct operation Fault Recovery Tactics (Preparation & Repair)  Active redundancy (hot restart): All redundant components respond to events in parallel and the response from only one component is used (usually the first to respond). Often used in a client/server configuration, such as database management systems, where quick responses are necessary even when a fault occurs.  Passive Redundancy (warm spare): Only the active members of the protection group process input traffic; one of their duties is to provide the redundant spare(s) with periodic state updates. Fault Recovery Tactics (Preparation & Repair)  Spare (cold spare): redundant spares of a protection group remain out of service until a failure occurs, at which point a power-on-reset procedure is initiated on the redundant spare prior to its being placed in service.  Exception Handling: dealing with the exception by reporting it or handling it, potentially masking the fault by correcting the cause of the exception and retrying.  Rollback: Back to a previous known good state, referred to as the “rollback line”  Software Upgrade: in-service upgrades to executable code images in a non-service- affecting manner.  Prevent Faults  Removal From Service: temporarily placing a system component in an out-of-service state for the purpose of mitigating potential system failures  Transactions: bundling state updates so that asynchronous messages exchanged between distributed components are atomic, consistent, isolated, and durable.  Predictive Model: monitor the state of health of a process to ensure that the system is operating within nominal parameters; take corrective action when conditions are detected that are predictive of likely future faults.  Interoperability Tactics  For two or more systems to usefully exchange information they must:  Know about each other- that is the purpose behind the locate tactics  Exchange information in a semantically meaningful fashion - that is the purpose behind the manage interfaces tactics. Two aspects of the exchange are Provide services in the correct sequence Modify information produced by one actor to a form acceptable to the second actor. Interoperability Tactics  Interoperability Tactics Discover service: Locate a service through searching a known directory service. There may be multiple levels of indirection in this location process – i.e. a known location points to another location that in turn can be searched for the service. Orchestrate: uses a control mechanism to coordinate, manage and sequence the invocation of services. Orchestration is used when systems must interact in a complex fashion to accomplish a complex task. Tailor Interface: add or remove capabilities to an interface such as translation, buffering, or data-smoothing.  Modifiability Tactics  Goal is to control the time and cost to implement, test and deploy changes.  Specific tactics include: Localize modifications Prevent ripple effects Defer binding time Tactics Changes Made, Change Tested, and to Control Modifiability Arrives Deployed Within Time and Budget  Modifiability Tactics Modifiability Tactics Reduce Size Increase Reduce Defer of a Module Cohesion Coupling Binding Change Changes Made Requests Increase Encapsulate and Deployed Split Module Semantic Use an Coherence Intermediary Restrict Dependencies Refactor Abstract Common Services  Modifiability Tactics: to reduce size of module  Split Module: If the module being modified includes a great deal of capability, the modification costs will likely be high. Refining the module into several smaller modules should reduce the average cost of future changes.  Increase Semantic Coherence: If the responsibilities A and B in a module do not serve the same purpose, they should be placed in different modules. This may involve creating a new module or it may involve moving a responsibility to an existing module  Encapsulate: Encapsulation introduces an explicit interface to a module and its associated responsibilities.  Security Tactics  Tactics for achieving security can be divided into those concerned with Resisting attacks Detecting attacks Recovering from attacks System Detects, Tactics Resists, or Recovers to Control Attack from Attacks Security  Analogy: Putting a lock on your door is a form of resisting an attack, Having a motion sensor inside of your house is a form of detecting an attack, and Having insurance is a form of recovering from an attack.  Security tactics Security Tactics Detect Attacks Resist Attacks React to Recover Attacks from Attacks Identify Actors Revoke Detect Maintain Restore Access Intrustion Authenticate Audit Trail Attack System detects, Detect Service Actors Lock resists, reacts, Denial Computer or recovers Authorize See Verify Message Actors Availability Integrity Inform Actors Detect Message Limit Access Delay Limit Exposure Encrypt Data Separate Entities Change Default Settings  Security Tactics: Detect Attacks  Detect Intrusion: compare network traffic or service request patterns within a system to a set of signatures or known patterns of malicious behavior stored in a database.  Detect Service Denial: comparison of the pattern or signature of network traffic coming into a system to historic profiles of known DoS attacks.  Verify Message Integrity: use techniques such as checksums or hash values to verify the integrity of messages, resource files, deployment files, and configuration files.  Detect Message Delay: checking the time that it takes to deliver a message, it is possible to detect suspicious timing behavior.  Security Tactics: Resist Attacks  Identify Actors: identify the source of any external input to the system.  Authenticate Actors: ensure that an actor (user or a remote computer) is actually who.  Authorize Actors: ensuring that an authenticated actor has the rights to access and modify either data or services.  Limit Access: limiting access to resources such as memory, network connections, or access points.  Lock Computer: limit access to a resource if there are repeated failed attempts to access it.  Architectural Patterns What is a Pattern or Style? Is general ,reusable resolution to a commonly occurring design problem in software architecture within a given context and define the high level structure and organization of the system.  There are many ways to do design badly, and just a few ways to do it well. Success in architectural design is complex and challenging Designers have been looking for ways to capture and reuse hard-won architectural knowledge.  Architectural patterns has ways of capturing proven good design structures, so that can be reused.  An architectural pattern is a package of design decisions that is found repeatedly in practice, has known properties that permit reuse describes a class of architectures  An architectural pattern establishes a relationship between: A context - a recurring, common situation in the world that gives rise to a problem. The preconditions under which the pattern is applicable - a description of the initial state before the pattern is applied. A problem - appropriately generalized problem, that arises in the given context. A solution. A successful architectural resolution to the problem, appropriately abstracted. The solution for a pattern is determined and described by: A set of element types (data repositories, processes, objects, …) A set of interaction mechanisms or connectors (method calls, events, message bus, …) A topological layout of the components A set of semantic constraints covering topology, element behavior, and interaction mechanisms  Patterns (or styles) benefits: Promotes communications among the designers because the pattern names are used as a shorthand for a lengthy description Streamlines documentation for the same reason above Supports high level of reuse if the pattern is applicable Improves development efficiency and productivity for above reasons. Provide a starting point for additional and new design ideas.  There are various types of architectural styles Most common ones are:- Layered, Broker, MVC, Pipe-and-filter, Client-Server, P2P, SOA, Publish-Subscribe, Shared-data, Map-reduce, Multi- tier, …  Layer Pattern  There is a need to develop and maintain portions (modules) of a complex system independently.  Modules should have clear and well-documented separation of concerns and should have little interaction among them through public interface.  To achieve this separation of concerns, the layered pattern divides the software into units called layers  Each layer is a grouping of modules that offers a cohesive set of services. The usage must be unidirectional. Layer Pattern Example  Broker Pattern  Implementing systems with a collection of services distributed across multiple servers is complex.  Difficulties lies on how the systems will interoperate how they will connect to each other and how they will exchange information How to make sure the availability of the component services  Structuring distributed software so that service users do not need to know the nature and location of service providers is vital This makes easy to dynamically change the bindings between users and providers  The broker pattern separates users of services from providers of services by inserting an intermediary. Broker mediates the communication between a number of clients and servers. Broker Example Model-View-Controller Pattern  MVC pattern separates application functionality into three kinds of components MVC Example  Pipe and Filter Pattern  Many systems require successively transform streams of discrete data items, from input to the next output  Such systems need to be divided into reusable, loosely coupled components with simple, generic interaction mechanisms.  Pipe-and-filter pattern is characterized by successive transformations of streams of data. Data arrives at a filter’s input port(s), is transformed, and then is passed via its output port(s) through a pipe to the next filter. A single filter can consume data from, or produce data to, one or more ports. Pipe and Filter Example  Client-Server Pattern  There are shared resources and services that large numbers of distributed clients wish to access, and for which we wish to control access or quality of service.  Managing the set of shared resources and services vital to – promote modifiability and reuse – improve scalability and availability  Clients interact by requesting services of servers, which provide a set of services. – Some components may act as both clients and servers. – There may be one central server or multiple distributed ones. Client-Server Example  Peer-to-Peer Pattern  Distributed computational entities—each of which is considered equally important in terms of initiating an interaction and each of which provides its own resources— need to cooperate and collaborate to provide a service to a distributed community of users.  P2P enables a set of “equal” distributed computational entities be connected to each other via a common protocol so that they can organize and share their services with high availability and scalability?  In the P2P pattern, components directly interact as peers. – P2P communication is typically a request/reply interaction without the asymmetry found in the client-server pattern Peer-to-Peer Example Service Oriented Architecture Pattern  A number of services are offered (and described) by service providers and consumed by service consumers.  Service consumers need to be able to understand and use these services without any detailed knowledge of their implementation.  How can we support interoperability of distributed components running on different platforms and written in different implementation languages, provided by different organizations, and distributed across the Internet?  The SOA pattern describes a collection of distributed components that provide and/or consume services. SOA Example  Shared-Data Pattern  Various computational components need to share and manipulate large amounts of data. This data does not belong solely to any one of those components.  How can systems store and manipulate persistent data that is accessed by multiple independent components?  In the shared-data pattern, interaction is dominated by the exchange of persistent data between multiple data accessors and at least one shared-data store. – Exchange may be initiated by the accessors or the data store. – The connector type is data reading and writing. Shared-Data Example  Map-Reduce Pattern  Businesses have a pressing need to quickly analyze enormous volumes of data they generate or access, at petabyte scale.  How to efficiently perform a distributed and parallel sort of a large data set and provide a simple means for the programmer to specify the analysis to be done. – For many applications with ultra-large data sets, sorting the data and then analyzing the grouped data is sufficient.  The map-reduce pattern requires three parts: – An infrastructure that takes care of allocating software to the hardware nodes in a massively parallel computing environment & handles sorting the data as needed. – Map which filters the data to retrieve those items to be combined. – Reduce which combines the results of the map Map-Reduce Example  Multi-Tier Pattern  In a distributed deployment, there is often a need to distribute a system’s infrastructure into distinct subsets.  How can we split the system into a number of computationally independent execution structures— groups of software and hardware—connected by some communications media?  The execution structures of many systems are organized as a set of logical groupings of components. – Each grouping is termed a tier Multi-Tier Example Thank you ?