Mérnöknek lenni annyit jelent: előre látni, hogy egy megvalósítandó rendszer/termék hogyan működik, viselkedik majd a hétköznapokban.

Átírás

1 Rendszertervezés A legtöbb hallgató már hallgató krában lehetőség kap arra - főleg itt, az Adatbázisk Labr keretein belül -, hgy rendszereket hzzn létre a tervezéstől és a megvalósításig. Igazából ez az egyetlen lyan munka, amely egy mérnököt mérnökké tesz. Sajnálats módn aznban, a rendszertervezés kimaradt az ktatási alapanyagból. Tíz percben nem tudnám összefglalni a lényegét, de legalább megpróbálk egy vázat mutatni arról, hgy miből is kell álljn egy rendszerterv, és ami talán még fntsabb: miért. A rendszertervezés célja, hgy egy jól működő rendszert álmdjn meg. A legtöbb hallgató (sőt, végzett mérnökből is túl sk) abba a hibába esik, hgy egy prblémát az első kínálkzó módn igyekszik megldani, nem törődve azzal, hgy milyen hsszú távú következményei lesznek majd a döntéseinek. Ezt a fajta gndlkdást hagyjuk meg a plitikusknak, jgászknak és közgazdászknak. Nem az a legfntsabb, hgy egy prbléma meg legyen ldva, hanem az, hgy ideális megldást találjunk rá. Két mérnököt egymástól, illetve a mérnököt a technikustól éppen az különbözteti meg, hgy mennyire jó az a megldás, amelyet egy prblémára tudnak adni, azaz mennyivel több szempnt szerint tud kielégítő megldást vagy lehetőségeket kínálni a közvetlen prblémamegldásn túl. Mérnöknek lenni annyit jelent: előre látni, hgy egy megvalósítandó rendszer/termék hgyan működik, viselkedik majd a hétköznapkban. Egy tipikus példa a rendszertervezés hiányára az - ezzel szinte minden szftverfejlesztő találkztt -, amikr egy szftveralkalmazás átadása után a megrendelő szembesül azzal a prblémával, hgy fgalma sincs, mit és hgyan csinál a szftverünk, mit, hl, hgyan lehet benne elérni, használni. Úgy érzi, a rendszer nem csak nehezen használható, de még körülményesebb is, mint a krábbi, jól megszktt módszer szerint dlgzni. Az alábbihz hasnló helyzettel is sk hallgató találkztt már biznyára. Amikr elkészült végre a nagy alktás (pl. házi feladat), de még valami kis nüansznyi dlgt kell módsítani a prgramkódn (pl. beszúrni egy összeadást egy váratlan szempnt szerint), akkr az percek helyett csak napk alatt sikerül, mert az egész prgramstruktúrát lényegében át kell írni a módsításhz. Az ilyen és a számtalan hasnló helyzet elkerülésének kulcsa az, hgy körültekintően járjunk el már a prgram kialakításának a legelején is. Számítsunk váltzáskra, prblémákra, hibákra - ezek mindig lesznek -, és készüljünk fel megfelelő módn azk kezelésére. A legtöbb hallgató, mérnök, infrmatikus ilyenkr persze azt vágja a fejemhez, hgy szrít az idő, meg gyrsan kell mindig mindent csinálni; kinek van ideje alapsan tervezni. A tervezés az infrmatikai rendszerfejlesztés elején valóban többlet ráfrdítást jelent, aznban ez bőven kmpenzálódik nem csak a fejlesztési (például a párhuzamsíthatóság kapcsán), a dkumentációs (felhasználói és ktatói kézikönyvek alapja maga az absztrakt terv) és a tesztelési szakaszban (látjuk, mit, mikr, hgyan kell ellenőrizni), de annak utóélete srán is (termékfejlesztés, marketing, testre szabás). A harmadik-negyedik alkalmmal pedig lyan rutinná válik az összetett tervezés, hgy a többlet-ráfrdítást alig fgjuk megérezni.

