MOGENTES_2-07_1.1w_D2.2c_Updated-Framework ...

rangaleclickSoftware and s/w Development

Nov 4, 2013 (3 years and 10 months ago)

241 views




Version
:

1.
1




Status:
working



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc






MOGENTES

Model
-
Based Generation of Test
-
Cases

for Embedded Systems


Framework Implementation




Updated

Version








Proj
ect

MOGENTES

Contract Number

216679

Document Id


2
-
0
7
_
1
.
1w


Date

2013
-
11
-
04

Deliverable

D2.
2c

Contact Person

Balázs Polgár

Organisation

BME

Phone

+36
-
1
-
463
-
3579

E
-
Mail

polgar@mit.bme.hu



MOGENTES


Framework Implementation

-

Updated

Version


Page
2
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


Distribution Table


Name

Company

Department

No. of

copies

Hardcopy/
Softcopy

All MOGENTES team members




SC









Change

History


Version

Date

Reason for Change

Pages

Affected

1.0

20
11
-
03
-
3
1

Released

version

all
































MOGENTES


Framework Implementation

-

Updated

Version


Page
3
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


Contents



1

INTRODUCTION

................................
................................
................................
................................
....................

6

1.1

P
URPOSE AND
S
COPE

................................
................................
................................
................................
...........

6

1.2

P
ARTNER
C
ONTRIBUTIONS

................................
................................
................................
................................
..

7

2

IMPLEMENTATION OF TH
E GENERAL TOOL INTEG
RATION

FRAMEWORK

................................
...

8

2.1

F
RAMEWORK
A
RCHITECTURE

................................
................................
................................
..............................

8

2.2

D
ESCRIPTION OF THE
C
OMPONENTS

................................
................................
................................
....................

9

2.2.1

Overview

................................
................................
................................
................................
.....................

9

2.2.2

Process Management

................................
................................
................................
................................

12

2.2.3

Remote execution support

................................
................................
................................
.........................

14

2.3

I
NSTALLATION OF THE
C
OMPONENTS

................................
................................
................................
................

15

Step A: Installing the Service Development Environment (SDE)

................................
................................
.............

15

Step B: Prepare the workflow execution environment

................................
................................
..............................

16

Step C: Install the repository component

................................
................................
................................
..................

17

Step D: Install the traceab
ility component

................................
................................
................................
...............

18

2.4

U
SER

S
G
UIDE

................................
................................
................................
................................
...................

18

2.4.1

User interface basics
................................
................................
................................
................................
.

18

2.4.2

Designing tool integration processes

................................
................................
................................
........

19

2.4.3

Managing Process Executions

................................
................................
................................
..................

20

2.4.4

Artefact Management

................................
................................
................................
................................

23

2.4.5

Creating a tool connector: Overview

................................
................................
................................
........

24

2.4.6

Tool Connector example

................................
................................
................................
...........................

25

3

THE MOGENTES TEST GE
NERATION FRAMEWORK

................................
................................
..............

28

3.1

T
HE
UML

AND
S
IMULINK BASED
T
RACK

................................
................................
................................
..........

30

3.1.1

Input Artefacts
................................
................................
................................
................................
...........

30

3.1.2

UML based TCG

................................
................................
................................
................................
.......

32

3.1.3

Simulink based TCG

................................
................................
................................
................................
.

35

3.1.4

Output Artefacts

................................
................................
................................
................................
........

39

3.2

T
HE
P
ROVER I
L
OCK BASED
T
RACK
................................
................................
................................
....................

39

4

MOGENTES TOOLS AND P
ROCESSES IN THE FRAM
EWORK

................................
...............................

41

4.1

TCG

WITH
A
CTION
S
YSTEMS

................................
................................
................................
............................

42

4.2

TCG

WITH
UPPAAL

................................
................................
................................
................................
.........

45

4.3

F
AULT
I
NJECTION

................................
................................
................................
................................
..............

47

4.4

O
NTOLOGY
B
ASED
V
ALIDATION

................................
................................
................................
.......................

49

5

TRANSFORMATIONS

................................
................................
................................
................................
.........

51

5.1

P
ARAMETERIZATION OF
UML

MODELS

................................
................................
................................
.............

51

5.2

UML

TO
A
CTION
S
YSTEMS

................................
................................
................................
...............................

51

5.2.1

UML to Object Oriented Action Systems

................................
................................
................................
..

52

5.2.2

Object Oriented Action Systems to Action Systems

................................
................................
...................

54

5.3

S
IMULINK TO
A
CTION
S
YSTEM

................................
................................
................................
..........................

55

5.3.1

The Definition of Bloc
k Types

................................
................................
................................
...................

56

5.4

UML

TO
UPPAAL

................................
................................
................................
................................
............

57

5.4.1

Conceptual Steps of the Transformation

................................
................................
................................
...

57

5.4.2

Implementation of a UML Model in Uppaal

................................
................................
.............................

58

5.4.3

Design Decisions and Practical Considerations

................................
................................
......................

59

6

TRACEA
BILITY

................................
................................
................................
................................
...................

60

6.1

R
EQUIREMENTS MODELLIN
G

................................
................................
................................
.............................

60

6.2

T
RACEABILITY
M
ANAGEMENT
S
UPPORT IN THE
F
RAMEWORK

................................
................................
..........

60

6.2.1

The Traceability Information Repository Model

................................
................................
.......................

61

6.2.2

Storing traceability information
................................
................................
................................
................

6
2

6.2.3

Retrieving traceability information

................................
................................
................................
...........

63

MOGENTES


Framework Implementation

-

Updated

Version


Page
4
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


6.3

I
MPLEMENTATION OF
T
RACEABILITY DURING
T
EST
C
ASE
G
ENERATION

................................
...........................

67

6.3.1

UPPAAL tra
ck

................................
................................
................................
................................
..........

67

6.3.2

AS track

................................
................................
................................
................................
.....................

68

6.4

I
NTEGRATION OF
T
EST
M
ANAGEMENT WITH
T
EST
C
ASE
G
ENERATION

................................
.............................

69

6.4.1

DECOS Generic Test Bench Outline

................................
................................
................................
........

69

6.4.2

Integration of Test Management with Test Case Generation
................................
................................
....

70

6.5

R
EQUIREMENTS
T
RACING
E
XAMPLE

................................
................................
................................
.................

71

7

ABBREVIATIONS AND DE
FINITIONS

