Usluge i trendovi u razvoju softvera

Šta učimo ovog semestra (1–5)

Deset predavanja: dva časa teorije i jedan čas dopunske prakse. Danas je poglavlje 9. Isti primjer kroz knjigu: DeliveryApp 2.0.

Šta učimo ovog semestra (6–10)

Deset predavanja: dva časa teorije i jedan čas dopunske prakse. Danas: poglavlje 9 (označeno). Isti primjer kroz knjigu: DeliveryApp 2.0.

Priča za početak

Priča za početak

Literatura

1. I. Sommerville: Software Engineering, 10th ed., Pearson, 2016 (poglavlja 15, 17, 18 i 21).
2. R. S. Pressman, B. R. Maxim: Software Engineering: A Practitioner's Approach, 9th ed., McGraw-Hill, 2019.
3. P. Clements, L. Northrop: Software Product Lines, Addison-Wesley, 2001.

Zašto ovo poglavlje

U poglavlju 8 složili smo DeliveryApp 2.0 od komponenata s ugovorima i verzijama. Ovo poglavlje gleda šire: kako se softver danas nudi i povezuje, i koje ideje oblikuju njegov razvoj. Prvi dio govori o softveru kao usluzi, servisno orijentiranom inženjerstvu, internetu stvari i softverskim proizvodnim linijama. Drugi dio govori o dva programska pristupa koja rješavaju probleme koje klasično programiranje rješava teško: aspektno orijentiranom i reaktivnom programiranju. Na kraju vidimo kako se sve to uklapa u DeliveryApp i kako pratiti trendove bez jurenja za modom.

Riječi ovog poglavlja (1/2)

• SaaS (software as a service) – softver kao usluga: korisnik ga koristi preko interneta i plaća pretplatu.
• Višezakupnička usluga (multi-tenant) – jedna instalacija služi mnogo korisnika-firmi (zakupaca), odvojenih podacima.
• Servis – samostalna jedinica funkcionalnosti dostupna preko mreže, s ugovorom.
• SOA (service-oriented architecture) – arhitektura u kojoj se sistem sklapa od servisa.
• IoT (Internet of Things) – internet stvari: uređaji sa senzorima koji šalju podatke preko mreže.
• IoE (Internet of Everything) – internet svega: povezani ljudi, procesi, podaci i stvari.

Riječi ovog poglavlja (2/2)

• Softverska proizvodna linija – porodica proizvoda s istim jezgrom i planiranim razlikama.
• Varijabilnost – mjesta na kojima se proizvodi iz linije razlikuju.
• Presjecajuća briga (cross-cutting concern) – posao koji se tiče mnogih dijelova koda (mjerenje, zapis, sigurnost).
• Aspekt – modul koji opisuje presjecajuću brigu na jednom mjestu.
• Reaktivno programiranje – programiranje s tokovima događaja na koje kod reaguje.
• Tok (stream) – niz događaja kroz vrijeme.

Ciljevi poglavlja

Nakon poglavlja možete:

objasniti SaaS, PaaS i IaaS i šta znači višezakupnička usluga; opisati servisno orijentirano inženjerstvo i razliku između SOA i mikroservisa; opisati arhitekturu IoT sistema i njegove sigurnosne rizike; objasniti softversku proizvodnu liniju, jezgro i varijabilnost; prepoznati presjecajuće brige i napisati jednostavan aspekt kao dekorator; objasniti reaktivno programiranje i napraviti tok s filterom; procijeniti novi trend pitanjima umjesto oduševljenjem.

Plan poglavlja – Predavanje 9: dva časa teorije i jedan čas dopunske prakse

9.1 Programski proizvod kao usluga

Nekad se softver kupovao kao knjiga: na disku, jednom, i instalirao na svoj računar. Danas ga uglavnom koristimo kao uslugu: e-pošta, kancelarijski paketi, video, računovodstvo. Plaćamo mjesečno, ne instaliramo ništa, i uvijek imamo najnoviju verziju. To je softver kao usluga (SaaS).

Američki institut NIST je 2011. opisao tri osnovna modela usluga u oblaku, koji se najlakše razumiju kroz pizzu:

9.1 Programski proizvod kao usluga

9.1 Programski proizvod kao usluga

DeliveryApp 2.0 je SaaS za gradove i restorane: udruženje ugostitelja nudi uslugu, restorani plaćaju mjesečnu pretplatu, a kupci je koriste besplatno. Iznutra, tim DeliveryApp koristi PaaS (aplikacija u kontejneru i baza kao usluga kod pružaoca oblaka), da ne bi održavao servere.

