Abstract

Documenting a deployment is confusing. People, when asked to do it, do not know what to include or how to structure it. There are some theories around and they often address the analysis part. The UML deployment diagrams can be used for this. This paper introduces a way to document a deployment in a streamlined way with a common language. The result is an easily used model that provides benefits for the various actors: functional and organic structures can be explicitly discussed and tracked, the structure is useful for configuration management, common understanding and impact analysis. The model and techniques described here have been applied and evaluated on a set of projects by a small team (10 people) and worked well.

Introduction

First of all let's introduce the following figure to facilitate the discussion:

Fig1

This depics what we can call a PLATFORM.

Terminology

Here after, configuration items are defined.

Configuration Items

COMPUTING UNIT

This box depicts a "computing unit", an individual system, something like a PII 400Mhz, 128Mb RAM, HD 4Gb or HP9000 Unix or Sun SparcStation, you got the picture. Multiple CPU may exist inside. The main point is that it is a physical computing unit.

EXTERNAL DEVICE

This little box represents devices connected to a computing unit. This encompasses items like modems, scanners, special interface devices hooked on the serial port (e.g. barcode reader, CTI phone). Those boxes may also represent sensors. External devices may also encompass disk farms, storage robots (e.g. StorageTek). Those devices are usually connected through a communication card (see below).

COMMUNICATION "CARD"

Also known as hardware interface. All kinds of network cards, telephony cards, I/O cards fall in this category. These are the cards that allow the COMPUTING UNIT to talk with the external world. A disk controller is not a communication card, except when it interfaces with an external SCSI disk farm for example. This is left to the user because the disk is part of what is considered a computing unit. This fact comes from a blurred distinction here and are a matter of interpretation. The form factor of the "CARDS" may differ, it may be a ISA, PCMCIA/PCCard, PCI, VME card, a specific card featured for an exotic backplane...

RESOURCE "CARD"

A resource card is a card that performs some kind of special task that elects it to a special distinctive status within the computing unit. Maybe, the resource card was there for a special reason. Such cards may encompass DSP cards and the like.

COMPONENT

This item is the one that has had the most controversial number of definitions. A commonly accepted one today (from the Catalysis methodology) is :
"a coherent package of software that can be independently developed and delivered as a unit, and that defines interfaces by which it can be composed with other components to provide and use services."

So, when going down to the real platform, we are left to the following pieces of SOFTWARE that we can install on a computing unit:

PRODUCT	We see a product as a component produced by a party which is accountable for it, has produced relevant documentation to install and operate it and has build an installation package with a versioning scheme. Examples of this are Microsoft Office, Oracle SQL Client, ...
RUNTIME COMPONENT	An example of this is an ActiveX component
EXECUTABLES	An example of this is WINWORD.EXE and its related dlls. Needless to say, trying to describe the whole system this way is way too extensive. This is a question of scale and relevance. See P.A.R.T.S. for more details.

INTERFACE/CONNECTOR/PORT

The ports are the I/O points provided by components and allow them to be wired together. They allow the components to interact in structured ways across clearly defined interfaces. The Design by Contracts approach is recommended when defining interfaces syntax and semantics.

So here is depicted a component with one interface. Of course, many interfaces may exist for a component.

This little diamond is the symbol for containment. A component may contain another. For example, a library that is linked to a program is such a component. The library is a component in itself and is contained in another component when used. An example of this is component B contains component C in Fig1. A DLL will not be depicted that way because it is not contained in another component. It is loaded on its own and shared by components. Only a memory space is allocated by the component using it. An example of this is component B uses component D (a DLL) but does not contains it in Fig1.

Physical
Link

A Physical links connects one or more computing units together and form the physical "plumbing" of the platform. Ethernet cables, Radio links, ATM segments, Fiber optic cables, switching hubs, routers (but some routers are computing units, adding to the confusion), Satellite links, leased lines, pstn are types of physical links. Network protocols and standards are now present to ease the transport of data between software components through their ports. TCP/IP is one of them, as is CORBA, COM+, Java RMI, APPC, SNA

Logical
Link

A logical link is a connection between two or more components through their ports. A logical link can be asynchronous or synchronous. It can be between components hosted within a single computing unit or between components located within different computing units. Facilitating components enable logical links. Among them we can find middleware components for example (e.g. MQSeries, TUXEDO).

Article - Deployment Diagrams

Abstract

Introduction

Terminology