GYURKÓ GYÖRGY * Üzleti alkalmazások tervezése objektumorientált megközelítéssel (Az elmélet és a gyakorlat összevetése)

GYURKÓ GYÖRGY* Üzleti alkalmazások tervezése objektumorientált megközelítéssel (Az elmélet és a gyakorlat összeve összevetése) Object-oriented Design of Business Applications (Theory and Practice) While the implementation is dominated by the object-oriented (OO) programming, there has not been a real breakthrough in the field of the OO design of business applications. The following statements can be made. a) The use of OO methods in the design of business application is not as evident as in the development of technical applications. b) The OO approach is applied less frequently in the specification of business logic than in the design of graphical user interface. c) Many times, the specification, created without OO tools is programmed in the OO way. In that case, the OO structured source code is required by the OO programming environment. d) Even if the OO design is applied it is used only according to some formal rules not the essential aims of the approach. The goal of the author is to give an overall picture of the relation between theory and practice, and to discover the reasons of the facts presented above, the consequences and the opportunities toward progress.

Bevezetés Miközben a megvalósítás terén ma már szinte egyeduralkodó az objektumorientált (a továbbiakban: OO) programozás, addig speciálisan az üzleti (és ügyviteli) alkalmazások tervezésében nem figyelhetı meg áttörı elırelépés az OO megközelítés irányában. Megállapítható, hogy a) az üzleti alkalmazások tervezésében az OO módszerek nem használatosak olyan „természetességgel”, mint például a mőszaki alkalmazások fejlesztésében; b) az OO megközelítés az alkalmazáslogika specifikációjában kevésbé jellemzı, mint a grafikus felhasználói felületek tervezésében; c) gyakran hagyományos megközelítéssel készült tervek alapján kell OO módon programozni, ilyenkor csak az OO programozási környezet kényszeríti ki, hogy a forráskód végül mégis OO szerkezető lesz; d) ha mégis van OO tervezés, az gyakran csak bizonyos formai szabályok követésében, nem pedig az OO szemlélet lényegi céljainak érvényesítésében nyilvánul meg. A szerzı célja átfogó képet adni az elmélet és a gyakorlat viszonyáról az utóbbiban részben személyesen szerzett tapasztalatok, részben szakértı kollégák beszámolói alapján; továbbá feltárni a fenti tények okait, következményeit és az elırelépés tényezıit, lehetıségeit. *

BGF Pénzügyi és Számviteli Fıiskolai Kar, Informatika Tanszék, fıiskolai docens.

296

GYURKÓ GY.: ÜZLETI ALKALMAZÁSOK TERVEZÉSE...

Mivel az elméleti oldal nem tartalmaz olyan ismeretet, ami a témába vágó alapmővekben ne lenne megtalálható, a gyakorlatról mondottak pedig nem irodalomra, hanem konkrét projektek tapasztalataira támaszkodnak, a dolgozathoz csak sovány forrásjegyzék csatlakozik.

Alapvetı szemléletváltás A korábbi hagyományos megközelítési módok és az OO megközelítési mód közötti éles szemléletváltás eredményeként az OO technológia • másfajta elemzıi, tervezıi szaktudást • és más eszköztárat kíván, mint a korábbi technológiák.

Az elemzıi és tervezıi szaktudás Az elemzı, tervezı (továbbiakban röviden tervezı) szakember gondolkodásában az OO technológiára áttérés azt a gyökeres váltást feltételezi, hogy az alkalma-

