Notice of Originality

I declare that this paper is my own work and that information derived from published or unpublished work of others has been

acknowledged in the text and has been explicitly referred to in the list of references. All citations are in the text between quotation

marks (“ ”). I am fully aware that violation of these rules can have severe consequences for my study at Utrecht University.

Signed: Name: Drilon Ferati

Date: 22/04/2016 Place: Utrecht, The Netherlands

Final Paper

Activity Diagram in the Unified Modeling

Language (UML)

Course name: Method Engineering

Course code: INFOME

Faculty of Science

Department of Information and Computer Science

Utrecht University

Princetonplein 5,

3584 CC, Utrecht,

The Netherlands

Student Assistant: Student :

Daniel Alami Drilon Ferati- 5676932

Introduction

Nowadays there are a number of languages that help in modeling software systems. One of the leading

languages in this domain is Unified Modeling Language (UML). Mingsong Xiaokang and Xuandong

(2006) define Unified Modeling Language (UML) as a standard visual modeling language which is

designed for the purpose of specifying, visualizing, constructing and documenting the artefact of software

system. UML was introduced in the mid-90s by Rumbaugh, Jacobson and Booch (2004) and it is

nowadays acknowledged as the standardized language for modeling the structure and behavior of a

system. UML consist of around 13 types of diagrams that aid in model the systems (Pilone & Pitman,

2005). The diagrams are separated in groups of structural modeling (that captures the static feature of the

system) and behavioral modeling (that describes the interaction in the system).

Activity Diagrams, as part of behavioral UML diagrams, are used to graphically represent workflows.

They describe the sequential or concurrent flows of activities in the system (Mingsong et al., 2006).

Activity Diagram displays a sequence of activities, beginning from the starting point of the activity until

the finishing point, by describing in detail the decisions along the progress of the events in the activities

and the overall flow of control. The simplicity of Activity Diagram and the ease of understanding, enables

it to find applicability in a variety of modeling cases such as business process modeling (Brad, 2016),

complex operation modeling, object flow modeling, and lately it is deliberately used for test case and use

case generation. Although this technique does not have an explicit creator, the introduction of the UML

language as a whole signifies also the creation and introduction of Activity Diagram.

For compiling an Activity Diagram a number of procedures should be covered both before and during the

creation of the diagram. Although these procedures are not of a standardized nature, they are advocated as

means that help in better Activity Diagram compilation. The following procedures are combined from the

work of Gomaa, (2011), “Constructing Activity Diagrams,” (n.d.) and Embarcadero Technologies (2009):

Identify the process

Identify the activities

Identify the actors

Identify conditions

Add swimlane

Add transition

Review the diagram

For constructing the activity flow a number of notations are used to describe each state of the activity

flow such as the starting point, ending point, activities, decisions etc. The notations of Activity Diagram

are very similar with the notations of statechart diagram and Petri nets (Eshuis & Wieringa, 2001). Table

1 represents the most used notations in constructing an Activity Diagram, which are adapted from

Lucidchart, (n.d.), together with a detailed description for the corresponding notation. These notations are

also explained in the work of (Eshuis & Wieringa, 2003).

Start - represents the beginning of a process or

workflow in an Activity Diagram.

Activity - indicates the activities that make up a

modeled process and it is the main component of an

Activity Diagram

Connector - arrowed lines that show the directional

flow, or control flow, of the activity. An incoming

arrow starts a step of an activity; once the step is

completed, the flow continues with the outgoing arrow.

Join (synchronization bar) - it combines two

concurrent activities and re-introduces them to a flow

where only one activity occurs at a time and it can be

represented vertically or horizontally

Fork- splits a single activity flow into two concurrent

activities.

Decision - represents the branching or merging of

various flows with the symbol acting as a frame or

container.

Note - allows the diagram creators or collaborators to

communicate additional messages that don't fit within

the diagram itself.

Receive signal - demonstrates the acceptance of an

event. After the event is received, the flow that comes

from this action is completed

Send signal - means that a signal is being sent to a

receiving activity, as seen above

Option loop – used for modeling a repetitive sequence

within the option loop symbol.

Flow final - shows the ending point of a process' flow.

Swimlane- used to separates the activities conducted

by different actors.

End - represents the completion of a process or

workflow.

Table 1- Notations of Activity Diagram

Example Examples for creating Activity Diagrams can be identified easily in our daily life. One of those examples

is shown in the following picture, which describes the workflow of the OV chip card scanners in the

public transportation methods in The Netherland.

Picture 1- Activity Diagram of OV chip card scanners

The actor in this case is the user of the OV chip card who interacts with the card scanner. This indicates

that the Activity Diagram describes the workflow of the card scanner system via a series of use cases with

the first one being the activity of “Scan the OV chip card” in the scanners in order to check in. This is

