Functionality
Functionality is the ability of
the system to do the work for which it was in-tended. 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
function-ality 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, data-bases, 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.
But
although functionality is independent of any particular structure, functionality
is achieved by assigning responsibilities to architectural elements, re-sulting in one of the most basic
of architectural structures.
Although responsibilities can be
allocated arbitrarily to any modules, soft-ware architecture constrains this allocation when other
quality attributes are important. For example, systems are frequently divided
so that several people can cooperatively build them. The architect’s interest
in functionality is in how it interacts with and constrains other qualities.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.