• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Ron McLeod
  • Tim Cooke
Sheriffs:
  • Devaka Cooray
  • paul wheaton
  • Mark Herschberg
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Frits Walraven
  • Jj Roberts
Bartenders:
  • Carey Brown
  • salvin francis
  • Piet Souris

Class Diagram Question

 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi All,
I have two classes.
Class one
SysDBManager.java
Class two is a Utility class. It has different utility
methods placed in it.
Util.java
IF i have to show the relationship between these two
classes in a class diagram, how should i depict it.
a) Should i use a solid line showing navigability from
DBManager class to the Utility class
or
b) Should i used a dotted line from DBManager to the
Util class showing that the DBManager classes
Instantiates/Depends on the Util.java class
thanks
 
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ajit -
I also find the differences between association and dependency a little blurred.
From the UML spec, you will see an association defined as "a semantic relationship between classifiers", while a Dependency is "a term of convenience for a Relationship other than Association, Generalization, Flow, or metarelationship". Further, the spec states that dependencies are reified as classes, but implemented as Associations in the MOF. So that's clear then!
You will find some stereotyped Dependencies in the spec, which suggest different uses: Binding Refinement Usage Trace etc.
I found Larman the most useful for clarifying the differences. He suggests showing attribute dependency (on an implementation diagram, the client class holds a reference variable to the target class) as an association. Other forms of visibility (parameter/local) are shown as dependencies.
For your particular example, your 'SysDBManager' will have a dependency on the 'Util' class. You can stereotype this dependecy as a 'use' relationship by adding the <<use>> stereotype. It may also be useful to classify 'Util' as a Utility (with the the <<utility>> stereotype). Another suggestion from Fowler is to mark 'utility' packages with the {global} constraint to show that they are used by all the classes.
I hope this helps. If anyone else has a take on this, then I would be interested to hear it.
regards,
paul.
 
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
Since both solid and dotted lines are types of relationships I guess it's important to understand the defeinition of the types.
A solid line with an 'arrow' is simply an "association navigation" where the direction of the line shows the EASIEST way to get to the related object.
Ex.
<pre>
Legend:
_______> "SOLID" directed line
- - - -> "DASHED / DOTTED" directed line.
</pre>
<pre>
---------- ------------
| | | |
| User |_______>| Password |
| | | |
---------- ------------
</pre>

This says to me that EASIEST way to get a Password, is through the associated User. This DOES NOT say that I can't 'get a user' by a Password, it's just easier to go the other way. Additionally, it may not make sense to get a user from his password because alot of users may have the same Password.
The dashed line is known as a dependency. According to the UML user guide (by: Booch, Jacobson, Rumbaugh) there are 8 diffrent type of dependencies but I'll just summarize it briefly here.
In a nutshell "a dependency is a using relationshp" whereas a navigation associateion is a "having" or a "structural" relationship. A dependency can show that one object is dependant on another in the sense that changes to the source object may effect how the target object uses it.
Ex:
<pre>
---------- -------------
| Menu | | |
| Option |------->| Listener |
| | | |
---------- -------------
</pre>
This demonstrates that the Menu Option is dependant on the Listener. So, changes in the Lister's functionality or behaviour would effect how the menu needs ot use the Listener.
You should look up one of the many good UML books we have in the bunkkhouse. I started with "The Unified Modeling Language User Guide" by Grady Booch, James Rumbaugh and Ivar Jacobson ISBN:0-201-57168-4 and even though it's a very brief diescription of UML I still find myself referencing it when I need some kind of clarification.
Hope this at least gets you in the right direction.
------------------
SOURCE CODE should be SURROUNDED by "code" tags.
Click here for an example
 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by John Bateman:

Ex:
<pre>
---------- -------------
| Menu | | |
| Option |------->| Listener |
| | | |
---------- -------------
</pre>
This demonstrates that the Menu Option is dependant on the Listener. So, changes in the Lister's functionality or behaviour would effect how the menu needs ot use the Listener.


Hi,
So if i understand correctly, class MenuOption would instantiate class Listener in my code in this case?
thanks

