Critics concerning design pattern usage in ArgoUML.
These relate to the use of patterns as described by the so called “Gang of Four”. ArgoUML also uses this category for critics associated with deployment and sequence diagrams. The current version of ArgoUML has the following critics in this category.
The class has no non-static attributes nor any associations that are navigable away from instances of this class. This means that every instance of this class will be identical to every other instance, since there will be nothing about the instances that can differentiate them.
Under these circumstances you should consider making explicit that you have exactly one instance of this class, by using the singleton Pattern. Using the singleton pattern can save time and memory space. Within ArgoUML this can be done by using the «singleton» stereotype on this class.
If it is not your intent to have a single instance, you should define instance variables (i.e. non-static attributes) and/or outgoing associations that will represent differences bewteen instances.
Having specified class as a singleton, you need to define the class so there can only be a single instance. This will complete the information representation part of your design. To achieve this you need to do the following.
You must define a static attribute (a class variable) holding the instance. This must therefore have class as its type.
You must have only private constructors so that new instances cannot be made by other code. The creation of the single instance could be through a suitable helper operation, which invokes this private constructor just once.
You must have at least one constructor to override the default constructor, so that the default constructor is not used to create multiple instances.
For the definition of a constructor under the UML 1.4 standard, and extensions to that definition accepted by ArgoUML see Section 14.5.3, “Add a Constructor to a Class” .
This class is marked with the «singleton» stereotype, but it does not satisfy the constraints imposed on singletons (ArgoUML will also accept «Singleton» stereotype as defining a singleton). A singleton class can have at most one instance. This means that the class must meet the design criteria for a singleton (see Section 14.8.1, “Consider using Singleton Pattern for <class>”).
Whenever you mark a class with a stereotype, the class should satisfy all constraints of the stereotype. This is an important part of making a self-consistent and understangle design. Using the singleton pattern can save time and memory space.
If you no longer want this class to be a singleton, remove the «singleton» stereotype by clicking on the class and selecting the blank selection on the stereotype drop-down within the properties tab.
To apply the singleton pattern you should follow the directions in Section 14.8.1, “Consider using Singleton Pattern for <class>” .
A suggestion that nodes should not be drawn inside other artifacts on the deployment diagram, since they represent an autonomous physical object.
A suggestion that node instances should not be drawn inside other artifacts on the deployment diagram, since they represent an autonomous physical object.
A suggestion that components represent the logical entities within physical nodes, and so should be drawn within a node, where nodes are shown on the deployment diagram.
A suggestion that component instances represent the logical entities within physical nodes, and so should be drawn within a node instance, where node instances are shown on the deployment diagram.
A suggestion that classes, as artifacts making up components, should be drawn within components on the deployment diagram.
A suggestion that interfaces, as artifacts making up components, should be drawn within components on the deployment diagram.
A suggestion that objects, as instances of artifacts making up components, should be drawn within components or component instances on the deployment diagram.
A suggestion that a link (e.g. association) connecting objects on a deployment diagram has one end in a component and the other in a component instance (since objects can be in either). This makes no sense.
Suggestion that there is an instance (object) without an associated classifier (class, datatype) on a deployment diagram.
Suggestion that a sequence diagram has a send or call action without a corresponding return action.
Suggestion that a sequence diagram has a return action, but no preceding call or send action.
Suggestion that a sequence diagram has a link connecting objects without an associated stimulus (without which the link is meaningless).
![[Warning]](images/warning.png) | Warning |
|---|---|
Triggering this critic indicates a serious problem, since ArgoUML provides no mechanism for creating a link without a stimulus. It probably indicates that the diagram was created by loading a corrupt project, with an XMI file describing a link without a stimulus, possibly created by a tool other than ArgoUML. | |
Suggestion that there is an object without an associated classifier (class, datatype) on a sequence diagram.