Objektumorientált programelemzés és tervezés MDA segítségével

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

Download "Objektumorientált programelemzés és tervezés MDA segítségével"

Átírás

1 XI. Erdélyi Tudományos Diákköri Konferencia Kolozsvár, május Objektumorientált programelemzés és tervezés MDA segítségével Szerző: Lőrincz Beáta Babes-Bolyai Tudományegyetem, Matematika-Informatika kar, Matematika-Informatika szak, III. Év Témavezető: Dr. Darvay Zsolt, egyetemi adjunktus Babes-Bolyai Tudományegyetem, Matematika-Informatika kar, Programozási nyelvek és módszerek tanszék

2 Tartalomjegyzék 1 Bevezetés A szoftver-fejlesztés kihívásai Az alkalmazásfejlesztés problémái a történelem során Modellezés és formalizálás a problémák megoldása? Következtetések Az MDA előfutárai Az UML modellező nyelv Az UML 2 újdonságai Modellvezérelt fejlesztés (Model Driven Architecture) Szükséges még újabb technológia? MDA szabványrendszer MDA architektúra Előnyök, sikerek MDA oktatóprogram Összefoglaló Bibliográfia

3 1 Bevezetés A modellezés hasznosságát talán már senki nem vitatja, hiszen összefoglaló modellek nélkül a nagy projektek nem lehetnének sikeresek. A számokat összeadó programot fölösleges lett volna modellezni, de a mai informatika kihívásai nagyot fejlődtek és a valós életben már szinte kizárólag nagy és komplex feladatokat kell megoldani. A kérdés napjainkban úgy tevődik fel, hogy mely modellek alkalmazása a legmegfelelőbb adott helyzetekben. Győződjünk meg méginkább a modellezés fontosságáról. A modell szó alapvető értelme: egy minta, terv, ábrázolás (különösen miniatürizálva), vagy pedig egy tárgy, rendszer, fogalom szerkezetének, vagy működésének leírása 1. Vizsgáljuk meg a számunkra érdekes értelmet, vagyis informatikai rendszerek modellezését. A modellek a fizikai rendszerek absztrakcióját szolgáltatják, mely segítségével a fejlesztők átfogó képet kapnak a rendszerről, még mielőtt a részletekben elvesztődnének. A tervezés bármilyen formája modellekre támaszkodik, annak érdekében, hogy komplex, valós világbeli rendszereket megértsen. Modelleket sokféle formában alkalmazunk. A modellek lehetnek a fizikai rendszerek implementációinak előfutárai, vagy származtathatóak egy létező rendszerből, esetleg fejlődésben lévő rendszerből, mint segédeszköz viselkedésének a megértésére. Mivel a rendszer sokféle tulajdonságának ábrázolásában érdekeltek vagyunk, változatos modellezési fogalomra és jelölésrendszerre van szükség, hogy a rendszer egyéni nézeteit kiemelje, attól függően, hogy a feladat megoldásának időpontjában mi a releváns, lényeges. Továbbá egyes esetekben a modellek kiegészíthetőek útmutatásokkal, szabályokkal, melyek elősegítik egyik reprezentációból a másikba való alakítást. Gyakran szükséges a rendszer nézeteinek átalakítása egy azonos absztrakciós szinten (pl. strukturális nézetből a viselkedés nézetébe), és a modelltranszformáció automatizált módon teszi ezt lehetővé. Más esetekben a modelleket különböző absztrakciós szintek között kell alakítani, általában egy kevésbé absztrakt modellé. A modellek és a modellvezérelt alkalmazásfejlesztés az MDA megközelítés magját képezik. Minél jobban megértjük a szemléletet, annál inkább profitálhatunk a modellek alkalmazásából. A szoftver tervezés világában a modellezésnek gazdag hagyománya van a programozás kezdeitéig visszanyúlva. A dolgozat során röviden visszatekintünk ebbe a múltba, a jelentősebb lépéseket megemlítve, melyek a mai elterjedt alkalmazásfejlesztés alapját képezi, az UML modellező nyelv, mint alapjelölésrendszerből kiindulva. Az UML-ből kiindulva, ennek bővítéseit is kifejtve eljutunk az MDA-ig, mely a modellező nyelv mellett bevezeti a MOF metamodellt, mely ugyan magába foglalja az UML-t, de emellett a CWM adatmodelleket is

4 Az utóbbi pár évben sok vállalat figyelt fel a modellvezérelt alkalmazásfejlesztésre, mely segítségével megközelíthető az alkalmazás tervezése és implementációja is. Az MDA olyan elveket fogalmaz meg, melyek a rendszer modellek gyakorlatias és hatékony használatára biztat a szoftver tervezési folyamatban, és az újrahasználhatóságot is lehetővé teszi a rendszercsaládok esetén. A szerzők (OMG Object Management Group) szavaival élve, az MDA egy mód a vállalati architektúrák megszervezésére, irányítására és megszerkesztésére, olyan automatizált eszközökkel és szolgáltatásokkal alátámasztva, melyek a modellek meghatározását és az átalakítást különböző modellek között is lehetővé teszik. A következőkben vizsgáljuk meg a modellvezérelt architektúra összetevőit, ezek előnyeit és nem utolsó sorban gyakorlatban való alkalmazásukat. 4

5 2 A szoftver-fejlesztés kihívásai 2.1 Az alkalmazásfejlesztés problémái a történelem során Fassen wir noch einmal zusammen, was wir über das Problem wissen, Dann wird die Lösung sich von selbst aufdrängen. 2 Eduard von Hartmann Több mint 30 év óta merülnek fel problémák a szoftver-fejlesztésben, állandóan új igények jelentkeznek. Alapvető elvárás, hogy a szoftvertermékek folyamatosan és gyorsan alkalmazkodjanak a változó igényekhez. Annak ellenére, hogy jelentős előrehaladásoknak lehetünk szemtanúi ezen a téren, még nincsen minden probléma megoldva. Tekintsünk kicsit vissza a múltba. A 70-es évek közepén - amikor a szoftver alkalmazások egyre komplexebbek lettek, illetve megjelentek az objektum orientált programozási nyelvek felmerült az igény elemzési és tervezési módszerek használatára. A szakemberek, akik komplex fejlesztési folyamatokban dolgoztak, rájöttek, hogy a szemléltető eszközök, diagramok, ábrák nagy mértékben elősegítik a fejlesztést. Különböző vizualizációs technikákat alkalmazva egyszerűbbé és világosabbá vált a fejlesztési munka, a fejlesztők, illetve fejlesztők-felhasználók közötti kommunikáció. Hamar felmerült az egységesítés iránti igény, hiszen komoly problémát jelentett az alkalmazkodás olyan fejelsztőknek, akik egyszerre több projektben vettek részt, és esetleg több féle módszertan szerint kellett dolgozniuk. A kifejlesztett módszerek többsége azonban ebben a kezdeti fázisban még nem tudott egyértelmű fejlesztési lépéseket meghatározni, illetve nem volt képes a rendszer bonyolultságát általánosan kezelni. A többféle megjelenített módszertan csak a 90-es években vált annyira hatékonnyá, hogy fejlesztési folyamatokban eredményesen tesztelték és alkalmazták. A 90-es évek második felében már sok különböző OO-módszertan létezett, de a választás nehézsége még mindig bizonytalanná tette a fejlesztőket. Az egységesítési törekvések eredményeként, egy évtizednyi munka eredményeként megjelentek a RUP (Rational Unified Process), illetve az UML (Unified Modelling Language) első verziói. Az Ericsson cég módszertani kutatásai jelentették a kezdetet, majd erre épült az Objectory módszertan. 2 Foglaljuk össze azt, amit a problémáról tudunk, majd a megoldása magától adódik. 5

6 1996-ban jelent meg az egységesített modellező nyelv alapverziója, majd 1998-ban véglegesítették a RUP módszertanát, számos más szerző tapasztalatait és módszertanát figyelembe véve. 3 Hogy mit hozott az ez utáni időszak a következő fejezetekben részletesen kibontjuk. 2.2 Modellezés és formalizálás a problémák megoldása? Das Symbol, das Modell, die Hypothese geht dem Darzustellenden parallel. Aber der Paralellismus kann weiter reichen, oder weiter geführt warden, als es bei der Wahl dieser Mittel ursprünglich beabsichtigt war. Indem das Dargestellte und das Darstellungsmittel doch verschieden sind, fällt an dem einen auf, was an dem anderen verbogen bleiben würde. 4 Ernst Mach Tehát a probléma középpontjában a szoftver-rendszer modellezése, illetve a felhasználó nemformális, konkrét követelményekkel rendelkező világából az informatikus formalizált világába való átlépés áll. A követelményekből kiindulva a szoftver termékig és annak érvényesítéséig számos kihívással kell szembenézni, melyek inkább gyakorlati jellegűek, mint elméletiek. Vizsgáljuk először a modell, illetve modellezés fogalmát. A modellezés témakörében különbség van a módszertan és a modellező nyelv fogalma között. A módszertan meghatározza, hogy mit és hogyan kell végrehajtani, illetve hogy miért van szükség a feladat elvégzésére. A módszertan fontos építőelemei a módszerek, olyan eljárások, amelyek előre megadott szabályok szerint működnek. A módszertan az absztrakció alapelveire épül, eredményeit különböző formákban lehet ábrázolni, reprezentálni. Kifejezhetjük akár szóban, leírhatjuk szövegesen, vagy különböző szabályokat alkalmazva le lehet rajzolni. Ennek a kifejezésnek a formáját nevezzük modellező nyelvnek. Ez a nyelv egy szimbólumrendszerből épül fel, melyben az elemek formája és az elemek egymáshoz kapcsolódása jól definiált (szintaktikai szabályok). Ezeket a szabályokat a felhasználóknak azonos kontextusban és azonos módon kell alkalmazni, azaz a szemantikai szabályoknak megfelelően. A modellező nyelv csak akkor éri el célját, ha a szimbólumok segítségével érthetővé teszi az ábrázolandót. Ez a pragmatikai szabály a legfontosabb. Annak ellenére, hogy sok modellező nyelv 3 M. Raffai, UML 2 modellező nyelv, Palatia, 2005, 19. oldal 4 A szimbólum, a modell, a feltevés, az ábrázolandóval párhuzamban áll. Ez a párhuzam azonban tovább érhet, vagy tovább vezethető, mint ahogy ennek az eszköznek a kiválasztásánál eredetileg elképzeltük. Mivelhogy az ábrázolt és az ábrázolási eszköz különbözőek, feltűnik az egyikben, ami a másikban elrejtve maradt. 6

7 eleget tesz a szintaktikai és szemantikai szabályoknak, kevés az olyan, mely a pragmatikai szabályokat is kielégíti. A fejlesztők feladata a nyelv szemléletének elsajátítása és szabályainak pontos használata. A nyelv használatának eredményessége a fejlesztőkön múlik. A modellező nyelv és a programnyelv bizonyos vonásokban nagyon hasonlít egymásra, rendelkeznek meghatározott és absztrakt szintaktikával, szemantikai szabályokkal, de az absztrakció szintjében és elérni kívánt céljukban azonban lényeges az eltérés. A modellező nyelv a valós rendszer követelményeire, a valós elemekre, folyamatokra és viszonyokra épül, míg a programnyelvnél a tényleges megvalósításon van a hangsúly, azokon a műveleteken, amelyek a számítógépen való működést valósítják meg. A konkrét szintaxis is különböző, a modellező nyelv valamilyen szimbólumok használatával elkészített diagram, míg a programok meghatározott formában készített utasítások sorozatából állnak. Természetesen a programnyelvekben is találkozunk szöveges leírásokkal, de formája eleget kell tegyen formai szabályoknak, mely szerint alkalmas gépi fordításra a program. A modellező nyelv fontos szerephez jut az alkalmazás fejlesztési folyamatában, mert különböző szakemberek által érthető és kezelhető módon reprezentálják a rendszer funkcióit. Ha rendelkezésünkre állnak, a modellező nyelvből programnyelvbe átalakító szoftverek, és ezeket alkalmazzuk az alkalmazásfejlesztésben, akkor modellvezérelt fejlesztésről beszélünk. 2.3 Következtetések A természetes nyelvben megfogalmazott követelmények, melyek nem formális modellek formájában állnak a fejlesztők rendelkezésére, nem olvasható, illetve nem értelmezhető formálisan, és így nem alakítható automatikusan. Először a design, illetve implementálás során használhatóak a formális nyelvek. 7

8 Állandóan növekvő ráfordítás kevésbé formalizált kezdeti modellekkel, leírásokkal Ha az a fenti ábrával ellentétben a formalizálás szintje magasabb lett volna kezdetben, vagyis az elemzési fázisban, nemcsak számos hibát lehetett volna kiküszöbölni, hanem a munka egy részét automatizálni lehetett volna, úgyhogy a ráfordítás összességében csökkent volna. Magasszintű formalizálás magas fokú automatizálást tesz lehetővé Csökken a ráfordítás a formalizálás és automatizálás segítségével Egy központi kérdés a formalizálásban még mindig nyitott marad: hogyan készítjük el a szoftver-architektúrát, és mi a célfelület? Ezeket először formálisan definiálni kell ahhoz, hogy automatikus továbbfejleszthessük transzformációk segítségével, melyek végeredménye futtatható 8

9 kód. Pontosan ezt a szemléletmódot ülteti gyakorlatba az MDA a felületfüggetlen, illetve felületfüggő modellek használatával. Mielőtt az MDA használatát bővebben fejtegetnénk, vizsgáljuk meg a diagramokat, eszközöket, melyekből kiindul a modellvezérelt fejlesztés. 9

10 3 Az MDA előfutárai 3.1 Az UML modellező nyelv Egy tulajdonság elveszítésével, a tárgy mégis megőriz valamit abból, amit elveszít, de már valamit felmutat abból is, amivé válik. Egyáltalán, amikor valami elmúlik, megőriz valamit a létéből, és amikor valami keletkezik, muszáj valaminek lennie, amiből létrejön, de ez nem folytatódhat a végtelenségig. Tegyünk még egy megjegyzést, hogy nem egy és ugyanazt jelenti: változtatás a mennyiségre nézve, és változtatás a minőségre nézve. Aristoteles Metafizika A tudomány különböző területeinek megvan a maga sajátos nyelvezete, melyet az illető tudományág szakértői bizonyára értenek és értelmezni is tudnak. Ha a világ bármely pszichológusa az SR képlettel találkozik, akkor tudni fogja, hogy ez a behavioristák egy elméletéból származik, akik arra törekedtek, hogy a jelenségeket inger-válasz (stimulus-reaction) kategóriák segítségével írják le. Annak ellenére, hogy ez egyszerűnek tűnik, egy bonyolult elmélet áll mögötte. Tehát a pszichológusoknak van egy közös nyelvezete, de így van a zenészeknek, kémikusoknak és bármely más foglalkozásnak. Erre volt szüksége a szoftver-engineeringnek is. Tehát a Unified Modelling Language, vagy az UML, egy grafikus modellező nyelv, mely a szoftver-rendszereket modellez különböző nézetekben, vagyis egy olyan jelölésrendszer, melyben modellek és diagramok adhatóak meg különböző nézetekben, úgy hogy függetlenek maradjanak a felülettől, melyben alkalmazni fogják. Az OMG (Object Modeling Group), definíciója szerint: "Az egységesített modellező nyelv (UML) egy grafikus nyelv egy szoftver-intenzív rendszer termékeinek megjelenítésére, specifikálására, felépítésére és dokumentálására. Az UML szabványos lehetőségeket kínál a rendszer felvázolásához, beleértve a fogalmi dolgokat, mint üzleti modellezés és rendszerfunkciók, valamint a konkrét dolgokat, mint programnyelvi utasítások, adatbázis sémák és újrafelhasználható szoftverkomponensek." 5 5 M. Raffai, UML 2 modellező nyelv, op. cit., 71. oldal 10

11 3.2 Az UML 2 újdonságai At last... the OMG s long-awaited release of UML 2.0! Why has this version lurked on the horizon for so long? Three simple words: Model Driven Architecture (MDA). 6 Scott Ambler Software Development A 2003/2004-es évek folyamán fejlesztették ki a UML nyelv második szabványverzióját, alapos felülvizsgálat után 2004 októberében hagyták jóvá. Mivel az első szabványverziónak olyan hiányosságai voltak, melyek az egyre inkább elterjedt webalkalmazásoknak és osztott rendszereknek a megváltozott igényeihez nehezen tudtak alkalmazkodni, komplex megoldásokra volt szükség. Az UML 2.0-t a fejlesztők és felhasználok véleményének figyelembe vételével bővítették, és az új kihívásokhoz igazították. A legfontosabb módosításokat az MDA szabványhoz igazítva a szemantikai szabályokra, a szimbólumok használatára, és a kiterjesztési mechanizmusban használt lehetőségekre hajották végre. A változtatásokat a következőképpen foglalhatnánk össze röviden: o Fejlődtek az architektúra-orientált diagramok: a komponens, fejlődés és csomag diagramok. A komponens diagramok, mint részletes design diagramok támogatják az adat, illetve interface modellezést, tükrözve a minden egy komponens általános nézetet. Ezeket a szerkezeteket alkalmazás és vállalati architektúráknak javasolják. o Az aktivitásdiagram (tevékenységdiagram) egyértelműen külön vált az állapotdiagramtól. Ezután nem az állapotmenetekre, hanem a folyamatokra, az elágazási pontokra, a feltételekre és a párhuzamosságokat figyelembe vevő ábrázolási megoldásokra összpontosít. Objektum modellezés helyett üzleti folyamatok modellezésére javasolják. o A szekvenciadiagramban lehetőség van egyes események/üzenetek leválasztására. Ez komplexebb struktúrák ábrázolását teszi lehetővé, illetve a diagram egyes részei más típusú ábrázolásban is felhasználhatóak. o A régi együttműködési diagramban a hangsúly valóban az együttműködésre kerül, a kommunikáció pontos leírását ezután a kommunikációs diagram valósítja meg. 6 Végre... az OMG régen várt UML 2.0 kiadása! Miért rejtőzködött ez a láthatáron olyan sokáig? Három egyszerű szó: Modell Vezérelt Architektúra (MDA). 11

12 o Az új időzítésdiagrammal leírhatóak a időbeli folyamatok, és követketőek az időbeli állapotváltozások. Az időzítésdiagramon kívül két új diagramot vezettek be, az interakciós, illetve kommunikációs diagramot. o UML 2-ben lehetőség van a diagramrészletek egybefoglalására, és más diagramokban történő hivatkozott felhasználására. Az MDA koncepcióját figyelembe véve az UML 2 nem csak egy ábrázolási technika, hanem egy absztraktabb nyelv, mely az OCL nyelvvel a MOF és XMI szabványokhoz illeszkedve lehetővé teszi a különböző platformokon működő, egymástól eltérő rendszerek információinak azonos módon történő értelmezését, az elemek együttműködését, a modellek automatikus transzformációját 7. 7 M. Raffai, UML 2 modellező nyelv, op. cit., 122. oldal 12

13 4 Modellvezérelt fejlesztés (Model Driven Architecture) 4.1 Szükséges még újabb technológia? A fejlesztési hatékonyság egyik akadályozója a hagyományos alkalmazásfejlesztési szemlélet követése és az új technológiák összeférhetetlensége. Komoly gond az alkalmazások különböző platformok közötti hordozhatósága, illetve a dokumentációk karbantartásának a hiánya. Újrafelhasználhatóság és automatizálás segítségével, formális és standardizált nyelvek következetes használatával sok kérdést meg lehet oldani. Ezen a ponton lép színre az MDA és OMG (Object Managment Group). Elsősorban az MDA és MDA-eszközök biztosítják, hogy a modellek átalakítása kóddá automatikusan történjen, ahelyett, hogy azt manuálisan szerkesztenénk meg. Egy rendszer formalizált lényegét a technológiai felülettől függetlenül, modellek formájában fejleszteni és jobbítani lehet, majd a szükséges változtatások elvégzése után kerül sor a megfelelő kód generálására. Ha változnak a felületek, akkor a felületfüggetlen modellt csupán az új felülettel kell kombinálni, és létrejön az új szoftver a régi modellre alapozva. Az MDA-val kapcsolatban feltevődik a kérdés, hogy a modellezés és formalizálás a szoftver engineering problémáinak megoldására elegendő-e. A továbbiakban sor kerül az MDA módszereinek bemutatására és elemzésére. 4.2 MDA szabványrendszer A programozók régi álma, amikor majd program fog programot írni. Soha nem értettem ezt a dolgot, ez olyan, mintha egy buszvezető álma az lenne, hogy robot vezesse a buszt, szerencsére messze vagyunk még ettől az álomtól... Vannak azonban olyan helyzetek, amikor a favágó munkát célszerű ráhagyni a gépre. Mind ismerünk különféle fejlesztőkörnyezeteket, amelyek kisebb-nagyobb mértékben képesek kódot generálni, beírt kódot ellenőrizni, illetve kódot kiegészíteni. Egyszerűen arról van szó, hogy a nem kreatív munkát megcsinálja a gép. Java Forum, Gábor 13

14 Az MDA az Object Managment Group (OMG) egy újabb standardja, mely megalkotását ben kezdték el. Közben az OMG nemzetközi szervezetté vált, melynek világszerte több mint 800 tagja van. Célja az objektumorientált technológiák elméleti megközelítése és alkalmazása. E cél elérése érdekében számos irányelvet és specifikációt fogalmazott meg, melyek objektumalapú alkalmazások heterogén és osztott környezetekben való futtatását teszi lehetővé úgy, hogy ezek újrafelhasználhatóak, hordozhatóak, illetve kommunikációra képesek legyenek ben tették nyilvánossá a kezdetleges változatát, és jelölték az MDA fogalommal. A grafikus szimbóluma megmagyarázza a stratégiáját. Az MDA hivatalos szimbóluma A modell magja az OMG specifikáció 3 fontos alkotóelemét tartalmazza, a MOF-t (Meta Object Facility), az UML-t (Unified Modelling Language) és a CWM-t (Common Warehouse Metamodel), melyre a köztesrétegmodellek alapoznak. Ezeket a szoftver-architektúra különböző szempontjait biztosítják, mint például a biztonságot. A kifele mutató nyilak az alkalmazási területekre utalnak, melyekért a modellt szerkesztjük. A vezérelv egyszerű és hatásos: modelleket precízen és géppel leolvasható formában tervezni, hogy az absztrakciós szintek architektúráit automatizálni lehessen. Semmilyen mesterséges akadály, mint pl. összeférhetetlen operációs rendszerek, nem szabad a szoftver rendszer fejlődését akadályoznia. Ezt csak a különböző koncepciók és technológiák együttműködésével lehet elérni. Milyen újdonságot hoz az MDA az UML-lel szemben? A modell vezérelt architektúra egy új megközelítése az alkalmazásfejlesztésnek. Kiindulópontja platformfüggetlen UML modell, 14

15 melyhez kapcsolódik egy vagy több platform specifikus modell. Először a rendszer funkcionalitására és viselkedésére kell koncentrálni, a technológiai környezettől eltekintve. Ily módon a rendszer teljes modelljét csak egyszer kell megalkotni. Az MDA szemlélet egy alapvető eleme az alkalmazás-architektúra elkülönítése a rendszer architektúrától. Az alkalmazásarchitektúra az alkalmazás funkcionális céljait meghatározó összetevőket és kapcsolatokat specifikálja. A rendszer-architektúra pedig az alacsonyabb szintű komponensekből és kapcsolatokból áll, melyek az alkalmazás-architektúra végrehajtását teszik lehetővé. Vizsgáljuk meg a hivatalos szimbólum összetevőit. A közös magot három tényező alkotja az UML, MOF és CWM. Ahhoz hogy a fejlesztők azonos módon értelmezzék a modellezéshez használt elemeket, szükség van a modellező nyelv építőelemeinek általános leírására. Hogy azt a metamodellkoncepciót megvalósítsuk a modellelemeket, -struktúrát és -jellemzőket definiáló MOF-szabvány tölti be kulcsszerepet. A MOF egy technikai megoldás metaadatok definiálására olyan fejlesztésekben, amelyek a doménmodellt objektumosztályokká és különböző viselkedésmodellekké képezik le. A modellekre vonatkozó információkat egy repositoryban tárolja. Alapvető célja, hogy a metamodellek együttműködésével lehetővé tegye a különböző platformokon a kommunikációt. Tulajdonképpen egy leegyszerűsített osztálydiagram, mely képes a különböző modellszintek információinak integrálására. 15

16 A MOF metaadat architektúrája A meta-metamodell réteg absztrakt nyelvi formában kifejezett információkat tartalmaz a metametamodellekre vonatkozóan. M3: a metamodell réteg a modellek tulajdonságait leíró információkat tartalmazza. Egy absztrakt nyelv a különböző modellek és modellnézetek leírására, amely modellkomponenseket, szerkezeteket és szemantikát definiál. M2: a Modell réteg információkat tartalmaz a valós folyamatokról és elemeiről. Ezeket a jellemzőket informális módon alkalmazzuk a metamodellekben. M1: az információs réteg a modellezett valós világ tulajdonságait írja le, annak elemeit és viselkedését tükrözi. Az M0 réteg az információs rétegben meghatározott modellelemeket valós objektumokkal, kapcsolatokkal valósítja meg. Következtetésképpen megfogalmazhatjuk, hogy a MOF a metamodelljét alkotja az UML metamodellszinteknek és más specifikációknak, mint a CWM. Az MDA-ban felhasznált 16

17 modellrészeket (PIM, PSM, PM) és nézeteket (szintek), mint az UML, de más modellnyelveket is alkalmazhatunk, melyek metamodellje a MOF metamodellre alapoz. A MOF lehetővé teszi a navigálást egy eset és a metaobjektuma között, egy absztrakt szintaxist definiál egy nyelv számára a metamodell alkalmazásának segítségével, egy megvalósítási példa az UML, de ez csak egy lehetséges megoldás, OCL-kifejezéseket is használhatnánk. Eredményképp egy magasabb szintű kommunikációt kapunk, mely az MDA számára különösen fontos, mert nemcsak egyetlen eszköz áll rendelkezésünkre, anélkül, hogy az információcserére lehetőség lenne. Az eszközlánc felépítéséhez, és a hozzá kapcsolódó transzformációknál fontos szerepet tölt be a MOF. A különböző formátumban tárolt adatok átalakítására és egységes kezelésére van szükség. Olyan karbantartható adattárra van szükségünk, mely lehetővé teszi a különböző szintű döntési folyamatok támogatását. A CWM (Common Warehouse Model) valójában olyan keretrendszer, mely különböző adatforrásokat és céladatokat kezel, adatműveleteket, valamint az átalakítás és az elemzés módjára vonatkozó metaadatokat tartalmazza. Ez a szabvány specifikálja a vállalatok különböző adatbázisainak az együttműködését, és garantálja az adatbázisok közötti átjárhatóságot, leírja az adatmodellezés és implementáció szabályait, az adatbázissémák leképezésének formáit és módját. A CWM metamodell a következő almetamodellekből tevődik össze: o A Data Resources a relációs és az objektumorientált rekordok, valamint a multidimenzionális és az XML-adatforrások metainformációi. o A Data Analysis metamodell az adattranszformációs eljárásokat, az OLAP (On Line Analitycal Processing), az adatbányászati, az információmegjelenítési és az üzleti/szakterületi adatok. o A Warehouse Managment metamodell az adattárház-műveleteket és azok eredményeit képviseli. A CWM megoldást kínál a vállalatoknál felhalmozódott adatok rendszerezésére. Fontos megemlíteni a CWM Web Services kiterjesztést, mely a webimplementációk metaadatok továbbítására vonatkozó szintaktikát és szemantikáját írja elő és a metaadat forgalmat szabványosítja. 17

18 A CWM modell struktúrája táblázatba foglalva: Folyamatelemek Műveletek Adattárház kezelő rendszer Modellelemek Szakterületi komponens Transzformáció OLAP Adatbányászat Információmegjelenítés Objektum- Relációs Rekor Többdimenziós modell modell dok megvalósítás Üzleti Adattípus Kifeje Kulcsok, Típus információk ok zések indexek leképezés Objektumok architektúra- és viselkedésmodell nézetei Doménmegvalósítás XML Szoftverek futtatása 4.3 MDA architektúra Vizsgáljuk meg az architektúra összetevőit, abban a sorrendben, melyben alkalmazzuk őket. Frankel D., The Zachman Framework and the OMG's Model Driven Architecture A CIM modell Egy Computation Independent Model (CIM), melyet a Domain Model vagy Business Model kifejezésekkel is szoktak jelölni, a rendszert minden hard- és szoftverelemtől függetlenül írja le, vagyis a a rendszer használata és működése áll a figyelem középpontjában. Hasznos a fejlesztendő 18

19 rendszer megértése szempontjából, és egy közös terminológia megteremtése szempontjából. Ideális esetben a CIM-ből az út a PIM és PSM irányába is követhető. Például egy CIM modell egy UML osztálydiagram formájában áll rendelkezésre, mely a rendszer követelményeit írja le. A CIM modell létrehozásánál segítő eszközök az elemzési minták, olyan modellei a rendszerelemzésnek, melyek magas általánossági- és absztrakciós szintekkel rendelkeznek. Sok elemzési minta (Analysis Patterns) áll rendelkezésre, mint például Party, Organization Structure, Transactions, Contract, Product. Egy érdekes kiegészítése a CIM modellnek az Archetype Patterns. Az archetípusok olyan tényállasok, melyek állandóan előfordulnak, olyan előredefiniált modell komponensek, melyek az átmenetet képezik a PIM modellhez. Következetetés: a CIM modell nem részletezi a rendszer szerkezetét, nem igényel mély modellelméleti ismereteket, sem elképzeléseket a megvalósításról. Fontos szerepet játszik azok között, akik a rendszer doméniumának és követelményeinek szakértői, illetve a design és megvalósítás szakértői. Példa CIM modellre, mint UML osztálydiagram A PIM modell A modellvezérelt szoftver-fejlesztés esetében fontos egy olyan platformfüggetlen modellt (Platform Independent Model) megalkotni. A modell alkotásánál csupán szakmai szempontokat veszünk figyelembe, és ezeket modellezzük. Az így létrejött modell akkor is érvényes, ha semmilyen szoftvert nem fejlesztünk segítségével, ezeket a félig formalizált modelleket valóban használják a például az üzleti folyamatok elemzésénél és optimalizálásánál (Business Process Re-Engineering). De leggyakrabban ezek a modellek szolgálnak alapul a fejlesztendő szoftver rendszernek. 19

20 A CIM modellből kiindulva ezt finomítva, részletezve megkapjuk a PIM modellt, de mégis nagy a kettő közötti különbség, egy PIM modell a CIM modellel ellentétben megfelel az MDA formális elvárásainak, melyek segítségével a koddá átalakítás végrehajtható, vagyis a formalizálási szint minősége lényegesen magasabb. Míg a CIM modell esetében a leírások a természetes nyelvhez nagyon közel állnak, ez elfogadhatatlan a PIM modell esetében. Példa PIM modellre, mint UML osztálydiagram A PSM modell és implementáció (PSI) Egy platform-modell (PM) vagy platformleíró (Platform Descriptor) a PIM vagy PSM-tól függetlenül egy alapot specifikál a létrehozandó szoftver rendszerekhez. Középpontjában a platform struktúrái és szolgáltatásai állnak. A platform-modellek lehetnek generikusak, technológiaspecifikusak. Ha már kidolgoztuk a CIM, illetve PIM modellt, még egy lépés választ el a használható kódtól. A PIM modellból kiindulva automatikus transzformációval megkapjuk a célfelületet a PSM (Platform Specific Model) modellt, a PM segítségével. Ezt a modellt a PSI névvel is szokták jelölni, ami még kifejezőbb: Platform Specific Implementation, vagyis a Source-Code az eredmény. PIM modelleket automatizáltan alakítunk PSM modelleké, a fordított műveletre még nem alkottak programot, de erre igény sincs, mivel először tervezünk és utána implementálunk. 20

21 4.4 Előnyök, sikerek MDA A Life Cycle, Not Just a Model In the same way, models are just not a few fancy diagrams designed to temporarily visualize a problem or to impress project sponsors or developers. Models can be the lifeblood of the enterprise. They can flow smoothly through different layers. That is why MDA is so important to the current enterprise systems. A model has its own identity, behavior, and value, as objects do. 8 Jax Magazine, 2007 April, MDA T.R.E.N.D. Ahhoz, hogy a szoftverfejlesztéssel szemben támasztott elvárásokat a fejlesztők teljesíteni tudják gyors megoldásokra van szükség. Feltevődik a kérdés, hogy hogyan őrizhetjük meg az eddigi szoftver befektetésünket. A már létező szoftver alapot fel kellene használni, a minőségi munkát meg kellene őrizni, a létező kódalapot karbantartani, és integrálni azt amit már megépítettünk, azzal amit építeni fogunk. Az MDA szabvány erre is irányul, az alkalmazott megoldásoktól függetlenül lehetővé válik különböző korábbi modellelemek felhasználása, illetve a fejlesztési raktárakban (repository) tárolt információk projekten belüli vagy projektek közötti megosztása. Ahhoz, hogy a munkafolyamatok eredményesek legyenek a fejlesztőknek alkalmazkodni kell a formai követelményekhez. Ahhoz, hogy a megoldások kompatibilisek legyenek, az MDA keretrendszer leírja a technológiától független funkcionalitását és viselkedését a rendszernek, lehetővé teszi a különböző szinteken definiált modellek automatikus transzformációját, valamint biztosítja a különböző felületeken futó alkalmazások együttműködését. 8 Hasonlóképp, a modellek nem csak egy pár különlegesen szerkesztett diagram, melyeket azért szerkesztünk, hogy időszakosan ábrázoljunk egy problémát vagy meghassuk a projekt szponzorait és fejlesztőit. A modellek lehetnek a vállalkozás nélkülözhetetlen elemei. Simán áramolhatnak különböző szintek között. Ez az amiért olyan fontos az MDA a mostani vállalati rendszereknek. A modellnek megvan a a saját identitása, viselkedése, és értéke, mint az objektumoknak. 21

22 5 MDA oktatóprogram Egy saját alkalmazáson keresztül lehetőség van a modellvezérelt architektúra egy rövid elméleti áttekintéséhez, illetve gyakorlatok, tesztek végzéséhez interaktív felületen. A program főmenüjében megjelennek az architektúra alapvető elemei, mint a MOF, CWM és UML, a MOF-ról és CWM-ről rövid leírást olvashatunk, míg az UML gombra kattintva megjelenik egy újabb menü, mely az UML 2.0 összes diagramtípusáról tartalmaz leírásokat. A diagramnevek megjelennek a menüben, ezek leírása tartalmazza a diagram létrehozásának célját, ennek értelmezését, azaz a diagramok rendszerbeli funkcionalitását, és a modellelemeket. Minden diagramtípust példa tesz világossá, melynek modellelemeit lépésekben tekinthetőek meg, az elméletben megjelenő sorszámozásnak megfelelően. Az elméleti részben megjelenik még egy leírás a modellvezérelt alkalmazásfejlesztésről általánosan. A gyakorlati rész két részre osztott, lehet egyszerűen tesztkérdésekre válaszolni, a kiértékelésre az összes kérdés megválaszolása után kerül sor. A gyakorlat másik része interaktívabb, diagramrészeket kell felismerni, ezek közötti különbségeket megállapítani, illetve ábrákat összerakni. Az alkalmazás használatávál rövid betekintőt nyerünk a témába. 22

23 6 Összefoglaló Az MDA eredményeinek sikerei azt suggalják, hogy szükség van a modellezés elméletével foglalkozni, illetve ezt alaposabban oktatni, hogy növekedjen a fejlesztők száma, akiknek ismert az UML és MDA fogalom, hogy az ezek által felkínált lehetőségeket jobban ki tudják használni. Több figyelmet kellene fordítani arra, hogy a kliensek/felhasználók miként vegyenek részt a fejlesztési folyamatban. Ez azt javasolja, hogy az UML nem kizárólagosan csak szakértők számára érthető nyelvnek kell lennie, hanem a diagramok és ezek szerepének megértése a rendszerek megépítési folyamataiban szükséges a szervezetek számára is, akik a rendszereket igénylik. A diagramok egységesítése nagyban hozzájárult e cél eléréséhez. A használati utasítások standardizálása szintén szükséges. Az MDA megközelítésnek több előnye is van, befejezésképp vizsgáljuk meg a legfontosabbakat: o Az MDA fejlesztési folyamatban, a figyelem elsősorban az alkalmazás funkcionalitására és viselkedésére irányul, lehetővé téve a résztvevők számára, hogy azokra a tulajdonságokra összpontosítsanak, melyek jelentősen, kritikusan meghatározzák a rendszer magjának folyamatait. A technikai jellemzők megvalósítása végrehajtható az automatizált, illetve szemi-automatizált fejlesztési eszközök segítségével. o Egy architektúra, mely az MDA-ra alapoz, alkalmazkodik a változó igényekhez, és könnyebbé teszi az alkalmazások integrációját a köztesrétegek között. 23

24 Bibliográfia 1. Ariadne Training, UML applied, Object Oriented Analysis and Design Using the UML, 2. Raffai Mária, UML 2 modellező nyelv, Palatia, Roland Petrasch, Oliver Meimberg, Model Driven Architecture, Eine praxisorientierte Einführung in die MDA, Koninklijke Wöhrmann B.V., 2006, (Modell vezérelt architektúra, Egy gyakorlatias bevezetés az MDA-ba) Internetes források: 4. Az OMG hivatalos oldala: Az IBM információi:

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

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

Metamodellezés. Simon Balázs BME IIT, 2011.

Metamodellezés. Simon Balázs BME IIT, 2011. Metamodellezés Simon Balázs BME IIT, 2011. Bevezetés Metamodellezés EMF & ecore Tartalom (C) Simon Balázs, BME IIT, 2011. 2 Hétfő: Simon Balázs Bevezetés hetente felváltva: előadás és gyakorlat metamodellezés

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

Sapientia - Erdélyi Magyar TudományEgyetem (EMTE) Csíkszereda IRT 6. kurzus

Sapientia - Erdélyi Magyar TudományEgyetem (EMTE) Csíkszereda IRT 6. kurzus Sapientia - Erdélyi Magyar TudományEgyetem (EMTE) Csíkszereda IRT 6. kurzus 5-ös Kurzus (UML) Visszatekintés: történelmi szempontok Az UML létrejötte UML-1 (Unified Modeling Language) és UML-2 Magyarul

Részletesebben

Az UML2 és a modell-vezérelt alkalmazásfejlesztés

Az UML2 és a modell-vezérelt alkalmazásfejlesztés Az UML2 és a modell-vezérelt alkalmazásfejlesztés Papp Ágnes, agi@delfin.unideb.hu Debreceni Egyetem EFK A vállalati alkalmazások fejlesztése manapság olyan megközelítést igényel, amely flexibilis módon

Részletesebben

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár Software Engineering Dr. Barabás László Ismétlés/Kitekintő Ismétlés Software Engineering = softwaretechnológia Projekt, fogalma és jellemzői, személyek és szerepkörök Modell, módszertan Kitekintés Elemzés/

Részletesebben

Előzmények 2011.10.23.

Előzmények 2011.10.23. Előzmények Dr. Mileff Péter A 80-as évek közepétől a szoftverek komplexitása egyre növekszik. Megjelentek az OO nyelvek. Az OO fejlesztési módszerek a rendszer különböző nézőpontú modelljeit készítik el.

Részletesebben

problémák elvárások megoldások EAI MDA MOF CWM köztes Sw eszközök hatékonyság konklúzió 09:09 problémák elvárások megoldások EAI MDA MOF CWM

problémák elvárások megoldások EAI MDA MOF CWM köztes Sw eszközök hatékonyság konklúzió 09:09 problémák elvárások megoldások EAI MDA MOF CWM Az IR-fejlesztés problémái A vállalati alkalmazásintegráció szabványos megoldása avagy A domén-modell UML-alapú transzformációja -elvű modellezési stratégia alkalmazásával Néhány adat az informatikai rendszerekről:

Részletesebben

Oracle SQL Developer Data Modeler és a DW adatmodellezés. Gollnhofer Gábor Meta Consulting Kft.

Oracle SQL Developer Data Modeler és a DW adatmodellezés. Gollnhofer Gábor Meta Consulting Kft. Oracle SQL Developer Data Modeler és a DW adatmodellezés Gollnhofer Gábor Meta Consulting Kft. Oracle Information Management & Big Data Reference Architecture 2 Mi a NoSQL modellezés célja? Forrás: Insights

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

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

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

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

Informatika szigorlati témakörök gazdasági informatika egyetemi képzés hallgatói részére

Informatika szigorlati témakörök gazdasági informatika egyetemi képzés hallgatói részére Informatika szigorlati témakörök gazdasági informatika egyetemi képzés hallgatói részére Az Informatika szigorlat alapvetően az IR-fejlesztés, valamint az OO-fejlesztés c. tantárgyi blokkok, valamint az

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

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

Szakterületi modell A fogalmak megjelenítése. 9. fejezet Applying UML and Patterns Craig Larman

Szakterületi modell A fogalmak megjelenítése. 9. fejezet Applying UML and Patterns Craig Larman Szakterületi modell A fogalmak megjelenítése 9. fejezet Applying UML and Patterns Craig Larman 1 Néhány megjegyzés a diagramokhoz Ez a tárgy a rendszer elemzésről és modellezésről szól. Noha például egy

Részletesebben

OOP. Alapelvek Elek Tibor

OOP. Alapelvek Elek Tibor OOP Alapelvek Elek Tibor OOP szemlélet Az OOP szemlélete szerint: a valóságot objektumok halmazaként tekintjük. Ezen objektumok egymással kapcsolatban vannak és együttműködnek. Program készítés: Absztrakciós

Részletesebben

Ismeretanyag Záróvizsgára való felkészüléshez

Ismeretanyag Záróvizsgára való felkészüléshez Ismeretanyag Záróvizsgára való felkészüléshez 1. Információmenedzsment az információmenedzsment értelmezése, feladatok különböző megközelítésekben informatikai szerepek, informatikai szervezet, kapcsolat

Részletesebben

Microsoft SQL Server telepítése

Microsoft SQL Server telepítése Microsoft SQL Server telepítése Az SQL Server a Microsoft adatbázis kiszolgáló megoldása Windows operációs rendszerekre. Az SQL Server 1.0 verziója 1989-ben jelent meg, amelyet tizenegy további verzió

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

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

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

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

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

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

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

Programozás alapjai Bevezetés

Programozás alapjai Bevezetés Programozás alapjai Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Programozás alapjai Bevezetés SWF1 / 1 Tartalom A gépi kódú programozás és hátrányai A magas szintÿ programozási nyelv fogalma

Részletesebben

Tudásalapú információ integráció

Tudásalapú információ integráció Tudásalapú információ integráció (A Szemantikus Web megközelítés és a másik irány) Tanszéki értekezlet, 2008. május 14. 1 Miért van szükségünk ilyesmire? WWW: (Alkalmazások) Keresés a weben (pl. összehasonlítás

Részletesebben

Vállalati alkalmazások integrációja Objektum- és architektúraszemléletű fejlesztési stratégia

Vállalati alkalmazások integrációja Objektum- és architektúraszemléletű fejlesztési stratégia Vállalati alkalmazások integrációja Objektum- és architektúraszemléletű fejlesztési stratégia DR. RAFFAI MÁRIA Széchenyi István Egyetem, Műszaki Tudományi Kar professzor raffai@sze.hu ABSTRACT With regards

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

Adattárház kialakítása a Szövetkezet Integrációban, UML eszközökkel. Németh Rajmund Vezető BI Szakértő március 28.

Adattárház kialakítása a Szövetkezet Integrációban, UML eszközökkel. Németh Rajmund Vezető BI Szakértő március 28. Adattárház kialakítása a Szövetkezet Integrációban, UML eszközökkel Németh Rajmund Vezető BI Szakértő 2017. március 28. Szövetkezeti Integráció Központi Bank Takarékbank Zrt. Kereskedelmi Bank FHB Nyrt.

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

Objektum orientált software fejlesztés (Bevezetés)

Objektum orientált software fejlesztés (Bevezetés) Objektum orientált software fejlesztés (Bevezetés) Lajos Miskolci Egyetem Általános Informatikai Tanszék Út az objektum orientált szemléletig 1. Klasszikus módszerek: program = adatszerkezetek + algoritmusok

Részletesebben

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

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

Informatika szigorlati témakörök gazdasági informatika egyetemi képzés hallgatói részére

Informatika szigorlati témakörök gazdasági informatika egyetemi képzés hallgatói részére Informatika szigorlati témakörök gazdasági informatika egyetemi képzés hallgatói részére Az Informatika szigorlat alapvetően az IR-fejlesztés, valamint az OO-fejlesztés c. tantárgyi blokkok, valamint az

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

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

Közösség, projektek, IDE

Közösség, projektek, IDE Eclipse Közösség, projektek, IDE Eclipse egy nyílt forráskódú (open source) projekteken dolgozó közösség, céljuk egy kiterjeszthető fejlesztői platform és keretrendszer fejlesztése, amely megoldásokkal

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

Fogalmi modellezés. Ontológiák Alkalmazott modellező módszertan (UML)

Fogalmi modellezés. Ontológiák Alkalmazott modellező módszertan (UML) Fogalmi modellezés Ontológiák Alkalmazott modellező módszertan (UML) Fogalom képzés / kialakítás Cél: Példák: A fogalom képzés segít minket abban, hogy figyelmen kívül hagyjuk azt, ami lényegtelen idealizált

Részletesebben

Üzleti architektúra menedzsment, a digitális integrált irányítási rendszer

Üzleti architektúra menedzsment, a digitális integrált irányítási rendszer Üzleti architektúra menedzsment, a digitális integrált irányítási rendszer XXII. MINŐSÉGSZAKEMBEREK TALÁLKOZÓJA A digitalizálás a napjaink sürgető kihívása Dr. Ányos Éva működésfejlesztési tanácsadó Magyar

Részletesebben

Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K. 4. A meghirdetés ideje (mintatanterv szerint vagy keresztfélében):

Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K. 4. A meghirdetés ideje (mintatanterv szerint vagy keresztfélében): Követelményrendszer 1. Tantárgynév, kód, kredit, választhatóság: Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K 2. Felelős tanszék: Informatika Szakcsoport 3. Szak, szakirány, tagozat: Műszaki

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

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

TOGAF elemei a gyakorlatban

TOGAF elemei a gyakorlatban TOGAF elemei a gyakorlatban Vinczellér Gábor 2009.06.0406 04 8 éves szakmai tapasztalat Bemutatkozás IT Support, Programozó, jelenleg Projektvezető, Termékfejlesztési Üzletág Vezető Tanácsadási és Szoftverfejlesztési

Részletesebben

Feladataink, kötelességeink, önkéntes és szabadidős tevékenységeink elvégzése, a közösségi életformák gyakorlása döntések sorozatából tevődik össze.

Feladataink, kötelességeink, önkéntes és szabadidős tevékenységeink elvégzése, a közösségi életformák gyakorlása döntések sorozatából tevődik össze. INFORMATIKA Az informatika tantárgy ismeretkörei, fejlesztési területei hozzájárulnak ahhoz, hogy a tanuló az információs társadalom aktív tagjává válhasson. Az informatikai eszközök használata olyan eszköztudást

Részletesebben

VÁLLALATI INFORMÁCIÓS RENDSZEREK. Debrenti Attila Sándor

VÁLLALATI INFORMÁCIÓS RENDSZEREK. Debrenti Attila Sándor VÁLLALATI INFORMÁCIÓS RENDSZEREK Debrenti Attila Sándor Információs rendszer 2 Információs rendszer: az adatok megszerzésére, tárolására és a tárolt adatok különböző szempontok szerinti feldolgozására,

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

Absztrakció. Objektum orientált programozás Bevezetés. Általános Informatikai Tanszék Utolsó módosítás:

Absztrakció. Objektum orientált programozás Bevezetés. Általános Informatikai Tanszék Utolsó módosítá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

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

Oracle adatkezelési megoldások helye az EA világában. Előadó: Tar Zoltán

Oracle adatkezelési megoldások helye az EA világában. Előadó: Tar Zoltán Oracle adatkezelési megoldások helye az EA világában Előadó: Tar Zoltán Témák Bemutatkozás Enterprise Architecture bemutatása Mi az az EA? TOGAF bemutatása OEAF bemutatása Oracle megoldások Oracle termékek

Részletesebben

Sztöchiometriai egyenletrendszerek minimális számú aktív változót tartalmazó megoldásainak meghatározása a P-gráf módszertan alkalmazásával

Sztöchiometriai egyenletrendszerek minimális számú aktív változót tartalmazó megoldásainak meghatározása a P-gráf módszertan alkalmazásával Sztöchiometriai egyenletrendszerek minimális számú aktív változót tartalmazó megoldásainak meghatározása a P-gráf módszertan alkalmazásával * Pannon Egyetem, M szaki Informatikai Kar, Számítástudomány

Részletesebben

Programozás 1. 2.gyakorlat

Programozás 1. 2.gyakorlat Programozás 1. 2.gyakorlat Ismétlés Objektum: Egy a való világból vett elem (ami lehet elvonatkoztatott is) számítógépes ábrázolása. Pl: Kurzus, Személy stb Minden Objektum rendelkezik: Állapottal Viselkedéssel

Részletesebben

Tartalom. Szoftverfejlesztési. Szoftver = Termék. módszertan. la Rational XDE CASE eszköz. Az előállításához technológiára van szükség

Tartalom. Szoftverfejlesztési. Szoftver = Termék. módszertan. la Rational XDE CASE eszköz. Az előállításához technológiára van szükség Tartalom 6. Unified Process & Rational Unified Process lmi a szoftverfejlesztési módszertan? lunified Process lrational Unified Process (RUP) la Rational XDE CASE eszköz lpélda BMF-NIK-SZTI Tick: Szoftver

Részletesebben

Az üzleti modellek MDA-alapú transzformációja Objektum- és architektúraszemlélet fejlesztési stratégia

Az üzleti modellek MDA-alapú transzformációja Objektum- és architektúraszemlélet fejlesztési stratégia Stratégia Az üzleti modellek MDA-alapú transzformációja Objektum- és architektúraszemlélet fejlesztési stratégia DR. RAFFAI MÁRIA Széchenyi István Egyetem, M szaki Tudományi Kar, Informatika Tanszék egyetemi

Részletesebben

GENERIKUS PROGRAMOZÁS Osztálysablonok, Általános felépítésű függvények, Függvénynevek túlterhelése és. Függvénysablonok

GENERIKUS PROGRAMOZÁS Osztálysablonok, Általános felépítésű függvények, Függvénynevek túlterhelése és. Függvénysablonok GENERIKUS PROGRAMOZÁS Osztálysablonok, Általános felépítésű függvények, Függvénynevek túlterhelése és Függvénysablonok Gyakorlatorientált szoftverfejlesztés C++ nyelven Visual Studio Community fejlesztőkörnyezetben

Részletesebben

Használati alapú és modell alapú tesztelés kombinálása szolgáltatásorientált architektúrák teszteléséhez az ipari gyakorlatban

Használati alapú és modell alapú tesztelés kombinálása szolgáltatásorientált architektúrák teszteléséhez az ipari gyakorlatban Használati alapú és modell alapú tesztelés kombinálása szolgáltatásorientált architektúrák teszteléséhez az ipari gyakorlatban Nagy Attila Mátyás 2016.12.07. Áttekintés Bevezetés Megközelítés Pilot tanulmányok

Részletesebben

Vezetői információs rendszerek

Vezetői információs rendszerek Vezetői információs rendszerek Kiadott anyag: Vállalat és információk Elekes Edit, 2015. E-mail: elekes.edit@eng.unideb.hu Anyagok: eng.unideb.hu/userdir/vezetoi_inf_rd 1 A vállalat, mint információs rendszer

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

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

S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN. Structured Systems Analysis and Design Method

S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN. Structured Systems Analysis and Design Method S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN Structured Systems Analysis and Design Method Mi az SSADM? Kifejezetten a rendszerelemzést és a szoftverfejlesztést támogatja. Eljárási, műszaki és dokumentációs

Részletesebben

Fülöp Csaba, Kovács László, Micsik András

Fülöp Csaba, Kovács László, Micsik András Rendszerek Osztály Metaadatsémák nyilvántartása szemantikus web alapon Fülöp Csaba, Kovács László, Micsik András MTA SZTAKI Bemutatás A CORES az európai közösség projektje a Szemantikus Web témakörben

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

Programozási Technológia 1. 1. előadás bevezetés. Előadó: Lengyel Zsolt

Programozási Technológia 1. 1. előadás bevezetés. Előadó: Lengyel Zsolt Programozási Technológia 1. 1. előadás bevezetés Előadó: Lengyel Zsolt Tartalom Információk a tantárggyal kapcsolatban Programozási technológiai eszközök áttekintése UML tervezőeszközök JAVA fejlesztőeszközök,

Részletesebben

The Unified Software Development Process. Történet. Feltételek. Rational Unified Process. Krizsán Zoltán Ficsor Lajos

The Unified Software Development Process. Történet. Feltételek. Rational Unified Process. Krizsán Zoltán Ficsor Lajos The Unified Software Development Process Rational Unified Process Krizsán Zoltán Ficsor Lajos Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2007. 12. 04. Történet The Rational Rational

Részletesebben

Miskolci Egyetem Gépészmérnöki és Informatikai Kar Alkalmazott Informatikai Tanszék. Dr. Kulcsár Gyula egyetemi docens

Miskolci Egyetem Gépészmérnöki és Informatikai Kar Alkalmazott Informatikai Tanszék. Dr. Kulcsár Gyula egyetemi docens Miskolci Egyetem Gépészmérnöki és Informatikai Kar Alkalmazott Informatikai Tanszék Dr. Kulcsár Gyula egyetemi docens Tartalomjegyzék Bevezetés Termelési paradigma fogalma Paradigma váltások A CIM fogalmának

Részletesebben

Programozási technológia

Programozási technológia Programozási technológia Dinamikus modell Tevékenységdiagram, Együttműködési diagram, Felhasználói esetek diagramja Dr. Szendrei Rudolf ELTE Informatikai Kar 2018. Tevékenység diagram A tevékenység (vagy

Részletesebben

Miért is transzformáljunk modelleket? Varró Dániel

Miért is transzformáljunk modelleket? Varró Dániel Miért is transzformáljunk modelleket? Varró Dániel Mit látunk a képen? Tipikus kérdések (Hardvertervezés) Jól működik-e? 1+1 = 2? Hogyan készítsünk 8 bites összeadót 4 bites összeadóval? Hogyan készítsünk

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

A TANTÁRGY ADATLAPJA

A TANTÁRGY ADATLAPJA A TANTÁRGY ADATLAPJA 1. A képzési program adatai 1.1 Felsőoktatási intézmény Babeș-Bolyai Tudományegyetem 1.2 Kar Matematika és Informatika Kar 1.3 Intézet Magyar Matematika és Informatika Intézet 1.4

Részletesebben

Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18.

Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18. Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18. Két projekt Mindkettőben folyamatirányítás Eltérő követelmények Eltérő megoldások Dokumentum gyártási folyamat Üzemeltetés

Részletesebben

ANALYSIS PATTERNS MARTIN FOWLER ANALYSIS PATTERNS. Általános ismertető és Accountability Patterns

ANALYSIS PATTERNS MARTIN FOWLER ANALYSIS PATTERNS. Általános ismertető és Accountability Patterns MARTIN FOWLER ANALYSIS PATTERNS Általános ismertető és Accountability Patterns ELTE, 2010. 11. 25. Herczeg István iherczeg@inf.elte.hu 1 Mi az a 'ANALYSIS PATTERN'? Mi az a minta? MF minta (pattern) definíciója:

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

Magas szintű adatmodellek Egyed/kapcsolat modell I.

Magas szintű adatmodellek Egyed/kapcsolat modell I. Magas szintű adatmodellek Egyed/kapcsolat modell I. Ullman-Widom: Adatbázisrendszerek. Alapvetés. 4.fejezet Magas szintű adatmodellek (4.1-4.3.fej.) (köv.héten folyt.köv. 4.4-4.6.fej.) Az adatbázis modellezés

Részletesebben

Oracle Enterprise Metadata Management

Oracle Enterprise Metadata Management Oracle Enterprise Metadata Management Rövid bemutató Oracle Enterprise Metadata Management Gollnhofer Gábor 1 Tartalom Bevezetés a metaadatokhoz Oracle Enterprise Metadata Management - OEMM Összefoglaló

Részletesebben

Informatikai projektellenőr szerepe/feladatai Informatika / Az informatika térhódítása Függőség az információtól / informatikától Információs

Informatikai projektellenőr szerepe/feladatai Informatika / Az informatika térhódítása Függőség az információtól / informatikától Információs Bevezetés Projektellenőr szerepe és feladatai Informatika Informatikai függőség Informatikai projektek Mérnöki és informatikai feladatok találkozása technológiák 1 Tartalom Informatikai projektellenőr

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

Adatbázisok I 2012.05.11. Adatmodellek komponensei. Adatbázis modellek típusai. Adatbázisrendszer-specifikus tervezés

Adatbázisok I 2012.05.11. Adatmodellek komponensei. Adatbázis modellek típusai. Adatbázisrendszer-specifikus tervezés Adatbázisok I Szemantikai adatmodellek Szendrői Etelka PTE-PMMK Rendszer és Szoftvertechnológiai Tanszék szendroi@pmmk.pte.hu Adatmodellek komponensei Adatmodell: matematikai formalizmus, mely a valóság

Részletesebben

PROGRAMTERVEZŐ INFORMATIKUS ALAPKÉPZÉSI SZAK

PROGRAMTERVEZŐ INFORMATIKUS ALAPKÉPZÉSI SZAK PROGRAMTERVEZŐ INFORMATIKUS ALAPKÉPZÉSI SZAK 1. Az alapképzési szak megnevezése: programtervező informatikus (Computer Science) 2. Az alapképzési szakon szerezhető végzettségi szint és a szakképzettség

Részletesebben

Fogalomtár bevezetése a Magyar Telekomnál

Fogalomtár bevezetése a Magyar Telekomnál Fogalomtár bevezetése a Magyar Telekomnál Koncz Béla (MT) Tóth Rózsa (IQSYS) IQSYMPOSIUM, 2012. április 26 Tartalom 1. A projekt: Dilemmák és megoldások a Fogalomtár körül 2. Az eszköz: Funkciók és a működési

Részletesebben

Bevezetés. Szendrei Rudolf Informatikai Kar Eötvös Loránd Tudományegyetem. Programozási technológia I. Szendrei Rudolf. Bevezetés. Szoftvertechnológia

Bevezetés. Szendrei Rudolf Informatikai Kar Eötvös Loránd Tudományegyetem. Programozási technológia I. Szendrei Rudolf. Bevezetés. Szoftvertechnológia UML tervező JAVA fejlesztő és Informatikai Kar Eötvös Loránd Tudományegyetem 1 Tartalom 1 UML tervező JAVA fejlesztő és 2 UML tervező JAVA fejlesztő és 2 technológiai áttekintése UML tervező JAVA fejlesztő

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

Utolsó módosítás:

Utolsó módosítás: Utolsó módosítás: 2012. 02. 20. 1 Bonyolult rendszerekkel csak úgy tudunk dolgozni, hogy először egy egyszerűbb modellt építünk, megvizsgáljuk a rendszert különböző szempontokból. A modellezés nagyon általános

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

Autóipari beágyazott rendszerek Dr. Balogh, András

Autóipari beágyazott rendszerek Dr. Balogh, András Autóipari beágyazott rendszerek Dr. Balogh, András Autóipari beágyazott rendszerek Dr. Balogh, András Publication date 2013 Szerzői jog 2013 Dr. Balogh András Szerzői jog 2013 Dunaújvárosi Főiskola Kivonat

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

Modellezés és metamodellezés

Modellezés és metamodellezés Hibatűrő Rendszerek Kutatócsoport 2018 Tartalomjegyzék 1. Modellezés 1 2. Modellezési nyelvek 2 4. Absztrakció és finomítás 4 Irodalomjegyzék 6 3. Nyílt és zárt világ feltételezés 4 Bevezetés Ebben a fejezetben

Részletesebben

Szolgáltatásintegráció (VIMIM234) tárgy bevezető

Szolgáltatásintegráció (VIMIM234) tárgy bevezető Szolgáltatásintegráció Szolgáltatásintegráció (VIMIM234) tárgy bevezető Gönczy László gonczy@mit.bme.hu A tárgyról A tantárgy célja a hallgatók megismertetése a komplex informatikai rendszerek integrációs

Részletesebben

Data Vault 2.0 és az Oracle DW/BD referencia architektúra. Gollnhofer Gábor Meta Consulting Kft.

Data Vault 2.0 és az Oracle DW/BD referencia architektúra. Gollnhofer Gábor Meta Consulting Kft. Data Vault 2.0 és az Oracle DW/BD referencia architektúra Gollnhofer Gábor Meta Consulting Kft. Az Oracle referencia architektúrák Rövid bevezető Az IT Strategies from Oracle (ITSO) része Átgondolt, bevált,

Részletesebben

Modellek dokumentálása

Modellek dokumentálása előadás CAD Rendszerek II AGC2 Piros Attila Budapesti Műszaki és Gazdaságtudományi Egyetem, Gép- és Terméktervezés Tanszék 1 / 18 DOKUMENTÁCIÓK FELOSZTÁSA I. Felosztás felhasználás szerint: gyártási dokumentáció

Részletesebben

Földmérési és Távérzékelési Intézet

Földmérési és Távérzékelési Intézet Ta p a s z ta l a to k é s g ya ko r l a t i m e g o l d á s o k a W M S s zo l gá l tatá s b a n Földmérési és Távérzékelési Intézet 2011.03.13. WMS Szolgáltatások célja A technikai fejlődéshez igazodva

Részletesebben

Java I. A Java programozási nyelv

Java I. A Java programozási nyelv Java I. A Java programozási nyelv története,, alapvető jellemzői Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2007. 02. 12. Java I.: Történet, jellemzők, JDK JAVA1 / 1 Egy kis történelem

Részletesebben

Mesterséges Intelligencia Elektronikus Almanach

Mesterséges Intelligencia Elektronikus Almanach Mesterséges Intelligencia Elektronikus Almanach Dobrowiecki Tadeusz, Mészáros Tamás Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék MI Almanach a projekt

Részletesebben

Objektum Vezérelt Szoftverek Analízise

Objektum Vezérelt Szoftverek Analízise Objektum Vezérelt Szoftverek Analízise Ferenc Rudolf és Beszédes Árpád ferenc@inf.u-szeged.hu beszedes@inf.u-szeged.hu Szegedi Tudományegyetem FrontEndART Szoftver Kft. Bevezetés A szoftver rendszerek

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

A szak specializációi

A szak specializációi A szak specializációi Specializációk A specializációválasztás során a hallgatónak preferenciasorrendet kell megjelölnie, legalább két specializáció megadásával. A specializációkra történő besorolás a hallgatók

Részletesebben