A rendszerfejlesztés technológiája

Az előadások a következő témára: "A rendszerfejlesztés technológiája"— Előadás másolata:

1 A rendszerfejlesztés technológiája
Előadásvázlat

2 A szoftver A szoftver a programok, az adatok és a dokumentációk együttese, nem csak maga a program. Adatok alatt a szoftver vásárlásakor kapott állományokat kell érteni: ilyenek pl. a telepítő és a konfigurációs állományok.

3 A szoftver egy termék bizonyos funckiót szolgáltat (szolgáltatási funkció) határidőre kell előállítani (előállítási határidő) előállításának van költsége (előállítási költség) minőségi elvárásoknak kell megfelelnie (minőségi elvárások)

4 Szerzői jog - szabadalom
Automatikusan jár, ingyenes – bejegyzése, fenntartása országonként díjhoz kötött, a szabadalmi per is drága Szerző halála után 70 évig, utána közkincs – 20 évig Szellemi termékekre – találmányokra A szabadalom révén a gazdag multinacionális vállalatok jelentős előnyhöz jutnának a kisebb fejlesztőkkel szemben, a szabadalom húsz éves monopóliumot garantál tulajdonosának, és a hosszú ideig tartó védettség lelassítaná az iparág fejlődését, rontaná a programok minőségét és drágábbá tenné a multinacionális cégek termékeit

5 A szoftverek csoportjai
1. általános célú (dobozos; COTS = Commercial On The Self) szoftvertermékek bárki megvásárolhatja általában sok év fejlesztőmunkája van mögötte általában nagy szoftverek a szakértelmet és a befektetett energiát kell megfizetni pl.: az Oracle adatbázis-kezelő rendszere

6 A szoftverek csoportjai
2. Célszoftverek megrendelésre készülnek a kifejlesztést kell megfizetni pl.: a Neptun egységes felsőoktatási tanulmányi rendszer

7 Új módszerek Az információs rendszerek fejlesztéséhez, a szoftvertechnológiához, a szűkebben vett információ oldali részhez a kitalálás óta két új dolog csatlakozott: minőségbiztosítási módszerek a szoftverek kifejlesztéséhez; projektvezetési, -irányítási, -szervezési módszerek a fejlesztést végző emberek munkájának menedzselésére A nagyméretű (néhány százezer, de inkább néhány millió soros), összetett (komplex), hosszú fejlesztési idejű szoftverek előállítására vonatkoznak. Ebből következően nem egyedi munka, hanem csapatok dolgoznak a projekten, valamint a fejlesztési költség nagy, így a bukás is nagy lehet.

8 A szoftver, mint termék előállítása tevékenységsorozatban
specifikáció: az elvárásokat tárjuk fel, konkretizáljuk, rögzítjük elkészítés/implementáció validáció: az elkészült szoftverről belátjuk, hogy megfelelő szoftverevolúció: az elkészült szoftver módosítása, továbbfejlesztése (nem hibajavítás!)

9 A szoftverfejlesztés rendszerszervezési elemei
elemzés (analízis), tervezés, implementáció, követés.

10 Absztrakt megközelítés
A szoftverfejlesztési életciklusban egy abszrakt megközelítéstől egy teljesen konkrét megközelítés felé megyünk el valamilyen módon, valamilyen alkalmazott tevékenységsorozat folyamán. A cél ezt a tevékenységsorozatot abba az irányba tolni, hogy minél hamarabb, minél absztraktabb módon megfogalmazott dolgokból tudjuk a konkrét dolgokat automatikusan létrehozni.

11 A folyamat a követelmények meghatározása és elemzése tervezés
alrendszerek fejlesztése rendszerintegráció a rendszer telepítése a rendszer működtetése rendszerevolúció a rendszer üzemen kívül helyezése

12 A szoftverfejlesztés folyamatának kiegészülése
Minőségbiztosítás és projektmenedzsment Fő célok: határidők meghatározása, melyik lépést mikorra kell végrehajtani; szükséges hardver-, szoftver-, emberi, és anyagi erőforrások biztosítása; az emberek munkájának irányítása, az erőforrások szétosztása, határidők biztosítása stb.

13 A követelmények meghatározása és elemzése
funkcionális követelmények: rendszerszolgáltatások, pl.: tantárgyfelvétel, jegybeírás stb. rendszertulajdonságok: a rendszer egészére jellemző dolgok, pl.: rendelkezésre állás, biztonságosság, felhasználói felület lehatárolás: a rendszernek mit nem kell tudnia A rendszer követelményeinek meghatározása természetesen a felhasználókkal történő konzultációsorozaton keresztül történik, a felhasználókat nem lehet kihagyni a szoftverfejlesztésből. (Nyilvánvalóan időnként beszélünk a dobozos szoftverekről, azonban most a hangsúly a fejlesztésen van, tehát a második kategóriájú szoftverekről (célszoftverekről) beszélünk elsősorban.) Tehát a követelmények a felhasználókkal együtt derítendők ki, elemzendők és dokumentálandók.

14 Tervezés Alrendszerek azonosítása Követelmények alrendszerekhez rendelése Alrendszerek interfészének definiálása funkcionalitásának meghatározása Követelmények felosztása A lekerekített objektumok a tevékenységeket, a köztük lévő nyilak az egymásutániságukat, vagy egymáshoz való viszonyukat szemlélteti, a tevékenységek eredményét pedig majd téglalap jelzi. A tervezés során a követelményektől eljutunk valamilyen módon az alrendszerekig.

15 Alrendszerek fejlesztése
Az alrendszerek általában párhuzamosan fejlesztendők, fejleszthetők. Az egyes alrendszereken dolgoznak az egyes fejlesztői csapatok; tervezés után fejlesztik, implementálják, kódolják, majd tesztelik az egyes alrendszereket. Ennek eredményeképpen előállnak az alrendszereink.

16 Rendszerintegráció A kifejlesztett alrendszerekből összeállítjuk a teljes rendszert. Előfordulhat, hogy bizonyos alrendszereket nem fejlesztünk, hanem megvesszük. Bár a rendszerintegrációnál feltesszük, hogy az egyes alrendszerek önmagukban jól működnek, a rendszer összeállítása sok gondot okozhat.

17 A rendszer telepítése Ha a rendszerfejlesztő cég és a megbízó jónak látja az elkészült rendszert, akkor következik a rendszer telepítése. A kifejlesztett rendszert konkrét hardver és szoftver platformra kell telepíteni. Elképzelhető, hogy a kifejlesztett rendszer nem okoz osztatlan lelkesedést a felhasználók között, amikor telepíteni kell, mert pl. ellenérdekeltek, utálják a rendszer fejlesztőjét, nem szeretnének áttérni az új rendszerre stb. Általában a megrendelő nem maga a felhasználó. Általában egy működő rendszert szándékozunk lecserélni egy másik rendszerre. Ha egy működő rendszer kényelmetlen is, egy idő után megszokja az ember.

18 A rendszer működtetése
A rendszer működtetése során derülnek ki a problémák, amire nem gondolt a felhasználó, működés közben ezeket a problémákat orvosolni kell. Ki tegye mindezt? Ez főnök vagy szerződés kérdése. Nagyon fontos a felhasználók képzése; a felhasználókat el kell látni információval. A rendszert működtetni kell, a működtetést pedig emberek végzik. Általános az, hogy egy nem 100%-osan jól megírt rendszert az emberi hibák nem abba az irányba viszik, hogy kijavítsák a hibákat, hanem inkább még jobban felnagyítják.

19 Rendszerevolúció A rendszert módosítjuk, továbbfejlesztjük a felhasználói környezet, a törvényi szabályozás, a cég méretének stb. megváltozása miatt. Tehát természetes fejlődés megy végbe a szoftvereknél is, amelynek semmi köze nincs a hibákhoz. Tervezéskor figyelembeveendő.

20 A rendszer üzemen kívül helyezése
Az információs rendszer általában nem önmagában létezik, hanem további rendszerek környezetében dolgozik: más rendszerektől adatokat fogad, más rendszereknek adatokat szolgáltat. A végiggondolt rendszerevolúció oda vezet, hogy nem a teljes rendszert állítjuk le, csak a rendszernek bizonyos részeit, bizonyos alrendszereket cserélünk le

21 Szabványok tényleges, törvényszintű (de jure) szabványok: szabványügyi szervezetek (ISO, ANSI) dolgozzák ki őket ipari (de facto) szabványok: a szakterület vezető cégei összeállnak és alkotnak valamilyen formációt, konszenzusra jutnak, és ezt nyilvánosságra hozzák. (W3C) piaci szabványok: olyan szakterületeken alakulnak ki, amelyeken van egy nagyon erős piaci cég, őhozzá igazodnak a többiek

22 Folyamatmodellek vízesés modell evolúciós modell
formális fejlesztési modell újrafelhasználás-alapú modell iteratív modellek spirális fejlesztési modell inkrementális fejlesztési modell A szoftverfejlesztés egy folyamat. Az elmúlt néhány évtizedben kialakultak szabványos folyamatmodellek (életciklusmodellek). Ezen folyamatmodellek mindegyikének megvannak az előnyei és hátrányai, megvan az alkalmazási területe, mikor célszerű és mikor nem célszerű használni. A folyamatmodellek történetileg az elmúlt harminc éven át folyamatosan alakultak ki. Azonban ez nem azt jelenti, hogy a korábbi folyamatmodellek elavultak; ezen folyamatmodellek mindegyike ma is él. El kell tudni dönteni, hogy egy adott szoftver fejlesztésénél melyik modellt követjük, beleértve azt is, hogy keverjük őket.

23 Vízesésmodell Az első folyamatmodell, amely a történelemben kialakul, 1970-ben definiálták. Ez más termékelőállítási folyamatmodellből származik. követelmények meghatározása rendszer- és szoftvertervezés implementáció és egységteszt működtetés és karbantartás A vízesésmodell a nevét onnan kapta, hogy a folyamatelemek, az egyes lépések meglehetősen mereven egymásra épülnek, ilyen lépcsőzetesen kapcsolódnak egymáshoz, mint ahogy a víz folyik le a sziklán. Ez a modell előnyeit és hátrányait egyaránt magába foglalja.

24 Vízesésmodell Előnyei: Hátrányai:
a legegyszerűbb, a legjobban alkalmazható modell kicsi és közepes méretű rendszereknél jól struktúrált, jól felépített, jó architekturális jellemzőkkel rendelkező, robusztus rendszer fejleszthető Hátrányai: Merev, nem flexibilis egymásraépülés. Minden egyes folyamat teljeskörűen lezárul, mielőtt a következő folyamat elindulna. A legutolsó lépésben derülnek ki a korai lépések problémái: nem teljesített követelmények, félreértések, stb.

25 Evolúciós modell A 80-as évek elején találták ki, párhuzamos fejlesztési modell, implementációk verzióin keresztül jutunk el a végső verzióhoz: verziósorozatot produkál vázlat leírása specifikáció fejlesztés validálás kezdeti verzió közbülső verziók végleges verzió Adott egy kezdeti implementáció, majd annak vannak valamilyen változatai és végül megszületik a végleges verzió. Ezeket a verziókat hívja a modell prototípusoknak. Tehát ez a prototípusorientált vagy prototípusalapú modell. A párhuzamosság és a verziókezelés nagyon gyors visszacsatolási lehetőséget jelent, gyors beavatkozást tesz lehetővé. Tehát nem a végén derülnek ki a hiányosságok, hanem menet közben.

