Best diagram to model layered architecture

[peter.zrnko]

Consider also this:
- instances can have names (App1BL)
- it's possible to use the same instance in different diagrams

[Oliver F.]

I can see your point of having to document self interaction.

However this should imho not be done in a single diagram- on the level we are talking about you can only show a relation to self.

The collaboration however is not taking part between component C and component C but by certain *parts* of this component C and other *parts* of the same component.

Which brings us to the point where stepping down a level would be a good idea as we are propably talking about internal functionality/interaction (and this is why was talking about *parts* above, subtile, isn´t it). This is at least what I took from your text, please correct me if I am wrong.

Oliver

[drain]

[quote  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[/quote]


To show a layered architecture you can use a component diagram. Layers are notated with a "text element" that states the layer name then is followed by 100+ dashes so the text goes across the screen forming a boundary. You DO NOT use packages for layers! Packages represent a namespaces! Layers are conceptual and are not part of the UML! Do not follow anyone or any book that directs you otherwise!

Once you have your layers defined, you will have a bunch of dashes lines across your page. Now you drop components in their appropriate layer. Only dependencies between components are shown. In your example, I think you stated you will have an application layer with applications A, B, and C. These applications can be notated as components with dependencies on their respective sub-layer components.

In a typical layered architecture view, you never put a component or a layer in the diagram more than once, and you do not show behavior. I'm not sure where you're going here; I can only guess. If you're trying to show component instances, then your not doing a layered architecture view, you're probably doing a component "wiring" diagram with the layers in the background (which is irrelevant since you should have a layered architecture view first). In this diagram you wire together component instances to build a system. This is NOT a deployment! How and if you can do this for multiple applications in one diagram depends on the structure of your components (i.e. basic component, port-based component, subsystem component, etc).

In none of the cases above is behavior modeled. You need to look into the behavior diagrams to see which one is best. Layers are irrelevant in behavior diagrams. If you're trying to stick that in there, your approach is likely wrong as you're trying to do too much in one diagram.

[Dave_Bullet]

I agree with drain here.

Chances are you are trying to show too much in one diagram.  Typically a diagram is only useful to one stakeholder and worthless or much less value to another.  When you try to include more than one perspective in a diagram, you inadvertently complicate and "water down" the intent - making the diagram less useful to more stakeholders (if you see what I mean).

I think drain is referring to swimlanes to represent layers.   I also prefer to use swimlanes, but the only limitation here is you cannot show permitted layer interaction / communication with a swimlane.(eg you may for example not permit the presentation layer to directly access the integration layer but must go through the services layer etc...).  This is maybe why drain chose to use notes to represent layers.

Thinking another way, if you need to show the same logical component in multiple places on a diagram because it could otherwise be untidy with lines all over the place - do you need to refactor your system?  Alternatively, if you have an existing system you want to refactor - let the lines make a mess of the diagram.  That way you help justify your cause

I suppose if we knew your target audience (excuse me if I missed that skimming the posts) then we might help find a solution for you.

PS: I've wanted the same functionality as you, but have concluded it is a failure of my ability to choose the correct UML concepts, rather than an inability of the tool / UML.

Cheers,
David.