zást, amit addig utasítások sorozatának látott, ezután alkatrészek (objektumok) együttmőködésének (kommunikációjának) kell elképzelnie. A mőszaki szemlélet számára ez a megközelítés természetes, lévén kézenfekvı megoldás egy gép alkatrészei párhuzamos aktivitásának megfelelıen a gépet vezérlı szoftvert is konkurensen mőködı elemekbıl komponálni. Ezzel szemben az üzleti alkalmazások tervezıi nehezebben állnak át a OO gondolkodásra, mert bennük a tengernyi, korábbi kelető (ma is mőködı) rendszer fejlesztése során az a tapasztalat rögzıdött, hogy az üzleti logika mindig realizálható lineárisan egymás után végrehajtódó utasítások sorozatával. A Bevezetés a) megállapítása részben az itt elıadott tényeken alapul, részben pedig olyan tényeken, amiket a Költség-haszon alapú megfontolások c. rész tárgyal. Az üzleti rendszerek fejlesztésében (különösen az egyedi fejlesztések esetén) általánosan elterjedt gyakorlat volt, hogy a tervezık inkább csak a sztatikus struktúrákra (rekordtervek, adatmodell, képernyıtervek) koncentráltak, a rendszer dinamikus mőködésének kitalálását nagyobb részben rábízták a megvalósítókra. A feldolgozástervezés többnyire csak a kívülrıl is látható funkciók nagyvonalú specifikálására terjedt ki, és az alkalmazáslogika leírásában megállt a követelményszintő kifejtésnél. Az OO tervezés esetében ez a gyakorlat nem követhetı, mert az objektum = szerkezet + viselkedés képletbıl adódóan lehetetlen úgy objektumosztályokat definiálni, hogy a tervezı ne foglalkozzék a viselkedéssel, azaz a funkcionalitás osztályonkénti specifikálásával. Az elızı bekezdéssel összhangban hivatkozható lett volna az alkalmazás = objektumok együttmőködése (kommunikációja) képlet is, amibıl szintén következik, hogy a tervezı nem végezhet érdemi munkát, ha nem foglalkozik az együttmőködés mechanizmusával (forgatókönyvével). Az üzleti alkalmazások strukturált módszertanon és relációs adatmodellezésen nevelkedett tervezıi a korábbi és az OO technológia közötti formai hasonlóságok mentén próbálkoznak az OO technológia felé elmozdulni. Ilyen hasonlóság fedezhetı fel az egyedkapcsolat (ERD) diagram és az osztálydiagram technikák között. Konkrét projektekrıl szerzett tapasztalatok alapján elmondható, hogy az üzleti alkalmazások tervezésében az OO megközelítés ma még általában csak abból áll, 297

BUDAPESTI GAZDASÁGI FİISKOLA – MAGYAR TUDOMÁNY NAPJA, 2002

hogy az adatmodell ERD-jét átrajzolják osztálydiagrammá, nagyvonalúan elhanyagolva azokat a szemantikai különbségeket, amiket részletesebben Az OO technológia és a relációs adatbázis illesztése c. rész tárgyal, valamint azt a tényt, hogy az OO tervezésnek az adatbázisban tárolt objektumokon felül más természető objektumokat is definiálni kell. Az ilyen tervezés nem jelent érdemi segítséget a kivitelezık számára. A korábbi módszertanok szerint jószándékú amatırök is összebütykölhettek egy rendszertervet. Ha elszúrtak valamit, utólag valahogy helyre lehetett pofozni úgy, hogy a szoftver mégis mőködjön, legalább is amíg a környezetben nem állnak be a tervben számításba nem vett változások. Ezzel szemben az OO technológia már komoly szaktudást és kemény, mérnöki színvonalú munkát követel: Abból,

hogy az OO megközelítésnek fontos célja az újrafelhasználhatóság, következik, hogy a következetes OO tervezés szinte minden lépése szabványt teremt egy késıbbi lépés számára (pl. az ısosztály szabványt jelent a leszármazott alosztályok számára, egy interfész szabványt jelent a realizációi számára). Márpedig szabványt alkotni lényegesen szélesebb körültekintést, komolyabb szaktudást és konstruktivitást igényel, mint egy egyedi célú „egyszer használatos” terméket rögtönözni. A megfelelı mesterségbeli alapok hiányában készített OO terv nagy valószínőséggel éppen azokat a célokat nem teljesíti, amiért az OO technológiát kitalálták: az újrafelhasználhatóságot, a minél tágabb problémakörre érvényes általános megoldást, a szilárd alkalmazást. A Bevezetés d) pontjában említett jelenségnek ez az egyik fı oka; a másik az a megoldás, amikor a tervezés nem OO módon történik, de az alkalmazást végül mégis OO programozási eszközökkel valósítják meg. Ilyenkor a programozót érthetıen csak az adott eszköztárhoz illesztés kényszere motiválja; nem várható el tıle, hogy az üzleti logikát a tervezı helyett újragondolja.

