MODELAREA DECIZIEI

MONETAR - FINANCIARE

SUPORT DE CURS
 MODELARE SI SPECIFICAREA ÎNTREPRINDERII

Întelegerea exacta a ceea ce este de fapt un model, precum si a necesitatilor modelelor este
esential.
Definirea unui model
Un model este o reprezentare abstracta a realitatii. Se vor determina aspectele lumii reale care sunt de
interes si se vor identifica elementele sistemului care urmeaza a fi modelate. Modelul unei întreprinderi se
defineste ca fiind: o reprezentare simbolica a întreprinderii si a entitatilor cu care aceasta dialogh eaza.
Acestea contin reprezentari ale evenimentelor individuale, obiecte si relatii care apar în interiorul unei
întreprinderi (Presley, 1997). Aceasta definitie etaleaza tipurile de elemente care sunt de interes pentru
modelator. Utilizarea simbolurilor pentru reprezentarea întreprinderii, determina evenimentele
individuale, obiectele si relatiile de o maniera usor de înteles. Este important ca modelul întreprinderii sa
contina aspectele atât statice cât si pe cele dinamice ale întreprinderii (Pardasani si Chan, 1992) Aspectele
suplimentare sunt discutate separat, dar ceea ce este de retinut, ramâne faptul ca pentru o modelare
completa a întreprinderii sunt necesare mai multe puncte de vedere relative la aceasta. Presley (1993)
propune trei categorii:
1. acele procese care transforma restrictiile externe în restrictii interne (multimea directiilor);
2. acele procese care achizitioneaza si disponibilizeaza resursele necesare;
3. acele procese care utilizeaza resursele pentru a produce rezultatele întreprinderii;
Prin furnizarea categoriilor pentru organizarea proceselor se poate face o proiectare mai completa
a întreprinderii. Procesele economice sunt organizate într-o întreprindere reprezentata printr-un careu
mare. La acest nivel înalt de abstractizare, întreprinder ea însasi este reprezentata ca o activitate care ia
intrari, pe care le transforma în iesiri, prin utilizarea resurselor disponibile. În mod frecvent sunt luate în
considerare, pentru procesul de modelare, numai activitatile cuprinse în cea de a treia categorie, care
transforma intrarile în produse si servicii. Cu toate acestea este important sa fie luate în considerare
activitatile strategice ale întreprinderii. Întelegerea diferitelor categorii de procese este esentiala pentru
dezvoltarea reprezentarilor.
Necesitatea modelelor
Întelegerea comuna a întreprinderii este critica pentru orice efort de crestere. Modelarea este o abordare
necesara pentru a realiza o astfel de întelegere uzuala a întreprinderii si a modului în care acesta îsi va
îndeplini obiectivele viitoare. Modelele sunt utilizate uzual pentru:
- furnizarea unei focalizari a logosului
- furnizarea mijloacelor comunicatiei din întreprindere
- furnizarea unei baze pentru analiza si proiectarea proceselor noi
- actioneaza ca baza pentru continuarea cresterii proceselor
- faciliteaza controlul proceselor din lumea reala (Huckvale si Ould 1995)
În conformitate cu Frasier, modelarea întreprinderii faciliteaza întelegerea comuna a tuturor
aspectelor pertinente, descrierea clara a problemelor economice si a cer intelor acestora, identificarea
alternativelor de proiectare, precum si un mecanism acestor optiuni de implementare a proiectului, la
nivelul strategic, tactic si operativ (Frasier 1994). Petrie (1992) descrie importanta modelarii întreprinderii
prin furnizarea întelegerii comune a întreprinderii si a interactiunilor acesteia care pot fi utilizate pentru
optimizarea si cresterea acestor interactiuni.
Principii ale Modelarii Întreprinderii
Sunt enuntate (Ross si Schoman 1977) patru cerinte principale pentru orice tehnica de modelare. Acestea
includ un scop distinct al modelului, domeniul modelului (referit uzual ca fiind frontiera modelului)
punctul de vedere al modelului si nivelul de detaliere al modelului. Se vor adauga (Vernadat 1996) înca
opt principii prin CIM-OSA:
- principiul separarii continutului
- principiul descompunerii functionale
- principiul modularitatii
- principiul modelului generic
- principiul reutilizabilitatii
- principiul separarii comportamentului si functionalitatii
- principiul decuplarii proceselor si resurselor

1
 - principiul conformitatii
Vernadat enunta de asemenea principiile preluate de la Ward si Mellor (1985):
- principul vizualizarii modelului
- principiul simplicitatii versus adecvarii
- principiul gestiunii complexitatii
- principiul separarii datelor si al controlului
De altfel toate aceste principii vor fi utilizate pentru sustinerea acestei abordari. Determinarea
frontierei modelului si al nivelului de detaliere sunt centrale pentru aceasta.
Utilizarea modelelor întreprinderii
Modelarea întreprin derii a fost utilizata pentru constructia de modele ale organizatiilor în scopul
previzionarii si estimarii impactului schimbarilor din interiorul întreprinderii produse de modificarile
mediului extern. Puterea modelului deriva din posibilitatea acestuia de a simplifica sistemele lumii reale
pe care o reprezinta si de a previziona anumite aspecte ale evolutiei sistemului prin corespondente
evolutiilor din interiorul modelului (Wood 1994). Sunt enuntate, mai jos, utilizarile comune pentru
Modelarea Întreprinderii:
- Facilitarea întelegerii la nivelul uman si comunicatii. Aceasta este realizata prin identificarea:
semnificatiei elementelor, a ceea ce acestea trebuie sa realizeze, a modului în care acestea sunt realizate, a
celor care realizeaza aceasta, a ceea ce este de masurat, a costurilor asociate. Acestea, în mod uzual se vor
regasi sub forma unei semantici unificate;
- Sustinerea gestiunii proceselor si a cresterilor modelului; aceasta este realizata prin furnizarea
mecanismelor specifice întelegerii si analizei procesului;
- Furnizarea de ghiduri pentru procese; se va îndeplini prin furnizarea unui mecanism care sa asiste
operatorul uman în actuala executie a procesului.
- Facilitarea tiparelor de lucru: acestea solicita întelegerea si documentarea proceselor;
- Automatizarea executiei: se realizeaza prin furnizarea mecanismelor pentru executia proceselor;
- Validarea ingineriei întreprinderii; aceste modele sunt în prezent un mijloc de a valida comunicatia
în contextul ingineriei întreprinderii; în absenta modelului este foarte dificil de a realiza o forma de
inginerie;
- Facilitarea controlului proceselor din lumea reala.
Dupa Frasier modelarea întreprinderii valideaza:
- serveste ca mecanism pentru analiza în vederea implementarii proiectului la nivelele strategic,
tactic si operativ;
- furnizeaza suport de decizie prin furnizarea accesului la informatia necesara, prin simularea
alternativelor si implementarea în timp real a deciziilor;
- furnizarea unei laturi competitive – organizatia care are un model de întreprindere va fi capabila sa
reactioneze mai repede decât competitorii sai si sa obtina un avantaj prin studierea comportamentului
organizatiei bazat pe schimbarile care au loc în mediu.
Johnson, Melade 1995 sugestioneaza ca transformarile unei întreprinderi pot fi reprezentate ca o
serie de instante care descriu starea proceselor întreprinderii pe parcursul diferitelor stadii ale cresterii.
Aceste instante sau sabloane descriu operatiile proceselor, resursele, relatiile, capabilitatile etc. si include
cadre pentru procese li metrici pentru acestea. O privire generala si cele trei seturi de strategii sustin
transformarea. Modelul întreprinderii faciliteaza procesul de tranzitie prin furnizarea unei priviri
consistente si uzuale a acesteia. Se va considera, ca exemplu, cadrele reprezentate în figura ca fiind
diferite modele ale întreprinderii, care reprezinta întreprinderea în respectivul punct al tranzitiei. În
concluzie, utilizarea de baza a modelelor întreprinderii se refera la facilitarea tranzitie, precum si la
controlul acestei transformari.
Captarea cunostintelor domeniului
O componenta cheie al oricarui efort de crestere se va referi, cu precadere la mediul curent si la cerintele
pentru mediul viitor. SADT (Structured Analysis and Design Technique), premergator pentru IDEF, a
dezvoltat o modelare structurata a proceselor pentru captarea cunostintelor din domeniu. Cunostinta este
initial captata prin intermediul interviurilor care provin de la diferite surse. Aceste surse includ: oameni,
documente si observarii sistemului existent. Este foarte important ca autorii sa defineasca întrebari clare
pentru modelul raspunsului. Modelul trebuie sa aiba un singur subiect. Aceasta este referita curent ca
frontiera modelului. Modelul trebuie sa aiba, de asemenea, un singur punct de vedere.

2
Importanta modelarii pentru alte domenii de cercetare
Ingineria întreprinderii/integrare
Liles (Liles, Jonson 1996) defineste o întreprindere ca fiind: o multime complexa de procese economice
care pot fi proiectate pentru a îndeplini un set specific de obiective, Vernadat (1996) defineste
întreprinderea ca: realizarea unei colectii importante de procese economice concurente executate de o
multime de entitati functionale(sau resurse) care contribuie la procesele economice. În contextul
modelarii întreprinderii, termenul de întreprindere este utilizat pentru a desemna în mod specific acea
parte a companiei care este de interes. Acest domeniu este determinat de utilizatorul final al modelului.
Ingineria întreprinderii este definita ca un corp de cunos tinte, principii si practici care trebuie
realizate împreuna cu analiza, proiectarea, implementarea si operatia unei întreprinderi. Principiile si
practicile unei întreprinderi sunt: teoria, abstractizarea, proiectarea si implementarea. Un alt termen pentru
abstractizare este modelarea. Modelarea furnizeaza un mecanism pentru validarea întelegerii uzuale,
precum si a posibilitatilor de testare a ipotezelor. Ingineria întreprinderii priveste întreprinderile ca un
sistem complex de procese care pot fi puse în miscare pentru a îndeplini obiective organizationale
specifice. Ingineria întreprinderii trebuie sa recunoasca toate schimbarile de natura organica a
întreprinderii. Ingineria întreprinderii ia în considerare o abordare holistica, care este în opozitie cu cele
mai multe abordari limitative de proiectare a componentelor întreprinderii vizând doar post implementare,
aspectele integrarii. Petrie (1992) descrie importanta modelarii întreprinderii ca furnizoare a întelegerii
uzuale a acesteia si a interactiunilor care pot fi utilizate pentru a rationaliza si creste aceste interactiuni.
Petrie statueaza ca: Integrarea Întreprinderii se distinge prin concentrarea pe cresterea coordonarii relativ
la interactiunile dintre organizatii, indivizi si sisteme, II este or ientata initial pe integrarea din interiorul
întreprinderii, urmând abordarea integrarii dintre întreprinderi. Orice efort II este calat pe integrare, iar
acest deziderat este partial acoperit de modelarea întreprinderii pentru a sustine identificarea
componentelor integrarii.
Restructurarea proceselor economice
Restructurarea proceselor economice (BPR) este caracterizata de Hammer si Champy ca: o multime de
proceduri care au ca efect schimbari radicale. Cresterea continua (CI) este privita ca un constructor peste
procesele economice existente, pentru a le face mai bune, mai rapide si mai ieftine. CI este în contrast cu
BPR în ceea ce priveste natura incrementala. La modul ideal o schimbare radicala a procesului economic
cu abordarea BPR conduce la reformularea întreprinderii, pe când cresterea incrementala (continua) este
oarecum mai naturala. Anumiti autori nu fac o asemenea distinctie drastica relativa la abordarea BPR, dar
pentru abordarea prezenta se va utiliza formularea lui Champy. Atât BPR, cât si CI sunt tare legate de
întelesul curent al întreprinderii. Un model al întreprinderii este esential pentru ambele.
Modelarea si simularea (M&S)
M&S este considerata o parte importanta oricarui efort de crestere. Programul Next Generation
Manufacturing o pastreaza ca fiind: ”una dintre cheile care valideaza o forma mai completa si mai
integrata a realizarii rapide produs/proces” reducând astfel dramatic timpul aparitiei în piata a produsului.
Proiectarea va fi analizata prin prisma optimizarii procesului economic, al produsului, al procesului al
facilitatilor si al echipamentului care sa fie capabil de proiectul dat. Utilizarea principala a modelarii si
simularii a fost orientata pe ciclul de viata al dezvoltarii produsului, fiind, de asemenea, utilizata si la
proiectarea si analiza proceselor.
Surse ale modelarii întreprinderii
Exista mai multe surse legate de modelarea întreprinderii, în general, fiind identificate urmatoarele (Fox
1993):
- lack of currency a modelului întreprinderii
- modelul vizualizat este un simplu instrument pentru constructia deciziei
- dificultati în determinarea frontierelor modelului
- dificultati în pastrarea consistentei modelului
- lipsa integrarii diferitelor puncte de vedere (crearea unui model pentru întreaga întreprindere)
- definitiile minimale a diferitilor termeni din model
Abordarea se va orienta, cu precadere asupra primelor doua puncte din identificare. Acestea sunt
dependente între ele. Daca modelul este pastrat curent potentialul acestuia de a fi utilizat dupa decizia
initiala creste. Similar, daca modelul este privit mai mult decât un simplu instrument pentru facilitarea
raspunsului la întrebarile initiale atunci modelul va fi pastrat curent.

3
Metodele modelarii
IDEF (Integration DEFinition) a fost dezvoltata de US Air Force, la începutul anilor ’80. Exista, la ora
actuala mai multe metode IDEF. Fiecare metoda este propice pentru descrierea unei perspective
particulare a unei întreprinderi. Metodele IDEF importante considerate sunt:
- IDEF0 - modelarea functionala (sau a activitatii)
- IDEF1 - modelarea informatiei
- IDEF1x - modelarea datelor
- IDEF3 - captarea descrierilor proceselor
- IDEF4 - proiectarea orientata obiect
- IDEF5 - captarea ontologiei
Pentru (IDEF2) ipoteza de lucru se referea la utilizarea acesteia ca o metoda de modelare
dinamica pentru simulare, dar numeroasele instrumente comerciale disponibile în piata suplinesc aceasta
metoda.
Majoritatea metodelor IDEF utilizeaza un principiu subordonat abstractizarii: descompunerea
(Rumbaugh, Blaha 1991), care este o spargere a fiecarei activitati, în detalii mai fine, de o maniera
continua, pâna la atingerea nivelului convenabil de detaliere.

Figura 2.1 Descompunerea functionala [Whi99]

IDEF0 a fost prima tehnica de modelare definita în seria metodelor de modelare IDIDEF. Acesta îsi are
radacinile în SADT (Structural Analisys Design Technique). Sunt identificate cinci elemente :
- activitatile (functiile) sunt reprezentate prin dreptunghiuri;
- intrarile – reprezentate prin sageti care intra în partea stânga a unei activitati;
- iesirile - reprezentate prin sageti care ies dintr-o activitate;
- restrictiile sau controalele unei activitati – sageti care intra în partea superioara a activitatii;
- mecanismele de transport în afara al activitatii – sageti care ies în partea inferioara a activitatii
(Mazer 1992);
IDEF0 a fost utilizat extensiv, fiind astfel multe exemple de utilizare a acesteia:
- Islam (Islam 1997) utilizarea IDEF0 pentru a defini sistemele CIM generice;
- Presley (Presley, Huff 1993), (Presley si Liles 1995) propun un model de întreprindere pentru
IMM utilizând IDEF0 si pentru specificarea metodologiei, în general;
- Sarkis (Sarkis, Presley 1997) descriu metodologia de evaluare a proiectelor candidate BPR
care utilizeaza IDEF0;

4
 - Presley (Presley, Withman 1997) prezinta de asemenea o metodologie pentru managementul
strategic al performantei întreprinderii.
Metodologia utilizeaza si integreaza instrumentele si metodele pentru managementul
performantei regasit în literatura si în practica.
IDEF1 si IDEF1x
Mai multe serii de modelare contin un mecanism de reprezentare al datei. IDEF1 are intentia de a
capta datele într-o forma relationala. IDEF1 este utilizat tipic pentru:
- identificarea rolului pentru managementul informatiei
- identificarea problemelor cauzate de lipsa gestiunii acestor informatii
- definirea managementului adecvat al informatiei pentru mediul considerat
IDEF1 nu si-a propus sa fie o metoda pentru proiectarea bazelor de date relationale. Mai degraba
îsi propune sa furnizeze o privire grafica pentru manageri, pentru ca acestia sa înteleaga propria
informatie curenta si pentru identificarea si implementarea politicilor mai eficient utilizând propriu
management informational. Daca IDEF1 nu este o metoda de proiectare al BD relationale, IDEF1x a fost
proiectata, în mod special pentru acest scop. ISEF1x nu este creat pentru definirea cerintelor. Odata ce au
fost bine definite cerintele pentru BD IDEF1x poate fi utilizat pentru proiectarea respectivei BD, fiind
limitat la BD relationale. Pentru BD orientate obiect trebuie utilizat IDEF4.
IDEF3 Metoda de captare a descrierii proceselor (Mazer, Cullinane 1992) consta din diagrame ale
fluxului proceselor si retele de tranzitii a starii obiectelor. Elementele de baza ale descrierii proceselor
IDEF3 utilizeaza o sintaxa rigida, care, însa elimina ambiguitatile modelelor. Elementele luate în
considerare în prezenta abordare sunt:
- UOB – Unit of Behaviours (unitatea comportamentelor) descrie detaliat procesul actual într-un box
- Jonctiuni – descriu explicit logica link-urilor mult iple fie pentru concentrarea acestora, fie pentru
separarea lor (exemple: puncte de decizie sau entitati care se ramifica în fluxuri paralele a pasilor
proceselor)
- Link-uri – conecteaza box-urile si descriu relatiile dintre diferitele UOB
Un exemplu de model IDEF3 UOB, link-uri si diferite tipuri de jonctiuni este dat în figura 2.2.

Figura 2.2.
Descrierea IDEF3[Whi99]

IDEF3 a fost utilizat în mai multe tipuri de aplicatii. Cele mai multe s-au referit la utilizarea acestuia ca
front-end, pentru simulare si ca instrument de documentare al simularii (Benjamin, Marshall 1997).
Rensburg (van Rensburg Zwemstra 1995) apreciaza ca utilizarea tehnicilor IDEF (IDEF0 si IDEF3)
salveaza 50% din efortul normal de analiza si cresc acceptabilitatea si calitatea modelelor de simulare
rezultate. Un alt tip de aplicatie notabila este legata de fiabilitate si evaluarea riscului (Kusik, Zakarian
1995).
IDEF5 este metoda de captare a ontologiilor. Ontologiile sunt instrumente puternice pentru captarea
cunostintelor de baza a informatiilor dintr-un domeniu dat. Cantitatea de munca necesara pentru a
dezvolta metode pentru ontologii si în general teorii ontologie este deosebit de importanta. Eforturile de a
dezvolta ontologiile limitate la întreprindere se datoreaza: Mayer, Menzel 1993, Fadel ,Fox 1994,
Gruninger, Fox 1994, Gruninger, Fox 1995, Ushold, King 1995.
Proiectele, în general, si proiectele CIM în particular, care se expandeaza în latime , sunt expuse
la aparitia de discrepante în terminologie. Prim furnizarea unei ontologii pentru sistemul supus
modificarilor, personalul implicat va partaja un domeniu comun al discursului. IDEF5 va furniza de
asemenea mecanisme pentru modele de referinta pentru a facilita recunoasterea similitudinilor dintre
componentele sistemului, precum si cu componentele sistemelor externe. IDEF5 este utilizat pentru
modelarea conceptelor si a relatiilor dintre aceste concepte. Benjamin (Benjamin, Menzel 1994) dau cinci
activitati în captarea ontologiei:
- organizarea si definirea proiectului
- colectarea datelor
- analiza datelor
- dezvoltarea ontologei initiale

5
 - rafinarea si validarea ontologiei
Ca rezultat al efortului de modelare, captarea ontologiei are doua beneficii primare: cunostintele
acumulate pe parcursul dezvoltarii modelului si beneficiile rezultate chiar din modelul rezultat. Aceste
beneficii includ:
- termenii comuni pentru dezvoltarea sistemului;
- un model de referinta pentru planificarea si controlul proceselor;
- pot valida orice efort de redimensionare sau de restructurare al sistemului.

Reprezentarea proceselor
Rummler si Brache descriu o tehnica denumita “Process Mapping” (PM). Se considera organizatia ca un
sistem adaptiv. În consecinta, conducatorii acesteia trebuie sa gestioneze adaptarea acestei organizatii, pe
perioada modificarilor frecvente ale tuturor componentelor sistemului. Acesta include explicit intrari,
procese, iesiri si feedback. Acesta este locul în care reprezentarea proceselor este utila în legarea
scopurilor organizatiei de scopurile proceselor.
Primul pas în MP este de a identifica toate domeniile de responsabilitate sau departamentele cu
impact asupra procesului, acestea vor fi listate în partea stânga a axei. Fiecare dintre acestea vor fi
reprezentate printr-o banda orizontala. Pasul necesita ca pentru fiecare proces acestea sunt listate în
ordinea precedentei. Fiecare banda din diagrama indica responsabilitatea functionala pentru respectivul
pas. Diagrama faciliteaza identificarea disfunctiunilor din proces. Disfunctionalitatile sunt pasi
suplimentari, pasi lipsa sau pasi care nu adauga valoare. Exemplu în figura 2.3.

Figura 2.3.Maparea proceselor[Whi99]

Rummler si Brache pun problema legilor fundamentale ale sistemelor organice. Legile pertinente
pentru abordarea actuala sunt:
- Întelegerea performantelor necesita documentarea intrarilor, proceselor, iesirilor si a clientilor
care constituie procesul economic;
- Sistemele organizatiei se adapteaza sau dispar;
- La optimizarea unei componente a organizatiei, organizatia, de obicei este suboptimala
- Inserarea oricarui nivel în sistem va avea efecte în alte parti ale sistemului;
- O organizatie, de obicei, se comporta ca un sistem, ca urmare trebuie sa fie gestionata ca un
sistem

6
Arhitecturile întreprinderii, cadru si metodologie
O arhitectura este definita este definita ca: o multime organizata de elemente cu relatii clare cu altele, care
formeaza împreuna un tot unitar definit prin finalitatea sa (Vernadat 1996). O arhitectura difera de un
cadru general prin aceea ca un cadru este o supramultime a unei arhitecturi, cadrul este o asamblare de
elemente pentru un scop comun. Ca urmare cadrul este mai deschis decât o arhitectura.
Arhitecturi
CIMOSA Computer Integrated Manufacturing – Open Systems Architecture este un cadru de modelare.
Efortul CIMOSA este directionata pe modelarea orientata obiect a unei întreprinderi cu o privire asupra
enactment (Vliestra 1996). CIMOSA se adreseaza utilizatorilor economici. Aceasta arhitectura îsi
propune sa integreze toate trei aspectele întreprinderii: procese economice, aplicatii si sistemul fizic. O
privire generala asupra CIMOSA este data în figura 2.4

Figura 2.4. Cadrul arhitectural CIMOSA [Vliestra 1996]

Cubul prezentat reprezinta, grafic cele trei dimensiuni ale CIMOSA: generarea, instantierea si
derivarea. Generalitatea modelului este data de nivelul instantierii, care este o reflectare a nivelului de
detaliere inclus în model. Nivelele cele mai din stânga prezinta arhitecturile referite, iar cel de al treilea
arhitecturile particulare. Dimensiunea de derivare a modelului nu încearca sa dezvolte o abordare total
noua, cât mai degraba sa extinda abordarile existente. CIMOSA utilizeaza atât modelarea ca, cât si pentru,
utilizând o abordare “bottom up” asupra implementarilor existente si una “top dow n“ asupra
implementarii planificate. Abordarea lifecycle furnizeaza un mecanism pentru a lega utilizatorul atât cu
operatia de creare a modelului, cât si cu executia modelului astfel rezultat. Nivele modelului sunt definitii
de cerinte, specificatii de proiectare si descrieri ale implementarii modelului. Nivelul de generare descrie
cele patru puncte de vedere ale întreprinderii, fiind permisiva si altora. Cele patru puncte de vedere sunt:
functia, informatia, resursa si organizarea. Integrarea infrastructurii furnizeaza un mecanism pentru a
izola utilizatorul relativ la detaliile datelor si furnizeaza aceste informatii de o maniera consistenta. Exista
o extensie, numita SEW-OSA care furnizeaza un instrument CASE.
ARIS Architecture of Integrated Information Systems (Scheer1994) are ca obiectiv descrierea unui sistem
de informatii din toate punctele de vedere, de o maniera holistica. Acesta include toate fazele dezvoltarii:
definirea cerintelor, specificarea proiectarii, descrierea implementarii si patru puncte de vedere.
Principalele trei sunt functia, datele si organizarea. În functie de context (sistem informational sau al
proceselor economice) cel de al patrulea este fie de resurse, fie de control. ARIS are doua scopuri majore:
dezvoltarea unui model pentru procesele economice utilizând punctele de vedere anterioare si utilizarea
abordarii lifecycle descrisa anterior ca faze ale dezvoltarii. Fazele dezvoltarii si punctele de vedere
demonstreaza ca ARIS este structural similar cu CIMOSA. Diferenta dintre acestea rezida în faptul ca
CIMOSA se orienteaza mai mult asupra nivelului de vânzare (magazin), pe când ARIS se adreseaza cu
precadere mediului de birou. Arhitectura de baza ARIS se regaseste în figura 2-5.

7
 Figura 2.5. Arhitectura ARIS[Whi99]