26 Evolúciós megközelítések
feltáró fejlesztés: a felhasználó és a fejlesztő közösen finomítja a követelményeket eldobható prototípuskészítés:a felhasználó kipróbálja a prototípust, így rájöhet, hogy mit akar. feltáró fejlesztés A prototípusok segítségével a felhasználó és a fejlesztő közösen finomítja, pontosítja a követelményeket, tehát prototípus sorozaton keresztül tárjuk fel a követelményeket. Tehát a felhasználó kap egy működő verziót, ezek alapján pontosítja a követeményeket, a fejlesztésnél ezt figyelembe vesszük és a következő verzió már jobban teljesíti a követelményeket. Így a verziósorozat egyes verzióiban egyre több felhasználói igény kerül beépítésre, míg a végső verzió már a tényleges követelményeknek megfelelő verzió lesz. Ez lesz a rendszer. Ilyenkor az első prototípusoknak a rendszer azon részeivel kell kezdődnie, amelyek tiszták, világosak, amelyeknek a követelményei egyértelműek, a rendszer ismert részeinek kifejlesztésével kezdődik. A kevésbé ismert, zűrösebb rendszerelemek a későbbi prototípusokba kerülnek bele. Minden prototípus az előzőből következik, az előző prototípusra épül, a végleges változat prototípus sorozat alapján készül el. eldobható prototípuskészítés Adunk a felhasználó kezébe egy verziót, és ennek segítségével a felhasználó kipróbálja a prototípust, így rájöhet, hogy mit akar. Ha arra jön rá, hogy nem ezt akarja, a prototípust eldobjuk, újrafogalmazzuk a követelményrendszert, és az ennek megfelelő prototípust állítjuk elő. Ebben a megközelítésben az első prototípusok a legkevésbé megértett, legkevésbé feltárt rendszerelemekkel kezdődnek azért, hogy a felhasználó kitalálja, mit akar.

27 Evolúciós modell Előnyei Hátrányai
Nagyon hamar kap kipróbálható verziók A felhasználó hamar rájöhet, hogy a követelmények jók vagy nem Hátrányai A túl sok verzió áttekinthetetlenné válhat Nem robusztusak: általában rossz struktúráltságú, architektúrájú szoftverhez vezet. Gyors fejlesztést, rapid techikákat igényel

28 Formális modell A 70-es években alakult ki a vízesés modell egy változataként. követelmények meghatározása formális specifikáció formális transzformáció integráció és rendszerteszt rendszer-validáció Megtakarítjuk azt a lépést, amelyet mindenütt majd validálásnak nevezünk, mivel az egész modell a validáláson alapszik. Ehelyett van egy matematikai eszközrendszer, amellyel ezt megtesszük. A model Mills-től származik. Konkrét alkalmazása a 80-as évek második felében az IBM-Cleanroom folyamat. A Cleanroom egy formális modell alkalmazó szoftverfejlesztői folyamat. A közbenső rész más: a rendszerspecifikációból matematikai eszközökkel formálisan generálunk működő programot. A transzformációs folyamat a formálisan megadott követelményekből előállít egy adott nyelvű kódot.

29 Formális modell Előnye: Hátránya:
automatizált a folyamat; bármilyen rendszer esetén alkalmazható biztonságkritikus rendszerek esetén alkalmazzák Hátránya: a rendszerkövetelmények formalizálása kézzel kell, hogy történjen

30 Újrafelhasználás-orientált modell
Léteznek olyan komponensek, amelyeket újrafelhasználhatunk (kód, tervezési szinten) követelmények specifikációja komponens-elemzés követelmények módosítása rendszerterv újrafelhasználással fejlesztés és integráció rendszer-validáció Ha megvan a követelmények specifikációja, akkor elsőként megnézzük, hogy a világban vannak-e olyan szoftverek, netalán olyan tervelemek, amelyek nekünk jók, felhasználhatók a mi rendszerünkben; megkeressük ezeket az elemeket. Problémák: Ø   tudnunk kellene, hogy vannak ilyen komponensek Ø   tudnunk kellene, hogy egyáltalán milyen komponensek vannak Ø   meg kellene tudni találni ezeket a komponenseket ha meg is találtuk, ezek nagy valószínűséggel nem felelnek meg teljes mértékben az igényeinknek. Megoldásként módosítjuk a követelményeinket annak megfelelően, hogy a kész komponenseket be tudjuk építeni a rendszerünkbe. Aztán ennek megfelelően végrehajtjuk a tervezést és beépítjük a tervbe vagy az implementációba a komponenseket.

31 Újrafelhasználás-orientált modell
Hátrány: kompromisszumok, leromolhat a rendszer struktúrája Előnyök: idő, pénz megtakarítása; a komponensek kipróbáltak, teszteltek stb., így egyfajta biztonságérzetet nyújt, sok validációs lépést megspórolhatunk.

32 Iteratív folyamatmodellek: inkrementális fejlesztési modell
A fejlesztés inkremensekben történik, az inkremenseket építünk, inkremensekkel bővítjük, és ha szükséges, nyilván megismételjük az inkremenshez akár a specifikációs tervezés lépését is.

33 Inkrementális modell vázlatos követelmények meghatározása
inkremensekhez rendelése rendszer- architektúra megtervezése rendszer-inkremens fejlesztése inkremens validálása inkremens integrálása rendszer validálása végleges rendszer a rendszer nem teljes Az alsó rész, az inkremensek hozzáillesztése ciklikus folyamat, mindaddig folytatjuk, amíg úgy nem döntünk, hogy kész van a rendszer. Az inkrementális fejlesztésnek ez a ciklus a lényege. Az inkremenseket önállóan fejlesztjük, tervezzük, implementáljuk, validáljuk, sőt adott esetben még a követelményspecifikációt is megadhatjuk, megváltoztathatjuk inkremensenként. Az architektúrát változatlanul hagyva az inkremensek fejlesztése teljes életciklussal történik.

34 Inkrementális modell Előnyei:
inkremensek kicsik, jól körülhatárolhatók, adott esetben a követelmények egyértelműen specifikálhatók az inkremensek fejlesztése történhet párhuzamosan kezdhetjük a legfontosabb inkremensekkel, a felhasználó nagyon hamar kap egy nem eldobható prototípust, a rendszerfejlesztés kockázata kisebb a rendszerfejlesztés közben a hibák hamarabb kiderülnek Az inkrementális modell előnyei: Ø   az inkremensek kicsik (úgy kell megtervezni, hogy kicsik legyenek), ezekre önmagukban a legmegfelelőbb modell alkalmazható, például vízesésmodell is (az inkremensek kicsik, jól körülhatárolhatók, adott esetben a követelmények egyértelműen specifikálhatók). Ø   az inkremensek fejlesztése történhet párhuzamosan Ø   kezdhetjük a fejlesztést a legfontosabb funkciókat realizáló inkremensekkel, és mivel az inkremensek kicsik, a felhasználó nagyon hamar kap egy nem eldobható prototípust, amely viszont már nem a követelményfeltáráshoz való, hanem már tudja használni. Tehát bizonyos funkciókat, a legalapvetőbb funkciókat tartalmazó rendszert nagyon hamar kap a felhasználó, a kevésbé lényeges funkciókat majd később beépítjük a rendszerbe. A rendszervalidálás mindig megtörténik, tehát a rendszer ilyen értelemben a beépített inkremensekkel önmagában egy részrendszer, tehát egy használható rendszer. Ø   a rendszerfejlesztés kockázata kisebb, mint az összes többi modellnél (a fejlesztések igen nagy része, több mint 50 százaléka sikertelen), mivel a rendszer validált, kis elemekkel, tehát van egy validált működő rendszer még akkor is, ha befullad a projekt, legfeljebb nem teljes funkcionalitással. Nagyon nagy a valószínűsége, hogy az első pár inkremensnél még nem fogy el a pénz, az idő, az ember, nem változik meg a környezet. Ezért a részsikeres befejezés valószínűbb ennél a fejleszési modellnél. Ø   a fontosabb funkciókat implementáljuk először, ennek a következtében azokat a funckciókat a felhasználók rendszeresen tesztelik, a fontosabb funkciókat jóval többször használják, mint a kevésbé fontosakat. Így már a rendszerfejlesztés közben a hibák hamarabb kiderülnek, a mindenkori részrendszerben valóban a legfontosabb funkciók a legteszteltebbek. Tehát egy robusztusabb rendszer fejlesztéséhez vezet ez a modell. A modell problémáját a 2. és 3. lépésben az inkremensek megtervezése jelenti: milyen funckiókat tegyünk egy-egy inkremensbe? Mit jelent egy inkremens? Ez a felosztás, az architektúra megtervezése az, ami nagyon nyűgös. A modell ezen alapszik, tehát ha az elején az architektúrát rosszul tervezzük meg, akkor gond van. Nagyon nehéz az inkremensek behatárolása, az elején eldöntjük, hogy melyek a fontosabb funkciók: Melyik funkció mely inkremensbe kerüljön? – az inkremensek átfedhetik egymást, nem lehet a funkciókat egymástól szétválasztani.

35 Spirális modell 1. lépés: célok meghatározása
2. lépés: kockázatelemzés, kockázatok felismerése, megszüntetése 3. lépés: fejlesztés és validálás 4. lépés: áttekintés, döntés a folytatásról A legkésőbb, 1988-ban kialakuló modell, az ún. Boehm-spirál. Ez teljesen más modell, mint az eddigiek. Középpontjába olyan dolog kerül, amivel az eddigi modellek nem foglalkoztak: a fejlesztés kockázati tényezőinek felmérése, a kockázatból származó problémákra való felkészülés, a sikertelen kimenetek, a rizikó csökkentése. Négy alaplépés van, ezeket spirálisan ismételgetjük, tehát a következő spirálban ugyanaz a lépés az eddigieknél magasabb szinten ismétlődik meg. 1. lépés: a követelmények, pontosabban célok meghatározása: az adott spirális fázisban mit fogunk megvalósítani? azonosítjuk a tevékenységeket, meghatározzuk a megszorításokat, a menedzselési tervet és azt, hogy milyen kockázati tényezők várhatók ebben a lépésben, és ezeket a kockázatokat hogyan fogjuk kezelni, milyen alternatívák lehetnek a kezelésre. 2. lépés: kockázatelemzés, kockázatok felismerése, kockázatok tényezőinek megszűntetése, ezekre való felkészülés: megtervezzük azokat a lépéseket, amelyek azt célozzák, hogy a kockázatokat el tudjuk kerülni. (Ha például a követelmények meghatározása kritikus pont, tehát úgy gondoljuk, hogy a teljes fejlesztésben nagyon nagy kockázatot jelent, rosszak a követelmények, akkor egy feltáró evolúciós modellt alkalmazzuk ebben a lépésben, építenünk kell egy prototípus sorozatot a követelmények minél pontosabb meghatározása érdekében.) 3. lépés: fejlesztés és validálás: a 2. lépés után fejlesztési modellt választunk, adott esetben minden egyes spirálban más-más fejlesztési modell alkalmazható, adott esetben a kockázatanalízis eredményeként választható a fejlesztési modell. Ezek után hajtjuk végre a szokásos tervezés, implementáció, validálás lépéseket. Az első spirálok esetén nyilvánvalóan a követelményfeltárás, követelménytervezés és a validációs lépések következnek, amíg el nem jutunk odáig, hogy... 4. lépés: tekintsük át a teljes projektet, az eddigi fejlesztést, az eddigi spirálokat, elemezzük ezeket, és döntsünk a folytatásról olyan értelemben, hogy megállunk-e (a megvalósíthatósági esettanulmány után dönthetünk úgy, hogy befejezzük). Amennyiben a folytatásról döntünk, a projektet tervezzük meg, azt tervezzük meg, hogy hogyan folytatódjon a projekt, és kezdődik elölről a spirál.

36 Spirális modell Előnyei: Hátrányai: foglalkozik a kockázatokkal
sokkal szisztematikusabban foglalkozik a projekttel Hátrányai: nem a legtriviálisabb modell nagy rendszereknél javallott

