GYAKORLATORIENTÁLT UML-ALAPÚ FEJLESZTÉS OKTATÁSA A SZÉCHENYI ISTVÁN EGYETEM BSC MŰSZAKI INFORMATIKA SZAKÁN

Átírás

1 GYAKORLATORIENTÁLT UML-ALAPÚ FEJLESZTÉS OKTATÁSA A SZÉCHENYI ISTVÁN EGYETEM BSC MŰSZAKI INFORMATIKA SZAKÁN CURRICULUM OF THE UML-BASED SOFTWARE DEVELOPMENT AT SZÉCHENYI ISTVÁN UNIVERSITY Kovács Katalin, Molnár Csaba, Sziray József Széchenyi István Egyetem, Informatika Tanszék Összefoglaló A győri Széchenyi István Egyetemen őszén elsőként a mérnök informatika szak indult útjára a kétlépcsős rendszerben. Az UML-alapú fejlesztés című két féléves tárgy célja, hogy a hallgatók gyakorlatban is végigkövessék informatikai rendszerek kifejlesztésének lépéseit, megismerve a fejlesztési munka gyakorlati fogásait, elsajátítva a fejlesztői gondolkodás elveit. A fejlesztési munka sikeres elvégzéséhez a hallgatók a korábbi tanulmányaik során megismert RUP módszertan ajánlásait követik, a fejlesztési munkaszakaszok eredményeit az UML nyelv segítségével modellezik két, a fejlesztői körben is használt CASE eszköz, a Rational Rose és az Enterprise Architect támogatásával. Kulcsszavak rendszerfejlesztés, szoftverfejlesztés, módszertan, modell, UML, RUP Abstract At the Széchenyi István University in Győr the engineering IT major was the first to be started in the two-step system in the autumn of The aim of the two-semester course called UML-based development is to enable students to follow the steps of the development of IT systems in practice, thus get acquainted with the practical know-how, and learn the principles of development. In order to accomplish the development students follow the recommendations of the RUP methodology already familiar to them from previous courses. The stages of development are modeled with the help of the UML language supported by two CASE tools, the Rational Rose and the Enterprise Architect. Keywords system engineering, software engineering, methodology, model, UML, RUP 1

2 A műszaki informatika képzésben a BSc alapszak akkreditálása jelentős fordulópontot hozott, és egyben komoly kihívást jelentett a hazai felsőoktatási intézmények számára. A győri Széchenyi István Egyetemen őszén elsőként a mérnök informatika szak indult útjára a kétlépcsős rendszerben. A képzésben kiemelt hangsúlyt kapott azoknak a gyakorlati, szakmai ismereteknek és kreatív problémamegoldó képességeknek, kézségeknek a kifejlesztése, mely egyaránt képessé tesz a munkaerőpiacon való elhelyezkedésre és a tanulmányok folytatására. A BSc alapszakon az UML-alapú fejlesztés I. és II. névvel azonosított tantárgypáros azzal a konkrét céllal került elindításra, melyben nagy hangsúlyt kell fektetni az önálló gondolkodást igénylő hallgatói munkára és a csoportmunkában való együttműködés kézségének kialakítására. A tárgy hallgatása komoly feltételekhez kötött. A hallgatóknak korszerű adatbáziskezelő, programozói kézségekkel és rendszertervezési ismeretekkel kell rendelkezni. Az UML-alapú fejlesztés című két féléves tárgy célja, hogy a hallgatók gyakorlatban is végigkövessék informatikai rendszerek kifejlesztésének lépéseit, megismerve a fejlesztési munka gyakorlati fogásait, elsajátítva a fejlesztői gondolkodás elveit. [3], [7] A fejlesztési munka sikeres elvégzéséhez a hallgatók a korábbi tanulmányaik során megismert RUP módszertan ajánlásait követik [5], a fejlesztési munkaszakaszok eredményeit az UML nyelv segítségével modellezik két [4], a fejlesztői körben is használt CASE eszköz, a Rational Rose és az Enterprise Architect támogatásával. [2] 1. Az alapötlet Feladatként egy szabadidőközpont eddig papíron végzett adminisztrációját támogató szoftver elkészítését tűztük ki célul. A szabadidőközpont működtetésére egy nem létező céget alapítottunk. A megrendelő szerepkörben megbízást adó cég működési tevékenységét egy 19 oldalas Üzleti terv dokumentumban foglaltuk össze. A dokumentumot a tárgy indulásakor a hallgatók részére bocsátottunk. A dokumentum összefoglalta, hogy a cég mivel foglalkozik, milyen humán, ingatlan és pénzügyi erőforrásokkal rendelkezik, mik a céljai, mit tesz a célok elérése érdekében, jelenleg milyen informatikai infrastruktúrával rendelkezik. A hallgatók feladata az, hogy a fenti dokumentum és a megrendelőknek (oktatóknak) feltett kérdések alapján készítsék el az üzleti folyamatokat támogató szoftvert vagy szoftvereket a már korábban elsajátított ismeretekre alapozva, az összes fejlesztési lépést végigjárva. [1] 2. Az első félév tapasztalatai Az első órán ismertettük a tárggyal kapcsolatos, majd az első félévre vonatkozó tudnivalókat, elvárásokat. Ismertetésre került az Üzleti terv dokumentum tartalma, amely az egész feladat kiindulópontja volt. A feladat elindulásához meghatároztuk a szerepköröket. A fejlesztés megrendelői, tehát a szabadidőközpont tulajdonosai az oktató kollegák, míg a kivitelező cég alkalmazottaiként, vezetőiként a hallgatók vesznek részt a munkában. A hallgatók tesznek javaslatot hol, vagyis mely üzleti folyamatokhoz kell informatikai támogatás, melyek azok az üzleti folyamatok, amiket célszerű megtámogatni informatikával. Természetesen amikor szükséges, akkor az oktatók fejlesztői szemszögből is segítik a hallgatók munkáját, próbálják a helyes irányba terelni őket, de semmiképpen nem a kész megoldást elmondva számukra. A fenti szereposztással az volt a célunk, hogy amennyire csak 2

