4. Információrendszer fejlesztése

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

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 12207 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 4.2.3. szakasz) tárgyalja. A 4.2.4. 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.

143

INFORMÁCIÓRENDSZER FEJLESZTÉSE

4.2 Szoftverrendszerek fejlesztésének folyamata és eszközei 4.2.1 A fejlesztési folyamat tevékenységei A szoftverfejlesztési folyamat tevékenységeit az ISO 12207 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 Projekt

Rendszer

Szoftver

Kivitelezés, tesztelés, bevezetés

Folyamatkialakítás

Rendszerkövetelmények elemzése

Rendszer nagyvonalú tervezése

Szoftver telepítése

Szoftver átvételi támogatása

Rendszerintegrálás

Rendszer minıségi tesztelése

Szoftverkövetelmények elemzése

Szoftver minıségi tesztelése Szoftver nagyvonalú tervezése Szoftver részletes tervezése

Szoftverintegrálás Szoftverkódolás és -tesztelés

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.

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 4.2.3. 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 12207 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 4.2.3. 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;

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 4.6.1. 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 4.4-4.5. 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.

146


A szoftver nagyvonalú tervezése 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 4.6.1. 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.


147

A szoftver minıségi tesztelése 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. 4.2.2 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 (4.6.2. szakasz).

148

INFORMATIKUS SZAKMAI ISMERETEK Szoftverfejlesztési megközelítési mód

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ö-


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

150


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 4.4.2. 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 4.4.2. 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-


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.

152


Felhasználóvezérelt módszertanok 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 4.2.3. 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.

4.2.3 Életciklusmodellek Mint arról a 4.2.1. 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-

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ó.)

Elırehaladás

Elemzés

Visszacsatolás Tervezés

Kivitelezés és egységteszt

Integráció és rendszerteszt

Mőködtetés és karbantartás 4.2. ábra: Vízesés modell

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-

154


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öhl1993], amelynek több elemét az ISO 12207 szabvány is átvette (lásd a 4.2.1 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 minıségi tesztelése

Szoftver elemzése

Szoftver nagyvonalú tervezése

Szoftver részletes tervezése

Szoftver integrálása

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

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-

156


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ı team

Elemzés

Tervezı team 2.inkrementum

Tervezés

Kivitelezı és integrációs team

Elemzés 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;


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. 4.2.4 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] 3.16. á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.

158

INFORMATIKUS SZAKMAI ISMERETEK Szoftverfejlesztés eszköztára

Eszközök

Szerkesztık

Fordítók

Eszközkészletek

Állományösszehasonlítók

Elemzés és tervezés

Egy modellezési technika

Több modellezési technika

Integrált környezetek

Programozás

Általános célú eszközkészlet

Környezetek

Folyamatközpontú környezetek

Tesztelés

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 4.3-4.6. alfejezetekben ismerkedhet meg az olvasó. E szakasz további részében csak a


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 4.6.4. szakasz tárgyalja.

160


4.2.5 Ellenırzı kérdések a 4.2. alfejezethez

1. Az ISO 12207 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?


161

4.3 Célkitőzés, követelmények 4.3.1 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 4.3.3. 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. 4.3.2 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 14598 szabvány követi, de annak a tárgyalásától itt eltekintünk.

162


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., 1998. és 1999. é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!)


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 17799 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.

164


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;

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.

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.


167

Hordozhatóság 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). 4.3.3 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.

168


A követelmények forrásai 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 Vált.igények Karbantartás

Problémanyilvántatás, válltozáskezelés

Fejlesztés

Üzemeltetés, használat

Probléma

4.7. ábra: A fejlesztési, üzemeltetési, problémakezelési és karbantartási folyamatok kapcsolatai

Termékek 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.

169

INFORMÁCIÓRENDSZER FEJLESZTÉSE 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 4.5.1. 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

«extend»

Számla áttekintı

Egyenleg

Beállítások «extend»

Postaláda kezelése

Számlainformációk kérése Ügyfél

Bankkártya mőv eletek «extend»

«extend»

Számlatörténet

Számlakiv onatok

Megbízások «extend»

Forint átutalás

«extend» «include»

«include» «extend»

«extend» Forint átv ezetés

Idıszak beállítása

Kötegelt átutalás

Dev iza átutalás

«include» «extend»

Megbízásokat tartalmazó fáj l kij elölése

Átutalás fizetési mód

«extend»

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

170


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 4.6.3. 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


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. uc Actorok

•

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.

Ügyfél

Felhasználó

Ügyfélszolgálati ügyintézı

Pénztáros

4.9. ábra: Általánosítás és specializáció aktorok között

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. 4.3.4 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ásosak2, 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.

172


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. 4.3.5 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?


173

7. 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?

174


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. 4.4.1 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 4.3.2. 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.


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 4.2.2. 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ó.

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 1.4.3 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.


•

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 Adat

Feldolgozás

Szintek Fogalmi szint

A szakterületi igények, szabályok figyelembe vétele A kiszolgált szakterület adatai és ezeknek a szakterület szabályaiból következı kapcsolatai

Logikai szint

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

Fizikai szint

Felhasználói felület / Környezet, események

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

4.10. táblázat: A rendszertervezés szintjei és vetületei a hagyományos strukturált szemlélet szerint

178


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 4.2.1. szakaszban a fejlesztési folyamat ISO 12207 szerinti tevékenységeit). Az objektumorientált technológiák (lásd a 4.2.2. és a 4.4.2. szakaszokban) elterjedése a problémáknak és a megoldásoknak a 4.10. 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 4.11. á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.

4.11. ábra: A SunTone módszertan 3 dimenziós osztályozási sémája [Sun-2002] [Sun-2007]

A 4.11. á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.


• •

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 4.11. á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 4.2.1. 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 4.3.2. 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. 4.4.2 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 4.2.2. 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

180


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 4.12. á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

4.12. ábra: Az objektum mint szerkezet és viselkedés egysége


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

182


(lásd a 4.5.1. 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 4.14. á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

Objektum (példány) az osztályból

Példányosítás

bankszámla1:Bankszámla bankszámlaszám: 10023401 számlatulajdonosnév: Kiss József pénznem: HUF kamatláb: 15 egyenleg: 515.879

4.13. ábra: Osztály és példánya

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)


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 4.14. á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 4.14. á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.

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()

fıosztály (szülı osztály)

Ingatlan Az alosztály tényleges teljes sémája (az örökölt + saját)

Ingatlan

helységnév helyrajzi szám terület

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()

alosztály (utód osztály)

4.14. á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 4.14. á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 4.4.1. 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.


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 4.4.1. 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()

186


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.


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. 4.4.3 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 4.6.2. és 4.6.3. 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 4.10. 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 12207 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,

188


• 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 4.10. 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


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 absztrakt4 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 4.6.3. szakaszban találhatók.). Az absztrakt specifikációk például • használati esetek (lásd a 4.3.3. szakaszban), • használati eseteket tartalmazó csomagok, illetve • csomagdiagramok (lásd a 4.5.5. 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 4.6.3. 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 4.5.4. szakaszban), • használati esetek (lásd a 4.3.3. 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.

190


• csomagdiagramok (lásd a 4.5.5. 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 4.5.3. 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 4.5.4. szakaszban); • az elıbbieket tartalmazó csomagok, illetve • csomagdiagramok (lásd a 4.5.5. 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). 4.4.4 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?


191

5. 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?

192


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). 4.5.1 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 4.4.2. 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: 1995: 1996:

1997: 19982002. 2003. 2005.

Rumbaugh és Booch szándéknyilatkozata közös OO rendszerfejlesztési módszer kidolgozására Az OMT és a Booch módszerek egyesítésének vázlata 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. 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. Sorban jelennek meg az UML újabb verziói 1.2: 1998, 1.3: 1999, 1.4: 2001, 1.5(munkaverzió): 2002. [Booch-1998] [Rumbaugh-1998] [OMG-2001] [OMG-2002] UML 1.5 UML 2.0

(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.

193


Az UML részét képezi a 4.3.3. 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. 4.5.2 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 4.3.3. szakaszban, vagy az «interface» sztereotípust a 4.4.3. 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 4.15.. ábrán). «entity» Vevı

Vevı

«entity» Vevı

Vevı

4.15. ábra: Az «entity» sztereotípia nevének és/vagy jelének használata

194


4.16. á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 4.13-4.14. á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 4.16. á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 4.3.3. szakaszban). A megszorítást a vele jellemzett modellelem neve után vagy alá {} zárójelek közé kell írni, mint a 4.17. á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 4.17. á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-


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 }

4.17. á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 = 2002.08.09., version = 1.1.3}. 4.5.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 4.5.5. 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 4.18. á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.

196


Megszerkesztendı a 4.18. á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.

6

A probléma reprezentálására többféle objektummodell képzelhetı el, azonban a 4.19. á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útu49 ma, mégpedig a szakasz hossza, szükségképpen az útszakaszt is objektummal kell modellezni.

C 50

41 65

A

D 35

45 B

70

47 40

81

79

F

E

G 35

6

A 4.20. á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.)

4.18. á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 4.4.2. 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.

197

INFORMÁCIÓRENDSZER FEJLESZTÉSE obj ect Úthálózat OD R1

-szomszed -szomszed

C :Telepules

-szomszed

-szomszed

-szomszed -szomszed

-szomszed A :Telepules

D :Telepules -szomszed

-szomszed

-szomszed

-szomszed -szomszed B :Telepules

F :Telepules -szomszed

-szomszed

-szomszed -szomszed -szomszed E :Telepules -szomszed

G :Telepules -szomszed

4.19. ábra: A probléma egy elhamarkodott objektummodellje obj ect Ú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

ab :UtSzakasz

-szomszed

B :Telepules

A :Telepules -irany[3]

-irany[4] ae :UtSzakasz

-szomszed

E :Telepules

4.20. ábra: A probléma egy jobb modellje, amely azonban nem teljesíti a c) feltételt

198


obj ect Úthálózat OD -elsoIrany

-kovetkezo

ac :UtSzakasz szakaszHossz:=50

ad :UtSzakasz szakaszHossz:=65

-szomszed C :Telepules

D :Telepules

-szomszed

-szomszed

-szomszed -elsoIrany

ab :UtSzakasz szakaszHossz:=35

-szomszed -szomszed

-szomszed

-szomszed

-kovetkezo

-kovetkezo

ae :UtSzakasz szakaszHossz:=70

-szomszed -szomszed

B :Telepules

E :Telepules

-szomszed -szomszed -elsoIrany

cc :UtSzakasz

-elsoIrany

dc :UtSzakasz

bd :UtSzakasz

-elsoIrany ed :UtSzakasz

-kovetkezo

-kovetkezo

cd :UtSzakasz

-kovetkezo

db :UtSzakasz

be :UtSzakasz

-kovetkezo eg :UtSzakasz

-kovetkezo

-kovetkezo ge :UtSzakasz

ca :UtSzakasz

fd :UtSzakasz

de :UtSzakasz -elsoIrany

-elsoIrany -szomszed A :Telepules

F :Telepules

-szomszed

-szomszed

gf :UtSzakasz

G :Telepules

-szomszed

-szomszed -szomszed

-szomszed -kovetkezo

-kovetkezo

da :UtSzakasz

-kovetkezo

df :UtSzakasz

-kovetkezo ba :UtSzakasz

-kovetkezo ea :UtSzakasz

4.21. ábra: A probléma olyan objektummodellje, amely teljesíti a feladat feltételeit

A 4.20. á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 2.3.2. szakasz megmutatta, hogy az elıbbi bekezdésben leírt változatosság lista tárolási szerkezettel kezelhetı. – A 4.21. á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

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 2.3.3. 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 4.14-4.17. 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 4.14. á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 4.22. á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 4.21. á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 4.21. ábra objektumdiagramjából elvonatkoztatott osztálydiagram a 4.22. ábrán látható. Bármilyen sok objektumot mutat is a 4.21. á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 0..1 -elsoIrany

Telepules -

telepulesNev: String

0..1

0..1

UtSzakasz

1 -

szakaszHossz: double

-szomszed +

getTelepulesNev() : String

+ 1

getSzakaszHossz() : double

1..*

4.22. ábra: A 4.21. á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

200


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 4.18. á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 4.21. á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 0..1 1(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 0..1 0..1(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


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 0..1 1(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 0..1 0..1(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 2.3.2. szakaszban ismertetett lista elemeit modellezı ListaElem osztály a 4.23. á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 4.23. á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.

202


class Úthálózat CD

ListaElem

0..1 + + -kovetkezo 0..1

telepulesNev: String

«listamővelet» + elemSzam() : int + listabanVan(ListaElem) : boolean + elemetHozzaad(ListaElem) : void + elemetBeszur(ListaElem) : void + elemetLevag() : void + elemetLevag(int) : void + elemetLevag(ListaElem) : void

-elsoIrany

Telepules -

getKovetkezo() : ListaElem setKovetkezo(ListaElem) : void

0..1

1

UtSzakasz -

szakaszHossz: double

+

getSzakaszHossz() : double

-szomszed +

getTelepulesNev() : String 1

1..*

4.23. á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


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. 4.5.4 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

204


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 4.6.3. 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 4.24. á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.

205

INFORMÁCIÓRENDSZER FEJLESZTÉSE 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 }

4.24. á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:

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ártyaSzlaBankDb 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.


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 4.24. á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, kartyaBankSzla) 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 4.25. és a 4.26. ábrák inkább a részletes tervezés közbeni elemzés céljából készülhetnek. A 4.25. á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

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 4.25. á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 4.6.1. 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 getKovetkezo() null 3

4.25. ábra: Egy lista elemeinek megszámlálásáról készült szekvenciadigram

A 4.26. á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 listabanVan(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()).

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 e5e6e7 haladás lehetséges, az e5e4 e3e2e1 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() null getKovetkezo() e4 [e4 != e5]: getKovetkezo() e5 true

4.26. á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()).

210


•

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 4.26. ábra szekvenciadiagramjával modellezett folyamat logikáját követi) a 4.6.1. 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 4.27. ábra egy korábbi szekvenciadiagrammal (4.24. ábra) egyenértékő együttmőködési diagramot mutat be.

4.27. ábra: A 4.24. á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á-


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 4.28. á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 4.6.3. 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-

212


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.

4.28. 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.


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 4.28. á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 4.28. á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 4.28. ábrán), ami az objektum életének kezdeti állapotát mutatja, vagy egy szuperállapoton belüli kezdıállapotot (lásd a 4.30. á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 4.28. á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 4.28. ábrán a Határidı elıtt szuperállapoton belül, valamint a 4.30. á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 4.28. ábrán a [megfelel] és [nem felel meg] ırszemekkel „felszerelt” ágakat. A 4.28. á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.)

214


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ó 4.28. á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 4.29. á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.


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

SELECT

SET

ALARM ALARM ON/OFF

4.29. Digitális óra

A 4.30. á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.

216


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) Riasztás bekapcsolv a Éppen nem riaszt

Éppen riaszt

percÓraJel percÓrajel [pontosÓra=riasztásÓra AND pontosPerc=riasztásPerc]

+

do / hangjelzés()

selectGomb Nap állítása Hónap állítása + +

selectGomb

entry / kiJelzı.frissítés(p) setGomb / hónapLéptetés()

+ +

entry / kiJelzı.frissítés(p) setGomb / napLéptetés() selectGomb

Pontos perc állítása

selectGomb

Pontos óra állítása selectGomb

+ +

entry / kiJelzı.frissítés(p) setGomb / pontosPercLéptetés()

+ +

entry / kiJelzı.frissítés(p) setGomb / pontosÓraLéptetés()

selectGomb Riasztás óra állítása

Riasztás perc állítása selectGomb

+ +

entry / kiJelzı.frissítés(p) setGomb / riasztásÓraLéptetés()

+ +

entry / kiJelzı.frissítés(p) setGomb / riasztásPercLéptetés()

4.30. á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ó 4.30. á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ÓraJel 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-


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.

218


•

• •

•

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 4.33. á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 4.32. á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.

219

INFORMÁCIÓRENDSZER FEJLESZTÉSE 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 [Kijavított]

Laptop [Kijavítva megérkezett]

Laptop [Mőhelybe érkezett]

Jav ítás

Szállítás az ügyfélhez

Meghibásodás után 6-8 napra

4.31. á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ı

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 4.31-4.33. ábrák mindegyikén látható példa.)

A 4.31. és a 4.32. á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-2005-2007]): 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 4.31. á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 4.31. á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 4.32. á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


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.

4.32. á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 4.33. á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

222


példa, ez jellemzıen a tervezés során készül, és egy alkalmazás belsı mőködésének egy részletét modellezi. A diagram értelmezését az olvasóra bízzuk. act Háromrétegő architektúra Kliens

Alkalmazás indítása

Felhasználói bej elentkezés

Elutasítás

Választás a fımenübıl

elutasítóLap

fıMenüLap

...

Webszerver bej elentkezıLap

bej elentkezıLap

[üres]

[kitöltött]

[nem jogosult] Bej elentkezı lap letöltése

Bej elentkezés kezelése

Startlap letöltése

loginAdatok

felhasználóJogai

[jogosult]

DB szerver

Select felhasználói j ogok

4.33. ábra: A felhasználói bejelentkezés tevékenységdiagramja háromrétegő architektúrában (részlet)

4.5.5 Csomagok és csomagdiagramok

Egy rendszer OO modellezése során rengeteg diagramot készítenek, modellelemek (alrendszerek, használati esetek, osztályok, interfészek, attribútumok, mőveletek stb.) sokaságát definiálják. A munka hatékonysága a modellelemek olyan áttekinthetı rendszerezését és nyilvántartását követeli meg, amely megkönnyíti ezek utólagos megkeresését és felhasználását. A már ismert osztályfogalom felfogható az attribútumok és mőveletek csoportosításának, maguk az osztályok és más összetettebb modellelemek (pl. diagramok) pedig az UML szerint csomagokba (package) szervezhetık. Egy csomagba valamilyen értelemben egymáshoz szorosan kapcsolódó (egymást erısen hivatkozó = egymástól erısen függı) modellelemeket sorolunk. A csomag az elrejtés egysége is, amikor egyes modellelemek éppen azért kerülnek egy adott csomagba, hogy azok a csomagon kívüli elemek számára láthatatlanok legyenek (kivéve amikor public minısítéssel idegen csomagok számára is láthatóvá tesszük ıket – lásd itt késıbb a definíciószintő látha-


223

tóságot). Ennek másik oldala az, hogy egy csomag elemei viszont általában közvetlenül hivatkozhatják (látják) egymást. A csomagokat is modellelemnek tekintjük, tehát alkotható olyan csomag is, amelynek az elemei maguk is csomagok, és így beszélhetünk egy csomag alcsomagjairól. A tartalmazás tekintetében a csomagok hierarchiát képeznek, mert minden modellelem (így egy csomag is) közvetlenül csak egy (tartalmazó) csomagba tartozhat. (Pontosabban a hierarchia tetején álló csomag kivételével minden elem határozottan egy csomaghoz tartozik közvetlenül.) – Az UML egy adott rendszer esetében a hierarchia tetején álló csomagot a «system» sztereotípussal jelöli. A csomag jele címkézett téglalap (=füles mappa – 4.34. ábra). Tömör ábrázolás esetén a csomagszimbólum belsejében állhat a csomag neve esetleg sztereotípussal és/vagy megszorítással kiegészítve (pl. a 4.34. ábrán a beszerzés). Részletezı (a csomag elemeit is mutató) ábrázolás esetén a név és az említett kiegészítések a címkerészbe (a fülrészbe) írhatók (pl. a logisztika és a vállalatirányítás csomag). «system» vállalatirányítás logisztika

beszerzés

értékesítés

készletgazdálkodás

4.34. ábra: Csomagdiagram – Csomagok tartalmazási hierarchiája és függısége

A csomag egyébként névterületet (namespace) is képez. Ez azt jelenti, hogy a modellelemek nevének csak egy-egy csomagon belül kell egyedinek lenni. Egy csomagban felhasznált nevet egy másik csomagban ismét felhasználhatjuk egészen más modellelemek azonosítására. Ebbıl viszont egyenesen következik, hogy ha egy csomagban publikussá nyilvánított (public) modellelemet másik csomagból akarunk hivatkozni, azt csak az elérési útvonallal lehet megtenni, amiben a hierarchia szerint felülrıl lefelé haladva fel kell sorolni a modellelem egyértelmő meghatározásához szükséges csoportneveket és végül a modellelem nevét. Az elérési útvonal összetevıit az UML-ben :: (négy pont) választja el egymástól. Például ha beszerzés csomag tartalamaz egy Szállító osztályt, akkor az kívülrıl így hivatkozható: vállalatirányítás::logisztika::beszerzés::Szállító, de ha a hivatkozás a logisztika csomagból történik, akkor elegendı a beszerzés::Szállító útvonalmegadás is. Megjegyzés: Az egyes programnyelvek esetében – pl. Java – az elérési útvonal hivatkozásban a „::” terminátor helyett a „.” (pont) használatos: vállalatirányítás.logisztika.beszerzés.Szállító. – Az is igaz, hogy a programozási környezetekben a magasabb szintő csomagok (al)könyvtárat, a hierarchia alján lévı (levél szintő) csomagok pedig fájlt (forráskódot, dokumentumot) jelentenek.

224


Az UML a csomagok között a tartalmazási hierarchián felül további relációkat (viszonyokat) is értelmez, ezek egyike a függıség. A csomagok közötti függıség azt jelenti, hogy az egyik (a függı) csomag elemei a definíciójukban meghivatkozzák a másik csomag elemeit. Ezt a viszonyt az UML szaggatott nyíllal jelöli. Tehát a 4.34. ábrán látható szaggatott vonalú nyilak konkrétan azt jelzik, hogy mind a beszerzés csomag, mind az értékesítés csomag valamilyen módon használja a készletgazdálkodás csomag elemeit. – A függıség definíciójából adódóan az egyik csomag elemei definíciójának megváltozása maga után vonja a másik (függı) csomag elemei definíciójának változását is. Ez a tény forráskódot tartalmazó csomagok esetében fordítási függıséget jelent: az egyik elem megváltozása esetén az attól függı elemeket is újra kell fordítani. Az általánosan használatos osztályok csomagjaitól szinte az összes többi csomag függ. Az UML lehetıvé teszi, hogy ilyenkor a rengeteg függıség jelzése (ami nagyon kusza diagramhoz vezetne) helyett az általánosan használt elemek csomagját – a csomag neve után álló – {global} megszorítással lássuk el. A csomag definíciója szerint az egymással erıs függésben álló modellelemeket azonos csomagba kell sorolni. Ebbıl következik, hogy a csomagok közötti függıségeket viszont minimalizálni kell.

eredménykimutatás

hazai eredménykimutatás

anyavállalat székhelye szerinti eredménykimutatás

4.35. ábra: Csomagdiagram – Csomagok közötti általánosítás/pontosítás

A csomagok közötti relációk megkülönböztetett típusa az általánosítás / pontosítás, ami tekinthetı a függıség speciális esetének is. Ez akkor áll fenn, ha az egyik csomagban (a pontosításban) foglalt elemek (osztályok) specializációi (kiterjesztései, vagy realizációi) a másik csomag elemeinek (ısosztályoknak, interfészeknek). A csomagok közötti általánosítás / pontosítás jelölése azonos az osztályok közötti általánosítás / specializáció jelölésével: a háromszögben végzıdı nyíl a pontosítástól az általánosítás felé mutat (4.35. ábra). Tisztázni kell egy látszólagos ellentmondást: Korábban azt mondtuk, hogy a csomag az elrejtés eszköze. Itt pedig a függıség definíciójában arra utaltunk, hogy a függı csomag elemei hivatkoznak egy másik csomag elemeire. – Miként lehetséges a rejtett elemekre hivatkozni? – A válasz az, hogy az elrejtés mértékét – ellenkezı oldalról tekintve a definíciószintő láthatóság mértékét – a programnyelvek mintájára az UML-ben is lehet szabályozni. A definíciószintő láthatóság azt jelenti, hogy egy osztály definícióját vagy annak részeit mely más osztályok definíciójában lehet felhasználni, esetleg (ha mőveletrıl van szó) újradefiniálni.


225

A definíciószintő láthatóságot ne keverjük össze az objektumok navigációval összefüggı láthatóságával! Az utóbbi azt jelenti, hogy adott objektum aktuálisan mely más objektumokat láthat, azaz közvetlenül mely objektumoknak küldhet üzeneteket. A két fogalom ott mégis találkozik, hogy amikor egy objektum a navigáció szerint lát egy másik objektumot, akkor a definíciószerinti láthatóság határozza meg, hogy az adott objektum a látott objektum mely attribútumait, illetve mőveleteit tudja közvetlenül elérni (meghivatkozni). A definíciószerinti láthatóság azonban alapvetıen osztályszintő fogalom, mert a hivatkozható attribútumok és mőveletek körét közvetlenül nem a konkrét objektum, hanem annak osztálya határozza meg: Ez a kör nem változik, ha az éppen látott objektumot lecseréljük az osztályának egy másik példányára.

