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

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


XMI: Using C# to Capture UML Models : Page 4

UML models of the future will use XMI as a method of interchanging model data. And because XMI uses XML, suddenly the world is our oyster: In particular, you can extract model data and save it to a data store. Find out how to dissect data from your models using C#.




Application Security Testing: An Integral Part of DevOps

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) { Hashtable mainHash; IDictionaryEnumerator ienum; Node tNode; string name = ReadString("Please enter the XMI filename : "); NodeParse np = new NodeParse(name); mainHash = np.getNodes(); ienum = mainHash.GetEnumerator(); while (ienum.MoveNext()) { 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); System.Console.WriteLine(); } System.Console.ReadLine(); } } }

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.

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