1. III. dio Oblikovanje i implementacija, nastavak
9. predavanje
III. dio
Oblikovanje i implementacija, nastavak

2. U ovom predavanju trebali bi...
definirati ponovnu upotrebu softvera koja može značajno smanjiti cijenu, a povećati kvalitetu softvera
opisati nekoliko načina kako implementirati ponovnu upotrebu softvera

3. Ponovna upotreba softvera 1/2
Već smo uveli model za softverski proces zasnovan na ponovnoj upotrebi softvera
Što veći dio softvera treba realizirati korištenjem dijelova iz već postojećih sustava

4. Ponovna upotreba softvera 2/2
Prednosti:
- manje softvera kojeg stvarno treba napraviti, te se smanjuje vrijeme, trošak i rizik
- stavlja se oslonac na već projverene, dobro testirane i korištene dijelove softvera
Mane:
- sustav nekad neće u potpunosti odgovoriti na sve zahtjeve korisnika
- djelomično je izgubljena kontrola nad evolucijom sustava, jer ne upravljamo mi s razvojem novih verzija korištenih dijelova

5. Nužni uvjeti za ponovnu upotrebu softvera
Mora postojati katalog upotrebljivih dijelova softvera
Korisnik gotovih dijelova mora biti uvjeren u njihovu kvalitetu
Dijelovi u katalogu moraju biti dobro dokumentirani

6. Razvoj zasnovan na komponentama
Ovakav način razvoja softvera pojavio se u kasnim '90-tim godinama 20. stoljeća
Klase objekata su bile premale cjeline za uspješnu prodaju na tržištu
Nastoji se stvoriti veće cjeline – komponente
Komponenta je samostalni pružatelj usluga
Kada naš sustav treba uslugu – poziva komponentu, ne brinući se pri tome gdje se ona izvršava i u kojem je prog. jeziku napisana

7. Osnovna svojstva komponente
Komponenta je nazavisna izvršiva cjelina čiji nam izvorni kod nije dostupan, tako da se ona kompajlira zajedno s ostalim dijelovima našeg sustava
Komponenta objavljuje svoje sučelje i sve operacije s njome odvijaju se kroz to sučelje
Sučelje komponente izražava se u terminima parametriziranih operacija
Unutarnje stanje komponente nije nam vidljivo

8. Sučelje komponente 1/2

9. Sučelje komponente 2/2
"Provides interface" definira servise koje komponenta pruža
"Requires interface" definira koji servisi moraju biti dostupni samoj komponenti u sustavu koji koristi tu komponentu. Bez tih servisa komponenta ne može raditi!

10. Primjer komponente za prikupljanje podataka

11. Komercijalne komponente
Danas postoje tvrtke koje proizvode i prodaju softverske komponente
Kupuju ih druge softverske kuće
Komponenta za prodaju mora biti dovoljno općenita, pažljivo verificirana i dobro dokumentirana
Mogu biti manje ili veće, pa čak i do veličine cijele aplikacije

12. Stupnjevi veličine komponente 1/2
Apstrakcija funkcije – implementira jednu funkciju, npr. sinus ili kvadratni korijen, "Provides interface" je ta funkcija
Slučajno grupiranje – komponenta je skup labavo povezanih entiteta kao što su deklaracije podataka, funkcije itd. "Provides interface" sastoji se od imena tih entiteta
Apstraktni tip podataka – komponenta predstavlja apstraktni tip ili klasu u smislu OOP jezika. "Provides interface" sastoji se od operacija za stvaranje, promjenu i čitanje primjerka

13. Stupnjevi veličine komponente 2/2
Apstrakcija klastera – komponenta je skup povezanih klasa koje rade zajedno ("framework"). "Provides interface" je unija svih sučelja za klase koje čine framework
Apstrakcija sustava – komponenta predstavlja samostalni sustav. Obično se naziva COTS sustav (Commercial Off-The-Shelf System). "Provides interface" je tzv. API (Application programming Interface) koji je definiran zato da omogući programima pristup do naredbi i operacija sustava

14. Primjeri klastera (frameworka)
Infrastrukturni framework – podržava razvoj infrastrukture kao što je komunikacija, grafičko sučelje, "parsiranje" komandi itd.
Middleware framework – implementira standard za komunikaciju komponenti: CORBA, MS COM, MS DCOM, JavaBeans...
Enterprise application framework – implementira operacije iz specifičnih aplikacijskih domena, npr. financijski sustavi, knjižnice, ...

15. Primjeri COTS sustava
Sustav za upravljanje bazom podataka (DBMS), npr. Oracle, Microsoft SQL Server, IBM DB2, MySQL,...
Tablični kalkulator poput MS Excel
Emulator neuronskih mreža poput StatSoft Statistica
Kalkulator matematičkih funkcija poput WRI Mathematica

