Specifikāciju valodas

1. Specifikāciju valodas LU Datorzinātņu maģistra programma Rīga, 2010

2. Kas ir specifikācija? Intuitīvi: specifikācija = apraksts Interešu loks: datorsistēmu specifikācija (ar datoriem saistītu sistēmu specifikācija) Sistēmas specifikācija: precīzi, viennozīmīgi formulēts sistēmas īpašību apraksts. Lietojam matemātiskas, formālas metodes. Specifikācija apraksta:- sistēmas struktūru (sistēmas struktūras īpašības) un / vai - sistēmas darbību (sistēmas darbības īpašības), t.sk. darbību apkārtējās vides kontekstā – sadarbību ar ārējo vidi- sistēmas darbības kontekstu (“pasaules fragmentu”, kurā sistēma iekļaujas) Sistēma:- iecerēta, projektējama, var būt arī esoša- aparatūra vai programmatūra (vai abas kopā) Specifikācija- var būt vienošanās starp lietotāju un pakalpojuma sniedzēju- daļēja (atsevišķas īpašības) vai izsmeļoša (visas prasības, darba uzdevums kontraktā)- izmantotas dažādos līmeņos, dažādas specifikācijas vienai sistēmai

3. Specifikācijas programmatūras dzīves ciklā Dažādas specifikācijas attiecībā uz vienu sistēmu: • Priekšmeta apgabala (domēna) informācijas specifikācija; • Prasību (darbības) specifikācija, vienošanās starp gala lietotāju un sistēmas izstrādātāju • Dizaina specifikācija, ietver sistēmas arhitektūru, vienošanās starp sistēmas arhitektu un realizētāju • Moduļu (programmas) specifikācija, ietver prasības konkrētiem moduļiem, procedūrām, vienošanās starp programmētājiem, kas implementē, un kas lieto attiecīgo moduli / procedūru • Realizācija – arī “īpašību apraksts” (parasti neuzskata par specifikāciju). Specifikācijas: dažādos kontekstos, dažādos programmatūras dzīves cikla posmos (un pirms tiem ..)

4. Kāpēc specifikācijas? Precīzi fiksēt informāciju par izstrādājamo sistēmu: (sistēmas aprakstā lietotie jēdzieni, sistēmai izvirzītie uzdevumi, dizaina lēmumi sistēmas veidošanas ietvaros);izdarīt to iespējami agri sistēmas izstrādes procesā; strukturēt sistēmas izstrādes procesu. Praktisks skatījums: Iegūt programmas / sistēmas, kas “garantēti”, “droši” risina tām izvirzītos uzdevumus (garantijas un drošība nebūs absolūtas ..) Precīzas specifikācijas veidošana: • Tiek izveidota/iegūta precīza informācija par sistēmu(priekšmeta apgabala jēdzieni, uzdevuma formulējums, dizaina risinājumi) • Iespējas – specifikācijas analīze • Vai formulējums atbilst lietotāja vēlmēm (validācija) • Vai izstrādātā sistēma atbilst specifikācijai (verifikācija) • Iespējas izveidot / ģenerēt sistēmu, kas atbilst specifikācijai (sintēze) • Iespējas – programmatūras testēšanā: • Specifikācija kā mēraukla testa rezultātiem • Testa situāciju automātiska ģenerēšana no specifikācijām (var būt iespējama noteiktos kontekstos / situācijās)

