A SZOFTVERTECHNOLÓGIA ALAPJAI

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "A SZOFTVERTECHNOLÓGIA ALAPJAI"

Átírás

1 A SZOFTVERTECHNOLÓGIA ALAPJAI Valósidejű rendszerek Tervezés újrafelhasználással 9. előadás PPKE-ITK

2 Tartalom 1. Valósidejű rendszerek 2. Valósidejű rendszerek tervezése 2.1 Valósidejű rendszerek modellezése 2.2 Valós idejű programozás 3. Valósidejű futtató rendszerek PPKE-ITK Szoftvertechnológia / 2

3 1. Valós idejű rendszerek A valós idejű rendszerek olyan (gyakran beépülő) szoftverrendszerek, amelyek figyelik környezetüket és adott (rövid) időn belül képesek reagálni a környezeti hatásokra (ingerekre). Általában inger-válasz típusú rendszerek. Vannak: periodikus ingerek (időzítés hatására végez valamit a rendszer) aperiodikus ingerek (rendszertelenül bekövetkező külső esemény hatására kell valamit végrehajtani) A valós idejű rendszerek működésében az idő kritikus tényező. PPKE-ITK Szoftvertechnológia / 3

4 Valós idejű rendszerek A valós idejű rendszerekhez mindig tartoznak hardver eszközök is: érzékelők, amelyek adatokat gyűjtenek a rendszer környezetéből, Szabályozók, működtetők, amelyek a rendszer környezetét befolyásolják. Érzékelő Szabályozó Érzékelő Érzékelő Valós idejű vezérlő Érzékelő Érzékelő Működtető Szabályozó Szabályozó Működtető Működtető PPKE-ITK Szoftvertechnológia / 4

5 Architekturális megfontolások A szigorú válaszidő követelmények miatt a rendszer architektúrájának képesnek kell lennie az ingereket fogadó handlerek közötti gyors átkapcsolásra Az egyes ingerekre adandó válasz időzítési követelményei nem azonosak, ezért az egyszerű szekvenciális végrehajtás nem megfelelő. A valós idejű rendszereket együttműködő, párhuzamos folyamatokként kell megvalósítani, amelyeket valós idejű futtatórendszerek irányítanak. PPKE-ITK Szoftvertechnológia / 5

6 A rendszer elemei Az érzékelőket vezérlő folyamatok Összegyűjtik az adatokat az érzékelőktől, például azáltal, hogy beolvassák és átmenetileg tárolják azokat, mielőtt az érzékelő a következő adatot küldené. Számítási folyamatok Feldolgozza a begyűjtött adatokat és kiszámítja a rendszer válaszát. Működtető folyamatok A szabályozókat, beavatkozókat irányító működtető jeleket generálja. PPKE-ITK Szoftvertechnológia / 6

7 2. Valós idejű rendszerek tervezése A tervezéskor a fő szempont a rendszer helyes és időben való reagálása az eseményekre. A tervezési döntéseket alapvetően a nem funkcionális rendszerkövetelmények határozzák meg. A rendszer hardver és a szoftver elemeit együtt kell megtervezni, célszerűen elosztva a funkciókat a hardver és a szoftver között. A döntést azonban, hogy mit kell hardverben és mit szoftverben megvalósítani, célszerű halogatni. Egy funkció sok esetbe hardverrel jobb teljesítménnyel valósítható meg, de hosszabb fejlesztést igényel és a változások nehezebben követhetők. PPKE-ITK Szoftvertechnológia / 7

8 Hardver- és szoftvertervezés A rendszerkövetelmények meghatározása A követelmények szétosztása Szoftver követelmények Hardver követelmények Szoftver tervezés Hardver tervezés PPKE-ITK Szoftvertechnológia / 8

9 A valós idejű rendszertervezés folyamata 1. Meghatározzuk a rendszer által feldolgozandó ingereket és a válaszokat. 2. Minden ingerre és válaszra meghatározzuk az időzítési követelményeket. 3. Párhuzamos folyamatokba szervezzük az ingerek és a válaszok feldolgozását. Az ingerek és a válaszok minden osztályához egy folyamatot rendelhetünk. 4. Megtervezzük az algoritmusokat minden ingerre adandó válaszhoz úgy, hogy végrehajthatók legyenek a válaszadásra meghatározott idő alatt. PPKE-ITK Szoftvertechnológia / 9

10 A valós idejű rendszertervezés folyamata 5. Megtervezzük az ütemezési rendszert, amely időben indítja a folyamatokat, és gondoskodik arról, hogy a válaszok a rendelkezésre álló idő alatt megszületnek. 6. A szoftver rendszert integráljuk egy valós idejű futtatórendszer vagy operációs rendszer vezérlése alatt. 7. A tesztelést először szimulált hardveren, majd a megtervezett hardverrel együtt kell végrehajtani. PPKE-ITK Szoftvertechnológia / 10

11 Az időzítésre vonatkozó megfontolások Egy valós idejű rendszer időzítésének elemzése nagyon bonyolult. Sok szimulációra és mérésre van szükség a tervek, majd a rendszer validálásához. Kiderülhet, hogy az egyes tervezési stratégiák (pl. az objektumorientált tervezés) nem alkalmazhatók, az adatreprezentációk elrejtéséből és futtatórendszerekből kifolyólag. Ebből következően az erősen valós idejű rendszereket a szükséges teljesítmény érdekében alacsony szintű programozási nyelven kell megírni. PPKE-ITK Szoftvertechnológia / 11

12 2.1 Valós idejű rendszerek modellezése A valós idejű rendszereknek eseményekre kell reagálniuk, amelyek legtöbbször a rendszer állapotváltozását okozzák. Ezért ezek a rendszerek állapotátmenet diagramokkal modellezhetők. Az állapotátmenet modell feltételezi, hogy a rendszer mindig egy meghatározható állapotban van, amelyből egy adott inger egy másik, definiálható állapotba viszi át. Az állapotátmenet modellek hátránya, hogy a rendszer struktúráját nem ábrázolja és egy egyszerű rendszer is csak bonyolultan modellezhető. Az UML lehetővé teszi az állapotok definiálását. PPKE-ITK Szoftvertechnológia / 12

13 A mikrohullámú sütő állapotátmenet diagramja Teljes teljesítmény Várakozás do: idő megjelenítése Teljes teljesítmény do: teljesítmény beállítása = 600 Fél teljesítmény Teljes teljesítmény Időzítő Időzítő Idő beállítása do: szám beolvasása exit: idő beállítása Szám Indítás Működés do: sütő működtetése Törlés Fél teljesítmény Fél teljesítmény do: teljesítmény beállítása = 300 Ajtó nyitva Ajtó zárva Engedélyezett do: KÉSZ megjelenítése Várakozás do: idő megjelenítése Tiltott Ajtó nyitva do: NEM KÉSZ megjelenítése PPKE-ITK Szoftvertechnológia / 13

14 2.2 Valós idejű programozás A valós idejű rendszereket gyakran assembly nyelven programozzák, mert a szigorú időzítési követelmények nem teszik lehetővé magas szintű nyelv alkalmazását. Például C nyelven lehetséges effektív programokat írni, de nem feltétlenül támogatja a párhuzamos folyamatokat, vagy a megosztott erőforrások kezelését. Ezeket azonban az operációs rendszer megoldhatja. Az Ada a valós idejű rendszerek programozására készült, ezért támogatja a konkurenciát és az újabb verziója már az ütemezést és az időzítést is kezeli. PPKE-ITK Szoftvertechnológia / 14

