Az Egységesített Eljárás módszertan

Az Egységesített Eljárás módszertan Az Egységesített Eljárás (RUP, Rational Unified Process) továbbiakban RUP egy iteratív és inkrementációs szoftverfejlesztési eljárás, amelyet a Rational Corporation (2002 óta az IBM része) fejlesztett ki a 90-es évek közepétől. A RUP nem egy szokásos, egyszerű eljárás, hanem inkább egy feladatokra adaptálható keretrendszer, amelyből minden feladattípushoz az ahhoz illeszkedő módszereket, eszközöket alkalmazhatjuk. Ugyanakkor a RUP maga is egy szoftvertermék, amely leírásokat, ismeretbázist és példákat is tartalmaz különböző megoldásokra. Rövid történet A RUP gyökerei a 80-as és 90-es évek módszertani kísérleteiig nyúlnak vissza (spirális, evolúciós stb. modellek és a rájuk épülő eljárások) a Rational Approach kidolgozásáig. 1995-ben a Rational megvette a svéd Objectory Systems céget, amely szintén módszertani kérdésekkel foglalkozott (Ivar Jacobson munkássága). A két cég összeolvadásának, és kutatásaik egységesítésének (Rational Approach és Objectory Process) lett az eredménye a Rational Objectory Process és a Rational Rose modellező szoftver. A Rational Unified Process első publikált változata 1998-ban jelent meg, az utolsó pedig már az IBM égisze alatt, 2005-ben. Az elgondolás A RUP tervezői a szoftverfejlesztési problémákra koncentrálva, azok megoldására keresték a választ. Szoftverkrízis A 80-as évekre a szoftvergyártásban olyan helyzet alakult ki, amelyet ma szoftverkrízisnek nevezünk. Lényegében arról volt szó, hogy az addigi szoftverfejlesztési módszerek és eszközök egyre kevésbé feleltek meg a világ változó igényeinek; egyre több fejlesztés jutott zsákutcába (kb. 75%!!!). Kezdetben úgy tűnt, hogy a programkészítési eszközökben és módszerekben kell a problémák gyökerét keresni a 80-as évek végétől emiatt gyorsult fel pl. az objektumorientált programozási módszer elterjedése és a WYSIWIG jellegű integrált programfejlesztő eszközök készítése mindezek célja pedig a gyors, komponensalapú alkalmazásfejlesztés támogatása volt. A 90-es évekre a programozási módszerek és eszközök palettája szinte teljesen megújult de érdekes módon (a felmérések szerint), ez csak igen rövid ideig tartó és átmeneti hatást gyakorolt a fejlesztések eredményességére. Ekkor a kutatások más irányba, a komplex fejlesztés modelljeinek és módszertanainak irányába fordult. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 1

A különböző kutatások, felmérések a kudarcok okait keresve az alábbi fő tényezőket szűrték ki: esetleges, következetlen követelményfeltárás és elemzés; félreérthető, pontatlan kommunikáció; túl bonyolult megoldások; következetlenségek a követelmények-tervek-implementációk között; elégtelen tesztelés; a fejlesztési projektek állapotának szubjektív értékelése; kockázatelemzési hiányosságok, hibák; a változások kezelésének hiányosságai. A fejlesztési projektek problémáit általában néhány jellemző tünet mutatja bár maguk a bukások mindig egyedi módon következnek be. Az esetek tanulmányozásának eredményeképpen született meg az a legjobb megoldások (best practices) gyűjtemény, melyből a RUP kinőtt. A fejlesztési folyamat életciklusa A RUP szemléletében egy fejlesztés életciklusa a munka megkezdésétől a késztermék egy üzemszerű működésre szánt változatának átadásáig tart. 1. ábra A fejlesztés életciklusa Kezdet, előkészítés A fejlesztés kezdeti szakaszában a munka elhatározása, a feltételek és erőforrások meghatározása történik. Ez a szakasz gyakorlatilag egybeesik a projektfolyamatok első szakaszával, melyben célmeghatározások, felmérések, különféle erőforrásbecslések, projektváltozatok és az ezekhez kapcsolódó megvalósíthatósági tanulmányok és egyéb elemzések készülnek. Ezek alapján megtörténik a fejlesztés indítására vonatkozó döntés. A kezdeti szakaszban választ kell adni az alábbi kérdésekre: Kik a fejlesztés által érintett, illetve a fejlesztést leginkább befolyásoló kulcsfigurák (emberek, más rendszerek és igényeik, érdekeik)? Melyek az alapvető, meghatározó követelmények (a rendszer határainak meghúzása)? Az idő- és (vagy) költség-előirányzatok, prioritások, kockázati tényezők és a fejlesztési folyamat részeinek pontosítása, véglegesítése. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 2

