An abstraction is a dependency relationship joining two artifacts
within the model at different levels of abstraction. Within ArgoUML it
is principally used through its specific stereotype
realize to define realization dependencies, which link
artifacts that specify behavior to the
corresponding artifacts that implement the
behavior.
In the UML metamodel Abstraction is a sub-class of
Dependency and through that
Relationship.
An abstraction with stereotype realize is
represented on a class diagram as a dotted line with a solid white head
at the specifying end.
![[Caution]](images/caution.png) | Caution |
|---|---|
All other stereotypes of abstraction should be represented using an open arrow head, but this is not supported by ArgoUML | |
The details tabs that are active for abstractions are as follows.
ToDoItemStandard tab.
PropertiesSee Section 17.16.2, “Abstraction Property Toolbar” and Section 17.16.3, “Property Fields For Abstraction” below.
DocumentationStandard tab. See Section 12.5, “Documentation Tab”.
StyleStandard tab.
![[Note]](images/note.png)
Note The values for the bounds of the abstraction appear to have no meaning. Changing them has no effect on the diagram. This is sensible behavior, given the association is tied to particular artifacts.
SourceStandard tab. This contains the single downlighted text
N/A.ConstraintsStandard tab. ArgoUML only supports constraints on Classes and Features (Attributes, Operations, Receptions, and Methods), so this tab is grayed out.
Tagged ValuesStandard tab. In the UML metamodel,
Abstractionhas the following standard tagged values defined.derived(from the superclass,ModelElement). Valuestrue, meaning the abstraction is redundant—it can be formally derived from other elements, orfalsemeaning it cannot.Note Derived abstractions still have their value in analysis to introduce useful names or concepts, and in design to avoid re-computation.
Note The UML
Elementmetaclass from which all other artifacts are derived includes the tagged elementdocumentationwhich is handled by the documentation tab under ArgoUML
Go upNavigate up through the package structure.
DeleteThis deletes the abstraction from the model
![[Warning]](images/warning.png)
Warning This is a deletion from the model not just the diagram. To delete an abstraction from the diagram, but keep it within the model, use the main menu
Remove From Diagram(or press the Delete key).
NameText box. The name of the abstraction. There are no constraints on the name of an abstraction, which is not shown on any diagram.
StereotypeDrop down selector. Abstraction is provided by default with the UML standard stereotypes
derive,realize,refineandtrace.Caution ArgoUML automatically selects the stereotype realize when an abstraction is created. The user is free to change the stereotype to use the abstraction to indicate for example a
tracerelationship. However ArgoUML will not alter the representation on the diagram accordingly.Navigate Stereotype
icon. If a
stereotype has been selected, this will navigate to the
stereotype property panel (see Section 15.4, “Stereotype”).NamespaceDrop down selector. Records and allows changing the namespace for the abstraction. This is the package hierarchy.
SuppliersText area. Lists the artifact that is the supplier end of this abstraction (for a realization this is the end providing the implementation).
Note Although this is a text area there is no mechanism for adding more than one supplier.
Button 1 double click navigates to the selected entry.
ClientsText area. Lists the artifact that is the client end of this abstraction (for a realization this is the end providing the specification).
Note Although this is a text area there is no mechanism for adding more than one client.
Button 1 double click navigates to the selected entry.