followed by a decision of the scanner whether the user has sufficient funds in their OV card or not. If the

user does not have sufficient founds a set of concurrent activities that are represented by the fork follow.

The concurrent activities are “Illuminate red light”, that symbolizes the incomplete check in because of

insufficient funds, and “Notify that user has insufficient funds” which is shown in the screen of the

scanner. Afterwards the final activity of “Take away the card from the scanner” follows thus completing

the activity flow.

If in the other case, the user does have sufficient funds in their card for the travel. Again a set of

concurrent activities follow from the “fork”. The concurrent activities are “Illuminate green light” that

indicates that the check in for the trip is done successfully, “Current balance on the card” which indicates

how much funds are left in the card of the user for future travels and “Charge default amount” which

indicates the default amount that the transportation mean charges from the card of the user for the current

trip (this price is different for different transportation mean). These concurrent activities are then

synchronized via the join (synchronization bar), which introduces us to the last activity of “Take away the

card from the scanner”, which is the same with the last activity in the case of not having sufficient funds.

Process Deliverable Diagram

The following segment introduces the process deliverable diagram of Activity Diagram. Referring to the

work of Van de Weerd and Brinkkemper (2008) Process Deliverable Diagram (PDD) is a meta modeling

technique especially developed for method engineering purpose. Van de Weerd and Brinkkemper (2008)

state that “PDD’s are used for analyzing, storing, selecting and assembling the method fragments” which

is in line with the steps defined by van de Weerd, Brinkkemper, Souer, and Versendaal (2006) for

situational method engineering.

In order to compile a PDD, Saeki (2003) approach was taken into consideration, where he proposed the

diagram to have a meta process model, which is based on UML Activity Diagram in the left hand side,

and a meta-data model, based on UML class diagram and depicted on the right hand side. The purpose of

this diagram is to link the semantic information to the artefacts and in the same time to determine their

quality in using this information.

Aside from the PDD an additional activity table is constructed, where all the activities and sub activities

are listed together with a description about each of them, and a separate concept table, where all the

concepts are listed together with a description about their meaning.

Activity Diagram is a modeling technique that finds applicability in a variety of modeling cases, whether

that is for modeling business processes, generating use cases, test cases etc. Even though it is widely

applicable, Activity Diagram up to date has no standardized procedures for its compilation. Most of the

times the procedure that is followed to develop an Activity Diagram varies to the subject at hand. This

making it difficult to produce a proper PDD for Activity Diagram. Figure 1 depicts a PDD of Activity

Diagram where the activities represented are combined from a number of sources such as Gomaa (2011) ,

“Constructing Activity Diagrams” (n.d.), Embarcadero Technologies (2009) and Omg (2010).

Nevertheless this does not necessarily mean that these activities should be followed every time an

Activity Diagram is modeled, as said earlier it all depends to the study at hand for which you are

generating an Activity Diagram and thus in some cases some of the activities depicted in the figure below

can be omitted (i.e. you can have an Activity Diagram without a swimlane).

Figure 1-PDD of Activity Diagram

Activity Sub activity Description

Identification process Identify the process Identify what PROCESS you will model with the

Activity Diagram. Whether it will be a business

process, a use case, test case etc.

Identify activities Identify the ACTIVITY of the PROCESS that you

are modeling.

Identify actors By identifying the ACTOR, it is determined who is

responsible for each ACTIVITY.

Identify conditions Identify all the CONDITION there are in the

PROCESS that need to be satisfied in order to

continue to the next ACTIVITY

Development phase Add the swimlane to

separate the activities

of different actors

Add the SWIMLANE in order to specify the

ACTIVITY that are conducted by a certain ACTOR.

Add transition among

the activities

Add the TRANSITION to show the movement from

one ACTIVITY to the other, and the direction of the

movement.

Review the diagram Review the DIAGRAM to see whether all the

required ACTIVITY have been added and whether

there are CONDITIONs that have not been covered. Table 2- Activity table

Concept Description

DIAGRAM A DIAGRAM is an instantiation of the formal diagram structure that

consist only of semantically and syntactically valid IDEF0 graphic

statement (ISO/IEC & IEEE, 2010). IDEF0 is a technique used for

structured analysis and design of a system (Presley & Liles, 1995).

PROCESS PROCESS is a set of interrelated or interacting activities which transform

input into outputs (ISO/IEC & IEEE, 2010).

ACTIVITY ACTIVITY is a set of cohesive task of a PROCESS (ISO/IEC & IEEE,

2010).

LOCAL PRE-

CONDITION

LOCAL PRE-CONDITION represent constrains that should hold when an

execution of ACTIVITY starts (Omg, 2010)

LOCAL POST-

CONDITION

LOCAL POST-CONDITION represent constrains that should hold when an

execution of ACTIVITY completes (Omg, 2010).

