1 / 37

2. Architecture Qualities 2.1 Quality attribute scenarios

2. Architecture Qualities 2.1 Quality attribute scenarios. Notas del Dr. Hector Duran. Quality Attributes. Functionality and quality attributes are orthogonal E.g. the choice of function does not dictate the level of performance or security

spanns
Télécharger la présentation

2. Architecture Qualities 2.1 Quality attribute scenarios

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 2. Architecture Qualities2.1 Quality attribute scenarios Notas del Dr. Hector Duran

  2. Quality Attributes • Functionality and quality attributes are orthogonal • E.g. the choice of function does not dictate the level of performance or security • The functionality of a systems is about what a systems does • The non-functional attributes of a system is about how a system is performed

  3. Quality Attributes (2) • Achieving quality attributes must be considered throughout: • Design • Implementation • Deployment

  4. Quality Attributes (3) • Achievement of an attribute will have an effect (positive or negative) on another attribute • E.g. almost every quality attribute negatively affects performance

  5. Quality Attributes (4) • Quality attribute scenario • Source of stimulus • Stimulus • Environment • Artefact • Response • Response measure

  6. Quality Attributes (5) • System’s quality attribute requirements are seldom extracted and recorded in a disciplined way • Quality attribute scenarios are used to alleviate this situation

  7. 2.2 Quality attributes

  8. Quality Attributes (6) • Availability • Is concerned with system failure and its associated consequences • Areas of concern: • How system failure is detected • How frequently system failure may occur • What happens when the failure occurs • How failures can be prevented • Time it takes to repair

  9. Quality Attributes (7) • Failures vs faults • A fault may become a failure if not corrected or masked • Automatic repair strategies • If the system is able to recover from the fault, there’s no failure

  10. Quality Attributes (8) • Availability general scenarios: • Source of stimulus: internal and external • Stimulus: a fault of the following classes: • Omission.- fails to respond to an input • Crash.- repeatedly suffers from omission faults • Timing.- early or late • Response.- incorrect value

  11. Quality Attributes (9) • Availability general scenarios (2): • Artefact: specifies resource to be highly available e.g. processor, channel, etc • Environment.- state of system when fault or failure occur • Response.- logging the failure, notifying selected users or other systems, switching to a degraded mode, etc • Response measure.- availability percentage, time to repair, etc

  12. Response Measure: No downtime Stimulus: Unanticipated msg Responses: Inform operator Continue to operate Source: External To system Environment: Normal operation Quality Attributes (10) • Availability concrete scenario • An unanticipated external msg is received by a process during normal operation. The process informs the operator of this and continues to operate without downtime.

  13. Quality Attributes (11) • Modifiability • Is about the cost of change • It brings up two concerns: • What can change? • When is the change made and who makes it?

  14. Quality Attributes (12) • Modifiability • What can change? • Most aspects of the system • The functionality • The platform of deployment • Hardware • Operating system • Middleware • The environment within which it operates • The quality attributes • Its capacity

  15. Quality Attributes (13) • Modifiability • When the change is made? Who? • In the past only code was modified by the developer • Now, changes can be made by end user • Changes can be made to the implementation: • Source code • Compile time • Build time • Load time • Run time

  16. Quality Attributes (14) • Modifiability • Making a system modifiable involves: • Specify changes • Design changes • Implement • Test • Deploy

  17. Quality Attributes (15) • Modifiability general scenarios • Source of stimulus.- specify who makes the changes • Stimulus.- specifies nature of the stimulus • Artifact.- specifies what is to be changed • Environment.- specifies when the change can be made • Response.- possible side effects • Response measure.- time and cost to perform the change

  18. Response Measure: In three hours Stimulus: Wishes to Change UI Responses: Modification is Made with no side effects Source: Developer Environment: At design time Quality Attributes (16) • Modifiability concrete scenario • A developer wishes to change the user interface to make a screen’s background colour blue. It will take 3 hours with no side effects

  19. Quality attributes (17) • Performance • Is about responding to events within certain timing constraints • Events • Interrupts • Messages • Requests from the user

  20. Quality attributes (18) • e.g. in a web-based financial system the response might be • the number of transactions that can be processed in a minute • The arrival pattern of events • Periodic • Sporadic • Stochastic

  21. Quality attributes (19) • Measurement categories of the system’s response • Latency • Deadlines in processing • Throughput of the system • Jitter of the response

  22. Quality attributes (20) • Performance general scenarios • Source of stimulus • either from external or internal sources • Stimulus • are event arrivals • Artefact • is always the system’s services • Environment • can be in various operational modes • Response • the arriving events that must be processed • Response measure • is the time it takes to process the arriving events

  23. Response Measure: Stimulus: Responses: Source: Environment: Quality attributes (21) • Performance concrete scenario • Users initiate 1,000 transactions per minute stochastically under normal operations, and these transactions are processed with an average latency of two seconds With average Latency of two seconds Initiate Transactions Transactions are processed Users Under normal operations

  24. Quality attributes (22) • Security • Ability to resist unauthorised usage • An attempt to breach security is called an attack or threat • Unauthorised attempt to access data • Unauthorised attempt to access services • Intend to deny services to legitimate users

  25. Quality attributes (23) • Security • Can be characterised as: • No repudiation • Confidentiality • Integrity • Assurance • Availability • Auditing

  26. Quality attributes (24) • Security general scenarios • Source of stimulus • either a human or another system • Stimulus • is an attack or an attempt to break security • Artefact • the services of the system or the data within it • Environment • either online or offline, either connected to or disconnected from a network, either behind a firewall or open to the network

  27. Quality attributes (25) • Security general scenarios • Response • must authorise legitimate users and grant them access to data and services • Response measure • difficulty of dealing with various attacks • difficulty of recovering from attacks • surviving attacks

  28. Response Measure: Stimulus: Responses: Source: Environment: Quality attributes (26) • Security concrete scenario • A correctly identified individual tries to modify system data from an external site; system maintains an audit trail and the correct data is restored within one day Correct data is Restored Within a day Tries to Modify information System Maintain Audit trail Correctly Identified individual Under normal operations

  29. Quality attributes (27) • Testability • Ease with which software can be made to demonstrate its faults • At least 40% of cost employed by testing • To be properly testable is necessary • To control each component’s internal state and inputs • To observe its outputs

  30. Quality attributes (28) • Testability • Testability general scenarios • Source of stimulus • performed by testers or the client • Stimulus • The completion of some part of the system • Artifact • a design, • piece of code • the whole system • Environment.- the test can happen at • design time • Development time • Compile time • Deployment time

  31. Quality attributes (29) • Testability • Testability general scenarios • Response • the system can be controlled to perform the desired tests • Response measure • the percentage of statements that have been executed in some test • Estimates of the probability of finding additional faults

  32. Response Measure: Stimulus: Responses: Source: Environment: Quality attributes (30) • Testability concrete scenario • A tester performs a unit test on a completed system component that provides an interface for controlling its behaviour and observing its output; 85% path coverage is achieved within three hours Path coverage Of 85% is Achieved Within 3 hours Performs Unit test Component Has interface For controlling Behaviour and Output of the Component is observable Tester At the Completion Of the component

  33. Quality attributes (30) • Usability • How easy it is for the user to accomplish a desired task • Includes facilities for • Learning system features • Using a system efficiently • Minimising the impact of errors • Adapting the system to user needs • Increasing confidence and satisfaction

  34. Quality attributes (31) • Usability general scenarios • Source of stimulus • the end user is always the source of the stimulus • Stimulus.- the user wishes to • use a system efficiently • Learn to use the system • Minimise the impact of errors • Adapt the system • Feel comfortable with the system • Artifact • is always the system

  35. Quality attributes (32) • Usability general scenarios • Environment.- actions occur at • Runtime • System configuration time • Response.- provide the user • The features needed • Anticipates the user’s needs • Response measure.- is measured by • Task time • Number of errors • Number of problems solved • User satisfaction • Gain of user knowledge

  36. Response Measure: Stimulus: Responses: Source: Environment: Quality attributes (33) • Usability concrete scenario • A user, wanting to minimise the impact of an error, wishes to cancel a system operation at runtime; cancellation takes place in less than one second Cancellation Takes Less than One second Minimise Impact of errors Wishes to Cancel Current operations Users At runtime

  37. Quality attributes (34) A Classification and Comparison Framework for Software Architecture Description Languages. Nenan Medvidovic and Richard N. Taylor

More Related