SW Minosegbizt

Dr. Sziray Jzsef Dr. Beny Balzs Heckenast Tams

SZOFTVER-MINSGBIZTOSTS

Kszlt a HEFOP 3.3.1-P.-2004-09-0102/1.0 plyzat tmogatsval.

Szerzk: Dr. Sziray Jzsef Szchenyi Istvn Egyetem, Informatika Tanszk

Dr. Beny Balzs Szchenyi Istvn Egyetem, Informatika Tanszk

Heckenast Tams Szchenyi Istvn Egyetem, Informatika Tanszk

Lektor: Gaul Gza Szchenyi Istvn Egyetem, Informatika Tanszk

Szerzk, 2007

Szoftver-minsgbiztosts A dokumentum hasznlata

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom Vissza 3


A dokumentum hasznlata

Mozgs a dokumentumban A dokumentumban val mozgshoz a Windows s az Adobe Reader meg-szokott elemeit s mdszereit hasznlhatjuk.

Minden lap tetejn s aljn egy navigcis sor tallhat, itt a megfelel hivatkozsra kattintva ugorhatunk a hasznlati tmutatra, a tartalomjegy-zkre, valamint a trgymutatra. A s a nyilakkal az elz s a kvet-kez oldalra lphetnk t, mg a Vissza mez az utoljra megnzett oldalra visz vissza bennnket.

Pozcionls a knyvjelzablak segtsgvel A bal oldali knyvjelz ablakban tartalomjegyzkfa tallhat, amelynek bejegyzseire kattintva az adott fejezet/alfejezet els oldalra jutunk. Az aktulis pozcinkat a tartalomjegyzkfban kiemelt bejegyzs mutatja.

A tartalomjegyzk hasznlata

Ugrs megadott helyre a tartalomjegyzk segtsgvel Kattintsunk a tartalomjegyzk megfelel pontjra, ezzel az adott fejezet els oldalra jutunk.

Keress a szvegben A dokumentumban val keresshez hasznljuk megszokott mdon a Szerkeszts men Keress parancst. Az Adobe Reader az adott pozci-tl kezdve keres a szvegben.

Szoftver-minsgbiztosts Tartalomjegyzk



Tartalomjegyzk

1. Bevezets ........................................................................................ 6

2. Szoftverminsgbiztosts............................................................ 9 2.1. Minsgi koncepcik................................................................................... 9 2.2. Minsgbiztostsi fogalmak .................................................................... 11 2.3. Szoftverminsg (Software quality) ........................................................ 11 2.4. Szoftver-mrszmok (metrikk) ............................................................ 12 2.5. Szoftver-megbzhatsg............................................................................ 19

3. Biztonsgkritikus rendszerek....................................................... 22 3.1. Alapfogalmak.............................................................................................. 22 3.2. Minsgi s megbzhatsgi kvetelmnyek.......................................... 23 3.3. Rendszerstruktrk.................................................................................... 27 3.4. A hardver redundancia megvalstsa..................................................... 29 3.5. A szoftver redundancia megvalstsa.................................................... 31 3.6. Az ELEKTRA tpus vezrlrendszer felptse s mkdse ......... 35

4. Szoftver-tesztelsi mdszerek ...................................................... 42 4.1. Tesztelsi alapfogalmak............................................................................. 42 4.2. Hibamodellek s rvnyessgi krk ...................................................... 43 4.3. A tesztek megtervezse ............................................................................. 45 4.4. A programtesztels pszicholgija s gazdasgossga (Glenford

Myers elvei)................................................................................................. 47 4.5. Funkcionlis tesztels ................................................................................ 53 4.6. Strukturlis tesztels .................................................................................. 63 4.7. Tesztminsgi mrszmok..................................................................... 71 4.8. A mdszerek sszekapcsolsa.................................................................. 75

5. Tesztelsi stratgik s folyamatok ............................................. 76 5.1. Szoftverfejlesztsi modellek ..................................................................... 77 5.2. Verifikci s validci.............................................................................. 85 5.3. A verifikci s a validci fzisainak tervezse.................................... 88 5.4. Egysgek, modulok tesztelse .................................................................. 91 5.5. Integrcis tesztels s rendszertesztels .............................................101 5.6. Validcis tesztels ..................................................................................105 5.7. A tesztels kltsge..................................................................................108

Szoftver-minsgbiztosts Tartalomjegyzk



5.8. Bizonylatols.............................................................................................111 5.9. A formlis mdszerek szerepe ...............................................................113

6. Objektum-orientlt szoftvertesztels .......................................... 118 6.1. Az OO rendszerek jellemzi tesztelhetsgi szempontbl ...............118 6.2. Tesztels nem OO rendszerekben ........................................................120 6.3. Hagyomnyos tesztelsi mdszerek alkalmazsa OO

krnyezetben ............................................................................................121 6.4. OO rendszerek tesztelsi techniki .......................................................122 6.5. Mrtkszmok hasznlata .......................................................................125 6.6. Konkrt tesztel rendszerek...................................................................127

Felhasznlt irodalom ...........................................................................................130

Szoftver-minsgbiztosts Bevezets



1. Bevezets

Az informatikban hatalmas fejlds ment vgbe az elmlt negyedszzad-ban. Aki ezt szakmailag vgiglte, szinte mr maga sem tudja elhinni, ami a 25 vvel ezeltti vilgban volt. A fejlds pontosan nyomon kvethet a szmtgpek s szmtgp-hlzatok hardvernek vonaln. Ez a msza-ki, tervezstechnolgiai s gyrtstechnolgiai fejlds megkrdjelezhe-tetlenl impozns. A nyomon kvethetsg elssorban annak ksznhet, hogy a hardver ellltsi folyamatai szigoran kttt, meghatrozott rendben, jl bevlt, kitapasztalt folyamatokba szortva mehetnek vgbe. A be nem vlt vagy tl drga j technolgik, irnyzatok igen hamar kiszo-rulnak a piacrl, s feledsbe merlnek. Ilyenek voltak pldul a bubork-memrik, vagy a kszb logikn alapul digitlis ramkrk.

Az informatikai rendszerek msik szerves sszetevje a szoftver. Ami azt illeti, a szoftver vonalon vgbement fejlds mg dntbben szmt bele a mai helyzet kialakulsba. Ezen a tren sokkal kevesebb volt a k-tttsg, mint a hardvernl. A fejlesztsbe jval szlesebb rtegek tudtak s tudnak ma is bekapcsoldni. Ezen tl mg olyan orszgok is, mint Ma-gyarorszg pldul, amelyek a hardverfejlesztsbe nem tudnak beleszlni. Az itt munklkod szakemberek szma rohamosan nvekszik, nagyon sok a szertegaz egyedi fejleszts, mg akkor is, ha ugyanazon a hardver plat-formon mennek vgbe. A fejleszts nagyobb szabadsgfoka teszi lehetv a szoftver rendszerek belthatatlan mrtk kibontakozst, fejldst, ami a mretekben, vagyis az utastsok szmban, valamint a bonyolult-sgban s az ehhez kapcsold teljestmnyben nyilvnul meg.

A nagy szabadsgfok, valamint az egyedi fejleszts s a nvekv bo-nyolultsg ugyanakkor megnveli a veszlyt annak, hogy a szoftver rend-szer hibsan mkdik. A hiba addhat a specifikci sorn elkvetett t-vedsbl, vagy aminek nagyobb az eslye, a programozs sorn elkvetett tvedsbl. A hibk kiszrse s kijavtsa a fejleszts elrehaladtval egy-re nagyobb rfordtst ignyel. Az ilyen rfordts mrtke exponencilisan nvekszik. Ezrt nagy jelentsge van annak, hogy a fejlesztsi folyamato-kat minl szigorbb technolgiai rendben, minl alaposabban megtervezve s kivitelezve hajtsuk vgre.

A szoftver rendszerek megbzhat zemeltetse, felhasznlsa teht szigor kvetelmnyeket tmaszt a fejlesztskre vonatkozan. Ebbe szo-rosan beletartozik az a minsgbiztostsi technolgia, amely a teljes fej-




lesztsi folyamatot vgigkveti, a specifikci megadstl a ksz rendszer zembe helyezsig. A minsgi s megbzhatsgi kvetelmnyek kielg-tse szksgess teszi azt, hogy a szoftvert n. verifikcis s validcis eljr-soknak vessk al. A verifikciban az egyes fejlesztsi fzisok kztti sszhang ellenrzse a feladat, mg a validcival a vgs rendszer ellen-rzsre kerl sor, annak eldntsre, hogy az mennyire felel meg a fel-hasznl ltal elrt kvetelmnyeknek.

A verifiklsi-validlsi tevkenysg pontos vgrehajtsa a kvetkez fbb elnykkel jr:

Segt annak eldntsben, hogy elkezdhetjk-e a fejleszts soron k-vetkez fzist.

A fejlesztsi folyamat korai szakaszban mutathat ki problmkat, hi-bkat.

A szoftver minsgre vonatkozan mindvgig tmpontokat, adatokat szolgltat.

Kimutathatja mr korn azt is, hogy a szoftver nem teljesti a kvetel-mnyeket.

Mindez a szoftver elre megtervezett ellenrzsvel, intenzv tesztelsvel kell hogy jrjon az egyes fzisokban.

Ebben a knyvben azokkal a tmkkal, mdszerekkel foglalkozunk, amelyek a szoftverfejleszts minsgbiztostshoz kapcsoldnak, belert-ve a fejlesztsi fzisokat ksr tesztelsi, verifiklsi mveleteket, msrszt pedig a ksz rendszerek tvtelvel kapcsolatos validlsi mveleteket.

A knyv 2. fejezete a szoftver-minsgbiztosts ltalnos krdseivel, az alapvet koncepcik s fogalmak ismertetsvel foglalkozik.

A 3. fejezet az n. biztonsgkritikus rendszereket trgyalja. Az ilyen infor-matikai rendszereknl a legfontosabb kritrium a biztonsgot megkvetel mkds, zemels. A fejezetben a biztonsgkritikus rendszerek tulajdon-sgait, a rjuk vonatkoz minsgi s megbzhatsgi kvetelmnyeket, valamint a megvalstsban alkalmazott rendszerstruktrkat foglaljuk ssze.

A 4. fejezet a legfontosabb szoftver-tesztelsi mdszereket vonultatja fel. Ezen bell bemutatja a figyelembe vett szoftver-hibk krt, valamint a hibk felfedsre alkalmazhat teszttervezsi megoldsokat. Mint isme-retes, a mdszerek lnyegben kt csoportba sorolhatk: Az egyik cso-portba a mkd program kls funkcionlis megnyilvnulsainak vizsg-




lata tartozik, mg a msikba a programok bels struktrjnak alapjn tr-tn vizsglatok.

Az 5. fejezet a tesztelsi stratgikat s az ezeket megvalst folyama-tokat trgyalja. Minderre a rendszerfejlesztsi s felhasznlsi folyamat letciklusa fzisainak bemutatsval egytt kerl sor. A fejezet foglalkozik a verifikci s a validci vgrehajtsval, az egysgek s modulok teszte-lsvel, a modulok sszeintegrlsa sorn alkalmazand tesztelssel, majd a teljes rendszer tesztelsvel, ill. validlsval.

A 6. fejezet az objektum-orientlt szoftverek ellenrzsnek megk-zeltsi mdjait, megoldsait foglalja ssze. Az objektum-orientlt fejlesz-ts az osztly szint tesztelst, valamint az osztlyok kztti tesztelst kveteli meg. Itt felhasznlhatk mindazok a megoldsok, amelyek a ha-gyomnyos fejleszts (n. procedurlis tpus) szoftverekhez alkalmasak, de ezen tlmenen szmos olyan mdszerre is szksg van, amelyek kife-jezetten az objektum-orientlt szoftverekhez kapcsoldnak.

A knyv vgn a felhasznlt irodalom felsorolsa tallhat.

Szoftver-minsgbiztosts Szoftverminsgbiztosts



2. Szoftverminsgbiztosts

