== **Use Case Realizations**

----

=== **Сите**

|| **Пристап** ||При впишување на URL-то корисникот ја пристапува login страницата на сајтот. Во навигацискиот бар има опции да се регистрира како одреден тип на корисник (компанија, студент или пак тим) или да внесе корисничко име и лозинка. ||
|| **Login** ||**1.** Внесување на податоците за најава и избор на тоа за каков корисник станува збор, од User, Company и Team. \\ **2.** На фронтенд се сетира состојбата со моментално внесените податоци, а при клик на копчето Login моменталните податоци од состојбата се праќаат преку axios POST повик на Login контролер патернот во бекендот. \\ **3.** При примање на податоците во Login контролерот, бекендот прави повик на функцијата findUser од Account сервисот. \\ **4.** Account сервисот на пониско ниво комуницира со User, Company и Team репозиториумите врз основа на тоа каков тип на account е пратен во реквестот при што ги пребарува нивните табели и соодветно на тоа дали ќе најде некој корисник со внесените account и password резултатот го враќа во објект од типот Account. \\ **5.** Доколку успешно е пронајден корисникот во базата, Login контролерот проверува од кој тип е тој акаунт, односно од кој класен тип е тој објект врз основа на тоа од кој репозиториум е вратен. Соодветно на тоа се испраќаат корисничките информации до фронтендот преку Data Transfer Object. \\ **6.** Доколку не е пронајден таков корисник, на фронтенд се испраќа иницијализиран Login Response DTO (Ова е родител класа на сите login response dto-а) кој иницијално содржи Error кој фронтендот може да го препознае. \\ **7.** При добивање на податоците на фронтендот, доколку успеало најавувањето корисникот е редиректиран до страницата за поглед на профилот. Доколку не постои таков корисник соодветно е испратена порака за непостоечки корисник и е редиректиран до Login страницата повторно. \\ **8.** Со ова завршува најавата на корисникот што е имплементирана на ист начин за било кој тип на корисник. По успешната најава корисникот се наоѓа на страницата за поглед на сопствените податоци. ||
|| **Register** ||**1.** Избор на типот на account кој сака корисникот да го регистрира на иницијалниоут route во сајтот. \\ **2.** Редирекција на фронтенд до компонентите кој одговараат на тој избор (register_company_form.js, register_team_form.js или register_user_form.js). \\ **3.** Доколку се избрани компанија или тим, формата е хендлана на сличен начин како во логин само постира на различни endpoints во бекендот (/api/register/company за компанија и /api/register/team за тим). \\ **4.** По внесување на податоците и клик на Register копчето на фронтенд, на соодветата патека се праќа POST реквест преку axios повик до бекенд. \\ **5.** По примање на податоците на бекенд преку Account Register контролерот, се креира објект од тип Account кој е резултат на функцијата registerCompany или registerTeam. \\ **6.** Во овие функции најпрво се проверува дали сите параметри се внесени. Доколку има некој параметар кој е празен, а е потребен за регистрација, се фрла Invalid Arguments Exception. Доколку се е во ред второ се проерува дали постои таков е-mail во базата преку репозиториумите. Доколку постои корисник со тој e-mail се фрла User Exists Exception. Доколку се е во ред, Се креира нов објект од типот на корисникојт кој се регистрира, во овој случај (компанија или тим) и резултатот од методот save() во репозиториумот се враќа назад во објектот Account во контролерот. \\ **7.** Доколку се регистрира корисник (User) тогаш постапката е малце различна. На фронтенд корисникот треба да избере и листа на вештини кој ги поседува и кој сака да ги научи. \\ **8.** За да се овозможи овој избор, при клик на Register User копчето на фронтенд, се праќа повик до бекендот до Skill контролерот кој за возврат ги дава сите вештини кој ги имаме во базата на вештини. \\ **9.** По примање на вештините на фронтенд се сетира состојбата така што во листите за избор на вештини се листаат сите вештини кој се вратени од бекендот, а како вредност се сетираат ID-ата на истите. \\ **10.** Се креираат две листи од вештини. Првата е за retained skills а втората е за skills to learn. \\ **11.** По избор на вештините од страна на корисникот, на фронтенд се додаваат ID-ата на селектираните вештини во соодветните листи (retained и toLearn) и останатите податоци кој се потребни за регистрација. \\ **11.** Со клик на копчето Register на бекенд се праќаат сите овие податоци преку DTO. \\ **12.** Најпрво се креираат две листи од вештини на бекенд според ID-ата кој се проследени од фронтендот со повик на функцијата returnSkillsBasedOnId што прима листа од тип Long како аргумент. \\ **13.** Оваа функција итерира во базата и ги враќа сите вештини според нивните ID-а. \\ **14.** По ова се повторува постапката како кај компании и тимови, само додатно после зачувување во базата се повикува функцијата setUpUser кој го прима зачуваниот корисник како аргумент. \\ **15.** Оваа фунција го повикува Matchmaker сервисот кој најпрво ги брише сите податоци за постоечки корисник доколку истиот го има. \\ **16.** Потоа креира листи од сите Jobs, Internships и Projects. \\ **17.** Итерира низ сите листи по ред и повикува соодветни функции за setUpUserMatches кој примаат работа и корисник како аргументи. \\ **18.** Оваа функција прави листи од вештините на работата и корисникот, а потоа го пресметува коефициентот на усогласеност преку статичната функција match од Мatchmaker класата. \\ **19.** match функцијата го зема како иницијален коефициент бројот на вештини на работата, а потоа итерира низ сите вештини на работата и на корисникот, доколку тие одговараат има променлива која што се зголемува за 1. \\ **20.** Кога ќе завршат сите итерации се враќа коефициентот како резултат на делење помеѓу променливата која се зголемува и иницијалниот коефициент, односно бројот на вештини во работата. Резултатот на ова е секогаш float помеѓу 0 и 1. \\ **21.** Кога ќе го добиеме коефициентот се креира нов запис во табелата за усогласување со ID на корисникот, ID на работата и коефициент на усогласеност. Ова се повторува и за Internships и за Projects. \\ **22.** Доколку се ова е завршено успешно и Account променливата во контролерот има вредност различна од null се враќа Map<String, String> со success и порака за успех. Доколку има проблем се праќа истата мапа со порака за error. \\ **23.** По примање на пораката на фронтенд, доколку е успешно се редиректира на login рутата, доколку има некаков проблем се редиректира на register рутата со соодветната порака за проблем.||

