Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

PÁRHUZAMOS ARCHITEKTÚRÁK – 7 ABSZTRAKT SPECIFIKÁCIÓ Németh Gábor.

Hasonló előadás


Az előadások a következő témára: "PÁRHUZAMOS ARCHITEKTÚRÁK – 7 ABSZTRAKT SPECIFIKÁCIÓ Németh Gábor."— Előadás másolata:

1 PÁRHUZAMOS ARCHITEKTÚRÁK – 7 ABSZTRAKT SPECIFIKÁCIÓ Németh Gábor

2 2015Németh Gábor: Párhuzamos architektúrák2 ABSZTRAKT (ALGEBRAI) SPECIFIKÁCIÓ esemény alapú absztrakt modellAz ABSZTRAKT (ALGEBRAI) SPECIFIKÁCIÓs módszernél a rendszer viselkedését egy esemény alapú absztrakt modellel specifikáljuk. általánosított ekvivalencia relációkA különféle műveletkombinációk között általánosított ekvivalencia relációkat adunk meg. adatáramlásEgy számítógéprendszer által végzett információ feldolgozást a rendszer bemenetén és kimenetén átfolyó adatáramlásként értelmezzük. ABSZTRAKT SPECIFIKÁCIÓ - 1

3 2015Németh Gábor: Párhuzamos architektúrák3 ABSZTRAKT SPECIFIKÁCIÓ - 2 process portEzen absztrakt modell szerint két alapelemet kell definiálni: a kívánt műveletet biztosító (process) és a rendszernek a környezetéhez való csatlakozását biztosító (port) elemet. PROCESS  A PROCESS egy specifikációs egységnek tekintett, valamilyen adatfeldolgozást végző entitás. PORT  A PORT egy process része, és az illető folyamatnak a környezetével való kommunikációját biztosítja.

4 2015Németh Gábor: Párhuzamos architektúrák4 ABSZTRAKT SPECIFIKÁCIÓ - 3 KÖRNYEZET PROCESS PORT  csak a kívülről látható viselkedést specifikáljuk  A process és a port tulajdonságait ab- sztrakt módon írjuk le, csak a kívülről látható (kommuni- kációs) viselkedést specifikáljuk.  A specifikáció nem tartalmazza, hogyan valósítjuk meg ezt a viselkedést. A logikai és a fizikai megoldás szétválasztásával egy entitás a rendszer többi részének módosítása nélkül kicserélhető!

5 2015Németh Gábor: Párhuzamos architektúrák5 ABSZTRAKT SPECIFIKÁCIÓ - 4 FELÜLRŐL-LEFELÉ LÉPÉSENKÉNTI FINOMÍTÁSFELÜLRŐL-LEFELÉ mozgó tervezési eljárást alkalmazunk LÉPÉSENKÉNTI FINOMÍTÁSsal.  A megoldandó problémát először egyetlen rendszerként (processként) specifikáljuk.  A következő lépés(ek)ben a rendszert egymással (portokon keresztül) kommunikáló alrendszerekre bontjuk, és í.t.  Minden részletezési szinten a korlátozásokat és a tulajdonságokat örököljük a felsőbb szintről és finomításokkal egészítjük ki.

6 2015Németh Gábor: Párhuzamos architektúrák6 ABSZTRAKT SPECIFIKÁCIÓ - 5 A P1 P2 P3  Egy process portjai az illető process környezetének absztrakt képét jelentik. A P1 P2 P3 D E P2 A P3 B C P1 a környezet lehet ilyenvagy ilyen

7 2015Németh Gábor: Párhuzamos architektúrák7 ABSZTRAKT SPECIFIKÁCIÓ - 6 PORT SPECIFIKÁCIÓJA:PORT SPECIFIKÁCIÓJA: egymásrahatás típusok  A porton felléphető egymásrahatás típusok felsorolása. korlátozások  A végrehajtott egymásrahatások sorrendezésére és paramétereire vonatkozó korlátozások megadása.  Szerep (ez a port, vagy a hozzá csatlakozó másik kezdeményezi az egymásrahatást).  Kicserélt paraméterek típusának meghatározása.  Ez a port, vagy a hozzá csatlakozó másik határozza meg a kicserélt paraméter értékét?

8 2015Németh Gábor: Párhuzamos architektúrák8 ABSZTRAKT SPECIFIKÁCIÓ - 7 A rendszert a részrendszerek megfelelő portjainak összekötésével írjuk le.  Két port összekötését a két port közötti általánosított ekvivalencia relációval határozzuk meg.  A két összekötött port szerepeinek az egymásrahatás kezdeményezésére és a paraméterek típusainak és értékeinek meghatározására vonatkozóan egymás komplemenseinek kell lenniük. Ezt formálisan ellenőrizzük!

9 2015Németh Gábor: Párhuzamos architektúrák9 ABSZTRAKT SPECIFIKÁCIÓ - 8 PROCESS SPECIFIKÁCIÓJA:PROCESS SPECIFIKÁCIÓJA: Portjainak felsorolása  Portjainak felsorolása (mert azok tulajdonságait örökli). különböző portjain fellépő egymásrahatások közötti relációk  A process különböző portjain fellépő egymásrahatások közötti relációk meghatározása. A processnek csak a kívülről látható viselkedését specifikáljuk.

10 2015Németh Gábor: Párhuzamos architektúrák10 ABSZTRAKT SPECIFIKÁCIÓ - 9  PÉLDA:Tervezzünk információs rendszert, melyben véges számú előfizető kérdéseire a rendszer válaszol.  Egy felhasználót egy user process képvisel.  A válaszokat egy server process szolgáltatja.  A user és a server együttműködéséhez a request és a response egymásrahatásokat definiáljuk.

11 2015Németh Gábor: Párhuzamos architektúrák11 ABSZTRAKT SPECIFIKÁCIÓ - 10  ELŐFELTEVÉSEK  (a legmagasabb absztrakciós szinten):  1.A rendszerben nem lép fel meghibásodás.  2.A felhasználók nem befolyásolják egymás működését.  3.Egy meghatározott kérdésre adott válasz kizárólag az illető kérdés függénye.

12 2015Németh Gábor: Párhuzamos architektúrák12 ABSZTRAKT SPECIFIKÁCIÓ - 11  SPECIFIKÁCIÓK  (a legmagasabb absztrakciós szinten):  A user és server processek megfelelő portjaikon keresztül kommunikálnak egymással. Ezek vagy azonosak, vagy kompatibilisek kell legyenek (önkényes tervezői döntés). port access is operationrequest (X: question); response (Y: answer); constraint (access/request) i  (access/response) i  (access/request) i+1 end access.

