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