Сценарија на случаи на употреба

Дијаграм

Сценарија

Корисник

ID:	1
Случај на употреба:	ги прелистува секциите за дискусија
Опис:	Корисникот ги прелистува сите секции за дискусија и ги чита мислењата напишани во нив.
Тригер:	Корисникот сака да добие информација за конкретен професор или предмет, или пак сака да ги прегледа најновите или најпопуларните мислења од сите секции.
Нормален тек	Акции преземени од корисникот: 1.1 Кликнува на search алатката (HTML форма) и внесува податоци (кирилични или латинични знаци) за субјект кој го интересира ИЛИ 1.2 оди на landing страницата, каде се прикажани последните 10 мислења од категориите „предмет“ и „професор“, сортирани според времето на објавување Акции преземени од системот: 1.1 После >=4 внесени знаци контролерот пречекува барање од HTML формата, кое ги содржи истите во телото и ги пропагира до сервисите одговорни за ентитетите „професор“ и „мислење“, кои потоа поставуваат прашалници до базата за колоната „име“ од двете табели. На контролерот се враќаат сите колони од погодоците, кој потоа ги предава на логиката за рендерирање поглед, која натаму од добиените ИД и име генерира листа од anchor HTML елементи кои водат до соодветната секција за дискусија (страница мапирана на /ИД). 1.2 На секое прикажување на овој поглед, контролерот пречекува соодветно именувано барање без тело и го спореведува истиот тек, само што сервисите кои ги повикува поставуваат друг вид на прашалник (од типот order by time_posted desc limit 10 за двете табели)
Исклучоци:	Во чекорот 1.1, кога search функцијата враќа празно множество, корисникот е информиран дека може да ја користи компонентата за рачно пребарување (која содржи листа на сите професори и предмети за кои има запис во базата, групирани според институција)
Фреквенција на користење:	Највисока (релативно на честотите на користење на останатите случаи)
Забелешки:	Во чекорот 1.1 има дополнителен чекор од страна на browser апликацијата, која повикува функција за транслитерација на влезот во кирилица, за да има совпаѓања со колоната име (бидејќи така се зачувани преземените „статички“ податоци за професорите и предметите).

ID:	2
Случај на употреба:	корисничка најава
Опис:	Корисникот се најавува на апликацијата со своето корисничко име (или e-mail) и лозинка.
Тригер:	Корисникот сака да искористи некои од функционалностите достапни само доколку е најавен
Предуслов:	Претходна регистрација
Нормален тек	Акции преземени од корисникот: 1. Клика на опцијата за најавување (HTML anchor елемент) 2. Доколку веќе има корисничка сметка, ги внесува својот e-mail и лозинка и клика на Најави се, инаку оди на UseCase со ID 3 (корисничка регистрација) т.е. притиска на елемент кој го води на таа страница Акции преземени од системот: 1. Се активира погледот мапиран на /login патеката кој содржи две input полиња за внес на податоците. 2. Се праќа барање до одредена патека на контролерот, кое во телото ги содржи мејлот и лозинката. Аналогно на текот опишан во претходниот use-case, се испитува дали внесени кориснички мејл е претходно зачуван, дали сметката е активирана, се хашира пречеканата лозинка со некој алгоритам за таа намена и се споредува со соодветната колона во базата за торката каде е зачуван мејлот. Во случај на успех, се креира инстанца од HttpSession која содржи податоци за што е авторизиран корисникот (пр. преку getSession().getRoles()) и на прелистувачот се враќа id:String полето од истата. Апликацијата на клиентска страна ја зачувува променливава како колаче што дозволува рендерирање на повеќе погледи за корисникот. Во случај на неуспех, се случува истото, само што апликацијата на клиентска страна детектира од телото на response-от низа од знаци (пр. "error") и добиената сесиска променлива без привилегии ја игнорира.
Исклучоци:	Корисникот ја има заборавено својата лозинка: апликацијата нема функционалност за recovery на сметките.
Фреквенција на користење:	Висока (релативно на честотите на користење на останатите случаи)
Забелешки:	Пожелно е да се овозможи енкрипција на транспортно ниво, зашто user/pass во комуникацијата меѓу серверот и прелистуачот не се енкриптирани т.е. се користи Http Basic Authentication.

