1. Oblikovanje programske potpore
O čemu je riječ u ovom predmetu?
Copyright Nikola Bogunovic, FER

2. Copyright Nikola Bogunovic, FER
Značajan događaj ( )
Therac-25: sustav za terapiju radioaktivnim zračenjem
(elektroni ili fotoni do 25 MeV)
6 fatalnih pogrešaka (primljene prekomjerne doze)
Najgori akcident u 40 godina terapije zračenjem
Program:
- DEC PDP 11 asembler (simbolički program)
- konkurentni procesi
- “test and set” nije bila nedjeljiva operacija
- višestruki upis u zajedničku varijablu
Copyright Nikola Bogunovic, FER

3. Copyright Nikola Bogunovic, FER
Software “HALL OF SHAME”:
1993: London Stock Exchange ($ 600 M, canceled)
1996: Arianespace (Ariane 5 rocket explosion, $350 M)
1999: State of Mississippi (Tax system, $185 M loss)
2001: Nike Inc. (Supply chain management, $100 M loss)
2002: McDonald’s (Purchasing system canceled, $170 M)
2004: Hewlett-Packard (Management system, $160 M loss)
2004: Sainsbury food chain, UK ($527 M, canceled)
2004: Ford Motor Co. (purchasing, $400 M, canceled)
2004: Mars Spirit, NASA: "a serious software anomaly“
2005: UK Tax (soft errors resulted in $3.5 G (billion) overpay)
. . .
Što je tome uzrok ?
Copyright Nikola Bogunovic, FER

4. Copyright Nikola Bogunovic, FER
Tradicijski postupak oblikovanja sustava (1):
aktivnost
Analiza zahtjeva
rezultat
Specifikacija sustava
Odjeljivanje sklopovlja i programskih dijelova
Spec. sklopovlja
Spec. programa
Copyright Nikola Bogunovic, FER

5. Copyright Nikola Bogunovic, FER
Tradicijski postupak oblikovanja sustava (2): ?
Spec. sklopovlja
Spec. programa
Sinteza i konfiguracija programa
Sinteza i konfiguracija sklopovlja
Sinteza sučelja
Konf. moduli
Sklopovske komponente
HW/SW sučelje
Progr. moduli
USPJEH ?
HW/SW integracija
Evaluacija sustava
Prijenos korisniku
Copyright Nikola Bogunovic, FER

6. Copyright Nikola Bogunovic, FER
Nedostaci tradicijskog postupka oblikovanja sustava (1)
Temeljni nedostatak br. 1:
Proces sinteze sustava nije propisan (strukturiran) ni formalno definiran
Zahtjevi nisu formalizirani** te je nemoguće postići preciznost u oblikovanju, a neodređenost vodi k nekompatibilnosti s okruženjem i drugim sustavima.
Izgradnja “ad hoc” prototipa ne omogućuju dublju analizu
sustava.
Procjena performansi temeljena na neformalnom pristupu daje
pogrešne vrijednosti.
Dijeljenje na sklopovski i programski dio nije poduprto
formalnim transformacijama i postupcima donošenja odluka.
Dokumentacija se zbog ovih neodređenosti teško tumači.
_______________________________________________________
** Formalni = utemeljeni na matematičkim teorijama (logika, teorija
automata, teorija grafova, …).
Copyright Nikola Bogunovic, FER

7. Problem ispitivanja (testiranja) sustava:
Nedostaci tradicijskog postupka oblikovanja sustava (2)
Temeljni nedostatak br. 2:
Problem ispitivanja (testiranja) sustava:
Ručno ispitivanje složenog sustava je nedovoljno duboko jer ljudski um nije u mogućnosti predvidjeti sve moguće interakcije.
Cijena testiranja čini najveći dio cijene produkta.
Pokrivenost skupa testiranih stanja je ograničena.
“Corner cases” (netipični scenariji) teško se identificiraju.
Inzistiranje na kratkom vremenu stavljanja proizvoda na
tržište (engl. time to market) smanjuje pokrivenost već
ionako malog skupa ispitanih stanja.
Ispravnost provjeravana simulacijama i testiranjem
može samo dokazati postojanje pogreške (“bug”) ali
nikada njeno nepostojanje (Dijkstra) !!!
Copyright Nikola Bogunovic, FER

8. Copyright Nikola Bogunovic, FER
Što učiniti da se smanji vjerojatnost neuspjeha ?
Razmotrimo kako velike tvrtke (npr. IBM) gledaju na problem oblikovanja programske potpore...
Sljedeće slike su preuzete od: Bran Selic
“IBM Distinguished Engineer” u IBM Rational.
Honorarni profesor, Carleton University in Ottawa, Canada.
Preko 30 godina iskustva u oblikovanju i implementaciji velikih industrijskih programskih sustava.
Predvodnik metodologije oblikovanja zasnovanog na modelima (engl. Model-driven Development Methods).
Predsjeda OMG (Object Management Group) timu odgovornom za standard “unificirani jezik za modeliranje” UML 2.0 (engl. Unified Modeling Language).
Copyright Nikola Bogunovic, FER

9. Copyright Nikola Bogunovic, FER

10. Copyright Nikola Bogunovic, FER

11. Copyright Nikola Bogunovic, FER
(written in SystemC)
Copyright Nikola Bogunovic, FER

12. Copyright Nikola Bogunovic, FER
The power of modeling ?
(the architecture)
Copyright Nikola Bogunovic, FER

13. Copyright Nikola Bogunovic, FER

14. Engineering Models Engineering model:
A reduced representation of some system that highlights the properties of interest from a given viewpoint
Modelirani sustav
Funkcijski model
Ne vide se svi dijelovi sustava odjednom
Koristi se lako razumljiv model (reprezentacija) sustava za određenu svrhu

15. Difficulties with engineering models

16. Copyright Nikola Bogunovic, FER
Introducing modeling languages
Copyright Nikola Bogunovic, FER

17. Copyright Nikola Bogunovic, FER
Property of software modeling
Copyright Nikola Bogunovic, FER

18. Copyright Nikola Bogunovic, FER

19. The Remarkable Aspects of Software
Software has the unique property that it allows us to evolve abstract models into full-fledged implementations without changing the engineering medium, tools, or methods!
It also allows us to generate abstract views directly and automatically from the implementations
This ensures perfect accuracy of software models; since the model and the system that it models are the same thing!
Copyright Nikola Bogunovic, FER

20. Copyright Nikola Bogunovic, FER

21. Copyright Nikola Bogunovic, FER

22. Copyright Nikola Bogunovic, FER
of "mindstuff"
Copyright Nikola Bogunovic, FER

23. Copyright Nikola Bogunovic, FER
ZAKLJUČCI:
Kako oblikovati programsku potporu da se smanji vjerojatnost neuspjeha ?
1. Uvesti inženjerski propisane postupke (procedure) u proces oblikovanja programske potpore (precizno definirati faze procesa oblikovanja – tko radi, što radi i kada radi).
2. Svaku fazu procesa oblikovanja dokumentirati (po mogućnosti na standardan i formalan način).
3. U oblikovanje uvesti analizu i izbor stila arhitekture programske potpore te pripadne modele pogodne za formalnu analizu.
4. Programski produkt oblikovati u manjim cjelinama (komponentama).
5. Uz tradicijsko ispitivanje (testiranje) uvesti formalne metode provjere (verifikacije) modela programske potpore.
Copyright Nikola Bogunovic, FER

