Sober IT Software Business and Engineering Institute T76

Sober. IT Software Business and Engineering Institute T-76. 5150 Software Architectures Quality attributes: Performance, Dependability, Security, Maintainability, Usability HELSINKI UNIVERSITY OF TECHNOLOGY 1 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Outline § Performance § Dependability § Security § Maintainability § Usability HELSINKI UNIVERSITY OF TECHNOLOGY 2 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute QAs in architecture design Styles, patterns Scenarios Requirements Activities, checklists Tactics, patterns Means of achieving Pitfalls, antipatterns Architecture design process Technologies Design decisions HELSINKI UNIVERSITY OF TECHNOLOGY 3 Documented using architectural views © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Quality Attributes Performance HELSINKI UNIVERSITY OF TECHNOLOGY 4 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Performance § § Performance = the ability of software to provide appropriate response and processing times and throughput rates when performing its function (ISO-9126) Concerns § Responsiveness § Throughput § Predictability § Scalability § Resource utilisation § The time required to respond to a specific event (latency) § The number of events processed in a given interval of time § Distribution of time behaviour § Time behaviour with increasing workloads § E. g. , memory consumption HELSINKI UNIVERSITY OF TECHNOLOGY 5 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Performance scenarios Artifact System Stimulus A number of internal or external events arrive with certain arrival pattern or under certain workload Response Events are processed Bass et al. , 2003 HELSINKI UNIVERSITY OF TECHNOLOGY 6 Measure Within certain time constraints (response time, throughput, variation, miss rate, resource consumption) and with certain probability © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Example performance scenarios § Users initiate 500 queries per minute and these queries are processed within an average response time of one second. § Under load of 350 updates per minute, 95% of updates are processed within 5 seconds. § With 10 concurrent users, system can process 100 requests per minute. § When the number of concurrent users increases from 10 to 100, the average response time should not increase more than 100%. HELSINKI UNIVERSITY OF TECHNOLOGY 7 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Performance vs. hardware § § Common misconception: performance problems can be solved with efficient enough hardware § Hardware processing power has followed Moore’s law However, performance issues are still abundant § § Software complexity has also increased § § Buses, memory, disks etc. become new bottlenecks § Multi-core computer architectures require special attention in order to benefit from parallel processing Embedded devices set constraints on capabilities of the hardware, e. g. , through power consumption and BOM For real-time applications, speed does not solve the problem of schedulability and predictability HELSINKI UNIVERSITY OF TECHNOLOGY 8 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Performance vs. power consumption § § § Instead of hardware purchase cost, cost of electricity could become a major factor in software performance considerations Current power consumption optimisation concentrates mainly on hardware However, software design can also minimise power consumption § § Ensuring overall leanness of software § Minimising certain operations, e. g. , wireless communication Utilising processor idle states, system standby or hibernate, etc. HELSINKI UNIVERSITY OF TECHNOLOGY 9 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Activities for achieving performance § § § Capture performance requirements § For each scenario, define measurable response and workload intensity Create performance models § § Identify performance-critical elements and their tasks Estimate performance metrics for tasks Analyse performance models § Analyse the overall response for scenarios Approach can also be applied by giving time budgets to individual tasks, and evaluating whether these time budgets are realistic Finally, conduct practical testing and assess against the requirements Rozanski & Woods, 2005 HELSINKI UNIVERSITY OF TECHNOLOGY 10 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Example performance model At load of 40 concurrent clients: new. Order: ~3500 ms cancel. Order: ~1500 ms order. Status: ~2500 ms At load of 20 concurrent clients: check. Item: 900 ms 20 is max. concurrency. Above 20, clients queue. Stock checker Round-trip latency ~25 ms Round-trip latency ~35 ms Browser client Order processor Sales database At load of 40 concurrent clients: retrieve 1 order item: ~45 ms remove 1 order item: ~60 ms create 1 order item: ~60 ms When sales report generating, multiply by ~1. 75 Round-trip latency ~90 ms Local invocation, latency neglible Price calculator At load of 40 concurrent clients: get. Price. For. Item: ~1400 ms. OF TECHNOLOGY HELSINKI UNIVERSITY Local invocation, latency neglible Sales report generator 11 © Varvana Myllärniemi, 2008 Rozanski & Woods, 2005

