Login | Register
My pages Projects Community openCollabNet

15.8. Design Patterns

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.

15.8.1. Consider using Singleton Pattern for <class>

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.

  1. You must define a static attribute (a class variable) holding the instance. This must therefore have class as its type.

  2. 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.

  3. 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 15.5.3, “Add a Constructor to a Class” .

15.8.2. Singleton Stereotype Violated in <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 15.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 15.8.1, “Consider using Singleton Pattern for <class>” .

15.8.3. Nodes normally have no enclosers

A suggestion that nodes should not be drawn inside other model elements on the deployment diagram, since they represent an autonomous physical object.

15.8.4. NodeInstances normally have no enclosers

A suggestion that node instances should not be drawn inside other model elements on the deployment diagram, since they represent an autonomous physical object.

15.8.5. Components normally are inside nodes

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.

15.8.6. ComponentInstances normally are inside nodes

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.

15.8.7. Classes normally are inside components

A suggestion that classes, as model elements making up components, should be drawn within components on the deployment diagram.

15.8.8. Interfaces normally are inside components

A suggestion that interfaces, as model elements making up components, should be drawn within components on the deployment diagram.

15.8.9. Objects normally are inside components

A suggestion that objects, as instances of model elements making up components, should be drawn within components or component instances on the deployment diagram.

15.8.10. LinkEnds have not the same locations

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.

15.8.11. Set classifier (Deployment Diagram)

Suggestion that there is an instance (object) without an associated classifier (class, datatype) on a deployment diagram.

15.8.12. Missing return-actions

Suggestion that a sequence diagram has a send or call action without a corresponding return action.

15.8.13. Missing call(send)-action

Suggestion that a sequence diagram has a return action, but no preceding call or send action.

15.8.14. No Stimuli on these links

Suggestion that a sequence diagram has a link connecting objects without an associated stimulus (without which the link is meaningless).

[Warning]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.

15.8.15. Set Classifier (Sequence Diagram)

Suggestion that there is an object without an associated classifier (class, datatype) on a sequence diagram.

15.8.16. Wrong position of these stimuli

Suggestion that the initiation of send/call-return message exchanges in a sequence diagram does not properly initiate from left to right.