ID:	3
Случај на употреба:	корисничка регистрација
Опис:	Корисникот регистрира профил на апликацијата.
Тригер:	Исто како UseCase со ID 2 (корисничка најава)
Предуслов:	валидна e-mail адреса
Нормален тек	Акции преземени од корисникот: 1. Клика на линк кој го води до страницата за регистрација 2. Го пополнува формуларот во кој се бара неговата e-mail адреса, корисничкото име кое сака да го користи, неговото име и презиме (опционално) и лозинката која сака да ја користи за најава и притиска "Submit" 3. Добива електронска порака на наведената адреса со линк за потврда на регистрацијата 4. Клика на линкот за активација на сметката Акции преземени од системот: 1. Апликацијата на клиентска страна го прикажува погледот за регистрација со 4-те полиња и инструкции за нивно правилно пополнување 2. Формата се валидира на клиентска страна (само проверка дали некое од задолжителните полиња е празно) 3. Контролерот го пречекува барањето со 4-те полиња, за чијашто проверка (пр. дали лозинката содржи цифри) повикува сервиси со логика за regex препокривање. Ако ова е во ред, накратко: се креира нова сметка означена како неактивирана и се испраќа мејл со линк што содржи токен за активација 4. Сметката се означува за активирана, а токенот за искористен.
Исклучоци:	За 2.: Некои од полињата во формуларот се празни - барањето за регистрација нема да воопшто да биде пратено. За 3.: не поминува регекс проверката - се фрла исклучок кој го хендла контролерот, враќајки порака за грешка ИЛИ има погодок во базата за внесениот мејл - системот испитува дали таа сметка е активирана. Во слујачот да е, се фрла исклучок некаде во сервисниот слој со кој се справува контролерот така што враќа порака од типот „веќе постои корисник со ова кор. име“. Во случај да таквата сметка не е активирана (пр. истекле 15-те минути додека е валиден активацискиот токен, а корисникот не ја видел пораката), преку одговорниот сервис се генерира и зачувува нов токен и се испраќа нов мејл со линк за активација.
Фреквенција на користење:	Средна (релативно на честотите на користење на останатите случаи)

ID:	4
Случај на употреба:	додава мислење во секција за дискусија
Опис:	Корисникот објавува мислење во врска со одреден професор или предмет.
Тригер:	Корисникот сака да го искаже своето мислење во врска со некој професор или предмет
Предуслов:	Корисникот навигирал до страница за дискусија за професор или предмет
Нормален тек	Акции преземени од корисникот: 1. Притиска на копчето „додади мислење“ или „отвори тема“ (ако е во секција за предмет) 2. Ги внесува бараните податоци и притиска „објави“ 3. На корисникот му се рендерира истата страница, каде сега се прикажува додаденото мислење Акции преземени од системот: 1. Javascript апликацијата јавува modal со полиња за внес на содржина и наслов (условно, само ако се отвара нова тема за предмет) 2. Javascript апликацијата ги валидира полињата (дали некое е празно), по што праќа барање со споменатите полиња, кое на серверска страна го пречекува контролерот и наредува тек од повици што завршува со складирање на диск нова торка во соодветната релација (Post). 3. По добивање на одговорот, JS апликацијата го освежува прелистувачот, значи се прикажува истата страница за дискусија, но во одговорот на fetch повикот за мислењата кои и припаѓаат сега ќе се најде и новододаденото мислење
Исклучоци:	Во 2.: ако некое од полињата е празно, нема да се искомуницира со серверот, а на корисникот ќе му се прикаже порака да ги корегира полињата
Фреквенција на користење:	Средна (релативно на честотите на користење на останатите случаи)
Претпоставки:	Корисникот е претходно најавен на апликацијата
Забелешки:	Натаму, во секој опис на use-case што вклучува претходна најава, се претпоставува дека во телото на HTTP барањата се праќаат и податоци за моменталната сесија.