Sober. IT Software Business and Engineering Institute Performance tactics § Performance is often a function of how much communication and interaction there is between the components § § § Partly due to the number of steps involved in processing a task, partly due to overhead involved in the steps This is especially crucial for multi-processing or distributed systems Contention for resources is another affecting factor § § Resources = CPU, memory, disks, databases, etc. At any given moment, a task is either using a resource, waiting for it, or idle HELSINKI UNIVERSITY OF TECHNOLOGY 12 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Tactics for reducing resource demand § § § These tactics reduce the resource demand Optimise dominant and repeated processing § These scenarios matter the most Batch related workloads § Reduces overhead in preparation, data transfer, etc. Coupling § § Match the interface to elements with their most frequent uses Especially important when there is overhead involved in accessing the element Spread the load in time HELSINKI UNIVERSITY OF TECHNOLOGY 13 © Varvana Myllärniemi, 2008 Smith & Lloyd, 2002; Rozanski & Woods, 2005

Sober. IT Software Business and Engineering Institute Tactics for resource management § § § These tactics reduce the contention for resources Minimise the use of shared resources § Maintain multiple copies of data or computations If sharing is needed, avoid exclusive access to resources § When exclusive access is required, minimise holding time Process in parallel § § Real concurrency = separate processors § Things to consider: communication between tasks, context switches between tasks if multiplexed, use of shared resources Apparent concurrency = tasks are multiplexed on a single processor, either as processes or threads Prioritise first things first HELSINKI UNIVERSITY OF TECHNOLOGY 14 © Varvana Myllärniemi, 2008 Smith & Lloyd, 2002; Rozanski & Woods, 2005

Sober. IT Software Business and Engineering Institute Some performance antipatterns § “God” a. k. a. “Blob” § § One element performs most work of the system, delegating only minor tasks to other elements Typically a complex controller utilising simple data containers with get/set Excessive dynamic allocation § Frequent, unnecessary creation and destruction of similar elements Neglecting overhead § § Too much indirection involved Disregard for network and in-process invocation differences HELSINKI UNIVERSITY OF TECHNOLOGY 15 © Varvana Myllärniemi, 2008 Smith & Lloyd, 2002; Rozanski & Woods, 2005

Sober. IT Software Business and Engineering Institute DIY § Within your group, write a performance scenario that describes how weather data arrives and is processed. § What could be performancecritical elements for the scenario? What kinds of resources could be used? What kinds of tactics could be applicable? HELSINKI UNIVERSITY OF TECHNOLOGY 16 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Quality Attributes Dependability HELSINKI UNIVERSITY OF TECHNOLOGY 17 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Dependability § § § § Dependability typically consists of the following attributes: Reliability = continuity of correct service Availability = readiness for correct Dependability service Safety = absence of catastrophic consequences to the user(s) and the environment Integrity = absence of improper system alterations Fault-tolerance = ability to resist anticipated faults Robustness = fault-tolerance for unanticipated faults HELSINKI UNIVERSITY OF TECHNOLOGY 18 © Varvana Myllärniemi, 2008 Reliability Availability Safety Integrity Fault-tolerance Robustness Avizienis et al. , 2004

Sober. IT Software Business and Engineering Institute Faults, errors, failures § § A failure is system’s deviation from the correct service § System cannot provide its functions or provides them incorrectly, or with too long delays An error is an erroneous system state (e. g. incorrect variables) that may lead to a failure § Note: not all errors lead to failures An error is caused by a fault, either internal or external § § § Development fault (a bug) vs. operational fault (incorrect input) Hardware faults (processor fails) vs. software faults (process fails) Human-made faults vs. natural faults The handling of the faults determines the system dependability § Therefore, dependability scenarios often describe the system should respond to faults HELSINKI UNIVERSITY OF TECHNOLOGY 19 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Availability § Availability = probability of ”no failures” § § § Availability = uptime / elapsed time (e. g. 99%) § Downtime per time unit is affected by how often failures or planned downtime occurs, and repair time § § Typically measured against a given period of time (e. g. year) Uptime = time system provides correct services = elapsed time - downtime Repair time § Sometimes the amount of time it takes to error-mode shutdown and new startup, sometimes may involve maintenance and repair actions Some of the downtime may be unplanned, some may be planned § Availability objectives should address both cases © Varvana Myllärniemi, 2008 20 HELSINKI UNIVERSITY OF TECHNOLOGY