=== **Студент**

|| **ID** || **Use Case Realization** ||
|| **1** ||**Пребарува пракса/работа/проект според клучен збор** \\ **1.** По успешна најава User тип на корисник има опција во навигацискиот бар да пребарува работа/пракса/проект според клучен збор. \\ **2.** Kорисникот внесува некој клучен збор на фронтенд и избира каков тип на работа бара. Ова се одвива преку форма, која постира на бекендот на патека /api/search и соодветно /job, /internship или /project. Ова се одвива преку Search контролерот кој комуницира со Work сервисот преку функцијата за full-text search која е различна за сите типови на работа. \\ **3.** соодветно во функцијата се креираат филтрирани листи преку итерации на сите работи кој содржат вештина или дескрипција/име ист онаков како текстот кој е внесен како параметар во пребарувањето. \\ **4.** По итерациите се враќа листа на одредени работи кој одговараат на критериумот, при што истите се испраќаат на фронтенд каде соодветно се додаваат во состојбата на реакт компонентата која врши real-time refresh на клиентот и ги листа резултатите од пребарувањето. ||
|| **2** и **3** ||**Ажурира лични податоци / Ажурира вештини кој ги поседува или сака да ги стекне** \\ **1.** По најавата, корисникот може да одбере да ги смени својте лични податоци. По кликање на копчето Edit на фронтендот корисникот е редиректиран во рамките на фронтендот, на посебна форма во која може да ги внесе промените кој сака да ги направи на својот профил. \\ **2.** По кликање на Edit копчето, корисникот е редиректиран до рутата за Edit при што вредностите на полињата во формата се популираат од самата реакт состојба за моментално најавениот корисник. \\ **3.** По внесување на соодветните промени и кликање на копчето Confirm се праќа Post request на бекендот кој го прима патеката /api/edit/account и /user/{userid}/{userEmail}. \\ **4.** Ова се разликува за различните типови на корисници. По пристап на оваа патека, бекендот ги зема податоците за корисникот како и неговиот id и email кој се променливи во патеката. \\ **5.** Потоа враќа Optional која е резултат на повик до функцијата од Account сервисот - findByIdAndEmail која прима 3 аргументи, id, email и тип на корисник. \\ **6.** Ова за возврат прави повик до соодветните репозиториуми според тоа каков тип на акаунт бара едит. \\ **7.** Доколку тој email и тоа id постојат, односно Optional објектот не е празен, се креираат две листи од вештини кој се земаат од база врз основа на нивните id-a кој се праќаат од корисникот како List<Long> (Исто како за регистрација.) \\ **8.** Потоа се повикува Account сервис функцијата editUser која ги прима сите нови вредности како параметри. \\ **9.** Оваа функција функционира на ист начин како кај регистрацијата, само разликата е што во овој случај се прави overwrite на постоечки корисник со одредено ID. дали постои тој email, доколку постои се фрла exception кој е хендлан така што на фронтендот му праќа објект со error и е презентиран во формата за едит на податоци. Доколку новиот e-mail помине се зачувува нови гради UserResponseDTO Кој ги праќа новите податоци до фронтендот и корисникот се редиректира назад на профилот на фронтендот. ||