A modellezı eszköztár Az eszköztár esetünkben modellezési technikákat (zömében diagramtechnikákat) és azokat támogató, integráló szoftvert – CASE eszközt – jelent. A jelentısebb fejlesztéseket végrehajtó szervezetek általában már régebben ráálltak valamilyen CASE eszköz alkalmazására. Ezt éppen arra számítva tették, hogy a CASE segítségével jobban megırizhetik a korábbi komplex fejlesztésekbe fektetett tudás és munka értékét, mert a CASE-ben tárolt rendszertervek konzisztens aktualizálása lényegesen könnyebben elvégezhetı (automatizálható); a papíron álló dokumentációval ellentétben a CASE-ben minimális ráfordítással elérhetı, hogy a rendszertervnek mindig a programkóddal szinkronban álló, aktuálisan érvényes állapota álljon a rendelkezésünkre; a közös CASE repozitóriumból a korábbi projektek által kifejlesztett tervkomponensek egy új projektbe könnyen átemelhetık. A technológiai váltás azonban nem lehetséges a régi technológiához kitalált eszközökkel (hacsak nem okosabbak az eszközök, mint a kitalálóik). Amikor a szervezet egy OO technológiára és azt támogató CASE eszközre tér át, egy ellentmondásos helyzetben találja magát: azért akar új technológiát bevezetni, mert az a korábban megszerzett szaktudás és befektetett munka újra felhasználására minden eddiginél hatékonyabb megoldást kínál, és emiatt olyan

298


új CASE eszközre kell átállnia, ami a korábbi CASE eszközben rögzített tudást nem tudja értelmezni. Ennek az ellentmondásnak a kezelésére nincs tökéletes megoldás, de mindegyik nagyon drága: • Ha a szervezet hosszabb távon jelen akar lenni a piacon, akkor a legdrágább megoldás, ha eláll a technológiai váltástól, mert akkor kizárja magát a versenybıl. • Ha hagyják veszni a korábbi eszközökkel rögzített tudást, akkor ezért az ismeretek ismételt megszerzésére és rögzítésére fordított munkával kell fizetni. • Harmadik lehetıség: a régi és az új technológiát egyaránt jól ismerı szakemberek bevonásával projektet alapítanak a korábbi CASE eszközben rögzített modelleknek az OO CASE alá migrálására. A megoldásban benne rejlik az a lehetıség, hogy a régi tudás nemcsak értelmezhetıvé válik az új eszköztár számára, de plusz tudással is kiegészül, és az OO megközelítés céljaival összevágó, tökéletes végtermék áll elı. Azonban ezt a koncentrált befektetést, aminek a megtérülése hosszabb idıt igényel, és ezzel arányos kockázattal is jár, valószínőleg sok cég nem engedheti meg magának. • A negyedik lehetıség egy olyan eszköz bevetése, ami a hagyományos CASE-ben rögzített modelleket automatikusan az OO CASE alá konvertálja. Ez egy bonyolult mesterséges intelligencia megoldás, ami csak relatívan olcsóbb a harmadikként említett lehetıségnél. Ugyanakkor a hagyományos és az OO megközelítés közötti koncepcionális szakadék miatt erısen korlátozott az ismerteknek az köre, ami egy automatikus modellkonverzióval megmenthetı. A probléma az, hogy a hagyományos modellekben rögzített ismeretek OO modellekbe átmentéséhez olyan további ismeretekre és meggondolásokra van szükség, amik a hagyományos modellekben nincsenek jelen és semmilyen mesterséges intelligencia módszerrel nem pótolhatók. (Ha nem így lenne, nem is kellene áttérni az OO technológiára.)