37 KÖVETELMÉNYEK MEGHATÁROZÁSA, ELEMZÉSE
A követelmények osztályozása felhasználói követelmények rendszerkövetelmények szoftverterv-specifikáció A követelmények osztályozása: Ø   felhasználói követelmények: azt specifikálják, hogy a rendszernek milyen szolgáltatásai legyenek majd, és ezek a szolgáltatások hogyan, milyen körülmények között, milyen elvárásokkal működjenek. A felhasználói követelmények tehát a szolgáltatásokat, a funkcionalitást jelentik. Például egy tanulmányi rendszertől követelményként elvárjuk, hogy lehessen benne órarendet meghirdetni, vizsgát meghirdetni, tantárgyat felvenni, törölni, jegyet beírni, előfeltételeket, diplomakövetelményeket lekérdezni stb. Elvárjuk, hogy a rendszer automatikusan tudja kezelni ezeket a fogalmakat. Ø   rendszerkövetelmények: azok a követelmények, amelyek általában, globálisan a rendszer egészére vonatkoznak, melyek függetlenek az egyes szolgáltatásoktól, konkrét szolgáltatástól független követelmények. Szoktak belső (immanens, eredendő) követelményeiről beszélni (az információs rendszer követelményei): pl. hozzáférhetőség, bizonságosság, válaszidő, társzükséglet stb. A rendelkezésre állás nyilván független attól, hogy milyen szolgáltatást nyújt a rendszer, el kell tudni érni éjjel-nappal. Egy tanulmányi rendszertől azt várjuk el, hogy az év minden percében rendelkezésünkre álljon. Természetesen az eredendő rendszerkövetelményeken túl lehetnek speciális rendszerkövetelmények. Ø   szoftverterv-specifikáció: a követelmények meghatározásánál egy harmadik követelménycsoport a felhasználói és rendszerkövetelmények mellett. Ez általában kiegészítése a rendszerkövetelmény specifikációnak, ez a kifejlesztendő szoftvernek egy absztrakt specifikációja, amely majd a tervezési fázis alapjait szolgáltatja. A követelmények felosztása talán világosabbá válik, ha azt nézzük meg, hogy az egyes követelmények kiknek szólnak, az egyes követelményekkel elsősorban kiknek kell találkozniuk.

38 A követelmények osztályozása
funkcionális követelmények: hogyan reagál a rendszer bizonyos inputokra, bizonyos bekövetkező szituációkra, teljes és ellentmondásmentes nem-funkcionális követelmények szakterületi követelmények

39 A követelmények kiknek szólnak
A felhasználói követelményekkel elsősorban a fejlesztői oldali és a megrendelő oldali menedzserek találkoznak. A rendszerkövetelményekkel a rendszerfejlesztők, az informatikusok találkoznak. A szoftverterv specifikáció nyilvánvalóan a szoftver tervezőinek alapvető fontosságú.

40 Követelmények másik felosztása
funkcionális követelmények: hogyan reagál a rendszer bizonyos inputokra, szituációkra, kivételek feltárása nem-funkcionális követelmények: általános, teljes rendszerre vonatkozik szakterületi követelmények

41 Nem funkcionális követelmények
termék- szervezeti külső hatékonysági használhatósági megbízhatósági hordozhatósági telepítési implementációs szabány- együttműködési etnikai törvényi adatvédelmi biztonsági teljesítmény tárterület A nem-funkcionális követelményeknek három nagy csoportjáról szoktunk beszélni, a részletezés nem teljes, inkább csak példaként szolgál. A felsorolt követelmények eredendő rendszerkövetelmények. Ø   termékkövetelmények: a szoftverre vonatkozó követelmények szervezeti követelmények: azon szervezet követelményei, amelyek a szoftver működtetési környezetét jelentik, az adott szervezetből következnek, nem a szoftverből o   a szabványkövetelményekben elő lehet írni olyat, hogy a megrendelő pl. ISO-szabványnak megfelelő fejlesztést kér, vagy belső szabvány, általában dokumentálást jelent o   implementációs követelmény lehet, hogy milyen szoftvereszközzel történjen a fejlesztés; ez nagyon kemény nem-funkcionális követelmény o   telepítési követelmények azt adják meg, hogy milyen platformra vagy platformokra történjen a fejlesztés Ø   külső követelmények: a legnyűgösebb dolog, a szervezeten kívüli követelmények o   együttműködési követelmények: az adott szoftver nem az adott cégnek egy önálló szoftvere lesz, hanem a cég beleilleszkedik egy politikai, társadalmi, kulturális környezetbe, ahol természetesen már működnek rendszerek, és ebben a külső, szervezeten kívüli rendszerkörnyezetben kell a konkrét szoftvernek működnie. Például egy tanulmányi rendszernek együtt kellene működnie az országos felvételi rendszerrel. o   törvényi követelmények: az adott jogszabályi követelmények között kell működnie a rendszernek. o   etikai követelmények: pl. ugyan törvények nem tiltják, de egy kemény etikai követelmény, hogy a Neptunon keresztül politikai levelet ne küldjenek... A nem-funkcionális követelmények összegyűjtése nagyon kemény kérdés, itt szokták nagyon elszórni a követelményeket, nem kerül rájuk kellő hangsúly. Ahogy megyünk balról jobbra az ábrán, egyre kevésbé. A nem-funkcionális követelmények feltárása nagyon rossz szokott lenni. A nem-funkcionális követelmények nagy problémája az, hogy ezeket a követelményeket gyakran nagyon nehéz egyértelműen feltárni, megfogalmazni. Ráadásul mivel nincs egyértelmű megfogalmazás, ez rögtön implementálási gondokhoz vezet, ugyanis a programozó a könnyebb ellenállás irányába megy, úgy értelmezi a dolgokat, ahogy szeretné, és akkor nem kell programoznia semmit. Aztán meg majd ha jön a validáció, előjönnek a problémák a nem egyértelmű megfogalmazás miatt: mit lehet érteni egy követelmény alatt, és valójában az alatt mást értünk. Erre a problémára lenne megoldás a nem-funkcionális követelmények számszerűsítése metrikák megadásának segítségével. Van, amire könnyű metrikát adni (tárterület, sebesség, maximális válaszidő), viszont vannak nagyon nehezen mérhető követelmények (használhatóság, robusztusság). A nem-funkcionális követelmények másik nagy problémája, hogy gyakran ellentmondanak a funkcionális követelményeknek. Az egyik örök ellentét a válaszidő (funkcionális) és a tárméret (nem-funkcionális).

42 A funkcionális és nem-funkcionális követelmények elválasztása
ha együtt kezeljük, túl nagy lesz a specifikáció, nem veszünk észre bizonyos követelményeket; validációnál a bonyolultság miatt bizonyos követelmények elsikkadhatnak. ha külön kezeljük, akkor nehéz az ellentmondások felderítése

43 Követelmények dokumentációja
természetes nyelv diagramok (UML) leíró nyelvek: programnyelvekhez hasonló matematikai specifikáció hibrid megoldás A rendszerkövetelmények megadásához nagyon gyakran rendszermodelleket használnak. Ezek a modellek grafikus reprezentációk; diagram segítségével adják meg a rendszerkövetelményeket. Ezek szolgálnak dokumentációként a tervezéshez, hangsúlyozván, hogy a rendszermodellek minden esetben absztakciók. Ezek segítik formalizálni a követelményeket, képeznek egy hidat a felhasználó és a fejlesztő között.

44 Rendszermodellek környezeti modellek (HOL)
viselkedési modellek (HOGYAN) adatmodellek (MIVEL) A rendszermodellek három különböző szempontból próbálják közelíteni a rendszerspecifikációkat: Ø   környezeti modellek: kívülről közelítenek; azt a környezetet modellezik, amelybe bele kell helyezni a rendszert (HOL dolgozik a rendszer?) Ø   viselkedési modellek: belülről közelítenek, de a rendszer viselkedését helyezik a középpontba (HOGYAN dolgozik a rendszer?) adatmodellek: belülről közelítenek, középpontjukban a rendszer, és az általa feldolgozott adatok struktúrája áll (MIVEL dolgozik a rendszer?)

45 Igénybevételi adatbázis
Környezeti modellek A rendszer határainak felderítése biztonsági rendszer bankautomata karbantartó központi nyilvántartór. számlázór. számla- adatbázis Igénybevételi adatbázis A környezeti modell nem mond semmit magáról a rendszerről belülről, de nem mond semmit a rendszer és a környezet között fennálló viszonyokról sem, azon felül, hogy kapcsolat van közöttük. Hogy milyen jellegű a kapcsolat, milyen kommunikáció, milyen befolyás, milyen viselkedés, arról nem. Ez a modell tehát statikus környezetleírásra szolgál.

46 Viselkedési modellek adatfolyam modellek: tipikus struktúrált modellek
állapotátmenet modellek: tipikusan OO- modellek (adatfolyam modell az OO-ban nincs)

47 Adatfolyam modellek Az adatfolyamok hogyan mozognak, hogyan áramlanak a rendszeren belül, hogyan kerülnek feldolgozásra. Jelölések: ellipszis: feldolgozás, ezek egy-egy függvénynek tekinthető, amely a beérkező adatokból legenerálja a kimenetet és továbbítja. Nyíl: az adatáramlás irányát jelölik, az adatok milyensége a nyilakra van írva. Téglalap: adattárolók; ezek állományok, adatbázisok; itt megőrzésre kerülnek az adatok és újra elővehetők. Előnye az adatfolyam modellnek, hogy viszonylag könnyedén ráhúzhatók a hétköznapi folyamatokra, tehát intuitívek, a felhasználó könnyen megérti. A probléma, hogy rajzolunk, bizonyos bonyolultság után struktúrálni, tagolni kell.

48 Adatfolyam modell példája
kitöltött megrendelő űrlap megrendelés validálása megrendelés rögzítése továbbítás szállítóhoz költségkeret módosítása megrendelés-állomány költségvetés-állomány megrendelés részletei + üres megrendelő űrlap kitöltött megren- delő űrlap aláírt megren- megrendelés részletezése végösszege + számla rögzítése átvizsgált és

49 Állapotátmenet modell
A formális automata, mint absztrakt matematikai eszköz megjelenése a formális rendszerfejlesztésben. Ha túl bonyolult a rendszer, bizonyos állapotokat metaállapotnak tekintve külön állapotátmenet diagramon ki lehet fejteni.

50 Adatmodellek Az adatok struktúráját írják le, az egyedek tulajdonságait, és az egyedek közötti kapcsolatokat modellezik. Ezen modellek vezetnek az objektum modellek kialakulásához a 90-es évek elején. ETK, ER, OO adatmodellek

51 ER adatmodell 3 fő komponense van: egyed kapcsolat tulajdonságok A T

52 Egyed elem az ER-ben Egyed: egy objektum típus, egy a külvilág többi részétől egyértelműen megkülönböztetett dolog önálló léttel bír amikről az információkat tárolni kivánjuk Típusai: normál egyed (önmagában azonosítható): dolgozó, autó gyenge egyed (más egyedhez való kapcsolatán keresztül azonosított): dolgozó felesége, autó lámpája egyed neve egyed neve normál egyed gyenge egyed

53 Kapcsolat elem az ER-ben
opcionális: létezhet olyan egyed- előfordulás, melyhez nem kapcsolódik egyed-előfordulás a kapcsolatban kötelező: minden egyed-előforduláshoz kell kapcsolódnia egyed-előfordulásnak a kapcsolatban A B opcionális kötelező az A oldalon

54 Kapcsolat elem az ER-ben
ország - főváros tulajdonos - autó A B 1:1 1:N egy A-hoz több B színész - színdarab N:M