................................
................................
................................
............

73

8

REFERENCES

................................
................................
................................
................................
.......................

74

9

APPENDIX


PROCESS METAMODEL

................................
................................
................................
...........

76

10

APPENDIX


PROCESS EXECUTION SC
RIPT

................................
................................
...........................

77


MOGENTES


Framework Implementation

-

Updated

Version


Page
5
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


Figures

Figure 2
-
1: Architecture of the general tool integration framework

................................
................................
....

8

Figure 2
-
2: Implementation architecture

................................
................................
................................
.............

9

Figure
2
-
4: Data repository interface

................................
................................
................................
................

11

Figure 2
-
5: Detailed Architecture of the Process Management components

................................
...................

13

Figure 2
-
6: An examp
le deployment of potential framework components in a distributed environment

..........

15

Figure 2
-
7: The SDE tool browser

................................
................................
................................
....................

18

Figure 2
-
9:
The graphical Process Editor

................................
................................
................................
.........

20

Figure 2
-
10: Process Manager

................................
................................
................................
.........................

22

Figure 2
-
11:
Processes

view of the
Process Execution User Interf
ace

in Eclipse 3.4

................................
.....

23

Figure 2
-
12:
Workflow view

of the
Process Execution User Interface

in Eclipse 3.4

................................
.......

23

Figure 2
-
13: The JCR
Repository Browser user interface

................................
................................
................

24

Figure 3
-
1: The MOGENTES test generation workflow

................................
................................
...................

29

Figure 3
-
2: Parameterization of UML mo
dels

................................
................................
................................
...

30

Figure 3
-
3: Simulink model example

................................
................................
................................
................

32

Figure 3
-
4: Details of the UML to Action System transformation

................................
................................
.....

33

Figure 3
-
5: Test case generation with CBMC
................................
................................
................................
...

36

Figure 3
-
6: goto program scheme

................................
................................
................................
....................

37

Figure 4
-
1: Tools integrated into the tool integration framework

................................
................................
......

41

Figure 4
-
2: The services of the Ulysses tool

................................
................................
................................
....

42

Figure 4
-
3:

The first part of the AS based TCG process (transformation and TCG)

................................
........

43

Figure 4
-
4: The second part of the AS based TCG process (uploading results to repository)

........................

44

Figure 4
-
5: The services of the UPPAAL based TCG tool

................................
................................
...............

45

Figure 4
-
6: The UPPAAL based TCG process

................................
................................
................................
.

46

Figure 4
-
7: The services of the UPPAAL trace to AUT converter tool

................................
.............................

47

Figure 4
-
8: The services of the MODIFI and SWIFI tools

................................
................................
................

48

Figure 4
-
10: The services of the Ontology based validation and the metric calculation tools

.........................

49

Figure 4
-
11: The UML to OWL transformation process

................................
................................
...................

50

Figure 5
-
1: State machine of FFA Car Alarm System

................................
................................
......................

53

Figure 5
-
2: Overview of the Simulink to Action System Translation

................................
................................

56

Figure 6
-
1: An example tool chain with traceability information

................................
................................
.......

61

Figure 6
-
2: Traceability Information Repository metamodel

................................
................................
.............

62

Figure 6
-
3: Trace metamodel

................................
................................
................................
...........................

63

Figure 6
-
4: Trace Filter metamodel

................................
................................
................................
..................

65

Figure 6
-
5: Trace Info Query wizar
d

................................
................................
................................
.................

66

Figure 6
-
6: Example trace shown in a tree view in the Trace Info Viewer

................................
.......................

67

Figure 6
-
7: Loading Requirement


UML model elem
ent links to Traceability Information Repository

...........

67

Figure 6
-
8: Integration of test execution into the MOGENTES test generation framework

.............................

71

Figure 9
-
1: Process metamodel

................................
................................
................................
.......................

76


Tables

Table 3
-
1: Application of TCG Tracks to Demonstrator Applications

................................
...............................

30

Table 5
-
1: Mappings of UML elements to OOAS

................................
................................
.............................

53


MOGENTES


Framework Implementation

-

Updated

Version


Page
6
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


1

Introduction


1.1

Purpose and Scope

Since deliverable
D2.2
is the only one in WP2
all the results achieved in the workpackage are described
here. It is an updat
e of the
second
ve
rsion of this deliverable (D2.2b
).

In WP2 the following tasks ha
d

to be
performed:



establishment of a tool integration framework,



integration of tools,



support for traceability,



integration of the Generic Test Bench with the tool integrat
ion framework
.

Below we give a short overview about these items.


Tool integration framework

A

pre
-
final

implementation of the

General Tool Integration Framework

has been
described in the
second
version of
this deliverable, D2.2b
, containing
description
of

the tool management, artefact management,
process modelling, and process execution

management components
.
In the last year the traceability
component had been updated, an advanced process modelling component had been developed, which is
independent of the

underlying workflow engine, and the process execution management component had
been improved to use the new process model, to be workflow engine independent and to support remote
supervision.

Th
e tool integration framework

is discussed in
chapter

2
: after describing the implementation architecture, a
short overview about the installation steps is given followed by a detailed description how to use the
framework (a user guide).
Finally

the integration of tools to this framework

is discussed
.



Integration of tools

We call the union
and relation
of all methods
,

tools
, and formalisms

that have been used
or
were
developed
in the project, the
MOGENTES Test Generation Framework

or the

MOGENTES Toolchains
. Initial
versions have been o
utlined in deliverables D2.1 and D2.2a.
In D2.2b a pre
-
final version was described.
Here in this document we give an updated
(final)
version of this framework (
chapter

3
).

All tools and models
involved in the toolchains are des
cribed shortly and
reference
s are given
to other deliverables where detailed
descriptions can be found.

The transformations that helped the integration of different tools and formalisms
are described in more details here, in chapter
5
.

In chapter
4

an overview is given about the integration of the MOGENTES tools into
the
Tool Integration
Framework and the executable processes (toolchains) created from these.

The c
ontent of the former chapter 4, descr
ibing auxiliary formalisms have been moved into D4.5.


Requirement traceability

When test cases are generated from models, it is finally crucial to evaluate the coverage of requirements by
these test cases. Since application specific test cases are not gen
erated directly from requirements but
finally emanate after several transformation and processing steps (with the respective workflow controlled by
the framework), two basic ingredients are necessary:



At each processing step, the relation of inputs to outp
uts capturing the association with requirements
needs to be recorded.



These input/result
-
associations have to be combined to finally establish the requirements/test
-
case
correlations.


The traceability manager component is improved significantly in the las
t year and now traceability related
issues are described in a separate chapter (chapter
6
).
It contains a description about the requirements
modelling (which is the basis for identifying requirements), the traceability manager
component (what
traceability model is applied, how traceability information can be stored and how it can be queried)

and the
way how traceability information is produced in the toolchains.


MOGENTES


Framework Implementation

-

Updated

Version


Page
7
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


Connection to the Generic Test Bench

The Generic Test Bench, which

has been developed in the FP6 IP DECOS, is a requirements
-
driven test
automation tool supporting the establishment of safety cases. Considering its
potential to exploit the
outcomes of MOGENTES for certification of safety
-
critical embedded systems,

its in
tegration with the tool
integration framework has been investig
ated and a solution elaborated. This environment extends the
traceability management applied in the framework for TCG processes with the management of the
requirements on the one side, and with

the management of tests and test execution on the other and it
provides support for generating safety cases for the developed application. Details of it is
discussed in
section
6.4

as part of the Traceability chapter.


1.2

Partner

Contributions

This document has been produced by BME with contributions from AIT
, ETH, PROV, SP and TUG
, in
particular the descriptions of the individual tools in chapter 3
,
connectors, processes and
transformations in
chapter
4 and
5
,

and the
traceabilit
y management and
test bench integration in chapter
6
.




MOGENTES


Framework Implementation

-

Updated

Version


Page
8
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


2

Implementation of the General Tool Integration Framework

2.1

Framework Architecture

This section gives an overview

of
the framework that was specified in details in deliverable
D2.1

Tool
Integration Fram
ework Specification
. It supports the integration of tools
in general,

independently of the
concrete tools, which is applicable for test generation processes.

The
general tool integration framework

supports



the model based definition of the integration of t
ools and their input/output artefacts,



the model based execution of the tools together with supervision and tracing of the execution,



management of the artefacts (models, data files, etc.) handled during the tool integration.


Process Editor
Process Execution
User Interface
Process Execution
Engine
Data
Repository
Tool A
Tool B
Tool C
Connector A
Connector B
Connector C
Process
Model
Artefact
Manager
Tool
Repository
Tool Manager
control flow
data flow

Figure
2
-
1
: Architecture of the general tool integration framework

The architecture
of

the general tool integration framework can be found in

Figure
2
-
1
.
It contains the
following
components:



The basis of the framework is the
Process Model

that defines the
tools, artefacts, tasks and roles
involved in the tool integration process
. I.e., it contains the information about who does what, on
which artefact, with which tool. It can be cr
eated according to development standards, domain
requirements or best practices.



The
Process Editor

supports the
creation of the Process Model
.



The
Tool Manager

manages the instances of tools

and stores them in a
Tool Repository
. The Tool
Manager is respo
nsible for the registration, initialization and finalization of the tools; it gives
information about them and provides the “invokable” tools to the Process Execution Engine. It
supports also the
mapping between the tool components in the Process Model and

the tool
instances
.



The
Process Execution Engine

executes the steps defined in the Process Model: it
invokes single
tools or tool
-
chains

using the instances got from the Tool Manager and
feeds back the status
information

to the supervisory interface (Pro
cess Execution User Interface) based on the same
Process Model.



The
Process Execution User Interface

is for
managing

and
supervising

the execution of the
process by humans involved in the execution of the activities supported by the framework. If the
execu
tion of a tool or tool
-
chain is initiated on the User Interface then it calls the Process Execution
Engine. The User Interface provides information visualized with the help of the Process Model (i)
MOGENTES


Framework Implementation

-

Updated

Version


Page
9
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


about the status of the execution of the tool
-
chain and (i
i) about the artefacts created or handled
during the process. The information about the artefacts is retrieved from the Artefact Manager.



Models and data files (i.e., artefacts) handled during the tool integration process are also described
in the Process
Model. Instances of them that are already created by a tool are stored in a
Data
Repository

which

is
handled by an
Artefact Manager
. This Artefact Manager can support version
handling of the artefacts and is also responsible for traceability management reg
arding models and
model elements.



For each tool a
Connector

must be created that provides a uniform interface for the tools that can
be managed by the Tool Manager and can be invoked by the Process Execution Engine, i.e., tools
are registered and invoked t
hrough Connectors. Upon invocation it retrieves the input artefacts
needed by the tool from the Data Repository, and uploads the output artefacts provided by the tool to
the Data Repository, through the Artefact Manager.
The Connector is also responsible f
or uploading
traceability related information.



A
Tool

represents a component of the process. It can be either a legacy tool or a newly developed
tool that can be executed automatically (e.g. a test generator tool or a transformation component),
and the ste
ps representing user interaction in the process should be implemented also as tools.


2.2

Description of the Components

2.2.1

Overview


Process Execution Engine
SDE Tool Manager
jBPM engine
PEE Connector for jBPM
Process Editor
Data
Repository
(
Derby
)
Tool A
SDE Connector A
General
Process
Model
control flow
data flow
Tool B
SDE Connector B
Tomcat
Java Content
Repository
(
Jackrabbit
)
Web
DAV
JavaRPC
HTTP
Process Execution User Interface
jPDL
Model
Transf
.
SDE Action Handler for jBPM

Figure
2
-
2
:
Implementation architecture

The impl
emen
tation architecture of the t
ool
i
ntegration
f
ramework
is shown in

Figure
2
-
2
. The following
software components have been chosen

or implemented

for the generic design elements of the
f
ramework
architecture (see

Figure
2
-
1
):



General Process Model
: an execution engine independent process metamodel has been defined
on the basis of UML activity models (it contains the relevant elements of the UML activity metamodel
in a simplified form). The process models des
cribing tool chains are instances of this metamodel.



Process Editor
: an Eclipse GMF
[GMF]

based
graphical editor has been developed based on
the
process metamodel
mentioned above. This editor imports

the tools registered in the SDE Too
l
Manager
and makes it possible to create tool
-
chains from it.



Tool Manager
: the
Service

Development Environment
[SDE]

is used as a core tool management
component; it provides
an

Eclipse
-
based user interface
where execution of the tools

can be initiated
MOGENTES


Framework Implementation