Költség-haszon alapú megfontolások Itt az eszköztár vonatkozásában már kifejtett meggondolások folytatódnak, de több tényezıre kiterjedı érvénnyel. A szállító (fejlesztı) szemszögébıl az OO technológia legfıbb hasznát az egymással szabadon kombinálható, újrafelhasználható, kitesztelt komponensek jelentik; valamint az, hogy az objektumokból összerakott szoftver könnyen karbantartható, lévén jól elemezhetı, benne a hiba helye vagy a szükséges módosítás helye minimális ráfordítással azonosítható. Ezek között több olyan tulajdonság van, aminek a haszna csak késıbb és feltételesen – a karbantartás vagy az újrafelhasználás alkalmával – jelentkezik, de súlyos és azonnali plusz ráfordítást feltételez. A Bevezetés a) megállapítása azzal is összefügg, hogy a mőszaki alkalmazások OO tervezése általában nem jelent különösebb plusz ráfordítást a nem OO tervezéshez képest, hiszen például a dinamikus modellezési technikákat az OO technológia is a mőszaki rendszerek modellezésének hagyományos eszköztárából vette át. Üzleti alkalmazások esetében más a helyzet. Ha az üzleti logika osztályait „nulláról indulva” kell kitalálni, mert arra még nem adottak kész, közvetlenül vagy ısosztályként felhasználható, kitesztelt osztályok vagy alkalmas tervezési 299


minták, akkor az újrafelhasználhatóságot szem elıtt tartó OO tervezés azt jelenti, hogy az aktuális projekt a késıbbi projektek elvárásait is megpróbálja teljesíteni. A Bevezetés b) pontjában megállapított tényt az magyarázza, hogy a grafikus felület elemei nagyon gyakran visszatérı, általánosan használt objektumok, esetükben az újrafelhasználhatóság garantáltan megtérül; sıt ezek osztályait már a fejlesztı környezet (programnyelv) szállítójának megérte elkészíteni, a programozónak csak fel kell használni készen kapott osztályokat. Az egyedi fejlesztési feladatok esetében nyilvánvalóan kisebb az esély arra, hogy az újrafelhasználhatóság érdekében tett erıfeszítések megtérülnek. A plusz ráfordítások nem terhelhetık a megrendelıre. A megrendelı (felhasználó) számára elvben közömbös, hogy a szoftver milyen technológiával készült, és különösen nem várható el, hogy a megrendelı finanszírozzon olyan ráfordításokat, amik késıbb nem neki, hanem a szállítónak térülnek meg. Viszont a megrendelések elnyerésében versenyelınyt jelenthet az a tény, hogy a termék jobb minısége – szilárdsága, megbízhatósága – szignifikánsan pozitív korrelációt mutat az OO technológia alkalmazásával. Egyedi fejlesztés esetén az is elınyös, ha a technológia elısegíti a szállító és a megrendelı (a fejlesztı és a felhasználó) közötti megértést. Az nem állítható, hogy az OO modellek (vagy általában az UML) megkönnyítenék a fejlesztı és a felhasználó kommunikációját, de a dinamikus modellezést nem hanyagoló OO terv arra alkalmas szoftverrel jól animálható olyan módon, hogy az animáció a tervezett mőködést a laikus számára is világossá teszi. Az OO technológiára átállás kikényszerítésében szerepet játszhatnak olyan megrendelıi igények, amik hagyományos technológia alkalmazásával (gazdaságosan) nem teljesíthetık. Tipikusan ilyen igényt jelent, ha valamilyen problémára nagyon általános érvényő megoldást kell adni. Például egy olyan rendszerre szóló megrendelés, amely minimális idın belül jogszabálykövetı. (Az OO technológia kézenfekvı megoldást kínál a jogszabályfüggı és a jogszabályfüggetlen részek elkülönítésére és közéjük alkalmas interfész definiálására úgy, hogy a jogszabályfüggı rész tetszıleges megváltozása esetén összekapcsolható a változatlan interfészen keresztül a szintén változatlan jogszabályfüggetlen résszel.)

