This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
We are designing our application on J2EE 5.0 in which we have defined interfaces for each component.There is interface for service layer and two interfaces, remote and local extend this interface. Session bean implements these remote and local interfaces. Similarly for data access layer we have class UserJPADAO which extends UserDAO interface. Looks good. The question is that if we draw class and sequence diagram the dependency/association has to be shown with class or with interface ? If we show with interface then lets say UserJPADAO invokes two other classes, how are we going to depict that? If we show with interfaces and t'rrow we have UserTopLInkDAO which implements UserDAO, do we have to change the class diagram ? [ October 02, 2007: Message edited by: Vinay Singh ]
Having said that, I need to make my biases clear. Almost all the time, my use of the UML is as sketches. I find the UML sketches useful with forward and reverse engineering and in both conceptual and software perspectives. I'm not a fan of detailed forward-engineered blueprints; I believe that it's too difficult to do well and slows down a development effort. Blueprinting to a level of subsystem interfaces is reasonable; but even then you should expect to change those interfaces as developers implement the interactions across the interface. The value of reverse-engineered blueprints is dependent on how the tools works. If it is used as a dynamic browser, it can be very helpful; if it generates a large document, all it does is kill trees. I see UML as programming language as a nice idea but doubt that it will ever see significant usage. I'm not convinced that graphical forms are more productive than textual forms for most programming tasks and that even if they are, it's very difficult for a language to be widely accepted.
So basically productive UML is a balancing act. Show as much as you need to get your point across - no more, strip away what isn't essential. Only diagram the interesting bits - otherwise the essential will be drowned out by the trivial. [ October 02, 2007: Message edited by: Peer Reynders ]
Joined: Dec 15, 2004
Thanks Peer. I would go with the classes as that look more logical to me. Although the problem with this approach is that we would need to revisit design if there is new implementation. Or I should show a factory object and leave the task to him.