Deployment Diagram questions

[lfgcasey]

I have a couple of questions on Deployment Diagrams.

First, Say I've defined a generic 'Load Balancer' as a <<device>> type and create instances of Load Balancer representing physical servers e.g. LoadBalancerPetra, LoadBalancerAlexandria. Then, realizing my mistake, I change the 'Load Balancer' type to <<node>> since that's really what it should be (if I'm not mistaken). The type correctly changes on the 'Load Balancer' parent but the instances LoadBalancerPetra and LoadBalancerAlexandria still show as type <<device>> and not <<node>>, even though I still see the 'Load Balancer' as the classifier. Shouldn't the instance types have changed to <<node>> as well?

Second, somewhat related, how does one best represent a cluster and its individual nodes on a deployment diagram? We've been simply using a single node using a naming convention 'Cluster'<Type><RootName><Node1Name>/<Node2Name>/etc. So example ClusterAIXFluffA/B/C. However, there are times when we'd like to specify differences in node behavior in instances of the same cluster type. So ClusterAIXFluffA/B/C is a mirrored redundant set of nodes but ClusterAIXPeanutA/B/C has a primary node with two fail-over nodes. Our engineers need to know that a node failure on ClusterFluff is automatically handled and no special code needs to be written. However on ClusterPeanut, they need to know to wait for the failover node to spin up if the primary node goes down, as well as which is the primary,secondary,tertiary node (legacy systems, amiright?). What would be the best way to model the differences and failure details between the two cluster types?

Thanks!

[qwerty]

First, yes. That's what happens. You may claim it to the tool but then again, it was your fault. Shouldn't be that difficult to find the instances and fix them too. If you do that all day you should probably slow down in creating new things.

Second, I'd somehow group them in a boundary or a package. Eventually looking at both as nodes inside a failover node could as well be a way. Depends on many things. Simple notes can help to explain the circumstances as well.

q.

[matthew.james]

You may claim it to the tool but then again, it was your fault.

Interesting response ...
There is a lot of 'challenging' discussion in these forums where people are criticised (often fairly) becaue they want the tool to do something that would potentially compromise the modelling.  EA is after all a modelling tool (not a diagramming tool for example).

Yes there was user error here, but if EA is a modelling tool then I would expect that an instance would be linked to the abstract type and would retain model consistency.

Does the tool work this way ? apparently not
Is it likely to change ? possibly / probably not so we should understand that and work with the reality of where we are
Should it work this way ? I'd say that yes it should retain consistency

[Paolo F Cantoni]

Hi Matthew,

An interesting question.  Certainly, from a theoretical point of view, the change should flow through from the Classifier to the Instance.  However, in an enterprise situation where a modeller may not be aware that others have created such instances, it should NOT flow through automatically.  The tool should observe that there are instances (optionally list them) and ask if the change should be flowed.  It may be, as qwerty suggested, that the original model may have been slightly defective and just changing the Classifier type may be injecting more issues.

Paolo

[Glassboy]

Second, somewhat related, how does one best represent a cluster and its individual nodes on a deployment diagram? We've been simply using a single node using a naming convention 'Cluster'<Type><RootName><Node1Name>/<Node2Name>/etc. So example ClusterAIXFluffA/B/C. However, there are times when we'd like to specify differences in node behavior in instances of the same cluster type. So ClusterAIXFluffA/B/C is a mirrored redundant set of nodes but ClusterAIXPeanutA/B/C has a primary node with two fail-over nodes. Our engineers need to know that a node failure on ClusterFluff is automatically handled and no special code needs to be written. However on ClusterPeanut, they need to know to wait for the failover node to spin up if the primary node goes down, as well as which is the primary,secondary,tertiary node (legacy systems, amiright?). What would be the best way to model the differences and failure details between the two cluster types?

I think, that a cluster is a collection of nodes.  It has no compute resource in of itself (unlike a hypervisor).  So I think Qwerty's advice is spot on, although with what you're trying today a package may be better than a boundary.

In ArchiMate terms you'd use nodes in a grouping and then assign locations to each node.  I must admit I never use Sparx's group element because the shapescript is far harder to deal with than a boundary.

[Richard Freggi]

"We've been simply using a single node using a naming convention 'Cluster'<Type><RootName><Node1Name>/<Node2Name>/etc. So example ClusterAIXFluffA/B/C. However, there are times when we'd like to specify differences in node behavior in instances of the same cluster type. So ClusterAIXFluffA/B/C is a mirrored redundant set of nodes but ClusterAIXPeanutA/B/C has a primary node with two fail-over nodes. Our engineers need to know that a node failure on ClusterFluff is automatically handled and no special code needs to be written."

In my opinion the problem is that this is not information that should described in a deployment diagram.  There are other diagrams where you can describe classifier properties, behavior and interaction logic.

[lfgcasey]

querty,Mathew,Paolo:

Thanks for the very thoughtful discussion on the classifier/instance relationship WRT modeling. I can certainly understand why EA behaves the way it does, it just didn't behave the way we expected, which is why I asked the question. This is is good information that I can share with my team so thanks again!

[lfgcasey]

Second, somewhat related, how does one best represent a cluster and its individual nodes on a deployment diagram? We've been simply using a single node using a naming convention 'Cluster'<Type><RootName><Node1Name>/<Node2Name>/etc. So example ClusterAIXFluffA/B/C. However, there are times when we'd like to specify differences in node behavior in instances of the same cluster type. So ClusterAIXFluffA/B/C is a mirrored redundant set of nodes but ClusterAIXPeanutA/B/C has a primary node with two fail-over nodes. Our engineers need to know that a node failure on ClusterFluff is automatically handled and no special code needs to be written. However on ClusterPeanut, they need to know to wait for the failover node to spin up if the primary node goes down, as well as which is the primary,secondary,tertiary node (legacy systems, amiright?). What would be the best way to model the differences and failure details between the two cluster types?

I think, that a cluster is a collection of nodes.  It has no compute resource in of itself (unlike a hypervisor).  So I think Qwerty's advice is spot on, although with what you're trying today a package may be better than a boundary.

In ArchiMate terms you'd use nodes in a grouping and then assign locations to each node.  I must admit I never use Sparx's group element because the shapescript is far harder to deal with than a boundary.

Again, thanks for the thoughtful discussion. More great information I can take back to the team!

[lfgcasey]

"We've been simply using a single node using a naming convention 'Cluster'<Type><RootName><Node1Name>/<Node2Name>/etc. So example ClusterAIXFluffA/B/C. However, there are times when we'd like to specify differences in node behavior in instances of the same cluster type. So ClusterAIXFluffA/B/C is a mirrored redundant set of nodes but ClusterAIXPeanutA/B/C has a primary node with two fail-over nodes. Our engineers need to know that a node failure on ClusterFluff is automatically handled and no special code needs to be written."

In my opinion the problem is that this is not information that should described in a deployment diagram.  There are other diagrams where you can describe classifier properties, behavior and interaction logic.

Interesting. What other diagram types would you suggest?

[Richard Freggi]

Hello Casey

Deployment diagram is a structural diagram that shows what things you have and how they fit together.  A node is usually a physical thing - a metal box (server, switch, RAID array etc).  Metal boxes don't have behaviors besides maybe beeping and flashing lights.  They just sit there.
Nodes deploy artifacts that are usually binary files (executables, database instances etc.).  The files also pretty much sit there.

The best way to show how the system behaves is to use a behavioral diagram: in your case I suspect an interaction diagram (sequence or communication) would be best.

If you need to show some behavior information, business rule or constraint on the deployment diagram, the best practice is to add a good ol' text note to the diagram.

More info in "The unified modeling language reference manual" (Booch, Jacobson, Rumbaugh), or The elements of UML 2.0 style (Ambler)

Cheers!

[lfgcasey]

Hello Casey

Deployment diagram is a structural diagram that shows what things you have and how they fit together.  A node is usually a physical thing - a metal box (server, switch, RAID array etc).  Metal boxes don't have behaviors besides maybe beeping and flashing lights.  They just sit there.
Nodes deploy artifacts that are usually binary files (executables, database instances etc.).  The files also pretty much sit there.

The best way to show how the system behaves is to use a behavioral diagram: in your case I suspect an interaction diagram (sequence or communication) would be best.

If you need to show some behavior information, business rule or constraint on the deployment diagram, the best practice is to add a good ol' text note to the diagram.

More info in "The unified modeling language reference manual" (Booch, Jacobson, Rumbaugh), or The elements of UML 2.0 style (Ambler)

Cheers!

I'll have to get my hands on those books. Thanks!