0% found this document useful (0 votes)
53 views

Activity Diagr

UML activity diagrams are similar to flowcharts and data flow diagrams and are used to model business processes, use cases, and software processes. They consist of activities, decision points, guards on transitions, parallel activities shown using forks and joins, swimlanes to group activities, and action objects that activities act on. Well-formed activity diagrams follow guidelines such as starting with a start point, including end points, avoiding superfluous elements, using guards that form a complete set, and ordering swimlanes and action objects logically.

Uploaded by

Prasad Ganta
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
53 views

Activity Diagr

UML activity diagrams are similar to flowcharts and data flow diagrams and are used to model business processes, use cases, and software processes. They consist of activities, decision points, guards on transitions, parallel activities shown using forks and joins, swimlanes to group activities, and action objects that activities act on. Well-formed activity diagrams follow guidelines such as starting with a start point, including end points, avoiding superfluous elements, using guards that form a complete set, and ordering swimlanes and action objects logically.

Uploaded by

Prasad Ganta
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

In many ways UML Activity diagrams are the object-oriented equivalent of flow charts and data-flow diagrams (DFDs).

They are used to explore the logic of: y y y y y y A complex operation A complex business rule A single use case Several use cases A business process Software processes

Guidelines:
1. 2. 3. 4. 5. 6. 7.

General Guidelines Activities Decision Points Guards Parallel Activities Swimlanes Action Objects

1.

General Guidelines

Figure 1. Modeling a business process with a UML Activity Diagram.

1.

Place The Start Point In The Top-Left Corner. A start point is modeled with a filled in circle, using the same notation that UML State Chart diagrams use. Every UML Activity Diagram should have a starting point, and placing it in the top left corner reflects the way that people in Western cultures begin , which models the business process of enrolling in a university, takes this approach. reading. Always Include an Ending Point. An ending point is modeled with a filled in circle witha border around it, using the same notation that UML State Chart is interesting because it does not include an end point because it describes a continuous process sometimes the guidelines diagrams use. dont apply. Flowcharting Operations Implies the Need to Simplify. A good rule of thumb is that if an operation is so complex you need to develop a UML Activity diagram to understand it that you should consider refactoring it.

Figure 1

2.

Figure 2

3.

2.

Activities

An activity, also known as an activity state, on a UML Activity diagram typically represents the invocation of an operation, a step in a business process, or an entire business process.
1. 2. Question Black Hole Activities. A black hole activity is one that has transitions into it but none out, typically indicating that you have either missed oneor more transitions. Question Miracle Activities. A miracle activity is one that has transitions out of it but none into it, s omething that should be true only of start points.

3.

Decision Points

A decision point is modeled as a diamond on a UML Activity diagram.


1. Decision Points Should Reflect the Previous Activity. In you see that there is no label on the decision point, unlike traditional flowcharts which would include text describing the actual decision being made, you need to imply that the decision concerns whether the person was enrolled in the university based on the activity that the decision point follows. The guards, depicted using the format [description], on the transitions leaving the decision point also help to describe the decision point. Avoid Superfluous Decision Points. The Fill Out Enrollment Forms activity in are filled out properly, which simplified the diagram by avoiding an additional diamond.

Figure 1

2.

Figure 1 includes an implied decision point, a check to see that the forms

4.

Guards

A guard is a condition that must be true in order to traverse a transition.


1. 2. 3. 4. 5. 6. Each Transition Leaving a Decision Point Must Have a Guard Guards Should Not Overlap. For example guards such as x <0, x = 0, and x > 0 are consistent whereas guard such as x <= 0 and x >= 0 are not consistent because they overlap it isnt clear what should happen when x is 0. Guards on Decision Points Must Form a Complete Set. For example, guards such as x < 0 and x >0 are not complete because it isnt clear what happens when x is 0. Exit Transition Guards and Activity Invariants Must Form a Complete Set. An activity invariant is a condition that is always true when your system is processing an activity. Apply a [Otherwise] Guard for Fall Through Logic. Guards Are Optional. It is very common for a transition to not include a guard, even when an activity includes several exit transitions. Follow

Agile

Modeling (AM) s principle of Depict Models Simply

and only indicate a guard on a transition if it adds value.

5.

Parallel Activities

It is possible to show that activities can occur in parallel, as you see in Figure 1 depicted using two parallel bars. The first bar is called a fork, it has one transition entering it and two or more transitions leaving it. The second bar is a join, with two or more transitions entering it and only one leaving it.
1. 2. 3. 4. A Fork Should Have a Corresponding Join. In general, for every start (fork) there is an end (join). In UML 2 it is not required to have a join, but it usually makes sense. Forks Have One Entry Transition. Joins Have One Exit Transition Avoid Superfluous Forks.

There is significant opportunity for parallelism in this process, in fact all of these activities the could happen in parallel, but forks were not introduced because they would only have cluttered the diagram.

Figure 2 depicts a simplified description of the software process of enterprise architectural modeling, a part of Enterprise Unified Process (EUP).

6.

Swimlane Guidelines

A swimlane is a way to group activities performed by the same actor on an activity diagram or to group activities in a single thread. Figure 2 includes three swimlanes, one for each actor.
Figure 2. A UML activity diagram for the enterprise architectural modeling (simplified).

Figure 3. Submitting expenses.

1. 2. 3. 4. 5. 6.

Order Swimlanes in a Logical Manner. Apply Swim Lanes To Linear Processes. A good rule of thumb is that swimlanes are best applied to linear processes, unlike the one depicted in . Have Less Than Five Swimlanes. Consider Swimareas For Complex Diagrams. Swimareas Suggest The Need to Reorganize Into Smaller Activity Diagrams. Consider Horizontal Swimlanes for Business Processes. In convention of drawing them vertically.

Figure 2

Figure 3 you see that the swimlanes are drawn horizontally, going against common

7 Action-Object Guidelines
Activities act on objects, In the strict object-oriented sense of the term an action object is a system object, a software construct. In the looser, and much more useful for business application modeling, sense of the term an action object is any sort of item. For example in Figure 3 the ExpenseForm action object is likely a paper form.
1. 2. 3. 4. 5. Place Shared Action Objects on Swimlane Separators When An Object Appears Several Time Apply State Names State Names Should Reflect the Lifecycle Stage of an Action Object Show Only Critical Inputs and Outputs Depict Action Objects As Smaller Than Activities

You might also like