Directions of Stereotype-Reading, of Navigation and of Dependency

[Thomas Taeger]

Hi all,
There are four types of dependency in UML [UML@Work]:
- abstraction dependency:
- - Termin.java <- - -refine- - - Termin.class (p.167)
- binding dependency:
- - C++ templates, irrelevant for J2EE
- permission dependency:
- - BusinessLogicPackage <- - -access- - - PresentationPackage (similar to p.91)
- usage dependency:
- - SMTPServer <- - -use- - - EMail (p.52)
- - sub-categories of use dependency, indicated by stereotypes, replacing <<use>>:
- - - <<instantiate>> (p.51), like create:
- - - <<create>>: see question below
- - - <<call>>
- - - <<send>>
================

I concentrate on <<create>> dependency (and association) now.
In a diagram in M.Grand, "Patterns in Java", Vol.1, p.12, there is a simple example of a create associacion:
Factory ---create---> ConcreteProduct
and it is noted there: "That means that Factory objects will have a reference that allows them to access ConcreteProduct objects, but not the other way around".
For the other way around we need to change the association to a dependency!?!?
================

My question concerning dependency in general and <<create>> dependency especially is:
What is the meaning of the direction in:
- Stereotype-Reading direction:
- - Meaning of the stereotype is allways read "from the line to the arraowhead",
- - i.e. ".class refines .java" in the example above.

- Navigability direction:
- - Dependency is a special association, so its rules apply on dependency too.
- - The creation _association_ lets the Factory keep a reference to the new ConcreteProduct;
- - but not backwards.
- - If there is any directed association backwards needed,
- - - let us say for "fetches-objects-from",
- - - the Factory must have passed a back-reference to ConcreteProduct,
- - - and thereby the ConcreteProduct can access the Factory.
- - - This must be modelled as a dependency (dashed line) instead of an association (solid line).
- - - An example of passing a back-reference can be found in the Iterator pattern, Sun SL500, vol.1, 6-24:
- - - - ConcreteAggregate - - -create- - -> ConcreteIterator
- - - - ConcreteAggregate <---fetches-objects-from--- ConcreteIterator (note the direction!).

- Dependency-Semantic indicated by the direction:
- - For enabling "ConcreteIterator ---fetches-objects-from---> ConcreteAggregate":
- - - it must have got a referenc back to the creating ConcreateAggregate,
- - - via a parameter to the constructor of ConcreteIterator.
- - - This is assured by modelling "- - -creates- - ->" with a dashed line.
- - - The call-back "fetches-objects-from" is no dependency but a simple association,
- - - represented by an arrowhead with a solid (not dashed) line back to the creator.
- - After "ConcreteAggregate - - -creates- - -> ConcreteIterator":
- - - ConcreteAggregate depends on the ConcreteIterator that it has just created itself!?!?
- - - This is the direction of dependency. Not the other way around!?!? <<<<<<<<
================

Or a simpler example:
After
Granma ---create---> Mother ---create---> Daughter
the daughter will not be able to call granma.nurse().
To enable this, we must introduce dependency to the diagram:
Granma - - -create- - -> Mother - - -create- - -> Daughter
Granma <---nurse--- Mother <---nurseGranma--- Daughter
... also called lazy nursing ... (oonursing, nursing by delegating...)
Now we say "Granma depends on Mother" and "Mother depends on Daughter"!?!?
The following diagram does not model dependency, although it relies on it, and therefore is incomplete/wrong:
Granma ---create---> Mother ---create---> Daughter
Granma <---nurse--- Mother <---nurseGranma--- Daughter

Any corrections, any hints, any comments, please?
Thomas
Literature: [UML@Work]: M. Hitz & Gerti Kappel "UML@Work", ISBN 3-932588-38-X (German/Austria) on page 49
[ February 12, 2003: Message edited by: Thomas Taeger ]
[ February 12, 2003: Message edited by: Thomas Taeger ]

