Absztrakció (számítástechnika)

„Az absztrakció lényege az adott kontextusban releváns információk megőrzése, valamint az ebben az összefüggésben irreleváns információk elfelejtése.” John V. Guttag

A szoftverfejlesztésben és a számítástechnikában az absztrakció:

A fizikai, térbeli vagy időbeli részletek^[1] vagy attribútumok eltávolításának vagy általánosításának folyamata az objektumok vagy rendszerek tanulmányozása során. Célja, hogy a figyelmet a nagyobb jelentőségű részletekre irányítsa;^[2] hasonló az általánosítás folyamatához;
Absztrakt fogalmak létrehozása – tárgyak, különféle nem absztrakt objektumok vagy vizsgálati rendszerek közös jellemzőinek vagy attribútumainak tükrözésével^[2] – az absztrakciós folyamat eredménye.

Az absztrakció a számítástechnika és a szoftverfejlesztés alapvető fogalma.^[3] Az absztrakciós folyamatot modellezésnek is nevezzük, továbbá szorosan kapcsolódik az elmélet és a tervezés fogalmaihoz is.^[4] A modellek - a valóság aspektusainak általánosítása alapján - az absztrakciók típusainak is tekinthetők.

A számítástechnikabeli absztrakció fogalma szorosan kapcsolódik a matematikai absztrakcióhoz, mivel az absztrakciókat objektumként építi fel. Azonban az absztrakció kapcsolódhat más területeken használt fogalmakhoz is (pl. művészetben).

Az absztrakciók vonatkozhatnak valóságos objektumokra és rendszerekre, számítási rendszerek szabályaira vagy olyan programozási nyelvek szabályaira, amelyek magának az absztrakciónak a jellemzőit hordozzák vagy használják. Például:

adattípusok használata adatabsztrakció létrehozására, annak érdekében, hogy a programokon belüli adatstruktúrák működését elkülönítse azok reprezentációitól;^[5]
eljárások, funkciók vagy alprogramok koncepciója, amelyek a vezérlési folyamatbeli programokban (control flow) való megvalósításának sajátos módját képviselik;
az "absztrakciónak" nevezett szabályok, amelyek a kifejezéseket szabad és kötött változók használatával általánosítják a lambda-számítás különböző változataiban;^[6]^[7]
az S-kifejezések használata adatstruktúrák és programok absztrakciójaként a Lisp programozási nyelvben;^[8]
a közös viselkedés átszervezése a nem absztrakt osztályokból "absztrakt osztályokká" az öröklődés segítségével (alosztályok feletti elvonatkoztatással), ahogy az például az objektumorientált C++ és Java programozási nyelvekben is látható.

Alapok

Belátható, hogy a számítástechnika többnyire a fizikai világtól függetlenül működik. A hardver olyan számítási modellt implementál, mely felcserélhető másokkal,^[9] ezzel szemben a szoftver olyan architektúrákra épül, melyek lehetővé teszik az emberek számára, hogy hatalmas rendszereket hozzanak létre úgy, hogy egyszerre csak néhány problémára összpontosítanak a megvalósítás folyamán. Ezek az architektúrák az absztrakciók meghatározott választásaiból állnak. Greenspun tizedik szabálya egy aforizma arról, hogy egy ilyen architektúra egyszerre elkerülhetetlen és összetett.

Az absztrakció központi formája a számítástechnikában a nyelvi absztrakció: új mesterséges nyelveket fejlesztenek ki a rendszer meghatározott aspektusainak kifejezésére. Például, a modellező nyelvek segítenek a tervezésben, míg a számítógépes nyelvek számítógéppel feldolgozhatók. Jó reprezentációja ennek az absztrakciós folyamatnak a programozási nyelvek generációs fejlesztése, mely a kezdetben gépi nyelv volt, ez lett fejlsztve assembly nyelvre, majd kesőbb magas szintű nyelvre. Mindegyik szakasz ugródeszkaként használható a következő szakaszhoz. A nyelvi absztrakció folytatódik például a szkriptnyelvekben és a tartományspecifikus programozási nyelvekben.