Višezakupnička usluga (multi-tenancy). DeliveryApp ne instalira posebnu kopiju za svaki grad, nego jedna instalacija služi sve gradove, a svaki grad je zakupac: ima svoje podatke, tarife i restorane, i nikad ne vidi tuđe (NZ-6 iz poglavlja 6). Analogija: zgrada sa stanovima. Isti krov, lift i instalacije za sve, ali svako ima svoj stan i svoj ključ.

Za proizvođača SaaS znači stalan prihod, jednu verziju za održavanje i brzu isporuku izmjena svima; ali i odgovornost da usluga radi 24 sata, da čuva podatke i da ne pukne kad dođe novi grad. Zato su NFR iz poglavlja 6 kod SaaS-a centralni, a ne sporedni.

Ukratko – 9.1 Programski proizvod kao usluga

• SaaS je softver koji se koristi preko interneta uz pretplatu; IaaS i PaaS su niži nivoi usluge u oblaku.
• DeliveryApp 2.0 je SaaS za gradove i restorane, a interno koristi PaaS.
• Višezakupnička usluga služi mnogo zakupaca iz jedne instalacije, s odvojenim podacima, kao zgrada sa stanovima.

9.2 Servisno orijentirano inženjerstvo

Servis je samostalan dio funkcionalnosti dostupan preko mreže, s jasnim ugovorom: šta prima, šta vraća, koliko brzo i koliko pouzdano. Komponenta iz poglavlja 8 se instalira u vaš program; servis se poziva, a radi negdje drugo, i održava ga neko drugi.

Servisno orijentirana arhitektura (SOA) sklapa sistem od servisa. DeliveryApp već koristi tri vanjska servisa: sistem plaćanja, servis mapa i SMS. Nijedan od njih tim nije napisao; poziva ih preko interneta, po ugovoru.

Principi servisno orijentiranog inženjerstva:

1. Ugovor prvo. Servis se opisuje prije implementacije (npr. OpenAPI opis REST servisa: adrese, parametri, JSON odgovori, kodovi grešaka).
2. Labava povezanost. Pozivalac zna samo ugovor, ne i tehnologiju ni bazu servisa.
3. Ponovna upotreba. Isti servis plaćanja koriste i DeliveryApp i druge firme.
4. Pronalaženje i sastavljanje. Servisi se kombinuju u nove poslovne procese (narudžba = mape + plaćanje + SMS).
5. Bez stanja kod sebe gdje god je moguće, da se servis lako skalira.

9.2 Servisno orijentirano inženjerstvo

SOA i mikroservisi. Ranija SOA (2000-ih) često je koristila teške standarde (SOAP, WSDL) i centralnu „sabirnicu” (enterprise service bus) kroz koju idu sve poruke. Mikroservisi (poglavlje 7) su kasnija, lakša verzija iste ideje: mali servisi, REST i JSON ili poruke, svaki servis svoja baza, bez centralne sabirnice. Danas se pod „servisom” najčešće misli na REST API s JSON-om.

Ukratko – 9.2 Servisno orijentirano inženjerstvo

• Servis je funkcionalnost dostupna preko mreže s ugovorom; SOA sklapa sistem od servisa.
• Principi: ugovor prvo, labava povezanost, ponovna upotreba, sastavljanje, bez stanja.
• Mikroservisi su lakša, kasnija verzija servisne ideje.
• Poziv servisa može otkazati, pa uvijek ide uz taktike otpornosti.

9.3 Internet stvari i internet svega

Internet stvari (IoT) su uređaji sa senzorima i mrežnom vezom: pametni satovi, termostati, brojila struje, senzori u fabrikama, kamere. Internet svega (IoE) je širi pojam koji je popularizovala firma Cisco: povezani nisu samo uređaji, nego i ljudi, procesi i podaci.

Arhitektura IoT sistema ima obično četiri nivoa:

1. Uređaj – senzor i mali računar (mjeri temperaturu, lokaciju, pokret).
2. Mreža i prolaz (gateway) – prenosi podatke, često lakim protokolima kao što je MQTT, napravljenim za slabe veze i slabe uređaje.
3. Oblak – prima, čuva i obrađuje podatke iz hiljada uređaja.
4. Aplikacija – prikaz, upozorenja, odluke.

9.3 Internet stvari i internet svega