2.1. Minsgi koncepcik A minsg tgabb rtelemben az emberisg trtnelmvel egyids, azon-ban korszer rtelmezse a mlt szzad elejn jelent meg, az ipari termels elterjedsvel. A minsg s a minsggy igazi rtelmezse csak napja-inkban alakul ki. A korszer minsgfogalom a termelsben s a fogyasz-tsban rdekelt szemlyek, ill. a trsadalom rtktlete arra, hogy a terme-lsi-fogyasztsi folyamat mennyire elgti az ignyeket. Ebbl kvetkezen a minsg rtk. A minsggy a termelsi-fogyasztsi folyamat mins-gnek szablyozsval foglalkozik. Napjainkban egyre nagyobb hangsly fordtdik a minsgbiztostsra, azaz a termels s a fogyaszts magas sznvonal minsgre, amely a fogyasztvdelem, s a fogyaszti ignyek kielgtse mellett a termel nyeresgt is eredmnyezi. Mindez nem csak a vllalkozs gazdasgi felemelkedst jelenti, hanem hasznos a trsadalom szmra is.

2.1.1. A minsg filozfiai rtelmezse A minsggy kzponti fogalma az igny-kielgtsi folyamat minsge. A minsg filozfiai szempontbl ktflekppen rtelmezhet: ltalnos, s rtkszemlletben.

A minsg ltalnos filozfiai rtelmezse a dolgok tulajdonsgokkal trtn lersa.

A minsg rtkszemllet filozfiai rtelmezse szubjektv, rtkren-den alapul, szemlyhez kttt. A minsg rtelmezshez meg kell fogalmazni a vizsglati szempontokat, meg kell mrni a tulajdonsgok rtkt, meg kell hatrozni az rtkrendet, s meg kell adni az objek-tum minsgt (ez az rtkrend alapjn az objektumra vonatkoz r-tktlet, minsts).

2.1.2. A minsg fogyaszti rtelmezse Az igny-kielgtsi folyamat, ezen bell elssorban a termk s a fogyasz-tsi folyamat minsgnek fogyaszti rtelmezse a minsg rtkszeml-let filozfiai rtelmezsn alapul. A fogyasztsi folyamat minsgt a fogyaszt szempontjbl azok a funkcik hatrozzk meg, amelyek alkal-mass teszik a termket a fogyaszts sorn a fogyaszt ltal ignyelt funk-




cik kielgtsre, vagyis biztostjk a fogyasztsi folyamat megfelel mi-nsgt. Ez mskpp a termk hasznossgnak is nevezhet.

A fogyaszti minsg sok mindenre kiterjed, gy a fogyasztsi cikkek esetn a tnyleges fogyasztsi ignyek mellett tartalmazza tbbek kztt a cmkzs, a csomagols, a trolhatsg, a megismerhetsg, a hasznlhat-sg, a karbantarthatsg, a szerelhetsg, a tartalkalkatrsz-ellts, a szer-vzellts s a garancia krdskrt.

2.1.3. A minsg termeli rtelmezse Az igny-kielgtsi folyamat, ezen bell elssorban a termelsi folyamat minsgnek termeli rtelmezse a minsg rtkszemllet filozfiai rtelmezsn alapul. Az igny-kielgtsi folyamat termeli minsge teht attl fgg, hogy a termelsi folyamat s a termk a termeli rdekeltek szempontjbl megfelel-e, gy a termels folyamata az rdekeltek szmra hasznos-e, gazdasgos-e, kellen veszlytelen-e.

2.1.4. A minsg trsadalmi rtelmezse Az igny-kielgtsi folyamat minsgnek trsadalmi rtelmezse szintn a minsg rtkszemllet filozfiai rtelmezsn alapul. Az igny-kielgtsi folyamat trsadalmi minsge teht attl fgg, hogy megfelel-e a trsadalom szmra, vagyis a termelsi s fogyasztsi folyamatok a trsa-dalom szmra kellen hasznosak-e s vdelmi, klnsen letvdelmi, valamint krnyezetvdelmi szempontbl veszlytelenek-e.

Az Eurpai Uni s a fejlett orszgok minsggyi szablyozsi gya-korlatban egyre nagyobb hangslyt kap a minsg trsadalmi rtelmezse. A minsg trsadalmi rtelmezse alapjn teht a minsggy magban foglalja a fogyasztvdelem mellett a biztonsgtechnikt, a munkavdel-met, az let s egszsgvdelmet, az erklcsvdelmet, a krnyezetvdel-met, tovbb a vagyon- s a tzvdelmet is. A minsg trsadalmi rtel-mezsben, felfogsban a fejlett orszgokban a vdelem mellett, az el-mozdts s a tmogats is benne foglaltatik.

2.1.5. A minsg minsggyi rtelmezse Az igny-kielgtsi folyamat minsge korszer minsggyi szemllet-ben egyrszt a termk s a fogyasztsi folyamat fogyaszti minsgt, azaz a fogyaszti ignyek kielgtst, msrszt a termelsi folyamat s a termk termeli minsgt, a hasznossgot, valamint az igny-kielgtsi folyamat trsadalmi minsgt, ezen bell elssorban a vdelmet s a tmogatst foglalja magban.




A j minsg ngyfle kvetelmny egyenslya (J. Cons megfogalma-zsban):

mszaki (fizikai, kmiai, biolgiai stb.) (technical) erklcsi (ethical) piaci (marketing) gazdasgi (economical) Cons rtelmezse a megfelelsgre, a trsadalmi rdekekre, a fogyaszti s a termeli ignyekre utal.

2.1.6. A minsg mrse A minsg, szubjektv volta miatt nehezen mrhet. A mrs nehzsgt a kvetkez problmk okozzk:

a minsget meghatroz tulajdonsgok mrse ltalban nem objektv a minsget meghatroz funkcik, tulajdonsgok jelents rsze nem

mrhet a minsts szubjektv, mivel a minsg nem ms, mint az emberek

rtktlete, s nincs trsadalmilag elfogadott rtkrend a minsts idben s krnyezettl fggen vltoz sokan megfelel httr ismeret hinyban minstenek, ami a mins-

ts jsgt ronthatja

A minsg alapvet rtk, ezrt a mrst nehezt problmk ellenre is mrni kell, amennyire ez lehetsges.

2.2. Minsgbiztostsi fogalmak

2.3. Szoftverminsg (Software quality) A szoftver is egy termel-folyamat vgtermke, ezrt a minsgbiztosts ezen esetben is elengedhetetlen felttel. Napjainkban mr egyre kevsb fogadnak el gyengbb minsg termket. A tapasztalhat szoftver-krzis egyik oka a minsgi kvetelmnyek vltozsa, a minsgi termkek k-zppontba kerlse. A minsggyi menedzserek feladata, hogy a megk-vetelt (elrt) minsget biztostsk. A minsgbiztosts jelenti a megfele-l eljrsok, s szabvnyok definilst, valamint annak ellenrzst, hogy ezeknek megfelelen trtnik-e a gyrts. A szoftverminsg egy tbbdi-menzis fogalom, amit nem egyszer definilni. Klasszikus rtelemben a




minsg azt jelenti, hogy a fejlesztsi folyamat a specifikcis kvetelm-nyeket kielgti (Crosby 1979). Idelis esetben ez a definci minden ter-mkre alkalmazhat lehetne, de a szoftverek esetben nehzsgek akadnak ezzel:

A specifikcinak a felhasznl ltal kvnt termk karakterisztikjt kell kvetni, azonban a fejlesztsi szervezetnek is vannak kvetelm-nyei, amelyek nem szerepelnek a specifikciban.

A szoftver specifikcik rendszerint nem teljesek. A minsg tervezsnek kritikus pontja a fontos minsgi jellemzk kiv-lasztsa, s annak megtervezse, hogy ezek hogyan rhetk el. A szoftver-minsg menedzserek 3 fajta tevkenysgrt felelsek:

Minsgbiztosts (quality assurance): szervezeti eljrsokat, valamint szabvnyokat kell rgzteni, amelyek j minsg szoftverekhez vezet-nek.

Minsgtervezs (quality planning): ki kell vlasztani az alkalmas elj-rsokat, s szabvnyokat, s ezeket illeszteni kell a specilis szoftver projektekhez.

Minsgszablyozs (quality control): biztostani kell, hogy ezeket az eljrsokat s szabvnyokat kveti a szoftverfejleszt csapat A szoftverminsget alapveten meghatroz sszetevk:

Minstsi, illetve kirtkelsi szempontok Minsgfaktorok (hordozhatsg, megbzhatsg, hatkonysg, fel-

hasznlsi knyelem, tesztelhetsg, rthetsg, mdosthatsg), mi-nsgjegyek

Szoftverjellemzk (eszkzfggetlensg, teljessg, pontossg, konzisz-tencia, hatkonysg, elrhetsg, strukturlhatsg, dokumentltsg, tmrsg, rthetsg, olvashatsg, bvthetsg)

Szoftvermrtkek, szoftver-mrszmok

2.4. Szoftver-mrszmok (metrikk) A szoftver-merszmok (metrikk) a szoftver rendszerekhez, folyamatok-hoz, vagy kapcsold dokumentcihoz tartoznak. A metrikk kt osz-




tlyba sorolhatk: az egyik az ellenrz metrika (control metrics), a msik a prediktor metrika (predictor metrics) (2.1. bra).

szoftver folyamat(software process)

menedzsment dntsek(management decisions)

ellenorzo mrs(control measurement)

szoftver termk(software product)

prediktor mrsek(predictor measurements)

2.1. bra. Prediktor s ellenrz metrikk

Az ellenrz metrikt a szoftver folyamatok ellenrzsnek kezelsre hasznljk (pl. a lemezhasznlat, vagy a felhasznlhat, illetve eltelt id). Ezen mrszmok becslse hasznlhat a projekt tervezsi folyamatok finomtsra. Az ellenrz metrika informcit nyjt a folyamat mins-grl, s ezrt kapcsoldik a termk minsghez.

A prediktor metrika a termk jellemzinek mrshez tartozik, amely a termk minsgnek elzetes megjsolsra hasznlhat. Pldul a termk kziknyvnek olvashatsga elre jsolhat az n. Fog-index vizsglat-val, vagy pldul a szoftver komponensek nyomon kvetsnek egyszer-sge megjsolhat a ciklomatikus komplexits mrsvel.

Idelis esetben a prdiktor metrika megengedi, hogy a szoftver n-hny kls tulajdonsgnak rtkt elre megjsoljuk. A kls jellemzk olyan dolgok, amelyek csak a szoftver zembe helyezse utn fedezhetk fel. A bels jellemzket azonban kzvetlenl a szoftverbl hatrozhatjuk meg. A kls jellemzk kzvetlenl nem mrhetk, ezrt feltteleznnk kell, hogy ltezik kapcsolat akztt, amit mrni tudunk, s amit tudni aka-runk.

A 2.2 bra mutatja a fontos kls minsgi jellemzket, valamint azokat a bels minsgi jellemzket, amelyek mrhetk, s amelyek kapcsoldhat-nak a kls jellemzkhz. (Az itt lthat kapcsolati sma Kitchenham-tl szrmazik, USA, 1990) Az bra feltnteti a kls s bels jellemzk kzti




kapcsolatot, azonban a kapcsolat milyensgrl nem mond semmit. Ahhoz, hogy a bels tulajdonsgok mrse hasznos prediktora legyen a bels szoft-ver karakterisztiknak, a kvetkez hrom felttelnek kell teljeslnie:

A bels jellemzket pontosan kell mrni. A mrt s a kls tulajdonsgi jellemzk kztt kapcsolatnak kell lenni. A kapcsolat rthet, vals, valamint egy formulval, vagy modellel

lerhat legyen.

Mindehhez mg annyit fznk, hogy egy szoftver bels minsgi jellemzi elssorban a fejlesztk szempontjbl fontosak, mg a kls jellemzk a felhasznlk szempontjbl.

Nyomonkvethetosg(Maintainability)

Megbzhatsg(Reliability)

Hordozhatsg(Portability)

Hasznlhatsg(Usability)

Eljrs paramterek szma

Ciklomatikus komplexits

Programmret kdsorban

Hibazenetek szma

Felhasznli segdlet hossza

2.2. bra. Lehetsges kapcsolatok

a bels s kls szoftverjellemzk kztt

A modell formalizls az sszegyjttt adatok alapjn a modell funkcion-lis formjnak meghatrozst jelenti (pl. lineris, vagy exponencilis stb..), a modellben szerepl paramterek meghatrozst, ezek belltst a ren-delkezsre ll adatok hasznlatval. Ezltal a modellfejleszts statisztikai technikai gyakorlatot kvetel meg, teht ebbe a folyamatba statisztikusokat is be kell bevonni.

Jelenleg a szoftveriparban igen kis mrtkben hasznlnak csak metri-kkat, azonban a minsgi fejleszts fontos szerepe miatt egyre inkbb




