Specifikāciju valodas

LU Datorzinātņu maģistra programma

Rīga, 2010

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

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

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:

1) Tiek izveidota/iegūta precīza informācija par sistēmu (priekšmeta apgabala jēdzieni, uzdevuma formulējums, dizaina risinājumi)

2) 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)

3) 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)

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

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?

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

Tēma: specifikācijas un specifikāciju valodas

Specifikāciju valodas: ievads

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.

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

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?

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?

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!)

Tēma: formālās specifikācijas

Specifikāciju valodas: ievads

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.

Prasību formalizācijaGala 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: tR+ (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 r nozī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.

Formālo metožu izmantošanas līmeņiA. Precīza specifikācija

Specifikāciju valoda ar matemātiski precīzu sintaksi un semantiku

Izveidotā specifikācija kalpo kā garantija tam, ka prasības pret sistēmu ir precīzi

apzinātas

Specifikāciju var izmantot kā mērauklu testu rezultātiem un/vai kā avotu

sistemātiskai testu ģenerēšanai

B. Precīza specifikācija + analīze

Specifikāciju valoda ietver iespējas (piemēram, deduktīvu sistēmu) apgalvojumu

pierādīšanai

Iespējas analizēt pašas specifikācijas konsistenci, kā arī implementācijas

sasaisti ar specifikāciju (dažādus tās aspektus)

C. Precīza specifikācija + pierādīti korekta implementācija

Implementā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

Valodas dažādos formalitātes līmeņosO. 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.

Dziļākais līmenis: pierādīti korekta programmaJa 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.

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.

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.

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)

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

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

Kursa mērķis, saturs un vērtēšana

Specifikāciju valodas: ievads

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.

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

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.

Vērtēšana

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

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

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

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

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.

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ā?

Tēma: specifikācijas semantika(mazliet filosofijas..)

Specifikāciju valodas: ievads

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.

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.

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.

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 Si var 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.

Par specifikāciju un programmu semantikuSpec – 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.)