MOI UNIVERSITY INF 212: BUSINESS SYSTEMS MODELLING

LESSON 6: MODELING ORGANIZATIONAL ACTIVITIES AND PROCEDURES

Introduction
Most people intuitively understand a business process to be a procedure or event with the
purpose of reaching a goal. In an organization however, many activities and procedures run to
help achieve set organizational goals. For example an airport has different business processes
and goals:
 The goal of our passenger is to go on vacation. To achieve this goal, he has to book a
flight and hotel, pack his bags, drive to the Airport, check in and board his airplane, exit
the plane at his destination airport, go to the hotel, move into his room, and unpack his
bags.
 The owner of the newsstand at the Airport wants to sell her goods. For this, she buys
items inexpensively and sells them to her customers at a higher price.
 In order for passengers to check in at the Airport, an employee of passenger services
accepts their tickets and luggage, inquires about their seat preferences, and uses an IT
system. By the end of the procedure, the passengers receive their boarding passes on
which their reserved seats and the appropriate gates are marked.
From the example above one can see that business processes are often completed in several
steps. These steps are also referred to as activities, and have to be completed in a predetermined
order.
Definitions
A process is a coordinated (parallel and/or serial) set of process activity(s) that are connected in
order to achieve a common goal. Such activities may consist of manual activity(s) and/or
workflow activity(s). According to this definition, a process is a set of activities that occur in a
coordinated manner, either in parallel or one after another, and that pursue one common goal.
These activities can be performed manually or when supported by an IT system. A business
process is a kind of process in the domain of business organizational structure and policy for the
purpose of achieving business objectives. Business processes are dynamic in nature and involve
activities.
Activities can run sequentially or in parallel. For example, a passenger can buy a bottle of Coke
in the duty-free shop, while his or her luggage is being loaded into the Airbus 320 to London.
Individual activities can be organizationally distributed. The check-in procedure takes place at
the check-in counter and is performed by an employee of passenger services, while the
subsequent boarding occurs at a different location and is performed by different employees of
passenger services. Usually, the activities of a business process are interdependent. This
interdependency is created by the interaction of all the activities belonging to a business process
that pursue one common goal.
Bachelor of Science in Informatics Page 1
MOI UNIVERSITY INF 212: BUSINESS SYSTEMS MODELLING

BUSINESS SYSTEMS
Notes on print out
BUSINESS SYSTEMS MODELING
The essential starting point for good business modeling, and that includes data modeling, is to
model the Business Functions. Effective business modeling has five facets:
1. Information gathering
2. Analysis and investigation
3. Modeling
4. Feedback
5. Implementation
Organizations have and create different types of models and they include:
 Process Models: Processes are simple the linking together of Business Functions into a
particular order to achieve a particular business result.
 Data Structure Model: The shows the relationships between the data entities created
and used by Business Functions.
 Information Flow Model: This shows how information flows between Business
Functions within the business and between Business Functions and the outside world.
 Data State Model: This shows how data entities from the Data Structure Model are
transformed by Business Functions.
 Procedure Model: This shows the mechanisms by which Business Processes are
executed day-to-day.

Bachelor of Science in Informatics Page 2

MOI UNIVERSITY INF 212: BUSINESS SYSTEMS MODELLING

Business Activity Modelling

The technique provides a pictorial representation of the business which helps tease out the
requirements, focus on the areas of concern, put the system into perspective, inform the clients of
what is possible and what is in the realm of ‘science fiction’, while never alienating them in any
way. When used properly, Business Activity Modelling can increase user participation and
encourage users to build a sense of ownership for the future system.
In business activity modeling one captures the Business Events; Business Threads; Activities and
Tasks (An Activity can be broken-up into tasks. The tasks involved in completing an activity may
vary according to different conditions. When an activity is complicated, we may analyse the
activity by breaking it into tasks and then reconstructing these tasks.)

An Activity Diagram
Activity diagrams are typically used for business process modeling, for modeling the logic
captured by a single use case or usage scenario, or for modeling the detailed logic of a business
rule. Activity diagrams and use cases are logical model which describe the business domain’s
activities without suggesting how they are conduct, a diagram that emphasizes the flow of
control from activity to activity in an object. Activity diagram is basically a flow chart to

Bachelor of Science in Informatics Page 3

MOI UNIVERSITY INF 212: BUSINESS SYSTEMS MODELLING