IoT u DeliveryApp 2.0. Restorani u Gradu C traže da hrana stiže topla. Tim predlaže pametnu termo-torbu: senzor temperature u torbi dostavljača šalje temperaturu svake minute. Ako topla hrana padne ispod 60 °C, aplikacija upozori dostavljača i restoran. Iste poruke daju i lokaciju za „Praćenje dostavljača uživo”.

Šta je drugačije kod razvoja za IoT:

• uređaji imaju malo memorije i baterije, pa kod mora biti štedljiv;
• mreža je nepouzdana: uređaj mora pamtiti podatke dok veze nema i poslati ih kasnije;
• uređaji su hiljade, na terenu, pa se ažuriraju na daljinu (over-the-air), sigurno i postepeno (kanarinac iz poglavlja 5);
• sigurnost je teža i važnija: priča o Miraiju pokazuje šta se desi kad se to zanemari.

Lekcije iz Miraija za tim DeliveryApp: nijedan uređaj ne izlazi s fabričkom lozinkom (svaka torba ima jedinstven ključ); svaki uređaj se može ažurirati; uređaj govori samo s oblakom DeliveryApp, ne s cijelim internetom; podaci o lokaciji su lični podaci i štite se (NZ-5).

Ukratko – 9.3 Internet stvari i internet svega

• IoT su uređaji sa senzorima na mreži; IoE povezuje i ljude, procese i podatke.
• Nivoi IoT sistema: uređaj, mreža i prolaz, oblak, aplikacija.
• Razvoj za IoT traži štedljiv kod, rad bez veze, ažuriranje na daljinu i ozbiljnu sigurnost.
• Mirai je pokazao cijenu fabričkih lozinki i uređaja koji se ne ažuriraju.

9.4 Softverske proizvodne linije

Automobilska industrija ne pravi svaki model od nule. Ista platforma (šasija, motor, elektronika) koristi se za limuzinu, karavan i mali SUV; razlikuju se karoserija, oprema i motor. To je proizvodna linija.

Softverska proizvodna linija je porodica proizvoda koji dijele zajedničko jezgro i razlikuju se na planiranim mjestima (varijabilnost). Clements i Northrop su 2001. opisali tri aktivnosti: razvoj jezgra, razvoj proizvoda iz jezgra, i upravljanje cijelom linijom.

Uspjeh DeliveryApp zainteresovao je i udruženje apoteka. Umjesto novog proizvoda, nastaje proizvodna linija DeliveryApp:

9.4 Softverske proizvodne linije

9.4 Softverske proizvodne linije

Varijabilnost se ostvaruje na nekoliko načina: podešavanjem (tarife, pravila), prekidačima funkcija (poglavlje 5), dodacima (mikrokernel, poglavlje 7) ili zamjenom komponente. Opis varijanti može stajati u konfiguraciji (primjeri/proizvodna_linija.yaml):

jezgro: [narudzbe, dostava, placanje, obavjestenja]

varijante:
  deliveryapp-hrana:
    funkcije: [jelovnik, ponovi_narudzbu, pracenje_uzivo, napojnica]
    gradovi: [A, B, C]
  deliveryapp-apoteka:
    funkcije: [katalog_lijekova, recept_fotografija, pracenje_uzivo]
    gradovi: [A]
    pravila: {provjera_starosti: true, najmanja_narudzba_eur: 0}

Proizvodna linija se isplati tek kad ima više proizvoda: ulaganje u fleksibilno jezgro je veće nego u jedan proizvod, a vraća se sa drugim i trećim. Zato se pravi kad je porodica proizvoda izvjesna, a ne „za svaki slučaj” (YAGNI iz poglavlja 4).

Ukratko – 9.4 Softverske proizvodne linije

• Softverska proizvodna linija je porodica proizvoda sa zajedničkim jezgrom i planiranom varijabilnošću.
• DeliveryApp Hrana i DeliveryApp Apoteka dijele narudžbe, dostavu, plaćanje i obavještenja.
• Varijabilnost se ostvaruje podešavanjem, prekidačima funkcija, dodacima i zamjenom komponenti.
• Linija se isplati kad postoji više proizvoda.

Provjeri se

1. Kojem modelu usluge odgovara „naručite gotovu pizzu”? SaaS.
2. Kako je Mirai zarazio uređaje? Isprobavao je fabričke lozinke koje vlasnici nisu promijenili.
3. Šta je varijabilnost u proizvodnoj liniji? Planirana mjesta na kojima se proizvodi iz porodice razlikuju.

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