3 lehet, a hallgatók önállóan jöjjenek rá a szükséges teendőkre, megoldásra. A fejlesztési munka során minden lépés előtt röviden összefoglaltuk a már más tárgyakból elsajátított elméleti ismereteket, hogy a hallgatók tudják mihez kötni az órán elhangzottakat. A működést biztosító üzleti folyamatok lépéseinek pontos ismerete után gyakorlatban is megkezdődik a rendszerfejlesztési munka, aminek első nagy lépése az üzleti folyamatok modellezése (Business Process Modeling - BPM). A feladat megoldásához a hallgatók egy fejlesztési projektszervezetet alakítottak. Döntöttek a csoport tagjai közül a projektvezető szerepkörről és a projekt paramétereiről, mint a projekt célja, a projekt időtartama, döntési pontok, a projekt által végrehajtandó feladatok, előállítandó termékek (dokumentumok, modellek stb.), a projekt által használható eszközök (dokumentálást segítő eszközök, CASE fejlesztőeszközök stb.), segédanyagok stb. Áttekintve a kapcsolódó elméleti részeket ezzel megadva a továbblépés irányát megpróbáltuk rábírni a hallgatóságot, hogy az addigi ismereteik alapján próbáljanak elindulni valamilyen irányba. Az elinduláskor még több segítséget kellett nyújtani, mint a későbbiek folyamán, de néhány hallgató már ezen az órán is nagyon jó ötlettel, megoldási alternatívával állt elő. Az üzleti terv alapján elkészült az üzleti modell a business aktorok és workerek meghatározásával. A modell felépítését a hallgatókkal közösen, papíron kezdtük el összeállítani, majd mikor már mindenki átlátta a feladat lényegét, hogy pontosan mit szeretnénk a modellben leírni, akkor a dokumentálást elkezdtük az Enterprise Architect nevű szoftver segítségével. Az Enterprise Architect egy olyan CASE eszköz, amely a fejlesztési folyamat valamennyi fázisára ad támogatást. Képes az UML diagramokból a dokumentumok és a forráskódok előállítására is. Az eszköz használatának nagy előnye, hogy ha bármilyen specifikációt módosítunk a modellben, akkor azt a módosított elem összes előfordulási helyén átvezeti. Az üzleti modell részletes elkészítésére viszonylag sok időt szántunk, de ez érthető is, ugyanis ez az alapja a további munkának. Ha ez nem elég részletes, illetve hibás, akkor a minden igényt kielégítő szoftvertermék előállításának esélye minimálisra csökken. A BPM munkaszakasz lezárását követően kezdetét vette a szoftverfejlesztési munka, ami a funkcionális követelmények meghatározását célozta meg. A modellben a funkcionális követelményeket technikai use case-ekkel modelleztük. [6] A technikai use case-ek leírása során jó néhány vita bontakozott ki a fejlesztők között. Szinte minden hallgató máshogy próbálta megközelíteni a problémát, és így más megoldást javasolt, mint a többiek. Ez fejlődés szempontjából nagyon hasznos volt a hallgatók számára, ugyanis sok olyan megoldási alternatívát is megismerhettek, amire nem is gondoltak volna, illetve belekóstoltak a team munka rejtelmeibe, ahol nem biztos, hogy minden tag véleménye állandóan megegyezik. A fejlesztési megoldásokkal kapcsolatos vitákat általában hagytuk kibontakozni, várva, hogy mi fejlődik ki belőlük, azonban jó néhány alkalommal előfordult, hogy nekünk, oktatóknak kellett a végső döntést meghozni a továbblépés érdekében. Ezt a döntést csak akkor hoztuk meg, ha a hallgatók azután sem tudtak megegyezésre jutni, miután a lehetséges alternatíváik mellett felsoroltunk érveket és ellenérveket, annak érdekében, hogy ők lássák be, melyik alternatíva lehet az adott helyzetben a célravezetőbb. Azt viszont igyekeztünk hangsúlyozni, nem biztos, hogy mindig csak egy megoldás létezik az adott problémára, és az a legjobb, amit végül is választottunk. A fejlesztési feladatok helyes megoldása mellett fontosnak tartottuk, hogy a hallgatók képesek legyenek kompromisszumokat kötni annak érdekében, hogy a végső cél az adott keretek között a lehető legjobban megvalósuljon. Az első félévben a hardver-szoftver architektúra meghatározása mellett hozzákezdtünk a rendszer belső működésének megtervezéséhez. Az elemzés/tervezés (Analysis/Design) 3