13 2015Németh Gábor: Párhuzamos architektúrák13 ABSZTRAKT SPECIFIKÁCIÓ - 12 process user is service: access end user. process server is users: array [user_identifier] of access; constraint for u in user_identifier holds (users[u]/response) i.Y = ƒ((users[u]/request) i.X end server.

14 2015Németh Gábor: Párhuzamos architektúrák14 ABSZTRAKT SPECIFIKÁCIÓ - 13  Egy rendszert alkotó processeinek és azok összeköttetéseinek felsorolásával specifikálunk. process system is S: server; U: array [user_identifier] of user; connection for u in 1..N: U[u].service = S.users[u] end system.

15 2015Németh Gábor: Párhuzamos architektúrák15 ABSZTRAKT SPECIFIKÁCIÓ - 14 A lépésenkénti finomítás illusztrálására funkcionálisan particionáljuk a server processt. 1 N multiplexer coreserver új portok  örökölt portok

16 2015Németh Gábor: Párhuzamos architektúrák16 ABSZTRAKT SPECIFIKÁCIÓ - 15 process core is user: access; constraint (user/response) i.Y = ƒ((user/request) i.X) end core. process multiplexer is single: array[user_identifier] of access; multiplexed: access; constraint for s in user_identifier holds  i  i’ ((single[s]/request) i = (multiplexed/request) i’ and (single[s]/response) i = (multiplexed/response) i’ ) end multiplexer.  önkényes tervezői döntés önkényes tervezői döntés (IMPLE- MENTÁ- CIÓ!)  A FIFO tároló a multiplexer és a core között van!

17 2015Németh Gábor: Párhuzamos architektúrák17 ABSZTRAKT SPECIFIKÁCIÓ - 16 process server is M: multiplexer; C: core; connectionM.multiplexed = C.user;  u in user_identifier: users[u] is M.single[u] end server. csak virtuális összeköttetés  (ÖRÖKLŐDÉS!) Az absztrakt tervezésnél nincs megvalósítási modellünk, így a lépésenkénti finomítás legutolsó lépésében egy megvalósítási transzformáció szükséges.

18 2015Németh Gábor: Párhuzamos architektúrák18 ABSZTRAKT SPECIFIKÁCIÓ - 17  Az orthogonális tulajdonságokat külön-külön kell specifikálni, mivel ebben az esetben teljesítésük egymástól függetlenül bizonyítható. Ez az absztrakt tervezés legnagyobb előnye, mert elkerülhető az állapot-robbanás.  (Sajnos nincs közvetlen módszer az orthogonális tulajdonságok meghatározására, csak ellenőrizhető a megadott tulajdonságok orthogonalitása.)

19 2015Németh Gábor: Párhuzamos architektúrák19 ABSZTRAKT SPECIFIKÁCIÓ - 18 particionálásA lépésenkénti finomítás konkrét lépéseit jelentősen befolyásolja a particionálás módja. A következő szempontok szerint kell particionálni: Funkcionális  Funkcionálisan (ld. előző példa) (ez a rendszer működése szempontjából érthető). Diagnosztika  Diagnosztika (meghatározza a processek között minimálisan szükséges összeköttetéseket és egymásrahatásokat). Interfész  Interfész specifikáció (maximalizálja a rendszer értékét, miközben minimalizálja költségét).

20 2015Németh Gábor: Párhuzamos architektúrák20 KITÉRŐ: DIAGNOSZTIKA - 1 Feltételezzük, hogy az erőforrások intelligensek (processzorokat tartalmaznak). Az erőforrások egymást vizsgálhatják (meghatározott üzenetet küld az egyik processzor a másiknak, melyre helyes működés esetén meghatározott választ kell kapnia, meghatározott időn belül). A diagnosztikai gráf csúcsai azon egységeknek felelnek meg, melyek önállóan képesek más egységeket vizsgálni, az irányított élek pedig a vizsgálati kapcsolatokat és szerepeket képviselik.

21 2015Németh Gábor: Párhuzamos architektúrák21 KITÉRŐ: DIAGNOSZTIKA processzor kölcsönös diagnosztikai gráfja: P1P1 P2P2 a 12 a 21 Akár jónak, akár rossznak minősítheti!  Nem lehet egyértelmű diagnosztizálást garantálni.

22 2015Németh Gábor: Párhuzamos architektúrák22 KITÉRŐ: DIAGNOSZTIKA processzor diagnosztikai gráfja: P1P1 P2P2 P3P3 a 12 a 23 a 31 1 hiba diagnosztizálható. (Ez csak P 2 hibája esetén léphet fel.)

23 2015Németh Gábor: Párhuzamos architektúrák23 KITÉRŐ: DIAGNOSZTIKA - 4 Gráfelméleti alapon belátható, hogy n processzorból álló rendszerben 1 lépésben k hiba fedhető fel, ha n  2k + 1 és K(D)  k (K(D) a diagnosztikai gráf összefüggősége [hány csomópont eltávolításával szűnik meg az erős összefüggés]; D erősen összefüggő, ha tetszőleges 2 csomópontja kölcsönösen elérhető).  VIGYÁZAT: az előző összefüggések állandósult hibákat tételeztek fel. Időszakos (tranziens) hiba esetén a vizsgálat nem teljes!

24 2015Németh Gábor: Párhuzamos architektúrák24  A diagnosztizálhatóság követelménye azt jelenti, hogy egy, a rendszer különböző részeinek diagnosztizálása szerint változó szerkezetű részgráfot félre kell tenni a hardver gráfból és csak a megmaradó rész használható felhasználói és operációs rendszer folyamatok futtatására. HOZZÁRENDELÉSI PROBLÉMA MULTIPROCESZ- SZOROS RENDSZEREKBEN: pontatlanul ismert szoftver gráf leképzése pontatlanul ismert hardver gráfra, pontatlanul ismert időzítési korlátozások mellett. KITÉRŐ: DIAGNOSZTIKA - 5

25 2015Németh Gábor: Párhuzamos architektúrák25 KITÉRŐ: DIAGNOSZTIKA - 6 hibamódokA diagnosztika tervezésének első lépése a hibamódok meghatározása. (Ha például egy számítógép rendszerben csak cserélhető kártya szintig kívánjuk a hiba helyét meghatározni, akkor egy memória kártya hibamódjai: tápfeszültséghiba, földhiba, címsínleragadás, adatsínleragadás stb.)

26 2015Németh Gábor: Párhuzamos architektúrák26 KITÉRŐ: DIAGNOSZTIKA - 7 hibaszimptómákatMeghatározzuk a hibaszimptómákat (az egyes hibamódoknak a hibaérzékelési mechanizmus által meghatározott megnyilvánulási formáit).  A hibaszimptómák száma általában lényegesen kisebb a hibamódok számánál. (Gazdaságossági és átbocsátóképességi okok miatt általában nem valósítunk meg mindenre kiterjedő ellenőrzést.)  Előfordulhat, hogy egy hibamód hatása csak közvetve jelentkezik hosszabb idő múlva (hibaterjedés)!

27 2015Németh Gábor: Párhuzamos architektúrák27 KITÉRŐ: DIAGNOSZTIKA - 8 hibamódok és a hibaszimptómák közötti kapcsolatok hatékony kezelése  Kulcskérdés a hibamódok és a hibaszimptómák közötti kapcsolatok hatékony kezelése.  Korrelációs tömb  Korrelációs tömb: a hibaszimptómák és a hibamódok közötti kapcsolat. Elemei: gyakorlati tapasztalatok, elméleti megfontolások és szimulációs eredmények alapján megközelített összetartozási valószínűségek.  Általában kiegészítő vizsgálatok szükségesek.

28 2015Németh Gábor: Párhuzamos architektúrák28 KITÉRŐ: DIAGNOSZTIKA - 9 hibamód- hibaszimptóma reláció vektor  A diagnosztika hatékonysága javítható a hibamód- hibaszimptóma reláció vektor bevezetésével.  Egy hibamód több hibaszimptómát eredményezhet. Az észlelt hibaszimptóma alapján a vektor megadja, hogy milyen további hibaszimptómák megléte szükséges egy meghatározott hibamód azonosításához. Ehhez esetleg további vizsgálatok szükségesek.  Ha ez nem vezet eredményre akkor fordulunk a korrelációs tömb további elemeihez.

29 2015Németh Gábor: Párhuzamos architektúrák29 KITÉRŐ: DIAGNOSZTIKA - 10  A diagnosztika által hibásnak talált egységet kiiktatjuk a rendszerből. hatáskörzet  A rendszerben általában több egység működik együtt, így a kiiktatásnak az ún. hatáskörzetre kell kiterjednie. dinamikusA hatáskörzet gyakran dinamikus! (Függ a hibamód fellépése és a hibaszimptóma észlelése között eltelt időtől.)  Célszerű a hibaterjedés korlátozására törekedni.

30 2015Németh Gábor: Párhuzamos architektúrák30 ABSZTRAKT SPECIFIKÁCIÓ - 19 particionálásA lépésenkénti finomítás konkrét lépéseit jelentősen befolyásolja a particionálás módja. A következő szempontok szerint kell particionálni: Funkcionális  Funkcionálisan (ez a rendszer működése szempontjából érthető). Diagnosztika  Diagnosztika (meghatározza a processek között minimálisan szükséges összeköttetéseket és egymásrahatásokat). Interfész  Interfész specifikáció (maximalizálja a rendszer értékét, miközben minimalizálja költségét). Kölcsönösen ellentmondanak egymásnak!

31 2015Németh Gábor: Párhuzamos architektúrák31 ABSZTRAKT SPECIFIKÁCIÓ - 20 INTERFÉSZ SPECIFIKÁCIÓ:INTERFÉSZ SPECIFIKÁCIÓ: KONZISZTENS A process hiányzó információi a meglévőkből megjósolhatóak.  Elnevezési, paraméterátadási stb. konvenciók.  Minden fejlesztő rendszer rendelkezik vele, sajnos az egyes eszközök konvenciói eltérőek.

32 2015Németh Gábor: Párhuzamos architektúrák32 ABSZTRAKT SPECIFIKÁCIÓ - 21  ALAPVETŐ  A szükségtelen tulajdonságokat el kell hagyni.  Ugyanazt a funkciót nem szabad két különböző végrehajtási történettel felajánlani. A követelmény nyilvánvalónak tűnik, de egy tulajdonság szükséges voltát a tervező által elképzelt felhasználók megjósolt igényeire alapozzuk!

33 2015Németh Gábor: Párhuzamos architektúrák33 ABSZTRAKT SPECIFIKÁCIÓ - 22  ÁLTALÁNOS  A processt használni kell tudni az eredeti tervezési célokon túlmenő feladatokra is.  Nem a problémát, hanem a probléma osztályt kívánjuk megoldani!

34 2015Németh Gábor: Párhuzamos architektúrák34 ABSZTRAKT SPECIFIKÁCIÓ - 23  MINIMÁLIS  A független tulajdonságokat különálló egymásrahatási típusokba kell tenni.  A tulajdonságok függetlenségét a kérdéses szolgáltatás felhasználójának szemszögéből kell értelmezni!  Ez nyilvánvalóan tervező-függő (milyen felhasználói csoportot vesz figyelembe).

35 2015Németh Gábor: Párhuzamos architektúrák35 ABSZTRAKT SPECIFIKÁCIÓ - 24  ÁTTETSZŐ  Az interfész rejtse el a jövőben megváltozható valamennyi megvalósítási tervezői döntést.  Az interfész maga ne változzon, ha az elrejtett megvalósítási döntés megváltozik.  Készítsük el a megvalósítás lehetséges változásainak jegyzékét  (ún. titkok).

36 2015Németh Gábor: Párhuzamos architektúrák36 ABSZTRAKT SPECIFIKÁCIÓ - 25  A tervező nem szükségképpen tudja előre, hogy mi fog a termék élettartama alatt megváltozni!  A rendszert particionáljuk modulokra úgy, hogy minden modul egyetlen titkot tartalmazzon. (Csak egy modult kell kicserélni, ha egy tervezői döntés megváltozik.)  A modul interfészét tervezzük meg úgy, hogy ne változzon meg a titok módosításakor.

37 2015Németh Gábor: Párhuzamos architektúrák37 ABSZTRAKT SPECIFIKÁCIÓ - 26 Funkcionális particionálás Diagnosztikai particionálás Végső particionálás Titokelrejtési particionálás DE EKKOR MÁR NEM IGAZ, HOGY EGYETLEN MODULT KELL MEGVÁLTOZTATNI, HA EGY TITOK MEGVÁLTOZIK!

38 2015Németh Gábor: Párhuzamos architektúrák38 ABSZTRAKT SPECIFIKÁCIÓ - 27 PÉLDA: stack modul BEMENET EGYMÁSRA- HATÁS TÍPUSKIMENETKIVÉTEL pushs_ integer túlcsordulás popsg_ integerüres  Megsérti a minimalitás követel- ményét (a stack tartalmának felfelé mozgatását kombinálja a stack legfelső elemének vizsgálatával).

39 2015Németh Gábor: Párhuzamos architektúrák39 ABSZTRAKT SPECIFIKÁCIÓ - 28  ”Javított” stack modul: (két külön egymásrahatásba tesszük a stack felfelé tolását és legfelső elemének vizsgálatát) BEMENET EGYMÁSRA- HATÁS TÍPUSKIMENETKIVÉTEL pushs_ integer túlcsordulás  DE: a szokásos stack használat hosszabb lesz! pop’ s_ üres integertop üresg_

40 2015Németh Gábor: Párhuzamos architektúrák40 ABSZTRAKT SPECIFIKÁCIÓ - 29 PÉLDA: gráf építő program készítése  Intuitív úton határozzuk meg a szükséges funkciókat. BEMENET EGYMÁSRA- HATÁS TÍPUSKIMENETKIVÉTEL inits_ N: integer maxnodes... INICIALIZÁLÁS:megadjuk a gráf csomópontjainak megengedett maximális számát. A gráf mátrix formában tárolható, könnyen megvalósítható.  Megsérti az ÁTTETSZŐség követelményét.

41 2015Németh Gábor: Párhuzamos architektúrák41 ABSZTRAKT SPECIFIKÁCIÓ - 30 BEMENET EGYMÁSRA- HATÁS TÍPUSKIMENETKIVÉTEL inits_ N: integer maxnodes hasznos,  de nem szükséges (megsérti az ALAPVETŐség követelményét)! numnodes N: integer... LEHETSÉGES CSOMÓPONTOK SZÁMA: g_

42 2015Németh Gábor: Párhuzamos architektúrák42 ABSZTRAKT SPECIFIKÁCIÓ - 31 add_edges_ s: integer d: integer l: real node_number length arc_eqdst GRÁF BŐVÍTÉSE: csomópontot és élt csak együtt adhatunk meg.  Megsérti az ÁLTALÁNOSság követelményét (nem lehet külön él és csomópont felsorolást adni). BEMENET EGYMÁSRA- HATÁS TÍPUSKIMENETKIVÉTEL inits_ N: integer maxnodes numnodes N: integer... g_

43 2015Németh Gábor: Párhuzamos architektúrák43 ABSZTRAKT SPECIFIKÁCIÓ - 32 s_del_edge(s, d, l)A definiált modul nem teszi lehetővé csomópontok és élek törlését. Ez új egymásrahatás bevezetésével [s_del_edge(s, d, l)] lehetséges. Ez hasznos, de  nem szükséges; bevezetése sérti az ALAPVETŐség követelményét Hiánya viszont sérti az ÁLTALÁNOSság követelményét.  nem szükséges; bevezetése sérti az ALAPVETŐség követelményét (ugyanez a cél elérhető az init és azután egy sorozat add_edge használatával is). Hiánya viszont sérti az ÁLTALÁNOSság követelményét.

44 2015Németh Gábor: Párhuzamos architektúrák44 FORMÁLIS BIZONYÍTÁS - 1 A rendszer tulajdonságait orthogonálisan kell specifikálni.A rendszer tulajdonságait orthogonálisan kell specifikálni. Egymástól függetlenül bizonyíthatók (nincs állapot- robbanás).  Nincs közvetlen módszerünk a specifikációk orthogonális felvételére. Viszonylag könnyű formálisan bizonyítani a specifikációk teljesítését.  Absztrakt volta miatt nehezen értelmezhető.

45 2015Németh Gábor: Párhuzamos architektúrák45 FORMÁLIS BIZONYÍTÁS - 2 PÉLDA: gyűrű specifikálása. inportinport node N[u] node N[mod N (u)+1] inportinport outportoutport outout link L[u] inin outportoutport ab Csak egyirányú átvitel  minden csomópontnak van egy bemenő és egy kimenő portja.  ettől gyűrű

46 2015Németh Gábor: Párhuzamos architektúrák46 inportinport node N[u] node N[mod N (u)+1] inportinport outportoutport outout link L[u] inin outportoutport ab process system is N: array [identifier] of node; L: array [identifier] of link; connection for u in 1..N: N[u].outport = L[u].in; N[mod N (u) + 1].inport = L[u].out end system. FORMÁLIS BIZONYÍTÁS - 3

47 2015Németh Gábor: Párhuzamos architektúrák47 FORMÁLIS BIZONYÍTÁS - 4 inportinport node N[u] node N[mod N (u)+1] inportinport outportoutport outout link L[u] inin outportoutport ab port input is operation receive (a  b); constraint [(a  A)  (b  B)] end input. port output is operation send (a  b); constraint [(a  A)  (b  B)] end output.

48 2015Németh Gábor: Párhuzamos architektúrák48 FORMÁLIS BIZONYÍTÁS - 5 inportinport node N[u] node N[mod N (u)+1] inportinport outportoutport outout link L[u] inin outportoutport ab process node is inport: input; outport: output; constraint (outport/a) i  (outport/a) i+1 ; ƒ 1 (inport/b) i  (outport/a) i end node.

49 2015Németh Gábor: Párhuzamos architektúrák49 FORMÁLIS BIZONYÍTÁS - 6 process node is inport: input; outport: output; constraint (outport/a) i  (outport/a) i+1 ; ƒ 1 (inport/b) i  (outport/a) i end node.  A node process feldolgozza a vett üzeneteket és az eredményeket ugyanabban a sorrendben adja ki, ahogy vette a megfelelő bemeneteket.  ”nincs kimenet” helyett 0 hosszúságú kimenő üzenet.  ez írja le a feldolgozást.

50 2015Németh Gábor: Párhuzamos architektúrák50 FORMÁLIS BIZONYÍTÁS - 7  A link process írja le az üzenetátvitelt két feldolgozó csomópont között.  Intuitív  Intuitív vizsgálat eredményeként a hibátlan átvitelt öt orthogonális követelménnyel specifikáljuk. process link is in: input; out: output; constraint /*R1: megőrzi az üzenetek sorrendjét*/  [(a 1, a 2  A), (b 1, b 2  B)]: [(a 1  b 1 )  (a 2  b 2 )]  {[(a 1  a 2 )  (b 1  b 2 )]  [(a 1  a 2 )  (b 1  b 2 )]  [(a 2  a 1 )  (b 2  b 1 )]};  Nehéz áttekinteni és értelmezni.

51 2015Németh Gábor: Párhuzamos architektúrák51 FORMÁLIS BIZONYÍTÁS - 8 /*R2: nem veszik el üzenet az átvitel során*/  (a  A)  (b  B): a  b; /*R3: nem keletkezik üzenet a linkben*/  (b  B)  (a  A): a  b; /*R4: nincs üzenet duplikálás*/  [(a  A), (b 1, b 2  B)]: [(a  b 1 )  (a  b 2 )]  (b 1  b 2 ); /*R5: az üzenet tartalmát megőrzi*/  [(a  A), (b  B)]: ƒ 2 (in/a) i  (out/b) i end link.  kódátalakítás lehetséges!

52 2015Németh Gábor: Párhuzamos architektúrák52 FORMÁLIS BIZONYÍTÁS - 9  Formálisan bizonyítsuk be például, hogy az üzenet tartal- ma nem változik meg, miközben körbeutazik a gyűrűn. inportinport node N[u] node N[mod N (u)+1] inportinport outportoutport outout link L[u] inin outportoutport ab pqrs

53 2015Németh Gábor: Párhuzamos architektúrák53 FORMÁLIS BIZONYÍTÁS N[u].inport:  p  B N[u].outport:  q  A úgy, hogy p  q process node is inport: input; outport: output; constraint (outport/a) i  (outport/a) i+1 ; ƒ 1 (inport/b) i  (outport/a) i end node.  ƒ 1 (p)  q 2. N[mod N (u)+1].inport:  r  B N[mod N (u)+1].outport:  s  A úgy, hogy r  s  ƒ 1 (r)  s

54 2015Németh Gábor: Párhuzamos architektúrák54 FORMÁLIS BIZONYÍTÁS - 11 inportinport node N[u] node N[mod N (u)+1] inportinport outportoutport outout link L[u] inin outportoutport ab p qrs 3. ƒ 2 (q)  r ƒ 2 (q)  r process link is ……………. constraint /*R5: az üz. tart. megőrzi*/  [(a  A), (b  B)]: ƒ 2 (in/a) i  (out/b) i 4. p  s (  tranzitív).  ƒ 1 (p)  q ƒ 1 (r)  s

55 2015Németh Gábor: Párhuzamos architektúrák55 FORMÁLIS BIZONYÍTÁS - 12  Sajnos az alkalmazott formális bizonyítási eljárás (útkeresés gráfon) nem tudja kezelni az univerzális kvantorokat ( ,  és  ), ezeket csak kerülő úton tudjuk leírni.


Letölteni ppt "PÁRHUZAMOS ARCHITEKTÚRÁK – 7 ABSZTRAKT SPECIFIKÁCIÓ Németh Gábor."

Hasonló előadás


Google Hirdetések