megn az igny erre. Szmos nagy cg (pl. a HP, AT&T) gyjti s hasznl-ja ezeket a mrszmokat a fejlesztsek folyamn. A kzppontban legin-kbb a programhibk, valamint a verifikcis s validcis eljrsokhoz tartoz mrszmok llnak. Ezrt ahogyan risi a hajlandsg a mennyi-sgi informcis fejlesztsekre, gy nvekszik a metrikk ipari hasznlat-nak is a fontossga.

2.4.1. Termk minsgmrtke A szoftvermrsekben rszt vev szervezeteknek sokkal inkbb kell t-maszkodni a loklisan gyjttt adatokra, mint megbzni a kls tapasztala-tokban. Ahhoz, hogy felfedezzk, hogy egy bizonyos metrika egy termk minsgnek hasznos prediktora, egy minsgbiztost csoportnak kell kirtkelni a metrikt, loklis adatokat hasznl szisztematikus mdon, a helyi eljrsokat s szabvnyokat is figyelembe vve.

A 2.3. bra mutatja a mrszmok hasznlatnak folyamatt a minsg elrejelzsre. Alapveten a rendszer minden egyes komponenst fgget-lenl vizsgljk, s a mrszmok klnbz rtkeit sszehasonltjk, mind egymssal, mind pedig egy rgebbi projektbl szrmaz adatokkal. Rendhagy mrseket kellene hasznlni, hogy kzppontba a minsgi problmkkal rendelkez komponensek minsgbiztostsa kerljn.

mrsek vlasztsa

a kirtkelendo komponensek kivlasztsa

komponensek karakterisztiikjnak

mrse

rendhagy mrsek meghatrozsa

rendhagy komponensek vizsglata

2.3. bra. A termk mrsnek folyamata




Ilyen metrikkat hasznlnak tervezs, valamint program s dokumentci kirtkelsre. A tervezs kirtkelsnek metrikjt alkalmazzk a specifi-kcikban hasznlt grafikus jellsekben is. A dokumentcis metrika, mint a Fog-index alkalmazhat termszetes nyelv specifikcikban.

2.4.2. A tervezs minsgmrtke Sok fontos tervezsi tulajdonsg van, de a legfontosabb ezek kzl a kar-bantarthatsg. A minsgbiztosts ezrt leginkbb a hibadetektlssal, valamint a karbantarthatsg kirtkelsvel foglalkozik. A karbantartha-tsgot nem tudjuk kzvetlenl mrni. A tervezs karbantarthatsga kapcsoldik:

A kohzihoz (Cohesion): A komponens rszei milyen szorosan kap-csoldnak?

A csatoldshoz (Coupling): Mennyire fggetlen a komponens? Az rthetsghez (Understandability): Milyen knny megrteni a

komponens funkcijt? A beilleszthetsghez (Adaptability): Milyen knny a komponenst

lecserlni?

A kohzi egy egyszer minsgi fogalom, de nehz a kirtkelse a kom-ponens cljnak megrtse nlkl. A komponensek csatoldsa mrhet a komponensek kzti kapcsolatok szmnak figyelsvel, ha egy megfelel jellst hasznlnak a tervezsi folyamatban. Sem a komponensek rthet-sge, sem az alkalmazhatsga nem mrhet kzvetlenl. Azonban kap-csolat van e tulajdonsgok, s a komponens komplexitsa kztt. A komplexits mrse lehetsget biztost arra, hogy egymssal sszehason-ltsuk a komponensek rthetsgt s alkalmazhatsgt, nhny szab-vnyt is figyelembe vve.

Constantine s Yourdon (1979) javaslatra a tervezs trstsa megha-trozhat a tervezsi komponensek fan-in, s fan-out mrsvel. A fan-in azon komponensek szma, amelyek ezt a komponenst meghvjk, a fan-out pedig azon komponensek szmt jelenti, amelyeket a komponens meghv.

Henry s Kafura javasolta a komponens komplexitsnak meghatro-zsra a kvetkez kpletet az informcis Fan-in, valamint Fan-out-okkal:

Complexity = Length (Fan-in Fan-out)2




ahol, a length a hosszsgnak egy mrtke, ami lehet pl. a programkd sorainak szma is

Henry s Kafura Unix rendszer hasznlatval validltk a metrikjukat, s azt javasoltk, hogy a potencilisan hibs komponenst is megenged rendszer mrt komplexitst is meg kell hatrozni. A metrika magas rt-ket mutatott azokban a komponensekben, amelyek a rendszerproblmk viszonylag magas szmt okoztk, s ez magas karbantartsi kltsget eredmnyezett.

A metrika alapvet htrnya viszont az, hogy a komplexitsra nulla r-tket ad, ha az eljrsnak nincsenek kls klcsnhatsai. A komponensek a legalacsonyabb szinten nem tudnak ms komponenseket meghvni, azonban klcsnhatsba lphetnek a hardverrel, s ezltal bonyolultt vlnak. A Fan-in, valamint a Fan-out teljesen egyrtelm definilsa nehz.

Henry s Kafura metrikja szmos fggetlen tanulmny trgya lett a ksbbiekben. Ezek vizsgltk, hogy vajon ez a metrika jobb-e a tbbi egyszer metriknl, mint pl. a mret, vagy a vgsok szma, ezen kvl meg prbltk kitallni, hogy vajon a strukturlis komplexits hasznos prediktora-e a fejlesztsi idnek.

A Fan-in/Fan-out nem teljesen megbzhat mrtk a tervezsi min-sgre, de ezen metrikk hasznosak a hibs komponensek kiemelsre a tovbbi analzis szmra. Ha valamelyik komponensnek klnsen magas rtke van ebben a metrikban, akkor ez azt jelenti, hogy tlsgosan bo-nyolult.

2.4.3. A program minsgmrtke A programnak hibamentesnek valamint karbantarthatnak kell lennie. A szoftver-mrsekkel foglalkoz legtbb munka termszetesen a program analzist helyezi a kzppontba, aminek az oka, hogy a program egyr-telm nyelven van megfogalmazva, msrszt meglehetsen nyitott azokra eszkzkre nzve, amelyekkel a programrl adatokat gyjthetnk. A programban lv hibk megjslsra az albbi metrikk hasznlhatk:

Kdhossz (Length of code): a program mretnek mrtke. ltalban a nagyobb mret programkd tbb hibalehetsget rejthet magba.

Ciklomatikus komplexits (Cyclomatic complexity): a programkomp-lexits ellenrzsnek a mrtke. (A programban lv klnbz vg-rehajtsi utastssorozatok szmt jelenti.) Ez a komplexitsi mr-szm kapcsoldhat a program rthetsghez is.




Azonostk hossza (Length of identifiers): ez a programban hasznla-tos klnbz azonostk tlagos hossznak a mrtke. Minl hosz-szabb az azonost, annl tbb jelentst hordoz, teht jobban rthet a program.

Feltteles szerkezetek mlysge: a programban szerepl if-utastsok mlysgnek, begyazottsgnak a mrtke. Minl mlyebbek az if-utastsok, annl nehezebben rthetek, teht annl nagyobb a hiba-forrs.

A program mretnek mrse hasznlhat a minsgbiztostsi eljrs r-szeknt. Egy szabvnyban adtak egy fels korltot a komponens mretre vonatkozlag. Azok a komponenseket, amelyek ezt tlhaladtk, azokat jra kell tervezni, vagy pedig jabb rszletes analzis al vonni. Azonban a mret az egyik legegyszerbb metrika, s a legknnyebb gyjteni, Kitchenman (1990) szerint ez legalbb olyan j indiktora a rendellenes komponensek-nek, mint ms bonyolultabb metrika.

Egy eljrs ciklomatikus komplexitsa a komponensek bels komplexi-tsnak mrtke. E metrika alacsony rtke a program rthetsgvel fgg ssze. A ciklomatikus komplexits, mint a teljes kr komponens-komplexits mrtke kt htrnnyal br:

A program dntsi komplexitst mri, amely feltteles utastsokkal, valamint elfelttelekkel van meghatrozva. Ha a program adat-orientlt, akkor a ciklomatikus komplexitsra alacsony rtk addik, vi-szont ettl mg mindig elg komplex, s nehezen rthet.

Ugyanazon sllyal szerepelnek a begyazott, s nem begyazott ciklu-sok. Azonban a mlyen begyazott feltteles struktrkat nehezebb megrteni, mint a nem-begyazottat.

Oviedo (1980) kidolgozott egy program-komplexitsi mrszmot, amely szerint a komponens komplexitsa a kvetkez formulval becslhet meg:

C = aE + bN,

ahol a s b konstans egytthatk, s E a vezrlsi folyamatgrf leinek szma, N: olyan adatokra val hivatkozsok szma, amelyek nincsenek deklarlva

a komponensben.




J programozsi stlusban mindig jelentssel br azonostkat hasznlnak. Ezrt a program rthetsge nvelhet hosszabb nevek alkalmazsval, termszetesen egyb ms faktor is ltezik, ami nveli a program olvasha-tsgt, mint pl. a megjegyzsek rsa. Fontos lenne programozsi szab-vnyban definilni az azonostk hosszt is.

2.4.4. Dokumentcis minsgmrtk A szoftverhez kapcsold dokumentci minsge legalbb olyan fontos, mint a szoftvernek magnak a minsge. Gunning (1962) adta ki a Fog- indexet, ami az olvashatsg mrtke. A Fog-index a mondatok hosszn, s a nehz szavak szmn alapul, ahol a sz nehzsgt a szban tallha-t hangok szma adja. Ez hasznos indiktora lehet a dokumentci olvas-hatsgnak. Ez klnsen akkor hasznos, ha egy dokumentcinak tbb szerzje van. A dokumentci rszei kzti stlusbeli klnbsgeket ki kell emelni, s ki kell javtani.

2.5. Szoftver-megbzhatsg A szoftver rendszerek legfontosabb jellemzje a megbzhatsga. Napja-inkban minden rendszer esetben a minsg alapvet kvetelmny. A rendszerhibk a szoftverfejleszts kltsgt nvelik, mivel a megbzhatat-lan szoftver a vgfelhasznlnak nagy kltsgbe kerlhet.

Formlisan a megbzhatsgot egy specilis clra egy adott krnyezet-ben egy adott id alatti hibamentes mveletek valsznsgeknt definil-jk. Pl. a replgp vezrlsi szoftvernek 99,99%-os megbzhatsgnak kell lennie egy trs tlagos replt sorn. Azonban a megbzhatsg formlis defincija nem mindig van sszhangban a felhasznlk szoftver tapasztalatval. A felhasznlk nem figyelik az sszes azonos fontossg szolgltatst, viszont a rendszert megbzhatatlannak tarthatjk, ha az nem mkdik bizonyos kritikus krlmnyek kztt.

A szoftver-megbzhatsg fggvnye a szoftver bizonyos felhasznli ltal tapasztalt hibk szmnak. A szoftver hiba (failure) a szoftver futsa kzben jelentkezik. Ez az eset, amikor a szoftver nem teljesti a felhaszn-l ltal elvrt szolgltatst. A failure s a fault nem ugyanaz, de gyakran felcserlve hasznljk ket.

Szoftver hiba (fault) lehet programozsi vagy tervezsi hiba, amikor is a szoftver nem felel meg a rendszer specifikcinak. Ezek lehetnek mg dokumentcis, vagy specifikcis hibk is. Azaz a szoftver nem gy vi-selkedik, ahogyan a felhasznl elvrn. A szoftver hibk statikusak. Ezek




a program kd tulajdonsgai, amelyek a program fellvizsglatval felfe-dezhetk.

A szoftver hiba (fault) okozza a szoftver rendellenessgt (failure), amikor a hibs kd olyan bemeneti halmazzal fut, amely a szoftver hibt eredmnyezi. A kd amgy a legtbb bemenetre helyesen fut le.

A szoftverrendszer nem ms, mint egy lekpezs, egy input halmazbl egy output halmazba, azaz a programnak sok inputja lehet, amire a rend-szer vlaszkpp adja az outputot, vagy az output-halmazt. Az input hal-maz egy rszhalmaza tartalmazza azokat az inputokat, amelyek hatsra a program rossz outputokat generl. A szoftver megbzhatsga pedig an-nak a valsznsghez kapcsoldik, hogy a program egy bizonyos futtat-sa sorn a rendszer inputja elemei-e annak a rszhalmaznak, amelyek a hibs outputokat okozzk

Bonyolult kapcsolat ll fenn a vizsglt rendszer megbzhatsga, s a szoftver hibk szma kztt. Mills (1987) megmutatta, hogy a szoftver hibk nem egyforma valsznsggel okozzk a szoftver rendellenessgt. Rendszerint vannak olyan bemenetek, amelyeket nagyobb valsznsggel hasznlnak, s ha ezek a bemenetek nincsenek benne abban a halmazban, ami a szoftver hibt okozzk, akkor nem lesz rendellenessg. Teht a program megbzhatsga leginkbb a hibs kimeneteket okoz bemen adatok halmaztl fgg.

A megbzhatsg fgg a hasznlat kzbeni hibafellps valsznsg-tl is. Ha a szoftver ritkn hasznlt rszeibl eltvoltjuk a hibkat, akkor a megbzhatsg csak kis mrtkben nvekszik (a termkhibk 60%-nak eltvoltsa 3%-os megbzhatsgi nvekedst eredmnyez csak).

Ezrt a program hibkat is tartalmazhat, de mgis lehetsges az, hogy a felhasznlk szmra megbzhat, mivel nem jelentkezett rendellenessg a programban. A tapasztalt felhasznlk gyakran dolgoznak olyan krnye-zetben, ahol olyan hibk vannak, amikrl tudjk, hogy rendellenessget okozhatnak, ezrt megprbljk elkerlni ket.

Mivel a programot a felhasznlk klnbzkppen klnbz kr-nyezetben hasznljk, ezrt ugyanaz a program bizonyos felhasznlk szmra megbzhat, mg esetleg ms felhasznl szmra (aki hibt oko-z bemen adatokat hasznl) megbzhatatlan.

2.5.1. Formlis mdszerek Megbzhatbb szoftvert eredmnyez, ha formlis mdszereket hasznlunk a szoftverfejlesztsre, mert gy knnyebben elkerlhetjk az anomlikat.




Azonban a formlis specifikci mg nem garantlja, hogy a gyakorlati hasznlatban a szoftver megbzhat lesz. Az okok a kvetkezk:

A felhasznlk valdi ignyeit a specifikci nem mindig tkrzi teljesen. A bizonyts is tartalmazhat hibt Ha a rendszert nem gy hasznljk, ahogyan elre lthat volt, akkor a

bizonyts is hibs lehet.

A megbzhatsg nvelse rdekben tett tovbbi fejlesztsek, tervezsek drasztikusan megnvelhetik a kltsgeket. A valsgban lehetetlen lemrni s igazolni, hogy a rendszer 100%-osan megbzhat, azonban ha megbz-hatsgi kvetelmnyeket tovbb nveljk, akkor a kltsg exponencilisan fog nvekedni. Termszetesen a megbzhatsg nvelse gyakran a prog-ram hatkonysgnak cskkenst is okozhatja, pl. nvekszik a program a futsi ideje, mert gyakran extra redundns kdokat is kell hasznlni a kiv-teles felttelek megvalstsra. Azonban gyakran a megbzhatsg elnyt lvez a hatkonysggal szemben a kvetkez okok miatt:

A szmtgpek jelenleg olcsk s gyorsak A felhasznl hajlamos arra, hogy eldobja a nem megbzhat szoftve-

reket A rendszerhibk kltsge risi lehet A nem-megbzhat rendszert nehz fejleszteni A gyenge hatkonysg elre megjsolhat A nem-megbzhat szoftverek informcivesztst okozhatnak

Szoftver-minsgbiztosts Biztonsgkritikus rendszerek



3. Biztonsgkritikus rendszerek

Ebben a fejezetben a biztonsgkritikus informatikai rendszerekkel fogla-kozunk. A szoftver technolgia terletn azrt van kiemelt jelentsge az ilyen rendszereknek, mivel ezekben jelentkezik a legnagyobb mrtkben a fejlesztsi s tesztelsi feladatok szigor elrsokhoz kttt vgrehajts-nak ignye. Az ebbe a kategriba tartoz szoftverekre rvnyes elrsok sorbl nem mindegyik vonatkozik a ms kategrij szoftverekre, hanem azoknak csak egy rsze. A verifikcis s validcis folyamatok a bizton-sgkritikus rendszereknl hajtandk vgre a legnagyobb gonddal, hozzr-tssel s rfordtssal.

3.1. Alapfogalmak Biztonsgkritikus rendszer: Olyan informatikai rendszer, amely azzal az elsdleges kvetelmnnyel mkdtetend, hogy ne veszlyeztesse az em-beri letet, egszsget, ne okozzon gazdasgi vagy krnyezeti krokat. Ti-pikusan ilyenek a vasti llomsirnyt kzpontok, az atomermvek vezrlst, rhajk, rreplk irnytst, replgpek irnytst ellt rendszerek, valamint a krhzakban, bankokban, hadszatban (pl. cirkl rakta) alkalmazott informatikai rendszerek.

A felsorolt pldkban jl lthat az alkalmazott rendszerek hibs m-kdsbl szrmaz krok milyensge. Egy banki alkalmazs risi anyagi krokkal jrhat, egy vegyipari folyamat krnyezetei krt okozhat, hadszati eszkz esetben pedig a civil lakossgnak okozott vesztesg jhet szba.

A biztonsgot eredmnyez mkds mellett a msik legfontosabb tu-lajdonsg a megbzhatsg. Csak nagy megbzhatsg rendszerek alkalmaz-hatk eben a kategriban. ltalban 24 rn keresztl tart folyamatos zemelsre van igny. A biztonsg elrshez n. hibatr rendszerek alkal-mazsra van szksg.

Hibatr rendszer: Egy informatikai rendszer hibatr, ha kpes el-vgezni, ill. tovbb folytatni elrt feladatnak helyes vgrehajtst hard-ver-meghibsodsok s szoftver-hibk jelenlte esetn. A hibatrs nem azt jelenti, hogy a rendszer ugyanazzal a hatsfokkal, teljestmnnyel m-kdik hibsan is, mint hibamentesen, hanem azt, hogy a teljestmnye le-cskkenhet, esetleg nem mindegyik funkcijt ltja el maradktalanul, vi-szont a legfontosabb elrt feladatait mg vgre tudja hajtani.




A hibatr rendszerek tervezsekor bizonyos tervezsi clokat kell el-rni, amelyek elre megadott kvetelmnyek teljestst szolgljk. Ezek a kvetelmnyek klnbz matematikai, valsznsg-szmtsi mutatk minimlis rtknek elrst rjk el. A kvetkez alpontban ezeket a mutatkat soroljuk fel, s definiljuk.

3.2. Minsgi s megbzhatsgi kvetelmnyek Az albbiakban felsorolt mutatk szmszer rtknek meghatrozsra pontosan kidolgozott mrsi, vizsglati s szmtsi eljrsok lteznek, amelyekkel ebben a knyvben nem foglalkozunk.

Megbzhatsg (Reliability): Annak feltteles valsznsge, hogy a rendszer hibtlanul mkdik a [t0, t] idintervallumban, feltve, hogy a t0 t idpontban hibtlanul mkdtt. A megbzhatsgot ler valsz-nsgi fggvny jele R(t).

A megbzhatsgi rtk teht annak a valsznsgt fejezi ki, hogy a rendszer a [t0, t] idintervallumban vgig hibtlanul mkdik. Ez az rtk az intervallum hossznak a nvekedsvel nyilvnvalan cskken, hiszen az elektronikus rszegysgek az zemeltetsk, ignybe vtelk elrehalad-tval egyre inkbb elhasznldnak, elregszenek. A szoftver rsz elrege-dsrl, megbzhatsgi rtelemben, termszetesen nem beszlhetnk.

Ezt a paramtert elssorban olyan rendszerek jellemzsre hasznljk kiemelten, ahol egy rvid idre sincs megengedve a hibs mkds, vagy pedig nincs md a javtsra. Az elbbi felttelre plda egy rvid replsi idej replgp, ahol az intervallum 10 ra. Erre vonatkozan el van rva az

R(t) 0,9999999 = 0,97 rtkszint. Egy nem javthat rszondnl a mkdsi id 10 vet is kitehet. Ebben az esetben a kvetelmny a 10-ves peridus vgn:

R(t) 0,95. A megbzhatsg s a hibatrs nem ugyanazt jelenti. A hibatrs olyan technika, amely javtja a megbzhatsgot, de ettl mg nem biztos, hogy valban magas lesz a megbzhatsg. Ha egy rendszer ki tud vdeni hard-ver hibkat, de azok nagy gyakorisggal jelentkeznek, akkor az R(t) rtke mg alacsony is lehet. Msrszrl pedig, ha egy nagy megbzhatsg rendszerbe nincs beptve hibatrs, akkor az els hiba fellpstl kezdve rosszul fog mkdni.




Rendelkezsre lls (Availability): Annak valsznsge, hogy a rendszer helyesen mkdik a t idpontban, vagyis a t idpontban rendel-kezsre ll. A rendelkezsre llst ler valsznsgi fggvny jele A(t).

Mint lthat, az R(t) s az A(t) fggvny kztt az a klnbsg, hogy az elbbi a t idpontig tart folyamatos helyessget fejezi ki, mg az utbbi csak azt, hogy a t idpontban legyen a mkds helyes. Ezt megelzen lehetett hibs is.

Az A(t) mrszm rtke ott lehet fontos, ahol az informatikai rend-szert nem llandan hasznljk egy feladatra, hanem gyakori megszakt-sokkal. Ilyen esetekben megnvekszik a kzbens karbantarts s javts szerepe, amely a rendelkezsre lls magas szinten tartst szolglja.

Biztonsgossg (Safety): Annak valsznsge, hogy a rendszer he-lyesen vagy hibsan mkdik a t idpontban, de oly mdon, hogy nem veszlyeztet emberi letet, nem okoz anyagi vagy krnyezeti krt, s nem befolysolja krosan ms rendszerek mkdst. Msknt fogalmazva: Annak valsznsge, hogy a rendszer a t idpontban biztonsgosan m-kdik. A biztonsgossgot ler valsznsgi fggvny jele S(t).

Ez a paramter igen szorosan sszefgg a hibatrssel. Elfordulhat ugyanis, hogy az informatikai rendszerben komoly meghibsods lp fel, aminek kvetkeztben mr nem lesz kpes az elrt funkciit elltni. Eb-ben a helyzetben a biztonsg fenntartsa gy oldand meg, hogy a rend-szer olyan sorrendben hagy fel, egyms utn, a funkcik elltsval, ami a katasztrfa elkerlst teszi lehetv. Ez a fokozatos lepls esete (angol elnevezssel: graceful degradation). A fokozatos lepls egy rendszer azon kpessge, hogy automatikusan tudja cskkenteni teljestkpessgt, a hardver- s szoftver-hibk hatsnak ellenslyozsra.

A msik elterjedt vszmegolds az, hogy a rendszer, mg utols intz-kedseknt mindent gy llt le, hogy a katasztrfa semmikppen ne tud-jon bekvetkezni. Tipikus plda erre a vastirnyts, ahol a lellts azzal jr, hogy a vezrls hatsra egyik vonat vagy szerelvny sem mozoghat.

Teljestkpessg (Performability): Annak valsznsge, hogy a rendszer teljestkpessge a t idpontban elri vagy meghaladja az L szin-tet. A teljestkpessget ler valsznsgi fggvny jele P(L, t).

Ez a paramter azt fejezi ki, hogy a hiba esetn milyen cskkent szin-ten kpes mg a rendszer mkdni. Pldul: tbbprocesszoros szmt-gpnl egy-egy processzor kiesse a szmtsi sebessget cskkentheti. Ugyanilyen hatssal jr a memriaterletek kiesse is. Ilyen esetekben az L




rtke lehet a sebessg, a jl mkd processzorok szma, vagy a megma-rad memriaterlet.

A fokozatos lepls megvalstsa nem ms, mint a teljestkpessg elre megtervezett mdon val fokozatos cskkentse, a biztonsg fenn-tartsa rdekben.

Karbantarthatsg (Maintainability): Annak valsznsge, hogy a meghibsodott rendszer jra mkdkpess tehet t idtartam alatt. Eb-be az idbe beletartozik a hiba helynek meghatrozsa, a fizikai javts vagy csere elvgzse, valamint az jraindts. A karbantarthatsgot ler valsznsgi fggvny jele M(t).

Az M(t) rtknek magas szinten tartsa felttlenl megkveteli a bep-tett ntesztelst (built-in self-testing, BIST), valamint az automatizlt diagnzis elvgzst, amely a hiba helynek meghatrozsra irnyul. A tesztelsi s hibalokalizcis folyamatok vgrehajtshoz kln hardver egysgek s kln szoftver felhasznlsra van szksg, ahol mindezek a hibatr rendszer integrns rszt kpezik.

A fentiekben felsorolt paramterek mellett igen fontos tulajdonsga egy rendszernek a tesztelhetsg (testability) is. A tesztelhetsg azt a lehet-sget jelenti, hogy vizsglatok, tesztek segtsgvel meg tudjuk hatrozni a rendszer egyes mkdsi tulajdonsgait. Ez lehet pldul a mkdsi se-bessg ellenrizhetsge, vagy pedig ami a leginkbb fontos, annak meg-hatrozhatsga, hogy hibs-e a mkds.

A tesztelhetsg mrtke azt fejezi ki, hogy mekkora rfordtssal, ne-hzsggel jr egy-egy tesztelsi folyamat elvgzse. Ehhez a fogalomhoz igen nehz jl hasznlhat kvantitatv mrszmot rendelni, ilyen mr-szm jelenleg nincs mg definilva. Nyilvnval minsgi cl a minl gyor-sabb s knnyebb vgrehajthatsg. Erre vonatkozan kln mdszerek, ajnlott vagy elrt tervezsi megoldsok llnak rendelkezsre, ill. folyama-tosan kerlnek kidolgozsra. Ennek tmakre a tesztelhetsgre val tervezs (design for testability), amivel itt nem foglalkozunk.

A hibatrsre vonatkozan ngy f alkalmazsi terletet lehet megk-lnbztetni. Ezek a kvetkezk:

1. Hossz lettartam alkalmazsok

Az ide sorolhat berendezsek tbb ves idtartamban mkdnek, ltal-ban a javtsra kevs lehetsggel. Ilyenek: Ember nlkli rrepls, m-holdak, rszondk. Egy-egy rszonda akr tz ven tl is teljesti kldet-




st, amikor tvoli bolygk kzelbe kell jutnia. Mint mr emltettk, a megbzhatsgi rtknek 95% felett kell lenni mg ilyenkor is.

Az rszondkon a biztonsgos mkds elrse rdekben mindegyik egysgnek, blokknak van msodlagos tartalka. Ez nemcsak az informati-kai egysgekre, hanem a klnbz navigcis, tvmr, rdis, stb. blok-kokra is fennll.

2. Kritikus szmtsok

Ez a felhasznlsi md ppen az ellenkezje az elbbinek. Itt az a fontos, hogy arra a viszonylag rvid idtartamra, amg egy kritikus mkdsi, szmtsi szakaszban zemel a rendszer, a megbzhatsga garantltan magas legyen. Pldk:

rkompnl a felszlls s leszlls idejre nem szabad hibnak fellpni, mert a komp elveszhetne vgleg.

Vegyi zem szablyoz rendszere: egy technolgiai folyamat kritikus szakaszban megnhet a robbansveszly. Erre a szakaszra a hibtlan mkdst minl inkbb el kell rni.

Replsirnyt rendszer, amely a replgp fedlzetn helyezkedik el. A fenti esetekre az elrs a 95 % feletti megbzhatsg.

3. Elhalasztott karbantarts

Az olyan esetekre rvnyes, amikor a karbantartsi mveleteket igen nehz, vagy igen kltsges elvgezni. J pldk erre a tvoli helyeken zemeltetett feldolgozllomsok, vagy az rbeli alkalmazsok. Egy-egy ilyen rendszer karbantartsa egy ksbbi, megfelel idpontban trtnik meg. Kt kar-bantartsi procedra kztt kiemelten szksges a hibatr mkds.

A fldi alkalmazsra j plda az amerikai AT & T Bell szmtgpes vezrls s feldolgozs telefonhlzata, melyben a hibatrst az zeme-ls elvrt biztonsgossga s az risi anyagi vesztesgek elkerlse indo-kolja. (Itt mr 10 perc kiess is millird dollrokban mrhet krt jelent a szolgltatnak.) A telefonhlzat kiptse megkvetelte, hogy tvoli he-lyeken is legyenek teleptve szmtgpes kapcsolllomsok. Ezeket a vllalat emberei periodikusan ltogatjk vgig, s elvgzik a karbantartsi munkkat.

4. Magas szint rendelkezsre lls

A vltakoz mrtkben ignybe vett informatikai rendszerekre vonatkozik ez a kategria. Ilyenek az n. on-line tranzakci-feldolgozst vgz rend-




szerek (on-line transaction processing, OLTP), ahol a felhasznli megke-ress vletlenszer mdon rkezik tbb helyrl, s ezekre azonnali feldol-gozs, kiszolgls van megkvetelve. Ilyenek pldul a banki alkalmazsok.

Az OLTP-rendszerek ltalban nagykiterjeds orszgos hlzatban zemelnek, ezen bell tbb loklis hlzattal. Az zemels legtbbszr 24-rs munkarendben trtnik, de a felhasznls jellegbl addan md van az jszakai karbantarts idnknti elvgzsre is. Az ilyen rendszerek-nl nemcsak a kzponti szmtgp a hibatr, hanem a helyi hlzatok szerver gpei is. A felhasznli terminlok ltalban szemlyi szmtg-pek, amelyekre mr nincs elrva a hibatrs. Fontos azonban, hogy ezek is nagymegbzhatsg, kivl minsg gyrtmnyok legyenek.

A bankok mellett tovbbi elterjedt OLTP-alkalmazsok a kvetkezk:

Rendrsgi gyeleti bevetsirnyt rendszer, amely a bejelentsek feldolgozsn tl a rendri beavatkozsok nyilvntartst s szervez-st is vgzi. Ugyanilyen funkcij a mentk s tzoltk bevetsirny-tsa is.

Orszgos vagy nemzetkzi szlltssirnyts, amely a vasti, kamio-nos, vagy lgi ruszllts nyomon kvetsre, nyilvntartsra s op-timlis szervezsre szolgl.

3.3. Rendszerstruktrk A hibatrs megvalstsa mindenkppen elre betervezett redundancival kell hogy jrjon. Ennek az a magtl rtend oka van, hogy a hibatr infor-matikai rendszerre a norml funkcijn kvl a sajt hibs mkds felis-merse s az ilyenkor megvalstand feladatteljests is rhrul. A redun-dancia mind a hardverben, mind pedig a szoftverben rvnyre jut, mivel egyedl egyik f komponens sem kpes a msik hibjt felismerni s funk-cijt elltni. Termszetesen a szoftver s a hardver egymssal sszhang-ban zemel, amibe az is beletartozik, hogy a hibafelismersben s az ilyen-kor szksges reakcikban is kiegsztik, vagy tfedik egymst. A hibatr rendszerek felptse sok esetben olyan, hogy a hardver is hozzjrul a szoftver-hibk felismershez, s viszont, a szoftver is rszt vehet a hard-ver-hibk szlelsben.

A redundancia megvalstsra ngy terlet vlt alkalmass. Ezek a kvetkezk:




1. Hardver redundancia: A hibatrs elrse rdekben kiegszt hardver elemeket alkalmaznak, klnbz funkcikkal. A funkcik egyrszt a mkdshez kapcsold tesztelst (beptett ntesztelst), msrszt pedig egyes elemek ismtlst (tartalkknt) jelentik ltalban. A fejezet ksbbi rszben erre be fogunk mutatni nhny jellegzetes megoldst.

2. Szoftver redundancia: A hibatrs elrse rdekben kiegszt szoftverelemeket, ill. szoftverrel megvalstott mdszereket alkalmaz-nak. Itt is szmtsba kell vennnk a szoftvert az ntesztels megval-stsban, valamint az ismtld funkcik elltsban. Ezzel is bveb-ben foglalkozunk mg a fejezetben.

3. Informcis redundancia: A mkdsi biztonsg nvelse rdek-ben tbbletinformcit, tbbletbiteket hasznlnak fel. Ezltal a hibk detektlsra s/vagy tolerlsra kerlhet sor. Tipikus elterjedt meg-olds pldul a paritsbitek, hibadetektl kdok, hibajavt kdok, el-lenrz sszegek (check sum) hasznlata. A hibajavt kdok nemcsak detektlsra, hanem tolerlsra, vagyis a hiba elfedsre, hatsnak megszntetsre is alkalmasak. Az ilyen megoldsok az adattviteli fo-lyamatokban, tovbb a memrikban, ill. a kzponti feldolgoz egy-sgekben (CPU) terjedtek el leginkbb. Megvalstsuk egyarnt tr-tnhet hardver s szoftver ton.

4. Id redundancia: A szksgesnl hosszabb feldolgozsi id ignybe-vtele. A cl itt is a hibk detektlsa s/vagy tolerlsa. A legelterjed-tebb megolds a feldolgozs, a szmtsok ismtelt lefolytatsa, az eredmnyek sszehasonltsval egybektve. Ezzel elrhet az, hogy a hardverben fellp tmeneti hibt, amely az egyik vgrehajts alatt r-vnyeslt, egy jabb vgrehajtssal ki lehessen ejteni. Az idtbblet te-ht gy detektlst s korriglst is lehetv tesz. A megvalsts egy-arnt trtnhet hardverrel s szoftverrel is.

A gyakorlatban a fenti ngy elv kombincijt alkalmazzk. Igen sok eset-ben mind a ngy redundancit beptik a biztonsgkritikus rendszerekbe.

A kvetkezkben nhny fontosabb strukturlis s algoritmikus meg-oldst ismertetnk, amelyek a hibatrst szolgljk hardver s szoftver tren. A hardvert itt rendszertechnikai szempontbl mutatjuk be, s csak olyan mlysgben, amennyire ez a szoftver oldalrl fontos lehet.




3.4. A hardver redundancia megvalstsa A kvetkezkben hrom jellegzetes megoldst ismertetnk a hardver re-dundancia megvalstsra.

3.4.1. Prhuzamos duplikls A legrgebben alkalmazott s kzenfekv struktra ugyanazon hardver egysgnek a megkettzse s prhuzamos mkdtetse. Ekkor mindkt egysg ugyanazokat a bemen jeleket kapja, s helyes mkds esetn ugyanazokat az eredmnyeket is kell produklniuk. Az eredmnyek megfi-gyelsrl s sszevetsrl egy kln beiktatott sszehasonlt egysg gondoskodik. Egyezs esetn az egyik egysg jelei jutnak tovbb a feldol-gozsi folyamatban. Az egymstl eltr eredmny az egyik egysg hibs mkdst jelenti. Itt a hibt csak detektlni lehet, de elfedsre, tolerl-sra mr nincs md. Clszer intzkeds lehet ilyenkor a tovbbi mkds biztonsgot nem srt lelltsa.

A lert prhuzamos struktrt a 3.1. brn mutatjuk be. A dupliklt egysgek brmilyen bonyolultsg modulok lehetnek, ugyanakkor tetsz-leges szm egysgprost lehet egy rendszeren bell kialaktani. Pldul aritmetikai logikai egysget (ALU-t), vagy httrtrolkat, diszkegysget. A legmagasabb szint megolds az, amikor egy teljes szmtgp megkett-zse valsul meg.

1. modul

Bemenet sszehasonlt egysg

Kimenet

2. modul

3.1. bra. Prhuzamos duplikls

3.4.2. Tartalkelemes zemeltets Ebben a struktrban is kt azonos egysg vesz rszt, de csak az egyik, a norml egysg fejt ki zemszer mkdst, a msik tartalkknt szerepel (3.2. bra). Azt, hogy melyik egysg jelei jutnak a kimenetre, az tkapcsol modul intzi el, a hibadetektor modul parancsa alapjn. A hibadetektor rendelkezik azzal a kpessggel, hogy meg tudja llaptani a helyes-hibs mkdst az ltala ellenrztt modulrl. Ha a norml modul hibsnak




mutatkozik, akkor a tartalkmodul zemeltetsre kerl sor. Ha az is meg-hibsodna, a mkds felfggesztdik.

A tartalkmodult ktfle llapotban szoks hasznlni a norml zeme-ls folyamn. Az egyikben nincs bekapcsolva, vagyis nincs tpfeszltsg al helyezve (hideg tartalk), a msikban llandan be van kapcsolva, s mkdst fejt ki (meleg tartalk). A hideg tartalk alkalmazsra egyrszt energia-takarkossgbl, msrszt pedig az lettartam meghosszabbtsa rdekben kertenek sort.

