11.2.3 Behavior Diagrams

(Apologies for the formatting problems in this posting. The editor is scrambling the input formats and won't change.)

Three of the eight behavior diagrams are discussed with examples in this section.

Activity Diagram - An activity diagram shows the flow from activity to activity within a system.  An activity shows a set of activities, the sequential of branching flow from activity to activity, and objects that act and are acted upon.  Activity digrams are used to illustrate the dynamic view of a system and are important in modeling the function of a system.  Activity digrams essentially are flow charts and emphasize the flow of control among objects.  Figure 11-4, shows a possible activity diagram for Taking a Picture in the digital camera system.

Figure 11-4 Example Activity Diagram for a Digital Camera System

Activity diagrams can also include forks to describe conditions and parallel activities.   A fork is used when multiple activities are occurring at the same time.  As shown on the diagram , all branches at some point are followed by a merge to indicate the end of the conditional behavior started by that branch. 

Activity diagrams should be used in conjunction with other modeling techniques such as sequence diagrams and state machine diagrams.  The main reason to use activity diagrams is to model the workflow behind the system being designed.  Activity Diagrams are also useful for: analyzing a use case by describing what actions need to take place and when they should occur;  describing a complicated sequential algorithm;  and modeling applications with parallel processes^11-4.  Software engineers have also found them to be useful for scientific software development.

Sequence Diagram - A sequence diagram is an interaction diagram that emphasizes the time ordering of messages.  A sequence diagram shows the objects and the messages that go between those objects at a particular instance of time.  They are used to illustrate the dynamic view of a system.  An example of a possible sequence diagram for the digital camera system is hown in Figure 11-5.

Figure 11-5 Example Sequence Diagram for a Digital Camera System

As shown in the diagram, an object has veritical lines called lifelines which represent the existence of an object over a period of time.  The stick figure represents an actor, the Picture Taker.  The messages become method calls when translated into executable software.  The focus of control represents the period of time during which an object is performing an action directly or through a subordinate operation.  Other graphic elements used in a sequence diagram can be found in the UML specification at http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

Sequence diagrams can be used at all levels of defining a software system – Use Cases down to a detailed software function.  Although sequence diagrams are typically used to describe object-oriented software systems, they are also extremely useful as system engineering tools to design system architectures.

State Machine Diagram - A state machine is a behavior that specifies the sequence of states an object goes through during its lifetime in response to events, together with its response to those events.  A state machine diagram shows the state machine, consisting of states, transitions, events, and activities.  These diagrams are used to illustrate the dynamic view of a system.  These are important when modeling the behavior of an interface, class, or collaboration and are useful when modeling reactive systems.  Figure 11-6 shows a state machine diagram for the Shutter Object.  When the button on the camera is pushed to take a picture, the Shutter object moves from the Opened state to the Closed state.  Once the button is released, the Shutter Object moves back into the opened state. 

  

Figure 11-6 Example State Machine Diagram for a Digital Camera System

Note that a transition from one state to another could be a signal, an event, a change in some condition, or the passage of time.  A state machine diagram may have a transition back to its own state.  At its simplest, an object within a software system has two states, idle or running.  When defining a software system, state diagrams are very beneficial for defining complex objects and how they behave.

Use Case Diagram – A Use Case Diagram is a diagram that shows a set of use cases and actors and their relationships.  A Use Case is a description of a system’s behavior as it responds to a request that originates from outside of that system.  It provides context to what is within a system and what interacts with a system and defines the behavior of the system when it receives external stimuli (i.e. the goals of the system).   A system is made up of multiple Use Cases to define the behavior of the overall system.  Use Cases were first defined in 1987 at the Proceedings of OOPSLA^11-5 by Ivar Jacobson for use in Software Engineering to define functional requirements.  Ivar Jacobson, et al, later published a book titled Object-Oriented Software Engineering: A Use Case Driven Approach in 1992^11-6 based on his experiences with Use Cases while working on large telecommunications systems.  Figure 11-7 shows a Use Case Diagram for the simple Digital Camera System.

Figure 11-7 Example Use Case Diagram for a Digital Camera System

The Picture Taker and the Printer are outside the boundary of the system being defined and are called Actors.  Take Digital Picture, Print Picture, and Delete Picture are all use cases within the system (i.e. functions the Digital Camera performs).  When developing Use Cases, all Actors are described as “nouns” while the Use Cases are “verb phrases” that describe an action the system performs.  The arrow on the association line indicates initiation of interaction.  If either the Use Case or the Actor can initiate interaction, then there is no arrow on the relationship line.  There can be two types of actors depicted on a Use Case diagram:  Primary Actors which benefit from the Use Case (arrow from Actor to Use Case) and secondary actors which participate in the system but don’t get benefit (arrow from Use Case to Actor).

Use Case modeling not only includes the model, but also written text to describe how the system behaves when the external Actor stimulates the system.  Typically a Use Case template is defined so all needed information is captured on how the system behaves.  One example of a Use Case template for capturing the behavior of a system is shown in Figure 11-8.

 Figure 11-8 Example Use Case Template

When starting Use Cases, it’s advisable to keep the description at the top-level at first and add details as the Use Case is better understood. Typically a Use Case is started with the normal flow of events; alternate and exception paths are added if needed.  One of the strengths and a significant benefit of Use Cases is that it makes engineers think about how they want the system to behave under abnormal or failure conditions. 

 11-4 Unified Modeling Language Tutorial, http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/activity.htm

11-5 Object-Oriented Development in an Industrial Environment, Ivar Jacobson,  Proceedings of OOPSLA´87, SIGPLAN Notices, Vol. 22, No. 12, pages 183-191, 1987

11-6 Object-Oriented Software Engineering: A Use Case Driven Approach, by Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Addison-Wesley, Wokingham, England, 1992.