2.előadás. alapfogalmak, formális definíció
|
|
- Lilla Királyné
- 6 évvel ezelőtt
- Látták:
Átírás
1 2.előadás Források: -Molnár Ágnes: Formális módszerek az informatikában (1), NetAkadámia Tudástár -dr. Pataricza András, dr. Bartha Tamás: Petri hálók: alapfogalmak, formális definíció
2 Validáció és verifikáció Tekintve, hogy az informatikai rendszerek jellegzetesen egyediek, a minőségbiztosításnak nem a termék reprodukciójára, hanem magára a konstrukcióra kell koncentrálnia. A tervezés során a végcél egy olyan rendszer felépítése, amely bizonyítottan helyes szolgáltatásokat nyújt a végfelhasználó felé. E cél érdekében egyrészt alkalmazhatunk matematikai módszereket, amelyek (az adott modell érvényességén belül) 1% valószínűséggel bizonyítják a struktúra helyességét. Másrészt tervezett teszteléssel is megpróbálhatjuk megbecsülni épülő vagy már kész rendszerünk jóságát. Sajnos azonban a legalaposabb tesztelés sem képes a teljes problématér átvizsgálására, ezért sohasem adhat 1%-os bizonyosságot rendszerünk helyes működéséről.
3 A vizsgálat során két kérdéskört kell alaposan végigjárnunk: a megrendelő igényeinek megfelelő, jó rendszert építünk-e (validáció), illetve a fejlesztés során kapott különböző mélységű modellek ekvivalensek-e, azaz jól építjük-e a rendszert (verifikáció).
4 V modell verifikáció verifikáció dekompozíció kompozíció
5 Verifikáció és validáció szerepe Verifikáció: jól építjük-e a rendszert? Validáció: jó rendszert építünk-e? validáció Specifikáció 1 t 1 transzformáció, finomítás Rendszer 2 Specifikáció 2 Rendszer 2 verifikáció Specifikáció n Implementáció Rendszer n
6 Tegyük fel, hogy biztosak lehetünk abban, hogy a kiinduló specifikációnk teljes (az egész problémateret lefedi), és az összes megrendelői kívánalmat teljesíti. Ebben az esetben természetesen elég a tisztán verifikációs megközelítés, azaz a specifikáció és az implementációs modellek ekvivalenciájának bizonyítása. A valós életben azonban gyakran előfordul, hogy a fenti feltételek nem teljesülnek, a rendszer biztonságkritikus, vagy a felhasznált eszközkészlet által nem garantált tulajdonságok ellenőrzése elkerülhetetlen (pl. holtpontmentesség), a validációt sem kerülhetjük el. A specifikáció teljességének ellenőrzése már önmagában is kreativitást igénylő feladat, hiszen bonyolultabb rendszerek reakcióit nemcsak az adott esetben funkcionálisan értelmes esetekre kell specifikálni, hanem minden elképzelhető (és el sem képzelhető) bemeneti szekvenciára is.
7 Modellalkotás és a modell ellenőrzése A fejlesztés első lépéseként a felhasználó igényeinek megfelelő rendszer egy véges modelljét kell megalkotnunk. Az informatikai modell a számítógépben tárolható adatszerkezetek, adatstruktúrák és az ezeket kezelő, átalakító, ezekből információkat lekérdező algoritmusok összessége, rendszere. A modellalkotás egy absztrakciós folyamat, amelynek során egyrészt elhagyjuk a feladat szempontjából lényegtelen jellemzőket, másrészt pontosítjuk és formalizáljuk a lényegeseket, állandóan szem előtt tartva a feladatot majd megoldó eszköz (jelen esetben egy számítógépes hardver-szoftver környezet) tulajdonságait és képességeit.
8 Egy bonyolultabb probléma megoldása közben tapasztalhatjuk azt is, hogy a modell két komponense nem független, az adatstruktúra megválasztása befolyásolja az algoritmus megválasztását és ez fordítva is igaz. Ugyanaz az algoritmus, amely hatékony egyfajta adatstruktúrával, nagyon rossz hatásfokú lehet egy másikkal. Ezért a gyakorlati tervezés általában egy iteratív, javító, módosító lépéseket is tartalmazó folyamat. A modellellenőrzés során a rendszer egy korábban megalkotott modelljéről bizonyítjuk be, hogy teljesülneke rá a kívánt tulajdonságok.
9 Modellellenőrzés A modellellenőrzés olyan plusz előnyökkel rendelkezik, amelyek már a fejlesztés korai, specifikációs szakaszában is megjelennek. Ideális esetben: -a modell határozza meg a designt, -a szoftvert automatikus kódgenerálással készítjük, -a validációt pedig modellellenőrzéssel. A technikák hatékony alkalmazásához azonban tisztában kell lennünk az alkalmazható és alkalmazandó formális módszerekkel, illetve gyakorlatot kell szereznünk az eszközök és technológiák területén is.
10 A modell végessége A modell végessége elvileg garantálja, hogy az algoritmus futása előbb-utóbb véget ér, azonban a gyakorlati életben általában olyan hatalmas állapotterek jönnek létre, amelyek teljes, kimerítő bejárása reménytelen, esélytelen vállalkozás. Kihívás: a mérhetetlenül nagy állapotterek kezelése. Az utóbbi időben két gyakorlati megvalósítás terjedt el: a temporális modellellenőrzés, illetve az automaták formájában történő specifikáció. A temporális modell és a véges automaták modellje matematikai módszerekkel egymásnak megfeleltethető, ekvivalenssé tehető.
11 Temporális modellellenőrzés Alapvetően a temporális logikára épít, és a rendszereket mint véges állapotú rendszereket modellezi. A temporális logika az események időbeli tanulmányozására szolgál. A modális logika egy változata, ahol az operátorokat arra használják, hogy a tények igazságának idejét jelöljék meg. Temporális logikában például ilyen állításokat fogalmazhatunk meg: p a jövőben mindig, minden pillanatban igaz lesz, p a jövőben valamikor igaz lesz stb.
12 Véges automaták (másik megközelítés ) Az automata ugyanúgy matematikai modell, mint a temporális logika, vagy bármely más formalizmus, azonban rendelkezik azzal az óriási előnnyel, hogy már ránézésre is sok minden leolvasható belőle. Egy beszédes UML ábra gyorsabban és több dolgot elárul, mint egy több oldalas magyarázkodás, amely ráadásul sok esetben még félre is értelmezhető. (Egységes Modellező Nyelv (Unified Modelling Language -A Rational Software Corporation által kifejlesztett nyelv, amelyet az objektumorientált tervezés adatleírási céljaira fejlesztettek ki) Az automata mindig valamilyen meghatározott állapotban van. Ezen állapotok közül mindig egy, és csakis egy érvényes (ekkor azt mondjuk, hogy az automata ebben az állapotban van).
13
14 Gondok: A modellellenőrzési módszerek legfőbb veszélye az állapottér robbanása, azaz a probléma bonyolultságának növelésével az állapotok és állapotátmenetek száma exponenciálisan nő. Ma már különböző minimalizáló és redukciós eljárások segítségével akár 1 12 elérhető állapot is vizsgálható (természetesen automatizált, gépi módszerekkel).
15 Létjogosultság Elhíresült példa az IEEE FUTUREBUS szabvány (1986), amelyet különböző formális analíziseknek alávetve kiderült, hogy számos hibát és potenciális kétértelműséget tartalmaz. Sőt, a későbbiekben időanalízissel kibővített módszer még további hibákat is felfedett. Ez volt az első olyan eset, amikor egy nemzetközi szabványról matematikai módszerekkel sikerült bebizonyítani, hogy hibás.
16 Példa Képzeljünk el egy épületet, ahova liftet szeretnénk építeni. A lift alapesetben nyugalmi állapotban van valamelyik emeleten (Idle). Ha utasítás érkezik, ajtaja becsukódik, és a lift elindul a megfelelő irányba. Ha menet közben olyan közbülső emeletre ér, ahonnan szintén hívták, akkor ott is megáll.
17 A modellállapot-automatája háromszintes épületet feltételezve (földszint plusz két emelet).
18 A rendszer a temporális logika nyelvén Milyen operátorokat használhatunk az elemi temporális kifejezésekben: Temporális operátor Fp Gp Xp puq Az operátor jelentése Valamikor p (p valamikor a jövőben igaz lesz) Mindig p (p mindig igaz) Következő p (p a következő pillanatban igaz lesz) p amíg q (p igaz, amíg q igaz nem lesz)
19 G((Ajtót_nyit_1) Ł (X(Ajtót_zár_1)s X(Idle_1)) Mindig igaz, hogy ha valamikor az első emeleten kinyílik az ajtó, a következő állapot az ajtó bezárása, vagy nyugalom lesz. G(F(Idle_)Ł (Idle_)U(Ajtót_zár_)) Mindig igaz, hogy ha a földszinten valamikor nyugalmi állapotba kerülünk, ott is maradunk egészen addig, amíg az ajtó bezárására (és az indulásra) nem kapunk utasítást).
20 Miért is jó mindez? a rendszerünk tulajdonságait, követelményeit implementációfüggetlen módon írhatjuk le; olyan rendszereket is vizsgálhatunk a temporális logika segítségével, amelyek be- és kimenő adatainak kapcsolata nem adható meg egyszerű transzformációként, hanem az időtényező is lényegi szempont (ilyenek például a folyamatos működésű, reaktív rendszerek, az operációs rendszerek stb.).
21 Petri-hálók A Petri-hálók egyidejűleg nyújtanak grafikus és matematikai reprezentációt konkurens aszinkron elosztott párhuzamos nemdeterminisztikus és/vagy sztochasztikus rendszerek modellezésére.
22 Egy rendszer konkurens, ha benne egyidejűleg működő, önálló egységek kommunikálnak egymással úgy, hogy ezen egységek egymáshoz képest tetszőleges működési fázisban vannak. Aszinkronnak nevezzük az eseményvezérelt rendszereket, elosztottnak pedig azokat, amelyeknél az egyes rendszerelemek között funkcionális tagolódás van, azaz valamilyen megegyezés arról, ki milyen feladatot lásson el a teljes és hatékony működés érdekében. A párhuzamos rendszerek nagyon hasonlítanak a konkurensekre, lényeges különbség azonban, hogy párhuzamos esetben a rendszerelemek között szoros szinkronizáció áll fenn (konkurens rendszereknél erre semmilyen megkötés nincs). Ha egy rendszer nemdeterminisztikus, az azt jelenti, hogy egy-egy adott állapotából nem egyértelmű, melyik állapot lesz a következő. Általában adatfüggő, hogy hova lépünk tovább, azonban előfordulhat, hogy a működési módot véletlennel modellezzük.
23 C.A. Petri a 6-as évek elején publikálta a róla elnevezett módszert. Mindent struktúrával fejez ki: a vezérlést és az adatszerkezetet egyaránt. Ennek a megközelítésnek egyik fő előnye, hogy minden más ábrázolásmód kiteríthető Pethi-hálóvá, ugyanakkor már egyszerű feladatok leírása is hatalmas hálót eredményez. Összességében a kiforrott matematikai háttér miatt ez a leírásmód rendkívül hatékony eszköz lehet rendszerek analízisére, ha a rendszer modelljét valamely kompaktabb modellezésből automatikusan származtatjuk.
24 Egyidejűleg: grafikus matematikai reprezentáció Struktúrával fejezi ki: vezérlési struktúra adatstruktúra Előnyök/hátrányok: +más ábrázolásmódok is kiteríthetőek Petri hálóvá egyszerű feladathoz is nagy Petri háló tartozhat
25 Petri hálók struktúrája Strukturálisan: irányított, súlyozott, páros gráf Két típusú csomópont: hely: p P tranzíció: t T O Irányított élek (páros gráf): hely tranzíció tranzíció hely e E : (P T ) (T P )
26 Élek Élsúly: Bármely e E élhez w * (e ) N + súlyt lehet rendelni A w * (e ) súlyú e él ugyanaz, mint w e darab párhuzamos él Nem szokás feltüntetni az egyszeres súlyokat 3
27 Petri hálók felépítése N = <P, T, E, W> = 3
28 Dinamikus működés: állapotváltozók Állapot: Állapotjelölő: token token jelölése: fekete pötty a hely körébe rajzolva Hely állapota: benne levő tokenek száma Hálózat állapota: az egyes helyek állapotainak összessége Állapotvektor: a π = P komponensű M token eloszlás vektor Az m i komponense a p i helyen található tokenek száma p i t m i token jelöli M = m M 1 m π 2 3 Kezdőállapot: M kezdő token elosztás
29 Működés Állapotváltás: Állapot megváltozása: tranzíciók tüzelése engedélyezettség vizsgálata tüzelés végrehajtása tokenek elvétele a bemeneti helyekről tokenek kirakása a kimeneti helyekre megváltozott token eloszlás vektor: új állapot
30 Speciális csomópontok a forrás- és a nyelő tranzíció A forrásnak nincs bemenete, és mindig képes tüzelni a nyelő tranzíciónak pedig nincs kimenete, így a tüzelés során a hozzá érkező tokeneket elnyeli.
31 Példa
32 egy egyszerű Petri-háló kezdeti állapotát (tokeneloszlását) láthatjuk: A P1 állapotban 3, a P2-ben 1, P3-ban token van. A T1 tranzíciónak két bemenő (P1-ből és P2-ből), és két kimenő (P2-be és P3-ba) éle van. Két élnek van 1-től különböző súlya: a P1 T2 él 2, a T2 P1 él 3 súlyú.
33 Mit is jelent mindez? Petri-hálók esetében állapotátmenet helyett tüzelésről beszélünk: ez az a folyamat, amely során a tokenek ide-oda vándorolnak a hálón belül. Egy tranzíció akkor tüzelhet, ha az összes bemenő éléhez csatlakozó helyen van legalább annyi token, amennyi az adott él súlya.
34 T1 tüzelhet, mert P1-ben is, P2-ben is van 1-1 token, T2 azonban nem, mert P1-ben van ugyan 2 token, de P3-ban nincs egy sem. A tüzelés során a tranzíció a bemenő éleihez csatlakozó helyekről (az őseitől) elveszi az élnek megfelelő számú tokent, a kimenő élek végpontjain álló helyekhez (utódaihoz) pedig hozzáad az él súlyának megfelelő számút. A példában a T2 tranzíció a P3 helyről 1, a P1 helyről 2 tokent vesz el a tüzelés során. Most egyértelm rtelmű,, hogy a következk vetkező tüzelő tranzíci ció a T1 lesz, de mi törtt rténik, ha egyszerre több t tranzíci ció is tüzelhett zelhetővé válik? Ebben az esetben is egyetlen tranzíci ció tüzel a következk vetkező alkalommal (a következk vetkező logikai időpillanatban), de hogy melyik, az előre teljesen kiszámíthatatlan (a Petriháló nemdeterminisztikus volta miatt).
35 Hogyan néz ki a fenti háló a T1 tranzíció tüzelése után? Jól látható, hogy most már mind a T1, mind a T2 állapot tüzelhető.
36 T2 tüzelése után A T1 tüzelése után
37 -T2 tranzíció ismét nem képes tüzelésre -ha a T1 tranzíció még egy alkalommal tüzel, akkor a P1 helyen nem marad A T1 tüzelése több token, után a háló holtpontba (deadlock) kerül megegyezik a kiinduló tokeneloszlással
38 Matematikai formalizmussal: Egy adott tokeneloszlást az az M vektor jelöl, amelynek dimenziója a P helyek száma (π= P ), elemei pedig az adott sorszámú helyen az adott pillanatban található tokenek száma. Az előzőekben tekintett kezdeti tokeneloszlás leírása tehát ily módon 3 M = 1 (π =3):
39 M = 3 1 M T1 = 2 1 1
40 Összefoglaló Petri háló: Nemdeterminisztikus véges automata Állapotvektor: token eloszlás vektor Állapotátmeneti függvény: tranzíciók Felépítés: egy-egy hely egy-egy logikai feltétel Petri háló struktúrája követi a feladat logikai dekompozícióját
41 Szintakszis összefoglalása
42 Topológia n (P T ) csomópont n ősei és n utódai: t T ősei a bemeneti helyei: t T utódai a kimeneti helyei: p P ősei a bemeneti tranzíciói: p P utódai a kimeneti tranzíciói: t = {p (p,t ) E } t = {p (t,p ) E } p = {t (t,p ) E } p = {t (p,t ) E }
43 Topológia Csomópontok P P ill. tranzíciók T T részhalmazára: U U U U ' ' ' ' ' ' ' ' T t T t P p P p t T t T p P p P = = = =
44 Speciális csomópontok Forrás ill. nyelő csomópontok t T forrás (nyelő) tranzíció: Bemenő (kimenő) hely nélküli ( t = illetve t = ) Forrás tranzíció minden esetben tud tüzelni PN tiszta, ha nincsenek önhurkai, azaz t T : t t =
45 Topológia példa p 1 2 t 1 p 4 p 2 t p 5 p 3 t 3 p 6 p 1 = p 1 = {t 1, t 2 } p 2 = p 2 = {t 2 } p 3 = {t 3 } p 3 = {t 2 } p 4 = {t 1, t 2 } p 4 = p 5 = {t 2 } p 5 = p 6 = {t 2 } p 6 = {t 3 } t 1 = {p 1 } t 2 = {p 1, p 2, p 3 } t 3 = {p 6 } t 1 = {p 4 } t 2 = {p 4, p 5, p 6 } t 3 = {p 3 }
46 Dinamikus viselkedés Petri hálók működésének egy lépése: Állapot megváltozása: tranzíciók tüzelése korábbi állapot: kezdeti token eloszlás vektor tüzelés végrehajtása 1. engedélyezettség vizsgálata 2. tokenek elvétele a bemeneti helyekről 3. tokenek kirakása a kimeneti helyekre új állapot: megváltozott token eloszlás vektor
47 Tüzelés feltétele Ha egy t T tranzíció minden bemeneti helyét legalább w - (p, t ) token jelöli: w - (p,t) a p -ből t -be vezető e = (p, t ) él w * (e ) súlya a tranzíció tüzelése engedélyezett, ha p t : m w ( p, t) p
48 Állapotátmenet Tüzelés végrehajtása: Engedélyezett tranzíció tetszése szerint tüzelhet vagy nem fire at will Több tranzíció engedélyezett: konfliktus egy lépésben csak egy engedélyezett tranzíció tüzelhet konfliktusfeloldás véletlen választással Nemdeterminisztikus működés A tranzíció tüzelése elvesz w - (p, t ) darab tokent a p t bemeneti helyekről w - (p, t) a p t él súlya elhelyez w + (t, p ) darab tokent a p t kimeneti helyekre w + (t, p) a t p él súlya
49 Nemdeterminizmus és időzítés Tetszés szerinti tüzelés jelentése: implicit időfogalom nincs időskála a tüzelés a [, ) időintervallumban valahol megtörténhet A tüzelésekhez tetszőleges konkrét időértéket rendelve: az azonos struktúrájú és kezdőállapotú nemdeterminisztikus időzítetlen Petri háló annak minden lehetséges tüzelési szekvenciáját lefedi.
50 Szomszédossági mátrix Súlyozott szomszédossági mátrix: W = [w(t, p)] Dimenziója: τ π= T P Ha t tüzel, mennyit változik a p -beli tokenszám: w(t, p) = ha (t, p ) E és (p, t ) E w+ (t, p ) w - (p,t) ha (t, p ) E vagy (p, t ) E
51 Szomszédossági mátrix példa p 1 p 2 p 3 p 4 p 5 p 6 t 1 t 2 t 3 = W = W = W
Petri hálók: alapfogalmak, kiterjesztések
Petri hálók: alapfogalmak, kiterjesztések dr. Bartha Tamás Dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék A Petri hálók eredete Petri háló: Mi az? Carl Adam Petri: német matematikus,
Petri hálók: Alapelemek és kiterjesztések
Petri hálók: Alapelemek és kiterjesztések dr. Bartha Tamás dr. Pataricza András dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék Modellek a formális ellenőrzéshez Mivel nyújt többet
Petri hálók: Alapelemek és kiterjesztések
Petri hálók: Alapelemek és kiterjesztések dr. Bartha Tamás dr. Pataricza András dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék Modellek a formális ellenőrzéshez Mivel nyújt többet
Petri hálók: alapfogalmak, kiterjesztések
Petri hálók: alapfogalmak, kiterjesztések dr. Bartha Tamás Dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék Petri hálók felépítése, működése A Petri hálók eredete Petri háló: Mi
Elérhetőségi analízis Petri hálók dinamikus tulajdonságai
Elérhetőségi analízis Petri hálók dinamikus tulajdonságai dr. Bartha Tamás Dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék Petri hálók vizsgálata Az elemzés mélysége szerint: Vizsgálati
Diszkrét állapotú rendszerek modellezése. Petri-hálók
Diszkrét állapotú rendszerek modellezése Petri-hálók Diszkrét eseményű rendszerek Discret Event (Dynamic) Systems DES, DEDS állapotterük diszkrét halmaz állapotváltozásuk kizárólag az időben aszinkron
Elérhetőségi probléma egyszerűsítése: Állapottér és struktúra redukció Petri-háló alosztályok
Elérhetőségi probléma egyszerűsítése: Állapottér és struktúra redukció Petri-háló alosztályok dr. Bartha Tamás Dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék Elérhetőségi probléma
Diszkrét állapotú rendszerek modellezése. Petri-hálók
Diszkrét állapotú rendszerek modellezése Petri-hálók Diszkrét eseményű rendszerek Discret Event (Dynamic) Systems DES, DEDS állapotterük diszkrét halmaz állapotváltozásuk kizárólag az időben aszinkron
Rendszermodellezés. Modellellenőrzés. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Rendszermodellezés Modellellenőrzés Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Ismétlés: Mire használunk modelleket? Kommunikáció, dokumentáció Gondolkodás,
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (13) Szoftverminőségbiztosítás Szoftverminőség és formális módszerek Formális módszerek Formális módszer formalizált módszer(tan) Formális eljárások alkalmazása a fejlesztésben
Transzformációk integrált alkalmazása a modellvezérelt szoftverfejlesztésben. Ráth István
Transzformációk integrált alkalmazása a modellvezérelt szoftverfejlesztésben Ráth István rath@mit.bme.hu A grafikus nyelvek... mindenhol ott vannak: Grafikus felületek (Visual Studio) Relációs sémák (dbdesign)
A modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel
A modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel Majzik István Micskei Zoltán BME Méréstechnika és Információs Rendszerek Tanszék 1 Modell alapú fejlesztési folyamat (részlet)
Adatfolyam hálók Dr. Bartha Tamás, Dr. Pataricza András fóliái
Adatfolyam hálók Dr. Bartha Tamás, Dr. Pataricza András fóliái Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Adatfolyam modellezés Nem determinisztikus
Elérhetőségi analízis Petri hálók dinamikus és strukturális tulajdonságai
Elérhetőségi analízis Petri hálók dinamikus és strukturális tulajdonságai dr. Bartha Tamás BME Közlekedés- és Járműirányítási Tanszék Dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék
Petri hálók strukturális tulajdonságai Invariánsok és számításuk
Petri hálók strukturális tulajdonságai Invariánsok és számításuk dr. Bartha Tamás Dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék Az elemzés mélysége szerint: Vizsgálati lehetőségek
Részletes szoftver tervek ellenőrzése
Részletes szoftver tervek ellenőrzése Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.mit.bme.hu/~majzik/ Tartalomjegyzék A részletes
A modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel
A modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel Majzik István Micskei Zoltán BME Méréstechnika és Információs Rendszerek Tanszék 1 Modell alapú fejlesztési folyamat (részlet)
Formális módszerek GM_IN003_1 Program verifikálás, formalizmusok
Formális módszerek GM_IN003_1 Program verifikálás, formalizmusok Program verifikálás Konkurens programozási megoldások terjedése -> verifikálás szükséges, (nehéz) logika Legszélesebb körben alkalmazott
Modellellenőrzés a vasút automatikai rendszerek fejlesztésében. XIX. Közlekedésfejlesztési és beruházási konferencia Bükfürdő
Modellellenőrzés a vasút automatikai rendszerek fejlesztésében XIX. Közlekedésfejlesztési és beruházási konferencia Bükfürdő 2018.04.25-27. Tartalom 1. Formális módszerek state of the art 2. Esettanulmány
UML (Unified Modelling Language)
UML (Unified Modelling Language) UML (+ Object Constraint Language) Az objektum- modellezés egy szabványa (OMG) UML A 80-as, 90-es években egyre inkább terjedő objektum-orientált analízis és tervezés (OOA&D)
Gyakorló feladatok: Formális modellek, temporális logikák, modellellenőrzés. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék
Gyakorló feladatok: Formális modellek, temporális logikák, modellellenőrzés Majzik István BME Méréstechnika és Információs Rendszerek Tanszék Formális modellek használata és értelmezése Formális modellek
Színezett Petri hálók
Színezett Petri hálók dr. Bartha Tamás dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék Motiváció Étkező filozófusok Petri-háló modellje: C1 P1 C2 P5 C5 P2 C3 P4 C4 P3 2 Motiváció
Színezett Petri hálók
Színezett Petri hálók dr. Bartha Tamás dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék Étkező filozófusok Petri-háló modellje Motiváció 2 Motiváció Miért nem így? 3 Motiváció Tokenek
Bevezetés az informatikába
Bevezetés az informatikába 6. előadás Dr. Istenes Zoltán Eötvös Loránd Tudományegyetem Informatikai Kar Programozáselmélet és Szoftvertechnológiai Tanszék Matematikus BSc - I. félév / 2008 / Budapest Dr.
Színezett Petri-hálók
Színezett Petri-hálók dr. Bartha Tamás BME Méréstechnika és Információs Rendszerek Tanszék Bevezetés Mik a színezett Petri-hálók? A színezett Petri-hálók olyan modellek, amik a grafikus reprezentációt
Adat és folyamat modellek
Adat és folyamat modellek Előadásvázlat dr. Kovács László Folyamatmodell nyersanyag miből termék mit funkció ki munkaerő eszköz mivel Objektumok Tevékenységek Adatmodell Funkció modell Folyamat modell
Programfejlesztési Modellek
Programfejlesztési Modellek Programfejlesztési fázisok: Követelmények leírása (megvalósíthatósági tanulmány, funkcionális specifikáció) Specifikáció elkészítése Tervezés (vázlatos és finom) Implementáció
Alapszintű formalizmusok
Alapszintű formalizmusok dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék 1 Mit szeretnénk elérni? Informális tervek Informális követelmények Formális modell Formalizált követelmények
Szoftvertechnológia ellenőrző kérdések 2005
Szoftvertechnológia ellenőrző kérdések 2005 Mi a szoftver, milyen részekből áll és milyen típusait különböztetjük meg? Mik a szoftverfejlesztés általános lépései? Mik a szoftvergyártás általános modelljei?
folyamatrendszerek modellezése
Diszkrét eseményű folyamatrendszerek modellezése Hangos Katalin Számítástudomány Alkalmazása Tanszék Veszprémi Egyetem Haladó Folyamatmodellezés és modell analízis PhD kurzus p. 1/36 Tartalom Diszkrét
Modellezés Petri hálókkal. dr. Bartha Tamás dr. Majzik István dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék
Modellezés Petri hálókkal dr. Bartha Tamás dr. Majzik István dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék Modellező eszközök: DNAnet, Snoopy, PetriDotNet A DNAnet modellező
Zárthelyi mintapéldák. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék
Zárthelyi mintapéldák Majzik István BME Méréstechnika és Információs Rendszerek Tanszék Elméleti kérdések Indokolja meg, hogy az A (X Stop F Start) kifejezés szintaktikailag helyes kifejezés-e CTL illetve
Aszinkron rendszerek modellellenőrzése párhuzamos technikákkal
Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Méréstechnika és Információs Rendszerek Tanszék Aszinkron rendszerek modellellenőrzése párhuzamos technikákkal TDK dolgozat
Automatikus tesztgenerálás modell ellenőrző segítségével
Méréstechnika és Információs Rendszerek Tanszék Automatikus tesztgenerálás modell ellenőrző segítségével Micskei Zoltán műszaki informatika, V. Konzulens: Dr. Majzik István Tesztelés Célja: a rendszerben
OpenCL alapú eszközök verifikációja és validációja a gyakorlatban
OpenCL alapú eszközök verifikációja és validációja a gyakorlatban Fekete Tamás 2015. December 3. Szoftver verifikáció és validáció tantárgy Áttekintés Miért és mennyire fontos a megfelelő validáció és
Véges automaták, reguláris nyelvek
Véges automaták, reguláris nyelvek Kiegészítő anyag az lgoritmuselmélet tárgyhoz (a Rónyai Ivanyos Szabó: lgoritmusok könyv mellé) Friedl Katalin BME SZIT friedl@cs.bme.hu 27. augusztus 3. véges automata
Verifikáció és validáció Általános bevezető
Verifikáció és validáció Általános bevezető Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának
Mérés és modellezés Méréstechnika VM, GM, MM 1
Mérés és modellezés 2008.02.04. 1 Mérés és modellezés A mérnöki tevékenység alapeleme a mérés. A mérés célja valamely jelenség megismerése, vizsgálata. A mérés tervszerűen végzett tevékenység: azaz rögzíteni
Részletes tervek ellenőrzése
Szoftverellenőrzési technikák Részletes tervek ellenőrzése Majzik István http://www.inf.mit.bme.hu/ 1 Tartalomjegyzék Áttekintés Milyen szerepe van a részletes terveknek? Milyen ellenőrzési módszerek vannak?
Méréselmélet MI BSc 1
Mérés és s modellezés 2008.02.15. 1 Méréselmélet - bevezetés a mérnöki problémamegoldás menete 1. A probléma kitűzése 2. A hipotézis felállítása 3. Kísérlettervezés 4. Megfigyelések elvégzése 5. Adatok
Tartalom. Állapottér reprezentációk tulajdonságai stabilitás irányíthatóság megfigyelhetőség minimalitás
Tartalom Állapottér reprezentációk tulajdonságai stabilitás irányíthatóság megfigyelhetőség minimalitás 2018 1 Állapottér reprezentációk tulajdonságai Általánosan egy lineáris, SISO dinamikus rendszer
Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert
Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája Készítette: Urbán Norbert Szoftver-minőség A szoftver egy termelő-folyamat végterméke, A minőség azt jelenti,
Valószínűségi modellellenőrzés Markov döntési folyamatokkal
Valószínűségi modellellenőrzés Markov döntési folyamatokkal Hajdu Ákos Szoftver verifikáció és validáció 2015.12.09. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek
Szoftver-modellellenőrzés absztrakciós módszerekkel
Szoftver-modellellenőrzés absztrakciós módszerekkel Hajdu Ákos Formális módszerek 2017.03.22. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék 1 BEVEZETŐ 2
Folyamatmodellezés (BPMN), adatfolyamhálók
Folyamatmodellezés (BPMN), adatfolyamhálók Rendszermodellezés 2015. Budapesti Műszaki és Gazdaságtudományi Egyetem Hibatűrő Rendszerek Kutatócsoport Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika
Mérés és modellezés 1
Mérés és modellezés 1 Mérés és modellezés A mérnöki tevékenység alapeleme a mérés. A mérés célja valamely jelenség megismerése, vizsgálata. A mérés tervszerűen végzett tevékenység: azaz rögzíteni kell
Aszinkron rendszerek heurisztikával támogatott modellellenőrzése
Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Méréstechnika és Információs Rendszerek Tanszék Aszinkron rendszerek heurisztikával támogatott modellellenőrzése SZAKDOLGOZAT
Autóipari beágyazott rendszerek. Komponens és rendszer integráció
Autóipari beágyazott rendszerek és rendszer integráció 1 Magas szintű fejlesztési folyamat SW architektúra modellezés Modell (VFB) Magas szintű modellezés komponensek portok interfészek adattípusok meghatározása
Bevezetés a programozásba
Bevezetés a programozásba A szoftverfejlesztés folyamata PPKE-ITK Tartalom A rendszer és a szoftver fogalma A szoftver, mint termék és készítésének jellegzetességei A szoftverkészítés fázisai: Az igények
S01-7 Komponens alapú szoftverfejlesztés 1
S01-7 Komponens alapú szoftverfejlesztés 1 1. A szoftverfejlesztési modell fogalma. 2. A komponens és komponens modell fogalma. 3. UML kompozíciós diagram fogalma. 4. A szoftverarchitektúrák fogalma, összetevői.
01. gyakorlat - Projektalapítás
2 Követelmények 01. gyakorlat - Projektalapítás Szoftvertechnológia gyakorlat OE-NIK A félév során egy nagyobb szoftverrendszer prototípusának elkészítése lesz a feladat Fejlesztési módszertan: RUP CASE-eszköz:
Modell alapú tesztelés mobil környezetben
Modell alapú tesztelés mobil környezetben Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék A terület behatárolása Testing is an activity performed
Programozási módszertan
1 Programozási módszertan 1. Alapfogalmak Feldhoffer Gergely 2012 Féléves tananyag terve 2 Program helyességének bizonyítása Reprezentáció Logikai-matematikai eszköztár Programozási tételek bizonyítása
Sztochasztikus temporális logikák
Sztochasztikus temporális logikák Teljesítmény és szolgáltatásbiztonság jellemzők formalizálása és ellenőrzése Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs
Szoftver karbantartási lépések ellenőrzése
Szoftverellenőrzési technikák (vimim148) Szoftver karbantartási lépések ellenőrzése Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.inf.mit.bme.hu/
Számítógép hálózatok, osztott rendszerek 2009
Számítógép hálózatok, osztott rendszerek 2009 1: Bevezetés: Internet, rétegmodell Alapok: aszimptótika, gráfok 1 Az előadáshoz Előadás: Hétfő 10:00 12:00 óra Gyakorlat: Hétfő 14:00-16:00 óra Honlap: http://people.inf.elte.hu/lukovszki/courses/0910nwmsc
Osztott rendszer. Osztott rendszer informális definíciója
Osztott rendszer Osztott rendszer informális definíciója Egymástól elkülönülten létező program-komponensek egy halmaza. A komponensek egymástól függetlenül dolgoznak saját erőforrásukkal. A komponensek
Az UPPAAL egyes modellezési lehetőségeinek összefoglalása. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék
Az UPPAAL egyes modellezési lehetőségeinek összefoglalása Majzik István BME Méréstechnika és Információs Rendszerek Tanszék Résztvevők együttműködése (1) Automaták interakciói üzenetküldéssel Szinkron
Objektumorientált paradigma és a programfejlesztés
Objektumorientált paradigma és a programfejlesztés Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján Objektumorientált
Petri-hálók és produkciós hálók közötti kapcsolat
A kutatás célkitűzése a Petri-hálók és a produkciós hálók közötti kapcsolat feltárásának segítségével olyan hatékony analízis és optimalizálási módszerek kidolgozása volt, melyek eszközként szolgálnak
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN
ALAPFOGALMAK 1. A reláció az program programfüggvénye, ha. Azt mondjuk, hogy az feladat szigorúbb, mint az feladat, ha
ALAPFOGALMAK 1 Á l l a p o t t é r Legyen I egy véges halmaz és legyenek A i, i I tetszőleges véges vagy megszámlálható, nem üres halmazok Ekkor az A= A i halmazt állapottérnek, az A i halmazokat pedig
... S n. A párhuzamos programszerkezet két vagy több folyamatot tartalmaz, melyek egymással közös változó segítségével kommunikálnak.
Párhuzamos programok Legyen S parbegin S 1... S n parend; program. A párhuzamos programszerkezet két vagy több folyamatot tartalmaz, melyek egymással közös változó segítségével kommunikálnak. Folyamat
1: Bevezetés: Internet, rétegmodell Alapok: aszimptótika, gráfok. HálózatokII, 2007
Hálózatok II 2007 1: Bevezetés: Internet, rétegmodell Alapok: aszimptótika, gráfok 1 Az előadáshoz Előadás: Szerda 17:00 18:30 Gyakorlat: nincs Vizsga írásbeli Honlap: http://people.inf.elte.hu/lukovszki/courses/g/07nwii
Csoportos üzenetszórás optimalizálása klaszter rendszerekben
Csoportos üzenetszórás optimalizálása klaszter rendszerekben Készítette: Juhász Sándor Csikvári András Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Automatizálási
BPEL nyelvű üzleti folyamatok modellezése és formális ellenőrzése
BPEL nyelvű üzleti folyamatok modellezése és formális ellenőrzése Kovács Máté, Gönczy László {kovmate,gonczy}@mit.bme.hu Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek
TDK-dolgozat. Darvas Dániel 2010.
TDK-dolgozat Darvas Dániel 2010. Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Méréstechnika és Információs Rendszerek Tanszék Szaturáció alapú automatikus modellellenőrző
Formális módszerek GM_IN003_1 Bevezetés
Formális módszerek GM_IN003_1 Formális módszerek Formális módszer! formalizált módszer(tan) Formális eljárások alkalmazása a fejlesztésben nincs olyan formális eljárás, ami egy komplex rendszer minden
Hardver és szoftver rendszerek verifikációja Röviden megválaszolható kérdések
Hardver és szoftver rendszerek verifikációja Röviden megválaszolható kérdések 1. Az informatikai rendszereknél mit ellenőriznek validációnál és mit verifikációnál? 2. A szoftver verifikációs technikák
Biológiai rendszerek modellellenőrzése bayesi megközelítésben
Biológiai rendszerek modellellenőrzése bayesi megközelítésben Gál Tamás Zoltán Szoftver verifikáció és validáció kiselőadás, 2013. ősz Forrás: Sumit K. Jha et al.: A Bayesian Approach to Model Checking
Témakörök. Egyed-kapcsolat modell. Alapfogalmak
Témakörök Alapkocepciók Szoftvertechológia előadás Egyed-kapcsolat modellek Osztálydiagramok Iterakciódiagramok Vezérlési struktúrák Dötési táblák és fák Állapotautomaták Petri hálók Egyed-kapcsolat modell
A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-folyamat Szoftver
Bánsághi Anna anna.bansaghi@mamikon.net. 2014 Bánsághi Anna 1 of 31
IMPERATÍV PROGRAMOZÁS Bánsághi Anna anna.bansaghi@mamikon.net 9. ELŐADÁS - OOP TERVEZÉS 2014 Bánsághi Anna 1 of 31 TEMATIKA I. ALAPFOGALMAK, TUDOMÁNYTÖRTÉNET II. IMPERATÍV PROGRAMOZÁS Imperatív paradigma
Összefoglalás és gyakorlás
Összefoglalás és gyakorlás High Speed Networks Laboratory 1 / 28 Hálózatok jellemző paraméterei High Speed Networks Laboratory 2 / 28 Evolúció alkotta adatbázis Önszerveződő adatbázis = (struktúra, lekérdezés)
Programtervezés. Dr. Iványi Péter
Programtervezés Dr. Iványi Péter 1 A programozás lépései 2 Feladat meghatározás Feladat kiírás Mik az input adatok A megoldáshoz szükséges idő és költség Gyorsan, jót, olcsón 3 Feladat megfogalmazása Egyértelmű
2.1.A SZOFTVERFEJLESZTÉS STRUKTÚRÁJA
2.Szoftverfejlesztés 2.1.A SZOFTVERFEJLESZTÉS STRUKTÚRÁJA Szoftverfejlesztés: magában foglalja mindazon elveket, módszereket és eszközöket, amelyek célja a programok megbízható és hatékony elkészítésének
Korlátos modellellenőrzés. dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék
Korlátos modellellenőrzés dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék 1 Hol tartunk most? Alacsony szintű formalizmusok (KS, LTS, KTS) Magasabb szintű formalizmusok Temporális
0,424 0,576. f) P (X 2 = 3) g) P (X 3 = 1) h) P (X 4 = 1 vagy 2 X 2 = 2) i) P (X 7 = 3, X 4 = 1, X 2 = 2 X 0 = 2) j) P (X 7 = 3, X 4 = 1, X 2 = 2)
Legyen adott a P átmenetvalószín ség mátrix és a ϕ 0 kezdeti eloszlás Kérdés, hogy miként lehetne meghatározni az egyes állapotokban való tartózkodás valószín ségét az n-edik lépés múlva Deniáljuk az n-lépéses
A programozás alapjai előadás. Amiről szólesz: A tárgy címe: A programozás alapjai
A programozás alapjai 1 1. előadás Híradástechnikai Tanszék Amiről szólesz: A tárgy címe: A programozás alapjai A számítógép részegységei, alacsony- és magasszintű programnyelvek, az imperatív programozási
Intervenciós röntgen berendezés teljesítményszabályozójának automatizált tesztelése
Intervenciós röntgen berendezés teljesítményszabályozójának automatizált tesztelése Somogyi Ferenc Attila 2016. December 07. Szoftver verifikáció és validáció kiselőadás Forrás Mathijs Schuts and Jozef
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2017-18/2 (9) Szoftverminőségbiztosítás Specifikáció alapú (black-box) technikák A szoftver mint leképezés Szoftverhiba Hibát okozó bement Hibás kimenet Input Szoftver Output Funkcionális
NP-teljesség röviden
NP-teljesség röviden Bucsay Balázs earthquake[at]rycon[dot]hu http://rycon.hu 1 Turing gépek 1/3 Mi a turing gép? 1. Definíció. [Turing gép] Egy Turing-gép formálisan egy M = (K, Σ, δ, s) rendezett négyessel
A fejlesztési szabványok szerepe a szoftverellenőrzésben
A fejlesztési szabványok szerepe a szoftverellenőrzésben Majzik István majzik@mit.bme.hu http://www.inf.mit.bme.hu/ 1 Tartalomjegyzék Biztonságkritikus rendszerek A biztonságintegritási szint Az ellenőrzés
Temporális logikák és modell ellenırzés
Temporális logikák és modell ellenırzés Temporális logikák Modális logika: kijelentések különböző módjainak tanulmányozására vezették be (eredetileg filozófusok). Ilyen módok: esetleg, mindig, szükségszerűen,
V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus
V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus 1 Az előadás tartalma A GI helye az informatikában Az előadás tartalmának magyarázata A
3. gyakorlat Folyamatmodellek, kooperáló viselkedésmodellek Megoldások
3. gyakorlat Folyamatmodellek, kooperáló viselkedésmodellek ok Figyelem: Jelen anyag belső használatra készült megoldási útmutató, melyet a ZH felkészülés segítése érdekében publikáltunk. A feladatok részletesebb
Objektumorientált paradigma és programfejlesztés Bevezető
Objektumorientált paradigma és programfejlesztés Bevezető Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján
Párhuzamos programozási platformok
Párhuzamos programozási platformok Parallel számítógép részei Hardver Több processzor Több memória Kapcsolatot biztosító hálózat Rendszer szoftver Párhuzamos operációs rendszer Konkurenciát biztosító programozási
26. MINIMÁLIS KÖLTSÉGŰ UTAK MINDEN CSÚCSPÁRRA
26. MINIMÁLIS KÖLTSÉGŰ UTAK MINDEN CSÚCSPÁRRA Az előző két fejezetben tárgyalt feladat általánosításaként a gráfban található összes csúcspárra szeretnénk meghatározni a legkisebb költségű utat. A probléma
Digitális eszközök típusai
Digitális eszközök típusai A digitális eszközök típusai Digitális rendszer fogalma Több minden lehet digitális rendszer Jelen esetben digitális integrált áramköröket értünk a digitális rendszerek alatt
NEM-DETERMINISZTIKUS PROGRAMOK HELYESSÉGE. Szekvenciális programok kategóriái. Hoare-Dijkstra-Gries módszere
Szekvenciális programok kategóriái strukturálatlan strukturált NEM-DETERMINISZTIKUS PROGRAMOK HELYESSÉGE Hoare-Dijkstra-Gries módszere determinisztikus valódi korai nem-determinisztikus általános fejlett
Gráfelméleti alapfogalmak
1 Gráfelméleti alapfogalmak Gráf (angol graph= rajz): pontokból és vonalakból álló alakzat. pontok a gráf csúcsai, a vonalak a gráf élei. GRÁ Irányítatlan gráf Vegyes gráf Irányított gráf G H Izolált pont
Hatékony technikák modellellenőrzéshez: Korlátos modellellenőrzés. dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék
Hatékony technikák modellellenőrzéshez: Korlátos modellellenőrzés dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék 1 Hol tartunk most? Alacsony szintű formalizmusok (KS, LTS, KTS)
Autóipari beágyazott rendszerek. Kockázatelemzés
Autóipari beágyazott rendszerek Kockázatelemzés 1 Biztonságkritikus rendszer Beágyazott rendszer Aminek hibája Anyagi vagyont, vagy Emberéletet veszélyeztet Tipikus példák ABS, ESP, elektronikus szervokormány
Párhuzamos programozási platformok
Párhuzamos programozási platformok Parallel számítógép részei Hardver Több processzor Több memória Kapcsolatot biztosító hálózat Rendszer szoftver Párhuzamos operációs rendszer Konkurenciát biztosító programozási
OOP. Alapelvek Elek Tibor
OOP Alapelvek Elek Tibor OOP szemlélet Az OOP szemlélete szerint: a valóságot objektumok halmazaként tekintjük. Ezen objektumok egymással kapcsolatban vannak és együttműködnek. Program készítés: Absztrakciós
Gráfelméleti alapfogalmak-1
KOMBINATORIKA ELŐADÁS osztatlan matematika tanár hallgatók számára Gráfelméleti alapfogalmak Előadó: Hajnal Péter 2015 1. Egyszerű gráfok Nagyon sok helyzetben egy alaphalmaz elemei között kitűntetett
Modellezési alapismeretek
Modellezési alapismeretek Budapesti Műszaki és Gazdaságtudományi Egyetem Hibatűrő Rendszerek Kutatócsoport Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Irányítástechnika GÁSPÁR PÉTER. Prof. BOKOR JÓZSEF útmutatásai alapján
Irányítástechnika GÁSPÁR PÉTER Prof. BOKOR JÓZSEF útmutatásai alapján Irányítástechnika rendszerek Irányítástechnika Budapest, 2008 2 Az előadás felépítése 1. 2. 3. 4. Irányítástechnika Budapest, 2008
2. gyakorlat Állapot alapú modellezés Megoldások. 1. feladat. Rendszermodellezés (BMEVIMIAA00), tavaszi félév
2. gyakorlat Állapot alapú modellezés ok Figyelem: Jelen anyag belső használatra készült megoldási útmutató, melyet a ZH felkészülés segítése érdekében publikáltunk. A feladatok részletesebb megoldása