Programming | Programming theory » Benedek Zoltán - Szoftverfejlesztés alapok

Előzetes verzió: 2002-05-16 Szoftverfejlesztés alapok Szoftvertechnika segédlet BME Automatizálási és Alkalmazott Informatikai Tanszék Tanszéki használatra Készítette: Benedek Zoltán 2002. május Szoftverfejlesztés alapok Előzetes verzió Tartalom A jegyzet célja, hogy megismertesse az olvasót a szoftverfejlesztés alapproblémáival, betekintést adjon az objektum orientált alapú szoftverfejlesztési módszertanok és modellező nyelvek (UML) világába. 1. A szoftverfejlesztés feladata .3 1.1 Bevezetés .3 A rendszerfejlesztés (system engineering) és a szoftverfejlesztés (software engineerig) kapcsolata.3 1.2 Alapproblémák3 Szoftver krízis .3 Modellezés .4 Komplexitás kezelése .5 Formalizálás szerepe.5 1.3 A szoftverfejlesztés „kellékei”.6 A sikerháromszög .6 UML, mint jelölésrendszer .6 Fejlesztési folyamatok .7 Fejlesztő és modellező eszközök .9 1.4 Életciklus „modellek” .9 Bevezető.9 Vízesés modell.10 Prototípus

használata .11 Spirális modell .12 Iteratív és inkrementális fejlesztési modellek.13 1.5 Szoftverfejlesztési folyamatok áttekintése.14 Analízis .14 Tervezés (design).14 Implementáció (construction) .14 Tesztelés*.14 Telepítés/karbantartás* .15 2. Egy egyszerűsített Unified Process alapú fejlesztési folyamat16 A RUP fontosabb jellemzői .16 2.1 Üzleti folyamatok modellezése.21 2.2 Követelmények meghatározása (Requirements) .21 2.3 Analízis (elemzés) és tervezés .31 Statikus nézet .33 2 Szoftverfejlesztés alapok Előzetes verzió 1. A szoftverfejlesztés feladata 1.1 Bevezetés A szoftverfejlesztés során fejlesztésről van szó: a cél vagy egy új termék létrehozása vagy egy meglevő módosítása. A fejlesztendő termék feladata általában információ feldolgozás, vagyis az információnak tárolása, valamint az információnak egyik megjelenési formájából (reprezentációjából) egy olyan formába történő alakítása, ami

számunkra valamilyen szempontból értékesebb. A rendszerfejlesztés (System Engineering) és a szoftverfejlesztés (Software Engineerig) kapcsolata Egy adott problémára végtelen sok megoldás létezik, az egyes megoldásokban a részfeladatok más és más felosztásban oldják meg a következő szereplők: i. Szoftver ii. Hardver iii. Humán Tekintsük például a vásárlás üzleti folyamatát. A vásárló számára a számla kiállítása történhet kézzel, de használhatunk egy számla kiállítására és nyomtatására alkalmas számítógépes ügyviteli alkalmazást is. Míg az első eset a humán megoldás képviseli, a második esetben a feladatot egy megfelelő hardver-szoftver együttes végzi el. Egy másik példa a tételek számlára történő bevitele a számítógépes megvalósítás esetében: az egyes tételeket felveheti a bolti alkalmazott az egyes tételek vonalkódjának begépelésével (humán), vagy a felvitel történhet egy vonalkód olvasó

használatával (hardver eszköz). A rendszerfejlesztés feladata a rendszernek, mint egészének a megtervezése és elkészítése. A rendszerfejlesztés során mindig eljutunk arra a pontra, amikor a részfeladatokat a kívánt erőforrásokhoz (HW, SW, humán) rendeljük. A szoftverfejlesztés feladata ezen belül a szoftverre allokált részek megtervezése és elkészítése. Manapság nem mindig szokták a fejlesztés ilyen jellegű különválasztását hangsúlyozni abban az esetben, amikor a feladat szoftver centrikus, vagyis a feladat elvégzésében a szoftver részek a hangsúlyosak. Ebben az esetben gyakran csak szoftverfejlesztésről beszélünk, amibe beleértjük a rendszerfejlesztéshez kapcsolódó fejlesztési lépéseket, feladatokat is. A jegyzet a továbbiakban a szoftverfejlesztés témakörével foglalkozik 1.2 Alapproblémák Szoftver krízis A programozás hőskorában a ’60-as évek közepén az embernek a gép nyelvén kellett gondolkodni és

