Chapter 3: Quality Attributes in Software Design

Welcome to Last Minute Lecture.

This free chapter overview is designed to help students review and understand key concepts.

These summaries supplement not replaced the original textbook and may not be redistributed or resold.

For complete coverage, always consult the official text.

Welcome to the Deep Dive.

We're tackling a core concept today, something that really separates, you know, good architecture from truly great architecture.

If you've ever wondered why these big complex systems get replaced,

well, here's a counterintuitive truth.

It's almost never because they stop doing their basic job.

Exactly.

That's spot on.

The replacement system, it often does the exact same things as the old one.

Yeah, systems usually get retired because, well, they've become too difficult to maintain, maybe too slow to scale up, or increasingly, they've got security holes you can drive a truck through.

And this focus, this kind of short -sighted view on just what the system does rather than how well it does it, that's precisely why software architecture is so critical.

So our mission today is to dive deep into building that resilience.

We're using chapter three of software architecture in practice as our guide, focusing on understanding quality attributes.

We're really figuring out how architects move beyond just the basic functions to build systems that, you know, actually last.

And to do that, we need a really crisp definition first.

So a quality attribute or QA is basically a measurable or testable property of a system.

It defines the system's utility, its value along some dimension that people care about, like speed or how easy it is to modify things beyond the basic features it provides.

Perfect.

So think of this deep dive like a roadmap for you listening.

We're going to hit three critical things.

First, how you actually express these qualities properly.

Yeah, that's key.

Second, the architectural techniques, the tricks of the trade used to achieve them.

And finally, how architects analyze and actually make design decisions about those qualities.

Sound good.

Sounds great.

Let's get started.

Okay.

So the relationship between function and structure, that's really where this whole architecture conversation kicks off.

Yeah.

Functionality, what the system does, it's obviously critical, but here's the thing.

It doesn't actually determine the architecture.

That's the absolute core insight.

Yeah.

If functionality was the only thing that mattered, you could theoretically just code the entire system as one giant monolithic blob.

Chuckles slightly.

Right.

And functionally, it would work.

You know, every task required would execute, but that structureless mess, it would fail instantly on every other important dimension.

Like what?

Well, you couldn't scale it effectively, you couldn't secure parts of it differently, and forget about bringing a new developer on board and saying, hey, just quickly change that one thing.

Impossible.

So the architecture then, it emerges out of necessity.

Exactly.

It's the structure, the breakdown into modules, layers, components, whatever, that's necessary to support those other purposes.

Those are the quality attributes.

Okay.

We assign responsibilities to those different pieces so we can manage the complexity and actually achieve things like high performance or make it easier to modify later on.

Right.

So even though functionality itself isn't dependent on structure,

it is achieved by assigning those responsibilities to the structured elements.

Precisely.

And speaking of functionality, the book makes a point about terminology here.

It really pushes for using the term responsibility instead of functional requirement, especially when you need precision.

Okay.

I gotta ask.

That sounds a little bit, well, academic on the surface.

Why the insistence?

We all kind of know what a functional requirement is, don't we?

Well, yes and no.

The thing is, responsibility is more actionable from an architectural standpoint.

Function can be a bit slippery.

How so?

When you're doing analysis, you need that precision.

You can ask, what are the security constraints on this specific component's responsibility?

Or maybe what kinds of modifications are we expecting for this set of responsibilities?

Oh, I see.

If you just talk about functionality in general, the scope is often way too broad.

Focusing on specific responsibilities lets you attach those quality attributes like security or modifiability to something really concrete.

Got it.

So the QA is like an annotation.

It describes the utility attached to a specific functional responsibility.

Exactly.

So if the system's job, its responsibility is processing a payment.

Yeah.

The QAs describe how well that happens.

Performance dictates the speed.

Security tells you about encryption.

Availability sets the acceptable downtime.

They're really tied together.

They are inseparable.

So now that we agree they're critical, we have to talk about actually specifying them.

And historically, this has been, well,

a bit of a mess.

Oh, how so?

Mainly due to three big problems that kept cropping up.

Okay, lay them on us.

Problem one, untestable definitions.

You know, you couldn't just tell an architect, make the system secure.

Right.

Secure how?