Egy programozási nyelven belül egyes funkciók lehetővé teszik a programozó számára, hogy újabb és újabb absztrakciókat hozzon létre. Ilyenek például az alprogramok, modulok, polimorfizmus és szoftverkomponensek. Néhány más absztrakció, például a szoftvertervezési minták, láthatatlanok maradnak a szoftverfejlesztő környezet fordítója számára, és csak a rendszer megtervezésében segítenek.

Egyes absztrakciók megpróbálják korlátozni azon fogalmak körét, amelyekkel a programozónak tisztában kell lennie azáltal, hogy elrejti azokat az absztrakciókat, amelyekre építkezik. Joel Spolsky szoftvermérnök és író bírálta ezeket az erőfeszítéseket, és azt állítja, hogy minden absztrakció kiszivárog – azaz, hogy soha nem tudják teljesen elrejteni a részleteket;^[10] ez azonban nem tagadja az absztrakció hasznosságát.

Egyes absztrakciók úgy lettek megtervezve, hogy együttműködjenek más absztrakciókkal – például egy programozási nyelv tartalmazhat idegen függvényinterfészt az alacsonyabb szintű nyelv hívásaihoz.

Absztrakciós jellemzők

Programozási nyelvek

A különböző programozási nyelvek különböző típusú absztrakciót biztosítanak, attól függően, hogy a nyelvnek milyen alkalmazási területe van. Például:

Az olyan objektumorientált programozási nyelvekben, mint a C++, Object Pascal vagy Java, az absztrakció fogalma maga is deklaratív utasítássá vált a szintaktikai function (parameters) = 0; (C++ nyelven) vagy az abstract^[11] és interface^[12] (Java nyelven) kulcsszavak használatával. Egy ilyen deklaráció után a programozó feladata, hogy megvalósítson egy osztályt a deklaráció objektumának példányosítására.
A funkcionális programozási nyelvek gyakran mutatnak függvényekkel kapcsolatos absztrakciókat, például lambda-absztrakciókat (egy kifejezést valamely változó függvényévé alakítanak) és magasabb rendű függvényeket (a paraméterek függvények).
A Lisp programozási nyelvcsalád modern tagjai, mint például a Clojure, a Scheme és a Common Lisp támogatják a makrórendszereket, hogy lehetővé tegyék a szintaktikai absztrakciót. Más programozási nyelvek, például a Scala is tartalmaznak makrókat vagy nagyon hasonló metaprogramozási funkciókat (például a Haskell rendelkezik a Haskell sablonnal, az OCaml pedig a MetaOCaml-lel). Ezek lehetővé teszik a programozó számára, hogy kiküszöbölje a sablonkódot, elvonja az unalmas és ismétlődő függvényhívási szekvenciákat, új vezérlőfolyam-struktúrákat építsen be, és implementálja a tartományspecifikus nyelveket (DSL), amelyek lehetővé teszik a tartományspecifikus fogalmak tömör és elegáns kifejezését. Mindezek helyes használat esetén javítják a programozó hatékonyságát és a kód egyértelműségét azáltal, hogy egyértelműbbé teszik a tervezett célt. A szintaktikai absztrakció következménye az is, hogy bármely Lisp dialektus és tulajdonképpen szinte bármilyen programozási nyelv elvileg bármely modern Lispben megvalósítható, jelentősen csökkentett (de a legtöbb esetben még mindig nem triviális) erőfeszítéssel a "hagyományosabb" programozási nyelvekhez képest, mint amilyen például a Python, a C vagy a Java.

Specifikációs módszerek

Az elemzők különféle módszereket fejlesztettek ki a szoftverrendszerek formális meghatározására. Néhány ismert módszer a következőket tartalmazza:

Absztrakt modell alapú módszer (VDM, Z);
Algebrai technikák (Larch, CLEAR, OBJ, ACT ONE, CASL);
Folyamat alapú technikák (LOTOS, SDL, Estelle);
Nyomkövetési technikák (SPECIAL, TAM);
Tudásalapú technikák (Refine, Gist).

Specifikációs nyelvek

