UML i slučajevi korištenja

Šta učimo ovog semestra

Petnaest sedmica, svaka s tri časa teorije i tri časa prakse. Danas: poglavlje 5 (Sedmica 5, označeno). Isti primjer kroz knjigu: DeliveryApp, narudžba N-1001 (24,50 €).

Literatura

1. B. Popović, K. Kuk: Informacioni sistemi, Kriminalističko-policijski univerzitet, Beograd, 2017.
2. J. S. Valacich, J. F. George: Modern Systems Analysis and Design, 9th ed., Pearson, 2020.
3. L. Jelenković: Sustavi za rad u stvarnom vremenu – skripta, FER, Zagreb, 2015.
4. D. Milićev: Programiranje u realnom vremenu – skripta, Beograd, 2002.
5. V. Kovačević, M. Popović: Sistemska programska podrška u realnom vremenu 1, FTN, Novi Sad, 2013.

Priča za početak

Zašto ovo poglavlje

U poglavlju 4 nacrtali smo proces narudžbe po stazama: ko šta radi i kojim redom. Sada se pitamo drugačije: šta sve sistem DeliveryApp nudi svakom svom korisniku? Odgovor daje dijagram slučajeva korištenja, prvi od UML dijagrama koje učimo. Poglavlje počinje pregledom UML-a: šta je, koje dijagrame ima i čime se crta. Zatim crtamo slučajeve korištenja DeliveryApp s akterima i vezama. Na kraju jedan slučaj, „Naruči hranu”, opisujemo do detalja: glavni tok, alternativne tokove i dijagram aktivnosti. Na praktičnoj nastavi crtamo dijagram u PlantUML-u i pišemo specifikaciju.

Riječi ovog poglavlja (1/3)

• UML (Unified Modeling Language) – objedinjeni jezik za modelovanje: dogovorene oznake za crtanje softverskih sistema.
• Strukturni dijagram – UML dijagram koji pokazuje od čega se sistem sastoji (npr. klase).
• Dijagram ponašanja – UML dijagram koji pokazuje šta sistem radi i kako se mijenja (npr. slučajevi korištenja, stanja).
• Akter – uloga (čovjek ili drugi sistem) koja koristi sistem ili s njim razgovara.
• Slučaj korištenja (use case) – cilj koji akter postiže uz pomoć sistema (npr. „Naruči hranu”).
• Granica sistema – pravougaonik koji pokazuje šta je unutar sistema koji pravimo.

Riječi ovog poglavlja (2/3)

• «include» – slučaj korištenja koji se uvijek izvrši kao dio drugog (npr. „Izračunaj cijenu” u „Naruči hranu”).
• «extend» – slučaj korištenja koji se ponekad, pod uslovom, doda drugom (npr. „Primijeni kod popusta”).
• Specifikacija slučaja korištenja – tekstualni opis jednog slučaja: preduslovi, glavni tok, alternativni tokovi, postuslovi.
• Glavni tok – uobičajen, uspješan put kroz slučaj korištenja.
• Alternativni tok – drugačiji put: greška, izuzetak ili izbor korisnika.
• Scenarij – jedan konkretan put kroz slučaj korištenja, od početka do kraja.

Riječi ovog poglavlja (3/3)

• Dijagram aktivnosti – UML dijagram toka koraka, odluka i paralelnih poslova.
• PlantUML – alat koji UML dijagrame crta iz teksta, slično Mermaidu.

Ciljevi poglavlja

Nakon poglavlja možete:

objasniti šta je UML, ko ga je napravio i čemu služi; razlikovati strukturne dijagrame i dijagrame ponašanja i navesti najvažnije od njih; izabrati alat za crtanje UML-a; prepoznati aktere DeliveryApp, primarne i sekundarne; imenovati slučajeve korištenja kao ciljeve aktera; nacrtati dijagram slučajeva korištenja s granicom sistema, asocijacijama i vezama «include» i «extend»; prepoznati česte greške na dijagramu; napisati specifikaciju slučaja korištenja „Naruči hranu” s glavnim i alternativnim tokovima; iz specifikacije izvesti scenarije i testove; nacrtati dijagram aktivnosti s odlukom i paralelnim tokom.

Plan poglavlja – Sedmica 5: tri časa teorije i tri časa praktične nastave

5.1 Jedan jezik za crtanje softvera

