24-01-2013, 10:06 AM
Software Architecture in Practice
1Software Architecture.pdf (Size: 821.5 KB / Downloads: 50)
INTRODUCTION
We have structured this book into five distinct portions. Part One introduces
architecture and the various contextual lenses through which it could be viewed.
These are the following:
Technical. What technical role does the software architecture play in the
system or systems of which it’s a part?
Project. How does a software architecture relate to the other phases of a
software development life cycle?
Business. How does the presence of a software architecture affect an
organization’s business environment?
Professional. What is the role of a software architect in an organization or a
development project?
Part Two is focused on technical background. Part Two describes how
decisions are made. Decisions are based on the desired quality attributes for a
system, and Chapters 5–11 describe seven different quality attributes and the
techniques used to achieve them. The seven are availability, interoperability,
maintainability, performance, security, testability, and usability. Chapter 12
tells you how to add other quality attributes to our seven, Chapter 13 discusses
patterns and tactics, and Chapter 14 discusses the various types of modeling and
analysis that are possible.
Part Three is devoted to how a software architecture is related to the other
portions of the life cycle. Of special note is how architecture can be used in Agile
projects. We discuss individually other aspects of the life cycle: requirements,
design, implementation and testing, recovery and conformance, and evaluation.
Part Four deals with the business of architecting from an economic
perspective, from an organizational perspective, and from the perspective of
constructing a series of similar systems.
Architecture and Requirements
Requirements for a system come in a variety of forms: textual requirements,
mockups, existing systems, use cases, user stories, and more. Chapter 16 discusses
the concept of an architecturally significant requirement, the role such requirements
play in architecture, and how to identify them. No matter the source,
all requirements encompass the following categories:
1. Functional requirements. These requirements state what the system must
do, and how it must behave or react to runtime stimuli.
2. Quality attribute requirements. These requirements are qualifications of
the functional requirements or of the overall product. A qualification of a
functional requirement is an item such as how fast the function must be
performed, or how resilient it must be to erroneous input. A qualification
of the overall product is an item such as the time to deploy the product or a
limitation on operational costs.
Functionality
Functionality is the ability of the system to do the work for which it was intended.
Of all of the requirements, functionality has the strangest relationship to
architecture.
First of all, functionality does not determine architecture. That is, given a
set of required functionality, there is no end to the architectures you could create
to satisfy that functionality. At the very least, you could divide up the functionality
in any number of ways and assign the subpieces to different architectural
elements.
In fact, if functionality were the only thing that mattered, you wouldn’t have
to divide the system into pieces at all; a single monolithic blob with no internal
structure would do just fine. Instead, we design our systems as structured sets
of cooperating architectural elements—modules, layers, classes, services, databases,
apps, threads, peers, tiers, and on and on—to make them understandable
and to support a variety of other purposes. Those “other purposes” are the other
quality attributes that we’ll turn our attention to in the remaining sections of this
chapter, and the remaining chapters of Part II.
Specifying Quality Attribute Requirements
A quality attribute requirement should be unambiguous and testable. We use a
common form to specify all quality attribute requirements. This has the advantage
of emphasizing the commonalities among all quality attributes. It has the disadvantage
of occasionally being a force-fit for some aspects of quality attributes.
Our common form for quality attribute expression has these parts:
Stimulus. We use the term “stimulus” to describe an event arriving at the
system. The stimulus can be an event to the performance community, a
user operation to the usability community, or an attack to the security
community. We use the same term to describe a motivating action for developmental
qualities. Thus, a stimulus for modifiability is a request for
a modification; a stimulus for testability is the completion of a phase of
development.
Stimulus source. A stimulus must have a source—it must come from somewhere.
The source of the stimulus may affect how it is treated by the system.
A request from a trusted user will not undergo the same scrutiny as a
request by an untrusted user.
Response. How the system should respond to the stimulus must also be
specified. The response consists of the responsibilities that the system
(for runtime qualities) or the developers (for development-time qualities)
should perform in response to the stimulus. For example, in a performance
scenario, an event arrives (the stimulus) and the system should process
that event and generate a response. In a modifiability scenario, a request
for a modification arrives (the stimulus) and the developers should implement
the modification—without side effects—and then test and deploy the
modification.