Activity Diagrams

1. Activity Diagrams • Derived from several techniques: • Event diagrams of Jim Odell • SDL state modeling techniques • Workflow modeling • Petri nets • Especially useful when: • Modeling a workflow • Modeling an operation • Describing behavior that has a lot of parallel processing

2. Activity • Activity is the state of doing something • Real-world process like typing a letter • Execution of a software routine like a method on a class. • Rounded rectangle is narrower and more oval-shaped than the state icon.

3. Activity Diagrams vs. State Diagrams • Activity diagram describes the sequencing of activities, with support for both conditional and parallel behavior • Activity diagram is a variant of a state diagram in which most, if not all, the states are activity states. • Much of the terminology used in Activity diagrams follows that of state diagrams.

4. Activity Diagram

5. Activity vs.State Diagrams

6. Activity vs. State Diagrams

7. Activity Diagram

8. Activity Diagrams • Activity diagrams: • allow the user to choose the order in which to do things • states the essential sequencing rules that must be followed • Flowcharts are limited to sequential processes, whereas activity diagrams can handle parallel processes

9. Forks & Joins • A join synchronizes parallel behavior • Forks and joins must match – every time you have a fork, you must have a join that combines the threads started by that fork.

10. Forks & Joins • Extensions to previous rule: • A thread that comes out of a fork can itself fork, with the new threads coming back together before reaching the matching join

11. Forks & Joins • Extensions to previous rule: • If a thread coming out of a fork goes straight to another fork, you can remove the second fork and just have the threads from the second fork coming out of the first fork.

12. Decomposing an Activity • An activity can be broken down into subactivities using notation similar to superstates and substates on a state diagram.

13. Activity Diagram

14. Dynamic Concurrency

15. Swimlanes • Our activity diagrams so far have focused on what happens, but they do not tell you who does what. • Communication among responsible objects is missing. • Swimlanes can be used to arrange activity diagrams into “zones of responsibility.”

16. Activity Diagram

17. Assigning Objects to Activities • The task of assigning objects to activities should be done. • Should it be done immediately when initially diagramming activities, or later when an overall sense of the behavior is understood?

18. Activity Diagrams • Strengths • Support and encourage parallel behavior • Good tool for workflow modeling • Good tool for multithreading • Weaknesses • Links among actions and objects are not especially clear • Interaction diagrams are more helpful in this area

19. When to use Activity Diagrams • Analyzing a Use Case • Understanding Workflow • Describing a complicated sequential algorithm • Dealing with multithreaded applications

20. When not to use Activity Diagrams • Trying to see how objects collaborate • Trying to see how an object behaves over its lifetime • Representing complex conditional logic

21. ObjectFlow

22. ESU Revisited • Preparing for Registration • The process of preparing the course curriculum and making it available to the student community can be expressed using an Activity Diagram. • We don’t assign responsibilities to each activity at this time.

23. ESU Revisited

24. ESU Revisited • Preparing for Registration • We must make sure all courses have been assigned a professor

25. ESU Revisited

26. The UML and Design Flow Collaboration Diagram Use Case Sequence Diagram State Diagram Object Diagram Class Diagram Activity Diagram