notice of originality i declare that this paper is my own ...5676932/me/final_5676932_ferati.pdf ·...
Post on 27-Apr-2018
213 Views
Preview:
TRANSCRIPT
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)
top related