15 A Java alkalmazása valós idejű rendszerekben A Java támogatja a konkurenciát (szálak és szinkronizált módszerek), ezért alkalmas a kevéssé kritikusan valós idejű rendszerek fejlesztésére. Nem használható viszont szigorúan real-time rendszerekhez, mert: Nem lehet megadni egy szál végrehajtási idejét, A szemétgyűjtés nem vezérelhető, A megosztott erőforrásokat tartalmazó sorok méretét nem lehet lekérdezni, A különböző virtuális gép implementációk különböző időzítéssel futtatják ugyanazt a szoftvert, Nem lehetséges a futási idő tár- és processzorhasználatának elemzése. PPKE-ITK Szoftvertechnológia / 15

16 3. Valós idejű futtató rendszerek A valós idejű futtató rendszerek speciális operációs rendszerek, amelyek a folyamatokat és az erőforrásokat (processzor és memória) vezérlik. Egy konkrét alkalmazás legtöbbször egy általános valós idejű kernelre alapozott, az igények szerint kiegészített futtató rendszer alatt működik. A futtató rendszerek általában nem tartalmaznak fájl, vagy adatbáziskezelést. PPKE-ITK Szoftvertechnológia / 16

17 A valós idejű futtatórendszer komponensei Ütemezési információk Valós idejű óra Ütemező Megszakításkezelő Folyamatok erőforrás igényei Erőforrásra váró folyamatok listája Erőforráskezelő Szabad erőforrások listája Indítandó folyamatok listája Indítandó folyamat Elosztó Felszabadított erőforrások Processzorok listája Folyamatok futtatása PPKE-ITK Szoftvertechnológia / 17

18 Futtatórendszer komponensei Valós idejű óra Periodikus időzítési információt szolgáltat az ütemezéshez. Megszakításkezelő Fogadja és kezeli az aperiodikus ingereket. Ütemező Kiválasztja a következő futtatandó folyamatot. Erőforráskezelő Memória- és processzor erőforrásokat allokál a kiválasztott folyamatokhoz. Elosztó Indítja a következő folyamat végrehajtását. PPKE-ITK Szoftvertechnológia / 18

19 Non-stop rendszerek további komponensei Konfigurációkezelő A rendszer hardver és szoftver elemeinek dinamikus rekonfigurálását végzi. A hardver modulok a rendszer leállítása nélkül kicserélhetők, illetve bővíthetők, Hibakezelő A szoftver és hardver hibák detektálásáért és a rendszer folyamatos működéséért felelős. Végrehajtja a hiba kiküszöböléséhez szükséges teendőket, például átkapcsolás tartalék lemezre, vagy memóriára. PPKE-ITK Szoftvertechnológia / 19

20 A SZOFTVERTECHNOLÓGIA ALAPJAI Tervezés újrafelhasználással 9. előadás PPKE-ITK

21 Tartalom 1. A szoftver újrafelhasználása 1.1 Újrafelhasználás programgenerátorral 2. Komponens alapú fejlesztés 3. A komponens alapú fejlesztési folyamat 3.1 Alkalmazási keretrendszerek 3.2 Polcról levehető termékek 3.3 Komponensek fejlesztése újrafelhasználásra 4. Alkalmazáscsaládok 4.1 Az alkalmazáscsaládok specializációja 4.2 Alkalmazáscsaládok architektúrái 4.3 Alkalmazáscsaládok tagjainak fejlesztése PPKE-ITK Szoftvertechnológia / 21

22 1. A szoftver újrafelhasználása A legtöbb mérnöki tervezési tevékenység komponensek újrafelhasználásán alapul. A terveket más rendszerekben már kipróbált, szabványos, kisebb-nagyobb komponens újrafelhasználására alapozzák (csavaroktól a hajtóművekig). A szoftverfejlesztés hagyományosan az eredeti fejlesztésen alapul, de a minőség javítása, a költségek, és a fejlesztési idő csökkentése érdekében mindinkább előtérbe kerül a szoftver komponensek újrafelhasználása. Ehhez olyan tervezési módszereket kell alkalmazni, amely a szisztematikus újrafelhasználáson alapul. PPKE-ITK Szoftvertechnológia / 22

23 Újrafelhasználáson alapuló szoftverfejlesztés Alkalmazási rendszerek újrafelhasználása Teljes alkalmazási rendszerek újrafelhasználása: Beépítve más rendszerekbe, vagy Speciális felhasználói igényeket kiszolgáló alkalmazás-családok kifejlesztése. Komponensek újrafelhasználása Különböző méretű (objektum alrendszer) komponensek beépítése új rendszerekbe. (pl. driverek, interfész modulok, stb.) Függvények újrafelhasználása Egyszerű, jól definiált tevékenységet végző komponensek újrafelhasználása. (pl. szabványos könyvtárak) PPKE-ITK Szoftvertechnológia / 23

24 Az újrafelhasználás előnyei Javuló megbízhatóság A komponenseket már több működő rendszerben kipróbálták. Alacsonyabb projektkockázat A komponensek ára és adaptálási költsége pontosabban tervezhető. A szaktudás jobb kihasználása A speciális szaktudás a komponensben testesül meg, nem szükséges minden projekthez külön alkalmazni. Szabványosság A szabványoknak való megfelelést a komponensek garantálják (interfészek, kommunikációs és GUI szabványok) Gyorsabb fejlesztés Egy rendszer kifejlesztése gyorsabb, ha kevesebb eredeti fejlesztést igényel. PPKE-ITK Szoftvertechnológia / 24

25 Az újrafelhasználás hátrányai Növekvő karbantartási költségek A komponens forráskódja és tervezési dokumentációja hiányában növekszik a karbantartás költsége. Az eszköztámogatás hiánya A CASE eszközök nem támogatják az újrafelhasználást. A nem mi találtuk ki jelenség Egy teljes rendszer kidolgozása nagyobb szakmai kihívás. A komponenskönyvtárak karbantartása Sokba kerül a komponenskönyvtárak feltöltése és folyamatos karbantartása. Az újrafelhasználható komponensek megtalálása és adaptálása Még nem fejlődtek ki a komponensek megtalálását és adaptálását segítő általános technikák. PPKE-ITK Szoftvertechnológia / 25

26 Kritikus követelmények Meg kell találni a megfelelő újrafelhasználható komponenseket. Ehhez katalógusokra és nyilvántartásokra, alkalmas kereső mechanizmusokra van szükség. Az újrafelhasználónak bíznia kell abban, hogy a komponens a leírtaknak megfelelően és megbízhatóan működik. A komponenseknek olyan dokumentációval kell rendelkezniük, amely érthető, teljes, aktuális és hivatkozik a korábbi felhasználásokra is (referenciák). PPKE-ITK Szoftvertechnológia / 26

27 1.1 Újrafelhasználás programgenerátorral A generátor alapú újrafelhasználás akkor lehetséges, ha egy programgenerátor tartalmazza egy szakterület alapvető ismeretanyagát. (pl. adatfeldolgozás) Az ilyen programgenerátorok tartalmazzák a szabványos algoritmusokat és függvényeket, és ezek paraméterezését követően a generátor automatikusan előállítja a programot. A szakterületre kidolgozott nyelven, vagy újabban grafikus eszközökkel lehet elkészíteni a rendszer modelljét. (Ebben az esetben elsősorban a szakterületi tudás újrafelhasználásáról van szó.) PPKE-ITK Szoftvertechnológia / 27

