functionality and architecture quality attributes eec 521...

EEC 521Software Engineering

EEC 521: Software Engineering

Quality Attributes


Quality Attributes

• Business considerations determine qualityattributes

• These are over and above functionality

• It’s not enough to build just any functionalsystem


Functionality andArchitecture• Functionality and quality attributes are orthogonal

– I can build a horribly inefficient, correct program

• Purpose of today’s lecture is to think about qualityattributes in a disciplined manner

• Functionality is independent of the structure of thesystem!

– I can build a monolithic program

• The whole idea behind software architecture is to seehow functionality interacts with other qualities


What systems do you Like?

• Think of all the software systems you use (mailprograms, editors, compilers, etc). Make a list.Pick the one you “like” the most.


Why do you like it?

• Write down why you like your favorite system.

• What is it about this system that provides yourdesired attribute?


Some Example Qualities

• Usability

• Modifiability

• Performance

• Productivity

• Many of these cannot be quantified. So how tostate them as requirements?


Some Observations

• Architecture is critical to achieving qualities.

• Architecture by itself cannot achieve qualities.

• In complex systems, qualities can never beachieved in isolation

• Example: Portability requires highly modularsystem, but that hurts performance


Kinds of Qualities

• System qualities. e.g., Secure

• Business qualities. e.g., Time to market

• Architectural qualities e.g., Conceptual integrity


Quality Attribute Scenario

• A scenario is a short story, a narrative. It mayhave a set format or be free form

• A Quality Attribute Scenario has six parts:– Source of stimulus

– Stimulus

– Environment

– Artifact

– Response

– Response measure


Performance QualityScenario


Modifiability Quality Scenario


Quality Attributes

• Write a quality attribute scenario for the qualityyou identified for your favorite system.


Availability

• Concerned with system failure andconsequences.

• We only care about observable failure.

! = Availability

MTTF = mean time to failure

MTTR = mean time to repair


General Quality Scenarios

• System-independent

• Each of the six parts are shown with the rangeof values they can take

• Concrete scenarios can be generated fromgeneral scenario


General Availability Scenario


Sample Availability Scenario


Testability

• The ability of a system to expose its faults.

• IF there is a fault, how likely is the fault to befound during testing?

• Can be enhanced by providing access to thestate attributes of each module.

• Make everything public, and it’s 100% testable!

• But what happens to modifiability?


General Testability Scenario


General ModifiabilityScenario


General PerformanceScenario


General Security Scenario


General Usability Scenario


Business Qualities

• Time to market

• Cost and benefit

• Projected lifetime of system

• Targeted market

• Rollout schedule

• Integration with legacy systems


Architectural Qualities

• Conceptual integrity

– One vision, defended vigorously

• Correctness and Completeness

– Formal evaluation

• Buildability

– How easy is it to build?

functionality and architecture quality attributes eec 521...

Documents