TITAN: TTCN-3 tesztvégrehajtó környezet
|
|
- Réka Farkasné
- 9 évvel ezelőtt
- Látták:
Átírás
1 TITAN: TTCN-3 tesztvégrehajtó környezet SZABÓ JÁNOS ZOLTÁN, CSÖNDES TIBOR Ericsson Magyarország, Test Competence Center {janos.zoltan.szabo, Kulcsszavak: tesztelés, TTCN-3, tesztrendszer megvalósítás Cikkünkben bemutatjuk az Ericsson TITAN nevû TTCN-3 tesztvégrehajtó környezetét, annak mûködését és belsô felépítését. Megvizsgáljuk a TITAN fô jellemzôit és a lényeges különbségeket más, kereskedelmi TTCN-3 eszközökhöz képest. Fejlesztésünk eredményeként a TTCN-3 és a TITAN széles körben használt tesztmegoldás lett az Ericsson-on belül, emellett lehetôségünk volt részt venni az ETSI-ben folyó TTCN-3 szabványosítási munkában. 1. Bevezetés A 80-as és 90-es években az OSI rétegmodellre épülô távközlési rendszerek tesztelésére a TTCN nyelv 2. változatát használták. Széleskörû elterjedésének gátat szabott a nyelv nehézkes táblázatos leíró formátuma, valamint a korlátozott alkalmazási terület. Ennek hatására az ETSI a 90-es évek végén a nyelv legújabb változatának, a TTCN-3-nak a kidolgozásához kezdett. A nyelv tervezésénél figyelembe vették, hogy az eddigi konformanciateszt-alkalmazásokon felül új tesztelési módszerekre is megfelelô legyen, mint például: együttmûködési teszt, teljesítményteszt, robosztussági teszt, rendszerteszt. Az ETSI szakított a klasszikus ISO OSI modell alapú felfogással, ezzel lehetôvé téve az IP alapú rendszerek, valamint a programinterfészek (API Application Program Interface) tesztelését is A TTCN-3 nyelv A TTCN-3 nyelv elsô szabványsorozatát 2000-ben adta ki az ETSI. Azóta több verziója látott napvilágot. A legutolsó, aktuális szabványgyûjteményt 2005-ben jelent meg [1]. A szabványosítás alatt megpróbálták elfeledni a nehézkes TTCN-2-es struktúrákat és ezzel elejét venni az ismételt negatív megítélésnek, ami a TTCN elôzô verziója kapcsán elterjedt a távközlési szakemberek körében. A törekvés nem volt hiábavaló, mivel egy könnyen átlátható és a tesztelést nagymértékben segítô nyelv lett az eredmény. A TTCN-3 szöveges formátuma nagyban hasonlít a széles körben elterjedt C/C++ programozási nyelvre, így sok felhasználó számára mélyebb TTCN-3-as ismeret nélkül is érthetôek a nyelvi struktúrák. A TTCN-3 nyelvrôl és elemeirôl egy részletes öszszefoglaló cikkben olvashatunk [4] A TITAN története A TITAN kifejlesztése elején egy egyetemi diplomamunka keretében kezdôdött. A fejlesztés elsôdleges célja egy teljesítménytesztek végrehajtására is alkalmas, hatékony, de ugyanakkor protokoll- és alkalmazásfüggetlen futtatókörnyezet létrehozása volt. Ehhez jó alapot szolgált az ETSI-ben éppen kidolgozás alatt álló TTCN-3 nyelv. Kevesebb, mint 1 év alatt készült el a rendszer elsô prototípusa, amely a nyelv lehetôségeinek csak egy részét támogatta, de belsô felépítése és mûködése a mostani állapothoz nagyon hasonlított [5]. A TITAN azóta is folyamatos fejlôdés alatt áll, követi a szabványok változásait, egyre több kényelmi funkcióval rendelkezik, és mára szinte az összes TTCN-3 nyelvi konstrukciót támogatja. A fejlesztés fôbb mérföldkövei az alábbiak voltak: 2000: prototípus készítése, 2001: párhuzamos és elosztott teszt végrehajtás, : ASN.1 nyelv támogatása, szemantikus ellenôrzéssel, 2004: grafikus felhasználói felület, 2005: teljes TTCN-3 szemantikus ellenôrzés. 2. A TITAN felépítése A TTCN-3 fordító és futtató környezet blokkdiagrammja az 1. ábrán látható. A TITAN részei a következôk: 2.1. TTCN-3, ASN.1 fordító A TTCN-3 és ASN.1 fordítóprogram a TITAN legnagyobb, legösszetettebb részegysége. Feladata a tesztkészletet alkotó modulok elemzése, ellenôrzése és a bennük található esetleges szintaktikai és szemantikai hibák jelzése. Ha a bemenet hibátlannak bizonyult, a fordító C++ nyelvû programmodulokat generál, melyek részét képezik a végrehajtható tesztsorozatnak Alapkönyvtár Az alapkönyvtár tartalmazza a futtatható tesztsorozatoknak azt az állandó közös részét, amely független a tesztsorozatot alkotó modulok tartalmától. Az alap- LXI. ÉVFOLYAM 2006/9 29
2 HÍRADÁSTECHNIKA 1. ábra A TITAN blokkdiagrammja könyvtár kézzel megírt és elôre lefordított C++ programkódból áll. Itt találhatók meg a TTCN-3 alaptípusait megvalósító osztályok, a nyelv beépített függvényeit és mûveleteit (például idôzítôk, portok, komponensek kezelését) megvalósító funkciók. A tesztsorozat futtatásához szükséges egyéb, például a naplót készítô vagy a konfigurációs fájlt értelmezô szoftvermodulok szintén az alapkönyvtár részét alkotják Tesztportok A tesztportok feladata az összeköttetés és a kommunikáció biztosítása a futtatható tesztsorozat és a tesztelendô rendszer között. A TTCN-3 nyelv a külvilággal való kapcsolatot kommunikációs portokon át küldött és fogadott absztrakt üzenetekkel modellezi. A tesztport tulajdonképpen egy TTCN-3 kommunikációs port C++ nyelvû megvalósítása a végrehajtható tesztsorozatban. A TITAN egy jól definiált programozói interfészt, úgynevezett tesztport API-t biztosít a kimenô és bejövô üzenetek kezelésére. A tesztport megvalósítások operációs rendszer hívások és általában IP alapú protokollok segítségével kommunikálnak a tesztelendô rendszerrel. Szintén a tesztportok feladata a TTCN-3 absztrakt, struktúrált üzeneteinek átviteli csatornán használt bitfolyammá alakítása (kódolása) és visszaalakítása (dekódolása) Segédprogramok A TITAN-hoz tartozik még számos kis segédprogram, melyek a tesztírást, végrehajtást vagy az eredmények feldolgozását segítik. Található itt tesztfuttatást automatizáló szkript, naplófájlokat összefûzô és formázó segédprogram stb Teszt-vezérlô Ha egy teszteset egyszerre több párhuzamosan futó tesztkomponenst használ, akkor ezek mûködését öszsze kell hangolni. A tesztrendszer központi koordinálását a futtatható tesztsorozattól független, TITAN-hoz tartozó program végzi. A tesztvezérlô program kapcsolatban áll a tesztrendszer összes komponensével, segítségével zajlik a tesztkomponensek létrehozása és leállítása valamint a közöttük lévô port kapcsolatok felépítése és bontása. Teljesítmény-tesztelés esetén a tesztrendszer több számítógépre is elosztható. Ilyenkor a gépek közötti terhelésmegosztás szintén a tesztvezérlô feladata. Hogy a tesztrendszerben ne legyen szûk keresztmetszet, a tesztvezérlô kizárólag koordinátori feladatokat lát el, üzenetek továbbításában és elemi teszteseményekben egyáltalán nem vesz részt. A TITAN elosztott teszt-architektúrájának részletes leírása [6]-ban olvasható. A tesztvezérlô biztosítja a felhasználói felületet a tesztsorozat interaktív végrehajtása közben. A felhasználói felület lehet szöveges (parancssori) vagy grafikus. Ezen keresztül a felhasználó folyamatosan képet kap a tesztrendszer pillanatnyi állapotáról és a végrehajtott mûveletekrôl, és szükség esetén be is avatkozhat: leállíthatja az éppen futó tesztesetet vagy egy új tesztesetet indíthat el. 3. A TITAN mûködése 3.1. Szintaktikai és szemantikai ellenôrzés A bemenô modulok szintaktikai elemzése a GNU flex és bison segédprogramokkal készített elemzôk segítségével történik. Az elemzés során a bemenetbôl a fordító egy speciális memóriastruktúrát, úgynevezett ab- 30 LXI. ÉVFOLYAM 2006/9
3 TITAN: TTCN-3 teszt végrehajtó környezet sztrakt szintaxisfát épít, amely a további fordítási lépések alapjául szolgál. Az integrált ASN.1 és TTCN-3 fordítóprogram elônye, hogy a két nyelv definíciói egy közös és egységes szintaxisfába kerülhetnek. Ez megkönnyíti a TTCN-3 tesztek írását az ASN.1 leírással rendelkezô protokollokhoz. A szemantikai ellenôrzés feladata a hibás név szerinti hivatkozások, meg nem engedett mûveletek, adattípus-ütközések és hasonló hibák kiszûrése. Az ellenôrzô algoritmus egymenetes, tehát a szintaxisfát egyszer járja végig, de a bejárás sorrendjét a definíciók közötti hivatkozások befolyásolhatják. Szemantikai ellenôrzés során a legnagyobb kihívást a kétértelmû nyelvi elemek kezelése jelenti, ugyanis ASN.1-ben és TTCN- 3-ban egyaránt elôfordulnak olyan konstrukciók, melyeket a szintaktikai elemzés nem tud beazonosítani. Ha a fordító akár szintaktikai, akár szemantikai hibát talál, az elsô hibaüzenet kiírása után nem áll meg, hanem folytatja tovább az ellenôrzést, hogy újabb hibákat derítsen fel. Az ellenôrzô algoritmusokban hibaelfedést alkalmazunk, azaz egy létezô, de hibás definícióra történô hivatkozás nem generál újabb hibaüzeneteket. Különben egyetlen egyszerû hiba is hibaüzenetek lavináját indítaná el Kódgenerálás A C++ kód generálása szintén a szintaxisfa alapján történik, melyen a szemantikus ellenôrzô már bizonyos egyszerûsítéseket végrehajtott, például a konstans aritmetikai kifejezéseket összevonta. A generált kód legfôbb jellemzôje, hogy statikusan tipizált, azaz minden TTCN-3 és ASN.1 adattípushoz külön C++ típus (osztály) tartozik. Ennek legfôbb elônye a futási sebességben jelentkezik, ugyanis a TTCN- 3 adatértékek és mezôk memóriabeli elhelyezését a C++ fordító automatikusan elvégzi. További elôny, hogy a TTCN-3 mûveleteknél a típusegyezést a C++ fordító is ellenôrzi. Ez utóbbit a fordítóprogram azon régebbi változatainál használtuk ki, amelyek egyáltalán nem tartalmaztak TTCN-3 szemantikus ellenôrzést. A korai verziókban a C++ kódgenerálás a szintaktikai elemzéssel egyidejûleg történt, a szemantikai hibákra a C++ fordító hibaüzeneteibôl lehetett következtetni. A statikus típuskezelés egyetlen hátránya az összetett protokollok típusait leíró C++ osztályhierarchia nagy mérete és az emiatt megnövekedô fordítási idô. A típusok nagy kódméretét némileg ellensúlyozza, hogy a TTCN-3 értékekre, adatmintákra (templatekre) és viselkedés leírásokra (függvényekre, tesztesetekre stb.) tömör C++ kód generálható. Dinamikus tipizálás esetén, melyet a legtöbb piacon kapható TTCN-3 eszköz alkalmaz, az adatértékeket a futtató környezet általános struktúrákból állítja össze, és minden mûveletnél a típusegyezést is vizsgálni kell (például egy egész számokon végzett mûvelet egy általános adatstruktúrában kapja meg a paraméterét, és neki kell meggyôzôdnie arról, hogy tényleg egész számot kapott-e). E kiegészítô mûveletek akár 10 vagy 100- szoros sebességcsökkenést is eredményezhetnek a TITAN-hoz viszonyítva Futtatható tesztsorozat elôállítása A teljes fordítási folyamat, így a tesztsorozat C++-ra fordítása, a generált C++ programkód és a tesztportok gépi kódra fordítása valamint a végrehajtható tesztsorozat összeszerkesztése, a make segédprogram használatával történik. A fordítási lépések közötti függôséget leíró Makefile-t a TITAN fordítóprogramja automatikusan elô tudja állítani a TTCN-3 és ASN.1 modulok, valamint a tesztportok ismeretében. A gyakorlatban használt TTCN-3 tesztsorozatok általában sok modulból állnak. Megfigyelhetô, hogy a tesztírási folyamat során a modulok nagy része (például egy protokoll üzeneteit leíró típusdefiníciókat tartalmazó modul) csak ritkán változik. Két fordítás és futtatás közötti változás általában csak néhány modult és ezen belül néhány programsort érint (leggyakrabban a teszteseteket leíró TTCN-3 utasítások változnak). Mivel egy teljes fordítás percekig, komplex tesztsorozatok esetén akár órákig is eltarthat, nem célszerû ezt a folyamatot minden apró módosítás után megismételni. A TITAN fordítója és a make segédprogram együtt képes inkrementális fordítást végezni. Ez azt jelenti, hogy az elôzô fordítás részeredményeit felhasználva csak a változások által érintett modulokból generál C++ kódot, és csak a szükséges állományokat fordítja le újra. Az újrafordítandó modulok beazonosítása bizonyos esetekben nem egyszerû feladat. Ha egy modul definícióit más modulok is használják, akkor az itt bekövetkezô változások a használó modulokat is érinthetik, amelyek hatással lehetnek az ôket használó modulokra, és így tovább. Ilyenkor elôfordulhat, hogy egyetlen változás miatt modulok tucatját kell újrafordítani azért, hogy a végrehajtható tesztsorozat konzisztenciáját megôrizzük. Mindezek ellenére a gyakorlati példák azt igazolják, hogy a TITAN inkrementális fordítással jelentôsen tudja csökkenteni a fordítási idôt és ezáltal növelni a tesztsorozat-fejlesztés hatékonyságát Kódolás, dekódolás A tesztfuttatás során a tesztelendô rendszernek küldött üzeneteket kódolni, míg az onnan fogadottakat értelmezni, dekódolni kell. Ennek megkönnyítésére a TITAN számos beépített kódolóval rendelkezik, melyek C++ nyelvû interfészen keresztül érhetôk el. Így egy üzenet kódolása vagy dekódolása az üzenet bonyolultságától függetlenül néhány programsorban elvégezhetô. Ezek a kódoló funkciók elhelyezhetôk egy tesztportban vagy egy TTCN-3-ból hívható, de C++ nyelven megírt külsô függvényben. Az ASN.1-ben leírt üzeneteket a TITAN a BER szabályai szerint képes kódolni, a TTCN-3 adattípusokhoz kétféle, egy szöveges (TEXT) és egy táblázatos, bit alapú (RAW) kódolás létezik. TTCN-3 típusok esetén a kódolási szabályokat, melyek lehetnek egészen összetettek is, attribútumok segítségével lehet megadni. LXI. ÉVFOLYAM 2006/9 31
4 HÍRADÁSTECHNIKA 3.5. Grafikus felület A TITAN-hoz a tesztvezérlôvel egybeépített grafikus felület is tartozik, mely a TTCN-3 tesztsorozatok fejlesztésénél és futtatásánál is segítséget nyújt a felhasználók számára. A 2. ábrán a grafikus felület fô ablakának képernyôképe látható. Bal oldalon találjuk a tesztsorozatot alkotó modulok, tesztportok és egyéb fájlok listáját. A jobb oldali ablakban pedig a fordítás menetét követhetjük nyomon, most épp egy inkrementális fordítás kimenete látható. 4. TTCN-3 interfészek Egy futtatható TTCN-3 tesztsorozat a külvilágot interfészeken keresztül érheti el. Az ETSI két szabványban (TTCN-3 Runtime Interface, TRI [2] és TTCN-3 Control Interface, TCI [3]) hat ilyen interfészt definiált. A TRI két interfésze a tesztsorozatnak a tesztelendô rendszerrel illetve az operációs rendszerrel való kapcsolatát (pl. idôzítés) írja le. A TCI négy interfészbôl áll: tesztmenedzsment (tesztesetek futtatása és a tesztsorozat paraméterezése), kódolás és dekódolás, tesztkomponensek kezelése és naplózás. A szabványok programozási nyelvektôl független adattípusok és eljárások segítségével írják le az interfészeket, és ezekhez C, JAVA és néhol XML nyelvû leképzést adnak. Az interfészek szabványosításának célja, hogy az ezeknek megfelelô TTCN-3 futtatókörnyezetek egymással csereszabatosak legyenek. A TITAN a fenti szabványos interfészek közül jelenleg egyiket sem támogatja. Ennek több oka van: egyrészt amikor az interfész-szabványok 2002-ben és ban megjelentek, akkor a TITAN már egy kész, kiforrott rendszer volt a saját interfészeivel. Másrészt a fejlesztés során más szempontokat részesítettünk elônyben, mint a szabványosítók. Elsôdleges célunk az volt, hogy egy teljes, mûködôképes és hatékony tesztrendszert állítsunk elô úgy, hogy a felhasználónak a lehetô legkevesebb külsô programmodult kelljen a rendszerhez hozzáfejlesztenie. Így a TITAN egyedül a tesztelendô 2. ábra A grafikus felület 32 LXI. ÉVFOLYAM 2006/9
5 TITAN: TTCN-3 teszt végrehajtó környezet rendszer felé biztosít programozói felületet, ez pedig a tesztport-interfész. A TRI és TCI összes többi funkcióját a TITAN beépített módon támogatja, ezekhez nem biztosít programozói hozzáférést. A TITAN tesztport interfésze több szempontból is elônyösebb a TRI-nél. A tesztportok mindig egy TTCN-3 kommunikációs porthoz (és ezáltal egy protokollhoz) kapcsolódnak, így az egyidejûleg tesztelt többféle protokoll szétválasztásáról az interfész maga gondoskodik. TRI használata esetén a tesztelendô rendszer felé irányuló összes üzenet egyetlen függvényhíváson és a felhasználó által írt, úgynevezett adapter modulon halad keresztül, és a szétválogatást itt kell megoldani. Ha a tesztelésbe egy újabb protokollt vagy rendszer-interfészt akarunk bevonni, akkor ez a TITAN-ban építôkocka elven egy új tesztport hozzáadásával könnyen megoldható, míg TRI esetén ugyanez az adapter újratervezését jelenti. A tesztport interfész elosztott teljesítménytesztek esetén is kedvezôbb, ugyanis a TTCN-3 párhuzamos teszt komponensekhez kapcsolódó tesztportok nem okoznak szûk keresztmetszetet. A szabványos interfészek utólagos beépítése bizonyos esetekben nehézséget is okozhat, mert ezek a TITAN-nal ellentétben dinamikus tipizálást és többszálú mûködést feltételeznek. A TRI és TCI interfészei általában nem a hatékony mûködést preferálják, így ezek gyakorlati haszna is megkérdôjelezhetô a TITAN-ban. Használatukkal többnyire nem lehetne a TITAN beépített funkcióihoz képest gyorsabb, egyszerûbb vagy kényelmesebb megoldásokat elôállítani. Irodalom [1] ETSI ES V3.1.1 (06/2005) Part1: Core Language [2] ETSI ES V3.1.1 (06/2005) Part5: TTCN-3 Runtime Interface (TRI) [3] ETSI ES V3.1.1 (06/2005) Part6: TTCN-3 Control Interface (TCI) [4] Szabó János Zoltán: A TTCN-3 tesztleíró nyelv, Magyar Távközlés, XII. Évf., 2. szám, február [5] János Zoltán Szabó: Experiences of TTCN-3 Test Executor Development, Testing of Communicating Systems XIV, Application to Internet Technologies and Services, Edited by Ina Schieferdecker, Hartmut König and Adam Wolisz, Kluwer Academic Publishers, [6] János Zoltán Szabó: Performance Testing Architecture for Communication Protocols, Periodica Polytechnica, Electrical Engineering, Budapest University of Technology and Economics, / Összefoglalás A TITAN fejlesztése és használata révén az Ericsson is bekapcsolódott az ETSI TTCN-3 szabványosító munkájába. Aktivitásunkat jól mutatja, hogy a nyelv szabványához eddig összesen beküldött 340 db módosító javaslat (Change Request) több mint fele (196 db) az Ericssontól származik. Ezek többsége a nyelv leírásában talált kétértelmûségekre vagy ellentmondásokra ad feloldást, de számos olyan nyelvi kiterjesztést is javasoltunk, melyek a TTCN-3 használatát egyszerûbbé, kényelmesebbé teszik. A TITAN óta hivatalosan elfogadott és támogatott teszt eszköz az Ericssonban. Azóta az Ericsson Magyarország Kft-ben egy közel 40 fôs részleg foglalkozik a TITAN valamint a rá épülô TTCN-3 teszt megoldások (tesztportok, protokoll modulok és kész tesztsorozatok) fejlesztésével és karbantartásával. Megrendelôink az Ericsson termékfejlesztô részlegei a világ minden tájáról. Bár a TITAN a cégen kívül piaci forgalomba nem került, így is jelentôs és folyamatosan növekvô felhasználói táborra tett szert az elmúlt évek során. Közel 50 tesztport és csaknem 100 protokoll modul készült eddig a TITAN-hoz, mely lehetôséget nyújt a távközlési rendszerek széles spektrumának teszteléséhez. LXI. ÉVFOLYAM 2006/9 33
Feladat. Bemenő adatok. Bemenő adatfájlok elvárt formája. Berezvai Dániel 1. beadandó/4. feladat 2012. április 13. Például (bemenet/pelda.
Berezvai Dániel 1. beadandó/4. feladat 2012. április 13. BEDTACI.ELTE Programozás 3ice@3ice.hu 11. csoport Feladat Madarak életének kutatásával foglalkozó szakemberek különböző településen különböző madárfaj
XCZ állományok ellenőrzése, átadása elektronikus beküldésre és közvetlen beküldése parancssori funkcióval az ÁNYK programban
XCZ állományok ellenőrzése, átadása elektronikus beküldésre és közvetlen beküldése parancssori funkcióval az ÁNYK programban 1. XCZ állomány ellenőrzése és átadása elektronikus beküldésre 2. Nyomtatvány
ESZKÖZTÁMOGATÁS A TESZTELÉSBEN
ESZKÖZTÁMOGATÁS A TESZTELÉSBEN MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA, TURISZTIKA ÉS VENDÉGLÁTÁS TERÜLETEN
Rubin SPIRIT TEST. Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0. Készítette: Hajnali Krisztián Jóváhagyta: Varga József
Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0 Készítette: Hajnali Krisztián Jóváhagyta: Varga József Rubin Informatikai Zrt. 1149 Budapest, Egressy út 17-21. telefon: +361 469 4020; fax:
2011.11.29. JUnit. JUnit használata. IDE támogatás. Parancssori használat. Teszt készítése. Teszt készítése
Tartalom Integrált fejlesztés Java platformon JUnit JUnit használata Tesztelési technikák Demo 2 A specifikáció alapján teszteljük a program egyes részeit, klasszikus V-modell szerint Minden olyan metódust,
Iman 3.0 szoftverdokumentáció
Melléklet: Az iman3 program előzetes leírása. Iman 3.0 szoftverdokumentáció Tartalomjegyzék 1. Az Iman rendszer...2 1.1. Modulok...2 1.2. Modulok részletes leírása...2 1.2.1. Iman.exe...2 1.2.2. Interpreter.dll...3
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
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
Megoldás. Feladat 1. Statikus teszt Specifikáció felülvizsgálat
Megoldás Feladat 1. Statikus teszt Specifikáció felülvizsgálat A feladatban szereplő specifikáció eredeti, angol nyelvű változata egy létező eszköz leírása. Nem állítjuk, hogy az eredeti dokumentum jól
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
Programrendszerek tanúsítása szoftverminőség mérése
SZEGEDI TUDOMÁNYEGYETEM Programrendszerek tanúsítása szoftverminőség mérése Dr. Gyimóthy Tibor Dr. Ferenc Rudolf Szoftverminőség biztosítás Fő cél: az üzemelő IT rendszerekben csökkenteni a hibák számát
Interfészek. PPT 2007/2008 tavasz.
Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése 2 Már megismert fogalmak áttekintése Objektumorientált
Egy Erlang refaktor lépés: Függvényparaméterek összevonása tuple-ba
Egy Erlang refaktor lépés: Függvényparaméterek összevonása tuple-ba Témavezető: Horváth Zoltán és Simon Thompson OTDK 2007, Miskolc Egy Erlang refaktor lépés: Függvényparaméterek összevonása tuple-ba OTDK
Infokommunikációs protokollok
Infokommunikációs protokollok Dibuz Sarolta a műsz. tud. kandidátusa, PhD, egyetemi docens Ericsson Magyarország K+F Igazgatóság, BME Távközlési és Médiainformatikai Tanszék Sarolta.Dibuz@ericsson.com
Már megismert fogalmak áttekintése
Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése Eseménykezelési módszerek 2 Már megismert fogalmak
Integrációs mellékhatások és gyógymódok a felhőben. Géczy Viktor Üzletfejlesztési igazgató
Integrációs mellékhatások és gyógymódok a felhőben Géczy Viktor Üzletfejlesztési igazgató Middleware projektek sikertelenségeihez vezethet Integrációs (interfész) tesztek HIÁNYA Tesztadatok? Emulátorok?
Java I. A Java programozási nyelv
Java I. A Java programozási nyelv története,, alapvető jellemzői Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2007. 02. 12. Java I.: Történet, jellemzők, JDK JAVA1 / 1 Egy kis történelem
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ű
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
GPU Lab. 5. fejezet. A C++ fordítási modellje. Grafikus Processzorok Tudományos Célú Programozása. Berényi Dániel Nagy-Egri Máté Ferenc
5. fejezet A C++ fordítási modellje Grafikus Processzorok Tudományos Célú Programozása Kódtól a végrehajtásig Végrehajtás előtt valamikor létre kell jönnie az adott architektúrára jellemző bináris utasításoknak.
Digitális technika VIMIAA01 9. hét Fehér Béla BME MIT
BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM VILLAMOSMÉRNÖKI ÉS INFORMATIKAI KAR MÉRÉSTECHNIKA ÉS INFORMÁCIÓS RENDSZEREK TANSZÉK Digitális technika VIMIAA01 9. hét Fehér Béla BME MIT Eddig Tetszőleges
Digitális technika VIMIAA01 9. hét
BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM VILLAMOSMÉRNÖKI ÉS INFORMATIKAI KAR MÉRÉSTECHNIKA ÉS INFORMÁCIÓS RENDSZEREK TANSZÉK Digitális technika VIMIAA01 9. hét Fehér Béla BME MIT Eddig Tetszőleges
Magyar Nemzeti Bank - Elektronikus Rendszer Hitelesített Adatok Fogadásához ERA. Elektronikus aláírás - felhasználói dokumentáció
ERA Elektronikus aláírás - felhasználói dokumentáció Tartalomjegyzék 1. Bevezető... 3 1.1. Általános információk... 3 2. DesktopSign... 3 2.1. Általános információk... 3 2.2. Telepítés... 3 3. MNBSubscriber...
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ó
Grid menedzsment megoldás az ARC köztesrétegben
Grid menedzsment megoldás az ARC köztesrétegben Intézetünk az Új Magyarország Fejlesztési Terv TÁMOP 4.1.3[1] alprojektjének keretén belül dolgozott ki sikeresen egy jól működő megoldást egy olyan problémára,
GPU Lab. 4. fejezet. Fordítók felépítése. Grafikus Processzorok Tudományos Célú Programozása. Berényi Dániel Nagy-Egri Máté Ferenc
4. fejezet Fordítók felépítése Grafikus Processzorok Tudományos Célú Programozása Fordítók Kézzel assembly kódot írni nem érdemes, mert: Egyszerűen nem skálázik nagy problémákhoz arányosan sok kódot kell
SOA modell: Ez az interfész definiálja az elérhető adatokat, és megadja, hogy hogyan lehet azokhoz hozzáférni.
Service-Oriented Architecture, SOA Az elosztott rendszerek fejlesztésének módja. Célja:az IT eszközök komplexitásának a kezelésének egyszerűsítése könnyebben újrafelhasználhatóság, egymással integrálhatóság
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)
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)
OPENCV TELEPÍTÉSE SZÁMÍTÓGÉPES LÁTÁS ÉS KÉPFELDOLGOZÁS. Tanács Attila Képfeldolgozás és Számítógépes Grafika Tanszék Szegedi Tudományegyetem
OPENCV TELEPÍTÉSE SZÁMÍTÓGÉPES LÁTÁS ÉS KÉPFELDOLGOZÁS Tanács Attila Képfeldolgozás és Számítógépes Grafika Tanszék Szegedi Tudományegyetem OpenCV Nyílt forráskódú szoftver (BSD licensz) Számítógépes látás,
1. Mi a fejállományok szerepe C és C++ nyelvben és hogyan használjuk őket? 2. Milyen alapvető változókat használhatunk a C és C++ nyelvben?
1. Mi a fejállományok szerepe C és C++ nyelvben és hogyan használjuk őket? 2. Milyen alapvető változókat használhatunk a C és C++ nyelvben? 3. Ismertesse a névtér fogalmát! 4. Mit értünk a "változó hatóköre"
Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom
Szoftver újrafelhasználás (Software reuse) Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 18. Roger S. Pressman: Software Engineering, 5th e. chapter 27. 2 Szoftver újrafelhasználás Szoftver
ALKALMAZÁS KERETRENDSZER
JUDO ALKALMAZÁS KERETRENDSZER 2014 1 FELHASZNÁLÓK A cégvezetők többsége a dobozos termékek bevezetésével összehasonlítva az egyedi informatikai alkalmazások kialakítását költséges és időigényes beruházásnak
Tartalomjegyzék. Előszó... 10
Előszó... 10 1. Bevezetés a Symbian operációs rendszerbe... 11 1.1. Az operációs rendszer múltja...11 1.2. Az okos telefonok képességei...12 1.3. A Symbian felépítése...15 1.4. A könyv tartalma...17 2.
Technikai információk fejlesztőknek
Technikai információk fejlesztőknek Különbségek a Java-s nyomtatványkitöltő program és az Abev2006 között 1. A mezőkód kijelzés bekapcsolása a Szerviz/Beállítások ablakban érhető el. 2. Az xml állományok
Szilipet programok telepítése Hálózatos (kliens/szerver) telepítés Windows 7 operációs rendszer alatt
Szilipet programok telepítése Hálózatos (kliens/szerver) telepítés Windows 7 operációs rendszer alatt segédlet A Szilipet programok az adatok tárolásához Firebird adatbázis szervert használnak. Hálózatos
kodolosuli.hu: Interaktív, programozást tanító portál BALLA TAMÁS, DR. KIRÁLY SÁNDOR NETWORKSHOP 2017, SZEGED
kodolosuli.hu: Interaktív, programozást tanító portál BALLA TAMÁS, DR. KIRÁLY SÁNDOR NETWORKSHOP 2017, SZEGED A közoktatásban folyó informatika oktatásával kapcsolatos elvárások Állami szereplő: Az informatikaoktatás
Podoski Péter és Zabb László
Podoski Péter és Zabb László Bevezető Algoritmus-vizualizáció témakörében végeztünk kutatásokat és fejlesztéseket Felmértük a manapság ismert eszközök előnyeit és hiányosságait Kidolgoztunk egy saját megjelenítő
Fordító részei. Fordító részei. Kód visszafejtés. Izsó Tamás szeptember 29. Izsó Tamás Fordító részei / 1
Fordító részei Kód visszafejtés. Izsó Tamás 2016. szeptember 29. Izsó Tamás Fordító részei / 1 Section 1 Fordító részei Izsó Tamás Fordító részei / 2 Irodalom Izsó Tamás Fordító részei / 3 Irodalom Izsó
HORVÁTH ZSÓFIA 1. Beadandó feladat (HOZSAAI.ELTE) ápr 7. 8-as csoport
10-es Keressünk egy egész számokat tartalmazó négyzetes mátrixban olyan oszlopot, ahol a főátló alatti elemek mind nullák! Megolda si terv: Specifika cio : A = (mat: Z n m,ind: N, l: L) Ef =(mat = mat`)
1. Az Android platform bemutatása (Ekler Péter)... 1 1.1. Az Android sikerességének okai... 1 1.2. Az Android platform története... 3 1.3. Android-verziók... 5 1.4. Android Market (Google Play)... 13 1.5.
A konformancia- és együttmûködés-tesztelés bemutatása
A konformancia- és együttmûködés-tesztelés bemutatása KRÉMER PÉTER Ericsson Magyarország Kft., Test Competence Center Peter.Kremer@ericsson.com Kulcsszavak: együttmûködés-tesztelés, konformancia-tesztelés,
IP150 frissítés 4.20-ra
IP150 frissítés 4.20-ra Bevezető Ez a dokumentum az IP150 modul legfrissebb, v.4.20.008-ra történő frissítéséhez nyújt útmutatást. Kérjük, figyelmesen olvassa végig a sikeres frissítés érdekében. A 4.20.008
Flash és PHP kommunikáció. Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft
Flash és PHP kommunikáció Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft A lehetőségek FlashVars External Interface Loadvars XML SOAP Socket AMF AMFphp PHPObject Flash Vars Flash verziótól függetlenül
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
Programozási nyelvek (ADA)
Programozási nyelvek (ADA) Kozsik Tamás előadása alapján Készítette: Nagy Krisztián 1. előadás Hasznos weboldal http://kto.web.elte.hu Program felépítése Programegységek (program unit) eljárások (procedure)
Programozás alapjai Bevezetés
Programozás alapjai Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Programozás alapjai Bevezetés SWF1 / 1 Tartalom A gépi kódú programozás és hátrányai A magas szintÿ programozási nyelv fogalma
Selling Platform Telepítési útmutató Gyakori hibák és megoldások
Selling Platform Telepítési útmutató Gyakori hibák és megoldások 265ced1609a17cf1a5979880a2ad364653895ae8 Index _ Amadeus szoftvertelepítő 3 _ Rendszerkövetelmények 3 Támogatott operációs rendszerek 3
Selling Platform Telepítési útmutató Gyakori hibák és megoldások
Selling Platform Telepítési útmutató Gyakori hibák és megoldások 265ced1609a17cf1a5979880a2ad364653895ae8 Index _ Amadeus szoftvertelepítő 3 _ Rendszerkövetelmények 3 Támogatott operációs rendszerek 3
Tudásalapú információ-kereső rendszerek elemzése és kifejlesztése
Tudásalapú információ-kereső rendszerek elemzése és kifejlesztése 1 Tudásalapú információ-kereső rendszerek elemzése és kifejlesztése Természetes nyelv feldolgozás 2 Tudásalapú információ-kereső rendszerek
Név: Neptun kód: Pontszám:
Név: Neptun kód: Pontszám: 1. Melyek a szoftver minőségi mutatói? Fejlesztési idő, architektúra, programozási paradigma. Fejlesztőcsapat összetétele, projekt mérföldkövek, fejlesztési modell. Karbantarthatóság,
A Feldspar fordító, illetve Feldspar programok tesztelése
A Feldspar fordító, illetve Feldspar programok tesztelése [KMOP-1.1.2-08/1-2008-0002 társfinanszírozó: ERFA] Leskó Dániel Eötvös Loránd Tudományegyetem Programozási Nyelvek és Fordítóprogramok Tanszék
Mesterséges intelligencia alapú regressziós tesztelés
Mesterséges intelligencia alapú regressziós tesztelés Gujgiczer Anna, Elekes Márton* * AZ EMBERI ERŐFORRÁSOK MINISZTÉRIUMA ÚNKP-16-1-I. KÓDSZÁMÚ ÚJ NEMZETI KIVÁLÓSÁG PROGRAMJÁNAK TÁMOGATÁSÁVAL KÉSZÜLT
TERC V.I.P. hardverkulcs regisztráció
TERC V.I.P. hardverkulcs regisztráció 2014. második félévétől kezdődően a TERC V.I.P. költségvetés-készítő program hardverkulcsát regisztrálniuk kell a felhasználóknak azon a számítógépen, melyeken futtatni
Kommunikáció. 3. előadás
Kommunikáció 3. előadás Kommunikáció A és B folyamatnak meg kell egyeznie a bitek jelentésében Szabályok protokollok ISO OSI Többrétegű protokollok előnyei Kapcsolat-orientált / kapcsolat nélküli Protokollrétegek
Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.
Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.hu. 1 Tartalom 1. BEVEZETŐ... 3 1.1 Architektúra (terv) felülvizsgálat...
SZOFTVERFEJLESZTÉS. Földtudományi mérnöki mesterszak / Geoinformatikus-mérnöki szakirány. 2017/18 II. félév. A kurzus ebben a félévben nem indult
SZOFTVERFEJLESZTÉS Földtudományi mérnöki mesterszak / Geoinformatikus-mérnöki szakirány 2017/18 II. félév A kurzus ebben a félévben nem indult TANTÁRGYI KOMMUNIKÁCIÓS DOSSZIÉ Miskolci Egyetem Műszaki Földtudományi
Alkalmazások architektúrája
Alkalmazások architektúrája Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 13. Bass, Clements, Kazman: Software Architecture in Practice, Addison- Wesley, 2004 2 Alkalmazás típusok Adat
Programzás I. - 1. gyakorlat
Programzás I. - 1. gyakorlat Alapok Tar Péter 1 Pannon Egyetem Műszaki Informatikai Kar Számítástudomány Alkalmazása Tanszék Utolsó frissítés: September 15, 2007 1 tar@dcs.vein.hu Tar Péter (PE-MIK-DCS)
Modellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK
Modellinformációk szabványos cseréje Papp Ágnes, agi@delfin.unideb.hu Debreceni Egyetem EFK Tartalom MOF, UML, XMI Az UML és az XML séma MDA - Model Driven Architecture Networkshop 2004 2 Az OMG metamodell
PTE-PROXY VPN használata, könyvtári adatbázisok elérhetősége távolról
PTE-PROXY VPN használata, könyvtári adatbázisok elérhetősége távolról Az Informatikai Igazgatóság minden aktív egyetemi hallgató és munkaviszonnyal rendelkező egyetemi dolgozó részére úgynevezett proxy
Internet programozása. 1. előadás
Internet programozása 1. előadás Áttekintés 1. Mi a PHP? 2. A PHP fejlődése 3. A PHP 4 újdonságai 4. Miért pont PHP? 5. A programfejlesztés eszközei 1. Mi a PHP? Egy makrókészlet volt, amely személyes
Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata
Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata jelentése: gyors, fürge 1990-es évek vége Változás igénye Módszertan-család
Univerzális munkafolyamat szimulátor
Univerzális munkafolyamat szimulátor Ütemterv Készítette: Kerek Róbert KERQABT.SZE Gazdaságinformatikus BSc III. évfolyam Külső témavezető Kesztyűs Attila Lajos Siemens PSE Kft. Belső konzulens Dr. Ferenc
Intelligens biztonsági megoldások. Távfelügyelet
Intelligens biztonsági megoldások A riasztást fogadó távfelügyeleti központok felelősek a felügyelt helyszínekről érkező információ hatékony feldolgozásáért, és a bejövő eseményekhez tartozó azonnali intézkedésekért.
1. Bevezetés szeptember 9. BME Fizika Intézet. Szám. szim. labor ea. Tőke Csaba. Tudnivalók. feladat. Tematika. Moodle Házi feladatok
Számítógépes szimulációk 1. Bevezetés BME Fizika Intézet 2015. szeptember 9. Bevezetés A félév menete C-ismétlés, 1. rész Oktatók: Nagyfalusi Balázs: nagyfalusi@phy.bme.hu, F3 211. : tcsaba@eik.bme.hu,
Adatszerkezetek Tömb, sor, verem. Dr. Iványi Péter
Adatszerkezetek Tömb, sor, verem Dr. Iványi Péter 1 Adat Adat minden, amit a számítógépünkben tárolunk és a külvilágból jön Az adatnak két fontos tulajdonsága van: Értéke Típusa 2 Adat típusa Az adatot
SQUID. Forrás:
Forrás: http://www.squid-cache.org/ http://www.szabilinux.hu/squid/ http://www.lok.hu Mi a Squid? Proxy: kliens kérést továbbít. Lehet transzparens átlátszó proxy Cache: átmeneti tároló, gyorsítás céljából
Objektum orientáltság alapjai A Java nyelv Fordítás - futtatás
Objektum orientáltság alapjai A Java nyelv Fordítás - futtatás Objektum orientáltság alapjai Objektum: A való világ egy elemének ábrázolása, amely minden esetben rendelkezik: Állapottal,Viselkedéssel,Identitással
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
Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem
A Java EE 5 platform Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2008. 04. 17. A Java EE 5 platform A Java EE 5 plattform A J2EE 1.4 után következő verzió. Alapvető továbbfejlesztési
Az MTA Cloud a tudományos alkalmazások támogatására. Kacsuk Péter MTA SZTAKI
Az MTA Cloud a tudományos alkalmazások támogatására Kacsuk Péter MTA SZTAKI Kacsuk.Peter@sztaki.mta.hu Tudományos alkalmazások és skálázhatóság Kétféle skálázhatóság: o Vertikális: dinamikusan változik
Programozási alapismeretek 1. előadás
Programozási alapismeretek 1. előadás Tartalom A problémamegoldás lépései programkészítés folyamata A specifikáció Az algoritmus Algoritmikus nyelvek struktogram A kódolás a fejlesztői környezet 2/33 A
Közösség, projektek, IDE
Eclipse Közösség, projektek, IDE Eclipse egy nyílt forráskódú (open source) projekteken dolgozó közösség, céljuk egy kiterjeszthető fejlesztői platform és keretrendszer fejlesztése, amely megoldásokkal
Új generációs informatikai és kommunikációs megoldások ANMS. távközlési hálózatok informatikai hálózatok kutatás és fejlesztés gazdaságos üzemeltetés
Új generációs informatikai és kommunikációs megoldások ANMS távközlési hálózatok informatikai hálózatok kutatás és fejlesztés gazdaságos üzemeltetés ANMS Távközlési szolgáltatók számára Az ANMS egy fejlett
Programozási alapismeretek beadandó feladat: ProgAlap beadandó feladatok téma 99. feladat 1
Programozási alapismeretek beadandó feladat: ProgAlap beadandó feladatok téma 99. feladat 1 Készítette: Gipsz Jakab Neptun-azonosító: A1B2C3 E-mail: gipszjakab@vilaghalo.hu Kurzuskód: IP-08PAED Gyakorlatvezető
Tájékoztató. Használható segédeszköz: számológép
A 12/2013. (III. 29.) NFM rendelet szakmai és vizsgakövetelménye alapján. Szakképesítés azonosítószáma és megnevezése 54 523 05 Távközlési technikus Tájékoztató A vizsgázó az első lapra írja fel a nevét!
Algoritmizálás és adatmodellezés tanítása beadandó feladat: Algtan1 tanári beadandó /99 1
Algoritmizálás és adatmodellezés tanítása beadandó feladat: Algtan1 tanári beadandó /99 1 Készítette: Gipsz Jakab Neptun-azonosító: ABC123 E-mail: gipszjakab@seholse.hu Kurzuskód: IT-13AAT1EG 1 A fenti
Kinek szól a könyv? A könyv témája A könyv felépítése Mire van szükség a könyv használatához? A könyvben használt jelölések. 1. Mi a programozás?
Bevezetés Kinek szól a könyv? A könyv témája A könyv felépítése Mire van szükség a könyv használatához? A könyvben használt jelölések Forráskód Hibajegyzék p2p.wrox.com xiii xiii xiv xiv xvi xvii xviii
Bevezetés a Python programozási nyelvbe
Bevezetés a Python programozási nyelvbe 8. Gyakorlat modulok random számok (utolsó módosítás: 2017. aug. 3.) Szathmáry László Debreceni Egyetem Informatikai Kar 2017-2018, 1. félév Modulok Amint a programunk
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,
Webes alkalmazások fejlesztése
Webes alkalmazások fejlesztése 3. gyakorlat Authentikáció, adatok feltöltése Szabó Tamás (sztrabi@inf.elte.hu) - sztrabi.web.elte.hu Authentikáció Manapság már elvárás, hogy a felhasználó regisztrálni
Fordítóprogramok. Aszalós László. 2009. szeptember 7.
Fordítóprogramok Aszalós László 2009. szeptember 7. 1. Bemelegítés Honlap: www.inf.unideb.hu/ aszalos/diak.html (Fordítóprogramok, 2009) Jegymegajánló: utolsó hét előadásán. PótZH (csak gyakorlat) vizsgaidőszak
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
iphone és Android két jó barát...
iphone és Android két jó barát... Multiplatform alkalmazásfejlesztés a gyakorlatban Kis Gergely MattaKis Consulting 1 Tartalom Miért multiplatform fejlesztés? Multiplatform fejlesztési módszerek A közös
UNIX: folyamatok kommunikációja
UNIX: folyamatok kommunikációja kiegészítő fóliák az előadásokhoz Mészáros Tamás http://home.mit.bme.hu/~meszaros/ Budapesti Műszaki Egyetem Méréstechnika és Információs Rendszerek Tanszék 1 A kommunikáció
Parametrikus tervezés
2012.03.31. Statikus modell Dinamikus modell Parametrikus tervezés Módosítások a tervezés folyamán Konstrukciós variánsok (termékcsaládok) Parametrikus Modell Parametrikus tervezés Paraméterek (változók
Szoftver labor III. Tematika. Gyakorlatok. Dr. Csébfalvi Balázs
Szoftver labor III. Dr. Csébfalvi Balázs Irányítástechnika és Informatika Tanszék e-mail: cseb@iit.bme.hu http://www.iit.bme.hu/~cseb/ Tematika Bevezetés Java programozás alapjai Kivételkezelés Dinamikus
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
Vizuális, eseményvezérelt programozás XI.
Vizuális, eseményvezérelt programozás XI ÓE-NIK, 2011 1 Hallgatói tájékoztató A jelen bemutatóban található adatok, tudnivalók és információk a számonkérendő anyag vázlatát képezik Ismeretük szükséges,
A Java EE 5 plattform
A Java EE 5 platform Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2007. 11. 13. A Java EE 5 platform A Java EE 5 plattform A J2EE 1.4 után következő verzió. Alapvető továbbfejlesztési
Az iskolai rendszerű képzésben az összefüggő szakmai gyakorlat időtartama. 10. évfolyam Adatbázis- és szoftverfejlesztés gyakorlat 50 óra
Az iskolai rendszerű képzésben az összefüggő szakmai gyakorlat időtartama 10. évfolyam: 105 óra 11. évfolyam: 140 óra 10. évfolyam Adatbázis- és szoftverfejlesztés gyakorlat 50 óra 36 óra OOP 14 óra Programozási
és az instanceof operátor
Java VIII. Az interfacei és az instanceof operátor Krizsán Zoltán Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2005. 10. 24. Java VIII.: Interface JAVA8 / 1 Az interfészről általában
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN
Java VIII. Az interfacei. és az instanceof operátor. Az interfészről általában. Interfészek JAVA-ban. Krizsán Zoltán
Java VIII. Az interfacei és az instanceof operátor Krizsán Zoltán Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2005. 10. 24. Java VIII.: Interface JAVA8 / 1 Az interfészről általában
Unit Teszt. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) Unit Teszt / 22
Unit Teszt Tóth Zsolt Miskolci Egyetem 2013 Tóth Zsolt (Miskolci Egyetem) Unit Teszt 2013 1 / 22 Tartalomjegyzék 1 Bevezetés 2 Unit Teszt 3 Példa Tóth Zsolt (Miskolci Egyetem) Unit Teszt 2013 2 / 22 Szoftvertesztelés
E-Freight beállítási segédlet
E-Freight beállítási segédlet Az E-Freight rendszer működéséhez szükséges programok és beállítások v08 A legújabb verzióért kérjük, olvassa be az alábbi kódot: 1. Támogatott böngészők Az E-Freight az Internet
IDAXA-PiroSTOP. PIRINT PiroFlex Interfész. Terméklap
IDAXA-PiroSTOP PIRINT PiroFlex Interfész Terméklap Hexium Kft. PIRINT Terméklap Rev 2 2 Tartalomjegyzék. ISMERTETŐ... 3 2. HARDVER... 4 2. LED... 5 2.2 KAPCSOLAT A VKGY GYŰRŰVEL... 6 2.3 CÍMBEÁLLÍTÁS...
Statikus technikák: A szoftver átvizsgálása. Statikus technikák: A szoftver átvizsgálása 2011.04.25.
Dr. Mileff Péter A V & V tervezési folyamatoknak egyensúlyt kell kialakítani a verifikáció és a validációstatikus és dinamikus technikái között. 1 2 Statikus technikák: A szoftver átvizsgálása A szisztematikus