Best diagram to model layered architecture

[vtcoder]

What would be the best diagram and approach if I want to model a layered architecture and show multiple applications using the layers, so that the layers would have to be listed multiple times.

I tried to do this with a component diagram, and I modeled each layer as a package, but I could not have multiple instances of the package (nor any other type I could find).

Is there a better diagram where I can list components multiple times?

Thanks

[«Midnight»]

Perhaps composite structure diagrams, depending on the level and type of things you need to expose.

Note that you don't necessarily have to be modeling instances to use a composite structure diagram, though most examples seem to assume that you are.

[vtcoder]

I still couldn't have multiple copies of any element.

What diagram can I use to list multiple copies of some type of element?

Thanks

[«Midnight»]

I think I see what you mean.

You generally cannot have the same element appear more than once on the same diagram.

What threw me was reading "multiple instances" above. I somehow fastened on those words and missed the rest of the sentence. You can have multiple instances - in the UML sense of the word - on a diagram, but these don't seem to be what you are trying for.

Could you work around your problem somehow? Perhaps create a 'master' diagram with hyperlinks to separate diagrams, each showing one aspect. You can see something like this on some of the diagrams in the EA Example project.

[vtcoder]

Well, I have found a workaround, but it is ugly. I had to create like 50+ object instances to show my set of ~10 items multiple times on the same dialog.

There really is no maintainability to this approach, it was really done just to be able to produce the diagram.

This seems to be a serious limitation in EA, to me at least. There are many places where you may want to list the same item mutlple times (in a component fashion like I have here, or in order to better organize a document, etc.).

I wonder if there is any hope of removing this limitation in the future?

Thanks

[thomaskilian]

How about creating multiple diagrams for each layer and create a single diagram with all these single diagrams? Also not directly what you want but probably an alternative.

[vtcoder]

That approach could certainly work for some scenarios. But not for this particular scenario. Allow me to elaborate a bit.

Lets say I have logical 'components' A, B, and C. Then lets say I need to show how 2 different applications are built from A, B, and C, and futher, how the components from each applicaiton interact with each other.

In this situation, if the sets of components are not on the same diagram, showing their allowed and disallowed interactions, then it wouldn't be of much use, in this context.

I really think EA should have the option to list multiple instances of things for this reason, and for avoiding clutter in some situations.

Thanks for the suggestions though. Hopefully a future release may allow this.

[Oliver F.]

Lets say I have logical 'components' A, B, and C. Then lets say I need to show how 2 different applications are built from A, B, and C, and futher, how the components from each applicaiton interact with each other.

So what you want to do is link *physical* instances of those components *physically* together into several applications, not logically.

You can of course have several *instances* of the same component in one diagram.

If you move the component on the diagram you are usually asked what to do (if not use the Ctrl-Key before dropping it)- Simple Link, Instance or new child.
Choose "Instance" and there you go.

Oliver

[vtcoder]

I was unable to get this to work in EA 7.0

I get a message saying this item already exists and multiple copies are not currently supported. This is the case for package, object, class, etc.

For component, it does prompt me, but it will not allow the simple link, it gives the same message above. The only option that works is the instance, which creates many instances in my model elements, which is basically the solution I have now.

Thanks for the suggestion, but it doesn't look like it works in this case.

I certainly may be missing something. Perhaps you can do this linking with some other type of element, or in some other diagram type. If so, let me know.

[dbax]

I fully agree with this request as I was in the similar situation. Just to note that every other UML modeling tool I have used (RSA, MagicDraw, VS, and yes, even NetBeans) have allowed me to make multiple copies (not instances if I have chosen so) of the same artifact on the diagram. I found this very useful when creating multiple architectural views.
However, considering that EA and alike tools are designed for the sole purpose of software design I do not necessarily agree with the statement about the clutter. I think the main purpose of these kind of tools like EA is to simplify the process of modeling by allowing us to create simple and concise diagrams that can be drilled down to further detailed ones. Most of them lack the "System" perspective and are, IMHO, solely focused on "Software" design and architecture. For former I have to resort to some other tools which again brakes the traceability that I am so keen on preserving.
I do hope that EA will address this issue though.
Regards,

D

[vtcoder]