55 Tulajdonság elem az ER-ben
normál: egyértékű ember.szülidő kulcs: azonosító szerepű ember.TAJszám összetett: több tagból áll ember.lakcim (irsz,varos) többértékű: több értéke is lehet, ember.hobby származtatott: értéke kiszámítható ember.életkor t t t normál többértékű t t összetett t t kulcs származtatott

56 KÖVETELMÉNYTERVEZÉS Amelynek során előáll a követelmény- dokumentum, és ez szolgál majd a tervezés alapjául dokumentumként. Alfolyamatai: megvalósíthatósági tanulmány elkészítése követelmények feltárása, elemzése követelmények specifikálása és dokumentálása követelmények validálása

57 Követelménytervezés folyamata
megvalósíthatósági tanulmány követelmények feltárása, elemzése követelmények specifikálása követelmények validálása megvalósíthatósági jelentés rendszer- modellek felhasználói és rendszerkövetelmények követelmények dokumentumai A rendszerfejlesztés egy folyamat. A folyamat lépésekből áll, minden egyes lépés előállít egy eredményt, egy közbenső terméket. A folyamat lépéseit jelöljük ellipszissel, a folyamat eredményét téglalappal, a nyilak jelzik az átmenetet a lépések és a közbenső termékek között.

58 Megvalósíthatósági tanulmány / jelentés
A rendszer nagyvonalú leírását tartalmazza, ez alapján döntjük el, hogy egyáltalán elindul-e a folyamat. A kifejlesztendő rendszer támogatja-e az adott szervezet általános célkitűzéseit, munkáját, igényeit? Megvalósítható-e a megfogalmazott időkeret, költségkeret és technológiai keretek között? (alternatívák) Integrálható-e, beilleszthető-e a jelenleg használatban lévő rendszerbe? A megvalósíthatósági tanulmány előállításához információt kell beszerezni. Egyrészt meg kell tudni, hogy kitől/kiktől szerezhető be, másrészt be kell szerezni. Ez annyit jelent, hogy a vízió megbízójával kell konzultálni.

59 Követelmények feltárása, elemzése
szakterület megismerése követelmények összegyűjtése ellenőrzése osztályozása fontossági sorrendbe állítás ellentmondások feloldása specifikációja követelmények dokumentációja a folyamat belépési pontja Azokat a személyeket, akik valamilyen módon kapcsolatba kerülnek majd a rendszerrel (végfelhasználókat, főnököket, menedzsereket, rendszergazdákat stb.), kulcsfiguráknak nevezzük. A követelmények feltárása és elemzése a kulcsfiguráktól beszerzett információk feltárását és elemzését jelenti. Az ábrán a követelmények feltárásának folyamata látható. Ez egy iteratív folyamat, melyben minden lépés összefügg az összes többivel, iterálható. A megvalósíthatósági tanulmány után ennek eredményeképp megszületik a követelménydokumentáció. A követelmények specifikálása megakadhat a követelményellenőrzésnél, erről még külön beszélünk. -Szakterület megismerése: az informatikus, a fejlesztő kénytelen megismerkedni az adott szakterület fogalmaival, absztrakcióival, szokásaival. Lényeges, hogy a követelményeket a megrendelő és a fejlesztő együtt tárják fel olyan értelemben, hogy a megrendelő adja az összes információt, a többi a fejlesztő dolga. Nem várhatjuk el ugyanis, hogy a megrendelő az általa használni kívánt, kifejlesztendő rendszer specifikációját megadja. -követelmények osztályozása: a követelményeket kategorizálni kell. Ez a kategorizálás majd alapvetően befolyásolja a tervezést és a megvalósítást, illetve segít a következő két lépés megtételében (az ellentmondások feloldásában és a követelmények fontossági sorrendbe állításában). -Ellentmondások feloldása: az ellentmondásokat fel kell oldani valamilyen módon. Ez nyilvánvalóan visszacsatolást és újraindulást jelent. -fontossági sorrendbe állítás: több szempontból is fontos. Miután már elviekben van egy ellentmondásmentes, kategorizált követelményrendszerünk, ott prioritásokat kell felállítani, mert ez egyrészt befolyásolhatja a további tervezést és implementálást, másrészt befolyásolhatja az időbeli ütemezést, a pénzeszközök elosztását. -követelmények specifikációja, dokumentációja -követelmények összegyűjtése

60 Követelmények feltárása -problémák
Nem tudják, mit várnak a rendszertől (vagy megfogalmazás problémája). Triviális, vagy megoldhatatlan elvárások Kommunikáció a fejlesztővel, ellentmondások feloldása Külső körülmények, pl. vállalati politika

61 Követelmények összegyűjtése
prototípus-készítés nézőpont-orientált feltárás forgatókönyv-technika (interakciók) eseményforgatókönyvek használati esetek (OO) etnográfia nézőpont-orientált feltárás (közepes nagyságú rendszereknél). Ennek a technikának a középpontjában az áll, hogy az egyes kulcsfigurák más-más oldalról szemlélik a kifejlesztendő rendszert, más-más követelményeik, prioritásaik vannak; más nézőpontokat képviselnek. Általánosan egy forgatókönyv a következő információkat tartalmazza: – kezdő rendszerállapot leírása (a rendszernek az az állapota, amely a forgatókönyv leírásának elején van) – események leírása (a forgatókönyv, az interakciók eseményeinek leírása) ­– a kivételes események leírása – az adott eseményekkel párhuzamosan zajló események leírása – a rendszerállapot leírása az interakció lezajlásának végén Az etnográfia megfigyelésen alapuló technika. Ez a technika vissza fog térni a rendszerfejlesztés más fázisaiban is. A megfigyelésen alapuló követelményfeltárás annyit jelent, hogy a követelményelemző behelyezi magát a környezetbe, ahol a rendszert használni fogják, nem beszélget, nem kommunikál a kulcsfigurákkal, hanem nézi őket.

62 Követelmények ellenőrzése
a felhasználók és a fejlesztők együtt végzik, lépései: ellentmondásmentesség a teljes dokumentációra teljességellenőrzés megvalósíthatóság verifikálhatóság

63 Validációs technikák felülvizsgálat prototípuskészítés
tesztesetek generálása automatikus validálás (CASE eszközök)

64 Követelmények menedzselése
Környezeti változások  követelmény- változások automatizált dokumentációs eszközökkel: követelmények azonosítása változtatáskezelés nyomonkövethetőség

65 Prototípuskészítés, előnyök
Eldobható prototípuskészítés Evolúciós prototípuskészítés folyamatosan felhasználható a felhasználók képzésére megerősítő tesztek futtatására a termék hamarabb piacra dobható felhasználók hamarabb válnak elkötelezetté

66 Prototípuskészítés, hátrányok
az emberek cserélődhetnek a cégnél karbantartási problémák (rossz struktúráltság) nehéz jó fejlesztői szerződést kötni a változások miatt

67 TERVEZÉS Architekturális tervezés: szoftverarchitektúra leírást eredményez, a szoftver struktúráját írja le. Tervezéskor implementációs problémákat is figyelembe kell vennünk. Kiindulópontjai az alrendszerek

68 Alrendszerek, modulok Az alrendszer egy olyan létjogosultságokkal rendelkező része a rendszernek, amelynek működése nem függ az egyéb alrendszerek szolgáltatásaitól. Kommunikációjuk interfészeken keresztül történik. A modulok nem önállóak az alrendszeren belül. A modulok mérete alapján kétfajta rendszerről beszélhetünk: Ø   finom szemcsézettségű rendszer: a rendszer alrendszereiben a modulok kicsik Ø   durva szemcsézettségú rendszer: a rendszer alrendszereiben a modulok nagyok Például egy felsőoktatási intézményben az alábbi alrendszerek különböztethetők meg: Ø   gazdasági alrendszer, Ø   tanulmányi alrendszer, Ø   humánerőforrás alrendszer stb. Például a tanulmányi alrendszeren belül a következő modulok lehetnek: Ø   órarendkészítő modul (viszonylag nagy modul; általános órarendkészítő algoritmus nem létezik) Ø   felvételit intéző modul

69 Architekturális terv – nem funkcionális rendszerkövetelmények
Teljesítménykritikus rendszer – kritikus műveletek kevés modulban Védelem – rétegzett architektúra Biztonságosság – biztonságkritikus műveletek egy, vagy kevés helyen Rendelkezésre állás – redundás rendszerelemek Karbantarthatóság – könnyen módosítható, kis modulok Nyilvánvalóan ezek a szempontok egymásnak gyakran ellentmondanak. Ilyenkor kompromisszumot kell kötni, a követelményeknél felállított prioritásokat figyelembe kell venni, és a felhasználókkal konzultálva a kompromisszumokat meg kell kötni, elsősorban a finom és durva szemcsézettség, illetve bizonyos architektúra modellek esetén.

70 Alrendszerek információtárolási modelljei
közös, megosztott adatbázis: ugyanazt az információegyüttest használják az alrendszerek minden alrendszernek külön adatbázis (valódi kommunikáció)

71 Megosztott adatbázis jellemzői
minden alrendszernek azonos adatmodell (de nehézkes módosítás) Információ kell arról, hogy az adatot ki, hogyan használja fel Egyszerűbb biztonsági problémák, mentés, védelem, konzisztencia

72 Architektúra-modellek
kliens-szerver modell (elosztott architektúra), elosztott rendszereknél célszerű rétegezett modell (több rétegből álló struktúra), inkrementális modellhez illeszkedik

73 Vezérlési modell Alrendszerek és modulok együttműködéséhez
Központosított: egy kitüntetett alrendszer koordinálja a többit (szekvencális, vagy párhuzamosnál szinkronizált működésű) Eseményvezérelt

74 Eseményvezérelt modellek
Eseményszórás: az egyes elemek regisztrálják magukat bizonyos eseményekre. Probléma: nem tudhatja egy alrendszer, hogy hány másik reagál ugyanarra az eseményre. Eseménymegszakítás: operációs rendszer megszakításkezelése alkalmazásszinten – eseménymegszakítás: az operációs rendszer megszakításkezelése jön fel alkalmazás szintre. Eseménytípusok vannak, mindegyik eseménytípushoz tartozik egy eseménykezelő, és ha az adott esemény bekövetkezik, akkor a hozzá tartozó eseménykezelő aktivizálódik. Az eseménymegszakítási modell előnye: egyértelmű reakció van, nincsenek különböző reakciók más-más alrendszerektől, moduloktól;

75 Modultervezés struktúrált módszertan: a modulokat egy adatfolyam modell alapján tervezzük meg. OO-szemlélet: az alrendszereket objektumokká bontjuk szét az objektumok tulajdonságaival Az alrendszerek modulokra bontása. Az alrendszerek a követelmények elemzéséből következnek, a modulok nem következnek a követelményekből, szerepük ténylegesen a tervezésben jön el. Struktúrált módszertan: Az alrendszereket ezzel a szemlélettel olyan modulokká bontjuk szét, ahol minden modul egy-egy jól definiált adatleképezési funkcióval rendelkezik. Az adatfolyam szemléletnek megfelelően ezek a modulok a működés szempontjából szekvenciát, csővezetéket alkotnak. Ezzel egy adattranszformációs modulegyüttest tervezünk meg. OO: Tervezéskor ne foglalkozzunk a konkurenciával, a szoftver működésében megjelenő párhuzamosság legyen az implementáció kérdése. A tervezési szinten nincs konkurencia. Majd az implementálás során a környezettől, platformtól függően lehet a modulokat konkurens vagy szekvenciális módon implementálni. Az utóbbi időben nyilván az OO-szemlélet erősödik fel, a divatos módszertanok objektumokban gondolkodnak. Az OO-modell jellegénél fogva absztaktabb, egy objektumorientált szemléletű felbontás jobban támogatja az újrafelhasználhatóságot, a konkurens implementálás könnyebb.

