- Why Evaluate an Architecture?
- 2 When Can an Architecture Be Evaluated?
- 3 Who's Involved?
- 4 What Result Does an Architecture Evaluation Produce?
- 5 For What Qualities Can We Evaluate an Architecture?
- 6 Why Are Quality Attributes Too Vague for Analysis?
- 7 What Are the Outputs of an Architecture Evaluation?
- 8 What Are the Benefits and Costs of Performing an Architecture Evaluation?
- 9 For Further Reading
- 10 Discussion Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
2.6 Why Are Quality Attributes Too Vague for Analysis?
Quality attributes form the basis for architectural evaluation, but simply naming the attributes by themselves is not a sufficient basis on which to judge an architecture for suitability. Often, requirements statements like the following are written:
"The system shall be robust."
"The system shall be highly modifiable."
"The system shall be secure from unauthorized break-in."
"The system shall exhibit acceptable performance."
Without elaboration, each of these statements is subject to interpretation and misunderstanding. What you might think of as robust, your customer might consider barely adequate—or vice versa. Perhaps the system can easily adopt a new database but cannot adapt to a new operating system. Is that system maintainable or not? Perhaps the system uses passwords for security, which prevents a whole class of unauthorized users from breaking in, but has no virus protection mechanisms. Is that system secure from intrusion or not?
The point here is that quality attributes are not absolute quantities; they exist in the context of specific goals. In particular:
A system is modifiable (or not) with respect to a specific kind of change.
A system is secure (or not) with respect to a specific kind of threat.
A system is reliable (or not) with respect to a specific kind of fault occurrence.
A system performs well (or not) with respect to specific performance criteria.
A system is suitable (or not) for a product line with respect to a specific set or range of envisioned products in the product line (that is, with respect to a specific product line scope).
An architecture is buildable (or not) with respect to specific time and budget constraints.
If this doesn't seem reasonable, consider that no system can ever be, for example, completely reliable under all circumstances. (Think power failure, tornado, or disgruntled system operator with a sledgehammer.) Given that, it is incumbent upon the architect to understand under exactly what circumstances the system should be reliable in order to be deemed acceptable.
In a perfect world, the quality requirements for a system would be completely and unambiguously specified in a requirements document. Most of us do not live in such a world. Requirements documents are not written, or are written poorly, or are not finished when it is time to begin the architecture. Also, architectures have goals of their own that are not enumerated in a requirements document for the system: They must be built using resources at hand, they should exhibit conceptual integrity, and so on. And so the first job of an architecture evaluation is to elicit the specific quality goals against which the architecture will be judged.
If all of these goals are specifically, unambiguously articulated, that's wonderful. Otherwise, we ask the stakeholders to help us write them down during an evaluation. The mechanism we use is the scenario. A scenario is a short statement describing an interaction of one of the stakeholders with the system. A user would describe using the system to perform some task; these scenarios would very much resemble use cases in object-oriented parlance. A maintenance stakeholder would describe making a change to the system, such as upgrading the operating system in a particular way or adding a specific new function. A developer's scenario might involve using the architecture to build the system or predict its performance. A customer's scenario might describe the architecture reused for a second product in a product line or might assert that the system is buildable given certain resources.
Each scenario, then, is associated with a particular stakeholder (although different stakeholders might well be interested in the same scenario). Each scenario also addresses a particular quality, but in specific terms. Scenarios are discussed more fully in Chapter 3.