Sober. IT Software Business and Engineering Institute Reliability § Reliability = continuity of ”no failures” § § Reliability is often measured with time to failure (TTF) or number of failures in a given time period Reliability is about continuing offering services despite faults happening A system may require high availability but low reliability, and vice versa § Example: aeroplane auto-land system Both reliability and availability should be tied to particular services § Different services may have different requirements for reliability and availability HELSINKI UNIVERSITY OF TECHNOLOGY 21 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Reliability / availability scenarios Stimulus Internal or external fault: crash, omission, timing, break-down, incorrect input, etc. Artifact Resource that should be available: service, processor, communication channel, persistent storage Response Fault is noticed and actions are taken: resist, repair, go to a degrade mode, notify parties Measure Time interval in which the system can be in degraded mode; repair time; availability time Bass et al. , 2003 HELSINKI UNIVERSITY OF TECHNOLOGY 22 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Example reliability / availability scenarios § § § An incorrect external message is received by a process. The process informs the operator of the receipt of the message, discards the message and the system continues to operate with no downtime. While writing summary statistics to database, the system receives an exception indicating that database is full. The system should immediately stop processing the statistics set, log fatal message and shut down. The processor hardware that the process runs on fails. The process should be switched to a new processor without any loss of data and within 15 minutes. HELSINKI UNIVERSITY OF TECHNOLOGY 23 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Activities for availability § § Capture availability requirements and schedule § § § Types of services Levels of services Required schedule for services Estimate platform availability § § Hardware: may utilise published MTTF rates OS, network, middleware: more difficult to estimate than for hardware Estimate functional availability § Mainly about identifying planned downtime Assess against the requirements § Combine platform and functional availability HELSINKI UNIVERSITY OF TECHNOLOGY 24 © Varvana Myllärniemi, 2008 Rozanski & Woods, 2005

Sober. IT Software Business and Engineering Institute Tactics for reliability and availability § § § Prevent faults from happening § Use fault-tolerant hardware, e. g. RAID Detect faults § § E. g. watchdog, heartbeats/pings, monitors, exceptions etc. Message / input checks Repair faults § § § Redundancy, both software and hardware § Hardware clustering and load balancing Backup of data, state rollback, use of transactions Switch levels of service Report faults § Logging etc. Establish a strategy for design-level solutions § Error and exception handling HELSINKI UNIVERSITY OF TECHNOLOGY 25 © Varvana Myllärniemi, 2008 Bass et al. , 2003; Rozanski & Woods, 2005

Sober. IT Software Business and Engineering Institute Safety § § § Safety = absence of catastrophic consequences to the user(s) and the environment § § These consequences may involve injuries or deaths Example: embedded software in cars Safety is addressed by identifying possible conditions of the system (hazards) that may lead to undesirable consequences (mishaps) § § § Example hazard: ABS ceases working properly Example mishap: a car falls off the road Mishaps are prevented by preventing hazards Capturing and achieving safety requirements is often similar to reliability HELSINKI UNIVERSITY OF TECHNOLOGY 26 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute DIY § Within your group, identify services and levels of services in the system. § Identify some faults that could be critical for dependability point of view. Try to write at least one appropriate scenario. HELSINKI UNIVERSITY OF TECHNOLOGY 27 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Quality Attributes Security HELSINKI UNIVERSITY OF TECHNOLOGY 28 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Security § § Security = the capability of the software to protect information so that unauthorised persons or systems cannot read or modify them and authorised persons or systems are not denied access to them (ISO/IEC 9126, 2001) Security is divided into the following attributes § § § Confidentiality = protection of unauthorised disclosure Integrity = protection of unauthorised modification Availability = protection from denial of service to authorised users Accountability = capability of tracing actions unambiguously to the actor Compared to performance and reliability, security has no clean quantitative measures HELSINKI UNIVERSITY OF TECHNOLOGY 29 © Varvana Myllärniemi, 2008 Integrity Availability