-

Updated

Version


Page
10
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


and the base classes for creating tool connecto
rs. It
s other features such as Javascript
-
based tool
orchestration and temporary data storage (Blackboard) may also be used.



Tool Connectors
: the framework relies on the core functionality
of the SDE to cre
ate and support
tool connectors.

It has been
exten
ded with

support for

the
use of
other components of the framework
(e.g.,
data repository
)

and with support for managing traceability related tasks
.



Process Execution Engine
: as the process
execution engine, the JBoss jBPM
[jBPM]

software
package has been integrated into the system (as a special
SDE

tool). The jBPM has been
augmented with a special action handler component (called the
SDE

Action Handler), which enables
th
e engine to invoke

services of

tool
s

through the tool manager component. This way, as the engine
is processing the workflow model,
services of
tool
s

can
be invoked (with referencing data in

the Data
Repository, and/or process variables used to propagate in
formation within a workflow session).

The
status of the execution is stored in a
persistent
database (in the framework MySQL DB is used)
.



Process Execution User Interface
:

The process execution user interface is
implemented as a new,
separate component (
an

Eclipse
application
).
This maintains
a catalogue of the general process
models, enables the deployment of these to workflow engines
, process instances can be
created,
parameterized and
started and their status can be monitored.
Currently the jBPM SDE tool

is
integrated into the user interface.



Data Repository/Artefact Manager
:
A general data repository component is developed as a thin,
universal access interface to different data repositories. It hides details about the concrete
implementation (whether it
is a file system, Jackrabbit database or something other) and about the
location of the repository (whether it is on a local or on a remote machine).

T
he Apache Foundations JSR
-
170 implementation called JackRabbit [Jackrabbit]
i
s an object
-
oriented metadat
a
-
assisted data repository
.

An SDE tool connector is implemented to this interface
and this is registered to the Artefact Manager component as a Data Repository.
Data storage
in
JackRabbit
is carried out with an integrated Apache Derby SQL database managem
ent system.

This

data repository can be acce
ssed via (i) the tool interface

in

the integration framework, (ii) the
HTTP
-
based WebDAV protocol, and (iii) the Java RMI interface that is usable from any Java
program (remotely).


2.2.2

Data Management

Data managemen
t is implemented in two layers

(
Figure
2
-
3
)
:



The
General Data Repository

tool provides a uniform interface to multiple repositories. The
background repositories can be of different types and can be located on different hosts. Whe
n
accessing data through this general component,
an
address
with uniform structure is used to access
data. The address
contains information about the host
,

the type of the repository

and the location of
the data within that repository
.



S
pecific data reposi
tories are connected to the framework by a dedicated
SDE
tool connector; this
enables the access of that single repository from other to
ols integrated to the framework

through the
General Data Repository component (but also direct access is possible)
.

The

Artefact Manager

is composed of multiple components: it contains the
General Data Repository

tool, the
specific repository connectors and a component for managing traceability related information (
Traceability
Manager Tool
).
The former two is discussed he
re in
details;

the later is described later, in Chapter
6
.


MOGENTES


Framework Implementation

-

Updated

Version


Page
11
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


Process Editor
Process Execution
User Interface
Process Execution
Engine
Tool A
Tool B
Tool C
Connector A
Connector B
Connector C
Process
Model
Artefact Manager
Tool
Repository
Tool Manager
control flow
data flow
General
Data
Repository
Tool
Traceability
Manager Tool
Other Data
Repository
Connector
JCR
Connector
Other Data
Repository
Trace
Repository
File System
Connector
File
System
Jackrabbit
Repository

Figure
2
-
3
:
Data management in the tool integration framework

2.2.2.1

General Data Repository

T
he

General Data Repository

tool provides four interface functions to download/upload some data from/to
the repository to/from a workspace file or a memory location (string variable), see
Figure
2
-
4
.

There are two requirements for a
specific repository connector in order to be
accessible

from the general
component
:



it has to implement this interface (
Figure
2
-
4
),



it has to
provide an extension

to the
hu.bme.mit.toolintegra
tion
.
repository
.
general
.datarepotool

extension point

(connecting specific repositories to the general component leverages the Eclipse
extension mechanism)
.

The general component can explore those repository connectors that
extend
this
extension point. The
extension point contains a single el
ement (
tool
) with two attributes (
id, schemaname
). The
id

attribute is the
SDE identifier of the tool (as used in the
SDE
Tool extension point), the
schemaname
defines the type of the
repository

(which is used in the address).

An example can be seen here:

<extension

point=
" hu.bme.mit.toolintegration.repository.general.datarepotool"
>


<tool



id=
"
hu.bme.mit.toolintegration.repository.jcr.IJCRRepositoryAccessTool
"



scheman
ame=
"
jcr
"
>


</tool>

</extension>



Figure
2
-
4
: Data repository interface

The
nodePath

parameters in the functions are URLs that uniquely identify the artefacts. These have the
following format:

URL = schemaname
://hostname:port_number/path

MOGENTES


Framework Implementation

-

Updated

Version


Page
12
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


The
hostname:port_number

identifies the host (local

or remote); this shall be the name of the
SDE
core. The
schemaname

identifies the repository on the given host (currently it is assumed, that multiple instances of a
given repository are not running on a single host). The
path

is the identifier of the art
efact within the given
repository.

2.2.2.2

JCR Repository

The JSR170 specification describes an object
-
oriented data repository system
(JCR


Java Content
Repository)
where data and metadata are stored in a tree containment hierarchy. Essentially, the JCR
reposito
ry can be thought of as a large XML DOM (Document Object Model), where each Node can have
different types (such as plain text nodes, binary (file) nodes, metadata nodes, etc). Nodes can have
attributes which are used to store content and metadata (such as
creation, modification time). The JSR170
standard specifies interface functions through which this DOM may be accessed and manipulated; Apache
Jackrabbit implements this standard with a variety of backends and options. In the current prototype, we use
the
embedded Derby

database
based backend (or, alternatively, the filesystem
-
based backend), and provide
a
n

SDE

tool interface to allow easy access
them
in the tool integration framework. Jackrabbit also provides a
web application (to allow for WebDAV and RMI
access), which is run in an embedded Apache Tomcat
container in the Tool Integration Framework.

2.2.2.3

File System Repository

The file system on a given host is the simplest repository where data can be stored. However, in case of
integrating tools in distributed