megfogalmazni az adott problémát. A `60-as évek végén felfigyeltek arra, hogy a szoftverfejlesztők az esetek többségében minden előzetes idő és költségkeretet túlléptek, ezen felül a projektek 75%-a teljes kudarccal végződött, mert olyan rossz minőségű volt az elkészült szoftver termék, hogy a minimális használhatósági szintet sem ütötte meg. Ennek alapvető okát a 3 Szoftverfejlesztés alapok Előzetes verzió fejlesztés módszerességének és szervezésének hiányosságaiban találták meg. Ez a felismerés vezettett a - szoftverfejlesztési módszertanok (software development process) - munkaszervezési módszerek (management process) - programozási nyelvek - fejlesztő eszközök (ma már integrált fejlesztő környezetek) - CASE eszközök (Computer Aided Software Engineering) - egyéb, pl. komponens alapú szoftver technológiák (COM, CORBA) kialakulásához, a mai napig tartó, egyre gyorsuló ütemű evolúciójához. Modellezés A

modellezés során magunkban a való világról egy gondolati képet alakítunk ki. Ez a kialakult képet nevezzük modellnek. A modellezés során a számunkra, a cél elérése szempontjából fontos részekre koncentrálunk, a lényegtelen részeket elhagyjuk, vagyis használjuk az absztrakció eszközét. Természetesen ugyanannak a valóságos dolognak több különböző modellje lehet attól függően, hogy az adott dolgot milyen absztrakciós szinten modellezzük. Ezen túlmenően a modell függ a szemlélő személyétől is. Ez abból következik, hogy a modell gondolati termék, ebből következően magában hordozza az elkészítőjének személyiségét, a valóság modellezett részének benne kialakult sajátos képét. Az szoftverfejlesztés során bonyolult, komplex rendszerekkel foglalkozunk. A modell kialakítása során könnyű olyan modelleket kell kialakítani, amelyek áttekinthetetlenek, kezelhetetlenek és nehéz megérteni őket. A fejlesztési módszertanok

feladata részben az, hogy utat mutassanak számunkra ahhoz, hogy modelljeink átláthatóak, kezelhetők maradjanak. Felmerülhet bennünk a kérdés, hogy a milyen részletességgel kell modelljeinket elkészíteni. A válasz: olyan részletességgel, hogy a modell a számunkra/a probléma szempontjából minden lényeges vonásában tükrözze a valóságot. A fejlesztés egy „valamire is való” rendszer esetében a ma már kizárólag csapatmunkában történik. Ehhez elengedhetetlen a csapat tagjai közötti megfelelő információcsere biztosítása. Ennek megfelelően a követelményeket és az egységes kép kialakítása érdekében a modelleket is dokumentálni kell. Szintén kulcsfontosságú, hogy a modell leírása kellőképpen egyértelmű legyen ahhoz, hogy mindenki számára ugyanazt jelentse, vagyis hogy a fejlesztésben résztvevők mindegyikében (a megrendelőt is beleértve) a feladatról ugyanaz a kép alakuljon ki. Ennek megfelelően a modelleket

kellőképpen formális módon kell leírni. A modell kellően precíz leírásával elérhetjük azt is, hogy a modellben levő ellentmondások a felszínre kerüljenek. A modellezéssel kapcsolatos problémákat a következőképpen foglalhatjuk össze: 1. Megoldást kell találni a bonyolultság kezelésére, vagyis hogy az elkészült modellek átláthatóak, kezelhetők maradjanak 2. Biztosítanunk kell a modellnek leírásának egyértelműségét, az ellentmondások ellenőrizhetőségét. A következő két fejezet ez a két gondolatot fejti ki részletesebben. 4 Szoftverfejlesztés alapok Előzetes verzió Komplexitás kezelése A szoftverrendszerek alapjában véve komplexek, mivel bonyolult feladatot kell megoldaniuk A komplexitás számunkra abban jelenik meg, hogy nem tudjuk a teljes problémát egyszerre teljes szélességében és mélységében átlátni, fejben tartani. A komplexitáson természetesen valamilyen módon uralkodni kell, melyhez két alapvető

eszköz áll rendelkezésünkre: az absztrakció és a dekompozíció. Absztrakció Az absztrakció során a dolgok számunkra, valamint a probléma szempontjából fontos részeit kiemeljük, a többi kevésbé fontos “zavaró” részektől pedig eltekintünk. A valóságot különböző absztrakciós szinten modellezhetjük a részletezés aprólékosságától függően. Ez természetesen gondolati síkon történik. Dekompozíció A dekompozíció során a rendszert olyan egyszerűbb részekre bontjuk, ahol a részrendszerek együttműködve az eredeti rendszernek megfelelő viselkedést mutatnak. A dekompozíció során meghatározzuk a részrendszereket és ezek együttműködésének módját, a részrendszereket pedig egymástól függetlenül fejlesztjük tovább. A dekompozíció során tulajdonképpen a jól bevált oszd meg és uralkodj elvet követjük. Az absztrakciót és a dekompozíciót általában együtt használjuk. Amikor egy problémát a részleteiben

mélyebben (vagyis alacsonyabb absztrakciós szinten) nézünk, akkor van szükség a feltáruló részek együttműködő részrendszerekre bontására (dekompozícióra), különben a feltáruló részletek áttekinthetetlenné válnának. Formalizálás szerepe A modell gondolati kép, amely egy adott absztrakciós szinten, adott nézetből ábrázolja a rendszert. Egy modellt nagyon sok módon le lehet írni: köznyelvi szöveges megfogalmazással, grafikusan, stb. Fontos, hogy a modellt olyan módon tudjuk leírni, amelyet mindenki ugyanúgy értelmez. Érezzük, hogy enélkül – különösen ha többen dolgozunk egy feladaton – a modellezés nem sokat ér. Ahhoz, hogy a modellt kellő egyértelműséggel tudjuk leírni, a leírást amennyire lehet, formalizálni kell. Ez azt jelenti, hogy formai és tartalmi szabályokat vezetünk be, amelyeket szigorúan betartunk. A köznapi nyelvű szöveges leírás önmagában sajnos sokszor nem tekinthető eléggé formálisnak

(egyértelműnek). Ennek kikerülésére sokszor grafikus reprezentációt használnak (pl más műszaki tudományokban az építészeti, vagy villamos kapcsolási rajz). A legalacsonyabb absztrakciós szinten elhelyezkedő implementációs modell, vagyis a forráskód teljesen formális, ennek szabályait az adott programozási nyelv szabályrendszere határozza meg. Magasabb absztrakciós szinten sajnos ilyen szintű formalizálás ma még nem lehetséges. Ha lehetséges volna, akkor a mai modellező eszközök a modellből képesek lennének a teljes forráskód legenerálására (lehetséges volna ún. futtatható modellek elkészítése, de erre megoldások még csak bizonyos beágyazott rendszerek esetében léteznek). A mai modellező eszközök általában arra képesek, hogy az UML nyelven megadott implementációs modellből egy adott objektum orientált programozási nyelven kódvázat generáljanak, ami pl. C++ nyelv esetében az osztályok vázának legenerálását

jelenti (osztály definíció és metódus fejlécek, de a metódusok törzsét nem tölti ki). 5 Szoftverfejlesztés alapok 1.3 Előzetes verzió A szoftverfejlesztés „kellékei” A sikerháromszög Némiképpen leegyszerűsítve a sikeres szoftver fejlesztésnek három alapvető eleme van, ezt egy ún. „sikerháromszög” segítségével lehet ábrázolni: Eszköz Modellező nyelv Fejlesztési folyamat A három kritérium a háromszög három csúcsán helyezkedik el: modellező nyelv, fejlesztési folyamat, fejlesztő és modellező eszközök. Nézzük ezeket most sorban UML, mint jelölésrendszer Mint már volt róla szó a fejlesztés általában csapatmunkában történik, ennek megfelelően fontos a modellek dokumentálása. Ehhez szükségszerűen a modelleket a gondolati síkból egy mindenki számara megfogható formába kell hozni (következik mindez abból, hogy a gondolatolvasás ma még nem megvalósítható alternatívája az információ

átvitelnek). Ennek megfelelően szükség van olyan modellező nyelvre, amely lehetővé teszi a modellek leírását olyan formában, amely mindenki számára érthető. Egy ilyen, szabványos modellező nyelv az UML (Unified Modeling Language), amelyet ma már minden magára valamit is adó szoftvercég a modelljeinek dokumentálására használ. Megjegyzés Az UML nem fejlesztési folyamat, ennek megfelelően nem mondja meg, hogy hogyan kell a szoftvert kifejleszteni. Az UML modell leíró nyelv, egy jelölésrendszer, amely modell elemeket definiál és meghatározza az egyes modell elemekhez szemantikai tartalmát és szintaktikáját. Az UML, mint modell leíró nyelv szerepe  Lehetővé teszi a modellek dokumentálását - később is emlékezni fogunk - segíti a csapat tagjai közötti kommunikációt  Vizuális, grafikus nyelv, ezáltal nagymértékben segíti a probléma megértését - szemléletes - kifejező  Szabvány - lehetővé teszi a cégek közötti

kommunikációt 6 Szoftverfejlesztés alapok Előzetes verzió  Kellően flexibilis és könnyen kiterjeszthető ahhoz, hogy valamennyi szoftverfejlesztéssel foglalkozó cég illeszteni tudja a maga fejlesztési folyamatához  Kellően formális ahhoz, hogy - A fejlesztők számára megfelelő pontossággal bírjon - A modellező eszközök számára is kellőképpen megfogható és kezelhető Fejlesztési folyamatok Két nagyobb csoportra osztható a „módszer”: Development Process (fejlesztés módszere) ÉS Management Process (fejlesztés szervezése) A fejlesztési folyamatok szerepe:  A meghatározza a következőket: - Milyen lépéseken át juthatunk el a kész szoftver termékig (választ ad a „na most mit csináljak?” kérdésre) - Az egyes lépésekben milyen “termékeknek” kell elkészülnie. A termék itt általános értelemben szerepel, így termékek a következők:  Dokumentum  Modell (illetve modell elemek)  Szoftver - Milyen

szerepkörök (analizátor, architektúra tervező, programozó, projekt menedzser, stb.) vannak, mi az egyes szerepkörök feladata, milyen tevékenységeket kell elvégezniük. Pl  Útmutatók, guideline-ok (pl. hogy az egyes tevékenységeket hogyan kell elvégezni) Természetesen az intuíció, a kreativitás szerepe megmarad, hiszen pl. a szoftvertervező számára nem tud lépésről lépésre megoldást adni (pl. hogy egy adott problémát milyen osztályokkal célszerű modellezni). Itt nagy szerepet játszik  tapasztalat  mások tapasztalata (lásd analízis és tervezési minták) Amiben itt is segít: útmutatók, jótanácsok. Egy jó fejlesztési folyamat kritériumai A következőkre keressük a választ: Mikor tekinthetünk egy elkészült szoftver terméket sikeresnek? Milyen elvárásaink vannak egy fejlesztési folyamattal szemben? A fontosabb kritériumok: 1. Az elkészült termék (minimálisan) kielégíti a megrendelő igényeit Sajnos gyakran csak a

szállításkor derül ki, hogy ami elkészült, meg amire a megrendelő gondolt csak „távcsövön át nézve” van közel egymáshoz. Ennek két oka lehetséges: a. A követelmények nem megfelelő kezelése i. Nem sikerült megérteni a megrendelő igényeit: ugyanazt mondtuk, de másra gondoltunk. 7 Szoftverfejlesztés alapok Előzetes verzió ii. A megrendelő sem tudta pontosan megfogalmazni, hogy mik a követelmények, amit pedig kitaláltunk nem sikerült a megbeszélések során vagy a specifikáció által a megrendelővel kellő mélységben megértetni. b. Nem a követelményeknek megfelelő szoftver készül el Validáció 2. Megismételhető Ehhez többek között az szükséges, hogy kellőképpen szabályozott legyen. 3. Képes a folyamatosan változó követelményeket kezelni a. A felhasználók általában maguk sem tudják meghatározni pontosan, hogy mit szeretnének. Pl kaphatunk ilyen feladatot a megrendelőtől: „Alkatrész forgalmazással

foglalkozom, szeretnék egy olyan számítógépes rendszert, amivel gyorsabban, hatékonyabban, kisebb költséggel tudok termelni”. Egy ilyen esetben a mi feladatunk a megrendelővel való konzultációk során a pontos követelmények meghatározása. b. A szoftver „szoft”, „puha” termék, elvileg könnyű rajta változtatni: a megrendelő elvárja, hogy képesek legyünk a kért változtatásokat véghezvinni. 4. Képes a követelményekben, a tervekben és az implementációban fellépő inkonzisztenciák minél korábbi detektálására. Egy adott hiba kijavításának költsége az idő előrehaladtával hatványozottan nő. Egy rosszul megfogalmazott követelményt kijavítása a következőket vonhatja maga után akkor, ha a hibára csak a fejlesztés végén jövünk rá: követelmény specifikáció módosítása, az architektúra áttervezése, valamennyi érintett komponens áttervezése, az implementáció módosítása. költség idő 5. Képes a kockázatok

megfelelő kezelésére (risk management) 6. Folyamatos rálátást biztosít a fejlesztés státuszára, elkészültségi fokára vonatkozóan a megrendelőnek és a menedzsmentnek 7. Korrekt, nem feltétlenül minimális, de mindenképpen megjósolható költség és időkorlátokat biztosít. 8. Egyéb a. Ne zsenikre, hanem átlagosan jól képzett emberekre legyen szükség b. Lehetővé teszi az egyes tevékenységek átlapolását, valamint az egyes részrendszerek párhuzamos fejlesztését. c. Az architektúra tervezési, tervezési, implementációs és egyéb technológiai kényszerek tudjanak visszahatni a követelményekkel kapcsolatos döntésekre, tudják azokat súlyozni. Pl Adott egy részfeladat, ami megoldható A és B módon Tegyük fel, hogy a megrendelő számára gyakorlatilag mindegy, hogy melyik utat választjuk, viszont az A megoldást 3-szor annyi ideig tart “lekódolni” vagyis implementálni, mint a B-t. Ebben az esetben természetesen a B megoldást 8

Szoftverfejlesztés alapok Előzetes verzió választjuk. Ezt a fajta elvárást nagyon nehéz teljesíteni, legtöbbször a fejlesztők (analizátorok) tapasztalatán, alapulnak ezek a döntések, és az egyes szerepkörök közötti kommunikáció is kulcsfontosságú (az analizátor konzultál az architektúra tervezővel vagy a programozóval) + “mindenki jelen van” típusú megbeszélések. Hogyan tudjuk ezt elérni (RUP best practices, lásd később): 1. Iteratívan fejlesszünk 2. Menedzseljük a követelményeket 3. Használjunk komponens alapú szoftver architektúrát 4. Modellezzünk, mégpedig vizuálisan 5. Folyamatosan ellenőrizzük a szoftver minőségét 6. Biztosítsuk a változtatások szabályozott kezelését Személyes jótanácsok: + A fejlesztés során végig törekedjünk a következőkre - átláthatóság - újrafelhasználhatóság - módosíthatóság (kiterjeszthetőség) + Mindig törekedjünk az egyszerűségre, különösen a felhasználói

megtervezésénél. A mindentudó, de nehezen kezelhető alkalmazások kora lejárt! felület Fejlesztő és modellező eszközök Miben segítenek ma ezek az eszközök? Változó követelmények menedzselése. Modellek kezelése: - analízis és tervezési modellek elkészítése UML nyelven - reverse engineering: kódból modell - forward engineering: modellből kód - round-trip engineering: az előző kettő együtt. Előnye, hogy mindig konzisztens marad a model és a kód (ha módosítjuk a kódot, a modellt is módosítani kell: enélkül a részletes terv modell nem sokat ér, hiszen félrevezető!) 1.4 Életciklus „modellek” Bevezető Életciklus fogalma: az igény felmerülésétől a termék forgalomból való kivonásáig tart. A fejlesztési rész a hangsúlyos, mi is erre koncentrálunk. Egy szoftver termék életében általában több fejlesztési fázis követi egymást: az első működő példány kifejlesztését általában több módosítási, illetve

továbbfejlesztési fázis követi, melyek mindegyike egy-egy önálló fejlesztésnek tekinthető. Egy ilyen fejlesztési folyamat során a – első közelítésben - következő tevékenységekre van szükség: 9 Szoftverfejlesztés alapok Előzetes verzió 1. Analízis Funkcionális és egyéb követelmények meghatározása Azt határozzuk meg, hogy MIT kell a rendszernek tudnia. 2. Tervezés Azt határozzuk meg, hogy HOGYAN fogja rendszer a követelményeit megvalósítani. Egy megoldást keresünk Architektúrális és részletes terv 3. Implementáció, a megtervezett rendszer elkészítése 4. (Integrálás) 5. Tesztelés 6. Átadás/karbantartás Bár ezek a tevékenységek többé-kevésbé a fenti sorrendben követik egymást, időben átlapolódhatnak, többször meg is ismétlődhetnek. A fejlesztés egyes tevékenységeinek és szakaszainak időbeli szervezése szempontjából különböző életciklus modelleket különböztetünk meg. Az életciklus modell olyan

modell, amely meghatározza, hogy a szoftverfejlesztés lépései milyen sorrendben követhetik egymást, az első ötlettől a végleges, átadott verzióig. Minden életciklus modellnek vannak előnyei és hátrányai. Ennek megfelelően nem létezik ideális életciklus modell, mindig a helyzetnek legmegfelelőbbet kell választani. Valamilyen módon el kell dönteni a fejlesztés során, hogy mikor mondhatjuk azt, hogy egy adott fázis végére értünk. Ennek eldönthetőségére az ajánlások ún mérföldköveket (milestone) vezetnek be. Minden mérföldkő elérését konkrét dokumentumok elkészüléséhez, illetve értékelő megbeszélések (review) megtartásához szokták kötni. Tekintsük át a legelterjedtebb életciklus modelleket. Vízesés modell Jellemzők - Szigorú sorrend a lépések között - Addig marad egy fázisban, amíg kész nincs a következőre - a fázisok nem fedik át egymást 10 Szoftverfejlesztés alapok - Előzetes verzió

Dokumentum-központú Hátrányok: - Nehezen kezeli a változó követelményeket (a vízesésen nehéz visszafelé haladni) - Nem tolerálja a hibás döntéseket: a tesztelésnél észrevett specifikációs/tervezési hiba nagyon drága lehet - A felhasználó csak a fejlesztés végén szembesül az eredménnyel - Nagy dokumentációs overhead - Nincs átfedés a szakaszok között Akkor működik jól, dolgozunk. ha nem változnak a követelmények és kipróbált technológiákkal Prototípus használata Prototípus: a rendszer problémás vagy kérdéses részeinek elkészítése, elsődlegesen a követelmények pontos megértése érdekében. Gyakran a megrendelő nem tudja pontosan meghatározni az elvárásait: ebben segít. Tipikusan a felhasználói felületre szoktak prototípust készíteni: a felhasználó így egyből látja, milyen funkciókat és azokat milyen lépésekben nyújt a program. Két fajtája létezik: A, Eldobható: a prototípust csak a követelmények

jobb megértése végett készítjük el (minél gyorsabban), majd eldobjuk, vagyis nem kerül felhasználásra a végleges termékben B, Evolúciós: a prototípust Initial concept Design and implement prototype Refine prototype until acceptable Complete and release prototype Nézzük most az evolúciós prototípust részletesebben. Folyamatos finomítás, melynek lépései: 1. Kezdeti koncepció kialakítása 2. Prototípus megtervezése és implementálása 3. Az elkészült prototípus kiértékeltetése a megrendelővel 4. A prototípus finomítása, amíg el nem fogadható 5. Prototípus release 6. (Tervezés, implementáció, teszt, ) Jellemzők - Fejlesztés közben a rendszerterv is a prototípussal együtt változik 11 Szoftverfejlesztés alapok Előzetes verzió - Szoros együttműködés a megrendelővel: a rendszer kész, ha ‘elég jó’ - Előnyök o követelmények jobb megértése o látványos haladás o követelmények, architektúra változására

kevésbe érzékeny - Hátrányok o nincs stabil határidő a projekt végére o a prototípust gyorsan összedobjuk, rossz minőségű kód marad a végleges verzióban Spirális modell Tervezés kezdeti követelmények Kockázatelemzés kezdeti követelmények kockázatának elemzése követelmények módosítása Tovább/megáll kezdeti proto kiértékelése a felhasználóval Kiértékelés következô proto átadott változat Gyártás Jellemzők: Kockázat-orientált, iteratív életciklus modell  A projektek ‘mini-projektek’ sorozatára bontjuk  Minden mini-projekt - egy-egy kockázati tényezőt old meg - vízesésként viselkedik, lépései:  követelmények, célok meghatározása; alternatívák, feltételek felállítása  kockázati tényezők meghatározása; alternatívák kiértékelése  termék elkészítése a következő iterációhoz  a termék kiértékelése  következő iteráció tervezése, lehetőségek, döntés a

következő iteráció mibenlétéről  A kezdeti iterációk olcsóbbak, érdemes a legnagyobb kockázati tényezőket a projekt elején elintézni  Fontos az életciklus modell testreszabása: - hány iteráció van - egy iteráción belül milyen lépéseket hajunk végre - mennyire vonjuk be a megrendelőt  Egyetlen nagy hátránya a bonyolultsága - komoly projekt menedzsment szükséges Itt is használunk prototípusokat, de itt a fejlesztés egészére vonatkozólag. 12 Szoftverfejlesztés alapok Előzetes verzió Iteratív és inkrementális fejlesztési modellek A szoftver egymást követő, egyre pontosabb változatait állítja elő. Megjegyzés: a spirális modell is ilyen volt. Jellemzők:  A teljes fejlesztést iterációkra bontjuk  Iteratív és inkrementális: az iterációk során nő a program  Kisebb „működő” részek: minden egyes iteráció egy futtatható release-zel végződik Minden iterációhoz eldöntjük, hogy az összes

megvalósítandó funkciókból melyeket vesszük bele: Előnyei:  Működésorientált: egy működő programot könnyebb bővíteni, mint egy nem működő sok funkciójú programot működővé tenni.  Lehetővé teszi, hogy a rendszer problematikus részeit fejlesszük ki először.  Tévedés esetén gyorsan fel lehet fedezni a zsákutcát. 13 Szoftverfejlesztés alapok Előzetes verzió  Jó rálátást biztosít a fejlesztés előrehaladására vonatkozólag.  Az egyes szerepkörök párhuzamosan dolgozhatnak: pl. amíg az első iteráció release-ét tesztelik, addig már folyamatban lehet a következő iteráció tervezése és implementációja  A megrendelő korábban szembesül az eredménnyel, jobb a visszacsatolás.  A folyamatos integráció miatt kisebb integrációs problémákkal szembesülünk, mintha csak a végén próbálnánk meg „összeszerelni” a rendszert. Megjegyzés: mint látható, az iteratív fejlesztési módszerek

alkalmazásával a fejlesztési folyamattal szemben egy korábbi fejezetben felállított kritériumokból többnek is meg tudunk felelni. Ezért is fontos a pontos megértése Inkrementális Az iteratív modell egyben inkrementális is:  Növekményes: minden egyes alkalommal „hízik” a szoftver  A szoftver fejlődését az origótól való távolság adja 1.5 Szoftverfejlesztési folyamatok áttekintése A fejlesztés során szükség van analízisre és tervezésre. Eddig nem volt szó arról, hogy ez hogyan történik. Bármilyen megközelítést is választunk, a cél a komplex probléma kezelhető egységekre való bontása a cél (dekompozíció). A klasszikus strukturált analízis és tervezés során a dekompozíció elsődlegesen funkciók vagy folyamatok szerint történik, mely funkciók/folyamatok tovább bontása során alakul ki a hierarchia. Az objektum-orientált analízis és tervezés (OOAD) ezzel szemben a problémateret a valóságot jobban

közelítő objektumokra bontja, mely objektumok együttműködve valósítják meg az egyes funkciókat. Analízis Célja a követelmények meghatározása, a problématér megértése. Részleteiben lásd később Tervezés (design) Célja a követelményeknek eleget tevő rendszer megtervezése. Részleteiben lásd később Implementáció (construction) Valamely programozási nyelven elkészítjük a tervezés során megtervezett rendszer kódját, létrehozzuk a megfelelő adatbázis sémákat, stb. Tesztelés* Hagyományos értelemben az egyes modulok, majd az integrált rendszer tesztelését jelenti. Ebben Célja az elkészült szoftver termék minőségének biztosítása. Valójában ennél sokkal többre – a fejlesztés során folyamatos minőség biztosításra van szükség: - A fejlesztési folyamat valamennyi termékének (dokumentumok, modellek, szoftver) megfelelő minőségűnek kell lennie - Fontos a fejlesztési folyamat „minősége” 14

Szoftverfejlesztés alapok Előzetes verzió o mennyire szabályozott a folyamat (lásd korábban, a fejlesztési folyamattal szemben megfogalmazott követelményeinket) o mennyire sikerül magunkat tartani hozzá Hogyan tesztelünk: - Unit teszt: a forráskód valamennyi során végiglépünk (debug). - Komponens teszt: a komponens (binárisan újrafelhasználható szoftver egység) alapú technológiák egyik nagy előnye, hogy az egyes komponenseket önmagukban le lehet tesztelni. A biztosan jól működő, robosztus komponensekből felépített rendszer nagyobb valószínűséggel fog jól működni - Integrációs teszt: valamennyi funkciót, forgatókönyvet le kell tesztelni (a RUP esetében ezek a tesztek is a use-case-ek alapján történnek). Nehéz feladat, különösen konkurens, elosztott környezetekben. - A folyamatos minőségbiztosításban nagy szerepet játszanak az iteratív életciklus modellek: ezek folyamatosan kikényszerítik a termék legalább elfogadható

szinten tartását azáltal, hogy minden iteráció végén el kell készüljön a rendszer egy része (release), így lehetőség van az adott iterációban elkészült rész/inkrementum tesztelésére, illetve az addig elkészült részek integrációjára. Telepítés/karbantartás* A szoftver termék élete a telepítéssel csak a legritkább esetben ér véget. A karbantartás során derül ki mennyire sikerült jó a megrendelőt “boldoggá tevő”, illetve a későbbi változtatási és továbbfejlesztési igényeket is jól tűrő rendszert elkészíteni. Egy idő után a karbantartási költségek meghaladhatják (általában meg is haladják) a fejlesztési költségeket, emiatt is különösen fontos, hogy rendszerünk könnyen karbantartható (és konfigurálható) legyen. 15 Szoftverfejlesztés alapok Előzetes verzió 2. Egy egyszerűsített Unified Process alapú fejlesztési folyamat Mindannyian tisztában vagyunk a szabványok bevezetésének és

használatának jelentősségével. Szoftverfejlesztési sikerháromszögünk egyik csúcsán elhelyezkedő modellező nyelvvel ez sikerült is megtenni, ennek eredménye az UML. Felmerül bennünk a kérdés, hogy mi a helyzet a sikerháromszög második csúcsát elfoglaló fejlesztési folyamattal: létezik-e olyan fejlesztési folyamat, amely kellőképpen általános ahhoz, hogy a szoftverfejlesztés valamennyi területén (irodai rendszerek, üzleti alkalmazások, beágyazott rendszerek, játékok, stb.) hatékonyan alkalmazható legyen, ugyanakkor kellőképpen szabályozott, ami ezáltal egy szabvány alapját képezhetné. Természetesen voltak ilyen irányú erőfeszítések, a cél az ún Unified Process (Egységesített Fejlesztési Folyamat) létrehozása volt. Az erőfeszítéseket azonban nem koronázta teljes siker, a Unified Process, mint teljes értékű szabvány nem született meg. Megszületett azonban a Rational cég “terméke”, a Rational Unified Process

(RUP), ami egy olyan fejlesztési folyamat, ami a kitűzött céloknak leginkább megfelel, és manapság leginkább irányadónak tekinthető. Ez nem szabvány, hanem egy termék abban az értelemben, hogy a leírását meg kell vásároljuk a Rational cégtől. Ez nem olcsó mulatság, de azért ne csüggedjünk: rohamosan nő azoknak a könyvesboltokban is megvásárolható (egyelőre csak angol nyelvű) könyveknek a száma, amelyek a RUP folyamatot - különböző mélységekben - leírják. A RUP egy nagyon összetett fejlesztési folyamat, részletes tárgyalása messze meghaladja a jegyzet kereteit. A RUP részletes leírása helyett ismerkedjünk meg inkább a folyamat irányelveivel, az UML nyelv alapjaival (amely köré a RUP is épül) és az objektum orientált szoftverfejlesztés néhány fontosabb irányelvével. Megjegyzés: bizonyos irodalmak a UP kifejezést használják, ekkor is a RUP-ra kell gondoljunk A RUP fontosabb jellemzői A RUP biztosítani tudja számunkra

mindazokat a fejlesztési folyamatokkal szemben támasztott valamennyi fontosabb kritériumokat (lásd korábbi fejezet). Mindezt persze nem kapjuk ingyen A RUP egy összetett, bonyolult fejlesztési folyamat, ebből következően nehéz megérteni, jól alkalmazni és még nehezebb megfelelően testre szabni. Kisebb projekteknél egy kivonatát célszerű alkalmazni, vagy legalábbis átvenni belőle a lényegesebb elemeket (tanulni mindenképpen nagyon sokat lehet belőle). Alkalmazása általában a 3-4 projekttől kezdődően szokott megtérülni. Néhány RUP jellemző - UML köré épül - OOAD az alapja - iteratív - use-case vezérelt - architektúra központú - összetett, nagy projekteknél célszerű (viszont egészen nagy projekteket is tud kezelni) - testreszabható 16 Szoftverfejlesztés alapok Előzetes verzió A RUP szerkezete (ebből a fejezetből az ábrát nem, de a munkafolyamatokat és definíciójukat tudni kell)* A függőleges tengely mentén a

munkafolyamatokat (workflow), a vízszintes tengely mentén az időt ábrázolva (az idő fázisonként/iterációnként ferdén lefelé folyik): Minden munkafolyamatnak jól definiált célja van. Az ábra egyik fő mondanivalója: ezek a munkafolyamatok időben átfedik egymást. Egy másik fontos gondolat: feltesszük, hogy az egyes tevékenységek a fejlesztés elejétől a fejlesztés végéig tartanak (vesd össze a vízesés modellel!), de természetesen minden munkafolyamat a fejlesztés más és más fázisában hangsúlyos, mint ahogy azt az ábrán az egyes tevékenységek „domborzati viszonyai” szemléltetik. Mérnöki munkafolyamatok:  Üzleti modellezés  Követelmény-elemzés  Elemzés-tervezés  Implementáció  Tesztelés  Telepítés Támogató munkafolyamatok:  Konfiguráció és változás-kezelés  Projektvezetés  Környezet kialakítása Részletesebben: • • Üzleti modellezés (Business Modeling) • Cél megérteni annak a

szervezetnek a felépítését, folyamatait, amely támogatására az alkalmazást fejlesztjük Követelmények meghatározása (Requirements) 17 Szoftverfejlesztés alapok Előzetes verzió Cél meghatározni azokat a feladatokat, amelyeket a rendszernek meg kell oldani (scope) és a megrendelőkkel együttműködve egy egységes képet kell kialakítani a fejlesztendő rendszerről Elemzés-tervezés (Analysis & design) • Cél a követelményelemzés során meghatározott elvárásoknak megfelelő, robosztus rendszer tervezése Implementáció (Implementation) • Cél a terv alapján a rendszert alkotó komponensek implementálása, egységtesztjeinek elvégzése és integrálása Tesztelés (Test) • Cél annak ellenőrzése, hogy az implementált rendszer megfelel-e az elvárásoknak, és hogy valamennyi követelmény implementálva lett-e Telepítés (Deployment) • Cél a kész alkalmazást elérhetővé tenni a felhasználó számára Konfiguráció és

változás-kezelés • Cél a fejlesztés során előálló termékek verzióinak kezelése Projektvezetés • Cél irányelvek megadása és a projekt ellenőrzésével kapcsolatos feladatok elvégzése Környezet kialakítása • Cél a szoftverfejlesztési környezet (módszertan, eszközök) kialakításával kapcsolatos feladatok ellátása • • • • • • • • FÁZISOK* A Rational Unified Process a szoftverfejlesztés életciklusát négy egymást követő fázisra bontja: • Előkészítés (Inception) • Kidolgozás (Elaboration) • Megvalósítás (Construction) • Átadás (Transition) Az egyes fázisokban más és más munkafolyamatok a hangsúlyosak. Minden fázis végén jól-definiált mérföldkövek vannak: kritikus döntéseket kell hozni. • Értékelni az eddigi eredményeket • Dönteni a folytatásról A fázis fogalmát többek között azért vezették be: jól definiált határokat a projekt előrehaladottsági állapotára

vonatkozólag és ezt a mérföldkövek által jól követhetővé is teszi. 18 Szoftverfejlesztés alapok Előzetes verzió Iterációk • • • A RUP szerint a fejlesztés egyes fázisai tovább bonthatóak iterációkra. Az iteráció egy olyan fejlesztési ciklus, amely során minden nden alapvető munkafolyamatot (üzleti folyamatoktól modellezésétől kezdve egészen a tesztelésig) egyszer elvégzünk. Egy adott iteráció: vízesés modell szerint Ciklusok* • • • • Egy fejlesztési ciklusnak nevezzük azt az időtartamot, amíg egyszer végigmegyünk mind a négy fázison és előáll a szoftver egy (első, következő) generációja. A szoftvert az új igényeknek megfelelően folyamatosan fejleszteni, javítani kell. Ilyenkor újabb és újabb fejlesztési ciklusok következnek, amelyek szintén végigmennek a négy fejlesztési fázison és a szoftver újabb és újabb generációját állítják elő. Ezeket a fejlesztési ciklusokat evolúciós

ciklusoknak nevezzük. Az evolúciós ciklusoknál általában eltérően alakul a négy fázis aránya. RUP szemlélet* Követelmény elemzés Analízis és tervezés Tervezés Előzetes tervezés Implementáció Menedzsment Kibocsátás Értékelés Teszt  Iteratív fejlesztés  Projekt vezetés + iteratív fejlesztés komolyan vétele!!!  Spirális életciklus modell - Az elején érdemes megtervezni, hány iteráció lesz, legalább a következő fázisban 19 Szoftverfejlesztés alapok Előzetes verzió - A megrendelő jobban szereti a tervezhető költségeket - A becslés gyakran kétfázisú Use-case vezérelt folyamat* Nem egyszerű megérteni azt, hogy a RUP use-case (vagyis a megvalósítandó rendszer funkciói által) vezérelt. Ebből úgy érezzük, hogy a use-case-ek központi szerepet töltenek be a RUP esetében. Nézzünk néhány esetet, hogy mit is jelent ez Iterációk megtervezése Az iterációkat előre meg kell tervezni (legalább a

következőt). Egy adott iteráció megtervezése során elsődlegesen azt határozzuk meg, hogy az rendszer összes funkciójából az adott iteráció során mely funkcióknak és milyen szinten kell elkészülniük (az „elkészülésbe” természetesen az analízis, tervezés, implementáció, teszt lépéseket kell beleérteni). Ennek megfelelően mondhatjuk, hogy az iterációkat a funkciók, vagyis a use-case-ek vezérlik. A következő iteráció megtervezése leegyszerűsítve abból áll, hogy meghatározzuk, hogy milyen új funkciókat kell a rendszernek tudnia a következő iteráció végére. A projekt előrehaladottsági fokának megállapítása Ebben is a use-case-ek segítenek. Egyszerűen meg kell vizsgáljuk, hogy mely use-case-ek lettek már megvalósítva Tesztelés A tesztelést is a use-case-ek vezérlik. Itt arra gondoljunk, hogy use-case-enként lehet a rendszert tesztelni. Minden egyes use-case-re összeállítunk egy teszt-forgatókönyvet a use-case

forgatókönyvei alapján, és megvizsgáljuk, hogy a rendszer hibátlanul „teljesít-e” az adott forgatókönyv végigjátszása során. A következő fejezettől kezdődően tekintsük át a fontosabb RUP munkafolyamatokat. Néhány fontosabb UML fogalom Sztereotípia  Az UML nyelv kiterjesztésére ad lehetőséget,  Szintaktika: <<sztereotipia nev>>  Minden UML modell elemre lehetséges megadása, persze az már a modell elemtől függ, hogy milyen kiterjesztéseknek van értelme  Több sztereotípiát is meg lehet adni egy modell elemre, ezek nevét vesszővel kell elválasztani. Pl a művelet (operation) modell elem esetében van értelme a következőnek: - <<abstract, virtual>> Draw(): void - Itt a Draw művelet absztrakt és virtuális, ezt két sztereotípiával tudtuk megadni.  Lehetőség van arra is, hogy a sztereotípiához speciális modell elem jelölést használjunk, de ezt csak ritkán szoktuk kihasználni. 20

Szoftverfejlesztés alapok 2.1 Előzetes verzió Üzleti folyamatok modellezése Célja: megérteni annak a szervezetnek a felépítését, folyamatait, amely támogatására az alkalmazást fejlesztjük. Üzleti folyamatra példák az élet különböző területeiről: - vasúti jegy eladása - jelentkezés szoftvertechnika vizsgára - számla kiállítása a vevőnek Ezt a modellt sokszor nem kell elkészítenünk. Modellezés: - Minden üzleti folyamatot egy üzleti use-case (business use-case) reprezentál. - Egy üzleti use-case (vagyis üzleti folyamat) leírása aktivitás diagrammal történik (de szövegesen is le lehet írni a lépéseket). - Egy a munkafolyamatban résztvevő szerepkört egy üzleti aktor (business actor) reprezentál - Egy üzleti fogalmat egy entitás reprezentál Az use-case és az aktor fogalmát a következő fejezetben tisztázzuk. Az üzleti folyamatok modellezése még az elkészítendő rendszertől függetlenül történik, bár természetesen

azokat az üzleti folyamatokat próbáljuk meg megérteni, melyek melyekhez a majdan elkészítendő számítógépes rendszernek köze lesz. Az üzleti use case-ek az egész tartományt, problémateret írják le, és alapvetően semmi köze a fejlesztendő rendszerhez, attól teljesen függetlenül állítják fel ezeket. A fejlesztőknek szól, akik nem feltétlenül értik a problémateret (egy orvosi vagy egy banki rendszer esetén ez nem is várható el az orvosi vagy pénzügyi téren laikus fejlesztőktől). 2.2 Követelmények meghatározása (Requirements) Cél: meghatározni azokat a feladatokat, amelyeket a rendszernek meg kell oldani (scope) és a megrendelőkkel együttműködve egy egységes képet kell kialakítani a fejlesztendő rendszerről. Meghatározzuk, hogy MIT kell tudnia a rendszernek. A követelmény elemzés során elvégezendő fontosabb feladatok: Koncepció (vízió) kialakítása • • • A feladat (overview statement,1-2 mondat) Pl: - Egy

számlakészítő és készletnyilvántartó program elkészítése vagy - Egy egyszerű képkirakó játék elkészítése Az érdekeltek (megrendelő, felhasználó) felsorolása A rendszer határainak magas szintű meghúzása 21 Szoftverfejlesztés alapok • • Előzetes verzió A rendszer céljának tisztázása A legfontosabb tulajdonságok meghatározása Pl: - Mivel a rendszert olyan emberek fogják használni, akik most ülnek életükben először számítógép előtt, fontos a minél egyszerűbb, intuitívabb felhasználói felület kialakítása. vagy - A rendszert alfa verzióját „mindenáron” szállítani kell 3 hónapon belül, még ha a a kevésbé fontos funkciók nem is készülnek el vagy nem működnek tökéletesen. vagy - A rendszert a kilátások szerint több megrendelő számára is szállítani kell, így különösen fontos a moduláris felépítés és a testreszabhatóság. Mint érezhető itt néhány olyan kritériumot kell megadni, melyek

a fejlesztés során támpontot adnak a tervezői és implementációs döntések meghozatalakor. A rendszer funkcióinak meghatározása Táblázatszerűen (esetleg csoportosítva) felsoroljuk mindazokat a funkciókat, amiket a rendszenek tudnia kell. A funkciókat még nem fejtjük ki (nem adjuk meg, hogy milyen lépésekben fognak ezek megvalósulni), bár egy egyszerűbb leírással opcionálisan „megtámogathatjuk” megértésüket. A következő táblázat egy üzleti nyilvántartó rendszer esetében próbálja meg érzékeltetni, hogy miről is van szó (természetesen a teljesség igénye nélkül): Ref# Általános R1.1 R1.2 Árukiadás számlára R2.1 R2.2 Funkció A felhasználónak a rendszer használata előtt érvényes felhasználónévvel és jelszóval hitelesítenie kell magát A rendszernek az adatokat perzisztens módon tárolnia kell Vásárláskor legyen lehetőség az adott vásárló rendszerben történő regisztrálására (amennyiben a vásárló még

nem regisztrált) A tételek felvétele a tétellistába az árucikk vonalkódjának begépelésével vagy vonalkód olvasóval való bevitelével történik. Ilyenkor a rendszer az árucikk törzsadat nyilvántartásból kikeresi az adott árucikket és megjeleníti annak nevét és árát a képernyőn. Stb R2.3 Kimutatások készítése R3.1 A rendszernek a bevételezések és kiadások alapján kimutatásokat kell tudni készítenie, nyomtatható formában R3.2 A kimutatásokat heti, havi és éves bontásban kell elkészíteni R3.3 Kimutatás 1: a kimenő számlák alapján nettó árbevétel R3.4 Kimutatás 2: . 22 Szoftverfejlesztés alapok Előzetes verzió Bonyolultabb esetben a követelmények meghatározhatjuk prioritásukat. között függőségeket definiálhatunk, illetve A rendszer attribútum jellegű követelményeinek meghatározása Valamennyi nem funkcionális követelményt itt kell felsorolni. Pl: - Könnyű kezelhetőség - válaszidőre vonatkozó

követelmények - hibatűrésre vonatkozó követelmények - milyen platformokon kell a rendszernek futnia Fogalomszótár készítése Fogalmak összegyűjtése (Capture a Common Vocabulary) • Nagyon fontos az egyértelmű terminológia kialakítása! • A koncepcióból illetve az üzleti modellből indulhatunk ki Táblázatos formában, röviden definiáljuk a fontosabb fogalmakat. A rendszer folyamatainak/funkcióinak meghatározása Ennek során elkészítjük a rendszer use-case (használati eset) modelljét. Megkeressük a rendszerünkben szereplő aktorokat, use-case-eket és ezek kapcsolatát valamint meghatározzuk a use-case-ekhez tartozó forgatókönyveket. A use-case modell elkészítésének célja, hogy segítse a funkcionális követelmények jobb megértését. Lehetővé teszi ezek ábrázolását, segíti a megrendelő és a fejlesztő közötti jobb kommunikációt. Miben más ez, mint az 1. lépésben tárgyalt (és kevésbé fontos) üzleti folyamatok

modellezése munkafolyamatnál? Itt már konkrétan az elkészítendő rendszer által támogatott munkafolyamatokat írjuk le a rendszer által megvalósított, illetve itt még csak megvalósítandó módon. Use-case modell elkészítése Aktor (szereplő) Definíció: valaki vagy valami a rendszer határán kívül, aki/ami kapcsolatba kerül a rendszerrel. Egy szerepet azonosít a rendszerrel folytatott interakcióban. • Több felhasználó is lehet azonos szerepű. • Egy felhasználó több szerepben is lehet. • A szereplő lehet külső rendszer is. Jelölése: Szereplõ Meg kell találni az aktorokat: 23 Szoftverfejlesztés alapok - Előzetes verzió Kik, milyen felhasználói csoportok fogják használni a rendszert Kik végzik a másodlagos funkciókat, mint például a rendszer karbantartását, adminisztrációját? Lesz-e az új rendszernek kapcsolata más rendszerekkel? (pl. egy bankautomatánál a banki információs rendszer). Pl. egy üzleti számlázó

rendszerben: vásárló, pénztáros, menedzser, rendszer adminisztrátor Use-case Tipikusan a rendszer és a felhasználó közötti kommunikációt ír le - a felhasználó szemszögéből. Egy rendszer által nyújtott magasabb szintű funkciót (üzleti folyamatot) ír le. Jelölés Használati eset A szereplők listájának elkészülése után keressük a használati eseteket: vegyük sorra a szereplőket, és nézzük meg - a felhasználó szemszögéből -, mit várnak a rendszertől! - Mi az az elsődleges funkció, amit a szereplő a rendszertől elvár? - A szereplő fog adatot bevinni a rendszerbe, módosítani vagy törölni? - További használati eset forrás: üzleti folyamatok modellje. Első lépésben a használati eseteket el kell nevezni, és mindegyikhez kell adni egy rövid szöveges leírást. Pl egy üzleti számlázó rendszerben egy használati eset: Use-case név: eladás Aktorok: pénztáros, vásárló Leírás: A vásárló megérkezik a pulthoz a

megvásárolni kívánt tételekkel. A pénztáros rögzíti a tételeket és begyűjti a vásárlótól a pénzt. A rendszer kinyomtatja a számlát három példányban, és a vevő távozik a vásárolt tételekkel és a számlával. Aktorok és use-case-ek kapcsolata Kommunikál kapcsolat Kezdeményezõ Szereplõ Használati eset Résztvevõ szereplõ  Kezdeményező - Minden használati esetet csak egy szereplő kezdeményezhet. Ilyenkor a nyíl vezet a szereplőtől a használati esethez.  Végrehajtás (vagy „részt vesz”) 24 Szoftverfejlesztés alapok Előzetes verzió - Egy használati eset végrehajtásában több szereplő is részt vehet, ilyenkor nyíl nélküli vonal köti össze a szereplőt és a használati esetet. Kiterjesztés (extend) kapcsolat A kapcsolat megadása: <<extend>> sztereotípia megadásával. Két use-case között értelmezett, jelentése: - Különböző, alternatív változatok (az aktor választása, döntése

alapján) - Feltételes végrehajtás Gyűjtsük össze a “Milyen hiba lehet?”, “Hogyan történhet másképp?” kérdésekre a válaszokat. Tartalmazás (include) A kapcsolat megadása: << include >> sztereotípia megadásával. Két use-case között értelmezett, jelentése: • A több használati esetben előforduló közös viselkedést kiemelhetjük • Végrehajtása feltétel nélküli Tekintsünk egy példát a use-case diagram tartalmaz és kiterjeszt relációjára: Általánosítás Két aktor vagy két use-case között értelmezett. 25 Szoftverfejlesztés alapok Előzetes verzió Jelentése: az egyik use-case (ill. aktor) általános esete a másiknak Fontos a behelyettesíthetőségi szabály. Példa, amely a jelölését is szemlélteti: Egy Modern banki információs rendszer hitelesítési mechanizmusának use-case diagramja: Aktorok általánosítására példa.: Felhasználó Péntáros Menedzser Rendszergazda Ebben az esetben a

következő példa érzékelteti jól az általánosítás kapcsolat hasznát: Felhasznál ó azonosítás Felhasznál ó A felhasználó azonosítás use-case jelentése: a rendszerben minden felhasználónak érvényes felhasználónévvel és jelszóval hitelesítenie kell magát, mielőtt a rendszer bármely funkcióját használhatná. Ha nem használtuk volna az általánosítás eszközét, akkor valamennyi felhasználó típust (pénztáros, menedzser, rendszergazda, stb) össze kellett volna kötni a felhasználó azonosítás use-case-el, így egy jóval áttekinthetetlenebb és kezelhetetlenebb ábrát kaptunk volna. 26 Szoftverfejlesztés alapok Előzetes verzió További példák aktorokra és use-case-ekre Áru érkezett Raktározási alrendszer Árufelvevő Árut szállítanak el Eladó Raktárvezető Áru definiálása Raktárkészlet lekérdezése RendszergazdaFelhasználók karbantartása A use-case-ek részletezése • • Részleteiben megadjuk

a használati eset végrehajtásának menetét oly módon, hogy azt mind a felhasználó, mind a fejlesztő megértse Ez a use-case forgatókönyvének megadásával történik Főforgatókönyv (main success scenario): 1. 2. 3. . . . Kiterjesztések (extensions) 3a. Feltétel (ha valami miatt nem teljesülhet a 3 lépés) 1. 2. 3a2a. (ha valami miatt a 3a2 lépés nem teljesülhet) 3a2a1. 3a2a2. Bankautomata use-case modellje: 27 Szoftverfejlesztés alapok Előzetes verzió Use-case: Tranzakciót lebonyolít Főforgatókönyv Ez a forgatókönyv azokat a lépéseket írja le, amelyeket a kiváltó eseménytől a cél végrehajtásáig tesz meg a use case akkor, amikor minden hibátlanul működik. Ezen kívül leírja azokat a szükséges tisztogató lépéseket is, amelyet a cél elérése után kell végrehajtani. Más use case-ek használatára (include) aláhúzással utalunk. Lépés 1. 2. 3. 4. Cselekvés leírása Az Ügyfél hitelesíti magát mágneskártyájával

és PIN kódjával. Az Ügyfél végrehajtja tranzakcióját. A Ügyfél megkapja a kért dolgokat. Az Ügyfél visszakapja kártyáját. Kiegészítések Itt egy-egy főforgatókönyvbeli lépéshez rendelhetünk kiegészítést, amely a számozás révén kapcsolódik a főforgatókönyv adott lépéséhez. Egy másik megközelítésben: milyen hibák fordulhatnak elő a főforgatókönyvben. Ha például a főforgatókönyv 3 lépésében hiba fordul elő, akkor a ki, akkor a kiegészítésekben a 3a lépésben folytatódik. A feltétel kettősponttal megelőzi a lépés további leírását Például: 3a File nem található: kilépés Az „1a1a” számozás jelentése: a hiba az 1a1 kiegészítés lépés során fordult elő. Lépés 1a Feltétel A hitelesítés sikertelen: Cselekvés leírása 1a1. Az Ügyfél még egyszer beüti a PIN kódot 1a1a. Az Ügyfél még egyszer beüti a PIN kódot Utána elveszik a kártyája. 28 Szoftverfejlesztés alapok Előzetes verzió

Technológiai és adatvariációk A főforgatókönyv kiegészítése. A számozási konvenció megegyezik a kiegészítéseknél alkalmazottal Lépés 2.a 2.b 2.c Lépés 3.a Lehetséges variációk A felhasználó átutalást hajt végre A felhasználó pénzkivételt hajt végre A felhasználó egyenleglekérdezést hajt végre. Lehetséges variációk A kért dolgok átutalás és egyenleglekérdezés esetén nyugta, pénzkivétel esetén pénz és nyugta. Tevékenység diagram (activity diagram) A folyamatok szemléltetésére szolgálhat. A fontosabb, bonyolultabb üzleti folyamatokhoz (usecase) célszerű készíteni - A folyamatok szerkezetét ezzel szemléltethetjük. - Hasznos munkafolyamatok, illetve párhuzamos folyamatok modellezésére is. Penztaros Rendszer [Az adott vasarlo meg nincs regisztralva] Vasarlo regisztralasa Tetelek felvitel e Elfogad Szamla nyomtatasa Keszlet csokkentese a tetelekbol Email kul dese a vasarlonak az aktualis akciokrol A egyes,

aktivitás diagrammon szerepeltethető modell elemek: 29 Szoftverfejlesztés alapok Kezdõ áll apot Előzetes verzió Aktivitás Döntés Befejezõ ál lapot Szinkronizáci ós vonal Aktivitás (vagy tevékenység): valamilyen, nem pillanatszerű tevékenység Szinkronizációs vonal (synchronization bar): párhuzamos folyamatok szemléltetésére használható. - Ha egy szinkronizációs vonalba egy átmenet meg be és több átmenet jön ki, akkor azon tevékenységek végrehajtási sorrendje, melyekbe a kimenő átmenetek vezetnek számunkra közömbös (párhuzamos végrehajtás). - Ha egy szinkronizációs vonalba több átmenet megy be és egy jön ki, akkor a kimenet csak akkor következik be, ha az összes bemenő tevékenységek már befejeződött (tevékenységek szinkronizációja). Átmenet: Végrehajtása pillanatszerű. Az tevékenység befejezésekor egy következő aktivitásba megy át. Feltételhez lehet kötni, a feltételt [] között kell megadni

(guard), pl: [a>b] Döntés: elágazásra használható, feltételhez kell kötni az egyes kimenő átmeneteket. Megjegyzések a use-case modellel kapcsolatban • • Elő- és utófeltételek leírása • Nem az indító vagy termináló események, hanem azok a feltételek, amelyeknek igaznak kell lenniük a használati eset indulása előtt illetve befejeződése után Felhasználói felület modellezése (User Interface Modeling) • A felhasználói felület azon osztályainak definiálása, amelyek egy adott használati esethez kötődnek, ezek modellezése, leírása Az iterációk megtervezésének fontos lépése, hogy az egyes use-case-eket különböző szempontok (pl. kockázati tényezők) alapján prioritási sorrendbe helyezzük és eldöntjük, hogy az egyes usecase-eket melyik iterációban valósítsuk meg Amikor a use-case-eket keressük a rendszerben gyakori hiba, hogy egy alacsonyabb szintű lépést veszünk fel use-case-nek. Egy use-case mindig egy

magasabb szintű funkciót (üzleti folyamatot) jelent: egy folyamat elindításától annak befejezéséig tart, és mindig van valamilyen eredménye a rendszer szempontjából. Pl egy eladás use-case esetében a vásárló kiválasztását vagy a tételek számlára való felvételét nem tekinthetjük külön use-case-nek, mert önmagukban nincs értelmük, eredményt nem produkálnak. Ehelyett ezek az eladás use-case forgatókönyvében szereplő lépések. 30 Szoftverfejlesztés alapok Előzetes verzió Amikor valamilyen modellező eszközt használunk, lehetőség van a rendszerünk use-case modelljének több diagramon való ábrázolására (mindegyik a modell egy különböző nézetét, „szeletét” adja). Gyakori hiba, hogy a rendszer valamennyi use-case-ét egy diagramra próbáljuk meg bezsúfolni, aminek eredményeképpen egy áttekinthetetlen ábrát kapunk. Próbáljuk meg ehelyett a use-case modellt aktoronként vagy valamilyen más szempont szerint

csoportosítva diagrammokra bontani. Természetesen ritkán sikerül első nekifutásra a use-case modellt végleges formájában kialakítani. Ez természetes, hiszen a problémát és a követelményeket is folyamatosan értjük meg: ennek megfelelően lehetőség van a use case modell több lépésben történő finomítására. Bár elsődlegesen a következő tevékenység (analízis) része, de már itt is megtörténhet a rendszer magas szintű fogalmi modelljének (conceptional model) elkészítése. A fogalmi modell elkészítésekor objektum-orientált megközelítésben (objektumok, linkek, osztályok, asszociációk) ábrázoljuk a problématér „dolgait”, fogalmait és ezek kapcsolatát. Áttekintés Célunk a funkcionális és nem funkcionális követelmények meghatározása. OOAD esetében a funkciók leírásának leginkább javasolt módszere a rendszer use-case modelljének elkészítése, amely során definiáljuk a rendszerben az aktorokat, use-case–eket,

meghatározzuk ezek kapcsolatát, valamint dokumentáljuk az egyes use-case-ek forgatókönyveit. Egy aktor egy szerepkört (pl. pénztáros), egy use-case egy üzleti folyamatot (megrendelés felvétele), magasabb szintű rendszer funkciót reprezentál. Egy use-case folyamatának ábrázolására aktivitás diagramot készíthetünk. A követelmény analízis végére elkészül az ún. követelmény specifikáció dokumentum, amely pontosan leírja a követelményeket. Ez az a dokumentum, amit a megrendelő és a szállító aláír, így hivatalos keretet biztosít mind a megrendelő (azt kapja, amit kért) mind a fejlesztő cég (a megrendelő ne tudja a végtelenségig csűrni-csavarni a követelményeket) védelmére. 2.3 Analízis (elemzés) és tervezés Előljáróban megjegyezném, hogy a RUP az analízis és tervezés tevékenységet nem választja élesen külön, hanem egy analízis-tervezés tevékenységet definiál. Ez természetesen nem véletlen, hosszú órákon

át lehetne vitatkozni azon, hogy mi tartozik pontosan az analízis és a tervezés lépésbe, akkor sem jutnánk megegyezésre, a kettőt nem lehet élesen elválasztani egymástól (mint ahogy ez a szoftverfejlesztés „professzorainak” sem sikerült eddig). Az analízis arra próbál választ adni, hogy mit, a tervezés pedig arra, hogy hogyan. Az analízis során a megértés a hangsúlyos, a tervezés során a szintézis, egy megoldás elkészítése. Analízis A analízis során megismerjük a problémateret és elkészítjük a létrehozandó rendszer fogalmi modelljét. A cél a problématér számunkra fontos fogalmainak, „dolgainak” és a köztük levő kapcsolatok meghatározása és modellezése (tisztán a problématér fogalmaival, eszköz és technológia függetlenül!). OOAD esetében a világ dolgainak, fogalmainak ábrázolása, megragadása objektumokkal történik. Azokat az objektumokat keressük, melyek az elkészítendő rendszer szempontjából fontosak

(pl. egy könyvtári nyilvántartó rendszer esetében ezek a könyv, 31 Szoftverfejlesztés alapok Előzetes verzió könyvtár, kölcsönzés, stb.) Az analízis bemenete a követelmény specifikáció (egyszerűbb esetben a probléma definíció). Analízis a RUP esetében: - architektúra analízis (később) - use-case analízis A use-case analízis célja - Meghatározni azokat az osztályokat, amelyek a használati esetet végrehajtják - A használati eset által definiált viselkedést szétosztani az osztályok között Az analízis végére rendszerint elkészül a rendszer analízis modellje - Objektum és osztály diagrammok a fogalmi modell statikus ábrázolására Szekvenciális és kollaborációs diagrammok az egyes use-case-ek és a fogalmi modell dinamikájának (időbeli lefolyásának ábrázolására) Tervezés Az analízis során meghatározott követelményeket végtelen sok számítógépes rendszer meg tudja valósítani. A tervezés során azt

határozzuk meg, hogy hogyan fogja rendszer a követelményeket megvalósítani, vagyis egy megoldást keresünk. A tervezés során az ún. implementációs térben dolgozunk, a felhasználható eszközök és technológiák figyelembe vételével elkészíthető megoldásokat keressük: feladatunk a rendszer implementációs modelljének elkészítése. A részletes tervezés során OOAD esetben azokat a szoftver objektumokat keressük, melyeket majd végső soron valamely objektum-orientált nyelven implementálni fogunk. Meghatározzuk, hogy az egyes objektumok pontosan milyen attribútumokkal és metódusokkal rendelkeznek. Mi alapján választunk megoldást? Néhány szempont: - A legtermészetesebb kikötésünk az, hogy a rendszer minél inkább kövesse a fogalmi modellt, hiszen ezáltal válik az elkészült implementációs modell könnyen érthetővé - figyelembe vesszük a teljesítményre vonatkozó megkötéseket (az analízis modell csak a funkcionális

követelményekről szól) - figyelünk arra, hogy rendszerünk könnyen kiterjeszthető, módosítható legyen a rendszer - törekszünk arra, hogy már meglevő komponenseket használjunk fel, vagy újrafelhasználható komponenseket készítsünk el (csak ha van értelme, mert meglehetősen nagy a „költésvonzata”) - Segítenek a tervezési minták!!! A tervezés végére elkészül a rendszer tervezési modellje: - Architektúra terv (különböző architektúra diagrammok). Az architektúrának több nézete létezik (a RUP szerint 4+1), mindegyiket el kell készíteni. - Részletes terv - osztály diagrammok (statikus nézet) 32 Szoftverfejlesztés alapok Előzetes verzió - fontosabb objektumok kollaborációját ábrázoló kollaborációs vagy szekvenciális diagrammok Statikus nézet A fogalmi modell statikus nézete: objektum diagramok és osztály diagramok. Objektum – egy jól körülhatárolt „dolog” - Entitás, egyed: megkülönböztethető a többi

objektumtól Vannak tulajdonságai, vagyis attribútumai Van állapota, ami attribútumainak aktuális értékeiből adódik Műveletek értelmezettek rajta, ezek határozzák meg a viselkedését. (Műveletei által definiált szolgáltatásokat nyújt, ezek által vesz részt a rendszer megvalósításban.) Ezen a szolgáltatások megvalósítását elrejti (fekete doboz), és csak egy jól definiált interfészen (a műveletek egy halmaza) keresztül vehetők igénybe: így a rendszer áttekinthetőbb és könnyebben módosítható Jelölése: Kiss Béla Jelölése az osztály nevének megadásával: Kovács Géza : Személy Kiss Béla : Személy Az objektumok közötti kapcsolatot neve: link (ami az asszociáció egy példánya, lásd később). Pl.: Föld : Bolygó kering Nap : Csi ll ag kering Mars : Bolygó Objektum diagram A problémateret modellezi objektumokkal (objektumok és kapcsolatuk). Nem kötelező elkészíteni, ha van tapasztalatunk, modellezhetünk egyből

osztályokkal is (valójában ha kellő rutinnal rendelkezünk, akkor soha nem szoktuk elkészíteni, bár egy egészen bonyolult és nehezen érthető probléma esetében még ekkor is célszerű lehet ezzel kezdeni). Osztály Az azonos attribútumokkal és műveletekkel rendelkező objektumok azonos osztályhoz tartoznak. Fordítva: az objektumok példányai az osztálynak Tekinthetjük az osztályokat az azonos tulajdonságú és viselkedésű objektumok öntőformájának is. Osztály diagram 33 Szoftverfejlesztés alapok Előzetes verzió A problémateret modellezi osztályokkal: - osztályok azonosítása - osztályok attribútumainak meghatározása - osztályok közötti kapcsolatok meghatározása Meg kell találni a rendszerben az osztályokat ami egy nehéz feladat. Azon fogalmak listáját keressük, amelyeket osztályként kell ábrázolni. Egy másik jó stratégia a probléma leírásban szereplő főneveket aláhúzni, első megközelítésben legyenek ezek az

osztályok. Ezt még alaposan meg kell szűrni: - közös viselkedéssel bíró osztályokat összevonni - vigyázzunk, bizonyos főnevekből osztályok attribútumai lesznek (pl. a lakcímet nem célszerű külön osztályként ábrázolni, legyen inkább a személy osztály attribútuma) Megjegyzés: az analízis során a fogalmi modell elkészítésekor a rendszernek egy viszonylag durva modelljét készítjük el: - Modellezzük az osztályokat és azok kapcsolatait - Meghatározzuk az osztályok fontosabb attribútumait (típus megadása nélkül) - A műveletek közül csak a legfontosabbakat adjuk meg A következő fejezetek a az UML nyelv statikus modellek leírására alkalmas elemeit tekinti át, azon elemeket is részletezve, melyeknek inkább csak a tervezés során lesz jelentősségük. UML kitérő: Tihamér jegyzete Osztály jelölése: Stack m elemek : int* = NULL m aktual isindex : int = 0 Push(el em : int) Pop() : int Stack() ~Stack() Attribútumok Típus

kifejezése: Programozási nyelvtől függő típusmeghatározás (pl. int, char, ) Kezdőérték: Szintén nyelvfüggő kifejezés a kezdőérték beállítására. Műveletek <<sztereotípia>> láthatóság név (paraméterlista) : visszatérési érték kifejezése Ahol a paraméterlista a következő szintaxisú vesszővel elválasztott formális paraméterekből áll: név : típus kifejezése = alapértelmezett érték Láthatóság Osztály sztereotípiák: Pl. a részletes tervezés során: ha egy osztály struktúra, akkor az a neve elé írt <<struct>> sztereotípiával lehet megadni. 34 Szoftverfejlesztés alapok Előzetes verzió Osztályok közötti kapcsolatok A valódi világ entitásai általában nem függetlenek egymástól. Általánosítás-specializáció (generalization) Egyik osztály általános esete a másiknak. A leszármazottak öröklik az ős viselkedését és tulajdonságait. Asszociáció Kommunikációt (információ

áramlást) jelent az osztályok között. Csil lag keri ng Bolygó A kommunikációnak iránya van. Ahhoz, hogy a kommunikáció létrejöhessen a kezdeményezőnek el kell érnie a cél osztályt: ez határozza meg az asszociáció irányát. Az analízis során kétirányú (bidirectional) kommunikációt szoktunk feltenni, és annak eldöntését, hogy a két irányból melyikre van szükség a tervezési fázisra hagyjuk. Egyirányú asszociáció jelölése és példa. Video capture system uses Im age compressor Az asszociációnak lehet nevet adni, ha két osztály között több asszociáció is létezik, akkor kötelező. Szerepkörök Önmagával asszociáció és több asszociációra példa: házasság 0.1 +feleség 0.1 +férj Személy +főnök 0.1 +beosztott * hierarchia Lásd 35