2 De miből is áll a rendszerterv? - legalábbis szerintünk. Funkcinális terv. A funkcinális tervnek a lényege az, hgy kncepcinálisan, nagy vnalakban, ha úgy tetszik 0. szinten végiggndljuk (lásd Prgramzás technlógiája), milyen szereplők (aktrk), funkciók (szlgáltatásk, feladatk), erőfrrásk (adatbázisk, eszközök, szftverek) és kmpnensek kerülnek egymással kapcslatba. A funkcinális terv az egyes elemekről leírja A teljes rendszer célját, mtivációját, helyét a világban (Bár ez a legfntsabb rész a szereplők igényei mellett, mégis sk dkumentumból kimarad. Fnts aznban látni, hgy a célk, a valós életbeli felhasználása az, ami alapján két lehetőség közül választunk, vagy valami mellett döntünk. Nagy, intézményi prjekt esetében itt kell szerepeljen, hgy ez hgyan illeszkedik az intézmény stratégiájába. Szkás ezt vezetői összefglalásnak, kitekintőnek is nevezni. Terjedelme max. 3-5 ldal.) Az egyes szereplők igényeit, céljait, szempntjait, ahgyan a rendszert használni szeretné (Szkás ezt igényspecifikációnak is nevezni. Terjedelme rendszerenként nagyn váltzó, a szereplők, szereplőtípusk számától jelentősen függ. Átlagsan, tapasztalataim alapján nagyjából 2-3 ldal/szereplő.) Az egyes kmpnensek szerepét, felelősségi és hatáskörét (Ügyelni kell arra, hgy a kmpnensek minél kisebb méretűre tervezzük, de mégis teljes feladatkat ldjanak meg. Ez egyrészt azért fnts, mert célfókuszált, de se nem túl speciális, se nem túl általáns kmpnenseket nagy valószínűséggel később újra fel tudjuk majd használni; másrészt pedig a feladatk párhuzamsítása, szétsztása, illetve a függetlensége a rendszer későbbi fejlesztése, javítása és ellenőrzése szempntjából ez az egyetlen kulcsfntsságú tényező. Kmpnensenként 0,5-1 ldalban összefglalható a lényeg.) A kmpnensek minimális infrmációigényeit, be- és kimeneti mezőit és állaptváltzóit (Lásd Jelek és rendszerek c. tárgy négypólusú világról szóló nézetét. A váltzóktól való függés, infrmációs igény általában a kmpnensek felelősségéből, szerepköréből általában származtatható, ezért azkkal összevntan kezeljük. Lényegében a legfntsabb interfész elemeket már itt definiáljuk, de nem megyünk abba bele, azk pntsan hgyan is nézzenek ki. Ez ugyanis függ még a teszteléstől és az adatbázisk szerkezetétől is -- esetleg a kapcslódó szabványktól, készként átvett szftverkmpnensektől.) Az egyes kmpnensek által használt erőfrrásk listáját, illetve azk specifikációját (Ha van krábbról hztt, ismert kmpnens, akkr azk felületének leírását, szabványk megnevezését és azk referenciáit, valamint a felhasználható adatbázisk, adattárak szerkezetét.) A megvalósítás tervezett prgramnyelvi környezetét és perációs rendszerét - részletes indklással (Száms prjekt a "szeretett" prgramzási nyelven és perációs rendszerre íródik még akkr is, ha van értelme más lehetőségen is eltöprengeni. Sk cég egyetlen prgramnyelvre specializálta magát, nekik nyilván nincs más alternatívájuk, bár a termékskálát ssem árt bővíteni. Minden más esetben aznban szükség van arra, hgy a megrendelő fejével gndlkdjunk és azt lássuk, hgy neki mire van szüksége; milyen költséggel, infrastruktúrával, saját erőfrrással tudja-e üzemeltetni. A döntés hátterét indklni, kait a munka flytatásáhz, környezetének megismeréséhez,

3 elkészültének körülményeinek megértéséhez felettébb szükséges. Terjedelme 1-3 ldal.) Tesztelési terv. A tesztelési terv a szftver üzembiztnságának, az ellenőrzésének, egyszersmind az átadásának követelményeit rögzítik. A tesztelési tervet a hallgatók és a rsszabb szftverfejlesztő cégek szinte mindegyike kihagyja. Az k, persze, egyszerű: sk, apróléks munka kell az elkészítéséhez. Miért hiba? Azért, mert egy jó tesztterv segíti a fejlesztőt a gyrs haladásban (tudja, mire kell figyelnie), láthatóak a kivételkezelés legfntsabb módzatai, tudjuk, hgy milyen körülmények és paraméterek között szabad futtatni a szftverrendszert, illetve az átadás-átvétel is könnyebben fgadtatható el a megrendelővel, hiszen rögzített, mit kell tudnia kezelni a rendszernek. A tesztelési tervnek egy jórészét nem a fejlesztőknek, hanem a megrendelőnek, vagy a megrendelővel közösöen kell/érdemes kialakítani. Mindegyik terv mérete erősen függ a rendszer bnylultságától - irányelvként 5-10 ldal/alacsny szintű kmpnenst érdemes rá számlni. A tesztelési terv elkészítéséhez legalább négy különböző nézőpntból érdemes gndlkdni. Gndlkdjunk kifejezetten a funkcinalitás teszteléséről és tesztelhetőségéről. Minden egyes mdul számára, esetleg a rendszer egésze számára tipikus helyes és tipikus helytelen(!) tesztvektrkat, bemeneti tesztadatkat érdemes gyártani. Ha nem túl költséges, akkr kimerítő tesztelést is végezhetünk. Rögzített véletlenszerű vagy a legfntsabb funkciók tesztelésére egyedi és kmbinált megldáskat is készíthetünk. Utóbbi azért lehet jó, mert nem csak azt detektálja, hgy hl a hiba, hanem azt is, hgy milyen funkció feldlgzása helytelen. A funkcinális terv legmeghatárzóbb elemeire is érdemes tételes, bjektívan ellenőrizhető tesztfeltételt, tesztadatt készíteni. Minden bemeneti tesztadat mellé az elvárt kimeneti adatt (vagy jelenséget) is rögzíteni kell. Készítenünk kell egy hibatűrési tesztet is, ami főleg magyar nyelvterületen lehet kritikus. Tesztelni kell azt, hgy hgyan viselkedik a rendszer nem rendeltetésszerű használatra - nem kz-e kárkat esetleg egy képzetlen felhasználó, vagy egy hirtelen fellépő nagy terhelés. Az utóbbit szktuk stressz tesztnek nevezni. A hibatűrés ellenőrzésének része szktt lenni az ellenségteszt, amikr kifejezetten a rsszindulatű támadásk célpntját meghatárzzuk. A teszt célja annak felderítése, hgy a kész rendszernek hl vannak gyenge pntjai. Nem baj, ha van ilyen, de az baj, ha ennek nincs a fejlesztő tudatában, azaz nem ismeri őket. A kész rendszer kiszlgálási ideje lehet kritikus. Például egy felhasználókat flyamatsan kiszlgáló szftverrendszer válaszideje nem lehet több 1-2 másdpercnél, mert a felhasználó kényelmetlennek fgja érezni a termékhasználatt. Éppen ezért a hatéknyság mérésére is érdemes bjektív méréseket, teszteseteket előállítani. A teszt célja az, hgy egyrészt a kritikus részeket aznsítsuk, másrészt a javítást és a javulást kimutathassuk. Sk esetben a knkurens termék hasnló tesztjét is célszerű elvégezni. Végül, de nem utlsó srban a szftver elfgadtatásának, valós környezeti tesztelését is érdemes megtervezni. A teszt célja, hgy a felhasználás zökkenőmentességét, elégedettségét, és általáns, nem csak a funkcinális használhatóságát mérje. A tesztterv általában azt tartalmazza, hgy kik, milyen körben, hl fgják a belső, ún. alfatesztelést, illetve a félnyilváns bétatesztet végezni. A terv hiányában prjektfinanszírzási prblémák is felmerülhetnek(!).

