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
Clients 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
One of the general patterns of an architecture is the Model-View-Controller-Pattern, or the Boundary-Control-Entity-Schema, as it is often rephrased in the UML community. According to this, an architecture is constructed in three layers.
First, the Boundary is responsible for representing information to the user and receiving his interactions. The next layer, Control, contains the rules on how to combine information and how to deal with interaction. And finally, the Entity layer holds the data and is responsible for its persistence. To which layer a class belongs is expressed using corresponding stereotypes. You obtain these in the Properties tab of each class. An example for the usage of stereotypes is shown below.
The code generation functionality of Poseidon for UML can distinguish between different stereotypes for the same element type. In this way it can select the appropriate template for generation based on both of these factors.
Stereotypes can be displayed for nearly every element type.
Associations are very important in UML. They have properties in and
of themselves, as well as consisting of other model elements. Every association
has two association
ends that are model elements in their own right, as defined in the UML specification.
Figure 9–4 shows the Properties tab for an association, in this case
between E-mail and Client. Notice that there is no name or stereotype for
this association, but that they could conceivably exist. Also note that the
association is part of the clients namespace.
An association end can also be given a name, and like an association it doesn't require one. If an association end does not have its own name, the class name at that end of the association is displayed. Look to the left hand side of Figure 9–4. Both association ends are the names of the classes to which they connect. Like hypertext, they link to the association end properties, not to the class properties.
Associations can be specialized to anThe navigability of associations is similarly changed, using the association ends properties. The check box titled 'navigable', when checked, means towards the class that this association end points to. This is a bit counter-intuitive at first, so further explanation is warranted:
Associations can be modeled as navigable in both directions, navigable
in only in one direction, or without any navigability. In most cases, navigability
is indicated by arrows in the diagrams. The one exception is the default association,
an association which is navigable in both directions. In this case arrows
are omitted. The navigability of an association occurs at the beginning of
the arrow, not at the end. You can easily navigate to the opposite association
end using the navigation button in the Properties tab.
When you first create an association, it is navigable in both directions. The UML standard requires that both arrows are hidden in this case, so it looks just the same as an association with no arrows at all. To distinguish these two cases, the arrows of both its ends show up in grey, if necessary, when you select an association.
When a multiplicity of 1 is set, some UML authors recommend hiding the 1, whereas others like to show the 1. To suit your needs, you can set the single multiplicity to be displayed or hidden. This can only be set diagram-wide in order to avoid confusion.
To change the display setting for single multiplicity:
Select the diagram where you want to change the setting.
Go to the Style tab.
Activate or deactivate the 'Show association multiplicity of 1' check box.
Every class can have attributes that express some of its properties. In UML, every attribute has a name and a type. The type can be any other DataType, Class or Interface that is in the model. You can select the type from a combo box of all available types. If the type you need is not in the list, you can create it elsewhere, and then select it from the list.
Attribute Properties
Visibility — The visibility of an attribute expresses which other classes can access it. The options are between public, protected, package and private visibility. They are expressed with the characters +, #, ~, and –.
Modifiers — You can also set whether the attribute is write-only by checking the final check box. An attribute can also be static (class scope instead of instance scope) or transient or volatile. An initial value can be given as a Java expression.
Multiplicity — The multiplicity field determines how many references the class has to this attribute.
Accessor Methods — You can create the appropriate accessor methods for this attribute with a simple click. Just hit the button 'Add Accessors', and in the list below you will see a list of methods. This list depends on the multiplicity and the state of the final check box. If the multiplicity is 0..1 or 1..1, one setAttribute and one getAttribute method are created. If final is checked, it is only the getAttribute method that is created. If you chose a multiplicity that has a numerical upper bound (and not 1), array access methods are displayed. If you give a multiplicity with unlimited upper bound (also known as ..* or ..n), accessors for a java.util.Collection are created.
When you create a new attribute, these methods are created automatically if you checked 'Create accessors for new attributes' in
Every time you change the name or the multiplicity of the attribute, the access methods will change accordingly.If you prefer to have only some accessor methods, right-click on one of the entries in the list 'Accessor Methods'. Then, select 'Delete'. The operation will be removed from the list and thus, will not be marked as accessor any more. You will be asked if you want to remove this relation only or if you want to delete the operation completely. Whether this dialog appears or not is determined by your settings, which can be accessed in
The 'Modeling' tab is displayed in Figure 9–9. Notice the 'When removing attributes' drop-down list. The default option is to ask before deleting the accessor operation. You can also choose to always keep the operations or to delete them directly without asking. This depends on your preference and your style of working with accessor methods.For every operation, you can set several UML properties. Among them are visibility, scope (class or instance), and concurrency (with designators like sequential, synchronized, and concurrent). You can set an operation to be final, be a query, abstract, or a root method (with no parent).
In the field 'Accessed Attribute', you can define whether this operation should be marked as an accessor method for an attribute. The primary use of accessor methods is to modify the attribute internally and to control access to the modifications externally. You can choose a modified attribute (if the operation is an accessor method created by Poseidon, an attribute is already selected) or select none if you want to decouple an accessor method from its attribute.
The two lists on the right of the Properties tab are used to refine the operation's signature. In the list of parameters, the first parameter return is always there. This defines a return type for this operation. Similarly, you can add parameters that may be given a name, a type and the modifier 'final'. The final modifier is a special case that we introduced to handle Java.
The last list, 'Raised signals', is used to define whether this operation throws exceptions. Select 'Add...' from the context menu, enter a name and select a type for the thrown exception. As you know, only the type of the exception (not the name) is relevant for code generation. If you need more exception types, simply create the corresponding class in your model (e.g., MailException in your package javax.mail). Your exception type must end in ...Exception in order to be visible in the type list of exceptions.
You can define a constructor by setting the stereotype <<create>>. When you do this, the name of the operation is automatically set to the class name, and the return type is also of the class. The Java code generation respects this fact by correctly generating a constructor signature.
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.
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.