Li Cent A Stable Matching

UNIVERSITATEA ALEXANDRU IOAN CUZA IAI
FACULTATEA DE INFORMATIC
Lucrare de licen
Cadru de lucru pentru rezolvarea problemelor de tip

Stable-Matching
propus de:
Student: Andreea-Eveline Giosanu

Coordonator tiinific: Lect. dr. Frsinaru Cristian
Sesiunea: iulie 2017

UNIVERSITATEA ALEXANDRU IOAN CUZA IAI
FACULTATEA DE INFORMATIC
Cadru de lucru pentru rezolvarea problemelor de

tip Stable-Matching
Student: Andreea-Eveline Giosanu

Coordonator tiinific: Lect. dr. Frsinaru Cristian
Sesiunea: iulie 2017

3
DECLARAIE PRIVIND ORIGINALITATEA I RESPECTAREA

DREPTURILOR DE AUTOR
Prin prezenta declar c Lucrarea de licen cu titlul Cadru de lucru pentru rezolvarea
problemelor tip Stable-Matching este scris de mine i nu a mai fost prezentat niciodat la
o alt facultate sau instituie de nvmnt superior din ar sau din wstrintate. De ase-
menea, declar c toate sursele utilizate, inclusiv cele preluate de pe Internet, sunt indicate n
lucrare, cu respectarea regulilor de evitare a plagiatului:
toate fragmentele de text reproduse exact, chiar i n traducere proprie din alt
limb, sunt scrise ntre ghilimele i dein referina precis a sursei;
reformularea n cuvinte proprii a textelor scrise de ctre ali autori deine refer-
ina precis;
codul surs, imagini etc. preluate din proiecte open-source sau alte surse sunt uti-
lizate cu respectarea drepturilor de autor i dein referine precise;
rezumarea ideilor altor autori precizeaz referina precis la textul original.
Iai, 3 iulie 2017
Absolvent Andreea Eveline Giosanu
_________________________
(semntura n original)
DECLARAIE DE CONSIMMNT
Prin prezenta declar c sunt de acord ca Lucrarea de licen cu titlul Cadru de lucru
pentru rezolvarea problemelor tip Stable-Matching, codul surs al programelor i celelalte
coninuturi (grafice, multimedia, date de test etc.) care nsoesc aceast lucrare s fie utili-
zate n cadrul Facultii de Informatic. De asemenea, sunt de acord ca Facultatea de Infor-
matic de la Universitatea Alexandru Ioan Cuza din Iai s utilizeze, modifice, reproduc i
s distribuie n scopuri necomerciale programele-calculator, format executabil i surs, reali-
zate de mine n cadrul prezentei lucrri de licen.
Iai, 3 iulie 2017
Absolvent Andreea Eveline Giosanu
_________________________
(semntura n original)
5
Cuprins
Introducere ............................................................................................................................... 6
1 Stable Matching................................................................................................................ 9
1.1 Caracteristici generale .............................................................................................. 9
1.2 One-to-one ............................................................................................................. 10
1.3 One-to-many .......................................................................................................... 19
1.4 Many-to-many ....................................................................................................... 21
1.4.1 Stable - Allocation ................................................................................................. 21
1.4.2 Two-sided Market sau Teachers-Repartition ....................................................... 24
2 Modelarea problemelor de Stable-Matching prin reprezentri XML. Instanierea
problemelor ................................................................................................................................ 27
2.1 Schema XSD a modelului de baz ......................................................................... 27
2.2 Particularitile problemelor definite prin structura XML .................................. 29
2.3 Specificaii importante ........................................................................................... 32
3 Arhitectur i implementare ......................................................................................... 32
3.1 Schema general a funcionrii proiectului .......................................................... 33
3.2 Structura proiectului .............................................................................................. 34
3.3 Detalii de implementare al algoritmilor................................................................ 37
3.4 Serviciul REST ........................................................................................................ 39
3.5 Tehnologii i platforme utilizate ........................................................................... 40
4 Lucrul cu serviciul de Stable-Matching ........................................................................ 42
5 Concluzii i perspective de viitor .................................................................................. 46
Bibliografie ............................................................................................................................. 47
6
Introducere
Motivaie
Problemele de Stable-Matching acoper o mare varietate din situaiile din ziua de

astzi. Problema clasic de construire a unei distribuii stabile ntre entiti din clase diferite
se ntalnete, n general, sub diferite forme n realitate (spre exemplu: distribuirea
studenilor la opionale, a rezidenilor la spitale, a profesorilor la diferite coli etc). n lu-
crarea de fa se vor prezenta diferite variante ale algoritmilor de Stable-Matching, avnd ca
i suport practic implementarea unui cadru de lucru care le trateaz.
Problema construirii unei repartiii stabile a aprut n 1962, introdus de Gale i Shap-
ley, n lucrarea College admissions and the stability of marriage [1] care a dezvoltat ulteri-
or un interes sporit din partea multor cercettori, fiind aplicabil n viaa real.
Dou seturi de entiti, femei i brbai, fiecare element avnd specificat o anumit
list de preferine cu corespondeni din setul opus, se doresc a fi repartizai ntr-un Stable-
Matching. Stabilitatea este dat de inexistena a dou elemente care s-ar prefera reciproc fa
de cei cu care au fost asignai. Varianta iniial a problemei face parte din clasa one-to-one
de instane i trateaz doar cazul unei distribuii ntre dou elemente din clase diferite.
Problema s-a extins i la cazuri mai complexe, one-to-many i many-to-many.
O problema real a fost sesizat n New York, unde, n fiecare an, elevii care ncheiau
clasa a 8-a, trebuiau s depun aplicaii pentru liceul dorit, completnd o list cu cte 5 pre-
ferine. n primul tur, liceele i alegeau preferaii din toi aplicanii iar elevii care nu au fost
acceptai la niciun liceu din cele specificate, intrau n urmtorul tur. Statistica a artat c
majoritatea participanilor care nu aveau performane deosebite nu au ajuns la vreun liceu
menionat n preferinele lor. S-a ajuns, astfel, la construirea unor liste care nu reflectau
neaprat aspiraiile reale ale aplicanilor ci dorina de a fi siguri c vor ajunge la un liceu
7
orecum potrivit din punctul lor de vedere. i, prin urmare, nc din primul tur puteau exista
elevi care s ajung la un liceu mai puin prestigios dei aveau un profil potrivit pentru unul
mai bun, acetia optnd pentru sigurana obinerii unui liceu aproape bun dect pentru a
risca s ajung la un liceu (mai ru) care nu se afla printre preferinele lor. Astfel, s-a
ncercat gsirea unei modaliti noi de distribuii care s reflecte meritele reale ale
aplicanilor [17].
n lucrarea de fa voi prezenta o mare varietate de probleme din aceast clas i voi
arat cum am pus n practic tot ce am studiat din diferite articole care trateaz aceast tem.
Astfel:
- n primul capitol, Stable Matching, am prezentat partea teoretic, att definiii,
tipuri de probleme, exemplificri de instane ct i algoritmii care construiesc
astfel de distribuii stabile;
- n capitolul al doilea, Modelarea problemelor de Stable-Matching, am descris mod-

ul n care am construit structura XML-ului care va transpune diferite instane de
probleme;
- n seciunea Arhitectur i implementare am oferit o imagine de ansamblu a felului

n care a fost construit i organizat proiectul;
- n ultima parte este nfiat modul n care se poate utiliza produsul pus la dis-
poziie prin intermediul serviciului REST.
Contribuii
Proiectul a pornit de la ideea necesitii unui serviciu care s ofere posibilitatea

rezolvrii variaiilor de problemelor ce au ca i scop construirea unei distribuii ntre dou
mulimi de elemente diferite.
8
n realizarea acestui proiect a trebuit s ncep prin citirea documentaiei de

specialitate pentru a putea pune cap la cap o multitudine de algoritmi ce trateaz probleme
din aceeai clas. Documentaia a reprezentat elementul fundamental n conceperea unui
model de structur al proiectului, bineneles, i n construirea reprezentrilor instanelor
sub form de XML. Modelarea instanelor sub form de XML s-a putut realiza i studiind
princiipii eseniale n vederea descoperirii celei mai bune structuri, cum sunt prezentate,
spre exemplu n [12].
Pe lng construirea XML-urilor i implementare algoritmilor, a trebuit s nv i un

framework nou, anume SpringBoot, pentru a putea construi serviciul REST ntr-un mod ct
mai practic pentru a facilita extinderea proiectului n viitor.
9
1 Stable Matching
Problemele de tip Stable-Matching sunt nelese, n domenii precum: matematic,
informatic, tiine economice, ca fiind probleme de construire a unei distribuii stabile
ntre dou seturi de elemente. Stable-Marriage reprezint varianta de baz a problemelor de
acest tip.
Problemele de Stable Matching se mpart n trei clase:

one-to-one (ex: Stable-Marriage)
one-to-many (ex: Hospitals-Residents problem, College-Admission problem,
Courses-Repartition problem)
many-to-many (ex: Stable Allocation, Two-sided Market)
1.1 Caracteristici generale

Notaii:
SM = Stable Matching
M = matching
(1 ) = elementul cu care a fost distribuituit 1 , 1 1 n matching-ul
rezultat (avnd perechea (1 , 1 ), spunem c (1 ) = 1 )
(1 , 1 ) = p, p = nivelul de preferin al elementului 1 pentru 1 , unde
1 1 i 1 2
(1 ) = c, c = capacitatea maxim a elementului, 1 1
Definiie SM:
- M = {1 ,2 ... } un set de n elemente, W = {1 ,2 ... } un set de n
elemente
- M este un matching peste cele 2 seturi de elemente (M, W), reprezentnd un
set de perechi (m, w), unde M i W
- M este stabil dac niciuna dintre perechi nu este pereche blocant, adic
trebuie s fie respectat condiia:
(, ) , , (, )
- (m, w) = dac au loc urmtoarele [3]:
o M(m) w;
o P(m, w) > P(m, M(m));
o P(w, m) > P(w, M(w)).
10
Sensul optimalitii SM-ului

- pentru construirea unui SM, algoritmul de baz are ca i principiu adresarea
propunerilor n funcie de ordinea elementelor n listele de preferine
- aceste propuneri se fac ntr-un singur sens; spre exemplu dac setul M(men)
face propuneri spunem ca SM este men-optimal
- s-a demonstrat c un SM men-optimal este cel mai puin optim dintre toate
configuraiile care ar fi plecat de la propuneri venind din setul opus, deci o
distribuie men-optimal este cel mai puin favorabil pentru setul women [3]
1.2 One-to-one
Vom trata pentru nceput cazul de baz, anume problema Stable-Marriage:
Enun:
Fie 2 seturi, femei (W ) i brbai (M ), fiecare avnd aceeai dimensiune, n. Fiecare
element din cele 2 seturi prezint cte o list, ordonat strict descresctor, cu preferinele
tuturor elementelor corespunztoare setului opus.
Cerin:
S se construiasc un SM peste cele dou seturi.
Exemplificare:
Fie seturile de elemente M = {1 ,2 ,3 }, W = {1 ,2 ,3 }. i urmtoarele liste de

preferine1:
Setul M: Setul W:
P(1 ): 1 , 3 , 2 P(1 ): 1 , 3 , 2
P(2 ): 3 , 1 , 2 P(2 ): 3 , 1 , 2
P(3 ): 3 , 1 , 2 P(3 ): 3 , 2 , 1
Se dorete construcia lui M, unde M = {( , ) | , = 1,3 = 1,3 }

= stabil.
1 Elementele sunt afiate n ordine descresctoare, ex. P (1 , 1 ) > (1 , 3 )

11
Reprezentarea sub form de graf2 a instanei:

n graf sunt desenate arcuri ntre noduri,
1 2 3 reprezennd preferine astfel:
Un arc care pleac din nodul x la
1
un nod y pe linia a se interpreteaz
ca P(a, x) < P (a, y)
2 Analog i pe coloane, un arc care
pleac din nodul a la un nod b, pe o
coloan x, nelegem
3 P(x, b) < P(x, a)
n caz de nu exist un nod la
intersecia unei linii cu o coloan,
se va nelege c cel puin una din
cele 2 elemente (date prin id-ul
coloanei i id-ul liniei) nu are
niciun fel de afinitate pentru
cealalt
Algoritmul GS
Gale i Shapley, n anul 1962, prezentau un algoritm care ar crea un astfel de SM [1];
demonstrnd, chiar, c orice astfel de instn prezint cel puin un SM. Complexitatea timp
a algoritmului este (2 ), n fiind dimensiunea fiecrui set n parte.
Descriere:
Plecnd de la una din mulimile de elemente, se fac, pe rnd, propuneri
Pentru elementul curent, din coada elementelor nc libere, se iau partenerii
preferai n ordine descresctoare
Dac primul element din lista de preferine este liber, atunci se adaug n match-
ul curent perechea (m, w)
n caz contrar, adic elementul w nu este disponibil, fiind deja repartizat cu
altcineva, se va verifica dac nu cumva, w l-ar prefera pe actualul pretendent fa
de cel cu care este deja repartizat, adic (, ) > (, 1 )
2 Reprezentare construit conform indicaiilor prezentate n [2]

12
Dac are loc (, ) > (, 1 ) atunci f va fi distribuit cu b (M = M

{(, )}), iar 1 va fi adugat din nou n coada de elemente libere (F = F 1 ),
urmnd s fac din nou propuneri
Dac nu are loc (, ) > (, 1 ), atunci se va reintra n bucla WHILE(ms
preferences list ) i, n caz de m nc mai are elemente n lista de preferine,
acesta i va face o propunere noului element, urmnd din nou paii descrii mai
sus
Cnd m nu mai are preferine nseamn c a fost refuzat de toate elementele pe
care le-ar fi acceptat, deci nu va mai avea cum s aib vreo pereche, prin urmare
nu l mai adugm n coada de elemente libere
Procesul acesta se va executa pentru toate elementele din F
13
n pseudocod avem:
F = lista elementelor disponible; va fi iniializat cu mulimea elementelor din M
(men)
M = matching-ul ce va fi rezultat, iniial fiind mulimea vid ()
Construcia lui M cu algoritmul GS pentru instana prezentat:
Pasul 1: iniializarea
o M=
o F = {1 , 2 , 3 }
o 1 , 2 , 3 = disponibile
o 1 ,2 ,3 = disponibile
Pasul 2: propunerile
. 1 face propuneri:
o F = F \ 1 = {2 , 3 }
o 1 propune ca i partener pe 1
o 1 este disponibil i l accept pe 1 ca i partener
o M = {(1, 1)}
. 2 face propuneri:
o F = F \ 2 = {3 }
o M = M {(m2, 3 )} = {(1, 1 ), (2, 3 )}
. 3 face propuneri:
o F = F \ 3 =
o 3 nu mai este disponibil i avem P (3 , 2 ) < (3 , 3 ), deci 3 l va accepta
pe 3 i l va respinge pe 2
o M = M \ {(2 , 3 )} = {(1 , 1 )}
14
o M = M {(3, 3 )} = {(1, 1 ), (3, 3 )}

o F = F 2 = {2 }
. 2 face propuneri dup ce a fost respins de 3:

o F = F \ 2 =
o 1 nu mai este disponibil i avem P (1 , 1 ) > (1 , 2 ), deci 1 nu l va accepta
pe 2
. 2 face propuneri dup ce a fost respins de 1 :

o M = M {(2, 2 )} = {(1, 1 ), (3, 3 ), (2, 2 )}
Pasul 3: ntoarcerea match-ului M = {(1,1 ),(3,3 ), (2,2 )}
Extensii ale problemei Stable-Marriage
Problema de baz Stable-Marriage prezint dou seturi de elemente, ambele cu cte n com-
ponente. Fiecare element prezint cte o list strict ordonat cu cele n elemente din setul
opus. Bineneles, n practic nu pot fi ndeplinite oricnd toate aceste condiii, de aceea ex-
ist i extensii n care condiiile sunt mai permisive.
I. Stable-Marriage cu liste incomplete (SMI):
- elementele nu mai sunt restricionate la construirea de liste de preferine care s

conin toate elementele din setul opus (size(P(w)) n )
II. Stable-Marriage cu indiferene (SMT):
- nu mai exist restricia ca listele de preferine s fie ordonate strict cresctor, n

listele de preferine pot aprea elemente la acelai nivel, adic avem condiii de
forma P(m, ) P(m, ) ( , = 1, )
15
III. Stable-Marriage cu liste incomplete i indiferene (SMTI):
- au loc condiiile prezentate la I i II
Pentru aceste tipuri de instane stabilitatea matching-ului ce va fi construit este uor diferi-
t de varianta clasic. Se definesc, deci, trei tipuri de stabilitate [3]:
stabilitatea slab3: definit ca n cazul instanelor de Stable-Marriage simple
M = puternic stabil dac (, ) ,