A specifikációs nyelvek általában valamilyen típusú absztrakciókra támaszkodnak, mivel a specifikációkat általában korábban határozzák meg a projektben (és egy elvontabb szinten), mint egy esetleges megvalósítást. Az UML specifikációs nyelv például lehetővé teszi absztrakt osztályok meghatározását, amelyek egy "vízesés projektben" továbbra is absztraktak maradnak a projekt architektúra és specifikációs szakaszában.

Az absztrakció szabályozása

A programozási nyelvek absztrakció-szabályozást kínálnak, mint egyik fő felhasználási módjuk. A számítógépek nagyon alacsony szinten megértik a műveleteket, például néhány bitet a memória egyik helyéről egy másik helyre mozgatnak, és két bitsorozat összegét állítják elő. A programozási nyelvek ezt magasabb szinten teszik lehetővé. Vegyük például ezt az állítást Pascal -szerű módon írva:

a := (1 + 2) * 5

Egy ember számára ez meglehetősen egyszerű és kézenfekvő számításnak tűnik ("egy plusz kettő egyenlő hárommal, ezt megszorozva öttel azt kapjuk végeredményül, hogy tizenöt"). Azonban az alacsony szintű lépések, melyek szükségesek ahhoz, hogy elvégezzük a műveletet és visszakapjuk a 15-öt, mint az "a" változó értéke, valójában komplexek és kifinomultak. Az értékeket bináris számrendszerbe kell konvertálni (gyakran sokkal bonyolultabb feladat, mint gondolná az ember), és a számításokat (a fordító vagy az értelmező által) összeállítási utasításokká kell lebontani (ezek sokkal kevésbé intuitívak a programozó számára: az olyan műveletek, mint pl. egy bináris regiszter balra tolása, vagy az egyik regiszter tartalmának bináris komplementerének összeadása egy másik regiszter tartalmával, egyáltalán nem azonos azokkal az aritmetikai műveletekkel, amikre az ember gondol az "összeadás" vagy "szorzás" szó hallatán). Végül, a kapott „15” értéket hozzárendeljük az „a” jelzésű változóhoz, hogy az „a” később felhasználható legyen. Ez további „színfalak mögötti” lépésekkel jár, amelyek során meg kell keresni a változó címkéjét és az eredő helyet a fizikai környezetben, vagy a virtuális memóriában.

Vezérlési absztrakció nélkül a programozónak meg kellene adnia az összes regiszter/bináris szintű lépést minden alkalommal, amikor egyszerűen össze akarna adni vagy megszorozni néhány számot, és az eredményt egy változóhoz rendelni. Az erőfeszítések ilyen duplikálása két súlyos negatív következménnyel jár:

Arra kényszeríti a programozót, hogy mindig ismételje meg a meglehetősen gyakori feladatokat, valahányszor hasonló műveletre van szükség.
Arra kényszeríti a programozót, hogy az adott hardverhez és utasításkészlethez programozzon.

Strukturált programozás

A strukturált programozás magában foglalja az összetett programfeladatok kisebb, kevésbé összetett darabokra bontását egyértelmű áramlásszabályozással és a komponensek közötti interfészekkel.

Egy egyszerű programban ennek a célja lehet annak biztosítása, hogy a ciklusok egyetlen, vagy nyilvánvaló kilépési ponttal rendelkezzenek a függvényekből és eljárásokból.

Nagyobb rendszerben ez magában foglalhatja az összetett feladatok sok különböző modulra történő felosztását. Vegyünk egy olyan rendszert, amely kezeli a bérszámfejtést a hajókon és a parti irodákban:

