Odjel za matematiku FORMALNA SPECIFIKACIJA Softversko inženjerstvo Dragana Ostopanj
1. Formalna specifikacija U posljednjih 30 godina veliki broj istraživača podržao je korištenje formalnih metoda u razvoju softverskih produkta. Formalne metode razvoju softvera pristupaju s matematičke strane. Time se omogućuje formalna analiza modela te se takvi modeli koriste kao podloga formalne specifikacije sustava. Formalna metoda pogoduje dokazivanju konzistentnosti krajnjeg produkta s modelom eliminirajući pogreške u softveru nastale implementacijom. Formalni razvoj započinje formalnim modelom sustava. Kako bismo kreirali takav model potrebno je zahtjeve korisnika koji su dani običnim jezikom, dijagramima i tablicama prevesti u matematički jezik koji ima svoju formalno definiranu semantiku. Bitno je naglasiti da je formalna specifikacija nedvosmisleni opis onoga što bi sustav trebao raditi. Formalna specifikacija nije osnova samo za verifikaciju dizajna i implementacije softvera već je to najprecizniji način specifikacije sustava te smanjenja nesporazuma između zahtjeva klijenta i stručnjaka koji grade sami sustav. Također, preciznom analizom moguće je otkriti i neke probleme u zahtjevima koji nastaju zbog nepreciznosti običnog jezika kojeg koristimo. Slika 1. prikazuje faze specifikacije softvera te njegovo sučelje s dizajnom. Slika 1. Formalna specifikacija u planiranom softverskom prosecu Budući da je neisplativo kreiranje formalne specifikacije cijelog produkta često se takva metoda primjenjuje samo na kritične dijelove sustava za koje je nužno da budu precizni. Takve dijelove sustava identificiramo u arhitekturi dizajna. 2. Povijest Softverski inženjeri su 80-ih godina pretpostavljali da je razvoj softvera formalnom metodom najbolji način postizanja kvalitete softvera. Glavno pitanje softverskih inženjera bilo je vodi li stroga i detaljna analiza (osnova formalne metode) programima s manje grešaka te jesu li takvi programi bolja rješenja za potrebe korisnika. Predviđanja su bila da će se u 21. st. velik broj softvera razviti upravo formalnom metodom, no predviđanja se nisu ostvarila, a evo i nekoliko razloga zašto: 1. Uspješno softversko inženjerstvo Upotreba nekih drugih metoda softverskog inženjerstva (npr., strukturalne metode) u dizajnu i razvoju rezultirala je ostvarenjem kvalitete softvera. 2. Promjena tržišta 1980-ih je kvaliteta softvera bila glavni problem softverskog inženjerstva. Međutim, od tada, najkritičniji problem za velik broj klasa softverskog razvoja postalo je vrijeme (eng. time-to-market ), vrijeme od osmišljanja proizvoda do njegove prodaje. Kupci
su bili spremni prihvatiti i neke nedostatke proizvoda ukoliko je on u kratkom vremenskom periodu mogao doći u prodaju. Dakle, softver se morao razviti brzo što razvoju formalnom metodom nikako ne pogoduje. Dakako, kvaliteta je i dalje bitan čimbenik, no mora biti zadovoljena u kontekstu brze dostave. 3. Ograničeni opseg formalnih metoda Formalne metode nisu korisne kada su u pitanju korisnička sučelja i interakcija. Komponente korisničkih sučelja postale su sve veće i veće te se formalne metode mogu primjeniti u razvoju nekih drugih dijelova sustava. 4. Ograničena skalabilnost formalnih metoda Uspješni projekti koji su koristili ovakvu metodu razvoja koristili su ju na malim, kritičnim dijelovima sustava. Razlog tomu je što kako sustav raste, vrijeme i trud uložen u razvoj formalne specifikacije može neproporcionalno rasti. 3. Prednosti Formalna specifikacija je izvrstan način otkrivanja pogrešaka u specifikaciji, utvrđivanju točnosti sustava i predstavljanju sustava na nedvosmislen način. Organizacije koje su uložile u razvoj formalnim metodama imale su manje grešaka u sustavima bez povećanja troška. Upotreba ovakve metode može smanjiti troškove ukoliko se koristi na nekim manjim, ali kritičnim dijelovima sustava za koje je bitno da su precizni, bez grešaka. Navedimo nekoliko prednosti korištenja formalnih metoda: bolji uvid u zahtjeve, otklanjanje nesporazuma, smanjenje mogućnosti grešaka (što sve pridonosi pouzdanosti softvera) analiziranje matematičkim metodama (potpunost, konzistentnost) može služiti kao podloga za formalnu verifikaciju implementiranog sustava mogućnost animacije specifikacije u svrhu prototipiranja 4. Mane Unatoč svim gore navedenim prednostima, formalne metode ograničene su u praktičnom razvoju softvera, kako za veće sustave tako i za kritične dijelove sustava. Stoga je i malo stručnjaka koji imaju iskustva u razvoju ovakvom metodom. Razlozi za nekorištenje formalne metode su: nerazumljiva je korisnicima i menadžmentu (korisnicima je teže provjeriti ispunjava li specifikacija njihove zahtjeve) zahtjeva posebno osposobljene softverske inženjere nije pogodna za interaktivne sustave i sučelja nije skalabilna, za veće sustave količina posla postane prevelika nije kompatibilna s agilnom metodom razvoja softvera
5. Formalna specifikacija sučelja Veliki sustavi sastoje se od pod-sustava koji su u međusobnoj interakciji. Važan dio specifikacije sustava je definiranje sučelja pojedinih pod-sustava. Nakon što su ta sučelja utvrđena svaki podsustav može se dalje razvijati neovisno od drugih. Sučelje pod-sustava obično se definira kao skup apstraktnih tipova podataka, kao što je ilustrirano Slikom 2. Dakle, definiraju se podaci i operacije kojima se može pristupiti izvana. Specifikacija sučelja svodi se na specifikaciju svakog od korištenih apstraktnih tipova podataka. Slika 2. Sučelje podsustava prikazano pomoću objekata Precizne specifikacije sučelja pod-sustava su bitne developerima koji su zaduženi za implementaciju pod-sustava budući da oni moraju razviti pod-sustav koji komunicira sa servisima drugih pod-sustava prije nego su oni implementirani. Specifikacija sučelja služi developerima kako bi znali koji će se servisi koristiti u drugim pod-sustavima i kako im pristupiti. Algebarski pristup bio je prvi u definiranju takvih apstraktnih sučelja. Takav pristup u formalnoj specifikaciji definira apstraktne tipove podataka u smislu veza među operacijama nekog tipa podatka. Ovakvim pristupom bavili su se John Guttag, američki računalni znanstvenik, Fred Cohen, izumitelj programa za zaštitu od kompjuterskih virusa i Barbara Liskov, također računalna znanstvenica. Struktura specifikacije takvog objekta prikazana je Slikom 3. Slika 3. Općenita struktura algebarske specifikacije
Takva struktura sastoji se od četiri dijela: 1. Uvod koji sadrži naziv entiteta koji se specificira. Sort je naziv za skup objekata sa nekih zajedničkim svojstvima. Možemo ga poistovjetiti s tipovima u programskim jezicima. U imports dijelu deklariramo nazive nekih drugih specificiranih objekata koje ćemo koristiti. 2. Opisni dio sadrži neformalne opise operacija te čini specifikaciju razumljivijom. 3. Signature dio sadrži sintaksu sučelja. Također sadrži nazive definiranih operacija te njihovu domenu i kodomenu. 4. Aksiomski dio sadrži logiku svih operacija i time opisuje ponašanje takvog tipa podatka. Slika 4. Primjer algebarske specifikacije 6. Formalna specifikacija ponašanja Algebarske tehnike iz prethodnog odjeljka postaju vrlo nespretne ukoliko rezultat operacije ovisi o stanju objekta na kojeg se ta operacija primjenjuje. Tada je bolje koristiti formalnu specifikaciju koja se zasniva na matematičkom modelu stanja sustava. Operacije se specificiraju tako da se definira kako one mijenjaju stanje sustava. Na taj se način specificira ponašanje sustava. Najpoznatiji modelni specifikacijski jezik je Z. Specifikacija u Z-u sastoji se od malih dijelova koji se nazivaju sheme. Opći oblik ilustriran je Slikom 5.
Slika 5. Općenita struktura Z-sheme Formalne specifikacije mogu biti nerazumljive pogotovo ako su prezentirane matematičkim izrazima. Osnivači Z-a taj su problem riješili tako što su specifikaciju tretirali kao neformalan tekst nadopunjen formalnim opisom. Formalne opise sklopili su u manje, lako čitljive, dijelove koji se nazivaju sheme, a razlikuju se od neformalnoh teksta tako što su grafički istaknuti. Primjer Z-sheme je rad inzulinske pumpe. Algebarski Bazirani na modelu Sekvencijalni Podudarni Larch (1993) Lotos (1987) OBJ (1985) Z (1992) CSP (1985) B (1996) Petri Nets (1981) VMD (1980) Tablica 1. Jezici za formalnu specifikaciju 7. Sedam mitova o formalnim specifikacijama 1. Formalne metode jamče savršenstvo softvera. Činjenica je da i formalne metode mogu zakazati. Moglo bi se reći da ništa ne može postići savršenstvo. Nažalost, zagovornici formalnih metoda tvrde kako nude apsolutnu garanciju koja se ne može postići niti na bilo koji drugi način. Formalne metode kritizirane su upravo zbog njihove savršenosti. Bitno je razumijeti nedostatke formalnih metoda koji proizlaze iz dvije glavne činjenice: neke se stvari nikada ne mogu dokazati, a u onima koje mogu biti dokazane možemo učiniti greške u dokazivanju. Dokazom pokazujemo kako jedan izraz formalne metode slijedi iz drugog, no dokazom ne možemo reći da će se u stvarnom svijetu stvari odviti na tako formalan način. Također, koliko god formalni bili, možemo učiniti pogreške u dokazivanju kao što možemo pogriješiti u pisanju programa. Jedna od najbitnijih činjenica je korektnost. Testiranjem programa možemo utvrditi postojanje bugova, ali ne može utvrditi njihovu odsutnost. 2. Formalne metode služe samo dokazivanju programa. Činjenica je da formalne metode najviše služe specificiranju. Verificiranje programa je samo jedan od dijelova formalne metode i također jedan od najtežih dijelova. Za kritične sustave
verifikacija je daleko od najbitnijeg dijela formalnog razvoja. Budući da je trošak uklanjanja pogrešaka proporcionalan s napretkom razvoja bitnije je obratiti temeljitu pozornost na ranije faze softvera. 3. Formalne metode su korisne samo za specificiranje sigurnosnih kritičnih sustava. Činjenica je da formalne metode pomažu u svakom sustavu. Zapravo se formalna metoda najviše i primijenjuje u nekritičnim sustavima. Ovakav tip metode trebao bi se koristiti svugdje gdje je trošak uzrokovan pogreškama velik. Sustavi gdje je trošak pogreške velik uključuju sustave koji su kritični u nekim područjima, replicirani nekoliko puta, prerađeni u hardver te koji ovise o kvaliteti iz komercijalnih razloga. 4. Formalne metode zahtjevaju visoko obrazovane matematičare. Činjenica je da je matematika koju koriste formalne metode poprilično jednostavna i lagana. Formalna metoda ne radi se najvećim dijelom o matematičkim izrazima, već o pisanju specifikacije. Npr., u Z-shemi jedini matematički dio je dio s logikom koja govori o ponašanju pojedinog pod-sustava. Sve ostalo se zapravo temelji na pisanju specifikacije nematematičkim jezikom. Šire matematičko znanje od onog srednjoškolskog je potrebno ukoliko ćemo ići malo dalje od formalne specifikacije prema potpunom formalnom razvoju koji uključuje i matematičke dokaze. 5. Formalne metode povećavaju trošak razvoja. Činjenica je da formalne metode mogu znatno smanjiti trošak razvoja. Naravno,nećemo koristiti formalnu metodu za cijeli sustav jer bi tada trošak razvoja bio prevelik, ali korištenjem ovakve metode u nekim manjim pod-sustavima možemo znatno smanjiti cijenu. Teško je usporediti razvoj softvera koristeći formalne i neformalne metode. Međutim, iskustva pokazuju da je količina projekata koji koriste formalne specifikacije počela rasti što doprinosi činjenici o smanjenju troška. Npr., Rolls-Royce and Associates izvijestili su kako im je korištenje formalnih specifikacija u sigurnosnim kritičnim projektima osigurala veću produktivnost. Također, rekli su kako 7% vremena projekta utrošenog na formalne specifikacije može spriječiti velike troškove na samom kraju projekta. 6. Formalne metode neprihvatljive su korisnicima. Formalne metode mogu pomoći korisnicima da shvate što dobivaju. Specifikacija sadrži sve ono što korisnik hoće prije nego je sami sustav izgrađen. No kako bismo iskoristili ovaj benefit moramo prvo učiniti specifikaciju razumljivu korisniku. Kako bismo to ostvarili bitno je izraziti specifikaciju u korisniku prirodnom jeziku, demonstrirati posljedice specifikacije i prikazati specifikaciju u stvarnom svijetu, tj., animirati ju. 7. Formalne metode ne koriste se u stvarnim softverima velikih razmjera. Činjenica je da se formalne metode koriste svakodnevno u industrijskim projektima. Evo nekolilko primjera: Proces transakcije. IBM-ov CICS (Customer Information Control System) je veliki, 20 godina star sustav transakcije. Sadrži više od pola milijuna redaka koda. IBM koristi Z za
respecificiranje ključnih CICS sučelja. Do sada, Z specifikacija sadrži više od 100 000 linija novog ili izmijenjenog koda Hardver. Primjer je SMITE (Secure Multiprocessing of Information by Type) arhitektura kompjutera čiji je kod specificiran u Z-u (neke greške floating-point jedinice otkrivene su koristeći Z) Kompajleri. Danski Datamatik Center koristi formalne metode u razvoju kompajlera. Kontrola nuklearnih reaktora. Rolls-Royce and Associates specificirali su softver za kontrolu nuklearnih reaktora kombinirajući engleski jezik i formalne specifikacije.
8. Zaključak Formalne metode ne daju nam magična rješenja i garancije točnosti, ali mogu biti vrlo efektivne u nekim manjim dijelovima sustava. Kako bismo ih mogli uspješno koristiti potrebni su nam developeri koji će u cjelosti razumijeti formalne specifikacije. Snažan su alat koji može pronaći greške u predrazvojnoj fazi te na taj način spriječiti velike troškove koji bi se pojavili ukoliko bismo neke propuste morali rješavati na kraju samog projekta. Jednim dijelom baziraju se na matematičkim terminima i logici stoga su potrebni i developeri toga tipa. Također, vidjeli smo u prethodnom poglavlju da su uspješno korištene u nekim većim industrijskim projektima. Stoga, mogu se koristiti u manjim kritičnim pod-sustavima, no imaju primjenu i u softverima velikih razmjera.
Literatura: 1. R. Manger: Softversko inženjerstvo, skripta, Prvo izdanje, PMF Zagreb, rujan 2005., link: http://ttl.masfak.ni.ac.rs/suk/softversko%20inzenjestvo.pdf 2. I. Sommerville: Formal Specification, Chapter 27, 2009, link: https://ifs.host.cs.standrews.ac.uk/books/se9/webchapters/pdf/ch_27_formal_spec.pdf 3. I. Sommerville: Software engineering, 9th edition, Pearson Education, 2009. 4. A. Hall: Seven Myths of Formal Methods, IEEE Software, rujan 1990, link: http://www.cs.um.edu.mt/gordon.pace/teaching/formalmethods/2006papers/sevenmyths. pdf 5. Formal specification, Wikipedia, link: https://en.wikipedia.org/wiki/formal_specification