Norml modul

Bemenet Kimenet

Tartalk modul

tkapcsol

egysg

Hibadetektl egysg

3.2. bra. Tartalkelemes zemeltets

3.4.3. Hrommodulos redundancia (TMR) Mint lthat volt, a hibatrs megvalstsra nem elegend kt egysg. A cl elrse legalbb hrom egysg beiktatst kvnja meg. Egy ilyen struk-trt tntet fel a 3.3. bra, az n. hrommodulos redundancit. (Angolul: Triple Modular Redundancy, TMR.) A TMR-struktrban a hrom megismtelt modul jelei egy n. szavazegysgre (voting unit, voter) jutnak, amely a tbbsgi szavazs elvn mkdik. Ez azt jelenti, hogy a kimenetre az a jel megy tovbb, amely legalbb kt modulnl azonos. Ha teht egy modul meghi-bsodik, akkor a msik kett azonosan helyes mkdse rvnyesl. A hibs modul hibja egyrszt detektldik, mivel az megllapthat, hogy melyik trt el a msik ketttl, msrszt pedig tolerldik is, mivel a hatsa nem jut rvnyre a teljes mkdsben.

Ha kt vagy hrom modul hibsodna meg, akkor vrhatlag hrom klnbz jel jutna a szavazra, amely ilyenkor deklarln a teljesen tves mkdst, aminek alapjn egy biztonsgra trekv lellts, vagy tartalk-egysg belptetse kvetkezhet.




1. modul

Bemenet

2. modul

3. modul

Szavaz egysg

Kimenet

(Tbbsgi szavazs) 3.3. bra. A TMR-rendszer felptse

Mindehhez mg az a felttelezs is jrul, hogy annak a valsznsge, hogy kt modul teljesen azonos mdon hibsodik meg egyidejleg, elhanyagol-hatan kicsi.

A vzolt szisztma egyetlen hibs modul tolerlsra alkalmas. Az el-trt hibs modulok szma gy nvelhet, hogy nveljk a prhuzamosan dolgoz modulok szmt, de mindig gy, hogy ez a szm pratlan legyen a tbbsgi szavazssal sszhangban. Knnyen belthat, hogy az eltrt hi-bs modulok szma N 3 esetn az

(N 1) / 2

kplettel hatrozhat meg. Ez a szm t modulnl kett, ht modulnl hrom. A modulok szmnak nvelse termszetesen nem jr arnyosan egyrtelm javulssal, mivel a meghibsodsok valsznsge is nvekszik, msrszt pedig gazdasgossgi korltok is jelentkeznek. A gyakorlatban alkalmazott informatikai rendszerek ismeretben megllapthatjuk, hogy a vilgon a TMR-konstrukci terjedt el s vlt be leginkbb.

rdekessgknt mg megemltend, hogy a tbbsgi szavazsos rend-szerek megbzhatsgi elmletvel elszr Neumann Jnos foglakozott behatbban, az Egyeslt llamokban, az 1950-es vekben. Akkoriban mg az volt a f gond, hogy kisebb megbzhatsg alkatrszekbl (relk, elektroncsvek) hogyan lehet olyan szmtgpet pteni, ami nagy meg-bzhatsggal ltja el a szmtsi feladatait.

3.5. A szoftver redundancia megvalstsa A hibatrs magas fokon val elrse megkveteli a szoftver-hibk elfed-st, ami plusz szoftvert ignyel, msrszt pedig, mint tudjuk, a hardver-hibkhoz is szksg van a tbblet-szoftver alkalmazsra.




A szoftver hibatrs kt cllal valsthat meg:

A szoftver sajt hibjnak elfedsre. A szoftver sajt s a hardver hibinak egyttes elfedsre. A msodik felttel magban foglalja az elst is, ezrt a kvetend megol-dsknt ezt rdemes vlasztani. A tovbbiakban csak ilyen megoldsokkal foglalkozunk.

Elszr vizsgljuk meg azt a struktrt, amelyben a hardver megkett-zse szerepel (3.4. bra). Tegyk fel, hogy mindkt csatornban ugyanaz a szoftver van teleptve, s a csatornk CPU-ja is megegyezik, vagyis

SW1 SW2, valamint CPU1 CPU2.

sszehasonlt

CPU2

SW1

CPU1

SW2

3.4. bra. Ktcsatorns szoftvermkds




Ebben a struktrban a szoftverben elfordul hibk detektlsra sem-milyen lehetsg nincsen, mivel mindkt csatorna hibsan is azonosan mkdik, s gy az sszehasonlt ezt helyes mkdsnek rzkeli. Hard-verhiba esetn a csatornk kztt eltrs fog mutatkozni, ami hibadetekt-lsra vezet.

Ha egy TMR-rendszerben alkalmazzuk ugyanezt az elrendezst, akkor sem vltozik a helyzet, az ismtld szoftver hibjt ilyenkor sem lehet szlelni. A megolds kulcsa abban ll, hogy elkerlend a teljesen azonos szoftverek alkalmazsa. Ezt gy valsthatjuk meg, hogy a klnbz csa-tornk szoftverje nem lesz azonos, viszont ugyanazt a mkdst vrjuk el az egyes vltozatoktl. Ezt az elvet szoftver diverzitsnak nevezzk.

A kvetkezkben kt olyan megoldst mutatunk be, amely a szoftver hibatrst szolglja a diverzitsi elv rvnyestsvel.

3.5.1. N-verzis programozs Az N-verzis programozsban a teljes szoftvert N db. pldnyban valst-jk meg, kt lehetsges megkzeltsben:

Ugyanazt a programozsi nyelvet alkalmazva, egymstl fggetlen, klnbz fejleszt csoportok, teamek.

Eltr programozsi nyelveket alkalmazva, egymstl fggetlen, k-lnbz fejleszt csoportok, teamek.

A fejleszt csoportok ugyanazt a specifikcit realizljk. Eltr nyelvek esetn az egymstl val fggetlensgk azt a clt szolglja, hogy nehogy ugyanazokat a hibkat kvessk el s vigyk bele a szoftverbe.

Az N-verzis rendszer mkdse a kvetkez: Az N program a szm-tgpes szervezstl fggen lefut, akr prhuzamosan, akr sorosan. Elbbi esetben N db. CPU vesz rszt a feldolgozsban, utbbi esetben csak egyetlen CPU. Az egyes programverzik ugyanazokat a bemen ada-tokat hasznljk, s a kimen adatok sszehasonltdnak. Az sszehason-ltst egy erre a clra elksztett program vgzi.

N = 2 esetn, ha prhuzamos feldolgozs trtnik, csak a hibadetekt-ls tnye derl ki. A hibs szoftver-komponensre, vagy a hibs hardverre nem kapunk informcit. Egymst kvet feldolgozsok esetn ugyanez a helyzet, azzal a klnbsggel, hogy a hardverben fellp esetleges tmeneti hiba detektlsra is sor kerlhet.




Ennl hatkonyabb megolds az N = 3, ahol md nylik a TMR-szisz-tma alkalmazsra, egy a szavazst megvalst programkomponens be-vonsval. Ez a szervezs lehetv teszi a hibs szoftver meghatrozst, s hibjnak eltrst is.

A szmtgpes implementci meglehetsen kltsges, hiszen ugyan-azt a szoftvert tbbszrsen kell kifejleszteni. A futtats szervezse is plusz fejlesztst kvn. Akr prhuzamos a feldolgozs, akr soros, a futsi eredmnyek eltrolsrl s sszehasonltsrl kln kell gondoskodni. Esetenknt ez igen komoly adatmennyisg kezelst teheti szksgess.

A magas ltrehozsi kltsgek korltoztk a mdszer elterjedst. Az egyik jellegzetes megvalsts az Egyeslt llomokban trtnt, ahol az AIRBUS A330/340 nagyteljestmny replgp fedlzeti irnyt sz-mtgpn hoztak ltre TMR-rendszer szoftvert.

3.5.2. A javt blokkok mdszere A szoftverhibk elfedsnek egy msik mdszere az n. javt blokkok (recovery blocks) alkalmazsa. Ebben a teljes szoftvert tbb modulra bontjk, s az egyes modulok tbbverzis megvalstsval, valamint a modulok ntesztelssel egybekttt jrafuttatsval rhetjk el a hibatrst. A vg-rehajts elve a kvetkez:

Egy-egy modul azonos funkcij verzii alkotnak egy blokkot. Mind-egyik blokkhoz tartozik egy n. elfogadsi teszt (acceptance test), ami egy kln program az esetleges hibs mkds detektlsra. A feldolgozsban a mo-dulok egyms utni futtatsra kerl sor, ahol minden futst az elfogadsi teszt vgrehajtsa kvet. Ha egy modulverzit elfogad a teszt, jabb verzi-ra nem kerl sor, a kvetkez blokk els verzijn lesz a sor. Ha egy mo-dulverzi hibsnak bizonyul a teszt alapjn, akkor a soron kvetkez tarta-lkmodul futtatsra kerl sor, a blokkon bell. Ha ez is hibs a teszt sze-rint, jabb modulra kerl sor stb., mindaddig, amg csak van futtathat modulverzi. A javts (felpls, recovery) elve akkor rvnyesl egy blokkban, ha egy hibs modult egy j modul futsa kvet. Ha egy blokkban mindegyik modulverzi hibsnak bizonyul, akkor a teljes futs vget r.

Egy j blokk futtatsa eltt mindig el kell menteni az addig elllt sz-szes adatot egy fggetlen trba. Ha hibt tall az ellenrzs, az j modul futtatsa ebbl az elmentett llapotbl kell hogy trtnjk.

Az elfogadsi tesztek megrsa igen komoly szellemi rfordtst ig-nyel. A programmodul s a mkdsi krnyezet alapos ismerete s tanul-




mnyozsa szksges hozz. Egzakt mdszerek nem llnak rendelkezsre. Nhny kvetend irnyelv lehet a kvetkez:

Annak ellenrzse, hogy egy kiszmtott rtk az elfogadhat normlis fizikai tartomnyba esik-e (pldul, hmrsklet vagy nyoms).

Nem trtnt 0-val val oszts. Nem trtnt cmtartomnyon kvli cmzs, a tmbdeklarcik figye-

lembevtelvel. Egy-egy fontos szmrtk meghatrozsa alternatv algoritmussal is

megtrtnik.

Vgezetl megemltjk mg, hogy a javt blokkok elve az elosztott szm-tgpes rendszerekben is alkalmazst nyert. Az ilyen rendszerekben tbb klnbz szmtgp (csompont) vesz rszt egy-egy feladat megolds-ban, az erforrsok sszehangolt, automatizlt elosztsval. Ilyen szerve-zsben elfordulhat az is, hogy egy modul ismtelt vgrehajtsra egy m-sik csomponton kerl sor, ha az elz csompont hibsnak bizonyult.

3.6. Az ELEKTRA tpus vezrlrendszer felptse s mkdse

A szoftver diverzitson alapul hibatrs egyik rdekes gyakorlati pldjt adja az ALCATEL-AUSTRIA AG. cg ltal tervezett s gyrtott szmt-gpes vastirnyt rendszer, melynek tpusneve ELEKTRA. Az ELEKT-RA egy n. biztostberendezs, amely vasti plyaudvarok forgalmnak irny-tsra szolgl. A felhasznlsbl addan ez is biztonsgkritikus rendszer, ktelezen elrt hibatrssel. A szmtgpes vezrlrendszer ktoldal informcis kapcsolatban ll az ltala felgyelt plyaudvarral, ahol az n. klstri berendezsek, a jelzlmpk, sorompk, vgnyvltk helyezkednek el. A bejv informci a vonatok, szerelvnyek mozgsra, helyzetre utal. A kimen informci a klstri berendezsek automatizlt vezrls-re szolgl. Mindezt a 3.5. bra szerinti felptsben is szemlltetjk.

Az ALCATEL-ELEKTRA megkettztt prhuzamos felpts rend-szer, amelyben a kt prhuzamos csatornhoz (A s B csatorna) egymstl eltr fejleszts szoftverek tartoznak. Az ELEKTRA felptst a 3.6. bra mutatja be.




Szmtgpes irnytrendszer

Hardver interfsz

Klstri berendezs: jelzlmpk, vltk

Vasti plyaudvar irnyt kzpontja

Plyaudvar

3.5. bra. Vasti irnytrendszer vzlata

1. Szmtgp-

rendszer

2. Szmtgp-

rendszer

Irnytott folyamat

