Supose you are using composite (BMP) entity with a session facade and the DAO pattern for storing the JDBC code. This implies the following patterns:
- Session facade - Composite entity - Service locator (for looking up the session facade and the entity bean) - DAO pattern - Abstract factory pattern (for the entity to create its DAO's)
The first 3 patterns are hard to illustrate. I would just tie a note to the class and describe the pattern used in the HTML documentation.
Now, the last three patterns you can illustrate with classes. The DAO pattern for example takes 12 class for having 5 dao's (5 interfaces, 5 impl classes, 1 factory interface , 1 factory impl class).
This cannot be the right way ? I feel the class diagram becoming to much low level and to hard to read. The fact that a DAO is looked up using a factory does not add much the the understanding of the system. (allthough it is important for a developer).
I saw some posts of people telling they showed patterns in their component diagram. But I cannot see how this is possible since their is no real inheritance possible etc.
My question: is it nececairy to have the patterns illustrated in the class diagram ? Or is refering to them in the HTML file also valid...
What are you doing? You are supposed to be reading this tiny ad!
the new thread boost feature brings a LOT of attention to your favorite threads