10.3 Visualizing the Whole System

A system is composed of many elements, including subsystems organized into a collaboration to accomplish some purpose. It is an aggregation of constructs joined in some regular interaction. The diagraming techniques discussed in this chapter allow the developer to model a single system from different viewpoints, from different levels, and from different flows of control to assist in the design and development of the system. In this section, we discuss modeling and documenting the system as a whole. This means at the highest level the major components or functional elements can be depicted. The diagraming techniques discussed in this section are the ones used to model the delivered system and the architecture of the system. Although this is the last section in this chapter, modeling and documenting the whole system would be the first level of designing and developing a system.

10.3.1 Visualizing Deployment of Systems

The deployment of a system is the last step in system development. Deployment is the delivery of the system. When a system is to be deployed, you may want to model the actual physical components of the runtime version of your system. A deployment diagram depicts the configuration of runtime processing elements and the software components that execute on them. The software components are actual executable modules such as active objects (processes), libraries, databases, and so on. A deployment diagram consists of nodes and components. The components used in a deployment diagram are runtime entities. Runtime entities are the physical implementations of logical elements. A class is a logical element that may be implemented as one or several components. A class may be divided into processes or threads. Each process or thread can be a component in a deployment diagram. The components of a class may be executed on different nodes on a single machine (threads/processes) or different machines (processes).

A node is represented by a cube. Nodes are connected by dependencies or associations. Components and nodes can be connected by dependencies as well. As discussed earlier, a node can list its components or a component can be depicted separate from a node showing the relationship between them. A component can be represented as a rectangle with tags on the left side. The name of the component is contained inside the symbol.

Components can be grouped together to create larger chunks such as packages or subsystems. Figure 10-18 shows a deployment diagram. In Figure 10-18, the users connect to the system via intranet. The nodes are the part of a cluster of PCs. They are grouped into a package. The user connects to the cluster as a whole. Each node lists the components that reside on them. The communication between nodes is by means of a network node.

Figure 10-18. A deployment diagram using packages.

10.3.2 The Architecture of a System

When modeling and documenting the architecture of a system, the view of the system is at the highest level. Booch, Rumbaugh, and Jacobson define architecture as:

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, together with their behavior as specified in the collaboration among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization ”these elements and their interfaces, their collaborations, and their composition.

Modeling and documenting the architecture will capture the system's logical and physical elements along with the structure and behavior of the system at the highest level.

The architecture of the system is a description of the system from a distinct view that focuses on the structure and organization of the system from that aspect. The views are as follows :

use case	Describes the behavior of the system presented to end users.
process	Describes the processes and threads used in the system's mechanisms of concurrency and synchronization.
design	Describes the services and functions provided to the end user.
implementation	Describes the components used to create the physical system.
deployment	Describes the software components and the nodes on which they are executing in the delivered system.

As you can see, these views overlap and interact with each other. Use cases can be used in the design view. Processes can show up as components in the implementation view. Software components are used in both implementation and deployment views. When designing the architecture of the system, diagrams that reflect each of these views should be constructed .

A system can be decomposed into subsystems and modules. The subsystems or modules will be further broken down into components, nodes, classes, objects, and interfaces. In the UML, subsystems or modules used at the architectural level of documentation are called packages . A package can be used to organize elements into a group that describes the general purpose of those elements. A package is represented as a rectangle with a tab on the upper left corner. The package symbol contains the name of the package. The packages in the system can be connected by means of composition, aggregation, dependency, and associations relationships. Stereotype indicators can be used to distinguish one type of package from another. Figure 10-19 shows the packages involved in the course adviser system. The system package uses a <<system>> indicator to distinguish it from the User Interface Client and Logic Server subsystems, which use the <<subsystem>> indicator. Because they are subsystems, they are related to the system by aggregation relationship.

Figure 10-19. Packages used in the course adviser system.

Packages can contain other packages. If a package contains other packages, then the name of the package is placed in the tab. Figure 10-19 also shows the content of each subsystem.