Abstraktion (datalogi) - Abstraction (computer science)
Essensen af abstraktion er at bevare oplysninger, der er relevante i en given kontekst, og glemme oplysninger, der er irrelevante i den kontekst.
I softwareteknik og datalogi er abstraktion :
- processen med at fjerne fysiske, rumlige eller tidsmæssige detaljer eller attributter i studiet af objekter eller systemer for at fokusere opmærksomheden på detaljer af større betydning det ligner karakteren af generaliseringsprocessen ;
- skabelsen af et abstrakt koncept - objekter ved at spejle fælles træk eller attributter for forskellige ikke -abstrakte objekter eller undersøgelsessystemer - resultatet af abstraktionsprocessen.
Abstraktion er generelt et grundlæggende koncept inden for datalogi og softwareudvikling . Abstraktionsprocessen kan også kaldes modellering og er tæt forbundet med begreberne teori og design . Modeller kan også betragtes som typer af abstraktioner i henhold til deres generalisering af aspekter af virkeligheden .
Abstraktion i datalogi er tæt forbundet med abstraktion i matematik på grund af deres fælles fokus på at bygge abstraktioner som objekter, men er også relateret til andre forestillinger om abstraktion, der bruges inden for andre områder som kunst .
Abstraktioner kan også referere til virkelige objekter og systemer, regler for beregningssystemer eller regler for programmeringssprog, der bærer eller udnytter funktioner i selve abstraktionen, såsom:
- brugen af datatyper til at udføre dataabstraktion til adskillelse af brug fra arbejdsrepræsentationer af datastrukturer inden for programmer ;
- begrebet procedurer, funktioner eller underrutiner, der repræsenterer en specifik for implementering af kontrolflow i programmer
- reglerne, der almindeligvis kaldes "abstraktion", der generaliserer udtryk ved hjælp af frie og bundne variabler i de forskellige versioner af lambda -beregning ;
- brugen af S-udtryk som en abstraktion af datastrukturer og programmer i programmeringssproget Lisp ;
- processen med at reorganisere almindelig adfærd fra ikke-abstrakte klasser til "abstrakte klasser" ved hjælp af arv til at abstrahere over underklasser som set i de objektorienterede C ++ og Java- programmeringssprog.
Begrundelse
Computing fungerer for det meste uafhængigt af den konkrete verden. Hardwaren implementerer en beregningsmodel, der kan udskiftes med andre. Softwaren er struktureret i arkitekturer for at sætte mennesker i stand til at skabe de enorme systemer ved at koncentrere sig om et par spørgsmål ad gangen. Disse arkitekturer er lavet af specifikke valg af abstraktioner. Greenspun's tiende regel er en aforisme om, hvordan en sådan arkitektur er både uundgåelig og kompleks.
En central form for abstraktion i computing er sprogabstraktion: nye kunstige sprog udvikles til at udtrykke specifikke aspekter af et system. Modelsprog hjælper med at planlægge. Computersprog kan behandles med en computer. Et eksempel på denne abstraktionsproces er generationsudviklingen af programmeringssprog fra maskinsprog til samlingssprog og sprog på højt niveau . Hver etape kan bruges som et springbræt til den næste fase. Sprogabstraktionen fortsætter f.eks. I scriptsprog og domænespecifikke programmeringssprog .
Inden for et programmeringssprog lader nogle funktioner programmereren skabe nye abstraktioner. Disse inkluderer underprogrammer , moduler , polymorfisme og softwarekomponenter . Nogle andre abstraktioner såsom softwaredesignmønstre og arkitektoniske stilarter forbliver usynlige for en oversætter og fungerer kun i design af et system.
Nogle abstraktioner forsøger at begrænse rækkevidden af begreber, en programmør skal være opmærksom på, ved helt at skjule de abstraktioner, som de igen er bygget på. Softwareingeniøren og forfatteren Joel Spolsky har kritiseret disse bestræbelser ved at hævde, at alle abstraktioner er utætte - at de aldrig helt kan skjule detaljerne nedenfor; dette negerer imidlertid ikke abstraktionens nytteværdi.
Nogle abstraktioner er designet til at fungere sammen med andre abstraktioner-for eksempel kan et programmeringssprog indeholde en fremmed funktionsgrænseflade til opkald til sproget på lavere niveau.
Abstraktionsfunktioner
Programmeringssprog
Forskellige programmeringssprog giver forskellige former for abstraktion afhængigt af de tiltænkte applikationer til sproget. For eksempel:
- I objektorienterede programmeringssprog som C ++ , Object Pascal eller Java er begrebet abstraktion i sig selv blevet et deklarativt udsagn-ved hjælp af syntaksen (i C ++ ) eller søgeordene og (i Java ). Efter en sådan erklæring er det programmørens ansvar at implementere en klasse for at instantiere genstanden for erklæringen.
function(parameters) = 0;
abstract
interface
- Funktionelle programmeringssprog udviser almindeligvis abstraktioner relateret til funktioner, såsom lambda-abstraktioner (gør et udtryk til en funktion af en variabel) og funktioner i højere orden (parametre er funktioner).
- Moderne medlemmer af Lisp -programmeringssprogsfamilien som Clojure , Scheme og Common Lisp understøtter makrosystemer for at tillade syntaktisk abstraktion. Andre programmeringssprog såsom Scala har også makroer eller meget lignende metaprogramming funktioner (f.eks Haskell har Skabelon Haskell , og OCaml har MetaOCaml ). Disse kan give en programmerer mulighed for at fjerne kogepladekode , abstrahere kedelige funktionsopkaldssekvenser, implementere nye kontrolflowstrukturer og implementere Domain Specific Languages (DSL'er) , som gør det muligt at udtrykke domænespecifikke koncepter på en kortfattet og elegant måde. Alle disse, når de bruges korrekt, forbedrer både programmørens effektivitet og klarheden af koden ved at gøre det tilsigtede formål mere eksplicit. En konsekvens af syntaktisk abstraktion er også, at enhver Lisp-dialekt og faktisk næsten ethvert programmeringssprog i princippet kan implementeres i enhver moderne Lisp med betydeligt reduceret (men stadig ikke-triviel i nogle tilfælde) indsats sammenlignet med "mere traditionel" programmeringssprog som Python , C eller Java .
Specifikationsmetoder
Analytikere har udviklet forskellige metoder til formelt at specificere softwaresystemer. Nogle kendte metoder omfatter:
- Abstrakt-model baseret metode (VDM, Z);
- Algebraiske teknikker (lærk, CLEAR, OBJ, ACT ONE, CASL);
- Procesbaserede teknikker (LOTOS, SDL, Estelle);
- Sporbaserede teknikker (SPECIAL, TAM);
- Vidensbaserede teknikker (Refine, Gist).
Specifikationssprog
Specifikationssprog er generelt afhængige af abstraktioner af en eller anden art, da specifikationer typisk er defineret tidligere i et projekt (og på et mere abstrakt niveau) end en eventuel implementering. Den UML specifikationssprog, for eksempel, giver definitionen af abstrakte klasser, som i et vandfald projekt, forbliver abstrakt under arkitektur og specifikation fase af projektet.
Kontroller abstraktion
Programmeringssprog tilbyder kontrolabstraktion som et af hovedformålene med deres anvendelse. Computermaskiner forstår operationer på det meget lave niveau, såsom at flytte nogle bits fra et sted i hukommelsen til et andet sted og producere summen af to sekvenser af bits. Programmeringssprog gør det muligt at gøre dette på det højere niveau. Overvej f.eks. Denne erklæring skrevet på en Pascal -lignende måde:
a := (1 + 2) * 5
For et menneske virker dette som en ret simpel og oplagt beregning ( "et plus to er tre, fem er femten" ). Imidlertid er de trin på lavt niveau, der er nødvendige for at udføre denne evaluering, og returnere værdien "15" og derefter tildele værdien til variablen "a", faktisk ret subtile og komplekse. Værdierne skal konverteres til binær repræsentation (ofte en meget mere kompliceret opgave end man skulle tro) og beregningerne nedbrydes (af kompilatoren eller tolken) til samleinstruktioner (igen, som er meget mindre intuitive for programmereren: operationer som f.eks. at flytte et binært register til venstre eller tilføje det binære komplement af indholdet i et register til et andet, er simpelthen ikke, hvordan mennesker tænker om de abstrakte aritmetiske operationer ved addition eller multiplikation). Endelig tildeler den resulterende værdi "15" variablen mærket "a", så "a" kan bruges senere, indebærer yderligere 'bag kulisserne' trin med at slå en variabels etiket og den resulterende placering i fysisk op eller virtuel hukommelse, lagring af den binære repræsentation af "15" til denne hukommelsesplacering osv.
Uden kontrolabstraktion skulle en programmør specificere alle trin på register/binært niveau, hver gang de blot ville tilføje eller multiplicere et par tal og tildele resultatet til en variabel. En sådan dobbeltarbejde har to alvorlige negative konsekvenser:
- det tvinger programmereren til konstant at gentage ret almindelige opgaver hver gang en lignende operation er nødvendig
- det tvinger programmereren til at programmere til det særlige hardware- og instruktionssæt
Struktureret programmering
Struktureret programmering indebærer opdeling af komplekse programopgaver i mindre stykker med klar flowkontrol og grænseflader mellem komponenter, med en reduktion af kompleksitetspotentialet for bivirkninger.
I et simpelt program kan dette have til formål at sikre, at sløjfer har enkelte eller tydelige udgangspunkter og (hvor det er muligt) at have enkelte udgangspunkter fra funktioner og procedurer.
I et større system kan det indebære at opdele komplekse opgaver i mange forskellige moduler. Overvej et system, der håndterer lønninger på skibe og på landkontorer:
- Det øverste niveau kan indeholde en menu med typiske slutbrugeroperationer.
- Inden for det kunne være selvstændige eksekverbare filer eller biblioteker til opgaver som at logge på og af medarbejdere eller udskrive checks.
- Inden for hver af disse selvstændige komponenter kunne der være mange forskellige kildefiler, der hver indeholdt programkoden til at håndtere en del af problemet, med kun udvalgte grænseflader tilgængelige for andre dele af programmet. Et tegn på program kan have kildefiler til hver dataindtastningsskærm og databasegrænsefladen (som i sig selv kan være et selvstændigt tredjepartsbibliotek eller et statisk forbundet sæt biblioteksrutiner).
- Enten skal databasen eller lønprogrammet også starte processen med at udveksle data mellem skib og land, og den dataoverførselsopgave vil ofte indeholde mange andre komponenter.
Disse lag frembringer effekten af at isolere implementeringsdetaljerne for en komponent og dens forskellige interne metoder fra de andre. Objektorienteret programmering omfavner og udvider dette koncept.
Dataabstraktion
Dataabstraktion håndhæver en klar adskillelse mellem en datatypes abstrakte egenskaber og de konkrete detaljer om dens implementering. De abstrakte egenskaber er dem, der er synlige for klientkode, der gør brug af datatypen - grænsefladen til datatypen - mens den konkrete implementering holdes helt privat og faktisk kan ændres, for eksempel for at inkorporere effektivitetsforbedringer over tid. Ideen er, at sådanne ændringer ikke formodes at have indflydelse på klientkode, da de ikke involverer nogen forskel i den abstrakte adfærd.
For eksempel kan man definere en abstrakt datatype kaldet opslagstabel, der unikt forbinder nøgler med værdier , og hvor værdier kan hentes ved at specificere deres tilsvarende nøgler. En sådan opslagstabel kan implementeres på forskellige måder: som en hashtabel , et binært søgetræ eller endda en simpel lineær liste over (nøgle: værdi) par. Hvad angår klientkode, er de abstrakte egenskaber af typen de samme i hvert tilfælde.
Selvfølgelig afhænger alt dette af at få detaljer om grænsefladen lige i første omgang, da eventuelle ændringer der kan have stor indvirkning på klientkode. Som en måde at se på dette: grænsefladen danner en kontrakt om aftalt adfærd mellem datatype og klientkode; Alt, der ikke er angivet i kontrakten, kan ændres uden varsel.
Manuel dataabstraktion
Mens meget af dataabstraktion sker gennem datalogi og automatisering, er der tidspunkter, hvor denne proces udføres manuelt og uden programmeringsindgreb. En måde dette kan forstås på er gennem dataabstraktion i processen med at foretage en systematisk gennemgang af litteraturen. I denne metode abstraheres data af en eller flere abstraktører, når de foretager en metaanalyse , med fejl reduceret gennem dobbelt dataabstraktion efterfulgt af uafhængig kontrol, kendt som dom .
Abstraktion i objektorienteret programmering
I objektorienteret programmering teori, abstraktion indebærer mulighed for at definere objekter, der repræsenterer abstrakte "aktører", der kan udføre arbejdet, rapport om og ændre deres tilstand, og "kommunikere" med andre objekter i systemet. Begrebet indkapsling refererer til skjulning af tilstandsdetaljer , men at udvide begrebet datatype fra tidligere programmeringssprog til at knytte adfærd stærkest til dataene og standardisere den måde, hvorpå forskellige datatyper interagerer, er begyndelsen på abstraktion . Når abstraktion fortsætter til de definerede operationer, så objekter af forskellige typer kan erstattes, kaldes det polymorfisme . Når det fortsætter i den modsatte retning, inden for typerne eller klasserne, og strukturerer dem for at forenkle et komplekst sæt af relationer, kaldes det delegering eller arv .
Forskellige objektorienterede programmeringssprog tilbyder lignende muligheder for abstraktion, alle for at understøtte en generel strategi for polymorfisme i objektorienteret programmering, som omfatter substitution af en type til en anden i samme eller lignende rolle. Selvom det ikke er så generelt understøttet, en konfiguration kan eller billede eller pakke forudbestemme en stor del af disse bindinger på compile-tid , link-tid , eller loadtime . Dette ville kun efterlade et minimum af sådanne bindinger i løbetid .
Common Lisp Object System eller Self , for eksempel, har mindre klasse-forekomstsondeling og mere brug af delegering til polymorfisme . Individuelle objekter og funktioner abstraheres mere fleksibelt for bedre at passe med en fælles funktionel arv fra Lisp .
C ++ eksemplificerer en anden ekstrem: den er stærkt afhængig af skabeloner og overbelastning og andre statiske bindinger ved kompileringstidspunktet, hvilket igen har visse fleksibilitetsproblemer.
Selvom disse eksempler tilbyder alternative strategier for at opnå den samme abstraktion, ændrer de ikke fundamentalt behovet for at understøtte abstrakte substantiver i kode - al programmering er afhængig af en evne til at abstrahere verber som funktioner, substantiver som datastrukturer og enten som processer.
Overvej f.eks. Et eksempel på et Java -fragment for at repræsentere nogle almindelige husdyr "til et abstraktionsniveau, der er egnet til at modellere simple aspekter af deres sult og fodring. Det definerer en Animal
klasse til at repræsentere både dyrets tilstand og dets funktioner:
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;
}
}
Med ovenstående definition kunne man oprette objekter af typen Dyr og kalder deres metoder sådan:
thePig = new Animal();
theCow = new Animal();
if (thePig.isHungry()) {
thePig.eat(tableScraps);
}
if (theCow.isHungry()) {
theCow.eat(grass);
}
theCow.moveTo(theBarn);
I ovenstående eksempel er klassen Animal
en abstraktion, der bruges i stedet for et faktisk dyr, LivingThing
er en yderligere abstraktion (i dette tilfælde en generalisering) af Animal
.
Hvis man kræver et mere differentieret hierarki af dyr - for eksempel at differentiere dem, der leverer mælk fra dem, der ikke leverer andet end kød i slutningen af deres liv - det er et mellemled af abstraktion, sandsynligvis DairyAnimal (køer, geder), der ville spise mad, der er egnet til at give god mælk, og MeatAnimal (svin, styr), der ville spise mad for at give den bedste kødkvalitet.
En sådan abstraktion kan fjerne behovet for, at applikationskoderen angiver fødevaretypen, så de i stedet kan koncentrere sig om fodringsplanen. De to klasser kunne relateres ved hjælp af arv eller stå alene, og programmøren kunne definere varierende grader af polymorfisme mellem de to typer. Disse faciliteter har en tendens til at variere drastisk mellem sprog, men generelt kan hver opnå alt, hvad der er muligt med nogen af de andre. Rigtig mange driftsoverbelastninger, datatype efter datatype, kan have den samme effekt ved kompileringstidspunktet som enhver form for arv eller andre midler til at opnå polymorfisme. Klassenotationen er simpelthen en koders bekvemmelighed.
Objektorienteret design
Beslutninger om, hvad der skal abstraheres, og hvad der skal holdes under kontrol af koderen, bliver det største problem ved objektorienteret design og domæneanalyse- faktisk at bestemme de relevante relationer i den virkelige verden er bekymringen for objektorienteret analyse eller arveanalyse .
Generelt for at bestemme passende abstraktion skal man træffe mange små beslutninger om omfang (domæneanalyse), bestemme hvilke andre systemer man skal samarbejde med (ældre analyse) og derefter udføre en detaljeret objektorienteret analyse, der kommer til udtryk inden for projekttid og budget begrænsninger som et objektorienteret design. I vores enkle eksempel er domænet ladegården, de levende svin og køer og deres spisevaner er de gamle begrænsninger, den detaljerede analyse er, at kodere skal have fleksibiliteten til at fodre dyrene med det, der er tilgængeligt, og der er derfor ingen grund til at kode typen af mad ind i selve klassen, og designet er en enkelt dyreklasse, hvor svin og køer er forekomster med de samme funktioner. En beslutning om at differentiere DairyAnimal ville ændre den detaljerede analyse, men domæne- og arveanalysen ville være uændret-dermed er den helt under programmeringens kontrol, og den kaldes en abstraktion i objektorienteret programmering adskilt fra abstraktion i domæne eller arv analyse.
Overvejelser
Når man diskuterer formel semantik i programmeringssprog , formelle metoder eller abstrakt fortolkning , refererer abstraktion til handlingen om at overveje en mindre detaljeret, men sikker, definition af den observerede programadfærd. For eksempel kan man kun observere det endelige resultat af programudførelser i stedet for at overveje alle de mellemliggende trin i henrettelser. Abstraktion defineres til en konkret (mere præcis) udførelsesmodel.
Abstraktion kan være nøjagtig eller trofast med hensyn til en ejendom, hvis man kan besvare et spørgsmål om ejendommen lige godt på den konkrete eller abstrakte model. For eksempel, hvis man ønsker at vide, hvad resultatet af evalueringen af et matematisk udtryk, der kun involverer heltal +, -, ×, er modulo n værd , skal man kun udføre alle operationer modulo n (en velkendt form for denne abstraktion støber ud ni ).
Abstraktioner, men ikke nødvendigvis nøjagtige , bør være sunde . Det vil sige, at det burde være muligt at få sunde svar fra dem - selvom abstraktionen ganske enkelt kan give et resultat af uafgørelighed . For eksempel kan elever i en klasse abstraheres af deres minimale og maksimale alder; hvis man spørger, om en bestemt person tilhører den klasse, kan man ganske enkelt sammenligne denne persons alder med den minimale og maksimale alder; hvis hans alder ligger uden for området, kan man roligt svare, at personen ikke tilhører klassen; hvis det ikke gør det, kan man kun svare "jeg ved det ikke".
Abstraktionsniveauet i et programmeringssprog kan påvirke dets generelle anvendelighed . Den kognitive dimensioner rammer omfatter begrebet abstraktion gradient i en formalisme. Denne ramme giver designeren af et programmeringssprog mulighed for at studere afvejningerne mellem abstraktion og andre karakteristika ved designet, og hvordan ændringer i abstraktion påvirker sprogets anvendelighed.
Abstraktioner kan vise sig nyttige i forbindelse med computerprogrammer, fordi ikke-trivielle egenskaber ved computerprogrammer i det væsentlige ikke kan afgøres (se Rices sætning ). Som en konsekvens heraf skal automatiske metoder til at udlede oplysninger om computerprogrammers adfærd enten slippe afslutningen (ved nogle lejligheder kan de mislykkes, gå ned eller aldrig give et resultat), forsvarlighed (de kan give falske oplysninger) eller præcision ( de kan svare "jeg ved det ikke" på nogle spørgsmål).
Abstraktion er kernebegrebet for abstrakt fortolkning . Modelkontrol finder generelt sted på abstrakte versioner af de undersøgte systemer.
Abstraktionsniveauer
Datalogi præsenterer sædvanligvis niveauer (eller, mindre almindeligt, lag ) af abstraktion, hvor hvert niveau repræsenterer en anden model af den samme information og processer, men med varierende mængder detaljer. Hvert niveau bruger et udtrykssystem, der involverer et unikt sæt objekter og kompositioner, der kun gælder for et bestemt domæne. Hvert relativt abstrakt, "højere" niveau bygger på et relativt konkret, "lavere" niveau, som har en tendens til at give en stadig mere "granulær" repræsentation. For eksempel bygger porte på elektroniske kredsløb, binært på porte, maskinsprog på binært, programmeringssprog på maskinsprog, applikationer og operativsystemer på programmeringssprog. Hvert niveau er legemliggjort, men ikke bestemt, af niveauet under det, hvilket gør det til et beskrivelsessprog, der er noget selvstændigt.
Databasesystemer
Da mange brugere af databasesystemer ikke har grundig kendskab til computerdatastrukturer, skjuler databaseudviklere ofte kompleksitet gennem følgende niveauer:
Fysisk niveau: Det laveste abstraktionsniveau beskriver, hvordan et system faktisk lagrer data. Det fysiske niveau beskriver detaljerede komplekse datastrukturer på lavt niveau.
Logisk niveau: Det næste højere abstraktionsniveau beskriver, hvilke data databasen gemmer, og hvilke relationer der findes mellem disse data. Det logiske niveau beskriver således en hel database i form af et lille antal relativt enkle strukturer. Selvom implementering af de enkle strukturer på det logiske niveau kan indebære komplekse strukturer på fysisk niveau, behøver brugeren af det logiske niveau ikke at være opmærksom på denne kompleksitet. Dette kaldes fysisk datauafhængighed . Databaseadministratorer , der skal beslutte, hvilke oplysninger der skal opbevares i en database, bruger det logiske abstraktionsniveau.
Visningsniveau: Det højeste abstraktionsniveau beskriver kun en del af hele databasen. Selvom det logiske niveau anvender enklere strukturer, forbliver kompleksiteten på grund af de mange forskellige oplysninger, der er gemt i en stor database. Mange brugere af et databasesystem behøver ikke alle disse oplysninger; i stedet skal de kun få adgang til en del af databasen. Abstraktionens synsniveau eksisterer for at forenkle deres interaktion med systemet. Systemet kan give mange visninger for den samme database.
Lagdelt arkitektur
Evnen til at give et design af forskellige abstraktionsniveauer kan
- forenkle designet betydeligt
- gøre det muligt for forskellige rollespillere effektivt at arbejde på forskellige abstraktionsniveauer
- understøtte overførsel af softwareartifakter (ideelt set modelbaseret)
Systemdesign og forretningsprocesdesign kan begge bruge dette. Nogle designprocesser genererer specifikt designs, der indeholder forskellige abstraktionsniveauer.
Lagdelt arkitektur opdeler applikationens bekymringer i stablede grupper (lag). Det er en teknik, der bruges til at designe computersoftware, hardware og kommunikation, hvor system- eller netværkskomponenter isoleres i lag, så ændringer kan foretages i et lag uden at påvirke de andre.
Se også
- Abstraktionsprincip (computerprogrammering)
- Abstraktionsinversion for et antimønster af én fare i abstraktion
- Abstrakt datatype til en abstrakt beskrivelse af et datasæt
- Algoritme til en abstrakt beskrivelse af en beregningsmetode
- Bracket -abstraktion til at gøre et udtryk til en funktion af en variabel
- Datamodellering til strukturering af data uafhængigt af de processer, der bruger dem
- Indkapsling til abstraktioner, der skjuler implementeringsdetaljer
- Greenspun's tiende regel for et aforisme om et (det?) Optimale punkt i abstraktionens rum
- Funktion i højere orden til abstraktion, hvor funktioner producerer eller forbruger andre funktioner
- Lambda -abstraktion for at gøre et udtryk til en funktion af en variabel
- Liste over abstraktioner (datalogi)
- Forfining til det modsatte af abstraktion i computing
- Heltal (datalogi)
- Heuristisk (datalogi)
Referencer
Yderligere læsning
- Harold Abelson; Gerald Jay Sussman; Julie Sussman (25. juli 1996). Struktur og fortolkning af computerprogrammer (2 udg.). MIT Tryk. ISBN 978-0-262-01153-2. Arkiveret fra originalen den 26. februar 2009 . Hentet 22. juni 2012 .
- Spolsky, Joel (11. november 2002). "Loven om utætte abstraktioner" . Joel om software .
- Abstraktion/informations skjul - CS211 kursus, Cornell University.
- Eric S. Roberts (1997). Programmering af abstraktioner i CA Andet kursus i datalogi .
- Palermo, Jeffrey (29. juli 2008). "Løgarkitekturen" . Jeffrey Palermo .
- Vishkin, Uzi (januar 2011). "Brug af simpel abstraktion til at genopfinde computing til parallelisme" . Kommunikation af ACM . 54 (1): 75–85. doi : 10.1145/1866739.1866757 .
eksterne links
- SimArch -eksempel på lagdelt arkitektur til distribuerede simuleringssystemer.