stabilitatea puternic4:
(, ) ( ) , n acest caz (m, w ) = ,
dac au loc urmtoarele:
o M (m) w;
o P (m, w) > P (m, (m));
o P (w, m) P (w, (w)).
super stabilitatea5: M = super stabil dac (, ) , unde

(, ) ( ) , n acest caz (m, w) = ,
dac au loc urmtoarele:
o M (m) w;
o P (m, w) P (m, (m));
o P (w, m) P (w, (w)).
De acum vom folosi notaia SMTI pentru a ngloba toate tipurile de extensii de Stable-
Matching, anume SMT, SMI i SMTI. De asemenea, restul tipurilor de probleme au fost
tratate fr a fi respectate restriciile prezentate de problema clasic de Stable-Matching.
Problemele SMTI sunt instane de Stable-Marriage n care exist conceptul de acceptabili-

tate ntre entiti. Cu alte cuvinte, dac un element m nu prezint n lista lui de preferine
un element f spunem c m nu accept f, prin urmare, n niciun SM ce va fi creat nu va putea
exista o pereche format din cele dou entiti.
3 weak-stability n eng.
4 strong-stability n eng.
5 super-stability n eng.
16
Optimizri ale problemelor de tip SMTI
n cazul problemei clasice, Gale i Shapley au propus un algoritm care construiete un SM

avnd dimensiunea maxim posibil, anume n [2]. Cnd se trateaz cazuri ce nu ndeplinesc
condiiile, fiind vorba de instane de SMTI, problema construirii unui SM maximal devine
mai complicat.
Au fost propui algoritmi care construiesc aproximri ale unui SM maximal, spre exemplu
Irving i Manlove propun un algoritm cu factor de aproximare de 5/3 [4], dar cu condiia ca
doar unul din cele dou seturi s conin indiferene n listele de preferine.
Zoltn Kirly ofer o abordare n timp liniar care are factor de aproximare de 3/2 [5] i chiar
fr condiia impus de algoritmul precedent. De asemenea, exist multe alte propuneri ns
cu un factor de aproximare mai puin bun dect cele menionate.
Avnd n vedere c cel din urm prezint o aproximare mai bun, am decis s implementez
aceast variant optimizat a instanelor de tip SMTI i ca urmare l voi prezenta n contin-
uare.
Algoritmul lui Kirly pentru probleme de tip SMTI
nainte de a prezenta ideea propus de Kirly, vom defini factorul de aproximare. Factorul
de aproximare al unui algoritm de optimizare al dimensiunii matching-ului, pentru instane
de SMTI, desemnat prin f, este acel numr pentru care algoritmul returneaz un matching M
cu dimensiunea size(M) 1/f. [5]
Kirly a pornit de la faptul c multe elemente din primul set (cel care face propuneri) rmn
fr parteneri la final, unii dintre ei fiind preferai n mod egal cu cei cu care au fost dis-
tribuii pretendenii lor, adic P(f, m) = P(f, M(f)). Dezavantajul pornete de la faptul c
dac un nou element face o propunere unui pretendent care are deja ca i partener pe cineva
cu acelai nivel de preferin, acesta este refuzat n favoarea curentului match deoarece nu
prezint un nivel strict mai mare de preferin.
Principiul primul venit, primul servit. Asta reprezint o problem deoarece pot exist cazuri
cnd cel care a fost refuzat s nu mai poat fi acceptat de altcineva, n timp ce, cel pentru
17
care a fost refuzat, s mai poat avea i alte anse. Astfel, dimensiunea matching-ului are de
suferit.
Algoritmul propus pornete de la un matching deja construit cu algoritmul GS pentru o in-

stan de SMTI i, avnd toate elementele care nu au fost distribuite, se repromoveaz. Con-
ceptul de baz este, de fapt, distrugerea indiferenelor6 sau ruperea egalitilor.
Acest lucru se realizeaz prin creterea nivelului de preferin a tuturor elementelor dis-
ponibile din primul set n listele elementelor opuse. Creterea se face cu un , unde =
12. Spre exemplu dac P (w, 1 ) = P (w, 2 ), iar 2 a rezultat ca fiind disponibil n
matching, vom avea P (w, 2 ) = P (w, 2 ) + . Deci cnd 2 va face din nou propuneri w
l va prefera pe 2 fa de 1 . Valoarea lui este raional i subunitar deoarece se dorete
spargerea egalitilor i nu creterea cu un nivel al elementului care este promovat.
Odat ce un element a fost deja promovat el nu va mai putea fi promovat nc o dat, chiar
dac n matching-ul nou este tot nerepartizat.
Algoritmul se oprete cnd orice element care este liber, la un moment dat, a fost promovat.
6 break the ties n eng.

18
n pseudocod avem definite:

V = mulimea care reine care element din M (men) a fost vizitat deja
M = matching-ul rezultat rulnd algoritmul GS
dup creterea nivelului lui m n preferinele celor din setul W , se va construi un
nou matching cu listele de preferine actualizate
se vor re-promova de data aceasta elementele care nu au fost pn acum
promovate i care nu au partener n noul matching
procesul se va repeta pn nu vor mai exista elemente disponibile nepromovate
GS i Kiraly. Comparaie
Avem instana: W = {1 , 2 , 3 , 4 , 5 } M = {1 , 2 , 3 , 4 , 5 }
Setul W: Setul M:
(1 ): 1 , 2 , 3 , 4 (1 ): 1 , 2
(2 ): 2 , 1 , 4 , 3 (2 ): 1 , (3, 2 ), 4
(3 ): 2 , 1 , 3 , 4 (3 ): 1 , 2 , 5
(4 ): 2 , 1 , 3 , 4 (4 ): 1 , 2
(5 ): 3 , 1 , 2 , 4 (5 ): 5 , 2
Rulnd cei doi algoritmi pe aceast instan avem urmtoarele output-uri:
| | < | |7
Se observ, deci, c algoritmul lui Kirly ofer un matching cu o dimensiune mai mare dect
algoritmul obinuit. Pentru a crea matching-uri cu un factor de aproximare mai bun, algo-
ritmul lui Kirly a fost folosit i pentru instanele de one-to-many.
7 Prin |M| = cardinalul mulimii M

19
1.3 One-to-many
n aceast seciune vom trata problema Hospitals-Residents:
Enun:
Fie dou seturi: spitale (H ) i rezideni (R ). Fiecare element din cele dou seturi
prezint cte o list, ordonat descresctor, cu preferinele elementelor corespunztoare
setului opus. Fiecare spital prezint o capacitate, reprezentnd numrul de posturi
disponibile.
Cerin:
Particulariti
- un set de elemente prezint o caracteristic, capacitatea, care desemneaz

numrul maxim de locuri disponibile/numrul maxim de perechi posibile pe
care-l poate forma
- se introduce noiunea de cupluri prin care se nelege c dou elemente (din set-
ul celor care nu au capacitatea specificat) prezint aceleai preferine i doresc
s fie repartizate n acelai loc
Exemplificare
Fie seturile de elemente H = {1 ,2 }, R = {1 ,2 ,3 , 4 , 5 } i urmtoarele liste de preferine:

Setul H: Setul R: Cupluri:
P(1 ): 1 , 2 , 4 , 3 , 5 P(1 ): (1 , 2 ) (1 , 3 )
P(2 ): (3 , 2 ), 4 , 5 , 1 P(2 ): 2 , 1
C(1 ) = 4 P(3 ): (1 , 2 )
C(2 ) = 2 P(4 ): 2 , 1
P(5 ): 2 , 1