I agree, in most cases having concise diagrams with links is optimal. But, with regard to the clutter issue, if I have a large class diagram that I need to present in one view (diagram) and I have two classes that need to be on opposite corners of the diagram, and they both inherit from the same base class, I would like to have 2 instances of that base class, one on each corner, instead of trying to rearrange stuff to allow them both to point to the same base class copy without 'cluttering' up the diagram (or at least having to reshuffle everything to avoid ugly overlap.

I think both arguements for supporting multiple copies are valid, although I admit they probably do not fall into the primary use case for the diagrams, they are still valid alternatives.

Thanks for the input

[Oliver F.]

For component, it does prompt me, but it will not allow the simple link, it gives the same message above. The only option that works is the instance, which creates many instances in my model elements, which is basically the solution I have now.

I think you are missing a key concept here- you have logical components (A, B, C), which are unique.
You would like to tie *instances* of those components together to several physical applications (which is a deployment, btw.) so the physical view of this is clear to me- you are indeed having a lot of instances because this relects the real conditions in the model.

Oliver

[vtcoder]

No, I think I'm clear on that.

I don't want to show multiple instances - I want to show the logical concept in multiple arrangements. Simple as that. These are not instances, it is not physical or implementation. It is still logical concepts.

I still think it makes sense to allow multiple copies for this.

Don't mean to be argumentative. I appreaciate your perspectives. Thanks.

[Oliver F.]

No, I think I'm clear on that.

I don't want to show multiple instances - I want to show the logical concept in multiple arrangements. Simple as that. These are not instances, it is not physical or implementation. It is still logical concepts.

Sorry for being picky here.
What you call "arrangement" is a physical, thus a deployment, concept. You create  a deployment by deploying instances of the same logical component into several applications and now you would like to show the collaboration between those instances.

Though your intention to show this using the same component several times is clear, UML does not support this because this is what the scenario of having instances is for.
If you could draw associations between visualisations of the same component in a diagram this would raise a visualisation issue:
If you have component C in the upper right corner and in the lower left corner you would draw some sort of dependency/association between them. However this would also be a dependency/association to "self" which in turn must be hidden on this diagram to avoid confusion (because it appears three times in the view- upper right, lower left and between both Cs) but propably drawn in others where C is drawn only once.
If you have the same component three times in the same diagram- well, even worse because you create two associations/dependecies to "self".

I believe those components you mention are collaborating with a defined interface, meaning that C is not behaving differently with other instances of C.
So why not draw a collaboration diagram for each component A, B and C with 2 instances per component showing the collaboration between them ? You could reference the three diagrams in the overview diagram thus still having the path to the collaboration where it belongs to.

Oliver

[vtcoder]

Good suggestion. I will look into the collaboration diagram as an option.

I do see exactly what you mean with the concept of these 'component's being instances. I still disagree in this instances however. Perhaps I should have used a more viable examples than 'components'.

If you consider 2 logical layers, lets say business layer (BL) and data access layer (DAL), and you want to show the possible allowed interactions between these, including allowed 'self' interaction, then unless you make up arbitrary instances to represent multiple copies of the BL or DAL, then you need some way to be able to show these logical layers multiple times on the same diagram.

Now granted, if I have multiple DAL layers listed on a diagram, I can certainly see that this walking a fine line between instance and logical layer, so I don't fault your arguement. I guess I'm just convinced that there is a subtle difference here, primarily because I'm still showing logical layers. I.e., I am not showing an implementation of a DAL, I'm showing the logical concept of a DAL in order to document its allowed interactions with other layers, and even itself. Of course this will be realized with real DAL component implementations, and once we have an idea of a couple of actual applications we could created a diagram to depict the physical implementation plans of a given application. But, at this point, I would want to pull out the logical diagram and review the plan to make sure the implementation is within our planned architecture.

I guess another angle on this, if you're still not buying into my logical vs instance arguement, is that it is a matter of practicality. If I am creating models during the logical architectual planning, and I have no real instances/components, I should be able to list my logical items multiple times to show interaction at this level. Even if I have a couple of applications that have components I could use to model this, it doesn't make sense, because the interactions I'm modeling are global to all possible applications, and it wouldn't make sense to try to use any one implementation to capture that. So I'm left with the option of creating arbitrary, fake instances, which clutter up my model, and are impossible to maintain (because they are all, for example, DAL, DAL, DAL, DAL, BL, BL, BL, BL, not App1BL, App2BL, App1DAL, App2DAL.

Having said all of that, I will look into the collaboration diagram. Perhaps this is what I need. Also, I would like to be clear that I'm not trying to say that your arguement is invalid. It may be dead on for the diagrams we're talking about, and perhaps I have not found the correct diagram I need to capture this type of information yet. I hope this is the case. If it is not, then I really hope EA considers this as an option (not a primary work flow, but at least an option). Or I'm going to have to look into other products because I have to do a lot of this and it is just not practical using EA given my current understanding of the product and diagrams. So I do hope I find a diagram that meets the need.

Thanks