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
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. Users of the system interact with this layer only. The next layer, Control, contains the rules on how to combine information and how to deal with interaction. It is responsible for transferring control based on the input received from the Boundary layer. 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.
Poseidon supports multiple stereotypes for single elements. Adding, editing, and removing these stereotypes is accomplished via a dialog that is accessible from the Details pane.
To access the Stereotype dialog:
Select the element the stereotype applies to from the diagram, Details pane, or Navigation pane.
Open the Properties tab for this element in the Details pane.
Right-click in the Stereotype box.
Select 'Edit' from the menu.
Once this dialog is open, altering and applying stereotypes is quite simple. The buttons with the arrows allow you to add and remove stereotypes from the element. The 'Add' box below the list of stereotypes will create new stereotypes, but will not automatically add them to the element. Removal of stereotypes from an element is only possible through this dialog. Selecting a stereotype and clicking the delete button will remove the stereotype from the model completely, not just from the selected element.
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 Account and Member. Notice that there is no stereotype or name for
this association, but they could conceivably exist. Also note that the association
is part of the Design.Use Case - Implementation.User Registration 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. In this case, both association ends have been named. 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:
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' in the Properties tab of the Details pane, 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 from
within the interface. The class which implements the interface is also responsible
for implementing the operations.
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.