5. Programmatūras kļūdas .. Radiācijas terapijas vadības sistēma, Panamas Nacionālais vēža pētījumu institūts, 2000.gads; programmas nespecificētas izmantošanas dēļ pacienti terapijas laikā saņem divkāršu radiācijas devu, vismaz 8 cilvēki miruši; Naudas transakciju apstrāde bankās (cilvēks atnāk izņemt naudu no bankomāta, naudu viņam neizdod, bet no konta summu noņem, pretenzijas netiek pieņemtas, jo viņam nav pierādījumu); Kosmisko lidaparātu vadības sistēmas – Ariane 5 owerflow kļūdas dēļ apstājas borta vadības datori, kā sekas – lidaparāts tiek “disintegrēts” – gaisā sadalīts daļās; Intel Pentium nepareizi veikta dalīšana skaitļiem ar peldošo punktu (kļūda par 0,006%) – kompānijai izmaksāja aptuveni 475 miljonus dolāru; Programmas kļūdas dēļ AT&T telefonijas komutatoros (nepareiza komutatora restartēšanās) Ņujorkas pilsēta uz 9 stundām paliek bez telefona sakariem (1990.gada 15.janvāris) Sk. “10 nopietnākās programmēšanas kļūdas cilvēces vēsturē”. Kļūdu novēršana ir dārga, bet arī kļūdu esamība ne vienmēr ir lēta. Svarīgi – noteikt pareizo balansu – cik lielus līdzekļus ieguldīt programmatūras drošībā.

6. Jautājumi refleksijai • Jūsu pieredze ar specifikāciju izmantošanu ... • Vai ir kādas situācijās / veidi, kur un kā Jūsuprāt specifikācijas varētu tikt izmantotas? • Kāda nozīme ir specifikācijas precizitātei?

7. Precīzu specifikāciju veidošana • Interesanta un nozīmīga pasaules izpratnes tēma: dažādas valodas un līdzekļi, kā precīzi: • fiksēt zināšanas, kas saistās ar programmas/sistēmas struktūru un/vai darbību • formulēt uzdevumus programmatūras sistēmu un to komponenšu, kā arī algoritmu un atsevišķu programmu izstrādei • aprakstīt algoritmu un programmu īpašības • Var būt praktiska nozīme .. • Ir labi zināt principus, kā to veikt, lai varētu piemērotā situācijā izmantot tiešā vai adaptētā veidā ..

8. Tēma: specifikācijas un specifikāciju valodas Specifikāciju valodas: ievads

9. Specifikāciju īpašības (sagaidāmās) Dažas īpašības, kas bieži tiek sagaidītas no specifikācijām: (īpašības var būt un var nebūt spēkā, var būt un var nebūt prasītas konkrētos gadījumos): • Lasāmība, • Precizitāte (priekš cilvēka, formāli precīza), • Būtisko sistēmas īpašību atspoguļojums, • Validācijas iespēja klienta klātbūtnē (specifikācijas izpildāmība), • Tipu korektība un konsistence (nav sintakses kļūdu un iekšēju loģisku pretrunu), • Implementācijas eksistence (realizējamība), • Formālas analīzes iespēja attiecībā uz noteiktām lietotājam būtiskām īpašībām, formālas verifikācijas iespēja (svarīgi noteikt, vai noteiktas īpašības ir sekas no prasībām, kā arī to, vai prasības ir interpretētas korekti dizaina un programmu izstrādē) • Augsts abstrakcijas līmenis: vai modelis (specifikācija) veidots agri sistēmas izstrādes procesā, kad daudzi dizaina un implementācijas jautājumi vēl nav risināti.

10. Specifikāciju valodu veidi Specifikāciju valoda: jēdzienu, konstrukciju sistēma specifikāciju veidošanai Valoda, kurā veidot precīzus sistēmu īpašību aprakstus. Dažādas programmēšanas valodas: C++, JAVA, PHP, Basic, Prolog, LISP, ML, u.c. Specifikāciju valodas: vēl lielāka dažādība: • dažādas pieejas specifikācijai (dažādas “paradigmas”) • dažāda rakstura specificējamie objekti (struktūra, funkcionalitāte, u.c.) Specifikācijas dažāda veida valodās: • dabiskā valodā (latviešu, angļu, japāņu, utt.) • formalizētās notācijās (izmanto diagrammas, shēmas, utt.) • formālas specifikācijas – matemātiski precīzi definēta konstrukciju sintakse un semantika Pamatā aplūkosim formālas specifikācijas, valodas to veidošanai Dabiskā valoda: nav pietiekama precizitāte (parasti).

