Szoftverarchitektúra - implementáció tervezése - Architektúra Architektúra: strukturálisan fontos elemek és ezek kapcsolata. 1
Architektúra központú A rendszer architektúrája (egy adott pillanatban) a rendszer alapvető komponenseinek szerveződése, melyek egymással meghatározott felületeken keresztül kommunikálnak, és hierarchikus szervezésű, egyre finomabb, egymással szintén megfelelő, alacsonyabb szintű felületeken keresztül kommunikáló komponensekből épülnek fel. Architektúra - nézet Egy architektúrát több nézet szerint lehet leírni. A különböző módszertanok különböző nézeteket javasolnak: Statikus nézet: rendszert alkotó elemek, kapcsolatok. Dinamikus nézet: a rendszer időbelisége. Funkcionális nézet: a rendszer funkcionalitása, a rendszer milyen adatokat milyen algoritmusok alapján generál. 2
Architektúra az alkalmazás jellege alapján Az objektumok csoportosítása az MVC koordináta rendszer alapján Model-View-Control Smalltalk vezette be Sztereotípus Minden jól tervezett objektum valamelyik koordináta fele húz. MVC koordináta rendszer Koordináták: Határ, Entitás, Control objektumok. Ez a gondolatmenet általánosítható alkalmazásokra, egy-egy alkalmazás olyan mint egy nagy objektum. 3
MVC koordináta rendszer Határ: Felület dominenciájú alkalmazások: Jellegzetes desktop alkalmazások, szövegszerkesztők, vizuális felhasználói környezetek stb. Entitás: Klasszikus információrendszerek Fő feladatuk az adatkezelés Control Algoritmus dominenciájú alkalmazások Tudományos, műszaki számításokat végző alkalmazások Az architektúrát az algoritmusok befolyásolják Ritka a gyakorlatban. Mi a szoftverarchitektúra? A rendszert felépítő alrendszerek (szoftver komponensek) kerete alrendszerek meghatározása alrendszerek tulajdonságai Vezérlési, valamint kommunikációs kapcsolataik 4
Mi még a szoftverarchitektúra? Magasszintű terv A rendszer átfogó struktúrája több nézet -> több struktúra Komponensek és összekötők összesége Architektúra központú Architektúrális komponensek: A rendszer alapvető működését meghatározó szoftver részek, rendszerszervezési megoldások. A fejlesztés fázisaiban központi szerepet kap a robosztus architektúra: Robosztus = rugalmas, jól tűri a változásokat Az architektúra megalapozása az elsődleges feladat, hiszen ha itt hibázunk, az nagyon sokba kerül. 5
A SW architektúra szerepe Az érdekelt szereplők kommunikációjának lehetővé tétele. A korai fejlesztási fázisok döntéseinek támogatása a követelmények tükrében. Nagyléptékű újrafelhasználhatóság elősegítése. A SW architektúra célja Az architektúra célja: átláthatóvá teszi a fejlesztést, könnyebben felismerhetők az újrafelhasználható elemek, átlátható projekt menedzsment, kockázatok csökkentése, lehetővé válik a párhuzamos fejlesztés. 6
A SW architektúrák forrása Üzleti és technológiai döntések eredménye Meghatározó a környezet szerepe A fejlesztők céljai és stratégiája által befolyásolt követelmények vezetnek különféle szoftver architektúrákhoz Az architektúra ciklus Az architektúra meghatározó a fejlesztő szervezet szerkezetére Az architektúra befolyásolja a fejlesztő szervezet céljait Az architektúra hatással van a követelményekre A fejlesztés során a fejlesztők tapasztalatokat szereznek architektúráról Bizonyos rendszerek hatással vannak a fejlesztési kultúrára 7
Az architektúra ciklus Fejlesztõ szervezet Követelmények Architektúra A rendszer szereplõi Technológiai követelmények A tervezõ tapasztalata Tervezõ/fejlesztõ Rendszer Mitől jó egy architektúra? Kis számú vezető tervező Jól definiált funkcionális követelmények és minőségi jellemzők Jól dokumentált az architektúra Az architektúra értékelésében az összes érintett szereplő részt vesz Kvantitatív minőségi mértékek Inkrementális architektúra implementáció Kevés erőforrás versenyhelyzet a fejlesztés során 8
Architektúra elemek Architektúrális minta típus elemek és kapcsolatok, kényszerek pl. kliens-szerver minta Referencia modell standard funkcionális felosztás és adatfolyam megoldások pl. adatbázis kezelő rendszer Referencia architektúra referencia modell leképezése szoftver elemekre pl. ISO OSI architektúra Az architektúra rétegei A rendszer különböző szinten elhelyezkedő elemei rétegekbe sorolhatók. 9
Rétegzett architektúra Általánosan használt modell Mit jelent a rétegzettség: Fizikai rétegek (tier): az egyes rétegek különböző futtatható állományokban vannak, ezek a futtatható állományok különböző gépeken helyezkednek el, az egyes futtatható elemek hálózati protokollon keresztül beszélgetnek Logikai rétegek (layer): a forráskód belső tagozódása. Egyirányú a logikai függés: a fizikai rétegzettség feltételezi a logikait, de fordítva nem! Javasolt rétegek Rendszerszoftver réteg. Közép réteg (elosztott komponensek: EJB, CORBA, DCOM). Általános alkalmazási réteg. Felhasználó specifikus alkalmazási réteg (user interfészek). RUP által javasolt. 10
Szokásos logikai rétegek Kezelői felület Alkalmazás logika Adatbázis logika Frameworks, middleware, rendszer szoftver Minden, ami kiszolgál. Szokásos logikai rétegek Kezelői felület Csak a megjelenés. Alkalmazás logika Az alkalmazásra jellemző elemek. 11
Szokásos logikai rétegek Adatbázis logika Egész szervezetre, egész adatbázisra jellemző, nem alkalmazás függő. Általában egy adatbázison több, különböző célú alkalmazás is dolgozhat (Számlázó-, Megrendelés kezelő-, Raktárkészlet kezelő alkalmazás), amik részben vagy egészében ugyan azokat az adatokat használják és az adatok között vannak olyan összefüggések, amik függetlenek a feldolgozás céljától. Frameworks, middleware, rendszer szoftver Minden, ami kiszolgál. Együttműködés Kliens-szerver architektúra. 12
Néhány elterjedt architektúrális modell Osztott adatokra épített architektúra CASE eszközök Kliens-szerver architektúra hálózati, kommunikációs szoftverek Réteg szerkezet architektúra protokoll referencia modellek Funkcionális csőrendszerek Eseményvezérelt rendszerek Osztott adatok Az alrendszerek adatokat cserélnek központi adatbázis saját adatbázisok, explicit adatcsere Közös adatigényű alkalmazások 13
Osztott adatok Előnyök nagy mennyiség" adat hatékonymegosztása központi adat kezelés lehetősége Hátrányok minden részrendszerben azonos adatszervezés elosztottság nehézkes Osztott adatok Integrált CASE eszköz 14
Réteg szerkezet modell Speciális alrendszer elrendezés Rétegekbe szervezett modulok, szolgáltatások Jól definiált interfészek Inkrementálisan, egymástól elkülönülten fejleszthető rétegek Mesterségesen kialakított rétegek Az OSI modell 7 rétege fizikai réteg adatkapcsolati réteg hálózati réteg szállítási réteg viszony réteg megjelenítési réteg alkalmazási rétegek 15
A hoszt Alkalmazási Alkalmazási protokoll B hoszt Alkalmazási Megjelenítési Megjelenítési protokoll Megjelenítési Viszony Viszony protokoll Viszony Szállítási Szállítási protokoll Szállítási Hálózati Hálózati protokoll Hálózati Adatkapcsolati Adatkapcsolati protokoll Adatkapcsolati Fizikai Fizikai protokoll Fizikai Eseményvezérelt rendszerek A rendszer vezérlésén kívülről érkező események határozzák meg a viselkedést Pl. Ha a vállalat eseményvezérelten működik, a felhasználói rendelések közvetlenül meghatározzák a legyártandó termékek számát (a rendelés beérkezése "kiváltja" a gyártás indítását). Eseményvezérelt modell broadcast modell 16
Broadcast modell Elosztott alrendszerek integrálása Az alrendszerek előfizetnek azőket érdeklő eseményekre az eseménykezelőnél Események időbeli bekövetkezte ismeretlen A programtervezés jelentősége a végzendő feladatok mennyisége karbantartás tesztelés karban- tartás tesztelés kódolás tervezés programtervezés kódolás Megvalósítás tervezés nélkül Megvalósítás tervezéssel 17
A programtervezési módszerek sajátosságai cél az információs domének tervezési reprezentációvá alakítása megoldás szimbólumkészlettel, amely a komponensek, azok viszonyának és az algoritmusnak a leírására szolgál ajánlás az eljárások finomításának és komponensre bontásának végrehajtására szempontokat ad a szoftverminőség biztosításához A Warnier-féle strukturált programtervezési lépések adatszerkezetek tervezése a programszerkezet kialakítása funkcionális leírás tevékenységek programstruktúrákhoz rendelése 18
A Lorensen-féle OO programtervezés lépései az alrendszerek adatigényét kielégítő osztályabsztrakciók meghatározása az absztrakciós osztályok jellemzőinek specifikálása az osztályok műveleteinek meghatározása objektumok közötti kommunikáció módjának (üzenetek) specifikációja felhasználói igények leírása scenárióval öröklődés vizsgálata A programtervezés feladatai A programtervezés a korábbi fázisokban kialakított modellek (adat- illetve objektum-modell, funkcionális modell és a rendszer viselkedését leíró dinamikus modell) alapján történik. A programspecifikációt lépései: adat-tervezés: az adatstruktúrák és ábrázolási módok specifikálása architektúra tervezés: a programrendszer egyes komponenseinek, azok egymáshoz való viszonyának meghatározása folyamatok (procedures) tervezése a szerkezeti komponensek működési folyamatokhoz illesztésének specifikációja 19
Dinamikus Adat/objektum modell modell adatok tervezése Funkcionális modell Egyéb elvárások, körülmények Programtervezés Az implementációs fázis szakaszai procedurális tervezés Kódolás architektúra-terv Programmodulok Tesztelés tesztelt szoftver-rendszer (integrációs és validitási ellenõrzés) Tervezési alapelvek absztrakció lépésenkénti finomítás modularitás, komponens szemlélet szoftver-architektúra vezérlési hierarchia adatstruktúra és adatfolyam szoftverfolyamatok komponens architektúra információelrejtés 20
Modularitás modul, komponens értelmezése beépülési, aktivitási jellemző, vezérlési mód típusok: compile time~, corutin~, conrutin~ definíció: a modul, a komponens a programrendszer legkisebb, önállóan is működőképes, cserélhető, újrafelhasználható egysége, amely interfészeken keresztül csatlakozik a környezetéhez funkcionális függetlenség kohézió (binding), csatolás (link, coupling) A Architektúra adatfolyamdiagram Cél: az architektúra-komponensek B 0. szint közötti adat- és vezérlési információk áramlásának, az üzenettovábbítási folyamatoknak a szemléltetése 1. szint 21
Objektumorientált fejlesztőkörnyezet - komponensdiagram Alkalmazások, kliens oldal user interface (felhasználói felület komponens) TCP/IPv6 protokoll Rendszer szerver object database (objektum adatbázis) Fejlesztõ rendszer CASEeszközök, alkalmazásgenerátorok Projectmanagement repository domain (fejlesztési adatbázis) rendszerszolgáltatások A programtervezés feladatai adat- és objektumtervezés architektúra tervezés bemeneti, kimeneti információk, működési, vezérlési funkciók, tesztelési feladatok folyamat-terv készítése működési algoritmus fejlesztőkörnyezet kiválasztása kódolás 22
A program-architektúra tervezés feladatai a rendszer bemeneti információinak meghatározása felhasználói interfészek tervezése a rendszer működését vezérlő funkciók terve: menüszerkezet architektúra kontextus diagram: információ forrása,típusa, kommunikációs útvonal szolgáltatások, outputok specifikációja karbantartási, diagnosztikai és tesztelési tervek A működési algoritmus tervezése folyamatábra Warnier-Orr diagram Jackson ábra avagy struktúra diagram Nassi-Shneidermann avagy Chapin-Chart ábra komponensdiagram vezérlési struktúradiagram lásd szemléletesen: 23
Folyamatábra szimbólumok start/stop kapcsolódási pont manuális mûvelet funkció, mûvelet általános adat szimbólum forrás-dokumentumvagy nyomtatott output on-line input Folyamatábrakészítés START Input a,b c= 2a+ 5b d= 7ab-4b/a Folyamatábra minta szalag állomány elõkészítõ funkció lemez állomány rutinmûvelet, könyvtárprogram logikai döntés, elágaztatás on-line output mûveletek sorrendje adatkommunikáció c= d? igen x= 5b-3d nem x= 4a+ 7c x= d+ a? igen kiír a,b,x nem END Műveleti struktúrák folyamatábrával Mûveletek szekvenciája Aszelekció logikai struktúrája Iteratív mûveletek ciklikus szerkezetei hátultesztelõ elõltesztelõ utasítás IF... nem feltétel igen ciklusutasítások ciklusutasítások utasítás ELSEág THEN ág DOUNTIL felltétel igen nem DOWHILE felltétel igen nem DOUNTIL DOWHILE 24
JACKPR o a= 1? a«0? o o a= 9999? * end: k= 50 o o a= 1000? különben vege k= k+ 1 k= 25 k= k*2 a= a*k+ 1 Jackson-féle struktúradiagram Chapin-Chart szerkezetek Szekvencia IF THEN... ELSE... szelekció Iteráció szemléltetése CASEszelekció 1. feladat 2. feladat 3. feladat feltétel hamis igaz ELSE THEN ág ág ciklus feltétel DOWHILE ciklusmag REPEAT UNTIL ciklusmag ciklus feltétel CASEfeltételek érték érték... utas. utas.... 25
Vezérlési struktúradiagram sorrendiség S; S; S; döntés (if... then... else...) S; if Cthen else S; S; S; S; S; end if case S; S; S; case Dis when C1= > S; S; end case when C2 = > S; S; while ciklus S; while C; S; S; S; end C; S; Komponens architektúra "A" modul "A1" modul "A2" modul "A3" modul "A31" modul "A32" modul 26
Kódolás A számítógépes program készítése a végrehajtandó utasítások meghatározott sorrendben írását jelenti a rendelkezésre álló nyelven. Az a mód azonban, ahogyan a programozó a nyelvi lehetőségeket használja a program intelligenciájának mértéke Kernighan, 1978. Tesztelés 27
A tesztelés szükségessége, jelentősége Tesztelés kiértékelése Elfogadási, rendszer - és terhelési teszt Modul- és integrációs teszt Bevezetés, üzemeltetés, karbantartás, minőségbiztosítás M egvalósítás Célkitűzés, problémadefiniálás Elemzés, követelményspecifikáció Inkrementális tervezés Tesztelés célja Helytelen szemlélet: a szoftver hibamentességének bizonyítása, ill. a specifikált tulajdonságok megvalósításának bizonyítása. Helyes felfogás: a szoftvertesztelés a fejlesztett szoftver végrehajtása azzal a céllal, hogy a benne levő hibákat, ill. a specifikációtól eltérő viselkedését felderítsük. 28
Szoftverrendszerek tesztelése A szoftver fejlesztés célja: a specifikációban leírt követelményeket kielégítő szoftver készítése. Fejlesztés során különböző ellenőrző, elemző lépéseket kell végrehajtanunk a cél elérése érdekében. A vizsgálat során két egymástól eltérő célunk lehet: Vizsgálhatjuk azt, hogy a megfelelő terméket készítjük-e. Ebben az esetben validációt végzünk. Vizsgálhatjuk azt, hogy a terméket jól készítjük-e. Ebben az esetben verifikációt végzünk. V & V: verifikáció és validáció A verifikáció: azt vizsgáljuk, hogy a fejlesztés során egymás után végrehajtott fejlesztési lépések során előállított szoftver (ill. annak terve) megfelel-e a specifikációban rögzített elvárásoknak, tulajdonságoknak. A verifikáció során a vizsgálat alapja mindig valamilyen fejlesztés során előállított információ (termék). 29
V & V: verifikáció és validáció A validáció: általánosabb folyamat, Azt vizsgáljuk, hogy az elkészített termék megfelel-e a megrendelő elvárásainak. A validáció tehát magában foglalja a specifikáció ellenőrzését is. V & V: verifikáció és validáció A verifikáció, és a validáció végrehajtására használható technikák: Szoftver átvizsgálás. Szoftvertesztelés. 30
V & V: verifikáció és validáció Szoftver átvizsgálás: A fejlesztés során előállított termékek (modellek, kód, stb.) statikus elemzése, ami lehet manuális vagy automatizált. Manuális vizsgálatra példa a kód-review különböző formái, automatizált vizsgálatra példa a UNIX rendszerekben használt lint (splint) eszköz, mely C programokat elemez és felhívja a fejlesztő figyelmét a potenciálisan hibás, vagy hibát eredményező kódrészletekre. V & V: verifikáció és validáció Szoftvertesztelés: Az implementált szoftver futtatása tesztadatokkal, annak kimeneteinek, viselkedésének, ill. teljesítményének megfigyelése, összevetése a követelményekkel, azzal a céllal, hogy a benne levő hibákat felderítsük. Ezt nevezzük dinamikus elemzésnek, ill. dinamikus verifikációnak. 31
Statikus és dinamikus verifikáció alkalmazása szoftverfejlesztés során Követelmények 1. Analízis & Tervezés Rendszer terv (pl. UML diagrammok) statikus verifikáció (review) 2. Terv verifikációja Verifikált rendszer terv (pl. UML diagrammok) 3. Implementáció Implementált rendszer (pl. C++ code) dinamikus verifikáció (szoftvertesztelés) 4. Tesztelés Tesztelt rendszer Szoftvertesztelés alapsémája A tesztelés lényege összehasonlítás: A tesztelt szoftver (software under test, SUT) kimeneteit, működését, viselkedését összehasonlítjuk valamilyen referenciával. Az összehasonlítás alapjául szolgáló referencia leírása sok forrásból származhat, attól függően, hogy a szoftverfejlesztés mely stádiumában hajtjuk végre a tesztelést. Származhat az információ a specifikációból nyert adatokból, prototípus szoftver leírásából/megfigyeléséből, vagy a fejlesztés során előállított, rendszer viselkedését leíró modellből. 32
Szoftvertesztelés alapsémája Referencia (követelmény specifikáció, prototípus, rendszermodell stb.) referencia kimenet bemeneti sorozat viselkedés, állapot megfigyelése Értékelés (viselkedés, kimenetek összehasonlítása) eredmény Tesztelt szoftver software under test, SUT SUT kimenet Szoftvertesztelés típusai Két típus az alapján, hogy mi a tesztelés célja: Hiányosság és hiba tesztelés: A tesztelés célja a fejlesztés során bekerült specifikációtól eltérő, vagy nem megvalósított működés kiszűrése. Statisztikai tesztelés: A program teljesítményének, megbízhatóságának vizsgálata általában valós bemenetek felhasználásával. 33
Tesztelés folyamata A szoftver tesztelése különböző lépésekre bontható. A szoftverfejlesztés korai szakasza, teszt tervezése: definiáljuk, milyen módszerekkel és milyen lépésekben végezzük a szoftver tesztelését. A tesztelés következő lépése a tesztesetek definiálása. Tesztesetnek nevezzük egy adott hiba felderítésére szolgáló tesztet. A teszteset definíciója tartalmazza: a tesztelés során használandó bemeneteket, a tesztelt szoftver teszteset végrehajtásához szükséges állapotának leírását (esetlegesen az állapot beállítás módját), a helyes működés során keletkező referencia kimeneteket, ill. a teszteset hibamentes végrehajtása során történő viselkedésének (pl. bejárt állapotok) leírását. Tesztelés folyamata Ha egy teszteset alkalmas arra, hogy annak végrehajtásával egy adott hiba meglétét, ill. hiányát felderítsük, akkor azt mondjuk, hogy az adott teszteset (ill. az adott teszt) a kérdéses hibát lefedi. Ennek megfelelően beszélünk tesztesetek (tesztek), ill. teszteset halmazok (teszthalmazok) hibafedéséről. Tesztgenerálásnak azt a folyamatot nevezzük, mely során a teszteseteket előállítjuk, definiáljuk. A tesztgenerálás célja a minél nagyobb hibafedésű teszthalmaz előállítása. 34
Tesztelés folyamata A tesztesetek definiálása és szoftver implementálása után történik: a tesztesetek végrehajtása, az eredmények értékelése, elemzése, mely a tesztelés utolsó fázisa. A szoftverben feltételezhetően előfordulható hibák leírását nevezzük hibamodellnek. SW hibamodell Hibák: specifikációs hibák, tervezési hibák, kódolási hibák... Általános probléma: Nem lehet olyan leírását adni a hibáknak, ami általánosan használható. Nehéz a tesztelés hatékonyságát mérni. 35
Tesztelési megközelítések A tesztelés során a tesztelt rendszert különböző módon lehet kezelni, mely alapvetően más, és más módszereket fog eredményezni a tesztesetek előállítására. Két alapvető megközelítés létezik: Funkcionális tesztelés Strukturális tesztelés Funkcionális tesztelés A tesztelő nem veszi figyelembe a tesztelt szoftver belső felépítését. Kizárólag a rendszer specifikációja alapján végzi a tesztelést. Az ilyen szemléletben történő tesztelést szokták még specifikáció alapján történő tesztelésnek is hívni. Mivel a tesztek tervezése, ill. végrehajtása során a tesztelés alatt álló szoftver belsejébe nem látunk bele, szokásos az ilyen technikákat fekete doboz (black box) tesztelésnek is nevezni. 36
Strukturális tesztelés A funkcionális tesztelés ellentéte. A tesztelés a szoftver a specifikációban megadott funkciót megvalósító program szerkezete alapján történik. Mivel a tesztelő belelát a szoftver belső működésébe szokásos az ilyen technikákat fehér doboz (white box) tesztelésnek is nevezni. Strukturális tesztelés esetén a program vezérélési szerkezetét modellezzük és a tesztelő a vezérlési szerkezet minden ágát, a program különböző bemenetek esetén végrehajtódó részét végrehajtva vizsgálja annak működését. Funkcionális tesztelési módszerek Az ekvivalencia partícionálás egy természetes tesztelési megközelítés formalizálása. Abból indul ki, hogy minden hibához lehetőleg csak egy tesztesetet definiáljunk. Ennek érdekében a szoftver bemeneti adatainak minden kombinációját tartalmazó képzeletbeli halmazt olyan részekre (partíciókra) bontja, melyek mindegyike más és más hiba felderítésére alkalmas. A bemenetek partícionálása után, a tesztesetek definiálásakor a tesztelő az egyes partíciókból egyet-egyet választ. 37
Funkcionális tesztelési módszerek A határérték analízis: az ekvivalencia partícionálás finomítása. Míg az ekvivalencia partícionálás során minden ekvivalencia osztályból csak egy, az osztályt reprezentáló bemenetet választottunk, addig a határérték analízis definiálja, hogy melyik bemenetet (vagy bemeneteket) válasszuk az ekvivalencia osztályból. Azt mondja, hogy ha két partíció határos, vagyis a bemenetek természetes sorrendjében egymás után következő bemeneteket tartalmaz, akkor ezeket a partíció határán levő értékeket célszerű a tesztesetekben használt bemenetnek választani. Egy partícióból, ha több más partícióval határos, akár több bemenetet is használhatunk. Strukturális tesztelés A tesztelő nem állít fel explicit hibamodellt a felderítendő hibákról, kizárólag a hibamentes program működését, vezérlési szerkezetét modellezi a folyamat vezérlési gráf (Control Flow Graph - CFG) segítségével. A strukturális tesztelés alapfeltételezése szerint a programban létrejövő hibák valamilyen módon befolyásolják a program vezérlési szerkezetét, mely a működést leíró folyamat vezérlési gráf gráfpontjainak, ill. éleinek hibás (nem megengedett) bejárását jelenti. A használt hibamodell tehát egy folyamat vezérlési gráf alapján felállított implicit hibamodell. 38
Tesztelés menete ST esetén Tesztgenerálás: Teszt bemenetek generálása valamilyen mértékszám alapján. Teszt végrehajtás: Program egy vezérlési ágának végrehajtása. Eredmények összehasonlítása a specifikációban rögzítettel. Strukturális tesztelés előnyei Hibák keresése anélkül, hogy tudnám, milyen hibákat is keresek konkrétan. Matematikai modell: tesztelés hatékonyságának számszerű mérése. ST felhasználási területei: Vezérlés intenzív alkalmazások. Tervezési hibák felderítése. Elérhetetlen (dead) kódrészek felderítése. 39
Strukturális tesztelés módszerei Vezérlési szerkezet modellezése Programok vezérlési bonyolultsága Egyszerű strukturális tesztgenerálás Vezérlési szerkezet modellezése Folyamat vezérlési gráf (FVG) Control Flow Graph (CFG) Gráf pontok: utasítások + végpont. Egymás után végrehajtott utasításokat gráf él köti össze. Utasítások típusa: Szekvenciális utasítás. Elágazás utasítás (predicate statement). 40
CFG A CFG egy gráf modell. A gráf pontok az utasításoknak feleltethetők meg. Az utasításokat reprezentáló gráf pontokon kívül a program kezdetét, belépési pontját és végét, kilépési pontját is egy-egy gráf pont reprezentálja. A gráf származtatása igen egyszerű, az egymás után végrehajtható utasításokat egy-egy irányított gráf él köti össze. CFG A gráf-pontok két típusa: Egyszerű (szekvenciális) gráf pont, amelyből egyetlen gráf él indul ki, és egy szekvenciális utasítást reprezentál. Elágazás gráf pont, amelyből egynél több gráf él indul ki, és egy elágazás utasítás (predicate statement) feleltethető meg neki. A CFG esetén az egyszerűbb kezelhetőség miatt általában a kimenő élek számát kettőben szokták limitálni. Az elágazás utasításban mindig szerepel egy feltétel, mely meghatározza, hogy az utasítás végrehajtásakor melyik következő utasítás hajtódik végre. 41
CFG START 1 2 3 4 5 6 7 END Programok vezérlési bonyolultsága A programok vezérlési szerkezetének bonyolultsága igen eltérő lehet. A programok vezérlési szerkezetének bonyolultságát jellemző mérőszám, az ún. ciklomatikus komplexitás (CK, Cyclometric complexity). 42
Programok vezérlési bonyolultsága Ciklonometrikus komplexitás (CK) (Cyclonometric complexity) Független út: Olyan gráf út, amelyben létezik olyan pont v. él, amely más útnak nem eleme. Ciklonometrikus komplexitás definíciója: A FVG-ben található független gráf utak maximális száma. CK számítása Jelölés: G: gráf; V(G): CK ; E: élek száma; N: pontok száma; P: elágazás utasítások száma. V(G)= E-N+2 V(G)=P+1 (bináris elágazások esetén) 43
CK számítási példa E=11 N=9 V(G)=E-N+2=11-9+2=4 begin 1 2 P=3 V(G)=P+1=3+1=4 3 5 7 4 6 end Egyszerű strukturális tesztgenerálási algoritmus CFG generálása a kód alapján. CK számítása az CFG alapján. Független utak maximális (CK darab utat tartalmazó) halmazának generálása. Bemenetek generálása a független utak bejárásához. 44
Problémák tesztgenerálás során AZ CFG: ciklikus, vagyis kört tartalmaz, így elvben a végtelen sok út generálható az adott CFG-hoz. Nem generálható olyan bemeneti kombináció, amely egy adott út bejárását eredményezné az CFGben. Teszt hatékonyságának mérése A strukturális tesztelés alaposságának jellemzésére mértékszámokat lehet használni. A mértékszám egy arányszám: megmutatja, hogy a kiválasztott szempont szerint a tesztelhető elemek (egységek, tételek) mekkora részét teszteltük le, a korábban bevezetett terminológiát használva a feltételezett hibák mekkora részét fedtük le. 45
Mértékszámok Utasítás lefedettség: Az utasítások mekkora hányadát hajtottuk végre teszteléskor. Ág lefedettség (döntés lefedettség): A CFG ágainak mekkora hányadát fedtük le (hajtottuk végre) teszteléskor. Út lefedettség: A CFG-ban található utaknak mekkora hányadát fedtük le (hajtottuk végre) teszteléskor. SW tesztelés végrehajtása SW tesztelését több fázisban hajtják végre. Első fázis a modul tesztelés (unit testing). Integrációs tesztelés. Rendszerteszt. Míg az első két fázis tipikusan verifikáció, addig a rendszertesztet általában validálására használják. 46
Modul tesztelés Unit testing. A fázisban csak az egyes modulok specifikációját veszik alapul. Különösen munkaigényes és emiatt költséges fejlesztési fázis. Modul tesztelés A szoftvermodulok: önálló specifikációval rendelkező, más moduloktól függetlenül fordítható szoftver egységek. Strukturált program esetén ezek lehetnek eljárások, függvények, ill. azok csoportja, objektumorientált környezetben objektumok, ill. azok halmaza (clustere). 47
Modul tesztelés A modulok a kész rendszerben használják egymás szolgáltatásait, pl. az egyik modul meghívja a másik modul adott függvényét. Ekkor azt mondjuk, hogy az egyik modul függ a másik modultól. Modulok függősége grafikusan is ábrázolható. Modulok függősége A modul például függ a B a C és D moduloktól. A B C D E F G H I J 48
Modulok függősége A tesztelő elkészíti azon modulok biztosan hibamentesen (a specifikációban leírt módon) viselkedő egyszerűsített változatát, melyektől a tesztelt modul (SUT) függ. A szoftver modulok ilyen egyszerűsített megvalósítását nevezik stub-nak (csonknak). Teszt driver A modulok tesztelése csak úgy történhet, ha azokat működtetjük, azok szolgáltatásait meghívjuk. Ehhez létre kell hozni a megfelelő szoftver környezetet. Teszt driver-nek nevezzük azt a szoftver elemet, mely a tesztelés során a tesztelt szoftvert működteti. 49
Teszt driver Feladata: a tesztelt szoftver működtetése, annak bemeneti adatok biztosítása. A szoftver driver általában megvalósítja a kimenetek eltárolását, ill. más, szoftver viselkedését jellemző információ összegyűjtését. Teszt driver A stub-ok, ill. teszt drive-ek készítése: legmunkaigényesebb, így legköltségesebb része a tesztelésnek. Ha egy szoftver minden modulját önállóan szeretném tesztelni, akkor minden elemnek el kell készítenem a stub változatát, ill. minden elemhez készítenem kell egy teszt driver-t. Az ilyen típusú tesztelés az izolációs tesztelés. 50
Izolációs tesztelés teszt driver B C D tesztelt modul E stub F stub G stub H I J Tesztelési költségek csökkentése A teszt driver-ek, ill. stub-ok készítése költséges. Ezek készítését részben elkerülhetjük: ha az amúgy is megvalósítandó szoftver moduljaimat használom driver-ként, ill. stub-ként. Feltétlenül be kell tartanom a tesztelés azon szabályát, hogy tesztelés során a szoftvernek csak olyan komponensét használhatom (driver-ként vagy stub-ként), melynek helyes működése biztos, vagyis már átesett a tesztelésen. Két alap technika létezik, a többi lényegében ezek finomítása: top down tesztelés és bottom up tesztelés. 51
Top-down tesztelés A teszt driver-ek készítése kerülhető el. Teszt driver-ként mindig azokat a modulokat használom, melyek az adott tesztelés alatt álló modulomtól függenek. Először mindig a hierarchia legmagasabb szintjén álló modulomat kell tesztelni, majd sorban az alatta levő modulokat. Top-down tesztelés A driver (tesztelve) B (tesztelve) C (tesztelve) D tesztelt modul E stub F stub G stub H I J 52
Bottom-up tesztelés A teszt stub-ok készítése kerülhető el. Stub-ként mindig azokat a modulokat használom, melyektől az adott tesztelés alatt álló modulom függ. A tesztelést a függőségi hierarchia legalsó szintjén kell elkezdeni azokkal a modulokkal, melyek nem függenek más moduloktól. Ezeket letesztelve léphetünk tovább a hierarchia következő szintjére. Bottom-up tesztelés teszt driver B C D tesztelt modul E (tesztelve) F (tesztelve) G (tesztelve) H (tesztelve) I (tesztelve) J (tesztelve) 53
Tesztesetek definiálása Teszteset azonosító: a fejlesztési folyamat teljes menete során ezzel hivatkozhatunk a tesztesetre. Fontos, hogy tényleg ne változzon. Hibajelentések készítésekor, ill. teszt riportok összeállításakor látjuk hasznát. Regressziós tesztelésnél különösen hasznos. A tesztelt szoftver elem azonosítása, ill. a tesztelt funkció, viselkedés azonosítása, leírása. A tesztelt szoftver (SUT) teszteset végrehajtása előtt beállítandó állapotának leírása, szükség szerint a beállítás módja. Tesztesetek definiálása Teszteset végrehajtásához szükséges bemeneti adatok. Elvárt eredmény: hibamentes esetben várt kimenet, állapot, esetleg teljesítmény. Teszteset végrehajtásának előfeltételei: mely tesztesetet kell hibamentesen végrehajtani, ill. mely teszteset által tesztelt funkcióra épül az aktuális teszteset. A tesztelésnél alkalmazott szabványok előírhatnak további jellemzők megadását, pl. a teszteset definiálásakor alkalmazott tesztelési módszert. 54
Integrációs tesztelés A rendszer moduljait együtt tesztelik nagy hangsúlyt fektetve a modulok együttműködésére, interfészek vizsgálatára. Rendszerteszt A teljes rendszert valós adatokkal valós környezetben tesztelik. 55
Tesztadatok összeállításának szempontjai adatok körének meghatározása: napi adatok szélsőséges adatok tesztelési szintekhez eltérő adatok tesztállományok összeállítása elvárt eredmények meghatározása Tesztelés alapjai (terminológia) teszt driver: tesztelő rutin teszt csonk (stub): Tesztelt egység által használt más egység működését szimuláló rutin. teszt eset: egy adott hiba felderítésére szolgáló teszt 56
A programspecifikáció tartalma 1. 1. a programrendszer célja rendszercélok HW, SW környezet specifikációuser interface tervek menü- és struktúra tervek adatbázis (külsőleg definiált) tervezési feltételek 2. Hivatkozott dokumentumok szoftver dokumentáció rendszerleírás HW/SW szállítói információk technikai referenciák A programspecifikáció tartalma 2. 3. Tervezési specifikáció adatleírás (típus, struktúra) származtatott programstruktúra struktúrán belüli interfészek 4. Modulonkénti részletes specifikáció feldolgozási eljárások működési algoritmus leírása interfészspecifikáció (input, output) tervezési technológia felhasználandó modulok, hívás módja adatok köre és szervezési módja 57
A programspecifikáció tartalma 3. 5. File-szerkezetek, globális modell specifikáció külső file-szerkezet: file-ok, rekordok, szervezési és elérési mód globális adatok jegyzéke file/adat kapcsolatok 6. Folyamatok-modulok kapcsolatrendszere 7. Tesztelési előírások, dokumentáció tesztadatok, tesztelési utasítás tesztelési stratégia, integrációs teszt különleges előírások 8. Programegységek létrehozása (package) speciális átlapolás átalakítási feltételek Átállás Kísérleti futtatás Fokozatos átállás Párhuzamos feldolgozás Azonnali átállás 58
Átadás Az átadás programja, forgatókönyv Átadási információk Az átadás programja Különleges rendelkezések Átadási információk Az átadás tárgya Az átadás időpontja Az átadás helye Résztvevők Az átadási anyagok HW, SW dokumentáció, kézikönyvek Elfogadási feltételek, átvételi kritériumok 59
Az átadás programja Bevezető tájékoztató A rendszer bemutatása, elfogadási teszt (projektvezető és a megbízó) Az elfogadási teszt kiértékelése (megbízó) Döntés az elfogadásról Jegyzőkönyv készítése 60