A legfelső szint tartalmazhat egy tipikus végfelhasználói műveleteket tartalmazó menüt.
Ezen belül lehetnek önálló végrehajtható fájlok vagy könyvtárak olyan feladatokhoz, mint az alkalmazottak be- és kijelentkezése vagy a csekk nyomtatása.
Ezen önálló összetevők mindegyikén belül sok különböző forrásfájl lehet, amelyek mindegyike tartalmazza a probléma egy részének kezeléséhez szükséges programkódot, és csak kiválasztott interfészek érhetők el a program többi része számára. Egy bejelentkezési programnak lehetnek forrásfájljai minden adatbeviteli képernyőhöz és az adatbázis-felülethez (amely maga lehet egy önálló, harmadik féltől származó könyvtár vagy egy statikusan összekapcsolt könyvtárrutinkészlet).
Akár az adatbázisnak, akár a bérszámfejtő alkalmazásnak kell elindítania a hajó és a part közötti adatcsere folyamatát, és ez az adatátviteli feladat gyakran sok egyéb összetevőt is tartalmaz.

Ezek a rétegek azt a hatást váltják ki, hogy az egyik komponens megvalósítási részleteit és a különféle belső módszereket elszigetelik a többitől. Az objektumorientált programozás átfogja és kiterjeszti ezt a koncepciót.

Adatabsztrakció

Az adatabsztrakció egyértelmű elválasztást tesz lehetővé egy adattípus absztrakt tulajdonságai, és megvalósításának konkrét részletei között. Az absztrakt tulajdonságok azok, amelyek láthatók az adattípust használó klienskód számára – az adattípus interfésze –, miközben a konkrét megvalósítás teljesen privát marad, és valóban változhatnak, például az idő múlásával a hatékonyság javítása érdekében. Az ötlet az, hogy az ilyen változtatásoknak nem kellene semmilyen hatást gyakorolniuk a kliens kódjára, mivel nem járnak különbséggel az absztrakt viselkedésben.

Például, definiálhat egy absztrakt adattípust, az úgynevezett keresőtáblát, amely egyedileg társítja a kulcsokat az értékekhez, és amelyben az értékek lekérhetők a megfelelő kulcsok megadásával. Egy ilyen keresési tábla többféleképpen megvalósítható: hash táblaként, bináris keresési faként vagy akár egyszerű lineáris listaként (kulcs:érték). Ami a kliens kódot illeti, a típus absztrakt tulajdonságai minden esetben megegyeznek.

Természetesen minden azon múlik, hogy mindenekelőtt az interfész részleteit helyesen találjuk meg, mivel az ottani változások jelentős hatással lehetnek a kliens kódjára. Ennek egyik módja az, hogy az interfész szerződést köt az adattípus és a kliens kódja közötti megállapodás szerinti viselkedésre; minden, ami a szerződésben nem szerepel, előzetes értesítés nélkül megváltozhat.

Manuális adatabsztrakció

Míg az adatok absztrakciójának nagy része számítástechnikán és automatizáláson keresztül történik, előfordul, hogy ezt a folyamatot manuálisan, azaz programozási beavatkozás nélkül hajtják végre. Megértésének egyik módja az adatok absztrakciója a szakirodalom szisztematikus áttekintése során. Ebben a módszerben az adatokat egy vagy több absztraktor absztraktálja a metaanalízis során, és a hibákat kettős adatabsztrakcióval csökkentik. Ezt független ellenőrzés, azaz elbírálás követi.^[13]

Absztrakció az objektumorientált programozásban

Az objektumorientált programozási elméletben az absztrakció olyan objektumok meghatározását jelenti, amelyek absztrakt "szereplőket" képviselnek, amelyek munkát végezhetnek, jelentést készíthetnek, és megváltoztathatják állapotukat, valamint "kommunikálhatnak" a rendszer más objektumaival. Azt, amikor az absztrakció a meghatározott műveletekbe lép, lehetővé téve különböző típusú objektumok helyettesítését, polimorfizmusnak nevezzük. Amikor az ellenkező irányba halad, a típusokon vagy osztályokon belül, és strukturálja azokat, hogy egyszerűsítsen egy összetett kapcsolathalmazt, delegálásnak vagy öröklődésnek nevezzük.

Különböző objektumorientált programozási nyelvek hasonló lehetőségeket kínálnak az absztrakcióhoz, amelyek mindegyike támogatja a polimorfizmus általános stratégiáját az objektumorientált programozásban, amely magában foglalja az egyik típus helyettesítését egy másik típussal, azonos vagy hasonló szerepkörben. Bár nem az általánosan támogatott módon, de egy konfiguráció, kép vagy csomag előre meghatározhatja az összerendelések nagy részét a fordítási, a hivatkozási vagy a betöltési időben.

