Context

The patterns in this chapter deal with the modeling problems connected to deploying a piece of software. These problems are different from design or construction problems the problem domain is typically a set of givens, including physical elements, such as the network architecture of an organization; as well as soft elements, such as the human organizational structure. Even for a commercial software product, both the target platforms and the intent of the out-of-the-box experience need to be factored into the system model that is part of the delivered package.

Models of the physical system have a different level of abstraction and a different audience from analysis or design models. They are more closely tied to user and operational practicalities than to designed concepts. They are more direct, more like a depiction than a representation. They should provide easy-to-grasp pictures and maps; they should be blunt and straightforward; and they should be connected to the needs of users, the values of stakeholders, and the goals of management.

From a programming perspective, components are interesting because of "pluggability," "replaceability," and reuse. From a modeling perspective, components are simpler things: components are what are deployed. They are the atomic elements of executable delivery; the physical reality that is delivered to the end user on processors and devices are called nodesin the UML. They are also the documentation and any other support needed to make the executable solution useful and maintainable.