Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Tracking Dependencies with Components and XMI : Page 3

XMI is a great technology for anyone who builds applications from models, allowing you to use information contained in those models for big upside. But if you want your model data to be effective, components are an essential building block. Learn to get your dependencies straight by making traceable components.

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:

<UML:Dependency client="EAID_E5383BFA_309E_4d3a_9882_D5AE2633FE61" supplier="EAID_20A5F9A4_44F0_4bed_801F_B1F6E555B16A" xmi.id="EAID_C5463356_384B_4105_8EBC_84D996D51BC8" visibility="public">

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 ways—Payments 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( XMIFunctoids.findNodeComponentDependency( XMIFunctoids.findNodeNodeAssociation( XMIFunctoids.findComponentNodeDependency( XMIFunctoids.findComponent(dependencyQuery))))); System.Console.WriteLine( "Connection from one dependency to another is : " + dependencyQuery + " : " + componentName); System.Console.ReadLine(); }

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.

Mark Goetsch is an Enterprise Software Architect with Wheels, Inc, and has more than fifteen years of experience in software development, enterprise modeling, and software architecture. He has another seven years experience as a trader, dealer, Broker, and an expert in e-trading. He was one of the enterprise modelers of the Tapestry Project at ABNAMRO, one of the most extensive uses of UML component and deployment diagrams to date. He is the lead architect for the MAP (Meta-Architectural Processes) framework, which is a framework for mapping the role of the software architect into software development processes. Mark is certified in Intermediate UML with the OMG and a member of WWISA. He also has a Masters in Distributed Systems from DePaul University.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date