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