FOLYAMATLEIRO NYELV KIVALASZTASA

spinabundantInternet and Web Development

Jul 30, 2012 (5 years and 3 months ago)

613 views









F
OLYAMATLEÍRÓ NYELV K
IVÁLASZTÁSA

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



2
/
31

A dokumentum az Új Magyarország Fejlesztési Terv keretében, az Államreform
Operatív Program támogatásával, az „Elektronikus közigazgatási keretrendszer”
tárgyú kiemelt projekt megvalósításának részeként

készült.
A dokumentum
elkészítésében részt vett:

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



3
/
31

Metaadat
-
táblázat

Megnevezés

Leírás

Cím (dc:Title)

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA

Kulcsszó

(dc:Subject)

Folyamatleírás; folyamatleíró nyelv; útmutató

Leírás (dc:Description)

A
dokumentum a folyamatleíró módszertan kidolgozását segítendő
meghatározza azokat a követelményeket, melyeket a leíró nyelvvel
szemben kell támasztanunk, majd javaslatot tesz az e
-
közigazgatási
keretrendszerben használandó leírónyelvre.

Típus (dc:Type)

Szö
veg

Forrás (dc:Source)


Kapcsolat (dc:Relation)

Folyamatleírást segítő gyakorlati útmutató

Folyamatleírást Segítő Módszertani Ajánlás


Terület (dc:Coverage)

KOP
-
ok során megvalósuló projektek, központi IT fejlesztési projektek

Létrehozó (dc:Creator)

BME IK

Kiadó (dc:Publisher)

MEH EKK

Résztvevő (dc:Contributor)


Jogok (dc:Rights)

e
-
Közigazgatási Keretrendszer

Dátum (dc:Date)

2008.07.29.

Formátum (dc:Format)

Microsoft Word .doc, elektronikus adathordozón

Azonosító (dc:Identifier)


Nyelv
(dc:Language)

Magyar

Verzió (dc:Version)

V2

Státusz (State)

végleges

Fájlnév (FileName)

EKK_ekozig_folyamatleiro_kivalasztasa_080729_V2.doc
.

Méret (Size)

30

oldal

Ár (Price)

-

Felhasználási jogok (UserRights)

-

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



4
/
31

Verzió

vetési táblázat

A dokumentum neve

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA

A dokumentum készítőjének neve

Szeberényi
Imre

A dokumentum jóváhagyójának neve


A dokumentum készítésének dátuma

2008.07.29.

Verziószám

V2

Összes oldalszám

30

A pro
jekt azonosítója

e
-
Közigazgatási Keretrendszer

projekt


Változáskezelés

Verzió

Dátum

A változás leírása

V1.0

2008.05.20

First draft

V1.1

2008.05.29

Munkaanyagként átadott

V1.2

2008.06.10

Bővítések

V1.3

2008.07.27

Szerkezeti változtatások,
kiegészítések

V1.4

2008.07.2
8

Javítások

V2

2008.07.2
9

A MeH
-
nek átadott verzió


FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



5
/
31


Tartalomjegyzék


1.

Előszó

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

6

2.

Bevezetés

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

6

2.1.

A

DOKUMENTUM CÉLJA

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

7

2.2.

A

DOKUMENTUM FELÉPÍTÉS
E

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

7

3.

Követelmények

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

8

4.

Webszolgáltatások

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

8

5.

Folyamatok ábrázolása, folyamatleíró nyelvek

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

9

5.3.

UML

(U
NIFIED
M
ODELLING
L
ANGUAGE
)

TEVÉKENYSÉGDIAGRAMOK

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

10

5.4.

EPC

(E
VENT
D
RIVEN
P
ROCESS
C
HAI
N
)

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

11

5.5.

YAWL

(Y
ET
A
NOTHER
W
ORKFLOW
L
ANGUAGE
)

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

11

5.6.

BPMN

(B
USINESS

P
ROCESS
M
ODELING
N
OTATION
)

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

12

5.6.1.

BPD (Business Process Diagram)

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

12

5.7.

XPDL

(XML

P
ROCESS
D
EFINITION
L
ANGUAGE
)

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

12

5.8.

BPEL

(B
USINESS
P
ROCESS
E
CEXUTION
L
ANGUAGE
)

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

12

6.

BPMN

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

13

6.1.

E
GYSZERŰ
BPMN

ELEMEK

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

13

6.2.

BPMN

FOLYAMAT TERMÉKEI

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

14

6.3.

BPMN

KIBŐVÍTETT ELEMEI

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

15

6.4.

BPMN
-
T JELENLEG TÁMOGATÓ
ESZKÖZÖK LISTÁJA

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

16

6.5.

BPMN

TÁMOGATÁST TERVEZŐ C
ÉGEK ÉS ESZKÖZEIK

LISTÁJA

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

17

6.6.

BPMN
-
T TÁMOGATÓ NEMZETKÖZ
I SZOLGÁLTATÓ CÉGEK
................................
................................
..

17

7.

BP
EL

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

18

7.7.

T
ÖRTÉNETI ÁTTEKINTÉS

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

18

7.8.

BPEL

JELLEMZŐI

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

19

7.9.

BPEL

FOLYAMAT KOMPONENSEI

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

19

7.10.

E
GYSZERŰ TEVÉKENYSÉGE
K NY
ELVI ELEMEI

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

20

7.11.

K
OMPLEX TEVÉKENYSÉGEK

NYELVI ELEMEI

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

25

8.

Követe
lményeknek való megfelelés

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

28

9.

Összefoglalás, javaslat

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

29

10.

Irodalomjegyzék

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

30


FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



6
/
31


1.

Előszó

Jel
en dokumentum az e
-
közigazgatási k
eretrendszer részét képezi.

A dokumentum az e
-
közigazgatási keretrendszerbe integrált,
informatikával
támogatott
(munka)
folyamatok leírónyelvének kiválasztására tesz javaslatot.

A dokumentumban folyamatra mindig munkafolyamat (workflow) értelemben gondolunk.
B
ár az üzleti életben ezt gyakran határozottan megkülönböztetik, mi a folyamatot és
a
munkafolyamatot
szinonimaként

kezeljük.

2.

Bevezetés

A közigazgatás meglévő ügyintézési folyamatainak elektronizálása nem jelenti automatikusan
sem a közigazgatás belső hatékonyságának, sem az ügyfelek elégedettségének növekedését.
Az elektronikus közigazga
tás kiépítésének, amely mind az EU, mind a hazai fejlesztési
stratégiák egyik kiemelt prioritása, az állampolgárok és a vállalkozások ig
ényei alapján kell
megtörténnie
annak érdekében, hogy megvalósuljon a politika által megfogalmazott
szolgáltató állam
-
mo
dell, illetve, hogy megtakarításokat lehessen elérni a folyamatok
egyszerűsítése által.

Az ügyfélorientált szolgáltató állam kialakításához
,

az ügyfelek jobb kiszolgálásához
,

a
folyamatok elektronizáltságához, az ügyfél oldali ügyintézés egyszerűsítéséhez,

a
háttérintézmények interoperabilis működése szükséges.

A közigazgatás ügyfelei problémákat oldanak meg. A problémák minden állampolgár és
vállalkozás részére egyedi formában jelentkeznek. A problémák megoldása során „jönnek
létre” az ügyek
,

mint a problé
ma megoldás eszközei. A problémák, az ügyektől eltérőe
n

a
legtöbb esetben nem sorolhatók be valamely ágazati intézmény hatáskörébe. A modern
közigazgatás egyik jellemzője, hogy az ügyintézés folyamatai nem
intézmény
i
alapon

szerveződnek, hanem élethelyzet
-

és
problémaalapon
. Az új ügyintézési folyamatok
kialakításához egyrészt előtérbe kell helyezni a felhasználói érdekeket, másrészt biztosítani
kell, hogy az egyes folyamatok összehangoltan működjenek, az ügyfél igényeihez igazodva
kikerüljenek az ágazati i
ntézményi keretek közül. A rendszeren belüli valódi hatékonyság
megteremtése intézményi érdekeken és működési körön túlnyúló, horizontális megközelítést
igényel.

Az ügyfelek részéről várhatóan akkor érhető el jelentős előrelépés az elektronikus
szolgáltatá
sok használatában, ha azok a hagyományos ügyintézésekkel összehasonlítva
kényelmesebbé, gyorsabbá, egyszerűbbé teszik számukra ügyeik intézését.

A fenti célok eléréséhez kíván az e
-
közigazgatási keretrendszer kialakítása projekt segítséget,
megfelelő eszkö
zöket és módszereket kínálni. A projekt alapvető feltevése, hogy a
közigazgatási folyamatok és eljárások kezelése az üzlet
i

és

az ipari folyamatok kezelése
során

felmerülő problémákhoz hasonló problémákat vet fel.

Annak ellenére, hogy a közigazgatási
eljárások és belső folyamatok számos, az üzleti világtól
jelentősen eltérő jellemzővel rendelkeznek, legalább annyi hasonlóságot is mutatnak. Ezért a
projekt megvalósítói egy olyan előremutató megoldást keresnek, mely kellőképpen rugalmas
és időtálló. Ezt
jelenlegi ismere
teink szerint leginkább a
szerviz

orientált architektúra és
FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



7
/
31

tervezési mó
dszertan tudja biztosítani.
Ezek a

megoldások az üzleti szférában 2000 óta
növekvő szerepet töltenek be, és egyre több olyan nemzetközi és már hazai példa is áll a
rend
elkezésünkre, melyben igazgatási, kormányzati, önkormányzati feladatok megoldására
használják, illetve tervezik használni.

Az e
-
közigazgatási keretrendszer kialakítása projekt keretében a közigazgatási folyamato
k
leírására egységes formátumot

