1. Computing & Technology

Discuss in my forum

Interpreting the UML Modeling Language for Programmers

UML Behavior Diagrams

By , About.com Guide

Activity Diagrams

One of the problems that programmers have is that their code is inherently "static" - that is, it just sits there until the program runs. Then the programmer finds out all the things that can happen as control flows throughout the system with different data.

Activity diagrams are designed to analyze all this before the investment in writing running code is made. So an activity may be an operation on some class in the system that results in a change in the "state" of the system. But like other UML diagrams, they're not used to model individual programs most of the time. Activity diagrams are used to model workflow or business processes across the entire system.

  • Use Case Diagrams

Use case diagrams are probably the most common activity diagram because they're the most conceptual and the easiest to create. These charts are often used to make sure that system users and analysts are on the same page about what a proposed system will do. They're often put in front of programmers to tell them what the system should do. Usually, users are represented by "business process experts" who are assigned to the development team to make sure that systems actually do what the business needs.

The idea behind use case diagrams is to draw ovals, called "use cases", which describe some action that the system actually does. The persons, organizations, or external systems that interact with these use cases are called "actors" and are drawn as stick figures.

Another important function of use case diagrams is to specify the system boundary. That is, what actions are included inside the proposed system. This is one that you'll appreciate more in a real project where users tend to decide near the end of a project that the system absolutely must do some additional thing that they forgot to mention.

Here's a use case diagram for the Signature Block program drawn using Visio.

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

  • State Machine Diagrams

The "state" of an object has been described as what the object "knows" at a point in time. Another way to put that is that the state is a single set of the values that of all the properties can be. If even one property changes, then the object moves to a different state.

This can be a huge problem because, in general, if you have "n" different property values (a single property that could have five different values counts for five), then the number of states is n! (n factorial). A small system with a dozen property values would have almost 500 million states. You don't have to pay attention to all of these because most won't affect the way the system works. For example, if you change the background color of a Button, the Button still works the same way. (Unless you change the color to the same color used by the font. Then you can't see the text!)

The state machine diagram of the Signature Block program actually reveals some interesting behavior of the program that isn't completely obvious from the code. The illustration below shows that state machine diagram:

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

The other UML 2.0 activity diagrams are:

  • Sequence Diagrams

Describe interactions among classes. The messages sent between classes are shown in this diagram.

  • Interaction Overview Diagrams

This diagram is designed to show a control flow that has a specific purpose in the system.

  • Communication Diagrams

This is a variation of a the sequence diagram that emphasizes what is communicated rather than when it is communicated.

  • Timing Diagrams

Some objects behave differently within a time-scale. In a program for a timed test, for example, this diagram would show the timing of test processes.

As a programmer, think of a system model as being something like your office. If you work in a networked office, you know that a lot of work gets done by people sending each other messages. Objects are the same way. People and objects have things they know (these are properties) and things they can do (these are methods). And if you understand how the office works, getting something done is a lot easier.

©2012 About.com. All rights reserved.

A part of The New York Times Company.