represent the flow form one activity to another activity. The activity can be described as an
operation of the system.
Purpose:
The basic purposes of activity diagrams are similar to other four diagrams. It captures the
dynamic behaviour of the system. Other four diagrams are used to show the message flow from
one object to another but activity diagram is used to show message flow from one activity to
another.
Activity is a particular operation of the system. Activity diagrams are not only used for
visualizing dynamic nature of a system but they are also used to construct the executable system
by using forward and reverse engineering techniques. The only missing thing in activity diagram
is the message part.
It does not show any message flow from one activity to another. Activity diagram is some time
considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows
different flow like parallel, branched, concurrent and single.
So the purposes 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.
How to draw Activity Diagram?
Activity diagrams are mainly used as a flow chart consists of activities performed by the system.
But activity diagram are not exactly a flow chart as they have some additional capabilities. These
additional capabilities include branching, parallel flow, swimlane etc.
Before drawing an activity diagram we must have a clear understanding about the elements used
in activity diagram. The main element of an activity diagram is the activity itself. An activity is a
function performed by the system. After identifying the activities we need to understand how
they are associated with constraints and conditions.
So before drawing an activity diagram we should identify the following elements:
 Activities
 Association
 Conditions
 Constraints
Once the above mentioned parameters are identified we need to make a mental layout of the
entire flow. This mental layout is then transformed into an activity diagram.
The following is an example of an activity diagram for order management system. In the diagram
four activities are identified which are associated with conditions. One important point should be
clearly understood that an activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and mainly used by the business users.

Bachelor of Science in Informatics Page 4

MOI UNIVERSITY INF 212: BUSINESS SYSTEMS MODELLING

The following diagram is drawn with the four main activities:

 Send order by the customer
 Receipt of the order
 Confirm order
 Dispatch order
After receiving the order request condition checks are performed to check if it is normal or
special order. After the type of order is identified dispatch activity is performed and that is
marked as the termination of the process.

Bachelor of Science in Informatics Page 5

MOI UNIVERSITY INF 212: BUSINESS SYSTEMS MODELLING

Where to use Activity Diagrams?

The basic usage of activity diagram is similar to other four UML diagrams. The specific usage is
to model the control flow from one activity to another. This control flow does not include
messages.
The activity diagram is suitable for modeling the activity flow of the system. An application can
have multiple systems. Activity diagram also captures these systems and describes flow from one
system to another. This specific usage is not available in other diagrams. These systems can be
database, external queues or any other system.
Now we will look into the practical applications of the activity diagram. From the above
discussion it is clear that an activity diagram is drawn from a very high level. So it gives high
level view of a system. This high level view is mainly for business users or any other person who
is not a technical person.
This diagram is used to model the activities which are nothing but business requirements. So the
diagram has more impact on business understanding rather implementation details.
Following are the main usages of activity diagram:
 Modeling work flow by using activities.
 Modeling business requirements.
 High level understanding of the system's functionalities.
 Investigate business requirements at a later stage.

Let's start by describing the basic notation (there's more) that I've used in Figures 1 and 2:
 Initial node. The filled in circle is the starting point of the diagram. An initial node isn't
required although it does make it significantly easier to read the diagram.
 Activity final node. The filled circle with a border is the ending point. An activity
diagram can have zero or more activity final nodes.
 Activity. The rounded rectangles represent activities that occur. An activity may be
physical, such as Inspect Forms, or electronic, such as Display Create Student Screen.
 Flow/edge. The arrows on the diagram. Although there is a subtle difference between
flows and edges I have never seen a practical purpose for the difference although I have
no doubt one exists. I'll use the term flow.
 Fork. A black bar with one flow going into it and several leaving it. This denotes the
beginning of parallel activity.
 Join. A black bar with several flows entering it and one leaving it. All flows going into
the join must reach it before processing may continue. This denotes the end of parallel
processing.
 Condition. Text such as [Incorrect Form] on a flow, defining a guard which must
evaluate to true in order to traverse the node.

Bachelor of Science in Informatics Page 6

MOI UNIVERSITY INF 212: BUSINESS SYSTEMS MODELLING

 Decision. A diamond with one flow entering and several leaving. The flows leaving
include conditions although some modelers will not indicate the conditions if it is
obvious.
 Merge. A diamond with several flows entering and one leaving. The implication is that
one or more incoming flows must reach this point until processing continues, based on
any guards on the outgoing flow.
 Partition. Figure 2 is organized into three partitions, also called swimlanes, indicating
who/what is performing the activities (either the Applicant, Registrar, or System).
 Sub-activity indicator. The rake in the bottom corner of an activity, such as in the Apply
to University activity, indicates that the activity is described by a more finely detailed
activity diagram. In Figure 2 the Enroll In Seminar activity includes this symbol.
 Flow final. The circle with the X through it. This indicates that the process stops at this
point.
 Note. Figure 2 includes a standard UML note to indicate that the merges does not require