environment, it is of high importance to
make accessible all local file systems
of hosts, as lot of tools (e.g. UPPAAL, Argos, Ulysses) work on local files and produces outputs in the local
file system. To create toolchains from these tools if these are d
istributed to several hosts,

and to handle data
needed or provided by them, there are

two approaches possible: the data transfer can be either handled by
the tool connector; or moving files can be included in the workflow. In
the later case

it is

essential

to be able
to access these file systems just as any other data repository (but it is also helpful in the former case).

For this reason a specific data repository connector is provided within the framework for file systems.


2.2.3

Process Management

2.2.3.1

Process Mod
elling

A new, workflow independent
Process Editor

is developed as part of the framework. This editor is based on
a process metamodel (see
Appendix


Process Metamodel
), which is defined as a subset of UML activity
models. It contains those elements that are relevant from the tool integration aspect.

A
process

is composed of nodes, which can be service, data or control nodes. The
service node

represents
a service call; it can have
input

and
output

pins

(which are dat
a nodes) that represents the inputs and
outputs of the service. The
parameter node

is also a data node that represents the inputs and outputs of the
process.

Control nodes are the
initial

and
final
, the
fork

and
join

and the
decision

and
merge

nodes.
Contr
ol
flow

can be defined between service and control nodes, whereas
data flow

is defined between data and
control nodes.

The process metamodel is defined as an ECore model, thus a process model is an EMF model.

We call this
workflow independent process model

the
General Process Model.

The Process Editor is implemented using the Eclipse Graphical Modeling Framework
[GMF]

technology.

2.2.3.2

General Process Execution and Monitoring

The main parts of the process execution and monitoring are the follo
wing

(
Figure
2
-
5
)
:



The Process Execution User Interface is the workflow engine independent component which serves
as a general control and monitoring panel.

It is composed of the following subcomponents:

o

Process Repo Manager

It ma
intains a catalogue of the available
General Process Models
, the
Deployed Process
Models

that are deployed to a specific workflow engine and the
Deployed Process Instances

that are executed on the specific workflow engine.

o

Execution Manager

This component

is responsible for

MOGENTES


Framework Implementation

-

Updated

Version


Page
13
/
7
7


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc




adding new general process models to the process catalogue,



deploying these to workflow engine and remove deployed processes from there,



creating instances of deployed process models on a workflow engine,



setting parameters of a proces
s instance,



starting the execution of a process instance.

o

Execution Monitor

The execution monitor listens for notification events sent from the workflow engine and
updates the status of the process instance on the graphical user interface.



The Process Exe
cution Engine is the collection of the workflow engine related components. It is
composed of the following subcomponents:

o

Workflow Engine

This is an Off
-
The
-
Shelf component that can execute a process
described by a
Specific
Process Model

(this can be eithe
r engine dependent or some other format).

o

Connector for Workflow Engine

This connector provides a uniform, predefined interface for the workflow engine providing
services for deployment of general process models, creation and execution of process
instances

and potential deletion of them. These services are invoked from the Execution
Manager.

o

SDE Action Handler for Workflow Engine

This component is called by the workflow engine when a given step in the process is
executed. Parameters for the action handler c
ontain information about the service to be
invoked, and the referenced SDE service is executed through the SDE Tool Manager. This
component sends notification events for the Execution Monitor indicating that the given step
is being executed.

o

Process Model
Transformation

This generates the workflow engine specific process model from the general one.

o

Connector of Deployed Process Repository

This component provides information about the deployed and instantiated processes

for the
Process Repo Manager.


Process Execution Engine
SDE Tool Manager
Workflow Engine
Connector for
Workflow Engine
Process Editor
General
Process
Repository
Tool A
SDE Connector A
General
Process
Model
control flow
data flow
Tool B
SDE Connector B
Process Execution User Interface
Specific
Process
Model
Transf
.
SDE Action Handler for Workflow Engine
Execution Manager
Deployed
Process
Repository
Process Repo
Manager
Execution Monitor
Connector for Deployed
Process Repo
Process
Visualizer

Figure
2
-
5
:
Detailed Architecture of the Process Management components


MOGENTES


Framework Implementation

-

Updated

Version


Page
14
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


2.2.3.3

The

integrated

jBPM
Workflow Engine

The jBPM workflow engine
[jBPM]

is integrated into the P
rocess Execution Engine component (
Figure
2
-
2
).


The four engine specific components are implemented for it:



The connector for the deployment, deletion and instantiation of processes and for the
parameterization, execution and de
letion of process instances.



The connector for providing information about the processes and their instances that are persisted in
the jBPM workflow repository.



The transformation from the general process model to a jPDL model. This is realized by a VIATR
A
model transformation.



The SDE Action Handler, which is referenced in the generated jPDL model and called by the jBPM
engine when the given step is executed. It calls the referenced SDE tool with the given parameters
(which are stored in process variables
) and notifies the Execution Monitor about the status of the
execution by sending it an appropriate OSGi event.


2.2.4

Remote execution support

The tool integration framework is capable of orchestrating and executing tool integration workflows across a
distribut
ed network infrastructure. For this purpose, we use the remote tool invocation support of the SDE,
which enables the invocation of tool functions through a remote procedure call protocol called Remote
-
OSGi.


An example deployment of the UPPAAL based TCG pr
ocess (for details see Section
4.2
) is depicted in
Error! Reference source not found.
. Let’s assume that the services are separated into three tools:

a
transformation tool with two transformations (UML
-
to
-
SMTE, SMTE
-
to
-
UPPAAL), a UPPAAL

based tool
generating trace
s

from a model
using
test goal
s
, and a converter tool producing ATC
s from UPPAAL

trace
s

using the UML
-
UPPAAL mapping information.
Furthermore l
et's assume that
we want to store

models in a

repository deployed on
Host A

(the UML
model is located
here,
and
we want t
o
upload
the intermediate
models and results

here
), and has a test server (
Host B
) with a Jackrabbit JCR based test repository on it (to
where the AT
C shall be uploaded). To use the

framework, we need a process server (t
he jBPM workflow
engine), which is worth to be deployed in a separate machine (
Host C
).
As the
transformation and the
converter tools
are quite lightweight tools, we deploy these
also to
Host C
, but the UPPAAL model checker is
deployed to a separate, stron
g machine (
Host D
) as in case of large models it needs
a lot of
resources.