A Common Lisp Object System vagy Self például kevesebb osztálypéldány megkülönböztetést tartalmaz, és több delegációt használ a polimorfizmushoz. Az egyes objektumok és funkciók rugalmasabban absztraktálódnak, hogy jobban illeszkedjenek a Lisp közös funkcionális örökségéhez.

A C++ egy másik végletet is példáz: nagymértékben támaszkodik a sablonokra, a túlterhelésre és más statikus összerendelésekre fordítás közben, ami viszont bizonyos rugalmassági problémákkal jár.

Tekintsünk például egy Java-minta kódtöredéket, amely néhány közönséges farm „állatot” képvisel olyan absztrakciós szinten, amely alkalmas éhségük és táplálkozásuk egyszerű szempontjainak modellezésére. Meghatároz egy Animal osztályt, amely mind az állat állapotát, mind funkcióit reprezentálja:

public class Animal extends LivingThing
{
     private Location loc;
     private double energyReserves;

     public boolean isHungry() {
         return energyReserves < 2.5;
     }
     public void eat(Food food) {
         // Consume food
         energyReserves += food.getCalories();
     }
     public void moveTo(Location location) {
         // Move to new location
         this.loc = location;
     }
}

A fenti definícióval létrehozhatunk Animal típusú objektumokat, és így hívhatjuk meg a metódusaikat:

thePig = new Animal();
theCow = new Animal();
if (thePig.isHungry()) {
    thePig.eat(tableScraps);
}
if (theCow.isHungry()) {
    theCow.eat(grass);
}
theCow.moveTo(theBarn);

A fenti példában az Animal osztály egy tényleges állat helyett használt absztrakció, LivingThing pedig az Animal egy további absztrakciója (jelen esetben egy általánosítása).

Ha az állatok differenciáltabb hierarchiáját kívánjuk meg – hogy megkülönböztessük mondjuk azokat, akik tejet adnak azoktól, akik életük végén húson kívül mást sem adnak –, az az absztrakció egy köztes szintje.

Egy ilyen absztrakció megszüntetheti annak szükségességét, hogy az program kódolója meghatározza az élelmiszer típusát, így ehelyett az etetési ütemezésre koncentrálhat. A két osztály összekapcsolható öröklődéssel vagy önállóan, és a programozó a két típus között különböző mértékű polimorfizmust határozhat meg. Ezek a lehetőségek drasztikusan változnak a nyelvek között, de általában mindegyik képes bármit elérni, ami a többi nyelven elérhető. A nagyon sok műveleti túlterhelés adattípusonként ugyanolyan hatást fejthet ki fordítási időben, mint bármely fokú öröklődés vagy a polimorfizmus elérésének más módjai. Az osztályjelölés egyszerűen a kódoló kényelme.

Objektumorientált tervezés

Az objektumorientált tervezés és a tartományelemzés fő kérdésévé válnak a kódoló felügyelete alá tartozó döntések – a valós világban a releváns kapcsolatok meghatározása az objektumorientált elemzés vagy az örökölt elemzés feladata.

Általánosságban elmondható, hogy a megfelelő absztrakció meghatározásához sok kis döntést kell hozni a hatókörrel kapcsolatban (tartományelemzés), meg kell határozni, hogy milyen más rendszerekkel kell együttműködni (örökölt elemzés), majd részletes objektumorientált elemzést kell végezni, amely a projekt időbeli és költségvetési keretén belül van kifejezve.

Megfontolások

Amikor a programozási nyelvek formális szemantikájáról, formális metódusairól vagy absztrakt értelmezéséről beszélünk, az absztrakció a megfigyelt programviselkedések kevésbé részletes, de biztonságos meghatározását jelenti. Például megfigyelhetjük csak a programvégrehajtások végeredményét, ahelyett, hogy a végrehajtás összes közbenső lépését figyelembe vennénk.

