T-76. 5150 Software Architectures Quality attributes



Yüklə 470 b.
tarix25.05.2018
ölçüsü470 b.
#45757


T-76.5150 Software Architectures

  • Quality attributes:

  • Performance, Dependability, Security, Maintainability, Usability


Outline

  • Performance

  • Dependability

  • Security

  • Maintainability

  • Usability



QAs in architecture design



Quality Attributes

  • Performance



Performance

  • Performance = the ability of software to provide appropriate response and processing times and throughput rates when performing its function (ISO-9126)

  • Concerns

    • Responsiveness
      • The time required to respond to a specific event (latency)
    • Throughput
      • The number of events processed in a given interval of time
    • Predictability
      • Distribution of time behaviour
    • Scalability
      • Time behaviour with increasing workloads
    • Resource utilisation
      • E.g., memory consumption


Performance scenarios



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%.



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
    • Multi-core computer architectures require special attention in order to benefit from parallel processing
    • Buses, memory, disks etc. become new bottlenecks
    • 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


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
    • Utilising processor idle states, system standby or hibernate, etc.
    • Minimising certain operations, e.g., wireless communication


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



Example performance model



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


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



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
    • Apparent concurrency = tasks are multiplexed on a single processor, either as processes or threads
    • Things to consider: communication between tasks, context switches between tasks if multiplexed, use of shared resources
  • Prioritise first things first



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


DIY

  • Within your group, write a performance scenario that describes how weather data arrives and is processed.

  • What could be performance-critical elements for the scenario? What kinds of resources could be used? What kinds of tactics could be applicable?



Quality Attributes

  • Dependability



Dependability

  • Dependability typically consists of the following attributes:

  • Reliability = continuity of correct service

  • Availability = readiness for correct 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



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


Availability

  • Availability = probability of ”no failures”

    • Availability = uptime / elapsed time (e.g. 99.99%)
    • Typically measured against a given period of time (e.g. year)
    • Uptime = time system provides correct services = elapsed time - downtime
    • Downtime per time unit is affected by how often failures or planned downtime occurs, and repair time
    • 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


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


Reliability / availability scenarios



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.



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


Tactics for reliability and availability

  • Prevent faults from happening

  • 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


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



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.



Quality Attributes

  • Security



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



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


Security scenarios



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 brute-force guessing. The attempt is prevented by using non-transferable authentication tokens (e.g. biometric authentication).



Capturing requirements with misuse cases



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


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


DIY

  • Within your group, identify some sensitive assets and threats to the system.

  • Try to construct a scenario that addresses some threat.



Quality Attributes

  • Maintainability, modifiability



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


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

    • 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?
  • Also the probability of change requests should be anticipated

    • More probable or frequent changes should be easier to implement
  • Maintainability is typically achieved by adding indirection or abstraction



Modifiability scenarios



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


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
      • In general, design of good interfaces is a cornerstone
    • Use an intermediary
    • Hide information
  • Compare these to many of the original design patterns...



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


Quality Attributes

  • Usability



Usability

  • Usability can be divided into the following attributes (Folmer and Bosch, 2004)

  • Key question: is usability an architecturally sensitive quality attribute?



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)



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


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. 2nd 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 15408-1, 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.



Yüklə 470 b.

Dostları ilə paylaş:




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə