Tracking Dependencies with Components and XMI

his fourth installment in an ongoing series on XMI leads me to a discussion of components. Components are an essential building block of your data model and are thus a valuable asset to any developer who is using models and XMI. In this article, I will discuss how components are linked together and how they interact with nodes, UML's method of representing hardware. This article should give the final pieces to building a system that can track software dependencies on an enterprise scale. The idea is very similar to what many banks are building to track their software assets.

So just what, exactly, is a component? I discussed that very issue in the opening paragraph of an earlier article on component diagrams, but here I am really just concerned with what it means from a data perspective. The data that we are concerned about answers the questions: How many components do I have that have the same attributes? Which component depends upon other components?

Components come in two different varieties: one is the abstract representation of a component and the other represents the implemented software. There are numerous applications for mining components using XMI and C#. For example, I can study how one component relies on another and use the information to map my software dependencies. Inventory management is another use that I discussed in an earlier article on nodes. In short, the more you know about your components, the better you will understand your enterprise as a whole.

Reading a Component from an XMI File

Figure 1. Abstract Component: The Payments component is still in development. It is being developed in C#.NET version 2.0. In this example I used the stereotype <<development software>> to indicate that the software is in development. Another way to indicate software in development is to add a "status" tag that is set to development.

The first example that I have developed shows an abstract component (see Figure 1). Abstract components develop the reference architecture for an application; they are always components that are deployed but they are either in development or will exist generically in a couple of different deployments. In contrast, instantiated components represent the actual implementation of a particular component.

An abstract component, for example, is the Payments component. It is stereotyped as software in development with version information pertaining to the .NET framework and the C# language. The Payments instantiated component is an executable component, which is stereotyped as an executable with its applicable version information referring to the version of Payments, not to the .NET framework version as in the abstract component.

Author's Note: The code in this article builds on the sample code developed throughout this XMI series.

Now let's take a look at the code for this example. The first thing to note is that UML tags, such as the Language and Version tags used in the Payments component, are not encapsulated in the XML tag for a component. They are listed in the XML as if they were separate parts like a component or node. The only way to differentiate between a component's tag and a node's tag is by checking the ModelElement id. To solve this I added another hash table for components. My code checks which table has the key that will let me switch between node tags and component tags.

Figure 2. Output: The screen shot shows the results of finding the Payments component using XMI.

if (_nodes.ContainsKey(attrRef))
 {
    Node attrNode;
    attrNode = (Node)_nodes[attrRef];
    _nodes.Remove(attrRef);

    switch (attrName)
       {
       case "CPU":
              ...
       }
       _nodes.Add(attrRef, attrNode);
   }       else {
       if (_components.ContainsKey(attrRef))
       {
       Component attrComponent;
       attrComponent = (Component)_components[attrRef];
       _components.Remove(attrRef);

    switch (attrName)
    {
       case "Language":
              ...
    }
       _components.Add(attrRef, attrComponent);
  }
}

The end result of the first example is that I can read the component from the XML file, find its name and the tags for the programming language it is written in, and find the version of the .NET framework that the language is hosted in (see Figure 2).