11. Specifikāciju valodu raksturojumi [AP98, u.c.] Dažas prasības attiecībā uz specifikāciju valodām(var būt un var nebūt spēkā konkrētām specifikāciju valodām): Formalitāte – valodas konstrukcijām ir skaidra sintakse un formāla semantika. Abstrakcija – valodas spēja definēt un apstrādāt datus loģiskā līmenī, neatkarīgi no to reprezentācijas. Modularitāte – konstrukcijas specifikācijas paplašināšanai, izmantojot bagātināšanu un kompozīciju. Modelēšana – valoda piedāvā modeli sistēmas objektu un to sadarbības aprakstam. Nedeterminitāte – valoda piedāvā nedeterminētas konstrukcijas netiešai pieejai datiem un brīvai darbību izvēlei no saraksta. Izveduma sistēma – deduktīva metode, kas pēc sistēmas apraksta ļauj konstatēt vēl citas tās īpašības. Formāla specifikācijas un implementācijas sasaiste – verifikācijas, detalizācijas un/vai sintēzes iespējamība. Temporālie aspekti – laika specifikācija un tā saistīšana ar sistēmas objektu darbību. Kādas no šīm īpašībām piemīt programmēšanas valodām?

12. Dabiskās un formālās valodas specifikācijā Specifikāciju valoda – konstrukciju sistēma specifikāciju veidošanai Dabiskā valoda - ? Nav precizitātes, daudz “trokšņa”: • viens un tas pats jēdziens dažādās vietās izteikts dažādi (sevišķi ja jēdzienu jālieto daudzkārt nelielā teksta fragmentā) Programmas ieejā tiek padotas divas netukšas simbolu virknes, un izejā programma izdod virkni, kas satur vismaz vienu simbolu. • var būt lietas, kas rakstītājam var šķist skaidras bez rakstīšanas, vai arī, kuras uzrakstīt tiek aizmirsts • “notikums a notiek pēc notikuma b” – gan “notiek”, gan “pēc” var tikt interpretēts vairāk, nekā vienā veidā. “notiek” – vai laikā momentāni, vai, iespējams, ilglaicīgi? “pēc” – vai a sākums ir pēc b beigām, vai arī pietiek ar to, ka a sākums ir pēc b sākuma, un a beigas pēc b beigām?

13. Diagrammas kā specifikāciju valoda Specifikāciju valoda – konstrukciju sistēma specifikāciju veidošanai Dabiskā valoda - Nav precizitātes, daudz “trokšņa”: Shematiskas diagrammas – var palīdzēt labāk strukturēt specifikāciju Tomēr: arī diagrammai nav pašai par sevi precīzas semantikas (nozīmes), ja to nepapildina precīzas anotācijas UML klašu diagrammas – ļauj labi aprakstīt strukturētu priekšstatu par pasauli, semantika skaidrota dabiskā valodā, ir lietas, kas nav līdz galam pateiktas; semantikas formalizācija iespējama dažādos veidos Formālas specifikāciju valodas: matemātiski precīzi definēta konstrukciju sintakse un semantika (tas neatbrīvo no nepieciešamības konstrukcijām būt saprotamām!)

14. Tēma: formālās specifikācijas Specifikāciju valodas: ievads