és módszertan
t dolgozunk ki. Az egységes formalizmusokon
alapuló leírás többek között lehetővé teszi az automatikus kódgenerálást, a számítógéppel
segített konzisztencia ellenőrzést, valamint a közös részfolyamatok kiválasztását. Ezért a leíró
módszer és eszközrendszer

kiválasztása különösen fontos feladat.

2.1.

A dokumentum célja

Jelen dokumentum a folyamatleíró módszertan kidolgozását segítendő meghatározza azokat a
követelményeket, melyeket a leíró nyelvvel szemben kell támasztanunk, majd javaslatot tesz
az e
-
közigazgatás
i keretrendszerben használandó leírónyelvre.

A közigazgatási folyamatok átalakítása e
-
közigazgatási folyamatokká a folyamatok leírásával,
kapcsolataik, érvényességi körük meghatározásával kezdődik. E
zt a
feladatot

közigazgatási
sza
kemberek és informatikuso
k közösen végzik. Ennek er
e
dményeként előáll egy
szöveges/táblázatos és nagyvonalú grafikus leírás.

Ezt követően ezt pontosít
an
i, formalizálni kell. A formalizált leírásnak több
,

esetleg
ellentmondó szempontot kell kielégítenie. A dokumentum a célok megha
tározása után
javaslatot tesz ko
nkrét leírónyelv(ek)re.

2.2.

A dokumentum felépítése

Az 1. fejezet

elhelyezi a dokumentumot az e
-
közigazgatási keretrendszeren belül

tájékoztatást
adva a célközönségről és a kapcsolódó dokumentumokról.

A 2. fejezet bevezető infor
mációkat tartalmaz, megadva a dokumentum célját és felépítését.

A 3. fejezet meghatározza a leírónyelvvel szemben támasztott követelményeket.

A 4.
fejezet néhány gondolat erejé
ig bemutatja a webszolgáltatások lényegét és megemlíti a
legfontosabb szabványok
at.

Az 5. fejezet rövid történeti áttekintés után
a

folyamatleírás és ábrázolás ismertebb eszközeit
veszi számba.

A 6. és a 7. fejezet

a BMPN és a BPEL leírás eszközkészletét

mutatja be
, mint az e
-
közigazgatási keretrendszerben javasolt eszközt.

A 8 fejezet
összeveti a bemutatott eszközök
et

és a követelményeket.

A 9 fejezet
javaslatot tesz a
z

e
-
közigazgatási keretrendszerben alkalmazandó folyamatleíró
nyelvre, és röviden vázolja annak alkalmazási módszerét.
Ennek

pontos részleteit a
folyamatleírás
t segítő módszertani ajánlásban és gyakorlati útmutatóban kell kidolgozni.

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



8
/
31

3.

Követelmények

Az e
-
közigazgatási keretrendszer kialakítása projekt keretében

a

kiválasztandó folyamatleíró
nyelvvel támasztott legfontosabb követelmény, hogy képes legyen megfelelni

az
interoperabilitási feltételeknek.

További fontos szempont a kezelhetőség és elsajátíthatóság, valamint a közigazgatási
környezetbe való illeszthetőség. Ezért a kiválasztásnál különös figyelmet kell fordítani arra,
hogy a

leírási módszer, illetve a leí

nyelv mennyire képes figyelembe venni az ügyintézések
jogszabályi előírásait, a meglévő ügyintézési folyamatokat, valamint az ügyfelek elvárásait,
képességeit és lehetőségeit. Az új, illetve megújított folyamatok kialakít
ásának célja egyrészt
az
ügyfélol
dal

igényeinek kielégítése, másrészt az ügyintézés hatékonyságának növelése,
felhasználva a folyamatok interoperabilitásának eszközét.

Az e
-
közigazgatási keretrendszer kialakítása projektben a közigazgatási folyamato
k leírására
egységes formátumot

és módsz
ertant kell kidolgo
z
ni elsődlegesen annak érdekében, hogy a
leírás alapján lehetővé váljon a folyamatok vezérlését, szervezését leíró technológiai nyelv
automatikus generálása.

Technológiai leírónyelv alatt olyan folyamatleíró nyelvet értünk,

melyet kü
lön
böző
folyamatvégrehajtó motorok közvetlenül fel tudnak használni az adott üzleti/közigazgatási
folyamat végrehajtására/végrehajtatására, szervezésére és vezérlésére.

Mindemellett más motivációk is megjelennek.

A leírónyelvvel kapcsolatban felmerülő elvárás
okat a következőkben foglaljuk össze:



de facto vagy de jure szabványokon alapuljon;



a szoftver fejlesztő eszközök szempontjából szóba jöhető gyártók által legyen
elfogadott és támogatott;



támogassa mind elemi, mind komplex folyamatok leírását;



támogassa a

leírt folyamatok közötti kapcsolatok kiépítését;



modellező és elemző eszközök
támogassák.

Annak érdekében, hogy jól szétválasztható legyen a technológiai leírás a modellezést,
tervezést,
konzisztencia
-
ellenőrzést

lehetővé tevő leírásoktól, úgy tűnik, hogy

legalább két
szintű megközelítés szükséges:

1.

A magasabb szintnek a
folyamatok felmérését, tervezését, igény esetén modellezését
kell

támogatnia. Jól kell illeszked
n
i
e az elsődleges folyamatleírás, felmérés
módszeréhez, és könnyen érthetőnek,
jól

használhat
ónak kell lennie mind
informatikus, mind közigazgatási szakember számára.

2.

Az alacsonyabb, technológiai szintű leírásnak a folyamatok végrehatását, szervezését
,

vezérlését kell támogatnia.

4.

Webszolgáltatások

A versenyképes termékek és szolgáltatások előfelté
tele a folyamatok pontos előírása és
hibátlan végrehajtása. A precíz folyamatspecifikáció elősegíti a költségcsökkentési
törekvéseket, valamint a változó piaci körülményekhez történő gyors alkalmazkodást.

A hagyományos integrációs megoldások gyártóspecifi
kusak, drágák
,

és „csak az integrációs
piac legfelsőbb szegmensének igényeit veszik figyelembe”. A J2EE
[3]

Connector
Architecture (JCA), a Java Messaging Service (JMS) és a RosettaNet
[4]

s
zabványokat ennek
FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



9
/
31

a kérdéskörnek a megoldására fejlesztették ki, azonban a folyamatok összehangolása továbbra
is megoldatlan maradt.

Az OASIS (Organization for the Advancement of Structured Information Standards)
konzorcium
[1]

által ajánlott üzleti folyamatok és webszolgáltatások összehangolására
szolgáló ipari szabvány lehetővé teszi az integrációs projektek felgyorsítását, csökkenti a
költségeket a meglevő folyamatok felügyeletével, m
ódosításával, kibővítésével és
korszerűsítésével kapcsolatban.

A webszolgáltatások olyan kompatibilitási szabványok (WSDL, XML és XML
-
séma, SOAP,
JMS, JCA stb.), amelyek az ügyfelekkel és partnerekkel leegyszerűsítik a heterogén
rendszerekkel történő inte
grációt.

A webszolgáltatások az internetet valódi elosztott számítógépes platformmá alakítják, ahol
egyszerűen és megbízhatóan együttműködhetnek a heterogén rendszerek. Az elosztott
rendszerek együttműködését ún. vezénylők (orchestrator) biztosítják. Ezek
vezénylik a
munkafolyamatok végrehatását. A munkafolyamat egy olyan tevékenységsorozat, mely a
megfelelő előfeltételek teljesülése esetén v
égrehajtandó lépésekből


ezek

további
részfolyamatokat is tartalmazhatnak


áll. Lehetnek benne elágazások, feltétel
ek,
jogosultságok az egyes lépésekhez, időzítés, más folyamatokra ill szolgáltatásokra történő
hivatkozás.

5.

Folyamatok ábrázolása, folyamatleíró nyelvek

Folyamatok, algoritmusok leírását a mérnöki/műszaki tudományok területén kezdték
formalizálni 1930 körül
. Az első ilyen formalizmus a folyamatábra volt, melynek különböző
változataival
ma is számos területen találkoz
unk. A korai programkészítés egyik eszközeként
Neumann János fejlesz
t
ette tovább a 40
-
es évek végén. Lényegében ezzel egyidőben kezdték
alkalmaz
ni az üzleti folyamatok leírására is, mivel a folyamatok szöveges leírásával
egyidejűleg történő grafikus ábrázolás segíti a folyamatok későbbi (elsősorban külső fél általi)
megértését. A grafikus ábrázolás amellett, hogy könnyebben és gyorsabban értelmezh
ető,
feldolgozhatóbb, mint egy többoldalas szöveg, információt sűrít
,

és jól alkalmazható az
elágazások, ciklusok, döntési pontok egyértelmű reprezentálására, javítja az információ
átláthatóságát.

Később a grafikus ábrázolás kiegészítő szöveges leírásokat
formális szabályoknak eleget

tevő
leíró
nyelvek váltottá
k fel mind a műszaki, mind az ü
zleti szférában,
amelyek már
nemcsak

leírásra, hanem modellezésre, ellenőrzésre is lehetőséget adnak. Az üzleti folyamatok
leírására
,

modellezésére
számos folyamatleírási
,

modellezési módszer és nyelv alakult ki.
Ezek közül a legismertebbek a következők:

1.

UML tevékenségdiagramok (Unified Modelling Language Activity Diagram)
,

2.

EPC (Event Driven Process Chain),

3.

YAWL (Yet Another Workflow Language),

4.

BPMN (Business Process Model
ing Notation) és

BPD (Business Process Diagram),

5.

XPDL

(
XML Process Definition
Language)
,

6.

BPEL
(Business Process Ecexution Language)
.

Ezen eszközök különböző szinten, de l
ehetőséget adnak a modellezésre

és szimulációra is. A
szoftverfejlesztésben legelterje
dtebben az UML különböző eszközeit használják, amivel
különböző szempontból írhatók le a folyamatok és azok kapcsolatai.

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