28 A programgenerátorok típusai A generátorok fajtái: Alkalmazásgenerátorok - üzleti adatfeldolgozó rendszerek készítésére. Szintaktikus elemzők - a programozási nyelvek értelmezésére. CASE eszközökben lévő kódgenerátorok egy szoftvertervből a tervezett rendszer implementációját állítják elő. A generátor alapú újrafelhasználás igen költséghatékony, de viszonylag kevés szakterülethez léteznek ilyen rendszerek (üzleti adatfeldolgozás, ebusiness, stb.) Ezzel a módszerrel könnyebben állíthatók elő az alkalmazások, mint a komponens alapú módszerrel. PPKE-ITK Szoftvertechnológia / 28

29 A generátor alapú újrafelhasználás folyamata Az alkalmazás leírása (modellje) Programgenerátor Generált program Szakterületi alkalmazási ismeretek Adatbázis PPKE-ITK Szoftvertechnológia / 29

30 2. Komponens alapú fejlesztés A komponens alapú szoftverfejlesztés (CBSE Component Based Software Engineering) az újrafelhasználáson alapul. Kialakulásának oka az, hogy az objektumorientált fejlesztés nem igazán támogatja az újrafelhasználást, mert: Az egyedi objektumosztályok túl részletesek és specifikusak és csak a folyamat késői fázisában kapcsolódnak az alkalmazáshoz. Nem alakult ki olyan piac, ahol az egyes szakterületek objektumosztályaihoz lehetne hozzájutni. A komponensek az objektumosztályoknál sokkal absztraktabbak és különálló szolgáltatásoknak tekinthetők. PPKE-ITK Szoftvertechnológia / 30

31 A komponensek A komponensek szolgáltatásokat nyújtanak a rendszer számára, a végrehajtás helyétől és a megvalósítás nyelvétől függetlenül. Egy komponens egy függetlenül végrehajtható program, amely egy vagy több végrehajtható objektumból áll. A komponensek interfészeit publikálják és minden interakció ezeken az interfészeken keresztül folyik. A komponens forráskódja általában nem hozzáférhető, belső állapotai nem láthatóak. A komponensek mérete az egyszerű függvénytől a teljes alkalmazási rendszerig terjed. PPKE-ITK Szoftvertechnológia / 31

32 A komponensek interfészei Szolgáltatott interfészek a komponens által szolgáltatott interfészek. Szükséges interfészek azok az interfészek, amelyeket a komponenst használó rendszernek, vagy környezetének kell biztosítania. Szükséges interfészek Komponens Szolgáltatott interfészek PPKE-ITK Szoftvertechnológia / 32

33 3.1 A komponens alapú fejlesztési folyamat A komponens alapú fejlesztés beilleszthető a szabályos szoftverfolyamatba, ha beépítjük abba az újrafelhasználással kapcsolatos tevékenységeket: Komponensek specifikálása, Komponensek megtalálása, A tervek (esetleg a követelmények) módosítása a meglelt komponensek tulajdonságainak megfelelően. Ez az alkalmazkodó újrafelhasználás Rendszer architektúra tervezése Komponensek meghatározása Komponensek keresése Kiválasztott komponensek egyesítése PPKE-ITK Szoftvertechnológia / 33

34 Fejlesztés újrafelhasználással Vázlatos rendszerkövetelmények Újrafelhasználható komponensek keresése A követelmények módosítása a komponensek szerint Architektúra tervezés Újrafelhasználható komponensek keresése Rendszertervezés az újrafelhasználható komponensekkel A rendszer megvalósítása történhet prototípuskészítéssel, vagy inkrementális módon. A legtöbb programozási nyelvben hivatkozhatunk könyvtárban tárolt komponensekre Leggyakrabban script nyelvet használnak a komponensek integrálására. PPKE-ITK Szoftvertechnológia / 34

35 Hátrányok, nehézségek A komponensek inkompatibilitása miatt a költség- és időmegtakarítás a vártnál kevesebb lehet (integrációs munkák). Nehézséget okozhat a komponensek megtalálása (nincsenek szabványok a komponensek tulajdonságainak leírására, hiányoznak az egységes komponens könyvtárak). A követelmények változását követő evolúció lehetetlen, ha a komponensek nem cserélhetők. A karbantartás nehezebb. Mindezek ellenére a fejlesztési idő és a szoftverek élettartamának csökkenése sokszor megéri újrafelhasználható komponensek alkalmazását. PPKE-ITK Szoftvertechnológia / 35

36 3.1 Alkalmazási keretrendszerek A keretrendszer absztrakt és konkrét osztályok gyűjteményéből és a köztük lévő interfészekből álló alrendszer-terv. A keretrendszerek úgy implementálhatók, hogy a terv részeit komponensek hozzáadásával egészítjük ki. Általában viszonylag nagy, újrafelhasználható egységek, de nem önálló alkalmazások. Az alkalmazások több keretrendszer integrálásával hozhatók létre. PPKE-ITK Szoftvertechnológia / 36

37 A keretrendszerek csoportosítása A rendszer infrastruktúrájának keretrendszerei A rendszer infrastrukturális alapjainak (kommunikáció, felhasználói felületek, titkosítás, stb.) fejlesztését támogatják. Köztes, integrációs keretrendszerek komponensek közti kommunikációt és információcserét támogató szabványok és osztályok. (Ilyen például a CORBA, JavaBean, JMI, COM, DCOM,.NET, stb.) Vállalati alkalmazások keretrendszerei Az egyes speciális szakterületi alkalmazások fejlesztését támogatják. A szakterületi tudást tartalmazzák (pl. pénzügy, telekommunikáció). PPKE-ITK Szoftvertechnológia / 37

38 A keretrendszerek kibővítése A keretrendszer általános struktúra, amely a konkrét alkalmazás létrehozásakor konkrét osztályokkal kibővíthető. A keretrendszer kibővítése az alábbiakat jelenti: A keretrendszer absztrakt osztályainak kiegészítése konkrét osztályokkal. Műveletek hozzáadása, amelyek meghívhatók a keretrendszer által kezelt események bekövetkezésekor. A keretrendszerek hátránya a bonyolultság. Sok időt igényel az effektív használatukhoz szükséges megismerésük. PPKE-ITK Szoftvertechnológia / 38

39 3.2 Polcról levehető termékek A polcról levehető, COTS Commercial Off-The-Shelf rendszerek általában komplett alkalmazási rendszerek, amelyek API-val rendelkeznek. Legtöbbször rendszerszoftver termékek, az egyszerű komponenseknél nagyobb funkcionalitással. Nagy rendszerek építésekor gyakran használt stratégia a COTS termékek integrálása. Különösen a gyors fejlesztést kívánó ecommerce, ebusiness rendszerek körében. A fejlesztési idő nagyságrendekkel csökkenthető. PPKE-ITK Szoftvertechnológia / 39

