Poglavlje 5: UML i slučajevi korištenja
Priča za početak. Krajem šezdesetih godina mladi švedski inženjer Ivar Jacobson počeo je raditi u firmi Ericsson, na softveru za telefonske centrale. To su bili ogromni sistemi: hiljade funkcija, stotine programera, a jedna greška mogla je ostaviti grad bez telefona. Jacobson je primijetio da se programeri i ljudi iz telekomunikacija teško razumiju. Jedni govore o modulima i signalima, drugi o tome šta pretplatnik hoće: „podići slušalicu i nazvati broj”, „preusmjeriti poziv”. Počeo je opisivati sistem upravo tim rečenicama, iz ugla onoga ko sistem koristi, i nazvao ih slučajevima korištenja (engleski use cases). Ideju je predstavio svijetu na konferenciji 1987. godine. Desetak godina kasnije, Jacobson i još dvojica autora svojih metoda za crtanje softvera, Grady Booch i James Rumbaugh (zvali su ih „tri amigosa”), spojili su svoje oznake u jedan jezik. Međunarodna organizacija OMG usvojila ga je 1997. godine pod imenom UML, objedinjeni jezik za modelovanje. Slučajevi korištenja ušli su u UML kao prvi dijagram koji se crta za novi sistem.
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.
Literatura. Osnovna literatura predmeta:
- B. Popović, K. Kuk: Informacioni sistemi, Kriminalističko-policijski univerzitet, Beograd, 2017.
- J. S. Valacich, J. F. George: Modern Systems Analysis and Design, 9th ed., Pearson, 2020.
- L. Jelenković: Sustavi za rad u stvarnom vremenu – skripta, FER, Zagreb, 2015.
- D. Milićev: Programiranje u realnom vremenu – skripta, Beograd, 2002.
- V. Kovačević, M. Popović: Sistemska programska podrška u realnom vremenu 1, FTN, Novi Sad, 2013.
Riječi ovog poglavlja.
- 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.
- «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.
- 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
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 5.1–5.3 UML, vrste dijagrama, alati | Porodica od 14 dijagrama |
| Teorija 2 | 5.4–5.6 Akteri, slučajevi, veze | Dijagram slučajeva korištenja DeliveryApp |
| Teorija 3 | 5.7–5.9 Specifikacija, scenariji, dijagram aktivnosti | UC-01 „Naruči hranu”: pet scenarija |
| Praksa 1–3 | PlantUML; specifikacija u Markdownu; aktivnosti u Mermaidu | UC-01 i UC-02 DeliveryApp |
Dio 1 – Šta je UML
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:
- 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).
- 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.
- 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.
Česta zabluda. „UML je zastario, danas se samo programira.” Tačno je da se danas rjeđe crtaju veliki UML modeli od stotinu stranica. Ali dijagrami slučajeva korištenja, klasa, sekvenci i stanja svakodnevno se crtaju na tablama, u dokumentaciji i u Markdownu (Mermaid ih podržava upravo zato što ih ljudi koriste). Jezik koji svi razumiju ne zastarijeva dok ga ljudi koriste da se razumiju.
Ukratko.
- 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:
| Dijagram | Grupa | Pitanje | Poglavlje |
|---|---|---|---|
| Slučajeva korištenja | ponašanje | Ko koristi sistem i za šta? | 5 |
| Aktivnosti | ponašanje | Kojim redom se rade koraci jednog posla? | 5 |
| Klasa | struktura | Koje stvari sistem poznaje i kako su povezane? | 6 |
| Sekvencijalni | ponašanje (interakcija) | Ko kome šalje koju poruku i kojim redom? | 7 |
| Stanja | ponašanje | Kroz koja stanja prolazi jedna stvar (narudžba)? | 7 |
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.
- 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:
| Vrsta alata | Primjeri | Prednosti | Mane |
|---|---|---|---|
| Dijagram kao tekst | Mermaid, PlantUML | tekst se čuva u Gitu, vidi se šta se promijenilo, brzo se ispravlja | raspored elemenata bira alat, ne vi |
| Crtanje mišem | draw.io, StarUML, Visual Paradigm, Enterprise Architect | potpuna kontrola izgleda; neki alati provjeravaju UML pravila | fajl je teže porediti između verzija |
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).
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 ili u VS Codeu, uz ekstenziju PlantUML.
Ukratko.
- 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.
- Da li UML propisuje kojim redom se projektuje? – Ne; UML je jezik, a ne metoda.
- 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.
- 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.
Dio 2 – Dijagram slučajeva korištenja
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:
- 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č.
- 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.
- 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:
| Akter | Primarni ili sekundarni | Cilj ili uloga |
|---|---|---|
| Kupac | primarni | naručiti i dobiti hranu |
| Restoran | primarni | primiti i pripremiti narudžbe; održavati jelovnik |
| Dostavljač | primarni | preuzeti i isporučiti narudžbu |
| Administrator | primarni | dodati restoran, riješiti žalbu |
| Sistem plaćanja | sekundarni | naplatiti karticom i vratiti novac |
| Servis mapa | sekundarni | izračunati udaljenost i put |
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.
- 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:
| Oznaka | Slučaj korištenja | Primarni akter | Sekundarni akteri |
|---|---|---|---|
| UC-01 | Naruči hranu | Kupac | Sistem plaćanja, Servis mapa |
| UC-02 | Prihvati ili odbij narudžbu | Restoran | – |
| UC-03 | Prati narudžbu | Kupac | – |
| UC-04 | Otkaži narudžbu | Kupac | Sistem plaćanja |
| UC-05 | Uredi jelovnik | Restoran | – |
| UC-06 | Isporuči narudžbu | Dostavljač | Servis mapa |
| UC-07 | Dodaj restoran | Administrator | – |
| UC-08 | Pregledaj mjesečni izvještaj | Restoran | – |
Na času. Prođe li test kafe slučaj „Prijavi se”? (Rasprava je česta. Kupac ne otvara aplikaciju da bi se prijavio, nego da bi naručio, pa mnogi timovi prijavu ne crtaju kao poseban slučaj, nego je zapišu kao preduslov ostalih slučajeva. Važno je da tim odluči jednom i drži se toga.)
Ukratko.
- 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).
Česte greške na dijagramu
- 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).
- Dijagram kao tok. Strelice između slučajeva ne znače „poslije ovoga ide ono”. Redoslijed pokazuje dijagram aktivnosti, a ne dijagram slučajeva.
- 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.
- Sistem kao akter. DeliveryApp nije akter u svom dijagramu; on je granica.
Ukratko.
- «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.
- Da li je dostavljač D-2 akter? – Ne; akter je uloga Dostavljač, a D-2 je jedna osoba u toj ulozi.
- Prolazi li „Unesi broj kuće” test kafe? – Ne; to je samo korak unutar slučaja „Naruči hranu”.
- Kojom vezom povezujemo „Primijeni kod popusta” s „Naruči hranu”? – «extend», jer se kod primjenjuje samo kad ga kupac upiše.
Dio 3 – Specifikacija i dijagram aktivnosti
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
| Polje | Sadržaj |
|---|---|
| Primarni akter | Kupac |
| Sekundarni akteri | Sistem plaćanja, Servis mapa |
| Cilj | Kupac naruči i plati hranu iz jednog restorana, uz tačnu cijenu dostave. |
| Preduslovi | Kupac je prijavljen; restoran je otvoren. |
| Okidač | Kupac otvori jelovnik restorana. |
| Postuslov (uspjeh) | Narudžba je plaćena i u stanju NOVA; restoran je vidi. |
| Postuslov (neuspjeh) | Nema naplate; korpa ostaje sačuvana. |
| Poslovna pravila | PP-1 do PP-5 |
Glavni tok (uspješan put):
- Kupac bira jela i količine; sistem pokazuje zbir artikala.
- Kupac unosi ili bira adresu dostave.
- Sistem traži udaljenost od servisa mapa.
- Sistem provjerava PP-1 i PP-3 i računa dostavu po PP-2 i PP-4 (uključuje Izračunaj cijenu).
- Sistem prikazuje pregled: artikli, dostava, ukupno.
- Kupac potvrđuje i bira plaćanje karticom.
- Sistem šalje iznos sistemu plaćanja; plaćanje je odobreno.
- 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):
- 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.
- 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:
| Scenarij | Put | Primjer s brojevima | Očekivani kraj |
|---|---|---|---|
| S1 | glavni tok | N-1001: 21,50 €, 4,2 km | plaćeno 24,50 €, stanje NOVA |
| S2 | 1–4, 4a | N-1003: 4,50 € | poruka o najmanjoj narudžbi |
| S3 | 1–4, 4b | N-1004: 13,50 €, 11 km | poruka „izvan zone” |
| S4 | glavni tok + 5a (važeći kod) | N-1001 sa STUDENT10 | plaćeno 22,35 € |
| S5 | glavni tok + 7a | N-1001, kartica odbijena | nema naplate, korpa sačuvana |
| S6 | 1–3, 3a | servis mapa ne odgovara | nema plaćanja, poruka o pokušaju |
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.
- 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:
| Element | Oznaka |
|---|---|
| početni čvor | pun crni krug |
| aktivnost (akcija) | zaobljen pravougaonik |
| odluka i spajanje | romb; uslovi u uglastim zagradama, npr. [iznos < 5 €] |
| račvanje i spajanje (fork, join) | debela crna crta: iz nje kreće ili u nju ulazi više paralelnih tokova |
| završni čvor | crni krug u bijelom krugu („volovsko oko”) |
| particije (staze) | pojasevi po učesnicima, kao staze u BPMN-u |
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(("◉"))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.
- 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.
- Šta je postuslov slučaja korištenja? – Stanje sistema poslije slučaja, npr. narudžba je plaćena i u stanju NOVA.
- Koliko scenarija ima UC-01 u ovoj knjizi? – Šest: glavni tok i pet alternativnih.
- Čemu služi račvanje u dijagramu aktivnosti? – Pokreće više tokova koji se izvode istovremeno.
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
- 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.
- Napravite fajl
modeli/slucajevi.pumli 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- Pritisnite Alt+D za pregled. Uporedite sa slikom 5.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
- U
modeli/uc-01.mdprepiš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”). - U
modeli/uc-02.mdnapiš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žbe
Vježba za studenta 1 – akteri.
Za sistem studentske službe (prijava ispita, upis ocjene, potvrda o studiranju) nabrojte aktere i za svakog recite je li primarni ili sekundarni.
Rješenje. Student (primarni: prijavljuje ispit, traži potvrdu); Nastavnik (primarni: upisuje ocjenu); Referent studentske službe (primarni: izdaje potvrdu, rješava zahtjeve); Bankarski sistem (sekundarni: potvrđuje uplatu za prijavu ispita); Sistem za e-poštu (sekundarni: šalje obavještenja). Prihvatljivi su i drugi tačni akteri.
Vježba za studenta 2 – test kafe.
Koji od ovih su dobri slučajevi korištenja za DeliveryApp, a koji su koraci? a) „Izaberi količinu”; b) „Ocijeni restoran”; c) „Pritisni dugme Plati”; d) „Isporuči narudžbu”; e) „Provjeri lozinku”.
Rješenje. Dobri slučajevi: b) i d), jer akter nakon njih postiže cilj. Koraci: a) i c) su koraci unutar „Naruči hranu”; e) je korak prijave (ili preduslov), a ne cilj kupca.
Vježba za studenta 3 – include ili extend.
Odredite vezu i smjer strelice: a) „Isporuči narudžbu” i „Potvrdi predaju kodom”, ako se kod traži pri svakoj predaji; b) „Prati narudžbu” i „Pozovi dostavljača”, ako kupac zove samo kad kasni; c) „Otkaži narudžbu” i „Vrati novac”.
Rješenje. a) «include», strelica od „Isporuči narudžbu” prema „Potvrdi predaju kodom”. b) «extend», strelica od „Pozovi dostavljača” prema „Prati narudžbu”. c) «include», strelica od „Otkaži narudžbu” prema „Vrati novac”.
Vježba za studenta 4 – alternativni tok.
Napišite alternativni tok za UC-01 kad kupac u koraku 1 izabere jela iz dva različita restorana (DeliveryApp dozvoljava samo jedan restoran po narudžbi). Iz kojeg koraka se odvaja i gdje se vraća?
Rješenje. 1a. Jela iz drugog restorana. Kad kupac doda jelo iz drugog restorana, sistem pita „U korpi su jela iz R-1. Želite li isprazniti korpu i naručiti iz R-2?”. Ako kupac potvrdi, korpa se isprazni i doda se novo jelo; ako odbije, novo jelo se ne dodaje. U oba slučaja tok se nastavlja na koraku 1.
Vježba za studenta 5 – scenarij s brojevima.
Napišite scenarij za UC-01 s narudžbom N-1002 (4 × Ćevapi, 2,5 km, bez koda). Kojim putem ide i koliki je očekivani iznos?
Rješenje. Glavni tok bez alternativa: artikli 4 × 8,00 = 32,00 €; PP-1 i PP-3 su ispunjeni; po PP-4 dostava je besplatna jer je iznos veći od 30,00 €; pregled pokazuje ukupno 32,00 €; plaćanje odobreno; narudžba u stanju NOVA.
Sažetak u pet rečenica
- 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.
- UML 2 ima četrnaest dijagrama, strukturnih i dijagrama ponašanja, a u knjizi crtamo pet: slučajeva korištenja, aktivnosti, klasa, sekvencijalni i stanja.
- 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).
- 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.
- Dijagram aktivnosti crta tok unutar jednog slučaja korištenja s odlukama, račvanjem i spajanjem, dok BPMN služi za proces cijele organizacije.