To allow the process server to access the tools and data repositories, the
SDE Tool Manager

component
shall be deployed to all hosts with the appropriate tool or repository connecto
rs. In addition, the
General Data
Repository Component

shall be deployed to the host where the process execution engine is located
(
Host

C
), and the
File System Connector

to the hosts where tools operating on local files are deployed
(
Host

C, D
).

The deplo
yment of the TCG process to the process server and the execution of it can be initiated from a
separate Desktop, where the Process Execution User Interface is available. When starting the process the
workflow engine executes automatically the following step
s (which are defined by the process model):



Downloads the UML model from the Model Repository (MR) to the local file system on Host C
(LFS
_
C).



Invokes the Transformation tool, which transforms the UML model to SMTE then to UPPAAL model,
and pro
duces the mapp
ing file (on LFS_C
).



Uploads these intermediate files to the Model Repository.



Downloads the recently uploaded UPPAAL model from MR to the local file system on Host D
(LFS
_
D).



Invokes the UPPAAL t
ool on Host D, which produces
trace
s

on LFS
_
D.



Uploads the trac
e
s

to the Model Repository.



Downloads the recentl
y uploaded traces from MR to LFS_
C.



Invokes the Converter tool on Host C
, which produces the ATCs on LFS_
C.



Uploads the ATC
s

to the Test Repository.

During the execution the status is updated on the

user interface on the Desktop. At the end all related
information is stored in one of the repositories in a traceable manner.

MOGENTES


Framework Implementation

-

Updated

Version


Page
15
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


Host D
(
Model checking
)
SDE Tool Manager
UPPAAL
UPPAAL
Connector
File
System
Connector
Local File
System
Host A
(
Model
management
)
SDE Tool Manager
SVN
Connector
Subversion
Model
Repository
(
SVN
)
Host B
(
Test management
)
SDE Tool Manager
Some other
(
test
)
tool
JCR
Connector
Java Content
Repository
(
Jackrabbit
)
Test
Repository
(
Derby
)
Desktop
SDE Tool Manager
Process Execution
User Interface
Host C
(
Process management
+
lightweight tools
)
SDE Tool Manager
Transfor
-
mation tool
Converter
Converter
Connector
Transformation
Connector
jBPM
Connector
jBPM
workflow
engine
Process
Repository
(
MySQL
)
action
handlers
File
System
Connector
Local File
System
General
Artefact
Manager
Comp
.

Figure
2
-
6
: An example

deployment of

potential
f
ramework components
in a

distributed
environment



2.3

Installation of the Components

In this section we give an overview about the steps that
are

needed for the installation of the General Tool
Integration Framework.

The framework is implemented as a set of
Eclipse plugins, thus first an Eclipse instance shall be downloaded
(
http://eclipse.org/downloads/
)


the release
Eclipse Classic 3.6

is sufficient, but others can also be used.
The Process Editor and the Proc
ess Execution User Interface needs at least version 3.5, however for tools
that processes UML model, the version from 2008, i.e., 3.4 is needed.

The old version of the Process
Execution User Interface works with Eclipse 3.4; this can also be installed from

the update site.


Step A: Installing the

Service

Development Environment (SDE)

The core component of the framework is the
Service
Development Environment, which was developed in the
SENSORIA project

[Sensoria]
.
In this section onl
y

t
he installation procedure of it is outlined; for a detailed
description, see its own tutorial

(
http://svn.pst.ifi.lmu.de/trac/sde
)
[SDETUT]
.

Prerequisites



Java JDK 1.6 (Sun, Open
JDK tested and supported.)



Eclipse version 3.4.X



OS: Windows, Linux are tested and supported.

Installing via update site

The Eclipse update site for the SDE is:
http://svn.pst.ifi.lmu.de/update/sde/


T
his update site contains
multiple

features: the core

and the
development tools are needed.

To install these features into your Eclipse installation, follow these steps:

MOGENTES


Framework Implementation

-

Updated

Version


Page
16
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


1.

From the Help menu, select
Install New
Software

2.

Click Add
…, and enter the update site
URL,
and a name;
select OK

3.

In the feature selection dialog, select the
SDE Core

and
SDE Dev

features

4.

Select Install…, Next, Next, Finish.

5.

Restart Eclipse to activate the newly installed features.

a.

The following perspective shall be available:

i.

SDE

b.

The follow
ing views shall be available:

i.

SDE

/

SDE
Browser


ii.

SDE
/
SDE
Shell

iii.

SDE
/
SDE

Blackboard

c.

The base tools are available

in the
SDE

Browser

view:

i.

Remote Service
/

Remote service server

ii.

SDE

/

*


Step
B
:
Prepare the workflow execution environment


B.1 Install the
jBPM engine

1.

Run the installer
jbpm
-
installer
-
3.3.1.GA.jar

It can be downloaded from
http://sourceforge.net/projects/jbpm/files/

or from the MOGENTES web
folder
/WP2
-

Framework/FrameworkComponent
s/jbpm_install/



B.2

Set up MySQL for the JBoss jBPM engine

1.

Install the MySQL database (version 5.x tested and recommended).

See
http://dev.mysql.com/downloads/mysql/5.1.html

for details and
help.

2.

The tool integration framework currently assumes that the MySQL server can be located on
localhost, under port 3306, with the default user and password of
root/root
.

3.

Create a schema called
jbpm

and allow the root user to access it with full control.


B.
3
a Install the new workflow component of the Tool Integration Framework

This is for 3.5 or newer version of Eclipse.

1.

Install feature from the update site
http://toolintegration.inf.mit.bme
.hu/pmupdate/
:



Process Manager

2.

Restart Eclipse.

a.

The following perspective shall be available:



Process Manager



ProcessModel Diagram

b.

The following views shall be available:



Process Manager

/

Processes




Process Manager

/

Process graph




Process Manager

/

PM E
vents

c.

The following tools shall be available

in the
SDE

Browser

view:



Workflow management / jBPM
E
xecutor
T
ool


MOGENTES


Framework Implementation

-

Updated

Version


Page
17
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc



B.
3
b Install the old workflow component of the Tool Integration Framework

This is for Eclipse version 3.4.

1.

Install feature from the update site

http://toolintegration.inf.mit.bme.hu/update/
:



Tool Integration Framework


Workflow Component

2.

Restart Eclipse.

a.

The following perspective shall be available:



Sensoria Workflow

b.

