Notes

Outline

Quality Attributes John D. McGregor Clemson University

What do you like? Think about all of the software systems you use such as mailers, compilers, editors, etc. Make a list. Select the one you like the most.

Why do you like it? Write down why you like this software system. What is it about this system that provides your desired attribute?

Scenarios A scenario is a short story. It is a narrative. It may have a set format or it may be free form. UML use cases use scenarios as part of the description of a use of the system. In fact most use cases have several scenarios: sunny day alternative course failure exceptional Each scenario has a stimulus and a response.

Scenario The user presses the “search” button. The system responds by invoking the search web service passing the contents of the search textbox as a parameter to the search service.

Quality Attributes – some examples Modifiability Performance Productivity Many of these can not be quantified exactly so how do we state them as requirements?

Qualities System qualities secure Business qualities time to market Architectural qualities conceptual integrity

Quality Attribute Scenario Source of stimulus Stimulus Environment Artifact Response Response measure

Performance quality scenario The driver applies the brakes while the car is traveling at 55 mph a signal is sent to the brake controller. The controller activates braking action within 10ms of receiving the signal.

Quality attributes Write a quality attribute scenario for the quality you identified for your favorite system.

System qualities Modifiability Performance Security Usability Maintainability

Availability Percentage of time that the system is available WHEN it is planned that it will be available mean time to failure mean time to failure+mean time to repair

Testability The ability of the system to expose its faults. IF there is a fault, how likely is the fault to be found during testing? Can be enhanced by providing access to the state attributes of each module Make everything public and it is 100% testable but it is not as modifiable

Business Qualities Time to market COTS reuse of components architectures test cases outsourcing

Architectural Qualities Buildability too complex circular dependencies Conceptual Integrity One vision, defended vigorously A small architecture team

Problem The system will include consumers and producers of data Consumers need to maintain the most current data Producers of data keep changing Have other activities the system needs to be doing How should we architect that part of the system?

Possibilities Polling – go looking for new data periodically qualities enhanced: qualities degraded: Broadcasting – every piece of data is sent to every consumer qualities enhanced: qualities degraded: MatchMaker – sources of data are matched with consumers of data qualities enhanced: qualities degraded:

Solution – Publish/Subscribe Producers – publish data to the matchmaker Consumers – subscribe to the services of the matchmaker When a producer publishes a new piece of data to the matchmaker, a notification is sent to all consumers who have subscribed for this “type” of data.

Known use