Hardver interfsz

sszehasonlt

A B

Csatorna

Logikai csatorna

Csatorna

Biztonsgi csatorna

3.6. bra. Az ALCATEL-ELEKTRA rendszer felptse




Az A csatorna elnevezse: logikai csatorna. A B elnevezse: biztonsgi csator-na. Norml, hibamentes zemben a plyaudvar irnytst az A csatorna intzi. A kt csatorna szoftverei kztt lnyeges mkdsbeli klnbsg van, a kvetkezk szerint:

1. Az A csatorna szoftvere egy CHILL programozsi nyelven elksztett procedurlis vgrehajts program. (A CHILL magas szint program-nyelv, a telekommunikci terletn fejlesztett vals idej (real-time) rendszereknl terjedt el a felhasznlsa.) A bemen adatok a kls p-lyaudvari esemnyek, helyzetek, amiknek alapjn a program lefut, s en-nek eredmnyeknt kiadja a szksges vezrl jeleket a plyaudvar fel.

2. A B csatorna szoftvere nem procedurlis program, hanem egy nll szakrti rendszer. Elnevezse: SAFETY BAG (biztonsgi csomag). Lt-rehozsa a PAMELA nev fejleszti krnyezetben ment vgbe. A rendszer tudsbzisa szablyalap: tbb mint 800 szablyt tartalmaz. A szablyok PAMELA nyelven rdtak. (PAMELA: PAttern Matching Expert System LAnguage.) A SAFETY BAG egy-egy szablynak struktrja: Ha egy adott esemny vagy esemnylnc kvetkezett be, akkor egy elre definilt intzkedsre van szksg. Pldul:

IF track 27 is occupied AND signal 33 is free THEN set signal 33 to stop

Ennek rtelmezse: HA a 27-es vgny foglalt S a 33-as jelz szabad, AKKOR lltsd a 33-as jelzt llj-ra.

Amikor egy helyzetet elemez a szakrti rendszer, akkor azt vizsglja vgig, hogy az sszes szably kzl melyek azok, amelyeket figyelembe kell venni az adott helyzetben, ill. melyeket nem, s a szerint kell dntst hozni a plyaudvari teendket illeten.

A mkdsi folyamat a kvetkez:

Az A jel csatorna a forgalomirnyts bejv jeleit dolgozza fel logi-kailag, az adott helyzetet elemzi, kirtkeli, s a szksges vezrl jele-ket kldi ki.

A B csatorna a biztonsgi mkdst szolglja. A bejv jeleket elemzi, dntst hoz, majd megvizsglja az A csatorna dntst. Ha azt elfo-gadja, az A intzkedse kimegy. Ha nem fogadja el, akkor a kvetkez esetek lehetsgesek: 1. B veszi t az intzkedst. 2. B tilt jelet ad ki a forgalom korltozsra. 3. B lelltja a forgalmat.




A dntshozatalhoz mindkt csatorna a TMR-struktrt alkalmazza sajt magn bell, a biztonsg nvelse rdekben. Ez azt jelenti, hogy a szoft-ver is hromszorozva van a kt g CPU-ival egytt, mind az A-ban, mind a B-ben kln-kln. A csatornk kevsb kritikus helyein (a monitorok vezrlse, ill. a hardver interfsz vezrlse) mr csak megkettztt prhu-zamostst terveztek be.

A csatornk tbb ponton el vannak ltva ntesztel egysgekkel is. Az ezekhez elksztett tesztprogramok szintn a szoftver rszt kpezik. Az ntesztels a hardver hibk felfedsre irnyul. Hibadetektls esetn a hiba helye az ramkri krtya szintjig automatizltan behatroldik, s kijelzsre kerl. A mkdsi helyzettl fggen egyes krtyk zem kz-ben is kicserlhetk, msok cserje eltt a rendszert le kell lltani. Ekkor a krtyacsert kveten jraindtsra kerl sor.

Az A meghibsodsa esetn B intzkedik a forgalomirnytsrl, s vi-szont: ha B-ben lp fel hardver-hiba, akkor az A egyedl vgzi az irny-tst. Ez az ideiglenes llapot a krtyacsere vgrehajtsig ll fenn.

Az ELEKTRA szisztma hibalefedsi kpessgeit tekintve az albbi megllaptsokat tehetjk:

1. A prhuzamosan, valamint a TMR-ben szervezett mkdtets nem-csak az llandsult, hanem az tmeneti hardver-hibk felfedsre is al-kalmas. Ezeknek a hibknak a felfedshez mindkt csatorna szoftvere is hozzjrul.

2. A kt csatorna egymstl gykeresen eltr szoftvermegoldsa lnye-gesen nveli a biztonsgot, ahol a kt szoftvernek ugyanazt a feladatot kell elltnia, s az eredmnyeik mindig szembestve vannak egymssal. Ez a konstrukci egyrszt lehetv teszi a meglev szoftver-hibk de-tektlst, msrszt pedig azoknak a hibknak a detektlst is, ame-lyeket mg a tervezs sorn sem tudtak elre szmtsba venni. Ezen tlmenen, a diverzits megvalstsi mdjbl mg egy nagyon fon-tos kvetkezmny is szrmazik: Nevezetesen az, hogy ezltal olyan zemelsi veszlyek elkerlse is lehetv vlik, amelyekkel a tervezsi folyamatban nem kalkulltak.

A teljes hardver-szoftver komplexum hibadetektlsa s hibatrse a k-vetkez mdon elemezhet:

Jelljk az sszes, elvileg lehetsges, tervezsi s mkdsi hiba hal-mazt H-val. A H halmazt az albbi rszhalmazokra tudjuk felosztani (3.7. bra):




HE: Az elre felttelezett s detektlhat hardver-hibk halmaza, ame-lyek felfedsrl a tervezs sorn gondoskods trtnt (vagyis az ELEKTRA bizonythatan felfedi ezeket a hibkat).

HN: Olyan hibk, amelyek bekvetkezsvel nem kell szmolni, mert felismerskrl s elkerlskrl az ELEKTR-n kvl kln trtnt gondoskods. (Pldul: kbelezsi hibk.)

HI: A biztonsgra nem hat, irrelevns hibk kre. HU: Azon hibk kre, amelyekrl nincs semmilyen elzetes tudom-

sunk. Ide tartoznak azok a veszlyes forgalmi helyzetek is, amelyek ke-zelse a tervezs sorn nem volt kalkullva s megoldva.

HE

HU HI

HN H:

3.7. bra. A lehetsges hibk felosztsa

Mindezek utn rhat, hogy

H = HE HN HI HU. A teljes halmazban nem jelent gondot a bizonytottan lefedett, valamint a veszlyt nem okoz hibk kre. Biztonsgi okokbl egyedl a HU halmaz hibinak egy rsze a kritikus, ezek idzhetnek el balesetet. Vizsgljuk meg ezt a halmazt kzelebbrl.

Legyen azoknak a hibknak a halmaza HA, amelyeket nem ismernk, s amelyek megnyilvnulsa, jelentkezse az A csatorna mkdsnek a kvetkezmnye. Ugyangy, legyen azoknak a hibknak a halmaza HB, ame-




lyeket nem ismernk, s amelyek megnyilvnulsa, jelentkezse a B csa-torna mkdsnek a kvetkezmnye. A kt halmazt a 3.8. brn tntet-tk fel.

3.8. bra. A szoftverdiverzits eredmnye

Legyen tovbb azoknak a hibknak a halmaza HX, amelyeket nem isme-rnk, s hatsuk teljesen kvl esik az ELEKTRA mkdsi krn. Ezek utn felrhat a kvetkez sszefggs:

HU = HA HB HX. Az sszefggst a 3.9. bra illusztrlja.

3.9. bra. Az ismeretlen hibkat kpvisel halmazok

A HA s HB halmazok egymssal diszjunkt rszei olyan hibkat foglalnak magukban, amelyekre a kt csatorna eltren reagl, gy azok a hibk a csatornk kztti mkdsi sszehasonltsban detektldnak. Ezzel szemben nem ll fenn ugyanez a kt halmaz kzs rszre: Az ide tartoz

HA HB

HA HB HX




hibkra vagy egyformn reagl a kt csatorna, vagy pedig a B nem veszi szre, hogy az A helytelenl reaglt. Vgeredmnyben teht kimondhat, hogy azoknak az ismeretlen hibknak a HV halmaza, amelyek potencilis katasztrfaveszlyt jelentenek, a kvetkez sszefggssel rhat le:

HV = HA HB HX. A HV halmaz teht a biztonsgot veszlyeztet hibkat hordozza mag-ban. Annak az idelis tervezsi clnak az elrse, hogy ez a halmaz abszo-lt res legyen, lehetetlen. Mindazonltal arra kell trekedni, hogy HV mi-nl kisebb mrtk legyen. Ennek elrshez a tervezsi s fejlesztsi fo-lyamat szigor szablyainak betartsra, msrszt pedig az elkszlt rend-szer kln biztonsgi vizsglatra van szksg. Ezekkel a tmakrkkel az 5. fejezetben fogunk rszletesebben foglalkozni.

Szoftver-minsgbiztosts Szoftver-tesztelsi mdszerek



4. Szoftver-tesztelsi mdszerek

4.1. Tesztelsi alapfogalmak A kvetkezkben a szoftverek tesztelshez kapcsold legfontosabb fogalmakat s defincikat soroljuk fel.

Defincik

Bemeneti adat: Olyan szmtgpes adat, amely egy tetszleges szoftver mkdtetst vonja maga utn, felhasznli szinten. Kimeneti adat: Olyan szmtgpes adat, amely egy tetszleges szoftver mkdtetse sorn jelenik meg, a mkdtets eredmnyeknt, felhasznli szinten. Hibamodell: Azon szoftverhibk halmaza, amelyeknek a felfedsre ir-nyul a teszttervezs. Tesztels: A szoftver bemeneti adatokkal val sorozatos elltsa s a kimeneti vlaszadatok megfigyelse. Egy hiba tesztje: Bemeneti adatok olyan rendezett sorozata, melynek hatsra az adott hibt tartalmaz szoftver a legutols adatkombincira a helyestl eltr (hibs) kimeneti adatkombincival vlaszol. Ebben az esetben azt mondjuk, hogy a teszt kimutatja, felfedi vagy detektlja a hibt. Itt hasznlatban van mg az a kifejezs is, hogy a teszt lefedi az adott hibt. Detektlhat hiba: Egy hibrl akkor mondjuk, hogy detektlhat, ha legalbb egy tesztje ltezik. (Tervezsi redundancia folytn ltezhetnek olyan hibk, amelyek semmilyen krlmnyek kztt nem reztetik hatsukat a szoftver egsznek mkdsben. Az ilyen hibk nem detektlhatk a teszt defincija rtelmben.) Tesztkszlet: Tbb hiba tesztjeinek egyttese, halmaza. Tesztkszlet hibalefedse (fault coverage): Azon hibk szzalkos ar-nya az sszes felttelezett hibhoz kpest, amelyeket a tesztkszlet detek-tlni tud. Msknt megfogalmazva: Azon hibk szzalkos arnya az sszes felttelezett hibhoz kpest, amelyeknek van tesztjk a tesztkszletben. Az elrend cl a 100%-os lefedst produkl tesztkszlet ltrehozsa. Teljes tesztkszlet/teszthalmaz: Teszteknek olyan sszessge, amely a szoftver mindegyik elre felttelezett s detektlhat hibjnak tesztjt




magban foglalja. Az ilyen teszthalmazrl azt mondjuk, hogy teljes hibalefe-dst eredmnyez. A teljes teszthalmaz 100%-os hibalefeds. Teszttervezs: Az a tervezsi folyamat, amelyben egyms utn meghat-rozzuk az egyes elre felttelezett szoftverhibk tesztjt. Ennek sorn megtrtnik a bemeneti tesztek s az ezekre elvrt vlaszadatok meghat-rozsa az elre felttelezett hibahalmazra nzve. A szmtsok mindenkori clja egy olyan tesztsorozat ellltsa, amely kpes az sszes elre defini-lt hiba felfedsre, amikor az adott ltez szoftveren vgrehajtjuk a teszt-eljrst.

Megjegyzs: A mai informci-technolgia mr olyan bonyolult szoft-ver-rendszerek ellltst teszi lehetv (millis szmban tudnak utast-sokat tartalmazni), hogy a teljes hibalefeds elrse gyakorlatilag nem val-sthat meg. ltalban a 90%-on felli minl jobb lefeds a relis s elfo-gadhat cl.

