PÁRHUZAMOS ARCHITEKTÚRÁK – 4 FORMÁLIS TERVEZÉSI MODELL LÉTREHOZÁSA Németh Gábor

2015Németh Gábor: Párhuzamos architektúrák2 ELOSZTOTT RENDSZEREK TERVEZÉSE - 1 SYSTEM: never ready; if ready: doesn’t work; if works: doesn’t do what I want; if does what I want: I am wrong.

2015Németh Gábor: Párhuzamos architektúrák3 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).

2015Németh Gábor: Párhuzamos architektúrák4 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.

2015Németh Gábor: Párhuzamos architektúrák5 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

2015Németh Gábor: Párhuzamos architektúrák6 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á.

2015Németh Gábor: Párhuzamos architektúrák7 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!

2015Németh Gábor: Párhuzamos architektúrák8 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.

2015Németh Gábor: Párhuzamos architektúrák9 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.

2015Németh Gábor: Párhuzamos architektúrák10 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.

2015Németh Gábor: Párhuzamos architektúrák11 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 (a rendszer viselkedésének kiderítését).

2015Németh Gábor: Párhuzamos architektúrák12 ELOSZTOTT RENDSZEREK TERVEZÉSE 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!

2015Németh Gábor: Párhuzamos architektúrák13 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.

2015Németh Gábor: Párhuzamos architektúrák14 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.)

2015Németh Gábor: Párhuzamos architektúrák15 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.)

2015Németh Gábor: Párhuzamos architektúrák16 ELOSZTOTT RENDSZEREK TERVEZÉSE 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.  A hiányt a rendszer viselkedéséből lehet kideríteni.  Elméletileg nem lehet automatikusan kitölteni a hiányt.  Interaktív rendszer. (Ki kell választani egyetlen eseményt a jelenleg végrehajthatók közül, mert ebben a tervezési fázisban még nincs összefüggő végrehajtási gráf.)

2015Németh Gábor: Párhuzamos architektúrák17 ELOSZTOTT RENDSZEREK TERVEZÉSE - 16  Elő- és utófeltételekre alapozott esemény- szabályokat használunk. (Meghatározzák, hogy az esemény mikor léphet fel és fellépésének mi lesz az eredménye.)

2015Németh Gábor: Párhuzamos architektúrák18 ELOSZTOTT RENDSZEREK TERVEZÉSE LÉPÉS: az ellentmondá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égrehajt- ható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.)

2015Németh Gábor: Párhuzamos architektúrák19 ELOSZTOTT RENDSZEREK TERVEZÉSE - 18  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. 

2015Németh Gábor: Párhuzamos architektúrák20 ELOSZTOTT RENDSZEREK TERVEZÉSE - 19 ESEMÉNYSZINTŰ GRANULARITÁSt használunk. Az elő- és utófeltétel alapú eseményszabá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.)

2015Németh Gábor: Párhuzamos architektúrák21 ELOSZTOTT RENDSZEREK TERVEZÉSE - 20 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ÉNYSORREND KIALAKÍTÁSÁT.

2015Németh Gábor: Párhuzamos architektúrák22 ELOSZTOTT RENDSZEREK TERVEZÉSE - 21  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.

2015Németh Gábor: Párhuzamos architektúrák23 ELOSZTOTT RENDSZEREK TERVEZÉSE - 22 nemformális, nemteljes és nemkonzisztens feladatmegfogalmazás formális, teljes és ellentmondásmentes logikai modell összetétel megvalósítás tervezési modell A vízesés eljárás biztosítja a rendszer elérhetőségét.

2015Németh Gábor: Párhuzamos architektúrák24 SXL NYELV - 1 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.

2015Németh Gábor: Párhuzamos architektúrák25 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).

2015Németh Gábor: Párhuzamos architektúrák26 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.)

2015Németh Gábor: Párhuzamos architektúrák27 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.

2015Németh Gábor: Párhuzamos architektúrák28 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)

2015Németh Gábor: Párhuzamos architektúrák29 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). Csak addig kell kiírni a buffer név karaktereit, amig egyedileg azonosíthatóvá válik.

2015Németh Gábor: Párhuzamos architektúrák30 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)!

2015Németh Gábor: Párhuzamos architektúrák31 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}.

2015Németh Gábor: Párhuzamos architektúrák32 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.

2015Németh Gábor: Párhuzamos architektúrák33 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).

2015Németh Gábor: Párhuzamos architektúrák34 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.