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

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.

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

2.2. Toolbar

Select
Add or remove space between elements
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