The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Getting Started

Consider the investor who finances the building of a new high rise. She is unlikely to be interested in the details of the building process. The selection of materials, the scheduling of the trades, and the many meetings about engineering details are activities that are important to the builder, but far less so to the person bankrolling the project.

The investor is interested in getting a good return on the investment, and that also means protecting the investment against risk. A very trusting investor will give a builder a pile of money, walk away for a while, and return only when the builder is ready to hand over the keys to the building. Such an investor is really interested in the final state of the building.

A more pragmatic investor will still trust the builder, but will also want to verify that the project is on track before releasing money. So, rather than give the builder an unattended pile of money to dip into, the prudent investor will set up clear milestones for the project, each of which is tied to the completion of certain activities, and only after meeting each one will money be released to the builder for the next phase of the project. For example, a modest amount of funds might be released at the project's inception to fund the architectural work. After the architectural vision has been approved, then more funds may be released to pay for the engineering work. After that work is completed to the project stakeholders satisfaction, a larger pile of money may be released so that the builder can proceed with breaking ground.

Along the way, from ground breaking to issuance of the certificate of occupancy, there are other milestones. Each of these milestones names a stable state of the project: architecture complete, engineering done, ground broken, infrastructure completed, building sealed, and so on. For the investor, following the changing state of the building is more important than following the flow of activities, which is what the builder might be doing by using Pert charts to model the workflow of the project.

In modeling software-intensive systems as well, you'll find that the most natural way to visualize, specify, construct, and document the behavior of certain kinds of objects is by focusing on the flow of control from state to state rather than from activity to activity. You would do the latter with a flowchart (and in the UML, with an activity diagram). Imagine, for a moment, modeling the behavior of an embedded home security system. Such a system runs continuously, reacting to events from the outside, such as the breaking of a window. In addition, the order of events changes the way the system behaves. For example, the detection of a broken window will only trigger an alarm if the system is first armed. The behavior of such a system is best specified by modeling its stable states (for example, Idle, Armed, Active, Checking, and so on), the events that trigger a change from state to state, and the actions that occur on each state change.

In the UML, you model the event-ordered behavior of an object by using state diagrams. As Figure 25-1 shows, a state diagram is simply a presentation of a state machine, emphasizing the flow of control from state to state.