9.5 Aspektno orijentirano programiranje

Neki poslovi se ne mogu smjestiti u jednu klasu ili komponentu, jer se tiču svih: zapisivanje u dnevnik (log), mjerenje vremena, provjera prava pristupa, transakcije. Zovemo ih presjecajuće brige, jer presijecaju sve module, kao što struja i voda prolaze kroz sve sobe kuće.

Bez posebne tehnike, kod za mjerenje vremena se kopira u svaku funkciju: dvije linije na početku, dvije na kraju, u stotinu funkcija. To je dupliran kod (miris iz poglavlja 4), i poslovna logika se gubi među linijama koje s njom nemaju veze.

Aspektno orijentirano programiranje (AOP) opisuje presjecajuću brigu na jednom mjestu, kao aspekt, i kaže gdje se primjenjuje. Ideju su 1997. objavili Gregor Kiczales i saradnici, u Xerox PARC-u (istoj laboratoriji iz poglavlja 3), a najpoznatiji alat je AspectJ za Javu. Danas se ideja najčešće koristi kroz jednostavnije mehanizme: dekoratore u Pythonu, atribute i međusloj (middleware) u C# i ASP.NET Coreu, i presretače u okvirima.

Aspekt „mjeri i zapiši” u Pythonu (primjeri/python/aspekt.py):

9.5 Aspektno orijentirano programiranje

def mjeri(funkcija):
    """Presjecajuća briga: svaki poziv se mjeri i zapisuje u dnevnik."""

    @functools.wraps(funkcija)
    def omotac(*args, **kwargs):
        pocetak = time.perf_counter()
        try:
            return funkcija(*args, **kwargs)
        finally:
            ms = (time.perf_counter() - pocetak) * 1000
            DNEVNIK.append(f"{funkcija.__name__}{args} trajalo {ms:.3f} ms")

    return omotac


@mjeri
def dostava(grad, km, iznos):
    return TARIFE[grad].dostava(km, iznos)

Funkcija dostava ne zna da je mjerena; mjerenje je dodato jednom linijom, @mjeri. Poziv dostava("B", 4.2, 2150) vraća 380, a u dnevniku se pojavi zapis s trajanjem.

Isto u C#, kao funkcija koja omotava drugu funkciju (primjeri/csharp/Aspekt.cs):

9.5 Aspektno orijentirano programiranje

Func<T, R> Mjeri<T, R>(string ime, Func<T, R> funkcija) => ulaz =>
{
    var sat = Stopwatch.StartNew();
    try { return funkcija(ulaz); }
    finally { dnevnik.Add($"{ime}({ulaz}) trajalo {sat.Elapsed.TotalMilliseconds:F3} ms"); }
};

U pravoj ASP.NET Core aplikaciji isti posao radi međusloj kroz koji prolazi svaki HTTP zahtjev, ili gotova biblioteka za praćenje (npr. OpenTelemetry), koja mjeri sve pozive bez ijedne linije u poslovnom kodu.

Ukratko – 9.5 Aspektno orijentirano programiranje

• Presjecajuće brige (zapis, mjerenje, prava, transakcije) tiču se cijelog koda.
• AOP ih opisuje na jednom mjestu kao aspekte; ideja potiče iz Xerox PARC-a, 1997.
• U praksi: dekoratori u Pythonu, omotači, atributi i međusloj u C#.
• Aspekti su za tehničke brige, a ne za poslovna pravila.

9.6 Reaktivno programiranje

Kad pišemo klasičan program, mi pitamo: „koje je stanje narudžbe?” Ako želimo pratiti promjene, pitamo stalno, svake sekunde. To je kao da svakih pet minuta otvarate poštansko sanduče da vidite je li stiglo pismo.

Reaktivno programiranje okreće pristup: podaci su tok događaja kroz vrijeme, a kod se pretplati na tok i reaguje kad događaj stigne. Kao obavještenje na mobitelu: ne provjeravate, nego vas aplikacija obavijesti. Tok je kao pokretna traka u fabrici: događaji dolaze jedan za drugim, a na traci ih možemo filtrirati (propusti samo isporučene), pretvarati (od događaja napravi poruku) i spajati.

Ideja je bliska obrascu posmatrač (poglavlje 7). Popularizovale su je biblioteke ReactiveX (Rx; za .NET je Microsoft objavio Rx.NET, a postoje i RxJava, RxJS, RxPY), a Reaktivni manifest iz 2014. opisao je reaktivne sisteme kao sisteme koji su brzi u odzivu, otporni, elastični i vođeni porukama.

