software engineering with uml- activity diagram

109
Chapter 7
Activity Diagrams,
Interaction Overview
Diagrams, and Business
Process Models
Learning Objectives
◾
◾ Understand the importance and complexities of process models
◾
◾ Learn UML notations for activity diagrams
◾
◾ Create activity diagrams with activities, partitions, multithreads, and decision points
◾
◾ Relate activity diagrams to use case documentation
◾
◾ Learn UML notations for interaction overview diagrams
◾
◾ Create interaction overview diagram
◾
◾ Learn Business Process Model and Notation (BPMN)
◾
◾ Use BPMN to create process models
Introduction
The discussion in this chapter focuses on process modeling. These processes are documented
within use cases; they are also business processes comprising many use cases. Process modeling
starts with the documentation of use cases (as discussed in Chapter 5) and their modeling in a
use case diagram (Chapter 6). In this chapter, the focus is on visual modeling of the use case
documentation using activity diagrams. The activity diagrams of the UML have a rich suite of
notations and guidelines, making them ideal for modeling any kind of process within a system
or business. Business Process Model and Notation (BPMN) is another rich suite of notations that
can be used for process modeling. BPMN is owned by the Object Management Group (OMG)

110 ◾ Software Engineering with UML
but is not a part of the UML. However, the richness of its notations and semantics means it can
be used for modeling large and complex business processes. In addition to the activity diagram
and BPMN, this chapter also
discusses the interaction overview diagram (IOD) of the UML. The
IOD is conceptually similar to an activity diagram (because it also has a flow); however, the IOD
provides opportunities to model the interactions at a high level as compared to the detailed models
created by activity diagrams.
SEPARATING BUSINESS PROCESSES FROM
SOFTWARE DEVELOPMENT PROCESSES
An important word of caution here: the process modeling discussed in this chap-
ter is based on business processes and use cases. The software development life
cycle (SDLC) and Agile processes discussed in Chapter 4 are dimensionally differ-
ent as they focus on the approach to developing a software solution. Thus, those
processes support solution development, whereas the processes in this chapter are
the actual business processes that describe how to perform a particular business
function.
Activity Diagrams
Activity diagrams of the UML are meant to show any flow, or process, in the system. This makes
them capable of modeling the following:
◾
◾ Business processes or workflows within the organization that describe how the business
functions are carried out
◾
◾ The flow within a use case by creating a visual map of the documentation of that use case
◾
◾ Dependencies between use cases by using the activity notation to represent a use case
(although this requirement is better served by the interaction overview diagram)
◾
◾ The navigation of a mobile app (storyboard) by representing the mobile screens as activities
within the activity diagram
Since the activity diagram shows the processes like a flowchart, it is far more readable from the
user’s viewpoint than the use case diagram. As a result, users find this an attractive way to discuss
their requirements, but at a lower level than with use case diagrams. Furthermore, since activity
diagrams represent process flows, they can be used to model the existing business processes as
well as the new (envisioned) business processes. This modeling of processes enables comparison
between current and new processes, identifies gaps between them, and creates a systematic oppor-
tunity to transition the gap in those processes.
Notations of Activity Diagrams
The UML notations used to create activity diagrams include activities, transitions, start and end
points, synchronization points, decision points, and guard conditions. Figure 7.1 shows these
activity diagram notations.

ActivityDiagrams,Interaction OverviewDiagrams,andBusinessProcessModels ◾ 111
The start activity and stop activity are shown with their corresponding notations in Figure
7.1. Syntactically it is necessary to have only one start activity in the activity diagram; however,
multiple stop activities are allowed. The stop activity is optional, though. All activities other
than the start and stop activities are represented by the rounded rectangle, marked “activity”
in Figure 7.1.
The dependency between activities, and their flow (similar to a flowchart), is shown by an
arrow marked “Flow of Activities” in Figure 7.1. Activity diagrams also have a decision point
similar to that in a flowchart. The decision point enables branching of the activities based on speci-
fied conditions. Notes are also a part of activity diagrams, and should be liberally used to explain
diagrams.
While an activity diagram has the look and feel of a flowchart (see Figure 7.2, discussed in
detail in the next section), it is more than a flowchart. One key difference is the activity diagram’s
ability to show partitions. Partitions, also known as swimlanes in previous versions of the UML,
indicate “lanes” in which the activities are performed by actors. The actor that performs the activi-
ties is shown as a label on top of the partition. Activity diagrams are usually drawn top-down,
but they can also be drawn going left to right depending on the modeling tool being used. The
arrangement of the actor and its label is not dictated by the UML—hence modelers can use their
judgment to improve the aesthetics of their activity models.
An activity diagram can also have synchronization (sync) points that are either a fork or a join.
A sync point is indicated by the horizontal bar in Figure 7.1. The sync point indicates the start and
stop of parallel activities—that is, activities that don’t depend on each other but that need to be
performed simultaneously.
Naming an Activity Diagram
An activity diagram is usually named after the use case whose flow is being modeled. A “verb like”
name similar to the use case is appropriate for the activity diagram, e.g., “BooksConsultation.”
Some activity diagrams in the system may model activities belonging to multiple use cases. In
these cases, the appropriate behavioral names covering multiple use cases should be provided.
Start activity
Activity
Fork/Join
Decision point
Notes
Stop activity
Flow of activities
Partition
Figure 7.1 Notations of an activity diagram.

Activity Diagrams for Hospital Management System
A good way to understand the modeling of activity diagrams is to use the running example of the
HMS. In this section, four specific activity diagrams corresponding to the four use cases that were
documented in Chapter 5 are discussed. These activity diagrams, based on those four use cases,
are as follows:
◾
◾ RegistersPatient activity diagram
◾
◾ MaintainsCalendar activity diagram
◾
◾ BooksConsultation activity diagram
◾
◾ PaysBill activity diagram
Each activity diagram shows a specific nuance of process modeling. Each activity diagram is
further discussed next.
“RegistersPatient” Activity Diagram
Figure 7.2 shows the activity diagram that represents the process of registering patient details.
This diagram starts with a pseudo start activity, followed by the activity AnnounceArrival.
'A10-Patient'
AnnounceArrival
If patient is already registered,
then they need not be registered
again here.
YES
NO
'Provide Details'
FirstTime?
'Enter Details'
'Verify Details'
CreatePatientRecord
Private Patient
details will be
similarly forwarded to the
patient’s insurance company
DetailsCorrect?
RegistrationConfirmed
Additional/mandatory
details must be provided
by first-time patients
NO
'A80-Administrator' System 'A90-GovtHRS'
Verify Medical
InsuranceDetails
Figure 7.2 RegistersPatient activity diagram.

On completion of this activity, the flow within this activity diagram reaches a decision point.
The decision point checks whether the patient is visiting the hospital for the first time. A
patient not coming for first time is shown by the activity diagram as entering the pseudo stop
state as that patient’s details are present in the system. A patient visiting for the first time starts
the activity of ProvideDetails. The process control then transfers to the EnterDetails
activity in the Administrator partition. The flow then reaches the sync point where
activities
are split into two threads. The Verify/Details in the system partition checks for the correct-
ness of the details entered and the VerifyMedicalInsuranceDetails in the GovtHRS
partition verifies the patient’s medical insurance details.
If these two activities are conducted sequentially (one after the other), the processing time
will take much longer than if the activities are conducted in parallel. The two activities occur-
ring in parallel join back at the next sync point. The time taken by each of these two activi-
ties conducted in parallel can be different. For example, VerifyDetails may take only
30 seconds, but VerifyMedicalInsuranceDetails may take a few minutes. When
both these activities, with different time frames, are complete, then the next activity can start.
Completion of both these activities at a point in time is shown by the horizontal joining bar.
This forking and joining of an activity diagram facilitates the optimization of workflows and
enhancement of quality.
Once the details of the patient are verified as correct, the patient record is created
in the CreatePatientRecord activity. Alternatively, the flow is redirected to the
ProvideDetails activity. The registration of the new patient record is confirmed in the
RegistrationConfirmed activity, which then concludes at the pseudo stop state.
“MaintainsCalendar” Activity Diagram
Figure 7.3 shows the activity diagram that represents the process of maintaining the cal-
endar details. This diagram starts with the pseudo start activity, followed by the activ-
ity RequestPersonalCalendar in the staff partition. Control is then transferred
to the ProvidesPersonalCalendar activity in the system partition. The activity of
EnterPreferredDetails follows in which the staff enters his preferred working times.
These details are verified in the ValidatePreferredRosterDetails activity and control
reaches the decision point.
In the case of a conflicting calendar, the control is passed to the ProvideCalendar
OptionsToStaff activity, which follows the EnterPreferredDetails activity for
another set of validation. If the requested roster details do not conflict with the existing schedule,
the details are accepted in the AcceptDetails activity. The accepted details are updated in the
calendar in the UpdateCalendar activity in the system partition. The new calendar details
are confirmed in the RegistrationConfirmed activity, which then concludes at the pseudo
stop state.
“BooksConsultation” Activity Diagram
Figure 7.4 shows the activity diagram that represents the process of booking a consul-
tation. This diagram starts with the pseudo start activity, followed by the activity
SpecifiesInitialDetailsForConsultation in the Patient partition. The special
note attached to this activity states that the details need to be selected from the list of services