24. Copyright Nikola Bogunovic, FER
Detaljnije o ZAKLJUČCIMA:
1. Uvesti inženjerski propisane postupke (procedure) u proces oblikovanja programske potpore (precizno definirati faze procesa oblikovanja – tko radi, što radi i kada radi).
Ovaj dio problema oblikovanja programske potpore analizira i predlaže rješenja disciplina koja se naziva Programsko inženjerstvo (engl. Software engineering).
Nema jedinstvenog i standardnog prijedloga, ali postoje neke generičke aktivnosti u svim prijedlozima.
Nekoliko najpopularnijih pristupa pokazat će se u nastavku predavanja.
Posebice će se razmotriti dio programskog inženjerstva u kojem se navode postupci kako precizno specificirati zahtjeve koje korisnik postavlja na sustav.
Disciplina koja se bavi ovim dijelom Programskog inženjerstva naziva se Inženjerstvo zahtjeva (engl. Requirements engineering).
Copyright Nikola Bogunovic, FER

25. Copyright Nikola Bogunovic, FER
Detaljnije o ZAKLJUČCIMA:
2. Svaku fazu procesa oblikovanja dokumentirati (po mogućnosti na standardan i formalan način).
Svaki proces oblikovanja programske potpore ima svoje faze.
Rezultat svake faze oblikovanja je dokument.
Tako postoje dokumenti koji specificiraju zahtjeve korisnika, dokumenti koji specificiraju arhitekturu sustava (uz navođenje argumenata zašto je izabrana), dokument kodiranja, dokument ispitivanja i sl.
Rezultat oblikovanja projekta na ovom kolegiju je također dokument.
Dokumenti se podvrgavaju ocjeni i reviziji (promjeni).
Copyright Nikola Bogunovic, FER

26. Copyright Nikola Bogunovic, FER
Detaljnije o ZAKLJUČCIMA:
U oblikovanje uvesti analizu i izbor stila arhitekture programske potpore te pripadne modele pogodne za formalnu analizu.
Temeljem (dokumenta) izlučivanja zahtjeva analizira se nekoliko stilova arhitekture programske potpore kako bi se došlo do optimalnog izbora obzirom na konkretnu primjenu.
Stilovi arhitekture ne mogu se analizirati na razini programskog koda, već na apstrakcijama te arhitekture – modelima.
Svi stilovi arhitekture nisu jednako detaljno podržani modelima.
Neki stilovi još nemaju standardne modele.
Najdetaljnije je podržan stil arhitekture koji se naziva Objektno usmjeren pristup; OO (engl. Object oriented) i taj stil će biti u fokusu ovoga kolegija.
Copyright Nikola Bogunovic, FER

27. Copyright Nikola Bogunovic, FER
Detaljnije o ZAKLJUČCIMA:
Programski produkt oblikovati u manjim cjelinama (komponentama).
Oblikovanje programske potpore slijedi princip “podijeli pa vladaj” (engl. divide-and-conquer).
U fokusu oblikovanja su manji dijelovi sustava – komponente, te njihovo ponovno i višestruko korištenje (engl. reuse).
Princip višestrukog korištenja u oblikovanju programske potpore manifestirao se tijekom vremena kroz:
programske jezike
knjižnice procedura i objekata,
ponovno korištenje manjih dijelova arhitekture (arhitekturni obrasci – engl. architectural patterns) ili
većih dijelova arhitekture (radni okviri – engl. frameworks).
Copyright Nikola Bogunovic, FER

28. Copyright Nikola Bogunovic, FER
Detaljnije o ZAKLJUČCIMA:
Uz tradicijsko ispitivanje (testiranje) uvesti formalne metode provjere (formalnu verifikaciju - FV) modela programske potpore.
Temelji formalne provjere - verifikacije (FV) modela sustava
Tijekom procesa oblikovanja generiraju se dva objekta:
S - specifikacija (što sustav treba raditi) = formalna specifikacija
I - implementacija (kako to sustav radi) = formalni model
Treba odrediti da li: I odgovara S
Pri tome je “odgovara” = logička zadovoljivost
Formalna verifikacija (FV) je postupak provjere da li formalni model implementacije (/) logički zadovoljava specifikaciju (S) .
Copyright Nikola Bogunovic, FER

