Dependency stereotypes

[pneutam]

Say class A is heavily dependent on class B (A->B), and class C is lightly dependent on class B (C->B).

I wanted to indicate that the detailed design of class B should be done with A and thought that a stereotype on the (A->B) dependency would do the trick.

Does anyone have any suggestions as to the correctness of this approach and what stereotype to use?

Thanks for any suggestions,
Ben

[Javier]

pneutam,

If A is heavily dependent on class B, then it probably deserves a regular association (solid line).  Let me explain:

All dependencies can be traced to this:

                    <<stereotype here>>
CLASS A-----------------------------------> CLASS B

Bidirectional dependencies can be represented like this:

               ----------------------------------->
CLASS A <----------------------------------- CLASS B

Dependencies that are so common deserve their own icon (or line), e.g., aggregation, composition, etc.

Therefore, if A is heavily dependent on B, it should probably look like this:

CLASS A ____________________> CLASS B

and if B is not so heavily dependent on C then it should look like this:

CLASS B----------------------------------> CLASS C


This is usually true, for example, when in class B a method takes an argument of type C or something that can be converted to C, or when within a method in B you use a C.

If you receive an argument in a method in B that can be converted to a C, there is a special stereotype, <<become>>, that indicates that the argument can become a given type.  Usually you would have to cast the argument it to given type.  In C++ you would use a dynamic_cast, in C# a (MyType) cast, in VB a (IMyInterface) cast, etc.  The association can be represented with:

                     <<become>>
CLASS B -----------------------------------> CLASS C


C++ design also distinguishes heavy and lightweight dependencies by calling them "uses in the interface" and "uses in the implementation" (John Lakos), which roughly correspond to the description you gave.

Hope this helps--given the late response :-)

Javier

[pneutam]

Thanks for your response Javier,

What I was doing (and perhaps should have been more specific in the original post) was automatically generating design documents using EA and Automation, and wanted to specify a 'focus' class which would constitute the beginning of the document and a bunch of 'auxiliary' classes that would be included in the same document. I could have easily used my own stereotype, or tagged values etc., but wanted to see if there was commonly used method of describing the concept.

Somewhere in my reading I found the terminology of a 'focus' class and 'auxiliary' classes, the latter only existing to service the former. So, I decided to use an <<auxiliary>> stereotype, which can apply to either generealization, association or dependency relationship. The source of the relationships is implicitly a focus class, and the graph of auxiliary relationships are followed when generating the documentation.

Pros:
- Don't have to model package structure for this purpose. If I did it would result in one package (and therefore C# namespace) per focus class. I did start doing this but the design quickly became harder to understand.
- Communicates to others, at a glance, the reason for an auxiliary class' existence.

Cons:
- Uses up a stereotype. So far with my approach this is only a problem with <<realize>>, in which case I create another <<auxiliary>> dependency.
- Shows more stereotypes on diagrams. I put up with this because of the Pros.
- May become unmanageable for huge projects.

Other Notes:
- I am mostly following the specification perspective [UML Distilled], with some elements of an implementation perspective - this stereotype is one of those elements.
- As mentioned earlier, I am using associations for structural dependencies and dependencies for semantic dependencies.

Well, now I've thumped this out, perhaps this can help someone else approaching the same issue.

Cheers,
Pneutam