NEMFORMÁLIS KÖVETELMÉNYEK ÁTALAKÍTÁSA FORMÁLIS SPECIFIKÁCIÓKKÁ Németh Gábor.

Az előadások a következő témára: "NEMFORMÁLIS KÖVETELMÉNYEK ÁTALAKÍTÁSA FORMÁLIS SPECIFIKÁCIÓKKÁ Németh Gábor."— Előadás másolata:

1 NEMFORMÁLIS KÖVETELMÉNYEK ÁTALAKÍTÁSA FORMÁLIS SPECIFIKÁCIÓKKÁ Németh Gábor

2 2001Németh Gábor: Számítógép architektúrák 2 ELOSZTOTT RENDSZEREK TERVEZÉSE SYSTEM: never ready; if ready: doesn’t work; if works: doesn’t do what I want; if does what I want: I am wrong.

3 2001Németh Gábor: Számítógép architektúrák 3 ELOSZTOTT RENDSZEREK TERVEZÉSE - 2 RENDSZERTERVEZÉSI LÉPÉSEK: 1.Meg kell határozni az ELŐFELTEVÉSEKet (rend- szerre vonatkozó korlátozások; a rendszernek csak ezen feltételek mellett kell helyesen működnie). 2.SPECIFIKÁCIÓK megadása (a rendszer helyes működésének kritériumai). 3.Elő kell állítani a rendszer MODELLjét (az algoritmikus megoldást). 4. A megoldás helyességét formálisan BIZONYÍTANI KELL (az előfeltevések és a specifikációk alapján).

4 2001Németh Gábor: Számítógép architektúrák 4 ELOSZTOTT RENDSZEREK TERVEZÉSE - 3 Az ellenőrző vizsgálat nagy rendszerek esetén túl hosszú időt igényel (vagy nem is lehet teljes). A szükséges javítások érdekében külön kell választani a logikai megoldás hibáit (az algoritmikus hibákat) és a megvalósítási hibákat. A logikai megoldás hibái a tervezési modell formális bizonyításával deríthetők ki. Az ellenőrző vizsgálat most már csak a logikailag helyes megoldás megvalósításának helyességét kell, hogy ellenőrizze.

5 2001Németh Gábor: Számítógép architektúrák 5 ELOSZTOTT RENDSZEREK TERVEZÉSE - 4 A felhasználó szemszögéből a rendszer egy fekete doboz (entitás), mely környezetével egy porton keresztül kommunikál. KÖRNYEZET RENDSZER PORT üzenetek

6 2001Németh Gábor: Számítógép architektúrák 6 ELOSZTOTT RENDSZEREK TERVEZÉSE - 5  A gyakorlatban célszerű finomítani a modellt, mert  A tervezés során a rendszert egymással kommunikáló alrendszerekké particionáljuk (entity-relationship model), így a kezdeti és a későbbi részletezési szintek eltérőek lennének.  Egy tervezési problémánál a környezet eseményeinek csak egy részhalmazát tekintjük.  A környezetet is egy entitásnak tekintjük, portja a rendszer felé eseményeinek csak egy részét teszi láthatóvá.

7 2001Németh Gábor: Számítógép architektúrák 7 ELOSZTOTT RENDSZEREK TERVEZÉSE - 6 KÖRNYEZET RENDSZER PORT Következmény: a rendszer specifikációit a rendszer által megfigyelhető eseményekre kell alapozni!

8 2001Németh Gábor: Számítógép architektúrák 8 ELOSZTOTT RENDSZEREK TERVEZÉSE - 7 Kezdetben a megoldandó feladat nemformális, nemteljes és ellentmondásokat tartalmazó megfogalmazása áll rendelkezésünkre. Létre kell hozni a formális, teljes és ellentmondásmentes specifikációkat.  Célunk egy nemlétező fekete macska megfogása egy sötét szobában.  Oka: minden formális módszer a valóság valamilyen szempontú közelítése.

9 2001Németh Gábor: Számítógép architektúrák 9 ELOSZTOTT RENDSZEREK TERVEZÉSE - 8 ”Elég jó” formális specifikációs módszert kell választani. (Nincs legjobb.) Két fő csoport:  modell-alapú és  absztrakt (algebrai) specifikációs módszerek.