4 munkaszakaszban a belső működés leírását use case realizációkkal modelleztük, ám azok részletes kidolgozására már ebben a félévben nem került sor. [6] Olyan szempontból viszont hasznos volt, hogy a második félév elején a hallgatók már aktívan tudtak a belső működés megvalósítási kérdéseivel foglalkozni. Az első félév tapasztalatait összefoglalva elmondhatjuk, hogy a hallgatók számára a technikai use case-ek kidolgozása volt a nagy kihívás és leginkább időigényesebb feladat. Azzal igyekeztünk gyorsítani a munkát, hogy otthoni feladatnak mindig kiadtuk előre a következő heti modellek elkészítését, ezzel ösztönözve a hallgatóságot, hogy legalább egyszer átgondolják az adott problémát. Az otthoni feladatok kijavítása természetesen plusz munkát rótt az oktatókra, viszont a hallgatókat rákényszeríttette arra, hogy az órákon kívül is foglalkozzanak a témával. Azok a hallgatók, akik rendszeresen készítettek otthoni feladatokat, azoknak a munkáját beleszámítottuk a félévi teljesítménybe. 3. A második félév feladatai A második félévben a hallgatók megismerték, hogy az összeállított elemzési/tervezési modellek alapján hogyan kell webes és desktopos alkalmazások teljes implementálását végrehajtani. A desktopos alkalmazás implementálása Java fejlesztőkörnyezetben történt, amihez szükség volt a Java Development Kit keretrendszerre és egy IDE fejlesztő környezetre (Eclipse). A hallgatósággal a webes alkalmazás megvalósításához szükséges szerverkörnyezet is részletesen átbeszéltük (PHP esetén Apache szerver, JSP esetén Tomcat szerver). A fejlesztett szoftver-rendszer működéséhez szükséges adatokat tárolásával kapcsolatos kérdéseket is tisztáztuk. A hallgatók az adatbázis adatainak tárolásához a MySql adatbázis kezelő rendszert használták, a tesztelési feladatokat is megoldva a validációs tesztelés elvégzéséhez use case-alapú tesztelést végeztek, amihez teszteseteket is írtak. A félév lezárásaként felhasználói dokumentációt készítettek. A második félév elején átismételtük az előző félévben elkészített modelleket, majd kitűztük a félév céljait. Ezek között két hangsúlyos pont volt, az egyik az adatok tárolásához elengedhetetlen adatbázis megtervezése és létrehozása, a másik pedig egy szoftver készítése, mely ha nem is az összes, de néhány funkciót megvalósít a tervezett feladatból. Sajnos az órák száma nem tette lehetővé, hogy egy komplex, minden a követelménymodellben vázolt funkciót megvalósító szoftver elkészülhessen. A cél nem is az volt, hogy egy akár kereskedelmi forgalomban is a helyét megálló program készüljön, hanem az, hogy néhány funkció elkészítésén keresztül a hallgatók megismerjék azokat az alapvető fejlesztési szempontokat, gyakorlati fogásokat, amiket egy ilyen jellegű alkalmazás fejlesztésénél be kell tartani. A hallgatók lehetőséget kaptak arra is, hogy féléves feladatot készítsenek a vizsga kiváltására. A féléves feladat egy-egy technikai use case-ben definiált működés részletes megtervezését, implementálást és tesztelését célozta meg. Pontosan meghatározásra kerültek az elkészítésre és a feladat elfogadására vonatkozó feltételek. A hallgatók kizárólag a félév során elkészült adatbázist használhatták az adatok tárolására és a modellből kiválasztott funkciót pontosan úgy kellett elkészíteniük, ahogy az a technikai use case-ekben le volt írva. Arra is volt lehetőség, hogy akár 2-3 fős csoportokban egy nagyobb részét készítsék el a szoftvernek, de egyénileg is lehetett otthoni munkát vállalni. Természetesen csak előre egyeztetett részfeladatot lehetett elkészíteni, annak elkerülése érdekében, nehogy többen is ugyanazt a munkát végezzék el. A kikötés az volt, hogy önmagában is értelmes és 4

