Architecture Quality Attributes

From Suhrid.net Wiki
Jump to navigationJump to search

Intro

  • Qualities that must be accommodated in a systems architecture over and above basic functionality.
  • Categories of quality attributes:
    • Observable attributes. e.g:
      • Performance
      • Usability
      • Functionality
      • Security
      • Availability
    • Unobservable attributes. e.g:
      • Modifiability
      • Reusability
      • Testability
      • Portability
      • Certifiability
    • Business attributes.e.g:
      • Time to market
      • Overall cost
      • Longevity
      • Backward compatibility

Quality Attribute Scenarios

  • Meaningless to say System is modifiable, reusable etc. How do we justify it ?
  • Quality Attributes are best characterised via scenarios.
  • SEI format for QA scenarios:
    • Source of stimulus: The entity (human, computer system) that has generated the stimulus.
    • Stimulus: The stimulus is a condition that needs to be considered when it arrives at a system.
    • Environment: The prevailing condition when the stimulus occurs (e.g. system may be overloaded when stimulus occurs or maybe the system is in normal operating conditions)
    • Artifact: Some piece of the system is stimulated. This may be the whole system or some pieces of it.
    • Response: The response is the activity undertaken after the arrival of the stimulus.
    • Response Measure: When the response occurs, it should be measurable so that the requirement can be tested.
  • General QA scenarios: These scenarios are system independent and can be applied to any system.
  • Specific QA scenarios: These scenarios are derived from the general scenario by instantiating each part. They are specific to the particular system under consideration.
  • For e.g. there is a general availability scenario with a range of values that each part (source, stimulus, env etc) can take. From this we can derive concrete, system specific scenarios.

Observable Quality Attributes

Availability

  • Availability is concerned with system failure and its associated consequences.
  • A fault may become a failure if not corrected or masked.
  • Availability of a system is the probability that it will be operational when it is needed.
  • Defined as (MTTF)/(MTTF + MTTR). Where MTTF = Mean Time to Failure and MTTR = Mean Time to Repair.

General Scenario

  • Source: Internal or external to the system.
  • Stimulus: The stimulus is a fault. The fault can be omission (fails to respond), crash (repeatedly suffers omission faults), timing (late or early response), response itself (incorrect)
  • Artifact: The part of the system that is required to be highly available (processor, communication channel, storage etc)
  • Environment: Normal/Degraded.
  • Response: One or more of : Logging, Notifying, Disable source of events, become unavailable, continue to operate in normal or degraded mode.
  • Response Measure: Time interval when the system must be available or a repair time.

Performance

General Scenario