Chapter 10. Diagram Reference
- Table of Contents
- Structural Diagrams
- Behavioral Diagrams
There is a lot to say about when to use which diagram type when developing a design, and what the role of it should be. The different answers to this are referred to as the design process or design method. This document is not intended to describe a concrete design process. Poseidon for UML can be used for any such process. Instead, in this chapter we will look at the various diagram types and how the corresponding model elements are created or edited in Poseidon. For many of these diagrams, a short example has already been given in the default model Stattauto, which we looked at in Chapter 4.
Structural Diagrams
Structural diagrams are used to show the organization of the system and include Class, Component, Deployment, and Object diagrams.
Class Diagram
Class diagrams 
are probably the
most important diagrams of UML.
They can be used for various purposes and at different times in the
development life cycle. Class diagrams are often applied to analyze
the application domain and to pin down the terminology to be used. In
this stage they are usually taken as a basis for discussing things
with the domain experts, who cannot be expected to have any
programming nor computer background at all; therefore, they remain
relatively simple like this typical example, the
Entity Class Model Overview Class
Diagram.
Please note that graphical elements have been added to this diagram simply to highlight different regions.
Once the domain has been established, the overall architecture needs to be developed. Class Diagrams are used again, but now implementation-specific classes are expressed in addition to the terms of the domain.
If a class is shown in a diagram of a different package, the text (from package.subpackage) is displayed just under the class name in the diagram. You can turn it off with the Context menu of the class. Move the mouse over the class, right-click, and select
Diagram Elements
Packages -
Packages are used to structure the model. Placed into Class
Diagrams, they illustrate the hierarchy explicitly. Classes can
then be nested inside them, or they can be used exclusively to
express the interdependencies of the packages. These diagrams
are sometimes referred to as package diagrams, but in Poseidon
you do not need to make a difference here and can combine them
at will.
Dependencies - Exist between
packages, and express that classes within one package use
classes from the package on which it depends.
Collaborations -
Exist between objects. Additionally you have to associate a
Classifier Role to this collaboration to
illustrate what role a special element plays in that
collaboration.
Interfaces -
Restricted to contain operations only, no attributes. Operations
are abstract and have no implementation from within the
interface. The class that implements the interface is also
responsible for implementing the operations. Interfaces can also
be represented with lollipop (or ball) n
Classes - Classes
are the most important concept in object-oriented software
development, and in UML as well. Classes hold operations and
attributes and are related to other classes via association or
inheritance relations. A class has a few properties of its own,
such as name, stereotype and visibility, but the more important
aspect is its relation to other classes.
Inheritance
relations - Relations between interfaces or between
classes. They are not allowed between an interface and a
class.
Implementation
relations - Relations which exist only between
interfaces and classes.
Association
Relations - Relations between classes.
Toolbar
| Select |
| Class |
| Package |
| Actor |
| Actor as Classifier |
| Generalization |
| Dependency |
| Association |
| Directed Association |
| Aggregation |
| Composition |
| Association Class |
| Interface |
| Interface as Circle |
| Realization |
| Lollipop |
| Socket |
| Collaboration |
| Classifier Role |
| Attribute |
| Operation |
| Comment |
| Connect Comment to Element |
| Text |
| Circle |
| Rectangle |
| Polygon |
| Polyline |
| Repaint the diagram |
Object Diagram
Object diagrams show classes at the instance level.
Since objects are not on the same conceptual level as classes,
although very closely related, they are expressed in separate
diagrams. On the other hand, objects are on the same conceptual level
as instances of components and instances of nodes. That's why Poseidon
for UML combines the functionality for creating object diagrams,
component diagrams and deployment diagrams into a single editor;
therefore, to create an object diagram, use the editor for the
deployment diagram
This may not seem very intuitive at first, but we found it to be very useful. Objects, component instances and node instances can thus be used conjunctively. You can still restrict yourself to use only objects and their links in a deployment diagram.
The diagram elements and toobar options are provided here for
quick reference. A much more comprehensive look at the editor is
provided in the section on deployment
diagrams.
Diagram Elements
Nodes and
Instances of Nodes - Nodes
represent the hardware elements of the deployment system.
Components and
Instances of
Components - Components stand for software elements
that are deployed to the hardware system.
Links - Links are
used to connect instances of nodes or objects.-
Dependencies - Dependencies
exist between components and can be specified by utilizing
predefined or user-defined stereotypes.
- Associations -
Associations are used to display communication relations between
nodes. They can be specified by utilizing predefined or
user-defined stereotypes.
Objects, Classes, Interfaces - Components and nodes can
include objects, classes or interfaces.
Component Diagrams
After a while, clusters of classes that strongly interact and
form a unit will start to peel out from the architecture. To express
this, the corresponding clusters can be represented as components. If
taken far enough, this can lead to a highly reusable component
architecture. But such an architecture is hard to design from scratch
and usually evolves over time. As mentioned above, component diagrams
are, like object diagrams, edited with the deployment diagram
editor; therefore, the corresponding model elements are explained in
that section.
Diagram Elements
- Nodes and
Instances of Nodes - Nodes
represent the hardware elements of the deployment system.
- Components and
Instances of
Components - Components stand for software elements
that are deployed to the hardware system.
- Links - Links are
used to connect instances of nodes or objects.
-
Dependencies - Dependencies
exist between components and can be specified by utilizing
predefined or user-defined stereotypes.
- Associations -
Associations are used to display communication relations between
nodes. They can be specified by utilizing predefined or
user-defined stereotypes.
-
Objects, Classes, Interfaces - Components and nodes can
include objects, classes or interfaces.
Deployment Diagrams
Finally the way the individual components are deployed to a
hardware system can be described using the deployment
diagram. Because we decided to merge the different diagram types, the
editor contains a wide set of elements to be used (see also: Object
diagrams Component diagrams). Deployment
diagrams are defined on two levels: object or _instance level and
class level. For this reason, Poseidon for UML provides both nodes and
instances of nodes.
Diagram Elements
- Nodes and
Instances of Nodes - Represent
the hardware elements of the deployment system.
- Components and
Instances of
Components - Represent software elements that are
deployed to the hardware system.
- Links - Used to
connect instances of nodes or objects.
-
Dependencies - Exist between
components and can be specified by utilizing predefined or
user-defined stereotypes.
- Associations -
Used to display communication relations between nodes. They can
be specified by utilizing predefined or user-defined
stereotypes.
-
Objects, Classes, Interfaces - Components and nodes can
include objects, classes or interfaces.