dependencies on packages

[Mr. Sanders]

Hello,

I wonder if there is a possibility to show the dependencies between packages.

Asume you have

A.ClassA
and
B.ClassB

so ClassA is in namespace/package A
and ClassB is in namespace/package B.
Now draw an aggregation in a way that
ClassA aggregates ClassB.

If you have modelled it this way you have an
implicit dependency from package A to package B.

If you now create a package diagram and drag and drop
package A and B on it, NO dependency is shown.

This is wrong.

And reverse engineering doesn't elaborate the depencies on this level.

This is bad.

Because that's what I want to see for refactoring and it would be an ease for such a tool to draw this dependencies.

So please create this dependencies at reverse engineering and modeling automatically.

This information is very worthy.

Regards

[«Midnight»]

Remember that in EA the concept of "dependency" generally does not relate to packages. Packages represent arbitrary partitioning of elements. As such, the concept of one package depending on another because such a relationship exists among the contained elements, is a bit of a stretch.

In fact, it is perfectly acceptable to have circular set of such relationships. Some elements in package A may depend on elements in package B, while some elements in package B depend on some in package A. This does imply a circular "dependency" relationship between packages A and B. Such a relationship would be a cause for alarm among the contained elements, but makes sense at the package level.

What I am saying is that such relationships do exist among packages, but it can be impossible (or difficult) to 'infer' them automatically. If you add such a feature you might find the results are not always what you expect, or desire.

David

[Mr. Sanders]

Hello David,

thank you for your answer, but I don't agree with you.

Beginning with your first sentence, I have to ask why is it possible to draw dependencies on package level if the concept does not relate to dependencies.

It is not impossible nor difficult to infer them.
This is a problem of directed graphs and can be calculated very easy with matrices. These problems are very well understood in mathmatics and I can't see a problem in that.
By the way: rational rose did it this way.

Of course your sample can make sense. I don't disagree.
If it makes sense, thatn do it.

But it also makes sense that I want do find e.g. these cyclic dependencies, because in a refactoring I want to get rid of them.

Or you want to find dependencies of packages which against
architecural rules e.g. frontend directly accesses DB layer
instead of going through the middleware layer.

it would be an ease to find these things it the dependcies are drawn automatically.

I am talking about the scenario, when creating new diagrams.
At least at this diagrams I want to have the dependcies.

Existing diagram, of course shouldn't be affected, because
the tool can not decide if the user wants to see it, or not.

On new diagrams I can decide it I want do see it.

Regards
Michael

[«Midnight»]

You are definitely making sense Michael. And I did not mean to imply that you were not.

However, please reread the last sentence of my first paragraph, as well as the second paragraph.

[First, please take the following points as all being prefixed by IMHO.]

What I am trying to get at is that the packages themselves are not the subject of the dependencies, the elements are. This is subtle. One effect is that you often do not want to remove dependencies between packages. Nor should you always be concerned by a circular package dependency chain.

Finally, automatic detection of package dependency relationships can be somewhat subjective. In one instance you may want to show the relationship between packages containing 'owner' elements and packages containing 'owned' elements - this is the example you used. In another you might want to illustrate a relationship between packages that have elements involved in a different type of connection. If all 'dependent' relationships were included this could easily link almost every package in your model; often not what you want.

Of course, EA could have a dialog (or something) providing a set of options for package dependency detection. However, these would likely need to be individually set for each set of packages - sometimes each diagram containing a given package. Suddenly we're getting into something quite complex to develop, maddeningly difficult to maintain, and having fairly limited utility.

Considering the work of maintaining the option sets when working with your model, an individual user might do just as well to set this up by hand, or write a task-specific add-in. From the Sparx side, the time involved might be better spent in other areas of the product.

That's all I wanted to point out,
David

[Mr. Sanders]

Hello David,

yes you are right, the elements in the package have the dependcies and therefore it shouldn't be possible to remove a dependencie from one package to another if there are still elements in these packages which are dependend from each other. Only if no dependencies on the element level exist, than the dependency on the package level should be allowed to be deleted.

Showing dependencies for different aspects between packages is just the same as showing them between classes.

When dropping two classes with an association between then on a diagram, leads to a drawn association between the classes. And it's my decision if I want do have it in the diagram or not. If I don't want to show it, i remove it, without deleting it.

And that's what we need for dependencies too.

I guess, if you will get a diagram where nearly every package is dependend from nearly every otherone, than this is a good indicator that here is something going wrong.

There shouldn't be an option for package dependency detection.
This is a must in my point of view. Not an option.

The question is: Do I want to show the dependency them?

And that's the same question, everybody has to answer on every class diagram. The relationship between them is there.
They are just not visible on all diagrams, depending on the context I want to show.

And you are right, there are still ohter areas in the product, where other things have to be done.

And as a sample, we need the same solution for components too.

Regards
Michael

[Thomas Mercer-Hursh]

Note that it should be fairly simple to create automation which would create a "roll up" link between packages based on the contents.  We are going to do something like this in our work in order to summarize the links of the lower level components into higher levels.

[Paolo F Cantoni]

Note that it should be fairly simple to create automation which would create a "roll up" link between packages based on the contents.  We are going to do something like this in our work in order to summarize the links of the lower level components into higher levels.

Hi Thomas and Michael,

You will need to decide which relations are "canonical" and which are, therefore, "derived".  Unfortunately (as usual ) - while EA does support isDerived via a Custom Property (well hidden, it took me two years to find it...) for Associations - it doesn't for Dependencies... Perhaps one of you could submit a big report since the plethora of bugs I've reported over the last two weeks have disappeared down a black hole...

Paolo