You can divide software architecture structures into 3 groups: 1) module structures, 2) component-and-connector structures, and 3) allocation structures. These 3 groups map to 3 broad types of decisions for architectural design. The 3 broad types of decisions are: 1) how to structure modules, 2) how to structure components and connectors, and 3) how does the system relate to non-software structures. In Software Architecture in Practice (2nd Edition) (SEI Series in Software Engineering)
Structure and View
Bass, Klements and Kazman write that a view is a coherent representation of a set of elements, while the structure is the set of elements itself:
We will be using the related terms structure and view when discussing architecture representations. A view is a representation of a coherent set of architectural elements, as written by and read by system stakeholders. It consists of a representation of a set of elements and the relations among them. A structure is the set of elements itself, as they exist in software or hardware. For example, a module structure is the set of the system’s modules and their organization. A module view is the representation of the structure, as documented by and used by some system stakeholders. These terms are often used interchangeably, but we will adhere to these definitions.
Module Structures, Component-and-Connector Structures, Allocation Structures
Bass, Klements, and Kazman write that architectural structures can be divided into three groups, depending on the broad nature of the elements they show:
- Module Structures. Here the elements are modules, which are units of implementation. Modules represent a code-based way of consdering the system. They are assigned areas of functional responsibility. There is less emphasis on how the resulting software manifests itself at runtime. Module structures allow us to answer questions such as What is the primary functional responsibility assigned to each module? What other software elements is a module allowed to use? What other software does it actually use? What modules are related to other modules by generalization or specialization (i.e. inheritance) relationships?
- Component-and-connector structures. Here the elements are runtime components (which are the principal units of computation) and connectors (which are the communication vehicles among components). Component-and-connector structures help answer questions such as What are the major executing components and how do they interact? What are the major shared data stores? Which part of the system are replicated? How does data progress through the system? What parts of the system can run in parallel? How can the system’s structure change as it executes?
- Allocation structures. Allocation structures show the relationship between the software elements and the elements in one or more external environments in which the software is created and executed. They answer questions such as What processor does each software element execute on? In what files is each element stored during development, testing, and system building? What is the assignment of software elements to develoment teams?
3 Broad Types of Decisions for Architecture Design
According to Bass, Klements, and Kazman, these three software structures correspond to the three broad types of decisions that architectural design involves:
- How is the system to be structured as a set of code units (modules)?
- How is the system to be structured as a set of elements that have runtime behavior (components) and interactions (connectors)?
- How is the system to relate to nonsoftware structures in its environment? (ie. CPUs, file systems, networks, development teams, etc.)?
Key Take Aways
Here’s my key take aways:
- A view is a coherent representation of a set of elements, while the structure is the set of elements itself.
- You group architectural elements into 3 buckets: 1) module structures, 2) component-and-connector structures, and 3) allocation structures.
- These 3 groups map to 3 broad types of decisions for architectural design: 1) how to structure modules, 2) how to structure components and connectors, and 3) how does the system relate to non-software structures.
My Related Posts
Better Work Breakdown Structures: Make a List of the Jobs to Be Done