If you've never used the Uniform Modeling Language (UML) before, it can seem a little intimidating. However, UML is actually not all that difficult, once you get to be familiar with the different diagrams and how they can help you to model and document your project. This article takes you through the process of modeling an application using UML, explaining each of the different diagrams, and the basics of how they work. When you're done, you'll have enough of an understanding of UML to document your own project. You'll also have enough of an understanding to delve into UML's finer points without feeling overwhelmed.

To demonstrate the power and capabilities of UML, I use it to model the design of Chaos Crusher, an application that reads syndicated RSS (and Atom, and whatever else comes along) feeds. In future parts of this series, I'll show you how to build the GUI interface using C++, interact with XML, work with databases, and other necessary tasks.

For this article, I'm not assuming familiarity with any particular programming language. You don't even have to be an expert at object-oriented programming, but it will help if you understand concepts such as class, object, interface, and inheritance.

First let's talk about the actual application.

Now, I don't know about you, but information overload caught up with me about five years ago. No matter how organized I tried to be, I just couldn't keep up with all of the different mailing lists and Web sites I wanted to read every day. And that was back before the advent of weblogs, or blogging, in which an ordinary non-programmer person can easily keep a journal online, typically pointing to even more interesting things to look at. These days, it seems like everybody and his cat has a blog, and I've given up trying to visit all of my favorites on a regular basis.

That's not to say that I don't read them, however. No, the world of blogging has brought to prominence another technology that helps to spread the word: syndication. News sites, bloggers, and really anybody who has information that changes regularly can syndicate their content by creating an XML file that provides information about what's available. Software programs called "feed readers" can read and analyze these XML files to find out what people are talking about. These feed readers typically act as personal aggregators, displaying all of the feeds you follow in one place and even telling you what you haven't read yet, saving you the trouble of visiting a hundred different sites every day just to find out that three of them have new content you're actually interested in.

This, of course, presents its own problems. Now instead of having a few sites I'm compelled to visit every day, I have, say, 100 feeds I follow. At an average of 15 entries per feed, that's as many as 1,500 items to review every day. That's not making things any better, thanks!

So in this series of articles, I'm going to build a feed reader that (hopefully) solves my information overload problems. The Chaos Crusher FeedReader will be written in C++ using .NET, and will provide the following features, to be chronicled in subsequent articles:

• An easy-to-use GUI interface
• Ability to retrieve an feed from the Web in multiple formats, including RSS and Atom
• Ability to easily add new formats
• Ability to analyze and transform received XML
• Ability to sort feed entries by blog, date, read or unread status, or referenced links
• Ability to save feeds and entries to and retrieve them from an SQL database
• A Web browser launched from or embedded within the application

But having said all that, I can tell you that in this article, we will do no coding at all. No, instead, we'll start by analyzing the application and documenting it using the Uniform Modeling Language, or UML.

I'll tell you right now that UML is a big language. It's got no less than thirteen different diagrams and the reference manual for it, The Unified Modeling Language Reference Manual, Second Edition, by James Rumbaugh, Ivar Jacobson, and Grady Booch, is 752 pages long.

Wait a minute, don't get nervous about that. There are two very nice things about UML:

1. You don't have to use all of it.
2. The parts you do decide to use are straightforward once you get to know them.

Let's start by talking about what Unified Modeling Language actually is. Literally, it is a way of talking (Language) about the overall form and structure of something (Modeling) that everybody can agree on (Unified). In other words, it's a way to describe your application that everyone can understand.

Now, when we talk about modeling, we're talking about something that represents the real thing, but isn't actually the real thing. One analogy that gets used a lot is the idea of blueprints. A blueprint isn't actually the building, but a builder can take the blueprint and make a building out of it. In the same way, many UML tools can take your model and create a basic application out of it. (We're not going to go that route, but it helps to know you can.)

Another reason blueprints provide a good analogy for UML is that a single project typically has several different versions of the blueprints. One may be for the builders, one for the electrician, one for the plumber, all showing what's relevant to the person in that role in a way that makes it easy for him or her to understand it. UML provides the same capabilities, with several different "views" of the same application. For example, the "Use Case View" provides a way to understand who's using the application and what they can actually do with it, while the "Interaction View" shows the different pieces of the application and what kinds of messages, or interactions, they have with each other. Each view has its own set of diagrams, and it's easy to get caught up in which diagram belongs to which view.