40 COTS integrációs nehézségek A funkcionalitás és a teljesítmény nem tartható kézben: A COTS rendszerek sokszor kevésbé effektívek mint azt a reklámokban ígérik. A COTS rendszerek együttműködése bizonytalan A különböző COTS rendszerek eltérő feltételezésekkel készültek (pl. sorkezelés), ezért az integráció nehéz lehet. Az evolúció ellenőrizhetetlen A szállító és nem a felhasználó határozza meg. A COTS termékek támogatása A szállító által biztosított támogatás gyakran nem terjed ki a rendszer teljes élettartamára. PPKE-ITK Szoftvertechnológia / 40

41 3.3 Komponensek fejlesztése újrafelhasználásra Az újrafelhasználható komponensek meglévő komponensek általánosításával hozhatók létre. Ehhez nagy tapasztalat kell. A komponens újrafelhasználhatóságának jellemzői: Stabil szakterületi absztrakciókra támaszkodnak. El kell rejtenie az állapotait, és műveleteket kell biztosítania a az állapotához való hozzáférésre. Amennyire lehetséges függetlennek és önállónak kell lennie. A hibakezelést interfészeken keresztül kell megoldania. Az újrafelhasználhatóság és a használhatóság ellentmondása: Minél általánosabb interfésszel rendelkezik, annál inkább újrafelhasználható, de annál bonyolultabb, vagyis kevésbé használható. PPKE-ITK Szoftvertechnológia / 41

42 Újrafelhasználható komponensek fejlesztése Az újrafelhasználható komponensek fejlesztési költségei többszörösen meghaladják az egyszerű, specifikus komponensek költségeit. Ezt egyetlen projekt költségeiből nem lehet fedezni, ezért kialakultak olyan szoftverfejlesztő vállalatok, amelyek specializálódtak az újrafelhasználható komponensek fejlesztésére. Az általános komponensek kevésbé effektívek, több erőforrást használnak és végrehajtási idejük hosszabb, mint a specifikus komponenseké. PPKE-ITK Szoftvertechnológia / 42

43 Specifikus komponens kiterjesztése Egy specifikus komponens újrafelhasználhatóvá tétele az alábbi folyamattal végezhető: Kezdeti komponens Újrafelhasználható komponens Név általánosítás Művelet általánosítás Hibakezelés általánosítás A komponens hitelesítése PPKE-ITK Szoftvertechnológia / 43

44 4. Alkalmazáscsaládok Az alkalmazáscsalád az alkalmazási rendszerek olyan termékcsaládja, vagy termékvonulata, amelyek egy közös, szakterület-specifikus architektúrára épülnek ( közös mag ). Az alkalmazáscsaládnak ezt a közös magját minden esetben újra felhasználják, amikor egy új alkalmazást fejlesztenek ki. Mindegyik specifikus alkalmazás különbözik a többitől, miután a közös mag más komponensekkel egészül ki. PPKE-ITK Szoftvertechnológia / 44

45 4.1 Az alkalmazáscsaládok specializációja Platform specializáció Az alkalmazás egyes verziói különböző platformokra készülnek (pl. Windows, Solaris, Linux,..), de a funkcionalitás azonos. Konfigurációs specializáció Az alkalmazás egyes verziói különböző perifériákkal képesek együttműködni. (A perifériákat kezelő komponensek különböznek.) Funkcionális specializáció Az alkalmazás egyes verziói eltérő funkcionális követelmények kielégítésére készülnek. (A funkcionális komponensek különböznek.) PPKE-ITK Szoftvertechnológia / 45

46 Példa: Állóeszköz nyilvántartó rendszer I. Felhasználói hozzáférés Program hozzáférés Hozzáadás Törlés Lekérd. Tallózás Admin Jelentés Leírások, jellemzők Képernyő spec. Jelentés-spec. Adatbázis PPKE-ITK Szoftvertechnológia / 46

47 Példa: Állóeszköz nyilvántartó rendszer II. Adatbázis szint A nyilvántartott tárgyak, eszközök részletes adatait, mennyiségét, stb. tárolja és kezeli. I/O leírások szintje Az adatbázis struktúrájának, az input és output formátumoknak leírásai. Funkcionális szint A lekérdezések és adatkezelések funkcióit tartalmazza. Interfészek szintje Felhasználói- és program-interfészek PPKE-ITK Szoftvertechnológia / 47

48 4.2 Alkalmazáscsaládok architektúrái Az alkalmazáscsalád specializálása az alábbi megfontolásokkal biztosítható: Az architektúrát úgy kell strukturálni, hogy jól különválasztható és módosítható alrendszerekből álljon. Az architektúrában a kezelendő egyedeket és azok leírását szintén külön kell választani. Az egyedekhez csak magasabb szinten, a leírásokon keresztül szabad hozzáférést biztosítani. A fentiekkel megoldható, hogy az alkalmazás speciális alkalmazási igényeknek megfelelő kialakításához csak jól körülhatárolt komponensek cseréjére legyen szükség. PPKE-ITK Szoftvertechnológia / 48

49 4.3 Alkalmazáscsaládok tagjainak fejlesztése A követelmények felderítése A család meglévő tagjai prototípusként használhatók Kiindulásként a követelményekhez legközelebb álló családtag kiválasztása Meg kell találni az adott követelményekhez legközelebb lévő, már létező családtagot. A követelmények újratárgyalása A követelményeket a meglévő rendszerhez minél közelebb kell hozni. A meglévő rendszer adaptálása Új modulok kifejlesztése, változtatások a kiválasztott meglévő családtag moduljain. Az új családtag kibocsátása Az új családtag dokumentálása, a bevezetést, telepítést támogató funkciók megtervezése. PPKE-ITK Szoftvertechnológia / 49

50 Az új családtag fejlesztésének folyamata A követelmények felderítése A legközelebbi családtag kiválasztása A követelmények újratárgyalása A meglévő rendszer adaptálása Az új családtag kibocsátása PPKE-ITK Szoftvertechnológia / 50

51 4. Tervezési minták A meglévő komponensek részletes tervezési döntései (egyéni algoritmusok, interfészek típusai, stb.) befolyásolják a komponens újrafelhasználhatóságát. Ezért magasabb szintű, implementációs részleteket nem tartalmazó, absztrakt terveket alkalmaznak újrafelhasználásra. A tervezési minta egy probléma ismertetése és annak megoldásának absztrakt leírása, nem részletes specifikáció. Gyakran alkalmazzák az olyan objektum karakterisztikákat, mint az öröklődés vagy a szülőosztály műveleteinek átdefiniálására (polymorphism) amit nem minden OO környezet támogat. PPKE-ITK Szoftvertechnológia / 51

52 A tervezési minta elemei Név Jelentéssel bíró (beszédes) név. A probléma leírása Annak ismertetése, hogy a minta milyen feladatra és milyen körülmények között alkalmazható. A megoldás leírása Nem egy részletes terv, hanem annak egy sablonja, amely többféle módon implementálható. Gyakran egy grafikus ismertetés (pl. diagramok), amely az objektumok és osztályok kapcsolatait mutatja. Következmények A minta alkalmazásának lehetséges következményei. Segíti a tervezőt annak eldöntésében, hogy a minta alkalmazható-e a konkrét problémára, vagy sem. PPKE-ITK Szoftvertechnológia / 52

