In their landmark book on the subject, Shaw and Garlan discuss software architecture in the following manner: Ever since the first program...
In their landmark book on the subject, Shaw and Garlan discuss software architecture in the following manner:
Ever since the first program was divided into modules, software systems have had architectures, and programmers have been responsible for the interactions among the modules and the global properties of the assemblage. Historically, architectures have been implicit— accidents of implementation, or legacy systems of the past. Good software developers have often adopted one or several architectural patterns as strategies for system organization, but they use these patterns informally and have no means to make them explicit in the resulting system.
Today, effective software architecture and its explicit representation and design have become dominant themes in software engineering.
What Is Architecture?
When we discuss the architecture of a building, many different attributes come to mind. At the most simplistic level, we consider the overall shape of the physical structure. But in reality, architecture is much more. It is the manner in which the various components of the building are integrated to form a cohesive whole. It is the way in which the building fits into its environment and meshes with other buildings in its vicinity. It is the degree to which the building meets its stated purpose and satisfies the needs of its owner. It is the aesthetic feel of the structure—the visual impact of the building—and the way textures, colors, and materials are combined to create the external facade and the internal “living environment.” It is small details—the design of lighting fixtures, the type of flooring, the placement of wall hangings, the list is almost endless. And finally, it is art.
But what about software architecture? Bass, Clements, and Kazman define this elusive term in the following way:
The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.
The architecture is not the operational software. Rather, it is a representation that enables a software engineer to (1) analyze the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reducing the risks associated with the construction of the software.
This definition emphasizes the role of “software components” in any architectural representation. In the context of architectural design, a software component can be something as simple as a program module, but it can also be extended to include databases and “middleware” that enable the configuration of a network of clients and servers. The properties of components are those characteristics that are necessary to an understanding of how the components interact with other components. At the architectural level, internal properties (e.g., details of an algorithm) are not specified.
The relationships between components can be as simple as a procedure call from one module to another or as complex as a database access protocol. Architectural design focuses on the representation of the structure of software components, their properties, and interactions.
Why Is Architecture Important?
In a book dedicated to software architecture, Bass and his colleagues identify three key reasons that software architecture is important:
• Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer- based system.
• The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.
• Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” .
The architectural design model and the architectural patterns contained within it are transferrable. That is, architecture styles and patterns can be applied to the design of other systems and represent a set of abstractions that enable software engineers to describe architecture in predictable ways.