ID:	5
Случај на употреба:	оценува туѓо мислење
Опис:	Корисникот прави upvote или downvote на мислење објавено од друг корисник, со што влијае на неговата karma.
Тригер:	Корисникот сака да ја оцени т.е. да се изјасни дали се согласува или не со некоја објава
Предуслов:	Корисникот навигирал до страница за дискусија за професор или предмет
Нормален тек	Акции преземени од корисникот: 1. Притиска на некоја од иконите за upvote или downvote (HTML button елементи) кои се наоѓаат на крајот на секое мислење Акции преземени од системот: 1. Апликацијата на клиентска страна со самото вчитување на мислењата кои одговараат на секцијата има достапна во меморија листа од кориснички ИД-а кои го оцениле секое мислење. Врз основа на тоа кликот го игнорира (доколку ИД на моменталниот корисник е исто со некое ИД од листата), или праќа повик до серверот што резултира со додавање на ставка во релацијата што ги чува податоците за оцени (корисник-пост) и инкрементирање/декрементирање на кармата на авторот на корисникот.
Фреквенција на користење:	Висока (релативно на честотите на користење на останатите случаи)
Претпоставки:	Корисникот е претходно најавен на апликацијата

ID:	6
Случај на употреба:	коментира туѓо мислење
Опис:	Корисникот реплицира т.е. остава мислење во врска со мислењето објавено од друг корисник.
Тригер:	Корисникот сака да дополни или да направи забелешка за некоја објава
Предуслов:	Корисникот навигирал до страница за дискусија за професор или предмет
Нормален тек	Акции преземени од корисникот: 1. Притиска на иконата за реплика на мислење (HTML button елемент на крајот на секое мислење) 2. Внесува содржина на коментарот и притиска „објави“ 3. На корисникот му се рендерира истата страница, каде сега се прикажува додаденото мислење Акции преземени од системот: 1. Javascript апликацијата јавува modal со единствено поле за содржина на коментарот 2. Javascript апликацијата проверува дали полето е празно (ако е, не испраќа повик и рендерира порака за грешка), а потоа испраќа барање (кое во телото содржи ИД на засегнатото мислење и содржина на коментарот) до одредена патека на која реагира контролерот. Тој потоа повикува соодветен метод од сервисната логика, што резултира со зачувување на диск нова торка во релацијата за мислења (Post) со атрибут ИД на родител-мислење еднаков на ИД-то добиено во payload-от на барањето. 3. По добивање на одговорот, JS апликацијата го освежува прелистувачот, значи се прикажува истата страница за дискусија, но во одговорот на fetch повикот за мислењата кои и припаѓаат сега ќе се најде и новододадената реплика
Фреквенција на користење:	Средна (релативно на честотите на користење на останатите случаи)
Претпоставки:	Корисникот е претходно најавен на апликацијата

ID:	7
Случај на употреба:	пријавува туѓо мислење
Опис:	Корисникот пријавува кон модераторите мислење објавено од друг корисник, со цел тоа да биде отстрането или изменето.
Тригер:	Корисникот смета дека објавеното мислење не соодветствува на темата, дека е навредливо/содржи говор на омраза, дека е автоматизирана spam порака и сл.
Предуслов:	Корисникот навигирал до страница за дискусија за професор или предмет
Нормален тек	Акции преземени од корисникот: 1. Притиска на иконата за пријава на мислење (HTML button елемент на крајот на секое мислење) 2. Внесува содржина на причината и притиска „пријави“ Акции преземени од системот: 1. Javascript апликацијата јавува modal со единствено поле за содржина на причината 2. Javascript апликацијата проверува дали полето е празно (ако е, не испраќа повик и рендерира порака за грешка), а потоа испраќа барање (кое во телото содржи ИД на засегнатото мислење и содржина на причина) до одговарачката патека на која реагира контролерот. Тој потоа повикува метод од сервисната логика, што резултира со зачувување на диск нова торка во релацијата пријави на мислења (корисник-причина-мислење) со атрибут причина еднаков на „причина“ полето добиено во payload-от на барањето.
Фреквенција на користење:	Ниска (релативно на честотите на користење на останатите случаи)
Претпоставки:	Корисникот е претходно најавен на апликацијата