53 Observer - a minta klasszikus példája Név: Observer Leírás Különválasztja az objektum állapotának megjelenítését az objektumtól, így többféle megjelenítés lehetséges. A probléma leírása Ugyanazt az állapotinformációt többféleképpen kell megjeleníteni: grafikusan, táblázatosan, stb. A megoldás leírása A minta szerkezetét az UML diagram mutatja. Két absztrakt (Subject és Observer) és két konkrét (ConcreteSubject és ConcreteObserver) objektumot definiál. A konkrét objektumok öröklik az absztrakt objektumok attribútumait. (A ConcreteObserver automatikusan kijelzi állapotát, ami nem szokásos interfész művelet) Következmények A megjelenítés teljesítményének optimalizálása nem célszerű, mert az objektumok között nem szoros a kapcsolat, ezért nem kívánt frissítések sorozatát válthatja ki. PPKE-ITK Szoftvertechnológia / 53

54 Observer többszörös megjelenítés C D B A A B C D 0 Adatok Observer 1 A: 40 B: 25 Observer 2 C: 15 D: 20 PPKE-ITK Szoftvertechnológia / 54

55 Az Observer osztálydiagramja PPKE-ITK Szoftvertechnológia / 55

56 Összefoglalás A tervezés újrafelhasználással feltételezi, hogy az új szoftver tervezésekor egy létező, bevált terv és létező komponensek hasznosításával történik. Az előnyök: alacsonyabb költségek, gyorsabb szoftverfejlesztés és alacsonyabb kockázat. A komponens alapú fejlesztés black-box komponensek felhasználását jelenti, amelyeknek csak a szükséges és a biztosított interfészeit ismeri. A COTS termékek újrafelhasználása a nagy szoftverek felhasználását jelenti. PPKE-ITK Szoftvertechnológia / 56

57 Összefoglalás Az újrafelhasználható komponensnek függetlennek kell lennie, stabil szakterületi absztrakciókat kell tükröznie és állapotaihoz csak interfészeken keresztül biztosíthat hozzáférést. Az alkalmazáscsaládok egy általános rendszer (közös mag) specializációját és kiegészítését jelentik. A tervezési minták magas szintű absztrakciók, amelyek sikeres tervezési megoldásokat dokumentálnak. PPKE-ITK Szoftvertechnológia / 57

Szoftver újrafelhasználás

Szoftver újrafelhasználás Szoftver újrafelhasználás Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással

Részletesebben

Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom

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

Részletesebben

Bánsághi Anna anna.bansaghi@mamikon.net. 1 of 67

Bá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észletesebben

Komponens alapú fejlesztés

Komponens alapú fejlesztés Komponens alapú fejlesztés Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással

Részletesebben

Autóipari beágyazott rendszerek. Komponens és rendszer integráció

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

Részletesebben

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

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

Részletesebben

S01-8 Komponens alapú szoftverfejlesztés 2

S01-8 Komponens alapú szoftverfejlesztés 2 S01-8 Komponens alapú szoftverfejlesztés 2 Tartalom 1. Komponens megvalósítása: kölcsönhatás modell, viselkedési vagy algoritmikus modell és strukturális modell. 2. Komponens megtestesítés: finomítás és

Részletesebben

Bevezetés a programozásba

Bevezetés a programozásba Bevezetés a programozásba A szoftverfejlesztés folyamata PPKE-ITK Tartalom A rendszer és a szoftver fogalma A szoftver, mint termék és készítésének jellegzetességei A szoftverkészítés fázisai: Az igények

Részletesebben

Programfejlesztési Modellek

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ó

Részletesebben

1. 1. Mi a szoftver? Sorolja fel azokat a termékeket, amelyek a szoftverhez tartoznak.

