Black box rendszer
A Miau Wiki wikiből
Magyar megnevezés: Fekete doboz rendszer
Tartalomjegyzék
Történeti modul
- Fekete doboz elmélet (Black Box Concept): Olyan rendszerelemzési eljárás, melynek során a rendszer belsõ felépítését figyelmen kívül hagyjuk (a rendszert fekete doboznak tekintjük), és kizárólag az inputok és az outputok közötti összefüggések alapján próbálunk következtetéseket levonni a rendszer mûködésével kapcsolatban.[1]
- 1972 A tudomány megismerésben, az ismeretelméletben, a rendszerelméletben alkalmazott eljárás. Segítségével egy ismeretlen felépítésű rendszer (az ún. fekete doboz, black box<ang.>) struktúráját, tartalmát úgy vizsgáljuk, hogy elemezzük az ún. bemenetre (input<ang.>) adott jelek reakciójaként az ún. kimeneteken (output<ang.> ) megjelenő válaszokat anélkül, hogy a „fekete dobozt” megbontanánk. A ~ részben eredményeivel (ismeretek) jelenik meg az oktatásban, részben alkalmazott módszerként. Az utóbbi fontos szerepet kap a különböző tanulmányi versenyeken, főként a term.-tud tantárgyak esetében.[2]
- 1997 Az első Black box ablak kezekő rendszer melyet az amerikai származású Bradley Hughes fejleszette ki abból kifolyólag hogy egy ablak kezelő renszert hozzon létre a Xinerama-ra. A Fekete doboz egy gyors és könnyen kezelhető Ablak kezeleő rendszer a Linux alapú X WINDOW rendszerben a ún felesleges könyvtári tartozékok nélkül. Ez a rendszer C++ nyelven irodott és eredeti kódokat tartalmaz(habár a grafikai felület kivitelezése hasonlit az alap Ablak kezelőkéhez)[3]
- 2004 Az automatizált tesztelés két dolgot foglal magában. Az egyik az automatizált teszteset generálás, másik pedig az automatizált tesztvégrehajtás. Az automatizált teszteset generálás általában strukturális (white-box) tesztek készítésénél működik, az alkalmazott technika általában szimbolikus végrehajtáson alapul. Amennyiben a szoftver specifikálására valamilyen formális keretben került sor, úgy ebből szintén lehetséges automatizált teszteset származtatás (black-box tesztelés). Tesztesetek létrehozását segítő eljárások lehetnek pl. teszt templatek használata ill. teszt "factory" osztályok használata objektum orientált rendszerek tesztelésénél. Az automatizált tesztvégrehajtás lehetővé teszi, hogy a teszt konfiguráció manager vezérelje a tesztek végrehajtását, a tesztek megismételhetők legyenek (regressziós tesztelés), ill. nagy mennyiségı tesztet lehessen végrehajtani. Az alkalmazott megoldások miatt szét kell választani a parancssor interfészı és a grafikus felhasználói felületı szoftverek automatizált tesztelését. Az első esetben a tesztadatok és eredmények egyszerı be- kivitel átirányításával adat alapú tesztelést végezhetünk (egyszerı test driver). Grafikus interfészek teszteléséhez léteznek makró rögzítő rendszerek, de ezek csak korlátozottan használhatók. Hatékonyabb automatizálást tesz lehetővé az adat alapú architektúra vagyis a tesztesetek szemantikus adatainak függetlenítése a konkrét felhasználói felületre vonatkozó adatoktól. Használható megoldás még keretrendszer alapú architektúra alkalmazása. Ilyenkor egy magas szintı tesztdefiniáló környezetet hoznak létre, melynek primitívjeit a grafikus felületen végrehajtható műveletek jelentik. Mindkét módszer a tesztek karbantartását, újra hasznosítását könnyíti meg.[4]
- 2004 A célok és a modelltípusok tekintetében két nagy áramlatot lehet elkülöníteni:
- a magyarázó (white-box) és
- az elõrejelzõ (black-box) modelleket.
- cél:
- összefüggések magyarázata (szerkezeti modell, white box)
- rendszerviselkedés elõrejelzése (magatartásmodell, black-box)
- követelmény
- szerkezeti egybeesés a valósággal(szerkezeti modell, white box)
- a valósággal megegyezõ viselkedés biztosítása (magatartásmodell, black-box)
- A adott pontosságú elõrejelzés több, szerkezetileg egymástól eltérõ modellel is elérhetõk. Ebbõl következõen minden szerkezeti modell egyben elõrejelzõ modell is, míg fordítva nem. Visszagondolva azonban a második fejezetben a "zár és kulcsai" problémára az is kijelenthetõ, hogy szerkezeti modell, mint olyan nem létezik, hiszen csak a tapasztalat útján való egyezõség vizsgálható, ami nem más, mint az elõrejelzõ modellek követelménye. Ennek kapcsán érdekes az a tény is, hogy az úgy nevezett szerkezeti modellek elõrejelzési pontossága ritkán éri csak el a magatartásmodellek (elõrejelzõ modellek) szintjét. Másként fogalmazva: ellentmondáshoz vezet az a kijelentés, mely szerint, az úgy nevezett parametrizált szerkezeti modellek, melyek általában ok-okozatilag igazak tûnnek, egy konkrét objektumra a paraméterek változtatásával adaptálhatók. Az adaptáció során ugyanis a lehetséges paraméterkombinációk sokasága vezethet azonos pontossági szintre, nem beszélve a majdhogynem tetszõleges pontossági szintek okozta problémáról. Így nem dönthetõ el soha, hogy melyik konkrét modell (paraméter-kiosztás) a legjobb. Vagyis addig amíg a legjobb modellnek ill. a modellek rangsorának nincs egzakt definíciója a szerkezeti modellek az alkalmazás szintjén kényszerûen elõrejelzõ modellekké válnak.
Ontológiai modul
"ez egy" kapcsolattípus
- Blackboxwiki (felhasználói segítség)
- Generátormodell (fajta)
- Data mining software (alkalmazó rendszer).....
"van neki, része a szócikknek" kapcsolattípus
- Paraméter
- Tesztelés
- Tesztadatok
- Input (bemeneti jel)
- Output (kimeneti jel)
"a szócikk része valaminek (a szócikkel egyenrangú fogalmak)" kapcsolattípus
- Szimuláció (leíró-magyarázó szimuláció (vö. black box vs. white box modellek,statikus-dinamikus szimuláció (az időtényező kezelésétől függően), determinisztikus-sztohasztikus szimuláció)
- Modellezés (Black box, white box, Dinamikus és zárt rendszerek, Komplexitás, Gondolatkísérlet, Célzatosság,Bonyolultság)
- ...
Ellentmondások és vitatott kijelentések modulja
* Ellentmondást nem találtam, ugyanis a források több jenetést adtak meg a black box rendszerrel kapcsolatban, igy mivel több "értelmezése" van az informatikában, ezért nem lehet őket összehasonlítani.
Szerkesztői javaslat A miau-dokumentumok világosan jelzik a black box és white box modellek antagonizmusait...
Válasz a szerkeztői javaslatra
- Black-box vs. White-box
- Eredeti (angol verzió)
- Further experience of the available (black-box) data-mining software is, that the result always depends on the capability of parametrisation. Therefore it can not be sure, that a “universal” software from the market is able to compete with an own (not market based or white box) “not universal” but rather aim and result oriented solution. This was proved by a comprehensive test, where 2 commercial black-box software and 1 white box solution (WAM =Weight and Activity Model - spreadsheet based) were compared on the same database and the results mostly showed the advantage of the white box solution. It is important to outline, that commercial software can not handle any goal function....
- ....White box solutions can be interpreted as a neural network or an inductive expert-system. In the case of inductive expert-systems it can be necessary to interpret the final rule system into a verbal way or text based (to expertise). This conversion can be made with the WAM-TXT system.
- Az angol verzió tömörítése magyarul
- Néhány tesztet hajtottak végre black box alapú adatbányászó softwarrel kapcsolatban ami az mutatta ki hogy az eredmény mindig a mérhető adottságoktól függ. Igy nem biztos hogy egy piacon megtalálható rendzer ugyanazt az eredményt tudja nyújtani mint egy nem piaci alapu de kérdés és eredmény orientált software (lsd white box). A testett 2 black box alapú és 1 white box alpú megoldáson (WAM) végezték el. A végeredmény miutatta hogy hasonló rendszereknél az eredmény a white box nál sokkal kedvezőbbek voltak és előnyösebbek. Ehhez még hozzá kell tenni hogy a kereskedelmi software semmilyen használato eredményt nem tudott fel mutattni...
- ... A white box rendszer alkalmazhatjuk akár egy induktiv szakértő rendszernél vagy neurális hálónál. A induktiv szakértő rendszernél azért hogy értelmezhető eredményt kapjuk ezért az eredményt vagy következettést vagy verbális úton vagy irott formában kell lenni. Ehhez a megjuelenítéshez alkalmazhatjuk a WAM_TXT rendszert.[6]
- OGIL összehasonlítás
- Mivel a white box (szerkezeti modell), mint olyan, önmagában nem létezik, hiszen a valósággal való szerkezeti egybeesést csakis a tapasztalat igazolhatja, az pedig, hogy a modell viselkedése megegyezzen a valóságos folyamatokkal, a black box követelménye, ezért a black és white box modellek különbségére rávilágító példát nehezen lehet meghatározni, hiszen általában együttesen alkalmazzák. De talán példa lehetne egy számítógépes szoftver modellezése. Black box esetén csak az inputokat kell ismerni, és azokat az outputokat, amelyeket elérni szeretnénk, de az, hogy a program ezt hogyan valósítja meg, mellékes (nem ismert). White box esetén azonban feltétlenül ismerni kell a cél megvalósításához szükséges algoritmust.
- Míg a black box olyan problémamegoldási modell, aminek szerkezetét egyáltalán nem, vagy csak részben nem ismerjük, a bemenet és a kimenet között fennálló kapcsolatot pedig csak matematikai módszerekkel írhatjuk le, addig a white box szerkezete ismert, vagyis a modell futtatásához szükséges adatokat képesek vagyunk a terepről begyűjteni.
- Az automatizált tesztelés két dolgot foglal magában.
- Az egyik az automatizált teszteset generálás, másik pedig az automatizált tesztvégrehajtás. Az automatizált teszteset generálás általában strukturális (white-box) tesztek készítésénél működik, az alkalmazott technika általában szimbolikus végrehajtáson alapul. Amennyiben a szoftver specifikálására valamilyen formális keretben került sor, úgy ebből szintén lehetséges automatizált teszteset származtatás (black-box tesztelés). Tesztesetek létrehozását segítő eljárások lehetnek pl. teszt templatek használata ill. teszt "factory" osztályok használata objektum orientált rendszerek tesztelésénél. Az automatizált tesztvégrehajtás lehetővé teszi, hogy a teszt konfiguráció manager vezérelje a tesztek végrehajtását, a tesztek megismételhetők legyenek (regressziós tesztelés), ill. nagy mennyiségı tesztet lehessen végrehajtani. Az alkalmazott megoldások miatt szét kell választani a parancssor interfészı és a grafikus felhasználói felületı szoftverek automatizált tesztelését. Az első esetben a tesztadatok és eredmények egyszerı be- kivitel átirányításával adat alapú tesztelést végezhetünk (egyszerı test driver). Grafikus interfészek teszteléséhez léteznek makró rögzítő rendszerek, de ezek csak korlátozottan használhatók. Hatékonyabb automatizálást tesz lehetővé az adat alapú architektúra vagyis a tesztesetek szemantikus adatainak függetlenítése a konkrét felhasználói felületre vonatkozó adatoktól. Használható megoldás még keretrendszer alapú architektúra alkalmazása. Ilyenkor egy magas szintı tesztdefiniáló környezetet hoznak létre, melynek primitívjeit a grafikus felületen végrehajtható műveletek jelentik. Mindkét módszer a tesztek karbantartását, újra hasznosítását könnyíti meg.[7]
- A célok és a modelltípusok tekintetében két nagy áramlatot lehet elkülöníteni:
- a magyarázó (white-box) és
- az elõrejelzõ (black-box) modelleket.
- cél:
- összefüggések magyarázata (szerkezeti modell, white box)
- rendszerviselkedés elõrejelzése (magatartásmodell, black-box)
- követelmény
- szerkezeti egybeesés a valósággal(szerkezeti modell, white box)
- a valósággal megegyezõ viselkedés biztosítása (magatartásmodell, black-box)
- A adott pontosságú elõrejelzés több, szerkezetileg egymástól eltérõ modellel is elérhetõk. Ebbõl következõen minden szerkezeti modell egyben elõrejelzõ modell is, míg fordítva nem. Visszagondolva azonban a második fejezetben a "zár és kulcsai" problémára az is kijelenthetõ, hogy szerkezeti modell, mint olyan nem létezik, hiszen csak a tapasztalat útján való egyezõség vizsgálható, ami nem más, mint az elõrejelzõ modellek követelménye. Ennek kapcsán érdekes az a tény is, hogy az úgy nevezett szerkezeti modellek elõrejelzési pontossága ritkán éri csak el a magatartásmodellek (elõrejelzõ modellek) szintjét. Másként fogalmazva: ellentmondáshoz vezet az a kijelentés, mely szerint, az úgy nevezett parametrizált szerkezeti modellek, melyek általában ok-okozatilag igazak tûnnek, egy konkrét objektumra a paraméterek változtatásával adaptálhatók. Az adaptáció során ugyanis a lehetséges paraméterkombinációk sokasága vezethet azonos pontossági szintre, nem beszélve a majdhogynem tetszõleges pontossági szintek okozta problémáról. Így nem dönthetõ el soha, hogy melyik konkrét modell (paraméter-kiosztás) a legjobb. Vagyis addig amíg a legjobb modellnek ill. a modellek rangsorának nincs egzakt definíciója a szerkezeti modellek az alkalmazás szintjén kényszerûen elõrejelzõ modellekké válnak.
Definíciós modul
- A Black box rendszer tulajdonképpen egy adatfeldolgozó rendszer, melynél az adatokat viszünk be (input), és elemezzük a rendszer által kibocsájtott jeleket, majd ezt követően a kimeneten érkező(output)válaszokat is. És a két jel közötti azonosságot vizsgáljuk meg úgy, hogy magát a rendszert nem bontjuk fel.
- A másik megfogalmzás szerint, ez egy ablakkezelő rendszer, mely Linux operánciós rendszer alatt fut és a lényege, hogy a háttér és más egyéb kezelői felületek színe fekete.
Black box menü grafikai felülete
Tesztkérdések modul
- Igaz, hogy a Black box-nak több értelmezése van?
(Igaz, hisz jelenthet adatfeldolgozó rendszert, Linuxos ablakkezelő rendszert, és egy hardver elemet, mely működésének lényege, hogy a benne tárolt adatok csak kiolvashatók, s nem megváltoztathatók.
- Igaz-e, hogy a black box folyamatait csak tapasztalati úton (próbálkozással) ismerhetjük meg?
(Igaz, mivel a működési algoritmus ismeretlen.)
- Igaz-e, higy a vizsgált rendszer belső szerkezetére nézve a fekete dodoz módszer pontos tájékoztatást nem ad.
(Hamis, mert nem tudjuk hogy a bemeneteli jelen milyen folyamatok mentek végig ezért is a neve hogy black box'nem látni mi történik'
- Igaz-e, hogy a black box modell abban különbözik a white box modelltől, hogy a szerkezetét leíró adatok a valós életből nem állnak a rendelkezésünkre, szerkezetére csakis matematikai módszerekkel következtethetünk?
(Igaz)