provided. The list of physicians is provided in the ProvidesListOfPhysician activity in
the system partition.
The patient then selects the physician in the SelectsPhysician activity. The system
then provides the available consultation times for the selected physician in the ProvidesAv
ailableConsultationDay&Times activity. The patient then selects the date and time in
SelectsDay&Time, which is updated in the UpdateCalendar activity.
The consultation could be brief or detailed. This variation is not easy to depict using the activ-
ity diagram notations—hence it is shown in a special note. The confirmation is viewed in the
ViewConfirmation activity, which then concludes at the stop state.
'A50-Staff' System
Request
Personal
Calendar
Provides
Personal
Calendar
Staff is seeking
their own personal
calendar (roster)
Staff updates the calendar
with their availability.
Roster duties are also updated.
System validates the
data entered by staff
against existing calendar,
and against other staff's
calendar.
EnterPreferred
RosterDetails
ValidatePreferred
RosterDetails
Provide Calendar
Options to Staff
AcceptDetails
UpdateCalendar
ConflictingRosters?
YES
NO
Figure 7.3 “MaintainsCalendar” activity diagram.

“PaysBill” Activity Diagram
Figure 7.5 shows the activity diagram that represents the process of paying a bill by a patient.
This diagram starts with the pseudo start activity, followed by the activity ReceivesBill
in the Patient partition, in which the patient receives a bill for all services. The bill is veri-
fied against all the consultations in the VerifiesBillAgainstConsultation activity,
and then the control passes to the decision point Valid. If the details are valid, the PaysBill
activity starts and later concludes at the stop state. If there are errors in the bill, the control is
transferred to the ReportError activity, which again is concluded at the pseudo stop state.
A10-Patient System
Specifies Initial
Details for
Consultation
ProvidesListof
Physicians
SelectsPhysician
SelectsDay & Time
ViewsConfirmation
UpdatesCalendar
ProvidesAvailable
ConsultationDays & Times
Patient may indicate
type of consultation
(brief, detailed)
These details include
selecting first from a
list of services (diseases)
Figure 7.4 “BooksConsultation” activity diagram.

Strengths and Weaknesses of Activity Diagrams
Strengths of Activity Diagrams
What follows are some of the strengths of activity diagrams. An understanding of these strengths
is helpful in conducting workshops and modeling process flows in practice:
◾
◾ Activity diagrams model the flow within a use case (or a number of use cases). They comple-
ment use case documentation by showing a visual representation of the internals of a use case
and result in improved use case documentation.
◾
◾ Activity diagrams show the flow of a process and are ideal for documenting use cases and system
flows in practice. This allows requirements to be modeled in great detail in the problem space.
◾
◾ Activity diagrams can show multiple flows that occur simultaneously within a system by
using sync points (forks and joins). This is a major strength of activity diagrams over tradi-
tional flowcharts as these techniques help in optimizing workflows.
◾
◾ Activity diagrams can show decisions that occur and the alternative paths with the help of
decision points. The ability to show multiple paths (“if-then-else”) is most helpful in model-
ing processes (as compared with use case diagrams, which do not have a decision point).
◾
◾ Partitions show a clear mapping between the actors and the activities they undertake. This
mapping helps in categorizing, assigning, documenting, and testing the activities as well as
assigning them to the actors.
A10-Patient
ReceivesBill
Valid?
YES
PaysBill
ReportError
See extended
use cases and their
activity diagrams for
payment by Card, Internet
and Cash/Check
This is a generic
PaysBill activity
diagram. It is
extended to
specific types of
payments
VerifiesBill
Against
Consultations
NO
System
Figure 7.5 “PaysBill” activity diagram.

◾
◾ Activity diagrams act as a bridge between use cases and sequence diagrams. This enables
the text-based documentation of the use cases to be shown pictorially in activity dia-
grams. At the same time, activity diagrams enable a high-level view of what is shown
in detail, at the object level, on a sequence diagram (sequence diagrams are a topic of
Chapter 12).
◾
◾ The use of notes on the activity diagrams enables easier reading and understanding of the
diagrams for users with no technical background. Explanations of the activities, their depen-
dencies, and the decisions points all provide excellent user-level documentation. Therefore,
activity diagrams are used when training users new to a system.
◾
◾ Activity diagrams are easily understood by people new to UML. Therefore, it is often easier
to start a requirements modeling workshop with an activity diagram, especially if users par-
ticipating in workshops are new to the concept of modeling.
◾
◾ Activity diagrams can provide documentation on the use of a system. Therefore, they can be
inserted in user manuals and help files, with the judicious use of explanatory notes.
◾
◾ Activity diagrams can also be used in business process engineering, in which the existing
business processes are first documented using these diagrams and then reengineered for
optimization.
Activity diagrams are also used in documenting software development processes (although
that use is outside the scope of discussion in this chapter).
Weaknesses of Activity Diagrams
What follows are some of the weaknesses of activity diagrams. An understanding of these weak-
nesses is also helpful in conducting workshops and modeling process flows in practice:
◾
◾ Activity diagrams have minimal structural characteristics, and they do not provide direct
information on how a system or requirements are organized and prioritized.
◾
◾ Activity diagrams do not give a complete picture of a system when they are used to model
use case behavior; thus, unlike use case diagrams, activity diagrams do not show the full
requirements of a system at a glance.
◾
◾ Activity diagrams depict flow, and therefore they should be used only when there is a need
to show dependencies between activities. Activity diagrams are not ideal for organizing and
managing requirements.
◾
◾ Activity diagrams that document large and complex use cases can quickly become very
complicated and lose their value. Several smaller activity diagrams are needed to model the
flow of complex use cases.
◾
◾ Activity diagrams have been confused with state machine diagrams in earlier versions of
UML—perhaps because there were similar notations in those earlier UML versions. For exam-
ple, it was common to confuse an activity with a state. Inexperienced modelers can still make
the same mistake, and care should be taken to differentiate between an activity and a state.
◾
◾ Activity diagrams have been confused with data flow diagrams (DFDs). The two are differ-
ent in that activity diagrams focus on the business workflow and DFDs focus on the flow of
data. DFDs also have levels, but activity diagrams do not.
◾
◾ Different types of processes cannot be shown in a single activity diagram because the scope
of an activity diagram is a singular use case or a business process. In such cases, multiple
activity diagrams are required with notes linking them with each other.

◾
◾ Although activity diagrams can be used in the solution space, unless a system is
multi
threaded and multitasked, they don’t add great value in this space.
◾
◾ Modelers are prone to assume that the activity flow within an activity diagram includes a
timeline; however, because activity diagrams do not display time, they are not considered
dynamic.
Interaction Overview Diagram
Interaction overview diagrams (IODs), as their name suggests, provide a high-level overview of the
interactions happening within a system. Therefore, these diagrams show dependencies and flows
between use cases. As discussed later in Chapter 12, sequence diagrams also depict interactions,
but at a detailed, object level. IODs contain references to the corresponding sequence diagrams.
Thus, one IOD can contain references to multiple sequence diagrams and also show the dependen-
cies between those sequence diagrams. IODs can also reference other diagrams such as the activity
diagram or a use case and provide an overview of how these other diagrams are related to each
other. Because of their ability to show “if-then-else” scenarios, these IODs have a similar look and
feel to activity diagrams.
Notations of an Interaction Overview Diagram
IODs are created with the UML notations shown in Figure 7.6. Some of these notations are
similar to those of an activity diagram. This is because the interaction overview also represents
a flow—albeit at a higher overview level and not at the activity level. The reference notation in
an IOD provides the ability to reference another use case or sequence diagram. The start and
stop states, decision points, flow, sync points, and notes in IODs are similar to those of activity
diagrams.
Naming an Interaction Overview Diagram
Since IODs can show the “if-then-else” situation between use cases, they are “flowcharts” of use
cases. They should be named similarly to the use case diagrams that were discussed in Chapter 6.
Two examples of IODs for the HMS are discussed next.
Start
Flow
Fork/Join
Note
Stop
Inquiry Sequence
ref
Decision
Reference
(to a use case or a
sequence diagram)
Figure 7.6 Notations of an interaction overview diagram.