Az absztrakció egy konkrét (pontosabb) végrehajtási modellre vonatkozik.

Az absztrakció akkor lehet pontos vagy hű egy tulajdonság tekintetében, ha egy adott tulajdonságra vonatkozó kérdésre egyformán jól tud válaszolni konkrét vagy absztrakt modellen.

Az absztrakcióknak azonban nem feltétlenül kell pontosaknak, vagy megbízhatóaknak lenniük. Ez azt jelenti, hogy lehetõvé kell tenni, hogy megalapozott válaszokat kapjuk tőlük – még akkor is, ha az absztrakció eredménye nem eldönthető. Például egy osztály tanulóit elvonatkoztathatja minimális és maximális életkoruk alapján; ha valaki azt kérdezi, hogy egy bizonyos személy ebbe az osztályba tartozik-e, egyszerűen összehasonlíthatja a személy életkorát a minimális és maximális életkorral; ha a kora a tartományon kívül esik, nyugodtan azt lehet válaszolni, hogy az illető nem tartozik az osztályba; ha nem, akkor csak azt lehet válaszolni, hogy „nem tudom”.

A programozási nyelvben található absztrakció szintje befolyásolhatja annak általános használhatóságát. A Kognitív dimenziók keretrendszere tartalmazza az absztrakciós gradiens fogalmát egy formalizmusban. Ez a keretrendszer lehetővé teszi a programozási nyelv tervezőjének, hogy tanulmányozza az absztrakció és a tervezés egyéb jellemzői közötti kompromisszumokat, és azt, ahogyan az absztrakció változásai befolyásolják a nyelv használhatóságát.

Az absztrakciók hasznosnak bizonyulhatnak számítógépes programokkal való foglalkozás során, mivel a számítógépes programok nem triviális tulajdonságai lényegében eldönthetetlenek (lásd Rice tételét). Következésképpen a számítógépes programok viselkedésére vonatkozó információk lekérésére szolgáló automatikus módszereknek el kell hagyniuk a befejezést (egyes esetekben meghiúsulhatnak, összeomolhatnak vagy soha nem adnak eredményt), a megbízhatóságot (hamis információt szolgáltathatnak), vagy a pontosságot (bizonyos kérdésekre "nem tudom" választ adhatnak)

Az absztrakció az absztrakt értelmezés alapfogalma. A modellellenőrzés általában a vizsgált rendszerek absztrakt változatain történik.

Az absztrakció szintjei

A számítástechnika általában az absztrakció szintjeit (vagy ritkábban rétegeit) mutatja be, ahol minden szint ugyanazon információk és folyamatok más-más modelljét képviseli, de eltérő részletességgel. Mindegyik szint egy olyan kifejezésrendszert használ, amely egyedi objektumok és kompozíciók halmazát foglalja magába, amelyek csak egy adott tartományra vonatkoznak.^[14] Minden viszonylag absztrakt, "magasabb" szint egy viszonylag konkrét, "alacsonyabb" szintre épül. Például, a kapuk elektronikus áramkörökre, a binárisok a kapukra, a gépi nyelvek a binárisokra, a programozási nyelvek a gépi nyelvekre, az alkalmazások és az operációs rendszerek programozási nyelvekre építenek. Minden szintet megtestesít, de nem határoz meg az alatta lévő szint, így a leírás nyelve némileg önálló.

Adatbázis rendszerek

Mivel az adatbázisrendszerek sok felhasználója nem ismeri alaposan a számítógépes adatstruktúrákat, az adatbázis-fejlesztők gyakran a következő szinteken keresztül rejtik el a bonyolultságot:

Fizikai szint: Az absztrakció legalacsonyabb szintje azt írja le, hogy egy rendszer valójában hogyan tárolja az adatokat. A fizikai szint részletesen leírja az összetett alacsony szintű adatstruktúrákat.

