Poglavlje 9: Usluge i trendovi u razvoju softvera
Priča za početak. U petak, 21. oktobra 2016, korisnici na istočnoj obali Amerike, a zatim i drugdje, ujutro nisu mogli otvoriti Twitter, Netflix, Reddit, GitHub, Spotify ni desetine drugih servisa. Ti servisi su radili; nije radio Dyn, firma koja je za njih prevodila imena (npr. twitter.com) u brojčane adrese servera. Na Dyn je udarila poplava lažnih zahtjeva iz stotina hiljada uređaja istovremeno. Ti uređaji nisu bili računari, nego kućne kamere i snimači video nadzora povezani na internet. Zarazio ih je zlonamjerni program Mirai, koji je jednostavno isprobavao fabričke lozinke poput „admin” i „12345”, koje vlasnici nikad nisu promijenili. Kamera koja košta nekoliko desetina dolara, s lozinkom koju niko ne mijenja i softverom koji se nikad ne ažurira, postala je vojnik u napadu na pola interneta. Internet stvari je tog dana pokazao koliko je moćan, i koliko je opasan kad se softver za njega pravi bez inženjerskog pristupa.
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.
Literatura. Osnovna literatura predmeta:
- I. Sommerville: Software Engineering, 10th ed., Pearson, 2016 (poglavlja 15, 17, 18 i 21).
- R. S. Pressman, B. R. Maxim: Software Engineering: A Practitioner’s Approach, 9th ed., McGraw-Hill, 2019.
- P. Clements, L. Northrop: Software Product Lines, Addison-Wesley, 2001.
Riječi ovog poglavlja.
- 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.
- 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
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 9.1–9.4 SaaS, SOA, IoT, proizvodne linije | Grad kao zakupac; DeliveryApp Apoteka |
| Teorija 2 | 9.5–9.8 Aspekti, reaktivno, trendovi u DeliveryApp, kako pratiti trendove | Dekorator @mjeri; tok statusa narudžbe |
| Dopunska praksa | Dekorator za mjerenje i reaktivni tok | Dva mala programa, Python i C# |
Dio 1 – Usluge, stvari i porodice proizvoda
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:
| Model | Šta dobijate | Šta radite sami | Pizza |
|---|---|---|---|
| IaaS (infrastruktura kao usluga) | virtuelne mašine, mreža, diskovi | operativni sistem, baze, aplikacija | iznajmite kuhinju, sve ostalo vaše |
| PaaS (platforma kao usluga) | okruženje za pokretanje aplikacije, baza kao usluga | samo aplikacija i podaci | donesete samo sastojke za pizzu, peć je njihova |
| SaaS (softver kao usluga) | gotova aplikacija | samo je koristite | naručite gotovu pizzu |
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.
- 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:
- Ugovor prvo. Servis se opisuje prije implementacije (npr. OpenAPI opis REST servisa: adrese, parametri, JSON odgovori, kodovi grešaka).
- Labava povezanost. Pozivalac zna samo ugovor, ne i tehnologiju ni bazu servisa.
- Ponovna upotreba. Isti servis plaćanja koriste i DeliveryApp i druge firme.
- Pronalaženje i sastavljanje. Servisi se kombinuju u nove poslovne procese (narudžba = mape + plaćanje + SMS).
- Bez stanja kod sebe gdje god je moguće, da se servis lako skalira.
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.
Česta zabluda. „Poziv servisa je isto što i poziv funkcije.” Funkcija u istom programu odgovori za nanosekunde i (skoro) nikad ne „nestane”. Servis preko mreže može kasniti, vratiti grešku ili ne odgovoriti uopšte. Zato su vremensko ograničenje, ponovni pokušaj i prekidač kola iz poglavlja 6 obavezni uz svaki poziv servisa.
Ukratko.
- 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:
- Uređaj – senzor i mali računar (mjeri temperaturu, lokaciju, pokret).
- Mreža i prolaz (gateway) – prenosi podatke, često lakim protokolima kao što je MQTT, napravljenim za slabe veze i slabe uređaje.
- Oblak – prima, čuva i obrađuje podatke iz hiljada uređaja.
- Aplikacija – prikaz, upozorenja, odluke.
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.
- 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:
| Jezgro (zajedničko) | DeliveryApp Hrana | DeliveryApp Apoteka | |
|---|---|---|---|
| narudžbe, stanja | ✓ | ✓ | ✓ |
| dostava po tarifi grada | ✓ | ✓ | ✓ |
| plaćanje, obavještenja | ✓ | ✓ | ✓ |
| jelovnik, „Ponovi narudžbu” | ✓ | ||
| katalog lijekova, fotografija recepta | ✓ | ||
| provjera punoljetnosti | ✓ | ||
| najmanja narudžba 5,00 € | ✓ | (nema) |
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.
- 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.
- Kojem modelu usluge odgovara „naručite gotovu pizzu”? – SaaS.
- Kako je Mirai zarazio uređaje? – Isprobavao je fabričke lozinke koje vlasnici nisu promijenili.
- Šta je varijabilnost u proizvodnoj liniji? – Planirana mjesta na kojima se proizvodi iz porodice razlikuju.
Dio 2 – Novi načini programiranja
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):
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):
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.
Česta zabluda. „Aspekti su magija koja sve rješava.” Što je aspekt nevidljiviji, to je teže shvatiti šta se zaista dešava kad se funkcija pozove. Aspekti su dobri za tehničke brige (mjerenje, zapis, transakcije, prava), a loši za poslovna pravila: popust ili tarifa ne smiju se „sakriti” u aspekt.
Ukratko.
- 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):
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.
- 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
| Trend | Gdje u DeliveryApp 2.0 | Šta dobijamo | Šta plaćamo |
|---|---|---|---|
| SaaS, višezakupnička usluga | gradovi kao zakupci | jedna verzija, brz ulazak novog grada | izolacija podataka, odgovornost za rad 24 h |
| servisi | plaćanje, mape, SMS | ne pišemo ono što drugi rade bolje | zavisnost od tuđe dostupnosti; taktike otpornosti |
| IoT | termo-torba, lokacija dostavljača | topla hrana, praćenje uživo | uređaji na terenu, sigurnost, baterija |
| proizvodna linija | DeliveryApp Hrana i Apoteka | drugi proizvod iz istog jezgra | fleksibilnije, skuplje jezgro |
| AOP | mjerenje i zapis svih poziva | jedan kod za cijeli sistem | manje vidljivo ponašanje |
| reaktivno | praćenje uživo, statusi narudžbe | odziv bez stalnog pitanja | teže otklanjanje grešaka |
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.
- 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.
Pet pitanja koja tim DeliveryApp postavlja prije uvođenja nove tehnologije:
- Koji naš problem rješava? Ako ne možemo imenovati problem, ne treba nam.
- Šta ćemo platiti? Učenje, nove greške, zavisnost od dobavljača, licence.
- 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).
- Možemo li je probati malo i jeftino? Prototip, jedan modul, prekidač funkcije.
- Možemo li se vratiti? Ako ne uspije, koliko košta odustajanje?
Na času. Izaberite tehnologiju o kojoj se sada mnogo priča. Odgovorite na pet pitanja za DeliveryApp 2.0. Da li biste je uveli?
Ukratko.
- 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.
- Šta je presjecajuća briga? Navedite primjer. – Posao koji se tiče mnogih dijelova koda, npr. mjerenje vremena ili zapis u dnevnik.
- Kako se u Pythonu najčešće piše aspekt? – Kao dekorator, npr.
@mjeri.- Šta radi
filteru reaktivnom toku? – Propušta dalje samo događaje koji zadovoljavaju uslov.
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žbe
Vježba za studenta 1 – modeli usluge.
Za svaki slučaj recite da li je IaaS, PaaS ili SaaS: a) restoran koristi DeliveryApp preko tableta; b) tim DeliveryApp iznajmljuje virtuelnu mašinu i sam instalira Linux i bazu; c) tim pokreće kontejner aplikacije na usluzi koja sama skalira i ažurira operativni sistem; d) tim koristi bazu podataka kao uslugu, bez brige o serveru.
Rješenje. a) SaaS; b) IaaS; c) PaaS; d) PaaS (baza kao usluga).
Vježba za studenta 2 – IoT sigurnost.
Firma nudi DeliveryApp jeftine termo-torbe sa senzorom. Sve imaju lozinku „admin”, ažuriranje softvera nije moguće, a torba šalje podatke nešifrovano. Navedite tri problema i zahtjev za svaki.
Rješenje. (1) Ista fabrička lozinka: zahtjev – jedinstven ključ za svaku torbu, bez zajedničke lozinke. (2) Nema ažuriranja: zahtjev – sigurno ažuriranje na daljinu. (3) Nešifrovani podaci (lokacija je lični podatak): zahtjev – šifrovana veza (npr. TLS) prema oblaku DeliveryApp, i ništa drugo.
Vježba za studenta 3 – presjecajuće brige.
Koje od sljedećeg su presjecajuće brige pogodne za aspekt, a koje nisu: a) zapis svakog poziva API-ja; b) obračun popusta STUDENT10; c) provjera da je korisnik prijavljen; d) pravilo da se narudžba u pripremi ne može otkazati; e) mjerenje vremena svih upita u bazu?
Rješenje. Pogodne: a), c), e) – tehničke brige koje se tiču mnogih mjesta. Nisu: b) i d) – to su poslovna pravila i moraju biti vidljiva u domenu (poglavlja 3 i 4).
Vježba za studenta 4 – proizvodna linija.
Udruženje cvjećara želi „DeliveryApp Cvijeće”: dostava u određeni sat (npr. rođendan), poruka na kartici, nema najmanje narudžbe. Šta ide iz jezgra, a šta je varijanta?
Rješenje. Iz jezgra: narudžbe i stanja, dostava po tarifi grada, plaćanje, obavještenja, praćenje uživo. Varijanta: katalog cvijeća, izbor termina dostave, tekst kartice, pravilo bez najmanje narudžbe (podešavanje). Možda i novo stanje „ČEKA TERMIN”, što je promjena jezgra i treba je dobro razmotriti da ne pokvari druge proizvode.
Sažetak u pet rečenica
- 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.
- 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.
- 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.
- Softverska proizvodna linija pravi porodicu proizvoda iz zajedničkog jezgra s planiranom varijabilnošću, kao DeliveryApp Hrana i DeliveryApp Apoteka.
- 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.