1.4 What Do We Mean by Architecture?

In the ROPES process (described later in this chapter) architecture is defined as the set of strategic design decisions that affect the structure, behavior, or functionality of the system as a whole. The ROPES process goes on to discuss five primary aspects of architecture:

Subsystem/Component Architecture The large-scale pieces of the system that can be done prior to the decomposition of the system into hardware and software aspects, or may refer to the large-scale software pieces, as appropriate for the project.
Resource and Concurrency Architecture The identification of the concurrent tasks, how the primitive semantic objects map into those threads, the scheduling policies, and policies for synchronization and resource management. Note that in the UML, the primary unit of concurrency is the «active» object, which creates and owns the thread in which it executes. Note also that this is primarily a software architecture concern and has a relatively minor impact on system engineering and hardware architectures. However, it does impact the selection of processors and connection media such as networks and busses.
Distribution Architecture The identification of how objects map into different address spaces, and how they will communicate across those address space boundaries, including distribution patterns (such as Publish/Subscribe, Broker, etc.) and communication protocols.
Safety and Reliability Architecture The specification of how faults will be identified, isolated, and managed during runtime. This typically includes the redundant architectural substructures and their management in the event of faults.
Deployment Architecture The specification of how the different architectural aspects relate to each other, specifically the software, mechanical, electronic, and chemical aspects. This can be done asymmetrically, where each piece of software is assigned at design time to run on a particular hardware target, or symmetrically where runtime locale decisions are made dynamically at runtime to permit load-balancing.

We call these architectural aspects because there is a single system that in fact contains all of these. Therefore the system model must likewise have an architecture that contains all of these different aspects in a coherent and consistent way. Systems engineers are responsible for the subsystem and component architecture, the safety and reliability architecture, and the deployment architecture. They also may heavily influence, although not completely design, the other architectural aspects distribution and concurrency and resource architectures. Software engineers may be responsible for the subsystem and component architectures for the software, most of the concurrency and resource management architecture, and parts of the distribution, deployment, and safety and reliability architectures. In the next chapter, we'll talk about how to represent these different architectural views using the UML.