1. 1. Mi a szoftver? Sorolja fel azokat a termékeket, amelyek a szoftverhez tartoznak. 1. 1. Mi a szoftver? Sorolja fel azokat a termékeket, amelyek a szoftverhez tartoznak. A szoftver: Számítógép-programok és a hozzájuk tartozó dokumentációk összessége (Somerville def.) (A gyakorlatban

Részletesebben

01. gyakorlat - Projektalapítás

01. gyakorlat - Projektalapítás 2 Követelmények 01. gyakorlat - Projektalapítás Szoftvertechnológia gyakorlat OE-NIK A félév során egy nagyobb szoftverrendszer prototípusának elkészítése lesz a feladat Fejlesztési módszertan: RUP CASE-eszköz:

Részletesebben

30 MB INFORMATIKAI PROJEKTELLENŐR

30 MB INFORMATIKAI PROJEKTELLENŐR INFORMATIKAI PROJEKTELLENŐR 30 MB DOMBORA SÁNDOR BEVEZETÉS (INFORMATIKA, INFORMATIAKI FÜGGŐSÉG, INFORMATIKAI PROJEKTEK, MÉRNÖKI ÉS INFORMATIKAI FELADATOK TALÁKOZÁSA, TECHNOLÓGIÁK) 2016. 09. 17. MMK- Informatikai

Részletesebben

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 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

Részletesebben

S01-7 Komponens alapú szoftverfejlesztés 1

S01-7 Komponens alapú szoftverfejlesztés 1 S01-7 Komponens alapú szoftverfejlesztés 1 1. A szoftverfejlesztési modell fogalma. 2. A komponens és komponens modell fogalma. 3. UML kompozíciós diagram fogalma. 4. A szoftverarchitektúrák fogalma, összetevői.

Részletesebben

Orvosi készülékekben használható modern fejlesztési technológiák lehetőségeinek vizsgálata

Orvosi készülékekben használható modern fejlesztési technológiák lehetőségeinek vizsgálata Kutatási beszámoló a Pro Progressio Alapítvány számára Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Mérnök informatika szak Orvosi készülékekben használható modern

Részletesebben

UML (Unified Modelling Language)

UML (Unified Modelling Language) UML (Unified Modelling Language) UML (+ Object Constraint Language) Az objektum- modellezés egy szabványa (OMG) UML A 80-as, 90-es években egyre inkább terjedő objektum-orientált analízis és tervezés (OOA&D)

Részletesebben

Modell alapú tesztelés mobil környezetben

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

Részletesebben

A szoftverfejlesztés eszközei

A szoftverfejlesztés eszközei A szoftverfejlesztés eszközei Fejleszt! eszközök Segédeszközök (szoftverek) programok és fejlesztési dokumentáció írásához elemzéséhez teszteléséhez karbantartásához 2 Segédeszközök szükségessége Szoftver

Részletesebben

Modellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK

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

Részletesebben

A szoftverfejlesztés eszközei

A szoftverfejlesztés eszközei A szoftverfejlesztés eszközei Fejleszt! eszközök Segédeszközök (szoftverek) programok és fejlesztési dokumentáció írásához elemzéséhez teszteléséhez karbantartásához 2 Történet (hw) Lyukkártya válogató

Részletesebben

Szoftvertechnológia ellenőrző kérdések 2005

Szoftvertechnológia ellenőrző kérdések 2005 Szoftvertechnológia ellenőrző kérdések 2005 Mi a szoftver, milyen részekből áll és milyen típusait különböztetjük meg? Mik a szoftverfejlesztés általános lépései? Mik a szoftvergyártás általános modelljei?

Részletesebben

Miskolci Egyetem Általános Informatikai Tanszék

Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a

Részletesebben

A tesztelés feladata. Verifikáció

A tesztelés feladata. Verifikáció Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a

Részletesebben

Smart Strategic Planner

Smart Strategic Planner Smart Strategic Planner STRATÉGIAI FTTX HÁLÓZAT TERVEZŐ ÉS KÖLTSÉG ELEMZŐ ESZKÖZ távközlési hálózatok informatikai hálózatok kutatás és fejlesztés gazdaságos üzemeltetés Smart Strategic Planner Térinformatikai

Részletesebben

Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor

Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor A szotverarchitektúra fogalma A szoftverarchitektúra nagyon fiatal diszciplína. A fogalma még nem teljesen kiforrott. Néhány definíció: A szoftverarchitektúra

Részletesebben

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve Kérdő Attila, ügyvezető, INSERO Kft. EOQ MNB, Informatikai Szakosztály, HTE, ISACA 2012. május 17. Módszertanok

Részletesebben

Bánsághi Anna anna.bansaghi@mamikon.net. 2014 Bánsághi Anna 1 of 31

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

Részletesebben

Iman 3.0 szoftverdokumentáció

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

Részletesebben

Objektumorientált felbontás

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észletesebben

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 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,

Részletesebben

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Munkafolyamat (Workflow): azoknak a lépéseknek a sorozata,

Részletesebben

Szoftverminőségbiztosítás

Szoftverminőségbiztosítás NGB_IN003_1 SZE 2014-15/2 (8) Szoftverminőségbiztosítás Szoftvertesztelési folyamat (folyt.) Szoftvertesztelési ráfordítások (Perry 1995) Tesztelésre fordítódik a projekt költségvetés 24%-a a projekt menedzsment

Részletesebben

V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus

V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus 1 Az előadás tartalma A GI helye az informatikában Az előadás tartalmának magyarázata A

Részletesebben

Transzformációk integrált alkalmazása a modellvezérelt szoftverfejlesztésben. Ráth István

Transzformációk integrált alkalmazása a modellvezérelt szoftverfejlesztésben. Ráth István Transzformációk integrált alkalmazása a modellvezérelt szoftverfejlesztésben Ráth István rath@mit.bme.hu A grafikus nyelvek... mindenhol ott vannak: Grafikus felületek (Visual Studio) Relációs sémák (dbdesign)

Részletesebben

Név: Neptun kód: Pontszám:

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,

Részletesebben

Szolgáltatás Orientált Architektúra a MAVIR-nál

Szolgáltatás Orientált Architektúra a MAVIR-nál Szolgáltatás Orientált Architektúra a MAVIR-nál Sajner Zsuzsanna Accenture Sztráda Gyula MAVIR ZRt. FIO 2009. szeptember 10. Tartalomjegyzék 2 Mi a Szolgáltatás Orientált Architektúra? A SOA bevezetés

Részletesebben

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese

Részletesebben

Nagy bonyolultságú rendszerek fejlesztőeszközei

Nagy bonyolultságú rendszerek fejlesztőeszközei Nagy bonyolultságú rendszerek fejlesztőeszközei Balogh András balogh@optxware.com A cég A BME spin-off-ja A Hibatűrő Rendszerek Kutatócsoport tagjai alapították Tisztán magánkézben Szakmai háttér Hibatűrő

Részletesebben

Alkalmazások típusai Szoftverismeretek

Alkalmazások típusai Szoftverismeretek Alkalmazások típusai Szoftverismeretek Prezentáció tartalma Szoftverek csoportjai Operációs rendszerek Partíciók, fájlrendszerek Tömörítés Vírusok Adatvédelem 2 A szoftver fogalma A szoftver teszi használhatóvá

Részletesebben

SOA modell: Ez az interfész definiálja az elérhető adatokat, és megadja, hogy hogyan lehet azokhoz hozzáférni.

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

Részletesebben

Objektumorientált paradigma és programfejlesztés Bevezető

Objektumorientált paradigma és programfejlesztés Bevezető Objektumorientált paradigma és programfejlesztés Bevezető Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján

Részletesebben

DW 9. előadás DW tervezése, DW-projekt

DW 9. előadás DW tervezése, DW-projekt DW 9. előadás DW tervezése, DW-projekt Követelmény felmérés DW séma tervezése Betöltési modul tervezése Fizikai DW tervezése OLAP felület tervezése Hardver kiépítése Implementáció Tesztelés, bevezetés

Részletesebben

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

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-technológia aspektusai

Részletesebben

Objektumorientált paradigma és a programfejlesztés

Objektumorientált paradigma és a programfejlesztés Objektumorientált paradigma és a programfejlesztés Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján Objektumorientált

Részletesebben

A dokumentáció felépítése

A dokumentáció felépítése A dokumentáció felépítése Készítette: Keszthelyi Zsolt, 2010. szeptember A szoftver dokumentációját az itt megadott szakaszok szerint kell elkészíteni. A szoftvert az Egységesített Eljárás (Unified Process)

Részletesebben

Verifikáció és validáció Általános bevezető

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

Részletesebben

AZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP 3.4.2-B) Kern Zoltán Közoktatási szakértő Kern.zoltan@educatio.hu

AZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP 3.4.2-B) Kern Zoltán Közoktatási szakértő Kern.zoltan@educatio.hu AZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP 3.4.2-B) Kern Zoltán Közoktatási szakértő Kern.zoltan@educatio.hu Integrált (Elektronikus) Nyomonkövető Rendszer Miért használjuk? Hogyan használjuk?

Részletesebben

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Ez vajon egy állapotgép-e? Munkafolyamat (Workflow):

Részletesebben

Információtartalom vázlata

Információtartalom vázlata 1. Az Ön cégétől árajánlatot kértek egy üzleti portál fejlesztésére, amelynek célja egy online áruház kialakítása. Az árajánlatkérés megválaszolásához munkaértekezletet tartanak, ahol Önnek egy vázlatos

Részletesebben

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja 1 / 15 Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja Vajna Miklós 2012. január 24. Tartalomjegyzék 2 / 15 1 Bevezető 2 Motiváció 3

Részletesebben

Tartalomjegyzék. Előszó... 10

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.

Részletesebben

Számítógép architektúra

Számítógép architektúra Budapesti Műszaki Főiskola Regionális Oktatási és Innovációs Központ Székesfehérvár Számítógép architektúra Dr. Seebauer Márta főiskolai tanár seebauer.marta@roik.bmf.hu Irodalmi források Cserny L.: Számítógépek

Részletesebben

OPERÁCIÓS RENDSZEREK I. BEVEZETÉS Koczka Ferenc -

OPERÁCIÓS RENDSZEREK I. BEVEZETÉS Koczka Ferenc - OPERÁCIÓS RENDSZEREK I. BEVEZETÉS Koczka Ferenc - koczka.ferenc@ektf.hu KÖVETELMÉNYEK GYAKORLATI JEGY: Két zárthelyi dolgozat eredményes megírása. Forrás: http://wiki.koczka.hu ELMÉLETI VIZSGA Az előadások

Részletesebben

Tartalomjegyzék. Bevezetés. 1. A.NET 3.5-keretrendszer 1. A korszerű alkalmazások felépítésének kihívásai... 2

Tartalomjegyzék. Bevezetés. 1. A.NET 3.5-keretrendszer 1. A korszerű alkalmazások felépítésének kihívásai... 2 Bevezetés xv Mitől tartozik egy platform a következő generációhoz?... xvi Mennyire jelentős az egyre újabb.net-változatok közötti különbség?... xviii Mit jelentett a Windows Vista megjelenése a Microsoft.NET

Részletesebben

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás A Mobil multimédiás kliens fejlesztői eszközkészlet létrehozása című kutatás-fejlesztési projekthez A dokumentum célja A dokumentum