10
/
31

Az üzleti folyamatok leírására és modellezésére pedig a BPMN látszik legelterjedtebbnek.
Jelenleg mind az UML, mind a BPMN fejlesztését
, szabványosítását az
OMG (Object
Management Group) kezeli.

A következőkben röviden összefoglaljuk a fen
ti eszközök főbb tulajdonságait, majd a
következő fejezetekben
részletesebben is
bemutatjuk a BPMN és a BPEL eszközkészletét.

5.3.

UML (Unified Modelling Lan
guage
)
tevékenységdiagramok

Az UML fejlesztése a kilencvenes évek közepén kezdő

tt az objektum orientált modellezési
és szoftverfejlesztési technikák támogatására. A fő célok a következőkben foglalhatók össze:

1.

Olyan
grafikus modelle
zési eszköz létrehozása
, am
el
y közvetlenül felhasználható
szoftverfejlesztésben és a modellezésben.

2.

Könnyen bővíthető

és specializálható eszköz legyen.

3.

Programozási nyelvektől független legyen.

4.

Adjon alapokat a formális modellek megértéséhez.

5.

Segí
tse az objektum orientált
modellezés és tervezés elterjedését.

6.

Támogassa a magas
abb szintű minta
-
alapú tervezést és a keretre
ndszereket.

7.

Integrálja a legjobb gyakorlatnak megfelelő módszereket
.

Jelenleg 13 diagramtípust definiál az UML, melyek közül több is alkalmas folyamatok
leír
ására. Ilyenek például a szekvencia diagramok, tevékenységdiagramok, állapotgép
-
diagramok, együttműködési diagramok, kommunikációs diagramok és időzítés diagramok.
Ezek közül a tevékenységdiagram a legalkalmasabb a folyamatok leírására
,

és ezt is
használjá
k e célra a leggyakrabban.

Az UML tevékenységdiagram elemeinek összefoglalóját és szimbólumait az alábbi ábra
ismerteti (
1
. ábra
).



1
. ábra


Az UML tevékenységdiagramok elemei


A grafikusan áb
rázolt folyamatok leírásait a modellező eszközök leginkább XMI
formátumban tárolják.
Az XMI (ISO/IEC 19503:2005 Information technology
-

XML
Metadata Interchange) szabványt

szintén
az OMG fejlesztette ki metaadatok XML
-
es
leírására. Bármilyen metaadat leír
ására használható, amely MOF
-
ban (Meta
-
Object Facility)
kifejezhető. Jelenleg sajnos az UML modellező eszközök közötti XMI fájl alapú
hordozhatóság ritkán zökkenőmentes az inkompatibilis XMI formátumok miatt.


FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



11
/
31

5.4.

EPC

(Event Driven Process Chain)

Az EPC módsze
rt az ARIS projekt keretében fejlesztette ki Prof. Wilhelm
-
August Scheer a
Saarlandes Egyetemen a 90
-
es évek elején. Kezdetben elsősorban az SAP
-
nál

használták, de
mára számos cég használja modellezésre, elemzésre és üzleti folyamatok újratervezésére.

Az E
PC események és funkciók egy irányított gráfja. Többféle összekapcsoló elemet
tartalmaz, melyekkel leírhatók a folyamatok alternatív vagy párhuzamos végrehajtási útjai.
Ezekhez olyan logikai operátorokat használ, mint az OR, AND és a XOR. Az EPC egyik
legn
agyobb erőssége az érthetősége és egyszerűsége. Sajnos sem a szintaktikája se
m

a
szemantikája nem jól definiált.

Az EPC elemei a következők: event, function, process interface, connectors (AND, OR,
XOR), control flow arc, participant (pl. szervezeti egység
), application, data (information,
material, resource object), relation. Az EPC diagram elemeinek összefoglalóját és
szimbólumait az alábbi ábra ismerteti (
2
. ábra
).


2
. ábra


az EPC diagram szimbólumai


Fonto
s megemlíteni, hogy az EPC mellé társul az EPML (EPC Markup Language), mely egy
szabványos, hordozható XML
-
alapú formátum. Számos modellezési eszköz képes EPML
leírást importálni vagy exportálni.
[22]

5.5.

YAWL

(Yet Another Workflow
Language)

Amint a neve is mutatja
,

egy újabb folyamatleíró nyelvr
ő
l van szó
(
Yet Another Workflow
Language)

[16]
, a
mely k
ezdetben csupán a munkafolyamatokban előforduló tevéken
y
ségekre
koncen
t
rált, de mára már munkafolyamat leírás
á
nak

teljes eszköztárát támogatja a
folyamateditortól a fo
l
yamatmotoron át a modellező eszközig.

A nyelvet az ausz
t
ráliai Queensland University of Technology kutatói fejlesztették ki az
eindhoveni egyetemmel közösen végrehajtott munkafolyamat
-
mintákat vizsg
áló projekt
eredményei alapján. Ez a projekt feltérkép
e
zte az üzleti folyamatokban előforduló
munkafolyamat
-
mintákat
[17]

és az ehhez kapcsolódó adat és
e
rőforráskezelési módokat,
majd megvizsgálta, hogy mely nyelvek ill. fejlesztőeszközök támogatják ezeket.

A vizsgálat eredményeként jött létre a YAWL. A nyelv
és a hozzá kapcs
o
lódó eszközök
fejlesztése ma
egy nyí
lt nem profit orientált alapítvány keretében folyik. Az eredmények i
gen
í
géretesek. A különböző eszközök és dokumentációk GPL
szerződés
[
30]

elfogadása mellett
szabadon letölthet
ők.

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



12
/
31

Külön kiemelendő az a munka, amit
számos
üzleti és nem üzleti
termék tulajdonságának,
összehasonlításának terén végzett a
munkafolyamat
-
mintákat
vizsgáló csoport
[17]
. Kár, hogy
látszólag ez a munka 2007
-
ben lezárult.

5.6.

BPMN
(Bu
siness Process Modeling Notation)

A BPMN (Business Process Modeling Notation) egy szabványosított grafikus jelölési mód az
üzleti folyamatok munkafolyamatban való megjelenítésére. A

szabványt
jelenleg az OMG
(Object Management Group) kezeli
.

Fontos kiemeln
i, hogy a BPMN flowchart technikára épül, kidolgozásánál pedig számos
jelölésrendszert és módszert felhasználtak, így például az UML tevékenységdiagramot, UML
EDOC Business Process, IDEF, ebXML BPSS, Activity
-
Decision Flow (ADF) Diagram,
RosettaNet, LOVeM
és az EPC
-
t

[14]
.

5.6.1.

BPD

(Business Process Diagram)

A BPMN jelölésekkel BPD
-
ket (Business Process Diagram), készíthetünk. Egy BPD többféle
típusú lehet, köztük például



magas szintű üzleti,



részletes üzleti,



külső, nem ismert folyamato
kkal együttműködő,



két vagy több folyamat együttműködését, kollaborációját megjelenítő BPD.

A BPD
-
k különböző típusai egy ábrán is használhatók, mégis ha túl sok BPD típust
használunk egyszerre, akkor a diagram nehezen érthetővé válhat, így érdemes inkább
mindig
a BPD egy típusát használni (pl. egyéni folyamatábra vagy kollaborációs folyamatok).

5.7.

XPDL
(
XML Process Definition
Language)

A
z XPDL
[21]

(
XML Process Defini
tion
Language)

a WfMC (Wokflow Management
Coalition)
[29]

által szabványosított leírónyelv. Az XPDL egy olyan XML sémát definiál, ami
alkalmas a különböző leíró és

modellezési eszközök közötti információcserére. Fontos
kiemelni, hogy az XPDL a folyamat leírása mellett a folyamat végrehajtására is tartalmaz
információkat. Ezzel szemben a BPEL csak a végrehajtásra koncentrál.

A nyelv több elemet átvett a Petri hálók
elméletéből, de számos elem származik a BPMN
-
ből
is. A kilencvenes évek elején alapított WfMC
[28]
, mint nem profitorientált szervezet 1989
-
ban publikálta először a
z XPDL
-
t. Legutolsó 2.0
-
ás szabványváltozata 2005
-
ben került
elfogadásra.

Az XPDL formátumot számos termék támogatja, így számos editor, szimulátor, modellező
eszköz és felügyelő eszköz. Felhasználása azonban talán a korábban várttól lassabban terjed.

5.8.

BPEL

(Business Process Ecexution Language)

A BPEL (Business Process Ecexution Language) olyan szabványos leírónyelv, amely segíti a
webszolgáltatásokra épülő folyamatok összehangolását és végrehajtását.
Elsősorban a
végrehajtást támogatja, ezért a
nyelv egy
egyszerűbb programozási nyelvhez hasonló
utasításk
észlettel rendelkezik. Az
XML

alapú folyamatleíró szabványt a
Microsoft

és az
IBM

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



13
/
31

definiálta és fejlesztette ki, a korábbi
BPML

(
Business Process Modeling Language

-

Üzleti
folyamatokat modellező nyelv) ala
pján.

Jellemző tulajdonságai:

1.

A modellezett folyamatok webszolgáltatásokon keresztül kommunikálnak a
külvilággal.

2.

A reprezentációs nyelv
XML
, de a

szabvány nem ad meg semmilyen konkrét gr
afikus
megjelenítési formátumot,
sem szabványos folyamat
-
tervezési módszertant.


3.

B
iztosít mind hierarchia
,
mind gr
áf alapú vezérlési struktúrákat.

4.

Feltételezi, hogy folyamat
modellek (de)kompozíciója
webszolgáltatás

alapon történik,
az elemi folyamatok ill. azok kompozíciói webszolgáltatásokat valósítanak meg.


A nyelvet részletesebben mutatja be a
7
. fejezet.

6.

BPMN

