The many web pages and books on software architecture have provided dozens, if not hundreds, of definitions of software architecture and related terms. Given this plethora of definitions, we must settle on a set of definitions for the purposes of communicating software architecture concepts. What follows are some key definitions required for a discussion of software architecture.
The Institute of Electrical and Electronic Engineers (IEEE) recently issued a recommended practice regarding Software Architecture: IEEE 1471. The definitions we provide in this book are closely aligned with IEEE 1471. These include definitions of system, stakeholder, architect, architecture, architectural views, and architectural viewpoints. IEEE 1471 defines the following key terms:
* System is a set of components that accomplishes a specific function or set of functions.
* Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution'.
* Architectural Description is a set of products that document the architecture.
* Architectural View is a representation of a particular system or part of a system from a particular perspective.
* Architectural Viewpoint is a template that describes how to create and use an architectural view. A viewpoint includes a name, stakeholders, coucerns addressed by the viewpoint, and the modeling and analytic conventions.
The IEEE definitions are intentionally general, to cover many types of software architecture, and are not specific enough to provide detailed guidance to architects and developers of large-scale systems.
The System Architecture is the set of entities, the properties of those entities, and relationships among them that define the structure of the system. The Software Architecture is the set of software components, subsystems, relationships, interactions, the properties of each of these elements, and the set of guiding principles that together constitute the fundamental properties and constraints of a software system or set of systems.
Software Architecting refers to the analysis, design, documentation, review, approval, and other related activities concerned with the definition and management of the software architecture. Architectural Views provide representations of the architecture that can be used to guide construction, manage, explore, train personnel, test, and perform other engineering tasks related to creation and maintenance of the software system. Some uses for Views include:
* Capturing the design decisions both early on, and as enhancements are made.
* Capturing information about the runtime environment for the software.
* Providing constraints on the lower-level design and implementation
* Providing input to the structure of the development organization
* Designing the system to meet the software reliability, availability, maintainability, and performance requirements
* Facilitating communication among the project teams
* Communicating the software capabilities and constraints to various developers, testers, and others
For each of these views there is a group of associated Stakeholders. The stakeholders may include project and program managers, development team managers and technical leads, system engineers, the test organization, and individual developers.
This group of stakeholders may he building the early versions of the software, or may he making maintenance modifications to software that has existed for some time. The architectural views are used to communicate with the stakeholders and, as such, must be carefully crafted to communicate the appropriate information at the appropriate level of detail to the set of associated stakeholders for that view.
While the definition of software architecture terminology provided above is useful, the definitions are still somewhat fuzzy since some of the terms used in the definitions are not themselves clearly defined. The following will help refine and clarify these definitions:
Architecting software is primarily about software design--design in the large. Thus, the focus of architecture is on the arrangement of the larger aspects of software systems such as subsystems and components rather than classes and objects. To model software systems in the large requires examining both the static or build-time view and the dynamic or runtime behaviours of the software.
Another way of thinking about software architecture is to think about some of the typical questions that can be answered by views of the architecture:
* What are the subsystems or components of the software?
* What are the responsibilities of the components?
* What are the interfaces provided/consumed by these subsystems or components?
* What subsystems or components are impacted by a change to the software?
* How much retesting is required if we change this component?
* What components are involved in installing this change?
* How are parts of the system to he physically distributed?
* How will a change impact the performance of the...