ACTOR ACTOR in which the enterprise object fulfilling the role participates in the

ACTIVITY (ISO/IEC & IEEE, 2010).

CONDITION CONDITION is a description of a contingency to be considered in the

representation of a problem, or a reference to other procedures to be

considered as part of the condition (ISO/IEC & IEEE, 2010).

SWIMLANE SWIMLANE is used to separate the ACTIVITY of different ACTORs.

(Paech, 1998)

HIERARCHICAL

PARTITION

HIERARCHICAL PARTITION used to represent the sub-partitions as

further partitioning of the super-partition (Omg, 2010).

TRANSITION TRANSITION is a change from one state to another state or the same state

(ISO/IEC & IEEE, 2010). Whereas Gomaa (2011) states that

TRANSITION is a movement from one ACTIVITY to another, or the

movement between a state and an ACTIVITY in either direction

REVIEW REVIEW is a process or meeting during which a work product, or set of

work products, is presented to project personnel, managers, users,

customers, or other interested parties for comment or approval (ISO/IEC &

IEEE, 2010) Table 3- Concept table

Related literature

A literature review on Activity Diagram indicated that this type of UML diagram found applicability in a

wide number of researches for a variety of modeling cases. Dumas and Ter Hofstede (2001) examined

how adequate is the Activity Diagram for workflow specification and at the same time evaluated its

ability for capturing workflow patterns. Kalnins and Vitolins (2006) in their work referred to Activity

Diagram as one of the standards for design, execution and administration of business processes together

with Business Process Model and Notation (BPMN). Torres (2004) used Activity Diagram in their work

for modeling agent (which are software entities designed to satisfy specific conditions such as goals)

plans and actions. Other than the previously mentioned researches where Activity Diagram modeling

finds applicability, an emerging domain that uses this kinds of diagrams in the latest years is the one of

test case and use case generation using this type of diagram.

One of the papers that clearly explains why Activity Diagrams find applicability in test case generation is

the paper of Kundu and Samanta (2009). They state that the main reasons of using design model for

program testing is that they can test the dynamic behavior of the system. They make it easier for software

testers to better understand the system and find test information by simply comparing the models with the

code. At the same time the model based test case generation can be conducted at an early stage of

software development cycle by allowing to carry out functions such as coding and testing in parallel. The

results of the research indicated that this approach engendered in reduction of testing effort since it

identifies the location of the fault in the implementation and at the same time this approach was capable

of detecting faults in the loops and synchronization.

Activity Diagram for test case generation is used by many authors, such as Mingsong et al. (2006) who

used Activity Diagram as design specification, in their work, and develop an automatic approach of test

case generation. Then there is the work Chen, Mishra, and Kalita (2008), who also proposed an automated

test case generation approach for the Activity Diagram since they saw the lack of automated techniques

for test generation as one of the bottlenecks of the UML Activity Diagram. Heinecke, Bruckmann,

Griebe, and Gruhn (2010) propose an approach for generating acceptance tests of a high level

automatically from business processes, which processes are modeled as UML Activity Diagrams.

The mentioned literature indicates that the Activity Diagram finds applicability in a wide range of

domains, whether it is for modeling business processes, generating test case scenarios or generating use

case scenarios.

References

Brad, L. (2016). An Adjustment Model For Eva Computation In Financial Institutions And Non-

FIinancial Companies Information System. In ACCOUNTING AND MANAGEMENT

INFORMATION SYSTEMS AMIS 2012 (pp. 1368–1383). Retrieved from

http://www.cig.ase.ro/amis2012/image/amis2012.pdf

Brinkemper, S. (1996). Method engineering: engineering of information methods and tools. Information

and Software Technology, 38(4), 275–280.

Chen, M., Mishra, P., & Kalita, D. (2008). Coverage-driven automatic test generation for UML activity

diagrams. Proceedings of the 18th ACM Great Lakes Symposium on VLSI, 139–142. Retrieved from

http://dl.acm.org/citation.cfm?id=1366145

Constructing Activity Diagrams. (n.d.). Retrieved from https://sourcemaking.com/uml/modeling-

business-systems/external-view/constructing-activity-diagrams

Dumas, M., & Ter Hofstede, A. H. M. (2001). UML Activity Diagrams as a Workflow Specification

Language. Lecture Notes in Computer Science, 76–90. http://doi.org/10.1007/3-540-45441-1_7

Embarcadero Technologies. (2009). Designing a UML 2.0 Activity Diagram. Retrieved from

http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devco

mmon/design20activitydiagram_xml.html

Eshuis, R., & Wieringa, R. (2001). A Formal Semantics for UML Activity Diagrams - Formalising

Workflow Models, 2(612), 1–44. Retrieved from http://doc.utwente.nl/37504

Eshuis, R., & Wieringa, R. (2003). Comparing petri net and activity diagram variants for workflow

