| This book is intended to be a practical guide. Our goal is to be brief. We cover only the essential information to guide software architects in defining the software architecture, providing pointers to further reading in lieu of detailed descriptions of this literature. Ideally, we can help software development teams avoid the common practice of capturing the architecture after the software has been developed instead of utilizing the architecture as a tool to guide the software development.
The Unified Modeling Language (UML) is used throughout this book. We reduce the myriad of UML constructs to a precious few that we have found to be most useful. Leveraging the recent IEEE 1471 standard for software intensive systems, we describe several architectural viewpoints that are helpful in the development and documentation of software architectures. After reading this book, you will understand these viewpoints and techniques that will improve the modeling of your system’s software architecture.
The focus of this book will be the software architecture of large-scale systems. Typically, this means enterprise systems and large distributed systems. However, most of the viewpoints and techniques discussed here will apply to smaller projects and embedded systems. A typical large-scale software project will include:
- Large quantities of source code (typically millions of lines)
- Large numbers of developers (potentially hundreds, often geographically distributed)
- High complexity of interaction between components
- Extensive use of off-the-shelf components
- Multiple programming languages
- Multiple persistence mechanisms (files, relational databases, object databases)
- Multiple hardware platforms
- Distribution of components over several hardware platforms
- High concurrency
Dealing with the complexity of large-scale systems can be a challenge for even the most experienced software designers and developers. Large software systems contain millions of elements, which interact to achieve the system functionality. The interaction of these elements is far from obvious, especially given the artifacts created for a typical software project. These artifacts are especially critical as new team members are added and at different phases of the project. These phases include development, integration, testing and maintenance of the system. Even more challenging, however, these elements must be understood and modified as the required functionality of the system evolves. To do this correctly requires an understanding of how the elements interact as well as the underlying principles of the design.
This book does not purport to describe the best or only way to represent software architecture. Some systems may require additional representations from the ones shown in this book, and others may require only a subset of those shown here. However, most software development projects could benefit from at least some of the techniques and architecture representations described here. |
|
