Relating Component Instances and Node Instances
The third example adds a node instance to the diagram. (I had to add the <<deployment>> stereotype to the dependency because SparxSystems Enterprise Architect thought it was bad UML to leave it off! See Figure 5
.) I also added a dependency from the component instance to the node instance. In UML diagrams this has the stereotype of <<deployment>> indicating that the component is deployed on the hardware that the node represents.
Figure 5. Adding a Node Instance: The Payments executable component instance is deployed on the Car Server. Notice that the arrow for the <<deployment>> dependency points to the server where the software is deployed. In deployments the component and the nodes are instances not abstractions.
Figure 6. Client and Supplier: The dependency has two pieces, a client and a supplier. In this case the client is Payments. The supplier, Car, is the server. When this example is output as a diagram the first end of the dependency is the CAR instance (supplier), while the second is the payments (client).
Adding a dependency is the same as adding an association except that each end of an association points to the same thing. In dependencies one end is the supplier and the other is the client:
The supplier points to what the component is dependent upon. In this case, it is the CAR Node. The client, on the other hand, is the dependee or in this case the payments component (see Figure 6
Putting It All Together
The final example combines managing the dependencies between two nodes with managing the dependencies between a component and a node to track the dependency between a component instance on one piece of hardware [node] with a component instance on another. This example shows how the Finance component instance is dependent on the Payments instance through the dependencies they have on the their nodes (see Figure 7). Just to show that the example is somewhat generic, I also show how the Payments instance is dependent on the Finance instance.
Figure 7. Dependency: This diagram depicts the dependency of the Finance component on the Payments component.
Figure 8. Output No. 1: The output from the XMI in Figure 7 has the component instance of Finance depending upon Payments.
The output (Figure 8
) corresponds with the example diagram, where the Finance component instance is dependent on the Payments component. The second output (see Figure 9
) shows that it can be the other way around. The Payments component is dependent on the Finance component. In a real situation you would of course use the directional indicator on the node's associations to constrain it to a one-way dependency.
|Figure 9. Output No. 2: The second output from Figure 7 demonstrates that it can work both waysPayments depends upon Finance.|
My first cut at coding a solution was to do the step-by-step approach (see Listing 1
). Even though the code works, it is not very coherent. Even with some added comments, it is difficult to tell what each part of the code is doing.
If I use the pipes and filters pattern the code is easier to understand and change. There is little need for documentation (which we know all programmers dislike).
public static void Main(string args)
string name = ReadString("Please enter the XMI filename : ");
string dependencyQuery =
ReadString("Please enter the component instance : ");
XMIFactory XFact = new XMIFactory(name);
String componentName = XMIFunctoids.findComponentName(
"Connection from one dependency to another is : "
+ dependencyQuery + " : " + componentName);
This discussion of nodes and components should get you started developing asset management system to mine your diagrams. There are many more uses for XMI including creating diagrams from the company's assets (in a database or flat file), validating class diagrams, and building a UML editor.