Interaction Overview for “Consultation Details”
Figure 7.7 shows an IOD for the process of booking and providing consultations. The use case
diagram corresponding to this IOD was shown earlier in Chapter 6. This interaction starts when
the calendar is checked for availability of booking as represented by ChecksCalendar in
Figure 7.7. If booking is not available, the ChecksCalendar sequence or use case is executed
again. If booking is available, then the BooksConsultation use case is executed, followed by
ExaminesPatient. Finally, there is an opportunity for two parallel process referenced in the
diagram by OrdersTests and WritesPrescriptions. When both of these processes are
completed, the consultation process ends.
Interaction Overview for “Accounting”
Figure 7.8 shows another example of an IOD for the HMS. In this diagram, the first reference
is PaysBill, which describes the common part of the process of bill payment. After that,
the process checks how the bill will be paid. For each of the three alternatives of Card, BPAY,
and CashCheque, there are three corresponding references. They are PaysBillByCard,
PaysBillOnInternet (representing BPAY on the Internet), and CashChequePayment,
respectively. These are references to use cases described in Chapters 5 and 6. After the bill payment
is completed, it is verified whether or not the patient is private. If the patient is private, then there
is another reference to a use case called PlacesInsuranceClaim; otherwise the process ends.
ChecksCalendar
BookingAvailable?
YES
NO
BooksConsultation
ExaminesPatient
OrdersTests
Check the calendar
again for alternatives.
If no bookings are available,
no consultation takes place
WritesPrescriptions
ref
ref
ref ref
ref
Figure 7.7 Consultation details interaction overview diagram.

Strengths and Weaknesses of Interaction Overview Diagrams
Strengths of Interaction Overview Diagrams
What follows are some of the strengths of IODs in practice. Awareness of these strengths by

modelers is most helpful in improving the quality of the model of the problem space (MOPS):
◾
◾ The primary strength of IODs is they are able to show the dependencies between various
sequences within a system. IODs provide strength to the modeling effort in the problem
space by enabling the display of conditions and multiple threads in the diagrams.
◾
◾ Being similar to activity diagrams, IODs show the normal and alternative flows of sequences
within a system through a combination of flowchart and references to sequence diagram
mechanisms.
Weaknesses of Interaction Overview Diagrams
◾
◾ What follows are some of the weaknesses of IODs. Awareness of these strengths by modelers
is most helpful in improving the quality of the MOPS: IODs may have weaknesses similar
to those of activity diagrams. IODs may not be able to show “instance” level modeling and
should not be used for that purpose.
◾
◾ Being an overview diagram, the IOD should be used sparingly. Excessive modeling with
IODs can lead to confusion between those and activity diagrams.
PaysBill
Method
CARD BPAY
CashCheque
Private?
YES
NO
ref
PlacesInsuranceClaim
PaysBillByCard
ref
ref
PaysBillOnInternetBPAY CashChequePayment
ref ref
Figure 7.8 Accounting interaction overview diagram.

◾
◾ IODs are precisely that—overview diagrams. These diagrams are not closely linked to the
other diagrams they reference. As a result, there isn’t a good syntax and semantic check pos-
sible for these diagrams during the quality assurance exercise.
◾
◾ Referencing to other diagrams within IODs is not clearly understood in practice. There is
the possibility of confusion as to what is being referenced (sequence diagram, communica-
tion diagram, or a use case) within the IOD.
Business Process Modeling
Business processes are an integral part of modern businesses. Business processes have inputs,