76 Szakterületspecifikus architektúrák
általános szakterületi architektúra referencia-architektúra általános szakterületi architektúra: az adott szakterületen meglévő konkrét alkalmazások közös architektúrájaként jelenik meg. Vannak konkrét alkalmazások, ezekben közös architektúrát emeljük ki egy közös architektúrába. Tehát ez egy ipari szabvány jellegű architektúra, alulról felfelé alakul ki, a meglévő rendszerekből általánosítjuk. referencia-architektúra: felülről lefelé kialakuló szakterületi absztrakció. A referencia-architektúrák nem arra valók, hogy visszaköszönjenek a konkrét alkalmazásokban, hanem elsősorban arra valók, hogy a konkrét alkalmazásokat hozzájuk lehessen hasonlítani, és ezzel egy értékelési lehetőséget nyújt, ezért hívják referencia-architektúrának. A referencia-architektúrák analóg módon a de jure szabványokhoz hasonlítanak, vagy netán azok. Bizonyos gazdasági területeken vagy pl. a társadalombiztosítás területén vannak referencia-architektúrák. Például: az ISO-OSI (Open System Interconnection) nyílt hálózatösszekapcsolási szabány egy referencia. Ez 1980-ban nagy szabványként jön létre. Nincs olyan rendszer, amely

77 A fordítóprogram architektúrája
szimbólumtábla lexikális elemzés szemantikai elemzés szintaktikai elemzés kód-generálás Általános szakterületi modellnek tekinthető a fordítóprogram architektúrája Ez egy adatfolyam modell (nyilván OO-ról ekkor nem lehetett beszélni), ahol a modulok a lexikális, szintaktikai és szemantikai elemző valamint a kódgeneráló, és a szimbólumtábla mint általános adattároló. Jelen pillanatban is automatikus fordítóprogram-generáló eszközök állnak rendelkezésre ezzel az architektúrával. Megadjuk a nyelvtant, a végén automatikusan, automatizáltan kijön a fordítóprogram ezen architektúra segítségével. Ez úgy alakult ki, hogy megírták az első párezer fordítóprogramot és kiderült, hogy fordítóprogramot így kell írni, a fordítóprogramíró alkalmazásnak ez az architektúrája.

78 Tervezés újrafelhasználással
alkalmazkodó újrafelhasználás: implementálás közben fedezzük fel az elemeket és illesztjük be a programba. módszeres újrafelhasználás: a tervezést eleve így képzeljük el Az újrafelhasználható komponensek mérete nagyon eltérhet egymástól. Méret szerinti osztályozásuk: o   teljes alkalmazási rendszerek (lásd: alkalmazáscsaládok) o   alrendszerek, modulok o alprogramjellegű elemek: ennek felhasználásával indulhat el az újrafelhasználás kérdése, nyilván programozásnál először alprogramokat használtunk fel újra.

79 Tervezés újrafelhasználással - előnyök
Megbízhatóság Alacsony kockázat Szabványos komponensek (pl. GUI) Rövid tervezési, fejlesztési, tesztelési idő

80 Tervezés újrafelhasználással - problémák
Meg kell találni őket Megbízhatóság Dokumentáltság Nagyobb karbantartási költség (komponensek evolúciója, megszűnése)

81 Komponens-orientált tervezés
A komponens egy önálló, végrehajtható entitás, amely valamilyen szolgáltatást nyújt más komponenseknek vagy más szoftvereknek. A komponensnek minden esetben van egy interfésze, és a vele történő minden interakció ezen az interfészen keresztül megy végbe. A mai értelemben vett komponens az OO-világból nőtt ki, de nincs mögötte OO, nincs bezárás stb. Az interfészen keresztül a komponenshez parametrizált hívásokkal tudunk hozzáférni, de a komponens belső állapota nem ismert.  A komponens-orientáltságról és erről a komponens fogalomról a 90-es évek második fele óta beszélnek.

82 A rendszer/komponens interfésze
rendszer vagy másik komponens a rendszer szolgáltatásokat vár, keresendő a komponens, ami ezeket nyújtja. Az interfésznek két oldala van: a komponens oldali interfész, melyen keresztül az ő általa nyújtott szolgáltatások elérhetőek, valamint a másik oldali interfész, amelyet a rendszer vagy a másik interfész publikál az általa igényelt szolgáltatásokhoz. Nyilvánvalóan ha a nyújtott és elvárt szolgáltatások megegyeznek, az interfész illeszkedik, a komponens jó, különben nem jó. A komponens-orientáltság röviden annyit jelent, hogy van a rendszerünk, amely szolgáltatásokat vár, meg kell keresni azokat a komponenseket, amelyek nyújtani tudják az elvárt szolgáltatásokat, és összeillesztjük a rendszerrel. Ez a komponens-orientáltság az első lépés a szoftverek környékén afelé, hogy valódi újrafelhasználhatóságról lehessen beszélni, ennek segítségével kicserélhető, kompatibilis dolgokat tudunk létrehozni óta komponens-alapú fejlesztésről beszélünk, és komponens-alapú technológiák módszertanok jönnek létre.

83 A komponensek absztrakciós szintje
funkcionális absztrakció lazán összefüggő entitások adatabsztrakció klaszterabsztrakció rendszerabsztrakció funkcionális absztrakció: a komponens egyetlen funkciót valósít meg, egyetlen szolgáltatása van, az interfész maga a szolgáltatás lazán összefüggő entitások: ekkor az interfész az entitások neveit tartalmazza, például egy függvénygyűjtemény, vagy egy típusgyűjtemény, vagy generikus könyvtár stb. adatabsztrakció: ez tulajdonképpen egy absztrakt adattípus implementációját jelenti, tipikusan egy OO osztályt. Ekkor az osztály metódusainak specifikációja vagy az absztrakt adattípus műveletei adják az interfészt. klaszterabsztrakció: absztrakt adattípusok egy rendszere, tipikusan egy osztályhierarchia. Ezt hívják keretrendszernek egyes irodalmak, cégek, és nagyon gyakran ezt hívják komponensnek. rendszerabsztrakció: a komponens nyilván ekkor a legnagyobb, egy teljes rendszer, az interfésze egy API.

84 A komponens-orientált tervezés folyamata
rendszerarchitektúra tervezése komponensek meghatározása újrafelhasználható kom-ponensek megkeresése felderített kompo-nensek egyesítése Tipikusan követő modell, mert ha nem találunk meg minden komponenst, akkor fejleszteni kell.

85 A komponens-orientált tervezés folyamata #2
vázlatos rendszer-követelmények újrafelhasználható kom-ponensek megkeresése követelmények módosítása a felderített komponenseknek megfelelően architekturális terv a rendszer megtervezése az újrafelhasz-nálható koponenseknek megfelelően már a tervezés előtt keressük a komponenseket kompromisszum: követelménymódosítás

86 Alkalmazási keretrendszerek
infrastruktúra keretrendszerek: pl. a felhasználói felületek legyártásához köztes termék keretrendszerek (middleware): információcsere, pl. Corba alkalmazásszintű keretrendszerek: szakterületi alkalmazások, pl. CMS, ERP Az OO világ túl statikusnak bizonyult->építsünk osztályhierarchiákból komponenseket.

87 Az újrafelhasználásra alkalmas komponens:
stabil szakterületi absztrakción alapul bezárást, reprezentációt valósít meg ideális esetben független más komponensektől a komponens kivételei az interfészben, a felhasználó kezelheti A komponens világban ellentmondás van az újrafelhasználhatóság és a használhatóság között. Minél általánosabb az újrafelhasználhatóság, minél magasabb absztrakciós szintű, azaz minél jobban újrafelhasználható komponenseket követelnek, annál jobb, de nem biztos, hogy használható is.

88 Alkalmazáscsalád (product-line)
Általában közös és szakterületspecifikus architektúrát valósít meg (architektúra újrafelhasználás) platformspecializáció konfigurációspecializáció funkcionális specializáció platformspecializáció: ugyanannak az alkalmazásnak különböző verziói különböző platformokra készülnek. Az architektúra ugyanaz, a platform más. konfigurációspecializáció: az Enterprise (nagyvállalati) szinttől a Personal (személyi) szintig ugyanaz az alkalmazáscsalád, ugyanazon a platformon nagyon nagy, illetve kicsi konfiguráción is fut. funkcionális specializáció: a követelmények térnek el az egyes alkalmazások között. Például van egy órarendkészítő alkalmazás, akkor ennek egy verzióját kell alkalmazni a közoktatásban és egy másik verzióját a felsőoktatásban. Az alkalmazáscsaládok esetén az architektúrát úgy kell megtervezni, hogy az valóban újrafelhasználható legyen, az előbbi specializációknak megfelelően a platformfüggő, konfigurációfüggő, funkcionalitásfüggő részeket ki kell emelni az architektúrából és külön kell kezelni. A funkcionalitást el kell választani az erőforrásoktól és a felhasználói hozzáféréstől, és ezeket külön kell kezelni.  Az alkalmazáscsalád általában egyetlen alkalmazásból fejlődik ki, mert kiderül, hogy az alkalmazás az adott szakterületen jól alkalmazható. Ekkor jön az, hogy az alkalmazás architektúrája vagy olyan, hogy alkalmazáscsalád építhető rá, vagy újra kell tervezni.

89 Tervezési minta Terv-újrafelhasználási elem, implementációfüggetlen. Pl: az absztrakt adatszerkezet az algoritmusoknál. Leírja a problémát, a megoldását, az újrafelhasználhatóságot.

90 Szolgáltatás-orientált architektúra (SOA)
ObjektumKomponensSzolgáltatás A szolgáltatás egy zárt, független üzleti függvény, amely képes egy vagy több kérés fogadására és egy vagy több válasz generálására egy jól definiált interfészen keresztül. Speciális fajtája a webszolgáltatás.

91 Webszolgáltatás Emeli az absztrakciós szintet, elfedi hogy mi van mögötte, csak interfészen keresztül érjük el, a kommunikáció eszköze az XML XML alkalmazásokat képeznek le programokra, objektumokra, adatbázisokra vagy üzleti függvényekre Az interfész mögött jellemzően adatbázis- kezelő-rendszer van A webszolgáltatás egy szabványos interfészen keresztül kap XML dokumentumot.

92 Interakciós technikák
RPC (Remote Procedure Call) – online-alapú, szinkron szolgáltatás; egy kérés egyetlen XML dokumentum továbbítását jelenti, ez egyetlen háttérelemre képezendő le, amely azonnal le is fut, mint egy távoli eljáráshívás. dokumentumorientált technika – batch, aszinkron szolgáltatás; az XML dokumentumot nem leképezni kell, hanem feldolgozni a webszolgáltatás a W3C szabványokon alapul

93 A SOA webservices eszközei
XML: szöveges dokumentumkódolási szabályok WSDL: szolgáltatásleíró nyelv, leírja az üzenettípusokat, az interfészt SOAP: a webszolgáltatások kommunikációjának protokollja (XML) UDDI: a szolgáltatás közzétételének, megosztásának eszköze XML Web Service Definition Language Simple Object Access Protocol Universal Description Discovery and Integration

94 Felhasználói felületek tervezése
interfész-orientált tervezés: egy prototípusnál a felhasználó hogyan tud kapcsolatba kerülni az alkalmazással Jellemző a GUI, szokásos elemek, skinek, stb. Ergonómiai szempontok: RTM, olvashatóság, színtévesztés, stb.

95 Felhasználói felületek megtervezésének elvei
felhasználói jártasság konzisztencia minimális meglepetés elve visszaállíthatóság elve (undo) felhasználói támogatás felhasználói sokféleség elve felhasználói jártasság: nem szabad egy felületet azért adni egy felhasználónak, mert azt könnyű implementálni, hanem a felhasználó számára megszokott terminológiát használni, megszokott és az alkalmazás környezetével összhangban lévő objektumoknak kell megjelenni a felületen. Ismerős, megszokott környezetbe kell vinni a felhasználót akkor is, ha ez új alkalmazás számára. Konzisztencia: ha egy menüben az utolsó a kilépés menüpont, akkor minden menüben utolsó legyen a kilépés; ha azt szokjuk meg egy felhasználói felületen, hogy kétszer kell kattintani, ahhoz, hogy elfogadásra kerüljön, akkor kétszer kelljen kattintani mindenhol. felhasználói sokféleség elve: Van, aki az egeret szereti, van, aki a gyorsbillentyűket, van, aki az ablakos környezet szereti, van, aki a parancssorosat

96 Felhasználói interakciók
közvetlen manipuláció menüpont kiválasztása űrlapkitöltés parancsnyelv emberi nyelvű vezérlés

97 Információmegjelenítés kérdései
mit akarunk megjeleníteni? mi a lényeges a felhasználó számára? csak látni akarja, vagy interakcióba lépni is vele? Diszkrét / analóg megjelenítés kérdése mit akarunk megjeleníteni? numerikus vagy nem numerikus információt? mi a lényeges a felhasználó számára a numerikus információval kapcsolatban? az abszolútértéke? az, hogy változik? vagy az, hogy hogyan változik? analóg megjelenítés: pl. állapotjelző csík, százalékos arányban látható, hogy hol tart a folyamat; ilyenek még mindenféle grafikus megjelenítési formátumok; relatív értékek megjelenítése Szöveges megjelenítésnél a kérdés az, ha nagyobb terjedelmű a szöveg, akkor benne bizonyos kiemelések eszközölendők: Ø   betűtípus, Ø   szín, betűméret stb.

98 A felhasználói felületek ergonómiája
Felhasználóbarát felületek (webes megjelenés) Letöltési idő Egyszerű, következetes navigáció, átláthatóság (térkép), szemmozgás, stb. Akadálymentesség Megfelelő színek, színpárok, kontraszt

99 Ergonómia – felhasználói szokások
A felhasználók egy idő után mindent megszoknak.. (pl. Microsoft-Apple) A felhasználó már megszokott egy sémát, akkor elvárja azt az újtól is Amit nem talál meg, az a funkció nem létezik (There is no spoon..)

100 Színek, színhasználat Konzervatív, kevés szín használata (felhasználási területtől függően) Funkcionális használat: kiemeléshez, állapotváltozás jelzéséhez más szín Színek – érzelmi hatások Színhűség, webbiztos színek – a megnyugtató színek a pasztel színek – a mi kultúránkban a vörös szín veszélyt vagy tiltást jelent – a kék egy hideg, rideg szín

101 Felhasználói támogatás
Jellemzően szövegesek, ill. illusztráltak Helyzetérzékeny súgó, online súgó Segítség a kezdőknek és a tapasztaltaknak: segítségkérés és informálódás, visszajelzés Informatikai hibaüzenetek elrejtése, becsomagolása Többnyelvűség, honosítás Gráfrendszer, többféle navigáció, belépési pont

102 Felhasználói dokumentáció
rendszer- értékelők rendszeradmi-nisztrátorok kezdő felhasználók tapasztalt felhasználók funkcionális leírás telepítési dokumentáció bevezető kézikönyv referencia kézikönyv adminisztráto-rok útmutatója szolgáltatá-sok leírása Hogyan telepítjük a rendszert? kezdeti leírások eszközök leírása működtetés és karbantartás A felhasználói dokumentáció elemei középen találhatók, felettük az, hogy kinek szólnak, alattuk pedig az, hogy mit tartalmaznak. A funkcionális leírás egy rövid leírás, amely a főnöknek, a döntéshozónak szól, aki ezek alapján el tudja dönteni, hogy érdekli-e a szoftver vagy sem. Informatikai részleteket nem tartalmaz, kívülről, felülről írja le, szemléli a szoftvert, annak tulajdonságait, funkcióit (mire való a szoftver?). Telepítési dokumentációnak a legkisebb szoftvernél is lennie kell. Ebben leírjuk, hogy milyen hardver és szoftverkövetelményei vannak a szoftvernek, milyen formában kapja meg a megrendelő, hogyan jut el odáig, hogy a saját rendszerén telepítse a szoftvert, hogy használható legyen. A kézikönyv a végfelhasználóknak szóló, a napi munkát segítő nagyon részletes dokumentáció. Nyilvánvalóan informatikai oldalról is sok információt tartalmaz. Ez tulajdonképpen egy receptgyűjtemény, amely a funkciók mentén részletesen leírja a rendszer működését, beleértve az összes rendszerüzenetet, amelyet a végfelhasználó kaphat és az ezekre adható lehetséges válaszokat. Adminisztrátori útmutató, amely a rendszeradminisztrátoroknak szól, nem a végfelhasználóknak. Ez kimondottan informatikai oldalról nézi a rendszert, konfigurációról, rendszeradaptációról, -továbbfejlesztésről szól, és belülről szemléli a rendszert.

103 Felhasználói felületek értékelése
Tanulhatóság Interakciósebesség Robusztusság Visszaállíthatóság Adaptálhatóság A felhasználói felületek értékelésénél az informatikusokon kívül illene bevonni pszichológusokat, vagy olyan embereket, akik valamilyen értelemben esztétikával foglalkoznak, mivel a felhasználói felületeknek ergonómián túl esztétikai vonatkozásai is vannak. Kérdőívek, etnográfia és intelligens visszajelzés

104 Verifikáció és validáció
Verifikáció: megfelel-e a szoftver a specifikációknak, kielégíti-e a követelményeket Validáció: olyan verifikált szoftver, ami a felhasználó igényeit szolgálja, minden lépés után elvégzendő. Módszerek: átvizsgálás, tesztelés A követelményeket összegyűjtöttük, elemeztük, eldöntöttük, hogy milyen modell alapján fejlesztünk, megterveztük az architektúrát és a felhasználói felületet, implementáltuk a tervet. Ezután következik a verifikáció és validáció lépése.

105 Verifikáció és validáció
Szoftverátvizsgálás: statikus módszer, általában manuális tevékenység. Szoftvertesztelés: dinamikus módszer, a program futtatása tesztfeladatokkal, majd összehasonlítás az elvárt eredményekkel Szoftverátvizsgálás  Ez egy statikus módszer, úgy végezzük a lépéseket, hogy közben nem futtatjuk a programot. Bármilyen dokumentációt, bármilyen részterméket és a programkódot magát át tudjuk vizsgálni. Ez az átvizsgálás általában manuális, emberi tevékenység. Átvizsgálás során ellenőrizzük a dokumentációk, az ábrák és a kód konzisztenciáját. A kód átvizsgálásához vannak automatikus eszközök is.

106 Tesztelés Hiányosságtesztelés: verifikációs
Statisztikai tesztelés: használható validációsra is Ø   hiányosságtesztelés: ez kimondottan egy verifikációs tesztelés, feladata, hogy kiderítse a szoftver és a specifikáció közötti ellentmondásokat. Akkor hatékony, ha minél több hibát derít fel. Ø   statisztikai tesztelés: inkább validációs tesztelés, vagy legalábbis már használható validációra. A szoftvert elsősorban nem-funkcionális aspektusból teszteli, mindenféle méréseket (pl. válaszidő, megbízhatóság, használhatóság) próbál végezni arra vonatkozólag, hogy az adott környezetben hogyan működik a program. Ez a két tesztelésfajta nem biztos, hogy elkülönül egymástól és természetesen a statisztikai tesztelésnél is derülnek ki hiányosságok mint ahogy a hiányosságtesztelésnél is bizonyos jellegű statisztikai mérések megjelenhetnek. A verifikáció és validáció folyamata sosem mondja azt, hogy a szoftver 100%-os, legfeljebb annyit tud mondani, hogy a szoftver a követelményeknek lényegében, nagyjából megfelel, a szoftver a felhasználónak nagyjából jó lesz. A tesztelés nem alkalmas arra, hogy a szoftverről azt állítsuk, hogy helyes. Nagy kérdés, hogy mikor mondhatjuk azt, hogy a szoftver megfelelő. Az informatika arra szoktatta rá a felhasználókat, hogy elfogadják a rossz szoftvereket is. A terméket előállító iparban jóval nagyobb minőségi követelményeket állítanak eleve. Az informatika az egyetlen olyan ipar, amely nem vállal felelőséget azért, hogy a szoftvereinek milyen következményei vannak. Ha nem minden funkció működik 100%-osan, van olyan kevésbé lényeges, kevésbé gyakran használt, kevésbé általános funkció, amely nem jól működik, ettől maga a szoftver valóban jól és kellemesen használható ha tudjuk, hogy mi nem működik benne. Tehát ha néhány %-nyi funkció nem működik, az elviselhető általános szoftvereknél, azonban nyilvánvalóan egy biztonsági szoftvernél a néhány % már nem megengedhető. Attól függ, hogy milyen jellegű, milyen területen használt szoftverről van szó. Az elfogadhatóságnál alapprobléma a piac és a piaci környezet. Ha szoftvert fejlesztünk, és ez elkészül, akkor a fejlesztőnek kell tesztelnie (alfa-teszt). Ekkor előáll egy alfa-verzió, ez kerül ki először a fejlesztőcsapat kezéből. Ezek után a rendszert kiadják a fejlesztőtől független embereknek béta-tesztelésre, ezt lehetőleg felhasználói körülmények között kell végrehajtani. A béta-tesztelés elsősorban hiányosságtesztelés, és csak másodsorban statisztikai tesztelés. Ezen tesztelésnél feltárt hiányosságok megszünetetése után áll elő a béta-verzió. Valamikor a béta-verzió elfogadott verzió volt, manapság még kell tesztelni. A probléma ott van, hogy a piac annyira felgyorsult, hogy azonnal meg kell jelenni, és félig letesztelt béta-verziókat adnak ki.

107 A tesztelés kideríti A hiányosságokat a szoftverben
A teljesítményproblémákat A specifikációtól eltérést Ezt követi a hibák behatárolása, a debuggolás, majd a regressziós tesztelés A debuggolás, belövés. Ekkor tudjuk, hogy rossz a szoftver, meg kell keresni, hogy hol a hiba, ezután kijavítani. A hiba hatása általában később jelentkezik. Automatizált hibakereső eszközöknek semmi közük nincs a teszteléshez. Kiderítettük, behatároltuk, kijavítottuk a hibákat, ezután újratesztelünk. Ezt a tesztelést hívjuk regressziós tesztelésnek. Ugyanis lehetséges, hogy ha kijavítunk egy hibát, az három újabbat visz be a rendszerbe. A regressziós tesztelés alatt azt értjük, hogy ugyanazokat a teszteket futtatjuk le, mint amiket kezdetben, legalábbis elméletben. A regressziós teszteknél elviekben az összes korábbi tesztet le kellene futtatni, de ezt nem tudjuk megtenni, tehát a régebbiek közül a leglényegesebbeket kell újra lefuttatni, ezt a tesztesetek egy részhalmazára szokták végrehajtani.

108 Szoftvertesztelés tervezése
követelmények meghatározása rendszer-specifikáció rendszer- tervezés részletes tervezés szolgáltatás átviteli teszt rendszer-integrációs teszt alrendszer-integrációs teszt modul az egységkó-dolásra és tesztelésre átviteli teszt terve rendszerintegrációs teszt terve alrendszerinteg-rációs teszt terve A szoftverfejlesztés legkényesebb, legnyűgösebb, legköltségesebb része a verifikáció és validáció. Ma nagy rendszereknél a verifikáció és validáció a projektköltségnek közel a fele (40-50%). Ennek megfelelően a verifikáció és validáció lépését is tervezni kell, sőt igazából ezt kell tervezni. A tesztelés tervezésénél a következőket kell megtervezni: Ø   először a teljes tesztelési folyamatot tervezni kell; Ø   a tesztelést úgy kell megtervezni, hogy a követelményeket egyenként lehessen tesztelni; Ø   meg kell nevezni az szoftver azon elemeit, amelyeket az adott lépésben tesztelni kell; Ø   a tesztelést ütemezni kell, a különböző tesztelési módszereket másképp kell ütemezni; Ø   a tesztelést természetesen dokumentálni kell; Ø   meg kell tervezni a tesztelő eszközöket amennyiben szükségesek, és hogy ezek hol szükségesek.

109 Átvizsgálás Az átvizsgálás a teljes fejlesztési folyamat minden egyes lépésében alkalmazható. A szoftver átvizsgálása egy szárazteszt, amihez nem kell futtatni a programot. Tehát a forráskód átnézése alapján történő hiányosságtesztelés, verifikáció. Az átvizsgálás a teljes fejlesztési folyamat minden egyes lépésében alkalmazható. A dokumentumokat, mint résztermékeket tudjuk átvizsgálni, és át tudjuk vizsgálni a szoftvert. Ezt szoftverátvizsgálást hívja a szakmai szleng száraztesztnek. Az átvizsgálásra gyakorlatilag különböző módszerek alakultak ki a 70-es évektől kezdve, különösen az IBM dolgozott ki ilyen módszereket, átvizsgálási technikákat. A szoftverátvizsgáláshoz nem kell futtatni a programot. Ez egy olcsó és hatékony módszer a hiányosságok tesztelésére. Tehát a szárazteszt tipikusan egy hiányosságtesztelés, egy verifikációs technika. Nyilvánvalóan a forráskódból ránézésre elég nehéz megmondani a válaszidőt és egyéb statisztikai jellemzőket. Ugyanakkor hiányosságtesztelésre meglehetősen alkalmas, mert: -   az átvizsgálás folyamán egyszerre több hiányosságra is fény derülhet, tehát a hiányosságok csoportját tudjuk az átvizsgálás során felderíteni. A tesztelés akkor jó, ha egy-egy teszteset egy bizonyos dolgot, egy-egy követelményt tesztel. -   ha futtatjuk a programot (dinamikus tesztet hajtunk végre), akkor a hiányosságtesztelésnek van egy olyan kellemetlen mellékhatása, hogy a hiányosságok valószínűleg az adatok leromlását eredményezik, korrodálódnak az adatok a tesztelés folyamán és akkor más adatot tesztelünk, tehát vissza kell állítani az eredeti adatokat. - Az igazán jó tesztelők azok, akik az adott területet, nyelvet, technikákat, platformot jól ismerik.

110 Átvizsgálás során felismerhető hibák
adatkezelési hibák vezérlési hibák I/O hibák interfész problémák tárkezelési hibák a dinamikus szerkezeteknél kivételkezelés    adatkezelési hibák    változónak van-e kezdőértéke?    tömbindex hivatkozások méreten belül vannak-e?    bizonyos típusú határolókarakterek megvannak-e? (pl. C-ben a sztringhatároló)    vezérlési hibák    minden ciklus végetér? mindig? (végtelen ciklusok)    elágaztató utasítással minden rendben az adott nyelvnél? (break, default ág, csellengő ELSE)    I/O hibák    az input adatok mindegyikére szükség van? felhasználja a program?    ki vannak védve az input-hibák? minden inputra működik a program?   output-változóknak adtunk értéket?   interfész problémák   alprogramok, metódusok paraméterkiértékelésénél, -átadásánál minden rendben van? (típus, sorrend, szám)   tárkezelési hibák különös tekintettel a dinamikus szerkezetekre mutatók, NULL-mutatók használata hivatkozásra tárfoglalás kivételkezelés minden kivétel le van kezelve? ott van lekezelve, ahol kell?

111 Automatikus statikus tesztelők
A program szövege alapján megpróbálják felderíteni a fenti kategóriájú problémákat. Bármilyen nyelvnél tesztelhető: pl. a paraméterek számossága, a formális és aktuális paraméterek típusa, stb. Előnyös az útvonalelemzésnél A programátvizsgálásokhoz léteznek nyelvspecifikus automatikus eszközök, megoldható az automatikus átvizsgálás (automatikus statikus tesztelés). Ezek a statikus tesztelők a program szövege alapján megpróbálják felderíteni a fenti kategóriájú problémákat. Nyilvánvalóan nyelve válogatja, hogy mennyire könnyű vagy nehéz egy ilyen automatikus eszközt megírni. Szigorúan típusos nyelvek esetén bizonyos dolgokat sokkal könnyebb felfedezni. Vannak olyan dolgok, amelyeket bármilyen nyelvnél könnyen lehet tesztelni, például paraméterek számossága; szigorúan típusos nyelvnél könnyű ellenőrizni, hogy a formális és aktuális paraméterek típusa megegyezik-e. Azt viszont nem lehet kideríteni automatikus statikus elemzővel, hogy bár a típus jó, teljesen mást adtunk át. Ez szemmel könnyebben észrevehető. Nagyon kellemesek az automatikus statikus elemzők abban, ami az embernek nem annyira kellemes, ez pedig az ún. útvonalelemzés. Ez annyit jelent, hogy felderítjük a program működése során bejárható összes végrehajtási útvonalat. Ezt nyilvánvalóan az ember nehezen tudja elkövetni bizonyos bonyolultság fölött. Első kikötés, hogy nem engedjük meg a feltétel nélküli ugrást (GOTO), meg kell nézni az elágazásokat, és automatikusan le lehet generálni az összes utat.

112 Modul- és egységteszt A legkisebb tesztelhető programegységek.
Az elemek önállóan tesztelhetők. Modul- és egységteszt  Alrendszer- integrációs teszt Rendszerintegrációs teszt A modulok és az egységek (programegységek) a legkisebb olyan szoftverelemek, amelyeket tesztelni tudunk és szoktunk. A modulokból épülnek fel az alrendszerek, a modulok alrendszerekké való összeépítésénél beszélünk alrendszerintegrációs tesztről. A különbség a modul- és egységteszt és az alrendszerintegrációs teszt között, hogy az előbbinél az elemek önállóan, egyedül tesztelendők, tesztelhetők, az utóbbi pedig ezen részek együttműködését teszteli és ennek megfelelően jóval bonyolultabb. Még eggyel magasabb szint a rendszerintegrációs teszt, amikor az alrendszerek együttműködését teszteljük. A verifikációs és validációs lépés végén van egy átvételi/átadási teszt, melynek szerepe, hogy átadáskor a megrendelőnek demonstráljuk, hogy ez egy validált, használható rendszer. Alapvetően másként kell tesztelni egy eljárásorientált nyelven fejlesztett rendszert, mint egy OO-nyelven megírt alkalmazást.

113 Hiányosságteszt tesztesetek tervezése tesztadatok előkészítése
program futtatása tesztadatokkal eredmények összehason-lítása a tesztesetekkkel teszt- esetek teszt- adatok teszt- eredmények teszt- jelentések A hiányosságtesztelés akkor sikeres, ha minél több hiányosságot tár fel. Ennek megfelelően kell az egész hiányosságtesztelést felépíteni, megtervezni és végrehajtani. A cél, hogy hibákat tárjunk fel, helytelen működést derítsünk ki. Tesztesetek alatt értjük Ø   azon input adatok specifikációját, amelyekkel a tesztelést végezzük, Ø   annak leírását, hogy milyen követelményt, milyen szoftverelemet tesztelünk, Ø   annak specifikációját, hogy milyen működést, milyen outputot várunk el a rendszerelemtől. A tesztadatok a konkrét inputok, amelyekkel majd működtetjük a rendszert. Ezeket valamilyen módon meg kell adnunk, meg kell szereznünk, össze kell gyűjtenünk. Tesztadatot nagyon gyakran automatikusan tudunk generálni, tesztesetet soha. Egy adott tesztesethez nyilvánvalóan akárhány tesztadatot generálhatunk. Ha ezek megvannak, lefuttatjuk a programot, megnézzük, hogy mit csinál, megvárjuk az outputot, és ezt az outputot összevetjük a tesztesetben megadott elvárt output specifikációval, és mindezt dokumentáljuk. A tesztelés egy független dolog. Ez nem azzal fejeződik be, hogy kijavítjuk a hibákat, hanem a tesztjelentés visszakerül ahhoz, aki megkeresi a hibát és kijavítja, aki tipikusan a modul- és egységtesztnél az az ember, aki fejlesztette; második esetben a rendszerintegrátorhoz, harmadik esetben az átadást vezénylő személyhez. Az átadás/átvételi teszt már nem hiányosságteszt.

114 Kimerítő tesztelés Az összes lehetséges programútvonalat teszteljük.
A teszteseteket úgy tervezik, hogy a program minden utasítása legalább egyszer lefusson. Automatizált eszközökkel történhet. Kimerítő tesztelésről beszélünk akkor, ha az összes lehetséges programútvonalat teszteljük. Ez az, ami általában lehetetlen, mert bizonyos programszerkezeteknél ez közel végtelen. A kimerítő tesztelést próbáljuk úgy lecsökkenteni, hogy a teszteseteket úgy tervezzük meg, hogy a program minden egyes utasítása legalább egyszer lefusson. A szoftverfejlesztő cégek általában saját tesztelési szabványokat alakítanak ki, amelyben az itt felmerülő kéréseket és a későbbi dolgokat szabályozzák. Vannak a fejlesztők, ezek gyártják a szoftvereket, majd ezeket tesztelik, és a tesztelés visszacsatolódik, hibát keresünk, javítunk, újratesztelünk stb. Ennek párhuzamosan működnie kell. Meg kell oldani, hogy mindig van egy utolsó verzió, amelyről tudjuk, hogy éppen pontosan hol tart. Ennek megfelelően a teljes fejlesztés folyamán, de különösen itt a tesztelésnél automatizált eszközök vannak, ilyen automatizált eszközöket minden magára adó nagy szoftvercég alkalmaz, minden magára adó nagy informatikai cég szolgáltat.

115 Tesztelési technikák 1. funkcionális vagy feketedoboz teszt: csak a viselkedésmódot, az I/O-t teszteljük. 2. struktúrateszt, fehérdoboz vagy üvegdoboz teszt: egységtesztelő módszer, a kód ismeretében tervezzük a teszt útvonalát.

116 Feketedoboz teszt output teszt- eredmények input adatok IE OE rendszer A tervezett tesztesetek alapján legenerálandók az input tesztaadatok A rendszer visszaadja az eredményeket A teszteredmények nem egyező részhalmaza határolja be a hiányosságokat. A teszteset-tervezés lényege, hogy hogyan tudjuk növelni ezt a bizonyos két részhalmazt. Ehhez kell a tapasztalat, hogy milyen típusú adatokat nem szoktak tudni kezelni a rendszerek.

117 Tesztesetek tervezése
inputok rendszer outputok A tesztesetek tervezéséhez generálásához egy ekvivalencia-osztályozást alkalmaznak az inputokon és az outputokon, ugyanis az inputadatok általában jól kategorizálhatók. Elvégezzük az osztályozást, ezután azonos osztályú adatokból próbálunk tesztadatokat generálni, biztosítva, hogy a tesztadatok flexibilisek legyenek, nagy változatosságot mutassanak, hogy valóban teszteljük a rendszert. Ugyanis amikor valaki kódol egy programot, a megoldásnál a normál, általános, átlagos esetet kódolja le. Kérdés: hogyan működik szélsőséges esetekben a program? Tesztelni valószínűleg nem az átlagos esetet kell, mert az úgy lett megírva, hogy arra működik. Azonos ekvivalencia-osztályból különböző inputadatokat tudunk generálni. Példa: rendezőalgoritmusok a rendezőalgoritmusoknak egy elem esetében is működniük kell, olyan tesztsorozatokat kell generálni, melyek elemszáma különböző, minden elem azonos, minden elem különböző, minimum, maximum benne van; a szélsőséges szituációkat tükrözze. Biztos, hogy nem jó az a taktika, hogy véletlenszerűen generálunk adatokat.