Against what?

Exactly.

Or make it modifiable.

Modifiable for what kind of change and how quickly does that change need to happen, that kind of language.

It's basically useless when you're trying to build something concrete.

Okay, that makes sense.

What was number two?

Number two was overlapping issues.

The book uses the denial of service attack example, which I think is perfect.

Yeah.

Is that a performance problem because it slows everything down?

Is it a security problem because it's, well, an attack?

Or is it an availability problem because users can't access the system?

Everyone wants to claim it.

Right.

Everyone claimed ownership performance people, security people, availability people, but nobody was designing against a single clear agreed upon requirement.

It led to confusion.

And the third problem.

Just different vocabularies.

Different communities use different words for basically the same kind of event.

Performance folks might talk about events, security people about attacks, reliability engineers about faults.

Same stimulus, different labels.

Confusing.

Very.

So the structure that emerged to solve all three of those problems to give us common, testable, and unambiguous definitions is the quality attribute scenario or QAS.

This is probably the single most important tool we have for defining these quality expectations clearly.

And it's a six part structure, right?

That's what turns a vague idea like make it secure into something you can actually measure and test.

Exactly.

Should we walk through the six parts?

Maybe use an example like defining a security requirement against unauthorized data access.

Yeah, let's do it.

What's part one?

Part one is the stimulus.

This is the event that arrives at the system.

In our security example, it's the unauthorized query itself trying to get data it shouldn't.

Okay.

Stimulus.

Got it.

Part two.

Stimulus source.

Where does that query come from?

This is huge.

Is it say a known employee accidentally trying to access salary data they're not cleared for?

Or is it an unknown external hacker using some known vulnerability?

The way the architecture needs to respond is completely different depending on the source.

Right.

Context maps.

Yeah.

Which leads to part three.

The environment.

Under what conditions does the stimulus arrive?

Is the system just running normally?

Is it under heavy load, maybe during a specific maintenance window?

Or, and this is crucial for development qualities, the environment could even be something like after the code base has been frozen for a production release.

Ah, interesting.

Okay.

Environment.

Part four.

The artifact.

What specifically is the target of the stimulus?

Is the hacker going after the entire web server?

Or a specific user database?

Or maybe just one configuration file?

You have to be precise.

Target, artifact.

Makes sense.

Number five.

The response.

What does the system actually do when the stimulus occurs?

For our security example, it might need to detect the unauthorized query, log the attempt, maybe isolate the component under attack, and then send an alert to the security operations team.

Okay.

The action taken.

And finally, the most important part.

Arguably, yes.

Part six.

The response measure.

This is how we test whether the response was adequate.

It absolutely must be quantifiable.

Give me an example for the security scenario.

Okay.

For security, a response measure might be fewer than a thousand sensitive records are exposed.

Or maybe the intrusion attempt is detected and blocked within 50 milliseconds.

Without that measurable part, the whole scenario is still just wishful thinking.

Okay.

So stimulus, source,

environment, artifact, response, and response measure.

That QAS structure really forces clarity.

It really does.

It takes you from these fuzzy concepts to concrete requirements that an architect could actually design against and a tester can verify.

And this works for all kinds of qualities.

Yep.

It applies equally well to runtime QAs, things you observe when the system is running, like availability and performance and developing QAs, things related to building and evolving the system, like modifiability and testability.

But it's never that simple, is it?

The moment you try to improve one quality.

Oh, here it comes.

You almost always negatively impact another one.

It's the eternal truth of architecture, the trade off.

Absolutely.

The classic example, you decide to introduce extra layers of abstraction to make the system more portable across different platforms.

Great for portability,

but those extra layers add processing overhead every time data passes through them, which inevitably hurts performance.

Architecture is fundamentally the art or maybe the science of negotiating these conflicting demands.

Okay.

So we know how to specify qualities using QAS and we know about trade -offs.

How do architects actually build systems to meet these requirements?

What are the sort of design tools?

We primarily talk about two kinds of design primitives, tactics and patterns.

Tactics and patterns.

Let's break those down.

What's a tactic?

A tactic is a very specific kind of surgical design decision.

It directly influences how a quality attribute responds to a particular stimulus.

