Appendix A — Dodaci
Dodaci su priručnik za brzo ponavljanje i za rad na projektu: rječnik pojmova, sve formule na jednom mjestu, podsjetnici za Mermaid, SQL i HTTP, šabloni dokumenata, ispitni zadaci s rješenjima i izvori istinitih priča iz knjige.
A. Rječnik
| Pojam | Značenje | Poglavlje |
|---|---|---|
| ACID | atomarnost, konzistentnost, izolacija i trajnost transakcije | 8 |
| ADR | kratak zapis jedne arhitektonske odluke: kontekst, odluka, posljedice | 9 |
| agilni razvoj | razvoj u kratkim iteracijama uz stalan razgovor s korisnikom | 2 |
| akter | uloga (čovjek ili sistem) koja koristi sistem ili s njim razgovara | 5 |
| API | dogovoren način na koji jedan program traži uslugu od drugog | 10 |
| arhitektura | važne odluke o dijelovima sistema koje se teško mijenjaju | 9 |
| asocijacija | veza između klasa čiji se objekti poznaju | 6 |
| autentifikacija / autorizacija | provjera ko je korisnik / šta smije | 12 |
| backlog | lista posla poredana po važnosti | 2 |
| balanser opterećenja | raspoređuje zahtjeve na više servera | 9 |
| BPMN | standard za crtanje poslovnih procesa | 4 |
| C4 model | četiri nivoa crteža arhitekture: kontekst, kontejneri, komponente, kod | 9 |
| CI / CD | automatsko testiranje / isporuka pri svakoj izmjeni | 2, 14 |
| CIA | povjerljivost, integritet, dostupnost | 12 |
| DFD | dijagram toka podataka | 4 |
| dijagram stanja | stanja jednog objekta i prelazi između njih | 7 |
| dostupnost | udio vremena u kojem sistem radi | 3, 9 |
| enkapsulacija | objekat skriva podatke i mijenja ih samo kroz svoje operacije | 6 |
| ER dijagram | crtež tabela (entiteta) i veza | 8 |
| evaluacija | mjerenje AI sistema na skupu pitanja s tačnim odgovorima | 15 |
| funkcionalni / nefunkcionalni zahtjev | šta sistem radi / kakav mora biti | 3 |
| GDPR | evropska uredba o zaštiti podataka o ličnosti | 12 |
| halucinacija | uvjerljiv, ali netačan odgovor jezičkog modela | 15 |
| heš | jednosmjerni otisak iz kojeg se lozinka ne može vratiti | 12 |
| histereza | dvije granice regulatora da se uređaj ne pali i gasi stalno | 13 |
| idempotentnost | ponovljen zahtjev ima isti efekat kao jedan | 10 |
| indeks | pomoćna struktura koja ubrzava pretragu, kao kazalo u knjizi | 8 |
| inkrement | komad sistema koji radi i dodaje se prethodnim | 2 |
| IoT | uređaji sa senzorima povezani preko interneta | 13 |
| JSON | tekstualni format podataka s objektima i nizovima | 10 |
| Kanban | tabla s kolonama i ograničenjem posla u toku | 2 |
| klasa / objekat | opis (kalup) / konkretna instanca (kolač) | 6 |
| kompozicija | dio ne postoji bez cjeline | 6 |
| kontejner (Docker) | program zapakovan sa svim što mu treba | 14 |
| korisnička priča | „Kao …, želim …, da bih …” | 3 |
| kriterij prihvatanja | provjerljiv uslov Dato–Kada–Tada | 3 |
| LLM | veliki jezički model | 15 |
| mikroservisi / monolit | mnogo malih samostalnih programa / jedan program | 9 |
| model | pojednostavljena slika sistema za jedno pitanje | 1 |
| MoSCoW | mora, trebalo bi, moglo bi, neće ovaj put | 3 |
| MQTT | protokol objavi–pretplati se za IoT | 13 |
| normalizacija | svaka činjenica na jednom mjestu (1NF, 2NF, 3NF) | 8 |
| OpenAPI | standard za opis API-ja kao ugovora | 10 |
| OWASP Top 10 | lista deset najčešćih rizika web aplikacija | 12 |
| persona | izmišljen, ali tipičan korisnik iz stvarnih intervjua | 11 |
| primarni / strani ključ | jedinstveni identitet reda / veza na red druge tabele | 8 |
| prototip | model ekrana koji se može isprobati | 11 |
| pull request | prijedlog izmjene uz pregled i automatske provjere | 14 |
| RAG | model odgovara na osnovu dohvaćenih dokumenata | 15 |
| realno vrijeme | rezultat je ispravan samo ako je tačan i na vrijeme | 13 |
| redundancija | dodatni primjerak koji preuzima posao | 9, 13 |
| REST | stil API-ja: resursi s adresama, radnje kao HTTP metode | 10 |
| revizijski trag | zapis ko je, kada i šta uradio | 12 |
| RTOS | operativni sistem za realno vrijeme | 13 |
| Scrum | agilni okvir: tri uloge, tri artefakta, pet događaja | 2 |
| sekvencijalni dijagram | poruke između učesnika kroz vrijeme | 7 |
| SLO | mjerljiv cilj nivoa usluge | 14 |
| slučaj korištenja | cilj koji akter postiže uz pomoć sistema | 5 |
| SQL injekcija | unos korisnika postane dio SQL naredbe | 12 |
| STRIDE | šest vrsta prijetnji | 12 |
| tehnički dug | brza prečica danas, kamata sutra | 14 |
| transakcija | izmjene koje se izvrše sve ili nijedna | 8 |
| UML | objedinjeni jezik za modelovanje softvera | 5 |
| V-model | svaka faza projektovanja ima svoj par provjere | 2 |
| verifikacija / validacija | pravimo li sistem ispravno / pravimo li pravi sistem | 14 |
| vodopad | faze jedna za drugom, bez vraćanja | 2 |
| WCAG | smjernice za pristupačnost weba | 11 |
| zainteresovana strana | svako koga se sistem tiče | 3 |
B. Formule
| Formula | Značenje | Primjer | Poglavlje |
|---|---|---|---|
| dostava = 200 + 50 · ⌈max(0, d − 3)⌉ centi | pravilo PP-2 (ispod 30,00 €, do 10 km) | d = 4,2 km → 300 centi = 3,00 € | 1 |
| v̄ = (v₁ + … + vₙ) / n | prosječna brzina tima | (18 + 22 + 20) / 3 = 20 bodova | 2 |
| W = L / λ | Littleov zakon: vrijeme u sistemu | 6 / 3 = 2 dana | 2 |
| t_zastoj = (1 − A) · 720 h | dozvoljeni zastoj u 30 dana | (1 − 0,995) · 720 = 3,6 h | 3, 14 |
| E = t_rad / t_ukupno · 100 % | efikasnost toka procesa | 27 / 50 = 54 %; 27 / 35 ≈ 77 % | 4 |
| A_niz = A₁ · A₂ | dostupnost dijelova u nizu | 0,995 · 0,995 ≈ 99,0 % | 9 |
| A_par = 1 − (1 − A)ⁿ | dostupnost paralelnih dijelova | 1 − 0,005² = 99,9975 % | 9 |
| λ = korisnici / vrijeme između zahtjeva | opterećenje servera | 200 / 5 s = 40 zahtjeva/s | 9 |
| K = (L₁ + 0,05) / (L₂ + 0,05) | omjer kontrasta (WCAG) | bijelo na #1F5FA8 ≈ 6,4 : 1 | 11 |
| P(n) = 1 − (1 − 0,31)ⁿ | dio problema koje otkrije n korisnika | P(5) ≈ 84 % | 11 |
| N = kᴸ | broj mogućih lozinki (k znakova, dužina L) | 26⁸ ≈ 2,09 · 10¹¹ | 12 |
| rizik = vjerovatnoća · uticaj | ocjena prijetnje (1–5 · 1–5) | 4 · 4 = 16 | 12 |
| ΔU = U_opseg / 2ⁿ | rezolucija A/D pretvarača | 3,3 V / 1024 ≈ 3,2 mV | 13 |
| U = Σ Cᵢ / Tᵢ ≤ n(2^{1/n} − 1) | test rasporedivosti zadataka | 0,25 ≤ 0,78 | 13 |
| R = 3r² − 2r³ | pouzdanost glasanja dva od tri | r = 0,99 → 0,9997 | 13 |
| greška = ε · f · t | nagomilana greška sata | 9,5 · 10⁻⁸ · 10 · 360 000 ≈ 0,34 s | 13 |
C. DeliveryApp na jednom mjestu
Pravila: PP-1 najmanja narudžba 5,00 €; PP-2 dostava 2,00 € do 3 km, plus 0,50 € za svaki započeti km preko 3 km; PP-3 najdalje 10 km; PP-4 od 30,00 € dostava besplatna; PP-5 STUDENT10 daje 10 % na artikle, najviše 5,00 €; PP-6 otkazivanje samo u stanju NOVA ili PRIHVAĆENA.
Nefunkcionalni zahtjevi: NZ-1 95 % odgovora ≤ 2 s pri 200 korisnika; NZ-2 dostupnost 99,5 % (≤ 3,6 h u 30 dana); NZ-3 lozinke kao heš, restoran dvofaktorski; NZ-4 prva narudžba ≤ 3 min, kontrast ≥ 4,5 : 1; NZ-5 adresa i telefon se brišu 12 mjeseci poslije posljednje narudžbe.
Narudžbe: N-1001 = 24,50 € (sa STUDENT10 22,35 €); N-1002 = 32,00 €; N-1003 odbijena (4,50 €); N-1004 odbijena (11 km); N-1005 = 25,60 €.
Stanja: NOVA, PRIHVAĆENA, ODBIJENA, U_PRIPREMI, NA_PUTU, ISPORUČENA, OTKAZANA; 7 dozvoljenih i 42 nedozvoljena prelaza.
Fajlovi u primjeri/deliveryapp/: deliveryapp.py (pravila i stanja), model.py (klase), schema.sql i podaci.sql (baza), baza.py, api.py i openapi.yaml (API), hladnjak.py (realno vrijeme), test_deliveryapp.py (testovi), Dockerfile i requirements.txt (kontejner); primjeri/ci/ci.yml (GitHub Actions); primjeri/mermaid/ (izvori dijagrama).
D. Podsjetnik: Mermaid
U vlastitom Markdown fajlu blok počinje sa ```mermaid. Natpise sa razmacima, zagradama, dvotačkom ili znakovima < i > stavite pod navodnike.
flowchart LR dijagram toka (LR lijevo-desno, TD odozgo)
A["Kupac"] -->|narudžba| B(("DeliveryApp"))
C{"Iznos ≥ 30 €?"} -- da --> D["0,00 €"]
classDiagram klase
class Narudzba { +broj: str -stanje: str +ukupno() int }
Kupac "1" --> "0..*" Narudzba : pravi
Narudzba "1" *-- "1..*" Stavka : sadrži
Korisnik <|-- Kupac
sequenceDiagram sekvence
actor K as Kupac
K->>S: zahtjev
S-->>K: odgovor
alt uslov
else drugi uslov
end
stateDiagram-v2 stanja
state "PRIHVAĆENA" as PRIHVACENA
[*] --> NOVA
NOVA --> PRIHVACENA: restoran prihvati
erDiagram baza
KUPAC ||--o{ NARUDZBA : pravi
C4Context arhitektura
Person(kupac, "Kupac", "opis")
System(z, "DeliveryApp", "opis")
Rel(kupac, z, "naručuje")E. Podsjetnik: SQL
CREATE TABLE stavka (
narudzba TEXT NOT NULL REFERENCES narudzba(broj) ON DELETE CASCADE,
jelo INTEGER NOT NULL REFERENCES jelo(id),
kolicina INTEGER NOT NULL CHECK (kolicina > 0),
PRIMARY KEY (narudzba, jelo)
);
INSERT INTO stavka VALUES ('N-1001', 1, 2);
SELECT n.broj, SUM(s.kolicina * s.cijena_u_trenutku) AS artikli
FROM narudzba n JOIN stavka s ON s.narudzba = n.broj
WHERE n.kupac = ? -- parametar, nikad zalijepljen tekst
GROUP BY n.broj ORDER BY n.broj;
UPDATE narudzba SET stanje = 'PRIHVAĆENA' WHERE broj = 'N-1001';
DELETE FROM adresa WHERE kupac IN (...);
BEGIN; ... COMMIT; -- ili ROLLBACK;
CREATE INDEX ix_narudzba_restoran ON narudzba(restoran);U SQLiteu: PRAGMA foreign_keys = ON; uključuje provjeru stranih ključeva. Prazna vrijednost se provjerava sa IS NULL.
F. Podsjetnik: HTTP
| Metoda | Namjena | Kod | Značenje | |
|---|---|---|---|---|
| GET | čitanje | 200 | uspjeh | |
| POST | pravljenje | 201 | napravljeno | |
| PATCH | izmjena dijela | 204 | uspjeh bez tijela | |
| PUT | zamjena | 400 | pokvaren zahtjev | |
| DELETE | brisanje | 401 / 403 | niste prijavljeni / nemate pravo | |
| 404 | ne postoji | |||
| 409 | sukob sa stanjem | |||
| 422 | podaci krše pravilo | |||
| 429 | previše zahtjeva | |||
| 500 / 503 | greška servera / privremeno nedostupan |
HTTPie: http GET :8000/v1/jela restoran==R-1 (parametar u adresi), http POST :8000/v1/cijena kupac=K-01 udaljenost_km:=4.2 (= tekst, := broj ili JSON), http PATCH … X-Kupac:K-01 (zaglavlje).
G. Šabloni dokumenata
Vizija
# Vizija – <sistem>
## Problem
## Za koga
## Rješenje u jednoj rečenici
Za … koji …, <sistem> je … koji … . Za razliku od …, … .
## Kako mjerimo uspjeh
## Pravila posla
## Šta nije u prvoj verzijiKorisnička priča (GitHub Issue)
Kao <uloga>, želim <nešto>, da bih <korist>.
Kriteriji prihvatanja
1. Dato … Kada … Tada …
2. Dato … Kada … Tada …
Prioritet: M / S / C / W · Veličina: … bodova · Pripada: UC-…Specifikacija slučaja korištenja
# UC-<broj> <Naziv>
| Polje | Sadržaj |
| --- | --- |
| Primarni akter | |
| Sekundarni akteri | |
| Cilj | |
| Preduslovi | |
| Okidač | |
| Postuslov (uspjeh) | |
| Postuslov (neuspjeh) | |
| Poslovna pravila | |
## Glavni tok
1. …
## Alternativni tokovi
- 3a. …ADR
# ADR-<broj>: <Odluka>
- Status: predloženo / prihvaćeno / zamijenjeno ADR-…
- Datum:
## Kontekst
## Odluka
## Posljedice
+ …
− …
## Razmotrene opcijeRed modela prijetnji
| Element | STRIDE | Prijetnja | V | U | Rizik | Odbrana |Dnevnik AI pomoći
| Datum | Alat | Zadatak | Šta je predloženo | Šta je prihvaćeno | Kako je provjereno |H. Ispitni zadaci s rješenjima
Zadaci su na proširenju DeliveryApp. Udruženje dodaje četvrti restoran, R-4 Pekara, s jelima: burek 3,50 €, jogurt 1,20 €, kroasan 2,00 €. Pekara radi od 6 do 14 h i nudi novo pravilo PP-7: narudžbe primljene prije 8 h imaju dostavu 1,00 € jeftiniju (ali ne ispod 0,00 €).
Zadatak 1 – zahtjevi. Napišite PP-7 kao korisničku priču i dva kriterija prihvatanja s brojevima. Postavite jedno pitanje koje otkriva nejasnoću pravila.
Rješenje. „Kao kupac koji naručuje doručak, želim jeftiniju dostavu prije 8 h, da bih platio manje.” Kriterij 1: Dato su 2 bureka i 1 jogurt (8,20 €), 4,2 km, narudžba u 7:30; Kada kupac otvori pregled; Tada vidi dostavu 3,00 − 1,00 = 2,00 € i ukupno 10,20 €. Kriterij 2: isto u 8:15 → dostava 3,00 €, ukupno 11,20 €. Pitanje: računa li se vrijeme narudžbe ili vrijeme plaćanja, i šta je s narudžbom u tačno 8:00? (Nejasnoća granice, kao „započeti kilometar” u PP-2.)
Zadatak 2 – proces i stanja. Pekara želi da kupac može naručiti uveče „za sutra u 7 h”. Koje novo stanje treba mašini stanja i koji prelazi? Da li se PP-6 mijenja?
Rješenje. Novo stanje ZAKAZANA: [*] → ZAKAZANA (plaćanje odobreno, termin u budućnosti); ZAKAZANA → NOVA (vremenski događaj: 30 min prije termina); ZAKAZANA → OTKAZANA (kupac otkaže / vrati novac). PP-6 treba proširiti: otkazivanje je dozvoljeno i u stanju ZAKAZANA. U tabeli prelaza sada je 8 stanja (64 para) i 9 dozvoljenih prelaza (sedam starih i dva nova; ulaz iz početnog čvora se ne broji kao par stanja).
Zadatak 3 – baza. Šta treba dodati u šemu iz poglavlja 8 za R-4 i PP-7? Napišite SQL za izmjenu.
Rješenje. Radno vrijeme restorana i vrijeme termina narudžbe: ALTER TABLE restoran ADD COLUMN otvara TEXT; ALTER TABLE restoran ADD COLUMN zatvara TEXT; ALTER TABLE narudzba ADD COLUMN termin TEXT; i u CHECK za stanje dodati ‘ZAKAZANA’. Popust iz PP-7 se ne čuva posebno, jer kolona dostava već pamti obračunati iznos u trenutku narudžbe. Jela R-4 su novi redovi u tabeli jelo.
Zadatak 4 – dostupnost. Pekara prima narudžbe od 6 h, kad je i redovno održavanje servera (30 minuta svake srijede od 6:00). Koliko to zastoja daje mjesečno (4 srijede) i kako se uklapa u NZ-2?
Rješenje. 4 × 30 min = 2 h mjesečno od 3,6 h budžeta; ostaje 1,6 h za sve ostale kvarove. Bolje je održavanje pomjeriti na noć (npr. 3:00), kad nema ni jednog otvorenog restorana, ili ga raditi bez zastoja (plavo–zelena isporuka, poglavlje 14).
Zadatak 5 – API. Koji statusni kod vraća POST /v1/narudzbe za narudžbu iz R-4 u 15:00? Napišite poruku za korisnika.
Rješenje. 422 (zahtjev je ispravan JSON, ali krši pravilo radnog vremena), ili 409 ako se zatvoren restoran shvata kao sukob sa stanjem; tim bira i zapisuje u OpenAPI. Poruka: „Pekara radi od 6 do 14 h. Možete zakazati narudžbu za sutra od 6 h.”
Zadatak 6 – sigurnost. Navedite dvije prijetnje STRIDE za novu funkciju zakazivanja i odbranu.
Rješenje. T: kupac promijeni vrijeme narudžbe u zahtjevu na 7:30 da dobije PP-7, iako naručuje u 9:00 → server popust računa po vremenu servera, ne po vremenu iz zahtjeva. D: napadač zakaže hiljade lažnih narudžbi za sutra → plaćanje unaprijed, ograničenje broja zakazanih narudžbi po kupcu i ograničenje broja zahtjeva.
Zadatak 7 – testovi. Napišite bar tri jedinična testa za PP-7 (opis ulaza i očekivanog izlaza).
Rješenje. (1) 8,20 €, 4,2 km, 7:30 → dostava 200 centi. (2) isto u 8:15 → 300 centi. (3) 8,20 €, 2 km, 7:00 → osnovna dostava 200 − 100 = 100 centi; (4) granica: 30,00 € u 7:00 → 0 centi (ne −100), jer PP-7 kaže „ne ispod 0,00 €”.
Zadatak 8 – realno vrijeme. Pekara ima peć s tri senzora temperature i glasanjem dva od tri. Senzori pokazuju 182 °C, 180 °C i 25 °C. Šta glasač vraća i šta sistem treba uraditi?
Rješenje. Dva senzora se slažu (oko 181 °C), pa glasač vraća njihov prosjek, 181 °C. Treći senzor (25 °C) je vjerovatno pokvaren: sistem nastavlja rad, ali pali upozorenje za održavanje, jer sada nema rezerve: ako otkaže još jedan, glasanje više nije moguće.
I. Izvori priča
Brojevi u pričama provjereni su u ovim izvorima (oktobar 2026). Gdje se izvori razilaze, u tekstu je napisana opreznija vrijednost („oko”, „više od”).
| Priča | Izvor |
|---|---|
| Denver, 1995 | Wikipedia: Denver International Airport; Associated Press, juni 2005 (United napušta automatski sistem prtljaga) |
| FBI Virtual Case File, 2005 | Computerworld, 2005: FBI scuttles $170M system for managing investigations |
| Healthcare.gov, 2013 | ABC News, 2013: Memo reveals only 6 people signed up for Obamacare on first day; PolitiFact, 2013 |
| Britanska pošta (Horizon) | Criminal Cases Review Commission: Post Office Horizon cases; Wikipedia: British Post Office scandal |
| Estonija, X-Road | e-estonia.com: X-Road |
| Agilni manifest, 2001 | agilemanifesto.org |
| W. Royce, 1970 | W. W. Royce: Managing the Development of Large Software Systems, Proceedings of IEEE WESCON, 1970 |
| Hitna pomoć London, 1992 | Report of the Inquiry into the London Ambulance Service, februar 1993 |
| Ford, 1913 | The Henry Ford: Ford Methods and the Ford Shops |
| I. Jacobson; UML | I. Jacobson, OOPSLA 1987; Object Management Group, UML 1.1 (1997) |
| Simula, Dahl i Nygaard | ACM A. M. Turing Award 2001 |
| A. Turing, 1936 | A. M. Turing: On Computable Numbers, with an Application to the Entscheidungsproblem, Proc. London Math. Society, 1936 |
| E. F. Codd, 1970 | E. F. Codd: A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, 1970 |
| Netflix, 2008–2016 | Netflix Technology Blog, 2016: Completing the Netflix Cloud Migration |
| Mars Climate Orbiter, 1999 | NASA: Mars Climate Orbiter Mishap Investigation Board Phase I Report, 1999 |
| Havaji, 2018 | Federal Communications Commission: izvještaji o lažnoj uzbuni od 13. 1. 2018 |
| Equifax, 2017 | CSO Online: Equifax data breach FAQ; saopštenja Equifaxa, 2017 |
| Apollo 11, 1969 | NASA: Apollo 11 Lunar Surface Journal (alarmi 1201 i 1202) |
| Patriot, 1991 | GAO/IMTEC-92-26: Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia, 1992 |
| Mars Pathfinder, 1997 | G. Reeves (JPL): What really happened on Mars?, 1997 |
| Knight Capital, 2012 | Knight Capital Group, Form 8-K (SEC), avgust 2012; SEC, 2013 |
| CrowdStrike, 2024 | Microsoft, 20. 7. 2024; CISA: Widespread IT Outage Due to CrowdStrike Update, 2024 |
| Air Canada, 2024 | Civil Resolution Tribunal (Britanska Kolumbija): Moffatt v. Air Canada, 14. 2. 2024 |
Za Netflixovu priču o 2008. i za podatke o Knight Capitalu (osam servera, ponovo upotrijebljena oznaka) korišteni su i izvještaji s kraja tih godina; ako se kasnije pojave precizniji podaci, okviri se usklađuju s njima.