PERA (Purdue Entreprise Reference Architecture (PERA)) Deoarece cele mai multe arhitecturi de
referinta sunt proiectate pentru proiectarea sistemelor CIM sau implementari la nivelul controlului, PERA
(Williams 1996) dezvolta modelarea componentei umane a unei întreprinderi similare cu componentele
de proces economic, proces si tehnologice. Arhitectura de baza descrie nivelele programului de dezvoltare
CIM ca: identificarea entitatii proceselor economice CIM, nivelul concept, nivelul definitie, nivelul
proiectare (care contine atât proiectarea functionala, cât si nivelul detaliat), nivelul constructie si instalare,
precum si nivelul operare. Astfel, este evident ca PERA este orientat pe întregul ciclu de viata al
întreprinderii. Nivelele, proiectare detaliata, instalare si operare, sunt separate în trei parti pentru a
distinge între aspectele informatie, umane si resurse (echipamente si servicii). PERA nu dezvolta
instrumente specifice de modelare, în schimb utilizeaza instrumentele existente pentru modelarea
diferitelor aspecte ale întreprinderii.
GERAM Generalized Entreprise Reference Architecture ans Methodology a fost dezvoltata de IFAC
(International Federation of Automatic Control). Misiunea grupului de lucru este tocmai alegerea
arhitecturii celei mai bune pentru întreprindere. GERAM construieste peste CIMOSA, GIM si PERA si
va fi un standard ISO: GERAM va furniza definitii comune ale termenilor, un mediu consistent de
modelare, o metodologie detaliata si face disponibila reutilizarea modelelor. Versiunea revizuita a
GERAM va combina CIMOSA si PERA pentru a include identificare întreprinderii si definirea fazelor si
va include, de asemenea si fazele de constructie si operare ale implementarii, GERAM va avea, de altfel
si urmatoarele componente:
- GERA (Generic Entreprise Reference Architecture)
- GEEM (Generic Entreprise Engineering Methodology)
- GEML (Generic Entreprise Modeling Tools)
- GEM (Generic Entreprise Models)
- GMs (Generic Entreprise Modules)
Cu toate ca GERAM este relativ noua în scena arhitecturilor întreprinderii, exista deja extensii ale
acesteia. Tinând cont de faptul ca GERAM este o arhitectura descriptiva, mai degraba decât prescriptiva,
Klingstam (Klingstam 1998) extinde fazele ciclului de viata al GERAM prin adaugarea activitatilor
pentru fiecare faza. Aceste activitati sunt numite: caracteristicile principale ale proiectului, pentru fiecare
dintre fazele ciclului de viata din GERAM.
Cadre
ISA (Information Systems Architecture) (Arhitectura sistemelor de informatii) ISA (Zachman 1987)
introduce un cadru care furnizeaza o taxonomie pentru implementarile lumii reale. Prima intentie a ISA se
refera la modul în care sunt relationate diferitele perspective. Aceasta se lega atât de paragrafele
anterioare (arhitecturile) cât si de cele care urmeaza (metodologii de modelare multinivel) Original ISA
are trei coloane care descriu:

8
 - entitatile implicate (date)
- functiunile realizate (functii)
- locatiile utilizate cu conectivele lor (retea)
Acestea vor raspunde la întrebarile curente: ce, cum si unde. Cele cinci linii vor descrie cele cinci
perspective:
- domeniul
- modelul întreprinderii
- modelul sistemului
- modelul tehnologiei
- componente
ISA a fost extinsa (Sowa, Zachman 1992) prin introducerea altor întrebari comune: cine, când, de ce.
- cine – furnizeaza informatiile întreprinderii
- când – furnizeaza planificarea informatiei
- de ce – furnizeaza strategia întreprinderii
Cadrul ISA se extinde la sase coloane (figura). A se nota ca fiecare celula contine tipul de descrieri
considerate uzual pentru celula particulara respectiva.
Metodologii de modelare multi-perspective
Sunt mai multe perspective ale unei întreprinderi date. Diferitele grupuri au necesitati diferite relativ la
modelele întreprinderii. Modelul însasi este o reprezentare care considera, în general, numai acele aspecte
care sunt considerate relevante. Daca de la un singur model se asteapta sa contina fiecare piesa numai
chiar pentru informatia necesara si pertinenta despre întreprindere, modelul va creste spre o stare
inutilizabila. În consecinta, în mod tipic, modelele sunt restrictionate la reprezentarea unei singure
perspective a întreprinderii. Aceasta promotioneaza întelegerea prin reducerea complexitatii din model.
Totusi, apar si facilitati disjuncte si o incompleta întelegere a întregii întreprinderi. Integrarea a acestor
perspective este vitala pentru reprezentarea completa a întreprinderii. Aceasta extensie descrie, în primul
rând, punctele de vedere diferite si apoi prezinta metodologiile si cadrele pentru integrarea perspectivelor.
Cercetarile anterioare definesc un numar de perspective. CIMOSA promoveaza patru perspective:
Functia, Informatia, Resursele si Organizarea. ISA descrie date (ce), functii (cum), retea (unde),
organizarea (cine), planificarea (când) si strategia (de ce) ca dimensiuni ce trebuie descrise. Curtis (Curtis,
Kellner 1992) defineste patru perspective: functional (care elemente ale proceselor trebuie realizate si ce
flux al entitatilor informatiei este relevant pentru elementele proces), comportament (când trebuie
realizate elem entele proceselor (secventierea)), organizational sau resurse (unde si de catre cine sunt
realizate procesele, mecanismele comunicatiilor fizice, mediul stocarilor si locatiile) si informational (ce
entitati de informatie se produce sau se gestioneaza de catre procese). Acestea includ date, produse si
obiecte. ARIS (Architecture of Integrated Information Systems) are de asemenea patru perspective.
Principalele trei sunt: datele, functiile si organizatia. În functie de context cel de al patrulea este de control
sau resursa. Activitatile anterioare de dezvoltare a arhitecturilor date de Automation & Robotics Research
Institute descriu o abordare cu cinci perspective:
- Regulile proceselor economice (sau informatia), perspectiva care defineste entitatile gestionate de
întreprindere, precum si a regulilor care guverneaza relatiile si interactiunile acestora;
- Activitate – perspectiva care defineste functiile realizate de întreprindere (ceea ce trebuie facut);
- Procesele economice – defineste secventierea temporala a proceselor (modul în care se face);
- Resursele – definesc resursele si capabilitatile gestionate de întreprindere;
- Organizatie – modul de organizare a întreprinderii care include multimea restrictiilor si regulile
care guverneaza modul în care aceasta se auto-gestioneaza si în care îsi gestioneaza procesele.
Asta nu înseamna ca toate aceste perspective vor fi prezente în toate modelele. Un model este o
reprezentare abstracta a realitatii care trebuie sa excluda detalii ale realitatii si care nu sunt de interes
pentru modelator sau pentru utilizatorul final al modelului. Modelele au fost dezvoltate pentru a da
raspunsuri la întrebarile majore si specifice ale întreprinderii. Cei mai multi dintre autori au întâmpinat
mari probleme în relationarea punctelor de vedere între ele, la care se adauga problema consistentei dintre
multiplele puncte de vedere.
HEMO (Holonic Modeling Ontology )
Presley (1997) îsi propune sa integreze aceste cinci puncte de vedere bazând toate punctele de vedere pe
perspectiva ontologica (IDEF5). Presley da un model IDEF0 care descrie metodologia. Modul în care
sunt integrate punctele de vedere prin IDEF5 este prezentata în figura 2.6.

9
 Figura 2.6. Metodologia de modelare a întreprinderii HEMO [Presley 1997]

Modelul IDEF5 serveste ca regula a proceselor economice. Relatiile necesare sunt preluate din
modelul IDEF5 si sunt utilizate pentru a specifica organizatia si resursele. Informatia activitatii din
modelul IDEF5 este utilizata pentru a genera o activitate IDEF0 si modele ale proceselor economice
IDEF3.
FIDO(Functions, Information, Dynamics, and Organization) Cadrul FIDO consta dintr-o serie de
instrumente de modelare. FIDO este bazata pe principii orientate obiect peste întreaga serie. FIDO îsi
bazeaza modelul pe un model functional IDEF0 extins si expandeaza astfel analiza si proiectarea orientata
obiect. Instrumentele sunt:
- FIDO0 – (FIDO Integrated Modeling Framework) - defineste cadrul general al metodologiei FIDO;
- FIDO1 (Extended IDEF0 modeling) este o extensie a modelului activitate IDEF0. Prima diferenta
dintre IDEF0 si FIDO1 este aceea ca timpul de procesare si proprietarii functiei (perspectiva
organizationala) este plasat explicit (si grafic) în dreptunghi. Aceasta perspectiva este baza pentru toate
celelalte perspective din metodologia FIDO, FIDO1 utilizând, tipic, descompunerea top-down pentru
construirea de modele si furnizeaza integrarea perspectivelor functionale si organizationale;
- FIDO2 (modelarea OO IDEF0) – acesta reprezinta perspectiva analizei informatiei întreprinderii.
FIDO2 utilizeaza o abordare orientata obiect si în consecinta face apel la clase de obiecte si mosteniri.
Acestea sunt îndeplinite prin definirea modelului informatiei OO ca un submodel al modelului FIDO1.
FIDO2 utilizeaza agregar ea bottom up pentru a crea modelul si integreaza perspectivele întreprinderii:
informational, organizational si functional;
- FIDO3 (specificatia IDEF0 a OO) – se refera la proiectarea perspectivei informationale a
întreprinderii. Specificatia defineste obiecte ICOM si mesajul de trecere, respectiv. FIDO3 utilizeaza
agregarea bottom up pentru crearea de model si serveste ca un depozit pentru modele;
- FIDO4 (modelarea dinamica IDEF0) este punctul de vedere dinamic al întreprinderii. FIDO4
mapeaza modelul FIDO1 pe un model de simulare SLAMII care este realizat prin adaugarea de timp,
cost, calitate, tipul resursei, tipul capacitatii, parametrii de arborescenta. Simularea FIDO4 poate fi
realizata la orice nivel al ierarhiei si integreaza perspectivele dinamice si functionale ale întreprinderii.
Efecte între perspective
Withman (Withman, Huff 1998) identifica patru efecte cheie în sinteza dintre perspective. Acestea sunt:
1. distanta dintre perspective
2. diferente dintre structura metodologiilor
3. banda artificiala (descompunerea versus agregare)
4. ambiguitatea modelului
Diferentele dintre perspective – un model a fost definit ca o reprezentare a realitatii. Sunt incluse
detaliile care sunt importante pentru ca modelul sa raspunda acestei realitati. Alte detalii nu sunt incluse.

10
În consecinta, anumite informatii care sunt pertinente într-o perspectiva pot sa nu aiba relevanta într-o
alta, ceea ce de fapt constituie si avantajul mai multor perspective. Figura 2.7 prezinta conceptual ceea ce
este semnificativ pentru acoperirea dintre perspectivele activitate, proces si organizatie.

Figura 2.7. Distantele dintre punctele de vedere

Cu toate acestea sunt portiuni semnificative ale fiecarei perspective care nu sunt descrise în
celelalte. Aceasta devine cheia atât pentru abordarea prin prisma unei perspective principale, cât si prin
prisma ghidarii perspectivelor.
Diferentele dintre structuri – structura diferitelor perspective nu trebuie în mod necesar sa conduca la o
mapare între acestea. De exemplu, perspectivele ac tivitate si proces, faciliteaza reprezentarea ierarhica, pe
când cea a datelor nu. O perspectiva activitate, de nivel înalt, poate contine “documente” ca elemente de
date, iar pe nivelul inferior sa contina “achizitie de ordine”. Perspectiva date trebuie sa contina numai
elementul “achizitie de ordine” cu datele aferente cerute de câmpurile form-ului. O tehnica de mapare
poate doar sa mapeze nivelul cel mai de jos al metodei ierarhice, dar aceasta abordare pierde avantajul
modelului ierarhic în reducerea complexitatii sistemului si cresterea inteligibilitatii acestuia.
Banda artificiala - Modelarea ierarhica furnizeaza un instrument firesc pentru inteligibilitatea
întreprinderii sau a sistemului. În mod tipic, modelele vor utiliza un principiu subordonat abstractizarii
denumit descompunere, care va “sparge“ fiecare activitate în mai multe, mai detaliate, de o maniera
continua pâna la atingerea nivelului inferior. De multe ori acesta introduce o banda artificiala în nivelele
intermediare ale ierarhiei. Acest fapt poate crea confuzii. Cea mai mare parte dintre cei care revizuiesc
modelul sunt familiarizati atât cu nivelele superioare cât si cu modelele inferioare ale sistemului. Exista
etichete obisnuite pentru aceste nivele care furnizeaza cadrul referintelor pentru acestia. În figura
anterioara nivelele A-0 si A0 vor utiliza termeni similari pentru activitatile identificate pe aceste nivele.
De asemenea, nivelul A23 va utiliza termeni familiari pentru nivelul inferior. Cu toate acestea, activitatile
nivelului intermediar, cum ar fi A2, poate sa nu fie recunoscut de cineva familiarizat cu sistemul. În
consecinta, pentru o descompunere “curata” a acestor activitati se va plasa o banda artificiala asupra
gruparilor pentru a agrega activitatile nivelului inferior pentru a se adapta activitatilor nivelului superior.
Cele mai multe dintre sisteme sunt bine definite la nivelele superioare si la cele inferioare, dar nu sunt
explicit definite la nivelele intermediare. Aceasta va putea confuziona, în practica, proiectantii sistemului
în fazele ulterioare ale ciclului de viata.
Ambiguitatile modelului – Informatia pertinenta într-o perspectiva, de obicei nu are aceeasi valoare
pentru o alta. Aceasta reducere a informatiei este utilizata, de obicei, pentru sporirea inteligibilitatii
sistemului. În contrapozitie, însa, aceasta va fi legata si de ambiguitatile modelului. Anumite concepte pot
fi reprezentate cu usurinta într-o perspectiva a modelului, dar, într-una complementara sunt necesare
informatii suplimentare pentru a elimina ambiguitatile. Pentru clarificarea acestui aspect, se va prezenta
urmatorul exemplu. În figura 2.8. este prezentata o activitate cu doua intrari. Aceasta este o reprezentare
corecta a procesului dar devine ambigua. Cele doua intrari reprezinta una dintre cele trei conditii: un
ansamblu, o adaptare sau o selectie. Un ansamblu semnifica ca cele doua intrari pot reprezenta doua
elemente necesare, împreuna, activitatii.
O adaptare semnifica o instanta specifica în care Input trebuie sa fie adaptat cu Input1 pentru ca
activitatea sa aiba loc. Un exemplu pentru acesta se poate referi la o masina si un program care lucreaza
pe aceasta.

11
Figura 2.8 Exemplu de ambiguitate

O selectie semnifica faptul ca numai una dintre cele doua intrari este necesara pentru ca
activitatea sa se produca. Un exemplu în acest sens îl reprezinta modelul IDEF0 din figura 2.9.

Figura 2.9. Diagrama IDEF0[Whi99]

Figura 2.10. Secventa de proces IDEF3[Whi99]

Modelul IDEF0 apare ca descriind exp licit ordinea activitatilor (metode IDEF0 însasi statueaza
ca nu defineste secvente temporale). Aceasta implica faptul ca, informatia despre angajare trebuie
preluata prima, apoi trebuie realizat aspectul fizic si la sfârsit se va determina beneficiul angajarii.
Aceasta nu este, de fapt intentia sistemului. Modelul IDEF3 prezentat în figura 2-19 va descrie secventa
partiala si acesta implica faptul ca ordinea ultimelor doua procese nu este importanta, ambele trebuind a fi
îndeplinite deodata. Prin utilizarea conectivei AND asincrone, intentia actuala a sistemului este, în fine
descrisa cu claritate.
Teoria generala a sistemelor
Teoria generala a sistemelor a fost dezvoltata de biologul Ludwig von Bertalanffy (Bertalanffy 1968).
Aceasta a fost o privire asupr a unui sistem mai mult decât simpla suma a partilor componente ale

12
acestuia. S -a dorit prezentarea unui sistem de legi care se aplica tuturor nivelelor sistemului, mai degraba
decât un set specific de legi pentru nivelul micro si un altul pentru nivelul macro. Teoria sistemelor este o
permanenta cautare pentru identificare partilor comune mai multor discipline, în scopul de a aplica
cunostintele unei discipline la alta. Abordarea sistem este în opozitie cu metodele analitice, în care
sistemul este spart în componente care simplifica analiza, Abordarea analitica este suplimentata de
abordarea sistemica si ambele pot fi utilizate pentru o analiza efectiva. Teoria sistemelor enuntata aici
sunt modele, principii si legitati care se aplica respectiv la un tip particular de sistem. Suboptimizarea este
definita ca optimizarea functiilor de pe nivelul inferior, fara o introspectie holistica sau a naturii globale a
organizatiei si fara a se tine cont de sinergiile potentiale care au fost create interactiune cooperativa a mai
multor functii. Abordarea sistemica este o metodologie de proiectare, un cadru conceptual comun, o
metoda stiintifica sau o teorie a organizatiei (Van Gigch 1991).
Teoria sistemelor living
În 1990 s-a dezvoltat 1 o 2extensie a teoriei generale a sis temelor denumita Teoria sistemelor living: teoria
generala a sistemelor este un set de definitii relationate, ipoteze si propozitii care, împreuna reprezinta
realitatea ca pe o ierarhie integrata a organizatiilor, a materiei si a energiei. Teoria generala a sistemelor
living este concentrata asupra unei submultimi speciale a sistemelor în general, cele care functioneaza. S-
au cautat principiile generale care vor fi aplicate tuturor cercetarilor asupra lucrurilor living. Aceste
principii fac nenecesare multe specializari si promoveaza aspectele comune dintre discipline. Pornind de
aici, a fost dezvoltata o teorie generala a sistemelor living prin clasificarea organismelor living. În primul
rând s-a cautat plasarea sistemelor living în nivele ierarhice si au fost propuse 3 douazeci de caracteristici
care sa sustina existenta. O descriere a naturii existentiale a acestor modele poate fi aplicata de la
organismele vii la întreprindere si la modelarea întreprinderii, în particular.
Un principiu interesant, preluat de la teoria sistemelor vii este acela care statueaza ca un sistem
stabil sub presiune se va deplasa în acea directie care tinde sa minimizeze respectiva presiune. Se constata
ca toate sistemele vii tind sa ajunga pe o stare stabila. Exista patru nivele ale modificarilor (primul este
intuitiv, celelalte trei sunt preluate direct din teoria sistemelor living).
- Nici o modificare : primul nivel al modificarii este simplu: fara modificare. În cele mai multe dintre
cazuri este usor sau mai eficient sa se paraseasca situatia neschimbata relativ la modificarea mediului.
Aceasta este adevarata pentru cele mai multe modele.
- Ajustari – urmatorul nivel al modificarii este ajustarea. Acesta este utilizarea caracteristicilor
existente pentru a raspunde la schimbari. În cele mai multe instrumente de modelare, astazi, nu exista
extensii catre instrumente disponibile care sa permita modificari semnificative ale modelului. Aceasta
poate fi legata, doar de modificari minore ale intrarilor si ale iesirilor activitatilor existente.
- Adaptarea – cel de al treilea pas al modificarilor este adaptarea. Aceasta se refera la dezvoltarea
de capabilitati pentru a face fata schimbarii. Aceasta poate fi legata de adaugarea si eliminarea de
activitati si date din diagrama astfel încât sa se produca schimbarea pozitiei lor relative.
- Evolutie – de obicei aceasta apare încet, de-a lungul unei lungi perioade de timp. Oricum,
utilizarea termenului se aplica numai la modificarile radicale si nu la schimbarile naturale provenite în
timp. Evolutia este schimbarea structurii genetice a modelului, acesta poate fi relationata cu restructurarea
proceselor economice prin schimbarea radicala a respectivului proces si respectiv a modelului acestuia.
Cât timp conditiile externe ramân într-o marja acceptata, adaptarea nu este necesara. Depasirea
respectivei marje, în lipsa adaptarii, conduce la esuarea organizatiei. Cauzele posibile ale presiunii din
sistemele living pot sa fie aplicate de asemenea si la modelele living. Lipsa intrarilor necesare, precum si
excesul de iesiri solicitate produc aceiasi problema a reducerii resurselor din sistem. Deci, sistemele
dezvolta un control de feedback pentru a monitoriza atât intrarile actuale cât si iesirile din sistem. Aceste
semnale de feedback au, ele însele, o anumit a probabilitate de eroare. Acestea vor diferi de la momentul
masurarii la momentul deciziei pentru o actiune si mai departe de momentul la care actiune în sine va
avea loc. Aceasta formula va determina un anumit grad de adaptabilitate a sistemului.
Aplicarea sistemelor living la modelarea întreprinderii
Exista mai multe aplicatii ale sistemelor living la modelarea întreprinderii. Câteva dintre cele mai
pertinente aspecte ale teoriei sistemelor living sunt enuntate mai jos:
- Echifinalitatea – este similara cu faptul ca modificarea apare în forme diverse, determinând astfel
mai multe cai diferite de a stabili conditiile finale ale functionalitatii. Aceasta este definita ca fiind

1
James Miller
2
Miller 1978
3
Miller 1978

13
echifinalitatea care semnifica ca o stare finala a unui sistem living poate fi atinsa din diferite conditii
initiale si în moduri diferite. Exista numeroase moduri de a modifica modelul unei întreprinderi. Pentru
aceasta trebuie sa existe o metoda formala pentru documentarea procesului de schimbare survenit în
modelul unei întreprinderi, daca modelul se preteaza la a fi întretinut si utilizat. Aceasta poate fi
îndeplinita în aceiasi maniera ca si modelele utilizate în prezent în inginerie.
- Comportament variabil – sistemele living afiseaza un comportament variabil care poate fi definit
ca un comportament suficient de nesistematic pentru a fi aproape impredictibil în detaliu. Cele mai multe
instrumente pentru modelarea întreprinderii asigura un anumit sablon pentru furnizarea modificarilor
modelului. Un model living al întreprinderii trebuie sa fie capabil sa raspunda la schimbari care nu au fost
anticipate. Cercetari asociate se refera la utilizarea teoriei complexitatii pentru a descrie complexitatea
unei întreprinderi si a unor modele asociate.
- Rata modificarilor - existenta unei întreprinderi se manifesta într-un mediu în care rata schimbarii
este permanent accelerata. Acele organizatii care au un timp de raspuns lent la modificarile mediului nu
vor supravietui. Cele mai multe modele de întreprindere nu furnizeaza capabilitati specifice legate de
usurinta modificarii modelului. Chiar si cele care dau un astfel de mecanism se refera numai la un raspuns
ajustativ care nu este întotdeauna adecvat. Se propune4 ca, daca un sistem dinamic este reprezentat
complet, atunci exista un algoritm care sa fie capabil de automodificare (adaptare) ca raspuns la
modificarile mediului. Specificatia modelului bazat pe paradigma statica s-a dovedit incompleta, trebuind
sa se ia în considerare toate calitatile dinamice ale sistemelor living. Cele mai multe paradigme de
modelare presupun un sistem relativ închis. Eforturile anterioare au fost caracterizate tocmai de
inabilitatea sistemului si a modelului de a se modifica pe sine ca raspuns la stimulii externi.
Sursele modelului living al întreprinderii
În modelarea sistemului, frontierele sistemului reprezinta cheia atât pentru timp, cât si pentru resursele
necesare pentru crearea modelului. Pe de alta parte, minimizarea domeniului efortului, cel mai probabil va
conduce la o solutie suboptimala în raport cu un sis tem mare al întreprinderii care depaseste frontierele
respective. Aceasta determina ca efortul sa fie suficient de mare pentru a avea impact asupra întreprinderii
si suficient de mic pentru a putea fi gestionabil si finalizabil într-o perioada temporala rezonabila. Sursele
modelelor living ale întreprinderii includ: Domeniul efortului, întretinerea si abilitatea de a raspunde al
deviatiile procesului.
Domeniul efortului. Problema se reduce al delimitarea frontierelor domeniului, ca mai sus.
Întretinerea. Schimbarea întreprinderii atrage dupa sine, natural, necesitatea schimbarii modelului
acesteia. Relevanta modelelor greu de întretinut va fi pierduta. Mai jos sunt enuntate principiile de baza
ale modificarii modelelor5:
- modelul nu mai poate fi utilizat daca schimbarile nu pot fi gestionabile;
- modelul nu este gestionabil daca metricile nu pot identifica ce anume s-a schimbat;
- modelul nu mai poate fi utilizat daca nu este sincronizat cu realitatea.
Se sugereaza de asemenea ca sunt utilizate modele pentru controlul actual pentru anumite metrici
în loc de analize si suport de decizie, fapt pentru care modelele întreprinderii vor continua sa fie de o
valoare limitata. Acesta este de fapt si factorul cheie pentru necesitatea modelelor living a întreprinderii.
Abilitatea de a raspunde al deviatiile procesului. Majoritatea timpului alocat dezvoltarii modelului este
concentrata pe fluxul din interiorul întreprinderii. Când un sistem expert este chestionat relativ la fluxul
procesului prin domeniul propriu de expertiza, acesta ia în considerare, aproape în exclusivitatea fluxul
tipic. La o chestionare în continuare acesta va descrie câteva (putine) scenarii semnificative. Cu o probare
cât mai amanuntita, sistemul poate descrie anomaliile de sistem. Toate aceste descrier i sunt vitale pentru
modelul living al întreprinderii, pentru ca acesta sa fie codat în operatii cotidiene. Expertii sistemelor care
urmeaza a fi modelate nu pot lua în considerare evolutiile viitore si sa-si imagineze toate circumstantele
posibile. Pentru ca modelul întreprinderii sa fie efectiv, acesta trebuie sa dispuna de abilitati care sa-i
permita modificari rapide si facile pentru a sustine evenimentele noi. Cel mai frecvent, modelul închis
trebuie evitat, deoarece va deveni mai putin relevant. Aceasta sursa este direct legata de anterioarele doua.
Aceasta sursa adreseaza, de asemenea topica reducerii gradului de variabilitate. Reducerea variabilitatii
este un efort foarte însemnat în procesul cresterii. Variabilitatea trebuie modelata si definita în modelul
living al întreprinderii.

4
Wood 1994
5
Petrie 1992