A BPMN (Business Process Mod
eling Notation) egy szabványosított grafikus jelölési mód az
üzleti folyamatok munkafolyamatban való megjelenítésére. A BPMN
-
t a BPMI (Business
Process Management Initiative) fejlesztette ki
,

és jelenleg az OMG (Object Management
Group) kezeli a két szerve
zet 2005
-
ös összeolvadása óta. A BPMN széles körben elterjedt
verz
i
ója az 1.1. A 2.0 verzió
,

végleges formája 2008 során fog megjelenni. A 2.0
-
s verzió
jelenleg RFP
-
ként (Request for Proposal) már elérhető.

A BPMI célja a BPMN
-
n
el egy minden érintett számá
ra érthető szabványos jelölési mód
kidolgozása volt. Ezek az érintettek lehetnek üzleti elemzők, akik létrehozzák és finomítják a
folyamatokat, fejlesztők, akik a folyamatok megvalósításáért felelnek
,

vagy menedzserek,
akik menedzselik és követik a folyama
tot. A BPMN tehát egy közös grafikus jelölési mód,
melynek célja, hogy kiküszöbölje a kommunikációs problémákat különböző hátterű érintett
felek között. Fontos kiemelni, hogy a BPMN flowchart technikára épül, kidolgozásánál pedig
számos jelölésrendszert és

módszert felhasználtak, így például az UML
tevékenységdiagramot, UML EDOC Business Process, IDEF, ebXML BPSS, Activity
-
Decision Flow (ADF) Diagram, RosettaNet, LOVeM és az EPC
-
t.

6.1.

Egyszerű BPMN elemek

Az alábbiakban bemutatjuk a BPMN alapvető elemeit. A kö
nnyebb érthetőség érdekében az
elemek megnevezését angolul és magyarul is feltüntettük.

1.

Flow objects (Folyamat objektumok):

A BPMN
-
nek három alapeleme van:

Event


esemény

o

Az eseményeket körrel jelöljük, és segítségével jelezhetjük, hogy valami
„történik”

az üzleti folyamat során. Az események a folyamat működését
befolyásolják, így egy eseménynek jellemzően van oka és hatása. Háromféle
eseménytípust különböztetünk meg, attól függően, hogy hogyan befolyásolja
az üzleti folyamatot:



Start (indító),



Intermediate (köztes),



End (záró) esemény.


FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



14
/
31


3
. ábra Indító, köztes és záró esemény BPMN jelölése

Activity


Tevékenység

o

A tevékenységeket BPMN
-
ben kerekített sarkú téglalappal jelöljük
,

és a
szervezet munkáját jelképezik. A tevékenységek lehetnek feladatok (atomiak)
vagy alfolyamatok (összetettek, tovább részletezettek). Az alfolyamatot egy kis
„plusz jel”
-
l
el jelöljük a téglalap alsó részén, középen. Abban az esetben, ha az
alfolyamatot

nem külön ábrán részletezzük, akkor a „plusz jel” helyett „mínusz
jelt” használunk.

Gateway


Átjáró

o

Az átjárót a jól megszokott rombusszal (45 fokban elforgatott négyzettel, vagy
„gyémánttal”) jelöljük
,

és a szokásos fork
-
join szerepét tölti be, tehát

ntéseket, elágazási és összefogó pontokat jelölhetünk vele. A rombusz belső
felében feltüntetett jelek mutatják az átjáró típusát.

2.

Connecting objects (Összekapcsoló objektumok):

A folyamatobjektumokat összekapcsoló objektumok segítségével köthetjük össze.
A
BPMN ezekből is három típust különböztet meg:

Sequence flow


szekvencia folyam

o

A szekvencia folyammal tevékenységeket köthetünk össze. A szekvencia
folyamot egy vékony vonallal és a végén sötét nyíllal jelöljük, ahol a nyíl vége
mutatja a tevékenységek
végrehajtásának irányát, sorrendjét. (Megj: a BPMN
nem használja a „control flow” kifejezést).

o

Figyelem: két különböző medencében lévő tevékenység között csak
üzenetfolyam jelölést használhatunk, szekvencia folyamot nem.

Message flow


üzenetfolyam

o

Az üzen
etfolyam szaggatott vonallal, a végén fehér nyíllal reprezentálható. Az
üzenetfolyam két egymástól elkülönülő folyamatszereplő (üzleti entitás vagy
üzleti szerepkör) üzenetváltását mutatja meg. A BPMN
-
ben két különálló
medence között húzhatunk üzenetfolyam
okat.

o

Az üzenetfolyam segítségével az üzleti felek közti üzenetváltások (küldés
-
fogadás) válik hangsúlyossá.

Association


asszociáció

o

Az asszociáció pöttyözött vonallal, végén egyszerű nyíllal reprezentálható.
Segítségével adat, szöveg és más termékek
rendelhetők a
folyamatobjektumokhoz.

o

Terméket csak asszociációs kapcsolattal rendelhetünk
folyamatobjektumokhoz. Ilyenkor kötelező meghatározni az asszociáció
irányát is (a vonal melyik végén legyen a nyíl). Az asszociáció irányától
függően az adat
-

vagy s
zövegobjektum be
-

vagy kimenet lesz.

6.2.

BPMN folyamat termékei

A BPMN alapelemei között három terméktípus szerepel: az adatobjektum, a csoport és a
megjegyzés. Eme
l
lett a BPMN
-
t úgy tervezték, hogy bármennyi terméket hozzá lehessen adni
egy diagramhoz
,

és ki
lehessen terjeszteni az alapelemek listáját.

1.

Artifact


(Termékek):

Data objects


adatobjektumok

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



15
/
31

o

Az adatobjektum klasszikus inputokat és outputokat jelenít meg. Segítségével
megmutathatjuk, hogy egy tevékenységhez milyen adatokra van szükség
,

illetve, hog
y milyen adatok jönnek létre a tevékenység végrehajtása esetén.

o

Az adatobjektumokat asszociáció segítségével köthetjük a tevékenységekhez.

Group


csoport(osítás)

o

A csoportosítást használhatjuk dokumentációs vagy elemzési célokra. Fontos
tudni, hogy nincs
hatással a szekvencia folyamra. A csoportosítást pontozott
-
szaggatott vonalú és kerekített sarkú téglalappal jelöljük.

Annotation


megjegyzés

o

A megjegyzések segítségével további információkat fűzhetünk a BPD
-
hez
vagy a BPD egyes elemeihez.


Olyan modellez
ésnél, ahol elég egy magas szintű, kevésbé precíz ábra (pl. dokumentációs
vagy kommunikációs célokra), ott egy jól érthető modell könnyen és gyorsan elkészíthető a
bemutatott alapelemek felhasználásával.


4
. ábra

BPMN alapelemekből

álló BPD

Ha mégis precízebb modellt szeretnénk, akkor felhasználható a BPMN kibővített elemlistája,
mely az alapelemeket további altípusokra bontva segít még konkrétabbá tenni az ábrát. Ezek a
kibővített jelölések általában az alapjelöléseken belül jelenn
ek meg.

6.3.

BPMN kibővített elemei

1.

pluszjel a tevékenység jelében


tovább részletezett, alfolyamat,

2.

vagy óra a köztes eseményt jelölő kettős kör belsejében


mely időzítést jelöl.

3.

Swimlanes


(Úszósávok):

Pool


medence

o

A medence egy folyamat résztvevőjét re
prezentálja, ugyanakkor grafikusan
mutatja meg az egymáshoz tartozó tevékenységek listáját.

o

A különböző medencékben található tevékenységek külön folyamathoz
tartoznak. Mindegyiknek van indító és záró eseménye.

Lane


sáv

o

Egy medencét több sávra lehet oszt
ani, így a sáv mindig egy medence részét
képezi. A sávok a tevékenységek szervezésére és kategorizálására
használhatók fel.

o

A különböző sávokhoz tartozó események egy folyamathoz tartoznak, így egy
indító és egy záró eseményük van.

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



16
/
31

o

Fontos különbség a meden
ce és a sáv között, hogy különböző sávokban
található tevékenységek között létrehozhatunk szekvencia folyamot, viszont
különböző medencékben található tevékenységek között nem (ez esetben
üzenetfolyamot hozhatunk létre).



5
. ábra
-

kiterjesztett BPMN elemeket is tartalmazó BPD

6.4.

BPMN
-
t jelenleg támogató eszközök listája

1.

Altova: UModel v2008r2 www.altova.com

2.

Appian Enterprise 5 Business Process Management Suite www.appian.com

3.

aXway: Process Manager™ www.axway.com

4.

BizAgi www.bizagi.com

5.

BOC Information Systems: ADONIS® www.boc
-
eu.com

6.

Borland® Together® Products: Together Architect® 2006 and Together Designer®
2006 www.borland.com

7.

Casewise: Corporate Modeler™ www.casewise.com

8.

Cordys: Studio www.cordys.com/products/studio

9.

Fuego: Fuego 5™ (B
EA) www.fuego.com

10.

Elixer Intelligent Software: eliXir BPMN
-
MDA Framework www.al
-
ixir.com

11.

EMC: EMC Documentation Process Suite software.emc.com

12.


Embarcadero Technologies: EA/Studio
http://www.embarcadero.com/products/eastudio/

13.

Fujitsu: Interstage Business P
rocess Manager 7.1
www.fujitsu.com/global/services/software/interstage/products/bpm/

14.

Graham Technology: GT
-
X www.gtnet.com

15.

Global 360: Business Optimization Server
-

Process Sketchpad www.global360.com/

16.

HandySoft Global Corp: BizFlow® BPM www.handysoft.com

17.

IDS
-
Scheer: Aris™ www.ids
-
scheer.com

18.

Corel: iGrafx™ www.igrafx.com

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



17
/
31

19.

ILOG: JViews™ www.ilog.com

20.

Intalio: n³ Designer™ www.intalio.com

21.

Intellior AG: AENEIS www.intellior.ag

22.

