Менаџмент информациски системи

UML Use Case Diagram

UML Use Case дијаграмот се користи за да овозможи да се дефинираат барањата што

системот мора да ги исполни. Овој дијаграм опишува кои корисници кои функционалности
(use cases) ги користат на системот, но не адресираат специфични детали на
спроведувањето.

Поточно, користиме Use Case дијаграм за да одговориме на следните прашања:

1. Што се опишува? -​Системот
2. Koj e во интеракција со системот? -​Актерите
3. Што можат да направат актерите? -​Use cases

1. Use Cases
Функции на системот (процеси) кои се означуваат со елипса во која
се опишува функцијата. Во главно секој Use Case e активиран од
некој актер или тригер.

2. Актери
Некој кој е во интеракција со системот. Актерот може да биде
било каков надворешен ентитет (човек, улога, сервер,
организација...) и може да активира use case или да очекува
резултат од некој use case. Најчесто се именува со именка и
се означува со фигура („човече“) или правоаголник.

3. Асоцијации и граници на систем

Врската помеѓу актерите и use cases се нарекува асоцијација и се означува со линија (се
додава бројче за кардиналност доколку е потребно).
Функционалностите на даден систем (use cases) се наоѓаат внатре во даден
правоаголник, кој ги претставува границите на системот.
На сликата може да се види дека имаме ​систем​ за администрација на студенти кој нуди
три функционалности (​use cases​):
- Пребарување на студентски податоци
- Издавање на сертификат
- Објавување на испит
Овие три use cases може да бидат активирани (извршени) од ​актерот​ „Професор“.

4. Релации помеѓу актерите

Актерите често може да имаат заеднички својства и дадени use cases да може да бидат
извршени од повеќе видови актери. Во овој случај се користи ​наследување
(генерализација)​ кај актерите.

Пример: Во системот за администрација на студенти и професорите и асистентите може

да пребаруваат студентски податоци, додека само професорите може креираат курс и да
издаваат сертификат, така што при издавањето на сертификат може да биде вклучен
(опционално) еден асистент. Исто така, асистентот може да објавува задачи.

За оваа цел може да креираме генерализиран актер од која наследуваат и асистентите и

професорите, кој ќе биде одговорен за сите функции кои може да ги извршуваат и
асистентите и професорите.
На сликата подолу треба да забележиме дека двете сценарија се различни.

- На првата слика во извршување на процесот треба да бидат вклучени и професор

и асистент.
- На втората слика извршувањето на процесот е од страна на актер кој наследува
„Research Associate“.

5. Релации помеѓу use cases

Како што постојат релации помеѓу актер и use case, помеѓу актер и актер
(генерализација), така постои и ​релација помеѓу use case и use case. ​Постојат три вида
на релации помеѓу use cases:

5.1 <<include>> релација (или <<uses>>)

Доколку извршувањето на use case „А“, го вклучува и use case „B“,
велиме дека use case „А“ е во ​„include“​ релација со use case „В“. Еден
use case може да вклучува и повеќе use cases. Релацијата се
одбележува со испрекината линија на која пишува „<<include>>“, како
на сликата.
(Објаснување на сликата: Извршувањето на „А“ вклучува извршување на „В“)

5.2 <<extend>> релација

Доколку извршувањето на use case „А“ може да го вклучи (но не мора)
и use case „B“, велиме дека use case „В“ е во ​„extend“​ релација со use
case „А“. Еден use case може да e во „extends“ релација со повеќе use
cases. Релацијата се одбележува со испрекината линија на која пишува
„<<extend>>“, како на сликата.
(Објаснување на сликата: Извршувањето на „А“, може, но не мора да го
вклучи извршувањето на „В“)

Забележете дека кај „include“ стрелката излегува од главниот use case, додека кај
„extends“, стрелката влегува во главниот use case.
5.3 генерализација
Како и кај актерите, така и овде постои ​наследување, ​така што заеднички функции може
да бидат групирани на повисоко ниво. Ако use case „А“ го генерализира use case „В“,
тогаш „В“ го наследува однесувањето на „А“, кое може да го прошири или презапише. Ако
даден use case е „abstract“, тогаш тој не може да се изврши, туку се извршуваат само тие
што наследуваат од него. Релацијата се одбележува со стрелка од изведениот до
главниот use case.

На горниот дијаграм може да се забележи дека даден професор може да:

- најави разговор или предавање
- најави испит
- додели предавач
При најава на разговор или лекција се доделува и предавач, додека при најавување на
лекција може да се најави и испит.
Задача: Да се моделира системот „апликација за банка“ со користење на Use Case
дијаграм:

Корисникот може да се најави на системот, така што се проверува дали внесените

податоци за најава се валидни. Доколку најавата не е успешна, му се прикажува порака
со грешка.
Откако ќе се најави, корисникот може да го провери своето салдо во банката или да
направи трансакција (во овој случај, се прави верификација на трансакцијата).
Трансакцијата може да биде направена или со користење на обични валути или со
користење на криптовалути. Доколку трансакцијата е направена со користење на
криптовалути, се пресметува процент од сумата кој го задржува банката.
Постојат и „премиум“ корисници кои освен останатите функции, можат да ги видат и
цените на валутите во последните 24 часа.

Решение: