4. Információrendszer fejlesztése

Átírás

1 4. Információrendszer fejlesztése 4.1. Bevezetés 4.2. A szoftverrendszerek fejlesztésének folyamata és eszközei 4.3. Célkitőzés, követelmények 4.4. Tervezés 4.5. Modellezési technikák 4.6. Kivitelezés és bevezetés

2 142 INFORMATIKUS SZAKMAI ISMERETEK 4.1 Bevezetés Egy szoftverrendszer fejlesztése a feladat informatikai-mőszaki tartalmát képezı tevékenységeken felül nagyon komoly támogatási, irányítási tevékenységeket is magában foglal. Azonban ebben a fejezetben a szoftverfejlesztési folyamatot csak szőkebben az informatikai-mőszaki tartalomra koncentrálva tárgyaljuk, a szoftverfejlesztés irányítási folyamataival (pl. projektmenedzselés) és támogatási folyamataival (pl. konfigurációkezelés) érdemben nem foglalkozunk. A 4.2. alfejezet a szoftverfejlesztési folyamat tevékenységeirıl az ISO szabvánnyal összhangban ad egy vázlatos áttekintést, majd bemutatja a szoftverfejlesztés technológiáját befolyásoló megközelítési módokat és módszertanokat. Az egyes módszertanoknak a fejlesztés életciklusára vonatkozó különbözı elképzeléseit külön szakasz (a szakasz) tárgyalja. A szakasz a szoftverfejlesztés eszközeit a [Sommerville-2002] forrás szerint tekinti át. A fejlesztési folyamat egyes szakaszait, valamint speciálisan az egyes szakaszokban használt eszközöket a késıbbi alfejezetek részletesebben is ismertetik. A 4.3. alfejezet a fejlesztés célja és a fejlesztés termékére vonatkozó követelmények meghatározására irányuló tevékenységekkel, valamint a kapcsolódó fogalmakkal (mint a szoftver minıségi jellemzıi), módszerekkel, eszközökkel (mint a használati eset diagramtechnika) és a követelményspecifikációt alkotó temékekkel (köztük a rendszerszervezési változatokkal) foglalkozik. A szoftvertervezési tevékenységet kiemelten kezeltük, tárgyalása két alfejezetre is kiterjed. A 4.4. alfejezet a szoftverrendszer komplexitásából eredı problémák kezelésére irányuló tervezési módszereket tekinti át, majd az éppen ilyen tekintetben legsikeresebb objektumorientált megközelítési módot ismerteti. A tervezés (és részben az elemzés) olyan sokféle modellezési technikát használ, hogy a teljes 4.5. alfejezetet ezek tárgyalása tölti ki. Az alfejezet az iparági szabványnak számító UML diagramtechnikáit mutatja be. A 4.6. alfejezet tárgya a szoftverrendszer kivitelezése és használatba vétele. Mivel a tankönyv nem feltételez programozói ismereteket, az alfejezet a kivitelezés tevékenységeinek dominánsan elméleti áttekintését nyújtja. Azonban a tevékenységi szakaszhoz tapadó fogalmak, módszerek és eszközök sokasága miatt, és a tömörítési kísérletek dacára az alfejezet így is terjedelmesre sikeredett.

3 INFORMÁCIÓRENDSZER FEJLESZTÉSE Szoftverrendszerek fejlesztésének folyamata és eszközei A fejlesztési folyamat tevékenységei A szoftverfejlesztési folyamat tevékenységeit az ISO szoftveréletciklus szabványnyal összhangban a 4.1. ábra foglalja össze. Az ábrán a tevékenységeket reprezentáló dobozok elrendezése egy V alakot formál. A V szárain lefelé, majd felfelé haladva a tevékenységek egy logikai sorrendjét kapjuk. A V alakú elrendezés azt szimbolizálja, hogy az elemzés és a tervezés felülrıl az egésztıl a részei felé halad, miközben a specifikáció egyre részletesebbé válik; a kivitelezés viszont éppen ellenkezı irányú: a legkisebb alkotóelemek megvalósításával kezdıdik, majd azokból fokozatosan építi fel az összetettebb szerkezeteket. Fejlesztési folyamat kialakítása, elemzés, tervezés Kivitelezés, tesztelés, bevezetés Projekt Folyamatkialakítás Szoftver telepítése Szoftver átvételi támogatása Rendszer Rendszerkövetelmények elemzése Rendszer nagyvonalú tervezése Rendszerintegrálás Rendszer minıségi tesztelése Szoftver Szoftverkövetelmények elemzése Szoftver nagyvonalú tervezése Szoftver részletes tervezése Szoftverintegrálás Szoftverkódolás és -tesztelés Szoftver minıségi tesztelése 4.1. ábra: A fejlesztési folyamat tevékenységei A fejlesztési folyamat tevékenységeinek a szabvány szerinti felsorolásából az is kitőnik, hogy a szabvány a fejlesztés tárgyaként megkülönböztet egy nagyobb egységet, a rendszert, és annak részeiként a szoftvereket. Ennek folyományaként létezik egy olyan fázis, amely a szoftverekbıl felépíti a rendszert, és meggyızıdik a szoftverek közötti együttmőködés helyességérıl, azaz a rendszer integrálása. A szoftver ebben a kontextusban egy (összetartozó szolgáltatások sokaságát nyújtó) komplett alkalmazást jelent.

4 144 INFORMATIKUS SZAKMAI ISMERETEK A 4.1. ábráról (a V alakot követve) leolvasható logikai sorrend tehát a következı: folyamatkialakítás; a rendszerkövetelmények elemzése; a rendszer nagyvonalú tervezése; a szoftverkövetelmények elemzése; a szoftver nagyvonalú tervezése; a szoftver részletes tervezése; a szoftver kódolása, tesztelése; a szoftver integrálása; a szoftver minıségi tesztelése; a rendszer integrálása; a rendszer minıségi tesztelése; a szoftver telepítése; a szoftver átvételi támogatása. Ebbıl a logikai sorrendbıl azonban nagyon különbözı idırendi sorrendek következnek attól függıen, hogy mit tekintünk a tevékenység tárgyának: a rendszer egészét vagy egy alrendszert (alkalmazást) vagy egy alkalmazáskomponenst. Persze a rendszerkövetelmények elemzése, a rendszer nagyvonalú tervezése, a rendszer integrálása vagy a rendszer minıségi tesztelése értelemszerően csak a rendszer egészére vonatkoztatható, de a többi tevékenység tárgya szabadabban választható. Pont ebben különböznek az egyes életciklusmodellek. A fentebb adott logikai sorrend csak akkor azonos a tevékenységek végrehajtásának idıbeli sorrendjével. ha a tevékenységeket mind a rendszer egészére értelmezzük, mégpedig úgy, hogy mindegyik tevékenység csak akkor kezdıdhet, ha a logikailag közvetlenül megelızı tevékenység a rendszer egészére nézve befejezıdött. Ilyen megoldás azonban csak a klasszikus vízesésmodellre (vízesés életciklusmodellre), illetve annak egyik változatára a V-modellre jellemzı (lásd a szakaszban). Ellenben az inkrementális életciklusmodellek esetében a fejlesztés a rendszer viszonylag független inkrementumaira (alrendszereire, moduljaira) eltérı ütemezésben történik, azaz csak az egyes inkrementumokra mondható meg határozottan, hogy a fentiek közül éppen melyik tevékenységi szakaszban járnak, a projekt egészére az ilyen állapotmeghatározás nem értelmezhetı, illetve az inkrementális fejlesztés iteratív változatában a tevékenységek a rendszer egyre fejlettebb változataira ciklikusan megismétlıdnek. Folyamatkialakítás Az ISO szabvány elismerve a fejlesztési projektek egyediségét, nem írja elı valamely életciklusmodell kötelezı használatát. Éppen a szabványban is megjelenı folyamatkialakítás tevékenység feladata, hogy az egyes konkrét projektek esetén kiválassza az adott fejlesztési feladathoz leginkább illeszkedı életciklusmodellt, és a fejlesztési tevékenységeket leképezze a kiválasztott modellre. (A leggyakoribb ilyen modelleket a szakasz tárgyalja.) Megjegyzés: Bár a szabvány az életciklusmodell választásában a semlegességét deklarálja, a fejlesztési tevékenységekre való elképzelését a V-modell néven ismert módszertantól és életciklusmodelltıl vette át. A rendszerkövetelmények elemzése E tevékenység céljai: specifikálni a rendszer egészének határaira és szolgáltatástartalmára vonatkozó követelményeket és korlátokat;

5 INFORMÁCIÓRENDSZER FEJLESZTÉSE 145 specifikálni a rendszer szolgáltatástartalom szerinti alrendszerekre (szoftverekre, alkalmazásokra) való tagolásának módjára, valamint az említett rendszerrészek közötti interfészekre vonatkozó követelményeket; felállítani az elıbbiekbıl következı rendszerszervezési változatokat. Megjegyzés: Itt és a továbbiakban specifikáció alatt valamilyen tárgyat (követelményt, korlátot, rendszert, rendszerkomponenst, ) leíró, definiáló dokumentumot értünk; a specifikálás pedig e dokumentum tartalmának elıállítását szolgáló tevékenységeket jelenti a dokumentum tartalmi szerkesztésével bezárólag. A követelményelemezés általános (nem csak a rendszer egészére, hanem annak komponens szoftvereire vonatkozó) értelmezésérıl, módszereirıl, eszközeirıl és termékeirıl, köztük a rendszerszervezési változatokról a 4.3. alfejezetben részletesebben lesz szó. A rendszer nagyvonalú tervezése A rendszer nagyvonalú tervezése a következıket jelenti: A rendszerkövetelmények alapján felállított és a menedzsment által érvényessé nyilvánított rendszerszervezési változatnak megfelelıen a rendszerarchitektúra specifikálása, a rendszer felbontása alrendszerekre (szoftverekre, alkalmazásokra); a rendszer szolgáltatásaira vonatkozó követelmények hozzárendelése a megfelelı rendszerrészekhez (szoftverekhez) és azok alapján az egyes szoftverek absztrakt specifikációjának elkészítése; az azonosított rendszerrészek (szoftverek) közötti interfészek specifikálása; az interfészek verifikálására alkalmas (rendszerintegrációs) teszt specifikálása; a rendszer egészének validálására alkalmas (minıségi) teszt specifikálása. 1. megjegyzés: A fentebb említett absztrakt specifikáció kifejezésben az absztrakt jelzı arra utal, hogy a specifikáció csak azt határozza meg, hogy milyen szolgáltatásokat nyújt az adott szoftver, de ennek megvalósítási módjával, részleteivel, technikai megoldásaival nem foglalkozik. Az absztrakt specifikáció a specifikált egység (rendszer, szoftver, modul, funkcionális egység) környezetének szól; csak azt írja le, amit az egység környezetének az egységrıl tudnia kell, ha azt használni akarja, és mindent eltakar (elrejt), ami az egység belügye. A környezetre nem tartozó részletek elrejtése a könnyen elemezhetı, változtatható, tesztelhetı szoftverek fejlesztésének fontos eszköze. 2. megjegyzés: A verifikáció (magyarul igazolás) és a validáció (magyarul érvényesítés) tevékenységek tartalmáról a szakaszban valamivel részletesebben szólunk. A tervezés általános (nem csak a rendszer nagyvonalú tervezésére vonatkozó) leírásáról, módszereirıl, eszközeirıl és termékeirıl a alfejezetekben részletesebben lesz szó. A szoftverkövetelmények elemzése E tevékenység célja a rendszer nagyvonalú tervezése során azonosított egyes szoftverekre (alkalmazásokra, alrendszerekre) vonatkozó követelmények pontosabb meghatározása. A rendszerkövetelmények elemzése során a rendszer részét képezı szoftverhez rendelt követelményeket keretként használva a szoftver szolgáltatástartalmának részleteire vonatkozó követelményeket, valamint a megvalósítás módját is befolyásoló követelményeket fogalmaznak meg; szervezési változatokat állítanak fel az adott szoftverre vonatkozóan azonosított követelmények felhasználásával.

6 146 A szoftver nagyvonalú tervezése INFORMATIKUS SZAKMAI ISMERETEK A szoftverkövetelmények alapján felállított és a menedzsment által érvényessé nyilvánított szervezési változatnak megfelelıen a szoftver felépítésének specifikálása, a szoftver magasabb szintő komponenseinek (modulok, funkcionális egységek) elhatárolása, az egyes szoftverkövetelményekért felelıs komponensek azonosítása (a komponensek absztrakt specifikációjának elkészítése); az azonosított komponensek (modulok, funkcionális egységek) közötti interfészek specifikálása; az interfészek verifikálására alkalmas (szoftverintegrációs) teszt specifikálása; a szoftver egészének validálására alkalmas (minıségi) teszt specifikálása. A szoftver részletes tervezése Egy, a megelızı fázisban azonosított modul (funkcionális egység) absztrakt specifikációja a modult még csak mint egy fekete dobozt írja le. A fekete doboz kifehérítése, azaz a modul megvalósítására vonatkozó részletek meghatározása, valamint az egységtesztek (modultesztek) specifikációjának elkészítése a részletes tervezés feladata. Fogalmilag ez a tevékenység is a tervezés része, a végrehajtóját tekintve azonban már inkább a kivitelezésé. Ugyanis a részletes terv elkészítésére általában azok a legalkalmasabbak, akik a kivitelezést (a program kódolását) is el tudják végezni, merthogy ık ismerik azt a fejlesztı környezetet (programozási eszköztárat), amellyel a terv megvalósítható. (Errıl a szakaszban még lesz szó.) A szoftver kódolása, tesztelése Ez már egyértelmően a kivitelezés részét képezı tevékenység, amely a programegységek adott programnyelven (forrásnyelven), adott programozási környezetben való lekódolását, valamint az egységtesztek (modultesztek) végrehajtásával a programegységek verifikálását (és belövését) foglalja magában. Megjegyzés: Ellentétben azzal, amit a tevékenység neve sugall, programkód írása nem csak itt történik, hanem valamilyen mértékben például a szoftver integrálása tevékenységnek is részét képezi. Sıt, a minıségi tesztek fázisában is sor kerülhet a programkód javítására. A kivitelezés és tesztelés tartalmáról, módszereirıl, eszközeirıl és termékeirıl a 4.6. alfejezetben részletesebben lesz szó. A szoftver integrálása A szoftver integrálása azt jelenti, hogy a szoftver kódolása során elıállt programegységekbıl komponensekbıl összeszerelik a szoftvert, és végrehajtják a komponensek közötti együttmőködés megfelelıségét igazoló szoftverintegrációs tesztet. A megfelelıség itt a szoftver nagyvonalú tervének való megfelelıséget jelenti. Egy bonyolultabb szoftver több szinten tagolódik komponensekre, azaz a kompozíció közvetlen összetevıi maguk is kompozíciók, azaz több önállóan fejleszthetı alacsonyabb szintő komponensbıl tevıdnek össze, és ez a megoldás az utóbbiaknál megint ismétlıdhet. Az elmondottakból következik, hogy a szoftverintegráció is többszintő lehet. Még itt is történik programkódolás, mégpedig a komponensek együttmőködését (a kompozíció szintjén) vezérlı kód megírásának erejéig.

7 A szoftver minıségi tesztelése INFORMÁCIÓRENDSZER FEJLESZTÉSE 147 A szoftver minıségi tesztelése tipikusan validációs teszt, azaz (a szoftver verifikáció célú integrációs tesztjével ellentétben nem a szoftver nagyvonalú tervének, hanem) a szerzıdéses kötelezettségeknek, a megrendelıi igényeknek való megfelelés bizonyítása képezi a feladatát. A rendszer integrálása A rendszer integrálása azt jelenti, hogy a szoftverekbıl összeszerelik a rendszert, és végrehajtják a szoftverek közötti együttmőködés megfelelıségét igazoló rendszerintegrációs tesztet. A megfelelıség itt a rendszer nagyvonalú tervének való megfelelıséget jelenti. A rendszer minıségi tesztelése A rendszer minıségi tesztelése ismét egy validációs teszt, azaz a rendszer egészére vonatkozó szerzıdéses kötelezettségeknek (megrendelıi igényeknek) való megfelelést kell bizonyítania. A szoftver telepítése A szoftver(rendszer) felhasználónál való telepítése a szőkebben vett telepítési mőveleteken, a szoftver üzemeltetési környezetének kialakításán felül magában foglalja a telepítési idıre halasztható olyan döntések meghozatalát is, amelyekkel a szoftvernek a megrendelı (felhasználó) igényei szerinti mőködése alakítható ki. A szoftver átvételi támogatása. A szoftver(rendszer)nek a megrendelı környezetében való használatba vételét, bevezetését segítı szolgáltatás, amelyet a szoftver szállítója vagy attól független szakértı (cég) nyújt a megrendelı számára. Megjegyzés: A tevékenységek itt tárgyalt rendje egy rendszer > szoftver > szoftvermodul > > alapszintő funkcionális egység hierarchiához igazodott. Azonban ez a rend csak a feldolgozást végzı programkód tervezésénél és kivitelezésénél követhetı. 1 A programkódtól nagymértékben függetlenül végezhetı adatbázistervezésre ilyen hierarchia nehezen alkalmazható. Ugyanis, mint azt az adatbázistervezésrıl szóló 2.7. alfejezetben láttuk, az adatbázisok szerkezete (az egyedtípusok táblák kapcsolatrendszere) általában nem hierarchiát, hanem hálót képez Megközelítési módok és módszertanok A szakirodalomban is gyakran elıfordul, hogy nem különböztetik meg a megközelítési módot és a módszertant; és ez bizonyos mértékig érthetı is, mert a megközelítési mód befolyással van az alkalmazható módszertanra, a módszertan pedig általában egy megközelítési mód érvényesítésének folyamatát és kereteit határozza meg. Ráadásul, ha nem egy konkrét módszertanra, hanem módszertanok egy csoportjára gondolunk, akkor például az objektumorientált megközelítés mellett jogos objektumorientált módszertanokról beszélni, ezzel az objektumorientált megközelítési módot feltételezı módszertanok csoportjára utalva. A megközelítési mód egyfajta filozófia, amely valamilyen szinten befolyással lehet akár a fejlesztési folyamat egészének technológiatartalmára, de mégsem határozza meg annak minden mozzanatát, az irányítási és a támogatási folyamatok pedig sok tekintetben közömbösek lehetnek a megközelítési mód iránt. 1 Az OO technológia esetében még a programkódra is csak korlátozásokkal igaz ez a hierarchia ( szakasz).

8 148 Szoftverfejlesztési megközelítési mód INFORMATIKUS SZAKMAI ISMERETEK A (szoftver)fejlesztési megközelítési mód egy absztrakciós szemlélet, amelybıl sajátos fogalomrendszer, eszköztár, elemzési (felbontási) és konstrukciós (építési) elvek következnek. Szoftverfejlesztési módszertan A (szoftver)fejlesztési módszertan a fejlesztési folyamat minden összetevıjét lefedı, a kidolgozók által figyelembe vett célkitőzések és feltételek mellett legjobb gyakorlatnak szánt terméksémák, folyamatsémák és szervezeti sémák, valamint a felsoroltakhoz kapcsolódó értékelési (mérési) kritériumok együttese. A termékséma meghatározza a fejlesztés során kötelezıen vagy opcionálisan elıállítandó termékek fajtáit, szerkezetét és értékelési szempontjait. A folyamatséma megadja a folyamat architektúráját, a végrehajtandó tevékenységeket, a köztük lévı függéseket; az egyes tevékenységek bemeneteit, eszközeit, elıállítandó termékeit; valamint a folyamat értékelésének szempontjait. A szervezeti séma meghatározza a szerepköröket, és azokat hozzárendelve a folyamatséma tevékenységeihez meghatározza a feladataikat, továbbá útmutatást ad a csoportmunka irányításához, az egyéni és a csoportteljesítmény értékeléséhez. A szoftverfejlesztés fıbb megközelítési módjai A következıkben röviden jellemezzük a megközelítési módok fıbb csoportjait. A kialakulásuk sorrendjében megkülönböztethetjük a moduláris, a strukturált és az objektumorientált megközelítési módokat. Moduláris megközelítés A moduláris megközelítés odáig jutott el, hogy a komplex rendszerek tervezését, fejlesztését megkönnyíti, ha azokat viszonylag független, önállóan megérthetı, fejleszthetı, tesztelhetı modulokra bontjuk. Másképpen fogalmazva: a modulok a komplex rendszerek felépítését megkönnyítı absztrakció eszközei. Ebben az esetben az absztrakció két jelentést hordoz: összetettséget és elrejtést: A modulok olyan a szakterület jelenségeihez, a rendszertıl elvárt szolgáltatásokhoz közelebb álló összetett mőveletek, amelyekbıl a rendszert könnyebb összerakni, mint a programnyelv elemi mőveleteibıl. Ugyanakkor egy-egy modult, egy-egy szőkebb szoftverépítıelemet sokkal egyszerőbb kifejleszteni, mint a rendszer egészét. A modul az elrejtés eszköze, amennyiben a külvilágnak (más moduloknak, a rendszer egészének) elegendı annyit tudni róla, hogy mit csinál (milyen adatokat vár, illetve milyen adatot szolgáltat), és csak a modulra tartozik, hogy hogyan csinálja. (Tömö-

9 INFORMÁCIÓRENDSZER FEJLESZTÉSE 149 rebben fogalmazva, a modul a környezete számára fekete doboz.) Ennek az az elınye, hogy a modul belseje (a megoldás módja) anélkül módosítható, hogy az kihatással lenne a más modulokkal való együttmőködésére. Ennek következtében várhatóan könnyebb a rendszer karbantartása: az alkalmazás hozzáigazítása a megváltozott követelményekhez. Szerencsés esetben a modul az újrafelhasználás egysége is, amennyiben többször is (az aktuálistól eltérı kombinációban is) felhasználható. A modulok léte hatékonyabb csoportmunkát tesz lehetıvé. Ha a különbözı modulok különbözı szakértelmet kívánnak, mindegyik modul a témához leginkább értı munkatársnak adható ki. A különbözı modulokat különbözı munkatársak párhuzamosan fejleszthetik, így csökkenthetı a projekt átfutási ideje. Már a tisztán moduláris szemlélet kitalálói is felismerték, hogy a modulok fenti kedvezı tulajdonságai csak akkor jelentkeznek, ha a modulok egymáshoz vékony szálon kapcsolódnak, a környezetükrıl keveset feltételeznek, viszont erıs belsı kötéssel rendelkeznek; de a moduláris megközelítés azon továbbfejlesztéseit, melyek a rendszer modulokra tagolásának optimális módját is keresték, már úgy hívják, hogy strukturált megközelítési mód, illetve objektumorientált megközelítési mód. Strukturált megközelítési mód A strukturált megközelítési mód [Yourdon-1989] onnan kapta nevét, hogy nagyrészt a strukturált programozás [Dahl-1972] elveit terjesztette ki a rendszerelemzés és -tervezés területére. Azon felül a kialakulásában szerepet játszottak az adatbázisok tervezésével, használatával kapcsolatban szerzett tapasztalatok és felmerült igények is. Ez a megközelítési mód (az adatbázisokkal kapcsolatban szerzett tapasztalatokra támaszkodva) az adattervezést (adatmodellezést) függetlenítette a feldolgozástervezéstıl, és így tudatosította, hogy a több feldolgozási egység által használt adatszerkezetet elegendı csak egyszer definiálni. A feldolgozás strukturált tervezése a fokozatos lebontás (hierarchikus lebontás / fokozatos finomítás) módszerét követi. A moduláris megközelítésnek azt az elvét, hogy a lebontással kapott modulok között csak vékony szálú kapcsolat legyen, viszont erıs belsı kötéssel rendelkezzenek, úgy teszi konkréttá, hogy a vékony szálat a gyenge külsı adatkötéssel, az erıs belsı kötést pedig az erıs belsı adatkötéssel azonosítja. Eszerint a közös adatstruktúrán végzett mőveletek kerülnek azonos modulba; a különbözı modulok által kezelt adatstruktúrák pedig minimális közös résszel rendelkeznek. Csakhogy a strukturált tervezéssel kapott feldolgozási modulok sem bizonyultak igazán újrafelhasználhatónak. Sıt ha a hierarchikus lebontással kapott különbözı ágak további lebontását (finomítását) különbözı személyek végezték, nem vették észre, hogy a különbözı ágakon azonos feldolgozási tevékenység fordul elı, amelyre célszerő lenne egyetlen közösen használt funkcionális egységet kifejleszteni. Így a rendszer terve és a megvalósított kódja gyakran redundáns lett, és ez a tény rontotta a karbantarthatóságot, megnehezítette továbbfejlesztést. Az eddig tárgyalt megközelítési módok (továbbiakban hagyományos vagy más szóval funkcióorientált megközelítési módok) közös jellemzıje, hogy az adatokra és az eljárásokra külön-külön egymástól elszigetelten alakítják ki az absztrakció (az elrejtés, az újrafelhasználás) egységeit: az absztrakt (összetett) adattípusokat és az absztrakt (összetett) mőveleteket megvalósító eljárásmodulokat. Az elkülönítve konstruált adat- és eljárásabsztrakciók

10 150 INFORMATIKUS SZAKMAI ISMERETEK azonban nem képezhetik az elrejtés és az újrafelhasználás tökéletes egységeit, mert nem alkotnak zárt, önjáró integritást, következésképpen a hagyományos megoldások absztrakt egységeinek (moduljainak) a szükségesnél többet kell feltételezni a környezetükrıl, illetve a környezetüknek a szükségesnél több ismerettel kell rendelkezni a hagyományos modulokról (ezt bıvebben kifejtve lásd a szakaszban). Objektumorientált (OO) megközelítés Az OO-megközelítés [Rumbaugh-1991] találta fel az absztrakció, az elrejtés és az újrafelhasználás ezidáig legsikeresebb alapegységét, az objektumot, illetve típusszinten az objektumok osztályát. E szemlélet szerint az objektum olyan konstrukció, amely egy egységbe zár egy adatszerkezetet (az objektum szerkezetét) és az azt kezelı (összetett) mőveleteket (az objektum viselkedését). A szerkezet és a viselkedés ilyen egysége a lehetséges legkevesebbet feltételezi a környezetérıl; következésképpen elmondható, hogy az objektum megjelenésével már nem csak az alkalmazás vagy a rendszer egésze képez integritást, hanem az egyes objektumok is. Az OO felfogás szerint az alkalmazás (a program) nem csupán utasítások sorozata, hanem együttmőködı, egymással kommunikáló objektumok társasága. Az OO megközelítés nagymértékben javította az alkalmazások elemezhetıségét, tesztelhetıségét, karbantarthatóságát, stabilitását; az egyszer kifejlesztett építıelemek újrafelhasználhatóságát, ami a fejlesztı számára többszörös megtérülést, a felhasználó számára többszörösen kipróbált megbízhatóbb szoftvert jelent. (Az OO megközelítési móddal bıvebben foglalkozik a szakasz.) Alapvetı módszertanok Az eljárásrendet és a megoldási sémákat is meghatározó fejlesztési módszertanoknak történetileg folyamatvezérelt, eseményvezérelt, adatvezérelt, felhasználóvezérelt típusai alakultak ki. Azonban a jelenben követett módszertanok a felsorolt típusok egyikébe sem sorolhatók, de olyan elemekbıl építkeznek, amelyeket a felsoroltak alakítottak ki. Egyfelıl figyelembe véve a mai szoftverfejlesztési módszertanoknak a fenti kategóriákba való besorolhatatlanságát, másfelıl azt a tényt, hogy a mai módszertanok közös sajátossága, hogy objektumorientált technológiát (megközelítési módot) feltételeznek, egy olyan tipizálásnak is van létjogosultsága, amely a módszertanokat hagyományos, másképpen funkcióorientált (ilyenek a fentiek) és objektumorientált csoportokba sorolja. Folyamatvezérelt módszertanok A folyamatvezérelt módszertanok elsıdlegesen a megvalósítandó adatfeldolgozási folyamatokra koncentráltak, és az azok által kezelt adatokból (fıleg az elıállítandó outputadatokból) vezették le a rendszer adattervét is. [Katzan-1976] A múlt idı azért jogos, mert tisztán (egyoldalúan) folyamatvezérelt módszertan csak a ködbeveszı kezdetekre, a kötegelt adatfeldolgozások korára volt jellemzı. Mivel ez a módszertan a kifejlesztendı rendszert egyoldalúan a feldolgozási célok szerint tagolta, és a fejlesztési feladatokat is ilyen tagolásban osztotta szét a különbözı fejlesztık között, azok ritkán vették észre, hogy az egyik célú feldol-

11 INFORMÁCIÓRENDSZER FEJLESZTÉSE 151 gozási folyamat sok olyan programrészt tartalmaz, illetve olyan adatszerkezetet kezel, amelyek egy másik célú folyamatnak is részét képezik. Ez az átfedı részek többszörös kifejlesztésével és többszörös teszteléssel járt együtt; általában komoly gátját jelentette a hatékony absztrakciónak, azaz olyan újrafelhasználható összetett építıelemek kifejlesztésének, amelyekbıl kisebb ráfordítással megbízhatóbb rendszereket lehet építeni. Az így fejlesztett szoftverek utóbb nehezen elemezhetınek, nehezen tesztelhetınek és nehezen változtathatónak bizonyultak. A félreértések elkerülése végett ide kívánkozik két megjegyzés: 1. A folyamatvezérelt módszertan leírásában az adatfeldolgozási folyamatokról volt szó, nem a szakterületi (üzleti) folyamatokról. Az utóbb említetteket minden módszertannak figyelembe kell venni mint olyan tényezıt, amely alapján a szoftver szolgáltatásai azonosíthatók. 2. Ma már tudjuk: ha valamit a feldolgozási folyamatokhoz kell igazítani, az nem a fejlesztés folyamata és a szoftver belsı szerkezete, hanem a felszíne, a felhasználói felülete. Eseményvezérelt módszertanok Az eseményvezérelt módszertanok [Yourdon-1989] [Ward-1985] kialakulása együtt járt a valós idejő mőszaki alkalmazások, valamint az on-line tranzakciófeldolgozások iránti igény megjelenésével. E módszertanok a rendszer strukturálásában abból indulnak ki, hogy a rendszernek milyen külsı eseményekre kell reagálni. Ez tükrözıdik a rendszer makrostruktúrájában, amennyiben egy-egy alrendszert azzal definiálnak, hogy az mely külsı események kezeléséért felel; és tükrözıdik az egyes tranzakciók feldolgozására alkalmazott felhasználói felületek programkódjában, valamint az ezek programozására kifejlesztett negyedik generációs (4GL) nyelvekben is. Az eseményvezérelt módszertanokhoz kapcsolódóan jelentek meg olyan dinamikus modellezési technikák, mint állapot(átmenet)diagram, az eseménykövetés-diagram, az eseményhatás-diagram vagy az egyedéletrajz-diagram. Más árnyalásban és némileg tompítva erre a módszertanra is elmondhatók a folyamatvezérelt módszertannál említett hátrányok. Ugyanakkor ez a módszertan sosem volt teljesen egyoldalú, mert felhasználta a korábbi kelető folyamatvezérelt módszertanok hasznosnak bizonyult elemeit, így többféle szempontból tudta vizsgálni a fejlesztés tárgyát, és ezzel javította a hatékonyabb absztrakció esélyeit. Adatvezérelt módszertanok Az adatvezérelt módszertanok megjelenése az adatbázisok használatához köthetı. A fejlesztık az adatbázisokkal összefüggésben jutottak arra a felismerésre, hogy az adatszerkezetek tervezése viszonylag független az azokat használó programok tervezésétıl, és a rendszer szilárd vázát éppen az adatbázis struktúrája (tehát egy komplex adatszerkezet) képezi. A korábbi fejlesztések tapasztalatai alapján pedig azt a következtetést is levonták, hogy akkor hatékonyabb az absztrakció, ha a funkciónak (összetett mőveletnek) az a fı meghatározója, hogy milyen adatokat kezel, és a funkció belsı struktúrájának (az algoritmusnak, azaz a vezérlési szerkezetnek) a kezelt adatszerkezethez kell igazodnia. [Jackson-1975] [Orr-1977] [Warnier-1977] Ez egyébként az adatvezérelt módszertannal együtt járó strukturált megközelítési mód (lásd itt fentebb) szemlélete is. Az adatvezérelt jelzı a hangsúlyra utal, nem az egyoldalúságra. A lényeg, hogy a módszertanban önálló és domináns vetületként jelenik meg az adatstruktúrák tervezése (adatmodellezés), ugyanakkor a feldolgozástervezésben a módszertan megırizte a folyamatorientált és eseményorientált modellezési technikákat is.

12 152 Felhasználóvezérelt módszertanok INFORMATIKUS SZAKMAI ISMERETEK A felhasználóvezérelt módszertanok [Norman-1986] lényege, hogy a fejlesztésben a felhasználó aktív részvételét támogatják, és ennek érdekében elıszeretettel alkalmazzák a felhasználó bevonását segítı prototípuskészítı, gyors alkalmazásfejlesztı (Rapid Application Development RAD) technikákat.[clegg-1994] Ez a módszertan szorosan összefügg a prototípuson alapuló életciklusmodellel, illetve az evolúciós fejlesztéssel (lásd a szakaszban). Más felosztás: Hagyományos (funkcióorientált) és objektumorientált módszertanok A korszerő módszertanok minden korábbi módszertan hasznosnak bizonyult elemeit kombinálják; integráltan alkalmaznak folyamat-, adat- és eseménymodellezési technikákat, valamint a felhasználó bevonását segítı prototípuskészítı technikákat. Következésképpen e módszertanok karakteresebben különböznek az alkalmazott megközelítési mód tekintetében, mint más jegyeikben; ilyen szempontból jogos beszélni (a lényegében strukturált megközelítésen alapuló) hagyományos (vagy funkcióorientált) módszertanokról, illetve objektumorientált módszertanokról is mint csoportszintő kategóriáról. Egy példa: A Rational Unified Process (RUP) [Jacobson-1999] módszertan leginkább OO módszertannak tekinthetı, mert lényegében abban különbözik a korábbiakban felsoroltaktól, hogy az OOmegközelítéshez illeszkedik. Egyébként a funkcionális követelmények és az ember-gép kommunikációra vonatkozó követelmények meghatározása során a folyamat-, az esemény- és a felhasználóvezérelt módszertanok mindegyikébıl vett elemeket alkalmaz. Az objektumosztályok szerkezetének meghatározása fıleg az adatvezérelt módszertanokra emlékeztet. Az osztályok viselkedésének meghatározása adat- és eseményvezérelt elemeket kombinál. Az alkalmazást felépítı objektumok együttmőködésének tervezése folyamat- és eseményvezérelt modellezési technikákat alkalmaz Életciklusmodellek Mint arról a szakaszban már volt szó, a szoftverfejlesztési folyamat kialakítása a projektek egyedisége miatt változatos életciklusmodellek szerint történhet. Az egyes módszertanok a folyamatsémájukban szintén eltérı életciklusmodelleket preferálnak, illetve az egyik legfontosabb megkülönböztetı jegyük éppen a preferált életciklusmodell. A szakirodalom sokféle életciklusmodellt tart számon. Ezek közül a legismertebbek száma is meghaladja a féltucatot. Ebben a szakaszban csak néhány alaptípus ismertetésére, így a vízesés modellre, a V-modellre, az iteratív fejlesztésre és az inkrementális modellre kerítünk sort. Vízesés modell A vízesés modellnél (4.2. ábra) a különbözı tevékenységek elméletileg szigorúan egymást követı szakaszokat idıben átlapolás nélküli fázisokat képeznek. Minden szakaszra adott, hogy abban milyen termékeket (specifikációt vagy mőködı szoftvert) kell elıállítani. A modell komoly dokumentálási ráfordításokkal jár, hiszen egy sor fázisban csak dokumentumtermékek készülnek. Érdemi visszacsatolás csak az egyes szakaszok végén szakaszzáró értékelés formájában történik. A következı fázis csak akkor kezdıdhet el, ha az elızı fázis termékeit a szakaszzáró értékelés elfogadta. Ez az értékelés egy, dokumentumtermékeken alapuló és a felhasználói oldal bevonásával végrehajtott, nagyon szigorú verifikációt feltételez. A klasszikus modellt a projekt egészére értelmezik, tehát kizártak a részenkénti inkrementumonkénti eltérı ütemezéső vízesések (vagy ha megengedik, az már egy másik iteratívinkrementális modell). A tiszta vízesés modellt normálisan legfeljebb egy-egy szakaszra kiterjedı iteráció jellemzi, amennyiben a szakaszzáró értékelés ilyen értelmő döntést hoz. (Elvileg nem lehetetlen több szakasz köztük az elemzés együttes ismételt, azaz iteratív végrehajtása, azon-

13 INFORMÁCIÓRENDSZER FEJLESZTÉSE 153 ban a gyakorlatban ezzel általában nem számolnak, mert nehezebb menedzselni; és a különben is nagy dokumentálási ráfordításokat és hosszú átfutási idıt tovább növeli; külsı vis major ok hiányában a felelıs döntéshozók alkalmatlanságának bizonyítékaként könyvelhetı el; egyébként pedig már ez is egy másik modell, amirıl késıbb lesz szó.) Elemzés Elırehaladás Visszacsatolás Tervezés Kivitelezés és egységteszt Integráció és rendszerteszt 4.2. ábra: Vízesés modell Mőködtetés és karbantartás A modell elınyei: Világos struktúra; a projekt egyszerően ütemezhetı, irányítható. A modell hátrányai: Mivel a rendszer egészére vonatkozóan a követelmények meghatározása és végleges rögzítése az egyszeri elemzési fázis feladata, ez a modell feltételezi, hogy a követelmények az elején pontosan ismertek és késıbb nem változnak. A valóságban a legtöbb rendszernél ez nem teljesül: Az elemzési szakasz végére nem lesz ismert minden követelmény, hiszen a felhasználó sem tudja pontosan, mit szeretne (majd akkor lesznek ötletei, ha már lát valamit mőködni a rendszerbıl). Az összegyőjtött követelményeket is másképpen értelmezi a felhasználó és a fejlesztı. Hosszabb projekt során a követelmények egy része már a projekt alatt elavul, helyettük újak keletkeznek. A dokumentumalapú szakaszzáró értékelések a gyakorlatban érdemi-tartalmi verifikáció helyett csak felületes formai ellenırzések, mert a felhasználói oldal nem érti a dokumentumokban elıadott modelleket, terveket, a dokumentálással túlterhelt fejlesztıi oldal pedig éppen az ellenırzési ráfordítások megtakarításával próbál a projekttervben elıírt határidın és költségkereten belül maradni. Így mind a követelmények, mind a tervek nem-megfelelıségét a felhasználó csak a mőködı szoftver bemutatásakor veszi észre; illetve a fejlesztı az idıben fel nem fedezett hibák miatti problémák tömegével a finisben, az integráció során szembesül. Mivel a modell komoly dokumentálási ráfordításokat feltételez, és kizárja az átfutási idıt csökkentı fázisátlapolásokat, általában hosszú fejlesztési idıvel kell számolni, és csak a projekt végén jelenik meg használható termék. A hosszú fejlesztési idı azon túl, hogy növeli a követelmények megváltozásának esélyét, egyéb kellemetlenségekkel is jár: cserélıdnek a fejlesztıi és felhasználói munkatár-

14 154 INFORMATIKUS SZAKMAI ISMERETEK sak. Az új projekttagok mindaddig improduktív tevékenységet végeznek, amíg nem kerülnek képbe. Közben megváltozik a technológia, az új technológia más szakértelmet igényel. Bekövetkezik a szállító rémálma: lecserélıdik a megrendelı menedzsmentje, az új menedzsment a projekt indítását az elızı menedzsment kifejezetten hibás (sıt bőnös) döntései között könyveli el. V-modell A V-modell a vízesés modell speciális változatának tekinthetı (4.3. ábra). A V-modell elnevezés egyébként nemcsak életciklusmodellt, hanem egy teljes módszertant jelöl [Bröhl- 1993], amelynek több elemét az ISO szabvány is átvette (lásd a szakaszban). A V-modell életciklus elképzelése nemcsak az egyes fázisok idıbeli sorrendjérıl szól, hanem arról is, hogy az egyes fázisokban mely korábbi fázisokban készült specifikációkat kell felhasználni; illetve az adott fázis tevékenységét és termékét mely korábbi fázisban specifikált követelmények, illetve tervek alapján kell ellenırizni (verifikálni). Azon felül, hogy ez a modell nagyon jó támpontokat ad a verifikáció végrehajtásához, egyéb elınyeirıl és hátrányairól hasonlók mondhatók el, mint a vízesés modellnél. Rendszer elemzése, nagyvonalú tervezése Rendszer integrálása, minıségi tesztelése Szoftver elemzése Szoftver minıségi tesztelése Szoftver nagyvonalú tervezése Szoftver integrálása Szoftver részletes tervezése Szoftver kódolása, tesztelése Idıbeli elırehaladás Megfelelés terveknek, követelményeknek 4.3. ábra: V-modell Iteratív fejlesztés Az iteratív fejlesztés tulajdonképpen nem önálló modell, hanem egy olyan, a célt fokozatosan közelítı megoldás, amelyet több életciklusmodell és módszertan is felhasznál, illetve amelyet olyan klasszikus modellekkel kombinálva, mint pl. a vízesés modell, új életciklusmodellt kapunk. Az iteráció itt azonos tevékenység vagy tevékenységsor ismételt végrehajtását jelenti, minden ismétléssel újabb minıséget adva az elızı végrehajtás termékéhez. Az itt értelmezett iteratív fejlesztés ezen felül azt is feltételezi, hogy az iterációkat határozott célkitőzés, átfogó projektterv (az inkrementális változatában átfogó és nagyvonalú termékterv, valamint az

15 INFORMÁCIÓRENDSZER FEJLESZTÉSE 155 inkrementumok közötti interfészek tervezése) elızi meg. (Ez a feltételezés különbözteti meg az iteratív fejlesztést a kötetlenebb evolúciós fejlesztéstıl.) Az iterációs fejlesztésnek (itt az evolúciós fejlesztést nem hozzászámítva) lényegében két változata létezik: az inkrementális modell (lásd alább), valamint a spirálmodell (ezt csak megemlítjük). Az iteratív fejlesztés motivációi: kezelni azt a körülményt, hogy kezdetben nem lehet ismert minden követelmény; számolni az ismert követelmények megváltozásával; a különlegesen nagy kockázatú projekteket is kezelhetıvé tenni (a spirálmodellnél ez a domináns motívum); minél korábban megszülessen egy mőködı, felhasználásra átadott verzió (ez csak az inkrementális modell sajátja); az elızı verziók fejlesztése, illetve használata során szerzett tapasztalatok felhasználásával a módszerek, a termékminıség folyamatos javítása (inkrementális modell); megbízhatóbb termék (ez inkrementális modell esetén attól remélhetı, hogy az egyre késıbbi verziók egyre nagyobb részben tartalmaznak többszörösen üzemi környezetben is kipróbált komponenseket; a spirálmodell esetén pedig a kifejezetten minıségi kockázatok csökkentését célzó, a megoldásokat is tesztelı prototípusoktól). Követelmények meghatározása Követelmények inkrementumokhoz rendelése Inkrementum fejlesztése Inkrementum validálása Inkrementum integrálása Rendszer validálása Teljes rendszer nem teljes rendszer 4.4. ábra: Iteratív és inkrementális modell [Sommerville-2002] Inkrementális modell Az inkrementális modell [Mills-1980] [Sommerville-2002] lényege a rendszer vagy a szoftver elkülönülten fejleszthetı részekre inkrementumokra (hagyományosan alrendszerekre, viszonylag független alkalmazásokra) bontása, amelyek fejlesztése különbözı ütemezésben hajtható végre (a 4.5. ábra az inkrementális modellnek ezt a szerkezetét hangsúlyozza). Elsıként olyan inkrementum készül el, amely magában is használatba vehetı (nem igényli más olyan komponensek támogatását, amelyek csak egy késıbbi inkrementumban készülnek el), és lehetıleg a felhasználók számára legfontosabb szolgáltatásokat nyújtja. A 4.5. ábra azt is mutatja, hogy ha az erıforrások rendelkezésre állnak hozzá, akkor a különbözı inkremen-

16 156 INFORMATIKUS SZAKMAI ISMERETEK tumok fejlesztése egymással átlapolva is történhet. A kivitelezés is tágabban értelmezendı; az inkrementum szőken vett kivitelezésén túl magában foglalja az adott inkrementum validálását, a korábbi inkrementumokból álló rendszerhez integrálását, valamint a rendszer validálását is. 1.inkrementum Elemzés Tervezés 2.inkrementum Elemzés Elemzı team Tervezı team Kivitelezı és integrációs team 3.inkrementum Kivitelezés Tervezés Elemzés Kivitelezés Tervezés Kivitelezés Mőködés 4.5. ábra: Inkrementális modell átlapolással A 4.5. ábra szerinti (a követelmények elızetes összegzése nélküli) tisztán inkrementális modell esetén az integráció komoly gondokkal járhat. Ezért az inkrementális modell a gyakorlatban szükségképpen olyan iteratív fejlesztés, amelynél az iterációkat megelızi a rendszerkövetelmények meghatározása és inkrementumokhoz rendelése (4.4. ábra). (A Követelmények inkrementumokhoz rendelése dobozt a nevéhez képest célszerő tágabban értelmezni, beleértve egy átfogó nagyvonalú rendszertervet is.) Ennél a modellnél minden iteráció alkalmával mőködı verzió készül, amely eljut a felhasználóhoz (némely verziók csak validáló tesztelésre, kitüntetett verziók pedig üzemszerő felhasználásra is). A modell akkor tudja kezelni a követelmények változásait, ha a 4.4. ábra Inkrementum fejlesztése dobozába kezdeti tevékenységként beleértjük az aktuális és az azt követı inkrementumokra vonatkozó követelmények aktualizálását is. A modell elınyei: Általában teljesülnek azok az elvárások, amelyeket az iteratív fejlesztéssel szemben szoktak támasztani: kezelni tudja az egyes követelmények és a követelményhalmaz változásait; korán megszületik egy mőködı, felhasználásra átadott verzió, ez a tény a projekt megítélése, a megrendelı elégedettsége (és a további iterációk iránti elkötelezıdése) szempontjából különösen fontos lehet;

17 INFORMÁCIÓRENDSZER FEJLESZTÉSE 157 az elızı verziók fejlesztése, illetve használata során szerzett tapasztalatok felhasználásával a módszerek folyamatosan javulnak, a követelmények finomodnak, a kockázatok viszonylag meredeken csökkennek; a késıbbi verziók egyre megbízhatóbbak, mert egyre nagyobb részben tartalmaznak többszörösen kipróbált komponenseket (de az elıbb említett tapasztalatokból kifolyólag is). Mindezeken felül tisztán az inkrementális szerkezetbıl is adódnak elınyök: A teljes rendszer helyett egy inkrementumot fejlesztı projekt egyidejőleg lényegesen kevesebb erıforrást foglal le, és jelentısen szerényebb költségkerettel megoldható; tehát akkor is elindítható, ha a szervezet szőkösebb emberi és pénzügyi erıforrásokkal rendelkezik. Elegendı erıforrások birtokában pedig az inkrementumok fejlesztésének átlapolásával a teljes rendszer fejlesztésének idıtartama is lecsökkenthetı. A modell hátrányai: Szőkös erıforrások esetén a teljes rendszer ennél a modellnél is lassan készül el. A soklépéses folyamat és a párhuzamos tevékenységek irányítása nehéz feladat. A rendszer inkrementumokra bontása és az inkrementumok közötti interfészek meghatározása alapos megfontolásokat kíván. Ha ez ügyben rossz döntés születik, az többszörösére növelheti az iterációnként ismétlıdı integráció amúgy is komoly ráfordításait. További életciklusmodellek A vízesés modellnél említett hátrányok orvoslására egy sor életciklusmodell született. Közülük több az iteratív fejlesztés valamilyen változata (mint a Boehm-féle spirálmodell) [Boehm-1988]. Mások a kombinált iteratív-inkrementális modell változatai (mint például a Rational Unified Process RUP modell). A felhasználó és a fejlesztı közötti jobb megértést, a követelmények pontosabb meghatározását, valamint a fejlesztés gyorsítását szolgáló modellek az egyszerő prototípusmodell és annak az evolúciós fejlesztés nevő változata. A követelmények megváltozásával szemben különösen toleráns az ún. agilis módszertanok csoportjába tartozó extrém programozás modellje. A ráfordítások megvásárolható kész komponensek beépítésével való csökkentése motiválja a komponens alapú fejlesztés modelljét. A megbízhatóság-kritikus rendszerek fejlesztése esetén (amelyeknél a hibák katasztrofális következménnyel járhatnak), kitüntetett cél a kockázatok módszeres csökkentése. Erre legjobb példa a Boehm-féle spirálmodell A szoftverfejlesztés eszközei Ebben a szakaszban fıleg a [Sommerville-2002] forrásra támaszkodva tekintjük át a szoftverfejlesztés eszköztárát alkotó eszközkategóriákat. A 4.6. összefoglaló ábra is a [Sommerville-2002] ábrájának (96. oldal) némi módosításával készült. Megjegyzés: [Sommerville-2002]-höz képest két módosítással éltünk: (1) [Sommerville-2002] a CASEtechnológiák osztályozásáról beszélt, mi pedig a szoftverfejlesztés eszköztáráról. (2) [Sommerville-2002] az elemzés és tervezés kategórián belül egyeszközös eszközkészletet és többeszközös eszközkészletet különböztetett meg, ezeket nem csak azért nem vettük át, mert az egyeszközös eszközkészletet magában is ellentmondásos kifejezés, hanem azért is, mert a lényeget sokkal inkább megragadó osztályozásnak érezzük az elemzı és tervezı eszközkészleteket aszerint megkülönböztetni, hogy csak egy modellezési technikát (lásd a 4.5. alfejezetben) vagy összehangoltan több modellezési technikát támogatnak.

18 158 INFORMATIKUS SZAKMAI ISMERETEK Szoftverfejlesztés eszköztára Eszközök Eszközkészletek Környezetek Szerkesztık Fordítók Állományösszehasonlítók Integrált környezetek Folyamatközpontú környezetek Elemzés és tervezés Programozás Tesztelés Egy modellezési technika Több modellezési technika Általános célú eszközkészlet Nyelvspecifikus eszközkészlet 4.6. ábra: A szoftverfejlesztés eszköztára ([Sommerville-2002] nyomán) Az eszközök többféle nézıpontból osztályozhatók, és a 4.6. ábrán is egyszerre több nézıpont érvényesül: Funkcionális nézıpontból az eszközök aszerint különböztethetık meg, hogy milyen technikai mőveletet (pl. szövegszerkesztést, diagramszerkesztést, verziókezelést, programfordítást, ) támogatnak. A 4.6. ábra ilyen elv szerint különíti el az egyszerőbb eszközökön belül a szerkesztıket, a fordítókat és az állományösszehasonlítókat, valamint a programozás eszközkészletein belül az általános célúakat és a nyelvspecifikusakat. Folyamat nézıpontból az eszközök aszerint különböztethetık meg, hogy fejlesztési folyamat mely tevékenységét (szakaszát) támogatják. A 4.6. ábrán ennek felel meg a fejlesztés eszközkészleteinek aszerinti osztályozása, hogy azok az elemzést és a tervezést vagy a programozást vagy a tesztelést segítik-e. Integrációs nézıpontból az eszközök az integráció foka szerinti osztályozhatók, és így megkülönböztethetık az egyszerő (egyfunkciós) eszközök, a fejlesztési folyamat egy tevékenységének (szakaszának) több funkcióját támogató eszköztárak, a folyamat több szakaszát összehangoltan támogató integrált környezetek, a folyamat teljes hosszát összehangoltan támogató környezetek. A 4.6. ábrán ennek felel meg a legfelsı szinten az eszközök, eszközkészletek, integrált környezetek és folyamatközpontú környezetek kategórizálás; valamint legalul az elemzés és a tervezés eszköztárának aszerinti osztályozása, hogy egy vagy több modellezési technikát támogatnak-e. Az eszközkészleteknek a folyamat nézıpont szerinti konkrétabb változataival részletesebben a alfejezetekben ismerkedhet meg az olvasó. E szakasz további részében csak a

19 INFORMÁCIÓRENDSZER FEJLESZTÉSE 159 CASE eszköz (CASE = Computer Aided Software Engineering magyarul: számítógéppel támogatott szoftvertervezés) fogalmát tisztázzuk. [Sommerville-2002] a CASE eszköz fogalmába a számítógép által adott összes fejlesztı eszközt beleérti az egyszerőektıl kezdve a legmagasabb fokon integráltakig. Ezzel szemben mi a CASE-t szőkebben értelmezzük, mégpedig azzal összhangban, hogy a gyakorlatban CASE néven olyan szoftvereket forgalmaznak, amelyek által kínált eszközkészlet meghaladja az integráltság egy bizonyos fokát. Így a továbbiakban CASE eszköz (szoftver) alatt olyan eszköztárat értünk, amely a szoftverfejlesztés legalább egy szakaszának (pl. a tervezésnek vagy a kivitelezésnek) vagy legalább egy vetületének (pl. az adatvetületnek) minden funkcióját (technikai mőveletét) összehangoltan képes támogatni. A szakirodalom megkülönböztet upper CASE és lower CASE eszközöket: az elıbbieknél a támogatás súlypontja a (követelmény)elemzési és tervezési szakaszokra esik, az utóbbiaknál viszont a kivitelezésre és a tesztelésre. Egy tipikus upper CASE eszköz jellemzıi: Nélküle (papíron) nem oldható meg redundanciamentes (minden tényt, döntést, definíciót aktuális verzióban csak egyszer tartalmazó) terv készítése. Automatikusan kizár bizonyos tervezési-szintaktikai hibákat. Automatizmusokat tartalmaz a modellek ellentmondásmentességének és hivatkozási teljességének ellenırzésére. Iparági szabványnak számító technikák használatára és technológia követésére kényszeríti a munkatársakat: a team minden tagja azonos (modellezési) nyelvet beszél, azonos technológiai szabályokat követ. Támogatja a csoportmunkát. (A fejlesztı csapat minden tagja a modellek, tervek mindenkori legfrissebb állapotát látja. Azok a tevékenységek, amelyek nélküle csak egymás után végezhetık, egy CASE eszközt használva párhuzamosíthatók, és így a fejlesztési projekt átfutási ideje csökkenthetı.) Együtt tárolja a követelményeket és a tervtermékeket, így benne közvetlen hivatkozás hozható létre a követelmények és az ıket teljesítı tervtermékek között. Bármikor kimutatás készíthetı vele az érvényes követelményekrıl, a már teljesített, illetve a még nem teljesített követelményekrıl, az adott követelmény teljesítéséért felelıs tervkomponensekrıl vagy programegységekrıl. Támogatja a követelmények és tervek változáskövetését, konfigurációkezelését. Támogatja az adatbáziskód (SQL) generálását 100%-ban és a programkód generálását (részben), valamint arra szolgáló módszertani szabályok betartása esetén segíti a terv és a megvalósítás szinkronban tartását is. Támogatja a reengineeringet (Pl. adott, mőködı adatbázis adatszótára vagy SQL script alapján automatikusan adatmodellt rajzol, vagy objektumorientált programkód alapján osztálydiagramokat rajzol.) Adott sablon szerint automatikusan nyomtatott dokumentációt generál (Az érvényes és teljes dokumentáció az, amit a CASE elektronikusan tárol. Ebbıl bármikor olyan nyomtatott dokumentáció generálható, amely éppen a megcélzott olvasóközönség nézetének megfelelı információkat tartalmazza.) A lower CASE eszközök legfıbb célja a programkódolási és tesztelési ráfordítások csökkentése a szoftvertermék megbízhatóságának egyidejő javítása mellett. Ilyen eszközök szolgáltatásait részletesebben a szakasz tárgyalja.

20 160 INFORMATIKUS SZAKMAI ISMERETEK Ellenırzı kérdések a 4.2. alfejezethez 1. Az ISO szabvány szerint milyen tevékenységekbıl áll a szoftverfejlesztési folyamat? 2. Mit jelent a szoftver absztrakt specifikációja? 3. Mit jelent a szoftverfejlesztés megközelítési módja? 4. Mit jelent a szoftverfejlesztési módszertan? 5. A szoftverfejlesztés milyen fıbb megközelítési módjai különböztethetık meg? 6. Fejtse ki, mit jelent az az állítás, hogy modul a komplex rendszerek felépítését megkönnyítı absztrakció eszköze! 7. A szoftver milyen minıségi jellemzıit javította jelentıs mértékben az OO megközelítési mód? 8. Történetileg milyen szoftverfejlesztési módszertanok alakultak ki? 9. A napjaink szoftverfejlesztési módszertanai milyen közös jellemzıkkel bírnak? 10. Ismertesse a fejlesztési folyamat fıbb életciklusmodellejeit! (Jellemzık, elınyök, hátrányok.) 11. Milyen célkitőzések motiválják az iteratív fejlesztést? 12. Osztályozza (kategorizálja) a szoftverfejlesztés eszköztárának összetevıit! (Szempontok: funkció, a folyamat támogatott tevékenysége, az integráció foka.) 13. Milyen képességek jellemzik az upper CASE eszközöket?

21 INFORMÁCIÓRENDSZER FEJLESZTÉSE Célkitőzés, követelmények A szoftverfejlesztési projekt céljának meghatározása Egy szoftverfejlesztési (akár egyedi fejlesztési, akár beszerzési) projekt indítását többféle cél motiválhatja: egy új rendszerrel a szervezet egyes tevékenységeinek automatizálása és azáltal a költségek csökkentése, a teljesítmény és az árbevétel növelése; a meglévı megbízhatatlan vagy elavult rendszer lecserélése, ezáltal az adatminıség és a szolgáltatások színvonalának javítása; a meglévı rendszer szolgáltatástartalmának bıvítése vagy hozzáigazítása a technológiai, üzleti és jogi környezet változásaihoz; a meglévı rendszerek közötti együttmőködés kialakítása, javítása; kapcsolódás más szervezetek rendszereihez, a világhálóhoz. Egy konkrét fejlesztési projekt egyedi céljának kijelölése általában több körben iteratívan történik. A kezdetben nagyratörı célokat egy megvalósíthatósági tanulmány a kor technikai színvonalán lehetséges megoldásokhoz, valamint a szervezet pénzügyi korlátaihoz, illetve a projekt idıbeli és erıforrásbeli korlátaihoz igazítja. Az elmondottakból az is következik, hogy a célkitőzés nem csak pozitív (mit kell tudni a projekt termékének) állításokat, hanem negatív (mi nem része a projektnek) állításokat is tartalmazhat. A finanszírozó szervezet mendzsmentje által elfogadott célokat a projekt alapító okirata legfeljebb néhány oldalas terjedelemben és a menedzsment nézıpontjának megfelelı szintő pontokba összefoglalva rögzíti. Ha a projekt megrendelı-szállító együttmőködésben hajtódik végre, akkor a projektcélokat a szerzıdés (is vagy annak mőszaki melléklete) tartalmazza. Azonban a célkitőzés a projektet, illetve annak termékét csak a kereteiben határozza meg. A termék szolgáltatástartalmának, valamint a megvalósítás módjának pontosabb meghatározása az említett kereteket kitöltı, a felhasználók és a fejlesztık egyetértésével kialakított követelmények (és korlátok) formájában történik. E követelmények azonosítása már az elindított fejlesztési projekt feladata (lásd a szakaszban). A fejlesztési projekt céljainak és követelményeinek szakszerőbb meghatározását segíti elı, ha általában is tisztában vagyunk a szoftverek minıségének összetevıivel. Ezekrıl szól a következı szakasz Szoftverek minıségi jellemzıi (MSZ ISO/IEC 9126) Minıségi követelményeket megfogalmazni legalább két okból szükséges: A követelmények a fejlesztık számára egy elérendı célt definiálnak, amelyhez igazítani kell a rendszer fejlesztésének folyamatát, módszereit; az elemzési, tervezési, kivitelezési tevékenységeket; a fejlesztés dokumentumait; végül a mőködı szoftver képességeit. Az ISO 9126 szabvány elsısorban ilyen szempontból tárgyalja a minıségi jellemzıket. A követelmények a megrendelı (felhasználó) oldalán támpontot adnak a fejlesztés eredményének értékelésére vagy a beszerezhetı rendszerek, alkalmazások értékelésére, kiválasztására. Ezt a szempontot inkább az ISO/IEC szabvány követi, de annak a tárgyalásától itt eltekintünk.

22 162 INFORMATIKUS SZAKMAI ISMERETEK A szakaszok következı része a szoftverek minıségi jellemzıinek osztályozó kategóriáit veszi számba azzal a céllal, hogy keretet adjon konkrét fejlesztések vagy beszerzések speciális minıségi követelményeinek kialakításához. Ilyen fıbb kategóriák az alábbiak: funkcionalitás, megbízhatóság, használhatóság, hatékonyság, karbantarthatóság, hordozhatóság. Ezeket a kategóriákat a szoftvereknek az ISO 9126 szabványban adott minıségi jellemzıi közül vettük, és tekinthetık olyan szempontoknak, amelyeket mindig mérlegelni kell, hogy az adott termék esetében milyen mértékben merülnek fel. A mérlegelés a követelmények és a tervezett megoldások vizsgálatára alapozható. A minıségi jellemzık felsorolása az MSZ ISO/IEC 9126:2000 szabvány A mellékletének ajánlásához igazodik. A nemzetközi szabvány eredeti változata az ISO/IEC 9126:1991 volt, az itt hivatkozott változat pedig ennek 2000-ben megjelent magyar fordítása. A nemzetközi szabványnak utóbb újabb változatai születtek. A 2000-es magyar változat ezeket nem tartalmazza (sıt még az 1995., és évi kiegészítéseket sem), és ebben a fejezetben mi sem használjuk fel. (Az itt nem tárgyalt kiegészítések lényegét minıségi mérıszámok kidolgozása és egy minıségmodell definiálása képezik. A minıségmodell külsı, belsı és használatban megmutatkozó minıségkategóriákat vezet be, és a késıbbi változatok a minıségi mérıszámokat már ezen kategóriák szerint csoportosítva értelmezik.) Megjegyzés: Nem zárható ki egy olyan szélsıségesen speciális projekt sem, amelyre valamelyik minıségi cél nem értelmezhetı. Ráadásul egy idıbeli- és pénzügyi keretek által korlátozott konkrét projekt esetében a különbözı minıségi célok egymással versenyeznek, azaz némely célok csak mások rovására teljesíthetık. (Adott projekt esetében az értelmezhetı minıségi célokat és azok prioritásait a projektalapító dokumentum rögzíti.) Funkcionalitás A funkcionalitás a szoftver által nyújtott szolgáltatásokat, illetve mint minıségi jellemzı a szolgáltatások iránt kifejezett vagy elvárt igények teljesítésének mértékét jelenti. Ebbe a kategóriába dominánsan szerzıdésenként / projektenként / termékenként különbözı ismérvek (követelmények, terméktervben rögzített megoldási elıírások) tartoznak, amelyeket ugyancsak egyedileg specifikált funkcionális tesztekkel lehet igazolni / érvényesíteni. Másképpen szólva: amikor a szoftver szolgáltatástartalmára vonatkozó követelményeket azonosítjuk, akkor éppen a szoftver elvárt funkcionalitását rögzítjük, illetve amikor a különbözı szintő tesztekkel e követelmények teljesülését igazoljuk, akkor éppen a szoftver funkcionalitás minıségét vizsgáljuk. A funkcionalitás összetevıi: Alkalmasság: a szoftver a kitőzött konkrét feladatokra használható funkciókat tartalmaz, e funkciókkal megvalósított szolgáltatásokat a szükséges kapacitással (pl. adatbáziskapacitás) nyújtja. Pontosság; az alkalmasságnak jellemzıen számszerő kimenetek elıállítására szolgáló szoftverre való speciális megfogalmazása. Együttmőködés: illeszkedési kompatibilitás, funkcionális illeszkedési szabványoknak megfelelés; más rendszerekkel, alkalmazásokkal való együttmőködést lehetıvé tevı szabványos interfészekkel való rendelkezés. (Itt kifejezetten az azonos szintő más alkalmazásokkal való együttmőködésre kell gondolni, az alacsonyabb pl. operációs rendszer, hardver rétegekkel való együttmőködés képessége már nem ide, hanem a hordozhatóság kategóriájába tartozik. Lásd késıbb a Hordozhatóság cím alatt!)

23 INFORMÁCIÓRENDSZER FEJLESZTÉSE 163 Alkalmazhatóság: az alkalmazással kapcsolatos szabványok, szabályok, törvényi szabályozások, elıírások betartása. Biztonság: szolgáltatásokhoz, adatokhoz jogosulatlan hozzáférés megakadályozása, felhasználói tevékenységek nyilvántartása. (Az informatikai biztonsági követelményekrıl részletesebben például az MSZ ISO/IEC szabványból tájékozódhat az olvasó.) 1. megjegyzés: A funkcionalitás imént felsorolt alkategóriái nem teljesen idegenek egymástól. Bizonyos esetekben egymást feltételezik vagy egymásból következnek. Például az együttmőködési képesség esetleg az alkalmazhatóságnak (valamely szakterületi interoperabilitási szabvány betartásának) a következménye. 2. megjegyzés: Az alkalmasságba a szolgáltatás elvárt kapacitással nyújtása csak a következı finomításokkal érthetı bele: nem kérhetı számon a szoftveren olyan kapacitástényezı, amely alapvetıen nem szoftver-, hanem hardverképességen alapul (pl. az adattároló egységen tárolható adatmennyiség); az viszont szoftverfüggı kapacitástényezınek számít, hogy pl. adott típusú egyedek azonosító adata legfeljebb hány egyed azonosítására alkalmas. Megbízhatóság A megbízhatóság a szoftver olyan tulajdonságainak összessége, amelyek hatással vannak arra, hogy a szoftver a szolgáltatásait adott feltételek között és adott idıszakon belül (tartósan) az elvárt teljesítményszinten képes nyújtani. A megbízhatóság némi átfedést mutat az alkalmasság kategóriával, és ez különösen igaz, ha az alkalmasságba a szolgáltatás adott teljesítményszinten való nyújtását is beleértjük. A különbség abban áll, hogy a megbízhatóság a teljesítményszint adott feltételek mellett tartósan adott idıtartamig folyamatosan való fennállását jelenti. Megjegyzés: A megbízhatóságnak ez az értelmezése a mőszaki életbıl lett átvéve, ahol ez a minıség hagyományosan szorosan összefügg a mőszaki berendezések, gépek alkatrészeinek kopásával. A szoftverek esetében viszont kopásról nem beszélhetünk, következésképpen a szoftver tartós rendelkezésre állása inkább azon múlik, hogy a szoftver használata során milyen gyakran fordul elı olyan szituáció, amellyel a szoftver tervezıi, kivitelezıi vagy tesztelıi nem számoltak, és ezért a szoftver hibás mőködését okozza. Tehát a szoftver megbízhatósága alapvetıen a tervezés és a megvalósítás átgondoltságával, a tesztelés alaposságával, készen adott, kitesztelt komponensek (az újrafelhasználás) arányának növelésével összefüggı minıség. A megbízhatóság összetevıi: Kiforrottság (érettség): a szoftver azon tulajdonságai, amelyek hatással vannak a szoftverhiba miatti meghibásodás gyakoriságára. Hibatőrés: a szoftver azon tulajdonságai, amelyek hatással vannak a teljesítmény egy meghatározott szintjének fenntarthatóságára szoftverhibák bekövetkezésének vagy a használati felületére megadott szabályok megsértésének ellenére is. Helyreállíthatóság: a szoftver azon tulajdonságai, amelyek hatással vannak arra a képességére, hogy meghibásodás esetén a teljesítménye az eredeti szintre visszaállítható, a közvetlenül érintett adatok visszanyerhetık, továbbá arra, hogy mennyi idı és ráfordítás szükséges mindehhez.

24 164 INFORMATIKUS SZAKMAI ISMERETEK Tehát a kiforrottság a szoftverhibák elıfordulási gyakoriságával mérhetı (persze úgy, hogy kisebb gyakoriság jelent kiforrottabb szoftvert). A hibatőrés pedig azzal van fordított viszonyban, hogy a hibák gyakorisága vagy súlyossága mennyire akadályozza a szoftver rendeltetésszerő használatát, és ezzel mennyire csökkenti a szoftver teljesítményét. A hibatőrés fogalmába tartozik az is, hogy a felhasználói felület mennyire van felkészítve a felhasználói hibák vagy illegális akciók kizárására; vagy az adatbázis-definíció tartalmazza-e a hibás adatbevitelt megakadályozó (hivatkozásintegritási és adatintegritási) szabályokat. A helyreállításnak lehetnek alkalmazástól független (pl. operációsrendszer-szintő) megoldásai is, azonban az itt tárgyalt helyreállíthatóság alatt kifejezetten az alkalmazásba beépített megoldások meglétét és milyenségét kell érteni. Ez különösen lényeges minıségi tényezı akkor, ha a helyreállítás olyan alkalmazásspecifikus képességeket igényel, amilyenek az alkalmazásfüggetlen megoldásoktól nem várhatók el. A helyreállíthatóság komoly problémát jelentett az adatbázishasználat általános elterjedése elıtt, de ma már az üzleti alkalmazások általánosan adatbázist használnak, és a helyreállíthatóságot az adatbáziskezelı tranzakciókezelési, naplózási, mentési, helyreállítási képességeire építhetik rá. Kiegészítı megoldásokra csak akkor van szükség, ha az adott alkalmazás esetében a helyreállításnak részlegesen vagy adatfajtánként differenciáltan is mőködnie kell. Használhatóság A használhatóság a szoftver olyan tulajdonságainak összessége, amelyek hatással vannak a használathoz szükséges ráfordításra a felhasználók közvetlenül vagy közvetetten meghatározható körében. Megjegyzés: Az ISO 9126 szabvány (eredeti változata) nem ergonómiai nézıpontból értelmezte a használhatóságot, ezért nem tartoznak bele olyan összetevık, mint a felhasználó munkájának hatékonysága és eredményessége. A használhatóság összetevıi: Érthetıség: a szoftver azon tulajdonságai, amelyek hatással vannak arra, hogy a felhasználótól mennyi ráfordítást igényel a mőködési elvek és ezek alkalmazhatóságának megismerése, azaz a szakterületi alkalmazás lehetıségeinek megismerése. Megtanulhatóság: a szoftver azon tulajdonságai, amelyek hatással vannak arra, hogy a felhasználótól mennyi ráfordítást igényel az alkalmazás megtanulása, azaz a szoftver kezelésének, a felhasználói felületnek, a megengedett bemeneteknek, a lehetséges kimeneteknek a megismerése. Üzemeltethetıség: a szoftver azon tulajdonságai, amelyek hatással vannak arra, hogy a felhasználótól mennyi ráfordítást igényel az üzemeltetés és a kezelés. A használhatóság összetevıit és még más késıbbi minıségi tényezıket is az ISO 9126 szabvány valamilyen ráfordítások mértékével definiálja. Ez nem jelenti azt, hogy az adott minıség fokát ténylegesen a ráfordítások (utólagos) megmérésével kellene / lehetne megállapítani. Azt elızetesen is becsülni lehet a termék vagy még a tervdokumentumok bizonyos jellemzıi alapján, sıt a minıségrıl való preventív gondoskodásnak kifejezetten ilyen jegyekre kell figyelnie. Az érthetıség elızetesen például ilyen jegyek alapján ítélhetı meg: a szoftver a dokumentációban és a felhasználóval folytatott párbeszédben a támogatott szakterület terminológiáját használja; rendelkezésre áll alkalmazási tutorial; az online help tartalmaz összetett alkalmazási feladatok megoldására vezetı többlépéses eljárásokat leíró hogyan oldjuk meg részeket;

25 INFORMÁCIÓRENDSZER FEJLESZTÉSE 165 a tipikus alkalmazási feladatok megoldására a felhasználót kézen vezetı wizardok indíthatók. A megtanulhatóság és az üzemeltethetıség (kezelhetıség) nincsenek átfedés nélkül: A könnyebben kezelhetı szoftver általában könnyebben is tanulható, és igaz fordítva is. Ezért a kétféle minıség közös jegyek alapján ítélhetı meg. Néhány ilyen jegy: Rendelkezésre áll a kezelést magyarázó felhasználói / üzemeltetıi kézikönyv és online help. A leggyakrabban használt funkciókat indító menüpontok / funkciógombok találhatók meg a legkönnyebben. A szoftver felhasználói felülete a szervezetnél leggyakrabban használt más szoftverekhez hasonló felépítéső. A felhasználói felület intelligens: a választéklistában csak olyan értékeket ajánl fel, amelyeket más bemenı adatok vagy azokhoz az adatbázisból hozzákapcsolható adatok valamilyen szabály alapján nem zárnak ki. Nem várja olyan bemenı adat megadását, amelyre az elıbb említett kizáró feltételek csak egyetlen lehetséges értéket engednek meg. A hibás felhasználói akciókat vagy a valamilyen szabályt sértı bemeneti adategyüttest visszautasítja. (Ennyiben a kezelhetıség átfed a hibatőrés minıséggel is.) Hatékonyság A hatékonyság azon tulajdonságok összessége, amelyek a szoftver teljesítményszintje és az ehhez felhasznált erıforrások mennyisége között adott feltételek mellett fennálló kapcsolatra vannak hatással. Megjegyzés: Az erıforrások közé tartozhatnak más szoftvertermékek, hardverek, anyagok (pl. nyomtatópapír, cserélhetı külsı tárolók) és az üzemeltetı, karbantartó vagy fenntartó személyzet szolgáltatásai. A hatékonyság összetevıi: Idıigény: a szoftver azon tulajdonságai, amelyek a funkcióinak végrehajtásakor hatással vannak a válaszidıkre, illetve feldolgozási idıkre és az egységnyi idıre esı teljesítményekre. Erıforrásigény: a szoftver azon tulajdonságai, amelyek a funkcióinak végrehajtásakor hatással vannak a felhasznált erıforrások mennyiségére és a felhasználásuk idıtartamára. Karbantarthatóság A karbantarthatóság a konkrét változtatások elvégzéséhez szükséges ráfordításokra hatással lévı tulajdonságok összessége. Megjegyzés: A változtatás lehet helyesbítés, továbbfejlesztés vagy a környezetben, a követelményekben és a funkcionális elıírásokban bekövetkezett változásokhoz való illesztés. A karbantarthatóság összetevıi: Elemezhetıség: a szoftver azon tulajdonságai, amelyek hatással vannak a hibák vagy a meghibásodási okok feltárásához, illetve a módosítandó részek azonosításához szükséges ráfordításra. Változtathatóság: a szoftver azon tulajdonságai, amelyek hatással vannak a módosítás, hibaeltávolítás, illetve a környezetben történı változásokhoz illesztés által igényelt ráfordításra.

26 166 INFORMATIKUS SZAKMAI ISMERETEK Stabilitás: a szoftver azon tulajdonságai, amelyek hatással vannak a módosítások miatt fellépı nem várt következmények kockázatára. Tesztelhetıség: a szoftver azon tulajdonságai, amelyek hatással vannak a módosított szoftver igazoló / érvényesítı ellenırzéséhez szükséges ráfordításra. A karbantarthatóságra is igaz, hogy bár azt az ISO 9126 szabvány valamilyen ráfordítások mértékével definiálja, a minıség fokának meghatározásánál mégsem lehet csupán a ráfordítások (utólagos) megmérésére hagyatkozni. Azt preventíven is becsülni lehet, sıt kell, a tervdokumentumok és a termék más jellemzıi, a szoftver architektúrája alapján. A karbantarthatóság egy szoftverfejlesztı cég számára kétszeresen különös jelentıséggel bír, mert ez kifejezetten olyan jellemzı, amelyhez a szoftvert fejlesztı vállalkozásnak a megrendelı igényeitıl függetlenül érdeke főzıdik, sıt e tekintetben a szállító érdekeltsége közvetlenebb és fokozottabb, mint a megrendelıé. A fentiek magyarázatául: a karbantarthatóság a szoftver használati értékét csak közvetve növeli (pl. a megbízhatóság javításával), viszont (hosszabb távon) a fejlesztı cég ráfordításainak költségeinek radikális csökkentését, az egyszeri ráfordítás többszöri megtérülését teszi lehetıvé. Mindebbıl az is következik, hogy adott projektre / termékre vonatkozóan a karbantarthatóság jelentıségét értelmetlen azon mérni, hogy megfizeti-e a megrendelı vagy sem. A megrendelı-szállító relációra tett megállapításon túl ki kell térni a vállalkozás és alkalmazottja, valamint a vállalkozás és részlege relációra is. Ami igaz a cég egészére és hosszabb távon, nem feltétlenül igaz az alkalmazottai vagy részlegei szintjén és aktuálisan. A karbantarthatóság által feltételezett korrekt dokumentálás közvetlenül nem érdeke a szoftverfejlesztı vállalkozás egyes alkalmazottainak, sıt az alkalmazottnak kifejezetten elınyös, ha valamely szoftvertermékre vonatkozó tudás minél nagyobb része egyedül az ı fejében van meg, mert ez a tény ıt kulcsfontosságú munkatárssá teszi a cégen belül. A vállalkozás egy olyan részlege, amelynek az a feladata, hogy erıforrást szolgáltasson más részlegek számára, közvetlenül abban érdekelt, hogy minél több erıforrást vásároljanak tıle, tehát ellenérdekelt az erıforrásigényt csökkentı, tehát a ráfordításokat csökkentı megoldásokkal szemben. Az elemezhetıséget, a változtathatóságot javító átgondolt tervezés, valamint a korrekt dokumentálás olyan plusz ráfordítás az éppen futó projekt és annak munkatársa(i) számára; amely más, késıbbi projektek és más munkatársak hatékonyságát javítja. Ha a menedzsment rövid távon csak az aktuális évre kimutatható eredményben gondolkodik, akkor ez a tény ıt is a karbantarthatóság minıség hanyagolásában teszi érdekeltté. A megelızı elemzésekbıl kitőnik, a karbantarthatóság teljesítése nem csupán egy speciális minıségszabályozási feladat. Ez hosszú távú gondolkodás, cégszintő felsı vezetıi szintő elkötelezettség, támogatás és számonkérés hiányában nem oldható meg. Rövid távon gondolkodó vezetés a karbantarthatóság javításában csak elırehozott ráfordításokat, tehát likviditási gondokat okozó tényezıt lát; figyelmét elkerüli a jövıbeni költségcsökkenés, a ráfordítások többszörös megtérülésének lehetısége. Az ilyen vezetés könnyen hagyja meggyızni magát arról, hogy a karbantarthatóságot rafinált okostojások csak azért forszírozzák, hogy jól fizetı keresletet támasszanak kedvenc passzióik iránt.

27 Hordozhatóság INFORMÁCIÓRENDSZER FEJLESZTÉSE 167 A hordozhatóság a szoftver egyik (szervezeti vagy hardver- vagy szoftver-) környezetbıl a másikba átvihetıségének képességére ható tulajdonságok összessége. A hordozhatóság összetevıi: Adaptálhatóság: a szoftver azon tulajdonságai, amelyek hatással vannak arra, hogy különbözı, adott környezetekhez adaptálni lehessen kizárólag olyan tevékenységek, illetve eszközök alkalmazásával, amelyekkel a szóban forgó szoftver ennek céljából el van látva. Telepíthetıség: a szoftver azon tulajdonságai, amelyek hatással vannak arra, hogy a szoftver valamely adott környezetben való telepítéséhez mennyi ráfordítás szükséges. Mőszaki megfelelıség: a szoftver azon tulajdonságai, amelyek biztosítják, hogy a szoftver a hordozhatósággal kapcsolatos szabványokat és szabályokat betartsa. Kiváltó képesség: a szoftver azon tulajdonságai, amelyek hatással vannak arra, hogy egy másik szoftver helyett használni lehessen annak környezetében, továbbá arra, hogy mennyi ráfordítás szükséges ehhez. Megjegyzések: 1. A modell a kiváltóképesség fogalmát a kompatibilitás helyett használja, hogy ne legyen összetéveszthetı az együttmőködés fogalmával (lásd fentebb a Funkcionalitás alatt). 2. Egy adott szoftvernek egy másik szoftverrel való kiválthatósága nem vonja maga után, hogy az utóbbit is ki lehet váltani az elıbbivel (lásd felfelé kompatibilitás). Az itt felsorolt jellemzık mellett a gyakorlatban más, hasonló célú jellemzıket is emlegetni szoktak. Ilyen például a nyitottság, ami leginkább az itteni hordozhatóság és a Funkcionalitás alatti együttmőködés jellemzık együttesének felel meg, amennyiben a nyitott rendszerek általánosan elfogadott szabványokat követnek, párhuzamosan többféle szabványt is támogatnak; sokféle interfésszel rendelkeznek (mind vertikálisan az infrastruktúra irányában, mind horizontálisan más alkalmazások irányában) Követelményelemzés követelményspecifikáció Elemzésre általánosságban bármikor szükség lehet egy döntés elıkészítése vagy valamilyen kimenetelek értékelése céljából. Azonban a szoftverfejlesztés kapcsán emlegetett elemzés speciálisan egy kezdeti szakaszt jelöl (egy rendszerfejlesztés, egy szoftverfejlesztés, egy inkrementumfejlesztés vagy egy iteráció kezdeti szakaszát), amelynek alapvetı feladata a miért kérdés részletezı megválaszolása, azaz a fejlesztés tárgyára vonatkozó követelmények azonosítása, leírása és az érvényes követelmények kijelölése. A szakasz ezért kapja gyakran a követelményelemzés nevet (lásd még: rendszerkövetelmények elemzése, szoftverkövetelmények elemzése), illetve e szakasz termékei a követelményspecifikációk. Megjegyzés: A fejlesztés kezdıpontját a különbözı érintettek nagyon eltérıen határozhatják meg. Így a finanszírozó szervezet számára a követelményelemzést megelızıen legalább két plusz fázis létezik, és mindkettı dominánsan elemzıi aktivitást kíván: az elsı a fejlesztés üzleti céljának a meghatározása, a második az üzleti céloknak megfelelı fejlesztési célok vezetıi szintő meghatározása. Az utóbbi a finanszírozó szervezet vezetésének a fejlesztési projekt indítására vagy elvetésére vonatkozó döntését készíti elı, és olyan termékekkel zárulhat, mint a megvalósíthatósági tanulmány vagy az ajánlatkérés vagy a projektdefiníció. Mindezektıl különbözik az itt tárgyalt követelményelemzés, amelynek termékei már az elindított projekt érintettjeinek és részvevıinek szólnak.

28 168 A követelmények forrásai INFORMATIKUS SZAKMAI ISMERETEK A követelmények forrását képezhetik: problémák és változtatási igények nyilvántartása, amit az üzemeltetés alatti problémakezelés vezet (lásd a 4.7. ábrát); különféle dokumentumok (jogszabályok, szabályzatok, szabványok, szoftverdokumentációk, ajánlatkérés, ajánlat, szerzıdés szakmai melléklete, tanulmányok, ); kérdıíves felmérések; interjúk a felhasználói oldal képviselıivel; megfigyelés (az üzleti folyamatok vagy a jelenlegi rendszer feldolgozási folyamatainak megfigyelése); a külvilág, a partnerek jelzései; az elemzı józan esze (legfıképpen az inkonzisztens vagy a korlátokat túllépı követelmények felismeréséhez nélkülözhetetlen). Követelmények Karbantartás Vált.igények Problémanyilvántatás, válltozáskezelés Fejlesztés Üzemeltetés, használat Probléma Termékek 4.7. ábra: A fejlesztési, üzemeltetési, problémakezelési és karbantartási folyamatok kapcsolatai E szakasz alapvetı termékei: az összegyőjtött követelmények leírása (specifikációja); rendszerszervezési változatok (javaslatok) és értékelésük; elemzési modellek, amelyek többsége formailag hasonló a tervezési modellekhez (lásd a 4.5. alfejezetben); a követelményeket tesztelı prototípus és értékelése; tanulmányok. Mint a fenti felsorolásból kitőnik, e szakasz termékei között modellek is találhatók. Van olyan modellezési technika, amely közvetlenül a követelmények specifikálására szolgál, ez a használati eset diagramtechnika, amelyet alább részletesen is bemutatunk. Mások a tervezési modellek diagramtechnikáival azonosak, de ebben a szakaszban nem tervek készítését szolgálják, hanem például a megfigyelések eredményeinek rögzítésére használják ıket (mint a tevékenységdiagramot), illetve általában a probléma megértését segítı modelleket készítenek velük.

29 INFORMÁCIÓRENDSZER FEJLESZTÉSE 169 A funkcionális követelmények specifikálása Használati eset diagramok Az Object Management Group (OMG) konzorcium által gondozott UML (Unified Modeling Language) modellezési nyelvben (lásd a szakaszban) a használati eset (use case) diagramtechnika alkalmas a funkcionális követelmények összegyőjtésére és áttekintı leírására. ud BB InternetBank Számla áttekintı «extend» Egyenleg «extend» Beállítások Számlainformációk kérése Postaláda kezelése Ügyfél «extend» «extend» Bankkártya mőv eletek Számlatörténet Számlakiv onatok Megbízások «extend» Forint átutalás «include» «include» «extend» «extend» «extend» Forint átv ezetés Idıszak beállítása Kötegelt átutalás Dev iza átutalás «include» «extend» «extend» Megbízásokat tartalmazó fájl kij elölése Átutalás fizetési mód Import beszedés fizetési mód 4.8. ábra: A BB InternetBank szolgáltatásainak használati eset (use case) diagramjának részlete A Jacobson és társai által [Jacobson-1992] kidolgozott használati eset diagram elınye, hogy bárki könnyen elkészítheti, hiszen a pálcikaemberkékbıl, krumplikból és nyilakból álló ábra rajzolójának csak igen kevés és egyszerő szabályt kell betartani, szintúgy a kész diagram értelmezéséhez sem szükséges különösebb elıképzettséggel rendelkezni. Az interjút készítı elemzı szakember akár a felhasználóval folytatott beszélgetés közben gyorsan

30 170 INFORMATIKUS SZAKMAI ISMERETEK felvázolhatja az aktuális vagy az igényelt rendszer szolgáltatásaira vonatkozóan frissen szerzett értesüléseit, és a vázlatát valószínőleg a felhasználói partner is érteni fogja. Az utóbbi fontosabb lehet, mint elsıre gondolnánk, mert ellenırizhetıvé teszi, hogy az informatikus és a felhasználó legalább nagyvonalakban azonos módon értelmezik az elhangzottakat. A használati eset diagramok célja, jelentısége: alkalmasak a szolgáltatásokra vonatkozó követelmények specifikálására és alkalmasak a felhasználói szerepkörök azonosítására, kijelölik a rendszer határait; támpontot adnak a projekt által igényelt erıforrások meghatározásához; megalapozzák a fejlesztı projekt ütemezését, idı- és költségtervezését, bemenetül szolgálnak a tesztspecifikációk készítéséhez (lásd a szakaszban). A fenti felsorolásból talán csak az igényel magyarázatot, hogy miért van szükség a felhasználói szerepkörök azonosítására: A rendszer biztonsága megkívánja a felhasználók hozzáférési jogainak megtervezését is. A jogosultságokat azonban a tervezés során nem lehet konkrét személyekhez rendelni (azok akkor még nem is ismertek), helyettük felhasználói szerepköröket (absztrakt személyeket) kell kijelölni, és azok jogosultságait kell meghatározni. A használati eset diagram szimbólumai: Aktor: Az aktorok felhasználói szerepköröket, illetve a rendszer határain kívül esı, de a rendszerrel kapcsolatban álló olyan elemeket (pl. kapcsolódó más rendszereket) képviselnek, amelyek adatot szolgáltatnak a rendszernek vagy adatokat kapnak tıle. Az aktor jele egy pálcikaember, alatta az aktor nevével, vagy egy téglalap, amiben az «actor» sztereotípia és az aktor neve látható. A 4.8. ábra példájában egyetlen aktor van, az Ügyfél. Használati eset: A használati esetek a rendszer azon szolgáltatásai (funkciói), amelyeket a felhasználók látnak, másképpen mondva: amelyekkel az aktorok közvetlen kapcsolatba kerülnek (a funkció végrehajtását az aktor kezdeményezi, vagy az valamely aktorra hat), illetve az elıbbiek olyan részfunkciói, amelyek az aktorok által még mindig láthatók. A használati eset jele egy ellipszis ( krumpli ), benne a használati eset (funkció) nevével. Aktor és használati eset kapcsolata: Az aktor és a használati eset kapcsolata általában valamilyen kommunikációs viszonyt jelent. Az UML ezt a viszonyt (az UMLben) asszociációnak nevezett összekötı vonallal jelöli. Ez kétirányú kommunikáció esetén az aktort és a használati esetet összekötı egyszerő vonal, de egyirányú kommunikáció esetében lehet az adat (üzenet) áramlásának irányát mutató nyíl is. Egy interaktív felületen a kommunikáció technikailag általában kétirányú, de még ilyenkor is alkalmazható nyíl, ha a modellezı azt akarja kifejezni, hogy a funkciót az aktor kezdeményezte (amikor a lényeg az, hogy az aktor közöl valamit a rendszerrel), ilyenkor a nyíl az aktortól a használati eset felé mutat; vagy ha azt akarja kifejezni, hogy a használati eset az aktorra hat (amikor a lényeg az, hogy a rendszer közöl valamit az aktorral), ilyenkor a nyíl a használati esettıl az aktor felé mutat. Használati esetek közötti függés: A használati esetek között kétféle függést szokás jelölni. Az egyik a tartalmazás, amikor egy A használati eset mint funkció részfunkcióként tartalmaz (használ) egy B használati esetet. A másik az opcionális kiegészítés: az A használati eset opcionális kiegészítése a B használati esetnek, ha speciális feltételek teljesülése esetén (de csak akkor) a B-vel együtt az A is végrehajtódik. A használati esetek függıségét az UML szaggatott vonalú nyíllal jelöli. A tartalmazást jelölı nyíl a tartalmazott használati eset felé mutat és «include» sztereotípia

31 uc Actorok INFORMÁCIÓRENDSZER FEJLESZTÉSE 171 minısíti. Az opcionális kiegészítést jelölı nyíl a kiegészített használati eset felé mutat és «extend» sztereotípia minısíti. A 4.8. ábrán a Számlatörténet használati eset tartalmazza (include) például az Idıszak beállítása funkciót; másrészt a Számlatörténet funkció egy opcionális kiegészítése a Számlainformációk kérése funkciónak, amennyiben csak akkor hajtódik végre, ha a kért információ éppen egy adott számla története. Felhasználó Ügyfél Ügyfélszolgálati ügyintézı Pénztáros 4.9. ábra: Általánosítás és specializáció aktorok között Aktorok általánosítása / specializációja: Ha az A1, A2, aktorok speciális változatai az A aktornak, akkor ezt az UML általánosítás (specializáció) szimbólummal (a speciális aktortól az általános felé mutató, háromszögben végzıdı nyíllal) jelöli. A 4.9. ábra példájában a Felhasználó aktor általánosítása az Ügyfél, az Ügyfélszolgálati ügyintézı és a Pénztáros aktoroknak; illetve megfordítva: az utóbbiak specializációi a Felhasználó aktornak. Használati esetek általánosítása / specializációja: Ha az A1, A2, használati esetek speciális változatai az A használati esetnek, akkor ezt az UML szintén az általánosítás (specializáció) szimbólummal (a speciális használati esettıl az általános felé mutató, háromszögben végzıdı nyíllal) jelöli. A 4.8. ábrán a Forint átvezetés speciális esete a Forint átutalás funkciónak. A diagramon megjelenı szimbólumokhoz (aktorokhoz, használati esetekhez, összekötı vonalakhoz) további szöveges leírások is kapcsolhatók. Esetleg az egy-egy használati eseten belüli történések más diagramtechnikával (tevékenységdiagrammal, szekvenciadiagrammal) vagy szöveges forgatókönyvvel részletezhetık. Megjegyzés: Ez a diagramtechnika alkalmatlan a felhasználók számára észrevehetetlen háttérfunkciók iránti követelmények feltárására Rendszerszervezési változatok Az összegyőjtött követelmények mind együttvéve általában nem valósíthatók meg, mert vagy ellentmondásosak 2, vagy nem férnek bele az adott határidı, költségvetési keret és erıforrások által korlátozott projektbe. Ezért a követelménygyőjtemény alapján rendszerszervezési változatokat (javaslatokat) dolgoznak ki. Az egyes változatok a követelmények egy-egy részhalmazát képviselik: egy ilyen részhalmazba csak egymással konzisztens és a figyelembe veendı korlátok mellett együttesen megvalósítható követelmények tartozhatnak. 2 A követelmények között nagyon gyakoriak az ellentmondások. Ennek oka általában nem a megfogalmazók figyelmetlensége. Mindegyik követelmény valós lehet, csak éppen ellentétes érdekek alapján született.

32 172 INFORMATIKUS SZAKMAI ISMERETEK Egy követelményhalmaz akkor konzisztens, ha ellentmondásmentes és hivatkozásteljes. Az utóbbi azt jelenti, hogy ha a követelményhalmaz tartalmaz egy olyan A követelményt, amelynek teljesítése feltételezi egy másik B követelmény teljesítését is, akkor a követelményhalmaz szükségképpen a B követelményt is tartalmazza. A követelményelemzés szakaszban az elemzık elvégzik az egyes rendszerszervezési változatok elınyök, hátrányok, egyéb következmények szempontjából való értékelését is. A menedzsment az értékelésekre támaszkodva kiválasztja azt a változatot, amely alapján elkezdıdhet a fejlesztés tárgyának tervezése. Megjegyzés: Egyes módszertanok (pl. a RUP) az itt leírtaktól eltérıen megkülönböztetik a követelmények meghatározása és az elemzés tevékenységeket, mert náluk az elemzés általában csak elemzési modellek elkészítését, a rendszerszervezési változatok értékelését jelenti Ellenırzı kérdések a 4.3. alfejezethez 1. Milyen célok motiválhatják egy szoftverfejlesztési vagy szoftverbeszerzési projekt indítását? 2. A szoftverek minıségi jellemzıinek milyen fıbb minıségi kategóriáit ismeri az ISO 9126 szabvány? 3. Az alábbi állításokkal jellemzett szoftverekre ISO 9126 szerinti minıségi kategóriák közül melyek illenek? Az A szoftver egy adatbáziskezelı rendszerre épül, de nem használja ki az adott adatbáziskezelı speciális (más adatbáziskezelı rendszereknél hiányzó) képességeit. A B eleget tesz a támogatott szakterületre vonatkozó szabványoknak, szabályoknak, törvényi elıírásoknak. A C szoftver tervdokumentációja jól tagolt, egyértelmővé teszi, hogy melyik döntés (tervelem) milyen követelmény teljesítése érdekében vagy milyen korlát figyelembe vétele okán született. A D szoftver az iparági szinten legáltalánosabban elfogadott technológiai szabványokat követi. Az E szoftver a saját eszközeinek felhasználásával könnyen igazítható különbözı alkalmazási környezetekhez. Az F szoftver lényegesen különbözı teljesítményő erıforrásokon is mőködıképes, a szoftver által felhasznált erıforrások mennyisége, teljesítménye rugalmasan a terheléshez igazítható. Az új G szoftver felhasználói felülete nagymértékben hasonlít az alkalmazottak által eddig megszokott szoftverekéhez. A H szoftver a dokumentációban és a felhasználóval folytatott párbeszédben a támogatott szakterület terminológiáját használja. Az I szoftvernél a leggyakrabban használt funkciókat indító menüpontok / funkciógombok "találhatók meg" a legkönnyebben. A J szoftver a választéklistában csak olyan értékeket ajánl fel, amelyeket más bemenı adatok vagy azokhoz az adatbázisból hozzákapcsolható adatok valamilyen szabály alapján nem zárnak ki. Nem várja olyan bemenı adat megadását, amelyre az elıbb említett kizáró feltételek csak egyetlen lehetséges értéket engednek meg. A K szoftver a hibás felhasználói akciókat vagy valamilyen szabályt sértı bemeneti adategyüttest visszautasítja. 6. Milyen ráfordításokkal javítható a szoftver megbízhatósága?

33 INFORMÁCIÓRENDSZER FEJLESZTÉSE Milyen jegyek alapján prognosztizálható egy szoftver karbantarthatósága? 8. Melyek azok a szoftverminıségek, amelyek javításához a fejlesztı cégnek nagyobb érdeke főzıdik, mint a megrendelınek? 9. Mi a követelményelemzés tevékenység célja? 10. Milyen források képezik a követelményelemzés inputját? 11. Milyen termékei lehetnek a követelményelemzés tevékenységnek? 12. Milyen célokat szolgál a használati eset diagram? 13. Milyen szimbólumokat tartalmazhat a használati eset diagram, és mit reprezentál a különbözı típusú szimbólumok? 14. Milyen objektív okai lehetnek az azonosított szoftverkövetelmények közötti ellentmondásoknak? 15. Mit értünk rendszerszervezési változatok alatt?

34 174 INFORMATIKUS SZAKMAI ISMERETEK 4.4 Tervezés Itt a tervezésnek a rendszer nagyvonalú tervezésére, azon belül egy szoftver nagyvonalú tervezésére, valamint a részletes tervezésre egyaránt kiterjedı áttekintését adjuk A szoftver mint komplex rendszer A szoftver tervezése során általánosan (azaz nem a szoftver rendeltetésétıl függıen) felmerülı problémák, valamint az alkalmazott technológia megoldásai mind azzal függnek össze, hogy a szoftver egy komplex (bonyolult, összetett) rendszer. Ennek következménye, hogy mindegyik szoftverfejlesztési módszertan és megközelítési mód lényegében két általános célt tőzött ki maga elé: kezelhetıvé tenni a bonyolult (összetett) problémákat, javítani a szoftver fejlesztési és megtérülési minıségi jellemzıit. A komplex problémák kezelhetıvé tétele közelebbrıl az alábbi részcélokra bontható le: Bármilyen bonyolult is a probléma egésze, annak megoldása olyan út(hálózat) bejárásával legyen produkálható, amelynek végül minden csomópontjában csak egyszerő problémákat kell megoldani. A feladat egésze csoportmunkában is elvégezhetı legyen, azaz felosztható legyen a csoport tagjai által nagymértékben függetlenül megoldható részfeladatokra. A szoftver fejlesztési és megtérülési minıségi jellemzıin a szoftvereknek kifejezetten a fejlesztési technológia (szoftvertechnológia) megválasztásával és következetes betartásával befolyásolható minıségi jellemzıit értjük, melyek a következık: az elemezhetıség, a változtathatóság, a tesztelhetıség, a stabilitás, a hordozhatóság, az újrafelhasználhatóság. Mivel a fenti felsorolás elsı öt elemét a szakaszban ismertetett ISO 9126-os szoftverminıségi szabványból vettük, ezért itt csak az újrafelhasználhatóság értelmezését kell pótolni; de azt is meg kell jegyezni, hogy a hordozhatóságnak itt csak olyan elemeire szorítkozunk, amelyekre a szoftvertechnológia megválasztása befolyással lehet. Az újrafelhasználhatóság jelentése: egy probléma megoldására kifejlesztett szoftverkomponens minden olyan más szoftver fejlesztése során, amelynek a probléma megoldása szintén feladatát képezi változatlanul felhasználható legyen, illetve az utóbbi (a kompozíció szintő) szoftver legyen készen idegen fejlesztéső komponensek befogadására. A felsorolt minıségi jellemzıket összefoglalóan fejlesztési és megtérülési minıségeknek nevezhetjük, mert ezek olyan elınyös következményekkel járhatnak, mint (1) a fejlesztési vagy továbbfejlesztési költségek csökkenése, (2) az egyszeri ráfordítások többszöri megtérülése. Az (1) állítás fıleg az elemezhetıség, a változtathatóság, a tesztelhetıség, a stabilitás és az újrafelhasználhatóság minıségekre igaz; a (2) állítás pedig (megint) az újrafelhasználhatóságra és a hordozhatóságra.

35 INFORMÁCIÓRENDSZER FEJLESZTÉSE 175 Megjegyzés: A szakirodalom különösen az objektumorientált technológia irodalma gyakran használja minıségi kategóriaként a robusztusságot (robust software, robustness), vagy magyarra fordítva a szilárdságot. Ez a minıség leginkább a fentebb felsorolt változtathatóság és stabilitás kombinációjának felel meg. Azt jelenti, hogy a szoftverrel szembeni funkcionális követelmények megváltozása, új igények jelentkezése esetén egyértelmően azonosítható az a szoftverkomponens (építıelem), amely egy-egy elkülöníthetı igényváltoztatást érvényesítı módosítás tárgyát képezi; a változtatás hatása azon nem terjed túl, következésképpen a szoftver más kapcsolódó részeinél nem várt következményekkel nem kell számolni. A megoldási módokban is elmélyedve, látni fogjuk, hogy a komplex feladat kezelhetıvé tétele, valamint a fejlesztési és megtérülési minıségi jellemzık javítása célok nem függetlenek egymástól, legalábbis abban az értelemben nem, hogy nagyvonalakban mindkét cél ugyanazon az úton, ugyanazokat a technológiai megoldásokat alkalmazva közelíthetı meg. A komplex problémák megszelídítésének általánosan nem csak a szoftverfejlesztés során követett módja az osztd meg és uralkodj elv alkalmazása, azaz a probléma vagy az elıállítandó termék alkalmas modulokra, építıelemekre bontása. Ezért ezt másképpen modularizálásnak is nevezik (lásd még a moduláris megközelítést a szakaszban). Az alkalmas modul (építıelem) elsı közelítésben olyan modult jelent, amely a környezete részérıl fekete dobozként kezelhetı, ilymódon az absztrakciónak, a környezetre nem tartozó részletek elrejtésének eszköze; a környezet csak a modul feléje mutatott felületét (interfészét: a modul inputjának és outputjának szerkezetét, tulajdonságait) ismerheti, aminek a modul rendeltetésével együtt stabilnak kell lennie. a rendeltetése egymagában is (más modulok nélkül is) megérthetı, meghatározható; önállóan (elkülönülten) tervezhetı, kivitelezhetı, tesztelhetı; a modulokból az eredetileg célul kitőzött rendszer felépíthetı, a rendszer mőködése a modulok megfelelı együttmőködésével produkálható. Az igazán komplex feladatok esetében többszintő, azaz hierarchikus modularizációt (felbontást) kell alkalmazni, mert az egyszintő felbontás vagy akkora modulokat eredményez, amelyek magukban is közel azonos bonyolultságúak az eredeti feladattal, vagy a modulok és a modulkapcsolatok akkora sokaságát kapjuk, amely végül ugyanolyan átláthatatlan, mint az eredeti feladat. Az itt bevezetett hierarchikus modularizáció a következık miatt képes megszelídíteni a bonyolult feladatokat: A rendszer egészének megtervezése, vagy felépítése azért egyszerő, mert ezen a szinten a rendszer kevés számú elemet (néhány nagyobb modult) és kevés számú kapcsolatot (az említett modulok közötti kapcsolatokat) tartalmazza. A rendszer egészét közvetlenül alkotó modulok a felbontás legmagasabb szintjén fekete dobozok: érdektelen, hogy belül hogyan mőködnek; csak az a lényeg, hogy a külvilággal (a velük kapcsolatban lévı más modulokkal) az elvárt együttmőködést valósítsák meg, azaz a rendeltetésük szerint elfogadható megszólításra (inputra), a rendeltetésük szerinti választ (outputot) adjanak. Mivel a környezet nem tudhatja, hogy a modul belül hogyan mőködik, a modul belseje könnyen a többi modul számára észrevétlenül lecserélhetı, ha a környezet felé mutatott felületének a tulajdonságai nem változnak. Egy komponens modul tervezése vagy felépítése azért egyszerő, mert vagy az eggyel alacsonyabb szintő felbontás miatt ugyanaz mondható el róla, mint fentebb a rendszer egészérıl; vagy ez már egy valódi elemi komponens, amely minden részletével együtt könnyen átlátható.

36 176 INFORMATIKUS SZAKMAI ISMERETEK Nincs akadálya a csoportmunkának, a felsorolt tulajdonságú modulok kivitelezése szétosztható egy csoport különbözı tagjai között. Egy komplex rendszer azonban nagyon sokféleképpen tagolható modulokra, építıelemekre. Éppen a tagolás (a lebontás) megválasztásához adnak szempontot a fejlesztési és megtérülési szoftverjellemzık. Érdekes módon a különbözı minıségek teljesítése érdemben egyetlen elvnek a független problémák megoldása elkülönítésének következetes alkalmazását feltételezi, amely az alábbi két pontban fogalmazható meg: A szoftver komponenseit (építıelemeit) úgy kell kijelölni, hogy adott probléma megoldásáért felelıs (egyszerő vagy összetett) szoftverépítıelem mindig egyértelmően azonosítható legyen. Ha két probléma egymástól függetlenül is felmerülhet, vagy az egyik probléma megoldására vonatkozó követelmények a másik probléma megoldására vonatkozó követelményektıl függetlenül megváltozhatnak, akkor ezen két probléma megoldása nem lehet egyetlen bonthatatlan szoftverépítıelem feladata. Fontos technológiai elv: Egymástól független célok között a fejlesztı ne létesítsen mesterséges függést azzal, hogy a megoldásukat egyazon (nem bontható) komponensre bízza. A független problémák megoldása elkülönítésének elve jelenik meg a szakaszban tárgyalt hétrétegő ISO/OSI modellben is. Vegyük sorra, milyen hatással van ezen elv alkalmazása az egyes fejlesztési és megtérülési minıségekre! Elemezhetıség: Ha egy hibajelenség meghatározott probléma megoldásához köthetı, akkor a hiba oka a probléma megoldásáért felelıs szoftverelemben van. Hasonlóan, ha egy probléma megoldására vonatkozó követelmény megváltozik, akkor az is egyértelmően adódik, hogy melyik építıelem módosításával lehet érvényesíteni ezt a változást. Változtathatóság: A szükséges változtatások csak a hibával vagy követelményváltozással érintett probléma megoldásáért felelıs modulra (építıelemre) korlátozódnak. Ez részben az elemezhetıségnél már említett okok következménye, de elengedhetetlen feltétele a jó modularizáció azon tulajdonsága is, amely szerint minden építıelem a többi építıelem számára fekete doboz, azaz a modul belseje a többi modul számára észrevétlenül cserélhetı, ha a környezet felé mutatott felületének a tulajdonságai nem változnak. Így a többi modulhoz nem kell hozzányúlni, hiszen azok változatlanul együtt tudnak mőködni a megváltozott modullal. Tesztelhetıség: A legalacsonyabb szintő építıelemek tesztelése (az egységteszt) azért nem igényel nagy ráfordítást, mert az ilyen egységek csak valamilyen egyszerő, könnyen ellenırizhetı szolgáltatásért felelnek. Az összetett modulok tesztelését (az integrációs tesztet) pedig az könnyíti meg, hogy annak alkalmával a komponens modulok jóságáról már nem kell meggyızıdni, azt az alacsonyabb szintő tesztek már igazolták, elegendı csupán a komponensek közötti együttmőködés helyességét vizsgálni. Ha pedig egy késıbbi változtatásra kerül sor, akkor a változtathatóságról szóló részben végigvitt gondolatmenetet követve az is adódik, hogy a tesztelésnek elegendı a megváltozott modulra és annak közvetlen kapcsolataira kiterjedni. Stabilitás: Ha az elemezhetıség és a változtathatóság feltételei a modularizáció, az interfészek változatlansága, a független problémák megoldásának elkülönítése teljesülnek, akkor nem várt következmények csak a módosított modulon belül fordulhatnak elı. Ezek a belsı következmények pedig a tesztelhetıség javulása miatt akkor is könnyebben felderíthetık, ha ez a modul maga is összetett.

37 INFORMÁCIÓRENDSZER FEJLESZTÉSE 177 Úrafelhasználhatóság: Az újrafelhasználás alapegységei is a modulok. Ezek újrafelhasználását az könnyíti meg, ha a befogadó környezettel szemben minél kevesebb elvárásuk van; másképpen mondva a modul nagymértékben önjáró integritás, azaz a mőködéséhez a befogadó környezetnek minél kevesebb feltételrıl kell gondoskodnia. Ez megint összevág a modulok fekete doboz minıségével, de elengedhetetlenné teszi a független problémák megoldásának elkülönítését is. Ha ugyanis egy modul többet tud, mint amit egy adott környezet elvár tıle, akkor általában a környezet részérıl is nagyobb ráfordítással jár a befogadása és a mőködtetése. Hordozhatóság: Itt a független problémák megoldása elkülönítésének az a speciális esete játszik szerepet, amikor a technikai környezettel való kommunikációt elkülönített modul(ok)ban oldjuk meg. A hordozhatóságban szerepet kapnak még olyan szoftvertechnológiai konstrukciók is, amelyekre támaszkodva a környezettel való kommunikáció lebonyolítására vonatkozó döntések a tervezési vagy kivitelezési idı helyett a telepítési vagy a futtatási idıre halaszthatók. Miután a független problémák megoldása elkülönítésének több elınyös következményét beláttuk, be kell vallani, hogy ezen elv alkalmazásának gyenge pontja éppen a problémák függetlenségének felismerhetısége. A klasszikus strukturált megközelítés [Yourdon-1989] az egymástól független problémáknak (független döntéseknek) a tervezésben való elkülönítésére egy tervezési szintekbıl és vetületekbıl álló sablont ajánlott. Bevezette a tervezés fogalmi (más szóval szakterületi), logikai és fizikai szintjét, valamint más dimenzióban az adat, a feldolgozás és a felhasználói felület (vagy esemény vagy környezet) vetületeket (4.10. táblázat). Vetületek Szintek Adat Feldolgozás Felhasználói felület / Környezet, események Fogalmi szint Logikai szint Fizikai szint A kiszolgált szakterület adatai és ezeknek a szakterület szabályaiból következı kapcsolatai A szakterületi igények, szabályok figyelembe vétele Mit?: Milyen szolgáltatásokat kell nyújtani a rendszernek? Ennek érdekében milyen funkciói lesznek? (A funkciókat mint fekete dobozokat leíró specifikációk.) Szőkebben: az ember gép kapcsolatra vonatkozó elképzelések. Tágabban: a környezet azon eseményei, amelyekre a rendszer reagál Hatékonysági, biztonsági szempontok és szervezeti korlátok figyelembe vétele Informatikai hatékonysági, biztonsági szempontok miatt szükséges további adatok, adatkapcsolatok. A szervezeti korlátokat is figyelembe vevı struktúra Hogyan?: A megoldás az egyes funkciók mőködésének részletes megtervezése Szőkebben: a felhasználói felület, párbeszédek részletes megtervezése minden elıtér-funkcióhoz. Tágabban: részletes eseménymodellek, a rendszer és a környezete interakcióinak megtervezése A technikai környezet sajátosságainak, korlátainak figyelembe vétele Konkrét adatbáziskezelı rendszer képességeit kihasználó és korlátait figyelembe vevı tervezés Operációs rendszer, programnyelv, fejlesztı környezet, üzemeltetı környezet sajátosságait figyelembe vevı tervezés A párbeszédeszközök, konkrét kommunikációs kapcsolatok sajátosságait figyelembe vevı tervezés táblázat: A rendszertervezés szintjei és vetületei a hagyományos strukturált szemlélet szerint

38 178 INFORMATIKUS SZAKMAI ISMERETEK A szintek és a vetületek részletes tárgyalása helyett álljon itt a megkülönböztetésüket indokló két érv: Ha a rendszert át kell tenni egy másik operációs rendszerre vagy egy másik adatbáziskezelı rendszer fölé, akkor csak a fizikai szintő tervezést kell megismételni. Egy adatszerkezetet az adatvetületben magában egyszer kell megtervezni, nem annyiszor, ahány feldolgozás (funkció) azt használja, kezeli. Más szempontból megkülönböztetik a rendszer vagy a szoftver nagyvonalú tervezését és a szoftver részletes tervezését (lásd a szakaszban a fejlesztési folyamat ISO szerinti tevékenységeit). Az objektumorientált technológiák (lásd a és a szakaszokban) elterjedése a problémáknak és a megoldásoknak a táblázatnál kifinomultabb osztályozását teszi szükségessé. Például a Sun Microsystemsnél kidolgozott SunTone módszertan [Sun-2002] [Sun-2007] a ábra szerinti osztályozási sémát javasolja. Eszerint a rendszert olyan alapkomponensekbıl kell felépíteni, amelyek külön-külön egyértelmően adott szinthez, adott réteghez tartozó feladatot oldanak meg, és adott minıségért felelnek ábra: A SunTone módszertan 3 dimenziós osztályozási sémája [Sun-2002] [Sun-2007] A ábrán a szintek egymásra épülı megoldásokat jelentenek: Legalul van a hardver. Ezen a szinten arról kell dönteni, milyen típusú gép lesz a kliens-munkaállomás, a webszerver, illetve az adatbázisszerver.

39 INFORMÁCIÓRENDSZER FEJLESZTÉSE 179 A következı szint az alsó platform, konkrétabban az operációs rendszer. Itt meghatározzák az egy-egy hardvercsomóponton futó operációs rendszer típusát (Linux, MS Windows, Unix, ). A felsı platform azt a szoftverkörnyezetet jelenti, amelyikbe a felhasználói alkalmazás beágyazódik. Történetesen a kliens-munkaállomáson valamilyen böngészıre kell gondolni; a webszervergépen valamilyen kiszolgáló alapszoftverre (pl. J2SE), az adatbázisszerveren valamilyen adatbáziskezelı szoftverre. A virtuális platform a rétegeken belüli vezérlési, illetve a rétegek közötti kommunikációs technológiákat takar. (Például: HTML, azután servlet-technológia, azután JDBC adatbáziskapcsolat.) Az alkalmazás szint a kifejlesztendı alkalmazást foglalja magában. Az elıbbiekben felsorolt alsóbb szintek általában készen adott megoldásokat takarnak, tehát nem fejlesztés, hanem kiválasztás tárgyát képezik. Persze, a választás kimenetelét mint az alkalmazás tervezését és kivitelezését meghatározó tényezıt figyelembe kell venni; ha másért nem, hát az alkalmazás szint alacsonyabb szintek felé mutatott interfészeinek kialakítása céljából. A ábra rétegei az alkalmazásnak a telepítés / futtatás helye szerint elkülönülı komponensei. Tehát az egyes komponensek abban különböznek, hogy az eltérı rendeltetéső csomópontok kliens-munkaállomások, webszerver, a webszerver mögé szervezett alkalmazásszerver(ek) vagy az adatbázisszerver közül melyiken futtatandók. Mivel a kliens-komponens dolga a HTML-lapok (és abból kezdeményezett egyéb effektek) megjelenítése, külön magyarázatra szorul a kliensréteg és a megjelenítési réteg megkülönböztetése: Nos, itt a megjelenítés a megjelenítendı HTML-lapok dinamikus összeállítását takarja, ami a webszerver(ek) feladata. Az üzleti logika a webszerveren vagy a webszerver mögé szervezett alkalmazásszerver(ek)en futó komponenseket jelent. Ebben a kontextusban az integráció rétegnek semmi köze nincs a szakaszban tárgyalt integrációhoz, azaz a modulok szoftverré, illetve rendszerré integrálásához, hanem az üzleti logika és az adatforrás (= adatbázis) közötti kommunikáció megoldását takarja. A rendszerminıségek dimenzióban a minıségek SunTone módszertan szerinti fıbb csoportjai láthatók (ezek nincsenek teljesen összhangban a szakaszban tárgyalt minıségi kategóriákkal). A felhasználói minıségek (eredetiben kézzelfogható manifest minıségek) csoportba tartoznak például a teljesítmény, a megbízhatóság, a rendelkezésreállás, az elérhetıség. A mőködési minıségek csoport elemei például a szolgáltatási hasznosság, a biztonság. A fejlesztıi minıségek elemei például a megvalósíthatóság, a ráfordítások tervezhetısége. Fejlıdési minıségek például a skálázhatóság, a bıvíthetıség, a rugalmasság Az objektumorientált megközelítési mód Az elızı szakasz arról szólt, hogy a legkülönfélébb szoftverfejlesztési technológiákat általánosságban két cél vezeti: a komplex rendszerek kezelhetıvé tétele, valamint a végtermék fejlesztési és megtérülési minıségének javítása. Mivel mindezidáig e célok elérése a szakaszban már említett objektumorientált (OO) technológiának (módszertannak, megközelítési módnak) sikerült a legjobban, ezért itt egy rövid bevezetés következik az OO technológiába. (A téma mélyebb tárgyalása több szemesztert kitöltı külön tantárgyat képez.) Az objektumorientált elemzési, tervezési módszertanok az OO programozási módszertanból fejlıdtek ki, a programozás fogásait általánosították, terjesztették ki tervezést szervezı elvekké. Az OO programozás ısének az 1960-as években megjelent Simula nyelvet tartják [Dahl-1966]. Ezt speciális célra, véletlen folyamatokat szimuláló programok írására fejlesztették ki, és alapelveiben hasonlított a mai OO nyelvekhez. Lényegében a Simula koncepcióját vitték tovább a Xerox PARC (Paolo Alto Research Center) kutató központjában a tisztán

40 180 INFORMATIKUS SZAKMAI ISMERETEK objektumorientált Smalltalk nyelv kifejlesztıi. Az 1970-es években kétévente állt elı a Smalltalk nyelv újabb verziója, de közülük az évtized végére megjelent Smalltalk-80 volt az elsı, amely szélesebb körő ismertségre tett szert [Goldberg-1984]. Az 1980-as évek elején fejlesztette ki a C++ nyelvet Bjarne Stroustrup az AT&T Bell laboratóriumban; ez a nyelv nagyszámítógépeken 1985 óta, PC-ken 1988 óta rendelkezik fordítóprogrammal. A C++ az alapszoftverek és a platformfüggetlen alkalmazások fejlesztésében az OO programozás legelterjedtebben használt nyelvévé vált. Az üzleti alkalmazások fejlesztésében mára már nála is népszerőbb a szigorúan objektumorientált Java nyelv (fejlesztı: Sun Microsystems, Inc., az elsı változat megjelenése: 1993). Az OO elemzési, tervezési módszertanok létrejötte az 1980-as évek második felére tehetı, kialakulásuk kitüntetett mérföldkövei az ACM (Association of Computing Machinery) által szervezett és 1986 óta évente megtartott OOPSLA (Object-Oriented Programming Systems, Languages, and Applications) konferenciák. Az 1980-as évek végén, az 1990-es évek elején már OO elemzést és tervezést tárgyaló könyvek egész sora jelent meg [Shlaer-1988], [Coad-1990A], [Coad-1990D], [Rumbaugh-1991], [Booch-1991], [Jacobson-1992]. A hagyományos módszertanok közös jellemzıje, hogy az adatokra és az eljárásokra külön-külön egymástól elszigetelten képezik az absztrakció és az újrafelhasználás egységeit. Az elkülönítve konstruált összetett adatstruktúrák és összetett mőveletek (eljárások) nem képezhetik az elrejtés és az újrafelhasználás tökéletes egységeit, mert külön-külön nem alkotnak zárt, önjáró integritást, hiszen mindegyikbıl hiányzik valami: az absztrakt adatszerkezet mellıl hiányoznak az azt kezelni hivatott mőveletek, az absztrakt mőveletek mellıl hiányoznak a tárgyukként feltételezett adatok. A hiányzó részekrıl mindig a környezetnek (a környezetet kialakító programozónak) kell gondoskodni. A hagyományos megoldások ilyen fogyatékosságokban szenvedı absztrakt egységeinek (moduljainak) a szükségesnél többet kell feltételezni a környezetükrıl, illetve a környezetüknek a szükségesnél több ismerettel kell rendelkezni a hagyományos modulokról. Ezzel szemben az OO-megközelítés objektuma olyan konstrukció, amely egy egységbe zár egy adatszerkezetet (az objektum szerkezetét) és az azt kezelı (összetett) mőveleteket (az objektum viselkedését). A szerkezet és a viselkedés ilyen egysége a lehetséges legkevesebbet feltételezi a környezetérıl; következésképpen elmondható, hogy az objektum megjelenésével már nemcsak az alkalmazás vagy a rendszer egésze képez integritást, hanem az egyes objektumok is. Az objektum fogalma Az objektum (object) a módszertan felıl közelítve olyan konstrukció, amely egy egységbe zár egy adatszerkezetet és az azt kezelı mőveleteket (eljárásokat vagy az OO programozás terminológiája szerint metódusokat). A modellezett világ felıl közelítve az objektum a legkülönfélébb jelenségek (dolgok, tárgyak, események, fogalmak stb.) olyan modellje, amely magában foglalja vagy ha kell, magába rejti a jelenség szerkezetét (értsd az azt jellemzı adatokat, komponenseket egy szóval: attribútumokat), valamint a viselkedését (értsd a rajta végezhetı mőveleteket). A ábra példaként egy bankszámlát mutat mint objektumot. bankszámla bankszámlaszám számlatulajdonos-név pénznem kamatláb egyenleg befizetés kivétel kamatjóváírás kamatterhelés egyenleg-lekérdezés attribútumok, azaz a szerkezet mőveletek (metódusok), azaz a viselkedés ábra: Az objektum mint szerkezet és viselkedés egysége

41 INFORMÁCIÓRENDSZER FEJLESZTÉSE 181 A szerkezetet és a viselkedést együttesen az objektum (a késıbbiekben az objektumosztály) definíciójának vagy sémájának nevezzük. Attribútum Az attribútum (attribute) az objektum valamilyen jellemzıje vagy komponense, különféle típusú (egyszerő vagy összetett) adatot jelenthet. Egy konkrét objektum attribútumai valamilyen konkrét értéket vesznek fel. Közülük egyesek idıben megváltozhatnak (mint pl. az egyenleg). Egy objektum pillanatnyi belsı állapotán az attribútumai aktuális értékeinek együttesét értjük. Mővelet (metódus) A mővelet (operation, method) alatt az attribútumokon végzett összetett mőveletet kell érteni, amely megvalósítására a fejlesztés során valamilyen eljárást kell programozni. Az elrejtés elvének megfelelıen a külvilág számára csak az (lehet) fontos, hogy az egyes mőveletek mit csinálnak, és közömbös, hogyan csinálják. Másképpen szólva a külvilág számára közömbös a mőveletek belsı megvalósítása. Ez a gyakorlatban azt jelenti, hogy az objektum környezete nem feltételez semmit a mőveletek megvalósításáról, azaz a mőveletek bármilyen környezetben változtatás nélkül felhasználhatók; másrészt a mőveletek megvalósítása anélkül kicserélhetı, hogy azt az objektum környezete érzékelné, és ezért az is változtatásra szorulna. A metódus kétféle értelmezése: Az OO módszertan korábbi irodalma a mővelettıl (operation) megkülönböztette a metódust (method), amin kifejezetten a mővelet megvalósítását értette. (Ilyen értelmezés szerint lehet igaz az az állítás, hogy az elrejtés elvének tökéletes érvényesítése esetén az objektummőveletek metódusa kicserélhetı anélkül, hogy a külvilág számára az objektum viselkedése megváltozna.) Újabban az OO elemzés és tervezés irodalma nem ennyire következetes, a szerzık gyakran használják a metódust a mővelet egyszerő szinonimájaként; a programozásban pedig a metódus alatt olyan eljárást értenek, amely tagja valamely objektumosztály definíciójának (lásd alább). Az objektumok osztályozása, az osztály fogalma Két objektum azonos típusú, ha mindegyiket az attribútumoknak azonos halmaza (azonos szerkezet) jellemzi, továbbá mindegyiken a mőveleteknek azonos készlete értelmezhetı. Az azonos típusú objektumok egy osztályt (class) alkotnak. Az osztály egyrészt a bele tartozó objektumok halmaza, másrészt olyan absztrakció, ami az azonos típusú objektumok közös szerkezetét és közös viselkedési módját képviseli, azaz a példányainak közös sémája. Valamely osztályba tartozó objektumot, az adott osztály példányának (instance) szokás nevezni. Egy konkrét bankszámla objektum a Bankszámla osztály egy példánya. A fejlesztés során többnyire az objektumok típusait, tehát az osztályokat tervezzük. Ennek az az oka, hogy az azonos típusú objektumokra elegendı egyszer meghatározni a közös szerkezetet, illetve azt, hogy mit csinál valamely közös mővelet. Az eddigiek alapján elmondható, hogy pl. a Bankszámla osztálynak azért attribútuma az egyenleg, mert az osztály minden példányának (minden bankszámlának) van egyenlege. Hasonlóan a Bankszámla osztálynak azért mővelete a kamatjóváírás, mert ez a mővelet minden (a kamatjóváírás feltételét teljesítı) bankszámlára értelmezhetı. Egy osztály definíciójába (sémájába, felelısségébe) pontosan azok a mőveletek tartoznak, amelyekkel közvetlenül elérhetık (lekérdezhetık, változtathatók) az adott osztályú objektumok attribútumainak értékei. (Szigorúan OO környezetben, például egy szigorúan OO programnyelvben nem is léteznek önálló eljárások, hanem csak olyanok, amelyek valamely osztály metódusai. Ezt másképpen úgy mondják, hogy minden eljárásért felelıs valamely osztály.) UML-ben

42 182 INFORMATIKUS SZAKMAI ISMERETEK (lásd a szakaszban) az osztályok definíciója az osztályok közötti relációkkal együtt osztálydiagramon ábrázolható. (Lásd például a ábrát!) Osztály Bankszámla bankszámlaszám számlatulajdonosnév pénznem kamatláb egyenleg befizetés kivétel kamatjóváírás kamatterhelés egyenleglekérdezés Példányosítás ábra: Osztály és példánya Objektum (példány) az osztályból bankszámla1:bankszámla bankszámlaszám: számlatulajdonosnév: Kiss József pénznem: HUF kamatláb: 15 egyenleg: Példányosítás Egy osztály példányosítása azt jelenti, hogy létrehozunk egy, az adott osztályba tartozó objektumot. A példányosítás során az osztály attribútumaiból is létrejön saját példány az adott objektumra. Ez természetes is, hiszen a Bankszámla osztály különbözı példányainál másmás értéket vehet fel pl. az egyenleg attribútum. A mőveletek (metódusok) példányosulásáról nem abban az értelemben beszélhetünk, hogy a mőveletekbıl (azok eljárásából) az osztály minden példányára saját másolat jönne létre. (Ez pazarlás lenne.) A mővelet példányosítása csak azt jelenti, hogy az osztály adott mőveletét hivatkozással éppen az osztály adott példányával kapcsoljuk össze (az adott példányra hajtatjuk végre). Másrészt egy objektum csak azokat a mőveleteket hajlandó végrehajtani, amelyeket az osztályára nézve definiáltunk (azaz csak az osztálya sémájához tartozó mőveleteket). Megjegyzés: Az OO technológia egy osztály definícióján belül megkülönböztet példányattribútumot és nem példányosodó osztályattribútumot, valamint példánymőveletet és nem példányosodó osztálymőveletet. Azonban a téma bevezetı jellegő tárgyalásában ilyen megkülönböztetéssel nem élünk, osztályattribútumokkal és osztálymőveletekkel itt nem foglalkozunk. Egyébként a példányosításra vonatkozó fentebbi állítások a példányattribútumokra, illetve a példánymőveletekre igazak. Példaként tekintsünk a Bankszámla osztályból egy bankszámla1 objektumot (4.13. ábra)! Ha történetesen a bankszámla1 objektumra kell végrehajtani a kamatjóváírás mőveletet, akkor azt a bankszámla1.kamatjóváírás() alakú hivatkozással, általában pedig objektum.mővelet(paraméterek) alakú példányosító hivatkozással írjuk le. A példányosítás az újrafelhasználás egyik esete, hiszen minden új példány létrehozása felhasználja az osztállyal adott közös sémát. Meg kell jegyezni, elıfordulhat, hogy azonos osztályú két objektum mindegyik attribútuma azonos értéket vesz fel, a két objektum mégsem azonos. Tehát, ha egy objektumot tökéletesen lemásolunk, akkor is egy másik objektumot hozunk létre. Mindebbıl az következik, hogy az objektum nem azonosítható valamely attribútumának értékével. Minden objektumnak van egy belsı (a felhasználó által nem manipulálható) azonosítója, ami az objektum memóriába elhelyezésekor egy mutatóra (végeredményben az objektum memóriacímére)

43 INFORMÁCIÓRENDSZER FEJLESZTÉSE 183 képezıdik le. Amikor a program a memóriában végez mőveleteket egy objektummal, azt a mutatója alapján éri el. Az objektum(osztály)ok konstruálása sok hasonlóságot mutat az adatmodellezéssel. Azonban akik a relációs adatmodellezés felıl próbálják megérteni az OO technológiát, észre kell venniük, hogy az osztály és az egyedtípus fogalmak minden hasonlóságuk ellenére lényeges vonásokban különböznek. Eddig két lényeges különbséggel találkoztunk: 1. Az egyedtípus sémája csak attribútumokat tartalmaz, az osztály sémája viszont az attribútumokon felül mőveleteket is. 2. Az objektum az egyedtıl eltérıen nem azonosítható valamelyik attribútumának értékével. Így a bankszámla objektum bankszámlaszám attribútuma is csak az alkalmazás felhasználóinak szólóan azonosítja a bankszámlát, az alkalmazáson belül nem azonosítja a bankszámla objektumot. Egy osztály definícióján belül speciális mővelet a konstruktor. Konstruktorral adott osztályból egy új objektumot (példányt) lehet létrehozni, azaz a konstruktor példányosítja az osztályt. Közelebbrıl ez azt jelenti, hogy a konstruktor a memóriában lefoglalja azt a helyet, amelyben az objektum tárolódik, és beállítja az objektum kezdeti állapotát, azaz az objektum attribútumainak kezdeti értékét. Általánosítás és specializáció Ha több osztály sémája közös résszel (attribútumok és mőveletek közös halmazával) bír, akkor definiálható egy általánosabb osztály, azaz fıosztály (superclass), amelynek sémája azonos az elıbbiek, azaz az alosztályok (subclasses) sémájának közös részével, a példányhalmaza pedig az alosztályok példányhalmazának egyesítése. Ez az általánosítás megfelel annak az absztrakciónak, ahogy a biológus a halak, a madarak, az emlısök stb. általánosításaként megalkotta a gerinces állatok fogalmát. Ha egy osztály (fıosztály) bizonyos példányai különösek abban az értelemben, hogy azokat vagy valamilyen plusz attribútum is jellemzi, és/vagy valamilyen plusz mővelet is értelmezhetı rájuk, és/vagy valamely mővelet másképpen hajtható végre rajtuk, akkor megalkotható e speciális példányokat tartalmazó szőkebb osztály (alosztály). Például adott a tárgyi eszközök osztálya, amelyen belül elkülönítjük az ingatlanok osztályát. A modell ilyen finomítását nevezzük specializációnak. Az általánosítás és a specializáció éppen ellenkezı irányú konstrukciós mőveletek, de bármelyiket alkalmazzuk, jelen van az ellenkezıje is. Ugyanis mindenképpen létrejön fıosztály és alosztály, és közülük az elıbbi az általánosítást, az utóbbi a specializációt hordozza magában. Az általánosítás/specializáció viszony szimbóluma egy háromszögcsúcsban végzıdı nyíl, ami az alosztálytól a fıosztály felé mutat (lásd a ábrán). Az öröklıdés fogalma Az öröklıdés egy, a specializáció mentén alkalmazott mechanizmus: Ha egy B osztály alosztálya valamely A osztálynak, akkor a B osztály automatikusan rendelkezik az A osztály minden példányattribútumával és példánymőveletével (másképpen megörökli azokat), így a modellben közvetlenül a B osztályra csak az A osztály definícióján felüli attribútumokat és/vagy mőveleteket kell definiálni. Ebben az értelemben a fıosztályt másképpen szülı (ıs) osztálynak, az alosztályt pedig az elıbbi utódjának vagy leszármazottjának nevezzük. Az öröklıdés viszony szimbóluma értelemszerően azonos az általánosítás/specializáció viszonyéval. A ábrán a fıosztály a TárgyiEszköz, az alosztály pedig az Ingatlan mint speciális tárgyi eszközök osztálya. Az Ingatlan osztály megörökli a TárgyiEszköz összes attribútumát és mőveletét, azon felül további attribútumokkal is rendelkezik.

44 184 INFORMATIKUS SZAKMAI ISMERETEK TárgyiEszköz leltári szám bruttó érték nettó érték leírási mód leírási kulcs értékcsökkenés() Ingatlan helységnév helyrajzi szám terület fıosztály (szülı osztály) Az alosztály tényleges teljes sémája (az örökölt + saját) alosztály (utód osztály) Ingatlan leltári szám bruttó érték nettó érték leírási mód leírási kulcs helységnév helyrajzi szám terület értékcsökkenés() ábra: Az általánosítás / specializáció viszony és az öröklıdés Megjegyzés: A konstruktor mővelet nem örökölhetı. Így a ábra példájában csak azért igaz, hogy az Ingatlan osztály a TárgyiEszköz összes mőveletét megörökli, mert az ábrán nem tüntettük fel a konstruktorokat. Az öröklıdés kapcsán azt is észre kell venni, hogy az OO megközelítés a gyakorlatban feltételez egy olyan fejlesztı környezetet, amely az akár több szinttel megelızı ısök sémájából képes összerakni az utódosztály teljes sémáját. Az öröklıdés az újrafelhasználás egy újabb esete. Az utódosztályban felhasználjuk a szülı osztály struktúráját és viselkedését. Másképpen szólva az utódosztályok osztoznak a szülı osztály által hordozott közös sémán. Mindez a gazdaságos (munkatakarékos) tervezést támogatja, redundanciamentes tervet eredményez, annak minden kedvezı következményével együtt: megbízhatóság, könnyebben (olcsóbban) karbantartható termék (lásd a szakaszban). Polimorfizmus (többalakúság) A polimorfizmus (többalakúság) azt jelenti, hogy azonos (példány)mőveletnek különbözı osztályoknál különbözı megvalósításai (implementációi) lehetnek. A szakirodalomban a polimorfizmusra igen változatos definíciók találhatók. [Rumbaugh-1991]-ben lényegében az ittenivel egyezı értelmezéssel találkozunk. A legtágabban azt a tényt értik polimorfizmus alatt, hogy egy alosztály példánya egyben példánya az összes (közvetlen és közvetett) fıosztályának / ısosztályának is. Ez a meghatározás azonban semmi pluszt nem tesz hozzá ahhoz, amit a fıosztály-alosztály viszonyról eddig is kézenfekvıen feltételeztünk. Hasznosabbak, de inkább csak a programozók számára értelmezhetık az egyes OO programnyelvek kézikönyveiben adott definíciók. Így a Java nyelv leírásában [Nyékiné-2001] alkalmazott terminológia szerint a polimorfizmus azt jelenti, hogy ha egy v változót a forráskódban (egyben fordítási idıben) C osztályúnak deklaráltunk, akkor a v futási idıben a C bármely alosztályához tartozó objektumot hivatkozhat (jelenthet). Eszerint megkülönböztetik a változók sztatikus típusát (ami a forráskódban deklarált típust jelenti) és a dinamikus típusát (ami a futási idıben felvett típust jelenti). Az elmondottakból következik, hogy a dinamikus típus vagy azonos a sztatikus típussal, vagy egy abból leszármazott (utód) típus (osztály) lehet. A polimorfizmus elvét tulajdonképpen már a specializáció fogalmának definíciójában elırevetítettük, amikor egy alosztály elkülönítésének okaként azt is megengedtük, hogy az alosztály példányaira valamely mővelet másképpen hajtódik végre.

45 INFORMÁCIÓRENDSZER FEJLESZTÉSE 185 A polimorfizmus koncepciójának elıfeltétele az a felfogás, hogy egy mőveletet (funkciót) az határozza meg (különbözteti meg más mőveletektıl), hogy mit csinál, azaz milyen bemenetekre milyen kimenetekkel reagál. Tehát két mővelet attól még lehet azonos, hogy a reakció belül más mechanizmussal áll elı, azaz a funkció akkor is azonos maradhat magával, ha a transzformációt máshogyan csinálja. Például akár egy téglalap, akár egy háromszög, akár egy kör területét számítjuk ki, a fenti értelemben azonos mőveletet, t.i. mindegyik esetben területszámítást végzünk. Mindegyik esetben a bemenet valamilyen mérhetı kétdimenziós idom, a kimenet pedig egy valós szám; és ha ez a szám mindhárom esetben azonos, akkor biztosak lehetünk benne, hogy mindhárom idom azonos mennyiségő festékkel festhetı be. Ugyanakkor közismert, hogy ezen idomok területét más-más képlet szerint célszerő számolni; bár alkalmazhatnánk egy általános, közös képletet is (valamilyen integrálközelítı összegét), de az esetleg nem volna hatékony megoldás. A polimorfizmus birtokában a fejlesztı megmenekül attól a kényszertıl, hogy azonos mővelet különbözı megvalósításait más-más névvel kelljen ellátnia. Következésképpen az alkalmazás tervezıjének, programozójának nem kell arra figyelnie, hogy adott mőveletnek mikor melyik nevő változatát kell éppen használni; az alkalmazást nem kell módosítani azért, mert benne valahol a mővelet egyik változatát újabban más nevő változatra kell cserélni. Végeredményben a polimorfizmus tökéletessé teszi a felszínre nem tartozó részletek elrejtését, ezért nagyon nagy a jelentısége az OO alkalmazások szilárdságának megalapozásában (lásd a szakaszban). A polimorfizmust nem ismerı hagyományos fejlesztıi környezetben jellemzı a következı programkód: idoma: Téglalap; idomb: Kör; IF Tégla_Terület(idomA) < Kör_terület(idomB) THEN Ugyanennek OO változata: idoma: Téglalap; idomb: Kör; IF idoma.terület() < idomb.terület() THEN Az elıbbi (hagyományos) kód érzékeny arra, ha utóbb egy téglalap helyett kört (vagy fordítva) kell venni. Az OO kódot viszont akkor sem kell módosítani, ha a feladat változása miatt valamelyik objektum (pl. idoma) egy késıbb definiált osztályba (pl. háromszög) tartozik. A példa kapcsán arra is fel kell hívni a figyelmet, hogy nem csak formai, hanem komoly elvi különbség is van a Tégla_Terület(idomA) idoma.terület() hivatkozások között. A Tégla_Terület(idomA) hivatkozás esetén a program futásakor elindul a Tégla_Terület eljárás, és ez fogja értelmezni az idoma paramétert. Ha történetesen az idoma nem téglalap, hanem kör (széle, hossza helyett csak sugara van), akkor az eljárás nem tud vele mit kezdeni, a program hibaüzenettel elszáll. Egy OO futtató környezetben az idoma.terület() hivatkozásból elıször az idoma objektumhivatkozás értelmezıdik, majd a Terület() mőveletnek automatikusan az idoma osztályának megfelelı változata (megvalósítása, implementációja) hívódik meg. A polimorfizmus a többféle implementációval (megvalósítással) rendelkezı mőveletek esetén az objektumok és a mővelet-megvalósítások dinamikus összerendelését kívánja meg, azaz a gyakorlatban feltételez egy olyan futtató környezetet, amely egy objektum.mővelet()

46 186 INFORMATIKUS SZAKMAI ISMERETEK alakú hivatkozás esetén a mőveletnek azt az implementációját fogja elindítani, ami az objektum osztályának éppen megfelel. Az elrejtés mellett a polimorfizmusnak van egy másik hasznos következménye is: megkönnyíti olyan szoftverek fejlesztését, amelyek nem csak egy-egy speciális problémára, hanem hasonló típusú feladatok egész sokaságára adnak megoldást. Azonban ennek megértéséhez a programozással is mélyebben meg kellene ismerkedni, ami azonban csak egy másik tantárgy témája lehetne. Absztrakt mővelet Egy osztály valamely mővelete absztrakt, ha az adott osztályban a mőveletnek csak specifikációja van (mit csinál), de megvalósítása (hogyan csinálja) nincs, azaz a mőveletnek csak az adott osztály utódosztályai határozzák meg a megvalósítását. (Az absztrakt mőveletet UML-ben dılt betős mőveletnévvel vagy az {abstract} megszorítással jelölik meg.) A modellben az absztrakt mőveletek alkalmazását egyéb, késıbb tárgyalt okok mellett olyan osztályok létezése magyarázza, amelyeknek mindegyik elemére értelmezhetı egy adott mővelet (ezért ennek az általános osztálynak a szintjén kell az adott mőveletet specifikálni), de a mővelethez nem határozható meg olyan közös megvalósítás, amely az osztály minden példányára mőködıképes lenne (ezért alosztályonként különbözı megvalósítást kell az adott mővelethez adni.) Például a mérhetı kétdimenziós idomok osztályára megvalósítás nélkül specifikáljuk a területszámítás mőveletet (így jelezzük, hogy minden mérhetı kétdimenziós síkidomra értelmezhetı a területszámítás), majd ezen osztály háromszög alosztályánál, téglalap alosztályánál stb. adunk ehhez a mővelethez (alosztályonként más) megvalósítást. Az absztrakt mővelet fogalma nem létezhetne a polimorfizmus nélkül, mivel a polimorfizmus teszi lehetıvé, hogy egy C osztály sémájában megvalósítás nélküli mővelet a C valamely alosztályában kapjon megvalósítást. Absztrakt osztály, konkrét osztály és interfész (osztály) Egy (példányosodó 3 ) osztály akkor absztrakt osztály, ha nincsenek közvetlen példányai (csak olyan példányai lehetnek, amelyek valamely alosztályának is példányai. Ezzel egyenértékő meghatározás: absztrakt osztály az (a példányosodó osztály), amelynek van legalább egy absztrakt mővelete. Minden nem absztrakt osztály konkrét osztály. (Az absztrakt osztályt UML-ben dılt betős osztálynévvel vagy az osztály neve után/alatt álló {abstract} megszorítással jelölik meg.) Az, hogy egy absztrakt osztálynak nem lehet közvetlen példánya, a programozó számára így jelentkezik: Deklarálhat ugyan egy olyan objektumváltozót, amelynek a típusa egy absztrakt osztály, de a változóba csak olyan objektumot tehet, amelynek a típusa az elıbbi absztrakt osztály utódjának számító konkrét osztály. Az általánosítás és a specializáció eredményeként az osztályhierarchia tetején szükségképpen jönnek létre olyan absztrakt osztályok, amelyeknek csak az a szerepük, hogy a szerkezetüket és a viselkedésüket továbbadják az utódosztályoknak. Az osztályhierarchia legalján 3 Léteznek nem példányosodó osztályok is, de velük itt nem foglalkozunk. Egy nem példányosodó osztálynak csak osztályattribútumai és osztálymőveletei vannak, és közvetlenül az osztály képez mőködı programegységet. Azonban szemben ez a tankönyv csak olyan osztályokkal foglalkozik, amelyeknek a példányai a mőködı egységek, az osztály pedig csak a példányok közös sablonját képezi.

47 INFORMÁCIÓRENDSZER FEJLESZTÉSE 187 álló (levélszintő) osztályok szükségképpen konkrét osztályok, de nem csak a levélszintő osztályok lehetnek konkrétak, sıt konkrét osztálynak lehet absztrakt alosztálya is. Azokat a nagyon absztrakt osztályokat, amelyeknek csak absztrakt mőveletei léteznek, és nincsenek attribútumaik (Javaban konstans attribútumok megengedettek) interfésznek nevezik. Az OO technológia további elemi Az OO technológia szemlélete szerint a program nem csupán utasítások sorozata, hanem egy olyan mőködı szerkezet, amelynek alkatrészei az objektumok, és a program végrehajtása, az alkatrészeit képezı objektumok együttmőködése, kommunikációja útján realizálódik: az egyik objektum valamilyen mővelet végrehajtására kéri fel a másikat, vagy kérdez valamit a másiktól; az utóbbi végrehajtja a kért mőveletet, illetve válaszol a kérdésre. Az objektumok ugyanúgy kapcsolatban állhatnak egymással, mint az adatmodellezésben az egyedek (lásd a 2.7. alfejezetben), azonban a két esetben a kapcsolatok létezésének egészen más indokai vannak. Az adatmodellezésben két egyed kapcsolata az egyik egyeddel viszonyban álló másik egyed elérését navigáló konstrukció; az OO technológiában viszont két objektum kapcsolatáról akkor beszélünk, ha az elıbbi bekezdésben említett együttmőködésben az egyik objektum használja a másikat (kommunikál a másikkal). Az OO technológia itt megemlített összetevıi azonban már csak érintılegesen, a 4.5. alfejezetben tárgyalt modellezési technikák magyarázatának részeként kerülnek szóba. (A megértésük egyébként is komolyabb programozói elıtanulmányokat feltételezne.) A következı szakasz bemutatja az objektumok belsı szerkezetét és az objektumok közötti kapcsolatok (típusszinten az osztályok közötti viszonyok, asszociációk) modellezésére alkalmas objektumdiagram, illetve osztálydiagram technikákat (összefoglaló névvel: statikus modellezési technikákat); továbbá az objektumok együttmőködésének vagy az egyes objektumok állapotváltozásainak leírására alkalmas (és ezzel az objektumok viselkedésének kiderítését szolgáló) dinamikus modellezési technikákat A tervezés termékei Az elızı szakaszban tárgyalt OO technológia egyfelıl a tervezésben és a kivitelezésben megtörte a strukturált megközelítésre jellemzı szigorú hierarchikus rendet, mivel az objektumok a tartalmazás tekintetében nem alkotnak hierarchiát (a kivitelezés kapcsán errıl a és szakaszokban is lesz szó); másfelıl az adatszerkezet és a mőveletek egységbe zárásával módosította az adattervezés és a feldolgozástervezés elkülönült lebonyolítására vonatkozó elképzeléseket (lásd a táblázatot). Azonban korlátozott mértékig mind a hierarchikus terméklebontás, mind a feldolgozásvetület és az adatvetület elkülönülése (4.10. táblázat) napjainkban is fennmaradt (mint azt az ISO szabvány is tükrözi 4.1. ábra), és ezek a tervezés termékeiben is tükrözıdnek. Ami a hierarchiát illeti, változatlanul tovább él egy rendszer > alrendszer (=alkalmazás) > magasabb szintő modul hierarchia (még akkor is ha ez lejjebb, az objektumok szintjén már nem folytatható). Ennek megfelelıen a rendszer szintjén a termékek között megjelenik a nagyvonalú rendszerterv, a rendszerintegrációs teszt specifikációja és a rendszerszintő minıségi teszt specifikációja; alrendszer szinten (az ISO12207-ben szoftver szinten) pedig a nagyvonalú szoftverterv,

48 188 INFORMATIKUS SZAKMAI ISMERETEK a szoftverintegrációs teszt specifikációja és a szoftverszintő minıségi teszt specifikációja; majd lejjebb, a szoftver komponensei szintjén a részletes szoftverterv, az egységtesztek specifikációi (opcionálisan: független tesztelık alkalmazása esetén). Az adatvetület és a feldolgozásvetület elkülönülése (4.10. táblázat) annyiban él tovább, hogy az adatbázis tervezése változatlanul nagy mértékben független a programok tervezésétıl. Így a fentebb vázolt hierarchia nem vonatkozik az adatbázistervezésre, az csupán a végrehajtandó programok tervezésére korlározottan jellemzı. Az elkülönülés fennmaradásában szerepet játszik az a tény is, hogy az üzleti alkalmazások alatt napjainkban is dominánsan relációs adatbázisokat használnak, amelyek tervezési módszerei (a hibrid objektumrelációs adatbázisok létezése dacára is) kilógnak az OO technológiából. A lényeg, hogy a fentebb felsoroltakon felül a tervezés termékei közé tartozik az adatbázisterv (az adatmodell is) méghozzá a táblázat szerinti fogalmi, logikai és fizikai változatokban. Megjegyzés: Az adatvetület és a feldolgozásvetület valamennyire visszaköszön az OO technológiában is: az elıbbinek a sztatikus modellek, az utóbbinak a dinamikus modellek felelnek meg. Ezek azonban a hagyományos technológiák vetületeivel ellentétben nem elkülönült termékek létrehozására irányulnak, hanem azonos termékek, az objektum(osztály)ok különbözı nézıpontú megközelítésére szolgálnak. (Az egyik nézıpontból kapott kép a másik nézıpontból alkotott képet finomítja.) Az alábbiakban röviden ismertetjük a tervtermékek tartalmi elemeit. Adatmodell A fogalmi adatmodell a 2.7. alfejezetbıl ismert tartalmi elemeket tartalmaz, úgy mint: tulajdonságtípusok definícióit, egyedtípusok definícióit, kapcsolatok definícióit és az elıbbiekre vonatkozó megszorításokat. A fenti elemek ERD diagramok, specifikációs őrlapok és kötetlen leírások formájában jelennek meg a tervben. A logikai szintő modell egyrészt olyan tulajdonságtípusok, egyedtípusok és kapcsolattípusok definíciójával és megszorításaival is bıvül, amelyek szükségességére már a végrehajtandó programok tervezése során derül fény (pl. a biztonsági funkciók által igényelt adatok vagy a programmőködés speciális vezérlésére szolgáló adatok); másrészt olyan hatékonyságnövelı elemek definícióival egészül ki, mint az indextáblák és a nézettáblák. A fizikai szintő modell az elıbbieket a konkrét adatbáziskezelı rendszer speciális jellemzıinek, beállításainak megadására szolgáló adatokkal egészíti ki, illetve bizonyos jellemzıket (pl. tulajdonság adattípusa) a konkrét adatbáziskezelı sajátosságainak megfelelıen módosított változatban tartalmaz. Ami a fizikai adatbázisterv formáját illeti, az adatbázis SQL nyelvő definíciója is ilyen fizikai tervnek tekinthetı. Nagyvonalú rendszerterv A nagyvonalú rendszerterv a rendszer felépítésérıl architektúrájáról szól. Egy rendszer felépítése azonban többféle nézıpontból (funkcionális tartalom nézıpontjából vagy az

49 INFORMÁCIÓRENDSZER FEJLESZTÉSE 189 alkalmazott technológia nézıpontjából, ) írható le. A szakirodalom egy része (pl. [Sommerville-2002]) a rendszer bármilyen nézıpontú szerkezettervét architekturális tervnek tekinti, és ilyen felfogásban a teljes nagyvonalú rendszerterv nem más, mint a rendszer architekturális terve. A szakirodalom más része (pl. [Sun-2002]) a nagyvonalú terven belül megkülönböztet architektúratervet (architektúramodellt) és terméktervet, továbbá az architektúraterv fogalmát a rendszernek csak a nem funkcionális követelményekhez és az azok teljesítése céljából felhasznált technológiákhoz alkalmazkodó felépítésére korlátozza (pl. háromrétegő architektúra). A [Sun-2002] terminológiája szerint egy rendszer funkcionális szempontú felépítése (szolgáltatások szerint megkülönböztetett alrendszerekre, modulokra való felbontása) nem architektúramodell, hanem termékmodell. A nagyvonalú rendszerterv tartalmazza a rendszer közvetlen komponenseinek (alrendszereknek, alkalmazásoknak) az absztrakt 4 specifikációját, tehát azt, hogy milyen szolgáltatást nyújt a rendszer a környezetének, és a szolgáltatás milyen interfészen keresztül érhetı el (az interfészekrıl további tudnivalók a szakaszban találhatók.). Az absztrakt specifikációk például használati esetek (lásd a szakaszban), használati eseteket tartalmazó csomagok, illetve csomagdiagramok (lásd a szakaszban) formájában jelenhetnek meg. A nagyvonalú rendszerterv részét képezi. a rendszer verifikálására alkalmas rendszerintegrációs teszt (interfészteszt) specifikációja és a rendszer egészének validálására alkalmas (minıségi) teszt specifikációja is. (Ezekrıl bıvebben a szakaszban tájékozódhat az olvasó.) Megjegyzés: A rendszerintegrációs teszt specifikációjának ilyen korai konkrétan a nagyvonalú rendszerterv részeként való elıállítása egyrészt lehetséges, mert a nagyvonalú rendszerterv minden szükséges információt tartalmaz hozzá, másrészt annyiban szükségszerőség is, hogy az integrációs tesztek több erıforrást és több részvevıt vesznek igénybe, mint az egyszerőbb egységtesztek, és így az elıkészítésük is hosszabb ideig tart. Nagyvonalú szoftverterv A nagyvonalú szoftverterv az alkalmazásszintő (tehát nagy számú, de összetartozó szolgáltatást nyújtó) szoftver magasabb szintő komponensekbıl (modulokból, funkcionális egységekbıl) felépítésérıl szól. Tartalmazza a szoftver azonosított komponenseinek absztrakt specifikációját, tehát azt, hogy milyen szolgáltatást nyújt a komponens a környezetének, és a szolgáltatás milyen interfészen keresztül érhetı el. Az absztrakt specifikációk például az azonosított komponensek közötti tipikus interakciókat mutató szekvenciadiagramok (lásd a szakaszban), használati esetek (lásd a szakaszban), az elıbbieket tartalmazó csomagok, illetve 4 Azért absztrakt, mert a megoldás módjával nem foglalkozik, azaz a komponenseket fekete doboznak tekinti.

50 190 INFORMATIKUS SZAKMAI ISMERETEK csomagdiagramok (lásd a szakaszban) formájában jelenhetnek meg. A nagyvonalú szoftverterv részét képezi. a szoftver verifikálására alkalmas integrációs teszt (interfészteszt) specifikációja és a szoftver validálására alkalmas (minıségi) teszt specifikációja is. Részletes szoftverterv A részletes szoftvertervnek a szoftver legkisebb építıelemeirıl is minden olyan információt (nem csak az absztrakt specifikációját) meg kell adni, amelyre a program kódolóinak szüksége lehet; azaz csak az maradhat fekete doboz, aminek az absztrakt specifikációja is egyértelmően meghatározza a programozó teendıit, vagy amit nem kell megvalósítani, mert korábbi fejlesztésbıl vagy idegen fejlesztésbıl készen átvett (újrafelhasznált) elem. OO technológia esetén a részletes szoftverterv tartalmi elemei a következık: Osztályok definíciói az osztályok attribútumainak és mőveleteinek, valamint más osztályokkal alkotott viszonyainak specifikációjával együtt. Objektumok különbözı szintő összetett kompozícióinak és a kompozíción belüli komponensek együttmőködésének specifikációi. Szigorúan OO nyelvek esetében ez formailag nem különbözik a terv elıbbi pontban adott részétıl, mivel a kompozíciók is valamely osztály példányai (vagy nem példányosodó osztályok). Az összetettség fokának növekedésével azonban a specifikáció felépítése változik, megnövekszik benne a komponensek együttmőködését magyarázó dinamikus modellek szerepe. Ugyancsak az OO technológia esetén a részletes szoftverterv formai elemei a következık: sztatikus modellek: osztálydiagramok, esetleg objektumdiagramok, illetve az ezek elemeihez kapcsolt specifikációs őrlapok és kötetlen leírások (lásd a szakaszban); a kompozíciók (összetett objektumok vagy nem példányosodó összetett osztályok) komponensei közötti kölcsönhatásokat specifikáló, illetve magyarázó dinamikus modellek: kölcsönhatásdiagramok, állapotdiagramok, tevékenységdiagramok (lásd a szakaszban); az elıbbieket tartalmazó csomagok, illetve csomagdiagramok (lásd a szakaszban). A részletes szoftverterv részét képezheti: a szoftveregységek verifikálására alkalmas egységtesztek specifikációi, ha az egységteszteket független tesztelık (is) végrehajtják; kompozíciók integrációs tesztjeinek specifikációja (mivel különösen az OO technológia esetében a részletes tervezés során is definiálódhatnak olyan összetett kompozíciók, amelyeket a nagyvonalú szoftverterv még nem azonosíthatott) Ellenırzı kérdések a 4.4. alfejezethez 1. A szoftverfejlesztés különbözı megközelítési módjait milyen közös általános célok jellemzik? 2. Ismertesse a szoftver fejlesztési és megtérülési minıségi jellemzıit! 3. Mit jelent a modularizálás? 4. Milyen szerepet játszik a modularizálás egy komplex feladat kezelhetıvé tételében?

51 INFORMÁCIÓRENDSZER FEJLESZTÉSE Mit jelent a független problémák elkülönítésének elve? 6. A modularizálás a független problémák elkülönítésének elvével együtt hogyan szolgálja a szoftver fejlesztési és megtérülési minıségi jellemzıinek javítását? 7. Röviden foglalja össze, hogy az általános célok teljesítése és a technológiai alapelvek érvényesítése tekintetében az OO megközelítési mód miben különbözik a korábbi megközelítési módoktól! 8. Az elkülönítve konstruált adat- és eljárásabsztrakciók miért nem képezhetik az elrejtés és az újrafelhasználás tökéletes egységeit? 9. Értelmezze az objektum fogalmát! Jellemezze az objektumot mint az absztrakció egységét! 10. Értelmezze az osztály fogalmát! 11. Mit kell elrejteni az osztály mőveleteibıl, és miért? 12. Értelmezze az osztály példányosítását! A példányosítás mennyiben jelent újrafelhasználást? 13. Mit jelent a mővelet példányosítása? 14. Miben különbözik az objektum azonosítása a relációs adatmodellben alkalmazott egyedazonosítótól (elsıdleges kulcstól)? 15. Mi a konstruktor feladata? 16. Értelmezze az osztályok közötti általánosítást és specializációt! Mondjon példát ezekre a fogalmakra! 17. Értelmezze a fıosztály és alosztály fogalmakat! Mi a kapcsolat egy fıosztály és annak alosztálya példányhalmazai között? 18. Értelmezze az osztályok közötti öröklıdést! Hogyan függ ez össze a specializációval? 19. Az öröklıdés mennyiben jelent újrafelhasználást? 20. Miért jelent hasznos technológiai megoldást az öröklıdés? 21. Értelmezze a polimorfizmust, és mondjon rá példát! Minek az elrejtését teszi tökéletesebbé a polimorfizmus? 21. Szemléltesse példával, hogyan javítja a polimorfizmus az alkalmazás szilárdságát! 22. Értelmezze az absztrakt mővelet és az absztrakt osztály fogalmát! 23. Lehet-e egy konkrét osztálynak absztrakt leszármazottja? 24. Értelmezze az interfész (osztály fogalmát)! Miért hasznos technológiai konstrukció az interfész?

52 192 INFORMATIKUS SZAKMAI ISMERETEK 4.5 Modellezési technikák A tervezés során (de a korábban tárgyalt elemzés során is) a fejlesztık elıszeretettel alkalmaznak grafikus modelleket. Ennek oka az, hogy a grafikus modellekkel (azok kötött jelentéső szimbólumaival) a verbális formánál lényegesen tömörebben és egyértelmőbben lehet leírni akár a felismert összefüggéseket, akár az új konstrukciókat. Persze, a diagramokhoz, illetve azok egyes szimbólumaihoz speciális őrlapokon vagy szabad szöveges formában (a grafikus szimbólumrendszerrel ki nem fejezhetı) jellemzık és leírások is főzhetık. Ezen felül a tervek természetesen tartalmazhatnak tisztán szöveges leírásokat (verbális modelleket is) Az UML modellezési nyelv Ebben a szakaszban az Object Management Group (OMG) konzorcium által gondozott és mára iparági szabványnak számító UML (Unified Modeling Language) modellezési nyelv grafikus modellezési technikáival ismerkedünk meg. Röviden az UML kialakulásáról: Mint azt a szakaszban már leírtuk, az 1990-es évek elejére nem is egy, hanem sokféle OO módszertan született. Ezek mind a hangsúlyozott témákban, mind az életciklus tagolásában, mind az alkalmazott modellezési technikákban (a grafikus modellek jelrendszereiben) különböztek egymástól. Ez a sokszínőség a gyakorlati szakemberek számára az anarchia érzetét keltette: Miközben látszott, hogy le kell mondani a hagyományos módszerekrıl; hogy olyan újabb CASE eszközökre kell átállni, amelyekbe a korábban használt CASE-ekben tárolt rendszerdokumentációk nem menthetık át; senki sem tudhatta, hogy az új irányok közül melyiket érdemes választani. A szakma döntı többsége által elfogadott szabványok hiánya mindig plusz költségekkel és sokféle kockázattal jár. (Költségek: pl. dokumentációk konvertálásának, termékek illesztésének költsége. Kockázat: A cég szakmai megfontolások alapján választ egy irányt, a piac meg a pénzügyi erıvonalak mentén utóbb elmegy egy másik irányba, így a cég üzleti lehetıségei is beszőkülnek és az adott irányú ráfordítások nem vagy nem az elvárt szinten térülnek meg.) A módszertani guruk is érzékelték, hogy a szakma hiányolja az eligazító szabványokat. Az 1990-es évek derekát, második felét a módszerek egységesítésére irányuló törekvés jellemezte. A következı állomások közül az elsı három egymást követı OOPSLA konferenciához főzıdik: 1994: Rumbaugh és Booch szándéknyilatkozata közös OO rendszerfejlesztési módszer kidolgozására 1995: Az OMT és a Booch módszerek egyesítésének vázlata 1996: Csatlakozik Jacobson is. Hárman jelentik be az UML (Unified Modeling Language) modellezési nyelvet. Az UML további fejlıdésében és szabvánnyá válásában jelentıs szerepet játszott az OMG (Object Management Group) konzorcium. 1997: Januárban az UML 1.0, szeptemberben pedig az 1.1 változata megjelenik az Interneten. Ezt követıen egyre több CASE gyártó terméke támogatja az UML-t UML UML 2.0 Sorban jelennek meg az UML újabb verziói 1.2: 1998, 1.3: 1999, 1.4: 2001, 1.5(munkaverzió): [Booch-1998] [Rumbaugh-1998] [OMG-2001] [OMG-2002] (A jelen tankönyvben az UML diagramtechnikáinak tárgyalása nem haladja meg az 1.5 verziót.) Nem véletlen, hogy az UML alkotói modellezési nyelvrıl és nem módszertanról beszéltek. Az UML megmondja ugyan, hogy hogyan lehet leírni az objektumokat, azok kapcsolatait, állapotváltozásait, az objektumok közötti együttmőködést, ha az objektumokat már ismerjük; de nem szól arról, hogyan kell megtalálni ezeket az objektumokat; nem foglalkozik a fejlesztési folyamat felépítésével, azaz hogy milyen tevékenységeket kell végrehajtani és milyen rendben.

53 INFORMÁCIÓRENDSZER FEJLESZTÉSE 193 Az UML részét képezi a szakaszban bemutatott használati eset (Use Case) diagram is. Itt az OO elemzés és tervezés során alkalmazható további modelleket tárgyalunk. Ezek: az objektumdiagram, az osztálydiagram, a szekvenciadiagram, az együttmőködési diagram, az állapotdiagram, a tevékenységdiagram és a csomagdiagram. De mindezeket megelızıen az UML bármely diagramtechnikájában alkalmazható kiterjesztési mechanizmusaival a sztereotípusokkal és a megszorításokkal ismerkedünk meg Sztereotípusok és megszorítások Az UML diagramtechnikáiban megjelenı egy-egy modellelem típusát elsıdlegesen az ıt szabványosan jelölı szimbólum különbözteti meg más típusú modellelemektıl, illetve a modellelemhez a típusától függı jellemzık (metaattribútumok, element properties) adhatók meg. (Az itt említett metaattribútum nem keverendı össze az osztály szerkezetét alkotó attribútumokkal, amelyek maguk is modellelemek. Egy attribútumnak is lehetnek metaattribútumai, például az attribútum neve, láthatósága, típusa.) Azonban a konkrét projektekben egyrészt a modellelemeknek annál többféle kategóriája iránti igény merülhet fel, mint amennyi a szabványos szimbólumokkal kifejezhetı, illetve a modellelemekhez szabványosan rendelteken felül egyéb speciális metaattribútumokra is szükség lehet. Az eszköztár ilyen speciális igények szerinti bıvítését szolgálják a sztereotípusok és a megszorítások. (Harmadik lehetıséget jelent a bármilyen modellelemhez szimbólumokhoz, diagramokhoz főzhetı kötetlen megjegyzés. Azonban a modellelemeknek CASE eszközökkel való automatikus szőrésére, osztályozás szerinti lekérdezésére a megjegyzések alkalmatlanok.) Sztereotípusok A sztereotípusok (stereotype) UML-ben a modellelemek több szempontú osztályozásának, illetve újabb a szabványoson felüli típusú modellelemek képzésének eszközei. Ennek nem mond ellent, hogy az UML számos szabványos, illetve ajánlott sztereotípust kínál (lásd az «include» és az «extend» sztereotípusokat a szakaszban, vagy az «interface» sztereotípust a szakaszban), mert az UML alkalmazója (vagy egy CASE eszköz felhasználója) tetszıleges saját sztereotípust hozhat létre. A sztereotípus neve jelek között áll, és részletezı ábrázolás esetén a modellelem neve elé vagy fölé kell írni, tömör (ikonos) ábrázolás esetén megjelenhet az ikon fölött vagy mellett. Egyes szetereotípusok nem csak névvel, hanem szabványos jellel is rendelkeznek (pl. «entity»); és a jel alkalmazható a sztereotípus neve mellett / helyett, sıt tömör ábrázolás esetén a tipizált modellelem szabványos szimbólumát helyettesítı szimbólumként is (lásd a ábrán). «entity» «entity» Vevı Vevı Vevı Vevı ábra: Az «entity» sztereotípia nevének és/vagy jelének használata

54 194 INFORMATIKUS SZAKMAI ISMERETEK ábra: Az általánosítás / specializáció viszony és a «class» sztereotípus Még az UML szabványos szimbólumainak is vannak sztereotípusai. Például az osztály szimbóluma a ábrákon már látott téglalap, tehát ebben az esetben nem szükséges a szimbólumot még az osztályt jelzı «class» sztereotípussal is ellátni; azonban az UML megengedi, hogy a modellezı bármely szabványos szimbólumot a tetszése szerinti saját szimbólumra (ikonra) cseréljen le, ebben az esetben már csak a sztereotípussal lehet jelezni, hogy az egyedi szimbólum történetesen osztályt jelöl. Erre mutat példát a ábra, amelyen négyféle szimbólum látható, és csak a «class» sztereotípus jelzi, hogy mindegyik osztályt jelöl. Megszorítások A megszorítások (constraint) egy része ugyanúgy alkalmazható a modellelemek tipizálására, mint a sztereotípusok, a kulcsszavas értéknek nevezett megszorítások pedig a modellelemek szabványos metaattribútumokon felüli speciális jellemzıinek megadására szolgálnak. Az UML alkalmazója (vagy egy CASE eszköz felhasználója) tetszıleges saját megszorításokat hozhat létre, de az UML-ben léteznek szabványos megszorítások is (lásd például az {abstract} megszorítást a szakaszban). A megszorítást a vele jellemzett modellelem neve után vagy alá {} zárójelek közé kell írni, mint a ábrán a mennyiség attribútumnév utáni {mennyiség>=0} megszorítást. (De a szimbólumokat összekötı névtelen vonalakhoz is megadható megszorítás.) Ha azonos modellelemre több megszorítás is vonatkozik, akkor azokat egy {} zárójelpáron belül felsorolhatjuk, köztük vesszıt vagy soremelést alkalmazva elválasztásként. A ábrán a megszorítások megadásának különbözı módjai figyelhetık meg, és arra is láthatunk példát, hogy a megszorításnak is lehet sztereotípusa: A {mennyiség>=0} megszorítás a mennyiség attribútumra vonatkozik, a {mennyiség>=kimennyiség} meg-

55 INFORMÁCIÓRENDSZER FEJLESZTÉSE 195 szorítás pedig a mennyiség attribútum és a kimennyiség paraméter viszonyára. Az utóbbi megszorítás az osztályhoz kapcsolt megjegyzés dobozban szerepel, és van sztereotípusa is. A «precondition» sztereotípus azt jelzi, hogy a {mennyiség >= kimennyiség} megszorítás teljesülése elıfeltétele a kiszállítás(kimennyiség) mővelet végrehajtásának. Készlet - cikk - raktár - mennyiség {mennyiség >= 0} + kiszállítás(kimennyiség)... <<precondition>> { mennyiség >= kimennyiség } ábra: Példa megszorítások megadásának különbözı módjaira A fentebb említett kulcsszavas érték (tagged value) megszorításokkal a modellelemek speciális jellemzıi kulcsszó = érték formában adhatók meg. Például: {date = , version = 1.1.3} Sztatikus modellek Azokat a modelleket, amelyek tárgyát a rendszer idıtıl független szerkezeti váza képezi, sztatikus modelleknek nevezzük szemben a dinamikus modellekkel, amelyek viszont a rendszer vagy a rendszer komponensei viselkedésérıl, idıbeli változásairól, a komponensek közötti kölcsönhatásokról szólnak. Az UML modellezési technikái közül az objektumdiagram és az osztálydiagram a sztatikus modellezés eszközei, mivel ezek egyrészt a objektumok/osztályok belsı felépítését és a objektumok/osztályok közötti kapcsolatokat/viszonyokat képesek ábrázolni; de ide sorolhatók a csomagdiagramok is, amelyekrıl azonban csak szakaszban lesz szó. Objektumdiagram Mivel a tervezés tárgyát általában nem az egyes konkrét objektumok, hanem azok osztályai képezik, az objektumdiagram jellemzıen nem a tervezés, hanem az elemzés részeként készül. Tulajdonképpen csak akkor van rá szükség, ha a probléma bonyolultsága miatt a tervezınek gondot okoz az osztálydiagram azonnali megrajzolása, ezért elıbb konkrét objektumok konkrét kapcsolatait rajzolja meg egy (vagy több) objektumdiagramon, és késıbb azokból vonatkoztatja el az objektumok osztályait, valamint az objektumok kapcsolatait típusszinten képviselı asszociációkat, végeredményben pedig az osztálymodellt. Úthálózat példa: A ábra egy úthálózat részletét mutató irányított háló. A csomópontok települések, a nyilak szomszédos településeket összekötı útszakaszok, a nyilak melletti számok az útszakasz hosszát jelölik. Ha két települést csak egyirányú nyíl köt össze (pl. B-E, G-F), akkor az egyirányú útszakaszt jelöl. Az egyirányú útszakaszok miatt a szomszédság nem szimmetrikus, pl. B-nek szomszédja az E, de az E-nek nem szomszédja a B. Ha két település közötti kétféle irányú nyíl mellett csak egy távolság van, akkor az útszakasz oda-vissza ugyanolyan hosszú. Ehhez képest vannak kivételek is, pl. az A-E és a D-F viszonylatok. Az is elıfordulhat, hogy egy útszakasz ugyanabba a városba érkezik, amelybıl kiindult, pl. C-C.

56 196 INFORMATIKUS SZAKMAI ISMERETEK Megszerkesztendı a ábrán mutatott úthálózatot reprezentáló objektumokat tartalmazó objektumdiagram. A diagram az úthálózat olyan modellje legyen, amelyre teljesül: a) Minden településhez képes legyen külön keresés nélkül közvetlenül visszaadni a vele szomszédos településeket. b) Vegye figyelembe, hogy egyes településeknek nagyon sok szomszédja van, másoknak csak egy-kettı, és a szomszédok számának maximuma (a tervezés során) nem határozható meg. c) Tegye egyszerővé az úthálózat változásainak aktualizálását, egy település szomszédai körének bıvítését, vagy szőkítését. A 79 6 C B E 35 D G F A probléma reprezentálására többféle objektummodell képzelhetı el, azonban a ábrán látható modell nem csak azért elhamarkodott, mert a feladat a)-c) feltételeit nem veszi figyelembe, hanem azért is, mert csak a településeket reprezentálja objektummal, az összekötı útszakaszokat viszont csak asszociációk képviselik. Mivel az útszakasznak is van attribútuma, mégpedig a szakasz hossza, szükségképpen az útszakaszt is objektummal kell modellezni. A ábrán már az útszakaszok is objektumok, de még ez a modellrészlet sem tökéletes, mert a feladat a)-c) feltételei közül csak az elsı kettıt teljesíti. (Azért beszélünk modellrészletrıl, mert a diagram csak az A települést és szomszédait mutatja.) ábra: Úthálózat részlete A modell javítását megelızıen tisztázzuk az objektumdiagram jelöléseit: Az objektumokat téglalapok képviselik. A téglalapban minimum az objektum neve szerepel, amely után kettısponttal elválasztva az objektum osztálya (típusa) adható meg (feltéve, hogy az a diagram rajzolásakor már ismert). Mivel az osztály szimbóluma is téglalap, a név aláhúzása jelzi, hogy nem osztályról, hanem objektumról van szó (pl. C:Település). Az objektumok kapcsolatát a kapcsolóvonalak mutatják. A kapcsolóvonal nyíl felıli végéhez szerepnév tapad. Mint a szakaszban volt róla szó, az OO program objektumok együttmőködéseként áll elı. Azonban alapesetben csak a kapcsolatban álló objektumok látják egymást, azaz egy objektum csak a vele kapcsolatban álló másik objektumot tudja felkérni valamilyen mővelet végrehajtására. (Az már nem alapeset, ha az A objektum a vele kapcsolatban álló B objektumtól megkapja egy A-val nem kapcsolódó C objektum mutatóját, és ezáltal a C is látható lesz az A számára.) Egy a b kapcsolat azt jelzi, hogy az a objektum kérheti valamilyen mővelet végrehajtását a b objektumtól. Egy a b kapcsolat esetén a kapcsolatnak a b-hez közeli végén álló szerepnév azt jelzi, hogy az a objektum milyen szerepben látja / használja a b objektumot.

57 INFORMÁCIÓRENDSZER FEJLESZTÉSE 197 object Úthálózat OD R1 -szomszed -szomszed C :Telepules -szomszed -szomszed -szomszed A :Telepules -szomszed D :Telepules -szomszed -szomszed -szomszed -szomszed -szomszed -szomszed B :Telepules F :Telepules -szomszed -szomszed -szomszed -szomszed E :Telepules -szomszed G :Telepules -szomszed -szomszed ábra: A probléma egy elhamarkodott objektummodellje object Úthálózat OD R2 ac :UtSzakasz -szomszed C :Telepules Ez csak egy részlete a teljes objektummodellnek. -irany[1] -irany[2] ad :UtSzakasz -szomszed D :Telepules A :Telepules -irany[3] ab :UtSzakasz -szomszed B :Telepules -irany[4] ae :UtSzakasz -szomszed E :Telepules ábra: A probléma egy jobb modellje, amely azonban nem teljesíti a c) feltételt

58 198 INFORMATIKUS SZAKMAI ISMERETEK object Úthálózat OD -elsoirany ac :UtSzakasz -kovetkezo -kovetkezo -kovetkezo ad :UtSzakasz ab :UtSzakasz ae :UtSzakasz szakaszhossz:=50 szakaszhossz:=65 szakaszhossz:=35 szakaszhossz:=70 -szomszed C :Telepules -szomszed -szomszed D :Telepules -szomszed -szomszed -szomszed -szomszed B :Telepules -szomszed -szomszed E :Telepules -elsoirany -szomszed -szomszed -elsoirany -szomszed -elsoirany cc :UtSzakasz dc :UtSzakasz bd :UtSzakasz -elsoirany ed :UtSzakasz -kovetkezo -kovetkezo -kovetkezo cd :UtSzakasz db :UtSzakasz be :UtSzakasz -kovetkezo eg :UtSzakasz -kovetkezo ca :UtSzakasz fd :UtSzakasz -kovetkezo de :UtSzakasz ge :UtSzakasz -elsoirany -szomszed -kovetkezo -elsoirany -szomszed A :Telepules F :Telepules -szomszed gf :UtSzakasz G :Telepules -szomszed -szomszed -szomszed -kovetkezo -szomszed da :UtSzakasz -kovetkezo df :UtSzakasz -kovetkezo ba :UtSzakasz -kovetkezo ea :UtSzakasz ábra: A probléma olyan objektummodellje, amely teljesíti a feladat feltételeit A ábrán mutatott modellnél az úthálózat változásainak aktualizálását, egy település szomszédai körének bıvítését vagy szőkítését a következı körülmények nehezítik: Az A településbıl az irany[1], irany[2], irany[3], irany[4] irányokba indul útszakasz; ezzel szemben ha a G-t és a szomszédait ábrázoltuk volna, akkor irany[1], irany[2] is elég lett volna; ugyanakkor elképzelhetı olyan település is, amelynek több tucat irányban van szomszédja; végül mindegyik esetben a szomszédok száma akár nıhet, akár csökkenhet. A szakasz megmutatta, hogy az elıbbi bekezdésben leírt változatosság lista tárolási szerkezettel kezelhetı. A ábra diagramján látható modell ezt használja ki, és e modell számára az említett változatosság teljesen közömbös, mert minden településnél csak egy

59 INFORMÁCIÓRENDSZER FEJLESZTÉSE 199 (akármilyen szempontból kitüntetett) irányú (elsoirany) szomszédot kell nyilvántartani, a település többi szomszédja a kitüntetett szomszédból induló listában helyezkedik el. Ebben az objektummodellben lényegében a szakaszban tárgyalt multilista köszön vissza. (A diagram rajzolója némileg takarékoskodott az energiájával, mert az útszakaszok hosszát (szakaszhossz) csak mutatóban tüntette fel: az ac, ad, ab és ae útszakaszoknál.) Osztálydiagram Aki idáig jutott az olvasásban, az már találkozott az osztálydiagrammal, mert a diagramok is azok voltak. Az osztálydiagramon az osztályok definíciója (attribútumai, mőveletei) és az osztályok közötti különbözı természető viszonyok adhatók meg. Ilyen viszonyok az általánosításspecializáció (lásd a ábrán), az asszociáció és a függıségek. Az asszociáció az objektumok közötti kapcsolatok típusszintő reprezentációja, a ábrához kapcsolódóan fogunk bıvebben szólni róla, mert azon három is van belıle. Függıségrıl akkor beszélünk, ha az egyik osztály valamilyen módon használja a másik osztályt (a másik osztály definícióját vagy példányát). Tulajdonképpen a specializáció és az asszociáció is függıségek, de ezeken túli, más természető függıségek is léteznek, és a (szőkebb értelemben vett) függıségen az utóbbiakat értjük (de velük a könyvünk bıvebben nem foglalkozik). Az úthálózat osztálydiagramja: Szerkessze meg a ábrán látható objektumdiagramból elvonatkoztatható osztálydiagramot! A diagramon keresse meg a gettelepulesnev() és a getszakaszhossz() mőveletek helyét! Az elıbbi mővelettel a település nevét (telepulesnev), az utóbbival pedig az útszakasz hosszát (szakaszhossz) lehet lekérdezni. A ábra objektumdiagramjából elvonatkoztatott osztálydiagram a ábrán látható. Bármilyen sok objektumot mutat is a ábra, azok csak kétféle (Telepules és UtSzakasz) típusba tartoznak, ezért az osztálydiagramon csak a Telepules és az UtSzakasz osztály jelenik meg. A telepulesnev kézenfekvıen a Telepules attribútuma, a szakaszhossz pedig az UtSzakasz attribútuma; következésképpen az ezeket lekérdezı mőveletek közül a gettelepulesnev() mőveletnek a Telepules osztály a felelıse, a getszakaszhossz() mőveletnek pedig az UtSzakasz osztály. class Úthálózat CD -kovetkezo Telepules -elsoirany UtSzakasz - telepulesnev: String + gettelepulesnev() : String szomszed * - szakaszhossz: double + getszakaszhossz() : double ábra: A ábra objektummodelljébıl elvonatkoztatott osztálydiagram Megjegyzés: Az olvasó itt és a továbbiakban számára furcsa nevekkel találkozik. Az a helyzet, hogy itt többnyire az OO programozók körében bevett szokásokhoz igazodunk. (Ezeknek az UML-hez semmi köze, nem is kötelezı érvényőek, de tervek és a programkód olvasását megkönnyítik.) A lényeg, hogy az osztályok neve nagybetővel kezdıdik, minden

60 200 INFORMATIKUS SZAKMAI ISMERETEK más tervelem neve pedig kisbetővel. (Egyedül a településobjektumok nevében sértettük meg ezt a megállapodást: A:Telepules helyett az a:telepules lett volna szabályos, de a ábra csomópontneveinek való teljes megfelelés céljából kivételt tettünk) Azon felül a tervelemek nevei nem tagolhatók szóközökkel, ha mégis több szóból raktuk össze ıket, akkor a névben a 2., 3., szó kezdetét nagybető jelzi (pl. UtSzakasz vagy telepulesnev). Ráadásul itt kerültük az angol betőkészleten felüli ékezetes betők használatát is, mert a programkódban általában hibásnak minısülnek. (A könyvben nem mindig tettünk így, mert mind az UML, mind a tervezés CASE-eszközei megengedik a nemzeti betőkészletek használatát.) Az attribútumok, mőveletek és szerepnevek elıtti +/- (plusz/mínusz) jelek az adott tervelem láthatóságát jelölik. A + elıjellel ellátott név publikus, azaz az osztályon kívül is ismert; a - elıjellel ellátott név privát, azaz csak az osztályon belül definiált mőveletek hivatkozhatják. Az elrejtés elvét követve az attribútumok többnyire privátnak számítanak, a mőveletek pedig inkább publikusak (kivéve azt a néhányat, amelyet soha nem kell vagy nem lehet használni más osztályokban definiált mőveletekben. (Ha például az útszakasz egy példánya kíváncsi lenne a szomszed település nevére, akkor azt a szomszed.telepulesnev hivatkozással nem érheti el, mert a telepulesnev számára láthatatlan, privát attribútum. Viszont lekérdezheti ezt a nevet a szomszed.gettelepules() mővelettel.) A ábrán látható sok kapcsolat csak három típust képez. Az egyik típusú az, amely Telepules osztályú objektumot egy UtSzakasz osztályú objektummal köti össze, és az utóbbi elsoirany szerepben kapcsolódik az elıbbihez. Ilyenek például az A:Telepules (elsoirany) ac:utszakasz vagy a C:Telepules (elsoirany) cc:utszakasz kapcsolatok, amelyeket az osztálydiagramon összevontan egyetlen asszociáció képviseli, ez a Telepules (elsoIrany) UtSzakasz asszociáció. Egy másik típus az, amely UtSzakasz osztályú objektumot egy másik UtSzakasz osztályú objektummal köti össze, és az utóbbi kovetkezo szerepben kapcsolódik az elıbbihez. Ilyenek például az ac:utszakasz (kovetkezo) ad:utszakasz vagy a ad:utszakasz (kovetkezo) ab:utszakasz kapcsolatok, amelyeket az osztálydiagramon összevontan egyetlen asszociáció képviseli, az UtSzakasz (kovetkezo) UtSzakasz asszociáció. Egy harmadik típus az, amely UtSzakasz osztályú objektumot egy Telepules osztályú objektummal köti össze, és az utóbbi szomszed szerepben kapcsolódik az elıbbihez. Ilyenek például az ac:utszakasz (szomszed) C:Telepules vagy a ad:utszakasz (szomszed) D:Telepules kapcsolatok, amelyeket az osztálydiagramon összevontan egyetlen asszociáció képviseli, az UtSzakasz 1..* 1(szomszed) Telepules asszociáció. Lényeges, hogy végül a szerepnevekbıl is attribútum lesz. Így a Telepules osztálynak a telepulesnev-en felül attribútuma lesz még az elsoirány is, amelynek típusa az UtSzakasz, mert az elsoirány attribútum minden Telepules-példányban az adott példányhoz elsoirány szerepben kapcsolódó UtSzakasz-példány mutatóját fogja tartalmazni (pl. az A:Telepules objektum elsoirány attribútumának tartalma az

61 INFORMÁCIÓRENDSZER FEJLESZTÉSE 201 ac:utszakasz objektum mutatója lesz.). Hasonlóan az UtSzakasz osztálynak a szakaszhosszon felül lesz még egy kovetkezo attribútuma UtSzakasz típussal és egy szomszed attribútuma Telepules típussal. Az osztálydiagram nem csak abban különbözik az objektumdiagramtól, hogy az objektumok helyett osztályokat, a kapcsolatok helyett asszociációkat tartalmaz, de az asszociácók végeihez kapcsolódóan számosságok is megjelennek rajta. A Telepules (elsoIrany) UtSzakasz asszociáció esetében a 0..1 számosságban a 0 azt jelzi, hogy nem minden útszakaszhoz tartozik olyan település, amelynél az adott útszakasz mutatna a kitüntetett elsı irányú szomszédra (lásd például az ad útszakaszt). Ugyanebben a számosságban az 1 azt jelzi, hogy egy útszakaszhoz legfeljebb csak egy olyan település létezik, amelynél az adott útszakasz mutat a kitüntetett elsı irányú szomszédra. Az asszociáció másik végéhet tapadó, magában álló 1 számosság azt jelzi, hogy minden településhez pontosan egy olyan útszakasz tartozik, amely a település elsı irányú szomszédjára mutat; másképpen minden településnek van elsı irányú szomszédja, azaz legalább egy szomszédja. (Egy szigeten magában álló településre ez nem igaz, de azt nem is kell modelleznünk, mert a példa csak az úthálózatba bekapcsolódó településekrıl szól.) Az UtSzakasz (kovetkezo) UtSzakasz asszociáció esetében az UtSzakasz felıli 0..1 számosságban a 0 azt jelzi, hogy nem minden útszakaszhoz tartozik (a listában) megelızı útszakasz (nevezetesen az elsı irányú útszakaszokhoz nem tartozik). Ugyanebben a számosságban az 1 azt jelzi, hogy egy útszakaszhoz legfeljebb csak egy (a listában) megelızı útszakasz létezik. Az asszociáció másik végéhet tapadó 0..1 számosságban a 0 azt jelzi, hogy nem minden útszakaszhoz tartozik (a listában) következı útszakasz (nevezetesen a listában utolsó útszakaszokhoz nem tartozik). Ugyanebben a számoságban az 1 azt jelzi, hogy egy útszakaszhoz legfeljebb csak egy (a listában) következı útszakasz létezik. Az UtSzakasz 1..* 1(szomszed) Telepules asszociáció esetében az 1..* számosságban az 1 azt jelzi, hogy minden településbe mutat legalább egy útszakasz, azaz minden település szomszédja legalább egy településnek. (Egy szigeten magában álló településre ez sem igaz, de megint emlékeztetünk rá, hogy a példa csak az úthálózatba bekapcsolódó településekrıl szól.) Ugyanebben a számosságban a * azt jelzi, hogy egy településbe több útszakasz is mutathat, azaz a település több másik településnek lehet szomszédja (vagy egy településnek többszörösen is). Az asszociáció másik végéhet tapadó, magában álló 1 számosság azt jelzi, hogy minden útszakasz pontosan egy (szomszéd) településre mutat. Most tegyük fel, hogy a modellezı az úthálózat kezelésére kifejlesztendı szoftver követelményeit tanulmányozva megállapítja, hogy a szoftvernek tudnia kell választ adni olyan kérdésekre, hogy egy településnek hány szomszédja van, vagy egy település szomszédja-e egy másik településnek; tudni kell újabb települést hozzáadni egy adott település szomszédaihoz, vagy elvenni egy települést az adott település szomszédai közül. Közben az is eszébe jut, hogy korábbi fejlesztésekbıl már készen adott egy a szakaszban ismertetett lista elemeit modellezı ListaElem osztály a ábrán mutatott mőveletekkel, és ha az UtSzakasz osztályt a ListaElem osztályból leszármaztatással (a ListaElem osztály specializációjaként) képezné (a ábrán mutatott módon), akkor sokkal kevesebb munkával megúszhatná az említett szolgáltatások kifejlesztését. Mivel az útszakaszok listára vannak felfőzve, kézenfekvı az említett leszármaztatás, és akkor az UtSzakasz osztály definíciójába már felesleges a kovetkezo attribútumot és a getkovetkezo() és setkovetkezo() mőveleteket felvenni, hiszen azokat a ListaElem osztálytól megörökölheti.

62 202 INFORMATIKUS SZAKMAI ISMERETEK class Úthálózat CD kovetkezo 0..1 ListaElem + getkovetkezo() : ListaElem + setkovetkezo(listaelem) : void «listamővelet» + elemszam() : int + listabanvan(listaelem) : boolean + elemethozzaad(listaelem) : void + elemetbeszur(listaelem) : void + elemetlevag() : void + elemetlevag(int) : void + elemetlevag(listaelem) : void Telepules -elsoirany UtSzakasz - telepulesnev: String + gettelepulesnev() : String szomszed * - szakaszhossz: double + getszakaszhossz() : double ábra: Az úthálózat osztálydiagramja a ListaElembıl leszármaztatott UtSzakasz osztállyal Azonban a jelentısebb munkamegtakarítás a ListaElem osztály további (készen adott) mőveleteinek felhasználásával érhetı el. Itt áttekintjük az összes mőveletet: getkövetkezo():listaelem A mővelet visszaadja a listaelem kovetkezo attribútumának értékét, azaz a megszólított listaelemet követı listaelem mutatóját. setkovetkezo(e:listaelem) A mővelet írja (beállítja) a listaelem kovetkezo attribútumának értékét. Az attribútum új értéke a paraméterként átadott listaelem (e) mutatója lesz. elemszam():integer A mővelet visszaadja, hogy a megszólított listaelemtıl kezdıdıen hány elem van a listában; ha a megszólított elem a lista elsı eleme, akkor a teljes lista elemeinek számát adja vissza. listabanvan(e:listaelem):boolean A mővelet igaz (true) értéket ad vissza, ha a paraméterben adott listaelem benne van a megszólított listaelemet tartalmazó listában. A megszólított listaelem rendszerint a lista elsı eleme, de bármely elem legyen is, az eredmény ennél a mőveletnél mindig a teljes listát jellemzi (tehát nem csak a megszólított listaelemmel kezdıdı részét). elemethozzaad(e:listaelem) Amennyiben a paraméterben adott listaelem (e) még nincs benne a megszólított listaelemet tartalmazó listában, akkor az e listaelem lesz a lista utolsó eleme. elemetbeszur(e:listaelem):integer Amennyiben a paraméterben adott listaelem (e) még nincs benne a megszólított listaelemet tartalmazó listában, akkor az e

63 INFORMÁCIÓRENDSZER FEJLESZTÉSE 203 listaelem beszúródik oda úgy, hogy az e lesz a megszólított listaelemre következı elem. A korábbi következı elem ha volt ilyen pedig az e-re következı elem lesz. Ez a mővelet különbözik a setkovetkezo(e:listaelem) mővelettıl, mert nemcsak a megszólított elemben változtatja a következo mutató értékét, hanem az e-ben is. elemetlevag() A mővelet a megszólított listaelemre közvetlenül következı elemet ha van ilyen levágja a listáról (törli a listából). A mővelet azonos értelmő az elemetlevag(2) mővelettel. elemetlevag(i:integer) A mővelet az i. (i=1,2, ) helyen álló listaelemet levágja a megszólított listaelemmel kezdıdı listáról, feltéve, hogy a megszólított listaelemmel kezdıdı lista legalább i elemet tartalmaz. elemetlevag(e:listaelem) A mővelet a paraméterben adott listaelemet (e) levágja a megszólított listaelemmel kezdıdı listáról, feltéve, hogy a megszólított listaelemmel kezdıdı lista tartalmazza az e elemet. Megjegyzés: A ListaElem definíciójában a «listamővelet» sztereotípus után felsorolt mőveletek mind olyanok, hogy azok végrehajtásában a megszólított listaelem objektumon felül a lista más elemeinek (esetleg az összes elemének) is részt kell venni. (Ha lenne Lista osztály, akkor ezeket a mőveleteket annak a definíciójában kellene szerepeltetni. De az sem hiba, hogy nincs Lista osztály, mert a lista objektumot az elsı eleme helyettesíteni tudja. Ha viszont az ilyen helyettesítésen alapuló megoldást választottunk, akkor minden olyan mőveletet is a ListaElem definíciójába kellett felvenni, amely egyébként egy Lista osztály felelısségébe tartozna.) Ezek után könnyő belátni a következı megoldásokat: Egy település szomszédainak száma könnyen megállapítható a ListaElem osztályban definiált elemszam() mővelet felhasználásával (pl. az A település szomszédainak számát az A.elsoIrany.elemSzam() kifejezéssel kezdeményezett mővelet adja vissza). Az A településnek azért szomszédja a D település, mert a D településre mint szomszédra mutató ad útszakasz paraméterrel az A.elsoIrany.listabanVan(ad) kifejezéssel kezdeményezett mővelet true (igaz) értéket ad vissza; Egy új X települést többféleképpen is hozzáadhatunk az A szomszédaihoz, de mindegyik változatban létre kell hozni egy olyan ax útszakaszt, amely az X településre mutat mint szomszédra. Utána az egyik megoldás A.elsoIrany.elemetHozzaad(ax) kifejezéssel kezdeményezett mővelet, amelynek végrehajtását követıen már az ax útszakasz nem csak beiktatódik az A településbıl induló útszakaszok listájába, de ı lesz az A.elsoIrany is Dinamikus modellek A dinamikus modellek a rendszer vagy a rendszer komponensei viselkedésérıl, idıbeli változásairól, a komponensek közötti kölcsönhatásokról szólnak. Az UML-ben a dinamikus modellezés eszközei a szekvenciadiagram, az együttmőködési diagram, az állapotdiagram és a tevékenységdiagram. A dinamikus modellezés célja elsıdlegesen az objektumok viselkedésének kiderítése, vagyis az objektumok osztályainak felelısségi körében definiálandó mőveletek azonosítása. Azonban a dinamikus modellek egyéb módon is hozzájárulnak az elızetesen kidolgozott

64 204 INFORMATIKUS SZAKMAI ISMERETEK osztálymodellek finomításához: újabb asszociációk és attribútumok szükségességére világítanak rá; de segíthetnek a tesztspecifikációk elkészítésénél és a programok belövésénél is. Szekvenciadiagram Egy szekvenciadiagrammal konkrét objektumok együttmőködésének (kommunikációjának) egy kiragadott esetben való lefolyása ábrázolható; ezért dominánsan az elemzést szolgálja, mivel a tervezésnek minden lehetséges esetre érvényes megoldásokat kell produkálnia. Szekvenciadiagramokat így a követelményelemzés során is alkalmazzák, például az ott azonosított használati esetek forgatókönyvének megjelenítésére. Mivel bonyolultabb feladatok esetében az általánosan érvényes megoldások csak az egyes kiragadott esetek modelljeibıl vonatkoztathatók el, a szekvenciadiagramok a tervezés közben is szerepet kapnak. Megjegyzés: A használati esetek forgatókönyvének ábrázolására szolgáló szekvenciadiagramok jól felhasználhatók a forgatókönyvalapú objektumintegrációs tesztek teszteseteinek tervezésében (lásd a szakaszban). A szekvenciadiagramon szerepelı szimbólumok: Példaobjektumok: Ezeket általában egy-egy téglalap (doboz) képviseli, belsejében az objektum hivatkozásával. Ha a példaobjektum jellegét is hangsúlyozni akarjuk, akkor az másképpen is ábrázolható, például aktort jelzı szimbólummal vagy speciálisan vezérlı objektumot jelzı szimbólummal; ilyenkor az objektum hivatkozása a szimbólum alatt állhat. A példaobjektum függılegesen életvonalban folytatódik. (Azonos osztályból különbözı nevekkel több példaobjektum is részt vehet az együttmőködésben. Ha viszont egy osztálynak csak egy példánya szerepel a diagramon, akkor azt elegendı egy :osztálynév alakú hivatkozással ellátni; pl.: :POS.) Megjegyzés: A példaobjektum elnevezés onnan van, hogy a diagram mindig egy kiragadott példát mutat be, tehát a kiragadott példában konkrétan együttmőködı objektumok a példaobjektumok. Üzenetküldések: Ezeket nyíl ábrázolja. A nyíl a küldı (forrásobjektum) életvonalától a fogadó (célobjektum) életvonala felé mutat. Különbözı alakú nyilak különbözı típusú üzenetküldést képviselnek. Az üzenetet a nyíl fölé/mellé kell írni. (A dinamikus modellezés során az üzenet, az esemény és a mővelet szinte szinonim fogalmak. Ugyanis ami az egyik objektum részérıl üzenet, az a másik objektum számára esemény, illetve mővelet. Az ügyfél (kliens) objektum (vagy forrásobjektum) üzenetet küld (kérést intéz) a kiszolgáló (szerver) objektumhoz (másképpen célobjektumhoz). Az utóbbi számára az üzenet érkezése egy esemény, amire ha az állapota megengedi reagálni fog. A kiszolgáló objektum az üzenetre/eseményre valamilyen az üzenetben hivatkozott mővelet végrehajtásával reagál. Ez a mővelet a kiszolgáló objektum osztályának felelısségi körébe tartozik, azaz annak sémájában kell definiálni.) A szekvenciadiagramon az idı felülrıl lefelé halad, azaz a késıbbi üzenetek a diagramon alább helyezkednek el. Vezérlésfókusz: Az életvonalra helyezett függıleges hasáb. Egy megszakítás nélküli hasáb olyan idıintervallumot jelöl, amely alatt az objektum folyamatosan mőködik, azaz vagy nála van a vezérlés (közvetlenül ı hajt végre mőveleteket) vagy egy általa küldött üzenet feldolgozására vár. A ábra a POS készüléken kezdeményezett fizetés alatti üzenetváltások leegyszerősített szekvenciadiagramját mutatja. Ilyen témájú szekvenciadiagram inkább a követelményelemzés során készül például egy használati eseten belüli történések ábrázolása céljából.

65 INFORMÁCIÓRENDSZER FEJLESZTÉSE 205 sd POS2 :POS :PosSzolgáltatóBank :KártyaTársaságDb :KártyaSzlaBankDb kártyaolvasás összegolvasás jóváhagyás [kell PIN-kód]: pinkódolvasás t1 tranzakció(tradatok) tranzakció(tradatok) kártyabankszla:= kártyaérvényesség(kártyaadatai) [kártya érvényes]: számlaérvényesség(kártyabankszla) számla érvényes terhelés(tradatok, kártyabankszla) terhelés sikeres tranzakció sikeres t2 tranzakció sikeres bizonylatnyomtatás { t2 - t1 <= 25 sec } ábra: POS terminálon kezdeményezett fizetés szekvenciadiagramja Maga a POS terminál (az ábrán :POS) egy «boundary» (azaz határfelületi) objektum (másképpen felhasználói felület objektum), amelynek közvetítésével a kereskedı (pénztáros), illetve a kártyatulajdonos vevı kommunikál a rendszerrel. A POS terminálon végzett mőveletek a következık:

66 206 INFORMATIKUS SZAKMAI ISMERETEK kártyaolvasás: A POS készülék kártyaolvasójában elhúzott kártya mágnescsíkján rögzített azonosító adatok beolvasása. összegolvasás: A kereskedı (pénztáros) által a POS készülék billentyőzetén beütött összeg olvasása. jóváhagyás: Az összeg jóváhagyása a vevı által. [kell PIN-kód]:pinKódOlvasás: A vevı által bebillentyőzött PIN kód olvasása. A [kell PIN-kód] feltétel jelzi, hogy a POS készülék nem minden kártya esetén kér PIN kódot, de ez a szekvenciadiagram egy olyan konkrét esetet ábrázol, amikor igen. Alapvetıen a kártya típusától függ, hogy kell-e kérni PIN kódot (pl. Maestro kártya esetén kötelezı), de a POS készüléken egyedileg is beállíthatók erre vonatkozó szabályok. A :POS objektum a tranzakció(tradatok) üzenettel kezdeményezi a tranzakció feldolgozását a :PosSzolgáltatóBank objektumnál. A tranzakció(tradatok) üzenetben a tradatok paraméter maga is objektum, amelynek attribútumai a tranzakció jellemzıi (a POS terminál, a kereskedı, a kereskedı számlája és a kártya azonosítója; a PIN kód; a tranzakció azonosítója, idıpontja, összege). A további példaobjektumok értelmezése: A :PosSzolgáltatóBank a POS terminált telepítı bank rendszere, amelynek az együttmőködésben (az ábrázoló szimbólummal is jelezve) vezérlı szerepet tulajdonítottunk, mivel ı a kezdeményezı fél a :KártyaTársaságDb és a :Kártya- SzlaBankDb objektumokkal szemben; a POS terminált pedig (egy némileg önkényes nézıpontválasztással) a :PosSzolgáltatóBank objektummal reprezentált rendszer perifériájának tekintettük. A :KártyaTársaságDb a kártya típusának megfelelı kártyatársaság rendszere, amelynek esetünkben lényeges eleme a kártyák nyilvántartására (a kártya érvényességének és a kártyához tartozó bankszámlának a meghatározására) szolgáló adatbázis (a névben erre utal a Db rész). A :KártyaSzlaBankDb a kártyához tartozó számlát vezetı bank rendszere, amelynek esetünkben lényeges eleme a számlák nyilvántartására (a számla érvényességének és egyenlegének meghatározására) szolgáló adatbázis. A szekvenciadiagramon feltüntetett, de eddig nem említett üzenetek értelmezése: kártyabankszla:=kártyaérvényesség(kártyaadatai): A kártya érvényességének megállapítása a tradatok között átadott kártyaadatok (lásd a kártyaadatai paramétert) alapján, illetve érvényes kártya esetén a hozzátartozó bankszámla azonosítójának (kártyabankszla) visszaadása. [kártya érvényes]:számlaérvényesség(kártyabankszla): A kártyabankszla paraméterrel azonosított számla érvényességének megállapítása. A [kártya érvényes] feltétel jelzi, hogy erre az üzenetre és a vele kiváltott vizsgálatra csak akkor kerül sor, ha elızetesen a kártya érvényes volt, illetve hogy a szekvenciadiagramunk éppen ilyen konkrét esetet modellez. terhelés(tradatok,kártyabankszla): A kártyabankszla paraméterrel azonosított számla egyenlegének arra irányuló vizsgálata, hogy az egyenleg fedezetet nyújt-e a tranzakcióban fizetendı összegre; majd a fedezet megléte esetén a (vevıi) bankszámla megterhelése (más szóval olyan átutalás elıjegyzése a számlára, amelynek kedvezményezettje a kereskedı bankszámlája). A válasznyílon álló terhelés sikeres kimenetel jelzi, hogy a szekvenciadiagramunk olyan konkrét esetet tárgyal, amikor van fedezet.

67 INFORMÁCIÓRENDSZER FEJLESZTÉSE 207 bizonylatnyomtatás: A sikeres tranzakciót nyugtázó bizonylat nyomtatása a POS terminálon. A diagram tartalmaz egy {t2 t1<=25sec} megszorítást is. A t1 a tranzakció(tradatok)üzenet :POS általi indításának idıpontja, a t2 a pedig a válasz :POS-hoz való megérkezésének idıpontja. Az olvasó felvetheti azt a kérdést, hogy miért nem tartalmazza a folyamat a kereskedı számláján történı jóváírást is. Azért, mert az már egy másik folyamatnak, a terhelés(tradatok,kártyabankszla) üzenettel elıjegyzett átutalási folyamatnak a része. A ábra meglehetısen egyszerő, ezért a szekvenciadiagramnak az osztálymodell finomításához való hozzájárulását csak jelképesen érzékelteti: Konkrétan az olvasható le róla, hogy a tranzakció(tradatok) mőveletet mind a PosSzolgáltatóBank, mind a KártyaTarsaságDb osztályok definíciójába fel kell venni; a kartyaérvényesség (kártyaadatai) mőveletnek a KártyaTarsaságDb definíciójában kell szerepelni; a számlaérvényesség(kártyabankszla) és a terhelés(tradatok, kartya- BankSzla) mőveletek pedig a KártyaSzlaBankDb osztály felelısségébe tartoznak. A két osztály definíciójában is szereplı tranzakció(tradatok) mővelet megvalósítása a PosSzolgáltatóBank osztályban csak annyi, hogy a tranzakció feldolgozására vonatkozó kérést továbbítja (delegálja) a KártyaTarsaságDb-példányhoz, azt szólítja fel a saját tranzakció(tradatok) mőveletének a végrehajtására. Tehát a tranzakció tényleges feldolgozását végül a tranzakció(tradatok) mőveletnek a KártyaTarsaságDb osztályon belüli megvalósítása végzi el. Mivel a kartyaérvényesség(kártyaadatai) mőveletre a KártyaTarsaságDb-példány önmagát szólítja fel (ezt hívják öndelegációnak is), ezt a mőveletet az osztályon kívüli objektumoknak nem is kell ismerni, tehát ez a KártyaTarsaságDb osztálynak egy privát mővelete lehet. A és a ábrák inkább a részletes tervezés közbeni elemzés céljából készülhetnek. A ábra a ListaElem osztályban definiált elemszam() mővelet végrehajtását modellezi egy olyan kiragadott esetben, amikor a megszólított e1 elemmel kezdıdı lista (vagy egy lista e1 elemmel kezdıdı része) éppen három elemet (e1, e2, e3) tartalmaz. Az ábráról a következı történések olvashatók le: A vezerles objektum egy üzenettel felszólítja az e1 objektumot az elemszam() kérdés megválaszolására. Az e1 egy sz számlálót használ, és annak értékét legelıször 1-re állítja (sz:=1), mert sajátmagáról tudja, hogy benne van a listában. Mivel az e1 látja, hogy a saját e1.kovetkezo attribútumának értéke nem üres ([kovetkezo!= null]), megállapítja, hogy rajta kívül még egy további eleme is van a listának, ezért növeli 1-gyel az sz értékét (sz:=sz+1). Az sz értéke így már: 2. Mivel az e1.kovetkezo attribútum értéke e2, ezért az e1 látja az e2 elemet, így tıle is meg tudja kérdezni a kovetkezo attribútum értékét. (getkovetkezo()). Mivel az elıbbi kérdésre visszakapott válasz e3, azaz még ez az elem is része a listának, ismét növeli 1-gyel az sz értékét (sz:=sz+1). Az sz értéke így már: 3. Az elıbbi mőveletek eredményeként az e1 már az e3 elemet is látja, és tıle is megkérdezi a kovetkezo attribútum értékét. (getkovetkezo()). A visszakapott

68 208 INFORMATIKUS SZAKMAI ISMERETEK üres (null) érték jelzi, hogy nincs több eleme a listának, ezért az e1 az sz számláló idáig növekedett értékét (azaz a 3-at) adja vissza a vezerles objektumnak. A ábra szekvenciadiagramja csak arról a konkrét esetrıl szól, amikor éppen 3 eleme van a listának, de a tervezı már az akárhány elemő listára érvényes megoldást is ki tudja következtetni belıle, és már könnyebben megírja az elemszam() eljárás forráskódját. (Az elemszam() eljárás Java nyelvő forráskódját a szakaszban találja meg az olvasó.) sd Elemek megszámlálása e1 :ListaElem e2 :ListaElem e3 :ListaElem vezerles esz:=elemszam() sz:=1 [kovetkezo!= null]: sz:=sz+1 getkovetkezo() e3 sz:=sz+1 3 getkovetkezo() null ábra: Egy lista elemeinek megszámlálásáról készült szekvenciadigram A ábra a ListaElem osztályban definiált listabanvan(e: ListaElem) mővelet végrehajtását modellezi egy olyan kiragadott esetben, amikor a listának összesen 7 eleme van (e1, e2, e3, e4, e5, e6, e7) a vezerles által megszólított elem az e5, a keresett e elem pedig történetesen az e3 elemmel azonos. Az ábráról a következı történések olvashatók le: A vezerles objektum egy üzenettel felszólítja az e5 objektumot a listaban- Van(e) kérdés megválaszolására. Mivel elsıre az [e5!= e AND e6!= e] feltétel teljesül, azaz e5 megállapítja, hogy sem maga nem azonos a paraméterben adott e elemmel, sem a saját e5.kovetkezo attribútumával mutatott e6 elem, az e5 elem az e6 elemtıl kérdezi meg a rákövetkezı elemet (getkovetkezo()).

69 INFORMÁCIÓRENDSZER FEJLESZTÉSE 209 Mivel az elıbbi kérdésre visszakapott válasz e7, és még ez sem azonos a paraméterben adott e elemmel ([e7!= e]), az e5 elem az e7 elemtıl kérdezi meg a rákövetkezı elemet (getkovetkezo()). Az elıbbi kérdésre kapott üres (null) válasz jelzi, hogy az e5 mögött nincs több eleme a listának, ezért a paraméterben adott e elem a vizsgált listának már csak az e5 elemet megelızı elemei között fordulhat elı, ha egyáltalán benne van a listában. A lista e5 elemet megelızı elemeit azonban az e5 elembıl kiindulva nem lehet elérni, mert a listaelemekben csak kovetkezo mutató van (elozo mutató nincs), azaz az ismert e5 elembıl kiindulva csak az e5 e6 e7 haladás lehetséges, az e5 e4 e3 e2 e1 haladás lehetetlen. Ám egy jó ötlet mindig segíthet: Hogy a paraméterben adott e elem elıfordul-e a vizsgált listának az e5 elemet megelızı elemei között, az úgy is megállapítható, hogy a vizsgálat az e elembıl halad elıre a kovetkezo mutatók mentén, és ha eljut az e5 elemhez, akkor az e elem benne van az e5 elemet is tartalmazó listában, ellenkezıleg nincs benne. sd Adott elem benne v an-e a listában e = e3 e :ListaElem e4 :ListaElem e5 :ListaElem e6 :ListaElem e7 :ListaElem vezerles listabanvan(e) [e5!= e AND e6!= e]: getkovetkezo() e7 [e7!= e]: getkovetkezo() getkovetkezo() null e4 [e4!= e5]: getkovetkezo() e5 true ábra: Annak a folyamatnak a szekvenciadiagramja, amely kideríti, hogy adott listaelem benne van-e az adott listában Az imént vázolt ötletnek megfelelıen az e5 elem az e elemtıl kérdezi meg a rákövetkezı elemet (getkovetkezo()).

70 210 INFORMATIKUS SZAKMAI ISMERETEK Mivel az elıbbi kérdésre visszakapott válasz e4, azaz a folyamat még nem érte el sem a lista végét, sem az e5 elemet ([e4!= e5]), az e5 elem az e4 elemtıl kérdezi meg a rákövetkezı elemet (getkovetkezo()). Mivel az elıbbi kérdésre visszakapott válasz e5, bebizonyosodott, hogy a paraméterben adott e elem benne van az e5 elemet is tartalmazó listában. Az listabanvan(e) eljárás Java nyelvő forráskódját (amely a ábra szekvenciadiagramjával modellezett folyamat logikáját követi) a szakaszban találja meg az olvasó. Együttmőködési diagram Az együttmőködési diagrammal csak keveset foglalkozunk, mert ugyanarra a célra használható, mint a szekvenciadiagram, és attól csak formai megoldásokban különbözik. Ezt az állítást bizonyítandó, a ábra egy korábbi szekvenciadiagrammal (4.24. ábra) egyenértékő együttmőködési diagramot mutat be ábra: A ábra szekvenciadiagramjával egyenértékő együttmőködési diagram Az együttmőködési diagramon ugyanúgy példaobjektumok és üzenetek jelennek meg, mint a szekvenciadiagramon. A különbség az üzenetek idıbeli sorrendjének reprezentálásá-

71 INFORMÁCIÓRENDSZER FEJLESZTÉSE 211 ban van: az együttmőködési diagramon ezt nem az üzenetek térbeli elrendezése, hanem a sorszáma jelzi. Az együttmőködési diagramon kapcsolóvonallal kell összekötni azokat a példaobjektumokat, amelyek közvetlenül kommunikálnak egymással. (Öndelegáció esetén az objektumba visszamutató kapcsolóvonalat hurkot is alkalmazni kell.) Ha egy o1 objektum üzenetet küld egy o2 objektumnak, akkor az üzenetet reprezentáló nyilat az o1 o2 kapcsolóvonal mellett kell feltüntetni. Megjegyzés: A szekvenciadiagramot és az együttmőködési diagramot együtt kölcsönhatásdiagramoknak is nevezik. Állapotdiagram Amíg a kölcsönhatásdiagramokkal több objektum együttes viselkedése elemezhetı egy adott folyamat egy konkrét lefutásában, addig az állapotdiagrammal minden történést egy adott típusú objektum felıl nézve, annak életére vetítve vizsgálunk, és az objektum teljes életét, az összes lehetséges állapotváltozásait írjuk le. Az elıbbi diagramokkal ellentétben az állapotdiagram nem kiragadott példákat ábrázol, hanem egy objektum lehetséges változásait olyan teljességgel írja le, hogy az általánosságban érvényes legyen az objektum osztályának minden egyes példányára. Ezen okból gyakran használjuk az osztály állapotdiagramja kifejezést. (Elıretekintve a ábrára, megállapíthatjuk hogy a Rendelés állapotdiagramja egyformán érvényes az elfogadott és a visszautasított rendelésekre; a rendben leszállított és a nem megfelelıen leszállított rendelésekre.) Az állapotdiagram alkalmas a kölcsönhatásdiagramokkal feltárt kép kontrolljára, hézagainak pótlására, illetve egy finomabb elemzésre: A kölcsönhatásdiagramok az öndelegációk esetleges feltüntetését leszámítva tipikusan a publikus mőveleteket mutatják, és a belsı mőködésrıl csak az aktív objektumok esetében szólnak. Így az egyes osztályok nem publikus mőveleteire, valamint a passzív objektumok belsı mőködésére éppen az állapotdiagramokból következtethetünk. Az állapotdiagramok bemenetül szolgálnak az egyes objektumosztályok teszteléséhez szükséges tesztesetek tervezéséhez is (lásd a szakaszban). Az állapotdiagram olyan háló, amelynek a csomópontjai állapotok (egy adott osztályú objektum lehetséges állapotai), irányított élei pedig átmenetek, melyek az objektum lehetséges változásait mutatják. Azon felül a diagram még a következı elemeket tartalmazhatja: az egyes állapotokban az objektum által végezhetı tevékenységeket; akciókat, amelyeket az objektum valamely átmenet során (vagy esemény hatására) hajthat végre; eseményeket: vagy ahhoz az állapothoz rendelve, amelyben az esemény bekövetkezhet, vagy ahhoz az átmenethez rendelve, amelyet az esemény idéz elı; ırszemeket (más szóval elıfeltételeket), amikkel az objektum (kiterjesztett) állapotából eredı feltételek fogalmazhatók meg annak pontosítására, hogy egy esemény mikor következhet be, egy akció mikor hajtható végre, egy átmenet mikor történhet meg. (İrszem nem idézhet elı átmenetet, éppen ellenkezıleg, korlátozza az átmenet megtörténtét. Ha egy esemény mellett ırszem is áll, az esemény csak akkor válthatja ki az átmenetet, ha egyidejőleg az ırszemben adott feltétel is teljesül.) Az állapotdiagramon az állapotot lekerekített sarkú doboz képviseli, benne az állapot nevével, ez alól kivételt képeznek a pszeudoállapotok, amelyekrıl késıbb lesz szó. Az állapotok közötti átmeneteket az állapotszimbólumokat összekötı nyilak mutatják. Egy objektum pillanatnyi belsı állapotán, az attribútumai aktuális értékének együttesét értjük. Egy objektum reagálását valamely külsı hatásra gyakran egyedül a külsı hatás mi-

72 212 INFORMATIKUS SZAKMAI ISMERETEK lyensége nem tudja meghatározni, hanem az függ az objektum belsı állapotától is. Például a mobiltelefonon a 2-es gomb lenyomása egyik állapotban a 2 számjegy, másik állapotban viszont az a bető megjelenését váltja ki. De a mobiltelefonnál maradva messzebbre vezetı példát is találunk: A készülék híváskor adott esetben kijelzi a hívó számát, máskor viszont nem, mert a hívó ezt a lehetıséget letiltotta. Ez arra példa, amikor egy objektum reagálása egy másik objektum egyidejő állapotától függ. Az utóbbi tény miatt lehet beszélni egy objektum adott idıpontban vett külsı állapotáról, ami alatt az objektumhoz közvetlen vagy közvetett módon kapcsolódó más objektumok adott idıpontbeli belsı állapotainak együttesét kell érteni. Az objektum egyidejő belsı és külsı állapota együtt adja ki az objektum kiterjesztett állapotát. A bevezetı példákból is kitőnik, hogy az objektum viselkedését csak a kiterjesztett állapotai függvényében lehet korrekten leírni, tehát állapoton a továbbiakban ezt fogjuk érteni. Egy objektum és a vele kapcsolatban lévı más objektumok attribútumai egyidejő konkrét értékeinek összessége kiad egy konkrét állapotot. Könnyő belátni, hogy adott objektum konkrét állapotainak száma igen nagy tud lenni, illetve ha a szerepet játszó attribútumok között csak egyetlen folytonosan változtatható mennyiség is akad, akkor az objektum konkrét állapotainak száma végtelen. Tehát a viselkedés konkrét állapotokhoz kötött modellezése reménytelen vállalkozás. Azonban a lényeges és lényegtelen jegyek praktikus megkülönböztetésével az objektum konkrét állapotainak halmazából mindig kijelölhetı kezelhetı számú részhalmaz úgy, hogy a kapott részhalmazok egyesítése lefedi az objektum konkrét állapotainak teljes halmazát, és az azonos részhalmazba tartozó konkrét állapotok mindegyikében az objektum a lehetséges hatásokra a lényeget tekintve azonos módon reagál. A konkrét állapotok így kapott egy-egy részhalmazát absztrakt állapotnak tekintjük. A modellezés során érthetıen mindig absztrakt állapotokra vonatkozó megállapításokat rögzítünk Rendelés objektumok állapotdiagramja Például a Rendelés életútjának modellezésénél (4.28. ábra) elhanyagolható körülménynek vettük, hogy a rendelés határidın túli szállítása a határidı után éppen hány nappal történt. Ebbıl adódóan a Rendelés minden ilyen konkrét állapotát egy Határidın túl nevő absztrakt állapotba foglalhattuk.

73 INFORMÁCIÓRENDSZER FEJLESZTÉSE 213 Az objektum lehetséges állapotváltozásait az átmenetek jelölik ki. Azt a tényt, hogy az objektum élete során elıfordulhat olyan változás, hogy az A állapotból éppen a B állapotba megy át, az A-ból B-be mutató átmenet jelzi. Lehetséges azonos állapotba visszamutató átmenet is, mint azt a ábra példája is mutatja. Az átmenetet kiválthatja valamilyen esemény, de történhet automatikusan is. Ez utóbbi inkább az aktív objektumokat jellemzi, de elıfordulhat azon egyszerő okból is, hogy egy olyan részletesebb diagramot rajzoltunk, amelyben egy tevékenység közvetlenül és feltétel nélkül egymást követı szakaszait különbözı tevékenységeknek tekintettük, és így azokat különbözı állapotokba különítettük el. Az állapotnak idıtartamot tulajdonítunk, az átmenetet viszont idıtartam nélküli (megszakíthatatlan) változásnak gondoljuk. Tehát amikor egy átmenettel összekötött két állapot között ténylegesen megtörténik az átmenet, az egyik (absztrakt) állapot megszőnésével azonnal beáll a másik állapot. Az állapotok között is értelmezhetı általánosítás és specializáció. Az A1, A2, absztrakt állapotok általánosításaként kapott A fıállapot (szuperállapot) egy olyan absztrakt állapot, amelybe éppen azok a konkrét állapotok tartoznak, melyeket az A1, A2, absztrakt állapotok legalább egyike tartalmaz. Megfordítva az A1, A2, absztrakt állapotokat az A állapot specializációinak, másképpen alállapotainak nevezzük. Az állapotdiagramon a fıállapot és alállapotai arról ismerhetık fel, hogy a fıállapot doboza magában tartalmazza az alállapotok dobozait. (Lásd a ábrán a Határidı elıtt fıállapotot, benne a Feladott és a Visszaigazolt alállapotokkal.) A fı- és alállapot fogalmak praktikus haszna, hogy az állapotdiagramok készítését sokkal egyszerőbbé teszik, e fogalmak nélkül a bonyolultabb életutak ábrázolása lényegesen nagyobb ráfordítással járna, az eredmény pedig nagyon sok átmenetet tartalmazó, áttekinthetetlen diagram lenne: azonos tevékenységet, eseményt, akciót, ırszemet sokkal több helyen kellene feltüntetni. Az állapotdiagram jelentésének pontosítása, illetve az állapotdiagram formai egyszerősítése céljából az eddig említett normális állapotokon felül különféle pszeudoállapotok is használhatók. Közülük itt négyfélét említünk meg: A kezdı állapot (jele kis fekete korong lásd a ábrán), ami az objektum életének kezdeti állapotát mutatja, vagy egy szuperállapoton belüli kezdıállapotot (lásd a ábrán a Riasztás bekapcsolva szuperállapoton belül) jelöl. A záró állapot (jele kis céltábla, másképpen ökörszem lásd a ábra jobb alsó sarkában), ami az objektum életének végét vagy egy szuperállapoton belüli tevékenység végét jelöli. Az emlékezı (history) állapot jele kis körben egy H bető. Lásd a ábrán a Határidı elıtt szuperállapoton belül, valamint a ábrán a Normál mőködés szuperállapoton belül. Az elágazás (jele kis rombusz), amelyben egy átmenet elágazhat, és a kimeneti átmeneteit (a folytatást) feltételekhez (ırszemekhez) lehet kötni. Lásd a ábrán a [megfelel] és [nem felel meg] ırszemekkel felszerelt ágakat. A ábra értelmezése: A rendelés Feladott állapotban jön létre. Ha a szállítótól visszaigazolás érkezik, akkor a rendelés Visszaigazolt állapotba megy át. Mivel mind a szállítás érkezése, mind a határidı lejárta a Feladott és a Visszaigazolt állapotban egyaránt bekövetkezhet, és mindkét állapotban azonos követekezményekkel jár, célszerő volt bevezetni egy a Feladott és a Visszaigazolt állapotokat magába foglaló Határidı elıtt szuperállapotot. A szállítás eseménnyel elıidézett átmenetnek a Határidı elıtt szuperállapot határáról indítása éppen azt fejezi ki, hogy ez az esemény a Feladott és a Visszaigazolt állapotban egyaránt bekövetkezhet, és mindkét állapotban azonos következményekkel jár. (Hasonló mondható el a when(határidı lejárt) esemény által elıidézett átmenetrıl is.)

74 214 INFORMATIKUS SZAKMAI ISMERETEK Ha a rendelés teljesítésére a Határidı elıtt állapotban érkezett szállítás megfelelı (lásd a [megfelelı] ırszemet), akkor a rendelés Leszállítva állapotba kerül; ellenkezıleg (a [nem felel meg] ırszem esete) visszatér a Határidı elıtt állapotba (pontosabban ottmarad ebben az állapotban). Az utóbbi ág egy H emlékezı pszeudoállapotban végzıdik, ami jezi, hogy a rendelés a Határidı elıtt állapoton belül éppen abba az állapotba kerül vissza, amelyben a szállítás esemény elıtt volt: ha a Feladott állapotban volt, akkor abba, ha a Visszaigazolt állapotban volt, akkor abba. Az utóbbi ág [nem felel meg]/szállítás.visszaküldés specifikációjában a / jel utáni rész egy akció, amely ebben az esetben konkrétan a szállítás objektumhoz intézett visszaküldés üzenet, amely a szállítás objektumot visszaküldött állapotba viszi. (Ez azonban a mi állapotdiagramunkon nem látszódhat, mert az nem a Szállítás osztály, hanem a Rendelés osztály példányairól szól.) A Rendelés osztály definíciójának kialakítása céljából a rendelés objektumok életútját mutató ábráról leolvasható, hogy a rendelés objektumnak tudni kell reagálni a visszaigazolás, a szállítás, az ellenérték utalása és az archiválás eseményekre; azaz a Rendeles osztály definíciójában meg kell jelenni a visszaigazolás(vip), a szállítás(szp) az ellenértékutalása(up) és az archiválás() mőveleteknek. (Itt vip a visszaigazolás tartalmát, szp a szállítás adatait, az up pedig az utalás adatait közlı paraméterobjektumok.) Mivel a rendelés objektum szállítás.visszaküldés akciója azt jelenti, hogy a rendelés egy visszaküldés üzenetet küld a szállítás objektumnak, a Szállítás osztály definíciójában meg kell jelenni az ezen üzenetre reagáló visszaküldés(vkp) mőveletnek, amelyben vkp a visszaküldés indokait közlı paraméterobjektum. Ugyanezen diagram állapotait tekintve, megállapítható, hogy a Rendeles osztály szerkezetében kell lenni egy olyan attribútumnak, amelynek értékei megkülönböztetik a Határidı elıtt, a Határidın túl, a Leszállítva, és a Számla kiegyenlítve állapotokat; továbbá egy olyan attribútumnak, amelynek értékei megkülönböztetik a Feladott és a Visszaigazolt állapotokat. A digitális óra modellezendı viselkedése: A következı feladat a ábrán látható digitális óra viselkedésének modellezése állapotdiagrammal. A digitális óra felületén három gomb (SELECT, SET és ALARM ON/OFF), és egy kijelzı látható. Az utóbbi öt mezıt tartalmaz: hónapmezı (HH), napmezı (NN), óramezı (OO), percmezı (PP) és alarmmezı (ALARM). A digitális óra objektum (egyebek mellett) a következı adatokat (attribútumokat) kezeli: hónap, nap, pontosóra, pontosperc, riasztásóra, riasztásperc. Normál állapotban (nem beállítási állapotban) az óra kijelzıjén a hónapmezı a hónap értékét, a napmezı a nap értékét, az óramezı a pontosóra értékét, a percmezı a pontosperc értékét mutatja. Ha a riasztás be van kapcsolva, akkor az alarmmezıben az ALARM szöveg világít, egyébként pedig üres (a szöveg nem világít). A digitális óra a bekapcsolása után normál állapotba kerül, abban is a riasztás kikapcsolva. Az óra kijelzıje a hónap, nap, pontosóra, pontosperc valamilyen sztenderden beállított kezdeti értékeit mutatja (amely persze mindaddig nem felel meg a pontos idınek, amíg a felhasználó azt be nem állítja). Ebben az állapotban az óra vezérlése percenként egy órajelet kap, amelynek hatására frissíti a hónap, nap, pontosóra, pontosperc értékét, valamint a hónapmezı, a napmezı, az óramezı és a percmezı tartalmát a kijelzın. Ugyancsak ebben az állapotban az ALARM ON/OFF gomb lenyomása az órát a riasztás bekapcsolva állapotba viszi át, ismételt lenyomása pedig visszaviszi a riasztás kikapcsolva állapotba. A bekapcsolt riasztás nem azt jelenti, hogy az óra azonnal riasztó (ébresztı) hangjelzést ad, hanem csak azt, hogy ebben az állapotban figyeli azt az eseményt, amikor a pontosóra, pontosperc értéke egyenlıvé válik a riasztásóra, illetve riasztásperc értékével, és csak akkor fog hangjelzést adni. A hangjelzést a következı órajel (1 perc múlva) vagy az ALARM ON/OFF gomb lenyomása kapcsolja ki.

75 INFORMÁCIÓRENDSZER FEJLESZTÉSE 215 Normál állapotból a felhasználó a SELECT gomb lenyomásával viheti át a beállító állapotba az órát, mégpedig legelıbb a hónapot állító állapotba, majd a SELECT gomb ismételt nyomkodásával rendre a napot, a pontos órát, a pontos percet, a riasztás órát és a riasztás percet állító állapotba, majd vissza a normál mőködési állapotba. A riasztás óra és a riasztás perc beállítása ugyanúgy az óramezıben, illetve a percmezıben történik, mint a pontos óra, illetve a pontos perc állítása; azzal a különbséggel, hogy a riasztás óra és a riasztás perc beállításakor ezek értéke látszik az óramezıben, illetve a percmezıben, és villog az ALARM szöveg az alarmmezıben. Beállításkor bármely értéket a SET gombbal lehet egyesével elıre léptetni, a maximális érték elérését követı léptetés a minimális értéket állítja be (például az óramezıben a 23 óra utáni léptetés 0 órát eredményez). HH.NN ÓÓ.PP ALARM SELECT SET ALARM ON/OFF Digitális óra A ábra a keretezett feladat egy vázlatos megoldását mutatja. Az ábra értelmezését az olvasóra bízzuk, de dolgát megkönnyítendı itt közlünk néhány tudnivalót: selectgomb: A SELECT gomb lenyomása esemény. setgomb: A SET gomb lenyomása esemény. alarmonoffgomb: Az ALARM ON/OFF gomb lenyomása esemény. percórajel: Órajel esemény, amelyet percenként kap a digitális óra. frissítés(): Ezt a mőveletet maga a digitális óra hajtja végre. A mővelet azt jelenti, hogy a digitális óra frissíti a saját hónap, nap, pontosóra, pontosperc attribútumainak értékét (legtöbbször csak a pontospercet, és csak 60 percenként a pontosóra értékét, és csak 24 óránként a nap értékét,...) entry: Egy állapotdoboz belsejében olyan akciót jelöl, amely mindig végrehajtódik, amikor az objektum az adott állapotba lép. kijelzı.frissítés(p): A digitális óra felkéri egyik alkatrészét, a kijelzıt a frissítés mőveletre p paraméterrel. Ennek hatására változik a kijelzın látott tartalom. A p paraméter maga is objektum, amely minden olyan adatot tartalmaz, amely alapján a kijelzı az adott állapotnak megfelelı tartalmat jeleníti meg. Például a Normál mőködés állapotba lépéskor olyan p paraméter megy ki a kijelzıhöz, amely alapján az a hónap, a nap, a pontosóra, és a pontosperc értékeket jeleníti meg a hónapmezıben, a napmezıben, az óramezıben és a percmezıben; az alarmmezıben pedig aszerint világít vagy nem az ALARM szöveg, hogy a Normál mőködés állapotba lépés konkrétan a Riasztás kikapcsolva vagy a Riasztás bekapcsolva állapotba lépést jelent-e. Ezzel szemben a Riasztás óra állítása állapotba lépéskor olyan p paraméter megy ki a kijelzıhöz, amely alapján az a riasztásóra, és a riasztásperc értékeket jeleníti meg az óramezıben és a percmezıben; az alarmmezıben pedig villog az ALARM szöveg, továbbá villog az óramezı tartalma is, azzal jelezve, hogy aktuálisan ennek a mezınek a tartalma léptethetı a SET gombbal.

76 216 INFORMATIKUS SZAKMAI ISMERETEK stm Digitális óra Normál mőködés + entry / kijelzı.frissítés(p) + percórajel / frissítés() Riasztás kikapcsolv a alarmonoffgomb /kijelzı.frissítés(p) alarmonoffgomb /kijelzı.frissítés(p) Éppen nem riaszt Riasztás bekapcsolv a percórajel percórajel [pontosóra=riasztásóra AND pontosperc=riasztásperc] Éppen riaszt + do / hangjelzés() selectgomb Nap állítása Hónap állítása + entry / kijelzı.frissítés(p) + setgomb / hónapléptetés() selectgomb + entry / kijelzı.frissítés(p) + setgomb / napléptetés() selectgomb selectgomb Pontos perc állítása + entry / kijelzı.frissítés(p) + setgomb / pontospercléptetés() selectgomb Pontos óra állítása + entry / kijelzı.frissítés(p) + setgomb / pontosóraléptetés() selectgomb Riasztás óra állítása + entry / kijelzı.frissítés(p) + setgomb / riasztásóraléptetés() selectgomb Riasztás perc állítása + entry / kijelzı.frissítés(p) + setgomb / riasztáspercléptetés() ábra: A digitális óra állapotdiagramja A DigitálisÓra osztály definíciójának kialakítása céljából a digitális óra állapotdiagramját mutató ábráról leolvasható, hogy a digitális óra objektumnak tudni kell reagálni a percórajel, az alarmonoffgomb, a selectgomb és a setgomb eseményekre; azaz a DigitálisÓra osztály definíciójában meg kell jelenni a megfelelı reagáló mőveleteknek. A percórajel/frissítés() specifikáció szerint a percóra- Jel eseményre reagáló mővelet a frissítés(). A setgomb eseményre reagáló mővelet több is van, ilyenek: a hónapléptetés(), a napléptetés(), a pontosóralép-

77 INFORMÁCIÓRENDSZER FEJLESZTÉSE 217 tetés(), a pontospercléptetés(), a riasztásóraléptetés() és a riasztáspercléptetés(). A digitális óra kijelzı.frissítés(p) akciója alapján (amely annyit tesz, hogy a digitális óra felkéri a kijelzı objektumot a frissítés mőveletre p paraméterrel) az következik, hogy a Kijelzı osztálynak lesz egy frissítés(p) mővelete. Ugyanezen diagram állapotait tekintve, megállapítható, hogy a DigitálisÓra osztály szerkezetében kell lenni egy olyan attribútumnak, amelynek értékei megkülönböztetik a Normál mőködés, a Hónap állítása, a Nap állítása, a Pontos óra állítása, a Pontos perc állítása, a Riasztás óra állítása és a Riasztás perc állítása állapotokat; továbbá olyan attribútumnak is, amelynek értékei megkülönböztetik a Riasztás kikapcsolva és a Riasztás bekapcsolva állapotokat. Tevékenységdiagram A tevékenységdiagram eredetileg az üzleti folyamatok ábrázolásának céljából került az UML-be, de kiválóan használható az objektumokból összerakott alkalmazások mőködésének, azaz az alkalmazásban végbemenı folyamatnak (vagy párhuzamos folyamatoknak) a leírására is. Ez a technika tulajdonképpen a szekvenciadiagram és az állapotdiagram lehetıségeit egyesíti. A szekvenciadiagramhoz abban hasonlít, hogy több (példa)objektum (bonyolultabb esetben több folyamatszál) kölcsönhatását képes ábrázolni. Az állapotdiagramhoz abban hasonlít, hogy az érintett objektumoknak (folyamatszálaknak) a kölcsönhatás alatti (miatti) állapotait (állapotváltozásait) is mutatja; továbbá abban is, hogy nem csak kiragadott esetek modellezhetık vele: a tevékenységdiagram egy folyamat vagy több konkurens folyamatszál idıbeli lefutásának általánosan érvényes ábrázolása. (A általánosan érvényes azt jelenti, hogy a diagram a folyamat bármely alkalommal, bármilyen feltételek melletti lefutására érvényes.) Tevékenységdiagrammal egy folyamatot olyan részletességgel is ábrázolhatunk, hogy a diagramon szereplı minden tevékenységrıl megmondható, hogy az melyik objektum tevékenysége. Egy durvább felbontású diagramon azonban több, idıben egymást követı, ráadásul különbözı objektumok által végrehajtott tevékenység egyetlen összetett tevékenységbe olvad össze, ami már nem tekinthetı semelyik benne érintett objektum tevékenységének sem. Így az az állapot, amelyben ez az összetett tevékenység végrehajtódik, már nem valamelyik objektum állapotának, hanem a folyamat vagy részfolyamat vagy egy folyamatszál állapotának fogható fel. A tevékenységdiagram elemei: A tevékenységeket a diagram lekerekített sarkú dobozai jelképezik, egyébként a tevékenységek értelmezése hasonló az állapotdiagramnál adotthoz, tehát ez egy idıtartammal bíró mőveletsor, ami megszakítható például egy másik folyamat(szál) által küldött jelzés által. Ugyanakkor mint azt fentebb indokoltuk itt a tevékenység nem mindig tekinthetı egyetlen objektum sajátjának. Az akció értelmezése azonos az állapotdiagramnál adottal, tehát ez egy megszakíthatatlan atomi mővelet. Az kezdı állapot és a záró állapot jele azonos az állapotdiagramnál adottal. A szimbólumok értelmezése azonban csak hasonlít az állapotdiagramnál adotthoz: A kezdı és a záró állapot itt mindig az egész folyamat kezdetét, illetve végét jelenti. Idıbeli sorrend (átmenet): A tevékenységdiagramon az állapotdiagraméval azonos átmenet(nyíl) mutatja az állapotok (itt inkább tevékenységek) idıbeli sorrendjét.

78 218 INFORMATIKUS SZAKMAI ISMERETEK Azonban itt ez a nyíl gyakran nem átmenetet, hanem objektumok közötti vezérlésátadást jelent, amikor is például egy objektum valamely tevékenységébıl (kvázi állapotából) egy másik objektum tevékenységébe (állapotába) mutat. Elágazás: Amikor egy adott A tevékenységre következı tevékenység a folyamat különbözı lefutásainak alkalmával valamilyen feltételtıl függıen más-más lehet, akkor ezt az A állapot után beiktatott elágazással lehet lekezelni. Az elágazás szimbólum egy sarkára állított rombusz. Az elágazásból kiinduló ágakhoz egymást kizáró ırszemek vagy else rendelkezés tartozhatnak. Az elágazásból a folyamat mindig csak egy ágon folytatódhat: ha valamelyik ırszemben foglalt feltétel teljesül, akkor az annak megfelelı ágon, különben ha adott egy else ág, akkor azon. Ha egyik feltétel sem teljesül és nincs else ág sem, akkor az a folyamat(szál) végét jelenti. Meg kell jegyezni, hogy az elágazás szimbólum alkalmazása gyakran elkerülhetı, mert a folyamat bármely tevékenységnél elágazhat. A ábrán erre példa az a megoldás, hogy a Startlap letöltése tevékenyég maga képez elágazást. İrszem: Az ırszem szögletes zárójelek közötti szöveggel vagy logikai kifejezéssel adott feltétel, amit elágazásból kifelé vezetı nyilakon (ágakon), vagy egy szinkronizáció (lásd alább) mellett tüntethetünk fel. Párhuzamosság / szinkronizáció: A párhuzamosság és a szinkronizáció szimbóluma egyaránt egy vastag vonal (erre a ábrán látható példa). A párhuzamossággal azt a pontot jelöljük, amelytıl a folyamat egyidejőleg (tehát nem alternatívan) több konkurens (párhuzamos) szálon halad(hat) tovább. A párhuzamosságot nem kell feltétlenül párhuzamos végrehajtással megvalósítani, gyakran a párhuzamosság mindössze azt jelzi, hogy a különbözı szálakhoz tartozó tevékenységek sorrendje egymáshoz képest tetszıleges lehet. A párhuzamos szálak egyesítése történhet szinkronizációval vagy anélkül. Szinkronizációval egyesített szálak esetén a folyamat csak akkor léphet tovább (a szinkronizáció utáni tevékenységre csak akkor kerülhet sor), ha mindegyik szál tevékenységei végrehajtódtak; kivételt képez, ha a szinkronizáció mellett ırszemet tüntetünk fel, mert akkor az elsı olyan beérkezı szál, amely az ırszemben adott feltételt teljesíti, az azonos párhuzamossághoz tartozó összes többi szálat megszakítja, és a folyamat a szinkronizációt követı tevékenységgel folytatódik. A szinkronizáció nélkül egyesített szálak közül bármelyik fejezıdik be legkorábban, az a többi szál tevékenységének megszakítását okozza. Egyébként párhuzamos szálakból álló folyamat szinkronizáció és záró állapotok hiányában akkor fejezıdik be, ha minden szál olyan állapotba kerül, amelybıl kifelé nem mutat átmenetnyíl, és a szál befejezi az adott állapotban elıírt tevékenységét. Sávok: Az UML-ben egy tevékenységdiagram mezıjét (függıleges vagy vízszintes) sávokra oszthatjuk fel. A különbözı sávok alapesetben különbözı (példa)objektumokat képviselnek. Ha azonban sok objektum mőködik együtt egy folyamatban, a diagram áttekinthetıbb, ha több egymáshoz szorosabban kapcsolódó objektum kap egy sávot, minek következtésben az ilyen sáv már nem egy objektumot, hanem egy objektumcsoporthoz tartozó részfolyamatot képvisel. Üzleti folyamatot modellezı tevékenységdiagramon a sávok a folyamat szereplıit (szervezeti egységeket, munkaköröket, partnereket) reprezentálnak. Ha sávokat alkalmazunk, akkor minden tevékenységet az azt végrehajtó objektum / részfolyamat / szerepkör sávjába kell elhelyezni.

79 INFORMÁCIÓRENDSZER FEJLESZTÉSE 219 act UPS-Toshiba1 Ügyfél UPS csomagfelvevı UPS disztribúciós központ Toshiba mőhely Laptop meghibásodása Leadás a UPS csomagfelv ev ınél Laptop [Átvéve] Szállítás a UPS központba Laptop [Központba érkezett] Szállítás a Toshiba mőhelybe Laptop [Mőhelybe érkezett] Laptop [Kijavított] Jav ítás Laptop [Kijavítva megérkezett] Szállítás az ügyfélhez Meghibásodás után 6-8 napra ábra: A meghibásodott Toshiba laptopok szállítási és javítási folyamata Objektumfolyam, állapotnév: Amikor az egyik objektum vagy részfolyamat (a továbbiakban: részfolyamat) tevékenységének eredményét egy másik részfolyamat felhasználja (esetleg módosítja), akkor ezt a viszonyt objektumfolyammal lehet kifejezni. Az objektumfolyam a következıkbıl áll: az átadott objektumot képviselı téglalapból (benne az objektum osztályára utaló objektumhivatkozással), valamint egy olyan nyílból, amely az elıállító részfolyamattól az átadott objektum felé mutat, és egy olyan nyílból, amely az átadott objektumtól a felhasználó részfolyamat felé mutat. Az átadott objektum jelentheti egy hívásjellegő üzenet kimenı paraméterét, jelenthet konkurens részfolyamatok (szálak) között alkalmazott üzenetobjektumot, de jelentheti egyszerően csak azt, hogy a vezérlést korábban és késıbben birtokló részfolyamatok egy közös objektumot érnek el (kezelnek). Azonos objektum többször és különbözı

80 220 INFORMATIKUS SZAKMAI ISMERETEK irányokban is átadódhat a részfolyamatok között, azaz többször is elıfordulhat egy tevékenységdiagramon, miközben feltehetıen változik az állapota. Ezért az objektumáram dobozában az objektumhivatkozás után szögletes zárójelek között állapotnevet is meg lehet adni. (Erre a ábrák mindegyikén látható példa.) A és a ábra a tevékenységdiagram üzleti (szakterületi) folyamatok ábrázolására való alkalmazását mutatja. Ilyen ábrák inkább az elemzési szakaszban, a megfigyelt folyamatok modellezésére szolgálnak és közvetve a folyamatot támogató szoftverekkel szembeni követelmények megfogalmazását segítik. (A két ábra megjelenésbeli különbségét az magyarázza, hogy az ábrák különbözı CASE-eszközökkel készültek.) A meghibásodott Toshiba laptopok szállítási és javítási folyamata (forrás: [Friedman ]): A meghibásodott Toshiba laptopok javítása egy idıben a következı rendszerben történt. Az ügyfél leadja a gépet a UPS helyi csomagfelvevıjénél, amely a gépet UPS disztribúciós központjába szállítja, az utóbbi, pedig a Toshiba mőhelybe repteti, ahol megtörténik a javítás. A kijavított gép ellenkezı irányban a UPS disztribúciós központjának érintésével kerül vissza az ügyfélhez. A keretezett példában leírt szállítási és javítási folyamat tevékenységdiagrammal adott modelljét a ábra mutatja. A diagram függıleges sávjai a folyamat Ügyfél, UPS csomagfelevevı, UPS disztribúciós központ és Toshiba mőhely részvevıit képviselik. Mindegyik tevékenységet az a részvevı hajtja végre, amelynek sávja a tevékenységet tartalmazza. A tevékenységeket a meghibásodott laptopot képviselı objektumáram kapcsolja össze. Megjegyzés: A ábrához hasonló diagramokat nem csak a szoftverfejlesztést, hanem az üzleti folyamatok újraszervezését célzó projektekben is használnak. Például az ábráról leolvasható, hogy ha a Toshiba kiszervezi a UPS-hez a javítást, akkor a folyamat a vastag vonalakkal jelzett szállítások megtakarításával jelentısen lerövidíthetı, és várhatóan kevesebb költséggel jár. Hajózói kérések kezelése egy légitársaság intranet rendszerében: A légitársaság tervezett intranet rendszerével szemben elvárás volt egyebek mellett lehetıvé tenni, hogy a hajózók (pilóták és légiutaskísérık) a járatbeosztásukra, illetve járatbeosztás-módosításra vonatkozó kéréseiket rögzíthessék, és ha a kérést a vezetı jóváhagyja, azt a járatbeosztást kialakítók (az adott légitársaság zsargonjában a mősorkészítık ) vegyék figyelembe a beosztáskészítés következı menetében. A legutóbbi keretezett példában leírt intranetszolgáltatás tevékenységdiagrammal adott modelljét a ábra mutatja. A folyamatot a hajózó kezdeményezi a Kérés feladása tevékenységgel. Ennek eredményeként egy feladott állapotú Kérés objektum keletkezik a rendszer adatbázisában, és azzal egyidejőleg egy sms értesítés (az ábrán Értesítés kérésrıl objektum) is továbbítódik a vezetıhöz. A Kérés feladása dobozba visszamutató átmenet a kérés módosítás() [még nem engedélyezett] specifikációval együtt jelzi, hogy a hajózó mindaddig módosíthatja a feladott kérést, amíg az a még nem engedélyezett állapotban van (vagyis amíg azt a vezetı nem vette kézbe ). Az a párhuzamosság szimbólum (lásd a vastagabban húzott vízszintes vonalat), amelyben a feladott állapotú Kérés objektumáram és az elküldött állapotú Értesítés kérésrıl objektumáram találkozik, annak határozatlanságára utal, hogy a vezetı milyen sorrendben hajtja végre a Kérésrıl értesítés olvasása és a Kérés engedélyezése tevékenységeket. Magyarul egyformán lehetséges a következı két eset: (1) A vezetı elıbb az sms üzenetet olvassa, és ennek hatására leül a számítógép elé és belép a Kérés engedélyezése funkcióba. (2) A vezetı anélkül, hogy az sms üzenetet olvasta volna belép a

81 INFORMÁCIÓRENDSZER FEJLESZTÉSE 221 Kérés engedélyezése funkcióba, és a neki címzett kéréseknek ott automatikusan megjelenı listájából elıveszi az engedélyezendı kérés(eke)t. A Kérés engedélyezése tevékenység vagy elutasítással vagy jóváhagyással zárul. Az eseményrıl mindenképpen megy értesítés a hajózónak (lásd az elküldött állapotú Értesítés az engedélyezésrıl objektumáramot). A jóváhagyott kérés a mősorkészítı számára is látható lesz az adatbázisban, azt a mősorkészítés következı menetében figyelembe kell vennie ábra: Hajózói kérések elbírálásának tevékenységdiagramja Felhasználói bejelentkezés egy, háromrétegő architektúrában mőködı alkalmazásba: Egy olyan alkalmazást tekintünk, amelynek a komponensei az együttmőködı gépek következı három rétegét használják: (1) A kliens munkaállomás a felhasználó és az alkalmazás közötti párbeszédet bonyolítja. (2) A mögöttes üzleti logikát megvalósító komponensek a webszerveren futnak. (3) A rendszer adatbázisát a DB szerver tárolja, és ezen fut az adatbáziskezelı rendszer is. A felhasználó a kliens munkaállomáson kezdeményezi az alkalmazás indítását (ahogy például a hallgatók a böngészıben a Neptun alkalmazást indítják). A kezdeményezést az indított (a böngészıben a megcímzett) alkalmazás érzékeli, és letölt egy bejelentkezı lapot (egy login ablakot) a kliensre. A felhasználó ezt a lapot kitöltve közli a login adatait (felhasználói név és jelszó), amelyek segítségével a webszerver lekéri az adatbázisból a felhasználó hozzáférési jogosultságait. Ha az adatbázisszervertıl visszakapott válasz szerint az adott login adatokkal nincs felhasználó az adatbázisban, vagy van, de nem rendelkezik az alkalmazás futtatásához szükséges joggal, akkor a webszerver egy elutasító lapot, egyébként pedig az alkalmazás fımenüjét tölti le a kliensre. A keretezett példában leírt folyamatrészletet a ábra tevékenységdiagramja modellezi. Ilyen ábra már nem az elemzés során és nem az üzleti folyamatokról készülı modellre