Architekturális kérdések tisztázása. (A RUP megfogalmazása szerint az architektúrának mindaz része, ami lényegében meghatározza a rendszer jellegzetességeit.) Kidolgozás A kidolgozási fázisban kezd testet ölteni a fejlesztési projekt. A fő cél a követelményrendszer és az általános megoldási elképzelések felállítása az üzleti modellezés, szakterületi modellezés, kulcsfigurák igényei alapján. Ezekre támaszkodva meg kell alkotni a szoftver végleges architektúráját (a tervezett rendszer fő alkotóelemei és azok fontossági sorrendje, kapcsolatrendszere). Elkezdődik a rendszer tényleges tervezése, és a részeredmények prototípus-programokban való tesztelése. Építés Az építési szakaszban a rendszer komponenseinek véglegesítése és kivitelezése történik. Elkészül az első, kiadható programkód. Átadás Az átadási szakaszban kerül a szoftver a fejlesztőtől a felhasználóhoz. A szakasz jellemző tevékenységei: a felhasználók oktatása, a felhasználói tesztek elvégzése. Az alábbi ábra a RUP folyamatát és a folyamathoz kapcsolódó tevékenységeket szemlélteti. 2. ábra A RUP buckás" ábrája Fázisok és iterációk A folyamat a spirál modell egy megvalósításának tekinthető. Az ábra a fejlesztés egy ciklusát, egy termékverzió előállítását mutatja. A fejlesztési ciklus négy fázisból áll (előkészítés, kidolgozás, építés, átmenet), egy-egy fázis elkészítése során több munkafolyamatot (függőleges tengely) érint. Az egyes munkafolyamatok a különböző fázisokban különböző intenzitásúak, erőforrás-igényűek. Másik megközelítésben a fázisok iterációkra bonthatók. Minden egyes iteráció egy-egy mini projekt, melynek Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 3

során a rendszer egy inkrementuma (a célokat, követelményeket valamilyen kidolgozottsági szinten teljesítő megoldás) áll elő. Tehát az ábra vízszintes dimenziója az időbeliséget, függőleges dimenziója a különböző tevékenységeket szimbolizálja. Időben a fejlesztés fázisokra, a fázisokon belül iterációkra bomlik, az egyes fázisok végén ún. mérföldkövek vannak. Minden egyes iteráció egy-egy fejlesztési mini projekt, melyben kicsiben megvan minden, ami egy fejlesztési projekt szerves része. Kezdődik az üzleti modellezéssel, követelményelemzéssel, folytatódik elemzéssel, tervezéssel, implementálással, teszteléssel, és befejeződik a telepítéssel. Az iteráció végén a rendszer újabb, bővített funkcionalitású verziója készül el. A fejlesztés különböző fázisaiban az iterációk lényegesen különbözőek lehetnek. Míg a fejlesztés kezdeti szakaszában az üzleti modellezés és a követelményelemzés a hangsúlyosabb, s a tesztelés, telepítés lehet, hogy ki is marad, addig a középső szakaszban az implementálás, a legvégső szakaszban a telepítés, a tesztelés a domináns. A fejlesztés bizonyos szakaszaiban egyes munkafolyamatok erőforrásigénye szinte nullára is csökkenhet. Az iterációk számát nem rögzíti a szabvány, fázisonként illetve fejlesztésenként eltérő számú iterációra lehet szükségünk. Hasonlóan az iterációkhoz, a fázisok is a projekt időbeli lefolyását tagolják, számuk és nevük azonban kötött. A fázisok a hasonló iterációk összessége. A fázisokhoz jellegzetes mérföldkövek, azaz elérendő célok tartoznak. A fázis végén, a mérföldkő elérésekor lehet és kell dönteni a projekt további sorsáról. Természetesen a fázisokat lezáró nagy mérföldkövekhez hasonlóan minden egyes iteráció végén is számba kell venni, hogy sikeresek-e az erőfeszítéseink; ezeket a technikai jellegű célokat nevezi a RUP terminológiája kis mérföldkőnek. Munkafolyamatok, tevékenységek A módszertan tevékenységtípusok szerinti tagozódását mutatja a buckás ábra függőleges dimenziója. Ez a munkafolyamatok (újabb megfogalmazás szerint diszciplínák), termékek, munkatársak szerinti tagozódás. A tevékenység jellegének megfelelően megkülönböztetünk mérnöki, illetve támogató folyamatokat. A mérnöki folyamatok hozzák létre a szoftverterméket, míg a támogató munkafolyamatok a fejlesztés irányításával, a környezet biztosításával, a változáskövetéssel, azaz a menedzsment feladataival foglalkoznak. Az ábra harmadik dimenziója amit a sávok magassága jelent, az egyes tevékenységek intenzitását, erőforrásigényét szimbolizálja. Mérnöki munkafolyamatok Üzleti modellezés (Business Modelling) Azt a környezetet írja le, amelyikben a rendszer működik, vagy amelyikben működni fog. A rendszernek az üzleti környezetben, a szakterületi környezeten belüli helyét határozza meg. Más néven szakterületi (domain) modellezés. Értelmezhető mind a jelenlegi, mind a tervezett rendszer üzleti környezetére. Követelménytervezés (Requirements) A rendszernek kívülről, a felhasználó szempontjából való leírását adja meg. Feladata a funkcionális és a nem funkcionális követelmények összegyűjtése. A funkcionális követelményeket jellemzően használati esetekként gyűjtjük össze. A Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 4

rendszer működőképességét lényegesen befolyásolhatják a nem funkcionális követelmények (üzleti környezet, hardver- és szoftverkörnyezet, egyéb követelmények: pl.: válaszidők, technológia, megbízhatóság stb.) is. Elemzés és tervezés (Analyzis & Design) o Elemzés A rendszer képét belülről, a fejlesztő szempontjából írja le. Az architektúrára koncentrál, koncepcionális szintű osztályokat és együttműködéseket határoz meg. o Tervezés Feladata az implementálható pontosságú tervek elkészítése. Hasonlóan az elemzés munkafolyamatához, a rendszert belülről, a fejlesztő szempontjából írja le, azonban a leírás lényegesen részletesebb. A RUP összevonja az elemzés és a tervezés munkafolyamatát. Kódolás (Implementation) Feladata a rendszer tényleges elkészítése, a kódolás. Az implementációs szintű tervek tekintettel vannak a konkrét környezetre, a forráskód pedig erősen kötődik a hardver- és (vagy) szoftverkörnyezethez. Tesztelés (Test) Feladata a rendszer helyességének ellenőrzése. Magában foglalja a tesztelés tervezését, a teszteléshez szükséges adatok, eszközök elkészítését, a tesztek tényleges lebonyolítását illetve az esetleges hibák, hiányosságok visszajelzését. Telepítés (Deployment) Telepítéssel, üzemeltetéssel kapcsolatos tevékenységek. Támogató munkafolyamatok Projektvezetés (management) A fejlesztési projekt működését, menetét irányító projektmenedzsmenttevékenység. Változáskövetés (change and configuration management) A fejlesztés során különféle változások következhetnek be a feltételekben (pl. követelmények változásai). E változások folyamatos figyelése és érvényesítése a tervezésben-kivitelezésben döntő fontosságú. Környezet biztosítása (environment) A fejlesztési folyamatok felülvizsgálata, tervezést és kódolást segítő eszközök biztosítása. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 5

A RUP termékei A módszertan különböző termékeket definiál, amelyeket a fejlesztési folyamatban elő kell állítani. A fejlesztés eredménye mindig több, mint a kód: tervek, dokumentációk, modellek. Egyetlen fejlesztési cikluson belül is állandóan használjuk a megelőző tevékenységek dokumentációit, s amennyiben az előállított terméket használják, úgy szinte biztos, hogy előbb-utóbb lesznek módosítási, továbbfejlesztési, bővítési, hibajavítási igények is. Ebben az esetben szintén újra felhasználjuk a már elkészített dokumentációkat. A RUP termékei két, egymástól független dimenzió szerint csoportosíthatóak. Beszélünk nézetekről, illetve beszélünk modellekről. Nézetek A különböző nézetek ugyanazon rendszernek lényegében ugyanannyira részletes leírásai, de a rendszer különböző oldalait mutatják. A különböző nézetek lényegében egyenrangúak, illetve az alkalmazás jellege dönti el, hogy melyik nézet mennyire határozza meg az architektúrát. A 4+1 nézet A RUP megfogalmazása szerint a teljes rendszert 4+1 nézetből lehet leírni. A különböző nézetek ugyanazt a rendszert különböző szemszögből láttatják. Például, ha szemügyre vesszük a számítógépes egeret, milyen szempontok szerint modellezhetjük? Többek között nézhetjük belső szerkezetét és az egyes elemek egymáshoz való viszonyát ekkor statikus nézetről beszélünk, és felvázoljuk az egér lényeges alkatrészeit és kapcsolódásukat egymáshoz. 3. ábra Az egér szerkezeti elemei Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 6

Ha az egér működését szeretnénk megérteni/bemutatni, akkor dinamizáljuk a modellt (dinamikus nézet): 1: Az egér mozgatása elforgatja a golyót. 2: Az irányérzékelő görgők tartják a golyót, és továbbítják a mozgást. 3: Fényáteresztő résekkel rendelkező tárcsák. 4: Az infravörös LED átvilágít a korongok résein. 5: A szenzorok (optikai kapuk) érzékelik a fényimpulzusokat. 4. ábra Az egér belső működését bemutató modell Mindkét esetben ugyanazt a rendszert vizsgáltuk csak más szemszögből, más nézetben. 5. ábra A RUP nézetei Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 7

Tervezési nézet ( Design view) A rendszerben szereplő dolgokat fogalmakat, tárgyakat, kapcsolatokat és együttműködéseket mutatja. Implementációs nézet, avagy Komponens nézet A rendszerben lévő szoftverkomponenseket (exe fájlok, dll-ek, adatbázis-táblák stb.) mutatja. Dinamikus, avagy folyamat nézet A rendszerben lévő zajló folyamatokat, műveleteket, a párhuzamos működést, a processzeket, taskokat, szálakat mutatja. Telepítési nézet A tényleges fizikai telepítést, a hálózati csomópontokat mutatja. Követelmény nézet A rendszer felhasználóit (aktorok/actor), a funkcionalitást (használati eseteket, use case) mutatja. Az egész szoftverfejlesztési folyamatot a követelmények (elsősorban a felhasználó által elvárt szolgáltatások használati esetek) vezérlik, mivel azt és úgy kell megvalósítanunk, amire és ahogyan a felhasználónak szüksége van. Modellek A különböző modellek a rendszer logikailag különböző absztrakciós szintjeit mutatják be. A modellekre jellemző, hogy minden modellt meghatároz a logikailag nála magasabb szinten lévő modell. Az egyes modellek kidolgozása viszonylag szorosan köthető egyrészt a nézetekhez, másrészt a fejlesztés munkafázisaihoz: pl. a követelményelemzés jellegzetes terméke a használati eset modell, az implementáció terméke az implementációs modell, s az implementációs modell értelemszerűen függ a használati eset modelltől. A fejlesztés során a különböző modellek eltérő sebességgel növekednek, a fejlesztésnek már a korai szakaszában viszonylag jól kidolgozott a használati eset modell, míg az implementációs, avagy a teszt modell eleinte alig növekszik. A modelleket diagramokon ábrázoljuk, a diagramokat és az azokon alkalmazható szimbólumokat, definíciókat és az alkalmazási szabályokat az UML (Unified Modeling Language, Egységes Modellező Nyelv) írja le. Korábban (a 4. ábrán) az egér mechanikus és optikai elemeinek együttműködését mutattuk be valósághű ábrázolásban. Ha teljesen szabadon, minden fizikai megkötéstől mentesen akarunk gondolkodni, elvonatkoztathatunk ezektől, és modellezhetjük az egér működését a célnak megfelelő (jelen esetben épp együttműködési) UMLdiagram segítségével. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 8

támasztó görgő infra led 3: Támaszt 2: Forgat +fény +átereszt/visszaver golyó 1: Fordul irányérzékelő 1.1: Fordul görgő fényáteresztő tárcsa 1.2: [ha átereszt]:fényimpulzus optikai kapu 6. ábra Az egér működésének absztrakt modellje Az alábbi ábrákon további példákat láthatunk modellekre, illetve az ezeket bemutató diagramokra. Beállítás Bejelentkezés «extend» Diák Bemutatás «extend» Fileválasztás «extend» Feltöltés Tanár 7. ábra Egy oktatási demonstrációs alkalmazás felhasználók szerinti funkciómegoszlását mutató használati eset diagram Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 9