Logikai szint: Az absztrakció következő szintje azt írja le, hogy az adatbázis milyen adatokat tárol, és milyen kapcsolatok vannak ezen adatok között. A logikai szint tehát egy egész adatbázist ír le, kis számú, viszonylag egyszerű struktúrával. Bár az egyszerű struktúrák logikai szinten való megvalósítása összetett fizikai szintű struktúrákat is tartalmazhat, a logikai szint használójának nem kell tisztában lennie ezzel a bonyolultsággal. Ezt fizikai adatfüggetlenségnek nevezik. Az adatbázis-adminisztrátorok, akiknek el kell dönteniük, hogy milyen információkat tároljanak az adatbázisban, az absztrakció logikai szintjét használják.

Nézetszint: A legmagasabb szintű absztrakció a teljes adatbázisnak csak egy részét írja le. Annak ellenére, hogy a logikai szint egyszerűbb struktúrákat használ, a komplexitás megmarad a nagy adatbázisban tárolt információk sokfélesége miatt. Az adatbázisrendszer sok felhasználójának nincs szüksége mindezekre az információkra, ehelyett csak az adatbázis egy részét kell elérniük. Az absztrakció nézetszintje azért létezik, hogy leegyszerűsítse a rendszerrel való interakciót. A rendszer több nézetet is biztosíthat ugyanahhoz az adatbázishoz.

Rétegelt felépítés

Az a képesség, hogy a tervezés különböző szintű absztrakciókat biztosíthasson:

jelentősen leegyszerűsíti a tervezést,
lehetővé teszi a különböző szereplők számára, hogy hatékonyan dolgozzanak az absztrakció különböző szintjein,
támogatja a szoftvertermékek hordozhatóságát (ideális esetben modell alapú).

A rendszertervezés és az üzleti folyamattervezés egyaránt használhatja ezt. Egyes tervezési folyamatok kifejezetten olyan terveket hoznak létre, amelyek különböző szintű absztrakciót tartalmaznak.

A rétegelt felépítés az alkalmazás problémáit halmozott csoportokba (rétegekbe) particionálja. Ez a számítógépes szoftverek, hardverek és a kommunikáció tervezésénél használt technika, amelyben a rendszer- vagy hálózati komponensek rétegenként vannak elszigetelve, így az egyik rétegben változtatások hajthatók végre anélkül, hogy a többit érintenék.

Jegyzetek

↑ Colburn (2007. június 5.). „Abstraction in Computer Science” (angol nyelven). Minds and Machines 17 (2), 169–184. o. DOI:10.1007/s11023-007-9061-7. ISSN 0924-6495.
↑ ^a ^b Kramer (2007. április 1.). „Is abstraction the key to computing?”. Communications of the ACM 50 (4), 36–42. o. DOI:10.1145/1232743.1232745. ISSN 0001-0782.
↑ Ben-Ari (1998. március 1.). „Constructivism in computer science education”. ACM SIGCSE Bulletin 30 (1), 257, 257–261. o. DOI:10.1145/274790.274308. ISSN 0097-8418.
↑ Comer (1989. január 1.). „Computing as a discipline”. Communications of the ACM 32 (1), 9–23. o. DOI:10.1145/63238.63239. ISSN 0001-0782.
↑ Liskov (1988. május 1.). „Keynote address – data abstraction and hierarchy”. ACM SIGPLAN Notices 23, 17–34. o, Kiadó: ACM. DOI:10.1145/62138.62141.
↑ Barendregt, Hendrik Pieter. The lambda calculus: its syntax and semantics, Revised, Amsterdam: North-Holland (1984. november 15.). ISBN 0444867481. OCLC 10559084
↑ Barendregt, Hendrik Pieter. Lambda calculus with types, Dekkers, Wil., Statman, Richard., Alessi, Fabio., Association for Symbolic Logic., Cambridge, UK: Cambridge University Press (2013. november 15.). ISBN 9780521766142. OCLC 852197712
↑ Newell, Allen. Computer science as empirical inquiry: symbols and search. ACM, 1975. o.. DOI: 10.1145/1283920.1283930 (2007. január 1.). ISBN 9781450310499
↑ Floridi (2008. szeptember 1.). „The Method of Levels of Abstraction” (angol nyelven). Minds and Machines 18 (3), 303–329. o. DOI:10.1007/s11023-008-9113-7. ISSN 0924-6495.
↑ Spolsky: The Law of Leaky Abstractions
↑ Abstract Methods and Classes. The Java™ Tutorials. Oracle. (Hozzáférés: 2014. szeptember 4.)
↑ Using an Interface as a Type. The Java™ Tutorials. Oracle. (Hozzáférés: 2014. szeptember 4.)
↑ E (2020. november 15.). „Adjudication rather than experience of data abstraction matters more in reducing errors in abstracting data in systematic reviews” (angol nyelven). Research Synthesis Methods 11 (3), 354–362. o. DOI:10.1002/jrsm.1396. ISSN 1759-2879. PMID 31955502.
↑ Luciano Floridi, Levellism and the Method of Abstraction IEG – Research Report 22.11.04

