Chapter 8 – Behavioral Modeling

Recap:

In previous chapters we have learned

(1) Use case modeling (external functional viewpoint = user’s viewpoint or “how the system appears to function when observed from the outside”) (Chapter 6)

(2) Structural modeling (internal structural viewpoint = the object structure of an information system or “how objects relate to one another in terms of their properties such as class, attributes and methods”) (Chapter 7)

Revisit: Chapter 7, Object diagrams (page 198). Object diagrams are views of information contained in class diagram. Views can be class subsets, subsets of relationships, or subsets of information. Goal is clarity of presentation.

This chapter:

In this chapter we will learn the UML models that are used in behavioral modeling (internal dynamic viewpoint = sequence; collaboration; or changes in underlying data; or “what are sequences of methods):

(1) Sequence Diagrams (internal view of the business process) (interaction diagram)

(2) Collaboration Diagrams (internal view of the business process) (interaction diagram)

(3) Statechart Diagrams (changes in underlying data)

One of the primary purposes of behavioral models is to show how the underlying objects in the problem domain will collaborate to support each use case.

Logical models.

Holism.

Iterative process. Revising use cases; structural models and behavioral models until system is satisfactory.

Step 1: with team -- Interaction Diagrams: Sequence Diagrams

Sequence diagrams illustrate the objects that participate in a use case and the messages that pass between them over time for one use case.

Principle: Structural modeling is at the class level (Chapter 7). Behavioral modeling is at an object level (Chapter 8).

Objects receive messages. Messages tell an object to execute one of its behaviors.

Message is a function, a procedure call from one object to another.

Sequence diagrams illustrate the objects that participate in a use case and the messages that pass between them over time for one use case.

A sequence diagram is a dynamic model that shows the explicit sequence of messages that are passed between objects in a defined interaction.

Time based ordering of activity.

Generic sequence diagram shows all possible scenarios.

Instance sequence diagram shows depicts a single scenario.

(Scenarios correspond with scenarios in use cases see page 153).

Elements of a Sequence Diagram

See Figure 8-1 (p. 218) Instance Sequence Diagram.

See Figure 8-2 (p. 219) Sequence diagram syntax.

See Figure 8-3 (p. 221) for 6 steps for building Sequence diagrams.

Step 2: with team – Collaboration diagrams

Collaboration diagram essentially is an object diagram that shows message passing relationships instead of aggregation/generalization relationships.

Like sequence diagrams.

Difference:

Sequence diagrams emphasize time ordering of the messages being passed.

Collaboration diagrams emphasize the flow of messages through a set of objects.

Sequence diagrams used when desirable to understand time ordering of the messages.

Collaboration diagrams used when desirable to understand interactions among a set of collaborating objects.

Which diagrams you should use depends on what you wish to understand, clarify and/or communicate.

Elements of Collaboration Diagram

See figure 8-6 Example Collaboration Diagram on page 224.

See figure 8-7 Collaboration Diagram Syntax on page 225.

Building a collaboration diagram. See figure 8-8 on page 226.

Identifying potential collaborators. CRUD analysis. See figure 8-9 on page 227.

Step 3: with team – Statechart Diagrams

A statechart diagram is a dynamic model that shows the different states that a single object passes through during its life in response to events, along with its responses and actions.

Statecharts typically not used for all objects.

Statecharts are used to understand complex objects to help simplify the design of algorithms for their methods.

CRUD analysis (see page 226) can be used to identify complex objects that require statecharts. The more C, U, D entries in the column associated with a class, the more likely it is that a class has a complex life cycle and requires statecharts.

More UML vocabulary (this time with definitions attached…):

n State (value of its attributes and relationships with other objects at a point of time; not all attribute changes make a difference).

n Event (something that takes place in a certain point in time and changes a value(s) that describes an object, which in turn changes the object’s state).

n Transition is a relationship that represents the movement of an object from one state to another.

o A guard condition is a Boolean expression that includes attribute values, which allows the transition to occur only if the condition is true. An object typically moves from one state to another based on the outcome of an action that is triggered by an event.

o An action is an atomic, nondecomposable process that cannot be interrupted. (user viewpoint: zero time, cannot be interrupted).

n Activity is a nonatomic, decomposable process that can be interrupted (it has steps that can be articulated and articulated as states).

Elements of a Statechart Diagram:

See figure 8-11 Example Statechart Diagram (p. 230).

See figure 8-12 Statechart Diagram Syntax (p. 231).

Steps for Building Statechart Diagrams (p. 231).