The following v
iews shall be available:



Sensoria
/

Processes




Sensoria / Workflow View

c.

The following tools shall be available

in the
SDE

Browser

view:



Workflow management / jBPM
E
xecutor
T
ool



B.
4

Configure the jBPM database

In
Eclipse
the
createSchema
function
of the
S
DE tool
"jBPM Executor Tool"

shall be invoked once
.


Step C: Install the repository component


C.1 Install the general repository

1.

Install feature from the update site
http://toolintegration.inf.
mit.bme.hu/update/
:



Tool Integration Framework


General Repository

Component

It contains an extendable repository manager component and the extension for handling
local file systems.

2.

Restart Eclipse.

a.

The following tools shall be available

in the
SDE

Brow
ser

view:



Artefact

management /
General Data Repository



Artefact

management /
File System Repository Access


C.2 Install the Jackrabbit repository

1.

Unzip the Jackrabbit database to C:
\
jackrabbitrepository

The database is in the MOGENTES web folder:

/
WP2

-

Framework/FrameworkComponents/jackrabbitrepository.zip

2.

Install feature from the update site
http://toolintegration.inf.mit.bme.hu/update/
:



Tool Integration Framework


JCR Repository

Component

It contains the extension to the general repository component for handling JCR repositories.

3.

Restart Eclipse.

a.

The following views shall be available:



JCR

/

JCR Repository Browser


b.

The following tools shall be available

in the
SDE

Browser

view:



Artefact

man
agement /
JCR Repository Access


c.

The repository shall be available also as a webfolder using the address
http://localhost:8080/jackrabbit/repository/default/

with empty username/password
.


MOGENTES


Framework Implementation

-

Updated

Version


Page
18
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


Step D
: Install

the traceability component

1.

Install feature from the update site
http://toolintegration.inf.mit.bme.hu/update/
:



Tool Integration Framework


Traceability

Component

2.

Restart Ecl
ipse.

a.

The tool
Traceability

/
TraceabilityController

in the
SDE

Browser

view shall be available.

b.

The traceability repository is stored locally in the

/EMFTraceInfoRepo/TraceInfoRepo.tracerepo

file.

This is created (if it does not exist) when traceability i
nformation is added.


2.4

User’s Guide

In this section, we discuss those use cases in detail that are related to our additions to the
Service

Development Environment

(SDE)
. For a general user’s guide

about the base features of the SDE
, please
refer to Section
3 of
the

SDE Tutorial

[SDETUT]
. The following subsections describe important features:



Subsections 3.1
-
3.3 discuss the purpose, basic functionality and UI components of the system.
These subsections are highly recomme
nded to read.



Subsection 3.4 discusses tool orchestration, a feature that allows the composition of tool invocation
processes with Javascript. This feature is replaced by process modelling in the MOGENTES Tool
Integration Framework, so this subsection is o
ptional.



Subsection 3.5 discusses tool
-
specific Eclipse user interface extensions, which is an optional feature
and not related to the tool integration framework itself.

The following descriptions lead the user through the process of designing, deploying,
executing a tool
integration process, and also describe how the artefact management component can be used.


2.4.1

User interface basics

In order to use the tool integration framework, it is recommended to switch to the
SDE

perspective in Eclipse
(from the Window

menu, select Open perspective, Other…, and then browse for
SDE
). The most important
component is the
SDE

Browser view (
F
igure
2
-
7
). It shows the Tool Repository, i.e. the collection of tools
currently available in the system.


F
igure
2
-
7
:

The
SDE

tool browser

Double clicking on a tool opens the invocation interface (
Figure
2
-
8
). From this page, a tool function may be
selected for invocation, and a basic set
tings dialog

opens

for
providing
parameters
.

MOGENTES


Framework Implementation

-

Updated

Version


Page
19
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc



Figure
2
-
8
:

The
SDE

Tool invocation interface

2.4.2

Designing tool integration processes

A new General Process Model can be created by invoking the wizard

New... / Exa
mples/ProcessModel
Diagram
. This creates a
.processmodel

and a
.processmodel_diagram
file. The first contains the process
model itself, while the second contains the related graphical information. When opening a
.processmodel_diagram

file, the process mode
l is opened in the graphical Process Editor (
Figure
2
-
9
).

The Palette on the right side contains the general elements that compose the process model and the tools
with their services imported from the SDE Tool Manager. When an SDE

service is added, a service node is
created with correct parameters and with input and output pins.

The perspective
Processmodel Diagram

contains the views needed for editing a process model.

MOGENTES


Framework Implementation

-

Updated

Version


Page
20
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc



Figure
2
-
9
:
The graphical Process Editor

2.4.3

Managing P
rocess

Executions

There are two ways to deploy a process model to the jBPM workflow engine, create an instance and execute
it: it could be described in an SDE script or it can be managed step
-
by
-
step from the P
rocess Execution User
Interface. The new version of the user interface is based on the graphical representation of the general
process model (as it is created in the Process Editor), can work with local or remote workflow engines, but
works only with Eclip
se version 3.5 or later. The old version of the user interface

which works with Ecipse
3.4


is also available;
but the process representation of it is based on jPDL process models with their
graphical (GPD) information, and this works only with local jBPM

workflow engine.

In the subsections these three approaches are described.

General Process
Model

Properties

Elements of
processes

SDE
Tools and their
services

MOGENTES


Framework Implementation

-

Updated

Version


Page
21
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


2.4.3.1

SDE Script Based Execution

The SDE scripts
[SDETUT]

can be used to
create a new instance of a deployed process, set its parameters
and execute it. The main ad
vantage of it is that it can be easily re
-
executed with given parameter set without
clicking and typing on the interface (it is especially useful when there are a lot of process parameters). The
disadvantage is that it needs more background knowledge about

the process and the execution could not be
monitored.

SDE scripts shall be saved in a file with extension .
sscript
.

I
n the Eclipse workspace select
Run as|Sensoria
Shell Script NB

from the context me
nu

of the file
. This will execute the script in the non
-
blocking mode on a
background thread, which allows the user to continue working with Eclipse while the tool integration process
is executing (this is required for processes which invoke tools with user interaction).

After refreshing the
Process Execution U
ser Interface, the status of the newly created process instance can be monitored.

The SDE script shall contain the following steps:



get the jBPM tool,



create new instance of an already deployed process (name, id, version of process shall be known),



