PÁRHUZAMOS ARCHITEKTÚRÁK – 7 ABSZTRAKT SPECIFIKÁCIÓ

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

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

2 ABSZTRAKT SPECIFIKÁCIÓ - 1
Az ABSZTRAKT (ALGEBRAI) SPECIFIKÁCIÓs módszernél a rendszer viselkedését egy esemény alapú absztrakt modellel specifikáljuk. A különféle műveletkombinációk között általánosított ekvivalencia relációkat adunk meg. Egy 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. 2015 Németh Gábor: Párhuzamos architektúrák

3 ABSZTRAKT SPECIFIKÁCIÓ - 2
Ezen 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.  A PROCESS egy specifikációs egységnek tekintett, valamilyen adatfeldolgozást végző entitás.  A PORT egy process része, és az illető folyamatnak a környezetével való kommunikációját biztosítja. 2015 Németh Gábor: Párhuzamos architektúrák

4 ABSZTRAKT SPECIFIKÁCIÓ - 3
KÖRNYEZET PROCESS PORT  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ő! 2015 Németh Gábor: Párhuzamos architektúrák

5 ABSZTRAKT SPECIFIKÁCIÓ - 4
FELÜ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. 2015 Németh Gábor: Párhuzamos architektúrák

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

7 ABSZTRAKT SPECIFIKÁCIÓ - 6
PORT SPECIFIKÁCIÓJA:  A porton felléphető egymásrahatás típusok felsorolása.  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? 2015 Németh Gábor: Párhuzamos architektúrák

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

9 ABSZTRAKT SPECIFIKÁCIÓ - 8
PROCESS SPECIFIKÁCIÓJA:  Portjainak felsorolása (mert azok tulajdonságait örökli).  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. 2015 Németh Gábor: Párhuzamos architektúrák

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

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

12 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 operation request (X: question); response (Y: answer); constraint (access/request)i  (access/response)i  (access/request)i+1 end access. 2015 Németh Gábor: Párhuzamos architektúrák

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

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

15 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 2 . . . multiplexer core server  örökölt portok új portok 2015 Németh Gábor: Párhuzamos architektúrák

16 ABSZTRAKT SPECIFIKÁCIÓ - 15
process core is user: access; constraint (user/response)i.Y = ƒ((user/request)i.X) end core.  önkényes tervezői döntés önkényes tervezői döntés (IMPLE-MENTÁ-CIÓ!)  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. A FIFO tároló a multiplexer és a core között van! 2015 Németh Gábor: Párhuzamos architektúrák

17 ABSZTRAKT SPECIFIKÁCIÓ - 16
process server is M: multiplexer; C: core; connection M.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. 2015 Németh Gábor: Párhuzamos architektúrák

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

19 ABSZTRAKT SPECIFIKÁCIÓ - 18
A 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álisan (ld. előző példa) (ez a rendszer működése szempontjából érthető).  Diagnosztika (meghatározza a processek között minimálisan szükséges összeköttetéseket és egymásrahatásokat).  Interfész specifikáció (maximalizálja a rendszer értékét, miközben minimalizálja költségét). 2015 Németh Gábor: Párhuzamos architektúrák

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

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

22 KITÉRŐ: DIAGNOSZTIKA - 3
3 processzor diagnosztikai gráfja: P1 P2 P3 a12 a23 a31 (Ez csak P2 hibája esetén léphet fel.)  1 hiba diagnosztizálható. 2015 Németh Gábor: Párhuzamos architektúrák

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

24 KITÉRŐ: DIAGNOSZTIKA - 5
 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. 2015 Németh Gábor: Párhuzamos architektúrák

25 KITÉRŐ: DIAGNOSZTIKA - 6
A 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.) 2015 Németh Gábor: Párhuzamos architektúrák

26 KITÉRŐ: DIAGNOSZTIKA - 7
Meghatá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)! 2015 Németh Gábor: Párhuzamos architektúrák

27 KITÉRŐ: DIAGNOSZTIKA - 8
Kulcskérdés a hibamódok és a hibaszimptómák közötti kapcsolatok hatékony kezelése. 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. 2015 Németh Gábor: Párhuzamos architektúrák

28 KITÉRŐ: DIAGNOSZTIKA - 9
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. 2015 Németh Gábor: Párhuzamos architektúrák

29 KITÉRŐ: DIAGNOSZTIKA - 10
A diagnosztika által hibásnak talált egységet kiiktatjuk a rendszerből. A rendszerben általában több egység működik együtt, így a kiiktatásnak az ún. hatáskörzetre kell kiterjednie. A 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. 2015 Németh Gábor: Párhuzamos architektúrák

30 ABSZTRAKT SPECIFIKÁCIÓ - 19 Kölcsönösen ellentmondanak egymásnak!
A 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álisan (ez a rendszer működése szempontjából érthető).  Diagnosztika (meghatározza a processek között minimálisan szükséges összeköttetéseket és egymásrahatásokat).  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! 2015 Németh Gábor: Párhuzamos architektúrák

31 ABSZTRAKT SPECIFIKÁCIÓ - 20
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. 2015 Németh Gábor: Párhuzamos architektúrák

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

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

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

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

36 ABSZTRAKT SPECIFIKÁCIÓ - 25
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.  A tervező nem szükségképpen tudja előre, hogy mi fog a termék élettartama alatt megváltozni! 2015 Németh Gábor: Párhuzamos architektúrák

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

38 ABSZTRAKT SPECIFIKÁCIÓ - 27
 PÉLDA: stack modul BEMENET EGYMÁSRA- HATÁS TÍPUS KIMENET KIVÉTEL push s_ integer túlcsordulás pop sg_ ü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). 2015 Németh Gábor: Párhuzamos architektúrák

39 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)  DE: a szokásos stack használat hosszabb lesz! BEMENET EGYMÁSRA- HATÁS TÍPUS KIMENET KIVÉTEL push s_ integer túlcsordulás pop’ s_ üres integer top üres g_ 2015 Németh Gábor: Párhuzamos architektúrák

40 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. INICIALIZÁLÁS: megadjuk a gráf csomópontjainak megengedett maximális számát. BEMENET EGYMÁSRA- HATÁS TÍPUS KIMENET KIVÉTEL init s_ N: integer maxnodes . . .  A gráf mátrix formában tárolható, könnyen megvalósítható.  Megsérti az ÁTTETSZŐség követelményét. 2015 Németh Gábor: Párhuzamos architektúrák

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

42 ABSZTRAKT SPECIFIKÁCIÓ - 31
BEMENET EGYMÁSRA- HATÁS TÍPUS KIMENET KIVÉTEL init s_ N: integer maxnodes numnodes . . . g_ add_edge s_ 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). 2015 Németh Gábor: Párhuzamos architektúrák

43 ABSZTRAKT SPECIFIKÁCIÓ - 32
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 (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. 2015 Németh Gábor: Párhuzamos architektúrák

44 Németh Gábor: Párhuzamos architektúrák
FORMÁLIS BIZONYÍTÁS - 1 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ő. 2015 Németh Gábor: Párhuzamos architektúrák

45 Németh Gábor: Párhuzamos architektúrák
FORMÁLIS BIZONYÍTÁS - 2  PÉLDA: gyűrű specifikálása. Csak egyirányú átvitel  minden csomópontnak van egy bemenő és egy kimenő portja. inport node N[u] node N[modN(u)+1] outport out link L[u] in a b  ettől gyűrű 2015 Németh Gábor: Párhuzamos architektúrák

46 Németh Gábor: Párhuzamos architektúrák
FORMÁLIS BIZONYÍTÁS - 3 inport node N[u] node N[modN(u)+1] outport out link L[u] in a b 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[modN(u) + 1].inport = L[u].out end system. 2015 Németh Gábor: Párhuzamos architektúrák

47 Németh Gábor: Párhuzamos architektúrák
FORMÁLIS BIZONYÍTÁS - 4 inport node N[u] node N[modN(u)+1] outport out link L[u] in a b 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. 2015 Németh Gábor: Párhuzamos architektúrák

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

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

50 Németh Gábor: Párhuzamos architektúrák
FORMÁLIS BIZONYÍTÁS - 7  A link process írja le az üzenetátvitelt két feldolgozó csomópont között.  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*/ [(a1, a2  A), (b1, b2  B)]: [(a1  b1)  (a2  b2)]  {[(a1  a2)  (b1  b2)]  [(a1  a2)  (b1  b2)]  [(a2  a1)  (b2  b1)]};  Nehéz áttekinteni és értelmezni. 2015 Németh Gábor: Párhuzamos architektúrák

51 Németh Gábor: Párhuzamos architektúrák
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), (b1, b2  B)]: [(a  b1)  (a  b2)]  (b1  b2); /*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! 2015 Németh Gábor: Párhuzamos architektúrák

52 Németh Gábor: Párhuzamos architektúrák
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. inport node N[u] node N[modN(u)+1] outport out link L[u] in a b p q r s 2015 Németh Gábor: Párhuzamos architektúrák

53 Németh Gábor: Párhuzamos architektúrák
FORMÁLIS BIZONYÍTÁS - 10 1. 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[modN(u)+1].inport: r  B N[modN(u)+1].outport: s  A úgy, hogy r  s  ƒ1(r)  s 2015 Németh Gábor: Párhuzamos architektúrák

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

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