It looks like an interaction diagram. As you note, the semantics of UML will change in minor ways depending upon the type of diagram.

The Client creates a ConcreteCommand object, while it has or defines a Receiver object. The ConcreteCommand object executes by using the Receiver object. That looks familiar.

Ah, the Command pattern.

The Command pattern is used to objectify an action. Basically it performs the action while storing the result of the action in a variable that can be persisted for later reference.

These are not UML notations, they are OMT notations. UML is more strict when it comes to class diagrams (dashed line == dependance, non-dashed line == aggregation). One way to differentiate the two is to look at the "inherit" symbol. In OMT, the arrow is in the middle of the line, while in UML the arrow touch the class rectangle.

Regards,

If Subject knows Observer and Observer knows Subject, you have a cyclic dependency, and cyclic dependencies are not good since they increase class coupling, effectively decreasing the possibility of code reuse. The less link you have between classes, the more your class will be reusable in another project.

The typical solution to the observer pattern is to have an AbstractSubject that known AbstractObserver, while AbstractObserver don't know AbstractSubject (no need). ConcreteSubject inherit AbstractSubject (hence it knows AbstractObserver) and defines getState(), and ConcreteObserver inherits AbstractObserver and knows ConcreteSubject - this way, it will be able to call getState(). This way, you don't have any cyclic dependency. AbstractObserver is not tied to AbstractSubject.



HTH,