Interfacing Technologies: Enterprise Process Center; Free BPMN Modeler
www.interfacin
g.com

23.

ITpearls: Process Modeler for Visio www.itpearls.com

24.

Kaisha
-
Tec: ActiveModeler Avantage www.activemodeler.com

25.

Lanner: Witness™ www.lanner.com

26.

Lombardi Software: TeamWorks™ 5 www.lombardisoftware.com

27.

M1 Global: BPI Studio www.m1global.com

28.

Mega
International: Mega Suite™ www.mega.com

29.

Metastorm: Metastorm BPM™ Suite www.metastorm.com

30.

No Magic: MagicDraw UML 10.0 www.nomagic.com

31.

Orbus Software: iServer www.orbussoftware.com

32.

Pegasystems: BPMSuite www.pega.com

33.

QPR Software: QPR BPM Suite www.qpr.com

34.

Seagull Software: LegaSuite BPM www.seagullsoftware.org

35.

Software AG: Enterprise Business Process Manager (EBPM)
www.softwareagusa.com

36.

Popkin: System Architect™ www.popkin.com

37.

Proforma: ProVision™ www.proformacorp.com

38.

Santeon: XIP BPM Platform www.santeon.c
om

39.

Savvion: Process Asset Management www.savvion.com

40.

Select Business Solutions: Select Component Factory www.selectbs.com

41.

Skelta: Skelta BPM.NET 2006 www.skelta.com

42.

Soyatec: eBPMN Designer www.soyatec.com

43.

Sparx Systems: Enterprise Architect 6.5 www.sparxsy
stems.com

44.

Sun Microsystems: Studio Enterprise Edition www.sun.com

45.

Sybase: PowerDesigner® 12 www.sybase.com/developmentintegration

46.

Tibco: Business Studio ™ www.tibco.com

47.

Troux™: Metis 3.6 Enterprise Architecture Suite™ www.troux.com

48.

Visual Paradigm: Visual
Architect™ www.visual
-
paradigm.com


6.5.

BPMN támogatást tervező cégek és eszközeik listája

1.

Hyland: OnBase™ www.onbase.com

2.

IBM: WBI Modeler™ www.ibm.com

3.

Staffware: Process Suite™ www.staffware.com

4.

webMethods: Fabric www.webmethods.com


6.6.

BPMN
-
t támogató
nemzetközi szolgáltató cégek

1.

Service Provider Support for BPMN

2.

CSC e4 Architecture www.csc.com

3.

CTG: IT Services and Solutions www.ctg.be

4.

EDS www.eds.com

5.

Enix Consulting www.enix.co.uk

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



18
/
31

6.

Infy www.infy.com

7.

BPEL

Ebben a fejezetben áttekintjük az üzleti folyamat
ok leírására létrehozott BPEL (Business
Process Execution Language)
[2]

nyelvet, melyet egyre szélesebb körben alkalmaznak az új
informatikai rends
zerekben, és olyan nagy infrastruktúra
-

és alkalmazásfejlesztő vállalatok
támogatását élvezi, mint pl. Oracle, Microsoft, IBM, SAP, Siebel.

Amennyiben az e
-
közigazgatási keretrendszer kialakítása c. projekt irányait meghatározó
alapvető feltevésünk helyes
, miszerint az üzleti világ megoldásai között kell keresnünk azokat
a megoldásokat, melyeket közigazgatásban hosszútávon alkalmaznunk kell, különös
figyelmet kell fordítanunk a BPEL
-
re
,

mint a folyamatok szabványos leírónyelvére.

A webszolgáltatásokon alapuló rendszerek működésének összehangolására ma leginkább
olyan vezénylő motorokat használnak, melyben a folyamatokat BPEL nyelven írják le. A
BPEL olyan szabványos leírónyelv, amely segíti a webszolgáltatásokra épülő folyamatok
ös
szehangolását és végrehajtását. A nyelv egy egyszerűbb programozási nyelvhez hasonló
utasításkészlettel rendelkezik, amelyben támogatja a változók kezelését, adatműveleteket,
külső folyamat és szolgáltatáshívásokat, de önmagában nem alkalmas semmilyen konk
rét
feladat elvégzésére. Az egyes aktivitások végrehajtása egy külső, kiegészítő nyelven
elkészített parancs meghívásával jár, ami leggyakrabban Java.

A BPEL segítségével a következő építőelemek írhatók elő: XML
-
üzenetek távoli
szolgáltatásoknak történő k
üldése, XML
-
adatstruktúrák kezelése, XML
-
üzenetek távoli
szolgáltatásoktól történő aszinkron fogadása, események és kivételek kezelése, műveletek
párhuzamosan történő végrehajtása. Ezekkel az építőelemekkel a szolgáltatások csoportjai
együttműködő és tranz
akció alapú üzleti folyamatokká egyesíthetők. A BPEL az XML
-
sémán, valamint a SOAP, WSDL és a UDDI szabványokon alapul. A SOAP (Simple Object
Access Protocol) protokol biztosítja az objektumok közötti intreoperabilis kommunikácó
alapjait. A WSDL (Web Servi
ces Description Language) a webszolgáltatás nyilvános felületét
leíró nyelvtan. Az UDDI (Universal Description, Discovery and Integration) biztosítja azt az
infrastruktúrát, ami a szolgáltatások publikálásához és nyilvántartásához szükséges. A
z

UDDI
lehető
vé teszi a vállalatok számára, hogy megtalálják egymást, és meghatározzák ennek
segítségével, hogy miként kommunikáljanak az interneten.

7.7.

Történeti áttekintés

A 90
-
es évek végén az üzleti folyamatok modellezése (BPM) és leírása fontos informatikai
fejleszté
si célnak látszott. Olyan nagy rendszereket, eszközöket vizionáltak, melyekkel
minimális informatikai ismeretekkel az üzleti élet fogalmainak megfelelő leírásával
automatizált módon előállíthatók az üzleti folyamatokat hatékonyan támogató informatikai
rend
szerek. Az akkori BPM és dotcom technológia keltette várakozások a vártnál lassabban
valósultak meg, de ezen a területen az akkor megindult szabványosítási törekvések mára
beérni látszanak.

Az IBM és Microsoft kezdetben ugyan kifejlesztették maguknak a saj
át, mégis a másikéhoz
kísérteti
esen hasonló magas szintű leíró
nyelvüket. Ez az IBM
-
nél a WSFL, a Microsoftnál az
XLANG volt. A kezdeti külön utak azonban összekapcsolódtak, az IBM és a Microsoft
létrehozta a BPEL2WS nyelvet. 2003
-
ban az OASIS
-
nál szabványo
sításra jelentette be a BEA
FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



19
/
31

Systems, IBM, Microsoft, SAP és a Siebel Systems a BPEL4WS 1.1
-
et. 2004
-
től az OASIS
WS
-
BPEL 2.0 néven tartja nyilván a szabványt.

2007
-
ben az Adobe, BEA, IBM, ORACLE és SAP nyilvánosságra hozta a BPEL4People és
WS
-
HumanTask spe
cifikációkat, melyek azt célozzák leírni, hogy miként épülhet be a humán
interakció egy BPEL folyamatba.

7.8.

BPEL jellemzői

A 90
-
es évek kutatásainak eredményeként az üzleti folyamatokat modelljeiben kétféle leírási
módszert alkalmaznak a folyamatok leírására:

1.

Végrehajtható folyamatok leírása, amely az üzleti interakciók résztvevőinek aktuális
viselkedésére koncentrál.

2.

Ún. absztrakt folyamatok leírása. Az absztrakt folyamatok részlegesen specifikált
folyamatok, amelyeket nem hajtanak végre. Ezek azt írják le, hogy mikor van szükség
üzenetek küldésére és fogadására, mi történjen, ha pl. egy tranzakció nem sikerül. Az
absz
trakt folyamat számos műveleti részletet elrejthet.


A WS
-
BPEL mind a végrehajtható mind az absztrakt üzleti folyamatok modellezésére
alkalmas. Kiterjeszti a webszolgáltatások interakciós modelljét, és lehetővé teszi az üzleti
tranzakciók támogatását. A W
S
-
BPEL egy olyan interoperabilitis integrált modell, amely
lehetővé teszi az automatizált folyamatok integrálásainak kibővítését mind a vállalaton belül,
mind a vállalatok közt.


A BPEL nyelv az üzenetek küldése/fogadása mellett támogatja az alábbiakat:



T
ulajdonság alapú üzenetkorrelációs mechanizmus
.



XML és WSDL típusú változók
.



Lehetővé teszi kifejezések, feltételek megjelenítését. Alapértelmezésben XPath 1.0
-
t
.



Strukturált programozást tesz lehetővé az olyan szerkezetek használatával, mint „if
-
then
-
else

if
-
else, while, sequence”
.



Helyi változókkal történő egységbe zárás, hibakezelés, kompenzációkezelés,
eseménykezelés
.


Annak érdekében, hogy közzétegyünk egy webszolgáltatást, először definiálni kell a
szolgáltatós interfészét. Ezt a WSDL sémák teszik leh
etővé. A WSDL definiálja azokat az
információkat, amelyek azért kellenek, hogy meghívjunk egy szolgáltatást. Ilyenek például a
szolgáltatások bemenő és kimenő üzeneteinek formátumai.

A folyamatdefiníció egy üzleti folyamat reprezentációja, amely elősegíti
a modellezést, illetve
a folyamatkezelő rendszerek általi felhasználást. A folyamatdefiníció aktivitások hálózatából
áll, amelynek konkrét kezdete és vége van. Legfontosabb tulajdonságai:

1.

A modellezés eredményeképp tartalmazhat manuális és automatizált akt
ivitásokat.

2.

Tartalmazhat részfolyamatokra való hivatkozásokat.

3.

Hivatkozhat külső szervezet vagy erőforrás modellre.

7.9.

BPEL folyamat komponensei