Égitest név: Karakter pozíció: Koordináta sugár: Egész szín: Szín kering körülötte * MozgóÉgitest maxtáv: Egész mintáv: Egész keringésiidő: Egész Csillag Sugároz() : void Mozog() : void Hold Bolygó Üstökös Csóvál() : void 8. ábra A Naprendszer objektumait és azok kapcsolatrendszerét bemutató logikai modell diagramja Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 10

+Kapcsolat a játékossal, játékelemek megjelenítése Megjelenítő játékfelület «manifest» «program-m... felület +Parancsok értelmezése játékvezérlő Vezérlő Lufik «manifest» «program-m... vezérlő +Lufik létrehozása, rendelkezésre bocsájtása, megszüntetése +Találatvizsgálat +Lövedékek indítása, rendelkezésre bocsájtása, megszüntetése; Ágyú működtetése Lufik lufi Löv és lövedék lufigép ágyú «manifest» «manifest» «program-m... lufik «program-m... lövés 9. ábra Egy játékprogram komponensmodellje iskola + Beoszt() : void + Felvesz() : void 2: Tanít() tanár + Tanít() : void - Felkészül() : void - Előad() : void - Feleltet() : void 2.1: Felkészül() 2.2: Előad() 2.3: Feleltet() 3: Tanul() 4: Felel() 1: Beiratkozik() diák + Tanul() : void + Felel() : void + Beiratkozik() : void 10. ábra Iskola Tanár Diák együttműködést ábrázoló diagram Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 11

Vevő Egy internetes árurendelés folyamata Belépés a weboldalra «datastore» Készlet Termék kiválasztása Összetett lépés Van kiválasztott termék? [igen] [nem] Vége Bankkártya megadása Rendelés elküldése Szállító Raktárkészlet ellenőrzése Bankkártya ellenőrzése Rendben? [nem] Rendben? [igen] [igen] [nem] Rendelés megszakítása Összetett lépés Kifizetés Termék küldése «datastore» Készlet Vége 11. ábra Folyamatot ábrázoló diagram Termékek A RUP termékei a legfőképpen modellekben megtestesülő dokumentumok, és természetesen maga a szoftver. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 12

Az RUP jellemzői Az eddigiek alapján összefoglalhatjuk a RUP jellemzőit, amit az alábbi háromlábú székkel szoktak illusztrálni. 12. ábra A RUP háromlábú széke" Követelményvezérelt jelleg A korábban említett, a fejlesztési projektek kudarcait elemző felmérések, vizsgálatok szerint a problémák egyik fő oka a követelmények nem megfelelő kezelése. A módszertan ezért az egyik fő szempontként emeli ki a követelménymenedzsment fontosságát és érvényesíti is mind a nézethierarchiában, mind a fejlesztési munkafolyamatokban. A követelménymenedzsment folyamatos tevékenység, amely végigkíséri a fejlesztés teljes folyamatát. Célja a követelmények feltárása, rendszerezése, dokumentálása. További fontos feladata a követelmények változásának nyomon követése és ezek érvényesítése a fejlesztési folyamatra. A módszertan elvárja, hogy a befoglaló projektirányítás megoldja és alkalmazza a követelmények menedzselését mind módszerben, mind szervezésben, mind dokumentációs megoldásaiban. Architektúra központúság Architektúra alatt egy rendszer meghatározó összetevőit és ezek kapcsolatait értjük. Az architektúra célja: átláthatóvá teszi a fejlesztést; könnyebben felismerhetők az újrafelhasználható elemek; átlátható projektmenedzsment; kockázatok csökkentése; lehetővé válik a párhuzamos fejlesztés. Architekturálisan fontos nézetek Az alkalmazás jellegének megfelelően a 4+1 nézet közül némelyek jelentősen befolyásolják az architektúrát, míg mások alig hatnak rá. Például egy erősen osztott alkalmazás esetében jelentős, meghatározó szerepe lesz a telepítési nézetnek, míg egy párhuzamos feldolgozásokra kitalált alkalmazás esetében a dinamikus nézet architektúra lesz meghatározó. Az alkalmazás jellegétől függetlenül a követelmény (használati eset) nézetnek mindig kitüntetett szerepe van (erről szól a háromlábú szék első lába). Ugyanígy nagyon sokszor architektúrát meghatározó a tervezési nézet. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 13

Az architektúra az alkalmazás jellege alapján Egy alkalmazás funkcionális elemeinek (objektumok) csoportosítására, az alkalmazás alapvető jellegének meghatározására az MVC koordinátarendszert, illetve a sztereotípus fogalmát használjuk. E megfogalmazás szerint minden objektum elhelyezhető a model view control koordináta-rendszerben, s minden jól tervezett objektum jellegzetesen e három koordináta valamelyike felé húz. Így beszélhetünk egyed, határ illetve vezérlő jellegű (sztereotípiájú) objektumokról. 13. ábra Objektumok kategóriái Az egyed jellegű objektumok jellemző feladata az adatok tárolása. A határobjektumok a külvilággal tartják a kapcsolatot (pl. felhasználói felület, ablakok), a vezérlő objektumok pedig a szakterületi feladatokat, műveleteket ismerik, látják el, illetve koordinálják a működést. E gondolatmenet általánosítható az alkalmazásokra is, hiszen egy-egy alkalmazás nem más, mint egy meglehetősen nagy, összetett objektum. Az alkalmazás jellege (egyed, vezérlő, vagy határ dominanciájú alkalmazás) befolyásolja, hogy a tervezési modell mely sztereotípusai lesznek architekturálisan meghatározóak. Egyed dominanciájú alkalmazások Ezek a klasszikus információs rendszerek, fő feladatuk az adatkezelés. Az architektúrára lényeges hatással van a szakterületi modell, illetve a hosszú távú tárolás az esetek többségében ez adatbázis-táblákat jelent. Ezeknél az alkalmazásoknál érdekes feladat a relációs szemléletű adatbázis-logika illetve az objektumos szemléletű kezelői felület (és alkalmazáslogika) összekapcsolása. Felület dominanciájú alkalmazások Jellegzetes desktop alkalmazások, szövegszerkesztők, képmanipuláló programok, vizuális felhasználói környeztek stb. Az architektúrát a határ jellegű elemek dominálják, az architektúra leírásánál a határ jellegű elemek osztály- illetve együttműködés diagramjai a mérvadóak, valamint a felhasználói felület prototípusa. Algoritmus dominanciájú alkalmazások A tudományos illetve műszaki számításokat végző alkalmazások jellegzetes csoportja. Az architektúrát a megvalósítandó algoritmusok döntően befolyásolják. A rendszer leírása szempontjából az aktivitás- illetve az állapotdiagramok döntő jelentőségűek. Ilyen alkalmazások meglehetősen ritkán fordulnak elő a napi fejlesztői gyakorlatban. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 14

Rétegzett architektúra Az alkalmazást rétegekkel és a réteg által biztosított interfészekkel modellezik. Az egyes rétegeknek jellegzetesen különböző feladatkörük van, mint például felhasználói felület, vezérlés, adattárolás. Az elvileg ideális esetben minden egyes réteg csak és kizárólag a vele szomszédos rétegekkel tart kapcsolatot. A rétegzett architektúrának jellegzetes példája a hálózati protokollok OSI referenciamodellje, avagy az elterjedt háromrétegű modell, ami kezelői felületet, alkalmazáslogikát és adatkezelési logikát definiál. Az alkalmazások rétegzett felépítésével a szoftver összetevőiről szóló fejezetben már részletesebben foglalkoztunk. Példa speciális architektúrájú alkalmazásra: a kliens-szerver architektúra Hálózati együttműködést lehetővé tevő megoldásminta, melynek legfontosabb elemei: 14. ábra Kliens-szerver architektúra Független szerverek halmaza A szerverek a rendszer többi eleme számára valamilyen szolgáltatást nyújtanak, mint például az állományszerverek, amik állományok osztott elérését biztosítják, adatbázis, nyomtató- vagy videoszerverek, amik szintén speciális szolgáltatásokat ajánlanak fel. Kliensek halmaza A kliensek hozzáférhetnek a szerverek által biztosított szolgáltatásokhoz. A kliensek jellemzően önálló létjogosultsággal rendelkező alrendszereket valósítanak meg. Ismerik és használják a szervereket és a szerverek által megvalósított szolgáltatásokat. A kliensalkalmazásból jellemzően számos példány futhat egyidejűleg. Hálózat Biztosítja a kliensek és szerverek közötti kommunikációt. Elvileg elhagyható elem, amennyiben fizikailag ugyanazon a gépen fut mind a szerver-, mind a kliensalkalmazás. A kliens-szerver architektúra legfőbb előnye az osztott architektúrája. Hatékony sok egymástól független feldolgozás esetében. Meglehetősen széles határok között könnyen bővíthető, mind újabb kliensek, mind újabb szerverek viszonylag könnyen csatlakoztathatóak a rendszerhez. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 15

Példa a vezérlési architektúrára: az eseményszórásos modell A vezérlési architektúrák az alkalmazás dinamikus viselkedését, a vezérlési folyamatot írják le. Az eseményvezérelt alkalmazások (pl. maga a Windows és a Windowsalkalmazások) elterjedt megvalósítása az eseményszórásos modell. 15. ábra Eseményszórásos modell összetevői Az eseményszórásos modellben megkülönböztetünk eseményforrást, eseményobjektumot és eseménykezelőt, avagy -nyelőt. Az esemény- illetve üzenetkezelő alrendszer a keletkezett eseményobjektumot elvileg minden alrendszer számára eljuttatja, s az alrendszer az eseményobjektum, illetve a saját állapota alapján eldönti, kíván-e reagálni az eseményre. Hatékonysági megfontolásokból általában a potenciális kezelőobjektumnak be kell jelentenie az érdeklődést bizonyos helyen keletkezett, avagy bizonyos típusú eseményekre, s ebben az esetben a keletkező eseményobjektumok csak az őt hallgató, figyelő objektumokhoz jutnak el. A hallgató objektum eldöntheti, reagál-e az eseményre, s ha igen, akkor hogyan. Iteratív és inkrementális jelleg A módszertan által preferált és a korábban bemutatott fejlesztési folyamat fázisiterációk-mérföldkövek felépítése előírja ezt a fajta megközelítést. Miért van szükség iteratív fejlesztésre? Egyszerű, kicsiny rendszerek esetében alkalmazható a feladat definiálása, tervezés, kódolás, tesztelés szekvenciális, vízesésszerű fejlesztési mód. Nagyobb, bonyolultabb rendszerek esetében más módszert kell keresni. A megrendelői, felhasználói igények is folyamatosan változnak. A hagyományos vízesés modell alkalmazásakor számos hiányosság, félreértés, hiba csak a fejlesztés végén, a tesztelési fázisban bukik elő. Ugyanakkor ez a modell nagyon nehezen viseli el a fejlesztési célok menet közbeni megváltozását. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 16

16. ábra A kockázat mértékének alakulása a fejlesztés ideje alatt Az iteratív fejlesztés tolerálja a követelmények megváltozását A határidő illetve a költségek túllépése általában a megváltozott követelményekből adódik. A fejlesztés időtartama alatt viszont a követelmények törvényszerűen megváltoznak, mivel a rendszer környezete, a szabályok és az előírások, a technológia is változik, a felhasználók folyamatosan ismerik meg a rendszer szolgáltatásait. A fejlesztési iterációk eredményeként létrejövő újabb és újabb szoftververziókat a megrendelő rendszeresen megkapja, így szoros a kapcsolat a megrendelői és a fejlesztői csapat között. A megváltozott követelményeket viszonylag hamar be lehet építeni a rendszerbe. Az iteratív fejlesztés viszonylag jól tolerálja a taktikai jellegű változtatásokat. Elképzelhető, hogy az üzleti viszonyok változása miatt hamarabb kell piacra dobni a terméket az iteratív fejlesztés esetén az egyes iterációk végeredménye kibocsátható termék. Az iteratív fejlesztés csökkenti a kockázatot Az egyes iterációk által előállított termékeket a megrendelő megkapja, teszteli, így a követelmények megváltozására, az esetlegesen pontatlanul, avagy hiányosan rögzített követelményekre viszonylag hamar fény derül, s ezzel jelentősen csökkenti az üzleti jellegű kockázatokat. A műszaki jellegű kockázatok jelentős része a késői integrációból adódik. A klasszikus, vízesésszerű fejlesztés esetében az egyes részrendszerek integrációja a fejlesztés végén, egyetlen nagy összeépítési kampányban (big bang) történik meg. A hibák és a kockázatok jelentős részére az integrációkor derül fény. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 17