= stabil.
20
Introducerea noului element care trebuie luat n calcul, capacitatea, nu reprezint o schim-
bare drastic n comportamentului algoritmului de baz. De aceea, elementele cu capacitate
sunt luate n calcul ca fiind capacitate(h) elemente n locul unui singur element h.
Reprezentarea instanei sub form de graf conform specificaiilor prezentate n [2]:
1 2 3 4 5 - o muchie orizontal/vertica-
l ntre 2 noduri reprezint 2
1 C(1 ) = 4 elemente preferate n mod
2 egal de elementul desemnat
C(2 ) = 2 de linie/coloan
Algoritm
Algoritmul se construiete pornind de la algoritmul GS, rezidenii fiind cei care fac
propuneri. Spitalele accept n numrul locurilor disponibile i pe baza preferinelor. n ca-
zul cuplurilor dac un spital ar accepta doar unul din cei doi, cuplul va trece la urmtoarea
opiune. Cuplul este tratat ca un singur element dar care ocup 2 locuri n loc de unul. [6]
Rezultatul algoritmului pentru instana propus:
M = {(1, 1 ),(3 , 1),(2 , 2),(4 , 2), (5 , 1)}
Problemele College-Admission, Courses-Repartition sunt tratate exact n acelai mod, n

fond toate reprezentnd instane de one-to-many.
21
1.4 Many-to-many
n aceast seciune vorbim despre dou probleme, fiecare cu propriile particulariti, Stable-
Allocation i Two-Sided Market/Teachers Repartition.
1.4.1 Stable - Allocation
Enun:
Fie dou seturi: firme (F ) i lucrtori (W ). Fiecare element din cele dou seturi
prezint cte o list, ordonat descresctor, cu preferinele elementelor corespunztoare
setului opus. De asemenea, fiecare element prezint un numr de uniti. Pe lng unitile
fiecruia exist un numr maxim de uniti pe care l poate oferi un anumit lucrtor la o
anumit firm.
Cerin:
Particulariti
- numrul de uniti semnific pentru o firm numrul de ore pe care ar dori s le

acopere viitorii angajai (U(f) > 0, f )
- pentru lucrtori, unitile semnific numrul total de ore pe care sunt dispui s l
ofere (U(w) > 0, w )
- numrul maxim de uniti dintre o firm i un lucrtor se refer la numrul max-
im de ore pe care poate lucrtorul respectiv s le aloce la acea firm, adic
(U (w, f ) 0, w )
Exemplificare
Fie seturile de elemente F = {1, 2 , 3 }, W = {1 ,2 ,3 , 4 , 5 , 6 , 7 } i urmtoarele liste