15. Formālās specifikācijas Formāls – balstās uz formu. Matemātiski precīzi definēts. Sinonīmi: formāls – precīzs. Formālā loģika: noskaidrot izteikuma patiesumu, balstoties uz tā formu. Piemēram, A  A ir patiess, neatkarīgi no tā, kāds ir A “saturs”.Formāls izvedums no aksiomām. Iespējams pārbaudīt uz datora.Matemātiskā loģika: spriedumi tiek veidoti formāli.Programmas izpilde: simbolu manipulācija – formāla aktivitāte. Filosofiski pretstati: forma – saturs. Formāla, precīza specifikācija: spriedumi par specifikāciju izdarāmi aplūkojot tikai specifikācijas “formu” – uzrakstīto specifikācijas tekstu. Formālā specifikācija – visas būtiskās sistēmas īpašības ietvertas arī formāli uzrakstītajā specifikācijas tekstā. Nav “apslēptu pieņēmumu”, lietu, kuras ir skaidras “tāpat”. N.B. Specifikācijas formalitāte neatceļ prasību pēc specifikācijas lasāmības, saprotamības! Saturs = formas interpretācija. Skaidri, visai specifikāciju valodai vienoti likumi.

16. Prasību formalizācija Gala lietotāja prasības – būtībā saturiskas (lai sistēma “strādā”, noteiktā specifiskā veidā). Lai iegūtu iespēju veidot formālu specifikāciju, nepieciešams lietotāja prasības ietvert kādā formālā, matemātiskā sistēmā. Specifikāciju valodas – var piedāvāt (vairāk vai mazāk) ērtu notāciju lietotāja prasību fiksēšanai. “Saturiskā specifikācija”: Katram laika momentam t, ja tajā tiek kanālā sūtīts signāls, tad kādā laika momentā, kas ir lielāks par t, šis signāls tiks no šī kanāla saņemts. Formalizācija:tR+ (s(t)  t1>t  r(t1)) Predikātu s un r “saturiskā nozīme”: var palikt ārpus formālās sistēmas ietvariem. Būtiski, ka predikāti s un rnozīmē vienu un to pašu visas specifikācijas ietvaros. Cilvēkam, kas raksta/lasa šo specifikāciju, s un r nozīme būs svarīga. Spriedumi par specifikāciju veidojami neatkarīgi no šīs nozīmes. http://www.railwaydomain.org/ - mēģinājums formalizēt veselu nozari.

17. Formālo metožu izmantošanas līmeņi • Precīza specifikācijaSpecifikāciju valoda ar matemātiski precīzu sintaksi un semantikuIzveidotā specifikācija kalpo kā garantija tam, ka prasības pret sistēmu ir precīzi apzinātasSpecifikāciju var izmantot kā mērauklu testu rezultātiem un/vai kā avotu sistemātiskai testu ģenerēšanai • Precīza specifikācija + analīzeSpecifikāciju valoda ietver iespējas (piemēram, deduktīvu sistēmu) apgalvojumu pierādīšanaiIespējas analizēt pašas specifikācijas konsistenci, kā arī implementācijas sasaisti ar specifikāciju (dažādus tās aspektus) • Precīza specifikācija + pierādīti korekta implementācijaImplementāciju un specifikāciju sasaiste vienotā semantiskā ietvarāSistemātiskas metodes implementācijas korektības pierādīšanai vai implementācijas sintēzei vai specifikācijas detalizācijai par implementāciju Praktiski lietojumi bieži var apstāties A līmenī, varbūt ietverot nedaudz no B. B un C līmeņos praktiskos lietojumos nepieciešams rīku atbalsts

18. Valodas dažādos formalitātes līmeņos O. Diagrammu notācija OO modelēšanai, UML – daļēji formālas valodas(kā ir ar UML klašu diagrammu formālo semantiku ?) A./B. Z, VDM, Larch, OBJ u.c. – specifikāciju valodas ar matemātiski precīzu sintaksi un semantiku, pieejami arī atsevišķi atbalsta rīki sintakses pārbaudei, semantiskajai analīzei un pierādījumu veikšanai C. HOL, PVS, EVES, u.c. – atbalsts formālu specifikāciju veidošanai, iespējams veikt stingru semantisku analīzi un sistemātiskus mehāniski verificētus pierādījumus Formalitātes līmeņa izvēle – atkarībā no projekta mērķiem, drošības nozīmīguma, projekta apjoma, pieejamajiem resursiem. Kursā – koncentrēsimies uz “Z, VDM, Larch, OBJ” līmeni – specifikāciju valodas ar matemātiski precīzu sintaksi un semantiku, atsevišķām pierādījuma iespējām. Iespēju robežās aplūkosim arī detalizācijas pieeju.

19. Dziļākais līmenis: pierādīti korekta programma Ja mērķis ir – iegūt programmatūras sistēmu un tās korektības pierādījumu(sistēmai ar ļoti augstām drošības prasībām) [ne vienmēr tas tiks prasīts]: 3 elementi: (A) Specifikācija, (B) Programma, (C) Pierādījums Kādā secībā veidot (A), (B) un (C)? 1. pieeja: Sākam ar specifikāciju (A), pēc tam (B), tad (C) [+ veidojot (B) un (C) var būt nepieciešamība atgriezties pie (A) precizēšanas] 2.pieeja:Sākam ar specifikāciju (A), pēc tam (B) un (C) paralēli kā atsevišķas aktivitātes [+ ...] 3. pieeja:Sākam ar specifikāciju (A), pēc tam integrēta (B) un (C) izstrāde [+ ...] (tiek uzskatīta par optimālo, nepieciešamība veikt pierādījumu var ietekmēt veidu, kā programmas tiek rakstītas). Specifikācijas detalizācija par implementāciju: atbilst (3.) pieejai, (B) un (C) integrācija pēc būtības (detalizācijas ietvaros nav iespējams izveidot (B), neizveidojot (C)) P.S. Var būt iespējamas situācijas, kad formāla, precīza specifikācija tiek veidota visai sistēmai, bet pierādījumi tiek veikti tikai atsevišķām komponentēm. P.S.2. Ja programmas korektība tiek pierādīta, tas vēl nenozīmē, ka programma tiešām ir pareiza – paliek jautājums arī par to, vai specifikācija ir pareiza un pilnīga. 

20. Programmas komponenšu korektība Pastāv iespējas korektības pierādījumus veikt attiecībā uz atsevišķām programmas koda komponentēm arī sistēmām ar mazāk kritiskām drošības prasībām: • Nozīmīga sistēmas komponente • Atsevišķas komponentes verifikācija var būt ievērojami lētāka par visas sistēmas verifikāciju. Kursā aplūkotās specifikācijas un analīzes metodes būs izmantojamas arī atsevišķu programmas fragmentu īpašību aprakstam un analīzei.

21. Formāla specifikācija un verifikācija praksē NASA, 1995, citēts pēc [AP98]: Formāla verifikācija ir veikta programmām līdz 10 KSLOC Dizaina līmeņa specifikācija un verifikācija ir veikta apakšsistēmām starp 10 KSLOC un 100 KSLOC Formāla prasību specifikācija ir mēģināta arī sistēmām, kas izstrādes laikā ir izaugušas arī virs 100 KSLOC KSLOC (Kilo Source Lines of Code) “Vidējas sarežģītības” sistēmas.

22. Formāla specifikācija un verifikācija praksē NASA: formālas metodes nevar tikt pilnībā pielietotas lielām sistēmām, kas veidotas, izmantojot “parastās” programmēšanas metodes. Lai baudītu formālo metožu augļus lielu sistēmu izstrādē, sistēmām jābūt labi strukturētām, sadalāmām skaidri definētās komponentēs. Tikai viskritiskākās no tām ir pakļaujamas formālajām metodēm. Lielāks ieguvums ir tad, ja formālos spriedumus par atsevišķām sistēmas komponentēm var kombinēt, tādējādi iegūstot slēdzienus par visas sistēmas uzvedību (“kompozicionalitātes” princips)

23. Specifikāciju valodu pārskats Orientētas uz sistēmas īpašībām • Algebriskās: ACT ONE, OBJ3, COLD-K, CASL, ASM • Aksiomātiskās: Larch (augšējais līmenis), temporālās loģikas, HOL, PVS, (paralēlo procesu algebras, LOTOS) • (Funkcionālās programmēšanas valodas) Orientētas uz sistēmas modeli: Z, VDM, B, RAISE, Larch (otrais līmenis) Sistēmas modelis tiek veidots no “zināmiem” matemātiskiem objektiem – kopas, attiecības, virknes, utt. Operācijas specificētas sākuma un beigu nosacījumu terminos. Orientētas uz stāvokļu pārejām: Petri tīkli, Statecharts, paralēlo procesu algebras, LOTOS

24. Formālās specifikāciju valodas: mazliet cita klasifikācija “Modeļbāzētas” – valoda ļauj konstruēt specificējamās sistēmas matemātisko modeli, tipiski aprakstot sistēmas stāvokļus un iespējamās operācijas (VDM-SL, Z, B). Matemātiskais pamats – kopu teorija. “Ekvacionālas” – datu struktūru specifikācija, izmantojot vienādības. Algebriskās specifikācijas: ACT ONE, COLD-K, OBJ. Loģiskās ekvacionālās specifikācijas: Larch.Matemātiskais pamats – abstraktā algebra, kategoriju teorija. Uz procesiem balstītas: process kā primitīvs paralēlu un reaktīvu sistēmu darbības aprakstam. CCS, CSP, LOTOS. Valodas darbību secības atspoguļošanai. Temporālās loģikas.(Matemātiskais pamats – procesu modelis, automātu teorija, algebra) Loģiskas: pirmās kārtas predikātu loģika, augstākas kārtas predikātu loģika (HOL sistēma, u.c.), tipu teorijas (sk. NUPRL sistēma, u.c.).Matemātiskais pamats – matemātiskā loģika (1.kārtas, augstākas kārtas) Salīdzināt: http://www.rbjones.com/rbjpub/cs/csfm02.htm

25. Kursa mērķis, saturs un vērtēšana Specifikāciju valodas: ievads

26. Specifikāciju valodas: kursa mērķis Kursa mērķis: iepazīstināt ar plašāk lietotajām formālajām specifikāciju valodām, kā arī ar specifikāciju analīzes iespējām uz to bāzes. Kursa pamata akcents ir uz specifikāciju valodām - Z, VDM (modeļbāzētas spec. valodas) un - OBJ (algebriska spec. valoda), - atsevišķi aplūkotas procedūru (operāciju) sākuma/beigu specifikācijas, - kā arī sniegts pārskats par virkni citām dažāda veida specifikāciju valodām. Kurss sniedz pamata zināšanas, lai students varētu lasīt, saprast un rakstīt specifikācijas valodās Z, VDM un OBJ.

27. Precīzu specifikāciju veidošana • Interesanta un nozīmīga pasaules izpratnes tēma: dažādas valodas un līdzekļi, kā precīzi: • fiksēt zināšanas, kas saistās ar programmas/sistēmas struktūru un/vai darbību • formulēt uzdevumus programmatūras sistēmu un to komponenšu, kā arī algoritmu un atsevišķu programmu izstrādei • aprakstīt algoritmu un programmu īpašības • Var būt praktiska nozīme .. • Ir labi zināt principus, kā to veikt, lai varētu piemērotā situācijā izmantot tiešā vai adaptētā veidā ..

