intelligent support for context sensitive business process...

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

I would like to dedicate this thesis to my parents,

George Kartsounis and Evanthia Fourli.

iv

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

D.8 ”PC ConfigurationErrors” Ontology Diagram . . . . . . . . . . . 105

x

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)


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).


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


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.


• 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.


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


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


• 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.


• 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


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


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


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


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


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.


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


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


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:


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


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.


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-


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)


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


• 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)


¬(∃Pre b∈ Preactivities

∧∃Post b∈ Postactivities)


junction(Type,Preactivities,Postactivities)∧ (∃Post a∈ Postactivities)⇒

¬(Preactivities= nil)


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)


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(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.


∧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


∧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.



Class, Instance,




∧action(Delete,Class, Instance) ∈ Action a


∧action(Create,Class, Instance) ∈ Action b





∧action(Delete,Class, Instance) ∈ Action c∧path(Namec,Nameb)


Axiom 12 An actionshould not deletea class that hasnot been previously

createdby another activity.


Postconditiona,Action a,Class, Instance.


∧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.


Postconditiona,Action a,Class, Instance.


∧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)


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.



Class, Instance,




∧action(U pdates,Class, Instance) ∈ Action a


∧action(Create,Class, Instance) ∈ Action b





∧action(Delete,Class, Instance) ∈ Action c∧path(Namec,Nameb)


Axiom 15 All activities should be reachable in a process model.


Postconditiona,Action a,Nameb,Trigger 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


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:


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.


• 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


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.


Figure 6.8: The Activity Label text box

Figure 6.9: The Activity Properties window


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.


Figure 6.11: Junctions that can be defined


�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)


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.


Figure 6.15: Right-click Concrete class Menu


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


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.


Figure 6.19: No Concrete Class error

Figure 6.20: No Concrete Class Object Attributes error


�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,


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


Figure 6.23: Close warning

prompted to save the model before exiting (see figure 6.24).


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


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.


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


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.


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


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”.


Figure 6.32: The Consistency errors detected in the model

Figure 6.33: The corrected model


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:


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:


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-


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.


• 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.


- 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.


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


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.


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-


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.


• 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


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


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:


• 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


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.


• 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

A model consisting of the following process and ontology diagrams:

85

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’.




insert sort(Prec1,SortedPrec1),insertsort(Prec2,SortedPrec2),

SortedPrec1\=SortedPrec2,ImageId1\=ImageId2,Attribute=’Precondition’.




insert sort(Post1,SortedPost1),insertsort(Post2,SortedPost2),

SortedPost1\=SortedPost2,ImageId1\=ImageId2,Attribute=’Postcondition’.




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’.




Example\=Example1,ImageId1\=ImageId2,Property=’Example’.




Rule\=Rule1,ImageId1\=ImageId2,Property=’Rules’.




Cross\=Cross1,ImageId1\=ImageId2,Property=’Cross-Reference’.




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.


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(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):-


member(action(Type,Class1,Instance1),Act1),

Class1=Class,

Type=’Create’,

Instance1=Instance.

createsno class(Name):-



Class1=’null’,

Type=’Create’.

createsno inst(Name):-




Type=’Create’,

Instance=’null’.

updatesclass(Name,Class):-



Class1=Class,

Type=’Update’.

updatesinst(Name,Class,Instance):-



Class1=Class,

Type=’Update’,

Instance1=Instance.

updatesno class(Name):-



Class1=’null’,

Type=’Update’.

updatesno inst(Name):-



Type=’Update’,


deletesclass(Name,Class):-



Class1=Class,

Type=’Delete’.

deletesinst(Name,Class,Instance):-




Class1=Class,

Type=’Delete’,

Instance1=Instance.

deletesno class(Name):-



Class1=’null’,

Type=’Delete’.

deletesno inst(Name):-



Type=’Delete’,


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):-


exists(Name3,createsclass(Name3,Class),path(Name3,Name1,Path)).

inv delete(Name1,Name2,Class):-



path(Name1,Name2,Path),

not(val delete(Path,Class)),

Name1\=Name2.

inv create(Name1,Name2,Class):-

createsclass(Name1,Class),



not(val create(Path,Class)),

Name1\=Name2.

inv update(Name1,Name2,Name3,Class):-

updatesclass(Name1,Class),



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).


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).


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 98

Figure D.1: Notation Process Diagram


Figure D.2: Notation Ontology Diagram


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


Figure D.4: PC Configuration Ontology Diagram


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


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?


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


Figure D.8: ”PC Configuration Errors” Ontology Diagram


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:


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?


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:


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


C: Lack of undo functionality (Ctr-Z) in the text box of the Property Dialog

D: None given

E: None given


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


E: Yes

Syntax:


B: Yes

C: Yes

D: Yes

E: Yes

Semantics:


B: Yes

C: Yes

D: Yes

E: Yes

Loop Detection:


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


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.


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.

intelligent support for context sensitive business process...

Documents