aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes relation between Caretaker and Orignator in Memento pattern UML representation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "relation between Caretaker and Orignator in Memento pattern UML representation " Watch "relation between Caretaker and Orignator in Memento pattern UML representation " New topic
Author

relation between Caretaker and Orignator in Memento pattern UML representation

Peter Kovac
Ranch Hand

Joined: Aug 08, 2010
Posts: 42
Hi,

I have a possibly dumb question about Memento UML representation.

Why there is no association/navigation specified between Originator and Caretaker?

AFAIK Caretaker calls Orignator for a new Memento - and this is usually shown in Sequence Diagrams - so shouldn't it be a relation?

Thanks
Thorin Potjes
Greenhorn

Joined: Aug 27, 2011
Posts: 14

I agree that this relationship should be drawn in the class diagram; the GoF are not perfect either


'Design Patterns for Java' trainer
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1770
    
    7

I disagree.
It's not necessary for there to be an association in the class model, between the Originator and CareTaker.
The class diagram is a static structure diagram and an association represents a static relationship.
There needn't be a static relationship between the Originator and CareTaker for an correct implementation of this pattern.
The relationship in the sequence diagram models dynamic behavior between objects, which is why in that diagram there must be an interaction between the Originator and CareTaker objects.


Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Thorin Potjes
Greenhorn

Joined: Aug 27, 2011
Posts: 14

OK, but since the page doesn't show a sequence diagram they could have drawn a dependency relation in the class diagram. In my opinion, this would increase understanding of the relationship between these classes, which is the goal of the class diagram in this case.
Peter Kovac
Ranch Hand

Joined: Aug 08, 2010
Posts: 42
Hi Thorin,

Could you elaborate on why Originator and CareTaker don't need any relationship?

Isn't Originator and CareTaker relationship similar to the factory pattern where client (Caretaker) asks for an object (Memento) from a factory (Originator)?
Thorin Potjes
Greenhorn

Joined: Aug 27, 2011
Posts: 14

Hi Peter,

Exactly, and that is why I think a dependency relationship should have been drawn in the class diagram.

As always, you don't have to follow the book with design patterns: in your application it might be better to split the Caretaker responsibility into 2 classes: one that extracts the Memento from the Originator, and one that stores the Memento. No good example comes to mind though.
Peter Kovac
Ranch Hand

Joined: Aug 08, 2010
Posts: 42
Hi Thorin,

Sorry, I wanted to ask Jelle about his/her opinion, but unfortunately I inserted the wrong name...

I think we're on the same track..

I hope Jelle will give us some details..

Thorin Potjes
Greenhorn

Joined: Aug 27, 2011
Posts: 14

I'm no UML expert, but I think there is some confusion in what 'static' means; a class diagram should describe the static structure of classes. I think 'static' here is meant as opposed to an object diagram, which describes what the structure of a set of objects could be at a certain point in time.

However, I don't think 'static' means that the relationships described in the class diagram need to be immutable, otherwise you could only describe inheritance in your class diagram, and not composition or aggregation, as composition and aggregation are dynamic relationships.

Therefore I think it is valid to include dependency relationships in your class diagram, even though the relationship is not 'static' as in technically immutable.

If in your application for some reason you decide to include an extra class that gets the Memento from the Originator and hands it over to the Caretaker, and when needed extracts it from the Caretaker to hand it back to the Originator, then ofcourse you would not draw a relationship between Caretaker and Originator.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: relation between Caretaker and Orignator in Memento pattern UML representation