• Advertisement
Sign in to follow this  

uml denotation

This topic is 4327 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

what does the relation mean maked by red circle ? uml book organize bad way.it is hard to found them. and it seem these graphic denotation have more than one meanning in different circs.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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,

Share this post


Link to post
Share on other sites
thanks.



another a design pattern problem.


Observer pattern is good. but why subject need a base class? I see no need for that. Notify() getState() just is in a subject class. am I right?

Share this post


Link to post
Share on other sites
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.


//--
#include "AbstractObserver.h"
class AbstractSubject
{
std::vector<AbstractObserver*> mObservers;
public:
void register(AbstractObserver* o);
void unregister(AbstractObserver* o);
void update()
{
std::for_each(mObservers.begin(), mObservers.end(), std::mem_fun(&AbstractObserver::notify));
}
};
//--
class AbstractObserver
{
public:
virtual void notify() = 0;
};
//--
#include "AbstractSubject.h"
class ConcreteSubject : public AbstractSubject
{
public:
const State& getState() const;
};
//--
#include "AbstractObserver.h"
class ConcreteObserver : public AbstractObserver
{
ConcreteSubject *mSubject;
public:
virtual void notify()
{
State state = mSubject->getState();
// ...
}
};



HTH,

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement