View
217
Download
0
Category
Preview:
Citation preview
Intelligent Support for Context Sensitive
Business Process Modelling
Florendia Kartsouni-Fourli
TH
E
U N I V E RS
IT
Y
OF
ED I N B U
RG
H
Master of Science
Artificial Intelligence
School of Informatics
University of Edinburgh
2004
Abstract
Business Process Modelling (BPM) and Workflow technologies are fundamental
to many business process re-engineering initiatives. Not all BPM and Workflow
technologies, however, manipulate information that is context-sensitive. In fact,
currently, none of the standard semantic web related workflow languages provides
sufficient support for this.
This project aims to provide an intelligent support tool for a semantic based
BPM language, the Fundamental Business Process Modelling Language (FBPML).
The tool created enables the generation of semantic business process models that
integrates and interacting with context sensitive information/knowledge - that is
ontology based. In addition it provides automatic modelling assistances based on
inferred information derived from the underlying model(s). Theoretical as well as
empirical evaluations of the system were carried out as part of the project based
on the methodology and trials on real modellers.
i
Acknowledgements
I would like to thank my supervisor, Yun-Heh (Jessica) Chen-Burger, for all the
valuable help, advice and guidance she provided me with during all the stages
of this project. Many thanks also to my family and friends for supporting me
throughout this MSc course.
ii
Declaration
I declare that this thesis was composed by myself, that the work contained herein
is my own except where explicitly stated otherwise in the text, and that this work
has not been submitted for any other degree or professional qualification except
as specified.
(Florendia Kartsouni-Fourli)
iii
Table of Contents
1 Introduction 1
2 FBPML Background 4
2.1 IDEF3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Process Specification Language . . . . . . . . . . . . . . . . . . 5
2.3 FBPML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Comparison between IDEF3, PSL and FBPML . . . . . . . . . . 9
2.4.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 System Requirements 12
3.1 Overall Description . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Functionality Specification . . . . . . . . . . . . . . . . . . . . . 13
3.3 Interface Specification . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Performance Requirements . . . . . . . . . . . . . . . . . . . . . 14
3.5 Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6 Portability Requirements . . . . . . . . . . . . . . . . . . . . . . 15
4 System Design 17
4.1 High Level Design . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Model Support Framework . . . . . . . . . . . . . . . . . 17
4.1.2 UML Package Diagram . . . . . . . . . . . . . . . . . . 18
4.2 Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
v
4.3 Model Building Design . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Model Verification Design . . . . . . . . . . . . . . . . . . . . . 22
5 Technical Details 25
5.1 The Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 The functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.1 The inference engine . . . . . . . . . . . . . . . . . . . . 27
5.2.2 FBPML Formal Definitions . . . . . . . . . . . . . . . . 27
5.2.3 Ontology Formal Definitions . . . . . . . . . . . . . . . . 30
5.2.4 Model Verification Axioms . . . . . . . . . . . . . . . . . 30
6 Use of the System 40
6.1 User Support Framework . . . . . . . . . . . . . . . . . . . . . . 40
6.1.1 Model Building . . . . . . . . . . . . . . . . . . . . . . . 41
6.1.2 Model Verification . . . . . . . . . . . . . . . . . . . . . 58
6.2 Example User scenario . . . . . . . . . . . . . . . . . . . . . . . 61
7 Evaluation 66
7.1 Evaluation Framework . . . . . . . . . . . . . . . . . . . . . . . 66
7.2 Theoretical Evaluation . . . . . . . . . . . . . . . . . . . . . . . 67
7.2.1 Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.2.2 Assessment . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.3 Empirical Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 71
7.4 Comparison with Relevant Modelling Tools . . . . . . . . . . . . 75
8 Conclusions and Future work 80
8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.2 Discussion of Results . . . . . . . . . . . . . . . . . . . . . . . . 82
8.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A Definitions File 85
vi
B Prolog Rules 87
B.1 Inconsistency Rules . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.2 Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.3 Semantic Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.4 Loop Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B.5 General Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C Error Messages 95
C.1 Inconsistency Messages . . . . . . . . . . . . . . . . . . . . . . . 95
C.2 Syntax Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 95
C.3 Semantics Messages . . . . . . . . . . . . . . . . . . . . . . . . 96
C.4 Loop Detection Message . . . . . . . . . . . . . . . . . . . . . . 96
D Evaluation Questionnaire and Results 97
D.1 Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
D.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Bibliography 115
vii
List of Figures
2.1 FBPML Notation (KBST-EM screenshot) . . . . . . . . . . . . . 7
2.2 FBPML Junctions (KBST-EM screenshot) . . . . . . . . . . . . . 8
4.1 The system’s UML Package Diagram . . . . . . . . . . . . . . . 19
4.2 The system’s Interface UML Class Diagram . . . . . . . . . . . . 20
4.3 First level of the Model UML Class Diagram . . . . . . . . . . . 21
4.4 Second level of the Model UML Class Diagram - Process Diagram 22
4.5 Second level of the Model UML Class Diagram - Ontology Diagram 23
4.6 Model Verification UML Class Diagram . . . . . . . . . . . . . . 24
6.1 The system’s Main Window . . . . . . . . . . . . . . . . . . . . 41
6.2 Expansion of the model menu . . . . . . . . . . . . . . . . . . . 41
6.3 Diagram Name Request window . . . . . . . . . . . . . . . . . . 42
6.4 The Process Diagram Panel . . . . . . . . . . . . . . . . . . . . . 42
6.5 The Process Diagram Toolbar . . . . . . . . . . . . . . . . . . . . 43
6.6 The FBPML Notation Diagram . . . . . . . . . . . . . . . . . . . 44
6.7 Right-click Activity Menu . . . . . . . . . . . . . . . . . . . . . 45
6.8 The Activity Label text box . . . . . . . . . . . . . . . . . . . . . 46
6.9 The Activity Properties window . . . . . . . . . . . . . . . . . . 46
6.10 Right-click Activity ID Menu . . . . . . . . . . . . . . . . . . . . 47
6.11 Junctions that can be defined . . . . . . . . . . . . . . . . . . . . 48
6.12 The Ontology Diagram Panel . . . . . . . . . . . . . . . . . . . . 49
6.13 The Ontology Diagram Toolbar . . . . . . . . . . . . . . . . . . . 49
viii
6.14 The Ontology Notation Diagram . . . . . . . . . . . . . . . . . . 50
6.15 Right-click Concrete class Menu . . . . . . . . . . . . . . . . . . 51
6.16 The Concrete class Properties window . . . . . . . . . . . . . . . 52
6.17 The Concrete class Object Attributes window . . . . . . . . . . . 52
6.18 The Instance Object Attributes window . . . . . . . . . . . . . . 53
6.19 No Concrete Class error . . . . . . . . . . . . . . . . . . . . . . . 54
6.20 No Concrete Class Object Attributes error . . . . . . . . . . . . . 54
6.21 The Save As File Browse window . . . . . . . . . . . . . . . . . 55
6.22 A model as it opens . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.23 Close warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.24 Exit warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.25 Modelling Support Menu . . . . . . . . . . . . . . . . . . . . . . 59
6.26 The JIProlog warning . . . . . . . . . . . . . . . . . . . . . . . . 59
6.27 ”No Errors” checking message . . . . . . . . . . . . . . . . . . . 59
6.28 Checking Errors message . . . . . . . . . . . . . . . . . . . . . . 60
6.29 Model ”Simple Model” loaded on screen . . . . . . . . . . . . . . 61
6.30 Properties of activity ”Receive Order” . . . . . . . . . . . . . . . 62
6.31 JIProlog warning . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.32 The Consistency errors detected in the model . . . . . . . . . . . 64
6.33 The corrected model . . . . . . . . . . . . . . . . . . . . . . . . 64
6.34 The ”No Errors” message . . . . . . . . . . . . . . . . . . . . . . 65
6.35 Saving the model as ”Simple Correct Model” . . . . . . . . . . . 65
7.1 Fault created when connected node is deleted . . . . . . . . . . . 74
D.1 Notation Process Diagram . . . . . . . . . . . . . . . . . . . . . 98
D.2 Notation Ontology Diagram . . . . . . . . . . . . . . . . . . . . 99
D.3 PC Configuration Process Diagram . . . . . . . . . . . . . . . . . 100
D.4 PC Configuration Ontology Diagram . . . . . . . . . . . . . . . . 101
D.5 ”Top Level Process” Process Diagram . . . . . . . . . . . . . . . 102
D.6 ”Domain Ontology” Ontology Diagram . . . . . . . . . . . . . . 102
D.7 ”PC ConfigurationErrors” Process Diagram . . . . . . . . . . . . 104
ix
List of Tables
2.1 Comparison Between IDEF3, PSL and FBPML . . . . . . . . . . 10
7.1 FBPML Notation Compliance and Support Assessment . . . . . . 68
7.2 Ontology Notation Compliance and Support Assessment . . . . . 69
7.3 Summary of usability test results . . . . . . . . . . . . . . . . . . 73
7.4 Comparison of Modelling Tools . . . . . . . . . . . . . . . . . . 77
xi
Chapter 1
Introduction
Most enterprises have been using information technology for many years in order
to automate and speed up their processes. However, this has proven not enough
when they face the new competitive and continuously changing business environ-
ment of our days. In order to regain their competitive edge and to provide high
quality services/products many businesses take Process Reengineering initiatives.
Business Process Reengineering (BPR) is a Knowledge Management approach
which addresses the issue of structural integration by re-organising enterprises
along critical business processes, such as the supply chain and the product life
cycle (Hammer and Champy (1993)).
Business Process Modelling and Workflow technologies play a key role in
such initiatives. Business process modelling is a technique used to analyse and
model business processes (Curtis et al. (1992)). Workflow is used to describe
business process tasks at a conceptual level necessary for understanding, evaluat-
ing, and redesigning the business process (Georgakopoulos et al. (1995)).
Many Modelling languages exist in order to describe Business Process and
Workflow models. They are usually part of a modelling method and include their
own notation, syntax and semantics. They usually differ in the level of formal-
ism that they use and in the level of information that they can capture in the
models. However not all of them manipulate information and knowledge that
is context-sensitive. Currently, none of the standard semantic web related work-
1
Chapter 1. Introduction 2
flow languages provides sufficient support for this. They often provide means to
describe the name of (sub)processes and some information about the data that the
processes manipulate. Nevertheless, they are not able to describe data in such a
way that maybe used as an integral part of their process descriptions (i.e. describ-
ing it in actions). This makes the models produced less flexible and limits their
applications.
This project focuses on a semantic based BPM language, the Fundamental
Business Process Modelling Language (FBPML) Chen-Burger et al. (2002). This
language is based on the merging and adaptation of two recognised Process Mod-
elling languages PSL (Schlenoff et al. (1997)) and IDEF3 (IDEF3 (1995)). In
addition it uses simple Ontology notation which enables the creation of systemat-
ically ordered data structures that enhance the definition and sharing of domain-
specific vocabularies.
The project’s aim is to provide an intelligent support tool for the FBPML
method which will:
• Enable the generation of semantic business process models and their inte-
gration with context sensitive information/knowledge.
• Enable the generation of simple ontological models which can hold the in-
formation entities of the domain.
• Provide automatic modelling assistances based on inferred information de-
rived from the underlying model(s).
Such a tool can be useful to a wide range of users desiring to create Business
Process Models. Essentially the target was for the tool to be equally usable by a
project manager as well as a software analyst. Thus communication gaps between
such different knowledge sources in an enterprise could be bridged. In addition it’s
ability to manipulate context sensitive information gives it great future expansion
capabilities. To name only a few:
• It could be enhanced with workflow enactment capabilities and prove valu-
able for process reengineering activities.
Chapter 1. Introduction 3
• It could be enhanced with automatic translation of the models to a standard
semantic web services language such as OWL-S (OWL-S (2004)) and act
as a modelling tool for web services (Guo et al. (2004)).
In this thesis a detailed description of the work undertaken is provided in the
following chapters:
• Chapter 2, ”FBPML Background”: including background information about
the language specifications as well as its notation and semantics.
• Chapter 3, ”System Requirements”: including a brief requirements specifi-
cation for the tool developed.
• Chapter 4, ”System Design”: including a design specification for the tool
developed.
• Chapter 5, ”Technical Details”: including a technical specification of the
tool developed.
• Chapter 6, ”Use of the System”: describing how the system can be used by
a potential user, including a user scenario.
• Chapter 7, ”Evaluation”: discussing the criteria and results of a thorough
evaluation of the system.
• Chapter 8, ”Conclusion and Future Work”: including a final discussion on
the system created and its expansion capabilities.
Chapter 2
FBPML Background
A business process modelling method requires a ”language” in which the models
are described. The language of the method includes a particular notation, a syn-
tax for the notation elements and the semantics of these elements. The FBPML
language was based on a merging an adaptation of two recognised modelling lan-
guages IDEF3 and Process Specification Language (PSL).
2.1 IDEF3
IDEF3 1 is a process description capture method created specifically to capture
descriptions of sequences of activities. The method also enables capturing of the
objects that participate in the process, supporting objects, and the precedence and
causality relations between processes and events in the environment.
The primary goal of IDEF3 is to provide a well-structured method by which a
domain expert can express knowledge about the operation of a particular system or
organisation. The method includes two different forms of models: a process flow
description describing ”how things work” in an organisation and an object state
transition network focusing on objects and their state change behaviours(Mayer
et al. (1995)).
1As described in Mayer et al. (1995)
4
Chapter 2. FBPML Background 5
An IDEF3 process flow description captures a description of processes and the
relationships between them. It provides a graphical and structural representation
that domain experts and analysts from different disciplines can use to communi-
cate with each other. This includes knowledge about events and objects involved
in the process, and the constraining relations which determine the behaviour of
each occurrence (process and object). It uses UOB (units of behaviour), links,
junctions, referents and notes to represent the processes and their relationships
(such as temporal ordering).
Overall it is a well structured and mature method however, it lacks formal
semantics of its notation. This often leaves the models defined open to interpreta-
tion.
2.2 Process Specification Language
Process Specification Language2 (PSL) is an interchange language that allows ap-
plications to exchange discrete process data. It can serve as a common language
between different applications and can captures the necessary process informa-
tion from any given application. The goal of PSL is to facilitate communication
between those applications by using PSL-based translators.
PSL provides formal specification for semantics in process models. This can
be described as the PSL ”ontology” as it focuses not only on the terms of the
ontology but also their meanings. The PSL ontology has three notions: language,
model theory and proof theory. A language is a lexicon (a set of symbols) and a
grammar (a specification of how these symbols can be combined to make well-
formed formulas). Logical (e.g. boolean, quantifiers) and nonlogical symbols
(e.g. constants, functions, symbols, and predicates) are used in order to define a
lexicon.
In model theory, PSL provides a mathematical characterization of the seman-
tics, or meaning, of the language of PSL. Proof theory consists of three compo-
2As described in Schlenoff et al. (1997)
Chapter 2. FBPML Background 6
nents: PSL core, foundational theories, and PSL extensions. The PSL core is a set
of axioms written in the basic language of PSL. These axioms provide a syntactic
representation and semantic description of the PSL model theory A foundational
theory has sufficient expressive power for giving precise definitions of, or axiom-
atizations for, the primitive concepts of PSL. PSL extensions are expressions that
are not included in the PSL core. It provides extra usage for expressing more
complicated processes.
Overall PSL provides strict formal definitions of its concepts however, it lacks
a visual presentation of the models. This means that users cannot easily use this
language if they do not obtain proper training in logical languages.
2.3 FBPML
FBPML being based on the two previous methods was an effort to bring formal
semantics for the notation together with a more flexible visual presentation of
concepts.
This language is designed to support both software and workflow system de-
velopment. It offers precise semantics and can express business processes in log-
ical sentences Kuo et al. (2003).
Chapter 2. FBPML Background 7
2.3.1 Notation
Figure 2.1 shows the FBPML notation as it is displayed by KBST-EM(Knowledge
Based Support Tool for Enterprise Models, Chen-Burger (2001)).
Figure 2.1: FBPML Notation (KBST-EM screenshot)
The notation consists of: main nodes, junctions, links and annotations.
Main nodes:
• Activity: which denotes the type of process that may be decomposed or
specialised into subprocesses.
• Primitive Activity: which denotes a leaf node activity that may not be fur-
ther decomposed or specialised.
• Role: which denotes an enabler that includes a set of activities and may
have responsibilities for these activities.
• Time Point: which indicates a particular point in time during the enactment
Chapter 2. FBPML Background 8
of a process model. A duration of a time interval is indicated by two time
points.
Links:
• Precedence link: which places a temporal constraint on process execution.
For example the precedence link between activities A and B in figure 2.1
defines that the execution of activity B may NOT start before the execution
of Activity A is finished.
• Synchronisation Bar: which places a temporal constraint between two time
points. For example the synchronisation bar between activities C and and D
in figure 2.1 defines that the begin time of activity C should be synchronised
with the end time of activity D.
Figure 2.2: FBPML Junctions (KBST-EM screenshot)
Junctions:
• Start and Finish junctions: which indicate the logical starting and finishing
points of a process.
Chapter 2. FBPML Background 9
• And and Or junctions: depicted in figure 2.2 (a KBST-EM screenshot as
well) can be broken down to:
◦ And Joint: indicating the process execution flow and temporal con-
straint that all of the preceding activities (A, B, C) must be finished before
the following activity (D) can be executed.
◦ Or Joint: indicating the process execution flow and temporal con-
straint that only one of the preceding activities (A, B, C) is required to be
finished before the following activity (D) can be executed.
◦ And Split: indicating the process execution flow and temporal con-
straint that all of the following activities (A, B, C) must be executed after
the preceding activity (D) is finished.
◦ Or Split: indicating the process execution flow and temporal con-
straint that only one of the following activities (A, B, C) is required to be
executed after the preceding activity (D) is finished.
Annotations:
• Idea Note: which records textual information that is relevant to, but outside
the scope of, a process model.
• Navigation Note: which records the relationships between diagrams in a
model.
2.4 Comparison between IDEF3, PSL and FBPML
A detailed comparison between the three languages was not carried out in this
project. This is because it already exists both in Kuo et al. (2003) and Kuo (2002)
in a very complete form. However, the comparison table provided in Kuo et al.
(2003) and a small discussion in included here for the interested readers.
Chapter 2. FBPML Background 10
ITEM IDEF3 PSL FBPML
Property Process modelling Interchange language Business modelling
language between different language especially
manufacturing supports software and
applications workflow system
development
Notation Rich Graphic Ontology and Simpler version
notation formal semantics notation but semantics
are presented
Basic Process UOB(Unit of Activity, Activity,
Description Behaviour) Primitive-Activity Primitive-Activity
Distinguish terms
between process,√ √
×activity and
task
Link between Precedence links Ordering Precedence Link
processes with different Relation over Synchronisation
types of activities(ext) bar
constraints
Junction AND, OR, XOR AND, OR, XOR,√
(not the same as
junction(core) PSL and IDEF3 but
junction (ext) is an extension and
refinement of both
Time not in the Duration(ext) time point,
notation but Temporal Ordering duration,
may be expressed Relation(ext) length
informally
Role × ×√
Annotation Referent and Note × Idea Note
Navigation Note
Decomposition A process may be SubActivity(ext) A process may be
decomposed into decomposed into
subprocesses subprocesses
Specialisation√
×√
Execution Logic × ×√
Table 2.1: Comparison Between IDEF3, PSL and FBPML from Kuo et al. (2003)√
=Yes
×=No/Not Applied
core=PSL core concept
ext=PSL extension concept
Chapter 2. FBPML Background 11
2.4.1 Discussion
From this comparison table 2.1 we can draw the following conclusions:
• All the languages use process expression techniques in order to provide a
standard methodology when describing a process.
• As discussed in the language description IDEF3 provides a graphical way
to represent processes, allowing the logic of processes to be more easily
represented however, it lacks an unambiguous semantic description for its
notation.
• Opposite from IDEF3 PSL has a well-defined ontology and formal seman-
tics but lacks graphical notations.
• FBPML combines aspects of both IDEF3 and PSL to obtain the advantages
of their different aspects. It provides a simpler and more pragmatic mod-
elling language suitable for workflow system design.
Chapter 3
System Requirements
This MSc project required the creation of an intelligent support tool for the FBPML
language. The requirements of this tool were carefully specified during the very
early stages of this project. A requirements specification was created and is fully
included in this chapter. This specification is based on the guidelines provided by
IEEE (1998).
3.1 Overall Description
The intelligent support tool was to be an independent and totally self-contained
system, capable of:
• Enabling the description of semantic Business Process Models and Data
Models (Ontology)
• Providing automatic modelling assistances e.g. Inconsistency checking and
guidance for error-correction
The potential user group for the tool would be any person with basic knowl-
edge in Business Process Modelling. No further particular technical knowledge
of the person was assumed. In order to distinguish this work from other relevant
existing modelling tools great focus was given to attributes such as portability,
usability, report generation and modelling assistances provided.
12
Chapter 3. System Requirements 13
3.2 Functionality Specification
In detail the functionality of the system had to enable the user to:
• Create models consisting of Business Process Models using the FBPML
notation and Data Models using Ontology notation, which would comply
with the FBPML-DL definitions (Chen-Burger (2002a)).
• Define particular properties for model elements such as:
1. Activity: Triggers, Preconditions, Postconditions, Actions
2. Class: Description, Example, Rules, Cross-Reference, Object At-
tributes
3. Instance: Object Attributes
• Manipulate the models e.g. performing editing, saving, opening, closing.
• Use modelling assistances to perform:
1. Inconsistency checking of the models
2. Syntactic checking of the models
3. Semantic checking of the models
4. Detection of semantic loops in the models
• Create reports of the results of the modelling assistances performed.
• Save a collection of models as one ”project”1
3.3 Interface Specification
The system had to include a user-friendly interface enabling users of all levels of
expertise to use the functionalities specified above. This interface was required to
have the following elements:
1A ”project” is defined by the application as a ”model” and it can consist of various BusinessProcess and Ontology ”diagrams”. It is very important that this separation is kept in mind by thereader as it is used throughout this document
Chapter 3. System Requirements 14
• A main area including the main menu of the application.
• Internal areas including the tool bars and the area required for the creation
and editing of the diagrams.
• Output messages to the user including:
1. Error messages to inform the user of attempt of illegal actions.
2. Warning messages reminding the user to save changes before closing
a model or exiting the application.
3. Comprehensive and well presented messages of the results of the
modelling assistances.
More specifically the internal model creation areas should enable:
• More than one diagrams to be displayed at the same time, organised in a
way that as many of them as possible are visible at the same time.
• Diagrams to be minimised and appear by title at the bottom of the desktop
pane.
• Diagrams to be resized or maximised to fit the size of the application win-
dow.
3.4 Performance Requirements
Since this system is to be used atomically by each user the only performance
requirements specified were the following:
• Highly complex models should be able to be opened and saved relatively
fast.
• Modelling assistances should be able to be executed relatively fast even
when acting on large and complicated models.
Chapter 3. System Requirements 15
• Saved models should occupy minimum space even if they are highly com-
plex.
• In general the user should be able to use all of the functionalities specified
above without serious time delays or space constraints.
3.5 Design Constraints
The most important design constraints are related to the system’s diagram creation
capabilities. In particular the following constraint was specified:
• The design of the elements for the creation of models should maintain an
immediate mapping to the existing notation for both FBPML and Ontology.
This constraint ensures full compliance of the models created by the system
with the methodology of the particular modelling languages.
3.6 Portability Requirements
Portability was a very important issue for the particular system created. First of all
high portability would give this tool a great advantage over many existing mod-
elling tools. In addition portability can ensure the future expansion opportunities
of the system. For example such a system could be easily transformed to be used
through a web browser or/and in relation with semantic web technologies or be
integrated into a web service. Such expansion capabilities are discussed in detail
in chapter 8. For all these reasons the following requirements were specified:
• The system should be able to run on a wide range of platforms.
• The system should be able to work within the web environment.
Due to these requirements the Java programming language was chosen for the
development of the system. The Java language ensures that both of the portability
Chapter 3. System Requirements 16
requirements are met. This is because software written in Java can run on most of
the commonly used platforms and within a web browser. The use of Java for all
the system’s components is described in detail in chapter 5.
Chapter 4
System Design
The design of the system was based on the requirements specification described in
the previous chapter. This chapter describes all the different levels of design using
UML (Unified Modelling Language) diagrams. UML diagrams are particularly
appropriate for this systems design as they can incorporate the object-oriented
concepts of the Java language.
4.1 High Level Design
4.1.1 Model Support Framework
At the highest level of design a Model Support framework was created to include
all the functionality required for the system. It is a hierarchical framework:
• Model support framework
◦ Model building framework
- Model creation
- Model updating
- Model archiving
◦ Model verification framework
17
Chapter 4. System Design 18
- Consistency checking
- Syntactic checking
- Semantic checking
- Detection of semantic loops
4.1.2 UML Package Diagram
In order to reflect this framework on the system’s organisation, a UML Package
Diagram was created (see figure 4.1). Package Diagrams are not official UML dia-
grams. However their use is quite common by Object-Oriented software designers
as they provide a way to divide and organise model elements such as classes into
groups that provide related services.
Three packages were defined for the particular system:
• Package GUI (Graphical User Interface) contains the class responsible for
the interface of the application.
• Package ”Model Building” contains the classes responsible for model build-
ing framework functionality.
• Finally package ”Model Verification” contains the classes responsible for
the model verification framework functionality.
The arrows in the diagram denote the dependencies between the packages. Both
packages Model Building and Model Verification depend on package GUI as they
use its interface services. In addition package Model Verification depends on
package Model Building because it uses the information about the model’s dia-
grams, in order to perform checking on a model.
4.2 Interface Design
The interface of the system was designed to be one class implementing all of
the interface requirements. The UML class diagram in figure 4.2 describes the
Chapter 4. System Design 19
Figure 4.1: The system’s UML Package Diagram
interface ApplicationWindow class including its attributes and operations. The
particular class diagram is very detailed in that it contains the Java types of the
attributes and of the operations inputs and outputs. This level of detail is useful
as it allows a reader with some knowledge in the Java programming language to
understand the realisation of the specified requirements for the system’s interface
in this class. In particular its easy to see that the interface consists of a main
window (a Desktop Pane) containing two menus namely Model and Modelling
Support. Menu Model contains the menu items for specifying a new model (i.e.
project), adding Process and Ontology diagrams to the model, saving the model,
opening an existing model, closing the model, and exiting the application. Menu
Modelling Support contains the menu items for checking the models Consistency,
Syntax and Semantics and detecting Semantic loops in the models.
In addition the required methods for performing some of the above menu ac-
tions are included in the class’s operations. In particular the method for adding
new diagrams to the model (addNewDiagram) creates new Internal Frames that
act as containers for the diagram classes included in the Model Building package.
Model Building classes are responsible for the drawing and editing of Process and
Chapter 4. System Design 20
Figure 4.2: The system’s Interface UML Class Diagram
Ontology diagrams. A choice was made that even though Model Building classes
also contain interface properties (menu bar for adding diagram elements etc.), they
are not included in the GUI package. This is because it was considered wiser to
hold together all the classes which are responsible for the diagrams elements and
attributes. In order to ensure full satisfaction of the requirements, more than one
Internal Frames can exist simultaneously in the Main Window and they can be
minimised or maximised according to preference.
4.3 Model Building Design
It should be obvious to the reader at this stage that the word ”model” is used for a
collection of FBPML process and Ontology diagrams.
The design for the system’s capabilities of drawing and editing such diagrams
was completely based on the particular modelling languages notation elements.
A direct mapping was attempted between the UML class diagrams created and
Chapter 4. System Design 21
Figure 4.3: First level of the Model UML Class Diagram
the notation. For the shake of clearer viewing the UML class diagram has been
broken to three levels. The first level (figure 4.3) shows the class Model and its
aggregation relationship to classes ProcessDiagram and OntologyDiagram. The
second level shows further relationships of the ProcessDiagram class (see figure
4.4) and the OntologyDiagram class (see figure 4.5) with other classes.
This UML diagrams are much more abstract than the ones before. They only
include class names and basic relationships. It was considered that more detail
would make the UML diagrams far too complex to display. In addition this level
of detail is enough for the reader to understand the mapping between the design
and the modelling languages notation.
In both diagrams the arrows from the main diagram class to classes Node and
Chapter 4. System Design 22
Figure 4.4: Second level of the Model UML Class Diagram - Process Diagram
Link are aggregation arrows denoting that a diagram is a collection of nodes and
links. The rest of the arrows in both diagrams are generalisation arrows denoting
that a class is a subclass of another, for example Start class is a subclass of class
Junction (or startis a type of junction). All the classes implementing elements
of the notation include attributes of their appearance (shape, size) and rendering
operations. Most of these are inherited by the JGraph Java library (see JGraph
(2004)), which use is discussed in detail in chapter 5.
4.4 Model Verification Design
A decision had been taken early in the project to use an inference engine in order
to perform the checking on the models. This demands the design of the classes
that will handle this type of checking.
Chapter 4. System Design 23
Figure 4.5: Second level of the Model UML Class Diagram - Ontology Diagram
Figure 4.6 shows the UML Class Diagram for Model Verification.
Class ModelCheck is the class that creates the representation of the model in
logic with method createmodel representation(). Method performcheck() uses
the association link to class LogicCheck in order to call an inference check (per-
form inference()) on this model representation. Class LogicTest invokes the in-
ference engine, performs the test and then returns the result to class ModelCheck.
This class can then use the association link to class MessageToUser in order to
call a method (createmessage()) which will process this result and return it as a
formatted message ready to be displayed to the user. Of course the message to
the user is output on the screen by using the interface class in the GUI package,
hence the relationship between the packages mentioned earlier. It should be noted
that all the different types of model checking (Consistency, Syntax and Semantic
checking and Loop Detection) use exactly the same classes and methods and are
Chapter 4. System Design 24
Figure 4.6: Model Verification UML Class Diagram
just distinguished by the use of different parameters.
More technical details regarding the use of the inference engine for the Model
Verification functionality are included in section 5.2.1 of this document.
Chapter 5
Technical Details
The system was implemented according to the design described in chapter 4. As
it has already been mentioned it was decided that the system was implemented
using the Java programming language. This chapter provides details about all
the methods and technologies used for the implementation of the system. These
details are provided separately for the two major components of the system: the
interface and the functionality.
5.1 The Interface
The ”Menu and Messages” interface’s technical implementation was based on
straightforward use of common Java Swing UI classes.
The graphical interface used to create the models was based on the JGraph li-
brary (JGraph (2004) version 3.14). JGraph is an open source graph visualization
Java library. As described in Gaudenz (2003), JGraph provides a fully standards-
compliant graph component for the Java Swing UI library that supports extended
display and editing options, however the semantics of the graph, that is, the mean-
ing of the vertices and edges, is defined by the application. Therefore, JGraph is
highly customisable, and the classes provide ”hooks” for subclasses.
The implementation of JGraph is entirely based on the source code of the
JTree class JTree (2004), which is Swing’s component for displaying trees. How-
25
Chapter 5. Technical Details 26
ever the components for trees and lists are mostly used to display data structures,
whereas this graph component is typically also used to modify a graph, and han-
dle these modifications in an application-dependent way. JGraph complies with
all of Swing’s standards, such as pluggable look and feel, data transfer, accessibil-
ity, internationalisation, and serialization. Also, all concepts used in JGraph are
common, well-known concepts from Swing.
Most of the classes of the JGraph library were customised, by inheriting their
features to create the graph related classes required by the system. This way the
system was enabled to include graphical representations of FBPML and Ontology
elements that comply fully with the specified notation.
The use of the JGraph library proved easy and straightforward to use on most
cases. In addition it provided the classes to build on in order to produce a notation
compliant, user-friendly interface for the models creation capabilities of the sys-
tem. However it should be mentioned that the particular choice also caused certain
restrictions on the graphical interface mainly on cases that further customisation
was two difficult to occur within the specified time limits. Some of those problems
are discussed in the Evaluation chapter.
5.2 The functionality
The ”Model Manipulation” functionality of the system was based on the serial-
ization capabilities of the JGraph library discussed in the previous section. The
models were saved as Serializable objects given the arbitrary extension ”.model”.
The FBPML activity’s Properties and Ontology concrete class’s Properties and
Object Attributes and Instance Object Attributes are saved as attributes of a Map
included in the Serializable Object.
The ”Model Verification” functionality was based on the formal representa-
tions of the FBPML and Ontology models and the use of a collection of rules
used by a Prolog inference engine. More specifically, on request of a model check
the system generates a file including the formal representation of the model in
Chapter 5. Technical Details 27
First Order Predicate Logic (an example of such a file is included in Appendix A).
A Knowledge Base is created consisting of this file and the predefined inference
rules. The inference engine is then carrying out the relevant checking based on
this Knowledge Base.
5.2.1 The inference engine
Prolog is a programming language widely used in Artificial Intelligence to imple-
ment, at higher level, ”smart” applications as a set of logical axioms and inference
rules. However Prolog interpreters are very hard to use within web servers or
browsers. Trying to maintain the portability of the system a list of option where
examined. You can see some of these options on Declarativa Servinos de Infor-
matica, Lda (2004). The final decision was to use the JIProlog - Java Internet
Prolog JIProlog (2004), which is a pure Java prolog interpreter.
As described in Ugo (2004) JIProlog is based on a WAM (Warren Abstract
Machine) implemented using a LISP-like algorithm. It is composed of a set of
Java classes implementing the WAM and the typical prolog mechanisms (such as
backtracking etc.), a manager for built-in predicates , a parser for the Prolog lan-
guage and so on. In addition it implements a mechanism to call Prolog predicates
from any Java classes and vice versa. The part of the API used by the particular
system was the one regarding the way to invoke Prolog from Java. A particular
class was written which is responsible for starting the Prolog inference engine,
consulting the necessary files and recording the results.
In all the JIProlog component proved very useful, as it was fairly easy to use
and maintained the system’s portability features guaranteed by the use of the Java
programming language.
5.2.2 FBPML Formal Definitions
The notation of FBPML was fully represented in First Order Predicate logic. In
detail the elements of the notation were defined as follows:
Chapter 5. Technical Details 28
Activity: Activity as described in Chen-Burger et al. (2002) can be defined by
the tuple:<HP,Activity name,Tigger,Precondition,Action>. However the defini-
tion used by this system was slightly different. Firstly Hierarchical Position was
not used directly by the Model Verification Framework of the system, so it was not
included in the definition. Secondly our definition includes the property Postcon-
ditions that the Chen-Burger et al. (2002) definition does not include as it regards
it as derivable from the pre-conditions and Actions of a process.
In addition our definition includes ID (the identity of the activity as defined
by the user), which is used in the Modelling Framework for syntactic checking as
well as tracking purposes. Hence the new predicate for activity was defined as:
activity(ID,Name,Trigger,Precondition,Postcondition,Action)
Since each activity can contain more than one of triggers, preconditions or post-
conditions, these where actually each represented as a collection of constants
(e.g. Trigger=[TriggerA,TriggerB,TriggerC]). For the same reason Actions were
represented as a collection of the predicate ”action” which was defined as:
action(ActionType,Class,Instance)
This includes the actions type (”Create”,”Update” or ”Delete”), the class which
the action acts upon and the instance of this class that the action acts upon (op-
tional).
Primitive Activity: Primitive activity includes the same components as activ-
ity and was hence similarly defined as:
primitive activity(ID,Name,Trigger,Precondition,Postcondition,Action)
Junction: Junctions, as previously discussed, can be decomposed to And-
Joint, OrJoint, AndSplit,OrSplit junctions, Start and Finish.
However in this representation the junction type was restricted to ”And”, ”Or”,
Start and Finish. This does not create an inconsistency with the notation because
the system was able to identify the most particular type of the junction by check-
ing the relationship, which it defines. This is based on the fact that a ”many to
Chapter 5. Technical Details 29
one” junction always represents a ”Joint” and a ”one to many” junction always
represents a ”Split”. As a result the basic junction predicate only included the
simple type of the junction (”And” or ”Or”), the activities that come in the junc-
tion (Preactivities) and the activities that come out of the junction (Postactivities).
Preactivities and Postactivities were each represented as a collection of the
relevant activity names. In addition two predicates were defined to represent the
Start and Finish junctions only including the starting or finishing activity name
respectively.
In total the junction predicates were defined as:
junction(JunctionType,PreActivities,PostActivities)
start(ActivityName)
finish(ActivityName)
Precedence Link:Precedence Link was defined by just the names of the two
activities that it links together, hence:
link(ActivityA,ActivityB)
Which means that ActivityA should be finished before ActivityB can be executed.
This concludes the definitions used for the FBPML models representation.
The reader is now probably aware that a few of the FBPML notation elements
have not been included in the definitions. These are namely Synchronisation Bar,
Time Points, Role and Annotations. The first two were not included for the reason
that time was not handled by the model verification framework of the system.
Even though Synchronisation Bars can exist on the models defined by the user,
the only temporal constraints handled by the system were the ones created by the
Precedence Link (temporal sequences).
Elements Role and Annotation were not used for the reason that they do not
provide the models with any semantic information important to the model verifi-
cation framework. In addition the predicates for Activity and Primitive Activity
also include an ImageId, which was not mentioned as it is only used for tracking
purposes by the system.
Chapter 5. Technical Details 30
5.2.3 Ontology Formal Definitions
The notation of Ontology was also fully represented in First Order Predicate logic.
In detail the elements of the notation were defined as follows:
Concrete Class:Concrete Class was defined by its Name (the name given to
the class by the user), its basic Properties, (Description, Example, Rules, Cross-
Reference) and its Object Attributes which is represented as a list of constants.
Hence the predicate for concrete class was defined as:
concreteclass(Name,Description,Example,Rules,CrossReference,ObjectAttributes)
Instance: Instance was defined by its Name (the name given to the instance
by the user), the Name of its parent (the concrete class linked to it by an Instance
Link) and its Object Attributes which is represented as a list of constants. Hence
the predicate for instance was defined as:
instance(Name,ParentName,ObjectAttributes)
This concludes the definitions used for the Ontology models representation.
As above elements Abstract Class,Membership Link, Instance Link, Subject
Area and Post-it have not been included in the definitions because they are not
used by the model verification framework. In addition the predicates for Concrete
Class and Instance also include an ImageId, which was not mentioned as it is only
used for tracking purposes by the system.
5.2.4 Model Verification Axioms
A set of axioms where created to be used as rules by the inference engine in order
to perform the checking required by the modelling verification framework. These
axioms where first expressed in simple english, then in First Order Predicate Logic
and then in Prolog (Prolog code included in Appendix B).
The english word ”should” and the strong inference symbol⇒ is used to rep-
resent the stronger enforcement of rules. Similarly the english phrase ”is rec-
Chapter 5. Technical Details 31
ommended” and the weaker inference symbol. is used to represent the weaker
enforcement of guidelines.
The axioms can be separated in four categories according to the type of check-
ing they perform.
• Inconsistency Axioms1
Axiom 1 If two activities share thesame namethen theyshouldhave ex-
actly the same Properties values:
∀Name,Trigger a,Trigger b,Preconditiona,Preconditionb,
Postconditiona,Postconditionb,Action a,Action b.
activity(Name,Trigger a,Preconditiona,Postconditiona,Action a)
∧activity(Name,Trigger b,Preconditionb,Postconditionb,Action b)⇒
Trigger a = Trigger b,
Preconditiona = Preconditionb,
Postconditiona = Postconditionb,
Action a = Action b
1Based on ”Consistent Representation of Information” as described in Chen-Burger (2002b)
Chapter 5. Technical Details 32
Axiom 2 If two concrete classes share thesame namethen theyshould
have exactly the same Properties and Object Attributes values:
∀Name,Descriptiona,Descriptionb,Examplea,Exampleb,
Rulesa,Rulesb,CrossRe f erencea,CrossRe f erenceb,
Ob jectAttributesa,Ob jectAttributesb.
concreteclass(Name,Descriptiona,Examplea,Rulesa,CrossRe f erencea,Ob jectAttributesa)
∧concreteclass(Name,Descriptionb,Exampleb,Rulesb,CrossRe f erenceb,Ob jectAttributesb)⇒
Descriptiona = Descriptionb,
Examplea = Exampleb,
Rulesa = Rulesb,
CrossRe f erencea = CrossRe f erenceb,
Ob jectAttributesa = Ob jectAttributesb
Axiom 3 If two instances share thesame namethen theyshouldhave ex-
actly the same Object Attributes values:
∀Name,Ob jectAttributesa,Ob jectAttributesb,Parent a,Parent b.
instance(Name,Ob jectAttributesa,Parent a)∧instance(Name,Ob jectAttributesb,Parent b)⇒
Ob jectAttributesa = Ob jectAttributesb
Axiom 4 If an activity acts upon an instance of a class, the specific class
shouldalready have been defined in a concrete class with in the Ontology.
∀ActionType,ClassName, InstanceName.
action(ActionType,Class, Instance)⇒
∃ClassNamea,Description,Example,Rules,CrossRe f erence,
ConcreteOb jectAttributes.
concreteclass(ClassNamea,Description,Example,Rules,CrossRe f erence,Ob jectAttributes)∧ClassNamea = ClassName
Chapter 5. Technical Details 33
• Syntactic Axioms
Axiom 5 IDs assigned to activitiesshouldbeunique.
∀ID,ActNamea,Trigger a,Preconditiona,Postconditiona,Action a
ActNameb,Trigger b,Preconditionb,Postconditionb,Action b.
activity(ID,ActNamea,Trigger a,Preconditiona,Postconditiona,Action a)⇒
¬(∃activity(ID,ActNameb,Trigger b,Preconditionb,Postconditionb,Action b)
∧(¬(ActNamea = ActNameb)
∨¬(Trigger a = Trigger b)
∨¬(Preconditiona = Preconditionb)
∨¬(Postconditiona = Postconditionb)
∨¬(Action a = Action b)))
Axiom 6 It is recommendedthat all activities specified have been assigned
IDs.
∀ID,ActName,Trigger,Precondition,Postcondition,Action.
activity(ID,ActName,Trigger,Precondition,Postcondition,Action).
¬(ID = null)
Axiom 7 Junctionsshould always specify a”one to many” or ”many to
one” relationship, i.e. many to many relations are not allowed.2.
∀Type,Preactivities,Postactivities.
junction(Type,Preactivities,Postactivities)
∧(∃Pre a∈ Preactivities∧∃Post a∈ Postactivities)⇒
2Based onsyntactic critiquesproposed in Kuo (2002)
Chapter 5. Technical Details 34
¬(∃Pre b∈ Preactivities
∧∃Post b∈ Postactivities)
∀Type,Preactivities,Postactivities.
junction(Type,Preactivities,Postactivities)∧ (∃Post a∈ Postactivities)⇒
¬(Preactivities= nil)
∀Type,Preactivities,Postactivities.
junction(Type,Preactivities,Postactivities)∧ (∃Pre a∈ Preactivities)⇒
¬(Postactivities= nil)
• Semantics Rules
Semantic Rules use the concept of a ”path” between two activities. Path is
defined by the following two axioms:
Axiom 8 There is apath from one activity (A) to another activity (B) if A
and B are linked with aprecedence linkfrom A to B.
∀Namea,Nameb,Trigger a,Trigger b,
Preconditiona,Preconditionb,Postconditiona,Postconditionb,
Action a,Action b.
activity(Namea,Trigger a,Preconditiona,Postconditiona,Action a)
∧activity(Nameb,Trigger b,Preconditionb,Postconditionb,Action b)
∧link(Namea,Nameb)⇒
path(Namea,Nameb)
Chapter 5. Technical Details 35
Axiom 9 There is apath from one activity (A) to another activity (C) if
there is aprecedence linkfrom A to another activity (B) and there is apath
from activity B to activity C3.
∀Namea,Nameb,Namec,Trigger a,Trigger b,Trigger c,
Preconditiona,Preconditionb,Preconditionc,
Postconditiona,Postconditionb,Postconditionc,
Action a,Action b,Action c.
activity(Namea,Trigger a,Preconditiona,Postconditiona,Action a)
∧activity(Nameb,Trigger b,Preconditionb,Postconditionb,Action b)
∧activity(Namec,Trigger c,Preconditionc,Postconditionc,Action c)
∧link(Namea,Nameb)
∧path(Nameb,Namec)⇒
path(Namea,Namec)
Axiom 10 An activity (A)should not createan instance of a class that
has already been previously created by another activity (C), unless a third
activity (B) hasdeletedit before activity A was reached.
∀Namea,Trigger a,Preconditiona,
Postconditiona,Action a,
Class, Instance,
¬∃Nameb,Trigger b,
Preconditionb,Postconditionb,Action b.
activity(Namea,Trigger a,Preconditiona,Postconditiona,Action a)
∧action(Create,Class, Instance) ∈ Action a
∧(activity(Nameb,Trigger b,Preconditionb,Postconditionb,Action b)
∧action(Delete,Class, Instance) ∈ Action b
3This is a recursive definition
Chapter 5. Technical Details 36
∧path(Nameb,Namea))⇒
¬∃Namec,Trigger c,Preconditionc,
Postconditionc,Action c.
activity(Namec,Trigger c,Preconditionc,Postconditionc,Action c)
∧action(Create,Class, Instance) ∈ Action c∧path(Namec,Nameb)
Axiom 11 An activity (A)should not deletean instance of a class that has
already been previously deleted by another activity (C), unless a third ac-
tivity (B) hascreatedit before activity A was reached.
∀Namea,Trigger a,Preconditiona,
Postconditiona,Action a,
Class, Instance,
¬∃Nameb,Trigger b,
Preconditionb,Postconditionb,Action b.
activity(Namea,Trigger a,Preconditiona,Postconditiona,Action a)
∧action(Delete,Class, Instance) ∈ Action a
∧(activity(Nameb,Trigger b,Preconditionb,Postconditionb,Action b)
∧action(Create,Class, Instance) ∈ Action b
∧path(Nameb,Namea))⇒
¬∃Namec,Trigger c,Preconditionc,
Postconditionc,Action c.
activity(Namec,Trigger c,Preconditionc,Postconditionc,Action c)
∧action(Delete,Class, Instance) ∈ Action c∧path(Namec,Nameb)
Chapter 5. Technical Details 37
Axiom 12 An actionshould not deletea class that hasnot been previously
createdby another activity.
∀Namea,Trigger a,Preconditiona,
Postconditiona,Action a,Class, Instance.
activity(Namea,Trigger a,Preconditiona,Postconditiona,Action a)
∧action(Delete,Class, Instance) ∈ Action a⇒
∃Nameb,Trigger b,Preconditionb,
Postconditionb,Action b.
activity(Nameb,Trigger b,Preconditionb,Postconditionb,Action b)
∧action(Create,Class, Instance) ∈ Action b∧ path(Nameb,Namea)
Axiom 13 An activityshould not updatean instance of a class that hasnot
been previouslycreatedby another activity.
∀Namea,Trigger a,Preconditiona,
Postconditiona,Action a,Class, Instance.
activity(Namea,Trigger a,Preconditiona,Postconditiona,Action a)
∧action(U pdate,Class, Instance) ∈ Action a⇒
∃Nameb,Trigger b,Preconditionb,
Postconditionb,Action b.
activity(Nameb,Trigger b,Preconditionb,Postconditionb,Action b)
∧action(Create,Class, Instance) ∈ Action b∧ path(Nameb,Namea)
Chapter 5. Technical Details 38
Axiom 14 An activity (A)should not updatean instance of a class that has
been previously deleted by another activity (C), unless a third activity (B)
hascreatedagain it before activity A was reached.
∀Namea,Trigger a,Preconditiona,
Postconditiona,Action a,
Class, Instance,
¬∃Nameb,Trigger b,
Preconditionb,Postconditionb,Action b.
activity(Namea,Trigger a,Preconditiona,Postconditiona,Action a)
∧action(U pdates,Class, Instance) ∈ Action a
∧(activity(Nameb,Trigger b,Preconditionb,Postconditionb,Action b)
∧action(Create,Class, Instance) ∈ Action b
∧path(Nameb,Namea))⇒
¬∃Namec,Trigger c,Preconditionc,
Postconditionc,Action c.
activity(Namec,Trigger c,Preconditionc,Postconditionc,Action c)
∧action(Delete,Class, Instance) ∈ Action c∧path(Namec,Nameb)
Chapter 5. Technical Details 39
Axiom 15 All activities should be reachable in a process model.
∀Namea,Trigger a,Preconditiona,
Postconditiona,Action a,Nameb,Trigger b,
Preconditionb,Postconditionb,Action b.
activity(Namea,Trigger a,Preconditiona,Postconditiona,Action a)⇒
start(Namea)
∨(activity(Nameb,Trigger b,Preconditionb,Postconditionb,Action b
∧start(Nameb)
∧path(Nameb,Namea))
• Semantic Loop Axiom
Axiom 16 It is recommendedthat an activity isnot involved in a semantic
loop.
∀Name,Trigger,Precondition,Postcondition,Action.
activity(Name,Trigger,Precondition,Postcondition,Action).
¬path(Name,Name)
Chapter 6
Use of the System
Chapters 3, 4 and 5 (System Requirements, System Design and Technical Details)
should have already provided the reader with a good understanding of the system’s
properties and capabilities. This chapter serves at describing in more detail how
the system can actually be used by a potential user.
6.1 User Support Framework
As mentioned in the requirements chapter the users of this system may have dif-
ferent levels of knowledge in modelling and technical expertise.
The user support framework facilitates the potential users needs by providing
them with clear menus and toolbars and an organisation of the system’s function-
alities. The user is expected to desire to build new models describing a partic-
ular domain, including FBPML process and Ontology diagrams describing the
processes of the domain and the data on which these processes act on. Further
more the user is given the option to check the models using the model verification
framework provided by the system.
40
Chapter 6. Use of the System 41
6.1.1 Model Building
When the application starts a main window is open (see figure 6.1), including the
main menu
Figure 6.1: The system’s Main Window
At this stage the user can use the Model menu (see expansion in figure 6.2) in
order to start building a new model or open an existing one.
Figure 6.2: Expansion of the model menu
Chapter 6. Use of the System 42
In order to create a new model the user just has to add some new process and/or
ontology diagrams by using the option Model/Add New/ and then choosing the
type of diagram to add.
�NewProcessDiagram
Figure 6.3: Diagram Name Request window
If the user chooses to add a process diagram first he/she is asked to provide
a name for this diagram (see figure 6.3). As seen in the screen shot, duplicated
names are not allowed for the diagrams. If a duplicated name is provided nothing
happens and the name request window keeps on appearing until a suitable name
has been given or the user clicks on cancel. If a suitable name is provided the panel
shown in figure 6.4, with the chosen name as title, appears in the main window.
The process diagram panel includes a toolbar (see figure 6.5) consisting of all
the buttons that the user needs for creating elements of the FBPML notation.
Figure 6.4: The Process Diagram Panel
The buttons on the bar correspond (from left to right) to:
Chapter 6. Use of the System 43
Figure 6.5: The Process Diagram Toolbar
• Start (adding a Start junction to the diagram)
• Role (adding a Role node to the diagram)
• Primitive Activity (adding a primitive activity node to the diagram)
• Activity (adding an activity node to the diagram)
• And Junction (adding a And junction to the diagram)
• Or Junction (adding a Or junction to the diagram)
• Finish (adding a Finish junction to the diagram)
• Precedence Link (switching the link mode to Precedence link with straight
line)
• Routed Precedence Link (switching the link mode to Precedence link with
routed line)
• Synchronisation Bar (switching the link mode to Synchronisation Ber)
• Idea Node (adding an Idea annotation to the diagram)
• Navigation Node (adding an Idea annotation to the diagram)
• Show/Hide Ports (determining if the ports in the diagram are visible or not)1
• Undo (Revokes last change made to the diagram)
• Redo (Revokes last Undo action on the diagram)
• Paste (pastes part of the diagram that has been previously copied or cut)
1Ports are little guide-dots in the centre of nodes where the user has to click in order to start aconnection to another node.
Chapter 6. Use of the System 44
• Copy (copies the selected part of the diagram)
• Cut (cuts the selected part of the diagram)
• Delete (deletes the selected part of the diagram)
• Normal Size (displays the diagram at its normal size)
• Zoom In (displays the diagram scaled up)
• Zoom Out (displays the diagram scaled down)
• Bring to Front (displays selected elements in front of other elements they
might overlap with)
• Send to Back (hides selected elements behind other elements they might
overlap with)
Figure 6.6: The FBPML Notation Diagram
Chapter 6. Use of the System 45
Using these buttons the user can create FBPML process diagrams consisting
of elements of the notation like is shown in figure 6.6. A simple comparison
to the standard FBPML notation (figure 2.1) proves coverage of all the notation
elements. When the user creates an new activity in the process diagram he/she can
specify its name and, properties by right-clicking on it and choosing Edit Activity
Label or Properties (see figure 6.7).
Figure 6.7: Right-click Activity Menu
The Edit Activity Label options invokes a text box to appear on the selected
activity, (see figure 6.8) In this text box the user can type in the desired label and
then press the Enter key to apply that label to the activity2.
The Properties option invokes the Properties window to appear (see figure 6.9).
Through this window the user can assign properties to the selected activity such
as: Triggers, Preconditions, Postconditions and Actions. Actions in particular are
defined by choosing an action type from the drop down menu (Create, Update,
Delete), the instance to act upon and the class this instance belongs to. The button
add row can be used to add more rows to the table displayed in order to define
more occurrences of these properties.
2Labels on Annotation nodes ”Idea” and ”Navigation” can be applied in exactly the same way.
Chapter 6. Use of the System 46
Figure 6.8: The Activity Label text box
Figure 6.9: The Activity Properties window
Chapter 6. Use of the System 47
The final attribute of an activity that the user can define is it’s ID (identity
number). This is possible by right clicking in the Activity id area (the separate
box under the label) and choosing Edit Activity ID (see figure 6.10).
Figure 6.10: Right-click Activity ID Menu
After creating two or more activities the user can create links and junctions
between them by clicking on the relevant buttons and dragging an arrow from one
node to the other. You can see the junctions that can be created in figure 6.11
On last thing to note here is that when the user chooses to connect activity A
to activity B through a synchronisation bar, a label is created automatically on the
bar as ”Begin(ID of A) - End(ID of B)” to denote that the begin time of A should
be synchronised with the end time of B. An example can be seen in the notation
diagram mentioned before (figure 6.6) with activities B and C.
Chapter 6. Use of the System 49
�NewOntologyDiagram
Similarly if the user chooses to add an ontology diagram to the model, the
name of the diagram is requested exactly as above (figure 6.3). If a suitable dia-
gram name is provided by the user the panel shown in figure 6.12 appears in the
main window.
Figure 6.12: The Ontology Diagram Panel
Figure 6.13: The Ontology Diagram Toolbar
The ontology diagram includes its own toolbar (see figure 6.13) as well. The
buttons on this bar correspond (from left to right) to:
• Subject Area (adding a Subject Area node to the diagram)
• Abstract Class (adding an Abstract class to the diagram)
• Concrete Class (adding a Concrete class to the diagram)
• Instance (adding an Instance to the diagram)
• Membership/Instance Link (switching the link mode to membership or in-
stance link)
Chapter 6. Use of the System 50
Figure 6.14: The Ontology Notation Diagram
• Routed Membership/Instance Link (switching the link mode to membership
or instance link with routed line)
• Note Link (switching the link mode to note link)
• Post-it (adding a post-it note to the diagram)
• Rest of buttons exactly like the Process diagram toolbar.
Using these buttons the user can create Ontology diagrams consisting of el-
ements of the Ontology notation shown in figure 6.14. Like before the user can
right click on a Concrete class he/she has created and see the menu shown in fig-
ure 6.15. Using this menu the user can choose to edit the label of the class (same
as for activity), and assign Properties and Object Attributes to the class.
Chapter 6. Use of the System 52
The Properties option invokes the Properties window to appear (see figure
6.16). Through this window the user can assign properties to the selected class
such as: Description, Example, Rules and Cross-Reference.
Figure 6.16: The Concrete class Properties window
Figure 6.17: The Concrete class Object Attributes window
The Object Attributes option invokes the Object Attributes window to appear
(see figure 6.17). Through this window the user can assign the Object Attributes
that should be defined for any instances of this class. Instances have a similar
Chapter 6. Use of the System 53
right-click menu for assigning the particular Object Attributes. However for this
action to work an instance should have been connected to a concrete class and
Object Attributes should have been defined for this class.
Figure 6.18: The Instance Object Attributes window
If this is the case the instance Object Attributes window appears which has
automatically inherited the labels from the parent class (see figure 6.18). In the
case that the instance is not connected to a Concrete class the error message shown
in figure 6.19 appears. In the case that the instance is connected to a Concrete
class but no Object Attributes for this class have been specified, the error message
shown in figure 6.20 appears.
Chapter 6. Use of the System 54
Figure 6.19: No Concrete Class error
Figure 6.20: No Concrete Class Object Attributes error
Chapter 6. Use of the System 55
�SaveandSaveAs
When the user has completed creating a new model, or updating an old one,
he/she can save the mode using the Model/Save or Model/Save As options. If the
model is a new one both options will result in a File Browse window popping up
(see figure 6.21), from which the user can specify a folder in which to save the
model and the name of the model. The file name the user specifies is given the ar-
bitrary extension ”.model” chosen to specify models created with the application.
Figure 6.21: The Save As File Browse window
If the option Model/Save is used on a model which has been already saved
before, the File Browse window will not appear and the updated model will just
be saved under it’s old name.
�OpenandClose
At any stage the user may open a new model which has been previously cre-
ated. If no model is loaded in the main window, the diagrams of the model will
open in the main window (see figure 6.22) organised in a way that as many of
them are partly visible as possible. If a model is loaded and a new one is opened,
Chapter 6. Use of the System 56
the old one closes (prompting the user to save if changes have been made), and
the new one is loaded.
Figure 6.22: A model as it opens
When a model is loaded in the main window the user can use the Model/Close
option in order to close the model. If changes to the model have occurred the user
is prompted to save the model before closing it (see figure 6.23). After the user’s
choice has been made the model closes and the main window is empty again.
One thing that is worth mentioning is that all the above options are available
to the user depending on their suitability at a time. For example if no model is
loaded in the main window the options Save, Save As and Close are greyed out
and cannot be chosen because invoking their functionality at this state would not
make sense.
�Exit
The user can exit the application at any time by choosing Model/Exit. If
the user is currently working on a model that has been changed he/she will be
Chapter 6. Use of the System 57
Figure 6.23: Close warning
prompted to save the model before exiting (see figure 6.24).
Chapter 6. Use of the System 58
Figure 6.24: Exit warning
6.1.2 Model Verification
Anytime that a model is loaded in the main window it can be checked using the
model verification framework. This framework includes all the various checks
(described in chapter 5) that can be enforced on the models. Checking can be
invoked by the user by choosing one of the options under the Modelling Support
Menu shown in figure 6.25.
By using this menu the user can check the models for Consistency, Syntax,
Semantics, Loops or all the above at the same time. The models are checked
using the functionality described in chapter 6. During the internal processing of
a check a message window appears (see figure 6.26) informing the user that the
JIProlog inference engine (see JIProlog (2004)) is being used. This is due to the
fact that an unregistered version of JiProlog was used in this project3.
3JIProlog can be used for free under a shareware licence
Chapter 6. Use of the System 59
Figure 6.25: Modelling Support Menu
Figure 6.26: The JIProlog warning
When the check is finished, if no errors have been detected in the models the
user is informed about this with a message like the one shown in figure 6.27.
Figure 6.27: ”No Errors” checking message
If one or more errors have been detected by a particular checking a message
window appears informing the user of the errors in simple english (see figure
6.28). Words like ”should” or ”invalid” are used to inform of violation of strong
rules and the word ”warning” is used to inform of violation of weak rules. The
syntax of all the possible error messages can be found in Appendix C.
Chapter 6. Use of the System 60
When the error message appears the user has the option to save the message in
a text file, for later viewing using the Save Result As option. This option invokes a
File Browse window like the one in figure 6.21 and the user can choose a location
to save the file which takes the arbitrary extension ”.log”.
Figure 6.28: Checking Errors message
Chapter 6. Use of the System 61
6.2 Example User scenario
This section provides an example user manual which uses some of the menus and
functionality mentioned above. For simplicity this example deals with a model
already created by the user.
I The user opens a previously created and saved model named ”SimpleModel.model”,
using the Model/Open menu.
The model is loaded in the main window (see figure 6.29). It consists of a
process diagram named ”Simple Process” and an ontology diagram, named
”Simple Ontology”.
Figure 6.29: Model ”Simple Model” loaded on screen
II The user adds some properties to activity ”Receive Order”, by right-clicking
on the activity and choosing ”Properties”.
In particular he adds two actions ”Create Customer Details” and ”Create Or-
der Report” as shown in figure 6.30.
Chapter 6. Use of the System 62
Figure 6.30: Properties of activity ”Receive Order”
III The user now checks the model’s consistency by clicking on ”Modelling Sup-
port/Check Consistency”.
Fist the JIProlog message is displayed in the centre of the screen (see figure
6.31).
The user click on ”OK” and then the following error message is displayed
”Inconsistency in action ’ Create’ in activity ’Receive Order’, class: ’ Cus-
tomer’ is not specified in Ontology”,
”Inconsistency in action ’Create’ in activity ’Receive Order’, Instance: ’De-
tails’ is not specified in Ontology” (see figure 6.32).
It is quite straightforward that these error messages appear because the user
has been trying to define an action upon the instance of a class that does not
Chapter 6. Use of the System 63
Figure 6.31: JIProlog warning
exist in the ontology diagram.
IV The user corrects the error by adding a new concrete class named ”Customer”
and a new instance of this class called ”Details”, in the ontology diagram (see
figure 6.33).
V The user runs the Consistency check again.
Fist the JIProlog message is displayed in the centre of the screen (see figure
6.31).
The user click on ”OK” and then the following error message is displayed
”No errors” (see figure 6.34).
VI The user saves the model as ”Simple Correct Model” by clicking on ”Model/Save
As”, inserting the name in the File Browse window and clicking OK (see fig-
ure 6.35).
VII The user exits the application by clicking on ”Model/Exit”.
Chapter 6. Use of the System 64
Figure 6.32: The Consistency errors detected in the model
Figure 6.33: The corrected model
Chapter 6. Use of the System 65
Figure 6.34: The ”No Errors” message
Figure 6.35: Saving the model as ”Simple Correct Model”
Chapter 7
Evaluation
The system created under the scope of this project was carefully evaluated and cor-
rected during all the stages of its development. Moreover an evaluation framework
was designed after the completion of the systems implementation. The evaluation
framework as well as the results of its use are described in this chapter.
7.1 Evaluation Framework
The framework consists of three different evaluation approaches:
• The theoretical approach, focussing on the reflection of the FBPML method’s
syntax and semantics on the system.
• The empirical approach, employing a usability test performed on a sample
of potential users.
• The comparison approach, exploring similarities and differences to few
other similar modelling tools.
The combination of these three approaches serves at assessing various prop-
erties of the system such as completeness, correctness, robustness, usability and
competitive edge.
66
Chapter 7. Evaluation 67
7.2 Theoretical Evaluation
7.2.1 Criteria
The theoretical evaluation uses the following criteria:
• Completeness of the model building capabilities: how compliant to the
FBPML notation are the models that can be created by the user.
• Completeness and Correctness of the model verification capabilities: how
well the modelling rules and guidelines of the FBPML method are reflected
on the rules incorporated by the system’s Model Verification framework.
7.2.2 Assessment
Tables 7.1 and 7.2 provide a quick summary of the completeness of the model
creation capabilities of the system.
The first column in both tables gives a listing of all the FBPML and Ontol-
ogy notation elements that are used by the FBPML method. The second column
specifies whether the particular element can be included in a model created us-
ing the tool. The rest of the columns specify if the element is part of any Con-
sistency/Syntactic/Semantic checking that the model verification of the tool pro-
vides. For example lets look at the element ”Activity”. An activity can be included
in a model using the tool. Moreover it can be checked whether the particular activ-
ity creates an inconsistency in the model. In addition the activity’s syntax can be
checked. Finally the activity’s semantic meaning is used by the modelling support
in order to perform a semantic check on the model.
This final claim is supported by the definition of an activity’s semantic mean-
ing: ”The semantics of an activity to a model is therefore defined together by its lo-
cation in the model, its usage in the model and the content defined within itself i.e.
the Trigger(s), Pre-condition(s), Post-condition(s) and Action(s).”(Chen-Burger
et al. (2002)).
As it is described in the formal representation of activity in chapter 5:
Chapter 7. Evaluation 68
Element Provision Consistency Syntax Semantics
Role√
× × ×Activity
√comp comp part
Primitive Activity√
comp comp part
Precedence Link√
× × part
Synchronisation Bar√
× × ×And Junction
√× comp part
Or Junction√
× comp part
Start Junction√
× × part
Finish Junction√
× × part
Time Point × × × ×Annotations
√× × ×
Table 7.1: FBPML Notation Compliance and Support Assessment√
=Implemented
×=Not implemented/No support provided
comp=Complete support
part=Partial Support
• Location in the model is captured by recording its precedence links to junc-
tions and other activities.
• Usage is captured by recording its links to possible parent activities.
• Content is captured by recording its Trigger(s), Precondition(s), Postcondi-
tion(s) and Actions.
Usage of semantic meaning for the rest of the elements (when claimed) can be
similarly supported on the basis that all the formal representations used by the sys-
tem where derived by the standard definitions provided for FBPML.
More observations and discussion can be produced by examining these tables:
Chapter 7. Evaluation 69
Element Provision Consistency Syntax Semantics
Subject Area√
× × ×Abstract Class
√comp × ×
Concrete Class√
comp × part
Instance√
comp × part
Membership Link√
× × ×Instance Link
√× × part
Note Link√
× × ×Post-it
√× × ×
Table 7.2: FBPML Notation Compliance and Support Assessment√
=Implemented
×=Not implemented/No support provided
comp=Complete support
part=Partial Support
• The system covers the FBPML and Ontology notation with the only excep-
tion being the FBPML element ”Time Point”.
It is partially true that the use of Time Point was not included as an element
in the system. The creation of a Synchronisation Bar, which is supported by the
tool, captures a temporal constraint enforced on two time points, that is the ”Be-
gin” and ”End” point of two activities. However no further time points creation is
supported. This omission was a conscious one. Time point as defined by (Chen-
Burger et al. (2002))”Indicates a particular point in time during the enactment
of a process model. The reference of time point may be decided by the implemen-
tation method of the model.”. This definition shows that time point would be a
useful element to a system that focuses on the simulation of the workflow (e.g.
Kuo (2002)) defined by the models. However this goes out of the scope of this
project and could only be suggested as further possible expansion to the system.
• Most of the semantic meaning of the notation elements is captured. Excep-
Chapter 7. Evaluation 70
tions include: Synchronisation Bar, Time Point, Role and Annotations.
Synchronisation Bar and Time Point were not used semantically because in the
scope of this project (as explained above) no rules could be enforced on the model
based on their semantic meaning. Role is also a functional concept only important
during the enactment of a model so its semantic meaning was again useless to this
system. Annotations as defined in (Chen-Burger et al. (2002))”do not contribute
semantically to a process model, but help the organisation and management of the
modelling process”. Therefore no semantic rules can be drawn based on them.
In further assessing the second criteria of this evaluation approach, the rules
enforced on the models by the ”Modelling Support” framework should be exam-
ined.
Lets look at each group of rules separately:
• Consistency Rules
The rules defined in order to check the consistency of the models were based
on (Chen-Burger (2002b)) and it is believed that they completely cover all the
possible inconsistencies that can occur in the models created using the tool.
• Syntax Rules
Syntax rules were based on the basic syntactic guidelines for the FBPML method-
ology. They are not considered complete as there is a very big number of syntactic
errors that a user could make while creating a model. However, they provide a
good example on how such errors could be tracked by the system.
• Semantic Rules
The semantic rules defined for the models in this project cover a limited number of
possible definitions. They should be considered as an attempt to prove the ability
of such a system to semantically check the models. One important example of
their limitation is that they focus only on linear sequences of processes and do not
deal with parallel processing. The reason that no further rules where examined by
this project was mainly limitation of time.
Chapter 7. Evaluation 71
• Loop Detection
Detection of semantic loops in the models is considered complete and actually
captures loops not only when they appear in sequential processing but also in par-
allel. However further theoretical examination of the models could have taken
place in order for the system to be able to determine when a loop should be al-
lowed or not in a model. This would have to take into further consideration the
semantic meaning of junctions and would still be hard to achieve since sometimes
it just depends on the intentions of the user in defining such a process.
Overall the rules used by the model verification framework are considered to
be correct as they are based on the methodology and guidelines of the FBPML
method.
7.3 Empirical Evaluation
During implementation each component was tested for correctness straight after
its implementation was completed. Therefore it can be claimed with confidence
that all the major components function correctly. This of course is just saying that
things work according to the way they were designed to work. If errors in the
design existed then those would be reflected on the system. This falls back on the
theoretical criteria of evaluation in this framework.
However since this tool was designed to be used by a wide variety of users, this
level of assessment was not considered enough. It was considered very important
that a sample of potential users would have the chance to use it and provide their
comments. For this reason the following testing framework was drawn:
• Five test users were carefully chosen so that different levels of expertise
would participate.
• An test was constructed1 to include:1The questionnaire used is included in appendix D.
Chapter 7. Evaluation 72
- Provision of basic training to the users. This included an introduction
to the FBPML method, explanation of the tool’s functionality and provision
of sample models for browsing (see figures D.1, D.2, D.3, D.4 in appendix
D1)
- Usability testing of the tool’s Model Building abilities. This section
urged the user to recreate a model that was shown to him/her (see figures
D.5, D.6 in appendix D).
- Usability testing of the tool’s Model Verification abilities. This section
provided the user with an erroneous model (see figures D.7, D.8 in appendix
D) an asked him/her to try to trace these errors and correct them using the
model verification framework.
- Collection of general comments and suggestions. The users were
asked to record their experiences from performing the above tasks, to asses
the system’s usability and communication ability and to suggest any im-
provements that they would find useful.
• The test was carried out by all five users and the results were recorded2 and
examined.
� The test-usersIndividuals from different disciplines and levels of expertise
in modelling, were targeted by this test. Five such persons took the test. They can
be described generally3 as:
A. A second year PhD student4 with a research topic based on Business Process
Modelling. This person was considered by the evaluation as the ”expert” be-
cause he has strong knowledge in the area of BPM and he is highly familiar
with the FBPML method. This user was requested to further test the system
after the completion of the standard questionnaire. His comments proved most
valuable to this evaluation.2The results are included in detail in appendix D2.3Names of the users are being withheld for privacy reasons but can become available under
request.4All the students mentioned study in the School of informatics of the University of Edinburgh.
Chapter 7. Evaluation 73
B. An MSc student currently working on the field of Artificial Intelligence but
also holding a degree and experience in Psychology.
C. An MSc student with a traditional computer science background.
D. An MSc student with a strong Artificial Intelligence background.
E. A professional holding the position of ”Head of the IT Consulting Depart-
ment” in a software company.
� The results
An overall summary of the results of this test is presented in table 7.3.
User Expertise Recreation Tasks Verification Tasks Usability GUI
A 5,6 easy with comments very easy with commentsvery good good
B 3,5,6 very easy with comments very easy very good good
C 1,5,6 very easy with commentsvery easy with commentsvery good very good
D 6 very easy with commentsvery easy with comments good good
E 4 fairly easy very easy good very good
Table 7.3: Summary of Usability Test results
Expertise: indicates the level of expertise of the user:
1=expert in FBPML and modelling methods
2=some understanding in FBPML and modelling methods
3=general knowledge in modelling
4=limited knowledge in modelling
5=general knowledge in AI
6=general knowledge in CS
7=no prior knowledge
A number of conclusions was drawn by these results:
1. Most of the users found the model recreation tasks easy to complete.
One comment was similarly expressed by three out of the five users was that
the buttons on the toolbar in the Process diagram panel were not all clear
Chapter 7. Evaluation 74
as to what they represent (especially the ones for Activity and Primitive
Activity). All three users suggested that the addition of tooltips5 would
make their use much easier.
Another fault in the interface was spotted by two of the users. That is that
when a link between two nodes exists, if one of the nodes is deleted the
link remains (see figure 7.1 observe runaway link). This is actually a known
Figure 7.1: Fault created when connected node is deleted
”bug” inherited from the use of the JGraph library (see section 5.1). Another
problem of the same source, also depicted in figure 7.1 (observe selected
link) was not spotted by the test-users. That is the routed arrow (optionally
used for the precedence link) which would help to produce cleaner complex
diagrams sometimes appears at ”bad” positions and cannot be bended to a
better one. Unfortunately such problems were detected in the late stages of
development were not corrected due to time limitations.
Nevertheless, bearing in mind the limited training provided, the results from
this part of the test were very pleasing. Overall all the users created the
5Explanatory text that appears when the mouse is over a button.
Chapter 7. Evaluation 75
models much easier than they expected when they first had a look at the
examples. This is a proof that the tool provides user-friendly support for
FBPML model building.
2. Most users found the model verification tasks very easy to perform.
Comments where excellent and all the users seamed to fully understand
the error messages provided. This is also supported by the fact that all
of them managed to trace back errors in the models and correct them as
well as creating their own errors in the models and correctly predicting the
messages provided by the Model Verification framework.
3. Comments on general usability where positive including phrases such as
”very easy to use”, ”useful and intuitive”, ”a good system”.
4. Comments on the Graphical User Interface were positive but more modest
such as”OK”, ”Good”, ”Nice” .
Overall the test revealed a lot of information about the actual use of the system.
It was pleasing to see such good results. Moreover the comments and especially
the suggestions of the users proved valuable in identifying some weaknesses of
the tool that could be corrected in future expansions.
7.4 Comparison with Relevant Modelling Tools
This evaluation would be inadequate if there did not exist a comparison of the tool
with other existing tools dealing with similar issues. For this reason a number of
tools were examined and their features were recorded for the shake of comparison.
For reference reasons the tool created in this project has been given the arbitrary
name FBPMLGraph.
The tools chosen for comparison were the following:
• KBST-EM (Knowledge Based Support Tool for Enterprise Modelling): KBST-
EM is a generic modelling system build by (Chen-Burger (2001)) and pub-
Chapter 7. Evaluation 76
lished in (Chen-Burger and Robertson (1998)). KBST-EM currently sup-
ports 27 different modelling methods including FBPML. In addition it pro-
vides intelligent Model Verification support for a lot of these methods, in-
cluding Business Model and Ontology (and pairwise consistency checking
for the two), Knowledge Maps and more. However Verification Support for
FBPML is still limited (basic consistency checking).
• IX Process Panel, I-P2: IX is an AIAI (University of Edinburgh (2004))
research project (IX Technology for Intelligent Systems (2004)). IX is an
assistance tool which allows humans and computer systems to cooperate in
the creation or modification of some product such as a plan, design or phys-
ical entity (i.e. it supports synthesis tasks). I-X may also be used to support
more general collaborative activity. In particular IX Process Panel, I-P2 is
a component supporting user tasks and collaboration. This component is
not strictly speaking a process modelling tool, however it provides a basic
graphical user interface for drawing simple process models. In addition it
supports process execution which can also be graphically displayed.
• KBSI AI /0WIN c©: AI /0WIN is a Knowledge Based Systems, Inc. product
(see KBSI (2004)). This tools supports Enterprise Activity modelling (a
BPM variation) by providing graphical visualisation of a model in different
perspectives. An interesting feature is that it provides an facility for export-
ing the models data elements to a database. Moreover it supports Activity
Based Costing and Analysis (an accounting technique which determines the
actual cost associated with a model).
• KBSI ProCapc©6: ProCap is a different KBSI product. This tool supports
the IDEF3 process modelling language. Like above it also provides differ-
ent visual perspectives of the models and their elements. In addition it is
claimed that the tool allows you to publish a knowledge base on the World
Wide Web and create process knowledge maps. Unfortunately these fea-
tures were not included in the trial version so they could not be examined.
Chapter 7. Evaluation 77
• Renew 2.0: Renew is a tool developed at the ”Theoretical Foundations
Group” of the Department for Informatics of the University of Hamburg
(see Renew 2.0 for Petri Net (2004)). Renew is a drawing tool which sup-
ports the Petri Nets method. Petri Nets is a formal modelling language
appropriate for describing systems with concurrency and resource sharing
(see Petri Nets (2004)). Renew provides a simple and extensible graphical
user interface for the creation of Petri Nets. In addition it provides some
Model Verification support in the form of Syntactical checking and Layout
checking. Moreover it supports the execution of the models via a simulation
facility.
Comparison of the above tools with FBPMLGraph was focused on the features
more relevant to this project. Table 7.4 provides a summary of the comparison
results.
KBST-EM IX Process Panel AI /0WIN c© ProCapc© Renew FBPMLGraph
Modelling 26 methods Process Activity IDEF3 Petri Nets FBPML,
methods + FBPML Modelling Modelling Ontology
Visualisation good poor good good good good
consistency,
Model consistency none none none syntax syntax,
verification semantics,
loops
Execution√ √
Exporting ps,bmp,wmf xml IDL,mdb,html, txt ps,eps,xml fol
facilities visio,winhelp
Platforms Win 2000/XP Win 2000/XP, Win 95/98 Win 95/98 all Java all Java
supported Unix Win 2000/XP Win 2000/XP supporting supporting
platforms platforms
Table 7.4: Comparison of Modelling Tools
The following observations can be made based on this comparison:
• In terms of modelling methods supported KBST-EM supports the most
Chapter 7. Evaluation 78
modelling methods. This is not important for this project as the aim was
pure support of the FBPML method. However support for different meth-
ods could be integrated in the future.
• Most of the tools support good graphical visualisation of the models. This
proves that this is a very important feature for any modelling support tool.
This had been recognised early in the requirements elicitation stage of this
project. For this reason extra effort was put into the development of the
Graphical User Interface of the FBPMLGraph tool. It is believed that this
produced a high quality result and this was reflected on the user comments
during the empirical evaluation.
• It is obvious from the results that the FBPMLGraph tool holds a big advan-
tage against the others in providing a multi-perspective model verification
framework. This was one of the main goals of this project and it has been
achieved to a satisfying extend.
• Execution of the models through workflow simulation or similar was not in
the scope of this project. However by examining the two tools that support it
(IX Process Panel and Renew) it should be said that it has been considered
and important feature. Further expansions of this tools should definitely
consider the development of such a feature.
• On disadvantage of the FBPML tool against the others is that it does not
provide any exporting facilities apart from the ability to save the First Order
Logic formal definition of the model (automatically created when the model
is under verification). Some of the formats that the other systems can export
their models in, such as Bitmap, XML and HTML can be very useful as
they provide the user with reporting, Web publishing and other options.
• Finally another advantage of the FBPMLGraph tool is that it can be run on
any platform supporting Java, which includes Windows, Unix, MacOS and
Chapter 7. Evaluation 79
a lot more. This is a powerful feature that adds accessibility and robustness
to the system.
Closing this comparison section it should be mentioned that the most pow-
erful advantage of the system developed in this project is its capabilities
for future expansion. Most of the additional functionality of the other tools
could be added to the system without having to change any of the existing
structure or technical features.
Chapter 8
Conclusions and Future work
This chapter reviews the work and results of this project. In addition it provides a
discussion of those results and an overview of future work that could be based on
this project.
8.1 Overview
This project’s motivation comes from the significant need of many enterprises
for Process Reengineering initiatives. As this is heavily dependant on Process
Modelling and Workflow technologies, the main interest is focused on providing
an intelligent support tool for a process modelling language, the Fundamental
Business Process Modelling Language (FBPML).
The FBPML language was chosen for its advantage of being one of the few
BPM languages capable of manipulating context sensitive information. This adds
to the project significant value and expansion capabilities due to the emergence of
the Semantic Web and the rapid development and application of web services.
Overall the support tool developed had the following general requirements:
• To enable the generation of semantic business process models and integra-
tion with context sensitive information/knowledge.
• To enable the generation of simple ontological models which can hold the
80
Chapter 8. Conclusions and Future work 81
information entities of the domain.
• To provide automatic modelling assistances based on inferred information
derived from the underlying model(s)
More specifically a Model Support framework for FBPML with the following
structure was designed and developed:
• Model support framework
◦ Model building framework
- Model creation
- Model updating
- Model archiving
◦ Model verification framework
- Consistency checking
- Syntactic checking
- Semantic checking
- Detection of semantic loops
Leading edge technologies (Java 2 TM) in combination with Artificial Intel-
ligence representation methods (First Order Logic) and the capabilities of an AI
programming language (Prolog), were used in the development of the tool. This
provided the tool with the ability to infer knowledge from underlying models used
to provide modelling verification capabilities. In addition a specific choice of tech-
nologies (Java, JGraph, JIProlog) ensured platform independence properties and
possible integration of the tool in a Web environment. Great focus was given to
providing the tool with a user-friendly interface to accommodate potential users of
different expertise in modelling and different levels of technological knowledge.
Extensive evaluation of the tool took place when the development stage was
completed. An evaluation framework was built based on the following approaches:
Chapter 8. Conclusions and Future work 82
• The theoretical approach, focussing on the reflection of the FBPML method’s
syntax and semantics on the system.
• The empirical approach, employing a usability test performed on a sample
of potential users.
• The comparison approach, exploring similarities and differences to few
other similar modelling tools.
8.2 Discussion of Results
Overall the project was completed successfully. Some interesting points about the
final results can been drawn based on the development and the final evaluation of
the system:
• The notation of FBPML was fully represented in First Order Predicate logic.
The definitions were based on the methodology and guidelines of the lan-
guage. They provide a complete set of definitions as far as the scope of this
project is concerned.
• A set of axioms were defined using First Order Predicate Logic to be used as
rules by the inference engine in order to perform the checking required by
the modelling verification framework. Overall these axioms are considered
to be correct as they are based on the methodology and guidelines of the
FBPML method. In terms of completeness:
◦ Consistency axioms are believed to completely cover all the possible
inconsistencies that can occur in the models created using the tool.
◦ Syntax axioms are not considered to completely cover all the possible
syntactic errors that can be made by the user. However, they provide a good
example on how such errors could be tracked by the system.
◦ Semantic axioms are not believed to be theoretically complete. They
should be considered as an attempt to prove the ability of such a system to
Chapter 8. Conclusions and Future work 83
semantically check the models.
◦ Detection of semantic loops in the models is considered complete.
However, further use of the semantic information captured by the models
could enhance the support given in the case of such detection occurring.
• Empirical evaluation proved the system being highly usable by users of dif-
ferent backgrounds and modelling expertise.
• The functionality of the system is correct and faithful to the requirements
with just a few minor problems related only to the interface.
• In comparison to relevant existing modelling tools the system showed great
advantages relating to the model verification framework provided and other
properties such as good graphical visualisation of the models and portabil-
ity. Disadvantages included lack of exporting facilities and inability of ex-
ecution of the models through workflow simulation. However, these were
well out of the scope of this project.
8.3 Future Work
Future work based on this project can be focused on three approaches: extension
of support for the FBPML method, expansion to other methods and combination
with other technologies and methods for further functionalities.
� Extension of support:
• More rules could be defined to be used by the Model Verification framework
including:
◦ Further syntactic checking to assist the user to define models that fully
comply with the FBPML syntax.
◦ Further semantic checking. For example semantic checking for par-
allel processing.
Chapter 8. Conclusions and Future work 84
• Further use of the Ontological data models. For example these models could
be used as a dynamic Knowledge Base so that when a user defines a creation
of an entity in the process model this can automatically appear in the data
model.
� Support for more methods:
• The Model Support framework could be expanded to accommodate more
modelling methods.
� Combination with other technologies and methods:
• The system could be expanded to provide automatic enactment of the pro-
cess models through workflow simulation. This is particularly feasible since
a formalisation called ”FWFL” which can provide a declarative description
of a workflow system from an FBPML model has already been developed
by (Kuo (2002)).
• The system could be expanded to facilitate automatic translation of the mod-
els in a semantic web services language such as OWL-S (OWL-S (2004)).
This could be based on existing research by (Guo et al. (2004)) in order to
provide a direct mapping of the process models to semantic web services
models.
Appendix A. Definitions File 86
And the definitions generated by the system:
diagram(’0’,’Process’,’Order Process’).
start(’Contact Person’).
finsh(’Accept Order’).
primitive activity(’1’,’1’,’Contact Person’,[’contact=true’],[’none’],
[’order created’],[action(’Create’,’Order ’,’Order 1’)]).
link (’Contact Person’,’Contact Customer’).
link (’Decline Order’,’Contact Customer’).
activity(’2’,’2’,’Contact Customer’,[’order=true’],
[’order created’],[’report created’],
[action(’Create’,’Report’,’Report 1’)]).
activity(’3’,’4’,’Decline Order’,[’evaluation=true’],
[’report created’],[’delete order’],
[action(’Delete’,’Order’,’Order1’)]).
activity(’4’,’3’,’Accept Order’,[’evaluation=true’],[’report created’],
[’order updated’],[action(’Update’,’Order’,’Order 1’)]).
junction(’Or’,’Contact Customer’,[’Decline Order’, ’Accept Order’]).
diagram(’1’,’Ontology’,’Domain Ontology’).
concrete(’5’,’Order’,’A customer order’,’Order 1’,’Order complete’,’none’,[Details]).
instance(’6’,’Order 1’,’Order’,[product 1]).
instance(’7’,’Report 1’,’Report’,[report 1]).
concrete(’8’,’Report’,’An order report’,’Report 1’,’Report complete’,’none’,[Details]).
Appendix B
Prolog Rules
B.1 Inconsistency Rules
inconsistentact(Name1,Attribute)
:-activity(ImageId1,Id1,Name1,Trigger1,Prec1,Post1,Act1,Actname1),
activity(ImageId2,Id2,Name1,Trigger2,Prec2,Post2,Act2,Actname2),
insert sort(Trigger1,SortedTrigg1),insertsort(Trigger2,SortedTrigg2),
SortedTrigg1\=SortedTrigg2,ImageId1\=ImageId2,Attribute=’Trigger’.
inconsistentact(Name1,Attribute)
:-activity(ImageId1,Id1,Name1,Trigger1,Prec1,Post1,Act1,Actname1),
activity(ImageId2,Id2,Name1,Trigger2,Prec2,Post2,Act2,Actname2),
insert sort(Prec1,SortedPrec1),insertsort(Prec2,SortedPrec2),
SortedPrec1\=SortedPrec2,ImageId1\=ImageId2,Attribute=’Precondition’.
inconsistentact(Name1,Attribute)
:-activity(ImageId1,Id1,Name1,Trigger1,Prec1,Post1,Act1,Actname1),
activity(ImageId2,Id2,Name1,Trigger2,Prec2,Post2,Act2,Actname2),
insert sort(Post1,SortedPost1),insertsort(Post2,SortedPost2),
SortedPost1\=SortedPost2,ImageId1\=ImageId2,Attribute=’Postcondition’.
inconsistentact(Name1,Attribute)
:-activity(ImageId1,Id1,Name1,Trigger1,Prec1,Post1,Act1,Actname1),
activity(ImageId2,Id2,Name1,Trigger2,Prec2,Post2,Act2,Actname2),
87
Appendix B. Prolog Rules 88
insert sort(Act name1,SortedAct1),insertsort(Act name2,SortedAct2),
SortedAct1\=SortedAct2,ImageId1\=ImageId2,Attribute=’Action’.
inconsistentclass(Name1,Property)
:-concrete(ImageId1,Name1,Desc,Example,Rule,Cross,Object),
concrete(ImageId2,Name1,Desc1,Example1,Rule1,Cross1,Object1),
Desc\=Desc1,ImageId1\=ImageId2,Property=’Description’.
inconsistentclass(Name1,Property)
:-concrete(ImageId1,Name1,Desc,Example,Rule,Cross,Object),
concrete(ImageId2,Name1,Desc1,Example1,Rule1,Cross1,Object1),
Example\=Example1,ImageId1\=ImageId2,Property=’Example’.
inconsistentclass(Name1,Property)
:-concrete(ImageId1,Name1,Desc,Example,Rule,Cross,Object),
concrete(ImageId2,Name1,Desc1,Example1,Rule1,Cross1,Object1),
Rule\=Rule1,ImageId1\=ImageId2,Property=’Rules’.
inconsistentclass(Name1,Property)
:-concrete(ImageId1,Name1,Desc,Example,Rule,Cross,Object),
concrete(ImageId2,Name1,Desc1,Example1,Rule1,Cross1,Object1),
Cross\=Cross1,ImageId1\=ImageId2,Property=’Cross-Reference’.
inconsistentclass(Name1,Property)
:-concrete(ImageId1,Name1,Desc,Example,Rule,Cross,Object),
concrete(ImageId2,Name1,Desc1,Example1,Rule1,Cross1,Object1),
insert sort(Object,SortedObject),insertsort(Object1,SortedObject1),
SortedObject\=SortedObject1,ImageId1\=ImageId2,Property=’ObjectAttributes’.
inconsistentinst(Name1)
:-instance(ImageId1,Name1,Parent1,Attributes1),
instance(ImageId2,Name1,Parent2,Attributes2),
insert sort(Attributes1,SortedAttr1),insertsort(Attributes2,SortedAttr2),
SortedAttr1\=SortedAttr2,ImageId1\=ImageId2.
Appendix B. Prolog Rules 89
B.2 Syntax Rules
not junction(Type,PreActivities):-
junction(Type,PreActivities,PostActivities),islist(PostActivities),islist(PreActivities).
no id activity(Name1):-
activity(ImageId1,Id1,Name1,Trigger1,Prec1,Post1,Act1,Actname1),Id1=’null’.
activityId not unique(Name1,Name2):-
activity(ImageId1,Id1,Name1,Trigger1,Prec1,Post1,Act1,Actname1),
activity(ImageId2,Id1,Name2,Trigger2,Prec2,Post2,Act2,Actname2),ImageId1\=ImageId2,Id1\=’null’.
B.3 Semantic Rules
createsclass(Name,Class):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,Actname1),
member(action(Type,Class1,Instance),Act1),
Class1=Class,
Type=’Create’.
createsinst(Name,Class,Instance):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,Actname1),
member(action(Type,Class1,Instance1),Act1),
Class1=Class,
Type=’Create’,
Instance1=Instance.
createsno class(Name):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,Actname1),
member(action(Type,Class1,Instance),Act1),
Class1=’null’,
Type=’Create’.
createsno inst(Name):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,Actname1),
Appendix B. Prolog Rules 90
member(action(Type,Class1,Instance),Act1),
Type=’Create’,
Instance=’null’.
updatesclass(Name,Class):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,Actname1),
member(action(Type,Class1,Instance),Act1),
Class1=Class,
Type=’Update’.
updatesinst(Name,Class,Instance):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,Actname1),
member(action(Type,Class1,Instance1),Act1),
Class1=Class,
Type=’Update’,
Instance1=Instance.
updatesno class(Name):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,Actname1),
member(action(Type,Class1,Instance),Act1),
Class1=’null’,
Type=’Update’.
updatesno inst(Name):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,Actname1),
member(action(Type,Class1,Instance),Act1),
Type=’Update’,
Instance=’null’.
deletesclass(Name,Class):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,Actname1),
member(action(Type,Class1,Instance),Act1),
Class1=Class,
Type=’Delete’.
deletesinst(Name,Class,Instance):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,Actname1),
Appendix B. Prolog Rules 91
member(action(Type,Class1,Instance1),Act1),
Class1=Class,
Type=’Delete’,
Instance1=Instance.
deletesno class(Name):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,Actname1),
member(action(Type,Class1,Instance),Act1),
Class1=’null’,
Type=’Delete’.
deletesno inst(Name):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,Actname1),
member(action(Type,Class1,Instance),Act1),
Type=’Delete’,
Instance=’null’.
val create(Path,Class):-
exists(Name3,deletesclass(Name3,Class),member(Name3,Path)).
val delete(Path,Class):-
exists(Name3,createsclass(Name3,Class),member(Name3,Path)).
inv action(Name1,Class,ActionType,ActionOn):-
ActionType=’Delete’,
ActionOn=’class’,
deletesclass(Name1,Class),
not(createdbef(Name1,Class)).
inv action(Name1,Class,ActionType,ActionOn):-
ActionType=’Update’,
ActionOn=’class’,
updatesclass(Name1,Class),
not(createdbef(Name1,Class)).
createdbef(Name1,Class):-
Appendix B. Prolog Rules 92
exists(Name3,createsclass(Name3,Class),path(Name3,Name1,Path)).
inv delete(Name1,Name2,Class):-
deletesclass(Name1,Class),
deletesclass(Name2,Class),
path(Name1,Name2,Path),
not(val delete(Path,Class)),
Name1\=Name2.
inv create(Name1,Name2,Class):-
createsclass(Name1,Class),
createsclass(Name2,Class),
path(Name1,Name2,Path),
not(val create(Path,Class)),
Name1\=Name2.
inv update(Name1,Name2,Name3,Class):-
updatesclass(Name1,Class),
createsclass(Name2,Class),
path(Name2,Name1,Path),
deletedin way(Path,Class,Name3),
Name1\=Name2.
deletedin way(Path,Class,Name3):-
exists(Name3,deletesclass(Name3,Class),member(Name3,Path)).
unreachable(Name):-
activity(ImageId1,Id1,Name,Trigger1,Prec1,Post1,Act1,ActName1),
not(start(Name)),
not(afterstart(Name1,Name)).
afterstart(Name1,Name2):-
activity(ImageId1,Id1,Name1,Trigger1,Prec1,Post1,Act1,ActName1),
activity(ImageId2,Id2,Name2,Trigger2,Prec2,Post2,Act2,ActName2),
start(Name1),
path(Name1,Name2,Path).
Appendix B. Prolog Rules 93
B.4 Loop Detection
precededby(Name1,Name2):-
link(Name1,Name2).
precededby(Name1,Name2):-
junction(Type,PreActivities,PostActivities),
(member(Name1,PreActivities);Name1=PreActivities),
(member(Name2,PostActivities);Name2=PostActivities).
path(X,Y,Path):-
path(X,Y,[],Path).
path(X,Y,Pre,NewPath):-
precededby(X,Y),
append([Y,X],Pre,NewPath).
path(X,Y,Trail,NewPath):-
precededby(X,Z),
not(member(Z,Trail)),
path(Z,Y,[X—Trail],NewPath).
loop(RevPath):-
path(X,X,Path),reverse(Path,RevPath).
B.5 General Rules
insert sort(List,Sorted):-
i sort(List,[],Sorted).
i sort([],Acc,Acc).
i sort([H—T],Acc,Sorted):-
insert(H,Acc,NAcc),isort(T,NAcc,Sorted).
Appendix B. Prolog Rules 94
reverse([],SoFar,SoFar).
reverse([H—T],SoFar,Final):-
reverse(T,[H—SoFar],Final).
insert(X,[Y—T],[Y—NT]):-
aless(Y,X),insert(X,T,NT).
insert(X,[Y—T],[X,Y—T]):-
aless(X,Y);X=Y.
insert(X,[],[X]).
aless(X,Y):-
name(X,L),name(Y,M),alessx(L,M).
alessx([],[— ]).
alessx([X—],[Y— ]):-
X¡Y.
alessx([P—Q],[R,S]):-
P=R,alessx(Q,S).
isemptylist([]).
islist([ — ]).
exists(,Restriction,Body) :-
Restriction,Body,!.
all( ,Restriction,Body) :-
not((Restriction,not(Body))).
Appendix C
Error Messages
C.1 Inconsistency Messages
• Inconsistency in duplicated class: ’Class Name’ different assignments for: Description/Example/Rule/Cross-
Reference.
• Inconsistency in duplicated activity: ’Activity Name’ different assignments for: Trig-
ger/Precondition/Postcondition,Action.
• Inconsistency in duplicated instance: ’Instance Name’ different assignments for: Attributes.
• Inconsistency in action ’Create/Update/Delete Class Name Instance Name’ in activity ’Ac-
tivity Name’, Class/Instance: ’Class/Instance Name’ is not specified in Ontology
C.2 Syntax Messages
• Warning: ’And/Or’ junction, near activity ’Activity Name’ has, ’many-to-many’ connec-
tions which is not allowed. Please change to ’one-to-many’ or ’many-to-one’!
• Warning: you have not specified an ID for activity ’Activity Name’.
• You have duplicated activity ID for activities: ’Activity1 Name’ and ’Activity2 Name’, IDs
must be unique.
95
Appendix C. Error Messages 96
C.3 Semantics Messages
• Invalid action ’Create/Update/Delete’ in activity: ’Activity Name’, no class to be created
has been specified.
• Invalid action ’Update/Delete Class/Instance Name’ in activity ’Activity Name’ , this Class/Instance
has not been previously created in any activity.
• Invalid action ’Create/Delete Class Name’ in activity ’Activity1 Name’, this class has been
already created/deleted in activity ’Activity2 Name’.
• Invalid action ’Update’ in activity ’Activity1 Name’, this class has been already deleted in
activity ’Activity2 Name’.
• Warning: Activity ’Activity Name’, is never reached in the process diagram.
C.4 Loop Detection Message
• Warning: A loop has been detected in path: ’Activity Names of the activities in the path’
please correct this loop if you desire further loop checking to occur!
Appendix D
Evaluation Questionnaire and
Results
D.1 Questionnaire
Intelligent Support for Context-Sensitive Workflow
Level of Expertise
Please tick one or more of the appropriate boxes below:
� 1. I am an expert in FBPML and modelling methods.
� 2. I have some understanding in FBPML and modelling methods.
� 3. I have general knowledge in modelling.
� 4. I have limited knowledge in modelling.
� 5. I have general knowledge in AI.
� 6. I have general knowledge in CS.
� 7. I have no prior knowledge.
Basic Training
Have a quick look at the notation diagrams as a part of the existing FBPML model Nota-
tion.model (figures D.1, D.2).
This model provides you with an example of the notation for FBPML and Ontology diagrams.
Try to understand the syntax as well as the semantics of the notation.
97
Appendix D. Evaluation Questionnaire and Results 100
Now open the PC Configuration FBPML model (figures D.3, D.4).
This is an example model using the notation described above. Try to familiarise yourself with
the diagrams by browsing through the model.
Figure D.3: PC Configuration Process Diagram
Appendix D. Evaluation Questionnaire and Results 102
Model Recreation
Task I: Create a new FBPML model consisting of the following diagrams:
Process Diagram: ”Top Level Process”
Figure D.5: ”Top Level Process” Process Diagram
Assign Properties to the activity ’Obtain Customer Requirements’ (hint: right-click on the
activity and choose Properties) using the values below:
Triggers: ”meeting=true”,
Preconditions: ”Customer created”,
Postconditions: ”Report created”,
Action: ”Create”
Class: ”Customer”
Task II : Create a new ontological model with the diagram below:
Ontology Diagram: ”Domain Ontology”
Figure D.6: ”Domain Ontology” Ontology Diagram
Appendix D. Evaluation Questionnaire and Results 103
Assign Properties to Class ’Customer’ (hint: right-click on the activity and choose Properties)
with the values below:
Description: ”A new customer”,
Example: ”John Smith”,
Rules: ”Record all customer details”,
Cross-Reference: ”Customer in Other.model”
Assign Object Attributes to Class ’Customer’ (hint: right-click on the activity and choose Ob-
ject Attributes):
1. Name,
2. Surname,
3. Address
Assign Attributes to instance ’John Smith’ (hint: right-click on the activity and choose Attributes):
Name: ”John”
Surname: ”Smith”
Address: ”21 S. Road, Edinburgh”
After you have completed the model save it in a file named ”EvaluationYourName.model” and
try to answer the following questions:
a. Did you find it reasonably easy to create the diagrams? If not, will you please explain why
not?
b. Did you find the interface reasonably useful? Do you have any suggestion of improvements
that would make the creation of the diagrams easier?
c. Any other comments?
Appendix D. Evaluation Questionnaire and Results 104
Modelling Support Evaluation
Open the model ”PC ConfigurationErrors.model” (figures D.7, D.8). You have seen some of
those diagrams in this model, as they have been used as examples earlier. However this version
has been created to include errors such as inconsistencies, syntactic errors etc.
Figure D.7: ”PC Configuration Errors” Process Diagram
Appendix D. Evaluation Questionnaire and Results 105
Figure D.8: ”PC Configuration Errors” Ontology Diagram
Appendix D. Evaluation Questionnaire and Results 106
Task I: Try to use the Modelling Support functionality of the system, to detect these errors.
For each category answer the following questions:
a. Did you fully understand the error messages for:
Inconsistencies:
Syntax:
Semantics:
Loop Detection:
b. Were you able to trace back the errors in the model (and correct the errors)?
Inconsistencies:
Syntax:
Semantics:
Loop Detection:
Appendix D. Evaluation Questionnaire and Results 107
Task II: Now try to create a new fault in one of the diagrams, similar to the ones that were
detected. Then answer the following questions:
a. What fault did you create? (Please include the type e.g. ”Inconsistency”, ”Syntactic error”, etc.)
b. Did the system detect your fault?
c. If yes, was the message provided, the one you expected to get?
d. Do you have any other comments about this facility?
Appendix D. Evaluation Questionnaire and Results 108
General Comments
Please provide some more general comments relating to the below topics:
Usability of the system:
Graphical Interface:
Anything else you would like to add:
Appendix D. Evaluation Questionnaire and Results 109
D.2 Results
Here you can see the answers that the five test users gave to the above questionnaire. User’s an-
swers are shown as A, B, C, D, E to denote which user gave which answer.
Level of Expertise
A: 5, 6
B: 3, 5, 6
C: 1,5,6
D: 6
E: 4
Model Recreation
Task I/II :
a. Did you find it reasonably easy to create the diagrams? If not, will you please explain why not?
A: Yes it was pretty easy for me to create my own FBPML model using your tool
B: Yes it was very easy, except that I’m not used to right-clicking (MacOs user)
C: Yes it was very easy maybe tooltips would be useful. And in order to add an attribute to the
ontology it would be better if there was already a line there.
D: Yes very easy.
E: It was easy but took a little bit of training first.
b. Did you find the interface reasonably useful? Do you have any suggestion of improvements
that would make the creation of the diagrams easier?
A: It would be nice to provide some keynotes for the hot keys on the tool bar for those who
are not familiar with the notations of FBPML. In addition, the links can only be straight line,
which make the complex modelling difficult.
B: I did not like that the labels in some icons were tilted. Put activity buttons straight up. Tooltips.
C: Yes it was useful enough. Maybe some ready templates would be helpful.
D: I’d like to have tooltips on the buttons (process diagrams)
E: Yes it is useful.
c. Any other comments?
A: There are some small technical problems with the interface
B: None given
Appendix D. Evaluation Questionnaire and Results 110
C: Lack of undo functionality (Ctr-Z) in the text box of the Property Dialog
D: None given
E: None given
Appendix D. Evaluation Questionnaire and Results 111
Modelling Support Evaluation
Task I:
a. Did you fully understand the error messages for:
Inconsistencies:
A: Yes
B: Yes
C: Doesn’t mention which diagram it refers to.
D: Yes
E: Yes
Syntax:
A: Yes
B: Yes
C: Double message
D: Double message for not Unique id
E: Yes
Semantics:
A: Yes
B: Yes
C: Yes
D: Yes
E: Yes
Loop Detection:
A: Yes
B: Yes
C: Yes
D: Yes
E: Yes
b. Were you able to trace back the errors in the model (and correct the errors)?
Inconsistencies:
A: Yes especially for the model you provided.
B: Yes
C: Yes
D: Yes
Appendix D. Evaluation Questionnaire and Results 112
E: Yes
Syntax:
A: Yes especially for the model you provided.
B: Yes
C: Yes
D: Yes
E: Yes
Semantics:
A: Yes especially for the model you provided.
B: Yes
C: Yes
D: Yes
E: Yes
Loop Detection:
A: Yes especially for the model you provided.
B: Yes
C: Yes
D: Yes
E: Yes
Task II :
a. What fault did you create? (Please include the type e.g. ”Inconsistency”, ”Syntactic error”, etc.)
A: Not answered
B: Syntactic error ”many to many OR junction”
C: Loop and syntactic error
D: Syntactic
E: Semantic
b. Did the system detect your fault?
A: Not answered
B: Yes
C: Yes
D: Yes
E: Yes
Appendix D. Evaluation Questionnaire and Results 113
c. If yes, was the message provided, the one you expected to get?
A: Not answered
B: Yes
C: Yes
D: Yes
E: Yes
d. Do you have any other comments about this facility?
A: Not answered
B: Ok and Close button do the same thing? You could highlight the errors in the diagram
C: I would like to have the checking results in the background and be able to bring it back, or a
split screen functionality. A recheck button?
D: No
E: Yes I think it is very useful
General Comments
Usability of the system:
A: It is a good system. It gives us an opportunity to create FBPML models using its diagram
notations. For a person who knows the notation of FBPML, he/she can pick up this toll rapidly
and use it to develop his/her own FBPML model.
B: In general OK, just had problems with understanding some icons.
C: Without being an expert I think the modelling support was very useful and intuitive.
D: Very easy to use.
E: It is a nice system that could be very useful.
Graphical Interface:
A: Nice graphical interface.
B: OK.
C: The GUI is good and intuitive but more functionality would be beneficial.
D: GOOD.
E: It’s a nice interface looks like other tools so I’m used to it.
Anything else you would like to add:
A: Not answered.
B: Not answered.
Appendix D. Evaluation Questionnaire and Results 114
C: Not answered.
D: Not answered.
E: Not answered.
Bibliography
Chen-Burger, Y.-H. (2001).Formal Support for an Informal Business ModellingMethod. PhD thesis, University of Edinburgh.
Chen-Burger, Y.-H. (2002a). Informal Semantics for the FBPML Data Language.Technical report, School of Informatics, the University of Edinburgh.
Chen-Burger, Y. H. (2002b). Sharing and checking organisation knowledge. InDieng-Kuntz, R. and Matta, N., editors,Knowledge Management and Organi-zational Memories. Kluwer Academic Publishers, Boston Hardbound.
Chen-Burger, Y. H. and Robertson, D. (1998). Formal support for an informalbusiness modelling method. InThe Tenth International Conference on SoftwareEngineering and Knowledge Engineering, SEKE’98.
Chen-Burger, Y. H., Tate, A., and Robertson, D. (2002). Enterprise modelling: Adeclarative approach for FBPML. InEuropean Conference of Artificial Intelli-gence, Knowledge Management and Organisational Memories Workshop.
Curtis, B., Kellner, M., and Over, J. (1992). Process modelling. InCommunica-tions of the ACM, volume 35, pages 75–90.
Declarativa Servinos de Informatica, Lda (2004). Java+Prolog systems and in-terfaces. Website.http://www.declarativa.com/interprolog/systems.htm.
Gaudenz, A. (2003). Design and Implementation of the JGraph Swing Compo-nent. Website.http://prdownloads.sourceforge.net/jgraph/paper-11 0 0.pdf.
Georgakopoulos, D., Hornick, M., and Sheth, A. (1995). An overview of work-flow management: From process modeling to workflow automation infrastruc-ture. InDistributed and Parallel Databases, volume 3, pages 119–153.
115
Bibliography 116
Guo, L., Chen-Burger, Y.-H., and Robertson, D. (2004). Mapping a businessprocess model to a semantic web services model. InIEEE International Con-ference on Web Services.
Hammer, M. and Champy, J. (1993). Reengineering the corporation: A manifestofor business revolution. InHarper Business, New York.
IDEF3 (1995). Information integration for concurrent engineering (iice) idef3process description capture method report. InKnowledge Based Systems Inc.(KBSI).
IEEE (1998). IEEE recommended practice for software requirements specifica-tions. Technical report, The Institute of Electrical and Electronics Engineers,Inc, USA.
IX Technology for Intelligent Systems (2000-2004). Artificial intelligence appli-cations institute, school of informatics. Website.http://www.aiai.ed.ac.uk/project/ix/.
JGraph (2004). Professional open source java graph visualization. Website.http://www.jgraph.com.
JIProlog (2004). Java Internet Prolog. Website.http://www.ugosweb.com/jiprolog/.
JTree (2004). Java Technology Documentation, JTree API Specification. Website.http://java.sun.com/j2se/1.4/docs/api/javax/swing/JTree.html.
KBSI (2004). Knowledge Based Systems, Inc. AI/0WIN c©. Website. http://www.kbsi.com/Software/AI0WIN.htm.
Kuo, H.-L. (2002). Knowledge Management using Business Process Modellingand Workflow Techniques. Master’s thesis, University of Edinburgh.
Kuo, H.-L., Chen-Burger, Y.-H., and Robertson, D. (2003). Knowledge man-agement using business process modeling and workflow techniques. In18thInternational Joint conference on Artificial Intelligence (IJCAI), Workshop onKnowledge Management and Organizational Memories.
Mayer, R., Menzel, C., Painter, M., Witte, P., Blinn, T., and Perakath, B. (1995).Information integration for concurrent engineering (iice) idef3 process descrip-tion capture method report. Technical report.
OWL-S (2004). OWL-S 1.0 Release. Website.http://www.daml.org/services/owl-s/1.0/.
Bibliography 117
Petri Nets (2004). A list of literature including introductory material on vari-ous kinds of Petri Nets. Website.http://www.daimi.au.dk/PetriNets/introductions/.
Renew 2.0 for Petri Net (2004). Theoretical Foundations Group of the Departmentfor Informatics, University of Hamburg. Website.http://www.renew.de/.
Schlenoff, C., Knutila, A., and Ray, S. (1997). Proceeding of the process specifica-tion language(psl) roundtable. InNISTIR 6081, National Institute for Standardsand Technology, Gaithersburg,MD. http://www.nist.gov/psl/.
Ugo, C. (2004). JIProlog 2.1.0 reference manual. Website.http://www.ugosweb.com/jiprolog/.
University of Edinburgh (2004). Artificial intelligence applications institute,school of informatics. Website.http://www.aiai.ed.ac.uk.
Recommended