10 2001Németh Gábor: Számítógép architektúrák 10 ELOSZTOTT RENDSZEREK TERVEZÉSE - 9 A nemformális - formális leírások közötti rés mértékéről a tervezendő rendszer viselkedése ad felvilágosítást. A viselkedés szimulációja azonban nagy rendszerek esetén nem célszerű a tervezés ezen fázisában:  Csak a már megtervezett rendszer szimulálható (a problémák csak hosszú idő múlva derülnek ki).  A szimulációs csomag is nagy lesz; saját hibákkal.

11 2001Németh Gábor: Számítógép architektúrák 11 ELOSZTOTT RENDSZEREK TERVEZÉSE - 10  A szoftver tervezésben népszerű ”vízesés” eljárás a tervezett rendszer viselkedését csak a legutolsó lépésben (későn)adja meg.  Célszerű egy NAGYON EGYSZERŰ NYELV létrehozása (mely elég egyszerű ahhoz, hogy elkerüljük a használatából eredő hibákat), mely lehetővé teszi az e nyelven írt SPECIFIKÁCIÓK KÖZVETLEN VÉGREHAJTÁSÁt.

12 2001Németh Gábor: Számítógép architektúrák 12 ELOSZTOTT RENDSZEREK TERVEZÉSE - 11 1. LÉPÉS:a nemformális, nemteljes és ellentmondásos specifikációkat formális, nemteljes és ellentmondásos specifikációkká alakítjuk át.  A nemformális - formális transzformációra egy nagyon egyszerű deklaratív nyelvet választunk.  A formális specifikáció a valós világnak kell megfeleljen, nem pedig annak (nagyon bonyolult) természetes nyelvű leírásának!

13 2001Németh Gábor: Számítógép architektúrák 13 ELOSZTOTT RENDSZEREK TERVEZÉSE - 12 Következéskép, nincs értelme a természetes nyelvű leírást nagyon megközelíteni (ellentétben sok programozó álmával), ami a rendszertervezés kezdetén maga is csak egy bizonytalan kívánság közelítése.  A hangsúlyt a koncepciók és hatásuk könnyű és félreérthetetlen értelmezésére helyezzük.

14 2001Németh Gábor: Számítógép architektúrák 14 ELOSZTOTT RENDSZEREK TERVEZÉSE - 13  PÉLDA: szoftver tervezés.  (Egy természetes nyelven megfogalmazott feladatot egy másik nyelven, pl. C nyelven kívánjuk megoldani.)  Jóslat Andreas Rudigeriusnak: ”arare rus Dei dignus” (latin anagramma; magyarul kb.: méltó vagy az Úr kertjének művelésére.)  Próbáljuk meg a feladatot német nyelven értelmezni (pap vagy orvos, a Gottesäcker egyben a temető szinonímája is!).  (Orvos lett, akik általában szorgosan megtöltik a temetőket.)

15 2001Németh Gábor: Számítógép architektúrák 15 ELOSZTOTT RENDSZEREK TERVEZÉSE - 14  A nyelvi szerkezet feleljen meg a feladat viselkedési szerkezetének.  Egzisztenciálisan kvantifikált elsőrendű logikán alapuló deklaratív nyelv kívánatos.  PÉLDA: status (Processor, ok)  (A processor objektum osztályból van néhány olyan Processor entitás, melynek állapota ok.)  PÉLDA: not status (Processor, ok)  (A processzor objektum osztályban nincs olyan Processor entitás, melynek állapota ok.)

16 2001Németh Gábor: Számítógép architektúrák 16 ELOSZTOTT RENDSZEREK TERVEZÉSE - 15 2. LÉPÉS:a formális, de még nemteljes és ellentmondá- sos specifikációkat alakítsuk át formális és teljes, de még ellentmondásos specifikációkká.  Ehhez felhasználói beavatkozás kell.  Interaktív rendszer. (Ki kell választani egyetlen eseményt a jelen- leg végrehajthatók közül, mert ebben a terve- zési fázisban még nincs összefüggő végrehaj- tási gráf.)  Elő- és utófeltételekre alapozott esemény szabályokat használunk. (Meghatározzák, hogy az esemény mikor lép- het fel és fellépésének mi lesz az eredménye.)

17 2001Németh Gábor: Számítógép architektúrák 17 ELOSZTOTT RENDSZEREK TERVEZÉSE - 16 3. LÉPÉS: az ellentmodásokat feloldjuk.  Az ellentmondások megtalálásához és feloldásá- hoz a modell feltétel nélküli eldönthetőségét és végrehajthatóságát biztosítani kell. (Ellenkező esetben a hiányok és az ellentmondások megakadályozhatnák a rendszer bizonyos részeinek felderítését.)  Ez megnehezíti az absztrakt specifikációk leírását. (Ezek definíció szerint nem végrehajthatóak.)

18 2001Németh Gábor: Számítógép architektúrák 18 ELOSZTOTT RENDSZEREK TERVEZÉSE - 17  A rendszertervezés ÖSSZETÉTELen alapul. A rendszer modelljét pontosan definiált és kipróbált részekkel bővítjük:  A rendszertervezés minden közbenső lépése JÓL DEFINIÁLT, NEMTELJES RENDSZERt ad.  A felülről-lefelé történő tervezés (”vízesés modell”) mindig teljes, de nem teljesen definiált rendszert ad. 

19 2001Németh Gábor: Számítógép architektúrák 19 ELOSZTOTT RENDSZEREK TERVEZÉSE - 18 ESEMÉNYSZINTŰ GRANULARITÁSt használunk. Az elő- és utófeltétel alapú esemény szabályok meg- felelnek a logikai órák részleges sorrendezésének.  A tervezés közbenső fázisainak nemteljessége és ellentmondásossága elméletileg lehetetlenné teszi a teljes sorrendezést. (Nem tudunk pl. real-time rendszereket vagy szorosan csatolt multiprocesszoros rendszereket modellezni.)

20 2001Németh Gábor: Számítógép architektúrák 20 ELOSZTOTT RENDSZEREK TERVEZÉSE - 19 AZ ÜZENETET OBJEKTUMNAK TEKINTJÜK (egy entitás már elküldte, a másikhoz még nem érkezett meg). A MODELL a rendszer viselkedését specifikálja, NEM FOGLALKOZIK A MEGVALÓSÍTÁSSAL. A MODELL egyszerűen formalizálja az egyenként leírt viselkedés elemeket és A FELHASZNÁLÓRA BÍZZA A MEGFELELŐ ESEMÉNY SORREND KIALAKÍTÁSÁT.

21 2001Németh Gábor: Számítógép architektúrák 21 ELOSZTOTT RENDSZEREK TERVEZÉSE - 20  AZ ALULRÓL-FELFELÉ SPECIFIKÁLÓ ELJÁRÁS NEM GARANTÁLJA A SPECIFIKÁCIÓ ELÉRHETŐSÉGÉT.  (A specifikáció elérhető, ha bármelyik érvényes állapot elérhető bármelyik érvényes állapotból a megengedett műveletek véges számú alkalmazásával.)  Az elérhetőség biztosítására felülről-lefelé formális tervezés kell.  A megvalósításhoz felülről-lefelé formális tervezés kell.

22 2001Németh Gábor: Számítógép architektúrák 22 SXL NYELV Közvetlenül végrehajtható specifikációs nyelv a nemformális - formális transzformáció elősegítésére. A nyelv előre definiált objektum osztályok (object class) konkrét objektum egyedeit kezeli.  Minden objektum a megfelelő objektum osztályra előre definiált tulajdonság halmazból tetszőleges számú tulajdonsággal (property) rendelkezik.  Egy tulajdonság értéke egy előre meghatározott tartományba (domain) kell essen. Az objektumok közötti kapcsolatokat relációkkal (fact) írjuk le.

23 2001Németh Gábor: Számítógép architektúrák 23 SXL NYELV - 2 A tervezési eljárás elején a következő koncepcionális modellünk van: KÖRNYEZET RENDSZER PORT  Ez a modell implikálja, hogy a környezet speci- fikációit a rendszer elő- feltevéseiként (korláto- zásaiként) örököljük.  Ezeket automati- kusan teljesíteni kell a rendszer formális specifiká- cióinak végrehaj- tásakor (absolute constraint).