Tok događaja o narudžbi, napravljen bez biblioteke da se vidi kako radi (primjeri/python/reaktivno.py):

9.6 Reaktivno programiranje

stanja = Tok()

# Kupac vidi svaku promjenu svoje narudžbe
stanja.filter(lambda d: d["kupac"] == "K-01").map(
    lambda d: f"K-01: narudžba {d['broj']} je {d['stanje']}"
).pretplati(print)

# Statistika broji samo isporučene
isporuceno = []
stanja.filter(lambda d: d["stanje"] == "ISPORUČENA").pretplati(isporuceno.append)

Kad se u tok pošalju četiri promjene narudžbe N-1001 (PRIHVAĆENA, U_PRIPREMI, NA_PUTU, ISPORUČENA) i jedna isporuka narudžbe N-1002 drugog kupca, kupac K-01 dobija četiri poruke o svojoj narudžbi, a statistika broji dvije isporuke. Kod koji šalje događaje ne zna ko ih sluša; svaki pretplatnik sam bira šta ga zanima.

Gdje se koristi: sučelja (svaki klik i svaka promjena podatka su događaji; Angular koristi RxJS), praćenje uživo (lokacija dostavljača svakih nekoliko sekundi), IoT (temperatura iz torbe), finansije (cijene na berzi). Cijena: kod je teže pratiti u debageru, jer se tok izvršavanja ne vidi „od vrha do dna”, i greške u tokovima su manje očigledne.

Ukratko – 9.6 Reaktivno programiranje

• Reaktivno programiranje radi s tokovima događaja na koje se kod pretplati i reaguje.
• Tokovi se filtriraju, pretvaraju i spajaju, kao proizvodi na pokretnoj traci.
• Biblioteke ReactiveX (Rx.NET, RxJS, RxPY) i Reaktivni manifest iz 2014. proširili su ideju.
• Dobro je za sučelja, praćenje uživo i IoT; cijena je teže praćenje toka izvršavanja.

9.7 Kako se trendovi uklapaju u DeliveryApp

Primijetite kolonu „Šta plaćamo”. Svaki trend je kompromis, kao i svaka arhitekturalna odluka iz poglavlja 7, i za svaki se piše ADR.

Ukratko – 9.7 Kako se trendovi uklapaju u DeliveryApp

• Svaki trend u DeliveryApp ima konkretno mjesto, korist i cijenu.
• Trend se uvodi kao arhitekturalna odluka, sa zapisom razloga.

9.8 Kako pratiti trendove

Svake godine pojavljuje se nova tehnologija za koju se kaže da će „promijeniti sve”. Neke zaista promijene (oblak, mobilni uređaji, AI asistenti), a mnoge nestanu. Firma Gartner je 1995. predložila krivu hajpa (hype cycle): nova tehnologija prvo izazove pretjerana očekivanja, zatim slijedi razočarenje, a tek onda polako dolazi do stvarne, korisne upotrebe.

9.8 Kako pratiti trendove

Pet pitanja koja tim DeliveryApp postavlja prije uvođenja nove tehnologije:

1. Koji naš problem rješava? Ako ne možemo imenovati problem, ne treba nam.
2. Šta ćemo platiti? Učenje, nove greške, zavisnost od dobavljača, licence.
3. Ko je koristi u produkciji, na našoj veličini? Tehnologija iz velike firme ne odgovara nužno timu od šest ljudi (priča o Prime Videu).
4. Možemo li je probati malo i jeftino? Prototip, jedan modul, prekidač funkcije.
5. Možemo li se vratiti? Ako ne uspije, koliko košta odustajanje?

Ukratko – 9.8 Kako pratiti trendove

• Kriva hajpa: pretjerana očekivanja, razočarenje, pa stvarna upotreba.
• Novi trend se procjenjuje pitanjima: koji problem rješava, koliko košta, ko ga koristi, može li se probati, može li se vratiti.

Provjeri se

1. Šta je presjecajuća briga? Navedite primjer. Posao koji se tiče mnogih dijelova koda, npr. mjerenje vremena ili zapis u dnevnik.
2. Kako se u Pythonu najčešće piše aspekt? Kao dekorator, npr. @mjeri.
3. Šta radi filter u reaktivnom toku? Propušta dalje samo događaje koji zadovoljavaju uslov.

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

Dopunska praksa – dekorator i reaktivni tok

