ProGi Teorija PDF - Osnove Programskog Inženjerstva

PR GI UVOD U PROGRAMSKO INŽENJERSTVO oni se također mogu personalizirati i miješati jer nema jednog, najboljeg izbora. Iako i danas pazimo na veličinu, složenost i funkcionalnost našeg programskog kôda, razvoj...

PR GI UVOD U PROGRAMSKO INŽENJERSTVO oni se također mogu personalizirati i miješati jer nema jednog, najboljeg izbora. Iako i danas pazimo na veličinu, složenost i funkcionalnost našeg programskog kôda, razvoj Model je reprezentacija sustava (nešto apstraktno, programske potpore puno je više od programiranja. nešto što prikazuje sustav s naglaskom na nešto) na temelju koje se onda konkretan projekt „instancira“ – Programsko inženjerstvo bavi se razvojem programske proizvodi po nekoj proceduri. Ovo se u praksi zove potpore i svime što taj proces okružuje: specifikacija, model-driven development i povećava produktivnost. oblikovanje, implementacija, verifikacija, adaptacija… Svi inženjeri trebaju se ponašati profesionalno i Dakle, programski inženjer bavi se i programiranjem i etično, što kaže Codes of Ethics – djelujemo s javnim komunikacijom, modeliranjem, specificiranjem, interesom i interesom klijenta, ali smo neovisni i naš verifikacijom, oblikovanjem, analizom… proizvod mora zadovoljavati najviši standard. Moramo Programsko inženjerstvo je sistematično, organizirano biti kolegijalni, paziti na povjerljivost, razumjeti vlastite razvijanje programske potpore (i dokumentacije) uz kompetencije i granice, čuvati integritet struke i ne odgovarajuće alate, na umu imajući i resurse i rizike. činiti koristiti znanje s lošim namjerama. Osnovni izazovi programskog inženjerstva uključuju Iako ključnu ulogu u ovome mogu imati menadžeri i brze promjene u industriji, neopipljivost proizvoda, voditelji, svatko od nas mora sudjelovati u procesu i lako kopiranje, otežanu komunikaciju s timom i raditi na sebi. dionicima koji nas ne razumiju, mijenjanje zahtjeva, ŽIVOTNI CIKLUS PROGRAMSKE POTPORE I heterogenost (kompatibilnost) softvera, vrijeme INŽENJERSTVO ZAHTJEVA isporuke, povjerenje (uspostavljeno formalizmima). Posljedica – visok stupanj nesigurnosti. Životni ciklus (proces) razvoja programske potpore govori o fazama kroz koje nastaje (i nestaje) neka Izazovima ćemo doskočiti smanjenjem složenosti pa programska potpora – definiramo tko, što, kada i na inkrementalno poboljšavamo rad (kroz verzije), temelju toga razlikujemo glavne modele tih procesa. prakticiramo divide et impera, razlikujemo osnovne i dodatne funkcionalnosti, uvodimo modele i formalizme koji normiraju proces te dokumentiramo. Za razliku od programskog inženjerstva koje se bavi softverom i svime što ga okružuje, računarska znanost Generičke aktivnosti procesa (SOVE) su specifikacija, i inženjerstvo računalnih sustava šire su i „teorijske“ oblikovanje (i implementacija), validacija (i verifikacija) branše koje promatraju sustav – i softver i hardver. i evolucija (ažuriranja i razne promjene). Te ćemo faze prepoznati u svakom od modela. Postoje dva tipa složenosti: osnovna složenost urođena je problemu i ne može se ukloniti, a Upravljanje projektima svodi se na upravljanje nenamjerna (dodana) složenost uvodi se alatima, ljudima, procesima, alatima, resursima, rizicima. tehnikama i radom te se može ukloniti. Na projektu imamo dionike – ili sudjeluju ili projekt na Tradicionalno oblikovanje linearne je prirode (SOVE – njih utječe. Na primarne dionike utječemo izravno specifikacija, oblikovanje i implementacija, verifikacija (rukovoditelji, programeri, partneri), a na sekundarne i validacija, evolucija), ali nije realistično jer nema dionike neizravno (tržište, prodavači, konkurencija). dobre dokumentacije i nedovoljno je formalnosti. Ovo je bilo moguće prije, kada su projekti bili manji. Definiramo i ključne dionike (nije vezano s primarnom i sekundarnom podjelom) koji donose odluke. Moderno oblikovanje uvodi proces dokumentiranja, modeliranja (razlikovanje apstraktnog i konkretizacije), Dionici unutar tvrtke uključuju rukovoditelja, modularnost (ponovna iskoristivost), formalno poslovnog i/ili marketinškog stručnjaka, razvojni tim ispitivanje (validacija i verifikacija) te normiranost. (back-end, front-end, baza, podaci), UX/UI i Q&A. Ovako se već mogu oblikovati i veliki projekti. Idealna veličina tima na projektu dokazano je četiri do Moderno oblikovanje, ono što ćemo mi proučavati, sedam ljudi, a tim može biti ili samoorganiziran ili oslanja se na razne (u praksi ustaljene) modele, ali imati formalno definiranog rukovoditelja.  PR GI Posebnu pažnju dajemo T-članovima koji sva područja Inženjerstvo zahtjeva može se dodatno razraditi na tehnologije poznaju površno, ali su za neke stručnjaci. faze i promatrati kroz nekoliko vrsta modeliranja. Razvojni tim koristi programsku potporu da si olakša Modeliranju zahtjeva pristupamo klasično (linearno uz posao: sustav za komunikaciju (Slack, MS Teams i/ili male preinake) ili spiralno (iterativan proces u kojem Jira) i sustav za upravljanje verzijama programske se intenzitet aktivnosti povećava – tri polja uključuju potpore (Git, Subversion i/ili Mercurial). specifikaciju, validaciju i izlučivanje). Tuckmanov model razvoja tima razlikuje pet stupnjeva Generičke aktivnosti inženjerstva zahtjeva (SISVU) razvoja: forming (nalazimo se i upoznajemo), storming uključuju studiju izvedivosti (preventivno – isplati li se (zajednički rad i prvi konflikti u kojima je rukovoditelj ono što radimo, kako doprinosi i što je već na tržištu), ključan), norming (uloge su normirane i dogovorene), specifikaciju, validaciju i upravljanje zahtjevima. performing (rad) i adjourning (raspuštanje grupe). Izlučivanje zahtjeva mora raditi netko tko dobro Inženjerstvo zahtjeva posebna je grana programskog komunicira pa može kupcima približiti situaciju i inženjerstva u kojoj razmišljamo o tome što je od nas napraviti traženu listu zahtjeva. traženo – ovo je sam početak razvoja softvera. Razlikujemo nekoliko različitih pogleda, a najbolje ih je PODJELA PO RAZINI DETALJA (APSTRAKCIJI) razlikovati na temelju primjera niže. poslovni apstraktni, opisuju zašto je projekt zahtjevi logičan i profitabilan – business view apstraktni, opisuju što korisnik želi, korisnički rukovoditelj i klijent raspisuju prirodnim zahtjevi jezikom, tablicama i dijagramima zahtjevi specifični i detaljni, uključuju formalnu sustava notaciju – inženjeri i razvojni tim Zahtjevi sustava bitni su za daljnje oblikovanje pa se raspisuju formalno – matematičkom notacijom, UML dijagramima, nekad strukturiranim (pseudo)jezicima. Zahtjeve izlučujemo intervjuiranjem (otvoreno nema PODJELA PO SADRŽAJU (ŠTO ZAHTJEV GOVORI) predefinira pitanja, zatvoreno ima), obrascima funkcionalni sustav pruža X ili Y funkcionalnost uporabe (izrada, prezentiranje i komentiranje), zahtjevi korisniku – system should do scenarijima (prezentiramo igru uloga) i etnografski sustav ima neka ograničenja (često (people watching – ali specifičnu kategoriju ljudi). nefunkcionalni vremenska ili jezična ili u izradi) ili zahtjevi Razlikujemo zahtjeve visokog prioriteta (must have), pravila – system should be srednjeg prioriteta (optional, but nice) i niskog zahtjevi specifični za domenu (pravnu i/ili prioriteta (not needed, maybe in the future). domene administrativnu) u kojoj se razvija primjene program – system should respect U provjeri zahtjeva osvrćemo se i na validaciju (are we building the right product?) i na verifikaciju (are we Kakvi zahtjevi trebaju biti? Potrebni, provjerljivi, building the product right?) ručnom provjerom, ostvarivi, korektni (točni), jednoznačni, kompletni izradom prototipa i generiranjem ispitnih slučajeva. (uključuju sve potrebno), konzistentni (ne krše se s Zahtjevi se mijenjaju na temelju okoline, ponekad drugim zahtjevima), promjenjivi, sljedivi (znamo im nastavu novi ili posljedični (nakon uvođenja sustava) razlog i izvor), adaptabilni (kroz vrijeme). ili zahtjevi kompatibilnosti (s drugim procesima). Nefunkcionalni zahtjevi obavezno moraju biti mjerljivi Rad sa zahtjevima mora biti iterativne prirode. (obično vremenski ili binarno kažemo – da ili ne). UML U INŽENJERSTVU ZAHTJEVA Zahtjevi domene primjene mogu biti problematični jer nisu razumljivi ljudima van te domene, a i ljudi koji se Pogledati povezanu (rozu) UML skriptu koja kombinira dugo bave nečime često mnogo toga smatraju gradivo međuispita i završnog ispita. podrazumijevanim, odnosno implicitnim.  PR GI MODELI PROCESA PROGRAMSKOG INŽENJERSTVA U svakoj iteraciji nastaje prototip (radni model). Razlikujemo throw-away prototyping (svaki novi U nastavku detaljnije raspravljamo o generičkim prototip služi za razvoj i odbacuje se kad nas nešto aktivnostima razvoja programske podrške (SOVE). nauči) i exploratory prototyping (konstantno GENERIČKE AKTIVNOSTI istražujemo zahtjeve s kupcem i početni se prototip pomoću aktivnosti inženjerstva razvija s namjerom da bude krajnji proizvod). specifikacija nastaje dokument zahtjeva, Evolucijski model primjenjiv je za male i srednje opis traženog proizvoda sustave, ali ne i za velike. Klijenti često ne razumiju prvo oblikujemo arhitekturu, a razliku između gotovog proizvoda i prototipa pa za oblikovanje i onda implementiramo – biramo implementacija tehnologije, programiramo, velike projekte zbog njih često moramo rapidno otklanjamo greške prototipizirati i time riskirati kvalitetu proizvoda. validacija (radimo li uopće ono validacija i što trebamo) i verifikacija verifikacija (radimo li to ispravno) Inkrementalni pristup generalni je naziv za modele Lehmanovi zakoni evolucije kažu da se programska potpora koji prakticiraju isporuku proizvoda u inkrementima ili mijenja ili propada te da (verzijama). Prvo se bavimo prioritetnim zahtjevima, a evolucija u kasnijim inkrementima manje bitnim. Početkom povećanje složenosti mora uzrokovati i preoblikovanje kako izrade nekog inkrementa fiksiraju se zahtjevi kako bi bi stalni rast bio moguć rad bio kontinuiran i kohezivan. Kupac je zadovoljan jer stalno dobiva sve bolji proizvod, a rizik je smanjen. Postoje razni modeli koje danas tvrtke i timovi koriste u procesu razvoja programske podrške – krenimo. Spiralni razvoj također je generalni izraz za modele koji iterativno razvijaju programsku potporu, ali s Oportunistički model (ad-hoc) sugerira da treba uočiti manje eksplicitnim početkom i krajem faza. priliku i odraditi posao. Sve se odvija bez pripreme i zahtjeva – samo se programira i popravlja. Ovo je moguće za male projekte (tako radimo labose), ali je rizik visok te je teško napredovati bez krupne slike. Vodopadni model pretežito je linearan (voda se ne vraća jednom kad padne) što se tiče faza. Svaka se mora potpuno dovršiti prije pokretanja nove. S obzirom na to da nema vraćanja, ovaj je model Aktivnosti se nadovezuju jedna na drugu i imaju sve dobar samo za projekte na kojima nema puno veću kompleksnost. Svaki krug spirale generira jedan promjena, zahtjevi su u početku odlično i jasno prototip. Iako je ovaj model vrlo pregledan i smanjuje definirani i korisnik je siguran da se neće predomišljati. rizik, on je veliko administrativno opterećenje. Model danas nije popularan jer malo projekata odmah Bitno je napomenuti da su inkrementalni i spiralni ima jako dobro definirane zahtjeve i zapravo je teško modeli zapravo dvije podvrste iterativnog pristupa. promjene svesti na minimum. Model nije fleksibilan. Unificirani proces (unificirani jer spojio bitne prakse) Evolucijski model (ideja evolucije – konstantno model je koji razvija iterativno, oblikuje na temelju poboljšanje vrsta) uključuje iterativni (ponavljajući modela i u svakoj od faza intezivno koristi obrasce ciklusi razvoja) i inkrementalni (nove verzije programa uporabe koji povezuju priču. Zapamtimo to po prva tri sve su bolje) pristup razvoju. slova modela (use-case, na temelju modela, iterative).  PR GI Unificirani proces koristi UML (isto unified) za opis SCRUM KONCEPTI modela, a njegova je najpoznatija implementacija RUP vlasnik proizvoda odgovoran za zadatke i (racionalni unificirani proces) nastao u IBM-u. prioritete kroz product backlog, razvojni tim samoorganiziranih profesionalaca Opisuje se dinamički (slijed faza), statički (prikaz tim koji se mogu mijenjati između sprintova i aktivnosti) i praktično (vodimo se dobrom praksom). SCRUM vođa kao medijator između tima i vlasnika (ugodna radna okolina) Tijekom sve četiri faze procesa komuniciramo s sprint je ciklus od par tjedana posla korisnicima (feedback i obrasci uporabe) te na kraju nakon kojeg imamo gotov inkrement svake faze imamo milestones koje očekujemo. događaji (verziju proizvoda), a dodatno imamo sastanak planiranja sprinta, daily ČETIRI FAZE UNIFICIRANOG PROCESA SCRUM, reviziju te retrospektivu sprinta inception definiram projekt i zahtjeve product backlog je sortirana lista elaboration specificiram značajke i arhitekturu zahtjeva koju prati vlasnik, dok je sprint construction oblikujem, implementiram i ispitujem artefakti backlog dnevnik jednog sprinta u kojem transition isporuka u radnu okolinu su neki zahtjevi odabran i raspisani te nastaje inkrement (verzija proizvoda). Ovaj je proces danas koristan i cijenjen jer spaja dobre prakse – iterativan je, koristi UML, stalno ispitujemo, koristi se komponentno zasnovana arhitektura (komponente se povezuju sučeljima). Disciplinirana agilna isporuka (DAD) ljude stavlja na prvo mjesto – članove tima, njihove uloge i prava. Oni razvijaju programsku potporu nekim hibridnim modelom i samostalno se organiziraju. Agilni razvoj ispravak je na krute tradicionalne postupke s puno administrativnog tereta. Cilj je agilnost (brzina) kroz iterativni razvoj, ali manje inkremente koji brzo reagiraju na zahtjeve. Danas KANBAN je prethodno spomenuti agilni model, popularne vrste – SCRUM, SCRUMBAN i KANBAN. temelji se na struktura podataka koja izgleda kao velika, dinamična ploča koja se kreće udesno. Inačice se isporučuju često pa je kupac zadovoljan neprekidnom isporukom. Međutim, kako bi ta neprekidna isporuka bila moguća, treba nam tim sa što manje administracije (samoorganiziran) koji je motiviran i svi su spremni raditi zajedno. Vizualiziramo rad, protočnost kroz određene faze, ali i Ekstremno programiranje posebna je podvrsta agilnog količinu rada, obveze i jasna pravila koja pomažu da razvoja u kojoj se programira u paru (skupi i sposobni bolje upravljamo procesom. programeri). Inkrementi su još manji, a administracija zanemariva. Samo jednostavniji projekti. OBLIKOVANJE I VREDNOVANJE ARHITEKTURE Ovaj model praktičan je kada je kupac dio tima jer je Arhitektura programske potpore prikazuje strukturu komunikacija bez greške. Programeri automatiziraju sustava, njegovih elemenata, vanjskih obilježja (API) testiranje, dogovaraju konvencije – insider job. tih elemenata i odnosa između njih – ne idemo u detalje elemenata, već promatramo „tlocrt“. Oblikovanje arhitekture programske potpore proces SCRUM je jedan od najpoznatijih agilnih pristupa, a je identificiranja i strukturiranja dijelova sustava, utemeljen je na empirizmu (iskustvo u industriji). komunikacije između dijelova i okoline samog sustava. Ključni koncepti uključuju tim, događaje i artefakte. Cilj je stvoriti dokumentaciju koja omogućava Ideja su ponavljajući sprintovi u kojima sudjeluje cijeli implementaciju. Arhitektura se dokumentira kroz tim te vode zajedno potrebnu dokumentaciju. različite i brojne poglede (za nas, UML dijagrame).  PR GI Prednosti definiranja arhitekture uključuju manju Tijekom tih odluka važemo razne resurse (sigurnost, šansu za ispravljanjem (ispravak je trošak), bolju performanse, mrežno opterećenje, prenosivost i kvalitetu proizvoda i ponovnu uporabu. memorijske resurse) te razlikujemo tehnički i ekonomski vrednovane odluke. Ne postoji idealno Arhitekt sustava razumije poslovni model, tehničke rješenje i na kraju je sve cost-value kompromis. detalje, vrednuje prednosti i mane različitih pristupa i tehnologija, a kasnije vodi i razvojni tim. Bitno je da uz Inženjerima su često najkompliciranije izvršne arhitekturu on priloži i vlastite odluke. (poslovne) odluke koje dajemo menadžerima. Stil arhitekture programske potpore je familija slično U odlučivanju razlikujemo tanke klijente (aplikacija na definiranih sustava – najviša razina apstrakcije. strani klijenta ne obavlja zahtjevne proračune – preglednik) i debele klijente (gdje se većina proračuna Pogleda na arhitekturu programske potpore u jednom obavlja na klijentskoj strani – računalne igrice). projektu ima mnogo – ne možemo sve obuhvatiti odjednom, već gledamo iz različitih perspektiva. Mi ćemo pretežito koristiti UML kao jezik koji može modelirati određene strukturne i ponašajne dijagrame Jedan tradicionalni pogled bavi se komponentama koji prikazuju određene poglede na arhitekturu. (jedinicama) i konektorima (interakcije, socket) koji pokazuju ponašanje sustava tijekom izvođenja. EA (enterprise architecture) su arhitekture za velike organizacije i one proširuju UML koncepte. Pogledi se dijele na statične (pregled), dinamičke (u izvođenju, ponašajne) i alocirane (odnos softvera s Arhitektura se može oblikovati top-down (prvo izvršnom ili razvojnom okolinom). oblikujemo najvišu razinu i postepeno razrađujemo detalje pa na kraju tok podataka, sučelja i slično) i Prema dosegu se dijele na koncepcijske (apstraktnije, bottom-up (krećemo s najnižim razinama, često za netehničko osoblje), logičke (detaljne, za tehničko gotovim komponentama, fokus na efikasnost i osoblje) i izvršne (iz perspektive procesa) poglede. reusability). Hibridni pristup kombinira dva navedena. Definiramo i posebne arhitektonske poglede koji Stabilna arhitektura ona je kojoj dodavanje novih zapravo prikazuju sustav iz perspektive nekih karakteristika nikako ili minimalno mijenja postojeće. povezanih problema – u svrhu diskusije i dosljednosti. 12 PRINCIPA ZA VREDNOVANJE ARHITEKTURE Arhitektura zasnovana na događajima sadrži arhitekturu moram biti u stanju komponente koje se međusobno ne pozivaju podijeli pa razdvojiti na dijelove (pakete, eksplicitno, već se generiraju određeni signali vladaj sustave, uloge) kako bi se odvojeno (događaji) koje određene strukture „slušaju“. razrađivale i proslijedile timovima Poznata varijacija je MVC (model-view-controller) arhitektura mora paziti da promjene na jednom mjestu ne pristup u kojem model oblikuje podatke kojima se puni uzrokuju promjene na drugom view, a svime (logikom) upravlja controller. (međuovisnost sadržaja govori Jedan od tipičnih pogleda je 4 + 1 pogled koji uključuje mijenjanju povezanih podataka, logički, procesni, fizički, razvojni i scenarije (obrasce na opća međuovisnost o globalnim temelju kojih je izgrađen taj dio arhitekture). varijablama, upravljačka međuovisnost o zastavicama, međuovisnost u objektnom smanji oblikovanju zabranjuje razred kao međuovisnost argument, podatkovna međuovisnost govori o što manjem broju argumenata, međuovisnost tipova o logičnoj implementaciji hijerarhije, međuovisnost Biranje arhitekture zapravo je boravak u prostoru uključivanjem o smanjenju uvoza oblikovanja (design space), a isti se smanjuje kada raznih knjižnica i modula, a vanjska probleme (design issues) svedemo na opcije (design međuovisnost o što manje options) i neku izaberemo (design decisions). povezanosti sa OS-om i hardverom)  PR GI arhitektura mora omogućivati Postoje i tri vrste dokumentacije – referentna grupiranje međusobno povezanih, specifikacija, pregled za upravu i dokumentacija a izoliranih elemenata (funkcijski komponenti. na temelju povezanih operacija, razinski na temelju slojeva, UML DIJAGRAMI RAZREDA komunikacijski na temelju pristupa povećaj Pogledati povezanu (rozu) UML skriptu koja kombinira istim podacima, sekvencijski na koheziju gradivo međuispita i završnog ispita. Dodatno ćemo temelju međusobnih poziva, proceduralno na temelju toga što razmotriti objektno usmjereno oblikovanje. ide nešto jedno za drugim, Objektno usmjereno oblikovanje je iterativno i vremenski na temelju inkrementalno oblikovanje u kojem su centralni istovremenog izvođenja i korisnički pojmovi razredi, sučelja, operacije, apstrakcija i slično. ako nikako drukčije) zadrži (višu) arhitektura igra defenzivno u smislu U procesu oblikovanja razreda razlikujemo istraživački razinu da se sakrije nepotrebni detalj i da model (konceptualni), model domene sustava apstrakcije privatiziramo što je moguće (specifičniji na temelju domene u kojoj se pojavljuju) i povećaj arhitektura treba ponuditi u onda model sustava (implementacijski model). ponovnu budućnosti nekome koristan kod ili uporabljivost komponente UML DIJAGRAMI STANJA, AKTIVNOSTI, povećaj KOMPONENTI I RAZMJEŠTAJA korištenje već otkrivenog, ali uporabu pazimo na intelektualno vlasništvo Pogledati povezanu (rozu) UML skriptu koja kombinira postojećeg oblikuj za ostaviti otvoren prostor za gradivo međuispita i završnog ispita. fleksibilnost promjene – zabranjen hardcoding ARHITEKTURE RASPODIJELJENIH SUSTAVA fokus na duljem životu programske planiraj potpore – izbjegavamo skroz nove Već smo spomenuli da postoje arhitekturni stilovi. U zastaru tehnologije i module, već biramo nastavku su neki od primjera – vrlo općenita podjela. one koje će ostati trajno dostupne oblikuj za efikasan rad na što većem broju prenosivost različitih platformi i okruženja oblikuj za automatsko ispitivanje koje može ispitivanje ispitivati zasebne module oblikuj ispitujemo komponente na sve konzervativno načine na koje se ona ne bi trebala (defenzivno) koristiti – bulletproof postoje preduvjeti (ugovori) za oblikuj po Danas su češći oblikovni obrasci – predstavljaju poziv neke metode i naša je ugovoru dokazano dobar način ponovne uporabe znanja o odgovornost da na to pazimo nekim čestim problemima i njihovim rješenjima. Postoji i pet principa za objektno usmjerene sustave Imaju naziv, opis, rješenje i posljedicu, a dijele se na koje pamtimo pod akronimom SOLID. stvaralačke, strukturne i ponašajne. svaki razred implementira jednu single odgovornost pa u budućnosti responsibility imamo jedan razlog za promjenu open-close svaki entitet je otvoren za principle proširenja, ali zatvoren za izmjene Liskov svaki objekt u programu treba moći substitution biti zamjenjiv podtipom onaj koji implementira sučelje ne interface smije ovisiti o neimplementiranim Raspodijeljeni sustav skup je računala povezanih segregation metodama (bolje manja sučelja) mrežom ili posredničkim programima – promatrani su dependency više razine ne smiju ovisiti o kao jedinstveni sustav iako dijele resurse. Obrada, inversion implementaciji nižih razina izračuni i logika su raspodijeljeni i odvojeni programi su u kontinuiranoj komunikaciji.  PR GI Takvi su sustavi skalabilni i manje osjetljivi na greške, Posrednička arhitektura (middleware) uključuje ali i složeni te zahtjevni što se upravljanja tiče. posrednički sloj između dva entiteta (u praksi često klijent i poslužitelj) koji osigurava nesmetanu Najpoznatiji primjer raspodijeljenih sustava je klijent- komunikaciju. Ovakva arhitektura dvostrano poslužitelj arhitektura, a imamo i ravnopravne djelovanje (komunikaciju) unutar usluge bez da mi sudionike (peer-to-peer) koji su nešto rjeđi u praksi. ručno moramo implementirati detalje. Arhitektura klijent-poslužitelj modelira se na način da Prednost je modularnost, transparentnost, (jedan ili više) klijent pristupa poslužitelju tražeći izmjenjivost i praktičnost, ali onda opet komunikacija uslugu, a poslužitelj (nekad i više, load balancing) biva malo sporijom (zbog dodatnog entiteta dostavlja uslugu – danas se protokoli aplikacijskog posrednika) i šansa za greškama je malo veća. sloja ponašaju upravo tako (WWW, FTP, SMTP, IMAP). Uslužno usmjerena arhitektura (SOAP) organizira Detaljnije – poslužitelj počinje s radom i sluša klijentski aplikaciju kao kolekciju usluga koje međusobno zahtjev. Klijent obavlja razne operacije i u nekom komuniciraju protokolima. Svaka je usluga trenutku šalje zahtjev poslužitelju koji ga obrađuje samodostatna i ne ovisi o drugima. (prihvati spajanje, šalje odgovor, rukuje odspajanjem). Dakle, promatramo sve kroz sferu usluga – zahtjevatelj Koriste se protokoli IP (mrežni sloj) i TCP (transportni traži uslugu, poslužitelj ju pruža, a posrednici sloj) jer svako računalo (i klijent i poslužitelj) ima IP olakšavaju njen protok. Koristi se istoimeni protokol adresu, samo što poslužitelj često ima i simbolično SOAP koji je neovisan o platformama i zasnovan na zadanu (www.nešto.com). Koristimo i IP adresu i vrata XML-u, a danas je zamijenjen stilom REST. kako bismo pristupili usluzi na aplikacijskom sloju. Mikroservis je malena web usluga koja koristi REST, Prednosti ovakve arhitekture su raspodjela, udaljeni samodostatna je, svaka za sebe izvodi svoje procese u rad, odvojeno oblikovanje, distribuiranost, istodobni svom jeziku i komunicira se međusobno ili HTTP ili TCP pristup više klijenata prema poslužitelju. Rizici su protokolom. Njihova svrha – aplikacije građene kao često sigurnosni (virusi, ali i prisluškivanje) te potreba skup mikroservisa kojima je onda lakše baratati. za održavanjem (moraju i odvojeno i zajedno raditi). RADNI OKVIRI ZA WEB RAZVOJ Višerazinska arhitektura (multi-layer) organizira program u razinama, a svaki sloj nudi svoje usluge. U objektno usmjerenom pristupu često se koriste Klijent-poslužitelj je nekad dvoslojna arhitektura, a radni okviri – platforme za razvoj programske potpore nekad troslojna (korisnička razina, logička razina i koje nude brojne komponente s jasno definiranim podatkovna razina – treba nam više tehnologija). sučeljima (namijenjene za ponovnu uporabu). Što je više slojeva i razina, to je veća modularnost, Oni su u osnovi nepotpuni, odnosno očekuje se da mi prenosivost i efikasnost, ali često je problem tunneling neke njihove dijelove (neke obvezno, a neke – za bolje performanse moramo preskakati razine u neobvezno) realiziramo sami – ali ih ne mijenjamo, slojevima, a prirodno je da svaka razina pruža uslugu eventualno proširujemo kostur (skeleton). razini iznad i uzima od razine ispod. Postoje horizontalni radni okviri koji se proširuju HTTP protokol temeljni je protokol usluge WWW, a intenzivnije i vertikalni radni okviri koji se proširuju najčešće su odgovori HTML datoteke i ono što one manje jer je puno toga implementirano. „pozivaju“ (CSS i JS). Metode HTTP-a definiraju se u Danas su najčešći radni okviri za web aplikacije zahtjevu: GET, HEAD, POST, PUT, DELETE, TRACE, itd. temeljeni na MVC arhitekturnom obrascu jer je on vrlo Ovaj protokol ključnu ulogu igra u stilu REST. On nije čest u praksi. Okviri olakšavaju rad s bazom podataka, nova arhitektura, već set pravila na temelju kojih se sjednicama, sigurnošću i slično. Primjeri uključuju definiraju sučelja (API) jer ograničavamo način Spring, React, Ruby on Rails, Angular i slično. komuniciranja. Danas je standard za klijent-poslužitelj MVC se s obzirom na tip obrade podataka dijeli na arhitekture i koristi norme HTTP, XML, JSON i URI. push i pull model. Prvi je puno češći i tu se podaci Bitno je znati sljedeće: NE pamtimo stanja (sve se obrađuju, a onda guraju u druge slojeve i prikazuju. pakira u HTTP zahtjevima) i stanja resursa vraćaju se Drugi je rjeđi i komponente su same odgovorne za kroz HTML, XML ili JSON. poziv koji će promijeniti njihovo stanje.  PR GI Radni okviri uvijek su višeslojni (višerazinski) i ugrubo Validacija (are we building the right system?) i se povezuju s MVC obrascem na način (korisnička verifikacija (are we building the system right?) nisu razina – V, podatkovna razina – M, logička razina – C). ista stvar – druga je više vezana za „konvencionalno“ testiranje kôda, a prva za razumijevanje razvoja. Dinamička verifikacija (ispitivanje u užem smislu) zapravo je ubacivanje ulaza i promatranje izlaza, odnosno dinamički (u momentu) testiramo sustav. Statička verifikacija je analiza bez izvođenja – češljanje kôda i nadzor, inspekcija koda za norme. Ispitljivi programi moraju biti osmotrivi ([ne]ispravnosti uočljive), upravljivi, djeljivi (neovisno Radni okvir na sebe preuzima ulogu organizatora ispitivanje modula), jednostavni, stabilni i razumljivi. između slojeva, što se naziva inverzija upravljanja i smanjuje međuovisnost – ono što je tradicionalnije, ali Cilj ispitivanja je, osim ispravljanja grešaka, ovdje nije prisutno, jest da kôd poziva libraries. minimiziranje rizika na programerskoj, pravnoj i administrativnoj razini. U praksi se inverzija upravljanja realizira kao ubacivanje ovisnosti (dependency injection). Radni HIJERARHIJA GREŠKE okvir ubacuje ovisnost o svojem ugrađenom objektu. uzročnik pogreške (ljudska greška, Većina radnih okvira ima posredničku arhitekturu, nerazumijevanje, loš kôd, loše kvar upravljanje, neodrživi timeline) koji podržava usmjeravanje (routing koji tumači URI i može neko vrijeme biti prikriven prosljeđuje na odgovarajuću logiku), upravljanje pogreška manifestacija kvara koja stvara zastoj perzistencijom podataka (sesije nisu trajna pohrana, nego baza – ORM), sigurnost (kolačići, sesije). sustav ne zadovoljava potrebne uvjete i zatajenje neispravno se ponaša Glavna klasifikacija radnih okvira jest na okvire na strani klijenta (frontend – Angular, Vue ili React) i one Kako bi nastalo zatajenje, kvar mora biti triggered, na strani poslužitelja (backend – Spring, Express). mora inficirati program i učiti nešto neispravnim te se React je tehnički knjižnica za frontend, dok je Angular to propagira na neki izlaz. veliki radni okvir odličan za složeniji UI, a popularan je Pogreške se obrađuju kroz prevenciju, detekciju i Spring koji je sveobuhvatan i ima tri glavna sloja (ispitivanje) i oporavak. Paretovo pravilo kaže da 20% (Controller, Service i Repository). greška uzrokuje 80% problema. ISPITIVANJE PROGRAMSKE POTPORE Ispitivanje treba početi rano, nije samo „kopanje“ po Ispitivanje programske potpore aktivnost je kojoj je kôdu. Kasnije su greške puno skuplje za ispravak. cilj definirati (ne)ispravnosti i kvalitetu te poboljšati Najbolje je koristiti neovisne (vanjske ili suradničke) programsku potporu pronalaskom kvarova. timove koji ne znaju „dobre podatke“ za ubaciti i neće biti u konfliktu s razvojnim timom. TEMELJNI KORACI ISPITIVANJA planiranje postavljanje ciljeva ispitivanja ispitivanja i prikupljanje relevantnih info oblikovanje ispitnih ispitni slučajevi bi trebali slučajeva zadovoljiti navedene ciljeve automatizacija priprema razvoje okoline i ispitivanja izrada ispitnih slučajeva provođenje izvođenje i prikupljanje ispitivanja rezultata ispitivanja vrednovanje utvrđujemo ishod ispitivanja, Ispitni slučaj je uređeni par (dani ulaz i očekivani izlaz) rezultata ispitivanja bitno je poznavati domenu definiran na temelju specifikacije – mi provjeravamo.  PR GI Kako znati da smo nešto potpuno ispitali? Teško – ni kada imamo veliku pokrivenost koda (code coverage) ne možemo reći da su sve funkcionalnosti ispitane. Dakle, možemo pristupiti ispitivanju na temelju pokrivenosti (naredbe pokrivamo), na temelju pogrešaka (nađi grešku i ispituj) i na temelju kvarova (tipična mjesta za kvarove). Dinamičko ispitivanje dijeli se na funkcijsko ispitivanje (black box, unknown inside) i strukturno ispitivanje (white box, transparent box). Statičko ne dijelimo. Funkcijsko ispitivanje provodi se bez poznavanja kôda, odnosno testiramo na temelju specifikacija – možemo predvidjeti izlaz čisto opisom ponašanja sustava. Strukturno ispitivanje nadopunjava funkcijsko i u njemu dobro poznajemo strukturu programa pa analiziramo putove kroz njega. Ako imamo stručnjake u timu, moguće je i ispitivanje na temelju znanja „veterana“ – iskustvene tehnike. METODE FUNKCIJSKOG ISPITIVANJA ulazi su (sve ili neke specifične) kombinacijsko moguće kombinacije parametara ispitivanje pa imamo problem kombinatorne eksplozije (previše slučajeva) domena ispitivanja dijeli se na particije i pretpostavljamo da se svi podjela na podaci jedne particije ponašaju ekvivalentne isto pa je dosta ispitati jedan – ili je particije cijela particija prošla ili cijela pala, a mi smo uspješno smanjili broj slučajeva koje moramo ispitivati opet dijelimo na particije, ali ovaj puta ispitni slučajevi moraju uključivati granične vrijednosti analiza skupova (dvovrijednosno ako graničnih ispitujemo vrijednost na granici i tik vrijednosti izvan granice, a trovrijednosno ako Najveći problem funkcijskog ispitivanja je ispitujemo vrijednost na granici i tik kombinatorna eksplozija ispitnih slučajeva, ali je dobar sa svake strane granice) izbor kada biramo jednostavnost i želimo da je ispitivanje testiranje moguće neovisno o jeziku implementacije. kombinacija prethodne 2 metode domene slučajan odabir vrijednosti po Strukturno ispitivanje nadopunjava funkcijsko slučajno uniformnoj razdiobi i testiramo s ispitivanje i zapravo je ispitivanje pomoću dostupnog ispitivanje njima – često kada ne znamo puno programskog kôda – ispitujemo putove, uvjete, protok toga o domeni ili stress testing podataka i slično. Cilj je pokriti programski kôd. U nastavku su neki primjeri za razumijevanje pojedinih Kako se programski kôd može analizirati? Imamo graf tipova ispitivanja, ali prije toga, pobliža definicija tijeka programa koji ga apstrahira – čvorovi su ispitnog slučaja – moramo odrediti ispitivani podatak, instrukcije, a lukovi kontroliraju tok. Na sljedećoj očekivani izlaz, ispitni slučaj (kombinacija prethodne stranici nalazi se primjer takvog grafa. dvije stvari), stvarni izlaz i kriterij prolaza.  PR GI Zaključno, strukturno ispitivanje zahtjeva uvid u kôd, a često je izuzetno puno putova za ispitivanje. Ovo je najiscrpniji i dugotrajniji oblik ispitivanja. Ispitivanje sive kutije kombinira funkcijsko i strukturno – znanje kôda je ograničeno, isto kao i znanje o specifikacijama sustava. Na svakom projektu definira se strategija ispitivanja, niz odluka kojima odlučujemo tko će što ispitati na Ispitivanje temeljnih putova svodi se na pronalazak kojoj razini i koje će se tehnike ispitivanja koristiti. Na temeljnih putova (putova koji se razlikuju barem po kraju očekujemo izvješće o odstupanjima. jednom čvoru) i promatranja njihovog ponašanja. Svaki tim ima voditelja, analitičara koji pomaže u tumačenju specifikacija, voditelja upravljanja kvalitetom, ispitivače (kreativne i kritički orijentirane) te korisnike koji mogu biti zadnji ispitivači. AUTOMATIZACIJA ISPITIVANJA Organizacija ispitivanja ovisi o svojstvima programske potpore, modelu procesa programske potpore, stavovima i iskustvu tima i još puno toga. Možemo pratiti V-model ispitivanja u kojem se sustav izrađuje pa obrnutim redom ispituje. Također se definira ciklomatska složenost grafa – broj linearno neovisnih putova u temeljnom skupu. Oznaka „P“ je broj nepovezanih komponenata u grafu i u 99% slučajeva iznosi jedan jer je jedan graf na slici. Možemo ispitivati i uvjete (sljedeći primjer) i petlje. Ispitivanje uvjeta nije teško, ali ispitivanje petlji brzo se komplicira pa se radi za „zeznute“ slučajeve – preskakanje petlje, jedan i dva prolaska, i