process those inputs, and produce outputs. Business processes provide value to a user. Therefore,
any good software design needs to start with a process model. Activity and interaction overview
diagrams of the UML are useful in modeling business processes. Business processes make use of
software systems during their execution.
Business process modeling is usually undertaken with a recognized suite of notations
derived from a framework. In practice, Business process modeling also requires the use of a
modeling tool that will enable a team of modelers to work together. Occasionally, Business
process modeling also represents the “management” of business processes—and includes mod-
eling, indexing, documenting, storage, retrieval, and removal of a suite of processes within an
organization.
Several techniques can be used to model a business process. Some of the well-known tech-
niques are listed in Table 7.1.
Business process modeling is an in-depth visualization of a process before designing its
solution. Such modeling can be used not only to create a new process but also to understand
and improve existing processes. The complexity and importance of business processes led to
the formation of a rich suite of notations—the Business Process Model and Notation (BPMN).
Business process modeling has been used as a basis for the overall organizational structure
that can be moved from a hierarchical inward-facing structure to a process-based organiza-
tional structure. Business processes can be both external facing (by providing value to an
external stakeholder) and internal to the organization (by satisfying the needs of an internal
stakeholder).
While early attempts at business process modeling focused on modeling a single process and
improving it from a time and cost perspective, increasingly business process modeling is moving
toward modeling a collaborative suite of processes that are likely to provide value to a stakeholder
based on multiple, cross-functional processes. Modeling collaborative processes end to end as the
“customer interacts” provides much higher value to stakeholders than the silo-centric (standalone)
view.
Examples of business processes (that are identified as use cases) that are primarily exter-
nal
facing include “customer withdraws cash,” “passenger checks in for a flight,” and “patient

admitted to a hospital.” On the other hand, examples of business processes that are internal

facing include
“end-of-day cash-in and cash-out from a bank branch,” “scheduling of flights,”
and “reorder antibiotics.” These examples include many different aspects of a business com-
ing into play. For example, in each case, a primary stakeholder gains value, and many other

stakeholders are involved in providing that value. Each process also needs extensive support with
technologies including software systems, mobile devices, and security/privacy.

The following figures show some important aspects of BPMN, including their flow and con-
necting notations (Figure 7.9) and their grouping objects (Figure 7.10).
◾
◾ Events—happen during the course of a business process and are made up of start, intermedi-
ate, and end stages.
◾
◾ Activities—generic term for what the business does; made up of process, subprocess, and
tasks.
◾
◾ Gateways—control divergence and convergence in business flow; include branching,

forking, merging, and joining
◾
◾ Sequence flow—denotes the order of activities
◾
◾ Message flow—denotes the flow of messages between two entities (such as pools) or directly
to an object within a pool
Table 7.1 Common BPM Techniques and Their Brief Explanation
BPM Technique Brief Explanation
Flowcharts Provide a basic flow of a business process
from start to finish with alternative
subprocesses in between.
Functional block diagrams Provide a high-level view of a large and
complex business process (or a suite of
business processes).
PERT and Gantt charts Provide precise routing of one or more
business processes with opportunities to
optimize on time and costs associated with
the processes.
Data flow diagrams Provide a more technical view of a business
process that is primarily based on the way
in which key data elements of the process
change as the process is executed
Use case diagrams (UML) Provide an important view of a business
process that is based on actors, use cases,
their relationships, and a system boundary
Activity diagrams (UML) Based on (and similar to) flowcharts, activity
diagrams provide an excellent basis for
modeling business processes by mapping
activities to actors within a partition and
optimizing processes through multithreads.
Business Process Model and Notation
(BPMN)
Rich suite of notations that create business
process models that can be embedded in
standardized case tools, shared, and
optimized.
Business Process Modeling Language (BPML) A modeling language based on BPMN and
supported by modeling tools.

◾
◾ Association—used to associate information and artifacts
◾
◾ Data object—denotes the Object within the process flow
◾
◾ Group—a mechanism to treat multiple activities together
◾
◾ Annotation (notes)—are explanatory labels or comments on any artifact on the process
model to provide further explanation
Figures 7.11 and 7.12 show examples of BPMN-based process models (insurance example)
Sequence flow
Events
Activities
Gateways
Association
Message flow
Name
Data Object
Group
Annotation
(notes)
Figure 7.9 BPMN notation.
Name
Name
Name-1
Name-2
Pools
Lanes
(within Pools)
Figure 7.10 BPMN – grouping with pods and lanes.