4 Üzemeltetési terv. Az üzemeltetési terv készítésének kiindulási pntja az a helyzet, amikr a rendszer -- előzetesen, fejben és papírn -- működik. A terv elkészítése srán lyan kérdésekre kell választadnunk, hgy a rendszert körülvevő személyzet hgyan fgja működtetni a rendszert, illetve tanítani a rendszerhasználatra a felhasználókat. A terv nagyrésze nem kritikus, azaz nem feltétlenül része teljes egészében a rendszertervnek. Két területre érdemes tehát fókuszálni az üzemeltetési tervet: A rendszert felügyelő felhasználók hgyan fgják mnitrzni, karbantartani, illetve vezérelni vagy szabályzni a rendszert. A terv egyfelől a naplózási és megjelenítési funkciókat, másrészt a rendszer szabadn állítható paramétereinek körét, illetve az állító felület kialakításának sajátsságait fglalja magában. Az üzemeltetési terv ez a fele mindenképpen benne kell legyen a rendszertervben, hiszen hibajelzéseket, kivezetéseket, szabad paramétereket már előre meg kell határzni. A terv prgramzói dkumentáció és az adminisztrátri kézikönyv legfntsabb elemeit is szkta már tartalmazni. (3-5 ldal/alacsny szintű kmpnens). A rendszer felhasználását segítő tréningek, tanflyamk ktatási anyagainak legfntsabb elemeit is érdemes összeállítani. A terv azért lehet fnts, mert ha az átadás környéként derül ki, hgy a szftver használatáhz nincs megfelelően képzett munkatársa a cégnek, akkr sem a tesztelés, sem a termék megfelelő felhasználása nem garantálható. Ilyen esetben szinte biznysan újra kell írni a szftvert, jelentősen leegyszerűsítve a működését. Az ktatási tananyagk előkészítése abban is segít, hgy a tervezési fázis srán jbban megértsük a célkörnyezet működését, a felhasználók gndlkdását. Adatszerkezeti terv. A legtöbb alkalmazás hátterében részben a csatlófelületek, részben a működési flyamattól független, önálló tevékenységet nem végző passzív eszközök, a tárlók állnak. Ezek kapcsán beszélünk interfész és adatbázis tervről. Mindkettő csak azután rögzíthető, miután a fenti tervek mindegyikét rögzítettük - az esetek többségében a krábban elkészítendő tervekből levezethető. Az interfész terv jelentősége az, hgy a rendszer egészét, párhuzams fejlesztését, illetve a krábban már említett funkciók beépítését lehetővé tevő interfészeket meghatárzzuk és rögzítsük. A terv mindig a megvalósítás minimális szeletét tartalmazza. Pl. bjektumrientált prgramzás esetében az interfész terv az sztályk minimálisan szükséges definícióját rögzíti. Az adatbázis terv a passzív erőfrrásk egységes leírását fglalja magába. A nevével ellentétben nem csak az adatbázis, hanem a naplófájlk definícióját is itt szkás megadni. Természetesen, a naplófájl tartalma erősen függ az üzemeltetés sajátsságaitól. Mivel a passzív erőfrrásk tipikusan közösen és függetlenül használt erőfrrásk, így a rendszertervből nem maradhatnak ki, enélkül a kmpnensek fejlesztése nem indulhat meg. Nincs rendszerterv adatszerkezeti terv nélkül! Megvalósítási terv. A megvalósítási terv az ktatásban leginkább bemutattt, illetve a legtöbb irdalmmal rendelkező terület. Száms módszertan, eszköz, támgatás van a jó megvalósítási terv elkészítéséhez. Éppen ezért a legfntsabb elemeit csak címszavakban említjük meg. A megvalósítási terv tartalmaz: magas szintű funkcinális flyamat ábrát, amely az idő függvényében mutatja be a prgram jellemző flyamatait pl. funkcinális dekmpzíció segítségével; időzítési vagy adattvábbítási diagramt, amely az egyes kmpnensek közötti üzenetváltáskat jellemzi; a bnyulaltabb, nem triviális funkciók, eljárásk pszeudkódját;

5 a megvalósítandó sztályk teljes definícióját, amely szuperhalmaza az adatszerkezetnél rögzített interfészeknek; végül az ún. use-case diagramk, amelyek egy adtt példán keresztül illusztrálják a helyes (vagy helytelen) működést. Képernyő terv. Iparművészeti hajlamaink kiélését szlgáló dkumentum, sk kép, alatta bőséges, nem szószátyár magyarázat. A terv legfntsabb tulajdnsága, hgy rögzíti, mit, mikr, hl és hva kell helyezni és egyetlen képernyőnyi méretbe belezsúflni, illetve mely ablakkból, felületekből milyen felületek, ablakk érhetőek el - elsősrban a use-case diagramkhz, valamint a célfelhasználók szkásaihz igazítva. A terv célja elsősrban ezen paraméterek meghatárzása, a többit szakavattt, ergnómiáhz és dizájnkérdésekhez jbban értő szakemberre illik bízni.