=== **Компанија**

|| **ID** || **Use Case Realization** ||
|| 4 ||**Објавува работа/пракса за која се потребни одредени вештини** По најава како компанија, која се одвива исто како за секој корисник, компанијата може да одбере да регистрира работа или пракса. По избор на тоа што сака да регистрира, е редиректирана на соодветната страна на фронтендот, која содржи форма во која треба да се пополнат податоците за соодветно работата или праксата. По пополнувањето се клика на копче за Confirm при што се праќаат податоците до бекендот преку формата на патека /api/register/work и соодветно /job или /internship. По прифаќање на податоците бекендот проверува дали корисникот кој ја постирал работата има привилегии да го направи тоа. Доколку има се креира нова работа и се додава во базата преку WorkService сервисот. При регистрација на било каква работа MatchmakerService сервисот одново ги мечува сите корисници со ново внесените работи, пракси или проекти и ги зачувува коефициентите во базата. По завршување на сето ова на компанија корисникот му се враќа ново внесената работа како објект на фронтендот. Од таму оваа работа се додава во листата на сите работи на тој корисник, се редиректира до работите и се прикажува новата листа. Иста е постапката и за internship. ||
|| 5 ||**Ажурира податоци за веќе објавена работа/пракса** Ова се одвива преку истата форма за креирање на работа/пракса само разликата е што се постира на различна патека, во овој случај /api/edit/work и /job/{id} или /internship/{id}. Доколку се внесени валидни информации, и корисникот кој го праќа барањето за едит е корисникот кој ја регистрирал таа работа, тогаш се пристапува до функцијата editJob или editInternship кој соодветно пристапуваат до базата и ги презапишуваат податоците. ||
|| 6 ||**Ажурира податоци за компанијата** Ова се одвива на ист начин како кај корисникот само се разгранува во соодветните функции кој се однесуваат за компаниите во бекендот. ||

=== **Тим**

|| **ID** || **Use Case Realization** ||
|| 7 || **Објавува проекти/работа за која се потребни одредени вештини** Ист начин како кај компанијата само место internship тимовите објавуваат project. И се пристапува до соодветните endpoints. ||
|| 8 || **Ажурира податоци за веќе објавени проект/работа** Ист начин како кај компанијата. ||
|| 9 || **Ажурира податоци за тимот** И ова е исто како и во претходните случаи само се пристапува до team endpoint кој ги повикува соодветните сервиси. ||

=== **Систем**

|| **Ги прикажува сите огласи на фирмите/тимовите кога ќе се најават** || При најава компаниите и тимовите имаат табови да изберат поглед кој Jobs/Internships/Projects соодветно, при чие кликање се редиректираат на фронтендот во нов поглед кој ги листа резултатите кој се добиени од бекенд при најавата за соодветните регистрирани работи чие accountId е еднакво на id-to на моментално најавениот корисник. Ова се случува на фронтенд и нема екстра повици до бекендот, освен иницијалниот при најава. ||
||**Нуди релевантна работа или пракса на студентите при најава**||При најава на User корисник системот ги зема сите мечувани податоци од базата и ги праќа како листа на најавениот корисник и ги прикажува во соодветните табови на веб апликацијата. ||