5 működőképes legyen az elkészítendő funkció. A programot JAVA nyelven kellett elkészíteni, de egyéni egyeztetés alapján lehetőséget adtunk más programozási nyelv használatára is. A félév elején folytattuk a use case realizációk kidolgozását, ahol főleg eseménykövetési diagramok segítségével modelleztük a folyamatokat. Az idő rövidsége és a kitűzött célok elérése érdekében ezeket már nem fejtettük ki olyan részletesen, mint az üzleti és technikai use case-eket. A cél az volt, hogy a technikai use case-ek alapján a hallgatók önállóan is el tudják készíteni ezeket. A következő lépés az elemzési osztályok meghatározása volt. Itt különös figyelmet fordítottunk az entitás osztályok azonosítására, mivel ezek képezik a következő lépés, az adatbázis tervezésének alapját. Az elemzési osztályok elkészítéséhez nagy segítséget nyújtottak az SSD (System Sequence Diagram) és a szekvencia diagramok. A munka során a boundary és control osztályok részletesen nem készültek el, mivel ezek rengeteg időt vettek volna el a többi fejlesztési szakasztól. [6] Az adatbázis megtervezése egyik meghatározó pontja volt ennek a félévnek és egyben a fejlesztendő alkalmazásnak is. Miután viszonylag szerteágazó adatokat kellett tárolni, ezért különös odafigyelésre volt szükség az adatbázis tervezésénél. Nagy segítséget nyújtottak az előző lépésben elkészített entitás osztályok, de mivel a hallgatók előzőleg nem tanultak semmilyen tárgyból sem adatbázis tervezést, ezért a kezdeti próbálkozásaik korántsem voltak optimálisnak mondhatók. Kivételt képeztek azok a hallgatók, akik már készítettek adatbázis centrikus alkalmazást, az ő ötleteik, terveik egész jól megközelítették az optimális szerkezetet. A félév második felében kezdődött el az alkalmazás implementálása. Mivel az egész fejlesztés objektum-orientált szemléletben valósult meg és minden hallgató tanult JAVA nyelvet, azért értelemszerűen erre esett a választás. Sajnos a grafikus felületű JAVA programok készítése nem törzsanyag, de választható tárgyként néhány hallgató felvette, azért arra nem lehetett alapozni, hogy mindenki hasonló tudással rendelkezik. A szoros időbeosztás nem tette lehetővé, hogy részletesen átvegyük a grafikus felületek építését, ezért mindig csak azoknak a vezérlőknek a tulajdonságai kerültek ismertetésre, amik az adott funkcióhoz szükségesek voltak. A további egyszerűsítés érdekében vizuális editor segítségével készítettük el ezeket a felületeket. A programozás során a fő cél az volt, hogy a hallgatóknak bemutassuk a különböző technikai megoldásokat és lehetőségeket, amik az adott problémánál szóba jöhettek. Az alapkoncepció az MVC modell használata volt, amely elősegíti egy hatékony, átlátható, könnyen módosítható és nem utolsó sorban karbantartható kód előállítását. Igyekeztünk jól külön választani a grafikus felületeket, az adatbázist elérő és kezelő, valamint az üzleti logikát megvalósító osztályokat. Első lépésként felépítettünk egy olyan, jól strukturált és átlátható keretrendszert, amelybe beépíthető az összes funkciót megvalósító további osztály. A funkciók megvalósítása a technikai use case-ek és eseménykövetési diagramok alapján történt az elemzési osztályok felhasználásával. Az első funkciót előre részletesen megbeszéltük, majd ugyan a hallgatókat is bevonva, de inkább az oktatók által bemutatva készítettük el. A további funkciók megvalósításánál viszont már nagyobb önállósággal kellett részt venniük a hallgatóknak is. A félév végére elkészült egy néhány funkciót tartalmazó, letesztelt szoftver, ami a két félév fejlesztési munkájának megkoronázása volt. 4. Konklúzió 5

