Example 4: Finishing with a Little Inheritance
In the final example I inherit Node instances from a Node. Before we were only looking at one node at a time and iterating through them. Node instances represent the relationship between UML nodes and hardware. Nodes provide us with a way to abstract out the common elements of Node instances.
There are two different approaches to this. The first approach is to use the Nodes to represent a common hardware platform. Imagine that I work for a company that wants to order the same computer configuration for all their servers (how strange would that be!). A Node could be used to represent the typical computer configuration, which would then have multiple Node instances that inherit from it. This would save quite a bit of typing! The other approach is when software architects inform infrastructure on how components are distributed. The node represents the different tiers with logical names for each tier. How the tiers map out to the actual hardware is determined by the node instances and is created by the infrastructure group.
In the example (see Figure 6), I show a generic node, "Fleet Management," which would normally have components that are added to it. Fleet Management was defined by the software architects as a separate tier in a much larger system. To enhance this I might use the "Purpose" tag as well. I have two node instances, "Trucks" and "Persons," that were defined by the infrastructure team to break the tier into two servers. Since "Trucks" and "Persons" are entirely different domains it is safe to say the architects were involved to split them up. The server names also have ":Fleet Management" attached to them indicating that they are implementing the Fleet Management node.
|Figure 6. Trucks and Persons: The Trucks and Persons Node Instances both inherit from the Fleet Management Node. In this example there are no tags to inherit from but there may be other relationships on other diagrams that would carry over to the node instances.|
I've refactored the main program one more time to print out all the tags, including tags for the node from which each node instance is derived (tNode.classname) and the node's ID (tNode.classifier).
public static void Main(string args)
string name = ReadString("Please enter the XMI filename : ");
NodeParse np = new NodeParse(name);
mainHash = np.getNodes();
ienum = mainHash.GetEnumerator();
tNode = (Node)ienum.Value;
System.Console.WriteLine("Node = " + tNode.name);
//Add "if (tNode. != null)" for each Writeline()
System.Console.WriteLine(" CPU = " + tNode.CPU);
System.Console.WriteLine(" DiskSize = " + tNode.DiskSize);
System.Console.WriteLine(" MemorySize = " + tNode.MemorySize);
System.Console.WriteLine(" Purpose = " + tNode.Purpose);
System.Console.WriteLine(" Notes = " + tNode.Notes);
System.Console.WriteLine("Node refers to = " + tNode.classname);
System.Console.WriteLine("Node addr is " + tNode.classifier);
|Figure 7. Trucks and Persons: In the final output for Example 4, Trucks and Persons each has a node that they refer to and the unique ID for that node.|
The classname and the classifier identify which node the node instance is inheriting from. In XMI this is represented like a stereotype as an element encapsulated in a node element.
Now I'll use a switch statement to check for "ModelElement.taggedValue" instead of "ModelElement.Stereotype," look for "TaggedValue" elements (there are separate ones for classname and classifier), and add them to the Node object. Again I've used the parsing idiom discussed earlier. This code is found in Listing 4a.
Figure 7 shows the final output for Example 4. (Listing 4b has the complete source code for Example 4.)
In this article I covered the way that hardware assets can be read from a diagram. I covered reading the names, the stereotypes, the attributes and reading the relationships between nodes and node instances (inheritance). Even though I did not give explicit code for putting this information into a database I will cover those techniques later, when there is more to add into the database.
In my next article I'll show nodes being connected and how components and their dependencies can be seen in code.