Sober. IT Software Business and Engineering Institute Assets, threats, countermeasures § § Security is about protecting assets (information, services) Security is about threats that could be targeted to assets § § § Eavesdropping, denial of service, tampering, replaying, stealing, etc. Threats exploit vulnerabilities in the system or in the organisation Threats materialise in the form of attacks Countermeasures are imposed to reduce vulnerabilities § § § At the requirements level At the architecture level At the design level Principals are users or other systems using system services HELSINKI UNIVERSITY OF TECHNOLOGY 30 © Varvana Myllärniemi, 2008 (ISO/IEC 15408, 1998)

Sober. IT Software Business and Engineering Institute Security scenarios Artifact Assets (data, services) Stimulus Attack: threat agent (user, outsider, another system) tries to display data, change/delete data, access system services, reduce availability to system services Response + Measure Attack is detected, prevented, resisted, alleviated or recovered using a countermeasure, with certain probability Bass et al. , 2003 HELSINKI UNIVERSITY OF TECHNOLOGY 31 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Example security scenarios § § A third party component attempts to modify information it is not authorised to modify. The attempt is prevented by restricting third party components’ freedom of execution. A student attempts to exploit an application that has been left unattended. This is prevented by locking the application after a certain elapsed time and requiring authentication to a locked application. A thief has gained physical access to the mobile device. Unwanted incidents are reduced by encrypting sensitive information stored on the device. A cracker tries to log in into an authenticated service by bruteforce guessing. The attempt is prevented by using nontransferable authentication tokens (e. g. biometric authentication). HELSINKI UNIVERSITY OF TECHNOLOGY 32 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Capturing requirements with misuse cases HELSINKI 2003 UNIVERSITY OF TECHNOLOGY Alexander, 33 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Activities for achieving security § Identify sensitive assets § Define security policy § Who can access what (access control) § Identify threats to the system § Design security implementation § For each threat, design a way to migitate them § Design a detection and recovery approach for security policy breeches § For selected technologies, assess and integrate them HELSINKI UNIVERSITY OF TECHNOLOGY 34 © Varvana Myllärniemi, 2008 Rozanski & Woods, 2005

Sober. IT Software Business and Engineering Institute Security tactics § § Prevent / resist attacks § § § § Authenticate principals (how, with what) Authorise access (access control) Limit exposure, e. g. hide services Limit access, e. g. single access point Compartmentalisation, e. g. sandboxing Obfuscation, e. g. cryptography Fairness, e. g. bandwidth throttling Detect attacks § Monitoring, logging Alleviate attacks § Limit unwanted consequences Recover from attacks § Restoration, e. g. redundancy HELSINKI UNIVERSITY OF TECHNOLOGY 35 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute DIY § Within your group, identify some sensitive assets and threats to the system. § Try to construct a scenario that addresses some threat. HELSINKI UNIVERSITY OF TECHNOLOGY 36 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Quality Attributes Maintainability, modifiability HELSINKI UNIVERSITY OF TECHNOLOGY 37 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Maintainability § § Maintainability = the ease with which a software system can be maintained § May address activities before the first release and after it Maintainability is probably the most architecturally sensitive quality attribute § § Maintainability is determined by how functionality is divided If changes can be localised into one or few components, they are often easier to implement Flexibility Reusability Maintainability Extensibility Modifiability Portability Integrability HELSINKI UNIVERSITY OF TECHNOLOGY 38 © Varvana Myllärniemi, 2008 Testability (Matinlassi and Niemelä, 2003)

Sober. IT Software Business and Engineering Institute Maintainability § § § Maintainability is often specified by specifying the change requests that may be targeted to the system For each change request, the response of the system is the required change § § § Also the probability of change requests should be anticipated § § How many components are changed / added / deleted? What is the cost of implementing the change request? How long does it take to implement the change request? More probable or frequent changes should be easier to implement Maintainability is typically achieved by adding indirection or abstraction HELSINKI UNIVERSITY OF TECHNOLOGY 39 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Modifiability scenarios Artifact Stimulus End user, developer, system administrator wishes to add / delete / modify / vary functionality, quality attribute, capacity System user interface, platform, environment, system that interoperates with target system Response Modification is made / tested / deployed (Bass et al. , 2003) HELSINKI UNIVERSITY OF TECHNOLOGY 40 © Varvana Myllärniemi, 2008 Measure Cost in terms of number of elements affected / effort / money; extent to which this affects other functions or quality attributes