28. Plānotās kursa tēmas 1. Specifikācijas jēdziens, specifikāciju veidi. Formālas specifikācijas, to raksturojumi un izmantošana programmatūras dzīves ciklā. 2. Procedūru sākuma un beigu specifikācijas loģiskā formā. Daļējā un pilnā korektība. 3. Atbilstības specifikācijai konstatēšana: Hoara loģika, cikla invarianti, cikla varianti. 4. Specifikāciju valodas Z pamati. Programmatūras sistēmu specifikācija valodā Z. 5. Modeļbāzētās specifikāciju valodas Object Z, B, Event B. 6. Specifikāciju valodas VDM un VDM++. Sistēmu izstrāde, izmantojot VDM++. 7. Algebriskās specifikācijas: algebras, abstraktie datu tipi, specifikāciju īpašības. 8. Algebriskā specifikāciju valoda OBJ3. CAFE OBJ sistēma. 9. Abstrakto automātu metode sistēmu specifikācijai. 10. Paralēlu sistēmu specifikācijas pamati. 11. Valoda LOTOS notikumu temporālā sakārtojuma specifikācijai. 12. Temporālās loģikas. 13. Petri tīkli sistēmu modelēšanā. Krāsainie Petri tīkli.

29. Vērtēšana • Mājas darbi (t.sk. nelieli izstrādes projekti) atbilstoši lekcijās aplūkotām tēmām: 6 punkti. Mājas darbus jāpilda patstāvīgi un mājas darbu risinājumus jāatbild. • Apmeklējums un piedalīšanās diskusijās, un/vai refleksija forumā par lekcijās apskatītiem jautājumiem (līdz 3 punktiem, tikai apmeklējums vien netiek vērtēts). • Referāts, 15-20 minūšu uzstāšanās ar slaidiem (līdz 3 punktiem), vai 8-12 lpp teksta iesniegšana (līdz 2 punktiem). Tēma saskaņojama ar pasniedzēju. Tiks piedāvātas iespējamās ievirzes tēmām. • Eksāmens - vienkārši teorijas jautājumi un uzdevumi (3 punkti). Atzīme par kursu – saņemto punktu skaits. Ja studenta saņemto punktu kopsumma pārsniedz 9, tad atzīme par kursu ir 9 . Atzīme 10 – par izcilību (nolasīts referāts, oriģināls projekts, dalība forumā, u.c.)

30. Informatīvais atbalsts Informatīvais atbalsts: Kurss e-studiju (moodle) vidē Kursa saturs, prasības, mājas darbi, literatūras saraksts, papildmateriāli (slaidi elektroniskā formā, norādes uz tīmekļa vietnēm) Papildus: www.ltn.lv/~karlisc/stud.htm,Specifikāciju valodas E-pasts: Karlis.Cerans@mii.lu.lv (saziņai lūdzu izmantot šo). Tel. 67213716 Apmeklējumi: LU MII 421. istaba.

31. Jautājumi refleksijai • Kādas ir galvenās cerības, kas Jums saistās ar šī kursa apguvi? • Kādas ir galvenās bažas, kas Jums saistās ar šī kursa apguvi? • Par kādām tēmām un jautājumiem Jūs vēlētos, lai tie tiktu vairāk akcentēti kursā?

32. Tēma: specifikācijas semantika(mazliet filosofijas..) Specifikāciju valodas: ievads

33. Par specifikācijas semantiku ... Specifikācija – “modelis”, sistēmas īpašību apraksts. Formāla specifikācija – matemātiski precīza sintakse un semantika. Sintakse – lineāra, grafiska, … Semantika - ? Piemērs: specifikācija – automāts (automātu sistēma, SDL sistēma). Automātam – noteikti darbības likumi (pārejas starp stāvokļiem). Formāla notācija, viss matemātiski precīzi. Kādas sistēmas atbilst automātam kā specifikācijai? Vai dotā uzprogrammētā sistēma X atbilst dotajai specifikācijai A ? Automāta stāvokļu pāreju likumi neatbild uz šiem jautājumiem. Arī automātu zināmā nozīmē kādreiz uzskata par sistēmas specifikāciju, kas gan nesniedz precīzu uzdevumu tālākai sistēmas programmatūras izstrādei. Piemērotāks vārds – sistēmas modelis. P.S. Automātiem un to sistēmām ir iespējams definēt specifikācijas semantiku.