14
Necesitatea modelului living pentru întreprindere
Modelul living pentru întreprindere are cinci caracteristici principale:: utilizabilitatea, actualitatea,
credibilitatea, aplicabilitatea de a actiona ca un depozit si posibilitatea de a fi obiectul unui audit.
Modele uzuale
În mod tipic, modelul întreprinderii este utilizat ca un instrument pentru sustinerea deciziei. Asa cum deja
a fost mentionat, modelul este dezvoltat pentru a sustine decizia pentru o perioada finita de timp, dupa
care, de obicei modelul este abandonat. Din aceasta cauza reutilizarea modelului este una din prioritatile
cercetarilor. Daca modelul este considerat ca fiind una dintre partile vitale ale întreprinderii însasi, atunci
modelul va trebui sa se pastreze actual si relevant. Prin realizarea unui model care sa acopere atât
cerintele de fiecare zi, cât si pe acelea strategice, acesta va deveni viabil ca resursa importanta. Aceasta
este cheia schimbarii culturii, care percepe modelul unei întreprinderi ca un mijloc catre o finalitate decât
ca pe o finalitate în sine.
Actualitatea
Una dintre caracteristicile importante ale modelului întreprinderii este acela de reusi sa dea o buna
cunoastere (întelegere) a întreprinderii. Odata cu trecerea timpului si cu modificarile întreprinderii,
complicatiile existentiale ale acesteia vor creste daca modelul nu va respecta, cu acuratete, mediul actual
al întreprinderii. Mediile contemporane forteaza permanent schimbarea întreprinderii. Ceea ce este de
succes azi, poate fi perimat saptamâna viitoare. În concordanta cu Presley 6 “sunt necesare instrumente
pentru realizarea reengineeringului continuu al întreprinderii. În mod special, sunt necesare metode de
modelare care sa sustina schimbarea”.
Credibilitatea
Cele mai multe modele sunt utilizate pentru analize de tipul “what-if” aceasta este de altfel întrebarea
fundamentala a validitatii modelului. Credibilitatea unui model este direct legata de actualitatea acestuia.
În afara actualizarii modelului, mai sunt si alte avantaje relative la credibilitate. Daca modulele unui
model living al întreprinderii a fost compatibil “plug-and-play”, scenariul “what-if” va putea fi rulat cu un
simulator care primeste datele direct de la sistemul însusi si sa aibe datele de iesire pentru intrarea unui alt
modul al sistemului actual. Aceasta va furniza date valide si credibile pentru sustinerea deciziei.
Depozitul
Un model living al întreprinderii poate servi, de asemenea ca un depozit general pentru toate modelele
dezvoltate pentru întreprindere. Aceasta va putea furniza o singura BD pentru proces si cunostintele
despre întreprindere. Cu o ontologie adecvat dezvoltata, un model living al întreprinderii poate servi la
verificarea consistentei dintre diferitele componente sistem ale întreprind erii.
Audit
Daca modelul este utilizat pentru a sprijini procesul de elaborare a deciziei si modelul este abandonat,
efortul necesar pentru a audita atât modelul cât si decizia este maximizat. Este de preferat, în aceasta
viziune sa se realizeze o crestere continua a modelarii si a abilitatilor de elaborare a deciziilor. Modelul
living al unei întreprinderi amplifica semnificativ abilitatea de a observa relevanta modelului ca si
ipotezele modelului. Modelul poate necesita o explicitare în anumite domenii pentru a asigura ca
facilitatile modelului sunt cele cerute elaborarii deciziei. Acesta este direct legata de faptul ca elaboratorii
deciziei înteleg (cunosc) în totalitate ipotezele inerente ale modelului.
Câmpul de studiu pentru modelele întreprinderii
Modelarea întreprinderii
Modelul este o reprezentare abstracta a realitatii. Modelatorul determina aspectele sistemelor
reale care sunt de interes, precum si a modului în care elementele sistemului urmeaza a fi modelate.
Modelul întreprinderii este definit ca: ”o reprezentare simbolica a întreprinderii si a lucrurilor care sunt
7
legate de aceasta” . Aceasta definire detaliaza tipurile de entitati care sunt de interes pentru modelator.
Utilizarea simbolurilor pentru a reprezenta întreprinderea va trebui sa prezinte aceste fapte, obiecte si
relatii de o maniera usor de înteles.
Cunoasterea întreprinderii este critica pentru orice efort de crestere. Modelarea este o abordare
necesara pentru furnizarea acestei cunoasteri si a modului în care aceasta îsi poate atinge conditiile
viitoare. Modelele sunt uzuale pentru:
- furnizarea unei orientari a logosului relativ la întreprindere
- furnizarea unei modalitati de comunicare (interioara si exterioara) a întreprinderii
- furnizeaza baza pentru analiza si proiectare a noilor procese

6
Presley 1997
7
Presley 1997

15
 - actioneaza ca un fundament pentru cresterea continua a proceselor existente
- faciliteaza controlul proceselor din lumea reala 8
Modelarea întreprinderii face posibila cunoasterea tuturor aspectelor pertinente, descrierea clara a
problemelor economice si a cerintelor acestora, identificarea diferitelor alternative de proiectare si a
mecanismelor pentru analiza acestor optiuni pentru implementarea proiectului la nivelul strategic, tactic si
operational9.
Petrie 10, descrie importanta modelarii întreprin derii ca furnizoare a cunostintelor relative la
întreprindere si a interactiunilor care pot fi utilizate si rationalizate pentru intensificarea acestor
interactiuni.
Modelarea întreprinderii a fost utilizata pentru a construi modele ale organizatiilor av ând ca scop
declarat predictia si estimarea impactului schimbarii din interiorul organizatiei datorat modificarilor
mediului. Puterea unui model se manifesta prin abilitatea acestuia de a simplifica sistemul lumii reale pe
care îl reprezinta si de a predictiona anumiti factori ai acestuia 11.
Un model este creat, tipic, în momentul în care compania îsi propune implementarea unui
echipament foarte costisitor sau planifica schimbarea radicala a procesului. Modelarea unei întreprinderi
este instrumentul fundam ental pentru cunoasterea, proiectarea si analiza întreprinderii. Dezvoltarea
modelelor întreprinderii necesita cantitati mari de resurse. În mod obisnuit, odata cu modelarea mediului
si completarea analizei modelul nu mai este actualizat sau utilizat într-un proces de elaborare a deciziei.
Punerea în sertar a modelului atrage dupa sine perimarea acestuia devenind astfel de neutilizat. Daca doar
o perspectiva limitata a modelului întreprinderii va fi actualizata, va fi dificila justificarea cererii acesteia
fara a mai mentiona costurile cu actualizarea. Aceasta se întâmpla cu modelele create de o maniera
“miopica”, care se datoreaza unui concept limitat asupra modelului. Perspectiva limitata rezultanta este ca
modelul devine doar un mijloc pentru o finalitate, mai degraba decât producerea din partea modelului
însasi de valoare pentru întreprindere. De altfel, modelul trebuie sa nu devina o finalitate în sine însusi,
deoarece modelele întreprinderii sunt considerate instrumente fundamentale pentru operatiile zilnice ale
întreprinderii, acestea trebuind sa fie privite ca “bunuri” ale acesteia. Utilizarea modelelor întreprinderii
atât pentru planificarea pe termen lung cât si pentru operativ extinde, de obicei, existenta modelelor
curente. Extensia unui model va permite o solutie mai holistica pentru analiza sistemului care va fi
utilizata ca un instrument în ingineria întreprinderii prin furnizarea domeniului larg al reprezentarii.
Aceasta este regasita mai degraba în cercetarile cu caracter teoretic decât în practica, chiar si acestea
relevând cazuri de studiu limitate.
Studiul constructiei si al infrastructurii
Obiectivele studiului au fost extinse asupra Ingineriei întreprinderii si a modelarii întreprinderii. În mod
special, acest studiu a fost determinat de modul în care întreprinderea îsi utilizeaza modelele. Studiul
constructiei datorate domeniului nou al modelarii întreprinderii, nu dispune, deocamdata de instrumente
de studiu proprii , disponibile. Au fost consultate mai multe surse pentru dezvoltarea întrebarilor legate
de studiu. Cercetarile în domeniul CAD/CAM în finele anilor saptezeci au avut acelasi nivel de maturitate
ca si modelarea întreprinderii la finele anilor nouazeci.
Producerea modelului de referinta al întreprinderii
În mediul competitional de astazi, abilitatea de a tranzit la o întreprindere sporita este un discriminator
critic pentru actorii unei piete date. Performantele superioare ale întreprinderii extinse sunt centrate pe
realizarea productiei celui de al 21-lea secol. Acest pas pentru orice sporire de efort este de a obtine o
cunoastere completa, comuna si corecta a întreprinderii. Modelele întreprinderii sunt utilizate pentru a
obtine aceasta cunoastere.
Modelele întreprinderii
O cunoastere comuna a întreprinderii este critica pentru orice efort de crestere. Modelarea este o abordare
pentru a furniza aceasta cunoastere comuna, precum si a modului în care se pot obtine conditiile viitoare.
Modelele sunt utilizate de obicei pentru:
- furnizarea unei orientari a logosului relativ la întreprindere
- furnizarea mijlocului de comunicare în întreprindere si în general al întreprinderii
- furnizeaza baza pentru analiza si proiectarea noilor procese
- actioneaza ca element de baza pentru crestere continua a procesului

8
Huckvale, Ould 1995
9
Frasier 1994
10
Petrie 1992
11
Wood 1994

16
 - faciliteaza controlul proceselor din universul real
În concordanta cu Frasier, modelarea întreprinderii valideaza cunoasterea comuna a tuturor
aspectelor pertinente, descrierea clara a cerintelor si problemelor proceselor economice, identificarea
alternativelor de proiectare si a mecanismelor pentru analiza acestor optiuni pentru implementare, la nivel
strategic si operational. Petrie descrie importanta modelarii întreprinderii ca furnizoare de cunoastere
comuna si a interactiunilor care pot astfel fi utilizate pentru optimizarea si crester ea acestor relatii.
Necesitatea modelelor întreprinderii
Modelarea întreprinderii a fost utilizata pentru a construi modele ale organizatiei având ca scop
previzionarea si estimarea impactului pe care îl are schimbarea în interiorul organizatiei produs de
schimbarea care apare în mediul extern. Puterea modelului provine din abilitatea de a simplifica sistemul
universului real pe care îl reprezinta si de a previziona anumiti factori relativ la sistem prin virtutea
corespondentelor din respectivul model12. Sunt prezentate în continuare utilizarile uzuale ale modelelor
întreprinderii (EM):
- Facilitarea comunicatiei si cunoasterii umane. Acestea sunt realizate prin identificarea: semnificatiei
lucrurilor, a ceea ce trebuie realizat, a modului în care lucrurile sunt realizate, a personalului care
realizeaza aceste lucruri, care anume dintre acestea sunt masurate si a costurilor asociate cu acestea.
Acestea sunt în general referite ca unificarea semantica13;
- Sustinerea managementului si a cresterii procesului. Aceasta este realizata prin furnizarea unui
mecanism pentru cunoastere si analiza a procesului;
- Furnizarea ghidarii procesului. Se obtine prin furnizarea unui mecanism de asistare a resursei umane
în extensia actuala a procesului;
- Facilitarea banchmarking-ului: Banchmarking-ul necesita o cunoastere comuna si o documentare;
- Automatizarea executiei, realizata prin furnizarea unui mecanism de executie a proceselor;
- Validarea ingineriei întreprinderii. Aceste modele sunt actualmente un mijloc pentru validarea
comunicatiei într-un context al ingineriei întreprinderii. În lipsa unui model este dificil de a realiza orice
forma a ingineriei.
- Facilitarea controlului asupra proceselor din universul real.
În acord cu Frasier modelarea întreprinderii valideaza:
- analizele pentru implementarea proiectarii al nivelele strategic, tactic si operativ;
- sustine decizia prin accesul la informatia necesara simularea alternativelor si implementare în timp
real a deciziilor;
- o latura competitiva – compania care a un model al întreprinderii va fi capabila sa reactioneze mai
rapid decât competitorii sai si sa câstige avantaj în competitivitate prin studierea comportamentului
organizatiei bazat pe schimbarile survenite în mediu.
Johnson 14 sugereaza ca transformarile întreprinderii pot fi reprezentate ca o serie de instantieri
care descriu starile proceselor întreprinderii pe parcursul diferitelor stadii de crestere. Aceste instantieri
sau sabloane descriu operatiile proceselor, resursele, relatiile, capabilitatile, etc., si include banchmark-
urile relevante ale procesului, precum si metricile acestuia. Proiectarea întreprinderii sau metodologia de
transformare este prezentata în figura 2.11. prin sensul sagetii. O perspectiva generala si trei seturi de
strategii vor sustine transformarea. Modelele întreprinderii vor facilita procesul de tranzitie prin
furnizarea de perspective consistente si comune ale întreprinderii.

Figura 2.11.
Proiectarea întreprinderii
[Whi99]

12
WOOD 1994
13
Vernadat 1996
14
Johnson and Meade

17
Cele trei categorii de procese
Presley 15 propune separarea proceselor economice în trei categorii:
- acele procese care transforma restrictiile externe în restrictii interne (stabilirea directiei)
- acele procese care achizitioneaza si pun la dispozitie resursele solicitate (achizitia de resurse)
- acele procese care utilizeaza resursele pentru a produce rezultatele întreprinderii (transforma)
Figura 2.12. prezinta activitatile (boxe) aranjate în procesele economice (elipse). Procesele
economice sunt organizate în întreprindere reprezentata de o boxa mare.

Figura 2.12.
Categoriile de procese[Whi99]

La acest nivel înalt de abstractizare, întreprinderea însati este reprezentata ca o activitate care
preia intrari, pe care le transforma în iesiri utilizând resursele disponibile sub limitarea unei multimi de
restrictii. Cu toate aceste frontiere (manifestate printr-o linie tare) natura deschisa a întreprinderii poate fi
reprezentata prin linii întrerupte. Este important ca la modelare sa se defineasca aceste frontiere si sa se
identifice acele detalii care sunt sub control.
În mod frecvent, numai activitatile sau procesele considerate în activitatile de crestere si de
modelare sunt cele din categoria 3, care transforma intrarile în activitati si servicii. Cu toate acestea este
important sa se considere activitatile strategic e si de achizitie dintr-o întreprindere. Cunoasterea diferitelor
categorii de procese este vitala pentru dezvoltarea unei reprezentari utilizabile.
Ingineria întreprinderii / Integrarea / BPR
Liles 16 defineste o întreprindere ca “o multime complexa de procese economice care pot fi proiectate
pentru a îndeplini un set specific de obiective”. Vernadat17 defineste, la rândul sau întreprinderea ca fiind
constituita dintr-o “multime de procese economice concurente executate de un set de entitati functionale
(sau resurse) care contribuie la procesele economice”. În contextul modelarii întreprinderii termenul de
întreprindere este utilizat pentru a desemna, în mod specific, acea parte a companiei care este de interes,
domeniul fiind determinat de utilizatorul final al modelului.
Ingineria întreprinderii este definita ca acel corp de cunostinte, principii si practici care trebuie
realizate cu analiza, implementarea si operatia unei întreprinderi. Principiile si practicile ingineriei
întreprinderii sunt : teoria, abstractizarea, proiectarea si implementarea. Un alt termen utilizat pentru
abstractizare este modelarea. Modelarea furnizeaza un mecanism pentru a valida o cunoastere comuna,
precum si posibilitatea testarii ipotezelor. Perspectiva ingineriei întreprinderii priveste întreprinderea ca
un sistem complex de procese care pot fi puse în opera pentru a îndeplini obiectivele organizationale
18
specifice . Ingineria întreprinderii trebuie sa recunoasca natura organica a fiecarei schimbari a
întreprinderii19. Ingineria întreprinderii preia o abordare holistica a întreprinderii care este în opozitie cu
cele mai multe abordari limitative ale proiectarii componentelor întreprinderii care îsi propun
considerente de integrare numai post-implementare, ceea ce va conduce, natural la solutii sub-optimale.
Petrie 20statueaza ca: “integrarea întreprinderii se distinge prin concentrarea acesteia spre a creste
coordonarea interactiunile individuale, organizationale si de sisteme. Integrarea întreprinderii a fost
orientata initial pe integrarea în interiorul întreprinderii, apoi pe integrarea între întreprinderi este înca o
preocupare importanta în domeniu. Mai mult eforturile EI sunt partial îndeplinite, prin modelarea
întreprinderii pentru a sprijini identificarea componentelor care vor participa la integrare.
15
Presley, Huff 1993
16
Liles and Jonson et al. 1996
17
Vernadat 1996
18
Liles and Jonson et al. 1996
19
Johnson and Whitman 1998
20
Petrie 1992

18
 Re-ingineria proceselor economice (BPR) este caracterizata de Hammer si Champy 21 ca “o
multime de proceduri necesare pentru a efectua schimbari radicale” Cresterea continua este privita ca un
proces care se suprapune peste actualele procese economice pentru a le face pe acestea sa fie mai bune,
mai ieftine si mai rapide. CI apare în acest sens ca fiind în contrast BPR relativ la modul în care se
realizeaza cresterea. La modul ideal se va produce o schimbare radicala a procesului economic printr-o
abordare BPR, urmata de o crestere incrementala, dupa ce întreprinderea a depasit procesul de re-
inginerie. Modelul întreprinderii este vital atât pentru BPR, cât si pentru cresterea incrementala.
Modelele de referinta ale întreprinderii
Se iau în considerare trei tipuri de modele: partial, de referinta si particular. Un model partial va da la
iesire detalii cheie care sunt populate la nivelele joase specifice pentru aspectele care trebuie modelate.
Un model de referinta este un model partial care furnizeaza o baza pentru dezvoltarea unui model mai
detaliat sau particular care reprezinta o instanta specifica a unei întreprinderi22.
Valoarea modelelor de referinta ale întreprinderii
Modelele de referinta ale întreprinderii aduc mai multe avantaje întreprinderii. Modelele întreprinderii
sunt folosite, în mod uzual pentru a furniza o referinta pentru diferite întreprinderi ale aceluiasi sector.
Similar, o reducere semnificativa de timp pentru crearea modelului întreprinderii poate fi obtinut cu
modelele de referinta, ca puncte de pornire. Mai multe întreprinderi care utilizeaza acelasi model de
referinta, ca model de start vor avea ca rezultat o crestere a calitatii, consistentei si a interschimbarii
modelelor întreprinderii. Aceasta faciliteaza atât comunicarea dintre întreprinderi cât si interconectarea,
fiind un rezultat direct al modelelor întreprinderii. Proiectele, programele, planurile individuale ale
întreprinderii, ca si configuratiile întreprinderii extinse pot fi evaluate pe baza modelului de referinta.
Acesta va servi, de asemenea, ca baza pentru compararea domeniului global (atât în orizontal cât si
vertical) a modelelor individuale si o serie de modele ale întreprinderii pentru a extinde pertinenta
modelelor în întreprindere.
Modelele de referinta furnizeaza o viziune grafica, clara si concisa a operatiilor productiei curente
a întreprinderii. Cu modelul rezultat, un observator cauzal poate studia operatiile întreprinderii incluzând
activitatile implicate cât si practicile curente din întreprindere. Prin realizarea unui model de referinta al
întreprinderii care preia intrari de la mai multe modele, modelul rezultat poate fi aplicat la mai multe
sectoare, pe nivele dimensionale ale productiei.
Trecerea în revista a modelelor de referinta
Exisa mai multe nivele de referinta pentru întreprinderi de productie, disponibile, în mod curent. Unul
dintre acestea este OSME23, care a fost initial dezvoltat pentru a trece în revista rezultatele deja obtinute.
Acest model a fost dezvoltat prin metoda IDEF0. Exista mai multe metode IDEF. Fiecare metoda este
utilizata pentru a descrie o anumita perspectiva a întreprinderii. Cele doua metode IDEF utilizate de
ARRI pentru modele de referinta cât si pentru modele particulare au fost IDEF0 (modelarea activitatii sau
functionala) si IDEF3 (captarea descrierilor proceselor). În figura2.13. sunt prezentate cele cinci elemente
ale modelului functional IDEF0. Activitatea (sau functia) este reprezentata prin boxe; intrarile sunt
reprezentate prin sageti în partea stânga a boxei, iesirile prin sageti, în partea dreapta a boxei; sagetile din
latura superioara a boxei vor reprezenta restrictiile sau controlul activitatii si în final sagetile din baza
boxei vor reprezenta mecanismele de realizare a activitatii.

Figura 2.13 Nomenclatorul IDEF0

Cel de al doilea model dezvoltat oarecum în acelasi timp a fost Modelul consensului de procese.
Acest model a fost dezvoltat în IDEF3, care a fost utilizat deoarece acest proces abordeaza mai degraba
procesul decât activitatea, perspectiva aceasta asupra întreprinderii luând în considerare si secventele
temporale ale evenimentelor.

21
Hammer and Champy 1993
22
Vernadat 1996
23
Operate a Small Manufacturing Enterprise

19
 Exista trei modele de referinta disponibile în mod obisnuit. SIME 24 (dezvoltat de ARRI), NCMS25
(dezvoltat de Wizdom Systems), SIMA26 (dezvoltat de NIST), în 1996. Mai exista si alte modele de
referinta ale întreprinderii dar cele mai multe dintre acestea se refera la domenii limitate. Cele trei modele
de referinta ale productiei adreseaza numai aspectele partiale ale categoriilor de procese mentionate
anterior.
Modelul de referinta SIMeE a fost utilizat si testat pentru mai multe întreprinderi mici. Cei mai
multi termeni utilizati sunt specifici întreprinderilor mici. Acest model a fost generalizat pentru a fi
aplicat unor scopuri mai largi ale întreprinderii, pentru a include întreprinderea extinsa. Cunostintele
câstigate în dezvoltarea modelului întreprinderii pentru campanii aerospatiale, mari a fost integrat în
modelul enuntat mia jos. Suplimentar, au fost date detalii cu privire la activitatea “Direct Eneterprise”.
Pentru o mai buna întelegere au fost modificate unele terminologii.
Modelul NCMS da mai multe detalii relevante pentru întreprinderea bazata de guvernare sau
pentru acelea care au entitati guvernamentale ca si consumatori principali. Aceasta este legata de
activitatile specifice enuntate, care au aparut, în primul rând în mediul guvernamental. Multe dintre aceste
activitati nu sunt fondate pe nivelul inferior al modelului. Modelul NCMS difera de modelul de referinta
combinat, propus, al întreprinderii prin plasarea activitatii de “Providing Resources” în activitatea de
nivel înalt “Manage Enterprise”. Modelul propus prezinta aceasta activitate pe nivelul A0. Achizitia si
pregatirea resurselor este o sarcina integrata pentru toate celelalte activitati din întreprinderea de
productie. Referitor la observatiile anterioare legate de categoriile de procese, procesele care
achizitioneaza si fac disponibile resursele solicitate sunt privite ca fiind o categorie separata, deoarece
acestea valideaza alte activitati ale întreprinderii.
Modelul de activitati SIMA nu îsi propune sa modeleze toate directiile: managementul valorilor
sau achizitia de clienti/comenzi a întreprinderii. Aceasta reprezinta, în detaliu, o informatie utila pentru
planificarea proceselor. Aceasta informatie este pe nivelul inferior de detaliu.
Prin combinarea cunostintelor, obtinute de la anterioarele patru modele, s-a dezvoltat modelul de
referinta combinat.
Aspecte generale relative la Modelul de referinta combinat
ARRI a revizuit modelul de referinta pentru operare a unei întreprinderi de productie. Figura 2.14 prezinta
diagrama A-0, care este diagrama nivelului de vârf si care defineste scopul si perspectiva si traseaza
frontierele modelului. Scopul acestui model este de a furniza un punct de referinta comun pentru
întelegerea si comunicarea dintr-o întreprindere. Punctul de vedere acceptat este acela al ingineriei
întreprinderii. Ingineria întreprinderii, proiecteaza întreprinderea si ca urmarea trebuie înteleasa întreaga
întreprindere, altfel modelul va fi unul suboptimal. Ingineria întreprinderii, trebuie sa aiba, de asemenea o
privirea asupra detaliilor activitatilor si proceselor întreprinderii, prin aceasta necesitând necesitatea
abordarii globale a întregii întreprinderi. Frontierele definesc mediul si ajuta la determinarea aspectelor
relevante a universului real care este inclus în acest model.

Figura 2.14. Perspectiva pe nivel înalt a întreprinderii [Whi99]

24
Operate a Small Integrated Manufacturing Enterprise
25
National Center for Manufacturing Science
26
System Integration of Manufacturing Applications

20
 Personalul face întreprinderea operationala. Acesta este realizata prin comunicatiile consumator
& furnizor, profit, informatia sector & consumator si elementele necesare. Personalul întreprinderii pune
în opera întreprinderea printr-un proces care este guvernat de mediu si resurse, furnizeaza informatiile de
performanta, costurile cu stocarile, mai multe informatii consumator & furnizor si un produs.
Punerea în opera a întreprinderii este realizata prin crearea unei culturi necesare integrarii si
cresterii proceselor si a implementarii de tehnologii pertinente de o maniera optimala, în concordanta cu
implementarea unui plan strategic. Prin optimal se va considera observatia lui Taha27: optimal înseamna
cel mai bun, relativ numai la modelul respectiv. În aceste conditii, solutia optimala semnifica cea mai
buna solutie pentru parametrii de intrare dati.
Diagrama de nivel înalt data în 2.14. este descompusa în nivele succesive de detaliu. Figura 2.15.
prezinta cele sase activitati de baza ale întreprinderii. Cele sase sunt:
- Direct Enterprise (directionarea întreprinderii)
- Aquire and Develop Assets (cerinta si dezvoltarea de valori)
- Aquire Customers and Orders (clienti si comenzi)
- Design Product and Processes (proiectarea produsului si a proceselor)
- Fill Orders (acoperirea comenzilor)
- Support Product (sustinerea produsului)

Figura 2.15. Cele sase activitati de baza ale întreprinderii [Whi99]

[A1] Directionarea întreprinderii – în cadrul acestei functii este conceputa strategia pe termen lung si
de nivel înalt. Planurile întreprinderii sunt o directiva globala a întreprinderii pentru dezvoltarea
planurilor la nivel tactic, politici si proceduri. Planurile întreprinderii specifica rolul organizatiei cu
respectarea conditiilor de mediu si a culturii organizationale. Acestea explica, de asemenea, natura
strategiei competitive a corporatiei si indica piata care trebuie deservita. Acestea include planuri care
indica bordului de conducere metodologiile curente, cum ar fi TQM, JIT, WCM, precum si planuri care
servesc la ghidarea pentru achizit ia si utilizarea resurselor. Planificarea strategica este orientata pe
definirea, în linii generale, a scopurilor pe termen lung a întreprinderii, a translatarii acestora în obiective
masurabile si determinarea strategiei prin care aceste obiective pot fi atinse. Planificarea are o natura
ierarhica. Anumite nivele ale planificarii sunt parte integranta ale tuturor proceselor din acest model. La
acest nivel superior planurile si obiectivele dezvoltate din directionarea întreprinderii conduc la
planificarea activitatilor realizate de toate celelalte procese. Obiectivele si scopurile strategice ale
întreprinderii sunt preluate, prin translatare si dezvoltare din scopurile corporatiei. Factorii mediului
extern, precum si factorii organizationali sunt definiti si se va realiza o analiza a competitivitatii pentru a
putea valida planuri care vor directiona în viitor întreprinderea. Aceasta activitate (directionarea
întreprinderii) este responsabila cu documentarea si desfasurarea acestor planuri pentru celelalte activitati.