de preferine:
Setul F: Setul L:
P(1 ): 3 , 7 , 2 , 1 , 5 , (4 , 6 ) U(1) = 70 P(1 ): 2 , 3 , 1 U(1 ) = 20
P(2 ): 2 , 1 , 5 , 4 , 3 , 6 U(2) = 55 P(2 ): 2 , 1 , 3 U(2 ) = 16
P(3 ): 2 , 7 , 4 , 5 , 3 , 6 , 1 U(3) = 31 P(3 ): 1 , 2 U(3 ) = 15
):
P(4 2 , 3 , 1 U(4 ) = 14
22
Max-uniti: P(5 ): 1 , 3 , 2 U(5 ) = 19

U(1 , ) = 15 P(6 ): 3 , 2 , 1 U(6 ) = 21
U(2 , ) = 12 P(7 ): 1 , 2 , 3 U(7 ) = 23
U(3 , ) = 10

= stabil.
Reprezentarea sub form de graf a acestei instane este mai greu de interpretat, nu aduce
niciun beneficiu vizual, prin urmare, nu o mai costruim.
Algoritm
Baou i Balinski descriu un algoritm pentru a rezolva aceast problem care pleac de la
algoritmul GS [2]. n acest context apare conceptul de alocare de uniti ntre entiti din
seturi diferite.
Algoritmul worker-optimal pleac de la lucrtori care fac propuneri n funcie de preferine.

Orele ce urmeaz a fi alocate ntre un anumit lucrtor w i o firm f se alege obinnd min-
imul dintre U(w), U(f) i U(w, f). Dac firma f este complet indisponibil, dar un lucrtor
nou w care face o propunere i se afl n lista preferinelor mai sus dect un lucrtor w
cruia deja i-au fost alocate un numr de ore, w va fi respins i va fi readugat n lista ele-
mentelor nc disponibile.
n continuare vom nota:
W = mulimea lucrtorilor
F = mulimea elementelor disponible; va fi iniializat cu W
A(w, f ) = numrul de uniti alocate ntre w i f
23
1 , 2 (1 , 2 ) = 12
Rezultatul obinut pentru instana prezentat:
1 , 3 (1 , 2 ) = 8
2 , 2 (2 , 2 ) = 12
2 , 1 (2 , 1 ) = 4
3 , 1 (3 , 1 ) = 15
4 , 2 (4 , 2 ) = 12
M= 4 , 3 (4 , 3 ) = 2
5 , 1 (5 , 1 ) = 15
5 , 3 (5 , 3 ) = 4
6 , 3 (6 , 3 ) = 10
6 , 2 (6 , 2 ) = 11
7 , 1 (7 , 1 ) = 15
{ 7 , 3 (7 , 3 ) = 7
24
1.4.2 Two-sided Market sau Teachers-Repartition
Enun:
Fie dou seturi: firme (F ) i lucrtori (W ). Fiecare element din cele dou seturi
prezint cte o list, ordonat descresctor, cu preferine. Listele conin i grupuri de
elemente. De asemenea fiecare element prezint o anumit capacitate.
Cerin:
Particulariti
- fa de Stable-Allocation, aici nu mai avem uniti, avem ca la Hospitals-

Residents, capaciti; de data aceasta la ambele seturi
- prin capacitate se nelege numrul total de locuri la care ar putea fi angajat un lu-
crtor w , iar pentru o firm f se nelege numrul de posturi libere
- grupul este o particularitate aparte a acestei probleme, prin ideea de grup nu se
creeaz o legtur att de strns ca la cupluri
- grupurile sunt ntlnite doar la nivel de preferine, adic o firm f poate meniona
c ar prefera un grup format din 1 i 2 faa de un grup format din 1 i 3
Exemplificare
Fie seturile de elemente F = {1,2 , 3 , 4 }, W = {1 ,2 ,3 , 4 }. i urmtoarele liste de

preferine8:
Setul F :
P(1 ) : < 1 , 2 >, (< 1 , 3 >, < 3 , 4 >), < 2 , 4 >, < 1 , 4 >, < 2 , 3 >
, 1 , 2 , 3 , 4
P(2 ): (< 1 , 2 >, < 1 , 4 >), (< 2 , 3 >, < 2 , 4 >), < 3 , 4 >, < 1 , 3 >
P(3 ) : < 1 , 4 >, < 1 , 2 >, < 2 , 4 >, 1 , 2 , 4
P(4 ) : < 1 , 2 >, 1 , 2
C(1 ) = 2 C(2) = 2
C(3) = 2 C(4 ) = 2
8 Prin notaia <w, w> se nelege grupul format din w, w cu w,w

25
Setul W:
P(1 ) : < 3 , 4 >, (< 2 , 3 >, < 2 , 4 >), < 1 , 3 >, < 1 , 2 >, 1 , 2 , 3 , 4
P(2 ): (< 3 , 4 >, < 2 , 4 >), < 2 , 3 >, < 1 , 4 >, (< 1 , 3 >, < 1 , 2 >), 1 , 2 , 3 , 4
P(3 ): (< 1 , 2 >, < 2 , 4 >, < 1 , 3 >), < 2 , 3 >, < 1 , 4 >, < 3 , 4 >, 1 , 2 , 3 , 4
P(4 ): (< 1 , 2 >, < 2 , 4 >, < 3 , 4 >), < 1 , 3 >, < 1 , 4 >, < 2 , 3 >, 1 , 2 , 3 , 4
C(1 ) = 2
C(2 ) = 2
C(3 ) = 2
C(4 ) = 2

= stabil.
Algoritm
n rezolvarea acestui tip de problem, algoritmul pornete, de asemenea, de la ideea de

acceptare ntrziat9 propus de Gale i Shapley. Ce are nou acest algoritm este conceptul
pe baza cruia se construiete matching-ul, anume prin preferine substituibile10. n
momentul n care o firm este respins de un anumit lucrtor, atunci aceasta va elimina, din
lista de preferine, toate grupurile care conin elementul respectiv.
La la fiecare pas, o firm face propuneri pn nu mai are posturi disponibile. La sfritul unei
runde de propuneri, angajaii, n caz de nc nu au primit suficiente oferte, rmn nc
disponibili, iar restul, care au primit prea multe cereri, aleg dintre ofertele primite ce prefer
mai mult, refuznd firmele mai puin dorite. n momentul n care o firm este respins are
loc fenomenul de eliminare a tuturor grupurilor ce conin entitatea care a refuzat-o.
Algoritmul se termin cnd toate firmele i-au ocupat toate posturile i, cnd cele care nc
au locuri disponibile au fost refuzate de toi angajaii pe care i i-ar mai fi dorit.
9 Deferred Acceptance n eng.

10 Substitutable Preferences n eng.
26
n continuare vom defini urmtoarele:
W = mulimea lucrtorilor
F = mulimea elementelor disponible; va fi iniializat cu W
c(x) = capacitatea unui element x
prin group se nelege orice tip de element, att grup format din n entiti ct i
dintr-un singur element
Rezultatul obinut pentru instana prezentat:

1 , 3
1 , 4
2 , 3
2 , 4
M= 3 , 1
3 , 2
4 , 1
{4 , 2
27
2 Modelarea problemelor de Stable-Matching prin

reprezentri XML. Instanierea problemelor
Pentru a putea crea un mod ct mai uor de reprezentare a datelor, instanierea problemelor
se va face pe baza unui XML, acesta dovedindu-se cel mai potrivit. Structura acestuia a fost
conceput respectnd principiile i regulile stabilite n [12].
Bineneles, fiecare tip de problem prezint particularitile sale dar, toate pleac de la
aceeai configuraie de baz. n continuare voi prezenta structura general a XML-ului i
particularitile fiecrei probleme, iar la Anexe A-D sunt ataate modele de XML pentru
fiecare tip de problem n parte.
2.1 Schema XSD a modelului de baz

Elementele principale pe care trebuie s le conin XML-ul sunt:
Tipul problemei (ex: SM, HR, MM, SA)
Definirea seturilor (nume set, dimensiune i elementele propriu-zise)
Definirea preferinelor:
o Numele elementului pentru care se definete lista de preferine
o Numele elementului curent, nivelul de preferin (1 = cel mai preferat)
o n caz de avem egalitate, vom meniona acest lucru i vom trece numele tuturor
elementelor
De asemenea sunt i elemente care pot fi menionate, precum:

Descriere a problemei
Dimensiunea (2D/3D)11
Un alt aspect important ce trebuie respectat este faptul c seturile de elemente trebuie
definite nainte s fie specificat vreo preferin. Elementele trebuie s existe pentru a putea
fi sau pentru a putea avea preferine.
n continuare este prezentat schema XSD a XML-ului de baz, pentru probleme one-to-
one.12
11 Deocamdat biblioteca rezolv doar probleme 2D, dar exist i opiunea 3D pentru extensii viitoare
12 Schema a fost generat folosind [13]
28
<?xml version="1.0" encoding="utf-8"?>


<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="problem">
<xs:complexType mixed="true">
<xs:sequence>
<xs:element minOccurs="2" maxOccurs="unbounded" name="set">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name" type="xs:string" use="required" />
<xs:attribute name="size" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" maxOccurs="unbounded" name="preferences">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" name="element">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="level" type="xs:unsignedByte" use="req"/>
<xs:attribute name="tie" type="xs:boolean" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="dimension" type="xs:string" use="optional" />
<xs:attribute name="description" type="xs:string" use="optional" />
</xs:complexType>
</xs:element>
</xs:schema>
Schema XSD a modelulului de baz

29
Un exemplu minimal de instan ar putea fi:

<problem name="SM" dimension="2D" description="Sample of SM instance">
<set name="women" size="3"> w1, w2, w3 </set>
<set name="men" size="3"> m1, m2, m3 </set>
<preferences name="m1">
<element name="w1" level="1" />
<element level="2" tie="true">
w2, w3
</element>
</preferences>
<preferences name="w1">
<element name="m1" level="1" />
</preferences>
</problem>
Restricii: dimensiunea i nivelul trebuie s aib o valoare pozitiv altfel instana se va

considera invalid.
2.2 Particularitile problemelor definite prin structura XML
Definirea capacitii
Pentru instanele de tip one-to-many i many-to-many, unde este necesar s fie specificate
capacitile elementelor, se prezint o structur uor diferit al tagului <set>. Fiecare
element din set va fi caracterizat prin intermediul tagului <element> care va avea ca i
atribut name i capacity.
Definim mai jos H = {1 ,2 }, C(1 ) = 4 i C(2 ) = 2:

<set name="hospitals" size="2">
<element name="h1" capacity="4"/>
<element name="h2" capacity="2"/>
</set>
30
Restricii: capacitatea trebuie s aib o valoare pozitiv, altfel instana se va considera

invalid.
Definirea cuplurilor
Cuplurile apar n cazul instanelor de one-to-many. Ele se definesc n interiorul tagului

<group>, dup ce au fost deja definite seturile de elemente i nainte de a fi specificate
preferinele.
Definim mai jos cuplurile 1 ,2 i 3 ,4 :
<group>
<couple> r1, r2 </couple>
</group>
Restricii: elementele definite sub tagul <couple> vor fi tratate ca avnd aceleai preferine
deci, dac apar liste pentru ambele elemente, instana se va considera invalid. Tagul
<couple> trebuie s conin maxim dou elemente separate prin virgul.
Definirea grupurilor
n cadrul instanelor de many-to-many care lucreaz cu grupuri se va defini un grup, n

listele de preferine, prin intermediul tagului <group>.
Definim mai jos urmtoarea list de preferine P(4 ) : < 1 , 2 >, 1 , 2 :
<preferences name="f4">
<element name="w1w2" level="1">
<group> w1, w2 </group>
</element>
<element name="w1" level="2">
<element name="w2" level="3">
</preferences>
31
Definirea unitilor
Pentru Stable-Allocation este necesar s se specifice numrul de uniti disponibile pentru

fiecare element, deci acest lucru se va face n momentul definirii seturilor. Specificarea max-
unitilor, dintre dou elemente, se va face n momentul specificrii listelor de preferine, n
dreptul elementului n cauz.
n continuare vom defini dou seturi i listele de preferine ale elementelor

F = { }, W = { }, U(f) = 70 , U(w) = 20, U(w,f) = 15:
<set name="firms" size="1">

<element name="f" units="70"/>
</set>
<set name ="workers" size="1">
<element name="w" units="20"/>
</set>
<preferences name ="f">

<element name="w" level="1" maxunits="15"/>
</set>
<preferences name ="w">

<element name="f" level="1" maxunits="15"/>
</set>
Restricii: max-unitile trebuie specificate pentru fiecare pereche de elemente n parte, iar
pentru aceeai pereche valoarea trebuie s fie identic, altfel instana va fi considerat in-
valid.
32
2.3 Specificaii importante

n continuare se vor specifica cteva reguli de construire a unui XML valid:
Tipul problemei trebuie s corespund cu una din variantele prezentate n seciunea

2.1
Fiecare instan trebuie s aib definite minim 2 seturi de elemente
Un set trebuie s conin minim un element
Numele elementelor trebuie s fie diferite
Seturile se definesc primele
Atributele care trebuie s primeasc ca i valoare un numr trebuie s fie obligatoriu
definite pozitiv, ex: capacity, size, units, maxunits
Toate elementele specificate la preferine i n grupuri trebuie s fi fost definite n
setul de elemente
Un cuplu este definit sub tagul <group> i trebuie s conin maxim dou elemente
Elementele dintr-un cuplu nu trebuie s aibe specificate dect o list de preferine
pentru oricare dintre ele
Pentru o instan de tip SA este obligatoriu s fie definite unitile pentru fiecare el-
ement n parte
Pentru o instan de tip HR/MM este necesar s se specific capacitile elementelor
3 Arhitectur i implementare
n acest capitol se va discuta despre arhitectura proiectului ct i detaliile la nivel de imple-
mentare al cadrului de lucru.
Proiectul poate fi utilizat sub dou forme. n primul rnd, acesta poate fi utilizat ca o bibli-
otec Java importat ntr-un proiect. De asemenea, avnd n vedere uurina pe care o aduc
n ultima perioad microserviciile, proiectul prezint i un serviciu REST prin care ofer
soluii problemelor de Stable-Matching.
Cadrul de lucru prezint patru niveluri importante:

Interpretarea i validarea inputului i instanierea problemei
Rezolvarea problemei
Construirea rezultatului
Serviciul REST
33
3.1 Schema general a funcionrii proiectului
Pentru oferirea unei imagini de ansamblu al serviciului REST pe care l-am creat, putem
prezenta urmtoare schem de interacionare cu API-ul:
Fig.
Clientul face 3.1 Diagrama
o cerere de interaciune
HTTP prin care trimite cu
unserviciul
XML cu REST
datele instanei
Serverul primete cererea pe care o trimite aplicaiei specificate (smrestservices)

API-ul primete cererea, interpreteaz inputul, l proceseaz i rezolv problema,
iar la final construiete rezultatul pe care urmeaz s l trimit, prin intermediul
protocolului HTTP, clientului, sub form de XML
Fig 3.2 Fluxul activitii n API dup ce se primete XML-ul de input

34
3.2 Structura proiectului

n acest subcapitol vom prezenta fluxul activitilor care au loc dup momentul n care se
trimite inputul sub form de XML.
Interpretare, validare input:

n modulul de interpretare are loc parsarea XML-ului i verificarea tuturor condiiilor
pentru a nu trimite date invalide modulului care se ocup cu rezolvarea problemelor. n
seciunea 2.3 au fost definite tiparele tuturor tipurilor de XML pentru problemele propuse
tocmai pentru a evita construcia unei instane greite.
Instanierea problemei:
Dup parsare, are loc instanierea. Diagrama de clase care modeleaz instanele este re-
prezentat astfel:
Fig 3.3 Clasele principale din pachetul model. Instanierea problemei

35
Rezolvarea problemei:
Pentru rezolvarea problemei, modulul principal, anume nucleul a fost construit respectnd
ca i design pattern Strategy.
Fig 3.4 Clasele principale din pachetul solvers. Strategy Pattern
n cazul de fa, Problem reprezint contextul, ea conine datele pentru care se va ti ce tip
de Solver este necesar. Bineneles, SmType este element esenial n determinarea tipului de
problem. SmType este definit ca fiind o enumeraie astfel13:
13 Tipurile sunt prezentate i n seciunea 0

36
De asemenea, n pachetul solvers exist i o fabric de solver-e, anume SolverFactory,

implementat astfel:
Fig 3.5 clasa SolverFactory. Factory Method Pattern
Structura de date definit pentru reprezentarea rezultatului final poart numele de Match-
ing i prezentm punctele principale din componena acesteia:
Fig 3.6 Clasele principale pentru reprezentarea rezultatului

37
3.3 Detalii de implementare al algoritmilor
@Override
public Matching solve() {
SmLogger.start(true, algorithmName, solverName);
matching = new Matching(problem.getSets().get(0).getElements());

Set men = problem.getSets().get(0);
/* array which holds a boolean that specifies if a man was already re-promoted */
boolean visited[] = new boolean[problem.getSets().get(0).getSize()];
Arrays.fill(visited, false);
boolean finished = false;

while(!finished){
finished = true;
matching = gsSolver.solve();
int size = men.getSize();
/* loop through all men */

for (int i = 0; i < size; i++){
Element man = men.getElements().poll();
/* if the current man has already been promoted or it has a matching we pass over
him */
if (visited[i] || !matching.isFree(man))
continue;
/* we promote him */
gsSolver.matching.addFreeElement(problem.element(man.elemId()));
visited[i] = true;
finished = false;
Set women = problem.getSets().get(1);
int womenSize = women.getSize();
/* loop through women to raise the current man's priority with the value of
EPSILON */
for (int j = 0; j < womenSize; j++){
Element woman = women.getElements().poll();
/* we have to verify if the woman has the current man on her list, and if she
does, his priority is raised with EPSILON */
if (woman.accepts(man))
woman.prioritize(man, EPSILON);
}
}
}
SmLogger.start (false, algorithmName, solverName);
return matching;
}
Fig 3.7 Implementarea algoritmului propus de Kiraly

38
@Override
public Matching solve() {
/* while there are elements that aren't matched yet */
while (!matching.freeElements().isEmpty()) {
/* get first element from the queue */

Element element = matching.freeElements().poll();
/* get its preference element: looping through its list => by the level value */
while (!element.preferences().isEmpty()) {
Element pref = element.preferences().poll();
/* check if is an acceptable partner for current preference */

if (!pref.accepts(element))
continue;
/* verify the availability of its current preference */

if (pref.isAvailable()) {
pref.setAvailability(false);
element.setAvailability(false);
matching.addPair(new Pair(element, pref));
break;
}
else {
/* if the preference is already taken, get the best one between
current element and its current match */
String currMatchName = matching.getElementPair(pref);
int currentMatchLevel = pref.getLevelFor(currMatchName);
int currentElemeLevel = pref.getLevelFor(element.elemId());
/* when current element that proposes is better than the current match */
if (currentMatchLevel > currentElemLevel){
if (matching.isFree(elem))
matching.removeFreeElement(elem);
pref.setAvailability(false);
element.setAvailability(false);
currentMatch.setAvailability(true);
/* add the current pair to the Matching and the old match for the
woman to the free list */
matching.removePairFor(element);
matching.addPair(new Pair(element, pref));
matching.addFreeElement(problem.element(currMatchName));
break;
}
}
/* when man was rejected by all its preferences */

if (element.preferences().isEmpty())
element.setAvailability(true);
}
}
problem.getFirstSetOfElements().stream().filter(Element::isAvailable).
forEach(Element::remakeList);
problem.getFirstSetOfElements().stream().filter(Element::isAvailable).
forEach(element -> matching.addFreeElement(problem.element(element.elemId())));
return matching;
}
Fig 3.8 Implementarea algoritmului propus de Gale i Shapley pentru instane de one-to-one
39
n Figura 4.8 este prezentat implementarea funciei solve a algoritmul de baz de la care au
pornit ideile dezvolatate n toate celelalte variante de solver-e. Am preferat de asemenea s
prezint i algoritmul propus de Kirly, n figura 4.7, deoarece am vrut s nfiez felul n
care am decis s implementez principiul de spargere al egalitilor.
3.4 Serviciul REST
Unele servicii sunt mult mai uor de folosit i de meninut la zi cu toate modificrile dac
prezint i o interfa web, de aceea am optat i pentru oferirea unui serviciu REST.
Pentru implementarea serviciului REST am folosit SpringBoot care ofer o modalitate prac-
tic i uoar. Cea mai important rut este cea care rezolv instana primit, anume ruta de
POST.
Fig 3.9 Ruta POST pentru apelarea serviciului de Stable-Matching
n caz de XML-ul primit nu trece de procesul de validare, cu alte cuvinte nu sunt respectate
cerinele specificate n 2.3, se va ntoarce un XML de eroare. La generarea lui s-a folosit
JAXB. Spre exemplu, clasa de baz, adic ResponseXml prezint urmtoarea implementare:
Fig 3.10 ResponseXml, implementare cu JAXB

40
Modele de output sunt prezentate n seciunea 5. Structura claselor implicate n construirea

XML-ului ce urmeaz a fi returnat este urmtoarea:
Binncjsncjsbchjsb
Fig 3.11 Structura general a claselor care modeleaz XML-ul ce va fi returnat
3.5 Tehnologii i platforme utilizate
Ca i tehnologie principal am optat pentru Java, aceasta oferind un mod uor de implemen-
tare al structurii proiectului i prezentnd concepte care permit gestionarea ntr-un mod
eficient al acestuia. De asemenea, Java are i o varietate de structuri de date uor de utilizat
n cadrul unor algoritmi.
41
Pentru crearea serviciului REST, am folosit framework-ul SpringBoot. REST14 este o arhitec-
tur nclinat spre expunerea unui mod uniform i uor de transfer de date [11]. Acest lucru
se realizeaz prin cereri i rspunsuri, metode HTTP15 16.
Cheia care st la baza acestei arhitecuri o reprezint modul de interpretare i reprezentare al

resurselor. REST ofer o idee nou prin care separ complet interfaa unei aplicaii de partea
de server, astfel reuind s fie extrem de uor de creat mai multe aplicaii care consum
acelai serviciu. Ca i imagine de ansamblu, prin servicii REST se nelege o arhitectur care,
prin intermediul URI17-urilor, expune o multitudine de resurse i servicii.
SpringBoot ofer un mod uor de lucru cu serviciile REST, acesta realizndu-se prin
adnotri, cum ar fi:
@Controller => adnotare care desemneaz o clas ca fiind

un controller ce va intercepta aciunile ce
vor fi cerute pentru o anumit resurs
@RequestMapping(/sm) => adnotare prin care se asigur c toate cere-

rile ctre /sm vor fi mapate ctre o
metod/clas; n cazul nostru este vorba de o
clas, anume controller-ul SmServiceCon-
troller
Cea de-a doua adnotare prezint i o multitudine de atribute care ajut la specificarea tu-
turor informaiilor necesare pentru o anumit rut, spre exemplu: value, method, consumes
(opional), produces (opional), headers etc. Utilizarea acestora poate fi observat n figura
3.9.
La realizarea XML-urilor, pentru a putea transpune datele din obiecte n noduri XML am
utilizat JAXB. Ca i SpringBoot, JAXB lucreaz tot cu ajutorul adnotrilor prin care ofer o
modalitate de mapare a obiectelor. Cteva adnotri importante ar fi: @RootElement,
@XmlAttribute, @XmlElement. Un exemplu n care au fost utilizate se poate constata
n figura 3.10.
14 Representational State Transfer n eng.

15 Hypertext Transfer Protocol
16 HTTP verbs n eng.
17 Uniform Resource Identifiers n eng

42
Pentru gzduirea18 serviciului construit am folosit un server gratuit, Heroku, acesta

punnd la dispoziie fiecrui utilizator aceast facilitate ntr-o anumit msur.
Heorku este o platform n Cloud care are la baz un container de sistem administrat cu ser-
vicii de date integrate, acesta ajutnd la facilitarea lansrii19 i a rulrii aplicaiilor pe web
[12].
4 Lucrul cu serviciul de Stable-Matching

Cum am menionat i anterior, serviciul poate fi folosit n dou moduri, anume:
Ca i cadru de lucru, importnd biblioteca n propriul proiect
Folosind serviciul REST
Utilizarea serviciului REST
n continuare se va prezenta modul n care se vor face cereri ctre serviciul rest. Ruta desti-
nat rezolvrii problemelor se apeleaz printr-o cerere20 de tip POST la URI-ul:
http://smrestservices.herokuapp.com/sm/algorithm/{param}.
{param} reprezint tipul problemei, el trebuie s fie identic cu numele problemei spe-cificat
n XML-ul trimis prin POST. Rezultatul pe care clientul l va primi, ca urmare al cerererii,
va fi tot un XML. Un exemplu ar putea fi:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<result description="Matching result for the instance proposed" algorithm="Gale
Shapley for one-to-many instance">
<match>
<element name="r1" set="residents"/>
<element name="h1" set="hospitals"/>
</match>
<match>
<element name="h1" set="hospitals"/>
</match>
<unmatched>
</unmatched>
</result>
18 host n eng.
19 deploy n eng.
20 request HTTP n eng.
43


<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="result">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" maxOccurs="unbounded" name="match">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" name="element"
type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element minOccurs="1" name="unmatched">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" name="element"
type="xs:string" />
</xs:sequence>
<xs:attribute name="number" type="xs:unsignedByte" use="optional" />
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="algorithm" type="xs:string" use="required" />
<xs:attribute name="description" type="xs:string" use="optional" />
</xs:complexType>
</xs:element>
</xs:schema>
Schema XSD a modelulului de output generat cu [13]
Dup cum este menionat n aceast schem i dup cum am observat i n exemplu, output-
ul este alctuit din:
Nodul rdcin care poart numele <result> i prezint dou atribute care ofer de-
talii legate de modul n care a fost generat acest XML rezultat, prin algorithm se
specific numele algoritmului folosit, iar prin description se descrie n cteva cu-
vinte tipul acestuia
ntre 0 i n elemente <match> care prezint cte o pereche format din cel puin
dou noduri <element>
Fiecare <element> are precizat numele i setul din care face parte
44
Prin tagul <unmatched> sunt prezentate acele elemente (din primul set, adic setul
care face propuneri) care nu au reuit s fie distribuite cu nicio alt entitate din
setul opus
n imaginea de mai jos este afiat un exemplu de cerere POST ctre serviciu:
Iar rspunsul primit n urma cererii va fi de tipul21:
21 Interfaa folosit pentru clientul care apeleaz serviciul este POSTMAN (https://www.getpostman.com/apps)
45
Acum se va oferi un exemplu de rezultat n cazul n care se trimite un XML invalid. Spre
exemplu vom specifica o dimensiune invalid pentru unul dintre cele dou seturi.
Vom trimite XML-ul (unde se observ c size-ul prezint o valoare negative):
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<problem description="Sample of HR instance" name="HR">
<set name ="students" size ="3">31090104SL151001, 31090104SL151002,
31090104SL140253</set>
<set name ="courses" size ="-1">
<element capacity ="125" name ="IC"/>
<element capacity ="100" name ="PF"/>
</set>
<preferences name ="31090104SL151002">
<element level ="2" name ="IC"/>
<element level ="1" name ="PF"/>
</preferences>
<preferences name ="31090104SL140253"/>
<preferences name ="IC">
<element level ="1" name ="31090104SL151002"/>
</preferences>
<preferences name ="PF">
</preferences>
</problem>
Rspunsul care se primete n urma trimiterii unei cereri cu acest XML este:
46
5 Concluzii i perspective de viitor
Cadrul de lucru prezentat n lucrarea de fa pune la dispoziie un serviciu prin care se

rezolv diferite tipuri de probleme de Stable-Matching. Aceste probleme se ntlnesc n situ-
aii din viaa real oricnd se vorbete despre distribuirea unui eantion de entiti n diferite
circumstane, spre exemplu distribuia elevilor la un liceu, repartizarea unor profesori la mai
multe licee/coli etc.
Exist numeroase variante ale acestor probleme, n lucrarea de fa prezentndu-se

cele mai generale tipuri care s-ar gsi n viaa real i ar fi utile pentru utilizarea n situaii
precum cele specificate anterior. Unele probleme destul de particulare care s-ar putea adu-
ga ar fi:
Students/Projects Allocation un anumit numr de studeni doresc s se nscrie

la examenul de licen i ar trebui s i aleag un proiect; un profesor poate
avea unul sau mai multe proiecte i prezint un numr limitat de locuri, de ase-
nemea i proiectele prezint un anumit numr de locuri disponibile
Stable Roommates este o problem de Stable-Matching aparte, distribuia se

face ntre elemente din acelai set, aici fiind prezent un singur set
Stable Matchings 3D o serie de probleme care ncearc s fac ditribuia ntre

trei seturi de entiti (ex: femei, brbai i cini)
De asemenea, n diferite lucrri specifice acestui subiect, s-a demonstrat faptul c nu

exist doar un singur Stable-Matching pentru o instan, exist mai multe, unele chiar
neavnd caracteristica de optimalitate ntr-un singur sens (woman-optimal/men-optimal
etc). Deci s-ar putea construi algoritmi care s gseasc ntreg setul de matching-uri i s
ofere anumite scoruri acestora.
47
Bibliografie
[1] D. Gale and L. S. Shapley, College admissions and the stability of marriage, Amer.
Math. Monthly, Vol.69, pp. 915, 1962.
[2] M. Baou and M. Balinski, Many-to-many matching: stable polyandrous polygamy (or
polygamous polyandry), Discrete Applied Mathematics, Vol. 101, pp. 112, 2000.
[3] Kazuo Iwama, A Survey of the Stable Marriage Problem and Its Variants, International
Conference on Informatics Education and Research for Knowledge-Circulating Society ,
2008.
[4] R. W. Irving, D. F. Manlove, Approximation algorithms for hard variants of the stable
marriage and hospitals/residents problems, Journal of Combinatorial
Optimization (2007)
[5] Zoltn Kirly, Better and simpler approximation algorithms for the stable marriage
problem, Egervry Research Group on Combinatorial Optimization, April 4, 2008.
[6] Robert W. Irving, David F. Manlove and Sandy Scott, The Hospitals/Residents Problem
with Ties.
[7] Ruth Martnez, Jordi Mass, Alejandro Neme and Jorge Oviedo, An algorithm to compute
the full set of many-to-many stable matchings, Journal of Economic Literature Classifica-
tion Number: C78, July, 2003.
[8] Robert W. Irving, David F. Manlove and Sandy Scott, Strong Stability in the Hospi-
tals/Residents Problem.
[9] David F. Manlove, Robert W. Irving, Kazuo Iwamay, Shuichi Miyazaki, and Yasufumi
Morita, Hard Variants of Stable Marriage.
48
[10] Dan Gusfiel, Three fast algorithms for four problems in Stable Marriage, Society for
Industrial and Applied Mathematics, Siam J. Comput., Vol. 16, No.1 , February, 1987.
[11] Robert W. Irving, Stable marriage and indifference, Discrete Applied Mathematics 48
(1994) 261-272, 5 February, 1990.
[12] Organising Committee of the Third International Competition of CSP Solvers, XML
Representation of Constraint Networks Format XCSP 2.1, 15 January, 2008.
[13] Liquid Studio 2017
[14] https://spring.io
[15] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
[16] https://www.heroku.com/platform
[17] https://www.ams.org/samplings/feature-column/fc-2015-03
[18] n general pentru subiecte legate de limbaj:
https://docs.oracle.com/javase/8/docs
[19] Pentru diagrame:
https://www.draw.io
https://www.genmymodel.com
https://www.gliffy.com
49
Anexa A
Model de XML pentru o instan de Stable-Marriage

<?xml version="1.0" encoding="UTF-8"?>
<problem name = "SM" dimension = "2D" description = "Sample of a SM
instance">
<set name = "women" size = "3">
w1, w2, w3
</set>
<set name = "men" size = "3">
m1, m2, m3
</set>
<preferences name = "w1">
<element name = "m1" level = "1" />
</preferences>

</preferences>

</preferences>
<preferences name = "m1">

<element name = "w1" level = "1" />
</preferences>

<element level ="2" tie = "true"> w3, w2 </element>
</preferences>

</preferences>
</problem>
50
Anexa B
Model de XML pentru o instan de Hostpitals/Residents

<problem name = "HR" category = "" dimension = "2D" description =
"Sample of a HR instance">
<set name = "residents" size = "3">

r1, r2, r3
</set>
<set name = "hospitals" size = "2">
<element name = "h1" capacity = "4" />
<element name = "h2" capacity = "2" />
</set>
<group>
</group>
<preferences name = "r2">

<element name = "h2" level = "1" />
<element name = "h1" level = "2" />
</preferences>
<preferences name = "r3">

<element level = "1" tie = "true"> h1, h2 </element>
</preferences>
<preferences name = "h1">

<element name = "r1" level = "1" />
</preferences>
<preferences name = "h2">

<element level ="1" tie = "true"> r3, r2 </element>
</preferences>
</problem>
51
Anexa C
Model de XML pentru o instan many-to-many (Teachers Repartition)

<problem name = "MM" dimension = "2D" description = "Sample of a MM instance">
<set name = "firms" size = "4">
<element name = "f1" capacity = "2" />
</set>
<set name = "workers" size = "4">
<element name = "w1" capacity = "2" />
</set>
<preferences name = "f1">
<element name = "w1w2" level = "1">
<group> w1, w2</group>
</element>
<element level = "2" tie = "true">

<group name = "w1w3"> w1, w3 </group>
</element>

</element>

</element>

</element>
</preferences>
</element>

</element>
52

</element>

</element>
</preferences>
</element>

</element>

</element>

</preferences>
</element>

</preferences>
<element name = "f3f4" level = "1">
<group> f3, f4 </group>
</element>

<group name = "f2f3"> f2, f3 </group>
</element>

</element>

</element>
<element name = "f1" level = "5" />

53

</preferences>
</element>

</element>

</element>

</element>

</preferences>
<element level = "1" tie = "false">
</element>

</element>

</element>

</element>

</preferences>
54

</element>

</element>

</element>

</element>

</preferences>
</problem>
55
Anexa D
Model de XML pentru o instan de tip many-to-many (Stable-

Allocation)
<problem name = "SA" dimension = "2D" description = "Sample of a SA instance">
<set name = "workers" size = "7">
<element name = "w1" units = "20" />
</set>
<set name = "firms" size = "3">
<element name = "f1" units = "70" />
</set>

<element name = "w3" level = "1" maxunits = "15" />
<element level = "6" maxunits = "15" tie = "true">
w4, w6
</element>
</preferences>
</preferences>
</preferences>
<element name = "f2" level = "1" maxunits = "12" />
56

</preferences>

</preferences>

</preferences>

</preferences>
</preferences>

</preferences>

</preferences>
</problem>

Li Cent A Stable Matching

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Li Cent A Stable Matching

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA ALEXANDRU IOAN CUZA IAI

Cadru de lucru pentru rezolvarea problemelor de tip

Student: Andreea-Eveline Giosanu

Sesiunea: iulie 2017

Cadru de lucru pentru rezolvarea problemelor de

Student: Andreea-Eveline Giosanu

Sesiunea: iulie 2017

DECLARAIE PRIVIND ORIGINALITATEA I RESPECTAREA

rezumarea ideilor altor autori precizeaz referina precis la textul original.

Iai, 3 iulie 2017

Absolvent Andreea Eveline Giosanu

Iai, 3 iulie 2017

Absolvent Andreea Eveline Giosanu

Problemele de Stable-Matching acoper o mare varietate din situaiile din ziua de

- n capitolul al doilea, Modelarea problemelor de Stable-Matching, am descris mod-

- n seciunea Arhitectur i implementare am oferit o imagine de ansamblu a felului

Proiectul a pornit de la ideea necesitii unui serviciu care s ofere posibilitatea

n realizarea acestui proiect a trebuit s ncep prin citirea documentaiei de

Pe lng construirea XML-urilor i implementare algoritmilor, a trebuit s nv i un

Problemele de Stable Matching se mpart n trei clase:

1.1 Caracteristici generale

Sensul optimalitii SM-ului

Fie seturile de elemente M = {1 ,2 ,3 }, W = {1 ,2 ,3 }. i urmtoarele liste de

Se dorete construcia lui M, unde M = {( , ) | , = 1,3 = 1,3 }

1 Elementele sunt afiate n ordine descresctoare, ex. P (1 , 1 ) > (1 , 3 )

Reprezentarea sub form de graf2 a instanei:

2 Reprezentare construit conform indicaiilor prezentate n [2]

Dac are loc (, ) > (, 1 ) atunci f va fi distribuit cu b (M = M

Construcia lui M cu algoritmul GS pentru instana prezentat:

o M = M {(3, 3 )} = {(1, 1 ), (3, 3 )}

. 2 face propuneri dup ce a fost respins de 3:

. 2 face propuneri dup ce a fost respins de 1 :

Pasul 3: ntoarcerea match-ului M = {(1,1 ),(3,3 ), (2,2 )}

Extensii ale problemei Stable-Marriage

I. Stable-Marriage cu liste incomplete (SMI):

- elementele nu mai sunt restricionate la construirea de liste de preferine care s

II. Stable-Marriage cu indiferene (SMT):

- nu mai exist restricia ca listele de preferine s fie ordonate strict cresctor, n

III. Stable-Marriage cu liste incomplete i indiferene (SMTI):

- au loc condiiile prezentate la I i II

stabilitatea slab3: definit ca n cazul instanelor de Stable-Marriage simple

M = puternic stabil dac (, ) ,

super stabilitatea5: M = super stabil dac (, ) , unde

Problemele SMTI sunt instane de Stable-Marriage n care exist conceptul de acceptabili-

Optimizri ale problemelor de tip SMTI

n cazul problemei clasice, Gale i Shapley au propus un algoritm care construiete un SM

Algoritmul lui Kirly pentru probleme de tip SMTI

Algoritmul propus pornete de la un matching deja construit cu algoritmul GS pentru o in-

6 break the ties n eng.

n pseudocod avem definite:

Rulnd cei doi algoritmi pe aceast instan avem urmtoarele output-uri:

7 Prin |M| = cardinalul mulimii M

n aceast seciune vom trata problema Hospitals-Residents:

- un set de elemente prezint o caracteristic, capacitatea, care desemneaz

Fie seturile de elemente H = {1 ,2 }, R = {1 ,2 ,3 , 4 , 5 } i urmtoarele liste de preferine:

Se dorete construcia lui M, unde M = {( , ) | , = 1,3 = 1,3 }

Reprezentarea instanei sub form de graf conform specificaiilor prezentate n [2]:

Rezultatul algoritmului pentru instana propus:

M = {(1, 1 ),(3 , 1),(2 , 2),(4 , 2), (5 , 1)}

Problemele College-Admission, Courses-Repartition sunt tratate exact n acelai mod, n

1.4.1 Stable - Allocation

- numrul de uniti semnific pentru o firm numrul de ore pe care ar dori s le

Fie seturile de elemente F = {1, 2 , 3 }, W = {1 ,2 ,3 , 4 , 5 , 6 , 7 } i urmtoarele liste