wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Dependency/Association with Interface or class in class diagram ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Dependency/Association with Interface or class in class diagram ?" Watch "Dependency/Association with Interface or class in class diagram ?" New topic
Author

Dependency/Association with Interface or class in class diagram ?

Vinay Singh
Ranch Hand

Joined: Dec 15, 2004
Posts: 174
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 ]

Technical quiz and interview questions   SCJP 6 mock practice test
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Basically You have to decide for yourself.

In UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd Edition (amazon US) Martin Fowler distinguishes between:
  • UML as a sketch
  • UML as a blueprint
  • UML as a programming language.


  • p.6
    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 ]
    Vinay Singh
    Ranch Hand

    Joined: Dec 15, 2004
    Posts: 174
    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.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Dependency/Association with Interface or class in class diagram ?