Stabilirea cerinţelor în contextual lumii reale

Transcription

1 SCIPA - Stabilirea cerințelor în contextual lumii reale SCIPA Servicii software semantice de Colaborare si Interoperabilitate pentru realizarea Proceselor Adaptive de business Stabilirea cerinţelor în contextual lumii reale Autori Academia de Studii Economice Bucureşti Prof. dr. Ion Smeureanu responsabil științific, Prof. dr. Ion Gh. Roşca, Conf. dr. Marian Dârdală, Conf. dr. Titus-Felix Furtună, Lect. dr. Adriana Reveiu, Lect. dr. Ramona Bologa, Prep. drd. Andreea Dioşteanu, Drd. Alexandra Tudorache Contract nr / Autoritatea contractantă: CNMP

2 SCIPA - Stabilirea cerinţelor în contextual lumii reale CUPRINS Partea I Definirea cerinţelor utilizatorilor şi a cazurilor utilizator Modelarea proceselor de business Modalitatea generală de lucru în vederea proiectării modelului de business Simularea proceselor Maparea modelului de business peste modelul lingvistic implementat cu ajutorul ontologiilor şi semanticii web Analiza procesului de afaceri pentru construirea ontologiilor Metodologie de analiză de tip proces-activitate Colectarea informaţiilor despre activităţi şi procese Gestiunea lanţului de activităţi aprovizionare-desfacere caz utilizator Cerinte ale unei platforme de interoperabilitate bazate pe semantici, ontologii si reguli de afaceri Testarea compatibilitatii regulilor de afaceri corespunzatoare organizatiilor implicate intr-o solutie de interoperabilitate Integrarea semanticii vocabularului regulilor de afaceri Compatibilizare la nivel de procese de afaceri. Interpretarea abstracta si concreta a unui proces de afaceri Urmarirea gradului de aliniere a sistemului informatic la strategia firmei Impactul adaptabilitatii proceselor de afaceri asupra proiectarii platformei de interoperabilitate Orientarea tehnologica a platformei Identificarea nevoilor si ofertelor de cooperare Identificarea sabloanelor de colaborare agreate de o firma Alegerea celor mai influenti agenti economici din lantul de creare a valorii noi adaugate Soluţii de cooperare virtuală pentru mediu de afaceri Structuri virtuale Biroul virtual Întreprinderea virtuală Organizaţia virtuală Echipa virtuală Caracteristicile întreprinderii virtuale Vectorii virtualităţii. Avantaje şi riscuri în întreprinderea virtuală Implicaţiile virtualizării structurii organizatorice Implicaţii din punct de vedere al strategiei competitive Implicaţii din punct de vedere al costurilor tranzacţionale Implicaţii din punct de vedere al dreptului de proprietate Avantaje şi riscuri ale cooperării în cadrul întreprinderilor virtuale Bibliografie

3 SCIPA - Stabilirea cerinţelor în contextual lumii reale Partea I Definirea cerinţelor utilizatorilor şi a cazurilor utilizator Rezumat Parte Majoritatea proceselor de business au fost documentate în vederea creării unor modelele de management complexe. Datorită volumului mare de informaţii şi transformărilor care au loc în domeniul IT&C, companiile se confruntă cu probleme care nu mai pot fi modelate şi tratate conform metodelor tradiţionale. În vederea soluţionării cât mai eficiente a problemei modelării proceselor de afaceri, au fost create ontologii, semantici web şi sisteme bazate pe agenţi inteligenţi. Pentru modelarea cât mai aproape de realitate a proceselor de afaceri, există posibilitatea de a defini regulile după care se defăşoară. În vederea implementării unui model de business, primul lucru care trebuie avut în vedere este modelul serviciilor web care conţin funcţionalităţile specifice fiecărui element al modelului. Semantica utilizată în modelul lingvistic se bazează pe ontologii. Regulile semantice şi lexicale vor fi create pe baza unor euristici conform regulilor lingvistice şi a logicii economice. Prin intermediul modelului lingvistic sunt reprezentate: fluxurile de date, mesajele, evenimentele, regulile de afaceri, excepţiile, tranzacţiile (distribuite, sincrone, asincrone, etc). Modelarea proceselor de business este o etapă esenţială în cadrul unei organizaţii. Cu ajutorul acestor modele se vor putea valorifica mai uşor şi mai eficient experienţele anterioare. Toate tehnicile de analiză bazate pe metoda proces-activitate presupun analiza afacerii pentru a obţine informaţii semantice referitoare la activităţile efectuate şi modul de transfer al informaţiilor între activităţi și pot fi folosite în vederea construirii ontologiilor. Utilizarea acestor tehnici transcede orice sector al industriei. Această metodă poate fi aplicată la orice nivel al unei organizaţii, la colaborarea între organizaţii, oricărei activităţi care consumă resurse. Operaţiile sunt formate dintr-un număr de subprocese, unele dintre acestea fiind de tip suport şi sunt comune majorităţii organizaţiilor precum: aprovizionare, recrutare de personal, gestiunea informaţiilor. Alte operaţii sunt specifice domeniului analizat, şi formează o listă de aşteptare. În funcţie de activităţile şi procesele folosite, datele trebuie colectate de la persoanele care participă la realizarea activităţilor din fiecare centru de buget sau sub-proces. Există o serie de metode care pot fi folosite pentru colectarea datelor în vederea construirii semanticilor. Gestiunea lanţului de activităţi de la aprovizionare până la desfacere presupune controlul și coordonarea tuturor activităţilor unei organizaţii de la furnizorii de produse la clienţii săi și poate fi folosită drept caz utilizator pentru sistemul IT integrat. Regulile de afaceri se referă la multitudinea de politici, proceduri sau definiţii care guvernează modul de funcţionare al unei organizaţii, împreună cu interacţiunea acesteia cu furnizorii si beneficiarii săi. Reiese ca orice interoperabilitate trebuie sa asigure 3

4 SCIPA - Stabilirea cerinţelor în contextual lumii reale respectarea sistemului de reguli de afaceri ale fiecarui participant intr-o solutie de interoperabilitate. Completitudinea si coerenta sistemului de reguli de afaceri la nivelul unei organizatii cade in sarcina organizatiei; in cazul unei platforme de colaborare, compatibilizarea regulilor de afaceri dupa care se conduc partenerii cade in sarcina platformei. O solutie de interoperabilitate bazata pe agenti va avea ca suport informatia oferita de sistemele informatice ale partenerilor implicati, impreuna cu dictionarul semantic al domeniului de business. Desi aparent cooperarea intre firme n-ar trebui sa implice cunoasterea detaliilor privind procesele de afaceri, ci numai "interfetele" lor, in realitate pot exista constrangeri privind procesele tehnologice, succesiunile de activitati, calitatea output-urilor etc. Spre exemplu, un proces tehnologic nu poate utiliza decat o materie prima de o anume calitate sau obtinuta la randul ei numai printr-un anumit proces tehnologic. Agentul de negociere a unei cooperari trebuie sa aiba capacitatea abstractizarii unui proces de afaceri, sa inceapa cautarea cu semantica nivelului cel mai abstract, procedand apoi la particularizari specifice unui domeniu de afaceri. Schimbarile majore din sistemele informatice ale firmelor se produc ca urmare a schimbarilor din procesele de afaceri. La proiectarea unei platforme de interoperabilitate trebuie sa se tina seama de directia evolutiei, pentru a asigura adaptabilitatea. Pentru a aprecia gradul de aliniere a sistemului informatic la strategia firmei. Intotdeauna se incepe cu clientii urmarindu-se adaptarea produselor la asteptarile acestora; se continua cu analiza procesului de business care sa permita obtinerea produselor dorite; abia apoi sunt deduse tehnologiile necesare, informatiile si tipul participantilor la un astfelde proces. Corelarea se produce in ambele sensuri şi poate fi apreciata la un moment dat (static), dar si in dinamica, cand o modificare a unui element atrage schimbari in lant (produse noi care presupun schimbari tehnologice, training pentru adaptare la noua tehnologie, achizitia de noi informatii si cunostinte). Cunoasterea flexibilitatii si limitelor proceselor tehnologice, dar si a sistemelor informatice de a se reconfigura pe masura schimbarilor din mediu de afaceri, reprezinta un criteriu esential in selectarea oportunitatilor si posibilitatilor de cooperare intre firme. Teoretic, arhitectura SOA incapsuleaza integral un domeniu de business; maniera in care o face este insa esentiala si depinde de abilitatea celui care modeleaza. In principiu, se urmareste gasirea unui echilibru intre diminuarea numarului de dependente dintre servicii (deoarece la un numar mare de interactiuni, modificarea unui serviciu antreneaza modificari in cascada in alte servicii) si evitarea unei granularitati exagerate, care ar conduce la o complexitate prea mare a sistemului. Alegerea unui nivel optim de descompunere a proceselor pe servicii asigura posibilitatea reconfigurarii sistemului prin compunerea serviciilor existente si doar rareori scrierea de noi servicii. Solutia de interoperabilitate trebuie sa fie orientata spre noile tehnologii de realizare a sistemelor informatice pentru afaceri, urmand ca sistemele mostenite (legacy systems) sa beneficieze de facilitatile unei astfel de platforme numai dupa expunerea functionalitatii lor prin servicii. Odata realizata aceasta transpunere, modificarea sau rescrierea totala a unei functionalitati nu mai afecteaza ulterior schema de colaborare intre functii si nici intre firme. Platforma trebuie sa dispuna de un set de sabloane de colaborare folosite uzual in domeniul afacerilor. Se includ aici modele incepand cu simple acorduri de colaborare, comenzi ferme emise in baza unor acorduri, contracte, pana la conventii prin care o firma 4

5 SCIPA - Stabilirea cerinţelor în contextual lumii reale preia atributii decizionale pe un segment limitat de competente dintr-o alta firma (spre exemplu, o firma furnizoare declanseza un proces de aprovizionare a unui supermarket). Avand in vedere ca procesul de creare a valorii adaugate este un flux, profitul unei firme depinde nu numai de performantele firmei si competitorilor, ci si de eficienta cu care opereaza furnizorii si beneficiarii: acest lucru se explica prin faptul ca valoarea adaugata se redistribuie prin preturi intre participanti, pe intreg lantul in care e creata. In consecinta, la alegerea partenerilor de afaceri, firma este interesata sa colaboreze cu cei mai influenti si eficienti participanti din lantul de creare al valorii adaugate. Platforma de interoperabilitate trebuie eventual sa permita utilizatorilor sa adere la anumite lanturi de creare a valorii nou adaugate. Noua economie digitală, bazată pe Internet este o economie a afacerilor clădite în jurul serviciilor Internet şi a reţelelor electronice, o economie în care apar noi forme de companii şi noi forme de muncă. În noua economie se observă o schimbare a paradigmelor legate de producţie şi management care însoţeşte trecerea de la societatea industrială la societatea informaţională. Întreprinderile virtuale sunt create pentru a veni în întâmpinarea unor anumite oportunităţi ivite pe piaţă şi sunt dizolvate în momentul în care oportunitatea dispare. Integrarea virtuală, opusă integrării verticale, va fi probabil fundamentul pentru o strategie de afaceri competitivă. Caracteristic oricărui obiect virtual este posibilitatea formării şi dizolvării legăturilor dintre părţile componente pentru a reacţiona rapid şi eficient la diferitele probleme ce apar în sistem sau în mediul său înconjurător. Biroul virtual defineşte companie sau un parteneriat de natură permanentă, dar care are un număr important de angajaţi la distanţă. Biroul virtual îndeplineşte rolul biroului tradiţional, centralizat, dar pe de altă parte, angajaţii lucrează în birouri aflate la domiciliu, şi colaborează în cea mai mare parte a timpului electronic, venind doar ocazional în contact cu ceilalţi angajaţi. Întreprinderea virtuală este o reţea, mai mult sau mai puţin temporară, alcătuită din întreprinderi sau persoane independente din punct de vedere juridic care care îşi unesc bunurile, competenţele şi alte resurse în scopul realizării unui proiect comun care depăşeşte capacităţile fiecăreia dintre unităţi luată individual în ceea ce priveşte posibilitatea de a exploata oportunităţile volatile, de a avea acces la noi pieţe şi de a partaja costurile şi riscurile, întreagă această suprastructură bazându-se pe noile tehnologii ale informaţiei şi telecomunicaţiilor. O organizaţie virtuală (sau organizaţia cu structură organizatorică virtuală) este formată din unităţi organizatorice distribuite care participă la un proces de muncă coordonat, divizat, unităţi ce sunt părţi ale unei reţele complexe susţinute de tehnologii informaţionale corespunzătoare. Pornind de la definiţia biroului virtual, putem defini echipa virtuală ca fiind construită pentru situaţii în care membrii săi sunt distribuiţi geografic. Atât biroul, cât şi echipa virtuală presupun membrii distribuiţi, aşadar au nevoie de infrastructură similară şi vor necesita planificare şi executare a sarcinilor într-un mediu cu restricţii de resurse. Pentru interconectarea întreprinderilor în întreprinderi virtuale este important nivelul executiv, unde există numeroase procese care pot să beneficieze de pe urma tehnologiei informaţiei şi chiar să fie complet automatizate. 5

6 SCIPA - Stabilirea cerinţelor în contextual lumii reale Abordările mai noi ale integrării întreprinderilor virtuale propun un model al fluxului de producţie interorganizaţional pe trei niveluri, care surprinde fluxurile de producţie ale partenerilor, viziuni ale fluxurilor şi fluxuri ale coaliţiei. În acest mod sunt depăşite limitările modelului cu un nivel (punct la punct) sau cu două niveluri (privat-public). Caracteristica esenţială a unei întreprinderi virtuale este virtualitatea, o capacitate pe care fiecare o posedă într-o măsura mai mare sau mai mică,. Virtualitatea este definită ca abilitatea unei organizaţii de a obţine şi menţine competenţe critice prin modelul proceselor sale de adăugare a valorii şi prin structura sa organizaţională. Compania obţine toate competenţele necritice din exterior, adică de la alte companii, împreună cu care formează o întreprindere virtuală. De aceea, conceptual tinde să extindă din punct de vedere conceptual noţiunile de eficienţă şi eficacitate la mai multe companii, şi, de exemplu prin externalizare sau francizare, să lege resursele într-o companie fără să fie nevoie să investească pentru ele. Folosirea comună a capacităţilor de producţie, canalelor de distribuţie, aprovizionare şi a altor resurse (potenţate de posibilitatea de comunicare şi monitorizare prin TIC) conduce la reducerea costurilor globale, apariţia unui efect de sinergie, a economiilor de scală şi a creşterii calităţii) datorită încrederii, destinului comun. Un alt aspect benefic este schimbul de cunoştinţe legate de tehnicile de producţie eficiente din punct de vedere al costurilor, activităţile comune în domeniul cercetării dezvoltării bazate pe groupware, , videoconferinţe, etc. Ca urmare, apare producţia comună de bunuri şi servicii inovative, puternic orientate spre client. Accesul lărgit la informaţii, legate spre exemplu de modificarea cerinţelor clientului, reduce mult timpul de reacţie la schimbările de pe piaţă. Ambele efecte oferă protecţie faţă de produsele substitut, în cazul în care substituibilitatea produselor şi serviciilor este corelată negativ cu complexitatea acestora. Are loc o reducere a timpului şi costurilor de comunicaţie şi creşterea vitezei tranzacţiilor de plată prin mijloace electronice, ceea ce conduce la îmbunătăţirea rezultatelor financiare. 6

7 SCIPA - Stabilirea cerinţelor în contextual lumii reale 1 Modelarea proceselor de business Companiile investesc sume uriaşe în managementul proceselor de business. Majoritatea proceselor de business au fost documentate în vederea creării unor modelele de management complexe. Datorită volumului mare de informaţii şi transformărilor care au loc în domeniul IT&C, companiile se confruntă cu probleme care nu mai pot fi modelate şi tratate conform metodelor tradiţionale. În vederea soluţionării cât mai eficiente a problemei modelării proceselor de afaceri, au fost create ontologii, semantici web şi sisteme bazate pe agenţi inteligenţi. Pentru modelarea proceselor de business există o serie de limbaje care pot fi utilizate: UML şi BPMN. SCIPA îşi propune ca pornind de la unul dintre aceste limbaje (BPMN este candidatul preferat), să dezvolte o extensie care va include caracteristici precum: specificarea proceselor colaborative inter-întreprinderi şi utilizarea şabloanelor de cooperare, cât şi instrumente de modelare şi simulare asociate. Astfel se doreşte dezvoltarea unui model al proceselor de business care să permită adnotarea semantică a componentelor (pe baza unei sau mai multor ontologii ale cunoştiinţelor de business) şi modelarea aspectelor adaptive în funcţie de context şi mediul specific. Un astfel de model va fi privit sub forma unei diagrame care va surprinde toate etapele principale ale procesului, actorii implicaţi şi acţiunile întreprinse. În spatele componentelor acestei diagrame vor fi apeluri către webservice-uri care conţin funcţionalităţi specifice. Alături de această component grafică de bazat pe ontologii pornind de la BPML, un limbaj care să faciliteze regăsirea modelare, mediul de lucru va avea şi un limbaj de modelarea (Language Modelling) semantic informaţiilor (Querry Language, o extensie a BPMQ) şi instrumente de simulare şi adaptare a procesului modelat pe situaţii concrete de lucru. Modalitatea de lucru folosind soluţia propusă va fi intuitivă şi similară metodelor de modelarea ale analiştilor de business astfel încât utilizatorii obişnuiţi (fără cunoştiinţe solide de IT) să nu întâmpine dificultăţi. De asemenea, notaţiile şi reprezentările utilizate vor fi accesibile şi uşor de înţeles de către toţi utilizatorii din lumea de afaceri care participă la modelarea proceselor, începând cu analiştii care concep schemele iniţiale şi până la responsabilii tehnici care vor implementa aceste procese. Soluţia oferită va integra modelul adaptiv semantic bazat pe colaborare, cu funcţionalităţi care permit compunerea serviciilor cu agenţi cognitivi (practic pornind de la ontologiile dezvoltate pentru procesul de afaceri, împreună cu modelul adaptiv şi serviciile identificate se vor dezvolta sisteme inteligente) ce vor simula condiţiile reale din mediul de afaceri modelat. Pentru a modela corect un proces de afaceri este necesară parcurgerea următoarelor etape. 1.1 Modalitatea generală de lucru în vederea proiectării modelului de business Se va specifica o singură diagramă de proces. Această diagramă va fi uşor de utilizat şi înteles chiar şi de către persoanele care nu au experinţă în domeniul tehnic (de obicei managerii). De asemnea, această diagramă va fi suficient de expresivă pentru a permite modelarea proceselor de business foarte complexe care vor fi ulterior mapate uşor în limbajele de implementare, simulare şi execuţie. Pentru a modela un proces, utilizatorul va trebui să: 7

8 SCIPA - Stabilirea cerinţelor în contextual lumii reale identifice evenimentele importante din cadrul procesului de afaceri să modeleze evenimentele identificate să proceseze evenimentele care se execută să centralizeze rezultatele obţinute. La pasul următor, se identifică elementele de tip decizional, precum şi elementele de ramificare ale fluxului. Acestea se vor modela cu ajutorul unor elemente speciale denumite gateways. Aceste elemente vor fi similare cu blocurile decizionale din cadrul schemelor logice. De asemenea, un proces poate conţine la rândul lui alte subprocese, care vor fi reprezentate grafic prin intermediul unei alte diagrame conectate prin intermediul unei legături de blocul de tip proces care reprezintă părintele. Procesele care nu se vor descompune în alte subprocese sunt considerate task-uri (cel mai jos nivel de proces). Simbolizarearea grafică se realizează prin semnul + lângă numele procesului conform reprezentării specifice BPMN. Procesele care nu au acest semn sunt task-uri. Pentru a scpecifica cine ce face evenimententele şi procesele vor fi plasate în aşa zisele piscine care denotă cine execută procesul respectiv. Aceste elemente de grupare pot fi partiţionate la rândul lor. Spre exemplu, organizaţia poate reprezenta piscina, iar o subdiviziue a ei să fie un department sau o divizie. Evenimentele care se execută pot fi de mai multe tipuri şi complexităţi. Când se modelează fluxuri de proces mai complexe cum sunt serviciile web B2B se vor folosi evenimente mai complexe precum: mesaje, timere, reguli de business, condiţii de eroare,etc. În centrul modelării procesului de business se află chiar procesele care pot fi de trei tipuri: proces, subproces şi task. De aceea este foarte important ca utilizatorul să identifice corect procesele şi ieararhiile care se stabilesc între acestea încă de la începutul etapei de proiectare. Blocurile de decizie care modelează logica interacţiunii dintre procese vor a avea implementări specifice fiecărui tip de operator logic: sau, şi, sau-exclusiv. De asemenea, va exista o modelare specifică şi pentru deciziile complexe realizate prin compunerea oparaţiilor logice. Pentru modelarea cât mai aproape de realitate a proceselor de afaceri, există posibilitatea de a defini regulile după care se defăşoară. Sistemul nu permite crearea de legături între blocuri în situaţia în care sunt încălcate regulile respective. Astfel se reduce riscul de a introduce erori sau inconsistenţe logice în proiectarea modelului. Transformarea fluxului de date de-a lungul diagramei În cadrul organizaţiei, datele sunt transformate prin intermediul proceselor. Spre exemplu, un proces de tip comandă determină crearea unei comenzi. Atunci când produsul este livrat către consumator comanda a fost realizată. Dacă apar inconsistenţe în modul de achitare al comenzii (informaţii eronate cu privire la datele despre cont, etc) se poate determina anularea comenzii. Clientul poate să îşi corecteze informaţiile legate de cont. Pentru modelarea datelor în cadrul unei diagrame de proces, se vor identifica principalele tipuri de date şi se vor utiliza obiecte de tip dată. Obiectele de tip dată sunt artefacte care reprezintă tipuri de elemente electronice şi fizice. Datele reprezintă în esenţă entităţi (corespunzătoare tabelelor din baza de date) sau clase (corespunzatoare modelelor orientate obiect care conţin date). 8

9 SCIPA - Stabilirea cerinţelor în contextual lumii reale Modelarea datelor poate fi opţională deoarece nu afectează în mod direct fluxul, ci mai degrabă oferă informaţii despre anumite procese. 1.2 Simularea proceselor Un model descris conform paşilor de mai sus reprezintă o descriere logică a fluxului. Pornind de la modelul realizat, se va putea defini semantica asociată. Totuşi, pentru a obţine rezultate optime această abordare trebuie sincronizată cu etapa de simulare a procesului. Simularea pentru un model, se referă la mimarea operaţiilor de business care se vor realiza, prin testarea pas cu pas a evenimentelor. Pe parcursul simulării vor fi înregistrate metrici de performanţă care vor fi ulterior analizate şi evaluate. Avantajul acestei etape este acela că reduce considerabil riscul de a comite erori cu consecinţe grave în mediul real de lucru. 1.3 Maparea modelului de business peste modelul lingvistic implementat cu ajutorul ontologiilor şi semanticii web Semantica utilizată în modelul lingvistic se bazează pe ontologii. Structura reţelei va fi similară cu cea din WordNet. Regulile semantice şi lexicale vor fi create pe baza unor euristici conform regulilor lingvistice şi a logicii economice. Modelul lingvistic va avea la bază limbajul XML pentru modelarea şi structurarea informaţiilor. În prezent, majoritatea modelelor lingvistice utilizează XML-ul şi sunt construite peste limbajul de descriere al serviciilor web (WSDL) conform standardelor W3C. Fluxul major din cadrul WSDL este acela că limbajul amestecă descrierea interfeţelor statice cu legarea informaţiilor de anumite protocoale de comunicare. Prin intermediul modelului lingvistic sunt reprezentate: fluxurile de date; mesajele; evenimentele; regulile de afaceri; excepţiile; tranzacţiile (distribuite, sincrone, asincrone, etc) Serviciile web În vederea implementării unui model de business, primul lucru care trebuie avut în vedere este modelul serviciilor web care conţin funcţionalităţile specifice fiecărui element al modelului. Serviciile web reprezintă baza pentru elementele descrise anterior. Această etapă va avea la rândul ei 5 subetape: proiectarea procesului de afaceri dezvoltarea serviciilor care să implementeze funcţionalităţile pentru componentele modelului simularea procesului şi relizarea anumitor modificări în vederea sporirii eficienţei publicarea serviciilor modelarea serviciilor în concordanţă cu procesele de business prin asamblarea şi coordonarea comportamentului lor. 9

10 SCIPA - Stabilirea cerinţelor în contextual lumii reale Exemple de diagrame realizate cu pentru modelarea proceselor de afaceri cu BPMN A. modelarea procesului de licitaţie Figura 1. Procesul de afaceri din cadrul unei licitaţii [ORJ03] B. Modelarea procesului de afaceri pentru rezervarea biletelor Figura 2. Rezervarea biletelor [2] Modelarea proceselor de business este o etapă esenţială în cadrul unei organizaţii. Cu ajutorul acestor modele se vor putea valorifica mai uşor şi mai eficient experienţele anterioare. De asemenea, datorită faptului că se va utiliza un limbaj intuitiv, concis şi clar pentru reprezentarea proceselor, evenimentelor, datelor, etc în cadrul unui flux de afaceri, toate persoanele implicate (de la analiştii de afaceri la persoanele tehinice care vor implementa software-ul necesar) vor putea înţelege logica din spatele procesului modelat. 10

11 SCIPA - Stabilirea cerinţelor în contextual lumii reale Cu ajutorul modelelor grafic, lingvistic şi de simulare a procesului se vor putea crea mai uşor reguli de business care vor reprezenta baza de cunoştiinţe a sistemului inteligent care va sprijini managementul organizaţiei în procesul decizional. 11

12 SCIPA - Stabilirea cerinţelor în contextual lumii reale 2 Analiza procesului de afaceri pentru construirea ontologiilor Toate tehnicile de analiză bazate pe metoda proces-activitate presupun analiza afacerii pentru a obţine informaţii semantice referitoare la activităţile efectuate şi modul de transfer al informaţiilor între activităţi. O serie de activităţi legate între ele formează un process. Tehnicile bazate pe metoda process- activitate pot fi grupate în 3 mari categorii: Cost/preţ/profit: Cost per activitate, Cost per produs sau serviciu, Preţ per produs sau serviciu, Profitul pieţei/canalului/sectorului sau clientului, Preţul de transfer. Creşterea performanţelor: Planificarea proceselor şi activităţilor Reducerea costurilor, Analiza valorii, Eliminarea constrângerilor, Reingineria procesului de afaceri, Integrarea fluxului de procese, Benchmarking. Gestiunea performanţelor curente: Gestiunea bazată pe valoare, Măsurarea şi gestiunea performanţelor, Evaluarea la nivelul serviciului, Bugetare bazată pe activitate, Bugetare bazată pe prioritate, Bugetarea şi contabilizarea resurselor (în sectorul public), Benchmarking, Cea mai bună valoare, Contabilizarea bazată pe process, Integrarea fluxului de procese. Utilizarea acestor tehnici transcede orice sector al industriei. Această metodă poate fi aplicată la orice nivel al unei organizaţii, la colaborarea între organizaţii, oricărei activităţi care consumă resurse. 2.1 Metodologie de analiză de tip proces-activitate Pentru realizarea analizei de tip activitate-proces se pleacă de la structura organizaţională a companiei. Reprezentanţii fiecărui centru cu buget propriu din structura organizaţională a departamentului sau unităţii de afaceri analizează activitatea realizată şi operaţiile din cadrul activităţii desfăşurate. Operaţiile şi activităţile sunt grupate în fluxuri de activităţi formând sub-procese, acestea putând fi legate de procesele de bază ale afacerii. Procesele de bază sunt acele procese care definesc scopul existenţei organizaţiei, procesele care au ca efect obţinerea serviciilor sau produselor pe care compania le oferă. Toate activităţile şi sub-procesele desfăşurate în cadrul 12

13 SCIPA - Stabilirea cerinţelor în contextual lumii reale companiei trebuie să contribuie la aceste procese de bază în diferite moduri. Acest tip de analiză clarifică tipurile de relaţii şi permite înţelegerea modului în care funcţionează afacerea. În acest model de analiză numărul nivelurilor ierarhiei variază considerabil în funcţie de mărimea organizaţiei şi de nivelul de detaliere cerut pentru a atinge obiectivele definite şi pentru extragerea semanticilor. Departamente (unităţi) Centre de cost (zeci) Activităţi (sute) Operaţii (mii) Figura 3. Structura ierarhică a organizaţiei Ierarhia care arată relaţiile şi contribuţiile la produsele şi serviciile finale este reprezentată în figura 4. Procese de bază (unităţi) Sub procese (zeci) Activităţi (sute) Operaţii (mii) Figura 4. Ierarhia modelului proces-activitate Având ca exemplu activitatea unei agenţii imobiliare, structura organizaţională a agenţiei imobiliare este prezentată pe verticală şi procesele de bază pe orizontală, în figura 5. Diagrama din figura 5 prezintă modul în care departamentele din structura organizaţională contribuie la procesul de bază prin intermediul sub-proceselor pe care le realizează. Procesele reprezintă o serie de activităţi care produc o anumită ieşire şi ignoră toate barierele funcţionale. 13

14 SCIPA - Stabilirea cerinţelor în contextual lumii reale Agenţie imobiliară Regiunea 1 Regiunea 2 Financiar Conducerea agenţiei Regiunea 3 Secretariat Furnizarea de servicii Serviciile agenţiei direcţionate către Dezvoltare utilizator Cinci departamente structurate fizic în 3 regiuni şi zeci de zone Figura 5. Diagrama contribuţiei departamentelor la procesul de bază În Figura 6, este exemplul sistemului şi al sub-procesului de distribuţie de produse văzut ca un sub-proces care contribuie la dezvoltarea infrastructurii, aceasta contribuind la rândul ei la dezvoltarea proceselor de bază. Figura 6 arată că un sub-proces este format dintr-un flux de activităţi, fiecare putând fi analizată în fluxul de operaţii care compun activitatea. Dacă este necesar, fiecare operaţie poate fi împărţită în sub-operaţii. Toate operaţiile sunt formate dintr-un număr de subprocese, unele dintre acestea fiind de tip suport şi sunt comune majorităţii organizaţiilor precum: aprovizionare, recrutare de personal, gestiunea informaţiilor. Alte operaţii sunt specifice domeniului analizat, şi formează o listă de aşteptare. Nivelul activităţilor Analiza afacerii Sistemul de dezvoltare Sistemul de testare Documentare Sistemul de distribuţie Nivelul operaţiilor Analiza iniţială Justificarea costurilor Scrierea specificaţiilor afacerii Agregarea specificaţiilor Dezvoltarea sistemului Figura 6. Analiza sistemului şi a sub-proceselor în procesul de livrare 14

15 SCIPA - Stabilirea cerinţelor în contextual lumii reale 2.2 Colectarea informaţiilor despre activităţi şi procese În funcţie de activităţile şi procesele folosite, datele trebuie colectate de la persoanele care participă la realizarea activităţilor din fiecare centru de buget sau sub-proces. Informaţile înregistrate sunt folosite pentru construirea semanticilor activităţilor şi proceselor descrise şi pot fi referitoare la: Activităţile şi operaţiile efectuate, Fluxul de relaţii dintre activităţi sau procese, Intrările şi ieşirile activităţilor sau proceselor şi unităţile lor de măsură, Resursele consumate, ca de exemplu: timp, spaţiul de birouri folosit (depinde de tipul de resurse), Alocarea per produs, serviciu sau client (depinde de tipul de activităţi), Factorii care influenţează performanţa procesului sau activităţii (depinde de cost), Măsurarea performanţei (criterii financiare şi non-financiare, cantitative şi calitative), Obiective şi responsabilităţi per activitate sau process, Clasificarea activităţii (de bază, suport, divers), Servicii alternative, Idei de îmbunătăţire. Metode de colectare a datelor pentru semantici Există o serie de metode care pot fi folosite pentru colectarea datelor în vederea construirii semanticilor. Principalele surse pentru date sunt: Sistemele de pontaj - pentru identificarea resurselor, Sistemele informaţionale ale organizaţiei pentru identificarea activităţilor, ieşirilor şi parametrilor non-financiari, Sistemele informaţionale financiare pentru costuri, materiale şi bugete, Sistemul de resurse umane - pentru structuri organizaţionale, informaţii despre persoane şi salarii, Centrul de cost al departamentului sau procesului analizat (activităţi, relaţii, fluxuri, costurile implicate, intrări şi ieşiri). Principalele metode de colectare a datelor sunt: Metoda observaţiei, Grupuri de discuţii folosite pentru a obţine sugestii pentru analiza activităţii sau procesului ultile când se încearcă obţinerea rapidă de informaţii iniţiale, Preluarea informaţiilor din alte sisteme informatice, Interviuri, Aplicarea de chestionare. 2.3 Gestiunea lanţului de activităţi aprovizionare-desfacere caz utilizator Gestiunea lanţului de activităţi de la aprovizionare până la desfacere presupune controlul și coordonarea tuturor activităţilor unei organizaţii de la furnizorii de produse la clienţii săi. 15

16 SCIPA - Stabilirea cerinţelor în contextual lumii reale Lanţul de aprovizionare poate fi împărţit în două componente: lanţul superior componenta de cumpărare a comerului electronic lanţul inferior componenta de vânzare a comerţului electronic. Furnizorii Partenerii Intermediari Intermediari Partenerii Clienţii furnizorilor furnizorilor la cumpărare la vânzare clienţilor clienţilor Client 1 Furnizor A Client 2 Furnizor B Furnizor C Schimb B2B Distribuitor/ agent Aplicaţii web ERP, CRM, SCM Web Instrumente şi servicii Vânzător cu amănuntul Distribuitor/ agent Client 4 Client 3 Partener 1 Partener 2 Lanţul superior Lanţul inferior Figura 7. Reţele de lanţuri de activităţi de la aprovizionare la desfacere Figura 7 prezintă cele două părţi ale lanţului de activităţi de la aprovizionare la desfacere împreună cu legăturile cu partenerii şi furnizorii precum şi cu furnizorii, partenerii şi clienţii acestora. După fabricare, produsele sunt transmise prin lanțul de distribuţie aprovizionare-desfacere. Când se implică clientul se vorbește despre un canal de tip cerere care îţi bazează toate resursele, inclusive producţia, vânzările, marketing-ul, cercetarea, dezvoltarea şi serviciile pe cererile clienţilor. Modelul de afaceri axat pe cerere foloseşte o serie tehnologii, precum previziuni, cercetări de piaţă şi business intelligence pentru îmbunătăţirea canalului cererii şi pentru a putea răspunde comportamentului actual al consumatorului. Toate aceste tehnici se pot folosi pentru construirea semanticilor asociate acestor activități. 8. Principalele caracteristici ale lanțului aprovizionare-desfacere sunt prezentate în figura Rezultatele estimate sunt: creşterea încasărilor şi profitului, reducerea stocurilor, îmbunătăţirea gestiunii produselor. 16

17 SCIPA - Stabilirea cerinţelor în contextual lumii reale Furnizor Creşterea eficienţei Scop: reducerea costurilor în lanțul de distribuție Elemente cheie: controlul pe termen scurt al resurselor și al constrângerilor legate de capacități Rezultate: dezvoltarea parteneriatelor și afacerilor electronice Client Creșterea valorii adăugate Scop: identificarea soluților pentru creșterea profiturilor obținute de clienți Elemente cheie: planificare pe termen lung, realizarea de cercetări de piață și business intelligence Rezultate: îmbunătățirea gestiunii la nivel de produs, reducerea stocurilor Figura 8. Caracteristici ale lanțului aprovizionare distribuție Un sistem de gestiune a lanțului aprovizionare-desfacere este format din următoarele 5 componente: Planificarea dezvoltarea unei strategii pentru gestiunea lanțului aprovizionare-desfacere în vederea obținerii eficienței maxime, Sursa - implică selectarea furnizorilor de bunuri și servicii necesare în lanțul aprovizionare-desfacere; gestiunea relațiilor, stabilirea regulilor de plată, de livrare și de calcul al prețurilor. Producția acoperă planificarea cererii, fabricarea, asamblarea, testarea, împachetarea și crearea stocurilor de produse. Livrarea se referă la recepționarea cererilor clienților, depozitarea, selectarea și livrarea, facturarea și plata. Retururi presupune crearea proceselor pentru gestiunea bunurilor returnate de clienți, inclusiv a celor care necesită reparații. 17

18 SCIPA - Stabilirea cerinţelor în contextual lumii reale 3 Cerinte ale unei platforme de interoperabilitate bazate pe semantici, ontologii si reguli de afaceri 3.1 Testarea compatibilitatii regulilor de afaceri corespunzatoare organizatiilor implicate intr-o solutie de interoperabilitate Regulile de afaceri se referă la multitudinea de politici, proceduri sau definiţii care guvernează modul de funcţionare al unei organizaţii, împreună cu interacţiunea acesteia cu furnizorii si beneficiarii săi. Reiese ca orice interoperabilitate trebuie sa asigure respectarea sistemului de reguli de afaceri ale fiecarui participant intr-o solutie de interoperabilitate. Este important de făcut deosebirea dintre strategii şi reguli de afaceri, în sensul că regulile reprezintă fundamentul pe care se construiesc strategiile, inclusiv cele de cooperare Una dintre primele definitii ale regulii de afaceri ofera o perspectiva foarte interesanta din punctul de vedere al demersului cercetarii noastre: O regula de afacere este o declaraţie explicită a unei constrângeri care există în cadrul ontologiei afacerii (Daniel S. Appleton (1984), [APL84]). Completitudinea si coerenta sistemului de reguli de afaceri la nivelul unei organizatii cade in sarcina organizatiei; in cazul unei platforme de colaborare, compatibilizarea regulilor de afaceri dupa care se conduc partenerii cade in sarcina platformei. 3.2 Integrarea semanticii vocabularului regulilor de afaceri Fara a intra in detalii privind conceptualizarea si formalizarea regulilor de afaceri, nu putem omite ca o solutie de interoperabilitate bazata pe agenti va avea ca suport informatia oferita de sistemele informatice ale partenerilor implicati, impreuna cu dictionarul semantic al domeniului de business. Din acest unghi de vedere, devine interesanta conceptualizarea propusa de Zachman, pentru dezvoltarea sistemelor informatice ([ZAC87].) si alinierea lor la strategia de business. Conform lui, arhitectura unui sistem informatic este determinată de strategia de afaceri, deci de obiectivele şi rezultatele aşteptate ale organizaţiei. Astfel, el identifică două modalităţi de reprezentare care, atunci când sunt utilizate în combinaţie, descriu precis natura şi scopul acestor rezultate în contextul organizaţiei. Aceste modalităţi de reprezentare sunt: Perspectiva umană, care are în vedere diferitele viziuni ale persoanelor implicate în dezvoltarea sistemului. Au fost identificate trei viziuni arhitecturale fundamentale: Modelul de business (business view), Modelul de proiectare (designer s view), Modelul tehnologic (builder s view) împreună cu trei orientari pentru etapele de dezvoltare ale sistemului: Scopul (scope view), Prezentarea detaliată (out-of-context view) şi Viziunea operaţională (operational view). Tipurile de abstractizări ce descriu fiecare perspectivă sunt folosite pentru a detalia caracteristicile relevante si pentru a pune accentul pe diferite aspecte ale sistemului. Au fost identificate şase tipuri de abstractizări: Datele (what? ), Funcţiile (how? ), Reţeaua (where? ), Factorul uman (who?), Timpul (when? ) şi Motivaţia (why? ). Ca parte a unui consorţiu format din 17 organizaţii, cunoscut sub denumirea de The Business Rules Team (BRT), Business Rules Grup (BRG) a participat la propunerea venită din partea Object Management Group (OMG) de a analiza semantica regulilor de afaceri din perspectiva afacerii. Răspunsul BRT, denumit Semantica Regulilor şi a Vocabularului 18

19 SCIPA - Stabilirea cerinţelor în contextual lumii reale Afacerii, (Semantics of Business Vocabulary and Business Rules - SBVR), reprezintă un studiu exhaustiv privind semantica vocabularului afacerii şi a regulilor de afaceri, în care s-au avut în vedere următoarele aspecte [OMG06]: Orientarea spre afacere, în sensul că nu se fac referiri la sisteme informatice sau la concepte specifice acestora, ci se concentrează exclusiv asupra modului în care gândesc oamenii de afaceri. Regulile de afaceri sunt integral specificate pornind de la vocabularul afacerii. Semantica regulilor de integritate trebuie să se bazeze pe logica predicatelor. Folosirea vocabularului afacerii ca element de comunicare intre oamenii de afaceri (în calitate de clienţi ) si specialiştii în informatică (în calitate de furnizori de servicii ), comunicare concretizata sub forma specificaţiilor cerinţelor sistemului. 3.3 Compatibilizare la nivel de procese de afaceri. Interpretarea abstracta si concreta a unui proces de afaceri Desi aparent cooperarea intre firme n-ar trebui sa implice cunoasterea detaliilor privind procesele de afaceri, ci numai "interfetele" lor, in realitate pot exista constrangeri privind procesele tehnologice, succesiunile de activitati, calitatea output-urilor etc. Spre exemplu, un proces tehnologic nu poate utiliza decat o materie prima de o anume calitate sau obtinuta la randul ei numai printr-un anumit proces tehnologic. Agentul de negociere a unei cooperari trebuie sa aiba capacitatea abstractizarii unui proces de afaceri, sa inceapa cautarea cu semantica nivelului cel mai abstract, procedand apoi la particularizari specifice unui domeniu de afaceri. Pe nivelul cel mai inalt, un proces de afaceri se defineste ca ansamblu de activitati interconectate, care folosesc oameni, informatii si resurse tehnologice pentru a crea valoare adaugata pentru clienti. Intr-o reprezentare schematica (figura 9), cinci sunt componentele de baza care afecteaza procesul de afaceri: Clientii, care influenteaza proiectarea si realizarea produselor, intr-o strategie customer oriented; Produsele, Tehnologia; Informatia si Participanti. O interoperabilitate pe criterii semantice la nivelul resurselor de business trebuie sa porneasca de la acest nivel, explorand ontologiile procesului si identificand formele specifice de manifestare (tipuri de produse, profesii implicate, tehnologii existente, cunostiinte obtinute pe baza informatiilor). 19

20 SCIPA - Stabilirea cerinţelor în contextual lumii reale CUSTOMERS Internal / external customers PRODUCTS Specific output or result used directly by customers Major steps BUSINESS PROCESS Basic approach Related activities that combine to create value for customers Sumarized in terms of basic approach PARTICIPANTS People who enter or use information INFORMATION Numbers, text, sounds Pictures nforms to customers TECHNOLOGY Computers Telecommunications system Software Figura 9. Reprezentarea abstracta a unui proces de afaceri [ALT 96] 3.4 Urmarirea gradului de aliniere a sistemului informatic la strategia firmei Schimbarile majore din sistemele informatice ale firmelor se produc ca urmare a schimbarilor din procesele de afaceri. La proiectarea unei platforme de interoperabilitate trebuie sa se tina seama de directia evolutiei, pentru a asigura adaptabilitatea. Pentru a aprecia gradul de aliniere a sistemului informatic la strategia firmei. Intotdeauna se incepe cu clientii urmarindu-se adaptarea produselor la asteptarile acestora; se continua cu analiza procesului de business care sa permita obtinerea produselor dorite; abia apoi sunt deduse tehnologiile necesare, informatiile si tipul participantilor la un astfelde proces. Corelarea se produce in ambele sensuri şi poate fi apreciata la un moment dat (static ), dar si in dinamica, cand o modificare a unui element atrage schimbari in lant (produse noi care presupun schimbari tehnologice, training pentru adaptare la noua tehnologie, achizitia de noi informatii si cunostinte). 3.5 Impactul adaptabilitatii proceselor de afaceri asupra proiectarii platformei de interoperabilitate Cunoasterea flexibilitatii si limitelor proceselor tehnologice, dar si a sistemelor informatice de a se reconfigura pe masura schimbarilor din mediu de afaceri, reprezinta un criteriu esential in selectarea oportunitatilor si posibilitatilor de cooperare intre firme. Teoretic, arhitectura SOA incapsuleaza integral un domeniu de business; maniera in care o face este insa esentiala si depinde de abilitatea celui care modeleaza. In principiu, se urmareste gasirea unui echilibru intre diminuarea numarului de dependente dintre servicii (deoarece la un numar mare de interactiuni, modificarea unui serviciu antreneaza modificari 20

21 SCIPA - Stabilirea cerinţelor în contextual lumii reale in cascada in alte servicii) si evitarea unei granularitati exagerate, care ar conduce la o complexitate prea mare a sistemului. Alegerea unui nivel optim de descompunere a proceselor pe servicii asigura posibilitatea reconfigurarii sistemului prin compunerea serviciilor existente si doar rareori scrierea de noi servicii. 3.6 Orientarea tehnologica a platformei Solutia de interoperabilitate trebuie sa fie orientata spre noile tehnologii de realizare a sistemelor informatice pentru afaceri, urmand ca sistemele mostenite (legacy systems) sa beneficieze de facilitatile unei astfel de platforme numai dupa expunerea functionalitatii lor prin servicii. Odata realizata aceasta transpunere, modificarea sau rescrierea totala a unei functionalitati nu mai afecteaza ulterior schema de colaborare intre functii si nici intre firme. 3.7 Identificarea nevoilor si ofertelor de cooperare Asa cum se cunoaste, un contract SOA specifica in principal: functionalitatea asigurata prin serviciu; input-urile cu care lucreaza serviciul si output-urile furnizate clientului; preconditiile si post-conditiile gestiunea erorilor calitatea serviciului si garantii oferite. Dintre toate, functionalitatea este cea care sta la baza initierii unei colaborari, deoarece este direct legata de un proces sau subproces de business, iar colaborarile inter-firme urmaresc in primul rand asigurarea unei functionalitati. Input-urile si output-urilor vor fi luate in considerare doar in masura in care cerintele de colaborare au o specificitate aparte sau functionalitatea cunoaste o diversitate mare de implementari. O atentie speciala la cautari pe baza de semantici trebuie acordata sinonimelor, care prin acelasi termen desemneaza functionalitati dintre cele mai variate. 3.8 Identificarea sabloanelor de colaborare agreate de o firma Platforma trebuie sa dispuna de un set de sabloane de colaborare folosite uzual in domeniul afacerilor. Se includ aici modele incepand cu simple acorduri de colaborare, comenzi ferme emise in baza unor acorduri, contracte, pana la conventii prin care o firma preia atributii decizionale pe un segment limitat de competente dintr-o alta firma (spre exemplu, o firma furnizoare declanseza un proces de aprovizionare a unui supermarket). 3.9 Alegerea celor mai influenti agenti economici din lantul de creare a valorii noi adaugate. Avand in vedere ca procesul de creare a valorii adaugate este un flux, profitul unei firme depinde nu numai de performantele firmei si competitorilor, ci si de eficienta cu care opereaza furnizorii si beneficiarii: acest lucru se explica prin faptul ca valoarea adaugata se redistribuie prin preturi intre participanti, pe intreg lantul in care e creata (Porter, 1985). In consecinta, la alegerea partenerilor de afaceri, firma este interesata sa colaboreze cu cei mai influenti si eficienti participanti din lantul de creare al valorii adaugate. Platforma de interoperabilitate trebuie eventual sa permita utilizatorilor sa adere la anumite lanturi de creare a valorii nou adaugate. 21

22 SCIPA - Stabilirea cerinţelor în contextual lumii reale Furnizor Furnizor Componente / semifabricate Comanda ferma Produse finite Proiectare Proiectare Prototip Productie Productie Prognoze Vanzari Vanzari Livrari Livrari Service Service Preferinte Facturi Produse finite Cereri Service Clienti Clienti Echipamente / informatii Figura 10. Firma vazuta ca o succesiune de cinci procese de afaceri 22

23 SCIPA - Stabilirea cerinţelor în contextual lumii reale 4 Soluţii de cooperare virtuală pentru mediu de afaceri Noua economie digitală, bazată pe Internet este o economie a afacerilor clădite în jurul serviciilor Internet şi a reţelelor electronice, o economie în care apar noi forme de companii şi noi forme de muncă. În noua economie se observă o schimbare a paradigmelor legate de producţie şi management care însoţeşte trecerea de la societatea industrială la societatea informaţională şi este ilustrată în următoarele tabele. Producţie de masă Produse şi servicii flexibile, adaptate cererii clienţilor Producţia de bunuri Producţia de servicii Produse tangibile Produse intangibile,digitale,dematerializate Ciclu de producţie lung Ciclu de producţie mai scurt datorită inovării permanente Piaţă naţională Piaţă globală Avantaj comparativ Avantaj competitiv Tabelul 1. Schimbarea principalelor paradigme ale proceselor de producţie Centralizare Ierarhie rigidă Structuri tip companie Descentralizare şi delocalizare Organizare flexibilă Companii orientate pe proiecte şi companii virtuale Lanţ de activităţi Suntem separaţi şi rivali Organizare tip reţea şi eliminarea intermediarilor Suntem conectaţi şi putem coopera Tabelul 2 Schimbarea principalelor paradigme ale organizării şi managementului companiilor Imaginea unui nou tip de organizaţie, organizaţia virtuală a fost mult vehiculată de la apariţia cărţii lui Malone şi Davidow în 1992 [MDa92]. Mulţi autori au prezentat o imagine puternic pozitivă a organizaţiilor virtuale şi au înaintat ipoteza unei acceptări largi şi rapide a acestora. Organizaţiile virtuale pot fi definite ca reţele temporare de companii independente furnizori, clienţi, competitori interconectate prin tehnologia informaţiei pentru a partaja competenţe, costuri şi acces la pieţele celorlalţi [BBB93]. Aflaţi la începutul secolului 21, nu observăm ca această viziune să fi fost pusă în practică pe scară largă, şi nici măcar să se fi atins o acceptare comună a acestei forme de organizare. Ba chiar există autori care văd în organizaţiile virtuale doar o etapă intermediară în tranziţia spre ceea ce ei numesc întreprindere bazată pe Internet ( internetworked enterprise ) care va apărea într-o comunitate viitoare a afacerilor electronice. Întreprinderile virtuale sunt create pentru a veni în întâmpinarea unor anumite oportunităţi ivite pe piaţă şi sunt dizolvate în momentul în care oportunitatea dispare. Integrarea virtuală, opusă integrării verticale, va fi probabil fundamentul pentru o strategie de afaceri competitivă în acest secol. Pot fi găsite multe motive pentru proiectarea organizaţiilor 23

24 SCIPA - Stabilirea cerinţelor în contextual lumii reale virtuale sau pentru organizarea activităţilor într-o organizaţie virtuală în locul unei organizaţii tradiţionale. În principal, aceste motive se reduc la: Nevoie sporită de flexibilitate, în raport cu care competenţele principale necesare pot fi obţinute doar în colaborare cu parteneri externi. Flexibilitatea a devenit o necesitate din cauza schimbărilor rapide care au loc în mediul organizaţiilor. De o bună perioadă de timp se observă că organizaţiile se concentrează pe nişte competenţe principale, pe activităţile la care sunt bune. Crearea de valoare adăugată pentru client a devenit un proces tot mai complex şi presupune combinarea unui numar mare de tipuri de cunoştinţe. În această situaţie, într-un grup de organizaţii, acestea au nevoie de cunoştinţele celorlalte pentru a produce bunuri şi servicii şi formează împreună o organizaţie virtuală. Acesta este de fapt cel mai puternic motiv pentru care partenerii lucrează împreună: partajarea competenţelor principale ale fiecăruia şi combinarea cunoştinţelor acestora astfel încât să se genereze un proces inovativ. Nevoia de eficienţă sporită prin partajarea resurselor cu partenerii. Pentru a putea reacţiona la cerinţele mediului de afaceri, se pare că colaborarea a devenit un factor tot mai important. Avantajele de scală şi de experienţă pot fi mai bine folosite când partenerii partajează resurse, ceea ce conduce la creşterea eficienţei şi competitivităţii, şi pe de altă parte are loc şi o reducere a riscurilor, prin difuzia acestora. 4.1 Structuri virtuale Caracteristic oricărui obiect virtual este posibilitatea formării şi dizolvării legăturilor dintre părţile componente pentru a reacţiona rapid şi eficient la diferitele probleme ce apar în sistem sau în mediul său înconjurător Biroul virtual Biroul virtual defineşte companie sau un parteneriat de natură permanentă, dar care are un număr important de angajaţi la distanţă. Biroul virtual îndeplineşte rolul biroului tradiţional, centralizat, dar pe de altă parte, angajaţii lucrează în birouri aflate la domiciliu, şi colaborează în cea mai mare parte a timpului electronic, venind doar ocazional în contact cu ceilalţi angajaţi. De obicei, birourile virtuale sunt consorţii (au personalitate juridică), iar consorţiile nu ţin cont de localizarea geografică a angajaţilor. Chiar şi în birourile tradiţionale, multe dintre relaţiile de afaceri se desfăşoară în medii distribuite, de exemplu clienţii şi furnizorii se află în locuri diferite, cei care lucrează împreună într-un proiect pot aparţine unor divizii diferite, etc. Atât în cazul biroului tradiţional, cât şi în cazul birului virtual, misiunea organizaţiei rămane aceeaşi, dar procedurile se schimbă în al doilea caz, adaptându-se colaborării la distanţă Întreprinderea virtuală Întreprinderea virtuală pleacă de la conceptul de organizaţie reţea, concept foarte general, care se referă la orice grup de organizaţii interconectate printr-o reţea de calculatoare, fără a fi necesar ca acestea să partajeze abilităţi, resurse, procese sau scopuri. Întreprinderea virtuală este o reţea, mai mult sau mai puţin temporară, alcătuită din întreprinderi sau persoane independente din punct de vedere juridic care care îşi unesc bunurile, competenţele şi alte resurse în scopul realizării unui proiect comun care depăşeşte capacităţile fiecăreia dintre unităţi luată individual în ceea ce priveşte posibilitatea de a exploata oportunităţile volatile, de a avea acces la noi pieţe şi de a partaja costurile şi riscurile, 24

25 SCIPA - Stabilirea cerinţelor în contextual lumii reale întreagă această suprastructură bazându-se pe noile tehnologii ale informaţiei şi telecomunicaţiilor. Procesele legate de funcţionarea afacerii şi de realizarea produselor sunt dispersate în diferitele companii partenere. Acestea sunt distribuite în diverse ţări şi au o cooperare strânsă. Fiecare dintre aceste companii se distinge prin produsele, procesele, competenţele sale principale, unice. Întreprinderea virtuală este alcătuită din aceste companii independente şi beneficiază de competenţele lor centrale pentru a câştiga oportunităţi importante de piaţă care nu pot fi obţinute de companii de unele singure. Figura 11. Întreprinderea virtuală Acest tip de organizaţie poate fi realizată şi dezasamblată rapid ca răspuns la schimbarea rapidă a oportunităţilor. Această proprietate face întreprinderea virtuală cel mai promiţător tip de organizaţie pentru secolul 21. În general, tehnologia necesară unei întreprinderi virtuale este similară celei dintr-o întreprindere centralizată, dar există câteva diferenţe: deseori întreprinderile virtuale sunt birouri virtuale, aşadar e vorba de medii distribuite; trebuie să satisfacă anumite cerinţe legate de partajarea proprietăţii intelectuale înafara organizaţiei; pot să fie temporare. Un concept înrudit este întreprinderea extinsă, care se aplică în cazul în care o întreprindere îşi extinde limitele peste o parte din furnizorii săi, în timp ce întreprinderea virtuală poate fi văzută ca un concept mai general, prin care se include alte organizaţii într-o structură în care comunicarea se face peer-to-peer. Având în vedere aceste aspecte, întreprinderea extinsă poate fi considerată un caz particular de întreprindere virtuală. 25

26 SCIPA - Stabilirea cerinţelor în contextual lumii reale Organizaţia virtuală O organizaţie virtuală (sau organizaţia cu structură organizatorică virtuală) este formată din unităţi organizatorice distribuite care participă la un proces de muncă coordonat, divizat, unităţi ce sunt părţi ale unei reţele complexe susţinute de tehnologii informaţionale corespunzătoare. Conceptul de organizaţie virtuală este oarecum similar celui de întreprindere virtuală, ea incluzând o reţea de organizaţii care partajează resurse şi abilităţi pentru a-şi realiza scopurile, dar fără a fi limitată la întreprinderi. De exemplu, municipalitatea virtuală care integrează prin intermediul unei reţele de calculatoare toate organizaţiile la nivelul municipalităţii: serviciile de distribuţie a apei, serviciile de întreţinere a spaţiilor verzi, de producere şi distribuţie a energiei termice, de salubrizare, etc. Întreprinderea virtuală reprezintă un caz particular de organizaţie virtuală [DHa98] Organizaţia virtuală include atât birourile virtuale, cât şi întreprinderile virtuale. Acest termen poate fi aplicat şi unor organisme de standardizare, consorţii sau proiecte de cercetare. Organizaţii reţea Organizaţii virtuale Întreprinderi virtuale Întreprinderi extinse Echipa virtuală Figura 12. Relaţii între tipuri de organizaţii Pornind de la definiţia biroului virtual, putem defini echipa virtuală ca fiind construită pentru situaţii în care membrii săi sunt distribuiţi geografic. Atât biroul, cât şi echipa virtuală presupun membrii distribuiţi, aşadar au nevoie de infrastructură similară şi vor necesita planificare şi executare a sarcinilor într-un mediu cu restricţii de resurse. În cazul biroului virtual, acesta este relativ permanent, cu membrii stabili, cu resurse stabile şi o cultură de întreprindere comună, formată în ani de zile. În cazul echipei virtuale, membrii se adaugă sau pleacă în mod dinamic, contextual comun trebuie transmis cât mai repede, situaţiile se schimbă rapid. La prima vedere pare necesară eliminarea rapidă a barierelor de comunicare şi formarea unui mediu collaborative, dar este suficient un mediu bine înţeles, cu structură modulară, care poate fi rapid configurat pentru a se adapta unor cerinţe variate după cum se schimbă situaţiile şi tehnologiile disponibile. 4.2 Caracteristicile întreprinderii virtuale Atunci când mai multe companii îşi combină specialiştii pentru a crea un produs, rezultatul poate fi numit întreprindere virtuală (ÎV). După cum s-a spus, o întreprindere virtuală este, prin definiţie, o alianţă de întreprinderi care conlucrează pentru a partaja abilităţi 26

27 SCIPA - Stabilirea cerinţelor în contextual lumii reale sau competenţe centrale şi resurse pentru a răspunde mai bine la oportunităţile ivite pe piaţă, cooperarea având la bază o reţea de calculatoare şi o arhitectură cooperativa, distribuită a sistemelor informatice. O întreprindere virtuală emergentă [THT02] merge un pas mai departe, asigurând o monitorizare continuă a performanţelor sale şi a pieţei pentru a-şi îmbunătăţi performanţele şi eficienţa, adică verifică în permanenţă dacă există parteneri disponibili pe piaţă care ar putea fie să-i înlocuiască pe cei existenţi, fie să contribuie la obiectivele globale într-o manieră pozitivă. Această caracteristică poate conduce la schimbări organizaţionale frecvente care trebuie reflectate prin schimbări corespunzătoare ale sistemelor informatice. Deşi există numeroase definiţii pentru întreprinderea virtuală, nici una nu este unanim acceptată. Întreprinderea virtuală este o reţea temporară de cooperare a unor companii, instituţii sau indivizi independenţi care se unesc rapid şi participă cu competenţele lor centrale pentru a exploata o oportunitate de piaţă. Deşi întreprinderea virtuală refuză instituţionalizarea nu are birou central, ierarhie sau integrare verticală partenerii autonomi acţionează ca o singură corporaţie pentru cei din exterior. Deoarece cooperarea este realizată prin intermediul tehnologiei informaţiei şi comunicaţiilor, structura sa organizaţională va fi fluidă şi flexibilă. Competenţele centrale sunt definite ca abilităţi, tehnologie şi know-how care sunt esenţiale pentru succesul companiei şi îi permit să obţină produse destinate pieţei. Esenţa organizaţiilor virtuale este metamanagementul activităţii orientate spre obiect într-o manieră independentă de mijloacele pentru realizarea acestei activităţi. Companiile întreprinderii virtuale împart costurile, abilităţile şi eficienţa pentru a avea acces pe piaţa globală. Cisco Systems este unul dintre cele mai cunoscute exemple de întreprindere virtuală care se concentrează pe dezvoltarea şi vânzarea de noi produse, lăsând toate celelalte activităţi pe seama partenerilor lor. Întreprinderea virtuală este o subdiviziune a reţelei de cooperare, a cluster-ului. Este o organizaţie ce se poate reconfigura, cu management propriu, resurse productive şi obiective de producţie proprii. Întreprinderea virtuală va combina activităţile de maximă eficienţă prin folosirea optimală a resurselor de producţie în concordanţă cu oportunităţile pieţei, indiferent de timp şi spaţiu. Are propria conducere şi se comportă ca o unitate economică individuală. Datorită cerinţelor specifice ale proiectului, întreprinderea virtuală poate conţine unităţi care nu aparţin reţelei, dacă abilităţile necesare nu sunt disponibile în reţea. În cadrul întreprinderii virtuale, resursele sunt alocate pentru realizarea unui anumit produs pe baza eficienţei şi disponibilităţii, fără a se lua în considerare locaţia geografică şi structura organizatorică. Unităţile sunt conectate într-un proces de producţie virtual realizat în cadrul unei singure unităţi, chiar dacă resursele sunt distribuite. Una dintre caracteristicile definitorii ale întreprinderii virtuale este natura sa oportunistă. Întreprinderile pot folosi strategia întreprinderii virtuale pentru întâmpinarea schimbărilor neaşteptate şi evenimentelor neprevăzute. Unul dintre beneficii este acela că pot deveni productive capacităţile neutilizate sau pentru care planificarea depăşeşte necesarul. Pentru tratarea cazului în care un anumit tip de capacitate este temporar indisponibilă, întreprinderea virtuală va include mai mulţi membrii cu aceleaşi capacităţi, creându-se o structură redundantă care conferă un plus de agilitate întreprinderii. În literatura de specialitate referitoare la teoriile organizaţionale nu există o definiţie unică şi unanim acceptată a organizaţiilor virtuale. Oricum, e foarte probabil ca o organizaţie să nu îndeplinească aproape niciodată toate caracteristicile tipului ideal. O organizaţie poate 27

28 SCIPA - Stabilirea cerinţelor în contextual lumii reale să aibă un număr de caracteristici care să o facă să apară mai mult sau mai puţin virtuală. Câteva caracteristici generale ale organizaţiilor virtuale sunt enumerate în tabelul 3: Proprietăţi din punct de vedere instituţional 1. unităţi independente juridic 2. competenţe profesionale complementare limitate în timp 3. partajare de resurse, know-how şi riscuri 4. inexistenţa concurenţei, cooperare totală pentru atingerea scopurilor 5. nu există o entitate centrală care să controleze activitatea; totul se bazează pe încredere reciprocă Proprietăţi din punct de vedere funcţional 1. independente de forma socialjuridică 2. coordonarea şi conducerea activitaţii se realizează de către competenţele profesionale 3. orientare adaptativă după cerinţele problemei Tabelul 3. Caracteristici generale ale organizaţiilor virtuale Aceste caracteristici diferenţiază întreprinderea virtuală de alte forme de structuri interorganizaţionale pe temen mai lung cum ar fi linia de aprovizionare sau întreprinderea extinsă. O linie de aprovizionare este un ansamblu stabil de activităţi prin care mai multe întreprinderi s-au angajat să contribuie cu competenţele lor la realizarea şi livrarea unui produs pe o piaţă relativ stabilă. Comunicarea într-o astfel de structură are ca scop minimizarea stocurilor şi a întârzierilor, monitorizarea calităţii, şi posibilitatea de introducere a unor programe de modernizare pe măsură ce se produce trecerea de la orientarea pe produs la orientarea pe client. Integrarea tehnologiei informaţiilor şi comunicaţiilor (TIC) într-o linie de aprovizionare se bazează pe fluxul de informaţii EDI (Electronic Data Interchange) ca parte integrantă a procesului operaţional şi include de asemenea schimbul de date despre produs, previziuni şi planuri de producţie. Capacităţile sunt angajate pe o perioadă lungă de timp. Întreprinderea extinsă poate fi privită ca o corporaţie virtuală care a evoluat dintr-o linie de aprovizionare. Pe măsură ce o linie de aprovizionare creşte într-o întreprindere cu mai multe nivele, cu furnizori pe mai multe nivele, colaborarea trece dincolo de nivelul producţiei, la nivelul proiectării, dezvoltării, costurilor. Întreprinderea extinsă este întâlnită, de obicei, în cazul unor produse complexe, al producţiei orientate pe loturi mari/medii şi al unei diferenţieri considerabile a produselor în funcţie de client. Integrarea este strânsă, permiţând un nivel înalt de sincronizare a programelor dezvoltării proceselor, producţiei şi livrării la nivelul partenerilor. Având în vedere natura oportunistă a întreprinderii virtuale, unul dintre scopurile sale este de a atinge nivelul de coordonare al întreprinderii extinse, fără a implica relaţii pe termen lung într- o linie de aprovizionare şi fără a aştepta viitoare economii de scală. În producţie, modelul întreprinderii virtuale se concentrează asupra produselor de serie mică sau a produselor unicat, pentru care clienţii, activităţile de planificare, producţie, testare, pot fi răspândite pe mai multe continente. Liniile de aprovizionare şi întreprinderile extinse pot evolua spre întreprinderi virtuale ca răspuns la presiunile pieţei şi pentru a realiza un nivel de personalizare satisfăcător pentru clienţi. Transformarea poate avea loc şi invers. Dacă o alianţă de tipul întreprinderii virtuale are asigurată o piaţă stabilă, partenerii vor dezvolta relaţii pe termen lung şi se va transforma 28

29 SCIPA - Stabilirea cerinţelor în contextual lumii reale astfel într-o linie de aprovizionare sau într-o întreprindere extinsă, dacă un anumit partener preia conducerea. Datorită unei strategii de diversificare, o întreprindere poate fi în acelaşi timp parte a unei linii de aprovizionare, a mai multor întreprinderi virtuale şi, de asemenea, prezentă pe mai multe pieţe electronice. Aşadar, întreprinderea va fi implicată doar ca o mică parte din capacitatea de producţie a întreprinderii virtuale, alte părţi fiind implicate în angajamente pe termen lung, de exemplu în linii de aprovizionare, după cum se poate observa în figura 11. Linie de aprovizionare 1 Grupul de clienţi 1 Linie de aprovizionare 2 Grupul de clienţi 2 Linie de aprovizionare n Grupul de clienţi n Figura 13. Participare simultană a unei întreprinderi într-o linie de aprovizionare şi într-o întreprindere virtuală Într-o întreprindere virtuală pot fi active simultan mai multe clustere. Un cluster este un grup de întreprinderi, membre ale unei întreprinderi virtuale mai mari care sunt implicate curent în execuţia unei comenzi de la un client. Resursele folosite într-un cluster trebuie să fie libere în momentul în care sunt necesare execuţiei comenzii. Surse de resurse disponibile: politici bazate pe supracapacitate, foarte populare pentru că sporesc flexibilitatea; comenzi întârziate sau anulate; planificarea comenzilor, proceselor, operaţiilor. O observaţie importantă este este că întreprinderile din clustere obţin cea mai mare parte din venituri prin contracte pe termen lung, care reprezintă principalele lor angajamente. Întreprinderea virtuală este privită doar ca o activitate colaterală, dar care le ajută să: acopere golurile în utilizarea resurselor lor şi astfel să-şi crească performanţele; participe activ la piaţa globală; extindă virtual tipurile de resurse. În prezent există mai mulţi factori care favorizează expansiunea întreprinderilor virtuale: Cluster: întreprindere virtuală pentru comenzi neaşteptate O posibilă întreprindere virtuală eradicarea barierelor taxelor şi globalizarea pieţelor; nivelul şi utilizarea facilă a resurselor de transport; mobilitatea crescută a populaţiei şi uşurinţa interacţiunii umane; uşurinţa comunicaţiilor, mai ales prin dispozitive mobile şi Internet. 29

30 SCIPA - Stabilirea cerinţelor în contextual lumii reale Pentru interconectarea întreprinderilor în întreprinderi virtuale este important nivelul executiv, unde există numeroase procese care pot să beneficieze de pe urma tehnologiei informaţiei şi chiar să fie complet automatizate: planificare de detaliu şi planificarea producţiei; alocarea resurselor; urmărirea produselor şi echipamentelor; monitorizarea fluxului de producţie; managementul calităţii şi al inventarului; raportare la nivelurile superioare. La nivelul implementării caracteristicile acestui tip de întreprinderi indică puternic folosirea unei arhitecturi de sistem multi-agent, în care întreprinderile sunt reprezentate de unul sau mai mulţi agenţi. În mediul unui sistem multiagent se presupune că fiecare agent este autonom şi arhitectura sa este în principiu plată, adica nu apar relaţii de subordonare. Acest lucru corespunde cu procesul de formare al întreprinderilor virtuale la nivel interîntreprinderi (integrare orizontală), nivelul cel mai discutat în literatura de specialitate. De cele mai multe ori se consideră că acestea au o arhitectură plată, care asigură comunicare punct la punct. Această abordare caracterizează cea mai mare parte a cercetărilor legate de crearea întreprinderii virtuale, în care formarea coaliţiilor este realizată prin integrare orizontală, bazată pe diferite mecanisme de brokeraj. Proiectare ÎV, constituire şi control soluţii ICT Integrator Întreprinderea virtuală Atribuţie 1 Atribuţie 2 Atribuţie 3 Atribuţie 4 IMM 1,2,3 IMM 4,5 IMM 6 IMM 7,8 Informaţii despre piaţă Produs final Competiţia Client Utilizatori finali Întreprinderi mari Piaţa Figura 14. Întreprinderea virtuală şi piaţa Abordările mai avansate ale integrării întreprinderilor virtuale propun un model al fluxului de producţie interorganizaţional pe trei niveluri, care surprinde fluxurile de producţie ale partenerilor, viziuni ale fluxurilor şi fluxuri ale coaliţiei. În acest mod sunt depăşite limitările modelului cu un nivel (punct la punct) sau cu două niveluri (privat-public). Deşi răspund mai bine necesităţii alocării dinamice a resurselor (permiţând autoorganizarea), aceste întreprinderi virtuale sunt limitate la structuri predeterminate, statice, 30

31 SCIPA - Stabilirea cerinţelor în contextual lumii reale cu parteneri şi resurse fixe, cunoscute. Astfel tehnicile avansate de descoperire şi compunere a serviciilor nu pot fi exploatate pentru a crea, rafina şi optimiza structuri organizaţionale create ad-hoc, orientate pe scop. Aceste cerinţe pot fi atinse doar dacă se realizează o integrare mai profundă (integrare verticală). Acest lucru este foarte important mai ales pentru organizaţiile globale (corporaţii multinaţionale) care se grupează pentru un interval de timp mai lung pentru a reacţiona la cerinţele pieţei, integrarea permiţând deciziilor de la nivel interîntreprinderi să fie propagate şi reflectate la toate nivelurile în întreprinderile membre. Abordări recente sugerează că ierarhiile imbricate ar putea să modeleze corespunzător coordonarea activităţilor la toate nivelurile într-o structură confederativă. Există deja companii vizionare, cum este TheMindElectric care încearcă crearea unei infrastructuri de servicii care copiază comportamentul biologic. Pentru a integra o astfel de arhitectură într-o societate de agenţi, este folosit conceptul de sistem de agenţi holonic, constând din mai multe niveluri imbricate recursiv de structuri similare (holonii) care se autorestructurează dinamic pentru a atinge scopurile sistemului. Tipologii de întreprinderi virtuale Analizând caracteristicile pe care le prezintă, se pot distinge două mari tipuri de întreprinderi virtuale: statice şi dinamice [GKT98]. Întreprinderile virtuale statice, în care colaborarea are un caracter permanent şi, de obicei, există o organizaţie care este partenerul central şi stabileşte regulile colaborării. Pe de altă parte există întreprinderile virtuale dinamice, în care relaţiile de colaborare sunt temporare, însoţite de partajarea conducerii. Aproape toate definiţiile din literatură se referă la acest al doilea tip de întreprinderi virtuale. Întreprinderi virtuale statice În întreprinderea virtuală statică modul de conectare între partenerii de afaceri este static, fix, procesele economice partajate fiind puternic integrate. Relaţiile economice între parteneri sunt predefinite, strânse, fixe, bine integrate. Reţeaua de parteneri este fixă şi predeterminată, ceea ce determină o structură a întreprinderii virtuale statică şi predeterminată. Exemple bine cunoscute de astfel de organizaţii sunt reţelele în care operează firmele Dell sau Amazon.com. În funcţie de stilul de management din cadrul reţelei, se pot diferenţia două categorii de întreprinderi virtuale statice: centralizate şi descentralizate. a. În cazul întreprinderilor virtuale statice centralizate există un centru de coordonare al relaţiilor economice între membrii reţelei, ceea ce impune existenţa unor interfeţe tehnice pentru integrarea partenerilor. Acestea integrează procesele partenerilor prin crearea unor procese partajate, în timp ce toată infrastructura tehnică şi procesele economice ale partenerilor sunt gestionate în mod centralizat. Între organizaţia centrală se formează relaţii pe termen lung, şi recuperarea investiţiilor are în vedere un orizont lung de timp, deoarece costurile de integrare, dezvoltare şi reinginerie sunt ridicate pentru toţi membrii. Constituirea întreprinderii virtuale este realizată manual, controlul aparţinând în totalitate organizaţiei dominante. Acest model de întreprindere virtuală a fost aplicat în industria constructoare de automobile [ZPo99]. În cazul acesta, un producător important de automobile are o reţea de furnizori, distribuitori, vânzători care sunt implicaţi în producţie, distribuţie şi revânzare. Producătorul are anumite cerinţe care trebuie realizate pentru a creşte gradul de automatizare şi a descreşte costurile de producţie şi distribuţie. Între reţeaua de colaboratori şi organizaţa 31

32 SCIPA - Stabilirea cerinţelor în contextual lumii reale centrală se stabileşte o colaborare strânsă prin adoptarea şi integrarea unor interfeţe predefinite. b. În cazul întreprinderilor virtuale statice descentralizate, partenerii de afaceri sunt conectaţi într-un mod autonom şi descentralizat. Reţeaua este similară celei anterioare, dar nu există o organizaţie centrală, dominantă, şi fiecare membru poate coopera liber cu oricare dintre celelalte întreprinderi. Integrarea membrilor se realizează împreună, în mod coordonat şi incremental. Între parteneri se stabilesc relaţii pe termen lung şi recuperarea investiţiilor are în vedere un orizont lung de timp. Constituirea întreprinderii virtuale este realizată manual, în funcţie de cerinţele tehnice ale partenerilor şi în acest caz costurile de integrare şi dezvoltare sunt ridicate. Acest model de întreprindere virtuală a fost aplicat în industria high-tech. Organizaţiile se concentrează pe câte o activitate specifică (de exemplu, fabricarea de semiconductoare, asamblare) şi realizează parteneriate cu alte organizaţii pentru a juca un rol în mai multe lanţuri valorice. Fiecare partener joacă un rol în cadrul întreprinderii virtuale şi contribuie cu competenţele sale. Pentru a automatiza procesul de formare a întreprinderilor virtuale au fost propuse în ultima vreme soluţii bazate pe pieţe virtuale sau servicii de director prin care potenţialii parteneri să-ţi înregistreze resursele şi procesele economice. Piaţa virtuală oferă servicii de căutare de parteneri potenţiali care oferă anumite procese (matchmaking). Ulterior, începe un proces manual de negociere pentru selectarea celui mai potrivit partener. Timpul necesar găsirii de parteneri şi stabilirii de relaţii este astfel îmbunătăţit. După formarea întreprinderii virtuale însă, relaţiile rămân fixe, statice, adăugarea de noi membrii care ar putea oferi servicii mai bune este imposibilă. Pieţele virtuale pot fi folosite în mod dinamic şi în faza de operare a întreprinderilor virtuale [OTs99]. Partenerii implicaţi în a oferi procese partajate se schimbă în permanenţă, dinamic, în funcţie de cerinţele clientului şi proceselor. Pentru fiecare execuţie a unui proces se crează în mod dinamic o nouă întreprindere virtuală, în funcţie de necesităţile clientului şi partenerilor. Întreprinderi virtuale dinamice În întreprinderea virtuală dinamică, partenerii de afaceri sunt conectaţi în mod dinamic, la cerere, conform cerinţelor clientului, prin intermediul unei pieţe virtuale. Între parteneri nu trebuie să existe relaţii de afaceri fixe, astfel încât întreprinderea virtuală se poate schimba continuu în funcţie de cerinţele pieţei. Piaţa virtuală oferă servicii pentru înregistrarea ofertelor de procese ale partenerilor utilizând o serie de modele de procese generice, globale, cunoscute. În momentul în care un partener doreşte să utilizeze un anumit proces realizează o căutare a tuturor celor care ar putea oferi procesul respectiv. Urmează un proces de selecţie, bazat de obicei pe negociere manuală sau automată, rezultatul fiind un contract pe termen scurt care reglementează relaţiile între părţile implicate. Datorită faptului că se utilizează pieţe virtuale de produse sau servicii organizate pe baza unor modele globale, nu există relaţii statice între parteneri şi nu este necesară o integrare a proceselor partenerilor. Deşi pieţele electronice au fost folosite pentru comerţ electronic de mai mult timp, nu prea au folosite pentru întreprinderi virtuale, în special datorită lipsei de tehnologii capabile să ofere definirea simplă a modelelor de proces, mecanismelor de negociere automată şi interacţiunilor autonome între diferite părţi. În ultima vreme însă, datorită dezvoltării XML, acestea au început să se dezvolte. Relaţiile între cei care oferă şi cei care solicită procese sunt de obicei pe termen scurt, astfel că recuperarea investiţiei se realizează pe baza unei singure tranzacţii, sau în intervalul 32

33 SCIPA - Stabilirea cerinţelor în contextual lumii reale în care se participă pe piaţa respectivă. Numărul de membrii se schimbă în permanenţă, structura întreprinderii virtuale evoluând de asemenea în funcţie de necesităţi. În funcţie de stilul de management din cadrul reţelei, se pot diferenţia două categorii de întreprinderi virtuale dinamice: centralizate şi descentralizate. a. Întreprinderile virtuale dinamice centralizate sunt cele în care unul dintre parteneri este proprietarul pieţei electronice, realizând gestionarea acesteia şi impunând modelele de procese. Acest tip de organizaţie nu este prea întâlnit, deoarece piaţa ar trebui să aparţină unei terţe părţi de încredere, care nu e implicată în întreprinderea virtuală. Totuşi, pot exista situaţii de organizaţii foarte mari care vor să transforme întreprinderea virtuală statică centralizată într-o variantă mai dinamică. b. În cazul întreprinderilor virtuale dinamice descentralizate, piaţa virtuală aparţine unei terţe părţi. Este cel mai evoluat şi mai performant tip de întreprindere virtuală, dar deocamdată tehnologiile şi sistemele economice existente sunt prea imature pentru acest tip de întreprindere. Elemente al acestui model sunt aplicate în domeniul comercial, de exemplu pentu companiile de logistică. Acestea pot să îşi înregistreze procesele pe o piaţă specializată (destinaţia finală, preţul, timpul necesar transferului, garanţiile, etc), ulterior acestea putând fi regăsite prin căutări automate. Acest ultimul tip de întreprinderi virtuale există de obicei doar pe durata furnizării unui singur serviciu. Partenerul este selectat de fiecare dată în funcţie de cerinţe specifice de selecţie şi negociere. Pieţele virtuale devin, în ultima vreme, tot mai specializate şi mai legate de anumite domenii industriale. Probabil că în viitor vor apărea comunităţi speciale pentru schimburi în cadrul unor domenii specifice. 4.3 Vectorii virtualităţii. Avantaje şi riscuri în întreprinderea virtuală Caracteristica esenţială a unei întreprinderi virtuale este virtualitatea, o capacitate pe care fiecare o posedă într-o măsura mai mare sau mai mică,. Virtualitatea este definită ca abilitatea unei organizaţii de a obţine şi menţine competenţe critice prin modelul proceselor sale de adăugare a valorii şi prin structura sa organizaţională. Compania obţine toate competenţele necritice din exterior, adică de la alte companii, împreună cu care formează o întreprindere virtuală. De aceea, conceptual tinde să extindă din punct de vedere conceptual noţiunile de eficienţă şi eficacitate la mai multe companii, şi, de exemplu prin externalizare sau francizare, să lege resursele într-o companie fără să fie nevoie să investească pentru ele. Scopul este de a se ajunge la situaţia câştigător-câştigător pentru părţile implicate. Relaţiile dintre companii sunt în esenţă voluntare, deşi prin dependenţe economice se creează presiuni inerente. Un studiu de caz asupra ultimilor 10 ani relevă multe exemple de astfel de aranjamente win-win între companii. Industrii întregi s-au schimbat, de exemplu industria automobilelor sau comerţul cu amănuntul. Domenii care au fost dominate înainte de corporaţii integrate pe verticală sunt acum deservite de reţele de companii în care funcţia de coordonare a fost în mare parte preluată de corporaţii multinaţionale, împreună cu câteva funcţii reziduale. Expertiza coordonatorilor reţelei constă în abilitatea lor de a face faţă complexităţii acestei structuri. Procesele reale de adăugare a valorii sunt realizate de un număr mare de întreprinderi mici şi mijlocii, unele dintre ele necunoscute clientului. Ei controlează fluxul de informaţie şi au capacitatea şi cunostinţele pentru a-l reproduce în sisteme. 33

34 SCIPA - Stabilirea cerinţelor în contextual lumii reale Din punctul lor de vedere, fluxul de informaţie în reţea este mult mai puţin complex în comparaţie cu companiile integrate vertical, din moment ce, cu un management de interfaţă corespunzător, multe decizii pot fi cedate partenerilor. Pentru partenerii de externalizare (cei mai mulţi fiind firme mici), complexitatea a crescut. De aceea, ele sunt asignate coordonatorului. Aceste două puncte diferite de vedere trebuie luate în considerare când evaluăm avantajele şi dezavantajele întreprinderii virtuale. Conceptul de virtualitate se bazează pe considerente de ordin strategic, cum sunt: asigurarea unor competenţe centrale, mărimea optimă a companiei sau aria de piaţă a produsului. Este necesară, desigur, implementarea în interiorul companiei şi între companii. Aceste schimbări necesită perioade lungi de timp (ani de zile). De aceea, evoluţia companiilor virtuale nu este un proces rapid; dacă există capacitatea, este posibil ca partenerii să fie schimbaţi rapid, aceasta fiind singura modalitate de a introduce flexibilitatea necesară. Schimbarea este deseori condusă de un expert, cu multă influenţă, lider de opinie. Venkatraman şi Henderson [VHe96] pornesc de la ideea că modelele actuale de strategie şi structură organizaţională, nu au succes în competiţia actuală, bazată tot mai mult pe cunoştinţe. Concentrându-se pe importanţa cunoştinţelor şi intelectului în crearea valorii adăugate, ei elaborează un cadru conceptual pentru organizarea virtuală. Tehnologia informaţiei este inima acestui model, iar cei trei vectori interdependenţi ai virtualităţii sunt: Interacţiunea cu piaţa tratează noile provocări şi oportunităţi pentru interacţiunile dintre companie şi clienţi; Echilibrarea competenţelor crearea şi amplasarea bunurilor de natură intelectuală, cele de natură fizică fiind luate dintr-o reţea de afaceri complexă; Configurarea muncii se referă la posibilitatea echilibrării-compensării diferitor surse de expertiză în cadrul şi înafara graniţelor organizaţionale. Vectori Etape ale virtualităţii Etapa 1 Etapa 2 Etapa 3 Interacţiune cu piaţa (Întâlnire virtuală) Produse şi servicii experimentate de la distanţă Personalizarea produselor sau serviciilor Croirea de soluţii client Echilibrarea competenţelor (Resurse virtuale) Resurse eficiente pentru componente standard Echilibrarea eficientă a activelor Cearea de noi competenţe prin alianţe Tabelul 4. Etapele virtualităţii Configurarea muncii (munca virtuală) Maximizarea expertizei individuale Valorificarea expertizei organizaţionale Echilibrarea expertizei comunităţii de profesionişti Au fost identificate mai multe etape ale virtualităţii: Etapa 1 se concentrează asupra unităţilor de lucru, cum sunt serviciile client, achiziţiile, dezvoltarea unui nou produs. Obiectivul implicit este de creştere a eficienţei prin integrarea mai strânsă a clienţilor. 34

35 SCIPA - Stabilirea cerinţelor în contextual lumii reale Etapa 2 se concentrează pe coordonarea activităţilor pentru crearea de valoare superioară. Implicit, în această etapă apar noi aranjamente organizaţionale. Etapa 3 se concentrează asupra reţelei internaţionale pentru a proiecta şi completa comunităţi interdependente pentru inovare şi creştere. Trebuie recreată în această etapă valoarea în termenii produselor şi serviciilor. Caracteristicile întreprinderii virtuale îi oferă un plus de flebibilitate şi dinamism. Dar care sunt deosebirile între întreprinderile virtuale şi celelalte modele tradiţionale de grupare a întreprinderilor? Mertens şi Faisst [MFa95] sunt cei care au analizat pentru prima dată acest aspect, principalele concluzii fiind prezentate în tabelul 5. Tip de grupare Deosebiri faţă de întreprinderile virtuale Alianţă strategică cooperare slabă nu exista o virtualizare a serviciilor majoritar întreprinderi mari Concern dominare sau existenţa pachetului majoritar Cartel dorinţa de a limita concurenţa Consorţiu colaborare formală Joint Venture necesitatea înfiinţării unei noi întreprinderi Franciză existenţa unei relaţii de subordonare pe termen lung Tabelul 5. Întreprindere virtuală versus alte tipuri de grupări organizaţionale Organizaţiile virtuale nu creează de obicei noi funcţii centrale pentru coordonare; acest lucru este rezolvat cu ajutorul tehnologiei informaţiei şi telecomunicaţiilor şi, ca urmare, nu apar noi nivele de management, ci dimpotrivă se reduc cele existente. Relaţiile sunt mai puţin formalizate, sunt limitate în timp, mai strânse decât relaţiile de piaţă (bazate pe EDI şi groupware). Relaţiile din structurile organizatorice de coordonare şi administrare sunt înlocuite cu relaţii contractuale pe termen scurt. 4.4 Implicaţiile virtualizării structurii organizatorice Implicaţii din punct de vedere al strategiei competitive Folosirea comună a capacităţilor de producţie, canalelor de distribuţie, aprovizionare şi a altor resurse (potenţate de posibilitatea de comunicare şi monitorizare prin TIC) conduce la reducerea costurilor globale, apariţia unui efect de sinergie, a economiilor de scală şi a creşterii calităţii) datorită încrederii, destinului comun. Un alt aspect benefic este schimbul de cunoştinţe legate de tehnicile de producţie eficiente din punct de vedere al costurilor, activităţile comune în domeniul cercetării dezvoltării bazate pe groupware, , videoconferinţe, etc. Ca urmare, apare producţia comună de bunuri şi servicii inovative, puternic orientate spre client. Accesul lărgit la informaţii, legate spre exemplu de modificarea cerinţelor clientului, reduce mult timpul de reacţie la schimbările de pe piaţă. Ambele efecte oferă protecţie faţă de produsele substitut, în cazul în care substituibilitatea produselor şi serviciilor este corelată negativ cu complexitatea acestora. Are loc o reducere a timpului şi costurilor de 35

36 SCIPA - Stabilirea cerinţelor în contextual lumii reale comunicaţie (EDI, ) şi creşterea vitezei tranzacţiilor de plată prin mijloace electronice, ceea ce conduce la îmbunătăţirea situaţiei financiare. O cooperare puternică între partenerii de afaceri va conduce la o poziţie mai puternică pe piaţă şi va împiedica intrarea pe piaţă a unor competitori care nu se pot baza pe un efect de sinergie similar Implicaţii din punct de vedere al costurilor tranzacţionale Tranziţia la organizaţia virtuală presupune o anumită infrastructură, aranjamente contractuale referitoare la modul de cooperare. Acestea reclamă dezvoltarea şi implementarea de sisteme informatice interorganizaţionale, ceea ce determină o sporire a cheltuielilor [Geb96]. Cresc de asemenea costurile datorită nevoii de coordonare recurentă a unităţilor organizaţionale. Pe de altă parte, scad cheltuielile pentru operaţiile zilnice: căutarea informaţiei, negocieri, contractări datorită unui număr mai redus de parteneri şi mai multor informaţii disponibile despre parteneri şi produsele lor. Scad costurile şi consumul de timp pentru schimbul de informaţii datorită canalelor de comunicare eficiente şi sistemelor informatice interorganizaţionale. Totuşi, datorită interdependenţelor între participanţi, creşte gradul de vulnerabilitate. Posibilitatea apariţiei comportamentului oportunist din partea unor parteneri, care să profite de ceilalţi creşte, de unde şi nevoia de monitorizare a activităţilor. Totuşi, probabilitatea de apariţie a unor astfel de comportamente oportuniste este destul de redusă pentru că relaţiile pe termen mai lung şi mai stabile conduc la o interdependenţă reciprocă, şi cresc vulnerabilitatea pentru toţi cei implicaţi. Aşadar, din punct de vedere al costurilor tranzacţionale, costurile de coordonare tind să crească, dar scad cheltuielile la nivelul operaţiilor, şi probabil pentru monitorizare, datorită creşterii vulnerabilităţii. Deci, eficienţa globală e îmbunătăţită atât timp cât economiile nu sunt depăşite datorită cheltuielilor adiţionale pentru coordonare, având în vedere că alţi factori, de exemplu costurile de producţie ramân neschimbate Implicaţii din punct de vedere al dreptului de proprietate Pentru a funcţiona corespunzător, structurile de cooperare trebuie bazate pe contracte cât mai complete (orice modificare ulterioară neprevăzută în contract trebuie negociată), reguli bine stabilite pentru a păstra încrederea între parteneri egali şi mecanisme corespunzătoare pentru a monitoriza performanţele actorilor economici. Nici una dintre părţi nu trebuie să fie dezavantajată în raport cu celelalte, toţi ar trebui să aibă cam acelaşi raport cost-beneficiu. În acest context, vor juca un rol important mecanismele de monitorizare a performanţelor (sisteme informatice interorganizaţionale cu funcţii de monitorizare şi creştere a transparenţei). Graniţele pentru fluxurile de informaţii ar trebui să fie permeabile din toate direcţiile, nu doar pentru una din părţi. Astfel, creşterea propriei arii de influenţă înseamnă, de asemenea, extinderea influenţei factorilor externi asupra condiţiilor interne, astfel că efectul global e nedeterminat. Pe de altă parte, pentru a păstra încrederea între parteneri egali, e necesară respectarea unor reguli, fie ele stipulate prin contract, fie reguli nescrise. Partenerii renunţă astfel la o anumită libertate de mişcare şi are loc o reducere a motivării, a securităţii angajaţilor. 36

37 SCIPA - Stabilirea cerinţelor în contextual lumii reale Avantaje şi riscuri ale cooperării în cadrul întreprinderilor virtuale Utilizarea acestei scheme de cooperare aduce numeroase beneficii, influenţând pozitiv parametrii globali ai întreprinderii virtuale. Pe baza unor cazuri reale, în cadrul proiectului ALIVE (Advanced Legal Issues în Virtual Enterprise), au fost obţinute evaluările următoare, la nivelul anului anului 2003: Tipuri de metrici Valoare Reducerea costurilor individuale Până la 50% Reducerea globală a costurilor 15%-20% Reducerea expunerii financiare a partenerilor 25% Creşterea profitabilităţii proiectelor 25% Reducerea timpului necesar formalizării contractelor de cooperare 50% Reducerea timpului de ieşire pe piaţă 25% Creşterea veniturilor utilizatorilor individuali Peste 25% Creşterea eficienţei proceselor de cooperare 15-30% Tabelul 6. Beneficii ale întreprinderii virtuale O sinteză a principalelor avantaje şi riscuri oferite de întreprinderea virtuală este prezentată în următorul tabel: Avantaje flexibilitate mare a lucrului în echipă posibilitatea reducerii costurilor noi oportunităţi de piaţă avantaje în ceea ce priveşte timpul de lucru accesul la resurse în afara întreprinderii proces de învăţare continuă în cadrul organizaţiei (schimb de experienţă) avantaje pentru clienţi Riscuri lipsa specializării distanţarea faţă de piaţă situaţia instabilă a posturilor inexistenţa unei culturi a firmei fixarea de scopuri, uneori divergente dezavantaje macroeconomice (şomaj) riscul neacceptării din partea clienţilor Tabelul 7. Principalele avantaje şi riscuri ale întreprinderii virtuale 37

38 SCIPA - Stabilirea cerinţelor în contextual lumii reale Bibliografie [ALT96] S.A. Alter, Information Systems: A Management Perspective, Benjamin Cummings, 1996, ISBN [APL84] D. Appleton, Business Rules: The Missing Link, Datamation, Octombrie, [BBB93] J.A.Byrne, R. Brandt, O. Bort, The Virtual Corporation, Business Week, februarie, [DHa98] Y.L, Doz, G. Hamel, Alliance Advantage. The Art of Creating Value through Partnering, Boston: Harvard Business School Press, [Geb96] J. Gebauer, Virtual Organizations from an Economic Perspective, Proceedings of the 4 th European Conference on Information Systems, vol. 1, Lisabona, Portugalia, iulie, 1996; [GKT98] A. Geppert, M. Kradolfer, D. Tombros, Market-Based Workflow Management, International IFIP Conf. on Distributed Systems for Electronic Commerce, Hamburg, Germania, iunie [Lho06] R. Lhotka, Expert C# 2005 Business Objects, Second Edition, Apress, [May03] May M., Business Process Management: Integration in a web-enabled environment, Prentice Hall, [MDa92] M. S. Malone, W.H. Davidow, The Virtual Corporation: Structuring and revitalizing the corporation for the 21st century, New-York, Harper Business, [MFa95] P. Mertens, W. Faisst, Virtuelle Unternehmen - eine Organisationsstruktur für die Zukunft?, în revista Technologie & Management, vol 44, 1995, nr. 2, p , [OMG06] Semantics of Business Vocabulary and Business Rules, disponibil la [ORJ03] M. Owen, and J. Raj, BPMN and Business Process Management-Introduction to the New Business Process Modeling Standard, Popkin Software, [OTs99] V. Ouzounis, V. Tschammer, A Framework for Virtual Enterprise Support Services, 32nd International Conference on Systems and Sciences (HICSS32) Maoui, Hawaii, ianuarie, [THT02] H.K. Tönshoff, O. Herzog, I.J. Timm, P.O. Woelk, Emerging Virtual Enterprises, Proceedings of the 4th International Workshop on Emergent Synthesis (IWES-02), Kobe University, Japan, mai [VHe96] N.Venkatraman, J. C. Henderson, The Architecture of Virtual Organizations: Leveraging Three Interdependent Vectors, lucrare elaborată în cadrul Systems Research Center, Boston University School of Management, Boston, MA [Whi03] S. A. White, Using BPMN to Model a BPEL Process, IBM Corp., US, [ZPo99] A. Zarli, P. Poyet, A Framework for Distributed Information Management in the Virtual Enterprise: The VEGA Project, în Infrastructures for Virtual Enterprises. Networking Industrial Enterprises, IFIP TC5 WG5.3 / PRODNET Working Conference for Virtual Enterprises (PRO-VE'99), Porto, Portugalia, p , octombrie

39 SCIPA - Stabilirea cerinţelor în contextual lumii reale Servicii software semantice de Colaborare si Interoperabilitate pentru realizarea Proceselor Adaptive de business Stabilirea cerinţelor în contextul lumii reale - Continuare Autori SC IPA SA - Societate comerciala pentru cercetare, proiectare si productie de echipamente si instalatii de automatizare Dr.Ing. Pîrvu Cristian Ing. Bran Iuliana Ec. Borta Roxana Cs. Ing. Predescu Ciprian Cs. I Ing. Gheorghiu Apolodor Contract nr / Autoritatea contractantă: CNMP Pagina Web: Info contact: 39

40 SCIPA - Stabilirea cerinţelor în contextual lumii reale CUPRINS 5 Modele de afaceri Studiul de caz: Controlul documentelor si informatiilor ce circula intr-o intreprindere Studiu de caz: plan tehnic de materiale Studiu de caz: flux de cereri de avans si deconturi Studiu de caz: modele de procese de afaceri Studiu de caz: Cultura managerial in business Studiu de caz: managementul afacerii bazat pe plan de afaceri

41 SCIPA - Stabilirea cerinţelor în contextual lumii reale 5 Modele de afaceri 5.1 Studiul de caz: Controlul documentelor si informatiilor ce circula intr-o intreprindere Organizatia este structurata in jurul documentelor: teancuri de scrisori, copii dupa diverse documente, rafturi pline cu dosare, cutia postala plina de mesaje electronice - sunt doar cateva exemple. Intreaga activitate a firmei este organizata in jurul acestor documente. Afacerea poate fi definita ca o arhitectura de documente. De aceea, putem spune ca documentele reprezinta esenta intregii afaceri. Dar o simpla analiza a problemelor legate de fluxul manual de documente arata dificultatile managementului clasic de documente in conditiile unei organizatii moderne. Managementul Documentelor reprezinta un sistem informatic care permite circulatia (pentru informari, aprobari sau modificari), stocarea si regasirea documentelor aflate in orice format electronic, cu facilitati de conectare la alte sisteme informatice sau dispozitive electronice (de exemplu, prin conectarea la dispozitive de scanare pot fi introduse automat in sistem documentele pe hartie). Caracteristici ale sistemelor de management al documentelor Un sistem performant de management al documentelor: implementeaza rapid fluxuri de documente este flexibil la orice structura organizationala are un grad inalt de securitate este adaptabil la orice tip de document este conectabil la alte aplicatii prezinta usurinta in exploatare este scalabil la dezvoltari ulterioare Sistemele de management al documentelor asigura: Alocarea unui numar unic de Inregistrare fiecarui document Stabilirea locului unde se afla fiecare document activ Urmarirea intregului ciclu de viata al unui document 41

42 SCIPA - Stabilirea cerinţelor în contextual lumii reale personalul insarcinat cu receptia acestuia momentul la care a fost receptionat persoana care raspunde de avizarea/raspunsul formulat data la care raspunsul/avizarea au fost finalizate Avantaje ale sistemelor de management al documentelor Spre deosebire de sistemele manuale sistemele automate de management al documentelor: Stocheaza informatiile legate de document intr-un singur loc Permit accesul rapid la locul in care se afla documentul in organizatie Informeaza privind stadiul de avizare (rezolutie) in care se afla un document Urmaresc timpul necesar finalizarii unei avizari (rezolutii) si cele care au depasit acest termen Vizualizeaza numarul de documente intrate zilnic,saptamânal si lunar Documentele sunt elemente cheie pentru succesul in afaceri pentru orice firma. Documentul ajuta mult mai mult in prezent ca inainte sa cream noi relatii, prin posibilitatea de a-l particulariza in concordanta cu dorintele destinatarului. Documentul interactiv ofera autorului posibilitatea de a diversifica accesul, continutul si modalitatea de transmitere a documentului, in functie de destinatar. Noile structuri de administrare, noile tehnici si strategii sunt efectul adoptarii unui marketing de tipul unu la unu. Documentul interactiv sprijina comunicarea si colaborarea in sensul maririi eficientei si a gradului de satisfactie in munca noastra. De asemenea, documentele ne permit sa construim mai multe medii de comunicare conectate intre ele. Mai jos este prezentata o imagine simplificata a stadiilor documentelor si fluxului cunostintelor intr-un proiect global din cadrul unei intreprinderi. 42

43 SCIPA - Stabilirea cerinţelor în contextual lumii reale Tehnologiile care permit administrarea si gestionarea documentelor, fara necesitatea de a le tipari, cresc semnificativ cantitatea de informatie inglobata in documentele unei firme, aceasta putandu-se dubla chiar anual. Managementul documentelor are sanse de existenta gratie tehnologiei de "tiparire la cerere", care inseamna un soi de tiparire a documentelor atunci cand se cere acest lucru, eliminandu-se astfel necesitatea de a se tipari de pilda un intreg inventar deoarece tocmai au aparut anumite actualizari. Ca aceasta tehnologie se va numi "tiparire la cerere" sau, dupa alte propuneri, "tiparire la nevoie" are mai putina importanta. Mult mai importanta este tehnologia in sine, de care vom tot auzi in urmatorii ani. Potentialul real al tiparirii la cerere este tocmai posibilitatea de a tipari ceea ce este necesar, atunci cand este nevoie. Utilizatorul documentului are posibilitatea de a asambla doar informatia de care are nevoie si sa tipareasca astfel documentul, cand are nevoie. Valoarea economica in birouri a acestui concept va putea fi observata si printr-o simpla privire spre cosul de hartii. 5.2 Studiu de caz: Plan tehnic de materiale Procesul de proiectare culmineaza cu un plan tehnic de materiale care descrie toate componentele care trebuie asamblate in produsul final. Acesta se transforma intr-un plan tehnic de manopera care descrie modul de construire a unei unitati din produs. Informatiile referitoare la productie sunt gestionate de mediul de management al resurselor intreprinderii pentru a asigura reflectarea cunostintelor cuprinse in planul tehnic de manopera in procesul efectiv de productie. Aceasta implica managementul resurselor, planificarea productiei, achizitiile si stocarea materialelor si componentelor si managementul comenzilor de lucru. Productia are legaturi cu un numar de sisteme secundare precum managementul resurselor umane, contabilitate si costuri si sisteme de control al planificarii. Managementul proceselor de schimbare tehnica si in documentatie poate fi realizat cel mai eficient prin intermediul unui sistem electronic de flux al muncii (suport in luarea deciziilor). Proiectele mari cuprind foarte multe cunostinte,regasite in diferite documente, atat in interiorul proiectului cat si livrabile clientului. Multe tipuri de documente trebuie pastrate timp de mai multi ani. De exemplu, scrierea documentatiei de intretinere pentru produsul respectiv incepe cu mult timp inainte de livrarea lui. Documentatia trebuie actualizata cu schimbarile produse in configuratia tehnica pana cand ultimul produs va iesi din serviciu. Costurile pentru producerea, gestiunea si livrarea documentatiei legate de proiect reprezinta cateva procente din costurile totale de achizitie. 43

44 SCIPA - Stabilirea cerinţelor în contextual lumii reale Figura 1 Fluxul informatiilor in producerea documentatiei de intretinere Figura de mai sus insumeaza procesul prin care aceste informatii sunt asamblate dintr-o varietate de surse. Cerintele pentru documentatia suport sunt specificate in contract si documentele conexe. Acestea sunt extinse si detaliate in planul integrat de suport logistic. Manualele tehnice si alte documentatii pentru sisteme si echipamente ofera informatii despre acestea. Detaliile despre ierarhia sistemelor, materiale,componente, instrumente, fluide si lubrifianti si alte elemente si echipamente de test sunt asamblate si gestionate in baza de date a sprijinului logistic integrat. Inginerii de logistica si intretinere transforma documentatia primita intr-o versiune initiala a planului de intretinere tehnica pentru sistemele proiectate, care stabileste filosofia de baza pentru intretinerea fiecarui sistem. Planurile de intretinere tehnica descriu doua tipuri de intretinere: specificatii tehnice de reparatie (care descriu sarcini de intretinere realizate de obicei de agenti externi) si proceduri de intretinere (care descriu sarcini de intretinere periodica efectuate de personalul beneficiarului). Studiu de caz:arhitectura pentru sisteme de management al cunostintelor pentru intretinere in serviciu Implementarea sistemului descris anterior a oferit o platforma pentru o arhitectura care a rezolvat cu succes problemele majore legate de procedurile de intretinere, atat intern cat si pentru client. Contractele cu valoare fixa pentru proiectele mari au o serie de caracteristici unice care forteaza compania sa se concentreze nu numai pe gestiunea fluxului de cunostinte in proceduri de management, dar si pe sprijinirea si actualizarea acestor cunostinte si dupa livrarea produselor si intrarea in serviciu. Figura de mai jos ilustreaza fluxul de informatii pentru actualizarea cunostintelor pentru suport logistic in partea de intretinere in serviciu a ciclului de viata al proiectului. Sagetile indica o bucla de reactie intre cunostintele operationale despre performanta pachetului de suport logistic (inclusiv documentatii) in timpul serviciului si modificarile adaptive ale diferitelor forme de documentatie care descriu cum trebuie intretinute sistemele in timpul serviciului. Aceste cunostinte au fost rafinate prin experienta acumulata in serviciu si poate fi 44

45 SCIPA - Stabilirea cerinţelor în contextual lumii reale folosita in alte proiecte similare. Totusi, pentru alte tipuri de documentatie, cunostintele autorului raman implicite si se pierd usor odata cu schimbarile de personal. 5.3 Studiu de caz: Flux de cereri de avans si deconturi Un exemplu tipic de documente care circula Intr-o firma sunt cererile de avans de numerar si deconturile ulterioare. Ele sunt originate de regula de o persoana de executie, avizate de seful ierarhic, de contabilitate si aprobate de conducatorul organizatiei sau sucursalei. Sistemul automatizeaza fluxul documentelor si reduce consumul de hârtie la minimum. Documentul de cerere de avans spre decontare este emis electronic de solicitant. El are o forma similar cu cel standard pe hârtie Documentul este rutat automat prin catre persoanele care trebuie sa-i avizeze sau aprobe. In caz de respingere sau cerere de refacere documentul se intoarce la emitent. Dupa aprobarea cererii se tipareste chitanta de avans si casieria elibereaza numerarul. Decontul se intocmeste tot electronic. Dupa aprobarea decontului se tipareste borderoul pentru semnarea de catre contabilitate si descarcarea posesorului de avans. Aprobarea se realizeaza electronic. Traseul documentelor de cerere de avans si decont este urmarit strict de sistem cu mentionarea datei si orei exacte când documentele au fost emise, avizate sau aprobate. Singurele documente tiparite conform legislatiei actuale sunt cele legate de primirea de numerar si decontare. Utilizatorul este informat privind destinatía urmatoare a documentului.sistemul de cereri de avans si deconturi poate fi util si prin datele suplimentare ce le ofera. Ca de exemplu totaluri de cereri, cereri aprobate si respinse, sume nedecontate, etc. 45

46 SCIPA - Stabilirea cerinţelor în contextual lumii reale 5.4 Studiu de caz: Modele de procese de afaceri Dezvoltarea orientata pe model (MDD = Model-driven development), si in particular OMG Model Driven Architecture este o abordare in dezvoltarea aplicatiilor si sistemelor software moderne din intreprinderi. Paradigma MMD ofera a modalitate de a aborda problemele de interoperabilitate spre deosebire de abordari anterioare care nu se bazau pe model. Un model independent de platforma (PIM) corespunde unei viziuni a platformei de implementare independenta de aceasta, descriind specificatiile software independent de detalii de executie cum ar fi servicii Web, J2EE,.net, agenti sau tehnologii P2P. Un model specific platformei (PSM) descrie realizarea sistemelor software intr-o anumita platforma specifica sau intr-un set de platforme. Un proces de business sau proces de afaceri (BP) este o colectie de activitati (task-uri) interconectate care rezolva o anumita problema de business. F. Davenport (1993) spune ca "un proces de business este o multime structurata si masurabila de activitati proiectate pentru a produce o iesire specifica pentru un client sau o piata". Modelarea BP poate fi vazuta ca o reprezentarea grafica a BP intr-un flux de lucru (workflow, un concept mai restrictiv decat cel de proces, care pune in evidenta fluxul de control si de date dintr-o perspectiva centralizata). La ora actuala, cele mai importante standarde considerate pentru modelarea proceselor de afaceri sunt BPMN (Business Process Modeling Notation) adoptat ca standard de OASIS din februarie 2006 si UML (stanadrd OMG). In prezent s-au impus doua concepte importante legate de BP: orchestrarea BP in care procesul este vazut ca o ordonare totala sau partiala a activitatilor sub control centralizat si coreografia BP in care procesul este vazut ca un schimb de mesaje intre participanti; defineste interactiuni. Standardele cele mai important pentru orchestrarea si executarea proceselor de afaceri sunt la ora actuala BPEL (Business Process Execution Language) cu varianta WS- BPEL pentru servicii, si ebxml, iar la nivelul coreografiei serviciilor Web propunerile actuale sunt WSCL (Web Service Conversation Language) si WSCI (Web Service Choreography Interface). Coordonarea proceselor de business este de asemenea un aspect important in care procesul de afaceri este vazut ca un set de activitati corelate intre partenerii de business. De exemplu, standardul WS Coordination specifica modul in care mai multe servicii Web opereaza intr-o maniera coordonata si un context consistent. Solutia propune si dezvolta un model al proceselor de afaceri care include adnotarea semantica a componentelor, adaptibilitatea modelului in functie de cerintele procesului de business si mediul in care acesta se desfasoara, cat si procese colaborative care pot fi evaluate si stocate sub forma unor sabloane de cooperare ce vor deveni progresiv fluxuri de lucru reutilizabile. Solutia cuprinde o platforma de modelare si dezvoltare software complexa care include: componente strategice si de proiectare cum ar fi modelatorul procesului de business (PB), componenta de proiectare a serviciilor semantice, si componente de implementare cum ar fi platforma de realizare si oferire a serviciilor software semantice bazata pe o arhitectura SOA, browserul de servicii (inclusiv descoperire), componenta de compunere a serviciilor, componenta de construire a regulilor de coordonare. 5.5 Studiu de caz: Cultura managerial in business Intr-o cultură organizaţională puternică, majoritatea managerilor împărtăşesc un set comun de credinţe, valori, comportamente cu privire la modul în care trebuie direcţionată afacerea respectivă. Noii angajaţi intră în contact cu acest set cultural şi îl adoptă, atât ca urmare a manifestării lor formale, cât şi informale. Cultura organizaţională este considerată din ce în ce mai mult astăzi ca unul dintre factorii cu o influenţă 46

47 SCIPA - Stabilirea cerinţelor în contextual lumii reale determinantă asupra performanţelor unei firme. În majoritatea cazurilor, rezultatele bune şi foarte bune sunt asociate cu capacitatea proprietarilor, managerilor, liderilor de a crea, menţine şi dezvolta o cultură organizaţională puternică, care să energizeze componenţii săi către realizarea obiectivelor propuse. Prin poziţia, statutul pe care îl au managerii în ierarhia organizaţiei, aceştia modelează semnificativ atitudinile, deciziile şi comportamentele subordonaţilor. Apare astfel o cultură managerială, ca parte integrantă a culturii organizaţionale, asupra căreia poate exercita o influenţă pozitivă sau chiar negativă uneori. Firmele ce beneficiază de o cultură managerial puternică, bine conturată, care îi individualizează acţiunile şi evoluţia în mediul de afaceri, sunt considerate a fi companii, branduri cu un anumit stil. Adesea, valorile manageriale, îndeosebi ale topmanagerilor, cu un impact remarcabil asupra evoluţiei firmei, sunt favorizate, oficializate în misiunea firmei, în diferite comandamente sau declaraţii care sunt communicate şi afişate în întreaga organizaţie, pentru a se da un nou imbold, o nouă direcţionare a eforturilor tuturor angajaţilor. Maniera în care cultura managerială influenţează performanţele unei firme poate fi explicată în mai multe moduri: asigură direcţionarea eforturilor către un obiectiv sau set de obiective precizat(e); dezvoltă o motivaţie puternică pentru salariaţi în obţinerea rezultatelor aşteptate; furnizează o structură şi un sistem de mecanisme care coordonează eforturile angajaţilor fără a fi nevoie de un set de proceduri sau sisteme formale. Prin cultură managerială înţelegem,, totalitatea credinţelor, valorilor, simbolurilor, atitudinilor şi comportamentelor managerilor dintr-o organizaţie, care se reflectă în deciziile şi acţiunile pe care aceştia le adoptă şi aplică pentru asigurarea unei dezvoltări competitive a firmei. Cultura managerială este mai bine înţeleasă şi exercită un rol major în cultura organizaţională în special atunci când managerii conştientizează rolul pe care ei îl au în firmă, nu numai la nivel formal ci şi informal şi, în consecinţă, sunt dispuşi să afecteze o parte apreciabilă din timpul lor pentru comunicarea şi pregătirea salariaţilor în ceea ce priveşte filosofia managerială şi setul de valori de bază al firmei. O modalitate larg răspândită pentru a promova astfel de concepte este aceea ca, în diferitele situaţii informaţionale (rapoarte, sinteze etc.), să fie publicate, pe lângă misiunea firmei (recomandabil pe coperta interioară sau pe prima pagină din interior), şi declaraţii precum că realizările sunt datorate şi valorilor, atitudinilor şi comportamentelor salariaţilor în consonanţă cu cultura organizaţională a firmei, comunicarea deschisă şi spiritual de echipă au făcut posibile rezultatele acestea etc. Strâns legat de această modalitate, se mai poate apela şi la o serie de ritualuri, de ceremonii (precum participarea la anumite excursii sau alte acţiuni de socializare) care să ofere sentimentul apartenenţei la un anumit grup. Filosofia firmelor cu brand, acentueaza câteva principii larg îmbrăţişate: respect pentru demnitatea salariaţilor şi drepturi egale în firmă pentru aceştia; oferirea celor mai bune servicii clienţilor săi, la un nivel superior în comparaţie cu orice altă companie din lume; 47

48 SCIPA - Stabilirea cerinţelor în contextual lumii reale nivel realizarea tuturor sarcinilor, cu obiectivul permanent în minte de a le realiza la un superior celor precedente. 5.6 Studiu de caz: Managementul afacerii bazat pe plan de afaceri Prezentul Plan de Afaceri se întocmeşte în vederea implementarii proiectului Studii şi cercetări privind sisteme pentru monitorizarea în timp real a calităţii energiei în staţiile electrice de medie tensiune SISMED-2. Planul de Afaceri este susţinut de trei entităţi juridice diferite: Universitatea din Craiova prin Facultatea de Inginerie în Electromecanică, Mediu şi Informatică Industrială care va fi şi coordonatorul proiectului realizînd în acelaşi timp şi activităţi de cercetare-dezvoltare, testare, monitorizare, elaborare a pachetelor de programe si analiză a rezultatelor obţinute; SC IPA SA (Institutul de Proiectări pentru Automatizări) prin Sucursala IPA CIFATT Craiova care va fi partener în acest proiect şi care va fi implicată în cercetarea aplicativă privind elaborarea soluţiei tehnice, proiectarea echipamentelor şi sistemelor, elaborarea pachetelor de programe, implementarea şi punerea în funcţiune a sistemului; SC RomData AQ srl (entitate operatoare după finalizarea etapei de proiectare), societate comercială privată, cu experienţă în domeniul producerii, implementării, comercializării şi mentenanţei soluţiilor de acest tip care va participa cu specialişti în activitatea concepţională si în plus va prelua producţia de serie, după ce va fi identificată soluţia optimă. În consecinţă planul de afaceri se va axa pe modelul firmei SC RomData AQ srl, deoarece activitatea productivă viitoare (ca rezultat al proiectului de investiţie) va fi efectuată de această entitate. Se va urmări modul în care va creste competitivitatea economică a firmei SC RomData AQ srl, ca rezultat al preluării know-how-ului generat de activitatea de cercetare dezvoltare a Universităţii din Craiova în colaborare cu SC IPA SA. Planul de Afaceri va încerca să dovedească faptul că proiectul este durabil şi că societarea RomData AQ SRL, parteneră în cadrul proiectului, care va prelua rezultatele activităţii de cercetare din cadrul proiectului, după realizare, dovedeşte durabilitate financiara şi are suficientă capacitate financiară si managerială de a menţine afacerea viabilă. Implementarea acestui proiect va duce la cresterea competitivitatii economice a intreprinderilor la care se va implementa, care vor realiza o activitate viabila din punct de vedere economico financiar, dar si la cresterea competitivitatii beneficiarilor indirecti ai proiectului, prin faptul ca vor dispune de un sistem care le va permite eficientizarea activitatilor de productie. 48

49 SCIPA - Stabilirea cerinţelor în contextual lumii reale 49

50 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi SCIPA Servicii software semantice de Colaborare si Interoperabilitate pentru realizarea Proceselor Adaptive de business Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Autori Universitatea din Craiova Contract nr / Autoritatea contractantă: CNMP Pagina Web:

51 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi CUPRINS Partea III Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Agenţi Definiţii Autonomia agenţilor Autonomia faţă de utilizator Autonomia socială Autonomia faţă de norme Modelarea conceptului de autonomie Arhitecturi Arhitectura unui agent cu autonomie adaptabilă Servicii software Arhitectura orientata pe servicii Conceptul de serviciu Servicii Web Introducere Tehnologii Arhitectura Standarde si instrumente pentru servicii Web Standarde pentru servicii Web SOAP SOAP Envelope WSDL UDDI Instrumente pentru servicii Web AXIS Standardele FIPA Principalele specificatii FIPA Structura unui mesaj FIPA ACL Tipuri de mesaje FIPA ACL Limbajul FIPA-SL pentru specificarea mesajelor semantice Protocoale de interactiune Platforme de agenti FIPA JADE Despre JADE Arhitectura Framework de baza Comunicarea intre agenti Comportamentul agentilor (Agent Behaviour) Bibliografie / 2/6/2009

52 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Partea III Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Rezumat Scopul acestei sectiuni a raportului este prezentarea rezultatelor unui studiu de evaluare a domeniului agentilor cognitivi din punctul de vedere al ofertarii de servicii si coordonarii prin protocoale de interactiune. Evaluarea are in vedere trei aspecte : conceptele de baza, principalele standarde existente, si suportul oferit de instrumentele software actuale. 3/ 2/6/2009

53 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi 1 Agenţi 1.1 Definiţii Deşi nu exista o definiţie unică, general acceptată a agenţilor artificiali (software sau hardware), marea majoritate a definitiilor propuse (şi nu sunt de loc putine, de exemplu definiţiile citate în [FRA96]) includ ca o proprietate fundamentala a acestora autonomia. Astfel, autonomia este o noţiune centrală în majoritatea definiţiilor agenţilor inteligenţi. Exemplificăm acest lucru prin indicarea unor definiţii existente în literatura de specialitate. Un agent este o entitate care percepe mediul înconjurător şi acţionează asupra lui [RUS97]. Agenţii inteligenţi sunt entităţi logice care realizează operaţii în locul unui utilizator sau al altui program, având un anumit grad de independenţă sau autonomie, şi pentru a realiza acest lucru foloseşte cunoştinţe şi reprezentări ale scopurilor sau dorinţelor utilizatorului (Agentul IBM). Un agent este o entitate care funcţionează în mod continuu şi de manieră autonomă într-un mediu în care alte procese se desfăşoară şi alţi agenţi există. [SHO93]. Un agent este o entitate autonomă, reală sau abstractă, care este capabilă să acţioneze asupra să şi a mediului inconjurător, entitate care într-un univers multi-agent poate comunica cu alţi agenţi, iar comportamentul său este o consecinţă a observaţiilor, cunoştinţelor şi interacţiunilor cu alţi agenţi [FEB95]. Un agent este o entitate software sau hardware caracterizată prin următoarele proprietăţi [WOO95]: - Conectat - agentul este capabil de a acţinona asupra mediului său, pornind de la intrările senzoriale pe care le primeşte din mediu; - Autonom - agentul este capabil să acţioneze fără intervenţia altuia (agent sau persoană) şi să îşi controleze propriile acţiuni şi stări interne; - Proactiv - agentul trebuie să fie dotat cu un comportament oportunist, să fie capabil să ia iniţiativa la momentul potrivit; - Capabil de un răspuns în timp - agentul tebiue să fie capabil de a percepe mediul înconjurător şi de a elabora un răspuns într-un anumit interval de timp; - Social- agentul trebuie să fie capabil să interacţioneze cu alţi agenţi (logici sau umani) pentru a îndeplini diverse sarcini sau de a juta pe ceilalţi agenţi să le îndeplinească. Intr-un sistem multi-agent (SMA), un agent intra în interacţiune cu alti agenţi (artificiali sau umani), deci agenţii au o dimensiune sociala. Deoarece agenţii sunt autonomi, una din cele mai dificile probleme şi bariere actuale ale adoptarii pe scara larga a paradigmei SMA este caracterul nedeterminist al comportarii ce rezulta din interactiuni dinamice intre componente autonome [GRE01]. Arhitecturi de agenţi existente arată că noţiunea de autonomie este strâns legată de capacitatea de luare a deciziilor a agentului inteligent. Diversitatea definiţiilor, arhitecturilor şi implementărilor existente arată că nu există o definiţie unitară şi comună a noţiunii de autonomie. 4/ 2/6/2009

54 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Specificarea precisă a noţiunii de autonomie şi a implicaţiilor unei comportari autonome ar putea conduce la rezolvarea, cel putin partiala daca nu totala, a problemei comportamentului nedeterminist al agenţilor autonomi. Cu toate ca exista numeroase cercetari care s-au orientat şi se orienteaza spre aceasta directie, nu exista pana în prezent o definiţie unica a autonomiei ci diferite definitii care, de multe ori, se refera la concepte diferite. 1.2 Autonomia agenţilor Autonomia faţă de utilizator Una dintre seminificatiile frecvente ale notiunii de autonomie este autonomia agentului fata de utilizator: masura în care agentul alege şi urmareste autonom scopuri sau, alternativ, consulta utlizatorul pentru prioritatea scopurilor şi a modului de satisfacere a acestora. Capacitatea agentului de a parcurge tot spectrul de la o comportare total autonoma la una total dependenta de utilizator este numita la ora actuala autonomie adaptabila [37, 39] şi este identificata ca o caracteristica de dorit în aplicatiile de calcul omniprezent şi pentru construirea dispozitivelor inteligente interconectate Autonomia socială O semnificatie oarecem alternativa a autonomiei este data în context social cu referire la capacitatea agenţilor de a delega scopuri şi, respectiv, de a adopta sau nu scopurile altor agenţi [5, 23]. În [LUC98] autonomia sociala este capacitatea agenţilor de a genera noi scopuri pe baza motivatiilor iar în [CAS00] autonomia este bazata pe teoria dependentelor sociale Autonomia faţă de norme O semnificatie recenta a notiunii de autonomie este data în contextul cercetarilor actuale despre sistemele de norme în SMA. Una din solutiile propuse recent pentru reducerea gradului de nedeterminism al comportarii agenţilor intr-un SMA este utilizarea legilor sociale sau a normelor ce trebuie respectate de toti agenţii din sistem. Intr-un astfel de sistem, agenţii trebuie să fie capabili să recunoasca, să inteleaga şi să aplice normele existente [21, 22]. Cu toate acestea, în functie de anumite situatii sau context, agenţii pot decide să nu respecte anumite norme, aparand astfel o noua semnificatie a autonomiei, respectiv autonomia fata de norme [VEN99, CCD99] Modelarea conceptului de autonomie Una din concluziile care s-a impus după studiul diferitelor tipuri de autonomii menţionate în literatură a fost aceea că autonomia nu trebuie considerată ca o proprietate absolută ci trebuie văzută în funcţie de entităţile şi actorii implicaţi în decizia autonomă dar şi dependentă de context şi de relaţiile care se stabilesc între agenţi autonomi şi între agenţi şi utilizatori. Nu se poate vorbi despre un autonomia unui agent fără a specifica faţă de ce este agentul autonom, şi anume obiectul autonomiei, şi faţă de cine este agentul autonom, şi anume cel care poate influenţa autonomia (faţă de cine este autonom). De exemplu, un agent personal al unui utilizator poate fi autonom faţă de alţi agenţi personali în selectarea unor informaţii de interes pentru utilizator şi poate fi autonom faţă de utilizator în elimnarea mesajelor electronice ce cuprind reclame de produse. Agentul poate să nu fie autonom faţă de 5/ 2/6/2009

55 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi utilizator din punct de vedere al trierii mesajelor venite de la prieteni şi poate să nu fie autonom faţă de alţi agenţi personali dacă aşteaptă de la aceştia noi adrese Web unde pot fi găsite informaţii de interes pentru utilizator. În plus, autonomia trebuie considerată în contextul de acţiune al agentului. De exemplu, în cazul autonomiei sociale, nu se paote spune pur şi simplu că un agent are sau nu autonomie socială, ci dacă agentul are autonomie socială faţă de un alt agent (software sau uman) pentru decizia relativă la o anumită entitate (de exemplu adoptarea unui scop, executarea unei acţiuni, etc.) şi într-un context dat. Se pot identifica, de asemenea, două perspective ale autonomiei: autonomia externă care este cea a unui observator (utilizator, alt agent) şi autonomia internă, care este cea a agentului şi de fapt, este cea a proiectantului agentului. Din prima perspectivă, spunem că un agent este sau nu autonom dacă comportarea lui nu poate sau poate să fie impusă de o sursă externă. Din perspectiva internă, un agent este autonom sau nu dacă este proiectat astfel încât să manifeste un comportament autonom sau nu. Beavers şi Hexmoor [BEV03] spun că nu poate exista autonomie fără intenţia agentului de a fi autonom. Suntem de acord cu aceast punct de vedere şi spunem că un agent, pentru a fi autonom, trebuie să aibă intenţia să se comporte autonom. Acesta este cazul autonomiei explicite a agenţilor. Există însă şi cazul autonomiei implicite, agentul cu autonomie implicită fiind acel agent al cărui comportament autonom este codificat direct în aplicaţie. Autonomie externă Explicită Implicită Autonomie internă Faţă de cine Utilizator Societate Norme Obiect Dorinţe Scopuri Intenţii Convingeri C O N T E X T Figura 1. Dimensiunile noţiunii de autonomie a agenţilor 1.3 Arhitecturi Arhitectura unui agent cu autonomie adaptabilă Agenţii au o structură BDI [WOO95] şi presupunem că dorinţele agenţilor sunt consistente, formând deci mulţimea de scopuri. Scopurile agentului pot fi realizate pe baza execuţiei unor taskuri. Există două tipuri de taskuri: taskuri specifice (ST) şi taskuri cooperative (CT). Un task specific poate fi executat de către agentul individual pe când un task cooperativ necesită intervenţia mai multor agenţi. Pentru executarea unui task cooperativ agenţii trebuie să realizeze coordonarea execuţiei taskului cooperativ. În plus, în sistem există un set de norme pe care agenţii ar trebui să le respecte. Fiecare task are asociat un câştig 6/ 2/6/2009

56 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi pentru agentul care îl execută şi încălcarea unei norme din sistem are asociată o penalizare pentru agentul care a încălcat norma. Taskurile pe care un agent le alege pentru a fi executate se transformă în angajamente. Un agent poate să formeze mai multe tipuri de angajamente: - angajamente de tip acţiune pe care să le execute el însuşi; - angajamente de tip acţiune pe care să le delege altor agenţi; - angajamente de tip comunicare, respectiv acţiuni comunicative care implică transmiterea unor mesaje. Taskurile pot fi generate de trei surse: de agentul însuşi, primite spre adoptare dacă au fost delegate de alt agent agentului în cauză; generate de normele din sistem. Figura 2 prezintă arhitectura agenţilor din sistem. Modulul de generare taskuri (Task Generation) generează cele trei tipuri de taskuri iar acestea sunt trimise către modulul de luare a deciziilor (Decision-Making). Un task este structurat şi realizat pe baza unui plan, plan care se formează de către o componentă de planificare pe baza bibliotecii de planuri (Plan Library). Există două tipuri de planuri: planuri pentru executarea unui unui task specific şi planuri pentru executarea unui task cooperativ. Planul pentru executarea unui task cooperativ include delegarea de taskuri sau subtaskuri către alţi agenţi. Dacă un agent a hotărât să delege un task, atunci planul corespunzător trebuie să includă şi acţiuni comunicative prin care agentul să transmită delegarea taskului către un alt agent şi să aştepte răspunsul de la acesta. Protocolul de comunicare este preluat dintr-o bibliotecă de protocoale (Protocol Library). Procesul de decizie asupra alegerii unui scop de îndeplinit şi a creării unui angajament pentru taskul asociat este iniţiat fie dacă modulul mediu (Environment) detectează o nouă stare a mediului fie dacă un agent primeşte o cerere de adoptare a unui task de la un alt agent prin modulul de comunicare (Communication Module). Modulul de luare a deciziilor este cel care va decide asupra angajamentelor asumate de agent la un moment dat, în funcţie de taskurile potenţiale disponibile sau propuse agentului şi în funcţie de autonomia agentului. Modulul de luare a deciziilor include doua componente: componenta efectivă de luare a deciziilor care alege dintre taskurile candidate cele care pot fi indeplinite în functie de preferintele agentului, în particular acea de maximizare a câştigului ţinând cont de norme. O a doua componenta este componenta de meta-decizie care implementează comportamentul autonom al agentului în funcţie de dimensiunile specificate în secţiunea anterioară (figura 1). Angajamentele asumate sunt apoi transmise modulului de planificare (Scheduler) în care taskurile sunt ordonate în functie de durata, prioritate şi termen de execuţie. Fig. Arhitectura agentului cu autonomie adaptabilă Plan library Protocol library AGENT environment state regenerate reselect Task Generation tasks generated from norms, by itself or delegated by others Decision-Making Module commitments Adopted norms new message Scheduler receive send 7/ 2/6/2009 Comm. Module action result Env. Module Other agents Environment

57 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi 2 Servicii software 2.1 Arhitectura orientata pe servicii Conceptul de serviciu O tendinta moderna in construirea sistemelor distribuite ce promoveaza orientarea pe obiect si reutilizarea este de a descompune aplicatiile in multimi de componente si de a incapsula functionalitatea oferita de acestea sub forma de servicii. In acest fel aplicatiile distribuite se transpun in multimi de servicii expuse utilizatorilor umani sau artificiali si respectiv interni sau externi. O definitie generala a conceptului de serviciu conform [SM05] este: useful labour that does not produce a tangible commodity. In cadrul proiectului SCIPA suntem interesati de servicii livrate prin software ce furnizeaza la cerere resurse de calcul sau resurse informationale necesare pentru implementarea proceselor adaptive de business. Conform [SM05], serviciile software cuprind urmatoarele categorii: Servicii utilizator inteligente si adaptive la context. Acestea sunt servicii de inteligenta ambientala ce ofera utilizatorilor abilitatea de acces convenabil la diverse functionalitati, de oriunde, oricand si de pe orice tip de dispozitiv. Servicii informationale. Acestea sunt servicii prin care se ofera informatie personalizata sau cu valoare adaugata, spre exemplu prin compararea, clasificarea, sau rezumarea uneia sau mai multor surse de informatie. Servicii de intermediere. Acestea sunt servicii care sprijina gasirea altor servicii corespunzator cerintelor clientilor. Servicii dependente de locatie. Reprezinta o familie de servicii a caror functionalitate depinde de cunoasterea locatiei geografice a utilizatorului disponibila prin intermediul dispozitivelor mobile. Un serviciu software furnizeaza o functionalitate precisa prin intermediul unei interfete software bine definite. Serviciile pot fi compuse in scopul definirii unor servicii complexe. Serviciile necesita definirea rolurilor de furnizor si respectiv consumator de servicii. Un furnizor ofera un serviciu spre a fi folosit de unul sau mai multi consumatori, fara ca acestia sa trebuiasca sa cunoasca detaliile interne de implementare ale serviciului respectiv. Consumatorii pot fi la randul furnizori de servicii compuse, bazate pe serviciile oferite de alti furnizori. 2.2 Servicii Web Introducere La ora actuala nu exista o definitie unanim acceptata a termenului de serviciu Web. Cu toate acestea principalele definitii propuse in literatura de specialitate sau de catre diversele organisme de standardizare fac apel la concepte si tehnologii relativ independente de diversele moduri de interpretare. 8/ 2/6/2009

58 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Intr-un sens foarte larg prin serviciu Web se poate intelege orice aplicatie care este accesibila altor aplicatii prin intermediul Web-ului. Conform acestei definitii orice aplicatie care are un URL public este un serviciu Web, de la un script CGI pana la o aplicatie stabila cu o interfata de programare precisa, posibil descrisa intr-un serviciu de directoare. Conform organismului de standardizare OASIS, serviciile Web permit aplicatiilor sa comunice independent de platforma si limbajul de programare folosind protocoale standard bazate pe XML [OA-WS08]. Aceasta definitie evidentieaza urmatoarele aspecte ale unui serviciu Web: independenta de platforma si de limbajul de programare, standardizarea protocoalelor de comunicare si folosirea XML. Clarificari suplimentare asupra diverselor definitii ale serviciilor Web sunt aduse de Consortiul Web. Din pacate, nici acest organism nu reuseste sa furnizeze o unica definitie a serviciilor Web. Astfel, conform [WSARCH04], un serviciu Web este un sistem software proiectat pentru a sprijini interoperabilitatea interactiunilor intre calculatoare intr-o retea. El are o interfata descrisa printr-un format procesabil de calculator (mai precis WSDL). Alte sisteme interactioneaza cu un serviciu Web intr-o maniera prestabilita in descrierea sa, folosind mesaje SOAP transportate utilizand HTTP cu serializare XML si in conformitate cu alte standarde Web. Conform [Web Services Architecture Requirements, 2004], un serviciu Web este un sistem identificat printr-un URI, ale carui interfete publice si legaturi sunt definite si descrise folosind XML. Definitia sa poate fi descoperita de alte sisteme software. Aceste sisteme pot interactiona cu serviciul Web intr-o maniera prestabilita de definitia sa, utilizand mesaje bazate pe XML [XML08] si transportate de protocoalele Internet. In cadrul proiectului SCIPA vom adopta punctul de vedere din [ACKM04] si vom considera ca serviciile Web reprezinta o modalitate de a expune functionalitatea unui sistem informatic si de a o face disponibila altor aplicatii prin tehnologii Web standardizate. In acest fel serviciile Web deschid in mod natural perspective pentru noi arhitecturi si paradigme in directia calculului orientat pe servicii Tehnologii Din definitiile expuse rezulta ca tehnologia serviciilor Web trebuie sa resolve urmatoarele patru probleme: descrierea, descoperirea, interactiunea si compunerea. Cea mai importanta dintre organizatiile care se ocupa cu specificatiile serviciilor Web este World Wide Web Consortium (W3C). Consortiumul W3C administreaza specificatiile legate de SOAP, WSDL, XML, XML Schema, HTTP, etc. W3C administreaza, de asemenea arhitectura serviciilor web, WS-Architecture. Acest document stabileste o definitie formala a serviciilor Web. O alta organizatie importanta in lumea serviciilor web este organizatia Organization for the Advancement of Structured Information Standards (OASIS). OASIS administreaza specificatiile pentru UDDI, securitatea serviciilor web (WS-Security), SAML, etc. Urmatoarele standarde sunt considerate principalele standarde pentru serviciile web: SOAP. Termenul SOAP provine de la Simple Object Access Protocol. SOAP este o specificatie care defineste o gramatica XML pentru trimiterea si primirea de mesaje. Scopul specificatiei SOAP este acela de a descrie un format de mesaje care sa nu depinda de 9/ 2/6/2009

59 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi arhitectura hardware sau software, capabil sa transmita si sa receptioneze mesaje la/de la orice platforma. Extensible Markup Language (XML). XML este un meta-limbaj de baza peste care sunt construite limbajele pentru serviciile Web. XML este mai mult un meta-limbaj decat un limbaj, deoarece este folosit pentru a crea gramatici. Aceste gramatici sunt descrise in scheme XML care specifica tag-urile care sunt permise de legaturile dintre elementele definite de aceste tag-uri. SOAP, WSDL si UDDI sunt gramatici bazate pe XML. Hypertext Transport Protocol (HTTP). Protocolul HTTP este un standard care precede aparitia serviciilor Web. Acesta a fost dezvoltat pentru a facilita trasnsferul de cereri dintre navigator (browser) si serverul Web. Serviciile Web beneficiaza de avantajul existentei acestui protocol matur cu ajutorul caruia se transmit mesaje SOAP si documente WSDL de la un calculator la altul. Versiunile mai noi de SOAP descriu cum alte mecanisme de transport ca FTP, SMTP si JMS pot fi folosite pentru a realiza aceeasi functie. Totusi majoritatea serviciilor Web este construite pe protocolul HTTP. Web Services Description Language (WSDL). Limbajul WSDL este o specificatie despre modalitatea de a descrie un program software in functie de apelurile de metode la care trebuie sa raspunda. Aceste metode sunt descrise intr-un mod abstract care este independent de limbajul de programare in care este scris serviciul, de calculator sau de sistemul de operare. WSDL contine, de asemenea, o sectiune in care sunt descrise detalii de conectare la serviciu. Universal Discovery Description Integration (UDDI). Specificatia UDDI descrie cum un potential client al serviciului Web poate invata despre capabilitatile serviciului si cum poate obtine informatia de baza necesara pentru a face contactul cu site-ul. Acest contact include si descarcarea documentului WSDL. Registrii UDDI pot fi publici, privati sau semiprivati Arhitectura Un serviciu Web este o functionalitate software accesibila in retea si construita pe tehnologii independente de platforma, limbaj de programare si componente. Serviciile Web se bazeaza pe Service-Oriented Architecture (SOA) unde functionalitatea software este distribuita intr-un set de servicii. Pentru ca un serviciu sa existe in domeniul SOA, este necesar un mecanism care sa descrie, sa descopere si sa faca apel la servicii. In figura urmatoare se observa diferite roluri si interactiunile dintre aceste roluri intr-o arhitectura orientata pe servicii. 10/ 2/6/2009

60 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Figura 2.1. Arhitectura orientata pe servicii Arhitectura SOA descrie 3 roluri de baza (vezi figura 2.1): Service Provider. Furnizorul de servicii este responsabil cu implementarea serviciilor Web. Prima sarcina pe care un service provider trebuie s-o indeplineasca este de a determina functionalitatea pe care o ofera ca serviciu. O data ce au realizat acest lucru, trebuie sa descrie interfata acestei functionalitati intr-o metoda standard. In final, trebuie sa publice aceasta interfata intr-un registru pentru a oferi consumatorilor de servicii posibilitatea de a-si gasi servicii web. Service Registry. Registrul de servicii functioneaza ca un repozitoriu de servicii Web. Ofertantii de servicii publica in acest registru definitiile serviciilor lor. Prin urmare, registrele de servicii au facilitate de publicare a serviciilor web si functioneaza ca un repozitoriu pentru consumatorii de servicii, pentru a le permite acestora sa gaseasca aceste servicii Web si de a le asigura informatia necesara pentru a apela serviciul Web. Service Consumer. Consumatorul de servicii foloseste serviciile Web create de ofertantul de servicii. Regaseste toata informatia necesara pentru a se conecta (bind) la serviciul web din registrul de servicii, incluzand interfata la serviciul respectiv publicat de provider-ul de servicii. Interfata ofera detalii ale metodelor, parametrilor si protocolului de transport necesar pentru utilizarea lui. SOA definit mai sus este un model abstract, dar are totusi cateva instantieri concrete. Una din aceste instantieri o reprezinta stiva de specificatii pentru servicii Web. Aceasta descrie tehnologiile folosite pentru a asigura functiile descrise mai sus: gaseste, conecteaza si publica. Figura 2.2 prezinta o aceasta stiva impreuna cu tehnologiile necesare. La nivelul cel mai de jos este nivelul de transport responsabil cu comunicarea intre porturile de comunicare care pot trimite si primi mesaje. Tehnologiile de servicii Web protejeaza investitia in tehnologiile de retele existente, folosind unele mecanisme de transport deja existente si foarte des folosite, in special HTTP. Este important de stiut ca se poate folosi orice protocol de transport. Cu un nivel mai sus se gaseste nivelul de mesaje, responsabil cu invocarea serviciilor web de catre consumator. Aici consumatorul foloseste mesaje SOAP pentru a apela metodele oferite de serviciul Web si ofertantul de servicii descrie interfata respectiva intr-o metoda standard cu WSDL (Web Services Description Language). Pe cel mai de sus nivel se afla descoperirea serviciilor Web, implementata in UDDI (Universal Description and Discovery Interface). 11/ 2/6/2009

61 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Figura 2.2. Stiva de servicii Web 12/ 2/6/2009

62 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi 3 Standarde si instrumente pentru servicii Web 3.1 Standarde pentru servicii Web SOAP SOAP (Simple Object Access Protocol) este un format bazat pe XML si permite apel la distanta (Remote Procedure Calls) si transport de mesaje peste orice protocol de retea, dar in special peste HTTP [SOA07]. Deoarece se foloseste formatul XML in locul celui binar, acesta este interoperabil intre platforme, limbaje de programare, componente, etc. Deoarece este bazat pe mesaje, SOAP poate fi usor implementat peste protocoale de retea asincrone cum ar fi SMTP sau JMS Java Messaging Services. SOAP are cateva avantaje comparativ cu predecesorul sau, protocol XML-RPC. XML- RPC Protocol este un protocol simplu care permite apeluri la distanta folosind XML pentru codificare si HTTP pentru protocolul de transport. SOAP este construit pe baza acestui protocol, oferind suport pentru tipuri de date complexe si diferite protocoale de transport, impreuna cu posibilitatea de a specifica exact metoda de procesare a mesajelor. W3C a inceput lucrul la formatul SOAP in 1999 [SOA07]. In prima versiune (1.0) a specificatiilor, SOAP era in intregime bazat pe HTTP. In urmatoarea revizie a specificatiilor (SOAP 1.1, Mai 2000), SOAP a fost pus deasupra mai multor protocoale de transport. In mai 2003, W3C a propus versiunea SOAP 1.2, versiunea revizuita. Versiunea curenta este SOAP 1.2 care clarifica si adauga aspecte semantice peste SOAP 1.1 in termenii legarii de protocoale de transport si codificarii XML. SOAP defineste modul de organizare a informatiei utilizand XML intr-o forma structurata, si specifica urmatoarele: Un format de mesaj pentru comunicarea unidirectionala, descriind cum poate fi impachetata informatia intr-un document XML. Un set de conventii pentru folosirea mesajelor SOAP pentru a implementa modelul de interactiune RPC, definind cum clientii pot invoca o procedura aflata la distanta prin trimiterea de mesaje SOAP si cum serviciile pot raspunde prin trimiterea unui alt mesaj SOAP inapoi la apelant. Un set de reguli pe care fiecare entitate care proceseaza un mesaj SOAP trebuie sa le urmareasca, definind in particular elemente XML pe care entitatea trebuie sa le citeasca si intelege si actiuni pe care entitatile trebuie sa le ia daca nu inteleg continutul. O descriere a modalitatii in care mesajul SOAP trebuie sa fie transportat cu un protocol de transport (HTTP, SMTP). Ca si protocol de comunicare, SOAP este fara stare si unidirectional. De asemenea, SOAP ignora aspectele semantice ale mesajelor. Un mesaj SOAP este un document XML care consta din urmatoarele 3 parti prezentate, mai jos. <SOAP-ENV: Envelope xmlns: SOAP-ENV=" 13/ 2/6/2009

63 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi xmlns: xsd=" xmlns: xsi=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Header>... </SOAP-ENV:Header> <SOAP-ENV:Body>... </SOAP-ENV:Body> </SOAP-ENV:Envelope> SOAP schimba informatie, folosind mesaje [ACKM04]. Aceste mesaje sunt folosite ca un plic (envelope) unde aplicatia inchide orice informatie care trebuie trimisa. Fiecare plic (envelope) contine 2 parti: header si body. Elementul header este optional, in timp ce elementul body este obligatoriu. Atat elementul header si body pot avea subparti multiple sub forma de blocuri header si blocuri body. SOAP Envelope SOAP header Header Block SOAP Body Body Figura 3.1. Structura mesajelor SOAP SOAP presupune ca fiecare mesaj are un emitator, un receptor si un numar arbitrar de intermediari (noduri) care proceseaza mesajul si il trimit la receptor. Principala informatie pe care emitatorul o trimite la receptor trebuie sa se gaseasca in corpul mesajului. Informatia aditionala necesara procesarii intermediare (autentificare, securitate, tranzactie, versiune) se gaseste in header. Ideea urmareste metoda din protocoalele standard de comunicare. 14/ 2/6/2009

64 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Exista doua aspecte care influenteaza modul in care sunt construite mesajele SOAP din header si body [SOA07]: stilul de interactiune si regulile de codificare. Stiluri de interactiune pot fi: interactiune bazata pe document si RPC. In interactiunea de tip document, cele doua aplicatii care interactioneaza se pun de acord cu structura documentelor schimbate intre ele. Mesajele SOAP sunt folosite pentru a transporta aceste documente de la o aplicatie la alta. Exemplu de mesaj SOAP care contine cele trei componente: <SOAP-ENV: Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Header> <t:transaction xmlns:t="some-uri" SOAP-ENV: mustunderstand="1"> 5 </t:transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>def</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> a. SOAP Envelope SOAP envelope este elementul radacina obligatoriu al mesajului SOAP. Contine un tag <Header> optional, ce permite specificarea informatiilor aditionale despre mesajul, si un tag obligatoriu <Body> ce contine mesajul propriu-zis, fie el o cerere de la un serviciu sau un raspuns de la server. Elementul <Envelope> poate fi comparat cu plicul unei scrisori. b. Header-ul SOAP Specificatia SOAP nu defineste cum sunt utilizate caracteristici precum autentificare, securitate, tranzactie, versiune etc. Totusi, aplicatiile au posibilitatea de a extinde protocolul prin adaugarea de informatie in tag-ul <Header>. De exemplu, poate fi folosit acest element pentru a adauga informatie despre securitate: <SOAP-ENV:Header> <axis:security xmlns:axis=" <axis:loginid> </axis:loginid> </axis:security> </SOAP-ENV:Header> Marcajul <Header> are 2 atribute: mustunderstand si actor amandoua extrem de importante. Acestea sunt componente intre clientul SOAP si serverul SOAP, procesand atat raspunsul cat si cererea mesajului. De exemplu, instrumentul AXIS asigura suport pentru intermediarii SOAP, permitand introducerea propriilor handle-re care pot intercepta cererea si/sau raspunsul. 15/ 2/6/2009

65 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Atributul mustunderstand indica destinatarului mesajului SOAP (intermediar sau final) faptul ca atributul header trebuie procesat obligatoriu. Daca valoarea atributului mustunderstand este 1, trebuie recunoscut elementul <Header> si procesat. Daca elementul nu este recunoscut, trebuie raportata o exceptie ca SOAP Fault. Daca mustunderstand este setat pe 0, procesarea elementului este optionala. Un exemplu de atribut mustunderstand este prezentat mai jos: <SOAP-ENV:Header> <axis:transaction xmlns:axis=" SOAP-ENV:mustUnderstand="1"> <axis:transactionid> </axis:transactionid> </axis:transaction> </SOAP-ENV:Header> Atributul actor specifica cine trebuie sa proceseze informatia din header. Actorul poate fi: none, next, ultimatereceiver. Daca actorul este none atunci informatia din header nu este necesar sa fie procesata; next indica ca un nod care primeste mesajul poate procesa blocul din header; ultimatereceiver indica ca header-ul este procesat in recipientul final al mesajului. c. SOAP Body Elementul <Body> defineste continutul mesajului. Elementul poate fi un apel RPC sau un mesaj. Poate de asemenea contine SOAP fault in caz de eroare. Specificatia SOAP descrie cum un apel RPC este mapat in structura XML. De exemplu, sa presupunem ca avem nevoie sa invocam, folosind SOAP, metoda getprice() a obiectului SparePartPrice. Metoda primeste ca si parametru un sir de caractere (identificatorul obiectului) si returneaza un numar de tip float (pretul obiectului). Serializarea SOAP RPC a acestui apel va fi ca in exemplul de mai jos: <SOAP-ENV:Envelope...> <SOAP-ENV:Header>...</SOAP-ENV:Header> <SOAP-ENV:Body> <ns1:getprice xmlns:ns1="sparepartprice"> <sku xsi:type="xsd:string">sku-123</sku> </ns1:getprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Primul element copil in elementul <Body> identifica metoda getprice() a obiectului. Spatiul de nume ns1 indica obiectul. Acesta are, de asemenea, elemente copil care indica numarul necesar de parametri pentru a invoca metoda getprice(). In mod similar, cand primim raspunsul, se va obtine: <SOAP-ENV:Envelope...> <SOAP-ENV:Header>...</SOAP-ENV:Header> <SOAP-ENV:Body> <ns1:getpriceresponse xmlns:ns1="sparepartprice"> <getpriceresult xsi:type="xsd:float">10.99</getpriceresult> 16/ 2/6/2009

66 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi </ns1:getpriceresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> In acelasi timp, exista o mare flexibilitate a folosirii mesajului de tip document-based protocol in loc de mecanismul RPC descris mai sus. Pentru stilul document-based mecanismul este urmatorul: se trimita mesajul serverului SOAP, serverul SOAP proceseaza mesajul si trimite un raspuns. Diferenta este ca acum se lucreaza cu un mesaj intreg in loc de obiecte, metode si parametri. Pe scurt, elementul <Body> contine intregul document XML care va fi interpretat si procesat de destinatar. Protocolul bazat pe document este important pentru tranzactii electronice bazate pe standarde, precum ebxml, RosettaNet etc. unde intreg documentul XML contine detalii despre tranzactie. De exemplu, un protocol bazat pe document poate avea o cerere de forma: <SOAP-ENV:Envelope...> <SOAP-ENV:Header>...</SOAP-ENV:Header> <SOAP-ENV:Body>...[XML Document as Request] e.g. ebxml Payload / RosettaNet Payload </SOAP-ENV:Body> </SOAP-ENV:Envelope> Raspunsul este similar: <SOAP-ENV:Envelope...> <SOAP-ENV:Header>...</SOAP-ENV:Header> <SOAP-ENV:Body>...[XML Document as Response] </SOAP-ENV:Body> </SOAP-ENV:Envelope> d. Tratarea erorilor in SOAP Specificatia SOAP mentioneaza, de asemenea ca toate erorile ar trebui raportate ca elemente SOAP <Fault>. Elementul <Body> al mesajului de raspuns SOAP poate contine elementul <Fault> ca in exemplul, de mai jos: <SOAP-ENV:Body> <Fault> <faultcode>...</faultcode> <faultactor> </faultactor> <faultstring> </faultstring> <detail> </Fault> </detail> </SOAP-ENV:Body> Un element <Fault> contine elementele <faultcode>, <faultactor>, <faultstring> si <detail>. 17/ 2/6/2009

67 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Elementul <faultcode> este folosit pentru a indica sursa erorii. Poate avea urmatoarele valori: VersionMismatch: indica faptul ca destinatarul mesajului nu intelege atributul namespace al elementului <Envelope>. MustUnderstand: indica faptul ca destinatarul elementului copil al elementului <Header> are un atribut MustUnderstand dar destinatarul nu a inteles acest atribut. Client: indica faptul ca mesajul SOAP nu contine toata informatia necesara destinatarului pentru procesare. Un motiv poate fi faptul ca lipseste informatie din elementul <Body> sau ca mesajul a fost format incorect. Este in general un indiciu ca mesajul nu trebuie retrimis fara modificari. Server: indica faptul ca destinatarul mesajului nu a fost capabil sa proceseze mesajul din cauza unor probleme de partea serverului. Cel mai probabil eroarea nu se datoreaza continutului mesajului. Elementul <faultactor> este folosit pentru a identifica serviciul care a cauzat eroarea. Elementul <faultstring> ofera o descriere mai detaliata a erorii. Elementul <detail/> ofera mai multa informatie specifica aplicatiei. Trebuie sa fie prezenta daca elementul <Body> nu poate fi procesat. e. Legatura dintre SOAP si protocoalele de transport Legarea formatului SOAP la un protocol de transport reprezinta descrierea modalitatii in care mesajele SOAP sunt trimise folosind protocolul de transport. SOAP nu impune folosirea unui anumit tip de protocol de transport [ACKM04]. Cel mai comun protocol pentru SOAP este HTTP, dar pot fi folosite si alte protocoale cum ar fi SMTP. SOAP poate folosi GET sau POST. Cu GET, cererea nu este un mesaj SOAP, dar raspunsul este un mesaj SOAP, cu POST, atat cererea cat si raspunsul sunt mesaje SOAP. SOAP foloseste aceleasi erori si coduri de stare ca si HTTP. SOAP este independent de protocolul de Internet folosit pentru transmiterea mesajelor. Totusi, specificatia SOAP defineste legaturile pentru cererile HTTP POST. Prin urmare legatura cu HTTP defineste relatia dintre partile mesajului SOAP si header-ele HTTP. Cele mai intalnite elemente intr-o cerere SOAP sunt Content-Type, Content-Length si un antet SOAPAction. Mesajul SOAP este transmis ca si continutul unei cereri sau al unui raspuns HTTP. Sa consideram ca exemplu urmatoarea tranzactie SOAP care invoca metoda getprice() a obiectului SparePartPrice. Metoda getprice() are un singur parametru si returneaza valoarea indicata de pret. Cererea SOAP este mai jos: POST /axis/services HTTP/1.0 Content-Length: 445 Host: localhost Content-Type: text/xml; charset=utf-8 SOAPAction: "" <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle=" 18/ 2/6/2009

68 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi xmlns:soap-env=" xmlns:xsd=" xmlns:xsi=" <SOAP-ENV:Body> <ns1:getprice xmlns:ns1="sparepartprice"> <sku xsi:type="xsd:string">sku-123</sku> </ns1:getprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> In mod similar, raspunsul SOAP este mapat la raspunsul HTTP ca in exemplul de mai jos: HTTP/ OK Content-Type; text/xml: charset=utf-8 Content-Length: 480 Date: Mon, 11 Feb :10:32 GMT Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector) <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle=" xmlns:soap-env=" xmlns:xsd=" xmlns:xsi=" <SOAP-ENV:Body> <ns1:getpriceresponse xmlns:ns1="sparepartprice"> <getpriceresult xsi:type="xsd:float">10.99</getpriceresult> </ns1:getpriceresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> WSDL Web Services Description Language (WSDL) este un limbaj pentru descrierea interfetelor serviciilor Web. Cu ajutorul sau se pot descrie serviciile Web astfel: metodele care pot fi invocate, parametrii metodelor, tipurile parametrilor, protocolul care va fi folosit, etc. Avand dat un document WSDL al unui serviciu Web se poate scrie un client care sa invoce functionalitatea serviciului Web [WSD07]. Documentul WSDL este un document XML structurat in doua parti: prima este o definitie abstracta a serviciului Web si contine tipuri de date, metode, etc., si a doua contine detalii despre protocolul de transport folosit (HTTP, SMTP, FTP, etc) si implementarea de SOAP folosita. 19/ 2/6/2009

69 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Figura 3.2. Structura documentului WSDL Elementele documentului sunt [WSD07]: Elementul <type> reprezinta tipurile de date folosite in mesajele schimbate in comunicarea cu serviciul Web: float, integer, string, etc. WSDL foloseste specificatiile XML Schema pentru codificarea tipurilor de date. Fiecare element <message> reprezinta o unitate de comunicatie cu serviciul invocat. O operatie in terminologia WSDL reprezinta semnatura metodei si cuprinde legatura dintre mesajele de intrare si iesire. O operatie descrie astfel un schimb simplu de mesaje cu serviciul Web. Elementul <porttype> descrie o multime de operatii expuse de serviciul Web. Fiind asemanator unei interfete din invocarea procedurilor la distanta. Elementul <porttype> contine o colectie de operatii. Elementul <binding> este folosit pentru a specifica protocolul de transport care este folosit (SOAP este folosit peste HTTP, SMTP, posibil si alt protocol de transport) impreuna cu tipul de cerere SOAP (rpc sau document). Un element <service> creeaza legatura cu implementarea actuala a serviciului. Acesta va referi elementul <binding> care este asociat cu elementul <port> ce contine adresa serviciului Web sub forma unui URL. Serviciul Web SparePartPrice are o singura metoda numita getprice(). Metoda getprice() primeste un singur parametru de tip string si returneaza pretul care este de tipul float. Documentul WSDL pentru acest serviciu este urmatorul: Elementul radacina este <definitions>: <wsdl:definitions targetnamespace= xmlns=" xmlns:soap-enc=" xmlns:impl= " xmlns:intf=" 20/ 2/6/2009

70 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi xmlns:wsdl=" xmlns:wsdl=" xmlns:xsd=" Elementele <message> definesc parametrii de intrare (getpricerequest) si de iesire (getpriceresponse), cu tipurile de date potrivite. <wsdl:message name="getpriceresponse"> <wsdl:part name="return" type="xsd:float"/> </wsdl:message> <wsdl:message name="getpricerequest"> <wsdl:part name="in0" type="xsd:string"/> </wsdl:message> Elementul operation este similar cu apelul unei metode in Java. Exista insa diferenta ca numai 3 mesaje sunt permise intr-o operatie: Elementul <input> defineste datele pe care serviciul Web asteapta sa le primeasca ca cereri. Elementul <output> defineste datele pe care serviciul Web asteapta sa le trimita ca raspuns. Elementul <fault> defineste mesajele de eroare care sunt returnate de serviciul Web. Intr-un document WSDL pot fi declarate mai multe tipuri de operatii. Acestea sunt: Request/Response clientul face o cerere si serviciul Web raspunde la ea. Solicit/Response serviciul Web trimite un mesaj la client si clientul raspunde. One-way clientul trimite un mesaj la un serviciu Web, dar nu asteapta nici un mesaj. Notification serviciul Web trimite un mesaj la client dar nu asteapta nici un raspuns. Figura 3.3. Tipul de mesaje transmise intr-o operatie 21/ 2/6/2009

71 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Atributul name al elementului <porttype> identifica obiectul SparePartPrice si operatiile (metodele) lui. Se observa semnatura metodei: intrarea este mesajul getpricerequest() care primeste un string ca parametru si iesirea getpriceresponse() care returneaza un numar de tip float. <wsdl:porttype name="sparepartprice"> <wsdl:operation name="getprice" parameterorder="in0"> <wsdl:input message="intf:getpricerequest"/> <wsdl:output message="intf:getpriceresponse"/> </wsdl:operation> </wsdl:porttype> Elementul <binding> mapeaza elementul <porttype> (SparePartPrice) la un protocol specific. In acest caz elementul se mapeaza la SOAP. <wsdl:binding name="sparepartpricesoapbinding" type="intf:sparepartprice"> <wsdlsoap:binding style="rpc" transport=" <wsdl:operation name="getprice"> <wsdlsoap:operation soapaction="" style="rpc"/> <wsdl:input> <wsdlsoap:body /> encodingstyle=" namespace= " use="encoded" </wsdl:input> <wsdl:output> <wsdlsoap:body /> encodingstyle=" namespace= " use="encoded" </wsdl:output> </wsdl:operation> </wsdl:binding> Elementul <service> face maparea la elementul <port> care reprezinta adresa fizica accesibila a serviciului Web. <wsdl:service name="sparepartpriceservice"> <wsdl:port binding="intf:sparepartpricesoapbinding" name="sparepartprice"> 22/ 2/6/2009

72 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi <wsdlsoap:address location= " </wsdl:port> </wsdl:service> </wsdl:definitions> Structura de date WSDL are implicatii interesante in ceea ce priveste interactiunea dintre servicii. Unele dintre ele sunt legate de tipurile de operatii. Modurile de interactiune care pot fi asociate cu operatii WSDL arata ca un serviciu poate initia interactiunea si un serviciu nu expune doar operatii care sa poata fi invocate, insemnand ca un serviciu poate actiona ca un client. In domeniul serviciilor Web, fiecare entitate de interactiune este modelata, de obicei ca un serviciu WSDL. O alta implicare a specificatiei WSDL este aceea ca nu se presupune o anumita forma particulara pentru schimburile care au loc. De aceea, WSDL poate descrie 2 aspecte ale serviciilor Web: interfata abstracta a serviciului, fara a specifica locatia sau protocolul care se foloseste si partea a doua reprezinta locatia serviciului si protocolul de comunicare folosit [WSD07]. Avantajul acestei separari este acela ca specificatiile WSDL care descriu interfete abstracte pot fi reutilizabile: servicii diferite pot fi combinate in interfete, folosind diferite metode de legare (bindings) si sa le faca disponibile la diverse adrese. Reutilizarea este facilitata, de asemenea, de faptul ca documentele WSDL pot sa importe alte documente WSDL. Se observa, de asemenea, corelatia dintre descrierea WSDL si SOAP. Abilitatea atat a SOAP, cat si a WSDL de a fi capabile sa foloseasca mai multe tipuri de legaturi cu protocoalele de transport si codificarile XML, este aspectul crucial al eforturilor de standardizare a serviciilor Web [WSD07]. WSDL este un standard orizontal in sensul ca acesta poate fi utilizat de o varietate de instrumente si nu contine nici o specificatie a unui domeniu particular. Acesta a fost proiectat ca un limbaj generic de descriere a serviciului. Pe langa WSDL, au fost create numeroase standarde B2B, printre acestea sunt Electronic Data Exchange (EDI) folosit in manufacturing si SWIFT folosit in lumea financiara. Avantajul acestor standarde peste WSDL este acela ca sunt proiectate pentru aplicatii concrete si captureaza aspecte semantice pe care WSDL nu este capabil sa le captureze.este posibil ca unele din aceste standarde sa convearga tot la WSDL, producand standarde hibride care vor fi utilizate in arii de aplicatii concrete, iar alte standarde sa supravietuiasca si sa ramana independente de WSDL UDDI Probabil specificatia UDDI este cea mai elaborata dintre toate specificatiile de pana acum [UOS08]. Ultima versiune este versiunea 1 definea conceptele de baza pentru directoare de servicii de business (business service registry) 23/ 2/6/2009

73 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi versiunea 2 adapteaza lucrul serviciilor de directoare UDDI la SOAP si WSDL versiunea 3 redefineste rolul si scopul directoarelor UDDI, pune in evidenta rolul implementarilor private si se ocupa cu problema interactiunii dintre directoarele UDDI private si publice. Initial, UDDI a fost conceput ca si Universal Business Registry similar cu motoarele de cautare (e.g., Google) si va fi folosit ca mecanism principal pentru a gasi serviciile electronice oferite de companii din lumea intreaga. In prezent, UDDI este cea mai pragmatica specificatie si recunoaste realitatile interactiunilor B2B: acesta este o infrastructura pentru serviciile Web, avand acelasi rol ca si serviciul de nume si director (binder in RPC), dar aplicat serviciilor Web si folosit in medii cu constrangeri (intern intr-o companie sau intr-o multime de parteneri de afaceri). Exista cativa registri UDDI universali mentinuti de IBM, Microsoft, SAP, etc. Acesti registri sunt vizibili, dar din pacate sunt foarte mici si cele mai multe intrari nu functioneaza sau nu corespund unui serviciu real [UOS08]. Serviciile oferite prin Internet companiilor necesita mult mai multa informatie decat intr-un serviciu tipic de middleware. Registrii UDDI se comporta ca si alte servicii Web: Figura 3.4. Registrii UDDI Toate API-urile din specificatiile UDDI sunt definite in XML, localizate in elementele SOAP envelope si trimise peste HTTP. In plus cererile clientilor care necesita modificarea datelor trebuie sa fie securizate si autentificate. O intrare intr-un registru UDDI este un document XML compus din diferite elemente, cele mai importante fiind [UOS08]: businessentity: reprezinta descrierea organizatiei care ofera serviciul. BusinessService: este o lista de servicii Web oferite de entitatea de business. bindingtemplate: descrie aspectele tehnice al serviciului care va fi oferit. tmodel: ( technical model ) este un element generic care poate fi utilizat pentru a memora informatii aditionale despre serviciu, in special informatie tehnica aditionala despre cum se foloseste serviciul, conditiile de utilizare, garantii, etc. Impreuna, aceste elemente sunt folosite pentru a oferi: 24/ 2/6/2009

74 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Informatii despre paginile albe: date despre cel care ofera serviciul (nume, adresa, persoana de contact, etc.) Informatii despre paginile galbene: ce tip de servicii sunt oferite si o lista cu diferitele servicii oferite Informatii despre paginile verzi: informatie tehnica despre cum sunt folosite fiecare din serviciile oferite, incluzand referinte la descrierile WSDL ale serviciilor (care nu se gasesc in registrul UDDI) Entitatea Business Informatia despre paginile generice albe si galbene despre cel care ofera serviciul este memorata in entitatea businessentity, care contine urmatoarele date: fiecare businessentity are un businesskey discoveryurls este o lista de URL-uri Name: contine informatie textuala Business description: contine informatie textuala Contacts: contine informatie textuala businessservices: o lista de servicii oferite de entitatea businessentity identifierbag: o lista de identificatori externi categorybag: o lista de categorii de business (de exemplu, industrie, categorie produs, regiune geografica) Entitatea Business nu trebuie sa fie o companie. Aceasta trebuie sa reprezinte orice entitate care ofera servicii: poate fi un departament, un grup, server sau o multiem de servere, etc. Serviciul Business Serviciile oferite de o entitate de afacere sunt descrise folosind elemente businessservice. Elementul businessservice poate descrie un serviciu Web sau un grup de servicii Web asociate (toate oferite de aceeasientitate businessentity). Binding Template Sablonul de legatura Bindingtemplate contine informatie tehnica asociata unui serviciu particular care consta in: bindingkey servicekey description accesspoint: adresa de retea a servicului oferit ( de obicei un URL) tmodels: este o lista de intrari corespunzatoare elementului tmodels asociat cu un anumit element de legatura. Aceasta lista include referinte la tmodels, documente care descriu tmodels, scurte descrieri, etc. categorybag: informatie aditionala despre serviciu si despre legaturile sale (de exemplu daca este o legatura de test, sau este in productie, etc) businessservice poate avea mai multe bindingtemplates dar un bindingtemplate poate avea doar un businessservice binding template poate fi vazut ca un director unde este memorata informatia tehnica despre serviciu 25/ 2/6/2009

75 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi tmodel tmodel este un container de informatie unde proiectantii pot scrie informatie tehnica asociata cu folosirea unui serviciu Web: interfata si protocolul folosit, incluzand o referinta a descrierea WSDL descrierea protocolui de afacere si conversatiile suportate de serviciu Acesta contine tmodelkey name description overviewdoc: (cu un overviewurl si usetype care indica unde se gaseste informatia si formatul sau, de exemplu text sau wsdldescription ) identifierbag categorybag Interfete UDDI Specificatia UDDI ofera un numar de API-uri (Application Program Interfaces) care dau posibilitatea accesului la un sistem UDDI: UDDI Inquiry: pentru a localiza si gasi detalii in registrii UDDI si suporta navigarea, invocarea, etc. UDDI Publication: pentru a publica si modifica informatia in registrii UDDI. Toate operatiile din acest API sunt atomice in sensul tranzactional. UDDI Security: pentru controlul accesului la registrii UDDI. UDDI Subscription: permite clientilor sa subscrie la schimbarile de informatii din registrele UDDI. UDDI Replication: descrie cum se efectueaza replicarea informatiei in nodurile din registrele UDDI. UDDI Custody si Ownership transfer: folosite pentru a schimba proprietarul (publisher) informatiilor si pentru a transfera custodia de la un nod la altul din registrul UDDI. UDDI ofera de asemenea API-uri pentru clientii sistemul UDDI: UDDI Subscription Listener: partea de client pentru API de subscriere. UDDI Value Set: folosit pentru a valida informatia oferita de un registru UDDI. 3.2 Instrumente pentru servicii Web AXIS2 Pentru a putea crea servicii Web, avem nevoie de anumite instrumente software. In primul rand avem nevoie de un procesor care sa prelucreze mesajele SOAP primite si sa apeleze functii sau metode pe care aceste mesaje le indica. Pe piata exista mai multe produse care sa raspunda acestor cerinte. In plus, unele dintre ele ofera si alte instrumente care sa ajute dezvoltatorul sa scrie cod necesar crearii de servicii Web. Unul dintre aceste produse este Apache Software Foundation s Axis [AA08]. 26/ 2/6/2009

76 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Apache Axis este un proiect open-source, iar numele provine de la Apache Extensible Interaction System. In prezent Axis a ajuns la versiunea 2. Axis realizeaza implementarea formatului Simple Object Access Protocol: SOAP. SOAP este folosit pentru interschimbarea datelor intr-un mediu distribuit. Soap este construit pe baza limbajului XML. Exista cateva implementari pentru SOAP, si una dintre aceste implementari este Apache SOAP, care in present a ajuns la versiunea 2.2. Axis este de asemenea creat de proiectul Apache. Apache Axis a fost complet rescris si a fost imbunatatit, devenind mult mai flexibil si performant. Axis poate fi vazut ca vesiunea 3 pentru Apache Soap. Arhitectura Axis Scopul fiecarui instrument de dezvoltare a serviciilor Web este acela de a construi o legatura intre procesarea mesajelor SOAP si logica de business care se executa pe server. In mod normal, logica de afacere este pastrata separat de logica procesarii mesajelor SOAP. In urmatoarea figura se prezinta aceasta structura [AA08]. Figura 3.5. Arhitectura Axis Arhitectura Apache Axis este construita pe fundatia motorului de procesare a mesajelor SOAP. Acest motor de procesare accepta mesaje SOAP, le parseaza si apeleaza metode si functii din serviciul Web. Componentele principare ale sistemului AXIS sunt: AxisEngine - acesta este elementul principal in procesarea SOAP si functioneaza ca si controler pentru alte componente. MessageContext clasa Messagecontext este ca un wrapper pentru cererile si raspunsurile SOAP; aceasta ofera informatie despre mesaje celorlalte componente din sistemul de procesare a mesajelor din AXIS. Handlers,Chains - handler-ele sunt blocurile de baza din sistemul AXIS. Un handler primeste un obiect MessageContex si efectueaza o anumita actiune pe baza continutului acestuia. Chain este un handler special care reprezinta un sir de alte handler-e. Transport componenta de transport ofera un mecanism pentru ca mesajele cerere sa ajunga la AXISEngine si pentru a trimite mesaje raspuns la client. Serializers, Deserializers acestia convertesc datele din forma lor nativa in XML, si invers. Deployment, Configuration AXIS defineste un descriptor bazat pe XML cunoscut ca Web Service Deployment Descriptor care defineste cum o instanta particulara a AXIS trebuie sa se comporte. 27/ 2/6/2009

77 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Procesarea mesajelor SOAP Principalul punct de intrare intr-un serviciu Web este Axis. Acest motor parseaza mesajele si apeleaza lanturile de handlerele potrivite in coformitate cu instructiunile oferite pentru descarcarea serviciilor Web. Dupa cum se poate observa din figura urmatoare, Axis trebuie sa existe atat pe partea de client, cat si pe partea de server. Figura 3.6. Sistemul AXIS si procesarea mesajelor Punctul principal al sistemului de pe client sau server este clasei implementarea org.apache.axis.axisengine. In terminologia UML, AXISEngine joaca rolul de actor care interactioneaza cu alte componente de procesare a mesajelor, cum ar fi handler-ele si lanturile de handlere si coordoneaza fluxul de mesaje prin intregul sistem. Sistemul de procesare de mesaje din AXIS foloseste un obiect de tip Message pentru a interpreta mesajele SOAP de tip request, response, fault. Obiectele Message sunt incluse in obiecte MessageContext si apoi sunt disponibile tuturor componentelor (chain, handler, etc.). Obiectul MessageContext este de fapt un container de mesaje request, response, fault care de asemenea ofera informatii contextuale, cum ar fi protocolul de transport cu ajutorul caruia mesajele sunt primite, referinte despre la instanta AxisEngine, etc. Clasa abstracta org.apache.axis.axisengine descrie sistemul de procesare a mesajelor. Axis ofera urmatoarele implementari ale AxisEngine: AxisServer aceasta este pentru partea de procesare a mesajelor pe server AxisClient aceasta este pentru partea de procesare a mesajelor pe client AxisEngine este de asemenea responsabil pentru invocarea tuturor lanturilor de handlere in ordinea definita in descriptorul de descarcare si sa se asigure ca semantica mesajelor SOAP este respectata. De exemplu, AxisEngine, trebuie sa asigure ca atribute ca mustunderstand sunt tratate corect. Handlere, Chains Axis este construit pe ideea de handlere. Un handler este o parte de cod care efectueaza o anumita functie. Un handler poate pastra log-urile mesajelor sau altul poate decripta mesaje etc. Aceste handlere trebuie scrise in Java, in versiunile curente de Axis, dar o versiune 1.6 de C++ a Axis este in dezvoltare. Handlerele sunt direct invocate de Axis. 28/ 2/6/2009

78 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Axis chains sunt tipuri speciale de handlere care pot contine alte handlere. Handlerele pe care ele le contin pot fi de asemenea lanturi. Executia acestora este ordonata, astfel incat lanturile reprezinta un tip de limbaj de control, dar fara pasare de parametri.un lant tinta este un tip special care contine mai multe intrari intr-un punct. Handlerele de transport au atat parte de client cat si de server, care permit unui handler HTTP sa primeasca dar si sa trimita mesaje. In figura urmatoare se observa cum handlerele pot fi folosite pentru a subdiviza sarcini asociate cu procesarea mesajelor SOAP. Transport Figura 3.7. Procesarea mesajelor SOAP Transportul reprezinta mecanismul de a transmite si primi mesaje de la /la Axis. La inceput, HTTP a fost un protocol pentru orice motor de servicii Web, dar suportul pentru SMTP, FTP si JMS a inceput sa apara de curand. Toate aceste tipuri de transport au o modalitate de a transfera datele de la un calculator la altul, dar cu grade variate de siguranta si viteza [AA08]. Dispecer Un dispecer este un tip special de handler care este folosit pentru a separa logica de business de logica handlerelor. Un dispatcher special, RPCDispatcher converteste mesajele SOAP la obiecte Java si apoi apeleaza serviciul Web, eliminand astfel logica de afacere din handlere. Ascultatori de transport Un ascultator de transport este un servlet care asteapta mesajele SOAP. Acesta este responsabil pentru crearea unei instante a Axis (sau gasirea unei instante existente) si pasarea de mesaje SOAP la aceasta. De asemenea, ii spune motorului de Axis ce tip de transport sa foloseasca pentru a returna raspunsul clientului. Un sistem care suporta 3 tipuri de transport are 3 ascultatori de transport: 29/ 2/6/2009

79 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Figura 3.8. Ascultatorii de transport Dupa ce un ascultator de transport proceseaza mesajul, acesta devine mesaj SOAP generic. Aceasta permite ca procesarea sa fie facuta in acelasi fel pentru toate mesajele indiferent de mecanismul de trasnport folosit pentru a le trimite. Transmitatorii de transport Cand Axis actioneaza ca un client, are nevoie sa trimita un mesaj SOAP ca si cerere pentru serverul de SOAP. Handlerele de Axis care fac aceasta se numesc transmitatori de transport. Daca un mesaj SOAP trebuie trimis la un serviciu Web prin HTTP, se va folosi transmitatorul de transport HTTP din AXIS. 30/ 2/6/2009

80 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi 4 Standardele FIPA 4.1 Principalele specificatii FIPA Structura unui mesaj FIPA ACL Comunicarea intre agenti este diferita de comunicarea dintre obiecte in paradigma orientata pe obiecte (invocarea de metode): deoarece agentii sunt autonomi, un agent nu poate obliga un alt agent sa execute o actiune si nici nu poate modifica starea interna a unui agent. In schimb un agent poate comunica in incercarea de a influenta alti agenti. Comunicarea poate fi tratata ca actiune, pornind de la teoria actelor de comunicare ("speech act theory") [Aus62], [Sea69]. Aceasta se bazeaza pe faptul ca actele de comunicare sunt realizate de agenti ca oricare alte actiuni, in sprijinul intentiilor lor [Coh79], [Coh90]. Teoria actelor de comunicare a influentat in mod direct un numar de limbaje dezvoltate special pentru comunicarea intre agenti. Astfel la inceputul anilor 1990 au fost dezvoltate doua limbaje de catre KSE (US-based DARPA-funded Knowledge Sharing Effort) [KES93]: KQML (Knowledge Query and Manipulation Language) un limbaj de comunicare interagenti bazat pe mesaje. KQML defineste un format comun pentru aceste mesaje, incluzand un performativ si un numar de parametri KIF (Knowledge Interchange Format) un limbaj bazat pe logica de ordinul I pentru reprezentarea cunostintelor dintr-un anumit domeniu. A fost creat in primul rand pentru a reprezenta partea de continut a mesajelor in format KQML. Limbajul KQML prezinta insa cateva dezavantaje [Woo02], precum: mecanismele de transport pentru mesajele KQML nu au fost precis definite, facand dificila interoperabilitatea agentilor care folosesc KQML multimea prea mare de performative lipsa unei semantici riguros definite (semnificatia performativelor a fost definita doar in limbaj natural) lipsa angajamentelor din multimea de performative In acest context, pentru a elimina neajunsurile KQML, FIPA a dezvoltat un nou limbaj, numit ACL (Agent Communication Language), devenit standard in 2002 [ACL02]. ACL ofera un set de 22 de performative si nu impune un anumit format pentru continutul propriuzis ale mesajului, fiind asemanator la nivel de sintaxa cu KQML. Un mesaj FIPA ACL contine o multime de parametri, care definesc: tipul actului de comunicare: o performative (vezi sectiunea 4.2.2) participantii la comunicare: o sender denota identitatea (numele) agentului care trimite mesajul; acesta poate fi omis daca agentul expeditor doreste sa ramana anonim o receiver denota identitatea agentului caruia ii este destinat mesajul. Daca mesajul este multicast, atunci parametrul va contine o multime de nume de agenti. Acest parametru poate fi omis daca destinatarul poate fi identificat din context sau in cazul mesajelor incorporate in proxy sau propagate. 31/ 2/6/2009

81 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi o reply-to indica agentul caruia i se vor trimite urmatoarele mesaje din aceasta conversatie (in locul agentului din parametrul sender) continutul mesajului: o content denota continutul mesajului, care trebuie interpretat de destinatarul acestuia. Unele tipuri de mesaje (de exemple cancel) au un continut implicit, caz in care parametrul content poate sa lipseasca descrierea continutului: o language denota limbajul in care este specificat continutul mesajului (de exemplu FIPA-SL, FIPA-CCL, FIPA-KIF, FIPA-RDF) (vezi sectiunea 4.2.3) o encoding denota modul de codificare al continutului mesajului o ontology denota ontologia utilizata in continutului mesajului controlul conversatiei: o protocol denota protocolul de interactiune utilizat de agentul expeditor al mesajului o conversation-id introduce un identificator al conversatiei, care va fi utilizat in toate actele de comunicare ce fac parte din conversatia curenta o reply-with introduce o expresie care va fi utilizata de agentul respondent pentru a identifica mesajul curent o in-reply-to denota o referinta la o actiune anterioara, pentru care mesajul curent este un raspuns o reply-by denota data pana la care expeditorul doreste sa primeasca raspunsul Dintre acesti parametri, obligatoriu este doar parametrul performative; de asemenea, majoritatea mesajelor ACL contin si parametrii sender, receiver si content. Unii parametri pot fi omisi atunci cand valoarea lor poate fi dedusa din context. In plus, o implementare specifica poate include si alti parametri definiti de utilizator, al caror nume trebuie prefixat cu "X-". Daca un agent nu recunoaste sau nu poate procesa unul dintre parametri, acesta va raspunde cu mesajul not-understood Tipuri de mesaje FIPA ACL FIPA propune un set de 22 de performative ([ACT02]). O clasificare a acestor performative in functie de rolul lor este inclusa in tabelul 4.1. Performativa Transmitere de informatii Cerere de informatii Negociere Realizare de actiuni accept-proposal agree cancel cfp confirm disconfirm 32/ 2/6/2009 Tratarea erorilor

82 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi failure inform inform-if inform-ref not-understood propagate propose proxy query-if query-ref refuse reject-proposal request request-when request-whenever subscribe Tabelul 4.1. Clasificarea performativele incluse in FIPA ACL (conform [Woo02]) In continuare vom prezenta o descriere succinta (informala) a acestor performative. accept-proposal acceptarea unei propuneri (facute anterior de un alt agent) de realizare a unei actiuni agree acordul pentru a realiza o anumita actiune. Este utilizata de un agent pentru a indica faptul ca accepta o cerere (request) a unui alt agent si ca intentioneaza sa realizeze actiunea ceruta. cancel utilizata de un agent pentru a informa un alt agent ca primul agent nu mai doreste ca cel de-al doilea agent sa realizeze o anumita actiune (ceruta anterior printrun mesaj de tip request) cfp cerere de propuneri pentru realizarea unei anumite actiuni; utilizata pentru a initia negocierea intre agenti. Atributul content cuprinde atat o actiune cat si o conditie (termenii in care se doreste sa fie realizata actiunea) confirm este utilizata de un agent pentru a informa un alt agent ca o anumita propozitie (continutul mesajului) este adevarata, in conditiile in care expeditorul crede ca destinatarul are o incertitudine asupra valorii de adevar a acestei propozitii disconfirm similara cu confirm; este utilizata de un agent pentru a informa destinatarul mesajului ca o anumita propozitie este falsa, in conditiile in care expeditorul crede ca destinatarul crede ca propozitia este adevarata. failure utilizata de un agent pentru a informa un alt agent ca o actiune intreprinsa a esuat. inform una dintre cele mai importante performative; mecanismul de baza pentru comunicarea de informatii; este utilizata de un agent pentru a-l informa pe un alt agent ca o propozitie este adevarata (expeditorul doreste ca destinatarul sa creada ca propozitia este adevarata; in mod implicit expeditorul afirma faptul ca el crede ca propozitia este adevarata) inform-if este o macro-performativa, specificand daca o anumita propozitie este adevarata sau nu. Actele de comunicare pot fi realizate direct, planificate si cerute de 33/ 2/6/2009

83 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi un agent unui alt agent; actele macro pot fi planificate si cerute dar nu pot fi realizate direct. Este si cazul lui inform-if, care este de obicei utilizata ca si continut al unui mesaj de tip request: expeditorul mesajului cere destinatarului sa-l informeze daca continutul lui inform-if este adevarat sau fals. inform-ref similara cu inform-if; diferenta este ca agentul expeditor doreste sa afle nu daca o expresie este adevarata sau falsa ci care este valoare unei expresii. not-understood Expeditorul mesajului (agentul i) il informeaza pe destinatar (agentul j) ca a perceput faptul ca j a realizat o anumita actiune dar nu a inteles actiunea realizata de j. O utilizare comuna este ca i sa-i indice lui j ca nu a inteles mesajul pe care j tocmai i l-a trimis lui i. Continutul mesajului include atat o actiune (cea care nu a fost inteleasa) cat si o afirmatie care ofera explicatii referitor la cauza neintelegerii. propagate Continutul mesajului cuprinde doua parti: un alt mesaj si o expresie care denota o multime de agenti. Ideea este ca destinatarul mesajului trebuie sa trimita mesajul incorporat agentilor desemnati in aceasta expresie. propose Un agent face o propunere de realizare a unei actiuni unui alt agent (de exemplu ca urmare a unui mesaj cfp trimis anterior) proxy Expeditorul mesajului il trateaza pe expeditor ca pe un proxy pentru o multime de agenti. Continutul include atat un alt mesaj incorporat, care se doreste a fi redirectat catre alti agenti, cat si o specificare a acestor agenti. query-if - Expeditorul mesajului il intreaba pe destinatar daca o anumita propozitie (repezentata de continutul mesajului) este adevarata sau nu query-ref Expeditorul mesajului il intreaba pe destinatar care este obiectul referit de o anumita expresie referentiala. refuse este utilizata de un agent pentru a indica unui alt agent ca nu va realiza o anumita actiune; continutul mesajului va cuprinde atat actiunea refuzata cat si o explicatie a acestui refuz. reject-proposal este utilizata de un agent pentru a indica unui alt agent ca nu accepta o propunere facuta in cadrul unei negocieri (prin intermediul unui mesaj propose). Continutul mesajului specifica atat propunerea care este respinsa cat si motivele acestei respingeri request utilizata de un agent pentru a cere unui alt agent sa realizeze o anumita actiune request-when utilizata de un agent pentru a cere unui alt agent sa realizeze o actiune atunci cand o anumita propozitie devine adevarata request-whenever - similara cu request-when; diferenta este ca actiunea trebuie realizata atunci cand propozitia devine pentru prima data adevarata, precum si ori de cate ori propozitia devine din nou adevarata subscribe Continutul este o expresie referentiala; expeditorul doreste sa fie informat de valoarea referintei si ori de cate ori obiectul identificat de referinta se modifica. Exemple de mesaje ACL [ACT02]: 1. Agentul i il informeaza pe agentul j ca (este adevarat ca) ninge astazi. 34/ 2/6/2009

84 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi 2. Agent i ii cere agentului j sa livreze o cutie la o anumita locatie; j raspunde ca este de acord cu cererea, dar aceasta va avea o prioritate mica. 3. Agentul j ii cere agentului i sa ii trimita propunerea sa pentru vanzarea a 50 de cutii de prune: 4. Agentul j il informeaza pe agentul i ca a esuat in incercarea de a deschide un fisier 35/ 2/6/2009

85 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi 5. Agentul i il informeaza pe agentul j ca nu a inteles un mesaj query-if pentru ca nu a recunoscut ontologia. 6. Agentul i il intreaba pe agentul j care sunt serviciile disponibile. Agentul j ii raspunde ca poate face rezervari pentru tren, avion, masina. 7. Agentul i ii spune agentului j sa-l anunte ori de cate ori pretul componentelor creste peste 50. Cum una din cele mai importante critici aduse limbajului KQML a fost lipsa unei semantici clare, FIPA ACL ofera o semantica formala riguroasa. Solutia abordata porneste de la teoria actelor de comunicare ca actiuni rationale [Coh90], [Bre97]. Definirea semanticii se bazeaza pe un limbaj formal numit FIPA SL [SL02], care permite reprezentarea 36/ 2/6/2009

86 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi convingerilor, dorintelor si convingerilor incerte ale agentilor, precum si a actiunilor realizate de agenti. Au mai fost propuse si alte limbaje pentru specificarea mesajelor semantice: CCL [CCL01], KIF [KIF03], RDF [RDF01], dar acestea au inca un statut experimental. Singurul care a devenit standard este FIPA-SL, pe care il vom prezenta in sectiunea urmatoare Limbajul FIPA-SL pentru specificarea mesajelor semantice Fiecare mesaj ACL e mapat la o formula din limbajul SL, care defineste o constrangere (numita conditie de fezabilitate) pe care agentul care trimite mesajul trebuie sa o respecte pentru a fi considerat conform cu standardul ACL. De asemenea, semantica mapeaza fiecare mesaj la o formula SL care defineste efectul rational al actiunii scopul mesajului (ce incearca agentul sa realizeze prin trimiterea mesajului). Evident, intr-o societate de agenti autonomi efectul rational al mesajului nu poate fi garantat. Conformanta la standardul ACL nu presupune asadar ca destinatarul mesajului sa respecte efectul rational al mesajului ci doar conditia de fezabilitate. In cele ce urmeaza vom prezenta semantica pentru cele mai importante tipuri de mesaje: inform si request. Toate celelalte performative din FIPA ACL sunt definite pe baza acestora doua. <i, inform(j, )> FP: B i Bi ( Bif j Uif j ) RE: B j B i semnifica faptul ca agentul i are convingerea Bif i semnifica faptul ca agentul i are o opinie clara despre adevarul sau falsitatea lui Uif i semnifica faptul ca agentul i are o incertitudine legata de Astfel un agent i care trimite un mesaj inform cu continutul agentului j respecta semantica FIPA ACL daca: i) are convingerea si ii) nu are convingerea ca j are fie o opinie clara despre, fie o incertitudine legata de. Daca actiunea de informare are success, atunci destinatarul mesajului, agentul j, va avea convingerea. <i, request(j, a)> FP: FP (a) [i\j] B Agent ( j, a) B I Done( a) RE: Done(a) i i Expresia Agent(j, a)semnifica faptul ca agentul care realizeaza actiunea a este j. Done(a) semnifica faptul ca actiunea a a fost realizata FP(a) [i\j] denota partea din preconditia de fezabilitate a lui a care reprezinta atitudini mentale ale lui i. Astfel agentul i care ii cere agentului j sa realizeze o anumita actiune respecta semantica FIPA ACL daca: i) partea din preconditia de fezabilitate a lui a care reprezinta atitudini mentale ale lui i este respectata; ii) agentul i are convingerea ca agentul care realizeaza actiunea a este j (deci trimite cererea catre agentul corespunzator); iii) agentul i crede ca 37/ 2/6/2009 j

87 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi agentul j nu intentioneaza in momentul curent sa realizeze a. Efectul rational (ceea ce i doreste sa realizeze prin aceasta cerere) este ca actiunea a sa fie realizata. Detalii despre sintaxa limbajului FIPA SL sunt incluse in [SL02]. In cele ce urmeaza vom prezenta pe scurt gramatica FIPA SL. 38/ 2/6/2009

88 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi 39/ 2/6/2009

89 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Observatii: O formula bine formata (well formed formula Wff) este construita dintr-o formula atomica sau in mod recursiv prin aplicarea operatorilor de constructie sau conectorilor logici. Pe langa operatorii logici uzuali (not, and, or, implies, equiv), apar si 4 operatori modali (B, U, I, PG) si 2 operatori de actiune (feasible, done), astfel: (B <agent> <expression>) Convingere. Este adevarat ca agentul agent crede ca expresia expression e adevarata. (U <agent> <expression>) Incertitudine. Este adevarat ca agentul agent are o incertitudine legata de adevarul expresiei expression. Agentul agent nu are convingerea ca expression este nici adevarata nici falsa, dar crede ca e mai probabil sa fie adevarata. (I <agent> <expression>) Intentie. Este adevarat ca agentul agent intentioneaza ca expresia expresion sa devina adevarata si va planifica realizarea acestui lucru. (PG <agent> <expression>) Scop persistent. Este adevarat ca agentul agent are un scop persistent ca expresia expression sa devina adevarata dar nu va planifica neaparat realizarea acestui lucru. 40/ 2/6/2009

90 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi (feasible <ActionExpression> <Wff>) Este adevarat ca ActionExpression poate avea loc, si imediat dupa Wff va fi adevarata. (done <ActionExpression> <Wff>) Este adevarat ca ActionExpression tocmai a avut loc, si imediat inainte Wff era adevarata Protocoale de interactiune Protocoalele de interactiune sunt scenarii de comunicare care pot avea loc intre agenti individuali, in cadrul unor sisteme multi-agent. Un proiectant al unor sisteme multi-agent are optiunea sa-i faca pe agenti suficient de constienti despre semnificatia mesajelor, scopurilor, credintelor si a altor atitudini mentale pe care le poseda agentul, permitand ca interactiunile sa fie generate spontan pe baza alegerilor facute de catre agenti. Aceasta optiune, desi este destul de intalnita in cadrul comunitatii de agenti, duce insa la cresterea complexitatii implementarii agentilor. O alternativa mult mai pragmatica consta in prestabilirea unor protocoale de interactiune, in asa fel incat sa permita unor implementari mult mai simple de agenti sa poata avea conversatii semnificative cu alti agenti, respectand pur si simplu protocoale de interactiune cunoscute. Un agent care initiaza o conversatie cu alti agenti poate indica protocolul de interactiune pe care doreste sa-l urmeze, dupa care destinatarul, in cazul in care cunoaste protocolul, va stii cum trebuie sa evolueze conversatia. Prin natura lor, agentii pot lua parte simultan la mai multe dialoguri, posibil cu mai multi agenti. Termenul conversatie este folosit pentru a denumi o instanta particulara a unui astfel de dialog. Astfel, un agent poate fi angajat concurent in mai multe conversatii cu mai multi agenti, folosind protocoale de interactiune diferite. Pornind de la cercetarile prezentate in [Lux98] si [Hau94] FIPA a dezvoltat un set de standarde de interactiune care descriu in totalitate conversatiile dintre agenti, servind pentru atingerea unui efect precum licitatia, negocierea unor servicii de brokeraj, inregistrarea si incheierea unor subscrieri. Lista completa a standardelor de interactiune dezvoltate de FIPA este urmatoarea: FIPA Request Interaction Protocol Specification (statut de standard) FIPA Query Interaction Protocol Specification (statut de standard) FIPA Request When Interaction Protocol Specification (statut de standard) FIPA Contract Net Interaction Protocol Specification (statut de standard) FIPA Iterated Contract Net Interaction Protocol Specification (statut de standard) FIPA English Auction Interaction Protocol Specification (statut experimental) FIPA Dutch Auction Interaction Protocol Specification (statut experimental) FIPA Brokering Interaction Protocol Specification (statut de standard) FIPA Recruiting Interaction Protocol Specification (statut de standard) FIPA Subscribe Interaction Protocol Specification (statut de standard) FIPA Propose Interaction Protocol Specification(statut de standard) Specificatiile mesajelor individuale care formeaza un protocol de interactiune sunt in mod necesar relaxate: de obicei sunt descrise numai functia mesajului, emitatorul si destinatarul. Acest lucru se datoreaza faptului ca protocolul de interactiune este o descriere generica a sablonului de interactiune. Continutul efectiv al mesajelor va fi insa diferit de la o 41/ 2/6/2009

91 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi executie a unui protocol la alta. Mai mult, actiunile locale executate de un agent, precum si deciziile luate de acesta sunt in mod traditional nereprezentate, chiar daca acestea au legatura cu desfasurarea protocolului. FIPA Request Interaction Protocol [RIP01] permite unui agent, numit Initiator, sa ceara unui alt agent, numit Participant, sa efectueze o anumita actiune. Participantul proceseaza cererea si decide daca accepta sau refuza cererea. Reprezentarea protocolului este ilustrata in figura pe baza extensiilor la UML 1.x [Ode01]. Figura FIPA Request Interaction Protocol 42/ 2/6/2009

92 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi In cazul in care conditiile indica furnizarea unui acord explicit (adica notification necessary are valoarea true) atunci Participantul trebuie sa comunice un mesaj agree. In functie de circumstante, acest acord este optional, cum ar fi in cazul in care actiunea ceruta este foarte rapida si se poate efectua inainte de momentul specificat in parametrul reply-by. O data ce s-a convenit asupra cererii, Participantul trebuie sa comunice unul din urmatoarele: Un mesaj failure daca esueaza in incercarea de a indeplini cererea, Un mesaj inform-done daca a indeplinit cererea cu succes si doreste numai sa comunice acest lucru, sau Un mesaj inform-result daca doreste sa anunte ca a efectuat cererea cu succes si sa notifice Initiatorul care au fost rezultatele. Interactiunile care folosesc acest protocol de interactiune sunt identificate folosind parametrul conversational_id. Parametrul are o valoare nenula, unica in sistem, fiind asignata de Initiator si setata in structura mesajului ACL. Agentii implicati in interactiune trebuie sa-si eticheteze toate mesajele lor cu acest identificator pentru conversatie. Acest lucru ofera fiecarui agent posibilitatea gestionarii activitatilor si strategiilor de comunicare. De exemplu, etichetarea mesajelor permite unui agent sa identifice conversatiile individuale si sa rationeze pe baza istoricului conversatiilor. In orice moment din cadrul protocolului de interactiune, destinatarul unui mesaj il poate informa pe expeditor ca nu a inteles ce se dorea comunicat. Acest lucru este realizat prin trimiterea unui mesaj not-understood. Acest lucru nu este ilustrat in figura deoarece un mesaj not-understood poate aparea oricand in cadrul protocolului de interactiune. Transmiterea unui mesaj non-understood in cadrul unui protocol de interactiune poate incheia intreaga interactiune si acest lucru poate implica faptul ca toate angajamentele luate in timpul interactiunii sunt nule. Suplimentar, in orice moment din cadrul protocolui, Initiatorul poate anula interactiunea prin initierea protocolului FIPA Cancel Meta-Protocol ilustrat in figura Parametrul conversation-id al interactiunii de anulare este identic cu parametrul conversational-id al interactiunii pe care Initiatorul doreste sa o anuleze. Semantica anularii trebuie interpretata in general ca insemnand ca Initiatorul nu mai este interesat in continuarea interactiunii si ca ar trebui incheiata intr-o maniera acceptabila atat pentru Initiator si Participant. Participantul informeaza Initiatorul fie ca interactiunea e incheiata folosind un mesaj inform-done, fie indica esuarea anularii folosind un mesaj failure. 43/ 2/6/2009

93 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Figura FIPA Cancel Meta-Protocol In FIPA Dutch Auction Interaction Protocol [DAP01], vanzatorul incearca sa gaseasca pretul pietei pentru un bun incepand licitatia de la un pret mult mai mare decat valoarea de piata asteptata, reducand apoi progresiv pretul pana cand unul dintre cumparatori accepta pretul. Rata cu care este redus pretul depinde de vanzator, care de obicei are un pret limita, sub care nu va cobora. Daca licitatia reduce pretul pana la pretul limita fara a aparea cumparatori atunci licitatia se incheie. Termenul de Licitatie Olandeza provine din pietele de flori din Olanda, unde este metoda predominanta de determinare a valorii de piata pentru diverse cantitati de flori. In modelarea licitatiei olandeze din piata de flori, precum si din alte piete, exista cateva complexitati suplimentare. Mai intai, bunul poate fi portionat: de exemplu vanzatorul poate vinde zece cutii de lalele la un anumit pret P si un cumparator poate cumpara numai sapte dintre acestea. Licitatia continua in acest caz cu urmatorul pret sub P, pana cand si restul bunului este vandut sau pretul limita este atins. Astfel de vanzari partiale sunt intalnite numai pe anumite piete, in altele cumparatorul trebuie sa liciteze pentru intregul bun. In al doilea rand, mecanismul pietei de flori se asigura ca nu se mai poate face o alta oferta dupa ce prima oferta a fost facuta. Ofertele de vanzare si cumparare sunt ferme, de aceea nu exista nici un protocol pentru acceptarea sau rejectarea unei oferte. In cazul unui agent nu este posibil sa presupunem ca astfel de conditii pot fi aplicabile, ceea ce ar fi si foarte restrictiv de altfel. Asa ca este posibil ca doua sau mai multe oferte pentru acelasi bun sa fie primite de catre adjudecator. De aceea protocolul permite ca o oferta sa fie rejectata, dar acest 44/ 2/6/2009

94 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi lucru este destinat numai cazului in care sunt receptionate simultan mai multe oferte aflate in competitie. Protocolul FIPA nu specifica insa care este mecanismul folosit pentru rezolvarea acestui conflict. In general, agentii nu ar trebui sa faca nici o alta presupune in afara regulii primul venit, primul servit, dar in anumite domenii se pot aplica alte reguli. Figura FIPA Dutch Auction Interaction Protocol Acest protocol reprezinta un sablon pentru o interactiune simpla. In majoritatea cazurilor va fi nevoie de o dezvoltare a acestui sablon pentru a specifica toate cazurile care pot aparea intr-o interactiune reala intre agenti. Situatii din lumea reala, precum anularea actiunilor, asincronie, incheierea anormala sau neasteptata a interactiunii, interactiuni imbricate, nu sunt adresate in mod explicit. Un agent care respecta standardul FIPA-ACL nu trebuie sa implementeze nici unul dintre protocoalele de interactiune din standardele FIPA si nici nu i se restrictioneaza folosirea unui alt nume pentru protocol. Daca insa e folosit unul din numele standard atunci agentul trebuie sa se comporte conform specificatiile din respectivul standard. Standardele FIPA nu intentioneaza sa acopere toate tipurile de interactiuni necesare. Un protocol de interactiune nu trateaza un numar de situatii din lumea reala a interactiunilor 45/ 2/6/2009

95 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi dintre agenti, precum tratarea exceptiilor, mesajelor care sosesc fara sa respecte ordinea, mesaje pierdute, intarzieri. Mai degraba, standardele FIPA ar trebui vazute ca sabloane de interactiune care trebuiesc dezvoltate in functie de contextul unei aplicatii individuale. Aceasta strategie implica faptul ca aderarea la un protocol de interactiune cunoscut nu asigura in mod necesar interoperabilitatea, fiind nevoie de intelegeri suplimentare intre agenti cu privire la situatiile mentionate anterior pentru a se asigura interoperabilitatea in toate cazurile. 46/ 2/6/2009

96 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi 5 Platforme de agenti FIPA JADE 5.1 Despre JADE JADE (Java Agent DEvelopment Framework) este un framework pentru dezvoltarea de aplicatii bazate pe agenti respectand standardele impuse de FIPA pentru sisteme multiagent. Scopul este simplificarea procesului de dezvoltare asigurand in acelasi timp respectarea standardelor printr-un set de cuprinzator de servicii si agenti. JADE poate fi considerat un middleware pentru agenti care implementeaza o Platforma agent (Agent Platform) si este si un mediu de dezvoltare (un framework). Ascunde programatorului toate acele detalii de implementare tipice pentru agenti, independente de aplicatie (nivelul transport, encodare si parsare, life cycle) si il lasa sa se concentreze asupra logicii de rulare, asupra comportamentului ce trebuie impus agentilor. Deasemenea sunt furnizate si metode de debug si vizualizare grafica a platformei. Acesta este un framework gratuit distribuit de Telecom Italia sub licenta LGPL ( Lesser General Public License Version 2). Alte companii si-au manifestat interesul in dezvoltarea si promovarea platformei si fac acum parte din comitetul JADE:Motorola, Whitestein Technologies AG, Profactor GmbH si France Telecom R&D. In Internet modelul de referinta pentru interactiunea dintre masini este Client-Server. Este o arhitectura bazata pe distinctia rigida dintre nodurile client (cei care cer resurse) si nodurile server (cei care furnizeaza resurse). Rolul de server face ca aceasta masina sa nu poata avea decat actiuni reactive la cererile initiate de clienti. Pe de alta parte, clientii inglobeaza toate initiativele de comunicatie din sistem. Din aceste cauze, clientii au libertatea de mobilitate, functionare temporara si sub diferite aliasuri in timp ce serverele trebuie sa furnizeze garantii de stabilitate, securitate, trebuie sa raspunda la aceleasi adrese si pe porturi stabilite. Exista aplicatii distribuite care nu se mapeaza bine pe acest model: chat-uri, file sharing sau multiplayer games trebuie sa comunice in mod direct si orice capat de comunicatie trebuie sa fie capabil sa inceapa o comunicatie deoarece cunostintele sunt distribuite in retea. Acest model se numeste peer-to-peer. Aceasta arhitectura are avantajul ca oricare dintre entitati poate intra sau parasi o retea, poate initia o comunicatie si poate primi requesturi in acelasi timp. Reteaua este descentralizata, logica si resursele fiind egal distribuite. Aici apare problema descoperiri celor ce fac parte din retea. Astfel exista 2 tipuri de P2P. Cele total descentralizate (c) in care modelul poate fi considerat ca o retea ad-hoc sau cele hibride in care exita servere centrale ce ofera servicii de white si yellow pages. 47/ 2/6/2009

97 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Fig. Tipuri de arhitecturi de retele Paradigma agentilor aplica concepte din inteligenta artificiala si tehnici de limbaj pe tehnologia de aplicatii distribuite. Paradigma este bazata pe abstractizarea cu agenti, componete software care sunt autonome (au un grad de libertate si pot lua decizii singuri), proactive (pot influienta mediul pentru a-si atinge scopurile) si sociale (interactioneaza cu alti agenti). Acestia sunt urmatoarea generatie de aplicatii ce vor popula Internetul pentru ca sunt flexibili, detin avantajele arhitecturii P2P si pot interactiona cu alti agenti pentru a-si indeplini misiunea. 5.2 Arhitectura FIPA a propus o arhitectura pentru agenti pentru a se asigura interactiunea intre software-uri scrise de diferiti developeri in diferite limbaje de programare. Este important ca doi agenti ce vor sa comunice sa se gaseasca in Internet in primul rand, sa se inteleaga asupra limbajului pe care il vor folosi si sa dea sensuri comune termenilor din conversatie. Aici intervine FIPA prin setul de standardizari propus. Arhitectura generala arata ca in figura 2. Fig. Arhitectura generica FIPA a unui AP 48/ 2/6/2009

98 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Fiecare platforma Agent trebuie sa cuprinda un nivel de transport, un limbaj de comunicare interagent, si metode de descoperire a agentilor si a serviciilor oferite. Agentul este un proces computational implementat in asa fel incat sa aiba o comportare autonoma si sa fie capabil sa comunice (socializeze) cu alti agenti printrun limbaj (Agent Communication Language). Acesta este actorul fundamental dintr-o platforma agent ce poate implementa si furniza servicii, dupa cum e specificat in descriptorul de servicii. Un Directory Facilitator (DF) este o componenta optionala ce ofera servicii de yellow pages agentilor. Agentii isi inregistreaza serviciile la DF sau pot interoga DF cu privire la serviciile oferite de alti agenti. Un Agent Management System (AMS) este o componenta obligatorie din AP. El supervizeaza acesul agentilor la AP si mentine o lista a AID-urilor (Agent IDs) valide si adrese unde se regasesc agentii. Astfel AMS reprezinta un serviciu de white pages pentru agenti. Message Transport Service (MTS) este nivelul unic de transport al mesajelor intre AP-uri Un Agent Platform (AP) este infrastructura fizica in care agentii pot fi executati. Este constituit din masina fizica, sistem de operare si framwork de rulare. JADE se angajeaza sa respecte specificatiile FIPA si sa implementeze o platforma bazata pe agenti in care si serviciile de yellow si white pages sa fie implementate de niste agenti predefiniti. Serviciul de regasire a agentilor si serviciilor este implementat prin 2 agenti speciali numiti AMS si DF. Nivelul transport trebuie sa asigure comunicarea cu cat mai multi agenti, indiferent de limbajul in care sunt scrisi. JADE suporta diferite protocolul de comunicatie poate fi oricare dintre cei consacrati (Java RMI, IIOP, SOAP, HTTP, etc) dar poate fi si extins cu alte librarii. Agentii rezida in containere, entitati logice ce faciliteaza gruparea lor. O platforma poate fi gazduita pe mai multe masini fiind compusa din containere independente dintre care unul singur poate fi main si cuprinde AMS-ul iar restul sunt secundare. Containerele si agentii pot fi porniti remote de pe alte calculatoare. Deasemenea, agentii de pe diferite calculatoare pot interactiona (acesta fiind de fapt scopul principal). Fiecare agent are alocat un thread in AP si poate contine in interiorul lui alte threaduri datorita suportului oferit de Java. Insa JADE o alternativa lightweight prin implementarea inteligenta a unui scheduler pentru comportamente cooperative (behaviours). Mai concret, se defineste o lista de event handleri pt agenti care vor fi chemati la momentul oportun de unicul thread al agentului. Aceste metode se vor executa serial insa vor mima executia paralela a mai multe fire de executie necesare agentului. Este inclus si suport pentru JESS, limbajul de descriere a modului de ratiune pentru un soft. 49/ 2/6/2009

99 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Fig. Arhitectura unui Agent in JADE 5.3 Framework de baza Pentru a mosteni proprietatile fundamentale ale unui agent (mecanismul de comunicatie), o clasa trebuie sa extinda jade.core.agent. In metoda setup() se introduce codul particular comportamentului fiecarui agent. Un Hello World! foarte simplu este descris in continuare. import jade.core.agent; public class HelloAgent extends Agent { } protected void setup() { } System.out.println("Hello World. "); System.out.println("My name is "+ getlocalname()); Pentru compilare se vor include in CLASSPATH toate librariile din JADE si se executa linia: javac HelloAgent.java. Apoi se poate lansa agentul in contextul unui nou container prin comanda java jade.boot agent_name:helloagent. 50/ 2/6/2009

100 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Acest nou container este cel principal si doar unul singur poate exista pe platforma agent curenta. Celelalte containere secundare vor fi lansate cu o comanda de genul: java jade.boot container agent_name2:helloagent Daca se vrea lansarea unui agent pe o alta masina din retea, se poate specifica in linia de comanda o optiune in care se indica numele de retea al masinii ce gazduieste containerul main. java jade.boot container host nume_retea agent_name2:helloagent Agentii au in general interactiuni paralele cu alti agenti si cu mediul. Din aceasta cauza este necesar un mecanism multithreaded care este implementat printr-o lista de comportamente specifica fiecarei instante. Aceste comportamente (bihaviours) sunt niste handleri sub forma de clase ce sunt apelati de catre threadul principal al agentului. Sunt deja definite in JADE o serie de comportamente predefinite care pot fi si extinse. La expirare de timere sau la eventuri (primire de mesaje) aceasta lista este parcursa si metodele sunt apelate pe rand. Orice behaviour poate fi scos din lista de executie pt o perioada prin apelul functiei block(). Acesta va fi reintrodus in lista la expirarea timerului specificat ca parametru sau la primirea unui mesaj. Forma generala este: import jade.core.agent; import jade.core.behaviours.*; public class Simple1 extends Agent { protected void setup() { addbehaviour( // Anonymous SimpleBehaviour new SimpleBehaviour( this ) { int n=0; public void action() { System.out.println( "Hello World! My name is " + myagent.getlocalname() ); n++; } public boolean done() { return n>=3; } } ); } // --- setup / 2/6/2009

101 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi } // --- class Simple1 Dupa cum se vede, s-a creat un behaviour de tip SimpleBihaviour. Acesta se va executa pana cand functia done() se evalueaza la false. Output-ul pt aceast agent este: java jade.boot x:simple1 Hello World! My name is x Hello World! My name is x Hello World! My name is x Un agent poate primi si parametri la creare sub prin specificarea lor intre paranteze rotunde in linia de comanda: java jade.boot x:simple1( alias, 3) si vor fi preluati prin intermediul functiei getarguments() care returneaza un Object[]. Deoarece comunicatia dintre agenti poate avea latente mari intre o cerere si un raspuns si deasemenea pot exista mai multe comunicatii simultane, nu se pot implementa metode de receptie a mesajelor prin blocare. O metoda eficienta este combinarea mecanismului de comportamente cu o masina de stari pt fiecare tip de comunicatie. Cu alte cuvinte, fiecare behaviour va avea in interior descrierea unei masini cu stari pentru a ghida fluxul de comunicatie. Pentru comunicatia intre un EPOS si o banca se poate asocia urmatorul cod: class EPOSQuery extends SimpleBehaviour { int state = 1; public void action() { switch( state ) { case 1: Communicate amount, client data Block(); break; case 2: receive(msg); if(msg==ok) print Ok ; else print Failed ; dodelete(); // applies to the Agent break; } } state++; 52/ 2/6/2009

102 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi } private boolean finished = false; public boolean done() { return finished; } dodelete() apeleaza metoda takedown() a agentului si determina terminarea acestuia. 5.4 Comunicarea intre agenti Comunicatia se realizeaza printr-un ACL (Agent Communication Language) ce compune mesaje cu urmatoarele campuri: Performative tipuri de mesaje standardizate de FIPA (INFORM, QUERY, PROPOSE,...) Addressing o Receiver o Sender Content corpul mesajului ConversationID folosit pentru a inlantui mesajele unei conversatii Language Ontology Protocol specifica protocolul ReplyWith specificarea unui tip de raspuns asteptat InReplyTo - marcarea unui mesaj ca fiind un raspuns ReplyBy timeout pt raspuns Mai sus s-a scris un comentariu in codul EPOS-ului ce tinea loc de codul pentru trimiterea unei interogari. Iata cum ar arata acest mesaj: switch( state ) { case 1: // Communicate amount, client data ACLMessage msg = new ACLMessage( ACLMessage.QUERY ); msg.setcontent("amount: 10EUR; clientid= ro35; bank=bank"); AID dest = getdest(); msg.addreceiver(dest); send(msg); 53/ 2/6/2009

103 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Block(); break; Pot exista mai multi destinatari pentru un mesaj. Un mesaj se poate receptiona fie prin blocarea si asteptarea lui cu blockingreceive sau prin interogarea cozii de mesaje printr-un apel neblocant cu receive(). Un corespondent al agentului EPOS ar fi banca: public class Bank extends Agent { protected void setup() { addbehaviour(new CyclicBehaviour(this) { public void action() { } ACLMessage msg= receive(); if (msg!=null) { } block(); ACLMessage reply = ComputeMessage(msg); send(reply); private ACLMessage ComputeMessage(ACLMessage msg) { String content = msg.getcontent(); ACLMessage reply = msg.createreply(); reply.setperformative(aclmessage.inform); if(checksold(content)) reply.setcontent( ok ); else reply.setcontent( failed ); } } }); } return reply; 54/ 2/6/2009

104 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi createreply() poate alcatui automat un mesaj de raspuns cu sender si destinatari completati, precum si un communicationid daca este cazul. Pentru a cauta un agent in paginile albe ale AP-ului, se vor apela functii API specifice AMS-ului: // Required imports import jade.domain.amsservice; import jade.domain.fipaagentmanagement.*;... AMSAgentDescription [] agents = null; try { } SearchConstraints c = new SearchConstraints(); c.setmaxresults ( new Long(-1) ); agents = AMSService.search( this, new AMSAgentDescription (), c ); catch (Exception e) {... } 5.5 Comportamentul agentilor (Agent Behaviour) Un agent trebuie sa fie capabil sa execute sarcini ca raspuns la diferitele evenimente externe.sarcina efectiva pe care un agent o are de efectuat este de obicei programata in metoda action a claselor de tip Behaviour (clasa comportamentala). O instanta a unei asemenea clase se va numi obiect comportamental. Clasa de baza Behaviour din pachetul jade.core.behaviours contine : Constructori Behaviour() Behaviour(Agent a) Obiectul comportamental se ataseaza agentului a. Metode abstract void action() defineste actjiunea realizata de agent abstract boolean done() metoda action se executa cat timp metoda done returneaza false block() suspenda executia metodei action. block(long dt) planifica urmatoarea executie a metodei action dupa dt milisecunde. Campuri 55/ 2/6/2009

105 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi protected Agent myagent referinta la agentul caruia ii apartine obiectul comportamental. Agentului i se atribuie un obiect comportamental prin metoda addbehaviour(behaviour b) iar prin removebehaviour(behaviour b) se ia agentului obiectul comportamental. Planificarea execuţiei obiectelor comportamentale se face ne-preemtiv, in sensul ca metoda action nu este intrerupta niciodata pentru a permite executia celorlalte obiecte comportamentale. Controlul este transferat unui alt obiect comportamental doar in momentul in care metoda action a obiectului comportamental curent se termina. Exista mai multe tipuri de clase comportamentale predefinite : 56/ 2/6/2009

106 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi OneShotBehaviour (se executa action o singura data) CyclicBehavior ( action se executa la infinit ) WakerBehaviour (se executa o singura data, dupa un interval de timp precizat la instantierea obiectului) TickerBehaviour (se executa periodic, cu perioada specificata la instantierea obiectului) clase comportamentale complexe : contin mai multe clase comportamentale simple Fig. Modelul claselor comportamentale Jade 57/ 2/6/2009

107 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi Bibliografie [AA08] Apache Axis2, 2008, [ACKM04] G. Alonso, F. Casati, H. Kuno, and V. Machiraju, Web Services: Concepts, Architecture and Applications, Springer Verlag, 2004 [ACL02] FIPA ACL Message Structure Specification, Foundation for Intelligent Physical Agents, 2002, [ACT02] FIPA Communicative Act Library Specification. Foundation for Intelligent Physical Agents, 2002, [Aus62] J.L. Austin, How To Do Things With Words. Oxford University Press, Oxford, [Bre97] P. Bretier and D. Sadek, A rational agent as the kernel of a cooperative spoken dialogue system: implementing a logical theory of interaction, Intelligent Agents, III, LNAI Volume 1193, Springer, Berlin, 1997, pp [CCL01] FIPA CCL Content Language Specification. Foundation for Intelligent Physical Agents, 2001, [Coh79] P.R. Cohen and C.R. Perrault, Elements of a plan based theory of speech acts, Cognitive Science, 3, 1979, pp [Coh90] P.R. Cohen and H.J. Levesque, Rational interaction as the basis for communication, Intentions in Communication, MIT Press, Cambridge, MA, 1990, pp [DAP01] FIPA Dutch Auction Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2001, [Hau94] H. Haugeneder (Ed). IMAGINE Final Project Report, IMAGINE Technical Report Series, [KIF03] FIPA KIF Content Language Specification. Foundation for Intelligent Physical Agents, 2003, [KSE93] Knowledge Sharing Effort, [Lux98] A.Lux and D. Steiner, Understanding Cooperation: An Agent s Perspective, Readings in Agents, Morgan Kaufmann, 1998, pp [OA-WS08] OASIS Committees for Web Services, 2008, accesat in noiembrie 2008 [Ode01] Odell, James, Van Dyke Parunak, H. and Bauer, B., Representing Agent Interaction Protocols in UML. Agent-Oriented Software Engineering, Springer, Berlin, 2001, pp [RDF01] FIPA RDF Content Language Specification. Foundation for Intelligent Physical Agents, 2001, [RIP01] FIPA Request Interaction Protocol Specification. Foundation for Intelligent Physical Agents, 2001, [SAWSDL07] Semantic Annotations for Web Services Description Language Working Group, 2007, accesat in octombrie / 2/6/2009

108 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi [Sea69] J.R. Searle, Speech Acts: an Essay in the Philosophy of Language. Cambridge University Press, Cambridge, [SL02] FIPA SL Content Language Specification. Foundation for Intelligent Physical Agents, [SOA07] Simple Object Access Protocol, 2007, [SM05] A.-M. Sassen, C. Macmillan. The service engineering area: An overview of its current state and a vision of its future, EUROPEAN COMMISSION, Information Society and Media Directorate-General, 2005 [SWS08] Semantic Web Services Interest Group, 2008, accesat in octombrie 2008 [UOS08] UDDI Oasis Standard, 2007, [Woo02] M. Wooldridge, An introduction to multiagent systems, Wiley, [WSACT08] Web Services Activity, 2008, accesat in octombrie 2008 [WSARCH04] Web Services Architecture, 2004, accesat in noiembrie 2008 [WSAREQ04] Web Services Architecture Requirements, 2004, accesat in noiembrie 2008 [WSD07] Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, 2007, [XML08] Extensible Markup Language (XML) 1.0 (Fifth Edition), 2008, [BEV03] Beavers, G., H.Hexmoor. Types and Limits of Agent Autonomy. În Proc. of the Workshop on Computational Autonomy, Autonomy 2003, Melbourne, Australia, [CAS00] Castefranchi, C. Founding Agent's 'Autonomy' On Dependence Theory. În Proc. of 14th European Conf. on Artificial Intelligence, IOS Press, 2000, p [CCD99] Conte, R., C.Castelfranchi, F.Dignum. Autonomous Norm-Acceptance. În J. Muller, M. Singh and A. Rao (eds.), Intelligent Agents V, LNAI 1555, Springer-Verlag, 1999, p [FEB95] Ferber, J. Les systèmes multi-agents: Vers une intelligence collective, InterEditions, 1995 [FRA96] Franklin, S., A. Graesser. Is it an Agent, or just a Program?: A Taxonomy for Autonomous Agents. Proc of the Third International Workshop on Agent Theories, Architectures, and Languages, Springer-Verlag, Disponibil la [GRE01] Greenwald, A., P. Stone. Autonomous bidding agents în the trading agent competition. IEEE Internet Computing, March-April 2001, p [LUC98] Luck, M., M.d'Inverno. Motivated Behaviour for Goal Adoption. În Multi-Agent Systems: Theories, Languages and Applications Proc, of the 4th Australian Workshop on Distributed Artificial Intelligence, Zhang and Lukose (eds.), LNAI 1544, Springer-Verlag, 1998, p [RUS97] Russell, S.J.. Rationality and intelligence, Artificial Intelligence, Vol. 94, p [SHO93] Shoham, Y. Agent-oriented programming, Artificial Intelligence, Vol. 60, p / 2/6/2009

109 SCIPA - Studiul şi evaluarea standardelor actuale în agenţi cognitivi ofertanţi de servicii si coordonare agenţi [VEN99] Verhagen, H., M.Boman. Adjustable Autonomy, Norms and Pronouncers. AAAI Spring Symposium on Agents with Adjustable Autonomy, 1999 [WOO95] Wooldridge, M., N. R. Jennings. Agent theories, architectures, and languages, În Intelligent Agents, M. Wooldridge et N. R. Jennings (eds), Springer Verlag, p / 2/6/2009

110 SCIPA - Studiul si evaluarea standardelor actuale in reprezentarea cunostintelor pentru Web semantic SCIPA Servicii software semantice de Colaborare şi Interoperabilitate pentru realizarea Proceselor Adaptive de business Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Autori Universitatea Politehnică Bucureşti Contract nr / Autoritatea contractantă: CNMP Contact: info@aimas.cs.pub.ro Pagina Web:

111 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Rezumat În cadrul iniţiativei de generalizare a Web-ului Semantic, structură care se doreşte a fi capabilă să interconecteze informaţiile din World Wide Web în aşa fel încât să poată fi prelucrate automat, la scară globală, este necesară o evaluare riguroasă a standardelor actuale folosite pentru reprezentarea cunoştiinţelor. Natura cunostintelor este o problema veche şi de-a lungul timpului au existat numeroase incercari de a gasi moduri de reprezentare. Fizica si matematica depind de limbaje simbolice specifice, existand multe abordari ale inteligentei artificiale pentru gasirea celei mai bune soluţii de reprezentare. Aparitia ontologiilor a demostrat faptul ca acestea reprezinta o modalitate convenabila de reprezentare a cunostintelor in diferite domenii: web semantic, aplicatii de gestiunea cunostintelor sau chiar aplicatiile din domeniul afacerilor. Cercetarea in domeniul reprezentarii cunostintelor si a proceselor de inferenta este in general axata pe metode care ofera descrieri de nivel inalt ale universului cunostintelor care pot fi utilizate pentru a construi aplicatii inteligente. In acest context, inteligenta se refera la capacitatea unui sistem de a gasi consecinte implicite pe baza cunostintelor reprezentate explicit. Lucrarea de faţă tratează câteva dintre cele mai importante formalisme de reprezentare a cunoştiinţelor, începând de la reprezentarea atribut-valoare până la structurarea semantică a informaţiei. 2

112 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic CUPRINS 1 Web Semantic Reprezentarea informatiei pe Web: XML, XML Scema XML XML Schema Reprezentarea cunostintelor pe Web: ontologii Ontologii Reprezentarea cunostintelor prin ontologii Limbaje de descriere a ontologiilor Ontologii de nivel si de domeniu Concluzii Logici de descriere Limbaje de descriere DL Limbajul de descriere Familia de limbaje Axiome terminologice si definitii ABox Inferente in DL Inferente pentru concepte Inferente pentru ABox Algoritmi de rationament Extensii ale limbajelor DL Constructori de rol Restrictii numerice expresive Harti rol-valoare Concluzii Limbajul OWL XML Schema şi RDF XML Schema RDF (Resource Description Framework) Elemente de bază în OWL Definiţie OWL Componente de bază Inferenţe în OWL Utilizarea unui reasoner Lanţuri de proprietăţi Ipotezele pe care se bazează Editoare OWL Reprezentarea cunostintelor prin reguli OPS JESS RuleML SWRL Inginerie ontologică Construirea ontologiilor Constructia manuala a ontologiilor Reutilizarea ontologiilor existente

113 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Folosirea metodelor semiautomate Implementarea ontologiilor Alinierea ontologiilor Dezvoltări actuale Medii de dezvoltare Ontologii existente Proiecte si standarde Concluzii Bibliografie

114 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic 1 Web Semantic 1.1 Reprezentarea informatiei pe Web: XML, XML Scema Cea mai usoara modalitate de reprezentare a informatiilor pe Web o constituie reprezentarea in forma atribut-valoare. Astfel un obiect este caracterizat de atributele sale, fiecare atribut avand un domeniu fixat de valori. In acest mod un concept este specificat printr-o categorie de obiecte reprezentate printr-o combinatie logica intre valorile atributelor XML XML (extensible Markup Language) [XML08] este un meta-limbaj de marcare recomandat de World Wide Web Consortium (W3C) [W3C08] pentru crearea de alte limbaje de marcare, cum ar fi XHTML, RDF, RSS, MathML, SVG, OWL etc. Aceste limbaje formează familia de limbaje XML. Meta-limbajul XML este o simplificare a limbajului SGML (din care se trage şi HTML). El a fost proiectat in scopul transferului de date intre aplicatii pe internet, descriind structura datelor. Totodata XML este şi un model de stocare a datelor nestructurate şi semi-structurate în cadrul bazelor de date native XML. Un document XML are doua niveluri de corectitudine: bine format: un document este bine format daca respecta toate regulile de sintaxa XML (de exemplu, in cazul in care un tag este deschis fara sa fie inchis, atunci documentul XML nu este bine format). valid: un document valid trebuie sa respecte anumite reguli semantice. Aceste reguli pot fi reguli definite de utilizatori sau reguli incluse ca o scema XML, in special DTD (Document Type Definition) (de exemplu, daca un document contine un element nedefinit, atunci el nu este un document valid). Un document XML este format din elemente specificate prin perechi atribut-valoare, elemente care sunt incluse intr-o structura ierarhica arborescenta. Document bine format. Sintactic, fiecare element este deschis printr-un tag de forma <nume> si inchis prin tagul corespunzator </nume>. Pentru a reflecta structura arborescenta elementele deschise trebuie inchise in ordinea inversa deschiderii lor. Un atribut este specificat in tag-ul de deschidere impreuna cu valoarea sa: <nume atribut = valoare >... </nume> Daca un element XML nu are copii, atunci el poate fi scris ca: <nume/> (echivalent cu <nume></nume>). Structura XML foloseste structura calculului atributional [MIC00]. Astfel: un selector este reprezentat printr-o pereche atribut-valoare; intersectia (conjunctia) selectorilor corespunde unei liste de perechi atribute-valoare asociata unui singur element; reuniunea (disjunctia) regulilor corespunde crearii de copii asociati unui element. 5

115 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Astfel un concept poate fi vazut ca un element care are zero sau mai multe reguli drept elemente copil; un selector este o pereche atribut-valoare corespunzatoare unui element regula. De exemplu, un concept poate fi descris ca: <concept> <regula a i = w ij... a k = w kl /> <regula a m = w mn... a p = w pq /> </concept> a i reprezinta atributul i, w i este domeniul sau, w ij face parte din W i este o valoare posibila a sa. Acest concept poate fi reprezentat grafic ca in Figura 1. concept Regula 1 selector S selector S 1n1... Regula k selector S k1... selector S kn1 Figura 1. Reprezentarea grafica a unui concept Exemplul 1: document XML pentru o adresa din Marea Britanie: <?xml version="1.0" encoding="utf-8"?> <Address xmlns:xsi=" xsi:nonamespaceschemalocation="simpleaddress.xsd"> <Recipient>Mr. Walter C. Brown</Recipient> <House>49</House> <Street>Featherstone Street</Street> <Town>LONDON</Town> <PostCode>EC1Y 8SY</PostCode> <Country>UK</Country> </Address> Document valid. Pentru ca elementele componente ale unui document XML sa poata fi accesate si definite prin intermediul unei scheme sau DTD (Document Type Definition) [DTD08]. XMLul ofera o sintaxa pentru acest scop, limbaje bazate pe XML. Sintaxa generala a acestor limbaje este rigida documentele trebuie sa respecte regulile generale XML, asigurand faptul ca orice soft bazat pe XML poate citi si intelege structura relativa a elementelor componente dintr-un document XML. Schema completeaza regulile de sintaxa cu o multime de constrangeri. De obicei schema restrictioneaza elementele si numele atributelor impreuna cu ierarhia permisa pentru componente. Constrangerile din schema pot include asignari de tipuri de date care afececteaza modul in care informatia este procesata. Un document XML care se supune unei scheme particulare/dtd si este bine format reprezinta un document valid. 6

116 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Reprezentarea prin atribut-valoare existenta in XML ofera o modalitate de reprezentare a cunostintelor. Sunt folosite concepte din calculul atributional, dar nu pot fi reprezentate toate conectivitatile logice. De exemplu, nu sunt acceptate structuri recursive sau concepte bazate pe inductie care au numai conditii necesare. In plus nu exista cuantificatori sau posibilitatea de negare, dar acestea pot fi implementate. Reprezentarea de tip atribut-valoare folosita de XML poate fi aplicata pentru reprezentarea cunostintelor numai in sistemele ce au domenii finite pentru valorile atributelor. Pe baza celor enuntate mai sus, XML-ul ofera urmatoarele avantaje: extensibilitate (se pot defini noi indicatori daca este nevoie); validitate (se verifica corectitudinea structurala a datelor ); ofera utilizatorilor posibilitatea de a reprezenta datele intr-un mod independent de aplicatie; se foloseste standardul Unicode, astfel permitandu-se reprezentarea pentru aproape orice informatie din limbajul natural; pot fi reprezentate structurile de date principale: liste si arbori; algoritmii pentru analiza sintactica sunt simpli, eficienti si consistenti; XML-ul este folosit pentru stocare si procesarea documentelor atat online cat si offline; XML-il poate fi validat pe baza limbajeleor schema, care face mai usoara constructia si implementarea; XML Schema Elementele unui document XML sunt declarate in DTD (Document type definition) [DTD08] sau mai general in XML Scema (referita si sub denumire XSD XML Schema Definition) [XSD08]. Schema reprezinta o descriere a unui document XML, de obicei exprimata in termeni de constrangeri asupra structurii si continutului acelui document, constrangeri ce apar peste cele impuse de XML. General o schema este formata dintr-o colectie de metadate, alcatuite dintr-o multime de componente ale schemei: declaratii de elemente, atribute si definitii de tipuri simple si complexe. De obicei aceste elemente sunt create prin procesarea unei colectii de scheme ale documentelor, ce contin definitiile acestor componente. Schemele documentelor sunt organizate pe baza namespace-urilor: toate componentele unei scheme apartin namespace-ului destinatie, care apartine schemei documentului ca un intreg. Un document schema poate include alte scheme de document pentru acelasi namespace si poate importa alte scheme pentru namespace-uri diferite. Pentru a valida instanta unui document fata de o schema, aceasta poate fi furnizata drept parametru motorului ce face validarea sau poate fi referita direct din instanta documentului prin folosirea a doua atribute speciale: xsi:schemalocation si xsi:nonamespaceschemalocation. XML schema permite ca un element sau un atribut sa fie validat in raport cu un tip de date. XSD pune la dispozitie o multime de 19 tipuri de date primitive, permitan de asemena constructia de noi tipuri de date pornind de la cele de baza pe baza mecanismelor: restrictie reducerea multimii valorilor permise; listare permiterea numai a unei secvente de valori; reuniune permiterea selectarilor valorilor din diferite tipuri. 7

117 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Dupa validarea bazata pe schema XML se pot exprima structura si continutul unui document XML in termenii unui model de date care a fost implicit in faza de validare. Modelul de date XML shema include : vocabularul numele elementelor si atributelor ; modelul continutului structura si relatiile; tipurile de date. Aceasta colectie de informatii poarta numele de Post Schema Validation Infoset (PSVI). PSVI furnizeaza un document XML valid si permite folosirea documentului ca un obiect folosind paradigmele programarii orientate obiect. Exemplul 2: de XML schema pentru o adresa din Marea Britanie (corespunzatoare documentului XML din Exemplul 1): <?xml version="1.0" encoding="utf-8"?> <xs:schema elementformdefault="qualified" xmlns:xs=" <xs:element name="address"> <xs:complextype> <xs:sequence> <xs:element name="recipient" type="xs:string" /> <xs:element name="house" type="xs:string" /> <xs:element name="street" type="xs:string" /> <xs:element name="town" type="xs:string" /> <xs:element minoccurs="0" name="county" type="xs:string" /> <xs:element name="postcode" type="xs:string" /> <xs:element name="country"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="fr" /> <xs:enumeration value="de" /> <xs:enumeration value="es" /> <xs:enumeration value="uk" /> <xs:enumeration value="us" /> </xs:restriction> </xs:simpletype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Elementul radacina al unui document XML este <xsd:schema>...</xsd:schema> (xsd specifica namespace-ul XML xmlns al consortiului W3C [W3C08]: xmlns:xsd= Schema documentului XML din Exemplul 1, pentru o adresa din Marea Britanie poate fi reprezentata ca in Figura 2. 8

118 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Figura 2. Reprezentarea documentului XML din Exemplul 1 Principalul scop pentru care a fost creat XML schema este acela de a descrie formal un document XML. Insa schema astfel obtinuta poate fi folosita si in alte scopuri, cum ar fi: generarea documentatiei; generarea codului XML Data Binding [XDB08] (acesta permite documentelor XML sa fie tratate ca obiecte in mediul de programare). 1.2 Reprezentarea cunostintelor pe Web: ontologii Principalul scop in reprezentarea cunostintelor il constituie reprezentarea acestora intro maniera care sa faciliteze inferentele din cunostinte. Principalele probleme rezultate din perspectiva inteligentei artificiale in reprezentarea cunostintelor sunt: cum pot fi reprezentate cunostintele, care este natura cunostintelor si cum poate fi reprezentata si anume o schema de reprezentare va fi caracteristica unui anumit domeniu sau va fi generala, cat de expresiva este o schema de reprezentare sau un limbaj formal, schema ar trebui sa fie declarativa sau procedurala? Termenul de ontologie a aparut in filosofie pentru a denumi teoria asupra existentei, asupra a ceea ce se considera ca exista de catre cel care intocmeste teoria. Construirea oricarui sistem filosofic pleaca de la o ontologie, adica de la clarificarea problemelor referitoare la categoriile de entitati din realitate si a relatiilor dintre ele [GRU08]. In stiinta calculatoarelor o ontologie este o reprezentare formala a unei multimi de concepte dintr-un anumit domeniu impreuna cu relatiile dintre aceste concepte [GRU95]. Este folosita in scopul de a intelege proprietatile acelui domeniu si de asemenea poate fi folosita pentru a defini domeniul respectiv. Ontologiile sunt folosite in inteligenta artificiala, web semantic, ingineria programarii, arhitectura, e-commerce, motoare de cautare, regasirea informatiilor ca o forma de reprezentare a cunostintelor despre lumea inconjuratoare sau o parte a lor. In mod general o ontologie contine o descriere ierarhica a celor mai importante concepte dintr-un domeniu si descrie principalele proprietati ale fiecarui concept pe baza unui mecanism de tip atribut-valoare. In plus, pot fi descrise relatii viitoare intre concepte pe baza 9

119 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic propozitoiilor logice aditionale. In final, indivizii din domeniul de interes sunt asignati unuia sau mai multor concepte in scopul de a le da un tip corespunzator. Principalele componente ale unei ontologii: indivizii: instante ale obiectelor (obiecte de baza) includ obiecte concrete, de exemplu oameni, animale, automobile, plante cat si obiecte abstracte, cum ar fi numere sau cuvinte; clase: multimi, colectii, concepte, tipuri ale obiectelor sau tipuri de lucruri clasele sunt obiecte abstracte ce sunt definite prin valorile aspectelor ce reprezinta constrangeri de apartenenta la clasa respectiva - clasele pot clasifica indivizi, alte clase sau combinatii intre acestea. atribute: aspecte, proprietati, caracteristici sau parametrii obictelor; fiecare atribut poate fi o clasa sau un individ; tipul unui obiect si tipul atributului determina relatia dintre ele; relatii: modalitati prin care clasele si indivizii pot fi legati unul de celalalt; termeni ai functiilor: structuri complexe formate din relatii sigure care pot fi folosite intr-un termen al unui individ intr-o declaratie; restrictii: descrieri formale pentru ce poate fi adevarat pentru o asertiune ce va fi acceptata ca intrare; reguli: declaratii de forma unei propozitii if-then (antecedent-consecvent) sentence care descrie inferentele logice ce pot fi deduse dintr-o asertiune; axiome: asertiuni (incluzand reguli); evenimente: modificarea atributelor sau relatiilor; Astfel o ontologie este o descriere formala, explicita a conceptelor dintr-un anumit domeniu (clase), proprietati ale fiecarui concept ce descriu diferite caracteristici si atribute ale conceptului (roluri sau proprietati) si restrictii asupra proprietatilor (numite si restrictii asupra rolurilor). O ontologie impreuna cu o multime de instante individuale ale claselor formeaza o baza de cunostinte. Ontologiile sunt implementate cu ajutorul limbajelor de ontologii, cum ar fi CycL [CYL08], DAML OIL {DAO08], OWL [OWL08]. 10

120 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic 2 Ontologii O ontologie poate fi vazuta ca o reprezentare formala a unei multimi de concepte dintrun anumit domeniu, precum si a relatiilor dintre aceste concepte. 2.1 Reprezentarea cunostintelor prin ontologii Principalele motive pentru care sunt necesare folosirea ontologiilor [NM01]: pentru a avea o intelegere comuna asupra structurii informatiei - sa presupunem ca mai multe site-uri Web diferite contin informatii medicale si furnizeaza servicii medicale de tip e- commerce. Daca aceste site-uri au la baza aceeasi ontologie pentru termenii pe care ii folosesc, atunci agentii Web pot extrage si compune informatia de pe aceste site-uri diferite. Agentii pot folosi aceasta informatie compusa pentru a raspunde cererilor utilizatorului sau ca si date de intrare ale altor aplicatii; pentru a permite reutilizarea cunostintelor din domeniu- modelele din diferite domenii trebuie sa aiba o reprezentare pentru notiunea de timp, reprezentare ce trebuie sa includa notiunile de interval de timp, momente in timp, unitati de masura ale timpului, etc. Daca un grup de cercetatori dezvolta o astfel de ontologie in detaliu, ceilalti pot pur si simplu sa o utilizeze pentru domeniul lor. In plus, daca avem nevoie sa dezvoltam o ontologie complexa, putem integra ontologiile existente ce descriu portiuni ale domeniului nostru; pentru a explicita ipotezele utilizate in domeniul respectiv - face posibila schimbarea facila a acestor ipoteze atunci cand cunostintele legate de domeniu se schimba. Ipotezele codificate direct in aplicatia informatica fac nu numai ca acestea sa fie greu de detectat si inteles ci si greu de schimbat. In plus, specificatiile explicite ale unui domeniu sunt utile noilor utilizatori care trebuie sa invete termenii din domeniul respectiv; pentru a separa cunostintele din domeniu de implementarea acestuia - putem descrie sarcina de asamblare a unui produs oarecare din componentele sale conform unei specificatii si sa implementam un program care realizeaza aceasta compunere independent de produs si de componentele acestuia; pentru a analiza cunostintele din domeniu - analiza formala a termenilor este extrem de valoroasa atunci cand urmarim sa reutilizam ontologii deja existente sau sa le extindem [MFR00]. Dezvoltarea unei ontologii este asemenea definirii unui set de date si a structurii acestora pentru a fi utilizate de catre un program. Metodele de rezolvarea a unor clase de probleme, aplicatiile independente de domeniu si agentii software utilizeaza ontologii si baze de cunostinte construite din ontologii ca date de intrare. Unele idei de proiectare a unei ontologii pornesc de la proiectarea orientata pe obiecte []RBP91], [BRJ97]. Totusi, dezvoltarea unei ontologii este diferita de proiectarea claselor si a relatiilor din programarea orientata pe obiecte, aceasta centrandu-se in primul rand pe metodele unei clase un programator i-a deciziile pe baza proprietatilor operationale ale unei clase - in timp ce un proiectant al unei ontologii ia deciziile pe baza proprietatilor structurale ale unei clase. Nu exista o singura metoda corecta de proiectare a ontologiilor. O ontologie este o descriere formala explicita a conceptelor dintr-un domeniu: clase (sau concepte), a proprietatilor fiecarui concept ce descriu diferite trasaturi si atribute ale conceptelor (numite 11

121 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic uneori atribute sau roluri) si caracteristici sau restrictii ale atributelor (implicatii, numite si restrictii de rol). 2.2 Limbaje de descriere a ontologiilor Un limbaj de descriere a ontologiilor este un limbaj formal folosint pentru implementarea acesteia. Limbajele de descriere a ontologiilor sunt clasificate in: limbaje traditionale principalele limbaje ce fac parte din aceasta categorie sunt: CycL [CYC08], F-logic, OCML, Ontolingua (bazat pe limbajul KIF [KIF08]) [ONT08]; limbaje bazate pe web - DAML+OIL [DAO08], OWL [OWL08], RDF, RDF Schema [RDF08], SHOE [SHO08]; limbaje bazate pe descrieri logice aceste limbaje reprezinta o extensie a limbajelor bazate pe frame-uri, fara a suporta logica predicatelor first order din aceasta categorie fac parte limbajelele OWL [OWL08]; Limbaje bazate pe logica predicatelor first order : CycL [CYC08], KIF [KIF08]. Dintre limbajele de descriere a ontologiilor prezentam in continuare cateva dintre acestea: Ontolingua [ONT08] este un limbaj pentru reprezentarea si partajarea ontologiilor dezvoltat la KSL (Knowledge Systems Lab) la Universitatea Stanford. Ontolingua nu ofera functionalitate de inferenta, acest limbaj fiind dezvoltat intr-un mediu ce pune la dispozitie functii de dezvoltare a ontologiilor (afisare, creare, editare, modificare si folosirea ontologiilor), precum si o biblioteca modulara de ontologii ce pot fi reutilizabile.de asemenea acest limbaj a fost cheia limbajelor pentru reprezentarea ontologiilor pentru cativa ani, insa nu a mai fost actualizat datorita aparitiei limbajelor bazate pe XML. RDF (Resource Description Framework) [RDF08] este un mediu pentru descrierea metadatelor dezvoltat de consortiul W3C [W3C08]. Acesta se bazeaza pe modelul triplet, de forma: <obiect, atribut, valoare>, in care obiect este o resursa ce reprezinta o pagina web. Un astfel de triplet poate fi un obiect si o valoare, valoarea poate fi un sir sau o resursa. Obiectul si valoarea sunt considerate un nod, iar atributul o legatura intre noduri. Astfel un model RDF formeaza o retea semantica. Sintaxa RDF este bazata pe sintaxa XML lucru care face sa semene cu un limbaj comun bazat pe XML. Insa RDF este diferit de un astfel de limbaj in sensul ca el este un model de reprezentare a datelor decat un limbaj, iar modelul datelor este sub forma unei structuri incuibarite a informatiilor, modelul fiind bazat pe proprietati. In cadrul RDF se pot crea noi reprezentari pentru date care sa contina metainformatii care de obicei nu apar in datele originale. De exemplu, sa consideram ca data un articol existent pe web. Acesta va contine numele autorului, de exemplu Riichiro Mizoguchi. Daca se marcheaza acest lucru in text, pe baza limbajului XML, sub forrma: <author> Riichiro Mizoguchi </author> atunci acest lucru va desemna in mod explicit faptul ca acel sir reprezinta autorul articolului. Pe de alta parte in reprezentarea RDF pentru metadate, de exemplu, autorul poate include si data cand a fost publicat articolul, care nu apare explicit in cadrul articolului. Sa presupunem ca articolul se afla la adresa 12

122 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic atunci descrierea RDF va fi: <rdf:description rdf:about=" <author>riichiro Mizoguchi</author> <pub-date> </pub-date> </rdf:description> Desi RDF a fost proiectat pentru a modela reprezentarea metadatelor, el poate fi folosit si pentru reprezentarea cunostintelor, astfel putem spune ca el este un fel de model semantic de retea. RDF Schema [RDF08] este un limbaj ce permite definirea tag-urilor (vocabularului) folosit de RDF. Cele mai comune metadate, cum ar fi autorul si data crearii sunt definite in DC (Dublin Core) [DC08], in care sunt definite 15 elemente metadata. RDF schema nu trebuuie sa le defineasca pentru a le folosi in RDF ci pot fi imprumutate folosindu-se de ajutorul namespace-ului dc:. La o prima privire corespondenta dintre RDF si RDF Schema ar parea similara cu cea dintre XML si XML schema. Insa acest lucru nu este adevarat. Rolul principal al XML schema este de a constrange instanta careia ii este atasat. De cealalta parte, principalul rol al RDF Schema este de a asocia tag-uri definitiilor si taxonomiei din RDF, totodata si a de a specifica constrangeri asupra valorilor posibile din modelul triplet. Daca XML-ul se poate folosi fara XML Schema RDF este inutil fara RDF Schema. RDF Schema are propriile clase si metaclase interne pe baza carora utilizatorii pot defini orice clasa si relatie. Rdfs:Resource impreuna cu cele doua subclase: rdf:sclass si rdfs:property sunt meta-clasele de baza. Orice clasa definita in RDF Schema este o instanta a rdfs:class. In acelasi mod, fiecare proprietate si relatie definita in RDF schema este o instanta a rdfs:property. Web Ontology Language (OWL) [OWL08] este un limbaj dezvoltat tot de consortiul W3C [W3C08]. OWL este proiectat ca un limbaj comun pentru reprezentarea ontologiilor, fiind bazat pe DAML+OIL [DAML08]. OWL este o extensie a RDF Schema si de asemenea se bazeaza pe modelul triplet. Principiul de proiectare se bazeaza pe dezvoltarea unui limbaj standard de reprezentare a ontologiilor. Datele descriese de o ontologie OWL sunt interpretate ca o multime de indivizi si o multime de proprietati, pe baza carora se inrudesc acesti indivizi. O ontologie OWL consta dintr-o mulime de axiome pe baza carora se asociaza constrangeri multimilor de indivizi si tipuri de relatii permise intre acestea. Aceste axiome furnizeaza semantica ce permite sistemului sa deduca informatiile aditionale pe baza datelor furnizate in mod explicit. De exemplu, o ontologie ce descrie informatii despre o familie, ar trebui sa includa axiome de tipul, ca o proprietate "AreMama" este prezenta intre doi indivizi, numai in conditiile in care exista proprietatea "AreParinti". In plus indivizi ai clasei "AreGrupaSangeO" nu vor fi niciodata inruditi cu membrii clasei "AreGrupaSangeAB", prin intermediul proprietatii "AreParinti". Daca un individ Mara este inrudit cu un individ Sanda, prin intermediul relatiei "AreGrupaSangeO", atunci putem deduce ca Sanda nu este membru al clasei "AreGrupaSangeAB". Specificarea OWL include definirea a trei componente OWL [OWL08]: 13

123 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic OWL Lite a fost dezvoltat pentru a suporta clasificari ierarhice si constrangeri simple. Cardinalitatea restrictiilor poate fi 0 sau 1, iar de asemenea se pot specifica o parte sau toate valorile proprietatii asupra careia se aplica restrictia. De asemena se pot specifica clase sau proprietati ce sunt echivalente (acest lucru este foarte folositor pentru a specifica faptul ca doua concepte in ontologii diferite reprezinta acelasi lucru) si faptul ca proprietatile pot fi functionale, simetrice, tranzitive sau inverse. OWL DL este un limbaj mai avansat bazat pe o submultime decidabila a logicii descriptive. In cadrul acestuia sunt posibile relatii pe disjunctii intre clase sau reuniune, intersectie, complement intre clase. De asemena pot fi specificate cardinalitati pentru restrictii sub forma oricarui numar natural. OWL Full este bazat pe semantica OWL Lite si OWL DL si a fost construit astfel incat sa pastreze o parte dintre compatibilitati cu RDF Schema. De exemplu, in OWL Full o clasa poate fi tratata simultan ca o colectie de indivizi, dar si ca un individ singular (ceea ce nu este permis in OWL DL). OWL Full permite ca o ontologie sa dezvolte intelesul vocabularului predefinit (RDF or OWL). Fiecare dintre aceste sublimbaje este o extensie sintactica a predecesorului sau mai simplu, astfel: Fiecare ontologie OWL Lite este o ontologie valida OWL DL; Fiecare ontologie OWL DL este o ontologie valida OWL Full; Uneltele pentru reprezentarea cunostintelor le rerezinta editoarele si API-urile. Dintre cele mai importante unelte amintim: Protégé [PRO08] este unealta cea mai cunosuta pentru dezvoltarea ontologiilor. Este un editor de ontologii si un framework bazat pe cunostinte open-source, dezvoltat la Universitatea Stanford. Protege este cea mai completa aplicatie de tipul sau, permite construirea de plugin-uri, ofera un API complex si bine documentat. Initial Protege suporta construirea numai de ontologii RDF sau in format propriu. Insa, pe baza plugin-urilor ofera suport pentru OWL, DAML+OIL, XML, limbaje de reguli, unelte de vizualizare, import/export de baze de date, dezvoltarea de ontologii web, WordNet, Prolog, UML. In plus ofera si crearea unei interfete pentru baza de cunostinte. Toate aceste caracteristici fac ca Protege sa fie unealta cea mai buna pentru gestiunea si reprezentarea cunostintelor. Jena2 [JEN08] este un framework open-source pentru construirea aplicatiilor web semantice dezvoltat de HP. El furnizeaza un API care permite construirea de ontologii folosind RDF,OWL sau DAML+OIL, precum si importul/exportul diferitelor tipuri de modele de ontologii. In Jena este posibil rationamentul. API-ul Jena este folosit de Proteje pentru API-ul sau OWL. 2.3 Ontologii de nivel si de domeniu Ontologiile de domeniu descriu vocabularul relativ la un domeniu generic (de exemplu, medicina, automobile etc.). Ele modeleaza un anumit domeniu sau o parte a lumii. Ele reprezinta sensul particular pentru termenii care se aplica domeniului respectiv. De exemplu, cuvantul card are diferite intelesuri. O ontologie pentru domeniul poker va modela sensul cuvantului poker card, in timp ce o ontologie in domeniul calculatoarelor va modela sensul cuvintelor video card sau punch card. 14

124 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Ontologiile de nivel descriu concepte foarte generale cum sunt: spatiul, timpul, materie, obiect, eveniment, actiune etc., ce sunt independente de o problema particulara sau domeniu; se pot aproxima aceste tipuri de ontologii pentru multe comunitati de utilizatori. O astfel de ontologie este un model asupra obiectelor comune care sunt aplicabile in diferite ontologii de domeniu. Dintre ontologiile de nivel existente amintim OpenCyc [OPC08], SUMO {SUo08], WordNet [WON08]. Ontologia Gellish [GEL08] este un exemplu de combinare intre o ontologie de nivel si o ontologie domeniu. 2.4 Concluzii Ontologiile ce descriu cuvintele existente intr-o anumita limba (sau cuvinte din mai multe limbi) pot fi combinate cu ontologii specifice unor domenii ducand la rezolvarea unor probleme ale web-ului semantic al viitorului, si anume: clasificarea, indexarea si regasirea mai precisa a cunostintelor (informatii sau imagini), dezvoltarea de interfeţe multilingve la aplicaţiile specifice web-ului semantic, crearea de comunitati virtuale fara sa se tina cont de de barierele lingvistice. 15

125 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic 3 Logici de descriere Cercetarea in domeniul reprezentarii cunostintelor si a proceselor de inferenta este in general axata pe metode care ofera descrieri de nivel inalt ale universului cunostintelor care pot fi utilizate pentru a construi aplicatii inteligente. In acest context, inteligenta se refera la capacitatea unui sistem de a gasi consecinte implicite pe baza cunostintelor reprezentate explicit. Astfel de sisteme sunt numite sisteme bazate pe cunostinte ([NB]). Logicile de descriere (DLs) ([BHS05], [BS01], [CGLN99]) reprezinta o familie de limbaje de reprezentare a cunostintelor, care pot fi folosite pentru a reprezenta cunostintele dintr-un anumit domeniu, intr-un mod structurat, formal si usor de inteles. Numele de logici de descriere poate fi explicat astfel: pe de o parte prin faptul ca notiuni importante referitoare la domeniu sunt exprimate prin descriere de concepte si pe de alta parte prin faptul ca, logicile de descriere, spre deosebire de predecesorii lor, retelele semantice si frame-urile, contin semantici formale, bazate pe logica. In Figura 1 prezentam arhitectura unui sistem de reprezentare a cunostintelor bazat pe logici de descriere ([BN]): Figura 1. Arhitectura unui sistem de reprezentare a cunostintelor bazat pe logici de descriere Un sistem de reprezentare a cunostintelor bazat pe logici de descriere permite crearea de baze de cunostinte, modificarea lor si realizarea de inferente asupra continutului acestor baze de cunostinte. O baza de cunostinte (KB) este compusa din doua componente TBox si ABox. TBox contine terminologia, adica vocabularul folosit pentru un anumit domeniu, iar ABox contine asertiuni referitoare la anumiti indivizi, utilizand vocabularul din TBox. Un sistem de forma celui prezentat mai sus ofera si servicii de inferenta asupra terminologiei si asertiunilor din sistem. Prezentul material are la baza prezentarea logicilor de descriere realizata in [BN]. 16

126 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic 3.1 Limbaje de descriere DL Descriptorii elementari sunt conceptele (multimi de indivizi) si rolurile (relatii binare intre indivizi). Descrierile mai complexe se pot realiza folosind descriptorii elementari si constructori de concepte. Vom folosi A si B pentru concepte atomice, R pentru roluri si C si D pentru descrieri de concepte. In aceasta sectiune prezentam familia de limbaje Limbajul de descriere Limbajul ( = attributive language ) este considerat un limbaj minimal de interes practic. Descrierile de concepte sunt formate folosind urmatoarele reguli: Pentru a defini o semantica formala pentru conceptele, introducem notiunea de interpretare. Interpretarea este compusa dintr-o multime nevida (domeniul interpretarii) si o functie de interpretare, care asociaza fiecarui concept atomic A o multime si fiecarui rol R o relatie binara. Functia de interpretare se extinde la descrieri de concepte astfel: Spunem ca doua concepte C, D sunt echivalente si scriem C D, daca = pentru toate interpretarile Familia de limbaje Pentru a obtine extensii ale limbajului introducem noi constructori: - reuniunea a doua concepte (indicata in numele limbajului de litera ), scrisa : - cuantificatorul existential (indicat in numele limbajului de litera ), scris : - restrictii numerice (indicate in numele limbajului de litera ), scrise si : 17

127 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic. - negatia conceptelor (nu neaparat atomice) (indicata in numele limbajului de litera ), scrisa ca : Adaugand constructorii de mai sus la limbajul, se obtin alte limbaje : Axiome terminologice si definitii Axiomele terminologice au urmatoarea forma: sau unde C si D sunt concepte, iar R si S sunt roluri. O interpretare satisface o incluziune, daca ; o interpretare satisface o egalitate daca. Daca este o multime de axiome, atunci satisface daca si numai daca sastisface fiecare element din. Daca satisface o multime de axiome, se numeste model al acelui set de axiome. O egalitate a carei parte stanga este un concept atomic se numeste definitie. Definitiile sunt folosite pentru a introduce nume simbolice pentru descrierile complexe ABox In ABox se pot introduce indivizi, asociindu-le nume; in plus se pot asocia proprietati acestor indivizi. Pentru un individ se folosesc nume ca a, b, c. Folosind conceptul C si rolul R, se pot face asertiuni de urmatoarele tipuri: C(a) (asertiuni de concept) si R(b,c) (asertiuni de rol). Privita la modul general, un ABox este o instanta a unei baze de date relationale, care are doar relatii unare si binare. Totusi, spre deosebire de principiul lumii inchise (absenta informatiei este considerata informatie negativa; informatia existenta este considerata completa) folosit de bazele de date clasice, aici se foloseste principiul lumii deschise (absenta informatiei indica lipsa informatiei; informatia existenta este considerata incompleta). O interpretare satisface ABox-ul daca satisface fiecare asertiune din. In acest caz spunem ca este un model al ABox-ului. 3.2 Inferente in DL Un sistem de reprezentare a cunostintelor bazat pe logici de descriere poate obtine noi cunostinte din cele existente folosind inferente. O baza de cunostinte ce contine TBox si ABox este echivalenta cu o multime de axiome din logica cu predicate de ordinul I. Astfel, prin inferente, cunostintele implicite existente in baza de cunostinte pot deveni explicite Inferente pentru concepte Fie un TBox. In continuare definim o serie de termeni: 18

128 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic - Satisfiabilitate: un concept C este satisfiabil referitor la daca exista un model al lui astfel incat este nevid. - Subsumare: un concept C este subsumat de un concept D referitor la daca pentru toate modelele ale lui - Echivalenta: doua concepte C si D sunt echivalente referitor la daca pentru toate modelele ale lui - Disjunctie: doua concepte C si D sunt disjuncte referitor la daca pentru toate modelele ale lui Avem urmatoarele rezultate referitoare la inferenta intr-un sistem de reprezentare a cunostintelor bazat pe logici de descriere: Propozitia 1 (Reducerea la subsumare) Fie C si D doua concepte. Atunci: a) C este nesatisfiabil C este subsumat de b) C si D sunt echivalente C este subsumat de D si D este subsumat de C c) C si D sunt disjuncte este subsumat de Propozitia 2 (Reducerea la nesatisfiabilitate) Fie C si D doua concepte. Atunci: a) C este subsumat de D este nesatisfiabil b) C si D sunt echivalente si sunt nesatisfiabile c) C si D sunt disjuncte este nesatisfiabil Propozitia 3 (Reducerea nesatisfiabilitatii) Fie C un concept. Atunci urmatoarele afirmatii sunt echivalente: a) C este nesatisfiabil b) C este subsumat de c) C si sunt equivalente d) D si sunt disjuncte Inferente pentru ABox Intr-un ABox sunt doua tipuri de asertiuni, asertiuni de concept C(a) si asertiuni de rol R(b,c). Reprezentarea cunostintelor trebuie sa fie consistenta pentru a nu rezulta in urma inferentelor, concluzii gresite. Un ABox este consistent referitor la un TBox, daca exista o interpretare care este model atat pentru cat si pentru. Spunem ca o asertiune este legata de ABox-ul, si scriem, daca orice interpretare care satisface, satisface pe. Avem urmatoarele rezultate: - este inconsistent. - C este satisfiabil este consistent 19

129 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic 3.3 Algoritmi de rationament Numim algoritm stabil un algoritm cu proprietatea ca atunci cand gaseste o solutie pentru o instanta a problemei, acea solutie este intr-adevar o solutie a problemei. Numim algoritm complet un algoritm cu proprietatea ca de fiecare data cand o instanta a problemei are solutie, algoritmul calculeaza acea solutie. Putem spune ca toate problemele importante referitoare la inferenta se pot reduce la problema consistentei pentru ABox-uri, presupunand ca logica de descriere permite conjunctia si negatia. Cu toate acestea, multe dintre sistemele bazate pe logici de descriere nu permit utilizarea negatiei. Pentru astfel de logici de descriere, subsumarea conceptelor poate fi realizata cu ajutorul algoritmilor de subsumare structurala (adica algoritmi care compara structura sintactica a descrierilor de concepte). Un algoritm de subsumare structurala are doua faze: in prima faza se normalizeaza descrierile care urmeaza sa fie testate pentru subsumare, iar in a doua faza se compara structurile sintactice ale celor doua descrieri normalizate. Desi algoritmii de subsumare structurala sunt foarte eficienti, ei sunt completi doar pentru limbaje simple cu expresivitate scazuta. Logicile de descriere care permit negatie si disjunctie nu pot fi abordate utilizand astfel de algoritmi. Pentru aceste logici se utilizeaza tableau based algorithms. Un algoritm tableau based nu testeaza direct subsumarea descrierilor de concepte, ci foloseste negatia pentru a reduce subsumarea la nesatisfiabilitatea descrierilor de concepte: C este subsumat de D este nesatisfiabil. Utilizand ideea de la tableau based algorithms, au fost construiti mai multi algoritmi stabili si completi pentru verificarea satisfiabilitatii (deci si a subsumarii). In loc de a construi noi algoritmi pentru rationamente in sisteme bazate pe logici de descriere, se poate incerca reducerea problemei studiate la o problema de inferenta din logica. De exemplu, decidabilitatea problemelor de inferenta pentru si pentru multe alte logici de descriere poate fi obtinuta ca o consecinta a rezultatelor referitoare la decidabilitatea pentru formule de doua variabile din calculul cu predicate de ordinul I. Alti algoritmi pentru rationamente in sisteme bazate pe logici de descriere pot fi obtinuti folosind legatura dintre logicile de descriere si logicile modale propozitionale. 3.4 Extensii ale limbajelor DL Desi limbajul poate fi privit ca un prototip pentru limbajele de descriere DL, pentru multe aplicatii expresivitatea acestui limbaj nu este suficienta. Din acest motiv au fost introdusi mai multi constructori de limbaj pentru a construi extensii ale limbajului Constructori de rol Rolurile sunt vazute ca relatii binare. De aceea este natural sa fie folosite operatiile de baza pentru relatii binare (operatori booleeni, compunere, inversare, inchidere tranzitiva). Definitie (Constructori de rol) Orice nume de rol este o descriere de rol (rol atomic), si daca R, S sunt descrieri de roluri, atunci (intersectia), (reuniunea), (complementul), (compunerea), (inchiderea tranzitiva) si (inversarea) sunt tot descrieri de roluri: Fiind data o interpretare, aceasta poate fi extinsa la descrieri (complexe) de roluri astfel: 20

130 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic, adica este inchiderea tranzitiva pentru Restrictii numerice expresive Exista trei metode de a crea restricitii numerice expresive. Prima metoda se refera la restrictiile numite restrictii numerice calificate, unde restrictia numerica se refera la argumentele unui rol pentru un anumit concept. De exemplu, fiind dat rolul haschild, restrictia numerica introdusa mai sus, poate sa arate ca numarul de copii este intre anumite limite, ca in conceptul. Restrictiile numerice calificate pot, in plus, sa exprime ca sunt cel putin 2 baieti si 5 fete: A doua metoda se refera la folosirea in interiorul restrictiilor numerice a expresiilor complexe ce contin roluri. Astfel au fost studiate limbaje care permit utilizarea compunerii de roluri in restrictiile numerice. A treia metoda consta in inlocuirea numarului n, dat explicit in restrictia numerica, cu variabile care tin locul unor numere naturale. Astfel, putem defini, de exemplu, conceptul care reprezinta toate persoanele care au cel putin un numar de fii si de fiice, fara sa se spuna explicit de ce numar e vorba: Harti rol-valoare Hartile pentru valorile rolurilor reprezinta o familie de constructori de concepte, foarte expresivi. Definitie Un lant de roluri este o compunere de nume de roluri:. Daca R, S sunt lanturi de roluri, atunci si sunt concepte (harti rol-valoare). Prima expresie este numita harta rol-valoare de incluziune, iar a doua este numita harta rol-valoare de egalitate. O interpretare se extinde la harti rol-valoare astfel: 21

131 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic 3.5 Concluzii Inca de la aparitia lor, la sfarsitul anilor 70, ca remediu pentru problemele logice si semantice care apareau ca urmare a folosirii reprezentarilor bazate pe frame-uri si retele semantice, logicile de descriere au devenit un formalism unic de extrem de important in istoria reprezentarii cunostintelor ([NB]). Logicile de descriere ofera un formalism simplu si usor de folosit pentru reprezentarea cunostintelor. O caracteristica importanta a logicilor de descriere este decidabilitatea lor (pentru a fi exacti exista si logici de descriere care nu sunt decidabile, dar marea majoritate a logicilor de descriere sunt decidabile). Un domeniu important de utilizare a logicilor de descriere este webul semantic. Pentru exemplificare, mentionam limbajul OWL-DL pentru reprezentarea ontologiilor. Acesta este un limbaj suficient de expresiv pentru a avea o mare aplicabilitate in practica. 22

132 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic 4 Limbajul OWL 4.1 XML Schema şi RDF XML Schema Limbajul XML (Extensible Markup Language) a apărut ca o variantă simplificată a limbajului SGML (Standard Generalized Markup Language) şi vine în întâmpinarea nevoii sistemelor informatice de partajare a datelor structurate (în special peste Internet), el fiind folosit atât în codarea de documente, cât şi în serializarea datelor. Limbajul XML oferă specificaţiile necesare ce permit utilizatorilor să îşi creeze propriile formate pentru stocarea şi partajarea informaţiei. Întrucât aceştia îşi pot defini propriile elemente de limbaj, XML este încadrat în categoria limbajelor extensibile (Extensible). La zece ani de la apariţie, limbajul XML este extrem de popular în rândul programatorilor, analiştilor de baze de date, autori ai literaturii de specialitate şi alţii, ubicuitatea acestui limbaj făcându-i să ia in considerare necesitatea prelucrării XML în business. Aplicabilitatea XML Succesul limbajului XML provine din convergenţa unei imense diversităţi de interese şi domenii de aplicabilitate. Numai din sfera de business, spre exemplu, putem enumera următoarele aplicaţii: XBRL (extensible Business Reporting Language) un limbaj bazat pe XML folosit în lumea financiară, folosirea tehnologiei XML in manualelor de întreţinere de catre fabricanţii de maşini sau de avioane sau de catre instituţiile guvernamentale pentru documentaţii. În plus, publicarea pe Web (Web publishing) sau căutarea pe Web (Web searching) beneficiază, de asemenea, de pe urma folosirii formatului XML. Înainte de apariţia limbajelor de descriere precum SGML sau XML, designerii de software erau cei care işi defineau nişte formate speciale pentru fişiere sau mici limbaje pentru a face posibilă partajarea datelor între programe. Toate acestea necesitau specificaţii detaliate şi programe de scriere sau parsare specifice fiecărui tip în parte. Structura regulată a limbajului XML şi regulile stricte de parsare permit designerilor software să delege parsarea către instrumente standard şi să se concentreze asupra dezvoltării propriilor reguli pentru date la un nivel relativ înalt de abstractizare. XML Schema XML Schema reprezintă descrierea unui tip de document XML. Această descriere se exprimă de cele mai multe ori sub forma unor constrângeri asupra structurii şi conţinutului unui anumit tip de documente, constrângeri ce se adaugă acelora impuse de însuşi limbajul XML. XML 1.0 includea o serie de instrumente pentru definirea stucturii unui document, numite DTDs (Document Type Definitions). Deşi aceste instrumente permiteau definirea structurii elementelor şi atributelor, ofereau mecanisme de setare a valorii implicite pentru atribute precum şi pentru adaugarea unui fel de metadate, cerinţele multor dezvoltatori au depăşit rapid capabilităţile oferite de DTDs. 23

133 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Consorţiul World Wide Web (W3C) a reuşit să răspundă acestor cerinţe prin construirea unui nou limbaj, care să ofere mai multă precizie în descrierea structurii şi conţinutului documentelor XML, să suporte namespace-uri XML şi să poată folosi un vocabular XML pentru a descrie alte vocabulare XML. Acest limbaj este XML Schema şi este descris prin recomandările normative W3C XML Schema Part 1: Structures şi Schema Part 2: Datatypes alături de recomandarea non-normativă Part 0: Primer. Functiile principale ale XML Schema Rolul principal al XML Schema este acela de validare a unui document XML. Validarea este necesară atunci când se primeşte un document nou în vederea procesării sau în urma producerii unui document (fie manual, fie de către o aplicaţie). Validarea are ca scop reducerea riscului procesării unor documente care nu sunt conform specificaţiilor sau al propagării erorilor în cazul transformărilor aplicate unui document în sistem de banda de asamblare. Există mai multe niveluri de validare: validarea structurală prin care se asigură structura impusă elementelor şi atributelor, validarea datelor, care asigură conformitatea conţinutului acestor structuri cu tipul de informaţie specificat, şi mai poate exista un set de reguli de business care verifică relaţiile dintre informaţii la un nivel mai înalt, însă acestea intră mai degrabă în domeniul verificărilor procedurale. Chiar şi în cazurile în care validarea nu este necesară, XML Schema poate fi folosit pentru documentarea vocabularelor XML. La publicarea specificaţiilor unui nou vocabular XML, cel mai adesea, se ataşează şi o schemă XML. Schemele oferă o descriere formală a vocabularului cu o precizie şi concizie care ar fi dificil de atins altfel. Schemele au avantajul că pot fi interpretate de către sistemele informatice, iar documentaţia pentru utilizatori se poate genera uşor pe baza descrierilor formale. Întrucât cunoaşterea structurii unui document şi a tipurilor de date folosite poate creşte eficienţa unor funcţii precum cele de căutare, sortare sau comparare, noile versiuni Xpath şi XSLT, precum şi noul limbaj de interogare XQuery se bazează pe disponibilitatea acestor caracteristici în XML Schema RDF (Resource Description Framework) RDF reprezintă un formalism grafic cu o sintaxă XML şi o semantică asociată pentru reprezentarea metadatelor, pentru descrierea semanticii informaţiilor într-un mod accesibil pentru calculator. Modelul de date RDF este compus din afirmaţii care descriu proprietăţi ale resurselor. O resursă este orice obiect care poate fi indicat printr-un URI. Proprietăţile sunt şi ele la rândul lor tot resurse (URI-uri). În RDF există legături între afirmaţii, astfel încât, subiectul unei afirmaţii poate fi obiectul alteia. O astfel de colecţie de afirmaţii formează un graf orientat şi etichetat. RDF are o sintaxă XML cu o anumită semnificaţie: elementele Description descriu o resursă iar orice atribut sau element imbricat al unui element Description este o proprietate a acelei resurse. Nu se face nici o distincţie între clase şi instanţe (indivizi) iar proprietăţile însele pot avea la rândul lor proprietăţi. Spre exemplu: <hasdaughter,subpropertyof,haschild> <hasdaughter,type,familyproperty> 24

134 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Nu există nici o distincţie între constructorii de limbaj şi vocabularul ontologiei, astfel încât constructorii se pot aplica asupra lor înşişi. <type,range,class> <Property,type,Class> <type,subpropertyof,subclassof> Aplicatii importante : owl Una dintre influenţele majore în conceperea limbajului OWL au fost cerinţele de menţinere, într-o măsură cât mai mare, a compatibilităţii cu limbajele deja existente, în special cu RDF. Aceste cerinţe erau justificate întrucât RDF (mai precis RDF Schema) includea deja unele dintre caracteristicile de bază ale unui limbaj de descriere a ontologiilor bazat pe clase şi proprietăţi (spre exemplu, permite declararea relaţiilor de subclasă şi subproprietate). Mai mult, dezvoltarea RDF a precedat-o pe cea a limbajului OWL, şi de aceea, era normal ca noul limbaj să încerce să fie pe placul utilizatorilor din comunitatea deja existentă stabilită de RDF. La început, părea suficientă alegerea pentru OWL a unei sintaxe bazate pe RDF. Ulterior, s-a considerat necesară şi asigurarea unei semantici OWL compatibilă cu cea din RDF. În cele din urmă, toate acestea s-au dovedit a fi destul de greu de implementat, dată fiind creşterea puterii de exprimare oferită de OWL. [HPH03] 4.2 Elemente de bază în OWL Definiţie OWL Web Ontology Language este o familie de limbaje de reprezentare a cunostintelor pentru crearea si gestionarea ontologiilor. OWL este un limbaj ce defineşte conceptele specifice domeniului de discurs şi enunţă faptele pe care se bazează lumea descrisă. Specii de OWL Influenţele multiple manifestate de limbajele ce stau la baza OWL (Description Logics, SHOE, DAML+OIL) asupra dezvoltării acestuia, au dus la apariţia a numeroase probleme de sintaxă, semantică sau computaţionale. Deoarece dificultatea consta în rezolvarea constrângerilor rezultate din combinarea tuturor acestor probleme, şi nu a fiecărei probleme în parte, s-a găsit o soluţie viabilă prin lansarea a trei varietăţi OWL, fiecare dintre ele reuşind sa îndeplinească aproape toate cerinţele impuse. Cele trei specii de OWL sunt: OWL DL, OWL Lite şi OWL Full. OWL DL are o sintaxă prietenoasă, inferenţele pot fi scrise într-o manieră Description Logic şi sunt decidabile. OWL Lite oferă o sintaxă mai simplă decât OWL DL şi inferenţe tractabile. OWL Full oferă posibilitatea dezvoltării nerestricţionate de construcţii OWL, asupra cărora însă nu se pot face inferenţe. OWL Full reprezintă o extensie sintactică şi semantică a RDFS, aşadar este compatibil cu RDF şi RDFS. [HPH03] În concluzie, există două stiluri în care poate fi folosit OWL. În primul, atunci când se lucrează în OWL DL sau OWL Lite, numai anumite construcţii sunt permise, iar aceste construcţii pot fi combinate numai într-un anunmit fel. Beneficiile pentru alegerea utilizării acestui stil, în ciuda limitărilor impuse, constau în decidabilitatea inferenţelor şi posibilitatea de a aborda limbajul OWL într-o manieră orientată asupra standardului. 25

135 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic În cel de-al doilea stil, lucrând în OWL Full, sunt permise toate grafurile RDF. Avantajele acestui stil expansiv includ o mai mare putere de expresie şi compatibilitatea cu RDF. [HPH03] În timp ce mulţi suporteri ai OWL DL susţin ca Web-ul semantic nu are sens în absenţa unei fundaţii logice clare, există şi cazuri în care are este suficientă exploatarea numai a anumitor caracteristici ale limbajului OWL. Selectarea unei varietăţi OWL depinde de scopul principal al utilizatorului : construirea unei taxonomii, a unor structuri de date sau a unor modele complexe pentru reprezentarea cunoştinţelor. Spre exemplu, o ontologie destinată comerţului electronic poate conţie clase de date despre clienţi împreună cu adresele şi numerele de telefon. O primă versiune a unei astfel de ontologii nu necesită construcţii OWL mai avansate decât specificarea domeniului şi al codomeniului. Aceste ontologii simple din punct de vedere semantic sunt suficiente pentru a servi unei aplicaţii Web care generează formulare pentru a interacţiona cu utilizatorul pe baza claselor definite şi pentru a descrie o schemă care să poată fi integrată cu baze de date convenţionale. Mai departe în ciclul de viaţă al ontologiei, dezvoltatorii pot să considere că au nevoie de şi mai multă expresivitate, spre exemplu, pentru a îi clasifica pe clienţi în funcţie de ceea ce au cumpărat. [KHM05] OWL DL (utilizarea OWL în stilul Description Logic) se bazează pe limbajul SHOIN(D), un set de logici de descriere foarte expresive şi puternice spre exemplu, cu ajutorul lor se pot construi descrieri booleene folosind doar reuniunea şi complementul. Această logică de descriere este oarecum dificil de prezentat utilizatorilor nefamiliarizaţi, de aceea, a fost selectata doar o submulţime a OWL DL care să fie mai simplu de utilizat din multe puncte de vedere. Această submulţime se numeşte OWL Lite. OWL Lite interzice reuniunea şi folosirea mulţimilor complementare, restricţionează intersecţiile la cele implicite din axiomele cadru pentru clase, limitează toate descrierile incorporate la numele conceptelor, nu permite ca indivizii să apară în descrieri sau axiome de clase iar cardinalitatea este limitată la 0 şi 1. Aceste restricţii fac versiunea Lite a limbajului OWL să fie similară cu Description Logic SHIF(D). OWL Lite aduce o îmbunătăţire semnificativă a tractabilităţii fără a pierde mult din puterea de expresie. Cu toate că sintaxa OWL Lite este mult restricţionată faţă de cea a OWL DL, pot fi exprimate descrieri complexe prin introducerea unor noi nume de clase şi exploatarea negaţiilor implicite introduse de axiomele de disjuncţie. Folosind aceste tehnici, toate descrierile OWL DL pot fi cuprinse în OWL Lite, cu excepţia celor ce fie conţin nume de indivizi sau au cardinalitatea mai mare ca 1. [HPH03] OWL DL şi OWL Lite sunt extensii ale unei utilizări restrânse a RDF şi RDFS, deoarece, spre deosebire de RDF şi RDFS, nu permit claselor să fie folosite drept indivizi iar constructorii din limbaj nu pot fi aplicaţi limbajului însuşi. Pentru utilizatorii care au nevoie de aceste capabilităţi, exită versiunea OWL Full care este compatibilă cu RDF şi RDFS. În OWL Full, toţi combinatorii RDF şi RDFS sunt permişi. Spre exemplu, în OWL Full este posibilă impunerea unei constrângeri de cardinalitate asupra rdfs:subclassof, dacă asta se doreşte. Deoarece restricţiile necesare pentru a păstra decidabilitatea în OWL DL nu se aplică în OWL Full, acesta din urmă nu este decidabil. În al doilea rând, sintaxa abstractă folosită în OWL DL este inadecvată pentru OWL Full, aşadar sintaxa oficială RDF/XML este cea care trebuie folosită. 26

136 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Componente de bază Limbajul OWL oferă o semantică decidabilă pentru modelarea primitivelor şi combinarea vocabularelor. Întrucât organizarea conceptelor într-o structură de arbore nu este potrivită pentru modelarea realităţii, în OWL informaţiile sunt organizate sub formă de graf etichetat (numit şi cercuri şi săgeţi ). Indivizii reprezintă entităţile sau fenomenele concrete dintr-un domeniu de interes. Clasele, în OWL, reprezintă un mecanism de abstractizare pentru gruparea indivizilor având caracteristici similare. Există trei modalităţi pentru definirea unei clase: axiomatic, prin extindere sau prin conotaţie. Axiomatic se refera la definirea unei clase prin simpla declarare a acesteia (spre exemplu: clasa Om, clasa Maşină). A defini o clasă prin extindere înseamnă a enumera toţi indivizii ce aparţin acelei clase, spre exemplu: {Germania, Italia, Franţa}. O clasă definită prin conotaţie, este o clasă pentru care a fost stabilit un criteriu de apartenenţă, spre exemplu, să aibă culoarea roşie. Astfel, pot exista două clase având aceeaşi membri, dar care să fie totuşi diferite. Un individ poate fi declarat explicit ca aparţinând unei clase. Clasele pot fi organizate într-o ierarhie de subclase şi superclase. Dacă un individ este membru al unei clase, el aparţine şi tuturor superclaselor aceste clase. O clasă poate fi construită ca o subclasă a unei clase. Spre exemplu, dacă există clasa Bărbat inclusă în clasa Om, înseamnă că o condiţie necesară pentru un individ să fie Bărbat este să fie Om. În cazul în care o clasă este definită ca un echivalent (un sinonim ) al altei clase, spre exemplu,, condiţia necesară şi suficientă pentru a fi SimpluMuritor este apartenenţa la clasa Om. O clasă se poate construi şi prin intersecţia sau reuniunea a două sau mai multe clase. Reuniunea dintre clasa Human şi Male Intersecţia dintre clasa Human şi Male Dacă o clasă (spre exemplu NonHuman) este construită ca şi complement al altei clase (Human), condiţia necesară şi suficientă pentru ca o entitate să aparţină clasei NonHuman este să nu aparţină clasei Human. Clase disjuncte Clasele disjuncte sunt cele care nu pot avea membri comuni. În imaginea de mai sus, spre exemplu, o condiţie suficientă pentru a NU face parte din clasa Bărbat este apartenenţa la clasa Femeie şi viceversa. [STA05] 27

137 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Clasele Thing şi Nothing Condiţia necesară şi suficientă pentru apartenenţa la clasa Thing este întotdeauna satisfăcută, ceea ce înseamnă că toate clasele sunt subclase ale clasei Thing şi că toţi indivizii sunt membri ai aceste clase. Condiţia necesară şi suficientă pentru apartenenţa la clasa Nothing nu este niciodată îndeplinită, ceea ce înseamnă că această clasă este o subclasă a oricărei clase şi că nu poate conţine nici un individ. Clase anonime În OWL există şi conceptul de clase anonime. Membrii unei clase anonime sunt acei indivizi care satisfac definiţiile logice ale clasei. O clasa anonimă poate fi construită cu ajutorul următoarelor expresii logice: - Reuniune sau Intersecţie (Or, And) - Complement (Not) - Enumerare (specificarea apartenenţei) - Restricţii (prin utilizarea proprietăţilor) [REC04] Proprietăţi Proprietăţile stabilesc o relaţie binară între doi indivizi sau între un individ şi o valoare, putând fi definite însâ, independent de indivizi. În exemplul de mai jos, s-a folosit reprezentarea cu cercuri şi săgeţi pentru a ilustra o ontologie în care sunt definite cinci proprietăţi (name, hascapitalcity, livesin, hasbrother şi hasage). În acest exemplu, hascapitalcity este o proprietate de tip obiect, şi leagă doi indivizi, în timp ce codomeniu pentru proprietatea hasage este reprezentat de mulţimea numerelor naturale, ceea ce înseamnă că hasage este o proprietate care face legătura între un individ şi o valoare. Pentru acest tip de proprietăţi codomeniul poate fi un tip de date sau un anumit tip 28

138 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic din XML Schema (ex: xsd:int, xsd:string, etc). Mai există şi Annotation Property utilă în ataşarea de metadate claselor, proprietăţilor sau indivizilor. Proprietăţile se organizează la randul lor într-o ierarhie de proprietăţi, ca şi clasele, putând fi mai mult sau mai puţin specifice. Spre exemplu, proprietatea arefiică este inclusă în proprietatea arecopil. Proprietăţile pot fi tranzitive, inverse, simetrice, funcţionale sau funcţionale inverse. Restricţii O restricţie defineşte un criteriul de apartenenţă în funcţie de o proprietate, un cuantificator (universal sau existenţial) sau un filtru pentru valorile unei proprietăţi. Alte restricţii utilizate în OWL sunt: hasvalue, restricţia de cardinalitate sau restricţia obţinută prin combinarea celor doi cuantificatori (universal şi existenţial). Exemple: Pentru a ilustra restricţia hasvalue vom alege un exemplu în care se doreşte selectarea tuturor persoanelor care sunt prietene cu individul Andrei. Asftel, se defineşte o clasă anonimă (clasa prietenilor lui Andrei) iar condiţia necesară şi suficientă pentru ca o entitate să aparţină acestei clase este să aibă relaţia isfriendwith cu Andrei. În cazul restricţiilor de cardinalitate se defineşte o clasă anonimă pentru care, condiţia necesară şi suficientă de apartenenţă pentru o entitate la această clasă este sa aibă definite un anumit număr de relaţii cu alţi indivizi dintr-o clasă dată. Pentru situaţiile în care se utilizează atât cuantificatorul existenţial cât şi cel universal, avem următorul exemplu: Din care se înţelege că un vegetarian este cineva care mănâncă mâncare vegetariană şi mănâncă numai mâncare vegetariană. Sintaxa OWL este un limbaj independent de sintaxă astfel încât există mai multe reprezentări. Printre cele mai utilizate se numără Sintaxa abstractă, N3 şi RDF/XML. [DRU05] Sintaxa abstractă pentru limbajul OWL este una dintre cele mai uşor de citit de către utilizator. Iată un exemplu: Class(SpicyPizza complete annotation(rdfs:label "PizzaTemperada"@pt) annotation(rdfs:comment "Any pizza that has a spicy topping is a SpicyPizza"@en) Pizza restriction(hastopping somevaluesfrom(spicytopping)) ) N3 este sintaxa recomandată pentru fragmentele care ar trebui să poată fi citite de către un utilizator uman. Exemplu: default:spicypizza a owl:class ; rdfs:comment "Any pizza that has a spicy topping is a SpicyPizza"@en ; 29

139 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic rdfs:label "PizzaTemperada"@pt ; owl:equivalentclass [ a owl:class ; owl:intersectionof (default:pizza [ a owl:restriction ; owl:onproperty default:hastopping ; owl:somevaluesfrom default:spicytopping ]) ]. Sintaxa RDF/XML este recomandată în vederea serializării: <owl:class rdf:id="spicypizza"> <rdfs:label xml:lang="pt">pizzatemperada</rdfs:label> <rdfs:comment xml:lang="en">any pizza that has a spicy topping is a SpicyPizza</rdfs:comment> <owl:equivalentclass> <owl:class> <owl:intersectionof rdf:parsetype="collection"> <owl:class rdf:about="#pizza"/> <owl:restriction> <owl:onproperty> <owl:objectproperty rdf:about="#hastopping"/> </owl:onproperty> <owl:somevaluesfrom rdf:resource="#spicytopping"/> </owl:restriction> </owl:intersectionof> </owl:class> </owl:equivalentclass> </owl:class> 4.3 Inferenţe în OWL Unul dintre aspectele care diferenţiază limbajul OWL de RDF este capacitatea sa de a suporta o mulţime extinsă de inferenţe. Unele dintre aceste inferenţe sunt destul de evidente, şi de aceea par a fi uşor de calculat, altele însă sunt suficient de complexe încât să necesite folosirea unui raţionament pe baza cazurilor similare rezolvate în trecut sau urmărirea lanţurilor de proprietăţi. Relaţiile dintre entităţile descrise în cadrul ontologiei sunt cele enunţate de utilizator, prin definirea proprietăţilor ce leagă doi indivizi la care se adaugă relaţiile pe care limbajul OWL ne permite să le obţinem prin inferenţe. 30

140 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Pentru a infera informaţiile care nu sunt conţinute explicit în ontologie, se folosesc programe numite generic reasoner; acestea pot fi întâlnite şi sub numele de clasificatoare. În figura de mai sus sunt ilustrate relaţiile inferate pe baza relaţiilor declarate. Acestea sunt inferenţe la nivelul proprietăţilor. La nivel de clase, reasoner-ul îndeplineşte următoarele funcţii: verificarea subsumărilor (dacă o clasă este subclasă a altei clase), clasificarea (determină clasele care subsumează direct sau sunt subsumate de o anumită clasă), construirea taxonomiei (a ierarhiei explicite a claselor) şi verificarea satisfiabilităţii pentru fiecare clasă. La nivel de individ se verifică dacă un individ poate exista în modelul dat (consistenţă), gradul de realizare (dându-se o descriere parţială a unui individ, găseşte clasa cea mai specifică în care este descris) sau se pot căuta toţi indivizii ce aparţin unei clase date. [STA05] Utilizarea unui reasoner Pe parcursul construirii unei ontologii, reasoner-ul poate fi folosit ca şi compilator pentru a se urmări dacă înţelesul este cel intenţionat. Folosirea reasoner-ului la momentul publicării face ca relaţiile inferate să devină disponibile pentru aplicaţia utilizator. Pentru interogarea unei ontologii (mai ales pentru ontologiile mai mici), este necesară folosirea reasoner-ului la runtime. Multe instrumentele de editare şi API-uri folosesc reasoner-i ce implementează interfaţa DIG; aceasta înseamnă că reasoner-ul este independent de aplicaţia care îl foloseşte, şi deci, poate fi ales în funcţie de necesităţi (unele pot fi optimizate, spre exemplu, în privinţa vitezei şi a consumului de memorie, în timp ce altele pot oferi mai multe funcţionalităţi). În general, reasoner-ii configurează un serviciu care să ruleze local sau pe un server la distanţă. Spre exemplu, editorul de ontologii Protégé-OWL se poate conecta la reasoneri printr-o conexiune http. Exemple de reasoneri 31

141 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic În continuare vom trece în revistă câteva dintre variantele existente de reasoneri. Cel mai popular pare a fi FaCT++, produs în cadrul proiectului WonderWeb [FAC08]. Acesta este un reasoner DL care foloseşte o mare parte din tehnicile standard de optimizare precum şi algortimi tableaux. Pentru aplicaţiile orientate asupra semanticii care trebuie să reprezintre şi să raţioneze asupra informaţiilor folosind OWL, Pellet este o opţiune demnă de luat în seamă pentru sistemele în care un raţionament OWL DL complet şi corect este esenţial. Pellet include şi suport pentru profile OWL 2 printre care şi OWL 2 EL. Are incorporate diverse tehnici de optimizare precum optimizări novel pentru nominali, tehnici de răspuns la interogări conjunctive sau raţionament incremental. Un alt clasificator este RACER (Robust Server for Scalable Ontology Reasoning). RACER suportă reguli, raţionament asupra constrângerilor şi o manieră expresivă de răspuns la interogări (spre exemplu în sintaxă SPARQL). Printre alte opţiuni de reasoneri se numără şi DPL [PRE08], KAON2 [KRO07] sau The NeOn Toolkit [NEO07] Lanţuri de proprietăţi OWL 1 nu oferă mijloace pentru definirea proprietăţilor ca şi compuneri ale altor proprietăţi. OWL 1 permite doar propagarea valorilor prin intermediul unei proprietăţi dacă aceasta este tranzitivă, dar nu permite propagarea unei proprietăţi (ex: estelocalizatin) împreună cu o altă proprietate (ex: facepartedin) ceea ce ar fi foarte util, mai ales în biologie. De asemenea, în OWL 1, utilizatorii nu pot defini proprietăţi ca şi lanţuri de relaţii (precum proprietatea areunchi, stiind că un unchi este fratele unui părinte). OWL 2 permite înlănţuirea mai multor proprietăţi de obiecte cu ajutorul unei noi construcţii numite PropertyChain. [OWL07] Ipotezele pe care se bazează Ipoteza lumii deschise (Open World Assumption) Într-o lume închisă, precum bazele de date spre exemplu, se consideră că în afara informaţiei conţinute mai există nimic. În contextul Web-ului semantic, însă, se doreşte ca oamenii să poată extinde modelele existente. În această lume deschisă se presupune că întotdeauna pot fi adăugate informaţii mai târziu. Dacă o bază de date întoarce un răspuns negativ atunci când nu găseşte anumite informaţii, reasonerul nu face nici un fel de presupuneri în privinţa completitudinii informaţiilor. Reasonerul nu poate determina că ceva este fals decât dacă acest lucru este specificat explicit în model. Cu alte cuvinte, dacă ceva a fost declarat se presupune că este adevărat, în caz contrar, nu se poate şti nimic despre el. Ipoteza numelor unice (Unique Name Assuption) Prin Ipoteza Numelor Unice se presupune că oricare doi indivizi având nume diferite, sunt diferiţi. In OWL nu se ţine cont de Ipoteza numelor unice, ci există mecanisme specializate ale acestui limbaj ce pot fi folosite pentru a arăta că indivizii sunt diferiţi 32

142 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic (owl:differentfrom şi owl:alldiferent). Totuşi, multi clasificatori care folosesc Description Logic se bazează pe această ipoteză. Spre exemplu, dacă în ontologie este enunţat faptul că Fred are doar un singur prieten şi că este prieten şi cu John şi cu Jack, atunci, prin inferenţă ar trebui să rezulte că John şi Jack trebuie să fie aceeaşi persoană. În cazul clasificatorului RACER (bazat pe DL) această inferenţă nu va fi făcută, raportându-se o inconsistenţă, deoarece acest reasoner foloseşte Ipoteza numelor unice. [BEC02] Editoare OWL Pentru construcţia unei ontologii în OWL au fost create mai multe editoare dintre care amintim: Protégé-OWL, SWOOP, The Manchester OWL Syntax Editor şi Altova SemanticWorks. Protégé este un editor open source pentru ontologii dezvoltat de Centrul pentru Cercetare Informatică în domeniul biomedical de la Universitatea de Medicină din Stanford [PRO08]. Editorul Protégé-OWL este o extensie la Protégé pentru limbajul OWL. SWOOP este un instrument pentru crearea, editarea şi depanarea ontologiilor OWL. A fost produs de către laboratorul MIND al Universităţii din Maryland, College Park iar în acest moment constituie un proiect open source având contribuitori de pretutindeni. [SWO08]. The Manchester OWL Syntax Editor oferă reprezintă un instrument pentru vizualizarea şi editarea descrierilor claselor OWL în Protégé-OWL oferind multiple facilităţi în interfaţa cu utilizatorul (lizibilitate, sublinierea cuvintelor cheie, auto-completare, semnalarea erorilor, generare de sugestii, etc). [MOS05] ALTOVA SemanticWorks include un editor RDF şi OWL pentru proiectarea într-un mod vizual al aplicaţiilor pentru Web Semantic. Acesta permite transformarea automată în cod RDF/XML a documentelor, vocabularelor şi ontologiilor proiectate în modul vizual. 33

143 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic 5 Reprezentarea cunostintelor prin reguli 5.1 OPS5 OPS5 este un limbaj bazat pe reguli, care are ca fundament strategia de calcul generala numita sistem bazat pe reguli sau sistem de productie. OPS reprezinta abrevierea pentru Official Production System si a fost dezvoltat la sfarsitul anilor 1970 de catre Charles Forgy la Universitatea Carnegie Mellon. OPS5 este primul limbaj bazat pe reguli, iar pornind de la acesta s-au dezvoltat celelalte sisteme bazate pe reguli. Componentele unui sistem bazat pe reguli sunt: baza de reguli, o baza de date numita memoria de lucru si un interpretor de reguli ce reprezinta sistemul care ruleaza programul. Interpretorul de reguli unifica datele cu reguli si alege regula care trebuie aplicata. Un sistem bazat pe reguli foloseste inlantuirea inainte sau inlantuirea inapoi a regulilor. Termenii inainte si inapoi se refera la directia de rezolvare a problemei. Un sistem cu inlantuire inainte foloseste regulile pentru ca, pornind de la o multime de date initiala, sa construiasca o concluzie. Un sistem cu inlantuire inapoi incepe cu concluzia dorita si deriveaza reguli evidente pentru acea concluzie. OPS5 este un limbaj bazat pe reguli cu inlantuire inainte, care poate fi folosit pentru rezolvarea problemelor cu inlantuire inainte si inapoi. OPS5 este utilizat pentru domenii in care este dificil de reprezentat o problema sub forma unui algoritm, care necesita expresii simbolice, pentru care exista o baza de cunostinte care creste dinamic sau care este in schimbare, sau in care solutia se exprima in mod natural prin reguli IF-THEN. O problema rezolvata in acest limbaj nu reprezinta, in general, o solutie optima. Diferenta intre OPS5 si majoritatea limbajelor de programare este ca OPS5 nu foloseste instructiuni de control explicite si codeaza starea programului ca fiind multimea intreaga de elemente din baza de date [Coo88]. Memoria de lucru are o structura si instante actuale. Structura este definita prin clase de elemente. Instantele actuale se numesc elementele memoriei de lucru. Baza de reguli este o multime de reguli IF-THEN care au urmatoarea forma: daca o multime de conditii exista in memoria de lucru, atunci se executa o multime de actiuni. Partea IF a regulii sau partea stanga a regulii contine elemente conditionale pozitive sau negate, ce descriu o multime de elemente din memoria de lucru care indeplinesc regula. Partea THEN a regulii sau partea dreapta a regulii consta din actiuni care se executa cand regula a fost aleasa. Partea stanga a regulilor poate folosi variabile, predicate, disjunctii si conjunctii pentru a specifica valorile din elementele memoriei de lucru care unifica cu elementul conditional. Ciclul recunoastere-actiune contine trei etape: identificare, selectie (rezolvarea conflictelor) si actiune. Prima etapa consta in identificarea intra-element intre fiecare element al memoriei de lucru si fiecare element conditional, precum si identificarea inter-element care testeaza daca 34

144 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic aceleasi nume de variabile folosite in diferite elemente conditionale se identifica cu aceleasi valori. Rezolvarea conflictelor alege o instanta din multimea de conflicte, folosind diferite criterii. Daca aceste criterii esueaza in alegerea unei instantieri unice, aceasta se alege arbitrar dintre acelea care sunt recente si specifice. In timpul celei de-a treia etape, actiunile din partea dreapta a regulii sunt executate in ordinea in care au fost scrise. Orice schimbare din memoria de lucru se reflecta imediat in multimea de conflicte. OPS5 furnizeaza o multime de comenzi pe baza carora utilizatorul poate interactiona cu programul si cu ciclul recunoastere-actiune. Interpretorul de comenzi executa aceste comenzi. Din interpretorul de comenzi, se poate initializa memoria de lucru, se poate rula ciclul recunoastere-actiune si se poate alege strategia folosita pentru rezolvarea conflictelor [Coo88]. Mai jos se prezinta un fragment dintr-un sistem bazat pe reguli in OPS5, pentru atribuirea camerelor de camin unor studenti. ;;O camera pentru un grup de studenti (literalize room number type ; Unique room number ; For printout only: ; << SINGLE DOUBLE... >> sexes-are ; Gender of occupants << MALE FEMALE >> smokers? ; Smoking preference << YES NO >> capacity vacancies assignments occupants) ; Maximum number of occupants: integer ; Assignment openings for this room: ; integer ; Number of students already assigned: ; integer (vector-attribute occupants) ; Names of students assigned to this room 5.2 JESS Unul dintre cele mai uzuale sisteme de reguli disponibile pentru utilizare necomerciala este JESS (Java Expert System Shell). JESS este implementat in limbajul Java. A fost dezvoltat pornind de la sistemul expert CLIPS, dar a evoluat intr-un sistem bazat pe reguli complet si distinct. Folosind JESS, se pot scrie applet-uri si aplicatii Java care au capacitatea de a rationa folosind cunostintele furnizate sub forma regulilor declarative. Sistemul JESS este folosit in utilitarele bazate pe Protege. De exemplu SWRLJessTab, SweetJess, JessTab. 35

145 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic JESS este un mediu pentru dezvoltarea unui tip de software inteligent numit sistem expert. Un sistem expert contine o multime de reguli care pot fi aplicate in mod repetat asupra unei multimi de fapte. JESS foloseste un algoritm foarte eficient numit RETE pentru unificarea regulilor cu faptele [Jess02]. Un sistem expert bazat pe algoritmul RETE construieste o retea de noduri, unde fiecare nod, cu exceptia radacinii, corespunde unui sablon care apare in partea stanga a unei reguli. Calea de la nodul radacina pana la un nod frunza defineste complet partea stanga a regulii. Fiecare nod memoreaza faptele care satisfac acel sablon. In momentul cand fapte noi sunt adaugate sau modificate, acestea se propaga de-a lungul retelei, adnotand nodurile cand faptul unifica cu acel sablon. Cand un fapt sau o combinatie de fapte face ca toate sabloanele pentru o anumita regula sa fie indeplinite, se ajunge la un nod frunza si regula respectiva este executata. Exista trei modalitati pentru reprezentarea cunostintelor in JESS: reguli, care sunt in principal utilizate pentru cunostinte euristice bazate pe experienta; functii, care sunt utilizate in principal pentru cunostinte procedurale; programare orientata pe obiecte, care este de asemenea utilizata in principal pentru cunostinte procedurale. Cele cinci caracteristici general acceptate ale programarii orientate pe obiecte sunt recunoscute: clasele, abstractizarea, incapsularea, mostenirea, polimorfismul. JESS este un sistem expert, deoarece este un mediu complet pentru dezvoltarea sistemelor expert, ce include caracteristici cum ar fi un editor integrat si un instrument de depanare. JESS ofera elementele de baza ale unui sistem expert: lista de fapte si lista de instante memoria globala pentru date; baza de cunostinte contine toate regulile, baza de reguli; motorul de inferenta controleaza executia regulilor. Un program scris in JESS poate contine reguli, fapte si obiecte. Motorul de inferenta hotaraste ce reguli trebuie sa fie executate si cand trebuie ele executate. Un sistem expert bazat pe reguli, scris in JESS este un program condus de date in care faptele si obiectele reprezinta datele care genereaza executia, folosind motorul de inferenta. O regula este similara unei instructiuni if-then dintr-un limbaj procedural. O regula ifthen poate fi exprimata astfel: daca anumite conditii sunt adevarate, atunci se executa actiunile. O parte a regulilor dintr-un sistem expert pentru miscarea unui robot, in functie de culorile semaforului, sunt prezentate mai jos: (defrule red-light ) (light red) => (printout t Stop crlf) (defrule green-light 36

146 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic ) (light green) => (printout t Go crlf) (defrule take-a-walk ) (status walking) (walk-sign walk) => (printout t Go crlf) JESS executa intodeauna actiunile din partea dreapta a regulii cu cea mai mare prioritate. Dupa aceea, aceasta regula este indepartata si se executa regula urmatoare, in ordinea descrescatoare a prioritatilor. JESS ofera doua modalitati diferite pentru rezolvarea conflictelor: in adancime (LIFO) si in latime (FIFO). In cazul strategiei in adancime se folosesc regulile activate cel mai recent inaintea regulilor activate mai putin recent si care au aceeasi prioritate. In cazul strategiei in latime, regulile cu aceeasi prioritate se aplica in ordinea in care au fost activate. Este greu de hotarat care strategie este mai buna, fara considerarea aplicatiei specifice. Modulele permit partitionarea unei baze de cunostinte. Orice constructie definita trebuie plasata intr-un modul. Programatorul poate controla in mod explicit ce constructii dintr-un modul sunt vizibile altor module, precum si ce constructii din alte module sunt vizibile unui modul. Vizibilitatea faptelor intre module poate fi controlata intr-o maniera similara. Modulele pot fi utilizate de asemenea pentru controlul executiei regulilor. 5.3 RuleML RuleML a aparut pe baza limbajelor de marcaje cu reguli existente si a generat deja alte proiecte bazate pe marcaje cu reguli. Initiativa RuleML a inceput in anul 2000 si a reunit echipe de experti din mai multe tari, incluzand lideri din domeniile reprezentarii cunostintelor si limbaje cu marcaje. Initiativa RuleML dezvolta un limbaj deschis bazat pe reguli XML/RDF. Aceasta va permite schimbul regulilor intre sisteme diferite, incluzand componente software distribuite pe Web, sisteme client-server eterogene care se gasesc in companiile mari. Limbajul RuleML ofera sintaxa XML pentru reguli de reprezentare a cunostintelor interoperabile intre principalele sisteme de reguli comerciale si necomerciale. Un exemplu de regula in RuleML este prezentata mai jos: <rulebase label= myrules > <imp> <_head><atom> <rel>likes</rel> 37

147 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic </imp> </rulebase> <ind>john</ind> <var>x</var> </atom></_head> <_body><atom> <rel>likes</rel> <var>x</var> <ind>pictures</ind> </atom></_body> Limbajul RuleML contine o ierarhie de reguli, pornind de la reguli de reactie (reguli eveniment-conditie-actiune), trecand prin reguli de constrangere a integritatilor (reguli de pastrare a consistentei) si reguli de derivare (reguli de inferenta a implicatiei), pana la fapte (reguli de derivare fara premize) [BTW07]. Ierarhia de reguli RuleML constituie o ordine partiala, al carei prim nivel sunt regulile de reactie. Al doilea nivel principal este constituit din reguli de constrangere a integritatii si din reguli de derivare. Al treilea nivel specializeaza reguli de derivare in fapte. Reguli de reactie Constrangeri de integritate Reguli de derivare Figura 1. Ierarhia de reguli RuleML Un sistem bazat pe reguli RuleML poate fi integrat intr-un model informatic sau baza de reguli poate avea un atribut care specifica contextul sau, referindu-se la documentul XML respectiv. Specificarea RuleML constituie o familie modulara de sub-limbaje Web, ale carei radacini acceseaza limbajul ca un intreg si ale carei membri identifica submultimi ale limbajului care se pot adapta si combina. Fiecare dintre sublimbajele familiei are o definitie XML Schema, o adresa Web identificata printr-un URI, care permite mostenirea intre schemele de sub-limbaje si referinta precisa la expresivitatea ceruta [Bol07]. RuleML se remarca prin reguli de derivare, interogari, constrangeri de integritate, reguli de productie si reactie. Hornlog RuleML adauga expresii functionale sub forma de termeni. In Hornlog cu egalitate astfel de functii neinterpretate sunt complementate de functii interpretate. Ramura de reguli de derivare se extinde in sus spre logica cu predicate de ordinul I si are subramuri pentru: negatia ca esec, negatia puternica sau limbaje combinate [RuleML06]. Fapte 38

148 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic 5.4 SWRL OWL s-a dezvoltat ca un limbaj formal pentru construirea ontologiilor, ce furnizeaza o descriere de nivel inalt a acestor resurse Web. Cercetarile recente s-au concentrat pe adaugarea regulilor la OWL pentru a furniza un nivel aditional de expresivitate. SWRL (Semantic Web Rule Language) este rezultatul acestor cercetari. SWRL permite utilizatorilor sa scrie reguli tip Horn care pot fi exprimate in termenii conceptelor OWL si care pot rationa despre indivizii OWL. Un exemplu simplu de regula SWRL este prezentata mai jos: hasbrother(?x1,?x2) hasage(?x1,?age1) hasage(?x2,?age2) swrlb:greaterthan(?age2,?age1) hasolderbrother(?x1,?x2) SWRL se bazeaza pe o combinatie a sublimbajelor OWL DL si OWL Lite, care fac parte din limbajul de ontologii Web OWL, impreuna cu sublimbajele Datalog RuleML unar si binar ale limbajului de marcaje cu reguli. SWRL include o sintaxa abstracta de nivel inalt pentru reguli de tip Horn in ambele sublimbaje OWL DL si OWL Lite ale limbajului OWL [CTNDM06]. SWRLTab este un mediu de dezvoltare pentru lucrul cu reguli SWRL in Protege-OWL. Acesta permite editarea si executarea regulilor SWRL. De asemenea, furnizeaza mecanisme ce permit interoperabilitatea cu o multime de motoare de reguli si incorporarea bibliotecilor de metode definite de utilizator care pot fi folosite in reguli. Mai multe biblioteci predefinite sunt furnizate, ce includ multimi de operatori matematici, operatori pentru siruri si operatori temporali, in plus fata de operatorii care pot fi folositi pentru a transforma efectiv SWRL intrun limbaj de interogari. Acest limbaj furnizeaza o posibilitate de extragere a informatiei din ontologiile OWL. SWRLTab furnizeaza o multime de API care permite construirea uneltelor ce lucreaza cu reguli SWRL. Acesta are mai multe componente software ce includ: un editor care permite crearea, editarea, citirea si scrierea regulilor SWRL in mod interactiv; un motor de reguli care ofera infrastructura necesara pentru a interactiona cu alte motoare de reguli; o cale predefinita care ofera un mecanism pentru definirea implimentarilor Java pentru regulile predefinite SWRL; o multime de biblioteci predefinite continand operatori matematici, operatori pentru siruri, operatori temporali, ABox si TBox. Editorul SWRL este o extensie la Protege-OWL, care permite editarea interactiva a regulilor SWRL. Utilizatorii pot crea, edita, citi si scrie reguli SWRL. Cu exceptia expresiilor OWL arbitrare, acest editor permite intreaga multime de caracteristici ale limbajului SWRL. Este integrat cu Protege-OWL si este accesibil din acesta. In momentul editarii regulilor, utilizatorii se pot referi direct la clasele OWL, proprietatile si indivizii dintr-o ontologie OWL. De asemenea, utilizatorii au acces direct la toate tipurile de date XML Schema [SWRL04]. Importarea datelor din bazele de date relationale in ontologii este ceruta in mod frecvent, in special cand o ontologie se foloseste pentru a descrie semantic datele utilizate de 39

149 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic o aplicatie software. O alta categorie de aplicatii necesita integrarea si introperabilitatea intre baza de date si ontologie, unde este necesara o relatie intre structura schemei bazei de date si conceptele ontologiei. SWRL intentioneaza sa fie limbajul bazat pe reguli al Web-ului semantic. SWRL se bazeaza pe OWL. Toate regulile sunt exprimate in termenii conceptelor OWL. SWRLTab este o extensie a Protege-OWL care permite crearea si executia regulilor SWRL. Acesta permite inferente cu motorul de reguli JESS. 40

150 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic 6 Inginerie ontologică Ingineria ontologica se ocupa cu studiul metodelor pentru construirea ontologiilor: procesul de dezvoltare a ontologiilor, ciclul de viata al ontologiilor, metodele de construire a ontologiilor, precum limbajele de descriere a acestora si tool-urile de editare. Ingineria ontologica consta dintr-o multime de task-uri pentru dezvoltarea ontologiilor pentru un anumit domeniu, dar totodata ofera si o modalitate de rezolvare a problemelor de interoperabilitate provenite datorita obstacolelor semantice (de exemplu, de a corela termeni din domeniul afacerilor cu clase software). 6.1 Construirea ontologiilor In proiectarea ontologiilor trebuie sa se tina cont de cateva reguli: nu exista un mod corect de modelare a unui domeniu exista intotdeauna alternative viabile. Cea mai buna solutie depinde aproape intotdeauna de aplicatia pe care o avem in minte si completarile pe care la anticipam; dezvoltarea unei ontologii este un proces iterativ; conceptele unei ontologii trebuie sa fie apropiate de obiectele (fizice sau logice) si relatiile din domeniul de interes. Ontologiile pot fi construite in diferite moduri: manual; prin refolosirea ontologiilor existente; folosind metode semiautomate; Constructia manuala a ontologiilor Constructia manuala a unei ontologii presupune trecerea prin mai multe etape, etape ce vor fi descrise in continuare ca in [NM01]. Determinarea domeniului si a scopului ontologiei Mai intai trebuie definit domeniul ontologiei precum si scopul ei. Pentru aceasta se poate raspunde la cateva intrebari de baza: Care este domeniul pe care il va acoperi ontologia? La ce va fi folosita ontologia? La ce tipuri de intrebari va furniza raspunsuri informatia din ontologie? Cine va folosi si va intretine ontologia? Raspunsurile la aceste intrebari se pot schimba pe parcursul proiectarii ontologiei dar la orice moment de timp ele vor ajuta la definirea si limitarea scopului modelarii. In continuare se considera dezvoltarea unei ontologii ce va sugera combinatiile bune de vin si mancare. In ontologie vor exista conceptele ce descriu diferitele tipuri de vinuri, tipurile principale de mancare, notiunea de combinatie buna de vin si mancare si notiunea de combinatie proasta. In schimb ontologia nu va contine concepte pentru gestiunea inventarului dintr-o fabrica de vinuri sau angajatii dintr-un restaurant chiar daca aceste concepte sunt cumva legate de notiunile de vin si mancare. 41

151 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Daca ontologia ce este preiectata va fi utilizata pentru a asista procesarea bazata pe limbaj a articolelor dintr-un magazin de vinuri poate fi importanta, de asemenea, includerea sinonimelor si a informatiilor legate de vorbire pentru conceptele din ontologie. Daca ontologia va fi utilizata pentru a ajuta un client al unui restaurant sa comande un vin, va trebui sa includem informatii legate de pret. Daca este utilizata de cumparatorii de vinuri, pretul de vanzare si disponibilitatea sunt necesare, iar daca cei care intretin ontologia descriu ontologia intr-un limbaj care este diferit de cel al utilizatorilor ei va trebui sa furnizam si maparea dintre limbaje. O modalitate de a determina scopul unei ontologii este de a face o lista de intrebari [GRF95], la care aplicatia bazata pe ontologia respectiva sa poata raspunde. In domeniul vinului si al mancarii, pot fi puse urmatoarele intrebari de competenta: Ce caracteristici sa iau in calcul cand aleg un vin? Este Bordeaux vin rosu sau vin alb? Vinul Cabernet Sauvignon merge bine cu carnea de miel? Care este cea mai buna alegere de vin pentru carnea fripta? Ce caracteristici ale unui vin duc la o proasta combinatie cu un fel de mancare? Se schimba buchetul sau taria unui vin in functie de anul in care a fost cules? Care sunt perioadele bune de cules pentru Napa Zinfandel? Pe baza acestor intrebari, ontologia va include informatii despre diferite caracteristici ale vinurilor, diferite tipuri de vinuri, anii in care a fost imbuteliat vinul buni si slabi clasificarea mancarii care conteaza pentru alegerea unui vin adecvat, combinatiile recomandate de vin si mancare. Considerarea ontologiilor deja existente Intotdeauna trebuie avut in vedere ceea ce exista deja realizat si trebuie verificat daca se pot rafina si extinde sursele existente pentru un domeniu particular. Reutilizarea ontologiilor deja existente poate fi o necesitate daca sistemul ce urmeaza a fi construit trebuie sa interactioneze cu alte aplicatii care utilizeaza deja o anumita ontologie. Enumerarea termenilor importanti in ontologie In acest scop este utila alcatuirea unei liste cuprinzand toti termenii pentru care se doresc sa fie facute anumite declaratii fie sa fie explicati unor utilizatori: Care sunt termenii despre care dorim sa discutam? Care sunt proprietatile pe care le au acestia? Ce dorim sa spunem despre acesti termeni? Initial este important de obtinut o lista cuprinzatoare de termeni fara teama de suprapunere a conceptelor pe care acestia le reprezinta, relatiile dintre ei sau orice proprietati pe care le poate avea conceptul. Implementarea ontologiei si popularea acesteia In acest pas se dezvoltarea ierarhia de clase si definirea proprietatilor conceptelor (atributelor). Astfel conceptele sunt reprezentate in cadrul unui limbaj formal. 42

152 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Documentarea In aceasta etapa se prezinta definitiile formale si informale, presupunerile facute si exemple care sunt esentiale in vedereea folosirii ontologiei sau refolosirea ulterioara a acesteia. Documentatia are drept scop definirea mai exacta (decat este realizata in cadrul ontologiei) pentru intelesul termenilor existenti in ontologie. Evaluarea In aceasta etapa se determina exactitatea ontologiei pentru scopul in care a fost proiectata. Evaluation se realizeaza pentru a determina daca ontologia satisface cerintele pentru care a fost proiectata, incluzand determinarea consistentei, daca este completa s nu exista redundanta in definirea ontologiei Reutilizarea ontologiilor existente Este greu de proiectat o ontologie de la inceput. Astfel este bine sa se tina cont de ontologiile deja construite. Dintre ontologiile existente amintim: ontologii in domeniul medical: ontologia in domeniul oncologic (National Cancer Institute in the United States) ontologii in domeniul cultural: Art and Architecture Thesaurus (contine 125,000 termeni din domaniul cultural); Union List of Artist Names (contine 220,000 de intrari); Iconclass (contine 28,000 termeni pentru descrierea imaginilor culturale); ontologii in domeniul geografic: Getty Thesaurus of Geographic Names (TGN) Pe baza ontologiilor deja existente pot fi create noi onologii prin: unificarea vocabularelor existente din acelasi domeniu intr-o singura resursa: Unified Medical Language System contine 100 vocabulare din domeniul medical (contine 750,000 concepte, cu peste 10 milioane de legaturi intre ele); unificarea vocabularelor din domenii diferite: Cyc, (60,000 asertiuni si 6,000 concepte) Standard Upperlevel Ontology Folosirea metodelor semiautomate Achizitia manuala a informatiilor in vederea construirii unei ontologii este un proces costisitor si mare consumator de timp. Pentru inlaturarea acestor aspecte se folosesc tehnici bazate pe invatare pentru: achizitia sau extragerea cunostintelor; intretinerea sau revizuirea cunostintelor; extragerea ontologiilor, a datelor relationale si a metadatelor din datele existente pe Web; unificarea si maparea ontologiilor prin analiza extinderilor pentru concepte; intretinerea ontologiilor prin analiza instantelor datelor. 43

153 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic 6.2 Implementarea ontologiilor Exista cateva abordari posibile in ceea ce priveste dezvoltarea unei ierarhii de clase [UGR96]: Un proces de dezvoltare top-down incepe cu definirea conceptelor generale despre domeniul respectiv urmatǎ de diferentierea ulterioarǎ a conceptelor. De exemplu, se creeaza clasele pentru conceptele generale (Wine si Food). Apoi se defineste clasa Wine prin crearea unor subclase ale sale: White wine, Red wine, Rosé wine. Mai departe poate fi clasificata clasa Red wine in Syrah, Red Burgundy, Cabernet Sauvignon etc. Un proces de dezvoltare bottom-up incepe cu definirea celor mai specializate clase, frunzele ierarhiei, urmata de gruparea acestora in concepte mai generale. De exemplu, se porneste de la definirea claselor pentru vinurile Pauillac si Margaux. Apoi se creeazaa o superclasa a acestor doua clase, Medoc, care la randul ei va fi o subclasa a clasei Bordeaux. Un proces de dezvoltare combinat este o combinatie a abordarilor top-down si bottom-up: se definesc mai intai conceptele fundamentale si apoi ele sunt generalizate si specializate corespunzator. De exemplu, se poate incepe cu cateva concepte importante (cum ar fi cel de Wine) si cateva concepte specifice (ca Margaux), care apoi pot fi relationate cu un concept de nivel intermediar, de exemplu Medoc. Dupa care se pot genera clasele pentru toate vinurile regionale din Franta, astfel generand un numar de concepte de nivel mediu. Niciuna din aceste trei metode nu este mai bunǎ decat celelalte. Abordarea aleasa depinde mult de perspectiva personalǎ asupra domeniului. Abordarea combinata este adesea cea mai usoara pentru multi proiectanti de ontologii, deoarece conceptele intermediare tind a fi cele mai descriptive concepte din domeniu [ROS78]. Definirea claselor si a ierarhiei de clase Dezvoltarea unei ontologii include: definirea claselor din ontologie; aranjarea claselor intr-o ierarhie taxonomica (subclasa superclasa); definirea atributelor si descrierea valorilor permise pentru acestea; completarea valorilor pentru atribute si instante. Clasele sunt cele mai importante componente ale celor mai multe ontologii. Ele descriu conceptele dintr-un domeniu. De exemplu, o clasa de vinuri (de exemplu, Wine) reprezinta toate vinurile. O clasa poate avea subclase care reprezinta concepte ce sunt mai specifice decat superclasele. De exemplu, putem imparti clasa tuturor tipurilor de vin in vin rosu, vin alb si vin roz. Sau o putem imparti in vinuri dulci si vinuri seci. Atributele descriu proprietatile claselor si instantelor: vinul Chateau Lafite Rothschild Pauillac este un vin tare; este produs de podgoria Chateau Lafite Rothschild. Sunt doua atribute ce descriu vinul in exemplul nostru: un atribut body cu valoarea full si un atribut producer cu valoarea Chateau Lafite Rothschild. La nivel de clasa, putem spune ca instantele clasei Wine vor avea atribute ce vor descrie aroma, nivelul de zahar, producatorul, etc. Figura 1prezinta o parte din clase, instante si relatiile dintre ele in domeniul vinului (cu negru sunt reprezentate clasele, iar cu rosu instantele, liniile drepte reprezinta atribute si legaturi interne). 44

154 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Figura 1. Exemplificare clase, instante si relatiile dintre aceste in domeniul vinului Clasele singure nu pot furniza suficiente informatii. Odata ce au fost definite clasele, trebuie descrisa structura interna a conceptelor. In general existǎ cateva tipuri de proprietati ale obiectelor care pot deveni atribute intr-o ontologie: proprietati intrinsece (de exemplu aroma (flavor) unui vin; proprietati extrinsece (de exemplu numele (name) sau zona (area) din care provine un vin); componente, daca obiectul este structurat; acestea pot fi atat componente fizice cat si abstracte (de exemplu mesele unei zile); relatii cu alti indivizi; acestea sunt legaturi intre membri individuali ai clasei cu alte elemente (fabricantul (maker) unui vin, reprezentand relatia dintre un vin si o cramǎ, si strugurele din care este fǎcut vinul). Toate subclasele unei clase mostenesc atributele acesteia. Un atribut trebuie asociat celei mai generale clase care poate avea proprietatea respectivǎ. Atributele pot avea diferite proprietati care descriu tipul de date, valorile permise, numarul de valori (cardinalitatea) si alte caracteristici ale valorilor pe care le poate lua un atribut. De exemplu, valoarea unui atribut name (cu semnificatia de numele unui vin ) este un sir de caractere. Asta inseamna cǎ name este un atribut cu tipul de date String. Un atribut produces (cu semnificatia crama produce aceste vinuri ) poate avea valori multiple, iar valorile sunt instante ale clasei Wine. Cu alte cuvinte, produces este un atribut cu tipul de date Instance a clasei Wine. Principalele proprietati ale atributelor: Cardinalitatea unui atribut - precizeaza numarul de valori pe care le poate avea un atribut. Tipul de date al atributului - descrie tipurile de date din care poate lua valori atributul respectiv. Cele mai utilizate tipuri de date: String (Valoarea este un sir de caractere); Number (Float numar real sau Integer numar intreg) descrie atributele printr-o valoare numericǎ; Boolean - indicatori simpli de tip DA/NU; Enumerare - specifica o lista de valori permise pentru respectivul atribut; 45

155 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Instanta - permit definirea relatiilor dintre entitati. Atributele cu valori de tip Instantǎ trebuie de asemenea sǎ defineasca o listǎ a claselor care pot fi instantiate. Domeniul unui atribut la definirea domeniului de valori pentru un atribut trebuie gasita cea mai generala clasa sau cele mai generale clase care pot fi domeniul atributului respectiv. Atributele pot fi: atribute inverse - valoarea unui atribut poate depinde de valoarea unui alt atribut; valori implicite - multe sisteme permit specificarea de valori implicite pentru atribute.daca valoarea unui atribut este aceeasi pentru majoritatea instantelor clasei, se poate defini acea valoare ca valoare implicita a atributului. La crearea unei noi instante a clasei respective sistemul va completa automat atributul cu valoare lui implicita. Aceasta valoare poate fi schimbata apoi cu alta valoare permisa. Ultimul pas in implementarea unei ontologii il reprezinta crearea instantelor individuale ale claselor din ierarhie. Definirea unei instante individuale a unei clase necesita: alegerea clasei; crearea unei instante individuale a acelei clase; completarea cu valori a atributelor. Ontologia nu trebuie sa contina toate informatiile posibile din domeniu: nu trebuie sa specializam sau sa generalizam mai mult decat este nevoie pentru aplicatia noastra. In mod similar, ontologia nu trebuie sa contina toate proprietatile si diferentele dintre clasele din ierarhie. 6.3 Alinierea ontologiilor Ontologiile de domeniu reprezinta concepte intr-un mod foarte specific, adesea acestea sunt incompatibile pe baza reprezentarii informatiilor existente. Pe masura ce sistemele ce se bazeaza pe ontologii de domeniu se extind, este necesar sa se unifice mai multe ontologii de domeniu intr-o reprezentare mult mai generala. Acest lucru nu constituie un proces foarte usor. Ontologii diferite din acelasi domeniu pot rezulta pe baza perceptiilor diferite ale aceluiasi domeniu in functie de cunostintele culturale, educationale, ideologice sau datorita limbajului de reprezentare diferit ales in reprezentarea ontologiei. Unificarea ontologiilor se poate realiza prin: unificare simpla - ontologia rezultata prin unificarea mai multor ontologii existente (ontologiile existente descriu acelasi domeniu sau domeniice se suprapun); alinierea ontologiilor - ontologiile existente ce se aliniaza raman in continuare, adaugandu-se legaturi intre elementele componente ale ontologiilor initiale. Alinierea ontologiilor se realizeaza in cazul in care ontologiile specifica domenii complementare. Fie doua ontologii o si o', diferitele tipuri de relatii ce pot fi definite intre termenii acestor ontologii poarta numele de aliniere [WKI08a]. Aceste relatii pot fi caracterizate prin diferite dimensiuni: similaritate versus logica: echivalenta logica sau incluziune; 46

156 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic atomic versus complex: alinierea este reprezentata unu la unu sau poate implica mai multi termeni; omogen versus heterogen: elementele ce sunt aliniate sunt de acelasi tip (clasele se inrudesc cu clase, indivizii cu indivizi, etc) sau se permit relatii intre elemente eterogene; tipul alinierii: relatia asociata este de echivalenta, disjunctie, parte a sau orice alt tip de relatie definit de utilizator. Alinierea intre cele doua ontologii o si o' poate fi descrisa ca [ALN08] o multime de corespondente <e, e', r, n> in care: e and e' sunt entitati in cele doua ontologii intre care se asociaza o noua relatie (de exemplu, clase, indivizi, etc); r este relatia asociatainta e si e' (poate fi orice fel de relatie intre cele doua entitati, de exemplu, relatia de echivalenta); n este gradul de similaritate al alinierii (al potrivirii intre elementele intre care s-a realizat corespondenta). Problema alinierii consta in calcularea potrivirilor si apoi maparea (asocierea de noi relatii) inttr-o maniera automata pe baza acestor potriviri calculate. Pentru a compara abordarile existente in alinierea ontologiilor a fost creata o organizatie Ontology Alignment Evaluation Initiative [OAE08] care compara cele mai bune abordari. 6.4 Dezvoltări actuale Medii de dezvoltare In continuare prezentam mai multe medii de dezvoltare pentru OWL, RuleML si SWRL. Protégé ([Protégé]): Protégé este o platforma open-source, free, care ofera comunitatii stiintifice mai multe unelte pentru a construi modele de domenii si aplicatii bazate pe cunostinte folosind ontologii. Protégé suporta doua moduri de a modela ontologii: Protégé- Frames editor care permite utilizatorilor sa creeze si sa populeze ontologii bazate pe frameuri si Protégé-OWL editor care permite utilizatorilor sa construiasca ontologii pentru webul semantic, in special pentru limbajul OWL. SWRLTab ([SWRL Tab]) este o extensie pt Protégé care suporta editarea si executia regulilor SWRL. Taxonomic RuleML Tab ([TX RuleML]) este o extentie pentru Protégé care converteste fisiere RuleML in ierarhii de clase taxonomice si invers; in plus poate fi folosit ca un validator pentru fisierul RuleML, recunoscand si raportand erorile, cum ar fi taguri incorecte sau simboluri nevalide. TopBraid Composer ([TopBraid Composer]) este un mediu pentru dezvoltarea ontologiilor pentru webul semantic si pentru construirea aplicatiilor semantice. Are suport complet pentru OWL si editor pentru SWRL ([Wiki Ontology Editor]). Bossam Rule/OWL Reasoner ([Bossam]) este un motor de inferenta pentru webul semantic. Este un motor de reguli bazat pe RETE cu suport pentru rationamente pentru ontologii OWL, ontologii SWRL si reguli RuleML. Hoolet ([Hoolet]) este o implementare a unui motor de inferenta OWL-DL. Ontologia este tradusa intr-o colectie de axiome (bazate pe semantica OWL) si aceasta colectie de 47

157 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic axiome este data unui demonstrator pt predicate de ordinul I pentru testarea consistentei. Deoarece motorul de inferenta este bazat pe traducerea folosind predicate de ordinul I, este usor de extins implementarea pentru extensii ale OWL, cum ar fi SWRL. Hoolet a fost extins pentru a fi utilizat pentru reguli prin adaugarea unui parser pentru reguli cu sintaxa RDF si prin extinderea translatorului si pentru reguli. Pellet ([Pellet]) este un motor de inferenta OWL-DL bazat pe Java cu support pentru SWRL ([Wiki SWRL]). Pellet suporta in totalitate specificarea initiala OWL DL. OWL 2 este o noua versiune a standardului international produsa de catre W3C pentru ontologii webfriendly. Pellet suporta in acest moment majoritatea facilitatilor propuse de OWL 2. KAON2 ([KAON2]) este o infrastructura pentru lucrul cu ontologii OWL-DL, SWRL si F-Logic. KAON2 este un urmas al proiectului KAON (uneori numit si KAON1). Principala diferenta dintre cele doua proiecte este limbajul pentru ontologii acceptat: KAON folosea o varianta de RDFS, in timp ce KAON2 este bazat pe OWL-DL si F-Logic. Cu toate acestea, KAON2 este un sistem complet nou, necompatibil cu KAON. RACER este abrevierea pentru Renamed ABox and Concept Expression Reasoner. RacerPro ([RacerPro]) este numele commercial al software-ului. Originile sistemului RacerPro provin din logicile de descriere. RacerPro poate fi utilizat ca un sistem pentru lucrul cu ontologii pentru webul semantic bazate pe OWL (de exemplu, poate fi utilizat ca motor de inferenta pentru editoare de ontologii, cum ar fi Protégé). RacerPro suporta procesarea regulilor descrise folosind o sintaxa bazata pe SWRL ([Wiki SWRL]). In plus, RacerPro poate fi privit si ca mediu de stocare a informatiilor din webul semantic cu un motor de cautare optimizat pentru ca poate fi utilizat pentru mari cantitati de date (definite folosind RDF). De asemenea, RacerPro poate fi folosit pentru logici modale cum ar fi Km Ontologii existente Dintre ontologiile existente amintim: Cell Cycle Ontology (CCO) [CCO08] care extinde ontologiile existente pentru cunostintele legate de ciclul celulei. CCO integreaza si gestioneaza cunostintele despre componentele si aspectele obisnuite ale ciclului celulei in OBO, OWL, RDF. Aceste cunostinte folosesc resurse deja existente (GO, UniProt, IntAct, GOA, NCBI taxonomy, and so forth), iar prin combinarea acestor cunostinte se furnizeaza o imagine a procesului de diviziune a celulei. Acest nou model al ciclului celului, intr-o mai buna reprezentare, nu este obtinut numai prin combinarea informatiilor existente deja, ci si prin folosirea Ontology Design Patterns aplicata in OWL. Customer Complaint Ontology (Ccontology) [CON08] ontologie ce a fost dezvoltata in scopul suportarii managementului online compatibil cu utilizatorul. In acest scop a fost dezvoltat un portal, in care fiecare utilizator putea inregistra o plangere impotriva unei parti, referitor la orice problema, in 11 limbaje. Ontologia este construita pentru reprezentarea problemelor cumulate pe acest portal: clasificarea plangerilor, clasificarea rezolvarilor plangerilor depuse, reclamantii, reclamatii, cele mai bune practici. Aceasta ontologie este o ontologie domeniu ce contine baza pentru elementele de plangere, ce pot fi extinse de orice companie sau grup de companii. 48

158 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic OpenCyc [OPC08] este versiunea open-source pentru tehnologia Cyc [CYC08], cea mai larga si completa baza de cunstinte si motor de rationament. OpenCyc include: ontologia Cyc ce contine sute de mii de termeni si milioane de asertiuni, pe baza carora se inrudesc termenii intre ei, formand o ontologie de nivel a carui domeniu este reprezentat de intreg consensul realitatii umane; siruri in engleza ce corespund tuturor conceptelor, folosite la cautare si afisare; versiunea completa pentru Cyc Inference Engine and the Cyc Knowledge Base Browser; documentatie pentru o buna intelegere a reprezentarii cunostintelor si a dezvoltarii aplicatiilor folosind Cyc; specificarea limbajului CycL, limbajul in care sunt scrise ata Cyc cat si OpenCyc; specificatia API-ului Cyc pentru dezvoltarea aplicatiilor; legaturi intre conceptele Cyc si synset -urile WordNet. OpenCyc poate fi folosit ca baza intr-o serie de aplicatii, cum ar fi: dezvoltarea rapida a unei ontologii; prioritizarea, rutarea, sumarizarea si anotarea -urilor; sisteme expert; jocuri. WordNet [WON08] este un lexicon semantic pentru limba engleza. El gupeaza cuvintele in mutimi de sinonime numite synsets, care reprezinta odefinitie scurta si generala. Totodata sunt referite relatiite semantice dintre aceste multimi de sinonime. Scopul acestei ontoloii este de a produce o combinatie intre un dictionar si un tezaur de cuvinte care sa fie mai intuitiv de folosit si totodata de a suporta analiza automata a textului. Substantivele, verbele, adjectivele si adverbele sunt grupate in multimi de sinonime synsets, fiecare exprimand un concept distinct. Synsets-urile sunt inlantuite cu ajutorul lexicale si semantice conceptuale. Reteaua rezultata ce contine cuvinte si concepte cu intelesuri inrudite reprezinta o unealta folositoare pentru lingvistica computationala precum si pentru prelucrarea limbajului natural. Gene ontology [GEO08] furnizeaza un vocabular pentru descrierea genelor si a atributelor acestora in orice organism. Acesta este compus din 3 ontologii ce descrie produsele de gene in termeni de procese biologice asociate, componente celulare si functii moleculare independenta de specii. In scopul realizarii acestor ontologii a trebui sa se aiba in vedere: (i) dezvoltarea si intretinerea ontologiilor, (ii) adnotarea produselor de gene pe baza carora se fac asocieri intre gene, produse de gene si bazele de date colaborative, (iii) dezvoltarea de unelte care sa faciliteze crearea, intretinerea si folosirea ontologiilor. Folosirea bazelor de date colaborative faciliteaza interogarea uniforma a acestora. Ontologiile pot fi interogate la diferite niveluri, in functie de nivelul de cunoastere al entitatii respective. Gellish English Dictionary [GEL08] (numita si STEPlib) este un dictionar electronic ce contine definitii pentru concepte, fiecare dintre acestea fiind identificat de un identificator unic (un numar alocat de gestionarul limbajului) care pot fi referite prin unul sau mai multe nume, ce reprezinta termeni in engleza existenti in orice dictionar. Toate definitiile nu au doar asociate o descriere textuala, ci si cel putin o relatie explicita cu conceptul (sau conceptele) superioare corespunzatoare. Astfel este formata o ierarhie consistenta de concepte. Pornind de la modelul acestui dictionar pot 49

159 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic fi construite dictionare specializate pentru anumite domenii sau dictionare in alte limbi. Plant Ontology (PO) [PLO08] reprezinta o ontologie care sa descrie structura plantelor si etapele de crestere ale acestora cu legaturi intre diferite specii. Cancer ontology [CAO08] Ontologia cuprinde informatii despre boli, medicamente, substante chimice, diagnostice, tratamente, anatomie, organisme si proteine. Enterprise ontology [ENO08]reprezinta o colectie de termeni si definitii din domeniul firmelor. Exista o serie de ontologii existente ce ofera si facilitati de cautare. Dintre acestea amintim: DAML Ontology Library [DAM08] cuprinde o serie de ontologii DAML. Protege Ontology Library [PRO08] contine o multime de ontologii OWL sau in alte formate. SchemaWeb [SCW08] este un director de informatii reprezentate in RDFS, OWL si DAML+OIL Proiecte si standarde Dintre proiectele existente amintim: Ontology Metada Vocabulary [OMV08] - Majoritatea ontologiilor existente sunt definite intr-o forma pura fara a avea asociate informatii aditionale. Acest proiect isi propune sa creeze un standard de metadate. American President Ontology [APO08] - ontologia despre presedintii americani, ilustrand modul in care aspectele temporale pot fi modelate intr-o ontologie. Ontologia modeleaza perioadele de guvernare ale presedintilor americani, titlurile academice ale acestora, evenimente, cum ar fi razboaie, scandaluri, etc ce au avut loc in timpul presidentiei fiecaruia. Text2Onto [T2O08] este succesorul TextToOnto [TTO08], care reprezinta un cadru de invatare a ontologiei dintr-un text (achizitia de informatii prin tehnici automate). Un alt proiect similar LexO (Learning Expressive Ontologies) [LEO08] ce transforma definitii din limbaj natural in axiome OWL DL. NeOn [NEO08] folosirea ontologiilor in aplicatii semantice pe scara larga, in organizatii distribuite. Ontologii pentru SOA [SOA08] faciliteaza alinierea intre comunitatile din domeniul afacerilor si cel al tehnologiei informatiilor. Acest proiect: defineste conceptele, terminologia si semantica SOA atat in termeni de afaceri cat si in termeni tehnici, in scopul de a: crea o baza pentru lucrul intr-o zona specifica domeniului; da posibilitatea comunicarii intre oamenii de afaceri si cei din domeniul ethnic; da posibilitatea intelegerii conceptelor SOA in comunitatile de afaceri si in cele tehnice; contribuie la implementarea bazata pe SOA, care va facilita adoptarea SOA. 50

160 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Proiectul va furniza ontologii formale ce va contine definitiile conceptelor SOA si a relatiilor dintre acestea. Dintre standardele existente amintim: Standard Upper Ontology(SUO) [SUO08] Suggested Upper Merged Ontology (SUMO) este o ontologie de nivel ce a fost propusa ca un document de pornire pentru The Standard Upper Ontology Working Group, un grup IEEEsanctioned ce cuprinde cercetatori din domeniul ingineriei, filosofiei si stiintei informatice. SUMO furnizeaza definitii pentru termeni in sens general si are rolul de a furniza diferite ontologii de domeniu. Ontologia reprezinta un standard deschis ce poate fi folosita gratis atat in scopuri academece cat si comerciale, permitand adaugarea de ontologii de domeniu suplimentare. Principalul scop al acestui standard a fost sa poata fi folosit in inferente automate, interoperabilitate semantica intre sisteme de heterogene de informatii si aplicatii de prelucrare a limbajului natural. 6.5 Concluzii Exista mai multe medii de dezvoltare pentru OWL, RuleML si SWRL. Mediul care ofera cele mai multe facilitati este Protégé, el oferind suport pentru toate cele 3 limbaje. Cele mai multe dintre mediile prezentate mai sus, ofera suport pentru OWL. Unele medii reprezinta doar motoare de inferenta (Bossam Rule/OWL Reasoner, Hoolet, Pellet). Astfel de motoare de inferenta pot fi utilizate in conjunctie cu medii mai complexe pentru construirea aplicatiilor. De exemplu, Pellet poate fi folosit impreuna cu Protégé pentru crearea de aplicatii bazate pe OWL. 51

161 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic Bibliografie [ALN08] accesat 2008 [APO08] accesat 2008 [BRJ97]G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language user guide: Addison-Wesley, [CAO08] accesat 2008 [CCO08] accesat 08 [CON08] accesat 2008 [CYC08] accesat 2008 [DTD08] accesat 2008 [DAO08] accesat 2008 [DAM08] accesat 2008 [DC08] accesat 2008 [ENO08] accesat 2008 [GEL08] accesat 2008 [GEO08] accesat 2008 [GRF95] M. Gruninger, M.S. Fox. Methodology for the Design and Evaluation of Ontologies, Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing, IJCAI-95, Montreal, [GRU95] T. R. Gruber, T. R., Toward Principles for the Design of Ontologies Used for Knowledge Sharing, International Journal Human-Computer Studies, Italia, Vol. 43, 1995, pp [GRU08] accesat 2008 [JEN08] accesat 2008 [KIF08] accesat 2008 [LEO08] accesat 2008 [MIC00] R.S. Michalski, Learnable Evolution Model: Evolutionary processes guided by machine learning, Special issue on multistrategy learning, Volum 38, 2000, pp [MFR00] D.L.McGuinness, R. Fikes, J. Rice, S. Wilder. An Environment for Merging and Testing Large Ontologies. Principles of Knowledge Representation and Reasoning, Proceedings of the Seventh International Conference (KR2000), San Francisco, CA, Morgan Kaufmann Publishers, [NEO08] accesat 2008 [NM01] N. F. Noy, D. L. McGuinness, Ontology Development 101: A Guide to Creating Your First Ontology, Stanford Knowledge Systems Laboratory Technical Report KSL and Stanford Medical Informatics Technical Report SMI , Martie

162 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic [OAE08] accesat 2008 [OMV08] accesat 2008 [ONT08] accesat 2008 [OPC08] accesat 2008 [OWL08] accesat 2008 [PLO08] accesat 2008 [PRO08] accesat 2008 [RBP91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. Object-oriented modeling and design, Englewood Cliffs, New Jersey: Prentice Hall, [RDF08] accesat 2008 [ROS78] E. Rosch, Principles of Categorization. Cognition and Categorization. R. E. and B. B. Lloyd, editors. Hillside, NJ, Lawrence Erlbaum Publishers, 1978, pp [SOA08] accesat 2008 [SCW08] accesat 2008 [SHO08] accesat 2008 [SUO08] accesat 2008 [T2O08] accesat 2008 [TTO08] accesat 2008 [UGR96] M. Uschold, M. Gruninger. Ontologies: Principles, Methods and Applications, Knowledge Engineering Review, [XDB08] accesat 2008 [XML08] accesat 2008 [XSD08] accesat 2008 [W3C08] accesat 2008 [WON08] accesat 2008 [WKI08a] accesat 2008 [SJR07] A.B. Smith, C.D. Jones, and E.F. Roberts, Article Title, Journal, Publisher, Location, Date 2007, pp [Jon07] C.D.Jones. Book Title, Publisher, Location, Date. [NB] D. Nardi, R.J. Brachman, An Introduction to Description Logics [BN] F. Baader, W. Nutt, Basic Description Logics 53

163 SCIPA - Studiul şi evaluarea standardelor actuale în reprezentarea cunoştinţelor pentru Web semantic [BHS05] F. Baader, I. Horrocks, and U. Sattler, Description Logics as Ontology Languages for the Semantic Web. In Dieter Hutter and Werner Stephan, editors, Mechanizing Mathematical Reasoning: Essays in Honor of Jörg Siekmann on the Occasion of His 60th Birthday, no in Lecture Notes in Artificial Intelligence, pp , Springer, [BS01] F. Baader, U. Sattler, An Overview of Tableau Algorithms for Description Logics, Studia Logica, vol. 69, no. 1, pp. 5-40, Springer, 2001 [CGLN99] D. Calvanese, G. De Giacomo, M. Lenzerini, and D. Nardi, Reasoning in Expressive Description Logics. In A. Robinson and A. Voronkov, editors, Handbook of Automated Reasoning, chapter 12, Elsevier Science Publishers (North-Holland), Amsterdam, 1999 [STA05] OWL Tutorial Final Stanislav Pokraev & Rogier Brussee, Telematica Instituut, 2005 [BEC02] OWL and Inference: Practical examples - Sean Bechhofer [HPH03] From SHIQ and RDF to OWL: The Making of a Web Ontology Language - Ian Horrocks, Peter F. Patel-Schneider and Frank van Harmelen [OWL07] accesat 2008 [DRU05] Introduction to Ontologies - Nick Drummond [REC04] A Practical Introduction to Ontologies & OWL The University of Manchester [KHM05] The Protégé OWL Experience Holger Knublauch, Matthew Horridge, Mark Musen, Alan Rector [GRI05] Closed World Reasoning in the Semantic Web through Epistemic Operators Stephan Grimm and Boris Motik [HAA05] An Introduction to the Ontology Web Language (OWL) Volker Haarslev [TSA06] FaCT++ Description Logic Reasoner: System Description Dmitry Tsarkov and Ian Horrocks [PRE08] accesat 2008 [KRO07] KAON2 - Practical Reasoning with OWL and Rules - Markus Krötzsch [NEO07] The NeOn Toolkit www. Neon-toolkit.org accesat 2008 [FAC08] accesat 2008 [PRO08] accesat 2008 [SWO08] accesat 2008 [MOS05] accesat

164 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business SCIPA Servicii software semantice de Colaborare şi Interoperabilitate pentru realizarea Proceselor Adaptive de business Standarde actuale în limbajele de modelare a proceselor de business Viorel Negru, Dana Petcu, Alexandru Cicortaş, Florin-Teodor Fortiş, Daniel Pop Universitatea de Vest Timişoara Universitatea de Vest Timişoara, Bd. V. Pârvan, nr. 4, Timişoara , România {vnegru, petcu, cico, fortis, danielpop}@info.uvt.ro Pagina Web:

165 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Rezumat Pentru a modela, specifica şi executa workflow-uri într-o platformă integrată este necesară analiza tehnologiilor existente. Domeniul tehnologiilor workflow este unul foarte dinamic şi în continuă evoluţie, ce conţine numeroase tehnologii disponibile. Au fost analizate şi evaluate cele mai semnificative dintre aceste tehnologii pentru a putea selecta pe cea mai potrivită pentru necesităţile proiectului SCIPA. Rezultatele acestei analize sunt prezentate în prezentul document. Primul capitol prezintă un sinteză a celor mai importante organizaţii şi structuri de standadizare din domeniu, cu tehnologiile şi standardele workflow pe care acestea le dezvoltă, astfel încăt cititorii pot obţine o înţelegere globală asupra organizaţiilor active şi a diverselor direcţii. În continuare sunt evaluate cele mai semnificative tehnologii, fiecare într-o secţiune distinctă urmărind un şablon prestabilit. La început, sunt prezentate informaţii generale despre tehnologie şi poziţia acesteia pe piaţă. Cele mai importante concepte tehnice ale tehnologiei sunt prezentate în continuare pentru a ilustra cât mai bine posibilităţile şi limitările fiecăarei tehnologii. În final, este oferit un rezumat al avantajelor şi dezavantajelor tehnologiei respective, precum şi o recomandare cu privire la utilizarea tehnologiei în cadrul proiectului SCIPA. Documentul acesta îşi propune să ofere unele intuiţii asupra numeroaselor standarde şi tehnologii workflow existente, în special asupra celor ce par să fie promiţătoare. Analizele făcute sunt organizate în patru capitole principale: primul prezintă metodologiile de modelare şi standardele pentru notaţiile grafice, urmat de limbajele de coregrafie şi orchestrare. Ultimul capitol prezintă alte standarde relevante pentru acest proiect. Acest document poate fi privit ca un document de referinţă, şi nu unul care trebuie lecturat de la un capăt la altul. Documentul a fost astfel structurat încât să permită cititorilor să regăsească cu uşurinţă informaţia de care au nevoie în complexitatea tehnologiilor legate de workflow-uri. Secţiunea bibliografică conţine numeroase intrări care să permită cititorilor interesaţi să urmeze detaliile de care au nevoie. 2

166 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business CUPRINS 1 Organizaţii şi structuri de standardizare OASIS Standarde suportate Business Process Management Initiative (BPMI) Standarde suportate Object Management Group (OMG) Standarde suportate World Wide Web Consortium (W3C) Standarde suportate Workflow Management Coalition (WfMC) Supported StandardsStandarde suportate RosettaNet Open Applications Group (OAGi) Limbaje de modelare şi notaţii grafice Unified Modeling Language (UML) Criterii de piaţă Criterii tehnice Aplicabilitate Rezumat Notaţia de modelare a proceselor de afaceri (BPMN) Criterii de piaţă Criterii tehnice Aplicabilitate Rezumat Concluzii Limbaje de coregrafie Orchestrare versus coregrafie Interfaţa comportamentală WS-CDL Concluzii Detalii coregrafie SOA Limbaje de orchestrare Web Services Business Process Execution Language (WSBPEL) Criterii de piaţă Criterii tehnice Aplicabilitate Rezumat XML Process Definition Language (XPDL) Criterii de piaţă Criterii tehnice Aplicabilitate Rezumat ebxml Collaboration Protocol Profile and Agreement (CPPA) Criterii de piaţă Criterii tehnice Aplicabilitate

167 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Rezumat Concluzii Alte standarde asociate tehnologiilor orientate spre fluxuri de activităţi Business Transaction Protocol (BTP) Criterii de piaţă Criterii tehnice Aplicabilitate Rezumat XML Based Protocol for Run-Time Integration of Process Engines (Wf-XML) Criterii de piaţă Criterii tehnice Aplicabilitate Rezumat Universal Business Language (UBL) Criterii de piaţă Criterii tehnice Aplicabilitate Rezumat Asynchronous Service Access Protocol (ASAP) Criterii tehnice Aplicabilitate Rezumat ebxml Messaging Service (ebms) Concluzii Bibliografie

168 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business LISTA DE TABELE Tabela 1 Criteriile de piaţă utilizate la evaluarea standardelor de orchestrare Tabela 2 Criteriile tehnice utilizate la evaluarea standardelor de orchestrare Tabela 3 Criterii de piaţă BPEL4WS / WSBPEL Tabela 4 Criterii tehnice BPEL4WS / WSBPEL Tabela 5 Criterii de piaţă XPDL Tabela 6 Criterii tehnice XPDL Tabela 7 Criterii de piaţă CPPA Tabela 8 Criterii tehnice CPPA Tabela 9 Sinteza analizei de piaţă pentru evaluarea standardelor de orchestrare Tabela 10 Sinteza analizei tehnice pentru evaluarea standardelor de orchestrare Tabela 11 Recomandări finale

169 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business LISTA DE FIGURI Figura 1 Tipuri de standarde şi relaţiile dintre ele... 7 Figura 2 BPMI.org - stiva de standarde BPM... 9 Figura 3 SEQ, limbajul canonic OAGIS Figura 4 SEQ Reprezantarea grafica a unui BOD Figura 5 Diagramă de activitate Figura 6 Principalele construcţii într-o diagramă de activitate Figura 7 Diagrama unui proces de colaborare de afaceri prin specificaţia BPMN Figura 8 Tipuri de markere care pot fi adăugate la evenimente de bază BPMN Figura 9 Un exemplu de specificaţie BPMN Figura 10 Interfaţa comportamentală pentru o cerere Figura 11 Interfaţa comportamentală pentru o comandă (o poziţie dintr-o comanda) Figura 12 O alternativă pentru interfaţa prezentată în Figura Figura 13 Nivelele WS-CDL Figura 14 Elementele şi structura WS_CDL Figura 15 Activitaţi în WS-CDL Figura 16 Exemplu de interacţiune în WS-CDL Figura 17 Exemplu de tip canal în WS-CDL Figura 18 Coregrafia unui model de proces Figura 19 Procesul de onorare a unei comenzi din perspectiva coregrafiei Figura 20 Exemplu de colaborare RosettaNet Figura 21 Activităţi WSBPEL Figura 22 WfMC Workflow Reference Model Figura 23 Structura CPP şi a specificaţiei procesului în ebxml Registry Figura 24 Vedere generală asupra Collaboration-Protocol Profiles (CPP) Figura 25 Vedere generală Collaboration-Protocol Agreements (CPA) Figura 26 Business Transations cu doi inferiori Figura 27 Tipuri de resurse ale unui serviciu web asincron şi metodele utilizate

170 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business 1 Organizaţii şi structuri de standardizare Cele mai multe standarde cu privire la managementul proceselor de bussines au fost introduse de către principalele consorţii industriale, sau de către principalele instituţii de standardizare aşa cum se poate vedea în figura următoare. Acest capitol va prezenta principalele tipuri de standarde şi relaţiile dintre ele. Activities Process Modelling UMM UML MDA / BPDM BPMN BPSM Process Choreography BPSS WSBPEL (abstract) WS-CDL WSCI WSCL Process Orchestration WSBPEL (executable) ebxml CPPA BPML XPDL Workflow Adminstration BPQL WfXML Workflow Extensions BPXL BTP Information Models UBL OAGIS RosettaNet PIP Service Descriptions WSDL Communication s SOAP ASAP Standards Bodies OASIS ebxml OMG BPMI W3C WfMC OAGi RosettaNet Figura 1 Tipuri de standarde şi relaţiile dintre ele 1.1 OASIS OASIS (Organisations for the Advancement of Structured Information Standards) este o organizatie non-profit, un consorţiu global care conduce şi gestionează modalitatea de dezvoltare, convergenţa şi adoptarea stanadardelor de e-bussines. OASIS produce standarde pentru standarde pentru securitate, servicii WEB, conformitatea documentelor XML, tranzacţii de business, publicarea documentelor electronice şi interoperabilitate. OASIS a fost fondată în 1993 sub numele de SGML Open ca un consorţiu de utilizatori care intenţionau dezvoltarea unui ghid de lucru pentru definirea interoperabilităţii pentru 7

171 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business produse care suportă standard Generalized Markup Language (SGML). OASIS şi-a schimbat numele în anul 1998 pentru a reflecta scopul muncii sale tehnice. La acest moment OASIS are mai mult de 5000 de participanţi reprezentând peste 600 de organizaţii şi membrii individuali din 100 de ţări Standarde suportate Mai multe standarde legate de Business Process Management Systems (BPMS) ca BPEL4WS sau BPMI s BPML au fost propuse la OASIS să devină fundamentul unei limbaj standard de bussines process execution Web Service Business Execution Language (WSBPEL), care a fost finalizat de către comitetul tehnic OASIS WSBPEL în Un proiect al comitetului WSBPEL versiunea 2.0 a fost finalizat în 21 decembrie În noiembrie 1999, UN / CEFACT şi OASIS au început să dezvolte iniţiativa ebxmlul ( Viziunea despre ebxml este de a crea o piaţă electronică unde firmele se pot găsi unele pe altele, dându-şi acordul să devină parteneri comerciali şi de conduită de afaceri. Toate operaţiunile sunt efectuate în mod automat prin schimbul de documente XML. OASIS ebxml Buisness Process Specification Schema (BPSS) se bazează pe concepte introduse de UN / CEFACT Modelarea Metodologiei (UMM). UMM este o metodologie pentru definirea aspectului afacerii dintr-o colaborare B2B care este bazată pe UML. BPSS poate fi considerată o reprezentare XML a unui subset de UMM. Sub WSBPEL şi UMM următoarele standarde sunt considerate pentru acest proiect: BPSS: OASIS ebxml Business Process Specification Schema pentru a descrie automatizarea şi previziunea de schimbul de afaceri de colaborare utilizând XML. CPPA: OASIS ebxml Profil Protocolul de Colaborare şi Agreement, descrie modul în care parteneri de afaceri se angajeză în afaceri electronice colaborarand prin schimbul de mesaje electronice. BTP: OASIS Buisness Transaction Protocolul defineşte modul de a gestiona complexe B2B de tranzacţii pe Internet. ASAP OASIS Asynchronous Service Access Protocol este un protocol pentru a începe, administra, şi monitoriză procese mari ruland. 1.2 Business Process Management Initiative (BPMI) Business Process Management Initiative (BPMI.org - este o corporaţie non-profit, care are scopul de a împuternici companii pentru a dezvolta şi opera procesele de afaceri care deţin mai multe aplicaţii şi parteneri de afaceri pe Internet. Iniţiativa de bază este de a promova şi dezvolta drepturi de autor bazate pe standardele XML deschise, complete şi gratuite care ofera suppoort şi deschide procesul de gestionare a afacerii în industrie. BPMI.org abordează standardele existente, acolo unde este cazul, de lucru cu standardele complementare, cum ar fi organismele de OMG, şi WfMC OASIS. În zonele în care nu există standarde, BPMI.org se concentrează asupra standardelor de dezvoltare pentru a sprijini întregul ciclu de viaţă al procesului de gestionare a afacerilor - de la proiectare, prin detaşare, executare, întreţinere, şi optimizare. În iunie 2005, Business Process Management Initiative (BPMI) şi Object Management Group (OMG) a anunţat dorinţa de fuziune pentru procesul de gestionare a activităţilor de afaceri. Combinările de activităţi vor fi efectuate în OMG Business Modeling şi Integration 8

172 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Domain Task Force (BMI DTF). Ele sunt continuarea muncii BPMI şi OMG şi sunt axate pe toate aspectele legate de procesul de management al afacerilor, inclusiv: Livrare Busisness Process Definition Metamodel (BPDM) Definitie de limbaj de afaceri, vocabular, precum şi reguli Informaţii de Managementul Afacerilor (BIM) Enterprise Application Integration (EAI) Colaborare Business-to-Business (B2B) Servicii Web de informaţii şi procese Politicii de securitate şi de gestionare Rafinament, de educaţie şi de promovare a principiilor, abordări şi tenets de Business Process Management din cadrul mai larg de comunitatea de afaceri BMI DTF va integra şi va refolosi sisteme complementare de integrare şi servicii Web, cum ar fi standardele WS-BPEL de la OASIS, WSDL, şi XML Schema de la W3C Standarde suportate BPMI.org a finalizat specificaţiile Business Process Modeling Language (BPML) în 2002 şi ale lui BPMN în O caracteristică fundamentala, esenţiala şi distinctivă a BPMI standard este că acestea au fost dezvoltate cu o fundaţie matematica solidă. A fost folosită ramura de calcul Pi a proceselor de calcul. Aceasta este o metoda de calcul formal care formează fundamentul pentru procesele dinamice şi mobile. Aceasta înseamnă că procesele de afaceri proiectate folosind standardele BPMN pot fi manipulate direct şi limba poate fi creeată şi făcuta disponibilă pentru executare imediat. Figura 2 BPMI.org - stiva de standarde BPM 9

173 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business BPML a fost lansat de către BPMI în noiembrie După cum este prezentat în Figura 2 din 2004, BPMI.org a oprit suportul pentru acest standard şi a favorizat BPEL. BPML a fost proiectat ca un Pi-de calcule pe bază standard de descriere a unui proces de afaceri. Specificaţiile BPML oferă un model abstract pentru procesele de afaceri şi sprijinirea entităţilor. BPML defineşte un model formal pentru a exprima abstract, procesele executabile care detin toate aspectele legate de întreprindere procese de afaceri, inclusiv activităţi de complexitate diferita, şi de tranzacţiile lor de compensare, de administrare a datelor, concurenta, excepţii de manipulare şi operaţionale semantica. BPML oferă, de asemenea, o gramatica, sub formă de o schemă XML pentru a permite persistenţa şi schimbul reciproc de definiţii dealungul sistemelor eterogene instrumente de modelare. "[BPML] BPMN a fost lansat ca un proiect de lucru de către BPMI.org în august 2003 şi ca o specificaţie finală în mai BPMN este în prezent pe cale de a deveni un standard al OMG. Termenul limită pentru "Adopted Final Specification" a fost pe 6 februarie În cea de-a doua fază a activităţii BPMI, au fost planificate să se dezvolte standarde viitoare: BPSM: Busisness Process Semantic Model a fost dezvoltat pentru a defini un cadru pentru definirea formală a Semanticii pentru procesele de afaceri. BPXL: Busisness Process extension Layer este o extensie a BPEL care acoperă, de exemplu, tranzacţii, reguli de afaceri, de management. BPQL: Business Process Query Language se propune a fi un standard de limbaj de interogare pentru procesele de afaceri, bazate pe definiţiile WSDL. BPQL a fost proiectat pentru a fi o interfaţa de management la un proces de gestionare a infrastructurii de afaceri, care include o facilitate a procesului de execuţie şi de facilitatea procesului de implementare. Interfata BPQL ar trebui să permită analize de afaceri şi a controla executarea de procese gestionate de instanţe în procesul de server. Interfaţa este bazată pe Simple Object Access Protocol (SOAP). Dezvoltarea acestor standarde a fost oprită, după fuziunea BPMI şi OMG. 1.3 Object Management Group (OMG) Object Management Group (OMG - este o alianta deschisa, nonprofit, un consorţiu care produce şi menţine industria software, specificaţii pentru aplicaţii de intreprindere interoperabile. Alianţa include fiecare mare companie din industria software şi alte sute de companii mai mici. Cele mai importante specificatii sunt multi-platforma - Model Driven Architecture (MDA). Ea se bazează pe specificaţiile de modelare Meta Object Facility (MF), de UML, XMI, şi de Common Warehouse Metamodel (CWM). PlatformaOMG intermediara este CORBA, care include Interface Definition Language IDL OMG şi protocolul IIOP. Object Management Architecture (OMA) defineşte standardul de servicii, care vor reporta în MDA rezultatele muncii în scurt timp. OMG Task Forces standardizează facilităţi din domeniul industrial precum servicii de îngrijire medicală, de fabricaţie, de telecomunicaţii, şi altele. 10

174 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Misiunea OMG (BMI DTF este de a dezvolta modele de specificaţii pentru suport integrat de gestionare a unei întreprinderi. Aceste specificaţii vor promova inter-şi intra - intreprinderii servicii de integrare şi colaborare de oameni, sisteme, procese şi de informaţii din cadrul întreprinderii, inclusiv clienţii şi partenerii de afaceri. Principalele domenii de interes sunt: Planificarea de afaceri şi motivaţia de modelare Business Process Management Reguli de afaceri Business Modeling Limbaj şi vocabular de business BMI DTF este axat pe semantica de bussines şi recunoaşte că este nevoie să se coordononeze cu alte organisme de standardizare. Business Process Definition Metamodel (BPDM) este în prezent în curs de dezvoltare în BMI DTF. Termenul limită pentru depunerea finală a fost aprilie Standarde suportate BMI DTF continuă BPMI.org şi OMG şi este concentrata pe toate aspectele legate de Business Process Management. BPMI.org-i utilizate pe scară largă standard pentru modelare de afaceri, Buisness Proces Modeling Notation (BPMN), a început perioada de comentariu solicitate de către OMG-rapid urmări "Cerere pentru comentarii" (RFC) adoptarea de proces, în septembrie 2005, aşa cum a făcut-business Motivation Model (BMM) a contribuit prin Regulamentul Grupului de afaceri. Separat, un nou standard de definind Semantica de afaceri Vocabular de afaceri şi de Reguli (SVBR) a completat evaluarea membru şi a început o serie de voturi care să conducă la adoptarea formală. BMM: Business Motivation Model este un standard, care oferă un metamodel pentru modele de enterprise- specificatii. BMM conţine: o Un set de construit concepte care definesc elementele unor planuri de afaceri. Ele sunt asociate într-o structură care este metodologic neutra; va sprijini o gamă largă de abordări pentru crearea şi menţinerea unui BMM pentru o întreprindere, şi este deosebit de puternic în sprijinirea proceselor de afaceri ce sunt conduse de schimbare. o Roluri în structura pentru trei concepte esenţiale: Bussines Process, Bussines Rule şi Organization Unit. Ei participa în asociaţii cu BMM, dar şi în alte asociaţii în afara domeniului său de aplicare - cum este cazul în SVBR. Ele sunt considerate ca referiri la elementele care vor fi definite şi menţinute în afara unei întreprinderi de BMM. SVBR: Un vocabular de afaceri conţine toţi termenii de specialitate şi definiţii de concepte pe care o anumită organizaţie data sau comunitate le utilizează în scris şi vorbit în cursul procesului de bussines. Semantica Vocabularului de afaceri şi de Reguli (SVBR) include doua vocabulare de specialitate: o SBVR "Vocabularul pentru descrierea vocabularelor de afaceri" se ocupa cu tot felul de termeni şi sensuri. El se bazează pe standardele ISO terminologice. o SBVR "Vocabular pentru Descrierea Regulilor de afaceri" se ocupa cu caietul de sarcini, în sensul de afaceri se bazează pe reguli şi pe "Vocabular pentru Descrierea vocabularului de afaceri". 11

175 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Cele două vocabulare au fost separate, astfel încât "Vocabularul pentru descrierea vocabularelor de afaceri" ar putea fi utilizat independent - de exemplu, ca bază pentru vocabularul pentru procese de afaceri sau de organizare de roluri. Standardul conţine metamodel SVBR, un model de MOF creat prin combinaţie de SVBR Logical Formulation şi Semantica Vocabularului, "Vocabular pentru Descrierea vocabularului de afaceri" şi ghidat de la "Vocabulary-to-MOF/XMI Mapare Set de Reguli ". 1.4 World Wide Web Consortium (W3C) World Wide Web Consortium (W3C - este un consorţiu internaţional unde organizaţiile membru, un personal full-time, precum şi publicul lucrează împreună pentru a dezvolta standardele web. Misiunea lui W3C este de a conduce World Wide Web la întregul său potenţial, prin dezvoltarea de protocoale şi linii directoare care să asigure creşterea pe termen lung pentru Web. În primul rand, prin misiunea sa, W3C, urmăreşte crearea de standarde şi linii directoare web. Din 1994, W3C a publicat mai mult de nouăzeci astfel de standarde, denumite Recomandări W3C. W3C angajează de asemenea, în educaţie şi deschidere, dezvoltă aplicaţii software, şi de asemenea un forum deschis pentru discutii despre Web. Pentru ca Web-ul să ajunga la întregul său potenţial, cele mai fundamentale tehnologii web trebuie să fie compatibile una cu cealaltă şi să permită oricarui hardware şi software acessul la Web pentru a lucra împreună. W3C se referă la acest obiectiv prin termenul de interoperabilitate Web". Prin publicarea standardelor deschise pentru limbaje Web şi protocoale, W3C caută să evite fragmentarea pieţei Standarde suportate W3C a publicat standarde diferite cu privire la serviciile web şi arhitecturi workflow de afaceri. De interes special, sunt: WS-CDL: Web Service Coregraphy Definition Language WS-CDL este un limbaj bazat pe XML, care descrie colaborări peer-to-peer de participanţi, prin definirea, dintr-un punct de vedere global, a unui comportament observabil şi complementar comun. Specificaţiile de servicii web oferă o punte de comunicare între medii eterogene computaţionale folosite pentru a dezvolta aplicaţii gazdă. WS-CDL permite specificarea de termen lung, a colaborării peer-to-peer între serviciile participante. WSDL: Web Service Description Language WSDL Version 2.0 (WSDL 2.0) oferă un model şi un format XML pentru descrierea serviciilor web. WSDL 2.0 permite separarea descrierii, a funcţionalitaţilor abstracte oferită de un serviciu de la detalii concrete, a unui serviciu de descriere, cum ar fi "cum" şi "unde", care este oferit de funcţionalitate. Recomandarea W3C candidată a fost publicată în ianuarie SOAP: Simple Object Access Protocol SOAP Version 1.2 prevede definiţia XML pe bază de informaţii care pot fi folosite pentru schimbul de informaţii structurate şi scris într-o între colegii descentralizate, distribuite de mediu. SOAP PART1 explică faptul că un mesaj SOAP, este formal, specificat ca un Infoset XML, care oferă o descriere abstract, a conţinutul său. SOAP este în esenţă stateless (lipsit de stare), cu un singur mod de schimb mesaj, dar aplicatiile pot crea mai multe aplicatii complexe de modele de interacţiune (de exemplu: cerere / răspuns, cererea / răspunsuri multiple, etc), prin combinarea unei astfel de mod de schimburi cu facilităţile oferite de o bază de protocol şi / sau aplicarea unor informaţii specifice. SOAP este silenţios pe semantică de orice cerere de date specifice, pe probleme cum ar fi de dirijare a mesajelor SOAP, 12

176 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business sigură de transfer de date, firewall, traversal, etc Cu toate acestea, SOAP furnizează cadre de aplicare specifice cu informaţii care pot fi transmise într-o manieră extensibilă. 1.5 Workflow Management Coalition (WfMC) Workflow Management Coalition (WfMC - a fost înfiinţată în august 1993, este o organizaţie non-profit de furnizori sisteme workflow, utilizatori, analişti şi grupuri de cercetare. Misiunea coaliţiei este de a promova dezvoltarea şi utilizarea fluxului de lucru prin stabilirea de standarde pentru software, a unei terminologii, interoperabilitate şi conectivitate între produsele de lucru. Format din peste 300 de membri în întreaga lume, WfMC este principalul organism de standarde pentru această semnificativă piaţă de software. Principalele obiective WfMC sunt: De a creşte valoarea clienţilor prin utilizarea tehnologiilor workflow. Reducerea riscului produselor workflow. Creşterea pieţei de produse workflow Supported StandardsStandarde suportate Munca initiala a WfMC s-a axat pe publicarea Modelului de Referinţă WFMC şi a unui glosar, definirea unei arhitecturi comune şi a unei terminologii pentru industrie. O importantă etapă a fost realizata cu prima publicare a specificaţiilor WorkFlow API (WAPI), care acoperă WorkFlow Client Application Interface, şi de WorkFlow Interoperability. Specificaţia Audit Data a fost adăugată în 1997, fiind urmată de specificaţia Process Definition Import / Export. O nouă versiune a WAPI acoperă Application Invocation API, completând livrabilele WfMC legate de cele cinci funcţii de interfaţă de referinţă definite în model. Munca din etapa urmatoare s-a axat pe completarea modelului comun de obiecte cu sisteme de legare de obiecte ca IDL şi OLE precum şi adăugarea de extensii de securitate şi modele de interopearbilitate. WfMC a validat utilizarea specificatiilor proprii prin implementarile de prototipuri şi demonstraţiile directe. În ceea ce priveşte standardele majore WfMC acestea sunt: XPDL: XML Process Definition Language. WfMC a identificat cinci interfeţe funcţionale la un proces sau serviciu workflow, ca parte a programului său de standardizare. XPDL face parte din documentatia referitoare la "Interfaţa unu" - sprijinirea Process Definition Import şi Export. Aceasta include o interfaţă comună pentru un metamodel care descrie procesul de definiţie (utilizăm XPDL) de companie şi de asemenea, o schemă XML pentru a defini procesul de succesiune. XPDL versiunea 2.0 este compatibilă cu versiunea 1.0, şi este destinat să fie folosit ca un format de fişier pentru BPMN. Scopul original al XPDL este menţinut şi consolidat prin cea de-a doua versiune. XPDL şi BPMN abordează aceeaşi problemă de modelare din perspective diferite. XPDL oferă un format de fişier XML care pot fi folosite pentru a alterna între procesul de modele de instrumente. BPMN oferă o grafică de notaţie complexă de procese de afaceri umană, pentru a facilita comunicarea între utilizatorii de afaceri şi tehnice utilizatori. Există un număr de elemente care sunt prezente în BPMN versiunea 1.0, care nu au fost prezente în XPDL versiunea 1.0. Acestea au fost încorporate în versiunea 2.0 a XPDL. 13

177 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Wf-XML: WF-XML pentru servicii Web este un protocol care pot fi folosite pentru a controla un proces motor de la distanţă, cu scopul de a trimite sau a recuperat procesul de definiţii. Procesul definiţii, care sunt descrise de limbaje ca WSBPEL sau XPDL sunt de aşteptat să fie instalat intr-un proces de executie pentru motor. Limbajul natural în sine nu defineşte modul de instalare a defini în motor. În schimb, acesta este rolul WF-XML. Conceptul central este că acolo va fi procesul de instrumente de design care se specializa în permite unui utilizator de a edita un proces de definiţie, care pot produce în consum şi un format standard. Vor fi motoarele de proces, care o pot executa. Procesul de design instrument utilizează XML pentru WF prima lista de procesul de definiţii, care sunt încărcate în procesul de motor, şi apoi de a primii un anumit proces de definiţie. WF-XML prevede, de asemenea, un mod de a defini procesul de actualizare, precum şi de a instala noul proces de definiţii. 1.6 RosettaNet RosettaNet ( o subsidiară a lui GSI US ( este o organizaţie non profit dedicata dezvoltarii colaborative şi a dislocării rapide de proceduri standard de e-business care aliniază procesele inauntrul retelelor globale de comert. Standardele şi serviciile RosettaNet furnizează un limbaj comun pentru tranzactiile e- business şi fundaţia pentru integrarea de procese critice între partenerii din lanţul global de furnizori. Companiile care folosesc standardele RosetttaNet beneficiază de imbunătăţiri în comunicaţiile de tip e-business cu partenerii de comerţ, îmbunătăţiri la mangemetnul capabilităţilor ciclului de viaţă al produselor furnizate şi o satisfacţie mai mare a clientului. Din 1998 RosettaNet a fost folosită şi aprobată de mai mult de 500 de companii din jurul lumii, companii cu activităţi din domeniile IT (Tehnologia Informatiei), Componente Electronice, Semiconductori şi Furnizori de Solutii, companii care lucrează impreună ca să creeze, să implementeze şi să promoveze standarde de e-business liber. RosettaNet este numită după Rosetta Stone, nume care cioplit în trei limbi a dus la intelegerea hieroglifelor. Standardele RosettaStone furnizează cadre pentru afaceri care dau voie companiilor individuale să işi imbunătăţească interoperabilitata proceselor de afaceri de-a lungul lanţului global de furnizori.aceste standarde transpun soluţii proprietare în piaţă. De fapt RosettaNet imprumută protocoale, ghiduri şi specificaţii pentru a crea standarde rapide pentru comunicaţii eficiente în afaceri pe platforme,aplicaţii şi reţele multiple. Standardele RosettaNet sunt libere şi globale. Ele ne invaţă cum să implementăm processe colaborative de tip business între partenerii din lanţul de furnizare, folosind aplicaţii prin reţea. Aceste specificaţii includ definiţiile procedurilor de afaceri şi elemente tehnice pentru interoperabilitate şi comunicaţie. Interfaţa Partener pentru Procese RosettaNet (PIPs) sunt dialoguri bazate pe XML şi speciliazate în transfer de tip system-to-system care definesc procedurile de afaceri dintre partenerii de comert.pip-ul standardizează automatizarea procedurilor publice de afaceri pin standardizare documentelor şi a secventei de trimitere a acestor documente, şi a atributelor fizice al mesajului care defineste calitatea serviciului.astfel fiecare specificare de PIP include un document de tip business cu vocabularul său şi o procedura de afaceri cu coregrafia mesajului din dialog. 14

178 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business De asemenea RosettaNet defineste sistemul de mesagerie folosit pentru trimiterea şi primirea acelor documente.cadrul de Implementare RosettaNet (RNIF) furnizează protocoale de schimb pentru o implementare rapidă şi eficientă a standardelor RosettaNet.RNIF-ul specifică schimbul de informaţii dintre servere partenere care folosesc XML,acoperind transportul,dirijarea şi impachetarea; securitatea semnalelor şi inţelegerea partenerilor de comerţ. În legătură cu PIP-ul website-ul RosettaNet declară: PIP-urile sunt organizate în sapte grupări principale de proceduri de afaceri care reprezintă baza retelei de comert. Fiecare grupare este impărţită în segmente proceduri de intreprindere care implică mai multe tipuri de parteneri de comerţ. Inăuntrul fiecarui segment sunt PIP-uri individuale. Gruparile PIP sunt: Gruparea 1: Revizuirea Produselor şi a Serviciilor Partenere. Permite colecţionarea de informaţii, intreţinerea şi distribuţia pentru dezvoltare a profilelor partenerilor de comert şi a subscrierilor produs-informaţie. Gruparea 2: Informaţii despre Produs. Permite distribuţia şi reînnoirea periodică a produsului şi a informaţiilor detaliate de design, incluzând notiţele cu schimbările care au fost făcute asupra produselor şi detaliile tehnice despre produs. Gruparea 3: Suport pentru Managementul de Comandă. Oferă suport pentru aria afacerilor de tip management de comandă, incepând de la preţ livrare şi trecand prin initierea comenzii de cumparare, reportare statsului şi managementul acestora.de asemenea facturarea comenzii,plata şi notificarea discrepantelor sunt administrate prin aceasta grupare de proceduri. Gruparea 4: Administrarea inventarului. Ingaduie managementul inventarului incluzand colaborarea, umplerea acestuia, protejarea preturilor, reportarea şi alocarea produselor constranse. Gruparea 5: Mangementul Informatiilor de Marketing. Permite comunicarea informaţiilor de marketing, incluzand planuri de campanii, informaţii de varf şi inregistrarea designului. Gruparea 6: Suportul de Servicii. Furnizează suport tehnic după vanzare, garantia servicilor şi competente de management al bunurilor. Guprarea 7: Fabricarea. Permite schimbul de design-uri, configuratii, proceduri, calitaţi şi alte informaţii de fabricatie care să suporte acest 'mediu virtual de fabricare'. Aproximativ 125 de specificatii de PIP pot fi preluate din directorul PIP. Aceste specificatii sunt numite validate dacă au fost aplicate cu succes între parteneri de comert. În momentul de fata aproximativ 50 de specificatii au acest status. 1.7 Open Applications Group (OAGi) Open Applications Group, Inc. (OAGi - este un grup non-profit cu standarde libere XML bazate pe proceduri pentru integrarile de tip A2A şi B2B. OAGi a fost format la sfarsitul lui 1994 ca prima organizaţie post-edi (Electronic Data Interchange) care se concentra asupra imbunatatirii starii de integrare a aplicatiilor. Abordarea neutra fata de tehnologie a lui OAGi fata de construirea standardului Open Applications Group Integration Sepcification (OAGIS) se asigură că atât clienţii de vârf cât şi furnizorii 15

179 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business de solutii folosesc un standard XML comun care poate fi dispus folosind serviciul web ebxml sau un cadru de lucru la alegere. Standardul OAGIS XML este complet gratuit. OAGIS este un limbaj de afaceri XML care permite crearea unui model informatic canonic între diferite afaceri sau organizatii administrative. Modelul canonic furnizează un limbaj de afaceri comun pe care organizatiile ce îl pot folosi ca să rezolve problema de integrare dintre n organizaţii eterogene care vorbesc limbaje specifice. Soluţia OAGIS XML este arhitecturală, pentru a suporta integrarea de care este nevoie atat între intreprinderi cat şi inauntrul intreprinderilor. În opt ani a fost alcatuit un set de definitii procedurale şi definiţii de mesaje XML (Figura 3). Versiunea curenta (9.0) include: Figura 3 SEQ, limbajul canonic OAGIS 434 Documente Obiect Business (BOD) 77 Substantive BOD-uri noi pentru Managementul Relatiilor cu Clientii, Logistica, şi Sarbanes- Oxley, printre altele Adoptarea a UN/CEFACT/ISO-CCTS 2.01 Adoptarea şi includerea a Componentelor de Bază aprobate şi armonizate din UN/CEFACT TBG 17 Imbunatatiri pentru a furniza un suport mai bun al serviciilor web BOD-urile sunt definite în prezent ca o schema XML; un model UML echivalent va aparea în curand. Conceptele OAGi se bazează pe modele obiect de afaceri virtuale, bazat pe continut care permit aplicatiilor pentru intreprinderi să construiasca un obiect virtual care să se muleze în jurul lor prin folosirea API-urilor compatibile cu OAGi. Aceasta interoperabilitate este realizata cu avantaje orientate pe obiecte fără necesitatea de a implementa o aplicatie software într-o tehnologie orientata pe obiecte specifica. Pentru a permite comunicarea între componentele software-urilor de afaceri, evenimentele sunt comunicate printr - o coloana vertebrala integrata folosind interfete obiect virtuale BOD-urilor compatibile cu OAGi. Coloana vertebrala integrata suporta paradigme de comunicare cum ar fi publica şi aboneazate, cere şi raspunde, şi mecanisme de transport, unelte de mapare de date, ghidare pentru 16

180 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business integrare şi capabilitatii de logare. Documentatiea pentru OAGIS,versiunea 9, explica un BOD şi termenele Substantiv şi Verb după cum urmeaza: BOD-ul este o arhitectură orizontală de mesagerie.bod-urile sunt mesajele de afaceri sau documentele de afaceri care sunt schimbate între aplicatiile software sau componentele; între companii, peste lanturi de furnizare, şi între lanturi de furnizare. În scopul de a face acest lucru BOD-ul trebuie să poată să informeze sistemul primitor despre tipul de mesaj la care trebuie să se astepte. De multe ori există o interacţiune dublă între cel care trimite şi cel care primeşte, din acest motive BOD-ul trebuie să fi apt să comunice statusul şi condiţiile de eroare.este de asemenea necesar să furnizeze pentru multiple actiuni asupra unui obiect comun de afaceri(substantiv).din acest motiv BOD-urile au fost proiectate să se foloseasca de Substantivele comune care dacă primesc o actiune (Verb) pot fi aplicate. Arhitectura de mesaj BOD este independenta de mecanismul de comunicare.poate fi folosita cu protocoale de transport simple cum ar fi HTTP şi SMTP dar mai poate fi folosit în protocoale de transport mai complexe cum ar fi SOAP,ebXML Transport şi Ghidare, sau orice alte Sistem de Integrare al Intreprinderilor de Afaceri. Figura 4 SEQ Reprezantarea grafica a unui BOD Părţile unui BOD sunt definite după cum urmează (Figura 4): Cel mai de dinafară strat al BOD-ului identifică Verbele, Substantivele, reviziile şi mediul de rulare Application Area comunica informaţia în asa fel incat să poata fi folosita de infrastructura pentru a comunica mesajele 17

181 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Data area contine sarcina utila specifica afacerii sau data care este comunicata de BOD Verbs(verbe) identifica actiunea care este realizata de un substantiv specific al BODului Nouns(substantive) identifica data specifica a afacerii care este comunicata, de exemplu Ordinul de Cumparare, Ordinul de Vanzare, Ruta, Transportul. Ele contin componentele care sunt descrise mai jos.substantivele sunt extensibile ca să poata suporta nevoile unor industrii specifice. Components sunt blocuri extensibile din care este construit un substantiv, de exemplu Header-ul Ordinului de Cumparare, Linia Ordinului de Cumparare, Adresa. Ele contin compusi şi campuri, care sunt descrise mai jos.componentele sunt extensibile. Compunds sunt cele mai de bază blocuri de constructie care sunt folosite de toate BOD-urile, de exemplu Cantitatea. Ele sunt extensibile prin folosire contextuală dar nu şi cu campuri în plus, de exemplu OrderedQuantity, ShippedQuantity, BackOrderedQuantity. Fields sunt cele mai de jos elemente definite în OAGIS.Fields sunt elemente fundamentale care sunt folosite pentra a crea Compounds şi Components,de exemplu Description,Name. 18

182 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business 2 Limbaje de modelare şi notaţii grafice Acest capitol prezintă metodologia de modelare şi standardele de notaţie grafică selectate pentru analiză şi evaluare. Aceste standarde sunt cele considerate a fi relevante pentru în analiza tehnologii workflow de afaceri. Cele patru standarde din acest capitol prezintă diferite aspecte şi abordări şi, care, astfel, nu sunt comparabile cu altele, spre deosebire de cazul standardele pentru limbajele de coregrafia şi orchestraţie. Fiecare standard de acolo a fost analizat în funcţie de contextul său special şi obiectivele într-un mod independent de evaluat şi apoi pentru a relevanţei sale SCIPA. UMM este o metodologie de modelare bazată pe UML şi dezvoltată pentru a modela procese de afaceri pentru utilizarea în relaţiile de e-afaceri. Este de interes special deoarece este un standard ONU/ CEFACT dezvoltat pentru utilizare în schimburi electronice de date şi este sprijinit de mai multe grupuri industriale. UML este un standard de modelare care se aplică în general în dezvoltarea de software. Este evaluat aici pentru aplicarea sa în context SCIPA. În continuare se fac referinţe, de asemenea, la MDA, abordarea archtecturala condusa de model (Model Driven Architecture) propusă de OMG, care prevede un mijloc de a adopta modele de dezvoltare pe tot parcursul ciclului de viaţă, de la abstract la o tehnologie specifică. BPDM este dezvoltat de către OMG ca un metamodel UML pentru definirea de procese de afaceri, independent de orice tehnologie specifică. BPMN este o notaţie grafică pentru fluxurile de proces de afaceri care se bazează pe diagrame tradiţional cunoscute analiştilor de afaceri. Deoarece poate fi mapat la BPEL, poate oferi o punte de legătură între viziunea bazată pe afaceri şi cea tehnică, şi, astfel, ocupă o poziţie strategică în stiva BPM. 2.1 Unified Modeling Language (UML) UML este un standard relativ deschis, controlat de Object Management Group (OMG), un consorţiu non-profit, constituit pentru produce şi menţine specificaţii în industria calculatoarelor pentru aplicaţii de întreprindere interoperabile. Specificatia OMG caiet de sarcini prevede: "The Unified Modeling Language (UML) este un limbaj grafic pentru vizualizarea, specificarea, construirea, şi documentare comportarii unui sistem software-intensiv. UML oferă o modalitate standard de a scrie un blueprint al sistemului, inclusiv conceptual lucruri, cum ar fi procesele de afaceri şi funcţiile sistemului, precum şi lucruri concrete, cum ar fi declaraţiile limbaj de programare, scheme de baze de date, software şi de componente refolosibile. "[ISO/IEC19501] Dezvoltarea Unified Modeling Language (UML) a început în 1994 de către Rational Software Corporation. În 1995, Object Management Group (OMG) a emis o cerere de ofertă (RFP) pentru el. Mai târziu, Rational a stabilit consorţiul Partenerilor UML incluzand mai multe companii care să lucreze pentru definirea UML 1.0. Consorţiul a inclus Rational Software, Digital Equipment Corporation, Hewlett-Packard, i-logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Texas Instruments, şi Unisys. Acest consorţiu a prezentat OMGului, în ianuarie 1997, un prim răspuns la cererea de ofertă. A fuzionat apoi şi actualizat prin propunerile de la IBM, ObjecTime, Platinum Technologies, Ptech, Taskon, Reich Technologies, şi Softeam, care au aderat la UML Parteneri. La sfârsitul lui 1997, după mai multe revizuiri şi comentarii publice, UML 1.1 a fost aprobat de către OMG. 19

183 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business În ultimii ani, UML a fost revizuit şi a crescut. Au fost publicate mai multe versiuni (majore au fost cele UML 1.3 şi 1.5), care au adaugat noi capabilităţi. UML a devenit foarte popular şi multe companii din industrie au contribuit la standard. UML este acceptat ca specificaţie ISO "ISO / IEC 19501:2005 Tehnologia informaţiei Procesare distribuita deschisă - Unified Modeling Language (UML) Versiunea 1.4.2". Versiunea curentă a standardului este UML 2.0, care a înlocuit UML 1.5. UML 2.0 este un caiet de sarcini mari şi constă din patru părţi: UML 2.0 Superstructure [UML20_SS]. Aceasta defineşte şase diagrame de structura, trei de comportament, patru de interacţiune, şi elementele pe care le cuprinde (parte a limbii ce este întâlnita în uneltele compatibile cu UML 2.0). UML 2.0 Infrastructure [UML20_I]. Infrastructura defineşte clase de bază care formează temelie nu numai pentru UML 2.0 suprastructură, dar, de asemenea, pentru MOF 2.0. UML 2.0 Object Constraint Language (OCL) [UML20_OCL]. Aceasta permite stabilirea de pre-şi post-condiţii, invarianti, şi alte condiţii. UML 2.0 Diagram Interchange [UML20_DI]. Această specificaţie extinde metamodelul UML cu un pachet suplimentar pentru informaţii orientate grafic, care să permită un schimb de modele pentru a fi depozitate sau / şi apoi preluate şi afişate ca au fost iniţial. Adoptarea UML 2.0 Suprastructura este completă [UML21_SS]; adoptarea de celelalte trei părţi ale UML 2.0 este aproape completă Criterii de piaţă Unified Modeling Language este în prezent standardul de-facto pentru construirea de software orientat pe obiecte. UML a devenit un standard ISO. Multe companii, inclusiv membrii ai OMG, ofera training în UML. OMG a organizat propriul sau program de certificare profesionala în UML Există mai multe instrumente de modelare UML pe piaţă, inclusiv cele mai recente instrumente de sprijin al versiunii 2.0. Unele dintre ele sunt instrumente cu sursă deschisă, dar în cele mai bune instrumente de UML sunt comerciale. UML poate fi folosit pentru modelarea proceselor de afaceri. Cu toate acestea, este de multe ori ca fiind prea "tehnic" pentru analiştii de afaceri şi se pare mai puţin popular decât de modelare pentru afaceri BPMN Criterii tehnice Principalele concepte utilizate UML utilizează următoarele concepte, care pot fi grupate în patru mari părţi: A) Concepte legate de modelare de structură: actor. Specifică rolul jucat de către un utilizator sau de orice alt sistem care interacţionează cu subiectul şi ofera un stimul sistemului. De exemplu, fără un client (un actor) la un restaurant, procesul de impunere a produselor alimentare nu poate începe. atribut. Un atribut este o caracteristică abstracta a unei entitati. 20

184 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business clasa. O clasa descrie un set de obiecte care partajează aceleaşi specificaţii de caracteristici, constrângeri, şi semantică. componentă. O componentă reprezinta o parte modulara a unui sistem care incapsulează conţinutul său şi a cărei manifestare este înlocuibila în mediu sau. O componentă îşi defineşte comportament în termeni interfeţe oferite şi solicitate. interfaţă. O interfaţă este un fel de clasificator care reprezintă o declaraţie de un set coerent de caracteristici şi de obligaţiile publice. O interfaţă specifică un contract; orice instanţă a unui clasificator care realizează interfaţa trebuie să-şi îndeplinească contractul. Obligaţiile care pot fi asociate cu o interfaţă sunt sub formă de diverse tipuri de constrângeri (cum ar fi pre-şi post-condiţiile) sau de specificaţiile de protocol, care pot impune restricţii privind interacţiunile de comanda prin intermediul interfeţei. Deoarece interfeţele sunt declaraţii, ele nu sunt instantiable. În schimb, o specificatie de interfaţă este pusa în aplicare de către o instanţă a unui clasificator instantiabil, ceea ce înseamnă că clasificatorul instantiabil prezintă o interfaţă publica care se conformează specificaţiilor de interfaţă. Un anumit clasificator poate implementa mai mult de o interfaţă şi o interfaţă care poate fi implementata de un număr de diferite clasificatoarele. obiect. Un obiect este un mcanism suportat de limbaj pentru a lega strans datele de metodele care operează pe care date. pachet. Un pachet este utilizat pentru a grupa elemente, şi oferă un spaţiu de nume pentru elementele grupate. De obicei, un pachet grupează clase relationate sau de clase cu funcţionalitate relationata. B) Concepte legate de modelare de comportament: activitate. O activitate este o specificatie a unui comportament parametrizat ca şi coordonat de secvenţiere unitaţi subordonate ale căror elemente sunt acţiunile individuale. Baza conceptuala a unei activitate a fost schimbata între versiunile 1.5 şi 2.0. În UML 2.0 o activitate nu mai este bazata pe o diagramă de stare; mai degrabă aceasta se bazează pe un mecanism de coordonare de tip retea Petri eveniment. Un eveniment este specificatia unor apariţii care pot declanşa potenţial efecte de către un obiect. mesaj. Un mesaj este un element într-un model care poate avea un nume care defineşte o anumită fel de comunicare într-o interacţiune. metodă. Metoda este o descriere de comportament care pune în aplicare comportamentale facilitate. Pot exista cel mult o comportare pentru o pereche particulara dintre un clasificator (în calitate de proprietar de comportament) şi o caracteristică comportamentala (ca specificaţie de comportament). operaţie. O operaţie este o trăsătură de comportament a unui clasificator care specifică numele, tipul, parametrii, şi constrângeri pentru a invoca un comportament asociat. stare. O stare modelează o situaţie în care o anumita condiţie invarianta (de obicei implicita) are loc. Invariantul poate reprezenta o situaţie statică, cum ar fi un obiect care aşteapta să apara un eveniment extern. Cu toate acestea, poate, de asemenea, modela condiţii dinamice, cum ar fi procesul de efectuare a unui comportament (de exemplu modelul de element luat în considerare intră în stare cand comportament începe şi-l lasă de îndată ce comportamentul este complet). caz de utilizare. Un caz de utilizare este o specificatie a unui set de acţiuni efectuate de către un sistem, care conduce la un rezultat vizibil, care este, de obicei, de valoare pentru unul sau mai multe actori sau alte părţi interesate a sistemului. 21

185 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business C) Concepte legate de modelare de relatii: agregare. O agregare este parte de relaţie. Agregarile sunt utilizate pentru a descrie elementele care sunt constituite din componente mai mici. Relaţiile de agregare sunt prezentate printr-o indicatie spre clasa ţintă sau părinte. asociere. O asociere specifică o relaţie semantică care poate apărea între instanţe cu tip. Ea are cel puţin două capete reprezentate de proprietăţi, fiecare dintre care este conectat la tipul capătului. Mai multe capete ale asociaţiei poate avea acelaşi tip. O instanta aunei asociaţie este numita link. compoziţie. O compoziţie (compozit de agregare) este o formă de agregare mai puternica. Este utilizat în cazul în care componentele pot fi incluse în maximum o compoziţie la un moment dat, pentru că numai o singură componentă, la un moment dat, poate avea responsabilitatea de viaţă pentru o altă componentă. Compoziţii sunt relaţii tranzitive, asimetrice şi pot fi recursive. dependenţă. O dependenţă este o relaţie care semnifică faptul că un singur sau un set de elemente de model necesită alte elemente ale modelului pentru specificatie sau implementare. Aceasta înseamnă că semantica completă a elementelor dependente este dependenta semantic sau structural de definiţia elementului(elor) de la furnizor. generalizare (sau moştenire). O generalizare este o relaţie taxonomitrica între un clasificator general şi un clasificator specific. Fiecare instanţă a clasificatorului specific este de asemenea o instanta indirectă a unui clasificator general. Astfel, un clasificator specific moşteneşte caracteristicile clasificatorului general. D) Concepte de suplimentare: stereotip. Un stereotip defineşte modul în care o metaclasă existentă poate fi prelungită, şi permite utilizarea terminologiei sau notaţiei specifice platformei sau domeniului în loc de, sau în plus faţă de, cele utilizate pentru metaclasa extinsă. multiplicitate. Multiplicitatea este o definiţie cuprinzătoare a unui interval de nonnegativ de intregi care începe cu o limită inferioară şi se încheie cu o limită (posibil infinită) superioară, de exemplu, 1, 0.. 1, 1..*. Un element al multiplicarii include aceste informaţii pentru a specifica cardinalitatile permise pentru instanţierea acestui element. rol. Termenul de rol poate indica un rol de asociere sau un rol de colaborare, care este un rol jucat de o instanţă a unei clase într-o colaborare. Modelarea tipurilor de diagramă UML 2.0 oferă o varietate de notatii de modelare puternice şi utile, şi fiecare dintre aceste notatii vizează şi este accesibila şi inteligibila pentru o audienţă limitată. UML 2.0 suportă 13 viziuni (sau tipuri de diagrame de modelare) variinde de la diagrame de utilizare de nivel înalt, care descriu interacţiunile şi relaţiile dintre actori (umani) şi funcţiile majore de afaceri, la diagrame obiecte de nivel scăzut care capturează instanţe ale obiectelor de date individuale, elemntele de date constituente şi valorile lor, precum şi relaţiile acestora cu alte obiecte de date. Aceste diagrame pot fi clasificate ierarhic în trei categorii: 1) Diagrame de structură care definesc arhitectura statică a unui model: 22

186 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Diagrama Clasa descrie tipurile de obiecte din sistem şi diferitele tipuri de relaţii statice care sunt utilizate pentru a construi un model complet. Acesta diagrama este cea mai des utilizata diagrama UML. Diagrama Componenta este folosita pentru a arăta organizarea şi dependenţele componentelor prin interfeţe bine definite. Diagrame Obiect arată un set de obiecte şi relatiile dintre ele. Diagrama de Structura Compusa arată detalii de interior, construcţie şi de relaţii, descompunand ierarhic un obiect în structurile interne. Diagrama de lansare arată nivelul fizic al sistemului, descriind produsului software pe hardware: pe care piese de hardware se executa piese de software. Diagrama pachet arată pachetele şi interacţiunile între ele la un nivel ridicat. 2) Diagramele de comportament definesc ceea ce se întâmplă în sistemul modelat: Diagrama de Activitate descrie logica procedurală, procesul de afaceri, şi de fluxul de lucru. Diagrame de Caz de Utilizare descrie interacţiunile tipice între sistem şi utilizatori (sau mediu). Se defineşte comportamentul, cerinţele şi constrângerile sub formă de script-uri sau de scenarii. Aceste diagrame adresează o viziune statică a unui sistem. Avantajul de a utiliza modelarea studiului de caz este acela că de permite o definiţie externă a sistemului prin identificarea actorilor care pot participa în sistemul viitor, precum şi principalele exemple de implementare. Diagrama Masina cu Stari este o tehnică de familiare pentru a descrie comportamentul unui sistem. Este extrem de utila pentru descrierea sistemelor reactive prin indicarea succesiunii de evenimente la care reacţionează un obiect şi comportamentul rezultat. 3) Diagrame de interacţiune, un subset de diagrame de comportament, pun în evidenţă fluxul de control şi de date între componentele sistemului modelat: Diagrama de Secvenţa descrie colaborarea în termenii unui singur scenariu prin indicarea secvenţei de mesaje pasate între obiecte folosind o linie cronologică verticală. Este un fel de diagrama de interacţiune cu accent pe ordonarea în timp a mesajelor. Diagrama de Comunicare arată legăturile de date între diferiţi participanţii la interacţiune în timpul rulării. A fost numită Diagrama de Colaborare în UML 1.x. În general, se arată instanţele de clase, interrelatiile lor, şi fluxul de mesaje dintre ele. Diagrama de Ansamblu a Interacţiunii afişează o imagine de ansamblu a interacţiuni pentru un caz de utilizare complex sau pentru intregul sistem. Este o alaturare a Diagramelor de Activitate, şi a Diagramelor de Secvenţe. Ea se axează pe evenimente în loc de acţiuni, faţă de o Diagrama de Activitate care permite ca fragmente de interacţiune să fie uşor de combinat cu puncte de decizie şi fluxuri. Diagrama de Termene este o altă formă de Diagrama de Interacţiune care oferă o imagine a stării unui obiect în timp, şi a mesajelor care modifică acea stare. Unele dintre aceste diagrame sunt adecvate pentru procesul de modelare de afaceri: Diagramele UML de Caz de Utilizare pot descrie segmente de afaceri. Participanţii în cazul de utilizare pot reprezenta rolurile partenerilor care interacţionează cu procesul. Diagramele UML de Componente pot fi folosite pentru a rafina dependenţele descrise în diagramele cazuri de utilizare. În acest sens, componenta simbol este utilizata 23

187 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business pentru a ilustra un serviciu Web. Atat participanţii la procesul de afaceri cat şi procesul în sine de afaceri pot fi modelaţi ca servicii Web. Diagramele UML de Comunicare pot fi utilizate pentru modelarea straturilor de afaceri şi de piaţă. Ele pot oferi o vedere de ansamblu a unui proces de colaborare de afaceri între participanţi şi relaţiile acestora. Diagrame UML de Activitate sunt adecvate pentru modelarea protocoalelor şi proceselor de afaceri pentru servicii Web. În afara de elemnetele de control a fluxului (de decizie, fork, join, etc), conţin activităţile de bază necesare pentru interactiunea cu serviciile partenere. Poate, de asemenea, defini procese tranzacţionale, care rafinează colaborări definite de Diagrama UML de Comunicare. Diagramele de activitate sunt cele mai detaliate forme de modelare de procese în termeni UML. Diagramele UML de Clasa sunt adecvate pentru definirea structurii de date manipulate de către procesele de afaceri: atribute de obiecte şi conţinut de mesaje, pasat între obiecte. De asemenea, ele pot furniza detalii cu privire ale diferitelor tipuri de port, prin definirea operaţiunilor lor şi a parametrilor în cauză. Diagramele UML Masina cu Stare pot să definească de obiecte care sunt folosite ca pre-şi post-condiţiile de tranzacţii. Diagramele UML de Interacţiune afişează o prezentare generală a interacţiunilor pentru un caz complex de utilizare sau un sistem. Acestea mixează o Diagramă de Activitate şi o Diagramă de Secvenţă, concentrându-se asupra evenimentelor în loc de acţiuni, comparativ cu o Diagramă de activitate. Diagrame de activitate Diagramele de Activitate sunt în zona de UML care a primit o atenţie deosebită. Motivul pentru aceasta este sunt adecvate pentru a oferi mijloacele de nivel înalt pentru modelarea comportamentului unui sistem dinamic, şi, în consecinţă, pentru procesul de modelare a afacerilor. Diagramele UML de Activitate pot descrie logica procedurală, procesul de afaceri şi fluxul de lucru prin afişarea secvenţei de activităţi. Flowcharts joacă acelaşi rol într-o anumită măsură, dar Diagramele de activitate pot fi folosite pentru a descrie comportamente paralele. Figura 5 prezintă un exemplu de Diagramă de activitate. Sintaxa Diagramelor UML de Activitate este bine adaptată pentru specificarea comportamentului, pentru că permite proceselor să fie reprezentate de actori, roluri, activităţi, flux de executie şi flux de date într-un mod grafic şi cuprinzător. În Diagramele UML de Activitate, unitatea fundamentală de specificare a comportamentului este Acţiunea. O Acţiune preia un set de intrari şi-l transformă intr-un set de iesiri, chiar dacă una sau ambele seturi poate fi goale. Acţiunile pot, de asemenea, modifica starea sistemului. Limbajul oferă o taxonomie a acţiunilor foarte detaliata, prin identificarea a mai mult de 40 de tipuri diferite de acţiune, în detaliu. Cele mai relevante tipuri de acţiuni pentru modelarea proceselor de afaceri sunt conceptul generic de Acţiune, Eveniment de Acceptare, Trimite Semnal, şi constructorii de Acţiune Comportament la Apel. Aceste tipuri de acţiuni sunt prezentate în Figura 6. 24

188 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Figura 5 Diagramă de activitate Figura 6 Principalele construcţii într-o diagramă de activitate În scopul de a reprezenta comportamentul de ansamblu al unui sistem, este utilizat conceptul de Activitate. Activităţile pot include orice număr de noduri de activitate, cum ar fi acţiunile individuale, nodurile de control (de exemplu, split şi join), noduri obiect şi / sau alte activităţi şi definesc dependenţelor dintre elementele lor. Grafic, ele sunt compuse din noduri şi muchii. Muchiile conectează nodurile în ordinea secvenţiala. Nodurile reprezintă Actiuni, Activităţi, Obiecte de date, sau noduri de control. Aceste noduri pot fi aranjate pentru a forma procese concurente sau secvenţiale, şi mai multe Diagrame de Activitate pot fi conectate pentru a descrie procesele mai mare. Diferitele tipuri de noduri de control sunt prezentate în Figura 3-6b. Utilizarea Diagramelor UML 2.0 pentru modelarea proceselor de afaceri a fost investigata în [Russell06]. Evaluarea este bazata pe Sabloane de Fluxuri de lucru, o taxonomie a construcţiilor generice şi recurente, iniţial concepute pentru a evalua sisteme workflow, şi, mai recent, folosite cu succes pentru a evalua standardele de lucru, limbaje ale proceselor de afaceri şi sisteme de informare conştiente de procese, în general. Autorii acestor evaluări de sabloane au ajuns la concluzia următoare: "În timp ce Diagamele UML 2.0 de Activitate au meritul ca o notaţie pentru procesul de modelare de afaceri, ele nu sunt potrivite pentru toate aspectele legate de acest tip de modelare. Ele oferă suport complet pentru 25

189 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business controlul debitului şi perspective de date care permit ca majoritatea construcţiilor întâlnite la analizarea acestor perspective să fie capturate direct. Cu toate acestea, adecvare lor pentru modelare aspectelor legate de resurse sau organizarea proceselor de afaceri este extrem de limitata. Este interesant de observat că acestea nu sunt în stare de a capta multe din construcţii naturale întâlnite în procesele de afaceri, precum noţiunea de cazuri de interacţiune cu mediul operaţional în care procesul funcţiozeza. Acestea sunt limitări pe care le partajează cu cele mai multe formalisme de modelare pentru afaceri şi reflectă accentul copleşitor pus pe perspectivele controlul de flux şi de date în notatiile contemporane de modelare". Tratarea Erorilor şi Tranzactii Excepţiile reprezintă evenimente nedorite care se întâmpla într-un mod neprevizibil. O Diagrama de Activitate efectuează o activitate de tratare a excepţiilor printr-o regiunea interruptibila care înconjoară una sau mai multe activităţi. Dacă ceva, fie finalizarea unei activităţi sau primirea unui semnal, provoacă un token pentru a parcurge o muchie de întreruperea, atunci toate activităţile din regiune va fi oprit, şi fluxul va continua numai pe muchia de intrerupere. UML sprijină modelarea de tranzacţii. Diagramele UML de Interacţiune pot specifica detaliile unei tranzacţii în termeni de schimburi de mesaje între participanţi, astfel rafinand tranzacţiile individuale ale modelului de activitate. Executie asincronă şi concurentă UML 2.0 suportă executarea concomitenta şi asincrone de activităţi. O activitate sau o finalizare a unui proces poate fi setată să depindă de finalizarea unor activităţi multiple şi concomitente. Mesajele şi evenimentele pot fi trimise sincron sau asincron şi pot fi primite asincron. Extensibilitate UML oferă facilităţi de extensie (stereotipuri, valorile etichetate şi constrângeri), care permite să fie construite profiluri UML pentru domenii specifice de aplicare, şi pentru a permite interoperabilitatea prin formatul standardizat, open-source XML Metadata Interchange (XMI). Maparea la BPEL4WS Nu există nici un standard de mapare a Diagramelor UML 2.0 de Activitate la BPEL. 26

190 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Arhitectura condusă de model şi UML Model Driven Architecture (MDA) este un cadru pentru dezvoltarea de software introdus de către Grupul de Management Obiect (OMG). MDA distinge trei straturi de modele: 1) Modelul Independent de Calcul (CIM). Acesta este modelul cel mai abstract, în termeni de MDA, deoarece este independent de tehnologia computaţională. 2) Modelul Independent de Platforma (PIM). Acest model este definit la un nivel ridicat de captare; acesta este independent de orice tehnologie de implementare. Se descrie un sistem software care suportă anumite afaceri. Într-un PIM, sistemul este modelat din punct de vedere al modului în care acesta acceptă cele mai bune afaceri. 3) Modelul Specific Platformei (PSM). Ca pas urmator, constructorii de implementare a sistemului vor fi disponibili într-o tehnologie specifica de implementare. Un PIM este transformat într-un PSM pentru fiecare platformă tehnologica specifica. Cele mai multe sisteme de azi se refera la mai multe tehnologii; prin urmare, pot exista mai multe PSMs pentru un PIM. Ultimul pas în dezvoltare este transformarea fiecarui PSM intr-un cod. Pentru că un PSM este adecvat unei tehnologii această transformare este relativ simpla. În abordarea MDA, UML poate fi folosit pentru a face modelul executabil. Utilizează pentru definitia sistemului şi claselor, cazuri de utilizarea a unui sistem. Apoi, identifică relaţia şi interacţiunile dintre clase, urmat de definirea comportamentului a sistemului şi, în final, generatoare de cod executabil pentru a pune în aplicare a modelului. De exemplu, un cod BPEL cod poate fi generate dintr-un model UML Aplicabilitate UML 2.0 oferă un metamodel şi o notaţie grafică pentru definirea de procese de afaceri pe baza diagramelor de activitate, deoarece acestea suporta şi încurajează comportamentul paralel. Acest lucru il face un instrument de lucru valors pentru workflow şi procesul de modelare. Standardul este public şi este disponibil pentru descărcare de pe site-ul OMG. Multe instrumente de modelare, inclusiv instrumente open source, suportă acest standard. Diagramele UML 2.0 de Activitate sunt similare cu BPMN, deoarece acestea sunt concepute pentru a rezolva aceeaşi problemă de bază: diagramarea proceselor procedurale de afaceri. Diferenţele între cele două diagrame sunt prezente din cauza utilizatorii de diagrame. BPMN este orientat spre oamenii de afaceri. Diagrama de Activitate este încă orientată mai multtehnic, deşi OMG doreste să upgradeze Diagrama de Activitate în termeni de utilizarea sa pentru oamenii de afaceri. În general, UML 2.0 este potrivit pentru SCIPA. 27

191 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Rezumat Avantaje UML 2.0 este un standard de modelare foarte popular şi foarte bine cunoscute. UML 2.0 este larg acceptate de către furnizorii de instrumente software. Poate fi utilizat în asociere cu abordarea MDA. Protocoalele şi procese de afaceri pentru servicii Web pot fi modelate cu Diagrame de activitate. Analiştii de business pot să utilizeze aceleaşi notaţii şi instrumente pentru documentarea proceselor de afaceri precum arhitectii şi designerii de software în documentarea sistemelor software. Dezavantaje Este mai mult orientat spre programare orientate-obiect decât spre definirea de procese de afaceri. Este mai mult orientat tehnic decât BPMN. Nu există nici un standard de mapare de la Diagrama UML 2.0 de Activitate pentru BPEL. Aptitudinii de modelare UML 2.0 pentru aspecte legate de resurse sau organizare a proceselor de afaceri este extrem de limitat. Recomandări UML ca un limbaj de notare grafica potrivita pentru modelarea proceselor de afaceri poate fi văzut ca o alternativă la BPMN şi poate fi recomandat pentru utilizare în SCIPA pentru specificarea grafica de coregrafie a proceselor de afaceri. 2.2 Notaţia de modelare a proceselor de afaceri (BPMN) Business Process Modeling Notation (BPMN) este un standard care a fost elaborat de către organizaţia non-profit Business Process Management Initiative (BPMI.org), care a fost înfiinţata în august 2000, în scopul de a promova dezvoltarea şi utilizarea de Business Process Management (BPM) prin stabilirea de standarde deschise pentru procesul de proiectare, implementare, executare, întreţinere, şi optimizare. A început prin specificatii deschise pentru Business Process Modeling Language (BPML) şi Business Process Query Language (BPQL). În timpul dezvoltării de BPML, membrii BPMI.org au discutat ideea de a crea o notaţie pentru a completa BPML deoarce nu exista niciun standard acceptat pentru notaţie proceselor de afaceri. Au fost, şi încă mai sunt, numeroase notatii proprietare pentru modelare proceselor de afaceri. Scopul Grupului de lucru pentru Notaţii în dezvoltarea BPMN a fost de a lua cele mai bune idei de la aceste notatii diverse pentru a oferi o notaţie standard care ar putea fi înţelesa şi utilizata de către toţi cei implicaţi în procesul de modelare de afaceri, nu numai de dezvoltatorii tehnici, ci şi de analiştii de afaceri. Scopul a fost o notaţie care să uneasca cele două lumi a designului de procese de afaceri şi a implementarii proceselor de afaceri. 28

192 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business În august 2001, a Grupului de lucru notaţie sub prezidentia lui Stephen White, IBM, a fost insarcinat să creeze notatia cu participarea altor firme, cum ar fi Intalio, CSC, MEGA International, Casewise, Popkin Software şi webmethods. În noiembrie 2002, specificatia BPMN 0.9 a fost lansată către public şi, în mai 2004, specificatia versiunii 1.0 a BPMN a fost publicata oficial [BPMN]. Această versiune a inclus o mapare de la BPMN la BPEL4WS, o indicaţie a faptului că inca de atunci BPMI.org a recunoscut importanţa BPEL4WS, comparativ cu propriile sale BPML. O versiune 1.x de BPMN a fost dezvoltata ca o eliberare de neconcordanţele constatate ulterior. S-a mai lucrat de asemenea la standardizarea seturilor de Artifacts pentru a sprijini modelarea generala a afacerilor şi pe verticală a domenii de afaceri (de exemplu, asigurări, producţie, finanţe) [White04b]. În iunie 2005 BPMI.org şi OMG si-au fuzionat activităţile lor legate de BPM, plasand responsabilitatea pentru specificatiile BPMN (si în prezent) în cadrul OMG, la unitatea Business Modeling and Integration Domain Task Force. Din septembrie 2005, grupul de lucru era compus din 58 de membri reprezentând 35 companii [White05b]. Specificatia BPMN 1.0 a fost publicat ca document OMG. Varianta finala adoptata de OMG ca specificatia BPMN a fost lansata în februarie 2006 ca document de OMG [BPMN06]. În ceea ce priveşte relaţia cu alte organizaţii este de standardizare în cauză, BPMI.org a dezvoltat BPMN cu scopul de a fi parte dintr-o stivă, iniţial cu BPML propriu, dar apoi cu BPEL4WS mai târziu, dar şi alte mapările au fost avute în vedere. Acum, că OMG-a luat BPMN în proprietate, nu există în mod clar intenţia de a stabili relaţii mai strânse între BPMN şi alte OMG de lucru [White05b]. De exemplu, este de asteptat ca BPDM ar putea servi ca metamodel pentru BPMN pentru a folosite şi pentru a genera o schemă BPMN pentru schimbul de informaţii semantice BPMN. Sunt de asteptat de asemenea fuzionarea BPMN şi Diagramelor UML de Activitate pentru a aduce împreună cele două sectoare de modelare a proceselor de afaceri şi de analiză şi design software. Nucleul versiunii curente de BPMN este compatibil cu o Diagrama UML 2.0 de Activitate şi este posibilitatea de construi un BPMN într-un profil de Diagrame UML 2.0 de Activitate este luată în considerare. Versiunile 1.x ale BPMN stabilesc specificaţiile pentru erori şi inconsecvenţe şi adaugă / modifică elemente [entru modelarea procesele de colaborare bazate pe sugestiile primite de la Comitetul tehnic OASIS pentru procese de afaceri ebxml, şi este posibil să existe o mapare pentru alte versiuni de BPEL, cum ar fi WS-BPEL 2.0. Este posibil de asemenea să fie construit un Metamodel (BPDM şi / sau XPDL) pentru BPMN pentru a genera o schemă de a păstra şi transporta în diagrama de informaţii semantice şi pentru a utiliza XMI pentru a face schimb de informaţii de cadru a Diagramelor BPMN. Nu există muncă avute în vedere, pe cât de explorare executiv şi alte niveluri de afaceri de modelare a extinde sau stratificat sunt în partea de sus a BPMN [White05b]. Un proces de afaceri nu este neapărat implementat ca un proces automatizat de afaceri într-un limbaj de executie. În acest caz, procesele de afaceri şi participanţii pot fi mapaţi la construcţii, cum ar fi utilizarea de modele comportamentale şi cazuri în UML. BPMN a fost conceput pentru modelarea proceselor de afaceri în general şi are ca ţintă o gamă largă de utilizatori care au nevoie de de a comunica procesele de afaceri cu alţii şi, astfel, au nevoie de un standard de notaţie. Notaţia grafica este destinata să fie intuitiva pentru utilizatori din mediul de afaceri, care ar trebui să poată uşor citit şi înţelege o diagramă BPMN, care are, de asemenea, posibilitatea de a reprezenta semantica pentru proces complex pentru implementorii procesului, care pot utiliza caracteristicile extinse ale notaţiei pentru a reprezenta o proces implementabil. Este prima notaţie în procesele de afaceri care oferă o viziune comuna modelatorilor proceselor de afaceri precum implementatorilor de procese. 29

193 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business BPMN este destinat să fie mapat cu uşurinţă la orice limbaj de executie a proceselor de afaceri, dar şi pentru a fi utilizate în modelarea de procese de afaceri fără a le executa neapărat. Se bazează pe tehnicile fluxurilor din procesele de afaceri utilizate de către analişti şi furnizate într-o varietate de instrumente proprietare, astfel încât analiştii de afaceri de modelare ce sunt obisnuiţi să utilizeze pentru una dintre aceste limbi nu vor avea prea multe probleme în conversie. Scopul a fost de a crea un mecanism simplu pentru crearea de modele de proces de afaceri, şi în acelaşi timp, pentru a se putea ocupa de complexitatea inerentă de a proceselor de afaceri [White 04b] Criterii de piaţă BPMN a fost acceptat în industrie ca notaţie pentru de utilizare şi procesare a modelelor în instrumente produse de vendori. Alternative la BPMN sunt sisteme proprier sau text simplu. Aproximativ 65% din procesul de modelare întreprinse în cele mai multe companii se bazează pe text, şi de multi manageri care folosesc procesul de diagrame grafice de utilizare, utilizează fie PowerPoint fie Visio [Harmon05]. Astfel, este clar că BPMN trebuie să fie evaluat împotriva unui astfel de fond. În Europa, se pare că BPMN este cu siguranţă la toată lumea pe lista de cerinţe. Cu toate acestea, nu a fost îmbrăţişat de către un număr mare de organizaţii încă. Este într-o situaţie similară cu BPEL pentru care numărul de adoptari este încă în fază incipientă. Se asteapta să mai dureze ceva timp înainte de BPMN devine un standard real [Casewise05]. În prezent, BPMN este singura notaţie standard grafica pentru modelare proceselor de afaceri. Nu este probabil să fie înlocuit de către orice alt standard, dar este foarte probabil că va evolua pentru a fi compatibil cu alte standarde ale OMG. BPMN este un standard deschis şi specificatia este disponibila pentru descărcare de pe site-ul OMG. Conform acestui site web, există în prezent peste treizeci de implementări de BPMN. Cele mai multe instrumente sunt produse comerciale, dar sunt disponibile şi unele instrumente open source. De exemplu, M1 Global Convergence Studio, menţionate pe site-ul OMG, este un plug-in Eclipse, pe baza standardului BPMN. BPMN Package of Plugins (proiect Sorceforge) oferă un şablon Visio pentru BPDs folosind BPMN Criterii tehnice BPMN a fost proiectat pentru o descriere stndard bazata pe π-calcul pentru procese de afaceri. Notaţia utilizata pentru BPMN este o notaţie grafică pentru exprimarea proceselor de afaceri într-o Diagrama a Proceselor de Afaceri (BPD), care se bazează pe diagrame tradiţional cunoscute de cei mai multi analişti de afaceri. Texte adnotări pot fi adăugate la oricare elemente ale modelului pentru a oferi informaţii şi detalii suplimentare. BPMN este independent de orice metodologie de modelare proces de afaceri specifice. Tipuri de procese care pot fi modelate Trei tipuri de bază modelul pot fi create cu un BPD [BPMN]. Colaborare (globale) procesele B2B care arată interacţiunea între două sau mai multe entităţi de afaceri. Interacţiunile dintre participanţi sunt definite ca o succesiune de activităţi, reprezentând sabloanelor schimburilor de mesaje între acestia. Aceste procese 30

194 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business sunt aproape de limbajele de coregrafiere şi a fost de aşteptat ca acolo ar fi mapările la diferite limbaje de colaborare, cum ar fi ebxml, BPSS, RosettaNet Limbajul de Coregrafie al W3C (care nu au fost disponibile la lansarea versiunii 1.0). Privat (intern) procesele de afaceri se concentrează asupra activităţilor unei singure organizaţii de afaceri, care, deşi arată interacţiuni cu interne participanţi, nu sunt vizibile pentru public şi sunt astfel activităţi private. Un proces de afaceri privat poate fi mapate la una sau mai multe documente BPEL4WS. Abstract (publice) procese care arată activităţi pe care un proces de afaceri privat le utilizează pentru a comunica cu un alt participant sau de proces, dar nu şi de activităţile interne ale procesului de afaceri privat. Un astfel de proces poate fi mapat la un singur proces BPEL4WS abstract (imposibil în versiunea 1.0 a BPMN). Principalele concepte utilizate BPMN fiind menit să sprijine atât analişti de afaceri, precum şi implementorii de procese, elementele diagramei de elemente în BPMN au fost organizate în două categorii. Nucleul set de elemente permite să fie produse BPDs care sunt familiariare analiştilor de afaceri deoarece sunt bazate pe diagrame de fluxuri. Această gamă cuprinde următoarele elemente: Debit de obiecte: o Evenimentele sunt utilizate pentru a reprezenta faptul că se întâmplă ceva şi, de obicei, au o cauză şi un rezultat şi pot începe, întrerupe sau termina un proces de flux. o Activităţile reprezinta lucrul care se realizează în cadrul unui proces de afaceri, ele pot fi descompuse în sub-activităţi şi sarcini. Ciclarea activtatilor este permisa. Noţiunea de "stare" nu este folosit astfel incat starea unei activităţi nu poate fi modelata. o Gateway modelează decizii de afaceri şi permite branşare, bifurcare, fuzionare şi aderare a drumurilor. Mai multe tipuri de Gateway sunt acceptate, şi se face o distincţie între gateway-xor pe bază de date şi pe bază de eveniment. Obiecte de conectare: o Ordinea curgerii arată ordinea de activităţi într-un proces. o Curgerea mesajelor arată fluxul de mesaje între entităţi. Un mesaj nu este considerat un eveniment în sine; un eveniment este caz primirea sau trimiterea mesajului. o Asocierea asociază informaţii / date, text şi altele cu obiectele flux.. Swimlanes o Bazin reprezinta un participant la proces, astfel încât un set de activităţi pot fi partitionate în diferite bazine. Bazinele pot reprezenta organizaţii, în special a entităţi diferite de afaceri în contexte B2B. o Banda este o sub-partiţie a unui Bazin utilizate pentru a organiza şi categorisi activităţi separate într-un Bazin, de obicei, prin rol sau funcţie. Banda poate reprezenta departamente din cadrul unei organizaţii, precum şi anumite funcţii sau sisteme. Artefact 31

195 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business o Obiecte de date furnizează informaţii despre modul în care documente, date şi alte obiecte sunt utilizate şi actualizate într-un un proces. Ele sunt conectate la Activităţi prin intermediul Asociaţiilor. o Adnotările Text sunt un mecanism care permite unui modelator să furnizeze informaţii suplimentare pentru un cititor de diagramă BPMN o Grupurile furnizează un mecanism de a organiza activităţi şi pot fi folosite pentru scopuri de analiză sau de documentaţie, dar nu afectează ordinea curgerii. Figura următoare oferă un exemplu pentru specificatia BPMN pentru un proces de colaborare de afaceri a folosind elemente grafice de baza. BPDul este uşor de citit şi de elemente de bază sunt adecvate pentru modelatorii care crează modele ale proceselor de afaceri pentru scopuri de documentare şi de comunicare scopuri. Figura 7 Diagrama unui proces de colaborare de afaceri prin specificaţia BPMN Pentru cei care au nevoie pentru a produce procesul de modele la un nivel mai mare de detaliu, în continuare se pot face adăugiri la elemente de bază. Markeri interni, de exemplu pentru Mesaj, Timpul, Excepţie, Anulare, Compensare, Regula, Link, Terminare, şi Multiple, pot fi adăugaţi la Evenimente pentru a arăta tipul de Eveniment (Figura 8). Markeri pot fi adăugate la Activităţi pentru a distinge Buclă, Instanţă multipla, Compensare, precum şi activităţi Ad-Hoc. BPMN pot fi folosite pentru a crea procese de nivel înalt, precum şi procese complexe cu mai multe niveluri de detaliu. Pot să includă procese de instrucţie cu puncte de vedere în nivele mai scăzute de detaliu separate, cu diagrame. 32

196 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Figura 8 Tipuri de markere care pot fi adăugate la evenimente de bază BPMN Specificatiile BPMN se referă la sabloane şi arată cum BPMNurile se pot ocupa de cerinţe de tratare simple şi complexe pentru modelarea proceselor de afaceri. Se pot considera bifurcatii ale curgerii, unirii ale curgerii, divizarea curgerii, instalarea curgerii, şi ciclari, precum şi un flux de excepţie. [White04a] a investigat măsura în care Diagrama BPMN a proceselor de afaceri (şi în UML 2.0 Diagrama de Activitate) poate reprezenta modele de flux de lucru elaborate de van der Aalst et al [Aalst03c]. Pentru fiecare sablon, cele două notations sunt comparate cât de bine tratează sablonul. Este arătat că fiecare sablon poate fi reprezentat în mod adecvat de către BPMN, deşi [Wohed05] consideră că există anumite probleme cu soluţia propusa şi că anumite limitări ale BPMN exista când întreaga gamă de modele este examinata. Figura 9 arată că fluxul este folosit ca un exemplu ilustrativ în [BPMN] pentru caracteristicile extinse ale BPMN. 33

197 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Figura 9 Un exemplu de specificaţie BPMN Tratarea erorilor, tranzacţii, asistenţă la compensare Tratarea excepţiilor este posibilă; evenimente intermediare ataşate la limita unei activităţi reprezintă generatoare ca început de activitate. Lucrul în activitate va fi oprit şi se va continua fluxul de la Eveniment. Se pot genera cronometre, excepţii, mesaje, etc. O Tranzacţie este o activitate descrisa de o frontieră dubla. Diverse fluxuri pot fi modelate, pentru o permite finalizarea cu succes a tranzacţiei, o anulare de finalizare, sau o excepţie de tranzacţie cauzând eroare. Compensarea este, de asemenea, sprijinita, atunci când este nevoie să se revina la unele dintre activităţi prin activităţi care invocă anularea efectelelor activitate initiale. Activităţile utilizat cu markerul de compensare sunt în afara fluxului normal al procesului şi sunt considerate a fi activităţi normale asociate. Extensibilitate BPMN este extensibil. În speciificatii se afirmă că: "Extensiile pot fi făcute în elementele Diagrama prin noi markeri sau indicatori markeri asociaţi cu elemente grafice curent. Aceşti markeri sau indicatori ar putea fi utilizaţi pentru a evidenţia un anumit atribut al unei activităţi pentru a crea un nou tip de eveniment, de exemplu. În plus, Extensiile ar putea include, de asemenea, un obiect de colorat sau a schimba o linie de stil a unui obiect, cu condiţia că nu trebuie să între în conflict cu orice linie de stil BPMN definita anterior.... Orice număr de artefacte, constând dintr-o varietate de forme, poate fi adăugată la o 34

198 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business diagrama, cu condiţia ca forma artefactul nu trebuie să între în conflict cu orice alta forma de obiect sau marcator deja definit." [BPMN] [White05a] introduce pictograme, care nu sunt parte a notaţie standard BPMN pentru a demonstra extensibilitatea BPMN. Aceasta înseamnă că modelatorii pot crea artefacte necesare pentru scopul lor specifice, posibil adăugand mai multe detalii la o activitate care este în curs de efectuat. Maparea la BPEL4WS Specificaţia BPMN oferă o mapare la BPEL4WS versiunea 1.1 pentru a arăta cum obiectele BPMN şi relaţiile dintre aceste obiecte pot fi mapate la BPEL4WS. Deşi BPMN nu poate fi considerat aproape de un limbaj de coregrafie mai mult decât un limbaj de orchestraţie, nu a existat nici un limbaj de coregrafie de disponibil atunci când a fost elaborat specificatia. Când o mapare este considerata terbuie decis unde să fie mapata la un format BPEL4WS bazat pe structura grafica BPEL4WS (elementul flux), sau pe structura BPEL4WS bloc (element de ordine). Specificatia BPMN adoptă o abordare de mapare la elementele BPEL4WS în principal folosind elemente şi structuri de bloc, iar în [White05a] este adoptata o structura de tip graf pentru mapare. Anexa A a specificatiei prevede codul complet BPEL4WS cod pentru exemplul din corp principal a specificatiei. Nu tot BPMN poate fi descris în BPEL4WS deci este posibil să se reprezinte procese în BPMN care nu pot fi mapate la BPEL4WS. Cu toate acestea, maparea la BPEL4WS nu este întotdeauna necesara deoarece un proces de afaceri nu este neapărat destinat a fi puse în aplicare ca un proces automatizat de afaceri într-un limbaj de executie a proceselor. Ea poate fi produsă la începutul procesului de design al software-ului pentru a înţelege cerinţele privind designul sistemul Aplicabilitate BPMN oferă un standard de notatie grafică pentru modelarea proceselor de afaceri. Nu are nici o alt concurent ca standard, exceptand instrumentele proprietate. Ca o notaţie de modelare pentru afaceri, este aplicabil la SCIPA pentru acele zone de lucru în care o astfel de notaţie este necesară. Este clar compatibil cu BPEL (4WS) şi exists o serie de instrumente software, care permit ca realizarea maparii în mod automat Rezumat Avantaje BPMN este singura notaţie standard grafica pentru modelarea de procese de afaceri. Este destinat să permita atât la nivel înalt de afaceri procesul de proiectare, precum şi acordarea de asistenţă pentru modelarea procese de afaceri mai complexe, cat şi maparea la un limbaj de executatie. Este destul de intuitiv pentru acei analişti de afaceri cu cunoştinţe privind notaţia grafică a procesului tradiţional de afaceri şi în acelasi timp permite construirea de procese complexe. Ea se extinde mai mult decât notatiile tradiţionale de afaceri în multe privinţe, nu numai legat de maparea la un limbaj de executie, dar sprijina de asemenea conceptul de proces B2B, inclusiv procese publice şi private, precum şi interacţiunele între două entităţi de afaceri. Se permite, de asemenea, tratarea excepţiilor, operaţiuni de compensare. 35

199 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Un alt punct forte al BPMN este suportul său pentru trimite mesaje de modelare între două entităţi. BPMN poate, de asemenea, descrie fluxurile de mesaje şi oferă o notaţie de obiecte de date care pot fi asociate cu activităţi. Spre deosebire de cele mai multe notatii pentru procesele de afaceri BPMN permite obiectelor de date să fie reprezentate şi modelatorii pot arată cum datele, documentele şi alte obiecte sunt folosite şi actualizate în timpul unui flux al procesului. Odată cu creşterea cererii de modelare a procesului de afaceri tip B2B, BPMN creste în semnificaţie. Cum un procesul de modelare de afaceri este implicat în tratarea datelor în cauză, BPMN oferă un avantaj faţă de alte notatii în cazul în care modelatorii trebuie să utilizeze soluţii sau faca presupuneri în care sunt implicite necesitati. BPMN nu este, totuşi, o notaţie pentru diagrame de flux de date. Modele de date şi informaţii nu sunt incluse în specificatii. Specificatia BPMN oferă o mapare la BPEL4WS şi o serie de instrumente sunt disponibile pentru a suporta aceasta mapare, care permite astfel ca BPMN să fie utilizat întrun lanţ de instrumente. Aceasta este în mod important pentru mediul SCIPA. Deoarece BPMN este parte a OMG, link-uri sale către alte specificaţii şi standarde vor fi consolidate. Dezavantaje Specificaţia nu prevede un metamodel sau de un mecanism de schimb al diagramelor. A fost destinat pentru a defini acest mecanism într-o etapă ulterioară [BPMN]. Acest lucru face dificil schimbul de modele între instrumente de lucru BPMN şi pot conduse la probleme severe atunci când o varietate de instrumente este utilizat de către diferiţi modelatori. Decizia de a dezvolta BPDM ca un metamodel pentru BPMN [Frankel06] va consolida poziţia şi această slăbiciune speciala va fi eliminata. BPMN nu oferă o notaţie pentru reprezintarea arhitecturii organizatorice la nivel de proces. Structurile organizaţionale şi de resurse, strategie, rolurile în afaceri sunt în mod specific excluse din domeniul de aplicare a standardului şi luate în considerare ca o problemă deschisă pentru a fi rezolvata. Nu există nici o schemă XML asociata cu BPMN. Specificaţia BPMN ca un nivel limbaj XML deasupra limbajelor de exceutie BPM a fost considerată o problemă deschisă în continuare pentru studiu. Recomandări Ca un standard de notatie grafica în modelarea proceselor de afaceri, el poate fi recomandat pentru utilizare la SCIPA în fazele timpurii ale sistemului de proiectare. Coregrafia acestor procese de afaceri pot fi specificate folosind notaţia BPMN. 2.3 Concluzii Acest capitol a evaluat patru standarde din domeniul metodologiei de modelare şi de notaţia grafică. Informaţiile furnizate în fiecare dintre secţiunile a oferit o bază pe care să facă o recomandare cu privire dacă adoptarea standardelor pentru mediul SCIPA. UMM este o tehnologie puternica de modelare pentru procese de afaceri şi modele de informaţii şi este un standard deschis. Acesta a fost dezvoltat în mod specific pentru construcţia de procese de afaceri şi modele de informaţii şi este bazat pe UML 1.x. A fost adoptată de către diferite grupuri de utilizatori din industrie, dar nu este bine susţinut de instrumente şi cunoştinţele despre UMM nu sunt larg răspândite. Este considerat complex şi 36

200 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business necesită un nivel ridicat de expertiză pentru a-l utiliza. Prin urmare, nu este recomandat pentru utilizare la SCIPA. UML este un limbaj orientat-obiect pentru modelare de la OMG pentru specificarea, vizualizarea, documentarea şi de modelarea de sisteme software. Este un standard deschis care a evoluat în ultimii ani, iar versiunea 2.0 este în curs de adoptare de către furnizorii de instrumente. A devenit satndardul de facto pentru modelare aplicabil la orice proiect de dezvoltare software, iar cunoştinţele de UML sunt larg răspândite. În modelarea proceselor de afaceri pentru SCIPA, Diagrama UML de Activitate este de interes deosebit, în special pentru coregrafia în modelarea proceselor de afaceri. Prin urmare, este recomandat pe tot parcursul ciclului de viaţă SCIPA în dezvoltarea software. BPDM este un standard deschis oferind un model abstract de modelare pentru procesele de afaceri care este dezvoltat de către OMG. Acesta a fost în curs de dezvoltare pentru o vreme, aparent cu întârziere datorate discutiilor dacă ar trebui să se bazeze pe UML, BPEL sau BPMN [Frankel06]. BPDM este de interes special pentru a SCIPA ca un potenţial metamodel pentru BPMN. Cu toate acestea, standardul nu poate fi recomandat pentru mediul de lucru SCIPA curent, fiind încă în curs de dezvoltare şi nu există instrumente de sprijin. BPMN este o notaţie standard grafica şi deschisa pentru procesul de modelare de afaceri care a fost dezvoltat de BPMI, acum fuzionat cu OMG. El se bazează pe binecunoscuta noatie flowchart şi, astfel, este destul de intuitiv pentru analiştii de afaceri. Specificatia prevede, de asemenea, o notaţie pentru mai multe procese complexe şi o mapare la BPEL (4WS), care îi permite să fie folosit în primul pas în procesul de dezvoltare a ciclului de viaţă. Exista instrumente de sprijin, în special pentru mapare la BPEL, dar, de asemenea, pentru XPDL, de asemenea de interes pentru SCIPA. Prin urmare, poate fi recomandat pentru utilizare ca notatie grafica la SCIPA pentru etapa de design a procesului de afaceri, în special, în modelarea coregrafiei proceselor de afaceri. 37

201 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business 3 Limbaje de coregrafie Standardele pentru compunerea serviciilor pot să fie considerate ca fiind în conexiune cu [Barros05b]: coregrafia - aceasta contine procese care colaborează (colaborative) implicand diferite servicii iar interactiunile dinter aceste servicii pot fi vazute dintr-o perspectiva globala. interfaţa de comportament (care poate să fie considerata ca fiind un proces abstract în BPEL şi ca un profil de protocol de colaborare în ebxml) capturează dependentele comportamentale dintre interactiunile care permit ca un anumit serviciu să fie utilizat; orchestratia (proces executabil în BPEL) - operează cu descrierea interactiunilor generate prin care un anumit serviciu poate fi implicat precum şi cu descrierea activităţilor interne care permit aceste interactiuni (ca de exemplu prezentarea datelor în anumite formate, etc.). 3.1 Orchestrare versus coregrafie Vom prezenta pe scurt orchesraţia şi coreografia [Pelz03]. Orchestratia prezinta modalitatea în care serviciile Web opt interactiona unul cu altul la nivel de mesaj, incluzand logica procesului şi ordinea de executie a interactiunilor din perspectiva şi sub controlul unic al unui singur participant. Orhestratia se refera la un proces executabil care deriva dintr-un model de proces de lunga durata, tranzactional, multi-step. Prin orchestratie, interactiunile procesului sunt controlate intotdeauna din perspectiva (particulara, privata) a uneia dintre partile implicate în proces. Coreografia se ocupa cu schimburile de masaje publice (global vizibile), reguli de interactiune şi consensuri care trebuiesc realizate între mai multe procese (intre mai mulţi parteneri). Coreografia urmareste (coordoneaza) secventa de mesaje care pot implica mai multe părţi şi mai multe surse, incluzand clienti, furnizori şi parteneri unde fiecare parte implicata în proces prezinta (descrie) partea care o joaca în interactiune (si nu propriile actiuni). Coreografia scoate în evidenta (ilustrează în esenta) colaborările. Ea descrie din perspectiva tuturor partilor (viziune comuna) şi defineste în esenta a starilor de interactiune (partajate în comun) dintre entitatile procesului. Aceasta viziune comuna poate fi utilizata pentru a determina dreularea implementarii pentru fiecare entitate individuala. Coreografia ofera o modalitate prin care regulile de participare ;a colaborare pot să fie clar definite şi agreeate de catre toate partile. În acest fel fiecare entitate poate să-şi implementeze propria parte de coregrafie rezultata din viziunea comuna. Un model de tip coregrafie trebuie să descrie colaborarea dintre o colectie de servicii care să permita realizarea (atingerea) unui anumit obiectiv. Ea caracterizează interactiunile în care serviciile participante se implica pentru a asigura realizarea acestui obiectiv şi dependentele dintre aceste interactiuni inclusiv dependentele de control pentru flux (ordinea succesiunii realizarii interactiunilor), dependentele impuse de fluxul datelor, de corelare a mesajelor, restrictii de timp depente tranzactionale şi altele [Barros05a]. 38

202 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Evident ca prin coregrafie nu sunt descrise interactiunile interne care se realizează intrun serviciu implicat (ca exemplu prelucrari-calcule interne) şi care nu au un efect vizibil în exterior. Coregrafia capturează interactiunile dintr-o perspectiva globala, fiecare participant fiind tratat în mod normal, fără preferinte. Coregrafia cuprinde toate intractiunile dintre serviciile participante care sunt relevante cu obiectivul coregrafiei. Un punct de vedere particular dar foarte important consideram ca este urmatorul. În coregrafie trebuiesa se accentueze interactiunea procesului cu serviciila care-i asigura realizarea obiectivului. O coregrafie este o comuniune (intelegere) dintre o multime de părţi prin care se reda modalitatea în care o anumita colaborare trebuie să se realizeze. 3.2 Interfaţa comportamentală Trebuie ca interfaţa comportamentala să fie conceputa într-o conexiune strictă cu coregrafia. Interfaţa comportamentala vine să completeze descrierile interfetei sructurale inter care cele suportate de WSDL care capturează interactiunile elementare în care un serviciu poate fi imlicat, tipurile de mesaje şi politicile care guvernează schimburile de mesaje în special în ceea ce privete securitatea şi siguranta. Capturarea aspectelor comportamentale ale interactiunilor cu un anumit serviciu care este solicitat să contribuie la realizarea obiectivului se realizează prin interfaţa comportamentala. Trebuie accentuat faptul ca interfaţa comportamentala capturează dependentelednter interactiuni: controlulu fluxului, constrangerile de timp, corelareal mesajelor şi dependentale tranzactionale. În absenta coregrafiei, interfaţa comportamentala se concenterază asupra perspectivei doar din partea unui participant la intercomunicare, în consecinta ea nu recceptionează interactiunile în totalitatea lor. Figura 10 Interfaţa comportamentală pentru o cerere 39

203 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Este deosbit de important să se tina cont de relatia coregrafie interfaţa comportamentala pentru a avea certitudinea corectitudinii în executie. Figura 11 Interfaţa comportamentală pentru o comandă (o poziţie dintr-o comanda) 40

204 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Figura 12 O alternativă pentru interfaţa prezentată în Figura 11 Într-o colaborare de tip B2B un rol într-o coregrafie poate fi asociat cu interefete comportamentale multiple şi în consecina şi interfete WSDL multiple. Avand o coregrafie şi un rol în aceasta, va terbuie să fie definite un numar arbitrar de interfete comportamentale care vor trebuie să se coreleze cu constrangerile impuse de coregrafie pentru acel rol. 3.3 WS-CDL WS-CDL este un limbaj exprimabil în XML pentru a compune colaborări interoperabile, de lunga durata, peer-to-peer între orice tip de "părţi" fără a tine cont de platforma sau modelul de programare utilizat pentru implementarea la mediul care gazduieste. WS-CDL viziunea globala a schimbului de mesaje ale tururor serviciilor (web) participante care sunt implicate în colaborarea din proces. 41

205 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Figura 13 Nivelele WS-CDL WS-CDL este un limbaj reprezentabil pe nivele [Ross-Talbot04]. El asigură diferite nivele pentru a decrie capacitatea de exprimare a unei ontologii. La cel mai inalt nivel pentru orice WS_CDL este un package care contine toate celelalte elemente. Toate coreografiile descrise în WS-CDL trebuie să includă un set minimal de roluri care sunt definite ca o modalitate de comportare reprezentand astfel notiunea nunui serviciu în WS-CDL. Relatiile între aceste roluri, canalele utilizate de roluri pentru a interactiona şi un bloc al coregrafiei care foloseste canalele pentru a descrie interactiunea. Figura 13 prezintă structura pe nivele a WS-CDL. Prin utilizare WS-CDL se defineste un contract care contine o definire a conditiilor comune de ordonare şi constrangeri prin care sunt schimbate (transmise) mesajele; acest contract descrie din punct de vedere global comportarea "complementar" observabila a tuturor partilor implicate. Fiecare parte poate în consecinta să utilizeze definitia globala şi să testeze solitiile care se conformează cu aceasta. WS-CDL se utilizează strict numai pentru "procese abstracte" independente de platforma şi de limbajele de programare care snt utilizate pentru implementarea participarii serviciilor. În specificatia WS-CDL schimburile de mesaje se realizează în cadrul unui set de reguli şi constrangeri în comun acceptate. Defintiile unei coreografii pot implica doi sau mai mulţi participanti. WS-CDL descrie o viziune generala a schimburilor de mesaje fără a lua în considerare nici un punct de vedere al verunui participant, pe cand în BPEL un proces abstract rperzinta punctul de vedere al unui participant. WS-CDL (ca de altfel şi BPEL) seste o specificatie de infrastructura care nu contrine semantici de proces (resurse, conventii, intelegeri, etc.). O definite de coregrafie în WS-CDL este intotdeauna o definitie abstracta de "roluri" care ulterior vor fi atribuite "participantilor". Rolurile sunt legate între ele (unul cu altul) prin "relatii" O relatie se defineste exact între doua roluri. Un participant poate implementa orice număr de roluri care nu sunt în opozitie cu el, în coregrafie. Exemplu: un distribuitor poate 42

206 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business implementa rolurile: "cumparator_la_fabricant" şi "vanzator_la_client".care sunt diferite de rolul "vanzator_la_distribuitor". Rolurile în WS-CDL sunt relativ similare cu <partnerlink> din BPEL. Un document WS-CDL este constituit dintr-un set de definitii. Definiţiile se numesc constructii şi pot fi referite.în radacina exista un element <package> şi coreografia individuala este definita în el. Un package WS-CDL contine un set de una sau mai mylte coreografii şi una sau mai multe definitii de tipuri de colaborare. Constructia unui package WS-CDL permite agregarea unui set de coreografii. Elementele de bază şi structura WS-CDL se pot regasi în draftul WS-CDL v1.0, 22 Septembrie 2004 şi sunt prezentate în Figura 14 [WS-CDL04]. Figura 14 Elementele şi structura WS_CDL Descrierile pentru coregrafia în WS-CDL asigura o viziune globala (sau nepartinica) a interactiunilor dintre doua sau mai multe parti. Serviciile web care pto fi dezvoltate de mai mulţi furnizori. Modalitatile de utilizare în combinatie cu alte servicii nu pot să fie descrise prin WSDL. Obiectivul propus de Grupul de lucru 4 este acela de scoate în evidenta necesitatea unor mijolace general acceptate cum pot să fie utilizate serviciile web atat individual cat şi în combinatii unul cu altul pentru a realiza obiectivele propuse. Obiectivele WS_CDL sunt acelea de a defini contractele multi-parti, care derscriu comportarea externa care este vizibila a serviciilor web şi clientii lor (alte servicii web) prin 43

207 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business descrierea schimburilor de mesaje dintre ele. Ca obiectiv general este acela prin care coregrafia WS-CDL să fie utilizata pentru a genera scheltoane de cod pentru servicii web sau procese abstracte BPEL. O descriere a coregrafiei WS-CDL este continuta intr-un pachet şi formează în esenta un container pentru o colectie de activităţi care pto să fie executate de catre unul sau mai mulţi participanti. În WS-CDL exista trei tipuri de activităţi (Figura 15): de control al fluxului, untiaţi de lucru şi elementare. Figura 15 Activitaţi în WS-CDL Cel mai important element al WS-CDL este activitatea de interacţiune. O interacţiune descrie un schimb de informaţie inter-părţi concentrată spre receptorul de informaţie. Interacţiunile au trei obiective: să emita o cerere (request) să emita un raspuns (respond) sau să emita o cerere care la randul său solicită un raspuns (request-respond). O descrierea a activităţii de interactiune are în consecinta trei părţi care corespund: participanţii implicati informaţia care trebuie comunicată canalul pentru comunicarea informaţiei. În Figura 16 sunt prezentate doua activităţi de tip interacţiune aferente Figura 11. De reţinut este faptul că descrierea activităţilor în WS-CDL este orientata mai mult spre receptor decât spre emitor. Rolorile emitorului şi receptorului şi relatiile dinter acestea sunt redate explicit în partea de "participare" a descrierii interactiunii. Este de asteptat ca receptorul să execute cu informaţia pe care o primeste ceea ce trebuie. 44

208 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Figura 16 Exemplu de interacţiune în WS-CDL Variablilele în WS-CDL sunt utilizare pentru a reprezenta: informaţii dependente de aplicatie, informaţie de stare şi informaţie referitoare la canal. Variabilele au un tip specific. Variabilele canal sunt de tip canal. O descriere de tip canal indică rolul receptorului pe care-l joacă şi ce comportare are pe acest canal. Comportatile rolurilor sunt descrise (opţional) prin interfeţele WSDL. 45

209 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Figura 17 Exemplu de tip canal în WS-CDL Variabilele care sunt utilizate în activităţile coregrafiei sunt descrise în definitia coregrafiei, deci domeniul lor de (existenta)valabilitate este la nivelul coregrafiei. Aceste variabile de cu domeniul mare (coregrafie) pot să fie accesate sau utilizate în comun cu coregrafiile apelate utilizand mecanismul de legare în activitatea de executat Concluzii Una dintre cerintele WS-CDL este aceea de a sigura un sens pentru instrumentele care validează conformitatea cu descrierile coregrafiei pentru a asigura interoperabilitatea între serviciile web. Sunt necesare validari referitoare la prorietaitle de a fi vie (live), dealock sau pentru a asigura le executie conformitatea comportarii participantilor în conformitate cu panul coregrafiei. Pentru aceasta WS-CDL are la bază conteptele din pi-calculus [Milner99]. Pentru a asigura realizarea compunerii serviciilor web, WS-CDL utiliează WSDL, WSDL- MEP (Message Exchange Patterns), WS-Reliable-Messaging. În general desrierile coregrafiei prezinta într-o modalitate abstracta la un nivel mai inalt, în termeni de capabilitate, iar la momentul executiei va trebui realizata selectionarea participantilor în coregrafie care vor fi capabili să satisfaca acea capabilitate chiar restrangand participarea în coregrafie a participantilor, utilizand pentru aceasta o interfaţa în WSDL sau operatii WSDL. De o mare importanta este consistenta semantica a coregrafiei globale şi a orchestrarii proceselor locale. Definitia coregrafiei introduce ordonarea (emiterii) mesajelor şi constrangerile vizavi de vederile interfetei proceselor locale prezente în orchestratie. 46

210 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business 3.4 Detalii coregrafie Coreografia se compune din activităţi. Principala activitate este "interacţiunea" şi constituie blocul constructiv fundamentatal unei coreografii, care rezulta din schimbul de mesaje dintre participanti, sincronizarile posibile dinter starile lor şi valorile actuale ale informaţiei schimbate. Interactiunile precizează legatura între schimburile de mesaje dintre roluri. O interactiune corespunde apelarii unui serviciu Web care operează asupra unui rol. Ca urmare, o interactiune este definita ca o cerere ci zero sau mai multe raspunsuri. Interactiunile pot implica activităţi de ordonare (secvente, paralele, alegeri) sau pot compune o alta coregrafie în cadrul coregrafiei parinte. Definitiile coregrafiei pot fi conduse de date (data-driven) adica, datele continute în mesaje avand impact asupra ordonarii. Datele sunt modelate ca şi "variabile" care pot fi asociate continutului mesajelor, un "canal" sau "starea" rolului implicat în coregrafie. "Jetoanele" (tokens)sunt alias-uri care por reprezenta partile unei varabile. Jetoanele sunt corelate cu conceptul prorietatii într-o multime de corelatie din BPEL. În concluzie, o coregrafie poate să fie utilizată pentru mai multe obiective: sa genereze interfaţa comportamentala în asa fel incat fiecare serviciu participant să poata participa la o (într-o) colaborare. Interfaţa comportamentala generata poate fi utilizata pe durata dezvoltarii serviciului. pe durata proiectarii să se verifice dacă interfaţa comportamentala a unui serviciu se conformează unei coregrafii şi astfel dacă serviciul în cauză este capabil să joace un rol în aceasta coregrafie. În mod similar o interfaţa comportamentala poate fi utilizata ca un punct de pornire pentru a genera un schelet (cadru) pentru o orchestratie., care va fi definitivata cu detalii. Pe de alta parte, o orchestratie existenta poate fi verificata de consistenta fata de o (printr-o) interfaţa comportamentala existenta. În acest fel se pot scoate în evidenta situatiile în care o orchestratie data nu trmitie mesajele în ordinea în care acestea sunt asteptate de catre alte servicii. Interfaţa comportamentală prezentată în Figura 12 va putea fi utilizată în locul uneia din Figura 11 în contextul coregrafiei folosite ca şi exemplu. Interfata comportamentala prezentata ca şi alternativa va avea aceeasi comportare ca şi cea din Figura 11, spre exemplu mesajul de anuare a comenzii (ordinului) nu va fi transmis ncicodata unui participant care joaca un rol de furnizor, datorita modului în care fost conceputa coregrafia. Procesul pentru onorarea comenzii unui producator de catre furnizor din perspective coregrafiei, este ilustrat în Figura

211 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Figura 18 Coregrafia unui model de proces Figura 19 Procesul de onorare a unei comenzi din perspectiva coregrafiei 48

212 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business 3.5 SOA Arhitecturile orientate pe servicii permit realizarea controlului şi gestiunii proceselor atat interne companiei cat şi celor între parteneri [Decker06]. Serviciile sunt utilizate ca să execute taskuri între procese.coreografia reperzinta protocolul de interactiune dintre mai mulţi parteneri (de afaceri). S-au facut eforturi pentru a identifica cele mai utile şi frecvente scenarii din prosepctiva procesului finalizate în Service Interaction Patterns [Barros05b]. Sabloanele sunt prezentate dupa nuarul de participanţi implicaţi în interactiune, dupa nuarul de schimburi, dupa necesitatile de rutare sau dupa cerinta de a primi sau nu raspuns. [Brogi04], [Busi05] şi [Gorrieri05] analizează formalismul coregrafiei pentru serviciile web unele dintre ele utilizand algebre de proces, afirmand inttre altele ca pi-calculus nu este necesar pentru descrierea coregrafiilor serviciului şi ca retelele Petri nu sunt adecvate în acest scop, ultimele, ne putand reprezenta în totalitate sabloanele pentru workflow, recurgandu-se la elaborarea unor instrumente mai adecvate, Yawl [Aalst03]. Lucrările mentionate anterior ca de altfel şi WS-CDL, iau în considerare numai interactiunile simple: într-o singura directie şi cea cu cerere-raspuns. În pi-calculus [Barros05a] un mesaj este reprezentat printr-un nume şi este transmis sincron şi receptionat, rezultand o interactiune (procesul care doreste să transmita un mesaj se blochează pana cand procesul receptor primeste mesajul).în pi-calculus se considera comunicarea sincrona ca fiind sigura şi livrarea mesajului fiind cazul implicit. Coreografia prezinta sabloanele utilizate de interfaţa unui serviciu web. Aceste sabloane prezinta modalitatea în care cunsumatorul va interactiona cu interfaţa serviciului web. O problema o constituie modelarea coregrafiei independent de definirea workflow-ului pentru care este utilizata. Independenta conduce la doua probleme[haller06], [Haller06a]: daca orice modificare oaapre în workflow-ul intern, coreografia trebuie să fie sincronizata manual cu definitia worflw-ului; nu exista posibilitatea de a verifica automat consistenta descirerii workflow-ului intern cu interfetele (externe) ale coregrafiei. Ca şi exemplu, în Figura 20 unde este reprezentată o colaborare în RosettaNet şi un model de proces reprezentat printr-o diagrama de activtaţi în UML. Activităţile publice sunt prezentate în negru iar activităţile private în alb. Coreografia distribuitorului (seller) este formata din activităţile prezentate în negru în culoarul drept iar coreografia cumapratorului prin activităţi în negru în culoarul din stanga. Pentru a putea extrage automat interfaţa pentru coregrafie procesul intern trebuie să contina informaţii necesare pentru procesele externe cu care el colaboreaza. 49

213 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Figura 20 Exemplu de colaborare RosettaNet 50

214 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business 4 Limbaje de orchestrare Într-o arhitectură software care îşi propune să elaboreze un mediu bazat pe servicii Web (interne şi externe) care interacţionează între ele, termenul de orchestrare a fost introdus pentru a descrie fluxul acestor comunicaţii ca un proces business multi-pas, long-lived din punctul de vedere al unui partener. Limbajele utilizate pentru a scrie aceste procese într-un mod în care sistemele software (adică motoarele de execuţie) le pot executa se numesc limbaje de orchestare. În ultimii 15 ani s-au depus multe eforturi în domeniul limbajelor de orchestrare. Printre primele propuneri se numără XLANG, proiectat de Microsoft pentru BizTalk Server sau WSFL propus de IBM. Aceste două limbaje au fost înlocuite de către BPELWS creat de către Microsoft împreună cu IBM şi BEA. O altă direcţie urmată a fost cea propusă de WfMC care a rezultat în publicarea limbajului XPDL versiunea 1.0 în 2002, iar pentru a fi pe deplin compatibil cu BRMN, acesta a evoluat la versiunea 2.0 în În aprilie 2008, WfMC a ratificat XPDL 2.1 care suportă BPMN 1.1. Cea de-a treia importantă iniţiativă în domeniul standardelor de orchestrare a fost creată de către OASIS, UN/CEFACT şi câteva corporaţii comerciale precum Intel şi SAP şi a dus la publicarea familiei de standarde ebxml, cu CPPA pe post de limbaj de orchestrare. Versiunea 2.0 a fost aprobată ca standard ISO Scopul acestui capitol este de a trece în revistă şi de a compara standardele de orchestrare cu scopul de a recomanda cele mai potrivite limbaje de orchestrare în cadrul proiectului SCIPA. Fiecare dintre limbajele analizate va fi descris succint şi a fost evaluat pe baza unor criterii de piaţă şi tehnice. Tabela 1 prezintă criteriile de piaţă utilizate pentru evaluarea standardelor de coregrafie şi orchestrare. Criteriu de piaţă Disponiblitatea unei versiuni stabile, mature a specificaţiilor Implementări open-source / comerciale disponibile Standarde înlocuitoare Evoluţia specificaţiilor Compatibilitate cu versiuni anterioare Standard deschis Experienţa consorţiului Explicaţie Specificaţia este acceptată de organizaţie Existenţa unor implementări open-source sau comerciale Acest standard a fost înlocuit de alte standarde Standardul va fi înlocuit de o versiune a altui standard Standardul este compatibil cu versiunile anterioare Standardul este disponibil şi poate fi utilizat gratuit Membrii consorţiului SCIPA cunosc şi au folosit/folosesc acest standard Tabela 1 Criteriile de piaţă utilizate la evaluarea standardelor de orchestrare 51

215 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Tabela 2 sumarizează criteriile tehnice folosite pentru evaluarea standardelor de orchestrare, cu explicarea semnificaţiei fiecărui criteriu. Primele criterii tehnice sunt similare cu cele folosite la coregrafie, în timp ce ultimele sunt specifice orchestrării. Criteriu tehnic Elemente de control (loop, choice, etc) Fire de execuţie paralele Suport pentru structuri precum module/procese Suport pentru subfluxurilor (subflows) Structuri complexe Fluxul de date Compatibilitate cu WSDL Compatibilitate cu BPMN Selectarea binding-urilor / endpoint-urilor Suport pentru tratarea erorilor Suport pentru compensare Suport pentru procesarea tranzacţiilor Suport pentru interacţiunea cu roluri / utilizatori umani Exceutabil Definiţie formală Extensibilitate Independent de platformă Securitate Constrângeri legate de timing Calitatea serviciilor / prioritizări Suportă conceptul programming-in-the-small Explicaţie Prezenţa elementelor de control specifice limbajelor de programare Se pot specifica fluxuri paralele de activităţi Suport pentru elemente reutilizabile, precum modulele, procese predefinite Permite folosirea subfluxurilor Permite specificarea şabloanelor de flux complexe precum şi structuri de date complexe Se pot specifica fluxuri de date în cadrul proceselor Standardul este compatibil cu WSDL Standardul este compatibil cu BPMN Permite specificarea protocoalelor şi punctelor de conexiunea pentru comunicaţii de nivel jos Permite specificarea comportamentului în cazurile de eroare Permite specificarea compensării comportamentului eronat Suportă comnucaţii tranzacţionale, de exemplu proprietăţi tip ACID În plus faţă de servicii implemetate ca procese, interacţiunea cu operatorii umani este suportată Un fişier pregătit poate fi executat de către un motor (engine) Notaţia folosită, de exemplu scheme XML Permite adăugarea de elemente noi, nestandard Standardul nu este dedicate unei platforme hardware sau software Mecanismele de securitate sunt parte a standardului Permite specificarea constrângerilor legate de timing (de exemplu timeouturi) Permite prioritizarea task-urilor Permite executarea în timpul unui flux a unei bucăţi de cod scrisă într-un limbaj de programare Tabela 2 Criteriile tehnice utilizate la evaluarea standardelor de orchestrare 52

216 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Aceste criterii sunt folosite pentru fiecare standard analizat în acest capitol astfel încât cititorului îi este oferită o imagine de ansamblu care pune în evidenţă plusurile şi minusurile fiecărui standard. Pentru toate criteriile care presupun un răspuns binary, s-au folosit următoarele notaţii: + standardul satisface criteriul - standardul nu satisface criteriul 0 standadrul satisface criteriul părţial na crieteriul nu se aplică pentru acest standard Există de asemenea criterii care necesită un răspuns textual, de exemplu care standarde au fost înlocuite sau vor fi înlocuite de către standardul evaluat. 4.1 Web Services Business Process Execution Language (WSBPEL) Standardul Web Services Business Process Execution Language WSBPEL, sau BPEL4WS cum a fost numit în primele sale versiuni, a fost introdus de către BEA, IBM şi Microsoft. BPEL4WS versiunea 1.0 a ieşit pe piaţă în iulie 2002 şi a fost o combinaţie între limabjele WSFL (propus de Microsoft) şi Xlang (propus de IBM) [BPEL4WS10]. În aprilie 2003, un comitet tehnic a fost fondat în cadrul OASIS compus din BEA Systems, IBM, Microsoft, SAP şi Siebel Systems cu scopul de a continua dezvoltarea idei BPEL4WS. Versiunea 1.1 a fost publicată în mai 2003 [BPEL4WS11]. În continuare, în septembrie 2004, comitetul a decis să schimbe denumirea noii versiuni în lucru (draft) a standardului la WSBPEL 2.0. Modificarea numelui şi a versiunii reflectă diferenţele semnificative, şi în multe cazuri incompatibile, între BPEL4WS 1.1 şi WSBPEL 2.0 [BPEL_WIKI]. WSBPEL 2.0 este ultima versiune a standardului şi este accesibilă aici [BPEL_oasisIntro]. În iunie 2007, Active Endpoints, Adobe, BEA, IBM, Oracle şi SAP au publicat specficaţiile pentru BPEL4People şi WS-HumanTask care descriu modul în care poate fi implementată interacţiunea cu utilitzatorul uman în procele BPEL. WSBPEL 2.0 este un limbaj deschis, bazat pe XML, pentru specificarea formală a proceselor de business, precum şi a protocoalelor de interacţiune business. Astfel, fiecare organizaţie care suportă BPEL poate efectua unul sau mai mulţi paşi ai proceselor de business în acelaşi mod. Standardul defineşte un model de integrare interoperabil care ar trebui să permită expansiunea integrării proceselor automate atât în spaţiul intra-corporaţie cât şi în spaţiul business-to-business [BPEL_santeon]. WSBPEL 2.0 suportă atât conceptul programming-in-the-large1 cât şi programming-inthe-small. Logica generală a procesului poate fi implementată folosind programming-in-thelarge, care le permite analiştilor de business să-şi exprime ideile într-un mod formal, fără a fi implicaţi în detaliile tehnice. Problemele arhitecturale şi detaliile de programare sunt tratate de către programatori folosind abordarea programming-in-the-small. 1 Programming-in-the-large se poate referi cod program ce reprezintă tranziţiile de stare de nivel înalt într-un system informatic.această logică codifică informaţii precum momentul când se aşteaptă mesaje, când se trimit mesaje, când se compensează tranzacţiile non-acid (Atomicity, Consistency, Isolation, and Durability) care au eşuat etc. Programming-in-thesmall tratează comportamentul de scurtă durată, deobicei executat ca o unică tranzacţie ACID şi care permite accesul la resurse şi logică locală, cum ar fi fişierele, bazele de date etc. 53

217 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Unul dintre scopurile WSBPEL 2.0 este de a diminua costul stabilirii proceselor de business automate inter-întreprinderi (cross-enterprise) [BPEL_ebpml] Criterii de piaţă Cum şi în ce domenii este folosit Grupul de lucru BPEL dă impresia că WSBPEL va fi focusat pe domeniul relaţionărilor B2B [BPEL_ebpml] WSBPEL poate fi aplicat în două moduri diferite, deoarece un process WSBPEL poate defini: Un protocol de business (coregrafie) folosind noţiunea de process abstract Un process de business executabil (orchestrare), adică logica şi starea procesului vor determina natura şi secvenţa interacţiunilor dintre serviciile Web executate la fiecare partener şi astfel protocoalele de interacţiune. Acceptanţa din partea clienţilor Este posibilă convertirea automată a grafurilor BPMN la scripturi WSBPEL. Există o largă acceptanţă a standardului WSBPEL de către mulţi utilizatori şi dezvoltatori. După cum este exprimat în [BPELJ_ibmDN], ( ) BPEL va fi cel mai folosit standard pentru procesele de business bazate pe servicii Web. Disponibilitatea produselor / uneltelor Există mai multe produse software open-source care suportă BPEL, de exemplu: Cape Clear suportă BPEL4WS 1.1, este o soluţie all în one, care include: modelatorul de procese, motorul workflow, managerul şi monitorul; în data de februarie 6, Cape Clear a fost achiziţionată de Workday Inc. Oracle BPEL Process Manager implementează specificaţiile BPEL4WS versiunea 1.1 incluzând modelatorul, motorul de execuţie şi o unealtă de administrare Borland Together Designer creează BPEL4WS din diagrame BPMN Motorul ActiveBPEL, care suportă unele elementele din WSBPEL2.0 Standard deschis / închis WSBPEL is este un standard deschis. Este disponibil în întregime, cu unele motoare şi unelte open-source care îl folosesc. Standardul evoluează rapid şi există un mare interes în jurul lui. Standarde înlocuite WSBPEL 2.0 este dezvoltat în continuare şi nu este prevăzut ca acest standard să fie înlocuit cu altul în viitorul apropiat. Deoarece WSBPEL 2.0 a fost publicat ca standard OASIS relativ recent, 11 aprilie 2007, nu există multe unelete care să suporte complet acest standard. De exemplu, ActiveBPEL 2.0 suportă unele elemente ale noului standard, dar încă nu este un produs compatibil 100%. Din acest motiv, unele companii (de exemplu IBM [BPEL4WS11]) încă recomandă utilizarea BPEL4WS 1.1 ca limbaj de execuţie a proceselor pentru aplicaţii dezvoltate pe arhitecturi SOA. Unele funcţionalităţi ale BPEL4WS au fost eliminate din WSBPEL2.0, în timp ce altele noi au fost introduse. De exemplu, conceptual de partener nu mai există în WSBPEL 54

218 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business deoarece funcţionalităţile partnerlinks sunt suficiente pentru a descrie procesele. Legăturile nu mai pot depăşi graniţele scopurilor din cadrul activităţilor structurate. Acest lucru a fost introdus pentru a simplifica schema rutinei (handler) de compensare. Sistemul de mesagerie din BPEL4WS prezintă câteva aspecte nespecificate. În WSBPEL, o eroare standard numit missingreply a fost adăugată pentru a trata lipsa de răspuns ca eroare, faţă de versiunea 1.1 a standardului în care acest caz era lăsat la latitudinea dezvoltatorilor. Un alt exemplu este handler-ul de eveniment a cărui iniţializare nu mai este lăsată complet în seama dezvoltatorilor. Tipurile de date în WSBPEL sunt mai bine controlate, fiind folosit un model de date (data model) pentru reprezentarea variabilelor. Acest model de date este acompaniat de un set de reguli pentru maparea lui pe diferite limbaje. Deoarece există deosebiri importante între BPEL4WS şi WSBPEL, migrarea automată între aceste două standarde nu este posibilă. Această migrarea necesită o reproiectare a proceselor de business, iar efortul intelectual uman este esenţial pentru reuşita acestui transfer. Criteriu de piaţă BPEL4WS WSBPEL Stabilitate, existenţa unei versiuni mature a + - specificaţiilor Disponibilitatea implementării Open source/comercială +/+ -/ Înlocuit - - În evoluţie + + Backward compatible na - Standard deschis + + Experienţa consorţiului Criterii tehnice Concepte de bază Tabela 3 Criterii de piaţă BPEL4WS / WSBPEL WSBPEL defineşte o notaţie pentru specificarea comportamentului procesului de business folosind servicii Web. Procesul de business poate fi descris în două moduri: Process de business executabil care modelează comportamentul efectiv al unui participant într-o interacţiune de business. Protocoalele de business, pe de altă parte, folosesc descrieri de procese care specifică, pentru fiecare parte implicată în protocol, comportamentul pe baza schimbului mutual de mesaje, fără a dezvălui comportamentul intern. Descrierile de procese pentru protocoale de business se numesc procese abstracte. WSBPEL modelează atât comportamentul proceselor executabile, cât şi al proceselor abstracte. Standardul include: Secvenţializarea activităţilor unui process, în mod special interacţiunile serviciilor Web Corelarea mesajelor şi a instanţelor de process Modul de recuperare în cazul erorilor şi a condiţiilor excepţionale Relaţii bilaterale bazate pe servicii Web între diferitele roluri de process 55

219 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Granularitatea Limbajul are o notaţie şi o organizare bazată pe XML. Elementele atomice ale limbajului se numesc activităţi de bază, cum ar fi: receive, reply, invoke, assign, validate, empty, throw, rethrow, exit, wait, compensate, extensionactivity. Există de asemenea activităţi structurate, cum sunt cele prezentate în Figura 21. Notaţia folosită Figura 21 Activităţi WSBPEL WSBPEL oferă o notaţie XML şi semanică pentru specificarea comportamentului proceselor business bazat pe servicii Web. Extensibilitatea Atribute calificate prin spaţii de nume pot fi specificate pentru orice element BPEL şi elemente BPEL din alte spaţii de nume pot fi specificate în cadrul unui element BPEL. Tratarea erorilor, suport pentru compensare Activităţi pentru compensare şi tratarea erorilor sunt disponibile în standard. În plus, alarm events pot fi invocate la expirarea termenului (timeout). Pentru a suporta recuperarea din eroare în cazul unor procese de lungă durată (long-running), un model cu tranzacţii de lungă-durată este definit. Dependenţe / interoperabilitate cu alte limbaje / notaţii Notaţia limbajului este bazată pe XML şi este posibil să se genereze cod WSBEL din majoritatea diagramelor BPMN. 56

220 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Orientarea pe servicii Web Serviciile Web sunt modele pentru descompunerea şi asamblarea proceselor. WEBPEL este bazat pe standarde ce ţin de serviciile Web într-un mod composabil şi modular. Bazat pe XML sau alt formalism WSBPEL este bazat pe XML. Suport pentru structuri complexe sau şabloane WSBEL oferă suport pentru următoarele structuri: limbaj de execuţie a proceselor de business pentru şabloane de folosire, incluzând atât descriptori pentru interfaţa procesului, cât şi modele de procese executabile sunt disponibile implementări pentru activităţi structurate, de exemplu: o flow: activităţile conţinute sunt executate în parallel, părţial ordonate prin legături de control o pick: blochează şi aşteaptă pentru sosirea unui mesaj potrivit sau expirarea timpului suport pentru imbricarea structurată a scopurilor Suport pentru constrângeri de timp/timing Sunt suportate constrângeri de timp la nivel de eveniment, care sunt declanşate de apariţia timeout-urilor ca instanţe WSBPEL Informaţii/tratarea datelor Data Handlers. Procesele de business modelează interacţiuni bazate pe stări (stateful interactions). O stare este formată din mesajele recepţionate şi trimise, plus alte date relevante, cum ar fi valorile de timeout. Menţinerea stării procesului de business necesită folosirea unor variabile de stare, care sunt denumite variabile în WSBPEL. În continuare, datele unei stări sunt extrase şi combinate în moduri interesante pentru a controla comporatamentul procesului, care necesită expresii de date. În final, actualizarea stării necesită noţiunea de asignare. WSBPEL oferă aceste funcţionalităţi pentru tipurile de date XML şi tipurile de mesaje WSDL. Familia de standarde XML în acest domeniu este în curs de dezvoltare, şi folosind atribute la nivel de process pentru interogări şi limbaje de expresii oferă o platformă pentru încorporarea standardelor viitoare. Extensiile necesare pentru procesele abstracte sau executabile sunt concentrate în setul de facilităţi pentru tratarea datelor (data handling). Proceselor executabile le este permis să folosească valori nederministe. Procesele abstracte sunt restricţionate la manipularea limitată a valorilor conţinute în proprietăţile mesajului, dar le este permisă folosirea valorilor nedeterministe pentru a reflecta consecinţele comportamentului ascuns privat. Diferenţele detaliate sunt explicate în secţiunile ce urmează. 57

221 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Event Handlers. Un întreg proces, precum şi fiecare scop2, poate fi asociat cu un set de handlere de eveniment care sunt invocate concurent la apariţia evenimentului respectiv. Acţiunile executate în cadrul unui handler de eveniment pot fi orice tip de activitate, de exemplu o secvenţă sau un flux (flow). Handlere de eveniment pot fi folosite pentru mesaje, alarme, tratarea erorilor. Folosind handlere de eveniment, evenimentele pot fi activate, procesate sau dezactivate. Fault handlers. Tratarea erorilor într-un process de business poate fi văzută ca un selector de mod din secvenţa normală de procesare. Tratarea erorilor în WSBPEL este întotdeauna tratată ca reverse work prin aceea că singurul ei scop este de a anula (undo) lucrurile făcute părţial sau fără succes în scopul în care a apărut eroarea. Terminarea activităţii unui fault handler, chiar dacă nu reactivează (rethrow) eroarea tratată, nu este niciodată considerată ca o terminare cu succes a scopului în care a apărut şi compensarea nu este activată niciodată pentru un scop în care a fost invocat un fault handler. Compensation Handlers. Scopurile pot descrie o parte a comportamentului care se presupune că poate fi reversibil într-un mod definit de aplicaţie prîntr-un handler de compensare. Scopurile cu handlere de compensare şi tratare de erori pot fi încuibate fără nici o constrângere legată de adâncime Aplicabilitate Există un număr seminificativ de produse care suportă acest standard. Unii dintre partenerii proiectul SCIPA au experienţă în utlilizarea acestui standard dobândită în urma participării în alte proiecte europene sau naţionale. WSBEL este un candidat serios cu avantajele că este open-source (fapt ce va evita costurile de licenţiere), se oferă suport, poate fi generat cod WSBPEL din diagrame BPMN şi, nu în ultimul rând, unii parteneri au o experienţă considerabilă cu acest standard. În plus, întreţinerea codului scris WSBPEL va fi suportată la nivel larg datorită popularităţii acestui standard. WSBPEL acoperă mai multe arii ce ţin atât de coregrafie cât şi de orchestrare. Criteriu tehnic BPEL4WS WSBPEL Elemente de control (loop, choice, etc) 0 0 Fire de execuţie paralele + + Suport pentru structuri precum module/procese + + Suport pentru subfluxurilor (subflows) 0 + Structuri complexe 0 0 Fluxul de date + + Compatibilitate cu WSDL + + Compatibilitate cu BPMN 0 0 Selectarea binding-urilor / endpoint-urilor + + Suport pentru tratarea erorilor + + Suport pentru compensare Scopul într-o secvenţă program este un set de linii imbricate între expresii speciale de început, respectiv de sfârşit. În unele limbaje, scopurile determină scopul unei variabile sau spaţii de nume. 58

222 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business Suport pentru procesarea tranzacţiilor + + Suport pentru interacţiunea cu roluri / utilizatori umani - - Exceutabil + + Definiţie formală XML XML Extensibilitate - 0 Independent de platformă - + Securitate - - Constrângeri legate de timing + + Calitatea serviciilor / prioritizări - - Suportă conceptul programming-in-the-small Rezumat Avantaje Tabela 4 Criterii tehnice BPEL4WS / WSBPEL WSBPEL acoperă atât coregrafia cât şi orchestrarea. Permite analiştilor de piaţă să descrie procesele de business, şi există extensii ale limbajului precum expressile XPath, mecanisme şi motoare de execuţie. Deasemenea, există unelte pentru generarea automată a codului WSBPEL din diagrame BPML. În versiunea originală, BPEL nu are legătură cu nici un limbaj de tipul programming-in-the-small. Astfel, este abstractizat faţă de detaliile tehnice şi este independent de platformă. Dezavantaje În versiunea originală, BPEL nu poate fi folosit cu succes pentru decrierea proceselor in-the-small. Detaliile tehnice nu sunt în scopul acestui standard, astfel încât trebuie să fie folosit un alt limbaj pentru a obţine cod exceutabil din descrierile BPEL. Uneltele BPEL existente comliează codul BPEL în limbaje de programare precum Java şi permite specificaţiilor BPEL să fie extinse prin fragmente de limbaj de programare. Recomandări BPEL poate fi folosit ca un limbaj de nivel jos pentru descrierea proceselor de business ce implică relaţii atât B2B cât şi B2C. BPEL acţionează şi ca un bridge între limbajele graphice de nivel înalt (de ex BPML) şi limbajele ce suprotă doar paradigma programming-inthe-small. Codul BPEL poate fi generat automat din diagramele BPML. BPEL este un standard în evoluţie cu un puternic srijin din partea pieţei. BPEL4WS 1.1 poate fi recomandat pentru SCIPA ca limbaj de nivel jos datorită avantajelor sale: este gratuit, deschis, matur, suportat de majoritatea furnizorilor importanţi, cum ar fi BEA sau IBM. Suportă majoritatea funcţionalităţilor care sunt importante pentru SCIPA, cum ar fi servicii Web, tratarea erorilor sau constrângerile de temporizare. Deasemnea, sunt numeroase unelte, atât open-source cât şi comericale, petru modelarea şi exceuţia proceselor. Din nefericire, WSBPEL 2.0 este un standard foarte nou, nu este compatibil cu versiunea anterioară (BPEL4WS 1.1), iar uneltele disponibile nu sunt foarte numeroase. 59

223 SCIPA - Standarde actuale în limbajele de modelare a proceselor de business 4.2 XML Process Definition Language (XPDL) Limbajul XPDL (XML Process Definition Language) este proiectat de către WfMC (Workflow Management Coalition), o organizaţie care are peste 300 de membrii, printre care IBM, Lucent Technologie, sau SAP AG, organizaţii de reprezintă toate faţetele procesului de lucru, de la vânzători la utilizatori, de la academicieni la consultanţi. Imediat după înfinţarea sa, WfMC a început lucrul la crearea unui limbaj sandardizat pentru definirea proceselor de lucru (workflow3). Astfel, a rezultat Workflow Process Definition Language (WPDL) prezentat întâia oară în Cu toate că mulţi vânzători au pretins că respectă WPDL, puţini au făcut eforturile necesare pentru a suporta acest limbaj. Între timp, XML a devenit standardul pentru schimbul de date. Deoarece WPDL nu era bazat pe XML, plecând de la WPDL, WfMC a început lucrul la un nou limbaj denumit XML Process Definition Language (XPDL). Oricum, XPDL nu trebuie considerată versiunea XML a limbajului WPDL deoarece concepte noi au fost adăugate, iar unele concepte au fost eliminate. Chiar WfMC nu are poziţie clară privind relaţia între XPDL şi WPDL. În octombrie 2002, WfMC a făcut publică versiunea finală a XPDL 1.0 [XPDL1.0]. Versiunea 2.0 a XPDL a fost aprobată ca un standard oficial al WfMC în septembrie 2005 şi este backward compatibilă cu versiunea 1.1 [XPDL2.0]. WfMC a dezvoltat modelul de referinţă pentru workflow-uri după cum este prezentat în Figura 22. În acest model au fost identificate cinci interfeţe funcţionale ale unui proces sau serviciu workflow, ca parte a programului de standardizare WfMC [WFMC_RM]. Figura 22 WfMC Workflow Reference Model 3 Datorită faptului că este un termen deja consacrat şi în limba română, pentru referirea la procesele de lucru vom folosi termenul din engleză pe tot parcursul acestei lucrări. 60