Poseidon for UML: User Guide
Prev |  | Next

# Chapter 10. Diagram Reference

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.

Figure 10-1. A Class diagram.

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 Display - Hide Package display.

### 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.

### Toolbar

| Select
| Node
| Instance of a Node
| Component
| Port
| Instance of a Component
| Dependency
| Connector Between Ports
| Class
| Interface As Circle
| Lollipop
| Socket
| Association
| Directed Association
| Aggregation
| Composition
| Association Class
| Object
| Link
| Comment
| Connect Comment to Element
| Text
| Circle
| Rectangle
| Polygon
| Polyline
| Repaint

## 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.

Figure 10-2. A Component diagram.

### 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.

### Toolbar

| Select
| Node
| Instance of a Node
| Component
| Port
| Instance of a Component
| Dependency
| Connector Between Ports
| Class
| Interface As Circle
| Lollipop
| Socket
| Association
| Directed Association
| Aggregation
| Composition
| Association Class
| Object
| Link
| Comment
| Connect Comment to Element
| Text
| Circle
| Rectangle
| Polygon
| Polyline
| Repaint

## 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.

Figure 10-3. A Deployment diagram.

### 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.

### Toolbar

| Select
| Node
| Instance of a Node
| Component
| Port
| Instance of a Component
| Dependency
| Connector Between Ports
| Class
| Interface As Circle
| Lollipop
| Socket
| Association
| Directed Association
| Aggregation
| Composition
| Association Class
| Object
| Link
| Comment
| Connect Comment to Element
| Text
| Circle
| Rectangle
| Polygon
| Polyline
| Repaint

Prev | Home | Next
Exporting Graphics and Printing |  | Behavioral Diagrams