Részletesebben

TÁMOP /1/A projekt Regionális turisztikai menedzsment /BSc/ /Differenciált szakmai ismeretek modul/ Információs irodák menedzsmentje

TÁMOP /1/A projekt Regionális turisztikai menedzsment /BSc/ /Differenciált szakmai ismeretek modul/ Információs irodák menedzsmentje Gyakorlatorientált képzési programok kidolgozása a turisztikai desztináció menedzsment és a kapcsolódó ismeretanyagok oktatására TÁMOP-4.1.2-08/1/A-2009-0034 projekt Regionális turisztikai menedzsment

Részletesebben

Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet

Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet Konfiguráció menedzsment bevezetési tapasztalatok Vinczellér Gábor AAM Technologies Kft. Tartalom 2 Bevezetés Tipikus konfigurációs adatbázis kialakítási projekt Adatbázis szerkezet Adatbázis feltöltés

Részletesebben

Szoftverminőségbiztosítás

Szoftverminőségbiztosítás NGB_IN003_1 SZE 2014-15/2 (13) Szoftverminőségbiztosítás Szoftverminőség és formális módszerek Formális módszerek Formális módszer formalizált módszer(tan) Formális eljárások alkalmazása a fejlesztésben

Részletesebben

iphone és Android két jó barát...

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

Részletesebben

Szoftver-technológia II. Architektúrák dokumentálása UML-lel. Irodalom. Szoftver-technológia II.

Szoftver-technológia II. Architektúrák dokumentálása UML-lel. Irodalom. Szoftver-technológia II. Architektúrák dokumentálása UML-lel Irodalom L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, Addison-Wesley, 2003 H. Störrle: UML 2, Panem, 2007 2 Szoftver architektúra (emlékeztet!)

Részletesebben

ALKALMAZÁS KERETRENDSZER

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

Részletesebben

Szoftver-technológia I.

Szoftver-technológia I. Szoftver technológia I. Oktatók Sziray József B602 Heckenast Tamás B603 2 Tananyag Elektronikus segédletek www.sze.hu/~sziray/ www.sze.hu/~heckenas/okt/ (www.sze.hu/~orbang/) Nyomtatott könyv Ian Sommerville:

Részletesebben

II. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László

II. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László A kockázat alapú felülvizsgálati és karbantartási stratégia alkalmazása a MOL Rt.-nél megvalósuló Statikus Készülékek Állapot-felügyeleti Rendszerének kialakításában II. rész: a rendszer felülvizsgálati

Részletesebben

Szoftverfejlesztő képzés tematika oktatott modulok

Szoftverfejlesztő képzés tematika oktatott modulok Szoftverfejlesztő képzés tematika oktatott modulok 1148-06 - Szoftverfejlesztés Megtervezi és megvalósítja az adatbázisokat Kódolja az adattárolási réteget egy adatbáziskezelő nyelv használatával Programozás

Részletesebben

Már megismert fogalmak áttekintése

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

Részletesebben

Modellező eszközök, kódgenerálás

Modellező eszközök, kódgenerálás Modellező eszközök, kódgenerálás Budapesti Műszaki és Gazdaságtudományi Egyetem Hibatűrő Rendszerek Kutatócsoport Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek

Részletesebben

Utolsó módosítás:

Utolsó módosítás: Utolsó módosítás: 2011. 09. 08. 1 A tantárggyal kapcsolatos adminisztratív kérdésekkel Micskei Zoltánt keressétek. 2 3 4 5 6 7 8 9 10 11 12 13 14 Erősen buzzword-fertőzött terület, manapság mindent szeretnek

Részletesebben

A SZOFTVERTECHNOLÓGIA ALAPJAI

A 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észletesebben

hardver-szoftver integrált rendszer, amely Xwindow alapú terminálokat szervez egy hálózatba

hardver-szoftver integrált rendszer, amely Xwindow alapú terminálokat szervez egy hálózatba = hardver-szoftver integrált rendszer, amely Xwindow alapú terminálokat szervez egy hálózatba HaXSoN Szerver Vékonyterminál vékonyterminál A HaXSoN vékonyterminál jellemzői - kis méretű, alacsony fogyasztású,

Részletesebben

TANMENET 2018/2019. tanév

TANMENET 2018/2019. tanév Szolnoki Műszaki Szakképzési Centrum Pálfy-Vízügyi Szakgimnáziuma 5000 Szolnok, Tiszaparti sétány 2-3. Tel:06-56-424-955, Fax: 06-56-513-925 e-mail cím: titkarsag@palfy-vizugyi.hu TANMENET 2018/2019. tanév

Részletesebben

Adatbázis rendszerek. dr. Siki Zoltán

Adatbázis rendszerek. dr. Siki Zoltán Adatbázis rendszerek I. dr. Siki Zoltán Adatbázis fogalma adatok valamely célszerűen rendezett, szisztéma szerinti tárolása Az informatika elterjedése előtt is számos adatbázis létezett pl. Vállalati személyzeti

Részletesebben

A SZOFTVERTECHNOLÓGIA ALAPJAI. Architekturális tervezés, Osztott rendszerek 7. előadás PPKE-ITK

A SZOFTVERTECHNOLÓGIA ALAPJAI. Architekturális tervezés, Osztott rendszerek 7. előadás PPKE-ITK A SZOFTVERTECHNOLÓGIA ALAPJAI Architekturális tervezés, Osztott rendszerek 7. előadás PPKE-ITK Tartalom 1. Az architekturális tervezés 1.1 A rendszerstruktúra meghatározása 1.2 Alrendszerek és modulok

Részletesebben

Automatikus tesztgenerálás modell ellenőrző segítségével

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

Részletesebben

IBM felhő menedzsment

IBM felhő menedzsment IBM Váltsunk stratégiát! Budapest, 2012 november 14. IBM felhő menedzsment SmartCloud Provisioning és Service Delivery Manager Felhő alapú szolgáltatások Felhasználás alapú számlázás és dinamikus kapacitás

Részletesebben

Kommunikációs rendszerek teljesítőképesség-vizsgálata

Kommunikációs rendszerek teljesítőképesség-vizsgálata Kommunikációs rendszerek teljesítőképesség-vizsgálata (3. előadás) Dr. Lencse Gábor lencse@sze.hu https://www.tilb.sze.hu/cgi-bin/tilb.cgi?0=m&1=targyak&2=krtv 1 Miről lesz szó? Az OMNeT++ diszkrét idejű

Részletesebben

Rózsa Tünde. Debreceni Egyetem AGTC, Pannon Szoftver Kft SINCRO Kft. Forrás: http://www.praxa.com.au/practices/erp/publishingimages/erp_visual.

Rózsa Tünde. Debreceni Egyetem AGTC, Pannon Szoftver Kft SINCRO Kft. Forrás: http://www.praxa.com.au/practices/erp/publishingimages/erp_visual. Rózsa Tünde Debreceni Egyetem AGTC, Pannon Szoftver Kft SINCRO Kft Forrás: http://www.praxa.com.au/practices/erp/publishingimages/erp_visual.jpg 2 Kutatási célok Tématerület rövid áttekintése A kiválasztást

Részletesebben

Osztálytervezés és implementációs ajánlások

Osztálytervezés és implementációs ajánlások Osztálytervezés és implementációs ajánlások Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2006. 04. 24. Osztálytervezés és implementációs kérdések OTERV / 1 Osztály tervezés Egy nyelv