Sober. IT Software Business and Engineering Institute Activities for achieving maintainability § § Characterise the evolution needs § § Type of change required Magnitude of change required Likelihood of change Timescale of required changes Assess the current ease of evolution § § § Evaluate also whether support for evolution is needed Flexibility doesn’t come without a cost Preparing for changes that never occur is a major waste of resources § Compare to XP, which doesn’t anticipate any particular change HELSINKI UNIVERSITY OF TECHNOLOGY 41 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Maintainability tactics § § § Localise change § § § Encapsulation Abstraction and generalisation Decompose system elements with clear responsibilities § Also define clear interfaces between system elements § Semantic coherence of responsibilities, measured against development effort / anticipated changes Prevent ripple effect § Maintain interfaces by e. g. creating flexible parameters § § Use an intermediary Hide information § In general, design of good interfaces is a cornerstone Compare these to many of the original design patterns. . . HELSINKI UNIVERSITY OF TECHNOLOGY 42 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Maintainability tactics § Introduce variation points § That is, postpone binding time of design decisions § Enable support for element replacement § Ensure configurability of system (e. g. configuration files, runtime registration) § Parameterise operations § Use polymorphism § Separate physical and logical processing, e. g. data format from logical data model HELSINKI UNIVERSITY OF TECHNOLOGY 43 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Quality Attributes Usability HELSINKI UNIVERSITY OF TECHNOLOGY 44 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Usability § Usability can be divided into the following attributes (Folmer and Bosch, 2004) Efficiency Usability § Key question: is usability an architecturally sensitive quality attribute? HELSINKI UNIVERSITY OF TECHNOLOGY Learnability Memorability Error avoidance and handling User satisfaction 45 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Usability § § § Usability is mostly a matter of detailed design § § A matter of getting the details of the user interface correct If user interface is separated from the architecture, these details are not architectural However, usability issues may have architectural impacts § § Right information must be available to the user at the right time User’s instructions must get to the right destination Efficiency has performance implications Example: undo operation (Folmer and Bosch, 2004) Therefore, usability must be considered when designing the architecture (Folmer and Bosch, 2004) HELSINKI UNIVERSITY OF TECHNOLOGY 46 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute Further reading in course book § § The perspective catalogue in the back of the book contains further discussion about certain quality attributes § § Security perspective Performance and scalability Availability and resilience Evolution perspective Each perspective discusses § § Concerns (characteristics) Tactics (means of achieving) Activities that one should execute Applicability to architectural views HELSINKI UNIVERSITY OF TECHNOLOGY 47 © Varvana Myllärniemi, 2008

Sober. IT Software Business and Engineering Institute References Avizienis, Algirdas; Laprie, Jean-Claude; Randell, Brian and Landwehr, Carl. Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing, 1(1), 2004. Bass, Len; Clements, Paul and Kazman, Rick. Software Architecture in Practice. 2 nd edition. Addison-Wesley, 2003. Folmer, Eelke and Bosch, Jan. Architecting for Usability: A Survey. Journal of Systems and Software 70, 2004. ISO/IEC 15408 -1. Information technology – Security techniques – Evaluation criteria for IT security – Part 1: Introduction and general model. ISO/IEC Standard 154081, 1999. ISO/IEC 9126 -1. Software engineering – Product quality – Part 1: Quality model. ISO/IEC Standard 9126 -1: 2001, 2001. Matinlassi, Mari and Niemelä, Eila. The Impact of Maintainability on Component-based Software Systems. Proc. of EUROMICRO Conference (EUROMICRO’ 03). 2003. Rozanski, Nick and Woods, Eoin. Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Addison-Wesley, 2005. Smith, Connie and Lloyd, William. Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software. Addison-Wesley, 2002. HELSINKI UNIVERSITY OF TECHNOLOGY 48 © Varvana Myllärniemi, 2008