Az üzleti alkalmazások speciális jellemzıi Az OO megközelítést tárgyaló alapmővek [1], [2] elsöprı többséggel mőszaki példákon mutatják be az OO módszereket. (Üzleti alkalmazások tervezésére is kínált CASE eszköz képességeit szemléltetı bevezetı példa egy kakukkos óra OO tervezésérıl szól.[10]) Vajon az üzleti alkalmazások természetében vannak olyan elemek, amik miatt az ilyen alkalmazások tervezésében lassabban terjednek az OO módszerek?

Az üzleti alkalmazások objektumai Az üzleti alkalmazások még ma is zömmel strukturált adatrekordokba szervezett egyszerő adattípusokkal: számokkal, szövegekkel, dátumokkal stb. dolgoznak, amik kényelmesen, hatékonyan és olcsón kezelhetık hagyományos módon. Az objektumreprezentációt erısebben igénylı komplex, nem strukturált multimédia adatok tömeges használata egyelıre kevésbé jellemzı. Az adatkezelés tekinte300


tében tehát nincs közvetlen hatékonysági kényszer az OO megoldások bevezetésére. A strukturált rekordokat objektumnak tekintve elmondható, hogy az üzleti alkalmazások nagy számú, de egyszerőbb objektumokat kezelnek. Ezek túlnyomó részben perzisztens objektumok, azaz olyanok, amelyek az ıket létrehozó alkalmazás futása után is tovább élnek. Tipikusan gyakori feladat az objektumok (megfelelı elérhetıséget biztosító) tárolása és az objektumok mozgatása a háttértár és az operatív memória között. Az üzleti alkalmazások túlnyomó részében az objektumok tárolására relációs, esetleg objektumrelációs [5] adatbázis szolgál.

Üzleti rendszerek architektúrája Az üzleti rendszerek elengedhetetlen komponense a központi adatbázis, amit közelbıl vagy távolból sok felhasználó használ, ki-ki az asztalán (vagy a táskájában) levı kliens munkaállomáson keresztül. A mai webes technológiával összhangban a munkaállomásokon felhasználói felületként leggyakrabban böngészık futnak (vagy a munkaállomáson használt programok böngészıbıl küldött kérésre töltıdnek le a kliensre). Az adatbázis (vagy adatbázisszerver) és a böngészı kliens közé általában beiktatódik egy webszerver, aminek a feladata a kliensektıl érkezı kérések fogadása, továbbá a kérések teljesítése céljából kommunikálás az adatbázissal, valamint az adatbázisból nyert adatokból HTML lapok összeállítása és letöltése a böngészıbe. E háromszintő architektúrából adódóan egyes objektumok az adatbázisszerveren mőködnek, mások a webszerveren, megint mások a kliens munkaállomáson, és végül vannak olyanok is, amik e rétegek között mozognak. Az elmondottakból következik, hogy az üzleti rendszerek esetében tipikus feladatnak számít a távoli objektumok kommunikációjának és az objektumok mozgatásának megoldása.

Az OO technológia és a relációs adatbázis illesztése A relációs adatbázis egy korábbi strukturált megközelítési mód szülötte. E technológiának nagy erıssége az SQL nyelv, ami a strukturált adatok kezelésére egyértelmően hatékony eszköznek bizonyult, a relációs adatbázisok világában általánosan elterjedt, így közöttük az átjárhatóságot biztosító eszköz, minden fejlesztı ismeri; következésképpen egy darabig még nem fog kimenni a divatból. Ugyanakkor az SQL eredeténél fogva nyilvánvalóan nem OO eszköz. SQL parancsokkal az adatbázis elemeit korlátlan változatosságú kombinációban lehet elérni. Ha az SQL-en számon akarnánk kérni azt az OO koncepciót, hogy minden mővelet valamelyik objektumosztály felelısségi körébe tartozik, és minden objektum csak az osztályának felelısségi körébe tartozó mőveletekkel manipulálható; akkor úgy találnánk, csak a teljes adatbázis az egyetlen olyan integritás, ami az SQLbıl kezdeményezett mőveleteknek ahhoz hasonlóan tárgya, mint a metódusainak egy objektum. Az OO technológia és a relációs adatbázis illesztése a tervezés során a hagyományos adatmodellezés és az objektummodellezés illesztését jelenti; a végtermékként elıálló alkalmazásban pedig annak a transzformációnak a mőködteté-

301


sét, ami az operatív memóriában egy objektumnak számító dolgot a relációs adatbázis egy vagy több táblasorának felelteti meg. A strukturált szemléletrıl OO szemléletre áttérni kívánó tervezı számára egyrészt jó fogódzónak számít az OO modell osztályaihoz az adatmodell egyedtípusai felıl közelíteni, másfelıl súlyos félreértések származhatnak abból, ha a kétféle modell közötti szemantikai különbségek nem tudatosodnak: • Egy ERD-nek és egy osztálydiagramnak akkor is lényegesen különbözik a jelentése, ha a kettı formailag izomorf egymással, és nemcsak azért, mert az egyedtípus nem rendelkezik viselkedéssel: Az egyedtípusok közötti kapcsolattípusokat a modellezett szakterület összefüggései, szabályai definiálják, a megvalósított adatbázisban pedig az egyedek kapcsolatai a tartalmi összetartozás szerinti adatelérést navigáló útvonalakat képeznek. Ezzel szemben az osztályok közötti asszociációk arról szólnak, hogy az osztályok példányai használják egymást, az asszociációk megvalósításai pedig az objektumok közötti üzeneteket közvetítı kommunikációs útvonalak. • Ami a relációs adatmodellben véglegesen leírható egyetlen egyedtípussal (egy relációval), az egy igazi OO modellben általában több osztályt jelent: Egy egyedtípust osztálynak tekintve legfeljebb egy olyan ısosztályt kapunk, amibıl egy valódi OO modellben többféle alosztályt kell leszármaztatni annak megfelelıen, hogy az eredetileg egyféle szerkezető egyed, az OO alkalmazáson belüli különbözı természető együttmőködési szituációkban más-más irányban kibıvített szerkezettel és viselkedéssel rendelkezı objektumként vesz részt. (Például egy Vevı egyedtípusnak az adatbázisszerveren olyan metódusokkal rendelkezı VevıDS osztály felel meg, aminek a metódusai a vevıadatok adatbázison belüli elérését, karbantartását, az adatokra vonatkozó megszorítások érvényesítését szolgálják. A webszerveren már egy olyan VevıWS osztályra van szükség, aminek a metódusai a vevıadatoknak az adatbázisszerver és webszerver közötti mozgatását, a vevıadatokat tartalmazó HTML lap (vagy XML üzenet) összeállítását végzik. A kliensen pedig egy olyan VevıK osztály példányának kell mőködni, aminek a metódusai a vevıadatoknak a webszerver és a kliens közötti mozgatásával, a vevıadatok kliensen való megjelenítésével, a vevıadatokra vonatkozó felhasználó–gép párbeszéddel foglalkoznak.) Amikor egy problémára OO megközelítéssel adott elvi megoldást csupán publikációs céllal írunk le, akkor elınyös az üzleti osztályokat vagy azok ısosztályait az adatmodell egyedtípusainak megfeleltetni olyan módon, hogy az egyedtípus szerkezete adja az osztály szerkezetét, és amennyiben az osztály valamely asszociációja egybeesik az egyedtípus valamely kapcsolatával, akkor az asszociáció olyan jellemzıi, mint a multiplicitás, opcionalitás, azonosak az adatmodellbeli kapcsolatéval. Az ilyen modell könnyebben érthetı és független a megvalósítástól, annak technikai környezetétıl, mert azzal az absztrakcióval él, hogy a rendszerben együttmőködı mindegyik objektum (folyamatosan amíg csak él) azonos gép memóriájában van jelen. Azonban egy konkrét adatbáziskörnyezetre és architektúra történı kivitelezés nem valószínő hogy hatékonyan elvégezhetı ez elıbbi bekezdés szerinti elvi leírás alapján. Ebben az esetben egy alkalmazáson belül mondjuk a VevıO üzleti osztály egy objektuma nem felel meg a VevıE egyedtípus egy egyedének, az inkább egy olyan adatkezelı objektum, amin keresztül az alkalmazás az adatbázissal

