State Diagram


State diagrams show the internal workings and life cycles of your objects. For instance, each software object is born into the runtime environment, lives a life interacting with other objects, and then dies out. State diagrams capture these important moments in time, including the event transitions for your objects. The states themselves capture what your objects are supposed to do after an important event.

 Tip   We build state diagrams for objects that are dynamic. In other words, they change a lot during their life. In general, you can build a state diagram for the following kinds of objects:

  • Controllers: Those objects that control the timing and behavior of other objects are called controllers—the objects that know when to get things done to meet the goals of your system. This type includes objects that make each use case work properly as well as objects that must start up and shut down your system. Each of these objects exhibits complex behavior that must be done in the right order at the right time.

  • Event handlers: If an object must receive events and then (as a result of the events) ask another object to actually perform the needed work, the object that has this job deserves a state diagram. Use the state diagram to show the allowable sequence of events and the resulting behavior.

  • Aggregations: When you have an aggregate with many parts, the object that represents the aggregate has an interesting life. At first, the aggregate must create instances of its parts. It then must receive requests from the outside and pass them off to the appropriate part(s). When the aggregate is deleted, it must first delete its internal parts in the right order and then (and only then) delete itself. You should capture the complex life cycle of an aggregate with a state diagram. (See Chapter 5 for more on aggregates.)

  • Dynamic domain: Every user domain has at least two or three dynamic objects. For instance, an insurance policy goes through many states in its life—open, established, claim processing, canceling, archived, and closed (to name a few). Look at each of your domain classes and think about their life cycles. If those look interesting, build a state diagram that describes them.




UML 2 for Dummies
UML 2 For Dummies
ISBN: 0764526146
EAN: 2147483647
Year: 2006
Pages: 193

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net