Feb

12

Fundamentals of UML Modeling: Structural Diagrams

Posted by Keith McMillan

February 12, 2008 | Leave a Comment

This is the third in a series of posts on the fundamentals of Unified Modeling Language diagrams. The first two posts covered requirements diagrams and behavioral diagrams.

In previous posts in this series, we’ve discussed requirements diagrams (use case diagrams) and commonly used behavioral diagrams in the Unified Modeling Language (UML). This article is about the last category of diagrams: the structural diagrams, which are sometimes called static diagrams. I like to think of structural diagrams “pictures of the system standing still,” where the behavioral diagrams we already discussed are how the system behaves.If you’ve recall the behavioral diagram post, I mentioned then that forced to make a choice, I’d rather have a behavioral diagram than a structural diagram. I’m not changing my story, if I had to choose one, that’s what I’d choose. It’s not because structural diagrams aren’t important: structural diagrams have great utility in describing the design of software systems, they convey a lot of information in a compact form, but I can deduce structure from documentation and code much more easily than I can figure out behavior. I still think you should have these diagrams, having it written down saves us from having to go and figure it out, so they’re a good idea.

UML defines several types of structural diagrams:

That’s a lot of different types of diagrams, and as you might expect, there are some exotica in there. As we did with the behavioral diagrams, we’re going to focus on the most commonly used diagrams, in order of their frequency: class, package, deployment and component diagrams.

Class Diagrams

Class diagrams are a staple of every object-oriented design class, and they are the most commonly used structural diagram, so you may already be familiar with them. Class diagrams represent classes and their relationships to one another. The example class diagram below represents the relationship between features, requirements and products (and their versions) for a requirements management tool.

Sample Class Diagram

This type of diagram is a very information-rich way of communicating the design. Here are just a few of the things this diagram says to the reader:

Class diagrams shows what classes are related to other classes, how many there are allowed to be, what the navigability of the relationships are, and much more.

What some practitioners fail to realize is that there are in fact two different types of class diagrams, not formally recognized in the UML. The two types of diagram don’t vary in terms of their semantics, but they show very different types of information. The first type we just saw, it shows the expected relationships between objects. The statements I made above were about what I expected to have happen when I had an instance of the Project object: it should have features and releases and requirements.

The second type of class diagram shows inheritance, the “genealogy” of classes, rather than their expected relationships with other classes when an instance is created. Here’s a simple example showing inheritance of some of our classes from a “versionable” base class:

Sample Inheritance Class Model

While UML doesn’t say you should not mix and match these two types of views (relationships and inheritance) within a single diagram, they show very different types of information, and should be separated into different diagrams except in very rare circumstances. It makes perfect sense to talk about a project class being related to a release class, and to show both of these being related to a base “Versionable” class, but it gets very confusing if you show both in the same diagram, so this practice should be avoided.

Package Diagrams

The second most commonly used type of structural diagram is the package diagram. Package diagrams represent higher level structures, packages of functionality, and their interdependencies. These diagrams allow you to visualize the organization of software structures, which among other things lets you try to avoid cyclic dependencies. These occur when the dependencies between packages form a cycle, or loop. Cyclic dependencies are undesirable because they show that we haven’t done a good job isolating various parts of our system, and as a result changes in one area are more likely to spread to another area, or continue to propagate around the cycle. Here is an example package diagram (without cyclic dependencies):

Sample Package Diagram

Many UML modeling tools allow you to run reports to verify that you have not created relationships that violate explicit dependencies in your package diagrams, allowing you to sanity check your dependencies.

Package diagrams are a good way to get an overview of the structure of a software system. They can be created for various levels, for instance the “web interface” package shown above could be broken down in another diagram to show the various portions of the web interface, and their dependencies. This would allow you to drill in for more details of the hierarchical structure of the software.

Deployment Diagrams

Deployment diagrams show the nodes and devices in the deployment of a system. These diagrams only seen occasionally, as the deployment topology is frequently simple and well understood. This is a simple deployment diagram showing a typical web based application.

Sample Deployment Diagram

Deployment diagrams can be helpful to explain complicated or atypical deployment environments, but don’t feel bad if your environment is simple, and as a result you think you can do without one.

Component Diagrams

Component diagrams are similar to package diagrams, in that they show higher level structures, assembly units, and their relationships to one another. Assembly units can have elements from several different packages groups together into a component, such as a library, a framework, DLL, or a servlet. I’ve only run into component diagrams a handful of times in over a decade of working with UML, so their use can fairly be called “infrequent”. Here’s a sample component diagram showing the relationship between various components of a travel booking application.

Sample Component Diagram

Component diagrams are infrequently used, but can be handy when you need to show relationships between assembly units, rather than classes or packages.

Continuing Your Learning

I hope you’ve found this series of posts interesting and informative. If you want to learn more about UML, here are some books that will help you continue your studies.





Comments

RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll