Objektum orientlt szoftverfejlesztsKondorosi Kroly Szirmay-Kalos Lszl Lszl Zoltn

Az eredeti m a ComputerBooks Kiad gondozsban jelent meg. Az elektronikus kiads az NKTH ltal lebonyoltott Felsoktatsi Tanknyv- s Szakknyv-tmogatsi Plyzat keretben kszlt, a DocBook XML formtumot Br Szabolcs ksztette. Copyright 2007 Kondorosi Kroly Copyright 2007 Szirmay-Kalos Lszl Copyright 2007 Lszl Zoltn

Jogi kzlemny

AjnlsKnyvnk 1997-es megjelense ta sok kritikt, de mg tbb pozitv visszajelzst kaptunk. Szmos oktatsi intzmnyben ltjuk a ktelez, vagy ajnlott irodalmak listjn, s rmnkre nem csak az informatika szakokon. Ez azt bizonytja, hogy az objektumorientlt megkzelts egyre inkbb hat az informatika alkalmazsi terletein, s egyre inkbb kpes betlteni azt a szerept, hogy alapja lehessen az alkalmazsi terletek szakrti s az informatikusok ltal egyarnt rthet formlis rendszermodelleknek. Megtisztel, hogy knyvnk a DIGIT2005 digitlis szakknyvplyzaton tmogatst nyert, s gy internetes kiadsban is elrhetv vlik. Ugyanakkor nem kis fejtrst okozott szmunkra, hogy hogyan reagljunk az eltelt tz esztend szakmai fejldsre, hiszen a szoftverfejleszts az informatika egyik legdinamikusabban fejld terletnek s egyben zletgnak bizonyult ebben az idszakban. Ennek megfelelen j irnyzatok, mdszerek, eszkzk, fogalmak jelentek, jelennek meg, amelyek kzl nem egyszer kivlasztani a lnyegeseket, a maradandkat. A komponenstechnolgia, az aspektus-orientlt s az intencionlis programozs, a verseng s egymssal klcsnhatsban fejld Java s .NET technolgik, az agilis szoftverfejleszts, a C# nyelv, az analzis-, architekturlis s tervezsi mintk, az j, integrlt fejleszt krnyezetek (mint pldul a Visual Studio, vagy az Eclipse) mind-mind j, lnyeges elemekkel sznestettk a palettt, s ismeretk elengedhetetlen egy kpzett informatikus szmra. A szakma egyik

legnagyobb hats konzorciuma, az Object Management Group (OMG), szmos szabvnyt, ajnlst dolgozott ki, amelyek eredmnyeknt a mdszertanok, jellsrendszerek egysgesedtek, a fogalmak tisztbb vltak. Az egysges modellez nyelv (Unified Modelling Language, UML), a modellvezrelt architektra (Model Driven Architecture, MDA), az objektum metamodell (Meta-Object Facility, MOF), az objektumok egyttmkdsnek elosztott rendszerekben is alkalmazhat szabvnya (Common Object Request Broker Architecture, CORBA), az interfszler nyelv (Interface Definition Language, IDL), szles krben elterjedt szabvnyokk vltak. A konzorciumnak a szakma legnagyobb piaci szerepli is tagjai, gy a szabvnyok gyakorlati alkalmazsa s a forgalmazott termkekben val megjelense is biztostott. Az OMG dokumentumainak jelents rsze nylt, elrhet a www.omg.org portlon. Az internetes kiads elksztsekor irrelis clkitzs lett volna minden lnyeges jdonsg trgyalsa, akr csak felletesen is. Valamilyen mrtk tdolgozst azonban felttlen szksgesnek lttunk, hiszen egy tanknyvtl elvrhatan a jellsrendszernek alkalmazkodnia kell a szabvnyokhoz, a pldaprogramoknak pedig lefuttathatknak kell maradniuk a mai rendszereken is. Az internetes kiadst teht az eredeti knyvhz kpest a kvetkezk jellemzik: Megtartottuk az eredeti clkitzst, azaz bemutatjuk az objektumorientlt szoftverfejleszts alapjait: az analzist, tervezst s a C++ nyelv implementcit. A bevezet, ttekint fejezetekben csak ott vltoztattunk, ahol az j eredmnyek alapjn a szveg felttlen korrekcira szorult. Az OMT (Object Modelling Technique) mdszertan s jellsrendszer helyett az UML-t alkalmazzuk. Ennek megfelelen az adatfolyamokat (dataflow) nem trgyaljuk, a hasznlati eseteket (usecase) pedig bevezetjk. A C++ nyelv bemutatsakor s a mintafeladatok implementciiban ma elterjedten hasznlt nyelvi krnyezetet vesznk alapul, gy az olvas a kzlt programokat knnyebben fordthatja s futtathatja az ltala elrhet szmtgpeken.

Ismtelten ksznjk mindazoknak, akik szrevteleikkel, tancsaikkal segtettk munknkat. Kln ksznjk Dr. Goldschmidt Balzs munkjt, aki brinkat az OMT jellsrendszerrl UML-re alaktotta. Ugyancsak megklnbztetett ksznet illeti Br Szabolcsot, aki az internetes megjelensre alkalmas formtumra alaktotta szvegeinket s brinkat. Remnyeink szerint a felfrissts a knyv hasznra vlik, s mind az oktatk s hallgatk, mind a gyakorlati szakemberek hasznos olvasmnya marad az elkvetkez vekben is. Budapest, 2007. februr A szerzk Tartalom

Elsz 1. Bevezets a szoftverfejlesztsbe 1.1. Szoftvertechnolgik 1.2. A fejleszts elvi alapjai 1.2.1. A szoftverfejleszts alapproblmi 1.2.2. Uraljuk a bonyolultsgot! 1.2.3. A lers szigorsga 1.2.4. A fejleszts folyamata 1.3. A szoftver letciklusa 1.3.1. Termkek letciklusa 1.3.2. A szoftver letciklusnak jellegzetessgei 1.3.3. A vzessmodell 1.3.4. Az inkrementlis fejlesztsi modell s a prototpus 1.3.5. Spirlmodellek 1.3.6. Az jrafelhasznlhatsg 1.3.7. Minsgbiztosts a szoftverfejlesztsben 2. Az objektumorientltsg fogalma 2.1. t az objektumig 2.1.1. A kezdetektl az absztrakt adatstruktrkig 2.1.2. Funkcionlis kontra adatorientlt tervezs 2.1.3. Irny az objektum! 2.2. Az objektum fogalma 2.2.1. Az objektum 2.2.2. Osztlyok s pldnyok 2.2.3. Az objektumok tpusai 2.2.4. Az objektum-vltoz 3. Modellezs objektumokkal 3.1. A modellek ttekintse 3.1.1. Objektummodell 3.1.2. Dinamikus modell 3.1.3. Funkcionlis modell

3.2. Az objektummodell 3.2.1. Attribtumok 3.2.2. A relcik s a lncols 3.2.3. Normalizls 3.2.4. rkls 3.2.5. Komponens-relci 3.2.6. Metaosztly 3.3. Dinamikus modellek 3.3.1. Esemnyek s llapotok 3.3.2. Az llapotdiagram 3.3.3. Az llapotgp fogalmnak kiterjesztse 3.3.4. Begyazott llapotmodellek 3.3.5. Az llapottmenet-tbla 3.4. A funkcionlis modell 3.5. A modellek kapcsolata 4. Fejlesztsi mdszer 4.1. Analzis 4.1.1. A feladatdefinci 4.1.2. Objektummodellezs 4.1.3. Dinamikus modellezs 4.1.4. Funkcionlis modellezs 4.2. Objektumorientlt tervezs 4.2.1. Architektrlis tervezs 4.2.1. Kls interfsz tervezse 4.2.2. Objektumtervezs 5. Objektumok valsidej rendszerekben 5.1. A valsidej rendszerek jellemzi 5.1.1. Meghatrozs, osztlyozs 5.1.2. Egyb jellemz tulajdonsgok 5.1.3. Kzkelet flrertsek s vitapontok 5.2. Idkvetelmnyek 5.2.1. Az idkvetelmnyek megadsa 5.2.2. Az idkvetelmnyek tpusai 5.3. A fejleszts problmi 5.4. Valsidej feladatokra ajnlott mdszertanok 6. Objektumorientlt programozs C++ nyelven 6.1. A C++ nyelv kialakulsa 6.2. A C++ programozsi nyelv nem objektumorientlt jdonsgai 6.2.1. A struktra s rokonai neve tpusrtk 6.2.2. Konstansok s makrok 6.2.3. Fggvnyek 6.2.4. Referencia tpus 6.2.5. Dinamikus memriakezels opertorokkal 6.2.6. Vltoz-definci, mint utasts 6.2.7. Nvterek

6.3. A C++ objektumorientlt megkzeltse 6.3.1. OOP nyelvek, C C++ tmenet 6.3.2. OOP programozs C-ben s C++-ban 6.3.3. Az osztlyok nyelvi megvalstsa (C++ C fordt) 6.3.4. Konstruktor s destruktor 6.3.5. A vdelem szelektv enyhtse - a bart (friend) mechanizmus 6.4. Opertorok tdefinilsa (operator overloading) 6.4.1. Opertor-tdefinils tagfggvnnyel 6.4.2. Opertor-tdefinils globlis fggvnnyel 6.4.3. Konverzis opertorok tdefinilsa 6.4.4. Szabvnyos I/O 6.5. Dinamikus adatszerkezeteket tartalmaz osztlyok 6.5.1. Dinamikusan nyjtzkod sztring osztly 6.5.2. A msol konstruktor meghvsnak szablyai 6.5.3. Egy rejtvny 6.5.4. Tanulsgok 6.6. Els mintafeladat: Telefonkzponti hvstirnyt rendszer 6.7. rklds 6.7.1. Egyszer rklds 6.7.2. Az egyszer rklds implementcija (nincs virtulis fggvny) 6.7.3. Az egyszer rklds implementcija (van virtulis fggvny) 6.7.4. Tbbszrs rklds (Multiple inheritence) 6.7.5. A konstruktor lthatatlan feladatai 6.7.6. A destruktor lthatatlan feladatai 6.7.7. Mutatk tpuskonverzija rklds esetn 6.7.8. Az rklds alkalmazsai 6.8. Generikus adatszerkezetek 6.8.1. Generikus szerkezetek megvalstsa elfordtval (preprocesszor) 6.8.2. Generikus szerkezetek megvalstsa sablonnal (template) 7. Objektumok tervezse s implementcija 7.1. Az objektum, a dinamikus s a funkcionlis modellek kombinls 7.1.1. Az objektummodell elemzse 7.1.2. A dinamikus modell elemzse 7.1.3. Osztlyok egyedi vizsglata 7.2. Az zenet-algoritmusok s az implementcis adatstruktrk kivlasztsa 7.2.1. ttekinthetsg s mdosthatsg 7.2.2. A komplexits

7.2.3. Az adatstruktrk kivlasztsa, az osztlyknyvtrak felhasznlsa 7.2.4. Robusztussg 7.2.5. Sajt debugger s profiler 7.3. Asszocicik tervezse 7.4. Lthatsg biztostsa 7.5. Nem objektumorientlt krnyezethez, illetve nyelvekhez trtn illeszts 7.6. temezsi szerkezet kialaktsa 7.6.1. Nem-preemptv temez alkalmazsa 7.7. Optimalizci 7.8. A deklarcis sorrend megllaptsa 7.9. Modulok kialaktsa 8. Mintafeladatok 8.1. Msodik mintafeladat: Irodai hierarchia nyilvntartsa 8.1.1. Informlis specifikci 8.1.2. Hasznlati esetek 8.1.3. Az objektummodell 8.1.4. A dinamikus modell 8.1.5. Objektumtervezs 8.1.6. Implementci 8.2. Harmadik mintafeladat: Lift szimultor 8.2.1. Informlis specifikci 8.2.2. Hasznlati esetek 8.2.3. Az objektum-modell 8.2.4. A dinamikus modell 8.2.5. Objektumtervezs 8.2.6. A konkurens viselkeds tervezse Irodalomjegyzk

ElszA szoftverfejleszts folyamata a programozs trtnetnek mintegy fl vszzada alatt jelents talakulsokon esett t nhny kivlasztott guru mgikus tnykedst a szoftver ipari ellltsa vltotta fel. Az "ipari" termelshez szigor technolgiai elrsokra, hatkony termeleszkzkre s a hajdani guruk helyett mind a technolgit, mind pedig az eszkzket jl ismer, fegyelmezett szakembergrdra van szksg. A szoftverfejleszts sorn a szabvnyos technolgiai elrsokat az n. fejlesztsi mdszertanok fogalmazzk meg, az eszkzket pedig a CASE rendszerek s a programozsi nyelvek jelentik. A mdszertanok alkalmazsa sorn megrtjk a megoldand problmt s krvonalazzuk a szmtgpes megvalsts mikntjt. Napjainkban szmos mdszertan vetlkedik egymssal, amelyek kzl az alkalmazsi terletek jelents rsznl az n. objektum-orientlt megkzelts

kerlt vezet pozciba. Ennek oka taln az, hogy a tbbi mdszerrel szemben az objektum-orientlt elvek nem a szmtstechnika elvont fogalmait kvnjk rerltetni az letre, hanem megfordtva az let termszetes s szmtstechnika-mentes mkdst hangslyozzk a feladatok megoldsa sorn. Az objektum-orientlt szemllettel megragadott feladatok programjait olyan programozsi nyelveken rdemes implementlni, amelyek maguk is segtik az objektum-orientlt gondolkozst, klnben a programfejleszts utols fzisban, az implementci sorn esetleg elvesztennk az objektum-orientlt megkzelts szmos elnyt. Szmos objektum-orientlt programozsi nyelv ltezik, melyek kzl messze a C++ nyelv a legelterjedtebb. Ezen knyv az objektum-orientlt szoftverfejleszts fzisait kvnja bemutatni, a megoldand problma megrtstl kezdve a megolds menetnek krvonalazsn t egszen az implementci rszletes kidolgozsig. A fejleszts klnbz fzisait igen sznvonalas idegen nyelv munkk trgyaltk ezen knyv megjelense eltt is. A knyvek egy rsze az analzis s tervezs lpseit ismerteti, mg ms mvek a C++ nyelv szintaktikjt s szemantikjt mutatjk be. A mi knyvnk fleg abban kvn jat adni, hogy a szoftvertechnolgiai lpseket s a C++ nyelv ismertetst sszekapcsolja, lehetsget teremtve arra, hogy a gyakorl programfejleszt szmra egy egysges kp alakuljon ki. Ezzel remnyeink szerint elkerlhet lesz az a oktati tapasztalataink alapjn elg gyakori hiba, hogy a fejleszt kln-kln remekl kezeli az objektum-orientlt analzis s tervezs lpseit, s jl ismeri a C++ nyelvet is, de C++ programjt mgsem az elkszlt tervekre pti, gy az analzis s tervezs hamar felesleges s rtelmetlennek ltsz teherr vlik szmra. A knyvben ismertetett objektum-orientlt analzis s tervezs dnt rszben a ma legelterjedtebb OMT (Object Modelling Technique) mdszertanra pl, amelyet kiegsztettnk s sszekapcsoltuk az implementcival. Terjedelmi korltok miatt a knyv nem trekedhet teljessgre az implementcis eszkz, a C++ nyelv bemutatsnl. Egyrszt ismertnek tekinti a C++ nyelvnek az sszes C nyelvtl rklt konstrukcijt, msrszt pedig nem trgyal nhny C++ jdonsgot (pldul a kivtelek (exception) kezelse).

Ajnljuk ezt a knyvet mind a dikoknak, mind pedig a gyakorl rendszertervezknek, programfejlesztknek s programozknak, ha mr jrtassgot szereztek a C programozsi nyelvben. Remnyeink szerint ezen knyv segtsgvel a kezd C++ programozk megtanulhatjk a nyelvet s az objektum-orientlt fejleszts mdszertant, de haszonnal forgathatjk a knyvet a C++ nyelvet mr jl ismerk is. A knyv a Budapesti Mszaki Egyetem Mszaki Informatika s Villamosmrnki karain a szerzk ltal eladott "Objektum-orientlt programozs", "Szoftver technolgia", "Objektum-orientlt szoftverfejleszts" trgyak anyagra s a B. Braun fejlesztintzetnl tartott tanfolyam anyagra pl. Hlsak vagyunk hallgatinknak s a B. Braun fejlesztinek, akik az eladsokon feltett krdseikkel, megjegyzseikkel sokat segtettek a knyv szerkezetnek s trgyalsmdjnak finomtsban. Vgl hlval tartozunk a B. Braun fejlesztintzet pletben mkd felvonnak, amely a harmadik mintafeladatot ihlette. Budapest, 1997. A szerzk

1. Bevezets a szoftverfejlesztsbeTartalom

1.1. Szoftvertechnolgik 1.2. A fejleszts elvi alapjai 1.2.1. A szoftverfejleszts alapproblmi 1.2.2. Uraljuk a bonyolultsgot! 1.2.3. A lers szigorsga 1.2.4. A fejleszts folyamata 1.3. A szoftver letciklusa 1.3.1. Termkek letciklusa 1.3.2. A szoftver letciklusnak jellegzetessgei 1.3.3. A vzessmodell 1.3.4. Az inkrementlis fejlesztsi modell s a prototpus 1.3.5. Spirlmodellek 1.3.6. Az jrafelhasznlhatsg 1.3.7. Minsgbiztosts a szoftverfejlesztsbenA szoftver karrierje egyelre felfel vel. Az alig nhny vtizedes trtnet nem mentes viharoktl s ellentmondsoktl. ppen csak elkezddtt a trtnet s mris krzisrl beszltek. Ma is tart a vita, hogy ebbl sikerlt-e kilbalnia. Egy dolog biztos, a szoftver

egyike az utbbi vek legdinamikusabban fejld zletgainak. Ellltsval amatrk s profik valsznleg tbb millian foglalkoznak. Hogy csinljk? Hogy kellene csinlniuk? A szoftver ellltsa tudomnyos vizsgldsok trgya is. A publikcik szma hatalmas. Kezdetben programozsi technikk, ksbb mdszerek, aztn mdszertanok, paradigmk jelentek meg. Ma tudomnyos krkben is taln a legnpszerbb mdszertan s paradigma az objektumorientltsg. Tekintve, hogy a szoftver ma vitathatatlanul tmegtermk, ellltsi mdszereit egyre inkbb indokolt technolgiknak nevezni.

1.1. SzoftvertechnolgikAz objektumorientlt szoftverfejleszts a lehetsges s hasznlatos szoftvertechnolgik egyike. A szkapcsolat szokatlan; rdemel nmi vizsgldst, hogy a szoftverrel kapcsolatosan miknt rtelmezhet a technolgia fogalma, milyen sajtossgok jelennek meg a hagyomnyos technolgikhoz kpest. Kezdjk a technolgia ltalnos fogalmval! A technolgia valaminek az ellltsval foglalkozik. ltalban megkvetelnk bizonyos ismrveket ahhoz, hogy ezt a kifejezst hasznljuk, nem tekintnk mindenfle barkcsolst technolginak. A trsadalom ltal a gyakorlatban felvetett problmk megoldsra szolgl dolgok tudomnyos ismeretek alkalmazsval trtn, gazdasgos ellltsnak mikntjt nevezzk technolginak. A definciban minden sznak klns jelentsge van, ezrt rdemes a mondatot alaposan elemezni. A technolgia lnyegben dolgok ellltsnak mikntje; mdszerek, eszkzk, technikk egyttese, amelyek alkalmazsval vges szm lpsben a kvnt dologhoz jutunk. A miknthez kt jelz is tartozik, nevezetesen a tudomnyossg s a gazdasgossg. A tudomny eredmnyeinek alkalmazstl remlnk garancit arra, hogy a mdszerek idtl s trtl fggetlenek, megbzhatak, megismtelhetek lesznek. A gazdasgossg az a szempont, amelynek alapjn a lehetsges

megoldsok kzl vlasztunk. Fontos a definciban szerepl dolog sz s jelzje is. Dolog az, aminek ellltsra a technolgia irnyul. A definciban kiktjk, hogy a technolgia csak olyan dolgok ksztsnek mdjval foglalkozik, amely dolgok a gyakorlatban elfordul problmk megoldst clozzk. Tovbbi szktst jelent a trsadalmi vonatkozs is. Ez szkebb rtelemben azt jelenti, hogy az ellltand dolgok irnt trsadalmi igny nyilvnul meg, tgabban pedig azt, hogy mind a dolognak, mind a technolginak magnak komoly egyb trsadalmi (jogi, krnyezeti, etikai, stb.) vonatkozsai is vannak. Az ellltand dolgokra s a technolgira vonatkoz trsadalmi elvrsok trvnyekben, szabvnyokban s ajnlsokban fogalmazdnak meg. Az elmlt nhny vtized egy j terleten, az informcifeldolgozs terletn vetett fel egyre nvekv trsadalmi ignyeket. A dolgok (termkek), amelyek ezeket az ignyeket kielgtik, sszefoglalan informci-feldolgoz rendszerek nvvel jellhetk. Az informci fogalmnak tisztzsa nem egyszer, a filozfusokat is komoly feladat el lltja. Mindenesetre nem anyagi termszet valamirl van sz, de az informci trolsa, feldolgozsa, tovbbtsa az anyag trvnyszersgeit kihasznl eszkzkkel lehetsges. Az informcit mindig valamilyen anyagi dolog, fizikai jellemz hordozza, amit hordoznak vagy kzegnek (mdia) neveznk. A kzeg kivlasztsn tl az brzolshoz meg kell llapodnunk abban is, hogy a fizikai jellemz mely rtkeit, milyen jelentssel hasznljuk. Az informcinak egy adott kzegen, adott szablyok szerint trtn brzolst az informci reprezentcijnak nevezzk. Ugyanannak az informcinak tbbfle reprezentcija lehetsges. Gondoljunk csak arra, hogy valamirl rteslhetnk pldul az jsgbl, az rott szveg elolvassa tjn, de ugyanaz az informci megszerezhet gy is, hogy meghallgatjuk a rdi hreit! Az informci-feldolgoz rendszerekben az eszkzk anyagi jellege, fizikai mkdse a megoldand feladat szempontjbl kzmbs, egybknt csak annyiban lnyeges, amennyiben az

informci brzolshoz, az informcival vgzett mveletek konkrt vgrehajtshoz ennek ismeretre szksg van. A mai informci-feldolgoz rendszerek ltalnos felptst az 1.1. brn lthatjuk.

1.1. bra A rendszer magja egy (esetleg tbb sszekapcsolt) ltalnos cl szmtgp, amelyre rpl egy ltalnos cl programcsomag, az alapszoftver (opercis rendszer, adatbzis-kezel, hlzatkezel szoftver stb.). Ezeket a komponenseket ptelemeknek tekinthetjk. A harmadik rteg a feladatspecifikus felhasznli szoftver az, amelynek ltrehozsa a feladat megoldsnak dnt rsze. Az informci-feldolgozsi problmk megoldi az esetek tbbsgben felhasznli szoftver ksztsvel foglalkoznak, jllehet munkjuk eredmnyeknt egy rendszer hardver-szoftver egyttes oldja meg a feldolgozsi feladatokat. Ugyanezen oknl fogva beszlhetnk az informci-feldogoz rendszerek ltrehozsval kapcsolatosan elssorban szoftvertechnolgirl. Termszetesen az anyagi technolgikhoz hasonlan az alapanyagok s a komponensek kszlett nmagukban is folyamatosan fejlesztjk. Bizonyos specilis feladatok pedig ennek

ellenre sem oldhatk meg ksz elemek sszeptsvel. A szoftvertechnolgia mdszerei termszetesen az alapszoftver fejlesztse sorn is alkalmazhatk, st nagyrszk mg a hardverfejlesztsben is, hiszen ilyenkor is informci-feldolgoz rendszereket kell ltrehoznunk. A kialakult szhasznlat szerinti szoftvertechnolgia, szoftverfejleszts (software engineering), rendszerfejleszts (system engineering) s informcitechnolgia fogalmak ltal jellt terletek jelentsen tfedik egymst. A tovbbiakban akkor hasznljuk a rendszer fogalmat, ha hangslyozni kvnjuk mondandnk rvnyessgnek kiterjeszthetsgt a hardver-szoftver egyttesekre is. Vizsgljuk meg a szoftver sajtossgait, rtelmezzk vele kapcsolatosan a technolgia fogalmt, s rtkeljk a szoftvertechnolgia mai helyzett! A "mi a szoftver?" krdsre adand vlasz nem egyszer, ha arra gondolunk, hogy szoftvervsrls cmn ltalban mgneses anyagokat s knyveket szoktunk kapni. Azonosthat-e a szoftver a mgneslemezzel? Nyilvnvalan nem, a lemez csak a szoftver hordozja. Hasonlkppen hordoznak tekinthetk a nyomtatott dokumentcik. A szoftver teht az informcihoz hasonl tulajdonsgokat mutat. Valban, a szoftvert rtelmezhetjk gy, mint azt az informcit, amely megmondja, hogy egy (vagy tbb) adott berendezst hogyan kell mkdtetni egy feladat megoldsa rdekben. Elkerlend a filozfia csapdit, a szabvnyok a szoftvert mint programok, adatok s dokumentcik egyttest definiljk, amelyek klnfle anyagi formt lthetnek (reprezentcik). Maga a szoftver szellemi termk, s mint ilyen, szmos a technolgik szempontjbl furcsa tulajdonsggal rendelkezik. Anyagtalansgnak fontos kvetkezmnye, hogy az anyag ismert trvnyei (Newton trvny, Maxwell egyenletek stb.) r nem rvnyesek. Ennek egyik jelents elnye, hogy a szoftver anyagi rtelemben nem avul, nem kopik s tbb ves hasznlat utn is ugyanannyi hiba van benne, mint a megvtelekor. A szoftvert reprezentcii hordozzk, de az igazi rtk termszetesen nem a

hordoz. ltalban nagyon egyszer a reprezentcik msolsa, hiszen gy lehet azokat sokszorozni, hogy annak az "eredetin" nincs nyoma. Ez a tulajdonsg kis mrtkben a technolgia megszokott fogalmt is mdostja. Amg az anyagi technolgik legfontosabb clja a minsg megrzse a sorozatgyrtsban (legyen a szzezredik darab is olyan, mint az els), addig a szoftver esetben a reprezentcik tbbszrzse ltalban nem jelent klnsebb gondot. A szoftvertechnolgik esetben a "tmeggyrts" nem az egyedi pldnyok ellltst, hanem sokkal inkbb szoftverek klnfle vltozatainak, verziinak szisztematikus s kvethet elksztst jelenti. Krds, hogy a mai szoftverksztsi gyakorlat a tudomnyossg s a gazdasgossg kritriumainak megfelel-e. Ersen vitathat, hogy a szoftverkszts mai ltalnos gyakorlata kellen kidolgozott, tudomnyos alapokon nyugszik. A piac risi felvevkpessge s bizonyos elssorban a minsg terletn mutatott ignytelensge mg ma is eltri a "mindegy-hogyhogyan" programksztst, st alkalmanknt jobban rtkeli, mint az alapos, ignyes szakmai munkt. A tmban mutatkoz zrzavart az is jelzi, hogy szemben az ptszettel, ahol csak a tervezi nvjegyzkbe felvett ptszkamarai tagok tervezhetnek nllan, szoftvert brki kszthet, akr szakmai kpests nlkl is. A technolgia hinyra egybknt a gazdasg hvta fel a figyelmet valamikor a 60-as vek vgn a szoftverkrzis felismersvel. A krzis lnyege, hogy a szoftverek fejleszti minden kltsg- s idkeretet rendszeresen tllptek, s mindezek ellenre sem voltak kpesek megbzhat s a felhasznli kvetelmnyeket legalbb elfogadhat szinten teljest szoftvert ellltani. Hitelesnek tartott vizsglati adatok szerint az elkszlt szoftvereknek tbbszri javts utn is kevesebb, mint 25 %-t vettk hasznlatba. A szakrtk a problma tanulmnyozsa sorn arra a kvetkeztetsre jutottak, hogy a krzis eredend okai a fejleszts mdszeressgnek s szervezsnek (menedzsment) hinyossgaiban keresendk. Ez a felismers lkst adott a nagy rendszerek uralsra alkalmas mdszertanok s programozsi nyelvek fejldsnek, valamint a technikai aspektusokon tlmenen

a hatkony munkaszervezsi (menedzsment) mdszerek kialaktsnak. Ekkor elkezddtt a szoftverfejleszts technolgijnak kialakulsa. Mra szmos fejlesztsi mdszertant dolgoztak ki s publikltak. Ezek nmelyikhez szmtgpes tmogat eszkzket is kifejlesztettek (CASE Computer Aided Software Engineering szmtgppel tmogatott szoftver mrnksg). A CASE eszkzket s mdszereket egyre tbb helyen alkalmazzk. Sok orszgban a minsg biztostsra szabvnyokat s ajnlsokat vezettek be. Tudomnyos intzetekben kutatsokat folytatnak a bizonythatan helyes programok ksztsnek matematikai szigorsggal rgztett mdszereit illeten. sszefoglalsul leszgezhetjk, hogy a mai szoftvergyrts mg elg messze ll attl, hogy "jl technologizltnak" nevezzk, de hatrozott lpsek trtntek a szksges irnyba.

1.2. A fejleszts elvi alapjaiElsknt tisztzzuk, mit is rtnk fejlesztsen! Minden termknek van lettrtnete (letciklusa), amely a r vonatkoz igny felmerlstl a termk hasznlatbl val kivonsig (feledsbe merlsig) tart. A ciklus elnevezs fknt azokban az esetekben indokolt, amikor egy termknek rendre jabb, tovbbfejlesztett vltozatait lltjk el. Ilyenkor minden tovbbfejlesztsi lpst gy tekinthetnk, mint az lettrtnet megismtldst, azaz ciklusokrl beszlhetnk. Valamennyi letciklus-tpuson bell megtallhat az a tervez, ksrletez tevkenysg, amelyik jellegzetesen az j vagy mdostott termk ellltsra vonatkoz igny megszletstl a gyrts megindtsig tart. Fejlesztsen egy termk letciklusnak azt a szakaszt rtjk, amelyik a termk ellltsra vagy mdostsra vonatkoz igny felmerlstl a gyrts megindtsig tart. A fejlesztsi szakaszban rszint magt a termket (gyrtmnyfejleszts), rszint a technolgit (gyrtstervezs) kell

megtervezni s ksrleti ton igazolni. Termszetesen a termk s a technolgia klcsnsen hatnak egymsra. Felidzve mindazt, amit az elz pontban a szoftverrl mondtunk, vegyk vizsglat al a szoftver lettrtnett! A szoftver elnevezs a kemny/lgy (hard/soft) ellenttprbl szrmazik. Az ellenttpr azt tkrzi, hogy szemben a szmtgp merev, a gyrts utn mr nem vltoztathat jellegvel a szoftver knnyen, rugalmasan, akr "hzilag" is mdosthat. Ez a knny vltoztathatsg csbt is a vltoztatsokra. A szoftver letnek ciklikus jellegt a mdostsok, tovbbfejlesztsek sorozata adja. Azt is megllapthatjuk, hogy a szoftver lettrtnetben az egyes szakaszok slya jelentsen eltr a hagyomnyos termkeknl megszokottl. Miutn a gyrts azaz a pldnyok ellltsa nem okoz klnsebb gondot, ezzel szemben a termk maga bonyolult, gy az letciklus dnt rsze a fejleszts, ezen bell is a termkfejleszts. Ennek megfelelen a szoftvertechnolgia nem a gyrts mikntjre, hanem a termkfejleszts mikntjre koncentrl, erre prbl szisztematikus mdszereket adni.

1.2.1. A szoftverfejleszts alapproblmiA szoftverfejleszts olyan folyamat, amely sorn egy adott ignyt kielgt szoftver els pldnyt ltrehozzuk. A folyamat indulhat "nullrl", azaz gy, hogy nincs jelents elzmnye, nincs meglv, hasonl szolgltats rendszer a birtokunkban; de indulhat gy is, hogy egy meglv szoftver tovbbfejlesztst hatrozzuk el. Fejlesztsrl csak akkor beszlnk, ha a folyamat sorn jelents jdonsgokat hozunk ltre. A fejleszts folyamatnak hrom jellegzetes lpst klnthetjk el: a modellezst, a tervezst s az implementcit. Ezt a hrom tevkenysget az 1.2. bra alapjn rtelmezhetjk. A fejleszts jelents rsze gondolati skon, azaz a modellek skjn folyik. A valsgos dolgokrl bennnk l kpeket nevezzk modelleknek, ennek a kpnek a kialaktst pedig modellezsnek. Egy modell sohasem tkrzi a valsg minden apr rszlett, hiszen mindig valamilyen cllal alkotjuk. A modellben azokra a

tulajdonsgokra koncentrlunk, amelyek a cl elrse szempontjbl fontosak. Ezrt a modell szksgkppen absztrakt (ld. ksbb). Milyen sszefggs ll fenn a modell s a valsgos dolgok kztt? Ugyanarrl a valsgos dologrl tbb modellt is alkothatunk, amelyek mindegyike ms-ms szempontbl emel ki lnyeges tulajdonsgokat. Fordtott irnyban: egy modellnek tbb valsgos dolog is megfelel. Ezek a valsgos dolgok a modellben figyelmen kvl hagyott (lnyegtelennek tartott) tulajdonsgaikban trnek el egymstl. A szoftverfejleszts sorn valamely specilis feladat megoldsra univerzlis eszkzket hasznlunk, azaz specilis rendszerknt viselked szmtgpes rendszert hozunk ltre. Ekzben mind a specilis rendszerrl kialaktott modellre, mind a felhasznlhat szmtstechnikai eszkzkrl kialaktott modellre szksgnk van, a cl elrshez pontosan ennek a kt modellnek az elemeit kell megfeleltetnnk egymsnak.

1.2. bra Vizsgljuk meg, milyen viszony ll fenn egy termk s a ltrehozsa sorn szlet modelljei kztt! Az 1.2. brn megjelen szimblumok hrom trrszben, hrom "vilgban" helyezkednek el. Az bra als rsze a valsgot jelli. A bal fels trrsz az gynevezett problmatr, ahol a specilis feladathoz ktd gondolatkrben mozoghatunk. Ebben a trben

alakthatjuk ki a ltrehozand rendszer fogalmi modelljt. A jobb fels trrsz az gynevezett implementcis tr, amelyet a megvalstshoz felhasznlhat eszkzk bennnk l kpe hatroz meg. Ebben a trben helyezkedik el az implementcis modell, amely esetnkben a megvalstand rendszert, mint szmtstechnikai eszkzk valamilyen egyttest rja le. Igen sok olyan rendszer ltezhet a valsgban, amelyik kielgti a tmasztott kvetelmnyeket. A fogalmi modell ezek mindegyiknek megfeleltethet. Ugyancsak igen sok rendszer ltezhet, (most ne firtassuk, hogy ezek egyltaln vges sokan vannak-e), amelyeket az implementcis eszkzkbl el tudnnk kszteni. Ezek kzl azok lesznek a lehetsges megvalstsok, amelyek egyben a tmasztott kvetelmnyeknek is megfelelnek. A megvalstott valsgos rendszer a lehetsges megvalstsok egyike. Ennek a konkrt rendszernek egy implementcis modell felel meg. Ugyanennek az implementcis modellnek azonban tbb egymstl lnyegtelen rszletekben klnbz valsgos rendszer is megfeleltethet. A fogalmi- s az implementcis modellek megfeleltetst vizsglva megllapthatjuk, hogy egy fogalmi modellnek tbb implementcis modell is megfeleltethet (a lehetsges megvalstsok implementcis modelljei). A fogalmi modellhez tartoz, neki megfeleltethet legkedvezbb implementcis modell ltrehozsa a tervezs feladata. A fejleszts kezdetekor ltalban a problmatr fogalmaival kifejezett ignyekbl, vagyis a fogalmi modell egy vltozatbl indulunk ki, s a kvetelmnyeket kielgt valsgos rendszerhez kell eljutnunk. A legtbb gondot ennek sorn az okozza, hogy a szban forg rendszerek bonyolultak, amibl szmos problma szrmazik. Rgtn elsknt emlthetjk, hogy a bonyolult modellek ttekinthetetlenek, megrtsk, kezelsk nehzkes. Nincs olyan zsenilis tervez, aki egy rendszernek, amelynek programja tbb tzezer forrssorbl ll, s sok (mondjuk tznl tbb) processzoron fut, valamennyi rszlett egyidejleg fejben tudn tartani, illetve egy-egy tervezi dnts minden kihatst tltn. A bonyolult

rendszerek modelljeit s a modellek kztti megfeleltetseket csak tbb lpsben tudjuk kidolgozni. Minden lps hibalehetsgeket rejt magban, mgpedig minl bonyolultabb a rendszer, annl nagyobb a hibzs eslye. Az ttekints nehzsgein tl komoly problma a rsztvevk informcicserje is. A rendszerrel szemben tmasztott kvetelmnyeket ltalban nem a fejlesztk, hanem a felhasznlk (megrendelk) fogalmazzk meg, maga a fejleszts pedig ltalban csoportmunka. Igen j lenne, ha a folyamat minden rsztvevje pontosan ugyanazt a gondolati kpet tudn kialaktani nmagban az amgy igen bonyolult rendszerrl. Sajnos ezt nagyon nehz elrni, nagy a flrerts veszlye. (Tapasztalatok szerint a problma egyszemlyes vltozata is ltezik: igen j lenne, ha egy fejleszt nhny ht elteltvel fel tudn idzni ugyanazt a kpet, amit korbban kialaktott magban a rendszerrl.) A bonyolultsgon valahogyan uralkodni kell. A felvetett problmk alapjn hrom krdst vesznk rszletesebb vizsglat al. Az els az, hogy milyen mdon tudunk bonyolult rendszerekrl ttekinthet, kezelhet modelleket alkotni. A msodik, hogy mit tehetnk a modellek egyrtelmsge s ellenrizhetsge rdekben. Ez a vizsglds a rendszerrl kszl dokumentumok (reprezentcik) tulajdonsgainak vizsglathoz vezet, miutn sajt korltos emlkezetnk, valamint a rsztvevk kztti informcicsere egyarnt megkveteli a kvetkezetes dokumentlst. A harmadik krds, hogy a fejleszts folyamatt hogyan clszer megszervezni. Milyen lpseket milyen sorrendben hajtsunk vgre annak rdekben, hogy a nagyobb buktatkat elkerljk, az elkvetett hibk minl elbb kiderljenek, s minden fzisban fel tudjuk mrni, hogy a munknak mekkora rszn vagyunk tl?

1.2.2. Uraljuk a bonyolultsgot!A bonyolultsgot ltalban gy rzkeljk, hogy nagyon sok mindent kellene egyszerre fejben tartanunk, s ez nem sikerl. Figyelmnket hol az egyik, hol a msik rszletre koncentrljuk, s a vltsok kzben elfelejtjk az elzleg tanulmnyozott rszleteket. A bonyolultsg uralsa rdekben olyan modelleket kellene

alkotnunk, amelyek lehetv teszik, hogy az egyidejleg fejben tartand informci mennyisgt cskkenthessk, a tervezs kzben hozott dntsek kihatst pedig az ppen ttekintett krre korltozzuk. Erre kt alapvet eszkz ll rendelkezsnkre, a rszletek eltakarsa (absztrakci), illetve a problma (rendszer) egyszerbb, egymstl minl kevsb fgg rszekre bontsa (dekompozci). Ezzel a kt gondolkodsi technikval olyan struktrkat hozhatunk ltre, amelyeken mozogva figyelmnket a rendszer klnbz rszeire, klnbz nzeteire irnythatjuk. Az absztrakci olyan gondolkodsi mvelet, amelynek segtsgvel a dolgok szmunkra fontos jegyeit elvonatkoztatjuk a kevsb fontosaktl, az ltalnosthat tulajdonsgokat az egyediektl. Ms szavakkal: az absztrakci mveletvel eltakarjuk a szksgtelen, zavar rszleteket, gy egy modellbl kevesebb rszletet tartalmaz j modellt lltunk el. Az absztrakci szintjt a rszletezettsg aprlkossga jellemzi. Minl nagyobb, bonyolultabb, sszetettebb dolgot tekintnk eleminek, azaz a vizsglat szempontjbl pillanatnyilag tovbb nem oszthatnak, annl magasabb absztrakcis szintrl beszlhetnk. Fordtva: ahogy kzelednk az apr rszletekhez, egyre konkrtabbak lesznk. Egy modellbl a finomts mveletvel llthatunk el egy alacsonyabb absztrakcis szint, rszleteiben gazdagabb modellt. Termszetesen az absztrakcis szintek nem abszoltak, hiszen csak egymshoz kpest van jelentsk. Dekompozcinak nevezzk egy rendszer egyttmkd, egyszerbb rszrendszerekre bontst, ahol a rszrendszerek egyttesen az eredeti rendszernek megfelel viselkedst mutatnak. Egy dekompozcis lpsben ltalban rszrendszereket definilunk, valamint meghatrozzuk a rszrendszerek egyttmkdsnek mdjt. Ezutn a rszrendszereket egymstl fggetlenl fejleszthetjk tovbb. A dekompozci kzvetlenl nem jr az absztrakcis szint cskkentsvel. Az azonban igaz, hogy a dekompozci ltalban egy finomtsi lps utn vlik szksgess, amikor a feltrul rszletek mr ttekinthetetlenn

vlnak. Fordtott irnyban: a rszekre bonts egy absztrakcis lpsben eltnhet, hiszen ppen az vlhat rdektelenn, hogy milyen rszrendszerekbl ll a teljes rendszer. Az absztrakci s a dekompozci az ember sztns gondolkodsi technikja. Ltezsket a beszlt nyelvben is megfigyelhetjk. Amikor fogalmakat hasznlunk, akkor konkrt dolgok absztrakt modelljeivel van dolgunk. Amikor pldul autrl beszlnk, akkor brmilyen mrkj, tpus, szn, mret, kor autra gondolhatunk. Amikor az aut mkdst magyarzzuk, clszeren a szerkezett vzoljuk fel, a motort, a kereket, a fket stb.. Ezeket a szerkezeti egysgeket azutn kln-kln trgyalhatjuk tovbb. Az absztrakcit s a dekompozcit mind a fogalmi, mind pedig az implementcis modell kialaktsakor bevethetjk. gy tulajdonkppen nem egyetlen fogalmi modellel s egyetlen implementcis modellel dolgozunk, hanem mindegyik egy-egy modellsorozatt vlik. A sorozat tagjai finomtssal, illetve absztrakcival llthatk el egymsbl. Szemlltessk az elmondottakat egy vasti helyfoglalsi rendszer pldjn! A fogalmi modell magas absztrakcis szint elemei a kvetkezk: jegy, helyjegy, vonat, indulsi s cllloms, kocsiosztly, szmla, foglals, trls, fizets. Ha ksrletet tesznk a fogalmak tartalmnak definilsra, akkor alacsonyabb absztrakcis szintre kerlnk, kzelebb a konkrtumokhoz. Pldul elemezhetjk a helyjegyen vagy a szmln szerepl adatokat (vonatszm, kocsiszm, lhely sorszma stb.), vagy a foglals trlsnek mechanizmust. Vgl eljuthatunk a helyjegyen vagy a szmln szerepl szvegekig, illetve a vasti alkalmazott elemi tevkenysgig (pldul a jegy lepecstelse), mint konkrtumig. De mit is tekintsnk konkrtumnak? Hiszen elemezhetnnk tovbb a pecstels kzben a blyegz mozgst, a jl olvashat lenyomathoz szksges nyomert stb. Valsznleg mindannyian egyetrtnk azonban abban, hogy a megoldand feladat szempontjbl ezek mr lnyegtelen (nem relevns) rszletek. A

pecstelst nyugodtan tekinthetjk tovbb nem rszletezend elemi mveletnek. Termszetesen a szoftver sajt vilgban is klnbz absztrakcis szint fogalmakat hasznlhatunk. Magas absztrakcis szint fogalmak pldul az alkalmazi program, az opercis rendszer, az adatbzis-kezel. Alacsonyabb szintek a fjl, az temez, a lekrdez parancs. Az absztrakcis szintet tovbb cskkentve olyan fogalmakig jutunk el, mint a rekordszerkezet vagy a programmodul. Folytathatjuk a finomtst az elemi adatok (int, char) s vezrl szerkezetek (switch, while, for) irnyban. Konkrtumnak pldul a szoftver egy kzismert programozsi nyelven lert kdjt tekinthetjk. Ennek tovbbi finomtsa, pldul a fordt ltal ellltott gpi utastssorozat, vagy a futtathat program bitsorozata mr tbbnyire rdektelen. A fenti pldbl azt a kvetkeztetst is levonhatjuk, hogy minden feladathoz a problmatrben s az implementcis trben egyarnt tartozik az absztrakcis szintnek egy relevns tartomnya. Ezen bell rdemes a problmt megragadni. Sem a tl ltalnos, sem a tl aprlkos modell nem hasznlhat. Lthattuk, hogy a vasti helyfoglal rendszer legklnbzbb absztrakcis szintjei megfogalmazhatk a problmatr elemeivel (cllloms, kocsiszm, pecstels), s semmi szksg sem volt olyan szmtgpes fogalmakra, mint a fjl, a rekord vagy a bit. A helyfoglals mkdik szmtstechnika nlkl is. A szoftver fejlesztse sorn kell megtallnunk a fogalmi modell elemeinek megfelelit a szmtgpes vilgban, az implementcis modellben. A teljes helyfoglal rendszer egy sszetett hardver-szoftver egyttes lesz. A jratokat nyilvntart alrendszernek megfelel egy adatbzisokkal dolgoz programrendszer. A vonatokat pldul fjlokkal reprezentlhatjuk, amelyekben egy-egy rekord az lhelyeknek felel meg. A foglals folyamata egy szmtgpes zenetvltssal rhat le. A fogalmi s az implementcis modell klnbz absztrakcis szintjeinek szemlltetst az 1.3. brn lthatjuk.

Ez az bra az 1.2. bra mdostott vltozata, amely minden trben csupn egyetlen rendszert brzol. A fogalmi s az implementcis modellt most egy-egy hromszg jelli. A hromszgek nem is egyetlen modellt, hanem modellsorozatokat jelkpeznek. Minden vzszintes metszetre elkpzelhetnk egy modellt. A hromszgek cscsa a relevns tartomny legmagasabb absztrakcis szintjnek felel meg. Lefel haladva az absztrakcis szint cskken, a hromszg egyre szlesed vzszintes metszete pedig a feltrul egyre tbb rszletet jelkpezi. A hromszgek alapja a konkrtnak tekinthet modellt jelli (a relevns tartomny als hatra). A tovbbiakban ltalban nem hangslyozzuk a modellsorozat jelenltt, de a fogalmi, illetve az implementcis modellen modellsorozatokat fogunk rteni. Felvetdik a krds, hogy a finomtssal, illetve a dekompozcival mekkora lpsekben haladjunk. Egy-egy lpsben mennyit trjunk fel a rszletekbl, hny rszre osszunk fel egy magasabb szinten egysgnek ltsz elemet? Erre ismt az emberi gondolkods tanulmnyozsa alapjn adhatunk vlaszt. Tulajdonkppen az a krds, hogy figyelmnket hny klnbz dolog kztt tudjuk mg viszonylag knyelmesen megosztani. Termszetesen a vlasz egyni kpessgektl, a fejben tartand dolgok bonyolultsgtl ersen fgg, de klnbz vizsglatok megksreltk a jellemz rtk meghatrozst. Sommerville szerint [Som89] ez a szm ht, ms publikcik ennl valamivel nagyobb rtket is megengednek. ltalban senki nem jell meg tnl kisebb s harmincnl nagyobb szmot. Ez azt jelenti, hogy az emberi megrtsre sznt modelleket s azok lersait gy clszer megszerkeszteni, az absztrakcis szinteket oly mdon egymsra pteni, hogy egyidejleg ne kelljen tz krli szmnl tbb fogalmat fejben tartani.

1.3. bra A szoftver fejlesztse sorn egyrszt ltre kell hozni a fogalmi, msrszt az implementcis modell klnbz absztrakcis szint vltozatait (a modellsorozatokat). Harmadrszt pedig el kell vgezni a kt modell megfeleltetst. Helyesen megtervezett s ltrehozott rendszerben a legmagasabb absztrakcis szint fogalmi modell (nevezetesen a "feladatot megold rendszer") szksgkppen megfelel a legmagasabb absztrakcis szint implementcis modellnek (nevezetesen a "feladatot megold szmtgpes rendszer"-nek). Ugyangy szksgkppen fennll a megfelels a legalacsonyabb (konkrt) szinten is. Ha ezek a megfelelsek nem llnnak fenn, akkor a rendszer nem teljesten feladatt. A szinteket thidal struktra azonban nem szksgkppen hasonl a kt trben. Helyfoglal rendszernkben pldul nem biztos, hogy tallunk egy fjlt s egy vonatot, amelyek klcsnsen s egyrtelmen megfeleltethetk egymsnak. Az azonban biztos, hogy a rendszer kimenetein konkrt helyjegyeknek megfelel nyomtatott bizonylatokat kell kapnunk. A tapasztalat azt mutatja, hogy ezek a kzbls megfeleltetsek nem szksgszerek, fennllsuk rendkvl hasznos. A fejlesztsi mdszertanok eddigi trtnetbl egyrtelmen leszrhet tendencia, hogy a bonyolultsgot akkor tudjuk uralni, vagyis akkor tudunk kezelhet, mdosthat, karbantarthat

szoftvert ellltani, ha a problmatr s az implementcis tr fogalmait minden absztrakcis szinten minl inkbb igyeksznk megfeleltetni egymsnak. Ms szavakkal: a problmatr brmilyen absztrakcis szint fogalma legyen felismerhet s elklnthet az implementci megfelel szint modelljben, st magban az implementciban is. E tendencia jegyben alakult ki a knyv trgyt kpez objektumorientlt mdszertan is. Sajnlatosan ezen elv kvetkezetes betartst megnehezti, hogy a fogalmi modellt tkrz implementci hatkonysga nem mindig kielgt.

1.2.3. A lers szigorsgaAmikor a fejleszts sorn ltrehozunk egy modellt, az adott nzetbl, adott absztrakcis szinten brzolja a rendszert. Ahhoz, hogy ezt a modellt ksbb ismtelten fel tudjuk idzni, valamint msokkal meg tudjuk ismertetni, dokumentlnunk kell, ltre kell hoznunk a modellnek emberi rtelmezsre sznt lerst. Azt mondtuk, hogy a modell a valsg gondolati kpe, s mint ilyen, szemlyhez ktdik. Krds, hogy tudunk-e a modellrl olyan lerst kszteni, amelyet mindenki azonosan rtelmez. Teljes ltalnossgban a krdsre nagyon nehz lenne vlaszolni, de berjk kevesebbel is, megelgsznk azzal, hogy csak azok rtsk azonosan, akik a rendszer ltrehozsban valamilyen mdon rszt vesznek. A krdsre igen vlaszt csak akkor kaphatunk, ha a lers (reprezentci) egyrtelm, pontos s kimert. Ezt gy rhetjk el, hogy azok, akiknek a lerst rtelmeznik kell, megegyeznek bizonyos tartalmi s formai szablyok szigor betartsban, azaz a lerst formalizljk. Formlisnak nevezzk az olyan reprezentcit, amely csak pontosan definilt fogalmakat, szerkezeteket s mveleteket hasznl, s a defincik megadsnak formit is rgzti. A szoftver konkrt implementcis modelljnek szintjn (ami nem ms, mint a forrsnyelv lers) a szablyok adottak, ezeket a programozsi nyelv definilja. A programnyelvet a programozk s

a fordtprogramok is rtelmezik. A magasabb absztrakcis szinteken kszl dokumentumokat azonban klnsen a fejleszts kezdeti szakaszban igen klnbz elismeretekkel, felkszltsggel rendelkez szemlyek (leend felhasznlk, menedzserek, fejlesztk) rtelmezik. Ezrt a szablyok esetleg kimerlnek annak megktsben, hogy a dokumentum milyen beszlt nyelven kszljn (pldul kszljn magyarul). Ez pedig, mint ltni fogjuk, aligha tekinthet formlisnak, s komoly flrertsek forrsa lehet. A klnbz kifejezsi mdok skljn a legkevsb formlisnak az l beszdben elfordul szerkezeteket tekintjk. Szndkosan kerltk a mondat kifejezst, mivel a "ktetlen" beszdben gyakorta nem is hasznlunk egsz mondatokat. Mr maga a ktetlen sz is a formktl val fggetlensget jelenti. Az l beszd szerkezeteinek rtelmezse ersen fgg a szitucitl, amelyben a szavak, mondattredkek elhangzanak. Tovbb a kzlt informcik trolsa sem megoldott (hangfelvtel persze kszthet, de ennek kezelse, a szvegkrnyezet felidzse nehzkes). Nem vletlen, hogy az letben valamennyi fontos dolgot rsban rgztnk. Pldul egy jogszably sem egyb, mint az letviszonyok szablyozsnak formalizlt lersa. Ismert, hogy mg a jl tagolt, paragrafusokba szedett, korrektl fogalmazott jogi kijelentseket is meglehetsen tgan lehet rtelmezni. A reprezentcik kznyelvi, szveges megfogalmazsnak problmja ketts. Egyrszt a kznyelvben hasznlt fogalmak nem elg egyrtelmek, msrszt a nyelvi elemekbl kpezhet szerkezetek szablyai sem elg szigorak. A fogalmi egyrtelmsg problmjnak rzkeltetsre gondoljunk a szmtgpes rendszerekre vonatkoz kvetelmnyek kztt gyakran elfordul "optimlis", "gyors" "rugalmasan bvthet" stb. megfogalmazsokra, amelyek nmagukban aligha rtelmezhetk. Az irodalmi mvekben st mr az ltalnos iskolai fogalmazsokban is elvrt stlusjegyek mint pldul szinonimk hasznlata szismtlsek helyett egy szoftver dokumentum

rtelmezst bizony nem teszik knnyebb. A szerkezeti egyrtelmsg problmjra pedig csak egyetlen plda: lettapasztalatunkat flretve prbljuk eldnteni, hogy vajon a "Megetette a lovat a zabbal." kijelentsben a l ette-e a zabot, vagy a zab a lovat. A formalizltsg mrtknek nvelstl vgeredmnyben azt vrjuk, hogy a reprezentci pontosan s egyrtelmen lerja a modellt, ami pedig remnyeink s szndkaink szerint minden lnyeges vonsban pontosan tkrzi a valsgot. A valsg s annak formalizlt reprezentcija kztti egyezsget pedig azrt keressk, mert ha ez fennll, akkor a formalizmuson rtelmezett s igazoltan helyes mveleteket vgrehajtva a valsgra vonatkoz korrekt kvetkeztetsekre juthatunk. A formalizlt reprezentci gyakorta nem szveges, hanem pldul grafikus formt lt. Egy adott jellsrendszer betartsval ksztett bra nem csak a formalizltsg szempontjbl, hanem kifejez erejt tekintve is igen kedvez tulajdonsgokat mutat. Minden lersnl tbbet jelent pldul egy hz esetben mondjuk az alaprajz, vagy a homlokzat kpe. Akik lttak szabadalmi lersokat, pontosan tudjk, hogy milyen bonyolult, "... azzal jellemezve, hogy..." alak mondatokban lehet csak egy nagyon egyszer brt szvegesen lerni. rdemes utnagondolni, hogy vonalakat s krket rajzol program futsnak eredmnye (az bra) s a program szvege (nagyon formlis lers) kztt kifejez erben mekkora klnbsg van. Nem vletlenl tartjuk az brkat a szvegnl kifejezbbnek. Mivel a rajz mszaki, ptszeti vagy villamos kapcsolsi rajz lnyegesen szigorbb szablyoknak felel meg, mint az l szveg, ezrt a rajzbl kiindulva jl definilt, ellenrztt lpsek segtsgvel hamar eljuthatunk a realizlsig. Gondoljunk a villamos kapcsolsi rajz alapjn nyomtatott ramkri lapot szerkeszt rendszerekre! A legszigorbban formalizlt lersoknak a matematikai modelleket tekintjk.

1.2.4. A fejleszts folyamataEgy "nullrl indul" szoftverfejleszts ltalban gy kezddik, hogy a valsgban zajl folyamatok megfigyelse alapjn felmerl egy problma, aminek megoldsa lehetsgesnek s clszernek ltszik valamilyen szmtgpes rendszer alkalmazsval. Tekintve, hogy a valsgot eleve a fogalmi modell alapjn figyeljk s rtjk meg, kiindulsi pontunk ltalban a fogalmi modell "cscspontja" (lsd 1.4. bra). Gondolatainkban megjelennek a rendszer krvonalai, mgpedig igen magas absztrakcis szinten. Ezeket a krvonalakat ltalban igen kevss formalizlt lerssal tudjuk megadni. Mindez pldul trtnhet gy, hogy a leend felhasznl megkeres bennnket, s l beszdben, a sajt terminolgijt hasznlva eladja meglehetsen kds elkpzelseit arrl, hogy mit vrna a rendszertl. ltalban mg a kitzend feladat tekintetben is tancsokat kr. Innen kell eljutnunk addig, hogy a problmt megold rendszer elkszl, s a valsgban mkdik. Kzben az absztrakcis rseket thidalva ki kell alaktanunk a teljes fogalmi s a teljes implementcis modellt, valamint a konkrt implementcis modell alapjn ltre kell hoznunk a konkrt, a valsgba tltetett implementcit. Az 1.4. brn nyomon kvethetjk a fenti folyamatot, s a korbbiakhoz kpest mr kiss finomtva rtelmezhetjk a fejlesztsi folyamat klnbz tevkenysgeit. A valsg gondolati kpnek kialaktst modellezsnek, a fogalmi modell szerkezetnek kialaktst analzisnek, az implementcis modell szerkezetnek kialaktst tervezsnek nevezzk. A konkrt megvalstst implementcinak, a fogalmi s az implementcis modell megfeleltetst pedig lekpezsnek nevezzk. A tervezs megjellst gyakran tgabb rtelemben hasznljuk, ilyenkor belertjk a lekpezst is (lsd 1.2. bra).

1.4. bra A legtbb esetben a folyamatot az (1) jel pontbl indtva a (2) jel pontba kell eljutnunk, mikzben mindkt teljes modellt megalkotjuk, azaz mindkt hromszget kitltjk. Ezt az utat tbbflekppen bejrhatjuk. A bejrs kt szlssges pldjt lthatjuk az 1.5. s az 1.6. brkon. Az 1.5. bra szerint haladva elszr a fogalmi modellt alaktjuk ki teljes egszben analizlunk mghozz gy, hogy a ltrehozott reprezentcik absztrakcis szintjt fokozatosan cskkentjk. Ezt fellrl-lefel (top-down) haladsnak nevezzk. Az absztrakcis szintet gy cskkentjk, hogy dntseket hozunk arra nzve, hogy az addig nem rszletezett fogalmakat, tulajdonsgokat s mveleteket milyen mdon ptjk fel egyszerbb komponensekbl. A legmagasabb absztrakcis szintrl teht dntsek sorozatval jutunk a konkrtumok szintjre. Minden dnts finomtja a modellt, jabb rszleteket tr fel belle. Minden dntshez ki kell vlasztanunk valamit, amirl dntnk. Ezt a valamit dominns fogalomnak vagy strukturl objektumnak nevezzk. Az gy vgrehajtott dntsi sorozat pedig lpsenknti finomts nven ismert.

1.5. bra Az albbiakban egy pldn szemlltetjk a finomts folyamatt. Tekintsnk egy hzat, amely szobkbl ll. Ha egy szobt konkrtabb akarunk tenni azaz preczebb, a rszleteire kitr lerst kvnunk adni akkor vlasztanunk kell egy szempontot, ami szerint finomtunk. Amennyiben az plet alakja rdekes szmunkra, akkor a dominns fogalom a geometria lesz, s a szobt mint geometriai alakzatot rjuk le. Ha lakberendezi szempontbl vizsgldunk, akkor a btorzattal jellemezzk a szobt. Ha vegessel trgyalunk, t minden bizonnyal a nylszrkrl kell tjkoztatnunk. Az 1.5. bra szerint elszr lpsenknti finomtssal kialaktjuk a teljes fogalmi modellt. Ezutn ttrnk az implementcis modellre, ahol ugyancsak ezt a stratgit kvetve haladunk. Krds, hogy az implementcis modell finomtsa kzben eltekinthetnk-e a mr ksz fogalmi modelltl. Nyilvnvalan nem, hiszen a konkrt implementcinak ugyangy kell viselkednie, mint a konkrt fogalmi modellnek. Az implementcis modell finomtsa kzben teht elbb-utbb meg kell cloznunk a konkrt fogalmi modell lekpezst. Sajnos semmifle garancia sincs arra nzve, hogy az implementcis modell finomtsnak kezdeti szakaszban ne hozzunk olyan rossz dntseket, amelyek megneheztik a fejlesztst. Egy msik stratgia lthat a 1.6. brn. A kezdeti (1) szakaszban hasonlan jrunk el, mint az elbb. Ezt kveten azonban az implementcis modellt alulrl-felfel (bottom-up) ptkezve hozzuk ltre. A (2) lps sorn az implementcis modell

konkrtumaibl sszerakjuk a fogalmi modell konkrtumait (szintzis), majd az implementci kezelhetsge rdekben egyre magasabb absztrakcis szint implementcis fogalmakat (pldul adatbzisok, modulok, fjlok, taszkok stb.) alkotunk. Ez a stratgia sem garantlja a fogalmi s az implementcis modell struktrjnak hasonlsgt, csak a felttlenl szksges megfeleltetseket biztostja. Emiatt nehz a program megrtse s a fogalmi modellben trtn legkisebb vltoztats is az implementci jelents mrtk tdolgozst teheti szksgess.

1.6. bra A fenti kt alapeset problminak kikszblsre szmos mdszertan javasolja az 1.7. bra szerinti stratgit. Az alkalmazott gondolatmenet: egy kicsit analizlunk, egy kicsit terveznk, s ezt ismtelgetjk. Vgrehajtunk egy finomtsi lpst a fogalmi modellen, meggondoljuk ennek kvetkezmnyeit, kihatst az implementcis modellre, majd ennek figyelembevtelvel az implementcis modellen is vgrehajtunk egy finomtsi lpst. Ezt ismtelgetve vgl olyan megoldshoz jutunk, amelyben a fogalmi modell s az implementcis modell szerkezetileg azaz a legklnbzbb absztrakcis szinteken is fedi egymst. A mdszer risi elnye, hogy az implementciban felismerhetk lesznek a problmatr fogalmai. Emiatt a szoftver knnyebben megrthet, ha pedig mdosts vlik szksgess, tudjuk hova kell nylnunk. Az utbb vzolt stratgia alkalmazsnak nehzsge abban ll, hogy a fogalmi modellek a felhasznlsi terlettl fggen a legvltozatosabb alakokat lthetik. Vannak szakmk, amelyek

elszeretettel rjk le problmikat pldul differencilegyenletek formjban, msok l nyelven fogalmazott szablyok tmegvel adjk meg, mit vrnak a rendszertl. Megknnyti a helyzetnket, ha minl elbb az analzist olyan irnyba tudjuk terelni, a fogalmi modellben pedig olyan dolgokat s szerkezeteket tudunk bevezetni, amelyeket klnsebb nehzsgek nlkl t tudunk ltetni az implementcis modellbe. Ha az tltets szablyai ismertek (pldul hasonl feladat megoldsa sorn mr eredmnyesen alkalmaztuk ket), akkor munka kzben el is hagyhatjuk a gyakori kitekintgetst az implementcis trre, hiszen ismert, hogy az analzis eredmnyeknt kapott fogalmi modell klnsebb gondok nlkl tvihet az implementcis trbe. Ezekben az esetekben az analzis s a tervezs kztt nem mindig hzhat les hatrvonal. A knyv trgyt kpez objektumorientlt mdszertan szintn ezt a gondolatmenetet kveti.

1.7. bra Akr a problmatrben, akr az implementcis trben dolgozunk, a modellek, illetve lersaik kialakulsa egy msik szempontbl is vizsglhat, az absztrakci s a formalizltsg fggvnyben (lsd 1.8. bra). A fejleszts kiindul pontja ltalban az brn lthat, (1) jel pont. Ez a felhasznl ltal hasznlt, igen magas absztrakcis szint, egyltaln nem formlis lers. Innen kell eljutnunk a (2) jel pontba, ami a programszveget jelenti, amely az implementcis trben konkrt szmtstechnikai fogalmakat hasznl s szigoran formalizlt. Az 1.8. bra alapjn is bevezethetnk kt fontos fogalmat. A formalizltsg nvelst a gyakorlatban specifiklsnak nevezzk.

Azt a tevkenysget, amikor az absztrakcis szintet cskkentve egy magasabb absztrakcis szint elemet alacsonyabb szint elemek segtsgvel lltunk el, tervezsnek hvjuk. A fogalmakat ilyen rtelemben hasznlva nem foglalkozunk azzal, hogy a tevkenysg ppen melyik trben, melyik modellen zajlik. Krds, hogy az (1) jel pontbl melyik ton juthatunk el a (2) pontba. Az brn a kt, nagybetvel azonostott tvonal kzl a B lenne az elvileg legjobb vlaszts. Ebben az esetben a felhasznl ltal hasznlt magas absztrakcis szint fogalmak segtsgvel olyan szigor, formlis lerst ksztnk, amely alkalmas arra, hogy jl definilt transzformcis lpseket vgrehajtva (akr szmtgpes tmogatssal) kzvetlenl a kdhoz jussunk. Tipikusan gy oldunk meg feladatokat az elemi matematika s fizika krbl: Tanulmnyozva a feladat szveges (kevss formlis) formjt felrjuk az egyenletet (szigor formalizmus), majd az egyenleten a matematika ltal megengedett lpseket vgrehajtva az egyenletben megfogalmazott llts igazsgtartalmt megrz talaktsokkal az egyenletet olyan alakra hozzuk, amely szmunkra a megoldst jelenti (pldul az egyenletben szerepl ismeretlent kifejezzk). A B tvonalon haladva egyetlen specifikcis lpsben eljutunk oda, ahonnan mr a tervezs kvetkezhet. Ez a megolds azonban csak a trivilisan egyszer esetekben hasznlhat, mivel jelenleg nem ll rendelkezsnkre olyan szigor formalizmus, amellyel egy bonyolultabb fogalmi modell a maga magas absztrakcis szint fogalmaival sszer terjedelemben lerhat lenne.

1.8. bra

Az A ton val halads azt jelenten, hogy egyidejleg specifiklunk s terveznk is. gy tnik azonban, hogy az emberi gondolkods nem tud egyszerre mindkt irnyba haladni, ezrt a gyakorlatban a specifikcis s tervezsi lpsek egymst vltogatjk az 1.9. brn lthat mdon. Az brn a specifiklst jelz vzszintes szakaszokat a tervezs kveti. Az utols tervezsi lps (a kdkszts) kivtelvel a tervezs nem kizrlag az absztrakci cskkentst jelenti, mivel a tervezs sorn egy magasabb absztrakcis szint elemet konkrtabbakbl ptnk fel. gy az ptelemknt hasznlt konkrtabb elemek szintjn a terv kevsb formlis, tovbbi specifiklst ignyel. A korbbi "szobs" pldval jl megvilgthat a jelensg. Tervezzk meg, hogy egy szobban hol legyenek a nylszrk! Legyen a tervezi dntsnk az, hogy kivlasztjuk, melyik falra kerljn ablak! Ez az ablak mg nem specifiklt, nem rgztettk a pontos helyt, a mrett, a tpust, a gyrtjt stb., azaz kzvetlenl a dnts utn az ablakot is tartalmaz szoba sszessgben kevsb specifiklt, mint az ablaktalan szoba a dnts eltt. A technolgikban megjelen szoftverfejlesztsi gyakorlat vgs soron nem ms, mint a fentiekben bemutatott elvi folyamatoknak irnythat, menedzselhet formja.

1.9. bra

1.3. A szoftver letciklusaAz elz kt pontban meghatroztuk a technolgia s a termk fogalmt, valamint tisztztuk a fejleszts elvi alapjait. Jelen pontban

kiindulva a termkek szoksos letciklusbl vizsglat al vesszk a szoftver letciklust s bemutatjuk annak klnbz modelljeit. A fejezet vgn a minsgbiztosts nhny krdsvel is foglalkozunk.

1.3.1. Termkek letciklusaMint mr emltettk, a termkek sorst a rjuk val igny felmerlstl a termk forgalombl val kivonsig (feledsbe merlsig) az letciklus rja le. A hagyomnyos (egyszerbb, anyagi jelleg) termkek letciklusnak jellegzetes szakaszai pldul a gyrtmnytervezs, a prototpuskszts, a gyrtstervezs, a nullszria gyrtsa, a gyrts, a karbantarts. Hosszabb idn t gyrtott tmegcikkek esetn mind a termk, mind az elllts technolgija tbbszr mdosul a termkrl szerzett tapasztalatok alapjn, valamint a technikai fejlds kvetkeztben. Ilyen letciklust lthatunk az 1.10. brn. Egyedi, bonyolult termkek gyakori jellegzetessge, hogy az els mkd pldny egyben az egyetlen is. Ilyenkor a tervezs szerepe megn, a fejleszts kltsgei nem oszlanak meg a sorozatban ellltott darabok kztt. Nem vletlen, hogy az ilyen tpus termkek megrendeli klns jelentsget tulajdontanak a szllt cg referenciinak.

1.10. bra

Az letciklus teht magas szinten rja le egy termk kezelsnek folyamatt, azaz a termkkel kapcsolatos teendket s azok sorrendjt. Az letciklus fogalmnak bevezetse megknnyti a szksges munkk felmrst, megtervezst s kirtkelst. Tudatos feltrkpezse, st megtervezse a termk ellltsval foglalkoz cg alapvet rdeke. Megfigyelhet az a tendencia, hogy a gazdasgi tervezs egyre inkbb a termk teljes lettartamra kiterjed tevkenysgek kltsgoptimumt keresi a loklis (pldul a csak gyrtsi, vagy az anyagkltsgekre vonatkoz) optimumok helyett. Vizsgljuk meg ezek utn a szoftver azon tulajdonsgait, amelyek az letciklus jellegt befolysoljk!

1.3.2. A szoftver letciklusnak jellegzetessgeiA 1.2. pont bevezetsben megllaptottuk, hogy a szoftver letnek slyponti szakasza a fejlesztsi, ezen bell is a termkfejlesztsi szakasz. A szoftver lettrtnett ler kezdeti modellek ezrt szinte kizrlag az els mkd pldny elkszltig terjed szakaszt vettk vizsglat al. Mra a helyzet jelentsen megvltozott. A szoftverrl kiderlt, hogy folyamatos vltozsokra hajlamos, kezelshez olyan letciklus-modellek szksgesek, amelyek ezt a tulajdonsgt is tkrzik. Ennek ellenre az letciklus termkfejlesztsi szakasznak elsdlegessge (dominancija) ma is fennll. A szoftver vltozsi hajlamt kt tnyez okozza. Egyrszt a vltoztatsok technikailag knnyen kivitelezhetk. Ezrt a felhasznlk elvrjk, hogy egyre jabb ignyeiket gyorsan kvessk a szoftver jabb vltozatai. Msrszt a szoftvertermk ltalban sokkal bonyolultabb, mint a hagyomnyos anyagi jelleg termkek. Ezrt nehz a "nullrl indul" fejleszts folyamn mr az els pldnyt gy elkszteni, hogy az minden ignyt kielgtsen. A szoftver vltozsi hajlama ezrt nemcsak azt eredmnyezi, hogy a nagypldnyszm szoftverek verzii srbben kvetik egymst, mint ahogyan az anyagi jelleg termkeknl megszoktuk, hanem azt is, hogy letk sorn az egyedi szoftverek is szmos vltoztatson, mdostson, bvtsen esnek t.

Amennyire a kivitelezs viszonylagos egyszersge csbt a gyakori vltoztatsra, annyira vatossgra intetnek a bonyolultsgbl fakad nehzsgek. A tapasztalatok megmutattk, hogy egy bonyolult rendszerben minden mdosts rendkvl veszlyes. Ugyanis gyakran nemcsak a kvnt elsdleges hatst rjk el, hanem olyan kellemetlen mellkhatsok is jelentkezhetnek, amelyekre nem gondolunk a mdosts megtervezsekor. A szoftverszlltk gyakorta nem adjk t a megrendelnek a szoftver forrsnyelv reprezentcijt. Ezen tnynek csak egyik oka a szerzi jog vdelme. A msik ok az, hogy a szlltk el akarjk kerlni a szoftver tgondolatlan megvltoztatst. Ugyanakkor a fejlesztk elemi rdeke, hogy a felmerl mdostsi ignyeket minl gyorsabban s minl biztonsgosabban ki tudjk elgteni, egy-egy j igny kielgtsre pedig minl gyorsabban tudjanak lehetleg mr meglv komponensekbl j rendszert kszteni. Ezrt lett a szoftvertechnolgia kt kulcsszava a mdosthatsg s az jrafelhasznlhatsg. A ma hasznlatos, igen bonyolult szoftverek egy-egy jabb vltozatnak ellltsa igen nagy az els verzi ellltsval sszemrhet feladat. Ezrt marad meg az lland vltozst tkrz, ciklikus lettrtneten bell a termkfejlesztsi szakasz dominancija. Vizsgljuk meg, milyen jellegzetes lettrtneti smk jttek ltre a szoftver projektek kvetsre! Elljrban is hangslyozzuk, hogy ezek olyan alapsmk, amelyek egy-egy konkrt projekt esetn egymssal kombinlva is alkalmazhatk. Az letciklussmkat is modelleknek szoks nevezni. Termszetesen itt nem a rendszer modelljrl, hanem a teljes projekt folyamatnak modelljrl van sz.

1.3.3. A vzessmodellA szoftverfejleszts problminak felismerse utn a projekt folyamatnak lersra kialakult legrgebbi modell a vzessmodell, amelyet fzismodellnek is neveznk. Nevt a szemlltet bra jellegzetes alakjrl kapta (1.11. bra). A modell a

termkfejlesztsre koncentrl, azaz az els mkd pldny ellltsig terjed szakasz lefolyst brzolja. Ma ltalban a vltoztatsokat is kezel ciklikus modellekbe gyazva hasznljk, nmagban legfeljebb nagy egyedi szoftverek esetn fordul el.

1.11. bra A modell a fejlesztsi folyamat kiindulsi pontjnak a kvetelmnyeket tekinti. Az els fejlesztsi ciklusban ezek a kvetelmnyek j kvetelmnyknt jelennek meg. A ksbbi vltozatoknl azonban mr nagyrszt a felhasznli, zemeltetsi tapasztalatok alapjn mdostott korbbi kvetelmnyekbl indulunk ki. A vzessmodellben megjelen els szakasz az analzis, amelynek eredmnyeknt ltrejn egy specifikci. A specifikci alapjn hrom tovbbi lpsben hozzuk ltre a szoftvert. Az elst architekturlis, a msodikat pedig rszletes tervezsnek nevezzk. A kt tervezsi lps a rendszerrl alkotott modellek absztrakcis szintjben klnbzik. A rszletes tervezs vgeredmnyeknt egymstl fggetlenl, nllan kdolhat rszek specifikciit lltjuk el. A kvetkez lps a kdols, amibe belertend az nllan kdolt rszek tesztje is. Ezen lpsen bell hzdik a tervezs s az implementci hatrvonala, azaz itt trnk t a gondolati skrl a valsgba. Korbban, a fejleszts elvi modelljnek trgyalsakor az implementcival nem foglalkoztunk. Valjban a fejleszts igen fontos szakasza a vzessmodellben integrcinak nevezett fzis, amelyben az nllan kdolt s kiprblt rszekbl lltjuk ssze a teljes rendszert, illetve a korbbi, meglv kdot s a mdostsok eredmnyeknt ltrehozott kdot sszeillesztjk. Az integrcihoz szorosan kapcsoldik a teljes rendszerre kiterjed ellenrzs, tesztels.

A szemlltet brn a lpcszs egyfell a tevkenysgek sorrendjt mutatja, msfell pedig azt kvnja brzolni, hogy amint a vzessen sem tudunk felfel haladni a megelz fzisokra nincs visszatrs. Valjban ilyen visszalpsekre gyakran van szksg, elssorban akkor, ha rjvnk, hogy valamelyik korbbi fzisban hibztunk (visszacsatolsos vzessmodell). A visszalps kltsgei annl nagyobbak, minl nagyobb a lps, azaz minl korbbi fzistl kezdden kell a mr elvgzett munknkat mdostani, javtani.

1.12. bra A vzessmodell egy msik, tovbbfejlesztett vltozata az gynevezett V-modell, amelyik az implementcis s tesztelsi szakaszt a V alakzat jobbra felfel halad gra helyezi, s rszletezi (lsd 1.12. bra). Minden tervezsi fzis utn a fejleszts kt gon fut tovbb. Egyrszt megkezddik a kvetkez tervezsi fzis, msrszt lehetleg egy fggetlen csoport munkjaknt megkezddik a megfelel tesztfzis tervezse. A vzessmodell gyakorlatban trtn alkalmazshoz definilni kell, hogy melyek az egyes fzisok befejezsnek kritriumai. Mikor mondhatjuk azt, hogy most elrkeztnk pldul az analzis fzis vgre? A fzisok elhatrolsra szksgnk van, hiszen ellenkez esetben kevs az eslynk, hogy meg tudjuk vlaszolni azt a krdst, hol tartunk a fejlesztsben id s kltsgek tekintetben. A fejlesztsi folyamat ttekinthetetlensge esetn vlik igazz Murphy trvnye, miszerint a fejleszts alatt ll szoftver kszltsgi foka brmely idpillanatban 90%.

1.13. bra A fzisok hatrait az ajnlsok s a szabvnyok bizonyos dokumentcik (reprezentcik) meglthez, tovbb ezek ttekintst szolgl sszefoglal s rtkel megbeszlsek (mrfldkvek) megtartshoz ktik. Az elrsok a dokumentumok elnevezsn kvl rszletesen szablyozzk azok pontos tartalomjegyzkt is. Az egyik legszigorbb szabvny, az USA Vdelmi Minisztriuma ltal kidolgozott DoD-2167 szm szabvny, amelyik tbb mint hatvan dokumentci megltt rja el. Az 1.13. brn a fzismodellhez kapcsold dokumentcik s mrfldkvek szerepelnek. Az brn az emltett DoD-2167 szabvny egy nagyon leegyszerstett vltozata lthat. Az egyes fzisok hatrainl s az analzis fzis alatt DLT betkkel feltntettk a mrfldk elnevezsnek hrombets kdjt. Az albbiakban sszefoglaljuk az brn szerepl betszavak angol s magyar rtelmezst.

P FR S

Product Feasibility Review Software Requirements

Megvalsthatsgi vizsglat Kvetelmnyelemzs

RR Review P DR C DR S CR A TR P RR P Preliminary Design Review Az architektra-tervek ttekintse A rszletes tervek ttekintse

Critical Design Review

Source Code Review

A forrskd fellvizsglata Az elfogadhatsgi teszt ttekintse Forgalombahozatal eltti ttekints Projektrtkels

Acceptance Test Review

Product Release Review Project Post-Mortem

PM Review

1.3.4. Az inkrementlis fejlesztsi modell s a prototpusA vzessmodell igen j szolglatot tett annak tudatostsban, hogy a szoftverfejleszts nem azonos a programozssal. A modell gy nmagban a nagy, egyedi rendszerek fejlesztsi folyamatnak kezelsre alkalmas. Korltai akkor jelentkeztek, amikor kiderlt, hogy a szoftver vltozsi hajlama mg az egyedi rendszerek esetn sem szorthat merev fzishatrok kz. A leggondosabb tervezs ellenre is csaknem minden rendszer tadsakor, vagy prbazeme sorn felmerlnek olyan mdostsi ignyek, amelyek mg a kvetelmnyekre is visszahatnak. Az ltalnos cl, nagypldnyszm szoftverek esetn a mdostsi ignyek pedig folyamatosan jelentkeznek. A gyakorlatban a legtbb szoftver letnek nagyobbik rszt teszi ki s a kltsgek nagyobb rszt is ignyli az egyre jabb vltozatok, verzik ellltsa, a mdostsok vgrehajtsa. Ezt a tevkenysget karbantarts (maintenance) nven szoks emlteni. Az j szoftver fejlesztse ebben a folyamatban mindssze egy specilis esetet kpvisel, az els vltozat ellltst. Ekkor a "semmibl" hozzuk ltre az els verzit, ezt kveten pedig a mr

meglv vltozatok mdostsval lltjuk el az jabbakat. Az 1.14. brn a szoftver teljes lettartama alatt szksges anyagi s lmunka rfordtsokat a kr terlete jelenti meg. Jl lthat, hogy az els fejlesztsre a rfordtsoknak csak tredke esik. Tekintettel arra, hogy egy vltozat fleg az els nmagban is elg nagy lehet ahhoz, hogy vekig kszljn, a fejleszts kzben megszerzett ismeretek fnyben szksgess vlhat a kvetelmnyek mdostsa. Clszer lehet ezrt egy vltozatot is tbb lpsben, alvltozatok egymsutnjaknt ellltani. Ezt a folyamatot nevezzk a fejleszts inkrementlis modelljnek.

1.14. bra Az inkrementlis fejleszts sorn mdunk van arra, hogy a rendszer problematikus rszeit fejlesszk ki elszr. Ha ez sikerrel jrt, akkor ehhez hozzfejleszthetjk az jabb s jabb rszeket. A szoftver problematikus rszeinek ksrletezsre alkalmas megvalstst nevezzk prototpusnak. A tapasztalatok szerint prototpus ksztsre ktfle okbl lehet szksg: - nem vagyunk biztosak abban, hogy valamilyen rszproblmt adott technikai-gazdasgi keretek kztt meg tudunk oldani, - a felhasznl nem tudja pontosan meghatrozni az elvrsait, vagy nem vagyunk biztosak benne, hogy a kvetelmnyeket azonosan rtelmezzk. A szoftverfejleszti gyakorlatban fknt az utbbi eset gyakori. Korbban elemeztk a fejlesztk s a felhasznlk informcicserjnek nehzsgeit. A flrertsek elkerlsnek legjobb mdja, ha minl elbb be tudjuk mutatni, s ksrletezsre rendelkezsre tudjuk bocstani a rendszer viselkedst s kezelsi

stlust rzkeltet prototpust. Ennek rdekben leggyakrabban a felhasznli felletek kszlnek el a prototpus vltozatban. Az inkrementlis fejlesztsi folyamatban teht szemben a vzessmodellel a rendszer nem egyenletesen fejldik teljes szlessgben, hanem bizonyos rszekkel elreszaladunk egszen a megvalstsig, tapasztalatokat szerznk, s az elkszlt rszekhez fejlesztjk hozz a mg hinyzkat. A kt modell termszetesen kombinlhat. Egy-egy inkrementum, vagy a prototpus fejlesztse vgbemehet a vzessmodell alapjn.

1.3.5. SpirlmodellekA szoftver letnek ciklikus jellegt, a folyamatos vltozsokat taln legszemlletesebben a spirlmodell rja le. A modell tbb vltozatban is definilt, egy vltozatt az 1.15. brn mutatjuk be. Az letciklus a ponttal jellt helyrl indul, s ngy trrszen t fut krbe. Az (1) jel trrsz tbb-kevsb megfeleltethet az analzis, illetve a nagyvonal tervezs tevkenysgnek. j eleme a modellnek, hogy tbb alternatva tudatos fellltst javasolja, amelyek mindegyikt ki kell dolgozni olyan rszletezettsgig, hogy rtkelsket el lehessen vgezni. Ezzel kezelhetv vlik az 1.2. brn bemutatott tbb lehetsges megfeleltets. Ugyancsak j elem, hogy a msodik trrszben gazdasgi szemllet kockzatelemzs folyik. A lehetsges megoldsok kzl a minimlis kockzattal rendelkezt tekintjk a legkedvezbbnek. A harmadik trrsz a kivlasztott megolds megvalstst, azaz a rszletes tervezst s az implementcit jelli. A megvalsts s zemeltets tapasztalatainak rtkelse alapjn dnthet el, hogy szksges-e mdosts, tovbbfejleszts, s ha igen, ennek alapjn az j clok is kitzhetk.

1.15. bra

A spirlmodell akr nagyobb lptkben az j verzik ciklusainak lersra, akr kisebb lptkben az inkrementlis fejleszts szakaszainak lersra egyarnt jl hasznlhat. Az egyes szakaszokban az eddig megismert modellek is alkalmazhatk.

1.3.6. Az jrafelhasznlhatsgValamennyi fejleszts sorn termszetes igny, hogy a korbbi fejleszti tevkenysg eredmnyeit ismtelten hasznostsuk. Az jrafelhasznlhatsg a szoftvertechnolgik varzsszava, amelytl sorsunk jobbra fordulst s a szoftver krzis lekzdst remljk. Ms technolgikhoz kpest a szoftver esetn az jrafelhasznlhatsg ltszlag sokkal nagyobb hangslyt kap. Ennek oka, hogy az ipari technolgik lnyegesen kialakultabbak, kikristlyosodtak meghatrozott funkcij alkatrszek, rszegysgek s lezajlott a szabvnyosods folyamata. Ugyanakkor a szoftver terletn nehezen talljuk meg (pontosabban vljk megtallni) az ismtelten hasznlhat komponenseket. jrafelhasznlhat komponenst a szoftverreprezentcik valamennyi absztrakcis szintjn tallhatunk. Egy szoftverrendszer tulajdonkppen alkalmazi programok egyttesnek is tekinthet. A jogi formasgokat rendezve teljes programokat is bepthetnk sajt rendszernkbe. Megfordtva is igaz ez a gondolat. ltalban jl ismert, elfogadott rendszerprogramokra (opercis rendszerek) plnek r a mi alkalmazsaink. A PC-s vilgban a programjainkat DOS vagy Windows krnyezetben futtatjuk. Ezt termszetesnek tartjuk, s elfeledkeznk arrl, hogy valjban az opercis rendszerek jrafelhasznlsval llunk szemben. Ez akkor vlik szembetnv, ha teljes rendszert kell szlltanunk, s knytelenek vagyunk az opercis rendszer jogtiszta vltozatt megvsrolni. Manapsg a szabadon felhasznlhat programok (freeware) szma meg sem becslhet. Ezeket ksztik azzal a szndkkal adjk kzre, hogy jbl felhasznljuk ket. Alkalmazsukat azonban korltozza, hogy mg nem alakult ki olyan rendezett krnyezet, amelyben legalbb ttekintst kaphatnnk a vlasztkrl. Ezen programok minsge s megbzhatsga ugyancsak nem problmamentes.

Jl ismert az jrahasznosts fogalma az eljrsok, illetve a fggvnyek szintjn. Mi ms is lehetne egy C fggvny meghvsa, mint a knyvtrbeli program ismtelt hasznostsa? Pontosan ezrt rdemes megtanulni, hogy milyen fggvnyek is llnak a rendelkezsnkre, hiszen ezen ismeretek ismtelten a hasznunkra vlhatnak. A fenti pldk mindegyike a szoftver ugyanazon reprezentcijnak nevezetesen a kdnak az jrahasznostst volt hivatva bemutatni. A fejlesztsrl kialaktott kpnk szerint hasznos s szksges lehet ms reprezentcik ismtelt felhasznlsa is. Az analzis sorn ksztett dokumentcik csak akkor hasznlhatk fel ismtelten, ha az j feladat a rgebbihez nagyon hasonl, akkor is inkbb csak orientl jelleggel. A tervezs kzben kszlt anyagok mg mindig tl ersen ktdnek az alkalmazshoz, ezrt ritkn jrafelhasznlhatak. Az ismtelt hasznlat lehetsgt jelentsen nveli a konkrt alkalmazstl val fggetlensg. Nem vletlen, hogy elssorban az alkalmazstl kevss fgg felhasznli felletek s az absztrakt adatszerkezetek (listk, fk stb.) kezelsre alakultak ki a hagyomnyos kdnl magasabb szint reprezentcik jrahasznostsnak techniki, amelyek ltalban az objektumorientltsgon alapulnak. Mint a fentiekbl kiderlt, az jrahasznosthatsg alapvet felttele, hogy a hasznosthat komponensekrl, azok paramtereirl, alkalmazsi feltteleirl minden ismeret rendszerezett, knnyen hozzfrhet formban lljon rendelkezsre, s maga a komponens is egyszer technikval legyen alkalmazhat. A hardvert tervez szakemberek szmra rendelkezsre llnak a klnbz gyrtk katalgusai, amelyekben rendben megtallhatk a komponensekkel kapcsolatos ismeretek. A szoftverkomponensek tekintetben mg nem lteznek ilyen jelleg katalgusok, tbbek kztt azrt sem, mert a ksz komponensekbl val ptkezsnek nincsenek olyan kialakult techniki, mint az ramkrk sszeptsnek. Ezrt a programtervez dilemma el kerl, hogy mikor jr el gyorsabban, olcsbban? Ha megprblja felderteni,

hogy van-e, s ha igen, akkor hol, mennyirt, milyen minsgben a feladathoz felhasznlhat ksz szoftverkomponens, vagy ha inkbb sajt maga kszti el azt? Az jrahasznosthatsg ebbl a szempontbl ma a menedzsmenttel szembeni kihvs sikerl-e mielbb sszelltani a hardveresekhez hasonl katalgust. A technolgusok feladata pedig a katalgusba bekerl elemek s az ptkezsi technolgia kidolgozsa, lehetleg egysges elvek alapjn. Mai kiltsaink szerint ezen egysges elv az objektumorientltsg lesz.

1.3.7. Minsgbiztosts a szoftverfejlesztsbenAz utbbi vtizedben a termkek minsgbiztostsnak problmja Eurpaszerte kzponti krdss vlt. (A folyamat az Egyeslt llamokban s Japnban mr valamivel korbban elkezddtt.) Az ISO 9000 sorozat szabvnyok megjelense s egyre szlesebb kr elfogadsa minden termkellltssal foglalkoz vllalkozst arra ksztet, hogy a termkelllts vllalkozson belli folyamatt vizsglat al vegye, rtkelje s elfogadtassa [ISO87]. Jelentsebb rendelsekre egy vllalkozs ugyanis egyre inkbb csak akkor szmthat, ha megszerezte valamely neves minst szervezet tanstvnyt, amely igazolja, hogy a termkellltsi folyamat a vllalkozson bell a szabvny kvetelmnyeinek milyen mrtkben felel meg. Nem kivtel ez all a szoftver mint termk sem, br sajtos jellegnl fogva a szoftver minsgnek megragadsa, szmszerstse s mrse nem knny feladat. Valamely termk minsgt vgs soron az jellemzi, hogy mennyire teljesti a felhasznl elvrsait. Ez egy konkrt pldnyrl utlag (kidobsakor) mr viszonylag egyszeren eldnthet, azonban a felhasznlt inkbb a vsrlskor adhat elzetes becslsek rdeklik. A termk vsrlskor trtn kiprblsa javtja az eslyeket, de klnsen a bonyolult, hossz lettartam termkek esetn a teljes hasznlati idre mg mindig sok bizonytalansg marad. Tapasztalatok szerint bizonyos gyrtk termkeiben jobban megbzhatunk, mint msokban. Sok felhasznl hosszabb idn t sszegyjttt tapasztalatai alapjn a

megbzhatnak tartott gyrtk termkeiben csupn elvtve tallkozunk rejtett hibkkal. Ha mgis hibt tallunk, kiterjedt, kszsges szervizszolglat segt t a problmn, a hasznlat kzben felmerl jabb ignyeinket egyszer bvtsekkel kielgthetjk, stb. Mitl alakulnak ki ezek a klnbsgek az egyes gyrtk termkei kztt mg hasonl alapanyagok, hasonl technolgik alkalmazsa esetn is? A szabvnyok kidolgozst megelz hosszas vizsgldsok eredmnyei szerint a termkek minsge "utlag" nem javthat. A termkek ellltsnak teljes folyamata, st a fejlesztsi ciklusok egymsra ptsnek mdja, azaz a teljes letciklus minden lpse, befolysolja a termk minsgt. A minsgbiztosts lnyeges elemei pldul - a minsgellenrzs minden fzisban, a berkez alapanyagok s rszegysgek vizsglattl kezdden a kibocstsig; - az eredmnyek dokumentlt megrzse, rendszeres kirtkelse s ennek alapjn a gyenge pontok feldertse; - a karbantartsi- s szerviztevkenysg tapasztalatainak rendszeres kirtkelse s figyelembevtele a fejlesztsi clok kitzsekor; - a fenti tevkenysgek szervezeti, jogi kereteinek kialaktsa. Ezrt a minsgbiztostsi szabvnyok clkitzse az, hogy a termkek kezelsnek teljes folyamatt s a gyrtk teljes mkdsi rendjt veszik vizsglat al, s ennek alapjn minstik a gyrtkat. A szoftver termkek tekintetben Eurpban ltalban az ISO 9000-3 ajnlsra hivatkoznak [ISO91], mg az Egyeslt llamok terletn a Carnegie Mellon Egyetem Szoftvertechnolgiai Intzete (Software Engineering Institute, SEI) ltal kidolgozott minstsi rendszer (Capability Maturity Model, CMM) a leginkbb elfogadott [Hum1]. Az ISO 9000-3 elsdlegesen egy ellenrz listaknt hasznlhat, amelyik sszefoglalja, hogy milyen problmkkal kell foglalkozni a

minsgbiztosts keretn bell. Hrom csoportban trgyalja a minsggyi rendszer elemeit: - a keretek (alapdefincik, szervezeti formk, felelssgi krk), - az letciklus tevkenysgei (azok a tevkenysgek, amelyek egy-egy projekthez ktdnek, pldul a kvetelmnyspecifikci, a fejlesztsi folyamat megtervezse, a minsgtervezs, a tervezs s az implementci stb.) - a kiegszt tevkenysgek, amelyek clja az letciklus egyes fzisainak hatkonyabb vgrehajtsa (pldul dokumentcik ellenrzse, adatgyjts a minsgi paramterekhez, mrtkek definilsa, mrs, fejleszteszkzk beszerzse, ksztse, rtkelse, oktats stb.). A CMM modell a szervezetben foly tevkenysg elemzshez ad szempontrendszert, amelynek kirtkelse alapjn a szervezetben zajl munkafolyamat t kategria valamelyikbe sorolhat: a kezdetleges, a megismtelhet, a jl meghatrozott, a szervezett, az optimalizlt. Az utols kt kategria mr szmszerstett jellemzket is megkvetel a munkafolyamat, illetve a termkminsg rtkelsre. Az optimalizlt kategria elrsnek felttele pedig az, hogy legyen kialakult mdszer a tbbfle technolgia kztti rugalmas vlasztsra, st magnak a munkafolyamatnak megvltoztatsra s a projekthez trtn igaztsra is. A fenti szabvnyok s ajnlsok nem ktik meg az alkalmazhat fejlesztsi mdszertanokat. Rgztik azonban, hogy kellen definilt, kezelhet mdszertanokat kell alkalmazni. gy az objektumorientlt mdszertanoknak is csak kellen kidolgozott, menedzselhet, mrhet jellemzkkel igazolt formi szmthatnak sikerre.

2. Az objektumorientltsg fogalmaTartalom

2.1. t az objektumig 2.1.1. A kezdetektl az absztrakt adatstruktrkig 2.1.2. Funkcionlis kontra adatorientlt tervezs 2.1.3. Irny az objektum! 2.2. Az objektum fogalma 2.2.1. Az objektum 2.2.2. Osztlyok s pldnyok 2.2.3. Az objektumok tpusai 2.2.4. Az objektum-vltoz

2.1. t az objektumigA szoftverfejleszts elvi alapjainak trgyalsakor megmutattuk, hogy a tervezs folyamn sorozatos dntsekkel konkretizljuk az ppen tervezend dolgot. A dntst a vlasztott dominns fogalomnak, vagy strukturl objektumnak megfelelen hozzuk meg. Jelen fejezetben azt kvnjuk bemutatni, hogy a megbzhat, korrekt szoftverksztsre val trekvs eredmnyeknt az idk folyamn miknt vltozott a dominns fogalom, s ez miknt vezetett el szinte szksgszeren az objektumorientltsg kialakulshoz.

2.1.1. A kezdetektl az absztrakt adatstruktrkigA szoftverfejleszts kezdeteit taln pontosabb programksztst emlteni a strukturlatlansg jellemezte. Az ltalban nagyon alacsony szint (tbbnyire assembly esetleg valamilyen autokd) nyelveken rt programok nlklztk a tervezsi meggondolsokat, a dntsek nem tudatosan vlasztott strukturl objektumokon alapultak. A program rja a megoldand feladatot egy bonyolult adatmanipulcinak tekintette. A program ezt tkrzte is, minden utasts egy jabb adatmanipulcit vgzett el. A programoz gondolatait az a szemllet hatotta t, hogy a feladat megoldshoz mg mely adatokon milyen vltoztatst kell vgrehajtani. A vltozkat programozs kzben szksg szerint vettk fel, esetenknt a programkd kzepbe belerva. A vezrl szerkezetek mg nem tisztultak le. Az alkalmazsukkal kapcsolatosan olyan kzszjon forg szablyok alakultak ki, hogy pldul ciklus belsejbe nem illik beugrani. Ezen a helyzeten az els magas szint

programozsi nyelvek (FORTRAN, ALGOL) megjelense sem sokat vltoztatott. Amint a megoldand feladatok bonyolultabb vltak, egyre inkbb csak kivteles kpessg, "zsenigyans" programozk voltak kpesek eligazodni a kialakul szvevnyes programszerkezetekben, k is elssorban csak a sajtjukban. Egyegy meghatroz egynisg kivlsa a munkbl akr a projekt kudarct is okozhatta, nem is szlva arrl, hogy a program megrsa s belvse utn a legkisebb mdosts is gyakorlatilag ttekinthetetlen kvetkezmnyekkel jrt. A szaporod kedveztlen tapasztalatok nyomn a programozk s tervezk kezdtek szoftverkrzisrl beszlni.

2.1.1.1 Strukturlt programozsA krzisbl val kilbalsra tett els tudatos lpsek egyike taln a legjelentsebbnek is nevezhetjk a strukturlt programozs mdszernek megfogalmazsa volt. A mdszert elmletileg megalapoz E. W. Dijkstra elmlete szerint [Dij1] elksztend programunkat elgondolhatjuk egy olyan absztrakt gpnek nevezzk A-nak , amelynek egyetlen utastsa van: "oldd meg a feladatot". Ez az utasts pontosan azt teszi, amit a programunktl elvrunk. Mivel nincs ilyen gpnk, knytelenek vagyunk egy kevsb okos absztrakt gp ltal nyjtott szolgltatsokbl ellltani a feladat megoldst. Definilunk ht egy egyszerbb B absztrakt gpet (meghatrozzuk az utastskszlett), s ezzel az utastskszlettel elksztjk az elz (A) gpet "szimull" programot, azaz a feladat megoldst. Ezutn jra feltehetjk a krdst, van-e ilyen B gpnk. Ha nincs, az eljrst meg kell ismtelni, azaz egy mg egyszerbb C absztrakt gppel s egy programmal most a B gpet kell szimullni. Az eljrst tovbb folytathatjuk, szksg szerint jabb, egyre egyszerbb D, E, F stb. gpeket definilhatunk. Akkor vagyunk kszen, ha olyan utastskszlethez jutunk, amelyik mr ltezik egy konkrt gpen, illetve egy olyan programozsi nyelvben, amelynek fordtprogramja rendelkezsnkre ll. A gondolatmenetet a 2.1. brn szemlltetjk. Lthatan absztrakt gpek hierarchijt hoztuk ltre, ahol a hierarchia szintjeit

rtegnek nevezzk. Brmely kt rteg hatrn lefel tekintve egy absztrakt gpet, felfel tekintve pedig egy erre rott programot ltunk. Minden rteg csak a kzvetlen alatta elhelyezked rteget, mint "utastskszletet" ltja, gy fggetlen annak tovbbi finomtstl, azaz az alsbb rtegek kialaktstl. A gondolatot kiegszthetjk azzal, hogy egy adott szint utastsait nem kell felttlen egyetlen absztrakt gphez tartoznak tekintennk, hanem egymssal egyttmkd gpeket is elkpzelhetnk. Ezek a gpek a tovbbiakban egymstl fggetlenl finomthatk, amennyiben a kztk lv kapcsolatot pontosan definiltuk. A strukturlt programozs gondolatmenetnek kvetkezetes alkalmazstl az albbi elnyk vrhatk: A kialakul programszerkezet ttekinthet lesz, hiszen egy-egy rteg nmagban vizsglhat, anlkl, hogy a teljes problmt s a teljes programot szem eltt kellene tartani. Az egyes finomtsi lpsekhez (azaz az egyes rtegekhez) klnll tervezi dnts tartozik. Ez egyrszt a dnts hatst csak a kvetkez rtegre korltozza, msrszt ha a dnts jl dokumentlt megknnyti azon pontok megtallst a programban, amelyeket egy-egy mdosts sorn meg kell vltoztatni. A rtegszerkezet megteremti a hordozhatsg lehetsgt. Ha brmely kt rteg hatrn sztvlasztjuk a teljes programot, akkor a fels rszt tvihetjk egy msik rendszerre, amennyiben a lefel es rszt, mint absztrakt gpet, ott valahogyan ltre tudjuk hozni.

2.1. bra Az elnyk mellett a mdszer nhny problmja is hamarosan tudatosult. Az egyik alapvet gondot az okozta, hogy a rtegek kialaktsa nmagban nem oldotta meg az ttekinthetsg problmjt, hiszen nhny lps utn a kialakul utastskszlet mr igen bonyolultt vlt. Ilyenkor a tbb egyttmkd gpre val bonts segtett, de ez egyben jabb problmkat is felvetett. Az egyttmkd gpek kapcsolatt ugyanis pontosan definilni kellett. Ezt megtehettk a kzsen hasznlt adattr (globlis vltozk) nagyon pontos az aktulis rteg absztrakcis szintjnl sokkal konkrtabb defincijval, vagy az egyes gpek msok (tbbiek) ltal hasznlhat eljrsainak pontos ugyancsak az egybknt aktulis absztrakcis szintnl lnyegesen konkrtabb specifikcijval. Ha egy adott rtegben tbb gpet definilunk, akkor egy bonyolultsgi fok fltt nehezen kvethet, hogy a fltte lv rteg mely funkcii melyik gp utastsait hasznljk. Ennek ismerete fknt a mdostsok vgrehajtshoz kellett, annak kvetshez, hogy egy mdosts a teljes program mely rszeire lesz hatssal. Ezen problmk megoldsra a strukturlt programozs egy vgletekig letiszttott elvi modelljt alaktottk ki, amely szerint valamely rteg ltal kpviselt virtulis gp

valamennyi utastst tekintsk a kvetkez, eggyel alacsonyabb szinten klnll gpnek. Ez a tiszta modell a rendszer funkciit (eljrsait) egy fa struktrba rendezi. A msik f problma a hatkonysg s a strukturltsg ellentmondsban rejlik. Egy program hatkonysgt meglehetsen szk rtelemben jellemezhetjk az ltala megoldott feladat s a felhasznlt erforrsok (trigny, processzorid stb.) viszonyval. A szigor rtegszerkezet (minden rteg csak a kzvetlenl alatta elhelyezked rteg "utastskszlett" hasznlhatja) mr nmagban is komoly hatkonysgi problmkat vet fel. Gyakran elfordul ugyanis, hogy egy magasabb szint rtegben olyan egyszer mveletekre is szksg lenne, amelyekre az alacsonyabb szintek is szmtanak, teht az csak tbb rteggel lejjebb vlik "elemi utastss". Ha ilyenkor kvetkezetesen betartjuk a strukturlt programozs elveit, akr tbb rtegen keresztl is csupn kzvett szerepet betlt, nll rdemi funkcionalitssal nem rendelkez eljrsokat cipelnk magunkkal. Ha engedmnyeket tesznk, s az alacsonyabb szintek eljrsainak hasznlatt is megengedjk, elvesztjk a "brmelyik rteghatr mentn sztszedhetjk" elv rugalmassgt s ttekinthetsgt. Tovbbi hatkonysgi problma merl fel a rtegenknti tbb gpre bonts sorn, klnsen a tiszta fa struktrj eljrsrendszer kialaktsa esetn. Programunk ugyanis ltalban egy (nha tbb, egymshoz hasonl) valsgos processzoron fog futni, ahol minden informci (adat s utasts) azonos kzegen, azonos formban troldik. A gpkzeli szinteken teht brmelyik absztrakt utasts hasonl elemekbl kell, hogy ptkezzen. gy a fa levelei fel haladva a klnbz gakon elhelyezked eljrsok egyre nagyobb valsznsggel hasznlnak kzs mveleteket. St, a trigny cskkentse rdekben trekednk is a kzs mveletek kialaktsra, hiszen ezeket elegend egyetlen pldnyban megvalstani. Ebben a pillanatban azonban a fa mr nem fa tbb, hiszen tbb gnak van kzs levele. A strukturlt programozs elvei alapjn kialakult programfejlesztsi gyakorlat megtallta az sszer

kompromisszumokat a fenti problmk kezelsre. A megolds sorn a fogalmi modell s az implementcis eszkzk kztti "rst" egyrszt fellrl lefel haladva a strukturlt programozs elvei szerint, msrszt alulrl felfel haladva, az implementcis eszkzk fl hzott "simt" rtegekkel lehetett thidalni. Ez a megkzelts mr nem zrta ki, hogy a magasabb szint rtegek kzs mveleteket hasznljanak. Mai szemlletnk igen sok elemt a strukturlt programozs gondolatkrbl rkltk, br a gykereket a problmamegolds elmletvel foglalkoz korbbi munkkban is megtalljuk (pldul [Pol1]). Az egyik legfontosabb ilyen gondolat a bonyolultsg kezelse az absztrakci s a dekompozci (rszekre bonts) alkalmazsval. Mind az absztrakci, mind a dekompozci azt a clt szolglja, hogy figyelmnket koncentrlni tudjuk, cskkentve a tervezs sorn egyidejleg fejben tartand informci mennyisgt. Az absztrakci ezt a rszletek eltakarsval, a dekompozci pedig a problma egymstl fggetlenl kezelhet, egyszerbb rszekre bontsval ri el. Figyeljk meg, hogy a strukturlt programozs mdszernek alkalmazsakor egyrszt igen magas szint absztrakcit alkalmazunk: a legmagasabb szint gp a feladat valamennyi rszlett elfedi. Ezutn fokozatosan trjuk fel a rszleteket. gy, hogy mindig csak az ppen aktulis rteg feladataival kell foglalkoznunk, vagyis azzal, hogy a kvetkez, alsbb rteg utastsaival hogyan szimulljuk az aktulis rtegnek megfelel virtulis gpet. Az absztrakcis szint cskkentsvel feltrul rszletek ttekintsnek terht teht a dekompozci egy formjval, a rtegekre bontssal enyhtjk. Ha egy-egy szintet mg gy is tl bonyolultnak tallunk, akkor egyetlen rtegen bell is alkalmazhatjuk a dekompozcit, azaz egyttmkd gpekre bonthatjuk a rteg ltal reprezentlt gpet. A dekompozcit gy is felfoghatjuk, hogy elkertjk, levlasztjuk a rendszer (feladat, problma) egy rszt, s definiljuk, mi lthat belle, hogyan viselkedik a klvilg (a

rendszer tbbi rsze) fel. Egyszersmind el is rejtjk a belsejt, hiszen azt a tovbbiakban a rendszer tbbi rsztl fggetlenl kvnjuk finomtani. Az ismertetett gondolatmenettel a strukturlt programozs mdszere fogalmazta meg elszr a szoftverfejlesztssel kapcsolatosan a fellrl lefel trtn tervezs, a lpsenknti finomts s az informcielrejts elvt. A kezdetben strukturlt programozsnak nevezett irnyzat alapjn a "nagybani programozs" jelentsgnek felismerst s eltrbe kerlst kveten kialakult a strukturlt rendszertervezsi mdszertan is (pldul [DeM78]). A strukturlt mdszertanokban a tervezi dntsek dominns fogalma a funkcionalits, illetve az azt reprezentl eljrs. Az eljrs azonban mr nem csupn a kd egyszerstsre s az ismtlsek kikszblsre szolglt, hanem a mveletek absztrakcijaknt elssorban a megrts eszkzv vlt. Jllehet a strukturlt programozs kzponti fogalma az eljrs, azt is felismertk a tervezk, hogy az adatok absztrakcijra is szksg van. Az "oldd meg a feladatot" utasts nyilvn bonyolult manipulcikat hajthat vgre egy bonyolult adattren, aminek a rszleteit ppen gy nem vizsgljuk, mint ahogyan az eljrs rszleteit sem. Dijkstra bemutatja [Dij1], hogy amikor konkrtabb tesszk az adatteret (pldul dntnk arrl, milyen tpus s szerkezet vltozkat hasznlunk valamilyen informci trolsra), akkor az kihatssal van minden olyan eljrsra, amelyik hasznlni akarja ezt az informcit. Egy konkrtabb virtulis gp utastskszlete gy is kialakulhat, hogy valamilyen adatabsztrakcit tesznk konkrtabb, s ezen konkretizls hatst rvnyestjk az adatot hasznl eljrsokban. Az eljrsok mellett, amelyek a mveletek absztrakcijnak kitn eszkzei, az adatabsztrakci jellsre is ler eszkzk bevezetse lett szksges. A programozsi mdszertannal kapcsolatos elmleti eredmnyek a nyelveken is reztettk hatsukat. A strukturlt programozs elveit az ALGOL-ra emlkeztet szigor blokkszerkezettel s lthatsgi szablyokkal tetzve leginkbb a PASCAL nyelv

testesti meg. A PASCAL program adatok s eljrsok szigor hierarchiba rendezett sszessge. A nyelv blokkos szerkezete nemcsak az szszer memriakihasznlst, hanem a tervezsi folyamatban kialakult hierarchikus modell lerst is szolglja, ezzel az informci elrejtsnek eszkze. A PASCAL nyelv az adatszerkezetek lersa terletn is jelents jdonsgokat hozott. Gazdag szerkezetpt s rugalmas tpusdefincis lehetsgeket nyjt, amivel az adatabsztrakci kifejezst is segti. Az egymsba gyazott blokkok struktrja oly mdon szablyozza a lthatsgot, hogy egy blokkbl nzve lthat valamennyi, az adott blokkban deklarlt vltoz s eljrs fejlce, valamint a blokkot kzvetlenl magban foglal kls blokkban deklarlt eljrsok fejlce (sorrend miatt esetleg forward deklarci szksges) s valamennyi, kls blokkban deklarlt vltoz. A 2.2. brnkon a B eljrst tartalmaz blokkbl krlnzve lthat a bi vltoz a B, a C s a D eljrsok fejlce, valamint az ai vltoz. A blokk rtelmezshez az is hozztartozik, hogy a blokkban deklarlt vltozk lettartama csak a blokkban lev program futsnak idejre korltozdik. Ebbl kvetkezik, hogy az eljrs befejezdse utn az eljrsban deklarlt vltozk elvesztik az rtkket. Az eljrs meghvsakor a vltozk rtke definilatlan.

2.2. bra A blokk megvalstsa megfelel a szigoran skatulyzott, strukturlt absztrakt gp modelljnek, de emellett komoly htrnyai is vannak. Annak kvetkezmnye, hogy a vltozk lettartamt az ket tartalmaz blokk futsi idejre korltozzuk az, hogy minden

olyan vltozt, amelynek rtkre a blokkba trtn ismtelt belpskor szmtunk (n. statikus vltozk), a blokkon kvl kell deklarlni. Ezltal az ilyen vltozk a kls blokk szmra lthatv vlnak. A skatulyzs tmogatja az eljrsok fastruktrban val elrendezdst. Ha ugyanazt az eljrst tbb, klnbz blokkokban deklarlt eljrsbl is hvni akarjuk azaz a fastruktrt hlss kvnjuk tenni akkor az ismertetett lthatsgi szablyok miatt az eljrst tbbszrzni kell. Ugyanazon eljrs tbb pldnyban trtn ltezse esetn a pldnyok kztti azonossg egy krltekints nlkl nem az sszes pldnyon elvgzett mdostssal knnyen megsrthet. Ez a hatkonysg romlsn tl mg inkonzisztencihoz (kvetkezetlensg) is vezet. A skatulyzott blokkstruktra megnehezti a program nllan fordthat rszekre bontst (szegmentlst), hiszen a fordtskor valamennyi kls blokkban deklarlt vltozt ismerni kell. Nagyobb programok, bonyolultabb feladatok esetn ez bizony komoly htrny. Nem vletlen, hogy a szoftverkrzis lekzdsnek egy msik jellegzetes ramlata pontosan a feladat kln kezelhet (nllan fordthat s tesztelhet) rszekre bontst, azaz a dekompozcit helyezte a kzppontba. Ez az ramlat a modulris programozs volt.

2.1.1.2. Modulris programozsA modulris programozs kzponti fogalma a modul, amely a rendszer valamilyen, a fejleszts sorn nll egysgknt kezelt, cserlhet rszt