Having set the stage with class diagrams, we'll now look more closely at what is likely to happen on that stage. We examine life cycles and (with the assistance of IT staff) interactions between all the small parts within the system.

State Diagrams

Some business entities have interesting life cycles because of real-world regularities and constraints, such as business rules, legislation, laws of nature, and so forth governing their “lives.” Because these business entities are represented by a class, we model this dynamic aspect in a state diagram per class.

In most enterprises, some key business entities have an interesting life cycle, which makes a state diagram necessary. These examples show the key states (life-cycle phases) for certain key entities in different industries:

• Banking: Account (in_credit – overdrawn – blocked – overdrawn and blocked – closed)

• Travel: Reservation (registered – on waiting list – reserved – paid)

• Brokerage, shares, bonds: Order (placed – activated at desired price – deal-confirmed – closed)

• Insurance: Retirement plan (employed – payment-aged – retired – deactivated)

We find such key entities in practically any business. The latter example simply mirrors the life cycle from a retirement plan point of view.

Strengths

A state diagram is a compact, yet quite intuitive, notation. These diagrams are versatile because they can mirror the lifetime dynamics of a rather long “life” in the kernel of an enterprise system, as well as a rather short “life” in a user dialogue or in a real-time system.