Tesztszmts vagy determinisztikus tesztgenerls: Egy adott hiba tesztjnek szisztematikus szmtsokkal trtn meghatrozsa. Vletlenszer/random tesztgenerls: Bemen adatok sorozatnak vletlenszer kpzse a hibk tesztjeknt trtn felhasznlsra. (Angol-ban: random test generation.) Ilyenkor a bemeneti tesztadatokat egy adott tartomnyban hasznlt vletlenszm-genertorral lltjuk el.

4.2. Hibamodellek s rvnyessgi krk Hibamodellnek nevezzk azoknak az elre felttelezett hibknak a konkrt halmazt, amelyekre vonatkozan a teszttervezst vgre kvnjuk hajtani. Tbb fajta hibamodell ltezik a gyakorlatban. Egy hibamodell meghatro-zsakor a kvetkez fbb szempontokat rdemes tekintetbe kell venni:

A teszttervezs kivitelezhetsgi lehetsgei s a rfordtand kltsgek. Az adott fejlesztsi technolgihoz kapcsold hibajelensgek elzetes

ismerete. A tesztels vgrehajtshoz szksges hardver s szoftver eszkzk

ltal nyjtott szolgltatsok kre.




Megjegyzs: A publiklt gyakorlati tapasztalatok alapjn ltalban megl-lapthat, hogy a szoftver rendszerek fejlesztsi s ellltsi kltsgben a tesztelsi folyamatok megtervezsre s vgrehajtsra fordtand kltsg tbb mint 50%-ot tesz ki. A technolgik fejldsvel folyamatosan n-vekszik a rendszerek bonyolultsga s mrete, ami vgs soron a tesztklt-sgek arnynak nvekedst vonja maga utn. Mindebbl az kvetkezik, hogy folyamatosan szksg van jabb s hatkonyabb mdszerek, eszk-zk kidolgozsra mind a teszttervezs, mind pedig a tesztvgrehajts terletn.

A kvetkezkben a hasznlatban lev fontosabb hibamodelleket tekintjk t. Fontos megjegyezni, hogy a szoftver-hibk mindig jelen vannak a mk-ds sorn, a krds csak az, hogy milyen mdon nyilvnulnak meg.

Szoftver hibk

a) Szoftver specifikcis hibk A fejleszts kezdetekor megjelen hibk, amelyek a szoftver elre meg-adott, specifiklt mkdsi funkciiban nyilvnulnak meg, mgpedig oly mdon, hogy a szoftver valamilyen vonatkozsban nem teljesti a felhasz-nli kvetelmnyeket. A specifikcis hiba addhat: tves specifikci-bl, ellentmondsos specifikcibl, valamint hinyos specifikcibl.

b) Programozi hibk A szoftver tervezse s kdolsa sorn a programoz ltal elkvetett hibk krt foglalja magban. A lehetsges hibk az albbiak:

Hibs funkciteljests. Hinyz funkcik. Adatkezelsi hibk az adatbzisban. Indtsi (inicializlsi) s lelltsi hibk. Felhasznli interfsz hibi Hatrrtkek tllpse Kdolsi hiba Algoritmikus hiba Kalkulcis hibk Inicializlsi hiba Vezrlsi folyamat hibja




Adattovbbtsi hiba Versenyhelyzet programblokkok kztt Terhelsi hiba A kvetkez alpontokban a teszttervezs legfontosabb megkzeltsi mdjaival foglalkozunk. Ezekhez kapcsoldan olyan determinisztikus mdszereket mutatunk be, amelyek felhasznlsval a klnbz hibk tesztjeit tudjuk megkeresni.

4.3. A tesztek megtervezse Annak rdekben, hogy betekintst kapjunk a szmtgpes programok tesztelsi feladatnak sszetettsgbe, vegynk egy egyszer pldt. Te-gyk fel, hogy a kvetkez funkcit teljest programot kell ellenriznnk:

A program beolvas hrom egszszmot, amelyek egy hromszg olda-lainak hosszt kpviselik. A feladata annak meghatrozsa, hogy az gy elll hromszg szablytalan, egyenl szr, vagy pedig egyenl oldal.

Ha tesztelni akarjuk az elkszlt programot, akkor a kvetkez vizsg-latokat, teszteket vgezhetjk el rajta:

1. Hrom olyan szmot adunk meg, amelyek egy rvnyes hromszget tesznek ki.

2. Hrom olyan szmot adunk meg, amelyek egyenlk, vagyis egyenl oldal hromszget alkotnak.

3. Kt egyenl s egy ettl klnbz szmot adunk meg, melyek gy egyenl szr hromszget adnak.

4. Olyan szmokat adunk meg, amelyek kzl kettnek az sszege ki-sebb, mint a harmadik szm.

5. Olyan szmokat adunk meg, amelyek kzl kettnek az sszege egyen-l a harmadikkal.

6. Hrom 0-t adunk meg. 7. Olyan szmokat adunk meg, melyek kztt nem egsz szm is van. 8. A hrom szm kztt negatvat is magadunk.

Az rvnytelen bemeneti adatokra azrt volt szksg, hogy ellenrizzk, hogyan reagl rjuk a program. Ha elfogadn valamelyiket, akkor az prog-ramhiba lenne.

A fenti vizsglati esetek mg egyltaln nem elegendek arra, hogy mindegyik elvileg lehetsges hibt fel tudjk derteni. Ebbl is lthat, hogy egy ilyen egyszer program tesztelse sem knny feladat. Mindez




teht azt jelenti, hogy pldul egy tbbszzezer utastsbl ll szoftver megbzhat leellenrzse belthatatlan bonyolultsg feladat tud lenni.

Ami a tesztek megtervezsnek krdst illeti, erre vonatkozan kt alapvet megkzelts ltezik: a funkcionlis, valamint a strukturlis. Ezeknek a lnyegt a kvetkez kt alpontban rjuk le.

4.3.1. A funkcionlis tesztels alapelve Funkcionlis tesztelsrl beszlnk akkor, amikor a programot egyedl csak a kls viselkedsben, az elrt funkciinak teljestsben vizsgljuk azltal, hogy a bementi adatokra kapott kimeneti vlaszadatokat figyeljk meg, a futtathat trgykd felhasznlsval. Ebben a megkzeltsben egyltaln nem vesszk figyelembe a forrskdot, mg a program megrsi nyelvt sem, vagyis a programot olyan egysgnek tekintjk, amibe nem ltunk bele. Emiatt szoks mg ezt a megoldst fekete doboz vagy vasdoboz teszte-lsnek is nevezni (angolban black-box testing, iron-box testing).

A funkcionlis tesztelsben a szoftver minden egyes specifiklt funkci-jnak a sorra vtele s leellenrzse a cl, ezen kvl pedig mg az is, hogy nincs-e valamilyen tves, nem betervezett tevkenysge a program-nak.

4.3.2. A strukturlis tesztels alapelve Strukturlis tesztelsrl beszlnk akkor, amikor a szoftver forrskdjnak felhasznlsval a bels struktra, a bels mkds vgigkvetsre ir-nyul az ellenrzs. Ebben a megkzeltsben a tesztelsi adatok megterve-zse sorn az a cl, hogy a forrskd utastsainak s elgazsainak minl alaposabb vgigjrst tudjuk elrni. Itt a programot teht olyan egysgnek tekintjk, amibe beleltunk. Emiatt szoks mg a fehr doboz vagy vegdo-boz tesztels elnevezsek hasznlata is. (Angolul: white-box testing, glass-box testing.)

A strukturlis tesztelssel a program minden egyes utastsnak a vg-rehajtst, a dntsi elgazsok lehetsges vgrehajtsait, valamint a ciklu-sok vgrehajtst kell ellenrizni.

A kdbejrs trgyalst megknnyti az n. vezrlsi folyamatgrf (VFG) (angolul: control-flow graph, CFG) fogalmnak a bevezetse s felhasznlsa.

A vezrlsi folyamatgrf egy olyan irnytott grf, melyben minden egyes csompont megfelel egy programutastsnak. Az egymst soron kvet A s B utasts csompontjait gy kti ssze az irnytott l, hogy az A pont-jbl a B-jbe mutat. Egy dntsi utasts (pldul IF THEN ELSE, vagy CASE) csompontjbl annyi irnytott l indul ki, ahny fel trtnhet a




dntshozatal feltteles elgazsa. A felttel nlkli elgazst (GO TO) rep-rezentl pontbl kivezet irnytott l az elgazst kvet utasts pontj-hoz vezet. A ciklusutastsokat (pldul FOR DO, REPEAT WHILE) egy visszafel irnyul hurokl reprezentlja. Mint lthat, a VFG a programok vgrehajtsi menetnek az elvont brzolsra szolgl, a vgrehajts struktu-rlis vzt hordozza magban.

A grf egyes csompontjai kztt definiljuk az t fogalmt: Az Si s Sj utastsok kztti t P(Si, Sj), az egymst kvet csompontok

azon sorozata, amely Si-vel kezddik s Sj-vel r vget. Az Si s Sj kztt tbb lehetsges t ltezhet.

4.4. A programtesztels pszicholgija s gazdasgossga (Glenford Myers elvei)

Jllehet a tesztels tmakrt szmos technikai szempontbl trgyalhatjuk, gy tnik, hogy a legfontosabb szempontok a pszicholgihoz s a gazda-sgossghoz ktdnek. Ms szval, az olyan megfontolsok, mint a teszte-lshez val szellemi hozzlls, egy program teljes tesztelsnek kivitelez-hetsge, vagy ki legyen a tesztels elvgzje, jval tbbet szmt a vgre-hajts sikerben, mint a technikai megfontolsok. Ezekkel a krdsekkel Glenford Myers (USA) foglalkozott behatbban.

Elszr is, vizsgljuk meg a tesztels cljnak krdst. Szoksos meg-fogalmazsok a kvetkezk:

Annak bizonytsa, hogy nincsenek a programban hibk. Annak bizonytsa, hogy a program a neki sznt funkcikat helyesen hajtja vgre. Ezek a defincik helytelenek, mivel ppen az ellenkezjt rjk le annak, aminek a tesztelst tekintennk kellene. Egy program rtkt akkor tudjuk nvelni, ha javtjuk a minsgt s megbzhatsgt. A megbzhatsg nvelse azltal rhet el, hogy megkeressk s eltvoltjuk a hibkat. Ab-bl a feltevsbl kell teht kiindulnunk, hogy a program hibkat tartalmaz, s azrt teszteljk, hogy minl tbb hibt fedjnk fel benne. Eszerint:

A tesztels clja a program olyan vgrehajtsa, amelyben a szndkunk a hibk megtallsa.

Itt azonnal addik a krds, hogy md van-e arra, hogy az sszes hibt megtalljuk. A vlasz egyrtelmen negatv, mg az egyszerbb esetekre nzve is. Az ltalnos gyakorlatban nem rdemes, vagy ppensggel lehe-




tetlen mindegyik hibt kiszrni. Ez az alapvet problma kihatssal van a tesztels gazdasgossgra, a programra vonatkoz elzetes feltevsekre, s nem utols sorban a tesztek tervezsnek mdjra.

A funkcionlis megkzeltsben a programot fekete dobozknt kezel-jk, ahol nem ismerjk a bels viselkedst s struktrt. Ilyenkor a tesztel abban rdekelt, hogy a specifikcitl eltr mkdst fedezzen fel. Az ehhez szksges bemen adatokat teht a specifikci alapjn lehet elll-tani. Az sszes lehetsges hiba megtallsnak egy biztos mdja a kimert inputtesztels, vagyis az sszes lehetsges bemen adat felhasznlsa. A h-romszges programban pldul az sszes, a szmtgpen ltez egsz-szmot kellene a klnbz hrmas kombincikban megadni. Az ilyen esetek szma csillagszati. De mg ez sem lenne elg: pldul nem fedn fel azt a hibt, aminl a program a {2, A, 2} halmazbl egyenlszr h-romszget hozna ki.

A bonyolultabb programok kimert tesztelse mg inkbb lehetetlen. Egy Pascal fordtprogramnl pldul olyan teszteket kellene ksztennk, amelyben az sszes rvnytelen Pascal programot rjuk le, elvrva azt, hogy a kompjler mindegyiket rvnytelennek tudja nyilvntani. Ha vala-melyiket helyes programnak fogadn el, az mr hiba lenne. A problma mg slyos

Documents

SW Minosegbizt