Cilj je napisati aspekt i reaktivni tok i vidjeti kako dodaju ponašanje bez mijenjanja poslovnog koda. Trajanje: jedan čas.

Korak 1 – Aspekt u Pythonu

Pokrenite primjeri/python/aspekt.py. Zatim dodajte drugi dekorator, @zapisi_greske, koji hvata ValueError, upisuje u dnevnik poruku greške i ponovo je baca. Primijenite oba dekoratora na dostava i pozovite je sa 8,1 km za Grad B. Šta piše u dnevniku?

Korak 2 – Aspekt u C#

Pokrenite dotnet run Aspekt.cs u folderu primjeri/csharp. Omotajte i drugu funkciju (npr. dostavu za Grad C) i provjerite da dnevnik ima dva zapisa.

Korak 3 – Reaktivni tok

Pokrenite primjeri/python/reaktivno.py. Dodajte pretplatnika za restoran R-1 koji dobija poruku samo kad je narudžba u stanju PRIHVAĆENA. Dodajte i pretplatnika koji broji koliko je narudžbi prošlo kroz stanje NA_PUTU.

Korak 4 – Termo-torba (opcionalno)

Napravite tok temperature u koji šaljete mjerenja {"narudzba": "N-1001", "c": 68}, pa 64, 61, 58. Napravite pretplatnika koji ispiše upozorenje kad temperatura padne ispod 60 °C, ali samo prvi put.

Rezultat: izmijenjeni fajlovi s novim dekoratorom i novim pretplatnicima i izlaz programa.

Vježba za studenta 1 – modeli usluge.

Vježba za studenta 1 – modeli usluge. – rješenje

Vježba za studenta 2 – IoT sigurnost.

Vježba za studenta 2 – IoT sigurnost. – rješenje

Vježba za studenta 3 – presjecajuće brige.

Vježba za studenta 3 – presjecajuće brige. – rješenje

Vježba za studenta 4 – proizvodna linija.

Vježba za studenta 4 – proizvodna linija. – rješenje

Sažetak u pet rečenica

1. Napad na Dyn 21. oktobra 2016. izveden je preko kućnih kamera i snimača zaraženih Miraijem preko fabričkih lozinki, i pokazao je koliko je internet stvari moćan i opasan bez inženjerskog pristupa.
2. Softver se danas nudi kao usluga (SaaS, PaaS, IaaS), a DeliveryApp 2.0 je višezakupnički SaaS u kojem je svaki grad zakupac s odvojenim podacima.
3. Servisno orijentirano inženjerstvo sklapa sisteme od servisa s ugovorima, a IoT dodaje uređaje sa senzorima, uz rad bez veze, ažuriranje na daljinu i strogu sigurnost.
4. Softverska proizvodna linija pravi porodicu proizvoda iz zajedničkog jezgra s planiranom varijabilnošću, kao DeliveryApp Hrana i DeliveryApp Apoteka.
5. Aspektno programiranje izdvaja presjecajuće brige (npr. dekorator @mjeri), reaktivno programiranje radi s tokovima događaja na koje kod reaguje, a svaki novi trend se procjenjuje pitanjima o problemu, cijeni i povratku, a ne oduševljenjem.

Pitanja za ponavljanje

1. Šta se desilo 21. oktobra 2016. i koje su pouke za razvoj IoT softvera?
2. Objasnite IaaS, PaaS i SaaS analogijom s pizzom.
3. Šta je višezakupnička usluga i kako je DeliveryApp 2.0 koristi?
4. Šta je servis i po čemu se razlikuje od komponente? Navedite principe servisno orijentiranog inženjerstva.
5. Koja je razlika između klasične SOA i mikroservisa? Zašto poziv servisa nije isto što i poziv funkcije?
6. Opišite četiri nivoa IoT sistema i primjer termo-torbe. Šta je posebno kod razvoja za IoT?
7. Šta je softverska proizvodna linija? Šta su jezgro i varijabilnost? Kako se varijabilnost ostvaruje?
8. Šta su presjecajuće brige i šta je aspekt? Ko je i kada objavio AOP?
9. Kako izgleda aspekt u Pythonu, a kako u C#? Za šta aspekti nisu pogodni?
10. Šta je reaktivno programiranje? Objasnite tok, pretplatu, filter i map.
11. Gdje se reaktivno programiranje koristi i koja mu je cijena?
12. Šta je kriva hajpa i koja pitanja postavljamo prije uvođenja novog trenda?