Architecture

Visualizing, specifying, constructing and documenting a software-intensive system demands that the system be viewed from a number of perspectives. Different stakeholders like end users, analysts, developers, system integrators, testers, technical writers and project managers each looks at the system in different ways at different times over the project’s life. A system’s architecture is perhaps the most important artifact that can be used to manage these different viewpoints and so control the iterative and incremental development of a system throughout its life cycle.

Architecture is the set of significant decisions about:

• The organization of a software system
• The selection of the structural elements and their interfaces by which the system is composed
•  Their behavior, as specified in the collaborations among those elements
• The composition of these structural and behavioral elements into progressively larger sub systems
• The architectural style that guides this organization: the static and dynamic elements and their interfaces, their collaborations and their composition

As the below figure illustrates, the architecture of a software-intensive system can best be described by five interlocking views. Each view is a projection into the organization and structure of the system, focused on a particular aspect of the system.

 

The use case view of a system encompasses the use cases that describe the behavior of the system as seen by its end users, analysts and testers. With UML, the static aspects of this view are captured in use case diagrams and the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams and activity diagrams.

The design view of a system encompasses the classes, interfaces and collaborations that form the vocabulary of the problem and its solution. With UML, the static aspects of this view are captured in class diagrams and object diagrams while the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams and activity diagrams.

The process view of a system encompasses the threads and processes that form the system’s concurrency and synchronization mechanisms. With UML, the static and dynamic aspects of this view are captured in the same kinds of diagrams as for the design view, but with a focus on the active classes that represent these threads and processes.

The implementation view of a system encompasses the components and files that are used to assemble and release the physical system. With UML, the static aspects of this view are captured in component diagrams and the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams and activity diagrams.

The deployment view of a system encompasses the nodes that form the system’s hardware topology on which the system executes. With UML, the static aspects of this view are captured in deployment diagrams and the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams and activity diagrams.

Each of these five views can stand alone so that different stakeholders can focus on the issues of the system’s architecture that most concern them. The UML permits us to express every one of these five views and their interactions.