16. Porodice aplikacija
Porodica aplikacija ili produktna linija je skup srodnih aplikacija koje imaju zajedničku arhitekturu
Svaki član porodice je specijaliziran u nekom smislu
Zajednička jezgra svih članova porodice ponovno se upotrebljava svaki put kad se pojavi potreba za novim članom porodice
Novi član se razvija tako da se iz stare verzije prepravljaju postojeći dijelovi, te dodaju novi

17. Tipovi specijalizacije jedne aplikacije unutar porodice 1/2
Platformska specijalizacija – razne verzije iste aplikacije na različitim platformama (Windows, Linux, Mac OS, Solaris, ...). Funkcionalnost je svugdje ista, promijenjeni su samo oni dijelovi koji komuniciraju sa hardverom i operacijskim sustavom
Konfiguracijska specijalizacija – razne verzije aplikacije stvaraju se kako bi rukovale s različitim vanjskim uređajima. Funkcionalnost verzija varira s obzirom na drugačiju funkcionalnost vanjskih uređaja

18. Tipovi specijalizacije jedne aplikacije unutar porodice 2/2
Funkcionalna specijalizacija – razne verzije aplikacije stvaraju se za kupce s različitim zahtjevima. Npr. drugačiji je sustav potreban za gradsku, a drugačiji za školsku knjižnicu pa imamo različite verzije takve aplikacije, tako da je funkcionalnost izmijenjena.

19. Primjer aplikacije upravljanja inventarom

20. Drugi primjer s raspoređivanjem vozila hitne ili vatrogasaca

21. Komentar dva primjera
U ova dva primjera vidimo jednu slojevitu arhitekturu aplikacije
Vidi se ponovno korištenje dijelova sustava
Osim toga jasno se vidi da se iz prvog primjera sustava, moglo nadograđivati i razviti drugi primjer sustava, pri tome, neki dijelovi sustava su ostali isti
Iz tih primjera lako je razviti još neke druge verzije sustava za drugačiju upotrebu

22. Koraci u razvoju novog člana porodice 1/2

23. Koraci u razvoju novog člana porodice 2/2
Ponovno pregovaranje o zahtjevima je poželjno kako bi se minimizirale promjene u postojećoj (najsličnijoj) verziji aplikacije
Ukoliko korisnik pristane na kompromise, tada će nova verzija biti jeftinija i brže isporučena
Uzastopnim razvojem novih članova dolazi do postupnog kvarenja polazne arhitekture
U jednom trenutku može se odlučiti za novu i bolju generičku aplikaciju
Nova aplikacija ne nasljeđuje programski kod koji se piše iznova, nego samo iskustva

24. Obrasci za oblikovanje
Obrasci za oblikovanje (eng. design patterns) - apstraktni dizajn koji definira uspješno rješenje za dobro poznati problem koji se često pojavljuje u različitim kontekstima
Ukoliko se susretnemo s takvim problemom – riješit ćemo ga odgovarajućim obrascem
Ovdje dolazi do ponovne upotrebe dizajna, a ne programskog koda

25. Obrasci i skupljanje mudrosti
Obrasci nastaju kao pokušaj da se dokumentira skupljena mudrost i iskustva u rješavanju problema
Skupljanje mudrosti prisutno je u gotovo svim granama računarstva (npr. tradicionalne knjige o strukturama podataka i algoritmima)
Kada govorimo o obrascima za oblikovanje tada mislimo na pristup koji je nastao u okviru objektnog oblikovanja, gdje se rješenje izražava kao objektni model od nekoliko apstraktnih klasa

26. Obavezni elementi kod obrasca za oblikovanje
Smisleno ime za obrazac
Opis problema - iz kojeg je vidljivo kad se obrazac može primijeniti
Opis rješenja – objašnjava dijelove predloženog dizajna, te odnose između tih dijelova (dijagrami klasa gdje se vidi nasljeđivanje i druge vrste veza)
Opis posljedica – nabrajaju se prednosti i mane primjene predloženog obrasca

27. Primjer "observer pattern" za različiti prikaz stanja istog objekta (1/2)
Ime: observer
Opis: razdvaja prikaz stanja od samog objekta
Opis problema: koristi se kad je potreban različiti prikaz stanja objekata
Rješenje: (idući slide)

28. Primjer "observer pattern" za različiti prikaz stanja istog objekta (2/2)
Posljedice: optimizacije koje poboljšavaju performanse prikaza nisu praktične

29. Realizacija višestrukog prikaza