modelling -A quest for reactive petri nets. Lecture Notes in Computer Science (including Subseries

Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2472, 321–351.

http://doi.org/10.1007/978-3-540-40022-6_16

Gomaa, H. (2011). Activity Diagrams. In Software Modeling and Design (pp. 89–92). Retrieved from

http://dspace.utamu.ac.ug:8080/xmlui/bitstream/handle/123456789/136/Gomaa-

SoftwareModellingAndDesign.pdf?sequence=1&isAllowed=y

Harmsen, F., Brinkkemper, S., & Oei, H. (1994). Situational Method Engineering for Information System

Project Approaches. Information Systems, 169–194. Retrieved from

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.452.4568&rep=rep1&type=pdf

Heinecke, A., Bruckmann, T., Griebe, T., & Gruhn, V. (2010). Generating test plans for acceptance tests

from UML activity diagrams. 17th IEEE International Conference and Workshops on the

Engineering of Computer-Based Systems, ECBS 2010, 57–66. http://doi.org/10.1109/ECBS.2010.14

ISO/IEC, & IEEE. (2010). ISO/IEC/IEEE 24765:2010 - Systems and software engineering -- Vocabulary.

Iso/Iec Ieee (Vol. 2010). Retrieved from

http://www.iso.org/iso/catalogue_detail.htm?csnumber=50518

Kalnins, A., & Vitolins, V. (2006). Use of UML and Model Transformations for Workflow Process

Definitions. Communications of the 7th International Baltic Conference on Databases and

Information Systems, 12. Retrieved from http://arxiv.org/abs/cs/0607044

Kundu, D., & Samanta, D. (2009). A Novel Approach to Generate Test Cases from UML Activity

Diagrams. The Journal of Object Technology, 8(3), 65. http://doi.org/10.5381/jot.2009.8.3.a1

Lucidchart. (n.d.). UML - Activity Diagram Symbols’ Meaning. Retrieved from

https://www.lucidchart.com/pages/uml-activity-diagram-symbols-meaning

Mingsong, C., Xiaokang, Q., & Xuandong, L. (2006). Automatic test case generation for UML activity

diagrams. Proceedings of the 2006, 2–8. Retrieved from http://dl.acm.org/citation.cfm?id=1138931

Omg. (2010). OMG Unified Modeling Language TM ( OMG UML ), Superstructure v.2.3.

InformatikSpektrum (Vol. 21). Retrieved from http://www.omg.org/spec/UML/2.3/

Paech, B. (1998). On the Role of Activity Diagrams in UML. In The Unified Modeling

Language.«UML»’98: Beyond the Notation (pp. 267–277). Springer Berlin Heidelberg. Retrieved

from http://wwwbroy.informatik.tu-muenchen.de/publ/papers/Pae_UML98.pdf

Pilone, D., & Pitman, N. (2005). UML 2.0 in a Nutshell. O’Reilly Media.

Presley, A., & Liles, D. (1995). The Use of IDEF0 for the Design and Specification of Methodologies.

Proceedings of the 4th Industrial Engineering Research Conference. Retrieved from

https://www.researchgate.net/profile/Adrien_Presley/publication/2447898_The_Use_of_IDEF0_for

_the_Design_and_Specification_of_Methodologies/links/554a57490cf29f836c964ddf.pdf

Rumbaugh, James, Ivar Jacobson, and G. B. (2004). Unified Modeling Language Reference Manual.

Pearson Higher Education, 2004.

Saeki, M. (2003). Embedding metrics into information systems development methods: an application of

method engineering technique. Proceedings of the 15th International Conference on Advanced

Information Systems Engineering, 374–389. Retrieved from

http://dl.acm.org/citation.cfm?id=1758398.1758433

Torres, V. (2004). Using the UML 2 . 0 Activity Diagram to Model Agent Plans and Actions. Retrieved

from http://www.cs.huji.ac.il/course/2005/aisemin/articles2006/docs/pa5a4_594.pdf

van de Weerd, I., & Brinkkemper, S. (2008). Meta-Modeling for Situational Analysis and Design

Methods. Handbook of Research on Modern Systems Analysis and Design Technologies and

Applications, 35–54. http://doi.org/10.4018/978-1-59904-887-1

van de Weerd, I., Brinkkemper, S., Souer, J., & Versendaal, J. (2006). A situational implementation

method for web-based content management system‐ applications: method engineering and

validation in practice. Software Process: Improvement and Practice, 11(5), 521–538.

Key Terms

Method engineering- the engineering discipline to design, construct and adopt methods (Brinkemper,

1996)

Method fragment- a coherent piece of an IS development method (Brinkemper, 1996)

Situational method – information system development method tuned to the situation of the project at

hand (Harmsen, Brinkkemper, & Oei, 1994)