A BPEL folyamatok folyamat elemekből ill. lépésekből épülnek fel
[13]
. M
inden lépés egy
aktivitás. Minden BPEL folyamat megadja azt a konkrét sorrendet, amiben a résztvevő
webszolgáltatások meghívandók. Ez történhet szekvenciálisan, illetve párhuzamosan is.

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



20
/
31

A BPEL segítségével kifejezhetünk feltételes viselkedést is, például e
gy webszolgáltatás
hívás függhet az előző hívás értékétől. Lehetőség van ciklusok létrehozására, változók
deklarálására, másolásra, illetve értékadásra, hibakezelésre, stb.

A fenti komponensek kombinálásával komplex üzleti folyamatokat lehet definiálni
al
goritmikus módon. Az így megadott folyamatok a determinisztikus és a nem
determinisztikus folyamatok is lehetnek. Az
6
. ábra

a BPEL folyamat webszolgáltatásokhoz
való kapcsolatát mutatja be. A külső kapcsolatokat az ún
. partner linkek azonosítják.



6
. ábra: BPEL folyamat és a webszolgáltatások kapcsolata

7.10.

Egyszerű tevékenységek nyelvi elemei

Az egyszerű tevékenységekre főként az alábbi egyszerű feladatok megvalósításánál van
szükség:

1.

webszolgáltatás meghívása <invoke>

2.

hívásfogadás, a kliens meghív egy folyamatot, miközben küld egy üzenetet. <recieve>

3.

szinkron műveletekre történő válaszadás generálás <reply>

4.

adatváltozók kezelése <assign>

5.

hibajelzés és kivételkezelés <throw>

6.

várakozás
<wait>

7.

folyamatmegszüntetés <terminate>


Folyamat elem

Fentebb már említettük, hogy egy folyamat mindig egy folyamat elemmel indul, aminek
tartalmaznia kell legalább egy tevékenységet (legyen az egyszerű vagy strukturált). Felépítése
a következő:

1.

name: a B
PEL folyamat nevét specifikálja

2.

targetNamespace: a folyamatdefiníció cél névterét specifikálja

3.

xmlns: a BPEL által használt névtér:
http://schemas.xmlsoap.org/ws/2003/03/business
-
process/


<process name="InsuranceSelectionProcess"


targetNamespace="http://packtpub.com/bpel/example/"


xmlns="http://schemas.xmlsoap.org/ws/2003/03/business
-
process/"

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



21
/
31


xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business
-
process/"


xmlns:ins="http://packtpub.com/bpel/insurance/"


xmlns:com="ht
tp://packtpub.com/bpel/company/"

>

A folyamat elemen belül számos további attribútum adható meg, amelyek a folyamat
különböző opciói vezérlésére szolgálnak.

1.

queryLanguage: specifikálja a lekérdezőnyelvet, amit a csomópont kiválasztásnál
használunk
,

pl. ért
ékadáskor, tulajdonságok megadás
a
kor. Az alapértelmezett az
XPath 2.0 vagy XQuery.

2.

expressionLanguage: az alapértelmezett kifejezésnyelv az XPath 1.0

3.

suppressJoinFailure: Összetett hibák kezelésének meghatározása.

4.

enableInstanceCompensation: a folyamatpél
dány kompenzálási lehetőségeit határozza
meg.

5.

abstractProcess: specifikálja, hogy absztrakt vagy futtatható folyamatról van
-
e szó. Az
alapértelmezett a „nem”, azaz a futtatható folyamat.


Partnerek

A BPEL használatának meghatározó eleme a folyamatok intera
kciója a webszolgáltatásokkal
kommunikáló partnerekkel. Ezen partnerek összekapcsolásának előfeltétele, hogy
létrehozható legyen kapcsolat a partnerek között. Minden résztvevő partnernek rendelkeznie
kell egy WSDL leíró fájllal, amelyben világosan szerepel
, mi módon lehet kommunikálni az
adott partnerrel.


PartnerLink

A BPEL folyamattal kommunikáló összes partnerhez való összeköttetés „partner link”
-
eken
keresztül történik. Partner linkeken keresztül történik a webszolgáltatásokkal történő
összeköttetés is.

Ezeket „invoked partner link”
-
eknek hívják. A partner linkek lehetnek linkek
a kliensekhez, amelyek meghívják a BPEL folyamatot. Ezek a „client partner link”
-
ek. Fontos
megjegyezni, hogy mindegyik BPEL folyamatnak legalább egy client partner linkkel kell
rendelkeznie, mivel kell lennie egy kliensnek, ami először meghívja a folyamatot.

Általában lesz egy invoked partner link is a BPEL folyamatban, mivel minden
valószínűséggel meg fog hívni legalább egy webszolgáltatást. A webszolgáltatás meghívása
az <invo
ke> tevékenység segítségével történik, ahol specifikálni kell a művelet nevét, a
meghívott port típusát. Azonban főleg aszinkron szolgáltatások meghívásánál, ahol a folyamat
műveletet hív meg, az invoked partner link client partner link lesz. Ezek után a s
zolgáltatás
meghívja a callback műveletet a folyamatra és visszatér a kért adattal.

A BPEL a klienseket két oknál fogva kezeli partnerként. Az egyik ok az aszinkron interakciók
támogatása. Az aszinkron interakcióknál a folyamatnak a műveleteket a klienseke
n keresztül
kell meghívnia. Másik ok az, hogy a BPEL folyamat maga is szolgáltatóvá válhat. A
szolgáltatásokat több kliens is igénybe veheti. A szolgáltatások ún portType
-
okon keresztül
érhetők el. (
7
. ábra
)


FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



22
/
31


7
. ábra: Aszinkron hívás


Az ábra egy tipikus aszinkron callback hívást illusztrál. A webszolgáltatás egy portType A
-
n
keresztül lehetővé teszi a BPEL folyamat számára, hogy használja a művelet meghívásakor. A
BPEL folyamatnak is ren
delkeznie kell egy portType
-
al annak érdekében, hogy a
webszolgáltatás meghívhassa a callback operációt. Jelen esetben utóbbit portTypeB
-
vel
jelöltük.


Partner link típusok

A partner link típus azt írja le, hogy miképpen lép interakcióba két fél, és mi az
, amit
egymásnak nyújtani tudnak. A fenti ábrára kétféleképp nézhetünk; tekinthetjük a BPEL
folyamat szemszögéből, illetve a webszolgáltatáséból. Ennek leküzdésére vezették be a
partner link típusokat. Egy partner link típusnak legalább egy szereppel rende
lkeznie kell, de
maximálisan kettővel. Az alábbi példában definiáljuk az
example

partnerLinkType
-
ot. Ez két
szerepet tartalmaz; a
role1
, illetve a
role2

szerepeket. A role1 az i névtérből való portTypeA
-
t
biztosítja, a role2 pedig az n névtérből való portTypeB
-
t. Ezek alapján ez BPEL kódban a
következőképp néz ki:


<partnerLinkType name="example"


xmlns="http://schemas.xmlsoap.org/ws/2003/05/partner
-
lin
k/">


<role name="role1">


<portType name="i:portTypeA"/>


</role>


<role name="role2">


<portType name="n:portTypeB"/>


</role>

</partnerLinkType>


Fontos megjegyezni, hogy a partner link típusok bevezetése nem tartozik a BPEL folyamat
dokumentum specifikációjába. Ez azért van így, mert a partner link típusok szolgáltatás
specifikusak
,

és nem a folyamat specifikációhoz tartoznak. A partner linkek konkrét
referenciák szolgáltatásokra, amelyekkel a BPEL folyamat kommunikál. Specifikációjuk

közvetlen a nyitó <process> címke után következik.

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



23
/
31


<process…>


<partnerLinks>



<partnerLink name="myExample"






partnerLinkType="t:example"






myRole="requester"






partnerRole="service"/>



<partnerLink .../>



...


</partnerLinks>


<sequence>




...


</sequence>

</process>


Változók

A változókban történik az üzenetcserék tárolása, melyek két folyamat partner közt zajlanak,
továbbá a folyamat állapotához tartozó adatokat is itt tárolhatjuk. Pontosabban a változók
tárolhatnak WSDL üzenete
ket, XML séma elemeket vagy XML séma típusokat. Minden
változót használata előtt deklarálni kell. Ez globálisan, a BPEL folyamat deklaráció elején
vagy a scope
-
ok közt adható meg. Egy változó deklarálásának szintaktikája többféle is lehet.


<variables>


<
variable name="ncname" messageType="qname"/>


<variable name="ngname" type="qname"/>


<variable name="ncname" element="qname"/>

</variables>


Értékadás

Adat másolása változók, kifejezések és partner linkek referenciái között értékadással történik.
Az
értékadás szintaktikája a következő:



<assign>


<copy>


<from ... />


<to ... />


</copy>


</assign>


Az <assign> tevékenységen belül egy vagy több <copy> szerepel, minden <copy>
-
hoz
specifikálni kell a forrást (<from>), illetve a c
élt (<to>). Lehetőség van az <assign>
tevékenységgel kifejezések változóba történő másolására is a következő módon. A <from>
címkénél specifikáljuk az expression attribútumot. Szintaktikailag a következő:



<assign>


<copy>


<from ex
pression="string('Name')" />


<to variable="LastName"/>


</copy>


</assign>


FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



24
/
31

Interfészek (invoke, receive, reply)

Mindhárom tevékenység használja az alábbi 3 alapvető attribútumot.

1.

partnerLink: specifikálja a használni kívánt partne
r linket

2.

portType: specifikálja a használni kívánt port típust

3.

operation: specifikálja a meghívandó (<invoke>), meghívott (<recieve>), választ
igénylő (<reply>) művelet nevét


<invoke>

