Tehnici de implementare a concurentei în analiza si proiectarea ...

UNIVERSITATEA "BABES - BOLYAI" CLUJ-NAPOCA
FACULTATEA DE MATEMATICA SI INFORMATICA
Tehnici de implementare a concurentei
în analiza si proiectarea orientata pe obiecte
TEZA DE DOCTORAT
CONDUCATOR STIINTIFIC: DOCTORAND:
prof. dr. Grigor MOLDOVAN Dan Mircea SUCIU
2001

Prefata
Automatizarea etapelor ciclului de dezvoltare a aplicatiilor constituie un
subiect fierbinte în comunitatea informatica. Lucrarea de fata îsi propune sa aduca o
contributie în aceasta directie, în special în cazul aplicatiilor orientate-obiect
concurente.
Doresc sa aduc multumiri sincere domnului profesor universitar doctor Grigor
Moldovan pentru întelegerea, rabdarea si tactul pedagogic pe care le-a dovedit fata de
mine. Consultarile si dicutiile care au însotit activitatea comuna de cercetare au
influentat în mod hotarâtor calitatea si definitivarea lucrarii de fata.
Domnului lector doctor Dan Chiorean îi multumesc pentru întreg sprijinul,
solicitudinea si încurajarile oferite în diverse împrejurari. Domnia sa a fost primul
meu îndrumator stiintific si cel care m-a determinat sa iau decizii corecte în momente
importante ale vietii mele. Faptul ca lucrarea de fata exista i se datoreaza într-o
covârsitoare masura dânsului.
Colegilor si prietenilor mei Dorel Bozga, Ileana Ober, Iulian Ober si Marian
Scuturici le multumesc pentru lungile discutii avute împreuna, discutii care au avut un
rol determinant în definitivarea tezei în forma actuala. De asemenea, multumesc
tuturor colegilor din cadrul Laboratorului de Cercetare în Informatica alaturi de care
am petrecut momente de neuitat.
Multumesc colegilor din Departamentul de Informatica pentru suportul,
dicutiile si sugestiile utile care au condus la o mai buna structurare a continutului
lucrarii.
1
Cluj-Napoca, mai 2001

Cuprins
1. Introducere ...............................................................................................................4
1.1. Contextul programarii orientate-obiect concurente............................................4
1.2. Metode de analiza si proiectare a aplicatiilor ....................................................7
1.3. Contributiile originale ale tezei...........................................................................8
1.4. Structura tezei....................................................................................................10
2. Specificarea si coordonarea concurentei în programarea orientata-obiect
concurenta ..............................................................................................................12
2.1. Introducere ........................................................................................................12
2.2. Principii de proiectare a limbajelor de programare orientate-obiect conc......13
2.3. Mecanisme de specificare a concurentei...........................................................20
2.4. Mecanisme de interactiune si sincronizare a obiectelor concurente................24
2.2.1. Mecanisme de interactiune orientate pe operatii ................................................ 27
2.2.2. Mecanisme de interactiune concurenta bazate pe încapsulare............................. 32
2.5. Concluzii ............................................................................................................53
3. Anomalii de mostenire ...........................................................................................55
3.1. Introducere ........................................................................................................55
3.2. Clasificari ale anomaliilor de mostenire...........................................................57
3.2.1. Clasificarea Matsuoka-Yonezawa.................................................................... 58
3.2.2. Clasificarea Zeng-Schach................................................................................ 63
3.2.3. Anomalii de reutilizare.................................................................................... 64
3.3. Formalizarea anomaliilor de mostenire............................................................67
3.4. Modelarea principiilor de proiectare ale limbajelor orientate-obiect conc .....82
3.5. Concluzii ............................................................................................................86
4. Modelarea comportamentului obiectelor active .................................................89
2

4.1. Introducere ........................................................................................................89
4.2. Sisteme reactive.................................................................................................90
4.3. Harti de stari......................................................................................................93
4.3.1. Structura hartilor de stari................................................................................. 93
4.3.2. Timp de executie ............................................................................................ 97
4.3.3. Pseudostari..................................................................................................... 99
4.4. Utilizarea hartilor de stari în modelarea obiectelor active.............................100
4.5. Harti de stari scalabile ....................................................................................109
4.5.1. Modelul obiect ..............................................................................................109
4.5.2. Definirea hartilor de stari scalabile ..................................................................111
4.5.3. Executabilitatea hartilor de stari scalabile ........................................................125
4.6. Concluzii ..........................................................................................................128
5. ActiveCASE - instrument de modelare si simulare a comportamentului
obiectelor active ...................................................................................................130
5.1. Introducere ......................................................................................................130
5.2. Meta-modelul hartilor de stari scalabile.........................................................132
5.2.1. Modelarea hartilor de stari în UML.................................................................132
5.2.2. Modelarea hartilor de stari scalabile în ActiveCASE ........................................134
5.3. Descrierea aplicatiei ActiveCASE...................................................................139
5.3. Modelarea si testarea unei aplicatii de simulare a traficului de masini.........143
5.4. Concluzii ..........................................................................................................148
6. Concluzii ...............................................................................................................151
6.1. Rezultate obtinute ............................................................................................151
6.2. Perspective.......................................................................................................152
6.2.1. Anomalii de reutilizare...................................................................................152
6.2.2. Modelarea si simularea aplicatiilor orientate-obiect concurente.........................153
Bibliografie ...............................................................................................................155
Anexa A. Notatii matematice ..................................................................................164
A.1. Multimi ............................................................................................................164
A.2. Relatii binare...................................................................................................164
A.3. Functii .............................................................................................................165
Anexa B. Notatii UML.............................................................................................166
B.1. Diagrame de clase...........................................................................................167
B.2. Harti de stari ...................................................................................................168
3

1. Introducere
1.1. Contextul programarii orientate-obiect concurente
Problema unificarii conceptelor programarii orientate-obiect cu mecanismele
specifice programarii concurente reprezinta o preocupare constanta în lumea
informaticii în ultimele doua decenii. Aceasta preocupare este justificata de puterea
ridicata de modelare, proprie limbajelor orientate-obiect, si puterea de calcul, proprie
limbajelor concurente, care au facut ca limbajele de programare orientate-obiect
concurente sa fie aplicabile într-un numar însemnat de domenii, cum ar fi: sistemele
de operare distribuite, inteligenta artificiala distribuita, simularea distribuita, baze de
date distribuite, dezvoltarea de sisteme în timp real, controlul proceselor distribuite,
proiectarea de arhitecturi multi-procesor etc.
Programarea orientata-obiect concurenta se bazeaza pe metodologia
programarii orientate-obiect 1 , care este recunoscuta în acest moment ca fiind
metodologia de vârf pentru dezvoltarea de aplicatii reutilizabile de nivel înalt. Ea
permite descrierea contextului unui sistem prin intermediul unei colectii de obiecte.
Obiectele reprezinta entitati fizice si conceptuale ce compun un anumit sistem.
Ele încapsuleaza anumite proprietati si pot efectua anumite operatii. Aplicatiile
dezvoltate într-o maniera orientata-obiect nu contin un algoritm global. Ele se
compun dintr-o multime de obiecte care interactioneaza între ele prin cereri si
schimburi de informatii. Aceste interactiuni se realizeaza prin intermediul unui
protocol unificat de comunicare, numit transmisie de mesaje, protocol care presupune
4

existenta unui obiect sursa si a unui obiect receptor. Trimiterea unui mesaj are ca
scop executia unei operatii definite la nivelul obiectului receptor. Mesajul receptionat
va contine informatii pe baza carora obiectul receptor va putea determina operatia
care va fi executata precum si valorile eventualilor parametrii ai acesteia. Aceasta
metodologie reprezinta, de fapt, o abstractizare a modului natural în care sunt
rezolvate cooperativ anumite probleme în diverse comunitati biologice.
Alte notiuni fundamentale intim legate de paradigma programarii orientate
obiect sunt abstractizarea (care introduce conceptul de clasa) si mostenirea (ce
introduce conceptul de subclasa), ele permitând specificarea, clasificarea si
reutilizarea descrierilor de obiecte.
Primul limbaj de programare bazat pe aceste concepte, numit Simula, a aparut
la sfârsitul anilor ’60 si a fost dezvoltat în scopul realizarii de aplicatii pentru
simularea anumitor evenimente ale lumii reale [DAH67]. Odata cu aparitia acestui
limbaj cercetarile relative la programarea orientata-obiect au luat amploare,
conceptele acesteia au fost clar identificate, iar metodologia orientata-obiect a fost
calificata de ingineria soft ca o îmbunatatire semnificativa în dezvoltarea programelor
si cresterea calitatii, fiabilitatii si reutilizabilitatii aplicatiilor.
Facând însa mai departe analogia cu lumea reala constatam ca aici obiectele
sunt în mod natural concurente. Acest lucru implica posibilitatea ca la un moment dat
mai multe obiecte sa efectueze concomitent anumite operatii (concurenta inter-
obiect), sau un acelasi obiect sa execute în paralel doua sau mai multe operatii
(concurenta intra-obiect).
Abilitatea de a exprima paralelismul potential al activitatilor prin programe
concurente a devenit subiect de cercetare pentru sistemele viitoare. Iata doar câteva
aspecte care sugereaza importanta acestei tendinte în programare:
?? generalizarea sistemelor de operare multi-tasking si a sistemelor multi-
procesor,
?? distribuirea cunostintelor (informatiilor), prin intermediul retelelor de
calculatoare,
1 În [BRI93] programarea orientata-obiect este privita ca o restrictie tehnologica a conceptului mai
general de programare orientata obiect concurenta.
5

?? existenta de interactiuni multiple în cadrul unor programe interactive mari
(cum ar fi controlul proceselor, unde intrarile si controlul acestora trebuie
sa fie multiple si distribuite),
?? exprimarea naturala a anumitor aplicatii prin intermediul mecanismelor de
concurenta si coordonare a activitatilor.
Prin urmare ideea de combinare a conceptelor programarii orientate-obiect cu
mecanisme de specificare si coordonare a activitatilor concurente are la baza doua
criterii distincte: unul obiectiv (determinat de cresterea performantelor si a
complexitatii sistemelor de calcul) si altul subiectiv (determinat practic de "bun simt",
care ne îndeamna sa modelam diverse probleme abstracte cautând similaritati cu
lumea reala).
Pentru a se putea realiza o integrare optima a acestor doua filozofii de
programare este utila identificarea obiectelor ca unitati de activitate si asocierea
sincronizarii între obiecte la nivelul transmiterii de mesaje. Astfel de obiecte sunt
numite în literatura obiecte active, actori sau obiecte concurente [BRI93].
Modul în care se realizeaza integrarea concurentei în cadrul programarii
orientate obiect a reprezentat preocuparea principala a mai multor cercetatori. În
prezent exista peste o suta de limbaje de programare orientate-obiect concurente
imperative ([PHI95b], [GOL83], [HUT87], [SCH86], [AND93], [AME90], [CAR93],
[KAF93], {YON97b] etc), au fost dezvoltate mai multe modele de obiecte concurente
([SHL88], [ELI92], [BER94], [PAP96], [OMG99], [HEN97]) si au fost depuse
eforturi pentru clasificarea acestora ([PAP92], [BER94]).
Combinarea concurentei cu mecanismele orientate-obiect nu este însa un
proces trivial. Cercetari mai vechi ([YON87]) au evidentiat existenta unor conflicte
între mecanismul de mostenire si mecanismele de coordonare a operatiilor concurente
în cadrul unor astfel de limbaje. Aceste conflicte, numite anomalii de mostenire, au
determinat mai multi proiectanti de limbaje orientate-obiect concurente sa elimine
mostenirea din limbajele lor sau sa implementeze mecanismele de coordonare
independent de ierarhiile de mostenire.
6

1.2. Metode de analiza si proiectare a aplicatiilor
Realizarea de aplicatii de complexitate medie sau mare nu mai poata fi
conceputa astazi fara utilizarea metodelor de analiza si proiectare. Prin metode de
analiza si proiectare întelegem o multime de procedee, tehnici si recomandari utilizate
în etapele timpurii ale ciclului de viata al unei aplicatii având ca scop final crearea
unui model al aplicatiei care urmeaza a fi construite. Specificarea acestui model se
realizeaza prin intermediul unui limbaj sau formalism vizual compus dintr-un set de
simboluri grafice si adnotari textuale.
Ciclul de viata al unei aplicatii reprezinta totalitatea etapelor care sunt parcurse
în procesul de dezvoltare a aplicatiei respective. Dintre cele mai importante etape
amintim:
- Analiza - în cadrul careia se realizeaza identificarea caracteristicilor
esentiale tuturor solutiilor corecte posibile,
- Proiectarea - care adauga modelelor de analiza noi elemente care definesc
o solutie particulara, pe baza optimizarii anumitor criterii,
- Implementarea - în care se realizeaza un proiect executabil al solutiei
particulare modelata în faza de proiectare,
- Testarea - în care se verifica echivalenta implementarii cu modelul
proiectat si valideaza faptul ca implementarea respecta criteriile de
corectitudine identificate în etapa de analiza.
Într-o abordare orientata-obiect în etapa de analiza sistemele informatice sunt
modelate prin indentificarea de clase si obiecte si ale relatiilor dintre acestea.
Proiectarea adauga detalii necesare implementarii modelului de analiza pe un sistem
de calcul, detalii referitoare la interactiunea utilizatorului cu aplicatia finala,
gestionarea proceselor, detalii de gestiune a datelor etc. Etapa de implementare
presupune translatarea modelelor de analiza si proiectare în cod sursa, folosind un
limbaj de programare particular. Un model de analiza sau proiectare al unei aplicatii
se numeste executabil daca translatarea sa în cod sursa se poate efectua automat.
Automatizarea procesului de translatare poate conduce la posibilitatea executarii unui
prototip al aplicatiei dezvoltate aproape imediat dupa ce modelul acestuia a fost
definitivat. Metodele de analiza si proiectare orientata-obiect permit parcurgerea
etapelor ciclului de viata a aplicatiilor într-o maniera iterativa (figura 1.1).
7

Specificatiile
aplicatiei
(limbaj natural)
Parcurgerea în sens
invers a etapelor ciclului
de viata a unei aplicatii
analiza
Model de analiza
(diagrame)
proiectare
Model de proiectare
(diagrame)
8
translatare
Model de implementare
(cod sursa)
compilare +
link-editare
Model executabil
(cod binar)
Figura 1.1. Modelul iterativ de dezvoltare a unei aplicatii în
cazul utilizarii unei metode de analiza si proiectare orientate-obiect
testare
Primele metode de analiza si proiectare orientate-obiect au aparut la sfârsitul
anilor '80, iar la începutul anilor '90 numarul acestora a crescut spectaculos. Anul
1997 marcheaza un moment important în evolutia domeniului prin adoptarea
limbajului UML (Unified Modeling Language [OMG99]) ca limbaj standard de
modelare a aplicatiilor de catre consortul international OMG (Object Management
Group).
Pe de alta parte, odata cu evolutia metodelor de analiza si proiectare orientate-
obiect s-au dezvoltat o serie de instrumente care permit automatizarea procesului de
realizare a aplicatiilor având la baza aceste metode. Astfel de instrumente poarta
numele de instrumente CASE (Computer Aided Software Engineering) si ele sunt
formate dintr-o colectie de componente care sprijina realizarea operatiilor ce trebuie
efectuate în cadrul uneia sau mai multor etape ale unei metode de analiza si
proiectare.
1.3. Contributiile originale ale tezei
Scopul acestei teze este de a defini si valida un formalism de modelare a
aplicatiilor orientate-obiect concurente. Pentru a realiza acest lucru am analizat în
detaliu principiile si modelele obiect care stau la baza unui numar mare de limbaje de
programare orientate-obiect concurente dezvoltate pâna în prezent. Formalizarea

matematica a conflictelor între concepte si a neajunsurilor care caracterizeaza aceste
limbaje a condus definirea unei extensii a formalismului hartilor de stari [HAR87]
utilizat în modelarea comportamentului sistemelor reactive, extensie numita harta de
stari scalabila. Caracterul executabil al hartilor de stari scalabile definite a permis
implementarea unui instrument de automatizare a dezvoltarii si simulare a aplicatiilor
orientate-obiect concurente.
Principalele contributii originale continute în teza si lucrarile în care acestea au
fost promovate sunt:
1. definirea unui set consistent de principii de proiectare a limbajelor de
programare orientate-obiect concurente care au la baza respectarea
integritatii conceptelor ce caracterizeaza fiecare dintre cele doua
metodologii de programare în parte (orientata-obiect si concurenta) -
[SUC97b];
2. sintetizarea caracteristicilor modelelor obiect implementate în peste o suta
de limbaje de programare imperative orientate-obiect concurente
dezvoltate pâna în prezent. Tratarea tuturor acestor modele obiect într-o
maniera unitara prin realizarea de extensii ale limbajului de programare
C++ cu mecanisme speciale de declarare de proprietati sau operatii si/sau
prin definirea de noi instructiuni - [SUC98b];
3. definirea conceptului de anomalie de reutilizare care extinde notiunea de
anomalie de mostenire, si care trateaza într-un mod unitar conflictele care
apar între concurenta si conceptele programarii orientate-obiect -
[SUC97a], [SUC98b];
4. extinderea unui sistem de formalizare a anomaliilor de mostenire pentru
modelarea respectarii principiului separarii codului de interactiune
concurenta determinat la punctul 1 si demonstrarea reducerii efectului
anomaliilor de mostenire pentru acest caz- [SUC98a];
5. definirea hartilor de stari scalabile ca extensie a formalismului vizual al
hartilor de stari definit în [HAR87]. Acest tip de harti de stari conduce la
simplificarea modelarii dinamice a obiectelor active cu comportament
complex, prin reducerea complexitatii în faza de modelare [SUC99];
6. definirea unei semantici care sa atribuie hartilor de stari scalabile un
caracter executabil, si care sa permita modelarea de obiecte active
9

corespunzatoare unui model obiect general, comun unei clase
semnificative de limbaje de programare orientate-obiect concurente -
[SUC98c], [SUC98d], [SCU97], [BOZ94b];
7. dezvoltarea unui instrument de proiectare, implementare si simulare a
1.4. Structura tezei
aplicatiilor orientate-obiect concurente, având la baza hartile de stari
scalabile. Acest instrument, numit ActiveCASE se constituie într-un
modul din cadrul unui instrument CASE mult mai general, Rocase -
[SUC98e], [CHI97], [SUC96b], [BOZ94a].
Capitolul al doilea, "Specificarea si coordonarea concurentei în programarea
orientata-obiect concurenta", este un capitol de sinteza în cadrul caruia am realizat o
analiza a constructiilor si mecanismelor de modelare a concurentei implementate în
peste o suta de limbaje de programare orientate-obiect concurente. De asemenea, am
enuntat patru principii de proiectare a modelelor de obiecte concurente care au stat la
baza evaluarii acestor mecanisme. Exemplificarea mecanismelor analizate s-a realizat
prin intermediul unor extensii ale limbajului C++.
În capitolul al treilea, "Anomalii de mostenire", am formalizat princiipiile
enuntate în cadrul capitolului al doilea si am demostrat importanta respectarii acestora
în ameliorarea anomaliilor de mostenire. Am aratat, de asemenea, ca termenul de
anomalie de mostenire este impropriu. Astfel, am demonstrat ca mecanismele de
initiere si coordonare a activitatilor concurente din limbajele de programare orientate
obiect concurente existente în prezent genereaza conflicte în raport cu relatiile de
asociere, agregare si delegare între clase. Cauzele si comportamentul acestor
conflicte sunt comune cu cele care determina anomaliile de mostenire. De asemenea,
am demonstrat ca termenul de anomalie de mostenire defineste un conflict particular
generat de integrarea concurentei într-un context orientat-obiect si am propus
termenul mai general de anomalie de reutilizare.
Capitolul patru, "Modelarea comportamentului obiectelor active", surprinde
aspecte privind modelarea aplicatiilor orientate-obiect concurente. Am realizat o
trecere în revista a principalelor modele obiect dezvoltate pâna în prezent insistând
10

asupra aspectelor de concurenta specifice. În centrul atentiei acestei analize se va afla
limbajul UML (Unified Modeling Language) versiunea 1.3 [OMG99].
Rezultatele obtinute în capitolul trei în studiul anomaliilor de mostenire alaturi
de interpretarea obiectelor active ca si (sub)sisteme reactive, conduc la ideea
modelarii comportamentului acestora prin intermediul formalismului hartilor de stari
[HAR87]. Lipsa unei semantici bine definite a acestor harti de stari pentru analiza si
proiectarea orientata-obiect au determinat specificarea în finalul capitolului a unei
variante de harti de stari, numita harta de stari scalabila, care sa permita crearea de
modele executabile, care ofera suport pentru generarea automata de cod si simularea
executiei obiectelor active.
În acest sens am propus mai multe modificari (extensii si constrângeri) ale
diagramelor de stari descrise în UML, în cadrul capitolului cinci, "ActiveCASE -
instrument de modelare si simulare a comportamentului obiectelor active". Aici este
descris un meta-model al hartilor de stari scalabile si este prezentata implementarea
acestuia în cadrul unei aplicatii de modelare si simulare a aplicatiilor orientate-obiect
concurente. Aceasta aplicatie se va constitui într-un modul distinct în cadrul
intrumentului CASE de analiza si proiectare orientata obiect Rocase, care a fost
realizat in cadrul Laboratorului de Cercetare în Informatica al Universitatii "Babes-
Bolyai" din Cluj-Napoca [CHI97].
În cadrul capitolului sase am expus concluziile finale rezultate în urma
studiilor efectuate în cadrul tezei, si se propun directii viitoare de cercetare în
domeniul analizei si proiectarii aplicatiilor orientate-obiect concurente.
În final, anexele A si B contin descrieri ale notatiilor matematice si grafice
utilizate în modelele formale si/sau vizuale dezvoltate în cadrul tezei.
11

2. Specificarea si coordonarea concurentei în programarea
orientata-obiect concurenta
2.1. Introducere
În clipa de fata exista o diversitate de limbaje de programare orientate-obiect
concurente, numarul acestora fiind în continua crestere datorita cercetarilor tot mai
intense în acest domeniu. Majoritatea acestor limbaje au fost dezvoltate în scopuri de
cercetare, pentru a demonstra sau infirma anumite rezultate teoretice.
În cadrul acestui capitol am enuntat un set de patru principii de proiectare a
limbajelor de programare orientate-obiect concurente. Acestea sunt în marea lor
majoritate principii care stau la baza filozofiei de programare orientata-obiect pe de o
parte si a programarii concurente pe de alta parte. Desi unificarea acestor doua clase
de principii pare a fi una naturala, referindu-se la doua paradigme ortogonale ale
programarii, se va arata ca respectarea unora dintre ele poate aduce atingere
integritatii celorlalte. Determinarea acestor principii s-a facut într-o maniera
informala, având la baza cercetari realizate în acest domeniu în [BLO79], [PAP89],
[MAT90], [FRO92], [PAP92], [MAT93], [MEY93] si [PHI95].
Prezentul capitol contine de asemenea un studiu amanuntit a modalitatilor de
specificare si coordonare a activitatilor concurente în peste o suta de limbaje
orientate-obiect concurente. Acest studiu are la baza descrieri si analize de limbaje de
programare, biblioteci de clase concurente sau modele de obiecte concurente si are ca
scop principal evaluarea acestora în raport cu respectarea principiilor determinate.
Rezultatele evaluarilor sunt prezentate în finalul capitolului sub o forma tabelara si ele
12

eleva faptul ca nici unul dintre mecanismele studiate nu respecta în totalitate cele
patru principii.
Pentru fiecare mecanism particular de specificare a interactiunilor între obiecte
concurente am propus extensii ale limbajului de programare C++ care le
implementeaza. Aceste extensii vizeaza introducerea de instructiuni sau constructii
de declarare noi si ele pot fi utilizate în dezvoltarea de aplicatii prin construirea de
preprocesoare sau compilatoare speciale. Modul de utilizare a extensiilor propuse
este exemplificat prin implementarea unei clase concurente concrete, care specifica o
coada cu numar finit de elemente.
2.2. Principii de proiectare a limbajelor de programare orientate-obiect
concurente
În programarea orientata-obiect concurenta un sistem informatic este privit ca
un model fizic de simulare a comportamentului unei parti din lumea reala sau
conceptuala. Acest model fizic este definit prin intermediul unui limbaj de
programare si el se concretizeaza într-o aplicatie ce poate fi executata pe un sistem de
calcul.
Obiectele sunt elemente cheie ale programarii orientate-obiect concurente si
ele reprezinta entitati individuale reale sau abstracte cu un rol bine definit în contextul
unui sistem. Un obiect are o identitate, o stare si un comportament. Tot ceea ce
obiectele cunosc (starea) si pot efectua (comportamentul) este exprimat prin
intermediul unor multimi de proprietati (sau atribute) si operatii (sau metode).
Astfel, starea unui obiect este data de valorile proprietatilor acestuia la un moment
dat. Operatiile sunt proceduri sau functii care permit modificarea acestor valori si
implementeaza comportamentul obiectelor.
Aplicatiile orientate-obiect concurente sunt compuse dintr-o multime de
obiecte care interactioneaza si comunica între ele prin intermediul mesajelor. Un
mesaj reprezinta o cerere adresata unui obiect de a executa o anumita operatie.
Mesajul este compus din trei elemente distincte: identitatea obiectului caruia îi este
adresat mesajul, numele operatiei care se doreste a fi executata si o lista de parametri
necesari executarii operatiei. Aceste trei informatii sunt suficiente pentru ca un obiect
care receptioneaza un mesaj sa poata executa operatia dorita. Mecanismul transmisiei
13

de mesaje permite prin urmare comunicarea între obiecte aflate în contexte (sau
procese) diferite sau pe diferite sisteme de calcul. Deoarece întreaga activitate a unui
obiect este exprimata prin intermediul operatiilor sale, mecanismul transmisiei de
mesaje poate exprima toate interactiunile posibile între obiecte.
Multimea de proprietati ale unui obiect formeaza nucleul acestuia. O parte din
operatiile sale sunt vizibile în exterior si ascund nucleul de celelalte obiecte dintr-un
sistem. Ascunderea proprietatilor interne ale unui obiect si oferirea de operatii care sa
le manipuleze poarta numele de încapsulare. Încapsularea este utilizata pentru a
ascunde detalii de implementare de alte obiecte aflate în sistem. Astfel poate fi
modificata implementarea unui obiect fara a afecta alte parti ale sistemului din care
acesta face parte. Încapsularea confera modularitate, implementarea unui obiect
putând fi modificata sau actualizata independent de implementarea celorlalte obiecte
din sistem. Multimea tuturor operatiilor unui obiect care sunt vizibile în exteriorul
acestuia poarta numele de interfata a obiectului.
Interfetele obiectelor definesc tipul acestora. Obiectele care au aceeasi
interfata apartin aceluiasi tip. Deoarece interfata este o submultime a operatiilor care
definesc comportamentul obiectelor, ea mai poarta numele de comportament extern
observabil.
Identificarea unei multimi de obiecte care au proprietati si comportamente
comune poarta numele de clasificare. Clasa este un alt concept de baza al
programarii orientate-obiect concurente, si ea reprezinta o abstractizarea a elementelor
(proprietatilor si operatiilor) comune partajate de o multime de obiecte si descrie
implementarea acestora.
Obiectele sunt reprezentari concrete ale claselor, iar procesul de creare a unui
obiect pe baza definitiei unei clase poarta numele de instantiere. De aceea în
literatura un obiect este numit si instanta a clasei care îl defineste.
Pentru a exemplifica notiunile introduse pâna în acest moment vom specifica
în cele ce urmeaza o clasa care implementeaza cozi cu numar finit de elemente, si pe
care o vom numi Coada. Proprietatile unei astfel de cozi sunt:
- maxElem - numarul maxim de elemente care pot fi stocate în coada,
- elemIntroduse – numarul elementelor introduse în coada pâna la un
moment dat,
- elemExtrase – numarul elementelor extrase din coada,
14

- listaElemente – lista circulara care contine elementele stocate în coada
(vom considera un caz general de coada, în care elementele stocate sunt
instante ale unei clase Element).
Valorile acestor proprietati vor putea fi modificate prin intermediul a doua
operatii, Adauga() si Extrage(), care adauga, respectiv extrag elemente din coada.
Figura 2.1. contine o descriere vizuala a clasei Coada, utilizând limbajul de
modelare UML (Unified Modeling Language). Notatiile grafice folosite aici sunt
descrise în detaliu în cadrul Anexei B.
Obiectul oCoada prezentat în figura 2.2. este un exemplu de instanta a clasei
Coada. Starea obiectului oCoada la momentul surprins în figura este caracterizata de
valoarea numarului maxim de elemente ce pot fi stocate (10), numarul de elemente
introduse (5), numarul elementelor extrase (3) si continutul vectorului listaElemente.
15
oCoada
maxElem : 10
elemIntroduse : 5
elemExtrase : 3
listaElemente :
0 1 2 3 4 5 6 7 8 9
Adauga() Extrage()
Figura 2.1. Modelul static al clasei Coada Figura 2.2. Descriere grafica a instantei
oCoada a clasei Coada
Dam mai jos si un exemplu de implementare a clasei Coada folosind limbajul
de programare C++ [STR91]. Codul prezentat va constitui o baza pentru descrierea
extensiilor limbajului C++ pe care le vom propune pentru implementarea
mecanismelor de sincronizare a operatiilor concurente. Proprietatea listaElemente,
implementata aici ca un tablou de elemente, simuleaza o lista circulara. Un nou
element adaugat în coada va ocupa pozitia elemeIntroduse mod maxElem, iar
extragerea unui element din coada se va realiza de pe pozitia elemeExtrase mod
maxElem.
class Coada{
protected:
Element listaElemente[]; //tablou cu elementele cozii
int maxElem; //nr. maxim de elemente din coada
int elemIntroduse; //nr. elementelor introduse în coada
int elemExtrase; //nr. elementelor extrase din coada
public:
Coada();
~Coada();

void Adauga(Element elem);
Element Extrage();
}
Coada::Coada(){
//pentru simplitate nu am definit constructor explicit
maxElem=10;
listaElemente=new [maxElem] Element;
elemIntroduse=elemExtrase=0;
}
Coada::~Coada{
delete [] listaElemente;
}
void Coada::Adauga(Element elem){
if(elemIntroduse - elemExtrase >=maxElem)
return; // eventual afisare mesaj de eroare
elemIntroduse++;
listaElemente[elemIntroduse % maxElem - 1]=elem;
}
Element Coada::Extrage(){
if(elemIntroduse - elemExtrase == 0)
return -1; // eventual afisare mesaj de eroare
elemExtrase++;
return listaElemente[elemExtrase % maxElem - 1];
}
Alaturi de notiunile de obiect si clasa, programarea orientata-obiect introduce
un mecanism puternic si natural de organizare si structurare a sistemelor informatice:
mecanismul de mostenire. Mostenirea permite definirea de noi clase (numite sub-
clase) pe baza unor clase deja existente (super-clase) într-o maniera incrementala.
Sub-clasele vor mosteni toate proprietatile si operatiile super-claselor. Relatia de
mostenire între clase induce organizarea claselor în ierarhii.
Caracterul concurent al unui limbaj de programare reprezinta capacitatea
limbajului de a exprima un paralelism potential. Limbajele de programare orientate-
obiect concurente permit implementarea de aplicatii în care doua sau mai multe
operatii apartinând obiectelor ce compun aplicatia pot fi executate în paralel, în fire de
executie distincte. Un fir de executie reprezinta un calcul ce poate fi executat în
paralel cu alte calcule. Pentru fire de executie în literatura mai sunt utilizate
termenele de activitati sau procese.
Un prim aspect deosebit de important care caracterizeaza modelele de obiecte
concurente este dat de natura relatiei dintre obiectele unui sistem si firele de executie.
Din acest punct de vedere exista trei abordari: ortogonala, omogena si eterogena.
În abordarea ortogonala obiectele si firele de executie sunt privite ca si
concepte independente. Implicit obiectele nu sunt protejate de apeluri concurente ale
operatiilor proprii (în orice moment un obiect va putea fi apelat din cadrul oricarui fir
de executie). Prin urmare protejarea starii interne a obiectelor de executiile
concurente ale propriilor operatii va trebui sa fie realizata explicit, prin intermediul
16

unor mecanisme de sincronizare de nivel scazut, specifice limbajelor de programare
procedurale cum ar fi semafoarele ([DIJ68]) sau regiunile critice conditionale
([HAN72], [HAN73]).
Abordarea omogena introduce un concept nou, si anume acela de obiect activ.
Un obiect activ este un obiect care poate controla si planifica executia propriilor
operatii. Astfel, obiectele detin fire de executie proprii care (în majoritatea modelelor
obiect omogene) sunt create implicit atunci când este receptionat un mesaj. Astfel de
obiecte pot sau nu sa fie protejate implicit de invocari concurente din exterior si
contin mecanisme specifice pentru protejarea explicita a starii interne (multimi de
activare [TOM89], abstractizarea comportamentului [PAP96], metode cu garzi
[FER95], etc).
Abordarea eterogena permite existenta în cadrul unui sistem a doua tipuri de
obiecte: active (având întelesul descris mai sus) si pasive. Obiectele pasive nu detin
fire de executie proprii, nu sunt protejate (implicit sau explicit) de apeluri concurente
din exterior, iar propriile operatii sunt executate în cadrul firelor de executie ale
obiectelor care le apeleaza.
În modelele obiect eterogene exista trei tipuri de abordari ale obiectelor pasive.
Un prim caz este acela în care în obiectele pasive nu poate exista mai mult de un fir de
executie la un moment de timp dat (astfel de obiecte sunt echivalente obiectelor
existente în cadrul limbajelor de programare orientate-obiect secventiale). Un al
doilea caz este acela al obiectelor pasive partajate, care permit executarea în interiorul
lor a mai multor fire de executie si care pot fi apelate de catre orice alt obiect din
sistem (activ sau pasiv). In fine, al treilea caz este cel al obiectelor pasive care
reprezinta o proprietate a unui obiect activ. În acest ultim caz obiectele pasive nu pot
fi apelate decât de catre obiectele active care le detin (si care vor realiza si protejarea
acestora).
Un alt element important care caracterizeaza modelele obiect pentru
concurenta implementate în diverse limbaje de programare este dat de gradul de
concurenta interna a obiectelor. Din acest punct de vedere exista modele cu obiecte
secventiale, cvasi-concurente si concurente [PAP92].
Modelele cu obiecte secventiale nu permit executia a mai mult de un fir de
executie în interiorul unui obiect. Mai mult, toate mesajele care sunt receptionate in
timpul executiei unei operatii vor fi luate în considerare doar dupa ce executia
17

espectivei operatii a luat sfârsit. Se poate spune ca în cazul acestor tipuri de modele
nu exista concurenta interna.
Modelele cu obiecte cvasi-concurente sunt caracterizate de faptul ca obiectele
pot detine mai multe fire de executie, însa numai unul dintre acestea este activ la un
moment dat. De asemenea, exista posibilitatea ca la un moment dat firul de executie
activ sa fie blocat si sa se realizeze activarea unui alt fir de executie aflat în asteptare.
Modelele cu obiecte concurente sunt cele "ideale", ele permitând existenta a
mai mult de un fir de executie în interiorul unui obiect. Firele de executie pot fi create
atât implicit cât si explicit. Cele implicite sunt create în momentul receptionarii unui
mesaj, când în cadrul noului fir de executie este executata operatia ceruta de acesta.
Crearea explicita de fire de executie se realizeaza prin intermediul asa-numitelor
mecanisme de initiere a concurentei. Majoritatea modelelor obiect pentru concurenta
propun crearea implicita a firelor de executie. Modelele care folosesc cea de-a doua
varianta utilizeaza mecanisme preluate din limbajele de programare procedurala.
Asa cum am aratat, obiectele comunica între ele prin intermediul transmiterii
de mesaje. Din punct de vedere al sursei mesajului interactiunea (comunicarea) poate
fi unidirectionala (fara primirea unui raspuns) sau bidirectionala (obiectul caruia îi
este destinat mesajul raspunde mesajului obiectului sursa). În acest ultim caz se pune
problema daca obiectul sursa asteapta raspunsul sau îsi continua activitatea, urmând a
lua în considerare raspunsul într-o faza ulterioara.
Din perspectiva obiectului destinatie, interactiunea cu obiectul sursa este
privita prin prisma acceptarii mesajului transmis de acesta si a modalitatii în care se
realizeaza acceptarea. Daca interactiunea dintre obiecte este controlata direct de catre
sistem, fara a se specifica explicit, prin mecanisme oferite de limbaj, constrângeri
privind aceasta interactiune, modelul este cu control extern. Urmatoarea categorie
este aceea a modelelor cu control mixt, în care responsabilitatea coordonarii
interactiunilor între activitatile concurente ale obiectelor este împartita între sistem si
impementarea obiectelor respective. În fine, din cea de-a treia categorie fac parte
modelele cu control reflectiv, în care constrângerile de sincronizare sunt exprimate cu
ajutorul unei meta-clase.
Sectiunile 3.3 si 3.4 contin descrierile detaliate ale mecanismelor si
primitivelor de limbaj utilizate în programarea orientata-obiect concurenta pentru
18

specificarea si coordonarea concurentei. Aceste mecanisme acopera toate categoriile
de modele de obiecte concurente descrise.
Vom enunta în continuare un set de principii pe baza carora vom realiza o
evaluare a mecanismelor analizate. Aceste principii caracterizeaza un model obiect
general, cu o putere ridicata de exprimare a interactiunii si sincronizarii activitatilor
concurente si care vizeaza pastrarea integritatii conceptelor orientate-obiect
(mostenirea, încapsularea, modularitatea etc).
Modele obiect cu cea mai mare putere de exprimare a concurentei sunt cele
care permit executarea în paralel a doua sau mai multe operatii ale aceluiasi obiect.
Pastrarea integritatii proprietatilor obiectelor asupra carora actioneaza mai multe
operatii în mod concurent presupune utilizarea de mecanisme de limbaj de
sincronizare si planificare a executiei operatiilor. Planificarea operatiilor unui obiect
poate fi realizata în functie de starea obiectului la un moment dat sau de istoricul
executiilor operatiilor acestuia. Prin urmare un prim principiu care trebuie respectat
de catre un model de obiecte concurente este ca acesta sa contina un mecanism de
specificare si interactiune între obiecte care sa permita exprimarea: a) concurentei
intra-obiect, b) executiei dependente de stare si c) executiei dependente de istoric.
Vom numi acest principiu: Principiul expresibilitatii concurentei.
Conditiile pe baza carora se realizeaza sincronizarea operatiilor concurente ale
unui obiect poarta numele de constrângeri de sincronizare. Constrângerile de
sincronizare reprezinta expresii logice în care, în general, sunt implicate proprietatile
obiectului. Pentru a evita violarea încapsularii unui obiect concurent constrângerile
de sincronizare ale operatiilor sale trebuie sa poata fi specificate la nivelul acestuia si
sa fie transparente celorlalte obiecte din sistem. Aceasta conditie naturala impusa
unui model de obiecte concurente o vom referi în continuare ca Principiul codului de
sincronizare orientat pe obiectul apelat.
Ultimele doua principii pe care le vom lua în considerare se refera la
localizarea constrângerilor de sincronizare în definirea comportamentului obiectelor
concurente. Astfel, Principiul izolarii codului de sincronizare concurenta vizeaza
detasarea codului care implementeaza functionalitatea unei operatii de codul
corespunzator descrierii constrângerilor sincronizare. De asemenea, posibilitatea de a
mosteni separat codul care implementeaza functionalitatea unei operatii si codul care
19

eprezinta constrângerea de sincronizare caracterizeaza Principiul separarii codului
de sincronizare concurenta.
Respectarea ultimelor doua principii enuntate are o importanta deosebita în
ameliorarea conflictelor care apar între mostenire si mecanismele de sincronizare
concurenta. Acest lucru va fi demonstrat prin descrierea lor într-un context formal în
cadrul capitolului 3.
2.3. Mecanisme de specificare a concurentei
În cadrul acestei sectiuni vor fi enumerate si analizate mecanismele de
specificare a concurentei în limbajele de programare orientate obiect existente pâna în
prezent si vor fi discutate avantajele si dezavantajele fiecaruia dintre acestea. Nici
unul dintre aceste mecanisme nu se distinge ca fiind net superior celorlalte, fiecare
având propriile neajunsuri. Majoritatea mecanismelor reprezinta adaptari ale
mecanismelor clasice, folosite în limbajele de programare ne-orientate obiect.
Descrieri în detaliu ale acestora fi gasite în [PHI95], [ELE91] si [GEO96].
Paralelizarea automata. Aceasta abordare a paralelismului este una extrema
si este caracterizata prin neimplicarea programatorului în activitatea de specificare a
concurentei. Programul secvential este preluat si convertit automat într-o
"reprezentare paralela". Desi nu reprezinta un mecanism propriu-zis, am luat în
considerare paralelizarea automata datorita potrivirii conceptuale perfecte cu
programarea orientata pe obiecte. Aceasta potrivire provine din neinterferenta cu
caracteristicile limbajului. În acest mod însa nu poate fi obtinut un grad ridicat de
performanta, datorita numarului ridicat de dependente între obiecte care compun o
aplicatie.
Fork-join, apeluri asincrone/variabile future, post-procesarea. Mecanismele
din aceasta categorie sunt folosite pentru lansarea a exact unei activitati concurente la
un moment de timp.
Mecanismul fork-join reprezinta prima constructie utilizata în programare
pentru specificarea concurentei la nivel de limbaj. El este foarte asemanator cu apelul
unei rutine. Rutina apelata este precedata de instructiunea fork si ea se va executa
20

concurent cu rutina care o apeleaza. De obicei, alaturi de instructiunea fork mai este
prezenta în limbaj si instructiunea join care este utila la sincronizarea activitatilor
concurente (activitatea care executa o instructiune join va fi blocata pâna la
terminarea unui proces specificat în instructiune). Dezavantajele acestui mecanism
sunt numeroase. Mentionam aici doar lizibilitatea scazuta a codului sursa si
dificultatea depanarii si întretinerii aplicatiilor realizate cu acest mecanism. Acest
fapt se datoreaza în principal nivelului scazut al instructiunii care poate fi considerata
ca o transpunere a instructiunii go to într-un mediu concurent.
Pe de alta parte, într-un context orientat-obiect acest mecanism poate
determina distrugerea încapsularii din cel putin doua motive. În primul rând
apelatorul unei rutine concurente trebuie sa se asigure ca rutina respectiva poate fi
executata în paralel cu restul firelor de executie fara a determina inconsistente ale
datelor programului. Daca pastrarea consistentei nu este garantata de catre
mecanismul de coordonare a concurentei folosit în limbajul de programare orientat pe
obiecte (iar în majoritatea cazurilor aceste mecanisme nu ofera o astfel de garantie,
dupa cum vom observa în sectiunea urmatoare), atunci apelatorul trebuie sa cunoasca
în detaliu implementarea rutinei apelate. Acest lucru, însa, va reduce dramatic
utilitatea bibliotecilor de clase.
În al doilea rând este practic imposibila modificarea codului rutinei fara a
analiza cu atentie toate secventele de cod în care aceasta rutina este lansata în paralel.
Prin urmare, rescrierea unei rutine poate determina adaugarea de noi conditii în
constrângerile de sincronizare de care apelatorul sau trebuie sa tina seama.
Apelurile asincrone de operatii cu variabile future si post-procesarea
mostenesc în principal toate aceste dezavantaje. Totusi, în cazul mecanismului de
post-procesare (deseori numit si cu retur timpuriu deoarece paralelismul este initiat
doar în momentul în care este întâlnita instructiunea return a unei rutine) poate fi
impusa o disciplina de programare care sa evite violarea încapsularii. Acest avantaj
fragil este secondat însa de o scadere a puterii de descriere a concurentei (nu pot fi
modelate anumite scenarii de concurenta între procese).
Cobegin - coend (parbegin - parend). Mecanismele din aceasta categorie
permit executia mai multor fire de executie concurente în acelasi timp. Astfel,
instructiunile care sunt cuprinse între cuvintele cheie cobegin si coend vor fi lansate
21

concurent în executie. Instructiunea cobegin reprezinta un pas înainte în structurarea
programelor concurente în raport cu instructiunea fork, dar spre deosebire de aceasta
din urma nu are aceeasi putere de descriere a concurentei.
Pe lânga avantajul unei mai bune structurari a programului acest mecanism
determina si o lizibilitate crescuta si usurinta în depanarea programelor. Din pacate,
dezavantajul privind distrugerea încapsularii obiectelor amintit si la mecanismul
anterior este prezent si în acest caz. Bineînteles, folosirea unor mecanisme potrivite
de coordonare a concurentei pot duce la restrângerea cazurilor potentiale de
interferente nedorite.
Mecanisme forall, aggregate si mecanisme echivalente. Aceste mecanisme
sunt cazuri particulare ale mecanismelor cobegin - coend. Diferenta consta în faptul
ca activitatile care sunt executate concurent se refera fiecare la câte un element
particular dintr-o anumita structura de date. Dezavantajele semnalate mai sus se
pastreaza si în cazul acestor mecanisme, dar riscul aparitiei cazurilor de violare a
încapsularii este mai scazut.
Cod autonom. Din aceasta categorie fac parte constructii de limbaj care
lanseaza o singura activitate concurenta la un moment dat, cum sunt: procesele,
rutinele autonome si rutinele active. Mecanismele prezentate pâna acum reprezinta
structuri de control care exprima paralelismul în interiorul unor fragmente de cod
secventiale. În cazul proceselor însa se realizeaza o declarare explicita a unui proces
asemanator declararii unei rutine obisnuite. Apelarea unui astfel de proces are ca
efect executia acestuia în paralel cu celelalte procese existente pâna în momentul
respectiv. În functie de limbajul de programare care ofera aceasta constructie,
procesele pot fi create static sau dinamic. Diferenta esentiala între procese si celelalte
mecanisme de specificare a concurentei este aceea ca procesele nu mai reprezinta
simple instructiuni ci sunt concepte de baza al limbajului de programare. De
asemenea, activitatile concurente vor avea întotdeauna un nume. Aceste diferente
însa nu influenteaza comportamentul mecanismului relativ la conceptele orientate-
obiect, astfel ca specificarea concurentei prin intemediul declararii explicite de
procese prezinta aceleasi dezavantaje ca si mecanismele prezentate anterior. În plus
acest mecanism determina o limitare a puterii de exprimare a concurentei [PHI95].
22

Rutinele autonome reprezinta o extensie a declararii proceselor într-un context
orientat-obiect. Astfel, în momentul în care un obiect este creat sunt lansate una sau
mai multe activitati care executa anumite operatii ale acestuia. Aceste operatii poarta
numele de rutine autonome. În functie de limbaj operatiile vor fi lansate automat
imediat dupa crearea obiectului sau vor fi necesare apeluri explicite ale acestora.
Rutinele autonome sunt prezente mai ales în limbaje de programare care utilizeaza
biblioteci de clase speciale pentru exprimarea concurentei. În astfel de limbaje exista
o clasa care defineste activitatile care vor fi lansate în paralel, iar ele pot fi reutilizate
si/sau rescrise prin intermediul mostenirii. Exista de asemenea si limbaje de
programare în care este permisa etichetarea operatiilor unei clase ca fiind rutine
autonome. Desi rutinele autonome par a fi mai bine integrate în paradigma orientata-
obiect decât procesele, ele sufera de aceleasi dezavantaje (favorizeaza distrugerea
încapsularii si a modularitatii).
O forma speciala de rutina autonoma este rutina activa. Aceasta rutina este
lansata în executie în momentul creerii obiectului si ea "supervizeaza" executia
celorlalte operatii ale obiectului. Astfel, rutina activa - numita si corp-ul clasei sau
rutina de vitalizare (life routine) - trateaza toate mesajele (sau apelurile de operatii)
lansate catre obiect. Daca rutina activa îsi înceteaza activitatea atunci obiectul nu mai
poate fi utilizat. În general codul unei astfel de rutine contine un ciclu în care sunt
receptionate toate mesajele transmise catre obiect si, în functie de anumite
constrângeri de sincronizare, lanseaza în executie operatiile obiectului
corespunzatoare mesajelor sau stocheaza aceste mesaje într-o coada de asteptare.
Simpla existenta a rutinei active într-o clasa nu poate duce însa la executarea
de activitati concurente. Concurenta poate fi obtinuta prin transmiterea asincrona a
unui mesaj de catre un obiect apelant sau prin utilizarea în cadrul rutinei active a unui
mecanism din cele amintite anterior.
Acest mecanism de specificare nu garanteaza separarea codului de
sincronizare de codul de implementare a functionalitatii (principiul al treilea enuntat
în sectiunea precedenta). Implicatiile acestui fapt vor fi discutat în detaliu în capitolul
urmator. Aici vom aminti doar ca nesepararea codului de sincronizare conduce la
imposibilitatea rescrierii unei rutine active a unei super-clase în descendentii sai fara a
cunoaste codul de implementare al acesteia (prin urmare, determina distrugerea
încapsularii).
23

Mecanismele de specificare a concurentei prezentate pot fi împartite în doua
categorii: mecanisme care pot declansa o singura activitate concurenta la un moment
dat (fork-join & mecanisme echivalente, cod autonom), respectiv mecanisme care pot
declansa un numar oarecare de activitati concurente (cobegin - coend, forall,
aggregate, etc.).
De asemenea, primele trei tipuri de mecanisme discutate (paralelizare
automata, fork-join & mecanisme echivalente, cobegin - coend) sunt orientate pe fire
de executie. Activitatile care sunt create si lansate în executie prin intermediul acestor
mecanisme nu sunt corelate cu nici o structura de date. Spre deosebire de acestea,
ultimele doua categorii de mecanisme (cod autonom, forall, aggregate, etc.) privesc
paralelismul ca fiind legat de anumite structuri de date (activitatile concurente
opereaza asupra unei structuri de date particulare sau sunt asociate sintactic de un
anumit obiect sau clasa). Mecanismele care par a se integra cel mai usor într-un cadru
orientat-obiect sunt acestea din urma. Totusi, superioritatea unuia sau altuia dintre
mecanisme nu poate fi determinata în aceasta etapa, fara sa fie luate în considerare si
mecanismele care realizeaza coordonarea concurentei.
2.4. Mecanisme de interactiune si sincronizare a obiectelor concurente
În cele ce urmeaza vom realiza o evaluare a mecanismelor de interactiune si
sincronizare între activitati concurente utilizate în peste o suta de limbaje de
programare orientate-obiect concurente. Evaluarea acestor mecanisme se va realiza în
raport cu respectarea principiilor enuntate în cadrul sectiunii 2.2. Vom propune de
asemenea extensii ale limbajului C++ care permit implementarea mecanismelor
studiate. Aceste extensii vizeaza introducerea de constructii de declarare sau
instructiuni noi si ele pot fi utilizate în dezvoltarea de aplicatii prin construirea de
preprocesoare sau compilatoare speciale. Utilizarea extensiilor este exemplificata
prin implementarea de versiuni concurente ale clasei Coada, a carei specificare a fost
data în cadrul sectiunii 2.2. Extensiile de limbaj sunt scoase în evidenta în
fragmentele de cod sursa prin utilizarea de caractere pline.
Figura 2.3 prezinta o clasificare a mecanismelor evaluate. O prima categorie
este data de mecanismele care asigura gestionarea corespunzatoare a proprietatilor
24

partajate de mai multe operatii din interiorul acestora. Mecanismele din aceasta
categorie nu impun conditii de sincronizare la nivel de obiect, iar interfetele
obiectelor vor ramâne neschimbate si sunt accesibile pe întreaga perioada de viata a
acestora. În general aceste mecanisme nu respecta principiul interactiunii orientate pe
apelant.
Mecanisme de interactiune orientate pe operatii:
sincronizare prin terminare,
semafoare, mutex si lock,
regiuni critice conditionale,
sincronizare "piggy-backed"
Mecanisme de interactiune bazate pe încapsulare:
a) mecanisme cu control extern:
monitorul,
variabile de conditie,
asteptarea conditionala
b) mecanisme cu control mixt:
coada de asteptare,
includere/excludere de metode,
abstractizarea comportamentului,
modelul Actor,
metode cu garzi,
multimi de acceptare,
expresii de cale,
rutine de vitalizare,
c) mecanisme cu control reflectiv
Figura 2.3. Clasificarea mecanismelor de interactiune si sincronizare
a obiectelor concurente
Caracteristica principala a mecanismelor de interactiune concurenta orientate
pe încapsulare este aceea ca impun un caracter dinamic interfetelor de obiecte.
Aceste mecanisme permit întârzierea executarii de operatii în functie de anumite
conditii date, întârzieri care pot fi privite ca si îndepartari temporare a operatiilor
respective din interfata unui obiect. Dupa cum sugereaza si numele, mecanismele din
aceasta categorie sunt întâlnite numai în limbajele de programare în care este definit
conceptul de încapsulare a datelor. Majoritatea acestor mecanisme au fost dezvoltate
odata cu dezvoltarea de limbaje de programare orientate-obiect concurente.
Toate mecanismele din aceasta categorie realizeaza coordonarea activitatilor
concurente la nivelul obiectelor. Diferenta majora dintre ele este data de gradul de
distributie a responsabilitatii de control al acestei coordonari între sistem si obiecte.
În functie de raspunsul dat la aceasta întrebare se pot distinge trei subcategorii
25

distincte de mecanisme de interactiune concurenta orientate pe încapsulare: cu control
extern, cu control mixt si cu control reflectiv.
Mecanismele de interactiune cu control extern sunt caracterizate de faptul ca
sistemul este cel care este direct raspunzator de interactiunea dintre obiecte. În acest
caz, coordonarea interactiunii concurente nu este specificata explicit. Astfel,
specificarea claselor de obiecte nu influenteaza ordinea de satisfacere a apelurilor
concurente de operatii si nici nu poate decide care operatie va fi executata si care nu la
un moment dat. Acest lucru este realizat implicit de catre sistem. Mecanismele care
fac parte din aceasta subcategorie respecta principiul codului de interactiune orientat
pe obiectul apelat. De asemenea, deoarece în cadrul claselor nu exista cod explicit
care sa descrie interactiunea concurenta dintre obiecte este evident faptul ca sunt
respectate si principiile cu privire la izolarea si separarea codului de interactiune. Un
dezavantaj important al acestor mecanisme rezulta din posibilitatile reduse de
specificare a concurentei, la un moment dat în cadrul unui obiect fiind permisa
executia unei singure operatii. Daca în interiorul unui obiect exista o operatie în
executie, toate celelalte mesaje de apel de operatii receptionate de obiect vor fi
amânate pâna când executia acesteia se încheie. Aceasta restrictie conduce la crearea
de programe concurente cu performante reduse.
În cazul mecanismelor cu control mixt responsabilitatea coordonarii
interactiunilor dintre activitatile concurente din cadrul unui obiect este împartita între
sistem si descrierea clasei obiectului. Astfel, codul scris pentru implementarea
obiectelor contine portiuni care au ca unic scop specificarea interactiunilor concurente
(mai precis realizarea modificarii dinamice a interfetei obiectului). Sistemul
reactioneaza la rândul sau corespunzator acestor specificari. În general mecanismele
cu control mixt respecta principiul codului de interactiune orientat pe obiectul apelat.
Mecanismele de interactiune cu control reflectiv se caracterizeaza prin
desprinderea totala a codului de interactiune de implementarea clasei. În acest caz se
pot formula constrângeri de interactiune explicit, în cadrul unor asa-numite metaclase.
În cele ce urmeaza vor fi descrise si analizate în detaliu fiecare dintre
mecanismele enumerate în figura 2.3, rezultatele evaluarii acestora fiind prezentate în
finalul capitolului într-un format tabelar.
26

2.2.1. Mecanisme de interactiune orientate pe operatii
Sincronizare prin terminare. Aproape toate mecanismele de initiere a
concurentei prezentate (exceptie facând doar cele din categoria cod autonom)
furnizeaza si o modalitate prin care o activitate poate fi blocata pâna când o alta
activitate (sau mai multe activitati) se termina. Principalul dezavantaj al acestei
primitive este faptul ca nu respecta principiul interactiunii orientate pe obiectul apelat.
Semafoare, mutex si lock. Un concept de baza al organizarii accesului
concurent la date partajate este semaforul (împreuna cu versiunile mutex si lock care
reprezinta cazuri particulare), mecanism care a fost propus de catre E. W. Dijkstra în
[DIJ68]. Un semafor este implementat prin intermediul unei variabile întregi
nenegative asupra careia sunt permise doua operatii atomice: prima operatie se
numeste P (sau wait) si ea blocheaza executia activitatii care o apeleaza pâna variabila
devine strict pozitiva dupa care o decrementeaza, iar cea de-a doua operatie, numita V
(sau signal) incrementeaza aceasta variabila. Programatorul va folosi aceste doua
operatii pentru a delimita o sectiune critica 2 .
Semafoarele sunt mecanisme de nivel scazut, cu un caracter foarte general.
Aceasta generalitate poate determina cu usurinta intrarea într-un impas daca
implementarea nu este realizata cu mare atentie, iar depanarea programelor este
evident îngreunata. Ele sunt deosebit de utile în implementari de înalta performanta la
nivel de sistem. Totusi, integrarea lor într-un mediu orientat obiect nu este o alegere
potrivita, ele nerespectând majoritatea dintre principiile enuntate anterior.
Asa cum am anticipat, acest mecanism nu respecta principiul coordonarii
orientate pe activitatea apelata, deoarece apelatorul este responsabil cu implementarea
acceptarii unui potential paralelism. În acest caz se remarca aceleasi probleme care au
fost discutate si la sincronizarea prin terminare. De aceea este posibila violarea
modularitatii si, în consecinta, este dificil de a demonstra corectitudinea implementarii
unei clase.
27

Totusi, din punct de vedere conceptual exista o modalitate de a rezolva aceasta
problema. Astfel, daca limbajul de programare permite folosirea semafoarelor doar
pentru marcarea de sectiuni critice ce se refera la proprietati private, atunci codul de
coordonare a concurentei poate fi implementat cu respectarea principiului codului de
interactiune orientat pe activitatea apelata, dar evident numai relativ la apelatorii care
fac parte din celelalte clase din domeniul aplicatiei. Nici unul dintre limbajele de
programare orientate-obiect concurente cunoscute nu suporta însa o astfel de
restrictie.
Pe de alta parte semafoarele au o putere restrânsa de specificare a
interactiunilor între fire de executie concurente. Astfel, deoarece initializarea
variabilei unui semafor poate permite executia paralela a mai multor activitati în
interiorul unei sectiuni critice este posibila implementarea concurentei intra-obiect.
Semafoarele însa nu ofera suport pentru coordonarea concurentei dependenta de
istoric. Mai mult, este dificila implementarea unei interactiuni conditionale între mai
multe activitati deoarece conditia si evaluarea acesteia trebuie simulata explicit prin
intermediul operatiilor asupra variabilei semaforului. Prin urmare semafoarele nu
ofera un suport real pentru executia dependenta de stare.
De asemenea, semafoarele nu satisfac principiul izolarii codului de
interactiune. Exemplul care urmeaza, în care este implementata clasa Coada,
ilustreaza foarte clar importanta acestui principiu. Bineînteles, nerespectarea de catre
semafoare a principiului izolarii codului de interactiune atrage automat dupa sine si
nerespectarea principiului separarii acestuia.
class Coada{
. . .
//declararea tuturor proprietatilor si a operatiilor este identica
//cu cea din exemplul de implementare secventiala
. . .
//declararea de proprietati specifice sincronizarii
//cu semafoare
private:
semaphore pozGoale;
semaphore pozPline;
semaphore secCritica1;//pt. modificare elemIntroduse
semaphore secCritica2;//pt. modificare elemExtrase
}
Implementarea cozii declarate mai sus este realizata astfel încât sa fie respectat
principiul codului de interactiune orientat pe obiectul apelat în maniera amintita mai
2 sectiune critica = fragment de cod în care se realizeaza anumite actiuni asupra unei proprietati
partajate
28

sus (adica semafoarele marcheaza sectiuni critice caracteristice unor proprietati
private ale clasei). Semafoarele pozGoale si pozPline coordoneaza adaugarea,
respectiv extragerea de elemente din coada (în functie de starea în care se afla
aceasta), iar secCritica1 si secCritica2 au rolul de a evita efectuarea de modificari
concurente asupra proprietatilor private elemIntroduse, respectiv elemExtrase precum
si realizarea în paralel a introducerii si extragerii efective de elemente. Prin urmare
exemplul surprinde atât implementarea excluderii mutuale cât si a sincronizarii
conditionale.
Coada::Coada():
pozGoale(100),
pozPline(0),
secCritica1(1),
secCritica2(1)
{
//pentru simplitate nu am definit constructor explicit
maxElem=100;
listaElemente=new [maxElem] Element;
elemIntroduse=elemExtrase=0;
}
Coada::~Coada(){
... //destructor identic cu cel din versiunea secventiala
}
void Coada::Adauga(Element elem){
pozGoale.P();
secCritica1.P();
elemIntroduse++;
listaElemente[elemIntroduse % maxElem - 1]=elem
secCritica1.V();
pozPline.V();
}
Element Coada::Extrage(){
pozPline.P();
secCritica2.P();
elemExtrase++;
Element elemTmp=listaElemente[elemExtrase % maxElem - 1];
secCritica2.V();
pozGoale.V();
return elemTmp;
}
Asa cum se poate observa din implementarea de mai sus, operatiile asupra
semafoarelor (care delimiteaza sectiunea critica) sunt efectuate în interiorul corpului
operatiilor clasei. Prin urmare, codul care descrie interactiunea concurenta nu este
separat de codul care implementeaza functionalitatea operatiilor, lucru care poate
determina aparitia asa-numitelor anomalii de mostenire în cazul reutilizarii.
La rândul lor, mecanismele mutex (derivat pe baza termenului de excludere
mutuala) si lock sunt cazuri particulare de semafoare care permit unei singure
activitati sa intre în sectiunea critica la un moment dat. Concluziile trase relativ la
29

semafoare sunt valabile si pentru aceste mecanisme care pot fi foarte usor simulate cu
operatii pe semafoare.
Regiuni critice conditionale. Regiunile critice conditionale au fost proiectate
pentru a se furniza un suport sintactic pentru sincronizarea conditionala. De
asemenea, spre deosebire de semafoare, coordonarea accesului la variabilele partajate
este mai transparent. Ideea principala în cazul regiunilor critice conditionale este
aceea de a grupa laolalta mai multe variabile în cadrul unor asa-numite resurse.
Oricare variabila poate corespunde unei singure resurse, iar declararea se face astfel:
resource r={v1, v2, ..., vn}
Regiunea critica este apoi specificata în cod astfel:
region r when { }
unde reprezinta descrierea actiunilor care urmeaza sa fie
executate de catre activitate în cazul în care este evaluata ca adevarata. În
cazul în care expresia nu este adevarata sau resursa r este ocupata de catre
o alta activitate paralela, activitatea curenta intra într-o coada de asteptare.
Implementarea versiunii concurente a clasei Coada folosind regiuni critice
conditionale este redata mai jos:
class Coada{
. . .
//declararea tuturor proprietati si a operatiilor este identica
//cu cea din exemplul de implementare secventiala
. . .
//declararea de proprietati specifice sincronizarii
//cu regiuni critice conditionale
private:
resource r1={elemIntroduse};
resource r2={elemExtrase};
}
//constructor si destructor identici cu cei din versiunea secventiala
. . .
void Coada::Adauga(Element elem){
region r1 when(elemIntroduse-elemExtrase 0){
elemExtrase++;
unElement=listaElemente[elemExtrase % maxElem - 1];
}
return unElement;
}
30

Regiunile critice conditionale se afla într-o relatie foarte strânsa cu
semafoarele ele putând fi simulate prin intermediul acestora. În concluzie regiunile
conditionale sunt caracterizate de aceleasi dezavantaje ca si semafoarele. În plus,
regiunile critice conditionale nu permit intrarea într-o anumita regiune decât a unei
singure activitati la un moment dat. Prin urmare nu se poate exprima un paralelism
intra-obiect folosind acest tip de mecanism de interactiune concurenta.
Pe de alta parte însa, existenta clauzei when în sintaxa regiunii critice
conditionale face ca acest mecanism sa fie potrivit pentru a coordona mai multe
activitati paralele în functie de starea unei instante la un moment dat.
De asemenea, regiunile critice conditionale reusesc sa elimine anumite
probleme care apar în cazul semafoarelor si care se datoreaza caracterului general al
acestora din urma. Astfel, nu apare pericolul de a ignora închiderea unei regiuni
critice, iar implementarea unor interactiuni concurente de nivel mai înalt se realizeaza
cu mai mare usurinta decât în cazul semafoarelor datorita specificarii grupate si
explicite a conditiilor.
Totusi, problemele principale ramân: în cazul în care implementarea
interactiunilor concurente nu este atent realizata se poate ajunge foarte usor la situatii
de impas, iar raspunsul la întrebarea "ce si când se încapsuleaza într-o regiune
critica?" trebuie sa fie dat în continuare de catre programator.
Sincronizare "piggy-backed". În limbajele de programare în care
comunicarea între activitatile paralele se realizeaza prin transmitere de mesaje,
executarea paralela a activitatilor este sincronizata de obicei prin comenzi de blocare a
comunicarii. Sa consideram spre exemplu urmatoarea intructiune care are ca efect
punerea activitatii curente în asteptare pâna când este receptionat mesajul m (sintaxa
instructiunii poate permite si specificarea sursei care transmite mesajul). :
receive m [from s]
O situatie similara are loc si în cazul în care este utilizata o abordare de tip
"apel invers". În locul unei instructiuni receive explicite de acceptare a unui mesaj,
este furnizata o operatie care este apelata de s. În ambele cazuri raspunsul activitatii
acceptate este coordonat cu activitatea de transmitere.
Majoritatea limbajelor de programare orientate-obiect concurente care se
bazeaza pe apeluri asincrone de operati, mesaje si variabile future (discutate în
31

sectiunea anterioara) ofera posibilitatea sincronizarii de tip "piggy-backed". Din
nefericire acest tip de sincronizare necesita cunoasterea cu exactitate a protocolului de
apelare. Apelatorul trebuie sa stie ce mesaj este asteptat de catre obiectul tinta.
Deoarece acest tip de informatie nu este accesibila prin intermediul interfetei
obiectului "apelat"; este necesar ca apelatorul sa cunoasca anumite detalii privind
implementarea obiectului apelat. Prin urmare nu este respectat principiul orientarii
codului de sincronizare pe obiectul apelat. Din aceasta cauza nu sunt respectate nici
principiile izolarii si a separarii codului de interactiune.
Mai mult, sincronizarea "piggy-baked" permite acceptarea unui singur mesaj
la un moment dat, ceea ce înseamna ca nu poate fi folosita pentru exprimarea
concurentei intra-obiect. Bineînteles, acest mecanism este capabil sa implementeze o
interactiune inter-activitati dependenta de starea obiectului.
Deoarece si acest mecanism de comunicare (ca si regiunile critice
conditionale) poate fi modelat cu ajutorul semafoarelor, dezavantajele amintite la
acestea din urma sunt valabile si pentru sincronizarea "piggy-baked".
2.2.2. Mecanisme de interactiune concurenta bazate pe încapsulare
a) Mecanisme de interactiune concurenta cu control extern
Monitorul. Din punctul de vedere al unui programator de aplicatii concurente
monitorul poate fi considerat ca si o combinatie sintactica între definirea unei resurse
(v. regiunile critice conditionale) si operatiile care sunt aplicate asupra variabilelor
dintr-o resursa, la un moment dat putând fi executata o singura operatie asupra unei
variabile din resursa respectiva. Din perspectiva unui programator de aplicatii
orientate-obiect monitorul poat fi privit ca si un obiect ce poseda propriile variabile
(prorpietati) care îi definesc starea si furnizeaza metode (operatiile asupra
proprietatilor) prin apelarea carora poate fi modificata aceasta stare.
Desi monitoarele satisfac majoritatea principiilor care au fost enuntate în
sectiunea 2.2, ele sunt caracterizate printr-o putere scazuta de exprimare a
concurentei. Acest lucru este determinat, asa cum am mentionat mai devreme, de
faptul ca este permisa executia doar a unei singure metode dintr-un monitor la un
moment dat. Mai mult, monitoarele nu pot fi utilizate în implementarea de
32

sincronizari conditionale, si deci nu poate fi realizata o sincronizare inter-activitati
dependenta de starea monitorului (mai exact, starea obiectului reprezentat printr-un
monitor) la un moment dat. "Greutatea" acestui dezavantaj poate fi masurata prin
prisma unui exemplu ce va fi dat în cele ce urmeaza si care implementeaza o clasa
Coada folosind monitorul ca mecanism de interactiune intre activitatile concurente.
class monitor Coada{
protected:
Element listaElemente[]; //tablou cu elementele cozii
int maxElem; //nr. maxim de elemente din coada
int elemIntroduse; //nr. elementelor introduse în coada
int elemExtrase; //nr. elementelor extrase din coada
public:
Coada(){…};
~Coada(){…};
void Adauga(Element elem) {…};
Element Extrage(){…};
BOOL EGoala(return elemIntroduse-elemExtrase==0;);
BOOL EPlina(return elemIntroduse-elemExtrase==maxElem;)
}
Daca monitorul permitea modelarea sincronizarii conditionale atunci, în
momentul în care un obiect de tip Coada ar fi fost în starea plin (adica au fost
introduse în coada cu maxElemente mai multe elemente decât au fost extrase) si ar fi
receptionat un mesaj Adauga(), mesajul respectiv ar fi fost pus într-o coada de
asteptare urmând ca, dupa extragerea a cel putin unui element, mesajul sa fie acceptat.
Din pacate monitorul nu poseda nici o modalitate de specificare a activarii sau
inactivarii unei operatii pe baza unei conditii. Pozitionarea mesajelor într-o coada de
asteptare se realizeaza strict pentru respectarea excluderii mutuale.
Astfel, pentru a se tine cont de starea unui obiect, trebuiesc definite în clasa
Coada doua metode care sa poata fi folosite la inspectarea acestei stari - EGoala(),
respectiv EPlina(). Cele doua metode vor fi folosite de catre obiectele care doresc
introducerea sau extragerea de elemente dintr-un obiect de tip Coada. Acest lucru
însa implica nerespectarea principiului implementarii codului de interactiune în cadrul
obiectului apelat.
Un alt dezavantaj major al monitoarelor este acela ca în cazul unei utilizari
neglijente ele pot conduce cu usurinta, asemanator semafoarelor, la situatii de impas.
Aceasta problema este cunoscuta în literatura de specialitate si sub denumirea de
problema apelului monitoarelor încastrate (nested monitors call).
33

Variabile de conditie. Variabilele de conditie reprezinta o extensie a
conceptului de monitor si ele au fost introduse de C. A. R. Hoare în 1974 [HOA74].
Prin aceasta extensie o activitate intrata într-un monitor poate fi blocata în interiorul
acestuia cu ajutorul unei variabile de conditie. Cât timp aceasta activitate este blocata
se poate da curs unui solicitari de apel de operatie care se afla în coada de asteptare a
monitorului. O variabila de conditie are doua operatii, wait si signal, care pot
determina blocarea sau deblocarea unei activitati. Problema care apare este data de
alegerea algortimului de decizie în cazul deblocarii a doua sau mai multe activitati în
acelasi timp (deoarece, asa cum am vazut, într-un monitor poate fi activa cel mult o
activitate). De asemenea, trebuie stabilit daca activitatea care a generat deblocarea îsi
va continua executia pâna la iesirea din monitor dupa care va fi reactivata una dintre
operatiile deblocate sau, dimpotriva, activitatea curenta va fi suspendata pâna când
vor parasi monitorul activitatile deblocate de acesta.
Câstigul evident al extinderii monitorului cu variabile de conditie este acela ca
pot fi modelate sincronizari conditionale între activitati concurente. Prin urmare pot fi
modelate interactiuni concurente în functie de starea monitorului la un moment dat.
class monitor Coada{
. . .
//declararea tuturor proprietati si a operatiilor este identica
//cu cea din exemplul de implementare secventiala
. . .
//declararea de proprietati specifice sincronizarii
//cu variabile de conditie
private:
condition Gol;//variabila de conditie pentru coada goala
condition Plin;//variabila de conditie pentru coada plina
}
void Coada::Adauga(Element elem){
if(elemIntroduse-elemExtrase==maxElem)
Plin.wait();
elemIntroduse++;
listaElemente[elemIntroduse % maxElem - 1]=elem
Gol.signal();
}
Element Coada::Extrage(){
if(elemIntroduse-elemExtrase==0)
Gol.wait();
elemExtrase++;
Element elemTmp=listaElemente[elemExtrase % maxElem - 1];
Plin.signal();
return elemTmp;
}
Implementarea unei cozi cu numar limitat de elemente folosind variabilele de
conditie sugereaza o asemanare dintre aceasta abordare de modelare a interactiunilor
concurente si abordarea folosind semafoare.
34

Aceasta asemanare nu este întâmplatoare (dupa cum nu este întâmplator nici
faptul ca operatiile care corespund variabilelor de conditie poarta acelasi nume ca si
operatiile corespunzatoare semafoarelor) dar nici benefica. Prin urmare, extinderea
monitorului în aceasta maniera este caracterizata de aceleasi dezavantaje ce
caracterizeaza si semafoarele. Astfel, deoarece codul corespunzator coordonarii
interactiunii concurente se implementeaza intercalat cu codul de implementare a
functionalitatii operatiilor nu mai sunt respectate principiile izolarii si separarii
codului de interactiune concurenta.
De asemenea, este evident mai dificil de demonstrat corectitudinea unei clase
astfel implementate. Trebuie remarcat si faptul ca, în cazul în care variabilele de
conditie sunt publice (deci sunt vizibile în afara monitoarelor în care au fost definite)
poate fi încalcat cu usurinta principiul care enunta faptul ca specificarea interactiunii
între obiecte concurente trebuie sa fie realizata exclusiv în cadrul entitatii apelate.
Asteptare conditionala. Conceptul de asteptare conditionala a fost introdus tot
în scopul extinderii monitoarelor pentru a putea fi modelate sincronizari conditionale
inter-activitati. Acest concept a fost introdus de catre Kessels în anul 1977 [KES77]
si este caracterizat de separarea sintactica în cadrul monitorului a conditiilor de
sincronizare:
condition is ;
În urma unei declaratii ca cea de mai sus se poate introduce într-una dintre
operatiile monitorului linia de cod wait() ce are ca efect întârzierea
executiei activitatii curente care a apelat operatia respectiva pâna în momentul
verificarii conditiei data de . Prin aceasta metoda se pot determina cu
usurinta care sunt portiunile de cod ce modeleaza sincronizarea concurenta. Din
nefericire si în acest caz riscul blocarii unei activitati sau al intrarii într-o situatie de
impas este la fel de crescut. De asemenea, nu poate fi determinata activitatea care va
fi executata în cazul în care sunt mai multe activitati blocate de aceeasi conditie iar
conditia este îndeplinita în momentul executiei unei alte activitati.
Implementarea unei cozi limitate folosind monitoare extinse cu variabile de
asteptare conditionala se poate realiza în maniera de mai jos:
class monitor Coada{
. . .
//declararea tuturor proprietatilor si a operatiilor este
//identica cu cea din exemplul de implementare secventiala
35

. . .
//declararea de proprietati specifice sincronizarii
//prin asteptare conditionala
private:
//conditia ce este respectata cand coada nu e goala
condition nuGol is not (elemIntroduse-elemExtrase==0);
//conditia ce este respectata cand coada e nu plina
condition nuPlin is not (elemIntroduse-elemExtrase==maxElem);
}
void Coada::Adauga(Element elem){
wait(nuPlin);
elemIntroduse++;
listaElemente[elemIntroduse % maxElem - 1]=elem
}
Element Coada::Extrage(){
wait(nuGol);
elemExtrase++;
Element elemTmp=listaElemente[elemExtrase % maxElem - 1];
return elemTmp;
}
În cadrul acestei implementari am tinut cont de faptul ca mecanismul de
monitor este bazat pe principiul "o singura activitate executata la un moment de timp
dat". În cazul în care se doreste modelarea unui paralelism intra-obiect este necesara
includerea variabilelor care compun în sectiuni critice, în caz contrar
valoarea de adevar rezultata în urma evaluarii conditiei din nemaifiind
certa. Introducerea unor astfel de sectiuni critice conduce la aparitia unor dezavantaje
asemanatoare cu cele care au fost semnalate la semafoare si variabile de conditie.
Principiul codului de interactiune orientat pe obiectul apelat este respectat de
acest mecanism doar în cazul evident în care identificatorii ce reprezinta conditiile
împreuna cu toate variabilele care compun conditiile respective sunt proprietati
private ale obiectului.
Nu poate fi modelata interactiunea concurenta dependenta de istoric. De
asemenea prezenta codului ce descrie interactiunea concurenta în cadrul codului care
descrie functionalitatea operatiei determina nerespectarea principiilor izolarii si
separarii codului de sincronizare.
b) Mecanisme de interactiune concurenta cu control mixt
Coada de asteptare. Anumite limbaje de programare orientate-obiect
concurente permit programatorilor sa defineasca instante ale unei clase mai speciale,
numita Coada_de_asteptare. Aceste instante pot fi atasate operatiilor unei clase si ele
au ca efect scoaterea, respectiv introducerea dinamica a operatiilor respective în
36

interfata publica a obiectelor clasei. Interfata clasei Coada_de_asteptare este
compusa din doua operatii: blocheaza(), respectiv deblocheaza(). Daca, de exemplu,
o instanta a acestei clase este deblocata, atunci se da curs oricarei solicitari de apel al
operatiilor atasate instantei, în caz contrar apelurile fiind întârziate.
Coada_de_intarziere CI;
Operatie()/CI {. . .};
În exemplul de mai sus operatia Operatie() este atasata cozii de asteptare CI.
Daca CI este blocata, apelul operatiei Operatie() este amânat. Apelul poate fi realizat
din momentul în care are loc deblocarea variabilei CI (deblocare ce poate fi realizata
doar de catre o activitate care apeleaza una dintre operatiile neblocate ale clasei). Este
important de subliniat ca este permisa legarea mai multor operatii ale aceluiasi obiect
la o aceeasi coada de asteptare.
class Coada{
protected:
Element listaElemente[]; //tablou cu elementele cozii
int maxElem; //nr. maxim de elemente din coada
int elemIntroduse; //nr. elementelor introduse în coada
int elemExtrase; //nr. elementelor extrase din coada
public:
//cozi de intarziere care vor fi blocate in momentul
//in care obiectul Coada va fi plin, respectiv gol.
Coada_de_asteptare nuEPlin;
Coada_de_ asteptare nuEGol;
. . .
}
void Coada::Adauga (Element elem)/nuEPlin {
elemIntroduse++;
listaElemente[elemIntroduse % maxElem - 1]=elem
nuEGol.deblocheaza();
if(elemIntroduse- elemExtrase==0)
nuEPlin.blocheaza();
}
Element Coada::Extrage()/nuEGol{
elemExtrase++;
Element elem= listaElemente[elemExtrase % maxElem - 1];
nuEPlin.deblocheaza();
if(elemIntroduse- elemExtrase==0)
nuEGol.blocheaza();
return elem
}
Cozile de asteptare respecta principiul al doilea enuntat la începutul acestei
sectiuni daca variabilele de tip Coada_de_asteptare sunt private. În caz contrar exista
posibilitatea blocarii sau deblocarii acestor variabile din exteriorul obiectului, si deci
influentarea interactiunii concurente ale operatiilor unei clase de catre activitatile
apelatoare.
37

Deoarece cozile de asteptare pot fi blocate sau deblocate pe baza unor conditii
este evident faptul ca se poate modela o interactiune de tip "sincronizare
conditionala". De aici rezulta faptul ca activitatile concurente care ajung în interiorul
unui obiect pot fi coordonate pe baza starii în care se afla obiectul. Cozile de
asteptare, însa, nu pot specifica interactiuni dependente de istoricul apelurilor
anterioare de operatii.
În plus acest mecanism a fost gândit pe baza aceleasi restrictii prezente si în
cazul monitorului: este permisa executia unei singure activitati la un moment dat în
interiorul unui obiect. Acest lucru usureaza, asa cum am vazut, demonstrarea
corectitudinii programelor orientate-obiect concurente dar limiteaza performantele
paralele ale acestora. Extinderea acestui mecanism pentru a putea permite executia
unui numar arbitrar de activitati paralele presupune practic introducerea unui nou
mecanism de interactiune concurenta (care sa nu permita blocari si/sau deblocari
concurente a unei cozi de asteptare), lucru care va determina o crestere a complexitatii
programelor si a metodelor de demonstrare a corectitudinii acestora. Mai mult,
mecanismul va fi mai degraba unul orientat pe activitati decât bazat pe încapsulare,
mostenind astfel toate dezavantajele amintite la aceasta categorie de mecanisme.
Daca mai adaugam si faptul ca liniile de cod corespunzatoare coordonarii
interactiunilor concurente nu respecta principiul izolarii si nici cel al separarii putem
trage concluzia ca acest mecanism, desi la prima vedere elegant si expresiv
favorizeaza distrugerea încapsularii.
Includere/excludere de operatii. Limbajele de programare orientate-obiect
concurente care contin acest tip de mecanism permit programatorului sa includa sau
sa excluda operatii din operatiile publice ale obiectelor (si care constituie interfata
dinamica a acestora). Astfel, apelul unei operatii care este exclusa din interfata unui
obiect este blocat pâna la reintroducerea acesteia în interfata. Spre deosebire de
mecanismul anterior acest mecanism presupune existenta unei singure cozi de astfel
de apeluri. Nu exista posibilitatea combinarii mai multor operatii care au constrângeri
de interactiune similare într-o unica coada, iar excluderea sau includerea fiecarei
operatii în coada trebuie sa fie facuta individual (din nou, în contrast cu coada de
asteptare).
38

Pentru exemplul studiat pâna acum, si anume implementarea unei clase pentru
o coada cu numar limitat de elemente, este evident faptul ca operatia Extrage() nu se
afla în interfata în momentul creerii unei instante a clasei Coada (deoarece initial
coada este goala). Am presupus în acest exemplu faptul ca initial toate operatiile
publice ale clasei sunt incluse în interfata si ca includerea, respectiv excluderea
operatiilor din interfata se realizeaza prin intermediul a doua functii globale,
INCLUDE(), respectiv EXCLUDE() ale caror parametrii sunt nume de operatii. O
restrictie care trebuie sa fie impusa acestui mecanism este interzicerea ca destructorul
si constructorii sa fie exclusi din interfata.
class Coada{
//declaratia clasei Coada este identica cu
//cea din cazul secvential
protected:
. . .
public:
. . .
}
Coada::Coada(){
//pentru simplitate nu am definit constructor explicit
maxElem=100;
listaElemente=new [maxElem] Element;
elemIntroduse=elemExtrase=0;
EXCLUDE(Extrage);
}
void Coada::Adauga(Element elem){
elemIntroduse++;
listaElemente[elemIntroduse % maxElem - 1]=elem
if(elemIntroduse - elemExtrase == maxElem)
EXCLUDE(Adauga);
INCLUDE(Extrage);
}
Element Coada::Extrage(){
elemExtrase++;
Element elem=listaElemente[elemExtrase % maxElem - 1];
if(elemIntroduse - elemExtrase == 0)
EXCLUDE(Extrage);
INCLUDE(Adauga);
return elem;
}
Desi dintr-un anumit punct de vedere codul de interactiune pare a fi separat de
codul care descrie functionalitatea, totusi functiile INCLUDE() si EXCLUDE() sunt
apelate din interiorul operatiilor. Prin urmare nu sunt respectate principiile izolarii si
ale separarii codului de interactiune, fapt care poate determina aparitia unor anomalii
(rescrieri complete ale unor operatii, etc.) în cazul reutilizarii clasei.
Este evident ca se respecta principiul dependentei codului de interactiune de
obiectul apelat si ca poate fi realizata o interactiune concurenta dependenta de starea
obiectului. Din pacate nici acest mecanism nu permite exprimarea concurentei intra-
39

obiect, fiind admisa executia a doar unei singure operatii a unui obiect la un moment
dat. Argumentele care au determinat necesitatea unei astfel de restrictii sunt comune
cu cele din cazul mecanismului cu coada de asteptare.
Abstractizarea comportamentului. Introducerea în limbajele de programare
orientate-obiect concurente a mecanismului de abstractizare a comportamentului
ofera programatorilor posibilitatea de a specifica mai multe interfete pentru un obiect,
interfete care se pot permuta dinamic în functie de necesitati [PAP96], [PAP97].
Daca în precedentele doua mecanisme acest lucru se realizeaza direct, în cadrul
mecanismului de abstractizare comportamentala modificarea dinamica a interfetei se
face prin intermediul unui concept nou pentru un limbaj de programare, si care poarta
numele de stare.
Figura 2.4. Descrierea comportametului clasei Coada folosind formalismul hartilor de stari
O astfel de abordare este foarte apropiata de tehnica modelarii
comportamentului unei clase folosita în metodele de analiza si proiectare orientate-
obiect. Astfel, înainte de a implementa o clasa programatorul va trebui sa faca o
analiza a comportamentului acesteia, sa specifice (folosind hartile de stari descrise de
David Harel sau variante ale acesteia) starile în care se poate gasi o instanta a clasei si
sa determine pentru fiecare stare în parte operatiile care pot fi apelate. Vom anticipa o
astfel de analiza prin intermediul unui exemplu de modelare cu ajutorul hartilor de
stari a comportamentului clasei Coada (figura 2.4), urmând ca în cadrul capitolului 4
sa tratam în detaliu acest formalism vizual. Semantica notatiilor utilizate în figura 2.4
este explicata de asemenea si în Anexa B.
40

Din diagrama prezentata în figura 2.4 deducem ca un obiect al clasei Coada se
poate afla într-una din urmatoarele stari: Gol, Plin sau Partial. Implementarea clasei
Coada realizata pe baza acestei diagrame defineste aceste trei stari în cadrul sectiunii
behavior si modifica starea obiectelor folosind instructiunea become asupra
identificatorului starii tinta. Constructorii si destructorul se considera ca facând parte
din interfata obiectului indiferent de stare.
class Coada{
protected:
Element listaElemente[]; //tablou cu elementele cozii
int maxElem; //nr. maxim de elemente din coada
int elemIntroduse; //nr. elementelor introduse în coada
int elemExtrase; //nr. elementelor extrase din coada
public:
Coada();
~Coada(){ . . . };
void Adauga(Element elem);
Element Extrage();
//definirea starilor clasei
behavior:
Plin = {Extrage};
Gol = {Adauga};
Partial = {Extrage, Adauga};
}
Coada::Coada(){
//pentru simplitate nu am definit constructor explicit
maxElem=100;
listaElemente=new [maxElem] Element;
elemIntroduse=elemExtrase=0;
become Gol;
}
void Coada::Adauga(Element elem){
elemIntroduse++;
listaElemente[elemIntroduse % maxElem - 1]=elem;
if (elemIntroduse - elemExtrase == maxElem)
become Plin;
else
become Partial;
}
Element Coada::Extrage(){
elemExtrase++;
Element elem=listaElemente[elemExtrase % maxElem - 1];
if (elemIntroduse - elemExtrase == 0)
become Gol;
else
become Partial;
return elem;
}
Codul de coordonare a interactiunilor concurente este într-un anumit fel mai
izolat. Totusi ramân instructiunile become care sunt executate în cadrul codului ce
descrie functionalitatea unei clase. Prin urmare nici în acest caz nu sunt respectate
principiile izolarii si separarii codului de interactiune.
Evident mecanismele bazate pe abstractizari de comportament respecta
principiul codului de interactiune orientat pe apelat. Mai mult, datorita conceptului de
41

stare nou introdus, aceste mecanisme permit descrierea de interactiuni dependente de
stare si dependente de istoric.
Un alt avantaj al acestei abordari este acela ca, spre deosebire de cozile de
asteptare sau mecanismele cu includere/excludere de operatii unde sunt precizate la
un moment dat doar operatiile care sunt introduse sau scoase din interfata la
momentul respectiv, în cazul abstractizarii comportamentului se cunoaste în fiecare
moment continutul acestei interfete.
Mecanismul abstractizarii comportamentului este caracterizat de acelasi
neajuns ca si cozile de asteptare sau mecanismul de include/excludere de operatii, si
anume acela ca permite executia unei singure activitati la un moment dat în interiorul
unui obiect.
De asemenea, la implementarea unor descendenti ai unei clase în care s-au
folosit abstractizari de comportament, diagramele de stari ale acestora pot diferi destul
de mult de diagrama de stari a clasei parinte. Din acest motiv în multe cazuri este
necesara rescrierea operatiilor clasei parinte, rescriere ce poate implica cunoasterea
codului operatiei corespunzatoare din clasa parinte, adica distrugerea modularitatii.
Modelul Actor. Mecanismele de specificare si coordonare a interactiunilor
concurente din modelul Actor [AGH86] pur combina conceptul de obiect cu
conceptul de interfata dinamica. Astfel, modificare interfetei unui obiect (numit
actor) are ca efect transformarea acestuia intr-un nou obiect care va avea un
comportament diferit. Noul actor poate fi implementat printr-o clasa diferita de cea a
vechiului actor. Practic, în modelul Actor nu sunt specificate dinamic operatiile care
sunt disponibile sau nu, ci este selectat în mod dinamic un nou comportament.
În exemplul anterior folosit pentru a prezenta mecanismele ce contin
abstractizari de comportament am distins trei stari în care se poate afla la un moment
dat un obiect al clasei Coada. În limbajele bazate pe modelul Actor fiecarei stari din
cele trei îi corespunde o clasa! În timpul executiei un obiect poate apartine la un
moment dat unei singure clase din cele trei.
//clasa actor Coada_Plina
actor Coada_Plina{
protected:
Element listaElemente[]; //tablou cu elementele cozii
int maxElem; //nr. maxim de elemente din coada
int elemIntroduse; //nr. elementelor introduse în coada
public:
42

}
Coada_Plina(int mE, int eIn, Element* lista){. . .};
~Coada_Plina(){ . . .};
Element Extrage();
Element Coada_Plina::Extrage()
{
. . .
become Coada_Partiala(maxElem, elemIntroduse,
(elemIntroduse-maxElem+1), listaElemente);
. . . //returnarea unei valori
}
//clasa actor Coada_Partiala
actor Coada_Partiala{
protected:
//aceleasi proprietati ca in cazul cozii pline +
int elemExtrase; //nr. elementelor extrase din coada
public:
Coada_Partiala(int mE,int eIn,int eEx,Element* lista);
~Coada_Partiala(){ . . .};
void Adauga(Element elem);
Element Extrage();
}
Coada_Partiala::Coada_Partiala(int mE,int eIn,int eEx,Element* lista)
{
if(eIn-eEx==mE)
become Coada_Plina(mE,mIn,lista);
if(eIn-eEx==0)
become Coada_Goala(mE,mIn,lista);
//initializarea proprietatilor
. . .
}
Element Coada_Partiala::Extrage()
{
. . .
if(elemIntroduse-elemExtrase==0)
become Coada_Goala(maxElem,elemIntroduse,listaElemente);
. . . //returnarea unei valori
}
void Coada_Partiala::Adauga(Element elem)
{
. . .
if(elemIntroduse-elemExtrase==maxElem)
become Coada_Plina(maxElem,elemIntroduse,listaElemente);
}
//clasa actor Coada_Goala
actor Coada_Goala{
protected:
//aceleasi proprietati ca in cazul cozilor anterioare
. . .
public:
Coada_Goala(int mE,int eIn, Element* lista){. . .};
~Coada_Goala(){ . . .};
void Adauga(Element elem);
}
void Adauga(Element elem)
{
become Coada_Partiala(maxElem, elemIntroduse,
(elemIntroduse+1), listaElemente);
}
Pentru ca implementarea bazata pe modelul Actor sa fie functionala am
adaugat fiecareia dintre cele trei clase câte un constructor explicit care este necesar în
43

momentul în care obiectul trece dintr-o clasa în alta. De asemenea, constructor
implicit este definit doar pentru clasa Coada_Goala pentru simplitate. Se poate
observa din aceasta implementare ca pentru clasa Coada_Plina nu este definita
operatia Adauga(), respectiv pentru clasa Coada_Goala operatia Extrage(). Pentru a
realiza schimbarea clasei pentru un actor am folosit, ca si în cazul mecanismului de
interactiune concurenta prin abstractizarea comportamentului, intructiunea become.
Privite în context orientat-obiect mecanismele bazate pe modelul Actor au
doua mari neajunsuri. În primul rând mostenirea este dificil de implementat, deoarece
în momentul în care se doreste definirea unei subclase cu un comportament
specializat, este necesara redefinirea fiecarui actor ce corespunde unei stari în parte.
Mai mult, în timpul executiei un actor se poate transforma într-un altul cu un
comportament total diferit. Aceste neajunsuri au determinat ca majoritatea limbajelor
de programare bazate pe actori sa nu implementeze conceptul de mostenire.
În al doilea rând, asa cum se poate observa si din exemplul cu implementarea
unei cozi limitate, nu este clar ce se întâmpla în momentul în care un actor se afla în
starea Coada_Plina si receptioneaza mesaj Adauga(). În general nu se ofera nici o
indicatie în ceea ce priveste faptul ca într-o alta stare actorul respectiv ar putea
raspunde acestui mesaj. Prin urmare majoritatea limbajelor cu actori nu realizeaza
introducerea mesajelor într-o coada de asteptare.
Si pentru acest mecanism principiul orientarii pe obiectul apelat al codului de
interactiune este respectat, iar principiile izolarii si separarii acestui cod nu. De
asemenea, modelul Actor este un model bazat pe principiul "o singura activitate
executata la un moment dat". Totusi o concurenta intra-obiect mai restrânsa poate fi
modelata folosind post-procesarea discutata în sectiunea 2.3. Astfel, imediat dupa
executarea unei instructiuni become poate fi acceptat apelul unei alte operatii, în timp
ce operatia curenta îsi continua executia. Din pacate, pentru a fi pastrata consistenta
starii actorului, operatia care eventual se va executa în paralel cu cea curenta trebuie
sa fie o operatie ce nu modifica în nici un mod starea obiectului (în acest context prin
starea obiectului am înteles un tuplu de valori corespunzatoare tuturor proprietatilor
actorului, asa cum a fost ea definita în sectiunea 2.2, si nu starea abstracta definita mai
devreme în cadrul mecanismului de abstractizare a comportamentului).
44

Metode cu garzi. Metodele cu garzi reprezinta o modalitate de coordonare a
interactiunilor concurente bazata pe modelul preconditiilor [MEY93]. Astfel, o
operatie a unei clase poate avea atasata o conditie care este evaluata înainte ca
operatia sa fie executata. Daca respectiva conditie nu este îndeplinita, apelul operatie
este întârziat, intrând într-o coada de asteptare.
class Coada{
protected:
Element listaElemente[]; //tablou cu elementele cozii
int maxElem; //nr. maxim de elemente din coada
int elemIntroduse; //nr. elementelor introduse în coada
int elemExtrase; //nr. elementelor extrase din coada
public:
Coada();
~Coada();
void (elemIntroduse-elemExtrase!=maxElem) Adauga(Element elem);
Element (elemIntroduse-elemExtrase!=0) Extrage();
}
Mecanismul de metode cu garzi are la rândul sau la baza principiul executiei
exclusive a operatiilor. Prin urmare o singura operatie a unui obiect va fi executata la
un moment dat. Exista însa limbaje de programare care ofera posibilitatea modelarii
concurentei intra-obiect folosind acest mecanism prin introducerea în cadrul unei
conditii a asa-numitelor constrângeri de concurenta, care sunt folosite pentru a filtra
operatiile ce pot fi executate concurent cu operatia curenta. Au fost implementate
pâna în prezent doua concepte care ofera posibilitatea realizarii acestei filtrari, si
anume contoarele si listele de operatii compatibile.
Contoarele reprezinta functii predefinite care pot fi utilizate în interiorul
conditiilor atasate unor operatii. Aceste contoare pot determina numarul de operatii
active la un moment dat (pentru toate operatiile sau doar pentru o operatie
particulara), numarul de invocari sau numarul de executii complete ale unor operatii.
Bineînteles toate aceste contoare sunt actualizate automat de catre sistem.
Unele limbaje de programare, printre care si limbajul CEiffel [LÖH93], permit
specificarea în interiorul conditiilor de interactiune a numelor de operatii din clasa
respectiva care pot fi executate concurent cu operatiile atasate lor. O lista de astfel de
nume de operatii poarta numele de lista de operatii compatibile.
Desi la prima vedere codul de interactiune concurenta este izolat, el este
influentat de modificarile proprietatilor obiectelor, modificari ce se realizeaza în
cadrul codului de descriere a functionalitatii. Exista limbaje de programare (de
exemplu SOS [MCH94]) în care se permite specificarea a doua tipuri de proprietati
45

pentru o clasa. Conditiile care joaca rol de garzi de metode pot face apel doar la un
tip de proprietati, ceea ce conduce la izolarea codului de coordonare concurenta în
adevaratul sens al cuvântului.
Un mare avantaj al metodelor cu garzi consta în faptul ca operatiile si
conditiile lor pot fi mostenite sau rescrise separat (este respectat principiul separarii).
Totusi, si acest mecanism genereaza un anumit tip de anomalii de mostenire deoarece
în anumite cazuri, trebuie ca la rescrierea unei conditii sa se cunoasca implementarea
acesteia în clasa parinte, lucru care determina distrugerea modularitatii ierarhiei de
clase.
În varianta originala metodele cu garzi nu pot exprima interactiuni concurente
dependente de istoricul apelurilor de operatii. Exista însa extensii care permit
introducerea în garzile operatiilor a unor expresii de logica temporala [FER95].
Metodele cu garzi reprezinta unul dintre mecanismele cele mai populare si
elegante folosite la implementarea interactiunilor activitatilor concurente. De
asemenea, luând în considerare si extensiile amintite mai sus, acest mecanism
respecta toate principiile enuntate la începutul acestei sectiuni.
Multimi de acceptare. Una dintre problemele care apar în cadrul
mecanismului de abstractizare a comportamentului este aceea ca determinarea
urmatoarei stari este posibil sa se realizeze în urma unei analize destul de complexe.
Acest fapt poate implica necesitatea rescrierii nejustificate a unor operatii în cadrul
claselor derivate.
În aceste mecanisme multimile de acceptare ([TOM89]) sunt considerate ca
fiind concepte de prima-clasa, adica ele pot fi transmise ca parametru de operatie sau
pot fi returnate ca si rezultat al unor functii. Astfel, instructiunea become poate fi
utilizata în acest caz alaturi de un nume de operatie care returneaza o multime de
acceptare. Analiza complexa este efectuata în cadrul unei astfel de operatii. Pentru
clasele derivate modificarea comportamentului are ca efect doar modificarea acestor
operatii.
Implementarea clasei Coada folosind multimi de acceptare va fi realizata pe
baza starilor determinate la exemplul de folosire a abstractizarii comportamentului.
class Coada{
protected:
Element listaElemente[]; //tablou cu elementele cozii
46

int maxElem; //nr. maxim de elemente din coada
int elemIntroduse; //nr. elementelor introduse în coada
int elemExtrase; //nr. elementelor extrase din coada
public:
Coada();
~Coada(){ . . .};
void Adauga(Element elem);
Element Extrage();
protected:
MultimeDeAcceptare Gol();
MultimeDeAcceptare Partial();
MultimeDeAcceptare Plin();
}
Coada::Coada(){
//initializari
. . .
become Gol();
}
void Coada::Adauga(Element elem){
. . .
if(elemIntroduse - elemExtrase == maxElem)
become Plin();
else
become Partial();
}
Element Coada::Extrage(){
. . .
if(elemIntroduse - elemExtrase == 0)
become Gol();
else
become Partial();
. . .
}
MultimeDeAcceptare Coada::Gol(){
return MultimeDeAcceptare(Adauga);
}
MultimeDeAcceptare Coada::Partial(){
return MultimeDeAcceptare(Adauga, Extrage);
}
MultimeDeAcceptare Coada::Plin(){
return MultimeDeAcceptare(Extrage);
}
Operatiile Plin(), Gol() si Partial(), numite operatii de determinare a starii,
returneaza obiecte de tip MultimeDeAcceptare. Analiza privind operatiile care vor fi
acceptate în interfata dinamica a obiectelor este stabila în cadrul acestor operatii.
Apelul acestor operatii se realizeaza în cadrul instructiunilor become pentru
determinarea starii urmatoare.
Multimile de acceptare pot fi considerate ca si perfectionari ale mecanismelor
de abstractizare a comportamentului. Ele respecta aceleasi principii (cod de
interactiune orientat pe obiectul apelat si modelarea de interactiuni concurente
dependente de stare si de istoric). În plus multimile de acceptare respecta si principiul
separarii codului de interactiune si, într-o anumita masura, principiul izolarii acestui
cod (codul nu este complet izolat deoarece operatiile de determinare a starii folosesc
proprietati care pot fi modificate în oricare alta operatie).
47

La fel ca abstractizarea comportamentala, multimile de acceptare nu pot
exprima concurenta intra-obiect din aceleasi motive care au fost amintite si la alte
mecanisme (cozi de asteptare, includere/excludere de operatii).
Un caz particular al multimilor de acceptare este obtinut prin eliminarea din
cod a instructiunilor become. Astfel, în momentul terminarii executiei unei operatii a
unui obiect este apelata automat o operatie speciala care determina urmatoarea
multime de operatii care fac parte din interfata obiectului. Aceasta extensie are rolul
de a micsora, în anumite situatii, codul care trebuie rescris în cazul specializarii unei
clase.
Expresii de cale. Mecanismul expresiilor de cale permite specificarea grupata
a tuturor dependentelor între operatiile potential concurente. Printr-o constructie de
forma:
path {lista_de_cale}
programatorul poate specifica operatiile care pot fi executate concurent si ordinea în
care acestea pot fi executate. Lista unei expresii de cale este formata dintr-o expresie
regulara ce contine mai multe nume de operatii alaturi de simboluri speciale care
exprima alegerea (|), repetitia ({}), concurenta (; si *) etc. Nu este necesara
introducerea de cod explicit pentru coordonarea interactiunilor între activitati
concurente în implementarea clasei.
Desi expresiile de cale reprezinta o metoda eleganta de coordonare a
constrângerilor de concurenta în interiorul unei clase, ele nu pot specifica sincronizari
conditionale. De asemenea, nu se specifica carei invocare de operatie i se va da curs
în cazul în care asteapta în coada mai multe apeluri ale aceleasi operatii.
Implementarea unei cozi marginite cu expresii de cale este triviala si
ineficienta. Pentru acest exemplu este necesar un mecanism suplimentar de
specificare a sincronizarii conditionale, fapt care ar determina o micsorare a
numarului de avantaje (printre care si eleganta) ce caracterizeaza expresiile de cale.
Sunt evident respectate principiile orientarii pe obiectul apelat si al izolarii
codului de interactiune concurenta. Din punct de vedere al expresibilitatii, expresiile
de cale pot specifica concurenta intra-obiect (prin intermediul operatorilor ; si *), dar
nu permit coordonarea interactiunilor concurente dependente de stare si de istoric. Cu
toate acestea exista limbaje de programare care suporta expresii de cale dar care
48

estrâng numarul de activitatii executate la un moment dat într-un obiect la una
singura.
Spre deosebire de majoritatea mecanismelor de specificare a interactiunilor
concurente care respecta principiul izolarii, expresiile de cale nu asigura
separareacodului de interactiune. Astfel, o expresie de cale implementata într-o clasa
parinte va fi sau mostenita sau rescrisa complet în clasele fiu, fapt ce conduce
bineînteles la distrugerea modularitatii ierarhiilor de clase.
Rutina de vitalizare (mecanisme cu control centralizat al interfetei).
Limbajele de programare care implementeaza rutinele de vitalizare ca si mecanisme
de specificare a concurentei furnizeaza anumite constructii specifice de coordonare a
concurentei ([CAR90], [AME87]). În aceste constructii un mesaj receptionat de catre
un obiect nu este interpretat automat de catre sistem ca si un apel de operatie. Acest
mesaj este analizat în cadrul rutinei de vitalizare urmând ca, în functie de starea
obiectului, sa fie apelate operatiile corespunzatoare. Declararea claselor va contine o
sectiune speciala, numita interface, unde sunt descrise toate mesajele care pot fi
receptionate de catre obiectele acestora.
În general rutinele de vitalizare proceseaza un singur mesaj la un moment dat,
fapt care determina serializarea stricta a comportamentului obiectelor. Asa cum s-a
aratat si în sectiunea precedenta, pentru a se putea executa mai multe activitati
concurente prin intermediul rutinelor de vitalizare este necesara prezenta unui
mecanism suplimentar de initiere a concurentei. În cazul în care acest mecanism
suplimentar este unul de tip fork-join atunci rutina de vitalizare poate utiliza comanda
fork pentru a lansa concurent mai multe apeluri de operatii. De asemenea, rutina de
vitalizare poate determina daca este executata la un moment dat o operatie
incompatibila cu mesajul curent receptionat.
În limbajele de programare orientate-obiect concurente care suporta rutine de
vitalizare sunt implementate instructiuni speciale pentru receptionarea si întârzierea
tratarii mesajelor. O astfel de instructiune este de forma:
receive {when },
în care mesajul va fi tratat doar în momentul în care expresia
este adevarata. În implementarea unei cozi limitate folosind rutine de vitalizare am
introdus o operatie noua, numita NrMaxElemente() care va returna numarul maxim de
49

elemente care pot exista în coada la un moment dat. Datorita faptului ca aceasta
operatie nu modifica nici una din proprietatile clasei ea poate fi executata în paralel cu
orice alta operatie din clasa (astfel de operatii poarta numele de observatori, ele
nemodificând starea obiectului în timpul executiei). Pentru lansarea unei activitati
concurente am utilizat un mecanism de tip fork-join.
class Coada{
interface:
//sabloanele mesajelor
//ce pot fi receptionate
void Adauga(Element elem);
Element Extrage();
int NrMaxElemente();
protected:
Element listaElemente[]; //tablou cu elementele cozii
int maxElem; //nr. maxim de elemente din coada
int elemIntroduse; //nr. elementelor introduse în coada
int elemExtrase; //nr. elementelor extrase din coada
Coada();
~Coada();
//operatiile ce urmeaza corespund 1:1 sabloanelor de
//mesaje din interfata (acest lucru nu este necesar)
//ele nu pot fi apelate direct din exterior
void rAdauga(Element elem){. . .};
Element rExtrage(){ . . .};
int rNrMaxElemente(){ return maxElem;};
//LifeBody() reprezinta o operatie (metoda) speciala care are rolul de a
//receptiona mesajele transmise unui obiect
void LifeBody();
};
void Coada::LifeBody(){
loop{
receive Adauga(e) when elemIntroduse-elemExtrase0;
rExtrage();
receive NrMaxElemente();
fork rNrMaxElemente(); //lansare concurenta
}
}
Rutinele de vitalizare respecta principiul privind implementarea codului de
interactiune concurenta în cadrul clasei server. De asemenea, cu ajutorul rutinelor de
vitalizare poate fi modelata concurenta intra-obiect (bineînteles cu ajutorul unui
mecanism suplimentar de specificare a concurentei) si poate fi exprimata coordonarea
dependenta de stare a activitatilor concurente. Exprimarea interactiunilor concurente
în functie de istoricul apelurilor de operatii nu este însa realizabila.
Rutinele de vitalizare respecta principiul izolarii codului de interactiune
concurenta. doar în cazul respectarii unei constrângeri de programare, si anume aceea
de a nu introduce în rutina de vitalizare cod pentru descrierea functionalitatii. Prin
50

urmare rutina de vitalizare trebuie folosita strict pentru conditionarea tratarii unor
mesaje si pentru lansarea în executie paralela a operatiilor corespunzatoare mesajelor.
În plus, la fel ca si în cazul expresiilor de cale, rutina de vitalizare nu poate fi
refolosita în clasele fiu: ea este sau mostenita integral sau rescrisa integral. Prin
urmare nu este respectat nici principiul separariu codului de interactiune. Exista
limbaje de programare (de exemplu Eiffel// [CAR90], [CAR93]) în care au fost
implementate asa-numitele rutine de vitalizare generalizate unde este necesare
initializarea unei tabele cu doua câmpuri: un câmp ce reprezinta o operatie a clasei iar
cel de-al doilea o conditie de apelare a acesteia. Prin urmare programatorul nu va
introduce cod efectiv în interiorul rutinei de vitalizare ci va initializa o astfel de
tabela. O astfel de abordare rezolva problema mostenirii rutinei de vitalizare si, în
plus, asigura si izolarea codului de interactiune nemaifiind necesara respectarea unei
discipline particulare de programare. Conditia necesara si suficienta pentru
suportarea unei rutine generalizate de vitalizare de catre un limbaj de programare este
aceea ca operatiile sa fie entitati de prima clasa ale limbajului.
Operatii (ne)serializate. Anumite limbaje de programare orientate-obiect
concurente (cum ar fi Java, Acore, ASK, etc. [PHI95]) folosesc un mod de etichetare
a operatiilor unei clase ca neserializate. Aceste operatii pot fi executate în paralel cu
oricare alta operatie a clasei. Practic operatiile neserializate sunt observatori (nu
afecteaza starea obiectului pe parcursul executiei lor).
Etichetarea operatiilor în maniera descrisa poate stabili operatiile care pot fi
executate în paralel. Modelarea excluderilor mutuale între astfel de operatii poate fi
realizata doar prin intermediul unui mecanism suplimentar de coordonare a
concurentei.
Din punct de vedere al respectarii principiilor enuntate la începutul acestei
sectiuni mecanismul operatiilor (ne)serializate se comporta foarte bine. Principala
problema consta în capacitatea redusa de coordonare a interactiunilor concurente.
Un mecanism particular bazat pe operatii (ne)serializate este mecanismul
cititor/scriitor. Acest mecanism permite etichetarea operatiilor ca "cititori" (numite,
asa cum am vazut, si observatori) si "scriitori" (cunoscute si sub denumirea de
modificatori). Operatiile cititor au rolul de a inspecta valorile proprietatilor obiectelor
si de a returna o valoare corespunzatoare, iar operatiile scriitor modifica valorile
51

acestor proprietati. Prin urmare executia operatiilor scriitor se va realiza într-o
maniera exclusiva.
c) Mecanisme de interactiune concurenta cu control reflectiv
Mecanismele de interactiune cu control reflectiv se caracterizeaza prin
desprinderea totala a codului de interactiune de implementarea clasei. Spre deosebire
de mecanismele cu control extern unde codul de interactiune nu era definit explicit, în
acest caz se pot formula constrângeri de interactiune explicit, iar acest lucru poate fi
realizat în cadrul unor asa-numite meta-clase.
Pentru a implementa o coada finita folosind acest mecanism de interactiune va
trebui definita clasa Coada asa cum este a fost ea definita pentru cazul secvential,
împreuna cu o noua clasa (MetaCoada) a carei interfata va contine doua operatii
numite Entry, respectiv Exit:
class Coada{
protected:
Element listaElemente[]; //tablou cu elementele cozii
int maxElem; //nr. maxim de elemente din coada
int elemIntroduse; //nr. elementelor introduse în coada
int elemExtrase; //nr. elementelor extrase din coada
public:
Coada(){...};
~Coada(){...};
void Adauga(Element elem) {...};
Element Extrage(){...};
}
class MetaCoada{
public:
Entry(){...};
Exit(){...};
}
...
Coada::attach(coada, meta_coada, Entry, Exit);
Ultima linie de cod realizeaza practic legatura dinamica dintre obiectul coada
de tip Coada si obiectul meta_coada de tip MetaCoada. În urma acestei legaturi
realizate dinamic orice apel de operatie a obiectului coada va avea ca efect executarea
operatiei Entry() din obiectul atasat dinamic meta_coada urmata de executia operatiei
apelate si, în final, lansarea în executie a operatiei Exit() apartinând tot obiectului
meta_coada.
Este evident faptul ca mecanismele din aceasta subcategorie respecta
principiile codului de interactiune orientat pe obiectul apelat si principiul izolarii
codului de interactiune. De asemenea, aceste mecanisme pot exprima concurenta
52

intra-obiect si executia concurenta dependenta de stare, neavând însa instrumente
specifice exprimarii executiilor concurente dependente de istoric.
În ceea ce priveste respectarea principiului separarii codului de interactiune,
aceasta depinde de implementarea mecanismelor în limbajul de programare. În cazul
în care meta-clasa poate fi utilizata ca si o rutina de vitalizare generalizata,
neimplementându-se în cadrul ei cod care sa afecteze functionalitatea clasei de care
este legata dinamic atunci codul de interactiune respecta principiul amintit. În caz
contrar este evident ca, codul de interactiune nu este separabil, si deci pentru a
modifica constrângerile de interactiune este necesara reprogramarea completa a meta-
clasei.
2.5. Concluzii
Eforturile din ultimele doua decenii de unificare a conceptelor orientate-obiect
cu mecanismele de initiere si coordonare a concurentei s-au concretizet într-un numar
mare de limbaje de programare si modele de concurenta. Cu toate acestea nu s-a
ajuns deocamdata la dezvoltarea unui model ideal, care sa îmbine în mod armonios
aceste doua directii diferite ale dezvoltarii aplicatiilor. Principiile enuntate în cadrul
sectiunii 2.2 descriu un astfel de model ideal, ele fiind determinate pe baza
rezultatelor teoretice si a experientei practice în fiecare dintre cele doua ramuri ale
programarii.
Nici unul dintre limbajele dezvoltate pâna în prezent nu respecta în totalitate
aceste principii, asa cum s-a aratat în sectiunea 2.4. În tabelul 2.1. sunt prezentate
toate mecanismele de interactiune concurenta luate în considerare în aceasta sectiune,
pentru fiecare precizându-se principiile care sunt sau nu respectate.
Pe parcursul analizei mecanismelor de limbaj au fost semnalate în dese rânduri
conflicte care apar între mecanismele de coordonare a concurentei si mecanismul de
mostenire. Aceste tipuri de conflicte, denumite în literatura anomalii de mostenire, au
fost intens studiate în ultimii ani. În capitolul 3 se va realiza o analiza formala a
acestor anomalii si se va demonstra faptul ca respectarea celor patru principii
contribuie la ameliorarea lor.
53

În multe cazuri respectarea principiilor este realizata doar în cazul în care se
impune o anumita disciplina de programare, constructiile de limbaj neputând garanta
acest lucru.
Mecanism de interactiune Principiul
Principiul Principiul Principiul
concurenta
expresibilitatii orientarii pe apelat izolarii separarii
sincronizare prin terminare concurenta intra-obiect
executie dep. de stare
nu nu nu
semafoare, mutex si lock concurenta intra-obiect nu (câteodata da) nu nu
regiuni critice conditionale executie dep. de stare nu (câteodata da) nu nu
sincronizare piggy-backed executie dep. de stare nu nu nu
monitor nu da da da
variabile de conditie executie dep. de stare da nu nu
asteptare conditionala executie dep. de stare da nu nu
coada de asteptare executie dep. de stare da nu nu
includere/excludere op. executie dep. de stare da nu nu
abstrac. comportamentului executie dep. de stare
executie dep. de istoric
concurenta intra-obiect
da nu nu
modelul Actor
executie dep. de stare
executie dep. de istoric
conc intra-obiect (uneori)
da
nu
nu
metode cu garzi
executie dep. de stare
da
da (nu e
da
executie dep. de istoric
complet izolat)
multimi de acceptare executie dep. de stare
da da (nu e
da
executie dep. de istoric
complet izolat)
expresii de cale concurenta intra-obiect
executie dep. de istoric
da da nu
rutina de vitalizare pos. conc. intra-obiect
da da (nu e
nu
executie dep. de stare
complet izolat)
rutina generalizata concurenta intra-obiect
executie dep. de stare
da da da
operatii neserializate conc. intra-ob. restrictiva da da da
protocol cititor/scriitor conc. intra-ob. restrictiva da da da
control reflectiv concurenta intra-obiect
executie dep. de stare
da da nu (posibil da)
Tabel 2.1.
În alta ordine de idei, alaturi de nerespectarea principiilor de proiectare ale
limbajelor, care sunt direct legate de conceptele de baza ale programarii orientate-
obiect si programarii concurente, multe dintre limbajele de programare studiate au
dezavantaje majore concretizate prin dificultatea testarii si depanarii aplicatiilor si
slaba lizibilitate a codului sursa.
Aceste dezavantaje pot fi minimizate prin utilizarea de instrumente care sa
automatizeze procesul de implementarea a aplicatiilor pe baza unor modele ale
structurii si comportamentului claselor de obiecte concurente. Aceasta idee va fi
dezvoltata pe larg în capitolele 4 si 5.
54

3. Anomalii de mostenire
3.1. Introducere
Analiza limbajelor de programare orientate-obiect concurente realizata în
capitolul precedent releva faptul ca mecanismele de initiere a concurentei, precum si
mecanismele de comunicare si sincronizare între activitati concurente interfereaza cu
conceptele programarii orientate-obiect determinând anumite conflicte.
Problema integrarii concurentei trebuie studiata cu multa atentie. O abordare
gresita a mecanismelor de concurenta poate conduce la proiectarea de clase care sa
satisfaca doar necesitatile unei aplicatii particulare. Prin urmare, reutilizarea claselor
respective pentru dezvoltarea altor aplicatii va fi dificila, daca nu chiar imposibila.
În acest sens, procesul de integrare a mecanismelor de initiere si coordonare a
concurentei cu mecanismul de mostenire s-a bucurat de un interes constant din partea
cercetatorilor în ultimul deceniu. Mostenirea este unul dintre mecanismele cheie, ea
reprezentând o metodologie larg folosita la reutilizarea codului în programarea
orienta-obiect secventiala. În literatura s-a acordat o atentie deosebita capacitatii de
reutilizare a obiectelor active, conflictele dintre concurenta si mostenire beneficiind
de un interes aparte. Aceste conflicte sunt numite anomalii de mostenire, denumire
întâlnita pentru prima data în [MAT93].
Anomaliile de mostenire au loc atunci când adaugarea unor operatii (metode)
într-o subclasa determina redefinirea unor operatii (metode) din superclasa, redefiniri
care nu sunt necesare in programarea orientata-obiect secventiala. Nebeneficiind de
avantajul adaugarii incrementale de cod într-o subclasa, programatorii se confrunta cu
55

problema redefinirii, uneori integrale, a codului mostenit, calitatile mostenirii si
încapsularii fiind astfel anulate.
Desi anomaliile de mostenire au beneficiat de o atentie deosebita în ultimii ani,
ele sunt înca vag definite si deseori interpretate gresit. Dintre cele mai importante
lucrari în care au fost propuse solutii de evitare si ameliorare ale anomaliilor de
mostenire amintim: [QUI97], [PAP96], [LEC96], [FER95], [AKS94], [MIT94],
[THO94], [MES93]. Rezultatele obtinute în aceste lucrari sunt contradictorii si
incomplete, deoarece ele se limiteaza la o abordare informala a anomaliilor, fiind în
principal analizate pe baza exemplelor particulare introduse în [MAT93]. Prin urmare
nu exista o metoda satisfacatoare de evaluare a diverselor propuneri (de limbaje,
mecanisme sau modele obiect) existente.
În cadrul urmatoarei sectiuni sunt prezentate doua dintre cele mai importante
clasificari ale anomaliilor de mostenire, realizate în [MAT93] si [ZEN97b], care au la
baza o analiza informala. Vom demonstra în finalul acestei sectiuni ca aceste
clasificari sunt incomplete, si vom propune o alta abordare care nu va lua în
considerare numai conflictele dintre concurenta si mostenire, ci si conflinctele dintre
concurenta si alte trei relatii importante între clase, cum sunt relatiile de asociere,
agregare si delegare. Aceste tipuri de conflicte au o legatura strânsa cu anomaliile de
mostenire, si de aceea am propus abordarea lor unitara. O astfel de abordare poate
determina o reconsiderare a conflictelor de acest tip dintr-o cu totul alta perspectiva, si
ar putea conduce la solutii de ameliorare a efectelor acestora. De asemenea, vom
propune o noua denumire pe care o consideram mult mai potrivita pentru a descrie
aceste tipuri de conflicte, si anume aceea de anomalie de reutilizare.
În cadrul sectiunii a treia am realizat o extensie a sistemului formal utilizat în
[CRN98] pentru clasificarea mecanismelor de mostenire în programarea orientata
obiect concurenta. Extensia se refera la descrierea anomaliilor de mostenire pentru
modelele obiect cu concurenta interna (ca urmare a respectarii principiului
expresibilitatii concurentei). De asemenea, sistemul formal introdus în [CRN98] a
permis modelarea mecanismului de mostenire pentru limbajele de programare
orientate-obiect concurente care respecta principiile izolarii si separarii codului de
interactiune între activitati concurente. Pe baza acestui model am demonstrat una
dintre concluziile desprinse în cadrul analizei mecanismelor de interactiune între
activitati concurente în cadrul capitolului doi, si anume ca respectarea celor doua
56

principii conduce la ameliorarea efectelor induse de anomaliile de mostenire. Vom
arata de asemenea ca acest lucru nu garanteaza si eliminarea anomaliilor.
Rezultatele formalizarii valideaza conceptul de anomalie de reutilizare propus
în [SUC97a] pe baza unei analize informale. Astfel, se demonstreaza ca mostenirea
nu reprezinta cauza reala a anomaliilor de mostenire, si ca probleme asemanatoare
anomaliilor de mostenire apar si în alte paradigme. De asemenea, se arata ca nu
exista o solutie ideala de rezolvare a acestor tipuri de anomalii.
Maniera de abordare a formalizarii anomaliilor de mostenire demonstreaza si
caracterul reactiv al obiectelor active (modificarea comportamentului extern-
observabil al obiectelor active în functie de mesajele receptionate). Rezultatele
obtinute în urma formalizarii vor sta la baza modificarilor semantice ale hartilor de
stari pentru modelarea comportamentului obiectelor active care vor fi descrise în
capitolul patru.
3.2. Clasificari ale anomaliilor de mostenire
Una dintre cele mai importante probleme ridicate de programarea orientata-
obiect concurenta, subliniata si la începutul capitolului precedent, este aceea a
sincronizarii obiectelor concurente: atunci când un obiect concurent se afla într-o
anumita stare, el poate accepta doar un subset din întregul sau set de mesaje pentru a-
si mentine integritatea interna. Aceasta restrictie impusa asupra interfetei obiectelor
concurente poarta în literatura de specialitate numele de constrângere de sincronizare.
În majoritatea limbajelor orientate-obiect concurente responsabilitatea
implementarii explicite de cod în cadrul operatiilor în scopul satisfacerii
constrângerilor de sincronizare cade în sarcina programatorului. Pentru a putea
realiza acest lucru este necesara existenta unor mecanisme sau primitive de limbaj
pentru implementarea sincronizarii si a comunicarii între operatiile obiectelor. Toate
tipurile de primitive care au fost implementate în cele peste o suta de limbaje
orientate-obiect concurente imperative existente au fost prezentate în capitolul
precedent. Tot în capitolul precedent am aratat faptul ca, în anumite cazuri, codul de
coordonare a interactiunilor concurente nu poate fi mostenit efectiv fara a genera
redefiniri netriviale de operatii. Acest conflict a fost identificat si studiat în mai multe
57

lucrari de specialitate, începând cu [MAT93], în care a fost numit anomalie de
mostenire.
S-au identificat, de asemenea, trei cazuri distincte în care utilitatea conceptului
de mostenire este mult diminuata (în unele cazuri particulare chiar anulata):
?? definirea unei noi subclase K' a clasei K necesita redefinirea operatiilor
acesteia (acelasi lucru este valabil si pentru descendentii clasei K');
?? modificarea unei operatii m a clasei K în cadrul ierarhiei de mostenire
implica modificarea, fara o motivatie functionala, a anumitor operatii atât
în clasa K cât si în descendentii sai;
?? definirea unei operatii noi poate forta alte operatii (inclusiv cele ce vor fi
definite în viitor în subclase) sa urmeze un protocol specific care nu era
necesar în cazul în care respectiva operatie nu ar fi existat. Pastrarearea
încapsularii claselor va fi, în consecinta, foarte dificila.
Principalele dezavantaje induse de anomaliile de mostenire sunt violarea
încapsularii si anularea într-o proportie ridicata a capacitatii mecanismului de
mostenire. În consecinta cantitatea de cod necesara pentru implementarea unei
subclase este mult mai mare decât în cazul secvential, iar modificarea operatiilor în
clasele parinte, în scopul maririi eficientei, nu are afect si asupra decendentilor
acestora, deoarece aceste operatii au fost rescrise. De asemenea, nu se pot realiza
modificari locale, acestea trebuind sa fie realizate la nivelul întregii ierarhii.
O observatie importanta este aceea ca aparitia anomaliilor de mostenire
depinde de primitivele de comunicare si sincronizare specifice limbajului. Rezulta de
aici ca problema anomaliilor de mostenire este generata de conflictele semantice
dintre descrierile sincronizarii si ale mostenirii specifice unui limbaj, si nu de modul
în care sunt implementate trasaturile limbajului.
3.2.1. Clasificarea Matsuoka-Yonezawa
Aceasta clasificare a fost realizata si prezentata în [MAT93] si ea a stat la baza
demonstrarii corectitudinii multor limbaje de programare orientate obiect concurente
(corectitudine privita prin prisma implementarii de mecanisme de initiere si
interactiune concurenta care sa împiedice aparitia anomaliilor de mostenire). Din
pacate, desi clasificarea Matsuoka-Yonezawa are meritul de a fi rodul unei analize
laborioase a conflictelor dintre mostenire si concurenta, ea are anumite neajunsuri
58

generate de modalitatea în care a fost abordata aceasta analiza. Studiile efectuate de
cei doi autori si prezentate în [MAT93] au identificat trei tipuri de anomalii de
mostenire: de partitionare a starilor abstracte, determinate de istoric si de modificare
a starilor abstracte.
Aparitia celor trei tipuri de anomalii în diverse situatii a fost demonstrata
utilizând exemple; dar exemplele nu reprezinta o baza adecvata pentru clasificare.
Prin urmare, nu exista nici o garantie ca aceasta clasificare este corecta sau completa.
În particular, o astfel de clasificare nu poate fi folosita pentru a demonstra absenta
anomaliilor de mostenire în cadrul unui limbaj de programare.
Pe de alta parte, exemplele studiate nu au fost prezentate într-un context
general, ci folosind mecanisme particulare de specificare a interactiunilor concurente.
Astfel, mecanismele utilizate au fost: receptionarea explicita de mesaje, expresiile de
cale, functii de vitalizare, abstractizari de comportament, multimi de acceptare si
metode cu garzi. Însa, asa cum am aratat în capitolul precedent, multimea
mecanismelor dezvoltate pâna în prezent este mult mai voluminoasa.
Exemplul utilizat pentru caracterizarea celor trei categorii de anomalii de
mostenire a fost cel folosit si în cadrul sectiunii 2.2, si anume implementarea unei cozi
cu numar finit de elemente (figura 2.1). Matsuoka si Yonezawa au folosit, de
asemenea, conceptul de stare abstracta a unui obiect. Pentru a realiza o prezentare
succinta si sugestiva a clasificarii celor doi vom apela din nou la modelarea
comportamentului obiectelor folosind harti de stari, descrise de Harel [HAR87].
Pentru o mai buna întelegere a celor trei tipuri de anomalii am recurs la o varianta
simplificata a acestor harti de stari, renuntând la specificarea de expresii conditionale
în etichetarea tranzitiilor si de invarianti la nivelul starilor, urmând ca acestea sa fie
tratate în detaliu în cadrul capitolului urmator. Cele trei clase care specializeaza clasa
Coada si care au fost utilizate pentru descrierea celor trei categorii de anomalii de
mostenire sunt prezentate în figura 3.1. utilizând notatia UML de modelare statica a
aplicatiilor orientate-obiect (Anexa B contone o descriere succinta a acestei notatii).
O prima categorie de anomalii de mostenire sunt cele determinate de
partitionarea starilor abstracte. Astfel, sa presupunem ca se doreste specializarea
clasei Coada prin adaugarea unei noi operatii, Extrage2(), care sa permita extragerea
din coada a doua elemente (primele) simultan.
59

Figura 3.1. Ierarhia de clase folosita de Matsuoka-Yonezawa
pentru clasificarea anomaliilor de mostenire
Modelarea comportamentului unei astfel de clase, pe care am numit-o Coada2,
este prezentata în figura 3.2, unde se poate observa ca starea abstracta Partial,
caracteristica clasei Coada, are în acest caz doua substari, Partial2 si Unu (practic
starea Partial este înlocuita în modelul comportamental de celelalte doua stari).
În exemplele din [MAT93] se arata ca adaugarea operatiei Extrage2() în clasa
Coada2 folosind, spre exemplu, mecanismul cu multimi de acceptare implica automat
redefinirea operatiilor clasei Coada, deoarece partajarea starii Partial trebuie tratata
de catre toate aceste operatii. Pe de alta parte, s-a aratat ca mecanismul cu metode cu
garzi nu conduce la aparitia acestui tip de anomalie de mostenire.
Figura 3.2. Descrierea comportamentului obiectelor clasei Coada2
60

Figura 3.3. Descrierea comportamentului obiectelor clasei HCoada
O a doua categorie semnalata în [MAT93] este aceea a anomaliilor de
mostenire determinate de istoric. Exemplul studiat de autorii lucrarii este acela al
unei subclase, HCoada, care contine o operatie ExtrageImediat() care poate fi
executata numai daca operatia precedent acceptata a fost Adauga() (deci operatia
ExtrageImediat() nu va putea fi lansata în executie imediat dupa acceptarea unei
operatii Extrage()sau ExtrageImediat()). Aceasta situatie necesita adaugarea unei noi
proprietati (în cazul utilizarii metodelor cu garzi) sau a unei noi stari (în cazul
mecanismului de abstractizare a comportamentului sau a multimilor de acceptare).
Modelul comportamentului prezentat în figura 3.3 este valabil pentru ambele cazuri.
Pentru multimile de acceptare redefinirile sunt necesare deoarece noua stare
trebuie sa fie luata în considerare de catre toate operatiile. În cazul metodelor cu garzi
sunt necesare redefiniri considerabile deoarece setarea corespunzatoare a valorii noii
proprietati trebuie realizata în toate operatiile. Totusi, în acest ultim caz, nu este
necesara cunoasterea implementarii operatiilor redefinite, deci nu are loc o violare a
modularizarii.
Ultima categorie de anomalii de mostenire este cea determinata de modificarea
starilor abstracte. Exemplul dat pentru definirea acestui tip de anomalii consta în
posibilitatea blocarii extragerii si adaugarii de elemente în coada. Astfel starea unei
obiect nu va depinde doar de numarul elementelor din coada ci si de valoarea
proprietatii blocat (figurile 3.1 si 3.4).
61

Figura 3.4. Descrierea comportamentului obiectelor clasei BCoada
Blocarea si deblocarea cozii se realizeaza prin intermediul operatiilor
Blocare(), respectiv Deblocare() ale clasei nou create BCoada. Si acest caz a fost
implementat folosind mecanismele de sincronizare amintite. Astfel, pentru multimile
de acceptare este necesara adaugarea unei noi stari, ceea ce implica aparitia
anomaliilor de mostenire, dupa cum s-a vazut si la exemplul anterior. În cazul
metodelor cu garzi este necesara modificarea conditiilor din garzi pentru a fi luata în
considerare noua proprietate blocat, si deci este necesara redefinirea operatiilor
Adauga() si Extrage() fara a modifica deloc functionalitatea acestora.
Clasificarea realizata de Matsuoka si Yonezawa reprezinta o prima încercare
de determinare sistematica a cauzelor care conduc la aparitia anomaliilor de
mostenire. Din pacate aceasta clasificare nu are un fundament teoretic, ea bazându-se
strict pe testarea cazurilor în care multimea de stari abstracte a unei clase este
modificata în descendentii sai. Prin urmare, nu exista nici o garantie ca respectiva
clasificare sa fie completa si corecta, realizarea ei depinzând strict de "bunul-simt" si
experienta autorilor.
Mai mult, nu este surprins cazul în care se ajunge la o anomalie de mosternire
fara ca multimea starilor abstracte sa fie modificata în clasa fiu. Astfel, pentru
exemplul de mai sus si folosind anumite mecanisme de coordonare a interactiunilor
concurente particulare, construirea unei subclase a clasei Coada care sa contina o
operatie ce extrage ultimul element al cozii conduce la redefinirea nejustificata din
puct de vedere functional a tuturor operatiilor din superclasa (acest lucru poate fi
62

demonstrat cu usurinta folosind, de exemplu, oricare dintre primitivele de interactiune
concurenta orientate pe operatii).
3.2.2. Clasificarea Zeng-Schach
Clasificarea propusa de Zeng si Schach a fost realizata relativ recent, în
lucrarea [Zen97b]. Autorii propun aici o analiza a modului în care functioneaza
mostenirea, mai precis a modului în care o subclasa poate specializa superclasa sa fara
a lua în considerare nici un mecanism de interactiune concurenta particular.
Sintactic, o subclasa poate specializa clasele parinte în trei moduri distincte:
prin definirea de noi proprietati, prin definirea de noi operatii sau prin rescrierea
operatiilor mostenite.
Desi cele trei modalitati de specializare sunt ortogonale, adaugarea unei noi
proprietati implica, în mod logic, definirea sau redefinirea a cel putin unei operatii
care sa actioneze asupra sa. De aceea Zeng si Schach considera ca aparitia
anomaliilor de mostenire este strâns legata de ultimele doua modalitati de extindere a
unei superclase. Aceasta abordare este total diferita de cea din [MAT93], deoarece
anomaliile de mostenire nu sunt privite în raport cu multimea starilor abstracte ale
unui obiect ci cu operatiile nou definite ale acestuia.
Mai mult, sunt luate în considerare situatiile în care sunt referite alte operatii
ale unui obiect din cadrul unei operatii nou definite. În tabelul 3.1. sunt prezentate
cazurile analizate în [ZEN97b] si care au fost considerate ca potentiale situatii de
generare de redefiniri netriviale de operatii.
Extensii operatie rescriere referinte la oper.
noua operatie super-clasei
E1 nu da nu
E2 nu da da
E3 da nu nu
E4 da nu da
E5 da da nu
E6 da da da
Tabel 3.1. Posibilitati de specializare a unei clase
Acest fapt reprezinta unul dintre neajunsurile abordarii, deoarece s-a avut în
vedere doar problema redefinirilor netriviale de operatii, ignorându-se un alt aspect
caracteristic anomaliilor de mostenire, si anume acela al violarii încapsularii.
63

Un alt neajuns este acela ca analiza celor sase cazuri prezentate în tabelul 3.1.
ia în considerare doar concurenta inter-obiect, considerându-se ca avem de-a face cu
obiecte care detin doar un singur fir de executie activ la un moment dat. Deci nu se
poate afirma ca rezultatele analizei conduc la o clasificare completa nici în acest caz.
Rezultatul final al analizei nu este unul surprinzator, el afirmând existenta a
doua categorii de anomalii. O prima categorie, numita categoria anomaliilor de
rescriere fortata, este determinata de necesitatea redefinirii uneia sau mai multor
operatii într-o subclasa în urma definirii unei operatii în cadrul acesteia. A doua
categorie determinata este aceea a anomaliilor de sincronizare care se refera la
imposibilitatea apelarii unei operatii (din cadrul superclasei sau nu) din cauza
constrângerilor de sincronizare impuse asupra acesteia.
Anomaliile din prima categorie corespund anomaliilor de mostenire din
clasificarea Matsuoka-Yonezawa. Analiza realizata aici însa nu permite determinarea
celor trei subcategorii pe care le-am mentionat în sectiunea precedenta.
Pe de alta parte, anomaliile de sincronizare nu sunt caracteristice programarii
orientate-obiect concurente. Asa cum afirma chiar autorii, aceste anomalii sunt
prezente si în medii neorientate obiect, iar rezolvarea lor se reduce la rezolvarea
problemei apelurilor încastrate în monitoare.
Prin urmare clasificarea introdusa aici nu aduce nimic nou. În plus, motivele
aparitiei anomaliilor nu sunt foarte clar scoase în evidenta, acest lucru datorându-se în
primul rând abordarii problemei fara a lua în considerare implementari particulare de
mecanisme de interactiune concurenta.
3.2.3. Anomalii de reutilizare
Conceptul de anomalie de mostenire a fost introdus pentru a descrie conflictele
care apar între concurenta si mecanismul de mostenire al programarii orientate-obiect.
În timp însa, asa cum se poate observa în diverse articole aparute pe aceasta tema în
ultimii ani, anomaliile de mostenire au fost considerate ca reprezentând singurele
conflicte provenite în urma fuzionarii între conceptele de concurenta si cele orientate-
obiect. Acest lucru este total eronat, deoarece, asa cum vom arata în continuare,
anomalii cu un comportament asemanator au loc si în cazul altor mecanisme
caracteristice programarii orientate-obiect. [ZEN97b] reprezinta una dintre putinele
lucrari în care se încearca demonstrarea existentei altor anomalii înafara celor de
64

mostenire în cadrul programarii orientate-obiect concurente. Din pacate, asa cum am
vazut, studiul realizat în aceasta lucrare conduce la concluzii nesatisfacatoare. Totusi,
anomaliile de rescriere fortata care înlocuiesc conceptul de anomalii de mostenire si
care au fost introduse în [ZEN97b] are un caracter mult mai general, chiar daca acest
lucru s-a realizat doar la nivel de denumire (singurele tipuri de anomalii de rescriere
date ca exemplu au fost cele trei amintite în [MAT93]).
Între clasele care descriu la un moment dat o anumita problema pot exista
patru tipuri de relatii. Un prim tip de relatie este aceea de mostenire, care permite
reutilizarea structurii si functionalitatii unei clase în definirea altei clase.
Exista limbaje de programare (ca, de exemplu, SINA) care nu au implementat
un mecanism pentru descrierea unei astfel de relatii. În aceste limbaje generalizarea
sau specializarea unei clase se realizeaza prin intermediul mecanismului de delegare.
Relatia de delegare dintre doua clase este tot o relatie de reutilizare si ea presupune
redirectarea potentiala a mesajelor receptionate de catre un obiect spre un asa-numit
obiect delegat. Obiectul delegat trebuie sa faca parte efectiv din constructia primului
obiect. Relatia de delegare este o relatie mult mai puternica decât mostenirea,
deoarece ea poate simula aceasta relatie si, în plus, poate modela o evolutie dinamica
a sistemelor (lucru pe care mostenirea, ca relatie statica dintre clase, nu îl poate
realiza).
O a treia relatie posibila între clasele unui sistem este relatia de agregare. Ea
implica existenta unei relatii de tip parte-întreg între instantele claselor aflate în
aceasta relatie.
Relatia de asociere este cea de-a patra relatie posibila în care se pot afla doua
clase ale unui sistem. Aceasta relatie mai poarta numele si de relatie de utilizare
deoarece, la un moment dat, un obiect unei clase se foloseste de serviciile oferite de
catre un obiect al clasei asociate.
Cele patru relatii descrise mai sus reprezinta tot atâtea cai de reutilizare a
claselor definite într-o anumita biblioteca. În cele ce urmeaza vom arata ca, într-un
context concurent, existenta uneia dintre aceste relatii poate determina în anumite
conditii redefiniri netriviale de operatii precum si violari grave ale încapsularii. Prin
urmare, au loc efectele considerate în [MAT93] în descrierea anomaliilor de
mostenire.
65

Relatiile de delegare, agregare si asociere implica, în ultima instanta, existenta
unei comunicari între obiecte, comunicare ce se bazeaza pe accesarea sau apelarea
structurii si a operatiilor publice ale unui obiect. Accesul la structura publica a unui
obiect, si deci la proprietatile publice ale acestuia poate determina într-un context
concurent si în lipsa unui mecanism de sincronizare adecvat aducerea obiectului într-o
stare inconsistenta.
Prin urmare, la nivelul operatiilor sau obiectelor care acceseaza proprietatile
publice ale unui obiect aflat într-o relatie de agregare, asociere sau delegare vor trebui
folosite mecanisme de comunicare si sincronizare pentru protejarea consistentei
datelor. Pentru cele mai multe dintre aceste mecanisme (dupa cum s-a demonstrat si
în cazul anomaliilor de mostenire) acest lucru presupune cunoasterea implementarii
operatiilor (publice sau nu) din obiectul a carei structura se acceseaza. Prin urmare
încapsularea claselor poate fi distrusa, iar reutilizarea claselor apartinând unei
biblioteci de clase, este îngreunata înca odata. Mai mult, modificarea claselor din
cadrul unei biblioteci de clase (prin modificari sau adaugari de operati) implica
modificarea tuturor claselor aflate în relatie cu acestea.
Este evident faptul ca în cazul asocierilor si agregarilor anomaliile de acest gen
pot fi eliminate prin considerarea tuturor proprietatilor unei clase ca fiind private.
Totusi, majoritatea limbajelor de programare orientate-obiect existente permit
definirea mai multor moduri de vizibilitate pentru proprietati. Mai mult, în unele
limbaje (cum ar fi, de exemplu, C++) se pot defini operatii care sa returneze referinte
ale proprietatilor, ele putând fi modificate în aceeasi maniera ca si proprietatile
publice (si implicând aceleasi anomalii).
Datorita asemanarii evidente dintre aceste tipuri de anomalii si cel cunoscut în
literatura de specialitate ca anomalie de mostenire consideram ca este mult mai
naturala tratarea unitara a lor precum si gasirea unei denumiri generale ce sa le
defineasca. Denumirea propusa de noi este aceea de anomalie de reutilizare.
Vom demonstra în sectiunea urmatoare ca principiile enuntate în capitolul doi
reprezinta conditii necesare pentru evitarea aparitiei anomaliilor de reutilizare si
pastrarea intacta a calitatilor conceptelor introduse atât de mecanismele de concurenta
cât si de tehnica orientata-obiect.
66

3.3. Formalizarea anomaliilor de mostenire
În [CRN98] a fost propus un sistem formal de clasificare a mecanismelor de
mostenire în programarea orientata-obiect concurenta. Acest sistem formal reprezinta
o varianta a semanticilor denotationale pentru mostenire introduse de Cook si
Palsberg în [COO89] si porneste de la modelarea unei ierarhii de mostenire
incrementale. Modul în care este modelata mostenirea în acest sistem formal permite
tratarea oricarei abordari particulare de proiectare a unui limbaj de programare
orientat-obiect concurent.
În ierarhia de clase din figura 3.1. superclasa Coada este complet reutilizata de
subclasele sale Coada2, HCoada si BCoada, deoarece nici una dintre operatiile ei nu
este redefinita în aceste subclase. Prin urmare volumul de cod reutilizat este maxim.
O astfel de ierarhie de mostenire, în care nici o subclasa nu redefineste operatii ale
claselor parinte poarta numele de ierarhie de mostenire incrementala.
Mostenirea induce si alta relatie între clase: relatia de subtipizare. Am definit
tipul ca fiind o multime de instante care au aceeasi interfata (sau comportament extern
observabil). Vom spune ca o clasa implementeaza un tip daca fiecare instanta a clasei
apartine tipului respectiv.
O clasa B derivata dintr-o clasa A va avea în componenta sa cel putin
proprietatile si operatiile clasei A. Deci, o instanta a clasei B poate fi utilizata în orice
context în care poate fi utilizata o instanta a clasei A, adica interfata unei instante a
clasei B va include operatiile ce compun interfata oricarei instante a clasei A. Aceasta
relatie de incluziune între interfetele a doua obiecte poarta numele de relatie de
subtipizare (în particular, instantele clasei B reprezinta subtipuri ale instantelor clasei
A). Relatia de subtipizare este o relatie între comportamentele externe ale instantelor,
si ea nu depinde de structura interna a unei clase cum este cazul relatiei de mostenire.
Notând cu ? un tip implementat de clasa A si cu ? un tip implementat de clasa
B vom nota prin ? ? ? faptul ca tipul ? este subtip al lui ?. Prin urmare o instanta
care apartine unui tip ? apartine de asemenea tipului ?, iar o clasa care implementeaza
tipul ? implementeaza de asemenea si tipul ?.
Definitia urmatoare si cele doua afirmatii care o preced introduc o legatura
între relatia de subtipizare si ierarhia de mostenire incrementala.
Definitie 1. Un lant de tipuri reprezinta o secventa finita de tipuri ? 1 ? ... ? ? n.
67

Afirmatie 1. Orice drum dintr-o ierarhie de mostenire incrementala
implementeaza un lant de subtipuri.
Afirmatie 2. Fiecare lant de subtipuri poate fi implementat de o ierarhie de
mostenire incrementala.
Conform definitiei de tip data anterior, în care acesta este caracterizat de o
multime de operatii, afirmatiile 1 si 2 au loc pentru orice ierarhie de mostenire (nu
neaparat incrementala!), în care nu este permisa stergerea de operatii. În cazul
programarii orientate-obiect concurente însa, exista o multime consistenta de limbaje
sau modele obiect care fac ca o subclasa dintr-o ierarhie de mostenire incrementala sa
fie strâns legata de superclasa acesteia printr-o relatie mai puternica de subtipizare,
bazata pe acceptarea de secvente de mesaje, spre deosebire de relatia bazata pe
multimi de operatii. Aceste limbaje sau modele obiect utilizeaza mecanisme de
sincronizare orientate pe încapsulare. Problema anomaliilor de mostenire apare
frecvent în cazul acestor limbaje deoarece afirmatia 2 nu este îndeplinita pentru
aceasta notiune de tip.
Obiectele active au cel putin un fir de executie propriu. Concurenta inter-
obiect si intra-obiect implica necesitatea sincronizarii, fara de care starea unui obiect
activ poate deveni inconsistenta. De aceea programarea orientata-obiect concurenta
introduce notiunea de control de interfata. Majoritatea modelelor obiect realizeaza
controlul interfetei prin intermediul unei entitati speciale, pe care le vom numi în
continuare gestionare de mesaje, si care se concretizeaza printr-un fir de executie
distinct, un mecanism de blocare sau un obiect special. Aceste entitati decid care sunt
operatiile permise a fi lansate în executie si operatiile care trebuie sa fie suspendate
astfel încât obiectul sa se afle în orice moment într-o stare consistenta. Mesajele
receptionate de la alte obiecte din sistem vor fi retinute într-o coada de mesaje pâna
când entitatea care gestioneaza controlul interfetei le permite sa avanseze. Prin
urmare controlul interfetei impune constrângerile de sincronizare.
Vom utiliza notatia pentru reprezentarea unei secvente de
mesaje acceptate m1, ..., mn. Presupunând ca putem caracteriza un tip prin intermediul
unei multimi de secvente de mesaje {u1,...,uk}, fiecare instanta apartinând acestui tip
are proprietatea ca cel putin fiecare ui reprezinta o secventa valida a instantei. Daca ?
? ? atunci fiecare instanta a lui ? este de asemenea un element al lui ?, si de aceea
este capabil sa accepte multimea de secvente de mesaje proprie lui ?. Prin urmare,
68

orice instanta din ? poate fi folosita în locul unei instante din ?, fara nici o modificare
observabila din exterior a comportamentului rezultat.
Sistemele de metode ([COO89]) reprezinta formalizari simple ale programarii
orientate-obiect si includ descrieri de instante, clase si operatii (metode) (figura 3.5).
Functia class returneaza clasa unei anumite instante, iar instances returneaza
multimea tuturor instantelor posibile ale unei clase.
Pentru o anumita clasa, functia methods pune în corespondenta numele unui
mesaj cu corpul acestuia (codul operatiei asociate) sau cu elementul nedefinit ? (în
cazul în care nu exista nici o operatie definita la nivelul clasei asociata mesajului).
Functia M returneaza multimea tuturor operatiilor (metodelor) definite pentru o clasa
anume.
Multimi
Instante: p, q, r ? Instance
Clase: P, Q, R ? Class
Signaturi de mesaje: m ? Key
Expresii de operatii: e, f ? Exp
class : Instance ? Class
Functii
instances : Class ? ? (Instance)
methods : Class ? Key ? Exp?
M : Class ? ? (Key), M(P) = {m : methods(P,m) ?? }
Figura 3.5. Multimile si functiile sistemului de metode introdus în [COO89]
Multimea Exp? reprezinta multimea implementarilor de operatii reunita cu
elementul nedefinit ? . Înainte de a formaliza mecanismul de mostenire pe baza
acestui sistem de metode, vom definit în cele ce urmeaza o relatie binara peste
multimea Exp?.
Definitie 2. Fie e, f ? Exp? doua expresii. Spunem ca e este "nedefinita sau
egal cu" f, si vom nota e f , daca e = ? sau e = f.
Din definitie rezulta ca evident faptul ca relatia este ordine partiala.
69

Vom formaliza în continuare mecanismul de mostenire al unui limbaj oarecare
printr-o relatia de tranzitie asupra unei multimi de clase. O pereche de clase (P, Q) va
forma o tranzitie daca Q poate fi derivata din P prin intermediul mecanismului de
mostenire. Exprimarea tuturor mecanismelor de mostenire prin intermediul relatiilor
de tranzitie permite separarea mostenirii de alte elemente ale limbajului, deci se va
obtine o vedere generala, uniforma a mostenirii în diferite limbaje de programarea
orientate-obiect concurente. Astfel, spre deosebire de sistemul formal propus
[COO89] mostenirea nu reprezinta o parte a formalismului sistemului de metode.
Mecanismul de mostenire este surprins prin intermediul unei multimi de clase care pot
fi definite în limbaj fara a utiliza mostenirea, între care însa exista o relatie de
tranzitie.
Definitie 3. Un mecanism de mostenire reprezinta o pereche (Class, ? ), unde
? ? Class ? ? ? Class . Un element (P, ?, Q) din ? se numeste tranzitie. ?
reprezinta multimea entitatilor sintactice care specifica diferentele dintre P si Q. Vom
scrie P ? ? ? Q
?
? ?
pentru (P, ?, Q) ? ? . De asemenea, vom utiliza P ? ? ? ? Q
*
?
pentru a nota închiderea reflexiva si tranzitiva a ? , adica o secventa de tranzitii
individuale.
Relatia de tranzitie ? este o multime de triplete (P, ?, Q). Tranzitiile
specifica modul în care mostenirea poate fi utilizata pentru a deriva o noua clasa Q
din clasa P specificând diferentele (adica noile operatii) în ?. Tranzitiile pot simula
redefiniri, adaugari sau eliminari de componente ale claselor. În [COO89] este
prezentat un model general de mecanism de mostenire în care este surprinsa inclusiv
utilizarea lui self si super. Multimile Class si ? sunt determinate de limbajul analizat.
Deoarece Q ? Class (Q fiind definita fara mostenire), definitia 3 specifica
faptul ca orice clasa ce poate fi definita utilizând mostenirea se poate defini si fara
aceasta.
Se va formaliza în cele ce urmeaza notiunea de ierarhie de mostenire
incrementala. Intuitiv, fiecare tranzitie utilizata într-o astfel de ierarhie trebuie sa fie
o tranzitie incrementala, adica aceasta trebuie doar sa defineasca noi operatii fara
redefinirea nici uneia dintre operatiile mostenite.
70

Definitie 4. Tranzitia P ? ? ? Q
?
71
este incrementala daca si numai daca
methods(P) methods(Q). Submultimea tuturor tranzitiilor incrementale se noteaza
??
? I
.
Se defineste notiunea de imp(P) ca fiind o functie care returneaza cel mai
specializat tip implementat de clasa P. Aceasta functie este utilizata în primul rând
pentru formalizarea afirmatiei 1 prin definirea conceptului de conservare a
comportamentului. Definitia anomaliei de mostenire va fi obtinuta apoi prin
formalizarea afirmatiei 2.
Sunt utilizate doua rezultate din [MAN74] si care au urmatoarea semnificatie:
daca x este limita inferioara pentru Y si x ? Y, atunci pY = x. De asemenea, daca pY
exista atunci ea este unica.
Sa presupunem ca notiunea de tip este definita, si ca Types reprezinta
multimea tuturor tipurilor posibile. Vom considera acum cel mai restrâns tip
implementat de catre o clasa.
Definitie 5. Fie ? ? Types . Clasa P implementeaza ? daca si numai daca
p ? ? , ? p ? instances(P). Mai mult, imp(P) = p{? : P implementeaza ?}. Spunem
ca un mecanism de mostenire (Class, ? ) conserva comportamentul daca si numai
daca P ? ? ? I Q ? imp(
Q)
? imp(
P)
?
.
Pentru orice notiune de tip este necesara existenta lui imp(P) pentru orice clasa
P. imp(P) reprezinta cel mai restrâns tip implementat de P, si este o functie, deoarece
asa cum s-a aratat mai sus, cea mai mare limita inferioara este unica. Functia imp nu
este injectiva în general, deoarece de obicei exista mai multe implementari diferite ale
aceluiasi tip. Un mecanism de mostenire conserva comportamentul daca de-a lungul
oricarui drum din cadrul unei ierarhii de mostenire incrementale subclasele sunt legate
de superclasele lor prin relatia de subtipizare.
Definitie 6. Fie un mecanism de mostenire (Class, ? ) si P , Q ? Class . Se
definesc urmatoarele multimi:
G P
? { Q:
P ?
*
? ? ?
? ? ?
Q}
*
? ? ?
I ? { Q:
P ? ? ? ? I Q}
P
B P
S P
? { Q:
imp(
Q)
? imp(
P)}
? { ?
? Types : ? ? imp(
P)}

Multimea GP reprezinta multimea tuturor claselor care pot fi obtinute din P
prin aplicarea repetata a mecanismului de mostenire. De notat faptul ca GP ? Class ,
însa în majoritatea cazurilor GP ? Class deoarece multe mecanisme de mostenire
permit obtinerea oricarei clase date din P prin redefiniri, eliminari si adaugari
repetate. Multimea IP este o submultime a lui GP care permite doar tranzitii
incrementale din P. Fie imp(P)=?. Multimea tuturor claselor care implementeaza
subtipurile lui ? este notata prin BP. În general, IP nu este o submultime a lui BP daca
mecanismul de mostenire nu conserva comportamentul. Intersectia ( I P ? BP)
reprezinta multimea tuturor claselor care implementeaza subtipurile lui ? si care pot fi
obtinute incremental din P. Imaginea multimii BP prin imp este data de imp(BP) si
este o submultime a lui SP, multimea tuturor subtipurilor lui ?. În majoritatea
cazurilor vom avea SP = imp(BP).
Class
GP
IP
BP
imp
72
imp
imp
imp(I P? B P)
S P
Types
imp(Bp)
Figura 3.6. Reprezentarea grafica a multimilor din definitia 7
pentru o clasa particulara P
Definitie 7. Un mecanism de mostenire (Class, ? ) este fara anomalii relativ la
Types daca si numai daca ? P ? Class,
imp(
I P ? BP)
? imp(
BP)
..
Propozitie 1. Fie P? Class . Mecanismul de mostenire (Class, ? ) este fara
anomalii relativ la o definitie data pentru Types daca si numai daca ? Q ? Class , daca
imp(Q) ? imp(P) atunci
*
? ? ? ? , R? Class astfel încât P ? ? ? I R
?
si imp(R)=imp(Q).
Demonstratie: Presupunem ca mecanismul de mostenire este fara anomalii.
Prin urmare Q? BP
. Conform definitiei 8 ? R ? ( IP
? BP)
astfel încât

imp(R)=imp(Q). Prin urmare P ? ? ? I R
?
inversa se demonstreaza în mod analog. ?
73
pentru un anumit
*
? ? ? . Implicatia
Definitia 7 reprezinta descrierea generala a anomaliei de mostenire în
programarea orientata obiect concurenta. O versiune particulara a acestei definitii
este data de o notiune particulara de tip. Un mecanism de mostenire poate fi fara
anomalii relativ la o versiune particulara de tip, si în acelasi timp sa contina anomalii
relativ la o alta versiune. Acesta observatie explica inconsistentele existente în
literatura pe aceasta tema. Pâna acum, notiunea de tip care determina o anomalie de
mostenire a fost data doar informal de catre cercetatori, prin intermediul exemplelor.
Prin urmare, diferenta dintre aceste notiuni conduce la concluzii diferite cu privire la
aparitia si implicatiile anomaliilor de mostenire.
Anomaliile de mostenire sunt în mod obisnuit privite ca fiind generate de
interferenta dintre mostenire si concurenta. Acest mod de a vedea lucrurile nu este
însa si cel mai general. De exemplu, anomalii de mostenire au fost întâlnite si în
cazul limbajelor de specificare în timp real secventiale. Formalismul prezentat
permite analiza anomaliilor de mostenire în paradigme diferite.
Mai mult, modelarea utilizata pentru formalizarea mostenirii poate fi utilizata
în mod analog pentru formalizarea relatiilor de agregare sau a mecanismelor de
delegare. Prin urmare anomalii de genul celor identificate în literatura ca fiind
generate de conflicte între concurenta si mostenire pot fi generalizate la anomaliile de
reutilizare identificate într-o maniera informala în sectiunea precedenta.
Vom dezvolta o taxonomie prin utilizarea a doua notiuni particulare de tip din
programarea orientata-obiect concurenta care definesc submultimi ale multimii tuturor
anomaliilor. Scopul principal al acestei sectiuni este acela de a asigura faptul ca toate
anomaliile de mostenire determinate în literatura sunt incluse în taxonomie.
Abordarea formala conduce la exemple de anomalii care nu au fost discutate pâna în
prezent, ceea ce demonstreaza înca odata dezavantajele abordarii informale.
Functiile si multimile semantice definite în figura 3.7 sunt utilizate pentru
formalizarea comportamentului unei instante. Notiunea de comportament considerata
aici priveste un obiect ca o "cutie neagra" care accepta sau nu un anumit mesaj, în
timp ce un observator extern retine toate acceptarile de mesaje. Prin urmare,
comportamentul unei instante este dat de o multime de secvente de mesaje.

Functia beh furnizeaza multimea tuturor secventelor de mesaje posibile pe care
le poate accepta o instanta. Se presupune ca aceasta multime este închisa la prefixare,
adica având o secventa valida < a, a, b >, se considera valide si secventele , si
< a, a>.
beh : Instance ? ? (Key * )
Semantici de urma:
bec : Class ? ? (Key * ), bec(P) = p{ beh(p) : p ? instances(P) }
Semantici de stari
state : ? (Key * ) ? Key * ? ? (Key * )
state(?)u = ?
? ? { z : u^
z ? ? }, daca u ? ?
? , in rest
States : ? (Key * ) ? ? (? (Key * ))
States(?) = { state(?)u : u ? ? }
Figura 3.7. Multimi si functii semantice pentru
formalizare comportamentului obiectelor concurente
Functia bec returneaza comportamentul unei clase. Dupa cum se observa,
comportamentul unei clase este privit ca si comportamentul comun al tuturor
instantelor acesteia. Daca ? este o multime de instante atunci notatia pbeh? reprezinta
cea mai mare margine inferioara a comportamentelor instantelor din ?, p{ beh(p) :
p ? ?}. Se va utiliza formalismul de urme pentru manipularea secventelor de mesaje
definit în [HOA85]. Operatia de concatenare construieste o urma dintr-o pereche de
urme u si v punându-le împreuna în aceasta ordine, rezultatul fiind notat prin u^v.
Capul unei urme u este primul simbol din aceasta, si este notat cu u0.
*
Definitie 8. Multimile de secvente de mesaje ? , ? ?? ( Key ) se afla în relatia:
? T ?
daca si numai daca ? ? ? si ? u ? ?, u = v^z unde v ? ? iar z0 (daca exista) nu apare
niciodata în ?. Multimea nevida de instante ? este un alement al TypesT daca si numai
daca ? p ? ?, pbeh? T beh(p). Mai mult, daca q ? Instance astfel încât pbeh? T
beh(q), atunci q ? ?.
74

Definitia 8 afirma faptul ca o multime de instante ? reprezinta un tip,
caracterizat de pbeh?, daca si numai daca fiecare instanta din ? accepta cel putin toate
secventele de mesaje din pbeh?. Bineînteles, o instanta din ? mai poate accepta si ale
secvente, care însa vor începe cu o urma v din pbeh? urmate de un mesaj z0 (ce nu
apare în pbeh?) care este acceptat de instanta. Prin urmare o instanta din ? se va
comporta identic cu pbeh? pâna în momentul în care va accepta un mesaj nou, dupa
care va avea un comportament distinct (va avea o functionalitate aditionala). Mai
mult, ? reprezinta multimea tuturor instantelor care satisfac proprietatile caracteristice
ale lui ?.
O limitarea a definitiei de tip TypeT este aceea ca nu captureaza corespunzator
cazul în care instantele unei clase au comportamente diferite. De exemplu, clasa
Coada(n) cu un argument n poate fi utilizata în instantierea unei cozi care contine n
elemente. Conform definitiei pentru TypeT singurul tip implementat de aceasta clasa
este tipul caracterizat de { < > }, adica tipul continut de toate instantele ale tutror
claselor (deoarece în cazul n = 0 bec returneaza { < > }). În consecinta, informatia
relativa la comportamentul comun al instantelor lui Coada(n) este pierdut. Aceasta
limitare poate fi înlaturata prin rafinarea definitiei pentru TypesT. În aceasta sectiune
vom utiliza notiune de tip specificata în definitia 8, concentrându-ne atentia asupra
aspectelor legate de taxonomie. Prin urmare vom presupune ca toate instantele unei
clase au acelasi comportament, adica ? p ? instances(p), beh(p) = bec(P).
Propozitie 2. Fie o relatie care captureaza proprietatile comune ale tuturor
instantelor reletive la un anumit tip. Daca este o preordine atunci pbeh? pbeh?
daca si numai daca ? ? ?. În plus, pentru orice clasa P imp(P) = ? exista si pbeh? =
bec(P).
Demonstratie: Presupunem ca pbeh? pbeh? si fie p ? ?. Avem pbeh?
beh(p). Din tranzitivitatea relatiei obtinem pbeh? beh(p) si deci p ? ?.
Presupunem, pentru implicatia inversa, ca ? ? ?, si fie o instanta p astfel încât
beh(p) = pbeh?. Din reflexivitatea relatiei rezulta ca p ? ?. Prin urmare, p ? ? si
pbeh? beh(p). Deoarece beh(p) = pbeh? obtinem pbeh? pbeh?.
Fie o clasa P si un tip ? astfel încât pbeh? = bec(P), si fie p o instanta a lui P.
Din reflexivitatea relatiei si pe baza presupunerii ca bec(P) = beh(p) avem pbeh?
beh(p). Prin urmare orice instanta p a lui P apartine tipului ?, si deci P
75

implementeaza tipul ?. Sa presupunem de asemenea ca P implementeaza ?. Prin
urmare pbeh? bec(P) si deoarece pbeh? = bec(P) vom obtine pbeh? pbeh?. Pe baza
rezultatului anterior vom avea ? ? ?. Prin urmare ? este o limita inferioara a multimii
{ ? : P implementeaza ? }, si deoarece se un element al acestei multimi vom avea ca ?
= imp(P).?
Propozitie 3. Relatia T este preordine.
Demonstratie: Presupunem ca ? T ? si ? T ? , unde ?, ?, ? ? ? (Key * ).
Atunci, ? ? ? si ? u ? ?, u = v^z cu v ? ? si z (posibil vid) astfel încât simbolul z0
(daca exista) nu apare niciodata în ?. Este evident ca ? ? ? .
Fie u ? ? , u = v^z unde v ? ? si deoarece ? T ? avem v = v1^v2 unde v1 ? ?.
Rezulta ca u = v1^(v2^z) si din contructie primul simbol din v2^z nu apare niciodata în
?, deci ? T ? . De asemenea, pe baza definitiei, este evident ca T este reflexiva. ?
Propozitiile 2 si 3 implica faptul ca pentru fiecare clasa cel mai restrâns tip
implementat de aceasta este unic. Un astfel de tip, notat cu impT(P) este caracterizat
de comportamentul clasei P. În acest moment pot fi analizate cazuri concrete de
anomalii de mostenire relative la TypesT. Fie doua clase P si Q. Daca cel mai specific
tip implementat de Q (impT(Q) ? TypesT) este un subtip al celui mai specific tip
implementat de P atunci conform propozitiei 1 trebuie sa existe o clasa R care poate fi
derivata incremental din P si care implementeaza impT(Q). În caz contrar are loc o
anomalie de mostenire.
Anomalia de mostenire indusa de TypesT reprezinta doar o versiune a
problemei generale a anomaliilor de mostenire în programarea orientata-obiect
concurenta. Exista multe alte notiuni de tip utile care pot fi analizate (de exemplu, un
subtip poate fi definit astfel încât sa restrictioneze posibilele secvente de mesaje din
supertip). TypesT induce o anomalie de mostenire deoarece afirmatia 1 este respectata
cu privire la aceasta notiune de tip, în timp ce presupunerea ca afirmatia 2 se respecta
în raport cu TypesT s-a dovedit a fi falsa.
Vom considera în cele ce urmeaza doua submultimi ale multimii de anomalii
induse de TypesT. Cu scopul de a definii formal aceste doua submultimi se va utiliza
o notiune de tip mai puternica. Astfel, se va considera un obiect ca fiind o masina de
stari care evolueaza de la o stare curenta la o noua stare prin acceptarea unui mesaj si
executarea expresiei de metoda corespunzatoare. Prima submultime de anomalii este
76

obtinuta prin constrângerea tuturor instantelor ale aceluiasi tip de a evolua prin acelasi
numar de stari de baza (definitia 10). Prin urmare se considera ca toate instantele
tipului respectiv sunt implementate prin masini de stari similare. Cea de-a doua
submultime de anomalii este obtinuta permitând instantelor aceluiasi tip sa evolueze
în stari aditionale, dar numai în cazul în care aceste stari reprezinta versiuni restrânse
ale starilor de baza (definitia 11).
Intuitiv, starea unui obiect este determinata de valorile propriilor atribute.
Acest lucru însa nu este observabil din exterior. De aceea vom considera o stare ca
fiind multimea secventelor de mesaje care sunt acceptabile la un moment dat. Fie p o
instanta a clasei Coada. Initial, p poate accepta orice secventa din beh(p). Prin
urmare starea initiala a lui p este beh(p). Dupa acceptarea mesajului Adauga,
multimea secventelor de mesaje acceptabile se modifica (de exemplu secventa
nu era acceptata în starea initiala dar acuma da - este secventa corespunzatoare care este acceptata din starea
initiala). Vom spune astfel ca p evolueaza de la starea initiala la o noua stare. De
exemplu, secventele de mesaje , , < Adauga,
Extrage, Adauga> conduc toate spre acceasi stare a lui p. Functia state din
semanticile starilor derivate descrise în figura 3.7 primeste starea initiala a unei
instante si returneaza starea instantei dupa acceptarea secventei de mesaje u. Functia
States retunreaza pe baza starii initiale a unei instante, multimea tuturor starilor
instantei (multime ce poate fi infinita).
state(?)u.
Propozitie 4. Fie ?, ? ? ? (Key * ) si ? T ?. Atunci, ? u ? ?, state(?)u T
Demonstratie. Fie u ? ?. Deoarece ? ? ?, u ? ? si state(?)u ? ? . Fie t ?
state(?)u. Atunci u^t ? ?. Deci t ? state(?)u si avem state(?)u ? state(?)u.
Fie z ? state(?)u. Rezulta ca u^z ? ? si deoarece ? T ?, u^z = (u^z1)^z2 unde
u^z1? ? si primul simbol din z2 nu apare niciodata în ?. Prin urmare, z1 ? state(?)u. ?
Pentru a exemplifica propozitia 4 sa consideram o instanta, p, a clasei Coada,
si o instanta, q, a clasei Coada2. Dupa acceptarea unei secvente de mesaje u, p va
ajunge într-o stare ?, iar q într-o stare ?. Intuitiv putem spune ca între cele doua stari
trebuie sa existe o relatie strânsa. Propozitia 4 arata ca orice secventa de mesaje
acceptabila din starea ? este de asemenea acceptabila si din starea ?. Acest lucru
trebuie sa aiba loc deoarece Coada2 implementeaza un subtip al tipului implementat
77

de Coada, si deci trebuie ca instantele acestei clase sa se comporte în mod similar cu
instantele clasei Coada. În plus, starea ? poate permite sî altor secvente de mesaje sa
fie acceptate, secvente de mesaje care vor contine noul mesaj Extrage2(). În general,
dupa acceptarea unei astfel de secvente, q poate sa evolueze spre o stare noua, care nu
are legatura cu nici una dintre starile lui p. În cazul clasei Coada2, o instanta a
acesteia nu va ajunge niciodata într-o stare care nu corespunde unei stari ale lui p. În
cazul clasi BCoada însa, o instanta poate sa ajunga într-o astfel de stare în momentul
acceptarii mesajului Blocare(). În aceasta stare nici unul dintre mesajele Extrage() si
Adauga() nu sunt acceptate, ceea ce nu se întâmpla în nici una dintre starile clasei
Coada.
Definitie 9. Fie ?,? ? ? (Key * ). Atunci,
? f ?
daca si numai daca ? T ? si ?f : States(?) ? States(?) astfel încât f sa fie bijectie.
Multimea nevida de instante ? este un element din Typesf daca si numai daca ? p ? ?,
pbeh? f beh(p). În plus, daca q ? Instance si pbeh? f beh(q) atunci q ? ?.
Definitia 9 afirma faptul ca o multime de instante ale lui ? reprezinta un tip,
caracterizat prin pbeh?, daca si numai daca ? este un tip definit de definitia 9 si fiacare
instanta din ? are acelasi numar de stari. Pe baza propozitiei 4, fiecare stare din pbeh?
este în strânsa legatura cu starile unei instante din ?. Deoarece numarul de stari este
egal, rezulta ca fiecare stare a unei instante este la rândul sa în legatura cu o stare din
pbeh?. Prin urmare, toate instantele tipului ? se au un comportament modelat de
masini de stari similare.
Propozitie 5. f este preordine. Demonstratia este imediata. ?
Propozitie 6. Multimea de anomalii relative la notiunea de tip Typesf este o
submultime a multimii de anomalii induse de notiunea de tip TypesT. Demonstratia se
afla în [CRN98]. ?
Notiunea de tip Typesf ne conduce la o submultime a problemei. Exemple de
limbaje de programare orientate-obiect concurente care sufera de anomalii de
mostenire relative la Typesf sunt limbajele cu rutine de vitalizare si cele care utilizeaza
multimi de acceptare. Asa cum am aratat în capitolul doi, limbajele cu rutine de
vitalizare realizeaza specificarea explicita a acceptarii mesajelor în cadrul unor functii
speciale. Aceste limbaje genereaza anomalii de tipul celor definite în definitia 10, din
78

cauza controlului de interfata centralizat, care grupeaza toate constrângerile de
sincronizare într-o singura functie. Astfel, adaugarea unei noi operatii într-o subclasa
determina redefinirea functiei de vitalizare, în caz contrar aceasta operatie neputând sa
fie executata niciodata.
Exista si limbaje care nu au un control centralizat al interfetei, dar care sunt
predispuse la anomalii relativ la notiunea de tip Typesf. În majoritatea acestor limbaje
controlul sincronizarii se realizeaza utilizând multimi de acceptare, specificându-se de
fiecare data multimea curenta de operatii acceptabile specificata de codul de
sincronizare. Multimea de operatii acceptabile se modifica pe masura ce obiectul
evolueaza, si acest lucru se realizeaza prin specificarea de catre fiecare operatie a
urmatoarei multimi de acceptare.
Anomaliile de partitionare a starilor abstracte din clasificarea propusa de
Matsuoka si Yonezawa [MAT93] satisfac definitia 9. Prin urmare, aceste anomalii
sunt exemple de anomalii relative la notiunea de tip Typesf. Anomaliile induse de
Typesf sunt eliminate în multe abordari prin intermediul metodelor cu garzi.
Propozitie 7. Un limbaj de programare orientat-obiect concurent care
implementeaza mecanismul de sincronizare bazat pe metode cu garzi este fara
anomalii relative la Typesf.
Demonstratie. Demonstratia completa necesita o formalizare a semanticii
garzilor. Fie clasele P si Q astfel încât impf(Q) ? impf(P). Sa presupunem ca
M(P) = {m1, ..., mn} si M(Q) = { m1, ..., mk} unde n ? k. Putem presupune, fara a se
restrânge generalitatea, ca k = n+1. Sa presupunem de asemenea ca ambele clase
utilizeaza metode cu garzi.
Se va construi incremental clasa R din P astfel încât impf(R)=impf(Q).
Deoarece bec(P) f bec(Q) este suficienta construirea unei garzi pentru metoda mn+1
în R astfel încât mn+1 sa fie acceptata daca si numai daca ea este acceptata de garda
acesteia din Q. Ar fi ideala utilizarea garzii din Q pentru definirea metodei din R însa
acest lucru nu poate fi realizat deoarece aceasta poate contine proprietati ale clasei Q
care sunt diferite de cele din R.
Din aceasta cauza garda pentru metoda mn+1 se va construi astfel: garda are o
multime oarecare de instante ale claselor P si Q. La receptionarea unui mesaj mn+1
expresia de garda trebuie sa determine care secventa de mesaje conduce la starea
curenta a obiectului. Aceasta este obtinuta prin încercarea tuturor secventelor de
79

mesaje posibile de lungimi 1, 2, ... În mod evident acest proces va putea determina
atât secventa de mesaje care a condus la starea curenta cât si alte secvente cu acelasi
efect. Prima secventa de acest tip va fi aplicata unei instante a clasei Q, urmata de
mesajul mn+1. Garda clasei R va accepta apelul de metoda mn+1 daca si numai daca
instanta clasei Q accepta mesajul mn+1. De notat ca evaluarea garzii clasei R nu va
genera efecte secundare asupra proprietatilor lui R. Prin urmare R satisface
proprietatea 1. ?
Se va defini în continuare cea de-a doua submultime de anomalii de mostenire.
Definitie 10. Fie ?, ? ? ? (Key * ). Relatia:
? R ?
are loc daca si numai daca ? T ? si ? s ? States(?), ?s' ? States(?) astfel încât, ? u ?
s u contine un simbol m care nu apare niciodata în ? sau u ? s'. Multimea nevida de
instante ale lui ? este un element al TypesR daca si numai daca ? p ? ?, pbeh? R
beh(p). În plus, daca q ? Instance astfel încât pbeh? R beh(q) atunci q ? ?.
Definitia 10 afirma faptul ca o multime de instante ? reprezinta un tip,
caracterizat de pbeh? daca si numai daca ? este un tip caracterizat de definitia 8 si
fiecare stare a unei instante în ? reprezinta o restrictie a uneia dintre starile din pbeh?.
Cu alte cuvinte, o instanta din ? poate avea mai multe stari decât pbeh? (care sunt
'activate' în momentul aceptarii unuia dintre mesajele noi). Fiecare dintre starile noi
trebuie sa contina urme din una din starile din pbeh? sau urme care implica metode
noi.
Anomaliile de mostenire determinate de istoric si cele de modificarea starilor
abstracte se încadreaza amândoua în definitia 10. Figura 3.8 prezinta pozitia celor
trei anomalii identificate în clasificarea Matsuoka-Yonezawa relativ la anomaliile de
mostenire bazate pe notiunile de tip formalizate pâna acum.
Propozitie 8. R este preordine. Demonstratia este imediata. ?
În mod analog cu propozitia 6 se poate arata ca multimea anomaliilor induse
de TypesR reprezinta o submultime a multimii anomaliilor induse de TypesT,
conducând la ierarhia din figura 3.8.
80

anomalii de
modificare a starii
anomalii de
partitionare a starii
anomalii
determinate de istoric
T R f
Figura 3.8. Anomalii induse de trei definitii de tip
Teorema 1. Fie un mecanism de mostenire (Class, ? ). Daca (Class, ? )
conserva comportamentul relativ la TypesT atunci acesta nu este fara anomalii relativ
la TypesR.
Demonstratie. Fie Reg ? ? (Key * ) multimea tuturor limbajelor regulare
peste Key. Vom presupune ca Reg ? bec(Class) - deci fiecare limbaj regular poate fi
acceptat de instante ale unei clase. Sa presupunem de asemenea ca mecanismul de
mostenire este fara anomalii relativ la TypesR si conserva comportamentul în raport cu
definitia de tip TypesT.
Fie P ? Class astfel încât bec(P)={ m1, m2 } * pentru anumiti m1, m2 ? Key.
Fie u ? bec(P) si m ? Key astfel încât m nu apare în bec(P). Atunci v = u^ ?
bec(P).
Vom considera acum tipul ? ? TypesR, unde pbeh? = bec(P) ? { v, v^ }.
Deoarece bec(P) R pbeh? rezulta ca ? ? impR(P) (v începe cu u care apartine lui
bec(P)). De asemenea fiecare stare din pbeh? contine urme care contin metodele m, m1
sau m2, si fiecare urma care contine m1 si/sau m2 reprezinta o urma în starea unica a
lui bec(P). Aplicând închiderea, vom avea pbeh? ? Reg.
Prin urmare, ? Q ? Class astfel încât bec(Q) = pbeh?, si deci impR(Q) ?
impR(P). Pe baza propozitiei 1 vom avea:
(1) ?? ? ? * , R ? Class a. î. P ? ? ? I R
?
si impR(R) = impR(Q) = ?.
Vom presupune în continuare ca, având P ? ? ? I Q si z ? bec(Q) atunci este
posibila construirea lui P' si Q' astfel încât P'? ? ? I Q'
, bec(Q') = state(bec(Q))z si
bec(P') = state(bec(P))w, cu w ? bec(P). Din presupunerea de mai sus avem ca Q' si
81

P' difera de Q respectiv P doar prin starea initiala. Starea unei instante este
determinata de valorile proprietatilor sale. Deci, Q' se obtine din Q prin modificarea
valorilor initiale ale anumitor proprietatile. În functie de limbaj acest lucru poate
invalida tranzitia incrementala dintre P si Q'. Prin urmare, vom impune ca fiind
întotdeauna posibila modificarea valorilor initiale ale proprietatilor din P (obtinând
P') astfel încât P' ? ? ? I Q'
. Aceasta afirmatie este adevarata pentru toate limbajele
de programare orientate obiect concurente imperative studiate în cadrul capitolului
doi.
Pornind de la expresia (1), vom considera v = u^ ? bec(R) si vom
construi clasa R' astfel încât bec(R') = state(bec(R))v. Din presupunerea anterioara
'
avem P' ? ? ? I R'
?
si bec(P') = state(bec(P))w, cu w ? bec(P). Dar bec(R') = { < >,
} în timp ce bec(P') = { m1, m2 } * (P are o singura stare).
Deci bec(P') T bec(R') si impT(R') ?? impT(P'). Prin urmare mecanismul de
mostenire nu conserva comportamentul.?
Teorema 1 demonstreaza faptul ca chiar pentru o submultime a anomaliilor
(indusa de TypesR), nu poate fi proiectat un limbaj de programare orientat-obiect
concurent fara anomalii si care conserva comportamentul. Majoritatea limbajelor de
programare orientate-obiect concurente conserva comportamentul relativ la TypesT.
Teorema 1 are loc doar pentru limbajele de programare care sunt cel putin la fel de
expresive ca si masinile cu stari finite.
3.4. Modelarea principiilor de proiectare ale limbajelor orientate-obiect
concurente
În cadrul capitolului precedent am determinat o multime de patru principii de
proiectarea ale limbajelor de programare orientate-obiect concurente. Aceste patru
principii sunt:
- principiul expresibilitatii concurentei, care se refera la:
- concurenta intra-obiect,
- executie dependenta de stare,
- executie dependenta de istoric,
- principiul codului de interactiune orientat pe obiectul apelat,
82

- principiul izolarii codului de sincronizare concurenta,
- principiul separarii codului de sincronizare concurenta.
Principiile de mai sus trebuie sa fie respectate de catre mecanismele de
coordonare a concurentei într-un context orientat-obiect astfel încât avantajele
caracteristice programarii concurente sau ale programarii orientate obiect sa nu se
reduca sau chiar anuleze. Principiile au fost determinate pe baza unor studii informale
privind programarea orientata-obiect si programarea concurenta. Am aratat însa ca
nici unul dintre limbajele de programare orientate-obiect concurente dezvoltate pâna
în prezent nu respecta toate aceste principii.
Sistemul formal prezentat în sectiunea anterioara este potrivit pentru
modelarea tuturor acestor principii. Mai mult, el are la baza respectarea primului
principiu enuntat, si anume acela al localizarii codului de gestiune a interactiunilor
între activitati concurente la nivelul obiectului activ apelat.
Executia dependenta de stare si cea dependenta de istoric au fost de asemenea
modelate prin intermediul definitiei 8. Aceasta introduce o notiune particulara de tip
prin modelarea comportamentului instantelor claselor concurente având la baza
sistemul de domenii si operatii semantice prezentat în figura 3.7. Definitia 8 sta la
baza extinderii unui formalism vizual de modelare a comportamentului obiectelor
active si care va fi prezentat în cadrul capitolului urmator.
Modelarea concurentei interne se realizeaza prin rafinarea multimii de mesaje
Key. Vom nota aceasta multime cu Keyintra si ea nu va contine doar o multime
simpla de signaturi de mesaje, ci pentru fiecare m ? Key, Keyintra va contine o
pereche ms - msf, unde ms reprezinta inceputul invocarii mesajului m, iar msf sfârsitul
acestei invocari. Pentru modelarea concurentei interne definitia anomaliei de
mostenire si taxonomia anomaliilor definite în sectiune precedenta pot fi usor
generalizate, prin introducerea de noi operatii semantice behintra, becintra, stateintra si
Statesintra (figura 3.9).
83

eh intra : Instance ? ? (Key intra * )\Inv
Semantici de urma:
bec intra : Class ? ? (Key intra * )\Inv, becintra(P) = p{ beh intra(p) : p ?
state intra
Semantici de stari
: ? (Key intra * )\Inv ? Keyintra * ? ? (Keyintra * )\Inv
stateintra(?)u = ?
? ? { z : u^
z ? ? }, daca u ?
? , in rest
States intra
: ? (Key intra * )\Inv ? ? (? (Keyintra * )\Inv)
States intra(?) = { state intra(?)u : u ? ? }
Figura 3.9. Multimi si functii semantice de surprindere a concurentei interne
Daca beh reprezenta multimea tuturor secventelor de mesaje care pot fi
acceptate de catre o instanta, behintra va avea o definitie similara, însa trebuie avuta în
vedere excluderea secventele inconsistente de mesaje (prin care terminarea invocarii
unui mesaje precede startul acesteia). Multimea Inv, pe care o vom numi multime de
inversiuni, este multimea care contine toate aceste secvente. Pentru a caracteriza
aceasta multime vom defini functia:
nr : Keyintra* ? Keyintra ? ,
unde nr(, m) reprezinta numarul de aparitii al mesajului m în secventa
de mesaje . Prin urmare multimea Inv poate fi definita astfel:
Inv = {, ? i ? n, ? ms, msf ? Keyintra a.î.
nr(, ms) < nr(, msf)},
adica multime Inv reprezinta multimea tuturor secventelor de mesaje pentru care
exista cel putin un mesaj din Keyintra si cel putin o subsecventa în care numarul de
aparitii al startului invocarii mesajului este mai mic decât numarul de aparitii a
terminarii invocarii mesajului.
în relatia:
84
?
Definitie 11. Multimile de secvente de mesaje ?, ? ? ? (Keyintra * )\Inv se afla
? Tintra ?
daca si numai daca ? ? ? si ? u ? ?, u = v^z unde v ? ? iar z0 (daca exista) nu apare
niciodata în ?. Multimea nevida de instante ? este un alement al TypesTintra daca si

numai daca ? p ? ?, pbehintra? T behintra(p). Mai mult, daca q ? Instance astfel încât
pbehintra? T behintra(q), atunci q ? ?.
Definitia 11 introduce notiunea de tip TypesTintra. Aceasta reprezinta o
generalizare a notiunii de tip TypesT si, prin urmare, ea induce o multime de anomalii
de mostenire care include anomaliile de mostenire induse de TypesT. Deci, prezenta
concurentei intra-obiect nu conduce la ameliorarea anomaliilor de mostenire, ci
dimpotriva poate induce anomalii de mostenire noi.
Daca principiul expresibilitatii concurentei este strict legat de puterea de
specificarea a concurentei la nivelul obiectelor active, celelalte trei principii au în
vedere respectarea proprietatilor mecanismelor specifice programarii orientate-obiect.
Prin urmare respectarea acestor principii poate influenta si efectul anomaliilor de
mostenire. Definitia urmatoare formalizeaza principiile izolarii si separarii codului de
specificare a interactiunilor între activitati concurente de codul care implementeaza
functionalitatea unui obiect activ. Acest lucru poate fi surprins prin înlocuirea
multimii Key cu multimea Keyc care va contine pentru fiecare mesaj m ? Key o
pereche m f , m c , unde methods(m f ) reprezinta codul care implementeaza
functionalitatea mesajului m, iar methods(m c ) reprezinta codul de sincronizare.
f c f c
Definitie 12. Daca M(P) = M(Q) = { m m , m , m ,... } si ?
85
1 , 1 2 2
c
m i ? Keyc*
methods(P) m = methods(Q) m , spunem ca limbajul respecta principiile izolarii si
c
i
c
i
separarii codului de interactiune concurenta daca si numai daca oricare ar fi P si Q
avem imp(P) = imp(Q).
Propozitie 9. Fie un limbaj de programare orientat-obiect concurent care
respecta principiile izolarii si separarii codului de interactiune concurenta relativ la
definitia de tip TypesT. Pentru un astfel de limbaj o anomalie de mostenire nu necesita
redefinirea partii functionale a operatiilor.
Demonstratie. Fie clasele P si Q pentru care presupunem ca are loc relatia
impT(Q) ? impT(P).
Deoarece are loc o anomalie de mostenire rezulta ca
? ?? ? *, R ? Class astfel încât P ? ? ? I R
?
si impT(R) = impT(Q).
f c f c f
Fie M(P) = { m m , m , m ,..., m , m
c
f c f c
1 , 1 2 2 n n } si M(Q) = { 1 , m1
,..., mn
, mn
,...
m }.
Vom contrui clasa R astfel încât ea sa fie identica cu Q mai putin operatiile pentru
care are loc methods(R) m = methods(P) m , unde 1 ? i ? n. Pe baza definitiei 12
f
i
f
i

vom avea ca impT(R) = impT(Q). Însa, prin constructie, clasa R nu redefineste cod
functional din P. Prin urmare anomalia de mostenire are loc doar la nivelul codului
de descriere a constrângerilor de sincronizare. ?
Propozitia 9 demonstreaza faptul ca specificarea si mostenirea separata a
codului de implementare a constrângerilor de sincronizare conduce la ameliorarea
anomaliilor de mostenire prin directionarea efectului acesteia doar asupra operatiilor
care implementeaza acest cod. Prin urmare codul de descriere a functionalitatii
obiectelor active nu necesita rescriere. Limbajele de programare care implementeaza
o notiune de tip TypesT si respecta întocmai conditiile definitiei 12 sunt limbajele cu
mecanisme de sincronizare cu control reflectiv. Limbajele cu mecanisme de
sincronizare cu control mixt ofera în general suport pentru respectarea definitie 12,
însa ele nu garanteaza respectarea acesteia (definitia 12 poate fi respectata doar
urmând o anumita disciplina de programare).
3.5. Concluzii
Rezultatele formalizarii anomaliilor de mostenire din sectiunea 3.3.
demostreaza faptul ca nu exista un model obiect ideal, în care sa nu fie prezente
anomalii de reutilizare. Efectul acestor anomalii poate fii însa ameliorat.
Respectarea principiile enuntate în cadrul capitolului doi si modelate formal în
cadrul acestui capitol conduc la o astfel de ameliorare. Din acest punct de vedere
principiul separarii codului de interactiune concurenta este cel mai important. Astfel
partea care tine exclusiv de concurenta va putea fi reutilizata separat de partea care
descrie functionalitatea. Deoarece separarea acestor notiuni duce la cresterea
posibilitatii de reutilizare, am analizat modul în care aceasta conduce la reducerea
efectelor anomaliilor de mostenire. Trebuie specificat faptul ca nimic nu constrânge
programatorul în a nu amesteca codul corespunzator functionalitatii cu cel pentru
descrierea constrângerilor de sincronizare. De exemplu, în cazul utilizarii
mecanismului de metode cu garzi, datorita faptului ca garzile au acces la proprietatile
obiectelor ele depind în general de detaliile de implementare ale operatiilor. Prin
urmare, reimplementarea unei operatii poate conduce si la reimplementarea codului
de sincronizare. Reciproca este de asemenea adevarata.
86

Teorema 1 afirma faptul ca daca exista un mecanism de mostenire fara
anomalii atunci el nu va conserva comportamentul. Prin urmare, o alta posibila
abordare de ameliorare a anomaliilor de mostenire este aceea de a introduce un astfel
de mecanism. Astfel, adaugarea de noi operatiie în cadrul unei clase nu va conduce în
mod necesar la crearea de subtipuri ale tipului initial. Mecanismele fara conservare a
comportamentului sunt mult mai expresive decât cele cu conservare a
comportamentului, si sunt capabile sa trateze mai multe anomalii de mostenire. În
literatura însa sunt foarte putine propuneri de astfel de mecanisme, deoarece ele
implica o multime de probleme cum ar fi negarantarea relatiei de subtipizare sau
necesitatea unor studii în directia tehnicilor de analiza statica si a tehnicilor de
optimizare în vederea eficientizarii programelor.
O a treia abordare de reducere a anomaliilor consta în construirea de biblioteci
de politici generice de sincronizare si concurenta, si ea este derivata din principiul
separarii codului de interactiune concurenta. Astfel, în locul mostenirii partii de
specificare si coordonare a concurentei dintr-o superclasa, o subclasa va avea
posibilitatea instantierii unei politici particulare. Aceasta abordare este utila în special
în cazul specificarii concurentei interne, unde exista un numar relativ restrâns de
politici utilizate (cum ar fi cititori/scriitor, prioritatea cititorilor etc).
În alta ordine de idei, faptul ca un model obiect este "predispus" la anomalii de
reutilizare nu implica automat ideea ca aceste anomalii nu vor putea fi evitate. S-a
aratat în dese rânduri, în studiul primitivelor de interactiune concurenta, faptul ca
urmarea unei discipline de programare poate oferii beneficii pe care analiza teoretica a
unui limbaj nu le releva. Prin urmare o alta solutie de eliminare a efectului
anomaliilor l-ar putea reprezinta generarea automata de cod pe baza unor modele de
structura si comportament ale obiectelor active.
Instrumentele CASE (Computer Aided Software Engineering) sunt utilizate tot
mai des în dezvoltarea de sisteme informatice, datorita multiplelor avantaje pe care le
implica: întelegerea mai profunda a specificatiilor, încurajarea reutilizabilitatii,
asigurarea corectitudinii codului (pentru codul generat automat), suport pentru lucru
în echipa etc ([BOZ94a], [CHI96], [CHi97], [SUC96a], [SUC96b]). Prin urmare, pe
lânga toate aceste avantaje, utilizarea intrumentelor CASE poate determina scadere
procentului de anomalii de mostenire în dezvoltarea de aplicatii orientate-obiect
concurente.
87

Formalizarea anomaliilor de mostenire prin intermediul comportamentului
extern observabil implica o maniera generala si eleganta de abordare a modelarii
aplicatiilor orientate-obiect concurente. Gradul de generalitate al acestora face
posibila dezvoltarea de modele a caror implementarea se poate realiza într-o gama
foarte variata de limbaje de programare. Pe baza acestor argumente în cadrul
capitolului patru vom specifica un formalism vizual de modelare a comportamentului
obiectelor active, având ca fundament formalismul hartilor de stari.
88

4. Modelarea comportamentului obiectelor active
4.1. Introducere
În cadrul acestui capitol propunem un formalism de modelare a
comportamentului obiectelor active. Acest formalism reprezinta o extensie a
formalismului vizual al hartilor de stari ([HAR87]).
În sectiunea a doua vom justifica alegerea hartilor de stari ca formalism de
baza, prin tratarea obiectelor active ca si sisteme reactive.
În cadrul sectiunii a treia, vom descrie formalismul hartilor de stari care
înglobeaza o serie de extensii ale masinilor cu stari finite si care a fost utilizat (cu
unele modificari) în majoritatea metodelor si tehnicilor de analiza orientata - obiect a
aplicatiilor (OMT [RUM91], Syntropy [COO94], UML [OMG99] etc.) pentru
descrierea comportamentului obiectelor, chiar daca în momentul dezvoltarii lor hartile
de stari nu au fost asociate cu paradigma orientata-obiect.
Asa cum vom arata în sectiunea a patra, hartile de stari sau diferite extensii ale
acestora au fost utilizate cu predilectie pentru modelarea comportamentului obiectelor
dintr-o anumita clasa. Multe dintre aceste metodologii însa nu reusesc sa defineasca
în mod riguros semanticile limbajului propus. Este si cazul limbajului de modelare
UML, care desi devenit limbajul standard utilizat în analiza si proiectarea aplicatiilor
orientate-obiect, contine o seama de elemente ambigue, vag specificate, sau chiar
contradictorii. În ceea ce priveste varianta diagramelor de tranzitie a starii propusa de
UML, am realizat în cadrul sectiunii a patra o analiza critica a acesor tipuri de
elemente.
89

În scopul dezvoltarii unui formalism care sa permita realizarea de modele
executabile (care permit translatarea automata în cod sursa), am definit în sectiunea a
cincea o extensie a hartilor de stari definite în UML, numita harta de stari scalabila.
Definirea semanticilor acestei variante este precedata de definirea unui model obiect
suficient de general, care este caracteristic tuturor limbajelor de programare care
implementeaza primitive de interactiune între activitati concurente bazate pe
încapsulare.
4.2. Sisteme reactive
În analiza sistemelor de calcul exista o dihotomie fundamentala care
tranziteaza frontierele dintre sistemele secventiale sau paralele, centrale sau
distribuite, imperative sau functionale. Aceasta dihotomie este între sistemele
transformationale si cele reactive.
Sistemele tranformationale sunt acele sisteme care pot fi descrise prin
intermediul unei relatii între valorile de intrare si de iesire ale acestora. Aceste
sisteme primesc anumite valori sau semnale de intrare pe baza carora vor produce, în
mod determinist sau nu, valori de iesire sau reactii, dupa care executia lor ia sfârsit.
Valorile sau semnalele de intrare sunt complet cunoscute de catre sistem în momentul
invocarii sale, iar producerea rezultatelor necesita o anumita perioada de calcul.
Sistemele transformationale au o structura liniara, iar singurele stari care au relevanta
pentru descrierea acestora sunt starile initiale si cele finale (figura 4.1).
SISTEM
TRANSFORMATIONAL
intrari (date) iesiri (rezultate)
90
timp
Figura 4.1. Schema de functionare a unui sistem transformational
Sistemele de achizitie a datelor, sistemele de compresia a vocii sau procedurile
simple de calcul a radicalului sau logaritmului unui numar reprezinta exemple de
sisteme transformationale.
Spre deosebire de sistemele tranformationale, sitemele reactive se
caracterizeaza prin faptul ca interactioneaza continuu cu mediul din care fac parte

(figura 4.2). Aproape toate sistemele contin cel putin un subsistem reactiv, deoarece
rareori un sistem este izolat de mediul în care activeaza.
SISTEM
REACTIV
91
timp
Figura 4.2. Reprezentarea schematica a unui sistem reactiv
si a canalelor sale de interactiune cu mediul înconjurator
Unul dintre cele mai reprezentative exemple de sisteme reactive este sistemul
de control al luminii de trafic. Acest sistem nu va avea niciodata intrarile pregatite,
ele sosind în secvente infinite si nedeterminate. Este imposibil de proiectat un sistem
transformational pentru un astfel de control. De fapt, majoritatea sistemelor de
control sunt reactive si nu transformationale. De asemenea, ceasurile digitale,
circuitele integrate sau sistemele program interactive reprezinta la rândul lor exemple
comune de sisteme reactive.
Deoarece au fost obtinute rezultate notabile în formalizarea sistemelor
tranformationale, s-a încercat specificarea sistemelor reactive prin intermediul
acestora, prin gruparea tuturor canalelor de intrare si de iesire în secvente de intrare
respectiv de iesire. Deoarece comportamentul mediului (caracterizat de intrarile
transmise sistemului) depind de reactiile anterioare ale sistemului, o astfel de abordare
s-a dovedit a fi nesatisfacatoare. Prin urmare, o relatie între secventele de intrare si
cele de iesire nu este suficienta pentru a descrie un sistem reactiv. Acest fenomen este
cunoscut în literatura ca paradoxul Brock-Ackermann [BRO81] si a fost descris
pentru prima data prin intermediul retelelor de fluxuri de date. Astfel, pentru o
descriere corecta a unui sistem reactiv, alaturi de secventele de intrare si de iesire mai
trebuie cunoscute momentele în care rezultatele sunt produse. O astfel de informatie
presupune includerea unei descrieri temporale a evenimentelor de intrare si iesire sau
o descrierea unei notini mai abstracte de timp (în cazul în care ordinea evenimentelor
de iesire este specificata relativ la evenimentele de intrare).
Într-un sistem reactiv, momentul în care o noua valoare de intrare este
receptionata este relevant pentru comportamentul sau. Cu alte cuvinte, starea interna
a sistemului la receptionarea intrarii este importanta pentru modul în care acesta va
reactiona în continuare. Prin urmare este necesara acordarea unei atentii sporite

starilor intermediare. Ele nu reprezinta doar puncte simple în calea atingerii starii
finale, ci au un înteles propriu. Mai mult, într-un numar considerabil de sisteme
reactive nu exista stare finala.
Asa cum am aratat si în capitolul precedent în cadrul analizei anomaliilor de
mostenire, obiectele active se deosebesc de cele pasive prin faptul ca au un fir de
executie propriu. În plus, în orice moment de timp exista o submultime de metode
acceptabile în functie de starea interna a obiectului. Acceptarea unei cereri de lansare
în executie a unei operatii din aceasta submultime determina modificarea sa.
Comportamentul unui obiect activ a fost modelat formal prin intermediul unor
secvente de mesaje (definite prin invocari de operatii). Acceptarea unui mesaj este
strâns legata de multimea mesajelor acceptate anterior. Bineînteles, acceptabilitatea
unui mesaj este data în ultima instanta de starea obiectului activ la un moment dat,
stare care a fost definita în capitolul 2 ca fiind caracterizata de multimea valorilor
proprietatilor.
Prin urmare tratarea obiectelor active ca si sisteme reactive reprezinta o
abordare naturala. Pentru modelarea comportamentului unui obiect activ pot fi
utilizate formalismele studiate în literatura relativ la modelarea sistemelor reactive. În
ultimii zece ani a fost dezvoltata o multime consistenta de metode de analiza si
proiectare care au utilizat astfel de formalisme în special pentru modelarea aplicatiilor
orientate-obiect secventiale.
Introducerea concurentei însa implica o reconsiderare a semanticii
formalismelor vizuale, în special a celor utilizate pentru descrierea comportamentului
obiectelor. Modelele obiect concurente eficiente din punct de vedere al respectarii
principiilor prezentate în capitolul 2, presupun existenta la nivelul obiectelor active a
unor mecanisme de gestionare a invocarilor de operatii, a unor cozi de asteptare si/sau
a unor porturi de comunicare între obiectele active. Toate aceste caracteristici nu sunt
surprinse în modelele metodelor de analiza si proiectare ale aplicatiilor orientate-
obiect existente.
92

4.3. Harti de stari
Exista diverse abordari de modelare a comportamentului dinamic al obiectelor
(comportament privit prin prisma relatiilor cauzale dintre actiuni). Practic toate
abordarile se bazeaza într-un anumit fel pe masinile cu stari finite, care descriu o
multime de stari în care se poate afla un sistem la un moment dat si tranzitiile posibile
între aceste stari. Pentru fiecare stare, reactiile posibile la intrarile sosite în momentul
în care sistemul se afla în starea respectiva sunt specificate prin intermediul
tranzitiilor spre alte stari. A fost dezvoltat un formalism grafic potrivit pentru
reprezentarea masinilor cu stari finite, numit diagrama de stari. Diagrama de stari
traditionala ofera o imagine clara si intuitiva a acestui comportament.
4.3.1. Structura hartilor de stari
Un element esential al diagramei îl constituie, bineînteles, starea sistemului la
un moment dat, reprezentata grafic cu ajutorul unui dreptunghi cu colturile rotunjite.
Un al doilea element este tranzitia între starile unui sistem. Ea se reprezinta grafic cu
ajutorul unui arc de cerc sau segmente de dreapta orientate si etichetate care leaga
doua stari. Eticheta unei tranzitii este formata dintr-un nume de eveniment urmat
optional de o conditie logica. Semantica tranzitiei dintre starea A si C prezentata în
figura 4.3 este urmatoarea: "daca sistemul se afla în starea A, aparitia unui eveniment
e1 va afea ca efect trecerea sistemului în starea C în cazul în care conditia c1 este
verificata".
Figura 4.3. Exemplu de masina cu trei stari si tre i tranzitii între acestea
a caror declansare depinde de aparitia a doua evenimente
Masinile cu stari finite traditionale produc însa un singur rezultat, si anume
semnalul produs în momentul atingerii starii finale. Exita doua extensii distincte ale
masinilor de stari în functie de modul de tratare a actiunilor:
- modelul Moore, în care actiunile sunt atasate la intrarea într-o noua stare,
- modelul Mealy, în care actiunile sunt asociate tranzitiilor.
93

De notat ca masinile cu stari finite definesc relatiile cauzale dintre evenimente
succesive, ceea ce nu reprezinta acelasi lucru cu descrierea constrângerilor de
sincronizare între actiuni.
Hartile de stari [HAR87] reprezinta o extensie a formalismelor modelelor
Moore si Mealy. Acestea au fost introduse pentru prima data într-un mediu de
programare în 1987 de catre compania israeliana AdCAD în cadrul produsului
STATEMATE. Acest mediu utiliza trei formalisme grafice pentru descrierea unui
sistem: harta de activitati (descrie descompunerea sistemului în unitati functionale si
interfata dintre acestea), harta de module (descrie modulele fizice în care aceste unitati
functionale sunt implementate si canalele de comunicare ce le conecteaza) si harta de
stari (utilizata în descrierea comportamentului unei unitati functionale) [iLO87].
Formalismul hartilor de stari implementat aici a fost adoptat rapid de multe alte
instrumente de modelare, analiza si/sau proiectare de sisteme informatice, suportând o
serie de modificari semantice, extensii sau particularizari. În 1996 David Harel
realizeaza o descriere informala consistenta a formalismului STATEMATE [HAR96].
Din punct de vedere semantic, hartile de stari reprezinta unul dintre cele mai
utile si complete formalisme, ele fiind adoptate în diverse forme si în majoritatea
metodelor de analiza si proiectare orientata-obiect (OMT, Booch, OSE, UML,
OPEN/OML, Syntropy) si utilizate în descrierea comportamentului la nivel de clase.
Ele sunt foarte potrivite în special pentru descrierea comportamentului sistemelor
reactive, desi au existat încercari de dezvoltare a unor tehnici derivate din diagramele
de stari pentru descrierea sistemelor transformationale, cum ar fi proiectarea de
organigrame.
Etichetele tranzitiilor descrise în cadrul hartilor de stari sunt formate din trei
componente optionale distincte:
?? un declansator care determina executarea tranzitiei. Acest declansator este
de fapt un eveniment sau o multime de evenimente care au loc la un
moment dat si care sunt receptionate de sistem,
?? o conditie logica (garda) care specifica cazurile în care tranzitia va fi
realizata atunci când are loc evenimentul din declansator,
?? o actiune care este realizata atunci când tranzitia are loc, si care consta de
fapt în generarea unei multimi de evenimente.
94

Un element important care a fost introdus în hartile de stari si care nu se
regasea în diagramele de stari traditionale este cel de structura. Lipsa unei modalitati
de structurare si de încapsulare a informatiei determina cresterea nejustificata a
dimensiunilor si a complexitatii diagramelor de stari. Hartile de stari însa permit
structurarea diagramelor utilizând stari ierarhice.
Astfel, hartile de stari au extins masinile cu stari finite cu trei noi trasaturi:
adâncime, ortogonalitate si distributie de evenimente (broadcast).
1. Adâncimea. Aceasta trasatura se refera la posibilitatea rafinarii si
ierarhizarii starilor. Astfel, pentru fiecare stare pot fi definite o multime de substari
împreuna cu tranzitii între acestea. Conceptul de adâncime permite gestionarea
complexitatii prin contruirea unei ierarhii de harti de stari încuibarite (figura 4.4). O
stare care contine substari este întâlnita în literatura sub numele de stare compusa,
OR-stare sau stare abstracta, iar un sistem care se afla într-o astfel de stare se va afla
în una si numai una dintre substarile acesteia. Prin urmare o harta de stari poate fi
reprezentata sub forma unui arbore ale carui noduri intermediare sunt reprezentate de
starile compuse, iar nodurile frunza reprezinta starile simple, concrete ale sistemului.
În unele versiuni ale hartilor de stari ierarhizarea este utilizata la eliminarea
nedeterminismului prin stabilirea unor prioritati de declansare a tranzitiilor.
Figura 4.4. Starea D este rafinata în substarile A si B (daca sistemul se afla în starea
D atunci, în mod obligatoriu, el se va afla în una si numai una dintre starile A sau B)
2. Ortogonalitatea. Unul dintre neajunsurile masinilor cu stari finite
conventionale este acela al exploziei exponentiale de stari generate de combinarea
tuturor starilor independente ale unui sistem. Prin utilizarea starilor ortogonale acest
neajuns este înlaturat. Astfel doua componente independente ale sistemului pot fi
modelate împreuna într-o asa numita stare ortogonala (cunoscuta în literatura si sub
denumirea de AND-stare), fiind separate prin intermediul unei linii punctate. Astfel,
un sistem care se afla într-o stare ortogonala, ea se va afla în câte o stare din fiecare
componenta ortogonala a acesteia. Aceasta trasatura ofera posibilitatea combinarii
95

hartilor de stari astfel încât sa poata fi modelata situatia în care un sistem se afla în
doua sau mai multe stari în acelasi timp. Ortogonalitatea reprezinta o alta trasatura de
tratare a complexitatii prin construirea descrierii unui sistem combinând mai multe
harti de stari (figura 4.5).
Figura 4.5. Reprezentarea masinilor de stari ortogonale.
Sistemul aflat în starea D se va afla în câte o stare din fiecare componenta ortogonala
(oricare din combinatzille de stari din {A, B} ? {E, F})
3. Distributia evenimetelor. În general componentele ortogonale nu sunt
complet independente. Este necesara uneori sa se specifice o anumita influenta
mutuala sau o comunicare între acestea. Dupa cum am aratat, în formalismul masinii
Mealy unei tranzitii îi era asociata o anumita iesire (rezultat). Asa cu am aratat,
hartile de stari permit specificarea pentru o tranzitie, alaturi de evenimentele si
conditiile care o declanseaza, a unei multimi de evenimente care au loc ca efect al
declansarii tranzitiei. De asemenea, fiecarei stari îi sunt asociate multimi de
evenimente care au loc atunci când sistemul intra (reprezentate de functia entry()),
respectiv iese (functia exit()) dintr-o stare. Atât evenimentele asociate tranzitiilor cât
si cele corespunzatoare functiilor entry() si exit() sunt transmise întregului sistem.
Aceasta trasatura permite comunicarea între harti de stari ortogonale de obicei
independente. Aceasta proprietate însa întra în conflict cu paradigma orientata-obiect
în care comunicare dintre obiecte este bazata strict pe transmiterea de mesaje punct-
la-punct.
Prin urmare, o harta de stari poate fi descrisa sintetic astfel:
harta de stari = masina cu stari finite + adâncime + ortogonalitate + distributie.
O serie de abordari ale diagramelor de stari permit ca declansatorul unei
tranzitii sa fie format dintr-o propozitie logica de evenimente, si ele poarta numele de
evenimente compuse [BEE94]. De exemplu, un declansator "¬a? b" specifica faptul
96

ca tranzitia etichetata astfel se declanseaza daca are loc evenimentul b si nu are loc
evenimentul a. Utilizarea în descrierea declansatorului a evenimentelor care nu au loc
la un moment dat sunt utilizate de obicei pentru a elimina anumite cazuri de
nedeterminism în hartile de stari (Esterel [BER92]).
Prin urmare, entitatea de observare a unui sistem reactiv este evenimentul.
Mediul transmite evenimente sistemului în scopul realizarii unor calcule, iar sistemul
raspunde la rândul sau generând evenimente înspre mediu. De asemenea,
evenimentele reprezinta elementul de comunicare între diferite parti ale sistemului.
Deoarece se doreste specificarea sistemelor reactive la un nivel de abstractizare ridicat
si într-o maniera discreta, evenimentele sunt întelese ca semnale discrete, care apar la
un anumit moment de timp. Evenimentele nu au durata: ele doar apar la un anumit
moment de timp sau nu apar deloc. Prin urmare, conctructia de program care va
generea evenimente trebuie la rândul sau sa nu aiba durata. Evenimentele sunt
generate la tranzitiile dintr-o stare în alta. Prin urmare aceste tranzitii vor avea un
caracter discret, ne-intreruptibil.
4.3.2. Timp de executie
În anumite abordari toate tranzitiile dintre stari sunt considerate instantanee,
doar stationarea într-o anumita stare având durata. Când se face o rafinare a
specificatiilor, descrierea starii devine mult mai detaliata, însa tranzitiile vor ramâne
instantanee. Aceasta abordare este utila si din punct de vedere al determinarii, în
orice moment de timp, a starii în care se afla sistemul. Deoarece se lucreaza pe un
domeniu discret, momentul de timp de dupa modificare succede imediat momentul
dinaintea modificarii, neexistând perioade de timp între aceste doua momente.
Bineînteles acest lucru este doar o abstractizare a realitatii, însa hartile de stari
reprezinta un limbaj de specificare de nivel înalt pentru care o astfel de abstractizare
este potrivita.
Durata în timp a reactiei sistemului este o alta problema care cunoaste diferite
abordari. Aceasta problema este la rândul sau caracteristica sistemelor reactive,
deoarece în cazul sistemelor tranformationale este relevant doar daca este produs
rezultatul nu si când are loc acest fapt. Pentru sistemele reactive cunoasterea faptului
ca un eveniment a fost sau nu produs nu este suficient. Rectiile pot interfera cu
aparitii de evenimente ulterioare, si prin urmare momentul în care acestea au loc este
97

foarte important. Chiar si în cazul în care timpul nu se cuantifica explicit, este
necesara cunoasterea momentului în care reactia apare relativ la evenimentele din
secventa de intrare (acest element sta de fapt la baza paradoxului Brock-Ackermann
prezentat anterior).
O abordare a acestei probleme este aceea de a specifica pentru fiecare situatie
o cantitate concreta de timp. Aceasta abordare nu este potrivita nivelului de
abstractizare al hartilor de stari, deoarece este dependenta de implementare si forteaza
cuantificarea din start a timpului. O alta abordare consta în fixarea timpului de reactie
la o unitate de timp (pentru un domeniu discret de timp). Acest lucru este simplu, însa
ramâne slab abstractizat, deoarece este dificila rafinarea specificatiilor fara
modificarea întelesului acestora la nivel înalt. În [HUI91] s-a aratat ca problemele
cauzate de o astfel de abordare sunt asemanatoare cu anomaliile tipice limbajelor de
programare de nivel coborât: o modificare locala a mai multor instructiuni afecteaza
comportamentul întregului program (modificare nereprezentând o corectie, ci doar o
rafinare a unei actiuni). De exemplu, o tranzitie etichetata întrebare/raspuns poate fi
rafinata în doua tranzitii etichetate intrebare/consultare si consultare/raspuns. În
acest caz lungimea sintactica a calculului este modificata. Prin urmare un timp de
executie fix pentru entitati sintactice (tranzitii, instructiuni etc) nu este suficient de
flexibil.
Abordarea aceasta are si un alt dezavantaj: impunerea unei durate fixe pentru o
reactie implica, în practica, introducerea de intârzieri explicite artificiale pentru a
corespunde intocmai specificatiilor.
O a treia abordare este aceea de a considera ca executia unei reactii dureaza o
perioada de timp strict pozitiva, urmând a constata durata exacta într-o faza ulterioara.
O astfel de abordare introduce însa nedeterminismul la nivelul hartilor de stari si face
dificila sau chiar imposibila demonstrarea anumitor proprietati în fazele timpurii ale
dezvoltarii.
Prin urmare, din analiza celor trei abordari mentionate, rezulta concluzia ca
timpul de executie al reactiilor trebuie sa fie caraterizate de urmatoarele proprietati:
?? trebuie sa fie precis, însa sa nu depinda de implementare,
?? sa fie cât de scurt posibil, pentru a nu determina întârzieri artificiale,
?? trebuie sa aiba un grad ridicat de abstractizare, astfel încât "cronometrarea"
sa fie ortogonala cu comportamentul functional.
98

Singura solutie care întruneste toate proprietatile de mai sus este sa
consideram ca timpul de reactie este egal cu 0. Aceasta este în esenta ipoteza de
sincronizare denumita astfel de Gerard Berry în [BER92]. Bineînteles ca acest fapt
nu este unul firesc din punct de vedere al implementarii, deoarece orice calcul real
necesita o anumita perioada de timp pentru a fi dus la bun sfârsit, chiar daca aceasta
perioada este extrem de scurta. Aceasta solutie însa are si un alt înteles, si anume
acela ca o reactie are loc înainte de a fi receptionate urmatoarele semnale de intrare.
Prin urmare o reactie nu este considerata a fi "nelimitat" de rapida ci "suficient" de
rapida. Aceasta interpretare nu mai pare nerealista, deoarece în foarte multe cazuri
frecventa evenimentelor externe este mica relativ la timpul de raspuns al sistemului.
Mai mult, chiar si în cazul în care vor apare probleme de implementare, este foarte
posibil ca acestea sa nu influenteze rezultatele proiectantilor si a programatorilor în
primele faze ale dezvoltarii de aplicatii.
4.3.3. Pseudostari
Tot în [HAR87] a fost introdus conceptul de stare initiala (implicita) prin
intermediul careia se este specificata substarea activa în momentul în care sistemul
intra în starea sa parinte (figura 4.6). Reprezentarea grafica a starii initiale este data
printr-un cerc plin. De asemenea, starea initiala poate fi prezenta si la nivelul
diagramei de stari, caz în care se specifica starea în care va intra sistemul în momentul
crearii sale.
Figura 4.6. Specificarea (sub)starilor initiale (în configuratia de mai sus,
intrarea sistemului în starea D va determina implicit activarea substarii A)
Starea initiala este numita si pseudostare (sistemul nu se va afla niciodata în
starea respectiva ci va efectua o tranzitie în plus pentru a intra într-o stare concreta).
Alte pseudostari introduse în timp si utilizate în majoritatea variantelor de harti de
stari sunt starile de iesire si starile istoric. Tranzitia într-o stare de iesire semnifica
încheierea ciclului de viata al sistemului si (în unele abordari) distrugerea acestuia.
99

100
H
a) b) c)
Figura 4.7. Pseudostari de intrare (a), de iesire (b) si istoric (c)
Pseudostarea istoric se poate afla pozitionata doar ca si substare a unei stari
compuse si o tranzitie spre acea stare semnifica intrarea sistemului în ultima substare
activa a starii compuse respective. Notatiile utilizate pentru simbolizarea acestor
pseudostari sunt date în figura 4.7.
4.4. Utilizarea hartilor de stari în modelarea obiectelor active
Desi, asa cum am aratat, diagramele de tranzitie a starilor au fost proiectate
initial pentru modelarea comportamentului sistemelor reactive, ele au fost foarte
natural incluse în cadrul metodelor de modelare vizuala orientate-obiect.
Acceptarea generala a diagramelor de stari pentru modelarea dinamica a
obiectelor din cadrul unei aplicatii s-a datorat în principal urmatoarelor aspecte:
?? diagramele de stari permit descrierea lizibila a comportamentului la un
nivel ridicat de abstractizare,
?? permit efectuarea de verificari la nivel semantic,
?? codul generat din diagramele de stari asigura pastrarea consistentei
obiectelor în timpul executiei sistemului; extinderea diagramelor de stari
cu adnotari formale duce la cresterea semnificativa a procentului de cod
generat pentru aplicatia modelata;
?? permit realizarea de simulari grafice a functionarii sistemului si
încurajeaza prototipizarea,
?? în ceea ce priveste aspectele legate de concurenta, permit o decriere
intuitiva si precisa a sincronizarii mesajelor dintre obiecte.
În cele ce urmeaza sunt prezentate sintetic patru dintre cele mai importante
extensii sau variante ale hartilor de stari utilizate în modelarea obiectelor active:
Objectcharts, OSA, Objchart si diagramele de tranzitie a starilor din UML. Deoarece
UML (v. Anexa B) reprezinta limbajul de modelare care s-a impus ca standard în
analiza si proiectarea orientata-obiect a aplicatiilor, se va insista mai mult asupra sa.
Analiza critica ce însoteste aceasta descriere se constituie într-un argument pentru

econsiderarea hartilor de stari în modelarea obiectelor active si are rolul de a
introduce modificarile semantice care sunt propuse în sectiunea urmatoare. Validarea
aspectelor privind consistenta si executabilitatea variantei de harti de stari propuse
aici se va realiza prin implementarea unui instrument de modelare si simulare a
aplicatiilor orientate-obiect concurente, numit ActiveCASE, si care va fi prezentat în
capitolul 5.
Objectcharts. În [COL92] a fost prezentata o notatie pentru specificarea
comportamentului obiectelor, numita Objectcharts (harti de obiecte). Hartile de
obiecte au la baza hartile de stari descrise de Harel dar nu adopta mecanismul de
distributie a evenimentelor, si integreaza tranzitiile cu invocarea mesajelor (dupa
modelul cerere-raspuns) din modelul orientat obiect. Hartile de obiecte furnizeaza o
notatie grafica la care se aduga detalii prin intermediul specificarilor formale ale
tranzitiilor si ale invariantilor (de stare).
Un aspect interesant privitor la aceste harti de obiecte este ca modelul permite
descrierea comportamentului sistemului prin descrierea interactiunilor dintre obiecte.
O prima restrictie a acestui model este aceea ca numarul de obiecte al sistemului este
fix (nu poate fi adaugat sau distrus nici un obiect în timpul rularii). Alte restrictii sunt
legate de inexistenta specificarii unei modalitati de mostenire a hartilor de obiecte sau
de imposibilitatea transmiterii de mesaje spre alte obiecte în timpul executiei unei
operatii.
OSA. În OSA (Object-oriented Systems Analysis descrisa în [BER94]) pentru
modelarea comportamentului dinamic al sistemelor se foloseste o notatie numita retea
de stari. Retelele de stari reprezinta o extensie a diagramelor de tranzitie a starilor.
Una dintre principalele extensii este aceea ca o tranzitie este formata dintr-o conditie
si o actiune, iar ea va fi declansata doar atunci când conditia asociata ei este
satisfacuta. De asemenea, tranzitia nu este considerata ca fiind atomica, ea fiind
realizata într-o anumita perioada de timp (în care este executata actiunea care îi este
asociata). Modelul permite specializarea retelelor de stari în subclase.
O tranzitie poate avea mai multe stari de pornire si stari tinta. Acest lucru
ofera posibilitatea definirii sincronizarilor (de exemplu, o tranzitie poate avea loc doar
atunci când obiectul se afla în toate starile de pornire). De asemenea poate fi
101

modelata concurenta intra-obiect permitând ca dupa efectuarea unei tranzitii obiectul
sa se afle în mai multe stari din care ulterior pot avea loc independent noi tranzitii.
Modelul ofera posibilitatea tratarii exceptiilor si specificarea de constrângeri de timp-
real.
Modelul OSA are o putere deosebita de analiza, dar din pacate nu este foarte
clar definita modalitatea de tranzitie de la un model de analiza la un model de
proiectare si, eventual, la implementare.
ObjChart. ObjChart reprezinta un set de notatii vizuale pentru descrierea obiectelor si
al comportamentului reactiv al acestora [GAN93]. Aici un sistem este privit ca fiind
format dintr-o colectie de obiecte care comunica asincron si care sunt reprezentate
într-o ierarhie de tip parte-intreg (mostenirea nu este modelata). La rândul sau,
fiecare obiect din sistem detine o masina finita de stari care îi defineste
comportamentul reactiv relativ la mesajele receptionate. Mesajele obtinute de catre
un obiect reprezinta evenimente care declanseaza tranzitii de stari. Fiecare tranzitie
este asociata cu o actiune care transmite unul sau mai multe mesaje asincrone
obiectului însusi sau componentelor sale. Relatiile dintre obiecte pot fi exprimate atât
prin utilizarea de invarianti functionali asupra proprietatilor cât si prin specificarea
dependentelor comportamentale dintre obiecte prin intermediul masinilor cu stari
finite.
Caracteristica ce deosebeste ObjChart de celelalte metode este aceea ca
modelele construite aici sunt executabile, adaugarea unei noi specificatii putând fi
testata imediat. Fiecare obiect contine o singura masina de stari. Desi proprietatea de
ortogonalitate nu este modelata, prevenire cresterii explosive a numarului de stari se
realizeaza prin compunerea obiectelor. Desi comportamentul fiecarui obiect este
controlat (sau modelat) de o masina de stari determinista, orice obiect are un
comportament nedeterminist datorita concurentei interne. Avantajul formalismului
ObjChart este acela ca face referire la o multime minimala de notatii, acestea având o
semantica precisa. Minimalitatea si precizia confera modelelor ObjChar coerenta si
executabilitate.
102

UML (Unified Modeling Language). UML este un limbaj de modelare de generatia
a treia care defineste semanticile metamodelului obiect si furnizeaza o notatie grafica
pentru specificarea structurii si a comportamentului obiectelor.
UML este un limbaj executabil, facând posibila generarea automata de sisteme
executabile pe baza modelelor realizate. Executabilitatea reprezinta o trasatura
importanta a unui limbaj deoarece contribuie la reducerea efortului de translatare a
modelelor abstracte în cod sursa, permite parcurgerea rapida a "distantei" dintre
modelarea unui concept si validarea acestuia si încurajeazeaza explorarea spatiului
solutiilor unei anumite probleme.
În UML diagramele de tranzitie a starilor sunt utilizate pentru modelarea
comportamentului atât a claselor cât si a activitatilor [OMG99], [DOU99]. În cele ce
urmeaza vom considera tratarea acestora numai din perspectiva claselor insistând în
special pe aspectele legate de concurenta. În UML clasele pot fi asociate cu una sau
mai multe diagrame de tranzitie a starilor. În documentatia UML se arata ca în
majoritatea cazurilor va fi suficienta specificarea unei singure masini de stari pentru
descrierea comportamentului unei clase (sau, mai general, al unui element din
modelul intern) fara a se preciza care ar fi cazurile în care este benefica specificarea
mai multor astfel de masini (probabil ca într-o faza timpurie de analiza, când decizia
stabilirii unui anumit model este amânata).
Un eveniment general este descris în UML ca reprezentând specificarea unui
“incident” semnificativ care poate fi localizat în timp si spatiu. Fiecare tranzitie are
asociat un eveniment care o declanseaza. Declansarea unei tranzitii implica
executarea unei anumite operatii definite la nivelul clasei modelate care trateaza
evenimentul receptionat.
Alaturi de pseudostarile de iesire, de intrare si istoric, UML mai introduce alte
trei pseudostari fara semnificatie semantica, având ca rol cresterea lizibilitatii
diagramei: starile ramificatie (branch - pentru reprezentarea a doua sau mai multe
tranzitii dintr-o stare sursa comuna, declansate de acelasi eveniment, dar cu garzi
diferite), fork si join (pentru tranzitii în si din stari aflate în componente ortogonale) -
figura 4.8. De asemenea pseudostarile istoric au doua variante: superficiale si
profunde. Pseudostarile istoric profunde activeaza recursiv ultima substare activata a
ultimei stari compuse active.
103

O stare compusa poate contine cel mult o pseudo-stare istoric (în variantele
sale superficiala si profunda), iar o pseudo-stare istoric poate fi sursa pentru cel mult
o tranzitie. Acelasi lucru este valabil si pentru starea initiala, restrictie impusa de
ideea ca dintr-o stare initiala nu poate pleca decât o singura tranzitie. Acest fapt însa
nu este natural, deoarece astfel nu poate fi permisa modelarea activarii implicite a
unei substari în raport cu o multime de conditii complementare.
Figura 4.8. Pseudostarile ramificatie (a), fork (b) si join (c)
Se considera ca evenimentele sunt stocate într-o coada de asteptare pe masura
ce ele apar. De asemenea se presupune ca exista un gestionar al acestor evenimente.
Acest gestionar asigura faptul ca tratarea unui eveniment de catre o masina de stari va
avea loc dupa ce precedentul eveniment a fost complet tratat. O tratare completa se
refera la modificarea starii obiectului (daca este cazul) si la încheierea executiei
tuturor actiunilor lansate ca efect al tratarii respectivului eveniment (actiuni care fac
parte din secventele entry() si exit() ale starilor, respectiv secventele atasate
tranzitiilor). În cazul unei stari compuse concurente, terminarea tratarii unui
eveniment presupune încheierea tratarii sale în cadrul fiecarei componente concurente
ale acesteia (o altfel de abordare ar duce la complicarea nejustificata a implementarii
unei masini de stari). Acest sistem propus de UML pentru tratarea evenimentelor
contribuie la pastrarea consistentei interne a obiectelor (evenimentul este tratat de
catre un obiect care se afla într-o configuratie stabila, bine definita de stari), însa nu
104

ofera suport pentru modelarea concurentei interne (cazul obiectelor secventiale
concurente!).
În cadrul documentului de specificare al UML apar în mai multe rânduri,
disparat, fraze care sugereaza ca un eveniment poate declansa mai multe tranzitii care
nu se afla în componente concurente! Acest aspect este tratat cu superficialitate,
facându-se referire doar la modalitatea de alegere a tranzitiei care se va declansa
efectiv dintre cele posibile. Astfel, în cazul în care un eveniment poate declansa mai
multe tranzitii în cadrul aceleasi regiuni (secventiale) va fi declansata o singura
tranzitie (cea cu prioritatea cea mai mare, în cazul în care sunt specificate prioritati,
sau este aleasa o tranzitie în mod nedeterminist în caz contrar).
Consideram ca trebuie evitate situatiile nedeterministe în modelarea
comportamentului deoarece este afectata atât întelegerea modelului cât si verificarea
automata a acestuia (din nou facem referire aici la cazul utilizarii unui instrument de
modelare). Prin urmare UML nu impune restrictii de eliminare a nedeterminismului,
asa cum se întâmpla de exemplu în Syntropy [COO94] unde pentru doua tranzitii
plecate din aceeasi stare si declansate de acelasi eveniment se impune ca expresiile
garzilor sa fie complementare. De asemenea se lasa la latitudinea proiectantului ca
reprezentarea unor astfel de tranzitii sa fie facute folosind tranzitii simple sau cu prin
pseudostari de ramificatie. O solutie simpla si în acelasi timp naturala consta în
evitarea trasarii mai multor tranzitii declansate de acelasi eveniment dintr-o anumita
stare prin utilizarea exclusiva pentru acest scop a pseudostarilor ramificatie, ale carei
ramuri vor fi etichetate cu expresii booleene complementare.
Un alt element de noutate introdus este notiunea de tranzitie de completare
(sau terminare). O astfel de tranzitie este neetichetata cu un nume de eveniment
(eventual ea poate avea o garda). Daca în urma tratarii unui anumit eveniment un
obiect se afla într-o configuratie de stari ce permite declansarea de tranzitii de
terminare atunci spunem ca obiectul respectiv a atins o configuratie instabila.
eveniment de terminare
105
tranzitie de terminare
Figura 4.9. Exemplu de utilizare a unei tranzitii de terminare

Tratarea urmatorului eveniment se va realiza în acest caz doar dupa efectuarea
unui numar corespunzator de pasi, pâna când se atinge o configuratie stabila (în
exemplul din figura 4.9 obiectul va atinge o configuratie instabila imediat dupa
tratarea evenimentului e; în aceasta faza se realizeaza un nou pas de trecere a
obiectului în starea C, înainte de tratarea urmatorului eveniment din coada). În cazul
unei proiectari incorecte se poate ajunge în situatia în care nu se atinge niciodata o
configuratie stabila. Pentru a preîntâmpina astfel de situatii UML propune stabilirea
initiala a unui numar maxim de pasi care sa poata fi efectuati dupa încheierea tratarii
unui eveniment. La interpretarea urmatorului eveniment, componenta instabila nu va
participa.
Figura 4.10. Activarea starilor în cazul unei tranzitii (e1) în cadrul unei stari compuse (B)
a) intrare implicita – C va fi starea activa, b) intrare explicita – stare activa D
c) intrare prin istoric – daca se intra pentru prima data în B de la crearea obiectului
starea activa va fi C, altfel stare activa este ultima sub-stare activa a starii B (C sau D)
Asa cum am vazut într-una din subsectiunile anterioare, starile pot fi active sau
inactive. O stare devine activata în urma declansarii unei tranzitii a carei destinatie
este respectiva stare. În cazul starilor compuse, daca acestea nu sunt concurente
106

atunci o sigura substare a sa poate fi activa la un moment dat. În cazul concurentei
vor fi active toate subregiunile starii compuse.
În diagramele de stari din UML exista trei modalitati prin care o sub-stare
devine activa în cazul unei tranzitii într-o stare compusa: implicit, explicit si prin
intermediul pseudostarii istoric. În figura 4.10 sunt reprezentate grafic toate aceste
cazuri, cu remarca suplimentara ca în cazul în care sub-starile sunt la rândul lor stari
compuse, activarea se va face analog recursiv. Indiferent de modalitatea în care se
realizeaza tranzitia în cadrul unei stari compuse se va executa secventa de actiuni
entry() specificata pentru aceasta stare. Un caz deosebit este cel în care starea
compusa contine mai multe componente concurente (ortogonale). În acest caz se va
utiliza o tranzitie complexa cu ajutorul pseudostarii fork, si fiecare regiune
(componenta) concurenta în care va intra o astfel de tranzitie va activa o substare a sa
dupa modelul starilor compuse prezentat anterior. Pentru regiunile în care nu intra
nici o tranzitie se va activa starea implicita (care este destinatie a unei tranzitii
initiale).
Se defineste tranzitia de terminare ca fiind o tranzitie a carei sursa este o stare
simpla sau stare compusa si care este neetichetata. O astfel de tranzitie este activata
atunci când starea sursa a atins o stare finala. De asemenea, se defineste termenul de
tranzitie de nivel înalt ca fiind acea tranzitie a carei sursa este o stare compusa.
neetichetate:
Sun mai multe cazuri distincte în care putem avea într-un model tranzitii
- tranzitii din stari initiale care nu apartin starii compuse de la nivelul unu
(optional poate apare ca eticheta o expresie booleana),
- tranzitii de terminare,
- tranzitii spre stari finale aflate în cadrul starii compuse de nivel unu care
sugereaza simpla distrugere a obiectului prin apelul destructorului
(optional – pot apare ca etichete nume de evenimente care determina
distrugerea obiectului),
- tranzitii care ies din pseudostarile istoric si fork si care intra în
pseudostarea join.
Iesirea din cadrul unei stari compuse este tratata foarte pe scurt în
documentatia UML, neinsistându-se prea mult cu explicatii pe marginea tranzitiilor de
terminare.
107

Fiecare subregiune a unei stari compuse concurente poate avea stari initiale si
stari finale. O tranzitie spre o stare compusa este echivalenta cu o tranzitie spre starea
de intrarea a starii compuse. O tranzitie spre o stare finala reprezinta încheierea
activitatii în regiunea parinte, iar încheierea activitatii tuturor regiunilor concurente
semnifica încheierea activitatii în starea compusa parinte si declanseaza un
"eveniment de încheiere a activitatii" spre aceasta. Aparitia unui astfel de eveniment
în cadrul starii compuse de la nivelul cel mai exterior reprezinta distrugerea obiectului
(apelarea destructorului acestuia).
UML permite realizarea tranzitiilor între regiuni concurente fara însa a se
explica sensul unei astfel de reprezentari. Foarte probabil ca astfel de tranzitii nu îsi
au sensul si sunt inconsistente cu faptul ca un sistem aflat într-o stare compusa cu mai
multe regiuni ortogonale se va afla de fapt în câte o stare din cadrul fiecarei
componente ortogonale.
În momentul creerii unui obiect se realizeaza o tranzitie din starea initiala a
starii compuse de la nivelul cel mai de sus. Rafinarea unei stari în substari concurente
se realizeaza prin împartirea starii în mai multe subregiuni care pot avea, optional,
nume.
În [OMG99] se specifica faptul ca un eveniment care nu declanseaza nici o
tranzitie este ignorat. Acest lucru conduce la presupunerea implicita (nu se face nici o
precizare explicita în acest sens) ca în cadrul unei diagrame de stari vor fi trasate
tranzitii pentru toate evenimentele posibile. O astfel de abordare este incomoda
deoarece reprezentarea grafica a tranzitiilor declansate de apelul unui observator de
exemplu, conduce la încarcarea nejustificata a diagramei de stari cu câte o
autotranzitie pentru fiecare stare..
O alta întrebare care nu îsi gaseste raspunsul în documentele UML este “Ce se
întâmpla atunci când apare un eveniment al carei nume se afla în eticheta a cel putin
unei tranzitii din diagrama dar nici una dintre acestea nu poate fi declansata?” Este
acest eveniment retinut, într-o coada de asteptare, în vederea unei tratari ulterioare sau
este ignorat?
În alta ordine de idei unei tranzitii îi este asociata o secventa de actiuni care se
executa în momentul declansarii tranzitiei respective. Poate aparea însa urmatoarea
problema în cazul claselor secventiale: ce se întâmpla atunci când exista o tranzitie
declansata de un eveniment de apelare al unei metode cu garda, iar conditia asociata
108

acesteia se verifica însa garda metodei nu? Specificatiile date de UML pot duce la
mai multe raspunsuri, unele dintre ele contradictorii. Spre exemplu ar putea exista
posibilitatea ca tranzitia sa se efectueze, sa fie executata secventa de actiuni însa
executia metodei cu garda sa nu se realizeze. În acest caz exista din nou doua
alternative: evenimentul de apel de operatie este repus în coada de evenimente sau nu.
Aceste ambiguitati sunt generate în mare parte de efortul creatorilor UML de a
nu intra în prea multe detalii si de a nu impune constrângeri si restrictii care ar putea
sa reduca din flexibilitatea modelului (în unele cazuri chiar este precizat faptul ca
anumite elemente sunt lasate intentionat la latitudinea proiectantului). Din pacate
acest fapt, la care se adauga si absenta unei bune sistematizari a informatiilor (de
exemplu sunt descrise aspecte semantice la prezentarea notatiei), conduc în multe
cazuri la abordari gresite de modelare.
4.5. Harti de stari scalabile
4.5.1. Modelul obiect
În cadrul acestei sectiuni vom defini o extensie a hartilor de stari pentru
modelarea comportamentului obiectelor active corespunzatoare modelelor obiect
omogene. Asa cum am aratat în capitolul 2, obiectele active din aceasta categorie
detin, alaturi de proprietati si operatii, un mecanism de coordonare si planificare a
mesajelor receptionate. Acest mecanism are rolul de a proteja consistenta starii
interne a obiectelor de accesul concurent al operatiilor la proprietatile acestora.
Protectia se realizeaza implicit, în cazul mecanismelor cu control extern (mecansime
de tip monitor) sau explicit, prin intermediul constrângerilor de sincronizare, în cazul
mecanismelor cu control mixt sau reflectiv (metode cu garzi, abstractizarea
comportamentului, multimi de operatii acceptabile etc).
109

gestionar de
interfata
.
.
.
110
Obiect activ
Proprietati
Operatii
Constrângeri de
sincronizare
coada de mesaje
Figura 4.11. Structura unui obiect activ general
În figura 4.11 am reprezentat grafic structura unui obiect activ. Gestionarul de
interfata reprezinta o entitate speciala situata la nivelul fiecarui obiect activ. Aceasta
entitate realizeaza controlul si planificarea mesajelor receptionate si se concretizeaza
la nivelul unui limbaj de programare particular printr-un fir de executie distinct, un
mecanism de blocare sau un obiect de sine statator încapsulat în cadrul obiectelor
active. Gestionarul de interfata controleaza tratarea mesajelor prin executia asincrona
a operatiilor asociate acestora pe baza valorilor proprietatilor (care definesc starea
obiectului), a constrângerilor de sincronizare si/sau a operatiilor aflate în executie la
un moment dat. Planificarea mesajelor este realizata cu ajutorul unei structuri
speciale, numita coada de mesaje, care retine toate mesajele receptionate si netratate
de catre gestionar. Gestionarul de interfata, coada de mesaje, proprietatile si
contrângerile de sincronizare nu sunt vizibile în exterior, de catre celelealte obiecte
active care compun un sistem. De asemenea, doar un subset de operatii care compun
interfata obiectului activ vor fi vizibile, si ele pot fi apelate prin intermediul
transmiterii de mesaje.
Vom considera ca toate elementele care fac parte din structura unui obiect
activ vor putea fi mostenite sau redefinite separat în subclase.
Modelul obiect general descris respecta cele patru principii de proiectare
enuntate în capitolul doi.

4.5.2. Definirea hartilor de stari scalabile
Vom defini hartile de stari scalabile într-o maniera incrementala, pornind de la
masini de stari (pe care le vom numi harti de stari scalabile de grad 0) si adaugând
elemente corespunzatoare tratarii notiunilor de adâncime, ortogonalitate, istoric etc.
Pentru fiecare dintre hartile de stari intermediare vom defini notiunile de configuratie
si executie. Abordarea de definire va fi una compozitionala, în care executia unei
harti de stari va reprezenta o compunere a executiei componentelor sale.
Hartile de stari scalabile reprezinta o abordare originala de modelare a
obiectelor active, si are la baza modelarea utilizata în teoria automatelor [MOL97].
Ele sunt strâns legate de notiuni ca mesaj, operatie, proprietate sau constrângere de
sincronizare proprii programarii orientate-obiect concurente. De aceea hartile de stari
scalabile sunt o specializare într-un context orientat-obiect a hartilor de stari utilizate
în modelarea sistemelor reactive si, în acelasi timp, extind hartile de stari UML cu
elemente specifice modelul omogen de obiecte prezentat în subsectiunea 4.5.1.
Harti de stari scalabile de grad 0 (HSS 0 )
unde:
Definitie 1. Definim hartile de stari scalabile de grad 0 ca fiind tuplul:
HSS 0 = (M, S, s0, SF, T; sa, C),
- M reprezinta o multime finita de mesaje. Vom considera, fara a restrânge
din generalitate, ca signaturile mesajelor nu contin parametrii.
Generalizarea unei harti de stari luând în considerare parametrii de mesaje
este imediata, si nu afecteaza semantica executiei. Vom nota cu ? mesajul
vid.
- S - multime finita, nevida de stari,
- s0 ? S - starea initiala,
- SF – multime finita de stari finale. Aceasta poate fi vida, caz în care
obiectele modelate nu se vor putea autodistruge,
- T ? S ? M ? (S ? SF) – multime finita de tranzitii. O tranzitie (s’, m, s’’)
? T semnifica faptul ca, în cazul în care un obiect se afla în starea sursa s’
si receptioneaza mesajul m atunci, dupa tratarea mesajului m (dupa
terminarea executiei operatiei atasate) obiectul se va afla în starea
destinatie s’’.
111

- sa ? S - starea activa a hartii de stari la un moment dat,
- C ? M*– secventa finita de mesaje care modeleaza coada de mesaje a unui
obiect activ. Vom nota cu m0^Cr secventa finita de mesaje C unde m0
reprezinta primul mesaj al secventei, iar Cr restul secventei (simbolul ^
reprezinta operatia de concatenare). Acesta va apartine multimii de mesaje
M sau va fi mesajul vid, în cazul în care C este o secventa de 0 mesaje.
În figura 4.12 este prezentat un exemplu de masina de stari HSS 0 împreuna cu
reprezentarea sa vizuala, care modeleaza comportamentul obiectelor unei clase
particulare, numita Sticla.
specificare vizuala
a starii initiale
HSS 0
Sticla = (M, S, T, s0, SF; C)
M = { Umple, Goleste, Sparge, Capacitate}
S = { Goala, Plina}
T = {(Goala, Umple, Plina),
(Goala, Sparge, F),
(Plina, Goleste, Goala),
(Plina, Sparge, F)}
s0 = Goala
S F = { F }
112
tranzitie
stare
F - stare finala
Figura 4.12. Reprezentarea grafica a hartilor de stari HSS 0
Primele 5 elemente ale hartii de stari HSS 0 reprezinta componenta statica a
acesteia si ele descriu structura hartii de stari. Pentru toate obiectele clasei pentru
care s-a definit o harta de stari HSS 0 particulara, aceste 5 elemente sunt comune, iar
ele nu se modifica în timpul executiei obiectelor. Componenta dinamica este formata
din coada de mesaje C. Coada de mesaje nu caracterizeaza comportamentul
obiectelor unei clase, ea fiind însa utilizata în executia acestora.
Un obiect activ se poate afla la un moment dat în una si numai una din starile
multimii S într-o harta de stari HSS 0 .
Definitie 2. Vom numi configuratie a hartii de stari HSS 0 tuplul:

(sa, m0^Cr) ? S ? M*,
unde sa reprezinta starea activa iar m0 primul mesaj aflat în coada C la un moment dat.
Configuratie initiala a unei harti de stari este data de tuplul (s0, ? ).
Executia unui obiect activ modelat printr-o harta de stari HSS 0 presupune
interpretarea succesiva a mesajelor existente în coada de mesaje. Interpretarea unui
mesaj poate avea ca efect modificarea configuratiei hartii de stari sau returnarea
mesajului în coada de mesaje. Vom defini în cele ce urmeaza notiunile de
interpretare a unei configuratii, respectiv executie a unei harti de stari HSS 0 .
functia:
Definitie 3. Se numeste interpretare a configuratiei unei harti de stari HSS 0
? 0 : S ? M* ? S? SF ? M*,
? 0 ? ( s',
C'r
), daca ? ( sa
, m0,
s')
? T
?
(sa,m0^Cr) = ? ( sa
, C'r
), daca ? s1,
s2
? S : ( s1,
m0,
s2
) ? T .
? ( sa
, C'r
^m0),
in rest
Coada de mesaje C poate suferi modificari în paralel cu interpretarea unei
configuratii, astfel ca în definitia functiei ? data mai sus este posibil ca Cr ? C’r (de
obicei C’r = Cr^R, unde R ? M* reprezinta o secventa de mesaje receptionate de catre
obiect în timpul interpretarii).
Notiunea de interpretare a configuratiei modeleaza functionalitatea
gestionarului de interfata din cadrul unui obiect activ. Astfel, un mesaj este acceptat,
iar operatia atasata acestuia este executata, în cazul în care mesajul eticheteaza o
tranzitie ce pleaca din starea activa sau daca acesta nu apare în eticheta nici unei
tranzitii a hartii de stari. În caz contrar mesajul este reintrodus în coada de mesaje. În
cazul în care în cadrul hartii de stari exista mai multe tranzitii etichetate cu acelasi
mesaj si a caror stare sursa coincide cu starea activa, alegerea unei tranzitii pentru
interpretare se realizeaza într-o maniera nedeterminista. Pentru eliminarea
nedeterminismului se pot atasa tranzitiilor prioritati.
Definitia 4. Se numeste executie a unei harti de stari HSS 0 o secventa finita
sau infinita de interpretari succesive a configuratiei hartii de stari, pornind de la
configuratia initiala a acesteia, si o vom nota:
(s0, ? ) ? ? ?
? 0
(s1, m1^Cr1) ? ? ?
? 0
113
... ? ? ?
? 0
(sk, mk^Crk) ? ? ?
? 0
... ,

unde s0, s1, ..., sk,.. ? S, m1, ..., mk,... ? M si Cr1,..., Crk,... ? M*. Executia este finita daca
starea activa devine o stare finala.
urmatoarea:
O executie posibila a unui obiect al clasei Sticla, definita în figura 4.12, este
(Goala, ? ) ? ? ?
? 0
(Goala, ) ? ? ?
? 0
(Plina, ) ? ? ?
? 0
(Plina, ) ? ? ?
? 0
(Plina, ) ? ? ?
? 0
114
(F, ).
Coada de mesaje C surprinsa în definitia hartii de stari HSS 0 reprezinta un caz
particular, ales pentru reducerea complexitatii descrierii interpretarii si executiei
hartilor de stari. Cazurile generale în care mecanismele de coordonare si sincronizare
a concurentei permit atasarea de prioritati mesajelor, sau care au politici diferite de
alegere a mesajelor tratabile, pot fi modelate înlocuind coada de mesaje C cu perechea
(C’, pol), unde C’ ? M* iar pol este o functie pol : M* ? M care caracterizeaza
politica de alegere a unui mesaj din multimea mesajelor receptionate, modelata de C’.
În acest caz vom înlocui în expresiile anterioare care definesc configuratia si executia
hartii de stari HSS 0 mesajul m0 cu pol(C’).
Harti de stari scalabile de grad 1 (HSS 1 )
Vom atasa hartilor de stari HSS 0 proprietatile de adâncime si ortogonalitate,
introduse în [HAR87]. Deoarece un obiect se va putea afla în mai multe stari simple
la un moment dat, stari care se afla în componente ortogonale distincte ale unei stari
compuse, se vor modifica si definitiile configuratiei, a functiei de interpretare a
configuratiei si a executiei.
Notiunile de adâncime si ortogonalitate sunt modelate în HSS 1 prin
intermediul unui arbore eterogen, al carui radacina este o stare iar nivelele
intermediare de ordin impar sunt ocupate de stari, iar cele de grad par de componente
ortogonale (figura 4.13). Vom considera ca fiecare stare are cel putin o componenta
ortogonala, iar fiecare componenta ortogonala are zero sau sau mai multe sub-stari.
Cele trei tipuri de stari introduse în [HAR87] vor pute fi modelate în mod unitar
astfel:

unde:
- o stare simpla este o stare care are o singura componenta ortogonala,
iar aceasta este vida.
- starea compusa (XOR – stare) are o singura componenta ortogonala,
nevida.
- starea ortogonala (AND-stare) are mai multe componente ortogonale
nevide.
Definitie 5. Definim hartile de stari scalabile de grad 1 ca fiind tuplul:
HSS 1 = (M, S, O, sR, SF, (stSucc, stInit, ortSucc), T; Sa, C),
- M este o multime finita de mesaje care pot fi receptionate de catre
obiectele clasei modelate de harta de stari,
- S este multimea finita a starilor,
- O este o multime finita de componente ortogonale,
- sR ? S este starea radacina a ierarhiei de stari,
- SF – multimea finita a starilor finale. Penru a pastra consistenta modelului
vom impune ca toate starile finale sa se afle în componente ortogonale ale
starii radacina sR, adica ? sf ? SF, stPred(ortPred(sf)) = sR. Vom elimina
astfel tranzitiile de terminare specificate în UML, fara însa a restrânge
puterea de modelare a hartilor de stari.
- functii de definire a ierarhiei de stari si componente ortogonale:
- stSucc : O ? ? (S? SF), unde stSucc(o) = {s1, s2, ... , sn} reprezinta
multimea substarilor componentei ortogonale o, cu restrictia ca ? o1,
o2 ? O vom avea stSucc(o1) ? stSucc(o2) = ? ;
- stInit : O\{o : stSucc(o)=? } ? S, stInit(o) = s0 ? stSucc(o), sub-
starea initiala a componentei ortogonale o (functia se aplica doar
pentru componentele ortogonale nevide);
- ortSucc : S ? ? (O) \ {? }, unde ortSucc(s) = {o1, o2, ... , om}
reprezinta multimea componentelor ortogonale ale starii s, cu
restrictia ca ? s1, s2 ? S vom avea ortSucc(s1) ? ortSucc(s2) = ? (o
stare are cel putin o componenta ortogonala);
- T ? ? (S\{sR}) ? M ? ? (S\{sR}) multime finita de tranzitii. O tranzitie
({s1’, ..., si’}, m, { s1’’, ..., sj’’}) ? T semnifica faptul ca, în cazul în care un
115

obiect se afla în starile sursa s1’, ..., si’ ? S\{sR} (fiecare dintre acestea
aflate în componentele ortogonale distincte ale unei stari) si receptioneaza
mesajul m atunci, dupa tratarea mesajului m obiectul se va afla în starile
destinatie s1’’, ..., sj’’ ? S\{sR} (la rândul lor apartinând unui numar j de
componente ortogonale distincte ale unei stari). Starea radacina nu poate
fi nici sursa nici destinatie a unei tranzitii, iar multimea starilor sursa si
multimea starilor destinatie nu contin stari care sa se includa.
- Sa ? S? SF - multimea starilor active ale hartii de stari la un moment dat,
care are proprietatea ca ? sa ? Sa, ortSucc(sa) = ? .
- C ? M*– secventa finita de mesaje care modeleaza coada de mesaje a unui
obiect activ.
HSS 1
Sticla = (M, S, O, sR, SF, (stSucc, stInit, ortSucc ), T; C)
M = { Umple, Goleste, Sparge, Capacitate}
S = { Sticla, Normal, Goala, Plina}
O = { o1, o2, o3, o4 }
s R = Sticla
S F = { F }
116
starea initiala
pentru o1
starea initiala
pentru o2
o2
o1
o3 o4
stSucc : { o1, o2, o3, o4 } ? ? ({ Sticla, Normal, Goala, Plina, F}),
stSucc(o1) = {Normal, F}, stSucc(o2) = {Goala, Plina},
stSucc(o 3) = ? , stSucc (o 4) =? ;
stInit : { o1, o2 } ? { Sticla, Normal, Goala, Plina},
stInit(o1) = Normal, stInit(o2) = Goala,
ortSucc : { Sticla, Normal, Goala, Plina } ? ? ({ o1, o2, o3, o4 }) \ {? },
ortSucc (Sticla) = {o1 }, ortSucc (Normal) = {o2 },
ortSucc (Goala) = {o3 }, ortSucc (Plina) = {o4 },
T = {({Goala}, Umple , {Plina}), ({Plina}, Goleste, {Goala}),
({Normal}, Sparge, {F}) }
Figura 4.13. Reprezentarea grafica a hartilor de stari HSS 1
Pe baza functiilor stSucc si ortSucc putem defini alte doua functii care
determina parintii directi ai unei stari sau componente ortogonale.

Definitie 6. Fie stPred : O ? S , unde stPred(o) = s ? S daca o ? ortSucc(s) si
reprezinta reprezinta starea parinte a componentei ortogonale o ? O. De asemenea,
definim functia ortPred : S? SF \{sR} ? O, unde pentru o stare s ? S? SF \{sR},
ortPred(s) = o ? O daca s ? stSucc(o), si reprezinta componenta ortogonala în care
este inclusa starea s.
Faptul ca multimile rezultat ale functiilor stSucc si ortSucc sunt disjuncte doua
câte doua, asa cum se specifica în definitia 5, asigura faptul ca functiile stPred si
ortPred sunt bine definite.
Deoarece descrierea unei tranzitii în cadrul definitiei hartii de stari HSS 1 este
realizata într-o maniera informala, în cele ce urmeaza vom specifica formal conceptul
de tranzitie valida. Pentru a realiza acest lucru vom defini relatia de încuibarire dinte
starile si componentele ortogonale ale unei harti de stari.
Definitie 7. Doua elemente so1, so2 ? S? O se afla în relatia de încuibarire,
notata prin so1 so2, daca si numai daca una din afirmatiile urmatoare este adevarata:
a) so1=so2,
b) so1 ? S ? so2? S ? ? n ?
c) so1 ? O ? so2? O ? ? n ?
+
a. î. so2
st Pr ed ( ort Pr ed (... so1...))
117
? ,
n
+
a. î. so2
ort Pr ed ( st Pr ed (... so1...))
n
ori
? ,
d) so1 ? S ? so2? O ? ? n ? a. î. so ? ort ed(
st Pr ed(...
ort Pred
( so )...)) ,
2
ori
Pr 1
e) so1 ? O ? so2? S ? ? n ? a. î. so ? st ed ( ort Pr ed (... st Pred
( so )...)) .
încuibaririi.
so
2
2
n ori
Pr 1
Propozitie 1. Relatia de încuibarire este ordine partiala peste multimea S? O.
Demonstratie. Reflexivitatea este asigurata de conditia a) a definitiei
Fie so1, so2, so3 ? S, si so1 so2 si so2 so3. Rezulta ca ? n ?
? st ed ( ort Pr ed (... so ...)) si ? m ?
Pr 1
n
ori
Prin urmare ? r= n + m ?
n ori
+ a. î.
+
a. î. so3
st Pr ed(
ort Pred
(... so2...))
? .
m ori
+
, a.î. so3
st Pr ed(
ort Pred
(... so1...))
adica relatie de încuibarire este tranzitiva peste S.
? , deci so1 so3,
r ? m?
n ori

În mode analog se demonstreaza tranzitivitatea si în celelalte sapte cazuri în
care so1, so2, so3 sunt fie stari fie componente ortogonale.
Vom demonstra în continuare faptul ca relatia de încuibarire este antisimetrica
pentru so1, so2 ? S.
Vom presupunem asadar ca so1 so2 si so2 so1. Acest lucru implica faptul
ca so1 = so2 sau ? n, m ?
so
2
+ a. î.:
? st ed ( ort Pr ed (... so ...)) si so ? st ed ( ort Pred
(... so ...)) .
Pr 1
n
ori
118
1
Pr 2
m ori
Vom presupune ca so1 ? so2. Prin urmare ? r= n + m ?
so
1
? st ed ( ort Pr ed (... so ..)) .
Pr 1
r ori
+ a. î.:
Din definitia hartii de stari HSS 1 rezulta ca egalitatea anterioara are loc doar în
cazul în care r=0. Am presupus însa ca r ?
+ . Rezulta ca
so1 so2 ? so2 so1 ? so1 = so2.
Deci relatia de încuibarire este antisimetrica peste multimea S. Pentru celelalte
trei cazuri (so1, so2 ? O, so1 ? O si so2 ? S, so1 ? S si so2 ? O) demonstratia se
realizeaza în mod analog. Prin urmare relatia (S? O, ) este reflexiva, tranzitiva si
antisimetrica, deci este o relatie de ordine partiala. ?
Definitie 8. Pentru o stare sau componenta ortogonala so ? S? O se defineste
multimea tuturor predecesorilor sai ca fiind:
PREDso = { so' : so' ? S? O , so so' }.
Propozitie 2. Oricare ar fi so ? S? O, (PREDso, ) este ordine totala.
Demonstratie. Conform propozitiei 1, relatia (PREDso, ) este ordine
partiala. Fie so', so'' ? PREDso ? S. Rezulta, conform definitiei multimii
succesorilor, ca:
? n' ?
? n'' ?
+ a. î. ...))
so'
? st Pr ed(
ord Pr ed(...
so si
n'
ori
+
a. î. so''
st Pr ed ( ort Pr ed(...
so...))
? .
n''
ori
Vom presupune în continuare ca n' > n''. Rezulta ca :
? n'' ?
+
a. î. so''
st Pr ed ( ort Pr ed(...
so'...))
? ,
n '?
n''
ori

si deci so' so''. În mod analog se demonstreaza existenta relatiei de încuibarire si
între celelalte trei posibile tipuri de perechi de elemente ale multimii PREDso.
Prin urmare ? so', so'' ? PREDso so' so'' sau so'' so' , deci relatia de
încuibarire peste multimea PREDso este ordine totala. ?
Deoarece (PREDso, ) este ordine totala, iar multimea PREDso este finita,
rezulta ca exista o cea mai mare limita inferioara pentru PREDso si aceasta apartine lui
PREDso. Vom nota aceasta limita inferioara prin pPREDso. Vom demonstra în
continuare ca pPREDso reprezinta parintele direct al elementului so.
Propozitie 3. Fie so ? S? O. Este adevarata una din urmatoare afirmatii:
a) so ? S ? ortPred(so) = p PREDso,
b) so ? O ? stPred(so) = p PREDso.
Demonstratie. a) Fie so ? S. Este evident faptul ca so ortPred(so), iar pe
baza definitiei multimii PREDso vom avea ca ortPred(so) ? PREDso.
Fie un element oarecare so' ? PREDso. Din definitia 8 avem ca so so'.
Daca so' reprezinta o componenta ortogonala, atunci ? n ? a. î.
so'
? ort Pr ed ( st Pr ed (... ort Pr ed(
so)...))
,
n ori
de unde rezulta ca ortPred(so) so'. În mod analog se demonstreaza ca are loc
relatia de încuibarire între ortPred(so) si so' pentru cazul în care so' este o stare.
Deoarece so' a fost un element al multimii PREDso ales aleator, rezulta ca
Rezulta ca ortPred(so) = p PREDso.
? so' ? PREDso , ortPred(so) so'.
Afirmatia b) se demonstreaza în mod analog. ?
Definitie 9. Fie doua stari sau componente ortogonale so', so'' ? S. Spunem
ca so' si so'' sunt ortogonale daca ele nu se afla în relatia de încuibarire si
p (PREDso' ? PREDso'') ? S.
Cu alte cuvinte, doua sau mai multe stari sunt ortogonale daca ele nu se contin
reciproc si cel mai apropiat parinte comun este o stare.
Definitie 10. Fie t = ({s'i ? S : i = 1..n}, m, {s''j ? S : j = 1..m}) ? T o tranzitie.
Tranzitia t este valida daca sunt adevarate urmatoarele afirmatii:
119

a) Ps' = p
b) Ps'' = p
i?
n
1
j?
m
1
PRED ? S, (starile sursa sunt ortogonale),
s'i PRED ? S, (starile destinatie sunt ortogonale),
s''j
c) Ps' si Ps'' nu se includ reciproc si p (PREDPs' ? PREDPs'') ? O. (starile
sursa si starile destinatie nu sunt ortogonale).
Vom numi domt = p (PREDPs' ? PREDPs'') ? O domeniul tranzitiei t.
Prin urmare domeniul unei tranzitii reprezinta cea mai mica componenta
ortogonala care contine toate starile sursa si destinatie ale acesteia.
Pentru exemplul ilustrat în figura 4.13, un obiect al clasei Sticla care se afla în
starea Plina, se afla în acelasi timp, conform ierarhiei construite, si în starile Normal
si Sticla. Prin urmare, conform definitiei 2 toate aceste stari reprezinta stari active ale
hartii de stari. Pentru a putea defini în mod unic configuratia unei harti de stari HSS 1
la un moment dat vom extinde notiunea de stare activa luând în considerare notiunile
de adâncime si ortogonalitate.
Asa cu rezulta din defintia 5, o stare activa a hartii de stari HSS 1 reprezinta o
stare în care se poate afla un obiect la un moment dat, si care are proprietatea ca este
stare simpla (cu o singura componenta ortogonala vida). Conform definitiei 5, pentru
exemplul din figura 4.13 singurele stari care pot fi stari active pentru un obiect al
clasei Sticla sunt Goala, Plina si F.
Definitie 11. Numim stare pseudo-activa o stare compusa care contine o sub-
stare activa. Vom nota cu Spa multimea tuturor starilor pseudo-active ale unui obiect
modelat printr-o harta de stari HSS 1 .
O harta de stari HSS 1 poate avea mai multe stari active, fiecare dintre acestea
aflate în componente ortogonale distincte ale unei stari pseudo-active. În mod evident
starea radacina sR este stare pseudo-activa pe toata perioada ciclului de viata al unui
obiect.
Intrarea unui obiect într-o stare compusa va determina activarea substarilor
initiale ale acesteia. Vom defini în continuare o functie recursiva care va fi utilizata în
determinarea starilor ce se vor activa la intrarea într-o stare compusa.
120

Definitie 12. Vom numi functie de activare functia care va asocia fiecarei stari
s multimea sub-starilor simple sau finale ale acesteia care se vor activa implicit în
momentul în care un obiect va intra în starea s. Vom nota aceasta functie:
activ : S ? SF ? ? (S ? SF),
? { s},
daca(
s ? S,
ortSucc(
s)
? { o},
stSucc(
o)
? ? ) sau s ? SF
?
activ ( s)
? ? activ(
stInit(
o)),
in rest
.
? o?
ortSucc(
s)
Vom defini de asemenea functia de activare globala, Activ : ? (S ? SF) ? ? (S ? SF)
Activ(S') =
s?
S'
activ(
s)
.
Definiti 13. Numim configuratie a unei harti de stari HSS 1 tuplul ( Sa, m0^Cr),
unde Sa ? S reprezinta multimea starilor active, iar m0^Cr ? M* reprezinta continutul
cozii de mesaje C la un moment dat. Configuratia initiala a unei harti de stari este
(active(sR), ? ).
functia:
Definitie 14. Se numeste interpretare a configuratiei unei harti de stari HSS 1
? 1 : ? (S) ? M* ? ? (S? SF) ? M*,
? 1 ? ( Activ(
S''
), C'
r ), daca ( S',
m0,
S'
')
? T si S'?
?
(Sa,m0^Cr) = ? ( S a,
C'r
), daca ? S1,
S2
? S : ( S1,
m0,
S2
) ? T
? ( Sa
, C'
r ^m0),
in rest
Definitia 15. Se numeste executie a unei harti de stari HSS 1 o secventa finita
sau infinita de interpretari succesive a configuratiei hartii de stari, pornind de la
configuratia initiala a acesteia, si o vom nota:
(active(sR), ? ) ? ? ?
? 1
(S1, m1^Cr1) ? ? ?
? 1
121
... ? ? ?
? 1
S
a
?
(Sk, mk^Crk) ? ? ?
? 1
unde S1, ..., Sk,.. ? S, m1, ..., mk,... ? M si Cr1,..., Crk,... ? M*. Executia este finita daca
multimea starilor active detine o stare finala.
urmatoarea:
O executie posibila a unui obiect al clasei Sticla, definita în figura 4.13, este
({Goala}, ? ) ? ? ?
? 1
({Goala}, ) ? ? ?
? 1
({Goala}, ) ? ? ?
? 1
({Plina}, ) ? ? ?
? 1
S
pa
.
... ,

({Plina}, ) ? ? ?
? 1
({F},? ).
Harti de stari scalabile de grad 2 (HSS 2 )
122
({Goala},) ? ? ?
? 1
Hartile de stari HSS 1 nu permit declansarea în paralel a mai multor tranzitii.
Prin urmare hartile HSS 1 nu pot fi utilizate în modelarea concurentei interne a
obiectelor active. De asemenea, hartile de stari scalabile de grad 1 nu permit
modelarea sincronizarilor conditionale sau a constrângerilor de sincronizare.
Vom extinde în cele ce urmeaza hartile de stari HSS 1 cu noi elemente care sa
permita specificarea invariantilor pentru stari, a conditiilor de declansare a tranzitiilor
precum si pentru tratarea concurenta a mai multr mesaje din coada de mesaje.
unde:
Definitie 16. Definim hartile de stari scalabile de grad 2 ca fiind tuplul:
HSS 2 =(M, S, O, P, E, sR, SF, (stSucc, stInit, ortSucc,), inv, T; eval, par, Sa, C)
- M, S, O, sR, SF, (stSucc, stInit, ortSucc), Sa, C au semnificatiile descrise în
definitia 5,
- P reprezinta o multime finita de proprietati,
- E multime finita de expresii logice ai caror operanzi includ constante
numerice si booleene, siruri de caractere si proprietati. Operatorii utilizati
în aceste expresii sunt cei caracteristici tipurilor de operanzi la care se
adauga operatorii logici ? (negatie), ? (conjunctie) si ? (disjunctie).
- inv reprezinta o functie inv : S ? E, care asociaza fiecarei stari o expresie
logica. Aceaste expresii logice poarta numele de invarianti de stare si ele
sunt evaluate ca adevarate atunci când un obiect se va afla în starile
asociate.
- T ? ? (S\{sR}) ? M ? E ? ? (S\{sR}) este o multime finita de tranzitii
valide. O tranzitie ({s1’, ..., si’}, m, e, { s1’’, ..., sj’’}) ? T are semnificatia
specificata în definitia 5 iar expresia e reprezenta conditia de declansare a
tranzitiei.
- eval reprezinta o functie de evaluare a expresiilor logice, eval : E ? ,
unde pentru e? E, eval(e) reprezinta valoarea de adevar a expresie e la un
moment dat. Deoarece valoarea unei expresii depinde de valorile

proprietatilor care o compun, functia eval face parte din componenta
dinamica a hartii de stari, fiind utilizata în faza de executie a acesteia.
- par : M* ? ? (M) este tot o functie care face parte din componenta
dinamica, si ea impune politica de alegere a unei multimi de mesaje din
coada de mesaje în raport cu configuratia hartii de stari.
Functia par caracterizeaza algoritmul de alegere al unei multimi de mesaje.
Specificarea unei astfel de functii nu este importanta în aceasta faza de formalizare a
executiei hartilor de stari. Ea este impusa de mecanismele particulare implementate
în diverse limbaje de programare orientate-obiect concurente. Vom impune doar ca
multimea mesajelor returnate de aceasta functie sa contina numarul maxim de mesaje
care pot fi tratate concurent la un moment dat.
Figura 4.14. Reprezentarea grafica a hartilor de stari HSS 2
Pentru a defini interpretarea unei configuratii prin tratarea paralela a mai
multor mesaje vor trebui determinate tranzitiile care nu se influenteaza reciproc si
care pot fi declansate în paralel. Astfel de tranzitii vor avea starile sursa si destinatie
123

incluse în componente ortogonale distincte si le vom numi tranzitii independente. De
exemplu, pentru harta de stari din figura 4.14, tranzitiile etichetate cu ScoateEticheta
si Goleste vor putea fi declansate concurent, fara a se afecta reciproc.
Definitie 17. Doua tranzitii t', t'' ? T sunt independente daca si numai daca
domeniile lor sunt ortogonale, adica p (PREDdom '
124
t ? PRED dom t ''
) ? S.
Definiti 18. Numim configuratie a unei harti de stari HSS 2 tuplul ( Sa, par(C),
Cr), unde Sa ? S reprezinta multimea starilor active, par(C) multimea mesajelor din
coada de mesaje ce urmeaza a fi tratate în paralel, iar Cr ? M* reprezinta "restul"
cozii de mesaje C în urma extragerii mesajelor din par(C). Configuratia initiala a
unei harti de stari este (active(sR), ? ).
functia:
Definitie 19. Se numeste interpretare a configuratiei unei harti de stari HSS 2
? 2 : ? (S) ?? (M) ? M* ? ? (S? SF) ? M*,
? 2 (Sa,{m1,...,mn},Cr) =
i?
1
?
? ( Activ(
Si
''),
C'
r ), daca ? i ? { 1,..,
n}
? ( Si
',
mi,
ei,
Si
'')
? T independente,
?
n
= ?
Si
'?
Sa
? S pa si eval(
ei
) ? true
.
? ( Sa
, C'r
), daca ? i ? { 1,..,
n}
? S1,
S 2 ? S,
e ? E : ( S1,
mi,
e,
S2
) ? T
?
? ( Sa
, C'r
^m1
^...^mn
), in rest
Definitia 20. Se numeste executie a unei harti de stari HSS 2 o secventa finita
sau infinita de interpretari succesive a configuratiei hartii de stari, pornind de la
configuratia initiala a acesteia, si o vom nota:
(active(sR), ? , ? ) ? ? ?
? 2
(S1, par(C),Cr1) ? ? ?
? 2
... ? ? ?
? 2
(Sk, par(C),Crk) ? ? ?
? 2
unde S1, ..., Sk,.. ? S, si Cr1,..., Crk,... ? M*. Executia este finita daca multimea starilor
active detine o stare finala.
Figura 4.15. reprezinta descrierea hartii de starii HSS 2 pentru clasa Sticla a
carei structura a fost descrisa în figura 4.14. O executie posibila a acestei harti de stari
este urmatoarea:
({Goala}, ? ) ? ? ?
? 1
({Goala}, ) ? ? ?
? 1
({Goala}, ) ? ? ?
? 1
({Plina}, ) ? ? ?
? 1
...

({Plina}, ) ? ? ?
? 1
({F},? ).
125
({Goala},) ? ? ?
? 1
HSS 2
Sticla = (M, S, O, P, E, sR, SF, (stSucc, stInit, ortSucc,), inv, T; eval, par, C)
M = { Umple, Goleste, Sparge, Capacitate, AdaugaEticheta, ScoateEticheta}
S = { Sticla, Normal, Goala, Plina, FaraEticheta, CuEticheta}
O = { o1, o2, o3, o4, o5, o6, o7 }
P = {capacitate, continut, eticheta}
E = {e1=(0? continut ? continut ? capacitate), e2=(continut < capacitate),
e3 = (continut = capacitate), e4 = (continut + 5 < capacitate),
e5 = (continut + 5 ? capacitate), e6 = (eticheta),
e7 = (? eticheta), e8 = ( true )}
sR = Sticla
S F = { F }
stSucc : { oi, i=1..7 } ? ? ({ Sticla, Normal, Goala, Plina, F}),
stSucc(o 1) = {Normal, F}, stSucc(o 2) = {Goala, Plina},
stSucc(o3) = {FaraEticheta, CuEticheta},
stSucc(o 4) = stSucc(o 5) = stSucc(o 6) = stSucc(o 7) =? ;
stInit : { o1, o2, o3} ? { Sticla, Normal, Goala, Plina, CuEticheta, FaraEticheta},
stInit(o1) = Normal, stInit(o2) = Goala, stInit(o3) = FaraEticheta,
ortSucc : { Sticla, Normal, Goala, Plina } ? ? ({ o i, i=1..7 }) \ {? },
ortSucc (Sticla) = {o 1 }, ortSucc (Normal) = { o 2 , o 3 },
ortSucc (Goala) = {o4 }, ortSucc (Plina) = {o5 },
ortSucc (FaraEticheta) = {o 6 }, ortSucc (CuEticheta) = {o 7 },
inv : S ? E,
inv(Sticla) = e 1, inv(Normal) = e 8, inv(Goala) = e 2,
inv(Plina) = e3, inv(CuEticheta) = e6, inv(FaraEticheta) = e7,
T = {({Goala}, Umple , e 4, {Goala}), ({Goala}, Umple, e 5, {Plina}),
({Plina}, Goleste, {Goala}),
({FaraEticheta}, AdaugaEticheta, e8, { CuEticheta }),
({CuEticheta }, ScoateEticheta, e 8, { FaraEticheta }),
({Normal}, Sparge, e8, {F}) }
Figura 4.15. Exemplu de harta de stari HSS 2
4.5.3. Executabilitatea hartilor de stari scalabile
Ciclul de viata a unei aplicatii are mai multe etape distincte: de specificare,
analiza, proiectare, implementare, testare si întretinere.
În cadrul acestei sectiuni ne-am preocupat în principal de trecerea de la un
model abstract al unei aplicatii, rezultat în urma etapelor de analiza si proiectare, la
modelul de implementare al acesteia. Acest lucru a fost realizat prin definirea
riguroasa a notiunii de executie a hartii de stari scalabile.
Implementarea unui prototip al unei aplicatii pe baza unui model necesita o
perioada relativ mare de timp. Aceasta deoarece dezvoltatorul este pus în situatia de a
exprima într-un limbaj de programare conceptele abstracte care compun modelul. De

exemplu, în cazul hartilor de stari dezvoltatorul îsi va pune problema modalitatii de
codificare a unei stari, a unui eveniment sau a conditiilor de activare a unei tranzitii.
Prin urmare translatarea unui model într-un limbaj de programare poate dura
mai multe zile sau chiar saptamâni. Un model se numeste executabil daca aceasta
translatare se poate efectua automat. Automatizarea procesului de translatare poate
conduce la posibilitatea executarii unui prototip aproape imediat dupa ce modelul
acestuia a fost definitivat.
Exista la ora actuala o serie de instrumente CASE care genereaza cod din
modelele construite. Generarea de cod implica existenta unei modalitati de
translatarea automata a elementelor modelelor în diferite limbaje de programare
particulare. Acest lucru presupune o descriere riguroasa a semanticii fiecarui element
ce compune un astfel de model. În particular, în [BOR95] si [DOU99] sunt descrise
doua modalitati de translatare a masinilor de stari finite, respectiv a hartilor de stari
UML într-un limbaj de programare orientat-obiect. Ambele metode iau în considerare
existenta în cadrul aplicatiei modelate a mai multor fire de executie care ruleaza în
paralel. Rezultatul translatarii diagramelor de stari însa nu corespunde unui model
obiect care sa respecte principiile enuntate în cadrul capitolului doi.
Asa cum am aratat în capitolul precedent, anomaliile existente la nivelul
limbajelor de programarea orientate-obiect concurente nu pot fi în totalitate eliminate.
În cazul multor limbaje de programare orientate-obiect concurente însa efectul acestor
anomalii poate fi diminuat daca se respecta anumite discipline de programare.
Generarea automata de cod poate impune o astfel de disciplina, iar efortul
dezvolttorilor de aplicatii este mult scazut. Prin urmare se impune definirea unei
semantici distince pentru hartile de stari astfel încât aceastea sa poata modela cât mai
multe modele de concurenta existente în literatura.
Puterea de modelare, precum si faptul ca reprezinta un formalism grafic,
vizual au determinat introducerea hartilor de stari, dupa cum am aratat si în sectiune
precedenta, într-o varietate de metode de analiza si proiectare de aplicatii. Caracterul
general al acestor diagrame a facut ca ele se fie utilizate atât în modelarea aplicatiilor
structurate cât si a celor orientate-obiect deopotriva.
Sistemul formal construit si prezentat în capitolul 3 (bazat pe domenii si
operatii semantice de modelare a comportamentului instantelor unei clase), alaturi de
concluziile din sectiunea 4.2. ne conduc la ideea ca si în cazul modelarii
126

comportamentului obiectelor active hartile de stari sunt potrivite. În cazul unor clase
ce implementeaza obiecte cu un comportament complex utilizarea hartilor de stari
este chiar necesara pentru întelegerea si gestionarea acestuia. Utilizarea într-un
context orientat-obiect concurent însa implica mai multe modificari si extensii
semantice, pentru a putea fi modelat un control general al interfetei.
Maniera de utilizare a acestor harti de stari în diverse metode de analiza si
proiectare nu este potrivita. Dupa cum am aratat si în sectiunea precedenta, hartile de
stari sau variante ale acestora sunt utilizate relativ la modele de obiecte concurente
particulare. Pe de alta parte, în cazul limbajului de modelare UML, hartile de stari nu
se bucura de o descriere riguroasa, precisa ceea ce conduce la o interpretare gresita a
acestora. Acest neajuns implica imposibilitatea realizarii de modele executabile ale
comportamentului obiectelor. În momentul de fata majoritatea instrumentelor CASE
de analiza si proiectare care sprijina UML nu permit generarea de cod din diagrame
de tranzitie a starii, cele care totusi o fac implementând variante restrânse ale acestor
diagrame [DOU99].
Prin urmare trebuie definita o modalitate de descriere vizuala a
comportamentului obiectelor active, având la baza hartile de stari al lui Harel,
extensiile semantice si vizuale introduse în UML si îmbogatite cu o semantica care sa
permita realizarea de modele executabile.
O astfel de harta de stari va permite descrierea comportamentului tuturor
instantelor unei clase concurente. Prin urmare vom considera ca singurele evenimente
care au loc în cadrul unui sistem si care pot influenta comportamentul instantelor unei
clase sunt mesajele de apelare a operatiilor clasei.
În practica însa un obiect activ nu îsi va modifica interfata astfel încât acest
lucru sa fie vizibil din exteriorul sau. El va comunica cu celelalte obiecte din sistem
prin intermediul unei interfete definite static, urmând ca mesajele receptionate prin
intermediul acestei interfete sa fie apoi procesate intern de catre gestionarul de
interfata.
Harta de stari va descrie atributiile gestionarului de interfata, deoarece ea va
contine toate informatiile necesare pentru determinarea oportunitatii acceptarii unui
mesaj sau nu.
127

4.6. Concluzii
Studiul limbajelor de programare orientate-obiect concurente realizat în
capitolul al doilea a evidentiat patru principii care stau la baza proiectarii de modele
de obiecte concurente. Pe baza acestor principii am determinat un model general al
obiectelor active. Implementarea acestui model se regaseste în majoritatea limbajelor
care utilizeaza mecanisme de sincronizare bazate pe încapsulare.
Am aratat în cadrul acestui capitol ca obiectele active au toate trasaturile care
caracterizeaza sistemele reactive. De aceea hartile de stari [HAR87] reprezinta cel
mai potrivit formalism grafic care poate fi utilizat în modelarea comportamentului
acestora.
Am extins formalismul hartilor de stari cu elemente noi, atât grafice cât si
semantice, în scopul utilizarii acestora în specificarea comportamentului obiectelor
active definite de modelul determinat. Extensiile se refera în principal la scalabilitate,
executabilitate si la definirea unei semantici precise.
Utilizarea unui astfel de formalism, alaturi de reguli de translatare a modelelor
rezultate în cod sursa usureaza activitatea de dezvoltare, testare si depanare a
aplicatiilor orientate-obiect concurente.
Formalismul grafic propus în sectiunea a patra a acestui capitol poarta numele
de harta de stari scalabile. Scalabilitatea starilor usureaza specificarea obiectelor
active care au un comportament complex. Utilitatea acestei trasaturi este evidenta în
special în cazul folosirii unui instrument care sa asiste analistul sau proiectantul de
aplicatii în activitatea de modelare. Modelele comportamentale ale obiectelor active
pot fi astfel foarte usor de analizat la diverse nivele de detaliu.
Executabilitatea este la rândul sau o trasatura extrem de importanta a hartilor
de stari scalabile, permitând automatizarea implementarii obiectelor active pe baza
modelelor comportamentale ale acestora. De asemenea, executabilitatea ofera suport
pentru simularea, testarea si depanarea executiei obiectelor active la acelasi nivel de
abstractizare cu modelul construit. Se evita astfel dezvoltarea aplicatiilor folosind
formalisme vizuale si depanarea acestora la nivelul codului sursa.
Deoarece semantica hartilor de stari scalabile are în vedere un model de
obiecte concurente general, ele permit generarea de cod sursa într-o diversitate de
limbaje de programare orientate-obiect concurente, care utilzeaza diferite modalitati si
128

mecanisme de specificare a concurentei si a interactiunii între activitati concurente.
Acest lucru confera o flexibilitate crescuta în ceea ce priveste translatarea modelelor
comportamentale în cod sursa.
Toate aceste trasaturi ale hartilor de stari scalabile au fost validate prin
implementarea unui instrument de asistare a dezvoltarii de aplicatii orientate-obiect
concurente, instrument a carui arhitectura si descriere functionala sunt prezentate în
capitolul urmator.
129

5. ActiveCASE - instrument de modelare si simulare a
comportamentului obiectelor active
5.1. Introducere
În cadrul acestui capitol este descrisa arhitectura si modul de functionare a
unei aplicatii de modelare, implementare si simulare a aplicatiilor orientate-obiect
concurente. Aceasta aplicatie, numita ActiveCASE, a fost realizata integral de catre
autorul tezei si are la baza modelarea obiectelor active prin intermediul hartilor de
stari scalabile descrise în finalul capitolului precedent. Instrumentul permite
specificarea structurii claselor de obiecte active, modelarea comportamentului
acestora si generarea de cod sursa. Codul sursa este generat în limbajul C++ si
utilizeaza clase din biblioteca MFC (Microsoft Foundation Class) versiunea 6.0. De
asemenea, implementarea instrumentului ActiveCASE s-a realizat utilizând mediul de
programare Visual C++ 6.0 si biblioteca de clase MFC 6.0.
Structura interna a acestui instrument a fost astfel conceputa astfel încât sa
poata fi integrata cu usurinta într-un instrument CASE de analiza si proiectare a
aplicatiilor cu un caracter mai general. În particular, ActiveCASE va reprezenta un
modul distinct al instrumentului Rocase ([BOZ94a], [SUC96b], [CHI97]), dezvoltat
în cadrul Laboratorului de Cercetare în Informatica al Universitatii "Babes-Bolyai"
din Cluj Napoca. Rocase este un instrument de analiza si proiectare a aplicatiilor
orientate-obiect secventiale folosind UML, si contine module pentru editarea de
diagrame UML, verificarea consistentei acestor diagrame, generare de cod sursa C++
si reverse-engineering (construire automata de diagrame de clase pe baza analizai de
cod sursa).
130

distincte:
Instrumentul ActiveCASE este constituit din trei elemente cu functionalitati
- ActiveCASE.exe - aplicatie care permite editarea diagramelor de clase si a
hartilor de stari si care realizeaza generarea codului sursa,
- StateControl.ocx - componenta utilizata în vizualizarea unei harti de stari
din cadrul unui model,
- ActiveStatechart.dll - componenta utilizata în simularea executiei unui
obiect activ.
Metamodelul diagramelor de clase si a hartilor de stari scalabile implementate
în ActiveCASE este prezentat în cadrul sectiunii a doua, comparativ cu meta-modelul
propus în [OMG99] la specificarea limbajului UML.
Sectiunea a treia descrie în detaliu functionalitatile componentelor
instrumentului ActiveCASE. De asemenea este prezentat modelul de obiecte active
implementat în C++ pe baza caruia se realizeaza generarea de cod pentru clasele
modelate prin intermediul instrumentului. Acest model obiect este unul simplu,
dezvoltat în scopul demonstrarii utilitatii intrumentului ActiveCASE în etapele de
testare si depanare a aplicatiilor orientate-obiect concurente. O viitoare versiune a
acestui instrument, asa cum va fi subliniat în finalul acestui capitol, va putea oferi
utilizatorului posibilitatea de a-si defini singur limbajul pentru generarea codului
sursa, fara a afecta calitatile privind simularea comportamentului obiectelor active
generate prin intermediul componentei ActiveStatchart.dll.
Sectiunea a patra demonstreaza capacitatea de modelare si executabilitatea
hartilor de stari scalabile prin dezvoltarea si simularea unei aplicatii de control al
traficului de masini pe o pista dreptunghiulara. Acest exemplu utilizeaza toate
elementele componente ale hartilor de stari scalabile descrise în cadrul capitolului
precedent.
În finalul acestui capitol este realizat un studiu comparativ între ActiveCASE
si alte doua produse existente în acest moment care au ca si caracteristica comuna
simularea executiei obiectelor active prin intermediul hartilor de stari. De asemenea
sunt prezentate directiile de viitor în acest domeniu.
131

5.2. Meta-modelul hartilor de stari scalabile
Asa cum am aratat în capitolul precedent, masinile de stari sunt foarte
populare în lumea ingineriei softului. Calitatile si neajunsurile acestora au fost
îndelung discutate în multe lucrari de specialitate, mai ales dupa extinderea acestora
cu noi trasaturi [HAR87]. În cele mai multe cazuri însa descrierea si caracterizarea
acestora s-a facut în absenta unui meta-model.
Specificatiile UML surprind însa acest aspect si contin un meta-model static
(diagrama de clase) al acestor diagrame. Astfel de meta-modele sunt utile deoarece
ele stau la baza implementarii diagramelor de stari în cadrul unor instrumente de
analiza si proiectare a aplicatiilor.
În cele ce urmeaza vor fi prezentate în detaliu doua meta-modele statice ale
diagramelor de stari care au stat la baza a doua instrumente CASE, si anume: meta-
modelul prezentat în specificatiile UML si cel utilizat în modelarea hartilor de stari
scalabile pentru instrumentul ActiveCASE.
5.2.1. Modelarea hartilor de stari în UML
În figura 5.1. este prezentata diagrama de clase corespunzatoare diagramelor
de tranzitie a starilor a carei specificare am rezumat-o în sectiunea a treia a capitolului
precedent.
În aceasta diagrama Event reprezinta o clasa abstracta care modeleaza toate
evenimetele care pot declansa o tranzitie în cadrul unei diagrame de stari (acestea sunt
împartite în SignalEvent, CallEvent, TimeEvent si ChangeEvent). Evenimentele de
apel (call events) reprezinta receptionarea unei cereri de invocare a unei operatii.
Aceste evenimente au în meta-modelul UML asociate operatii (metode ale claselor),
specificându-se existenta a doua operatii speciale, si anume cele de creare si
distrugere de obiecte.
ChangeEnvent reprezinta evenimentele generate de modificari aduse unor
atribute sau relatii (de asociere) care compun o anumita expresie booleana. Aceste
modificari pot fi verificate în urma executiei uneia sau mai multor actiuni (care nu au
fost generat de catre un eveniment de modificare). Aceste evenimente au asociate
câte o expresie booleana, expresie care este periodic evaluata. În momentul în care
expresia este adevarata se emite evenimentul care la rândul sau poate declansa una
sau mai multe tranzitii.
132

Figura 5.1. Metamodelul diagramelor de stari în UML
Clasa ce modeleaza starile compuse este descendenta a clasei State si contine
una sau mai multe substari (una sau mai multe instante ale clasei StateVertex).
Aceasta clasa are doua proprietati foarte importante, care precizeaza daca starea
compusa este concurenta (isConcurrent) si daca ea este o substare a unei stari
concurente (isRegion).
Clasa SimpleState a fost introdusa doar din ratiuni de “simetrie” cu
CompositeState, ea neavând nici o alta trasatura în plus fata de clasa State. Instantele
acestei clase reprezinta stari care nu contin substari.
O stare este asociata cu doua secvente de actiuni care vor fi executate la
intrarea (entry) respectiv la iesirea (exit) din starea respectiva prin intermediul unei
tranzitii. Aceste actiuni sunt atomice si ele nu sunt executate în cazul în care are loc o
auto-tranzitie. De asemenea o stare are asociata o lista de evenimente care sunt
amânate.
133

O masina de stari este compusa din tranzitii si stari. Starile continute de o
masina de stari formeaza un graf ale carui arce sunt tranzitiile între aceste stari. O
masina de stari modeleaza comportamentul unui anumit element din model. Acest
element reprezinta contextul masinii de stari. Pentru o masina de stari exista o
singura stare (compusa sau nu), numita Top care are ca si parinte direct masina de
stari. Toate celelalte stari continute de masina de stari reprezinta de fapt extensia
starii compuse Top.
Clasa abstracta StateVertex reprezinta clasa de baza pentru toate tipurile de
stari definite în UML, relatiile outgoing si incoming specificând faptul ca o stare poate
fi sursa si destinatia unui numar nedefinit de tranzitii.
Clasa SubmachineState reprezinta o masina de stari încuibarita (sub-masina de
stari). Asa cum se precizeaza si în documentatia UML o submasina de stari este
echivalenta din punct de vedere semantic cu o stare compusa precizându-se ca ea a
fost introdusa cu scopul de a usura în primul rând reutilizabilitatea. Din pacate nu se
precizeaza si modul în care s-ar putea realiza efectiv reutilizarea unei submasini de
stari si nici nu sunt impuse anumite constrângeri care sa granteze independenta
submasinilor.
5.2.2. Modelarea hartilor de stari scalabile în ActiveCASE
Asa cum am aratat, hartile de stari scalabile se bazeaza diagramele de tranzitie
a starii descrise în UML. ActiveCASE implementeaza aceste harti de stari, oferind
posibilitatea modelarii comportamentului obiectelor active. Modulul care
implementeaza hartile de stari scalabile reprezinta deocamdata un modul distinct,
neintegrat într-un context mai larg care sa permita realizarea tuturor modelelor
specificate în documentatia UML. Cu toate acestea, acest modul ofera suport pentru
patru dintre cele mai importante etape ale ciclului de viata a unei aplicatii, si anume:
analiza, implementare, testare si depanare.
Asa cum am amintit în introducere, modulul de modelare a obiectelor active
urmeaza sa fie integrat în cadrul instrumentului Rocase, dezvoltat la Laboratorul de
Cercetare în Informatica al Universitatii "Babes-Bolyai" din Cluj-Napoca. Rocase
reprezinta un instrument de analiza si proiectare a aplicatiilor orientate obiect, care
sprijina UML ca si limbaj de modelare si care ofera suport pentru toate etapele din
ciclul de viata al unei aplicatii premergatoare implementarii (modelare statica,
134

dinamica si functionala, generare de cod, reverse engineering, round-trip engineering
etc). Modulul implementat pentru modelarea obiectelor active ridica probleme care
pentru instrumentele de asistare a dezvoltatorilor de aplicatii orientate-obiect
secventiale nu existau. Astfel, implementarea diagramelor de stari pentru modelarea
dinamica s-a realizat pe baza extensiilor semantice prezentate în capitolul 4, si care se
refera în principal la existenta de interfete dinamice pentru obiecte, a unei cozi de
mesaje si a unui gestionar de mesaje.
Figura 5.2. Metamodelul diagramelor de tranzitie a starilor si a claselor în ActiveCASE
Modelul static propus pentru modelarea acestor diagrame (figura 5.2) este mai
robust si mai bine definit, eliminând redundantele existente în alte modele. De
asemenea, definirea legaturilor dintre o clasa si diagrama sa de stari, respectiv dintre o
stare compusa si substarile sale este mult mai clara si naturala.
În cele ce urmeaza vor fi prezentate doar elementele noi care au fost introduse
relativ la specificatiile date de UML.
Un prim element de noutate este dat de faptul ca în ActiveCASE starile nu
sunt împartite în stari simple - stari compuse sau în stari ortogonale - neortogonale asa
cum au fost gândite mai multe meta-modele anterioare. Prin urmare nu sunt definite
clase speciale pentru a modela fiecare dintre aceste categorii particulare de stari.
135

În ActiveCASE exista doar doua tipuri de stari: pseudostari (de iesire, intrare,
istoric) - clasa FSMPseudoState- si stari concrete - clasa FSMConcreteState. O stare
concreta poate contine una sau mai multe componente ortogonale (clasa
FSMOrthogonalComponent). Aceste componente corespund substarilor ortogonale
din modelul UML. Astfel, o stare concreta este concurenta daca contine mai mult de
o componenta ortogonala. Fiecare dintre aceste componente poate contine oricâte
stari (aceste stari sunt practic vazute de catre proiectant ca si substari ale starii
compuse care detine componenta ortogonala). O stare se reprezinta grafic prin
intermediul unui dreptunghi cu capetele rotunjite care are trei compartimente separate
între ele prin linii orizontale.
Prima sectiune va contine numele starii respective si un buton special utilizat
în scalarea starii (afisarea sau ascunderea componentelor ortogonale proprii).
Scalarea permite tratarea unei stari compuse ca si o stare simpla si ea este utila în
modele ce contin harti de stari de dimensiuni mari. În acest mod, atentia
proiectantului va putea fi canalizata doar spre anumite parti a descrierii
comportamentului unui obiect activ. De asemenea, proprietatea de scalabilitate a
starilor permite o mai buna testare si depanare a obiectelor active care au un
comportament complex.
Sectiunea a doua a reprezentarii grafice a unei stari va contine toate
componentele ortogonale care compun starea, despartite prin linii punctate, verticale.
Componentele ortogonale nu au o reprezentare grafica propriu-zisa, ele fiind
transparente proiectantului.
Cea de-a treia sectiune va contine:
- secventele de actiuni entry si exit asociate starii,
- o expresie booleana (invariant) care defineste starea (pentru testarea
consistentei obiectelor),
- evenimentele acceptate explicit de catre oricare dintre substari fara a se
declansa nici o tranzitie (vor fi acceptate implicit evenimentele
corespunzatoare apelurilor de operatii declarate ca observatori),
- variabile de stare (variabile intermediare pentru stocarea anumitor valori în
timpul declansarii unei tranzitii).
O stare concreta va contine cel putin o componenta ortogonala. Daca aceasta
nu contine nici o substare atunci este o starea concreta corespunde notiunii de stare
136

simpla din UML, în caz contrar fiind vorba de o stare compusa. În AciveCASE nici o
componenta ortogonala nu va fi vida, aceasta continând în mod obligatoriu o pseudo-
stare initiala sau o pseudo-stare istoric. În acest context o stare este simpla, daca ea
contine o singura componenta ortogonala, iar aceasta are o singura sub-stare: pseudo-
starea initiala.
Rezumând cele spuse pâna acum, în ActiveCASE o stare simpla este perceputa
ca o stare compusa cu zero substari, iar o stare neconcurenta ca o stare cu o singura
componenta ortogonala. Aceasta modalitate simpla de a gândi o diagrama de stari
conduce la descongestionarea vizibila a meta-modelului acesteia, eliminând clasele
redundante (în UML de exemplu clasa SimpleState a fost modelata doar pentru
"simetrie", ea însa neavând nici o trasatura în plus fata de parintele sau State). În plus,
o astfel de reprezentare are calitatea de a unifica din punct de vedere semantic
conceptele de stare simpla, compusa si ortogonala.
Figura 5.3 ofera o imagine intuitiva a legaturilor dintre entitatile hartilor de
stari scalabile. O astfel de harta de stari poate fi reprezentata printr-un arbore care va
avea întotdeauna un numar par de nivele (nivelele impare contin stari concrete iar
nivelele impare regiuni ortogonale), frunzele fiind întotdeauna regiunile ortogonale
vide, care nu contin nici o substare.
137
AM1
A
AM2
B1 B2 C1
B1M B2M C1M
Figura 5.3. Reprezentarea hartilor de stari scalabile prin intermediul unui arbore eterogen,
cu entitati grupate pe nivele
Un alt element de noutate esential este acela ca o clasa nu va avea asociata o
diagrama de stari sau o masina de stari ci o stare concreta. Aceasta stare concreta
reprezinta practic parintele tuturor celorlalte stari care descriu comportamentul
obiectelor clasei asociate. Acesta stare va avea numele clasei careia i-a fost atasata,
iar invariantul sau va reprezenta de fapt conditia de consistenta a obiectelor apartinând
clasei respective.

În alte modele realizate pâna în prezent o clasa putea sau nu sa aiba asociata o
diagrama de stari care sa-i modeleze comportamentul. Consideram ca este util sa
impunem ca o clasa sa aiba întotdeauna sa aiba atasata o stare. În cazul unei clase
oarecare al carui comportament dinamic nu este semnificativ, atunci aceasta stare va
fi una simpla (nu va contine nici o substare). Invariantul acestei stari va defini
conditia de consistenta a obiectelor clasei respective. În cazul unei clase cu un
comportament complex, starea atasata va contine practic diagrama de stari a clasei. În
momentul în care va fi creata o instanta a unei clase, obiectul sau va intra în starea
asociata acesteia, stare care se va comporta ca o stare compusa obisnuita activând una
dintre starile initiale ale acesteia.
Aceasta abordare uniforma este mult mai naturala si mai comoda din punct de
vedere al unui proiectant de aplicatii. Practic notiunea de diagrama de stari a disparut,
comportamentul claselor fiind descris prin intermediul unei ierarhii de stari între care
exista diverse tranzitii.
138
invariantul
starii State4
este inclus în
conditia tranzitiei
Figura 5.4. Exemplu de clonare a tranzitiilor
În scopul reducerii complexitatii meta-modelului static, în figura 5.2. am
prezentat toate clasele fara structura (proprietati si operatii). Este important de
precizat faptul ca în cadrul claselor FSMTransition si FSMAbstractState a fost
introdus un atribut de tip întreg, numit InternalID care are rolul de a atribui atât
tranzitiilor cât si starilor un identificator unic la nivelul hartii de stari din care fac

parte acestea. Acest identificator unic va fi utilizat în special în generarea de cod si în
procesul de simulare.
Autotranzitia de la nivelul clasei FSMTransition ataseaza fiecarei tranzitii câte
o dublura, utila în cazul scalarii (minimizarii sau maximizarii) starilor compuse.
Astfel, în figura 5.4. este dat un exemplu în care o astfel de dublura este necesara.
Tranzitiile etichetate cu m1, respectiv m3 fac legatura între stari aflate la nivele
diferite de încuibarire. În momentul în care se doreste ignorarea continutului starii
State2 de exemplu, substarile acesteia vor fi "ascunse", fapt care implica automat si
"ascunderea" celor doua tranzitii amintite. Aceasta operatie de "ascundere" conduce
însa la modificarea comportamentului obiectului modelat: obiectul nu va putea
accepta un mesaj m1 în cazul în care se afla în starea State1, sau un eveniment m2
atunci când se afla în starea State2. Aceasta este însa un efect nedorit, deoarece
scalarea starilor are doar rolul de a reduce complexitatea unei harti de stari din punct
de vedere al proiectantului si nu de a modifica comportamentul modelat.
Prin urmare este necesara introducerea unor tranzitii suplimentare care sa
conserve acest comportament. Aceste tranzitii sunt de fapt dublurile tranzitiilor
originale, si ele fac legatura între starile State1 si State2. Aceste tranzitii vor avea
acelasi identificator ca si tranzitiile originale pentru a nu perturba procesul de
simulare, iar ele nu vor influenta generarea de cod sursa. Tot în scopul conservarii
comportamentului, clonele tranzitiilor care au ca stare sursa o stare "ascunsa" vor avea
conditia de declansare ca o conjunctie între conditia originala si invariantul starii sursa
(cazul tranzitiei etichetate cu m3, care va avea acum conditia de declansare c3 && c4,
unde && reprezinta operatorul si-logic din limbajul de programare C++).
5.3. Descrierea aplicatiei ActiveCASE
Instrumentele CASE de analiza si proiectare orientata-obiect a aplicatiilor
ofera sprijin pentru cele mai importante etape ale ciclului de viata a unei aplicatii.
Acestea sunt:
- Analiza - în cadrul careia se realizeaza identificarea caracteristicilor
esentiale tuturor solutiilor corecte posibile,
- Proiectarea - care adauga modelelor de analiza noi elemente care definesc
o solutie particulara, pe baza optimizarii anumitor criterii,
139

- Implementarea - în care se realizeaza un proiect executabil al solutiei
particulare modelata în faza de proiectare,
- Testarea - în care are loc verificarea faptului ca implementarea este
echivalenta cu modelul proiectat si validarea faptului ca implementarea
respecta criteriile de corectitudine identificate în etapa de analiza.
Instrumentul ActiveCASE este un instrument de modelare a obiectelor active
care ofera suport pentru trei dintre aceste etape (etapa de proiectare nu este surprinsa,
codul sursa fiind generat direct din modelele de analiza). Aplicatia ActiveCASE
propriu-zisa permite editarea de diagrame de clase si de stari si contine un generator
de cod C++.
Editarea diagramelor de clase utilizeaza un sub-set restrâns de notatii dintre
cele introduse de UML. Editorul de diagrame de stari însa este mult mai complex, si
permite editarea de harti de stari scalabile, cu toate elementele introduse de acestea
(figura 5.5). Editarea este senzitiva la context si se realizeaza uniform pentru ambele
diagrame, modul de manipulare al entitatilor grafice fiind natural si simplu iar
actualizarea diagramelor facându-se rapid. Diagramele pot fi paginate, exista optiuni
de aliniere a entitatilor selectate, cursorul îsi modifica forma în raport cu entitatea
editatã, barele de instrumente pot fi gestionate si deplasate. Editorul dispune de
facilitati de print preview si zoom. Toate caracteristicile mentionate fac ca editorul sã
fie superior tuturor editoarelor instrumentelor cunoscute de noi pâna în prezent.
Fiecare proiect este reprezentat într-o fereastra care are doua sectiuni: una
pentru editarea diagramelor de clase iar cea de-a doua pentru cea a diagramelor de
stari. Fiecare clasa din diagrama de clasa va avea o stare concreta corespunzatoare în
diagrama de tranzitie a starilor.
Codul generat din diagramele editate este în limbajul C++. Toate clasele
modelate în ActiveCASE vor fi subclase ale unei clase speciale ActiveObject, care
încapsuleaza proprietati si operatii pentru tratarea corespunzatoare a starilor, a
tranzitiilor dintre acestea si pentru interactiunea cu componenta de simulare.
140

Figura 5.5. Captura a aplicatiei ActiveCASE care surprinde editorul de diagrame de clase si de stari
Codul de declarare a clasei ActiveObject este dat mai jos.
class ActiveObject : public CObject
{
//contructors/destructor
DECLARE_DYNAMIC(ActiveObject)
public:
ActiveObject(CString strName, BOOL bActivateSimulation=FALSE);
virtual ~ActiveObject();
//Attribute
protected:
static DLGActiveObjectSelection m_dlgSelection;
ISimulation* m_pSimulation;
CString m_strName;
public:
//Operations
protected:
virtual void GetCurrentStateCode(CUIntArray* pArray);
virtual void LaunchTransition(UINT nTransitionInternalID);
virtual void EndTransition(UINT nTransitionInternalID);
public:
static void SelectActiveObject();
141

};
CString GetName() {return m_strName;};
void SetName(CString strName){m_strName=strName;};
void ActivateSimulation();
void DeactivateSimulation();
BOOL IsSimulationActive(){return m_pSimulation!=NULL;};
Clasa ActiveObject este o subclasa a clasei CObject a bibliotecii de clase
MFC. Aceasta clasa permite consultarea informatiilor de tip in timpul executiei
(RunTime Type Information - RTTI).
O alta clasa importanta pentru simularea aplicatiilor concurente generate cu
ActiveCASE este clasa DLGActiveObjectSelection. Aceasta clasa implementeaza o
fereastra de dialog care permite selectarea în timpul executiei unei aplicatii a
obiectelor active pentru care se doreste vizualizarea diagramei de stari (figura 5.11).
Fereastra de dialog contine doua liste, una care afiseaza toate clasele descendente din
ActiveObject si care au instante în executie, si o a doua care contine toate instantele
clasei selectate existente în aplicatie la un moment dat.
Clasa ActiveObject are un atribut static m_dlgSelection de tip
DLGActiveObjectSelection. Atributul m_dlgSelection este informat de fiecare data
când este creat sau distrus un nou obiect activ, astfel încât atunci când se doreste
vizualizarea diagramei de stari pentru un obiect activ în executie, fereastra de dialog
va afisa toate obiectele active existente în aplicatie la momentul respectiv.
Identificarea de catre utilizator a unui obiect activ particular se realizeaza prin
intermediul atributului m_strName, implementat la nivelul clasei ActiveObject, care
este un sir de caractere.
Alaturi de fisierele de declarare si definire a claselor ActiveObject si
DLGActiveObjectSelection, în aplicatiile concurente generate de ActiveCASE mai
trebuie adaugate fisiere pentru specificarea interfetei componentei de simulare.
Aceasta componenta exporta functii care permit determinarea caii fisierului în care a
fost salvat modelul editat cu ajutorul instrumentului ActiveCASE, a diagramei de stari
care se doreste a fi vizualizata, precum si pentru activarea unei anumite tranzitii.
Codul de daclarare a interfetei este dat în continuare:
class ISimulation : public COleDispatchDriver
{
public:
ISimulation() {}
ISimulation(LPDISPATCH pDispatch) : COleDispatchDriver(pDispatch) {}
142

Attributes
public:
// Operations
public:
void ShowDialog();
void HideDialog();
CString GetPath();
void SetPath(LPCTSTR lpszNewValue);
CString GetClass();
void SetClass(LPCTSTR lpszNewValue);
void LaunchTransition(long TransitionCode);
CString GetTitle();
void SetTitle(LPCTSTR lpszNewValue);
void EndTransition(long TransitionCode, long NewState);
};
Componenta de simulare afiseaza o fereastra de dialog care contine un control
special de vizualizare a unei diagrame de stari a carei reprezentare grafica se afla în
cadrul unui fisier aflat la o cale data si care modeleaza comportamentul unei clase de
asemenea specificate initial.
Componenta de simulare este inclusa în fisierul ActiveStatechart.dll, si ea este
înregistrata în sistem, alaturi de componenta de vizualizare a unei diagrame de stari
(inclusa în fisierul StateControl.ocx), în momentul instalarii instrumentului
ActiveCASE.
În sectiunea urmatoare este prezentat un exemplu care implementeaza o
aplicatie de simulare a controlului traficului de masini pe o pista de forma
dreptunghiulara. Acest exemplu utilizeaza toate facilitatile oferite de instrumetul
ActiveCASE împreuna cu componentele anexe, si toate elementele introduse de
hartile de stari scalabile.
5.3. Modelarea si testarea unei aplicatii de simulare a traficului de masini
În figura 5.6. este prezentata diagrama de clase care modeleaza o aplicatie de
simulare a traficului masinilor pe o pista dreptunghiulara. Clasa Pista contine o
matrice de locatii si o multime de masini. Cele trei operatii ale clasei Pista (figura
5.7) realizeaza afisarea acesteia pe ecran precum si pornirea, respectiv oprirea, tuturor
masinilor care îi sunt asociate. Comportamentul unei piste este foarte simplu, aceasta
putându-se afla în doua stari, Stop si Start, care specifica faptul ca masinile asociate
sunt oprite sau se afla în miscare.
143

Figura 5.6. Diagrama de clase a aplicatiei de simulare a traficului de masini
Figura 5.7. Modelarea structurii si a comportamentului clasei Pista
Instantele clasei Masina au un comportament mai complex (figura 5.8).
Astfel, o masina se poate deplasa în cadrul unei piste în patru directii: sus, dreapta, jos
sau stânga. În momentul în care acestea întâlnesc un obstacol (marginea pistei, o
locatie blocata sau o alta masina) masinile se vor roti în sensul acelor de ceasornic
pentru a cauta o locatie libera pentru deplasare. O masina se poate afla în starile
Oprit, respectiv Pornit. În cazul în care o masina este pornita ea se poate afla în una
dintre cele patru stari corespunzatoare sensului de deplasare: InSus, InDreapta, InJos
si InStanga. Functia MergeDrept este apelata în continuu cât timp masina se afla în
starea Pornit si ea apeleaza functiile corespunzatoare de deplasare în raport de starea
locatiilor din vecinatatea locatiei ocupata de masina. În cazul opririi si repornirii
masinii aceasta îsi va continua deplasarea în sensul în care se deplasa înainte de oprire
(fapt modelat de pseudo-starea istoric din cadrul starii compuse Pornit).
144

Figura 5.8. Modelarea structurii si a comportamentului clasei Masina
Figura 5.9. Modelarea structurii si a comportamentului clasei Locatie
Si clasa Locatie are un comportament complex (figura 5.9). O locatie se poate
afla în doua stari distincte: Blocata si Neblocata. Starea Blocata sugereaza repararea
drumului aflat pe locatia respectiva, iar un obiect de tip Locatie sta într-o astfel de
stare o perioada finita de timp, dupa care se va debloca (în programul de test o locatie
ramâne blocata 2 secunde). În cazul în care o locatie este deblocata ea intra automat
în doua stari ortogonale: Libera si Utilizabila. Atunci când o locatie libera este
ocupata de o masina ea va trece în starea Ocupata, iar când ea a fost ocupata de patru
ori consecutiv va intra în starea CuGropi (o locatie se degradeaza pe masura ce este
traversata de masini). Parasirea acestei stari (prin eliberarea locatiei de masina care o
ocupa) genereaza automat un eveniment de blocare, pentru ca locatia sa fie reparata.
145

Figura 5.10. Simularea comportamentului masinii rosii
Editarea diagramelor prezentate în figurile 5.7, 5.8 si 5.9 este realizata cu
ajutorul instrumentului ActiveCASE (figura 5.5). De aici se va realiza generarea de
cod si atasarea codului generat unui proiect Visual C++. Interventia dezvoltatorului
aplicatiei este necesara doar pentru a creea o pista si a atasa acesteia un numar dorit de
masini. De asemenea este necesara interventia dezvoltatorului daca se doreste
reprezentarea grafica a obiectelor celor trei clase.
Dupa compilarea si link-editarea proiectului Visual C++ se poate lansa în
executie aplicatia care contine trasaturi de vizualizare a evolutiei comportamentului
tutror obiectelor active cu ajutorul celor doua componente de simulare amintite în
capitolul precedent.
146

Figura 5.11. Alegerea unui obiect activ în vederea simularii
Figura 5.12. Simularea comportamentului locatie din coltul stânga-sus al pistei
(starea Blocata e minimizata)
Figurile 5.10, 5.11 respectiv 5.12 prezinta momente distincte din executia
aplicatiei generate de ActiveCASE, si în care se exemplifica testarea
147

comportamentului obiectelor active “Masina rosie”, respectiv “Locatie_0_0”, prin
simularea acestuia prin harti de stari scalabile.
5.4. Concluzii
Dezvoltarea de aplicatii orientate-obiect concurente este extrem de laborioasa.
Asa cum am aratat în capitolele precedente, diferentele existente la nivel conceptual
între diverse limbaje de programare orientate-obiect concurente fac dificila
translatarea aplicatiilor dintr-un limbaj în altul. De asemenea, activitatea de testare si
depanare a acestor aplicatii implica o serie de probleme neexistente în cazul devoltarii
de aplicatii secventiale, probleme care tin în special de caracterul dinamic ridicat al
acestora. Prin urmare modelarea unor astfel de aplicatii folosind un set unitar de
notatii si concepte precum si posibilitatea testarii si depanarii la nivelul modelelor si
nu la nivelul codului sursa implica o crestere a calitatii aplicatiilor si o mai buna
întretinere a acestora.
Instrumentul ActiveCASE are rolul de a automatiza anumite etape ale
procesului de dezvoltare a aplicatiilor orientate-obiect concurente. Printre
principalele calitati ale acestui instrument amintim:
- flexibilitate în modelarea obiectelor active prin implementarea hartilor de
stari scalabile a caror semantica acopera o gama larga de modele obiect,
- puterea de modelare a concurentei interne a obiectelor active,
- ofera suport pentru adaptarea generatorului de cod la limbajul de
programare dorit,
- ofera suport pentru simularea comportamentului obiectelelor active la
executie prin intermediul unor componente care fac posibila utilizarea a
diverse medii de programare în dezvoltarea aplicatiilor finale,
- posibilitatea controlarii sau, în anumite cazuri, chiar a eliminarii
anomaliilor de mostenire prin impunerea de discipline de implementarea a
obiectelor active.
Alte produse care ofera suport pentru modelarea comportamentului obiectelor
active utilizând diagrame de stari sunt Rhapsody dezvoltat de firma i-Logix [DOU99]
si Covers realizat de Experimental Object Technologies din Sankt Petersburg
[BOR95]. Ambele produse permit generare de cod din diagrame de stari si ofera
148

posibilitatea testarii corectitudinii modelelor prin intermediul simularii
comportamentului la executie. De asemenea, ambele simulari se bazeaza pe
interpretarea structurii obiectelor si traducerea acestora în diagramele de stari din
model.
Simularea comportamentului se realizeaza însa la nivelul instrumentului de
modelare. O astfel de abordare reduce capacitatea de simulare “reala”, introducându-
se o serie de intârzieri datorate comunicarii între mediu si aplicatia concurenta
executata. Diferentele între modul de realizare a simularii în cadrul acestor
instrumente si abordarea ActivCASE sunt de aceeasi natura cu diferentele dintre
interpretare si compilare/executie a codului sursa.
Instrumentul Covers suporta modelarea comportamentului obiectelor active
doar prin intermediului masinilor cu stari finite, fara a introduce conceptele hartilor de
stari descrise în [HAR87]. Prin urmare modelarea unor comportamente complexe
este extrem de dificila sau chiar imposibila.
Pe de alta parte instrumentul Rhapsody ofera suport pentru majoritatea
tipurilor de modele descrise în specificatiile UML. Si aici însa, obiectele active cu un
comportament complex sunt mai dificil de modelat, iar urmarirea executiei acestora
prin intermediul simularii este greoaie, neexistând posibilitatea modificarii nivelului
de observare a dinamicii. Mai mult, codul generat se bazeaza pe un model obiect
complex, criptic, dificil de înteles si modificat.
Generarea de cod realizata în cadrul instrumentului ActiveCASE nu a avut în
vedere un model obiect complex. Acest model obiect se bazeaza pe utilizarea de
mecanisme din categoria celor orientate pe activitati. Diagrama de stari si semantica
atribuita acesteia permite însa generarea de cod în oricare dintre modelele obiect
specificate în literatura si luate în considerare în capitolul doi.
Spre deosebire de cele doua produse amintite, instrumentul ActiveCASE
introduce o serie de elemente noi, atât la nivelul editarii de diagrame cât si la nivelul
conceptelor introduse, cum sunt:
- editor de diagrame de stari performant, interactiv, senzitiv la context,
- scalabilitate,
- independenta simularii de mediul de analiza si proiectare,
- generare de cod configurabila,
149

- simulare interactiva, care permite configurarea hartilor de stari în timpul
executiei obiectelor active simulate,
- usurinta în manipulare si întretinere a diagramelor realizate,
- verificarea consistentei modelelor.
Una dintre dintre directiile viitoare de extensie a instrumentului ActiveCASE
este oferirea posibilitatii de definire si utilizare a sabloanelor de harti de stari.
Sabloanele de harti de stari reprezinta harti de stari generice, caracteristice unor
comportamente des întâlnite si care pot fi aplicate pe cazuri particulare de
comportament. Sabloanele de harti de stari sunt un concept nou, descris în [DOU99],
si care alaturi de sabloanele de proiectare contribuie la cresterea gradului de
reutilizabilitate a softului.
De asemenea, va trebui avuta în vedere posibilitatea mostenirii hartilor de stari
între super-clase si sub-clasele acestora. Exista doua modalitati distincte de abordare
a acestei probleme: una care presupune rescrierea completa a hartilor de stari pentru
sub-clase, si o a doua care presupune copierea integrala a hartii de stari a super-clasei
în modelul comportamental al sub-claselor, acestea neputând fi modificate decât prin
respectarea unor restrictii bine precizate. Oferirea unui suport de automatizare a
ultimului proces poate conduce la dezvoltarea de aplicatii orientate-obiect concurente
mai robuste si care permit tratarea anomaliilor de mostenire.
150

6. Concluzii
Unificarea conceptelor programarii orientate-obiect cu mecanismele specifice
programarii concurente reprezinta o preocupare constanta în lumea informaticii în
ultimele doua decenii. Aceasta preocupare este justificata de puterea ridicata de
modelare, proprie limbajelor orientate-obiect, si puterea de calcul, proprie limbajelor
concurente, care au facut ca limbajele de programare orientate-obiect concurente sa
fie aplicabile într-un numar însemnat de domenii.
Din nefericire, combinarea concurentei cu mecanismele orientate-obiect nu
este un proces trivial, cercetarile în domeniu evidentiind existenta unor conflicte între
conceptele introduse de catre fiecare filozofie de programare în parte. Unul dintre
cele mai importante conflicte determinate este cel dintre mecanismele de specificare a
sincronizarii activitatilor concurente si mecanismul de mostenire, conflict întâlnit în
literatura sub numele de anomalie de mostenire.
6.1. Rezultate obtinute
Scopul tezei este acela de a defini si valida un formalism vizual de modelare a
aplicatiilor orientate-obiect concurente. Definirea unui astfel de formalism se bazeaza
pe o analiza riguroasa a modelelor de obiecte concurente dezvoltate pâna în prezent si
a neajunsurilor care le caracterizeaza. Acesta este si motivul pentru care teza contine
un prim capitol în care s-a realizat o sinteza a limbajelor de programare orientate-
obiect concurente imperative dezvoltate pâna în prezent. Fiecare model de concurenta
implementat într-un astfel de limbaj de programare a fost analizat pe baza unui set
consistent de principii de proiectare. De asemenea, pentru fiecare model de
151

concurenta a fost propusa o extensie a limbajului C++ si a fost prezentat un exemplu
de implementare a unei cozi cu numar finit de elemente.
Neajunsurile determinate în mod unitar la nivelul modelelor de obiecte
concurente au stat la baza definirii notiunii de anomalie de reutilizare. S-a aratat ca
anomaliile de reutilizare reprezinta un concept care surprinde atât anomaliile de
mostenire cât si conflictele care apar între mecanismele de specificare a concurentei si
relatiile de asociere, agregare si delegare între obiecte. Anomaliile de reutilizare sunt
modelate prin extinderea unui sistem formal utilizat în clasificarea mecanismelor de
mostenire în programarea orientata-obiect concurenta.
Tratarea formala a anomaliilor de reutilizare a permis determinarea unui model
de obiecte concurente general care sta la baza definirii unui formalism vizual de
modelare. Acest formalism reprezinta o extensie a hartilor de stari definite pentru
modelarea comportamentului sistemelor reactive. Formalismul vizual propus este un
formalism executabil si el a fost numit harta de stari scalabila.
În finalul tezei este descrisa implementarea unui instrument de modelare a
aplicatiilor orientate-obiect concurente. Acest instrument, numit ActiveCASE,
valideaza executabilitatea hartilor de stari scalabile si realizeaza generarea automata
de cod sursa în limbajul C++, utilizând o ierarhie de clase concurente proprie. De
asemenea instrumentul permite simularea si depanarea grafica a executiei aplicatiilor
orientate-obiect concurente.
6.2. Perspective
6.2.1. Anomalii de reutilizare
Problema eliminarii anomaliilor de reutilizare din limbajele de programare
orientate-obiect concurente ramâne în continuare deschisa. Notiunile de tip introduse
în modelele obiect dezvoltate pâna în prezent nu rezolva aceasta problema. Solutiile
de ameliorare a efectelor acestor anomalii propuse în teza vizeaza izolarea si
separarea codului contrângerilor de sincronizare de codul de implementare a
functionalitatii, precum si generarea automata de cod sursa.
O alta posibila abordare de ameliorare a anomaliilor de reutilizare este aceea
de introducere a unui mecanism de sub-tipizare care nu conserva comportamentul.
152

Astfel, adaugarea de noi operatii în cadrul unei clase nu va conduce în mod necesar la
crearea de subtipuri ale tipului initial. Mecanismele fara conservare a
comportamentului sunt mult mai expresive decât cele cu conservare a
comportamentului, si sunt capabile sa trateze mai multe anomalii de mostenire. În
literatura însa sunt foarte putine propuneri de astfel de mecanisme, deoarece ele
implica o multime de probleme cum ar fi negarantarea relatiei de subtipizare sau
necesitatea unor studii în directia tehnicilor de analiza statica si a tehnicilor de
optimizare în vederea eficientizarii programelor.
O alta posibila solutie de reducere a anomaliilor are la baza tot respectarea
principiului separarii codului de interactiune concurenta si consta în construirea de
biblioteci de politici generice de sincronizare si concurenta. Astfel, în locul mostenirii
partii de specificare si coordonare a concurentei dintr-o superclasa, o subclasa va avea
posibilitatea instantierii unei politici particulare. Aceasta abordare poate fi utila în
special în cazul specificarii concurentei interne, unde exista un numar relativ restrâns
de politici utilizate (cum ar fi cititori/scriitor, prioritatea cititorilor etc).
6.2.2. Modelarea si simularea aplicatiilor orientate-obiect concurente
Hartile de stari scalabile reprezinta un formalism ce permite modelarea
comportamentului obiectelor concurente ce corespund modelelor obiect care
utilizeaza mecanisme de sincronizare orientate pe încapsulare. Astfel, receptionarea
unui mesaj care nu poate fi tratat la un moment dat nu implica ignorarea acestuia, el
fiind stocat într-o coada în vederea tratarii sale ulterioare. Exista însa cazuri
particulare de mesaje care necesita o planificare speciala, planificare ce cade în
sarcina gestionarului de mesaje. Prin urmare, una dintre posibilele extensii ale
hartilor de stari scalabile consta în capacitatea de modelare a planificarii mesajelor.
De asemenea, mostenirea hartilor de stari scalabile reprezinta un alt subiect
viitor de studiu. Automatizarea acestui proces, impunerea unor restrictii de
modificare a hartilor de stari mostenite precum si propagarea modificarilor hartilor de
stari ale sub-claselor în descendentii acestora pot conduce la controlarea si/sau
eliminarea conflictelor între mecanismul de mostenire si cel de sincronizare
concurenta.
153

Simularea executiei obiectelor active poate fi îmbunatatita la rândul sau în
scopul unei testari riguroase si a unei depanari eficiente a aplicatiilor orientate-obiect
concurente. Astfel, componentele intrumentului ActiveCASE utilizate în simulare
vor putea fi extinse pentru a permite blocarea executiei aplicatiei sau a unui anumit
obiect la un moment dat, transmiterea de mesaje din afara aplicatiei sau chiar
parcurgerea inversa a executiei aplicatiei.
De asemenea se vor avea în vedere realizarea de componente care sa verifice
corectitudinea executiei aplicatiei prin determinarea situatiilor de impas sau încalcarea
proprietatii de vivacitate a activitatilor obiectelor precum si posibilitatea de rezolvare
a acestora în timpul executiei aplicatiei simulate.
154

Bibliografie
[AAR96] Amund Aarsten, Davide Brugali, Giuseppe Menga, Designing
Concurrent and Distributed Control Systems: an Approach Based on
Design Patterns, Communication of ACM - Special Issue on Design
Patterns, oct. 1996
[AGH86] Gul Agha, Actors: A Model of Concurrent Computation in Distributed
Systems, MIT Press, Cambridge, 1986
[AKS94] M. Aksit, J. Bosch, W. van der Sterren, L. Bergmans, Real-Time
Specification Inheritance Anomalies and Real-Time Filters, Proceedings
of ECOOP'94, Lecture Notes in Computer Science, vol. 821, Bologna,
Italia, Springer-Verlag, p.386-407, iulie 1994
[AME87] Pierre America, „POOL-T: A Parallel object-oriented language”, in
Object Oriented Concurrent Programming, A. Yonezawa and M. Tokoro
eds., MIT Press, 1987
[AME90] Pierre America, Designing an object-oriented programming language
with behavioural subtyping, Foundations of Object-Oriented Languages,
Lecture Notes in Computer Science, vol. 489, Noordwijkerhout, Olanda,
Springer-Verlag, p. 60-90, iunie 1990
[AND93] G. R. Andrews, R. A. Olsson, The SR Programming Language:
Concurrency in Practice, Benjamin/Cummings Publishing Company,
1993
[ATK95] Colin Atkinson, Michel Izygon, ION A Notation for the Graphical
Depiction of Object Oriented Programs, Cooperative agreement ncc 9-
30, NASA, iul. 1995, disponibil pe Internet la adresa
http://ricis.cl.uh.edu/atkinson/ion/.
[BAQ95] C. Baquero, R. Oliveira, F. Moura, Integration of Concurrency Control
in a Language with Subtyping and Subclassing, Usenix COOTS’95,
Monterey, CA, 1995
[BAR98] F. Barbier, H. Briand, B. Dano, S. Rideau, The Executability of Object-
Oriented Finite State Machines, The Journal of Object-Oriented
Programming, 11(4), p. 16-24, iul./aug. 1998
155

[BEE94] Michael von der Beeck, A Comparison of Statecharts Variants, Formal
Techniques in Real-Time and Fault-Tolerant Systems, Lecture Notes in
Computer Science, vol. 863, Springer-Verlag, New York, p 128-148,
1994
[BER92] G. Berry, G. Gonthier, The Esterel synchronous programming language:
Design, semantics, implementation, Science of Computer Programming,
19(2), p. 87-152, 1992
[BER94] Lodewijk M. J. Bergmans, Composing Concurrent Objects, teza
doctorat, Twente University, iunie 1994
[BLO79] T. Bloom, Evaluating synchronization mechanisms, Proc. of the 7th
Symposium on Operating Systems Principles, p. 24-32, Pacific Grove,
CA, dec. 1979
[BLU97] Lazlo Blum, Lazlo Kozma, Specifying Objects in Concurrent Object-
Oriented Systems Using Temporal Logic, International COnference on
Applied Informatics, Eger-Noszvaj, Ungaria, p. 313-322, aug. 1997
[BOI94] Florian Mircea Boian, Sisteme de operare interactive, ed. Libris, Cluj-
Napoca, 1994
[BOO91] Grady Booch, Object Oriented Design With Applications, Benjamin/
Cummings Publishing Company, Inc., Redwood City, California 1991
[BOR95] A. V. Borshchev, Yu. G. Karpov, V. V. Roudakov, COVERS - A Tool
for the Design of Real-Time Concurrent Systems, V. Malyshkin (ed.),
Parallel Computing Technologies, Proceedings of the 3rd International
Conference PACT-95, Lecture Notes in Computer Science, vol. 964,
Springer Verlag, p. 219-233, 1995
[BOZ94a] D. Bozga, D. Chiorean, A. Frentiu, B. Rus, V. Scuturici, D. M. Suciu, D.
Vasilescu, Rocase - CASE Tool for Object-Oriented Analysis and
Design, Research Seminars, Seminar on Computer Science, Univ.
"Babes-Bolyai" Cluj-Napoca, preprint no 5, p. 29-36, 1994
[BOZ94b] D. Bozga, D. Chiorean, A. Frentiu, B. Rus, V. Scuturici, D. M. Suciu, D.
Vasilescu, OOA&D: the Transition Among Models, Research Seminars,
Seminar on Computer Science, Univ. "Babes-Bolyai" Cluj-Napoca,
preprint no 5, p. 37-44, 1994
[BRI93] Jean-Pierre Briot, Object-Oriented Concurrent Programming:
Introducing a New Programming Methodology, Proceedings of the 7th
International Meeting of Young Computer Scientists, 1993
[BRO81] J. D. Brock, W. B. Ackerman, Scenarios: a model of non-deterministic
computation, Formalization of Programming Concepts (Diaz and Ramos
eds), Lecture Notes in Computer Science, vol. 107, Springer-Verlag, p.
252-259, 1981
[CAR90] Denis Caromel, Concurrency: An Object-Oriented Approach, TOOLS-
2, (eds.) J. Bezivin, B. Meyer, J. M. Nerson, 1990, p. 183-197
[CAR93] Denis Caromel, Toward a Method of Object-Oriented Concurrent
Programming, Communication of the ACM, vol. 36, no. 9, sept. 1993,
p. 90-102
156

[CHI96] Dan Chiorean, Instrumente CASE pentru analiza si proiectare orientataobiect,
PC REPORT, 46, p. 24-27, 1996
[CHI97] Dan Chiorean, Iulian Ober, Marian Scuturici, Dan Mircea Suciu,
Present and Perspectives in the Object-Oriented Analysis & Design -
The RO-CASE Experience, The Third International Symposium in
Economic Informatics, p. 23-29, Bucharest, mai 1997
[COL92] D. Coleman, F. Hayes, S. Bear, Introducing Objectcharts or How to Use
Statecharts in Object-Oriented Design, IEEE Transaction on Software
Engineering, Vol. 18, No. 1, p. 9-18, ian 1992
[COO89] W. Cook, J. Palsberg, A denotational semantics of inheritance and its
correctness, OOPSLA'89, p. 433-443, New Orleans, 1989
[COO94] Steve Cook, John Daniels, Object Systems. Object-Oriented Modeling
with Syntropy, Prentice Hall, 1994
[CRN97a] L. Crnogorac, A. Rao, K. Ramamohanarao, Analysis of Inheritance
Mechanisms in Agent-Oriented Programming, Proceedings of IJCAI'97,
p. 647-652, Nagoya, Japonia, aug. 1997
[CRN97b] L. Crnogorac, A. Rao, K. Ramamohanarao, Inheritance Anomaly - a
Formal Treatment, FMOODS'97, p.319-334, Anglia, iul. 1997
[CRN98] L. Crnogorac, A. Rao, K. Ramamohanarao - Classifying Inheritance
Mechanisms in Concurrent Object-Oriented Programming, ECOOP '98,
p. 571-600, 1998
[DAH67] O.-J. Dahl, K. Nygaard, SIMULA- A language for Programming and
Description of Discrete Event Systems, Norwegian Computing Center,
Forskningveien 1B, 5th edition, Oslo 3, Norvegia, sept. 1967
[DIJ68] E. W. Dijkstra, Co-operating sequential processes, Programming
Languages, p. 43-112, 1968
[DOR96] Dov Dori, Unifying System Structure and Behavior Through Object-
Process Analysis, The Journal of Object-Oriented Programming, 9(4), p.
66-73, iul./aug. 1996
[DOU99] Bruce Powel Douglass, Doing Hard Time. Developing Real-Time
Systems with UML, Objects, Frameworks and Patterns, Addison-
Wesley, 1999
[ELE91] Petru Eles, Horia Ciocârlie, Programarea concurenta în limbaje de nivel
înalt, Editura Stiintifica, Bucuresti, 1991
[ELI92] Giuseppe Elia, Giuseppe Menga, Mario Cavalotto, Object Oriented
Analysis and Design of Distributed Concurrent Systems, Technical
Report grant 89.00039.69, Dip. di Automatica e Informatica del
Politecnico di Torino, 1992
[FER95] Szabolcs Ferenczi, Guarded Methods vs. Inheritance Anomaly /
Inheritance Anomaly Solved by Nested Guarded Method Calls,
SIGPLAN Notices 30(2): 49-58, 1995
157

[FRO92] Svend Frølund, Inheritance of Sinchronization Constraints in
Concurrent Object-Oriented Programming Languages, Proceeding of
ECOOP'92, L. Madsen editor, Lecture Notes in Computer Science, vol.
615, p. 185-196, Springer-Verlag, Utrecht, Netherlands, 1992
[GAN93] D. Gangopadhyay, S. Mitra, ObjChart: Tangible Specification of
Reactive Object Behavior, Proceedings of ECOOP'93, Oscar Nierstrasz
(ed.), LNCS 707, Springer Verlag, p. 432-457, 1993
[GEO96] Horia Georgescu, Programare concurenta. Teorie si aplicatii, Editura
Tehnica, Bucuresti, 1996
[GIR97] Alain Girault, Bilung Lee, Edward A. Lee, Hierarchical Finite State
Machines with Multiple Concurrency Models, Technical Memorandum
University of California at Berkeley, aug. 1997
[GOL83] A. Goldberg, D. Robson, Smalltalk-80: The Language and its
Implementation, Addison-Wesley, 1983
[HAN72] P. Brinch Hansen, Structured multiprogramming, Communications of
the ACM, 15(7), p. 574-578, iulie 1972
[HAN73] P. Brinch Hansen, Concurrent programming concepts, ACM Computing
Surveys, 5(4), p. 223-245, dec. 1973
[HAR85] D. Harel, A. Pnueli, On the Development of Reactive Systems, Logics
and Models of Concurrent Systems, NATO, ASI-13, Springer-Verlag, p.
477-498, 1985
[HAR87] David Harel, Statecharts: A Visual Formalism for Complex Systems,
Science of Computer Programming, vol.8, no. 3, p. 231-274, iun. 1987
[HAR96] D. Harel, A. Naamad, The STATEMATE Semantics of Statecharts, ACM
Transaction on Software Engineering and Methodology, 5(4), p. 293-
333, oct. 1996
[HAR97] David Harel, Eran Gery, Executable Object Modeling with Statecharts,
IEEE Computer, 0018-9162/97, p. 31-42, iulie 1997
[HEN97] Brian Henderson-Sellers, Evaluating Third Generation Object-Oriented
Software Development Approaches, predat la "Information and Software
Technology", mai 1997
[HOA74] C. A. R. Hoare, Monitors: an Operating System Structuring Concepts,
Communications of the ACM, no. 17(10), p. 549-557, oct. 1974
[HOA85] C. A. R. Hoare, Communicating Sequential Processes, Prentice-Hall
International Series in Computer Science, Prentice-Hall, 1985
[HOR83] E. Horowitz, Fundamentals of Programming Languages, Springer
Verlag, 1983
[HUI88] C. Huizing, R. Gerth, W. P. de Roever, Modelling Statecharts behaviour
in a fully abstract way, LNCS, vol. 299, Springer Verlag, p. 271-294,
1988
[HUI91] C. Huizing, Semantics of Reactive Systems: Comparison and Full
Abstraction, teza de doctorat, Technical University Eindhoven, Olanda,
1991
158

[HUT87] N. C. Hutchinson, R. K. Raj, A. P. Black, H. M. Levy, E. Jul, The
Emerald programming language report, Technical Report 87-10-07,
Department of Computer Science, University of Washington, Seattle,
oct. 1987
[iLO87] i-Logix Inc., The Languages of STATEMATE, în "Documentation for the
STATEMATE System", 1987
[JAC92] Ivar Jacobson, M. Christerson, P. Jonsson, G. Overgaard, Object-
Oriented Software Engineering - A Use Case Driven Approach,
Addison-Wesley/ ACM Press, 1992
[KAF88] D. G. Kafura, K. H. Lee, Inheritance in Actor Based Concurrent Object-
Oriented Languages, Technical Report TR 88-53 Departement of
Computer Science Virginia polytechnic Institute and State university,
1988
[KAF90] D. Kafura, K. H. Lee, ACT++: Building a concurrent C++ with Actors,
Journal of Object Oriented Programming, 3(1), p. 25-37, mai 1990
[KAF93] D. Kafura, M. Mukherji, G. Lavender, ACT++ 2.0: A Class Library for
Concurrent Programming in C++ Using Actors, Journal of Object
Oriented Programming, 6(3), p. 45-53, 1993
[KES77] J. L. W. Kessels, An alternative to event queues for synchronization in
monitors, Communications of the ACM, no. 20 (7), p. 500-503, iul.
1977
[KRA90] S. Kralowiak, M. Meysembourg, H. Nguyen Van, M. Riveill, C. Roisin,
X. Rousset de Pina, Design and implementation of an object-oriented,
strongly typed language for distributed applications, Journal of Object
oriented Programming, 3 (3), p. 11-22, sept./oct. 1990
[LEC96] Ulrike Lechner, Christian Lengauer, Friederike Nickl, Martin Wirsing,
(Objects + Concurrency) & Reusability - A Proposal to Circumvent the
Inheritance Anomaly, Proceedings of ECOOP'96, Lecture Notes in
Computer Science, vol. 1098, p. 232-247, Springer-Verlag, Linz,
Austria, 1996
[LEC97] Ulrike Lechner, Object-Oriented Specification of Distributed Systems,
Universität Passau, Fakultät für Mathematik und Informatik, teza
doctorat, iunie 1997
[LÖH93] Klaus-Peter Löhr, Concurrency annotations for reusable software,
Communication of the ACM , 36(9), p81-89, sep. 1993
[MAC96] Stuart Maclean, Sean Smith, Direct Mapping of Object-Oriented
Analysis Models into C++ Using Asynchronous Messaging, The Journal
of Object-Oriented Programming, 9(5), p. 24-31, sept. 1996
[MAI97] Christoph Maier, Luis Mandel, Object-Oriented Development of
Distributed Systems – a Survey, dec. 1997, disponibil pe Internet la
adresa http://www.fast.de/Projekte/forsoft/oosurvey/index.html
[MAN74] Z. Manna, Mathematical Theory of Computation, McGraw-Hill, 1974
159

[MAT90] Satoshi Matsuoka, Ken Wakita, Akinori Yonezawa, Sinchronization
Constraints With Inheritance: What Is Not Possible - So What Is?,
Technical Report 10, Department of Information Science, University of
Tokyo, 1990
[MAT93] Satoshi Matsuoka, Akinori Yonezawa, Analysis of Inheritance Anomaly
in Object-Oriented Concurrent Programming Languages, Research
Directions in Concurrent Object-Oriented Programming, p.107-150,
MIT Press, Cambridge, 1993
[MCH94] Ciaran McHale, Synchronization in Concurrent, Object-Oriented
Languages: Expressive Power, Genericity and Inheritance, teza
doctorat, Department of Computer Science, Trinity College, Dublin 2,
Irlanda, oct. 1994
[MES93] J. Meseguer, Solving the inheritance anomaly in concurrent objectoriented
programming, Proceedings of ECOOP'93, Lecture Notes in
Computer Science, vol. 707, Kaiserlautern, Germania, Springer-Verlag,
p.220-246, iulie 1993
[MEY93] Bertrand Meyer, Systematic Concurrent Object-Oriented Programming,
Communication of the ACM, Vol 36, no9, 1993, p.56-80
[MIT94] S. E. Mitchel, A. J. Wellings, Synchronisation, Concurrent Object-
Oriented Programming and the Inheriyance Anomaly, jun. 1994
[MOL00] Grigor Moldovan, Limbaje formale si tehnici de compilare, Centrul de
Formare Continua si Învatamânt la Distanta, Univ. “Babes-Bolyai”,
Cluj-Napoca, 2000
[MOL97] Grigor Moldovan, Limbaje formale si teoria automatelor, ed. Mesagerul,
Cluj-Napoca, 1997
[NIE87] O. Nierstrasz, Active objects in Hybrid, Proc. of OOPSLA'87, Conf. on
Object Oriented Programming Systems, Languages and Applications,
Orlando, Florida, ACM SIGPLAN Notices 22(12), p. 243-253, oct. 1987
[OBE99] Iulian Ober, Ileana Stan, On the Concurrent Object Model of UML,
Proceedings of EuroPar'99, Toulouse. Lecture Notes in Computer
Science, No. 1685, Springer Verlag, 1999
[OMG99] Object Management Group, OMG Unified Modeling Language
Specification, ver. 1.3, iunie 1999 disponibil pe Internet la adresa
http://www.rational.com/
[PAP89] Michael Papathomas, Concurrency Issues in Object-Oriented
Programming Languages, in D. Tsichritzis, editor, Object Oriented
Development, p. 207-245, University of Geneva, Switzerland, 1989
[PAP92] Michael Papathomas, Language Design Rationale and Semantic
Framework for Concurrent Object-Oriented Programming, teza
doctorat, Dept. of Computer Science, University of Geneva, 1992
[PAP96] Michael Papathomas, ATOM: An Active Object Model for Enhancing
Reuse in the Development of Concurrent Software, Research Report,
Ecole Nationale Superieure d'Informatique et de Mathematique
Appliques de Grenoble, France, nov. 1996
160

[PAP97] Michael Papathomas, Anders Andersen, Concurrent Object-Oriented
Programming in Python with ATOM, Proceedings of the 6th
International Python Conference, California, oct. 1997
[PAR80] D. M. R. Park, Concurrency and Automata on Infinite Sequences,
Lecture Notes in Computer Science, Vol 104, Springer Verlag, 1980.
[PHI95a] Michael Phillipsen, Imperative Concurrent Object-Oriented Languages,
Technical Report TR-95-049, International Computer Science Institute,
Berkeley, aug. 1995
[PHI95b] Michael Phillipsen, Imperative Concurrent Object-Oriented Languages:
An annotated bibliography, Technical Report TR-95-049, International
Computer Science Institute, Berkeley, aug. 1995
[PIE95] Benjamin C. Pierce, Fundational Calculi for Programming Languages,
CRC Handbook of Computer Science and Engineering, 1995
[PUN96] Franz Puntigam, Coordination Requirements Expressed in Types for
Active Objects, ECOOP p.367-388, 1996
[QUI97] P. H. Quiros, Jose M. Olmo Millan, Inheritance Anomaly in CORBA
Multithreaded Environments, Theory and Practice of Object Systems,
no. 1/3, 1997
[REI96] Stephan Reitzner, Synchronizing Classes: Splitting Inheritance
Concepts, Technical Report, Computer Science Department, Friedrich
Alexander University, Nürnberg, iul. 1996
[RUM91] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy,
William Lorensen, Object-Oriented Modeling and Design, Prentice Hall,
Englewood Cliffs, 1991
[RUM93] J. Rumbaugh, Controlling Code: How to implement dynamic models,
The Journal of Object-Oriented Programming, 6(2), p. 25-30, feb. 1993
[RUM96] J. Rumbaugh, A State of Mind: Modeling Behavior, The Journal of
Object-Oriented Programming, 9(4), p. 6-12, iul./aug. 1996
[SCH86] C. Schaffert, T. Cooper, B. Bullis, M. Kilian, C. Wilpolt, An
introduction to Trellis/Owl, Proc. of OOPSLA'86, Conference on
Object-Oriented Programming Systems, Languages and Applications,
Portland, Oregon, p. 9-15, sept 1986
[SCU97] Marian Scuturici, Dan Mircea Suciu, Mihaela Scuturici, Iulian Ober,
Specification of active objects behavior using statecharts, Studia
Universitatis "Babes Bolyai", Informatica, Vol. XLII, Nr. 1, p.19-30,
1997
[SET89] Ravi Sethy, Programming Languages Concepts and Constructs,
Addison-Wesley, 1989
[SHL88] S. Shlaer, S. J. Mellor, Object Oriented Systems Analysis: Modeling the
Worl in Data, Yourdon Press Computing Series, 1988
[STR91] Bjarne Stroustrup, The C++ Programming Language (second edition),
Addison Wesley, 1991
161

[STU97] Shelly S. Stubbs, D. L. Carver, IPCC++: InterProcess Communication
with C++, The Journal of Object-Oriented Programming, 9(9), p. 31-40,
febr. 1997
[SUC96a] Dan Mircea Suciu, Trei instrumente CASE la ora analizei, PC REPORT,
iul. p. 32-35, 1996
[SUC96b] Dan Mircea Suciu, RO-CASE, PC REPORT, iul. p. 40-41, 1996
[SUC97a] Dan Mircea Suciu, Reuse Anomaly in Object-Oriented Concurrent
Programming, Studia Universitatis "Babes-Bolyai", Informatica, Vol.
XLII, Nr. 2, p. 74-89, 1997
[SUC97b] Dan Mircea Suciu, Limbaje de programare orientate obiect concurente,
PC REPORT, aug. 1997
[SUC98a] Dan Mircea Suciu, Iulian Ober, Contructia sistemelor software -
OPEN/OML, PC REPORT, feb. p. 28-32 1998
[SUC98b] Dan Mircea Suciu, Anomalii de mostenire în programarea orientataobiect
concurenta, referat de doctorat, Universitatea "Babes-Bolyai"
Cluj Napoca, mai 1998
[SUC98c] Dan Mircea Suciu, Modele de concurenta, referat de doctorat,
Universitatea "Babes-Bolyai" Cluj Napoca, septembrie 1998
[SUC98d] Dan Mircea Suciu, Analiza si proiectarea obiectelor concurente, referat
de doctorat, Universitatea "Babes-Bolyai" Cluj Napoca, decembrie 1998
[SUC98e] Dan Mircea Suciu, Application Framework Reuse Using CASE Tools,
Studia Universitatis “Babes Bolyai”, Informatica, Vol. XLIII, Nr. 2, p.
81-92, 1998,
[SUC99] Dan Mircea Suciu, Extending Statecharts for Concurrent Objects
Modeling, Studia Universitatis “Babes Bolyai”, Informatica, Vol. XLIV,
Nr. 1, p. 37-44, 1999
[THO94] Laurent Thomas, Inheritance Anomaly in True Concurrent Object
Oriented Languages: A Proposal, IEEE TENCON'94, p. 541-545, aug.
1994
[TOM89] C. Tomlinson, V. Singh, Inheritance and synchronization with Enabledsets,
Proc. of OOPSLA'89, Conf. on Object-Oriented Programming
Systems, Languages and Applications, New Orleans, Louisiana, p. 103-
112, oct. 1989
[YOK87] Y. Yokote, M.Tokoro, Experience and Evolution of Concurrent
Smalltalk, proceedings OOPSLA '87, ACM, Orlando, Florida, p. 406-
415, dec. 1987
[YON87a] Akinori Yonezawa, Jean-Pierre Briot, Inheritance and Synchronization
in Concurrent Object Oriented Programming, Proceedings of the
European Conference on Object-Oriented Programming (ECOOP'87),
Lecture Notes in Computer Science, no. 276, p. 32-40, Springer -
Verlag, 1987
162

[YON97b] A. Yonezawa, E. Shibayama, T. Takada, Y. Honda, Modeling and
Programming in an Object-Oriented Concurrent Language ABCL/1,
Object-Oriented Concurrent Programming, Yonezawa and Tokoro eds.,
The MIT Press, Cambridge, Massachusetts, p. 88-89, 1987
[ZEN97a] Nanshan Zeng, Stephen R. Schach, A Critique of "Inheritance in
Concurrent Object-Oriented Programming: Doing more with ATOM",
Technical Report 97-01, Department of Computer Science Vanderbilt
University, Nashville, USA, febr. 1997
[ZEN97b] Nanshan Zeng, Stephen R. Schach, A New Approach to the Inheritance
Anomaly, submitted for publication, 1997
163

Anexa A. Notatii matematice
A.1. Multimi
Fie multimile M, M1, M2. Am utilizat urmatoarele notatii pentru a exprima
operatii asupra multimilor:
- ? reprezinta multimea vida,
- M1 ? M2 reprezinta reuniunea multimilor M1 si M2,
- M1 ? M2 reprezinta intersectia multimilor M1 si M2,
- M1 \ M2 reprezinta diferenta multimilor M1 si M2,
- M1 ? M2 reprezinta incluziunea multimilor M1 si M2,
- M1 ? M2 reprezinta produsul cartezian al multimilor M1 si M2,
- ? M? reprezinta cardinalul multimii M,
- ? (M) reprezinta multimea partilor lui M,
- M* reprezinta multimea secventelor de zero sau mai multe elemente din M.
Am utilizate urmatoarele multimi particulare:
- ( + ) - multimea numerelor naturale (strict pozitive),
- - multimea valorilor booleene, cu elemente {true, false}.
A.2. Relatii binare
Fie R o relatie binara definita pe multimea M, notata (M, R). Am facut referire
în cadrul tezei la urmatoarele proprietati ale relatiilor binare:
- reflexivitate: ? x ? M (x, x) ? R
164

ar fi n ? N.
- simetrie: ? x, y ? M (x, y) ? R ? (y, x) ? R
- antisimetrie: ? x, y ? M (x, y) ? R ? (y, x) ? R ? x = y,
- tranzitivitate: ? x, y, z ? M (x, y) ? R ? (y, z) ? R ? (x, z) ? R.
Relatii binare particulare:
- preordine: relatie reflexiva si tranzitiva,
- ordine partiala: relatie reflexiva, antisimetrica si tranzitiva,
- ordine totala: ordine partiala si ? x, y ? M, (x, y) ? R ? (y, x) ? R,
- echivalenta: relatie reflexiva, simetrica si tranzitiva.
Fie N o submultime a multimii M (N ? M).
Un element m ? M este limita inferioara a multimii N daca (m, n) ? R oricare
O limita inferioara m pentru N este cea mai mare limita inferioara pentru N
daca si numai daca pentru fiecare limita inferioara m’ a lui N avem (m’, m) ? R.
pN.
A.3. Functii
Atunci când exista, vom nota cea mai mare limita inferioara a multimii N cu
O functie este o aplicatiei f : M1 ? M2 care asociaza fiecarui element x ? M1
un element unic y ? M2. M1 poarta numele de domeniu de definitie, iar M2 co-
domeniul sau domeniul de valori al functiei f.
Fie n ? si xi ? M1 si yi ? M2 pentru 1? i ? n. Vom nota cu f[y1/x1,..., yn/xn]
functia g : M1 ? M2 definita astfel:
? yi
, daca x ? xi
g(
x)
? ?
.
? f ( x),
in rest
165

Anexa B. Notatii UML
Unified Modeling Language (UML) este un limbaj de specificare si modelare
orientata-obiect a entitatilor si relatiilor care compun sistemele informatice complexe.
El a fost realizat în urma cererii de standardizarea propuse de consortiul international
Object Management Group (OMG), si a devenit limbajul standard de modelare la data
de 17 noiembrie 1997. Denumirea limbajului provine din faptul ca el a rezultat în
urma unificarii a trei importante metode de analiza si proiectare a aplicatiilor
orientate-obiect: Object Oriented Design (OOD - [BOO91], Object Modeling
Technique (OMT - [RUM91]) si Objectory ([JAC92]).
UML a fost conceput ca un limbaj universal care sa fie utilizat la modelarea
sistemelor indiferent de tipul si scopul pentru care acestea au fost construite, la fel
cum limbajele de programare, sau mai larg limbajele naturale sunt folosite în cele mai
diverse domenii.
UML este un limbaj grafic, vizual, care alaturi de definirea unor concepte de
modelare furnizeaza si un set de notatii grafice de reprezentare a acestora. Desi gama
de modele are pot fi realizate cu UML este bogata, în cele ce urmeaza sunt prezentate
doar conceptele si notatiile corespunzatoare modelelor structurale si
comportamentale. Acestea au fost utilizate pe parcursul tezei în constructia unor
exemple. În particular, modelarea comportamentala este analizata în detaliu în cadrul
capitolului patru, ea stând la baza rezultatelor obtinute în teza în directia modelarii
comportamentului obiectelor active.
166

B.1. Diagrame de clase
UML utilizeaza diagramele de clase pentru descrierea statica, structurala a
unui sistem. Diagramele de clase specifica strutura claselor si relatiile existente între
acestea. Clasele în UML se reprezinta grafic sub forma unor dreptunghiuri care
contin în partea superioara numele clasei. Optional dreptunghiul de reprezentare a
unei clase poate contine doua compartimente speciale, care detin o lista de proprietati
(atribute), respectiv o lista de operatii (metode).
Tipurile de relatii între clase definite în UML utilizate în cadrul tezei sunt:
asocierea, agregarea, compunerea si generalizarea.
Asocierile sunt relatii care permit specificarea comunicarii între obiecte prin
intermediul mesajelor. Reprezentarea grafica a asocierilor se realizeaza prin linii
simple sau linii compuse din segmente care unesc doua clase. În lipsa unei specificari
explicite, asocierile sunt relatii bidirectionale si permit transmiterea de mesaje în
ambele directii. Atunci când transmiterea de mesaje se realizeaza strict într-o directie,
acest lucru este specificat prin intermediul unei sageti în capatul asocierii
corespunzator clasei de obiecte care receptioneaza mesajele.
simboluri pentru
vizibilitate
simbol mostenire
clase
proprietati
operatii
167
multiplicitate
simbol agregare
nume de rol
Figura B.1. Principalele notatii utilizate în diagramele de clase UML
Asocierea este o relatie între clase. O instanta a unei asocieri poarta numele de
legatura. Legaturile au loc între obiectele rezultate în urma instantierii claselor aflate
în relatia de asociere.
La ambele capete ale unei asocieri pot fi afisate anumite valori întregi, sau
intervale de valori, care reprezinta multiplicitatea relatiei si specifica numarul

obiectelor care sunt implicate în respectiva relatie. În lipsa unei specificari explicite,
multiplicitatea este considerata implicit 1.
Asocierile pot avea atasat un nume. Rolul jucat de obiectele fiecarei clase în
cadrul asocierii poate fi descris optional prin intermediul unor nume de rol, atasate la
capetele asocierii.
Agregarea este o relatie de asociere particulara, si ea specifica o legatura de tip
parte-întreg între obiecte. Aceasta relatie este utilizata atunci când un obiect contine,
în mod logic sau fizic, un alt obiect. Agregarea se reprezinta grafic la fel ca si
asocierea, utilizând în plus un romb alb în capatul corespunzator clasei care specifica
obiectele proprietar.
Compunerea este o forma mai puternica de agregare si ea specifica faptul ca
obiectele proprietar sunt responsabile cu crearea si distrugerea obiectelor pe care le
contin. Compunerea se reprezinta grafic ca si o agregare, dar culoarea rombului este
neagra.
În UML relatia de generalizare specifica mostenirea între clase. Ea se
reprezinta grafic prin intermediul unei linii între doua clase ce contine la capatul
corespunzator clasei parinte un triunghi cu unul din vârfuri îndreptat spre aceasta.
B.2. Harti de stari
În UML hartile de stari sunt utilizate în descrierea comportamentului
obiectelor apartinând unui clase.
O stare (concreta) este caracterizata de valorile proprietatilor unui obiect si de
multimea mesajelor care pot fi acceptate de catre acest obiect la un moment dat. O
stare contine descrierea unui invariant de stare (conditie logica adevarata pentru toate
obiectele care se afla în starea respectiva), si a trei proceduri speciale: entry, exit si do.
Aceste proceduri descriu secventele de actiuni care vor fi executate în momentul în
care un obiect intra (entry), paraseste (exit) sau se afla (do) în starea respectiva. O
stare se reprezinta grafic prin intermediul unui dreptunghi cu colturile rotunjite,
afisând în partea superioara un nume de stare. În partea inferioara a dreptunghiului
optional poate exista un compartiment care contine expresiile ce definesc invariantul
de stare si cele trei proceduri speciale.
O tranzitie exprima o situatie în care un obiect poate trece dintr-o stare în alta.
Tranzitiile se reprezinta grafic prin intermediul unor arce de cerc, linii simple sau linii
168

poligonale orientate si (optional) etichetate care unesc doua stari, numite stare sursa,
respectiv destinatie. Eticheta unei tranzitii este formata dintr-o signatura de mesaj, o
conditie (expresie logica) si o secventa de activitati care au loc în momentul
declansarii tranzitie. Pentru un obiect oarecare o tranzitie este declansata atunci când
obiectul se afla în starea sursa a acesteia, executa operatia corespunzatoare mesajului
si este îndeplinita conditia specificata în eticheta.
Hartile de stari permit reprezentarea ierarhica a starilor unui obiect prin
intermediul starilor compuse (întâlnite si sub denumirea de XOR-stari, stari abstracte
sau super-stari). Starile compuse contin un numar finit de stari simple sau compuse.
Un obiect aflat într-o stare compusa se va afla în una si numai una din sub-starile
acesteia. Starile compuse se reprezinta grafic la fel ca starile simple, la care se adauga
un compartiment special, localizat între numele starii si compartimentul destinat
afisarii invariantilor de stare si a procedurilor speciale. În cadrul acestui
compartiment sunt reprezentate grafic toate sub-starile corespunzatoare.
stare compusa mesaj
conditie de
declansare
169
activitate
pseudo-stare
terminala
Figura B.2. Etichetarea tranzitiilor în hartile de stari UML
Hartile de stari permit modelarea de comportamente paralele ale unui obiect
prin intermediul starilor ortogonale (denumite si AND-stari sau stari concurente).
Starile ortogonale sunt formate din mai multe componente ortogonale, fiecare dintre
acestea continând diverse sub-stari. Un obiect aflat într-o stare ortogonala se va afla
de fapt în câte o stare corespunzatoare fiecarei componente ortogonale a acesteia.
Reprezentarea grafica a starilor ortogonale este asemanatoare reprezentarii starilor
compuse, componentele ortogonale ale acestora fiind delimitate prin linii punctate
verticale.

mesaj pseudo-stare
tranzitie
stare compusa initiala
pseudo-stare
istoric
invariant de
stare
170
componente
ortogonale
stare ortogonala
Figura B.3. Principalele notatii ale hartilor de stari UML
De asemenea, hartile de stari introduc o serie de stari speciale, numite pseudo-
stari. Pseudo-starile sunt stari intermediare care permit conectarea mai multor
tranzitii în scopul descrierii unor situatii complexe de modificare a starii concrete a
unui obiect. Cele mai importante pseudo-stari definite în UML sunt:
- starea initiala - indica sub-starea implicita în care intra un obiect în cazul
declansarii unei tranzitii a carei stare destinatie este o stare compusa. Se
reprezinta grafic sub forma unui cerc plin.
- starea finala - indica parasirea contextului unei stari compuse. În cazul în
care starea finala apartine starii compuse de la cel mai înalt nivel al
ierarhiei de stari (este radacina ierarhiei de stari) intrarea o tranzitie spre
aceasta stare semnifica distrugerea obiectului.
- starea istoric - este utilizata atunci când sub-starea initiala a unei stari
compuse nu este fixata decât pentru prima tranzitie spre aceasta stare
compusa, ea fiind data mai apoi de ultima sub-stare activa. În figura B.3 o
prima tranzitie spre starea Pornita implica activarea sub-starii Normal,
urmatoarele tranzitii activând sub-starea (Normal sau Marsalier) activa în
momentul ultimei parasiri a starii Pornita.