ACTIVITY DIAGRAMS IN OBJECT ORIENTED ANALYSIS AND DESIGN

Activity Diagrams in OOAD

1. ACTIVITY DIAGRAMS Activity diagrams can be used to model business requirements, create a high-level view of a system’s functionalities , analyze use cases and for various other purposes. An Activity diagram is basically a flowchart to represent the flow of one activity to another activity. The activity can be described as an operation of the system. The control flow is drawn from one operation to another. The flow can be sequential, branched , iteration or concurrent. The purpose of an Activity diagram can be described as :- Draw the activity flow of a system Describe the sequence from one activity to another Describe the parallel, branched and concurrent flow of the system

2. ACTIVITY DIAGRAMS Activity diagram can be used for − Modeling work flow by using activities. Modeling business requirements . High level understanding of the system's functionalities . Investigating business requirements at a later stage.

3. How to Draw an Activity Diagram Step 1: Figure out the action steps from the use case Here you need to identify the various activities and actions your business process or system is made up of. Step 2: Identify the actors who are involved If you already have figured out who the actors are, then it’s easier to discern each action they are responsible for. Step 3: Find a flow among the activities Figure out in which order the actions are processed. Mark down the conditions that have to be met in order to carry out certain processes, which actions occur at the same time and whether you need to add any branches in the diagram. And do you have to complete some actions before you can proceed to others? Step 4: Add swimlanes You have already figured out who is responsible for each action. Now it’s time to assign them a swimlane and group each action they are responsible for under them .

4. How to Draw an activity diagram –STEP 3 Identify the initial state and the final states. Identify the intermediate activities needed to reach the final state from he initial state. Identify the conditions or constraints which cause the system to change control flow. Draw the diagram with appropriate notations.

5. ACTIVITY DIAGRAMS BASIC ACTIVITY DIGRAMS NOTATION AND SYMBOLS Initial State –  The starting state before an activity takes place is depicted using the initial state. Action or Activity State –  An activity represents execution of an action on objects or by objects. We represent an activity using a rectangle with rounded corners. Basically any action or event that takes place is represented using an activity Activity or State

6. ACTIVITY DIAGRAMS Fork –  Fork nodes are used to support concurrent activities When we use a fork node when both the activities get executed concurrently i.e. no decision is made before splitting the activity into two parts. Both parts need to be executed in case of a fork statement. We use a rounded solid rectangular bar to represent a Fork notation with incoming arrow from the parent activity state and outgoing arrows towards the newly created activities. For example: In the example below, the activity of making coffee can be split into two concurrent activities and hence we use the fork notation

7. ACTIVITY DIAGRAMS Join –  Join nodes are used to support concurrent activities converging into one. For join notations we have two or more incoming edges and one outgoing edge

8. ACTIVITY DIAGRAMS Merge or Merge Event –  Scenarios arise when activities which are not being executed concurrently have to be merged. We use the merge notation for such scenarios. We can merge two or more activities into one if the control proceeds onto the next activity irrespective of the path chosen .

9. ACTIVITY DIAGRAMS Swimlanes –  We use swimlanes for grouping related activities in one column. Swimlanes group related activities into one column or one row. Swimlanes can be vertical and horizontal. Swimlanes are used to add modularity to the activity diagram. It is not mandatory to use swimlanes . They usually give more clarity to the activity diagram. It’s similar to creating a function in a program. It’s not mandatory to do so, but, it is a recommended practice .

10. ACTIVITY DIAGRAMS Time Event – Final State or End State –  The state which the system reaches when a particular process or activity ends is known as a Final State or End State. We use a filled circle within a circle notation to represent the final state in a state machine diagram. A system or a process can have multiple final states.

11. AN ACTIVITY DIAGRAM WITHOUT SWIMLANES SHOWING ALL SYMBOLS AND NOTATIONS

12. Activity Diagrams with Swimlanes In activity diagrams  swimlanes  – also known as partitions – are used to represent or group actions carried out by different actors in a single thread . Here are a few tips you can follow when using swimlanes. Add swimlanes to linear processes. It makes it easy to read. Don’t add more than 5 swimlanes. Arrange swimlanes in a logical manner.

13. Activity is started by Commuter actor who needs to buy a ticket. Ticket vending machine will request trip information from Commuter. Based on the info machine will calculate payment due and request payment options. After payment is complete, ticket is dispensed to the Commuter.

14. Passenger checks in ,  passenger boards , and  loading luggage into airplane  are complex activities, each of which is detailed in another activity diagram. When a passenger checks in, he or she first shows his or her ticket at the check-in counter. The ticket will be checked for its validity. If the ticket is not OK the passenger will be referred to customer service. If the ticket is OK the passenger will check his or her luggage . If the luggage has excess weight he or she will pay an additional fee. The luggage will be forwarded to baggage transportation. The passenger receives his or her boarding pass. Determine the level of detail in activity diagrams very consciously. Test which level of detail users of the diagrams can stand and which is the least amount of detail necessary. We cannot give universally valid rules, since the level of detail essentially depends on the target group and purpose of the model. Now, we have the following additional actions (Figure 3.20):