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
Class Diagram.
Entity
Class Model Overview
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
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.
|
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 |
|
Do layout |
|
Update layout |
|
Zoom to 100% |
|
Zoom to Fit |
|
Zoom to Selection |