- Project tools
-
-
- Using ArgoUML
-
- The ArgoUML Project
-
- Nightly builds of docs
-
- The Stats Project
-
- How do I...
-
| Category |
Featured projects |
| scm |
Subversion,
Subclipse,
TortoiseSVN,
RapidSVN
|
| issuetrack |
Scarab |
| requirements |
xmlbasedsrs |
| design |
ArgoUML |
| techcomm |
SubEtha,
eyebrowse,
midgard,
cowiki |
| construction |
antelope,
scons,
frameworx,
build-interceptor,
propel,
phing
|
| testing |
maxq,
aut
|
| deployment |
current |
| process |
ReadySET |
| libraries |
GEF,
Axion,
Style,
SSTree
|
| Over 500 more tools... |
|
Welcome to the new Tigris! There have been some changes to the administration of mail lists. Project and list owners should check out the Discussion Services release notes.
An association on a class diagram represents a
relationship between classes, or between a class and an
interface. On a usecase diagram, an association binds an actor
to a usecase. Within the UML metamodel, Association
is a sub-class of both Relationship and
GeneralizableElement. The association is represented as a solid line connecting
actor and usecase or class or interface (see
Figure 18.1, “Possible model elements on a class diagram.”). The name of the
association and any stereotype appear above the line. ArgoUML is not restricted to binary associations. See
Section 18.12.1, “Three-way and Greater Associations and Association
Classes” for more on
this. Associations are permitted between interfaces and
classes, but UML 1.3 specifies they must only be navigable
toward the interface—in other words the interface cannot see
the class. ArgoUML will draw such associations with the
appropriate navigation. Associations are often not named, when their meaning is
obvious from the context. ![[Note]](images/note.png) | Note |
|---|
ArgoUML provides no specific way of showing the
direction of the association as described in the UML 1.4
standard. The naming should attempt to make this clear. |
The association contains at least two ends, which may be
navigated to via the association property sheet. See
Section 18.13, “Association End” for more
information. 18.12.1. Three-way and Greater Associations and Association
ClassesUML 1.3 provides for N-ary associations and
associations that are governed by a third
associative class. Both are supported by
ArgoUML. N-ary associations are created by
drawing with the association tool from an existing
association to a third class. The current implementation of
ArgoUML does not allow the inverse: drawing from a 3rd class
towards an existing association is not possible. Association Classes are drawn exactly like a normal
association, i.e. between two classes, but with a different
dedicated tool from the diagram toolbar. 18.12.2. Association Details TabsThe details tabs that are active for associations are
as follows. ToDoItemStandard tab. PropertiesSee
Section 18.12.3, “Association Property Toolbar”
and Section 18.12.4, “Property Fields For Association”
below. DocumentationStandard tab. See
Section 13.4, “Documentation Tab”. PresentationStandard tab. ![[Note]](images/note.png) | Note |
|---|
The values for the bounds of the Association
have no meaning, since they are determined by the
location of the connected items. Changing them has no
effect on the diagram. |
SourceStandard tab. You would not expect to generate
any code for an association, and any code entered here
is ignored (it will have disappeared when you come back
to the association. Tagged ValuesStandard tab. In the UML metamodel,
Association has the following standard tagged
values defined. persistence. Values
transitory, indicating state is
destroyed when an instance is destroyed or
persistent, marking state is preserved
when an instance is destroyed.
derived (from the
superclass, ModelElement).
Values true, meaning the
association is redundant—it can be formally derived
from other elements, or false
meaning it cannot.
![[Note]](images/note.png) | Note |
|---|
Derived associations still have their value
in analysis to introduce useful names or
concepts, and in design to avoid
re-computation. |
![[Note]](images/note.png) | Note |
|---|
The UML Element metaclass
from which all other model elements are derived includes
the tagged element documentation
which is handled by the documentation
tab under ArgoUML |
18.12.3. Association Property Toolbar
Go upNavigate up through the package structure of the
model. For an association this will be the package
containing the association.
New StereotypeThis creates a new Stereotype (see
Section 16.6, “Stereotype”) for the selected
association, navigating immediately to the properties
tab for that stereotype.
DeleteThis deletes the selected association from the
model. ![[Warning]](images/warning.png) | Warning |
|---|
This is a deletion from the model
not just the diagram. To delete
an association from the diagram, but keep it within
the model, use the main menu Remove From
Diagram (or press the Delete key). |
18.12.4. Property Fields For AssociationNameText box. The name of the association. By
convention association names start with a lower case
letter, with “bumpy caps” used to indicate
words within the name, thus:
salesHandling. ![[Note]](images/note.png) | Note |
|---|
ArgoUML does not enforce any naming convention
for associations. |
![[Tip]](images/tip.png) | Tip |
|---|
Although the design critics will advise
otherwise, it is perfectly normal not to name
associations on a class diagram, since the
relationship is often obvious from the classes (or
class and interface) name. |
StereotypeDrop down selector. Association is provided by
default with the UML standard stereotype for
Association (implicit) . Stereotyping can be useful when creating
associations in the problem domain (requirements
capture) and solution domain (analysis), as well as for
processes based on patterns. The stereotype is shown between « and » below the
name of the association on the diagram. Navigate Stereotype
icon. If a stereotype has been selected, this will
navigate to the stereotype property panel (see
Section 16.6, “Stereotype”).
NamespaceDrop down selector. Records and allows changing
the namespace for the association. This is the package
hierarchy. ConnectionsText area. Lists the ends of this association. An
association can have two or more ends. For more on
association ends see
Section 18.13, “Association End”. The names of the association ends are listed,
unless the association end has no name (the case when
it is first created), in which case (Unnamed
AssociationEnd) is shown. ![[Note]](images/note.png) | Note |
|---|
The only representation of association ends on
a diagram is that their name appears at the relevant
end of the corresponding association. |
Button 1 double click on an association end will
navigate to that end. Association RolesText area. (To be written) LinksText area. (To be written)
|