17. ábra A rendszer megfelelése a végső követelményeknek a fejlesztés ideje alatt Iteratív fejlesztés esetén folyamatos az integráció. A folyamatos integráció révén az egyes kockázati elemekre hamar fény derül, az esetlegesen hézagosan illeszkedő elemek javítására több idő van. Az iteratív fejlesztés biztonságosabb, hibatűrőbb alkalmazást eredményez Iteratív fejlesztésnél a rendszer tesztelése az integrációval együtt, már a fejlesztés korai szakaszában elkezdődik. A sokszori tesztelésnek köszönhetően valószínűbb, hogy még a fejlesztés időszaka alatt felszínre kerülnek az esetleges rejtett hibák, illetve a kritikus kódrészleteknek van idejük megérni. Az iteratív fejlesztés lehetővé teszi a résztvevők folyamatos tanulását, a módszertan finomítását Az iteratív fejlesztési folyamat során több lehetőségük van a fejlesztésben résztvevő személyeknek, hogy a módszertant és a fejlesztési technológiákat elsajátítsák, gyakorolják. Az iterativitás, az inkrementális növekedés miatt ez esetleges hibáknak, emberi tévedéseknek kisebb a kockázata: a rendszeres tesztelés az esetleges tökéletlen megoldásokat fel fogja deríteni. A fejlesztői csapat személyi összetétele egy hosszabb fejlesztés során meg szokott változni. Iteratív fejlesztés során az új tagoknak lehetőségük van a módszertan, a belső szabványok, szokások, konvenciók elsajátítására. Az egyes iterációk végén az áttekintés nemcsak a fejlesztés eredményét, a terméket vizsgálja, hanem magát a fejlesztési folyamat, a fejlesztői csapatban is javasolhat változtatásokat. Az iteratív fejlesztés lerövidíti a fejlesztés időtartamát Az iteratív fejlesztés növeli a fejlesztés hatékonyságát, lerövidíti a fejlesztés időtartamát, mert az egymást követő munkafolyamatok hamarabb elkezdhetők. Az implementációnak meg kell várnia a tervezés befejezését, a tesztelésnek meg kell várnia az implementációt, a kézikönyvek és oktatóanyagok írásával meg kell várni a végleges, kijavított verziót stb. Az iteratív fejlesztés a teljes fejlesztést sok mini projektre bontja fel, s ezek a mini projektek egymástól többé-kevésbé függetlenül fejleszthetők. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 18

Az egyes szakterületek, munkafolyamatok technológiafüggése megmarad, azonban több, részben párhuzamos mini projekt esetében az egyes szakterületek egymásra való várakozása jelentősen csökkenhet. Az iteratív fejlesztés révén könnyebb felismerni az újrafelhasználható szoftverkomponenseket is. Az iteratív fejlesztés tervszerű Vannak, akik az iteratív és inkrementális fejlesztést az ötletszerű, kapkodó, fejetlen munka tudományos megfogalmazásának vélik, s mint ilyen ellen berzenkednek. Ezzel szemben a RUP iterációi tervezettek és szigorúan ellenőrzöttek. Az iterációk számát és időtartamát, az egyes iterációk feladatát és az általuk előállított termékeket, az iterációs munkafolyamatok résztvevőit előre tervezi a RUP. Összefoglalás A RUP módszertan létrehozásának célja az volt, hogy kiküszöbölje a fejlesztési folyamatban felmerülő, a projekt sikerét megakadályozó problémákat. A fejlesztési projektek sikerességét három tényező alapján mérjük: 1. költségkeret betartása, 2. határidő betartása, 3. a követelményeknek való megfelelés. A három tényező nyilvánvalóan összefüggésben áll egymással (pl. határidőcsúszás következményeként felléphet költségtúllépés; a követelményváltozások miatti újratervezés/újrakódolás szintén költségemelkedéssel és valószínűleg határidőcsúszással jár; a határidők betartásának céljából végrehajtott pótlólagos erőforrásbevonás úgyszintén növeli a költségeket stb.) A 80-as és 90-es évek kutatásai a problémák okaként elsősorban nem technológiai, hanem módszertani hiányosságokat jelöltek meg, ezen belül is elsősorban a fejlesztés ideje alatt bekövetkező változások követésének, illetve az együttműködéskommunikáció problémáira világítottak rá. A RUP ezekre a problémákra a fejlesztési folyamat és a folyamat során elvégzendő tevékenységek, a tevékenységek egymásra épülésének, egymásutániságának, ugyanakkor a változások követésének definiálásával, megoldásával és előírásával próbál válaszolni. A módszertan elméleti módszertan, ami azt jelenti, hogy ajánlásait, mintáit és módszereit a különböző típusú fejlesztési feladatok esetében mindig át kell vizsgálni, és a helyzetnek megfelelően kell azokat alkalmazni. További információk: www.rational.com Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 19