create
a map containing parameter values assigned to parameter names defined by the process,



execute the new instance with the given parameter set.

This is illustrated in the following list, while a complete script for executing the AS based TCG process is
includ
ed in the Appendix.

processInstanceName =
"..."
;

processName = "ASBasedTCG";

processDefID = "10";

processVersion = "7";


jbpm = sCore.

findToolById("hu.bme.mit.toolintegration.workflow.jbpm.IJbpmExecutorTool").getServiceInterface();


processID = jbpm.creat
eNewProcessInstance(processName, processDefID, processInstanceName);


param1Value = "..."
;

param2Value = "..."
;


params = jbpm.addParameterToMap(null, "
Param1Name
",
Param1Value
);

params = jbpm.addParameterToMap(params, "

Param2Name
",
Param2
Valu
e
);


jbpm.ex
ecuteProcessInstance(processID,params);


2.4.3.2

Process Execution User Interface

The Process Execution User Interface contains the following views

(
Figure
2
-
10
)
:



Processes


This view contains the elements of the process catalogue (reposi
tory): the uploaded General
Process Models, the Deployed Process Models that are deployed to a specific workflow engine
and the process instances created from these. This view contains also a toolbar for the related
operations (adding, deploying, creating
, deleting, refreshing, ...).



Process graph


This view shows the graphical representation of the process that is selected in the
Processes

view. In case of process instances the parameters can be edited, the execution can be started
and the status can be m
onitored (the active nodes are
highlighted
).



P
roperties


This contains information about the nodes selected in the
Process graph

view.



PM Events


It contains some diagnostic messages that are related to the
Process Manager

(it is a filtered log
view)
.


The

usual workflow performed on the Process Execution User Interface is the following:

1.

Add General Process Model (.
processmodel_diagram
) to the process catalogue.

MOGENTES


Framework Implementation

-

Updated

Version


Page
22
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


2.

Deploy this to a workflow engine (to jBPM).

3.

Create a process instance.

4.

Add parameters of the pro
cess (if there are any and if we want to change the default values).

5.

Execution of the process instance and monitoring of its status.



Figure
2
-
10
:
Process Manager


2.4.3.3

Process Execution User Interf
ace in Eclipse 3.4

T
he

first version of the

Process Execution User Interface

works well also in Eclipse 3.4
.

The process
definition archive file, that could be deployed on this interface can be generated from General Process
Models created with the Process

Editor: the context menu of
.processmodel

files contains a menu item
(
Generate jPDL Code OLD
) which generates the needed process archive file.

This version of the user interface

is composed of
the following

dependent views:



The
Processes

view
(
Fig
ure
2
-
11
)
is an outline: it contains the process definitions deployed to the
process database and the process instances of it. These are represented in a two
-
level tree:
definitions are listed on the first level and their instances are be
low them.

The deployment of new
Process model

Properties

Catalogue of
General and
Deployed
Process Models
with their
Instance
s

Events

1.

Add General
Process Model

2. Deploy Process Model

3. Create process
instance

5. Start process
instance

4. Edit parameters of the
process instance

MOGENTES


Framework Implementation

-

Updated

Version


Page
23
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


process definitions and the creation of new process instances of the selected process definition can
be performed by the buttons on the top of the view.



The
Workflow

view (
Figure
2
-
12
) shows the gra
phical representation of the process definition or
instance that is selected in the
Processes

view. The representation contains control and data nodes
with control and data flow edges. If a process instance is shown, then
it can be started with the
Start

b
utton at the top, and the actual state of execution is shown by highlighting the active node.



Additional information can be found in the standard
Properties

view about the selected node of the
process (e.g. status, starting date, ending date).




Fig
ure
2
-
11
:
Processes

view of the
Process Execution User Interface

in Eclipse 3.4



Figure
2
-
12
:
Workflow view

of the
Process Execution User Interface

in E
clipse 3.4

2.4.4

Artefact
M
anagement

Artefact management is facilitated through the JCR Repository Access tool, available in the
SDE

browser
under the Artefact management category.
It
provides basic functionality to manipulate and access data:



The functions writ
eNodeToWorkspaceFile and uploadWorkspaceFileToNode are used to
down/upload data from/to the Eclipse workspace to the repository.



The getNodeContents and setNodeContents functions can be used to manipulate data directly.

Deploy process
definition

Create new
process instance
of the selected
definiti
on


P
rocess
definition

P
rocess
instance

Starts the
execution of the
proces instance

Control node
under execution

Control node

Data node

Data flow

Control flow

MOGENTES


Framework Implementation

-

Updated

Version


Page
24
/
77


Version
:


1.
1





Status:



rangaleclick_40bf7bd4
-
1c2b
-
4a98
-
b745
-
1476eeacac25.doc


All functions use String path parame
ters to refer to JCR nodes, which contain data and metadata. These
JCR paths use forward slashes to denominate hierarchy levels.

The JCR hierarchy is visualized in the JCR Repository Browser view (
Figure
2
-
13
).


Figure
2
-
13
:

The JCR Repository Browser user interface

This view component is best used
with
the standard Eclipse Properties view open, to show values of
attribute type nodes.

The following
functions can be used in this view:



The Refresh button is used to refresh the contents of the view (typically needed after a repository
manipulation operation has been completed).



If you right click on a file node, you can save the contents of the file to the workspace.

An alternative metho
d of viewing and manipulating the data repository is mounting it as a WebDAV resource.
In Windows, this may be done by:



Open My Network Places, select Add Network Place, Next



Enter
http:/
/localhost:8080/jackrabbit/repository/default/

as the location



When asked for creditentials, use the
empty
login name and

password.

This way, you can use Windows Explorer to visualize the contents of the repository, open files directly,
or
create and
dele
te files and directories.


2.5

Integration of Tools to the Framework

The
SDE

Development Environment Tutorial

[SDETUT]

provides detailed instructions on how to create a tool
connector. Section 4 (Developers Guide) provide
s a walkthrough description of the integration process
(Subsection 4.2). In this document, we focus on the extensions added to the MOGENTES Tool Integration
F
ramework, which aid the developer in taking advantage of the
a
rtefact management system.


2.5.1

Creating

a tool connector: Overview

In the following description, we refer the reader to the appropriate subsection of the SDE Tutorial for each of
the steps for the detailed description.

It is important to note that any tool (regardless of being implemented in Ja
va, C++, etc) can be integrated to