6 A két félév munkája és a tapasztalatok azt mutatják, hogy a két félév nem elegendő a tárgy céljaként meghatározott ismeretanyag olyan szintű bemutatására, elsajátítására, hogy az közvetlenül alkalmazható legyen egy valós fejlesztési probléma felmerülésénél, viszont jó alapot biztosít ahhoz, hogy nagyon kevés energia befektetésével a hallgató el tudjon indulni egy lehetséges megoldási irányba. Megfigyelhető volt, hogy azok a főleg levelezős hallgatók, akik hasonló munkát végeznek a kinti üzleti életben, sokkal könnyebben és alaposabban sajátították el az ismereteket, mint akik még soha nem vettek részt nagyobb volumenű fejlesztésben. Azok a hallgatók, akik rendszeresen készítettek otthoni feladatot és az órán is igyekeztek aktívan részt venni, sokkal könnyebben teljesítették az első félév követelményeit, mint akik a félév során többnyire passzívak voltak. Annak ellenére, hogy a féléves feladat a második szemeszterben fakultatív volt, mégis sok hallgató választotta az otthoni, önálló munkát. Mivel a feladat elkészítése során viszonylag sok energiát kell fektetni a modell átlátásába és megértésébe, ezért azok a hallgatók, akik készítettek ilyet, több gyakorlati tapasztalatot szereztek, és jobban átlátták az egész fejlesztést, mint akik vizsgát tettek a tárgyból. A tapasztalatokat figyelembe véve és levonva a következtetést úgy véljük, hogy a következő kurzuson kötelezően előírjuk az önálló féléves feladat készítését. Annál is inkább, mivel a vizsgán nincs lehetőség arra, hogy egy nagyobb volumenű feladatot készítsenek a hallgatók. Az elkészítendő program alapvetően grafikus felületű, viszont a tárgy kereteibe nem fér bele és nem is célja hogy grafikus JAVA programozást oktasson, itt a már megszerzett ismereteket kellene felhasználni a cél elérése érdekében. Sajnos nagy különbségek voltak a hallgatók között programozási ismeretek terén. A különbség abból adódott, hogy a grafikus JAVA programozás nem törzsanyag, de néhány hallgató választható tárgyként ezt is teljesítette. Mivel kötelezően előírni nem lehet egy másik választható tárgyat előtanulmányi követelményként, ezért a következő kurzuson a gördülékeny és hatékony munka érdekében csak azoknak a hallgatóknak javasoljuk a második félév felvételét, akik rendelkeznek ezekkel a szükséges grafikus felületek építésével kapcsolatos ismeretekkel. A tapasztalatok alapján és a fejlesztési munka során felmerült nehézségek ellenére úgy véljük, hogy a tárgyi blokk keretében oktatott korszerű rendszerfejlesztési, szoftverfejlesztési módszerek, fejlesztési praktikák, gyakorlati fogások nagymértékben hozzájárulnak ahhoz, hogy a hallgatók képesek legyenek a gazdasági problémák megoldásához vezető utat a megalapozott elméleti és gyakorlati tudással mérnöki szemléletben felismerni, a rendszer és szoftverfejlesztés során megtanult módszereket, metodikákat a problémamegoldás során a céloknak megfelelően alkalmazni. Irodalomjegyzék [1] Kovács, K.: A Unfied Software Development Method for the Business Innovation IDIMT-2001 Conference, Zadov, Czech Republic, [2] Sommerville, I.: Szoftver rendszerek fejlesztése, Software Engineering, PANEM Könyvkiadó, Budapest [3] Pressman, R.S.: Software Engineering, A Practitioner s Approach, Fifth Edition, McGraw-Hill Publishing Company, Unitied Kingdom, [4] Fowler, M Kendall, S.: UML Distilled: Applying the Standard Object Modeling Language, Addision-Wesley-Longman, Inc., USA,

7 [5] Jacobson, I. Booch, G. Rumbaugh J.: The Unified Software Development Process, Addision-Wesley, [6] Sziray J., Kovács K.: Az UML nyelv használata, 2006, ISBN , 176 oldal [7] Kovács K., Benyó B., Sziray J., Orbán G.: Szoftver rendszerek fejlesztésének oktatása a Széchenyi István Egyetem gazdasági informatika szakán, Informatika a felsőoktatásban 2005 konferencia kiadványa, Debrecen, augusztus 24-26, p 7, ISBN