A rendszerfejlesztés technológiája

A rendszerfejlesztés technológiája

Előadásvázlat

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.

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)

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

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

Ú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 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!)

A szoftverfejlesztés rendszerszervezési elemei

• elemzés (analízis),

• tervezés,

• implementáció,

• követés.

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.

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

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.

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

Tervezés

Alrendszerek azonosítása

Követelmények alrendszerekhez

rendelése

Alrendszerekinterfészének

definiálása

Alrendszerekfunkcionalitásának

meghatározása

Követelmények felosztása

A tervezés során a követelményektől eljutunk valamilyen módon az alrendszerekig.

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.

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.

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.

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.

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

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

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

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

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

Vízesésmodell• Előnyei:

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

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ázlatleírása

specifikáció

fejlesztés

validálás

kezdeti verzió

közbülső verziók

végleges verzió

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.

Evolúciós modell

• Előnyei– 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

Formális modell • A 70-es években alakult ki a vízesés

modell egy változataként.


formális specifikáció

formális transzformáció

integráció és rendszerteszt

rendszer-validáció

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.

Formális modell

• Előnye:

– 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

Ú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ó

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

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.

Inkrementális modell

vázlatos követelmények meghatározása

követelmények 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églegesrendszer

a rendszer nem teljes

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

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

Spirális modell

• Előnyei:– foglalkozik a kockázatokkal

– sokkal szisztematikusabban foglalkozik a projekttel

• Hátrányai:– nem a legtriviálisabb modell

– nagy rendszereknél javallott

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

• 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

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

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

Nem funkcionális követelményeknem-funkcionáliskövetelmények

termék-követelmények

szervezetikövetelmények

külsőkövetelmények

hatékonyságikövetelmények

használhatóságikövetelmények

megbízhatóságikövetelmények

hordozhatóságikövetelmények

telepítésikövetelmények

implementációskövetelmények

szabány-követelmények

együttműködésikövetelmények

etnikaikövetelmények

törvényikövetelmények

adatvédelmikövetelmények

biztonságikövetelmények

teljesítménykövetelmények

tárterületkövetelmények

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

Követelmények dokumentációja

• természetes nyelv

• diagramok (UML)

• leíró nyelvek: programnyelvekhez hasonló

• matematikai specifikáció

• hibrid megoldás

Rendszermodellek

• környezeti modellek (HOL)

• viselkedési modellek (HOGYAN)

• adatmodellek (MIVEL)

Környezeti modellek

• A rendszer határainak felderítése biztonságirendszer

bankautomatarendszer

karbantartórendszer

központinyilvántartór.

központiszámlázór.

számla-adatbázis

Igénybevételiadatbázis

Viselkedési modellek

• adatfolyam modellek: tipikus struktúrált modellek

• állapotátmenet modellek: tipikusan OO-modellek (adatfolyam modell az OO-ban nincs)

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.

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 megrendelő űrlap kitöltött megren-

delő űrlap

aláírt megren-delő űrlap

aláírt megren-delő űrlap

megrendelésrészletezése

megrendelésvégösszege +számla rögzítése

átvizsgált ésaláírt megren-delő űrlap

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

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

ER adatmodell

• 3 fő komponense van:

– egyed

– kapcsolat

– tulajdonságok

AT

Egyed elem az ER-benEgyed: 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ánjukTí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

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

opcionális

A B

kötelező az A oldalon

Kapcsolat elem az ER-ben

1:1

A B

N:M

ország - főváros tulajdonos - autó

1:N egy A-hoz több Bszínész - színdarab

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

normál

t

kulcs

t

összetett

t

t

t

többértékű

t

származtatott

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

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 ésrendszerkövetelmények

követelmények dokumentumai

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?

Követelmények feltárása, elemzése

szakterületmegismerése

követelményekösszegyűjtése

követelményekellenőrzése

követelményekosztályozása

fontossági sorrendbe állítás

ellentmondások feloldása

követelményekspecifikációja

követelmények dokumentációja

a folyamat belépési pontja

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

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

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

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)

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

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é

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

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

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.

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

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

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

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

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

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

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

Szakterületspecifikus architektúrák

• általános szakterületi architektúra

• referencia-architektúra

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

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

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ő

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)

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 rendszer/komponens interfésze

• a rendszer szolgáltatásokat vár, keresendő a komponens, ami ezeket nyújtja.

komponens

rendszer vagy másik komponens

A komponensek absztrakciós szintje

• funkcionális absztrakció

• lazán összefüggő entitások

• adatabsztrakció

• klaszterabsztrakció

• rendszerabsztrakció

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.

A komponens-orientált tervezés folyamata #2

• már a tervezés előtt keressük a komponenseket

• kompromisszum: követelménymódosítás

vázlatos rendszer-követelmények


követelmények módosítása a felderített komponenseknek megfelelően

architekturálisterv


a rendszer megtervezése az újrafelhasz-nálható koponenseknek megfelelően

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

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ó

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.

Szolgáltatás-orientált architektúra (SOA)

• ObjektumKomponensSzolgá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.

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

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

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

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.

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 interakciók

• közvetlen manipuláció

• menüpont kiválasztása

• űrlapkitöltés

• parancsnyelv

• emberi nyelvű vezérlés

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

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

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

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

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

Felhasználói dokumentáció

rendszer-értékelők

rendszeradmi-nisztrátorok

kezdő felhasználók

tapasztalt felhasználók

rendszeradmi-nisztrátorok

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

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

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

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

Tesztelés

• Hiányosságtesztelés: verifikációs

• Statisztikai tesztelés: használható validációsra is

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

Szoftvertesztelés tervezése


rendszer-specifikáció

rendszer-tervezés

részletestervezé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

átviteliteszt terve

rendszerintegrációs teszt terve

alrendszerinteg-rációs teszt terve

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

Á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

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

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

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

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.

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.

Feketedoboz teszt

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

outputteszt-eredmények

inputteszt-adatok

IE

OE

rendszer

Tesztesetek tervezése

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

inputok

rendszer

outputok

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.

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

A

B

T1

T2

T3

A

B

T1

T2

T3

C T4

A

B

T1

T2

T3

C T4

DT5

Integrációs teszt fentről lefelé

1. szint 1. szint

2. szint

2. szintű csonkok

3. szintű csonkok 3. szintű csonkok 3. szintű csonkok 3. szintű csonkok

2. szint 2. szint 2. szint

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

Integrációs teszt lentről felfelé

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

N. szint N. szint N. szint N. szint N. szint

N–1. szint N–1. szint N–1. szint

tesztelési sorozat

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

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.

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.

A tesztelés technológiai háttere

• tesztmenedzserek

• tesztadat-generátorok

• előrejelzők, jóslók

• dinamikus elemzők

• szimulátorok

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.

Minőség

• Minőségbiztosítás

– termékszabványok

– folyamatszabványok

• Minőségtervezés

• Minőségellenőrzés

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

Minőségi szabványok

• Az általános, ipari termékekre vonatkozó minőségszabvány: ISO9000

• Az ISO9000-3-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.

Documents

A rendszerfejlesztés technológiája