302


kommunikál a vevı adatainak elérése/kezelése céljából. A VevıO egy példánya használható arra, hogy abba egymás után a VevıE több (esetleg mindegyik) példánya betöltıdjék arra az idıre, amíg az alkalmazás éppen az adott VevıEpéldánnyal foglalkozik. Ebbıl adódóan mind a VevıO asszociációinak multiplicitása, mind a példányainak élettartama különbözik a VevıE kapcsolatainak multiplicitásától, illetve elıfordulásainak élettartamától. (Még az sem mondható, hogy VevıO kiterjesztése a VevıE-nek, mivel a kiterjesztés az ısosztály asszociációit is megörökli.) Érdekes áthidaló megoldást kínál a Oracle JDeveloper részét képezı BusinessComponents for Java (BC4J) [9], ami egy hagyományos adatmodell egyedtípusai alapján automatikusan generálja az architektúra különbözı rétegeiben használható üzleti osztályok definíciójának fıbb elemeit.

Üzleti alkalmazások tervezési mintái A tervezési minták lényege minél általánosabb megoldást adni gyakran elıforduló problémákra. A szakirodalomban egyre több OO tervezési minta publikációja lát napvilágot, és készültek már a mintákat rendszerezı áttekintések is.[3][4] (A témához bibliográfia található az [6] webhelyen, mintakatalógus pedig az [7] címen) A minták többsége alkalmazási területtıl független általános struktúrákat tárgyal, de léteznek szakterület-specifikus minták is. Az üzleti alkalmazások tervezésében az idevágó szakterületi minták léte és ismerete gyorsíthatja az OO technológia elterjedését. Ilyen mintákra is található példa az [8] címen. – A szerzı számviteli rendszerekre vonatkozó minták kidolgozásában vesz részt.

Forrásjegyzék [1] JAMES RUMBAUGH, MICHAEL BLAHA, WILLIAM PREMERLANI, et al.: ObjectOriented Modeling and Design, h.n., Pentice-Hall, 1991. [2] KONDOROSI K., LÁSZLÓ Z., SZIRMAI-KALOS L.: Objektum-orientált szoftverfejlesztés, h.n., ComputerBooks, 1997. [3] ERICH GAMMA, RICHARD HELM, RALPH JOHNSON, et al.: Elements of Reusable Object-Oriented Software, h.n., Addison-Wesley, 1995. [4] DEEPAK ALUR, JOHN CRUPI, DAN MALKS: Core J2EE Patterns: Best Practices and Design Strategies, h.n., Prentice-Hall, 2001. [5] Oracle9i Application Developer’s Guide – Object-Relational Features Release 1(9.0.1) [6] www.hillside.net/patterns/books/index.htm 2002. október. [7] www.hillside.net/patterns/onlinepatterncatalog.htm 2002. október. [8] www.sdm.de/g/arcus/cookbook 2002. október. [9] http://otn.oracle.com/products/jdev/htdocs/bc4j/bc4jsod.html 2002. október. [10] www.aonix.com/content/products/forms/stp_demo.html 2002. október.

303

GYURKÓ GYÖRGY * Üzleti alkalmazások tervezése objektumorientált megközelítéssel (Az elmélet és a gyakorlat összevetése)

Recommend Documents