Ordering the Flow of Behavior


When you want to explore the flow of behavior across classes, use an activity diagram. Although your class diagrams (see Chapter 3 and Chapter 7) tell you who performs what operations, they don’t show a valid sequence of operations across classes. If you build a state diagram (see Chapter 16), you show a sequence of operations—but a state diagram limits you to the operations within a single class. The activity diagram, on the other hand, allows you to show the flow of behavior across multiple classes. Use activity diagrams whenever you want to show object flow, dataflow, or the flow of control across different classes.

Dissecting an activity diagram

All activity diagrams have a few basic elements. Normally you use the following pieces to diagram the flow of behavior:

  • Action: A simple piece of behavior is called an action. An action cannot be further decomposed into smaller actions. You can specify pre- and postconditions for an action—defining what must be true before the action can execute and what must be true after the action executes. An action could be any of the following:

    • Getting or setting an attribute value

    • Invoking the operation of another class

    • Calling a function

    • Invoking an activity that contains actions

    • Sending a signal or notification of an event to a group of objects

    You show an action in UML notation as a rounded rectangle. Place the name of the simple behavior as text inside the rounded rectangle.

  • Activity: Activities contain sequences of actions and/or other activities. You use activities to group sequences of actions together. At the level of an object-oriented class, you can use an activity to represent the method of an operation. You can also use activities to represent the tasks that make up a business process.

    You diagram an activity as a rounded rectangle with the name of the activity inside (as with an action). You can also show activities in a large rounded rectangle containing complex sequences of actions, activities, object flows and control flows. The complex form of an activity also allows you to show parameters, preconditions, postconditions, and properties of the activity.

  • Control flow: Think of control as moving like a stream that connects actions and activities together; shows the sequence of execution.

    Connect your activities and actions with a line that has an arrowhead to indicate the direction in which control is flowing. For example, you draw a control flow from an activity like Browse Book to an activity such as Make A Note.

  • Object node: Your classes’ operations take in parameters and generate return results. Activities modify objects or transform objects into other objects. You use an object node to show these objects as they move from activity to activity.

    You use a class box with the name of the object’s class to show an object node. You can also describe the state of the object by including the name of the state in between square brackets underneath the name of the class.

  • Object flow: In the old days, this was known as “data flow.” Now the experts call the flow of objects, object flow. You use activity diagrams to show this flow of objects from one activity or action to another.

    You place an object node between two activities or actions to show object flow. Connect the first activity or action with a line and an arrowhead in the direction of the object node. Then connect the object node to the second activity or action with a line and an arrowhead in the direction of the second activity or action.

  • Control node: You use control nodes to guide the flow of control (and the flow of objects) through a group of activities and actions. Control nodes come in a variety of forms, depending on what you need; they serve as traffic cops for the flow of control and flow of objects. The control nodes are as follows:

    • Initial: You start a sequence of activities or actions with an initial node. An initial node is shown as a large dot.

    • Final activity: When you want to end all control flows and object flows in an activity, use the final-activity node. Show final activity with a bull’s-eye symbol.

    • Final flow: If you want to end some—but not all—flows inside an activity, use the final-flow node. You show a final flow as a small circle with an X inside.

    • Decision: A decision node uses a test to make sure that an object or control flow goes down only one path. Use this node when you want to construct an if-then-else selection for an execution path. You indicate a decision node with a large diamond shape. Connect the diamond with each downstream activity or action by drawing a control-flow arrow. Place decision criteria for each path in square brackets on the control flow line.

    • Merge: You bring separate decision paths back together with a merge node. Show your merge using a large diamond shape. This is the same shape as a decision node. Decision nodes create divergent control paths through an activity diagram. The merge node allows you to bring those divergent paths back together again following a decision node. Merge nodes do not have any decision criteria in square brackets.

    • Fork: Sometimes you need activities or actions to work in parallel. To split behavior into concurrent operations, use the fork node. A fork looks like (you guessed it) a fork. You show a fork with one line going into the fork and multiple lines coming out the other side.

    • Joins: A join is the opposite of a fork. When you want to bring parallel flows of operations back together, use the join, a symbol that looks like the mirror image of a fork.

    • Connector: If you run out of room on your diagram and you need to continue the flow of control to another page, use a connector —a small circle with a label inside. The connector indicates that the flow picks up at another location in the diagram or on another page where you find a connector with the same label.

 UML2   Older versions of UML had activity diagrams, but UML 2 takes this diagram to a new level. Previously, activity diagrams were a special kind of state diagram. You could show flow of control across classes—from one operation to another—but the diagram limited the kinds of flow you could show. UML2 provides activity diagrams that act like a Petri net—a flow that works kind of like a pinball machine: Instead of silver balls, objects known as tokens (which represent other objects or the presence of control) can bounce from node to node (that is, flow from activity to activity). In UML 2, activities and actions consume tokens and produce tokens—so now you can construct pure flow diagrams that pass the tokens around.

Utilizing activity diagrams

