Changes between Version 77 and Version 78 of UseCaseScenarios
- Timestamp:
- 02/18/23 19:25:19 (23 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
UseCaseScenarios
v77 v78 8 8 ||= **Опис:** =|| Корисникот ги прелистува сите секции за дискусија и ги чита мислењата напишани во нив. || 9 9 ||= **Тригер:** =|| Корисникот сака да добие информација за конкретен професор или предмет, или пак сака да ги прегледа најновите или најпопуларните мислења од сите секции. || 10 ||= **Предуслов:** =|| / ||11 ||= **Постуслов:** =|| / ||12 10 ||= **Нормален тек** =||''Акции преземени од корисникот:'' \\ **1.1** Кликнува на search алатката (HTML форма) и внесува податоци (кирилични или латинични знаци) за субјект кој го интересира ''ИЛИ'' \\ **1.2** оди на landing страницата, каде се прикажани последните 10 мислења од категориите „предмет“ и „професор“, сортирани според времето на објавување \\ \\ ''Акции преземени од системот:'' \\ **1.1** После >=4 внесени знаци контролерот пречекува барање од HTML формата, кое ги содржи истите во телото и ги пропагира до сервисите одговорни за ентитетите „професор“ и „мислење“, кои потоа поставуваат прашалници до базата за колоната „име“ од двете табели. На контролерот се враќаат сите колони од погодоците, кој потоа ги предава на логиката за рендерирање поглед, која натаму од добиените ИД и име генерира листа од anchor HTML елементи кои водат до соодветната секција за дискусија (страница мапирана на /ИД). \\ **1.2** На секое прикажување на овој поглед, контролерот пречекува соодветно именувано барање без тело и го спореведува истиот тек, само што сервисите кои ги повикува поставуваат друг вид на прашалник (од типот ''order by time_posted desc limit 10'' за двете табели) || 13 11 ||= **Исклучоци:** =|| Во чекорот **1.1**, кога search функцијата враќа празно множество, корисникот е информиран дека може да ја користи компонентата за рачно пребарување (која содржи листа на сите професори и предмети за кои има запис во базата, групирани според институција) || 14 ||= **Вклучува:** =|| ||15 ||= **Приоритет:** =|| / ||16 12 ||= **Фреквенција на користење:** =|| Највисока (релативно на честотите на користење на останатите случаи) || 17 ||= **Бизнис правила:** =|| / ||18 ||= **Специјални побарувања:** =|| / ||19 ||= **Претпоставки:** =|| / ||20 13 ||= **Забелешки:** =|| Во чекорот **1.1** има дополнителен чекор од страна на browser апликацијата, која повикува функција за транслитерација на влезот во кирилица, за да има совпаѓања со колоната име (бидејќи така се зачувани преземените „статички“ податоци за професорите и предметите). || 21 14 // … … 25 18 ||= **Тригер:** =|| Корисникот сака да искористи некои од функционалностите достапни само доколку е најавен || 26 19 ||= **Предуслов:** =|| Претходна регистрација || 27 ||= **Постуслов:** =|| / ||28 20 ||= **Нормален тек** =|| ''Акции преземени од корисникот:'' \\ **1.** Клика на опцијата за најавување (HTML anchor елемент)\\ **2.** Доколку веќе има корисничка сметка, ги внесува својот e-mail и лозинка и клика на ''Најави се'', инаку оди на !UseCase со ID 3 (корисничка регистрација) т.е. притиска на елемент кој го води на таа страница \\ \\ ''Акции преземени од системот:'' \\ **1.** Се активира погледот мапиран на /login патеката кој содржи две input полиња за внес на податоците. \\ **2.** Се праќа барање до одредена патека на контролерот, кое во телото ги содржи мејлот и лозинката. Аналогно на текот опишан во претходниот use-case, се испитува дали внесени кориснички мејл е претходно зачуван, дали сметката е активирана, се хашира пречеканата лозинка со некој алгоритам за таа намена и се споредува со соодветната колона во базата за торката каде е зачуван мејлот. Во случај на успех, се креира инстанца од HttpSession која содржи податоци за што е авторизиран корисникот (пр. преку getSession().getRoles()) и на прелистувачот се враќа id:String полето од истата. Апликацијата на клиентска страна ја зачувува променливава како колаче што дозволува рендерирање на повеќе погледи за корисникот. Во случај на неуспех, се случува истото, само што апликацијата на клиентска страна детектира од телото на response-от низа од знаци (пр. "error") и добиената сесиска променлива без привилегии ја игнорира. || 29 21 ||= **Исклучоци:** =|| Корисникот ја има заборавено својата лозинка: апликацијата нема функционалност за recovery на сметките. || 30 ||= **Вклучува:** =|| / ||31 ||= **Приоритет:** =|| / ||32 22 ||= **Фреквенција на користење:** =|| Висока (релативно на честотите на користење на останатите случаи) || 33 ||= **Бизнис правила:** =|| / ||34 ||= **Специјални побарувања:** =|| / ||35 ||= **Претпоставки:** =|| / ||36 23 ||= **Забелешки:** =|| Пожелно е да се овозможи енкрипција на транспортно ниво, зашто user/pass во комуникацијата меѓу серверот и прелистуачот не се енкриптирани т.е. се користи Http Basic Authentication. || 37 24 // … … 41 28 ||= **Тригер:** =|| Исто како !UseCase со ID 2 (корисничка најава) || 42 29 ||= **Предуслов:** =|| валидна e-mail адреса || 43 ||= **Постуслов:** =|| / ||44 30 ||= **Нормален тек** =|| ''Акции преземени од корисникот:'' \\ **1.** Клика на линк кој го води до страницата за регистрација\\ **2.** Го пополнува формуларот во кој се бара неговата e-mail адреса, корисничкото име кое сака да го користи, неговото име и презиме (опционално) и лозинката која сака да ја користи за најава и притиска "Submit" \\ **3.** Добива електронска порака на наведената адреса со линк за потврда на регистрацијата \\ **4.** Клика на линкот за активација на сметката \\ \\ ''Акции преземени од системот:'' \\ **1.** Апликацијата на клиентска страна го прикажува погледот за регистрација со 4-те полиња и инструкции за нивно правилно пополнување\\ **2.** Формата се валидира на клиентска страна (само проверка дали некое од задолжителните полиња е празно) \\ **3.** Контролерот го пречекува барањето со 4-те полиња, за чијашто проверка (пр. дали лозинката содржи цифри) повикува сервиси со логика за regex препокривање. Ако ова е во ред, накратко: се креира нова сметка означена како неактивирана и се испраќа мејл со линк што содржи токен за активација \\ **4.** Сметката се означува за активирана, а токенот за искористен. || 45 31 ||= **Исклучоци:** =|| За **2.**: Некои од полињата во формуларот се празни - барањето за регистрација нема да воопшто да биде пратено. \\ За **3.**: не поминува регекс проверката - се фрла исклучок кој го хендла контролерот, враќајки порака за грешка ''ИЛИ'' има погодок во базата за внесениот мејл - системот испитува дали таа сметка е активирана. Во слујачот да е, се фрла исклучок некаде во сервисниот слој со кој се справува контролерот така што враќа порака од типот „веќе постои корисник со ова кор. име“. Во случај да таквата сметка не е активирана (пр. истекле 15-те минути додека е валиден активацискиот токен, а корисникот не ја видел пораката), преку одговорниот сервис се генерира и зачувува нов токен и се испраќа нов мејл со линк за активација. || 46 ||= **Вклучува:** =|| / ||47 ||= **Приоритет:** =|| / ||48 32 ||= **Фреквенција на користење:** =|| Средна (релативно на честотите на користење на останатите случаи) || 49 ||= **Бизнис правила:** =|| / ||50 ||= **Специјални побарувања:** =|| / ||51 ||= **Претпоставки:** =|| / ||52 ||= **Забелешки:** =|| / ||53 33 // 54 34 ||= **ID:** =|| 4 || … … 57 37 ||= **Тригер:** =|| Корисникот сака да го искаже своето мислење во врска со некој професор или предмет || 58 38 ||= **Предуслов:** =|| Корисникот навигирал до страница за дискусија за професор или предмет || 59 ||= **Постуслов:** =|| / ||60 39 ||= **Нормален тек** =|| ''Акции преземени од корисникот:'' \\ **1.** Притиска на копчето „додади мислење“ или „отвори тема“ (ако е во секција за предмет) \\ **2.** Ги внесува бараните податоци и притиска „објави“ \\ **3.** На корисникот му се рендерира истата страница, каде сега се прикажува додаденото мислење \\ \\ ''Акции преземени од системот:'' \\ **1.** Javascript апликацијата јавува modal со полиња за внес на содржина и наслов (условно, само ако се отвара нова тема за предмет) \\ **2.** Javascript апликацијата ги валидира полињата (дали некое е празно), по што праќа барање со споменатите полиња, кое на серверска страна го пречекува контролерот и наредува тек од повици што завршува со складирање на диск нова торка во соодветната релација (Post). \\ **3.** По добивање на одговорот, JS апликацијата го освежува прелистувачот, значи се прикажува истата страница за дискусија, но во одговорот на fetch повикот за мислењата кои и припаѓаат сега ќе се најде и новододаденото мислење || 61 40 ||= **Исклучоци:** =|| Во **2.**: ако некое од полињата е празно, нема да се искомуницира со серверот, а на корисникот ќе му се прикаже порака да ги корегира полињата || 62 ||= **Вклучува:** =|| / ||63 ||= **Приоритет:** =|| / ||64 41 ||= **Фреквенција на користење:** =|| Средна (релативно на честотите на користење на останатите случаи) || 65 ||= **Бизнис правила:** =|| / ||66 ||= **Специјални побарувања:** =|| / ||67 42 ||= **Претпоставки:** =|| Корисникот е претходно најавен на апликацијата || 68 43 ||= **Забелешки:** =|| Натаму, во секој опис на use-case што вклучува претходна најава, се претпоставува дека во телото на HTTP барањата се праќаат и податоци за моменталната сесија. || … … 73 48 ||= **Тригер:** =|| Корисникот сака да ја оцени т.е. да се изјасни дали се согласува или не со некоја објава || 74 49 ||= **Предуслов:** =|| Корисникот навигирал до страница за дискусија за професор или предмет || 75 ||= **Постуслов:** =|| / ||76 50 ||= **Нормален тек** =|| ''Акции преземени од корисникот:'' \\ **1.** Притиска на некоја од иконите за upvote или downvote (HTML button елементи) кои се наоѓаат на крајот на секое мислење \\ \\ ''Акции преземени од системот:'' \\ **1.** Апликацијата на клиентска страна со самото вчитување на мислењата кои одговараат на секцијата има достапна во меморија листа од кориснички ИД-а кои го оцениле секое мислење. Врз основа на тоа кликот го игнорира (доколку ИД на моменталниот корисник е исто со некое ИД од листата), или праќа повик до серверот што резултира со додавање на ставка во релацијата што ги чува податоците за оцени (корисник-пост) и инкрементирање/декрементирање на кармата на авторот на корисникот. || 77 ||= **Исклучоци:** =|| / ||78 ||= **Вклучува:** =|| / ||79 ||= **Приоритет:** =|| / ||80 51 ||= **Фреквенција на користење:** =|| Висока (релативно на честотите на користење на останатите случаи) || 81 ||= **Бизнис правила:** =|| / ||82 ||= **Специјални побарувања:** =|| / ||83 52 ||= **Претпоставки:** =|| Корисникот е претходно најавен на апликацијата || 84 ||= **Забелешки:** =|| / ||85 53 // 86 54 ||= **ID:** =|| 6 || … … 89 57 ||= **Тригер:** =|| Корисникот сака да дополни или да направи забелешка за некоја објава || 90 58 ||= **Предуслов:** =|| Корисникот навигирал до страница за дискусија за професор или предмет || 91 ||= **Постуслов:** =|| / ||92 59 ||= **Нормален тек** =|| ''Акции преземени од корисникот:'' \\ **1.** Притиска на иконата за реплика на мислење (HTML button елемент на крајот на секое мислење) \\ **2.** Внесува содржина на коментарот и притиска „објави“ \\ **3.** На корисникот му се рендерира истата страница, каде сега се прикажува додаденото мислење \\ \\ ''Акции преземени од системот:'' \\ **1.** Javascript апликацијата јавува modal со единствено поле за содржина на коментарот \\ **2.** Javascript апликацијата проверува дали полето е празно (ако е, не испраќа повик и рендерира порака за грешка), а потоа испраќа барање (кое во телото содржи ИД на засегнатото мислење и содржина на коментарот) до одредена патека на која реагира контролерот. Тој потоа повикува соодветен метод од сервисната логика, што резултира со зачувување на диск нова торка во релацијата за мислења (Post) со атрибут ИД на родител-мислење еднаков на ИД-то добиено во payload-от на барањето. \\ **3.** По добивање на одговорот, JS апликацијата го освежува прелистувачот, значи се прикажува истата страница за дискусија, но во одговорот на fetch повикот за мислењата кои и припаѓаат сега ќе се најде и новододадената реплика || 93 ||= **Исклучоци:** =|| / ||94 ||= **Вклучува:** =|| / ||95 ||= **Приоритет:** =|| / ||96 60 ||= **Фреквенција на користење:** =|| Средна (релативно на честотите на користење на останатите случаи) || 97 ||= **Бизнис правила:** =|| / ||98 ||= **Специјални побарувања:** =|| / ||99 61 ||= **Претпоставки:** =|| Корисникот е претходно најавен на апликацијата || 100 ||= **Забелешки:** =|| / ||101 62 // 102 63 ||= **ID:** =|| 7 || … … 105 66 ||= **Тригер:** =|| Корисникот смета дека објавеното мислење не соодветствува на темата, дека е навредливо/содржи говор на омраза, дека е автоматизирана spam порака и сл. || 106 67 ||= **Предуслов:** =|| Корисникот навигирал до страница за дискусија за професор или предмет || 107 ||= **Постуслов:** =|| / ||108 68 ||= **Нормален тек** =|| ''Акции преземени од корисникот:'' \\ **1.** Притиска на иконата за пријава на мислење (HTML button елемент на крајот на секое мислење) \\ **2.** Внесува содржина на причината и притиска „пријави“ \\ \\ ''Акции преземени од системот:'' \\ **1.** Javascript апликацијата јавува modal со единствено поле за содржина на причината \\ **2.** Javascript апликацијата проверува дали полето е празно (ако е, не испраќа повик и рендерира порака за грешка), а потоа испраќа барање (кое во телото содржи ИД на засегнатото мислење и содржина на причина) до одговарачката патека на која реагира контролерот. Тој потоа повикува метод од сервисната логика, што резултира со зачувување на диск нова торка во релацијата пријави на мислења (корисник-причина-мислење) со атрибут причина еднаков на „причина“ полето добиено во payload-от на барањето. || 109 ||= **Исклучоци:** =|| / ||110 ||= **Вклучува:** =|| / ||111 ||= **Приоритет:** =|| / ||112 69 ||= **Фреквенција на користење:** =|| Ниска (релативно на честотите на користење на останатите случаи) || 113 ||= **Бизнис правила:** =|| / ||114 ||= **Специјални побарувања:** =|| / ||115 70 ||= **Претпоставки:** =|| Корисникот е претходно најавен на апликацијата || 116 ||= **Забелешки:** =|| / ||117 71 // 118 72 ||= **ID:** =|| 8 || … … 120 74 ||= **Опис:** =|| Корисникот го менува своето корисничко име, лозинка, додава дополнителни информации за себе како име, презиме, место на живеење, каде студира(л) и др. || 121 75 ||= **Тригер:** =|| Зависно од потребите на корисникот || 122 ||= **Предуслов:** =|| / ||123 ||= **Постуслов:** =|| / ||124 76 ||= **Нормален тек** =|| 1. Корисникот е на страницата за уредување кориснички профил\\ 2. Ги менува вредностите на параметрите што сака да ги измени\\ 2.1 (само доколку направи промена на лозинката) Добива порака со линк за потврда на промените по e-mail || 125 77 ||= **Исклучоци:** =|| Грешки при валидација на формата при што промените нема да бидат зачувани и корисникот ќе биде известен за тоа || 126 ||= **Вклучува:** =|| / ||127 78 ||= **Приоритет:** =|| ''Овој случај на употреба нема да се реализира.'' || 128 79 ||= **Фреквенција на користење:** =|| Средна (релативно на честотите на користење на останатите случаи) || 129 ||= **Бизнис правила:** =|| / ||130 ||= **Специјални побарувања:** =|| / ||131 80 ||= **Претпоставки:** =|| Корисникот е претходно најавен на апликацијата || 132 ||= **Забелешки:** =|| / ||133 81 // 134 82 ||= **ID:** =|| 9 || … … 137 85 ||= **Тригер:** =|| најчесто за неговите мислења да делуваат покредибилни (самата верификација не нуди дополнителни функционалности) || 138 86 ||= **Предуслов:** =|| документ за идентификација || 139 ||= **Постуслов:** =|| / ||140 87 ||= **Нормален тек** =|| 1. Корисникот е на страницата за уредување кориснички профил\\ 2. Ја одбира опцијата за верификација на профил и го исполнува формуларот во кој треба да внесе име, презиме и занимање (пр. студент или професор), како и да прикачи јасна слика од документ за идентификација (лична карта или пасош)\\ 3. По некој временски период (макс. 7 дена) добива електронска порака со информацијата дали верификацијата е успешна || 141 88 ||= **Исклучоци:** =|| Грешки при валидација на формата при што барањето за верификација нема да биде поднесено и корисникот ќе биде известен за тоа || 142 ||= **Вклучува:** =|| / ||143 89 ||= **Приоритет:** =|| ''Овој случај на употреба нема да се реализира.'' || 144 90 ||= **Фреквенција на користење:** =|| Ниска (релативно на честотите на користење на останатите случаи) || 145 ||= **Бизнис правила:** =|| / ||146 ||= **Специјални побарувања:** =|| / ||147 91 ||= **Претпоставки:** =|| Корисникот е претходно најавен на апликацијата || 148 ||= **Забелешки:** =|| / ||149 92 === Модератор 150 93 ||= **ID:** =|| 10 || … … 152 95 ||= **Опис:** =|| Модераторот уредува или брише мислења или реплики напишани од корисникот. || 153 96 ||= **Тригер:** =|| несогласност на содржината со правилата на употреба на апликацијата || 154 ||= **Предуслов:** =|| / ||155 ||= **Постуслов:** =|| / ||156 97 ||= **Нормален тек** =|| 1. Модераторот е на секцијата за дискусија каде се наоѓа мислењето\\ 2.1 Ја одбира опцијата за бришење ИЛИ\\ 2.2 Ја одбира опцијата за уредување, ги прави измените || 157 ||= **Исклучоци:** =|| / ||158 ||= **Вклучува:** =|| / ||159 ||= **Приоритет:** =|| / ||160 98 ||= **Фреквенција на користење:** =|| Висока (релативно на честотите на користење на останатите случаи) || 161 ||= **Бизнис правила:** =|| / ||162 ||= **Специјални побарувања:** =|| / ||163 ||= **Претпоставки:** =|| / ||164 ||= **Забелешки:** =|| / ||165 99 // 166 100 ||= **ID:** =|| 11 || … … 168 102 ||= **Опис:** =|| Модераторот ги разгледува пријавите за содржина испратени од корисникот. || 169 103 ||= **Тригер:** =|| Одржување на содржината во согласност со правилата за дискусија || 170 ||= **Предуслов:** =|| / ||171 ||= **Постуслов:** =|| / ||172 104 ||= **Нормален тек** =|| 1. Модераторот е во делот за прегледување пријавена содржина\\ 2. Доколку образложението на пријавата има смисла т.е. правилата за дискусија се прекршени, има опција да ја измени или избрише содржината || 173 ||= **Исклучоци:** =|| / ||174 ||= **Вклучува:** =|| / ||175 ||= **Приоритет:** =|| / ||176 105 ||= **Фреквенција на користење:** =|| Висока (релативно на честотите на користење на останатите случаи) || 177 ||= **Бизнис правила:** =|| / ||178 ||= **Специјални побарувања:** =|| / ||179 ||= **Претпоставки:** =|| / ||180 ||= **Забелешки:** =|| / ||
