Diagrammatic Inconsistency ?

[Hugo]

Here is another related issue that confuses me, one in which the hierarchy implied visually (by looking at diagrams/elements) becomes (apparently) inconsistent:

A use case diagram contained another element a Package called PrimaryUseCases. This appears a pink box as you know, in there is a list of contained use cases in this box.

The PrimaryUseCases element is also a child (in the tree view) of the UseCaseModel node node in the tree.

Now when I dragged my use case node (AddAuthorisedUser) within the tree view (as I described earlier) I dragged it to be a child of the PrimaryUseCases node.

The effect of this is that in the UseCaseModel (the main, outer diagram) the pink box called PrimaryUseCases now contains the additional use case (or rather its name) BUT if I double click that pink box I do NOT see this newly added use case diagram because (as you said) it has not been added to tha diagram simply because I moved it within the tree.

My confusion though, is that WHY does it appear in the pink box named PrimaryUseCases (seen in the main other UseCaseModel diagram) ?

Clearly dragging this use case HAS altered the diagrammatic view, because the package PrimaryUseCases clearly shows its name, yet dbl-clicking it show a use case diagram that has no trace of it.

Would you not agree that rendering a use case package in a diagram that contains a list of use cases BUT does not contain these diagrams when expanded, is inconsistent?

Thanks
Hugh

PS: I'd like to add that I am seriously evaluating this product for heavy usage by very experienced analysts in a large organisation, so please bear with me if I appear pedantic, I really am trying to get up to speed.

[«Midnight»]

Hugo,

[Please take the following as reading IMHO in all cases...]

You're certainly asking the appropriate questions for an evaluator, regardless of whether you are looking at personal or heavy corporate use.

As to your use case issue (and possibly your earlier post), I suspect without proof that somehow EA is not closing the loop when one use case is moved under another. If this is the case we might also see similar issues with other elements or diagrams.

[Note that the next thought applies to version EA 6.5. I am not sure if 6.1 works the same way; I simply don't remember and am part way through the 6.5 evaluation.]

If you were to make a use case a composite element, you would end up with a new use case diagram under the parent. Double clicking the parent would usually take you to the child diagram. [This last sentence would not always (or perhaps ever) apply to version 6.1.]

Ideally, regardless of whether we talk about use cases or other elements, if an element could be meaningfully set to composite, but is not so at the moment, dragging a (valid) 'inner' element onto the element should set (or allow to be set at user option) the parent element to be composite. Part of this should be setting the appropriate behaviors and attributes so that navigation occurs, and generation scripts etc. recognize the composite relationship.

I'd mention this to Sparx once you have a set of clear steps to replicate the problem - which should be trivial in this case. If it is a bug they will doubtless resolve it (unless, as I mention it has been handled in 6.5). If not, it might form the basis of a feature request. At the very least, if the behavior is not consistent they will likely want to revisit the logic in this area.

HTH, David

[Eve]

Hi Hugh,

I hope I can shed some light about how the interaction between the Project Browser and Diagrams interact.  What you're describing is all completely normal and intended behaviour.

The Project Browser is used to specify containment.  Diagrams are there to convey the information that you, the user want.  This is unlikely to be a pure copy of exactly what is contained in each package.  You may have multiple diagrams for a package that each reflect a small portion of the details found in that package.  Or, you may not have any diagrams at all.  Diagrams can contain any elements from any package.

Where I'm getting with this is that a diagram does not contain elements.  It contains a link to the original element.  No link does, or should exist without the user creating it.

The fact that a diagrammatic representation of a package lists the contents of that package by default does not mean that the diagram opened when the package is clicked should contain those elements.

I hope that has shed some light.  If you have any further questions, please do ask.

[bmioch]

To put it another way Hugo, Diagrams are single documents that can contain anything from your project, from any package or node. It is not a Hierarchy.

To use an analogy

On your computer, your Desktop (Diagram) can have shortcuts to files anywhere on your file system, regardless of what folder they are in.

Your Folder Structure (Project Browser) that you see in Windows Explorer, is independent of your Desktop.