More Symbols, More Diagrams, More UML: Beyond Class and Interaction Diagrams

Other types of diagrams defined in the UML specification may be less directly related to Java source code than the more glamorous class and interaction diagrams, but your UML toolkit is incomplete without them. In this fifth and final article in a series introducing UML from a Java programmer's perspective, Stephen Palmer takes a brief look at the other five diagrams defined in the UML specification.

Like this article? We recommend

Like this article? We recommend

Welcome to the fifth and final article in a series that introduces UML and
object modeling from a Java programmer's perspective. In the previous
articles, we introduced UML class, sequence, and collaboration
diagramscomparing their contents to classes, interfaces, and methods in
the Java programming language. In this article, we move on to briefly consider
the other types of diagrams defined in the UML specification. These diagrams may
be less directly related to our Java source code than the more glamorous class
and interaction diagrams, but our UML toolkit is incomplete without them. These
diagrams tend to be the subject of great debate about their use and
appropriateness for different circumstances. The important thing is that the
benefits to the development team of producing these diagrams should outweigh the
cost of doing so. If this is not the case, then reduce their use or stop using
them altogether.

State Chart Diagrams

The UML state chart, which is based on the work of David Harel, adds the
concepts of nested and concurrent states to the basic finite state machine that
most computer science students meet at some point in their studies. The item
being described by a state chart is considered to be in one of a number of named
recognizable states, and moves between those states as named recognizable events
occur. State charts can be used to describe anything that fits this profile of
behavior, including user interfaces and simple business processes. However, in
UML they are most frequently used to describe the internal life-cycle of objects
belonging to a specific class. Good examples are the state charts used to
describe the life-cycle of Entity, Session, and Message beans in the Enterprise
Java Bean (EJB) specification1.

State Charts and Source Code

A class whose behavior is described by a state chart can be implemented in a
variety of ways, including the following:

Hard-coding operations to act differently, depending on the value of a
status attribute.

Using lookup tables to determine the next state of an object, given the
current state and the event that has occurred.

Using a variant of the State Pattern described in the Design
Patterns2 book, in which each state is represented by another
class.

Given a particular implementation approach, state chart drawing tools can be
used to generate source code, and many such tools exist to do exactly this.
However, I don't know any tools that can be pointed at any body of Java
code and derive state charts from it in the same way tools can reverse-engineer
class and interaction diagrams.

Using State Charts

As with all UML diagrams and concepts, there is far more detail than can be
described in a few short paragraphs. State charts are powerful and complex
enough to fill several books of their own.

State charts are frequently used to define the behavior of technical
architecture and infrastructure classes. State charts are also very popular in
real-time and communication systems, and play important roles in many real-time
software development processes. OCTOPUS is one such method3.

However, state charts tend to be less popular, and are used less often in
business systems for two reasons.

First, business people tend to find state charts much harder to analyze than
color-coded class diagrams, traditional flowcharts, or UML activity diagrams.
This makes it harder to confirm that a system meets the client's
requirements.

Second, business processes and the systems that automate them are often less
defined than their real-time or communication counterparts. After all, people
are fundamentally involved in most business processes, and the involvement of
people in anything always complicates matters. Systems that automate business
processes often need to remember the history of events and activities that take
place instead of just worrying about the current state of the process. They also
need to handle partially complete activities, early recording of data for future
events, and manual override of business checks and rules. This can significantly
complicate the use of state charts to the point where the benefits are
outweighed by the complexity of handling all the exceptional conditions.