all three flows to arrive before processing can continue. An alternative way to model this
would have been with an OR constraint between the no match and applicant not on
match list flows. I prefer notes because stakeholders find them easier to understand.
 Use case. In Figure 1 I indicated that the Enroll in Seminar use case is invoked as one of
the activities. This is a visual cheat that I use to indicate that an included use case is being
invoked. To tell you the truth I'm not sure if this is official allowed by the UML but
clearly it should be. Another way to depict this is shown in Figure 2 via the use of a
normal activity although I don't think this is as obvious as using a use case.
The activity diagram of Figure 1 depicts one way to model the logic of the Enroll in University
use case, a very common use of activity diagrams because they enable you to depict both the
basic course of action as well as the alternate courses. Activity diagrams can also be drawn that
cross several use cases, or that address just a small portion of a use case. You can also use
activity diagrams without use cases being involved at all, for example a pair of eXtreme
Programming (XP) developers (Beck 2000) could draw activity diagrams with their customer
(the XP term for stakeholder) to analyze a user story or a larger business process that a user story
supports.

Figure 1. UML activity diagram for the Enroll in University use case.

Bachelor of Science in Informatics Page 7

MOI UNIVERSITY INF 212: BUSINESS SYSTEMS MODELLING

Figure 1 is notable for several things:

1. It depicts the notation that you're likely to use 90% of the time (I'll discuss the more
esoteric notation later).
2. It is incorrect. You can enter the join but never get out of it. When you look at the logic,
you see that you'll either Create a Student Record and then enter the join, or you could
enter the join directly from Display List of Potential Matches when the applicant is on the
list. One but not both of these things will happen, but both are required for you to exit the
join. I really should have used a merge (a diamond) instead of a join bar. Should I update
the diagram? No, because agile models are just barely good enough to get the job done
(this one is, IMHO) and because agile modelers follow the practice update only when it
hurts, and there isn't enough motivation to update this diagram (chances are very good
that once you implemented the logic contained within it that you'd simply erase it
anyway).

Bachelor of Science in Informatics Page 8

MOI UNIVERSITY INF 212: BUSINESS SYSTEMS MODELLING

3. The use of diamonds for decisions and merges is visually wordy but unfortunately all too
common. In Figure 2 I address this issue by placing conditions on flows leaving activities
instead of introducing additional diamonds to represent decision points.
4. It uses a fork to indicate parallel processing, in this case we've decided that we can
perform some of the checks on the applicant in parallel, something that wasn't easy to
indicate using flow charts.
5. It shows how activity diagrams can get large very quickly. Even though it models the
logic of a single use case I was forced to have it wind around the whiteboard because I
ran out of space. Ideally the diagram should be wider, with the logic going from left-to-
right across the board. Better yet, it would be nice to have more whiteboard space.
6. It includes a common mistake. At the very end I applied a decision just before the
Process Payment and Print Receipt processes to indicate that they can be done in parallel.
I should have used a fork, not a decision, for that. I should also use a balancing join,
instead of a merge, although either one would be allowed. The join or merge is required
because both processes need to finish before the overall process ends, without doing this
a race condition effectively exists where the first process to finish would end things.
Figure 2 depicts the Enroll in University use case but takes a different approach than. As noted
above it avoids the use of decision points. It also uses the concept of partitions, also called swim
lanes, to indicate who/what is performing the activity. In this diagram I simply labeled the
partitions with the text Applicant, Registrar, and System although it is also common to put actor
symbols (stick figures) to make it very clear that an actor is performing some activities.
Partitions are useful because they provide more information, but they also elongate the diagram -
I ran out of room and was forced to finish the diagram on another whiteboard (not shown), using
a connector (the circle with the letter A in it), to help show how the physical separate portions fit
together. A common use of connectors is to avoid a line going from one side of a diagram to
another. Instead you show a flow entering a connector and a second flow leaving a similarly
labeled connector, e.g. both connectors have the letter B in them, going into the target activity.
Figure 2 also depicts how to apply a flow final, the circle with the X through it, as well as a note
to indicate a constraint on a merge, as noted above.

Figure 2. UML activity diagram with partitions based on actors.

Bachelor of Science in Informatics Page 9

MOI UNIVERSITY INF 212: BUSINESS SYSTEMS MODELLING

The style of partitions in Figure 2 is often referred to as "swim lanes" because the partitions look
like the lanes in a swimming pool. Figure 3 takes a different approach, I guess you could call the
partitions "swim areas". As you can see swim areas take up less room than swim lanes. It's also
interesting to note that the partitioning strategies between the two diagrams are different - Figure
2 is partition by actor whereas Figure 3 is partitioned by courses of action within a use case. As
always, my advice is to use the strategy best suited for your situation.

Bachelor of Science in Informatics Page 10