Az UML-ben a definíciószerinti láthatóság szintjei: a public (publikus, jele: +), a private (saját jele: -) és a protected (védett, jele: #). A public láthatóság • attribútum és mővelet esetén azt jelenti, hogy az az osztályon kívülrıl is látható; • osztály esetén azt jelenti, hogy az (a publikus elemeivel együtt) a csomag határain kívül is látható; • csomag esetén azt jelenti, hogy az (a publikus elemeivel együtt) az ıt befoglaló csomag határain kívül is látható. A private láthatóság • attribútum és mővelet esetén azt jelenti, hogy az csak az osztályon belül látható; • osztály esetén azt jelenti, hogy az csak a csomagon belül látható; • csomag esetén azt jelenti, hogy az csak az ıt befoglaló csomagon belül látható. A protected láthatóság csak attribútumra és mőveletre értelmezett. Azt jelenti, hogy a jelölt elem az osztályán kívül is látható, de csak az osztályt tartalmazó csomagon belül, illetve más csomagokból csak olyan osztályokból, amelyek a jelölt elem osztályának leszármazottai. 4.5.6 Ellenırzı kérdések a 4.5. alfejezethez

1. Az UML-ben miért van szükség sztereotípusokra és megszorításokra? 2. Mi tartozik a sztatikus modell fogalmába? 3. Értelmezze a metaattribútum fogalmát! Mondjon rá példát! 4. Értelmezze az asszociáció (mint osztályok közötti viszony) fogalmát, és mondjon rá példát! 5. Értelmezze egy asszociációban betöltött szerep számosságát! A számosságból hogyan olvasható ki a szerepek kötelezı vagy opcionális volta? 6. Mi lesz az asszociációbeli szerepnévbıl a megvalósítás során? 7. A jelentés és a megvalósítás tekintetében milyen különbségek állnak fenn az adatmodellezés kapcsolattípus fogalma és az OO modellezés asszociáció fogalma között? 8. Szerkessze meg a multilista (lásd a 2.3.3. szakaszban) osztálydiagramját, ebben a Kapcsolat osztályt a ListaElem leszármazottjaként vegye fel! 9. Értelmezze a dinamikus modellezés fogalmát! Mi a dinamikus modellezés célja? 10. Tipikusan milyen jellegő attribútumokkal bıvülhet az osztály szerkezete a dinamikus modellezés eredményeképpen?

226


11. A dinamikus modellezés nézıpontjából világítsa meg az üzenet, esemény és mővelet fogalmainak összefüggését! 12. A kölcsönhatásdiagramokon: • mit képvisel a példaobjektum? • mit fejez ki az öndelegáció? 13. A szekvenciadiagramon a példaobjektum aktivitásának milyen szintjei különböztethetık meg? Ezekre alapozva értelmezze a vezérlési fókuszt! 14. Ábrázolja a 4.5.3. szakaszban adott listamőveletek belsı mőködését szekvenciadiagrammal vagy együttmőködési diagrammal! 15. Miben nyilvánul meg az, hogy az állapotdiagram egy típusszintő modell? 16. Milyen szimbólumokat tartalmazhat az állapotdiagram? 17. Értelmezze a következı fogalmakat: belsı állapot, külsı állapot, kiterjesztett állapot, konkrét állapot, absztrakt állapot, konkrét esemény, absztrakt esemény! A fogalmakat világítsa meg példákkal is! 18. Mi válthatja ki az állapotok közötti átmenetet? 19. Miben különbözik a tevékenység és az akció? 20. Egy ırszemfeltétel okozhat-e átmenetet, kiválthat-e akciót? 21. Értelmezze az automatikus átmenet fogalmát! 22. Egy átmenet mellett állhat-e a következı alakú rendelkezés: [ırszem]/akció ? 23. Hogyan írható le, hogy adott típusú objektum adott eseményt mely állapotaiban képes fogadni? 24. Értelmezze a fıállapot–alállapot viszonyt! 25. Milyen okai lehetnek annak, ha több állapotot egy szuperállapotba foglalunk? Mi ennek a haszna? 26. Egy szuperállapotra mutató átmenet esetén milyen eszközökkel tehetı egyértelmővé a folytatás? 27. Egy átmenethez az alábbi rendelkezés tartozik. Nevezze meg a rendelkezés részeit (szintaktikai egységeit), és értelmezze a rendelkezést! szállítás [nem felel meg] / szállítás.visszaküldés(vkP) 28. A Pohár osztály egyik példányának tartalmából átöntünk valamennyit egy másik pohárba (példányba). A következı állítások közül melyik igaz, melyik nem? • Ez az esemény állapotdiagrammal csak úgy ábrázolható, ha két különálló diagramot rajzolunk a két pohárnak. • Ez az esemény a Pohár állapotdiagramján nem ábrázolható, hanem csak egy olyan PohárPár kompozíció állapotdiagramján, ami a szóban forgó két poharat komponensként tartalmazza. • Ez az esemény egyetlen diagramon a Pohár állapotdiagramján ábrázolható. 29. Minek az ábrázolására használható a tevékenységdiagram? 30. Miért mondható, hogy a tevékenységdiagram a szekvenciadiagram és az állapotdiagram lehetıségeit egyesíti? 31. Milyen (szintaktikai) elemeket tartalmazhat a tevékenységdiagram?


227

32. Miben különbözik a kezdı állapot (záró állapot) értelmezése az állapotdiagramon és a tevékenységdiagramon? 33. Miben különbözik az átmenetnyíl értelmezése az állapotdiagramon és a tevékenységdiagramon? 34. A tevékenységdiagramon mit ábrázol • a sáv és • az objektumáram? 35. A tevékenységdiagramon hogyan ábrázolható az a tény, hogy a folyamatban „közlekedı” objektum állapotváltozásokon megy át? 36. Tegyük fel, hogy egy tevékenységdiagramban érintett objektumok kölcsönhatásáról szekvenciadiagram is készült. Hasonlítsa össze a két diagramot! 37. Milyen célokat szolgál a csomag fogalma? 38. Értelmezze a csomagok közötti következı relációkat: tartalmazás, függés, átalánosítás / pontosítás! Mondjon példát ezekre a relációkra! 39. Mit jelent a modellem elérési útvonala, és UML-ben azt milyen formában kell megadni? 40. Hogyan függ össze a modellelemek definíciószintő láthatósága a csomag fogalmával? 41. Mi a különbség a modellelemek definíciószintő láthatósága és az objektumok navigációval összefüggı láthatósága (navigálhatósága) között? 42. Milyen fokozatai lehetnek az attribútumok és a mőveletek definíciószintő láthatóságának?

228


4.6 Kivitelezés és bevezetés Mivel a szoftver kivitelezésének jelentıs része programozás, viszont a tankönyv nem programozók számára készült, így ezt a tevékenységet nagyon leszőkítve tárgyaljuk. Az a tény, hogy a 4. fejezetnek – a felületes kifejtés ellenére is – ez lett a második legterjedelmesebb alfejezete, a szükséges szakismeretek roppant sokaságára utal. 4.6.1 Kivitelezés, verifikáció és validáció

A kivitelezés (vagy megvalósítás) szőkebben értelmezve a szoftver forráskódjának megírását (röviden kódolását) és tesztelését jelenti. Ez a munka alulról felfelé a kisebb építıelemektıl (egységektıl) a nagyobb kompozíciók (modulok, alrendszerek) felé halad, annak megfelelıen, hogy a kompozíciók a már kész építıelemek „összeszerelésével” keletkeznek. A tesztelést egységenként maguk a fejlesztık végzik el, de a megbízhatóság javítása céljából független tesztelıket is alkalmaznak. Az összeszerelés megfelelıségének ellenırzésére szolgáló integrációs teszteket viszont kifejezetten független tesztelık végzik. A szakirodalomban a szoftver életciklusának részét képezı kivitelezés (megvalósítás) kifejezést éppen úgy, mint az angolból átvett megfelelıjét, az implementációt meglehetısen nagy rugalmassággal kezelik. Így van olyan tágabb értelmezése is, amely szerint beletartozik a részletes tervezés, másik végén az integráció (az elengedhetetlen integrációs teszttel) és a bevezetés is. Sıt, beszerzett szoftver esetében az implementáció kifejezetten a használatba vételt jelenti.

A szakirodalom megkülönböztet verifikáció és validáció célú tesztelést. Azonban a verifikáció és a validáció nem csak a kivitelezés idejére és nem csak a kivitelezés minıségének ellenırzésére szolgáló tevékenységek, ugyanúgy ahogy a szoftver sem a végrehajtódó programkódból áll. Verifikáció (igazolás): a beszerzı, a szállító vagy valamilyen független fél olyan tevékenysége, amely annak ellenırzésére (igazolására) szolgál, hogy a szoftvertermék megfelel a rávonatkozó terveknek, azaz más (ıt specifikáló) termékeknek. Validáció (érvényesítés): A beszerzı, a szállító vagy valamilyen független fél olyan tevékenysége, amely annak bizonyítására szolgál, hogy a szoftvertermék megfelel a rá vonatkozó szerzıdéses követelményeknek (bıvebben: a szerzıdésben és a felhasználói interjúkban megfogalmazott és a szerzıdı felek által érvényessé nyilvánított követelményeknek). [Boehm-1979] tömörebb megfogalmazásában: • Validáció: A megfelelı terméket készítettük el? • Verifikáció: A terméket jól készítettük el? (Közvetítı forrás [Sommerville-2002]) A verifikáció és a validáció (továbbiakban: V&V) szoftverátvizsgálás és szoftvertesztelés útján történhet. [Sommerville-2002] Szoftverátvizsgálás: Ez a tevékenység a szoftverfejlesztési folyamat bármely szakaszában alkalmazható. Átvizsgálás tárgya lehet bármely termék (akár dokumentum, akár programkód). A program forráskódjának átvizsgálása sem a program futtatásával, hanem a kód logikai elemzésével történik. Az átvizsgálásnak az a része, amely a megkülönböztetett figyelmet érdemlı gyanús elemek felderítését célozza, nagy mértékben automatizálható. A különféle specifikációk vizsgálatát segítı automatizmus az elemzı-tervezı CASE eszközbe, a forráskód


229

vizsgálatát segítı automatizmus pedig a kód szerkesztését támogató programozói környezetbe (fordítós nyelveknél a fordítóprogramba) épülhet be. A szoftverátvizsgálás statikus V & V technika, mert nem igényli a program futtatását. (Bıvebben lásd a 4.6.4. szakaszban.) Szoftvertesztelés: E tevékenység tartalma a szoftver végrehajtható kódjának tesztadatokkal (a tesztspecifikációban elıírt bemenetekkel) történı lefuttatása és annak ellenırzése, hogy a futtatás a specifikált kimenetet eredményezi-e, továbbá a szoftver hozza-e az elvárt teljesítményszintet és megbízhatósági szintet. A szoftvertesztelés dinamikus V & V technika, mert a végrehajtható kód futtatását feltételezi. A tesztelésen belül is megkülönböztethetı hiányosságtesztelés és statisztikai tesztelés. Hiányosságtesztelés: Ez a tesztelés a program specifikációja és megvalósítása közötti eltérések, ellentmondások, az ebbıl eredı hibák felderítésére irányul. [Sommerville-2002] Statisztikai tesztelés: Ez a tesztelés a program megbízhatóságának, valamint adott mőködési környezetben nyújtott teljesítményének ellenırzésére szolgál. Mivel a statisztikák az adatfeldolgozási mőveletek sokaságáról készülnek, ez a vizsgálat olyan tesztelést támogató szoftvert feltételez, amely felhasználók, illetve felhasználói mőveletek sokaságát szimulálja; méghozzá úgy, hogy a sokaságban a különbözı típusú szimulált bemenetek gyakorisága a valós feldolgozási esetek eloszlását kövesse. – Ebbe a kategóriába tartozik a stressztesztelés, amikor arra keresi a választ, hogy ha a rendszert szélsıséges terhelésnek teszik ki, az okoz-e adatvesztést vagy szolgáltatásösszeomlást. [Sommerville-2002] 4.6.2 Programegységek kódolása, tesztelése

Mint azt elıbb már láttuk, a szoftver kivitelezése a legalacsonyabb szintő programegységek kódolásával és tesztelésével kezdıdik. A kódolás normálisan a programegység részletes tervéhez igazodóan történik, illetve az egységtesztnek a részletes tervnek való megfelelıséget kell igazolnia. Ha a tervezés során valamilyen CASE eszközt használtunk, és az kódgeneráló funkcióval is rendelkezik, akkor a kódolás egy része automatizálható, mert a CASE eszköz a benne készült modellek alapján képes kódot generálni. Nem tartozik szigorúan ide, de kódolásról lévén szó, ki kell térni arra, hogy nem csak a végrehajtandó utasításokat kell kódolni, hanem az adatbázist definiáló SQL parancsokat is. Adatbázisdefiniáló SQL kód generálása Mivel az adatbázis felépítése ERD diagramokból (lásd a 2.7.2. szakaszban) álló adatmodellel (és az ERD diagramok elemeihez főzött metaattribútumokkal) teljes egészében leírható, a komolyabb CASE eszközök az adatmodellbıl 100 százalékban képesek legenerálni az adatbázisdefiniáló SQL parancsokat. Például a 4.36. ábrán mutatott ERD diagram a Sparx System által szállított Enterprise Architect CASE eszközzel készült, és ugyanez a szoftver a diagram alapján a következı SQL kódot generálta: /* A 4.36. ábra ERD-je alapján generált SQL kód */ CREATE TABLE Ugyiratok ( ID NUMBER(38) NOT NULL, Foszam NUMBER(10), Alszam NUMBER(4), Ev NUMBER(4), Tuk_szam VARCHAR2(100), Targy VARCHAR2(4000), Jelleg CHAR(2),

230

INFORMATIKUS SZAKMAI ISMERETEK Kategoria VARCHAR2(2), Eiv_ID_szulo NUMBER(38), Allapot VARCHAR2(2), Postazas_iranya VARCHAR2(1), Megkul_jelzes VARCHAR2(7), Ugyintezes_modja CHAR(1), Hatarido DATE, Skontroba_datum DATE, Lezarasdatum DATE, Selejtezesdatum DATE, Irattari_jel CHAR(2), Irattari_hely VARCHAR2(100), Sztornirozas_datuma DATE, Felelos_szervezet NUMBER(38) NOT NULL, Felelos_szemely NUMBER(38) NOT NULL, Orzo_szervezet NUMBER(38) NOT NULL, Orzo_szemely NUMBER(38) NOT NULL, Letrehozo NUMBER(38) NOT NULL, Letrehozas_ido DATE NOT NULL, Modosito NUMBER(38), Modositas_ido DATE

); CREATE TABLE Partnerek ( ID NUMBER(38) NOT NULL, Tipus VARCHAR2(2), Megnevezes VARCHAR2(80) NOT NULL, Erv_kezd_datum DATE, Erv_vege_datum DATE, Letrehozo NUMBER(38) NOT NULL, Letrehozas_ido DATE NOT NULL, Modosito NUMBER(38), Modositas_ido DATE, X500_azonosito VARCHAR2(100), Hierarchia VARCHAR2(100), Publikus_kulcs VARCHAR2(4000), LOVkulcs VARCHAR2(500), LOVkulcs_teljes VARCHAR2(4000), Kiszolgalo NUMBER(38) ); ALTER TABLE Ugyiratok ADD CONSTRAINT PK_Ugyiratok PRIMARY KEY (ID) ; ALTER TABLE Partnerek ADD CONSTRAINT PK_Partnerek PRIMARY KEY (ID) ; ALTER TABLE Ugyiratok ADD CONSTRAINT FK_Eiv FOREIGN KEY (Eiv_ID_szulo) REFERENCES Ugyiratok (ID) ; ALTER TABLE Ugyiratok ADD CONSTRAINT FK_Felelos_szemely FOREIGN KEY (Felelos_szemely) REFERENCES Partnerek (ID) ; ALTER TABLE Ugyiratok ADD CONSTRAINT FK_Felelos_szervezet FOREIGN KEY (Felelos_szervezet) REFERENCES Partnerek (ID) ; ALTER TABLE Ugyiratok ADD CONSTRAINT FK_Orzo_szemely FOREIGN KEY (Orzo_szemely) REFERENCES Partnerek (ID) ; ALTER TABLE Ugyiratok ADD CONSTRAINT FK_Orzo_szervezet FOREIGN KEY (Orzo_szervezet) REFERENCES Partnerek (ID) ;


231

Megjegyzés: Az adatbázisdefiniáló SQL parancsokat a 3.3.1. szakasz ismertette, de az az ALTER TABLE parancsot nem tárgyalta. Ez a parancs arra való, hogy egy tábla korábban (pl. CREATE TABLE paranccsal) adott definícióját utólag módosíthassuk vagy kiegészíthessük további elemekkel. Esetünkben a generált kód az ALTER TABLE parancsokat arra használta, hogy a táblák definícióját utólag elsıdleges kulcs (PRIMARY KEY) és idegen kulcs (FOREIGN KEY) megszorításokkal egészítette ki.

4.36. ábra: Egy CASE eszközzel készített ERD diagram – Az SQL kód generálásának forrása

Végrehajtandó programkód készítése Az adatfeldolgozó funkciók (programegységek) legrészletesebb terve is csak vázlatosan írja le, hogy a feladatát milyen módon kell megoldania az adott funkciónak. (Ha nem így lenne, akkor az azt jelentené, hogy a tervezés a programozás dolgát is vállára vette.) Így a legrészletesebb terv sem tartalmaz elegendı információt ahhoz, hogy egy CASE eszköz a végrehajtandó programkódot 100 százalékban le tudja generálni. Ez az oka annak, hogy a CASE eszközök a végrehajtandó programkódnak általában csak a vázát állítják elı automatikusan, és azt már a programozónak kell kitöltenie a „lágy részekkel”.

232


A 4.23. ábra osztálydiagramján adott ListaElem osztály Java nyelvő kódjának vázát az elıbbiekben már említett Enterprise Architect CASE szoftver az alábbi formában generálta le: public class ListaElem { private ListaElem kovetkezo; public ListaElem(){ } public void finalize() throws Throwable { } public ListaElem getKovetkezo(){ return null; } public void setKovetkezo(ListaElem e ){ } public int elemSzam(){ return 0; } public boolean listabanVan(ListaElem e){ return false; } public void elemetHozzaad(ListaElem e){ } public void elemetBeszur(ListaElem e){ } public void elemetLevag(){ } public void elemetLevag(int i){ } public void elemetLevag(ListaElem e){ } }

Nem szándékunk itt a Java nyelvet megtanítani, de a ListaElem osztály UML-ben és Javaban adott definíciói közötti megfelelések megértése céljából a Java nyelv néhány elemével kénytelenek vagyunk megismerkedni. Egy osztály definíciója Javaban a következı alakú: <minısítés> class { /* Ide jönnek az attribútumok és mőveletek definíciói*/ }


233

Példánkban ez a forma így konkretizálódott (a public minısítés a 4.5.5. szakaszban ismertetett publikus láthatóságnak felel meg): public class ListaElem { /* Ide jönnek a ListaElem attribútumainak és mőveleteinek definíciói*/ } A private ListaElem kovetkezo utasítás a kovetkezo nevő attribútumot definiálja (amely a 4.23. ábra ugyanilyen szerepnevébıl keletkezett). Vegyük észre az UML és a Java szintaktikája közötti következı különbséget: UML: : Java: Példánkban ez a különbség konkrétan így realizálódott: UML: - kovetkezo: ListaElem Java: private ListaElem kovetkezo A generált Java kód alábbi részének nincs megfelelıje a 4.23. ábrán, ezt a kódgenerátor „önszorgalomból” adta hozzá a ListaElem osztály definíciójához: public ListaElem(){ } public void finalize() throws Throwable { }

Eláruljuk, hogy a fenti kód már a ListaElem osztály két (publikus) mőveletének – a ListaElem() mőveletnek és a finalize() mőveletnek – a váza. Közülük az elsı a ListaElem konstruktora, ugyanis a Java nyelvben a konstruktort az jelzi, hogy a neve azonos az osztály nevével. (A finalize() mővelettel itt nem foglalkozunk.) A 4.23. ábra + getKovetkezo(): ListaElem + setKovetkezo(): void UML nyelvő mőveletspecifikációinak a generált Java kód alábbi része felel meg (amíg a visszatérési érték típusa az UML-ben a mővelet specifikációjának végén áll, Javaban a mővelet neve elé kerül): public ListaElem getKovetkezo(){ A programozó ezt lecseréli a szükséges kódra. return null; } public void setKovetkezo(ListaElem e ){ aaaaaaaaaaaa A programozó itt pótolja a hiányzó kódot. }

Mivel a getKovetkezo() mőveletnek egy ListaElem típusú értéket mindenképpen vissza kell adnia, ezért a CASE eszköz a mővelet megvalósításába belegenerált egy null értéket visszaadó utasítást (return null), amelyet persze a programozónak le kell cserélni a getKovetkezo() mővelet rendeltetésének megfelelı utasításra. A setKovetkezo() mővelet megvalósítását a kódgenerátor üresen hagyta, a hiányzó kódot is a programozónak kell pótolnia. A csere és a pótlás utáni programkód az alább látható:

234

INFORMATIKUS SZAKMAI ISMERETEK public ListaElem getKovetkezo(){ return kovetkezo; // Visszaadja a kovetkezo attribútum értékét. } public void setKovetkezo(ListaElem e ){ kovetkezo=e; // Az e mutatója lesz a kovetkezı attribútum // értéke. }

Mivel az elemSzam() mőveletnek egy int (egész szám) típusú értéket, a listabanVan() mőveletnek pedig egy boolean (logikai) típusú értéket mindenképpen vissza kell adnia, ezért a CASE eszköz e mőveletek megvalósításába belegenerált egy return 0, illetve egy return false utasítást, amelyeket a programozónak le kell cserélni az említett mőveletek rendeltetésének megfelelı utasítássorokra. public int elemSzam(){ A programozó ezt lecseréli a szükséges kódra. return 0; } public boolean listabanVan(ListaElem e){ return false; A programozó ezt lecseréli a szükséges kódra. }

A programozó munkája utáni eredmény alább látható: public int elemSzam(){ int sz=1; ListaElem aktElem = this; // this: a megszólított objektum while (aktElem.getKovetkezo() != null) { sz=sz+1; aktElem = aktElem.getKovetkezo(); } return sz; } public boolean listabanVan(ListaElem e){ ListaElem aktElem = this; // this: a megszólított objektum while ((aktElem != e) && (aktElem.getKovetkezo() != null)) { aktElem = aktElem.getKovetkezo(); } if (aktElem == e) return true; aktElem = e; while ((aktElem != this) && (aktElem.getKovetkezo()!= null)) { aktElem = aktElem.getKovetkezo(); } return (aktElem == this); }

Egy mővelet kódjában this a mővelettel megszólított objektum. Tehát az x.elemSzam() megszólítás esetén a this az x-szel azonos. A fenti kód a 4.25., illetve a 4.26. ábrákon látható szekvenciadiagramokon mutatott logika szerint készül. Megjegyezzük, hogy a kódban a listaelem kovetkezo attribútuma értékének elérésére a getKovetkezo() mőveletet itt csak azért használtuk, hogy a hasonlóság még szembetőnıbb legyen az említett szekvenciadiagramokkal. Ugyanakkor mivel a kovetkezo attribútum értékét nem idegen objektumok, hanem magának a ListaElem osztálynak a példányosításával elıálló listaelemek hivatkozzák, a getKovetkezo() mővelet helyett elegendı lett volna a kovetkezo attribútum közvetlen megszólítása is. (Például az aktElem.getKovetkezo() mővelethasználat helyett elegendı az aktElem.kovetkezo attribútumhivatkozás.) A fenti kódnak alább


235

egy ilyen értelmő módosítása következik, amelyben az említetteken felül még az sz=sz+1 utasítást is lecseréltük a vele egyenértékő, de a Javaban hatékonyabb ++sz utasításra. public int elemSzam(){ int sz=1; ListaElem aktElem = this; // this: a megszólított objektum while (aktElem.kovetkezo!=null) { ++sz; aktElem = aktElem.kovetkezo; } return sz; } public boolean listabanVan(ListaElem e){ ListaElem aktElem = this; // this: a megszólított objektum while (aktElem != e && aktElem.kovetkezo!=null) { aktElem = aktElem.kovetkezo; } if (aktElem == e) return true; aktElem = e; while (aktElem != this && aktElem.kovetkezo!=null) { aktElem = aktElem.kovetkezo; } return (aktElem == this); }

Mivel e tankönyv nem programozók részére készült a fenti kódhoz további magyarázatokat már nem főzünk. – Ha az olvasó mélyebben meg akarja ismerni a Java nyelvet, ajánljuk a következı könyvet: Nyékiné Gaizler J. (szerkesztı és társai): JAVA 2 – Útikalauz programozóknak: 1.3, ELTE TTK Hallgatói Alapítvány, Budapest, 2001. Egységtesztek A programok verifikációja az egységtesztek elvégzésével, azaz az olyan elemi programegységek megfelelıségének ellenırzésével kezdıdik, amelyek fejlesztése és tesztelése elkülönülten is hatékonyan megoldható. Funkcióorientált megközelítés esetén, amelyet a programok szigorúan hierarchikus tagolása jellemez, ezek a programegységek triviálisan azonosíthatók. Az objektumorientált (OO) megközelítés esetén azonban a helyzet bonyolultabb. Egy rendszer > alrendszer > magasabb szintő modul kategóriákban az OO megközelítés esetén is adódik egy hierarchia, de az OO technológia számára alapvetı absztrakciós egységet jelentı objektumosztályok a kompozíció-komponens viszony tekintetében nem alkotnak hierarchiát. Az objektumosztályok nagyon különbözı összetettségőek lehetnek, azaz nem mondható, hogy minden osztály az egységteszt tárgyát képezı programegységek közé számít: • Lehet olyan osztály, amely a komplexitása miatt nem sorolható az elemi alkotórészek közé. Egy ilyen osztály példányai többféle más osztály példányaiból összetevıdı bonyolult kompozíciók, azaz maguk is több olyan objektum „összeszerelésével” állnak elı, amelyek külön-külön is többféle követelmény teljesítéséért felelısek, és a különbözı komponensek felelısségi körébe tartozó követelményhalmazok egymáshoz képest több eltérést, mint átfedést mutatnak. Egy ilyen osztály tesztelése már inkább az integrációs tesztek közé számít. • Lehet olyan osztály, amely az egyszerőségénél fogva csak más osztályokkal együtt képezi elkülönült fejlesztés és tesztelés tárgyát. Sıt, ez még olyan osztály esetén is igaz lehet, amelyek példányai ugyan kompozíciók, de még mindig csak egy viszonylag egyszerő üzleti/szakterületi követelmény teljesítéséért felelısek. Ugyanis éppen a rengeteg „gyárilag” készen adott osztály újrafelhasználása miatt ma már egy viszony-

236

INFORMATIKUS SZAKMAI ISMERETEK lag egyszerő üzleti/szakterületi objektum felépítéséhez is a gyakorlatban több – a programozói környezetben készen adott – osztály példányát használják fel komponensként. (Figyelembe kell venni, hogy a program tesztelése csak alkalmas mőködési környezetben hajtható végre. Ennek a környezetnek a kiépítése maga is ráfordítással jár. Így több olyan egyszerőbb osztályt, amelyek tesztelése azonos vagy hasonló mőködési környezetet kíván, azért is célszerő nem egyenként, hanem „összecsomagolva” egy tesztelési egységnek tekinteni, mert ellenkezıleg különbözı fejlesztıknek osztják ki ıket, akik egymásról nem tudva többszörösen építik ki a teszteléshez szükséges mőködési környezetet.)

Általában elmondható, hogy ha az egységteszt tárgya osztályok egy csoportja (csomagja), akkor annak olyan okai lehetnek, hogy • ezek az osztályok egymással szorosan összefüggı követelmények teljesítéséért felelnek; • a csoport tagjai azonos mőködési környezetben tesztelhetık; továbbá olyan következményei lehetnek, hogy • az egységteszt alatt is alkalmazni kell olyan módszereket, amelyek egyébként csak az integrációs tesztekre jellemzık. Ilyenek az inkrementális tesztelés vagy az interfésztesztelés (lásd a 4.6.3. szakaszban). Az egységteszteket maguk a fejlesztık végzik, ezért gyakori megoldás, hogy nem készül az egységteszt feladatát részletezı tesztspecifikáció; a programozó közvetlenül a részletes szoftverterv alapján találja ki, hogy milyen teszteseteket milyen bemeneti adatokkal kell kipróbálnia, és milyen kimenetel számít helyesnek vagy hibásnak. – Azonban olyan szoftver esetében, amelynél komoly biztonsági kockázatot képez a megbízhatatlanság akár kisebb mértéke is, az egységteszteket független tesztelıkkel is megismételtetik. Ebben az esetben viszont elengedhetetlen, hogy olyan tesztspecifikációk készüljenek, amelyek alapján a független tesztelık is képesek hatékonyan elvégezni a szükséges ellenırzéseket. (A tesztspecifikációk tartalmáról a 4.6.3. szakaszban lesz bıvebben szó.) A tesztelés csak a hibák, hiányosságok tényét állapítja meg, a tapasztalt hibák okának azonosítása, és a program javítása a belövés tevékenység feladata. Ha a programegységek tesztelését annak programozója végzi, a tesztelés és a belövés szoros kapcsolatban mőködik. Független tesztelı bevonása esetén a belövés fontos bemeneti dokumentuma a tesztnapló (lásd a 4.6.3. szakaszban). A programbelövésrıl a 4.6.3. szakaszban, a tesztelés és a belövés eszközeirıl a 4.6.4. szakaszban lesz bıvebben szó. 4.6.3 Szoftver- és rendszerintegráció, a szoftver és a rendszer validációja

Integráció és integrációs teszt Az integráció mint fejlesztési lépés az a mővelet, amelynek során a különbözı fejlesztık vagy fejlesztı teamek által létrehozott egységekbıl, alacsonyabb szintő komponensekbıl, inkrementumokból összeállítják a különbözı szintő kompozíciókat: a magasabb szintő modulokat, a szoftvert, a rendszert. (A szoftver ebben a szakaszban éppen úgy, mint a 4.2.1. szakaszban – összetartozó szolgáltatások sokaságát nyújtó – komplett alkalmazást jelent.) Szoftverintegráción a szoftver (az alkalmazás) moduljaiból való összeszerelését, a rendszerintegráción pedig a rendszer alrendszerekbıl (együttmőködı szoftverekbıl) való felépítését értjük.


237

Az integrációs teszt célja meggyızıdni az integráció összetevıinek elvárt együttmőködésérıl. Ebben a lépésben feltételezhetı, hogy az egyes komponensek külön-külön az elvárt mőködést nyújtják, hiszen azt már bizonyította az egységteszt vagy az alacsonyabb szintő integrációs teszt, tehát az adott integrációs tesztnek elegendı az adott kompozíció közvetlen komponensei együttmőködésének helyességére koncentrálni. Tesztterv, tesztpecifikáció és tesztnapló Az integrációs teszt általában összetett tevékenység, amelybe beletartozik a tesztelés tárgyi feltételeinek elıállítása, a mőködési környezet kialakítása is. A teszteléshez szükséges erıforrások és munkaerı megfelelı kombinációban és ütemezésben való rendelkezésre állása, a tevékenységek megfelelı rendben való végrehajtása alapos teszttervet feltételez. A tesztterv egyfajta projektterv, azaz meghatározza a tesztelési feladatokat, azok végrehajtóit és ütemezését, de nem szól – az egyes feladatok teljesítése keretében – a tesztelık által végrehajtandó mőveletekrıl. Az már a tesztspecifikációk tárgya. Mivel az integrációs tesztet normálisan független tesztelık végzik, ezért annak végrehajtása jellemzıen tesztspecifikációk alapján történik. A tesztspecifikáció forrását az integrációs teszt esetében a nagyvonalú tervek (interfésztervek) képezik, de specifikációk az egységtesztek (4.6.2. szakasz) számára is készülhetnek, azok inputja a részletes rendszerterv. A tesztspecifikáció meghatározza • a vizsgálandó teszteseteket, tesztesetenként pedig • a végrehajtás elıfeltételeit (pl. mely másik teszteset végrehajtásának kell megelızni az adott tesztesetet), • az alkalmazandó adatbemeneteket, • a tesztelı által végrehajtandó mőveleti lépéseket és • az elvárt kimenetet. A listabanVan() mővelet tesztesetei: A korábban definiált ListaElem osztály tesztelése magába foglalja az osztály listabanVan() példánymőveletének tesztelését is. Itt az osztály összes tesztesete helyett csak az említett mővelet teszteseteire szorítkozunk, azaz olyan esetekre, amikor a környezet egy x.listábanVan(y) mővelettel felszólítja az x listaelemet annak a kérdésnek a megválaszolására, hogy az y listaelem eleme-e annak a listának, amely az x elemet tartalmazza. Az alábbi tesztesetek mindegyikének mőködési feltételeként elıírjuk egy olyan lista létezését, amelynek elemei e1, e2, e3, e4, e5, e6, e7. Maguk a tesztesetek a következık: 1. Bemenet: x=e5; y=e5. Elvárt kimenet: true. 2. Bemenet: x=e5; y=e7. Elvárt kimenet: true. 3. Bemenet: x=e5; y=e3. Elvárt kimenet: true. 4. Bemenet: x=e5; y=e8 (e8 nincs a listában). Elvárt kimenet: false. 5. Bemenet: x=e5; y=null, azaz az y nem mutat egyik listaelemre sem. Elvárt kimenet: leállás „A paraméter csak létezı listaelem lehet.” hibaüzenettel. A felsorolt tesztesetek, csak a bemenetet és az elvárt kimenetet írják le, mőveleti lépéseket nem tartalmaznak. Ennek az az oka, hogy itt egyszerő (egylépéses) tesztesetekkel állunk szemben.

Megjegyzés: A 4.6.1. szakaszban megkülönböztetett hiányosságtesztelés és statisztikai tesztelés közül itt elsıdlegesen a hiányosságtesztelésre koncentrálunk. A független tesztelı a teszt eredményérıl naplót készít. A tesztspecifikáció és a tesztnapló általában azonos dokumentumok; pontosabban a tesztspecifikáció úgy készül, hogy a naplóbejegyzések számára is tartalmaz üres rovatokat. A naplóbejegyzések típusai: • optimális esetben a tesztelı kipipálással nyugtázza a teszteset végrehajtását és az elvárt kimenet teljesülését;

238

INFORMATIKUS SZAKMAI ISMERETEK • •

végrehajthatatlan lépéssorozat esetén fel kell jegyezni, hogy a végrehajtás melyik lépésben milyen kísérı jelenségekkel szakadt meg; bejárható lépéssorozat, de hibás kimenetel esetén le kell írni az elvárttól különbözı kimenetet.

A program belövése A tesztelés csak a hibák, hiányosságok tényét állapítja meg, a tapasztalt hibák okának azonosítása és a program javítása a belövés tevékenység feladata. Az integráció során az összetett kompozíciók belövésének fontos bemeneti dokumentuma a tesztnapló. (Alacsonyabb szinten, a programegységek belövésénél némileg más a helyzet, mivel a programegység tesztelését gyakran csak annak programozója végzi, vagyis ugyanaz a személy, akinek a belövés is feladata. Ilyenkor sem tesztspecifikáció, sem tesztnapló nem készül.) A programhibák okának azonosítása és a javítás nem egyszerő feladatok: Különösen az összetett kompozíciókban a hibajelenséget produkáló programrész nem feltétlenül azonos a hibáért felelıs programrésszel, az utóbbi keresése komoly ráfordítással jár még akkor is, ha a hibát valószínősíthetıen okozó programhelyek behatárolása bizonyos mértékig automatizálható, illetve a hibaforrás programozó általi keresésének hatékonyságát a programozói környezet nyomkövetı szolgáltatással is javítja. – A belövési ráfordításoknak ez a része a szoftver elemezhetıség minıségével van összefüggésben (lásd a 4.3.2. szakaszban). A listabanVan() mővelet javítása: A megelızı keretes példában felsorolt teszteseteket lefuttatva, a tesztelı az elsı négy esetben az elvárt kimenet tejesülését nyugtázta; az 5. esetben viszont lejegyezte, hogy a várt hibaüzenet nem jelentkezik. A programozó a tesztnapló alapján a listabanVan(ListaElem e) mővelet kódjába javítás céljából az alább vastagon szedett részt szúrta be: public boolean listabanVan(ListaElem e){ if (e==null) { System.out.println( "A paraméter csak létezı listaelem lehet."); return false; } ListaElem aktElem = this; // this: a megszólított objektum while (aktElem != e && aktElem.kovetkezo!=null) { aktElem = aktElem.kovetkezo; } if (aktElem == e) return true; aktElem = e; while (aktElem != this && aktElem.kovetkezo!=null) { aktElem = aktElem.kovetkezo; } return (aktElem == this); }

A kód javítása során két kritikus kérdés merül fel: • A javításnak a szoftver mekkora részére kell kiterjedni? (A válasz annál érdekesebb, lehet minél magasabb szintő integrációról van szó.) • Mi az esélye annak, hogy a javítás nem várt – újabb hibákat okozó – mellékhatásokkal fog járni? Az elsı probléma a szoftver változtathatóság minıségével, az utóbbi pedig az elemezhetıség és a stabilitás minıségével van összefüggésben (lásd a 4.3.2. szakaszban). A hiba lokalizálásában, illetve a program azon részének meghatározásában, amelynek mőködésére a javítás következményekkel járhat, nagy segítséget nyújthatnak az osztálydiag-


239

ramok, ha azokon a tervezık gondosan feltüntettek minden függıséget. Ugyanis egy adott osztályon belüli változtatás hatása a függıségek mentén a függı osztályok felé terjedhet tovább. Emlékeztetünk rá, hogy a függıség szimbólummal jelölt viszonyokon felül a specializáció és az asszociáció is olyan függıséget képez, amely mentén a változtatások hatása tovaterjedhet. Így a speciális alosztály függıségben áll az ısosztályával, azaz az ısosztályban végzett változtatás következményekkel járhat a leszármazott osztályokban; egy kompozíció függıségben áll a komponenseivel, mert a komponens módosítása következményekkel járhat a kompozíció mőködésében. A tesztelés és a belövés eszközeirıl a 4.6.4. szakaszban lesz bıvebben szó. A következıkben a tesztelés és a belövés olyan módszereit vesszük sorra, amelyek tipikusan az integrációk tesztelésére és belövésére jellemzıek, ezek az interfésztesztelés, az inkrementális tesztelés és a stresszteszt. Azon felül külön kitérünk az objektumok intrágrációjára is. Interfésztesztelés Az integrációs tesztnek az adott kompozíció komponensei közötti együttmőködés helyességére kell koncentrálni. Ez az együttmőködés a komponensek közötti kommunikációs felületek, az interfészek közvetítésével bonyolódik, következésképpen az együttmőködés hibái érdemi részben vagy az interfészek hibájából adódnak vagy abból, hogy valamely komponens hibásan használja az interfészt (félreéltelmezi annak specifikációját). Éppen az ilyen anomáliák kiküszöbölésére szolgál az interfésztesztelés. A programkomponensek közötti interfészeknek a tesztelésük módját is befolyásoló típusai a következık [Sommerville-2002]: • Paraméterek: A komponensek eljáráshívás vagy függvényhívás útján kommunikálnak egymással, és az interfészt az eljárás (függvény) paraméterei, illetve a függvény visszaadott értéke alkotják. A paraméterek (vagy visszaadott érték) útján a komponensek egyszerő adatokat, adathivatkozásokat, objektumokat, objektumhivatkozásokat vagy függvényhivatkozásokat adhatnak át egymásnak. • Közös memória: A komponensek a memória egy területét közösen használják, az egyik komponens által oda letett tartalmat a másik is eléri. Olyan alkalmazások esetén, amelyeknél egymással szinkronban mőködő objektumokkal minden feldolgozási probléma megoldható, ez a megoldás kerülendı. Azonban a valós idejő mőszaki alkalmazások többnyire nem ilyenek, az azokat jellemzı aszinkron kommunikáció realizálására ez az egyik alkalmas megoldás. (Aszinkron kommunikáció: Amikor az adó adatokat tesz a csatornába, nem biztos, hogy a vevı is kész azok fogadására. Az adó nem is számít erre, ezért a mőködését a válaszra várakozás nélkül tovább folytatja mindaddig, amíg a folytatás a választ nélkülözni tudja. A vevı, amikor ismét fogadókész, akkor olvassa a neki címzett és a csatornában sorbanálló adatok közül az elsıt.) – A közös memóriával megvalósított interfész speciális esete, amikor alkalmazások az adatbázisban közösen használt táblák útján kommunikálnak egymással. Azonban ezzel külön nem foglalkozunk. • Eljárásinterfész: Az egyik komponens más komponensek által hívható eljárásokat tartalmaz. Tipikusan ilyenek az objektumosztályok publikus mőveletei. A teljesen absztrakt interfész osztályok absztrakt mőveletei pedig mind olyan – idegen objektumok által elérhetı – eljárások, amelyeknek az interfész mögé rejtett megvalósítása igény szerint dinamikusan (azaz futási idıben) megváltoztatható. • Üzenetek: Az egyik komponens egy üzenet(objektum) elküldésével (pl. http üzenet elküldésével) kér valamilyen szolgáltatást egy másik komponenstıl. A szolgáltatás

240

INFORMATIKUS SZAKMAI ISMERETEK végrehajtásának eredményét a megszólított komponens egy válaszüzenetben (pl. html lap) adja vissza. Ez a megoldás eredetileg a valós idejő mőszaki alkalmazások aszinkron módú kommunikációjának egyik eszköze volt. Ma már az OO technológiával fejlesztett üzleti alkalmazásokban is gyakran találkozunk vele. Azokban olyan komponensek között alkalmazzák, amelyek különbözı gépeken (például a kliens-szerver architektúra vagy a háromrétegő architektúra különbözı rétegeiben) fut(hat)nak.

Az interfészhibák a következı három osztályba sorolhatók [Sommerville-2002] [Lutz1993]: • Interfész téves alkalmazása: A használt komponens rendelkezik az ıt használó komponens számára szükséges interfésszel, de azt az utóbbi formailag hibásan használja. Például eltéveszti a paraméterek típusát, sorrendjét, darabszámát. • Interfész félreértelmezése: A használt komponens valamely interfészének nem az az értelmezése, mint amit az ıt használó komponens felıl tulajdonítanak neki, vagy a használó komponens felıl nem teljesen ismertek az interfész tartalmára vonatkozó azon feltételek, amelyek teljesülése nélkül a használt komponens hibás kimenetet állít elı. • Idızítési hibák: Ez a hiba közös memória vagy üzenetinterfész alkalmazása esetén fordul elı, tehát valós idejő mőszaki alkalmazásokra vagy üzenetinterfészt használó többrétegő üzleti alkalmazásokra jellemzı. Például egy szabályzóberendezés a finomabb szabályozás érdekében hiába akar gyakrabban (pl. 2 millisecundumonként) beavatkozni a folyamatba, ha az mérımőszer csak kisebb gyakorisággal (pl. 10 millisecundumonként) képes produkálni új mérési eredményt. Annak ellenére, hogy itt interfésztesztelésrıl beszélünk, meg kell említeni, hogy az interfészhibák felderítésére a statikus elemzés gyakran hatékonyabb a tesztelésnél, illetve az a tesztelés esetén sem takarítható meg, mert a teszteléssel produkált hibajelenség okának azonosítására a sztatikus elemzést mégiscsak be kell vetni. Ez különösen igaz a paraméterinterfészek téves alkalmazásainak felderítésére, de jelentıs mértékben igaz az interfész félreértelmezésének felderítésére is. Viszont az utóbbi hibatípus esetében kevés a statikus elemzés, ha az eljárásinterfész mögött futási idıben cserélıdhet annak megvalósítása. Az interfésztesztelésre vonatkozó megfontolások [Sommerville-2002]: • A paraméterinterfészeket mindig tesztelni kell az értékkészletük szélsıséges vagy a gyakorlatban szokatlan értékeivel is. • Az objektumhivatkozást váró paramétert null (üres) értékkel is tesztelni kell. (Ez tulajdon-képpen az elıbbi elv speciális esete.) • Ha egy komponens eljárásinterfészen keresztül hívódik meg, a tesztelés céljából a lehetı legszokatlanabb eljáráshívásokat is ki kell próbálni (vagyis az olyan hívásokat, amelyek lehetısége nagyobb valószínőséggel kerüli el a programozók figyelmét). • Üzenetinterfészek esetén elıforduló idızítési hibák kiszőrésére jól alkalmazható a stressztesztelés. • A közösen használt memórián alapuló együttmőködést a komponensek összes megengedett sorrendben való aktiválása mellett tesztelni kell. (Ez a megoldás az abból eredı hibák felfedezését szolgálja, hogy a programozó indokolatlanul feltételez valamilyen kitüntetett sorrendet.) Az integráció belövése során az interfészhibák javításának módjában is különbség mutatkozik az interfész téves alkalmazása és az interfész félreértelmezése között. Az elıbbi felismerésére és visszautasítására a hívott komponenst nagy mértékben fel lehet készíteni, tehát amennyiben a hibák ennek a felkészítésnek az elmulasztásából adódtak, akkor a javításnak an-


241

nak pótlására (is) kell kiterjedni. Az interfész félreértelmezésének felismerésére a hívott komponens kevésbé alkalmas (még a félreértelmezés egy-egy speciális esetének felismerése is indokolatlanul nagy ráfordítással járna), ezért a hibajavítás célja csak a félreértés megszüntetése lehet a hívó komponensnél. Inkrementális tesztelés és belövés Az inkrementális tesztelés elınyös sajátossága, hogy nem csak a hiba felderítését, hanem a belövés részeként a hiba okának lokalizálását is szolgálja. – Már az egységtesztnél is említettük, de összetett kompozíciók esetén még sokkal erısebben jellemzı, hogy a hibajelenséget produkáló programrész különbözhet a hibáért felelıs programrésztıl. Az inkrementális tesztelés éppen ezen problémán próbál úrrá lenni. A megoldás lényege, hogy egy komplexebb kompozíció esetén a tesztelést a kompozíció egy minimális részén kezdik, majd fokozatosan a kompozíció egyre bıvebb részére terjesztik ki, közben a következı szisztémát követik.: • Az elıször tesztelés alá vont minimális R1 részen végrehajtják a T1 tesztsorozatokat és az így feltárt hibákat mind kijavítják. • Az R1+R2 bıvített részen ismét végrehajtják a T1 tesztsorozatokat. (R2 a rendszer azon része, amellyel a második körben bıvül a tesztelés alá vont terület) Ha e teszt során újabb hibák mutatkoznak, azok oka nagy valószínőséggel az R2-ben lehet. • Az R1+R2 részen végrehajtják az R1+R2 részre specifikus T2 tesztsorozatokat is, és a T1+T2 teszttel feltárt hibákat mind kijavítják. • A következı (R3) bıvítéssel kapott R1+R2+R3 részen ismét végrehajtják a T1+T2 tesztsorozatokat. Ha e tesztelés során újabb hibák mutatkoznak, azok oka nagy valószínőséggel az R3-ban lehet. • … Stresszteszt A stressztesztet általában a kész rendszer teljesítményének és megbízhatóságának ellenırzésére használják, mivel a megrendelıt is általában az érdekli, hogy a rendszer egészben képes-e produkálni az említett jellemzık elvárt szintjét. (Ez a tény azonban nem zárja ki, hogy a fejlesztık már korábban a rendszer valamely – az említett jellemzık iránt kritikus – részére szorítkozva is alkalmazzák.) A tesztelés ezen típusának két funkciója van [Sommerville-2002]: 1. Arra keresi a választ, hogy ha a rendszert szélsıséges körülményeknek (az események nem várt kombinációjának, a feltételezett maximális terhelést meghaladó terhelésnek) teszik ki, az okoz-e adatvesztést vagy szolgáltatás-összeomlást. 2. A rendszer olyan hiányosságainak kiderítését célozza, amelyek egyszerő teszttel nem mutathatók ki, mert a hibajelenség csak olyan körülmények között tapasztalható, amelyeket csak egy bizonyos szint feletti terhelés képes elıidézni. Objektumosztály tesztelése – Objektumok integrációja Már a 4.6.2. szakaszban volt arról szó, hogy a OO technológiában nincs éles határ az egységteszt és az integrációs teszt között. Ezért bizonyos mértékig önkényes döntés eredménye, hogy az objektumosztályok tesztelését az integrációról szóló szakaszban tárgyaljuk. Az objektumokhoz, illetve azok osztályához kapcsolódó statikus elemzési és tesztelési feladatok elvben az alábbi szintekbe sorolhatók: • egy osztály összes mőveletének különálló tesztelése,

242

INFORMATIKUS SZAKMAI ISMERETEK • • •

az osztály egy példánya attribútumainak beállítása és vizsgálata, adott osztályba tartozó objektum lehetséges állapotváltozásainak vizsgálata, objektumok együttmőködı csoportjának tesztelése – objektumintegráció.

Fentebb azért beszéltünk elvileg lehetséges szintekrıl, mert amint azt a ListaElem osztály egyetlen mőveletének, a listabanVan() mőveletnek a tesztelése példázza, az egy szerre egy mővelet különálló tesztelése és objektumok együttmőködı csoportjának tesztelése is. Az objektumok verifikációjában akár a tesztelést megelızıen, akár a tesztelés mellett jelentıs szerep jut a statikus elemzésnek. Ennek tárgyát a forráskód mellett a specifikáció részeként elıálló diagramok (használati eset diagramok, osztálydiagramok, szekvenciadiagramok, állapotdiagramok) képezhetik (lásd a 4.3.3. szakaszban és a 4.5. alfejezetben). Már csak azért sem úszható meg a statikus elemzés, mert a specifikálandó tesztesetek azonosítása céljából is szükség van rá. A OO technológia öröklıdési mechanizmusa (lásd a 4.4.2. szakaszban) elvben munkamegtakarítással jár. Egy korábban sokszorosan kipróbált ısosztályból leszármaztatott alosztály tesztelése és belövése várhatólag kevesebb ráfordítással megoldható. Azonban az örökölt mőveleteket is tesztelni kell. Ennek legalább két oka van: • Egyes örökölt mőveletek megvalósítását az alosztály módosítja (lásd a polimorfizmust a 4.4.2. szakaszban). Ez a körülmény a változatlanul megörökölt mőveletek mőködését is befolyásolhatja, ha azok valamilyem függésben állnak a módosított mővelettel. • Egy – plusz attribútumokkal bıvült – alosztály esetében az elsı közelítésben változatlanul megörökölhetınek gondolt mőveletekrıl a teszt derítheti ki, hogy azokat mégis módosítani kell, mert különben nem veszik figyelembe azokat az újabb attribútumokat, amelyek éppen a szóban forgó mővelet finomabb vezérlése céljából adódtak hozzá a leszármazott osztály definíciójához. Az adott osztályba tartozó objektum lehetséges állapotváltozásainak vizsgálatában (történjen az akár statikus elemzéssel, akár teszteléssel) jó szolgálatot tesz az osztály objektumainak állapotdiagramja. Mivel az állapotváltozásokat vizsgáló adott teszteset éppen arról szól, hogy az objektumnak egy adott állapotban milyen eseményekre és hogyan kell reagálni (az eseménynek milyen állapotváltozást kell elıidézni), az ilyen tesztesetek azonosításának kézenfekvı eszköze az állapotdiagram. Objektumok együttmőködı csoportjának, azaz az objektumintegrációnak a tesztelési módszerei közül itt csak a használati eset alapú (más szóval: forgatókönyv alapú) tesztelést érintjük. A funkcionális követelményeknek megfelelés igazolása kézenfekvıen az ilyen követelményeket specifikáló használati esetek alapján történhet. Azonban a felhasználó és a fejlesztı együttmőködésében készülı használati esetek általában nem tartalmaznak elegendı információt a használati esettel reprezentált szolgáltatást produkáló objektumok együttmőködésének teszteléséhez, ezért a használati eseten belüli történésekrıl szekvenciadiagramok formájában forgatókönyvek is készülnek. A tesztesetek specifikációjának inputját ezek (az objektumok közötti interakciók részletesebb leírására alkalmasabb) szekvenciadiagramok képezik. Minıségi teszt – a rendszer validációja Az elıbbiekben említett tesztek célja a verifikáció, de azon felül általában szükség van validáció célú tesztelésre is, amely a szoftverterméknek a szerzıdésben vagy közvetlenül a megrendelıtıl (felhasználótól) származó követelményekben elıírt minıségi jellemzıit igazol-


243

ja. Ezt nevezik a rendszer vagy egy szoftver minıségi tesztjének, amely a rendszer vagy egy alkalmazás egészére vonatkozó integrációs tesztek egy speciális változata. A minıségi teszt specifikációjának forrásai: • A teljesítményszintre, a megbízhatósági szintre és a biztonságosságra vonatkozó követelmények • A funkcionalitásra vonatkozóan a szerzıdésben foglalt követelmények, valamint közvetlenül a megrendelıtıl (felhasználótól) származó követelmények, illetve az elıbbieket specifikáló használati esetek. • A minıségi tesztet megelızı integrációs tesztek specifikációi. A legutóbbira azért van szükség, mert a szoftver funkcionalitás szerinti minıségét bizonyító tesztesetek nagyrészt (vagy teljes egészében) a verifikációs célú integrációs tesztek tesztesetei közül válogathatók. Itt feltételezzük, hogy a verifikáció által igazolt követelmények részhalmazként tartalmazzák azon követelményeket is, amelyeket a validációnak is figyelembe kell venni. Tehát a minıségi tesztbe azokat a teszteseteket kell kiválogatni, amelyek az említett részhalmazba esı követelmények teljesítését bizonyítják. Ha a verifikációra vonatkozó feltételezésünk teljesül, akkor az elıbbi bekezdés szerint válogatott teszteseteken felüli új tesztesekre általában csak: • a rendszer teljesítmény- és megbízhatósági jellemzıinek, valamint • biztonságosságának validálása céljából lehet szükség. A rendszer teljesítményszintje és megbízhatósági szintje tipikusan mérhetı jellemzık, amelyek validálása statisztikai tesztelés útján, azon belül stressztesztelés útján lehetséges, illetve a megbízhatósági minıség elırejelzésében a statikus elemzés is alkalmazható. A rendszer biztonságosságának validálása egyebek mellett azért is külön tárgyalandó, mert a biztonságosság nem számszerően mérhetı jellemzı (nem statisztikailag jellemezhetı minıség), és így a validálás is más módszereket kíván, mint a teljesítmény és megbízhatóság minıségek esetében. Igazából a biztonsági követelmények is funkcionális követelmények, és nem csak azért, mert az ISO 9126 minıségi szabvány szerint a biztonságosság minıség a funkcionalitás minıség komponense, hanem azért is, mert a biztonság feltétele a vészhelyzetek kezelésére szolgáló funkciók jelenléte a rendszerben. – Ha így van, akkor a biztonságosság validálása miért nem végezhetı el más funkcionális követelmények validálásának mintájára? – A probléma az, hogy a vészhelyzetek csak úgy – tesztelés céljából – általában nem idézhetık elı, a vészhelyzet szimulálása melletti tesztelés pedig nem igazán meggyızı. Következésképen a rendszerek biztonságossága a tesztelésnél komplexebb és folyamatosan alkalmazott megoldást kíván olyan összetevıkkel, mint: • formális (matematikai) elemzéssel történı validálás, • vészhelyzet-naplózó és monitorozó rendszer, • rendszeres és módszeres biztonsági felülvizsgálatok, • biztonsági minısítési rendszer létrehozása és mőködtetése, • a programverziók és azok komponenseinek azonosításáért és nyilvántartásáért felelıs konfigurációkezelési rendszerben a korábbi vészhelyzetek tapasztalatainak, dokumentumainak nyilvántartása, nyomon követése, • futási (üzemeltetési) idejő biztonságossági ellenırzés.

244


4.6.4 Programozási környezetek

Programozási környezeten a • programkódolást, • tesztelést és • belövést együttesen támogató rendszert értünk, amely a 4.2.4. szakaszban bevezetett CASE eszköz fogalmon belül a lower CASE eszköz kategóriával azonosítható. A programozási környezet funkciói: • a programkód generálása, • a programkód egy adott forrásnyelven (vagy alternatívan többféle nyelven) való szerkesztése; • a programkód verzióinak nyilvántartása, kezelése; • a forráskód formai (szintaktikai) ellenırzése; • a program statikus elemzésének automatizálása; • a forráskód fordítása futtatható tárgykódra vagy futtatás közbeni értelmezése; • a programegységek mőködés közbeni kipróbálása; • programegységekbıl összetett szoftver összeállítása és kipróbálása; • hibás mőködés okának diagnosztizálása és javítása (a program belövése). Meg kell jegyezni, hogy az itt tárgyalt lower CASE eszközök mellett a hibák lokalizálásában, illetve az egyes javítások hatásai várható kiterjedésének behatárolásában komoly segítséget nyújthatnak az upper CASE eszközökkel készült tervezési modellek is. – A 4.6.3. szakaszban már utaltunk rá, hogy az ilyen irányú vizsgálatokban még az osztálydiagramok is komoly segítséget nyújthatnak azzal, hogy mutatják az osztályok közötti függıségeket. Egy osztály tesztelése során felfedezett hibák diagnosztizálásában szerepet kaphatnak az állapotdiagramok, az objektumintegráció hibáinak diagnosztizálásában pedig a szekvenciadiagramok. Programkód generálása A programkód generálásának gyakoribb változatai a következık: • Kódgenerálás az elemzést és a tervezést támogató upper CASE eszközökben készült modellek alapján: Erre példa a 4.6.2. szakasz mutatott eset, amikor is az osztálydiagram alapján maga az upper CASE eszköz legenerálta a ListaElem osztály Java nyelvő vázát. – A programkód többi részének megírása viszonyt szokásos szerkesztıprogramokkal történik • A speciális programozási környezetek a nagyon gyakori feladatokra (mint a felhasználói felületek; adataktualizálási, adatkeresési mőveletek, választéklisták kezelése, …) kifinomult kész komponenseket (osztályokat, csomagokat) kínálnak, továbbá egy olyan grafikus környezetet, amelyen a programozó a kész komponensek vizuálisan közzétett palettájából válogathat, és a probléma megoldásához szükséges komponenseket egérrel a grafikus szerkesztıfelületre húzva egy lego-építıhöz hasonlóan rakhatja össze a programot. Az egyes felhasznált komponensek mőködésével, illetve a komponensek közötti interakciókkal szembeni igényeit a programozó a komponensekhezhez, illetve a komponensek kapcsolataihoz tartozó őrlapokon közli. – Végül a grafikus konstrukció és ahhoz kapcsolódó őrlapokon adott információk alapján a programozási környezet legenerálja a végrehajtandó kódot.


245

Kódmigráció: A mai technológiákhoz nem illeszkedı, korszerő támogatással már nem rendelkezı programnyelven készült kód alapján egy napjainkban elterjedt nyelvő kód automatikus elıállítása. – E megoldás lehetıségei korlátozottak, hiszen a korábbi alkalmazásnak csak az elavult technológiához szorosan nem kötıdı részeit lehet és érdemes migrálni.

Programkód szerkesztése A kódszerkesztı környezettel szemben programnyelvtıl független elvárás, hogy támogassa a verziókezelést: a kódverziók nyilvántartását, azonosítását, összehasonlítását. Egy ok a sok közül, amely miatt nélkülözhetetlen a verziókezelés: Akármilyen részletes legyen is a specifikáció, a megoldás módjára vonatkozó számos döntés akkor is a programozóra marad. A programozó egy ideig halogathatja ezeket a döntéseket, addig megírja a kód egyértelmően meghatározottnak vélt részeit. Ám egy idı után a munka már csak úgy folytatható, hogy a programozónak választania kell valamilyem megoldási alternatívából. Akkor célszerő jeleznie, hogy ettıl kezdve egy új kódverziót szerkeszt. Az addig szerkesztett kód egyrészt elmentıdik (megırzıdik) egy v1 verzióként, másrészt létrejön belıle egy új v1.1 verzió. Minden további változtatás már csak a v1.1 verziót érinti. Ha utóbb a programozó döntése nem bizonyul sikeresnek, akkor visszatérhet a v1 verzióhoz, és abból létrehozhat egy olyan v1.2. verziót, amelyben egy másik alternatíva szerint folytatja a programozást. Lehet olyan eset is hogy a v1.1 irányba tett lépések ugyan sikertelenek voltak, de a munka egy része mégis hasznosítható az alternatív irányban is. Ilyenkor jól jönne, ha a programkódnak az a része, amely a v1 és a v1.1 verziók különbsége automatikusan megmutatná magát, hogy a programozó abból szemezgethesse össze az alternatív irány számára megırzendı részeket. Pontosan erre szolgál a verziókezelés állományösszehasonlító funkciója.

Programkódot egy buta szövegszerkesztıvel is össze lehet állítani, de a rendszer egészét vagy egy komplett alkalmazást nem érné meg ilyen módon kódolni, a munkaráfordítás iszonyú mértéke miatt. A programnyelv-specifikus szerkesztık a programozó által beírt szövegben felismerik az utasításokat és automatikus formázással gondoskodnak arról, hogy forráskód könnyen olvasható és áttekinthetı legyen. Például • eltérı betőtípussal, betőszínnel megkülönböztetik a nyelv kötött szavait a programozó által szabadon választott adatnevektıl, illetve a kötetlen megjegyzésektıl; vagy • automatikus sor eleji behúzással jelzik, hogy az adott utasítás egy korábban megkezdett összetett utasításba van beágyazva. A fejlettebb változatok aktívabb beavatkozásra is képesek: • A programozó által megkezdett utasítást felismerve, a szerkesztett kódszövegbe automatikusan beillesztik az utasítás kötelezıen alkalmazandó további szintaktikai egységeit (pontosabban az azokat jelzı kötött szavakat). • Szintaktikai ellenırzést, illetve a statikus elemzés automatizálását támogató szolgáltatásokat is tartalmaznak. Az OO nyelvek legfejlettebb programozási környezetei erısen támogatják a készen adott komponensek újrafelhasználását, és a kódszerkesztést általában kombinálják a kódgenerálásról szóló részben második helyen említett megoldással. A forráskód szintaktikai ellenırzése – Fordító, illetve értelmezı programok A programkód szintaktikai ellenırzése azt vizsgálja, hogy a kód formailag megfelel-e az adott programnyelv szabályainak. Például

246


az egyes utasítások (mőveletek) felépítése megfelel-e az adott típusú utasítás nyelvi sablonjának; • az utasításban (mőveletben) szereplı adat(hivatkozás) típusa megfelel-e az adott helyen elvárt adattípusnak. Tehát a szintaktikai elemzésnek nem tárgya a program funkcionális (mőködésbeli) helyessége. A fordítós nyelveknél (pl. a C nyelv) a programozó által megírt forráskódból fordítóprogram készít adott típusú gépen futtatható gépi kódot. A forráskód szintaktikai ellenırzése klasszikusan a fordítóprogram feladata, a fordítás során az összes formai hiba szükségképpen kiderül, hiszen a formailag hibás forráskód le sem fordítható. Az értelmezıs nyelveknél (mint pl. a Basic) nincsen fordítás, a forráskódot egy értelmezı program futtatja úgy, hogy a forrásnyelvi utasításokat egyenként értelmezi. Ebbıl adódik, hogy nincs a futtatást megelızı szintaktikai ellenırzés. Mind a formai, mind a tartalmi (szemantikai) hibák csak futtatás közben fedezhetık fel. Ha a program valamely ága a futtatás során nem kerül sorra, akkor az adott ágon létezı formai hibák sem derülnek ki. – E hiányosság enyhítésének egyik módja az adott nyelvre specializált kódszerkesztıbe illesztett formai ellenırzés. Azonban az ilyen ellenırzés hatóköre – az értelmezıs nyelvek itt nem említett egyéb sajátosságai miatt –korlátozottabb, mint a fordítóprogramoké. Megjegyzés: Az értelmezıs nyelvek nem csak a kód egészére kiterjedı szintaktikai ellenırzés hiánya miatt mutatkoznak hátrányosnak a fordítós nyelvekkel szemben. Az értelmezés a futási sebesség szempontjából nem igazán hatékony megoldás, mert a fordítással ellentétben az értelmezés a futási idı terhére történik, és ha egy utasítás ciklikusan pl. ezerszer hajtódik végre, akkor az értelmezése is ezerszer megismétlıdik. Azonban az értelmezıs nyelveknek van elınye is: a kód legkisebb változtatása is (szemantikailag) azonnal (fordítási menet nélkül) kipróbálható. Ez a tulajdonság két okból nagyon hasznos: (1) megkönnyíti a kezdı programozók és az alkalmilag programot írni kényszerülı profi felhasználók dolgát; (2) a fordítási menetek mellızése meggyorsítja a program belövését. – Az legelterjedtebb értelmezıs nyelvhez, a Basichez utóbb fordítók is készültek: az értelmezı módban belıtt kód utóbb le is fordítható. A napjainkban egyik legelterjedtebb OO nyelv, a Java különös hibrid. Értelmezı módban és lefordítva is használható, de a fordítása nem gépi kódra, hanem egy gépfüggetlen köztes kódra történik, amelyet a legkülönfélébb processzorokra kifejlesztett szoftver, a Java motor képes lefuttatni. A Java motor is egyfajta értelmezı szoftver, de a lefordított köztes kód futás közben lényegesen kevesebb ellenırzést és ellenırzési célú járulékos adminisztrációs mőveleteket igényel, mint az eredeti forráskód, ezért inkább absztrakt gépnek tekinthetı, és ezért jogos értelmezı program helyett futtató környezetnek nevezni.

A fordítóprogramok a fordításon felül a kód statikus elemzését szolgáló kimutatásokat is készítenek, lásd a következı cím alatt. A programok statikus elemzésének támogatása A statikus elemzés a forráskódon a szintaktikai ellenırzésen túlmutató olyan vizsgálatokat jelent, amelyek a program mőködésére vonatkozó következtetéseket képesek levonni. Ez a tevékenység általánosságban nem automatizálható, de a hibás mőködést valószínősítı kódrészek kiválogatása szoftverre bízható, a gyanút azután személyes szemrevételezés igazolhatja vagy vetheti el. A forráskód vizsgálatát segítı automatizmust nyújthatja egy arra specializált célszoftver, de beépülhet a nyelvspecifikus kódszerkesztıbe vagy fordítós nyelveknél a fordítóprogramba is.


247

A statikus elemzés szakaszai [Sommerville-2002] szerint a következık: • A vezérlés elemzése: A vezérlésátadó utasítások elágazások, feltétel nélküli ugró utasítások vizsgálatával ciklus belsejébe irányuló kritikus ugrások vagy olyan kódrészek felderítése, amelyek soha nem kaphatják meg a vezérlést. • Az adathasználat elemzése: A változók gyanús használatának vizsgálata. A változó a programban deklarált (vagy egyszerően csak hivatkozott) adatnév, amely a memóriának meghatározott típusú adat tárolására lefoglalt részét hivatkozza. Például hibás mőködést valószínősít, ha egy deklarált változót a program sehol nem használ, vagy ha egy változót a program azelıtt használja, hogy az értéket kapott volna. • Interfészelemzés: Olyan gyanús esetek felderítése, mint a deklarált, de mégsem használt eljárások és függvények, vagy olyan függvényhívás, amelynek visszatérési értékét a program nem használja fel. • Az adatáramlás elemzése: A bemenı és a kimenı adatokat tartalmazó változók közötti függések vizsgálata. • Útvonalelemzés: A program összes lehetséges végrehajtási útvonalának azonosítása, útvonalanként végrehajtott utasítások felsorolása. Az útvonalelemzés jól hasznosítható az útvonaltesztelési stratégia alkalmazása esetén a tesztspecifikáció készítésénél. Megjegyzés: A vezérlı utasításokkal vagy az adathasználattal kapcsolatos programozási hibák keresésének automatizálásánál hatékonyabb lehet egy olyan programnyelv használata, amely az ilyen hibák elkövetését eleve kizárja. Ilyen a már többször említett Java nyelv. A tesztelés és a programbelövés eszközei A tesztelést, a hibák és hiányosságok okainak azonosítását, valamint a javítást segítı eszközöknek a nyújtott szolgáltatás szerinti leggyakoribb kategóriái a következık: • Mőködési környezet, tesztelési feltételek kialakítása: A teszt végrehajtása a tesztelt kód rendeltetésének megfelelı mőködési környezet jelenlétét, bizonyos feltételek teljesülését kívánhatja meg. A tesztelés feltételeinek biztosítása gyakran maga is programozási feladat. Azonban egy kifinomult programozási környezettel nem csak az ilyen plusz programozási ráfordítások takaríthatók meg, hanem az olyan bizonytalanságok tisztázására irányuló vizsgálatok is, hogy egy hibajelenség oka valóban a tesztelt kódban van-e vagy a tesztelés feltételeit elıállító program hibázott. (Például egy objektum teszteléséhez jelen kell lenni más objektumoknak is, esetleg azoknak valamilyen szerkezetet kell alkotniuk, mint a 4.6.3. szakaszban a listaelem objektum listabanVan() mőveletének tesztelésérıl szóló példában. Ilyenkor elınyös, ha a programozói környezet képes arra, hogy párbeszédes módban – egy őrlap kitöltésével, illetve egérmőveletekkel – közölt kívánságoknak megfelelıen automatikusan elıállítsa a tesztelt objektumnak ezt a környezetét.) • Tesztadatok generálása: Ez a feladat is felfogható a mőködési feltételek biztosításának, de a tipikussága miatt külön kiemeljük. A tevékenység automatizálása különösen akkor hasznos, ha stresszteszthez kell nagy tömegben tesztadatokat elıállítani. (Példában ha nagy számú szimulált felhasználó által indított keresési mőveletek mellett teszteljük a válaszidıket, akkor ehhez elı kell állítani a felhasználandó keresı kulcsokat mégpedig meghatározott arányban olyanokat, amelyekre van találat az adatbázisban és olyanokat, amelyekre nincs. Az elıbbiek értékei az adatbázisból való leválogatással, az utóbbiak véletlen generálással állíthatók elı.) • Teszteredmény elırejelzése: Ez ugyan nem a programozói környezet feladata, mert általában nem is a programozás során, hanem egy új rendszernek vagy egy rendszer frissebb verziójának a használatba vételénél alkalmazzák, a probléma tipikussága

248


•

•

•

•

•

miatt mégis említést érdemel. A megoldás lényege az, hogy a tesztfeladatokat az adott szakterületre korábban alkalmazott rendszeren vagy verziófrissítés esetén a rendszer korábbi verzióján lefuttatják, és az így kapott kimeneteket várják el az új rendszeren vagy a frissebb rendszerverzión végrehajtott teszttıl is. Állományösszehasonlítók: Az állományösszehasonlítókról a programkód szerkesztésénél (lásd a kódverziók összahasonlítását) már volt szó. Hasonlóan hasznosíthatók a különbözı tesztmenetek eredményeinek összehasonlításánál; például a korábbi rendszerrel kapott (elırejelzett) teszteredmények és az új rendszeren végrehajtott teszt kimeneteinek összehasonlításánál; vagy a belövés során a javítás elıtti és utáni teszteredmények összehasonlításánál. Dinamikus elemzık: Egyik változata az elemzett kódot (az elemzés idejére) olyan kóddal egészíti ki, amely a futás alatt az eredeti utasítások végrehajtási alkalmainak számlálását végzi. Így teszt lefutása után egy olyan statisztika (hisztogram) áll az elemzı rendelkezésére, amely az egyes utasítások végrehajtásának gyakoriságát mutatja. Egy ilyen megoldás jó szolgálatot tehet, ha a program teljesítményének javítása a feladat. Ugyanis komoly eredmény a leggyakrabban végrehajtódó utasítások futási idejének csökkentésével érhetı el. Nyomkövetés lépésenkénti végrehajtással: Itt a programozási környezet olyan szolgáltatására kell gondolni, amely a program „lassított” lépésenkénti (utasításonkénti) végrehajtását teszi lehetıvé. Egy-egy utasítás után a rendszer a tesztelı beavatkozására várakozik, aki ilyenkor megtekintheti a programmal érintett változók aktuális állapotát is, illetve gombnyomással engedélyezi a következı utasítását végrehajtását. Egy rendszer minden porcikájának ilyen módon való ellenırzése természetesen lehetetlen, de ez a módszer nagyon hasznos lehet, ha egy hiba lokalizálására irányuló más módszerek már csıdöt mondtak. Szimulátor: A szimulátor egyik alkalmazása stresszteszt esetén nagy számú egyidejőleg tranzakciót kezdeményezı felhasználó szimulálása. Egy másik eset, amikor a szimulátor egy még el nem készült komponenst helyettesít, annak lehetséges kimeneteit produkálja azzal a céllal, hogy e kimeneteket használó más komponensek a kimenetet tényleges elıállítására szolgáló komponens hiányában tesztelhetık legyenek. Tesztmenedzser: Komplex rendszerek rendszeres tesztelésével foglalkozó szervezet számára jó befektetés lehet egy tesztmenedzser szoftver alkalmazása. Egy ilyen eszköz menedzseli a vele közölt tesztfeladatok futtatását, és nyomon követi, hogy milyen tesztadatokkal, milyen komponesek lettek tesztelve és milyen eredménnyel.

4.6.5 Használatba vétel – A rendszer bevezetésének módjai

Egy új rendszer használatba vételének (bevezetésének) teendıi: • a szervezeti (üzleti) folyamatok újraszervezése – a rendszer szakmai felhasználási környezetének kialakítása; • a rendszer testreszabása; • a rendszer üzemeltetési, technikai környezetének kialakítása, a rendszer üzemeltetési környezetbe telepítése; • adatmigráció, azaz a korábbi rendszer adatainak konvertálása és betöltése az új rendszer adatbázisába; • a felhasználók kiképzése; • a rendszer átvételi (próbaüzemi) tesztje – ez egy üzemi környezetben tényleges volumenek, illetve csúcsterhelés mellett végrehajtott minıségi teszt;


249

átállás az új rendszerre.

Ha a szoftver nem egyedi fejlesztés eredménye, hanem egy szélesebb körben forgalmazott áru, amely beszerzéssel kerül a szervezethez, akkor a bevezetés elsıdleges feladata a szoftver testreszabása, azaz a szervezeti igényekhez illesztése. – A jó szoftverek azonos típusú problémák kezelésére sokféle alternatív megoldást kínálnak a szoftver bevezetıjére bízva a választást. A szoftver bevezetésének gyakori feladata a szervezet folyamatainak újraszervezése. Optimális esetben a folyamatok újratervezése már a beszerzés vagy a fejlesztés elıtt megtörténik, és a kapott folyamattervek – mint megvalósítandó cél – ismeretében történik a fejlesztés vagy a beszerzés. Ez esetben a folyamatok újraszervezése egyértelmően az újratervezéssel feltárt optimumcélok teljesítése okán történik, és csak azért halasztódik a szoftver bevezetésének idejére, mert az elképzelt új folyamatok csak az új szoftver birtokában valósíthatók meg. Szoftverbeszerzés esetén a szervezeti folyamatok újraszervezésének a gyakorlatban általában más okai is vannak: • A szervezet korábban nem foglalkozott a folyamatai megújításával, optimalizálásával, hanem éppen az új szoftver filozófiája által diktált folyamatok bevezetésétıl várja, hogy automatikusan a legjobb gyakorlat (best practice) birtokába fog kerülni. • A beszerzett szoftver nem minden tekintetben testreszabható, ilyenkor bizonyos értelemben „a kabátot kell varrni a gombhoz”. 4

Komplex rendszerek esetében a szervezeti folyamatok újraszervezése és a szoftver testreszabása egy (kevésbé komplex) rendszer egyedi fejlesztésével egyenértékő ráfordításokat jelenthet, és hosszabb ideig (hónapokig, egy-két évig) tarthat.

Az új rendszerre átállás történhet: • közvetlenül, • szakaszosan, • párhuzamos üzemeltetéssel. A közvetlen átállás azt jelenti, hogy egy csapásra lecserélik a régi rendszert az újra. Egy új fejlesztéső rendszer esetében ez a megoldás csak akkor ajánlható, ha a rendszer kis mérete, egyszerősége vagy az alkalmazó közeg mérsékelt érzékenysége miatt alacsony a kockázat. Egy szoftverház által forgalmazott és széles felhasználói kör által kipróbált rendszer is – hacsak nem igényel bonyolult testreszabást – alapos elıkészítéssel bevezethetı közvetlenül. Az alapos elıkészítés vonatkozik a szoftver bemeneti, kimeneti kapcsolódási pontjaira; az üzemeltetési környezetre; a felhasználók kiképzésére, a szoftver tesztkörnyezetben való kipróbálására. A szakaszos átállásnak két változata lehet. Az egyik megoldás a részlegenkénti szakaszos átállás: a rendszert elıbb a szervezet egy részlegénél vezetik be, majd siker esetén fokozatosan a többieknél is. Az elsı részlegnél a rendszert alapos tesztnek vetik alá, esetleg ott a párhuzamos üzemeltetést is alkalmazzák. – A másik megoldás a modulonként szakaszos átállás (szakaszos bevezetés): elıbb a szoftvernek csak egy vagy néhány modulját vezetik be, és fokozatosan kerül sor további modulok bevezetésére. (Ez utóbbi megoldás nemcsak az átállás mozzanatára, hanem az egész bevezetési folyamatra alkalmazható, amennyiben a késıbb bevezetendı modulokhoz kapcsolódó újraszervezés és testreszabás is szakaszosan történhet.) – A szakaszos átállás mérsékli a kockázatot a közvetlen átálláshoz képest, és kisebb költséggel, munkaráfordítással jár, mint a párhuzamos üzemeltetés. Viszont minden elınye ellenére nem lehet szó részlegenkénti szakaszos átállásról, ha a különbözı részlegek intenzíven hasz-

250


nálják egymás adatait, és az új adatszerkezetek különböznek attól, amelyekre a régi rendszer számít. A párhuzamos üzemeltetéssel járó átállás esetén egymás mellett üzemel a régi rendszer és az új. Ha a régi rendszerrel való összehasonlítás az új rendszer megbízhatóságát igazolja, a régi leállítható. – Mivel minden tranzakciót fel kell dolgozni mind a két rendszerben, ez nagyon költséges és az alkalmazottakat is megterhelı megoldás. Azonban a nagy kockázatú rendszerek esetén, másképpen szólva a rendszer megbízhatósága, illetve a biztonsága iránt érzékeny alkalmazói környezetben való bevezetésekor csak ez a megoldás alkalmazható. 4.6.6 Ellenırzı kérdések a 4.6. alfejezethez

1. Adja meg a kivitelezés szőkebb és tágabb értelmezését (a szoftverfejlesztésben)! 2. Adjon példát verifikációs, illetve validációs célú tesztekre! 3. Mi a különbség szoftverátvizsgálás és a szoftvertesztelés között? 4. Mi a különbség hiányosságtesztelés és a statisztikai tesztelés között? 5. Hogyan kapcsolódik egymáshoz a tervezés és a kódgenerálás? 6. A programkódoláson belül hogyan kapcsolódik egymáshoz a kódgenerálás és kódszerkesztés? 7. Mit kell igazolni az egységteszttel? - Mi az egységteszt specifikációjának a forrása? 8. Mi a szoftverbelövés tevékenység tartalma? 9. Mit kell igazolni a különbözı szintő integrációs szintekkel? Mi képezi ezek specifikációjának forrását? 10. Mit tartalmaz a tesztterv? 11. Mit tartalmaz a tesztspecifikáció? 12. Jellemzıen milyen interfészhibák feltárására terjed ki az interfésztesztelés? 13. Mutassa be az inkrementális tesztelés és belövés folyamatát! 14. A szoftver milyen jellemzıinek igazolására, illetve milyen hibák kimutatására alkalmas a stresszteszt? 15. Mit jelent az objektumok együttmőködésének forgatókönyv alapú tesztelése? 17. Milyen forrásokra támaszkodik a minıségi teszt specifikációja? 18. Milyen funkciók várhatók el a programkódolást, a tesztelést és a belövést támogató programozási környezettıl? 19. Szoftver beszerzése (bevezetése) esetén milyen indokai lehetnek a szervezeti folyamatok újraszervezésének? 20. Határozza meg a szoftver használatba vételének (bevezetésének) jellemzı teendıit! 21 Ismertesse az új rendszerre átállás módjait!


251

FELHASZNÁLT ÉS AJÁNLOTT IRODALOM A 4. FEJEZETHEZ

[Boehm-1979] BOEHM,B.W.: Software Engineering; R & D trends and defense needs. In Research. Directions in Software Technology (P. Wegner, ed.). Cambrigde, MA: MIT Press. (19. fejezet) [Boehm-1988] BOEHM,B.W.: A spiral model of software development and enhancement. IEEE Computer, 21 (5) 1988, 61-72. [Booch-1991] BOOCH, G.: Object-Oriented Design with Applications. Benjamin Cummings, 1991. [Booch-1998] BOOCH,G. – JACOBSON,I. – RUMBAUGH,J.: The Unified Modeling Language User Guide. Addison-Wesley, 1998. [Bröhl-1993] BRÖHL,A.P. – DRÜSCHEL,W.: Das V-modell. Der Standard für Softwareentwicklung mit Praxisleitfaden. R. Oldenburg Verlag, 1993. [Clegg-1994] CLEGG,D. – BARKER,R.: Case Method Fast-Track. A RAD Approach. AddisonWesley, 1994. [Coad-1990A] COAD,P. – YOURDON,E.: Object-Oriented Analysis. Yourdon Press, 1990. [Coad-1990D] COAD,P. – YOURDON,E.: Object-Oriented Design. Yourdon Press, 1990. [Dahl-1966] DAHL,O. – NYGAARD,K.: „Simula: An Algol-based Simulation Language”, Communication of the ACM. 9. 1966. [Dahl-1972] DAHL,O.J. – DIJKSTRA,E.W. – HOARE,C.A.R.: Strukturált programozás. Mőszaki Könyvkiadó, 1978. (eredeti kiadás: Structured Programming. Academic Press, London and New York, 1972.) [Friedman-2005-2007] FRIEDMAN, THOMAS L.: És mégis lapos a Föld. A XXI. század rövid története. HVG Kiadói Rt., 2008. (eredetiben: The World is Flat. A Brief History of the Twenty-First Century. 2005, 2006, 2007) [Goldberg-1984] GOLDBERG,A.: Smalltalk 80: The Interactive Programming Environment. Addison-Wesley, 1984. [Jackson-1975] JACKSON,M.: Principles of Program Design. Academic Press, London, 1975. [Jacobson-1992] JACOBSON,I. – CHRISTERSON,M. – PATRIK,J. – ÖVERGAARD,G.: ObjectOriented Software Engineering – A Use Case Driven Approach. Addison-Wesley, 1992. [Jacobson-1999] JACOBSON,I. – BOOCH,G. – RUMBAUGH,J.: The Unified Software Development Process. Addison-Wesley, 1999. [Katzan-1976] KATZAN,H. JR.: Systems Design and Documentation: An Introduction to the HIPO Method. Van Nostrand Reinhold, New York, 1976. [Lutz-1993] LUTZ,R.R.: Analysing software requirements errors in safety-critical embedded systems. Proc. RE’93, San Diego, CA, IEEE. (16., 20., 21. fejezet) [Mills-1980] MILLS,H.D. – O'NEILL,D. – LINGER,R.C. – DYER,M. – QUINNAM,R.E.: The management of software engineering. IBM Sys. J., 24 (2) 1980, 414-477. [Norman-1986] NORMAN,D.A. – DRAPER,S.W. (eds.): User-centered System Design. Lawrence Erlbaum Associates, Hillsdale NJ, 1986 [Nyékiné-2001] NYÉKINÉ GAIZLER J. (szerkesztı és társai): JAVA 2 – Útikalauz programozóknak: 1.3. ELTE TTK Hallgatói Alapítvány, Budapest, 2001.

252


[OMG-2001] OMG Unified Modeling Language Specification, Version 1.4. 2001 September, ftp://ftp.omg.org/pub/docs/formal/01-09-67.pdf [OMG-2002] OMG Unified Modeling Language Specification, Version 1.5 (Proposed working draft). 2002 September, http://cgi.omg.org/docs/ptc/02-09-02.pdf [Orr-1977] ORR,K.: Structured System Development. Yourdon Press, New York, 1977. [Rumbaugh-1991] RUMBAUGH,J. – BLAHA,M. – PREMERLANI,W. – EDDY,F. – LORENSEN,W.: Object-Oriented Modeling and Design. Prentice-Hall, Englewood Cliffs NJ, 1991. [Shlaer-1988] SHLAER,S. – MELLOR,S.J.: Object-Oriented Software Analysis. Yourdon Press, 1988. [Sommerville-2002] SOMMERVILLE,I.: Szoftverrendszerek fejlesztése. (Software Engineering 6. kiadás fordítása) Panem Kft, 2002. [Sun-2002] SUN MICROSYSTEMS,INC.: Object-Oriented Application Analysis and Design for Java Technology (UML) . – OO-226 Student Guide. (Revision C), 2002. [Sun-2007] SUN MICROSYSTEMS: SunTone Architecture Methodology. http://www.makeitfly.co.uk/Presentations/suntoneam_wp_5.24.pdf, elérés 2007.08.01. [Ward-1985] WARD,P. – MELLOR,S.: Structured Development for Real-time Systems. Prentice-Hall, Englewood Cliffs NJ, 1985. [Warnier-1977] WARNIER,J.D.: Logical Construction of Programs. Van Nostrand Reinhold, New York, 1977. [Yourdon-1989] YOURDON,E.: Modern Structured Analysis. Prentice-Hall, Englewood Cliffs NJ, 1989. Szabványok: MSZ ISO/IEC 9126:2000 Informatika – Szoftvertermékek értékelése. Minıségi jellemzık és használatuk irányelvei MSZ ISO/IEC 12207 Informatika – Szoftveréletciklus-folyamatok

4. Információrendszer fejlesztése

Recommend Documents