1 / 43

Formalni postupci u oblikovanju računalnih sustava 2008. god. Nositelj: Prof.dr.sc. Nikola Bogunović ( D-309 ) Nikola.B

Formalni postupci u oblikovanju računalnih sustava 2008. god. Nositelj: Prof.dr.sc. Nikola Bogunović ( D-309 ) Nikola.Bogunovic@fer.hr Asistenti: Igor.Grudenic@fer.hr - D 34 2 Alan.Jovic@fer.hr - D 340 Ivan.Zuzak @fer.hr - D 3 38. Detaljna satnica i nastavni materijali :

elam
Download Presentation

Formalni postupci u oblikovanju računalnih sustava 2008. god. Nositelj: Prof.dr.sc. Nikola Bogunović ( D-309 ) Nikola.B

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Formalni postupci u oblikovanju računalnih sustava 2008. god. Nositelj: Prof.dr.sc. Nikola Bogunović ( D-309 ) Nikola.Bogunovic@fer.hr Asistenti: Igor.Grudenic@fer.hr- D342 Alan.Jovic@fer.hr - D 340 Ivan.Zuzak@fer.hr- D338

  2. Detaljna satnica i nastavni materijali : http://www.zemris.fer.hr/ ----> FPORS http://www.fer.hr/predmet/fpuors Predavanja: Petak: 09:15 -- 11:00, B4 Auditorne i dopuna predavanja: Ponedjeljak: 08:15 -- 10:00, D1 (Osim prvih auditornih: Ponedjeljak, 03.03.2008., 14:15 -16:00, D1 ) Na auditornima rješavanje ispitnih zadataka ! Labs: Ponedjeljak: 14-18, A-102, A-101, kolokviranje !!

  3. Laboratorijske vježbe (uvjet za potpis) 6 vježbi uz kolokviranje, izrada slobodno ili u labu, pomoć skripta i auditorne. Kolokviji iz vježbi (6): prema rasporedu (ponedjeljkom 14:00 - 18:00) 20 min 3 + 3 regularna termina + 2 za nadoknadu Ukupan broj bodova svih vježbi (6 x max 5 = max 30) Normalizira se na max 6.0 Uvjet za potpis:  2.0 Ispitivanje sustava: 10.03.2008., 14:00 – 16:30 po rasporedu dolazak = 0.6 (1/10 od max 6 boda) – nije obvezno Poslije ispitivanja (od 16:30 do 18:00) lab je otvoren za neobveznu izradu 1. vježbe. Prvi kolokvij (od 6) iz labosa: 17.03.2008., PO RASPOREDU

  4. KONTROLNE ZADAĆE 1. Kontrolna zadaća: Petak, 11.04.2008., 10:00 – 12:00, više dvorana po rasporedu 2. Kontrolna zadaća Petak, 30.05.2008., 10:00 – 12:00 više dvorana po rasporedu Obavijesti na: http://www.zemris.fer.hr/ ----> FPORS http://www.fer.hr/predmet/fpuors

  5. Ocjena: Normalizacija i maksimalni bodovi: Kontr. zadaća 1 : 10b (min 25% od najbolje) Kontr. zadaća 2 : 10b (min 25% od najbolje) K1 i K2 uključuju gradivo iz predavanja i labosa. K2 nema sadržaja iz K1. Lab. vježbe : 6b (min 2, uvjet za potpis) _____________ Ukupno : 26.0 boda U ocjenu na reg. roku ulazi ocjena iz labosa (20 + 6 b). Lagane zadaće: od 13 do 26 boda Teže zadaće: od 11do 26 boda Za ocjene preko kontrolnih zadaća moguća razdioba: 15% (5), 35% (4), 35% (3), 15% (2) (Bologna !)

  6. Nastavne cjeline u predavanjima: www.zemris.fer.hr/ ----> FPORS/Pred. 1. Uvod 2. Labs http://www.zemris.fer.hr/----> FPORS/lab. 3. Logika (predikatna i vremenska CTL) 4. Verifikacija provjerom modela (MC) 5. Logičke funkcije i predstavljanje BDD-ovima 6. Verifikacija uporabom BDD-ova 7. Modeli u sklopovsko-programskom suoblikovanju 8. Petrijeve mreže 9. Stilovi arhitekture programskih sustava 10. UML

  7. Događaj 1 (1985-1987) • Therac-25: sustav za terapiju radioaktivnim zračenjem • (elektroni ili fotoni do 25 MeV) • 6 fatalnih pogrešaka (prekomjerne doze) • Najgori akcident u 40 godina terapije zračenjem • Program: • - DEC PDP 11 asembler • - konkurentni prosesi • - “test and set” nije bila nedjeljiva operacija • - višestruki upis u zajedničke varijable

  8. Događaj 2 (1994/5) Pentium mikroprocesor Pogreška u računanju s pomičnim zarezom (“floating point”). Izostala formalna verifikacija (“corner bug”). Trošak: 500 Mil USD.

  9. 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) . . .

  10. Tradicijski postupak oblikovanja sustava (1): aktivnost Analiza zahtjeva rezultat Specifikacija sustava Odjeljivanje sklopovlja i programskih dijelova Opis sklopovlja Opis programa

  11. Tradicijski postupak oblikovanja sustava (2): Opis sklopovlja Opis programa Sinteza i konfiguracija programa Sinteza i konfiguracija sklopovlja Sinteza sučelja Konf. moduli Sklopovske komponente HW/SW sučelje Progr. moduli HE/SW integracija Evaluacija sustava Verifikacija sustava

  12. Nedostaci tradicijskog postupka oblikovanja sustava • Analiza i oblikovanje: • Zahtjevi nisu formalizirani (nemoguće postići preciznost, • neodređenost vodi u nekompatibilnost) • Izgradnja prototipa (neformalni prototipovi • ne omogućuju dublju analizu) • Procjena performanci (neformalni modeli daju • pogrešne vrijednosti) • Dijeljenje na sklopovski i programski dio nije • poduprt formalnim transformacijama • Dokumentaciju teško interpretirati • Ručna provjera: • Nedovoljno duboka • Ljudski um nije u mogućnosti predvidjeti • sve moguće interakcije u složenim sustavima.

  13. Problemi ispitivanja (testiranja) sustava • Cijena testiranja čini najveći dio cijene produkta. • Ljudski um nije u mogućnosti predvidjeti sve moguće interakcije u složenim sustavima. • Pokrivenost skupa testiranih stanja se smanjuje. • Podupire se podupire mentalitet “kolektivne krivnje”. • “Corner cases” se sve teže identificiraju. • Vrijeme stavljanja proizvoda na tržište (“time to market”) diktira kratko testiranje. • Posljedica: NEISPRAVNI SUSTAVI

  14. Posebice: tradicijsko oblikovanje programskih produkata • Formulacija zahtjeva (“requirements”, što bi sustav trebao raditi). • Specifikacija i analiza. • Oblikovanje (kako će sustav ispuniti ciljeve). • Kodiranje (stvarno programiranje). • Testiranje modula. • Integracija i testiranje sustava. • Ispravnost se provjeravasimulacijama i testiranjem koje: • mogu samo dokazati postojanje pogreške (“bug”)ali nikada njenonepostojanje (Dijkstra) !! • Što učiniti ?

  15. Engineering Models Functional Model Modeled system • Engineering model: A reduced representation of some system that highlights the properties of interest from a given viewpoint • We don’t see everything at once • We use a representation (notation) that is easily understood for the purpose on hand

  16. 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

  17. Moderan postupak oblikovanja sustava (2): Verificirani i simulirani model sustava “component-based design - IPs” Utvrđivanje tehnologije Sklopovlje Evaluacija sustava Sučelja Programske komponente

  18. Temelji formalne verifikacije (FV) Dva objekta: S - specifikacija (što sustav treba raditi) - formal. spec. I - implementacija (kako to sustav radi) - formal. model Odredi da li: IodgovaraS. “Odgovara”: ekvivalencija, simulacijske relacije, logička zadovoljivost, logička implikacija, implementacijske relacije, …

  19. Primjeri: Ulazno/izlazni programi: S: y = x2 I: y = 1 + 3 + … + (2x - 1) Reaktivni programi: trajna interakcija s okolinom (operacijski sustavi, upravljanje avio letovima, upravljanje nuklearnim reaktorom, …) S, I: formalizacija njihovog ponašanja tijekom vremena

  20. Formalna verifikacija postupak provjere da formalni model izvedenog sustava (/), odgovara formalnoj specifikaciji (S) sa matematičkom izvjesnošću I Da / Ne Sustav za verifikaciju S

  21. Pažnja: Često se oglašava da FV daje apsolutnu sigurnost u ispravnost sustava (programa/sklopovlja). iako FV garantira izvan svake sumnje samo ispravnu relaciju između formalnih (matematičkih) objekata I i S. FV ne osigurava ispravnu relaciju između stvarne implementacije i specifikacije. Temeljno: radi se s modelima (apstrakcijama) stvarne implementacije

  22. Razlozi neispravnosti postupka i rezultata FV 1. Razlika između matematičkih objekata i realnosti model I nije obuhvatio bitna obilježja realne implementacije (npr. ograničena duljina riječi, precizna informacija o vremenskim odnosima i sl.). Model S pretpostavlja suviše jaka ograničenja okoliša. 2. Neadekvatna specifikacija S ne opisuje intencije korisnika. S je nekompletan ili neispravan (opisuje krivo ponašanje).

  23. Kako specificirati “što želimo” (formalan opis, S): • Logika predikata prvoga reda: • X [c  (Xb)] • Vremenska logika: • “Signal REQ mora biti istinit i ostati istinit sve dok signal GRANT ne postane istinit” • Modeli implementacije ( I ): • Regularni jezici • Automati s konačnim brojem stanja • ( Opisi su ekvivalentni)

  24. Vremenska logika Specifikacija S(ponašanje u budućnosti): “Nikada se ne smije dogoditi da su vrata otvorena dok se lift kreće”, t.j ( otvorena_vrata lift_se_kreće ) mora uvijek biti neistinito. Primjer specifikacije: AG ( otvorena_vrata  lift_se_krece) Emerson - Clarke notacija (gornji primjer) Pnueli - Manna notacija:

  25. Okosnice za FV Algoritamska verifikacija –Provjera modela Istraživačka tehnika za strojeve s konačnim brojem stanja. Pobrojavanje (enumeriranje i simboličke varijante). Postupci zasnovana na dokazivanju teorema ( ATP ) Primjenjivi na sustave s beskonačnim brojem stanja. Zahtijevaju interakciju korisnika (ekspertno znanje).

  26. Provjera modela (engl. Model Checking) Treba dokazati da vremenski specificirano obilježje vrijedi tijekom svih ponašanja sustava (engl. computations). Dokaz da obilježje p vrijedi tijekom svih ponašanja sustava: Konstruiraj sva stanja dosezljiva iz početnih. Provjeri da svako stanje zadovoljava obilježje p. Temeljni problem: izračun svih dosezljivih stanja (“reachability analysis”) Simbolički postupci: predstavljanje skupova, relacija (funkcija) s logičkim funkcijama, a ove sa BDD. Danas postignuto: sustavi sa ~ 10500 stanja

  27. 2007 Turing Award Winners Announced for their groundbreaking work on Model Checking Edmund M. Clarke, E. Allen Emerson, and Joseph Sifakis are the recipients of the 2007 A.M. Turing Award for their work on an automated method for finding design errors in computer hardware and software. The method, called Model Checking, is the most widely used technique for detecting and diagnosing errors in complex hardware and software design. It has helped to improve the reliability of complex computer chips, systems and networks.

  28. FV u praksi: Poluvodička industrija (ASICS i drugi sklopovi visoke integracije): formiranje istraživačkih i razvojnih odjela, uvođenje FV Komunikacijski protokoli često su formalno verificirani Sigurnosno-kritični sustavi uskoro će se zahtijevati FV Programsko inženjerstvo slabo prihvaćanje FV tehnika ??

  29. Zašto postupci FV nisu široko prihvaćeni Ne uči se na sveučilištima. ;-) Usredotočenost na ulazno/izlazne scenarije. Tradicija ( nedovoljno matematike u računarstvu ). “Formalisti” su također krivi jer: Mnogi nemaju iskustva na stvarnim sustavima. Reklamiraju i ono što se sa FV ne može postići. Često se ekstrapolira (“silver bullets” traže vrijeme).

  30. CrossTalk, The Journal of Defense Software Engineering January, 2008 Computer Science Education: Where Are the Software Engineers of Tomorrow? Computer science professors at New York University, say that today's computer science graduates are not equipped with the skills they need to work well in the current software industry, leading to the conclusion that "we are training easily replaceable professionals." They recommend an approach to CS education characterized by the earlier introduction of formal methods such as model checking.

  31. Spas u formalnim metodama (FM) (US Computer Science and Technology Board) FM trebaju biti ključna inženjerska vještina u računarstvu koja povećava kakvoću produkta Iistodobno smanjuje vrijeme stavljanja produkta na tržište (“time to market”), te se mora uključiti u izobrazbu CS i EE. Treba razlikovati matematičke osnovice (teorija domena, teoriju čvrste točke, propozicijska i predikatna logika, teorija automata, teorija grafova i sl.) od formalnih postupaka ( Z metoda, provjera modela, funkcijsko programiranje i sl.).

  32. FM džungla ACL2, ACP, ASR, Action Semantics, Argos, ASM, ADLT, BDDs, B, Boyer-Moore, Caesar/Aldebaran, CCS, Circal, COLD, Coq, COSPAN, CSP, FDR2, CWB, DisCo, DC, Estelle, EVES, GIL, HOL, HyTech, IMPS, I/O Automata, ITL, Isabelle, JAPE, KIV, Kronos, LAMBDA, LARCH, LeanTaP, LEGO, LOTOS, Lustre, MALPAS, Meije, Mizar, CRL, Murphi, NP-tools, Nqthm, Nuprl, Obj, Otter, Petri Nets, PI-calculus, Pobl, ProofPower, PVS, RAISE, Rapide, Refinement Calculus, SDL, SGM, Signal, SMV, SPARK, SPIN, Step, TAM, TAM97, Temporal-Rover, TLA, TPS, TRIO, TTM/RTTL, Unity, Uppaal, VeriSoft, VDM, VIS, Z, …

  33. Gdje smo u evoluciji formalnih postupaka oblikovanja Semantika ima dobru teoretsku osnovicu ali slabu primjenu. Postupci oblikovanja sustava imaju dobru primjenu ali slabu teoretsku osnovicu. Budući ključni rad: razumjeti, razvijati i uspoređivati različite računalne modele (“models of computation”)

More Related