We recommend using activity diagrams in several different situations:

  • High-level operations: When you have a class with a complex operation that involves many steps, use an activity diagram to show those steps as a sequence of activities.

  • Use-case details: If one of your use cases is really a group of steps performed concurrently, use an interaction-overview diagram—a form of activity diagram that shows the flow of interaction between the main success scenario and any alternative scenarios. We show you an example interaction overview diagram a little later in this chapter.

  • Workflow or business-process flow: Activity diagrams are great for modeling business processes, not just software operations. You show who performs activities, which decisions must be made, and what documents the business process generates.

  • Process modeling: Since activity diagrams are the latest form of the good old data-flow diagram, you can use them to model any process. You model the steps in a process as activities and show sequencing with control flows and control nodes.

  • Summarize many sequence diagrams: If you find yourself generating lots of sequence diagrams for a use case—usually to make sure you capture all allowable orderings of events—then consider creating an activity diagram to summarize those sequence diagrams. The complex behavior of your use case—with its concurrent sequences—may be easiest to grasp as an activity diagram.

 Warning   Avoid the function trap. If you use the activity diagram as a way to pick apart functions into subfunctions (and the subfunctions into subsubfunctions), then beware—you may have fallen into the “functional decomposition” trap that lies in wait for anyone who builds object-oriented systems and software. After all, your system or software is composed of objects, not functions. Each object has a responsibility to perform certain behavior when asked. Functionality emerges from the collaboration of objects invoking behavior on each other. To avoid the functional trap, keep in mind who performs each action and who is responsible for each activity.

Figure 13-1 and Figure 13-2 illustrate the basic use of activity diagrams to document a high-level operation. This example focuses on the planTrip operation of the Person class. The operation takes one parameter—travelBooks : Book[0..*]. When you invoke the planTrip operation, you pass in zero or more instances of objects called travelBook—instances of the class Book. When planTrip completes, it returns an instance of the Itinerary class. The Person class has the needs attribute with the NeedKind datatype. NeedKind is a datatype that enumerates the different needs a person may have. Those needs are shown in the NeedKind class stereotyped with «enumeration».


Figure 13-1: The Person class with a high-level operation: planTrip.

Suppose a person like you needs a vacation (no challenge there). To plan a trip, you get your hands on several travel books and browse each book. If you have an interest in the locations discussed in one of the books, you take some notes, look into the location in more detail via the Internet, and call some friends. After you settle on a place to go, you make reservations and end up with an itinerary. Figure 13-2 captures your behavior for planning a trip in an activity diagram.


Figure 13-2: Activity diagram for planning a trip.

The name of the complex activity—Plan Trip—is shown in the large, rounded rectangle in the upper-left corner. You show parameters underneath the name of the activity. In this example, the travel-book parameter is shown as travel book: Book. You show pre- and postconditions in an activity close to the name of the activity, in the form of text preceded by a stereotype of the right type. Figure 13-2 shows the need vacation as a precondition and complete itinerary as the postcondition.

 Remember   You name activities with a verb phrase. Your activities express some behavior that an object or objects will perform. Just like use case names (see Chapter 3), activity names are best stated as an action verb followed by a noun or simple noun phrase.

 Tip   Whenever you have a complex operation, declare the pre- and postconditions for the operation. Preconditions describe what must be true before the operation can execute. Postconditions express what is true after the operation completes successfully.

After you determine which objects(s) flow into an activity (you identify them via parameters) and the object(s) that an activity returns (you identify them via operation result types), place them on the outside contour line of the rounded rectangle. Diagram incoming objects as object nodes inside a class box. The Plan Trip activity has an incoming Travel Book object node on the contour line of the activity. Any outgoing objects are also shown as class boxes. The Itinerary object node is also shown on the contour of the Plan Trip activity.

As a modeler, you can reveal activities, actions, flow, and control nodes inside the border of a complex activity, as we did in Figure 3-2. In the example, you see a sequence of steps—Browse Book, Make a Note, Check Internet, Call a Friend, and Make Reservation—in order to plan a trip. You show each step in a rounded rectangle. Flow of control passes from activity to activity along the lines in the direction of the arrow. For example, control flows from Make a Note to Browse Book after the Make a Note activity finishes.

In this example, we use several control nodes to further guide the flow of objects and the flow of control. For instance, a diamond-shaped decision node directs flow of control according to whether the person planning a trip is interested in the contents of a travel book he or she has finished browsing. If the person is interested, then control flows onto the Make a Note activity. If the person is not interested, then control flows to a final flow node—the X in a circle.

 Remember   As you look at an activity diagram, visualize objects flowing down a path like balls in a pinball machine. For example, a travel-book flow begins as follows:

  1. Into the Plan Trip activity.

  2. Moves to the Browse Book activity.

  3. When the Browse Book activity finishes, the travel book is passed on to the decision node:

    • The decision node tests the interested condition. If the condition is true, then the book moves on to the Make a Note activity. If this condition is false, then the decision node tests any other conditions attached to it.

    • The decision node tests the not interested condition. If the condition is true, then the book moves on the final flow node—where it disappears. The job of a final flow node is to remove any objects that flow into it.

From here, the flow continues on through the rest of the complex activity.

Your activities can generate new object nodes. For example, Make a Note generates instances of the Travel Note class. These travel notes are passed on, like balls in a pinball machine, to other activities.

 Tip   If you have activities that happen concurrently, use a combination of fork and join control nodes. In the example, Check Internet and Call a Friend are activities that happen at about the same time but are independent of each other. Above these two activities is a fork control node—a thick horizontal line with one control flow line coming into it and two control flows coming out the bottom. The flow of control comes back together into a single path with the use of a join control node shown below these two activities.

 Remember   Concurrent does not mean simultaneous. Concurrent activities may occur at the same time, but they are always independent of each other; one concurrent activity could start before other concurrent activities and end before they are complete.




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