We're not going to do that. UML is a language that is meant to be used, not precisely quantified. Even its authors will tell you that because it's meant for widespread use, it's messy and sprawling. They even come right out and say "It is unnecessary to listen too much to UML language lawyers. There is no single right way to use it."

So I'm just going to dive in and show you how you can use it to document the thought behind an application from concept to final deployment.

We'll start by figuring out just what we want the thing to do.

Simply put, a Use Case is a function that someone or something must be able to perform using the system. After all, you can have the coolest application in the history of programming, but if nobody can do anything with it, what's the point?

So what are the anticipated use cases for Chaos Crusher? Well, I expect that an end user, or "actor," needs to be able to perform several functions relating to feeds, such as adding and removing them, updating them, and sorting and reading entries. I can turn that into a Use Case Diagram, as in Figure 1:

Figure 1: A simple use case diagram

Let's look at what we have. First of all, stop laughing at my End User graphic, that's the UML symbol for an "actor."  An actor is anyone or anything that interacts with the system. Here it's an end-user, but in other situations, it might also be another application or another server. In a more detailed use case diagram, you might have several different actors, such as an administrator, an editor, and a janitor.

Each oval represents one use case, or function the actor must be able to perform. In this diagram, each use case is straightforward and self-contained, but it doesn't have to be that way. In UML, one use case can also extend or include another.

Now that we know what we want to do, let's look at documenting how to do it.

Activity Diagrams

Long before UML hit the scene, programmers were mapping out what they wanted to do using flowcharts. Flowcharts provided a simple way to document alternatives and what should be done about them. For example, Figure 2 shows a simple flowchart documenting my breakfast.

Figure 2 flowchart2a.gif

Figure 2: A simple flowchart

Flowcharts provide a way to show what happens, and to provide decision points. At each diamond, which path you take depends on the answer to the question. Other than that, you follow the arrows and take whatever steps are shown in the flowchart.

Flowcharts survive in UML in the form of activity diagrams, which enable you to state what should happen, and how to react to various conditions (and decisions). For example, consider the activity diagram in Figure 3.

Figure 3: An activity diagram

This activity diagram documents what should happen when the user adds a new feed for Chaos Crusher to process. We start with a solid circle, which represents the initial state. From there we move on to the first activity, User Enters Feed URL, in the rounded rectangle, and the second activity, GUI Retrieves Feed Text. From there we have a decision point, as indicated by the diamond. From the decision point, we can go in one of two directions, each of which has a guard condition. That means you can only go that way if the guard condition is true. If the feed is OK, we can move on to FeedReader Analyzes Feed. If there's a Feed Error, we move on to GUI Displays Error.

Notice that any time we branch off from a decision, as we did here, we need to merge the two flows back together with another diamond. Follow the flow from GUI Displays Error and you'll see how that works.

Assuming that there are no problems with the feed, Chaos Crusher analyzes the feed, determining whether it's in the "standard" format or whether we need to massage it a little before moving on. (There are no fewer than 10 RSS formats, plus at least one version of Atom, all of which we want to handle eventually. We'll do that by using XSLT to transform "nonstandard" feeds into one common format.)

Once we have the feed in the appropriate format, we need to both display the information and save it to the database, so we'll use the horizontal line to represent a fork. Once the simultaneous flows are finished, we can join them together with another horizontal line. (If your diagram needs it, you can use a vertical line instead.)

At the end of the process, we have a circle with a dot in the middle, representing the final state.

In this case, we assumed that even if there were an error, we'd continue on to the end of the activity. You could, however, specify an "interrupt" in the case of an exception, using a little lightning bolt instead of a straight arrow, as shown in Figure 4.

Figure 4: Showing an interrupt in an activity diagram

You can also use activity diagrams to show different realms of responsibility by using swimlanes. Swimlanes don't change the actual flow of the diagram, just how it's laid out on the page, as you can see in Figure 5:

Figure 5: Using swimlanes with an activity diagram

When you use a diagram with swimlanes, users, programmers, or other individuals involved can easily see what person or component is responsible for what activities.

For reasons of space, I'll leave it here, but in designing a complete application, you'd likely do a detailed activity diagram for each use case, as I'll do for Chaos Crusher. Note that I said "likely". There's no rule that says you have to document every part of your application using every available diagram.

Now let's start looking at the actual structure of the application.

Next: ' Class, Object, and Package ' >>

Discuss Creating a GUI Feedreader using C++, Part 1: A No-Brainer Guide to UML   >>> Be the FIRST to comment on this article!

>>> More Techniques Articles          >>> More By Nick Chase