29. Copyright Nikola Bogunovic, FER
Formalna verifikacija (FV):
Model implementacije (I)
Da / Ne
(ako NE, ispis pogrešnog izvođenja)
Sustav za verifikaciju
Specifikacija (S)
Postoje dvije vrste programa:
1, Ulazno/izlazni programi
Specifikacija (S) – željena transformacija ulaza (npr. y = x2 ).
Model implementacije (/) – matematički opis izvedbe transformacije ulaza
(npr. y = … (2x - 1) ).
Copyright Nikola Bogunovic, FER

30. Copyright Nikola Bogunovic, FER
2. Reaktivni programi:
trajna interakcija s okolinom (operacijski sustavi, upravljanje avio letovima, upravljanje nuklearnim reaktorom, …)
S, I: potreban je formalni opis njihovog ponašanja tijekom vremena
Specifikacija željenog ponašanja (S) – formalna logika proširena vremenskim operatorima budućeg
ponašanja (vremenska logika).
Npr. željeno ponašanje:
“Nikada se ne smije dogoditi da su vrata otvorena dok se lift kreće”
Specifikacija (S) vremenskom logikom:
AG ( otvorena_vrata  lift_se_krece)
Model implementacije (I):
Strojevi s konačnim brojem stanja (FSM).
Copyright Nikola Bogunovic, FER

31. Copyright Nikola Bogunovic, FER
Formalna verifikacija (FV) dio je područja kojega nazivamo
Formalne metode (FM).
Pitanje:
Da li se kakvoća i pouzdanost programske potpore povećava uvođenjem formalnih metoda u proces oblikovanja ?
Odgovor:
US Computer Science and Technology Board:
FM trebaju biti ključna inženjerska vještina u računarstvu koja povećava kakvoću produkta i istovremeno smanjuje vrijeme stavljanja produkta na tržište (“time to market”),
Copyright Nikola Bogunovic, FER

32. Copyright Nikola Bogunovic, FER
Temeljem ranije analize nedostataka tradicijskog postupka oblikovanja sustava i izvedenih zaključaka slijedi predloženi moderan postupak oblikovanja koji uključuje:
Propisane strukturirane postupke.
Dokumentiranje.
Modeliranje (apstrakciju).
Višestruku uporabu komponenata.
Formalna verifikacija modela + tradicijsko ispitivanje.
Copyright Nikola Bogunovic, FER

33. Copyright Nikola Bogunovic, FER
Moderan postupak oblikovanja sustava (1):
Analiza zahtjeva
aktivnost
Specifikacija sustava
rezultat
Modeliranje
Poboljšani model
Model sustava
Poboljšanje
Funkcijska obilježja
Validacija
Validirani model
Verificirani i simulirani model sustava
Verifikacija i simulacija NE DA
Kritična obilježja
Copyright Nikola Bogunovic, FER

34. Validacija i verifikacija - razlike
Validacija: da li smo napravili ispravan sustav ?
(da li sustav zadovoljava funkcijske zahtjeve)
(engl. “Are we building the right system?”)
Verifikacija: da li smo ispravno napravili sustav ?
(da li sustav zadovoljava zahtjeve na ispravan način, tj. odsustvo kvarova)
(engl. “Are we building the system right ?”)
Copyright Nikola Bogunovic, FER

35. Copyright Nikola Bogunovic, FER
Moderan postupak oblikovanja sustava (2):
Oblikovanje zasnovano na modelima
(engl. Model based design)
Verificirani i simulirani model sustava
Utvrđivanje tehnologije
Sklopovske komponente
Evaluacija sustava
Sučelja
Oblikovanje zasnovano na komponentama
(engl. Component based design)
Programske komponente
Copyright Nikola Bogunovic, FER

36. Gdje se nalazimo u evoluciji oblikovanja programske potpore ?
Metodologija oblikovanja programske potpore razvijala se i mijenjala od 50-tih godina prošlog stoljeća.
Razvija se i nadalje jer nisu dosegnuti standardi kao što je to primjerice u drugim inženjerskim disciplinama.
Ako taj razvoj pokušamo u grubo usporediti s razvojem čovjeka, može se reći da smo danas u sljedećoj točki:
Copyright Nikola Bogunovic, FER