Level: Introductory James Densmore, Consulting Solution Architect, IBM
15 Jan 2008 
from The Rational Edge: Learn about the differences between models and UML diagrams used in the process of software analysis and design. This article steps you through several operations using IBM Rational modeling tools to illustrate various ways to view and alter a model.
From The Rational Edge.
One of the interesting things about the English language is the number of words loaded with multiple meanings. This seems particularly true in the technology arena, and certainly in software and systems development, which are covered frequently in The Rational Edge. One of the early bits of "object-oriented" humor had partly to do with the numerous different uses of the word "virtual" in C++, not to mention the complexity of the language: "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when the was the last time you needed one?"
1
"Model" is another such word, burdened with multiple meanings and undertones of complexity. This article will focus on some basic aspects of UML modeling that often confuse new users of modeling tools in the IBM® Rational® Software Modeler family. Armed with these concepts, you'll make better use of the modeling tool as you incorporate it into your development methodology.
Basic semantics
The issue of multiple meanings for the word "model" came up recently during the modeling of a system in SysML,
2
a derivative of the Unified Modeling Language
3
(UML) for modeling systems. Naturally, we were using Rational Systems Developer
4
(RSD). First, we noted that the file RSD produces (?.emx) is called the model file. By extension, its contents, as rendered by the RSD tool itself, must be the model, right? Well, no. Actually, we were looking at a model of a subsystem of the system CheeseGrater
5
that was under development, a subsystem that participates in collaborations implementing functionality in other systems as well as CheeseGrater (see Figure 1). Our system's model was referring to several model files, each an .emx file. I've made an implicit assumption here that I should divulge: The only model we should call the model is the one associated with the entire system that's under development, enhancement, or otherwise under study. Thus, the thing that is the model varies with the system under study, but not with anything else. When I'm engaged in discussions with other analysts, and when modeling (at least in UML), we've found it important to clarify which system that is. On the other hand, we can have a model of anything, and we can have many model files.
Figure 1: Cheese grater system
So where was our system's model? It must be in CheeseGrater.emx, right? Again, not quite: some of it was, but not all of it, since CheeseGrater.emx's contents referred to information about subsystems in other .emx files. The model of CheeseGrater must be in all those model files. Formally, the entire model of a system is the information content of the closure of the model files describing any part of the system.
Let's consider the definition of the word model. Dictionary.com
6
provides this definition: A simplified representation of a system or phenomenon, as in the sciences or economics, with any hypotheses required to describe the system or explain the phenomenon, often mathematically. This aligns with our intuition that the model isn't the system; it's merely a representation of the system. The model is a simplification of the real system, designed to demonstrate or illustrate various important aspects of the system to interested stakeholders of the system. So, how are these demonstrations done when the model is depicted in UML or SysML? I think you know the answer -- modeling tools present the information in the form of diagrams. Diagrams are crucial, since without them, it is difficult to develop an understanding of the model and, hence, the system it represents. A diagram is a view of the model, but it is not a view of the whole model. Again, turning to the mathematical formalism, a diagram is a projection of the model.
Using diagrams as windows into your model
Many of you probably know that IBM Rational modeling tools permit most anything that is in the model to appear on a diagram. Conversely, if it isn't in the model, then (save for notes and other visual candy that is only a part of the diagram), it cannot be a part of the model. Therefore, if you see something depicted on the diagram, you know it's in the model. However, what if something you were expecting to see is not on a diagram? That does not mean it isn't in the model. The author of the diagram might have chosen to remove that element from the diagram. The author is free to do so, and may have done it to reduce clutter or otherwise address the need to communicate with some stakeholder that the author has in mind.
What if the element isn't found in the Rational Software Modeler (RSM) project explorer? Does that mean it isn't in the model? Usually, but again, not necessarily. The project explorer of most modeling tools is intended to provide a nearly complete view of the model of the system, but it also might be missing things. For example, RSA has a notion of filters for the project explorer
7
. An element of any kind can be filtered out so that it doesn't appear in the explorer window, as shown in Figure 2.
Figure 2: Project Explorer Filter in the Preferences window of Rational Software Architect
The power of UML diagrams
Okay, let's start modeling. Figure 3 shows our small model of a CheeseGrater, starting with a class diagram.
Figure 3: Class diagram for the model "CheeseGrater"
Let's review what the simple Class diagram in Figure 3 is communicating. Note that it conveys an impressive amount of precisely defined information. The cliché is true: a picture is worth a thousand words. Okay, 200 words in this case.
- Any Kitchen has zero or more CheeseGrater objects. All CheeseGrater objects are associated with exactly one Kitchen object. If a Kitchen is destroyed, so also are the CheeseGraters it contains.
- A CheeseGrater has an optional Cover. Each Cover is associated with exactly one CheeseGrater. The destruction of a CheeseGrater does not necessarily mean the destruction of its Cover.
- Each CheeseGrater has exactly one Handle. Each Handle is associated with exactly one CheeseGrater. If a CheeseGrater is destroyed, its Handle is destroyed.
- Each CheeseGrater has exactly one CuttingSurface. Each CuttingSurface is associated with exactly one CheeseGrater. If a CheeseGrater is destroyed, its CuttingSurface is destroyed.
- Each CuttingSurface has one or more Edges. Each Edge is associated with exactly one CuttingSurface. If a CuttingSurface is destroyed, so also are its Edges.
- Each CheeseGrater has a manufacturer. Each Handle is composed of some specific material. Each CuttingSurface is of a specific type and material. Each Edge is of a particular type. (The model, at least as it is shown, doesn't identify the kinds of values the associated objects might be endowed with. Let's give an example, though: the type of an Edge might be serrated or smooth.)
Now, let's look at another Class diagram (Figure 4) from the same model.
Figure 4: Another Class diagram for the CheeseGrater model
This simple diagram containing a single class fails to tell us about the Kitchen or about the Edge. Perhaps the author of the diagram was addressing a stakeholder whose only interest is in the CheeseGrater itself and not its constituent parts.
Let's make a simple change to the model. Suppose we have misnamed the class for the Cover; we should have named it "GraterCover." One way to change the name is to go to the project explorer and change the spelling of the class, as shown in Figure 5.
Figure 5: Renaming the class
Now the previous diagram looks like this (Figure 6):
Figure 6: The cover element is now renamed as "GraterCover."
What does the first class diagram look like? The change should be there now as well, right? Let's be sure this simple but powerful concept is understood: Every diagram depicting this element of the model formerly known as Cover will now depict that element with its new name GraterCover. Cover was represented previously on the first diagram, so we should find that it has changed, as shown in Figure 7:
Figure 7: Complete Class diagram for CheeseGrater model, showing new name for the cover element
And indeed it has changed, and the spelling has been changed on any diagram where that class's name appears. Again, the diagram is a view, or a projection, of the model. And in changing the name of Cover to GraterCover we are not merely changing something on a diagram, we are changing the model, and, therefore, all diagrams projecting the change. This includes the project explorer. While it's not a diagram, the project explorer certainly is a projection of the model, so the class Cover's name is changed to GraterCover there, too, as shown in Figure 8.
Figure 8: Even the project explorer reflects the change made to the cover element name.
We all know that models get larger over time. Just to be sure our understanding is complete, suppose that another package in our model contains some element whose name is also "Cover." Has the name of that element also been changed? No. It still is called Cover. The similarity in names is considered coincidental. Cover is unrelated to the GraterCover, because it is a different element in the model, as illustrated in Figure 9.
Figure 9: Another package in the same model with an element coincidentally named "Cover" remains unchanged.
The power of the model
Hopefully we've clearly shown that there is a semantic model behind these diagrams. This fact can be leveraged in other useful ways. For example, suppose we are dealing with a complicated model, perhaps one much more complicated than the one we've been using here, and it is difficult to remember all the elements associated with CheeseGrater. Let's demonstrate how we can discover what associations the model contains. We create a new class diagram (right-clicking on the For Edge model package, and selecting Add Diagram, then Class Diagram). Since it's new, the diagram is initially empty. From the project explorer we grab the CheeseGrater class with the mouse and drag it onto this empty diagram (Figure 10):
Figure 10: Empty diagram now populated with CheeseGrater class, dragged and dropped from the project explorer
Next we right-click on this class on the diagram, and select from the context menu Filter, then Show Related Elements, as illustrated in Figure 11.
Figure 11: Selecting the "Show related elements" function
The resulting dialog box appears as shown in Figure 12:
Figure 12: The "show related elements" function
Here we select "Show All Relationships [Default]," and we click on Details> > to get the Relationship Types, Expansion Direction, Stopping List, and Levels. If Levels is not set to 1, we set it to 1, and we set the Expansion Direction radio buttons to Both if necessary, then click OK.
Figure 13 shows the result of this graphical query.
Figure 13: Resulting Class diagram, based on selections made in "Show related elements" function
Did we get the whole model? Look carefully: we did not. In particular, the Edge class is not present. Had we set the Level to 2, or if we had selected Expand Indefinitely (careful, this can be resource intensive, and/or result in a very busy diagram), then the Edge class would have appeared. Level simply determines how many layers the query algorithm is applied to. Moreover, there's no Show Related Elements query we can run that will yield the element in that other package still named Cover, since there are no relationships, direct or indirect, with that element.
Why does this diagram not look like the first one? Because we started a new diagram, and there's no presentation relationship of any kind between the two diagrams. Both are projections of the same model, but the positions of the classes and associations are unique to each diagram. The locations were chosen by a positioning algorithm in RSA that tries to keep elements arranged in a visually appealing way. We can rearrange the diagram in any way we like.
Once the concept of an underlying model is clear, the modeling tool becomes much easier to work with. Perhaps you've made the classic error of deleting an element from the model instead of merely from the current diagram. At one time or another, we all have, but you'll be much less likely to make this error once the model concept is clear in your mind.
Let's discuss this concept further. In the following figure we're about to delete an element (the one we right-clicked on) from the model entirely, not merely from a diagram where it's depicted. If we finish this operation, it will be removed from the model and all the diagrams and views on which it appears, including the project explorer. If it's a package, its contents will also be removed. All relationships it has also will be removed. Thus, the "Delete from Model" option shown in Figure 14 is a very powerful operation, so it should be used with care. Our practice is to avoid hastily deleting elements from the model. Instead, we usually create a package to hold elements we think are no longer needed, and name it "Obsolete." Move the element you believe is no longer needed into that package. Of course, you'll undoubtedly remove it from the diagrams where it is present, too. This takes longer, but its relationships will have been preserved if you subsequently discover you didn't really want that element to be deleted.
Figure 14: The "Delete from Model" option is a very powerful operation that should be used carefully.
Conclusion
A model offers one-stop shopping for information about a system. It is a representation of a system that emphasizes things that are important to your stakeholders, among them the team of developers tasked with developing the actual system. In this article, the UML models are manipulated by modeling tools such as RSM or RSA. A UML model contains semantic elements and diagrams, and the diagrams are views, or projections, of the semantic elements in the UML model.
This is a powerful concept for several reasons. First, there is far less room for ambiguity. Two disconnected diagrams in a pure diagramming tool such as Microsoft PowerPoint can lose synchronization with each other. For two diagrams depicting elements in the same model this is unlikely, because a change to an element in one diagram is automatically reflected in other diagrams where it appears. A second, more subtle reason is that the model, not the diagrams, becomes the expression of record for the structure, semantics, and behavior of the system.
We can leverage this fact in ways beyond producing more UML diagrams that project the system for new stakeholders. For example, we might also produce reports from the system model. The latest version of RSM has a new report generating facility based on Eclipse Business Intelligence and Reporting Tools (BIRT), and it is the subject of a recent IBM Rational developerWorks article by Steve Hovater
8
demonstrating the effectiveness of this technique. Armed with this tooling, analysts no longer turn to diagrams for knowledge in the same way. Instead, they turn to the model. The diagrams it already contains may depict sufficient information, but if not, analysts can use the power of the model to create new diagrams or reports that will give them the information they need.
Notes
1 Tom Cargill, C++ Journal (http://www.ddj.com/cpp/cuj.jhtml)
2
http://www.omgsysml.org
3
http://www.uml.org
4
http://www.ibm.com/software/awdtools/developer/systemsdeveloper/index.html
5 No, of course it wasn't called CheeseGrater, but hey, I needed a system name. Did you want me to use Foo or Bar or Baz like everyone else? And by the way, that wasn't my idea -- thanks to Bob Wise for the original notion of using Cheese instead of Foo.
6
http://dictionary.reference.com/browse/model
7 Access via Windows > Preferences > Modeling > Views > Project Explorer
8
http://www.ibm.com/developerworks/rational/library/07/1211_hovater/index.html
Resources
About the author  | 
| | Jim Densmore is a regional practice lead for Solutions Architecture with IBM Rational. His responsibilities include enabling clients in the areas of organizational transformation and the engineering of complex systems. Before joining Rational as a sales team tech rep in 2000, Jim spent more than twenty years involved in the architecture, design, and development of high-fidelity, real-time combat simulations and real-time telecommunications software. He holds a BA from the University of California, Los Angeles, and an MS in computer science from the University of Maryland. |
Rate this page
| 