[Ajith Kallambella]

In my opinion, factory--->creates---->object does not necessarily mean factory depends on object. Of course the factory has to know how to create the object, but I am a little hesitant to call that as a dependency relationship.
A dependency might exist between the factory and the client of the factory. The client might depend on the factory to create the object. Similarly the client might depend on the object to get something done after factory creates it.
Consider this - if you change the behaviour of the object created, does factory get affected? Mostly such behaviour will not affect the creation semantics and hence the factory( the creator ) will remain oblivious to such a change. This essentially means factory doesnot depend on the object. Infact, in a properly designed scenario, factory will use some sort of standard contract to create the object and may not be aware of the internal workings of the object at all. Remember the factory's responsibility is just to create the object. Nothing less or nothing more.
But there is no dependency between the creator and the created other than the fact creator should have some idea how to create the object. That IMO, falls short of a dependency relationship.
I would love to hear what others think!
[ February 12, 2003: Message edited by: Ajith Kallambella ]

[Thomas Taeger]

Hi Ajith,
nice to read you!

Originally posted by Ajith Kallambella:
In my opinion, factory--->creates---->object does not necessarily mean factory depends on object. ... I am a little hesitant to call that as a dependency relationship.

You are right, it is no dependency. I also called it an association, not a dependency.
Please also note the difference between <--- (association) and <- - - (dependency). I know it is very hard to be seen, but we are bound to ASCII.

Originally posted by Ajith Kallambella:
Consider this - if you change the behaviour of the object created, does factory get affected?

Is this the only criterion for being a dependency?
So you would probabely disagree to:

Originally posted by Thomas Taeger:

For the other way around we need to change the association to a dependency!?!?

and you would probabely also disagree to:

Originally posted by Thomas Taeger:

- - If there is any directed association backwards needed, ...
- - - the Factory must have passed a back-reference to ConcreteProduct, ...
- - - This must be modelled as a dependency (dashed line) instead of an association (solid line).

and you would probabely also disagree to:

Originally posted by Thomas Taeger:

- - For enabling "ConcreteIterator ---fetches-objects-from---> ConcreteAggregate":
- - - it must have got a referenc back to the creating ConcreateAggregate, ...
- - - This is assured by modelling "- - -creates- - ->" with a dashed line.

?

Originally posted by Ajith Kallambella:
I would love to hear what others think!

Me too, yes, extraordinaryly!
Thomas.
[ February 12, 2003: Message edited by: Thomas Taeger ]

[Thomas Taeger]

Originally posted by Thomas Taeger:
There are four types of dependency in UML
...
- usage dependency:
...
- - - <<create>>: see question below
...
- - If there is any directed association backwards needed, ...
- - - the Factory must have passed a back-reference

The main mistake I did was to mix up
- data-change dependencies and
- definition-change dependencies.
The definitions and the types of dependency I gave concern the definition-changes only and were correct.
But my examples mainly dealed with data-change dependencies, and those are not notated in UML.
So today first of all I should eliminate those kinds of dependency that are not addressed by UML (but may be addressed by patterns notated with UML):
- datachange-dependency like in the Observer Pattern or its ...Listener implementations is not mentioned with that dependency UML speaks of.
- existence-dependency (and -guarantee) in data modelling
is not mentioned with what UML calls dependency.
(i.e. the guarantee that each foreign key will find its related primary key;
otherwise the database (not the data model) would be in an inkonsistent state).

UML on the other hand is concerned with dependency on definition-changes, interfacing-changes, i.e. mainly code-changes like:
- changing the name, type or sinature of a public method used by other classes
(but implementation code changes do not mind if both classes have been decoupled by an interface)
- adding, changin or removing public members or method declarations of an interface or class.
- adding, changin or removing interfaces or classes to/from a package
- ...
Thomas.
[ February 14, 2003: Message edited by: Thomas Taeger ]