27
Taha 1982

21
Aceste activitati vor fi monitorizate si masurate pentru asigurarea unui progres satisfacator. Se vor face si
actiuni corective, daca este cazul. Dezvoltarea si implementarea proceselor, la nivelul întreprinderii sunt
incluse în acest proces.
Factorii externi si interni contin procesul. Factorii externi include mediul în care întreprinderea
evolueaza, disponibilitatea de resurse si interesele corporatiei. Mediul, la rândul sau este compus din
factori de tipul: politici, de piata, reglementari ale mediului si cerintele si asteptarile consumatorilor.
Factorii interni, care se reflecta ca feed-back de la alte procese, contin, de asemenea, acest proces. Acesti
factori includ informatii relative la valori, piata si consumator, ca parte a procesului de ac hizitie a
consumatorului, starea si capabilitatile proiectului si starea operationala.
[A2] Achizitia si dezvoltarea de valori – Personalul întreprinderii achizitioneaza si produce noi valori
utilizând baza valorica existenta a întreprinderii. Acesta va realiza aceasta crestere prin comunicatiile
consumator & furnizor, venituri, valori & capital si prin examinarea cererilor de si a starii valorilor
existente. Transformarea spre valori utilizabile este guvernata de planul & performanta întreprinderii, care
da informatii relative la valoare, profit etc.
Aceasta functie este legata de gestiunea valorilor incluzând capital, personal, informatii si
facilitati. Acesta un nivel tactic al activitatii în care obiectivele nivelului strategic privind resursele sunt
translatate în planuri tactice, care definesc contributiile fiecarui domeniu operational pentru realizarea
planului strategic. Procedurile statueaza modul în care obiectivele vor fi îndeplinite la nivelul operational.
Activitatile includ producerea documentelor financiare si formele personalizate care relationeaza
informatia cu agentiile externe, precum si dezvoltarea de bugete departamentale care sunt de uz intern.
Problemele legate de personal, facilitati si securitate sunt luate, de asemenea, în considerare. Se va
produce si un plan agregat care are sarcina de a mentine echilibrul cerere/livrare de o maniera realista si
profitabila. Aceasta functie necesita intrari din piata (preluare de clienti/comenzi) cu privire la comenzile
actuale, comenzi previzionate si conditii de piata. Necesita, de asemenea, informatii relative la productie
(acoperirea comenzilor) cu privire la starea capacitatii, starea stocurilor, precum si a indicatorilor de
productie si vânzare.
Capitalul, facilitatile si personalul sunt valori care necesita un management proactiv. Obiectivele
nivelului strategic cu privire la achizitia si alocarea acestor valori trebuie sa fie translatata în planuri
tactice care definesc modul în care obiectivele strategice vor fi îndeplinite. Aceste planuri vor fi, la rândul
lor utilizate pentru dezvoltarea de politici si proceduri pentru a referi activitatile specifice. Aceste politici
si proceduri vor defini modul în care angajatii vor conduce activitati din sfera întreprinderii. Trebuie sa se
tina cont de faptul ca aceasta informatie este considerata resursa care trebuie sa fie, la rândul ei, controlata
si gestionata. Sistemul de informatii utilizat de întreprindere trebuie sa realizeze inerent, aceste functii,
dar sistemul însasi necesita o gestiune facuta de personal calificat în cunoasterea conceptului de integrare
a întreprinderii si, daca este necesar, sa fie capabil sa utilizeze tehnologii comunicationale avansate,
adaptate acestor activitati.
Valorile necesare pentru functionarea sanatoasa a întreprinder ii sunt achizitionate, dezvoltate,
gestionate si disponibilizate de catre acest proces. Categoriile de valori includ: facilitati, echipamente,
instrumentele de productie, personal, proprietate intelectuala si valori financiare. (Inventarierea productiei
în derulare este gestionata de procesul “Fill Orders”). Capabilitatile furnizor/partener sunt gestionate, de
asemenea. Obiectivele strategice si operationale care provin din activitatea A1 actioneaza ca un
declansator si controleaza acest proces. Informatiile relative la disponibilitatea valorilor si a capacitatilor
sunt întoarse spre A1 pentru a sustine planificarea. Cererile de valori, generate, de obicei, de alte procese
sunt convertite în valori productive necesare de catre acest proces. Aceasta iesire es te, deci, utilizata ca un
mecanism de alte procese. Alte intrari include capitalul si profitul din veniturile realizate din vânzari.
Acestea sunt convertite în resurse sau dividende.
[A3] Preluare clienti/comenzi – aceasta face o legatura dinamica, externa între întreprindere, clientii
acesteia si mediu. Ca urmare a analizelor aceasta functie este responsabila cu decriptarea starii actuale a
competitivitatii din piata ca si cu determinarea necesitatilor consumatorilor relativ la calitate, fiabilitate,
întretinere, estetica si de informatii. Informatia procesata pe durata analizei serveste de baza pentru
dezvoltarea previziunii economice, planurilor strategice, planurilor tactice si problemelor legate de
reclama. Venitul este consolidat prin satisfactia consumatorului materializata în solicitarile de servicii
relative la produs dupa ce acesta a fost vândut.
Pentru o întreprindere sa poata ramâna competitiva, domeniul curent trebuie sa fie interpretat si
translatat pentru a proiecta si produce pe baze de timp real. Cerintele ulterioare vor fi vor fi cu acuratete
previzionate si va fi evaluata starea de competitivitatea a pietii. Toate aceste informatii joaca un rol

22
special în procesul de planificarea strategica similar cu procesul actual de absorbtie a produsului de catre
piata în conditii de competitivitate.
Acest proces este responsabil pentru identificarea si dezvoltarea oportunitatilor pietii, cu
dezvoltarea scopuri si oferte, de primire a comenzilor si stabilirea si întretinerea relatiilor cu
consumatorii. Acest proces interactioneaza tare cu celelalte procese. Ghidarea pentru definirea
momentului si locului de realizare a unui proces economic este extras din planurile si politicile care
actioneaza ca si control din partea lui A1. Procesul da o iesire a necesitatilor consumatorului si a
asteptarilor acestuia, precum si a informatiilor relative la oportunitatile care sunt utilizate pentru
pregatirea planului în procesul A1. Informatiile cu privire la proiecte si starea operatiilor controleaza, de
asemenea procesul. Propuneri/oferte sunt iesiri catre consumatori potentiali. Comenzile generate ca
rezultat al acestei activitati sunt intrari ale acestui proces sau sunt contracte de la consumatori.
[A4] Proiectarea produsului/procesului – Produsele sunt proiectate dupa ce sunt definite cerintele
produsului. Procesul de definire a cerintelor utilizeaza mai multe studii pentru a determina un set optim de
cerinte. Procesele necesare sa fabrice si sa sustina produsul trebuie sa fie referite pe parcursul proiectarii
pentru a asigura faptul ca se poate produce un produs fiabil, fezabil si de calitate concordant cu cerintele
consumatorului, precum si fabricarea operatiilor de sustinere a produsului. Chiar cu aceste precautii, pot
exista probleme de proiectare care sa apara dupa ce a început productia. Functia “Fill Order” plaseaza
cererile de modificare a proiectului spre identificarea corectiilor care survin în proiect, pe când “Aquire
Customer” si “Order and Suport Product” sunt legate de urmarirea satisfactiei consumatorului pe tot
ciclul de viata al produsului. Calitatea si fiabilitatea nu pot fi inspectate într-un produs si ca urmare a
faptului testarea si evaluarea adecvata, atât pentru produs, cât si pentru proces trebuie realizata prin
efortul proiectarii de a asigura optimizarea productiei si satisfactia consumatorului.
Functia de proiectare este responsabila cu dezvoltarea produsului si a proceselor prin care acesta
este produs. Este imperativ ca procesul sa fie dezvoltat concurent cu produsul pentru a asigura o tranzitie
lina spre productie. Acest proces de proiectare este o interactiune iterativa cu preluare de consumatori si
comenzi, focalizat pe determinarea modului în care se poate obtine cea mai mare satisfacere a
consumatorului.
Produsul si procesul prin care se produce sunt dezvoltate angajând a abordare în echipa. Membrii
acestei echipe sunt reprezentanti ai tuturor functiilor, consumatorilor, partenerilor si furnizorilor. Acesta
va sprijini repetabilitatea proceselor care produc eficient si consistent produse care acopera sau exced
asteptarile consumatorului. Prima intrarea în acest proces o reprezinta produsul si cerintele procesului.
Iesirile vor include “build package” si feedback-ul de la alte procese: “direct enterprise” si “Aquire
Customers/Orders”. Cerintele relative la valori sunt transmise procesului de gestiune a valorilor.
[A5] – Procesul Fill Orders include toate sarcinile cerute pentru a produce si a livra produsele. Procesul
preia materia prima, componente, planuri si sarcina de planificare a productiei necesare pentru producerea
instrumentelor si produselor, completeaza detalierea fabricarii instrumentelor (SDV) activitatea cu
subansamblele si ansamblele si livreaza produsul final la consumator. În proces intra materialul si are la
iesire produsul. Se va transmite feedback catre alte procese, care privesc, starea, capacitatea si
capabilitatea. Limitarile acestui proces sunt “build package” planurile, politicile si procedurile.
Înainte de productie în sine, se pot executa planificari adecvate si trebuie stabilite mecanisme de
control. Prin acest mijloc se asigura ca valorile adecvate (materiale, informatie, echipament si munca)
sunt disponibile pentru satisfacerea cerintelor productiei si ca furnizeaza un mecanism de descarcare care
controleaza încarcarea nivelului vânzarilor. Odata cu producerea produsului trebuie întretinute facilitatile
si stocurile trebuie gestionate. Materia prima, componentele, subansamblele, energia, informatia sau
serviciile trebuie procurate prin efortul productiei. Produsul final, care include actualul produs,
documentatia si serviciile de sustinere care pot fi solicitate, trebuie sa fie eficient distribuite. Frecvent,
piesele de schimb sunt acoperite utilizând acelasi proces si are ca rezultat informatia aferenta.
[A6] ”Support Product” – Dupa ce produsul a fost fabricat si vândut pot fi necesare o suma de functii
care sa asigure sustinerea acestuia în piata / întretinere (Acest suport se poate materializa prin: editarea de
manuale si documentatii, furnizarea de suport logistic si educational, asigurarea serviciilor de întretinere,
sau asigurarea de piese de schimb. Asigurarea suportului produsului pe toate ciclurile de viata ale
produsului este deosebit de important pentru perceperea atât a întreprinderii cât si a produsului de catre
consumator, afectând direct posibilitatea întreprinderii de a ramâne competitiva.
Arborii de noduri
Modelele IDEF0 sunt colectii ierarhice de diagrame care formeaza un model. Intentia unui model este de
a introduce informatia de o maniera consiste nta si inteligibila. Lecturarea unui model IDEF0 prin
examinarea fiecarei diagrame înainte de a proceda la trecerea la nivelul urmator este referita ca citire

23
“prima latimea” (breadth first). O privire de ansamblu a modelului este data de o asemenea maniera.
Lecturarea unui model IDEF0 cu o privire spre detalii se va produce prin citirea în adâncime a arborelui
procedura referita ca fiind “adâncime prima”. Arborele de noduri al modelului da o privire rapida asupra
tuturor activitatilor din model. O exemplif icare pentru primele doua nivele este data în figura 2.16.

Figura 2.16 Arborele de noduri al modelului

Caracteristicile unui model viabil al întreprinderii

Modelul viabil al întreprinderii are câteva caracteristici cheie. Aceste cerinte sunt descrise mai jos si se
vor dezvolta în trei dimensiuni propuse.
Cerinte
Modelul viabil al întreprinderii trebuie sa aiba urmatoarele caracteristici pentru a fi efectiv (Huff, Liles
1991):
Întretinere: o caracteristica cheie a modelului este acesta reprezinta cu acuratete întreprinderea în fiecare
moment. Întreprinderea se modifica, ceea ce conduce la necesitatea naturala de a modifica modelul.
Modelul trebuie sa fie usor de extins pentru a încorpora schimbarile produse relativ la unul din aspectele
întreprinderii, iar acestea sa poata fi facil de încorporat. Aceasta este legata de prezumtia abordarii “top
down” sau “bottom up”. Abordarea “top down” este legata de un model mai holistic, pe când abordarea
“bottom up” tinde sa permita modelarea unui aspect al sistemului si apoi conectarea diferitelor
componente dupa ce acestea au fost validate. Prin concentrarea numai asupra modelarii aspectelor fizice
ale sistemului, utilizarea abordarii bottom up conduce la o dezvoltare mai naturala a sistemului (Pratt,
Mize 1993).
Dinamic: la modificarea sistemului, modelul trebuie sa se schimbe si el. Mai multe modele ale
întreprinderii sunt statice. Un model viabil al întreprinderii trebuie sa se modifice odata cu sistemul.
Acesta trebuie sa dea informatii importante atât relativ la rata schimbarii cât si la ratiunea acestora.
Expandabil : Modelul trebuie sa sustina, de asemenea, suplimentar subsisteme noi. În special în faza de
implementare, aspectele suplimentare ale întreprinderii vor fi asimilate în modelul întreprinderii. În
consecinta, este imperativ ca metodologia de modelare sa fie expandabila pentru a putea include aceste
modele (sub modele) noi.
Decompozabil : Modelele furnizeaza, curent, mai multe nivele de detaliere. Acest fapt este necesar pentru
a da întelegerea întreprinderii prin diferitele nivele ale managementului. Modelul viabil al întreprinderii

24
trebuie sa sustina nu numai întelegerea, dar si fundamentarea deciziei ti a controlului sistemului pe
diferite nivele de detaliu.
Consistenta cu metricile cheie ale întreprinderii : Unul dintre scopurile primare ale modelului viabil al
întreprinderii este de a sigura valoarea intrinseca a acestuia. Modelul este creat sa fie consistent cu
metricile curente ale întreprinderii si chiar se pune problema crearii unui model care sa conduca metricile,
astfel încât acesta sa devina parte integranta a întreprinderii.
Conducerea directa din datele actuale ale întreprinderii: Intrarile si iesirile în/din modelul viabil al
întreprinderii trebuie sa fie date actuale ale întreprinderii. Modelul trebuie sa conduca întreprinderea, iar
întreprinderea trebuie sa conduca modelul. Aceasta asigura realismul si credibilitatea modelului.
Dimensiunile modelului întreprinderii
Sunt propuse urmatoarele dimensiuni ale modelelor întreprinderii. Combinând asemenea caracteristici ale
cerintelor, sunt identificate trei dimensiuni ale acestor modele (Withman si Huff 1997). Natura
decompozitionala a modelelor întreprinderii furnizeaza domeniul dimensiunii modelului. Consistenta
modelului împreuna cu metricile cheie de întreprindere (care conduc întreprinderea), precum si modelele
existente sunt preluate din datele întreprinderii în rolul dual al dimensiunii de montare. Întretinerea si
expandabilitatea unui model defineste dinamicitatea acestuia. Descrierea fiecarei dintre aceste
caracteristici este prezentata mai jos.
Domeniul – este dat pe penetrabilitatea modelului în întreprindere. Modelarea întreprinderii prin natura
acesteia este de dorit sa dea o reprezentare holistica a întregii întreprinderi. Uneori este necesara limitarea
modelului la un subset al întreprinderii. Limitarea descrie domeniul modelului.
Montarea – este nivelul în care modelul conduce si este condus de catre sistem. Exista o mare diversitate
în capabilitatile de montare a modelului. Un model poate sa nu fie partajat în domenii care se vor monta
între ele, caz în care va gestiona întreaga întreprindere si va raporta, la cerere, toate intrarile si starile
întreprinderii. Mai multe dintre fazele montarii pot fi utilizate pentru un flux al activitatilor care poate
furniza atât directia personalului întreprinderii care sa permita acestora sa deriveze cuante ale procesului,
cât si stricta aderare la proces.
Un model dinamic este capabil sa raspunda atât schimbarilor proceselor temporale cât si a celor
permanente ale sistemului. Una dintre capabilitatile importante, de altfel, ale modelului întreprinderii, este
tocmai schimbarea. Fazele dinamicitatii se distribuie de la: fara capabilitati, pâna la structuri în care
modelul însasi este capabil sa “învete“ de la mediul în care evolueaza si sa se automodifice pentru a
reflecta si implementa procese noi, (Wood 1994). Aceasta dimensiune dinamica nu trebuie confundata cu
modelele de simulare care sunt, de multe ori numite reprezentari dinamice.
Metodologia de clasificare a modelelor întreprinderii
Una dintre sarcinile asumate în acest document este de a întelege si compara modelele întreprinderii. Cu
toate acestea, nu vor fi incluse relatii de ordine ale unui model relative la alte modele. Din aceasta ratiune
metrica propusa pentru modelul întreprinderii este multidimensionala mai degraba decât o valoare
singulara, relatia de ordine în acest caz fiind fara sens. De asemenea, scopul acestui document nu este de a
defini metrici pentru diferitele atribute ale modelului, cum ar fi complexitatea, întretinerea sau
interfatabilitatea. Ceea ce se propune este o metodologie de clasificare a modelelor întreprinderii pentru a
da un mecanism pentru întelegerea comuna a ceea ce este modelul si furnizând astfel un punct de pornire
pentru reorganizarea oportunitatilor cresterii (amplificarii) modelului. Trebuie de notat ca toate modelele
vor aborda în totalitate întreaga întreprindere. Cele patru dimensiuni prin care se realizeaza clasificarea
sunt: viziunea (V), caracterizata prin activitate (A), proces (P), informatie(I) resurse (R) si organizare (O).
Domeniul este desemnat prin trei categorii de baza ale proceselor:

Nivel Caracteristici
Întreprinderi Toate cele trei categorii de procese sunt modelate de-a
multiple (5) lungul întreprinderilor multiple
Divizii multiple (4) Toate cele trei procese sunt modelate pe site-uri
multiple ale întreprinderii
Întreprindere (3) Toate cele trei categorii de procese sunt modelate
Sistem (2) Modelele sunt considerate ipoteze si sunt cerute, în
consecinta pentru o decizie izolat temporala
Initial (1) Modelele nu sunt considerate ipoteze si sunt necesare
numai pentru decizii de mica importanta.

25
 Dimensiunea dinamica se refera la modul în care un model este actualizat, Scala utilizata în acest
sens este listata în tabela de mai jos:

Nivel Caracteristici
Matur (5) Este utilizat un depozit pentru a asigura controlul
versiunii modelelor întreprinderii
Evolutie (4) Un plan formal este pus în opera pentru integrarea
modificarilor majore ale întreprinderii modelelor, odata
cu schimbarea mediului.
Adaptare(3) Este pus în opera un plan formal pentru actualizarea si
întretinerea modelelor
Ajustare (2) Modelele sunt actualizate atunci când timpul o permite
Fara modificare (1) Modelele nu sunt considerate ipoteze si sunt utilizate în
consecinta numai pentru decizii de mica anvergura,
suplimentar modelele nu sunt actualizate.

Dimensiunea montare este împartita în doua componente: modul în care modelul conduce
întreprinderea si modul în care modelul este condus de catre întreprindere.

Nivel Caracteristica
Optimizare(5) Se utilizeaza o serie de modele care sunt conduse si conduc
întreprinderea de o maniera sistematica.

Gestionat(4) Este definit un plan formal pentru modele de a conduce si de

a fi conduse de întreprindere pâna se considera adecvate
Definit(3) Este definit un plan formal pentru modele de a conduce si de
a fi conduse de întreprindere pâna se considera adecvate
Ad hoc (2) Modelele sunt conduse /modelele conduc rar la comanda
(mai putin de o data pe an)
Fara montare Modelele nu sunt considerate ipoteze si sunt utilizate în
consecinta numai pentru decizii de mica anvergura,
suplimentar modelele nu conduc si nu sunt conduse de catre
întreprindere

2.2. O ARHITECTURA PENTRU ÎNTREPRINDEREA VIRTUALA

Este prezentata o arhitectura pentru întreprinderea virtuala bazata pe abordarea modelarii

procesului economic orientata obiect. Se considera faptul ca procesele economice se pot împartii în trei
categorii:
1. Procese care transforma restrictii externe în structura restrictiilor interne care poate fi exprimata
ca sistem de obiective, politici si proceduri.
2. Procese care procura si disponibilizeaza resursele utilizate de întreprindere
3. Procesele economice (proiectare, marketing, fabricare, distributie) care transforma intrarile în
rezultatele asteptate ale întreprinderii sau în iesiri (i.e. produse)
Procesele economice sunt organizate la rândul lor într-o întreprindere. Întreprinderea virtuala
consta dintr-o multime de procese economice din categoria 1 si care sunt, colectiv, proprietatea
întreprinderii virtuale si o multime de procese economice din toate cele trei categorii care sunt
recunoscute de doua sau mai multe întreprinderi individuale, dar utilizate atât de întreprinderea
individuala cât si de întreprinderea activa sau întreprinderea virtuala. Întreprinderea activa perturba ,
temporal, dar nu consuma întreprinderea individuala.
Trecerea spre fabricarea activa, pretinde abilitatea de a raspunde la modificari neanticipate.
Conceptul este construit pe fundamentul influentarii cunostintelor întreprinderii, mai degraba decât pe
forta în sine, pentru a realiza cerintele de calitate ale pietii, capacitatea de raspuns si satisfactia
consumatorului. Fabricatia activa a primit multa atentie de la mediul industrial, guverne si în egala
masura, de la mediul academic. Printre schimbarile manageriale si organizationale cerute de mediul

26
competitional, trebuie luata în considerare formarea companiei virtuale. Compania virtuala este o forma
de join venture, dar cu diferente semnificative. Aceasta reprezinta o alianta temporara a membrilor
companiei care se aduna pentru a obtine un avantaj relativ la oportunitatile pietii. Întreprinderea virtuala
nu poseda personal sau resurse inventariabile. Fiecare membru al companiei va furniza competentele
proprii în domenii ca: marketing, inginerie si fabricatie, companie virtuala. Sunt necesare numai: o echipa
pentru gestionarea detaliilor administrative si de management, pentru a se putea realiza o astfel de
companie formata din companii actionare, subcontractanti si parteneri care sunt legati împreuna prin
intermediul unei retele de calculatoare. Disparitia oportunitati din piata, duce la dizolvarea companiei.
Unul dintre scopurile majore ale constituirii întreprinderii virtuale este legat de rapida integrare a
proceselor economice ale companiilor participante.
Se va descrie o arhitectura pentru întreprinderea virtuala (The University of Texas, Arlington,
Automation&Robotics Researh Institute). Aceasta arhitectura este orientata pe abordarea orientata obiect
a modelarii întreprinderii. Arhitectura va sprijini companiile care doresc sa intre în relatie virtuala prin
definirea functiilor si a interfetelor sau a proceselor economice critice, permitând astfel o integrare rapida
si eficienta a competentelor cu care contribuie fiecare dintre participanti la compania virtuala.
Arhitectura întreprinderii
Arhitectura unei întreprinderi poate fi privita ca un plan care se impune în proiectarea asistata a
întreprinderii. Arhitectura întreprinderii trebuie sa defineasca trei lucruri:
- activitatile pe care întreprinderea trebuie sa le realizeze
- modul în care trebuie realizate aceste activitati
- modul în care întreprinderea poate fi construita
În consecinta, arhitectura care trebui construita, va identifica procesele esentiale realizate de
compania virtuala, modul în care compania virtuala si întreprinderea activa implicate în compania virtuala
realizeaza aceste procese si va fi inclusa si o metodologie pentru reconfigurarea rapida a întreprinderii
virtuale.
De-a lungul dezvoltarii se vor pune întrebarile relative la ce si la cum pentru constituirea
template-ului unei fabricatii active care îsi propune sa participe la relatiile virtuale. Aceste template-uri
vor fi uzuale pentru eforturile de perfectionare ale proceselor economice, aditional cu formarea
întreprinderii virtuale. Scopurile configuratiei se vor lua în considerare pe parcursul dezvoltarii
metodologiei pentru a facilita reconfigurarea rapida a întreprinderii pentru parteneri virtuali care
utilizeaza template-urile astfel dezvoltate.
O întreprindere trebuie privita din mai multe perspective pentru a putea fi complet descrisa si
înteleasa. Cele mai ample rezultate au fost obtinute prin programul ESPRIT, luate în considerare de CIM-
OSA, care defineste un cadru arhitectural ca fiind format din patru puncte de vedere: functional,
informatie, resurse si organizational. Suplimentar, CIM-OSA defineste o instantiere în trei pasi a
procesului de la generic la partial si apoi la particular, precum si trei nivele de abordare care constau din
crearea modelelor pornind de la definirea cerintelor, la specificarea proiectarii, pâna la implementare.
Lucrarile anterioare relative la dezvoltarea unei arhitecturi includ si activitatea ARRI. În cadrul
arhitectural ARRI, punctul de vedere functional al unei întreprinderi este separat în activitati (ceea ce este
de facut) si procesele economice (cum trebuie facut). Activitatile de referinta si modelele proceselor
economice pentru întreprinderile mici au fost dezvoltate si documentate utilizând IDEF0 si respectiv
IDEF3. Aceste doua lucrari formeaza baza pentru procesarea raspunsurilor la întrebarile relative la ce si la
cum, referitoare la o arhitectura.
Modelarea proceselor economice
O întreprindere este o multime de activitati ale întreprinderii organizate într-un set de procese economice
care coopereaza pentru a produce rezultatul scontat al acesteia. În contextul discutiei actuale, activitatea
unei întreprinderi este definita ca fiind orice comportament organizat care transforma o intrare într-o
iesire. În aceasta acceptiune se considera activitatile întreprinderii ca blocurile de baza ale întreprinderii si
mai mult acestea devin uzuale numai daca sunt organizate într-un proces economic.
Arhitectura trebuie sa furnizeze modelul întreprinderii pentru a promotiona întelegerea acesteia.
Tehnica de modelare prin IDEF0 este prezentata în figura 2.17.
Intrarile sunt reprezentate de ceea ce urmeaza a fi transformat de activitatea în sine. În
formalismul IDEF0 sunt definite doua categorii speciale de intrari. Un mecanism sau resursa este definit
ca persoana, contextul de echipament care realizeaza activitatea, iar restrictii sunt ceea ce influenteaza sau
controleaza modul în care o activitate este îndeplinita. Spre deosebire de intrari, mecanismele si
restrictiile nu sunt transformate sau consumate de activitate. O iesire este rezultatul unei activitati. Este de
remarcat ca fiecare dintre acestea pot fi materiale (echipamente, persoane sau materiale) sau imateriale

27
(informatie sau concepte). Conceptul unei întreprinderi active sau virtuale introduce unele solutii în
configurarea si implementarea proceselor economice. O întreprindere virtuala este, prin definitie, o
structura organizational temporala, care implica numerosi actori (internali cât si externali pentru o singura
astfel de întreprindere).
Restrictii

Realizarea
Intrare Iesire
activitatii

Mecanisme(resurse)

Figura 2.17. Reprezentarea unei activitati în IDEF0

Definirea si coordonarea proceselor economice care contin o organizatie devine mult mai dificila.
Avantajul competitivitatii sau competentele diferite ale membrilor întreprinderii virtuale va un context
fundamental. Membrii se leaga la întreprinderea virtuala pe baza competentelor proprii, pastrând însa
natura proprietatii asupra respectivelor competente, ceea ce ar putea deveni o cerinta critica pentru o
astfel de organizatie temporala. Legat de aceasta problema se ridica necesitatea comunicatiei inter -
procese. Comunicarea trebuie sa fie permisa peste domeniile functionale, între activitatile adiacente din
cadrul unui proces si între procesele întreprinderii virtuale. Dezvoltarea, în continuare, a structurilor
organizationale, a sistemului informational si mecanismelor de coordonare devine un set de activitati
consumatoare de resurse (timp, financiare etc.) În final organizatia foarte flexibila si orientata proces
determina ca toate aspectele (informational, resursa, organizational si activitati) ale întreprinderii sa fie
integrate. Paradigma orientata obiect este propice tuturor acestor necesitati si furnizeaza o metoda
reprezentationala mai naturala decât metodele traditionale. Modelarea traditionala a proceselor
accentueaza unul dintre aspectele operatiei întreprinderii în detrimentul celorlalte. Seria de metode IDEF
formalizeaza spargerea aspectelor organizationale în: date, distributie, activitati si aspecte socio-tehnice.
Fiecare aspect organizational este modelat utilizând tehnici reprezentationale diferite si nu exista
mecanisme formale pentru a coordona aceste reprezentari. O metodologie care sa sprijine dezvoltarea
întreprinderii virtuale trebuie sa permita ca procesele economice sa poata fi modelate ca “black box”. BB
vor permite fluxul de informatii si material în întreprinderea virtuala, simultan cu protejarea naturii
proprietatii proceselor economice ale organizatiei. O astfel de abordare poate, prin definitie, sa permita
reconfigurarea rapida a proceselor economice de catre membrii organizatiei. Pe scurt, procesele trebuie
modelate de maniera la care sa permita compatibilitatea “plug and play” dintre procesele organizationale.
Modele de procese economice orientate obiect
Paradigma orientata obiect furnizeaza o solutie tare pentru modelarea necesitatilor unice ale proceselor
economice ale întreprinderii virtuale. Abordarea orientata obiect, fenomenele din lumea reala (un proces,
o activitate, un actor) sunt percepute ca entitati complete. La un nivel înalt de abstractizare, fenomenele
din lumea reala sunt clasificate sau grupate pe baza caracteristicilor partajate si a comportamentelor.
Aceste grupari abstracte formeaza clasele. Toate aspectele unui fenomen dat sunt încapsulate sau
continute în reprezentarea unei clase. Activitatea curenta din sistemele orientate obiect accentueaza
reprezentarea caracteristicilor (viziunea informatie) sau a comportamentelor (viziunea activitate). Acest
model poate fi extins pentru a încapsula viziunile mecanismelor de coordonare si de resursa.
Ocurenta fizica sau instantierea unei clase de fenomene este reprezentata de un obiect. Obiectele
apar, în aceasta acceptiune ca fiind instantele unei clase care a fost identificata în mediul organizational.
Mediul economic este reprezentat ca interactiuni ale acestor obiecte (fenomene ale lumii reale). Un astfel
de aranjament permite o reprezentare mai naturala a mediului organizational si implica coordonarea
diferitelor viziuni contextuale ale întreprinderii virtuale. O astfel de metoda reprezentationala
formalizeaza, de asemenea, relatiile de comunicare între elementele modelului. Comunicatia este realizata
prin mesaje de la o reprezentare la alta, nefiind permisa nici o alta interactiune. Obiectele sunt percepute
ca fiind BB care-si contin propria informatie si “stiu” modul în care sa-si realizeze propriul
comportament. Un obiect va primi mesaje pentru a-si realiza propriul comportament, iar pentru cazul în
care obiectul nu are comportament, mesajul va fi ignorat.

28
 Specificarea claselor în mediul economic poate fi realizat pe diferite nivele de abstractizare. O
caracteristica a sistemelor orientate obiect este ca aceste clase au particularitatea de a-si partaja
proprietatile cu forme mai speciale lor însele. Aceasta particularitate este referita ca mostenire si
reprezinta unul dintre avantajele importante ale acestei paradigme. O clasa poate fi rafinata în forme mai
specializate. Fiecare dintre aceste clase specializate, mostenesc proprietatile claselor mai generale
(parinti). Subclasele pot utiliza caracteristicile (proprietati sau comportamente) la care pot adauga unele
noi sau pot modifica aceste caracter istici pentru a sustine mai bine o necesitate.
În termeni de modelare a întreprinderii virtuale, structura clase-subclase si mostenirea sunt
proprietati uzuale ale abordarii orientate obiect. Ceea ce trebuire limitat în procesul de modelare al
întreprinderii virtuale este numarul, teoretic foarte mare, al configuratiilor posibile pe care fiecare proces
si le poate asuma. Structura fundamentala, însa, ramâne aceiasi pentru realizarea proceselor: Resursele
sunt transformate si trimise la consumator. Cazul general al structurii claselor furnizeaza un punct de
pornire conceptual pentru modelarea specificitatii unei conjuncturi date. Suplimentar, efortul implicat în
realizarea modelarii proceselor este micsorat prin reutilizarea structurilor generale în modelarea cerintelor
mai speciale ale proceselor în contextul relatiilor din întreprinderea virtuala. Efortul de modelare este mai
oportun daca se produc numai modificari ale modelului general, pe perioada organizarii întreprinderii
virtuale.
Relativ la mostenirea dintre clase în abordarea orientata obiect, o caracteristica importanta este
abilitatea claselor sau a obiectelor mai specifice de a masca informatia. O alta caracteristica fundamentala
a reprezentarii orientate obiect este polimorfismul. Polimorfismul, în termeni de model orientat obiect are
semnificatia: un singur mesaj (comanda) poate avea mai multe semnificatii, functie de receptor mesajului.
O subclasa interpreteaza mesajul pe baza definitiei interne a acestuia. În consecinta comportamentul
invocat pr intr-un mesaj MOVE poate avea semnificatii diferite pentru o subclasa care controleaza
transportul mesajului relativ la una care controleaza AGV (Automated Guidede Vehicle). Tipul pentru
Move este determinat de comportamentul specificat al subclasei care realizeaza activitatea si nu de
controlerul extern al solicitantului activitatii.
Rezumând, caracteristicile fundamentale ale abordarii orientate obiect sunt:
1. clasificarea
2. încapsularea
3. comunicatia bazata pe mesaje
4. mostenirea
5. polimorfismul
Acestea furnizeaza capabilitatile necesare modelarii proceselor care sustin întreprinderea virtuala.
Independenta dintre activitatile procesului si functii este realizata prin reprezentarea proceselor
economice ca multimi de relatii dintre obiecte. O astfel de reprezentare a procesului accepta natura
dinamica a unei organizatii virtuale, în care membrii acesteia pot varia (cauzând astfel modificari
corespunzatoare în configuratia proceselor organizationale). Încapsularea comunicatiei bazata pe mesaje
si polimorfismul permit standardizarea interfetelor dintre activitati si procese. Standardizarea acestora
este deosebit de importanta pentru întreprinderea virtuala, deoarece comunicatia traverseaza frontierele
fizice organizationale. Competentele distincte ale membrilor organizatiei sunt protejate, de asemenea
printr-o astfel de abordare. Întreprinderile competitoare pot coopera într-o întreprindere virtuala unica
deoarece interactiunile sunt într-o multime unica de mesaje sau mecanisme de interfata. Suplimentar,
activitatile sau procesele percep numai interfetele si nu proprietarii din spatele acestora.
Acceptiunea de fata îsi propune, ca baza, pentru modelarea proceselor economice orientate obiect
un model cu doua clase (figura 2.18.).

Utilizeaza
Activitate

Produs

Produce Procese

Figura 2.18. Modelul general al proceselor economice orientate obiect

29
 Cele doua clase continute în acest model sunt : produsele si activitatile.
Produsele reprezinta o generalizare a resurselor sau intrarilor utilizate de organizatie si iesirile
organizatiei. Literatura contemporana si restructurarea proceselor accentueaza ca fiecare activitate este un
consumator al produselor operatiilor anterioare, fie ca aceste operatii sunt statii de lucru sau întreprinderi
separate. Fiecare operatie produce un produs care este obtinut prin urmarea unor operatii, ceea ce însemna
ca operatiilor li se atribuie semnificatie. Utilizând aceasta denumire de produs pentru aceasta clasa se va
accentua relatia furnizor-client în operatiile organizationale. Clasa activitate reprezinta acele operatii care
acopera transformarea intrarilor în iesiri. Activitatile consuma resurse (produse sau alte activitati) si
produce produse (care vor fi consumate). Relatia dintre aceste doua clase se constituie în modelul de baza
al procesului economic.
Un proces economic este definit ca o multime de activitati ordonate temporal, care îndeplinesc un
scop. Figura 2 defineste relatiile dintre clasele produs si activitate care definesc, la rândul lor conceptul de
proces economic în concordanta cu aceasta definitie. Sirul ordonat de activitati este reprezentat de relatia
recursiva dintre activitati. Aceasta relatie este etichetata ca proces si este atât ordonata cât si în natura.
Activitatile vor participa, deci, în doua tipuri de relatii cu produsul. Activitatile sunt consumatoare de
produse (relatia utilizeaza) si producatoare de produse (relatia produce).
Acest model nu este limitat la utilizarea sa în contextul întreprinderii virtuale, fiind o reprezentare
generala a proceselor (în speta a proceselor economice). Conceptele obiect (mostenire, clasificare) pot fi
aplicate acestui model pentru a forma reprezentarea specifica a proceselor organizationale.
Arhitectura întreprinderii virtuale
Se poate face o împartire naturala, în categorii a proceselor economice:
1. Acele procese care transforma restrictiile externe în restrictii interne
2. Acele procese care preiau si pregatesc resursele
3. Acele procese care utilizeaza resursele pentru a produce rezultatele întreprinderii

ÎNTREPRINDEREA

Categoria 1 a
proceselor economice

Categoria 2 a
BP3 proceselor economice

BP1

BP4
BP2

BP6 BP5

BP7 Categoria 3 a
proceselor

Figura 2.19. Întreprinderea ca o multime de procese economice

Figura 2.19 prezinta unele seturi de activitati ale întreprinderii organizate logic în procese
economice. Procesele economice, la rândul lor sunt organizate în întreprindere. La acest nivel înalt de

30
abstractizare, întreprinderea însasi este reprezentata ca o activitate care preia intrarile, pe care le
transforma în iesiri utilizând pentru aceasta resursele limitate la anumite conditii.
Întreprinderea virtuala consta dintr-o multime de procese economice din categoria 1 care sunt
colectiv recunoscute de catre aceasta si o multime din toate cele trei tipuri care sunt recunoscute de doua
sau mai multe întreprinderi active si utilizate atât de întreprinderea individuala cât si de întreprindere
virtuala. Întreprinderea virtuala, temporal, angajeaza întreprinderea individuala dar nu o consuma.
Întreprinderea virtuala nu este proprietara proceselor din categoriile 2 si 3 si nu dispune de resurse care sa
sustina procesele din categoriile 2 si 3. În anumite conditii poate sa dispuna de procesele categoriei 1si are
propriile intrari si propriile iesiri, iar restrictiile acesteia date de mediu difera, în general de conditiile de
mediu ale întreprinderilor individuale.
Suplimentar, la identificarea proceselor arhitectura trebuie sa defineasca modul în care procesele
economice trebuie sa fie îndeplinite. Pentru a acoperi aceasta cercetare trebuie identificate urmatoarele:
- activitatile întreprinderii continute în procese
- succesiunea logica si temporala a activitatilor
- intrarile transformate de fiecare activitate din proces
- iesirile intentionate de la fiecare activitate
- multimea restrictiilor care limiteaza fiecare activitate
- multimea regulilor de activare defineste iesirea tinta pentru combinatiile de intrari si restrictii
ÎNTREPRINDEREA VIRTUA LA

Categoria 1 procese economice recunoscute

colectiv pentru dezvoltarea strategiilor,
politicilor , tacticilor si planurilor

Categoriile 2,3 procesele economice

proprietate si gestiune individuala pentru
proiectare, producerea si distribuirea
produsului

Întreprinderea A
Întreprinderea B

Întreprinderea C

Figura 2.20. Întreprinderea virtuala

Proiectul de cercetare are trei obiective primare. Primul estre de a dezvolta si valida o multime de
template-uri pentru procesele economice, necesare “fabricarii” întreprinderii. Aceste template-uri se vor
finaliza în cele trei tipuri de procese descrise mai sus. Cel de al doilea se refera la formularea unei
metodologii pentru reconfigurarea rapida a unei întreprinderi, utilizând template-urile si în final, cel de al
treilea se refera la modalitatile în care partenerii industriali vor utiliza rezultatele primelor doua.
Activitatea se va dezvolta pe doua domenii importante:
Primul se refera la faptul ca daca template-urile pot fi construite, ramâne problema raspunsului la
modul în care trebuie sa se comporte întreprinderea activa. Astfel se vor identifica caracteristicile unei
întreprinderi active, cu identificarea metricilor care pot fi utilizate pentru a realiza masurarea sau
evaluarea unei întreprinderi pe scara de activitate. A fost deja dezvoltata definitia activitatii si au fost
identificate, formalizate si validate o multime de caracteristici. Aceste caracteristici sunt, în continuare
utilizate pentru a defini metricile de performanta pentru procesele economice esentiale.

31
 Cel de al doilea domeniu se refera la dezvoltarea m etodelor de modelare orientate obiect. Au fost
identificate clasele si subclasele care reprezinta obiecte, atât activitati cât si produse, care pun în opera
întreprinderea virtuala. La acest nivel înalt de abstractizare se defineste clasa generica a activitatii. Cele
trei categorii de procese se vor constitui în primul nivel al subclaselor activitatilor, în care fiecare
categorie poseda o caracteristica unica, suplimentar celor care sunt comune tuturor activitatilor. Din
acelasi domeniu face parte si identificarea atributelor care trebuie sa fie prezente în reprezentare pentru a
se putea realiza o descriere adecvata a întreprinderii.
Odata cu finalizarea specificarii caracteristicilor de activitate cerute, vor fi identificate si descrise
procesele economice de baza. Aceste procese economice de baza se definesc ca acele procese pe care
toate întreprinderile trebuie sa le realizeze pentru a deveni active. Aceasta poate fi îndeplinita printr-o
modelare exhaustiva a proceselor economice, efort la care participa mai multi producatori. Modelul
procesului rezultat prin consens, va fi descris utilizând abordarea de modelarea orientata obiect si va
defini activitatile realizate procesele economice si va descrie complet multimea interrelatiilor critice
dintre întreprinderea activa si întreprinderea virtuala.

2.3. ASPECTE ALE METODELOR FORMALE PENTRU SPECIFICAREA SI VERIFICAREA SOFTWARE SI

SISTEME

Metodele formale consista dintr-un set de tehnici si instrumente bazate pe modelarea matematica
si logica formala care sunt utilizate pentru specificarea si verificarea cerintelor si proiectarii sistemelor de
calcul si a software-ului. Utilizarea metodelor formale poate sa ia, într-un proiect forme diferite, de la
notatii matematice ocazionale încapsulate în specificatii în limbaj natural, pâna la specificatii formale,
complete, utilizând limbaje de specificatii cu semantica precisa. Metodele formale implica verificarea
asistata de calculator a proprietatilor semnificative (cheie) care privesc comportamentul sistemului.
Managerul proiectului alege din acest spectru al metodelor formale optiunile care optimizeaza raportul
cost – beneficiu si îndeplineste, nivelul de verificari care sa satisfaca cerintele date si sa se încadreze în
bugetul alocat. Metodele formale joaca un rol important în multe activitati de certificare, reutilizare si
asigurare a calitatii.
Software-ul continua sa joace un rol proeminent si critic în sistemele complexe. Odata cu
dezvoltarea ciclului de viata, modelele de defect si metodele care au functionat bine la sistemele hardware
nu mai sunt optime pentru sistemele care includ componente software semnificative; identificarea si
evaluarea tehnicilor de verificare pentru astfel de sisteme sunt necesitati imperioase care cresc odata cu
dezvoltarea disciplinei de sistem. Aceste necesitati, coroborate cu îmbunatatirea tehnicilor si
instrumentelor metodelor formale au dus la aparitia de specificatii si verificari a tehnicilor pentru cele mai
multe produse care include software. Principalele aspecte pozitive, de luat în considerare, relativ la
utilizarea metodelor formale sunt:
? Metodele formale sprijina detectarea defectelor; aceasta apare cu claritate atunci când, aplicate
la sisteme software de înalta calitate, metodele formale au detectat defecte care nu au fost identificate pe
parcursul testarii intensive. Natura inductiva a testelor determina faptul ca sisteme le complexe vor avea
totdeauna scenarii care nu pot fi testate din consideratii practice.
? Specificatiile formale permit detectare defectelor de cerinte si proiectare înca din primele faze
reducând astfel incidentele care pot sa apara în interpretarea si implementarea cerintelor si ale proiectarii.
? Enunturile formalizate pot fi analizate si în consecinta calculate într-o maniera repetabila.
Riscul concluzionarii relative la comportamentul unui sistem prin explorarea unui numar finit de teste ,
poate fi evitat prin utilizarea metodelor matematice de verificare. Astfel de metode permit un numar mare
(potential infinit) de clase de cazuri de test care sa fie acoperite într-o verificare finita si care pot fi
verificate, fie manual, de alt membru al colectivului, fie de catre o masina, cu o dependenta minima de
aspectele subiective.
? Utilizarea metodelor formale duce la detectarea mai multor defecte potentiale sau poate da
asigurari relativ la absenta unora.
Concepte
Metodele formale se refera la utilizarea tehnicilor specifice logicii formale si a matematicii discrete în
specificarea, proiectarea si constructia de sisteme de calcul si software. Metodele formale creeaza
posibilitatea calculabilitatii consistentei descrierii unui sistem, a faptului ca o proprietate enuntata este o
consecinta a unei cerinte propuse sau a corectitudinii cu care cerintele au fost interpretate în cadru

32
proiectarii. Acest tip de calculabilit ate va pune la dispozitie caile prin care se vor reduce subiectivitatile
generate de interpretarile informale sau cvasi-formale.
Modelarea formala a unui sistem impune, de obicei, translatarea unei descrieri a sistemului
pornind de la un model nematematic (diagrame de flux de date, diagrame obiect, scenarii, text în limba
naturala etc.) într-o specificatie formala utilizând unul sau mai multe limbaje formale. Aceste rezultate,
într-o descriere sistemica vor poseda un grad ridicat de precizie logica. Instrumentele metodelor formale
pot fi folosite pentru evaluarea logica a acestor specificatii, pentru a concluziona asupra completitudinii si
consistentei cerintelor sistemului sau ale proiectarii. Tehnicile de analiza a metodelor formale sunt bazate
pe abordari mai degraba deductive decât inductive relative la descrierea sistemului punând la dispozitie
toate clasele de probleme care trebuie sa fie rezolvate înainte ca cerintele sa fie prinse în faza de
proiectare si ulterior de implementare. Metodele formale completeaza testarea inductiva care urmeaza
implementarii prin calarea fazei de testare pe cazuri de test potentiale mici sau pe domenii cu probleme
ale sistemului.
Tehnicile si uneltele metodelor formale pot fi aplicate pentru specificarea si verificarea
produselor pentru fiecare ciclu de viata : cerinte, proiectare la nivel înalt sau scazut si implementare28.
Procesul de aplicare al metodelor formale la cerinte sau la proiectare difera în mod substantial relativ la
nivelul de detaliere la care respectiva tehnica este aplicata.
Aceste tehnici includ scrierea specificatiilor formale, verificarile interne (ex. Verificarea si
tiparirea corectiilor), verificarea trasabillitatii, specificarea animatiei si verificarea sintactica si semantica
a asertiunilor.
Cu toate ca întreaga serie de tehnici si instrumente poate fi aplicate tuturor cerintelor si
elementelor de proiect, abordarea uzuala nu va fi aceasta. În schimb, va fi ales un subset de cerinte care
vor urma metodele formale si un subset de tehnici care vor fi selectate pentru aplicatii. Aceasta va
permite proiectului sa aleaga un nivel de rigoare a verificarii în conformitate cu bugetul, planificarile si cu
nevoile echipei care face respectiva dezvoltare.
În completarea functiilor metodelor formale acestea pot as igura stabilirea si întretinerea stricta a
trasabilitatii între descrierile sistemului, în diferitele faze ale ciclului de vita.
Relativ la un produs, vor fi cerinte care se vor manifesta pe nivelul cel mai abstract pâna la
nivelul cel mai concret, cerinte care vor apare la proiectarea de nivel înalt, prin proiectarea de nivel scazut
pâna la implementare.
Documentele care vor defini specificatiile, vor corespunde fazelor ciclurilor de viata ale
produsului. Metodele formale pot fi utilizate si pentru a face demonstratia ca o proprietate definita pe un
nivel oarecare al acestei ierarhii este corect implementata pe nivelul urmator.
Intr-un tratament minutios si riguros metodele formale sunt cadru care poate demonstra ca
cerintele sunt corect reflectate în proiectarea care urmeaza si ca caracteristicile proiectului sunt corect
reflectate în implementarea corespunzatoare.
Definitii
În continuare sunt date definitiile termenilor de baza si a conceptelor cu care se va opera ulterior:
Specificatie formala - este o descriere concisa a comportamentului si a proprietatilor unui sistem scris
intr-un limbaj bazat pe matematica , specificând ceea ce sistemul ar trebui sa faca, cât mai abstract cu
putinta, cu alte cuvinte eliminând detaliile si furnizând o descriere care sa reziste modificarilor ulterioare
ale sistemului.
Cele mai formale specificatii sunt scrise în limbaje care dispun de semantici bine definite si care
accepta deductii formale si permit calculabilitatea consecintelor specificatiilor prin probarea acestora în
teoreme curent acceptate.
Proba formala - este un argument complet si convingator pentru validitatea unui enunt relativ la
descrierea sistemului. O proba consta într-o serie de pasi, fiecare dintre acestia concluzionând asupra unui
set de ipoteze. Justificarea fiecarui pas este derivata din numarul mic de reguli care sa statueze concluzia
ce poate fi trasa, în mod rezonabil din ipoteze. Astfel de justificari elimina ambiguitatea si subiectivitatea
argumentului. Probele formale pot fi pregatite manual, sau, de preferat cu instrumente automatizate ale
metodelor formale.
Abstractizare - este procesul simplificarii si ignorarii detaliilor irelevante focusarea, distilarea si
generalizarea a ceea ce a mai ramas. În metodele formale, abstractizarea apare ca un in strument utilizat

28
Analiza cost beneficiu, în general, favorizeaza metodele formale aplicate la ciclurile de viata initiale ale
produselor (nivelul cerinte si proiectare de nivel înalt)

33
pentru eliminarea detaliilor accidentale si pentru evitarea trecerii premature la implementare, precum si la
calarea pe esenta problemei
Specificarea animatorilor (emulatorilor) - sunt programe executabile care reinterpreteaza specificatiile
formale într-o forma executabila, în mod dinamic, la nivel înalt. Emulatorii nu sunt formali în sensul
strict, dar suporta cerintele formale si procesul de verificare al proiectului prin asigurarea de analize
relative la comportamentul dinamic, pe nivel înalt al cerintelor.
Pentru identificarea modificarilor necesare în vederea integrarii metodelor formale într-un proces
software existent sunt necesare:
1. Cerintele initiale ale procesului. Introducerea efectiva a metodelor formale presupune existenta
proceselor bine definite ale caror caracteristici au fost deja stabilite:
? pasii au fost deja definiti si documentati, adica: faza cerintelor, faza proiectarii la nivel înalt etc.
? produsele activitatii pentru fiecare faza au fost de asemenea definite: documentele pentru cerinte,
diagramele pentru proiectarea pe nivel înalt etc.
? procedurile de analiza pentru asigurarea corectitudinii produsului fiecarei faze au fost definite,
adica verificarea proprietatilor cheie ale sistemului
Un proces care nu are definite aceste aspecte nu este suficient de elaborat pentru a putea avea un
beneficiu semnificativ prin aplicarea metodelor formale.
În fazele carora li se aplica metode formale se vor adauga câteva din urmatoarele produse sau activitati:
? o noua activitate de analiza numita: modelare, pe parcursul careia se propune o descriere initiala, de
obicei grafica, a relatiilor dintre entitatile sistem. Sunt posibil de utilizat metode diverse: masini finite de
stare, proiectare orientata obiect etc.
? o noua activitate de dezvoltare: formalizarea, pe parcursul careia sunt create specificatiile formale
? un nou tip de produs al activitatii numit: specificatia formala. Acesta poate sa fie un produs cu totul
separat, dar poate fi si un adagio la un produs deja existent cum ar fi: documentul cu cerintele.
? o noua activitate de analiza numita: animare a specificatiilor, necesara unei întelegeri mai bune a
comportamentului implicat de specificatiile formale
? o noua activitate de analiza: probarea asertiunilor pentru a creste corectitudinea specificatiilor
formale si a întelege implicatiile proiectarii cerintelor si a specificatiilor
? o revizuire a specificatiilor pentru verificarea corectitudinii si a completitudinii acestora.
? o sporire a instrumentelor de trasabilitate si a tehnicilor de trasare a noilor produse ca de exemplu a
specificatiilor formale si probarea relatiilor cu celelalte produse.
2. Ordonarea activitatilor. Nu este o ordonare fixa, prestabilita pentru activitatile necesare metodelor
formale. De fapt, o abordare iterativa es te mai eficienta pentru dezvoltarea si analiza specificatiilor.
Reluarile pot fi productive la un moment dat, dupa ce specificatiile au fost deja dezvoltate, atât înainte cât
si dupa ce proprietatile cheie au fost odata verificate. Cel putin o revizuire trebuie sa aiba loc dupa ce
specificatiile sunt complete.
3. Analiza sigurantei în functionare. Analizele standard sunt calate pe corectitudinea functionarii, adica
a comportamentului pe care sistemul trebuie sa-l aiba. Analiza sigurantei în functionare este în general
calata pe comportamentul pe care sistemul nu trebuie sa-l manifeste deoarece aceasta va trebui sa creeze
conditii de nesiguranta sau de hazard adica sistemul nu trebuie sa emita o comanda eronata sau sa se
produca un esec ca raspuns într-un timp dat. Analiza sigurantei în functionare priveste produsele
activitatii din punctul de vedere al sigurantei, iar aceasta poate fi combinata cu analiza traditionala sau
poate face obiectul unei activitati separate. Analiza tehnica pentru siguranta produselor software este în
mod curent definita chiar daca este mai putin bine definita ca pentru produsele hardware dar deja sunt
metode formale care completeaza tehnicile existente pentru asigurarea metodelor necesare statuarii si
analizei proprietatilor de siguranta în functionare. În mod particular, metodele formale asigura calea
pentru statuarea corectitudinii functionale si a proprietatilor de siguranta folosind specificatiile formale
urmând demonstratia ca aceste specificatii satisfac proprietatile de siguranta cerute. Metodele formale pot
fi utilizate pentru formalizarea si automatizarea unui pas existent de analiza a sigurantei sau pentru a
asista aditionarea analizei pasului analizei sigurantei la un proces existent
4. Masurarea eficacitatii metodelor formale. Se cunosc mai putine relativ la metricile utilizate în
metodele formale. Cu toate acestea, un proces ajuns la maturitate poate include clauze pentru colectarea
de date relative la eficienta metodelor formale sau asupra eficientei oricarui proces. Metricele potentiale
includ:
? numarul de pagini în descrierea în limbaj natural care a fost utilizat ca baza pentru specificatia
formala relationat cu indicatiile subiective a nivelului de detaliere si completitudine;
? numarul de linii al specificatiei formale produs;

34
 ? cantitatea de timp consumata pentru dezvoltarea specificatiilor, incluzând proprietati si probarea
acestora;
? numarul de scopuri gasite în cerintele initiale (cerintele în forma de descriere din limbajul natural,
înainte de a fi formalizate), împreuna cu o ierarhie subiectiva a importantei acestora;
? dimensiunea timpului consumat în revizuirea si în inspectarea documentului relationata cu numarul
si tipul de scopuri determinate cu acest prilej;
? numarul de scopuri gasite dupa analiza cerintelor, împreuna cu descrierea cauzei pentru care
scopurile nu au fost determinate la momentul la care trebuiau gasite.
5. Stabilirea metodelor formale pentru un proiect. Pentru alegerea metodelor formale în vederea
dezvoltarii unui proiect sunt de luat în consideratie doua tipuri de baza de considerente: factori
administrativi si factori tehnici
Factorii administrativi:
? Conducerea proiectului: Echipa responsabila cu planificarea rolului metodelor formale pentru un
proiect trebuie sa includa cel putin o persoana care sa cunoasca semnificativ despre metodele formale si
cel putin una care sa cunoasca suficient de bine domeniul pe care proiectul îl abordeaza. Echipa
responsabila cu aplicarea metodelor formale trebuie sa aibe experienta în aplicarea de metode formale.
? Scara proiectului: Scara proiectului trebuie luata în considerare. Daca personalul implicat în proiect
nu are sau are o mica experienta în domeniu, va trebui avizat un studiu initial fie ca un obiectiv final, fie
ca legatura cu proiectul în totalitatea sa.
? Educatie pentru Metode Formale: Educatia disponibila pentru personalul acestui proiect trebuie sa
fie riguroasa si sa includa experienta deja existenta relativ la instrumentele utilizate si tipul de aplicatii
care vor fi integrate în proiect.
? Integrarea proceselor: Strategia de integrare a metodelor formale într-un proces nou sau deja
existent trebuie sa fie minutios planificata si documentata, preferabil la începutul proiectului.
? Metoda exacta, standardele si conventiile, trebuie dezvoltate si considerate înca de la început, atât
pentru specificare cât si pentru documentare.
Factori tehnici:
? Tipul aplicatiei: Metodele formale nu sunt la fel de potrivite pentru toate aplicatiile; acestea sunt
convenabile pentru analiza problemelor complexe, luate singure sau în combinatie si mai putin
convenabile pentru algoritmii numerici.
? Dimensiune si structura aplicatiei: dimensiune si structurarea aplicatiei determina gradul de
dificultate în utilizare metodelor formale; ideal, aplicatiile ar trebui sa fie de dimensiune moderata,
decompozabile în subsisteme sau componente si bazate pe o structura de baza coerenta.
? Tipul de analiza/metoda formala: tipul de analiza, i.e., ratiunea pentru aplicarea metodelor formale,
determina cel mai convenabil nivel de formalizare, cea mai convenabila metoda formala si instrumentele
metodelor formale. Obiectivele care sunt legate de metodele formale sunt de la producerea clara si
neambigua la verificarea mecanica a corectitudinii algoritmilor de baza sau a componentelor.
? Nivelul rigorii metodelor formale: Metodele formale pot fi aplicate la diverse nivele de rigoare.
Rigoarea se poate ierarhiza de la apartenenta unei notatii matematice sau a altor documente informale,
metode “riguroase” care utilizeaza limbaje de specificare standardizate, la metode “formale” care
utilizeaza verificari mecanice ale probarii teoremelor.
? Scopul utilizarii Metodelor Formale: Sunt trei dimensiuni ale scopului metodelor formale
? Stadiile ciclului d viata ale produsului(toate sau selectate)
? Componentele sistemului (toate sau selectate)
? Întreaga functionalitate sau parte a acestuia
? Tipul instrumentelor metodelor formale: alegerea instrumentelor metodelor formale, daca acestea
exista, vor fi determinate direct din evaluarea factorilor anterior enuntati. Cel mai important, însa, ramâne
tipul limbajului de specificare si necesitatea suportului probarii mecanice.
Abordarea sistemelor de dimensiune medie si mare necesita la rândul lor o abordare sistemica a
problematicii propuse. Deoarece descrierea cerintelor este de obicei informala se impune formalizarea
cerintelor, respectiv scrierea acestora sub forma de specificatii. Limbajele alese pentru aceasta noua forma
de redactare trebuie sa fie din domeniul Metodelor Formale, respectiv acestea pot sa fie scrise în limbaje
care accepta descrierile respective. Formalizarea cerintelor atrage dupa sine definirea si specificarea
comportamentului sistemului astfel modelat, ceea ce, prin intermediul editoarelor propuse prin abordarea
în Metode Formale poate fi verificat si controlat ca si corectitudine si coerenta, înca dintr-o faza initiala a
ciclului de viata. Ceea ce reduce substantial costurile cu rezolvarea ulterioara a defectelor care pot sa
apara.

35
Beneficiile Metodelor Formale pot fi:
? Caracteristica specificatiilor formale, de un înalt nivel al preciziei logice care elimina cele mai
multe ambiguitati ce se regasesc inevitabil în specificatiile informale. Aceasta precizie se translateaza
într-o fiabilitate ridicata pentru toti proiectantii de cerinte ale sistemului, si a cresterii gradului de
siguranta ca respectivele cerinte au fost corect implementate.
? Probarile formale elimina ambiguitatea si subiectivitatea provenind din analiza cerintelor prin
probarea si argumentarea precisa a comportamentului acestor cerinte.
? Utilizarea specificatiilor formale si a probarilor formale furnizeaza o abordare sistematica si
rentabila a analizelor.
? Specificatiile si probarile formale complementeaza abordarile actuale ale testarii, dar actioneaza si
în spatele a ceea ce este de testat.
Mecanismele formale care sunt de luat în considerare ca limbaje de specificare pot fi:
1. ACL2 probator de teoreme, dezvoltat de Computational Logic, Inc. Austin Texas
2. ADL (Algebric Design Language) Limbaj de specificare de nivel înalt bazat pe concepte algebrice,
dezvoltat de Oregon Graduate Institut
3. ASM (Abstract State Machines) realizeaza legatura dintre modelele formale de calcul si metodele
de specificare practica
4. CCS (Calculus of Communicating Systems) O algebra pentru specificarea sistemelor concurente
5. LOTOS (Language of Temporal Ordering Specificat ions) o tehnica formala pentru specificare,
care suporta limbajul de specificare ISLA (Interactive System for LOTOS Applications)
6. Petri Nets - O notatie formala grafica pentru modelarea sistemelor concurente. Suporta o suma de
instrumente de editare si verificare regasibile pe Petri Net Web.
7. PVS (Prototype Verification System) - Este un instrument bazat pe dezvoltarea logica de înalt
nivel.
8. SCR (Software Cost Reduction) este o metoda de descriere a cerintelor sistemului bazat pe o
notatie tabelara. Pentru aceasta au fost dezvoltate de catre Naval Researh Laboratory o suma de
instrumente.
9. SDL (Specification and Description Language) este un limbaj standardizat ITU pentru modelarea
sistemelor de comunicatie bazat pe formalismul unei masini de stare extinsa.
10. SMV una dintre metodele disponibile pentru verificarea formala a sistemelor concurente stare
finita.
11. SPIN este un instrument de verificare automata
12. VDM (Vienna Development Method) o metodologie completa de dezvoltare a software-ului
Fiecare dintre aceste produse se particularizeaza, fie pentru dimensiunea proiectului, fie pentru
faza din ciclul de viata al produsului la care poate fi optim aplicata.
Ceea ce se poate remarca este existenta editoarelor grafice, care permit preluarea si formalizarea
specificatiei cerintelor, cu translatare acestora în formalisme care pot fi verificate si probate automat.
Reducerea de efort, costuri si timp de proiectare prin utilizarea metodelor formale le face foarte
utile. Dezvoltarea însasi a metodelor formale, pentru cresterea performantelor de verificare si control pe
tot ciclul de viata al produsului, determina evolutia spectaculoasa a productiei de protocoale, din ce în ce
mai sofisticate, care sa acopere domenii ca e-business, e-commerce, în general a protocoalelor care
implica interactiunile dintre procese si interlucru dintre utilizatori.

2.4. PROCESUL UNIFICAT RELATIONAL (RUP)

RUP este un proces de inginerie software, disponibil prin web. Procesul intensifica
productivitatea echipei si livreaza practici verificate, prin ghiduri, sabloane si instrumente pentru toate
activitatile critice ale ciclului de viata ale produsului software. Baza de cunostinte permite dezvoltarea
echipei pentru a obtine beneficii complete prin utilizarea standardului UML.
RUP este un proces al ingineriei software. Acesta furnizeaza o abordare disciplinata care se refera
la signarea sarcinilor si responsabilitatilor în interiorul organizatiei pentru care se proiecteaza sistemul.
Scopurile acestuia sunt de a asigura productia unui software de înalta calitate care împlineste cerintele
utilizatorului final, tinând cont de bugete si de planificari.
RUP este un proces de productie, care asigura faptul ca procesul este actualizat permanent si
dezvoltat, reflectând astfel experientele actuale în domeniu.

36
 RUP creste productivitatea echipei prin furnizarea fiecarui membru la echipei accesul facil la o
baza de cunostinte cu ghidarile necesare, sabloanele si instrumentele aferente, pentru toate activitatile
critice pe tot parcursul ciclului de viata al produsului. Accesul fiecarui membru al echipei la permite
realizarea independentei relative la tipul activitatii: specificarea cerintelor, proiectul, specificarea si
realizarea testarilor, managementul proiectului sau managementul configurarii, în sensul asigurarii
partajarii din partea tuturor membrilor echipei a aceluiasi limbaj, proces si perspectiva asupra modului în
care se realizeaza dezvoltarea software. RUP creeaza si întretine modele, fiind orientat mai degraba pe
dezvoltarea si întretinerea semantica a acestora. RUP este un ghid eficient în utilizarea UML. Este
sustinut de instrumente care automatizeaza o parte mare a procesului. Instrumentele sunt utilizate pentru a
crea si întretine diferite modele ale procesului ingineriei software: modelarea vizuala, programare, testare
etc. RUP este, de asemenea, si un proces configurabil. Un proces singular nu poate fi convenabil pentru
toate dezvoltarile software. RUP este fundat pe o arhitectura simpla si clara a procesului care furnizeaza
partile comune peste o familie de procese. O alta particularitate a RUP este ca acesta capteaza multe din
practicile eficiente ale dezvoltarii moderne de software într-o forma care este convenabila pentru o gama
larga de procese si organizatii, ceea ce ofera echipei o suma de avantaje semnificative.
Una dintre problemele centrale ale RUP este definirea modalitatii în care se poate desfasura o
probare comerciala a dezvoltarii de software pentru echipa care realizeaza acest lucru. Aceasta se va numi
o practica eficienta nu numai pentru ca permite cuantificarea precisa a valorii sale dar si pentru ca s-a
observat utilizarea acesteia, foarte frecvent în practicile industriale, reflectate în succesul organizatiilor
pentru care s-a dezvoltat respectivul software. RUP furnizeaza fiecarui membru al echipei ghiduri,
sabloane si instrumente necesare întregii echipe de a obtine un avantaj (cel putin de timp si minimizare a
costurilor):
1. Dezvoltarea de software interactiv - Fiind date sistemele software sofisticate, care marcheaza
perioada actual, nu este posibil definirea initiala si secventiala a întregii probleme, a proiectarii solutiei
integrale, constructia software-ului si în consecinta a testarii produsului. O abordare iterativa se impune
pentru a permite o crestere continua a întelegerii problemei, în întreaga sa dimensiune, prin rafinari
succesive. Aceasta conduce la cresterea incrementala a solutiei efective de-a lungul mai multor iteratii.
RUP sustine o abordare iterativa care refera elementele cele mai expuse riscului pentru fiecare stadiu din
ciclul de viata, reducând astfel riscul proiectului în ansamblul lui. Aceasta abordare iterativa permite
abordarea riscului printr-un progres demonstrabil la nivelul versiunilor executabile care valideaza
implicarea utilizatorului final si feedb ack-ul acestuia. Deoarece fiecare iteratie se finalizeaza cu o
versiune executabila se poate urmari, din partea echipei încadrarea în bugete si planificari la fiecare
stadiu. O astfel de abordarea iterativa permite, de asemenea si acomodarea modificarilor tactice ale
cerintelor noilor caracteristici sau planificari.
2. Gestiunea cerintelor – RUP descrie modul în care se deduc, se organizeaza si se
documenteaza functionalitatile si restrictiile cerute; traseaza si documenteaza optimizarile si deciziile
permitând o captare simpla si eficienta a cerintelor procesului economic. Notiunea de use case si scenarii
interzise procesului a probat a fi o cale foarte buna pentru a capta cerintele functionale si de a asigura ca
acestea conduc proiectul, implementarea si testarea software-ului, asigurând astfel o mai buna finalizare
cu îndeplinirea cât mai apropiata a necesitatilor utilizatorului final. Furnizeaza, de asemenea tratamente
coerente si trasabile atât pentru dezvoltarea sistemului cât si pentru livrarea acestuia.
3. Utilizarea de arhitecturi bazate pe componente – procesul orientat pe dezvoltarea initiala si
bazat pe o arhitectura robusta, executabila care este si flexibila, adapteaza modificarile, devine intuitiv
inteligibil si permite mai multe reutilizari ale componentelor software. Componentele sunt module
netriviale, subsisteme care îndeplinesc o functionalitatea clara. RUP furnizeaza o abordare sistematica
pentru definirea unei arhitecturi care sa utilizeze atât componente noi cât si componentele existente.
Acestea sunt asamblate într-o arhitectura bine definita, fie de o maniera strict particulara fie în interiorul
unei infrastructuri date: Internet, CORBA, COM, pentru care este definita reutilizarea industriala a
componentelor.
4. Modelarea vizuala a software-ului – sunt considerate modalitatile în care modelul vizual
capteaza structura si comportamentul arhitecturilor si a componentelor. Aceasta permite mascarea
detaliilor si scrierea de cod prin utilizarea “graphical building code”. Abstractizarile vizuale sprijina
comunicarea diferitelor aspecte ale software-ului: modul în care se “potrivesc” componentele sistemului,
asigurarea consistentei “building block” cu codul, pastrarea consistentei între proiect si implementare si
asigurarea unei comunicatii neambigue. UM L este fundamentul unei astfel de modelari vizuale.
5. Verificarea calitatii software-ului – Aplicatiile cu o performanta si fiabilitate scazuta
reprezinta experiente care blocheaza dramatic acceptabilitatea aplicatiilor software. În aceste conditii

37
calitate a trebuie revizuita tinând cont de cerintele bazate pe fiabilitate, functionalitate, performantele
aplicatiei si ale sistemului în totalitate. RUP poate deveni astfel, fundamentul planificarii, proiectarii,
implementarii executiei si evaluarii acestor tipuri de teste. Evaluarea calitatii este construita în interiorul
procesului, în toate activitatile, implicând toti participantii, utilizând criterii si masuratori obiective.
Acestea nu sunt tratate postfactum sau ca activitati separate de catre un grup separat de echipa care
realizeaza sistemul.
6. Modificarile controlului – Abilitatea de a gestiona modificarea, face demonstrabila
acceptabilitatea acesteia si permite trasarea modificarilor, ceea ce este esential într-un mediu în care
modificarile sunt inevitabile. Procesul descrie modul în care se realizeaza controlul, trasa si monitorizarea
modificarii pentru a valida succesul dezvoltarii iterative. Este si un ghid în stabilirea cerintelor de
securizare a spatiului de lucru pentru fiecare membrul al echipei prin izolarea relativa la modificarile care
se produc în alte spatii de lucru si prin controlul modificarilor pentru toate componentele software-ului
(modele, coduri, documente, etc.). Este, de asemenea, un sprijin real pentru integrarea membrilor echipei
care pot lucra astfel ca o echipa unica, prin descrierea modului în care se automatizeaza integrarea si se
construieste managementul.
Privire generala asupra procesului
Procesele pot fi descrie într-un sistem bidimensional (doua axe):
- axa orizontala reprezinta componenta temporala si caracterizeaza aspectele dinamice ale
proceselor. Axa orizontala este exprimata în termeni de cicluri, faze, iteratii sau borne;
- axa verticala reprezinta aspectele statice ale proceselor, fiind descrisa în termeni de activitati,
fluxuri, sau produse.
Dimensiune temporala, caracterizata prin faze si iteratii este organizarea dinamica a procesului de-a
lungul timpului, ciclul de viata al software-ului este “spart” în cicluri care activeaza asupra unei generatii
noi a produsului. Un ciclu de dezvoltare a produsului, la rândul sau, este divizat în patru faze consecutive:
- faza incipienta
- faza de elaborare
- faza de constructie
- faza de tranzitie
fiecare faza se concluzioneaza cu o borna – un moment temporal la care anumite decizii critice trebuie sa
aiba loc, ca urmare a îndeplinirii scopurilor cheie.

Faza incipienta -

Pe parcursul fazei incipiente, se vor stabili cazurile proceselor economice ale sistemului si se va
delimita domeniul proiectului. Pentru a acoperi aceasta trebuie identificate entitatile externe cu care
sistemul va interactiona (actorii) si definirea naturii acestor interactiuni pe nivelul înalt. Acesta implica
identificarea tuturor use case si descrierea celor mai putin semnificative. Cazurile proceselor economice
vor include criterii de succes, evaluarea riscurilor si estimarea resurselor necesare, precum si o planificare
a fazei cu vizualizarea datelor legate de bornele temporale majore. Iesirile din faza incipienta sunt:
- un document al perspectivei: o perspectiva generala asupra cerintelor fundamentale ale proiectului,
caracteristicile cheie si restrictiile mai importante;
- un model use case initial (completat 10-20%);
- un glosar al proiectului initial (care poate fi exprimat partial ca un model de domeniu);
- un caz de proces economic initial, care include contextul procesului economic, criteriile de succes
(proiectarea veniturilor, recunoasterea pietii, etc.) si proiectiile financiare;
- evaluarea initiala a riscului;
- un plan al proiectului, cu prezentarea fazelor si a iteratiilor;
- un model al procesului economic, daca acesta este necesar;
- unul sau mai multe prototipuri;

Borna: obiectivele ciclului de viata

La finele fazei incipiente apare prima borna semnificativa a proiectului: borna obiectivelor
ciclului de viata. Criteriile de evaluare pentru faza incipienta sunt:
- concurenta pretendentilor pe definitia domeniului si estimarea costului / planificarii;
- întelegerea cerintelor ca evidentiata prin fidelitatea primului use case;
- credibilitatea estimarii cost / planificare, prioritati riscuri si procesul de dezvoltare;

38
 - adâncimea si latimea unui prototip arhitectural care a fost realizat;
- compararea cheltuielilor actuale cu cheltuielile planificate;
Proiectul poate fi eliminat sau semnificativ regândit daca nu va trece aceasta borna.

Faza de elaborare

Scopul fazei de elaborare este de a analiza problema domeniului, de a stabili o fundamentare

arhitecturala de buna calitate, de a dezvolta planul proiectului si de a elimina elementele cu risc ridicat din
proiect. Pentru a îndeplini aceste obiective, trebuie sa se dispuna de o perspectiva globala a sistemului.
Deciziile arhitecturale trebuie luate tinând cont de întelegerea întregului sistem: domeniul,
functionalitatile majore si cerintele nefunctionale cum ar fi cerintele de performanta.
Este relativ simpla argumentarea ca faza de elaborare este cea mai critica dintre cele patru faze.
La finele acestei faze partea “grea” a ingineriei este considerata ca fiind completata si proiectul a suportat
cele mai importante momente de evaluare: decizia a ceea ce se va trece fazelor de constructie si respectiv
de tranzitie. Pentru cele mai multe proiecte aceasta corespunde unei tranzitii de la o operatie mobila, clara
si elastica la una cu costuri si riscuri ridicate, care este marcata de o mare inertie. Deoarece procesul
trebuie sa se adapteze modificarilor, activitatile fazei de elaborare asigura ca arhitectura, cerintele si
planurile sunt suficient de stabile si ca riscurile sunt suficient de atenuate, astfel încât se poate determina
predictib ilitatea costurilor si a planificarii pentru finalizarea dezvoltarii. Conceptual, nivelul de fidelitate
trebuie sa corespunda nivelului necesar unei organizatii sa-si asume un cost fix pentru faza de constructie.
În faza de elaborare, se va construi un prototip arhitectural executabil, într-o sau mai multe iteratii fiind
dependent de domeniul, dimensiunea, riscul si noutatea proiectului. Acest efort trebuie sa refere cel putin
use case critic identificat în faza incipienta, care în mod uzual, expune riscurile tehnice majore ale
proiectului. Deoarece scopul principal este un prototip de dezvoltare a producerii unei componente de
calitate, aceasta nu exclude necesitatea unuia sau mai multor prototipuri exploratorii care sa minimizeze
riscurile specifice cum ar fi: optimizarea proiectului / cerintelor, studiul de fezabilitate al componentei sau
demonstratiile catre investitori, clienti si utilizatorii finali. Iesirile din faza de elaborare sunt:
- Un model use case (cel putin 80% completat). Toate use case si actorii au fost identificati si cele
mai multe descrieri ale use case au fost realizate.
- Captarea cerintelor suplimentare, cerintele nefunctionale si orice cerinta care nu este asociata cu
un use case specific.
- O descriere a arhitecturii software.
- Un prototip arhitectural executabil.
- O lista revizuita a riscului si o procesul economic revizuit.
- Un plan de dezvoltare pentru ansamblul proiectului, incluzând planul de proiect fundament-
rafinat, cu prezentarea iteratiilor si a criteriilor de evaluare pentru fiecare iteratie.
- Un caz de dezvoltare actualizat care specifica procesul care va fi utilizat.
- Un manual al utilizatorului, preliminar (optional).

Borna: arhitectura ciclului de viata

La finele fazei de elaborare apare cea de a doua borna semnificativa: arhitectura ciclului de viata.
La acest punct se vor examina, în detaliu, obiectivele sistemului si domeniul, alegerea arhitecturii si
rezolutia riscurilor majore. Principalele criterii de evaluare pentru faza de elaborare implica raspunsul la
aceste probleme:
- daca viziunea proiectului este stabila;
- daca arhitectura este stabila;
- daca demonstratia executabila prezinta elementele de risc majore ca fiind referite si rezolvate
credibil;
- planul este suficient de detaliat si cu acuratete pregatit pentru faza de constructie. Daca este verificat
cu o baza a estimarii credibila;
- daca toti pretendentii sunt de acord ca actuala viziune este realizabila, pentru cazul în care se va
executa planul curent pentru a dezvolta întreg sistemul, în contextul actualei arhitecturi;
- cos turile cu resursa actuale sunt acceptabile relativ la costurile planificate.
Proiectul va fi abordat sau semnificativ regândit pentru cazul în care va esua la trecerea acestei borne.

39
Faza de constructie

Pe parcursul fazei de constructie se vor dezvolta toate componentele ramase si toate

caracteristicile aplicatiilor. Acestea vor fi integrate în produs si toate caracteristicile vor fi testate în
consecinta. Faza de constructie este, într-un anume sens, un proces de producere în care accentul se va
plasa pe managementul resurselor si controlul operatiilor pentru a optimiza costurile, planificarile si
calitatea. În acest sens, semnificatia managementului va suferi o tranzitie de la dezvoltarea unei
proprietati intelectuale, în fazele: incipienta si elaborare, catre dezvoltarea de produse pe parcursul fazelor
de constructie si tranzitie. Multe proiecte sunt destul de mari ca sa necesite constructii paralele. Aceste
activitati paralele pot sa accelereze semnificativ disponibilitatea versiunilor; pot de asemenea sa creasca
complexitatea managementului resurselor si sincronizarea fluxurilor de activitati. O arhitectura robusta si
un plan inteligibil vor fi puternic corelate. Una dintre calitatile critice ale unei arhitecturi este
simplicitatea pe care o ofera cons tructiei. Aceasta este una dintre ratiunile care conditioneaza si
echilibreaza dezvoltarea arhitecturii si a planului în faza de elaborare. Iesirile din faza de constructie sunt
legate de un produs disponibil utilizatorului final. Minimal acesta va consta din:
- produsul software integrat într-o platforma adecvata
- manualul de utilizare
- descrierea versiunii curente

Borna capabilitatile operationale initiale

La finele fazei de constructie apare ea de a treia borna majora. La acest punct, se va decide daca
software-ul, site-urile si utilizatorii sunt pregatiti pentru a deveni operationali fara a expune proiectul unui
risc prea mare. Aceasta versiune este de obicei denumita versiunea beta. Criteriile de evaluare pentru faza
de constructie implica raspunsul la urmatoarele întrebari:
- daca versiunea produsului este stabila si suficient de matura pentru a fi desfasurata în comunitatea
utilizatorilor;
- daca toti pretendentii sunt pregatiti pentru a tranzita în comunitatea utilizatorilor;
- daca actualele costuri cu resursele sunt acceptabile relativ la costurile planificate.
Tranzitia poate fi amânata pentru o versiune, în cazul în care proiectul esueaza la aceasta borna.

Faza de tranzitie

Scopul fazei de tranzitie este de a tranzita produsul software catre comunitatea utilizatorilor.
Odata ce produsul a ajuns la utilizatorul final apar probleme noi care determina realizarea unei noi
versiuni, cu corectarea unor probleme sau finalizarea unor caracteristici care au fost amânate. Faza de
tranzitie este abordata atunci când linia de baza este destul de matura pentru a fi desfasurata în domeniul
utilizatorului final. Acesta cere, în mod normal, ca anumite parti ale sistemului au fost finalizate la un
nivel acceptabil al calitatii si ca exista disponibila documentatia pentru utilizator astfel încât tranzitia catre
utilizator va determina rezultate pozitive pentru toti partenerii. Aceasta include:
- testarea versiunii beta pentru a valida noul sistem relativ la asteptarile utilizator;
- operatiile paralele cu sistemul în functiune, pe care îl înlocuieste;
- conversia bazelor de date operationale;
- training pentru utilizatori si responsabilii cu întretinerea sistemului;
- scoaterea produsului în piata, distributia si echipa de vânzari;
Faza de tranzitie se caleaza pe activitatile cerute pentru a plasa software-ul în mâinile
utilizatorului. În mod tipic, aceasta faza include mai multe iteratii care include versiunea beta, versiunile
general disponibile, precum si versiunile de fixare a bug-urilor si a accentuarilor. Se va depune un efort
considerabil pentru a realiza documentatia catre client, pentru educarea utilizatorilor relativ la produs,
pentru sustinerea utilizatorilor în utilizarea initiala a produsului si pentru a asigura reactia la feedback-ul
clientilor. La acest punct din ciclul de viata, feedback-ul utilizator trebuie sa fie delimitat la problemele de
reglare a performantei, configurare, instalare si uzabilitate.
Obiectivele primare ale fazei de tranzitie includ:
- realizarea auto-sustinerii utilizatorului;
- realizarea concurentelor pretendentilor relative la faptul ca desfasurarea liniei de baza este
completa si consistenta cu criteriile de evaluare ale viziunii;
- realizarea liniei de baza a produsului rapid si cu costuri rezonabile care sa-l faca înca practic.

40
 Aceasta faza poate fi de la foarte simpla la foarte complexa, fiind dependenta de tipul de produs.

Borna versiunea produsului

La finele fazei de tranzitie apare cea de a patra borna semnificativa a proiectului. La acest punct,
se va decide daca obiectivele sunt atinse si daca trebuie demarat un nou ciclu de dezvoltare. În anumite
cazuri, aceasta borna poate coincide cu finele fazei incipiente pentru urmatorul ciclu. Criteriile de
evaluare primara pentru faza de tranzitie implica raspunsul la urmatoarele întrebari:
- exista satisfactie la nivelul utilizatorului;
- costurile cu resursele sunt acceptabile relativ la costurile planificate.
Fiecare faza poate fi “sparta” în iteratii. O iteratie este o bucla completa de dezvoltare dintr-o
versiune (interna sau externa) a unui produs executabil, a unei parti a produsului final aflat în dezvoltare
care creste incremental din iteratie în iteratie pentru a deveni sistem final.
Beneficiile unei abordari iterative:
- riscurile sunt evaluate si minimizate de timpuriu;
- modificarile sunt mult mai gestionabile;
- ofera un grad ridicat de reutilizabilitate;
- echipa proiectului se poate documenta pe parcurs;
- o calitate globala mai buna.
Structura statica a procesului
Un proces descrie: cine va realiza, ce, cum si când. RUP este reprezentat utilizând primele patru elemente
ale modelarii:
- worker – cine
- activitati - cum
- produse - ce
- workfows - când
Worker – defineste comportamentul si responsabilitatile unui individ sau a unui grup de indivizi care
lucreaza împreuna ca o echipa. Un worker poate fi privit ca un manson pe care un individ îl uzeaza în
cadrul proiectului. Un individ poate uza mai multe astfel de mansoane. Aceasta este o distinctie
importanta, deoarece este natural sa se gândeasca despre un worker ca despre un individ sau echipa însasi,
dar pentru RUP worker-ul este mai mult legat de rolul de definire a modului în care indivizii îsi pot
finaliza treaba. Responsabilitatile care se asigneaza worker-ilor include atât realizarea unei multimi de
activitati precum si faptul de a deveni proprietarii unei multimi de produse.
Activitati – O activitate a unui worker specific este o unitate de lucru pe care un individ având asignat un
astfel de rol poate pretinde sa o realizeze. Activitatea are un scop clar, exprimat uzual în termeni de creare
sau actualizare anumite produse, cum ar fi: modele, clase, planuri etc. Fiecare activitate este asignata unui
worker specific. Granularitatea activitatii este plasata, în general, de la câteva ore la câteva zile si implica,
uzual, un worker si afecteaza unul sau un numar mic de produse. O activitate trebuie sa fie utilizabila ca
un element de planificare si progres în sirul de activitati. Daca aceasta este prea mica, poate fi neglijata,
daca este prea mare progresul va fi exprimat în termeni de parti ale unei activitati. Exemple de activitati:
- plan si iteratii – worker: managerul de proiect;
- gasirea de use case si actori – worker: analistul de sistem;
- revizuirea proiectului – worker: proiectantul (specializat în revizuiri);
- executarea testului de performanta – worker – testerul de performanta.
Produse - Un produs este o piesa de informatie care este produsa, modificata sau utilizata de catre un
proces. Produsele sunt produse tangibile ale proiectului, lucrurile pe care proiectul le produce sau le
utilizeaza pâna se realizeaza produsul final. Produsele sunt utilizate ca intrare de catre worker pentru a
realiza o activitate si sunt rezultatul sau iesirea din astfel de activitati. În termeni de proiectare orientata
obiect, activitatile devin operatii care se manifesta asupra unui obiect activ (worker), produsele sunt
parametrii ai acestor activitati. Produsele pot îmbraca diferite forme si aspecte:
- un model – modelul use case sau modelul proiectului;
- un element de model – un element dintr-un model, cum ar fi o clasa, un use cas e sau un subsistem;
- un document – cum ar fi cazul procesului economic sau documentul arhitecturii software;
- un cod sursa;
- executabile.

41
Workflows - O simpla enumerare a tuturor workflow -urilor pentru toti worker-ii, activitatile si produsele
nu constituie înca un proces. Este necesara o cale pentru a descrie semnificatia secventelor de activitati
care produc anumite rezultate evaluabile si o prezentare a interactiunilor dintre worker-i. Un workflow
este o secventa de activitati care produc un rezultat cu valoare observabila. În termeni UML, un workflow
poate fi exprimat ca o secventa de diagrame, o diagrama de colaborare sau o diagrama de activitate. A se
nota ca nu este totdeauna posibil sau practic sa se reprezinte toate dependentele dintre activitati. De cele
mai multe ori doua activitati sunt tare întretesute decât pare la prima vedere, mai ales atunci când acestea
implica un acelasi worker sau individ. Oamenii nu sunt masini, iar workflow -ul nu poate fi interpretat ad -
literam ca un program pentru oameni, care sa fie urmat exact si mecanic.
Cele mai importante tipuri de workflow dintr-un proces, numite workflow-urile din nucleu. În
RUP sunt definite noua astfel de workflow, care reprezinta o partitionare a tuturor worker-ilor si
activitatilor într-o grupare logica:
Workflow ale ingineriei:
1. workflow pentru modelarea procesului economic
2. worflow pentru cerinte
3. workflow pentru analiza si proiectare
4. workflow pentru implementare
5. workflow pentru test
6. workflow pentru desfasurare
Workflow pentru sustinere
1. workflow pentru managementul proiectului
2. workflow pentru configurare si managementul modificarilor
3. workflow pentru mediu
De altfel, numele celor sase workflow pentru inginerie evoca fazele secventiale dintr-un proces
cascada, traditional. Totusi, trebuie sa nu se omita faptul ca fazele unui proces iterativ sunt diferite si ca
aceste workflow -uri sunt revizitate înca si înca în timpul ciclului de viata. Workflow complet al unui
proiect întretese aceste noua workflow ale nucleului si le repeta cu diferite accentuari si intensitati la
fiecare iteratie.
Modelarea procesului economic
Una dintre problemele majore care refera cele mai multe dintre eforturile ingineriei economice, este dat
de faptul ca ingineria economica si comunitatea economica nu comunica limpede între ele. Aceasta
conduce la faptul, de altfel regretabil, ca iesirile din ingineria procesului economic nu este utilizat, în sine,
ca intrare în efortul de dezvoltare a software-ului, reciproce fiind si ea din pacate adevarata. RUP refera
aceasta prin furnizarea unui limbaj comun si procesul pentru ambele comunitati, astfel încât sa fie
posibila creare si întretinerea directa a trasabilitatii între modelele software si cele economice.
În probleme modelului procesului economic se va documenta procesul utilizând asa numitul use
case al procesului economic. Acesta presupune o întelegere comuna peste toti pretendentii pe care
procesul economic îi va sustine în organizatie. Use case-ul procesului economic este analizat pentru a
întelege modul în care procesul economic trebuie sa sustina activitatea. Aceasta este documentata într-un
model obiect al procesului economic. Multe proiecte omit partea de modelare a procesului economic, dar
aceasta devine extrem de importanta având în vedere rata mare de esecuri pe care sistem ele
informationale le au la implementarea directa, fara a mai aminti de depasirile de bugete si timp.
Cerinte
Scopul workflow pentru cerinte este de a descrie ce anume trebuie sa faca sistemul si sa permita celor
care dezvolta sistemul si clientilor sa cada de acord asupra unei descrieri. Pentru a realiza aceasta se va
deduce, se va organiza si documenta cerinta de functionalitate si restrictiile. În acest sens se va crea un
document Vision si vor fi dedusi pretendentii necesari. Sunt identificati actorii, care reprezinta utilizatorii
si orice alt sistem care va interactiona cu sistemul ce se dezvolta. Sunt identificate, de asemenea si use
case-urile. Acestea reprezinta comportamentul sistemului. Deoarece use case-urile sunt dezvoltate în
concordanta cu necesitatile actorilor, sistemul devine cu atât mai relevant pentru utilizator. În figura de
mai jos este prezentat un mode use-case reciclarea unei masini în sistem.

42
 Fiecare use case este descris în detaliu. Descrierea use case prezinta modul în care sistemul
interactioneaza, pas cu pas cu actorii si ceea ce executa sistemul. Cerintele nefunctionale sunt descrise în
documentul de specificatii suplimentare. Use case functioneaza ca un tratament unificator pe ciclul
dezvoltarii sistemului. Acelasi use case este utilizat pe parcursul captarii cerintelor, analizei si proiectarii
si a testarii.
Analiza si proiectarea
Scopul workflow pentru analiza si proiectare este de a prezenta modul în care va fi realizat sistemul în
faza de implementare. Se va construi astfel un sistem care:
- realizeaza - într-un mediu de implementare specific – sarcinile si functiile specificate de use case a
utilizatorului;
- corespunde tuturor cerintelor;
- este structurat pentru a fi robust (simplu de modificat daca si când cerintele sale functionale se
schimba).
Analiza si proiectarea rezulta într-un model de proiect si optional într-un model de analiza.
Modelul de proiect serveste ca o abstractizare a codului sursa. Modelul de proiect actioneaza ca un plan
de detaliu relativ la modul în care este scris si structurat codul sursa.
Modelul de proiect consta din proiectul claselor structurat în pachetele proiectului si subsistemele
proiectului cu interfete bine definite reprezentând ceea ce vor deveni componente în implementare.
Contine, de asemenea, descrierea modului în care obiectele acestor clase de proiect colaboreaza pentru a
realiza use case. Figura de mai jos exemplifica o parte din modelul de proiect pentru use case din
exemplul anterior.

Proiectarea activitatilor este centrat pe notiunea de arhitectura. Productia si validarea acestei

arhitecturi este plasata, cu precadere, în fazele initiale ale iteratiilor. Arhitectura este reprezentata printr-
un numar de perspective arhitecturale. Aceste perspective capteaza deciziile structurate majore. În esenta,
perspectivele arhitecturale sunt abstractizari sau simplificari ale proiectului în totalitatea sa, în care
caracteristicile importante sunt scoase în evidenta prin înlaturarea detaliilor nesemnificative. Arhitectura
este un vehicul important nu numai pentru dezvoltarea unui model de proiect bun dar si pentru cresterea
calitatii oricarui model construit pe parcursul dezvoltarii sistemului.
Implementare
Scopul implementarii este:
- de a defini organizarea codului, în termeni de subsisteme de implementare organizate în nivele;
- de a implementa clasele si obiectele, în termeni de componente (fisiere sursa, binare, executabile
sau alte);
- de a testa dezvoltarea componentelor ca unitati;
- de a integra rezultatele produse prin implementatori ind ividuali (sau echipe) într-un sistem
executabil.
Sistemul este realizat prin implementarea componentelor. RUP descrie modul în care se pot
reutiliza componentele existente, sau în care se pot implementa componente noi cu responsabilitati bine
definite, ceea ce face sistemul mai simplu de întretinut, si aduce o crestere semnificativa a posibilitatilor
de reutilizare a componentelor.
Componentele sunt structurate în implementarea subsistemelor. Subsistemele iau forma
directoarelor, cu structuralitate si eventual management informational suplimentar (ex. un director sau un
folder într-un fisier sistem).
Testul
Scopul testarii este:
- de a verifica interactiunea dintre obiecte;
- de a verifica integrarea corecta a tuturor componentelor software;
- de a verifica faptul ca toate cerintele au fost corect implementate
- de a identifica defectele si de a asigura referirea lor înainte de a se realiza desfasurarea software.

43
 RUP propune o abordare iterativa, ceea ce semnifica testarea peste tot si tot timpul a proiectului.
Aceasta permite detectarea defectelor înca din primele faze, ceea ce reduce radical costul fixarii
defectelor. Testul este realizat pe trei dimensiuni ale calitatii: fiabilitate, functionalitate, performantele
aplicatiei si ale sistemului. Pentru fiecare dintre aceste dimensiuni ale calitatii, procesul descrie modul în
care se parcurg ciclurile testarii: planificarea, proiectarea, implementarea, executia si evaluarea. Sunt
descrise, de asemenea, strategii pentru automatizarea testului. Automatizarea testului este în special
importanta cu utilizarea unei abordari iterative, care permit testare de regresie la finele fiecarei iteratii,
precum si pentru fiecare versiune noua a produsului.
Desfasurare
Scopul workflow pentru desfasurare este de a produce versiuni ale produsului de succes si de a livra
software-ul la utilizatorul final. Aceasta acopera o gama larga de activitati care includ:
- producerea versiunii externe a software-ului;
- distribuirea software-ului;
- instalarea software-ului;
- furnizarea de help-uri si asistenta la utilizatorul final.
În multe cazuri mai sunt incluse activitati ca:
- planificarea si controlul testelor versiunilor beta;
- migrarea software-ului existent sau a datelor;
- acceptanta formala.
Cu toate ca activitatile de desfasurare sunt puternic centrate pe faza de tranzitie, multe dintre
acestea se vor include necesarmente în fazele initiale pentru a putea fi pregatite la finele fazei de
constructie. Workflow pentru desfasurare si pentru mediu contin mai putine detalii ca alte workflow.
Managementul proiectului
Managementul proiectului software va trebui sa realizeze un echilibru între obiective, managementul
riscului si restrictii, pentru a livra un produs de succes care sa satisfaca necesitatile atât a consumatorilor
(cei care platesc facturile) cât si a utilizatorilor. Faptul ca foarte putine proiecte sunt succese de
necontestat este o masura a dificultatii acestei sarcini.
Acest workflow este orientat în principal pe aspectele specifice ale unui proces de dezvoltare
iterativ. Scopul este de face mai simpla sarcina (care este si asa destul de grea) prin furnizarea:
- unui cadru pentru managementul proiectelor software;
- ghiduri practice pentru planificarea, executarea, monitorizarea si realizarea echipelor proiectului;
- un cadru pentru managementul risculu i.
Evident cadrele furnizate managementul proiectului nu se poate constitui într-o reteta a
succesului, dar prezinta o abordare realista a managementului proiectului.
Managementul configurarii si modificarii
Acest workflow descrie modul în care se realizeaza controlul numeroaselor produse, produse de mai
multa lume care lucreaza la un proiect comun. Controlul sprijina evitarea confuziilor costisitoare si
asigura ca produsele rezultate nu sunt în conflict generat de urmatoarele tipuri de probleme:
- actualizar i simultane – daca doi sau mai multi worker -i lucreaza separat la acelasi produs, cel de al
doilea poate distruge rezultatul primului;
- limitarea notificarilor – apare atunci când o problema este fixata într-un produs partajat de mai multi
producatori si pentru o parte dintre acestia nu se notifica modificarea;
- versiuni multiple – programele foarte mari sunt dezvoltate în versiuni evolutive. O versiune poate fu în
uzul clientului, pe când o alta este în test, iar o a treia este înca în curs de producere. Daca problema este
descoperita în oricare dintre versiuni, fixarea acesteia necesita propagarea în toate versiunile existente.
Pot apare confuzii legate de fixarile costisitoare si de reluarea acestora fara ca modificarile sa fie
controlate si monitorizate.
Acest workflow furnizeaza ghidul pentru gestiunea variantelor multiple ale evolutiei sistemului
software, cu tarsarea pentru versiunile utilizate într-o constructie software, realizarea constructiei
programelor individuale sau a întregii versiuni concordant cu specificatiile versiunii definite de utilizator
si presând politici de dezvoltare specifice site-ului. Se descrie modul în care se pot gestiona dezvoltari
paralele, dezvoltari realizate pe site-uri multiple, precum si a modului în care se automatizeaza procesul
de constructie. Aceasta este foarte important într-un proces iterativ în care se doreste o constructie rapida,
care nu poate fi îndeplinita în afara unui mecanism puternic de automatizare. Acest workflow contine de
asemenea modul în care se realizeaza raportarea defectelor, gestiunea acestora în întreg ciclul de viata,
precum si modul în care se utilizeaza defectele pentru a realiza tendintele.

44
Mediul
Scopul workflow pentru mediu este de a furniza organizarea dezvoltarii de software într-un mediu de
dezvoltare software – atât din punct de vedere al proceselor, cât si din punct de vedere al instrumentelor –
care este necesar sa sustina echipa de dezvoltare. Acest workflow se orienteaza asupra activitatilor de
configurare a procesului în contextul proiectului. Este de asemenea orientata pe activitatile de dezvoltare
a ghidurilor necesare sustinerii proiectului. Este furnizata o procedura pas cu pas pentru a descrie modul
în care este implementat un proces într-o organizatie. Workflow –ul de mediu contine de asemenea un kit
de dezvoltare care furnizeaza ghiduri, sabloane si instrumente necesare la personalizarea procesului.
Anumite aspecte ale workflow-ului de mediu nu sunt acoperite în proces. Astfel de exemple pot fi:
selectarea, achizitia si functio nalizarea instrumentelor precum si un mecanism de întretinere a evolutiei
mediului în sine.

2.5. DESPRE LIMBAJUL DE MODELARE UNIFICAT (UML)

Analiza si proiectarea OO este una dintre cele mai populare metode de modelare. UML a fost
propus pentru a deveni standard de limbaj pentru exprimarea proiectelor OO. Din nefericire, în forma
actuala a UML este opac definirilor semantice precise. Semnificatia acestei afirmatii consta în aceea ca
este dificil de decis asupra consistentei proiectului, asupra corectitudinii modificarii proiectului si
respectiv a faptului ca un program implementeaza corect un proiect.
Metodele formale furnizeaza rigoarea care este lipsa în notatiile OO. Aceste clauze conduc de
cele mai multe ori la lipsa claritatii expunerii, catre nespecialisti. Metodele formale sunt legate de
utilizarea tehnicilor matematice pentru a permite dezvoltarii activitatii software a fi precis definita si în
final automatizata. În acest paragraf se va prezenta o privire generala asupra activitatii depuse pentru
furnizarea unui (subset) UML cu semantici formale. Semanticile vor facilita utilizarea UML în procesul
de dezvoltare de software prin permisivitatea pasilor de proiectare care sunt definiti si verificati.
Introducere
UML este un limbaj pentru modelarea sistemelor obiect bazat pe unificarea metodelor OO a lui Booch,
Rumbaugh si Jacobson, cele mai populare metode de modelare. Este un standard de facto pentru
modelarea de astfel de sisteme. UML asigura mai multe tehnici de modelare diagramatica, regasite în cele
mai multe metode obiect actuale, cum ar fi diagramele obiect, diagramele de stare si diagramele de
interactiune a obiectelor. Scopul UML este de a furniza un limbaj conformant, standardizat, care poate fi
utilizat în locul excesului de notatii, diagrame si a altor conventii de prezentare care au aparut în domeniul
metodelor OO si structurate actuale.
Exista mai multe ratiuni care pot credita faptul ca UML îsi va sustine propriul scop, furnizând
astfel o notatie unificata pentru OO. În acest sens deja exista semnale clare: cei mai multi furnizori de
CASE deja si-au restructurat instrumentele pentru a sustine UML, în timp ce cea mai mare parte a
literaturii relativa la OO actuala încearca sa devina conforma cu UML. Suplimentar, UML a fost supus
recent ca un candidat pentru OMG, ceea ce duce la acceptarea acestuia.
Unul dintre aspectele interesante ale UM este recunoasterea din partea autorilor sai a necesitatii
furnizarii unei descrieri precise a semanticilor. Una dintre abordarile cu cele mai mari sanse de succes
pentru descrierea acestor semantici este de a da un metamodel pentru UML. Deci, notatiile UML sunt
utilizate pentru a descrie semanticile UML. Pentru moment metamodelul UML contine cinci concepte
fundamentale: conceptele comune (tipurile de baza), elementele structurale (tipuri si relatii), elementele
de comportament (masini de stare si interactiuni), elemente de vizualizare si elemente standard.
UML este un limbaj de specificare, vizualizare, constructie si documentare a produselor rezultate pentru
un proces din cadrul unui sistem complex:
- în interiorul sistemului se va aplica o metoda ca un proces de derivare sau dezvoltarea a sistemului;
- ca limbaj este utilizat pentru comunicatie, ceea ce înseamna a capta cunostintele (semanticile)
relative la un subiect si a exprima cunostintele (sintaxa) relative la respectivul subiect pentru scopuri de
comunicatie. Subiectul este de apt sistemul în discutie;
- ca limbaj de modelare este orientat pe întelegerea unui subiect prin formularea modelului subiectului
(si a contextului relationat acestuia). Modelul înglobeaza cunostinte relative la subiect si a aplicatiilor
adecvate acestor cunostinte;
- cu privirea la unificare, acesta unifica cele mai bune practici ale TI si SI peste mai multe tipuri de
sisteme (software sau non-software), domenii (procese economice versus software) si procese ale ciclului
de viata;

45
 - la aplicarea pentru specificarea sistemului, poate comunica ceea ce este cerut de la acesta, precum si
a modului în care sistemul poate fi realizat sau implementat;
- la aplicarea pentru vizualizarea sistemului, este utilizat pentru vizualizarea descrierii sistemului
înainte de realizarea acestuia;
- la aplicarea la construirea sistemului poate fi utilizat pentru conducerea realizarii sistemului similar
cu “blueprint”;
- la utilizarea pentru documentarea sistemului, acesta poate fi folosit pentru captarea cunostintelor pe
parcursul ciclului de viata.
UML nu este:
- un limbaj de programare vizual, dar este un limbaj de modelare vizual;
- specificare instrumentului sau depozit ului dat este specificarea limbajului de modelare;
- un proces, dar valideaza procese.
Prin recunoasterea importantei formalismului, autorii UML au facut deja un pas revolutionar catre
viitor, deoarece niciodata anterior rigoarea nu a jucat un asa mare rol în dezvoltarea unei metode de
modelare sau a unui limbaj comercial. Nu numai ca utilizarea semanticilor este acceptata si utilizata ca o
consecinta, dar, mai mult, se încurajeaza astfel de descrieri ca parte a tuturor metodelor de dezvoltare. Un
alt avantaj a furnizarii UML cu descrieri formale este ca acesta poate da baza pentru introducerea si a
altor verificari si tehnici de validare care anterior erau un apanaj numai al specificatiilor formale ca Z sau
VDM. Exista mai multe cai prin care UML poate sa beneficieze de rezultatele fundamentelor formale:
- claritatea: a actiona ca o referinta – daca într-un punct oarecare exista o confuzie relativa la
semnificatia exacta a unei componente particulare a UML, se poate realiza o referinta catre descrierea
formala pentru a verifica semanticile;
- echivalenta si consistenta – pentru a furniza o baza neambigua din care sa se poata face comparatia
si realiza contrastul UML cu alte tehnici si notatii si pentru a asigura consistenta dintre diferitele
componente;
- extendabilitatea - pentru a asigura factorul de calitate ca pentru orice extensie a UML sa fie
verificat.;
- rafinarea – pentru a permite corectitudinea pasilor proiectului din UML a fi verificati si documentati
precis. În particular, trebuie asigurate sabloanele proiectarii a caror corectitudine trebuie verificata. Odata
acest control realizat, un sablon poate fi reutilizat de ori de câte ori fara sa fie necesara o alta verificare;
- probarea - pentru a face disponibile probari si verificari justificate ale proprietatilor importante ale
sistemului descris în UML, de exemplu: securitatea si proprietatile de liveness. Într-un context industrial
aceasta poate deveni o baza pentru tehnicile de probare automata.
Din nefericire, în UML–ul actual, semanticile nu sunt suficient de formale pentru a realiza multe
dintre aceste beneficii. De altfel, multe dintre sintaxele limbajului au fost definite, o parte dintre
semanticile statice si cele mai multe dintre semanticile dinamice, au fost descrise în paragrafe, relativ
lungi, informale, scrise în limba engleza, care sunt destul de ambigue, sau descrierea acestora lipseste cu
desavârsire. O alta mare problema se refera la domeniul foarte vast pe care trebuie sa-l acopere limbajul,
numarul problemelor care trebuie tratate înainte ca lim bajul sa fie complet definit fiind foarte mare.
Fiind dat rolul intentionat la UML de a fi o notatie standard apare ca imperativa necesitatea de a
avea semantici bune fundamentate. Numai dupa ce aceste semantici au fost date se poate discuta despre
UML ca fiind utilizabil ca o tehnica riguroasa de modelare. Mai mult formalizarea UML poate fi legata
de întelegerea profunda a conceptelor OO, în general, care, în schimb pot fi legate de utilizarea mai
matura a tehnologiilor OO. O astfel de întelegere poate fi câstigata prin explorarea consecintelor unei
implementari particulare si prin observarea efectelor de relaxare si/sau armare a restrictiilor modelelor
semantice. Abordarea actuala se refera la eforturile depuse si rezultatele obtinute de formalismul ML
actual în contextul proiectelor colaborative. Unul dinte aspectele obiectivelor pe termen lung se refera la
definitivarea unui manual de referinta pentru UML. Acesta va da o descriere precisa a componentelor
nucleului de baza al limbajului si va furniza regu lile de inferenta pentru analiza proprietatilor acestuia. SE
va forma astfel fundamentarea raspunsurilor relative la întrebarile cu privire la utilizarea riguroasa a UML
prin:
- furnizarea unui set consistent de reguli pentru manevrarea diagramelor UML de o maniera precisa
si formala;
- determinarea cazurilor în care o diagrama particulara UML este o rafinarea a unei alte diagrame;
- permiterea de probari netriviale pentru diagramele UML. Aceste probari trebuie sa fie
automatizabile utilizând instrumente de verificare ale modelului sau probatoare de teoreme;

46
 - oferirea de compatibilitati cu alte modele standard industriale semnificative, cum ar fi Core Object
Model.
Se va prezenta o abordare initiala pentru furnizarea unui format convenabil pentru UML, bazat pe
identificarea unor concepte UML din nucleul de baza. Se va introduce si explora UML, de o maniera
informala, pentru a determina fundamentele semanticii de baza, care se va finaliza cu o descriere formala.
O privire informala asupra UML
UML este definit ca o colectie de modele grafice care exprima diferitele proprietati ale unui proiect
orientat OO. Exista doua tipuri importante de modele: modelele structurale si modelele comportamentale.
Modelele structurale – exprima informatia despre structura claselor si a obiectelor (instantelor) din
interiorul unui sistem, cum ar fi: relatiile cu alt obiect (Clasa), atribute, restrictii. Cel mai important model
structural si ca urmare, modelul central UML este diagrama claselor. O diagrama a claselor este un graf
bidimensio nal care va contine urmatoarele elemente:
- o colectie de tipuri sau clase 29 din care se pot proiecta o multime de instante obiect;
- o multime de valori distincte pe care le pot lua instantele unei clase;
- descrierile operatiilor proprii claselor si a parametrilor acestora;
- o multime de relatii de asociere care leaga si restrictioneaza cardinalitatea instantelor.
Este dat mai jos un mic exemplu a unei diagrame a unei clase. În exemplul prezentat exista trei
clase: Polygon, Point, GraphBundle care sunt relationate unele cu altele prin doua asocieri, dintre care
una este etichetata (numita). Asociatia etichetata: Contains relationeaza exact o instanta a lui Polygon cu
trei sau mai multe instante (ordonate) ale lui Point. Rombul blank semnifica faptul ca asociere este o
agregare si reprezinta întreaga / parte din relatia dintre clase. Cealalta asociere este o asociere compozita,
care odata creata nu poate fi modificata. Esential este ca o diagrama de clase serveste la restrictionarea
colectiei posibile de configuratii legale ale sistemului. Orice program care implementeaza proiectul
trebuie sa fie într-o configurare legala a sistemului pentru toti timpii.

Figura 2.21. Diagrama unei clase

Modele comportamentale – exprima informatii relative la comportamentul dinamic al programului care

este de proiectat. În mod tipic, acest model descrie comportamentul, în termeni de modificare a starii si
transmiterea mesajului, care trebuie sa se produca ca raspuns la un eveniment oarecare din sistem. Exista
si în acest caz doua tipuri importante de model dinamic: diagrame de colaborarea si diagramele de
tranzitie a starilor, care împreuna exprima comportamentul cerut al sistemului.
O diagrama de colaborare exprima informatia relativa la interactiunea mesajelor care apar între
instantele obiect ca fiind privite de un observator extern. Este o privire externa deoarece nu va defini
schimbarile de stare interne care apar la fiecare obiect de colaborator. În mod tipic, o diagrama de
colaborare va exprima secventa mesajelor care vor apare, datorate unui dintre obiectele participante, care
primeste un mesaj particular. Mesajele pot fi numai trimise între obiectele care sunt relationate într-un
mod oarecare. Exemplul urmator, se refera la o diagrama de colaborare ca parte a unei diagrame editor.
Mesajele dintre instante sunt desenate prin sageti. Mesajele care implementeaza o operatie sunt
numerotate de-a lungul operatiei pe care o implementeaza. O diagrama de tranzitie de stare exprima
informatia relativa la modificarea starii care apare la o clasa particulara de obiecte. La un moment de timp
oarecare, un obiect este într-o stare particulara si poate primi un mesaj de la un alt obiect, relationat.
Starea particulara si mesajul vor determina actiunea care este luata de catre receptor si noua stare a
acestuia. Se dau mai jos (figura 2.23.) exemple tipice în acest sens.

29
Distinctia dintre tipuri si clase în UML este ca: o clasa reprezinta o realizarea a unui tip. Pentru scopurile acestei
abordari este suficient sa se considere ca tipurile si clasele sunt semantic echivalente – o clasa mostenind toate
proprietatile unui tip. De asemenea se utiliza cu aceiasi semnificatie semantica termenii de “instanta” si “instanta a
unui obiect”.

47
Figura 2.22. Diagrama de colaborare

Figura 2.23. Diagramele de tranzitie

Nucleul semanticilor de baza

Fiind dat modelul anterior, este posibil sa se identifice, informal, unele dintre componentele de
baza ale modelului UML. Acestea vor fi examinate si într-un context mai formal. Nucleul central al UML
este constituite din descrierea colectiilor de clase a instantelor acestora si a relatiilor dintre acestea.
Aceste relatii vor corespunde unui numar distinct de componente ale unei implementari concrete care vor
include:
- relatia dintre o instanta obiect si valoarea sa.
- relatia dintre o clasa si instantele sale si o clasa si superclasa sa.
- relatia dintre instantele care sunt implicate în asocieri
- relatia dintre clase si operatiile pe care le ofera
- relatia dintre o operatie si semnatura sa
- relatia dintre clasa si comportamentul acesteia. Aceasta poate fi exprimata în termeni ai efectelor pe
care operatiile le au asupra valorilor instantelor sale si a mesajelor pe care aceasta le trece.
Starile legale sunt determinate printr-un numar de restrictii care protejeaza o stare fata de o
situatie imposibila. Aceste restrictii sunt:
- mesajele pot fi trimise între obiectele care sunt relationate. Intuitiv, acestea corespund acelei restrictii
care pentru a permite trimiterea unui mesaj de la un obiect la altul face verificarea ca emitatorul este
capabil sa refere destinatia. Referinta poate sa apara într-un atribut, un parametru al unei metode sau
printr-o asociere.
- toate obiectele trebuie sa fie instanta a cel putin una dintre clase. Un obiect poate fi instanta a
claselor multiple atunci când acestea sunt relationate prin mostenire.

48
Proiectele UML sunt ine vitabil bazate pe stare. Fiecare stare contine informatii despre instantele
obiectelor si valorile atributelor curente. În timpul executiei, valorile atributelor se pot modifica, fiind o
urmare a mesajelor care au fost trecute între obiecte si a operatiilor care au fost executate. O modificare
de stare, sau tranzitie, poate sa apara ca un rezultat al:
- schimbarea valorii unui obiect. În acest caz relatia care defineste valoarea curenta a obiectului
trebuie sa fie modificata;
- un mesaj ajunge la un obiect. În acest caz trebuie sa existe valori ale parametrului care sunt legate
de destinatia mesajului pe toata durata activarii mesajului.
- crearea unui obiect. În acest caz obiectul trebuie relationat cu valorile initiale ale atributelor.
- distrugerea unui obiect. În acest caz obiectul trebuie sters din toate relatiile la care a participat.
- s-a trimis o reluare. În acest caz valorile parametrilor nu mai sunt (posibil) relationate cu
destinatarul mesajului si emitentul mesajului devine relationat cu valoarea de reluar e.
Formalizarea
Scopul formalizarii este de a da raspuns întrebarii: care este cel mai simplu, mai mic si mai convingator
model formal, care capteaza proprietatile esentiale ale UML? Modeleul prezentat este un pas în aceasta
directie. Scopul este de a face modelul mai mic, mai simplu prin recunoasterea faptului ca multe dintre
tehnicile de modelare utilizate de UML prezinta mai multe puncte de vedere ale aceluiasi model de baza
al obiectului. De exemplu, diagramele de interactiune obiect capteaza pur si simplu ordinul de invocare al
operatiei dintre instantele obiectului. Specificatia astfel prezentata este o extensie a specificatiei Core
Object Model, care a fost redactata în Z. Aceasta a fost aleasa din cauza ca este capabila sa capteze o
descriere precisa a standardelor OMT pentru obiecte. Deoarece UML este accepta pentru standardizare de
catre grup, este limpede cerinta de conformitate a modelului de baza cu metamodelul UML. Prin aceasta
conformitate cu acest important standard industrial, modelul UML devine mai convingator. Modelul OT
este, în esenta, o descriere a sintaxei a unui model obiect simplu. Aceasta impune un numar de cerinte
pentru sistemele conforme. Un astfel de sistem trebuie sa fie capabil sa întretina o biblioteca de clase în
care:
- exista un numar de tipuri disponibile pentru sistem;
- sunt asociate, fiecarui tip, operatii;
- tipurile formeaza o ierarhie;
- are loc mostenirea operatiilor pentru subtipuri.
Asa cum s-a mentionat anterior, unul dintre scopuri, este de a descrie modelul de baza UML, prin
opozitie cu fiecare aspect al meta modelului UML bazat pe semanticile informale identificate anterior, au
fost identificate urmatoarele cerinte suplimentare
- fiecare tip este asociat cu o multime de valori posibile. În cazul tipului obiect aceste valori
vor reprezenta instantele obiectelor respectivului tip;
- tipurile sunt relationate prin asocieri;
- operatiile sunt asociate cu comportamentele si astfel permit trecerea mesajelor.
Fiecare dintre conceptele anteriore vor fi luate în considerare. Rezultatul va fi o chema Z pentru modelul
de baza UML. Modelul va cuprinde sapte scheme care corespund respectivelor concepte:
Modelul de baza
Types
Instances
Values
Operations
Behavours
Associations
Hierachy
Inheritance
Abordarea generala pentru descrierea semanticilor este de a da o denotatie fiecarui concept în Z. Aceasta
va facilita formalizarea conceptelor importante cum ar fi comportamentul, care este modelat ca o multime
de tranzitii de stare.
Tipuri
Se considera o multime data [TypeName] de la care se pot proiecta numele tuturor tipurilor.
Tipurile de obiecte disponibile sunt cele din standardul OMT. Tipurile disponibile în model constau din
tipuri obiect, tipuri non-obiect (numere) si tipuri abstracte. Pentru a exprima aceste trei multimi finite de
tipur i ale lui TypeName acestea sunt declarate în schema Type:
Cele doua restrictii în partea predicationala a schemei statueaza ca:
- un tip obiect nu poate avea acelasi nume cu tipul non-obiect

49
 - orice tip abstract trebuie sa fie un tip obiect

Instante
Similar ca la tipuri se considera existenta o multime de la care se poate proiecta identitatile tuturor
instantelor: [Instance]. O instanta este o instantiere a unui tip si are o identitate unica:

Restrictia din schema statueaza ca fiecare instanta este asociata numai cu un tip.
Valori
Un tip defineste valorile instantei sale. Valoarea unei instante consta din valoarea atributelor la un
moment de timp dat.
Se considera existenta multimea [Atribute,?] de la care se pot proiecta toate atributele si valorile de
interes. O value asociaza atribute cu valori.

Valoarea fiecarei instante trebuie sa fie concordanta cu definirea tipului.

O parte dintre aceste valori vor reprezenta multimea valorilor initiale pe care un tip obiect
particular îsi poate permite sa o aiba la cerere.

Valorile modelului sunt descrise prin conjunctia schemelor anterioare.

Operatii
Se considera, similar cu enunturile anteriore existenta unei multimi care sa poata fi baza definirii numelui
tuturor operatiilor: [OpName]. Semnatura unei operatii consta din numele operatiei, tipul parametrilor sai,
tipul valorilor de retur.

50
 Este posibila, astfel, definirea schemei Operation1. Aceasta exprima faptul ca fiecare obiect
furnizeaza o interfata, care consta dintr-o multime de semnaturi.

Spre deosebire de Core Object Model, UML trebuie sa permita redondanta operatiilor si ca
urmare nu sunt restrictii cerute interfetelor.
Comportamentul unui tip obiect este descris ca o extensie a COM. Comportamentul obiectului
este modelat ca o multime de tranzitii care denota progresia unui obiect de la o valoare la alta. Tranzitiile
constau din 6-tuple care constau din parametrii de intrarea si de iesire, un nume de operatie, o tranzitie de
la o valoare anterioara la o valoare ulterioara si un mesaj care sa denote interactiunea externa a operatiei.
Se considera data multimea [Message] de la care se pot descrie multimile tuturor mesajelor.
Pentru mesaj nu sunt date detalii de structura si semnificatie.

Urmatoarea schema des crie relatia dintre un tip obiect si comportamentul acestuia:

Cele doua restrictii enuntate în schema statueaza ca:

- fiecare tranzitie a unui tip obiect trebuie sa apartina multimii de valori posibile ale acestuia;
- semnatura unei operatii trebuie sa contina tipuri valide.
Schema completa pentru Operations este specificata în consecinta:

Relatii
UML descrie doua tipuri de relatii:
- asocierile, care modeleaza relatiile dintre instantele tipurilor;
- generalizarile, care modeleaza ierarhiile supertip/supertip.
Cu toate ca UML accepta asocieri n-are, vor fi luate în considerare numai asocieri binare, pentru
abordarea actuala.
Asocieri binare
Si în acest caz se considera existenta, cu acelasi rol, multimea [AssociationName, RoleName]
Reprezentarea valorilor booleene este introdusa prin enumerarea de mai jos:

Un rol conecteaza finalul unei asocieri cu un tip.

51
 Fiecare rol are un nume, un tip propriu si multiplicitate care denota domeniul cardinalitatilor
disponibile pe care un rol al asocierii îl poate avea. O multiplicitate este o submultime a numerelor
naturale. Valorile booleene isAggregae si isChangeable indica faptul ca rolul reprezinta întreaga parte
(proprie) a unei agregari sau o agregare compozita. Restrictiile din schema statueaza ca o agregare
compozita este de asemenea o agregare dar, reciproca nu este neaparat adevarata. Schema Associations
exprima relatiile dintre asocierii si roluri. Restrictiile statueaza ca:
- o asociere are exact doua roluri (ca fiind cerute de o asociere binara)
- rolurile trebuie sa fie proprii unui tip obiect
- cel mult un rol poate apartine unei agregari
Semnificatia unei asocieri este o relatie dintre instantele obiect(AssociationMeaning1).

Cea de a doua restrictie a schemei descrie relatia dintre instantele pe care le asociaza cu instantele
tipurilor pe care le leaga. Daca multiplicitatea unui rol particular contine ‘0’ atunci este optional ca
instantele rolului din cealalta parte sa poata participa la asociere. Daca multiplicitatea este conditionala
(nu contine ‘0’) atunci instantele rolului din cealalta parte trebuie sa participe la asociere.

Cea de a doua schema descrie semanticile asocierilor în termeni de instante pe care le

relationeaza.
Prima restrictie din schema este chiar o modalitate de a afirma ca multiplicitatea unei asocieri
limiteaza numarul instantelor obiect care pot participa la aceasta. Cea de a doua restrictie capteaza cerinta
data în UML relativa la faptul ca multiplicitatea unei agregari compozite trebuie sa fie unu. Schema
asocierii este data de conjunctia celor doua scheme anterioare:

52
Ierarhia
Exista un tip distinct denumit Object:
? Object: TypeName
Schema ierarhiei exprima relatiile supertipului între tipurile obiect si este data mai jos. Restrictia
schemei este modalitatea de a afirma o colectie de tipuri obiect care formeaza un graf directat aciclic cu
radacina în Object.

Mostenirea
În final, un tip mosteneste toate operatiile sustinute de supertipurile sale:

Nu este foarte cla r definit în UML daca un tip mosteneste toate comportamentele supertipurilor sale.
Acest fapt se exprima în urmatoarea schema:

Strategii de formalizare
Strategiile de formalizare considerate sunt legate de una din cele doua abordari care au fost investigate
relativ la UML. Abordarea adoptata îsi propune descrierea UML la meta-nivel. Avantajele acestei
abordari este utilitatea acesteia particulara de a investiga ambiguitatile din meta-modelul UML si devine
astfel un mijloc de a dezvolta reguli generale si tehnici pentru constructia, manevrarea si rafinarea
diagramelor UML.
Cealalta abordare este una tranzactionala. Aceasta atribuie o semantica fiecarei diagrame UML
prin translatarea acesteia într-o formula de logica modala. Deoarece logica modala ar e semantici bine
definite, translatia da o semantica fiecarei diagrame. Tehnicile de probare care au fost dezvoltate pentru
logica modala pot fi, în consecinta, aplicate, formulei astfel rezultate. Aceasta abordare este utila pentru
probarea proprietatilor relative la sisteme exprimate prin diagrame UML (în opozitie cu diagramele UML
însele).
Arhitectura UML
Pentru a întelege arhitectura UML se considera modul în care programele si limbajele de programare sunt
relationate între ele. Exista multe limbaje de programare, pe de o parte, iar fiecare program este dezvoltat
utilizând un limbaj de programare specific. Toate aceste limbaje vor sustine diferite constructii
declarative pentru a declara datele, aspectele procedurale, definirea logicilor care manipuleaza datele.
Deoarece modelul este o abstractizare, fiecare dintre aceste concepte poate fi captat într-o multime de
modele relationate. Conceptele limbajelor de programare sunt, la rândul lor definite în metamodel.
Fiecare limbaj de programare este definit într-un model care utilizeaza si specializeaza conceptele din
interiorul metamodelului. Fiecare program implementat într-un limbaj de proiectare poate fi definit într-
un model care se va numi model utilizator care utilizeaza si instantiaza conceptele modelului printr-un
limbaj convenabil. Aceasta schema a metamodelului, de reprezentare a constructorilor de programare,

53
modele care sa reprezinte, la rândul lor limbaje de programare si modele utilizator care sa reprezinte
programe, exemplifica arhitectura UML. UML este definit în cadrul conceptual al modelarii care consta
din urmatoarele patru nivele distincte de abstractizare:
- Nivelul meta-metamodelului, consta din elementele fundamentale pe care se bazeaza UML -
conceptul de ‘thing’, care reprezinta orice ce poate fi definit. Acest nivel de abstractizare formalizeaza
notiunea unui concept si defineste un limbaj pentru specificarea metamodelului.
- Nivelul metamodelului – consta din acele elemente care constituie UML, incluzând concepte din
paradigmele orientate obiect si orientate componente. Fiecare concept al nivelului este o instanta (prin
intermediul stereotipurilor) a conceptului meta-metamodelului ‘Thig’ Acest nivel de abstractizare este
utilizat pentru formalizarea conceptelor paradigmei si la definirea unui limbaj pentru specificarea
modelelor
- Nivelul model – consta din modele UML. Acesta este nivelul la care se produce: modelarea
problemelor, solutia sau sistemul. Fiecare concept din acest nivel este o instanta (prin intermediul
stereotipurilor) a unui concept din nivelul metamodelului. Acest nivel de abstractizare este utilizat la
formalizarea conceptelor si la definirea limbajului pentru comunicarea expresiilor cu privire la un subiect
dat. Modelele de pe acest nivel mai sunt numite clase sau modele ale tipurilor.
- Nivelul model utilizator – consta din acele elemente care exemplifica modelele UML. Fiecare
concept din acest nivel este o instanta (prin intermediul clasificarii) a conceptelor din nivelul model si o
instanta (prin stereotipuri) a unui concept din nivelul metamodel. Acest nivel de abstractizare este utilizat
pentru a formaliza expresiile specifice cu privire la un subiect dat. Modelele din acest nivel sunt numite si
obiecte sau instante ale modelului.
Modele
Modelele capteaza caracteristicile structurale sau statice ale sistemelor si comportamentul, sau
caracteristicile dinamice ale acestuia. Modelele pot fi privite ca prin intermediul unei multimi de
dimensiuni (aspecte) independente care etaleaza calitati particulare ale modelului. Fundamental, modelele
capteaza cunostinte (semantici).
Perspectiva arhitecturala
Perspectiva arhitecturala organizeaza modelele si cunostintele în jurul unei multimi specifice de interese
(focusarea arhitecturala). UML da urmatoarele perspective arhitecturale cu privire la modele sau
probleme si solutii:
- modelul utilizator – contine o problema si o solutie ca întelese de elementele individuale carora li
se adreseaza respectiva problema (solutie). Aceasta perspectiva este de asemenea numita use case sau
scenariu;
- modelul structural – cuprinde dimensiunea structurala a unei probleme si solutii. Aceasta
perspectiva este cunoscuta ca fiind perspectiva statica sau logica;
- modelul comportamental – cuprinde dimensiunea comportamentala a problemei si solutiei.
Aceasta perspectiva este cunoscuta de asemenea ca fiind: dinamica, de proces, concurenta sau
colaborativa;
- modelul implementarii cuprinde dimensiunea comportamentala si structurala a realizarii
solutiilor, fiind cunoscuta si ca: de dezvoltare sau de componente;
- modelul de mediu – cuprind dimensiunea structurala si comportamentala a domeniului în care
este realizata solutia. Este cunoscuta si ca perspectiva fizica;
Se pot defini si alte perspective, în cazul în care este remarcata necesitatea acestora. O orientare
arhitectur ala este definita printr-o multime de continuturi. O perspectiva arhitecturala este definita prin
intermediul unei multimi de elemente dintr-un model care refera o orientare arhitecturala. De exemplu,
securitatea poate fi definita ca o orientare arhitecturala. O arhitecturalitate a securitatii va include multime
a elementelor modelului care adreseaza securitatea.
Fundamental, perspectiva arhitecturala organizeaza cunostintele în concordanta cu ghidurile date
de exprimarea idiomurilor necesare utilizarii.
Diagrame
Diagramele prezinta cunostinte într-o forma comunicabila. UML furnizeaza urmatoarele diagrame,
organizate în jurul perspectivei arhitecturale cu privire la modelele problemelor si a solutiilor:
? perspectiva modelului utilizator
- diagrame de scenarii care descriu functionalitatea sistemului
? perspectiva modelului structural
- clasa de diagrame care descriu structura statica a sistemului

54
 - diagrame obiect care descriu structura statica a sistemului la un moment particular de
timp.
? perspectiva comportamentala
- diagrame de secvente care descriu o interactiune de-a lungul elementelor sistemului
organizat în secventa temporale
- diagrame de colaborare care descriu o interactiune de-a lungul elementelor unui sistem si
a relatiilor acestora, organizate în timp si spat iu
- diagrame de stare care descriu conditiile de stare si raspunsurile elementelor sistemului
- diagrame de activitate care descriu activitatea elementelor sistemului.
? perspectiva modelului implementare
- diagramele de componente care descriu organizarea elementelor care realizeaza sistemul
? perspectiva modelului de mediu
- diagrame de desfasurare care descriu configuratia elementelor de mediu si maparea
elementelor care realizeaza sistemul peste acestea
? alte diagrame pot fi definite si utilizate dupa necesitati.
Mecanismele de modelare
Mecanismele sunt practici pentru abordarea modelarii si a realizarii diagramelor care valideaza creare de
modele din ce în ce mai precise si ceea ce este mai important, din ce în ce mai comunicabile.
- Perspectivele definesc un punct de vedere particular de la care se pot elabora sau citi diagrame.
Acestea valideaza asocierea de puncte de vedere clare cu diagrame si sunt utilizate pentru eficientizarea
comunicarilor;
- Dihotomiile definesc modul în care ceva poate fi privit din doua perspective diferite. Acestea
valideaza o privire asupra unei entitati din puncte de vedere multiple si sunt utilizate (fiind foarte eficiente
în acest scop) la depistarea inconsistentelor dintre modele;
- Nivelele de abstractizare definesc un nivel particular si stabilesc nivelul de detaliu cu privire la un
subiect (problema sau solutie). Acestea permit orientarea spre comunicare si sunt utilizate pentru
organizarea tuturor diagramelor care apartin unui singur model într-un singur corp de cunostinte, coerent;
- Extensia mecanismelor defineste mijlocul prin care se poate realiza personalizarea si extinderea
UML. Aceasta permite UML sa fie flexibil si adaptiv si este utilizat pentru a asigura UML evolueaza,
solutie mai buna decât redefinirea necesara pentru descrierea nevoilor de modificare sau a cerintelor.
Într-un proces problema - solutie, cunostintele cu privire la o problema si o solutie sunt captate,
organizate în jurul deciziei si descrise utilizând UML astfel încât pot fi comunicabile si plasate pe diferite
nivele.

55