Fordítás

Ez a szócikk részben vagy egészben az Abstraction (computer science) című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További információk

SimArch Példa réteges architektúrára elosztott szimulációs rendszerek számára

Kapcsolódó szócikkek

Absztrakciós elv (számítógép-programozás)
Absztrakciós inverzió az absztrakció egyik veszélyének antimintájára
Algoritmus
Beágyazás a megvalósítás részleteit elrejtő absztrakciókhoz
Lambda-absztrakció egy kifejezés valamely változó függvényévé tételére
Integer (számítástechnika)

[:1-1] Colburn (2007. június 5.). „Abstraction in Computer Science” (angol nyelven). Minds and Machines 17 (2), 169–184. o. DOI:10.1007/s11023-007-9061-7. ISSN 0924-6495.

[:0-2] Kramer (2007. április 1.). „Is abstraction the key to computing?”. Communications of the ACM 50 (4), 36–42. o. DOI:10.1145/1232743.1232745. ISSN 0001-0782.

[3] Ben-Ari (1998. március 1.). „Constructivism in computer science education”. ACM SIGCSE Bulletin 30 (1), 257, 257–261. o. DOI:10.1145/274790.274308. ISSN 0097-8418.

[4] Comer (1989. január 1.). „Computing as a discipline”. Communications of the ACM 32 (1), 9–23. o. DOI:10.1145/63238.63239. ISSN 0001-0782.

[5] Liskov (1988. május 1.). „Keynote address – data abstraction and hierarchy”. ACM SIGPLAN Notices 23, 17–34. o, Kiadó: ACM. DOI:10.1145/62138.62141.

[6] Barendregt, Hendrik Pieter. The lambda calculus: its syntax and semantics, Revised, Amsterdam: North-Holland (1984. november 15.). ISBN 0444867481. OCLC 10559084

[7] Barendregt, Hendrik Pieter. Lambda calculus with types, Dekkers, Wil., Statman, Richard., Alessi, Fabio., Association for Symbolic Logic., Cambridge, UK: Cambridge University Press (2013. november 15.). ISBN 9780521766142. OCLC 852197712

[8] Newell, Allen. Computer science as empirical inquiry: symbols and search. ACM, 1975. o.. DOI: 10.1145/1283920.1283930 (2007. január 1.). ISBN 9781450310499

[9] Floridi (2008. szeptember 1.). „The Method of Levels of Abstraction” (angol nyelven). Minds and Machines 18 (3), 303–329. o. DOI:10.1007/s11023-008-9113-7. ISSN 0924-6495.

[10] Spolsky: The Law of Leaky Abstractions

[Oracle_Java_abstract-11] Abstract Methods and Classes. The Java™ Tutorials. Oracle. (Hozzáférés: 2014. szeptember 4.)

[Oracle_Java_interface-12] Using an Interface as a Type. The Java™ Tutorials. Oracle. (Hozzáférés: 2014. szeptember 4.)

[13] E (2020. november 15.). „Adjudication rather than experience of data abstraction matters more in reducing errors in abstracting data in systematic reviews” (angol nyelven). Research Synthesis Methods 11 (3), 354–362. o. DOI:10.1002/jrsm.1396. ISSN 1759-2879. PMID 31955502.

[14] Luciano Floridi, Levellism and the Method of Abstraction IEG – Research Report 22.11.04

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]