24 2001Németh Gábor: Számítógép architektúrák 24 SXL NYELV - 3  PÉLDA: always controls (Buffer, Processor)  (Minden modell állapotban van egy buffer egység által vezérelt processor egység.) A granularitás esemény szintű, de gyakran célszerű hierarchikus leírást alkalmazni a rendszer különböző részeire.  dynamic constraint:  auto EseményNév  before ElőFeltétel  after UtóFeltétel  (Az esemény automatikusan és azonnal végrehajtódik, ha előfeltétele teljesül.)

25 2001Németh Gábor: Számítógép architektúrák 25 SXL NYELV - 4  PÉLDA: Egy több számítógépből álló feldolgozó rendszer feldolgozandó feladatokat fogad egy közös átmeneti tárolóban. Ha van egy várakozó feladat az átmeneti tárolóban, akkor egy szabad számítógép elkezdi feldolgozását. A feladat feldolgozása után az eredményt elküldjük a rendeltetési helyre. Bármelyik számítógép bármikor meghibásodhat és egy meghibásodott számítógépet bármikor kijavíthatunk és visszatehetünk a rendszerbe. Azonosítsuk az SXL elemeket, végigmenve az eredeti nemformális megfogalmazás mondatrészein.

26 2001Németh Gábor: Számítógép architektúrák 26 SXL NYELV - 5  Egy több számítógépből álló feldolgozó rendszer  objektum osztály a számítógépek számára:  object processor  feldolgozandó feladatokat fogad  esemény a feladat érkezésére:  event request_arrival  before request (, no)  after request (, yes)

27 2001Németh Gábor: Számítógép architektúrák 27 SXL NYELV - 6  egy közös átmeneti tárolóban.  objektum osztály egyetlen átmeneti tároló objektum részére:  object buffer  property request: {yes, no}.  De ekkor pótolható a hiány a feladat beérkezésének eseményénél (hova érkezik a feladat):  event request_arrival  before request (b, no)  after request (b, yes).

28 2001Németh Gábor: Számítógép architektúrák 28 SXL NYELV - 7  Ha van egy várakozó feladat az átmeneti tárolóban, akkor egy szabad számítógép elkezdi feldolgozását.  esemény a feldolgozás elkezdésére:  event processing_starts  before status (P, free)  A processor objek-  and request (b, yes) tum osztálynak  and starts (b, P) lesz egy status nevű  after status (P, busy) tulajdonsága,  and request (b, no). eddig free és busy értékekkel.  fact starts (buffer, processor). A magyar nyelvű leírásból NEM látható (nem teljes a feladat megfogalmazása)!

29 2001Németh Gábor: Számítógép architektúrák 29 SXL NYELV - 8  A feladat feldolgozása után  esemény a feldolgozás befejezésére:  event processing_terminates  before status (P, busy)  after status (P, free)  and new message (Msgid, P, destiny, result).  az eredményt  objektum osztály az eredmények számára:  object message  property sender,  receiver,  content: {result}.

30 2001Németh Gábor: Számítógép architektúrák 30 SXL NYELV - 9  elküldjük  reláció a számítógép (osztály) és az üzenet (osztály) között:  fact sends (processor, message).  a rendeltetési helyre.  objektum osztály egyetlen rendeltetési hely objektummal:  object destiny.

31 2001Németh Gábor: Számítógép architektúrák 31 SXL NYELV - 10  Bármelyik számítógép bármikor meghibásodhat  esemény egy számítógép meghibásodására:  event processor_fails  before status (P, free) or status (P, busy)  after status (P, down).  új tulajdonság érték.  és egy meghibásodott számítógépet bármikor kijavíthatunk és visszatehetünk a rendszerbe.  esemény egy számítógép kijavítására:  event processor_repaired  before status (P, down)  after status (P, free).

32 2001Németh Gábor: Számítógép architektúrák 32 SXL NYELV - 11  Meg kell adni a rendszer kezdeti állapotát.  Az interaktív végrehajtással a hiányzó specifikációk és/vagy korlátozások, illetve az ellentmondások felderíthetők és kiküszöbölhetők.