Az operáció további két fontos attribútumot támogat. Amikor a folyamat
meghív egy
műveletet a webszolgáltatáson, akkor számos paramétert küld el. Ezek a paraméterek lesznek
a bemenő üzenetei a webszolgáltatásnak. Továbbiakban ezeket inputVariable attribútumnak
nevezzük. Szinkron kérés/válasz eredménnyel tér vissza. Ez újra üz
enetet generál, ami a
kimenő üzenet lesz. Annak érdekében, hogy eltároljuk egy változóban, az <invoke> egy újabb
attribútumot biztosít outputVariable névvel. Példával demonstrálva ez a következőképp néz
ki:


<invoke partnerLink="partner1"


p
ortType="i:Compute"


operation="A"


inputVariable="req "


outputVariable="resp" >

</invoke>


A fenti BPEL folyamatrészlet meghív egy szinkron műveletet, nevezetesen A
-
t i:Compute
port type
-
al, parner1 partner li
nkkel, miközben a bemenő üzenetet „req” változóban, a
kimenőt „resp”
-
ben tárolja.


<receive>

A <receive> tevékenység bemenő üzenetre vár, ami vagy a kezdő hívás, vagy egy callback.
Általában a folyamatnak tárolnia kell a bejövő üzenetet, amihez a variable

attribútumot
használja. További attribútum a <receive> tevékenységnél a createInstance, ami a folyamat
életciklusához, példányosításához köthető. Az alábbi kód szemlélteti a fentieket:


<receive partnerLink="client"


portType="c:port"



operation="op"


variable="req"


createInstance="yes" >


</receive>


<reply>

Használata szinkron BPEL folyamatoknál válasszal való visszatéréskor. A <reply> mindig az
indító <receive>

-
hez köthető, amelyen keresztül elindul a BPEL folyamat. Egy további
attribútumra van szükségünk, amiben tárolódik a válasz.

Az alábbi példában a select operáció c:port
-
on keresztül használja a client partner linket. A
visszatért választ a „resp” változó
ban tárolja.

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



25
/
31


<reply partnerLink="client"


portType="c:port"


operation="select"


variable="resp" >

</reply>


Várakozás

Néhány estben szükség lehet, hogy specifikáljunk egy bizonyos késést. Ezt kétféleképpen
valósí
thatjuk meg BPEL
-
ben, egyik verzió, hogy egy bizonyos ideig késleltetünk, illetve
addig tart a késleltetés, amíg egy bizonyos határidőt el nem értünk. Mindezeket a <wait>
blokkal adhatjuk meg.


<wait for="duration
-
expression"/>

<wait until="deadline
-
expre
ssion"/>


Üres tevékenységek

Ezek akkor hasznosak, amikor példányosításnál specifikálni kell egy tevékenységet, azonban
valójában nem kívánunk végrehajtani semmit. Például egy <switch> blokkon belül nem
szeretnénk minden esetre végrehajtani tevékenységet.
Ilyenkor <empty/> címkét használunk.


Folyamat megszüntetés

Lehetőség van folyamatok idő előtti, befejezés nélküli megszüntetésére a <terminate/> címke
segítségével. Gyakran alkalmazzuk ezt a switch
-
eknél. A megszüntetéskor nincsen semmilyen
hiba és
kompenzáció
-

kezelés.

7.11.

Komplex tevékenységek nyelvi elemei

Komplex algoritmusok leírását az ún. strukturált tevékenységek segítik. A strukturált
tevékenységek magát a folyamatot strukturáltan írják le. Így lehetővé válik vezérlő minták,
adat folyamok, hiba
kezelés és üzenet koordináció használata. Az idetartozó tevékenységek a
következők:

1.

tevékenység halmaz szekvenciális meghívása <sequence>

2.

tevékenység halmaz párhuzamosan történő meghívása <flow>

3.

elágazások megvalósítására case
-
switch szerkezet <switch>

4.

cik
lusok implementálására <while>

5.

alternatív lehetőségek kiválasztására <pick>


Feltételek

A BPEL
-
ben a feltételen alapuló elágazásokat <switch> tevékenységek definiálják, ahol
minden ágat a saját <case> eleme specifikál, amit egy <otherwise> ág követhet.

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



26
/
31



<switch>


<case condition="boolean
-
expression">


<!
--

some activity
--
>


</case>


<case condition="boolean
-
expression">


<!
--

some activity
--
>


</case>


<otherwise> <!
--

optional
--
>


<!
--

some activity
--
>


</
otherwise>


</switch>


sequence

Egy szekvenciális tevékenység egy vagy több olyan tevékenységet tartalmaz, amelyeket
időben egyszerre kell végrehajtani. Ezek bezárhatók a <sequence> tevékenységbe.


<sequence>



activities

</sequence>


while

A while tevékenység lehetővé teszi, hogy végigmenjünk bizonyos tevékenységeken iteratív
módon.


<while condition="bool
-
expr">



activity

</while>


A blokkban levő tevékenységek addig hajtódnak végre ciklikusan, míg a bool kifejezés a
feltétel részben iga
z.


Pick

A pick tevékenység addig vár, míg az egyik esemény be nem következik az események
sorából. Amikor bekövetkezik az esemény, a hozzá tartozó tevékenységek végrehajtódnak.

Amennyiben több esemény következik be, az elsőnek bekövetkező dolgozódik fel.

Lehetséges
események például egy üzenet megérkezése vagy ha az időzítő lejár.


<pick createInstance="yes|no">


<onMessage partnerLink="ncname" portType="qname" operation="ncname"


variable="ncname">


activity


</onMessage>