Terminate
policy
Commence
policy cover
Pay
premium
Pay periodic
policy
premium
Update policy
Defaulting policy
Update
underwriters
Accept
Quote?
No
Yes
Figure 7.12 Another basic process model (with additional details).
A task
A start event
Identify
insurance
type
A sequence flow
Car
A gateway decision
Home
Accept
premium
An end event
Evaluate home
insurance
Evaluate car
insurance
?
Figure 7.11 A basic process model (Insurance example).

Common Errors in Activity Diagrams, Interaction
Overview Diagrams, and Business Process
Models and How to Rectify Them
Common Errors Rectifying the Errors Examples
Drawing activity diagram
independent of use cases
Ensure a continuous cross-
reference between activity
diagrams and use case
documentation.
Study Figures 7.2 through 7.5
and their corresponding
use cases in Chapter 5. The
mapping between the use
cases and these activity
diagrams is important.
Not having proper start and
stop activities
Ensure one start activity and
as many stop activities as
needed.
Figure 7.5, like Figures 7.2
through 7.4, has one start
activity but more than one
stop activity.
Having a fork (sync point)
but not having a join (sync
point)
Ensure all forks have a join
and vice versa.
Figure 7.2 on the right-hand
side has a fork and a join.
Every fork should ideally
have a join.
Unsure of where to place
activities that seem to
belong to multiple actors
Place the activity in the
partition belonging to the
main actor who owns that
activity.
In Figure 7.2, the activities
belonging to the patient are
AnnounceArrival and
ProvideDetails; these are
mainly within the patient
partition, but the
administrator is also
involved in their execution.
Assuming system to be an
actor
While a system is not an
actor, there is usually a
partition for the system.
Figure 7.2 has a partition
corresponding to system.
This partition contains all
activities that are responses
of the system to an action
by an actor from the other
partitions.
Confusing activity diagrams
with use case diagrams
Activity diagrams have flow
and decision points.
Study the examples in this
chapter and compare them
with the use case diagrams
in Chapter 6.
Confusing activity diagrams
and interaction overview
diagrams
IOD are at a higher overview
level
Figure 7.7,
ConsultationDetails IOD,
has references to
“ChecksCalendar” and
“BooksConsultation” use
cases.

Discussion Questions
1. Does an activity diagram represent a use case diagram or a use case? Explain with examples.
2. What is the purpose of a partition in an activity diagram?
3. Draw a simple activity diagram, like a flowchart, based on a use case (e.g., like the one docu-
mented in Chapter 5).
4. Draw a detailed activity diagram that shows partitions, multithreads, and decision points.
5. How do multiple threads help optimize workflows? Discuss with examples.
6. Draw a simple interaction overview diagram (IOD) for any system (note: the boxed refer-
ences within the IOD can represent an entire use case or a sequence diagram).
7. Add notes to your activity and IOD.
8. What is BPMN? How can it help in process modeling efforts?
9. Consider how you would represent the activity diagram you have drawn using BPMN.
10. What is the difference between a business process and a software development process?
Team Project Case Study
1. Identify TWO use cases from EACH package you are working on.
2. Revisit and study the flow within the use case, including alternative flows and exceptions.
3. Draw an activity diagram for a use case based on the flow of the use case appearing in its
documentation. Repeat for another use case.
4. Ensure each activity diagram has carefully created partitions including the system partition.
5. You should thus have TWO activity diagrams per package corresponding to the two use
cases.
6. You may have an additional activity diagram that covers two or more use cases. That is not
mandatory, but if it happens, it is acceptable. However, depending on your modeling tool,
such a diagram may not get linked to a use case.
7. Add notes to your activity diagrams to further explain the diagrams.
8. Show multiple threads, running in parallel, in any one of the activity diagrams in your
system.
9. Draw ONE interaction overview diagram within each package. This IOD will represent the
high-levels interactions among use cases, activity diagrams, or sequence diagrams. (Since we
have yet to discuss sequence diagrams, you will have to come back to update the IODs after
the discussion on sequence diagrams in Chapter 12).

software engineering with uml- activity diagram

Recommended

More Related Content

What's hot (20)

Similar to software engineering with uml- activity diagram (20)

More from rahmantoyuri (20)

Recently uploaded (20)

software engineering with uml- activity diagram