Teza Cristian Danila

FONDUL SOCIAL EUROPEAN
Investete n oameni!
Programul Operaional Sectorial pentru Dezvoltarea Resurselor Umane 2007 2013
Proiect POSDRU/107/1.5/S/76813 Burse doctorale: investitii in cercetare-inovare-dezvoltare pentru viitor (DocInvest)
UNIVERSITATEA POLITEHNICA DIN BUCURETI

Facultatea Automatic i Calculatoare
Departamentul Automatic i Informatic Industrial
Nr. Decizie Senat 226 din 28.11.2013
TEZ DE DOCTORAT
Configurarea dinamic a Organizaiei Colaborative de ntreprinderi,
integrat prin tehnologii Internet of Services
Dynamic Configuration of Collaborative Networked Organization by

Internet of Services technologies
Autor: Ing. Cristian Dnil
Conductor de doctorat: Prof.dr.ing. Aurelian Mihai Stnescu
COMISIA DE DOCTORAT
Preedinte Prof. dr. ing. Adina Magda Florea de la Universitatea Politehnica din Bucureti
Conductor de Prof. dr. ing. Aurelian Mihai de la Universitatea Politehnica din Bucureti
doctorat Stnescu
Referent Prof. dr. ing. Simona Iuliana de la Universitatea Politehnica din Bucureti
Caramihai
Referent Prof. dr. ing. Viorel Mnzu de la Universitatea Dunrea de Jos din Galai
Referent Prof. dr. ing. Mircea Ivnescu de la Universitatea din Craiova
Bucureti
Configurarea dinamic a Organizaiei Colaborative de ntreprinderi, integrat prin tehnologii Internet of Services
Viitoarei mele soii, prinilor mei
2
Cuprins
INTRODUCERE 10
1. Context economic actual i motivaia abordrii temei de dizertaie 10
2. Scopul propus i obiectivele etapelor planului individual de cercetare 17
3. Organizarea tezei 18
4. Lucrri susinute n vederea validrii publice a unor rezultate pariale ale demersului de
cercetare 19
ACKNOWLEDGEMENT 20
CAPITOLUL 1 21
STADIUL ACTUAL AL CUNOATERII N DOMENIUL SISTEMELOR

INFORMAIONALE EVOLUATE, COMPLEXE, ADATIVE, DISPERSATE
GEOGRAFIC 21
1.1. TRSTURI CARE DEFINESC UN CADRU DE MODELARE PENTRU UN SISTEM

DE SISTEME INFORMAIONALE, COMPLEXE, ADAPTIVE, DISPERSATE GEOGRAFIC,
CU MODELE ORGANIZAIONALE DIN CATEGORIA ORGANIZAIILOR VIRTUALE
21
1.1.1. Universul discursului 21
1.2. CERINTE, ATRIBUTE, PROPRIETI ALE UNUI SISTEM DE SISTEME

(METASISTEM) INTEGRAT PRIN TEHNOLOGII EVOLUATE INTERNET: INTERNETUL
OBIECTELOR, INTERNETUL SERVICIILOR SEMANTIC WEB, INTERNETUL
CUNOATERII, INTERNETUL COMUNITILOR (SOCIALIZRII) 25
1.2.1. Introducere 25
1.2.2. Spaiile cunoaterii universului Future Internet Enterprise Systems 25
1.2.3. Direcia de cercetare Horizon 2020 30

1.2.4. Concluzii 38
1.3. TENDINE DE DEZVOLTARE ALE CERCETRII I INOVRII PENTRU

CATEGORIA DE SISTEME BAZATE PE SERVICII COMPUSE, ORIENTATE SPRE
PROPRIETI DE INTEROPERABILITATE 38
1.3.1. Specificul sub-sistemelor Service Based Systems 38
3
1.3.2. Clasa sistemelor Collaborative Networked Systems/Organisation 39
1.3.2.1. Introducere 39
1.3.2.2. Mediul de dezvoltare al organizaiilor virtuale 40
1.3.2.3. Managementul organizaiilor virtuale 50
1.3.2.4. Concluzii 62
1.3.3. Modele de compunere a serviciilor web 63

1.3.3.1. Concepte 63
1.3.3.2. Clasificarea modelelor de compunere a serviciilor 64
1.3.4. Abordari privind adaptabilitatea aplicatiilor orientate pe servicii 67
1.3.4.1. Taxonomia adaptrii 67
1.3.4.2. Abordri privind adaptabilitatea aplicaiilor orientate ctre servicii 70
1.4. CONCLUZII 77
CAPITOLUL 2 78
CERINE I SPECIFICAII LA NIVEL CONCEPTUAL PENTRU

ELABORAREA UNEI METODOLOGII DE INTEGRARE A
ORGANIZAIILOR DE NTREPRINDERE, INTEGRATE PRIN
COMUNICAII ORIENTATE PE TEHNOLOGII DEFINITE DE
PLATFORMA PLATFORM AS A SERVICE / FI-WARE 78
2.1. CONCEPTE FUNDAMENTALE 78
2.2. NIVELURI DE INTEROPERABILITATE 79
2.3. EVOLUIA SISTEMELOR INFORMAIONALE DE LA CONCEPTUL DE

INTEGRAREA APLICAIILOR LA NIVEL DE NTREPRINDERE LA SISTEM DE
SISTEME INFORMAIONALE, COMPLEXE, ADAPTIVE, DISPERSATE GEOGRAFIC
INTEGRATE PRIN TEHNOLOGII FUTURE INTERNET ENABLING TECHNOLOGIES:
INTERNETUL OBIECTELOR, INTERNETUL SERVICIILOR, INTERNETUL
CUNOATERII, INTERNETUL SOCIALIZRII 81
2.3.1 Definiii 81
2.3.1.1 Arhitecturi ale ntreprinderii 81
2.3.1.2 Concepte de baz ale arhitecturii ntreprinderii 81

4
2.3.1.3 Diferite tipuri de arhitecturi de ntreprindere 82
2.3.1.4. Integrarea la nivel de ntreprindere 82
2.3.1.5. Interoperabilitatea la nivel de ntreprindere 82
2.3.2. Istoric: Arhitecturi pentru integrarea la nivel de ntreprindere 83
2.3.2.1 Iniiative timpurii n privina arhitecturii de ntreprindere 83
2.3.2.2 Standarde privind integrarea la nivel de ntreprindere 90
2.3.3. Arhitecturi pentru interoperabilitatea la nivel de ntreprindere 92
2.3.3.1 Standarde de interoperabilitate 100
2.3.4. Concluzii 102
2.4. FORMULAREA PROBLEMEI DE REZOLVAT 102
2.4.1. Identificarea problemei la nivel de ntreprindere 102
2.4.2. Formularea propriu-zis a problemei 103
2.5. SUPORT FORMAL PENTRU CUTAREA SOLUIILOR 104
2.6. CONCLUZII 113
CAPITOLUL 3 114
CONFIGURAREA DINAMIC A METASISTEMULUI N CARE

ENTITILE / NODURILE REELEI SUNT BAZATE PE
REELAREA / RELAIONAREA PRIN INTERNETUL VIITORULUI
ORIENTATE ORGANIZAIONAL PE MODELUL COLABORATIV 114
3.1. CICLUL DE VIA AL UNEI ORGANIZAII VIRTUALE 114
3.2. DEFINIREA CONCEPTULUI DE MEDIU DE CRETERE / EVOLUIE AL
ASOCIERII ENTITILOR DINTR-UN METASISTEM N CARE ENTITILE /
NODURILE REELEI SUNT BAZATE PE REELAREA / RELAIONAREA PRIN
INTERNETUL VIITORULUI I ORIENTATE ORGANIZAIONAL PE UN MODEL
COLABORATIV 114
3.3. CADRU DE MODELARE PENTRU MANAGEMENTUL ORGANIZAIONAL AL
METASISTEMULUI N CARE ENTITILE / NODURILE REELEI SUNT BAZATE PE
REELAREA / RELAIONAREA PRIN INTERNETUL VIITORULUI ORIENTATE
ORGANIZAIONAL PE MODELUL COLABORATIV SUB PRESIUNEA
PERTURBAIILOR ENDOGENE I EXOGENE 116
5
3.4. METODA DE REZOLVARE PROPUS 119

3.5. CONCLUZII 137
CAPITOLUL 4 139
IDENTIFICAREA IMPACTULUI SCHIMBRILOR N CADRUL

PROCESELOR BAZATE PE SERVICII 139
4.1. INTRODUCERE 139

4.2. MODELUL DE PROCES ORIENTAT CTRE SERVICII 141
4.3. RELAIA DINTRE NIVELUL PROCES I NIVELUL SERVICII 145
4.4. IMPACTUL SCHIMBRILOR 145
4.5. IMPLEMENTARE 149
4.6. CONCLUZII 151
CAPITOLUL 5 152
STUDIU DE CAZ 152
5.1. DESCRIEREA SCENARIULUI 152
5.2. DESCRIEREA PROCESELOR 153
5.3. CONCLUZII 165
CONCLUZII 166
C.1. CONCLUZII GENERALE 166
C.2. CONTRIBUII ORIGINALE 167
C.3. PERSPECTIVEDE DEZVOLTARE ULTERIOAR 168
ANEXE 169
A1. COD SURS INSTRUMENT DE ANALIZ A
IMPACTULUI SCHIMBRILOR 169
BIBLIOGRAFIE 212
6
Future Internet Enterprise Systems (FInES) Sistem informaional, evoluat, dispersat

geografic, integrat prin tehnologii Future
Internet enabling technologies: Internetul
Obiectelor, Internetul Serviciilor, Internetul
Cunoaterii, Internetul Socializrii
Enterprise Integration, Interoperability and Sisteme de ntreprindere distribuite geografic,
Networking (E2IN) integrate, interoperabile i reelate prin
tehnologii internet
Service Based Systems (SBS) Sisteme bazate pe servicii coordonate i
orchestrate
Enterprise Applications Integration (EAI) Integrarea aplicaiilor la nivel de ntreprindere
Collaborative Networked Organization (CNO) Metasistem n care entitile / nodurile
reelei sunt bazate pe reelarea /
relaionarea internetului viitorului i orientate
organizaional pe un model colaborativ
Dynamic Digital Business Ecosystem (DDBE) Ecosistem de afaceri care se deruleaz ntr-un
mediu de comunicaie digital i care rspunde
unor schimbri impredictibile sub influena
stimuli/perturbaii exogene i endogene
Virtual Breeding Environment (VBE) Mediu de dezvoltare / configurare a
metasistemului CNO
Virtual Organization (VO) Organizaie virtual
Internet of Things (IoT) Internetul Obiectelor
Internet of Services (IoS) Internetul Serviciilor
Internet of Knowledge (IoK) Internetul Cunoaterii
Internet for/by People (IoP) Internetul Socializrii
Complex Adaptive System of Systems Sistem de Sisteme (metasistem)
(CASoS) Informaionale de entitate-ntreprindere, de
mare complexitate i adaptiv
Small and Medium Enterprises (SMEs) ntreprinderi Mici i Mijlocii
Universe of Discourse (UoD) Universul de discurs
7
ABREVIERI
API Application Programming Interface
BPM Business Process Management (Managementul Proceselor de Afaceri)
BMPN Business Process Modeling and Notation
CAD Computer Aided Design
CIM1 Computer Integrated Manufacturing ( Producie asistat de calculator)
CIM2 Computer Independent Platform(Calculatoare independente de platform)
CN/RC Collaborative Network/Reea Colaborativ
CNO Collaborative Networked Organisation
CPS Cyber Physical System
DE Digital Enterprise
FI-PPP Future Internet Public Private Partnership
SME/IMM Small and Medium Enterprises/ntreprinderi Mici i Mijlocii
IP Indicatori de Performan
ICP/KPI Indicatori Cheie de Performan/ Key Performance Indicators
ICT Information and Communications Technologies
IoT Internet of Trust
IoS Internet of Services
IoK Internet of Knowledge
IoP Internet of People
KMS Knowledge Management System
MAS Multi Agent System
MDA Model Driven Analysis
MDD Model Driven Development
MP Msurarea Performanelor
OC Oportunitile de colaborare
ODP Open Distributed Processing
RDF Resource Description Framework
RFID Radio Frequency Identification
SBA Service Based Application
SBS Service Based System/Sistem Bazat pe Servicii
SCC Service Composition and Coordination
SI Service Infrastructure
SBA Service Based Application
SE Sensing Enterprise/ntreprinderea Vie
SLA Service Level Agreement
SMMDOV Sistem de Management al Mediului de Dezvoltare al Organizaiilor Virtuale
SOA Service Oriented Architecture
SOC Service Oriented Computing
URI Uniform Resource Identifier
VO Virtual Organisation
VBE Virtual Organisations Breeding Environment/Mediul de Dezvoltare al
Organizaiilor Virtuale
WSDL Web Service Description Language
WE Web Entrepreneurs/Antreprenorii Web
8
MULUMIRI
Prezenta lucrare a fost realizat n cadrul colectivului de Sisteme Dinamice cu Evenimente
Discrete al Facultii de Automatic i Calculatoare, Universitatea Politehnica din
Bucureti, sub coordonarea tiinific i atenta ndrumare a prof.dr.ing. Aurelian Mihai
Stnescu, cruia i aduc pe aceast cale calde mulumiri pentru sprijinul permanent i
nelegerea artat de-a lungul elaborrii acesteia.
Pe aceast cale doresc s le mulumesc doamnei prof.dr.ing. Simona Caramihai, domnului
prof.dr.ing. Mircea Ivnescu, domnului prof.dr.ing. Viorel Mnzu pentru
amabilitatea de a citi acest manuscris i pentru observaiile constructive i pertinente aduse.
Le mulumesc colegilor i prietenilor din cadrul facultii, n special: dr.ing. Georgiana Stegaru,
drd. Luiza Burlacu, l.dr.ing. Mihnea Moisescu, sl.dr.ing. Ioan Sacal, drd. ing. George Burlacu
i l.dr.ing. Clin Munteanu pentru ajutorul competent i sprijinul moral cu care m-au nconjurat.
Sincere multumiri doresc sa aduc si tuturor colegilor din universitate sau din alte centre
universitare, specialistilor din cercetare, proiectare si productie care vor avea amabilitatea si
rabdarea de a citi aceasta lucrare si de a comunica observatiile, sugestiile si aprecierile
dumnealor.
In final, dar nu in ultimul rnd, a dori s multumesc clduros pe aceasta cale familiei mele
pentru sprijinul moral i nelegerea oferite.
9
INTRODUCERE
1. Context economic actual i motivaia abordrii temei de dizertaie
n ultimii ani, dezvoltarea tehnologiilor ICT a permis evoluia internetului de la o simpl surs de
informare la o infrastructur care permite ntreprinderilor aflate n puternic concuren pe o pia
dinamic n curs de globalizare, specific noii economii digitale[1] integrarea sub modele de
management organizaional din categoria: ntreprindere Virtual, Organizaie Virtual, cluster,
etc., care pot fi denumite generic ntreprinderi Globale cu geometrie variabil. n ultimii ani,
sectorul e-serviciilor a cunoscut cea mai rapid cretere din lume, devenind un sector de afaceri
important n economia teriar[2]. Emergena unor paradigme pentru sisteme software ca de
exemplu: SaaS (Software as a Service), PaaS (Platform as a Service), IaaS (Infrastructure as a
Service), social web (Facebook, MySpace, LinkedIn) , Web 3.0(Semantic Web)precum i
explozia numrului de furnizori de coninut media, a terminalelor de comunicare (telefoane
inteligente, tablete, etc.) i a reelelor wireless de senzori (WSN - Wireless Sensor Networks)
ridic o problem major n ceea ce privete dezvoltarea ulterioar a tehnologiilor Future
Internet. nceput n anult 2012, direcia de cercetare DG2-CONNECT a lansat n cadrul
programului de parteneriat public-privat un ambiios program privind platforma pan-european
FI-WARE[3].
n acest context s-a dezvoltat o nou paradigm sistemic eterogen: FInES, denumit generic
Sisteme de mare complexitate pentru ntreprindere Virtual, dispersat geografic, integrate prin
tehnologii ICT specifice noului val de utilizare a Internetului. Motoarele de inovare sunt
cunoscute prin urmtoarele prescurtri IoS (Internetul Serviciilor), IoT (Internetul Obiectelor),
IoK (Internetul Cunoaterii), IoP(Internetul Socializrii). n acelai timp, FInES reprezint un
domeniu de cercetare multi-disciplinar i inter-disciplinar. [1]
Dintre cele patru motoare, Internetul Serviciilor reprezint o sintagm folosit pentru a descrie
felul n care serviciile compuse create sub form de servicii semantic web sunt utilizate ntr-o
gam larg de aplicaii, n domenii ca: industrie, logistic, financiar, e - Sntate, e - Energie, e -
Guvernan [3] i este bazat pe arhitectura SOA (Service Oriented Architectures).
n ultima decad, domeniul serviciilor a cunoscut o dezvoltare impresionant. Pentru ca aceast

cretere s continue, serviciile ar trebui s devin disponibile la scar larg i mai uor accesibile,
s ofere un randament i o productivitate mai mare. Folosirea tehnologiilor informatice inovative
va conduce duce la realizarea acestor obiective i la crearea de noi modele de afaceri generatoare
10
de noi locuri de munc. SOA va susine transformarea ntreprinderilor n care indicatorii chei de
performan (KPI) vor fi urmrii cu ajutorul modelelor de tip RADAR, urmrind:
profitabilitatea, satisfacerea dorinelor clientului personalizat, agilitate, flexibilitate, scalabilitate,
etc..
Comportamentul economic al ntreprinderilor i plasarea lor n contextul social a cunoscut

modificri eseniale prin schimbarea de paradigm propus de trecerea de la societatea
informaional la societatea bazat pe cunoatere. ntreprinderile zilelor noastre sunt caracterizate
de deferite faete cheie: globalizarea, producia distribuit,managementul datelor i al
cunotinelor, noul mix al metodelor reactive bazat pe rspunsul reactiv la cerinele pieei i
metodele proactive. Participarea n cadrul paradigmei tiinifice FInES prin dezvoltarea
sistemelor cu model organizaional CNO a devenit foarte important pentru organizaiile mici i
mijlocii, care pot fi integrate vertical pstrnd proprietatea de interoperabilitate pe cel puin patru
niveluri[152]. Cele dou fee ale monedei privind dezvoltarea serviciilor de colaborare i
colaborare (proiect COIN-IP/258296 n care grupul UPB,ACS a fost partener) reprezint un
rspunsal cercetrii n cadrul programului PC7 la provocrile majore ale pieelor turbulente.
Integrarea i interoperabilitatea ntreprinderilor, precum i reelele de calculatoare sunt factori ce
permit organizaiilor s-i mbunteasc ntr-un mod eficient colaborarea i comunicarea[2].
Pentru a avea succes ntr-un mediu competitiv i n continu schimbare, companiile trebuie s-i
restructureze sistemele operaionale i informaionale, s reproiecteze procesele de producie
pentru a optimiza folosirea resurselor, pentru a reduce costurile i pentru a rspunde
oportunitilor ce se schimb rapid (proiect POSDRU/81/3.2/S/53084). Mai mult chiar,
organizaiile realizeaz parteneriate cu alte companii n ecosisteme dinamice digitale de afaceri
ce se extind global [4]. n prezent, s-a trecut de la piloii de experimentare de tip FInES CNO la
realizri viabile n economia real dintre care cel mai reprezentativ model este modelul de
cluster(exemplu Linz www.b2match.eu/danuberegionbusinessforum2013). n industria actual,
reelele colaborative se manifest ntr-o varietate de forme. Dac n sectorul produciei, un lan de
aprovizionare este caracterizat de o reea de ntreprinderi relativ stabil cu roluri bine definite i
coordonare minim, n domeniul guvernamental i al serviciilor, organizaiile formeaz n funcie
de oportunitatea de afacere identificat un consoriu temporar n termeni de competene i resurse
numit organizaie virtual. Alte exemple de reele colaborative sunt reelele de profesioniti care
colaboreaz n cadrul unor comuniti virtuale (VPC Virtual Professional Communities) pentru
a forma echipe virtuale ce adreseaz anumite probleme. Laboratoarele virtuale ofer oamenilor de
tiin situai n zone geografice diferite un mediu virtual experimental pentru a lucra mpreun,
mprtind resursele i rezultatele.
Constituirea ntreprinderilor n organizaii virtuale pentru oferirea de e-servicii i produse

inteligente ctre comunitile locale, regionale sau globale pentru o perioad restrns de timp
este susinut de asemenea de arhitectura SOA[5]. Fiecare ntreprindere este considerat ca
furnizor de servicii i selectat n cadrul organizaiei virtuale n funcie de serviciile oferite.
Compunerea de servicii duce la formarea de sisteme bazate pe servicii. Datorit caracterului
dinamic al organizaiilor virtuale, este necesar o flexibilitate i adaptivitate ridicat a proceselor
bazate pe servicii ce guverneaz organizaia, pentru adaptarea rapid a acesteia la condiiile
pieelor turbulente.
11
Conform dicionarului explicativ romn, cuvntul paradigm reprezint un exemplu, un model,

o pild, o nvtur. Thomas Kuhn definete termenul de paradigm tiinific n cartea sa,
The Structure of Scientific Revolution [6] ca fiind: un concept global, acceptat de majoritatea
unei comuniti tiinifice datorit eficacitii ei n rezolvarea problemelor importante, n
enumerarea ideilor ce deschid noi soluii pentru probleme complexe, sau a observaiilor asupra
experimentelor dintr-un domeniu dat. La aceast definiie riguroas i elegant, au contribuit i
autorii A. Kaposi i M. Myers prin precizarea trsturilor cheie ale paradigmei sistemice, trsturi
ce vor fi prezentate n paragrafele urmtoare. Kuhn a observat n cartea sa c tiinele trec
alternativ prin perioade de normalitate, cnd un anumit model al realitii este dominant pentru
rezolvarea problemelor i prin perioade de revoluie cnd modelele realitii trec prin schimbri
drastice.
Conform aceluiai autor, [6] schimbarea de paradigm (paradigm shift) reprezint o
modificare n cadrul ipotezelor de baz n domeniul tiinific. Acelai autor a concluzionat c
trecerea succesiv de la o paradigm la alta printr-o revoluie reprezint modul obinuit de
dezvoltare al unei tiine mature.
De-a lungul timpului, paradigma ntreprinderii a trecut prin mai multe etape de evoluie.
Evoluia paradigmelor ntreprinderii prezentate n figura 1.1. pornete de la producia n mas i
are ca posibil urmtoare etap n viitorul apropiat producia inteligent [30].
Producia n mas satisface nevoia social de noi produse, avnd o orientare ctre funcionalitate,
concentrndu-se asupra optimizrii proceselor de producie i a minimizrii costurilor. Mijloacele
tehnice folosite sunt reprezentate de roboi industriali, maini de control numerice i mai trziu de
sisteme de fabricaie automat (Automated Manufacturing Systems). Din punct de vedere
managerial, organizaia are o structur ierarhic, indicatorii de performan fiind productivitatea
i costul de producie sczut. Resursa uman este ntlnit preponderent la nivel de atelier de
producie i reprezint mai degrab o surs de erori dect un activ al organizaiei. Cerina social
de personalizare a produselor primeaz n aceast etap.
Producia flexibil are ca scop personalizarea produselor. Mijloacele tehnice folosite sunt
reprezentate de sistemele flexibile de producie (Flexible Manufacturing Systems). Din punct de
vedere managerial, organizaia are o structur ierarhic. Indicatorul de performan este
reprezentat de flexibilitatea la nivel de produs, tehnologie, main i producie. Resursa uman
este mai creativ la nivel de proiectare i mai specializat n operarea mainilor la nivel de atelier
de producie, ca urmare al instruirii i devine astfel un activ pentru organizaie. Ca i noi cerine
care apar, cea mai important dintre ele este interoperabilitatea ntre aplicaiile software.
Producia integrat cu calculatorul este orientat ctre interoperabilitatea la nivel de ntreprindere
i adaptarea continu la mediu. Mijloacele tehnice folosite sunt reprezentate de integrarea la nivel
de infrastructur ICT folosind modele i standarde. Din punct de vedere managerial, organizaia
este virtual i are o abordare centrat client. Resursa uman este cel mai important activ al
organizaiei, fiind cea care deine cunotinele. Indicatorul principal de performan este
adaptabilitatea, un factor cheie al eficienei fiind reprezentat de cunotine. Noi cerine ce apar n
aceast perioad sunt reprezentate de: cooperare, competitivitate, agilitate, excelen, toate
acestea ducnd nspre sisteme de sisteme inteligente i colaborative.
12
Producia inteligent are ca obiective: (i) gsirea unor noi ci inovative pentru producia
competitiv a unor materiale/produse noi sau existente care s satisfac nevoile unor piee n
continu cretere; (ii) crearea de procese agile n cadrul organizaiilor, capabile s rspund rapid
la fluctuaiile cerinelor clienilor; (iii) utilizarea eficient a resurselor; (iv) sustenabilitate prin
minimizarea impactului asupra mediului nconjurtor.
13
14
Fig. 1.1. Primele cinci valuri i patru schimbri de paradigm avnd ca int FInES [31]
Agnes Kaposi i Margaret Myers [7] au propus o list de cinci trsturi fundamentale ale
paradigmei sistemice. Aceste cinci trsturi vor fi redate pe rndurile urmtoare [7]:
T1 ar trebui s fie construit n jurul a patru coloane disciplinare: tiin / Calcul / Inginerie /
Management.
T2 ar trebui s fie larg accesibile, cuprinztoare pentru orice persoan interesat, implicnd
membrii consiliului de administraie al organizaiei implicate n proiect, management,
subcontractori, specialiti, personal, politicieni, membri ai guvernului. Din aceast cauz,
conceptele trebuie s fie clar definite, definiiile trebuie s fie consistente i s formeze o
structur coerent. Folosirea notaiilor pentru o mai bun nelegere i evitarea ambiguitilor este
binevenit.
T3 ar trebui s utilizeze principiile avansate ale calitii. Conform acestor principii, un proiect
trebuie s satisfac nu numai cerinele clientului cel care pltete, dar trebuie s respecte i
mediul i s ia n considerare toate prile implicate ct i necesitile comunitii.
T4 cei implicai n proiect sunt responsabili. Paradigma sistemic ar trebui s faciliteze

responsabilitatea: modele i metode specifice trebuie folosite pentru definirea specificaiilor,
reprezentarea clar, proiectare, implementare i managementul proiectului. Trebuie s asiste
analiza riguroas i s asigure trasabilitatea, facilitnd astfel livrarea n timp a soluiei i n
bugetul alocat. Din aceast cauz, modelele trebuie datate i caracterizate de uniti de msur ce
15
pot fi evaluate obiectiv. De asemenea, modelele trebuie s adauge managementul riscului,

formularea unor decizii informate, articularea unor judeci de valoare.
T5 ar trebuie s fie general: comun celei mai largi clase de probleme de dimensiune mic sau
mare, bazat pe filozofia teoriei sistemelor, i construite pe noiunea universal de sistem.
A.M. Stnescu a identificat un alt numr de ase trsturi ce pot fi adugate paradigmei sistemice
[8]. Acestea vor fi prezentate n continuare:
T6 ar trebui s fie susinut de ctre un suport formal coerent, bazat pe matematic discret,
meta-euristic i inteligen artificial.
T7 ar trebui s susin soluii centrate antropomorfic, dar avnd o abordare de tip CPS (Cyber
Physical System CPS).
T8 ar trebui s susin ntregul ciclu de via de la reprezentarea problemei la modelul de

validare i punerea n aplicare. De la idee inovatoare pn la transferul efectiv de tehnologie.
T9 ar trebui s fie corelat cu alte paradigme complementare: nvarea pe tot parcursul vieii
(LLL), Internetul Viitorului i Ingineria Concurenta.
T10 dezvoltarea sistemului ar trebui s fie bazat pe noi abordri, i anume: MDA(Model
Driven Analysis), MDD(Model Driven Developmet), CIM2(Computer Independent Platform)
T11 ar trebui s foloseasc concepte noi, cum ar fi Software ca Serviciu (Software as a Service -
SaaS), Infrastructur ca Serviciu (Infrastructure as a Service - IaaS), Platform ca Serviciu
(Platform as a Service - PaaS ).
n continuare, prezenta lucrare va propune un set de noi trsturi importate pentru autor n ceea ce
privete paradigma sistemic.
T12 ar trebui s asigure un grad ct mai mare de autonomie n procesul decizional.
T13 ar trebui s asigure un grad ct mai mare de adaptivitate al prilor componente i implicit
adaptivitatea sistemului.
T14 ar trebui s fie corelat cu conceptul de interoperabilitate sistemic sustenabil [12]
T15 ar trebui s fie orientat ctre societate (bunstare, sntate) [11].
FInES este paradigma sistemic care a stat la baza elaborrii programului individual de cercetare
n perioada 2010-2013.
Arhitectura de referin este, n esen, un model arhitectural predefinit, sau un set de modele,
parial sau complet instaniat/e, folosit cu succes ntr-o situaie particular de afacere sau ntr-un
context tehnic, mpreun cu artefactele care activeaz utilizarea sa.
Arhitectura de referin se refer la ingineria coerent i la proiectarea principiilor utilizate ntr-
un domeniu specific. Arhitectura de referin are drept obiectiv structurarea proiectrii unei
arhitecturi de sistem prin: definirea unei terminologii unificate, descrierea responabilitilor
16
componentelor, furnizarea componentelor standard (ablon), oferind exemple de arhitecturi de

sistem i definind metodologii de dezvoltare.
O arhitectur de sistem este o descriere abstract a unui sistem specific. Prin definirea
functionalitilor componentelor sistemului i a interaciunilor dintre acestea, precum i a
constrngerilor, ajut la (re)dezvoltarea sistemului. Arhitectura depinde de principiile inginereti
i de tehnologiile disponibile.
O reea colaborativ bazat pe modelul organizaional CNO este privit ca un sistem de sisteme,
de dimensiuni(Large Scale Enterprises, SMEs, micro-Enterprise) i forme variate. n cuprinsul
tezei, se va defini nivelul de metasistem pentru a aduga ce-a de-a cincea dimensiune primelor
patru definite conceptual n proiectul ECOLEAD. Datorit dinamicii mediului de afaceri i
pieelor turbulente sistemul sufer perturbaii (entiti pot intra sau iei din sistem, mediul de
afaceri se poate modifica, oportuniti de afaceri pot aprea). n aceste condiii, sistemul trebuie
s suporte tranziii succesive, pn n momentul cnd va ajunge la o stare de echilibru.
Dup identificarea acestei probleme, a urmat faza de dezvoltare a produsului program pentru
analiza impactului schimbrilor n cadrul proceselor descrise n WS-BPEL.
2. Scopul propus i obiectivele etapelor planului individual de cercetare
Scopul tezei este reprezentat de dezvoltarea unui cadru de modelare pentru managementul
organizaional al CNO.
Pentru ndeplinirea scopului tezei, au fost propuse urmtoarele obiective intermediare:
Identificarea stadiul actual al cunoaterii n domeniile:
IoS, Sisteme Bazate pe Servicii, adaptabilitatea serviciilor web
reelele colaborative (CN - Collaborative Networks), organizaiile virtuale (VO -

Virtual Organizations), mediul de dezvoltare al organizaiilor virtuale (VBE -
Virtual Breeding Environment)
interoperabilitatea i integrarea la nivel de ntreprindere
direcia de cercetare reprezentat de ntreprinderea Vie (Sensing Enterprise)
Dezvoltarea unei metode de aplicare a managementului schimbrii n cadrul unui

metasistem CNO
Dezvoltarea unui instrument software pentru analiza impactului schimbrilor n sisteme

bazate pe servicii
17
Aplicarea pe un studiu de caz a produsului program de analiz a impactului schimbrilor

prezentat n lucrare
ntrebrile formulate pe parcursul cercetrii sunt:

Care sunt conceptele de baz CN, CNO, VBE, VO
Ce presupune integrarea i interoperabilitatea la nivel de ntreprindere FInES?
Ce presupune managementul de schimbare al partenerilor ntr-o reea colaborativ?
Care sunt caracteristicile serviciilor web i modelele relevante de compunere a serviciilor

?
Ce presupune adaptivitatea aplicaiilor bazate pe servicii?
Care sunt principalele abordri privind adaptivitatea aplicaiilor bazate pe servicii?
Care sunt paii unei proceduri ce trebuie aplicat n cadrul schimbrii organizaionale?
Cum se evalueaz impactul schimbrilor la nivel de procese n cadrul organizaiei?
Care este algoritmul care st la baza produsului program?
Cum poate fi implementat optim produsul program?
3. Organizarea tezei
Teza este organizat n felul urmtor:
Capitolul unu descrie stadiul actual al cunoaterii n domeniul sistemelor informaionale evoluate
complexe distribuite geografic dup cum urmeaz: trsturile caracteristice cadrului de modelare
al sistemelor informaionale evoluate (1.1), spaiul cunoaterii universului FInES(1.2.2) i
direcia de cercetare Horizon 2020 (1.2.3), clasa sistemelor Collaborative Networked Systems
(1.3.2), modele de compunere a serviciilor (1.3.3) i abordri privind adaptabilitatea aplicaiilor
orientate ctre servicii(1.3.4)
Capitolul doi descrie cerinele i specificaiile la nivel conceptual pentru metodologia de

integrare a organizaiilor(E2IN). n (2.1) sunt descrise integrarea i interoperabilitatea la nivel de
ntreprindere, n (2.2) se prezint cele patru niveluri de interoperabilitate i cele cinci niveluri de
eficien a interoperabilitii. Evoluia sistemelor informaionale complexe de la Enterprise
Application Integration la sisteme informaionale evoluate FInES este descris n (2.3). n (2.4)
este identificat probla de rezolvat, iar n (2.5) este propus suportul formal pentru rezolvarea
problemei.
18
Capitolul trei prezint soluia pentru problema identificat. Aceasta const ntr-un cadru de
modelare pentru managementul organizaional al metasistemului CNO organizat pe patru niveluri
i o metod ce conine mai muli pai ce vor fi aplicai n cadrul procesului de schimbare (3.3). n
(3.1) este prezentat ciclul de via al unei organizaii virtuale, iar n (3.2) sunt prezentate
dimensiunile VBE, acestea fiind extinse cu o vedere sistemic. n (3.4) este prezentat metoda
utilizat pentru implementarea mangamentului schimbrii n cadrul metasistemului CNO.
Capitolul patru prezint instrumentul software dezvoltat pentru analiza impactului schimbrilor la
nivel de procese modelate folosind standardul BPEL. n (4.2) este descris modelul de proces
orientat ctre servicii propus. n (4.3) este descris relaia dintre nivelul proces i nivelul servicii
iar n (4.4) este propus algoritmul pentru determinarea impactului schimbrilor n cadrul unui
proces orientat ctre servicii.
Capitolul cinci prezint studiul de caz. n (5.2) este descris scenariul propus iar n (5.3) sunt
descrise procesele BPEL create pentru studiul de caz descris, mpreun cu exemple de rulare a
aplicaiei dezvoltate pentru determinare a impactului schimbrilor la nivel de proces.
Concluziile reprezint ultimul capitol al acestei lucrri.
4. Lucrri susinute n vederea validrii publice a unor rezultate pariale ale

demersului de cercetare
Au fost elaborate i publicate urmtoarele lucrri:

Articole n jurnale ISI
Cristian Danila, Georgiana Stegaru, Aurelian Mihai Stanescu: Web-Service based
Architecture to support SCM context-awareness and interoperability, Journal of
Intelligent Manufacturing, 2013 - n curs de aprobare pentru publicare
Georgiana Stegaru, Cristian Danila, Ioan Sacala, Mihnea Moisescu, Aurelian Mihai
Stanescu: E-Services Quality Assessment Framework for Collaborative Networks,
Enterprise Information Systems Journal, 2013, n curs de publicare
Articole n cadrul unor conferine ISI
Georgiana Stegaru, Cristian Danila, IoanStefan Sacala, Mihnea Moisescu, and Aurelian
Mihai Stanescu: Quality Driven Web Service Composition Modeling Framework, PRO-
VE 2012
Articole n cadrul unor conferine indexate n baze de date internaionale
George Burlacu, Luiza Cojocaru, Cristian Danila, Dan Popescu, Aurelian Stanescu: A
Digital Business Ecosystem Integrated Approach for Farm Management Information
System, 2nd International Conference on Systems and Computer Science(ICSCS), 2013 -
IEEE
Cristian Danila, Aurelian Stanescu, Ricardo Goncalves, Carlos Agostinho, Adina Florea,
Cristina Serbanescu: Towards a holistic approach for Developing Sensing Enterprise
19
Modelling Framework, IFAC Coference on Manufacturing Modeling, Management and

Control (MIM'2013), 2013
Cristian Danila, Aurelian Mihai Stanescu: Change impact analysis in WS-BPEL
processes, Buletinul UPB, 2013 - n curs de recenzie
Natalia Costetchi, Cristian Danila, Aurelian Mihai Stanescu: Enterprise System
Architecture to sustain cross-domain eHealthcare Applications, 7th International
Conference Interoperability for Enterprise Systems and Applications (I-ESA'14), 2014 -
acceptat provizoriu
Georgiana Stegaru, Cristian Danila: Quality Driven ModellingFramework for Service
based Manufacturing Systems , 14th IFAC Symposium on Information Control Problems
in Manufacturing (INCOM - Information Control Problems in Manufacturing), 2012
Articole n cadrul unor conferine Non-ISI
Cristian Danila, Georgiana Stegaru, Aurelian Mihai Stanescu: Framework for runtime
prediction of service failure based on fuzzy logic using time series data mining method,
UNITE 2nd Doctoral Symposium, 2012
Cristian Danila, Ioan Stefan Sacala, Mihnea Moisescu, Natalia Costetchi, Aurelian Mihai
Stanescu: Future Internet Enterprise Systems: towards the Sensing Enterprise,
International Conference on System Theory, Control and Computing (ICSTCC), 2012
Acknowledgement
Rezultatele prezentate n aceast tez de doctorat au fost obinute cu sprijinul financiar al

Ministerului Muncii, Familiei i Proteciei Sociale prin Fondul Social European, Programul
Operaional Sectorial Dezvoltarea Resurselor Umane 2007-2013, Contract nr.
POSDRU/107/1.5/S/76813.
Realizarea acestei teze de doctorat este o consecin a proiectului de Cresterea competitivitatii

intreprinderilor prin perfectionarea si specializarea resurselor umane in domeniul noilor
tehnologii, intr-o societate bazata pe cunoastere si pentru o dezvoltare durabila, Contract nr.
POSDRU/81/3.2/S/53084.
20
CAPITOLUL 1
STADIUL ACTUAL AL CUNOATERII N DOMENIUL SISTEMELOR

INFORMAIONALE EVOLUATE, COMPLEXE, ADATIVE, DISPERSATE
GEOGRAFIC
1.1. TRSTURI CARE DEFINESC UN CADRU DE MODELARE PENTRU UN

SISTEM DE SISTEME INFORMAIONALE, COMPLEXE, ADAPTIVE, DISPERSATE
GEOGRAFIC, CU MODELE ORGANIZAIONALE DIN CATEGORIA ORGANIZAIILOR
VIRTUALE
1.1.1. Universul discursului
n acest subcapitol vor fi prezentate trsturile caracteristice FInES vzut ca un CASoS.

Universul de discurs utilizat n definirea metodologiei de configurare dinamic a unui metasistem
FInES este prezentat n figura 1.
21
Fig. 1.1 Trsturi caracteristice conceptului FInES
a) CNO
Prin prisma schimbrii de paradigm propus de trecerea de la societatea informaional la
societatea bazata pe cunoatere, comportamentul economic al ntreprinderilor si plasarea lor in
contextul social sufer modificri eseniale, n concordanta cu mediul de afaceri.
In acest context se poate observa evoluia ntreprinderii ntr-un mediu distribuit, interconectat,
precum si necesitatea transformrii modului de lucru in acest mediu.
Reelele colaborative (Collaborative Networks) reprezint una din cele mai relevante
paradigme organizaionale n cadrul industriei i al serviciilor. Participarea n cadrul unei reele a
devenit foarte important pentru o organizaie mic sau mijlocie care dorete s obin avantaje
asupra competiiei. Colaborarea reprezint o problem cheie n ceea ce privete ntmpinarea
cerinelor pieei, n special n sectorul de producie, prin schimbul de competene i resurse.
O reea colaborativ este o reea format din diferite entiti (organizaii, oameni, maini)
autonome, eterogene, distribuite geografic, dar care colaboreaz pentru atingerea unui scop
comun sau compatibil, aducnd astfel valoare adugat i ale crei interaciuni se bazeaz pe
infrastructura oferit de reelele de calculatoare . [9]
Un CNO poate fi definit ca un metasistem n care entitile / nodurile reelei sunt bazate pe
reelarea / relaionarea internetului viitorului i orientate organizaional pe un model
colaborativ.
22
In cadrul reelei colaborative se creeaz ntreprinderi virtuale (VO - Virtual Organization), entiti
independente de spaiul geografic, coerente si complementare din punct de vedere funcional.
Eficacitatea procesului de creare a ntreprinderilor virtuale st la baza apariiei unor organizaii
dinamice in cadrul unui mediu virtual de dezvoltare (VBE - Virtual Breeding Environment).
b) VBE
Virtual Breeding Environment (VBE) reprezint o asociaie de organizaii nfiinat pe baza unui
acord de cooperare pe termen lung, asociaie ce are ca principal scop posibilitatea crerii de
aliane temporare, uor configurabile. Principalul avantaj l constituie uurina de a gsi parteneri
n cadrul VBE, precum si posibilitatea de formare a unei reele colaborative n timp util, pentru a
eficientiza la maxim orice oportunitate de afacere. Conceptul de reea colaborativ este unul
dinamic, ntruct apar in permanen noi forme de reele colaborative in funcie de contextul
economic existent si de oportunitatea de afacere aprut.
c) IoS
Internetul Serviciilor (IoS - Internet of Services) reprezint o viziune a internetului n care orice
informaie, software, platform sau infrastructur este disponibil ca un serviciu web. Serviciile
web disponibile n cadrul IoS pot fi folosite de ctre oricine respect politica definit de
furnizorul de servicii. Avantajul major oferit de IoS este reprezentat de posibilitatea de a reutiliza
serviciile deja create pentru crearea de aplicaii cu o investiie minim n prealabil.
O definiie a serviciului web este publicat de ctre Consoriul World Wide Web (W3C) [7]:
Un serviciu web este un sistem software identificat de ctre un URI (Uniform Resource
Identifier), ale crui interfee publice si legturi sunt definite si descrise folosind XML. Definiia
lui poate fi descoperit de alte sisteme software. Aceste sisteme pot apoi s interacioneze cu
serviciul Web intr-o manier descris de definiia sa, folosind mesaje de tip XML, transmise pe
baza protocoalelor Internet.
d) SBS
Serviciile web sunt descrise, publicate, descoperite i pot fi compuse pentru a crea Sisteme
Bazate pe Servicii (SBS) care sunt distribuite. Serviciile web i SBS implic modificri majore n
felul n care software-ul este dezvoltat, instalat, meninut. Trei mari clase de provocri ce
trebuie adresate au fost identificate [8]:
Evoluie i adaptare: SBS ruleaz n medii de afaceri dinamice i adreseaz cerine n

continu evoluie. Aceste sisteme trebuie s aib capacitatea de a identifica schimbrile
privind cerinele mediului de afaceri i ale contextului aplicaiei i de a reaciona ntr-un
mod adecvat la acestea. Pe lng mecanismele folosite la rulare i strategiile care trebuie
s susin adaptabilitatea sistemului, sunt necesare noi abordri de proiectare i
construcie care s foloseasc aceste mecanisme i strategii pentru construirea SBS.
Asigurarea dinamic a calitii: pentru a oferi o calitate end-to-end pentru SBS

distribuite global, aspectele calitative nu trebuie doar negociate i agreate, dar trebuie
verificate n timpul rulrii aplicaiei. Pentru a dezvolta capacitatea SBS de a se adapta,
exist o nevoie tot mai mare de automatizare a procesului de negociere a atributelor
23
calitative ce sunt stipulate n SLA (Service Level Agreement) i de tehnici de verificare i

validare care s poat fi aplicate la rulare.
Interaciunea dintre nivelele tehnologice: La momentul actual, practicile de dezvoltare ale

aplicaiilor bazate pe servicii pe baza arhitecturilor SOA iau n considerare trei nivele
tehnologice: infrastructura serviciilor, compoziia i coordonarea serviciilor, i
managementul proceselor de afaceri (BPM - Business Process Management).
Dezvoltarea unor servicii software i SBS inovative presupune nelegerea interaciunilor
dintre nivele tehnologice.
n lucrarea de fa ne vom concentra asupra adaptabilitii SBS. Problema construciei de sisteme
de calcul adaptive ctig o importan din ce n ce mai mare.
e) TQM
Managementul calitii totale (TQM - Total Quality Management) reprezint efortul global al
unei organizaii de a crea un climat n care organizaia i mbuntete abilitatea de a furniza
produse i servicii de calitate clienilor.
f) Collaborative Work
Acest termen acoper o varietate de modaliti n care dou sau mai multe organizaii pot lucra
mpreun. Poate avea o durat de timp limitat sau ndelungat. Implic schimburi i avantaje
mutuale, cu scopul de a oferi satisfacie clientului.
g) DDBE
Ecosistemul digital de afaceri (DBE - Digital Business Ecosystem) este descris n [13] ca
rezultatul dependenei structurale dintre ecosistemul digital i ecosistemul de afaceri. Conceptul
de ecosistem de afaceri a fost definit de J.F. Moore ca o comunitate economic ce are ca
fundament o mulime de organizaii i indivizi care interacioneaz. Aceast comunitate produce
bunuri i servicii pentru clieni, i face parte dintr-un ecosistem. Ecosistemul Digital reprezint
un mediu digital persistent populat de componente digitale care evolueaz i se adapteaz
condiiilor locale odat cu evoluia componentelor sale. Ecosistemul digital i ecosistemul de
afaceri sunt interconectate i coexist formnd un sistem dinamic inovativ. DDBE (Dynamic
Digital Business Ecosystem) reprezint un cosistem de afaceri care se deruleaz ntr-un mediu de
comunicaie digital i care rspunde unor schimbri impredictibile sub influena
stimuli/perturbaii exogene i endogene
h ) SOC
SOC (Service Oriented Computing) [243] este o paradigm ce utilizeaz serviciile ca i blocuri
constructive pentru a crea soluii software slab-interconectate. Serviciile sunt oferite de
componente software ce pot fi descrise, descoperite i compuse ntr-un mod interoperabil.
i) E2IN
Enterprise Integration and Interoperability Networking (E2IN) reprezint o direcie de cercetare
orientat ctre investigarea principiilor, modelelor de referin, metodologiilor de modelare,
metodelor aplicative, protocoalelor ICT ce guverneaz reelele colaborative de ntreprinderi.
24
Ariile de cercetare ale E2IN sunt reprezentate de integrarea i interoperabilitatea la nivel de

ntreprindere precum i de reelele de ntreprinderi.
n acest subcapitol am prezentat pe scurt trsturile relevante pentru universul discursului:
FInES, CNO, VBE, IoS, SBS, TQM, Collaborative Work, DDBE, SOC, E2IN . n capitolele
urmtoare acestea vor fi reluate i prezentate n amnunt.
1.2. CERINTE, ATRIBUTE, PROPRIETI ALE UNUI SISTEM DE SISTEME
(METASISTEM) INTEGRAT PRIN TEHNOLOGII EVOLUATE INTERNET: INTERNETUL
OBIECTELOR, INTERNETUL SERVICIILOR SEMANTIC WEB, INTERNETUL
CUNOATERII, INTERNETUL COMUNITILOR (SOCIALIZRII)
1.2.1. Introducere
n acest paragraf vor fi prezentate cerinele/atributele/proprietile categoriei de sisteme FInES,
aa cum au fost ele prezentate n viziunea comisiei europene. n sub-paragraful 1.2.2 este
prezentat universul cunoaterii FInES i cele patru spaii ale sale: spaiul socio-economic, spaiul
ntreprinderii, spaiul aplicaiilor, platformelor i sistemelor ntreprindere precum i spaiul
tehnologic. Sub-paragraful 1.2.2 prezint direcia de cercetare Horizon 2020 mpreun cu cele
cinci teme de cercetare propuse: Internetul Viitorului n contextul Parteneriatului Public Privat,
antreprenoriatul Web, Sensing Enterprise, ntreprinderea Digital i Collaborative Awareness
Platforms .
1.2.2. Spaiile cunoaterii universului Future Internet Enterprise Systems

Universul cunoaterii FInES este organizat n concordan cu urmtoarele patru spaii ale
cunoaterii
a) Spaiul Socio-economic
Acest spaiu reprezint contextul extins n care opereaz ntreprinderea. Printre subiectele de
interes pot fi enumerate: responsabilitatea social, impactul asupra mediului, sau sistemul de
valori.
b) Spaiul ntreprinderii
Acesta este spaiul unde pot fi adresate cele nou caracteristici cheie, cunoscute ca i caliti de
baz ale ntreprinderii. Paradigma de continu inovare este susinut prin impactul celor nou
caliti de baz asupra noilor modele de producie i afaceri, noile paradigme de guvernan i
organizare, noi forme de cooperare.
c) Spaiul Aplicaiilor, Platformelor si Sistemelor ntreprindere
Acest spaiu este dedicat soluiilor ICT i sistemelor socio-tehnice care vizeaz sprijinirea
ntreprinderilor Viitorului ce vor opera n cadrul Internetului Viitorului. Aspectele conturate n
acest spaiu vor fi aliniate cu nevoile de afaceri pentru ntreprinderile Viitorului, care merg de la
managementul cunotinelor semantice pn la cooperarea online, precum i noi paradigme
operaionale cu scopul de a ncuraja inovarea continu.
25
d) Spaiul Tehnologic
Spaiul tehnologic cuprinde soluiile bazate pe Internetul Viitorului, reprezentarea cunotinelor,

cooperarea i interoperabilitatea, securitatea, serviciile autonome i pro-active ce vor fi necesare
pentru dezvoltarea FInES.
Cele patru spaii se ntreptrund ca n figura 1.2. Putem observa c spaiul socio-economic
cuprinde spaiul ntreprindere, spaiul aplicaiilor, platformelor i sistemelor ntreprindere precum
i spaiul tehnologic. De asemenea, o mare parte din spaiul tehnologic este cuprins n spaiul
ntreprindere i spaiul FInES.
Fig. 1.2. Diagrama Venn a universului de cunoatere FInES [14]
Figura 1.2. reprezint o reprezentare sumar a relaiilor dintre cele patru spaii ale cunoaterii n
cadrul universului FInES. [14]
n continuare vom detalia fiecare spaiu.
Spaiul socio-economic
Spaiul socio-economic reprezint contextul cel mai larg n care o ntreprindere i desfoar
activitatea, interacionnd cu ali juctori de pe pia i mediul, avnd ca int producerea de
bunstare i satisfacia prilor implicate.
Datorit economiilor europene care nfrunt numeroase crize economice care se succed, s-a
format un curent conform cruia modelele socio-economice curente nu ar mai trebui s existe n
forma lor actual: s-a atins un punct de discontinuitate, un punct de bifurcaie. Sunt semne clare
26
c rile europene nu pot continua pe aceeai linie, datorit numeroaselor eecuri ale sistemelor
financiare, a degradrii mediului i a deteriorrii standardului de via al populaiei. Modelele de
dezvoltare europene au nevoie de o schimbare a paradigmei pentru a menine i mbunti
standardul curent de via.
Cheia problemei europene va fi gsirea n viitorul apropiat (urmtoarea decad) a unui model
capabil s garanteze creterea nivelului de trai, n contextul unor economii care nu vor putea s
ofere o cretere i expansiune constante. Obiectivul este de fapt obinerea unei bun-stri socio-
economice n cretere fr o cretere echivalent a bogiei produse de sistemele industriale.
Trebuie adresat n primul rnd modelul de cretere economic, unde mecanismele bazate pe
consumerism, dublate de o cretere a consumului i a produciei trebuie revizuite. Pentru aceasta,
o serie de noi direcii sunt luate n calcul privind reinterpretarea bogiilor unei ri privind din
perspectiva unor noi indicatori, satisfacerea nevoilor societii prin alte metode dect cele oferite
n cadrul societii bazate pe consum, optimizarea, reutilizarea i reciclarea bunurilor.
Pentru a atinge obiectivele precizate anterior, viziunea FInES este reprezentat de o societate
total interconectat, unde interoperabilitatea cultural va reprezenta baza unei noi forme de
inovare social. Internetul este cel care schimb metodele prin care persoanele se cunosc, in
legtura, schimb informaii, preri, cunotine.
Conform strategiei Lisabona, Europa trebuie s evolueze ctre o economie bazat pe cunoatere
[4]. Acest obiectiv pare mai greu de realizat dect s-a crezut iniial, probabil i datorit crizelor
economice. Dezvoltarea i adoptarea tehnologiilor bazate pe cunotine nu este suficient.
Oamenii stau la baza unei societi bazate pe cunotine. Trebuie imaginat un model socio-
economic unde dezvoltarea tehnologic va avea loc punnd oamenii n centru. Trebuie creat o
baz cultural pentru inovare care va fi adoptat nu numai n mediul de producie dar i n viaa
social, nivelnd astfel cunotinele i competenele fiecrui individ. Un alt rol esenial n mediul
socio-economic va fi jucat de ntreprinderi. Acestea reprezint principalul factor de producie,
avnd n acelai timp o contribuie important la evoluia social i cultural. ntreprinderile vor
aciona att n contextul intern fcnd aici referire la modelul organizaional, managementul
resurselor umane, producie i logistic precum i n contextul extern innd cont de strategiile de
marketing i relaiile cu clienii.
Spaiul ntreprinderii
Spaiul ntreprinderii este spaiul unde sunt adresate caracteristicile ntreprinderilor viitorului,
modelele de producie i de afaceri emergente, noi paradigme organizaionale i de conducere,
noi forme de cooperare, toate orientate ctre o inovarea continu. ntreprinderile viitorului ar
trebui s-i bazeze succesul pe cunotine, aptitudini i competene, creativitate i inovare,
contientizarea oportunitilor i a riscurilor, avnd o atitudine neleapt n ceea ce privete
riscurile, i adoptnd soluiile ICT n funcie de nevoile afacerii.
n acest spaiu vor fi adresate cele nou caliti de baz ale ntreprinderii viitorului. Acestea sunt
suficient de generale pentru a putea fi aplicate majoritii ntreprinderilor, independente de
mrimea lor, naionalitate sau sectorul industrial din care fac parte. Aceste caliti reprezint de
fapt nite obiective care trebuie atinse de ntreprinderi. Pentru a le putea atinge, ntreprinderile
trebuie s adopte noi forme organizaionale i noi abordri operaionale. Cele nou caliti de
baz ce vor fi descrise n continuare sunt: ntreprinderea umanist, ntreprinderea inventiv,
27
ntreprinderea agil, ntreprinderea cunoaterii, ntreprinderea vie (Sensing Enterprise),

ntreprinderea orientat ctre comunitate, ntreprinderea lichid, ntreprinderea glocal i
ntreprinderea sustenabil.
ntreprinderea Umanist
Timp de secole, scopul principal al ntreprinderilor a fost acela de a maximiza profitul si de a crea
bunstare. ncepnd cu revoluia industrial a lui Taylor [15] componenta uman a fost
subordonat acestui scop (de a maximiza profitul, i implicit i mainilor). Odat cu apariia
conceptului de economie a cunotinelor, bunurile tind s devin imateriale fiind reprezentate de
inteligena i cunotinele angajailor, introducnd o schimbare progresiv a mijloacelor de
producie, de la angajatori ctre angajai. ntreprinderea Umanist pune persoana (omul) n
centru, fie ea: un angajat, un consultant, un partener sau client. n ceea ce privete performana, o
ntreprindere Umanist are ca scop producerea de bunstare i bogie, considernd prile
interesate ca fiind: resursele umane, clienii, populaia din contextul socio-economic n care
ntreprinderea acioneaz. [16]
ntreprinderea Inventiv
ntreprinderea Inventiv este capabil s suporte ntregul ciclu al inovaiei, de la invenia n sine
i pn la producie i comercializare, implicnd toate departamentele, de la organizare pn la
logistic i resurse umane. De asemenea, ntreprinderea Inventiv este capabila s mbine
capacitatea de a inventa cu abilitatea de a transforma ideile inveniile, adic este capabil sa
transforme ideile inventive n aplicaii n domeniul afacerilor, pentru ca apoi s schimbe rapid
mecanismul de producie pentru a implementa noile soluii, fr a opri desfurarea afacerii.
ntreprinderea Agil
ntr-o lume n continu schimbare, schimbrile au o dubl influen asupra ntreprinderilor.
Influena pozitiv este reprezentat de soluiile inovative care pot fi adoptate in beneficiul
ntreprinderii i al parilor interesate, dac lum n considerare oportunitile de extindere a
pieelor de desfacere i a creterii produciei. Influena negativ este reprezentat de inovaia
declanat de competitori care devin agresivi, clieni nemulumii, sau de economia global
zguduit de criz. ntreprinderea Agil este ntreprinderea capabil s reacioneze la evenimentele
neprevzute, endogene sau exogene, dnd dovad de flexibilitate si adaptabilitate n organizare,
strategii si planuri de producie. [17] Acest tip de ntreprindere este de asemenea proactiv, fiind
capabil s anticipeze viitoarele schimbri, transformndu-se rapid pentru a prentmpina nevoile
inovative. [16]
ntreprinderea Cunoaterii
Cantitatea enorm de cunotine care poate fi produs sau descoperit pe Internet, i stocat intr-o
baz de cunotine, nu poate avea nici un efect asupra afacerii dac nu este pus n aplicare( nu
este nglobat n comportamentul agenilor ntreprinderii, fie ei umani sau artificiali).
ntreprinderea Cunoaterii depete graniele managementului cunotinelor, scopul ei fiind nu
numai acela de a acumula cunotine, ci de a gsi o modalitate de le pune n aplicare, de a stabili
contextul si efectele aplicrii lor, riscuri i alternative. [18]
ntreprinderea Vie (Sensing Enterprise)

Odat cu rspndirea reelelor de senzori, managementul afacerii in timp real se va schimba
progresiv. Pentru a exploata pe deplin potenialul inerent al Internetului Obiectelor si al
obiectelor inteligente, este nevoie de o decentralizare a inteligenei ntr-o ntreprindere vzut ca
28
o entitate inteligent, complex capabil s simt i s reacioneze la stimuli din mediul

afacerilor. [16]
ntreprinderea Vie (Sensing Enterprise) este un concept creat n anul 2011 de comunitatea FInES
n contextul apariiei i dezvoltrii Internetului Augmentat (Augmented Internet). Ea se refer la
o ntreprindere care anticipeaz deciziile viitoare folosind informaia multidimensional capturat
i mbogit prin intermediul obiectelor fizice i virtuale, mbuntindu-i astfel capacitatea de
contientizare a contextului. [16]
Traducerea termenului Sensing Enterprise n termenul ntreprinderea Vie a fost fcut pe baza
analogiei ntre om, ca organism viu ce exist ntr-un ecosistem natural i este capabil s perceap
universul prin simuri fundamentale, s transforme datele n informaii i s raioneze inteligent
pe baza informaiilor obinute i ntreprinderea ca entitate ce exist ntru-un ecosistem artificial
de afaceri i este capabil s perceap prin senzori mediul exterior, contientiznd contextul i
raionnd pe baza informaiilor multidimensionale capturate.
ntreprinderea orientat ctre comunitate

Adoptarea extensiv a coninutului media social n cadrul ntreprinderii ofer posibilitatea
nivelrii inteligenei colective n cadrul diferitelor comuniti, att intern ntre angajaii aceleiai
ntreprinderi, cat si extern ntre diferii clieni, furnizori, pentru a mbunti performanele n
cadrul ntreprinderii. Inteligena comunitii va cunoate o cretere a importanei, iar cursul fluent
al informaiilor va asigura mbuntirea transparenei i a responsabilitii. Totui, problemele
referitoare la securitate i confidenialitate ar putea fi subestimate. [16]
ntreprinderea Lichid
Aceast caracteristic se refer la estomparea granielor ntreprinderii, unde o distincie ntre ceea
ce este interior i exterior ntreprinderii, cine sunt angajaii i partenerii sau cine sunt competitorii
i colaboratorii este greu de fcut. Noi forme de munc i colaborare vor nflori. Ca i n cazul
abordrii cloud, lichiditatea se va rspndi n cadrul ntreprinderilor i al sistemelor social-
tehnice, i dac va fi corect administrat, va aduce beneficii importante.
ntreprinderea Glocal
Globalizarea reprezint un fenomen aflat n continu expansiune de-a lungul a mai multor
dimensiuni: comercial, cultural, religios. ntreprinderile trebuie s abordeze problema globalizrii
pentru a supravieui i a se extinde, dar n acelai timp ele trebuie s opereze n anumite teritorii
unde se regsesc producia i pieele lor de desfacere, nvnd cum s fac fa normelor i
obiceiurilor locale. [19]
ntreprinderea Sustenabil
Aceasta este o dimensiune bine cunoscut a ntreprinderii, dar care nu poate fi neglijat.
Sustenabilitatea implic trei aspecte: economic, social, si al mediului nconjurtor. Ultimul aspect
implic impactul asupra mediului nconjurtor, de la consumul de materie prim i pn la
producerea de deeuri. Este important s reafirmm importana acestei dimensiuni deoarece
exist un risc de acomodare care duce la indiferen. Comportamentul verde ar trebui s devin
o mentalitate i un mod de lucru. Acesta, mpreun cu o atitudine plin de consideraie fa de
ecosistemul social, este o problem critic pentru bunstarea noastr i a urmailor notri.
Spaiul Aplicaiilor, Platformelor si Sistemelor ntreprindere
Punctele de interes care afecteaz dezvoltarea ntreprinderilor viitorului pot fi organizate de-a
lungul a trei dimensiuni: dimensiunea cunoaterii, dimensiunea funcional i dimensiunea
29
ingineriei. n acest spaiu sunt identificate metodologiile, platformele, aplicaiile, sistemele si

soluiile ICT care au ca scop suportul ntreprinderilor Viitorului.
Scopul FInES a fost de a identifica principalele metode i paradigme care modeleaz afacerile,
incluznd aici i resursele i obiectivele ce trebuie folosite direct de ctre experii business,
reducnd astfel rolul inginerilor cunotinelor. Printre acestea se numr: (i) (dimensiunea
cunoaterii ) ntreprinderea digital unificat, Linked Open Knowledge, modelarea sistemelor
complexe, (ii) (dimensiunea funcional) platforme ntreprindere orientate ctre inovare, sistemul
de management al ntreprinderii digitale unificate, platforme de cooperare i colaborare,(iii)
(dimensiunea ingineriei) proactive FInES mashup, componente i subsisteme de calcul autonom,
platforme flexibile de execuie.
Spaiul tehnologic
Spaiul tehnologic cuprinde un set de arii de cercetare conectate cu FInES. Ariile tehnologice
identificate de comitetul FInES sunt reprezentate de: reelistic, cunotine, aplicaii, stocare de
date si interaciuni cu utilizatorul.
1.2.3. Direcia de cercetare Horizon 2020

n ciuda progresului tehnologic ICT, impactul actual este sub ateptri din cauza decalajului
dintre mediul socio-economic i tehnologii. ICT ofer noi soluii, de la cloud computing la
Internetul Obiectelor, de la reele sociale pn la noi forme de knowledge management.
ntrebrile curente sunt dac cercetarea tehnologic se ndreapt ntr-o direcie capabil s
promoveze paradigma schimbrii socio-economice, dac mediul socio-economic este capabil s
defineasc cerine clare ctre mediul de cercetare tehnologic i dac se poate stabili un spaiu
comun de colaborare ntre cele dou medii. Comisia FInES propune cinci teme de cercetare,
aliniate cu scopul i aria de interes ale unitii de cercetare E3 a direciei de cercetare Connect
(Communications Networks, Content and Technology) a Comisie Europene : [8]
Internetul Viitorului n contextul Parteneriatului Public Privat (FI -PPP )
Antreprenoriatul Web
Sensing Enterprise (SE)
ntreprinderea Digital (DE - Digital Enterprise)
Collaborative Awareness Platforms

Internetul Viitorului, Sensing Enterprise i Collaborative Awareness Platforms au o orientare
tehnologic pe cnd celelalte dou o orientare socio-economic.
Direcia de cercetare H2020 este bazat pe trei piloni centrali: excelena n tiin, leadership-ul
industrial i provocrile sociale. Nevoie de excelen n tiin se bazeaz pe faptul c tiina de
clas mondial reprezint fundamentul tehnologiilor de mine, locurilor de munc i bunstrii.
Pe de alt parte, nevoia de leadership industrial este bazat pe observaiile c investiiile
strategice n tehnologii cheie (ICT, nanotehnologii, microelectronice) susin inovarea de-a lungul
sectoarelor existente i emergente, c Europa are nevoie s atrag mai mult capital privat n
cercetare i inovare i faptul c Europa are nevoie de mai multe ntreprinderi Mici si Mijlocii
inovative care s creeze locuri de munc i cretere. Raionamentul din spatele provocrilor
30
sociale const n faptul c obiectivele cetenilor i ale societii (climat, transport, mediu,
energie) nu pot fi adresate fr inovare.
n ultimii ani potenialul tehnologiilor Internetului Viitorului au stat la baza Internetului
Viitorului bazat pe Parteneriatul Public Privat (FI-PPP). Mai mult dect att, dezvoltndu-se cu
succes n ultima vreme, antreprenoriatul web este acum mai important dect oricnd nainte,
datorit n special a impactul crizei economice asupra creterii europene i ocuprii forei de
munc. Folosirea potenialul tehnologic al Internetului Viitorului pentru susinerea
antreprenoriatului web n sectoarele-cheie de activitate economic va fi o provocare major ce va
trebui depit n anii urmtori. n aceast direcie, aa cum a fost artat mai sus, FInES a definit
deja calitile de baz ale ntreprinderilor Viitorului.
Fig 1.3. Inovarea n domeniul afacerilor digitale
Inovarea n domeniul afacerilor digitale se afl la intersecia a trei domenii mari de cercetare
(baza tehnologic, inovarea n domeniul afacerilor i antreprenoriatul). Bazele tehnologice au n
componen elementele tehnice cheie care faciliteaz dezvoltarea unor noi afaceri digitale sau
mbuntesc performana proceselor de afaceri existente. Inovarea n domeniul afacerilor se
ocup cu acele metode, unelte i cadre socio-tehnologice care permit implementarea diferitelor
modele de afaceri capabile s genereze reele de afaceri inovative n diferite sectoare economice.
Antreprenoriatul presupune dezvoltarea unor unelte specifice i a unor ecosisteme de afaceri
tehnico-economice care faciliteaz dezvoltarea sustenabil a ntreprinderilor Mici i Mijlocii
inovative i a ecosistemelor de afaceri.
Avnd la baz noiunile de Sensing Enterprise i de ntreprindere Digital, inovarea n domeniul
afacerilor digitale micoreaz distana dintre tehnologii, metode, unelte i cadre de afaceri cu
misiunea de a facilita emergena unor procese de afaceri mbuntite sau chiar noi n cadrul
ntreprinderilor, care s conecteze ntreprinderea cu reelele sociale de afaceri, Internetul
Obiectelor i cu capacitatea de a exploata bunurile tangibile i intangibile cum ar fi noiunea de
inteligen colectiv.
31
FI-PPP
FI-PPP reprezint o oportunitate european de a capitaliza avantajele oferite de internet n

sectoare de mare importan pentru a mbunti competitivitatea ntreprinderilor europene. FI-
PPP ofer posibilitatea unei ci alternative ctre adopia unei noi forme de inovare n afaceri, noi
metode de suport i dezvoltare a antreprenoriatului, utilizarea unor noi tehnologii care s inspire
noi forme de colaborare i noi tipuri de relaii de afaceri, ducnd la dezvoltarea unor noi tipuri de
ntreprinderi i ecosisteme de afaceri.
Programul FI-PPP urmrete creterea eficienei proceselor de afaceri i a infrastructurilor care
suport aplicaii n domenii ca: sntate, energie, producie i logistic, precum i dezvoltarea
unor modele de afaceri inovative care s ntreasc poziia competitiv industrial european n
domenii ca: telecomunicaii, dispozitive mobile, software i servicii, media.
FI-WARE [20] reprezint o nou infrastructur de servicii, construit din elemente numite
enabler-e generice. Acestea ofer funcii reutilizabile care pot fi folosite de ctre toat lumea,
facilitnd dezvoltarea Aplicaiilor Internetului Viitorului n numeroase sectoare. Adoptarea
enabler-elor FI-WARE ar putea duce la emergena unor ecosisteme bazate pe colaborare dar i pe
platforme de servicii concurente.
Transformarea digital este un concept ce se refer la schimbrile asociate cu aplicarea
tehnologiei digitale n toate aspectele societii umane [21]. Ea poate fi vzut ca i cel de-al
treilea pas al adoptrii tehnologiilor digitale: (1) competena digital, (2) alfabetizarea digital,
(3) transformarea digital. FI-PPP, cu o orientare ctre modelul de afaceri bazat pe servicii este
pe punctul unei transformri digitale n ceea ce privete modul curent de nelegere al proceselor
i modelelor de afaceri. FI-PPP se concretizeaz ca i un instrument de inovare, care intete ctre
transformarea digital n diferite sectoare economice care in de trei dimensiuni diferite: (1)
Fundaii Tehnologice bazate pe Platformele Centrale (Core Platforms) i pe enablerele generice;
(2) Inovarea n mediul afacerilor avnd ca scop validarea enablerelor generice ale Internetului
Viitorului prin implementri pilot; (3) Atreprenoriatul care promoveaz adoptarea la scar larg a
enablerelor generice n ntreprinderi, start-up-uri i IMM-uri. FI-PPP a fost gndit ca un program
cu scopul de a transforma diferite sectoare economice. Aceast transformare este exemplificat
prin adoptarea n mas (figura 1.4) a enabler-elor generice oferite de o versiune evoluat i mai
puternic a Internetului: Internetul Viitorului. Baza tehnologic puternic propus de FI-PPP ar
trebui s niveleze noile forme de afaceri ntre parteneri sau cel puin s determine obinerea unor
noi forme de operaiuni de afaceri.
32
Fig. 1.4. Ciclul de via al adoptrii tehnologiei [22]
Pentru a realiza noi forme de inovaii i antreprenoriat n mediul afacerilor online, FI-PPP ca
instrument de inovare i ecosistem complex ce implic diferii actori trebuie s depeasc o serie
de obstacole. Printre obstacolele identificate de comisia european [22] se numr: (1) nevoia FI-
PPP de a rspunde la cererile pieei (dinamica pieei); (2) generarea de procese de afaceri
orientate ctre client. Provocarea este aici de a genera treptat procese de afaceri care implic
procese intense orientate client de valorificare a tehnologiei; (3) uzabilitatea i sustenabilitatea
Internetului Viitorului. Provocarea const aici n a genera modele business care s determine
inovarea modelelor: social, de servicii, industrial (uzabilitate). Pentru sustenabilitate, provocarea
pentru FI-PPP este aceea de a adoptat la scar larg de IMM-uri; (4) Deschiderea IMM-urilor
ctre inovare, este reprezentat de faptul c acestea au fost destul de reticente n ceea ce privete
adoptarea noilor tehnologii datorit unor constrngeri cum ar fi: timp, expertiz sau costuri [23],
[24].
Antreprenoriatul Web
Antreprenorii Web(WE Web Entrepreneurs ) sunt vzui n cadrul agendei digitale 2020 ca o
categorie a ntreprinderilor digitale, avnd caracteristici specifice. Conform comisiei europene
[25] reprezint o categorie aparte de antreprenori care creeaz noi servicii digitale i produse care
folosesc web-ul ca i component indispensabil. Antreprenorul Web este un inovator care prin
utilizarea aplicaiilor web i a serviciilor ofer soluii de afaceri inovare cu un scop.
Antreprenorii web sunt i vor fi ntr-un numr tot mai mare o for motivatoare n Uniunea
Inovaiei (termen definit de comisia european), avnd un impact asupra serviciilor i produselor
n fiecare domeniu incluznd aici web-ul i ntreprinderea digital.
33
n contextul FInES, termenul de antreprenor web este complementar i ortogonal cu foaia de

parcurs FInES 2025 (FInES Roadmap 2025) deoarece aceasta din urm propune noi noiuni de
ntreprindere dar nu discut despre mecanismele care nlesnesc modul de a ajunge acolo. WE
reprezint unul dintre mecanismele care pot sta la baza ntreprinderii Agile sau a ntreprinderii
Vii, ei putnd fi integrai n paradigma FInES.
Deficitul european n momentul de fa const nu n idei, ci n posibilitatea de a transforma
aceste idei n afaceri de succes i n locuri de munc [22]. Cu toate acestea, n istoria european
nu a fost niciodat mai uor influenarea iniiativei globale dect este n ziua de azi. n trecut
antreprenorii trebuiau s investeasc sume masive de bani pentru punerea n aplicare a ideilor. n
ziua de azi, ideile mree se pot dezvolta pornind dintr-o ncpere cu un calculator conectat la
internet. Premisele pentru un astfel de parcurs al antreprenorilor web sunt reprezentate de: (i) un
spirit deschis i inovativ care s permit punerea bazelor afacerii fr frica de eec i (ii) o
infrastructur tehnic solid precum i un mediu legal/politic care s permit WE s se
concentreze asupra ideilor lor fr o prea mare grij asupra unor lucruri cum ar fi: cum se pot
obine anumite licene? Ce taxe trebuie pltite? Cum se poate obine o conexiune cu band larg
la internet?
Comisia european a identificat i pentru antreprenorii web un set de provocri n ceea ce
privete reutilizarea rezultatelor deja obinute prin activiti finanate din bani publici, acceptarea
ideilor acestora, crearea de programe pe termen lung care s sprijine dezvoltarea WE,
instrumente i proceduri n beneficiul acestora.
ntreprinderea Vie (Sensing Enterprise)
Conceptul SE a fost dezvoltat n cadrul FInES Cluster [26]. Definiia SE a fost publicat n [27]
i se refer la o ntreprindere capabil s anticipeze deciziile viitoare folosind informaia multi-
dimensional, capturat prin intermediul obiectelor fizice sau virtuale, care ofer valoare
adugat pentru a mbunti percepia asupra contextului global. Paradigma SE.ENV
imagineaz ntreprinderea ca o entitate inteligent complex capabil s simt i s reacioneze
la stimuli (business) n contextul obiectelor, echipamentelor i a infrastructurilor tehnologice
care posed capabiliti de procesare i transfer al datelor avansate, coopernd pentru a forma un
fel de sistem nervos n cadrul ntreprinderii. [28] Ea reprezint una din cele nou caracteristici
de baz ale ntreprinderii, aa cum a fost specificat mai sus.
Conceptul de ntreprindere care Simte deschide calea ctre o a treia lume (pe lng cea fizic i
virtual), lumea digital. n acest spaiu, fluxul continuu de informaii ce implic att obiecte
fizice i virtuale, precum i o inteligen decentralizat la scar larg, permite ntreprinderii s
dobndeasc noi capabiliti, proprieti si chiar noi identiti.
SE reprezint o aplicaie major n mediul business a viziunii de Internetul Obiectelor. n

Internetul Obiectelor, obiectele sunt conectate oriunde, oricnd cu oricine are acces la o reea.
Obiectele care fac parte din Internetul Obiectelor sunt inteligente, putnd comunica cu alte
obiecte inteligente, oferi i obine informaii i chiar lua decizii autonom n interesul oamenilor
sau organizaiilor de care aparin. Prin intermediul senzorilor i al obiectelor inteligente sistemele
ntreprindere reprezentate de SE este capabil s simt n timp real schimbrile din mediul intern
respectiv extern, s colaboreze i s rspund acestor schimbri.
34
Printre caracteristicile SE se numr: contientizarea global a contextului, inteligena

decentralizat, configurabilitatea dinamic, orientarea ctre identiti multiple, fuziunea dintre
real i virtual, re-invenia, precum si cele care ncep cu auto-: auto-adaptabilitatea, auto-
organizarea, auto-optimizarea, auto-configurarea, auto-protecia, auto-vindecarea, auto-descrierea
etc. [29]
Pentru a putea fi contient de contextul global n care i desfoar activitatea, ntreprinderea

primete date n timp real de la un numr mare de surse despre mediul nconjurtor
(intern/extern). Aceast date sunt apoi procesate i transformate n informaii folosite n procesul
de decizie. Informaiile sunt prelucrate mai departe i transformate n cunotine ce vor fi stocate
n baze de date de cunotine (figura 1.5).
Fig. 1.5. Problema cunotinelor [29]
Configurabilitatea dinamic este necesar pentru a asigura nivelul mare de flexibilitate necesar
sistemului pentru a opera. Datorit numrului mare de obiecte inteligente interconectate,
configurarea acestora este complex dar i critic pentru asigurarea integritii, robusteii dar i
securitii sistemului ntreprindere.
Opernd n trei dimeniuni diferite: fizic, virtual i digital SE va avea identiti multiple
deservite de multiple sisteme ntreprindere interactive. Ea poate avea obiective specifice n
fiecare dintre cele trei dimensiuni. Obiectele inteligente devin actori n cadrul ntreprinderii,
acionnd din proprie iniiativ la stimulii interni i externi i contribuind astfel la decentralizarea
inteligenei.
O serie de elemente cheie pentru SE sunt prezentate de ctre Man-Sze Li i reproduse n figura
1.6.
35
Fig. 1.6. Capabilitati ale SE [29]
Provocrile identificate de comisia european n ceea ce privete SE sunt: (1) provocri

funcionale i tehnologice (procesarea unei cantiti mari de date, securitate i ncredere,
interoperabilitate semantic, acurateea datelor, autonomia i morfologia obiectelor inteligente,
organizarea global a serviciilor); (2) provocri legate de arhitectur (limitele Internetului
Obiectelor, middleware pentru reelele de senzori, reele semantice de senzori, cine vorbete cu
cine i ce controleaz, cum pot fi integrate diferitele platforme IoT i ecosisteme); (3) provocri
politice i provocri ce provin din mediul de afaceri (noi modele de inovare business, distribuirea
controlului i a puterii de decizie ntre oameni i obiectele inteligente n cadrul ntreprinderii).
ntreprinderea Digital
ntreprinderea Digital este vzut ca o organizaie ce utilizeaz tehnologia digital n cadrul

operaiilor interne i externe pentru a obine un avantaj important asupra competitorilor [22]. n
contextul Internetului Viitorului, se concentreaz asupra dezvoltrii de activiti business prin
intermediul modelelor business care ncorporeaz tehnologii digitale. Astfel, ntreprinderea
Digital adreseaz noi forme de ntreprindere care au n componen active digitale o
conectivitate ad-hoc extensibil i procese de afaceri mbuntite prin integrarea capabilitii de
a simi. Acest tip de ntreprindere mbrieaz noi modele de relaii business inovative oferind
suport pentru ntreprinderea Virtual, ntreprinderea Agil, ntreprinderea Extins. De asemenea,
SE este susinut de componente inteligente care permit o contientizare continu i o
mbuntire a operaiilor business ntr-un mediu digital care va oferi noi tendine i modele
business.Dintre toate conceptele asociate cu ntreprinderea Digital, cel mai de interes este
reprezentat de SE datorit relevanei sale n ceea ce privete suportul oferit pentru implementarea
viziunii Horizon 2020. Conceptul SE a aprut odat cu evoluia Internetului Obiectelor, a
obiectelor inteligente, echipamentelor i a infrastructurii tehnologice ce permite mbuntirea
capabilitii de procesare i a reelisticii, lucruri care duc la o cooperare mbuntit n cadrul
ntreprinderii.
36
Nevoia de dezvoltare a conceptului de ntreprindere Digital a rezultat din mediul business global
care este lovit de un val fr precedent de inovare. Astfel, ntreprinderea Digital reprezint o
imagine digital a ntreprinderii, cuprinznd date conceptuale dar i fizice, aspecte
comportamentale i structurale. Beneficiile rezultate din implementarea ntreprinderii Digitale
pentru economia european sunt multiple. Astfel, ntreprinderile europene vor deveni mai agile n
ceea ce privete adaptarea proceselor lor business si exploatarea infrastructurii tehnologice la
schimbrile din mediul de afaceri. De asemenea, vor fi capabile s schimbe informaii cu
furnizorii, clienii i partenerii, indiferent de poziia geografic sau diferenele culturale.
ntreprinderile vor putea de asemenea s adopte modele de referin business fr a avea nevoi de
aptitudini speciale, ntr-un mod rapid i uor, prin folosirea unor utilitare de asisten web care
vor oferi servicii pentru o nelegere mai uoar a modelelor n mediile de afaceri.
Viziunea comisie europene n Horizon 2020, de a implementa conceptul de ntreprindere
Digital, abordeaz problema cunotinelor care n cadrul ntreprinderii sunt fragmentate (stocate
n baze de date diferite, gestionate de diferite departamente folosind diferite utilitare fr a acorda
atenie interoperabilitii). Abordarea este fcut ntr-un mod holistic, i ncearc s garanteze
folosirea efectiv a cunotinelor disponibile pentru a permite ntreprinderii aflate ntr-un proces
continuu de nvare s propun colaborri, crend ecosisteme i valorificnd cunotinele
externe, resursele i capabilitile astfel nct acestea s devin centre de inovare.
Principalele provocri identificate de comisia european n ceea ce privete ntreprinderea
Digital sunt reprezentate de: (1) provocri politice i din mediul de afaceri; (2) provocri
tehnologice i din mediul de afaceri.
Collective Awareness Platforms (CAPS)
Agenda Digital 2020 ndeamn ctre folosirea CAPS pentru cultivarea inteligenei colective,
promovarea inovaiei i luarea unor decizii orientate ctre sustenabilitate i bazate pe o informare
mai bun.
Contientizarea privete fiinele umane i percepia lor asupra contextului n care opereaz,
incluznd aici motivaia, credinele, dorinele, inteniile att ale unei persoane, ct i a
comunitii/organizaiei din care face parte. Cunoaterea realitii reprezint n acest cadru doar o
dimensiune a contientizrii, deoarece nelegerea unei realiti a mediului de afaceri ncepe de la
o mulime mare de fapte ce vin din diferite surse, incluznd aici chiar i reelele senzoriale.
Procesul de dezvoltare al unei platforme ce permite contientizarea trebuie s ia n calcul i
dimensiunea uman. Oamenii pot fi considerai senzori vii care fac parte din contextul socio-
economic. De asemenea acetia sunt entiti sociale, asociindu-se n reele colaborative sociale ce
permit transferul de cunotine i judecata colectiv.
Exist un numr mare de iniiative care adreseaz problemele societii prin inovare n mediul de
afaceri. Acestea se aliniaz cu CAPS n arii cum ar fi: (1) dezvoltarea unor stiluri de via i
comportamente sustenabile ale populaiei prin contientizarea impactului consumatorilor asupra
resurselor; (2) obinerea de feedback din partea consumatorilor i observarea comportamentului
lor pentru mbuntirea procesului de decizie la diferite nivele ale ntreprinderii i a abordrilor
colaborative cu privire la rezolvarea problemelor i mbuntirea serviciilor publice, a mediului
37
urban, a internetului, etc. ; (3) folosirea contiinei colective pentru a crea noi modele economice,
sociale, democratice.
Este de ateptat ca i CAPS s ofere noi paradigme n ce privete reelele colaborative i
managementul cunotinelor, oferind suport pentru proiectarea i analiza ntreprinderilor.
Printre provocrile identificate de comisia european n ceea ce privete CAPS se numr: (1)
provocrile de ordin politic i business reprezentate de necesitatea regndirii modelului
organizaional n cazul introducerii platformelor CAPS n ntreprinderi, necesitatea reproiectrii
KMS (Knowledge Management System) care au fost concepute pentru o singur ntreprindere, nu
pentru ntreprinderi virtuale i au fost axate doar pe un singur domeniu; (2) provocrile
tehnologice reprezentate de: baze extinse de cunotine pentru reprezentarea domeniului de
afaceri al ntreprinderii, reprezentarea ciclului de via al cunotinelor, reele colaborative
sociale, soluii bazate pe semantic.
1.2.4. Concluzii
n acest paragraf am prezentat universul cunoaterii FInES i cele patru spaii ale sale, precum i
principalele arii de cercetare propuse de comisia european n cadrul direciei de cercetare
Horizon 2020, precum i o sintez a principalelor provocri ce trebuie depite pentru fiecare din
spaiul al cunoaterii sau direcie de cercetare.
1.3. TENDINE DE DEZVOLTARE ALE CERCETRII I INOVRII PENTRU

CATEGORIA DE SISTEME BAZATE PE SERVICII COMPUSE, ORIENTATE SPRE
PROPRIETI DE INTEROPERABILITATE
1.3.1. Specificul sub-sistemelor Service Based Systems

Atunci cnd vorbim despre SBS, trebuie luat n considerare contextul n care sunt executate
serviciile. Informaia contextual afecteaz comportamentul i calitatea serviciilor. Modelarea
contextului este necesar pentru facilitarea descrierii acestuia i trebuie s ia n considerare
aspectul business (prile implicate, reguli), aspectul utilizator (preferinele utilizatorului,
activiti, taskuri) precum i aspectul operaional (protocoale, dispozitive). Modelele contextuale
sunt folosite pentru selectarea i ntreprinderea aciunilor de adaptare. Monitorizarea i adaptarea
SBS ar trebui s se fac pe baza unor mecanisme care s detecteze schimbrile n mediul de
execuie al sistemului. Pentru realizarea acestui lucru este necesar identificarea i codificarea
informaiei contextuale relevante, pentru a fi monitorizat i folosit pentru declanarea adaptrii.
Abordrile existente privind monitorizare i adaptarea n cadrul SBS sunt fragmentate i
adreseaz doar probleme specifice, domenii particulare de aplicaie sau tipuri particulare de
sisteme. n numeroase cazuri, soluiile de monitorizare sunt izolate de nevoile i abordrile
privind adaptarea. Este necesar un cadru holistic de monitorizare i adaptare care s permit
monitorizarea i adaptarea de-a lungul a mai multor niveluri. Integrarea monitorizrii de-a lungul
nivelurilor tehnologice este necesar pentru sistemele SBS ale viitorului, deoarece ofer o
modalitate de localizare eficient, evaluare i corelare a sursei problemei ce duce la o viitoare
adaptare precum i a impactului adaptrii. De asemenea, este necesar o adaptare pro-activ, care
38
n contrast cu adaptarea reactiv care este efectuat dup ce o deviere sau schimbare critic a
avut loc, va preveni situaiile nedorite prin anticiparea deciziilor i a activitilor de adaptare.
Pentru a reduce costurile i pentru a mbunti felul n care sunt fcute schimbrile n sistemele
complexe SBS, sunt necesare tehnologii care s permit adaptarea dinamic i automat a
sistemului prin auto-configurarea modelelor arhitecturale de servicii. n prezent exist o vairetate
de mecanisme de adaptare pentru configuraia iniial a infrastructurii de servicii dar exist
foarte puine soluii pentru adaptarea n momentul execuiei serviciilor prin reconfigurare. La
nivelul infrastructurii de servicii, o provocare semnificativ este de a oferi un comportament
autonom serviciilor, care s le permit s respecte cerinele SLA i s optimizeze folosirea
resurselor. Pentru dezvoltarea unei infrastructuri autonome sunt necesare metode pentru luarea
deciziei, realizarea de adaptri pro-active i reactive; studiul felului n care se poate face
colaborarea cu middlware-ul i sistemul de operare pentru optimizarea alocrii resurselor; noi
tehnici automate de negociere i asigurare a calitii.
Lucrarea de cercetare curent adreseaz necesitatea unui cadru holostic de monitorizare i
adaptare de-a lungul a mai multor niveluri ale SBS.
1.3.2. Clasa sistemelor Collaborative Networked Systems/Organisation

1.3.2.1. Introducere
Prin prisma schimbrii de paradigm propuse de trecerea de la societatea informaional la societatea

bazat pe cunoatere, comportamentul economic al ntreprinderilor i plasarea lor n contextul social
cunoate modificri eseniale, desigur urmrind aceleai scopuri fundamentale ale mediului economic
legate de economia de pia.
Se pot reine dou idei eseniale:
evoluia ntreprinderii ntr-un mediu distribuit, interconectat i
necesitatea acordrii modurilor de lucru al ntreprinderilor ce evolueaz n acest
mediu.
Reelele colaborative (Collaborative Networks - CN) constituie o nou disciplin tiinific
focalizat pe structura, comportarea i dinamica evolutiv a reelelor de entiti autonome care
colaboreaz pentru o mai bun realizare a unor obiective comune sau compatibile, care rspunde
primei idei enunate mai sus.
O definiie complet a reelelor colaborative este enunat de Camarinha-Matos [32] "O reea
colaborativ este autonom, dispersat geografic i eterogen n termenii mediului su de
desfurare, ai culturii, ai capitalului social i al scopurilor. Cu toate acestea, aceste entiti
colaboreaz pentru a atinge scopuri comune sau compatibile, iar interaciunile lor se defaoar
prin intermediul reelei de calculatoare. Spre deosebire de alte reele, n CN colaborarea este o
proprietate intenionat care provine din convingerea mprtit c membrii reelei pot atinge
scopuri care nu ar fi posibile sau ar fi mult mai costisitoare n cazul implementrii individuale."
In cadrul unei reele colaborative se creaz ntreprinderi virtuale (virtual organization - VO), care
nu sunt entiti fizice neaprat omogene din punct de vedere al siturii geografice, ci sunt
coerente i complementare funcional.
39
VO reprezint o mulime de organizaii independente a cror colaborare este facilitat de reele

de calculatoare, i care ofer pentru mediul exterior servicii i funcionaliti ca i cum ar fi o
singur organizaie [32].
Eficacitatea procesului de creare a ntreprinderilor virtuale (VO) este baza apariiei unor VO
dinamice ca rspuns la condiiile de colaborare create, esenial fiind crearea unui mediu de
dezvoltare al organizaiilor virtuale (Virtual Organization Breeding Environment - VBE).
n contextul reelelor colaborative, vor fi prezentate n continuare conceptele de baz propuse de

mediul de dezvoltare al organizaiilor virtuale (VBE) i de organizaiile virtuale (VO).
1.3.2.2. Mediul de dezvoltare al organizaiilor virtuale
Mediul de dezvoltare al organizaiilor virtuale (VBE) reprezint o alian strategic pe termen

lung, grup, asociaie sau grup de organizaii care ofer pre-condiii necesare pentru cooperarea
ntre organizaiile membre i faciliteaz dezvoltarea de organizaii virtuale (VO), ca rspuns la
oportuniti de colaborare n cadrul pieei/societii [32]. Formele incipiente de VBE erau
stabilite n regiuni geografice date, profitnd de cultura comun de afaceri i sentimentul de
apartenen la o comunitate, i erau de obicei axate pe unul sau mai multe sectoare de specialitate
din regiune. n prezent, provocarea este n principal ndreptat spre eliminarea acestor restricii,
precum i gsirea de soluii pentru a extinde i a stimula aceste asociaii. VBE aplic
infrastructuri ICT, instrumente i servicii pentru a oferi mijloace care s faciliteze configurarea i
nfiinarea de VO, pentru a asista VO n procesul de evoluie, pentru introducerea de noi abordri
i mecanisme cu scopul de a construi ncrederea, pentru stabilirea sistemelor de valori comune i
de schimbul de principii n rndul organizaiilor independente. Vom lua n considerare
urmtoarea definiie pentru VBE:
VBE este o asociaie format din organizaii i instituiile de sprijin aferente, care ader la un
acord de cooperare pe termen lung i opteaz pentru adoptarea unor principii de operare i a unor
infrastructuri comune, cu scopul principal de a crete nivelul de competene n vederea unei
colaborri n cadrul unor poteniale organizaii virtuale [33]
Prin observarea empiric a diferitelor studii de caz (de exemplu, Virtuelle Fabrik, Elveia;
IECOS, Mexic; CeBeNetwork, Germania, reeaua Helice, Spania; NetworkA, Finlanda; Torino
wireless, Italia, regiunea Treviso, Italia, etc) [34], pot fi identificate caracteristicile de baz ale
VBE. Pentru modelarea complex a VBE este totui necesar o abordare mai sistematic. Unele
cercetri din ultimii ani s-au concentrat pe definirea de arhitecturi de referin pentru
ntreprinderile virtuale [35] [36], i ntr-o msur mult mai mic, de asemenea, pentru
organizaiile virtuale.
a) Concepte de baz ale VBE
Unele cercetri anterioare au presupus c partenerii pentru un nou VO ar putea fi identificai cu

uurin i selectai din universul larg deschis al ntreprinderilor/organizaiilor disponibile, i
integrai ntr-o reea de colaborare. Aceast abordare trece cu vederea o serie de obstacole
importante n acest proces, printre care pot fi menionate urmtoarele[9]:
Cum pot afla despre existena potenialilor parteneri i cum pot fi tratate sursele
incompatibile de informaii?
40
Cum se pot obine informaii despre profilul de baz al organizaiilor, atunci cnd nu
exist niciun model comun, sau format standard?
Cum se poate stabili rapid o infrastructur de colaborare interoperabil, avnd n vedere

caracterul eterogen al organizaiilor la mai multe nivele, i de diversitatea sistemelor lor
de interaciune?
Cum se poate realiza ncrederea ntre organizaii, care reprezint baza pentru orice
colaborare?
Cum ne putem pune de acord cu privire la principiile comune ale

organizaiilor?
Cum definim rapid rolurile i responsabilitile fiecrui partener, pentru a reflecta

distribuirea sarcinilor, drepturile i rezultatele obinute?
Pentru a sprijini formarea rapid a reelelor colaborative, de exemplu a unui consoriu de afaceri,
o regul de baz este ca potenialii parteneri s fie pregtii s participe la o astfel de colaborare.
Aceast pregtire include o infrastructur interoperabil, norme comune de operare, un acord
comun de cooperare. Orice colaborare necesit, de asemenea, un anumit nivel de ncredere ntre
organizaii.
n general, VBE vizeaz tranziia de la conexiuni punct-la-punct ntre organizaii, la o structur

de reea, pentru a crete ansele de implicare a organizaiilor membre n oportuniti de
colaborare. n mod tradiional, mediile de dezvoltare erau stabilite ntr-o regiune geografic, n
districte industriale, cu avantajul de a avea o cultur de afaceri comun i un sim al comunitii,
precum i concentrndu-se pe un sector de specialitate din regiune. Aceste restricii pot fi
depite astzi de VBE [37]. Scopul principal pentru existena VBE este crearea eficient a VO.
Astfel, motivaia pentru crearea de unui mediu de dezvoltare al organizaiilor virtuale depinde n
primul rnd de identificarea/crearea de oportuniti de colaborare a organizaiilor ntr-un anumit
sector. Sunt dou feluri de posibiliti urmrite de un VBE, i anume cele care pot fi identificate
n pia/societate, i cele care pot fi create de VBE cu scopul de a inova. Principalii actori n
crearea/identificarea oportunitilor sunt fie membrii VBE, broker-ul VO, sau administratorul
VBE care promoveaz iniierea unor VO care par a fi benefice pentru pia/societate. Stabilirea
unui mediu de dezvoltare al organizaiilor virtuale ofer avantajele enumerate i exemplificate
mai jos [33]:
Agilitate n cazul unei oportuniti de creare a VO: flexibilitate pentru re-configurarea

organizaiei virtuale, eficiena costului.
Creterea dimensiunii i a puterii de negociere, ceea ce determin un acces mai bun la

piee/oportuniti i condiii mai bune de cumprare.
Asigurarea unor infrastructuri tehnologice pentru membrii VBE:

bazele comune pentru interoperabilitatea/motenire/colaborare.
Activele VBE, ce ofer membrilor si: informaii generale i cunotine partajate (de
exemplu, definiii standardizate pentru produse i procese), instrumente software,
experien acumulat.
41
Furnizarea de mecanisme, ghiduri i servicii de asisten pentru a motiva i facilita

configurarea i stabilirea de organizaii virtuale: crearea unui sistem de stimulente,
mecanisme pentru a crea o reputaie pozitiv, servicii pentru cutarea de parteneri,
negocierea contractelor, etc.
Gestionare proactiv a competenelor i resurselor disponibile n cadrul VBE asigurnd

necesarul de competene/resurse.
Acordarea de consultan/suport i ntreinere pe via pentru membrii VBE.
Introducerea de abordri/mecanisme pentru a construi ncrederea ntre membrii VBE: prin

nregistrarea istoricului performanei, precum i definirea criteriilor de ncredere.
Furnizarea unor linii directoare generale pentru colaborare: reguli de constituire a

comportamentului, principii de lucru i schimb, sisteme de valori, etici de colaborare,
protecia drepturilor de proprietate intelectual, etc.
Pentru ca VBE s funcioneze corect i sa genereze toate aceste avantaje trebuie ndeplinite un set
de cerine [33]. Printre cerinele principale identificate sunt:
Stabilirea VBE trebuie susinut de un sistem de management al VBE bazat pe o
infrastructur ICT care s ofere un set de instrumente care s suporte att administrarea
VBE precum configuraia i crearea de noi VO.
Implicarea activ a organizaiilor membre VBE, care s furnizeze informaii la zi cu

privire la capabilitile lor, resurse, capaciti i costuri.
Punerea la punct a unui model de afaceri viabil pentru stabilirea mediului de dezvoltare al
organizaiilor virtuale care s acopere problemele de finane VBE i de meninere n pia.
Stabilirea corect a strategiilor de management, regulilor de guvernare i a statutului,

abordnd principiile de lucru i schimb, precum i regulile privind contractarea,
recompensarea si sancionarea.
b) Membrii VBE
Structural, un mediu de dezvoltare al organizaiilor virtuale este o asociere deschis dar
reglementat de membri. Acesta are ca scop mbuntirea nivelului de pregtire a organizaiilor
membre pentru aderarea la poteniale viitoare organizaii virtuale, oferind astfel suport pentru
crearea de reele colaborative, n funcie de oportunitile viitoare.
Deoarece o parte din sarcinile necesare sunt deja realizate n cadrul VBE pentru toi membrii
acesteia nainte de stabilirea oricrei organizaii virtuale, crearea unei noi organizaii virtuale n
contextul unui VBE este mai puin costisitoare i mai eficient dect n cazul cutrii generalizate
de parteneri. Cu alte cuvinte, VBE contribuie substanial la creterea nivelului de pregtire al
membrilor acestuia pentru participarea la poteniale procese colaborative.
Un VBE nu trebuie s fie o organizaie nchis, noii membri se pot altura i adera la
asociaie, dar acetia trebuie s respecte principiile generale de funcionare ale asociaiei. De
exemplu, un membru asociat VBE ar putea s adere la un nivel minim de organizare pentru
42
implicarea ntr-o organizaie virtual, oferind un nivel minim de informaii administraiei VBE.
Un membru pe deplin activ al VBE contribuie la promovarea sa, creterea, i mbogirea
activelor VBE, i poate prelua un rol de broker al unei organizaii virtuale ntr-o ni de pia i
poate fi implicat n extinderea VBE n noi sectoare.
Prin urmare, pot exista diferite niveluri de apartenen la un VBE, fiecare n conformitate cu
un set diferit de drepturi i responsabiliti. n principiu, aceste niveluri se pot constitui ntr-un
interval, cu un grad sczut de apartenen la un capt al intervalului i un grad ridicat de
apartenen la cellalt capt. n cadrul structurii VBE, pentru formarea unei organizaii virtuale,
prioritate li se va da membrilor VBE n funcie de gradul de apartenen, dar n unele cazuri, n
funcie de lipsa sau insuficiena abilitilor si capacitilor necesare n cadrul VBE, ar putea
deveni necesar gsirea unui partener extern. Partenerul extern identificat va trebui apoi
s adere cel puin la nivelul cu cel mai mic grad de apartenen la VBE, de exemplu,
infrastructura comun i principiile de cooperare VBE . Pentru aceast ntreprindere, se va face
un training de ctre administratorul VBE sau de cei ce planific noi organizaii virtuale.
Un mediu de dezvoltare al organizaiilor virtuale ar putea include i alte tipuri de organizaii
(cum ar fi institutele de cercetare, organizaii guvernamentale, etc.) persoane care lucreaz pe
cont propriu(free-lancers). Scopul principal al includerii acestor tipuri de organizaii n cadrul
VBE este acela de a furniza diferite servicii suport membrilor VBE. Aceste instituii sunt referite
ca instituii suport. Serviciile tipice sau expertiza necesar n VBE pot include servicii juridice,
expertiza de marketing, de asigurare, de formare, etc. Pot fi identificate trei tipuri de organizaii
ce pot fi nregistrate n cadrul VBE:
Agenii economici ce furnizeaz produse i servicii n pia i care se implic n

organizaii virtuale pentru a obine un profit cantitativ, cum ar fi de exemplu
ntreprinderile.
Instituii non-profit care se implic n organizaii virtuale pentru a obine profit calitativ,
de exemplu, instituii academice i de cercetare.
Instituiile suport VO, cum ar fi de exemplu: furnizorii de servicii legale i contractuale,

ministere, asociaii sectoriale, Camera de Comer, organizaiile de mediu, etc.
n cadrul VBE organizaiile stabilesc legturi. Membrii VBE ar trebui s se supun regulilor
i politicilor VBE, cum ar fi adaptarea la structura comun ICT. Odat ce fac parte din VBE,
organizaiile membre pot beneficia de urmtoarele elemente: instrumente i tehnologii, canale de
distribuie comune, resurse comune, faciliti pentru a disemina leciile nvate, faciliti pentru a
mpri costurile implicate de dezvoltarea/utilizarea unor noi tehnologii.
Membrii VBE pot beneficia de o gam larg de posibiliti. De exemplu, organizaiile
membre ntr-un VBE pot juca rolul de broker, pentru a stabili o nou organizaie virtual, la
ivirea unei oportuniti de pia , organizaiile membre pot fi invitate s adere la noua VO,
datorit competenelor lor i/sau performanele anterior nregistrate. Fiecare membru poate avea
acces la o varietate de informaii generale i cunotinele necesare disponibile prin intermediul
VBE, i poate mpri costurile pentru cercetare de pia, publicitate, etc. Prin intermediul VBE,
membrii si pot avea acces i beneficia de suportul necesar(juridic, asigurri, instruire, etc.), prin
intermediul unor servicii furnizate de instituiile suport. Membrii pot accesa resursele partajate ce
fac parte din activele VBE, care sunt fie furnizate de ctre administraia VBE sau constituie
contribuii ale altor membri ai VBE. Membrii VBE pot beneficia, de asemenea, de experienele i
43
leciile nvate care sunt mprtite de ali membri n spaiul on-line comun prevzut n cadrul
VBE.
O varietate de roluri pot fi asumate de ctre un numr mare de actori n VBE [38] [39] unde un
actor VBE reprezint fie o organizaie membr VBE, fie individ care reprezint o organizaie
membr VBE.
Urmtoarele roluri principale sunt luate n considerare pentru VBE:

membru VBE: acesta este rolul fundamental jucat de acele organizaii care sunt
nregistrate n VBE i sunt gata s participe la activitile mediului de dezvoltare al
organizaiilor virtuale.
partener n cadrul unei organizaii virtuale: acesta este un rol fundamental jucat de un
membru VBE ntr-un VO.
administrator VBE: rolul jucat de organizaia responsabil de funcionarea i evoluia VBE,

promovarea cooperrii ntre membrii VBE, surmontarea deficitului de calificri/competene
n cadrul VBE prin cutarea i recrutarea/invitarea de noi organizaii, gestionarea zilnic al
proceselor generale VBE ( de exemplu, desemnarea de drepturi diferiilor actori), soluionarea
conflictelor, gestionarea activelor VBE.
broker: un rol efectuat de ctre un actor VBE care identific noi oportuniti de colaborare
(oportuniti de afaceri), promoveaz competenele i activele VBE i negociaz cu poteniali
clieni. Acest rol poate fi jucat i de o entitate din afara VBE.
planificator VO sau integrator de afaceri: un rol efectuat de ctre un actor VBE care
aflat n faa unei noi oportuniti de colaborare (identificat de un broker), identific
competenele i capacitile necesare, selecteaz partenerii (membri VBE i/sau parteneri din
afar, n cazul n care nu sunt suficiente competene i/sau capaciti din interiorul VBE), i
structureaz noile organizaii virtuale. n multe cazuri rolurile de broker i planificator VO
sunt asumate de acelai actor.
Coordonator VO: un rol efectuat de ctre un actor VBE, care va coordona o organizaie
virtual pe parcursul ciclului su de via, cu scopul de a ndeplini obiectivele stabilite pentru
oportunitatea de colaborare care a dus la formarea organizaiei virtuale.
c) Ciclul de via al VBE
Ciclul de via al mediului pentru dezvoltarea organizaiilor virtuale este reprezentat de totalitatea
etapelor prin care poate trece un VBE pe parcursul vieii sale, de la creare, operare i posibil
dizolvare(figura 1.7).
44
Fig. 1.7. Etapele ciclului de via VBE (adaptat dup [34])
Fiind o alian pe termen lung i jucnd un rol n pia/societate, dizolvarea unui VBE este o
situaie neobinuit. n schimb, este mult mai probabil ca VBE s treac printr-o alt etap, aa
numita etap de metamorfoz, n care poate s evolueze i s i schimbe forma i scopul. O
organizaie virtual poate fi creat doar n etapa operaional a VBE. Managementul VBE pe
parcursul tuturor etapelor ciclului de via se afl n centrul zonei de cercetare i dezvoltare
pentru VBE de generaia a doua. Iniiative n cercetare privind mediul de dezvoltare al
organizaiilor virtuale ce pot fi menionate sunt: THINK creative i VOmap ( [40], VOSTER
([41]), i PRODNET ([42]).
Funcionalitile de baz necesare pentru un VBE pot fi mprite n trei grupuri corespunztoare
cu fazele ciclului de via [34]:
Funcionalitatea de baz ce sprijin crearea VBE - Aceast etap cuprinde: (1) iniierea
/recrutarea, care necesit stabilirea i configurarea unei infrastructuri comune, recrutarea
potenialelor organizaii ce se pot altura VBE, i stabilirea unor ontologii de baz pentru
definirea viziunii i obiectivelor strategice ale VBE; (2) Fundamentarea VBE care presupune
parametrizarea sistemelor utilizate, stabilirea legturilor necesare, crearea bazelor de date
necesare (cu meta-date iniiale/ ontologii), i popularea acestor structuri informatice.
Funcionalitatea de baz ce sprijin funcionarea i evoluia VBE - Aceasta faz necesit

suport pentru: (1) managementul competenelor i activelor, (2) nregistrarea de noi membri ,
(3) asistarea crerii VO, (4) dezvoltarea incremental de meta-date/ontologii pentru
domeniu/sector, (5) inerea unei evidene privind performana i procesele colaborative, (6)
evaluarea i instrumentele de asisten, (7) suport pentru colaborare (de exemplu, forumuri de
discuii, arhive comune de informaii, etc.), (8) managementul i evoluia principiilor i
regulilor de lucru, (9) managementul cunotinelor comune i active.
Funcionalitatea de baz ce sprijin metamorfoza VBE i dizolvarea Aceast faz va

necesita asisten pentru proiectarea noii structuri organizatorice, selectarea i reorganizarea
informaiilor i cunotinelor colectate n timpul funcionrii VBE i care ar putea fi
transferate la noua organizaie, analiza si adaptarea la noul context, etc. n cazul dizolvrii
45
VBE este nevoie de o planificare pentru transferul cunotinelor colectate, informaii, active
ctre membrii si sau o alt organizaie pe baza unor acorduri definite.
d) ncrederea inter-organizaional n cadrul VBE
Stabilirea unor relaii de ncredere ntre organizaiile n VBE este o pre-condiie pentru
cooperarea lor armonioas. Avnd n vedere c crearea efectiv de organizaii virtuale este scopul
principal al mediilor de dezvoltare a organizaiilor virtuale, msurarea nivelului de ncredere
ofer informaii fundamentale pentru stabilirea relaiilor de ncredere ntre organizaii. n timp ce
n cadrul unui VBE de mici dimensiuni cu douzeci pn la patruzeci de membri, organizaiile
pot avea o bun ans de a ajunge s se cunoasc reciproc, avnd o judecat subiectiv a
moralitii altora, ntr-un VBE mediu sau mare, analiza ncrederii pe care o ofer alte organizaii
este un obstacol pentru crearea organizaiilor virtuale i o mare provocare. Proiectarea si
dezvoltarea unei abordri bazat pe fapte pentru evaluarea nivelului de ncredere al organizaiilor
este de o importan deosebit pentru VBE de mari dimensiuni, n cazul n care, de obicei,
organizaiile membre ale acestora nu se cunosc reciproc.
Nu s-a ajuns nc la un consens n literatura de specialitate cu privire la definiia ncrederii i ce
constituie managementul ncrederii ntre entiti diferite. Cercettorii au recunoscut importana sa
n facilitarea interaciunilor i conlucrarea ntre persoane fizice, precum i organizaii [34].
Aa cum este folosit zilnic de ctre persoane, termenul de ncredere se refer la opinia cuiva
despre o alt persoan. Good [43] a oferit o definiie a ncrederii, care a fost utilizat pe scar
larg, ca probabilitatea subiectiv prin care un individ A se ateapt ca un alt individ B s
efectueze o anumit aciune de care depinde bunstarea lui A. n [44] ncrederea este definit ca
dorina unui pri de a fi vulnerabila la aciunile unei alte pri bazat pe ateptrile ca partea
creia i se acord ncrederea va efectua o aciune fr a fi monitorizat sau controlat. O alt
definiie propus de Grandison este: ncrederea este credina n competena unei entiti de a
aciona ntr-un mod sigur, de ndejde, ntr-un anumit context[45]. Rousseau[46] definete
ncrederea ca o condiie psihologic ce cuprinde intenia celui care acord ncrederea de a
accepta o vulnerabilitate bazat pe ateptrile pozitive privind inteniile i comportamentului
celui ce i se acord ncrederea. Msanjila i Afsarmanesh [47] definesc ncrederea ntre
organizaii, aa cum este ea aplicat n cadrul VBE ca ncrederea unei organizaii ntr-o alt
organizaie bazat pe rezultatele obinute prin evaluarea nivelului de ncredere al unei organizaii
bazat pe fapte.
Diversitatea dintre aceste definiii (i altele) i diferena ntre elemente identificate de ele face
dificil caracterizarea ntr-un mod corespunztor a ncrederii. n ciuda dificultilor ntmpinate
n consolidarea unei definiii a ncrederii, n practic se aplic zilnic conceptul de ncredere ca o
baz pentru cooperarea i colaborarea ntre persoane fizice, precum i n rndul organizaiilor.
Cercetarea asupra RCO a artat c eficiena unitilor VBE precum i crearea de VO depinde de
nivelul de ncredere oferit de organizaii. ncredere ntre organizaii n cadrul VBE este un subiect
complex, care trebuie s fie abordat considernd interdisciplinaritatea dintre domenii,
eterogenitatea i contradicia ntre interesele i obiectivele organizaiilor implicate [48].
Msanjila i Afsarmanesh [48] au identificat i definit conceptele de baz ce implic ncrederea

ntre organizaii.
46
Actorii reprezint dou organizaii implicate ntr-o relaie de ncredere. Prima parte este
organizaia care evalueaz gradul de ncredere al celei de a doua pri. Cea de a doua
parte este organizaia care are nevoie de ncredere, nivel de ncredere al acesteia fiind
evaluat de prima parte.
Obiectivul se refer la scopul pentru care sunt stabilite relaiile de ncredere ntre
organizaiile implicate. Exemple de obiective sunt: invitarea unei organizaii s se alture
unui VO, selectarea unei organizaii ca i coordonator al VO, decizia unei organizaii de a
adera la un VBE, etc..
Perspectiva din care este privit ncrederea reprezint punctul de vedere specific al
unei organizaii privind principalele aspecte ce trebuie s fie luate n considerare pentru
evaluarea nivelului de ncredere al unei alte organizaii. n funcie de perspectiva din care
este privit ncrederea, organizaiile iau decizii n legtur cu informaiile necesare pentru
evaluarea nivelului de ncredere al unei organizaii.
Criterii de ncredere reprezint elementele de ncredere msurabile ce caracterizeaz

cerinele privind ncrederea ntr-o organizaie. Prin urmare, pentru fiecare organizaie,
valorile criteriilor de ncredere (legate de o cerin) pot fi folosite pentru a deduce ntr-un
mod raional (bazat pe fapte) dac cerina respectiv este ndeplinit.
e) Sisteme de management VBE
Gestionarea eficient a unui VBE este strns legat de pregtirea membrilor VBE pentru
colaborarea n cadrul VO. Pregtirea organizaiilor joac un rol strategic, necesitnd timp i efort
pentru a fi stabilit i meninut de-a lungul ntregului ciclu de via al VBE [49]. Un
management eficient al unui VBE ajut la reducerea timpului de creare a VO. Organizaiile care
pot fi aduse mpreun de ctre un broker nu au nici o familiaritate una cu cealalt deoarece
acestea nu au colaborat ntre ele nainte. Prin intermediul VBE i al sistemului de management al
acestuia oportunitile de colaborare pot fi detectate mult mai eficient n termeni de timp i efort
iar selecia organizaiilor celor mai potrivite poate fi mult mai eficient.
Pentru ca organizaiile s fie pregtite n orice moment pentru colaborare este necesar gestiunea
diferitelor tipuri de informaii n cadrul VBE. Este necesar un set de funcionaliti de baz
pentru a sprijini administrarea membrilor VBE, incluznd nregistrarea lor, rolurile i drepturile.
Afsarmanesh i Camarinha [49] au identificat un numr de funcionaliti avansate ce adaug
valoare unui VBE: managementul competenelor n cadrul VBE, managementul apartenenei la
un VBE, managementul ncrederii inter-organizaionale n cadrul VBE, managementul activelor
VBE.
Reelele colaborative au fost stabilite ca o nou disciplin tiinific n curs de dezvoltare

[49].O serie de reele VBE (sau cel puin cu unele caracteristici comune VBE) exist acum n
ntreaga lume, cum ar fi Swiss MicroTech (Elveia), Helice (Spania), CeBeNetwork (Germania)
47
IECOS (Mexic). Gestionarea acestor reele de VBE poate fi facilitat de o serie de instrumente
semi-automate i servicii. Serviciile au ca scop sporirea eficienei efecturii activitilor n cadrul
VBE (reducerea resurselor necesare, de timp i costurile). Un numr de sub-sisteme sunt
dezvoltate n Sistemul de Management al Mediului de Dezvoltare al Organizaiilor Virtuale
(SMMDOV). Pe scurt, SMMDOV este dezvoltat pentru a sprijini administraia VBE n
urmtoarele activiti: Colectarea / managementul informaiilor privind performana
organizaiilor din VBE; Management profilelor i competenelor organizaiilor membre ale VBE,
VO, i chiar al mediului de dezvoltare al organizaiilor virtuale; Evaluarea, i gestionarea
ncrederii membrilor organizaiilor din VBE; Suport pentru cooptarea de noi membri i
gestionarea structurii VBE; Gestionarea activelor i managementul informaiilor VO n cadrul
VBE; Suport pentru procesele legate de luarea deciziilor n VBE.
Eficiena procesului de creare al organizaiilor virtuale este elementul critic n reelele

colaborative. Cercetrile timpurii privind crearea de VO presupuneau c partenerii pot fi
identificai i selectai din universul deschis al ntreprinderilor/organizaiilor existente, i inclui
ntr-o reea colaborativ. Aceast abordare omite o serie de obstacole importante n acest proces
printre care pot fi menionate urmtoarele [50], [51]: (1) Cum s tiu despre simpla existen a
potenialilor parteneri n universul deschis al organizaiilor n condiiile unor surse incompatibile
i limitate de informaii? (2) Cum s obinem informaii de baz cu privire la profilul
organizaiilor, atunci cnd nu exist nici un model comun, sau format standard? (3) Cum stabilim
rapid i fiabil o infrastructur interoperabil pentru colaborare, avnd n vedere caracterul
eterogen al organizaiilor la mai multe nivele, i diversitatea sistemelor de interaciune? (4) Cum
s construim ncrederea ntre organizaii? (5) Cum s dezvoltam rapid acorduri cu privire la
principiile comune de partajare i lucru mpreun? (6) Cum s definim rapid acordurile cu privire
la rolurile i responsabilitile fiecrui partener, pentru a reflecta distribuirea sarcinilor, drepturile
privind rezultatele obinute?
n cazul proceselor de colaborare pe termen lung care nu sunt limitate la o singur oportunitate de
afaceri, cum ar fi n cazul lanurilor de aprovizionare, costurile i timpul de pregtire pentru
colaborare sunt accesibile innd cont de perspectivele pe termen lung. Pe de alt parte, pentru
anumite sectoare specifice de ni, n care toi actorii mprtesc aceleai instrumente sau
instrumente compatibile, cultur de afaceri i practici, este posibil formarea rapid a unui
consoriu chiar i pentru o oportunitate de afaceri pe termen scurt. Pentru celelalte cazuri, situaia
este mult mai critic. n special atunci cnd fereastra de oportunitate este scurt, pentru a facilita
formarea rapid a reelelor de colaborare este necesar ca potenialii parteneri sa fie pregtii i
gata s participe ntr-o astfel de colaborare. Pregtirea include o infrastructur interoperabil
comun, norme comune de exploatare i de cooperare. Orice colaborare necesit, de asemenea,
un nivel de baz de ncredere n rndul organizaiilor. n acest caz o soluie este crearea unei
asociaii pe termen lung format din entitile care se pregtesc s coopereze ori de cte ori apare
o oportunitate. Aceast asociere este un mediu de dezvoltare al organizaiilor virtuale [50] [51].
Un numr mare de proiecte de cercetare i dezvoltare au abordat aspecte specifice procesului de
creare de VO, aa cu se poate vedea n studiu VOSTER [41]. Dintr-un punct de vedere
metodologic pot fi considerate dou situaii n procesul de creare al VO:
Proiectarea VO - o dat ce o oportunitate de colaborare a fost detectat de ctre un

membru VBE ce joac rolul de broker, un proces de tipul top-down este demarat
pentru proiectarea i crearea de VO. Procesul este coordonat de planificatorul organizaiei
virtuale (ce poate fi n acelai timp i broker).
48
Emergena VO - n acest caz, brokerul va anuna membrii VBE privind oportunitatea de

colaborare i apoi va atepta emergena unor poteniali candidai la formarea consoriului.
n cele din urm, brokerul i/sau planificatorul VO, sau clientul, vor alege organizaiile
cele mai potrivite pentru a forma consoriul.
n ambele cazuri, trei abordri sunt adresate pn n prezent n cercetare i dezvoltare ca
alternative pentru crearea VO [9]:
1. Abordri manuale sau asistate de calculator
2. Abordrii multi-agent
3. Abordri bazate pe servicii.
1. Abordri manuale i asistate de calculator
De-a lungul anilor au fost dezvoltate mai multe abordri pentru planificarea i crearea VO.
Abordarea manual a fost folosit cu preponderen la nceput, n momentul introducerii
paradigmei VO. Progresiv, instrumentele ICT au fost dezvoltate pentru a asista planificatorul VO.
Dei abordarea asistat de calculator predomin n VO de astzi, exist nc abordri manuale
pentru crearea VO. Un exemplu de ncercare de trecere de la o abordare manual la cea asistat
de computer poate fi gsit n cadrul proiectului PRODNET [52]. Acest proiect a ncercat s
foloseasc liste interne de furnizori i directoare publice de ntreprinderi accesibile publicului. A
fost elaborat o metodologie ce implica o filtrare preliminar bazat pe profiluri i caracteristicile
cerute, urmate de o cerere de ofert, oferte management, precum i instrumente de asistare a
deciziei umane. n ultima decad un efort considerabil a fost pus n achiziiile publice.
Obiectivele principale n acest domeniu includ definiia unor proceduri normalizate de anun
public al ofertelor de afaceri, recepie, i de gestionare de oferte.
2. Abordrile multi-agent
Agenii sunt entiti software autonome concepute pentru a funciona i interaciona n

medii distribuite. Ei pot suporta interaciuni sofisticate datorit abilitilor sociale i, de
asemenea, pot rspunde n timp util schimbrilor din mediul lor [53]. Deoarece un sistem multi-
agent (SMA) prezint, la un nivel abstract, multe asemnri cu o reea colaborativ este natural
utilizarea SMA ca suport pentru modelare implementarea procesului de creare a VO [54].
Un numr tot mai mare de prototipuri ce aplic sistemele multi-agent i mecanismele de
negociere pentru formarea VO au fost dezvoltate. Un exemplu timpuriu este reprezentat de
Rocha i Oliviera n 1999 [55], care au introdus o pia virtual n care ntreprinderile distribuite
geografic i autonome sunt reprezentate de ctre ageni. Ideile propuse de Li urmeaz o abordare
similar [56]. Rabelo [57] a dezvoltat o arhitectur multi-agent pentru a sprijini selectarea
partenerilor n cadrul unui grup de dousprezece ntreprinderi . Diverse protocoale de negociere
au fost elaborate pentru selectarea partenerilor i formarea de coaliii. Mecanismele de licitaie au
devenit populare n formarea consoriilor bazat pe ageni datorit simplitii i regulilor bine
definite [58].
49
3. Abordri bazate pe servicii comerciale
n cadrul acestei abordri, companiile (poteniali membri ai organizaiei virtuale) sunt considerate
ca furnizori de servicii, adic potenialul comportamentul colaborativ al fiecrei companii este
materializat printr-un set de servicii [50]. Aceast abordare presupune existena unei entiti care
menine un catalog de servicii n cazul n care companiile care furnizeaz servicii i public
oferta de servicii. Indiferent de implementare, sunt de obicei luate n considerare trei funcii
principale ale arhitecturilor orientate ctre servicii: public, descoper, invoc. n acest caz,
tehnologiile standard ar trebui s fie utilizate pentru descrierea serviciului, comunicaie i
formatul datelor. n cazul serviciilor web astfel de standarde includ: WSDL, UDDI, SOAP.
Aceast abordare reflect o selecie indirect a partenerilor. Ceea ce este selectat este serviciul
(nu furnizorul), aciunea imediat fiind compunerea serviciilor (sau orchestraia) complexe bazate
pe cele simple. Partenerii sunt implicit selectai prin intermediul serviciilor specifice care sunt
alese. Este totui posibil s se includ caracteristicile partenerilor n interogarea folosit pentru
cutarea de servicii. Procesele de publicare a serviciilor, descoperire, selectare, invocare i legare
(binding) ofer o alternativ pentru gestionarea competenelor organizaiei, selectarea
partenerilor i negocierea pentru configurarea VO n cadrul unui VBE.
Un exemplu timpuriu de abordare bazat pe servicii aplicat pentru sectorul turismului poate fi
gsit n [59]. n aceast lucrare au fost introduse abordri orientate spre servicii n cadrul VO
pentru sectorul turistic (proiectul WTIS). Un alt exemplu este dat de proiectul Osmos [60], care
s-a concentrat pe industria de construcii i a urmat o abordare bazat pe servicii pentru
proiectarea i dezvoltarea infrastructurii ICT.
Dei serviciile web sunt foarte populare, exist nc o serie de limitri n ceea ce le privete.
Cteva ntrebri necesare sunt: Sunt serviciile web ntotdeauna disponibile? Ct de dedicat este
furnizorul? Care este modelul de afaceri de baz i cum este echilibrat volumul de munc? Exist
dependene ntre servicii? Pot fi toate abilitile reprezentate ca servicii?
1.3.2.3. Managementul organizaiilor virtuale
a) Concepte
GUVERNAREA
Conform Plumtre, fondatorul Institutului de Guvernan [61] cuvntul guvernan (governance)

era un termen aproape necunoscut n limba englez pn spre sfritul secolului 20. nc mai sunt
dezbateri asupra definiiei corecte pentru acest concept. Plumptre propune urmtoarea definiie:
"Guvernarea este procesul prin care societile i organizaiile iau decizii importante, determin
care sunt prile implicate i care este impactul asupra acestor pri." Aceast definiie
evideniaz ideea c guvernarea este diferit de management, deoarece const n procesul de
luare al unor decizii strategice i eseniale pentru ndeplinirea unor obiective importante. Este un
set de idei i abordri cu privire la conducerea activitilor umane n orice form de aciuni
colective, fr a implica proceduri formale de management. De asemenea, Dicionarul
Oxford[62] leag termenul de guvernare de un set de standarde i principii de control.
n contextul VO, termenul guvernare denot principiile de baz i conceptele necesare ce susin
ndeplinirea obiectivelor organizaiei virtuale. Prin guvernare se neleg principiile, structura,
50
procesele i relaiile dintre ele ce sprijin ndeplinirea eficient a obiectivelor VO. Guvernarea
unei VO este strns legat de conceptul de guvernarea proiectului [63]. Se poate considera c
guvernarea proiectului:
subliniaz relaiile dintre toate grupurile interne i externe implicate n cadrul proiectului
descrie ntr-un mod adecvat fluxul de date referitor proiectului prilor implicate
asigur revizuirea ntr-un mod adecvat a tuturor problemelor ntlnite n cadrul fiecrui
proiect
se asigur c aprobrile necesare i direcia proiectului sunt obinute/stabilite la fiecare

etap a proiectului
ODonovan [64] definete guvernarea corporativ ca un sistem intern cuprinznd politici,
procese i oameni care deservete nevoile prilor implicate, prin direcionarea i controlul
activitilor manageriale cu o bun nelegere a afacerii, obiectivitate, integritate.
Principiile de guvernare ale VO sunt n primul rnd stabilite n baza VBE. Organizaia virtual
este prin definiie temporar, aa c principiile de guvernare de baz au fost deja stabilite n VBE.
Participarea ntr-un VBE este determinat de obiective pe termen lung, prin aderarea la un VBE
o organizaie adernd la anumite reguli i principii, unul dintre acestea fiind conceptul de
ncredere[33].
Datorit duratei limitate a unei organizaii virtuale, managerul VO trebuie s adopte anumite
principii de guvernare. Principiile variaz n funcie de caracteristicile VO i de stilul personal al
managerului. Cteva stiluri de management ce pot fi identificate sunt: ncurajator, bazat pe auto-
organizare, dominat de timp sau management multi-organizaional [65]. Pentru a putea aciona,
managerul VO are nevoie de un anumit nivel de putere i autoritate. Deciziile manageriale pot fi
aplicate, dac managerul are un nivel de putere corespunztor. De aceea, trebuie luate n
considerare diferitele niveluri de putere asociate rolurilor manageriale. Distribuirea puterii poate
avea diferite motive, cum ar fi: mediul de afaceri, situaia economic, relaia cu clienii, asumarea
riscurilor, etc., aceasta trebuind a fi luat n considerare n selectarea abordrii de guvernare [66].
MANAGEMENTUL ORGANIZAIILOR VIRTUALE
n acest context, termenul de management poate fi legat de coordonarea operativ a activitilor

comune. Managementul se bazeaz pe abordarea de guvernare i pe regulile stabilite pentru o
organizaie virtual specific. O definiie timpurie a termenului de management a fost dat de
Mary Parker Follet la nceputul secolului XX: arta de a face lucruri prin intermediul oamenilor
[67]. Managementul poate consta n mai multe dimensiuni, cum ar fi: dimensiunea uman,
dimensiunea financiar, dimensiunea tehnologic, resurse, etc.
Faptul c o organizaie virtual const n entiti independente care colaboreaz pentru
ndeplinirea unor obiective, implic faptul c guvernarea i managementul activitilor sunt
devotate colaborrii, i nu proceselor interne n cadrul entitilor. Astfel, managementul VO este
considerat ca managementul proceselor business peste i de-a lungul membrilor VO. Acesta nu
acoper managementul membrilor constitutivi. ntr-un studiu anterior [68] nu a putut fi
identificat o form general pentru organizaiile virtuale, i nici nu a putut fi dezvoltat folosind
metodologiile, scenariile i cazurile analizate. VO au fost structurate n categorii,topologii i
factori de contingen [69].
51
n acest context, managementul VO poate fi definit ca organizarea, alocarea i coordonarea

resurselor i a activitilor lor precum i a dependenelor lor interorganizaionale pentru a atinge
obiectivele VO n timpul, resursele financiare i nivelul de calitate alocate [70].
Managementul VO poate fi vzut ca i controlul ciclului de via al organizaiei virtuale,

interacionnd cu procesele operaionale sau care ofer servicii clienilor. n principal conceptele
sunt bazate pe corelarea unor procese suplimentare cu metode i instrumente intra-oranizaionale
disponibile. Deoarece VO este format din organizaii independente, conducerea VO are
posibiliti limitate de a interveni n procesele interne ale partenerilor. Conducerea VO trebuie s
se bazeze doar pe valorile disponibile la nivelul interfeelor pentru organizaiile partenere. O
colaborare eficient n sensul descris nseamn c rezistenele interne la colaborare trebuie s fie
reduse la minimum. Multe dintre acestea sunt legate de mediu, n special mediul de dezvoltare, n
care VO sunt create i funcioneaz. Astfel de tipuri de rezisten sunt: ncrederea i regulile
pentru schimbul de informaie, poziiile concurente sau calitatea contractelor ce trebuie tratate n
mod corespunztor.
Comportament
dorit, ateptat
Msurtori, Decizii privind

Comparaii
Colecii de informaii aciunile
Procesele operaionale ale Organizaiei Virtuale
Fig. 1.8. Managementul VO vzut ca o bucl de control [9]
Natura temporar a VO implic faptul c durata de via a organizaiei virtuale corespunde cu

durata de timp necesar livrrii unui produs sau serviciu pentru care organizaia a fost creat.
Astfel, toate procedurile folosite pentru crearea VO vor deservi doar acestui caz specific. O
creare i un start eficient al VO nu permite aciuni de implementare complicate. O abordare
modularizat parametrizabil, unde aciuni predefinite pot fi configurate pentru o Organizaie
Virtual specific, poate reduce timpul de configurare i crete eficiena operaiilor VO [71].
n figura 1.8. este prezentat managementului unei VO ca o bucl de control. Pentru
managementul organizaiei sunt necesare date i informaii despre starea operaiilor VO.
Aciunile sunt bazate pe comparaia dintre comportamentul obinut sau estimat i
comportamentul dorit. Aciunile ar trebui s fie pro-active pentru a evita deviaiile emergente de
52
la rezultatele ateptate. ntr-un mediu dinamic, aceast abordare necesit dezvoltarea unei
abordri n timp real de management al VO.
Pentru a gestiona eficient organizaiile virtuale, este necesar un domeniu de aplicare larg, care se
regsete de asemenea n definiia managementului VO. Principalele provocri in managementul
VO vin din caracterul temporar al acesteia i din distribuirea operaiunilor ctre mai multe
organizaii. VO are ca scop rspunsul rapid la schimbrile survenite n mediul su, astfel nct
este necesar un management dinamic, care poate s includ restructurarea abordrii manageriale
sau chiar a configuraiei VO. Pentru a identifica n timp real aciunile ce trebuie ntreprinse, un
sistem eficient de msurare a performanei ar trebui implementat, pentru a oferi indicatori de
ncredere n timp real asupra performanei organizaiei [72].
Organizaia virtual este creat pentru a ndeplini un anumit task. Rezultatele organizaiei virtuale
sunt reprezentate de ndeplinirea taskului (fr a depi restriciile de cost, timp i calitate). Un
management eficient al VO implic un control al eficienei acesteia. Eficiena VO poate fi
mprit n trei categorii diferite, care pot fi interdependente:
1. Eficiena n ndeplinirea task-urilor, ndeplinind condiiile de timp, cost, calitate
2. Eficiena VO i a colaborrii
3. Eficiena abordrii i metodelor manageriale
Majoritatea aciunilor managementului sunt devotate ndeplinirii eficiente a taskurilor. Aciunile

de meninere i cretere a eficienei taskurilor sunt devotate coordonrii activitilor ntre
parteneri , lund n considerare provocrile ce provin din caracteristicile VO.
Eficiena organizaiilor virtuale depinde n mare msur de performana partenerilor i
colaborarea dintre acetia. Aceast performan poate depinde i de configuraia organizaiilor.
b) Disoluia i motenirea VO
Aa cum a fost descris anterior, VO este o organizaie temporar cu urmtoarele faze ale ciclului
de via: crearea, operarea i evoluia, disoluia. Este creat pentru un anumit task, de cele mai
multe ori pentru a crea valoare pentru un client, iar dup ducerea la bun sfrit a taskului, este
dizolvat. Durata unei astfel de organizaii se poate ntinde de la cteva zile (taskuri foarte scurte)
la civa ani. n faza dizolvrii, nu este cunoscut dac un task asemntor va mai fi efectuat.
Produsul oferit clientului i participanii n noul VO nu sunt neaprat aceiai. Astfel, disoluia
sfrete colaborarea concret.
Proiectele se aseamn din punct de vedere conceptual cu organizaiile virtuale. PMBOK [73]
definete proiectele ca eforturi temporare ntreprinse pentru a crea un produs sau serviciu unic.
Proiectele mprtesc aceleai caracteristici, limitri temporare i n ceea ce privesc resursele.
De fapt, multe proiecte sunt efectuate ca VO, chiar dac definiia proiectului nu presupune
participarea diferitelor organizaii. Proiectele ntmpin, de asemenea, problema discontinuitii,
i a transferului cunotinelor de la un proiect la un altul viitor. n PMBOK, faza de nchidere de
proiect (corespunztoare disoluiei VO) este descris foarte pe scurt. Motenirea este definit ca
fiind leciile nvate, dar nu exist o definiie clar a modului n care se face acest lucru.
53
Schindler i Eppler [74] vd nvarea din experienele proiectului prin intermediul a dou
metode: metode pe baz de proces i metode bazate pe documentare. n cadrul proiectelor
inginereti, aceste abordri se bazeaz pe date, informaii i cunoatere [75].
Astfel, n timp ce au creat valoare pentru clieni, partenerii VO i-au mbogit cunotinele, au
ctigat experien i consolidat reciproc relaiile. Experiena ctigat poate fi folosit pentru a
mbunti nivelul de pregtire din mediul de dezvoltare al organizaiilor virtuale. Dup
ndeplinirea taskului i dup ce organizaia virtual a fost dizolvat, nivelul de cunotine
mbuntit, experiena mpreun cu alte active trebuie returnate i motenite de mediul de
dezvoltare (reeaua) devenind astfel parte a activelor VBE.
Pentru a avea succes, managementul motenirii VO trebuie s fie urmat de managementul VBE,
deoarece organizaia virtual va fi dizolvat. Motenirea VO nu poate fi considerat de succes,
dac de exemplu, experiena stocat care este transmis ctre VBE nu este utilizat de ctre
aceasta din urm sau de o nou VO. Produsul/serviciul care este livrat clientului va deveni
proprietatea acestuia, astfel c aceasta nu face parte din motenirea VO. Obiectul motenirii
exclude activele care aparin exclusiv unui singur partener. Modelul VO i informaiile incluse n
acesta pot fi considerate ca motenire a VO.
Motenirea VO are rolul de a mri bagajul de active ale VBE. Activele VBE includ toate
elementele care au potenialul de a oferi valoare sau beneficii VBE sau membrilor ei atunci cnd
organizaii virtuale sunt create din VBE. Beneficiile pot fi realizate prin:
mbuntirea gradului de pregtire al VBE: organizaiile virtuale pot fi create i mai

repede
VO vor deveni mai eficiente i mai sigure n ceea ce privesc restriciile de timp, cost i
asigurarea calitii
Sprijin n ceea ce privete luarea deciziilor i monitorizarea abaterilor sau problemelor

VO
creterea valorii membrilor VBE prin creterea nivelului lor de cunotine i a poziiei lor
pe pia
Sprijinul n cadrul licitaiilor prin oferirea de cunotine despre client i relaiilor strnse
cu acetia
Sprijinul comercializrii serviciilor VBE ctre noi clieni prin oferirea de informaii de
referin. Referinele i reputaia creat pot fi folosite pentru a convinge clienii.
Principalele faze ale procesului de motenire al VO precum i localizarea lor n VBE i n ciclul
de via al VO. Aceste faze includ:
Crearea motenirii VO: motenirea VO este reprezentat de experiena operaional a VO.

Aceasta este dobndit pe parcursul ntregului ciclu de via al VO, ncepnd de la creare,
operare, evoluie i managementul disoluiei.
Stocarea motenirii VO n forma ei brut pe parcursul ciclului de via n diferite forme:

baze de date, documente, sisteme, relaii, n minile oamenilor, etc.
Analiza motenirii VO pe durata existenei acesteia.

54
Depozitarea motenirii VO n VBE. Aceast faz poate include combinarea a diferite

surse, procesarea, rafinarea datelor - poate fi fcut n VBE unde moteniri ale VO
precedente sunt disponibile.
Utilizarea motenirii VO: utilizarea poate avea loc n VBE sau n viitoare VO.
Managementul motenirii VO este necesar. Ar trebui s acopere att faza operaional a VBE ct
i ntregul ciclu de via al VO. Managementul motenirii VO implementeaz fazele motenirii
VO. De asemenea, definete regulile pentru colectarea, utilizarea i accesul la motenirea VO.
Motenirea crete numrul activelor VBE. Aceste active nu sunt concrete sau vizibile ca i
produsul creat pentru client, astfel nct VBE nu este de multe ori contient de existena lor.
Pentru a identifica diferitele forme de motenire a VO, o identificare a categoriilor de active ale
VBE este necesar. Romero i colaboratorii[76] au identificat trei categorii principale de active:
Capital financiar: resurse financiare i valori (bani, conturi, etc.), elemente de risc
Capital intelectual: date, informaii i cunotine, ambele n form tangibil sau

intangibil
Capital social: relaii cu clienii, furnizorii sau alte organizaii
Capitalul financiar este de obicei deinut de organizaii. Totui, este posibil n principiu, ca o
parte din profitul creat ntr-o organizaie virtual s fie motenit de VBE. Acesta poate fi folosit
pentru a plti serviciile comune de infrastructur, dezvoltarea de proceduri comune i posibil ca
fond de rezerv pentru rambursarea cheltuielilor unor clieni nemulumii.
Capitalul intelectual cuprinde toate datele, informaiile i cunotinele din bazele de date,
documentele precum i cunotinele tacite ale oamenilor. Informaiile pot consta n planuri i
experiena legat de realizarea lor, att din punct de vedere cantitativ ct i calitativ. Un model al
VO ct i o baz de date ce conine rezultatele msurtorilor de performan reprezint surse
importante pentru motenirea VO. Acestea pot fi transferate ca un pachet ctre VBE sau
informaia coninut de ele poate fi procesat mai nti.
Capitalul social are la baz colaborrile. Astfel, organizaiile virtuale n care partenerii
colaboreaz pentru atingerea unui obiectiv comun sunt contribuitori importani la capitalul social
al VBE prin relaiile de colaborare dintre membrii VBE i prin relaiile cu clienii.
Conform lui Schindler [74] factorii cheie pentru succesul nvrii n cadrul proiectului constau n
dezvoltarea i integrarea de metode bazate pe procese i documentaie, de exemplu nvarea
continu n cadrul proiectului n locul unei singure revizuiri. n contextul organizaiilor virtuale,
procesul de management al VO ar trebui s susin nvarea continu i colectarea de cunotine.
Exemple de metode bazate pe proces sunt: revizuirile, audit-ul, controalele.
Motenirea VO i propune s elimine decalajul introdus de caracterul temporar al acesteia.
Transformarea discontinuitii VO ntr-un proces continuu de nvare i mbuntire n VBE nu
este o sarcin uoar. Aceast sarcin necesit atenie la nivelul VBE i VO. n cadrul VBE
trebuie stabilite regulile de motenire, cine motenete ce, care sunt drepturile utilizatorilor i care
este gradul de accesibilitate i responsabilitile pentru managementul motenirii. Ar trebui
dezvoltate metode i instrumente pentru identificarea informaiilor importante i extragerea de
cunotine dintr-o cantitate mare de date i informaii. De asemenea, ar trebui identificate i
implementate practici de prezervare a activelor relaionale i structurale ale VO. Managementul
55
experienei, la fel ca i motenirea VO n CN este recunoscut ca o activitate important.

Barierele identificate pentru reutilizarea informaiilor sunt tehnologice, culturale i determinate
de procesele de lucru [75]. Diferiii actori ar trebui s neleag potenialele beneficii. Resursele
necesare pentru implementarea motenirii VO ar trebui puse n balan cu potenialele beneficii.
c) SUPERVIZAREA PROCESELOR COLABORATIVE N CADRUL VO
Un element cheie al managementului VO este reprezentat de supervizarea proceselor colaborative

din cadrul organizaiei virtuale. Un manager VO determin indicatorii de performan care ofer
informaii asupra statusului i operaiilor reelei sau ale entitilor lor i strnge informaii
necesare pentru a msura valoarea acestor indicatori. Abordarea sistematic de a planifica i
realiza colectarea de date cu privire la ndeplinirea taskurilor i a obiectivelor corespunztoare
poart numele de msurarea performanelor(MP). Msurarea performanelor este parte a
managementului performanei. Managementul performanei cuprinde: planificarea, msurarea,
monitorizarea i evaluarea, precum i mbuntirea performanei. Supervizarea proceselor
colaborative cuprinde planificarea i msurarea performanei. Supervizarea este punctul de
plecare pentru msurile de mbuntire, care reprezint de asemenea taskuri ale managementului
VO.
ntr-un VO pe termen scurt, cu un numr mic de parteneri, MP este fcut de multe ori manual
sau ntr-un mod ad-hoc, managerul VO folosete un telefon, fax sau email pentru a primi datele
de la membri. Acest lucru poate determina un efort semnificativ, fiind o procedur greoaie att
pentru manager ct i pentru membrii organizaiei, mai ales atunci cnd datele trebuie actualizate
frecvent. Ca urmare, este o tendin de a concentra MP n organizaiile virtuale pe un set limitat
de indicatori. Pentru a limita efortul, aceti indicatori sunt de obicei similari cu cei din afacerile
obinuite, cnd companiile lucreaz pe cont propriu. Exemple tipice sunt reprezentate de devieri
ale costurilor de la plan, progresul muncii i problemele de calitate. Experienele n aceste arii
arat c evaluarea performanei i indicatorii considerai nu sunt aliniate corespunztor la
specificul colaborrii n cadrul organizaiilor virtuale. Att timp ct managerul i membrii VO au
o vedere informal satisfctoare asupra activitilor i relaiilor, aceast msurare ad-hoc a
performanelor va fi la rndul ei satisfctoare. Totui, organizaiile virtuale pot fi complexe,
presupunnd taskuri ce necesit o varietate mai larg de competene i mai multe resurse.
Corespunztor, un numr mai mare de diveri parteneri sunt implicai. n plus, organizaiile
virtuale mai complexe pot acoperi un interval de timp mai lung, pot fi mai dinamice, i pot avea
de a face cu un grad mai mare de incertitudine. n aceste cazuri, msurarea ad-hoc a
performanelor nu mai este fezabil i nu mai poate oferi conducerii informaiile necesare ntr-un
mod adecvat. n aceste cazuri, managerul VO are nevoie de o abordare structurat a MP n cadrul
VO i de servicii de susinere. De exemplu, un sistem care susine selecia i transferul de
informaie ar putea s scuteasc managerul de complexitatea inutil a specificrii, cutrii i
obinerii de informaii care sunt relevante pentru o vedere de ansamblu i luarea unei decizii.
Cercetarea a oferit mai multe abordri pentru MP adoptate ulterior n practic. Totui, aceste
abordri s-au concentrat pe MP inter/intra-organizaionale n cadrul lanurilor de aprovizionare
unde colaborrile sunt statice. Nu exist unelte sau abordri specifice MP n organizaii virtuale
dinamice, avnd membri eterogeni, independeni i distribuii. Ar trebui analizate care sunt
cerinele specifice msurrii performanelor n cadrul organizaiilor virtuale, felul n care
56
abordrile MP existente satisfac aceste cerine i cum pot fi acestea adaptate i completate pentru
a le satisface.
d) Provocri pentru msurarea performanei n organizaiile virtuale
Abordrile de msurare a performanelor existente constau n dou pri principale: (1)

perspective i indicatori de performan; (2) conceptul de msurare a performanelor. Indicatorii
de performan descriu coninutul ce trebuie msurat pentru a determina performana unui proces
de afaceri. Unele abordri sugereaz diferite perspective din care poate fi evaluat performana,
cum ar fi perspectiva financiar care cuprinde diferii indicatori pentru costuri, capital, capital
investit. Literatura, ct i mediul practic ofer cteva cadre model n contextul msurrii
performanei afacerilor. Unele ofer seturi predefinite de indicatori de performan, altele ofer
doar concepte, iar altele ofer metodologii holistice ce integreaz concepte cu indicatori de
performan. Abordrile existente ofer o gam larg de perspective i indicatori de performan:
financiar, performana proceselor, calitate, relaia cu clienii i furnizorii, precum i aspecte legate
de capitalul intelectual i valoarea mrcii.
Niciuna din abordrile existente nu este aliniat n mod explicit la colaborarea business ntre
parteneri independeni. Nici nu exist o perspectiv de performan care se refer la colaborare
sau la un proces pentru monitorizarea colaborativ a performanelor. Decalajul introdus de lipsa
unei perspective pentru interaciunea dintre partenerii ce colaboreaz n cadrul unei reele a fost
identificat i dezbtut n cadrul ctorva lucrri de cercetare: [77], [78], [79] i alii. Ei
sugereaz perspective de performan cum ar fi: echitatea, flexibilitatea, fiabilitatea,
receptivitatea, colaborarea eficient, schimbul de informaii, etc.
O abordare consistent a MP pentru VO lipsete. Prin urmare este necesar un cadru model pentru
msurarea performanelor organizaiilor virtuale care s ofere managerului VO ndrumare i
suport.
VO au anumite caracteristici care le difereniaz de organizaiile tradiionale precum i de
lanurile de aprovizionare. Aceste diferene ar putea influena structura i procesele MP. Prin
urmare, ar trebui analizate aici care sunt principalele provocri pentru MP n organizaiile virtuale
i cum abordrile i uneltele pentru MP existente ar putea face fa acestor provocri. Aa cum nu
exist o nelegere universal a termenului MP sau o utilizare a sa invariabil, este necesar o
descriere de baz a conceptului de msurare a performanelor considerat. n felul acesta, se
identific o baz a provocrilor MP pentru VO. Scopul MP este de a evalua performanele
afacerii din diferite perspective i cazuri de utilizare. Cteva din cauzele msurrii performanelor
afacerii de ctre companii sunt urmtoarele [80]:
Pentru a monitoriza i controla
Pentru a aduce mbuntiri
Pentru a maximiza eficiena eforturilor de mbuntire
Pentru a realiza alinierea cu scopurile i obiectivele organizaionale
Pentru a recompensa i disciplina
57
Pentru a obine acest lucru, MP trebuie s atribuie valori indicatorilor de performan (IP), care
reprezint variabile ce evalueaz starea unui obiect ale crui performane sunt msurate, cum ar
fi: costul, rezultatul procesului de producie sau capacitatea de rspuns a unui partener. Indicatorii
de performan ar putea fi calitativi sau cantitativi. Indicatorii Cheie de Performan reprezint
componente eseniale sau critice care au un impact covritor asupra succesului organizaiei.
Pentru a obine valori pentru IP, trebuie efectuate msurtorile corespunztoare. Msurtorile ar
trebui nelese ntr-un sens general ca i colectare de date. Acest lucru poate fi realizat prin
ntrebarea persoanelor responsabile sau prin accesarea bazelor de date electronice. Variabilele
msurate se numesc metrici. Unele valori ale IP sunt calculate folosind mai multe metrici, de
exemplu indicatorul interval de timp poate fi calculat din valorile obinute pentru msurtorile
start i sfrit.
Valorile IP sunt furnizate de clienii MP. Principalul client este de obicei managementul
organizaiei n cauz. Pot fi de asemenea i ali clieni, cum ar fi angajaii organizaiei, clienii ei,
investitori sau alte pri interesate. Ei pot folosi valorile indicatorilor pentru o procesare i analiz
ulterioar .
Pentru a analiza felul n care msurarea parametrilor n cadrul organizaiilor virtuale este afectat
de caracteristicile acestora, vor fi prezentate n continuare principalele provocri pentru MP n
cadrul VO.
O prim provocare este reprezentat de independena membrilor VO. Acetia sunt n general
independeni unii fa de alii, lucrul acesta avnd dou mari consecine asupra VO. n primul
rnd, companiile au propriile afaceri n afara organizaiei virtuale i propriile obiective, planuri,
structuri i procese pentru afacerile lor. Pe de o parte, aceasta ar putea nsemna o competiie ntre
activitile din cadrul VO i alte activiti ce nu sunt legate de aceasta. Pe de alt parte, n multe
cazuri exist posibilitatea ca membrii organizaiei virtuale s devin competitori pentru alte
oportuniti de afaceri. A doua consecin este c VO are posibiliti limitate de a controla
partenerii dincolo de obligaiile contractuale. Acest lucru are urmtoarele implicaii pentru MP:
Msurarea Performanelor la nivelul VO trebuie conectat la procesul intern al fiecrui

membru. Se pot folosi valori existente pentru Indicatorii de Performan sau metrici
interne organizaiilor. Totui, exist posibilitatea necesitii unor msurtori suplimentare.
Furnizarea de date necesare MP depinde de nivelul de ncredere ntre partenerii

organizaiei virtuale, i de angajamentul lor pentru colaborare
n mod normal, membrii VO nu pot fi forai s pun la dispoziie sursele lor de date sau
s ofere anumite date care nu au fost stipulate n contract. Atunci cnd apare necesitatea
unor Indicatori de Performan adiionali pe durata fazei operaionale, este necesar
bunvoina membrilor.
Pentru multe organizaii, este important s se pstreze controlul local n ceea ce privete
msurarea i furnizarea datelor
MP trebuie s acopere aspectele colaborrii, aceasta nsemnnd contribuii i angajament

dincolo de obligaiile contractuale
O a doua provocare este reprezentat de natura eterogen a structurilor, proceselor i culturilor.
Membrii VO nu sunt de obicei doar organizaii independente, ci acoper diferite arii
58
complementare de competene care sunt necesare pentru a ndeplini taskurile VO. n plus, ei pot
fi localizai oriunde pe glob. Astfel c au diferite structuri organizaionale i ICT, procese, culturi
interne, legislaii i culturi regionale. Aceste lucruri au urmtoarele implicaii pentru MP:
Este necesar o definiie foarte clar a indicatorilor, a msurilor i responsabilitilor

pentru a evita nenelegerile i interpretrile greite. Pe cnd ntr-o singur companie sunt
de obicei standarde i cunotine despre structura general a proceselor interne, ntr-o
organizaie virtual, membri diferii pot avea moduri diferite de nelegere a momentelor
de nceput i sfrit ale unui proces sau asupra standardelor de calitate
MP trebuie s fie flexibil pentru a lua n considerare condiiile specifice diferiilor

membri ai VO
Sunt necesare diferite interfee pentru a face disponibile datele pentru MP n cadrul VO
deoarece sursele de date sunt eterogene, iar unii membri, n special cei mici, pot s nu
aib alte instrumente ICT n afara aplicaiilor de birou i de acces la internet
Distribuia partenerilor reprezint a treia provocare. Membrii VO pot fi localizai ntr-un mod
distribuit, chiar i n ri sau pe continente diferite. n aceste condiii, coordonarea fa n fa
sau transferul fizic de documente necesit eforturi suplimentare. Aceste condiii implic pentru
MP:
Necesitatea unor definiii clare pentru a evita necesitatea coordonrii la faa locului
MP trebuie s se bazeze pe tehnologiile ICT pentru realizarea transferului de date

electronice i pentru accesul distribuit pentru diferiii membri ai VO
A patra provocare este reprezentat de unicitatea i durata limitat a existenei unei organizaii
virtuale. VO sunt create pentru o anumit oportunitate de colaborare i dizolvate atunci cnd
sarcina a fost dus la bun sfrit. Durata de via a unei astfel de organizaii se poate ntinde de la
cteva sptmni la civa ani. Ca o consecin a acestei limitri, fiecare organizaie virtual este
unic, din momentul n care a fost dizolvat, nu va mai fi creat o organizaie identic niciodat.
Implicaiile pentru MP n acest caz sunt:
Trebuie dezvoltat un nou sistem de msurare a performanelor pentru fiecare organizaie

virtual nou creat
Nu poate fi creat o baz de date care s conin un istoric, ca n cazul companiilor sau
reelelor colaborative statice
Perioada de implementare a sistemului de msurare a performanelor trebuie adaptat

duratei de via a organizaiei. Pentru organizaii virtuale cu o durat de via scurt,
aceast perioad trebuie s fie la rndul ei foarte scurt
Efortul de implementare a sistemului de msurare a performanelor trebuie s fie minim

deoarece durata de viaa a organizaiei este limitat. Pri ale acestui sistem pot fi ulterior
refolosite n alte organizaii
Provocrile vizeaz att coninutul MP (performana n ceea ce privete colaborarea) ct i
metodologia de implementare a sistemului de msurare a performanei i de operare al lui.
Provocrile ce privesc metodologia sunt urmtoarele:
59
MP n cadrul VO trebuie fcut ntr-un mod colaborativ de ctre membrii si. Acest lucru
presupune existena unor obiective comune i angajamente privind MP
Nevoia de flexibilitate pentru a reduce sau limita resursele i timpul necesare pentru
implementarea i operarea sistemului de MP
Sistemul de msurare a performanelor trebuie s fie adaptabil la procesele i structurile

membrilor VO i s fie conectat la activitile interne ale acestora
Controlul local trebuie permis pentru a evita lipsa de ncredere n ceea ce privete
participarea n sistemul de MP
MP trebuie s fie bazat pe tehnologii ICT n cadrul VO pentru a fi accesibil ntr-un mod
eficient de ctre membrii distribuii ai organizaiei
e) Msurarea Performanei n Organizaii Virtuale
Msurarea performanei ofer datele necesare managementului VO. MP trebuie s in cont de

caracteristicile VO pentru a fi eficient. Abordrile dezvoltate pentru organizaii individuale sau
pentru cooperarea ntre mai multe organizaii ntr-un mod static trebuie adaptate i extinse pentru
a satisface nevoile organizaiilor virtuale. Un cadrul de modelare MP aliniat cerinelor VO poate
susine managementul VO i sarcinile de msurare a performanei.
Camarinha-Matos [9] propun un cadru model pentru msurarea performanei n cadrul
organizaiilor virtuale (VOPM - Virtual Organisation Performance Monitoring). VOPM poate fi
definit ca o abordare sistematic pentru a planifica i efectua colectarea de date calitative i
cantitative pentru indicatorii de performan care evalueze starea VO. VOPM reprezint una din
funciile de management ale VO. Managerii VO trebuie s defineasc Indicatorii de Performan
care ar trebui msurai i monitorizai la fel ca i valorile int sau cele admise.
Obiectivele VOPM pot fi deduse pe baza cerinelor diferiilor clieni(beneficiari i utilizatori ai
datelor oferite de VOPM) ai cadrului de modelare. Principalul client este managementul VO care
utilizeaz datele pentru monitorizarea felului n care sunt ndeplinite obiectivele VO i
controleaz procesele n cadrul organizaiei. Unitile organizaionale i angajaii implicai n
activitile VO pot fi de asemenea clieni ai VOPM dac folosesc datele pentru a-i monitoriza i
controla munca.
Nu orice activitate de a msura a unui membru VO face parte automat din VOPM. Cadrul de
modelare se concentreaz la nivel de reea. Lucreaz cu indicatorii de performan relevani
pentru reea, adic pentru mai mult de un membru. Astfel, cadrul VOPM nu nlocuiete
monitorizarea performanelor fiecrui membru n parte. Acetia trebuie s defineasc i s
msoare indicatori de performan pentru a-i controla procesele interne. Nivelul reea include un
nivel VO i un nivel membru VO. La nivelul VO sunt msurai:
Indicatorii de realizare care consider rezultatele generale obinute prin de organizaia

virtual. Realizrile reprezint produse livrate clientului, venituri aduse membrilor sau
ndeplinirea obiectivelor stabilite.
60
Indicatori pentru evaluarea interaciunilor dintre membrii organizaiei virtuale. Aspecte

importante sunt eficacitatea i eficiena colaborrii
MP la nivelul membrilor VO se concentreaz asupra interfeei dintre un membru VO i restul
reelei. Indicatorii de performan ai proceselor interne ale unui membru VO nu sunt luai n
considerare dect n cazul n care sunt necesari ca date de intrare pentru ali membri VO.
Conform Vervest[81] rolurile importante pentru msurarea performanelor sunt: cel care creeaz
informaia, cel care transmite informaia (brokerul) i cel care utilizeaz informaia. Sursa
informaiei este reprezentat de creatorul informaiei care efectiv msoar datele necesare ce sunt
produse pe durata activitilor organizaiei virtuale. Creatorul poate procesa datele pe care s le
ofere mai apoi brokerului sau utilizatorului. Utilizatorul folosete datele primite ca intrare pentru
deciziile i activitile sale. Managementul VO nu este numai principalul utilizator al datelor dar
este de asemenea responsabil cu implementarea i operarea VOPM. Aceasta include alocarea de
resurse pentru VOPM, definirea indicatorilor de performan i surselor de date i a valorilor
int. VOPM nu poate funciona fr creatorii de informaie. Acetia sunt reprezentai de membrii
VO .
Pentru a obine rezultate din VOPM, trebuie s existe procese care s proiecteze, implementeze
i opereze. Cercetarea n direcia proceselor pentru evaluarea performanelor include [82], [83],
[84], [85].
Un pas esenial n procesul VOPM este definirea indicatorilor de performan ce trebuie
considerai. Ca i n cazul companiilor, Organizaiile Virtuale trebuie s ndeplineasc cerinele
clienilor lor. Setul principal de indicatori poate fi dedus din aceste obligaii contractuale. Pasul
urmtor este identificarea indicatorilor pentru a controla procesul de creare de valoare i a susine
producia global pentru clieni. n timp ce procesul de creare de valoare contribuie direct la
ieire, cum ar fi asamblarea unui produs, procesele de susinere creeaz condiiile necesare i
intrrile pentru procesul de creare de valoare, ex. mediul ICT, achiziii de bunuri sau gestionarea
resurselor umane.
f) Msurarea eficienei colaborrii
O provocare specific VO este msurarea eficienei colaborrii n cadrul organizaiei.
Colaborarea este un catalizator n cadrul organizaiei pentru crearea de valoare i suportul
proceselor. Printr-o colaborare eficient, toi membrii organizaiei pot contribui la potenialul lor
maxim. Nevoia unei colaborri eficiente este determinat de caracteristicile VO: independena
partenerilor, eterogenitatea structurilor, proceselor i culturilor, efemeritatea organizaiei.
Eficiena colaborrii se axeaz pe eficiena interaciunilor i pe comportamentul emergent n
cadrul organizaiei virtuale. Pentru a obine datele corespunztoare pentru managementul VO
aspectul care privete eficiena colaborrii este integrat n cadrul de modelare VOPM. Abordrile
pentru MP prezentate nu iau n considerare conceptul de eficien a colaborrii, potrivit pentru
VO. De aceea, cadrele de modelare a indicatorilor de performan trebuie extinse. Este propus
privirea eficienei colaborrii ca o perspectiv ce nsumeaz diferii indicatori privind eficiena
interaciunilor dintre membri. Aceasta este o completare la perspectivele tradiionale aplicabile
organizaiilor virtuale (cost, calitate, timp). Implicarea membrilor VO distribuii i independeni
duce la o dependen ntre contribuiile diferiilor membri. Astfel, un aspect important al
eficienei colaborrii este ncrederea membrilor. Din perspectiva proceselor, ncrederea poate fi
evaluat prin indicatori care msoar dac materialele, informaiile, resursele sunt livrate n
61
normele de calitative, cantitative i de timp stabilite. Din perspectiva financiar, este analizat
costul. Indicatori de performan pentru fiabilitate, flexibilitate, comunicaie apar i n alte
abordri [86]. Totui, aceti indicatori nu au fost folosii pentru a msura eficiena colaborrii.
Perspectiva angajamentului este un element de baz al eficienei colaborrii n cadrul VO. Ea
nglobeaz aspectele eficienei colaborrii strns legate de atitudinea ctre organizaia virtual i
fa de interaciunea cu ali membri. Angajamentul ia n considerare contribuii ctre VO care nu
sunt definite formal, dar deriv din motivaia partenerilor.
f) Suportul ICT pentru VOPM

n cazul n care Organizaia Virtual devine complex din punct de vedere al mrimii, dinamicii,
nivelului de eterogenitate, MP trebuie susinut de unelte ICT pentru a uura munca managerului
organizaiei. Acestea ar trebui de asemenea s reduc complexitatea specificrii, cutrii i
obinerii informaiilor necesare unei vederi de ansamblu asupra VO. Majoritatea produselor i
soluiilor pentru suportul managementului se concentreaz asupra unei singure organizaii,
neputnd fi direct aplicate ntr-o reea de organizaii.
g) Soluii pentru managementul Organizaiilor Virtuale
Adevrata provocare pentru managementul VO const n capacitatea de a gestiona

operaiuni distribuite n cadrul organizaiilor independente, dar interdependente, care au propriul
lor scop, comportament i cultur. Acest lucru nseamn c managementul VO trebuie s se
bazeze pe coordonare pentru a putea atinge obiectivele VO:
fr a folosi fora
prin stabilirea ncrederii i lund n vedere riscurile
acionnd pe baza unor informaii incomplete

Supravegherea inter-organizaional, controlul i coordonarea activitilor i a resurselor n cadrul
unei VO sunt principalele sarcini ale managerului. Capacitatea de a superviza
comportamentul unui singur proces de afaceri permite sincronizarea i orchestraia VO prin
adaptarea i optimizarea procesului de afaceri complet distribuit. Managementul VO primete
date i informaii de la statusul operaiilor n cadrul VO.
1.3.2.4. Concluzii
n acest paragraf sunt prezentate conceptele de reele colaborative, organizaie virtual, mediu de
dezvoltare al organizaiilor virtuale mpreun cu caracteristicile acestora i stadiul actual. Am
explicat care sunt membrii VBE, ciclul de via al unui VBE, ce presupune managementul VBE,
guvernarea i managementul VO i cum se poate msura eficiena colaborrii n cadrul VO. CN
implic utilizarea unei reele pentru a comunica i pentru a schimba informaii. Caracteristicile
serviciilor web cum ar fi flexibilitatea, reutilizarea, compozabilitatea au permis adoptarea
acestora n cadrul reelelor colaborative. Serviciile web furnizate de organizaiile ce fac parte
62
dintr-o reea colaborativ pot fi compuse pentru a forma un proces de afaceri n funcie de
oportunitile de afaceri aprute sau de necesitatea de colaborare ntre organizaii. n paragraful
urmtor sunt descrise principalele modele de compunere a serviciilor web.
1.3.3. Modele de compunere a serviciilor web
1.3.3.1. Concepte
n [87] autorii identific urmtoarele grupe de motive ce determin adaptarea sistemelor
software: corective (eliminarea comportamentului eronat), adaptive (rspuns la schimbrile ce
afecteaz contextul), extensive (extind sistemul cu noi funcionaliti), i perfective (mbuntesc
caracteristicile unei aplicaii). De asemenea, adaptarea este clasificat la rndul su n mai multe
categorii: adaptare arhitectural (afecteaz structura sistemului), adaptarea implementrii
(afecteaz implementarea componentelor fr a modifica ns interfeele), adaptarea interfeelor
(afecteaz interfeele componentelor), adaptarea geografic (afecteaz distribuirea componentelor
de-a lungul reelei). n [88] abordrile adaptive sunt clasificate n: adaptri ale parametrilor, caz
n care variabilele ce determin comportamentul sistemului sunt afectate i adaptri ale
compoziiei, situaie n care pri structurale ale sistemului sunt schimbate. Separarea conceptelor
i proiectarea bazat pe componente a oferit programatorilor instrumentele necesare pentru a
construi sisteme adaptive ntr-un mod sistematic, tehnologia middleware permind
comportamentul adaptiv. Aceste tehnologii, combinate n diferite feluri, au condus la dezvoltarea
unei game largi de principii i abordri n ceea ce privete Adaptabilitatea aplicaiilor [88], [89].
Adaptarea(figura 1.9.) poate fi definit ca fiind procesul de modificare al unei aplicaii bazat pe
servicii pentru a satisface noi cerine sau situaii pe baza unor strategii de adaptare proiectate de
integratorul de sistem [90]. O aplicaie bazat pe servicii poate fi definit ca adaptabil dac
dispune de o bucl de control care s permit monitorizarea i ulterior modificarea aplicaiei pe
baza unor strategii predefinite. Aciunile de adaptare pot avea loc datorit unei probleme
identificate n timpul monitorizrii, datorit identificrii unei posibile optimizri, sau datorit
contextului de execuie(serviciile ce compun SBS, resursele de calcul disponibile, protocoalelor
folosite) schimbat.
Specificaiile de adaptare identific aspectele modelului SBS care sunt supuse schimbrii i care
sunt rezultatele ateptate n urma procesului de adaptare. Strategiile de adaptare sunt modalitile
prin care cerinele de adaptare sunt satisfcute: reconfigurare - modificarea parametrilor cureni ai
SBS, substituire - nlocuirea unui serviciu cu un altul, compensare - nlturarea efectului negativ
al unei aciuni anterioare prin executarea unor noi aciuni, replanificare - modificarea structurii i
modelului aplicaiei, recompunere a serviciilor, renegociere - modificarea SLA mpreun cu
furnizorul de servicii.
Strategiile de adaptare sunt realizate folosind mecanismele de adaptare disponibile ce pot
include instrumente pentru efectuarea efectiv a aciunilor de adaptare(mecanisme de realizare) i
instrumente pentru luarea deciziilor privind adaptarea (mecanisme de decizie - mecanisme
folosite pentru selectarea unei strategii de adaptare din mai multe alternative posibile, istoricul
adaptrilor anterioare, preferinele i deciziile utilizatorului).
63
Procedura de adaptare poate viza diferite elemente ale SBS. Procesul de adaptare implic diferii
actori care acoper diverse roluri pe care utilizatorii le pot avea n proces. Atunci cnd aceste
roluri sunt ndeplinite de componentele software corespunztoare , putem vorbi de abordri auto-
adaptive.
Fig. 1.9. Model de adaptare al unei aplicaii bazate pe servicii [90]
n subcapitolul urmtor vom prezenta o clasificare a modelelor de compunere a serviciilor.
1.3.3.2. Clasificarea modelelor de compunere a serviciilor
O proprietate important a serviciilor care fac parte dintr-o arhitectur orientat ctre servicii
(SOA) o reprezint compozabilitatea lor [91]. O compunere de servicii combin mai multe
servicii mpreun pentru a obine un scop. Exist mai multe moduri de utilizare pentru
compunerea de servicii.
Cele mai importante modele de compunere de servicii sunt orchestrarea i coregrafia. Alte trei
modele de compunere de servicii sunt reprezentate de coordonarea i asamblarea serviciilor
precum i compunerea semantic a serviciilor [90].
Procesele de afaceri pot fi implementate prin orchestrarea funciilor business existente
implementate ca servicii. O astfel de orchestrare de servicii implementeaz o parte a procesului
de afaceri care este apoi publicat ca un serviciu ce poate fi folosit n alte procese de afaceri. ntr-o
orchestrare de servicii, un nou serviciu este creat prin combinarea mai multor servicii existente
ntr-un flux proces.
n contextul serviciilor web, au fost cteva ncercri in ceea ce privete limbajele pentru
modelarea orchestraiilor. Printre acestea se numr: Web Service Flow Language (WSFL) [92],
XLANG [93], BPML [94], BPEL [95]. Limbajul standard adoptat pentru orchestrarea serviciilor
web este WS-BPEL [95] BPEL reprezint convergena a dou limbaje anterioare, WSFL i
XLANG. Procesele de afaceri pot fi descrise n dou feluri. Procesele business executabile
descriu activitatea unui participant n interaciunea business. Procesele business abstracte sunt
specificate parial fr intenia de a fi executate. Un proces abstract poate ascunde o parte din
detaliile operaiilor necesare avnd astfel un rol descriptiv. Acesta poate fi folosit in mai multe
situaii, servind ca un ablon proces.
64
ntr-o orchestrare(figura 1.10), care este de obicei folosit ntr-un proces de afaceri privat, un
proces central (care poate fi un alt serviciu Web) preia controlul asupra serviciilor Web implicate
i coordoneaz execuia a diferite operaii asupra lor. Serviciile implicate nu au cunotin despre
faptul ca sunt parte a unei compoziii si al unui proces de afaceri. Doar coordonatorul central este
contient de scop, astfel nct orchestraia este centralizat avnd o ordine explicit definit
pentru operaii ct i pentru invocarea serviciilor.[96]
Fig. 1.10. Compunere de servicii ntr-o orchestrare [96]

Modelele de coreografii de servicii sunt folosite pentru descrierea interaciunilor ntre servicii
dintr-o perspectiv global. Ele sunt folosite pentru a descrie serviciul public al unui partener de
afaceri, spre deosebire de orchestraiile de servicii care descriu procesul privat executabil al unui
singur partener. Astfel, o coreografie definete interaciunile dintre servicii. Ele sunt specificate
prin limbaje cum ar fi WS-CDL sau BPEL4Chor [97]. WS-CDL [98] este un limbaj bazat pe
XML care descrie colaborrile de tip peer-to-peer ale participanilor, prin definirea unui punct
de vedere global i a comportamentului lor observabil comun i complementar. n acest context
schimbul ordonat de mesaje va duce la ndeplinirea unui scop comun. Scopul WS-CDL este de a
compune colaborri interoperabile de tip peer-to-peer ntre orice tip de participani, indiferent
de platforma sau modelul de programare folosite pentru implementare. BPEL4Chor [99] ofer
mijloacele necesare pentru a descrie o coreografie folosind WS-BPEL 2.0. Limbajul preia ideea
de plug-links din WSFL la care adaug modelarea seturilor participanilor i a referinelor
participanilor.
Deoarece o coreografie nu se bazeaz pe un coordonator central, fiecare serviciu implicat tie
cnd s-i execute operaiile i cu cine s interacioneze(figura 1.11). Coreografia [96] reprezint
un efort colaborativ orientat ctre schimbul de mesaje ntre procese de afaceri publice. Toi
participanii la coreografie, trebuie s fie contieni de procesul de afaceri, operaiile pe care
trebuie s le execute, mesajele ce trebuie schimbate i momentul la care trebuie s se realizeze
schimbul de mesaje. Fiecare participant ntr-o coreografie de servicii poate fi modelat ca o
orchestrare de servicii, aceasta fiind practic implementarea acelui participant. Coreografia
ncadreaz implementarea unui participant n cadrul contextul global prin definirea interaciunilor
bazate pe mesaje cu ceilali participani. Notaiile sunt folosite n cadrul coreografiilor pentru a
suporta descrierea interaciunilor de tip mesaj dintre participani. Acestea pot fi mprite n dou
categorii [90]: (1) paradigme pentru modelarea interaciunilor, n care notaiile descriu
65
interaciunile ntre participani. Principalele paradigme sunt: interfa pentru interaciune n care
logica interaciunilor este definit global i interfa pentru interconectare n care logica
interaciunilor este definit pentru fiecare participant; (2) nivelul de abstractizare (specific
implementrii sau independent de implementare), care definete gradul de dependen ntre
notaiile folosite i un set particular de tehnologii.
Fig. 1.11. Compunere de servicii ntr-o coregrafie [96]
Coordonarea serviciilor are loc atunci cnd serviciile trebuie s urmreasc un anumit protocol
condus de un coordonator central pentru a efectua o activitate distribuit. Modelele de coordonare
a serviciilor sunt folosite n cazul n care mai multe servicii trebuie s cad de acord asupra
rezultatului execuiei unui proces distribuit folosind un coordonator central i un protocol de
coordonare. Coordonarea serviciilor este similar cu coreografia de servicii cu diferena c
participanii nu trebuie s comunice unul cu cellalt, ci doar cu coordonatorul care decide
rezultatul protocolului (eec sau succes) informnd i participanii. Modele de coordonare a
serviciilor pot fi definite folosind WS-Coordination [100]. WS-Coordination definete un cadru
pentru modelarea interaciunilor ntre serviciile web. Standardul permite serviciilor participante
s ajung la un acord comun n ceea ce privete rezultatul aciunilor folosind un coordonator
bazat pe un protocol de coordonare. Coordonatorul este compus din trei servicii: (1) serviciu de
activare care permite unei aplicaii s creeze o instan de coordonare sau context; (2) serviciu de
nregistrare care permite unei aplicaii s se nregistreze la coordonator; (3) un set de protocoale
pentru coordonare specifice coordonatorului.
Modelele de asamblare a serviciilor definesc felul n care servicii diferite ar trebui mpachetate
mpreun ntr-o soluie software care s poat fi deploy-at. Asamblarea serviciilor se face n
timpul deployment-ului aplicaiilor bazate pe servicii.
Serviciile web semantice conin descrieri formale bogate ale capabilitilor lor ntr-un format
interpretabil de calculator. Acest lucru permite compunerea automat, descoperirea, invocarea
66
dinamic a serviciilor. Dezvoltarea serviciilor web semantice a fost posibil odat cu apariia i
evoluia web-ului semantic (Semantic Web). Cele mai importante iniiative privind adnotarea
semantic a serviciilor web sunt reprezentate de OWL-S [101] i WSMO (Web Service Modeling
Onthology) [102].
1.3.4. Abordari privind adaptabilitatea aplicatiilor orientate pe servicii
1.3.4.1. Taxonomia adaptrii
Metodele de abordare a problemei adaptrii asigurate prin servicii web pot fi clasificate conform
diferitor criterii. Rspunsurile la ntrebrile tradiionale n managementul ntreprinderii : De ce?,
Cine?, Care? si Cum are loc adaptarea? [103] definesc urmtoarele patru dimensiuni privind
dezvoltarea aplicaiilor orientate ctre servicii care asigur proprietatea de adaptabilitate a unui
VO.
Dimensiunea d1: De ce?

Aceasta prim dimensiune a taxonomiei constat cauzele nevoii pentru adaptare. ncearc
sa identifice motivaia din spatele adaptrii. In funcie de scopul procesului de adaptare, se pot
identica cinci tipuri de adaptare:
Adaptarea Perfectiv are ca scop mbuntirea aplicaiei chiar dac aceasta
funcioneaz corect, de ex. s optimizeze calitativ.
Adaptarea Corectiv are ca scop ndeprtarea comportamentului eronat al SBA (Service
Based Application) prin nlocuirea ei cu o versiune nou care furnizeaz aceeai funcionalitate.
Diferite erori pot sa apar destul de des si pe neateptate n sistemele distribuite. Astfel este
necesar rezolvarea erorilor raportate in timpul execuiei SBS pentru a corecta comportament
nedorit sau pentru a schimba logica aplicaiei i pentru a ndeprta posibila viitoare eroare.
Adaptarea Flexibil modific aplicaia ca rspuns la schimbrile care afecteaz mediul
acesteia. Nevoia pentru acest tip de adaptare n SBA este dictat de (1) necesitatea de adaptare la
schimbrile in contextul SBA (context de execuie, context al utilizatorului sau context fizic); (2)
nevoia de a asigura interoperabilitatea intre prile care interacioneaz furniznd adaptri
corespunztoare sau mediatori; (3) necesitatea de a personaliza aplicaia conform nevoilor si
cerinelor anumitor utilizatori sau clieni.
Adaptarea Preventiv are ca scop nlturarea viitoarelor erori sau probleme extra -
funcionale nainte ca ele sa apar.
Adaptarea Extins extinde aplicaia prin adugarea de funcionaliti noi.
Dimensiunea d2: Cine?

Aceasta dimensiune a taxonomiei rspunde la ntrebarea Cine se afl in spatele procesului de
adaptare? sau Cine sunt participanii adaptrii de baz? Exist patru tipuri de participani:
Solicitantul Adaptrii caracterizeaz prile interesate, care definesc cerinele de
adaptare pentru un SBS.
67
Proiectantul Adaptrii, care definete strategiile adaptrii pentru a duce la bun sfrit
cerinele adaptrii.
Iniiatorul Adaptrii, care iniiaz modificarea aplicaiei n raport cu modificrile
necesare ce au fost identificate anterior.
Executantul Adaptrii este responsabil pentru executarea aciunilor de adaptare definite
de strategia de adaptare aleas.
Dimensiunea d3: Care?

Aceast dimensiune a taxonomiei ncearc sa rspund la urmtoarele dou ntrebri: (i)
care este inta adaptrii? si (ii) care este rezultatul ateptat? Sunt luate in considerare trei
elemente ale acestei taxonomii: Subiectul adaptrii, de exemplu entitatea care ar trebui sa fie
modificat prin procesul de adaptare, Aspectul Adaptrii, de exemplu detaliile cu privire la
procesul de adaptare (siguran, aplicabilitate, funcionalitate) i Scopul Adaptrii, de exemplu
efectul procesului de adaptare (temporar sau permanent). Pentru subiectul adaptrii putem
distinge patru tipuri la nivelul superior de abstracie:
Exemplul SBA, exemplul procesului de afacere, o aplicaie individualizat pentru un
anumit utilizator, conform profilului su de utilizator, o anumit configuraie a serviciului.
Clasa SBA care definete ntregul model al aplicaiei, inclusiv modelul procesului de
afacere, cerinele afacerii si Indicatorii Cheie de Performanta (KPI).
Contextul SBA cuprinde aspecte variate, de exemplu mediul utilizatorului/fizic/de calcul
n care se desfoar aplicaia.
Mecanismele Adaptrii si Monitorizrii modific felul n care sistemul este schimbat si
administrat.
Dimensiunea d4: Cum?

Aceast dimensiune a taxonomiei descrie cum se poate realiza si implementa adaptarea,
care sunt strategiile specifice adaptrii si mecanismele folosite pentru a implementa adaptarea.
Strategiile Adaptrii definesc modalitile posibile pentru a ndeplini Cerinele Adaptrii i
obiectivele date de mecanismele de adaptare care sunt disponibile n straturile funcionale diferite
ale SBS. Exemple de strategii de adaptare sunt reconfigurarea (de exemplu modificarea
parametrilor de configurare curenta ai SBA), nlocuirea, compensarea (de exemplu ndeprtarea
efectelor negative ale execuiilor anterioare), replanificarea (de exemplu modificarea structurii i
modelului SBS), recompunerea, renegocierea.
Strategiile de Adaptare pot fi clasificate conform locaiei, metodologiei folosite i modului n
care strategia este specificat.
Locaia determin plasarea schimbrilor n SBS prin procesul de adaptare:
o Scopul adaptri (orizontal) determin dac schimbrile sunt locale
(restricionate unui serviciu sau clienilor specifici) sau globale (modificri la scar mare).
O Nivelele funcionale ale SBS ce sunt afectate (vertical)
68
Modificrile pot avea loc la nivelul infrastructurii si afecteaz semnturile

serviciilor, protocoalele si timpul de rulare; la nivelul compunerii de servicii
afecteaz comportamentul i/sau semantica operaional ale SBS; la nivelul
business (sunt implicate reguli si cerine business); sau pot fi schimbri care
afecteaz mai multe nivele ale SBS.
Metodologia Adaptrii caracterizeaz sincronizarea, distribuia si direcia adaptrii:
o Sincronizarea definete momentul n care are loc adaptarea. Putem distinge aici
trei tipuri diferite de adaptare. Adaptarea Reactiv se refer la modificrile care vin ca i
reacie n urma unor schimbri() care s-au produs deja; adaptarea pro-activ are ca scop
modificarea SBS nainte sa apar o deviaie; adaptarea post-mortem este realizat in mod
specific prin reproiectarea aplicaiei, dup ce evenimentul de declanare a avut loc i a dus
la oprirea ei.
o Distribuia adaptrii se distinge intre adaptarea centralizata, unde aciunile
adaptrii sunt definite si executate pentru toate componentele afectate ntr-un mod integrat
si adaptarea distribuit efectuat local si apoi propagat ctre celelalte componente.
o Direcia adaptrii determin dac adaptarea va fi direcionat nainte, atunci
cnd sistemul este direcionat ctre o nou stare sau napoi dac sistemul revine la starea
stabil anterioar.
Specificaia Adaptrii definete notaiile necesare pentru a specifica strategiile de
adaptare si aciunile implicate.
Specificaia adaptrii poate fi procedural (aciuni concrete de executat), declarativ (anumite
scopuri de atins) sau hibrid. Notaia poate fi implicit sau explicit.
Adnotarea implicit reprezint faptul c strategiile de adaptare sunt codate foarte puternic in
sistem si nu pot fi schimbate fr modificarea mecanismelor de adaptare. Specificaiile Adaptrii
Explicite permit proiectantului s caracterizeze explicit cerinele sau instruciunile adaptrii.
Adaptarea explicit poate avea mai multe forme:
o Specificaie pe baz de aciune care const n reguli n funcie de situaie care
specific ce aciuni vor fi executate in anumite circumstane.
o Specificaie bazat pe scop care stabilete obiectivele de performan, lsnd
sistemul s determine ce aciuni sunt necesare pentru a atinge aceste obiective.
o Specificaie pe baza de funcii utilitare care exploateaz funciile de utilitate
pentru a califica si cuantifica diferitele alternative de adaptare si decide care este cea mai
bun alternativ
o Abordarea Variabil Explicit definete mai multe puncte unde adaptarea ar
trebui s aib loc, i un set de variante (alternative) pentru fiecare dintre aceste puncte,
variante care definesc diferitele implementri posibile ale prii corespunztoare
aplicaiei.
Aciunea adaptrii este o aciune executat cu scopul de a modifica starea sistemului
pentru a ndeplini cerinele de adaptare. Adaptarea poate fi static, atunci cnd strategia de
69
adaptare este predefinit n momentul designului aplicaiei, sau dinamic, atunci cnd strategia
este selectat n timpul execuiei. De asemenea adaptarea poate avea un grad diferit de
automatizare n funcie de gradul diferit de implicare al factorului uman n procesul de decizie.
1.3.4.2. Abordri privind adaptabilitatea aplicaiilor orientate ctre

servicii
n aceast seciune va fi prezentat un studiu asupra stadiului actual privind abordrile adaptive n
ceea ce privete aplicaiile bazate pe servicii. Vor fi prezentate iniial abordrile adaptive la
nivel de procese de afaceri, urmate de abordrile la nivel de compunere de servicii.
Adaptabilitatea la nivel de management al proceselor de afaceri
Adaptabilitatea la nivel de proces de afaceri poate presupune modificarea permanent a

ntregului model sau a unei singure instane. n primul caz se poate vorbi despre o evoluie,
ntruct noile instane vor urmri noul model. Acest tip de adaptare este obinut prin reproiectarea
proceselor de afaceri.
Adaptabilitatea fluxurilor de lucru(workflows) se refer la modificarea la rulare i/sau extensia
instanelor proceselor ce ruleaz pentru a reaciona la diferite probleme i pentru a lua n
considerare diferite schimbri ce au rol n mediul lor. Aceste schimbri pot fi determinate de
dinamica modelelor organizaionale, viitoare servicii sau noi reguli i reglementri. Modificrile
la rulare ale instanelor proceselor presupun de obicei o anumit strategie predefinit n momentul
proiectrii i care au ca scop modificarea fluxului de control i al fluxului de date al instanei
procesului.
Adaptabilitatea proceselor de afaceri prin variante de proces
Numeroase abordri privind Adaptabilitatea proceselor de afaceri iau n calcul problema definirii
i utilizrii dinamice a diferitor variante de proces. Necesitatea folosirii mai multor versiuni ale
modelelor de procese este determinat de numeroasele situaii, contexte de afaceri i a clienilor.
Managementul numeroaselor variante devine o procedur complex i pasibil de erori atunci
cnd complexitatea modelelor i numrul de variante de procese crete.
n PROPOV(PROcess Variants by OPtions) [104] este proiectat un proces de baz iar variantele
acestuia sunt reprezentate ca un set de operaii care permit migrarea modelului de baz ntr-o
variant specific. Transformrile sunt reprezentate prin operaii de inserare, tergere sau mutare
a unui fragment de proces, precum i prin operaii de modificare a atributelor procesului.
Utilizarea unei operaii presupune ndeplinirea anumitor constrngeri: dependene, excludere
mutual, constrngeri privind ordinea execuiei i ierarhia. Variabile de context i reguli care
definesc relaia dintre ele sunt utilizate pentru asocierea unei variante de proces cu un anumit
context. La rulare sunt selectate variantele de proces corespunztoare pe baza informaiei
contextuale i a opiunilor selectate.
n [105], [107] sunt abordate problemele legate de transformarea dinamic a unui proces ctre
altul. Aceasta necesit definirea instruciunilor i a aciunilor de transformare a procesului.
70
Aceste transformri ar trebui aplicate instanelor de proces care ruleaz ducnd astfel la probleme
i situaii neprevzute. Pe lng modelarea variantelor de proces, cele dou lucrri definesc
notaii i formalisme pentru descrierea i implementarea aciunilor de transformare. Aceste
aciuni definesc instruciuni pentru modificarea fluxului de control i a fluxului de date. n [106]
lista posibilelor aciuni cuprinde adugarea/tergerea de variabile, inserarea de taskuri,
adugarea/eliminarea succesorului unui task, schimbarea condiiilor unei tranziii. n [107]
aciunile includ de asemenea schimbri n ordinea operaiilor, tergerea taskurilor, etc. Lucrrile
n cauz propun de asemenea soluii pentru transformarea dinamic a instanelor proceselor.
Corectitudinea semantic a adaptrii proceselor
Transformarea dinamic a modelelor proceselor ntreprinderilor este adresat n [108]. Aceast

abordare propune un cadru formal pentru reprezentarea modelelor dinamice i a schimbrilor din
ele. Similar cu abordarea din [105], autorii definesc formal un limbaj i semantica pentru
schimbrile modelului procesului de afaceri. Constrngeri semantice sunt introduse sub forma
unor dependene i excluderi mutuale pentru schimbrile aplicabile. Este propus un cadru pentru
verificarea automat a schimbrilor n cadrul procesului innd cont de constrngeri.
Recuperarea n sisteme bazate pe fluxuri de lucru

Aciunile de recuperare concentrate pe adaptar corective au fost utilizate la scar larg n
sistemele bazate pe fluxuri de lucru. Modelele de fluxuri de lucru prezentate n [109], [110],
[111] ofer diferite capabiliti pentru aciuni de recuperare. Abordarea prezentat n [112] se
concentreaz asupra integrrii managementului excepiilor n sisteme de management al
fluxurilor de lucru. n [113] autorii propun utilizarea unui set de politici de recuperare pentru
taskuri i regiuni ale unui flux de lucru. Ei folosesc o abordare bazat pe reele Petri pentru a
schimba comportamentul normal atunci cnd o situaie ateptat, dar neobinuit, sau o eroare
apar.
Adaptabilitatea n Arhitecturi Orientate ctre Servicii
Abordrile adaptive n cadrul aplicaiilor bazate pe servicii variaz de la funcionalitile de auto-

vindecare pentru recuperarea din erorile aplicaiilor datorate n principal degradrii calitii, pn
la personalizarea aplicaiei n funcie de nevoile utilizatorului, context, sau un scenariu de
utilizare al serviciilor. Datorit acestei diversiti, soluiile propuse difer substanial din punct de
vedere al complexitii. Vom face o clasificare a adaptrilor pornind de la forme simple de
adaptare unde substituia serviciilor este singura form de adaptare ctre adaptri mai sofisticate.
a) Adaptarea prin legarea dinamic a serviciului
METEOR-S [114], [115], [116] este un cadru pentru configurarea dinamic a serviciilor i
execuia fluxurilor de lucru abstracte folosind o mulime de servicii disponibile. Este folosit un
set de constrngeri funcionale i non-funcionale pentru procesele i serviciile implicate.
Modelele abstracte pentru fluxurile de lucru sunt definite de proiectant folosind BPEL. Modelul
de proces conine specificaii semantice n OWL care descriu caracteristicile funcionale i non-
funcionale ale modelului. Constrngerile non-funcionale se refer la proprietile ce descriu
71
calitatea serviciilor, aspecte privind securitatea i sunt transformate n constrngeri privind

programarea liniar. Constrngerile funcionale se refer la compatibilitatea datelor i controlul
fluxului de lucru, fiind reprezentate folosind limbajul Semantic Web Resource Language
(SWRL) [115]. Dac apare o eroare n timpul deployment-ului aplicaiei sau la rulare i este
necesar reconfigurarea serviciilor, platforma realizeaz descoperirea serviciilor pe baza
abloanelor definite i a descrierii semantice a serviciilor i analiza cantitativ a proprietilor
non-funcionale folosind programarea liniar precum i proprietilor calitative ale serviciilor.
Abordarea prezentat n [117] intete problema meninerii compunerilor dinamice de servicii,
atunci cnd serviciile componente eueaz sau genereaz erori. Compunerea de servicii este
proiectat ca un proces BPEL. Criteriul de selectare al serviciului potrivit este determinat de
reputaia serviciului. Abordarea este pro-activ n sensul c procesele ofer informaii despre
reputaia serviciilor n urma folosirii lor. Abordarea permite mbuntirea calitii seleciei.
Cadrul SCENE [118] ofer un limbaj de compunere a serviciilor ce extinde standardul BPEL cu
reguli ce permit legarea dinamic a serviciilor i auto-configurarea operaiilor. Cadrul SCENE
este compus dintr-un motor de execuie BPEL, un motor de reguli open source, WS-Binder [119]
responsabil cu legarea dinamic a serviciilor, precum i o component responsabil cu negocierea
SLA cu serviciile componente. Cadrul SCENE a fost extins prin integrarea unui modul ce
permite rezolvarea problemelor ce rezult din nepotrivirea interfeelor i a protocoalelor
serviciilor invocate [120].
n cadrul PAWS [121] se pornete de la definiia unui proces abstract, n momentul proiectrii
realizndu-se o selecie a serviciilor candidate folosind un registru semantic, ce definete
informaiile de mapare ce vor fi folosite la rulare i modalitatea de negociere a nivelelor de
calitate pentru potenialele servicii. La rulare, serviciile sunt selectate pe baza unor constrngeri
privind parametrii de calitate, iar serviciile sunt invocate de ctre un motor de mediere.
Activitile la rulare sunt gestionate de trei module: un modul ce efectueaz optimizri asupra
procesului, un motor de auto-vindecare i un motor de mediere. Modul ce efectueaz optimizri
asupra procesului are ca scop principal asigurarea unui nivel al calitii att global ct i local
conform cu cerinele utilizatorului. Modulul de auto-vindecare permite adaptarea, efectund
aciuni semi-automate ca reacie a eecurilor. Dac este necesar substituirea unui serviciu, un
nou serviciu este selectat dintre candidaii disponibili. Motorul de mediere redirecteaz invocrile
procesului instalat ctre serviciile selectate.
n [122] serviciile care nu ndeplinesc anumite cerine i constrngeri sunt substituite dinamic la
rulare. Aplicaia compozit este monitorizat la rulare, iar n cazul identificrii unor violri ale
cerinelor, platforma extrage automat constrngerile pentru serviciile candidate din informaiile
de diagnostic primite de la modulul de monitorizare i efectueaz aciuni de descoperire i
selectare a serviciilor pe baza constrngerilor.
b) Adaptarea pe baza parametrilor de calitate
n cazul proceselor bazate pe servicii web, calitatea general a procesului depinde de calitatea
oferit de serviciile componente. Chiar dac procesul funcioneaz corect, este necesar
adaptarea datorit unui nivel insuficient al calitii. Sistemul bazat pe servicii trebuie s
reacioneze pentru mbuntirea calitii proceselor. Scopul este de a selecta mulimea de servicii
disponibile la rulare ce corespunde constrngerilor dar i preferinelor utilizatorului. Selectarea
serviciilor i legarea lor reprezint un mecanism cheie pentru adaptare n cadrul acestor abordri.
72
Selectarea serviciilor devine o problem de optimizare. Exist dou tipuri de abordri n

literatur. n cazul primului tip, soluiile implementeaz abordri locale, ce selecteaz un serviciu
web la un moment dat dintr-o mulime de servicii candidate. Serviciile sunt selectate pe baza
unor caracteristici stabilite. Al doilea tip de abordri presupune identificarea setului de servicii ce
satisfac constrngerile de proces i preferinele utilizatorului naintea momentului execuiei
procesului. n acest fel pot fi introduse constrngeri de calitate la nivel global asupra ntregii
compoziii de servicii. Principala problem n acest cazul ndeplinirii constrngerilor globale este
performana serviciilor care variaz. Dac un proces are o durat lung de execuie, serviciile
identificate de optimizare pot s-i schimbe proprietile calitative n timpul execuiei procesului,
unele servicii devenind chiar indisponibile. Pentru asigurarea calitii globale, optimizarea are loc
att la crearea instanei de proces ct i la rulare.
Cadrul WSCE [123] realizeaz compunerea i legarea serviciilor ntr-un mod care satisface
cerinele date dar i monitorizeaz execuia i mediul de execuie pentru a modifica ntr-un mod
dinamic compoziia atunci cnd au loc schimbri critice. Autorii propun o abordare n dou etape.
ntr-o prim faz este definit ablonul de compunere al serviciilor, bazat pe specificaiile
funcionale ale utilizatorului, urmnd ca n a doua etap s aib loc instanierea compoziiei
abstracte pe baza parametrilor de calitate.
n [124] autorii propun o abordare implicit pentru compunerea dinamic a serviciilor bazat pe
optimizarea multi-dimensional a parametrilor de calitate ai serviciilor. Procesul este proiectat ca
un flux de lucru ce compune taskuri elementare. La rulare, un serviciu concret este selectat pentru
efectuarea unui anumit task dintr-un set de servicii ce ofer funcionaliti similare, dar au diferite
valori pentru parametrii de calitate. Descrierea serviciilor nu include doar aspecte funcionale, ci
i proprieti non-funcionale ce sunt folosite pentru selectarea serviciilor. O serie de proprieti
calitative sunt identificate, cum ar fi: pre, durat, reputaie, iar funcii de agregare sunt definite
pentru fiecare dintre ele.
Abordarea prezentat n [125] se concentreaz asupra dezvoltrii metodelor pentru oferirea celei
mai nalte caliti posibile. Autorii folosesc extensii ale standardului WSDL pentru a exprima
proprietile calitative ale sistemului. Informaia adunat despre parametrii de calitate ai
sistemului este folosit pentru a compara diferite configuraii candidat, folosind algoritmi genetici
pentru gsirea soluiei optime.
Un alt exemplu de management al configuraiei SOA la rulare poate fi gsit n [126]. Abordarea
este bazat pe reprezentarea configuraiei serviciului printr-un model, i apoi prin modificarea
acestui model pentru adaptarea configuraiei la schimbrile din mediu i la cerinele utilizatorilor.
Sistemul este descris prin intermediul reelelor Petri, ce reprezint dependenele ntre servicii n
cadrul configuraiei. Reeaua Petri reprezint locurile unde sunt mapate serviciile, iar arcele n
modelul grafului reprezint dependena dintre locuri. Modelul poate evolua, conform
schimbrilor din domeniu. Autorii descriu un algoritm ce modific configuraia (i modelul ei)
cu scopul de a oferi cel mai nalt nivel calitativ. Numeroi parametri calitativi sunt folosii pentru
evaluarea calitii serviciilor, numeroase metrici fiind considerate pentru msurarea fiecrui
parametru. Nivelul calitii unui serviciu este definit n funcie de loc i timp, iar algoritmul
descris caut cea mai bun configuraie.
c) Adaptarea interfeelor serviciilor i a protocoalelor
73
n acest caz vorbim de mediere, o funcionalitate important ce ar trebui oferit pentru a permite
integrarea de-a lungul ntreprinderii. Trebuie generat un serviciu ce permite medierea
interaciunilor dintre dou servicii cu interfee diferite. Exist dou surse ce genereaz acest tip de
adaptare: eterogenitatea dintre nivelele superioare ale stivei de interoperabilitate precum i
numrul mare de clieni, fiecare dintre ei fiind capabil s suporte diferite interfee i protocoale.
Aceast mediere poate fi automat sau semi-automat. Adaptarea poate fi bazat pe semntur
(proprietile sintactice ale mesajelor schimbate), bazat pe ontologie (datele schimbate
reprezint diferite concepte), sau adaptarea bazat pe comportament (diferene n specificaiile
comportamentale).
Generarea de adaptri pentru nepotrivirile comportamentale este adresat n [127], [128], [129].
Abordarea necesit ca descrierile serviciilor participante s conin i numele protocolului de
interaciune implementat de serviciu. Acest protocol poate fi definit, de exemplu, ca un proces
BPEL abstract. Abordarea prezentat n [127] i propune generarea automat a unui adaptor
care garanteaz interaciunile non-blocante ale serviciilor, abordrile [128], [129] transfer
aceast problem integratorului de sistem. n [128] autorii propun o taxonomie pentru diferitele
neconcordane comportamentale i un set de modele comportamentale parametrizabile pentru
rezolvarea neconcordanelor. Modelul comportamental este pus n aplicare atunci cnd
neconcordana este detectat i propune o posibil strategie de adaptare integratorului de
aplicaie.
n [130] este abordat problema medierii prin propunerea unui cadru care s alinieze
implementarea intern a serviciilor cu o specificaie extern standardizat. Cadrul const ntr-o
taxonomie a diferitelor tipuri de nepotriviri dintre specificaiile externe i implementarea
serviciilor. Autorii consider c nepotriviri similare pot fi adresate folosind modificri similare
ale implementrii serviciilor. De aceea, pentru o nepotrivire, este folosit un ablon care descrie
abordarea adaptiv. Un ablon conine o serie de directive care specific locul unde va fi aplicat
logica adaptrii, i care sunt aciunile ce trebuie aplicate. Abordarea se bazeaz pe faptul c
serviciile sunt realizate ca procese BPEL, la fel ca i abloanele. Un instrument pentru
instanierea i execuia abloanelor este de asemenea prezentat de autori.
n [131] este prezentat un cadru bazat pe un protocol de mediere a serviciilor web semantice care
permite interaciunea ntre dou servicii n ciuda diferenelor de protocoale pe care se bazeaz
acestea. Medierea permite adaptarea automat a serviciului ce realizeaz invocarea pentru a fi
compatibil cu interfaa serviciului invocat.
d) Limbaje explicite de specificare a adaptrilor
n SH-BPEL [132] este abordat problema oferirii capabilitilor de auto-vindecare n compuneri

de servicii folosind standardul BPEL. Autorii urmresc extinderea capabilitilor de recuperare
n caz de recuperare n caz de eroare ale standardului BPEL cu strategii de recuperare la nivel de
servicii (retry sau rebind), modificarea valorilor variabilelor de proces, reproiectarea unui task din
cadrul unui proces, specificarea i execuia unor ci alternative dintr-un proces, ntoarcerea ntr-
un punct sigur n cadrul execuiei unui proces. SH-BPEL integreaz i suport facilitile de
recuperare necesare. Specificaia iniial a procesului este pre-procesat i extins cu
instruciunile adiionale i puncte de control, ce permit efectuarea aciunilor descrise mai sus.
Aceste aciuni pot fi invocate prin intermediul unui API (Application Programming Interface)
74
care devine utilizabil n momentul instalrii i activrii procesului. Arhitectura care st la baza
SH-BPEL ofer instrumente pentru detectarea evenimentelor critice precum i aciuni de
recuperare ce pot fi invocate prin intermediul API-ului. Strategiile i deciziile pot fi predefinite n
cadrul managerului de proces i personalizate prin intermediul interfeei. O mulime de motoare
care ruleaz serviciile participante n coreografie pot efectua activiti de recuperare coordonate
prin intermediul unor interfee corespunztoare. Platforma permite recuperarea la nivel de
instan de proces precum i la nivel de model de proces. Cadrul SH-BPEL este extins n [133] cu
o metodologie i un modul ce permite nvarea strategiilor de reparare a serviciilor web prin
selectarea automat a aciunilor de reparare propuse. Modulul poate nva incremental tehnici de
reparare, pe msur ce erorile sunt reparate.
n [134], [135] autorii folosesc monitorizarea execuiei pentru detectarea n timp util a situaiilor
problematice. Instruciunile de monitorizare sunt definite ca aseriuni funcionale sau non-
funcionale n cadrul activitilor BPEL. Sunt propuse trei strategii pentru recuperare: retry,
rebind, sau restructurare. Instruciunile corespunztoare pentru aciunile n caz de retry i rebind
sunt introduse direct n specificaia de compoziie, n timp ce instruciunile de restructurare sunt
definite ca reguli de rescriere a fluxului de control al procesului. n [135] abordarea propus este
extins. Monitorizarea este fcut folosind o notaie specific: Web Service Constraint Language
(WSCoL), ce ofer faciliti expresive i extensibile pentru monitorizarea aseriunilor. Web
Service Recovery Language (WSReL) este propus pentru definirea specificaiilor de recuperare.
Limbajul introduce aciuni atomice de recuperare care pot fi grupate n proceduri complexe(pai).
Aciunile pot fi definite la nivel de serviciu (retry, rebind, ignore) sau la nivel de proces
(substituie, oprire) precum i aciuni de gestionare (notificare, log). Platforma se bazeaz pe un
motor de reguli ce gestioneaz specificaiile de recuperare i activeaz recuperarea.
n [136] autorii prezint MASC, un middleware bazat pe anumite politici pentru a efectua
autoadaptri n caz de excepie sau eroare n cadrul unei arhitecturi SOA. Politicile sunt definite
sub forma de reguli ECA (Eveniment - Condiie - Aciune) care descriu evenimente
declanatoare (erori ale aplicaiei, nceputul/sfritul unei instane de aplicaie, etc.) condiii n
care se aplic regulile (restricii ce se aplic asupra aplicaiei) i aciunile ce trebuie aplicate.
Politicile sunt reprezentate ntr-un limbaj care extinde standardul WS-Policy [137]. Limbajul
permite definirea de reguli i directive pentru adaptare i monitorizare. Regulile de monitorizare
definesc informaiile ce trebuie observate i transform situaiile nedorite n evenimente de eroare
ce vor fi procesate de regulile de adaptare. Abordarea permite specificarea a dou tipuri de
aciuni de adaptare: aciuni la nivel de proces i aciuni la nivel de mesaj. Aciuni posibile la nivel
de proces sunt: adugarea, tergerea, nlocuirea, schimbarea ordinii activitilor, suspendarea,
ntrzierea. Aciuni posibile la nivel de mesaj sunt: ncercarea de a invoca din nou un serviciu,
substituirea unui serviciu, invocarea concurent a mai multor servicii. Regulile de adaptare pot
avea asignate prioriti care s defineasc ordinea de execuie atunci cnd mai multe reguli se
aplic unui eveniment.
n WS-Diamond [138] autorii se focalizeaz pe diagnoza problemelor n compunerile de servicii,
ct i pe aciuni de recuperare pentru aceste probleme. Mediile de execuie pentru servicii sunt
extinse pentru a include caracteristici care s suporte procese de recuperare i diagnoz. Strategii
de reparare i mecanisme de implementare au fost studiate de-a lungul proiectului. Ele includ
aciuni la nivel de instan i de clas.
n [139] autorii propun o abordare care definete un cadru de modelare bazat pe politici simple i
o arhitectur pentru proiectarea i implementarea serviciilor n cadrul aplicaiilor mobile
75
dependente de context. Contextul est reprezentat folosind Resource Description Framework

(RDF) i se refer la proprietile unui dispozitiv, servicii i caracteristicile lor, preferinele
utilizatorilor, etc. Pornind de la cunotinele contextuale iniial colectate, proiectantul specific
politicile de adaptare i extrage noi informaii contextuale.
n [140] este utilizat o abordare bazat pe modele, care sunt utilizate n momentul proiectrii i
pot fi utilizate pentru a efectua o adaptare automat n momentul rulrii aplicaiei. Pe lng
model, o configuraie iniial a serviciilor sistemului este construit. Modelul este orientat obiect
i cuprinde politici de nivel nalt care descriu comportamentul dorit al sistemului.
e) Adaptarea prin modelarea explicit a variabilitii
Acest tip de abordare permite definirea schimbrilor relevante la nivel de aplicaie i a felului n
care sistemul ar trebui s reacioneze la ele la un moment dat. Este utilizat specificaia
comportamental a aplicaiei pentru a defini explicit locaia variaiei. Pentru punctul de variaie
sunt definite o serie de alternative ce pot fi aplicate n funcie de anumite condiii i
particulariti.
Abordarea DySOA [141] pune problema reconfigurrii aplicaiei pentru a reaciona la schimbrile
critice n ceea ce privete parametrii de calitate a serviciilor. Aciunile adaptive corespund
selectrii i legrii unui nou serviciu sau unor schimbri n specificaia structurii de compoziie.
Abordarea se bazeaz pe modelarea explicit a diferitor variante corespunztoare punctelor de
variaie i pe definirea diferitor constrngeri care determin selectarea unei anumite variante.
Variantele pot fi fragmente de proces sau servicii componente i definesc variante funcionale sau
comportamentale. n cadrul DySOA, parametrii de calitate ai serviciilor sunt constant
monitorizai. Cnd anumite violri sunt identificate, posibilele variante sunt analizate i selectate
n punctele corespunztoare , astfel nct toate constrngerile s fie ndeplinite i optimizarea
parametrilor de calitate s fie realizat.
n [142] autorii modeleaz variabilitatea unui SBS la diferite nivele. La nivel de proces este
folosit BPMN pentru modelarea proceselor. Autorii denumesc Workflow Variability
flexibilitatea necesar la nivel de secven de activiti. Nivelul de servicii cuprinde definiia
serviciilor din perspectiva arhitectului. Compunerea dinamic a serviciilor este numit
Composition Variability i este modelat folosind BPEL. La nivel de interfa de servicii sunt
definite interfeele serviciilor folosind WSDL.
n [143] autorii afirm c pentru a aborda schimbrile n cadrul SBS sunt necesare urmtoarele
informaii: cunotine despre raionamentele care stau n spatele deciziilor, nelegerea
alternativelor, trasabilitate privind scopul prilor implicate i a elementele de realizare tehnic.
Ei susin c sistemele foarte flexibile i adaptabile nu pot fi specificate n avans i de aceea
consider c metodele de proiectare i tehnicile de modelare sunt necesare pentru a descrie
sistemele flexibile i evolutive ntr-un mod declarativ. Abordarea i orienteaz atenia ctre dou
tipuri de schimbri: (1) schimbri de tip top-down determinate de prile implicate. Noi
specificaii afecteaz serviciile existente i arhitecturile de servicii. De asemenea, negocierile cu
furnizori de servicii teri pot duce la noi acorduri privind nivelul calitii serviciilor (SLA) i de
asemenea la reconfigurarea arhitecturii de servicii; (2) schimbri de tipul bottom-up.
Rezultatele monitorizrii determin schimbri n configuraia curent pentru a respecta nivelul
agreat al calitii serviciilor. Pentru cele dou tipuri de schimbare sunt luate n considerare
urmtoarele: scopurile comune i specifice ale diferitelor pri implicate, cunotinele despre
76
configuraia curent, informaii despre configuraii alternative de servicii, trasabilitatea

informaiilor, reprezentri ale sistemului la diferite nivele pentru a nelege nevoile prilor
implicate raportate la configuraiile de sistem curente sau alternative. Abordarea prezint felul n
care poate fi descris un model de variabilitate pe baza modelului de scopuri i cum poate fi acest
model folosit pentru monitorizarea i adaptabilitatea aplicaiilor bazate pe servicii.
1.4. CONCLUZII
n acest capitol am prezentat universul de discurs (1.1) i am identificat trsturile eseniale

pentru paradigma FInEs, am identificat cerine/atribute/proprieti pentru categoria de sisteme
FInES prezentnd spaiul cunoaterii FInES i direcia de cercetare Horizon 2020(1.2). Am
prezentat categoria de sisteme Collaborative Networked Systems/Organization prin detalierea
conceptelor importante pentru teza curent: CNO, VO i VBE (1.3). Am prezentat modelele de
compunere a serviciilor precum i stadiul actual privind compunerea de servicii i adaptabilitatea
aplicaiilor orientate ctre servicii(1.4). Contextul actual al compunerii de servicii web este
dominat de abordri flexibile reactive care nu au ca obiectiv prentmpinarea unor probleme, n
schimb proiecteaz soluii pe baza situaiei prezente fr a privi in viitor. Am observat c
impactul efecturii schimbrilor n cadrul proceselor bazate pe servicii web nu este intensiv
studiat, rmnnd o problem deschis.
77
CAPITOLUL 2
CERINE I SPECIFICAII LA NIVEL CONCEPTUAL PENTRU

ELABORAREA UNEI METODOLOGII DE INTEGRARE A
ORGANIZAIILOR DE NTREPRINDERE, INTEGRATE PRIN
COMUNICAII ORIENTATE PE TEHNOLOGII DEFINITE DE
PLATFORMA PLATFORM AS A SERVICE / FI-WARE
2.1. CONCEPTE FUNDAMENTALE
Enterprise Integration and Interoperability Networking (E2IN) ncurajeaz cercetarea n

domeniile urmtoare: interoperabilitatea i integrarea reelelor de ntreprinderi, arhitecturi de
referin pentru reele de ntreprinderi, metodologii de proiectare a ntreprinderilor, precum i
modelarea ntreprinderilor[144]. Obiectivele EI2N sunt de a identifica tehnici corecte din punct
de vedere teoretic i viabile din punct de vedere practic pentru colaborarea ntre ntreprinderi
bazat pe infrastructura oferit de internet, limbajele de modelare ale ntreprinderii i tehnologiile
internet care s susin ntreprinderea digital durabil (Digital Sustainable Enterprise).
n particular E2IN se concentreaz asupra:
principiilor, modelelor, protocoalelor i tehnologiilor ICT privind reelele colaborative de

ntreprinderi.
Internetul Obiectelor pentru ntreprinderea digital durabil
ntreprinderea vie (Sensing Enterprise)
Sisteme CPS
teorii, modele i instrumente pentru verificarea i validarea de modele de ntreprinderi
tehnologii i metodologii pentru documentarea i stocarea modelelor de ntreprinderi
pentru a permite reutilizarea lor
Integrarea la nivel de ntreprindere este un domeniu de cercetare ce s-a dezvoltat ncepnd cu anii
1990 ca o extensie a CIM (Computer Integrated Manufacturing). Integrarea la nivel de
ntreprindere n contextul modelrii ntreprinderii se refer la concepte i abordri cum ar fi:
definiia arhitecturii globale a sistemului, consistena procesului de luare a deciziilor, noiunea de
proces ce modeleaz fluxul de activiti, alocarea dinamic a resurselor i consistena
datelor[145]. Integrarea la nivel de ntreprindere poate fi vzut pe mai multe niveluri. Comitetul
CEN TC310/WG1 recunoate trei niveluri de integrare[146]: fizic, aplicaie i business.
Integrarea poate fi obinut n termeni de: (1) date (modelarea datelor); (2) organizaie
(modelarea sistemelor i a proceselor); (3) comunicaie.
78
ncepnd cu sfritul anilor 1990, abordrile privind integrarea la nivel de ntreprindere au

nceput s pun accentul pe interoperabilitatea la nivel de ntreprindere. Interoperabilitatea la
nivel de ntreprindere este considerat mai adaptabil(presupune un cost mai mic i o
implementare mai rapid) n cadrul sistemelor decentralizate, flexibile n care comunicaia se face
prin intermediul unei reele de calculatoare. Se consider c integrarea merge dincolo de
interoperabilitate pentru c implic un grad de dependen funcional. Dac sistemele
interoperabile au capacitatea de a funciona independent, un sistem integrat pierde din
funcionalitate dac fluxul de servicii este ntrerupt[146 ].
n seciunea urmtoare vor fi prezentate nivelurile de interoperabilitate. Pentru o nelegere mai

bun a integrrii i interoperabilitii la nivel de ntreprindere i felul n care aceste dou
paradigme au evoluat, n seciunea 2.3 este prezentat evoluia sistemelor informaionale de la
Enterprise Aplication Integration( EAI) la sistemele informaionale evoluate FInES. n secinea
2.4 este prezentat problema pe care aceast lucrare ncearc s o rezolve, urmat n seciunea 2.5
de suportul formal pentru rezolvarea problemei.
2.2. NIVELURI DE INTEROPERABILITATE
Exist numeroase definiii pentru interoperabilitate, printre care amintim:
Abilitatea a dou sau mai multe sisteme sau componente s schimbe informaii i s
foloseasc informaiile care au fost schimbate [147]
Abilitatea de a aciona n sinergie n vederea executrii activitilor asignate [148]
O proprietate ce se refer la abilitatea a diverse sisteme sau organizaii de a conlucra.

[149]
Ca i arie de cercetare, interoperabilitatea la nivel de ntreprindere analizeaz problemele legate

de lipsa interoperabilitii n organizaii i propune metode noi si cadre de modelare care s
contribuie cu soluii inovative i s adreseze situaii n care informaia schimbat nu este neleas
sau utilizat corect. Interoperabilitatea la nivel de ntreprindere poate fi aplicat att nevoilor inter
ct i intra-ntreprindere[150].
Proiectele de cercetare privind interoperabilitatea la nivel de ntreprindere INTEROP NoE [151]

i Athena IP [152] au nceput s construiasc o viziune holistic a acesteia, adresnd
interoperabilitatea de-a lungul a patru niveluri:
Nivelul business: reprezint nivelul superior al ntreprinderii unde sunt adresate toate
problemele legate de managementul operaiilor. Aceste probleme includ felul n care
ntreprinderea este organizat, cum acioneaz pentru a produce valoare, cum sunt luate
deciziile. Interoperabilitatea la acest nivel ar trebui vzut ca i abilitatea organizaiei de a
coopera cu organizaii externe, fie ele instituii publice sau private
79
Nivelul proceselor i al cunoaterii: acest nivel presupune dobndirea unor cunotine

vaste asupra ntreprinderii. Interoperabilitatea la acest nivel ar trebui vzut ca
compatibilitatea abilitilor, competenelor, i a cunotinelor unei ntreprinderi cu cele ale
unei organizaii externe
Nivelul serviciilor i aplicaiilor: acest nivel presupune toate soluiile ICT care permit
organizaiei s fie operativ: metode, instrumente i servicii pentru luarea deciziilor i s
interacioneze cu alte organizaii. Interoperabilitatea la nivel de servicii se refer la
abilitatea partenerilor de a cere, oferi i utiliza reciproc serviciile. Acest nivel este deseori
referit ca interoperabilitate tehnic.
Nivelul datelor: acest nivel reprezint nivelul la care are loc schimbul de date.
Interoperabilitatea semantic are o dimensiune vertical ce se ntinde de-a lungul celor patru
niveluri i are ca scop captarea i reprezentarea semnificaiei conceptelor i promovarea
nelegerii.
Interoperabilitatea poate fi privit din perspectiva eficienei[153]. Eficiena n acest context se

refer la gradul de intervenie uman n comunicarea ntre dou sisteme pentru ( cu ct timpul
necesar pentru intervenia uman n ncercarea de a face dou sisteme s comunice informaii este
mai mic, cu att nivelul eficienei este mai ridicat). Nivelurile de eficien a interoperabilitii
sunt:
Interoperabilitate slab: informaia schimbat este reprezentat de text interpretabil de

utilizatorul uman dar inacceptabil pentru e-Business.
Interoperabilitatea neregulat: ntreprinderile se concentreaz n mod tradiional asupra

relaiilor de tip punct la punct, fr a lua n considerare nevoia global de colaborare a
reelei de ntreprinderi. ntreprinderile folosesc formate de date proprietare i propriile
reguli de afaceri, utiliznd un numr de morfisme egal cu numrul de parteneri pentru
transformarea datelor dintr-un format n altul.
Interoperabilitatea bazat pe standarde: n acest caz se folosesc modele de referin,

standardizarea devenind o prioritate evident. n cazul folosirii standardelor sau
modelelor de referin, ntreprinderile utilizeaz un singur morfism ce descrie maprile
din modelul intern la cel de referin.
Interoperabilitatea semantic: are ca scop asigurarea c datele transmise prin mesaje ntre
dou sisteme au aceeai semnificaie n ambele sisteme.
Interoperabilitatea sustenabil: niciunul din precedentele niveluri nu ia n considerare

problema restabilirii interoperabilitii ntre dou sisteme, n cazul n care aceasta a fost
iniial stabilit dar ulterior ntrerupt. Interoperabilitatea sustenabil se refer la
interoperabilitatea care satisface nevoile prezentului fr a compromite capacitatea de a
menine interoperabilitatea i n viitor prin adaptri adecvate.
80
2.3. EVOLUIA SISTEMELOR INFORMAIONALE DE LA CONCEPTUL DE

INTEGRAREA APLICAIILOR LA NIVEL DE NTREPRINDERE LA SISTEM DE
SISTEME INFORMAIONALE, COMPLEXE, ADAPTIVE, DISPERSATE GEOGRAFIC
INTEGRATE PRIN TEHNOLOGII FUTURE INTERNET ENABLING TECHNOLOGIES:
INTERNETUL OBIECTELOR, INTERNETUL SERVICIILOR, INTERNETUL
CUNOATERII, INTERNETUL SOCIALIZRII
2.3.1 Definiii
2.3.1.1 Arhitecturi ale ntreprinderii
O arhitectur este o descriere a dispunerii de baz i a conectivitii prilor unui sistem (fie
obiect fizic sau obiect sau entitate conceptual) [154]. Arhitectura poate avea mai multe sensuri,
n funcie de contextul in care este utilizat [154]: (1) o descriere formal a unui sistem la nivel
de componente pentru a ghida implementarea sa, (2) structura componentelor, interdependenele
lor i principiile i orientrile care le guverneaz proiectarea i evoluia n timp; (3) structura
organizatoric a unui sistem sau a unor componente.
Arhitectura ntreprinderii (EA Enterprise Architecture) definete componentele care alctuiesc
sistemul i ofer o schem/plan dup care sistemul poate fi dezvoltat. Pe baza ei ar trebui s fie
suportat raionamentul cu privire la structura, proprietile i comportamentul ei. De asemenea,
arhitectura permite gestionarea riscului si a complexitii a cror cauz sunt diveri factori, cum
ar fi tehnologia, dimensiunea, interfaa, contextul i prile interesate. Proiectarea la scar larg a
unor sisteme precum ntreprinderile ncepe de la un nivel de abstractizare nalt, pentru a asigura
coerena la nivel global, i continund apoi cu organizarea i s reprezentarea sistemelor
ntreprinderii la nivel de sub-sisteme i la nivel modular.
Un concept adiacent celui de EA este modelarea ntreprinderii (EM - Enterprise Modeling). EM
descrie n detaliu EA din diferite puncte de vedere, pentru a permite specificarea i punerea n
aplicare a sistemului. EA nu este o entitate executiv. Cu alte cuvinte, EA amplific
caracteristicile importante sau trsturile unui sistem, n timp ce modelele ntreprinderii descriu i
precizeaz sistemul n detaliu.
2.3.1.2 Concepte de baz ale arhitecturii ntreprinderii
Arhitectura ntreprinderii are ca scop crearea unei viziuni asupra viitorului sistem. Aceast
viziune este reprezentat ca o soluie cu un grad nalt de abstractizare care stabilete bazele pentru
proiectare, concentrndu-se pe caracteristicile i trsturile eseniale ale sistemului. Punctele forte
i punctele slabe pot fi apoi mult mai uor detectate i analizate. Pe de alt parte, de obicei,
designul n inginerie este mprit n modele preliminare i detaliate. Designul preliminar este, de
asemenea, numit design de arhitectura. Pe parcursul fazei preliminare de proiectare sunt definite
doar tipuri de soluii. Comunitatea ingineriei software consider, de asemenea, c arhitectura este
organizarea fundamental a unui sistem, ncorporat n componentele sale, n relaiile dintre ele i
cu mediul, cu principiile directoare ale designului i dezvoltrii sale [156]. Arhitectura
ntreprinderii este privit ca arhitectur complementar arhitecturii software, de natur s
documenteze organizarea la nivel de sistem i contextul de activitate n care funcioneaz
software-ul.
81
2.3.1.3 Diferite tipuri de arhitecturi de ntreprindere

Potrivit Grupului de Lucru IFAC-IFIP (IFAC-IFIP Task Force) [157] i ISO 15704 [154] exist
dou tipuri de arhitecturi care se ocup cu integrarea ntreprinderii: (1) arhitecturi de sistem
(uneori menionate ca arhitecturi de tip "1), care se ocup cu designul unui sistem, de exemplu,
sistemul parte a unui ansamblu de integrare a ntreprinderii; (2) Proiectele de Referin pentru
ntreprindere (denumite uneori ca arhitecturi de tip 2) care se ocup cu organizarea dezvoltrii
i punerii n aplicare a unui proiect, cum ar fi integrarea ntreprinderii sau alt program de
dezvoltare a ntreprinderii. Arhitecturile de tip 2 sunt de fapt cadre care vizeaz concepte i
activiti / sarcini de structurare necesare pentru a proiecta i construi un sistem. Arhitecturile de
tipul 1 reprezint sistemul sau sub-sistemul n termeni de structur i comportament. Alte lucrri
fac distincie ntre arhitecturi conceptuale i tehnice[158]. Arhitectura conceptual este derivat
din cerinele activitii; i este neleas i susinut de conducerea superioar. Arhitectura tehnic
ofer componente tehnice care permit strategiile i funciile activitii desfurate. Uneori,
arhitectura conceptual este, de asemenea, numit funcional sau a activitii, iar arhitectura
tehnic, arhitectur ICT.
n seciunea urmtoare va fi fcut o trecere in revist a abordrilor anterioare n direcia
arhitecturilor pentru integrarea ntreprinderii.
2.3.1.4. Integrarea la nivel de ntreprindere
Integrarea la nivel de ntreprindere este procesul de asigurare a interaciunii ntre entitile
ntreprinderii necesar pentru atingerea obiectivelor domeniului [159]. Integrarea ntreprinderii
poate fi abordat n diferite maniere i la diferite niveluri [160.], de exemplu: (1) integrarea fizic
(interconectarea de dispozitive, maini controlate numeric, prin reele de calculatoare), (2)
integrarea aplicaiilor (integrarea aplicaiilor software i a sistemelor de baze de date) i (3)
integrarea activitilor (coordonarea funciilor de administrare, de control i de monitorizare a
proceselor de activitate). Alte abordri pot, de asemenea, s ia n considerare: (1) integrarea prin
modelarea ntreprinderii (de exemplu, prin utilizarea unui cadru de modelare consistent) [161] i
(2) integrarea ca abordare metodologic pentru realizarea unui nivel consistent n cadrul ntregii
ntreprinderi de luare a deciziilor [162].
2.3.1.5. Interoperabilitatea la nivel de ntreprindere
Definiiile privind interoperabilitatea au fost revizuite n [163], [164]. Exist numeroase definiii
pentru interoperabilitate. Conform IEEE [165], interoperabilitatea este capacitatea a dou (sau
mai multe) sisteme de a se schimba informaii i de a folosi informaiile care au fost schimbate. O
alt definiie dat de Verdanat [166] caracterizeaz interoperabilitatea ca fiind abilitatea a dou
sisteme de a se comunica i de a-i utiliza funcionalitatea reciproc. IDEAS [167] consider
interoperabilitatea ca fiind abilitatea a dou ntreprinderi de a interaciona. Interoperabilitatea este
considerat semnificativ dac interaciunile poate avea loc cel puin pe trei niveluri diferite: de
date, servicii i procese, cu o semantic definit ntr-un context de afaceri dat [167].
Pe scurt, definiia IEEE se refer doar la interoperabilitatea la nivel de informaie. Definiia lui
Verdanat introduce conceptul de schimb de funcionalitate fiind complementar cu definiia
IEEE. Definiia dat de IDEAS reflect cel mai bine interoperabilitatea la nivel de ntreprindere,
fiind complementar ci primele dou. Cuvntul "inter-opera" implic faptul c un sistem
efectueaz o operaie pentru un alt sistem. Din punctul de vedere al tehnologiei informatice,
aceasta este capacitatea a dou sisteme informatice eterogene de a funciona mpreun i de a-i
82
oferi acces la resursele lor ntr-un mod reciproc. n contextul ntreprinderilor aflate n reea,
interoperabilitatea se refer la capacitatea de interacionare (schimb de informaii i servicii) ntre
sistemele ntreprinderii.
2.3.2. Istoric: Arhitecturi pentru integrarea la nivel de ntreprindere

Cele mai multe dintre EA pentru integrarea la nivel de ntreprindere dezvoltate pn n prezent
sunt arhitecturi de tip 2. Aceste arhitecturi structureaz concepte, principii i sarcini pentru
modelarea i ingineria integrat a ntreprinderii. Ele nu se ocup cu reprezentarea modului n care
o anumit ntreprindere este eficient structurat sau operat. Cu alte cuvinte, acestea nu sunt
reprezentarea proceselor operaionale, de date, ale structurii organizatorice, etc. Mai degrab, ele
definesc conceptele sau construciile de modelare (de exemplu, clasele de obiecte) care sunt
necesare pentru a descrie sistemele ntreprinderii, astfel nct modelele atinse sunt coerente i
uor de integrat.
2.3.2.1 Iniiative timpurii n privina arhitecturii de ntreprindere
Numeroase cercetri au fost ntreprinse n Europa i Statele Unite ale Americii, n timpul anilor
1980, n scopul dezvoltrii unor cadre pentru arhitectura de ntreprindere. Dintre acestea, cele
mai cunoscute sunt: Computer Integrated Manufacturing Open System Architecture (CIMOSA)
[168.], care a inventat termenul de arhitectur de ntreprindere, Purdue Enterprise-Reference
Architecture (Arhitectura de referin Purdue a ntreprinderii) (PERA) [169], arhitecturile GIM
[170] i ARIS [171]. Aceste arhitecturi de tip 2 sunt elaborate n principal de-a lungul ciclului de
via al sistemului cu scopul de a arta ce trebuie s fie fcut pentru a modela, proiecta i
implementa un sistem integrat al ntreprinderii. Cadrul Zachman [172] este un alt exemplu. El
structureaz concepte diferite de modelare i de inginerie a ntreprinderii n funcie de
perspectivele diferitelor pri interesate implicate n ingineria ntreprinderii. Acest lucru se
datoreaz faptului c diferitele pri interesate folosesc diferite niveluri de abstractizare n
aprecierea unei ntreprinderi i se ateapt rezultate diferite.
CIMOSA
Proiectul CIMOSA (Computer Integrated Manufacturing Open System Architecture) a fost
dezvoltat la nceputul anilor 1990 de consoriul AMICE(European CIM Architecture), una din
cele mai importante iniiative CIM in cadrul programului ESPRIT. Principalele dou rezultate
[173] ale proiectului au fost reprezentate de un cadru de modelare al ntreprinderii (figura 2.1),
avnd ca scop susinerea integrrii n cadrul ntreprinderii a mainilor, computerelor, persoanelor
si o infrastructur de integrare (figura 2.2). Ulterior, CIMOSA a fost validat in proiectele
ESPRIT: CIMPRES, CODE si VOICE, de ctre asociaii profesionale: IFIP/IFAC, organizaii
independente n mai multe ri precum si de organizaii membre AMICE.
Cadrul de modelare din figura 2.1 [174] structureaz arhitectura de referin CIMOSA pe mai
multe nivele, fiecare nivel oferind o perspectiva diferita asupra modelului ntreprinderii. Folosirea
conceptului de perspectiv permite lucrul la un moment dat doar cu un subset al modelului
ntreprinderii, reducnd astfel complexitatea pentru utilizatori. CIMOSA a definit patru
perspective de modelare diferite: funcional, informaional, resurse, organizaional.
Arhitectura de referin CIMOSA suport trei niveluri de modelare al ciclului de via al unei
ntreprinderi, ncepnd de la definirea cerinelor, specificaiile de proiectare, specificaiilor de
implementare si execuia operaiilor zilnice din cadrul ntreprinderii.
83
Fig. 2.1. Cadrul model CIMOSA [175]
Infrastructura de integrare ofer servicii informatice pentru execuia unui model particular de
implementare oferind independen furnizorilor si portabilitate.
Aceste servicii permit ingineria si procesarea modelului. Componentele infrastructurii de
integrare sunt prezentate in figura 2.2. Controlul asupra execuiei modelului de descriere al
implementrii este oferit de entitatea business care primete evenimente si creeaz ocurene ale
proceselor din domeniu precum si coninut. Controlul proceselor de afaceri, managementul
resurselor si controlul activitilor (toate parte a entitii business) analizeaz coninutul
modelului, atribuie resursele, identific informaia necesar si se conecteaz la resursele IT i
resursele de producie prin entitile: comun, informaie si de prezentare. n cele din urm,
entitile business controleaz execuia proceselor din domeniu si a activitilor din cadrul reelei.
84
Fig. 2.2. Infrastructura de integrare CIMOSA
GRAI-GIM
GRAI-GIM [176] este o metodologie de modelare destinat descrierii general, axat pe detalii n
sistemul de control de fabricaie. Ea a fost dezvoltat de Laboratorul de automatizare si Productie
(LAP), la Universitatea din Bordeaux - Frana. Aceasta a luat forma sa actual n anul 1988.
Metoda GRAI a fost publicat pentru prima dat n 1977.
Metodologia propune diferite formalisme pentru a valorifica cunotinele n cadrul unei
ntreprinderi, de a structura sistemul de producie, i de a sprijini dialogul i schimburile ntre
85
diferii actorii. GRAI-GIM include: (1) Modelul de referin conceptual GRAI, (2) cadrul de
modelare GRAI-GIM, (3) metoda de modelare structural GRAI-GIM.
n GRAI-GIM, o ntreprindere const ntr-un sistem fizic, un sistem de decizie i un sistem
informaional. O ntreprindere poate fi descris prin patru vizualizri (figura 2.3):
funcional, fizic, decizional, i informaional.
De asemenea, o structur cubic a fost propus cu patru vizualizri n partea stng, i trei
domenii: fabricaie, organizaional i informaional (Figura 2.4)
Modelul functional Modelul de luare Modelul fizic

Modelul informaii
a deciziilor
nivelurile funcii
de orizont Constrngeri
/ perioada Constrngeri
Conceptual
activitate
activitate
Constrngeri
entitate entitate activitate
activitate
Constrngeri suport
informaie
relaie
Mecanism
nivelurile
funcii
activitate Constrngeri
de orizont
/ perioada
Constrngeri
entitate
Mecanism activitate
activitate
Structural
Mecanism
activitate
Mecanism
suport informaie & resurse
Fig. 2.3. Arhitectura de referin GIM i forme de reprezentare pentru faza de proiectare
86
Vizualizare Domeniu
Informaional
Tehnologia
Decizional Informaiei
Fizic Tehnologia de
fabricaie
Funcional
Organizarea
Analiz
Proiectare
Proiectare
tehnic
Dezvoltare
Conceptual Structural Structural Realizare Nivel de

abstractizare
Ciclu de via
Fig. 2.4. Diferite vizualizri ale GIM
Ciclul de via al metodologiei GIM-GRAI are cinci faze: (1) analiz, (2) proiectare
specificaiilor, (3) proiectare tehnic, (4) dezvoltare, i (5) operare. Poate fi observat n figura 2.4
c faza de proiectare a specificaiilor are dou niveluri de abstractizare: conceptual i structural.
Faza de proiectare tehnic are de asemenea dou niveluri de abstractizare, dar n acest caz nivelul
conceptual este nlocuit cu nivelul de implementare. Nivelele conceptuale sunt organizate
conform celor patru vizualizri menionate anterior: funcional, fizic, decizional,
i informaional. Nivelul structural al fazei de proiectare tehnic ct i cel de implementare sunt
organizate conform celor trei domenii: fabricaie, organizaional i informaional.
GRAI-GIM conine o metod orientat ctre utilizator i una orientat tehnic. Metoda orientat
utilizator transpune cerinele specificate de utilizator n: funcii, informaii, decizii i resurse.
Metoda orientat tehnic transform specificaiile utilizatorului n specificaii tehnice n termeni de
tehnologii informatice i de producie ce pot fi folosite pentru a implementa sistemul.
Obiectivul GRAI-GIM este de a dezvolta specificaii pentru sisteme de producie asistat de
calculator (CIM). Totui, metodologia se ocup numai de analiz i fazele de proiectare din ciclul
de via al sistemului de producie. Dei GRAI-GIM nu se ocup de dezvoltarea sistemului n
sine, ea produce datele de intrare pentru aceast faz . Este util ca referin, ghid.
PERA
PERA (Purdue Enterprise Reference Architecture) [169] fost dezvoltat la Universitatea Purdue n
perioada 1989-1994. PERA reprezint o arhitectur de referin i o metodologie care poate fi
folosit pentru a satisface conceptele legate de integrarea ntreprinderii. Arhitectura descrie ciclul
de via al unei ntreprinderi pornind de la faza iniial de identificare a proiectului i cobornd
prin toate fazele intermediare: concept, definiie, proiectare funcional, proiectare detaliat,
construcie i instalare, operare i ntreinere, renovare sau eliminare i pn la faza final a
dizolvrii ntreprinderii. PERA propune un set de aptesprezece concepte(practici recomandate)
87
pentru simplificarea integrrii la nivel de ntreprindere. O alt contribuie important este

reprezentat de integrarea factorului uman n orice sistem automatizat printr-un set de apte
concepte care stabilesc locul factorului uman n ntreprindere.
Cadrul Zachman
Cadrul Zachmann (figura 2.5) reprezint un model de management organizaional al unei
ntreprinderii sau organizaii virtuale de tip matricial. El ofer o abordare formal i structurat
capabil s faciliteze vizualizarea activitilor de management. Const ntr-o matrice
bidimensional (6 x 6) obinut prin intersecia a dou clasificri istorice prezente n literatur.
Prima dintre ele (coloane) este reprezentat de fundamentele comunicrii gsite n interogrile:
Ce?, Cum?, Cnd?, Cine?, Unde? i De ce? Integrarea rspunsurilor la aceste ntrebri permite
descrierea complet a unor idei complexe. A doua dimensiune (rnduri) reprezint o reificare, o
transformare a unei idei abstracte ntr-o implementare/instaniere, i este reprezentat de:
identificare, definiie, reprezentare, specificaie, configurare si instaniere [177]. Clasificrile
propuse de cadrul Zachmann sunt reprezentate de celulele obinute prin intersecia ntre
interogative i transformri. Mai exact, cadrul Zachmann este o ontologie - o teorie a existenei
unui set structurat de componente eseniale ale unui obiect pentru care expresiile explicite sunt
necesare i poate chiar obligatorii pentru crearea, operarea si schimbarea obiectului (obiectul
fiind o ntreprindere, un departament, un lan de valori, o soluie, un proiect, etc.). Cadrul nu este
o metodologie folosit pentru implementarea(instanierea) obiectului. El reprezint o structur, pe
cnd o metodologie este un proces.
Comparnd aceste arhitecturi, se observ c CIMOSA este orientat spre procese ducnd la
integrarea funciilor de modelare i monitorizarea a fluxului activitilor. GIM se bazeaz pe
modelul de decizie GRAI n care integrarea este vzut drept coerena dintre obiectivele de
decizie globale i locale. PERA i arhitectura Zachman nu ofer nici un nou formalism al
modelrii, ns definesc cadrele unei arhitecturi complexe. Toate acestea arhitecturi sunt
eterogene i complementare, mai degrab dect contradictorii. Grupul de Lucru IFAC-IFIP
(IFAC-IFIP Task Force) a studiat la mijlocul anilor 1990 arhitecturile existente ncercnd
identificarea redundanelor si a complementaritii lor, n vederea unei posibile armonizri. Ceea
ce a rezultat se numete Generalized Enterprise-Reference Architecture and Methodology
(Arhitectura i metodologia generalizate de referin ale ntreprinderii) (GERAM) [157].
88
Fig. 2.5. Cadrul Zachmann pentru arhitectura ntreprinderii
GERAM
GERAM identific, n componenta sa cea mai important numit GERA (Generalized Enterprise
Reference Architecture Arhitectura generalizat de referin a ntreprinderii), conceptele de
baz pentru a fi utilizate n ingineria i integrarea ntreprinderii. GERAM a fost dezvoltat pe baza
unor contribuii semnificative din partea CIMOSA i a metodologiei integrate GRAI (GRAI /
GIM) i PERA. n urma analizei a diferitor cadre arhitecturale [178] cum ar fi: PERA, CIMOSA,
GRAI/GIM, Zachman, C4ISR/DoDAF, GERAM a fost preluat n procesul de standardizare
(CEN i ISO).
Munca Grupului de Lucru IFAC-IFIP (IFAC-IFIP Task Force) a adus o contribuie considerabil
la o mai bun i mai profund nelegere a arhitecturii de ntreprindere. Cu toate acestea, impactul
GERAM la nivel industrial nu este la fel de important precum ar fi fost de ateptat. Unul dintre
motive este, pe de o parte, lipsa de implicare a sectorului n studiu i, pe de alt parte,
caracteristicile conceptuale al studiului.
89
Alte lucrri importante au fost dezvoltate n SUA: TOGAF, C4ISR (sau DoDAF). TOGAF este
dezvoltat de Open Group on Architecture Framework (Grupul deschis pentru cadrul arhitectural).
Acesta conine dou pri principale: Architecture Development Method (ADM) i Foundation
Architecture cu funcii/servicii generice pe baza crora pot fi construite arhitecturi i module
specifice [155]. Arhitectura C4ISR este dezvoltat de C4ISR Architecture Working Group
pentru a defini o abordare coordonat, adic un cadru pentru comand, control, comunicaii,
informaii, supraveghere i recunoatere a dezvoltrii arhitecturii, prezentarea i integrarea ei
[179]. De asemenea, este cunoscut sub numele de DoDAF (Arhitectura-cadru a Departamentului
Aprrii (DoD)), furniznd o abordare comun pentru dezvoltarea descrierii arhitecturii
Departamentului Aprrii (DoD), prezentarea i integrarea ei, att pentru operaiunile de rzboi
ct i pentru operaiunile i procesele comercial-economice [180].
n concluzie, arhitecturile de ntreprindere (de tip 2) dezvoltate n trecut reflect
fondul/competenele dezvoltatorilor lor i scopul pentru care au fost elaborate: de exemplu,
CIMOSA pentru producia integrat cu calculatorul, GRAI pentru managementul produciei i al
lurii deciziilor, PERA pentru ingineria de sistem, Zachman pentru sistemele informaionale i
DoDAF pentru managementul i coordonarea operaiunile militare [178].
2.3.2.2 Standarde privind integrarea la nivel de ntreprindere
Cele dou organisme de standardizare active n dezvoltarea unor standarde de arhitectur de tip 2
sunt: CEN TC310/WG1 i ISO TC184 SC5/WG1 [181]. Principalele rezultate obinute de cele
dou organisme sunt standardele: ISO 15704 [154] - Cerine pentru arhitectura i metodologiile
de referin ale ntreprinderii, i EN / ISO I9439 [159] - Integrarea ntreprinderii - cadru pentru
modelarea ntreprinderii. EN / ISO 19439 a fost dezvoltat pe baza unui pre-standard european,
ENV 40003, elaborat la nceputul anului 1990 de CEN TC310/WG1. Acesta definete conceptele
generice care sunt necesare pentru a permite crearea de modele ale ntreprinderii pentru activiti
industriale i constituie o baz conceptual pentru ingineria bazat pe modele a ntreprinderii.
EN/ISO 19439 este n concordan cu ISO 15704 i este considerat ca o punere n aplicare a
cerinelor definite n ISO 15704. Domeniul de aplicare al ISO 15704 include orice tip de modul
de control al produciei, n timp ce EN/ISO 19439, se concentreaz mai mult pe un proces de
monitorizare i control bazat pe model i executabil pe computer. Cu toate acestea, cadrul de
modelare este compatibil cu GERAM, care este descris n anexa la ISO 15704. Alt abordare
dezvoltat de organismele de standardizare industrial este standardul IEEE 1471 [156]. Acest
standard este preocupat de Practica recomandat pentru descrierea arhitectural a sistemelor
intensiv-software. Practica recomandat se adreseaz activitilor de creaie, analiz i suport al
arhitecturilor de sisteme intensive de software, precum nregistrrii acestor arhitecturi n termeni
de descrieri arhitecturale. Un cadru conceptual pentru descrierea arhitectural este astfel stabilit
(figura 2.6). Este definit coninutul unei descriere arhitecturale. Anexele ofer motivaia
conceptelor cheie i terminologiei, relaiile cu alte standarde i exemple de utilizare. Dei
abordarea privete n primul rnd ingineria software, conceptele sale arhitecturale se aplic la fel
de bine arhitecturii ntreprinderii.
90
Fig. 2.6. Cadrul conceptual IEEE1471-2000
O alt lucrare relevant este Open Distributed Processing Reference Model (RM-ODP), cunoscut
i sub numele de ISO 10746. El a reprezentat o iniiativ comun a ISO i ITU-T pentru a
dezvolta o arhitectur generic pentru Open Distributed Processing (ODP). ODP combin
conceptele de sisteme deschise i de calcul distributiv, avnd diferite perspective, cum ar fi, de
exemplu, i o perspectiv a ntreprinderii. O perspectiv/punct de vedere (asupra unui sistem)
este o abstracie care ntlnete specificaiile ntregului sistem n relaie cu un anumit set de
preocupri. RM-ODP definete cinci puncte de vedere [182], fiecare punct de vedere al modelul
descriptiv fiind susinut de un limbaj definit n Modelul descriptiv. Modelul descriptiv este
format din dou pri: (1) definirea limbajelor punctelor de vedere i (2) Cadrul arhitectural
pentru interaciunea obiectelor. Cele cinci puncte de vedere/perspective ale ODP-ului sunt:
ntreprinderile, informaiile, calculele, ingineria i tehnologia.
Dei au fost depuse eforturi considerabile pentru a dezvolta standarde asupra arhitecturilor de
ntreprindere, nici una din cele patru abordri prezentat mai sus nu a ajuns la o maturitate
suficient pentru a fi recunoscut i acceptat n industrie. Nu a fost nici o colaborare ntre cele
trei grupuri (ISO TC184/SC5, ISO/IUT-T i IEEE) pentru elaborarea standardelor. Chiar dac
pare dificil ca aceste standarde s fuzioneze, este totui necesar s se stabileasc o mapare ntre
ele, n scopul de a obine anumite interoperabilitii ntre modelele i sistemele construite
folosind aceste standarde.
91
2.3.3. Arhitecturi pentru interoperabilitatea la nivel de ntreprindere

Cercetarea asupra interoperabilitii la nivel de ntreprindere a luat amploare la nceputul anilor
2000, principalele lucrri concentrndu-se asupra dezvoltrii arhitecturilor ntreprindere de tip
doi, fiind preocupate de elaborarea unui cadru al interoperabilitii la nivel de ntreprindere.
Conform standardului EN/ISO I9439 [159] scopul principal al unui cadru este de a oferi un
mecanism de organizare care s permit reprezentarea ntr-un mod structurat a conceptelor,
problemelor i cunotinelor cu privire la interoperabilitate ntreprinderii. Aceast structur este
exprimat prin intermediul diagramelor, textului i regulilor formale care leag componentele
unei entiti conceptuale.
Modelul de referin LISI
Prima iniiativ remarcabil n domeniul interoperabilitii ntreprinderii este reprezentat de LISI

(Levels of Information Systems Interoperability), abordare dezvoltat de C4ISR Architecture
Working Group pe parcursul anului 1997. Scopul LISI a fost acela de a nzestra Departamentul
Aprrii al SUA (DoD), cu modele i procese mature de determinare a nevoilor comune de
interoperabilitate, de evaluare a capacitii sistemelor informaionale de a rspunde acestor nevoi,
i de selectare a unor soluii pragmatice i a unei ci de transmitere pentru realizarea unor stri
superioare de capacitate i interoperabilitate [183].
LISI reprezint un proces pentru definirea, msurarea, evaluarea interoperabilitii sistemelor
informaionale. LISI se aplic de-a lungul ciclului de via al sistemelor informaionale, ncepnd
cu definirea cerinelor, dezvoltarea, achiziia, modificarea i mbuntirea sistemelor.
LISI ofer un model matur de interoperabilitate care descrie creterea nivelului de sofisticare n
ceea ce privete capacitatea sistemelor de a face schimb de informaii ntre ele. El permite
identificarea cerinelor operaionale i de sistem n termeni de niveluri specifice de
interoperabilitate prin identificarea tipurilor de tranzacii informaionale
necesare, n context cu nivelurile stabilite n modelul de interoperabilitate. Nivelurile de
interoperabilitate, prezentate si n figura 2.7 sunt: izolat, conectat, funcional, domeniu i
ntreprindere. Modelul de referin LISI caracterizeaz cele cinci niveluri de interoperabilitate
printr-un set comun de capaciti necesare tuturor sistemelor informaionale care doresc s fie
interoperabile la un anumit nivel. Fiecare nivel de interoperabilitate trebuie s acopere toate cele
patru atribute care permit interoperabilitatea, cunoscute sub numele de PAID, i anume:
proceduri, aplicaii, infrastructur (servicii de hardware, de comunicaii, de securitate i de
sistem) i date. Modelul de referin LISI ofer, de asemenea, vocabularul comun i structura
necesare pentru a stabili interoperabilitatea ntre sisteme. La fiecare nivel, un cuvnt sau o
expresie evideniaz cele mai importante aspecte al PAID necesare pentru a atinge acest nivel.
Dei fiecare atribut (PAID) este semnificativ i trebuie s fie luat n considerare n definirea unui
nivel de interoperabilitate, importana i impactul relativ al contribuiilor fiecrui atribut variaz
n funcie de nivel [183].
Calculare
Descriere Mediu Nivel P A I D
ntreprindere Universal 4 Nivel Interactiv Topologii Model
ntreprindere multi- ntreprindere
92
dimensionale
Domeniu Integrat 3 Nivel De grup Reele Model
domeniu globale domeniu
Funcional Distribuit 2 Nivel Automatizare Reele locale Model
program ecran program
Conectat De la egal 1 Nivel local / Drivere Conexiune Local
la egal locaie standard de simpl
sistem
Izolat Manual 0 Control Neaplicabil Independent Privat
Acces
Fig. 2.7. Modelul de referin LISI
LISI ofer de asemenea un proces practic de evaluare pentru a determina nivelul de maturitate al
interoperabilitii pentru un sistem sau sistem dat pereche, capabilitile care pot lipsi,
implementri care sunt incompatibile, i opiunile disponibile pentru rezolvarea deficienelor i
pentru realizarea unui nivel din ce n ce mai nalt de maturitate. Un proces de evaluare practic
pentru determinarea ajungerii la maturitate a nivelului de interoperabilitate al unui sistem sau a
sistemului pereche dat este de asemenea definit. Pentru mai multe detalii, a se vedea [183].
Abordarea LISI este axat pe dezvoltarea interoperabilitii n sectorul militar al SUA. Deoarece
este construit cu concepte generice i modele, este folosit ca baz pentru elaborarea altor
modele mature de interoperabilitate, cum ar fi, de exemplu, modelul de maturitate organizaional
[184] i modelul de maturitate al interoperabilitii ntreprinderii [185].
Cadrul de interoperabilitate IDEAS
Cadrul de interoperabilitate IDEAS (figura 2.8) a fost dezvoltat de proiectul IDEAS pe baza
ECMA/NIST (ECMA/NIST Toaster Model), i a standardelor ISO 19101, ISO 19119 la care s-au
adugat atribute privind calitatea [186].
Cadrul este i el destinat s reflecte concepia conform creia interoperabilitatea este obinut pe
mai multe niveluri: coordonarea inter-ntreprinderi, integrarea proceselor economice, integrarea
semantic a aplicaiilor, integrarea sintactic a aplicaiilor i integrarea fizic.
La nivelul economic al modelului sunt abordate toate problemele legate de organizarea i
conducerea unei ntreprinderi. Printre altele, acestea includ modul n care o ntreprindere este
organizat, cum funcioneaz pentru a produce valoare, cum se gestioneaz relaiile sale (intern
cu propriul personal i extern cu parteneri, clieni si furnizori). Interoperabilitatea la acest nivel ar
trebui s fie vzut drept capacitatea organizaional i operaional a unei ntreprinderi de a
coopera n fapt cu alte ntreprinderi.
Nivelul economic include modelul decizional, modelul economic i cel al proceselor economice.
Modelul decizional a unei ntreprinderi definete ce/cum sunt luate deciziile i gradul de
responsabilitate al fiecrei uniti de operare, rolul i poziia. Modelul economic este descrierea
relaiilor comerciale ntre o ntreprindere i modul n care ofer produse sau servicii pe pia.
Procesele economice sunt un set de activiti care ofer valoare pentru clienii unei ntreprinderi
[187].
93
La nivelul cunotinelor sunt dobndite, structurate i reprezentate cunotinele

colective/personale al unei ntreprinderi. Acesta include cunoaterea aspectelor interne, cum ar fi
produsele, modul n care administraia funcioneaz i controleaz, cum este gestionat personalul
i aa mai departe, dar, de asemenea, i aspectele externe privitoare la parteneri i furnizori, legi
i regulamente, obligaiile legale i relaiile cu instituiile publice.
Interoperabilitatea la nivel de cunotine ar trebui s fie vzut ca o compatibilitate a
aptitudinilor, competenelor i activelor de cunotine ale unei ntreprinderi cu cele ale altor
ntreprinderi. Acest strat se adreseaz metodelor i instrumentelor care susin suscitarea,
colectarea, organizarea i difuzarea de cunotine economice i comerciale ntr-o ntreprindere.
Nivelul de cunotine include mai multe modele. Modelul organizaional poate defini rolurile
organizarea intern, lanul de valori, o reea de ntreprinderi sau o constelaie. Un model de
abiliti-competene definete capacitatea unei organizaii i a angajailor si de a efectua o
anumit sarcin n anumite condiii de lucru. Activele de cunotine ale ntreprinderii sunt capital
al organizaiei formalizat din punct de vedere al procedurilor, normelor, regulilor i referinelor.
Nivelul 1 Nivelul 2 O Atribute privind

al al n calitatea
cadrului cadrului to
lo
gi
e
S Secu Scalabi Evol
e ritat litate uie
m e
a
n
ti
c

Economic Model
decizional
Model
economic
Modelul ntreprinderii
Procese
economice
Cunotin Roluri n
e organizaie
Abiliti Atribute privind calitatea
Competene
Active de Perfor Disponibi Portabili
cunotine man litate tate
Aplicaii Managemen
Platform
tul soluiilor
Interaciune
la locul de
lucru
94
Logica
aplicaiei
Procesul
aplicaiei
Date Date despre
Produs
Date despre
Proces
Date despre
Cunotine
Date
comerciale
Comunic
aie
Fig. 2.8. Cadrul de interoperabilitate IDEAS
Nivelul sistemelor ICT este preocupat de soluii ICT care permit unei ntreprinderi s opereze, s
ia decizii, s schimbe informaii n interiorul i n afara granielor sale. Execuia general a
aplicaiilor ntreprinderii va fi orchestrat de ctre modelul de procese economice identificat n
nivelul superior i va fi formal reprezentat i stocat n nivelul de mijloc (al cunotinelor).
Interoperabilitatea la nivel de sisteme ICT ar trebui s fi vzut ca fiind capacitatea sistemelor
ICT ale unei ntreprinderi de a colabora cu cele ale altor organizaii externe. Interoperabilitatea
trebuie s fie stabilit prin furnizarea de informaii prin intermediul comunicrii inter- i intra-
sistem. Nivelul ICT include diverse domenii, cum ar fi managementul soluiilor, interaciunea la
locul de munc, logica aplicaiilor, logica proceselor i logica datelor. Managementul soluiilor se
refer la instrumentele i procedurile necesare pentru a administra un sistem de ntreprindere.
Acesta include rolul i politica de management, instrumentele de monitorizare i simulare.
Interaciunea la locul de munc se refer la interaciunea utilizatorului uman cu sistemul, care ar
putea fi descris prin intrare, ieire i navigaie. Logica aplicaiilor descrie calculul efectuat de
ctre un sistem de ntreprindere pentru obinerea unui rezultat economic. Logica proceselor este
ordinea (de exemplu, pas-cu-pas) n care o aplicaie (sau un subset) este executat. Logica datelor
descrie datele necesare i datele produse de ctre un sistem de ntreprindere n timpul ciclului su
de via. Aceasta include servicii de stocare i de management al coninutului.
Dimensiunea semantic se ntinde de-a lungul nivelurilor: economic, ICT i de cunotine. Este
preocupat cu extragerea i reprezentarea sensului real al conceptelor, i astfel promoveaz
nelegerea lor. Perspectiv holistic privind interoperabilitatea impune luarea n considerare a
semanticii la fiecare nivel al unei ntreprinderi. Pentru ntreprinderile care doresc s colaboreze
unele cu altele i care necesit interoperabilitate la un anumit nivel, semantica este de prim
importan pentru a crea o nelegere comun [187].
Atributele de calitate constituie o dimensiune suplimentar a cadrului. Considerentele economice

determin calitile care trebuie s fie prezente ntr-un sistem. Aceste caliti sunt dincolo de cele
de funcionalitate, care in de caracteristica fundamental a capacitilor, serviciilor i
comportamentelor sistemului. Atributele luate n considerare sunt: (1) de securitate (de stocare a
datelor, transfer i de protecie etc.), (2) scalabilitate, (3) portabilitate (att date, ct i aplicaii),
(4) de performan; (5) disponibilitate i (6) evoluie. Trebuie s fie subliniat faptul c realizarea
95
oricrui atribut de calitate va avea un efect, uneori pozitiv i alteori negativ, asupra realizrii altor
atribute de calitate [ 186].
Cadrul de interoperabilitate IDEAS este prima iniiativ efectuat n Europa n cadrul FP5 - Fifth
Framework Programme adresat ntreprinderilor i probleme de interoperabilitate n fabricaie.
Este folosit ca baz pentru a elabora o foaie de parcurs ce va servi n dezvoltarea Proiectului
integrat ATHENA i a INTEROP NoE n cadrul FP6 - Sixth Framework Programme. Principalul
dezavantaj al interoperabilitii cadrului IDEAS este c se bazeaz pe cele trei domenii de
cercetare relevante (Modelare ntreprindere, platform arhitectural i ontologie) contribuind la
dezvoltarea interoperabilitii, mai degrab dect a se adresa domeniului interoperabilitii n sine.
Un cadru al domeniului de interoperabilitate trebuie s fie elaborat astfel nct probleme
cercetrii interoperabilitii s poat fi identificate i structurate cu precizie. Acest punct este
abordat n cadrul INTEROP NoE.
Cadrul european de interoperabilitate (EIF)
Cadrul european de interoperabilitate [188], [189] are ca obiectiv sprijinirea strategiei Uniunii
Europene de a oferi servicii de guvernare electronic centrate pe utilizator, prin facilitarea, la un
nivel pan-european, a interoperabilitii serviciilor i sistemelor ntre administraiile publice,
precum i ntre administraii i public (ceteni, ntreprinderi).
Acest cadru european de interoperabilitate este definit ca un set cuprinztor de politici, standarde
i linii directoare, care descrie modul n care organizaiile au fost de acord, sau ar trebui s fie de
acord, de a interaciona economic unele cu altele. Un cadru de interoperabilitate nu este, prin
urmare, un document static i ar putea fi adaptat, n timp, la cerinele induse de schimbrile n
tehnologii, standarde i n administraie. Figura 2.9 ofer o imagine de ansamblu a principalelor
aspecte ale cadrului de interoperabilitate european care sunt luate n considerare. EIF ofer
recomandri i definete generic standarde cu privire la organizare, aspecte semantice i tehnice
legate de interoperabilitate.
Cadrul european de interoperabilitate se bazeaz pe premisa c fiecare stat membru are, sau se
afl n proces de dezvoltare, a unui cadru naional guvernamental de interoperabilitate(GIF -
Government Interoperability Framework). EIF ncearc s completeze cadrele naionale de
interoperabilitate prin adugarea dimensiunii pan-european. Acesta ofer un set cuprinztor de
principii pentru cooperarea european n domeniul guvernrii electronice prin furnizarea de
recomandri i definirea standardelor generice cu privire la aspectele organizaionale, semantice
i tehnice ale interoperabilitii [190].
EIF este completat de ghidul arhitectural IDABC [191], care abordeaz interoperabilitatea dintr-
un punct de vedere mai tehnic i pragmatic. Att ghidul arhitectural ct i alte documente
prevzute n programul de lucru IDABC au ca scop ndrumarea practic i definirea de standarde
i infrastructuri necesare pentru implementarea interoperabilitii.
EIF identific trei tipuri de interaciune care acoper cea mai mare parte
din serviciile de guvernare electronic transfrontaliere disponibile la dat elaborrii cadrului:
Administrativ ctre cetean (A2C: administration to citizen) reprezint interaciunea direct
dintre ceteni sau ntreprinderi ale unui anumit stat membru, cu administraiile din alte state
membre i / sau instituii europene; Administrativ ctre administrativ (A2A: administration to
administration) - schimbul de date ntre administraii din diferite state membre; Administrativ
96
ctre mediul afacerilor (A2B: administration to business) - schimbul de date ntre diferite
instituii / agenii ale UE sau ntre o instituie/agenie UE i unul sau mai multe administraii ale
statelor membre [191]. De asemenea, EIF propune o clasificare interoperabilitii din punctul de
vedere al aspectelor de interoperabilitate: semantic, tehnic, organizatoric. Aceste aspecte se
concentreaz mai mult pe problemele ridicate de realizarea interoperabilitii dect pe nivelul
entitilor operaionale unde interoperabilitatea are loc prin schimbul de informaii.
Fig. 2.9. Principalele aspecte ale cadrului de interoperabilitate EIF
Cadrul de interoperabilitate la nivel de ntreprindere dezvoltat n INTEROP NoE
Aceast seciune prezint cadrul de interoperabilitate la nivel de ntreprindere dezvoltat n

Reeaua de Excelen INTEROP NoE.
Scopul acestui cadru este de a defini domeniul de cercetare al interoperabilitii ntreprinderii i

de a ajuta la identificarea i structurarea cunoaterii domeniului. Acesta ia n considerare faptul c
sistemele de ntreprinderi nu sunt interoperabile, deoarece exist bariere n calea
interoperabilitii. Barierele sunt reprezentate de incompatibiliti de diferite tipuri i la diferite
niveluri ale ntreprinderii. Incompatibilitile mpiedic schimbul de informaii i ridic obstacole
n calea schimbului de date dintre servicii. Exist bariere comune pentru toate ntreprinderile,
indiferent de sectorul de activiti i de mrime. Dezvoltarea interoperabilitii nseamn
dezvoltarea cunotinelor i soluiilor pentru eliminarea incompatibilitilor [192], [193].
Abordarea adoptat urmrete dou obiective majore, si anume s: (1) defineasc domeniul de
interoperabilitate al ntreprinderii prin elaborarea unui cadru de interoperabilitate bazat pe
97
abordarea barierelor; (2) identificarea i structurarea cunotinelor (soluiilor) din domeniu cu

ajutorul cadrului. Cadrul de interoperabilitate propus este elaborat pe baza conceptelor dezvoltate
n unele cadre i modele existente EIF [188], [189] ERISA [194], IDEAS [186], ATHENA
[187], concentrndu-se asupra conceptelor mai relevante pentru a defini domeniul de cercetare al
interoperabilitii ntreprinderii.
Cadrul de interoperabilitate ATHENA
Scopul cadrului de interoperabilitate ATHENA a fost s sintetizeze rezultatele cercetrii

proiectului ATHENA. Proiectul ATHENA adopt o abordare holistic asupra interoperabilitii
pentru a obine o interoperabilitate real i semnificativ ntre ntreprinderi. Proiectul ATHENA
continu direcia de cercetare propus de IDEAS, cadrul de interoperabilitate ATHENA i cadrul
de interoperabilitate IDEAS fiind considerate complementare. Standardul IEEE 1471(2000) [195]
care conine recomandri privind descrierea arhitectural a sistemelor software a stat i el la baza
cadrului de interoperabilitate ATHENA.
Originalitatea proiectului ATHENA const n abordarea multidisciplinar
prin comasarea a trei domenii de cercetare care sprijin dezvoltarea interoperabilitii
aplicaiilor i software-ului din cadrul ntreprinderii. Cele trei domenii sunt: (1) modelarea
ntreprinderii care definete cerinele de interoperabilitate i sprijin implementarea soluiilor, (2)
arhitecturi i platforme care ofer cadrul de implementare, i (3) ontologii pentru identificarea
semanticii de interoperabilitate n ntreprindere.[ 196]
Cadrul de interoperabilitatea ATHENA (AIF/FIA) [197] este structurat pe trei niveluri: nivelul
conceptual, nivelul tehnic i nivelul aplicativ (figura 2.10). Nivelul conceptual este utilizat pentru
identificarea cerinelor de cercetare i integreaz rezultatele de cercetare ale proiectelor
ATHENA n cercetare i dezvoltare. Nivelul aplicativ integreaz experiena provenit din
proiecte de cercetare i dezvoltare i de testare tehnologic n locaii pilot i este folosit pentru
transferul de cunotine n ceea ce privete aplicarea tehnologiilor de integrare. Nivelul tehnic
este folosit pentru testarea tehnologic bazat pe profiluri i integreaz prototipuri ale proiectelor
de cercetare i dezvoltare.
Datorit complementaritii cu cadrul IDEAS, la fiecare nivel al AIF, se poate folosi cadrul de
interoperabilitate IDEAS pentru a structura problemele de interoperabilitate pe 3 nivele
(economic, de cunotine i ICT) i o dimensiune semantic.
Arhitecturile de referin, metodologiile, limbajele de modelare i conceptele, precum i modelele
de referin sunt toate elemente conceptuale. Ele sunt folosite pentru a construi anumite modele
de ntreprindere ale companiilor studiate. Instrumentele de modelare sunt componente
tehnologice care sprijin construcia modelului. Modelul "specific" al unei ntreprinderi este un
model conceptual i este aplicabil ntr-un anumit domeniu. Modelele de ntreprindere sunt apoi
puse n aplicare sisteme operaionale cu module de ntreprindere (infrastructur, de exemplu)
pentru a sprijini sistemele operaionale care execut operaiuni n ntreprinderi n fiecare zi. Att
modulele de ntreprindere ct i sistemele operaionale ale ntreprinderilor sunt elemente tehnice
(tehnologice) concrete.
98
Fig. 2.10. Cadrul de interoperabilitate ATHENA.
Bariere n calea interoperabilitii
Trei categorii de bariere (conceptuale, tehnologice i organizatorice) sunt identificate dup cum
urmeaz [198]
Barierele conceptuale: se refer la diferenele sintactice i semantice ale informaiilor care

urmeaz s fie schimbate. Aceste probleme implic modelarea la un nivel nalt de
abstractizare (Cum ar fi, de exemplu, modelele de ntreprindere ale unei companii), precum i
nivelul de programare (de exemplu, modelele XML).
Barierele tehnologice: Aceste obstacole se refer la incompatibilitatea tehnologiilor
informaionale (arhitectur i platforme, infrastructur, etc.). Aceste probleme implic
standardele de prezentare, stocare, schimb, procesare i comunicare a datelor prin utilizarea
calculatoarelor.
Barierele organizaionale: acestea se refer la definiia responsabilitii (cine anume este
responsabil i pentru ce?) i autoritii (cine anume este autorizat s fac ce anume?), precum
i la incompatibilitatea structurilor de organizare (matrice versus cele ierarhice, de exemplu).
Conform INTEROP [199] cadrul de interoperabilitate LISI, cadrul IDEAS, cadrul de
interoperabilitate ATHENA, cadrul de interoperabilitate european, etc. nu adreseaz explicit
barierele interoperabilitii, scopul lor nu este acela de a structura cunotinele legate de
interoperabilitate avnd n vedere nlturarea acestor bariere.
n seciunea urmtoare vor fi descrise pe scurt standarde de interoperabilitate existente.
2.3.3.1 Standarde de interoperabilitate
ISO 1033
Standardul ISO_1033 este un standard ISO folosit pentru reprezentarea i schimbul de informaie
folosit pentru fabricarea produselor ntr-un format interpretabil de calculator. Cunoscut i ca:
99
STEP (Standard for the Exchange of Product Model Data) este folosit pentru reprezentarea de
obiecte 3D n proiectarea asistat de calculator CAD (Computer Aided Design) [200].
STEP este recunoscut de industrie ca un standard eficient de schimb al datelor ntre dou sisteme
CAD sau ntre sisteme CAD i sisteme de implementare. Primele pri ale standardului au fost
publicate n anul 1994 i reprezint rezultatul efortului membrilor comitetului ISO TC184/SC4
[201]. Versiunea iniial era concentrat pe dezvoltarea unei infrastructuri pentru standard care s
permit extensibilitatea sa ulterioar.
ISO 10303 acoper o mare varietate de tipuri de produse diferite ( de la electronice, mecanice, i
pn la mobilier arhitectural, etc.) precum i etapele ciclului lor de via (proiectare, analiz,
planificare, fabricarea, etc.). Pe msur ce noi pri/componente ale standardului sunt publicate,
aceast gam se extinde. Aceste componente sunt menionate ca ISO 10303-XXX, unde xxx este
numrul componentei. Fiecare parte reprezint un standard de sine stttor, n ciuda faptului c e
o component a unui ntreg mai mare i a interdependenei cu alte pri.
Schimbul de date ntre dou sisteme se face n prezent n doi pai. n primul pas datele sunt
transformate din formatul nativ al sistemului care transmite n formatul neutru al standardului
ISO 10303. Pasul doi presupune transformarea datelor din formatul ISO 10303 n formatul
sistemului care recepioneaz datele. Mediul de schimb este reprezentat de un fiier ASCII
(American Standard Code for Information Interchange). Standardul face o separare ntre modelul
informaional i implementarea fizic. Standardul ISO 10303-022 definete o interfa SDAI
(Standard Data Access Interface) ctre depozitele care conin informaie neutr ISO 10303.
Aceast interfa permite crearea unor legturi cu limbaje de programare cum ar fi C++ sau
JAVA. Entitile reprezentate i schimbate folosind STEP sunt definite folosind scheme scrise
ntr-un limbaj de modelare numit EXPRESS [202]. Aceste scheme pot fi interpretate de
calculator verificarea validitii lor fcndu-se ntr-un mod automat.
Prile implementabile ale standardului (AP - Application Protocols) definesc modele pe care
sunt bazate translatoarele. Fiecare AP este aplicabil unui stagiu al ciclului de via al unui produs.
Sistemul de numerotare al prilor componente este destul de complex, seria 01x fiind alocat
resurselor definitorii. Seria 02x este alocat metodelor de implementare. Standardele din seria
03x au scopul de a valida translatorii pentru conformitate cu standardul. Seria 04x conine resurse
generice integrate ce reprezint blocurile de baz ale standardului. Seria 1xx conine resurse
aplicaie integrate. Protocoalele aplicaie apar n seria 2xx iar seria 5xx conine construciile
aplicaie interpretate, urmtoarea direcie de cercetare.
ISO 14258
Obiectivul principal al standardului ISO 14258 [203] a fost de a defini concepte i reguli pentru
modelarea ntreprinderii i de a oferi direcii si constrngeri pentru oricine ncearc s modeleze o
ntreprindere sau procesele ei.
Conform standardului, exist trei metode prin care modelele pot fi legate ntre ele pentru a
dezvolta interoperabilitatea: integrat, unificat, federal.
n metoda integrat diverse modele sunt interpretate conform unui ablon comun. Modelele
standard sau referin trebuie s fie la fel de bogate ca i modelele constitutive. Toate modelele
pot fi ntr-un format standard, cu informaia filtrat sau translatat de aplicaii. ablonul comun
100
nu trebuie s fie neaprat un standard. El poate fi agreat de toate prile care elaboreaz modele i
construiesc sisteme.
Abordarea unificat presupune existena unui ablon comun ce ofer o structur comun la un
meta-nivel care ofer mijloacele stabilirii echivalenei semantice. ablonul reprezint baza pentru
un meta-model care s permit translatarea dintr-un model n altul. ablonul nu este executabil.
Pierderi de semantic sunt posibile.
n cadrul abordrii federative nu exist un ablon comun. Modelele trebuie luate ca atare, aa cum
sunt ntlnite. Pentru a stabili interoperabilitatea, prile implicate trebuie s ajung pe loc la un
acord, ntr-un mod dinamic, fr a exista un ablon predefinit.
ISO 15745
ISO 15745 [204] const n patru pri: (1) Descrierea general; (2) Descrierea de referin pentru
sisteme de control bazate pe standardul ISO 11898; (3) Descrierea de referin pentru sisteme de
control bazate pe standardul IEC 61158; (4) Descrierea de referin pentru sisteme de control
Ethernet.
Standardul propune un set de elemente i reguli pentru descrierea profilelor de interoperabilitate
la nivel de aplicaie. Elementele i regulile generice ofer abloane pentru dezvoltarea unor
profile de interoperabilitate la nivel de aplicaie (AIP Application Interoperability Profiles)
precum i la nivel de proces, resurse, schimb de informaie. Standardul este aplicabil pentru cadre
de integrare a aplicaiilor n domeniul automatizrii industriale.
ISO 16100
ISO 16100 [205] este compus i el din patru pri: (1) Cadrul de modelare ; (2) Metodologia de
profilare; (3)Interfeele pentru servicii, abloane pentru protocoale i capabiliti; (4) Metode,
criterii i rapoarte pentru teste de conformitate.
Standardul propune un cadrul de modelare pentru realizarea interoperabilitii ntre diferite
produse software folosite n domeniul de fabricaie. Cadrul de modelare adreseaz modele pentru
schimbul de informaie, obiecte software, servicii, etc. Standardul ofer i o metodologie pentru
construcia profilelor capabilitilor softurilor de fabricaie.
ISO 19440
Standardul ISO 19400 (2004) [206] propune structuri pentru modelarea ntreprinderii: semantic
comun pentru unificarea modelelor, poate fi folosit pe parcursul ntregului ciclu de via al
dezvoltrii modelelor, suport o abordare orientat proces. Standardul propune organizarea i
specializarea n funcie de scop, folosind abloane. Nu sunt permise maprile intre operaiile
funcionale i capabiliti. Nu este prezent un mecanism de versionare.
2.3.4. Concluzii
n paragraful curent am prezentat evoluia sistemelor informaionale de la EAI ncepnd cu
CIMOSA, GRAI-GIM, PERA, Zachmann, GERAM, EIS i continund cu: LISI, IDEAS, EIF i
ATHENA. Am identificat i discutat standarde privind interoperabilitatea. n continuare este
formulat problema de rezolvat.
101
2.4. FORMULAREA PROBLEMEI DE REZOLVAT
2.4.1. Identificarea problemei la nivel de ntreprindere
Avansul i inovarea tehnologic, globalizarea, apariia de noi modele de afaceri, dezvoltarea unei
piee unice Europene, schimbrile majore n cererea consumatorilor, schimbrile economice
determin ntreprinderile i personalul angajat s fie capabile i pregtite s se adapteze continuu.
n ceea ce privete organizaiile, acestea trebuie s-i adapteze operaiunile la condiiile

economice curente sau emergente i s i gestioneze fora de munc ntr-un mod ct mai flexibil.
Sunt necesare produse i servicii inovative, un management eficient al companiei, o abordare
creativ n ceea ce privete managementul resurselor umane pentru ca organizaia s aib succes
ntr-un mediu n permanent schimbare.
Fora de munc adaptiv este reprezentat de angajaii care au dobndit cunotine transferabile,
ceea ce le permite s ocupe diferite roluri profesionale n cadrul ntreprinderii sau n afara ei, dac
este necesar.
Anticiparea, restructurarea i managementul schimbrii au devenit subiecte de interes maxim pe

agenda companiilor i a autoritilor.
Datorit pieelor turbulente, n momentul actual companiile se confrunt cu o problem legat de

schimbarea continu contextului de afaceri. Schimbrile din mediul de afaceri duc la schimbri n
procesele de afaceri ale organizaiilor, la nivel de aplicaii informatice, la nivel de date, etc. Ca
exemplificare, au fost luate n considerare cteva domenii cum ar fi: industria farmaceutic,
industria productoare de automobile, industria petrochimic.
n domeniul industrie farmaceutice, considerm un productor de medicamente care dorete s

dezvolte i s introduc pe pia un nou medicament de combatere al gripei i rcelii. Pentru
cercetarea i producerea medicamentului dorit compania are nevoie de parteneri ce posed
abiliti diferite: centre de cercetare, spitale, farmacii. Partenerii ce fac parte dintr-o reea
colaborativ se constituie ntr-o organizaie virtual care pe durata ciclului de via al
medicamentului va suferi numeroase modifcri. n anumite etape ale producerii medicamentului
este nevoie cu predilecie de centre de cercetare, n alte etape de spitale sau de farmacii. Pentru a
putea colabora cu diferiii parteneri, productorul de medicamente trebuie s se adapteze n
permanen. Productorul este de asemenea nevoit s se adapteze chiar i la condiiile oferite de
mediul de afaceri n care i desfoar activitatea, deoarece se afl n competiie cu ali
productori de medicamente. Pentru a se adapta uor, productorul de medicamente trebuie s fie
eficient n procesul de schimbare.
n industria productoare de automobile, considerm un productor de automobile. Principalul
su furnizor de cabluri electrice ntmpin probleme n procesul de producie i nu poate s
livreze componentele necesare. Productorul de automobile trebuie s-i schimbe procesul de
producie pentru a se adapta noii situaii. Un alt furnizor poate fi gsit. n acest caz productorul
de automobile trebuie s se adapteze pentru a putea colabora cu noul furnizor.
102
n industria petrochimic, un productor de carburant decide s schimbe procesul de rafinare al

petrolului pentru a obine un carburant cu cifra octanic mai mare. Schimbarea aceasta afecteaz
direct distribuitorii care trebuie s revizuiasc procesul de stocare i transport al carburantului.
Aa cum se poate observa pe baza celor trei exemple selectate, ntreprinderile sunt interconectate
ntre ele. O schimbare n mediul unei ntreprinderi afecteaz ntreprinderile cu care aceasta
colaboreaz direct, derivnd astfel o nevoie de adaptare. Este nevoie de o metod, un cadru de
modelare pentru implementarea procesului de management al schimbrii la toate nivelele
organizaiei.
2.4.2. Formularea propriu-zis a problemei
Pentru a fi eficiente n procesul de adaptare, organizaiile au nevoie de o modalitate holistic de a

descrie, monitoriza i evalua impactul schimbrilor la diferite niveluri ale organizaiei.
Nevoia de schimbare este identificat pe baza criteriilor de management al schimbrii.
Schimbrile sunt determinate de diferii factori externi sau interni organizaiei. O trecere n
revist a diferii factori ce determin schimbarea relev impactul acestora asupra organizaiei:
Schimbarea metodologiei de producie - Procese i tehnici
Oamenii - Procese/ structura organizaional, etc.
Structura organizaional - ntreaga organizaie
Cumprtorul - Produsele oferite, metodologia de producie, procese
Furnizorul - Procesele n cadrul organizaiei
Partener n cadrul unei reele colaborative/organizaii virtuale - Procesele n cadrul organizaiei
Ameninarea produselor de substitut - Produsele oferite, posibil metodologia de producie
Ameninarea noilor intrai - Tehnologiile folosite
Rivalitatea ntre organizaiile existente - Organizaia efectueaz modificri de pre, modificri

n politica de marketing, mbuntirea calitii
produselor, introducerea unor noi produse
Factori politici - Strategia organizaiei, procesele n cadrul organizaiei
Factori economici - Strategia organizaiei
Factori socio-culturali - Strategia organizaiei
Factori tehnologici - Procesele interne ale organizaiei, nivelul de date
Este necesar ca pe baza strategiei organizaiei i a factorilor descrii s se specifice o metod de

aplicare a managementului schimbrii n cadrul organizaiei.
103
Este necesar definirea unui set de indicatori cheie de performan pentru evaluarea efectului
schimbrilor efectuate.
Este necesar de asemenea analiza i proiectarea unui cadru de modelare holistic al
managementului schimbrii organizaionale, care s ia n considerare diferitele niveluri ale
organizaie: nivel organizaie, nivel procese, nivel aplicaie, nivel date.
n capitolul urmtor este prezentat un astfel de cadru de modelare, care s rspund problemei
adresate. Pentru rezolvarea problemei, n paragraful urmtor a fost definit suportul formal.
2.5. SUPORT FORMAL PENTRU CUTAREA SOLUIILOR
Un sistem formal (teorie formal) este un ansamblu (, , , , , , ) unde:
este o mulime numrabil de simboluri, semnificnd vocabularul teoriei

este o mulime finit de simboluri, ale crei elemente sunt conective (2.1)
este o mulime finit de obiecte, numit simboluri de punctuaie
este o mulime finit de obiecte, numit cuantificatori
este o submulime ( ) a formulelor formate din mulimea tuturor
secvenelor finite, format cu elemente din ( )
este o parte a mulimii ale crei elemente sunt numite axiome
este o mulime finit de relaii pe mulimea , numite reguli de inferen
O teorie (sistem) formal se spune c este axiomatic, dac i exist posibilitatea de a

decide efectiv dac o formul este un element din .
Vom enuna n continuare cteva definiii istorice ale unui sistem formal:
1. Un sistem este un tot (whole) / ansamblu de entiti i relaiile dintre ele, care este
recognoscibil de ctre un observator al evoluiei lui (nu este construit de ctre observator,
care rmne n exteriorul anvelopei / suprafeei sistemului)
2. Un sistem este orice (felie de realitate modelabil) care nu este haos! (Kenneth
Boulding, 1995 - aforism)
3. Un sistem este o mulime de variabile, suficient de corect izolate (discriminate) care
rmn permanente (nonvolatile) un interval lung de timp de observare nct modelul
(sistemul) s fie persistent din punct de vedere al observatorului (Ross Ashly, 1990)
4. Un sistem este un set de uniti elementare care interacioneaz nct s formeze o
macroentitate integrat, cu scopul de a realiza o anumit funcie (orice structur care se
construiete pe tripleta: order, pattern, purpose i care este durabil n timp)
5. Un sistem este o colecie organizat de ageni umani, maini i materiale, necesar
realizrii unui scop specific, i care sunt legate prin relaii de comunicare.
6. Un sistem este o colecie de entiti inter-relaionate astfel nct att mulimea de entiti
i, respectiv, mulimea de relaii conduc mpreun la reducerea entropiei locale. Sistemul
genereaz proprieti globale emergente i are un scop specific realizabil prin ndeplinirea
unei anumite funcii (Derek Hitchins, 1992).
Structura unui sistem este aranjamentul subsistemelor i componentelor ntr-un spaiu
tridimensional ntr-un anumit moment de timp. Sistemele se difereniaz unul fa de celelalte
prin urmtoarele criterii:
104
modul cum sunt organizate

mecanismele particulare i dinamica inter-relaionrii prilor
mecanismele i dinamica interaciunii cu mediul exterior suprafeei anvelopei sistemului
Un sistem concret (numit sistem fizic) este un sistem care exist ca realitate fizic ntr-un spaiu
i timp i care este constituit din cel puin dou obiecte/uniti. Sistemele concrete sunt fie non-
vii (materiale) fie vii (biologice).
Un sistem organic este generat conform principiilor seleciei naturale i se caracterizeaz prin
dezechilibre termodinamice. Ele se caracterizeaz prin urmtoarele trsturi (autoreglare,
organizare, metabolism i cretere/descretere, capacitate de reacie, adaptabilitate, capacitate de
reproducere, capabilitate de dezvoltare).
Ca o observaie, un sistem deschis, organizat i complex este definit prin capacitatea sa pentru
autopoesis (Maturano i Varela, 1974) definit ca o proprietate de auto-rennoire (self-
renewing) - ceea ce permite sistemelor vii s fie autonome (metabolism, reparabilitate, cretere
i replicare).
Un sistem conceptual este un sistem de concepte, i este compus ca organizarea unui set de idei,
exprimate simbolic (entitile sunt cuvinte, numere, alte simboluri alfanumerice) dintr-un sistem
fizic (de exemplu: operaional uman). Sistemul nu conine variabile timp.
Un sistem abstract se definete ca o colecie n care toate elementele trebuie s fie concepte.
Sistemul deschis (toate sistemele vii) depinde de interaciunea cu mediul cu care schimb
materie, energie i informaie.
Analiza formal se refer la o gam larg de tehnici bazate pe instrumente care pot fi folosite
pentru a verifica specificaiile formale. Aceste instrumente pot calcula, rafina i chiar face
predicii n ceea ce privete comportamentul sistemelor specificate.
Un sistem formal const dintr-un set de primitive nevide, dintr-un set de iruri luate dintr-un
alfabet de simboluri, un set de axiome (enunuri considerate ca date ce implic primitivele) i un
set de reguli de inferen sau alte mijloace pentru a deriva teoreme. Axiomele i regulile de
inferen pot fi referite ca sistem deductiv. Setul de axiome mpreun cu toate teoremele
derivabile din acestea poart numele de teorii. Probarea unei teoreme ntr-un sistem formal se
reduce la o simpl serie de transformri conforme cu regulile de inferen ale sistemului.
Noiunea de probare este strict sintactic n aceast accepiune.
Noiunea de sistem formal schiat mai sus este pur sintactic i descrie un calcul neinterpretat.
Probarea teoriei poate fi descris ca studiul proprietilor pur formale sau sintactice ale unui
calcul neinterpretat, incluznd consistena, deductibilitatea, completitudinea simpl i
independena. Se poate spune despre un sistem c este consistent dac nu se poate deduce din
axiome att enunul ct i negaia acestuia. Un sistem formal S este simplu complet dac i
numai dac pentru fiecare formul bine format A, A poate fi probat sau disprobat n S. Se
poate spune despre un sistem c este complet dac se pot deduce toate teoremele care satisfac un
criteriu dat. Noiunea de independen se refer la faptul c toate axiomele mpreun cu regulile
de inferen ale unui sistem nu pot fi deduse din sistemul deductiv rmas.
Putem afirma despre un sistem formal S c este decidabil dac exist un algoritm ce poate fi
folosit pentru a determina dac o formul bine format sau nenchis este o teorem n S. De
asemenea, un sistem formal este simplu complet dac este consistent i dac orice formul
105
nchis, bine format este decidabil n S. Putem spune despre un sistem formal S c este semi-
decidabil dac exist un algoritm care s recunoasc o teorem a lui S. S este nedecidabil dac nu
este decidabil sau semidecidabil.
O interpretare const dintr-un domeniu al discursului i o reprezentare a acestuia care asigneaz
valori semantice sau coninut fiecrei formule bine formate ale calculului ca i fiecrui
constituent al unui astfel de enun. n cazul n care toate axiomele sistemului formal sunt
adevrate pentru o anumit interpretare, atunci aceasta devine un model pentru sistem. O
interpretare este un model pentru o teorie sau pentru un set de enunuri dac reprezint un model
pentru sistemul formal n care teoria sau seturile de enunuri au fost exprimate i toate enunurile
sunt evaluate ca adevrate pentru modelul respectiv.
Se poate defini spaiul strilor unui sistem ca un domeniu ce conine valorile variabilelor de stare
ale programului sau ale specificaiei ce-l descrie. Comportamentul pe care sistemul l poate avea
poate fi descris n termenii valorilor acestui domeniu. Comportamentele sistemului pot fi
enumerate n ntregimea lor dac spaiul strilor este finit i suficient de mic.
Metodele de stare finit refer tehnici pentru automatizarea verificrii sistemelor cu numr de
stri finit sau a sistemelor cu stri infinite care pot fi reduse prin folosirea unor simetrii sau
uniformiti. Pentru o formul dat care s descrie o proprietate dorit a sistemului metoda de
stare finit determin ntr-un model specific dac formula este adevrat sau fals.
Metodele formale utilizeaz tehnici ce in de matematicile discrete i logica matematic pentru
specificare, proiectarea i construirea unui sistem de calcul i a unui software de mari dimensiuni.
Termenul formal provine din logica formal. Logica formal implic metode de raionare
independente de coninut i valide din punct de vedere al formei lor. Aceste metode implic
enumerarea tuturor ipotezelor i a pailor raionamentului. La fiecare pas, un numr ct mai mic
de reguli de inferen trebuie instaniate. Obiectivele metodelor formale sunt reducerea apelrii la
intuiia uman pentru evaluarea argumentelor precum i justificarea cerinelor sau ale altor
aspecte ale proiectrii sau implementrii sistemelor. Metodele formale au aprut ca o aplicare a
logicii matematice i a matematicilor discrete la problemele legate de sistemele de calcul. Ele
ncorporeaz un model al calculaiei.
Metodele formale pot fi utilizate n mod analitic pentru determinarea consistenei interne a unei
descrieri, a consecvenei unei proprieti cu cerinele propuse, evaluarea comparativ a dou
proiecte. Tot acestea pot fi utilizate n mod descriptiv pentru clarificarea cerinelor, proiectarea la
nivel nalt, pentru a facilita comunicarea unei cerine sau a unui proiect.
Metodele formale pot fi clasificate n funcie de nivelul de formalizare i scopul formalizrii n:
concepte i notaii matematice, analiz informal ce nu implic mecanizare, folosite

pentru dezvoltarea proceselor existente, fr a impune revizuiri complete
limbaje de specificare formal n care apar elemente de suport mecanizat, folosite pentru
verificri sintactice, interpretoare. Acest nivel ofer suport din punct de vedere al
ingineriei software pentru dezvoltarea de interfee, module, tipuri de date abstracte i
obiecte
limbaje de specificare formal cu semantici riguroase ce includ verificarea automat a

demonstraiilor
106
Avantajele metodelor formale sunt reprezentate de concentrarea asupra cerinelor i subiectelor

de interes, fr a intra n detalii relativ la factorii implementrilor.
Aplicarea metodelor formale asupra unei aplicaii const n urmtoarele faze:
1. Faza de caracterizare presupune o nelegere a aplicaiei i a domeniului aplicaiei. n
aceast faz se realizeaz un studiu minuios al aplicaiei, componentelor,
subcomponentelor, interfeelor i algoritmilor eseniali, fluxului de control al datelor i
mediului operaional al aplicaiei.
2. Faza de modelare presupune definirea reprezentrilor matematice ce pot fi utilizate pentru
formalizarea domeniului aplicaiei i pentru a calcula i realiza predicii privind
comportamentul aplicaiei n contextul dat. Potenialele reprezentri matematice pot fi
evaluate considernd factori generali ca: expresivitatea, puterea analitic i simplicitatea
precum i factori specifici ca: modelul computaional utilizat, reprezentrile explicite sau
implicite ale strilor i timpului, instrumente mecanizate dac acestea exist. Tot n
aceast faz are loc selectarea reprezentrilor matematice care se dovedesc a fi cele mai
potrivite pentru aplicaie.
3. Faza de specificare presupune formalizarea aspectelor relevante ale aplicaiei. Este
dezvoltat strategia specificaiilor lund n considerare factorii ca ierarhici versus
specificarea pe un singur nivel, constructiv versus descriptiv.
4. Faza de analiz presupune validarea specificaiilor. Acestea sunt interpretate i executate,
invarianii i proprietile cheie sunt probate, se stabilete consistena axiomelor i
corectitudinea nivelurilor ierarhice.
5. Faza de documentare presupune nregistrarea ipotezelor operative n cazul n care acestea
exist, motivarea deciziilor critice, evaluarea efortului, colectarea de date privind costul
raportat la beneficii.
6. Faza de ntreinere i generalizare presupune modificarea specificaiilor pentru a realiza
predicii privind consecinele schimbrilor propuse sistemului modelat.
Cerinele definesc un set de condiii sau capabiliti ce trebuie satisfcute de un sistem sau o
component a acestuia pentru a satisface un contract sau standard. ntre cerine i metodele
formale exist o legtur strns acestea influenndu-se reciproc. Cerinele ce reprezint obiecte
ale analizei formale prezint urmtoarele puncte de interes: nivelul pe care au fost formulate,
gradul de explicitare, modul de prezentare, disponibilitatea pentru informaii i expertize
suplimentare. Prin aplicarea metodelor formale rezult produse tangibile: specificaii, analize ce
pot avea un impact asupra cerinelor asupra crora s-au aplicat.
Termenul de model are dou semnificaii n contextul metodelor formale. El poate fi utilizat
pentru a face referire la o reprezentare matematic a unui sistem natural pentru predicia i
calcularea proprietilor sistemului care este modelat. n acelai timp, termenul de model poate
face referire la o reprezentare matematic ce satisface un set de axiome consistente n sistem. n
contextul metodelor formale, modelele uzuale tind s fie reprezentri abstracte orientate pe
caracteristicile eseniale exprimate n termeni suficient de generali formalizai n instrumente
matematice bine alese. Printre avantajele modelelor matematice pot fi enumerate:
sunt mai precise dect o descriere informal, tinznd s foreze o analiz mai minuioas
107
pot fi utilizate pentru a calcula i realiza predicii asupra comportamentului sau

fenomenului modelat
pot fi analizate folosind metode ce in de raionamentul matematic

Modelele matematice se pot aplica domeniilor continue i discrete, dar i sistemelor discrete
compuse din entiti continue selectate, controlate, supravegheate de componente discrete.
Modelele funcionale reprezint modele ce utilizeaz noiunea matematic de funcie avnd ataat
de obicei un model al calculaiei simplu i implicit. Aceasta permite descrierea unui numr mare
de algoritmi utiliznd funcii recursive folosind operaiile componentelor funciei. Avantajul
principal al utilizrii modelelor funcionale este faptul c se pot realiza rapid prototipuri.
Mainile abstracte (State machines) constau ntr-o reprezentare abstract a strilor sistemului i
dintr-un set de operaii care acioneaz asupra strilor pentru a efectua tranziii din starea curent
n starea urmtoare. Tranziia ntr-o main abstract de stare reprezint o funcie matematic
bine definit care pe baza unor valori de intrare i a unor stri curente va produce valorile de
ieire i valori ale strilor urmtoare. Dac reprezentm att valorile de intrare ct i cele de ieire
ca nite vectori, I fiind mrimile de intrare, O fiind mrimile de ieire, S fiind mulimea strilor,
atunci tranziia T poate fi reprezentat ca o funcie:
: [ ] (2.2)
Ideea de baz n cazul mainilor abstracte de stare este c un sistem de control poate fi modelat ca
o funcie de control la care se adaug starea. Sistemul evolueaz n timp. La fiecare iteraie sau
instaniere sistemul va citi valoarea unei variabile monitorizate, consult variabilele strii n care
se afl i produce perechea de rezultate: valoarea noii variabile monitorizate i valoarea noii stri.
Automatele de stare pot fi deterministe cnd exist o tranziie unic dintr-o stare n alta sau
nedeterministe atunci cnd putem avea zero sau mai multe tranziii dintr-o stare n alta. Un
automat determinist poate fi definit ca un tuplu (, , , 0 , ) unde S este un set finit de stri,
alfabetul de intrri , 0 este starea iniial, setul de stri finale, iar funcia de tranziie
ntre i . Un automat nedeterminist este de asemenea definit ca un tuplu (, , , 0 , )
singura diferen fiind dat de care face tranziia ntre i mulimea submulimilor lui i
este scris ca ().
Modelele orientate obiect reprezint sistemele ca pe colecii structurate de clase i obiecte cu
noiuni explicite de ncapsulare , motenire i relaii ntre obiecte. Ca metodologii de proiectare i
analiz informal orientat obiect pot fi amintite UML (Unified Modeling Language), BPMN
(Business Process Model and Notation) i BPEL (Business Process Execution Language). Prin
intermediul acestei metodologii o aplicaie poate fi structurat pe baza unor reprezentri de
diagrame multiple a sistemului de baz. n cadrul acestei abordri, clasele de obiecte sunt legate
de limbaje de programare orientate obiect i de teoria specificaiilor algebrice.
Spre deosebire de automatele de stare care sunt neintuitive pentru utilizatorul nespecialist, o
metod mult mai compact i modular de reprezentare a sistemelor de tip evenimente discrete o
constituie Reelele Petri (RP). Reelele Petri asigur un mediu uniform pentru modelarea, analiza
formal i proiectarea sistemelor cu evenimente discrete. Alte avantaje oferite de RP sunt
108
reprezentate de faptul c pot fi folosite pentru modelarea unor proprieti ca: sincronizarea
proceselor, operaii concurente, rezolvarea conflictelor, partajarea resurselor. Ca instrument
grafic, [207], RP permit reprezentarea ntr-un mod grafic a cerinelor complexe, ntr-un mod uor
de neles de utilizator. De asemenea, ele permit simularea grafic interactiv. Reelele Petri pot
fi clasificate n funcie de semnificaia jetoanelor care alctuiesc marcajul reelei n: RP de nivel
redus (RP ordinare, RP cu temporizare determinist, etc.)[208], [209] i RP de nivel nalt (RP
colorate, RP de timp real, RP cu tranziii fuzzy [210]).
O Reea Petri este un cvintuplu = (, , , , 0 ) n care:

= {1 , 2 , } este mulimea finit a poziiilor sau locaiilor;
= {1 , 2 , } este mulimea finit a tranziiilor, unde = ;
( ) ( )este mulimea arcelor orientate; (2.3)
: {1,2,3, } este funcia de ponderare a arcelor;
0 0 este marcajul iniial.
Dac o poziie p este att poziie de intrare, ct i poziie de ieire pentru o tranziie t, atunci p i t
formeaz o bucl autonom. O reea Petri care nu conine bucle autonome se numete pur. Dac
toate arcele unei RP au pondere unitar atunci RP se numete ordinar. Dac cel puin un arc al
RP are pondere mai mare dect 1, atunci RP se numete generalizat.
Un marcaj atribuie unei poziii p un numr de jetoane mai mare sau egal cu 0. Dac un marcaj
atribuie unei poziii p ntregul k mai mare sau egal cu 0, atunci p este marcat cu k jetoane.
Poziiile unei RP pot conine oricte marcaje, dac nu sunt fcute precizri care s specifica
contrariul.
Prin modificare marcajului(regula tranziiei) este asigurat dinamica RP. O tranziie t este
validat dac fiecare poziie de intrare (predecesor) p a lui t este marcat un numr de jetoane
cel puin egal cu ponderea arcului de la p la t. O tranziie validat poate sau nu s fie executat
sau declanat, dac evenimentul asociat tranziiei are sau nu loc. Executarea unei tranziii
validate ndeprteaz W ( p, t ) jetoane din fiecare poziie de intrare (predecesor) p a lui t i adaug
W (t , p ) jetoane la fiecare poziie de ieire (succesor) p a lui t, unde W (t , p ) este ponderea arcului
de la t la p.
O tranziie fr nici o poziie de intrare se numete tranziie surs. Executarea ei produce

jetoane. O tranziie fr nici o poziie de ieire se numete tranziie receptor. Executarea unei
tranziii receptor consum jetoane.
Semnificative pentru aceast lucrare sunt RP interpretate, acestea fiind n continuare descrise pe
larg.
ntr-o RP interpretat, o tranziie poate avea asociate evenimente i/sau condiii logice, situaie n
care tranziia este executat dac este valid i dac este ndeplinit condiia logic asociat n
momentul n care are loc un eveniment. Atunci cnd un marcaj este adugat unei poziii (ca
urmare a execuiei uneia dintre tranziiile sale de intrare), anumite operaii, care pot fi asociate
poziiei n mod explicit (modificarea unei variabile de stare globale, generarea unui eveniment,
etc.) sunt efectuate, iar marcajul poate fi indisponibil pentru o perioad de timp (pentru a permite
execuia tranziiei urmtoare) dac poziia respectiv este temporizat, adic dac are asociat o
durat (de indisponibilitate). Modelul de RP interpretate a fost introdus de M. Moalla. Pe baza
109
acestui model, David i Alla [211] au propus pe baza unor extensii i restricii un model de RP
interpretate de conducere/control (Controlled Interpreted Petri Nets). David i Alla folosesc
semantica server-ului infinit. Dac q marcaje sunt adugate simultan ntr-o poziie de ctre o
tranziie, ar trebui executat tranziia asociat cu aceast poziie de q ori? Aceast ntrebare nu
apare n cazul RP sigure(al cror marcaj este l-mrginit). Retelele Petri interpretate permit
modelarea si simularea interaciunilor ntre mai multe procese care se sincronizeaz prin
evenimente (generarea evenimentelor asociate tranziiilor unui proces reprezint operaii asociate
poziiilor celuilalt).
Modelele bazate pe timp sunt mai importante pentru evaluarea performanei dect pentru control.
Modelul de RP prezentat nu este temporizat.
RP interpretat de control primete informaii de la mediul nconjurtor (sistemul controlat,

operatorul uman sau alte RP interpretate de control) sub forma unor variabile de tip boolean i a
unor evenimente. RP interpretat de control trimite informaii ctre mediul nconjurtor(variabile
de tip boolean), impulsuri, evenimente n funcie de schimbarea de marcaj i variabile ce rezult
n urma unui calcul.
n interiorul RP interpretate de control, partea de control poate trimite ordine de iniiere a

operaiilor ( ) i primete informaii de tip boolean de la partea de procesare a datelor (0 ).
Modelul presupune efectuarea unui calcul nu are durat relevant: rezultatul este disponibil
imediat. Figura 2.11a prezint o parte a unei RP interpretat de control. Intrrile sunt asociate cu
tranziii iar ieirile sunt asociate cu poziii. Evenimentul i condiia sunt asociate cu
tranziia . Condiia este o funcie de tip boolean ce depinde de partea de procesare a datelor
i de mediu. Evenimentul poate fi un eveniment extern declanat de mediu sau un eveniment e
ce apare n mod regulat.
Tranziia va fi executat dac este valid i condiia este adevrat atunci cnd are loc
evenimentul .
Produsul = poart numele de receptivitatea tranziiei . Dac este valid, ea va fi

receptiv la . Dac este valid iar condiia este adevrat, tranziia este receptiv la
evenimentul .
Aa cum se poate vedea n figura 2.11b, aciunile reprezentate de , , sunt asociate cu

poziia . Cnd un jeton este depozitat n poziia la momentul , operaia este executat iar
evenimentul generat prin execuia aciunii este trimis ctre exterior. Variabila boolean de
ieire are valoarea adevrat att timp ct exist un jeton n . Ieirile de tip eveniment ,
sunt marcate cu asterisc deoarece n acest caz sunt abstracte.
110
Fig. 2.11. RP interpretat de control [211]
Revenind, specificaiile formale reprezint caracterizri ale unui sistem existent sau planificat
exprimate ntr-un limbaj formal. O caracterizare const de obicei ntr-o colecie de axiome i
definiii ale cror sensuri i consecine sunt determinate de limbajul formal i regulile sale de
inferen.
Un limbaj formal de specificare este format dintr-o colecie de simboluri ce formeaz un alfabet
i un set de reguli sintactice, ce determin combinaiile de simboluri care reprezint o expresie
valid n limbaj. Cele mai multe limbaje formale utilizeaz logica tradiional: calculul
propoziiilor i calculul predicatelor. Cele mai multe limbaje de specificare sunt acceptate de
instrumente de analiz sintactic mecanizat iar o parte dintre ele sunt folosite de instrumentele
de analiz semantic pentru deductivitate. Ele au fost dezvoltate iniial pentru a fi utilizate n
formalizarea cerinelor, a algoritmilor i a programelor si pentru a reprezenta o baz pentru
raionamentele n aceste domenii. Limbajele de specificare formal trebuie s aib o baz
matematic solid pentru buna definire i credibilitate matematic a specificaiilor, dar i pentru a
furniza un cadru standard pentru nelegerea specificaiilor. n mod ideal, limbajul ar trebui s
aib o semantic formal complet. Cele mai multe limbaje de specificare formal vor adopta
tipuri de date din limbajele de date familiare precum i tipuri de date abstracte. Sintaxele utilizate
au n vedere familiarizarea i uurarea expresiei precum i utilitatea pentru documentare i
punerea la zi.
Tipizarea tare reprezint un capital semnificativ al limbajelor de specificare precum i al
limbajelor de programare. Limbajele de specificare se deosebesc de cele de programare prin
faptul c pot avea o mulime de tipuri sistem mai bogat. Un verificator de tipuri reprezint un
program ce valideaz consistena tipurilor, detectnd defectele, inconsistenele i omisiunile.
111
Funciile totale mapeaz toate elementele domeniului pe elemente din codomeniul lor. Funciile
pariale mapeaz numai o parte din elementele domeniului lor pe elemente din codomeniu,
celelalte rmnnd nedefinite.
O specificaie const ntr-o colecie de axiome i definiii. Axiomele se aplic unor entiti noi
sau deja existente. Definiiile sunt axiome restrnse la definirea de concepte noi n termenii
conceptelor deja existente. Unele limbaje de specificaie limiteaz axiomatizarea arbitrar altele
asigur puin sau deloc faptul c definiiile sunt bine definite.
Limbajele de specificare conin de asemenea mecanisme care asigur monitorizarea i
ncapsularea. Exist de asemenea i mecanisme care accept i parametrizarea modulelor.
Stilul specificaiilor are implicaii variate n funcie de orientarea sa: descriptiv sau constructiv.
Stilul constructiv este asociat cu utilizarea definiiilor, n vreme ce stilul descriptiv este asociat cu
utilizarea axiomelor. Stilul descriptiv ncurajeaz o specificare abstract, pe cnd stilul
constructiv furnizeaz un numr ct mai mare de detalii i particulariti. Specificaiile
descriptive pot introduce inconsistene, fiind greu de neles de un cititor mai puin avizat.
Deoarece folosirea celor dou stiluri ar putea fi judicioas pentru unele aplicaii, este de preferat
s fie utilizate specificaii descriptive pentru nivelul de vrf al specificaiei, urmnd s fie
introduse pentru nivelurile inferioare specificaii constructive.
Specificaiile formale pot fi integrate cu dezvoltarea sistemului prin construirea unei ierarhii de
specificaii pe diferite nivele. Fiecare nivel corespunde cu o faz a ciclului de via al produsului,
referind sau fiind elaborat cu ajutorul nivelului precedent. Prin utilizarea probrii formale se
poate stabili c fiecare nivel al proiectrii este o implementare corect a nivelului precedent.
Probarea formal se face cu ajutorul unor funcii care relaioneaz obiectele de pe un nivel cu
obiectele de pe nivelul anterior, probnd c relaia se pstreaz pentru toate execuiile posibile.
Utilizarea specificaiilor formale este eficient din punct de vedere al costurilor dar i funcional
n prima parte a ciclului de via al sistemului.
Specificaiile formale pot conine erori datorate:
subspecificrii - incompletitudinii specificaiilor

supraspecificrii - enunuri prea detaliate care pot genera limitri ce nu sunt necesare
pentru celelalte cicluri de via
inconsistenei interne
Supraspecificarea este greu de detectat prin mijloace mecanizate. Celelalte tipuri de erori pot fi
detectate manual sau prin instrumente mecanizate.
Inspecia este folosit pentru a detecta manual toate tipurile de erori enumerate. Nu este la fel de
eficient ca inspecia cu instrumente mecanizate pentru detectarea de erori subtile cum ar fi:
inconsistene logice, erori de sintax, implicaii nedorite.
Parsarea este o form de analiz care detecteaz inconsistenele sintactice. Parsarea va determina
doar dac specificaiile sunt conforme cu regulile sintactice ale limbajului de specificare.
Verificarea tipurilor este o form de analiz ce detecteaz inconsistenele semantice sau
anomaliile.
112
Execuia permite simularea specificaiilor n cazul n care acestea au fost realizate ntr-un limbaj
formal de specificare direct executabil.
Probarea teoremelor i verificarea modelului sunt utilizate pentru detectarea anomaliilor logice i
a nepotrivirilor dintr-o specificaie formal. Validarea specificaiilor formale urmrete
consistena intern a acestora, semnificativitatea i completitudinea.
Specificaiile formale pot servi mai multor scopuri. O funcie important a specificaiilor formale
este calcularea, predicia i testarea comportamentului sistemului. Specificaiile formale pot avea
un rol descriptiv ce va furniza o baz pentru documentare. O alt funcie a specificaiilor formale
este reprezentat de clarificarea cerinelor i a proiectului de nivel nalt prin specificarea unui
enun concis i neambiguu relativ la cerinele fundamentale i proiectul de baz. De asemenea,
formalismele pot ajuta la exprimarea clar a ipotezelor implicite. Procesul de formalizare va
expune defectele semnificative din specificaie i de asemenea va duce la identificarea excepiilor
2.6. CONCLUZII
n acest capitol am descris i analizat paradigmele reprezentate de integrarea i interoperabilitatea

la nivel de ntreprindere prezentnd evoluia sistemelor informatice de la EAI i pn la
sistemele evoluate FInES. Am identificat factorii eseniali ce determin nevoia de schimbare n
cadrul organizaiilor ce fac parte din reele colaborative. Am identificat nevoia unui cadru holistic
de modelare al managementului schimbrii la toate nivelurile organizaiei. Suportul formal folosit
pentru rezolvarea problemei identificate este reprezentat de specificaiile formale pentru testarea
i predicia comportamentului sistemelor, precum i de reelele Petri interpretate folosite pentru
modelarea proceselor bazate pe servicii n cadrul organizaiei.
113
CAPITOLUL 3
CONFIGURAREA DINAMIC A METASISTEMULUI N CARE

ENTITILE / NODURILE REELEI SUNT BAZATE PE
REELAREA / RELAIONAREA PRIN INTERNETUL VIITORULUI
ORIENTATE ORGANIZAIONAL PE MODELUL COLABORATIV
3.1. CICLUL DE VIA AL UNEI ORGANIZAII VIRTUALE

Ciclul de via al unei organizaii virtuale este compus din trei etape eseniale: (i) crearea VO;
(ii) punerea n funciunea, managementul i evoluia VO; (iii) dizolvarea VO. Pentru fiecare
etap a ciclului de via pot fi identificate procese colaborative, conform tabelului 3.1.
Tabel 3.1. Etapele ciclului de via ale VO [6]
Crearea VO Punerea n funciunea, Dizolvarea VO

managementul i evoluia VO
- Identificare oportunitii de - Punerea n funciune a VO - Motenirea VO
afacere - Guvernana operaional a - Evaluarea partenerilor
- Selectarea indicatorilor de VO - Managementul proprietii
performan - Managementul dinamic al intelectuale
- Cutarea partenerilor VO - Anularea accesului
- Selectarea partenerilor - Msurarea performanelor - Aspecte legale
- Negocierea i analiza VO - Recompensarea membrilor
riscurilor - Supervizarea proceselor de VBE
- Planificarea VO afaceri
- Luarea deciziilor ntr-un mod
colaborativ
- Simularea VO
3.2. DEFINIREA CONCEPTULUI DE MEDIU DE CRETERE / EVOLUIE AL

ASOCIERII ENTITILOR DINTR-UN METASISTEM N CARE ENTITILE /
NODURILE REELEI SUNT BAZATE PE REELAREA / RELAIONAREA PRIN
INTERNETUL VIITORULUI I ORIENTATE ORGANIZAIONAL PE UN MODEL
COLABORATIV
Considernd complexitatea VBE, orice ncercare de a defini formal aceast paradigm i de a
descrie infrastructura sa trebuie s ia n considerare mai multe dimensiuni i perspective ale
sistemului. Aceste dimensiuni trebuie s acopere pe ct de mult posibil toate caracteristicile
114
cunoscute i aspectele VBE, indiferent de natura lor. n [6] au fost identificate 4 dimensiuni
aproape ortogonale ale cadrului referin de modelare al VBE:
Dimensiunea structural : cuprinde structura conceptual a rolurilor i funciilor actorilor

VBE (roluri, drepturi, responsabiliti, ndatoriri asociate fiecrui membru al VBE)
Dimensiunea fizic: entiti, materiale, resurse fizice disponibile n cadrul VBE

reprezentate de organizaii sau aparinnd sistemului de management VBE (maini,
reelistic, personal, cunotine).
Dimensiunea secvenelor de activiti: activiti, proceduri, procese legate de coordonarea

i managementul ciclului de via al VBE.
Dimensiunea ce cuprinde regulile de comportament n cadrul VBE: politici i reguli de

guvernan (principii de interoperabilitate, politici de conduit, politici de rezolvare a
conflictelor).
Fiecare dimensiune reprezint un aspect specific/perspectiv a mediului complex al VBE.
Cele patru dimensiuni pot fi extinse cu o vedere sistemic. Cea de-a cincea dimensiune este
reprezentat de VBE ca un metasistem, si anume sistem de sisteme complex adaptive dispersat
geografic cu geometrie variabil. Pornind de la definiia VBE prezentat n 1.3 pot fi
identificate cerinele pentru urmtoarea generaie de VBE. Acestea trebuie s aplice eficient
infrastructuri ICT, instrumente i servicii pentru a oferi mijloacele necesare
interaciunii/colaborrii organizaiilor, s faciliteze configurarea i crearea de VO, s ofere
asisten pentru evoluia VO, s introduc noi abordri i mecanisme pentru construirea
ncrederii, definirea unei culturi colaborative, stabilirea unor sisteme de valori comune i a
principiilor de lucru/partajare a resurselor i cunotinelor ntre organizaii independente. Aceast
a doua generaie de VBE este un model/cadru de modelare bazat pe soluii organizaionale
evoluate (tip cluster, living lab, etc.) pentru asocierea entitilor eterogene ca precondiie de
punere n comun a resurselor: umane, tehnologice, financiare, etc. pentru atingerea unui scop
comun reprezentat de un set de indicatori cheie de performan, printre care pot fi enumerai:
profitabilitate maxim, satisfacerea specific (one-of-a-kind), eficiena folosirii resurselor,
acoperirea expertizelor competenelor profesionale. Scopul final este creterea potenialului
concurenial al unei companii mai, mici sau mijlocii, micro-ntrepridere care s evolueze ntr-un
ecosistem de afaceri (dinamic, turbulent, n curs de globalizare).
115
Fig. 3.1. Cadru referin de modelare al VBE
3.3. CADRU DE MODELARE PENTRU MANAGEMENTUL ORGANIZAIONAL

AL METASISTEMULUI N CARE ENTITILE / NODURILE REELEI SUNT BAZATE
PE REELAREA / RELAIONAREA PRIN INTERNETUL VIITORULUI ORIENTATE
ORGANIZAIONAL PE MODELUL COLABORATIV SUB PRESIUNEA
PERTURBAIILOR ENDOGENE I EXOGENE
Procesul complet de management al schimbrii const n patru etape majore: [212] (i)
identificarea nevoii de schimbare, (ii) evaluarea costurilor i a timpului necesar pentru a face
schimbarea, (iii) punerea n aplicare i gestionarea modificrile solicitate, i n cele din urm, (iv)
evaluarea rezultatelor schimbrii (revizuirea rezultatelor schimbrii privind calitatea serviciilor).
Prin punerea n aplicare a procesului de schimbare, o organizaie va fi capabil s monitorizeze i
controleze schimbrile ce au loc.
Schimbrile pot avea diferite scopuri. n unele situaii ele pot afecta doar anumite pri ale unei
organizaii. n alte situaii ntreaga organizaie poate fi afectat [213]:
Adaptarea: o schimbare incremental care are loc ca rspuns la o schimbare n mediul
extern (aciuni ale competitorilor, noi tehnologii, schimbri ale nevoilor pieei). Acest tip
de schimbare nu implic modificri fundamentale n cadrul organizaiei.
Reglare fin: o schimbare incremental fcut pentru a anticipa evenimente viitoare. Are
ca scop mbuntirea eficienei, dar nu apare ca rspuns la o problem imediat.
116
Reorientarea: o schimbare strategic fcut ca urmare a anticiprii evenimentelor externe

ce vor necesita n cele din urm schimbri.
Re-crearea: Este o schimbare strategic impus de evenimentele externe ce amenin de
obicei existena organizaiei. Aceste schimbri presupun o ndeprtare de trecut i constau
n schimbri la nivelul leadership-ului, valorilor, strategiei, culturii organizaionale.
Strategia organizaional este un termen folosit pentru a referi felul n care o organizaie
trebuie s evolueze de-a lungul timpului pentru a-i atinge obiectivele. Necesitatea de
schimbare este identificat pe baza criteriilor de management al schimbrii ce sunt aliniate cu
strategia organizaiei(figura 3.2).
117
Fig. 3.2. Cadrul de modelare pentru managementul schimbrii organizaionale
118
3.4. METODA DE REZOLVARE PROPUS

Metoda utilizat pentru implementarea managementului schimbrii presupune parcurgerea
urmtorilor pai.
P1. Identificarea factorilor ce genereaz Managementul Schimbrii
n condiiile unei piee turbulente, organizaiile trebuie s se transforme pentru a supravieui.

Schimbri rapide au loc datorit a numeroase motive. Organizaiile trebuie s identifice factorii
ce determin nevoia de schimbare i s efectueze paii necesari pentru a implementa procesul de
schimbare potrivit. Aceti factori pot fi mprii n dou mari categorii:
factori interni organizaiei
factori externi organizaiei

Factorii interni organizaiei se afl sub controlul acesteia (n cadrul organizaiei). Deoarece se
afl sub controlul managementului organizaiei, ei pot fi gestionai mai uor. Cu toate acestea, ei
nu trebuie subestimai, iar managementul ar trebui s le acorde atenia potrivit.
Factorii externi organizaiei ce determin schimbri nu se afl sub controlul managementului
organizaiei.
n tabelul 3.2 vor fi prezentate categoriile de factorii ce determin schimbri, mpreun cu o
scurt descriere a acestora [214], [215] [216].
Tabel 3.2. Factori ce determin schimbri n cadrul organizaie
Tip Factori Descriere

Modificarea mrimii
Mrimea organizaiei organizaiei necesit o scalare
la nivel operaional
Schimbrile la nivelul
metodologiei de producie pot
afecta modul n care
Metodologia de producie
organizaia i desfoar
activitatea n mediul de
afaceri
Schimbrile de
Factori interni
leadership/personal pot
determina schimbri n cadrul
Oamenii organizaie. De ex., un nou
manager poate conduce
afacerea ntr-un mod diferit
fa de managerul anterior.
Schimbrile structurale n
ierarhia organizaional pot
Structura organizaional
afecta ntregul proces de
afaceri.
119
Cumprtorul Dac importana clientul este

mare, organizaia se va adapta
la nevoile acestuia, iar
clientul are puterea s
schimbe organizaia n modul
dorit prin cumprarea sau
refuzarea produselor.
Furnizorul Dac furnizorul are o
importan mare, acesta va
avea puterea s foreze
organizaia s schimbe
ntregul proces de afaceri prin
modificarea preului
materialelor, schimbarea
perioadei de creditare,
.a.m.d.
Ameninarea Aceast ameninare poate
produselor de fora organizaia s opereze
substitut schimbri n produsele oferite
pentru a le diferenia de
celelalte produse de pe pia
Factori
Ameninarea Ameninarea organizaiilor
specifici
noilor intrai nou intrate pe pia va face
mediului de
companiile s creeze bariere
Factori externi afaceri al
prin adoptarea de noi
organizaiei
tehnologii, construirea unei
loialiti bazate pe brand,
fcnd investiii masive.
Acestea vor determina
schimbri n strategia de
afaceri.
Intrarea/prsirea Prin intrarea sau ieirea unui
organizaiei membru din organizaia
virtuale de un virtual celelalte organizaii
membru trebuie s-i reproiecteze
procesele pentru a se adapta
noii situaii.
Rivalitatea ntre n condiiile unei concurene
organizaiile acerbe, organizaiile sunt
existente forate s fac anumite
schimbri (modificri de pre,
modificri n politica de
marketing, mbuntirea
calitii produselor,
introducerea unor noi
produse)
Factori Legislaia i Un exemplu privind legislaia
politici regulamentele, ar putea fi politica
120
stabilitatea i guvernamental dintr-un

tipul guvernului anumit stat privind reciclarea
(democratic, deeurilor. Companiile
monarhic, trebuie s minimizeze
dictatorial), impactul asupra mediului
politica nconjurtor al produselor
economic a dezvoltate.
guvernului,
evenimentele
diplomatice n
rile vecine
Factori Impactul Recesiunea are un impact
economici recesiunii asupra direct asupra cumprtorilor
organizaiei i implicit asupra
organizaiilor productoare
Factori socio- Gusturile i Societatea se afl n continu
culturali moda, schimbare. Gusturile i moda
satisfacerea difer de la o generaie la alta.
diferitelor nevoi Generaia tnr prefer
ale clienilor, cumprturile online, cea n
fidelizarea vrst prefer metodele
clienilor tradiionale de a cumpra.
Clienii au nevoi diferite, n
continu schimbare.
Satisfacerea acestor nevoi si
fidelizarea clienilor
determin organizaiile s se
adapteze. Schimbrile
demografice ntr-o anumit
zon (densitatea populaiei)
afecteaz i ele organizaia.
Factori Apariia unor noi Apariia unor noi tehnologii
tehnologici tehnologii poate determina organizaiile
s-i modifice procesele
interne pentru a utiliza aceste
tehnologii din dorina de a nu
rmne n urm fa de
concuren.
Factorii interni, respectiv externi vor determina schimbri la diferite niveluri n cadrul
organizaiei. n continuarea sunt prezentate nivelurile organizaiei guvernate de managementul
schimbrii.
121
Tabel 3.3. Factori ce determin schimbri n cadrul organizaie i rezultate
Factori care Ce se schimb Cum se schimb Unde se schimb Rezultate

determin
schimbarea
Creterea/mic Procese, Re-proiecarea La nivelul ntregii Creterea mrimii
orarea structura proceselor, organizaii organizaiei
dimeniunii organizaional apariia de noi
organizaiei departamente
organizaionale
Schimbarea Procese i Re-proiectarea La nivelul ntregii Creterea
metodologiei tehnici proceselor pentru organizaii produciei/mbunti
de producie a crete eficiena rea calitii
produselor
Oamenii Structura Pot avea loc La diferite Schimbarea strategiei
organizaional restructurri la niveluri/departam organizaiei
, etc. diferite ente
nivele/departame organizaionale
nte
organizaionale
Structura ntreaga Restructurri la La diferite mbuntirea
organizaio- organizaie diferite niveluri/departe- produciei, creterea
nal nivele/departame mente, procese profitului
nte
organizaionale
Cumprtorul Produsele Produsele oferite Linia de Cumprtorul are o
oferite, vor satisface producie, influen mare asupra
metodologia de cerinele procesele din organizaiei
producie cumprtorului, cadrul
procesele n organizaiei
cadrul
organizaiei pot fi
schimbate pentru
a satisface
cerinele
cumprtorului,
organizaia
devine centrat pe
cumprtor
Furnizorul Procesele n Procesele se vor Procesele din Organizaia este
cadrul schimba n cadrul dependent de un
organizaiei funcie de organizaiei singur furnizor,
cantitatea de acesta are puterea s
materie prim foreze organizaia s
oferit de schimbe ntregul
furnizor, preul proces de afaceri
materiei prime
122
Ameninarea Produsele Adugarea/modi- La nivelul liniei Diferenierea

produselor de oferite, posibil ficarea unor de producie, produselor oferite
substitut metodologia de caracteristici ale proceselor de prin caracteristici
producie produselor, producie unice
metodologia de
producie este
schimbat n
concordan cu
noile
caracteristici
Ameninarea Tehnologiile Sunt adoptate noi La nivelul liniei Organizaia i
noilor intrai folosite tehnologii, se de producie, consolideaz poziia
construiete o strategiei pe pia
loialitate bazat organizaiei,
pe brand. politica de
marketing
Intrarea/prsi Procesele n Re-proiectarea La nivel de Organizaia se
rea cadrul proceselor pentru procese, aplicaii, adapteaz la noua
organizaiei organizaiei adaptarea la noua date situaie
virtuale de un situaie
membru
Rivalitatea Organizaia Optimizarea La nivelul liniei Organizaia i
ntre efectueaz proceselor de de producie, consolideaz poziia
organizaiile modificri de producie pentru strategiei pe pia.
existente pre, scderea organizaiei
modificri n costurilor i
politica de creterea calitii
marketing, produselor.
mbuntirea Aceasta se
calitii reflect n preul
produselor, final al
introducerea produsului.
unor noi Politica de
produse marketing devine
mai agresiv.
Factori politici Strategia Regndirea La nivelul ntregii Organizaia se
organizaiei, strategiei, organizaii aliniaz la politica
procesele n organizaia poate guvernamental din
cadrul chiar pleca din statul respectiv (ex.
organizaiei ara respectiv, se minimizeaz
modific impactul asupra
procesele mediului nconjurtor
al produselor
dezvoltate
Factori Strategia Regndirea La nivelul ntregii Organizaia se
economici organizaiei strategiei pentru organizaii aliniaz la cerinele
adaptarea la noile curente ale pieei
condiii de pia
123
(ieftinirea preului
produselor vs.
mbuntirea
calitii lor,
cutarea unor noi
piee de
desfacere)
Factori socio- Strategia Strategia La nivelul ntregii Organizaia se
culturali organizaiei organizaiei se organizaii adapteaz cerinelor
adapteaz n cumprtorilor i
funcie de nevoile evolueaz n acelai
clienilor, procese timp cu acetia
noi sunt
dezvoltate (cum
ar fi procesele
pentru comerul
online),
organizaia este
retehnologizat
Factori Procesele Procesele sunt re- Procese, Organizaia
tehnologici interne ale proiectate pentru metodologia de beneficiaz de
organizaiei a utiliza n cadrul producie tehnologii de ultim
organizaiei noile generaie n procesul
tehnologii de producie,
oferindu-i un avantaj
asupra competiiei
P2. Identificarea nivelelor Managementului Schimbrii

Managementul schimbrii reprezint o abordare n ceea ce privete tranziia indivizilor,
proiectelor i a organizaiilor la o stare viitoare dorit [217].
Managementul schimbrii ncepe la nivelul organizaional. Strategia, tactica i obiectivele
organizaiei sunt factori eseniali ce pot declana procesele de schimbare n cadrul organizaiei.
Schimbarea se propag la nivelul proceselor i const n remodelarea i mbuntirea lor ntr-un
mod incremental pn n momentul n care s-a atins scopul dorit. Modificrile n cadrul
proceselor determin modificri la nivel de aplicaie i la nivel de date.
P3. Managementul Schimbrii la nivel de Organizaie
O abordare universal valabil nu este eficient pentru gestiunea schimbrii. Exist diferite
schimbri distincte ntr-o organizaie(folosirea de ctre furnizori a unui nou formular bazat pe
web sau a unui nou proces, implementarea unei soluii de planificare a resurselor ntreprinderii,
reorientarea n jurul proceselor n locul produselor) [218]. Acestea au nevoie de un management
al schimbrii pentru a avea succes. Fiecare schimbare prezint anumite riscuri i poate implica
personalul organizaiei.
124
O strategie pentru gestionarea schimbrilor este necesar pentru implementarea eficient a

acestora. Strategia nu poate fi stabilit fr definirea unor obiective n prealabil, obiective pentru
care are loc schimbarea. Strategia pentru managementul schimbrilor presupune [218]:
contientizarea situaiei prin nelegerea schimbrii i a prilor implicate
identificarea structurilor suport implicate
analiza strategic a riscurilor, tacticilor speciale ce trebuie adoptate i posibilelor

rezistene ntmpinate
Contientizarea situaiei presupune ntr-o faz iniial nelegerea schimbrilor ce vor fi
introduse. Acestea pot fi reprezentate de proiecte formalizate, iniiative strategice sau mici
ajustri n modul n care o organizaie opereaz. nelegerea caracteristicilor schimbrii
presupune rspunsul la ntrebri precum: Care este scopul schimbrii? Ci oameni vor fi
implicai? Care sunt prile implicate? Ce este schimbat - procese, sisteme, roluri n cadrul
organizaiei? Care este perioada de timp necesar schimbrii?
Urmtorul pas este reprezentat de nelegerea persoanelor i grupurile implicate n schimbare.
Trebuie gsit un rspuns la urmtoarele ntrebri: Cum este perceput nevoia de schimbare n
rndul angajailor? Cum au fost gestionate schimbrile n trecut? Exist o viziune mprtit n
cadrul organizaiei?
Determinarea grupurilor implicate n schimbare este ultimul pas n contientizarea situaiei.
Acest pas const n construirea unei hri a persoanelor implicate n schimbare.
Structurile suport sunt reprezentate de cei ce vor ntreprinde aciunea de schimbare n cadrul
organizaiei. Structura unei echipe suport include de obicei o echip extern ce ofer suport unei
echipe din cadrul unui proiect.
Analiza strategic presupune evaluarea riscurilor, anticiparea rezistenei la schimbare, stabilirea
unor tactici.
Evaluarea riscurilor presupune documentarea riscurilor globale ce pot afecta organizaia i a
factorilor de risc specifici.
Anticiparea rezistenei la schimbare presupune rspunsul la cteva ntrebri: Exist regiuni sau
divizii particulare asupra crora schimbrile au un impact deosebit? Exist grupuri ce au propus o
soluie diferit la aceeai problem? Sunt grupuri care au investit mult n abordarea curent?
Scopul acestor ntrebri reprezint identificarea punctelor speciale de rezisten la schimbare.
Ultimul pas al analizei strategice este reprezentat de identificare tacticilor speciale ce trebuie
aplicate pentru o iniiativ de schimbare particular. Tacticile speciale formalizeaz cunotinele
dobndite din strategia de dezvoltare legat de schimbare i felul n care aceasta afecteaz
diferitele pri ale organizaiei. Pe parcursul implementrii schimbrilor, tacticile speciale
adoptate pot fi revizuite i modificate.
Formularea strategiei de management al schimbrii reprezint primul pas n implementarea
schimbrii. Strategia ofer o direcie precum i o modalitate informat de luare a deciziilor pe
parcursul procesului de schimbare. O strategie bine pus la punct descrie cine i cum va fi afectat
125
de procesul de schimbare. Stabilirea strategiei pentru gestionarea schimbrilor este urmat de

implementarea schimbrilor la nivel de procese n cadrul organizaiei.
P4. Managementul Schimbrii la nivel de Proces
Blocul de modelare a proceselor (figura 3.3) identific prile implicate n procesul de modelare
precum i scopul modelrii. n [219] sunt identificate abilitile necesare persoanei care
modeleaz pentru a abstractiza cerinele prilor implicate, pentru a construi un model pe baza
cerinelor i pentru a transforma modelul n propoziii / predicate (afirmaii) care pot fi verificate
de prile implicate. Prile implicate n modelare trebuie s fie capabile s formuleze o descriere
a mediului de lucru i cerine concise pentru persoana care modeleaz. Att prile implicate n
modelare, ct i persoana care modeleaz au un scop [220]. Scopul modelrii determin
perspectiva i nivelul de detaliu pe parcursul procesului de modelare [221] .
Modelul proces este un rezultat al procesului de modelare. n procesul de modelare al proceselor

de afaceri, decizia privind tipul de limbaj folosit este foarte important [222]. Un aspect
important n alegerea unui anumit limbaj de modelare este faptul c fiecare alegere ofer diferite
capabiliti. Diferite limbaje de modelare pun accentul pe aspecte diverse ale proceselor, cum ar
fi secvenele de activiti, alocarea resurselor, comunicaia, sau responsabilitile organizaionale
[223]. Comparaii ntre diversele limbaje de modelare au fost fcute n raport diferite criterii: n
funcie de suportul oferit pentru tehnologiile de modelare a fluxurilor de activiti [224] sau n
funcie de deficienele de reprezentare [222]. Aceste studii evideniaz faptul c sunt diferene
mari n ceea ce privete capabilitile limbajelor.
Limbajele de modelare a proceselor sunt deseori implementate i folosite ca instrumente de

modelare. Aceste instrumente de modelare ofer faciliti adiionale fa de limbajele
implementate [225]. Unele instrumente ofer repository-uri pentru stocarea modelelor. Cele mai
multe ofer o varietate de limbaje pentru modelarea proceselor, ceea ce ofer utilizatorilor
posibilitatea de a folosi simboluri dintr-un alt limbaj n cazul n care doresc s mbogeasc
modelul de proces cu informaie adiional.
n practic, persoanele care modeleaz folosesc un set de convenii, norme sau practici uzuale n
cadrul procesului de modelare. Aceste convenii de modelare pot fi vzute ca o standardizare
intern organizaiei n procesul de modelare. Ele specific modalitatea prin care un limbaj de
modelare a proceselor poate fi folosit n acest scop. n unele cazuri, conveniile de modelare
restricioneaz utilizarea limbajului de modelare a proceselor la un set redus de elemente sau
simboluri. n alte cazuri, conveniile de modelare fac modificri la specificaiile unui limbaj de
modelare a proceselor, prin schimbarea semanticii sau a sintaxei elementelor sau simbolurilor
[225].
Modelul rezultat poate fi diferit n funcie de tehnica de modelare folosit. Modelele pot fi
construite n cadrul mai multor sesiuni de modelare, sau/i prin folosirea diferitor abordri:
corectitudine prin proiectare, nelegere prin proiectare, etc.
126
Fig. 3.3. Cadru modelare managementul schimbrii la nivel de proces (adaptat dup
[221])
n cadrul unei organizaii virtuale, n cazul intrrii/prsirii organizaiei virtuale de ctre membru
al acesteia, procesele n cadrul organizaiei virtuale vor trebui reproiectate. Pentru a determina
impactul produs, este nevoie de un instrument de analiz a impactului schimbrilor n cadrul unui
proces. Un astfel de instrument este descris n capitolul 4.
mbuntirea proceselor n cadrul unei organizaii poate fi realizat prin implicarea angajailor
din cadrul diferitelor niveluri sau departamente ale organizaiei n procesul de management al
schimbrii. Acetia pot identifica cu uurin punctele slabe n cadrul unui proces cu direct
impact asupra activitii lor sau resursele ce nu sunt folosite eficient de ctre acest proces.
Reelele Petri pot fi utilizate n cadrul organizaiilor pentru mbuntirea proceselor.
Pentru a crete aria de utilizare a Reelelor Petri au fost propuse o serie de instrumente de
modelare i analiz asistat de calculator. Unul dintre acestea este reprezentat de Reelele Petri
Baukasten (RPB) [226]. Scopul acestora este de a oferi un mediu suport pentru Reelele Petri n
cadrul aplicaiilor din punct de vedere teoretic i al instrumentelor. Reelele Petri Baukasten pot fi
vzute din patru perspective (figura 3.4): (1) perspectiva dezvoltatorului de aplicaii; (2)
perspectiva expertului; (3) perspectiva dezvoltatorului de instrumente; (4) baza comun.
127
Fig. 3.4. Structura conceptual a Reelelor Petri Baukasten [226]
Scopul Reelelor Petri Baukasten este s ofere suport pentru diferii utilizatori ai Reelelor Petri.
Ele pot fi aplicate n domenii ca: producia automat, sisteme de control, managementul
fluxurilor de producie, etc. RPB permit unui inginer ce dezvolt aplicaii s foloseasc noiuni
legate de Reele Petri interpretate la nivelul aplicaiei. RPB permit dezvoltatorului de aplicaii s
foloseasc cele mai adecvate metode i tehnici caracteristice Reelelor Petri sau chiar Reelele
Petri cele mai potrivite pentru proiectarea unei aplicaii.
RPB ofer expertului n RP suport pentru elaborarea i extinderea tehnicilor formale, definirea
unor noi tipuri i noiuni ntr-un format standard, declararea proprietilor RP ntr-o manier
formal i constructiv, transferul rezultatelor ntre diferite tipuri de reele i publicarea
rezultatelor i a noiunilor ctre alte aplicaii.
RPB ofer dezvoltatorilor posibilitatea s distribuie instrumentele create, s gseasc instrumente

adecvate, s mbine instrumentele deja existente n prototipuri, s adauge sau s modifice
instrumente deja existente.
Elementul central al RPB este reprezentat de tehnicile RPB. O tehnic RPB este dat ca o
combinaie consistent ntre un tip de RP, formalizarea ei, o procedur metodologic i
instrumentul informatic aferent. Tipul unei RP este dat de o descriere semi-formal a
caracteristicilor ei. Descrierea folosete noiuni de RP privind elementele constituente ale unei RP
cum ar fi poziii, marcaje, tranziii i a operaiilor de analiz sau a tehnicilor de construcie.
Descrierea formal a tipului RP este realizat din perspectiva expertului. Instrumentele
informatice sunt oferite n perspectiva dezvoltatorului. Procedura metodologic privind modul de
128
lucru cu un tip de RP ntr-o aplicaie practic este descris din perspectiva dezvoltatorului de
aplicaii. Ea definete secvena de activiti de dezvoltare, incluznd operaiile caracteristice
Reelelor Petri pentru verificare, structurare.
Baza comun
Baza comun [227] [228] cuprinde toate tipurile de RP pentru un anumit domeniu de aplicaii,
integreaz toate aceste tipuri ntr-o schem comun i definete relaiile dintre tipurile de RP. Se
dorete ca baza comun s fie structurat ntr-un mod ct mai simplu cu putin i ct mai uor de
neles pentru dezvoltatorii de aplicaii, dezvoltatorii de instrumente i experii n RP. Clasificarea
RP n cadrul bazei comune este reprezentat de o ierarhie specializat pe baza unor atribute.
Aceste atribute descriu noiunile legate de RP la un nivel conceptual.
Perspectiva dezvoltatorului de aplicaii
Perspectiva dezvoltatorului de aplicaii [229] [228] ofer premisele dezvoltrii de aplicaii bazate
pe RP. Planificarea activitilor dezvoltate ntr-un domeniu se realizeaz pe baza tehnicilor
formale, instrumentelor i procedurilor tehnologice oferite de acest modul. Activitile de
modelare se bazeaz pe exemple, soluii standard i proceduri metodologice caracteristice unui
tip de RP.
Perspectiva expertului
Perspectiva expertului furnizeaz elementele formale caracteristice tipurilor de RP sub forma

unei reprezentri matematice a noiunilor i rezultatelor. Perspectiva expertului cuprinde tehnici
formale, elemente formale abstracte, actualizri i transformri. Tehnicile formale RP i
transformrile sunt n legtur direct cu Baza Comun. Elementele formale abstracte,
actualizrile i transformrile abstracte descriu relaiile i dependenele dintre tehnicile formale i
transformrile la un nivel abstract.
Perspectiva dezvoltatorului de instrumente informatice
Aceast perspectiv susine realizarea rapid de prototipuri pentru instrumente informatice bazate
pe RP. Aceste instrumente permit modelarea, simulare i analiza variantelor de RP.
Baza de date
Baza de date conine toate informaiile ce sunt puse la dispoziie de RPB. Informaiile sunt
structurate n funcie de diferitele grupuri de utilizatori i de baza comun.
Baza de date a aplicaiei conine metode, tehnici de dezvoltare a RP i exemple. Acestea sunt
descrise n funcie de numele lor, obiective, domeniile de aplicaie i cuvinte cheie specifice
aplicaiilor. Domeniile de aplicabilitate sunt caracterizate de un numr de aspecte ce reflect toate
entitile i ntrebrile specifice unui domeniu de aplicaie.
Baza de date caracteristic expertului cuprinde elemente teoretice legate de RP: cadrul abstract
al RP, tehnici, actualizri, transformri [230]. Scheme sunt folosite pentru reprezentarea
uniform a acestor noiuni.
129
Baza de date caracteristic instrumentelor cuprinde toate informaiile relevante pentru

dezvoltarea unui instrument bazat pe RP. n aceast baz de date sunt stocate informaii privind
utilizarea (manuale, ghiduri, documentaie, etc.) i dezvoltarea unui astfel de instrument (cod
surs, documentaie pentru codul surs, informaii despre formatul intrrilor i transformrile
asupra acestor intrri).
Baza de date comun conine versiunea curent a diagramei de clasificare a RP. Fiecare tip de RP
este descris folosind notaii UML. O ierarhizare a diferitelor tipuri de RP este realizat.
Serviciile
Serviciile de asisten sunt invocate n interfaa utilizator i opereaz pe baza de date. Exist dou
tipuri de servicii de asisten: de cutare i de ntreinere. Serviciile de cutare recupereaz datele
cerute conform parametrilor de intrare i prezint rezultatele cutrii ntr-o manier adaptat la
cerinele utilizatorului. Serviciile de ntreinere modific baza de date prin adugarea/tergerea de
nregistrri. Serviciile pot fi comune, specifice aplicaiei, instrumentelor i expertului.
Serviciile specifice aplicaiei ofer suport pentru:

Gsirea unei metode bazate pe RP adecvate pentru dezvoltarea unei aplicaii
Folosirea tehnicilor de RP adecvate n dezvoltarea aplicaiilor
Gsirea unui tip de RP potrivit aplicaiei
Gsirea unui instrument informatic adecvat
Punerea la dispoziia dezvoltatorului de exemple
Serviciile specifice expertului ofer suport experilor pentru cercetarea n domeniul RP:
Pentru dezvoltarea de tehnici formale
Pentru definirea de tipuri i noiuni ntr-un format standard
Pentru definirea proprietilor variantelor de RP ntr-o manier formal i constructiv
Pentru transferul rezultatelor ntre diferite tipuri de RP
Disponibilitatea rezultatelor i noiunilor pentru aplicaii
Accesul structurat la noiuni teoretice privind RP
Serviciile caracteristice instrumentelor informaionale permit:

Gestiunea instrumentelor informatice existente
Faciliteaz dezvoltarea de instrumente informatice
Faciliteaz dezvoltarea instrumentelor existente
Serviciile comune au un rol esenial. Ele nu sunt invocate direct de un utilizator ci indirect de un
serviciu specific unui tip de utilizator. Ele integreaz funcionaliti cum ar fi:
Cutare n baza de date comun
Actualizarea ntregii baze de date
Arhitectura pentru RPB
Arhitectura pentru RPB se bazeaz pe tehnologii middleware i este compus din trei module:
interfaa grafic, stratul funcional i depozitul de date. Arhitectura RPB este ilustrat n figura
130
3.5. Interfaa utilizator este mprit n interfaa expert, interfaa dezvoltatorului de aplicaii i
interfaa dezvoltatorului de instrumente informatice.
Fig 3.5. Arhitectura RPB
Cadrul de modelare pentru RPB poate fi extins cu dou noi perspective(figura 3.5): perspectiva
membrului organizaiei i perspectiva analistului business.
Perspectiva membrului organizaiei
n cadrul arhitecturii pentru RPB, interfeei comune i se adaug pe lng cele trei interfee
existente, o interfa specific membrului organizaiei. Prin intermediul acestei interfee membrul
organizaiei poate selecta i accesa procesul ce prezint interes pentru el. Acest proces este afiat
n cadrul unei interfee grafice i modelat cu un instrument ce respect standardul BPMN
(Business Proces Modeling and Notation) [231].
Instrumentul a fost dezvoltat n prealabil de dezvoltatorul de instrumente i este bazat pe RP.
Instrumentul suport adugarea de comentarii exprimate ntr-un format liber. Ele vor fi fcute de
ctre membrul organizaiei asupra activitilor ce trebuie mbuntite n opinia sa precum i
asupra diferitelor resurse ce sunt utilizate ineficient. Aceast metod ofer membrilor organizaiei
mputernicirea i responsabilitatea eliminrii lucrurilor care nu adaug valoare din perspectiva
lor.
131
De asemenea, membrul organizaiei nu trebuie s fie familiarizat cu RP sau instrumente bazate pe

RP, interfaa grafic i instrumentul bazat pe standardul BPMN permindu-i o adaptare i o
nelegere a procesului rapid. Versiunea modificat a procesului este adugat n baza de date
comun.
Perspectiva analistului business
n cadrul aceleai arhitecturi RPB, interfeei comune i se mai adaug o interfa specific
analistului business. Prin intermediul acestei interfee, analistul business are acces la procesele
din cadrul organizaiei construite de dezvoltatorul de instrumente. Analistul business poate
remodela procesele din cadrul organizaiei prin proiectarea unor noi versiuni. Aceste versiuni vor
fi stocate n baza de date dezvoltator de instrumente i vor putea fi verificate i aprobate de ctre
expert i dezvoltatorul de instrumente.
Cadrul de modelare RBP poate fi integrat i cu conceptul managerial lean six sigma [232].
Abordri curente ce utilizeaz lean six sigma pentru mbuntirea proceselor n cadrul
organizaiilor sunt reprezentate de platforma IBM Blueworks Live [233]. Aceast platform
combin tehnologii BPM (Business Process Management) proprietare IBM i arhitecturi SOA
mpreun cu conceptul lean six sigma pentru a accelera mbuntirea procesele n cadrul unei
organizaii i obinerea de rezultate.
Spre deosebire de abordarea prezentat, abordarea curent face uz de suportul oferit de RP i de
expertul n RP pentru mbuntirea proceselor organizaiei.
P5. Managementul Schimbrii la nivel de Aplicaie

Schimbrile la nivel de aplicaie pot fi privite din dou perspective: n contextul SOA i n afara
lui.
Contextul arhitecturilor orientate ctre servicii web
n acest context serviciile care stau la baza aplicaiei sunt compuse folosind unul din modelele
compunere prezentate n 1.3.3. Serviciile componente trebuie s respecte anumite criterii
conform acordului SLA(Service Level Agreement).
SLA are mai multe definiii posibile:
Conform BusinessDictionary.com SLA reprezint un contract ntre un furnizor de
serviciu i un client, n care sunt detaliate natura, calitatea i scopul serviciului oferit.
[234]
Conform Wikipedia, SLA este parte a unui contract de servicii, unde un serviciu este
definit formal.
n contextul serviciilor web, SLA reprezint un acord ntre un furnizor de servicii web i
un client ce definete obligaiile prilor implicate [235]. n primul rnd reprezint
obligaia unui furnizor de servicii web de a furniza un serviciu n conformitate cu
nivelurile de calitate negociate. Pentru a verifica respectarea nivelurilor de calitate
negociate, tehnici de monitorizare i control trebuie specificate. Un SLA specific de
asemenea i msurile ce trebuie luate n cazul nerespectrii nivelurilor de calitate
negociate, de exemplu o notificare ctre client.
132
Calitatea serviciilor (Quality of Service) [236] face referire la proprietile non-funcionale ale
serviciilor web, cum ar fi performana, sigurana (reliability), disponibilitatea i securitatea.
Principalele cerine pentru suportul calitii serviciilor la nivel de servicii web sunt:
Disponibilitatea: este aspectul calitativ care atest dac serviciul web este prezent i gata
s fie utilizat. Valori mari pentru disponibilitate reprezint faptul c serviciul este n
marea majoritate a timpului pregtit pentru a fi utilizat.
Accesibilitatea: este aspectul calitativ care nivelul de capabilitate al unui serviciu web de
a deservi un request. Poate fi exprimat ca o probabilitate a ratei de invocare cu succes a
unui serviciu la un anumit moment.
Integritatea: este aspectul calitativ care denot felul n care serviciul web menine
corectitudinea interaciunilor. Execuia corect a tranzaciilor serviciului web va
determina corectitudinea interaciunilor.
Performana: este aspectul calitativ msurat n funcie de numrul de request-uri deservite
ntr-o anumit perioad de timp (throughput) i laten (timpul msurat ntre momentul
trimiterii unui request de ctre client i momentul n care clientul primete rspunsul).
Reliability: o msur a acestui aspect calitativ este reprezentat de numrul de eecuri al
serviciului raportat la o perioad de o lun sau un an. ntr-un alt sens, acest aspect calitativ
se refer la sigurana primirii mesajelor att de clientul serviciului ct i de furnizorul
serviciului
Reglementarea: este aspectul calitativ care se refer la conformitatea serviciului cu
regulile, legile, standardele i SLA stabilit.
Securitatea
n cazul n care anumii furnizori de servicii din cadrul organizaiei virtuale nu respect nivelul de
calitate negociat conform SLA este necesar managementul schimbrii. Serviciile respective pot fi
nlocuite cu alte servicii cu caracteristici funcionale asemntoare, n urma negocierii cu succes
al nivelului calitii noilor serviciilor.
Contextul aplicaiilor software care nu sunt bazate pe servicii web

n acest caz, schimbarea implic instalarea unor versiuni noi de aplicaii, instalarea unor aplicaii
noi, upgrade-ul la o nou versiune a bazei de date, cumprarea unui numr mai mare de licene,
etc. dar i dezvoltarea unor noi aplicaii n cadrul organizaiei.
Spre deosebire de celelalte situaii , dezvoltarea unor aplicaii n cadrul organizaiei presupune un
efort consistent i va fi analizat n continuare. Managementul la nivel de aplicaie este bazat pe
metodologia agile.
Metodologia "agile" sparge taskurile n incremente mici ce necesit o planificare minimal i nu

implic direct o planificare pe termen lung. Iteraiile reprezint perioade scurte de timp care
dureaz de obicei de la una pn la patru sptmni. Fiecare iteraie implic o echip cros-
funcional care colaboreaz pe parcursul etapelor iteraiei: planificare, analiza cerinelor,
proiectare, implementare, testare unitar, testare n privina acceptrii produsului. La sfritul
iteraiei, produsul este prezentat prilor implicate, n vederea acceptrii acestuia. Acest mod de
133
lucru minimizeaz riscurile i permite proiectului s se adapteze la schimbri rapid. O iteraie

poate s nu adauge suficient funcionalitate produsului pentru a garanta o lansare pe pia, dar
scopul este de a avea ceva palpabil la sfritul fiecrei iteraii, i o flexibilitate i capacitate de
adaptare sporite. Mai multe iteraii sunt necesare pentru a dezvolta i lansa un produs nou.
Monitorizarea permanent a produsului n faza de operare poate duce la identificarea unor nevoi
de adaptare, ce vor determina mai departe schimbri n cadrul aplicaiei prin reiterarea buclei
(figura 3.6).
Planificare
Analiza
cerinelor Identificare
nevoi de
adaptare
Proiectare
Imple-
mentare
Testare Monitorizare
unitar
Testare n
privina
acceptrii
Respingere Operare
Fig. 3.6. Dezvoltarea i adaptarea unei aplicaii folosind metoda agile
P6. Managementul Schimbrii la nivel de Date

Pentru un management al schimbrii eficient la nivel de date ntr-o organizaie trebuie luate n
considerare urmtoarele aspecte [237]:
o nelegere clar a modului n care entitile de date sunt folosite de ctre servicii,
procese i logica de business
o nelegere clar a felului n care entitile de date sunt create, stocate, transportate i
raportate
care este nivelul i complexitatea implicate de transformrile necesare pentru schimbul de
informaii ntre aplicaii
care sunt cerinele n materie de software pentru integrarea la nivel de date cu clienii i
furnizorii ntreprinderii
calitatea datelor
securitatea datelor
interoperabilitatea la nivel de date
accesibilitatea datelor
134
utilitatea datelor
Calitatea datelor
n cazul unor carene privind calitatea datelor, sunt dezvoltate i aplicate proceduri de corectare a
erorilor. De asemenea, procesele care produc date eronate sunt supuse i ele procesului de
mbuntire.
Securitatea datelor
Datele trebuie protejate de utilizarea fr autorizaie i divulgare. Printre categoriile de date ce
trebuie protejate se numr: informaiile folosite n luarea deciziilor, informaiile proprietare
(informaii ce nu sunt publice: date financiare, rezultate ale unor teste, etc.) i informaiile
sensibile (informaii care dac sunt compromise pot leza organizaia ce le deine).
Securitatea trebuie luat n considerare i implementat nc de la definirea elementelor de date.
Sistemele, datele i tehnologiile trebuie protejate de accesul neautorizat i manipulare. n funcie
de importana datelor, nivelul de securitate poate fi mbuntit pentru anumite elemente de date.
Interoperabilitatea la nivel de date
Interoperabilitatea considerat la nivel de date este sintactic i semantic. Scopul
interoperabilitatea sintactic este acela de a asigura faptul c mesajele schimbate ntre dou
sisteme informatice au formate compatibile. Transmitorul mesajului codific mesajul folosind
reguli sintactice specificate de o gramatic iar receptorul decodific mesajul pe baza aceleiai
gramatici. Scopul interoperabilitii semantice este acela de a asigura faptul c mesajele
transmise ntre cele dou sisteme au aceeai semnificaie pentru ambele sisteme.
Un exemplu de management al schimbrii este reprezentat de stabilirea interoperabilitii la nivel
de date n momentul n care organizaia curent dorete s colaboreze cu o organizaie nou.
Mediatori care s asigure maparea din formatul curent de date ntr-un format comun celor dou
organizaii pot fi dezvoltai.
Accesibilitatea datelor
Accesul larg la date duce la eficien i eficacitate n luarea deciziilor, permind organizaiilor s
rspund rapid la diferitele solicitri. Accesul la informaie trebuie acordat diferitor grupuri de
persoane din cadrul organizaiei. Politica de acces la diferite categorii de date din interiorul
organizaiei sufer numeroase schimbri n funcie de persoanele care trebuie s aib acces la
aceste date la un moment dat. Diferite roluri pot fi acordate diferitor grupuri de persoane, cu
modaliti difereniate de acces: vizualizare, modificare, tergere.
Utilitatea datelor
n orice moment al existenei organizaiei trebuie asigurat accesul la datele utile factorului de
decizie din cadrul organizaiei. Datele redundante precum i colectarea datelor redundante trebuie
eliminate. De asemenea, trebuie stabilite categoriile de date eseniale n cadrul procesului de luare
al deciziei. Acestea pot fi reprezentate de indicatorii cheie de performan. O monitorizare atent
a acestor indicatori trebuie realizat.
135
P7. Definirea KPI

Indicatorii cheie de performan (KPI - Key Performance Indicators) [238] reprezint un tip de
msurare a performanei. O organizaie poate utiliza indicatori cheie de performan pentru a-i
evalua succesul, sau pentru a evalua succesul unei anumite activiti n care este implicat.
Succesul poate fi definit ca progresul fcut n direcia atingerii unui obiectiv strategic [239], dar
de obicei acesta este reprezentat de atingerea repetat, periodic a unor nivele prestabilite n ceea
ce privete scopurile operaionale (zero defecte, satisfacia deplin a clienilor). Acetia difer n
funcie de organizaie. Alegerea corect a indicatorilor cheie de performan depinde de o bun
nelegere a prioritilor companiei. Prioritile sunt diferite n funcie de departamentul din
companie considerat. Indicatorii trebuie s poat fi msurabili. Este important ca definiia pentru
un indicator de performan s rmn neschimbat pe parcursul unei perioade mai lungi de timp.
Primul pas n definirea indicatorilor de performan l reprezint definirea proceselor de afaceri i
a obiectivelor organizaiei [240]: nivel al vnzrilor mai ridicat, productivitate mai mare, etc.
Dup definirea obiectivelor, sunt definii indicatorii de performan specifici fiecrui obiectiv.
Indicatorii de performan pot fi folosii ca un instrument de management al performanei.
Acetia ofer membrilor organizaiei o imagine clar a ceea ce este important, a lucrurilor de care
este nevoie pentru a atinge obiectivele. Pe baza indicatorilor, sunt analizate diferite propuneri de
variante i ajustri ale proceselor sau ale resurselor pentru a atinge obiectivele pe termen scurt.
De asemenea, ei pot fi folosii ca un instrument de motivare a personalului organizaiei prin
stabilirea unei inte pentru fiecare KPI i evaluarea periodic a progresului nregistrat ctre inta
respectiv.
Posibilii identificatori cheie pot fi mprii n diferite sub-categorii:
indicatori cantitativi (numr)
indicatori calitativi (numr)
indicatori de intrare (msoar cantitatea de resurse consumate pentru generarea

rezultatului)
indicatori de proces (reprezint eficiena sau productivitatea procesului)
indicatori de ieire (reflect rezultatul sau rezultatele activitilor de proces)
indicatori practici (interfaeaz cu procesele existente ale companiei)
indicatori direcionali (precizeaz dac o organizaie sufer o mbuntire sau nu)
indicatori financiari (utilizai pentru msurarea performanei i a costurilor)

Cteva ntrebri ce trebuie luate n considerare n momentul selectrii indicatorilor cheie de
performan sunt:
Care sunt indicatorii critici?
Sunt indicatorii selectai n concordan cu strategia organizaiei?
La ce nivel al organizaiei pot fi raportai indicatorii selectai
136
Este sistemul de msurare al valorilor pentru indicatorii de performan valid? Este

constant n timp modul de colectare al datelor pentru un indicator?
Este indicatorul selectat controlabil? Este persoana asignat s mbunteasc valoarea

unui indicator capabil s opereze schimbrile necesare pentru a obine efectul dorit?
n cadrul curentei cercetri au fost selectai civa indicatori considerai eseniali pentru scopul
lucrrii. Acetia sunt reprezentai de indicatorii cheie pentru procese:
cost de procesare pentru o invocare a procesului
rata de eec a procesului
durata de execuie a procesului
acurateea/calitatea rezultatelor obinute

Indicatorii cheie pot fi stabilii i n funcie de domeniu. Pentru domeniul medical au fost selectai
urmtorii indicatori cheie ce au sens n contextul studiului de caz prezentat n capitolul cinci:
durata de admitere a unui pacient n secia de urgene
timpul de avertizare al unui doctor n secia de urgen n cazul apariiei unui caz grav
rata mortalitii n secia de urgen
timpul de avertizare al autoritilor n cazul unui dezastru ecologic/calamiti

P8. Benchmarking
Benchmarking-ul reprezint un proces sistematic i continuu de msurare a propriei performane
n raport cu cele mai bune practici pentru a identifica potenialul de mbuntire.
Datele oferite de indicatorii cheie definii la diferite niveluri ale organizaiei pot fi analizate din
mai multe perspective: (1) perspectiva financiar; (2) perspectiva clientului; (3) perspectiva
proceselor; (4) perspectiva inovrii.
Pe baza criteriilor de benchmarking(de exemplu cifra de afaceri anual, numrul de angajai,),
organizaia virtual sau organizaiile componente ale VO se pot raporta la baza de date
internaionale de benchmarking cum ar fi de exemplu Industry Canada [241], HammerDB [242].
Pe baza rezultatelor obinute i a analizei din mai multe perspective a indicatorilor cheie de
performan se stabilete strategia de management al schimbrii n concordan cu scopul,
viziunea i misiunea organizaiei, ciclul fiind reluat.
3.5. CONCLUZII
n acest capitol am propus un cadru de modelare pentru managementul schimbrii n cadrul unei
organizaii. Cadrul de modelare ia n considerare patru niveluri: organizaie, procese, aplicaii,
date. Am identificat factorii interni/externi organizaiei ce determin nevoia de schimbare n
cadrul organizaie precum i ce se schimb, cum, unde i rezultatele schimbrii n funcie de
fiecare factor n parte. Am propus o metod pentru managementul schimbrii compus din mai
137
muli pai ce se aplic la cele patru niveluri ale organizaiei considerate. Am identificat indicatorii
chei de performan ce trebuie considerai n managementul schimbrii. Atenia a fost concentrat
asupra nivelurilor procese i aplicaii. La nivelul procese am propus un cadru de modelare pentru
reproiectarea i validarea proceselor. Am extins de asemenea arhitectura pentru RPB pentru a
permite angajailor unei organizaii s mbunteasc procesele caracteristice zonei lor de lucru.
Procesele mbuntite de angajai vor fi validate de analistul business din cadrul organizaiei.
138
CAPITOLUL 4
IDENTIFICAREA IMPACTULUI SCHIMBRILOR N CADRUL

PROCESELOR BAZATE PE SERVICII
4.1. INTRODUCERE
SOC (Service Oriented Computing) [243] este o paradigm ce utilizeaz serviciile ca i blocuri
constructive pentru a crea soluii software slab-interconectate. Serviciile sunt oferite de
componente software ce pot fi descrise, descoperite i compuse ntr-un mod interoperabil.
Serviciile implementeaz funcionaliti pornind de nivelul tehnic i pn la procese de afaceri
[244]. Aplicaiile bazate pe servicii (SBA) sunt construite pe baza arhitecturilor SOA. Serviciul
Web are o interfa descris ntr-un format procesabil main (specific WSDL). Alte sisteme
interacioneaz cu serviciul web folosind HTTP sau date serializate n formatul XML n
conjuncie cu alte standarde Web. Cele mai populare servicii web [245] utilizeaz standarde cum
ar fi WSDL [246], SOAP [247], WS-BPEL [95]. O proprietate important a serviciilor ce fac
parte din SOA este compozabilitatea lor [245]. Aa cum am artat i n paragraful 1.3.3 au fost
identificate patru modele de compunere a serviciilor: orchestraie de servicii, coreografie de
servicii, coordonare de servicii, asamblare de servicii.
Pe parcursul acestui capitol efortul va fi concentrat asupra orchestraiilor de servicii i a
limbajului WS-BPEL. WS-BPEL [95] este limbajul standard pentru modelarea comportamentului
orchestraiilor de servicii. Limbajul WS-BPEL este format din activiti de baz: Invoke, Receive,
Reply, Assign,Throw, Wait, Empty i activiti structurate: Sequence, If, While, RepeatUntill,
Pick, Flow, ForEach. Activitile de baz sunt atomice i descriu etapele elementare ale
comportamentului procesului. Activitile structurate codific logica de control a fluxului. Ele pot
conine activiti de baz sau alte activiti structurate (de exemplu mai multe activiti de tip
sequence n cadrul unei activiti de tip flow) .
Managementul schimbrii a fost studiat ntr-o gam larg de arii, cum ar fi: ingineria software,
sistemele distribuite, sisteme de gestiune al bazelor de date, sisteme informatice. Managementul
schimbrii pentru procesele de afaceri a fost studiat intensiv ncepnd cu mijlocul anilor 1990
[250][251][252][253][254][255][256]. Aceste studii se concentreaz asupra evoluiei proceselor
de afaceri i pe asigurarea flexibilitii n cadrul sistemelor de gestiune a fluxurilor de lucru. Nu
sunt luate n considerare relaiile proceselor cu serviciile.
A fost efectuat de asemenea un studiu asupra instrumentelor existente pe pia care permit
proiectarea de procese WS-BPEL. Punctul de interes a fost reprezentat de capacitatea
instrumentelor de a identifica impactul schimbrilor n cadrul procesului WS-BPEL. Cel mai
popular instrument este reprezentat de Eclipse BPEL Designer. Acesta este un software pentru
139
care utilizatorul nu trebuie s plteasc. Doi mari productori de software ofer de asemenea,
contra cost, instrumente pentru proiectarea proceselor BPEL: Oracle i IBM. Produsul
comercializat de Oracle se numete Oracle BPEL Process Manager iar cel comercializat de IBM
poart numele de IBM Integration Designer. Modelio BPEL Designer [257] este un instrument
care permite proiectarea grafic de procese conforme cu standardul BPMN i generarea de cod
BPEL pe baza acestora.
Eclipse BPEL Designer ofer suport pentru proiectarea de procese WS-BPEL [258]. Instrumentul
nu ofer suport pentru analiza impactului schimbrilor din cadrul procesului asupra celorlalte
activiti ale procesului sau a altor procese.
n cazul Oracle, ultima versiune disponibil este reprezentat de BPEL Process Manager
11.1.1.7.0 [259]. Aceast versiune nu a putut fi descrcat de pe site, doar clienii care au
contracte de suport cu cei de la Oracle avnd acces. A fost descrcat i analizat versiunea
10.1.3.3, ce vine ca un plugin preinstalat pentru JDeveloper 10.1.3.3. n urma studiului efectuat
am putut observa c Oracle BPEL Process Manager nu ofer suport pentru analiza impactului
schimbrilor n cadrul procesului. Diferena ntre versiunea analizat 10.1.3.3 i versiunea cea
mai recent, conform celor de la Oracle [260], [261] este reprezentat de introducerea corelrilor
condiionale pentru agregarea scenariilor.
n cazul IBM, o versiune de evaluare a instrumentului IBM Integration Designer 7.5.1 nu a putut
fi descrcat [262], ea fiind disponibil doar pentru companii. Conform documentaiei oferite de
IBM [263] instrumentul nu evalueaz impactul pe care o anumit schimbare n cadrul procesului
l poate avea asupra activitilor procesului n cauz sau asupra altor procese. Schimbrile
efectuate de la o versiune la alta a modelului de proces BPEL pot fi exportate din Integration
Designer i importate n IBM Business Modeler. n cadrul instrumentului IBM Business Modeler
schimbrile pot fi analizate, sesiznd diferenele dintre modelul de proces creat n Integration
Designer i implementarea propriu-zis. Aceste schimbri pot fi propagate foarte uor n
implementare sau respinse [264].
Nici n cazul Modelio, impactul schimbrilor n cadrul unui proces nu este luat n considerare.
n sistemele bazate pe servicii, pot exista dependene complexe ntre servicii i procesele de
afaceri. Managementul schimbrii reprezint o problem dificil n cadrul SOA datorit
caracterului dinamic al serviciilor i al distribuiei acestora [265]. Serviciile sunt cuplate cu
procesele business din care fac parte. Din diferite motive, serviciile i procesele business sufer
schimbri. O schimbare la nivel de serviciu afecteaz de obicei procesul business asociat precum
i celelalte servicii. La fel, o schimbare la nivel de proces afecteaz serviciile asociate. Din
aceast cauz, este necesar identificarea unor tipuri de schimbare posibil i a mecanismelor de
detecie a impactului acestor schimbri. Abordarea propus se bazeaz pe modele de procese
business orientate ctre servicii ce captureaz dependena dintre servicii i procesele business. Un
numr de tipare de impact al schimbrilor este identificat pe baza schimbrilor serviciilor.
Propagarea schimbrilor n cadrul proceselor business orientate ctre servicii poate fi identificat
pe baza tiparelor propuse. Pe baza unei taxonomii de schimbare, se efectueaz analiza propagrii
schimbrilor n cadrul unui proces business orientat ctre servicii. Un algoritm n acest sens este
propus.
140
4.2. MODELUL DE PROCES ORIENTAT CTRE SERVICII

Modelul de proces business orientat ctre servicii propus este bazat pe modelul [266]. Modelul
propus conine dou niveluri, nivelul proces i nivelul servicii.
S considerm scenariul n care un pacient internat n spital trebuie transportat la o alt unitate
spitaliceasc. Procesul de transfer al pacientului ctre alt unitate spitaliceasc (figura 4.1) se
realizeaz n mai muli pai. Fia medical este transmis ctre unitatea spitaliceasc secundar.
Dup primirea acceptului transferului fia de transfer a pacientului este eliberat i trimis ctre
unitatea spitaliceasc secundar. n acest scenariu, procesul de transfer pacient interacioneaz cu
doi parteneri: unitatea spitaliceasc secundar i partenerul care a instaniat procesul.
Interaciunea este realizat prin invocarea serviciilor expuse de un anumit proces. Fiecare serviciu
reprezint o vedere exterioar asupra procesului din punctul de vedere al unui partener.
Activitile private ale procesului, cum ar fi n acest caz activitatea de pregtire a procesului de
transfer nu sunt vizibile de ctre parteneri. Procesul prezentat n figura 4.1 reprezint un serviciu,
ce poate fi reprezentat printr-o reea petri simpl n care activitile de comunicare sunt
reprezentate prin tranziii, poziiile reprezentnd stri ale procesului(figura 4.2).
141
Fig. 4.1. Procesul de transfer pacient
142
Fig. 4.2. Reprezentarea procesului de transfer pacient ca o reea petri interpretat
143
n continuare vom descrie cele dou niveluri.
a) Nivelul proces
Nivelul proces conine procese de afaceri referite ca procesele interne. Un proces intern const
dintr-o schem de control a fluxului i diagrama fluxului de informaii .
Schema de control a fluxului
Schema de control a fluxului const ntr-un set de activiti i relaiile de control asociate cu
acestea. Activitile sunt clasificate n activiti private (P-activiti) i activiti de comunicare
(C-activitati) [267], [268]. Activitile private sunt invizibile pentru parteneri. P-activitile
permise de standardul BPEL sunt: assign, throw, wait, empty, exit, rethrow. Activitile de
comunicare sunt folosite pentru schimbul de informaii cu partenerii. C-activiti permise de
standardul BPEL sunt: receive, reply, invoke.
Definiia 1 Schema de control a fluxului unui proces intern este definit ca un 3-tuplu:
SCF = (A, C, E), n cazul n care [266]:
- = {1 , , } este un set de activiti. Pentru , dac este un C-activitate, .

denot un partener care a intenioneaz s interacioneze ;
- = { , , , , } este un set de conectori de control, unde
reprezint conectorul AND n timp ce denot conectorul XOR;
- = {1 , , } este un set de arce asociate activitilor i conectorilor.
Diagrama fluxului de informaii
Diagrama fluxului de informaii definete modul n care sunt transferate date ntre activiti.
Diagrama fluxului de informaii este cheia pentru nelegerea dependenei de date ntre activiti.
Ea este indispensabil pentru analiza impactului schimbrilor. Diagrama fluxului de informaii
este similar cu schema fluxului de date, definit n [269].
Fie = {1 , , } un set de elemente de date asociate cu procesul intern. Fiecare activitate

poate avea un parametru de intrare i/sau un parametru de ieire () (). O
conexiune de date este definit ca = (, , , ) , unde , ,
() (), {, } .
Definiia 2 (Diagrama fluxului de informaii) Fie SCF = (A, C, E) este schema fluxului de control
al unui proces intern. Diagrama fluxului de informaii este setul tuturor conexiunilor de date
= {1 , , }.
Definiia 3 (Dependena de date a activitilor) Fie = (, , ) este schema de control a

fluxului unui proces intern, = {1 , , } fiind diagrama fluxului de informaii, i
= {1 , , } setul de elemente de date asociate cu procesul intern. Pentru , A, ai are o
dependen de date aj , , dac , , astfel nct =
(, , , ) , = (, , , ) , unde , = , =
)
( . Pentru a rezuma, un proces intern este definit de un 2-
144
tuplu = (, ) .
b) Nivelul serviciilor
Nivelul serviciilor cuprinde serviciile ce reprezint de un proces intern. Fiecare serviciu este o
vedere exterioar a procesului intern din punct de vedere al unui partener. Prin interfaa unui
serviciu se ofer un comportament observabil de ctre un partener [270].
Definiia 4 (Serviciul) Un serviciu [266] este definit de un 2-tuplu = (, ), n cazul n care:
- = {1 , , } este un set de operaii. Fiecare operaie este asociat cu un set de mesaje;
- este un set de relaii de control dintre operaii. Fiecare tranziie = , ( ,
) reprezint invocarea operaiei de ctre . reprezint originea tranziiei,
reprezint operaia destinaie. Pentru o tranziie , () reprezint o constrngere pe tranziia
t. Tranziia t are loc imediat dup execuia operaiei origine. Dac () , tranziia t se execut
imediat ce condiia () devine adevrat.
4.3. RELAIA DINTRE NIVELUL PROCES I NIVELUL SERVICII

Procese interne i serviciile sunt strns cuplate. Un proces intern poate sprijini servicii multiple.
Fiecare activitate este asociat cu o operaie care implementeaz sarcina specificat de activitate.
Operaiile asociate cu c-activiti sunt expuse partenerilor corespunztori. Operaiile legate de
acelai partener sunt grupate ca un serviciu. Un serviciu este o vedere exterioar a procesul intern
din punct de vedere al unui partener.
4.4. IMPACTUL SCHIMBRILOR
Aceast seciune prezint modelele de impact al schimbrii. Impactul modelului schimbrii
surprinde efectul unei anumite schimbri. Aceste modelele de impact al schimbrilor permit
analiza i o mai bun nelegere a impactului schimbrii precum i dezvoltarea efectiv i
eficient a reaciilor de schimbare.
n continuare vor fi introduse modelele de impact al schimbrii la nivel de proces BPEL iar apoi
va fi definit o funcie de calcul pentru determinarea impactului schimbrilor i descris aplicaia.
Inserarea unei activiti
Acest model descrie inserarea unei activiti n procesul intern. Au fost identificate mai multe
posibiliti de inserare a unei activiti. Acestea sunt: (1) inserarea secvenial a unei activiti;
(2) inserarea n paralel a unei activiti.
tergerea unei/unor activiti
Acest model descrie eliminarea unor activiti din procesul intern. Pot fi terse una sau o secven
de activiti.
nlocuirea unei activiti cu o alt activitate
Acest model este bazat pe modelele anterior prezentate i const n tergerea unei/unor activiti
i inserarea unei activiti
Determinarea impactului direct al modificrilor
145
Prin determinarea impactului direct al modificrilor se identific activitile dintr-un proces

BPEL ce vor fi afectate prin aplicarea unor modele de schimbare precum cele descrise mai sus.
Funcia FuncDep este o funcie : , , , unde este
schema fluxului de control a procesului intern iar este diagrama fluxului de informaii,
este secvena de activiti = {1 , , } implicate n schimbare, iar
reprezint ieirea funciei , i const ntr-un set de activiti = {1 , , }
afectate de schimbarea . ntre oricare dou activiti , pot
exista urmtoarele relaii de dependen de date: sau .
Pas iniial
outputVariables - hashMap {cheie - numele variabilei, valori - nodurile reprezentnd activiti
pentru care variabila este variabil de ieire}
inputVariables - hashMap {cheie - numele variabilei, valori - nodurile reprezentnd activiti
pentru care variabila este variabil de intrare}
variablesMap - hashMap { cheie - numele variabilei, valori de tipul variableUsage}
variableUsage - {inputs - set de noduri pentru care variabila este variabil de intrare, outputs - set
de noduri pentru care variabila este variabil de ieire}
Pentru fiecare nod ni al grafului SCF de la start ctre end:
( ) = (1 ) 1

<>
. ( ) (4.1)
= . ( )
. ( )

. ( ); . ( , )
<>
. ( )
= . ( )
. ( )
146
. ( ); . ( , )
Funcia FuncDep_delete_activities
Input: SCF, DFI, , variablesMap
Output:
Fie = {1 , , } secvena de activiti implicate n schimbare
Pentru toate
= (4.2)
<>
= {1 , , } - activitile care au ca intrare variabila
= . ( )
pentru fiecare
( )
Funcia FuncDep_add_activity
Input: SCF, DFI, , variablesMap
Output:
Fie = {1 , , } secvena de activiti implicate n schimbare
Pentru toate
= (4.3)
<>
= {1 , , } - activitile care au ca ieire variabila
= . ( )
147
pentru fiecare
( )
<>
= {1 , , } - activitile care au ca intrare variabila
= . ( )
pentru fiecare
( )
Funcia FuncDep_replace_activity
Input: SFC, DFI, , , variablesMap
Output: (4.4)
=
FuncDep_delete_activity(SCF, DFI, , )
__(, , , )
Dac o activitate implicat n schimbare este de tipul c-Activitate, n funcie de partnerLink-ul
activitii respective ce este specificat n XML, va fi identificat procesul BPEL cu care activitatea
respectiv comunic.
Algoritmul presupune construirea iniial a listei de predecesori pentru fiecare nod al arborelui i
a hashMap-ului variablesMap ce conine variabilele i activitile pentru care acestea reprezint
intrri/ieiri, n timpul primei parcurgeri.
n momentul n care se dorete invocare uneia dintre funcii: FuncDep_add_activity,
FuncDep_delete_activity, FuncDep_replace_activity, lista de predecesori fiind deja construit, se
identific nodurile din arbore(activiti) pentru care o variabila de intrare/ieire a unei activiti de
ce este tears/adugat este variabil de ieire/intrare. Dac ntre cele dou noduri exist o cale
direct, atunci activitatea respectiv va fi afectat de activitatea ce este tears/adugat.
O diferen ntre abordarea propus i abordarea propus de Wang [266] este c abordarea
propus n aceast lucrare este particularizat pentru procese BPEL, n timp ce abordarea din
[266] este axat pe procese bazate pe servicii. Complexitatea algoritmului de
adugare/tergere/nlocuire activiti propus este liniar () deoarece n momentul parsrii
fiierului BPEL ce reprezint un proces BPEL, este construit ntreg arborele de activiti ce
compun procesul, mpreun cu predecesorii pentru fiecare activitate n parte i variabilele de
intrare i ieire, ce vor fi apoi stocate n clase Java de tipul java.util.HashMap. Complexitatea
adugrii/extragerii unui element dintr-o clas Java de tipul java.util.HashMap depinde de
148
implementare, dar este de obicei constant (1) i n cel mai defavorabil caz posibil (). Avem
astfel pentru determinarea impactului unei schimbri o complexitate ce va fi determinat de
iterarea mulimii de activiti implicate n schimbare egal () i de complexitatea necesar
adugrii/extragerii de variabile de intrare/ieire din implementrile de tipul java.util.HashMap
egal n cel mai defavorabil caz cu () . n cazul abordrii propuse n aceast lucrare
complexitatea total va fi egal cu suma celor dou complexiti, iar cum constantele sunt
eliminate n cazul calculului complexitii, ea va fi egal cu ().
n abordarea propus de Wang [266] pentru determinarea impactului schimbrilor, pentru fiecare
activitate curent implicat n schimbare se itereaz prin toate activitile procesului pentru a
detecta dependenele de date ntre activitatea curent implicat n schimbare i restul activitilor.
Complexitatea total va fi astfel (2 ), implicit mai mare.
O comparare a timpilor de execuie nu a putut fi realizat deoarece Wang folosete pentru
stocarea proceselor i a activitilor componente o baz de date, n cazul curent procesul BPEL
fiind reprezentat de un fiier n format XML.
4.5. IMPLEMENTARE
Implementarea s-a fcut folosind Java SE 1.7. Mediul de dezvoltare ales este Eclipse Juno.
Instrumentul grafic a fost realizat folosind Java swing. n momentul n care se ncarc un proces
BPEL(figura 4.3) exportat sub form de XML, documentul este parsat folosind un parser SAX.
n timpul parsrii de ctre parserul SAX a XML-ului, pe baza tag-urilor definite n standardul
WS-BPEL 2.0, este construit arborele ce reprezint procesul BPEL. Fiecrui nod din arbore i
este asociat o list de predecesori ce corespunde rutei n arbore de la nodul de start la nodul
curent. Pentru fiecare nod din arbore ce reprezint o activitate, se iau in considerare i .
Acestea sunt adugate n hashMap-ul variablesMap mpreun cu nodul pentru care constituie o
ieire, respectiv intrare.
n momentul n care se dorete tergerea/nlocuirea unor activiti sunt selectate activitile din
arbore ce vor fi terse(prima i ultima activitate). n momentul n care se dorete adugarea unor
activiti sunt selectate din arbore activitatea din arbore dup care se va face inserarea unei
activiti secveniale, respectiv prima i ultima activitate n cazul n care se va face inserarea unei
activiti paralele.
149
Impactul modificrilor va fi calculat pe baza algoritmilor prezentai i afiat ntr-un textbox

(figura 4.4).
Fig. 4.3. Exemplu proces BPEL
150
Fig. 4.4. Instrument grafic pentru analiza impactului schimbrilor
4.6. CONCLUZII
Analiza impactului schimbrilor n cadrul proceselor BPEL nlesnete adaptabilitatea n cadrul
Sistemelor Bazate pe Servicii. Instrumentul grafic ncarc i parseaz fiiere de tip xml
reprezentnd procese BPEL. Construirea arborelui de predecesori i a dependenei de date ntre
activiti pe baza variabilelor se face n momentul parsrii. Determinarea impactului schimbrilor
se face ntr-un mod optim, prin utilizarea hashMap-urilor de variabile ce conin nodurile pentru
care respectivele variabile reprezint intrri/ieiri. Aceste hashMap-uri sunt costruite n momentul
parsrii i utilizate n momentul determinrii impactului. Pentru validarea instrumentului de
analiz a impactului schimbrilor a fost conceput un studiu de caz prezentat n capitolul urmtor.
151
CAPITOLUL 5
STUDIU DE CAZ
5.1. DESCRIEREA SCENARIULUI
O poriune semnificativ din digul iazului de decantare a apelor industriale al societii de

exploatare minier RoMin se rupe n urma cderii unor cantiti semnificative de precipitaii. Prin
sprtura creat se scurg 150.000 de metri cubi de ape cu cianuri rezultate n urma procesului de
extragere al aurului prin cianurare. Apa cu cianuri ajunge n zona de vale situat n vecintatea
iazului, scurgndu-se mai apoi ntr-un ru ce trece prin valea respectiv. Rul respectiv este un
afluent al Dmboviei care mai apoi se vars n Arge, Argeul n Dunre, Delta Dunrii i
Marea Neagr.
Organizaia guvernamental pentru situaii de urgen UrgGov face parte dintr-un mediu de
dezvoltare al organizaiilor virtuale mpreun cu mai multe spitale, organizaii de intervenie n
caz de urgen, organizaii care se ocup cu distribuia de ap i alimente, organizaii de
monitorizare a calitii apei, aerului, solului. UrgGov decide s formeze o organizaie virtual
folosind ca parteneri organizaii dintre cele enumerate mai sus. Procesele stabilite n cadrul
organizaiei virtuale i n cadrul organizaiilor partenere se bazeaz pe servicii web.
Organizaiile de monitorizare a calitii apei, aerului, solului vor pune la dispoziie servicii web
prin care UrgGov va putea monitoriza n permanen calitatea acestor parametri n diferite zone
ale rii. Organizaiile de monitorizare meteo vor pune la dispoziie servicii UrgGov pentru
informarea asupra strii meteo n diferite zone ale rii i asupra prognozei meteo. Spitalele vor
informa prin intermediul serviciilor web UrgGov privind pacienii ce sufer de probleme cauzate
de poluarea cu cianuri. Pe baza datelor provenite de la aceste organizaii, UrgGov va lua decizii
privind planul de aciune. Organizaiile de intervenie vor avea rolul de a minimiza impactul
polurii asupra mediului.
n figura 5.1 este descris arhitectura business ca sistem a organizaiei virtuale create. Pe baza
valorilor obinute n urma monitorizrii meteo, a poluanilor i a sistemului medical UrgGov
decide i acioneaz prin intermediul actuatorilor.
152
Fig. 5.1. Arhitectura business ca sistem
n seciunea urmtoare sunt prezentate cteva din procesele ce pot fi stabilite n cadrul unei astfel
de organizaii virtuale, ntr-o situaie n care poluarea afecteaz mediul nconjurtor i sntatea
populaiei.
5.2. DESCRIEREA PROCESELOR
Pentru studiul de caz definit au fost proiectate mai multe procese folosind limbajul WS-BPEL de
modelare al proceselor.
Orchestratorul este reprezentat de ctre organizaia guvernamental UrgGov. Staiile de

monitorizare a polurii precum i staiile meteo sunt reprezentate de servicii. Cteva procese au
fost descrise pentru un spital.
153
Fig. 5.2. Procesului ce descrie reacia organizaiei UrgGov ntr-o situaie de urgen
154
n cadrul procesului ce descrie reacia organizaiei UrgGov ntr-o situaie de urgen se obin
valori pentru datele meteorologice: temperatur, umiditate, vitez vnt, presiune atmosferic,
nivel precipitaii prin intermediu serviciilor meteo invocate prin: invokeServciuMeteo1,
invokeServciuMeteo2, invokeServciuMeteo3, precum i valori ale polurii apei, aerului i solului
pentru o anumit zona (invokeServiciuPoluareApa, invokeServiciuPoluareAer,
invokeServiciuPoluareSol). Pe baza informaiilor obinute pentru o anumit zon: nivel poluare
apa, nivel poluare aer, nivel poluare sol precum i pe baza valorilor meteo(nivel precipitaii n
cazul nostru) sunt luate anumite decizii n cadrul blocului if. n cazul n care nu sunt detectate
probleme valorile obinute sunt stocate ntr-o baz de date prin invocarea serviciului de
actualizare a bazei de date: invokeServiciuActualizareBazaDeDate. n cazul n care valorile
pentru poluani ai aerului/apei/solului depesc o anumit valoare organizaiile responsabile cu
intervenia n cazul polurii apei, aerului, apei sunt contactate prin invocarea serviciilor:
invokeServiciuInterveniePolSol, invokeServiciuInterveniePolApa,
invokeServiciuInterveniePolAer. n funcie de necesiti, poate fi solicitat o anumit cantitate
de ap sau alimente reprezentat aici de un numr ntreg. Pe baza solicitrilor organizaiilor
teritoriale sunt contactai distribuitorii de ap/alimente: invokeServiciuDistrib1,
invokeServiciuDistrib2. Procesul CutareIdentificarePersoane primete ca date de intrare numele
unei zone unde se vor cuta persoane care au fost afectate de dezastrul ecologic, diagnostica i
vor primi asisten medical de urgen(figura 5.3). Procesul returneaz CNP-ul unei persoane
afectate.Persoana afectat va primi asisten medical de urgen (procesul Asisten medical de
urgen). Valorile poluanilor pentru zona respectiv mpreun cu persoanele afectate sunt
adugate n baza de date pe acest ramur condiional.
155
Fig. 5.3. Cutare identificare diagnosticare persoane
n cadrul procesului de asisten medical de urgen(figura 5.4) pentru un pacient se obine

iniial fia medical a pacientului pe baza numelui su si a CNP-ului
(invokeObinereFiMedicalPacient). Urmeaz recoltarea analizelor pentru pacientul
respectiv(invokeRecoltareAnalizePacient) urmat de analiza acestora
(invokeAnalizaAnalizelorPacient). Pe baza rezultatelor ntoarse de laboratorul de analize este
stabilit un diagnostic preliminar pentru pacient (invokeStabilireDiagnosticPacient). n funcie de
gravitatea diagnosticului (blocul if) o decizie este luat. Pacientul poate fi internat
(invokeInternarePacient), poate fi transferat la o alt unitate
spitaliceasc(invokeTranferPacientAltUnitate) sau formalitile pentru externare pot fi efectuate
(invokeExternare Pacient). n cadrul acestui proces activitile sunt executate mult mai repede
dect s-ar petrece ele n realitae, acesta fiind un compromis fcut pentru descrierea ct mai
explicit a proceselor n cadrul studiului de caz.
156
Fig. 5.4. Asisten medical urgen pacient
n cadrul procesului de internare pacient (figura 5.5), pe baza fiei medicale a pacientului i este
repartizat acestuia un pat ntr-un salon, i este completat biletul de internare i fia de alimentaie.
157
Fig. 5.5. Internare pacient
Procesul de transfer al pacientului ctre alt unitate spitaliceasc(figura 5.6) se realizeaz n mai
muli pai. Fia medical este transmis ctre unitatea spitaliceasc secundar
(invokeTransmitereFisaMedicalaPacient). Dup primirea acceptului
transferului(invokeObtinereAcceptAltaUnitate) fia de transfer a pacientului este
eliberat(invokeEliberareDocumentaieTransfer).
158
Fig. 5.6. Transfer pacient la alt unitate
Procesul de externare al pacientului(Fig. 5.7) const n eliberarea tratamentului pentru pacient

(invokeEliberareTratament). Tratamentul prescris este trimis i medicului de familie prin
invocarea: invokeInformareMedicDeFamilie, iar nota de plat este
eliberat(invokeEliberareNotaDePlata).
159
Fig. 5.7. Externare pacient
Aa cum se poate vedea n figurile prezentate mai sus, nelegerea logicii proceselor BPEL este
dificil fr explicaii detaliate privind fiecare proces n parte. Activitile prezente n cadrul
procesului nu au o descriere iar variabilele folosite n cadrul activitilor sunt greu accesibile.
Determinarea impactului schimbrilor fr o nelegere riguroas a procesului n prealabil nu este
facil. Instrumentul pentru analiza impactului schimbrilor atac aceast problem prin analiza
repercusiunilor pe care le pot avea aciuni de modificare a procesului cum ar fi
tergerea/inserarea/nlocuirea de activiti.
Pentru exemplificarea aplicaiei de analiz a impactului schimbrilor vom considera cteva

cazuri.
Considerm procesul Reacie guvernamental.
1. n cadrul activitii Assign1 sunt iniializate valorile variabilelor de request (input) pentru
activitile invokeServiciuPoluareApa, invokeServiciuPoluareAer, invokeServiciuPoluareSol.
Aa cum am descris mai sus considerm c invocarea serviciilor respective se face pentru o
160
anumit zon. Deoarece se dorete ca iniializarea s nu mai fie fcut static, se dorete tergerea
activitii Assign1 i nlocuirea ei cu o activitate receive. Activitatea receive va avea ca variabil
de ieire: ServiciuPoluareApaPartnerLinkRequest. Efectul tergerii activitii Assign va afecta la
prima vedere activitile imediat urmtoare: invokeServiciuPoluareApa,
invokeServiciuPoluareAer, invokeServiciuPoluareSol. Conform instrumentului de analiz din
figura 5.8 urmtoarele activiti vor fi afectate:
InvokeServiciuPoluareSol;InvokeServiciuPoluareAer; Assign3; InvokeServiciuPoluareApa
Adugarea activitii receive ce va avea ca variabil de ieire

ServiciuPoluareApaPartnerLinkRequest va afecta urmtoarele activiti:
Assign3; InvokeServiciuPoluareApa
n acelai timp sunt afiate activitile ce vor fi afectate n mod negativ de tergerea activitii
Assign1, dar care nu vor fi afectate ntr-un mod pozitiv de adugarea activitii receive:
InvokeServiciuPoluareSol; InvokeServiciuPoluareAer
Fig. 5.8. Impactul schimbrilor n cazul nlocuirii activitii Assign1 cu o activitate de tip receive
161
2. Organizaia care se ocup cu msurarea nivelului de poluare al apei i ale crei servicii sunt
utilizate n cadrul procesului prin InvokeServiciuInterventiePoluareApa decide s prseasc
organizaia virtual din diferite motive. Pentru a detecta impactul ieirii acesteia se va terge
activitatea InvokeServiciuInterventiePoluareApa. Rezultatul este(figura 5.9):
If; Assign4; Assign1
Fig. 5.9. Impactul schimbrilor n cazul tergerii unei activiti de tip invoke
3. Presupunem c se dorete renunarea la invocarea din interiorul procesului ce descrie reacia

guvernamental a procesului de cutare i diagnosticare a persoanelor afectate de dezastrul
ecologic . Impactul acestei schimbri nu se va reflecta asupra activitilor procesului curent, dar
se va putea identifica imediat procesul la care se va renuna n urma tergerii acestei activiti de
comunicare (figura 5.10). Procesul implicat este:
CautareIdentificareSalvarePersoane
162
Fig. 5.10. Evidenierea procesului la care se renun n cazul tergerii unei activiti de tip invoke
Considerm procesul externare pacient.
4. n cadrul acestui proces putem aduga o activitate de tipul invoke paralel cu

invokeInformareMedicFamilie (figura 5.11). Aceast activitate primete ca parametru de intrare
reeta eliberat de medicul curant din cadrul spitalului i o transmite unei farmacii preselectate, de
unde pacientul o poate ridica. Prin adugarea acestei activiti se pot observa dependenele de
intrare ale activitii: InvokeEliberareTratament
163
Fig. 5.11. Evidenierea dependenelor n cazul introducerii unei activiti n paralel
Considerm procesul internare pacient n spital
5. Dorim s introducem o activitate secvenial de tip receive dup Assign i nainte de

flow prin care s iniializm variabila de intrare a pentru activitatea
invokeCompletareFisaAlimentaie (figura 5.12). Efectele acestei adugri sunt aa cum era de
ateptat:
InvokeCompletareFisaAlimentatie
164
Fig. 5.12. Evidenierea dependenelor n cazul introducerii unei activiti secveniale
5.3. CONCLUZII
n cadrul situaiilor limit n care trebuie luate decizii imediate este nevoie de un instrument
capabil s analizeze impactul schimbrilor. n aceast direcie a fost elaborat studiul de caz ce
prezint o organizaie virtual ce se poate forma n cadrul unui dezastru ecologic. Procesele i
servicii web au fost definite n cadrul organizaiilor.
Prin aplicarea instrumentului de analiz a impactului schimbrilor asupra proceselor WS-BPEL

definite pentru studiul de caz prezentat au fost exemplificate avantajele acestuia: contientizarea
imediat, n timp real, al impactului schimbrilor n cadrul unor procese WS-BPEL bazate pe
servicii web.
165
CONCLUZII
C.1. CONCLUZII GENERALE
Pentru a face fa pieelor turbulente, ntreprinderile i modific modul de a face afaceri. Dei
multe ntreprinderi nc folosesc metode tradiionale, numeroase ntreprinderi folosesc
colaborarea cu alte ntreprinderi pentru a obine avantaje n ceea ce privete oportunitile de
afaceri i rspunsul la nevoile clienilor. Internetul serviciilor prin tehnologii cum ar fi serviciile
web i SOA, permite organizaiilor s colaboreze i s-i ating obiectivele ntr-o manier
flexibil ce necesit doar o conexiune la internet.
Fiecare ntreprindere are n mod tipic propriul sistem informaional, propria viziune i propriile
obiective, dar poate suferi influene externe provenite din interiorul reelei colaborative sau din
mediul de afaceri.
Organizaiile nu mai exist ca entiti de sine stttoare. Ele devin parteneri n cadrul unor
organizaii virtuale din dorina de a-i atinge scopul ntr-un mod eficient. Organizaiile virtuale
sunt temporare, avnd o durat relativ scurt de via, perioad n care pot fi supuse la numeroase
schimbri, prin plecarea sau adoptarea unuia sau a mai multor parteneri. Datorit mediului
turbulent de afaceri care influeneaz organizaiile, acestea trebuie s-i reproiecteze procesele n
funcie de necesitile de adaptare. Este nevoie un model care s permit managementul
schimbrii i care s pun accent pe procese.
Entitile de tip ntreprindere pot fi vzute ca sisteme i reprezint subsisteme ale metasistemului
CNO. Interaciunile ntre entiti sunt susinute de servicii web, servicii care pot fi compuse
formnd un sistem bazat pe servicii. SBS reprezint astfel un subsistem al metasistemului CNO.
n urma cercetrii asupra stadiului actual, a fost identificat necesitatea unui cadru holistic de
monitorizare i adaptare care s permit monitorizarea i adaptarea de-a lungul a mai multor
niveluri ale SBS. Integrarea monitorizrii de-a lungul nivelurilor tehnologice este necesar
pentru sistemele SBS ale viitorului, deoarece ofer o modalitate de localizare eficient, evaluare
i corelare a sursei problemei ce duce la o viitoare adaptare precum i a impactului adaptrii.
Aceast necesitate a fost transpus la nivel de sistem ntreprindere, i s-a concretizat n
propunerea unui cadru de modelare pentru managementul schimbrii la nivelul ntregului CNO
ce se concentreaz asupra proceselor organizaiei propunnd o metod de implementare a
managementului schimbrii bazat pe mai muli pai.
Cadrul de modelare este organizat patru niveluri: nivel organizaie, nivel procese, nivel aplicaii
i nivel date. Nevoia de schimbare n cadrul CNO este determinat de aciunea unor factori care
au fost clasificai n factori externi (factori specifici mediului de afaceri al organizaiei, factori
politici, factori economici, factori sociali, factori tehnologici) respectiv factori interni organizaiei
(mrimea organizaiei, metodologia de producie, oamenii, structura organizaional). Pentru
fiecare categorie de factori am identificat: ce se schimb, cum se schimb, unde se schimb i
posibilele rezultate ale schimbrii n funcie de fiecare factor n parte. Am propus o metod
166
pentru managementul schimbrii compus din mai muli pai ce se aplic celor patru niveluri ale
organizaiei considerate: P1. Identificarea factorilor ce genereaz Managementul Schimbrii;
P2. Identificarea nivelelor Managementului Schimbrii; P3. Managementul Schimbrii la nivel
de Organizaie; P4. Managementul Schimbrii la nivel de Proces; P5. Managementul Schimbrii
la nivel de Aplicaie; P6. Managementul Schimbrii la nivel de Date ; P7. Definirea KPI; P8.
Benchmarking. La nivelul procese am propus un cadru de modelare pentru reproiectarea i
validarea proceselor. Am extins de asemenea arhitectura pentru RPB pentru a permite angajailor
unei organizaii s mbunteasc procesele caracteristice zonei lor de lucru. Procesele
mbuntite de angajai vor fi validate de analistul business din cadrul organizaiei. La nivelul
aplicaie au fost luate n considerare contextul aplicaiilor SOA i contextul aplicaiilor non-SOA.
La nivel de date am considerat atribute eseniale ale entitilor de date i felul n care sunt acestea
afectate de managementul schimbrii.
De asemenea, este nevoie de reconfigurarea n mod dinamic a organizaiilor ntr-un timp ct mai
scurt. Impactul schimbrilor trebuie contientizat. Aceast problem este adresat de instrumentul
de evaluare al impactului schimbrilor, ce permite contientizarea impactului pe care
tergerea/adugarea/nlocuirea de activiti n cadrul proceselor o poate avea asupra celorlalte
activiti din cadrul procesului respectiv sau asupra altor procese. Procesele bazate pe servicii
web sunt specificate pe baza standardului WS-BPEL i reprezentate n format XML. Instrumentul
grafic ncarc i parseaz fiiere de tip XML reprezentnd procese BPEL. n timpul parsrii,
instrumentul construiete arborele de predecesori i a dependenei de date ntre activiti pe baza
variabilelor. Determinarea impactului schimbrilor se face ntr-un mod optim.
Avantajele oferite de instrumentului de analiz a impactului schimbrilor asupra proceselor WS-
BPEL au fost evideniate printr-un studiu de caz i constau n : contientizarea imediat, n timp
real, al impactului schimbrilor n cadrul unor procese WS-BPEL bazate pe servicii web.
C.2. CONTRIBUII ORIGINALE
Pe parcursul acestei lucrri pot fi identificate un numr de contribuii originale. Ele vor fi
prezentate n continuare.
Am propus patru noi caracteristici pentru paradigma sistemic(seciunea 1.1.2.4).
Am realizat o sintez a stadiului actual privind cerinele/atributele/proprietile sistemelor

FInES(seciunea 1.2).
Am prezentat evoluia sistemelor informaionale complexe de la EAI la sisteme informaionale

evoluate FInES, realiznd o sintez a abordrilor propuse privind integrarea i interoperabilitatea
la nivel de ntreprindere, precum i standardele adoptate n aceast direcie de cercetare(seciunea
2.3).
Am extins cadrul referin de modelare al VBE cu o nou dimensiune (seciunea 3.2):

dimensiunea sistemic. Aceast dimensiune este reprezentat de VBE ca un metasistem, si
anume un sistem de sisteme complex adaptive dispersat geografic cu geometrie variabil. VBE
trebuie s aplice eficient infrastructuri ICT, instrumente i servicii pentru a oferi mijloacele
necesare interaciunii/colaborrii organizaiilor, s faciliteze configurarea i crearea de VO, s
167
ofere asisten pentru evoluia VO, s introduc noi abordri i mecanisme pentru construirea
ncrederii, definirea unei culturi colaborative, stabilirea unor sisteme de valori comune i a
principiilor de lucru/partajare a resurselor i cunotinelor ntre organizaii independente. Aceast
a doua generaie de VBE este un model/cadru de modelare bazat pe soluii organizaionale
evoluate (tip cluster, living lab, etc.) pentru asocierea entitilor eterogene ca precondiie de
punere n comun a resurselor: umane, tehnologice, financiare, etc. pentru atingerea unui scop
comun reprezentat de un set de indicatori cheie de performan, printre care pot fi enumerai:
profitabilitate maxim, satisfacerea specific (one-of-a-kind), eficiena folosirii resurselor,
acoperirea expertizelor competenelor profesionale. Scopul final este creterea potenialului
concurenial al unei companii mai, mici sau mijlocii, micro-ntrepridere care s evolueze ntr-un
ecosistem de afaceri (dinamic, turbulent, n curs de globalizare).
Am propus un cadru de modelare pentru managementul organizaional al CNO la nivel de:

organizaie, procese, aplicaii, date(seciunea 3.3).
Am identificat factorii ce determin nevoia de schimbare n cadrul CNO i am analizat impactul

acestora la diferite nivele ale organizaiei(seciunea 3.4).
Am propus o metod pentru managementul schimbrii compus din mai muli pai ce se aplic
celor patru niveluri ale organizaiei(seciunea 3.5).
Am extins de asemenea arhitectura pentru RPB pentru a permite angajailor unei organizaii s
mbunteasc procesele din cadrul organizaiei caracteristice zonei lor de lucru(seciunea 3.4).
Am implementat un instrument de analiz a impactului schimbrilor n procese BPEL bazate pe

servicii web (capitolul 4). Instrumentul parseaz folosind un parser SAX fiiere n format XML
care conin descrierea proceselor BPEL aa cum sunt ele exportate din eclipse. n timpul parsrii
este construit graful de dependen pentru activiti, ceea ce va determina ntr-un mod optim
impactul schimbrilor n momentul n care acestea au loc. Instrumentul suport diferite abloane
pentru adugarea/eliminarea/nlocuirea de activiti n cadrul procesului BPEL i analizeaz
impactul modificrilor asupra celorlalte activiti din procesul curent precum i ce alte procese
sunt afectate de modificrile aduse procesului curent.
Am validat instrumentul dezvoltat pe un studiu de caz, folosind pentru modelarea proceselor i

implementarea serviciilor web mediul de dezvoltare Eclipse (capitolul 5). Mediul de rulare folosit
pentru serviciile web a fost Apache Tomcat.
C.3. PERSPECTIVE DE DEZVOLTARE ULTERIOAR
O direcie viitoare de cercetare ar fi integrarea instrumentului dezvoltat cu mediul de dezvoltare

Eclise, plugin-ul BPEL.
168
O alt direcie de cercetare este reprezentat de extinderea grupului int de utilizatori ai

instrumentului de la proiectanii de procese ctre manageri prin adugarea unui modul de validare
a corectitudinii proceselor BPEL.
169
ANEXE
A1. COD SURS INSTRUMENT DE ANALIZ A IMPACTULUI SCHIMBRILOR

package bpel.objects; package bpel.objects;
public class PickImpl implements BpelElement { public class ActivityImpl implements BpelElement {
private String name; private String name = null;
public static int pickNumber; private Boolean suppressJoinFailure = null;
private int localPickNumber; private ActivityType type;
private String partnerLink = null;
@Override
public void setName(String aName) { public String getName() {
name = aName; return name;
}
} public void setName(String name) {
this.name = name;
@Override }
public String getName() { public Boolean getSuppressJoinFailure() {
return name; return suppressJoinFailure;
} }
public void setSuppressJoinFailure(Boolean
public PickImpl() { suppressJoinFailure) {
pickNumber++; this.suppressJoinFailure =
localPickNumber = pickNumber; suppressJoinFailure;
name = "Pick" + localPickNumber; }
} public ActivityType getType() {
return type;
public String toString() { }
StringBuffer sb = new StringBuffer(); public void setType(ActivityType type) {
sb.append("Pick|number=" + this.type = type;
localPickNumber+"|name=" + name /*+"|type="+type*/); }
return sb.toString();
} public String toString() {
StringBuffer sb = new StringBuffer();
@Override sb.append("activity|name="+name
public boolean equals(Object obj) { +"|type="+type+ "|partnerLink="+partnerLink);
if (obj == null) { return sb.toString();
return false; }
}
if (getClass() != obj.getClass()) { public String getPartnerLink() {
return false; return partnerLink;
} }
final PickImpl other = (PickImpl) obj; public void setPartnerLink(String partnerLink) {
if (this.getName() == null) this.partnerLink = partnerLink;
return false; }
if (other.getName() == null)
return false; }
if (this.getName().compareTo(other.getName())
!= 0)
return false; package bpel.objects;
return true; import java.util.ArrayList;

} import java.util.List;
} import bpel.tree.Node;
-------------------------------------------------------
package bpel.objects; public class InvokeImpl extends ActivityImpl{
private String inputVariable = null;
import java.util.ArrayList; private String outputVariable = null;
import java.util.HashMap; private String operation = null;
import java.util.List; private String partnerLink = null;
private String portType = null;
170
public class ProcessImpl implements BpelElement {

public String getInputVariable() {
private String name = null; return inputVariable;
private String xmlns_lns = null; }
private Boolean exitOnStandardFault = null; public void setInputVariable(String inputVariable) {
private String targetNamespace = null; this.inputVariable = inputVariable;
private String xmlns_bpel = null; }
public String getOperation() {
public String getName() { return operation;
return name; }
} public void setOperation(String operation) {
public void setName(String name) { this.operation = operation;
this.name = name; }
} public String getPartnerLink() {
public String getXmlns_lns() { return partnerLink;
return xmlns_lns; }
} public void setPartnerLink(String partnerLink) {
public void setXmlns_lns(String xmlns_lns) { this.partnerLink = partnerLink;
this.xmlns_lns = xmlns_lns; }
} public String getPortType() {
public Boolean getExitOnStandardFault() { return portType;
return exitOnStandardFault; }
} public void setPortType(String portType) {
public void setExitOnStandardFault(Boolean this.portType = portType;
exitOnStandardFault) { }
this.exitOnStandardFault = public String getOutputVariable() {
exitOnStandardFault; return outputVariable;
} }
public String getTargetNamespace() { public void setOutputVariable(String outputVariable) {
return targetNamespace; this.outputVariable = outputVariable;
} }
public void setTargetNamespace(String
targetNamespace) {
this.targetNamespace = @Override
targetNamespace; public boolean equals(Object obj) {
} if (obj == null) {
public String getXmlns_bpel() { return false;
return xmlns_bpel; }
} if (getClass() != obj.getClass()) {
public void setXmlns_bpel(String xmlns_bpel) { return false;
this.xmlns_bpel = xmlns_bpel; }
} final InvokeImpl other = (InvokeImpl) obj;
if (this.getName() == null)
public String toString() { return false;
StringBuffer sb = new StringBuffer(); if (other.getName() == null)
sb.append("Process|name="+name return false;
/*+"|variables="+ variables.toString()*/); if (this.getName().compareTo(other.getName()) != 0)
return sb.toString(); return false;
}
return true;
@Override }
public boolean equals(Object obj) {
if (obj == null) { }
return false; -------------------------------------------------------
}
if (getClass() != obj.getClass()) { package bpel.objects;
return false;
} import java.util.ArrayList;
final ProcessImpl other = (ProcessImpl) obj; import java.util.List;
return false; import bpel.tree.Node;
return false; public class ReceiveImpl extends ActivityImpl {
if (this.getName().compareTo(other.getName()) private String outputVariable = null;
171
!= 0)
return false; public String getOutputVariable() {
return outputVariable;
return true; }
}
} public void setOutputVariable(String
------------------------------------------------------- variable) {
package bpel.objects; this.outputVariable = variable;
}
public class OpaqueActivityImpl extends ActivityImpl {
private String name; @Override
public static int count = 0; public boolean equals(Object obj) {
private int localCount; if (obj == null) {
return false;
public OpaqueActivityImpl() { }
count++; if (getClass() != obj.getClass()) {
localCount = count; return false;
name = "OpaqueActivity" + count; }
} final ReceiveImpl other = (ReceiveImpl)
obj;
public String getName() { if (this.getName() == null)
return this.name; return false;
} if (other.getName() == null)
return false;
public void setName(String name) { if
this.name = name; (this.getName().compareTo(other.getName()) != 0)
} return false;
@Override return true;

public boolean equals(Object obj) { }
return false; -------------------------------------------------------
} package bpel.objects;
if (getClass() != obj.getClass()) {
return false; public class RepeatUntillImpl implements BpelElement {
} private String name;
final OpaqueActivityImpl other = public static int repeatUntillNumber;
(OpaqueActivityImpl) obj; private int localRepeatUntillNumber;
return false; @Override
if (other.getName() == null) public void setName(String aName) {
return false; name = aName;
!= 0) }
return false;
@Override
return true; public String getName() {
} return name;
} }
-------------------------------------------------------
package bpel.objects; public RepeatUntillImpl() {
repeatUntillNumber++;
public class PartnerLink { localRepeatUntillNumber =
private String name = null; repeatUntillNumber;
private String partnerLinkType = null; name = "RepeatUntill" +
private String myRole = null; localRepeatUntillNumber;
private String partnerRole = null; }
public String getName() { public String toString() {

return name; StringBuffer sb = new StringBuffer();
} sb.append("RepeatUntill|number=" +
public void setName(String name) { localRepeatUntillNumber+"|name=" + name /*+"|type="+type*/);
this.name = name; return sb.toString();
} }
172
public String getPartnerLinkType() {

return partnerLinkType; @Override
} public boolean equals(Object obj) {
public void setPartnerLinkType(String if (obj == null) {
partnerLinkType) { return false;
this.partnerLinkType = partnerLinkType; }
} if (getClass() != obj.getClass()) {
public String getMyRole() { return false;
return myRole; }
} final RepeatUntillImpl other = (RepeatUntillImpl)
public void setMyRole(String myRole) { obj;
this.myRole = myRole; if (this.getName() == null)
} return false;
public String getPartnerRole() { if (other.getName() == null)
return partnerRole; return false;
} if (this.getName().compareTo(other.getName()) != 0)
public void setPartnerRole(String partnerRole) { return false;
this.partnerRole = partnerRole;
} return true;
}
}
} -------------------------------------------------------
------------------------------------------------------- package bpel.objects;
package bpel.objects; import java.util.ArrayList;

import java.util.List;
public enum ActivityType {
INVOKE, RECEIVE, REPLY, ASSIGN, THROW import bpel.tree.Node;
}
--------------------------------------------------------- public class ReplyImpl extends ActivityImpl {
package bpel.objects;
private String inputVariable = null;
import java.util.ArrayList; //private ArrayList<Node<BpelElement>>
import java.util.List; childrenDataDep = new ArrayList<Node<BpelElement>>();
//private Node<BpelElement> fatherDataDep = null;
public class AssignImpl extends ActivityImpl{
public static int assignNumber; public String getInputVariable() {
private int localAssignNumber; return inputVariable;
private String name ; }
//private String inputVariable = null;
//private String outputVariable = null; public void setInputVariable(String variable) {
private List<String> inputVariables = new this.inputVariable = variable;
ArrayList<String>(); }
private List<String> outputVariables = new
ArrayList<String>(); @Override
public List<String> getInputVariables() { if (obj == null) {
return new ArrayList(inputVariables); return false;
} }
public void addInputVariable(String return false;
inputVariable) { }
this.inputVariables.add(inputVariable); final ReplyImpl other = (ReplyImpl) obj;
} if (this.getName() == null)
return false;
public List<String> getOutputVariables() { if (other.getName() == null)
return outputVariables; return false;
} if (this.getName().compareTo(other.getName()) != 0)
return false;
public void addOutputVariable(String
outputVariable) { return true;
}
this.outputVariables.add(outputVariable); }
173
} -------------------------------------------------------
public AssignImpl() {
assignNumber++; public class RethrowImpl extends ActivityImpl {
localAssignNumber = assignNumber; private String name;
name = "Assign" + localAssignNumber; public static int count = 0;
} private int localCount;
public String toString() { public RethrowImpl() {

StringBuffer sb = new StringBuffer(); count++;
sb.append("Assign|number=" + localCount = count;
localAssignNumber+"|name=" + this.name name = "RethrowActivity" + count;
/*+"|type="+type*/); }
} public String getName() {
return this.name;
public String getName() { }
return this.name;
} public void setName(String name) {
this.name = name;
@Override }
public void setName(String aName) {
this.name=aName; @Override
@Override if (obj == null) {
public boolean equals(Object obj) { return false;
return false; if (getClass() != obj.getClass()) {
} return false;
if (getClass() != obj.getClass()) { }
return false; final RethrowImpl other = (RethrowImpl) obj;
final AssignImpl other = (AssignImpl) obj; return false;
if (this.name == null) if (other.getName() == null)
return false; return false;
if (other.getName() == null) if (this.getName().compareTo(other.getName()) != 0)
if (this.name.compareTo(other.getName()) != 0)
return false; return true;
}
return true; }
} -------------------------------------------------------
}
----------------------------------------------------------- public class ScopeImpl implements BpelElement {
package bpel.objects; private String name;
public static int scopeNumber;
public interface BpelElement { private int localScopeNumber;
public void setName(String aName); @Override

public String getName(); name = aName;
public String toString(); }
} @Override
----------------------------------------------------------- public String getName() {
package bpel.objects; return name;
}
import java.util.ArrayList;
import java.util.List; public ScopeImpl() {
scopeNumber++;
public class ElseIfImpl implements BpelElement { localScopeNumber = scopeNumber;
private String name; name = "Scope" + localScopeNumber;
174
public static int elseIfNumber; }

private int locaElseIfNumber;
public String toString() {
private List<String> inputVariables = new StringBuffer sb = new StringBuffer();
ArrayList<String>(); sb.append("Scope|number=" +
private List<String> outputVariables = new localScopeNumber+"|name=" + name /*+"|type="+type*/);
ArrayList<String>(); return sb.toString();
}
public List<String> getInputVariables() {
return new ArrayList(inputVariables); @Override
if (obj == null) {
public void addInputVariable(String return false;
inputVariable) { }
this.inputVariables.add(inputVariable); if (getClass() != obj.getClass()) {
} return false;
}
public List<String> getOutputVariables() { final ScopeImpl other = (ScopeImpl) obj;
return outputVariables; if (this.getName() == null)
} return false;
public void addOutputVariable(String return false;
outputVariable) { if (this.getName().compareTo(other.getName()) != 0)
return false;
this.outputVariables.add(outputVariable);
} return true;
}
@Override
public void setName(String aName) { }
name = aName; -------------------------------------------------------
}
public class WaitImpl extends ActivityImpl {
@Override private String name;
public String getName() { public static int count = 0;
return name; private int localCount;
}
public WaitImpl() {
public ElseIfImpl() { count++;
elseIfNumber++; localCount = count;
locaElseIfNumber = elseIfNumber; name = "WaitActivity" + count;
name = "ElseIf" + locaElseIfNumber; }
}
public String getName() {
public String toString() { return this.name;
StringBuffer sb = new StringBuffer(); }
sb.append("ElseIf|number=" +
locaElseIfNumber+"|name=" + name /*+"|type="+type*/); public void setName(String name) {
return sb.toString(); this.name = name;
} }
@Override @Override
public boolean equals(Object obj) { public boolean equals(Object obj) {
if (obj == null) { if (obj == null) {
} }
if (getClass() != obj.getClass()) { if (getClass() != obj.getClass()) {
} }
final ElseIfImpl other = (ElseIfImpl) obj; final WaitImpl other = (WaitImpl) obj;
if (this.getName() == null) if (this.getName() == null)
if (other.getName() == null) if (other.getName() == null)
175
if (this.getName().compareTo(other.getName()) if (this.getName().compareTo(other.getName()) != 0)
!= 0) return false;
return false;
return true;
return true; }
} }
-------------------------------------------------------
} package bpel.objects;
-----------------------------------------------------------
package bpel.objects; public class WhileImpl implements BpelElement {
private String name;
public class ElseImpl implements BpelElement { public static int whileNumber;
private String name; private int localWhileNumber;
public static int elseNumber;
private int localElseNumber; @Override
@Override name = aName;
name = aName; }
} @Override
@Override return name;
public String getName() { }
return name;
} public WhileImpl() {
whileNumber++;
public ElseImpl() { localWhileNumber = whileNumber;
elseNumber++; name = "While" + localWhileNumber;
localElseNumber = elseNumber; }
name = "Else" + localElseNumber;
} public String toString() {
public String toString() { sb.append("While|number=" +
StringBuffer sb = new StringBuffer(); localWhileNumber+"|name=" + name /*+"|type="+type*/);
sb.append("Else|number=" + return sb.toString();
localElseNumber+"|name=" + name /*+"|type="+type*/); }
} @Override
@Override if (obj == null) {
public boolean equals(Object obj) { return false;
return false; if (getClass() != obj.getClass()) {
} return false;
if (getClass() != obj.getClass()) { }
return false; final WhileImpl other = (WhileImpl) obj;
final ElseImpl other = (ElseImpl) obj; return false;
if (this.getName() == null) if (other.getName() == null)
if (other.getName() == null) if (this.getName().compareTo(other.getName()) != 0)
!= 0) return true;
return false; }
return true; }
} -------------------------------------------------------
package bpel.tree;
}
----------------------------------------------------------- import java.util.ArrayList;
package bpel.objects; import java.util.List;
176
public class EmptyImpl extends ActivityImpl { public class Tree<T> {

private String name; private Node<T> root;
public static int count = 0; private Node<T> currentNode;
private int localCount;
public Tree(Node <T> aNode) {
public EmptyImpl() { root = new Node<T>();
count++; root.data = aNode.data;
localCount = count; root.children = new ArrayList<Node<T>>();
name = "EmptyActivity" + count; currentNode = root;
} }
public String getName() { public void addChildToNode(Node<T> aNode, Node<T>

return this.name; fatherNode) {
} fatherNode.children.add(fatherNode.children.size(),
aNode);
public void setName(String name) { aNode.parent = fatherNode;
this.name = name;
} }
@Override public Node<T> getCurrentNode() {

public boolean equals(Object obj) { return currentNode;
return false;
} public void setCurrentNode(Node<T> aCurrentNode) {
if (getClass() != obj.getClass()) { currentNode = aCurrentNode;
return false; }
}
final EmptyImpl other = (EmptyImpl) obj; public static class Node<T> implements Cloneable {
if (this.getName() == null) private T data;
return false;
if (other.getName() == null) private Node<T> parent;
return false; private List<Node<T>> children = new
if (this.getName().compareTo(other.getName()) ArrayList<Node<T>>();
!= 0)
return false; public Node() {
}
return true;
} public Node(T someData) {
} data = someData;
----------------------------------------------------------- }
/* copy constuctor
public class ExitImpl extends ActivityImpl { * */
private String name; /*public Node( Node<T> aNode) {
public static int count = 0; data = aNode.data;
private int localCount; parent = aNode.parent;
children = aNode.children;
public ExitImpl() { }*/
count++;
localCount = count; public T getData() {
name = "ExitActivity" + count; return data;
} }
public String getName() { public void setData(T data) {

return this.name; this.data = data;
} }
public void setName(String name) {

this.name = name;
} }
@Override
if (obj == null) { -------------------------------------------------------
177
return false; package dependency.analyzer;

}
if (getClass() != obj.getClass()) { import java.util.ArrayList;
return false; import java.util.HashMap;
} import java.util.LinkedHashMap;
final ExitImpl other = (ExitImpl) obj; import java.util.LinkedHashSet;
if (this.getName() == null) import java.util.LinkedList;
return false; import java.util.List;
if (other.getName() == null) import java.util.ListIterator;
return false; import java.util.Stack;
!= 0) import sax.parser.VariableUsage;
return false;
import bpel.objects.ActivityImpl;
return true; import bpel.objects.AssignImpl;
} import bpel.objects.BpelElement;
} import bpel.objects.ElseIfImpl;
----------------------------------------------------------- import bpel.objects.EmptyImpl;
package bpel.objects; import bpel.objects.FlowImpl;
import bpel.objects.IfImpl;
public class FlowImpl implements BpelElement { import bpel.objects.InvokeImpl;
import bpel.objects.ProcessImpl;
private String name; import bpel.objects.ReceiveImpl;
public static int count = 0; import bpel.objects.ReplyImpl;
private int localCount; import bpel.objects.SequenceImpl;
import bpel.tree.Node;
return this.name; class ReturnValues {
} public Boolean foundStart;
public Boolean foundEnd;
public void setName(String name) { public Boolean deadEnd;
this.name = name;
} public ReturnValues(Boolean firstBool, Boolean
secondBool, Boolean deadEndBool) {
public FlowImpl() { foundStart = firstBool;
count++; foundEnd = secondBool;
localCount = count; deadEnd = deadEndBool;
this.name = "Flow" + localCount; }
} }
public String toString() { class RetVal {

StringBuffer sb = new StringBuffer(); public Boolean foundEnd;
sb.append("Flow|number=" + public Boolean deadEnd;
localCount+"|name=" + this.name /*+"|type="+type*/);
return sb.toString(); public RetVal(Boolean firstBool, Boolean
} deadEndBool) {
foundEnd = firstBool;
@Override deadEnd = deadEndBool;
return false;
} public class DependencyAnalyzer {
if (getClass() != obj.getClass()) { private LinkedHashMap<String, Node<BpelElement>>
return false; namesHashMap = null;
} private HashMap<String, VariableUsage>
final FlowImpl other = (FlowImpl) obj; variablesMap = null;
return false; public DependencyAnalyzer(LinkedHashMap<String,
if (other.getName() == null) Node<BpelElement>> theNamesHashMap, HashMap<String,
return false; VariableUsage> theVariablesMap) {
if (this.getName().compareTo(other.getName()) namesHashMap = new
!= 0) LinkedHashMap<String,
return false; Node<BpelElement>>(theNamesHashMap);
variablesMap = new HashMap<String,
178
return true; VariableUsage>(theVariablesMap);

} }
}
----------------------------------------------------------- /*
package bpel.objects; public static ReturnValues
locateDirectImpactNodes_old(
public class ForEachImpl implements BpelElement { Node<BpelElement> aNode, String
private String name; startNode,
public static int forEachNumber; String
private int forEachLocalNumber; endNode,Stack<Node<BpelElement>> elements, Boolean
foundStart, Boolean foundEnd) {
@Override
name = aName;
if (!foundStart &&
} verifyAgainstName(startNode, aNode)==0 ) {
foundStart = true;
@Override elements.push(aNode);
public String getName() { if (startNode.compareTo(endNode)
return name; == 0)
} return new
ReturnValues(true, false);
public ForEachImpl() { }
forEachNumber++; if (foundStart && !foundEnd &&
forEachLocalNumber = forEachNumber; verifyAgainstName(endNode, aNode)==0) {
name = "ForEach" + foundEnd = true;
forEachLocalNumber; elements.push(aNode);
} return new ReturnValues(true,
true);
public String toString() { }
StringBuffer sb = new StringBuffer(); if (foundStart && foundEnd &&
sb.append("ForEach|number=" + verifyAgainstName(startNode, aNode)!=0) {
forEachLocalNumber+"|name=" + name elements.push(aNode);
/*+"|type="+type*/); }
return sb.toString(); if (aNode.getChildrenNodes().size() == 0 ) {
} return new
ReturnValues(foundStart, foundEnd);
@Override }
public boolean equals(Object obj) { List<Node<BpelElement>> children =
if (obj == null) { aNode.getChildrenNodes();
return false; for (ListIterator<Node<BpelElement>>
} iterator = children.listIterator(children.size());
if (getClass() != obj.getClass()) { iterator.hasPrevious();) {
return false; if (!foundEnd) {
} Node<BpelElement>
final ForEachImpl other = (ForEachImpl) obj; prevChild = (Node<BpelElement>)iterator.previous();
if (this.getName() == null) ReturnValues ret =
return false; locateDirectImpactNodes_old(prevChild, startNode, endNode,
if (other.getName() == null) elements, foundStart, foundEnd);
return false; foundStart =
if (this.getName().compareTo(other.getName()) ret.foundStart;
!= 0) foundEnd =
return false; ret.foundEnd;
if (foundStart &&
return true; !foundEnd)
} elements.pop();
}
} }
----------------------------------------------------------- return new ReturnValues(foundStart,
package bpel.objects; foundEnd);
}
import java.util.ArrayList;
import java.util.List; public static ReturnValues locateDirectImpactNodes(
Node<BpelElement> aNode, String
179
public class IfImpl implements BpelElement{ startNode,

String
private String name; endNode,Stack<Node<BpelElement>> elements, Boolean
public static int count = 0; foundStart, Boolean foundEnd) {
private int localCount;
Boolean thisFoundStart = foundStart;
private List<String> inputVariables = new Boolean thisFoundEnd = foundEnd;
ArrayList<String>();
private List<String> outputVariables = new if (aNode.getChildrenNodes().size() > 0 ) {
ArrayList<String>(); List<Node<BpelElement>>
children = aNode.getChildrenNodes();
public List<String> getInputVariables() { for
return new ArrayList(inputVariables); (ListIterator<Node<BpelElement>> iterator =
} children.listIterator(children.size()); iterator.hasPrevious();) {
public void addInputVariable(String Node<BpelElement> prevChild =

inputVariable) { (Node<BpelElement>)iterator.previous();
this.inputVariables.add(inputVariable); ReturnValues
} ret = locateDirectImpactNodes(prevChild, startNode, endNode,
elements, thisFoundStart, thisFoundEnd);
public List<String> getOutputVariables() { if
return outputVariables; (!thisFoundStart) {
} if
(ret.foundStart)
public void addOutputVariable(String
outputVariable) { thisFoundStart = ret.foundStart;
}
this.outputVariables.add(outputVariable); if
} (!thisFoundEnd) {
if
public String getName() { (ret.foundEnd)
return name;
} thisFoundEnd = ret.foundEnd;
}
public IfImpl() { if
count++; (thisFoundStart && thisFoundEnd)
localCount = count; return
this.name = "If" + localCount; new ReturnValues(true, true);
} }
@Override
public void setName(String name) { }
this.name = name;
} if (!thisFoundEnd &&
verifyAgainstName(endNode, aNode)==0 ) {
public String toString() { thisFoundEnd = true;
StringBuffer sb = new StringBuffer(); elements.push(aNode);
sb.append("If|name=" + name if
/*+"|type="+type*/); (startNode.compareTo(endNode) == 0)
return sb.toString(); return new
} ReturnValues(true, true);
} else if (!thisFoundStart &&
@Override thisFoundEnd) {
public boolean equals(Object obj) { if
if (obj == null) { (verifyAgainstName(startNode, aNode)==0) {
return false; thisFoundStart
} = true;
return false; elements.push(aNode);
} return new
final IfImpl other = (IfImpl) obj; ReturnValues(true, true);
if (this.getName() == null) }
return false; else {
180
return false; elements.push(aNode);

if (this.getName().compareTo(other.getName()) return new
!= 0) ReturnValues(false, true);
return false; }
}
return true;
} return new
ReturnValues(thisFoundStart, thisFoundEnd);
} }*/
-----------------------------------------------------------
public ReturnValues locateDirectImpactNodes_v3(
public class SequenceImpl implements BpelElement { Node<BpelElement> aNode, String
private String name; startNode,
public static int seqNumber; String
private int localSeqNumber; endNode,Stack<Node<BpelElement>> elements, Boolean
foundStart, Boolean foundEnd) {
@Override
public void setName(String aName) { if (!foundStart && !foundEnd &&
name = aName; verifyAgainstName(startNode, aNode)==0 ) {
foundStart = true;
} elements.push(aNode);
if (startNode.compareTo(endNode)
@Override == 0)
public String getName() { return new
return name; ReturnValues(true, true, false);
} } else if (foundStart && !foundEnd ) {
if (verifyAgainstName(endNode,
public SequenceImpl() { aNode)==0) {
seqNumber++; foundEnd = true;
localSeqNumber = seqNumber; elements.push(aNode);
name = "Sequence" + localSeqNumber; return new
} ReturnValues(true, true, false);
}
public String toString() { else
StringBuffer sb = new StringBuffer(); elements.push(aNode);
sb.append("Sequence|number=" + }
localSeqNumber+"|name=" + name /*+"|type="+type*/); if (aNode.getData() instanceof FlowImpl ||
return sb.toString(); aNode.getData() instanceof SequenceImpl) {
} if
(aNode.getChildrenNodes().size() == 0 )
@Override return new
public boolean equals(Object obj) { ReturnValues(foundStart, foundEnd, true);
return false; if (aNode.getData() instanceof ActivityImpl)
} {
if (getClass() != obj.getClass()) { if (aNode.getLinks().size() == 0 )
return false; return new
} ReturnValues(foundStart, foundEnd, true);
final SequenceImpl other = (SequenceImpl) obj; }
if (this.getName() == null) List<Node<BpelElement>> children =
return false; aNode.getChildrenNodes();
if (other.getName() == null) if ((aNode.getData() instanceof FlowImpl) ||
return false; (aNode.getData() instanceof ProcessImpl)) {
if (this.getName().compareTo(other.getName()) for (Node<BpelElement>
!= 0) child:children) {
return false; ReturnValues ret =
locateDirectImpactNodes_v3(child, startNode, endNode,
return true; elements, foundStart, foundEnd);
}
/*if (foundStart &&
} ret.foundStart && !foundEnd && ret.deadEnd)
----------------------------------------------------------- elements.pop();
package bpel.objects; else
181
if
public class ThrowImpl extends ActivityImpl { (ret.foundStart && ret.foundEnd)
private String name; return new
public static int count = 0; ReturnValues(true, true, false);*/
private int localCount; foundStart =
private String inputVariable = null; ret.foundStart;
foundEnd =
public ThrowImpl() { ret.foundEnd;
count++; }
localCount = count; } else if (aNode.getData() instanceof
name = "ThrowActivity" + count; SequenceImpl) {
} Node<BpelElement> child =
children.get(0);
public String getName() { ReturnValues ret =
return this.name; locateDirectImpactNodes_v3(child, startNode, endNode,
} elements, foundStart, foundEnd);
foundStart = ret.foundStart;
public void setName(String name) { foundEnd = ret.foundEnd;
this.name = name; }
} else if (aNode.getData() instanceof
ActivityImpl) {
public String getInputVariable() { List<Node<BpelElement>> links =
return inputVariable; aNode.getLinks();
} for (Node<BpelElement>
link:links) {
public void setInputVariable(String variable) { ReturnValues ret =
this.inputVariable = variable; locateDirectImpactNodes_v3(link, startNode, endNode, elements,
} foundStart, foundEnd);
if (foundStart &&
@Override ret.foundStart && !foundEnd && ret.deadEnd)
public boolean equals(Object obj) { elements.pop();
if (obj == null) { else
return false; if
} (ret.foundStart && ret.foundEnd)
if (getClass() != obj.getClass()) { return new
return false; ReturnValues(true, true, false);
} foundStart =
final ThrowImpl other = (ThrowImpl) obj; ret.foundStart;
if (this.getName() == null) foundEnd =
return false; ret.foundEnd;
if (other.getName() == null) }
return false; }
!= 0) return new ReturnValues(foundStart,
return false; foundEnd, true);
return true; }
}
} /***
----------------------------------------------------------- * Implementation based on nodes to find the
package bpel.tree; * @param aName
* @param aNode
import java.util.ArrayList; * @return
import java.util.HashSet; */
import java.util.LinkedHashSet; public RetVal locateDirectImpactNodes_v5(
import java.util.List; Node<BpelElement> aNode,
Node<BpelElement> startNode, Node<BpelElement> endNode,
import bpel.objects.ActivityImpl; Stack<Node<BpelElement>>
import bpel.objects.BpelElement; elements) {
if (aNode.equals(startNode)) {
public class Node<T> { elements.push(aNode);
private T data = null; if (startNode.equals(endNode))
//private Node<T> parent = null; return new RetVal(true,
182
private List<Node<T>> children = new false);

ArrayList<Node<T>>(); } else if (aNode.equals(endNode)) {
private List<Node<T>> parents = new elements.push(aNode);
ArrayList<Node<T>>(); return new RetVal(true, false);
private ArrayList<Node<BpelElement>> } else
childrenDataDep = new ArrayList<Node<BpelElement>>(); elements.push(aNode);
private Node<BpelElement> fatherDataDep = null; Boolean foundEnd = false;
private List<Node<T>> links = new if (aNode.getData() instanceof FlowImpl ||
ArrayList<Node<T>>(); aNode.getData() instanceof SequenceImpl) {
private Node<T> lastNodeInSeq = null; if
private int number; (aNode.getChildrenNodes().size() == 0 )
private static int count; return new RetVal(false,
private LinkedHashSet<String> prevPath = new true);
LinkedHashSet<String>(); }
if (aNode.getData() instanceof ActivityImpl)
public void addNodeToPrevPath(String {
nodeName) { if (aNode.getLinks().size() == 0 )
prevPath.add(nodeName); return new RetVal(false,
} true);
}
public void List<Node<BpelElement>> children =
addAllNodesToPrevPath(LinkedHashSet<String> nodesSet) aNode.getChildrenNodes();
{ if ((aNode.getData() instanceof FlowImpl) ||
prevPath.addAll(nodesSet); (aNode.getData() instanceof ProcessImpl)) {
} for (Node<BpelElement>
child:children) {
public LinkedHashSet<String> getPrevPath() { RetVal ret =
return prevPath; locateDirectImpactNodes_v5(child, startNode, endNode,
} elements);
foundEnd =
public boolean containsPrevNodeName(String ret.foundEnd;
nodeName) { if (foundEnd == true)
return prevPath.contains(nodeName); return new
} RetVal(true, false);
if (!ret.foundEnd &&
public int getNumber() { ret.deadEnd)
return number; elements.pop();
} }
public void setLastNodeInSeq(Node<T> aNode) { SequenceImpl) {
lastNodeInSeq = aNode; Node<BpelElement> child =
} children.get(0);
public Node<T> getLastNodeInSeq() { RetVal ret =
return lastNodeInSeq; locateDirectImpactNodes_v5(child, startNode, endNode,
} elements);
public void addLink(Node<T> aNode) { foundEnd = ret.foundEnd;
links.add(aNode); }
public List<Node<T>> getLinks() { ActivityImpl) {
return links; List<Node<BpelElement>> links =
} aNode.getLinks();
public void for (Node<BpelElement>
addChildrenDataDep(Node<BpelElement> aChild) { link:links) {
childrenDataDep.add(aChild); RetVal ret =
} locateDirectImpactNodes_v5(link, startNode, endNode,
public List<Node<BpelElement>> elements);
getChildrenDataDep() { if ( !ret.foundEnd &&
return childrenDataDep; ret.deadEnd)
} elements.pop();
public Node<BpelElement> getFatherDataDep() { else if (ret.foundEnd)
return fatherDataDep; return new
} RetVal(true, false);
public void }
addFatherDataDep(Node<BpelElement> aFather) { }
183
fatherDataDep = aFather;
} return new RetVal(foundEnd, true);
public int getChildreDataDepSize() {
return childrenDataDep.size(); }
}
public int verifyAgainstName(String aName,
public List<Node<T>> getChildrenNodes() { Node<BpelElement> aNode) {
return children; if (aNode.getData() == null ||
} (aNode.getData().getName() == null))
return -1;
public void addChildNode(Node<T> aNode) { return
children.add(aNode); aName.compareToIgnoreCase(aNode.getData().getName());
} }
public void addParent(Node<T> aFather) { public LinkedList<String>

parents.add(aFather); getOutputDependencies(String specifiedOutputVariable,
} Node<BpelElement> aNode) {
LinkedList<String> outDep = new
public List<Node<T>> getParents() { LinkedList<String>();
return parents; String nodeName =
} aNode.getData().getName();
public Node() { if (specifiedOutputVariable != null) {

} if
(variablesMap.get(specifiedOutputVariable) != null) {
public Node(T someData) { LinkedHashSet<String>
data = someData; impliedNodes =
count++; variablesMap.get(specifiedOutputVariable).getInputs();
number = count; for (String
} nodeNameIter:impliedNodes) {
/* copy constuctor Node<BpelElement> impliedNode =

* */ namesHashMap.get(nodeNameIter);
/*public Node( Node<T> aNode) { if
data = aNode.data; (impliedNode.containsPrevNodeName(nodeName))
parent = aNode.parent;
children = aNode.children; outDep.add(nodeNameIter);
}*/ }
}
public T getData() { } else {
return data; BpelElement element =
} (BpelElement) aNode.getData();
if (element instanceof FlowImpl) {
public void setData(T data) { /*flow behavior*/
this.data = data; } else if (element instanceof
} SequenceImpl) {
/*sequence behavior*/
public String toString() { } else {
sb.append("{fatherDep="); List<String>
if (fatherDataDep != null) outputVariables = new ArrayList<String>();
if (element instanceof
sb.append(fatherDataDep.getData().getName()); AssignImpl) {
sb.append("|ChildrenDep="); AssignImpl
for(Node<BpelElement> assign = (AssignImpl) element;
childNode:childrenDataDep) { List<String>
outVariablesAssign = assign.getOutputVariables();
sb.append(((ActivityImpl)childNode.getData()).get for(String
Name()); sb.append(";"); outputVar:outVariablesAssign) {
} if
sb.append("}"); (outputVar != null)
return data.toString() + sb.toString()+
"|No=" + getNumber() + "|prevNodes" + outputVariables.add(outputVar);
getPrevPath().toString(); }
184
}
} else if (element
@Override instanceof InvokeImpl) {
public boolean equals(Object obj) { InvokeImpl
if (obj == null) { invoke = (InvokeImpl) element;
return false; if
} (invoke.getOutputVariable() != null)
return false; outputVariables.add(invoke.getOutputVariable());
} } else if (element
final Node<T> otherNode = (Node<T>) obj; instanceof ReceiveImpl) {
ReceiveImpl
return data.equals(otherNode.getData()); receive = (ReceiveImpl) element;
} if
(receive.getOutputVariable() != null)
outputVariables.add(receive.getOutputVariable());
} else if (element
instanceof ReplyImpl || element instanceof EmptyImpl) {
} /*nothing to do
----------------------------------------------------------- here*/
package gui; }
if (outputVariables.size()
import java.awt.BorderLayout; != 0) {
import java.awt.Component; for (String
import java.awt.Container; outVar: outputVariables) {
import java.awt.Dimension;
import java.awt.GridBagConstraints; LinkedHashSet<String> impliedNodes =
import java.awt.GridBagLayout; variablesMap.get(outVar).getInputs();
import java.awt.event.ActionEvent; for
import java.awt.event.ActionListener; (String nodeNameIter:impliedNodes) {
import java.awt.event.ItemEvent;
import java.awt.event.ItemListener; Node<BpelElement> impliedNode =
import java.awt.event.KeyEvent; namesHashMap.get(nodeNameIter);
import java.io.File;
import java.io.FileInputStream; if (impliedNode.containsPrevNodeName(nodeName))
import java.io.FileNotFoundException;
import java.io.IOException; outDep.add(nodeNameIter);
import java.util.ArrayList; }
import java.util.HashMap; }
import java.util.HashSet; }
import java.util.LinkedHashSet;
import java.util.LinkedList; }
import java.util.List; }
import java.util.Set; return outDep;
import java.util.Stack; }
import javax.swing.BorderFactory; public LinkedList<String>

import javax.swing.ButtonGroup; getInputDependencies(String specifiedInputVariable,
import javax.swing.ImageIcon; Node<BpelElement> aNode) {
import javax.swing.JButton; LinkedList<String> inDep = new
import javax.swing.JCheckBoxMenuItem; LinkedList<String>();
import javax.swing.JComboBox; if (specifiedInputVariable != null) {
import javax.swing.JComponent; if
import javax.swing.JFileChooser; (variablesMap.get(specifiedInputVariable) != null) {
import javax.swing.JFrame; LinkedHashSet<String>
import javax.swing.JLabel; impliedNodes =
import javax.swing.JMenu; variablesMap.get(specifiedInputVariable).getOutputs();
import javax.swing.JMenuBar; for (String
import javax.swing.JMenuItem; nodeNameIter:impliedNodes) {
import javax.swing.JPanel; if
import javax.swing.JRadioButtonMenuItem; (aNode.containsPrevNodeName(nodeNameIter))
import javax.swing.JScrollPane;
import javax.swing.JSplitPane; inDep.add(nodeNameIter);
185
import javax.swing.JTextArea; }
import javax.swing.JTree; }
import javax.swing.KeyStroke; } else {
import javax.swing.MenuElement; BpelElement element =
import javax.swing.MenuSelectionManager; (BpelElement) aNode.getData();
import javax.swing.Timer; if (element instanceof FlowImpl) {
import javax.swing.event.TreeSelectionEvent; /*flow behavior*/
import javax.swing.event.TreeSelectionListener; } else if (element instanceof
import javax.swing.plaf.basic.BasicComboBoxUI; SequenceImpl) {
import javax.swing.tree.DefaultMutableTreeNode; /*sequence behavior*/
import javax.swing.tree.DefaultTreeModel; } else {
import javax.swing.tree.TreePath;
import javax.swing.tree.TreeSelectionModel; List<String>
inputVariables = new ArrayList<String>();
import org.xml.sax.InputSource; if (element instanceof
import org.xml.sax.SAXException; AssignImpl) {
import org.xml.sax.XMLReader; AssignImpl
import org.xml.sax.helpers.XMLReaderFactory; assign = (AssignImpl) element;
List<String>
import gui.MyTreeModelListener; inVariablesAssign = assign.getInputVariables();
for(String
import dependency.analyzer.DependencyAnalyzer; inVar:inVariablesAssign) {
if
import sax.parser.SaxParser_v1; (inVar != null)
import bpel.objects.ActivityImpl;
import bpel.objects.BpelElement; inputVariables.add(inVar);
import bpel.objects.ElseIfImpl; }
import bpel.objects.ElseImpl; } else if (element
import bpel.objects.EmptyImpl; instanceof IfImpl) {
import bpel.objects.ExitImpl; IfImpl
import bpel.objects.FlowImpl; ifImplementation = (IfImpl) element;
import bpel.objects.OpaqueActivityImpl; List<String>
import bpel.objects.PartnerLink; inVariablesAssign = ifImplementation.getInputVariables();
import bpel.objects.PickImpl; for(String
import bpel.objects.RethrowImpl; inVar:inVariablesAssign) {
import bpel.objects.ScopeImpl; if
import bpel.objects.SequenceImpl; (inVar != null)
import bpel.objects.WaitImpl;
import bpel.objects.WhileImpl; inputVariables.add(inVar);
import bpel.tree.Node; }
} else if (element
public class DepAnalyzerGui implements ActionListener, instanceof ElseIfImpl) {
ItemListener, TreeSelectionListener{ ElseIfImpl
JTextArea output; elseIfimplementation = (ElseIfImpl) element;
JScrollPane scrollPane; List<String>
String newline = "\n"; inVariablesAssign = elseIfimplementation.getInputVariables();
public final static int ONE_SECOND = 1000; for(String
String operationNames[] = {"addParalelActivity", inVar:inVariablesAssign) {
"addSequencialActivity", "replaceActivity(s)", if
"deleteActivity"}; (inVar != null)
String activityTypeName[] = {"receive", "reply",
"invoke", "assign"}; inputVariables.add(inVar);
JComboBox from = new JComboBox(); }
JComboBox to = new JComboBox(); } else if (element
JComboBox operation = new instanceof InvokeImpl) {
JComboBox(operationNames); InvokeImpl
JComboBox activityType = new invoke = (InvokeImpl) element;
JComboBox(activityTypeName); if
JComboBox inputActVariable = new JComboBox(); (invoke.getInputVariable() != null)
JComboBox outputActVariable = new JComboBox();
private JTree tree; inputVariables.add(invoke.getInputVariable());
protected DefaultTreeModel treeModel; } else if (element
private DefaultMutableTreeNode top; instanceof ReplyImpl) {
JLabel labelFrom; ReplyImpl
186
JLabel labelTo; reply = (ReplyImpl) element;

JLabel operationLabel; if
JLabel activityTypeLabel; (reply.getInputVariable() != null)
JLabel inputActVariableLabel;
JLabel outputActVariableLabel; inputVariables.add(reply.getInputVariable());
JSplitPane splitPane; } else if (element
SaxParser_v1 saxP; instanceof ReceiveImpl || element instanceof EmptyImpl) {
String toSelectedItem = null; /*nothing to do
String fromSelectedItem = null; here*/
String operationSelectedItem = null; }
String activitySelectedItem = null; if (inputVariables.size()
String inputVariableSelectedItem = null; != 0) {
String outputVariableSelectedItem = null; for(String
Node<BpelElement> root; inVar: inputVariables) {
private HashMap<String, SaxParser_v1> parsers = new
HashMap<String, SaxParser_v1>(); LinkedHashSet<String> impliedNodes =
private Set<String> affectedActByDelete = new variablesMap.get(inVar).getOutputs();
HashSet<String>(); for
private Set<String> postAffectedActByInsert = new (String nodeNameIter:impliedNodes) {
HashSet<String>();
private Set<String> prevAffectedActByInsert = new if (aNode.containsPrevNodeName(nodeNameIter))
HashSet<String>();
String currentProcessName =""; inDep.add(nodeNameIter);
}
}
public JMenuBar createMenuBar() { }
JMenuBar menuBar;
JMenu menu, submenu; }
JMenuItem menuItem; }
return inDep;
//Create the menu bar. }
menuBar = new JMenuBar(); }
-------------------------------------------------------
//Build the first menu. package gui;
menu = new JMenu("Menu");
menu.setMnemonic(KeyEvent.VK_A); import javax.swing.event.TreeModelEvent;
menu.getAccessibleContext().setAccessibleDescription( import javax.swing.event.TreeModelListener;
"Menu"); import javax.swing.tree.DefaultMutableTreeNode;
menuBar.add(menu);
class MyTreeModelListener implements TreeModelListener {
//a group of JMenuItems public void treeNodesChanged(TreeModelEvent e) {
menuItem = new JMenuItem("Open File..", DefaultMutableTreeNode node;
KeyEvent.VK_T); node =
//menuItem.setMnemonic(KeyEvent.VK_T); //used (DefaultMutableTreeNode)(e.getTreePath().getLastPathCompone
constructor instead nt());
menuItem.setAccelerator(KeyStroke.getKeyStroke(
KeyEvent.VK_1, ActionEvent.ALT_MASK)); /*
* If the event lists children, then the changed
menuItem.getAccessibleContext().setAccessibleDescription( * node is the child of the node we've already
"This doesn't really do anything"); * gotten. Otherwise, the changed node and the
menuItem.addActionListener(this); * specified node are the same.
menu.add(menuItem); */
int index = e.getChildIndices()[0];

/* Timer timer = new Timer(ONE_SECOND, new node =
ActionListener() { (DefaultMutableTreeNode)(node.getChildAt(index));
public void actionPerformed(ActionEvent evt) {
MenuElement[] path = System.out.println("The user has finished editing the
MenuSelectionManager.defaultManager(). node.");
getSelectedPath(); System.out.println("New value: " + node.getUserObject());
for (int i = 0; i < path.length; i++ ) { }
if (path[i].getComponent() instanceof public void treeNodesInserted(TreeModelEvent e) {
javax.swing.JMenuItem) { }
JMenuItem mi = public void treeNodesRemoved(TreeModelEvent e) {
187
(JMenuItem)path[i].getComponent(); }
if ("".equals(mi.getText())) { public void treeStructureChanged(TreeModelEvent e) {
output.append("ICON-ONLY MENU }
ITEM > "); }
} else { -------------------------------------------------------
output.append(mi.getText() + " > "); package sax.parser;
}
} import java.util.ArrayList;
} import java.util.HashMap;
if (path.length > 0) output.append(newline); import java.util.LinkedHashMap;
} import java.util.LinkedHashSet;
}); import java.util.List;
timer.start();*/ import java.util.Set;
return menuBar; import java.util.Stack;
}
import org.xml.sax.Attributes;
public JSplitPane createHorizontalSplitPane(Container c1, import org.xml.sax.helpers.DefaultHandler;
Container c2){
splitPane = new import bpel.objects.*;
JSplitPane(JSplitPane.HORIZONTAL_SPLIT, import bpel.tree.Node;
c1, c2); import bpel.tree.Tree;
splitPane.setResizeWeight(0.5); enum State {
splitPane.setOneTouchExpandable(true); SEQUENCE, FLOW, PROCESS, ACTIVITY,
splitPane.setContinuousLayout(true); FOREACH, IF, ELSE, ELSEIF, WHILE, REPEATUNTILL,
PICK, DEFAULT
return splitPane; };
}
public JSplitPane createVerticalSplitPane(Container c1, public class SaxParser_v1 extends DefaultHandler{

Container c2){
splitPane = new private Stack<Node<BpelElement>> stack;
JSplitPane(JSplitPane.VERTICAL_SPLIT, private boolean isStackReadyForText;
c1, c2); public boolean partnerLinksSection = false;
splitPane.setResizeWeight(0.5); private Node<BpelElement> startNode = null;
splitPane.setOneTouchExpandable(true); private Node<BpelElement> endNode = null;
splitPane.setContinuousLayout(true); private Boolean assignCopyFlag = false;
private HashMap<String, Node<BpelElement>>
return splitPane; linksHashMap = new HashMap<String, Node<BpelElement>>();
} private HashMap<String, String> variables = new
HashMap<String, String>();
public Container createButtonsPane() { private HashMap<String, Node<BpelElement>>
JPanel contentPane = new JPanel(new outputVariables = new HashMap<String,
BorderLayout()); Node<BpelElement>>();
contentPane.setOpaque(true); private HashMap<String, String> assignHashMap = new
HashMap<String, String>();
GridBagLayout gridbag = new GridBagLayout(); private LinkedHashMap<String, Node<BpelElement>>
GridBagConstraints c = new GridBagConstraints(); namesHashMap = new LinkedHashMap<String,
contentPane.setLayout(gridbag); Node<BpelElement>>();
private HashMap<String, VariableUsage> variablesMap = new
labelFrom = new JLabel("from:"); HashMap<String, VariableUsage>();
labelFrom.setLabelFor(from); private HashMap<String, PartnerLink> partners = new
labelTo = new JLabel("to:"); HashMap<String, PartnerLink>();
labelTo.setLabelFor(to); private String fromAssignPart = null;
operationLabel = new JLabel("desired operation:"); private Boolean copyFromState = false;
operationLabel.setLabelFor(operation); private State inState;
activityTypeLabel = new JLabel("activity type:"); StringBuffer sb;
activityTypeLabel.setLabelFor(activityType); private boolean conditionExpressionState = false;
inputActVariableLabel = new JLabel("input variable:");
inputActVariableLabel.setLabelFor(inputActVariable);
outputActVariableLabel = new JLabel("output public void addPartnerLink(String aPartnerLinkName,
variable:"); PartnerLink aPartnerLink) {
partners.put(aPartnerLinkName,
outputActVariableLabel.setLabelFor(outputActVariable); aPartnerLink);
188
//from.setPreferredSize(new Dimension(50, 25)); }

//to.setPreferredSize(new Dimension(50, 25)); public List<PartnerLink> getPartners() {
to.setVisible(false); return new
from.setVisible(false); ArrayList<PartnerLink>(partners.values());
operation.setVisible(false); }
labelFrom.setVisible(false); public boolean matchPartnerLink(String
labelTo.setVisible(false); aPartnerRole){
operationLabel.setVisible(false); ArrayList<PartnerLink> partnerLinks = new
activityTypeLabel.setVisible(false); ArrayList<PartnerLink>(partners.values());
inputActVariableLabel.setVisible(false); for (PartnerLink p: partnerLinks) {
outputActVariableLabel.setVisible(false); if
(p.getMyRole().compareTo(aPartnerRole) == 0)
operation.setSelectedIndex(2); return true;
activityType.setVisible(false); }
inputActVariable.setVisible(false); return false;
outputActVariable.setVisible(false); }
public PartnerLink getPartner(String aPartnerName) {
from.addActionListener(new ActionListener() { return partners.get(aPartnerName);
public void }
actionPerformed(ActionEvent event) {
JComboBox jc = public void printVariablesMap() {
(JComboBox)event.getSource(); StringBuffer sb = new StringBuffer();
fromSelectedItem = Set<String> keys = variablesMap.keySet();
(String)jc.getSelectedItem(); for (String variable:keys) {
} sb.append("variable:" + variable + "::");
});
sb.append(variablesMap.get(variable).toString());
to.addActionListener(new ActionListener() { sb.append("\n");
public void }
JComboBox jc = System.out.println(sb.toString());
(JComboBox)event.getSource(); }
toSelectedItem =
(String)jc.getSelectedItem();
} public Set<String> getKeysFromNamesHashMap() {
}); return namesHashMap.keySet();
operation.addActionListener(new ActionListener() }
{ public Set<String> getVariableNames() {
public void return variables.keySet();
actionPerformed(ActionEvent event) { }
JComboBox jc =
(JComboBox)event.getSource(); public Node<BpelElement>
operationSelectedItem = getValueFromNamesHashMap(String key) {
(String)jc.getSelectedItem(); return namesHashMap.get(key);
}
if
(operationSelectedItem.compareTo("addParalelActivity") public LinkedHashMap<String, Node<BpelElement>>
==0 getNamesMap()
|| {
operationSelectedItem.compareTo("addSequencialActivity") return namesHashMap;
== 0 }
||
operationSelectedItem.compareTo("replaceActivity(s)") ==0 public HashMap<String, VariableUsage> getVariablesMap() {
){ return variablesMap;
}
inputActVariable.removeAllItems();
public Node<BpelElement> getRootNode() {
outputActVariable.removeAllItems(); return startNode;
Set<String> varNames = }
saxP.getVariableNames(); public Node<BpelElement> getEndNode() {
for(String name:varNames) { return endNode;
}
inputActVariable.addItem(name);
189
outputActVariable.addItem(name);
} public SaxParser_v1() {
inputActVariable.addItem(" stack = new Stack<Node<BpelElement>>();
"); isStackReadyForText = false;
outputActVariable.addItem(" inState = State.DEFAULT;
"); }
private String getTagAttribute( String uri, String localName,
activityType.setVisible(true); Attributes attribs) {
return attribs.getValue(localName);
activityTypeLabel.setVisible(true); }
inputActVariable.setVisible(true); public void startElement( String uri, String localName, String

qName,
inputActVariableLabel.setVisible(true); Attributes attribs ) {
} isStackReadyForText = false;
else if // if next element is complex, push a new instance on
(operationSelectedItem.compareTo("deleteActivity") == 0) { the stack
// if element has attributes, set them in the new instance
activityType.setVisible(false); if( localName.equals( "process" ) ) {
ProcessImpl p = new ProcessImpl();
activityTypeLabel.setVisible(false); p.setName(getTagAttribute(uri, "name",
attribs));
inputActVariable.setVisible(false); Node<BpelElement> root = new
Node<BpelElement>(p);
inputActVariableLabel.setVisible(false); namesHashMap.put("process", root);
startNode = root;
outputActVariable.setVisible(false); endNode = root;
stack.push(root);
outputActVariableLabel.setVisible(false);
} }else if (localName.equals("partnerLinks")){
} partnerLinksSection = true;
}); }else if (localName.equals("partnerLink") &&
partnerLinksSection) {
activityType.addActionListener(new PartnerLink partner = new PartnerLink();
ActionListener() { partner.setName(getTagAttribute(uri,
public void "name", attribs));
JComboBox jc = partner.setPartnerLinkType(getTagAttribute(uri,
(JComboBox)event.getSource(); "partnerLinkType", attribs));
activitySelectedItem = partner.setMyRole(getTagAttribute(uri,
(String)jc.getSelectedItem(); "myRole", attribs));
if partner.setPartnerRole(getTagAttribute(uri,
(activitySelectedItem.compareTo("receive") == 0) { "partnerRole", attribs));
/*Node<BpelElement> nodeStack =
inputActVariable.setVisible(false); (Node<BpelElement>)stack.peek();
inputActVariableLabel.setVisible(false); if (nodeStack.getData() instanceof

ProcessImpl) {
outputActVariable.setVisible(true); ProcessImpl proc = (ProcessImpl)
nodeStack.getData();
outputActVariableLabel.setVisible(true); proc.addPartnerLink(partner);
} else if }*/
(activitySelectedItem.compareTo("invoke") == 0 this.addPartnerLink(partner.getName(),
|| partner);
activitySelectedItem.compareTo("assign") == 0) { }
else if( localName.equals( "sequence" ) ) {
inputActVariable.setVisible(true); SequenceImpl s = new SequenceImpl();
Node<BpelElement> node = new
inputActVariableLabel.setVisible(true); Node<BpelElement>(s);
outputActVariable.setVisible(true); namesHashMap.put(node.getData().getName(), node);

endNode = node;
outputActVariableLabel.setVisible(true); Node<BpelElement> nodeStack =
190
} else if (Node<BpelElement>)stack.peek();
(activitySelectedItem.compareTo("reply") == 0) { node.addParent(nodeStack);
nodeStack.addChildNode(node);
inputActVariable.setVisible(true); /**
* add previous nodes to current node
inputActVariableLabel.setVisible(true); */
//
outputActVariable.setVisible(false); node.addAllNodesToPrevPath(nodeStack.getPrevPath()
);
outputActVariableLabel.setVisible(false); //
} node.addNodeToPrevPath(nodeStack.getData().getNa
} me());
});
/**
inputActVariable.addActionListener(new * links
ActionListener() { */
public void createOrder(node, nodeStack);
JComboBox jc = // if (State.SEQUENCE == determineState()) {
(JComboBox)event.getSource(); // if (nodeStack.getLastNodeInSeq()
inputVariableSelectedItem = == null) {
(String)jc.getSelectedItem(); //
} nodeStack.setLastNodeInSeq(node);
}); // /**
// * add previous nodes to current
outputActVariable.addActionListener(new node
ActionListener() { // */
public void //
actionPerformed(ActionEvent event) { node.addAllNodesToPrevPath(nodeStack.getPrevPath()
JComboBox jc = );
(JComboBox)event.getSource(); //
outputVariableSelectedItem = node.addNodeToPrevPath(nodeStack.getData().getNa
(String)jc.getSelectedItem(); me());
} // }
}); // else {
// Node<BpelElement>
c.anchor = GridBagConstraints.WEST; previusPathNode = nodeStack.getLastNodeInSeq();
c.gridwidth = GridBagConstraints.RELATIVE; //next- //
to-last previusPathNode.addLink(node);
c.fill = GridBagConstraints.NONE; //reset to default //
c.weightx = 0.0; //reset to default nodeStack.setLastNodeInSeq(node);
contentPane.add(labelFrom, c); // /**
c.gridwidth = GridBagConstraints.REMAINDER; // * add previous nodes to current
//end row node
c.fill = GridBagConstraints.HORIZONTAL; // */
c.weightx = 0.0; //
contentPane.add(from, c); node.addAllNodesToPrevPath(previusPathNode.getPre
vPath());
c.anchor = GridBagConstraints.WEST; //
c.gridwidth = GridBagConstraints.RELATIVE; //next- node.addNodeToPrevPath(previusPathNode.getData().
to-last getName());
c.fill = GridBagConstraints.NONE; //reset to default //
c.weightx = 0.0; //reset to default // }
contentPane.add(labelTo, c); // } else {
c.gridwidth = GridBagConstraints.REMAINDER; // /**
//end row // * add previous nodes to current node
c.fill = GridBagConstraints.HORIZONTAL; // */
c.weightx = 0.0; //
contentPane.add(to, c); node.addAllNodesToPrevPath(nodeStack.getPrevPath()
);
c.anchor = GridBagConstraints.WEST; //
c.gridwidth = GridBagConstraints.RELATIVE; //next- node.addNodeToPrevPath(nodeStack.getData().getNa
to-last me());
c.fill = GridBagConstraints.NONE; //reset to default // }
191
c.weightx = 0.0; //reset to default stack.push(node);

contentPane.add(operationLabel, c);
c.gridwidth = GridBagConstraints.REMAINDER; }else if( localName.equals( "receive" ) ) {
//end row /*ActivityImpl a = new ActivityImpl();
c.fill = GridBagConstraints.HORIZONTAL; */
c.weightx = 0.0; ReceiveImpl a = new ReceiveImpl();
contentPane.add(operation, c); a.setName(getTagAttribute(uri, "name",
attribs));
c.anchor = GridBagConstraints.WEST; a.setPartnerLink(getTagAttribute(uri,
c.gridwidth = GridBagConstraints.RELATIVE; //next- "partnerLink", attribs));
to-last a.setType(ActivityType.RECEIVE);
c.fill = GridBagConstraints.NONE; //reset to default String variable = getTagAttribute(uri,
c.weightx = 0.0; //reset to default "variable", attribs);
contentPane.add(activityTypeLabel, c); //a.setVariable(variables.get(variable));
c.gridwidth = GridBagConstraints.REMAINDER; a.setOutputVariable(variable);
//end row Node<BpelElement> node = new
c.fill = GridBagConstraints.HORIZONTAL; Node<BpelElement>(a);
c.weightx = 0.0;
contentPane.add(activityType, c); namesHashMap.put(node.getData().getName(), node);
endNode = node;
/**
c.anchor = GridBagConstraints.WEST; * Data dependency for output
c.gridwidth = GridBagConstraints.RELATIVE; //next- */
to-last if (variable != null) {
c.fill = GridBagConstraints.NONE; //reset to default Node<BpelElement> oldValue =
c.weightx = 0.0; //reset to default outputVariables.put(variable, node);
contentPane.add(inputActVariableLabel, c);
c.gridwidth = GridBagConstraints.REMAINDER; if
//end row (!variablesMap.containsKey(variable)) {
c.fill = GridBagConstraints.HORIZONTAL; VariableUsage vu = new
c.weightx = 0.0; VariableUsage();
contentPane.add(inputActVariable, c);
vu.addOutput(node.getData().getName());
c.anchor = GridBagConstraints.WEST; variablesMap.put(variable, vu);

c.gridwidth = GridBagConstraints.RELATIVE; //next- } else {
to-last VariableUsage vu =
c.fill = GridBagConstraints.NONE; //reset to default variablesMap.get(variable);
c.weightx = 0.0; //reset to default
contentPane.add(outputActVariableLabel, c); vu.addOutput(node.getData().getName());
c.gridwidth = GridBagConstraints.REMAINDER; }
//end row
c.fill = GridBagConstraints.HORIZONTAL; }
c.weightx = 0.0;
contentPane.add(outputActVariable, c); Node<BpelElement> nodeStack =
(Node<BpelElement>)stack.peek();
node.addParent(nodeStack);
contentPane.validate(); nodeStack.addChildNode(node);
contentPane.setBorder( /**
BorderFactory.createCompoundBorder( * links
*/
BorderFactory.createTitledBorder("Operations"), createOrder(node, nodeStack);
BorderFactory.createEmptyBorder(5,5,5,5))); // if (State.SEQUENCE == determineState()) {

return contentPane; // if (nodeStack.getLastNodeInSeq()
} == null) {
public Container createContentPane() { //
//Create the content-pane-to-be. nodeStack.setLastNodeInSeq(node);
JPanel contentPane = new JPanel(new BorderLayout()); // /**
contentPane.setOpaque(true); // * add previous nodes to current
node
//Create a scrolled text area. // */
output = new JTextArea(5, 30); //
output.setEditable(false); node.addAllNodesToPrevPath(nodeStack.getPrevPath()
192
scrollPane = new JScrollPane(output); );

//
//Add the text area to the content pane. node.addNodeToPrevPath(nodeStack.getData().getNa
contentPane.add(scrollPane, BorderLayout.CENTER); me());
contentPane.setBorder( // }
BorderFactory.createCompoundBorder( // else {
BorderFactory.createTitledBorder("Results"), previusPathNode = nodeStack.getLastNodeInSeq();
//
BorderFactory.createEmptyBorder(5,5,5,5))); previusPathNode.addLink(node);
//
return contentPane; nodeStack.setLastNodeInSeq(node);
} // /**
node
public static void buildTree(Node<BpelElement> aNode, // */
DefaultMutableTreeNode parent) { //
DefaultMutableTreeNode currentNode = node.addAllNodesToPrevPath(previusPathNode.getPre
new DefaultMutableTreeNode(aNode.getData().getName()); vPath());
parent.add(currentNode); //
if (aNode.getChildrenNodes().size() == 0 ) node.addNodeToPrevPath(previusPathNode.getData().
return; getName());
for(Node<BpelElement> //
childNode:aNode.getChildrenNodes()) { // }
buildTree(childNode, currentNode); // } else {
} // /**
// * add previous nodes to current node
} // */
//
node.addAllNodesToPrevPath(nodeStack.getPrevPath()
public Container createTreePane() { );
//
top = new DefaultMutableTreeNode("Process"); node.addNodeToPrevPath(nodeStack.getData().getNa
treeModel = new DefaultTreeModel(top); me());
treeModel.addTreeModelListener(new // }
MyTreeModelListener()); stack.push(node);
tree = new JTree(treeModel);
tree.setEditable(false); } else if (localName.equals("invoke")) {
tree.getSelectionModel().setSelectionMode /*ActivityImpl a = new ActivityImpl();*/
InvokeImpl a = new InvokeImpl();
(TreeSelectionModel.SINGLE_TREE_SELECTION); a.setName(getTagAttribute(uri, "name",
tree.setShowsRootHandles(true); attribs));
tree.addTreeSelectionListener(new a.setPartnerLink(getTagAttribute(uri,
TreeSelectionListener() { "partnerLink", attribs));
public void valueChanged(TreeSelectionEvent e) { a.setType(ActivityType.INVOKE);
DefaultMutableTreeNode node = String inputVariableName =
(DefaultMutableTreeNode) getTagAttribute(uri, "inputVariable", attribs);
tree.getLastSelectedPathComponent();
//a.setInputVariable(variables.get(inputVariableName))
/* if nothing is selected */ ;
if (node == null) return; a.setInputVariable(inputVariableName);
String outputVariableName =
/* retrieve the node that was selected */ getTagAttribute(uri, "outputVariable", attribs);
TreePath currentSelection =
tree.getSelectionPath(); //a.setOutputVariable(variables.get(outputVariableNam
if (currentSelection.getPathCount() > 1) e));
{ a.setOutputVariable(outputVariableName);
String processName = Node<BpelElement> node = new
currentSelection.getPathComponent(1).toString(); Node<BpelElement>(a);
System.out.println(processName);
saxP = parsers.get(processName); namesHashMap.put(node.getData().getName(), node);
if endNode = node;
(processName.compareTo(currentProcessName) != 0) /**
{ repopulateSelections(); * Data dependecies for input and output
193
currentProcessName = */
processName; if (inputVariableName != null) {
} Node<BpelElement>
} fatherDataDependency =
} outputVariables.get(inputVariableName);
}); if (fatherDataDependency != null) {
//Create the scroll pane and add the tree to it. node.addFatherDataDep(fatherDataDependency);
JScrollPane treeView = new JScrollPane(tree);
fatherDataDependency.addChildrenDataDep(node);
treeView.setBorder( }
BorderFactory.createCompoundBorder(
BorderFactory.createTitledBorder("Tree if
view"), (!variablesMap.containsKey(inputVariableName)) {
VariableUsage vu = new
BorderFactory.createEmptyBorder(5,5,5,5))); VariableUsage();
return treeView;
} vu.addInput(node.getData().getName());
public void repopulateTree(Node<BpelElement> variablesMap.put(inputVariableName, vu);

rootNode, DefaultMutableTreeNode theTop) { } else {
//theTop.removeAllChildren(); VariableUsage vu =
variablesMap.get(inputVariableName);
buildTree(rootNode, theTop);
treeModel.reload(); vu.addInput(node.getData().getName());
for (int i = 0; i < tree.getRowCount(); i++) { }
tree.expandRow(i); }
} if (outputVariableName != null) {
Node<BpelElement> oldValue =
} outputVariables.put(outputVariableName, node);
// public Container createTreePane(Node<BpelElement> if

rootNode) { (!variablesMap.containsKey(outputVariableName)) {
// DefaultMutableTreeNode top = VariableUsage vu = new
// new DefaultMutableTreeNode("Process"); VariableUsage();
//
// buildTree(rootNode, top); vu.addOutput(node.getData().getName());
//
// //Create a tree that allows one selection at a time. variablesMap.put(outputVariableName, vu);
// tree = new JTree(top); } else {
// tree.getSelectionModel().setSelectionMode VariableUsage vu =
// variablesMap.get(outputVariableName);
(TreeSelectionModel.SINGLE_TREE_SELECTION);
// vu.addOutput(node.getData().getName());
// //Listen for when the selection changes. }
// //tree.addTreeSelectionListener(this); }
// Node<BpelElement> nodeStack =
// //Create the scroll pane and add the tree to it. (Node<BpelElement>)stack.peek();
// JScrollPane treeView = new JScrollPane(tree); node.addParent(nodeStack);
// return treeView; nodeStack.addChildNode(node);
// } /**
* links
public void repopulateSelections() { */
from.removeAllItems(); createOrder(node, nodeStack);
to.removeAllItems();
Set<String> nodeNames = // if (State.SEQUENCE == determineState()) {
saxP.getKeysFromNamesHashMap(); // if (nodeStack.getLastNodeInSeq()
for(String aNodeName:nodeNames) { == null) {
from.addItem(aNodeName); //
to.addItem(aNodeName); nodeStack.setLastNodeInSeq(node);
} // /**
to.setVisible(true); // * add previous nodes to current
from.setVisible(true); node
operation.setVisible(true); // */
194
labelFrom.setVisible(true); //
labelTo.setVisible(true); node.addAllNodesToPrevPath(nodeStack.getPrevPath()
operationLabel.setVisible(true); );
} //
node.addNodeToPrevPath(nodeStack.getData().getNa
public void actionPerformed(ActionEvent e) { me());
// }
if (e.getSource() instanceof JMenuItem) { // else {
JMenuItem source = // Node<BpelElement>
(JMenuItem)(e.getSource()); previusPathNode = nodeStack.getLastNodeInSeq();
/*String s = "Action event detected." //
+ newline previusPathNode.addLink(node);
+ " Event source: " + //
source.getText() nodeStack.setLastNodeInSeq(node);
+ " (an instance of " + // /**
getClassName(source) + ")"; // * add previous nodes to current
output.append(s + newline); node
// */
output.setCaretPosition(output.getDocument().getLength()); //
*/ node.addAllNodesToPrevPath(previusPathNode.getPre
String sourceOfAction = source.getText(); vPath());
if (sourceOfAction.compareTo("Open File..") //
== 0) { node.addNodeToPrevPath(previusPathNode.getData().
Chooser frame = new Chooser(); getName());
output.setText(frame.fileName); // }
try { // } else {
root = // /**
parseBpelFile(frame.fileName); // * add previous nodes to current node
StringBuffer sb = new // */
StringBuffer(); //
printGraph(root,"", sb); node.addAllNodesToPrevPath(nodeStack.getPrevPath()
repopulateTree(root, top); );
output.setText(sb.toString()); //
currentProcessName = node.addNodeToPrevPath(nodeStack.getData().getNa
root.getData().getName(); me());
repopulateSelections(); // }
stack.push(node);
System.out.println(saxP.getKeysFromNamesHash } else if (localName.equals("reply")) {
Map().toString()); /*ActivityImpl a = new ActivityImpl();*/
} catch (Exception exc) { ReplyImpl a = new ReplyImpl();
exc.printStackTrace(); a.setName(getTagAttribute(uri, "name",
} attribs));
} a.setPartnerLink(getTagAttribute(uri,
} "partnerLink", attribs));
else if (e.getSource() instanceof JButton){ a.setType(ActivityType.REPLY);
JButton sourceButton = (JButton) e.getSource(); String variable = getTagAttribute(uri,
if (sourceButton.getText().compareTo("Analyze") "variable", attribs);
== 0) { a.setInputVariable(variables.get(variable));
System.out.println("Analyze button Node<BpelElement> node = new
pushed"); Node<BpelElement>(a);
System.out.println("fromSelectedItem="
+ fromSelectedItem); namesHashMap.put(node.getData().getName(), node);
System.out.println("toSelectedItem=" + endNode = node;
toSelectedItem); /**
* Data dependency for input
System.out.println("operationSelectedItem=" + */
operationSelectedItem); if (variable != null) {
Node<BpelElement>
if fatherDataDependency = outputVariables.get(variable);
(operationSelectedItem.compareTo("deleteActivity") == 0) { if (fatherDataDependency != null) {
DependencyAnalyzer da = new
DependencyAnalyzer(saxP.getNamesMap(), node.addFatherDataDep(fatherDataDependency);
saxP.getVariablesMap());
Stack<Node<BpelElement>> fatherDataDependency.addChildrenDataDep(node);
195
stack = new Stack<Node<BpelElement>>(); }
//da.locateDirectImpactNodes_v3(root, "Assign1", if
"Receive1S2", stack, false, false); (!variablesMap.containsKey(variable)) {
VariableUsage vu = new
da.locateDirectImpactNodes_v5(saxP.getValueFro VariableUsage();
mNamesHashMap(fromSelectedItem),
saxP.getValueFromNamesHashMap(fromSelectedItem), vu.addInput(node.getData().getName());
saxP.getValueFromNamesHashMap(toSelectedItem), stack);
variablesMap.put(variable, vu);
ArrayList<Node<BpelElement>> sequence = new } else {
ArrayList<Node<BpelElement>>(); VariableUsage vu =
while(!stack.empty()) { variablesMap.get(variable);
Node<BpelElement>
node = (Node<BpelElement>)stack.pop(); vu.addInput(node.getData().getName());
sequence.add(0, }
node);
}
output.setText(""); }
for (Node<BpelElement> Node<BpelElement> nodeStack =
element: sequence) { (Node<BpelElement>)stack.peek();
output.append(element.getData().getName() + " nodeStack.addChildNode(node);
implies{"); /**
LinkedList<String> * links
outDepNameList = da.getOutputDependencies(null, */
element); createOrder(node, nodeStack);
for (String
depListName : outDepNameList) { // if (State.SEQUENCE == determineState()) {
// if (nodeStack.getLastNodeInSeq()
output.append(depListName + "|"); == null) {
} //
/*for nodeStack.setLastNodeInSeq(node);
(Node<BpelElement> childDataDep: // /**
element.getChildrenDataDep()) { // * add previous nodes to current
node
output.append(childDataDep.getData().getName() // */
+ "|"); //
}*/ node.addAllNodesToPrevPath(nodeStack.getPrevPath()
);
output.append("}\n"); //
if (element.getData() node.addNodeToPrevPath(nodeStack.getData().getNa
instanceof ActivityImpl) { me());
// }
ActivityImpl act = (ActivityImpl) // else {
element.getData(); // Node<BpelElement>
String previusPathNode = nodeStack.getLastNodeInSeq();
partLinkName = act.getPartnerLink(); //
if previusPathNode.addLink(node);
(partLinkName != null) { //
nodeStack.setLastNodeInSeq(node);
PartnerLink partLink = // /**
saxP.getPartner(partLinkName); // * add previous nodes to current
node
String partnerRole = partLink.getPartnerRole(); // */
//
for (String processNameIterator:parsers.keySet()) { node.addAllNodesToPrevPath(previusPathNode.getPre
vPath());
if //
(processNameIterator.compareTo(currentProcessName) != node.addNodeToPrevPath(previusPathNode.getData().
0) getName());
//
{ // }
// } else {
196
if // /**
(parsers.get(processNameIterator).matchPartnerLink(partner // * add previous nodes to current node
Role)){ // */
//
output.append(element.getData().getName() + " );
implies process:"); //
me());
output.append(processNameIterator); // }
output.append("\n"); stack.push(node);
} else if (localName.equals("assign")) {
} AssignImpl assignAct = new AssignImpl();
assignAct.setName(getTagAttribute(uri,
"name", attribs));
Node<BpelElement> node = new
} Node<BpelElement>(assignAct);
}
} namesHashMap.put(node.getData().getName(), node);
}
} endNode = node;
Node<BpelElement> nodeStack =
} else if (Node<BpelElement>)stack.peek();
(operationSelectedItem.compareTo("addSequencialActivity" node.addParent(nodeStack);
) == 0) { nodeStack.addChildNode(node);
output.setText(""); /**
DependencyAnalyzer da = new * links
DependencyAnalyzer(saxP.getNamesMap(), */
saxP.getVariablesMap()); createOrder(node, nodeStack);
Stack<Node<BpelElement>>
stack = new Stack<Node<BpelElement>>(); // if (State.SEQUENCE == determineState()) {
// if (nodeStack.getLastNodeInSeq()
da.locateDirectImpactNodes_v5(saxP.getValueFro == null) {
mNamesHashMap(fromSelectedItem), //
saxP.getValueFromNamesHashMap(fromSelectedItem), nodeStack.setLastNodeInSeq(node);
saxP.getValueFromNamesHashMap(toSelectedItem), stack); // /**
ArrayList<Node<BpelElement>> sequence = new node
ArrayList<Node<BpelElement>>(); // */
try { //
System.out.println("stack size=" + stack.size()); );
if (stack.size() != 2) //
throw new node.addNodeToPrevPath(nodeStack.getData().getNa
Exception("For sequencial adding an activity 2 consecutive me());
nodes should be selected"); // }
} catch // else {
(Exception e1) { // Node<BpelElement>
previusPathNode = nodeStack.getLastNodeInSeq();
e1.printStackTrace(); //
} previusPathNode.addLink(node);
Node<BpelElement> //
frontNode = (Node<BpelElement>)stack.pop(); nodeStack.setLastNodeInSeq(node);
Node<BpelElement> endNode // /**
= (Node<BpelElement>)stack.pop(); // * add previous nodes to current
node
if ( // */
activitySelectedItem.compareTo("invoke") == 0 || //
activitySelectedItem.compareTo("assign")==0) { node.addAllNodesToPrevPath(previusPathNode.getPre
vPath());
output.append("Adding of a " + //
activitySelectedItem + " depends on{"); node.addNodeToPrevPath(previusPathNode.getData().
LinkedList<String> getName());
inDepNameList = //
197
da.getInputDependencies(inputVariableSelectedItem, // }
frontNode); // } else {
// /**
prevAffectedActByInsert = new // * add previous nodes to current node
HashSet<String>(inDepNameList); // */
for (String //
depListName : prevAffectedActByInsert) { node.addAllNodesToPrevPath(nodeStack.getPrevPath()
);
output.append(depListName + "|"); //
} node.addNodeToPrevPath(nodeStack.getData().getNa
me());
output.append("}\n"); // }
stack.push(node);
output.append("Adding of a " + }
activitySelectedItem + " implies{"); else if (localName.equals("exit")) {
LinkedList<String> ExitImpl exitImpl = new ExitImpl();
outDepNameList = Node<BpelElement> node = new
da.getOutputDependencies(outputVariableSelectedItem, Node<BpelElement>(exitImpl);
endNode);
postAffectedActByInsert = new namesHashMap.put(node.getData().getName(), node);

HashSet<String>(outDepNameList); endNode = node;
for (String Node<BpelElement> nodeStack =
depListName : postAffectedActByInsert) { (Node<BpelElement>)stack.peek();
output.append(depListName + "|"); nodeStack.addChildNode(node);
}
createOrder(node, nodeStack);
output.append("}\n");
stack.push(node);
} else if }
(activitySelectedItem.compareTo("receive") == 0) { else if (localName.equals("throw")) {
ThrowImpl throwImpl = new ThrowImpl();
output.append("Adding of a " + Node<BpelElement> node = new
activitySelectedItem + " implies{"); Node<BpelElement>(throwImpl);
LinkedList<String>
outDepNameList = throwImpl.setName(getTagAttribute(uri,
da.getOutputDependencies(outputVariableSelectedItem, "name", attribs));
endNode); throwImpl.setType(ActivityType.THROW);
String variable = getTagAttribute(uri,
postAffectedActByInsert = new "faultVariable", attribs);
HashSet<String>(outDepNameList);
for (String throwImpl.setInputVariable(variables.get(variable));
depListName : postAffectedActByInsert) {
namesHashMap.put(node.getData().getName(), node);
output.append(depListName + "|"); endNode = node;
} /**
* Data dependency for input
output.append("}\n"); */
if (variable != null) {
} else if Node<BpelElement>
(activitySelectedItem.compareTo("reply") == 0) { fatherDataDependency = outputVariables.get(variable);
if (fatherDataDependency != null) {
output.append("Adding of a " +
activitySelectedItem + " depends on{"); node.addFatherDataDep(fatherDataDependency);
LinkedList<String>
inDepNameList = fatherDataDependency.addChildrenDataDep(node);
da.getInputDependencies(inputVariableSelectedItem, }
frontNode);
if
prevAffectedActByInsert = new (!variablesMap.containsKey(variable)) {
HashSet<String>(inDepNameList); VariableUsage vu = new
198
for (String VariableUsage();

depListName : prevAffectedActByInsert) {
vu.addInput(node.getData().getName());
output.append(depListName + "|");
} variablesMap.put(variable, vu);
} else {
output.append("}\n"); VariableUsage vu =
} variablesMap.get(variable);
// while(!stack.empty()) {
// Node<BpelElement> vu.addInput(node.getData().getName());
node = (Node<BpelElement>)stack.pop(); }
// sequence.add(0,
node);
// } }
// output.setText(""); Node<BpelElement> nodeStack =
// for (Node<BpelElement> (Node<BpelElement>)stack.peek();
element: sequence) { node.addParent(nodeStack);
// nodeStack.addChildNode(node);
output.append(element.getData().getName() + "
implies{"); createOrder(node, nodeStack);
// LinkedList<String>
outDepNameList = da.getOutputDependencies(null, stack.push(node);
element); }
// for (String else if (localName.equals("rethrow")) {
depListName : outDepNameList) { RethrowImpl rethrowImpl = new
// RethrowImpl();
output.append(depListName + "|"); Node<BpelElement> node = new
// } Node<BpelElement>(rethrowImpl);
// /*for
(Node<BpelElement> childDataDep:
element.getChildrenDataDep()) { namesHashMap.put(node.getData().getName(), node);
// endNode = node;
output.append(childDataDep.getData().getName() Node<BpelElement> nodeStack =
+ "|"); (Node<BpelElement>)stack.peek();
// }*/ node.addParent(nodeStack);
// nodeStack.addChildNode(node);
// createOrder(node, nodeStack);
// }
stack.push(node);
} else if }
(operationSelectedItem.compareTo("addParalelActivity") == else if (localName.equals("wait")) {
0) { WaitImpl waitImpl = new WaitImpl();
output.setText(""); Node<BpelElement> node = new
DependencyAnalyzer da = new Node<BpelElement>(waitImpl);
DependencyAnalyzer(saxP.getNamesMap(),
saxP.getVariablesMap());
Node<BpelElement> endNode = node;
frontNode = Node<BpelElement> nodeStack =
saxP.getValueFromNamesHashMap(fromSelectedItem); (Node<BpelElement>)stack.peek();
Node<BpelElement> endNode node.addParent(nodeStack);
= saxP.getValueFromNamesHashMap(toSelectedItem); nodeStack.addChildNode(node);
if ( createOrder(node, nodeStack);
activitySelectedItem.compareTo("invoke") == 0 ||
activitySelectedItem.compareTo("assign")==0) { stack.push(node);
}
output.append("Added "+ activitySelectedItem + " else if (localName.equals("empty")) {
depends on{"); EmptyImpl emptyImpl = new EmptyImpl();
LinkedList<String> Node<BpelElement> node = new
inDepNameList = Node<BpelElement>(emptyImpl);
da.getInputDependencies(inputVariableSelectedItem,
199
frontNode);
prevAffectedActByInsert = new endNode = node;
HashSet<String>(inDepNameList); Node<BpelElement> nodeStack =
for (String (Node<BpelElement>)stack.peek();
depListName : prevAffectedActByInsert) { node.addParent(nodeStack);
} createOrder(node, nodeStack);
output.append("}\n"); stack.push(node);
}
else if (localName.equals("opaqueActivity")) {
output.append("Added " + activitySelectedItem + " OpaqueActivityImpl opaqueActivityImpl =
implies{"); new OpaqueActivityImpl();
LinkedList<String> Node<BpelElement> node = new
outDepNameList = Node<BpelElement>(opaqueActivityImpl);
da.getOutputDependencies(outputVariableSelectedItem,
endNode);
postAffectedActByInsert = new endNode = node;
HashSet<String>(outDepNameList); Node<BpelElement> nodeStack =
for (String (Node<BpelElement>)stack.peek();
depListName : postAffectedActByInsert) { node.addParent(nodeStack);
output.append("}\n"); stack.push(node);
}
/*activities (all children) inside the flow are executed in
} else if parallel*/
(activitySelectedItem.compareTo("receive") == 0) { else if( localName.equals( "flow" ) ) {
FlowImpl f = new FlowImpl();
output.append("Adding of a " + Node<BpelElement> node = new
activitySelectedItem + " implies{"); Node<BpelElement>(f);
LinkedList<String>
outDepNameList = namesHashMap.put(node.getData().getName(), node);
da.getOutputDependencies(outputVariableSelectedItem, endNode = node;
endNode); Node<BpelElement> nodeStack =
postAffectedActByInsert = new node.addParent(nodeStack);
HashSet<String>(outDepNameList); nodeStack.addChildNode(node);
for (String /**
depListName : postAffectedActByInsert) { * links
*/
output.append(depListName + "|"); createOrder(node, nodeStack);
}
// if (State.SEQUENCE == determineState()) {
output.append("}\n"); // if (nodeStack.getLastNodeInSeq()
== null) {
} else if //
(activitySelectedItem.compareTo("reply") == 0) { nodeStack.setLastNodeInSeq(node);
// /**
output.append("Adding of a " + // * add previous nodes to current
activitySelectedItem + " depends on{"); node
LinkedList<String> // */
inDepNameList = //
da.getInputDependencies(inputVariableSelectedItem, node.addAllNodesToPrevPath(nodeStack.getPrevPath()
frontNode); );
//
prevAffectedActByInsert = new node.addNodeToPrevPath(nodeStack.getData().getNa
HashSet<String>(inDepNameList); me());
for (String // }
200
depListName : prevAffectedActByInsert) { // else {

output.append(depListName + "|"); previusPathNode = nodeStack.getLastNodeInSeq();
} //
previusPathNode.addLink(node);
output.append("}\n"); //
} nodeStack.setLastNodeInSeq(node);
// /**
} else if node
(operationSelectedItem.compareTo("replaceActivity(s)") == // */
0) { //
// affectedActByDelete.clear(); node.addAllNodesToPrevPath(previusPathNode.getPre
// vPath());
postAffectedActByInsert.clear(); //
// node.addNodeToPrevPath(previusPathNode.getData().
prevAffectedActByInsert.clear(); getName());
DependencyAnalyzer da = new //
DependencyAnalyzer(saxP.getNamesMap(), // }
saxP.getVariablesMap()); // } else {
Stack<Node<BpelElement>> // /**
stack = new Stack<Node<BpelElement>>(); // * add previous nodes to current node
// */
//da.locateDirectImpactNodes_v3(root, "Assign1", //
"Receive1S2", stack, false, false); node.addAllNodesToPrevPath(nodeStack.getPrevPath()
);
da.locateDirectImpactNodes_v5(saxP.getValueFro //
mNamesHashMap(fromSelectedItem), node.addNodeToPrevPath(nodeStack.getData().getNa
saxP.getValueFromNamesHashMap(fromSelectedItem), me());
saxP.getValueFromNamesHashMap(toSelectedItem), stack); // }
ArrayList<Node<BpelElement>> sequence = new stack.push(node);

ArrayList<Node<BpelElement>>(); }
while(!stack.empty()) { else if( localName.equals( "if" ) ) {
Node<BpelElement> IfImpl ifCond = new IfImpl();
node = (Node<BpelElement>)stack.pop(); ifCond.setName(getTagAttribute(uri, "name",
sequence.add(0, attribs));
node); Node<BpelElement> node = new
} Node<BpelElement>(ifCond);
output.setText("");
for (Node<BpelElement>
element: sequence) { namesHashMap.put(node.getData().getName(), node);
endNode = node;
output.append("Delete operation of:" + Node<BpelElement> nodeStack =
element.getData().getName() + " implies{"); (Node<BpelElement>)stack.peek();
LinkedList<String> node.addParent(nodeStack);
outDepNameList = da.getOutputDependencies(null, nodeStack.addChildNode(node);
element);
affectedActByDelete createOrder(node, nodeStack);
= new HashSet<String>(outDepNameList);
// for (String stack.push(node);
depListName : outDepNameList) { // ce era inainte
// //
affectedActByDelete.add(depListName); namesHashMap.put(node.getData().getName(), node);
// } // endNode = node;
for (String // Node<BpelElement> nodeStack =
uniqueDepListName: affectedActByDelete) { (Node<BpelElement>)stack.peek();
// /**
output.append(uniqueDepListName + "|"); // * add previous nodes to current node
} // */
/*for //
(Node<BpelElement> childDataDep: node.addAllNodesToPrevPath(nodeStack.getPrevPath()
element.getChildrenDataDep()) { );
//
201
output.append(childDataDep.getData().getName() node.addNodeToPrevPath(nodeStack.getData().getNa
+ "|"); me());
}*/ //
// node.addParent(nodeStack);
output.append("}\n"); // nodeStack.addChildNode(node);
if (element.getData() //
instanceof ActivityImpl) { // stack.push(node);
// end ce era inainte
ActivityImpl act = (ActivityImpl) }
element.getData(); else if (localName.equals( "forEach")) {
String ForEachImpl forEach = new ForEachImpl();
partLinkName = act.getPartnerLink(); Node<BpelElement> node = new
if Node<BpelElement>(forEach);
(partLinkName != null) {
PartnerLink partLink = namesHashMap.put(node.getData().getName(), node);

saxP.getPartner(partLinkName); endNode = node;
String partnerRole = partLink.getPartnerRole(); (Node<BpelElement>)stack.peek();
for (String processNameIterator:parsers.keySet()) { nodeStack.addChildNode(node);
if createOrder(node, nodeStack);
(processNameIterator.compareTo(currentProcessName) !=
0) stack.push(node);
}
{
else if (localName.equals( "while")) {
if WhileImpl whileImpl = new WhileImpl();
(parsers.get(processNameIterator).matchPartnerLink(partner Node<BpelElement> node = new
Role)){ Node<BpelElement>(whileImpl);
output.append(element.getData().getName() + " namesHashMap.put(node.getData().getName(), node);

implies process:"); endNode = node;
output.append(processNameIterator); node.addParent(nodeStack);
output.append("\n"); nodeStack.addChildNode(node);
stack.push(node);
}
} else if (localName.equals("repeatUntil")){
} RepeatUntillImpl repeatImpl = new
} RepeatUntillImpl();
} Node<BpelElement> node = new
} Node<BpelElement>(repeatImpl);
DependencyAnalyzer
daAddActivity = new
DependencyAnalyzer(saxP.getNamesMap(), namesHashMap.put(node.getData().getName(), node);
saxP.getVariablesMap()); endNode = node;
Stack<Node<BpelElement>> Node<BpelElement> nodeStack =
stackAddActivity = new Stack<Node<BpelElement>>(); (Node<BpelElement>)stack.peek();
daAddActivity.locateDirectImpactNodes_v5(saxP. nodeStack.addChildNode(node);
getValueFromNamesHashMap(fromSelectedItem),
saxP.getValueFromNamesHashMap(fromSelectedItem), createOrder(node, nodeStack);
saxP.getValueFromNamesHashMap(toSelectedItem),
stackAddActivity); stack.push(node);
}
ArrayList<Node<BpelElement>> else if (localName.equals("pick")) {
sequenceAddActivity = new PickImpl pickImpl = new PickImpl();
202
ArrayList<Node<BpelElement>>(); Node<BpelElement> node = new

Node<BpelElement>(pickImpl);
System.out.println("stack size=" +
stackAddActivity.size());
while(!stack.empty()) { endNode = node;
Node<BpelElement> Node<BpelElement> nodeStack =
node = (Node<BpelElement>)stack.pop(); (Node<BpelElement>)stack.peek();
sequence.add(0, node.addParent(nodeStack);
node); nodeStack.addChildNode(node);
}
Node<BpelElement>
frontNode = (Node<BpelElement>)stackAddActivity.pop(); stack.push(node);
Node<BpelElement> endNode }
= frontNode ; else if (localName.equals("scope")) {
while(!stack.empty()) { ScopeImpl scopeImpl = new ScopeImpl();
endNode = Node<BpelElement> node = new
(Node<BpelElement>)stack.pop(); Node<BpelElement>(scopeImpl);
}
if ( namesHashMap.put(node.getData().getName(), node);
activitySelectedItem.compareTo("invoke") == 0 || endNode = node;
activitySelectedItem.compareTo("assign")==0) { Node<BpelElement> nodeStack =
output.append("Adding of a " + node.addParent(nodeStack);
activitySelectedItem + " depends on{"); nodeStack.addChildNode(node);
LinkedList<String>
inDepNameList = createOrder(node, nodeStack);
daAddActivity.getInputDependencies(inputVariableSelected
Item, frontNode); stack.push(node);
}
prevAffectedActByInsert= new else if (localName.equals("elseif")) {
HashSet<String>(inDepNameList); ElseIfImpl elseIfImpl = new ElseIfImpl();
for (String Node<BpelElement> node = new
depListName : prevAffectedActByInsert) { Node<BpelElement>(elseIfImpl);
} namesHashMap.put(node.getData().getName(), node);
endNode = node;
output.append("}\n"); Node<BpelElement> nodeStack =
output.append("Adding of a " + nodeStack.addChildNode(node);
activitySelectedItem + " implies{");
LinkedList<String> createOrder(node, nodeStack);
outDepNameList =
daAddActivity.getOutputDependencies(outputVariableSelect stack.push(node);
edItem, endNode); }
else if (localName.equals("else")) {
postAffectedActByInsert = new ElseImpl elseImpl = new ElseImpl();
HashSet<String>(outDepNameList); Node<BpelElement> node = new
// for (String Node<BpelElement>(elseImpl);
depListName : outDepNameList) {
//
postAffectedActByInsert.add(depListName); namesHashMap.put(node.getData().getName(), node);
// } endNode = node;
for(String Node<BpelElement> nodeStack =
uniqueDepListName:postAffectedActByInsert) { (Node<BpelElement>)stack.peek();
output.append(uniqueDepListName + "|"); nodeStack.addChildNode(node);
}
203
stack.push(node);
}
} else if else if (localName.equals("source")) {
(activitySelectedItem.compareTo("receive") == 0) { Node<BpelElement> sourceNode =
output.append("Adding of a " + String linkName = getTagAttribute(uri,
activitySelectedItem + " activity implies{"); "linkName", attribs);
LinkedList<String> String key = "source_" + linkName;
outDepNameList = if (!linksHashMap.containsKey("target_"+
daAddActivity.getOutputDependencies(outputVariableSelect linkName)) {
edItem, endNode); linksHashMap.put(key,
sourceNode);
postAffectedActByInsert = new }
HashSet<String>(outDepNameList); else {
for (String Node<BpelElement> targetNode =
depListName : postAffectedActByInsert) { linksHashMap.get("target_"+ linkName);
targetNode.addParent(sourceNode);
sourceNode.addChildNode(targetNode);
//postAffectedActByInsert.add(depListName); /**
} * add previous nodes to current
node
output.append("}\n"); */
} else if targetNode.addAllNodesToPrevPath(sourceNode.getPr
(activitySelectedItem.compareTo("reply") == 0) { evPath());
output.append("Adding of a " + targetNode.addNodeToPrevPath(sourceNode.getData().

activitySelectedItem + " depends on{"); getName());
LinkedList<String> }
inDepNameList = }
daAddActivity.getInputDependencies(inputVariableSelected else if (localName.equals("target")) {
Item, frontNode); Node<BpelElement> targetNode =
prevAffectedActByInsert = new String linkName = getTagAttribute(uri,
HashSet<String>(inDepNameList); "linkName", attribs);
for (String String key = "target_" + linkName;
depListName : prevAffectedActByInsert) { if (!linksHashMap.containsKey("source_"+
linkName)) {
output.append(depListName + "|"); linksHashMap.put(key,
} targetNode);
}
output.append("}\n"); else {
} Node<BpelElement> sourceNode =
output.append("Activities that linksHashMap.get("source_"+ linkName);
may remain hanging{"); sourceNode.addLink(targetNode);
for(String /**
actName:affectedActByDelete){ * add previous nodes to current
if node
(!postAffectedActByInsert.contains(actName)) { */
output.append(actName + "|"); targetNode.addAllNodesToPrevPath(sourceNode.getPr

} evPath());
}
output.append("}\n"); targetNode.addNodeToPrevPath(sourceNode.getData().
} getName());
}
} /*targetNode.addParent(sourceNode);
} sourceNode.addChildNode(targetNode);*/
}
public static void printGraph(Node<BpelElement> aNode, }
String indent, StringBuffer sb) { else if (localName.equals("variable")) {
//System.out.println(indent + /*Node<BpelElement> nodeStack =
204
aNode.toString()); (Node<BpelElement>)stack.peek();
sb.append(indent + aNode.toString() + if (nodeStack.getData() instanceof
"\n"); ProcessImpl) {
if (aNode.getChildrenNodes().size() == 0 ProcessImpl p =
) (ProcessImpl)nodeStack.getData();
return;
indent+=" "; p.addVariablePair(getTagAttribute(uri, "name",
for(Node<BpelElement> attribs), getTagAttribute(uri, "messageType", attribs));
childNode:aNode.getChildrenNodes()) { }*/
printGraph(childNode, indent, try {
sb); if
} (variables.containsKey(getTagAttribute(uri, "name", attribs)))
} throw new
public Node<BpelElement> parseBpelFile(String Exception ("variables contains " + getTagAttribute(uri, "name",
fileName) throws FileNotFoundException, IOException, attribs));
SAXException { } catch (Exception e) {
File file = new File( fileName ); // TODO Auto-
InputSource src = new InputSource( new generated catch block
FileInputStream( file ) );
System.out.println( "--- SAX ---" ); e.printStackTrace();
}
SequenceImpl.seqNumber=0; variables.put(getTagAttribute(uri, "name",
FlowImpl.count = 0; attribs), getTagAttribute(uri, "messageType", attribs));
ElseIfImpl.elseIfNumber = 0;
ElseImpl.elseNumber = 0; }
EmptyImpl.count = 0; else if (localName.equals("condition")) {
ExitImpl.count = 0; // Node<BpelElement> stackTopNode =
OpaqueActivityImpl.count = 0; (Node<BpelElement>)stack.peek();
PickImpl.pickNumber = 0; // if (stackTopNode.getData() instanceof IfImpl
RethrowImpl.count = 0; || stackTopNode.getData() instanceof ElseIfImpl
ScopeImpl.scopeNumber = 0; // ||
WaitImpl.count = 0; stackTopNode.getData() instanceof ElseImpl) {
WhileImpl.whileNumber = 0; // String conditionExpression
// }
saxP = new SaxParser_v1(); sb = new StringBuffer();
conditionExpressionState = true;
XMLReader rdr = }
XMLReaderFactory.createXMLReader(); else if (localName.equals("copy")) {
rdr.setContentHandler( saxP ); Node<BpelElement> stackTopNode =
rdr.parse( src ); (Node<BpelElement>)stack.peek();
if (stackTopNode.getData() instanceof
Node<BpelElement> rootNode = AssignImpl) {
saxP.getRootNode(); assignCopyFlag = true;
saxP.printVariablesMap(); }
}
parsers.put(rootNode.getData().getName(), saxP); else if (localName.equals("from")) {
/*Node<BpelElement> anotherRoot = Node<BpelElement> stackTopNode =
saxP.getEndNode(); (Node<BpelElement>)stack.peek();
System.out.println("Eq test=" + if (stackTopNode.getData() instanceof
rootNode.equals(anotherRoot));*/ AssignImpl && assignCopyFlag) {
return rootNode; String part = getTagAttribute(uri,
} "part", attribs);
/**
public void itemStateChanged(ItemEvent e) { * variable is a WSDL message
/* JMenuItem source = (JMenuItem)(e.getSource()); type
String s = "Item event detected." */
+ newline if (part != null)
+ " Event source: " + source.getText() assignHashMap.put(part,
+ " (an instance of " + getClassName(source) + getTagAttribute(uri, "variable", attribs));
")" /**
+ newline * to be extended
+ " New state: " */
+ ((e.getStateChange() == }
205
ItemEvent.SELECTED) ? }
"selected":"unselected"); else if (localName.equals("to")) {
output.append(s + newline); Node<BpelElement> stackTopNode =
output.setCaretPosition(output.getDocument().getLength()); if (stackTopNode.getData() instanceof
*/ AssignImpl && assignCopyFlag) {
} String part = getTagAttribute(uri,
"part", attribs);
// Returns just the class name -- no package info. /**
protected String getClassName(Object o) { * variable is a WSDL message
String classString = o.getClass().getName(); type
int dotIndex = classString.lastIndexOf("."); */
return classString.substring(dotIndex+1); if (part != null) {
} String fromVariable =
assignHashMap.get(part);
/** /**
* Create the GUI and show it. For thread safety, * Data dependency for
* this method should be invoked from the input & output
* event-dispatching thread. */
*/ String
private static void createAndShowGUI() { toVariable = getTagAttribute(uri, "variable", attribs);
//Create and set up the window. if (fromVariable != null)
JFrame frame = new {
JFrame("MenuSelectionManagerDemo");
Node<BpelElement> fatherDataDependency =
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE outputVariables.get(fromVariable);
); if (fatherDataDependency
frame.setLayout(new BorderLayout()); != null) {
//Create and set up the content pane. stackTopNode.addFatherDataDep(fatherDataDependen

DepAnalyzerGui demo = new DepAnalyzerGui(); cy);
frame.setJMenuBar(demo.createMenuBar());
fatherDataDependency.addChildrenDataDep(stackTop
Node);
}
}
frame.add(demo.createVerticalSplitPane(demo.createHorizo
ntalSplitPane(demo.createTreePane(), Node<BpelElement>
demo.createButtonsPane()), demo.createContentPane()), oldValue = outputVariables.put(toVariable, stackTopNode);
BorderLayout.CENTER);
//frame.setContentPane(demo.createContentPane()); AssignImpl asi =
frame.add(demo.createControlPanel(), (AssignImpl) stackTopNode.getData();
BorderLayout.PAGE_END); if (fromVariable != null)
{
//Display the window.
frame.setSize(800, 520); asi.addInputVariable(fromVariable);
frame.setVisible(true); }
}
asi.addOutputVariable(toVariable);
public JComponent createControlPanel() {
JPanel panel = new JPanel(); if (fromVariable != null)
JButton analyze = new JButton("Analyze"); {
JButton another = new JButton("Another"); if
another.addActionListener(this); (!variablesMap.containsKey(fromVariable)) {
analyze.addActionListener(this);
panel.add(analyze); VariableUsage vu = new VariableUsage();
panel.add(another);
panel.setBorder( vu.addInput(stackTopNode.getData().getName());
BorderFactory.createCompoundBorder(
variablesMap.put(fromVariable, vu);
BorderFactory.createTitledBorder("Controls"), } else {
BorderFactory.createEmptyBorder(5,5,5,5))); VariableUsage vu = variablesMap.get(fromVariable);
206
return panel;
} vu.addInput(stackTopNode.getData().getName());
}
public static void main(String[] args) { }
//Schedule a job for the event-dispatching thread: if
//creating and showing this application's GUI. (!variablesMap.containsKey(toVariable)) {
javax.swing.SwingUtilities.invokeLater(new VariableUsage
Runnable() { vu = new VariableUsage();
public void run() {
createAndShowGUI(); vu.addOutput(stackTopNode.getData().getName());
}
}); variablesMap.put(toVariable, vu);
} } else {
VariableUsage
@Override vu = variablesMap.get(toVariable);
public void valueChanged(TreeSelectionEvent
arg0) { vu.addOutput(stackTopNode.getData().getName());
// TODO Auto-generated method stub }
} }
} /**
class Chooser extends JFrame { * to be extended
*/
JFileChooser chooser;
String fileName; }
}
public Chooser() {
chooser = new JFileChooser();
int r = chooser.showOpenDialog(new // if next element is simple, push StringBuffer
JFrame()); // this makes the stack ready to accept character text
if (r == else if( localName.equals( "title" ) || localName.equals(
JFileChooser.APPROVE_OPTION) { "author" ) ||
fileName = localName.equals( "name" ) ||
chooser.getSelectedFile().getPath(); localName.equals( "headline" ) ) {
} //stack.push( new StringBuffer() );
} //isStackReadyForText = true;
} }
----------------------------------------------------------- // if none of the above, it is an unexpected element
package sax.parser;
else{
import java.util.LinkedHashSet; // do nothing
}
public class VariableUsage { }
private LinkedHashSet<String> inputs = new
LinkedHashSet<String>(); public void endElement( String uri, String localName, String
private LinkedHashSet<String> outputs = new qName ) {
LinkedHashSet<String>();
public void addInput(String inputName) { // recognized text is always content of an element
inputs.add(inputName); // when the element closes, no more text should be
} expected
isStackReadyForText = false;
public void addOutput(String outputName) {
outputs.add(outputName); // pop stack and add to 'parent' element, which is next
} on the stack
// important to pop stack first, then peek at top element!
public LinkedHashSet<String> getInputs() {
return inputs; Node<BpelElement> node;
} if( localName.equals( "process" ) ) {
node = (Node<BpelElement>)stack.pop();
public LinkedHashSet<String> getOutputs() { } else if( localName.equals( "sequence" ) ) {
return outputs; node = (Node<BpelElement>)stack.pop();
} }else if( localName.equals( "receive" ) ) {
207
public String toString() { }else if( localName.equals( "invoke" ) ) {
StringBuffer sb = new StringBuffer(); node = (Node<BpelElement>)stack.pop();
sb.append("{inputs:"); }else if( localName.equals( "reply" ) ) {
for (String input:inputs) { node = (Node<BpelElement>)stack.pop();
sb.append(input); }else if( localName.equals( "flow" ) ) {
sb.append("|"); node = (Node<BpelElement>)stack.pop();
} }else if( localName.equals( "if" ) ) {
sb.append("}"); node = (Node<BpelElement>)stack.pop();
sb.append("{outputs:"); }else if( localName.equals( "elseif" ) ) {
for (String output:outputs) { node = (Node<BpelElement>)stack.pop();
sb.append(output); }else if( localName.equals( "else" ) ) {
sb.append("|"); node =
} (Node<BpelElement>)stack.pop();
sb.append("}"); }else if (localName.equals("assign")) {
return sb.toString(); node = (Node<BpelElement>)stack.pop();
} }else if (localName.equals("while")) {
} node = (Node<BpelElement>)stack.pop();
}else if (localName.equals("repeatUntil")) {
}else if (localName.equals("pick")) {
}else if (localName.equals("scope")) {
}else if (localName.equals("forEach")) {
}else if (localName.equals("exit")) {
}else if (localName.equals("throw")) {
}else if (localName.equals("rethrow")) {
}else if (localName.equals("wait")) {
}else if (localName.equals("empty")) {
}else if (localName.equals("opaqueActivity")) {
}
else if (localName.equals("copy")) {
assignCopyFlag = false;
}
else if (localName.equals("partnerLinks")) {
partnerLinksSection = false;
}
else if (localName.equals("condition")) {
Node<BpelElement> stackTopNode =
if (stackTopNode.getData() instanceof IfImpl
|| stackTopNode.getData() instanceof ElseIfImpl) {
String conditionExpression =
sb.toString();
String delims = "[ .,?!=/><]+";
String[]
tokens1=conditionExpression.split(">");
for (int i = 0; i<tokens1.length; i++)
{
String[] tokens2 =
tokens1[i].split("<");
for (int j=0;
j<tokens2.length; j++){
String[]
tokens3 = tokens2[j].split(delims);
for( int k=0;
208
k<tokens3.length; k++ ) {
if
(tokens3[k].startsWith("$")){
String inVar = tokens3[k].substring(1);

if
(stackTopNode.getData() instanceof IfImpl) {
IfImpl ifImplementation = (IfImpl)

stackTopNode.getData();
ifImplementation.addInputVariable(inVar);
}
if
(stackTopNode.getData() instanceof ElseIfImpl) {
ElseIfImpl elseIfImplementation = (ElseIfImpl)

stackTopNode.getData();
elseIfImplementation.addInputVariable(inVar);
}
if (inVar !=
null) {
if
(!variablesMap.containsKey(inVar)) {
VariableUsage vu = new VariableUsage();
vu.addInput(stackTopNode.getData().getName());
variablesMap.put(inVar, vu);
} else
{
VariableUsage vu = variablesMap.get(inVar);
vu.addInput(stackTopNode.getData().getName());
}
}
}
}
}
}
// String[] tokens =
conditionExpression.split(delims);
// for( int i=0; i<tokens.length; i++ ) {
// if
(tokens[i].startsWith("$")){
// String inVar =
tokens[i].substring(1);
//
System.out.println("if invar=" + inVar);
// }
// }
conditionExpressionState = false;
}
}
/*Object tmp = stack.pop();
if( localName.equals( "catalog" ) ) {
209
catalog = (Catalog)tmp;
}else if( localName.equals( "book" ) ) {

((Catalog)stack.peek()).addBook( (Book)tmp );
}else if( localName.equals( "magazine" ) ) {

((Catalog)stack.peek()).addMagazine(
(Magazine)tmp );
}else if( localName.equals( "article" ) ) {

((Magazine)stack.peek()).addArticle( (Article)tmp );
}
// for simple elements, pop StringBuffer and convert to
String
else if( localName.equals( "title" ) ) {
((Book)stack.peek()).setTitle( tmp.toString() );
}else if( localName.equals( "author" ) ) {

((Book)stack.peek()).setAuthor( tmp.toString() );
}else if( localName.equals( "name" ) ) {

((Magazine)stack.peek()).setName( tmp.toString() );
}else if( localName.equals( "headline" ) ) {

((Article)stack.peek()).setHeadline( tmp.toString() );
}
// if none of the above, it is an unexpected element:
// necessary to push popped element back!
else{
stack.push( tmp );
}*/
}
private State determineState() {

State aState = State.DEFAULT;
if (stack.empty())
return aState;
Node<BpelElement> node =
if (node.getData() instanceof ProcessImpl)
aState = State.PROCESS;
else if (node.getData() instanceof FlowImpl)
aState = State.FLOW;
else if (node.getData() instanceof SequenceImpl)
aState = State.SEQUENCE;
else if (node.getData() instanceof ActivityImpl)
aState = State.ACTIVITY;
else if (node.getData() instanceof ForEachImpl)
aState = State.FOREACH;
else if (node.getData() instanceof IfImpl)
aState = State.IF;
else if (node.getData() instanceof ElseIfImpl)
aState = State.ELSEIF;
else if (node.getData() instanceof ElseImpl)
aState = State.ELSE;
else if (node.getData() instanceof WhileImpl)
aState = State.WHILE;
else if (node.getData() instanceof RepeatUntillImpl)
aState = State.REPEATUNTILL;
else if (node.getData() instanceof PickImpl)
aState = State.PICK;
210
return aState;
}
public void characters( char[] data, int start, int length ) {

if (conditionExpressionState)
sb.append(data, start, length);
// if stack is not ready, data is not content of recognized

element
/*if( isStackReadyForText == true ) {
((StringBuffer)stack.peek()).append( data, start,
length );
}else{
// read data which is not part of recognized element
}*/
}
private void createOrder(Node<BpelElement> node,

Node<BpelElement> nodeStack) {
/**
* links
*/
if (State.SEQUENCE == determineState()) {
if (nodeStack.getLastNodeInSeq()
== null) {
/**
* add previous nodes to current
node
*/
);
me());
}
else {
Node<BpelElement>
previusPathNode = nodeStack.getLastNodeInSeq();
previusPathNode.addLink(node);
/**
* add previous nodes to current
node
*/
node.addAllNodesToPrevPath(previusPathNode.getPre
vPath());
node.addNodeToPrevPath(previusPathNode.getData().
getName());
if (previusPathNode.getData()
instanceof FlowImpl) {
FlowImpl flow =
(FlowImpl) previusPathNode.getData();
List<Node<BpelElement>> flowChildren =
previusPathNode.getChildrenNodes();
for (Node<BpelElement>
aNode: flowChildren)
211
node.addNodeToPrevPath(aNode.getData().getName())
;
}
} else {
/**
* add previous nodes to current node
*/
);
me());
}
}
BIBLIOGRAFIE
[1] Future Internet Enterprise Systems (FInES) Research Roadmap,

http://cordis.europa.eu/fp7/ict/enet/documents/fines-researchroadmap-final-report.pdf , June 2010
[2] H. Panetto, J. Cecil, Information Systems for Enterprise Integration, Interoperability and
Networking: Theory and Applications, Enterprise Information Systems 7, DOI : 10.1080/
17517575.2012.684802, 2013, pp. 1-6
[3] http://ec.europa.eu/dgs/connect/mission/index_en.htm
[4] J. Myers, Future value systems: Next generation economic growth engines & manufacturing. In:
Proc. of the IMS Vision Forum 2006 (B.-W. Choi, D. Nagy, Editors). IMS International. Seoul,
Korea, pp 30-47
[5] T. Earl. SOA Principles of Service Design,Prentice Hall, 2008
[6] Kuhn , S. Thomas, The Structure of Scientific Revolution, 3rd edition. Chicago: University of
Chicago Press, 1996
[7] A. Kaposi, M. Myers, Systems for All, Publicat de Imperial College Press, 2001
[8] Aurelian M.Stnescu, Mihnea A.Moisescu, Ioan S.Sacal, George Burlacu, Raluca A.Nedelcu,
Luiza E.Cojocaru: Concurrent innovation-based eEnterprise, ICE Conference 2012
[9] Luis M. Camarinha-Matos, Hamideh Afsarmanesh, Martin Ollus, METHODS AND TOOLS FOR
COLLABORATIVE NETWORKED ORGANIZATIONS, Springer Science+Business Media,
LLC, 2008
[10] http://www.w3.org/TR/ws-arch/, accesat la data de 06.11.2013
[11] http://ec.europa.eu/research/horizon2020/pdf/work-
programmes/health_draft_work_programme.pdf#view=fit&pagemode=none
212
[12] Jardim-Goncalves, R. Agostinho, C. Steiger-Garcao, A.Sustainable Systems Interoperability: A

reference model for seamless networked business. Publicat in Systems Man and Cybernetics
(SMC), 2010, pp. 1785 1792
[13] G. Burlacu , L. Cojocaru , C. Danila, D. Popescu, A. M. Stanescu, A Digital Business Ecosystem
Integrated Approach for Farm Management Information System, ICSCS, 2013
[14] FInES Research Roadmap 2025, iunie 2012, pp. 14
[15] http://en.wikipedia.org/wiki/Frederick_Winslow_Taylor
[16] FInES Research Roadmap 2025, http://cordis.europa.eu/fp7/ict/enet/documents/fines-research-
roadmap-v30_en.pdf, accesat in martie 2013
[17] K.E. Weick, K.M. Sutcliffe, D. Obstfeld,.Organizing and the Process of Sensemaking, Organization
Science, 2005, pp: 409421
[18] K.E. Weick, K.M. Sutcliffe, Mindfulness and the quality of organizational attention, Organization
Science, 2006
[19] D.A. Levinthal, W.M. Cohen, Absorptive Capacity: A New Perspective on Learning and
Innovation, Administrative Science Quarterly, 1990
[20] http://www.fi-ware.eu/]
[21] E. Stolterman, A. Croon Fors, "Information Technology and the Good Life", in: 35 "Information
systems research: relevant theory and informed practice", ISBN 1-36 4020-8094-8, 2004, p. 689
[22] Future Internet Enterprise Systems (FInES) Embarking on New Orientations Towards Horizon
2020, DRAFT DOCUMENT (Version 1.00), Mai 2013
[23] S.A. Wymer, and E.A. Regan, (2005) Factors influencing e-commerce adoption and 8 use by
small and medium businesses Electronic Markets, Vol. 15 No. 4, pp 438-453
[24] O. Lazaro Future Internet and SMEs, FInES Task Force, Brussels, 12th October 2011
[25] http://ec.europa.eu/digital-agenda/en/news/commission-staff-working-document-strengthening-
environment-web-entrepreneurs-eu
[26] http://www.fines-cluster.eu/].
[27] FInES Orientations for FP8 (2011). FInES Position Paper on Orientations for FP8. Accesat la
20.02.2013 la http://cordis.europa.eu/fp7/ict/enet/documents/finesposition-paper-fp8-orientations-
final.pdf
[28] FInES Research Roadmap 2025(2012). Future Internet Enterprise Systems FInES Research
Roadmap 2025. Accesat la 20.02.2013 la http://www.finescluster.eu/fines/jm/docman/Download-
document/297-FInES-Cluster-2012-Research-Roadmap-2025-v2.0.html
[29] Li Man-Sze (2011). IoT Conference @ Poznan, Panel on The Rise of the Sensing Enterprise,
Proceedings, 26th October 2011.Presentation of Man-Sze Li, Presentation of Rikardo Bueno.
Accesat la 20.02.2013 la: http://www.week.fipoznan.eu/online/?view=session&session_id=213
[30] Ioan Dumitrache, Simona Iuliana Caramihai, Aurelian Stanescu. From mass production to
Intelligent Cyber-enterpris. CSCS19, 2013.
[31] A.M., Stnescu, M. Moisescu, I. Sacal, G. Burlacu, R. Nedelcu, L. Cojocaru, Concurrent
innovation-based eEnterprise, 18th International ICE Conference on Engineering, Technology and
Innovation (ICE), 2012, pp:1-9
[32] L.M. Camarinha-Matos, H. Afsarmanesh: The emerging discipline of collaborative networks, in
Virtual Enterprises and Collaborative Networks (L.M. Camarinha-Matos, Editor), Kluwer
Academic Publishers, 2004
[33] H. Afsarmanesh, L.M. Camarinha-Matos: A framework for management of virtual organization
breeding environments, in Collaborative Networks and their Breeding Environments, Springer,
Boston, 2005, pp. 35-49
213
[34] H. Afsarmanesh, L.M. Camarinha-Matos, S.S. Msanjila, (2007): Virtual Organizations Breeding
Environment: Key Results from ECOLEAD. In the proceedings of the International conference on
Cost Effective Automation in Networked Product Development and Manufacturing - IFACCEA'
2007. Monterey, Mxico
[35] M. Tolle, A. Zwegers, J. Vesterager: Virtual Enterprise Reference Architecture and Methodology
(VERAM), GLOBEMEN Jopint D412 & D43 deliverables, 2003
[36] A. Zwegers, M. Tolle, J.Vesterager (2003): VERAM: Virtual Enterprise Reference Architecture
and Methodology, in Karvonen, I, et. al. (Eds.) Global Engineering and Manufacturing in
Enterprise Networks, GLOBEMEN, VTT Symposium 224, VTT Information Service, pp. 17-38
[37] L.M. Camarinha-Matos, H. Afsarmanesh: Elements of a base VE infrastructure. Computers in
Industry, 51(2), 2003
[38] R. Mejia, A. Molina: Virtual enterprise broker: Processes, methods and tools, in Collaborative
business ecosystems and virtual enterprises, Kluwer, Boston, 2002
[39] A.Molina, and M. Flores: Exploration of Business Opportunities: The role of the virtual enterprise
broker, in E-Business and Virtual Enterprise. Managing Business Cooperation (L.M. Camarinha-
Matos, H. Afsarmanesh, R. Rabelo, Eds) Kluwer Academic Publishers, Boston, 2002
[40] L.M. Camarinha-Matos, H. Afsarmanesh, (Ed.s): Collaborative networked organizations A
research agenda for emerging business models, Kluwer Academic Publishers, ISBN 1-4020-7823-
4, 2004
[41] L.M. Camarinha-Matos, H. Afsarmanesh, M. Ollus, (editors) (2005): Virtual Organizations:
Systems and Practices, Berlin, New York: Springer Science
[42] L.M. Camarinha-Matos, H. Afsarmanesh: Infrastructures for Virtual Enterprises Networking
Industrial Enterprises. Kluwer Academic Publishers, ISBN 0-7923-8639-6, Porto, Portugal, 1999
[43] D. Good. Individuals, interpersonal relations, and trust. In Trust: Making and Breaking
Cooperative Relations. Edited by D.G. Gambetta, Basil Blackwell: New York, 1988, pg. 3148
[44] R.C Mayer, J.H. Davis, F.D. Schoorman. An integrated model of organizational trust. In
Academy of Management review. Vol 20 No. 3, 1995, pp 709-734.
[45] T. Grandison, & M. Sloman, (2000). A survey of trust in Internet applications. In the IEEE
Communication Survey Tutorial, Vol. 3, pp 216.
[46] D.M. Rousseau, S.B. Sitkin, R.S. Burt, & C. Camerer. Not so different after all: a crossdiscipline
view of trust. In Academy of Management Review, Vol. 23, 1998, pp. 393404.
[47] S.S. Msanjila, & H. Afsarmanesh. HICI: An approach for identifying trust elements The case of
technological perspective in VBEs. In proceeding of International conference on availability,
reliability and security (ARES-2007), Vienna, 2007, pp. 757-764.
[48] S.S. Msanjila, & H. Afsarmanesh. Trust Analysis and Assessment in Virtual Organizations
Breeding Environments. In the International Journal of Production Research, ISBN (print) 0020-
7543, Research, Taylor & Francis., Vol. 46, No 5, 2007, pp. 1253-1295
[49] H. Afsarmanesh, & L.M. Camarinha-Matos. A framework for management of virtual organization
breeding environments, in Collaborative Networks and their Breeding Environments, Springer,
ISBN 0387282599, 2005, pp. 35-49
[50] H. Afsarmanesh, & L.M. Camarinha-Matos (26-28 September). A Framework for Managementof
Virtual Organization Breeding Environments. Paper presented at the 6th IFIP Working
Conference on Virtual Enterprises, Valencia, 2005
[51] L.M. Camarinha-Matos & H. Afsarmanesh. Elements of a base VE infrastructure. J. Computersin
Industry, Vol. 51 (Issue 2), 2003, pp. 139-163
214
[52] L.M . Camarinha-Matos, T. Cardoso. Selection of Partners for a Virtual organization,

Infrastructure for Virtual Enterprises: Kluwer Academic Publishers, 1999, pp. 259-278
[53] N.R. Jennings, & M.J. Wooldridge. Agent Technology - Foundations, Applications, and Markets:
Springer, 1998
[54] L.M. Camarinha-Matos, I. Silveri, H. Afsarmanesh, A.I. & Oliveira. Towards a Framework for
Creation of Dynamic Virtual Organizations. In L. M. Camarinha-Matos (Ed.), Collaborative
Networks and theirs Breeding Environments: Springer, 2005, pp. 69-80
[55] A.P. Rocha & E. Oliveira. An Electronic Market Architecture for the Formation of Virtual
Enterprises, Infrastructures for Virtual Enterprises. Boston: Kluwer, 1999
[56] Y. Li, B. Huang, W. Liu, C.Wu & H. Gou. Multi-agent system for Partner Selection of Virtual
Enterprise. Paper presented at the 16th IFIP World Computer Congress, Beijing, China, 21-25
August 2000
[57] R.J. Rabelo, L.M. Camarinha-Matos, & R.V. Vallejos. Agent-based Brokerage for Virtual
Enterprise Creation in the Moulds Industry, E-business and Virtual Enterprises: Kluwer Academic
Publishers, 2000, pp. 281-290
[58] T.J. Norman, A. Preece, S. Chalmers, N.R. Jennigs, M. Luck, V.D Dang, T.D. Nguyen, V. Deora,
J. Shao, W.A Gray & N.J. Fiddian: Agent-based formation of virtual organisations. Retrieved 12
April 2004, 2004, from the World Wide Web: www.sciencedirect.com
[59] H. Afsarmanesh, & L.M. Camarinha-Matos. Future smart organizations: A virtua tourism
enterprise. Paper presented at the WISE 2000 -1st ACM/IEEE International Conference on Web
Information Systems Engineering, Hong Kong, 19-20 iunie 2000
[60] Y. Rezgui. OSMOS: Open system for inter-enterprise information management in dynamic virtual
enterprises, in Virtual Organizations: Systems and Practices, Springer, 2005
[61] www.iog.ca
[62] Oxford Dictionary of Current English. Oxford University Press. Oxford, 1987
[63] P.S. Renz. Project Governance: Implementing Corporate Governance and Business Ethics in
Nonprofit Organizations. ISBN-10: 3790819263. Physica-Verlag Heidelberg, 2007
[64] G. ODonovan. A Board Culture of Corporate Governance. In Corporate Governance
International Journal, Vol 6, Issue 3, 2003
[65] A.A.Pereira-Klen, E.R. Klen. Human Supervised Virtual Organization Management.
In:Collaborative Networks and their Breeding Environments. In: Collaborative Networks and
theirBreeding Environments, Springer,2005, pp. 229-230
[66] I. Karvonen & K. Jansson & M. Ollus, & I. Hartel, & G.Burger, & M. Anastasiou & P.
Vlikangas & K. Mori. Inter-enterprise eCollaboration in Sales and Service of one-of-a-kind
products. In: B. Stanford-Smith & E. Chiozza & M. Edin, (Ed.). Challenges and Achievements in
E-business and E-work, IOS Press / Ohmsha, Berlin, Germany; 2000, pp. 1388-1395
[67] P. Graham (ed.). Mary Parker Follett: Prophet of Management. Harvard Business School Press.
ISBN: 0-87584-736-6, 1995
[68] I. Karvonen, I. Salkari, M. Ollus. Characterizing Virtual Organizations and Their Management.
In: Collaborative Networks and their Breeding Environments. (Camarinha-Matos, H.
Afsarmanesh, A. Ortiz (Ed)). Springer. New York, 2005
[69] B. Katzy, C.Zhang, H.Lh: Reference Models for Virtual Organizations. In: Virtual Organisations
Systems and Practices. ISBN 0-387-23755-0. Springer, New York,2005, pp. 45-58
[70] M. Ollus, K. Jansson, I. Karvonen. Approaches for the Management of Virtual Organizations;
Results from ECOLEAD. IFAC Conference on Cost Effective Automation in Networked Product
215
Development and Manufacturing. Monterrey, Mexico. 26. Oxford Dictionary of Current English
(2007). Oxford University Press. Oxford, 2-5 octombrie 2007
[71] K. Jansson, I. Karvonen, M.Ollus, P.Paganelli, R. Stewens, U. Negretto. Real Time Virtual
Organisations Management. In: Innovation and the Knowledge Economy - Issues, Applications,
Case Studies. (P. Cunningham, M. Cunningham (Ed)). ISBN 1-58603-563-0. IOS Press.
Amsterdam, 2005
[72] I. Westphal, K-D Thoben, M. Seifert. Measuring Collaboration Performance in Virtual
Organizations. In IFIP International Federation for Information Processing, Volume 243,
Establishing the Foundation of Collaborative Networks; eds. L. Camarinha-Matos, H.
Afsarmanesh, P. Novais, C. Analide; (Boston, Springer), 2007, pp. 33-42
[73] http://www.pmi.org/PMBOK-Guide-and-Standards.aspx
[74] M. Schindler, M. Eppler, 2003. Harvesting project knowledge: a review of project learning
methods and success factors. International Journal of Project Management 21. Elsevier Science
Ltd and IPMA, 2003, pp. 219-228
[75] FIATECH (2001). Guidelines and Drivers for Achieving Plant Lifecycle Data Management. The
owner operator forum. January 2001. http://www.fiatech.org
[76] D. Romero, N. Galeano, A.Molina. A conceptual model for virtual breeding environments value
systems, In IFIP International Federation for Information Processing, Volume 243, Establishing
the Foundation of Collaborative Networks; eds. L. Camarinha-Matos, H. Afsarmanesh, P. Novais,
C. Analide, (Boston, Springer), 2007, pp. 43-52
[77] A. Gunasekaran, C. Patel, E. Tirtiroglu: Performance measures and metrics in a supply chain
environment. International Journal of Operations & Production Management, Bradford, Vol. 21,
Iss. 1/2, 2001, pp. 71
[78] Ralf Hieber: Collaborative performance measurement in logistics networks : the model, approach
and assigned KPIs. In: Logistik-Management, Nrnberg, Vol. 4, No. 2, 2002
[79] M. Leseure, N. Shaw, G. Chapman: Performance measurement in organisational networks: an
exploratory case study. In: International journal of business performance management. Milton
Keynes, Genve, Vol. 3, No. 1, 2001
[80] Vince Kellen, Business Performance Measurement; Chicago 2003
[81] Peter Vervest, Kennetsh Preiss, Eric van Heck, Louis Pau: The Emergence of Smart Business
Networks. In: Smart Business Networks, Springer, Berlin 2005
[82] Robert S. Kaplan, David P. Norton, The Balanced Scorecard - Measures that Drive Performance,
Harvard Business Review, January-February, 1992
[83] Andy D. Neely, John F. Mills, Mike J. Gregory, Huw A. Richards, Ken W. Platts, Mike K.
Bourne: Getting the Measure of your Business. Findlay, London, 1996
[84] U. Bititci, T. Turner, M. Bourne:Performance Measurement: the comparison between a process
and a model approach. In: Int. J. Business Performance Measurement, Vol. 3, Nos. 2/3/4, 2001
[85] Bjrn Andersen, Tom Fagerhaug: Performance Measurement Explained: Designing and
Implementing Your State-of-the-Art System. ASQ Quality Press, Milwaukee, 2002
[86] Michael Hbig: Modellgesttzte Bewertung der Kooperationsfhigkeit produzierender
Unternehmen. Fortschritt-Berichte VDI Reihe 16 Nr. 140, VDI Verlag, Dsseldorf, 2002
[87] A. Ketfi, N. Belkhatir, P.-Y. Cunin: Dynamic Updating of Component-based Applications. In:
SERP, 2002
[88] P.K. McKinley, S.M. Sadjadi, E.P. Kasten, B.H.C. Cheng: A Taxonomy of Compositional
Adaptation. Technical report, Department of Computer Science and Engineering, Michigan State
University, 2004
216
[89] M. Aksit, Z. Choukair: Dynamic, Adaptive and Reconfigurable Systems Overview and
Prospective Vision. In: Short Paper Proceedings at (CAiSE), Porto, Portugal. CEUR Workshop
Proc., vol. 161, 2005
[90] M. Papazoglou, K. Pohl, M. Parkin, A. Metzger, Service Research Challenges and Solutions for
the Future Internet, Springer-Verlag Berlin Heidelberg, 2010
[91] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi, S. Weerawarana: Unraveling the Web
Services Web: an introduction to SOAP, WSDL, and UDDI. IEEE Internet Computing 6(2), 2002,
86-93
[92] F. Leymann: Web services flow language (wsfl 1.0). Technical report, IBM Corporation, May
2001
[93] Thatte, S.: XLANG Web Services for Business Process Design. Microsoft Corporation, 2001
[94] A. Arkin: Business Process Modeling Language, November 2002
[95] http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html
[96] http://www.oracle.com/technetwork/articles/matjaz-bpel1-090575.html
[97] G. Decker, O. Kopp, F. Leymann, M. Wesk: BPEL4Chor: Extending BPEL for modelling
choreographies. In: ICWS. IEEE Computer Society, 2007, pp. 296-303
[98] http://www.w3.org/TR/ws-cdl-10/]
[99] http://www.bpel4chor.org/]
[100] http://docs.oasis-open.org/ws-tx/wscoor/2006/06
[101] http://www.w3.org/Submission/OWL-S/
[102] http://www.w3.org/Submission/WSMO-primer/
[103] J. Hielscher, A. Metzger and R. Kazhamiakin: Taxonomy of Adaptation Principles and
Mechanisms, S-Cube Project Deliverable CD-JRA-1.2.2, 2009
[104] A. Hallerbach, T. Bauer, M. Reichert: Managing Process Variants in the Process Lifecycle. In:
10th Intl Conf. on Enterprise Information Systems, 2008
[105] F. Casati, S. Ceri, B. Pernici, G. Pozzi: Workflow Evolution. In: Thalheim, B. (ed.) ER 1996.
LNCS, vol. 1157, Springer, Heidelberg, 1996
[106] F. Casati, S. Ceri, B. Pernici, G. Pozzi: Workflow Evolution. In: Thalheim, B. (ed.) ER 1996.
LNCS, vol. 1157, Springer, Heidelberg, 1996
[107] M. Reichert, P. Dadam: ADEPTflex - Supporting Dynamic Changes of Workflows Without
Loosing Control. JIIS, 1998, pp. 93-192
[108] L.T. Ly, S.Rinderle, P. Dadam: Integration and Verification of Semantic Constraints in Adaptive
Process Management Systems. Data Knowl. Eng. 64(1), 2008, pp. 3-23
[109] F. Casati, S. Ceri, B. Pernici, G. Pozzi.: Workflow evolution. Data Knowl. Eng. 24(3), 1998, pp.
211-238
[110] J. Eder, W. Liebhart: Workflow recovery. In: Proc. of IFCIS Int. Conf. on Cooperative
Information Systems (CoopIS), Brussels, Belgium. IEEE Computer Society Press, Los Alamitos,
1996, pp. 124-134
[111] M. Reichert, S. Rinderle, U. Kreher, P. Dadam: Adaptive process management with ADEPT2. In:
Proc. of Int. Conf. on Data Engineering ICDE, Tokyo, Japan, 2005, pp. 1113-1114
[112] C.Hagen, G. Alonso.: Exception handling in workflow management systems. IEEE Trans.
Software Eng. 26(10), 2000,pp. 943-958
[113] R. Hamadi, B. Benatallah: Recovery nets: Towards self-adaptive workflow systems. In: X. Zhou,
S. Su, M.P. Papazoglou, M.E. Orlowska, K. Jeffery, (eds.) WISE 2004. LNCS, vol. 3306.
Springer, Heidelberg, 2004, pp. 439-453
217
[114] K. Verma, K. Gomadam, A.P. Sheth, J.A. Miller, Z. Wu: The METEOR-S Approach for
Configuring and Executing Dynamic Web Processes. Technical report, 2005
[115] K. Verma, R. Akkiraju, R.Goodwin, P. Doshi, J. Lee: On accommodating inter service
dependencies in web process flow composition. In: Proc. of Int. Semantic Web Services
Symposium, AAAI spring symposium series, Palo Alto (CA) USA, 2004
[116] Y. Wu, P. Doshi: Regret-Based Decentralized Adaptation of Web Processes with Coordination
Constraint. In: Proceedings of Service Computing Conference, SCC, 2007
[117] D. Bianculli, R. Jurca, W. Binder, C. Ghezzi, B.V. Faitings: Automated Dynamic Maintenance of
Composite Services Based on Service Reputation. In: Kramer, B.J., Lin, K.-J., Narasimhan, P.
(eds.) ICSOC 2007. LNCS, vol. 4749. Springer, Heidelberg, 2007, pp. 449-455
[118] M. Colombo, E. Di Nitto, M. Mauri: SCENE: A Service Composition Execution Environment
Supporting Dynamic Changes Disciplined Through Rules, ln: A. Dan, W. Lamersdorf, (eds.)
1CSOC 2006. LNCS, vol. 4294. Springer, Heidelberg, 2006, pp. 191-202
[119] M. Di Penta, R. Esposito, M.L. Villani, R. Codato, M.Colombo, E. Di Nitto: WS Binder: a
Framework to Enable Dynamic Binding of Composite Web Services. In: SOSE !06: Proceedings
of the 2006 international workshop on Service-oriented software engineering, New York, NY,
USA. ACM, 2006, pp. 74-80
[120] L. Cavallaro, E. Di Nitto: An Approach to Adapt Service Requests to Actual Service Interfaces.
In: SEAMS 08: Proceedings of the 2008 international work-shop on Software engineering for
adaptive and self-managing systems, New York, NY, USA. ACM Press, 2008, pp. 129-136
[121] D. Ardagna, M. Comuzzini, E.Mussi, B. Pernici, P. Plebani: PAWS: A FRAME- work for
Executing Adaptive Web-Service Processes. IEEE Software 24(6), 2007, pp. 39-46
[122] G. Spanoudakis, A. Zisman, A. Kozlenkov: A Service Discovery Framework for Service Centric
Systems. In: Proceedings of Service Computing Conference, SCC, 2005
[123] G.Chafle, K. Dasgupta, A. Kumar, S. Mittal, B. Srivastava: Adaptation in Web Service
Composition and Execution. In: International Conference on Web Serwices ICWS 2006, pp.
549-557
[124] G. Canfora, M. di Penta, R. Esposito, M.L. Villani: QoS-A ware Replanning of Composite Web
Services. In: ICWS 2005 Proc., Orlando, 2005
[125] T.Gao, H. Ma, I.-L.Yen, F. Bastani, W.T. Tsai: Toward QoS analysis of adaptive service-oriented
architecture. In: Toward QoS analysis of adaptive service-oriented architecture (SOSE), 2005, pp.
219-226
[126] P.C. Xiong, Y.S. Fan, M.C. Zhou, M.C.: Petri net-based Approach to QoS-aware Configuration
for WS. In: IEEE International Conference on Systems, Man and Cybernetics, 2007, pp. 1286-
1291
[127] A. Brogi, R. Popescu: Automated generation of BPEL adapters. IN: Dan, A., Lamersdorf, W.
(eds.) ICSOC 2006. LNCS, vol. 4294. Springer, Heidelberg, 2006, pp. 27-39
[128] B. Benatallah, F. Casati, D. Grigori, Ht.R.M. Nazhad, F. Toumani: Developing Adapters for
Web Services Integration. In: O. Pastor, Falcao e Cunha, J. (eds.) CAiSE 2005. LNCS, vol.
3520, Springer, Heidelberg, 2005, pp. 415-429
[129] M. Dumas, M. Spork, K. Wang: Adapt or perish: Algebra and visual notation for service interface
adaptation. In: S. Dustdar, J.L. Fiadeiro, AP. Sheth (eds.) BPM 2006. LNCS, vol. 4102. Springer,
Heidelberg, 2006, pp. 65-80
[130] W. Kongdenfha, R. Saint-Paul, B. Benatallah, F. Casati: An aspect-oriented framework for
service adaptation. In: Dan, A., Lamersdorf, W. (eds.) ICSOC 2006. LNCS, vol. 4294. Springer,
Heidelberg, 2006, pp. 15-26
218
[131] S.K. Williams, S.A. Battle, J.E. Cuadrado: Protocol Mediation for Adaptation in Semantic Web
Services. In: 2nd European Semantic Web Conference, 2006, pp. 635-649
[132] S. Modafferi, E. Mussi, B. Pernici: Sh-bpel: a self-healing plug-in for wsbpel engines. In:
Proceedings of the 1st Workshop on Middleware for Service Oriented Computing, MW4SOC
2006, Melbourne, Australia, 27 noiembrie-1decembrie 2006, pp. 48-53
[133] B. Pernici, A.M. Rosati: Automatic Learning of Repair Strategies for Web Services. In:
Proceedings of the Fifth European Conference on Web Services (ECOWS), 26-28 noiembrie,
2007, pp. 119-128
[134] L. Baresi, C. Ghezzi, S. Guinea: Towards Self-healing Service Compositions. In: First
Conference on the PRInciples of Software Engineering (PRISE), 2004, pp. 11-20
[135] L. Baresi, S. Guinea, L. Pasquale: Self-healing BPEL processes with Dynamo and the JBoss
rule engine. In: ESSPE 07: International workshop on Engineering of software services for
pervasive environments, 2007, pp. 11-20
[136] A. Erradi, P. Maheshwari, V. Tosic: Policy-driven middleware for selfadaptation of web services
compositions. In: van Steen, M., Henning, M. (eds.) Middleware 2006. LNCS, vol. 4290.
Springer, Heidelberg, 2006, pp. 62-80
[137] http://www.w3.org/Submission/WS-Policy/
[138] L. Console, M.G. Fugini: The WS-Diamond Team.WS-DlAMOND: an approach to Web
Services - DIAgnosability, MONitoring and Diagnosis. In: e- Challenges Conf. 2007, The Hague,
octombrie 2007
[139] E. Rukzio, S. Siorpaes, O. Falke, H. Hussmann: Policy based adaptive services for mobile
commerce. In: WMCS 05: Proceedings of the Second IEEE International Workshop on Mobile
Commerce and Services, Washington, DC, USA, IEEE Computer Society, 2005, pp. 183-192
[140] S. lllner, A. Pohl, H. Krumm, I. Luck, D. Manka, T. Sparenberg: Automated runtime management
of embedded service systems based on design-time modeling and model transformation. In: 3rd
IEEE International Conference on Industrial Informatics, 2005, pp. 134-139
[141] J. Siljee, I. Bosloper, J. Nijhuis, D. Hammer: DySOA: Making service systems self-adaptive. In:
B. Benatallah, F. Casati, P. Traverso, (eds.) ICSOC 2005. LNCS, vol. 3826. Springer, Heidelberg,
2005, pp. 255-268
[142] S.O. Hallsteinsen, E. Stav, A. Solberg, J. Floch: Using Product Line Techniques to Build
Adaptive Systems. In: SPLC, 2006, pp. 141-150
[143] R.Clotet, D. Dhungana, X. Franch, P. Grunbacher, L. Lopez, J. Marco, N. Seyff: Dealing with
Changes in Service-Oriented Computing Through Integrated Goal and Variability Modelling. In:
Proceedings 2nd International Workshop on VaMoS, 2008
[144] http://www.ifac-tc53.org/ accesat la 10.10.2013
[145] F.B. Vernadat, Enterprise Modeling and Integration (EMI): Current Status and
ResearchPerspectives. Annual Reviews in Control. 26, 2002, pp. 1525
[146] H. Panetto, J. Cecil, Information Systems for Enterprise Integration, Interoperability and
Networking: Theory and Applications, Enterprise Information Systems, DOI :
10.1080/17517575.2012.684802, 2013, pp. 1-6
[147] IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries ,
IEEE 610-1990, 1990
[148] Department of Defense Dictionary of Military and Associated Terms (Joint Publication 1-02),
U.S. Department of Defense. Accesat la 20.02.2013:
http://www.dtic.mil/doctrine/new_pubs/jp1_02.pdf
219
[149] Interoperabilitate, Wikipedia, Accesat la 20.02.2013:

http://en.wikipedia.org/wiki/Interoperability#_note-0
[150] ISO TC184/SC5, Advanced automation technologies and their applications Part 1 : Framework
for enterprise interoperability (ISO/DIS 11354-1:2011), 2011
[151] Livrabilul DI.2: Enterprise Interoperability-Framework and knowledge corpus-Advanced report,
INTEROP NoE Project (FP6 IST-1-508011). Accesat la 20.02.2013 la: http://interop-
vlab.eu/ei_public_deliverables/interop-noe-deliverables/di-domain-interoperability/di-2-
enterprise-interoperability-framework-and-knowledge-corpus/
[152] Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their
Application (FP6 IST-507849). Disponibil la 20.02.2013 la: http://interop-
vlab.eu/ei_public_deliverables/athena-deliverables/list-of-public-deliverables-submitted-during-
the-athena-project
[153] Agostinho, 2012
[154] ISO 15704, Industrial Automation SystemsRequirements for Enterprise-reference Architectures
and Methodologies, 2000
[155] Open Group, TOGAF: The Open Group Architecture Framework, Document No. 1910, Version
6, December 2000
[156] IEEE 1471, Recommended Practice for Architectural Description of Software- Intensive Systems,
2000
[157] IFACIFIP Task Force, GERAM: Generalized Enterprise Reference Architecture and
Methodology, Version 1.6.3, IFACIFIP Task Force on Architecture for Enterprise Integration,
1999
[158] David Chen, Guy Doumeingts, Franois Vernadat, Architectures for enterprise integration and
interoperability: Past, present and future. In: Computers in Industry 59 (2008) 647659
[159] EN/ISO I9439, Enterprise IntegrationFramework for Enterprise Modelling, 2003
[160] F.B. Vernadat, Enterprise Modeling and Integration: Principles and Applications, Chapman &
Hall, London, 1996
[161] D.N. Shorter, Requirements for enterprise model execution and integration services, in: N.
Kosanke (Ed.), Enterprise Engineering and Integration: Building International Consensus,
Springer-Verlag, Berlin, 1997, pp. 235243
[162] G. Doumeingts, B. Vallespir, D. Chen, Decision modelling GRAI grid, in: P. Bernus, K. Mertins,
G. Schmidt (Eds.), Handbook on Architecture for Information Systems, Springer-Verlag, Berlin,
1998
[163] D. Chen, F. Vernadat, Enterprise interoperability: a standardisation view, in: K. Kosanke, et al.
(Eds.), Enterprise Inter-and-Intra Organisational Integration, Kluwer Academic Publishers, 2002,
pp. 273282 (ISBN 1-4020-7277-5)
[164] D. Chen, F. Vernadat, Standards on enterprise integration and engineering-a state of the art,
International Journal of Computer Integrated Manufacturing 17 (3) (2004) 235253
[165] IEEE, (1990) IEEE standard computer dictionary: a compilation of IEEE standard computer
glossaries
[166] F.B. Vernadat, (1996) Enterprise Modelling and Integration: Principles and Applications,
Chapman & Hall, London
[167] IDEAS, IDEAS Project Deliverables (WP1-WP7), Public Reports, 2003.]
[168] AMICE, CIMOSAOpen System Architecture for CIM, 2nd edition, Springer- Verlag, Berlin,
1993
220
[169] T.J. Williams, The Purdue enterprise reference architecture, Computers in Industry 24 (2/3) (1994)
141158.
[170] D. Chen, G. Doumeingts, The GRAI-GIM reference model, architecture and methodology, in: P.
Bernus, et al. (Eds.), Architectures for Enterprise Integration, Chapman & Hall, London, 1996.
[171] A.-W. Scheer, Business Process Engineering. Reference Models for Industrial Enterprises, 2nd
edition, Springer-Verlag, Berlin, 1994
[172] J. Zachman, The Framework for Enterprise Architecture: Background, Description and Utility,
Zachman Institute for Advancement, 1996, http://www.zifa.com (effective link on April 2007)
[173] http://www.pera.net/Methodologies/Cimosa/CIMOSA.html
[174] http://cimosa.cnt.pl/
[175] http://cimosa.cnt.pl/Docs/Primer/primer5.htm
[176] http://www.atb-bremen.de/projects/prosme/Doku/oqim/grai_old.htm
[177] http://www.zachman.com/about-the-zachman-framework
[178] P. Bernus, L. Nemes, G. Schmidt (Eds.), Handbook on Enterprise Architecture, Springer-Verlag,
2003
[179] C4ISR, Architecture Working Group (AWG), C4ISR Architecture Framework, Version 2.0,
December 18, 1997
[180] DoD, DoD Architecture Framework Working Group, DoD Architecture Framework, Version 1.0,
vol. 1: Definitions and Guidelines, February 9, 2004
[181] http://www.pera.net/Standards/Relation_of_ISO_and_CEN.html
[182] ISO/IEC 10746-1, Information TechnologyOpen Distributed Processing Reference Model,
Overview, December 15, 1998
[183] C4ISR, Architecture Working Group (AWG), Levels of Information Systems Interoperability
(LISI), March 30, 1998.
[184] T. Clark, R. Jones, Organizational Interoperability Maturity Model for C2, Department of
Defense, Canberra, Australia, 1999
[185] ATHENA Integrated Project (507849), Framework for the Establishment and Management
Methodology, Deliverable DA1.4, 2005
[186] IDEAS, 2002, Thematic Network, IDEAS: Interoperability Development for Enterprise
Application and SoftwareRoadmaps, Annex 1DoW, May 13, 2002
[187] ATHENA, Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks
and their Applications, FP6-2002-IST1, Integrated Project, 2003
[188] EIF, European Interoperability Framework, White Paper, Brussels, February 18, 2004.
[189] EIF, European Interoperability Framework for PAN-European EGovernment Services, IDA
Working Document, Version 4.2, January 2004
[190] http://ec.europa.eu/idabc/en/document/2319/5644.html
[191] http://ec.europa.eu/idabc/en/document/2317/5644.html
[192] D. Chen, M. Dassisti, A. Tsalgatidou, Interoperability Knowledge Corpus, Deliverable DI.1,
Workpackage DI, INTEROP NoE, November 25, 2005
[193] D. Chen, N.Daclin, Framework for Enterprise Interoperability, IFAC TC5.3 Workshop EI2N06,
Bordeaux, France, March 21, 2006
[194] ERISA, The European Regional Information Society Association, A Guide to Interoperability for
Regional Initiatives, Brussels, September 2004.
[195] IEEE 1471, gsit la: http://www.iso-architecture.org/ieee-1471/]
221
[196] Arne-Jrgen Berre, Brian Elvester, Nicolas Figay, Claudia Guglielmina, Svein G. Johnsen, Dag
Karlsen, Thomas Knothe and Sonia Lipp. The ATHENA Interoperability Framework,
http://www.txtgroup.com/newsletter/attachment/Athena_Paper.pdf
[197] C. Guglielmina, A. Berre, ATHENA, Project A4 (Slide Presentation), in: ATHENA
Intermediate Audit, Athens, Greece, September 2930, 2005.
[198] INTEROP, Enterprise Interoperability-Framework and knowledge corpus - Final report,
INTEROP NoE, FP6 Contract n 508011, Deliverable DI.3, May 21st 2007
[199] INTEROP (2004) Knowledge map of research in interoperability, D1.1, INTEROP NoE, WP1,
version 1
[200] Michael J. Pratt, Introduction to ISO 10303 - the STEP Standard for Product Data Exchange,
accesat pe data de 13.05.2013 la adresa http://www.mel.nist.gov/msidlibrary/doc/jcise1.pdf
[201] ISO, ISO 10303:1994 - Industrial Automation Systems and Integration - Product Data
Representation and Exchange. (The ISO web site is at http://www.iso.ch/cate/cat.html - search on
10303 to find a list of parts of the standard)
[202] D. A. Schenk and P. R. Wilson, Information Modeling: The EXPRESS Way, Oxford University
Press, New York, NY, USA, 1994 (ISBN 0-19-508714-3)
[203] http://www.mel.nist.gov/sc5wg1/std-dft.htm
[204] ISO 15745 (2000), Industrial automation systems and integration Open systems appli-cation
integration frameworks, ISO/TC/184/SC5
[205] ISO 16100 (2002), Industrial automation systems and integration Manufacturing soft-ware
capability profiling for interoperability, ISO/TC/184/SC5
[206] http://www.iso.org/iso/catalogue_detail.htm?csnumber=33834
[207] L. Stanciu, Logistic Industrial i Comercial Curs pentru master, Sisteme Informatice Aplicate
n Producie i Servicii, 2011
[208] I. Dumitrache, T.Dragomir, Automatica, vol. II, Editura Academiei Romne, 2012
[209] A. M. Stanescu, S. I. Caramihai, Sisteme Dinamice cu Evenimente Discrete, Editura Politehnica,
1996
[210] T. Leia T., A. Atilean, Sisteme cu evenimente discrete: modelare, analiz, sintez i control.
Editura Albastr, Cluj-Napoca, 1998
[211] T. Murata, R. David, H. Alla, Discrete, Continuous, and Hybrid Petri Nets, ISBN 3-540-22480-7
Springer Berlin Heidelberg New York, 2005
[212] Kovair, Change Management Process Identify, Evaluate & Implement , accesibil la:
http://www.kovair.com/itsm-solutions/change-management-process.html
[213] D. Nadier, M. Tushma, M.: Organizational Frame Bending: Principles for Managing
Reorientation, In The Academy ol MMingement EXECUT) Vt, 1989, Vol. III. No. J, pp. 194-204
[214] http://www.mbaknol.com/management-concepts/factors-affecting-organizational-change/
[215] http://ayushveda.com/blogs/business/organizational-change-influencing-factors/
[216] http://smallbusiness.chron.com/factors-may-cause-change-organization-203.html
[217] J. Kotter, "Change Management vs. Change Leadership -- What's the Difference?". Forbes
online. Accesat la data de 21.05.2013
[218] http://www.change-management.com/tutorial-2007prep-strategy.htm, accesat la 29.07.2013
[219] P.J.M. Frederiks and T.P. Van Der Weide, Information modeling: The process and the required
competencies of its participants. Data & Knowledge Engineering 58 (1), 4-20, 2006
[220] J. Recker,: A socio-pragmatic constructionist framework for understanding quality in process
modelling. Australasian Journal of Information Systems 14 (2), 2007, pp. 43-63
222
[221] Mendling, J., Recker, J., Reijers, H. A., PROCESS MODELING QUALITY: A FRAMEWORK
AND RESEARCH AGENDA, accesat la 01.08.2013 la http://bpmcenter.org/wp-
content/uploads/reports/2009/BPM-09-02.pdf
[222] M. Rosemann, J. Recker, M. Indulska, P. and Green: A study of the evolution of the
representational capabilities of process modeling grammars. In Advanced information systems
engineering - caise 2006 (Dubois, E. and Pohl, K., Eds), Springer, Luxembourg, Grand-Duchy of
Luxembourg, 2006, pp 447-461
[223] P. Soffer and Y. Wand, Goal-driven multi-process analysis. Journal of the Association for
Information Systems 8 (3), 2007, pp 175-202
[224] W. M. P. Van Der Aalst, A. H. M. Ter Hofstede, B. Kiepuszewski and A.P. Barros, Workflow
patterns. Distributed and Parallel Databases 14 (1), 2003, pp 5-51
[225] J. Recker, M. Indulska, M. Rosemann, P. and Green, How good is bpmn really? Insights from
theory and practice. In 14th European Conference on Information Systems (Ljungberg, J. and
Andersson, M., Eds), Association for Information Systems, Goeteborg, Sweden, 2006, pp 1582-
1593
[226] H. Weber, H. Ehrig, W. Reisig, A. Borusan, S. Lembke, J. Dehnert, M. Weber, A. Martens, J.
Padberg, C. Ermel, and A. Q. Emali: The Petri Net Baukasten of the DFG Forschergruppe PETRI
NET TECHNOLOGY, LNCS 2472, 2003, pp. 121
[227] J. Dehnert. The Common Base of the Petri Net Baukasten. In Int. Colloquium on Petri Net
Technologies for Modelling Communication Based Systems, Part II: The _Petri Net Baukasten.
Fraunhofer Gesellschaft ISST, October 1999
[228] H. Weber, S. Lembke and A. Borusan. Improving the Usability of Petri Nets with the Petri Net
Baukasten. In Advances in Petri Nets: Unifying Petri Nets, volume 2128 of LNCS. Springer, 2001
[229] S. Lembke. The Application Developer View of the Petri Net Baukasten. In Int. Colloquium on
Petri Net Technologies for Modelling Communication Based Systems, Part II: The _Petri Net
Baukasten_. Fraunhofer Gesellschaft ISST, October 1999, pages 231241
[230] DFG-Forschergruppe Petri Net Technology. Initial realization of the _Petri Net Baukasten_.
Informatik-Berichte 129, Humboldt-Universitat zu Berlin, October 1999
[231] http://www.bpmn.org/
[232] M. George: Lean six sigma for service, The McGraw-Hill Companies, Inc., 2003
[233] H. Skalle, B. Hahn: Applying Lean, Six Sigma, BPM, and SOA to Drive Business Results, accesat
la 13.09.2013 la http://www.redbooks.ibm.com/abstracts/redp4447.html
[234] http://www.businessdictionary.com/definition/service-level-agreement.html
[235] Web Service Level Agreement (WSLA) Language Specification, disponibil la:
http://www.research.ibm.com/people/a/akeller/Data/WSLASpecV1-20030128.pdf
[236] Understanding quality of service for Web services
http://www.ibm.com/developerworks/webservices/library/ws-quality
[237] Open Group Standard TOGAF Version 9.1, 2009, disponibil la
http://www.opengroup.org/architecture/togaf91/downloads.htm
[238] C.T. Fitz-Gibbon: Performance indicators, In: BERA Dialogues (2), ISBN 978-1-85359-092-4,
1990
[239] Key performance Indicators, Disponibil la:
http://management.about.com/cs/generalmanagement/a/keyperfindic.htm, 2013
[240] Examples of KPI, Key Performance Indicators for Different Roles, Disponibil la:
http://suite101.com/article/examples-of-kpi-performance-indicators-for-different-roles-a270390,
2013
223
[241] http://www.ic.gc.ca/eic/site/pp-pp.nsf/eng/home
[242] http://hammerora.sourceforge.net/document.html
[243] M.N. Huhns, M.P. Singh: Service-Oriented Computing: Key Concepts and Principles. IEEE
Internet Computing 9(1), 2005, pp.75-81
[244] M.P. Papazoglu, P. Traverso, S. Dustdar, F. Leymann: Service-Oriented Computing: State of the
Art and Research Challenges. Computer 40(11), 2011, pp. 38-45
[245] F. Curcubera, M. Duftler, R. Khahaf, W. Nagy, N. Mukhi, S. Weerawarana: Unravelling the Web
Services Web: An introduction to SOAP, WSDL, and UDDI. IEEE Internet Computing 6(2),
2002, pp. 86-93
[246] http://www.w3.org/TR/wsdl
[247] http://www.w3.org/TR/soap/
[248] http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf
[249] M. Papazoglu, K. Pohl, M. Parkin, A. Metzger: Service Research Challenges and Solutions for
Future Internet, Springer-Vertag Berling Heidelberg, 2010
[250] F. Casati, S. Ceri, B. Pernici, G. Pozzi, Workflow evolution, Data Knowl Eng 24, 1998, pp. 211-
238
[251] G. Joeris, O. Herzog, Managing eolving workflow specifications. In: Proceedings of the 3rd
IFCIS International Conference on Cooperative Information Systems, New York Citym New
York, USA, 1998, pp.310-321
[252] M. Reichert, P. Dada: Adeptflex-supporting dynamic changes of workflows without loosing
control. J. Intell. Inf. Syst. 10(2): pp. 93-129
[253] M. Reichert, S. Rinderle, P. Dadam: On the common support of workflow type and instance
changes under correctenss constraints. In: Proceedings of the 2003 OTM Confederated
international conferences. CooplS. DOA. and ODBASE Catania, Sicily, Italy, 2003, pp.407-425
[254] S. Rinderle, B. Weber, M. Reichert, W. Wild: Integrating process learning and process evolution -
a semantics based approach. In: Proceedings of the 3rd international conference, Nancy, France,
BMP 2005, pp 252-267
[255] S.W. Sadiq, Handling dynamic schema change in process models. In: Proceedings of the 2000
Australasian dabasian conference, 2000, pp. 12-126
[256] W.M.P. Van der Aalst, A.H.M. Hofstede, B. Kiepuszewski, A.P. Barros, Workflow patterns.
Distr Parallel Databases 14(1), 2003, pp. 5-51
[257] http://archive.modeliosoft.com/en/modules/modelio-bpel-designer.html
[258] http://www.eclipse.org/bpel/
[259] http://www.oracle.com/technetwork/middleware/soasuite/downloads/index.html
[260] http://www.oracle.com/technetwork/middleware/bpel/overview/ds-bpel-11gr1-1-134826.pdf
[261] http://technology.amis.nl/2012/11/18/oracle-soa-suite-11g-ps-5-introduces-bpel-with-conditional-
correlation-for-aggregation-scenarios/
[262] http://www-01.ibm.com/support/docview.wss?uid=swg24030614
[263] http://pic.dhe.ibm.com/infocenter/esbsoa/wesbv7r5/index.jsp?topic=%2Fcom.ibm.wbpm.wid.bpel
.doc%2Ftopics%2Fcunact.html
[264] http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r1mx/index.jsp?topic=/com.ibm.btools.help
.modeler.doc/doc/tasks/widmodeling/analyzingchanges.html
[265] M. P. Papazoglou, The challenges of service evolution, in CAiSE, Montpellier, France, 2008,
pp. 115
[266] Y. Wang, J. Yang, W. Zhao: Change impact analysis for service based business processes, 2010
224
[267] Business process execution language for web services version 1.1, 2003. [Online]. Accesat la
25.05.2013 la http://www.ibm.com/developerworks/library/ws-bpel/
[268] M. Dumas, B. Benatallah, and H. R. M. Nezhad, Web service protocols: Compatibility and
adaptation, vol. 31, no. 3, 2008, pp. 4044
[269] M. Reichert and P. Dadam, Adeptflex-supporting dynamic changes of workflows without losing
control, J. Intell. Inf. Syst., vol. 10, no. 2, 1998, pp. 93129
[270] G. Salaun, L. Bordeaux, and M. Schaerf, Describing and reasoning on web services using
process algebra, in ICWS, 2004, pp. 4352.
[271] L. de Alfaro and T. Henzinger, Interface automata, in joint ESEC/FSE, 2001, pp. 109120
225

Teza Cristian Danila

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Teza Cristian Danila

Încărcat de

Drepturi de autor:

Formate disponibile

FONDUL SOCIAL EUROPEAN

UNIVERSITATEA POLITEHNICA DIN BUCURETI

Nr. Decizie Senat 226 din 28.11.2013

Dynamic Configuration of Collaborative Networked Organization by

Autor: Ing. Cristian Dnil

Conductor de doctorat: Prof.dr.ing. Aurelian Mihai Stnescu

Viitoarei mele soii, prinilor mei

2. Scopul propus i obiectivele etapelor planului individual de cercetare 17

STADIUL ACTUAL AL CUNOATERII N DOMENIUL SISTEMELOR

1.1. TRSTURI CARE DEFINESC UN CADRU DE MODELARE PENTRU UN SISTEM

1.1.1. Universul discursului 21

1.2. CERINTE, ATRIBUTE, PROPRIETI ALE UNUI SISTEM DE SISTEME

1.2.2. Spaiile cunoaterii universului Future Internet Enterprise Systems 25

1.2.3. Direcia de cercetare Horizon 2020 30

1.3. TENDINE DE DEZVOLTARE ALE CERCETRII I INOVRII PENTRU

1.3.1. Specificul sub-sistemelor Service Based Systems 38

1.3.2. Clasa sistemelor Collaborative Networked Systems/Organisation 39

1.3.2.3. Managementul organizaiilor virtuale 50

1.3.3. Modele de compunere a serviciilor web 63

CERINE I SPECIFICAII LA NIVEL CONCEPTUAL PENTRU

2.1. CONCEPTE FUNDAMENTALE 78

2.2. NIVELURI DE INTEROPERABILITATE 79

2.3. EVOLUIA SISTEMELOR INFORMAIONALE DE LA CONCEPTUL DE

2.3.1.1 Arhitecturi ale ntreprinderii 81

2.3.1.2 Concepte de baz ale arhitecturii ntreprinderii 81

2.3.1.3 Diferite tipuri de arhitecturi de ntreprindere 82

2.3.1.4. Integrarea la nivel de ntreprindere 82

2.3.1.5. Interoperabilitatea la nivel de ntreprindere 82

2.3.2. Istoric: Arhitecturi pentru integrarea la nivel de ntreprindere 83

2.3.2.1 Iniiative timpurii n privina arhitecturii de ntreprindere 83

2.3.2.2 Standarde privind integrarea la nivel de ntreprindere 90

2.3.3. Arhitecturi pentru interoperabilitatea la nivel de ntreprindere 92

2.3.3.1 Standarde de interoperabilitate 100

2.3.4. Concluzii 102

2.4. FORMULAREA PROBLEMEI DE REZOLVAT 102

2.4.1. Identificarea problemei la nivel de ntreprindere 102

2.4.2. Formularea propriu-zis a problemei 103

2.5. SUPORT FORMAL PENTRU CUTAREA SOLUIILOR 104

2.6. CONCLUZII 113

CONFIGURAREA DINAMIC A METASISTEMULUI N CARE

3.4. METODA DE REZOLVARE PROPUS 119

IDENTIFICAREA IMPACTULUI SCHIMBRILOR N CADRUL

4.1. INTRODUCERE 139

STUDIU DE CAZ 152

5.1. DESCRIEREA SCENARIULUI 152

5.2. DESCRIEREA PROCESELOR 153

5.3. CONCLUZII 165

C.1. CONCLUZII GENERALE 166

C.2. CONTRIBUII ORIGINALE 167

C.3. PERSPECTIVEDE DEZVOLTARE ULTERIOAR 168

A1. COD SURS INSTRUMENT DE ANALIZ A

IMPACTULUI SCHIMBRILOR 169

Future Internet Enterprise Systems (FInES) Sistem informaional, evoluat, dispersat

1. Context economic actual i motivaia abordrii temei de dizertaie

n ultima decad, domeniul serviciilor a cunoscut o dezvoltare impresionant. Pentru ca aceast

Comportamentul economic al ntreprinderilor i plasarea lor n contextul social a cunoscut

Constituirea ntreprinderilor n organizaii virtuale pentru oferirea de e-servicii i produse

Conform dicionarului explicativ romn, cuvntul paradigm reprezint un exemplu, un model,

T4 cei implicai n proiect sunt responsabili. Paradigma sistemic ar trebui s faciliteze

pot fi evaluate obiectiv. De asemenea, modelele trebuie s adauge managementul riscului,

T8 ar trebui s susin ntregul ciclu de via de la reprezentarea problemei la modelul de

T12 ar trebui s asigure un grad ct mai mare de autonomie n procesul decizional.

T14 ar trebui s fie corelat cu conceptul de interoperabilitate sistemic sustenabil [12]

T15 ar trebui s fie orientat ctre societate (bunstare, sntate) [11].