118 Struktúrateszt, fehérdoboz vagy üvegdoboz teszt
Tipikusan egységtesztelő módszer, használható integrációs tesztelésnél is, ahol felhasználjuk az implementációt is a tesztelésnél. A kódot arra használjuk fel, hogy ennek ismeretében tervezzük meg teszteseteket, generáljunk tesztadatokat. Ha tervezhető, minden utasítás minimum egyszer végrehajtásra kerüljön. Az útvonaltesztelés ezen belül egy kiemelt dolog. A szoftver bizonyos tulajdonságait szoftvermetrikákkal mértjük, ezek a szoftver bizonyos tulajdonságaihoz numerikus értékeket rendelnek. Például útvonaltervezésnél a ciklomatikus komplexitás, ez tulajdonképpen az adott szoftverelem független végrehajtási ágainak számát határozza meg. Ha nincs GOTO, akkor a kódban található feltételek száma + 1. És akkor az összes út legenerálható automatikusan. A tesztet ennek ismeretében úgy tudjuk megtervezni, hogy annyi tesztesetet tervezünk, ahány út van. Persze ez csak kis szám esetén működik. Ehhez vannak statikus elemzők, amelyek legenerálják ezeket az útvonalakat, és vannak olyan dinamikus tesztelőeszközök, amelyekkel valamilyen szinten automatizálható a struktúrateszt az útvonaltesztelésre vonatkozóan.

119 Integrációs tesztelés
Az elemek együttműködését teszteli. A rendszerspecifikációból indul ki. Jellemzően inkrementális teszteléssel ellenőrzik az összekapcsolt modulok együttműködését. Inkrementális tesztelés: létrehoznak egy minimális konfigurációt, amely kettő vagy néhány összekapcsolt elemet tartalmaz, ezt a minimális konfigurációt letesztelik, ha működik, mindig hozzáraknak egy elemet és újra tesztelik.

120 Inkrementális tesztelés
A B T1 T2 T3 C T4 D T5 Mivel az integrációs tesztelésnél méginkább igaz az, hogy a hiba kiderítése egy dolog, de aztán belövéssel be kell határolni a hibát. A hibabehatárolás nyűgös, és a hibabehatárolásnál hatványozottan igaz, hogy megvan a nyűg, csak éppen a hibát okozó rész nem ott van, ahol ténylegesen a hiba jelentkezik, az együttműködés miatt itt pláne nem. A hiba egészen más modulban lehet, mint ahol a hiba tünetei jelentkeztek. Az integrációs tesztelésnél általában kétféle közelítést szoktak alkalmazni: fentről lefelé, lentről felfelé.

121 Integrációs teszt fentről lefelé
1. szint 2. szint 2. szintű csonkok 3. szintű csonkok Fentről lefelé történő tesztelés a magasszintű komponensek fejlesztésével és azok integrálásával kezdődik, és úgy megyünk az alacsonyabb szintű egységek, komponensek irányába. Ez meglehetősen tipikus egy evolúciós fejlesztésnél. Előnye: a magasabb szintű komponensekkel egy kisebb funkcionalitással rendelkező, de már működő rendszert tesztelünk Probléma: az integrációs teszt adott esetben nagyon nehéz, mivel az outputot a levélkomponensek biztosítják majd, tehát a funkcionalitást a csonkoknál valamilyen módon biztosítani kell. Előnye: már működő rendszert tesztelünk. Probléma: az integrációs teszt adott esetben nagyon nehéz, mivel az outputot a levélkomponensek biztosítják majd.

122 Integrációs teszt lentről felfelé
N. szint N–1. szint tesztelési sorozat Ez meglehetősen tipikus egy evolúciós fejlesztésnél. Megvannak az egységtesztek, tehát itt valóban együttműködést lehet tesztelni. Probléma: ha elkezdjük összepakolni a modulokat és felépíteni a magasabbszintű elemeket, akkor egy környezetet kell biztosítani, szimulálni kell egy környezetet, amiben használni fogjuk. Ezeket hívjuk tesztmeghajtóknak, ilyeneket kell tervezni. Általában a két módszert együtt szokás alkalmazni az adott fejlesztési modellnek megfelelően. Előnye: itt valóban együttműködést lehet tesztelni. Probléma: a magasabb szintű elemekhez környezetet kell biztosítani, szimulálni.

123 Interfésztesztelés paraméter interfész: az egyes elemek paraméterekkel kommunikálnak osztott memória interfész: az egyes elemek osztott tárterületen keresztül kommunikálnak funkcionális interfész: az egyik elem egy hívható alprogram, metódus, eljárás, függvény halmaz specifikációját adja üzenetinterfész (szolgáltatás-orientált): az egyes komponensek üzenetekkel szolgáltatásokat hívnak meg Az interfésztesztelésnél a következő jellegű hibákat kell kiszűrni: Ø   nagyon gyakran fordul elő interfész-félreértelmezés; az adott interfészen a másik alrendszerrel, komponenssel stb. kapcsolatot teremtő szoftverelem azt hiszi.. Ø   paraméteres interfész esetén rosszul alkalmazza az interfészt, paraméterproblémák vannak Az interfészproblémák egy része átvizsgálás során kiszűrendő (például a paraméterhibák), a félreértelmezés általában csak dinamikusan derül ki. A probléma ott van, hogy az interfészhibák csak szélsőséges esetben derülnek ki. Tipikus lyukak az interfészek környékén vannak a rendszerekben, amelyen illegális módon tudunk behatolni a rendszerekbe. Ezért lényeges az interfészek tesztelése.

124 Stressztesztelés A rendszerintegráció során összeálló teljes szoftvert szélsőséges körülmények között, nem normális terhelés mellett teszteljük. Eredményeként lehet teljesítményt hangolni. A rendszerintegráció során összeálló teljes szoftvert szélsőséges körülmények között, nem normális terhelés mellett teszteljük; nagyon nagy adatmennyiséggel, nagyon nagy felhasználói számmal, nagyon intenzív kérdésekkel stb. Mindezt azért tesszük, mert a rendszernek robusztusnak kell lennie, nem érzékeny, vagy kevésbé érzékeny a szélsőséges terhelésre. A stressztesztelés eredménye az, amit teljesítményhangolásnak hívunk. Ha a rendszert arra tervezzük, hogy egyszerre 10 000 kérdésre válaszoljon percenként, akkor az 5000 nem minősül stressznek, az 50 000 már igen, az 500 000 pedig kimondottan. A robusztus rendszer a stresszre teljesítménycsökkenéssel reagál, de nem omolhat össze. Ha összeomlik a hiba, ha nagyon lelassul, akkor hangolni kell, ki kell deríteni, hogy hol vannak a szűk keresztmetszetek, és meg kell próbálni ezeket kiküszöbölni. Az, hogy a sztresszes terhelésnek hol vannak a határai, attól függ, hogy milyen rendszerről van szó. Általános ökölszabály, hogy a normál terhelés tízszeresét nem illik megérezni a rendszernek. A stresszterhelésre külön automatikus eszközök vannak.

125 Objektumorientált tesztelés
Objektumorientált szoftverek modultesztelésénél osztályokat tesztelünk, az osztálytesztelés pedig elsősorban viselkedésmód-tesztelést jelent. Az osztályok közötti együttműködés, mint nagyobb objektumcsoport-osztályok közötti integrációs teszt, mivel az alrendszer sok osztályból áll.

126 A tesztelés technológiai háttere
tesztmenedzserek tesztadat-generátorok előrejelzők, jóslók dinamikus elemzők szimulátorok Ø   tesztmenedzserek: a teljes tesztelést végigkövetik; kezelik a futtatandó kódot, a tesztadatokat, az output eredményeket Ø   tesztadat-generátorok: tesztesetek megtervezése után a tesztadatokat automatikusan generálja Ø   előrejelzők, jóslók: kevésbé elterjedtek; a tesztesetek alapján megjósolják az eredményt, így a tesztadatok generálásán túl adnak tesztadatokat is, amelyeket fel lehet használni összehasonlításhoz. Ø   dinamikus elemzők: a kód futásának bizonyos paramétereit mérik, elsősorban teljesítmény-tesztelésnél, stressztesztelésnél, teljesítményhangolásnál használatosak. Ø   szimulátorok: a gépet, az operációs rendszert, a környezetet szimulálják, adott környezetet biztosítanak a futtatáshoz; elsősorban interfészek, párhuzamos rendszerek tesztelésénél érdekes Az egész tesztelési folyamatban sok nyűg van. Az egyik nyűg, hogy megkapunk egy input-adatot, egy eredményt, az eredmény az ekvivalencia-osztályok alapján elfogadható, tehát az eredmény beleesik az elfogadható halmazba, de lehet, hogy nem helyes. Kérdés, hogy hogyan lehet ezt az esetet kiküszöbölni, hogy van egy nem elvetendő output, ami nem helyes.

127 Minőség kezelése A szoftver egy termék.
Az ipari termékeknek van minőségi specifikációjuk. A szoftver viszont egy szellemi termék.

128 Minőség Minőségbiztosítás Minőségtervezés Minőségellenőrzés
termékszabványok folyamatszabványok Minőségtervezés Minőségellenőrzés Minőségbiztosításnak hívjuk azt a tevékenységet, amelynek során eljárásokat, szabványokat állítunk össze ahhoz, hogy minőségi termék készüljön el. A minőségbiztosításnál kétfajta szabványegyüttes van, beszélünk termék és folyamatszabványokról. Ø   termékszabványok: magára a termékre vonatkoznak, a termék paramétereit specifikálják. Ø   folyamatszabványok: a termék előállításának folyamatára vonatkozó szabványok. Minőségtervezésről beszélünk akkor, amikor egy konkrét szoftverfejlesztési projekthez kiválasztjuk, az előbbi eljárás és szabványhalmazból a most alkalmazandó konkrét eljárásokat és szabványokat. Minőségellenőrzés, amikor meghatározzuk és bevezetjük azokat a folyamatokat, amelyeket a projekt folyamán használni kell a minőségtervezésnél kiválasztott eljárások és szabványok vonatkozásában.

129 Minőségbiztosítás szoftvereknél
termékszabvány: hogyan nézzen ki egy dokumentáció, a tesztelés eredményeként előálló jónak mondott szoftverelemekből hogyan lesz tényleges szoftverelem, hogyan kerül be egy szoftverelem a teljes szoftverbe, hogyan nézzen ki egy forráskód. folyamatszabványok: ki gyártja a teszteket, ki végzi a teszteket, ki végzi a felülvizsgálást, ki tervezi a minőséget a folyamat során, milyen tervezési mód, milyen szabvány, hogyan tervezzük, hogyan dokumentáljuk...

130 Minőségi szabványok Az általános, ipari termékekre vonatkozó minőségszabvány: ISO9000 Az ISO as a szoftverminőség szabvány. A cég minőségbiztosításához minősíttetni kell egy auditáló céggel a termék- előállítási folyamatot. Az ipari termékek előállításánál a szabványok folyamatszabványok, ugyanis az derül ki, ha az ipari termelés folyamán, ha a folyamatot szabványosítjuk, akkor az ipari termék jó minőségű lesz. A szoftverre ez nem igaz; lehet jó, szabványos folyamattal rossz szoftverterméket előállítani. Ez azért van, mert egy szellemi termék, nem egy fizikai termék.