A SZOFTVERTECHNOLÓGIA ALAPJAI
|
|
- Sándor Molnár
- 8 évvel ezelőtt
- Látták:
Á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 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észletesebbenSzoftver-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é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észletesebbenKomponens 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észletesebbenAutó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észletesebbenA 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észletesebbenS01-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észletesebbenBevezeté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észletesebbenProgramfejleszté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észletesebben1. 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észletesebben01. 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észletesebben30 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észletesebbenOpenCL 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észletesebbenS01-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észletesebbenOrvosi 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észletesebbenUML (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észletesebbenModell 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észletesebbenA 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észletesebbenModellinformá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észletesebbenA 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észletesebbenSzoftvertechnoló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észletesebbenMiskolci 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észletesebbenA 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észletesebbenSmart 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észletesebbenSzoftverarchitektú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észletesebbenHaté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észletesebbenBá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észletesebbenIman 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észletesebbenObjektumorientá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észletesebbenMiskolci 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észletesebbenFolyamatmodellezé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észletesebbenSzoftverminő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észletesebbenV. 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észletesebbenTranszformá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észletesebbenNé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észletesebbenSzolgá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észletesebbenAlkalmazá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észletesebbenNagy 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észletesebbenAlkalmazá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észletesebbenSOA 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észletesebbenObjektumorientá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észletesebbenDW 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észletesebbenA 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észletesebbenObjektumorientá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észletesebbenA 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észletesebbenVerifiká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észletesebbenAZ 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észletesebbenFolyamatmodellezé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észletesebbenInformá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észletesebbenNyí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észletesebbenTartalomjegyzé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észletesebbenSzá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észletesebbenOPERÁ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észletesebbenTartalomjegyzé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észletesebbenCrossplatform 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észletesebbenTÁ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észletesebbenTartalom. 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észletesebbenSzoftverminő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észletesebbeniphone é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észletesebbenSzoftver-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észletesebbenALKALMAZÁ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észletesebbenSzoftver-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észletesebbenII. 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észletesebbenSzoftverfejlesztő 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észletesebbenMá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észletesebbenModellező 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észletesebbenUtolsó 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é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észletesebbenhardver-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észletesebbenTANMENET 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észletesebbenAdatbá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észletesebbenA 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észletesebbenAutomatikus 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észletesebbenIBM 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észletesebbenKommuniká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észletesebbenRó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észletesebbenOsztá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észletesebbenAdatstruktú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észletesebbenOsztá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észletesebbenTudá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észletesebbenNETinv. Ú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észletesebbenEgy 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észletesebbenFicsor 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észletesebbenProjectvezető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észletesebbenMentá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észletesebbenIII. 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észletesebbenSzoftvermé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észletesebben1. 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észletesebbenMegoldá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észletesebbenESZKÖ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észletesebbenFelhaszná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észletesebbenObjektum 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észletesebbenSzenzorhá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észletesebbenInteraktí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észletesebbenMagic 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észletesebbenA 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észletesebbenANSYS 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 1 Tartalom Miről is lesz szó? Bosch GS-TC Automata sebességváltó TCU (Transmission Control Unit) Élettartam tesztek
RészletesebbenMŰ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észletesebbenInformatikai 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