Do devedesetih godina dvadesetog vijeka postojalo je desetak različitih načina crtanja softvera. Jedan autor je klasu crtao kao oblak, drugi kao pravougaonik, treći kao krug. Dijagram jedne firme druga firma nije mogla pročitati bez rječnika. UML (engleski Unified Modeling Language, objedinjeni jezik za modelovanje) je nastao da to riješi: jedan skup oznaka koji razumiju svi.

Tri stvari treba znati o UML-u od početka:

1. UML je jezik, a ne metoda. On kaže kako se nešto crta (klasa je pravougaonik s tri dijela), ali ne kaže kojim redom projektovati ni koje dijagrame obavezno nacrtati. Redoslijed bira tim (poglavlje 2).
2. UML je standard. Održava ga organizacija OMG (Object Management Group), ista koja održava BPMN. Prva usvojena verzija je iz 1997, a današnja grana je UML 2.
3. UML se koristi u mjeri. Niko ne crta sve dijagrame za svaki sistem. Crta se ono što pomaže da se nešto razumije ili dogovori, i to dovoljno detaljno za tu svrhu.

Slika iz života: UML je kao notni zapis u muzici. Note ne komponuju pjesmu umjesto kompozitora, ali omogućavaju da pjesmu koju je jedan napisao drugi odsvira bez razgovora. Isto tako, klasni dijagram koji je nacrtao analitičar u Brčkom programer u Beču može pročitati bez prevodioca.

5.1 Jedan jezik za crtanje softvera

Ukratko – 5.1 Jedan jezik za crtanje softvera

• UML je objedinjeni jezik za modelovanje softvera, usvojen u OMG-u 1997. godine.
• UML je jezik, a ne metoda: kaže kako se crta, a ne kojim redom se projektuje.
• Dijagrami se crtaju u mjeri u kojoj pomažu da se nešto razumije ili dogovori.
• Kao notni zapis, UML omogućava da dijagram jednog autora pročita bilo ko.

5.2 Porodica UML dijagrama

UML 2 ima četrnaest vrsta dijagrama, podijeljenih u dvije grupe:

• Strukturni dijagrami pokazuju od čega se sistem sastoji: koje stvari postoje i kako su povezane. Kao plan kuće: sobe, zidovi, vrata.
• Dijagrami ponašanja pokazuju šta sistem radi i kako se mijenja kroz vrijeme. Kao opis jednog dana u kući: ko ulazi, gdje ide, šta radi.

Ne treba ih sve znati napamet. U ovoj knjizi crtamo pet najvažnijih, koji pokrivaju veliku većinu stvarnih potreba:

5.2 Porodica UML dijagrama

Od ostalih vrijedi čuti za dijagram komponenti (od kojih većih dijelova je sistem složen), dijagram razmještaja (na kojim računarima koji dio radi), dijagram paketa (kako je kod grupisan) i dijagram objekata (stvarni primjerci klasa u jednom trenutku). Na arhitekturu se vraćamo u poglavlju 9, gdje umjesto komponenti i razmještaja koristimo jednostavniji C4 model.

Ukratko – 5.2 Porodica UML dijagrama

• UML 2 ima četrnaest vrsta dijagrama: strukturne (od čega je sistem) i dijagrame ponašanja (šta sistem radi).
• U knjizi crtamo pet: slučajeva korištenja, aktivnosti, klasa, sekvencijalni i stanja.
• Komponente i razmještaj zamjenjujemo jednostavnijim C4 modelom u poglavlju 9.

5.3 Čime se crta UML

UML dijagram se može nacrtati i olovkom na papiru, i to je često najbolji prvi korak: na tabli u sali za sastanke, dok se raspravlja. Za dijagram koji ostaje u dokumentaciji koristimo alate. Dijele se u dvije grupe:

U ovoj knjizi:

• Mermaid koristimo za dijagram klasa, sekvenci i stanja, jer ga GitHub i VS Code iscrtavaju direktno u Markdownu;
• PlantUML koristimo za dijagram slučajeva korištenja, jer Mermaid ne poznaje figurice aktera ni elipse slučajeva;
• draw.io koristimo kad treba slobodno crtati (BPMN iz poglavlja 4).

5.3 Čime se crta UML