Részletesebben

Adatstruktúrák, algoritmusok, objektumok

Adatstruktúrák, algoritmusok, objektumok Adatstruktúrák, algoritmusok, objektumok 2. Az objektumorientált programozási paradigma 1 A szoftverkrízis Kihívások a szoftverfejlesztés módszereivel szemben 1. A szoftveres megoldások szerepe folyamatosan

Részletesebben

Osztálytervezés és implementációs ajánlások

Osztálytervezés és implementációs ajánlások Osztálytervezés és implementációs ajánlások Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2006. 04. 24. Osztálytervezés és implementációs kérdések OTERV / 1 Osztály tervezés Egy nyelv

Részletesebben

Tudásalapú információ-kereső rendszerek elemzése és kifejlesztése

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

Részletesebben

NETinv. Új generációs informatikai és kommunikációs megoldások

NETinv. Új generációs informatikai és kommunikációs megoldások Új generációs informatikai és kommunikációs megoldások NETinv távközlési hálózatok informatikai hálózatok kutatás és fejlesztés gazdaságos üzemeltetés NETinv 1.4.2 Távközlési szolgáltatók és nagyvállatok

Részletesebben

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 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

Részletesebben

Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

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

Részletesebben

Projectvezetők képességei

Projectvezetők képességei Projectvezetők képességei MOI modell Motivation ösztönzés Organisation szervezés Ideas or Innovation ötletek vagy újítás Más felosztás Probléma megoldás Vezetői öntudat Teljesítmény Befolyás, team képzés

Részletesebben

Mentális modell, metaforák és analógiák. A desktop metafora. Xerox Star GUI

Mentális modell, metaforák és analógiák. A desktop metafora. Xerox Star GUI Mentális modell, metaforák és analógiák A desktop metafora Xerox Palo Alto Research Center Xerox Star GUI 1973/79. Xerox Alto A piacon megjelenő első számítógép bittérképes képernyővel egérrel grafikus

Részletesebben

III. Alapfogalmak és tervezési módszertan SystemC-ben

III. Alapfogalmak és tervezési módszertan SystemC-ben III. Alapfogalmak és tervezési módszertan SystemC-ben A SystemC egy lehetséges válasz és egyben egyfajta tökéletesített, tovább fejlesztett tervezési módszertan az elektronikai tervezés területén felmerülő

Részletesebben

Szoftvermérés:hogyan lehet a szoftvertermék vagy a szoftverfolyamat valamely jellemzőjéből numerikus értéket előállítani.

Szoftvermérés:hogyan lehet a szoftvertermék vagy a szoftverfolyamat valamely jellemzőjéből numerikus értéket előállítani. Szoftvermérés:hogyan lehet a szoftvertermék vagy a szoftverfolyamat valamely jellemzőjéből numerikus értéket előállítani. az értékeket összegyűjtik, tárolják egymással és az egész szervezetre alkalmazott

Részletesebben

1. SZÁMÚ FÜGGELÉK MŰSZAKI LEÍRÁS

1. SZÁMÚ FÜGGELÉK MŰSZAKI LEÍRÁS 1. SZÁMÚ FÜGGELÉK MŰSZAKI LEÍRÁS Az Enterprise Architect (EA) modell illesztése az számú, Komplex népegészségügyi szűrések elnevezésű kiemelt projekt megvalósításához kapcsolódóan 1. Fogalmak és rövidítések

Részletesebben

Megoldás. Feladat 1. Statikus teszt Specifikáció felülvizsgálat

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

Részletesebben

ESZKÖZTÁMOGATÁS A TESZTELÉSBEN

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

Részletesebben

Felhasználók hitelesítése adatbiztonság szállításkor. Felhasználóknak szeparálása

Felhasználók hitelesítése adatbiztonság szállításkor. Felhasználóknak szeparálása Szabó Zsolt adatbiztonság tároláskor Felhasználók hitelesítése adatbiztonság szállításkor Felhasználóknak szeparálása jogi és szabályozási kérdések incidens kezelés öntitkosító meghajtókat Hardveres Softveres

Részletesebben

Objektum orientált programozás Bevezetés

Objektum orientált programozás Bevezetés Objektum orientált programozás Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2008. 03. 04. OOPALAP / 1 A program készítés Absztrakciós folyamat, amelyben a valós világban

Részletesebben

Szenzorhálózatok programfejlesztési kérdései. Orosz György

Szenzorhálózatok programfejlesztési kérdései. Orosz György Szenzorhálózatok programfejlesztési kérdései Orosz György 2011. 09. 30. Szoftverfejlesztési alternatívák Erőforráskorlátok! (CPU, MEM, Energia) PC-től eltérő felfogás: HW közeli programozás Eszközök közvetlen

Részletesebben

Interaktív, grafikus környezet. Magasszintû alkalmazási nyelv (KAL) Integrált grafikus interface könyvtár. Intelligens kapcsolat más szoftverekkel

Interaktív, grafikus környezet. Magasszintû alkalmazási nyelv (KAL) Integrált grafikus interface könyvtár. Intelligens kapcsolat más szoftverekkel Készítette: Szabó Gábor, 1996 Az Az IntelliCorp IntelliCorp stratégiája: stratégiája: Kifinomult, Kifinomult, objektum-orientált objektum-orientált környezetet környezetet biztosít biztosít tervezéséhez,

Részletesebben

Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon

Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon Mi az IMDG? Nem memóriában futó relációs adatbázis NoSQL hagyományos relációs adatbázis Más fajta adat tárolás Az összes adat RAM-ban van, osztott

Részletesebben

A Java EE 5 plattform

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

Részletesebben

ANSYS ACT. Hatékonyság növelés testreszabással. Farkas Dániel econ Engineering Kft. Budapest, 21/04/2016

ANSYS ACT. Hatékonyság növelés testreszabással. Farkas Dániel econ Engineering Kft. Budapest, 21/04/2016 ANSYS ACT Hatékonyság növelés testreszabással Farkas Dániel econ Engineering Kft. Budapest, 21/04/2016 Szimuláció alapú termékfejlesztés Megbízhatóság Gyorsaság Kapcsolt szimulációk Parametrikus szimulációk

Részletesebben

Élettartam teszteknél alkalmazott programstruktúra egy váltóvezérlő példáján keresztül

Élettartam teszteknél alkalmazott programstruktúra egy váltóvezérlő példáján keresztül Élettartam teszteknél alkalmazott programstruktúra egy váltóvezérlő példáján keresztül 1 Tartalom Miről is lesz szó? Bosch GS-TC Automata sebességváltó TCU (Transmission Control Unit) Élettartam tesztek

Részletesebben

MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS. A) Műszaki követelmények

MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS. A) Műszaki követelmények 1. sz. melléklet MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS A) Műszaki követelmények A körkereső szoftvernek (a továbbiakban Szoftver) az alábbi követelményeknek kell megfelelnie

Részletesebben

Informatikai alkalmazásfejlesztő Információrendszer-elemző és - tervező

Informatikai alkalmazásfejlesztő Információrendszer-elemző és - tervező 11-06 Rendszer/alkalmazás -tervezés, -fejlesztés és -programozás A 10/07 (II. 27.) SzMM rendelettel módosított 1/06 (II. 17.) OM rendelet Országos Képzési Jegyzékről és az Országos Képzési Jegyzékbe történő

Részletesebben