Think of it like a single move or technique.

Like what?

Give me an example.

Okay.

Maybe using a specific algorithm for resource scheduling to improve performance under load or implementing a heartbeat monitor to detect component failures for availability.

It's a focused design choice targeting a specific QA response.

Got it.

So how is that different from an architectural pattern?

An architectural pattern is much broader.

It's a well understood proven solution to a common recurring design problem.

Think layered architecture or microservices or a broker pattern.

The key difference is that a pattern is essentially a recognized bundle of multiple tactics that work together.

Patterns inherently manage the quality attribute trade -offs that arise when you're trying to solve a bigger, more complex design challenge.

The patterns package up tactics.

In a way, yes.

They represent common combinations of tactics that have proven effective for certain kinds of problems and QA goals.

Before we go deeper into tactics, we need to address something slightly depressing maybe.

Yeah.

The reality of how systems evolve over time.

Ah, yes.

The death by a thousand cuts, as the book puts it.

Exactly.

Architectures don't usually fail spectacularly overnight.

They tend to erode.

That's right.

Developers often under intense time pressure make small suboptimal decisions.

They take shortcuts, maybe ignore established patterns, introduce tight couplings where there shouldn't be any.

And this slow decay, this accumulation of small compromises has an aim, right?

It does.

It's formalized as architecture debt.

It's the ongoing erosion of the system's integrity and its ability to meet those quality attributes over time.

Usually because of decisions focused purely on immediate feature delivery.

So if architecture debt is the problem, what's the solution or at least the countermeasure?

The essential counter tactic here is refactoring.

And we're not just talking about cleaning up code or renaming variables, though that's part of it.

Architecturally, refactoring is used specifically to restore or improve quality attributes that have degraded.

You might refactor to improve security by physically separating modules that handle sensitive data.

Or you might refactor to improve modifiability by identifying functionality that's been duplicated across different parts of the system and factoring it out into a shared service or library.

It's about actively paying down that architecture debt.

OK, that makes sense.

But back to tactics and patterns, you said patterns bundle tactics.

So why focus so much energy on understanding individual tactics if proven patterns already exist?

That's a really good question.

If I can just pick the layered pattern, why do I need to sweat the details of the individual tactics it uses?

Yeah, exactly.

There are a few key reasons.

First,

patterns are almost never a perfect off -the -shelf fit for your specific context.

You'll likely need to adapt or augment them.

Understanding the underlying tactics gives you a systematic way to do that.

Maybe you need a layered pattern, but with unusually high performance requirements in one layer.

Knowing performance tactics helps you modify the pattern appropriately.

OK, so for customization, what else?

Second, sometimes there just isn't a well -known pattern that fits your unique problem space.

In those cases, tactics provide the building blocks.

They allow architects to construct new design solutions from sort of first principles.

Right, you build up from the basics.

Exactly.

And the third reason, which ties into analysis later, is that focusing on tactics makes the whole design and analysis process more systematic and repeatable.

And the book mentions something called super tactics.

That sounds intriguing.

Yeah, it's in the idea.

These are fundamental design moves, like basic principles that seem to pop up everywhere, across almost every architectural pattern, and helping with multiple quality attributes.

Like what kind of moves?

Things like encapsulation, hiding implementation details,

or restricting dependencies, making sure modules don't know too much about each other.

Or using an intermediary, putting something in the middle to manage interactions.

Can you give an example?

Sure.

Think about a load balancer.

It's an intermediary, right?

It sits between clients and servers.

And what tactic does it implement?

Usually some form of resource scheduling or dispatching to improve performance and availability.

These super tactics are like the fundamental reusable atoms of architectural design.

Okay, this is clicking.

Tactics are the individual moves, patterns bundle them, and super tactics are the really common fundamental moves.

You got it.

Which brings us neatly to our last segment.

How do we analyze these decisions?

Because you can't wait until the system is fully built to figure out if you met your performance or security goals.

Right.

That's way too late.

We need tools for earlier assessment.

And one really powerful, yet relatively lightweight tool the book introduces is the tactics -based questionnaire.

A questionnaire.

Sounds simple.

It is simple in structure, but highly effective.

It basically forces the architect, or maybe an analyst reviewing the design, to systematically consider the known tactics relevant to a specific quality attribute, say, availability.

How does that help?

It forces you to step back from the nitty -gritty code details and look at the bigger picture through the lens of established good practices.

The tactics.

Are we employing the right techniques to achieve our availability goals?

Are we missing something obvious?

Okay.

How does it work in practice?

The process is straightforward.

It usually takes maybe 30 minutes to an hour and a half per quality attribute.

The analyst goes through a list of relevant tactics and answers four key questions for each one.

Four questions.

What are they?

First, is this tactic actually supported in the current design?

Simple yes or no.

Second, if yes, describe the design decision and location.

Where exactly is this tactic implemented?

Is it in custom code?

Is it handled by a specific framework we're using?

This documentation is vital for traceability later.

Right.

Proving you actually did it.

What's third?

Third is where the analysis really bites.

Assign a risk level high, medium, or low associated with using this tactic.

Or perhaps more importantly, associated with not using it if the answer to question one was no.

Ah, highlighting potential weak spots.

Exactly.

And the fourth step ties it all together.

The rationale.

Why was this decision made?

You just have to document the reasoning.

Why did we choose this specific implementation of the tactic?

Or if we didn't use a recommended tactic, why not?

And crucially, what are the implications for cost, schedule, or the system's future evolution?

This is where those trade -offs we talked about become really explicit and document.

Give a quick example.

Sure.

Let's say we're looking at availability tactics and one tactic is data replication.

Maybe the answer to support it is no.

Then for risk, the analysts might put high because data loss is unacceptable.

And for the rationale, they might write.

Replication was considered but rejected because initial estimates showed it would increase monthly hosting costs by 30 % exceeding the project budget.

The stakeholders have formally accepted the risk of data loss during the weekly one -hour scheduled maintenance window based on the current business continuity plan.

Wow.

Okay.

So even though it's simple,

that structure forces you to confront the choices and their consequences.

Precisely.

It provides immediate verifiable insight into the architecture strengths and just as importantly, it's known conscious weaknesses and the reasons behind them.

It ensures quality attributes are being addressed deliberately, not just by accident.

That's really powerful.

It prevents the architects from just stumbling into a design without thinking through the quality implications.

Absolutely.

So maybe let's try to wrap this up.

The core lesson here really is that functional requirements, they're satisfied by defining the right set of responsibilities for the system's parts but quality attribute requirements, the how well aspects, those are satisfied by the system's structure and behaviors.

That's the architecture itself.

We capture those complex QA requirements using that six -part tool.

The quality attribute scenario.

Stimulus, source, environment,

artifact, response, response measure.

That's how we make them concrete and testable.

And then to actually build the architecture to meet those scenarios, architects use specific design decisions.

Called tactics.

And these tactics often get bundled together into reusable proven solutions called architectural patterns.

Nicely summarized.

So as you, our listener, move forward thinking like an architect, there's one final thing to keep in mind.

It's a great anecdote from the book.

Oh, yeah.

It involves architects at Lawrence Livermore National Laboratory.

They were designing this incredibly critical, highly secure system.

They spent ages discussing performance, modifiability, all the usual suspects.

But they completely ignored external security threats.

That seems like a massive oversight for a critical system.

Well, when someone finally asked them why they hadn't implemented all these sophisticated digital security measures against external attacks,

their answer was brilliantly simple.

What did they say?

Basically said, we don't need to worry about that in the software.

How come?

Because, they explained, our systems aren't connected to any external network and the entire building is surrounded by multiple layers of physical security, including fences and armed guards.

Ah, the context.

Exactly.

And that brings us to our final provocative thought for you.

You absolutely must consider the broader system context, the physical environment, the organizational processes, the people involved to figure out which quality attributes are truly the software architect's responsibility and which ones are actually being handled elsewhere in the overall system.

That's a fantastic point.

Your design responsibility doesn't exist in a vacuum.

You need to know where it begins and, crucially, where it ends based on that wider context.

Think critically about that boundary.

Well, thank you for joining us for this deep dive into quality attributes.

We hope this structure helps you define, design, and build truly lasting, resilient systems.

Yeah, thanks for listening.

Catch you next time.