UML Structural

Models

UML Structural Diagrams depict the elements of a system

that are independent of time and that convey the concepts

of a system and how they relate to each other. The

elements in these diagrams resemble the nouns in a

natural language and the relationships that connect them

always show structural or semantic relationships. For

example, a structural diagram of a vehicle reservation

system might contain elements such as Car, Reservation,

Drivers Licence and Credit Card, and contain connectors

linking these elements. Experienced modelers will also

show the relationships to behavioral elements on these

diagrams.

The UML defines seven types of UML structural diagrams.

Class Diagram

The Class diagram captures the logical structure of the

system - the Classes - and things that make up the model.

It is a static model, describing what exists and what

attributes and behavior it has, rather than how something is

done. On a Class diagram you can illustrate relationships

between Classes and Interfaces using Generalizations,

Aggregations and Associations, which are valuable in

reflecting inheritance, composition or usage, and

connections respectively.
Example Diagram

In this example Class diagram, there are two forms of the

Aggregation relationship:

The pale form indicates that the Class Account uses

AddressBook, but does not necessarily contain

AddressBook

The dark Composite Aggregation form indicates

ownership or containment by the target Classes (at the

diamond end) of the source Classes

Composite

Structure Diagram

A Composite Structure diagram reflects the internal

collaboration of Classes, Interfaces or Components (and

their properties) to describe a functionality. Composite

Structure diagrams are similar to Class diagrams, but whilst

Class diagrams model a static view of Class structures,

including their attributes and behaviors, Composite

Structure diagrams model a specific usage of the structure.

You can use them to express run-time architectures, usage

patterns and the participating elements' relationships,

which might not be reflected by static diagrams.

In a Composite Structure diagram, Classes are accessed as

Parts or run-time instances fulfilling a particular role. These

Parts can have multiplicity, if the role filled by the Class

requires multiple instances. Ports defined by a Part's Class

should be represented in the composite structure, so that

all connecting Parts provide the required interfaces

specified by the Port. There is extensive flexibility, and a

consequent complexity, that come with modeling

composite structures. To optimize your modeling, consider

building Collaborations to represent reusable Patterns

responding to your design issues.

You generate Composite Structure diagram elements and

connectors from the 'Composite' pages of the Diagram

Toolbox .

Example Diagram

This diagram shows a Collaboration used in a Composite

Structure diagram to show a relationship for performing an

installation. Collaborations are often used to model

common patterns.

Component

Diagram

A Component diagram illustrates the pieces of software,

embedded controllers and such that make up a system,

and their organization and dependencies.

A Component diagram has a higher level of abstraction

than a Class diagram; usually a component is implemented

by one or more Classes (or Objects) at runtime. They are

building blocks, built up so that eventually a component can

encompass a large portion of a system.

You generate Component diagram elements and

connectors from the 'Component' pages of the Diagram

Toolbox .

Example Diagram

This diagram demonstrates a number of components and

their inter-relationships.

Deployment

Diagram

A Deployment diagram shows how and where the system is

to be deployed; that is, its execution architecture.

Hardware devices, processors and software execution

environments (system Artifacts) are reflected as Nodes,

and the internal construction can be depicted by

embedding or nesting Nodes. Deployment relationships

indicate the deployment of Artifacts, and Manifest

relationships reveal the physical implementation of

Components. As Artifacts are allocated to Nodes to model

the system's deployment, the allocation is guided by the

use of Deployment Specifications.

You generate Deployment diagram elements and

connectors from the 'Deployment' pages of the Diagram

Toolbox .

Example Diagram

This is a simple Deployment diagram, representing the

arrangement of servers at a head office.

The servers are represented by Nodes linked by either

simple or aggregate Association relationships.

Object Diagram

An Object diagram is closely related to a Class diagram,

with the distinction that it depicts object instances of

Classes and their relationships at a point in time. Object

diagrams do not reveal architectures varying from their

corresponding Class diagrams, but reflect multiplicity and

the roles instantiated Classes could serve. They are useful

in understanding a complex Class diagram, by creating

different cases in which the relationships and Classes are

applied

This might appear similar to a Composite Structure

diagram, which also models run-time behavior; the

difference is that Object diagrams exemplify the static

Class diagrams, whereas Composite Structure diagrams

reflect run-time architectures different from their static

counterparts. An Object diagram can also be a kind of

Communication diagram (which also models the

connections between objects, but additionally sequences

events along each path).

You generate Object diagram elements and connectors

from the 'Object' pages of the Diagram Toolbox .

Example Diagram

This example shows a simple Class diagram, with two

Class elements connected.

Package Diagram

Package diagrams depict the organization of model

elements into Packages and the dependencies amongst

them, including Package imports and Package extensions.

They also provide a visualization of the corresponding

namespaces.

You generate Package diagram elements and connectors

from the 'Package' pages of the Diagram Toolbox .

Example Diagram

This example illustrates a basic Package diagram.

Profile Diagram

A Profile diagram is any diagram created in a «profile»

Package.

Profiles provide a means of extending the UML. They are

based on additional stereotypes and Tagged Values that

are applied to UML elements, connectors and their

components. A Profile is a collection of such extensions

that together describe some particular modeling problem

and facilitate modeling constructs in that domain.

You generate Profile diagram elements and connectors

from the 'Profile' pages of the Diagram Toolbox .

Example Diagram

A typical unit on a Profile diagram resembles this: