Nagy feladatra vállalkozik azonban az az intézmény, aki ezen a szakterületen eleget kíván tenni a tudáspiaci elvárásoknak. A technológia folyamatos, gyors fejlõdése hatalmas kihívás az oktatási intézmények és azon oktatók számára, akik tudásuk legjavát adva kívánják a fiatalokat képezni. A probléma azonban nemcsak abban rejlik, hogy struktúrájában és tartalmában egyaránt változik és mennyiségileg növekszik a célszerûen oktatandó ismeretanyag, hanem abban is, hogy az új technológiák átvétele, alkalmazása elég gyakran komoly szemléletváltást is követel azoktól a munkatársaktól, akik alkalmazni, s különösen azoktól, akik oktatni szeretnék.

Ez felelõsségteljes feladatokat határoz meg a felsõoktatás számára, hiszen szükségessé válik

• az oktatók ismeretanyagának korszerûsítése, az új filozófiák és módszertanok megismerése (belülrõl fakadóan vagy valahogyan kívülrõl motiválva, ösztönözve),
• a tantervek átdolgozása, folyamatos illesztése az új technológiákhoz és a tudáspiaci elvárásokhoz,
• a szakmai ismeretek törzsanyagának és a választhatóan felkínált témák helyes arányának megválasztása,
• tantárgyi tematikák rugalmasan korszerûsíthetõ ismeretanyagának összeállítása,
• hatékony oktatási módszerek megválasztása és korszerûsítése,
• a hallgatók önálló, folyamatos tanulásra ösztönzése,
• oktatási anyagok (fóliák, slide-ok, feladatok, tudásszint-ellenõrzõ kérdéssorok, stb.), szakkönyvek, jegyzetek, segédletek készítése.

Bízva abban, hogy egy felsõoktatási konferencián az oktatókollégákkal közösen vitatva meg ezeket a kérdéseket megoldásra és együttmûködésre találunk, szeretnénk feltárni azokat a problémákat, amelyek magyar szakirodalommal ezen a téren még gyengén ellátott, múlttal, gyakorlati tapasztalatokkal nem rendelkezõ tantárgy (ismeretanyag) bevezetésével, az oktatói felkészüléssel, az ehhez szükséges irodalom beszerzésével (Internet anyagok, angol nyelvû szakkönyvek, konzultáció a témában úttörõ fejlesztõkkel), és ezek tanulmányozásával, az új ismeretek oktatásba történõ bevezetésével, a munkatársi és intézményi ellenállással kapcsolatban felmerülnek.

Rendszerfejlesztési ismeretek oktatása a SZIF-en
Fõiskolánkon csaknem egy évtizede folyik informatika szakos képzés, egyre növekvõ létszámmal (a 3 évfolyamon több, mint 500 hallgatónk van). Az Információrendszer-fejlesztés tantárgyi blokk súlyponti anyagát képezi az oktatásnak, a mûszaki informatika szakon 4 féléves, záróvizsgával illetve egyes szakirányokon szigorlattal záruló ismeretanyag. Folyamatosan figyelve a hallgatók elõrehaladását látjuk a problémákat, és arra törekszünk, hogy eredményesebb módszerekkel, mindig megújuló témákkal, módszerekkel és technikákkal több és korszerûbb, a gyakorlatban jól használható ismeretanyagot nyújtsunk a hallgatóknak.
A tantárgycsoport komplex anyagot ölel fel, a valós problémák szakmai ismereteibõl kiindulva alapos szoftverfejlesztési, -tervezési, számítástechnikai (hardver és szoftver), szervezési-vezetési, esetenként még oktatási készségeket is követel. A módszertanok megismeréséhez, az alkalmazási készség kifejlesztéséhez tehát szükség van arra, hogy a hallgatókat képessé tegyük a különbözõ tárgyakból szerzett ismeretek (számítástechnikai, programozási, adatbáziskezelési, matematikai, döntéselõkészítési, közgazdasági, projektirányítási stb.) integrálására és alkalmazására.
Az informatikában tapasztalható dinamikus fejlõdés nemcsak újabb és újabb eszközöket kínál, de a hatékonyabb alkalmazásokhoz a fejlesztõk új módszereket is javasolnak, sõt a korábbiaktól eltérõ filozófiákat látnak eredményesnek. Hogy lépést tartsunk a folyamatosan változó körülményekkel és igazodjunk az új lehetõségekhez, hogy a hallgatóinknak a legkorszerûbb ismereteket nyújtsuk folyamatosan módosítjuk az informatika szak tantervét, a tantárgyprogramokat, és ezen belül természetesen a Rendszermodellezés, Rendszerfejlesztés c. tárgyak tananyagát is. Megváltozik az alkalmazott oktatási módszer, a már elkészített oktatási anyagok, szakkönyvek, segédletek és a számonkérés módja is.
 

Az objektumorientált elemzési tervezési filozófia és módszertan oktatása
A SZIF informatikus képzésében nagy hangsúlyt kap a rendszerfejlesztés hagyományos paradigmáinak, módszereinek és eszközrendszerének oktatása, mindezideig azonban még csak szak-kollégiumokon, tudományos diákköri tevékenység keretében, valamint a közgazdászképzés informatika szakirányában foglalkoztunk az objektumszemléletû elemzési/tervezési módszertanokkal. Az 1996/97 tanévben végrehajtott tantervmódosításban azonban már úgy állítottuk össze a rendszerszervezõ szakirányú tantervet, hogy abban az 5.-6. Félévben helyet kapott az objektumtechnológia. Egy évünk volt a felkészülésre, és az elõkészületek megtételére, amelyhez nagy segítséget jelentettek a szakszemináriumok tapasztalati és a közben kidolgozott kéziratok.

Az "Objektumtechnológia" c. tantárgy tematikájának kidolgozásánál fontosnak tartottuk, hogy rávilágítsunk a hagyományos és az objektumorientált szemlélet eltéréseire, és megismertessük a hallgatókat az elmúlt évtized sikeres elemzési/tervezési módszertanaival, a fejlesztési fázisok teendõivel, és a tervezés során alkalmazható hatékony technikákkal. A tárgyoktatását 1998. szeptemberében kezdtük meg. Az alábbiakban röviden ismertetjük azokat a témaköröket, amelyeket az elsõ évben tanítottunk, illetve amelyeket az elsõ évi tapasztalatok alapján az oktatásba a jövõben mindenképpen beiktatunk.

Fejlesztési filozófiák hagyományos vs objektumorientált szemlélet

Mint tudjuk, a strukturált fejlesztés során a logikai tervezésnél élesen különválik az adatok és folyamatok tervezési szakasza. Az objektumorientált szemléletben ez valójában egységesen kezelhetõ, hiszen az objektumokhoz attribútumokat és mûveleteket egyaránt hozzárendelünk, és ugyanazt az objektum modellt használjuk a fejlesztési ciklus minden fázisában. Jóllehet több közös technika létezik, mégis különbséget kell tenni az egyes fázisok termékei között. Míg az elemzési fázisban egy szervezeten belüli üzleti folyamatok, szerepek és szabályok legmagasabb szintû modelljével, a követelményekkel és az ezt tükrözõ objektum-modellel foglalkozunk, addig a tervezési fázisban ezek finomítására és olyan újabb objektumok bevezetésére kerül sor, amelyek a felhasználói kommunikációt (dialógusok, outputok), a tranzakciókat valósítják meg. Ezek az eredmények képezik alapját a rendszerarchitektúrának, amely OOP nyelvekkel közvetlen módon implementálható [Raffai, 1997/1].

Ha nem azonos szemléletben folynak az egyes fázisok munkái, akkor az elemzési/tervezési eredményeket egy átalakító procedúrának kell alávetni annak érdekében, hogy a strukturált elemekbõl objektumokat lehessen generálni. Ez azonban nem egyszerû feladat, számtalan probléma merül fel, és mindenképpen fejlesztési információvesztéssel jár. Felismerve az elemzési, tervezési és programozási módszerek különbözõségének problémáját szükségessé válik, hogy a fejlesztés teljes életciklusában azonos szemlélet érvényesüljön.

Az objektumtechnológia fejlõdése, módszertanok

A hibrid, majd a tiszta OO programnyelvek megjelenése és gyors terjedése óriási lökést adott az objektumtechnológia széleskörû alkalmazásának, és csupán néhány évre volt szükség ahhoz, hogy bebizonyosodjon, az elemzési/tervezési munkában is szükség van az újfajta gondolkodásmód bevezetésére. Az egyre gyorsabban terjedõ OO implementációs módszerek és programnyelvek, az objektumorientált alkalmazásfejlesztõ 4G nyelvek és CASE eszközök mellett tehát egyre nagyobb igény jelentkezett a fejlesztés teljes életciklusát egységesen kezelõ OO elemzési és tervezési módszerek kidolgozására és alkalmazására. A '90-es évek elején több, a gyakorlati projektekben eredményesen használt módszer vált ismertté. Ezek közül az OODA-t alkalmazó fejlesztõk többsége (több, mint 35%-a) az OMT módszertant kedvelte és alkalmazta legszívesebben, ezért döntöttünk kezdetben mi is ennek a módszertannak a oktatása mellett.

Inkrementális, iteratív fejlesztés, az objektumtechnológia sajátosságai

A teljes életciklusban objektumorientált elveket követõ módszertanok kifejlõdésének folyamatát megismerve részletesen tárgyaljuk az objektumtechnológiának a korábbi módszertanoktól eltérõ sajátosságait, az egységbezárási, az öröklõdési jellemzõket, a polimorfizmust, a komponensek és relációk korábbi módszertanoktól eltérõ felfogását. Fontosnak tartjuk külön hangsúlyozni a fejlesztés inkrementális jellegét, hiszen az OOAD módszertanokban egy kezdeti modellbõl kiindulva a gyakorlati hasznosság és a felhasználói követelmények ismeretében történik a modell finomítása. Az egyes modell-elemeknek így több, nem szigorú sorrend szerint elvégzendõ lépésben különbözõ verziói jönnek létre. Ha a problémásabb részekkel kezdjük a munkát, akkor ezzel a fejlesztés kockázata csökkenthetõ.

Egyesített Fejlesztési Folyamat: Use Case alapú, architektúra-centrikus, iteratív és inkremantális

Bár 1998 szeptemberében Rumbaugh OMT módszertanával indultunk, a szakkönyvünk készítése közben a tanév végére kikristályosodott, hogy érdemesebb a legújabb, a vizualizációs szabványhoz illeszkedõ Booch, Rumbaugh és Jacobson egységes fejlesztési folyamat módszertanát oktatnunk. Az Egyesített Fejlesztési Folyamat módszertan kifejlesztésének gyökerei a '60-as évek végére nyúlnak vissza. Ivar Jabobson ekkor kezdett el dolgozni olyan megoldásokon, amelyekkel a rendszert egymással kapcsolatban lévõ blokkokkal modellezte. 1988-ban publikálta az Objectory-nak nevezett módszertan 1.0 verzióját, 1995-ben a Rational Software Incorporation-ben a módszertan egy kiterjesztett, továbbfejlesztett verzióját, a 3.8-at fejlesztették ki, majd Rational Objectory Process néven [Rational, 1998] publikálták a 4.1.-t. Az UML-nek szabványként való elfogadása arra késztette a három szerzõt, hogy a többi fejlesztõket is bevonja egy egységesített, közös fejlesztési módszertan kidolgozásába. 1998 júniusára készült el az az ajánlás, amely egy egyesített, egységesnek javasolt, a teljes életciklust lefedõ módszertan, a Rational Unified Process 5.0. [Booch et al., 1999]

Ez a tudásalapú, objektumorientált módszertan a követelménysepcifikációt a Jacobson féle Use Case technikára alapozza, hangsúlyozza a fejlesztés inkrementális és iteratív jellegét, és középpontba az újrafelhasználható komponenseket és az ezek architektúrájaként kialakított modellt állítja. Ezek a tényezõk indokolják, hogy az oktatott OMT módszertan helyett az Egyesített Fejlesztési Folyamatra váltsunk

A fejlesztés fázisai

Az Egyesített Fejlesztési Folyamat-módszertan alapján fázisonként részletesen foglalkozunk a különbözõ modellek jellemzõivel, a leképezési folyamat lépéseivel. Az elméleti ismeretek elsajátítását számtalan, valós problémát tükrözõ minta bemutatásával segítjük. Az egyes fázisok feladatainak részletes tárgyalását követõen esettanulmányt vitatunk meg, majd a hallgatók beszámolnak saját, teamben végzett fejlesztési munkáikról, a feladatvégzés problémáiról. A fejlesztési módszertant az alábbi fejezetenként tárgyaljuk:

• Követelményspecifikáció (Use Case modell-lel)
• Tervezés: objektummodell, alrendszerterv, interfészek és architektúra tervezés
• Implementáció és tesztelési stratégia, tervezés
• Kivitelezés, tesztelés
• Átállás, bevezetés, üzemeltetés, karbantartás tervezése.

1997-ben J.Rumbaugh, G. Booch és I. Jacobson az OMT [Rumbaogh et al., 1991], az OOADA [Booch, 1994] és az OOSE [Jacobson, 1994] koncepciók alapján egy olyan alkotásra, vizualizációra, dokumentálásra egyaránt alkalmas szimbólumrendszert, egy egyesített nyelvet (UML: Unified Modelling Language [Booch et al., 1998]) fejlesztett ki, amely kiváló kommunikációs eszköz nemcsak a fejlesztõk közötti, hanem a felhasználó-fejlesztõ együttmûködésében is. Az OMG által 1998 õszén modellezõ szabványként elfogadott jelölésrendszer célja egy olyan egységes szemantika és jelölésrendszer biztosítása, amely megoldást kínál a tervezés minden fázisában. Bár az UML alkalmazása önmagában nem garantálja a fejlesztés sikerét, mégis azt kell mondanunk, hogy használata jelentõsen lecsökkenti a betanítás, az átállás költségeit, lehetõséget biztosít a fejlesztési elvek, módszerek és eszközök hatékony integrációjára, és az üzleti folyamat-modellezési képességével valóban eredményes alkalmazásokat garantál.

Rational Rose'98 Case eszköz alkalmazása

A fejlesztéssel kapcsolatos módszerek és technikák elsajátítása után bemutatjuk a hallgatóknak a Rational Rose'98 Professional fejlesztõeszközt. A laboratóriumi foglalkozásokon kisebb részfeladatokat oldunk meg, és a hallgatók elkészítik a korábban tervezett rendszer tervét a rendelkezésünkre álló CASE eszközzel, majd saját tapasztalatuk alapján értékelik a számítógéppel támogatott fejlesztési lehetõség elõnyeinek kihasználásában rejlik.

Követelmények, feladatok, számonkérés

A hallgatók az elsajátított ismereteket különbözõ módon bizonyítják:

* mindkét félév vizsgával zárul, ahol az objektumtechnológiával kapcsolatos elméleti tudást kérjük számon,
* fejlesztési projekt kivitelezése:
• a hallgatóknak fejlesztõ team-eket kell alkotniuk, és meg kell jelölniük egy team vezetõt, aki menedzseli és összehangolja az 1 évig tartó projekt munkáját,
• a hallgatóknak valamilyen, általuk keresett valós munkahelyen, általuk választott, de általunk felülvizsgált és elfogadott témában rendszerfejlesztési munkát kell végezni,
• a fejlesztést manuálisan és CASE eszközzel is el kell végezni, a kész dokumentációt ütemezett módon, közbensõ részhatáridõkkel a 2. félév végére le kell adni,
* aktív részvétel a tréningeken,
* bemutatók, elõadások tartása a tárgyhoz kapcsolódó, választott témában.

A tervezési munka során a rendszertervezõ a valós problémák megismerésekor olyan helyzetekbe kerül, amelyek során fellépése, elméleti tudása, az információk begyûjtésének és rendszerezésének képessége a munka végeredményét nagymértékben befolyásolja. Különösen igaz ez az új szemléletû objektumtechnológia oktatása esetében. Ismerve az általunk képzett szakemberekkel szembeni elvárásokat nemcsak elméleti anyagot ismertetõ elõadásokat tartunk, hanem szemináriumokon (gyakorlatokon) a valós életben elõforduló szituációkat oldunk meg, mintákat mutatunk be. A hallgatóknak, illetve a hallgatói csoportoknak kiadott esetek közel állnak azokhoz a helyzetekhez, amelyek a gyakorlatban a tervezés során elõfordulnak. Míg a hagyományos oktatási rendszerben az elõadások egyoldalú kommunikációra épülnek az elõadó és a hallgató között, addig a szituációs gyakorlatok több teret biztosítanak a hallgatónak az aktívabb részvételre, a nyílt vélemény-nyilvánításra, a vitára, a helyes érvelésre, és így a tanulásban való igazi elmélyülésre. A tapasztalatok szerint azok az ismeretanyagok, amelyeket a hallgatók ezen a módon szereznek meg, sokkal nagyobb élményt jelentenek és ennél fogva maradandóbbak, mint az elõadásokon elhangzottak.

A szituációs gyakorlatok, esettanulmányok elemzésével, megoldási javaslatok készítésével a hallgatók a problémák széles skálájával kerülnek kapcsolatba. A leírt szituáció, a valós életbõl vett eset megismerése gondolatokat ébreszt, vitára szólít. A módszer lényege, hogy

• a hallgató elolvassa, megérti és végiggondolja a szituációt (ennek leírását legkésõbb egy héttel a gyakorlat elõtt megkapja),
• megfogalmazza a problémákat.
• elméleti tudását felhasználva meghatározza azokat az alternatívákat, amelyek a hatékony megoldás irányába vezetnek,
• elemezi az adatokat,
• meghozza a szükséges döntést és felvázol egy akciótervet.

Az oktatási módszerrel elérendõ célok:

• a hallgató egy eset leírása, felvázolása alapján legyen képes végiggondolni, megérteni a problémát,
• legyen képes problémaelemzésre, megoldási alternatívák kidolgozására és kiértékelésére,
• a vitában való aktív közremûködéssel, kérdések felvetésével, javaslatok tételével, õszinte véleménynyilvánítással növekedjék a hallgatók kreativitása,
• a valós szituációba tudja beleképzelni magát, tudjon vagy legalább próbáljon meg gondolkodni a felhasználó fejével.

• képes a különbözõ emberekkel, felhasználókkal való eredményes kommunikációra,
• a gyors és objektív helyzetfelismerésre,
• a körülményekhez igazított alternatívák felvázolására,
• a helyes döntések meghozatalára,
• álláspontjának, tervének elképzelésének megvédésére, és kivitelezésére,
• a lehetõ leghatékonyabb módszerek alkalmazására.

• A hallgatók elõre megkapják írásban a szituációt, esetet, amelyet megismernek, végiggondolnak, elemeznek, és egymás között megtárgyalhatják az eset különbözõ vonatkozásait. Az otthoni munkához szükség lehet bizonyos elméleti anyag áttanulmányozására, megismerésére, amelyhez az oktató javasolhat irodalmat.
• A szemináriumon az oktató ösztönöz azoknak az utaknak a végigjárására, amelyek a megoldáshoz vezetnek, és szükség szerint rávezet azokra a szempontokra, amelyek esetleg elkerülték a hallgatók figyelmét.
• Az elõkészítést egészséges vita, beszélgetés követi. A hallgató akkor hasznosít legtöbbet ebbõl, ha elõre felkészül és aktívan vesz részt ebben a vitában.
• A vita végén az oktató összefoglalja az elhangzottakat, felvázolja a tanulságokat és megfigyeléseket.

A beszélgetésekben, vitákban az oktató viszonylag passzív, a hallgatók egymással kommunikálnak, és valójában õk vezetik rá egymást a helyes megoldásra. Az effajta aktivitás pártolása mögött az a meggyõzõdés áll, hogy azoknak az embereknek a többsége, akik eredményesen kívánnak dolgozni gondolatébresztõ gyakorlatok útján tanulnak a leghatékonyabban, és nyílt viták, beszélgetések, vélemény-nyilvánítások útján képesek a tanulásban igazán elmélyülni.

Az objektumtechnológia szituációs gyakorlatain, a szakmai megbeszéléseken nagyon fontos szerepet kap a hallgatók fizikai elhelyezkedése, a légkör. A kreativitás akkor tud érvényesülni, a gondolatok akkor tudnak szárnyalni, ha biztosított a hallgatók közötti kötetlen beszélgetés, a közvetlen kommunikáció.

Elsõ alkalommal, amikor ilyen szemináriumot akartam vezetni engem is zavart, hogy a hallgatók nem igazán tudnak egymással beszélni, vitázni, gondolatokat cserélni. Az elsõ sorban ülõ hallgató nem látta a vele egy sorban ülõket, még kevésbé a mögötte ülõket. De a hátsó sorban elhelyezkedõ hallgatók sem érzékelték véleményük, gondolatuk hatását, hiszen az elõttük ülõknek csak a hátát látták. Nem tudtuk felforgatni másfél órára a termet, ezért azt javasoltam, hogy próbáljunk meg körben elhelyezkedni, úgy hogy mindenki lássa a másikat. Ez a hagyományos tantermi elrendezésben természetesen csak úgy tudtuk megoldani, ha a hallgatók felültek a padokra. Javaslatomra azonban elõször azonban nem mozdultak, úgy érezték, hogy csak viccelek velük, és valójában féltek a következményektõl. Miután harmadszor is kértem õket, az egyik vagány srác felült az ablakba (nálunk széles párkányok vannak viszonylag alacsonyan), és miután a többiek látták, hogy ebbõl semmi baj nem származik, kialakult a "kör". A többi szemináriumon már nem volt probléma az aktivitással, és a hallgatók véleménye szerint ez volt a legkedveltebb és legérdekesebb foglalkozás, amire mindig felkészülve és nagy várakozással jöttek.

Oktatást segítõ eszközök, anyagok, jegyzetek

Jegyzetek, segédanyagok, esettanulmányok

Az "Objektumtechnológia" c. tárgy bevezetésekor még nem állt rendelkezésre olyan tankönyv, amely a tervezett tematikának megfelelõen az elemzési /tervezési módszerekre épülve a fejlesztési életciklus elsõ két fázisának feladatait hangsúlyozná. Bár két kiváló hazai szakkönyv is foglalkozik objektumorientált elemzési/tervezési módszerekkel [Kondorosi et al., 1997], [Végh-Juhász, 1998], mindkét szakkönyv a programtervezési és programozási feladatokra helyezi a hangsúlyt. Mivel a rendszerszervezõ hallgatók számára az üzleti folyamatok, a szervezeti valós feladatok modellezésén van a hangsúly, ezért szükséges számukra egy, bizonyos mértékig más aspektust hangsúlyozó tan- és segédanyag. Bár egy ilyen kézirat már eddig is a hallgatók rendelkezésére állt [Raffai, 1997], ez kevésnek, és be kell vallanunk már elavultnak bizonyult. Ezért, részben oktatási tapasztalatainkat is felhasználva 1998-1999-ben elkészítettük a megjelenés alatt álló, fejlesztési esettanulmányt is tartalmazó "Objektumszemléletû rendszerfejlesztés vizuális modellezéssel" c. szakkönyvünket, [Kovács-Raffai, 1999].

Számítógépes támogatás

Az oktatásban kétféle, az ismeretátadást és a megértést segítõ eszköz áll rendelkezésünkre.

1. Az objektumorientált modellezési technikákat, a vizualizációt animáló számítógépes bemutató. Ez az eszköz a követelményspecifikáció fázisától kezdve a komponensek és az alkalmazások implementálásig végigkíséri egy probléma fejlesztési folyamatát, és iparági fejlesztési példákat mutat be.
2. A Rational Rose'98 Professional CASE eszköz, amely a vizuális modellezés, a tervezési munka UML szabványos modellezõ nyelven alapuló, számítógéppel történõ támogatása.

Konklúzió

Az elsõ év oktatási tapasztalatai azt mutatják, hogy a hallgatók értékelik a Tanszék törekvéseit, örömmel tanulják az objektumtechnológiát, és aktívan vesznek részt a feladatok megoldásában és a vitákban. A rendszerszervezõ szakirányos hallgatók többsége diplomatémaként is vagy egy objektumszemléletû rendszerfejlesztési munkát, vagy valamilyen, az objektumorientált elemzési/tervezési módszertanokkal, azok hatékonyságával kapcsolatos kutatási témát választott, illetve összehasonlító elemzésre vállalkoztak a hagyományos versus objektumorientált fejlesztéssel kapcsolatban.

Bár nem vonhatunk le messzemenõ következtetéseket a mindössze egyéves tapasztalatokból, mégis megállapíthatjuk, hogy az összeállított tematika, a készített segédanyagok, a kiadott és közösen megvitatott fejlesztési esettanulmányok, az alkalmazott oktatási módszertan, valamint a hallgatók véleménye és az elkészült diplomamunkák azt igazolják, hogy jó úton járunk. Ha a továbbiakban is képesek leszünk rugalmasan alkalmazkodni nemcsak a technológia kihívásaihoz, hanem a tudáspiaci elvárásokhoz is, akkor hallgatóink biztos álláslehetõséget és hosszú távon szakmai megbecsülést és sikereket remélhetnek.

Hivatkozások

[Booch et al., 1997] Booch, G. – Jacobson, I. – Rumbaugh, J.: Unified Modeling Language, -UML 1.0 - Rational Inc. USA

[Booch et al., 1998/1] Booch, G. – Jacobson, I. – Rumbaugh, J.: Unified Software Development Process - The Complete Guide to the Unified Process Addison-Wesley USA

[Booch et al., 1998/2] Booch, G. – Rumbaugh, J. - Jacobson, I.: The Unified Modeling Language User Guide – Addison-Wesley

[Booch, 1994] Booch, G.: Object-Oriented Analysis and Design with Applications - Benjamin-Cummings

[Coad-Yourdon, 1990] Coad, P.-Yourdon, E.: Object-Oriented Analysis - Prentice-Hall, Englewood Cliffs, N.J., Yourdon Press, New York

[Jacobson, 1994] Jacobson, I.: Object-Oriented Software Engineering: A Use Case Driven Approach - Addison-Wesley

[Kondorosi et al., 1997] Kondorosi, K.-László, Z.-Szirmay-Kalos, L.: Objektumorientált szoftverfejlesztés - Computerbooks, 1997

[Kovács, 1998] Kovács, K.: Objektumorientált módszertanok elemzése és bemutatás,a kiemelt hangsúlyt helyezve az UML szabványra - Diplomamunka

[Kovács-Raffai, 1999] Kovács, K.-Raffai, M.: Objektumorientált rendszerfejlesztés UML vizuális modellezéssel - NOVADAT Kiadó, megjelenés alatt

[Martin-Odell, 1992] Martin, J. – Odell, J.: Object-Oriented Analysis and Design - Prentice-Hall, Englewood, New Jersey

[Raffai, 1996] Raffai, M.: Objektumorientált elemzés/tervezés - Módszertan és esettanulmány- Jegyzet (kézirat)

[Raffai, 1997/1] Raffai, M.: OOAD versus SA/SD – Objektumorientált elvek a fejlesztési életciklusban - II. Országos Objektumorientált Konferencia, Visegrád

[Raffai, 1997/2] Raffai, M.: Object-Oriented Analysis and Design with Object Modeling Technique - Methodology and Case Study – tanulmány, Santa Clara, California

[Raffai, 1998] Raffai, M.: A hazai mikroszféra versenyképességét befolyásoló szervezeti, technológiai és tudáspiaci tényezõk - Empirikus vizsgálat - Kutatási tanulmány 675 fiatal diplomás megkérdezése és 865 hazai vállalat menedzsmentjével készített interjúk alapján

[Rational, 1998]: Automating Component-Based Development - Rational Software Inc

[Rumbaugh et al., 1991] Rumbaugh, J.-Blaha,M.-Premerlani, W.-Eddy, F.-Lorensen, W.: Object-Oriented Modeling and Design - Prentice Hall Inc.

[Ward, 1989] Ward, P.T.: How to Integrate Object-Orientation with Structured Analysis and Design – IEEE Software, March