Poseidon for UML: Users Guide
Prev | Chapter 10. Diagram Reference | Next

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

Prev | Home | Next
Diagram Reference | Up | Object Diagram