Az informatika fél évszázados történetében a különbözõ új fejlesztési módszerek iránti igény és ezek bevezetése elõször mindig a programozás területén jelentkezett. A programtervezésben kipróbált és bevált módszereket késõbb átültették a szoftverfejlesztési életciklus teljes fázisára is, így biztosítva egy, az egész folyamatban egységes szemléletet. A 70-es évek elején új, strukturált programozási technikák és nyelvek jelentek meg, amelyek-bõl kizárták a bonyolult, áttekinthetetlen programokat eredményezõ go to utasítást, és amelyekkel biztosították a programok moduláris felépítését. Ezek a programnyelvek, mint például a N.WIRTH által kifejlesztett Pascal is, egy újfajta szemléletet honosítottak meg, számos elõnnyel rendelkeznek, többek között egyszerû és gyors programmódosítást tesznek lehetõvé, és tiszta, világos, adat-, és funkciószerkezetben való gondolkodást követelnek meg a programozótól. Az elemzési/tervezési munkát végzõ rendszerszervezõk hamar átlátták, hogy fel kell oldani azt az ellentmondást, ami a fejlesztési ciklus egyes fázisainak végrehajtásában alkalmazott eltérõ módszerek miatt mutatkozik. A strukturált programnyelvek megjelenése után a strukturált elemzési/tervezési módszerekre vonatkozóan is hamarosan napvilágot láttak Coad, Yourdon, Gane és Sarson, DeMarco és mások munkái, az elsõ publikációk. Azt mondhatjuk, hogy ezek a sikeres módszertani ajánlások szinte napjainkig fennmaradt és alkalmazott technikákká váltak.
A fejlõdés azonban nem állt meg! A grafikus elemek kezelését is lehetõvé tevõ, egyre nagyobb teljesítményû PC-k megjelenésével a programtervezõk megvalósíthatónak látták a 60-as évek végén, az objektum-kezeléssel kapcsolatban felmerült gondolatot. A 70-es évek elején kifejlesztett, OO kiterjesztésû LISP, vagy az objektumorientált Smalltalk az elsõ, sikeres kezdeményezés volt, ám a forradalmi gondolat csupán a 80-as évek második felében tudott meghonosodni az alkalmazásokban. Az új elképzelés szerint a programtervezõk komplexebb elemekben gondolkodnak, olyanok-ban, amelyek az adatszerkezeteken és az ezekkel végezhetõ mûveleteken túl egységesen képesek ke-zelni a valóság objektumait, a köztük fennálló kapcsolatokat pedig sokkal magasabb szinten valósítják meg. Az egymás tulajdonságait öröklõ, többszörösen felhasználható, egymással kommunikáló objek-tumok sokkal inkább hasonlítanak a valós világra, mint a J.D.Warnier, az M.Jackson féle adatszerkezet-lebontáson, vagy a Constantine-Meyers nevével fémjelzett funkciólebontáson alapuló tervezés komponensei.
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 beveze-tésére.
Az egyre gyorsabban terjedõ OO implementációs módszerek és programnyelvek, az objektum-orientált alkalmazásfejlesztõ 4G nyelvek és CASE eszközök mellett 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. Évtizedünk elsõ felében több, a gyakorlati projektekben eredményesen használt módszer vált ismertté. Egy rendszerfejlesztési projekt megvalósítási folyamatát, mint tudjuk a fejlesztés életciklus modellje írja le, amely valójában a feladatokat, azok egymásutániságát, a fejlesztési tevékenység iteratív módon történõ finomítását jelenti. A cél egy olyan cselekvés-sor meghatározása, amellyel minimálisra csökkenthetõ a fejlesztés kockázata, a szoftverrel szembeni elvárások és az eredmény közötti különbség.
A legtöbb modell a fejlesztési folyamatot fázisokra bontja. Az egyik legáltalánosabban ismert és alkalmazott modell az ún. vízesés modell, amely egymástól jól elkülöníthetõ, egymást lineárisan követõ diszkrét tevékenységekbõl áll. Ebben a folyamatban egy tevékenység csak akkor kezdõdhet el, ha az elõtte lévõt már befejezték. Vannak azonban olyan modellek is, amelyek a fejlesztési lépéseket nem szigorúan kötött sorrendben végzik, mint például az evolúciós, az inkrementális fejlesztés vagy a spirál modell.
Ismeretes a három alapvetõ fázis: (1) analízis, (2) tervezés és az (3) implementáció, amelyek a különbözõ modellek esetében további finomított lépésekbõl állnak. A fázisok feladatai egymástól meglehetõsen eltérõ tevékenységeket jelentenek, amelyeket a fejlesztési projekt által meghatározott paradigmák szerint, a kiválasztott módszerekkel és technikákkal végeznek. Tudnunk kell azonban, hogy az elemzési, tervezési és programozási/tesztelési feladatokhoz más és más módszerek és technikák állnak rendelkezésre, amelyeket azonban célszerû úgy megválasztani, hogy az a fejlesz-tendõ szoftver termék minõsége szempontjából a lehetõ leghatékonyabb legyen.
Számtalan kérdés merül fel:
2. A rendszerfejlesztés hibrid módszerei
A napjainkra már szinte általánossá vált objektumorientált programozási munkát az esetek többségében még hagyományos elemzési/tervezési módszerek elõzik meg. Jóllehet egyre szélesedik azoknak a fejlesztõknek a köre, akik az üzleti problémák megoldását szolgáló szoftver kifejlesztését objektumorientált szemléletben végzik, mégis egyenlõre sok olyan elemzõ/tervezõ munkatárs van, aki a szoftverfejlesztésben hibrid megoldásokat alkalmaz. A különbözõ módszerekkel készített eredmények azonban csak akkor használhatók a következõ fázis bemeneteként, ha azt megfelelõ módon átalakítjuk, a másik módszer számára érthetõvé tesszük. Ez azonban idõt vesz igénybe, és információvesztéshez vezet. Nem is szólva arról a hátrányról, ami a korszerûbb metodika lehetõségeinek a hagyományos korlátja miatti kihasználatlanságához vezet. Azt tehát egyértelmûen megállapíthatjuk, hogy az a módszer lehet a leghatékonyabb, amely a teljes életciklusban egységes szemléletet valósít meg.
A különbözõ fázisokban a strukturált és objektumorientált módszereket elvileg 8 féleképpen variálhatjuk [13], ezek közül azonban csak a legjellemzõbb lehetséges elõfordulások elemzésével foglalkozom.
2.1. S -S -O fejlesztés Strukturált elemzés/tervezés, objektumorientált megvalósítás
A fejlesztésnek ez a változata csupán az implementációhoz, a programozási munkához használ tiszta vagy objektumorientált technológiákat, az elemzési és tervezési munkát strukturáltan végzi. Az a fejlesztési projekt, amelyben tiszta objektumorientált programozási nyelveket alkalmaznak, így például Eiffel-t vagy Smalltalk-ot valójában megköveteli, hogy a tervezést is hasonlóan, objektumorientált szemléletben végezzük el. Strukturált tervezés esetében ugyanis szükségünk van a strukturált szerkezetnek és elemeknek objektumorientált komponensekké történõ átalakítására.
A hibrid nyelvek, mint például a C++ használata jól illeszkedik a struktúra szerkezetekhez, azokat kiválóan implementálja, azonban az eredmény nem lesz objektumorientált. Használatuk mégis javasolt, hiszen a procedurális programkódok így könnyebben alakíthatók át OO kódokká, és így a program rugalmasabban illeszkedik a meglévõ, sok szempontból objektumorientált hardver-szoftver környezethez.
2.2. S -O -O fejlesztés: Strukturált elemzés, OO tervezés és megvalósítás
Felismerve a tervezési és programozási módszerek különbözõségének problémáját egyre gyakoribbá válik, hogy a fejlesztõk a tervezési munkát is objektumorientált módon végzik. Marad az elemzési tevékenység, amelynél sok fejlesztõ még ma is azt gondolja, hogy nem lényeges, milyen módszert alkalmaz. Mivel azonban az egyes fázisok eredménye a következõ fázis inputja, ezért az elemzési eredményeket is alá kell vetni egy átalakító procedúrának kell alávetnünk annak érdekében, hogy a strukturált elemekbõl objektumokat kell generálni. Ez azonban nem egyszerû feladat, számtalan probléma merül fel. A hagyományos, strukturált elemzési eredménye többek között az (1) egyed-kapcsolat diagram, valamint az (2) adatfolyam-diagram. Ezzel szemben az objektum-orientált elemzési/tervezési módszerek alkalmazásakor osztályokat definiálunk, osztályhierarchia és tranzakció-elemzõ diagramokat készítünk. Ha most egy strukturált egyedbõl akarunk osztályt konvertálni, akkor egy sor tulajdonságot, jellemzõt, vagy éppen a kapcsolat módját nem tudjuk meghatározni. Ennek alapvetõ oka, hogy az elemzés során nem erre koncentrálunk, az absztrakció során nem objektumokat definiálunk, hanem csak attribútumokkal leírt egyedeket.
Az osztálydiagram megmutatja az osztályok közötti aggregációs kapcsolatot, az öröklõdést, szemléltetni tudja a hármas kapcsolatot, de arra is alkalmas, hogy ábrázolja, milyen funkció szerint kapcsolódik az egyik osztály a másikhoz. Ezeket a jellemzõket az ER modellbõl nem tudjuk meghatározni, hiszen valójában az osztályt abból az egyedbõl vezetjük le, amelyre vonatkozóan nem ismerjük a hozzárendelhetõ mûveleteket.
Többen foglalkoztak a különbözõ tervezési módok outpujainak transzformálásával, így például Alabiso (1989), Wassermann (1990) vagy Ward, aki az ER modellbõl próbálta levezetni az osztályok közötti öröklõdési kapcsolatokat. Ezek a kísérletek azonban nem vezettek az elvárt eredményre.
3. Objektumorientált fejlesztés elõnyei a strukturálttal szemben
Az objektumorientált fejlesztési életciklus eltér a hagyományostól, bár alapvetõen ugyanúgy három fázist tartalmaz: (1) analízis, (2) tervezés és (3) implementáció, de jól látható, hogy vannak olyan feladatok, amelyek fázisba sorolása nem egyértelmû. Ha a hagyományos életciklus modelleket tekintjük, akkor a fejlesztés fokozatos finomítása, iterativitása miatt az objektumorientált fejlesztés életciklusát. leginkább talán az inkrementális modellhez hasonlíthatjuk Mint tudjuk, az információrendszerek strukturált fejlesztése 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. Az objektumorientált elv alkalmazásának legfontosabb elõnye, hogy a fejlesztési ciklus minden fázisában ugyanazt az objektum modellt használjuk. Jóllehet több olyan közös technika létezik, amely a különbözõ fejlesztési fázisokban egyaránt alkalmazható, mégis különbség van az egyes fázisok között. Míg az elemzési fázisban egy szervezeten belüli üzleti folyamatok, szerepek és szabályok legmagasabb szintû objektum-modelljével foglalkozunk, addig a tervezési fázisban ezek finomítására kerül sor, olyan újabb objektumok bevezetésére, amelyek a felhasználói kommunikációt (dialógusok, outputok), a tranzakciókat valósítják meg. Az ilyen objektumok és alkalmazások közvetlen módon implementálhatók OOP nyelvekkel.
3.1. Elemzési fázis
Az objektum modell technikái lehetõvé teszik, hogy a valóságnak egy a korábbinál sokkal mélyebb absztrakcióját végezzük el, konzisztensebb modelljét hozzuk létre. Az objektum-osztályok, amelyeket attribútumaikkal és viselkedésükkel együtt kezelünk sokkal közelebb állnak az emberi gondolkodáshoz, a dolgokról alkotott képhez, mint az adat- és funkcióstruktúrák. A létrehozott osztályok és ezek hierarchiája biztosítja, hogy egy késõbbi idõpontban, amikor a rendszer valamelyik pontján változás következik be, újabb felhasználói igény jelentkezik, vagy más alrendszert fejlesztünk, akkor ezek a meglévõ objektumok és a hierarchiában alatta lévõ, a felsõbb osztályok attribútumait öröklõ osztályok egyszerûen használhatók minden tulajdonságukkal együtt már alkalmazásokhoz is, vagyis újra felhasználhatók. És végül a GUI környezet segítségével könynyen lehetõvé válik a felhasználói interfészek tervezése és szükség szerinti módosítása is.
3.2. Tervezési fázis
Minden fejlesztési módszer és munka célja olyan tervet készíteni, amelynek eredménye egy, a problémát és annak környezetét reálisan leíró, egyértelmûen specifikált modell, amely könnyen implementálható és a késõbbiekben egyszerûen karbantartható. Bár eddig három alapvetõ életciklus fá-zisról beszéltünk a tiszta OO szemlélet alkalmazásánál mégis látnunk kell, hogy nem lehet olyan éles határt húzni az elemzési és tervezési munka fázisai közé, mint a strukturált fejlesztésnél. Már az elemzés során osztályokat specifikálunk, ami valójában tervezési feladat, ugyanakkor a tervezési fázisban létrehozott osztály-hierarchiát további elemzések után újabbakkal bõvítjük. Ezzel valójában az inkrementális fejlesztési jelleg domborodik ki, a rendszer részekbõl való felépítése, a modell fokozatos finomítása, az iteráció.
A tervezési fázisban a strukturált módszereknél is nagyobb hangsúlyt kap a modularitás valamint a rendszer moduljainak egymástól való függõsége. Az objektum-modellnél a modulkapcsolatok alapvetõen kétféleképpen realizálódnak az osztályok között: (1) egy osztály magában foglal egy másikat, vagy (2) két osztály egy interfésszel kapcsolódik egymáshoz, vagyis egy objektumra mutató pointer paramétere lehet egy másik objektumot hívó eljárásnak.
Fontos megemlíteni a másik nagyon fontos jellemzõt, a kohéziót. Az OO tervezés nagy hangsúlyt helyez a rendszerelemek belsõ kötésének szorosságát meghatározó kohézióra, és a szekvenciális kötõdés mellett a legerõsebb kohéziót, a funkcionális összetartozást preferálja.
4. Számítógép a fejlesztésben - CASE eszközök
A elemzés/tervezés feladatait, a fejlesztési munka eredményét a verbális leírás mellett különbözõ ábrázolási technikákkal szemléltetjük, amelyek könnyen áttekinthetõek, és rengeteg információt hordoznak. Vannak azonban olyan problémák, amelyek csak verbálisan kezelhetõk. Az OO fejlesztésnél bevezettek új koncepciókat (polimorfizmus, dinamikus kötés), amelyek szimbolikus ábrázolása még nehezebb. Szükség van tehát olyan eszközökre, amelyek hatékonyan támogatják az elemzés/tervezés feladatait, kezelik és nyilvántartják a fejlesztési eredményeket, irányítják a projekt munkát. Sajnos azonban nem minden OOA&D módszerhez áll rendelkezésre megfelelõ CASE eszköz, vagy olyan technikák segítik az elemzési/tervezési munkát, amelyek eredetileg strukturált tervezéshez készültek.
Szerencsés, ha rendelkezésünkre áll egy CASE eszköz, amely oly módon segít a teljes életcik-lusban, hogy a problémamegoldást legjobban támogató módszereket és technikákat alkalmazhatjuk. Ilyen CASE eszközök az OMT, Fusion, Booch, OOCL, Martin/Odell, Shlaer/Mellor, Coad/Yourdon módszereket valamint az UML-t támogató Paradigm Plus, a Martin/Odell féle módszertant támoga-tó PTech CASE eszköz vagy a Booch'93, OOSE, OMT, UML módszereket felajánló Rational Rose Family szoftvercsalád. Bár egy CASE eszköz megvásárlása meglehetõsen magas ráfordítást igényel hosszú távon megéri a befektetés, hiszen gyorsabban, a fejlesztés során elkövethetõ hibák minimálisra szorításával, a felhasználói igényekhez való jobb alkalmazkodással könnyen karbantart-ható, hatékony szoftvert fejleszthetünk.
5. Következtetések
Az objektumorientált elemzõ/tervezõ módszerek alkalmazása, eredményeinek OO programnyelvekkel és OO adatbázis-kezelõ rendszerekkel történõ realizálása a szoftverfejlesztés teljes életcik-lusára nézve egységes szemlélet biztosít. Az OO fejlesztési életciklusban az egyes lépések többszörösen iterálódnak, az osztályok tervezésének top-down és bottom-up kevert módja lehetõvé teszi nagy és rugalmas rendszerek tervezését. Az így létrehozott osztályok a meglévõ és a jövõbeli projektekben is többszörösen felhasználhatók.
A fejlesztési munka különbözõ lépéseinek végrehajtásával párhuzamosan végezhetõ el az osztá-lyok implementációja, ami lehetõvé teszi, hogy a programozási munka lényegesen korábban elkezdõdhet, mint a teljesen kész terv. A projekt munkájában több feladat hárul a rendszerelemzõkre és -tervezõkre, az implementációs fázis ugyanis jól elõkészített és magas szinten automatizálható. Különös gondot kell fordítani az osztály-könyvtár fenntartására és karbantartására. Ezt a feladatot rendszerint egy felelõs könyvtár-menedzser végzi, aki garantálja a meglévõ objektumok újrafelhasználha-tóságát, a könyvtár bõvítését új osztályokkal és könyvtárakkal a szervezetbõl és kívülrõl egyaránt.
Bár nem kérdéses, hogy a teljes életcikluson végigfutó egységes szemlélet a leghatékonyabb, hiszen ez tudja csak garantálni, hogy az egyik lépés outputja optimális inputja legyen a következõnek, mégis bizonyos esetekben indokolt lehet a módszerek és technikák kevert használata. Ilyen szituáció lehet például a jelenleg még magas fejlesztési költségek vagy az új módszerek fokozatos bevezetésének igénye. Annak eldöntése azonban, hogy a fejlesztés teljes életciklusában OO szemléletet valósítunk-e meg a projekt vezetõ feladata és felelõssége.
Biztos vagyok azonban abban, hogy a hibrid megoldások alkalmazása átmeneti állapot, ami megszûnik, ha a rendelkezésre álló, fejlesztést támogató szoftverek hozzáférhetõvé válnak a kisebb szervezetek vagy fejlesztõ-teamek számára is, és ha a fejlesztõk magukévá teszik az évszázad utolsó évtizedének elõremutató lehetõségét, az objektumorientált szemléletet.