34. Specifikācijas semantika “Specifikācijas semantika”, “Specifikācijas filosofiskais modelis” “Specifikācijas semantika” specifikāciju valodai L dod formālus kritērijus, kā noteikt, kādas implementācijas atbilst katrai valodā L rakstītai specifikācijai. Spec – specifikāciju kopa, Sys – sistēmu (vai programmu) kopa Sat  Sys x Spec – atbilstības attiecība. I Sat S – implementācija (sistēma) I atbilst specifikācijai S. Ja specifikācija apraksta konkrētas prasības konkrēti veidojamai programmai, jautājumu par Sat var būt labi uzstādīt, ja tas nav a priori valodas prezentācijā atbildēts ... Vienam formālam objektam (t.sk. specifikācijai) var būt vairākas semantikas. Svarīgi, lai tās būtu saskaņotas.

35. Specifikāciju detalizācijas jēdziens “Integrēta programmas koda un tās korektības pierādījuma izstrāde”. Spec – specifikāciju kopa, Sys – sistēmu kopa, Sat  Sys x Spec – atbilstības attiecība. I Sat S – implementācija (sistēma) I atbilst specifikācijai S. Ja izveido kopu SpecPlus – paplašinātā sistēmu kopa, kurai Spec, Sys SpecPlus, un definē tajā Ref  SpecPlus x SpecPlus, ar īpašībām: - ja I  Sys un S  Spec, tad I Sat S  I Ref S, - Ref ir refleksīva un tranzitīva, tad Ref ir detalizācijas (refinement) attiecība. Ja ir pieejama attiecība Ref, tad iespējamas metodoloģijas, kas atļauj iegūt I  Sys no S  Spec, kurai I Sat S pakāpenisku transformāciju rezultātā, veidojot virkni: S = S0, S1, S2, … , Sn = I, kur Si SpecPlus uni Si+1 Ref Si.

36. Specifikāciju detalizācijas jēdziens (2) Spec – specifikāciju kopa, Sys – sistēmu kopa, Sat  Sys x Spec – atbilstības attiecība. I Sat S – implementācija (sistēma) I atbilst specifikācijai S. Ja ir pieejama attiecība Ref, tad iespējamas metodoloģijas, kas atļauj iegūt I  Sys no S  Spec, lai I Sat S pakāpenisku transformāciju rezultātā, veidojot virkni: S = S0, S1, S2, … , Sn = I, kur Si SpecPlus un i Si+1 Ref Si. Ja papildus tam detalizācijas attiecība Ref ir kompozicionāla: S Ref T  C(S) Ref C(T) noteikta veida konteksta informācijas pievienošanas operatoriem C(piemēram S|X Ref T|X),tad katru no soļiem Si+1 Ref Sivar veikt atsevišķā sistēmas komponentē. Tipiski I un S būs sintaktiski pierakstītas dažādās valodās. Attiecība Ref veidojama kā attiecība starp I un S semantiskajiem objektiem. Izstrādes rezultātā, protams, I būs jāapmierina arī citas īpašības, ne tikai I Sat S.

37. Par specifikāciju un programmu semantiku Spec – specifikāciju kopa, Sys – sistēmu (programmu) kopa. Sat  Sys x Spec – atbilstības attiecība. I Sat S – implementācija (sistēma, programma) I atbilst specifikācijai S. Spec – formāla specifikāciju valoda, ja precīzi definēta tās sintakse un atbilstības attiecība Sat. Lai Sat varētu definēt precīzi, arī Sys – programmu kopai jābūt matemātiski precīzi definētai. Specifikācija – aplūko programmu sistēmu sintaktiskās un semantiskās īpašības (kāda būs programmas darbība). Pamata akcents specifikācijā – kā programma tiks izpildīta? Programmu izpildes laika semantikai jābūt precīzi definētai. Programmēšanas valodas semantika – kā definēt dotai programmai (tekstam) šajā valodā atbilstošu matemātisku struktūru, kas raksturo programmas izpildi (struktūra – grafs, sākuma un beigu stāvokļu attiecība, u.c.)