ID:	8
Случај на употреба:	го уредува својот кориснички профил
Опис:	Корисникот го менува своето корисничко име, лозинка, додава дополнителни информации за себе како име, презиме, место на живеење, каде студира(л) и др.
Тригер:	Зависно од потребите на корисникот
Нормален тек	1. Корисникот е на страницата за уредување кориснички профил 2. Ги менува вредностите на параметрите што сака да ги измени 2.1 (само доколку направи промена на лозинката) Добива порака со линк за потврда на промените по e-mail
Исклучоци:	Грешки при валидација на формата при што промените нема да бидат зачувани и корисникот ќе биде известен за тоа
Приоритет:	Овој случај на употреба нема да се реализира.
Фреквенција на користење:	Средна (релативно на честотите на користење на останатите случаи)
Претпоставки:	Корисникот е претходно најавен на апликацијата

ID:	9
Случај на употреба:	го верификува својот кориснички профил
Опис:	Корисникот го потврдува и поврзува својот идентитет со својот профил на profesori.mk
Тригер:	најчесто за неговите мислења да делуваат покредибилни (самата верификација не нуди дополнителни функционалности)
Предуслов:	документ за идентификација
Нормален тек	1. Корисникот е на страницата за уредување кориснички профил 2. Ја одбира опцијата за верификација на профил и го исполнува формуларот во кој треба да внесе име, презиме и занимање (пр. студент или професор), како и да прикачи јасна слика од документ за идентификација (лична карта или пасош) 3. По некој временски период (макс. 7 дена) добива електронска порака со информацијата дали верификацијата е успешна
Исклучоци:	Грешки при валидација на формата при што барањето за верификација нема да биде поднесено и корисникот ќе биде известен за тоа
Приоритет:	Овој случај на употреба нема да се реализира.
Фреквенција на користење:	Ниска (релативно на честотите на користење на останатите случаи)
Претпоставки:	Корисникот е претходно најавен на апликацијата

Модератор

ID:	10
Случај на употреба:	изменува или брише содржина
Опис:	Модераторот уредува или брише мислења или реплики напишани од корисникот.
Тригер:	несогласност на содржината со правилата на употреба на апликацијата
Предуслов:	Модераторот навигирал до страницата каде се прикажани пријавите за мислења
Нормален тек	Акции преземени од модераторот: 1. Доколку е на страницата каде се прикажани пријавите, притиска на копче „разлгедај“ 2.1 Доколку сака да го измени мислењето, притиска на опцијата за изменување, внесува нова содржина и наслов (доколку мислењето има наслов) и притиска „измени“ 2.2 Доколку сака да го избрише мислењето, ја избира опцијата за бришење и притиска „избриши“ 2.3 Доколку сака да го премести мислењето, ја избира новата секција за дискусија и опционално како дете на кое мислење треба да се постави (default=самостојно мислење) Акции преземени од системот: 1. Апликацијата на клиентска страна рендерира modal со три опции кои соодветсвуваат на можностите за измена, бришење и преместување 2.1 После валидацијата на полињата, се испраќа PUT барање до серверот што секогаш ги содржи: идентификаторот на мислењето, неговата нова содржина и наслов. Ова барање завршува со зачувување на мислењето со ажурираните полиња (се ажурира и полето што чува време кога мислењето е последно изменето) 2.2 Се испраќа DELETE барање што резултира со бришење на мислењето, заедно со сите мислења-потомци и податоци за негови оценки. 2.3 Откако ќе се прими барањето на сервер страната, се вршат проверки за тоа дали акцијата преместување нема да ја наруши структурата на мислењата (пр. преместување на родител како дете на негово дете), по што мислењето, заедно со своите реплики се преместуваат на местото специфицирано со полињата од барањето (ИД на секција и ИД на мислење-татко т.е. некоја falsy вредност за самостојно мислење).

ID:	11
Случај на употреба:	прегледува пријави за содржината
Опис:	Модераторот ги разгледува пријавите за содржина испратени од корисникот.
Тригер:	Одржување на содржината во согласност со правилата за дискусија
Предуслов:	Модераторот навигирал до страницата каде се прикажани пријавите за мислења (неговата почетна страница по најавата)
Нормален тек	Акции преземени од модераторот: 1. Притиска на копчето разгледај, кое се наоѓа до секоја пријава во листата Акции преземени од системот: 1. Се прикажува модалот опишан во случајот погоре, што покрај 3-те опции, содржи и податоци за пријавата, т.е. идентификатор, содржина, време на објава, како и причината за пријава (овие се повлечени од сервер при секој приказ на компонентата за пријави).