PlantUML radi slično Mermaidu: napišete tekst između @startuml i @enduml, a alat nacrta sliku. Može se koristiti na stranici [plantuml.com](https://www.plantuml.com/plantuml) ili u VS Codeu, uz ekstenziju PlantUML.

Ukratko – 5.3 Čime se crta UML

• UML se crta olovkom, alatima „dijagram kao tekst” (Mermaid, PlantUML) ili alatima za crtanje mišem (draw.io, StarUML).
• Tekstualni dijagrami se čuvaju u Gitu i lako porede između verzija.
• U knjizi Mermaid crta klase, sekvence i stanja, PlantUML slučajeve korištenja, a draw.io slobodne crteže.

Provjeri se

1. Da li UML propisuje kojim redom se projektuje? Ne; UML je jezik, a ne metoda.
2. Koja je razlika između strukturnog dijagrama i dijagrama ponašanja? Strukturni pokazuje od čega se sistem sastoji, a dijagram ponašanja šta sistem radi i kako se mijenja.
3. Zašto dijagram slučajeva korištenja crtamo u PlantUML-u, a ne u Mermaidu? Mermaid ne poznaje figurice aktera ni elipse slučajeva korištenja.

Odgovori: tipka R ili klik na zamućeno polje.

5.4 Akteri

Akter je uloga koja koristi sistem ili s njim razgovara, a nije dio sistema. Crta se kao figurica (čiča-gliša) s imenom ispod. Tri stvari su važne:

1. Akter je uloga, a ne osoba. Ista osoba može biti dva aktera: vlasnik Picerije R-1 koji naveče naruči ćevape iz R-2 u tom trenutku je akter Kupac, a ne Restoran. I obrnuto: četiri različita dostavljača su jedan akter, Dostavljač.
2. Akter može biti i drugi sistem. Sistem plaćanja i Servis mapa nisu ljudi, ali razgovaraju sa DeliveryApp, pa su akteri. Često ih crtamo kao pravougaonik s oznakom «system» umjesto figurice.
3. Akteri su primarni ili sekundarni. Primarni akter pokreće slučaj korištenja jer želi nešto postići (kupac želi naručiti). Sekundarni akter pomaže sistemu da ispuni taj cilj (sistem plaćanja naplati, servis mapa izračuna udaljenost).

Akteri DeliveryApp:

5.4 Akteri

Slika iz života: akteri su kao uloge u pozorišnoj predstavi. Uloga „Hamlet” postoji u tekstu bez obzira ko je igra večeras; isti glumac može sutra igrati drugu ulogu.

Ukratko – 5.4 Akteri

• Akter je uloga koja koristi sistem ili s njim razgovara, a nije dio sistema.
• Ista osoba može imati više uloga, a više osoba može biti isti akter.
• Akter može biti i drugi sistem, npr. sistem plaćanja.
• Primarni akter pokreće slučaj jer želi cilj, a sekundarni pomaže sistemu da ga ispuni.

5.5 Slučajevi korištenja i granica sistema

Slučaj korištenja je cilj koji akter postiže uz pomoć sistema, i to cilj koji akteru ima smisla sam po sebi. Crta se kao elipsa s imenom u obliku glagol + imenica: „Naruči hranu”, „Prati narudžbu”, „Prihvati narudžbu”.

Dobar test je test kafe: da li bi akter, kad završi taj slučaj, mogao otići na kafu zadovoljan što je nešto postigao? „Naruči hranu” prolazi: kupac je naručio i čeka. „Unesi broj kuće” ne prolazi: niko ne otvara aplikaciju da bi unio broj kuće; to je samo korak unutar narudžbe.

Svi slučajevi korištenja crtaju se unutar granice sistema: pravougaonika s imenom sistema na vrhu. Akteri su uvijek izvan granice. Granica jasno kaže šta mi pravimo (unutra), a šta samo koristimo (vani): sistem plaćanja je vani, jer ga pravi druga firma.

Linija između aktera i slučaja zove se asocijacija i znači „ovaj akter učestvuje u ovom slučaju”.

Slučajevi korištenja DeliveryApp:

5.5 Slučajevi korištenja i granica sistema

5.5 Slučajevi korištenja i granica sistema

Ukratko – 5.5 Slučajevi korištenja i granica sistema

• Slučaj korištenja je cilj aktera, imenovan kao glagol i imenica („Naruči hranu”).
• Test kafe: akter nakon slučaja može otići zadovoljan što je nešto postigao.
• Slučajevi su unutar granice sistema, akteri izvan nje, a asocijacija ih povezuje.
• DeliveryApp ima osam glavnih slučajeva korištenja, UC-01 do UC-08.

5.6 Veze između slučajeva korištenja

Neki slučajevi korištenja dijele korake ili se ponekad proširuju. UML za to ima tri veze, crtane isprekidanom strelicom s oznakom:

«include» (uključuje) – dio koji se uvijek izvrši u sklopu drugog slučaja, a izdvojen je jer ga koristi više slučajeva. „Naruči hranu” uvijek uključuje „Izračunaj cijenu”; „Otkaži narudžbu” uvijek uključuje „Vrati novac”. Strelica ide od slučaja koji uključuje prema uključenom.

«extend» (proširuje) – dio koji se ponekad, pod nekim uslovom, doda drugom slučaju. „Primijeni kod popusta” proširuje „Naruči hranu”, ali samo ako kupac upiše kod. Strelica ide od proširenja prema osnovnom slučaju, a uz nju se može napisati uslov.

Generalizacija – akter ili slučaj koji je poseban oblik drugog, crta se punom linijom sa šupljim trouglom. Na primjer, akter Registrovani kupac je poseban oblik aktera Kupac: može sve što i kupac, plus da sačuva adresu.

Najlakše se pamti ovako: include = obavezno, extend = opcionalno. A smjer strelice prati riječ: „Naruči hranu uključuje Izračunaj cijenu” (strelica od narudžbe); „Primijeni kod proširuje Naruči hranu” (strelica od koda).

5.6 Veze između slučajeva korištenja

Česte greške na dijagramu

1. Funkcionalno razbijanje. Dijagram s pedeset elipsa („Unesi ime”, „Unesi ulicu”, „Unesi broj”) nije dijagram slučajeva korištenja, nego spisak koraka. Koraci idu u specifikaciju (5.7).
2. Dijagram kao tok. Strelice između slučajeva ne znače „poslije ovoga ide ono”. Redoslijed pokazuje dijagram aktivnosti, a ne dijagram slučajeva.
3. Previše «include» i «extend». Ako svaki slučaj ima pet veza, dijagram se ne može pročitati. Veze crtamo samo kad stvarno pomažu.
4. Sistem kao akter. DeliveryApp nije akter u svom dijagramu; on je granica.

Ukratko – 5.6 Veze između slučajeva korištenja

• «include» znači da se dio uvijek izvrši u sklopu drugog slučaja; strelica ide od slučaja prema uključenom dijelu.
• «extend» znači da se dio ponekad, pod uslovom, doda; strelica ide od proširenja prema osnovnom slučaju.
• Generalizacija pokazuje da je akter ili slučaj poseban oblik drugog.
• Česte greške su razbijanje na korake, crtanje redoslijeda, previše veza i sistem kao akter.

Provjeri se

1. Da li je dostavljač D-2 akter? Ne; akter je uloga Dostavljač, a D-2 je jedna osoba u toj ulozi.
2. Prolazi li „Unesi broj kuće” test kafe? Ne; to je samo korak unutar slučaja „Naruči hranu”.
3. Kojom vezom povezujemo „Primijeni kod popusta” s „Naruči hranu”? «extend», jer se kod primjenjuje samo kad ga kupac upiše.

Odgovori: tipka R ili klik na zamućeno polje.

5.7 Specifikacija slučaja korištenja

Elipsa na dijagramu kaže samo ime cilja. Šta se tačno dešava, opisuje specifikacija slučaja korištenja: kratak dokument po ustaljenom šablonu. Evo cijele specifikacije za najvažniji slučaj DeliveryApp.

UC-01 Naruči hranu

5.7 Specifikacija slučaja korištenja

5.7 Specifikacija slučaja korištenja

Glavni tok (uspješan put):

1. Kupac bira jela i količine; sistem pokazuje zbir artikala.
2. Kupac unosi ili bira adresu dostave.
3. Sistem traži udaljenost od servisa mapa.
4. Sistem provjerava PP-1 i PP-3 i računa dostavu po PP-2 i PP-4 (uključuje Izračunaj cijenu).
5. Sistem prikazuje pregled: artikli, dostava, ukupno.
6. Kupac potvrđuje i bira plaćanje karticom.
7. Sistem šalje iznos sistemu plaćanja; plaćanje je odobreno.
8. Sistem pravi narudžbu u stanju NOVA, prikazuje je restoranu i kupcu pokazuje broj narudžbe.

Alternativni tokovi (broj kaže iz kojeg koraka glavnog toka se odvaja):

5.7 Specifikacija slučaja korištenja

• 4a. Iznos manji od 5,00 €. Sistem prikaže „Najmanja narudžba je 5,00 €” i vraća kupca na korak 1.
• 4b. Adresa dalje od 10 km. Sistem prikaže „Ova adresa je izvan zone dostave (najviše 10 km)” i vraća kupca na korak 2.
• 5a. Kupac upiše kod popusta (proširenje Primijeni kod popusta). Ako je kod STUDENT10, sistem oduzme 10 % artikala, najviše 5,00 €, i ponovo prikaže pregled. Ako je kod nepoznat, prikaže „Kod nije važeći” i nastavlja bez popusta.
• 7a. Plaćanje odbijeno. Sistem prikaže „Plaćanje nije uspjelo” i nudi novi pokušaj; korpa ostaje sačuvana. Slučaj završava neuspjehom ako kupac odustane.
• 3a. Servis mapa ne odgovara 10 sekundi. Sistem prikaže „Ne možemo izračunati dostavu, pokušajte ponovo” i ne dozvoljava plaćanje.

Primijetite šta specifikacija ne sadrži: nema riječi o bazama, dugmadima ni bojama. Ona kaže šta akter i sistem razmjenjuju, ne kako to izgleda na ekranu. Ekrane crtamo u poglavlju 11.

Ukratko – 5.7 Specifikacija slučaja korištenja

• Specifikacija slučaja korištenja opisuje aktere, cilj, preduslove, okidač, postuslove i pravila.
• Glavni tok je uobičajen uspješan put, korak po korak.
• Alternativni tokovi su označeni brojem koraka iz kojeg se odvajaju (4a, 7a).
• Specifikacija ne opisuje izgled ekrana ni tehnologiju.

5.8 Scenariji i testovi

Scenarij je jedan konkretan put kroz slučaj korištenja, od okidača do kraja. Glavni tok je jedan scenarij; svaki alternativni tok daje još jedan. Za UC-01 to je bar šest scenarija:

5.8 Scenariji i testovi

Svaki scenarij je gotov test slučaj: zna se početno stanje, koraci i očekivani rezultat. Tester (predmet Testiranje softvera) ovu tabelu može direktno pretvoriti u testove. Ovo je i provjera specifikacije: ako za neki scenarij ne znamo očekivani kraj, specifikacija nije potpuna.

Ukratko – 5.8 Scenariji i testovi

• Scenarij je jedan konkretan put kroz slučaj korištenja.
• UC-01 ima bar šest scenarija: glavni tok i pet alternativnih.
• Svaki scenarij s brojevima je gotov test slučaj, a scenarij bez očekivanog kraja otkriva nepotpunu specifikaciju.

5.9 Dijagram aktivnosti

Dijagram aktivnosti je UML-ov dijagram toka. Pokazuje korake jednog posla, odluke i poslove koji teku istovremeno. Sličan je dijagramu toka i BPMN-u iz poglavlja 4, ali koristi UML oznake:

5.9 Dijagram aktivnosti

Kada BPMN, a kada dijagram aktivnosti? BPMN je jezik posla: razumiju ga vlasnici restorana i koristi se za cijeli proces organizacije. Dijagram aktivnosti je jezik softvera: koristi se za tok unutar jednog slučaja korištenja ili jedne funkcije. Za DeliveryApp smo BPMN-om nacrtali cijeli proces narudžbe (slika 4.4), a dijagramom aktivnosti crtamo samo UC-01 iz ugla sistema:

flowchart TD
    S(("●")) --> A["Kupac bira jela"]
    A --> B["Kupac unosi adresu"]
    B --> F1["račvanje"]
    F1 --> C["Traži udaljenost od servisa mapa"]
    F1 --> D["Provjeri kod popusta"]
    C --> J1["spajanje"]
    D --> J1
    J1 --> E{"Ispravna narudžba?"}
    E -- "[ne]" --> A
    E -- "[da]" --> G["Prikaži pregled"]
    G --> H["Naplati"]
    H --> I{"Plaćeno?"}
    I -- "[ne]" --> G
    I -- "[da]" --> K["Napravi narudžbu NOVA"]
    K --> Z(("◉"))

5.9 Dijagram aktivnosti

Udaljenost i kod popusta mogu se provjeravati istovremeno, jer jedno ne zavisi od drugog; zato ih crtamo između račvanja i spajanja. Mermaid nema posebnu oznaku za debelu crtu, pa su račvanje i spajanje ovdje nacrtani kao uski pravougaonici; u PlantUML-u (fork i end fork) i u draw.io crtaju se pravom crtom.

Ukratko – 5.9 Dijagram aktivnosti

• Dijagram aktivnosti je UML-ov dijagram toka s akcijama, odlukama, račvanjem i spajanjem.
• Uslovi na granama pišu se u uglastim zagradama, npr. [iznos < 5 €].
• BPMN se koristi za proces cijele organizacije, a dijagram aktivnosti za tok unutar jednog slučaja ili funkcije.
• Poslovi koji ne zavise jedan od drugog crtaju se između račvanja i spajanja.

Provjeri se

1. Šta je postuslov slučaja korištenja? Stanje sistema poslije slučaja, npr. narudžba je plaćena i u stanju NOVA.
2. Koliko scenarija ima UC-01 u ovoj knjizi? Šest: glavni tok i pet alternativnih.
3. Čemu služi račvanje u dijagramu aktivnosti? Pokreće više tokova koji se izvode istovremeno.

Odgovori: tipka R ili klik na zamućeno polje.

Praktična nastava – slučajevi korištenja DeliveryApp

Cilj je nacrtati dijagram slučajeva korištenja DeliveryApp, napisati dvije pune specifikacije i dijagram aktivnosti, i iz njih izvesti scenarije. Fajlovi idu u folder modeli/ repozitorija deliveryapp-projekat.

Korak 1 – PlantUML u VS Codeu

1. Instalirajte ekstenziju PlantUML (jebbs). Za lokalno iscrtavanje treba Java; ako je nema, u postavkama ekstenzije izaberite iscrtavanje preko servera (Render: PlantUMLServer) ili koristite stranicu [plantuml.com/plantuml](https://www.plantuml.com/plantuml).
2. Napravite fajl modeli/slucajevi.puml i upišite:

@startuml
left to right direction
actor Kupac
actor Restoran
actor Dostavljač
actor Administrator
actor "Sistem plaćanja" as SP <<system>>
actor "Servis mapa" as SM <<system>>

rectangle DeliveryApp {
  usecase "Naruči hranu" as UC01
  usecase "Izračunaj cijenu" as CIJ
  usecase "Primijeni kod popusta" as KOD
  usecase "Prati narudžbu" as UC03
  usecase "Otkaži narudžbu" as UC04
  usecase "Vrati novac" as VN
  usecase "Prihvati ili odbij narudžbu" as UC02
  usecase "Uredi jelovnik" as UC05
  usecase "Isporuči narudžbu" as UC06
  usecase "Dodaj restoran" as UC07
}

Kupac -- UC01
Kupac -- UC03
Kupac -- UC04
UC01 ..> CIJ : <<include>>
KOD ..> UC01 : <<extend>>
UC04 ..> VN : <<include>>
UC01 -- SP
VN -- SP
CIJ -- SM
Restoran -- UC02
Restoran -- UC05
Dostavljač -- UC06
Administrator -- UC07
@enduml

1. Pritisnite Alt+D za pregled. Uporedite sa slikom 5.2.
2. Dodajte UC-08 „Pregledaj mjesečni izvještaj” i aktera Registrovani kupac koji je generalizacija Kupca (Kupac <|-- "Registrovani kupac") s vlastitim slučajem „Sačuvaj adresu”.

Korak 2 – Specifikacija UC-01 i UC-02

1. U modeli/uc-01.md prepišite šablon iz 5.7 i popunite ga vlastitim riječima. Dodajte bar jedan alternativni tok koji nije u udžbeniku (npr. „restoran se zatvori dok kupac bira jela”).
2. U modeli/uc-02.md napišite specifikaciju „Prihvati ili odbij narudžbu” za aktera Restoran: preduslovi (narudžba u stanju NOVA), glavni tok (restoran prihvati, stanje PRIHVAĆENA, kupac obaviješten), alternativni tokovi (odbijanje s razlogom i povratom novca; nema odgovora 5 minuta).

Korak 3 – Dijagram aktivnosti

U modeli/uc-01.md, ispod specifikacije, nacrtajte dijagram aktivnosti iz 5.9 u Mermaidu. Zatim dodajte granu za alternativni tok 3a (servis mapa ne odgovara). Provjerite da svaki alternativni tok iz specifikacije postoji i na dijagramu.

Korak 4 – Scenariji

Napravite tabelu scenarija za UC-01 (najmanje šest redova) po uzoru na 5.8, s konkretnim brojevima iz DeliveryApp i očekivanim krajem. Za UC-02 napravite bar tri scenarija.

Korak 5 – Povezivanje s backlogom

Za svaki slučaj korištenja provjerite koje GitHub Issues (korisničke priče iz poglavlja 3) mu pripadaju. U opis svake priče dopišite oznaku slučaja (npr. „Pripada UC-01”). Priča koja ne pripada nijednom slučaju je znak da dijagramu nešto fali, ili da priča nije potrebna.

Korak 6 – AI kao pomoćnik (opcionalno)

Dajte AI asistentu specifikaciju UC-01 i zatražite: „Predloži alternativne tokove koje sam zaboravio.” Svaki prijedlog provjerite: da li je zaista moguć u DeliveryApp i da li se slaže s pravilima PP-1 do PP-6? Dodajte samo one koje biste i sami branili. Zatražite i PlantUML kod za UC-02 i provjerite da se iscrtava.

Rezultat koji se predaje: modeli/slucajevi.puml (i izvezena slika), modeli/uc-01.md sa specifikacijom, dijagramom aktivnosti i tabelom scenarija, te modeli/uc-02.md.

Vježba za studenta 1 – akteri.

Vježba za studenta 1 – akteri. – rješenje

Vježba za studenta 2 – test kafe.

Vježba za studenta 2 – test kafe. – rješenje

Vježba za studenta 3 – include ili extend.

Vježba za studenta 3 – include ili extend. – rješenje

Vježba za studenta 4 – alternativni tok.

Vježba za studenta 4 – alternativni tok. – rješenje

Vježba za studenta 5 – scenarij s brojevima.

Vježba za studenta 5 – scenarij s brojevima. – rješenje

Sažetak u pet rečenica

1. UML je objedinjeni jezik za modelovanje softvera, nastao spajanjem metoda Boocha, Rumbaugha i Jacobsona i usvojen u OMG-u 1997, a kaže kako se crta, ne kojim redom se projektuje.
2. UML 2 ima četrnaest dijagrama, strukturnih i dijagrama ponašanja, a u knjizi crtamo pet: slučajeva korištenja, aktivnosti, klasa, sekvencijalni i stanja.
3. Dijagram slučajeva korištenja prikazuje aktere (uloge, i ljude i sisteme) izvan granice sistema i njihove ciljeve kao elipse unutar nje, povezane asocijacijom, «include» (uvijek) i «extend» (pod uslovom).
4. Specifikacija slučaja korištenja opisuje preduslove, okidač, glavni i alternativne tokove i postuslove, a svaki put kroz nju je scenarij koji se pretvara u test.
5. Dijagram aktivnosti crta tok unutar jednog slučaja korištenja s odlukama, račvanjem i spajanjem, dok BPMN služi za proces cijele organizacije.

Pitanja za ponavljanje

1. Ko je smislio slučajeve korištenja i u kakvom poslu?
2. Šta je UML i ko ga održava? Zašto se kaže da je jezik, a ne metoda?
3. Koje su dvije grupe UML dijagrama? Navedite po dva primjera.
4. Koje alate za crtanje UML-a znate i po čemu se razlikuju?
5. Šta je akter? Zašto je akter uloga, a ne osoba?
6. Koja je razlika između primarnog i sekundarnog aktera? Dajte primjere iz DeliveryApp.
7. Šta je slučaj korištenja i šta je test kafe?
8. Čemu služi granica sistema?
9. Objasnite razliku između «include» i «extend» i smjer strelice kod svake.
10. Navedite četiri česte greške na dijagramu slučajeva korištenja.
11. Koja polja ima specifikacija slučaja korištenja?
12. Šta je scenarij i kakva je njegova veza s testiranjem?
13. Koji su elementi dijagrama aktivnosti?
14. Kada koristimo BPMN, a kada dijagram aktivnosti?