------------------
SCJP2
 
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
You can understand Dependency and Association from the visibility point of view.An association would generally lead to Attribute Visibility, whereas a dependency would lead to Locally declared or a Parameter Visibility.
Further to John's example, the association between User and Password, would show navigability from User to Password.The direction of arrow shows that navigability is possible only from User to Password.This means a User can send a message to the Password instance, because the User has an Attribute Visibility for the Password.While coding you will define an attribute called Password in the User class.
As regards the MenuOption and Listener, it is a dependency and not an association.This is because there is a short-term visibility to Listener.In this case, the MenuOption cannot send direct messages to the Listener, however it may added as a parameter using addListener() method to listen to the appropriate actions.While coding, an attribute of Listener will not be defined in the MenuOption class, instead we will attempt to obtain the reference locally or pass it as a parameter of one of the methods defined in the MenuOption class.
Thus, User is associated with Password, and MenuOption is dependent on Listener.As John had stated, dependencies are represented by a dotted line and associations with a solid line.
Hope this helps,
Sandeep
SCJP2, OCSD(Oracle JDeveloper), OCED(Oracle Internet Platform)
 
Paul Newton
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by John Bateman:
Hi
...
A solid line with an 'arrow' is simply an "association navigation" where the direction of the line shows the EASIEST way to get to the related object.
...
The dashed line is known as a dependency. According to the UML user guide (by: Booch, Jacobson, Rumbaugh) there are 8 diffrent type of dependencies but I'll just summarize it briefly here.
In a nutshell "a dependency is a using relationshp" whereas a navigation associateion is a "having" or a "structural" relationship. A dependency can show that one object is dependant on another in the sense that changes to the source object may effect how the target object uses it.


John -
Thanks for some more feedback on this - I find this an interesting discussion.
I understand the definitions of Association and Dependency. However, I would disagree with your summary of a dependency as a "using" relationship. This is one of the kinds, but there are others (Abstraction, Binding, Permission, Usage - with all the stereotyped derivations of these). In fact, a Dependency is probably better summarised as "everything else other than an Association and a Generalisation".
I think my point is that the distinction between an association and a dependency seems somewhat artificial. If A has a reference to B, then A clearly has an Association with B. If A invokes operations on B, then clearly A has a Dependency on B. But what if A has a reference to B, then uses this to invoke operations on B? In this case, A has both an Association and Dependency. Do we show both? I have never seen a class diagram that shows both - the Association always takes priority.
Why is an association separated from a dependency? Why isn't it marked as a subtype of Dependency, or as a stereotype? Showing multiple stereotypes would make it simple to show classify a Relationship precisely.
I may be getting carried away with the UML notation here, but I don't entirely see the reason for separating associations from dependency. I am sure there are some good reasons for this, but I don't understand either UML or the UML MOF well enough.
Perhaps someone can shed light on this for me? John - would you mind listing the 8 dependency types that BJR state in their book?
regards,
paul.
 
John Bateman
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
I guess the way I've always looked at these notations is almost exactly how Paul put it. I would just add "Realisation" to the list of things Dependency is not.
I.E. Dependency can be anything other than Generalisation, Realisation and Association. (inheritance, implementation and 'object structure'. (but I will contradict myself in two seconds..
I also think that we might have to look at the example of A having a reference to B And invoking methods on B. Yes A is associated to B, and, yes we are dependant on B because we invoke methods on it. But, I beleive, association implies a certain type of dependency by default (as does ALL structural notation), I've just noticed that we term it Association to better describe the relationship.
Maybe I would improve my definition to now state:

Dependency is functional or structural relationship. To make things easier to read we 'specialise' our notation and use alternate forms when discussing Generalisation, Realisation and Association.

Just a thought.
I just wanted to also clarify that I won't pretend to have all the answers here. I'm not a greenhorn to UML put I'm still learning alot about it, so your patience, as I look up references (and ask alot of questions), is appreciated!!
The 8 dependency types in the "Booch / Jacobson / RUmbaugh" book "The Unified Modeling Language User Guide" are as follows: (I'm quoting and paraphrasing in this list.. please don't sure me Grady)
1- bind
Specifies that the source instantiates the target.
2- derive
Source is computed from the target.
3- friend
Specifal access / visibility.
4- instanceOf
5- instantiate
6- powertype
Powertype is a type where ALL objects of the source are children of the given parent. (Target?!? This is unclear to me - JB)
7- refine
Shows a finer degree of abstraction then target. I.E. Abstract Customer 'Type' as opposed to an Customer Implementation.
8- use
Source, depends on the public part of the target. This seems to bne the most common use of dependency notation.
As a developer, I notice that I use "use", "bind" and "friend" more often then the others. Could I be limiting myself too much? I mean I rarely show instance in my class models. I show hierarchy, realisation, generalisation and a bit of dependency but I rearely micro design by going into friend's and powertypes.
Comments, questions, flames? All are welcome.

[This message has been edited by John Bateman (edited September 07, 2001).]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic