More Symbols, More Diagrams, More UML: Beyond Class and Interaction Diagrams
- State Chart Diagrams
- Activity Diagrams
- Use Case Diagrams
- Component and Deployment Diagrams
- Packages
- Conclusion
Like this article? We recommend
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.
Figure 1 shows a state chart for a simplistic Point of Sale terminal.
)
Figure 1 UML state chart.
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.