Chapter 1
Software Architecture Basics
In This Chapter
Understanding the basics of software architecture
Considering your software development style
The term software architecture means different things to different people. To the developer, it means the structure of the system being built. To the framework developer, it’s the shape of the system that is created with the framework. To the tester, it’s the shape of what needs to be tested. For all concerned, it’s the high-level structure of the solution to a problem that the customer or client wants solved.
In this chapter, I explain the basics of software architecture — what it is and how you get started. Knowing the problem that you’re solving and the important requirements of the system are also very important, and I help you get going with these tasks in this chapter. In Chapter 4, I explain how software patterns fit into the picture.
Understanding Software Architecture
Every system has an architecture — some high-level structure that underlies the whole system. Software architecture is how the pieces fit together to build the solution to some business or technical need that your customer or client wants solved. The architecture has a purpose.
The decisions made during the creation of the architecture are truly fundamental to the system because they set the stage for all the other decisions that will come later.
Some systems’ architectures are best described as a Big Ball of Mud (see Chapter 2). These systems are hard to build and hard to maintain, and they may not meet the customer’s needs. Tackling the development of a software system with good software architecture will lead to a more successful result.
To an unsophisticated customer or client,
software architecture is a meaningless term, so don’t get hung up trying to explain how wonderful your architecture is. The customer wants the finished product that solves the problem at hand, not a description of the software that you’ll build to solve it. (For more information on explaining software architecture to others, see Chapter 3.)
Components of software architecture
The software architecture provides the high-level view of the system you’re building and must cover the following aspects:
Goals and philosophy of the system: The architecture explains the goals and describes the purpose of the system, as well as who uses it and what problem it solves.
Architectural assumptions and dependencies: The architecture explains the assumption made about the environment and about the system itself. The architecture also explains any dependencies on other systems or on the builders of the system.
Architecturally significant requirements: The architecture points to the most significant requirements that shaped it.
Packaging instructions for subsystems and components: The architecture explains how the parts of the system are deployed on computing platforms and how the parts must be combined for proper functioning. The subsystems and components are the building blocks of the architecture.
Critical subsystems and layers: The architecture explains the different views and parts of the system and how they relate. It also explains the most critical subsystems in detail.
References to architecturally significant design elements: The architecture describes the most prominent and significant parts of the design.
Critical system interfaces: The architecture describes the interfaces of the system, with special attention to the interfaces that are critical to meet the system’s requirements.
Key scenarios that describe critical behavior of the system: The architecture explains the most important scenarios that illustrate and explain how the system will be used.
Architecture document
All the components in the preceding section go into an architecture document, which contains the information needed to interpret the architecture. The document includes assumptions, key decisions that shaped the architecture, how the parts of the architecture work together, and how the system will be packaged. I tell you more about the architecture document in Chapter 3.
Architecture models (views)
The software architecture has several audiences, including fellow architects, programmers, configuration managers, testers, and customers. All are interested in different information, and all look for different things within the architecture. To make your architecture useful to all these audiences, divide the architectural description into ...