<
onAlarm (for="duration
-
expr" | until="deadline
-
expr")>


activity



</onAlarm>

</pick>


A receive tevékenységhez hasonlóan a <pick> a folyamat elejére helyezhető, és a
createInstance beállításával folyamatindítóvá választható.


FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



27
/
31

Flow

A <flow> blok
kban lehetséges a tevékenységek párhuzamos végrehajtása. A <flow> akkor ér
véget, ha a benne levő minden tevékenység lefutott. A <flow> blokkon belül lehetséges a
tevékenységek szinkronizációja.


<process ...>


...


<sequence>


<!
--

Wait for th
e incoming request to start the process
--
>


<receive ... />


<!
--

Invoke a set of related web services, concurrently
--
>


<flow>


<invoke ... />


<invoke ... />


<invoke ... />


</flow>


...


<
/sequence>

</process>


Korreláció

Mivel a folyamatok egyszerre több szolgáltatással kommunikálhatnak, illetve ezek a
szolgáltatások is kommunikálhatnak további szolgáltatásokkal, ezért fontos, hogy mindig
tisztában legyünk azzal, hogy a megfelelő szolgá
ltatás példánnyal kommunikálunk. Annak
érdekében, hogy ezt megvalósítsuk BPEL
-
ben, korrelációt lehet használni. A korreláció
megteremti a lehetőséget, hogy mindig ugyanahhoz a szolgáltatás példánnyal
kommunikáljunk. Mindezt azonosító változókkal valósítja
meg. Amikor egy folyamatot
meghívunk, ezeknek a változóknak rendelkezésre kell állniuk az azonosítás végett.


Scope

A scope
-
okkal lehetőség nyílik a komplex folyamatok hierarchikusan rendezett részekre való
bontása. Mindegyik résznek lehetősége van a saját

változóit elkészíteni. Egy scope
-
on belül
további új scope készíthető. Azonban az itt használt változók nem láthatók a szülő számára,
de a szülő változói láthatók a gyerek számára. Ebből következően a globális scope változói az
egész folyamat során elérhe
tők. Minden scope biztosít egy kompenzációkezelőt, hibakezelőt
és eseménykezelőt.

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



28
/
31

8.

Követelményeknek való megfelelés

Az e
-
közigazgatási keretrendszer kialakítása projekt keretében kiválasztandó folyamatleíró
nyelvvel támasztott legfontosabb követelmény, hog
y képes legyen megfelelni az
in
teroperabilitási feltételeknek. Ezen belül is a legfontosabb, hogy olyan a magas szintű leírást
válasszunk, ami garantálja a különböző rendszerek és platformok közötti együttműködés
lehetőségét.

A különböző leírónyelvek össze
hasonlításához felhasználtuk Eindhoven University of
Technology és az
ausz
t
ráliai Queensland University of Technology
munkafolyamat
-
mintákkal
végzett kutatásainak eredményeit
[17]

is. Ebben a kutatásban gyakran előforduló, tipikus
munkafolyamat
-
mintákat definiáltak a kutatók, majd azt vizsgálták, hogy mely nyelv ill.
eszköz hogyan támogatja az adott minta leírását.

Példaként álljon itt az egyszerű végrehajtási szekv
encia (Sequence), mint munkafolyamat
minta:


Ezt a mintát természetesen minden vizsgált leírónyelv támogatja, de nem mondható ez el a
bonyolultabb munkafolyamat
-
mintákra. A kutatásban közel 50 munkafolyamat
-
mintával
[18]

és hasonlóan nagy számú adatmintával
[19]

ill. erőforrás mintával
[20]

vizsgálták a
legjelentősebb nyelveket (BPEL, BPMN, XPDL, UML, EPC) és számos üzleti (
Staffware
,
WebSphere
,
FLOWer
,
COSA
,
iPlanet
,
SAP Workflow
,
FileNet
) és opensource ternéket
(
jBPM
,
OpenWFE
,
Enhydra Shark
)
[17]
.

A vizsgálati eredmények és saját tapasztalataink azt mutatják, hogy jelenleg nehezen
v
álasztható ki egyetlen egy nyelv, ami akár a magas szintű leírást, akár a technológiai
leírónyelvet egyaránt jól támogatja.

Legmegfelelőbbnek a BPMN és a YAWL tűnik. Gyártói támogatottság szempontjából a
BPEL is szóba jöhet, de e
ddigi tapasztalatink al
apján úgy tűnik, hogy a BPEL
nem tudja
kiváltani a magasabb szintű

leírásokat. Ennek egyik oka a grafikus leírás definíciójának
hiánya (nem célja definíciónak), másrészt maga a szabvány még nem forrt ki teljesen.
Nemrégiben volt egy jelentős verzióváltás,
amit a gyártók egy része még nem vezetett át
termékeken.

Ha csak a folyamat
-
minták támogatottságát vizsgáljuk, akkor YAWL valamivel több
támogatást nyújt, de ez nem véletlen, hiszen a YAWL nyelv létrehozói pont ezt a célt tűzték
ki a nyelv megalkotásánál.

Az EPC nem nyújt támogatást az adatminták leírásához, ezért ennek használatát nem
javasoljuk az e
-
közigazgatási keretrendszerben való alkalmazását.

További fontos szempont a kezelhetőség és elsajátíthatóság, valamint a közigazgatási
környezetbe való ille
sz
thetőség.

A grafikus leírás létrehozása szempontjából egyetlen közös pontnak az MS
-
visio tűnik, mivel
a grafikus elemkészlete könnyen bővíthető, és az elkészített grafikus leírást igen sok termék
képes importálni.

Az alacsonyabb szintű technológiai leírás
számára, melyet a folyamatmotorok közvetlenül
értelmezni tudnak, szinte csak a BPEL és a YAWL látszik valós lehetőségnek.

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



29
/
31

Itt azonban ismét vissza kell utalnunk a magasabb szintű leírásra. Amennyiben a magasabb
szintű leírás tartalmaz minden olyan informác
iót, ami a technológia számára kell, akkor a
technológiai leírás eszközéről szóló döntés lényegében megvalósítás szintjéig elhalasztható,
mivel ebben az esetben
a technológiai folyamatleírás már automatikusan generálható.

Ez a módszer segít áthidalni a tec
hnológiai leírás esetleges verzió vagy gyártófüggő
megoldásait is, ugyanis megfelelő metainformációkkal ellátott leírásból automatikusan
generálhatók a gyártófüggő megoldások technológiai leírásai.

Megfelelő formalizmus alkalmazásával automatikus konziszte
ncia ellenőrzés tovább segítheti
a folyamatok korszerűsítését. Ezzel lehetővé válik a rejtett problémák akár jogszabályi szintre
történő visszacsatolása.

9.

Összefoglalás, j
avaslat

A folyamatleíró nyelvek kiválasztását előkészítő irodalmi és gyakorlati kutatá
saink
eredményét összefoglalva alátámasztottnak látszik a dokumentum
3
. fejezetében tett azon
megfogalmazás, hogy a leírást több szinten kell elvégezni. Nem létezik ugyanis jelenleg olyan
eszköz, ami az elvárt előnyöket együtt tudn
á biztosítani.

Vizsgálataink során több eszközt és módszert is megvizsgáltunk. Ennek eredményeként
azonban nem tudunk egyértelmű, csak előnyöket felmutató módszerre rámutatni.

E
lterjedtsége és támogatottsága miatt az e
-
közigazgatási keretrendszerben a köz
igazgatási
folyamatok magas szintű leírására, modellezésére a BPMN alkalmazása tűnik indokoltnak és
célszerűnek. Ezt a módszert számos termék támogatja, és nem csak leírásra alkalmas, hanem
ellenőrzésre is.

Ma már a piacon számos olyan fejlesztőeszköz tal
álható, ami a BPMN segítségével készített
leírásokból a folyamatmotorok által közvetlenül felhasználható technológiai szintű leírást (pl.
BPEL) tud készíteni.

Technológia folyamatleíró nyelvnek a BPEL tűnik a legalkalmasabbnak, és
legperspektivikusabbnak,
mivel fejlesztésébe, tökéletesítésébe az OASIS konzorcium jelentős
erőforrásokat fektet.

Az e
-
közigazgatási keretrendszerben kialakítása projekt megvalósítása során a folyamatok
leírására e javaslat figyelembevételével kell kidolgozni módszertant és elkész
íteni a
folyamatok leírását segítő gyakorlati útmutatót.

A javaslat tehát egy olyan leírási módot vetít előre, melynek során az átalakítandó folyamatról
a kezdeti felmérés, információgyűjtés és a jogi feltételek ellenőrzése során a közigazgatási
szakembere
k és az informatikai szakemberekkel közösen egy szöveges/táblázatos leírást
készítenek, melyet BPMN jelöléssel grafikusan is dokumentálnak.

Ezt követően az informatikai szakemberek ellenőrzik, finomítják a leírást melynek: Ennek
eredményeként elkészül egy
olyan BPMN leírás, mely géppel segített konzisztencia
ellenőrzésre is alkalmas. Ez a leírás képezi alapját a folyamatok korszerűsítésének. Ez
tartalmazza mindazokat az információkat, kapcsolatokat, valamint a jogszabályokra való
hivatkozást, amit korszerűs
ítési munka során fel kell használni, esetenként ki kell egészíteni.

Feltételezhető, hogy az általunk javasolt megoldásokat egy
-
egy konkrét feladat
megvalósításakor egyéni megoldásokkal kell kiegészíteni, ami pl. alkalmas a
szöveges/táblázatos leírások kar
bantartására.


FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



30
/
31

10.

Irodalomjegyzék

[1]

OASIS (Organization for the Advancement of Structured Information Standards)
honlap:
http://www.oasis
-
open.org
, 2008. március

[2]

BPEL (Business Process Execution Language) standard:

http://docs.oasis
-
open.org/wsbpel/
2.0/OS/wsbpel
-
v2.0
-
OS.pdf, 2008. március

[3]

J2EE Java 2 Platform, Enterprise Edition honlap: http://java.sun.com/javaee

[4]

RosettaNet honlap: http://www.rosettanet.org, 2008. március

[5]

WebSphere Process Server honlap:

http://www
-
306.ibm.com/software/integration/w
ps/, 2008. március

[6]

WebSphere Application Server honlap:

http://www
-
306.ibm.com/software/webservers/appserv/was/, 2008. március

[7]

WebSphere Integration Developer honlap:

http://www
-
306.ibm.com/software/integration/wid/, 2008. április

[8]

Eclipse honlap: http://
www.eclipse.org/, 2008. március

[9]

Oracle BPEL Process Manager: honlap
http://www.oracle.com/technology/products/ias/bpel/index.html, 2008. március

[10]

Active BPEL honlap: http://www.activevos.com/community
-
open
-
source.php, 2008.
március

[11]

Websphere BPM megoldáscso
mag, IBM, 2007

[12]

Weszolgáltatások összehangolása: a BPEL kiszolgáló előnyei, Oracle tájékoztató, 2004.

[13]

Matjaz. B, Juric: Business Prosess Execution Lenguage for WebServices, PACKT,
2006. 2nd edition

[14]

Wahl T, Sindre G. (2005) “An Analytical Evaluation of BPMN
Using a Semiotic
Quality Framework”

http://www.via
-
nova
-
architectura.org/files/EMMSAD2005/Wahl.pdf

[15]

Business Process Execution Language, Wikipedia, honlap:

http://en.wikipedia.o
rg/wiki/BPEL, 2008. április

[16]

YAWL honlap:
http://www.yawl
-
system.com/
, 2008. július

[17]

Munkafolyamat
-
minták vizsgálatát végző projekt honlapja:
http://www.workflowpatterns.com/index.php
, 2008. július

[18]

N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst, and N
. Mulyar.

Workflow Control
-
Flow Patterns: A Revised View
.

BPM Center Report BPM
-
06
-
22
, BPMcenter.org, 2006.

[19]

N. Russell, A.H.M. ter Hofstede, D. Edmond, and W.M.P. van der Aalst.

Workflow Data Patterns
.

QUT Technical report, FIT
-
TR
-
2004
-
01, Queensland
University

of Technology, Brisbane, 2004.

[20]

N. Russell, A.H.M. ter Hofstede, D. Edmond, and W.M.P. van der Aalst.

Workflow Resource Patterns
.

BETA Working Pap
er Series, WP 127, Eindhoven
University of Technology, Eindhoven, 2004.

[21]

XPDL honlap:
http://www.wfmc.org/standards/xpdl.htm

[22]

EPML honlap: http://www.epml.de/, 2008. június

[23]

MendlingJ., Neumann G., Nüttgens M. (2005a), Towards Workflow Pattern Support of
Eve
nt
-
Driven Process Chains (EPC)

[24]

W.M.P. van der Aalst, J. Desel, and E. Kindler. On the Semantics of EPCs: A

Vicious
Circle. In M. N¨uttgens and F.J. Rump, editors, Proceedings of the EPK

2002: Business
Process Management using EPCs, pages 71

80, Trier, Germ
any,

November 2002.
Ges
ellschaft f¨ur Informatik, Bonn

FOLYAMATLEÍRÓ NYELV KIVÁLASZTÁSA



31
/
31

[25]

W. Reisig and G. Rozenberg, editors. Lectures on Petri Nets I: Basic Models,

volume 1491 of Lecture Notes in Computer Science. Springer
-
Verlag, Berlin, 1998.

[26]

Yi Gao (2008) BPMN
-
BPEL Transformation and
Round Trip Engineering,
http://www.eclarus.com/pdf/BPMN_BPEL_Mapping.pdf

[27]

M. Dumas and A.H.M. ter Hofstede. UML activity diagrams as a workflow
specification

language. In M. Gogolla and C. Kobryn, editors, Proc. of the 4th Int.

Conference on the Unified Mod
eling Language (UML01), volume 2185 of LNCS,

pages 76

90, Toronto, Canada, October 2001. Springer Verlag.

[28]

Wf
MC. Workflow Management Coa
lition Terminology and Glossary

(WFMCTC
-
1011). Technical report, Workflow Management Coalition, Brussels, 1996.

[29]

WfMC honl
ap:
http://www.wfmc.org
, 2008. június

[30]

GPL szerződés:
http://www.gnu.org/licenses/gpl.html
, 2008. június