Szoftverprototípus készítése. Szoftverprototípus készítése. Szoftverprototípus készítése
|
|
- György Fazekas
- 8 évvel ezelőtt
- Látták:
Átírás
1 Szoftverprototípus készítése Dr. Mileff Péter A prototípus fogalma: a szoftverrendszer kezdeti verziója Mi a célja? Arra használják, hogy bemutassák a koncepciókat, kipróbálják a tervezési opciókat, jobban megismerjék a problémát és annak lehetséges megoldásait. A prototípus gyors, iteratív fejlesztése azért nagyon fontos, mert a költségek így ellenőrizhetők. 1 2 Szoftverprototípus készítése A szoftverprototípus több helyen is használható a fejlesztés folyamatában: 1. A követelménytervezés folyamatában. 2. A rendszertervezési folyamatban. 3. A tesztelési folyamatban. A követelmény fázisban: a prototípus fejlesztése alatt fény derülhet a követelményekkel kapcsolatos lehetséges hibákra, esetleg új ötletek kapcsán új rendszerkövetelményeket is indítványozhatnak. Szoftverprototípus készítése A rendszertervezési folyamatban: a rendszerprototípus felhasználható a tervezési tapasztalatok alkalmazására, illetve a javasolt terv megvalósíthatóságának felülvizsgálatára. Pl.: a gyors prototípus készítés az egyetlen módja annak, hogy a felhasználók bevonásával grafikus felhasználói felületeket fejlesszünk ki
2 Szoftverprototípus készítése A rendszertesztelés fázisában: a prototípusok segítségével az eredmények ellenőrzéséhez szükséges munka visszacsatoló teszteksegítségével csökkenthető. Ilyenkor ugyanazokra a tesztesetekre futtatjuk a prototípust és a rendszert. Ha mindkét rendszer ugyanazt az eredményt adja, akkor a teszteset valószínűleg nem talált hibát. Szoftverprototípus készítése A prototípuskészítés rendszerint a szoftverfolyamat korai szakaszában növeli a költségeket, később viszont jelentősen csökkenti, mert elkerülhetők az újraírási munkák. A prototípuskészítés folyamata négykülönböző fázissal írható le: A prototípus céljainak megállapítása A prototípus funkcionalitásának definiálása A prototípus fejlesztése A prototípus kiértékelése 5 6 A négy fázis 1. A prototípuskészítés céljait érdemes az elején írásban megadni, e nélkül a vezetés vagy a végfelhasználók félreérthetik a rendeltetését. Ilyen cél lehet: az alkalmazás megvalósíthatóságának demonstrálása vagy a felhasználói felületek bemutatása, stb. Ugyanaz a prototípus nem szolgálhatja az összes célt. 2. Annak eldöntése, hogy mit tegyünk bele a prototípusba. 3. Prototípus kifejlesztése 4. A kiértékelés Gondoskodni kell a felhasználók képzéséről: Időbe telik, amíg megszokják az új rendszert csak ezután fedezhetik fel a követelménybeli hibákat és hiányosságokat. A két fő típus Két fő típusa: evolúciós és az eldobható. Az evolúciós prototípus célja: Egy működő rendszer átadása a végfelhasználóknak. Ezért a legjobban megértett és leginkább előtérbe helyezett követelményekkel kezd. Kevésbé fontos és körvonalazatlanabb követelmények: akkor kerülnek megvalósításra, amikor a felhasználók kérik. A módszer a weblapfejlesztés és az e-kereskedelmi alkalmazások szokásos technikája
3 A két fő típus Az eldobható prototípus célja: jobban megértsük a megrendelő igényeit. a rendszerkövetelmények validálásavagy származtatása. A nem jól megértett követelményekkel érdemes kezdeni, mivel azokról szeretnénk többet megtudni Bevezetés A szoftvertervezés lényege:a szoftver logikai szerkezetére vonatkozó döntések meghozatala. Célszerű: bizonyos esetekben a logikai szerkezetet modellezőnyelv segítségévei ábrázolni Pl.: amilyen az UML (Unified Modeling Language). Más esetekben: a tervet informális jelölésrendszerrel leírt vázlatokkal reprezentáljuk
4 Architektúrális tervezés A nagy rendszereket alrendszerekre bontják, amelyek biztosítják az egymással kapcsolatban lévő szolgáltatásokat. Architektúrálistervezés: ezen alrendszerek azonosításának és az alrendszer vezérlésére és kommunikációjára szolgáló keretrendszer létrehozásának kezdeti tervezési folyamata. 13 Architektúrális tervezés Kreatív folyamat: ahol megpróbálunk előállítani egy rendszerszerkezetet: amely megfelel a funkcionális és nem funkcionális rendszerkövetelményeknek. A rendszer architektúrája befolyásolja: a rendszer teljesítményét, robusztusságát, eloszthatóságát és karbantarthatóságát. Ezért fontos: a szoftvertervezőket rákényszerítsük arra, hogy a tervezés kulcsfontosságú aspektusaival már a folyamat korai szakaszában foglalkozzanak. 14 Architektúrális tervezés Az alkalmazás számára választott szerkezet: Függhet nem funkcionális rendszerkövetelményektől is. Pl.: teljesítmény, védettség, biztonságosság, rendelkezésre állás, és karbantarthatóság. Magában foglalja a rendszerek alrendszerekre bontását is: Az alrendszerek tervezése a rendszer durva szemcsézettségű komponensekre történő absztrakt felbontása, Ezen komponensek lehetnek önálló rendszerek. Az alrendszerek terveit általában blokkdiagram segítségével írjuk le. Tervezési döntések A tervezési folyamat során a rendszer tervezőinek számos döntést kell meghozniuk. amelyek alapvetően kihatnak a rendszerre és a fejlesztési folyamatra. Fontosabb felmerülő kérdések: 1. Létezik-e olyan általános alkalmazás architektúra, amely a tervezendő rendszer számára mintául szolgálhat? 2. Hogyan osztjuk szét a rendszert gépekre? 3. Milyen architektúrálisstílus lenne a rendszer számára megfelelő?
5 Tervezési döntések Tervezési döntések eredménye 4. Milyen alapvető megoldásokat alkalmazunk a rendszer strukturálására? 5. Hogyan lehet a rendszer szerkezeti egységeit modulokra felbontani? 6. Milyen stratégiát kell alkalmazni az egységek működésének vezérlésével kapcsolatban? 7. Hogyan értékelik majd ki az architektúrális tervet? 8. Hogyan kell a rendszer-architektúrát dokumentálni? A folyamat eredménye: egy architektúrális tervezési dokumentum Miket tartalmaz: A rendszer grafikus reprezentációit, és a hozzájuk kapcsolódó leíró szöveget. Annak a leírását, hogy a rendszert hogyan lehet alrendszerekre bontani, az egyes alrendszerek miképpen oszthatók modulokra Architektúrálismodellek 1. Statikus szerkezeti modell: megmutatja, hogyan lehet az alrendszereket és komponenseket különálló egységként fejleszteni. 2. Dinamikus folyamatmodell:ábrázolja, hogy a rendszer hogyan szervezhető futási idejű folyamatokba. Ez különbözhet a statikus modelltől. 3. Interfészmodell:az alrendszerek által publikus interfészeiken keresztül nyújtott szolgáltatásait írja le. 4. Kapcsolatmodellek:az alrendszerek közötti kapcsolatokat (például adatáramlás) mutatják be. 5. Elosztásimodell:azt adja meg, hogy az egyes alrendszereket hogyan kell elosztani a számítógépek között. A rendszer-architektúrák leírása: számos kutató az architektúra leíró nyelvek (architecturaldescriptionlanguages, ADL) használatát és az UML nyelvet javasolja. A rendszer felépítése A rendszer felépítését számos modell segítségével írhatjuk le. Pl.: Tárolási modell Kliens szerver modell Rétegzett modell Szolgáltatás orientált architektúra (SOA) Webszolgáltatások Egyéb
6 Moduláris felbontás 21 A teljes rendszer-architektúra kiválasztásra után, dönteni kell az alrendszerek modulokra bontásasorán alkalmazott megközelítésről. Az alrendszerek és modulok nem különböztethetők meg egyértelműen! Egy elképzelés: Alrendszer:egy olyan önálló rendszer, amely működése nem függ más alrendszerek szolgáltatásaitól. Az alrendszerek modulokból épülnek fel. Modul:olyan rendszerkomponens, amely más modulok számára szolgáltatás(oka)t biztosít. 22 Moduláris felbontás Az alrendszerek modulokra bontása során két fő stratégia ismeretes: 1. Objektumorientált felbontással a rendszert egymással kommunikáló objektumok halmazára bontjuk fel. 2. Funkcióorientált csővezetékekhasználatával a rendszert funkcionális modulokra bontjuk. bemenő adatokat fogadnak el és azokat kimenő adatokká alakítják. 23 Objektumorientált felbontás Az OO architekturális modell jellemzői: a rendszert lazán kapcsolódó, jól definiált interfészekkel rendelkező objektumok halmazára tagolja. Az objektumok a többi objektum által biztosított szolgáltatásokat hívják. Az OO felbontás: objektumosztályokkal, azok attribútumaival és műveleteivel foglalkozik. Implementációkor az objektumok ezekből az osztályokból jönnek létre, és az objektum műveleteinek koordinálásához valamilyen vezérlési modellt alkalmaznak. 24 6
7 Objektumorientált felbontás Objektumorientált felbontás Az OO megközelítés előnye: az objektumok lazán kapcsolódnak így az objektumok implementációja változtatható anélkül, hogy az hatással lenne más objektumokra. A komponensek közvetlen implementációjának biztosítására objektumorientált programozási nyelveket fejlesztettek ki. Pl.: C++, D, Objective Pascal, Java, stb. Hátránya: az objektumoknak explicit módon kell hivatkoznia a többi objektum nevére és interfészére. Ha a rendszerben interfész változtatás történt, akkor a változtatást minden, a megváltozott objektumot használó helyen át kell vezetni Vezérlési stílusok Ahhoz, hogy az alrendszerek rendszerként működjenek, vezérelni kell őket. hogy szolgáltatásaik a megfelelő helyre a megfelelő időben eljussanak. A strukturális modellek nem tartalmaznak ilyen elemeket ezért a rendszer kiépítőjének az alrendszereket valamilyen vezérlési modellnek megfelelően kell szerveznie. A vezérlési modellek az alrendszerek közötti vezérlési folyamatokkal foglalkoznak
8 Vezérlési stílusok 1. Központosított vezérlés:a vezérlés teljes felelősségét egyetlen alrendszer látja el, amely beindítja és leállítja a többi alrendszert. 2. Eseményalapú vezérlés:a vezérlési információ nincs egyetlen alrendszerbe ágyazva minden alrendszer válaszolhat egy külsőleg létrejött eseményre. Ezek az események vagy más alrendszerekből, vagy a rendszer környezetéből származhatnak. A vezérlési stílusok kiegészítik a strukturális stílusokat. Minden korábban bemutatott strukturális stílust meg lehet valósítani mindkét vezérléssel egyaránt. Központosított vezérlés A központosított vezérlési modellben létezik egy kitüntetett alrendszer: a rendszervezérlő, A többi alrendszer végrehajtásáért felelős. A központosított vezérlési modellek két csoportba oszthatók: attól függően, hogy a vezérelt alrendszerek szekvenciálisanvagy párhuzamosan hajtódnak-e végre Központosított vezérlés A hívásvisszatérés modell 1. A hívás-visszatérés modell: A megszokott fentről le alprogram modellje: ahol a vezérlés az alprogram-hierarchia csúcsán kezdődik és alprogramhívások segítségével jut el a fa alsóbb szintjeire. Ez a modell csak szekvenciális rendszerek esetén alkalmazható. A vezérlés a hierarchiában magasabb szintű rutintól jut el az alacsonyabb szinten lévőhöz, majd visszatér a hívás helyére
9 A hívásvisszatérés modell Központosított vezérlés A modell modulszinten használható a tevékenységek és objektumok vezérlésére, mert az OO rendszerben az objektumok műveletei eljárásként vagy függvényként vannak implementálva. A modell merev és korlátozott természete egyben előny és hátrány is. Erősségea vezérlési folyam elemzésének és bizonyos bemenet esetén a rendszer válasza kiszámíthatóságának viszonylagos egyszerűsége. Hátránya, hogy a normálistól eltérő működés esetén használata kényelmetlen. 2. A kezelőmodell: Konkurens és szekvenciális rendszerekre is alkalmazható. Egy kijelölt rendszerkezelő rendszerkomponens irányít: a többi rendszerfolyamat indítását, leállítását, valamint koordinálja azokat. Követelmény:egy folyamat olyan alrendszer vagy modul, amely végrehajtható más folyamatokkal párhuzamosan A kezelőmodell működése A rendszert vezérlő folyamat a rendszer állapotváltozói alapján dönt: az egyes folyamatokat mikor kell elindítani, illetve leállítani. Ellenőrzi: hogy a többi folyamat hozott-e létre feldolgozandó vagy feldolgozásra továbbküldendő információt. A vezérlő ciklikusan ellenőrzi az érzékelőket és folyamatokat, bekövetkezett-e valamilyen esemény vagy állapotváltozás. Éppen ezért ezt a modellt eseményciklus-modellnekis szokás nevezni
10 Eseményvezérelt rendszerek Az eseményvezérelt vezérlési modelleket külsőleg létrehozott események irányítják. Az eseményvezérelt rendszereknek sok fajtája ismeretes, beleértve a szerkesztőket, ahol a szerkesztő utasításokat felhasználói felület események jelzik. 1. Eseményszóró modellek 2. Megszakítás-vezérelt modellek Eseményvezérelt rendszerek Eseményszóró modellek: egy esemény minden alrendszerhez eljut, és bármelyik, az esemény kezelésére programozott alrendszer reagálhat rá. A vezérlési politika nincs beépítve az esemény-és üzenetkezelőbe. Az alrendszerek eldöntik, hogy mely eseményekre tartanak igényt, az esemény-és üzenetkezelő pedig biztosítja, hogy ezek az események eljussanak hozzájuk Eseményvezérelt rendszerek Megszakítás-vezérelt modellek: Kizárólag valós idejű rendszerekben használják ahol egy megszakítás-kezelő észleli a külső megszakításokat. Ezek aztán valamely más komponenshez kerülnek feldolgozásra
11 Objektumorientált tervezés Egy OO rendszer egymással együttműködő objektumokból áll, ahol az objektum saját állapotát karbantartja és erről az állapotról információs műveleteket biztosít. Az állapot reprezentációja privát, az objektumon kívülről közvetlenül nem hozzáférhető. Az OO tervezési folyamat: az objektumosztályoknak és az azok közötti kapcsolatoknak a megtervezéséből áll. 41 Objektumorientált tervezés Az OO tervezés az OO fejlesztés része a fejlesztési folyamat során objektumorientált stratégiát használunk: 1. Objektumorientált elemzés:a szoftver objektumorientált modelljének elemzésével foglalkozik. 2. Objektumorientált tervezés: a meghatározott követelményeknek megfelelő szoftverrendszer OO modelljének kialakítása. 3. Objektumorientált programozás: a szoftverterv objektumorientált programozási nyelven történő megvalósítása. Pl.: C++, D, Java. 42 Objektumorientált tervezés A különböző lépések közötti átmenetnek észrevehetetlennek kell lennie, Mindegyik lépésben kompatibilis jelölésrendszert kell használni. Az OO rendszereket a más elven fejlesztett rendszerekkel szemben könnyebb megváltoztatni, mert az objektumok egymástól függetlenek. Objektumorientált tervezés Egy objektum implementációjának megváltozása vagy új szolgáltatásokkal történő bővülése nem befolyásolhatja a rendszer többi objektumát. Ezért azt mondhatjuk, hogy az objektumok potenciálisan újrafelhasználható komponensek, mivel az állapotnak és a műveleteknek független egységbe zárásai. Ez növeli az érthetőséget és így a terv karbantarthatóságát is
12 Objektumok és objektumosztályok Objektumok és objektumosztályok Ian Sommerville féle objektum definíció: Egy objektum egy állapottal és az ezen az állapoton ható, meghatározott műveletekkel rendelkező entitás. Az állapotot objektum-attribútumok halmazaként adjuk meg. Az objektum műveletei szolgáltatásokat biztosítanak a többi objektum számára. Az objektumok egy objektumosztály-definíció alapján jönnek létre. Egy objektumosztály definíciója egyszerre típusspecifikáció és egy objektumok létrehozására szolgáló sablon. Az adott osztályba tartozó objektummal kapcsolatos összes attribútum és művelet deklarációját tartalmazza UML-ben megadott osztálydefiníció Objektumok és objektumosztályok Az objektumok kommunikációja: szolgáltatásokat kérnek más objektumoktól (meghívják azok módszereit). A szolgáltatás végrehajtásához szükséges információ és a szolgáltatás végrehajtásának eredményei paraméterként adódnak át. Pl.: Az Alkalmazott objektumosztály 47 // Egy puffer objektum módszerének hívása, amely visszaadja a pufferben található következő értéket v = Buffer.GetNextElement(); // Puffer elemszámának a beállítása v = Buffer.SetElements(20); 48 12
13 Szolgáltatás igénylése Egy objektum szolgáltatáskérés üzenetet küldhet egy másiknak, akitől a szolgáltatást kéri. A fogadóobjektum: elemzi az üzenetet azonosítja a szolgáltatást és az ahhoz kapcsolódó adatokat, majd végrehajtja a kívánt szolgáltatást. Ha a szolgáltatáskérelmek ily módon vannak implementálva, az objektumok közötti kommunikáció szinkron, azaz a hívóobjektum megvárja a szolgáltatás befejeződését (soros végrehajtás). A gyakorlatban a legtöbb objektum-orientált nyelvben ez a modell az alapértelmezett. Objektumok és objektumosztályok Az újabb OOP nyelvekben (pl. JAVA,) azonban léteznek a szálak, amelyek megengedik a konkurens módon végrehajtódó objektumok létrehozását és az aszinkron kommunikációt (a hívóobjektum folytatja a működését az általa igényelt szolgáltatás futása alatt is). Ezek a konkurens objektumok kétféleképpen implementálhatók: Aktív objektumok vagy Szerverek Objektumok és objektumosztályok 1. Aktív objektumok: önmaguk képesek belső állapotukat megváltoztatni és üzenetet küldeni, anélkül, hogy más objektumtól vezérlőüzenetet kaptak volna. (Ellentétük a passzív objektum.) Az aktív objektumot reprezentáló folyamat ezeket a műveleteket folyamatosan végrehajtja, így soha nem függesztődik fel. Objektumok és objektumosztályok 2. Szerverek: az objektum a megadott szolgáltatásokkal rendelkező párhuzamos folyamat. Az eljárások egy külső üzenetre válaszolva indulnak el és más objektumok eljárásaival párhuzamosan futhatnak. Mikor befejezték a tevékenységüket, az objektum várakozó állapotba kerül és további kéréseket vár
14 Szerverek alkalmazásai Aktív objektumok alkalmazásai A szervereket leginkább osztott környezetben érdemes használni ahol a hívó és a hívott objektum különböző számítógépeken hajtódik végre. Az igényelt szolgáltatásra adott válaszidő megjósolhatatlan úgy kell megtervezni a rendszert, hogy a szolgáltatást igénylő objektumnak ne kelljen megvárni a szolgáltatás befejeződését. A szerverek persze egyedi gépen is használhatók ahol a szolgáltatás befejeződéséhez némi időre van szükség pl. nyomtatás Aktív objektumokat akkor célszerű használni ha egy objektumnak saját állapotát megadott időközönként frissíteni kell. Ez valós idejű rendszerekben gyakori az objektumok ott a rendszer környezetéről információt gyűjtő hardvereszközökkel állnak kapcsolatban Objektumok és objektumosztályok Az objektumosztályok egy generalizációsvagy öröklődési hierarchiába szervezhetők, az általános és a specifikus objektumosztályok közötti kapcsolatot jeleníti meg. A hierarchiában a lejjebb található osztályok: rendelkeznek ugyanazokkal az attribútumokkal és műveletekkel, mint szülőosztályaik, de új attribútumokkal és műveletekkel egészítheti ki azokat, valamint meg is változtathatják szülőosztályaik attribútumainak és műveleteinek némelyikét. Objektumok élettartalma Egy objektum belső állapotát az attribútumainak pillanatnyi értéke határozza meg. Perzisztensobjektumok: A háttértárolón azon objektumok adatait kell tárolni, amelyek élettartama hosszabb, mint a program futási ideje. Tranziens objektumok: Azon objektumok, amelyek élettartama a program futási idejénél nem hosszabb. Ha a program nagyszámú perzisztensobjektummal dolgozik, érdemes egy adatbázis-kezelő rendszerrel kiegészíteni
15 57 15
Objektumorientált felbontás
Objektumorientált felbontás Dr. Mileff Péter Az OO architekturális modell jellemzői: a rendszert lazán kapcsolódó, jól definiált interfészekkel rendelkező objektumok halmazára tagolja. Az objektumok a
RészletesebbenSzoftverprototípus készítése
Dr. Mileff Péter 1 Szoftverprototípus készítése A prototípus fogalma: a szoftverrendszer kezdeti verziója Mi a célja? Arra használják, hogy bemutassák a koncepciókat, kipróbálják a tervezési opciókat,
RészletesebbenBánsághi Anna anna.bansaghi@mamikon.net. 1 of 67
SZOFTVERTECHNOLÓGIA Bánsághi Anna anna.bansaghi@mamikon.net 5. ELŐADÁS - RENDSZERTERVEZÉS 1 1 of 67 TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK IV. RENDSZERARCHITEKTÚRÁK
RészletesebbenElőzmények 2011.10.23.
Előzmények Dr. Mileff Péter A 80-as évek közepétől a szoftverek komplexitása egyre növekszik. Megjelentek az OO nyelvek. Az OO fejlesztési módszerek a rendszer különböző nézőpontú modelljeit készítik el.
RészletesebbenA SZOFTVERTECHNOLÓGIA ALAPJAI
A SZOFTVERTECHNOLÓGIA ALAPJAI Objektumorientált tervezés 8.előadás PPKE-ITK Tartalom 8.1 Objektumok és objektumosztályok 8.2 Objektumorientált tervezési folyamat 8.2.1 Rendszerkörnyezet, használati esetek
RészletesebbenIsmeretanyag Záróvizsgára való felkészüléshez
Ismeretanyag Záróvizsgára való felkészüléshez 1. Információmenedzsment az információmenedzsment értelmezése, feladatok különböző megközelítésekben informatikai szerepek, informatikai szervezet, kapcsolat
RészletesebbenAz objektumorientált megközelítés elınye: Hátránya:
1 Egy objektumorientált architekturális modell a rendszert lazán kapcsolódó, jól definiált interfészekkel rendelkezı objektumok halmazára tagolja. Az objektumok a többi objektum által biztosított szolgáltatásokat
RészletesebbenRendszertervezés 2. IR elemzés Dr. Szepesné Stiftinger, Mária
Rendszertervezés 2. IR elemzés Dr. Szepesné Stiftinger, Mária Rendszertervezés 2. : IR elemzés Dr. Szepesné Stiftinger, Mária Lektor : Rajki, Péter Ez a modul a TÁMOP - 4.1.2-08/1/A-2009-0027 Tananyagfejlesztéssel
RészletesebbenTartalom Kontextus modellek Viselkedési modellek Adat-modellek Objektum-modellek CASE munkapadok (workbench)
8. Rendszermodellek Kérdések Miért kell a rendszer kontextusát már a követelménytervezés során modellezni? Mi a viselkedési modell, az adatmodell és az objektum-modell? Milyen jelöléseket tartalmaz az
RészletesebbenBánsághi Anna anna.bansaghi@mamikon.net. Bánsághi Anna 1 of 54
SZOFTVERTECHNOLÓGIA Bánsághi Anna anna.bansaghi@mamikon.net 2. ELŐADÁS - KÖVETELMÉNY MENEDZSMENT Bánsághi Anna 1 of 54 TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK
RészletesebbenA szerelés olyan művelet, amely során az alkatrészeket illetve a szerelési részegységeket további egységekké, gyártmánnyá kapcsoljuk össze.
2.1 A szerelési alapfogalmak Olvassa el figyelmesen a tananyagot! Gyűjtse ki és jegyezze meg a kiemelt alapfogalmakat! Keressen gyakorlati példákat az alapfogalmak értelmezéséhez! A gépek gyártási folyamatában
RészletesebbenAdatstruktúrák, algoritmusok, objektumok
Adatstruktúrák, algoritmusok, objektumok 3. Az objektumorientált paradigma alapelemei Objektum Osztály Példányosítás A konstruktor és a destruktor Osztályok közötti kapcsolatok 1 Objektum Definíció Az
RészletesebbenA prototípus gyors, iteratív fejlesztése azért nagyon fontos, mert a költségek így ellenırizhetık.
A prototípus fogalma: a szoftverrendszer kezdeti verziója, Arra használják, hogy bemutassák a koncepciókat, kipróbálják a tervezési opciókat, és hogy jobban megismerjék a problémát és annak lehetséges
RészletesebbenInformatika szigorlati témakörök gazdasági informatika egyetemi képzés hallgatói részére
Informatika szigorlati témakörök gazdasági informatika egyetemi képzés hallgatói részére Az Informatika szigorlat alapvetően az IR-fejlesztés, valamint az OO-fejlesztés c. tantárgyi blokkok, valamint az
RészletesebbenA hierarchikus adatbázis struktúra jellemzői
A hierarchikus adatbázis struktúra jellemzői Az első adatbázis-kezelő rendszerek a hierarchikus modellen alapultak. Ennek az volt a magyarázata, hogy az élet sok területén első közelítésben elég jól lehet
RészletesebbenSzkeleton tervezése. 100 Generalis faliora. Csapattagok: Konzulens: Szabó András. 2005. március 21.
Szkeleton tervezése 100 Generalis faliora Konzulens: Szabó András Csapattagok: Kenéz Tamás TLSXNP arachnus@tvn.hu Kiss Gergely KNJU43 6er6e1y@gmail.com Papp Gergely L584UF pg554@hszk.bme.hu Rostás Gábor
RészletesebbenBook Template Title. Author Last Name, Author First Name
Book Template Title Author Last Name, Author First Name Book Template Title Author Last Name, Author First Name I. rész - Szoftver technológia 1. fejezet - Esettanulmány Bevezetés Az alkalmazás fejlesztésére
Részletesebben2.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
RészletesebbenInformatika szigorlati témakörök gazdasági informatika egyetemi képzés hallgatói részére
Informatika szigorlati témakörök gazdasági informatika egyetemi képzés hallgatói részére Az Informatika szigorlat alapvetően az IR-fejlesztés, valamint az OO-fejlesztés c. tantárgyi blokkok, valamint az
RészletesebbenObjektum Orientált Szoftverfejlesztés (jegyzet)
Objektum Orientált Szoftverfejlesztés (jegyzet) 1. Kialakulás Kísérletek a szoftverkrízisből való kilábalásra: 1.1 Strukturált programozás Ötlet (E. W. Dijkstra): 1. Elkészítendő programot elgondolhatjuk
RészletesebbenProgramozás 1. 2.gyakorlat
Programozás 1. 2.gyakorlat Ismétlés Objektum: Egy a való világból vett elem (ami lehet elvonatkoztatott is) számítógépes ábrázolása. Pl: Kurzus, Személy stb Minden Objektum rendelkezik: Állapottal Viselkedéssel
Részletesebben7. Verifikáci. ció. Ennek része a hagyományos értelemben vett szoftvertesztelés is. A szoftver verifikálásának,
7. Verifikáci ció, validáci ció A verifikáció és a validáció (V&V) azon ellenőrző és elemző folyamatok összessége, amelyek célja annak vizsgálata, hogy a szoftver megfelel a specifikációnak. Ennek része
Részletesebben!!" KÉSZÍTK: ERDÉLYI LAJOS KOLLÁR NÁNDOR WD6OGW BUK8Y7
!!" KÉSZÍTK: ERDÉLYI LAJOS KOLLÁR NÁNDOR WD6OGW BUK8Y7 #$%#&'( 1. Bevezet... 4 1.1. Feladatkiírás:... 4 1.2. Specifikáció... 4 2. A kidolgozás munkafázisai, szakaszai... 6 3. Fejlesztési irányelvek...
Részletesebben2. fejezet Hálózati szoftver
2. fejezet Hálózati szoftver Hálózati szoftver és hardver viszonya Az első gépek összekötésekor (azaz a hálózat első megjelenésekor) a legfontosabb lépésnek az számított, hogy elkészüljön az a hardver,
RészletesebbenBevezetés. Novell Netware 4.XX hálózati nyomtatók kezelése
Hálózati nyomtatás - Novell 4.xx Novell Netware 4.XX hálózati nyomtatók kezelése Szerzõ: Káli Gábor Bevezetés A helyi nyomtatás mechanizmusa általában A hálózati nyomtatás mechanizmusa általában A hálózati
RészletesebbenMVC Java EE Java EE Kliensek JavaBeanek Java EE komponensek Web-alkalmazások Fejlesztői környezet. Java Web technológiák
Java Web technológiák Bevezetés Áttekintés Model View Controller (MVC) elv Java EE Java alapú Web alkalmazások Áttekintés Model View Controller (MVC) elv Java EE Java alapú Web alkalmazások Áttekintés
RészletesebbenJava VI. Egy kis kitérő: az UML. Osztály diagram. Általános Informatikai Tanszék Utolsó módosítás: 2006. 03. 07.
Java VI. Öröklődés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2006. 03. 07. Java VI.: Öröklődés JAVA6 / 1 Egy kis kitérő: az UML UML: Unified Modelling Language Grafikus eszköz objektum
RészletesebbenWebSphere Adapters. 6. változat 2. alváltozat. WebSphere Adapter for SAP Software felhasználói kézikönyv 6. változat 2. kiadás
WebSphere Adapters 6. változat 2. alváltozat WebSphere Adapter for SAP Software felhasználói kézikönyv 6. változat 2. kiadás Megjegyzés Az információk és a tárgyalt termék használatba vétele előtt feltétlenül
RészletesebbenDSI működésre. tervezve. Hogyan fog kinézni a jövő informatikai infrastruktúrája? Egész szoftverrendszerek egy
DSI működésre tervezve A Microsoft Dynamic Systems Initiative (DSI, dinamikus rendszerek kezdeményezése) névre hallgató koncepciójának mottója: Design for Operations. Célja olyan dinamikus, rugalmas rendszerek
Részletesebbenaxióma alapú automatizált teszteléssel
.NET programok minőségi mutatóinak javítása axióma alapú automatizált teszteléssel Doktori értekezés Szerző: Biczó Mihály Témavezető: Dr. Porkoláb Zoltán Eötvös Loránd Tudományegyetem Informatika Doktori
RészletesebbenSZÁMVITELI POLITIKA SZABÁLYZATA
DUNAÚJVÁROSI FŐISKOLA A 2014. Dunaújváros 2. kiadás 0. módosítás 2(25) oldal Dunaújvárosi Főiskola Szenátusa 46-2013/2014.(2014.04.01) számú határozatával elfogadva Hatályos: 2014.április 2. napjától 2.
RészletesebbenOBJEKTUMORIENTÁLT TERVEZÉS ESETTANULMÁNYOK. 2.1 A feladat
2. Digitális óra 28 OBJEKTUMORIENTÁLT TERVEZÉS ESETTANULMÁNYOK 2.1 A feladat Ebben a fejezetben egy viszonylag egyszerő problémára alkalmazva tekintjük át az OO tervezés modellezési technikáit. A feladat
RészletesebbenOperációs rendszerek. A Windows NT felépítése
Operációs rendszerek A Windows NT felépítése A Windows NT 1996: NT 4.0. Felépítésében is új operációs rendszer: New Technology (NT). 32-bites Windows-os rendszerek felváltása. Windows 2000: NT alapú. Operációs
Részletesebben3.1. Alapelvek. Miskolci Egyetem, Gyártástudományi Intézet, Prof. Dr. Dudás Illés
3. A GYÁRTERVEZÉS ALAPJAI A gyártervezési folyamat bemutatását fontosnak tartottuk, mert a gyártórendszer-tervezés (amely folyamattervezés) része a gyártervezési feladatkörnek (objektumorientált tervezés),
RészletesebbenAdatbázisok I 2012.05.11. Adatmodellek komponensei. Adatbázis modellek típusai. Adatbázisrendszer-specifikus tervezés
Adatbázisok I Szemantikai adatmodellek Szendrői Etelka PTE-PMMK Rendszer és Szoftvertechnológiai Tanszék szendroi@pmmk.pte.hu Adatmodellek komponensei Adatmodell: matematikai formalizmus, mely a valóság
RészletesebbenTERMÉKTERVEZÉS PANDUR BÉLA TERMÉKTERVEZÉS
TERMÉKTERVEZÉS 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 támogatása.
RészletesebbenVÁLLALATI INFORMÁCIÓS RENDSZEREK, INTERNETES TECHNIKÁK
VÁLLALATI INFORMÁCIÓS RENDSZEREK, INTERNETES TECHNIKÁK A digitális gyár mint a termékéletciklusmenedzsment megvalósításának központi eleme A termékéletciklus-menedzsment lényege az üzleti folyamatok olyan
RészletesebbenKövetelmények a megbízható működés terén. Információbiztonsági osztályozás a megbízható működés szempontjából. T - T üz T
Követelmények a megbízható működés terén Információbiztonsági osztályozás a megbízható működés szempontjából Megbízható működés Az informatikai rendszerek megbízható működését úgy értelmezzük, hogy az
RészletesebbenCNC technika. segédlet a CNC tantárgy oktatásához. Készítette: Paróczai János 2005.12.08
CNC technika segédlet a CNC tantárgy oktatásához Készítette: Paróczai János 2005.12.08 3. A CNC technika és a szerszámgép 3.1. Bevezetés A különböző gépi megmunkálási technológiák szüntelen továbbfejlődésén
RészletesebbenAz élet szép, környezetünk tele van fákkal, virágokkal, repdeső madarakkal, vidáman futkározó állatokkal.
Objektumorientált programozás Az élet szép, környezetünk tele van fákkal, virágokkal, repdeső madarakkal, vidáman futkározó állatokkal. Ez a nem művészi értékű, de idillikus kép azt a pillanatot mutatja,
RészletesebbenTervezet A BIZOTTSÁG HATÁROZATA (...) a személyi számítógépek uniós ökocímkéjének odaítélésére vonatkozó ökológiai kritériumok megállapításáról
AZ EURÓPAI UNIÓ TANÁCSA Brüsszel, 2011. március 1. (02.03) (OR. en) 6829/11 ENV 116 FEDŐLAP Küldi: az Európai Bizottság Az átvétel dátuma: 2011. február 17. Címzett: a Főtitkárság Tárgy: Tervezet A BIZOTTSÁG
RészletesebbenMŰANYAGOK FELDOLGOZÁSA
MŰANYAGOK FELDOLGOZÁSA Fröccsöntés irányzatok és újdonságok Az európai műanyag-feldolgozók, gép- és vezérlésgyártók képviselői együtt vitatták meg a fröccsöntés fejlesztési lehetőségeit és az előrelépés
RészletesebbenTermelési logisztikai rendszerek tervezése-fejlesztése
Termelési logisztikai rendszerek tervezése-fejlesztése Fejlesztés-tervezés színterei Meglévő, működő rendszerek jellemzőinek értékelése, intenzifikálása Új termelési logisztikai rendszer tervezése Termelési
RészletesebbenElektronikus közhiteles nyilvántartások Megvalósítási tanulmány
eegészség Program 27. Projekt Elektronikus közhiteles nyilvántartások Megvalósítási tanulmány Készítette: Szentgáli Ádám (Stubenvoll Bt.) 1.1 Budapest, 2004 szeptember 30 Tartalom I. Az EKNY adatbank,
Részletesebben4. Programozási nyelvek osztályozása. Amatőr és professzionális
4. Programozási nyelvek osztályozása. Amatőr és professzionális programozási nyelvek. Számítási modellek (Neumann-elvű, automataelvű, funkcionális, logikai). Programozási nyelvekkel kapcsolatos fogalmak
RészletesebbenRendszerterv. 1. Funkcionális terv. 1.1. Feladat leírása:
Rendszerterv 1. Funkcionális terv 1.1. Feladat leírása: A feladat egy GPS-képes eszközökön futó alkalmazás, illetve ennek szerver oldali párjának létrehozása. A program a szerveren tárolt adatbázis alapján
RészletesebbenA szoftverfolyamat és s a tesztelés
A szoftverfolyamat és s a tesztelés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2008. 11. 19. swproc / 1 A szoftverfolyamat Alaptevékenységek Tartalom Szoftverfolyamat modellek A
RészletesebbenKomponens modellek. 3. Előadás (első fele)
Komponens modellek 3. Előadás (első fele) A komponens modellek feladata Támogassa a szoftverrendszerek felépítését különböző funkcionális, logikai komponensekből, amelyek a számítógépes hálózatban különböző
RészletesebbenElső Magyarországi Szoftvertesztelő Verseny Döntő feladatsor
Első Magyarországi Szoftvertesztelő Verseny Döntő feladatsor 2012. január 27. Masterfield Oktatóközpont Bevezető A feladatok csak az alább megadott sorrendben hajthatók végre. Minden feladatot be kell
RészletesebbenFPGA áramkörök alkalmazásainak vizsgálata
FPGA áramkörök alkalmazásainak vizsgálata Kutatási beszámoló a Pro Progressio alapítvány számára Raikovich Tamás, 2012. 1 Bevezetés A programozható logikai áramkörökön (FPGA) alapuló hardver gyorsítók
RészletesebbenIBM WebSphere Adapters 7. változat 5. alváltozat. IBM WebSphere Adapter for Oracle E-Business Suite felhasználói kézikönyv 7. változat 5.
IBM WebSphere Adapters 7. változat 5. alváltozat IBM WebSphere Adapter for Oracle E-Business Suite felhasználói kézikönyv 7. változat 5.kiadás IBM WebSphere Adapters 7. változat 5. alváltozat IBM WebSphere
RészletesebbenSZAKDOLGOZAT. Titkó Szabolcs. Debrecen 2009.
SZAKDOLGOZAT Titkó Szabolcs Debrecen 2009. Debreceni Egyetem Informatikai Kar Diódakatalógus a weben Témavezető: Dr Kuki Attila Egyetemi Adjunktus Készítette: Titkó Szabolcs Mérnök Informatikus Debrecen
RészletesebbenAlgoritmusok. Hogyan csináljam?
Algoritmusok Hogyan csináljam? 1 Az algoritmus fogalma Algoritmusnak olyan pontos előírást nevezünk, amely megmondja, hogy bizonyos feladat megoldásakor milyen műveleteket milyen meghatározott sorrendben
RészletesebbenTöbbrétegű műszaki nyilvántartás. NETinv
Többrétegű műszaki nyilvántartás NETinv NETinv TÁVKÖZLÉSI SZOLGÁLTATÓK, KÖZMŰVÁLLALATOK, ÁLLAMIGAZGATÁSI INTÉZMÉNYEK ÉS NAGYVÁLLATOK SZÁMÁRA A NETvisor NETinv műszaki nyilvántartó rendszere a távközlési
RészletesebbenProgramozás III CSOMAGOK. Az összetartozó osztályok és interfészek egy csomagba (package) kerülnek.
Programozás III CSOMAGOK Az összetartozó osztályok és interfészek egy csomagba (package) kerülnek. A Java is csomagok halmaza: csomagokban van a fejlesztő környezet és az osztálykönyvtárak is: rt.jar fájl
RészletesebbenSzervlet-JSP együttműködés
Java programozási nyelv 2007-2008/ősz 10. óra Szervlet-JSP együttműködés Kérés továbbítás technikái legradi.gabor@nik.bmf.hu szenasi.sandor@nik.bmf.hu Szervlet-JSP együttműködés Témakörök Osztálykönyvtár
RészletesebbenBevezetés a C++ programozási nyelvbe
Miskolci Egyetem Általános Informatikai Tanszék Bevezetés a C++ programozási nyelvbe Oktatási segédlet Összeállította: Ficsor Lajos 2001. 1. A C++ programozási nyelv története A C++ programozási nyelv
RészletesebbenMILYEN A JÓ PROJEKTMENEDZSMENT
MILYEN A JÓ PROJEKTMENEDZSMENT Aki házat épített vagy felújított úgy, hogy nem lépte túl a tervezett költségeket, időben elkészült, ráadásul az elképzelt minőségben, az átesett első projektmenedzseri munkáján.
RészletesebbenA stabil üzemű berendezések tápfeszültségét a hálózati feszültségből a hálózati tápegység állítja elő (1.ábra).
3.10. Tápegységek Az elektronikus berendezések (így a rádiók) működtetéséhez egy vagy több stabil tápfeszültség szükséges. A stabil tápfeszültség időben nem változó egyenfeszültség, melynek értéke független
Részletesebben(11) Lajstromszám: E 008 100 (13) T2 EURÓPAI SZABADALOM SZÖVEGÉNEK FORDÍTÁSA
!HU000008100T2! (19) HU (11) Lajstromszám: E 008 100 (13) T2 MAGYAR KÖZTÁRSASÁG Magyar Szabadalmi Hivatal EURÓPAI SZABADALOM SZÖVEGÉNEK FORDÍTÁSA (21) Magyar ügyszám: E 06 846052 (22) A bejelentés napja:
RészletesebbenWelcome3 Bele pteto rendszer
Welcome3 Bele pteto rendszer Programozói kézikönyv beks Kommunikációs Technika Kft 4024, Debrecen, Rákóczi utca 21 www.beks.hu 2013. március 7. Tartalomjegyzék Rendszer telepítési folyamatábra... 6 Welcome3
RészletesebbenTermék- és márkastratégiai döntéseket támogató eszközök
Termék- és márkastratégiai döntéseket támogató eszközök DR. BÍRÓ-SZIGETI SZILVIA MENEDZSMENT ÉS VÁLLALATGAZDASÁGTAN TANSZÉK BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM 1 MEV Marketing - PhD 2016. május
RészletesebbenZárójelentés. Az autonóm mobil eszközök felhasználási területei, irányítási módszerek
Zárójelentés Az autonóm mobil eszközök felhasználási területei, irányítási módszerek Az autonóm mobil robotok elterjedése növekedést mutat napjainkban az egész hétköznapi felhasználástól kezdve az ember
RészletesebbenA müncheni biohulladék-erjesztő teljesítményének növelése az előkezelő és víztisztító fokozatok módosításával
HULLADÉKOK ENERGETIKAI ÉS BIOLÓGIAI HASZNOSÍTÁSA 8.3 A müncheni biohulladék-erjesztő teljesítményének növelése az előkezelő és víztisztító fokozatok módosításával Tárgyszavak: berendezés; biohulladék;
RészletesebbenNagy adattömbökkel végzett FORRÓ TI BOR tudományos számítások lehetőségei. kisszámítógépes rendszerekben. Kutató Intézet
Nagy adattömbökkel végzett FORRÓ TI BOR tudományos számítások lehetőségei Kutató Intézet kisszámítógépes rendszerekben Tudományos számításokban gyakran nagy mennyiségű aritmetikai művelet elvégzésére van
RészletesebbenSZÁMOLÁSTECHNIKAI ISMERETEK
SZÁMOLÁSTECHNIKAI ISMERETEK Műveletek szögekkel Geodéziai számításaink során gyakran fogunk szögekkel dolgozni. Az egyszerűbb írásmód kedvéért ilyenkor a fok ( o ), perc (, ), másodperc (,, ) jelét el
RészletesebbenStatisztikai Módszertani Füzetek, 51. A munkaerő-piaci politikák (LMP) adatbázisa (módszertan)
Statisztikai Módszertani Füzetek, 51 A munkaerő-piaci politikák (LMP) adatbázisa (módszertan) Budapest, 2009 Központi Statisztikai Hivatal ISSN: 0291 0554 ISBN: 978 963 235 0237 4 (on-line) 978 963 235
RészletesebbenPÉCSI TUDOMÁNYEGYETEM
PÉCSI TUDOMÁNYEGYETEM Pollack Mihály Műszaki Főiskolai Kar Gépszerkezettan tanszék CAE gépészeknek Szerkesztette: Falmann László Lektorálta: Dr. Horváth Sándor Pécs 2004. Tartalomjegyzék 1. Bevezetés...3
RészletesebbenE-LEARNING ALAPÚ TÁVOKTATÁS A SZÉCHENYI ISTVÁN EGYETEMEN
E-LEARNING ALAPÚ TÁVOKTATÁS A SZÉCHENYI ISTVÁN EGYETEMEN E-LEARNING BASED DISTANCE EDUCATION AT SZÉCHENYI ISTVÁN UNIVERSITY Nyéki Lajos, nyeki@sze.hu Széchenyi István Egyetem 1. Bevezetés A Széchenyi István
RészletesebbenSzámítógépes grafika
Számítógépes grafika XVII. rész A grafikai modellezés A modellezés A generatív számítógépes grafikában és a képfeldolgozás során nem a valódi objektumokat (valóságbeli tárgyakat), hanem azok egy modelljét
RészletesebbenECP. Site Administration System. Felhasználói kézikönyv. v2.9.24+ (1. kiadás a 2.9.24 és újabb verziójú ECP SAS rendszerekhez)
v2.9.24+ ECP Site Administration System Felhasználói kézikönyv (1. kiadás a 2.9.24 és újabb verziójú ECP SAS rendszerekhez) AW STUDIO Nyíregyháza, Luther utca 5. 1/5, info@awstudio.hu 1 2 Jelen dokumentáció
RészletesebbenTERMÉK FEJLESZTÉS PANDUR BÉLA TERMÉK TERVEZÉSE
TERMÉK TERVEZÉSE A termék fogalma: Tevékenységek, vagy folyamatok eredménye /folyamat szemlélet /. (Minden terméknek értelmezhető, amely gazdasági potenciált közvetít /közgazdász szemlélet /.) Az ISO 8402
RészletesebbenMinőség- és környezetközpontú irányítási rendszer kézikönyve
FŐVÁROSI TELEPÜLÉSTISZTASÁGI ÉS KÖRNYEZETVÉDELMI KFT. 1186 Budapest, Ipacsfa utca 19. Telefon: 312-3652, Telefax: 332-7183 Minőség- és környezetközpontú irányítási rendszer kézikönyve Dokumentum adatai:
RészletesebbenMŰANYAGOK ALKALMAZÁSA
MŰANYAGOK ALKALMAZÁSA Korszerű tömítések A tömítések közül a poliuretánból készülteket alig ismerik, pedig vannak speciális célokra alkalmazható, kiemelkedően jó változataik. Bizonyos alkalmazásokra a
RészletesebbenMagyarország működőtőke vonzása a nemzetközi tőkeáramlás folyamatában
Budapesti Gazdasági Főiskola KÜLKERESKEDELMI FŐISKOLAI KAR KÜLGAZDASÁGI SZAK Nappali francia tagozat Gazdaságdiplomácia szakirány Magyarország működőtőke vonzása a nemzetközi tőkeáramlás folyamatában Készítette:
RészletesebbenDIPLOMAMUNKA KOVÁCS BALÁZS DEBRECEN
DIPLOMAMUNKA KOVÁCS BALÁZS DEBRECEN 2010 Debreceni Egyetem Informatikai Kar Háziorvosi alkalmazás fejlesztése Témavezető: Dr. Juhász István egyetemi adjunktus Készítette: Kovács Balázs programtervező informatikus
RészletesebbenCorel PHOTO-PAINT X5 Maszkolástól nyomtatásig
2 Minden jog fenntartva, beleértve bárminemű sokszorosítás, másolás és közlés jogát is. Kiadja a Mercator Stúdió Felelős kiadó a Mercator Stúdió vezetője Lektor: Gál Veronika Szerkesztő: Pétery István
RészletesebbenElektronikus dokumentumtárolási (EDT) szolgáltatás
Elektronikus dokumentumtárolási (EDT) szolgáltatás Csatlakozási Szabályzat 2016. március 8. EREDETI 2 Tartalom 1 BEVEZETŐ... 3 1.1 A dokumentum célja... 3 2 AZ EDT SZOLGÁLTATÁS JELLEMZŐI... 4 2.1 Kapcsolódó
RészletesebbenÁLTALÁNOS JELLEGŰ ELŐÍRÁSOK. A hitelesítési folyamat résztvevőit, az alapelemeket és a főbb kapcsolódási pontokat az 1.
A Miniszterelnöki Hivatalt vezető miniszter 2/2002. (IV. 26.) MeHVM irányelve a minősített elektronikus aláírással kapcsolatos szolgáltatásokra és ezek szolgáltatóira vonatkozó biztonsági követelményekről
Részletesebben5 HOZZÁFÉRÉS-VÉDELEM. A fejezet VIDEOTON fejlesztési dokumentációk felhasználásával készült
5 HOZZÁFÉRÉS-VÉDELEM A rejtjelezésben az adatvédelem hatékony és az adathálózat védelmében nélkülözhetetlen eszközét ismertük meg. Természetesen annak sincs semmilyen elvi akadálya, hogy a rejtjelezést
RészletesebbenProgramozási technikák Pál László. Sapientia EMTE, Csíkszereda, 2009/2010
Programozási technikák Pál László Sapientia EMTE, Csíkszereda, 2009/2010 Előadás tematika 1. Pascal ismétlés, kiegészítések 2. Objektum orientált programozás (OOP) 3. Delphi környezet 4. Komponensek bemutatása
RészletesebbenVállalati integrált kockázatkezelés (II. rész)
Dr. HORVÁTH ZSOLT, ügyvezetõ igazgató, INFOBIZ Kft. SZLÁVIK PÉTER, managing partner, Boda & Partners Vállalati integrált kockázatkezelés (II. rész) 4. Kockázatok kezelése 4.1. Kockázatok kezelésének általános
RészletesebbenAz üzemi méréstechnika hat szabálya
TECHNIKA Az üzemi méréstechnika hat szabálya Tárgyszavak: mérés; méréstechnika; számítógépes; szoftver; adatfeldolgozás; optikai ellenőrzés; mérőrendszer; integrált. A méretek felvétele és a mérési adatok
RészletesebbenTárgyi eszközök felhasználói leírás
Tárgyi eszközök felhasználói leírás Könyvelés modul 1149 Budapest, Egressy út 17-21. Telefon: +36 1 469 4021; fax: +36 1 469 4029 1/23 Tartalomjegyzék 1. Tárgyi eszköz kezelés a programban... 3 1.1. Beállítások...
RészletesebbenPrezentáció használata
Prezentáció használata A számítógép alkalmazásának egyik lehetséges területe, amikor a számítógépet mint segédeszközt hívjuk segítségül, annak érdekében, hogy előadásunk vagy ismertetőnk során elhangzottakat
RészletesebbenHálózatkezelés Szolgáltatási minőség (QoS)
System i Hálózatkezelés Szolgáltatási minőség (QoS) 6. verzió 1. kiadás System i Hálózatkezelés Szolgáltatási minőség (QoS) 6. verzió 1. kiadás Megjegyzés Jelen leírás és a tárgyalt termék használatba
RészletesebbenNeoCMS tartalommenedzselő szoftver leírása
NeoCMS tartalommenedzselő szoftver leírása A NeoSoft Informatika NeoCMS márkanévvel ellátott rendszere könnyen, gyorsan testre szabható tartalommenedzselő rendszer, mely egyedileg átalakítható, és így
RészletesebbenKERESKEDELMI AJÁNLAT BUDAÖRSI VÁROSFEJLESZTŐ KFT. RÉSZÉRE KERETRENDSZERBEN KIALAKÍTOTT - PROJEKT MENEDZSMENT FUNKCIONALITÁS
KERESKEDELMI AJÁNLAT BUDAÖRSI VÁROSFEJLESZTŐ KFT. RÉSZÉRE KERETRENDSZERBEN KIALAKÍTOTT - PROJEKT MENEDZSMENT FUNKCIONALITÁS BEVEZETÉSÉRE ÉS TÁMOGATÁSÁRA 1 TARTALOMJEGYZÉK Vezetői Összefoglaló...3 Projekt
RészletesebbenSzoftver-ergonómiára vonatkozó szabvány, avagy ISO 9241
Szoftver-ergonómiára vonatkozó szabvány, avagy ISO 9241 Ez a szabvány támpontokat ad a fejlesztőknek ahhoz, hogy ergonómikus rendszert tudjanak létrehozni. Az ISO 9241-es szabvány célja a képernyős munka
Részletesebben14. szám 122. évfolyam 2007. április 13. TARTALOM
14. szám 122. évfolyam 2007. április 13. ÉRTESÍTÕ MAGYAR ÁLLAMVASUTAK ZÁRTKÖRÛEN MÛKÖDÕ RÉSZVÉNYTÁRSASÁG TARTALOM Utasítások 6/2007. (IV. 13. MÁV Ért. 14.) PÁVIGH. sz. portfólió-kezelési általános vezérigazgató-helyettesi
RészletesebbenIFJÚSÁG-NEVELÉS. Nevelés, gondolkodás, matematika
IFJÚSÁG-NEVELÉS Nevelés, gondolkodás, matematika Érdeklődéssel olvastam a Korunk 1970. novemberi számában Édouard Labin cikkét: Miért érthetetlen a matematika? Egyetértek a cikk megállapításaival, a vázolt
RészletesebbenÁltalános áttekintés Készletek és paraméterek
A dokumentum írója: Viszket Anita, projektvezető A dokumentum lektora(i): Lőcsei Gábor (fejlesztési igazgató), Maurer Norbert (webes fejlesztő), Molnár István (vezető fejlesztő), Szilágyi Éva (belső tesztelő)
RészletesebbenFIR és IIR szűrők tervezése digitális jelfeldolgozás területén
Dr. Szabó Anita FIR és IIR szűrők tervezése digitális jelfeldolgozás területén A Szabadkai Műszaki Szakfőiskola oktatójaként kutatásaimat a digitális jelfeldolgozás területén folytatom, ezen belül a fő
RészletesebbenKomponens alapú fejlesztés. Szoftvertechnológia elıadás
Komponens alapú fejlesztés Szoftvertechnológia elıadás Tartalom Újrafelhasználás Komponens alapú fejlesztés Példák Újrafelhasználás alapú tervezés A mérnöki tudományágakban a tervezés már létezı komponensek
RészletesebbenModels are not right or wrong; they are more or less useful.
Eötvös Loránd Tudományegyetem Informatikai Kar Szoftvertechnológia 8. előadás Models are not right or wrong; they are more or less useful. (Martin Fowler) 2015 Giachetta Roberto groberto@inf.elte.hu http://people.inf.elte.hu/groberto
Részletesebben2006.4.11. HU Az Európai Unió Hivatalos Lapja L 102/35
2006.4.11. HU Az Európai Unió Hivatalos Lapja L 102/35 AZ EURÓPAI PARLAMENT ÉS A TANÁCS 2006/22/EK IRÁNYELVE (2006. március 15.) a közúti szállításra vonatkozó egyes szociális jogszabályokkal kapcsolatos
RészletesebbenModellalkotás UML-ben
Modellalkotás UML-ben Modellalkotás UML-ben A Unified Modeling Language (UML) egy grafikus modellező nyelv, amely lehetőséget nyújt egy megoldandó probléma specifikációjának leírására absztrakt szinten,
Részletesebben2. gyakorlat Állapot alapú modellezés Megoldások
2. gyakorlat Állapot alapú modellezés ok 1. Közlekedési lámpa Közlekedési lámpát vezérlő elektronikát tervezünk. a) Készítsük el egy egyszerű piros sárga zöld közlekedési lámpa olyan állapotterét, amely
RészletesebbenKapacitív áramokkal működtetett relés áramkörök 621.316.92S:621.318.B7:S21.3S2.$
DR. GÁL JÓZSEF Budapesti Műszaki Egyetem Kapacitív áramokkal működtetett relés áramkörök BTO 621.316.92S:621.318.B7:S21.3S2.$ A cikk cím szerinti témáját két, egymástól időben nagyon távoleső kapcsolási
RészletesebbenAdminisztrátori kézikönyv (Ver: 2.0.0.1)
(Ver: 2.0.0.1) Tartalomjegyzék Adminisztrátori ismeretek...4 Bevezetés...4 1. A rendszer telepítése...4 1.1 A telepítés elvégzése...4 1.2 A hardverkulcs használata...5 1.3 A telepített komponensek...6
Részletesebben