View source for Abstraction (computer science)

{{short description |Software that provides access that hides details}}
{{Use dmy dates|date=December 2019}}

In [[software]], an '''abstraction''' provides access while hiding details that otherwise might make access more challenging.<ref name=":1">{{Cite journal |last1=Colburn |first1=Timothy |last2=Shute |first2=Gary |date=5 June 2007 |title=Abstraction in Computer Science |journal=Minds and Machines |language=en |volume=17 |issue=2 |pages=169–184 |doi=10.1007/s11023-007-9061-7 |issn=0924-6495 |s2cid=5927969}}</ref> It focuses attention on details of greater importance.<ref name=":0">{{Cite journal |last1=Kramer |first1=Jeff |date=1 April 2007 |title=Is abstraction the key to computing? |journal=Communications of the ACM |volume=50 |issue=4 |pages=36–42 |doi=10.1145/1232743.1232745 |issn=0001-0782 |s2cid=12481509}}</ref><ref>{{Cite journal |last1=Ben-Ari |first1=Mordechai |date=1 March 1998 |title=Constructivism in computer science education |journal=ACM SIGCSE Bulletin |volume=30 |issue=1 |pages=257, 257–261 |doi=10.1145/274790.274308 |issn=0097-8418 |doi-access=free}}</ref> Examples include the [[abstract data type]] which separates use from the representation of [[data (computer science)|data]]<ref>{{Cite book |last1=Liskov |first1=Barbara |chapter=Keynote address - data abstraction and hierarchy |s2cid=14219043 |date=1 May 1988 |title=Addendum to the proceedings on Object-oriented programming systems, languages and applications (Addendum) - OOPSLA '87 |journal=ACM SIGPLAN Notices |publisher=ACM |volume=23 |pages=17–34 |doi=10.1145/62138.62141 |isbn=0897912667}}</ref> and [[Function (computer programming)|functions]] that form a call tree that is more general at the base and more specific towards the leaves.

==Rationale==
{{Quote box|quote=The essence of abstraction is preserving information that is relevant in a given context, and forgetting information that is irrelevant in that context.|source=– [[John Guttag|John V. Guttag]]<ref>{{Cite book |last1=Guttag |first1=John V. |date=18 January 2013 |title=Introduction to Computation and Programming Using Python |edition=Spring 2013 |publisher=The MIT Press |location=Cambridge, Massachusetts |isbn=978-0262519632}}</ref>|width=25%}}

Computing mostly operates independently of the concrete world. The hardware implements a [[model of computation]] that is interchangeable with others.<ref>{{Cite journal |last1=Floridi |first1=Luciano |date=September 2008 |title=The Method of Levels of Abstraction |url=http://link.springer.com/10.1007/s11023-008-9113-7 |journal=Minds and Machines |language=en |volume=18 |issue=3 |pages=303–329 |doi=10.1007/s11023-008-9113-7|hdl=2299/2998 |s2cid=7522925 |issn=0924-6495|hdl-access=free|url-access=subscription }}</ref> The software is structured in [[software architecture|architecture]]s to enable humans to create the enormous systems by concentrating on a few issues at a time. These architectures are made of specific choices of abstractions. [[Greenspun's tenth rule]] is an [[aphorism]] on how such an architecture is both inevitable and complex.

Language abstraction is a central form of abstraction in computing: new artificial languages are developed to express specific aspects of a system. ''[[Modeling languages]]'' help in planning. ''[[Computer language]]s'' can be processed with a computer. An example of this abstraction process is the generational development of [[programming language]] from the [[first-generation programming language]] ([[machine language]]) to the [[second-generation programming language]] ([[assembly language]]) and the [[third-generation programming language]] ([[high-level programming language]]). Each stage can be used as a stepping stone for the next stage. The language abstraction continues for example in [[scripting language]]s and [[domain-specific language]]s.

Within a programming language, some features let the programmer create new abstractions. These include [[subroutine]]s, [[Modular programming|modules]], [[Polymorphism (computer science)|polymorphism]], and [[software component]]s. Some other abstractions such as [[software design pattern]]s and [[software architecture#Architectural styles and patterns|architectural styles]] remain invisible to a [[Translator (computing)|translator]] and operate only in the design of a system.

Some abstractions try to limit the range of concepts a programmer needs to be aware of, by completely hiding the abstractions they are built on. The software engineer and writer [[Joel Spolsky]] has criticized these efforts by claiming that all abstractions are ''[[leaky abstraction|leaky]]'' – that they can never completely hide the details below;<ref>{{cite web |url=http://www.joelonsoftware.com/articles/LeakyAbstractions.html |title=The Law of Leaky Abstractions |last1=Spolsky |first1=Joel |date=11 November 2002 |author1-link=Joel Spolsky}}</ref> however, this does not negate the usefulness of abstraction.

Some abstractions are designed to inter-operate with other abstractions – for example, a programming language may contain a [[foreign function interface]] for making calls to the lower-level language.

==Abstraction features==

===Programming languages===
{{Further|Programming language}}

Different programming languages provide different types of abstraction, depending on the intended applications for the language. For example:

* In [[object-oriented programming]] languages such as [[C++]], [[Object Pascal]], or [[Java (programming language)|Java]], the concept of ''abstraction'' has become a declarative statement – using the [[Syntax (programming languages)|syntax]] <code>''function''(''parameters'') = 0;</code> (in [[C++]]) or the [[reserved word]]s (keywords) ''<code>abstract</code>''<ref name="Oracle Java abstract">{{cite web |url=http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html |title=Abstract Methods and Classes|website=The Java Tutorials |publisher=Oracle |access-date=4 September 2014}}</ref> and ''<code>interface</code>''<ref name="Oracle Java interface">{{cite web |url=http://docs.oracle.com/javase/tutorial/java/IandI/interfaceAsType.html |title=Using an Interface as a Type|website=The Java Tutorials |publisher=Oracle |access-date=4 September 2014}}</ref> (in [[Java (programming language)|Java]]). After such a declaration, it is the responsibility of the programmer to implement a [[Class (computer science)|class]] to instantiate the [[Object (computer science)|object]] of the declaration.
* [[Functional programming]] languages commonly exhibit abstractions related to functions, such as [[lambda abstraction]]s (making a term into a function of some variable) and [[higher-order function]]s (parameters are functions).<ref>{{FOLDOC|Abstraction}}</ref><!-- This has to be merged in the following sections. -->
* Modern members of the [[List of Lisp-family programming languages|Lisp programming language family]] such as [[Clojure]], [[Scheme (programming language)|Scheme]] and [[Common Lisp]] support [[Macro (computer science)#Syntactic macros|macro systems]] to allow syntactic abstraction. Other programming languages such as [[Scala (programming language)|Scala]] also have macros, or very similar [[metaprogramming]] features (for example, [[Haskell]] has [[Template Haskell]], [[OCaml]] has [[MetaOCaml]]). These can allow programs to omit [[boilerplate code]], abstract away tedious function call sequences, implement new [[control flow]] structures, and implement [[domain-specific language]]s (DSLs), which allow domain-specific concepts to be expressed in concise and elegant ways. All of these, when used correctly, improve both the programmer's efficiency and the clarity of [[source code]] by making the intended purpose more explicit. A consequence of syntactic abstraction is also that any Lisp dialect, and almost any programming language, can in principle, be implemented in any modern Lisp with significantly reduced (but still non-trivial in most cases) effort when compared to "more traditional" programming languages such as [[Python (programming language)|Python]], [[C (programming language)|C]] or [[Java (programming language)|Java]].

===Specification methods===
{{Further|Formal specification}}

Analysts have developed various methods to formally specify software systems. Some known methods include:

* Abstract-model based method (VDM, Z);
* Algebraic techniques (Larch, CLEAR, OBJ, ACT ONE, CASL);
* Process-based techniques (LOTOS, SDL, Estelle);
* Trace-based techniques (SPECIAL, TAM);
* Knowledge-based techniques (Refine, Gist).

===Specification languages===
{{Further|Specification language}}

Specification languages generally rely on abstractions of one kind or another, since specifications are typically defined earlier in a project, (and at a more abstract level) than an eventual implementation. The [[Unified Modeling Language]] (UML) specification language, for example, allows the definition of ''abstract'' classes, which in a waterfall project, remain abstract during the architecture and specification phase of the project.

==Control abstraction==
{{Further|Control flow}}

Programming languages offer control abstraction as one of the main purposes of their use. Computer machines understand operations at the very low level such as moving some bits from one location of the memory to another location and producing the sum of two sequences of bits. Programming languages allow this to be done in the higher level. For example, consider this statement written in a [[Pascal (programming language)|Pascal]]-like fashion:

:<code>a := (1 + 2) * 5</code>

To a human, this seems a fairly simple and obvious calculation (''"one plus two is three, times five is fifteen"''). However, the low-level steps necessary to carry out this evaluation, and return the value "15", and then assign that value to the variable "a", are actually quite subtle and complex. The values need to be converted to binary representation (often a much more complicated task than one would think) and the calculations decomposed (by the compiler or interpreter) into assembly instructions (again, which are much less intuitive to the programmer: operations such as shifting a binary register left, or adding the binary complement of the contents of one register to another, are simply not how humans think about the abstract arithmetical operations of addition or multiplication). Finally, assigning the resulting value of "15" to the variable labeled "a", so that "a" can be used later, involves additional 'behind-the-scenes' steps of looking up a variable's label and the resultant location in physical or virtual memory, storing the binary representation of "15" to that memory location, etc.

Without control abstraction, a programmer would need to specify ''all'' the register/binary-level steps each time they simply wanted to add or multiply a couple of numbers and assign the result to a variable. Such duplication of effort has two serious negative consequences:

# it forces the programmer to constantly repeat fairly common tasks every time a similar operation is needed
# it forces the programmer to program for the particular hardware and instruction set

===Structured programming===
{{Further|Structured programming}}

Structured programming involves the splitting of complex program tasks into smaller pieces with clear flow-control and interfaces between components, with a reduction of the complexity potential for side-effects.

In a simple program, this may aim to ensure that loops have single or obvious exit points and (where possible) to have single exit points from functions and procedures.

In a larger system, it may involve breaking down complex tasks into many different modules. Consider a system which handles payroll on ships and at shore offices:

* The uppermost level may feature a menu of typical end-user operations.
* Within that could be standalone executables or libraries for tasks such as signing on and off employees or printing checks.
* Within each of those standalone components there could be many different source files, each containing the program code to handle a part of the problem, with only selected interfaces available to other parts of the program. A sign on program could have source files for each data entry screen and the database interface (which may itself be a standalone third party library or a statically linked set of library routines).
*Either the database or the payroll application also has to initiate the process of exchanging data with between ship and shore, and that data transfer task will often contain many other components.

These layers produce the effect of isolating the implementation details of one component and its assorted internal methods from the others. Object-oriented programming embraces and extends this concept.

==Data abstraction==
{{Further|Abstract data type}}

Data abstraction enforces a clear separation between the ''abstract'' properties of a [[data type]] and the ''concrete'' details of its implementation. The abstract properties are those that are visible to client code that makes use of the data type—the ''interface'' to the data type—while the concrete implementation is kept entirely private, and indeed can change, for example to incorporate efficiency improvements over time. The idea is that such changes are not supposed to have any impact on client code, since they involve no difference in the abstract behaviour.

For example, one could define an [[abstract data type]] called ''lookup table'' which uniquely associates ''keys'' with ''values'', and in which values may be retrieved by specifying their corresponding keys. Such a lookup table may be implemented in various ways: as a [[hash table]], a [[binary search tree]], or even a simple linear [[List (computing)|list]] of (key:value) pairs. As far as client code is concerned, the abstract properties of the type are the same in each case.

Of course, this all relies on getting the details of the interface right in the first place, since any changes there can have major impacts on client code. As one way to look at this: the interface forms a ''contract'' on agreed behaviour between the data type and client code; anything not spelled out in the contract is subject to change without notice.

== Manual data abstraction ==
While much of data abstraction occurs through computer science and automation, there are times when this process is done manually and without programming intervention. One way this can be understood is through data abstraction within the process of conducting a [[systematic review]] of the literature. In this methodology, data is abstracted by one or several abstractors when conducting a [[meta-analysis]], with errors reduced through dual data abstraction followed by independent checking, known as [[adjudication]].<ref>{{Cite journal |last1=E |first1=Jian-Yu |last2=Saldanha |first2=Ian J. |last3=Canner |first3=Joseph |last4=Schmid |first4=Christopher H. |last5=Le |first5=Jimmy T. |last6=Li |first6=Tianjing |date=2020 |title=Adjudication rather than experience of data abstraction matters more in reducing errors in abstracting data in systematic reviews |journal=Research Synthesis Methods |language=en |volume=11 |issue=3 |pages=354–362 |doi=10.1002/jrsm.1396 |pmid=31955502 |s2cid=210829764 |issn=1759-2879}}</ref>

==Abstraction in object-oriented programming==
{{Further|Object (computer science)}}

In [[object-oriented programming]] theory, ''abstraction'' involves the facility to define objects that represent abstract "actors" that can perform work, report on and change their state, and "communicate" with other objects in the system. The term [[Encapsulation (object-oriented programming)|encapsulation]] refers to the hiding of [[state (computer science)|state]] details, but extending the concept of ''data type'' from earlier programming languages to associate ''behavior'' most strongly with the data, and standardizing the way that different data types interact, is the beginning of ''abstraction''. When abstraction proceeds into the operations defined, enabling objects of different types to be substituted, it is called [[Polymorphism (computer science)|polymorphism]]. When it proceeds in the opposite direction, inside the types or classes, structuring them to simplify a complex set of relationships, it is called [[Delegation (object-oriented programming)|delegation]] or [[Inheritance (object-oriented programming)|inheritance]].

Various object-oriented programming languages offer similar facilities for abstraction, all to support a general strategy of [[Polymorphism (computer science)|polymorphism]] in object-oriented programming, which includes the substitution of one [[data type]] for another in the same or similar role. Although not as generally supported, a [[Computer configuration|configuration]] or image or package may predetermine a great many of these [[name binding|bindings]] at [[compile time]], [[Linker (computing)|link time]], or [[Loader (computing)|load time]]. This would leave only a minimum of such bindings to change at [[Run time (program lifecycle phase)|run-time]].

[[Common Lisp Object System]] or [[Self (programming language)|Self]], for example, feature less of a class-instance distinction and more use of delegation for [[Polymorphism (computer science)|polymorphism]]. Individual objects and functions are abstracted more flexibly to better fit with a shared functional heritage from [[Lisp (programming language)|Lisp]].

C++ exemplifies another extreme: it relies heavily on [[generic programming|templates]] and [[method overloading|overloading]] and other static bindings at compile-time, which in turn has certain flexibility problems.

Although these examples offer alternate strategies for achieving the same abstraction, they do not fundamentally alter the need to support abstract nouns in code – all programming relies on an ability to abstract verbs as functions, nouns as data structures, and either as processes.

Consider for example a sample [[Java (programming language)|Java]] fragment to represent some common farm "animals" to a level of abstraction suitable to model simple aspects of their hunger and feeding. It defines an <code>Animal</code> class to represent both the state of the animal and its functions:

<syntaxhighlight lang="java">
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;
     }
}
</syntaxhighlight>
With the above definition, one could create objects of type {{samp|Animal}} and call their methods like this:

<syntaxhighlight lang="java">
thePig = new Animal();
theCow = new Animal();
if (thePig.isHungry()) {
    thePig.eat(tableScraps);
}
if (theCow.isHungry()) {
    theCow.eat(grass);
}
theCow.moveTo(theBarn);
</syntaxhighlight>
In the above example, the class ''<code>Animal</code>'' is an abstraction used in place of an actual animal, ''<code>LivingThing</code>'' is a further abstraction (in this case a generalisation) of ''<code>Animal</code>''.

If one requires a more differentiated hierarchy of animals – to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives – that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and MeatAnimal (pigs, steers) who would eat foods to give the best meat-quality.

Such an abstraction could remove the need for the application coder to specify the type of food, so they could concentrate instead on the feeding schedule. The two classes could be related using [[Inheritance (object-oriented programming)|inheritance]] or stand alone, and the programmer could define varying degrees of [[Polymorphism (computer science)|polymorphism]] between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.

===Object-oriented design===
{{Further|Object-oriented design}}

Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and [[domain analysis]]—actually determining the relevant relationships in the real world is the concern of [[object-oriented analysis and design|object-oriented analysis]] or [[legacy analysis]].

In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and it is called an abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.

==Considerations==
When discussing [[formal semantics of programming languages]], [[formal methods]] or [[abstract interpretation]], ''abstraction'' refers to the act of considering a less detailed, but safe, definition of the observed program behaviors. For instance, one may observe only the final result of program executions instead of considering all the intermediate steps of executions. Abstraction is defined to a ''concrete'' (more precise) model of execution.

Abstraction may be ''exact'' or ''faithful'' with respect to a property if one can answer a question about the property equally well on the concrete or abstract model. For instance, if one wishes to know what the result of the evaluation of a mathematical expression involving only integers +, -, ×, is worth [[modular arithmetic|modulo]] ''n'', then one needs only perform all operations modulo ''n'' (a familiar form of this abstraction is [[casting out nines]]).

Abstractions, however, though not necessarily ''exact'', should be ''sound''. That is, it should be possible to get sound answers from them—even though the abstraction may simply yield a result of [[undecidable problem|undecidability]]. For instance, students in a class may be abstracted by their minimal and maximal ages; if one asks whether a certain person belongs to that class, one may simply compare that person's age with the minimal and maximal ages; if his age lies outside the range, one may safely answer that the person does not belong to the class; if it does not, one may only answer "I don't know".

The level of abstraction included in a programming language can influence its overall [[usability]]. The [[Cognitive dimensions]] framework includes the concept of ''abstraction gradient'' in a formalism. This framework allows the designer of a programming language to study the trade-offs between abstraction and other characteristics of the design, and how changes in abstraction influence the language usability.

Abstractions can prove useful when dealing with computer programs, because non-trivial properties of computer programs are essentially [[undecidable problem|undecidable]] (see [[Rice's theorem]]). As a consequence, automatic methods for deriving information on the behavior of computer programs either have to drop termination (on some occasions, they may fail, crash or never yield out a result), soundness (they may provide false information), or precision (they may answer "I don't know" to some questions).

Abstraction is the core concept of [[abstract interpretation]]. [[Model checking]] generally takes place on abstract versions of the studied systems.

==Levels of abstraction==
{{Further|Abstraction layer}}

Computer science commonly presents ''levels'' (or, less commonly, ''layers'') of abstraction, wherein each level represents a different model of the same information and processes, but with varying amounts of detail. Each level uses a system of expression involving a unique set of objects and compositions that apply only to a particular domain.
<ref>[[Luciano Floridi]], [http://www.cs.ox.ac.uk/activities/ieg/research_reports/ieg_rr221104.pdf ''Levellism and the Method of Abstraction'']
IEG – Research Report 22.11.04</ref>
Each relatively abstract, "higher" level builds on a relatively concrete, "lower" level, which tends to provide an increasingly "granular" representation. For example, gates build on electronic circuits, binary on gates, machine language on binary, programming language on machine language, applications and operating systems on programming languages. Each level is embodied, but not determined, by the level beneath it, making it a language of description that is somewhat self-contained.

===Database systems===
{{Further|Database management system}}

Since many users of database systems lack in-depth familiarity with computer data-structures, database developers often hide complexity through the following levels:

[[Image:Data abstraction levels.png|thumb|Data abstraction levels of a database system]]

''Physical level'' – The lowest level of abstraction describes ''how'' a system actually stores data. The physical level describes complex low-level data structures in detail.

''Logical level'' – The next higher level of abstraction describes ''what'' data the database stores, and what relationships exist among those data. The logical level thus describes an entire database in terms of a small number of relatively simple structures. Although implementation of the simple structures at the logical level may involve complex physical level structures, the user of the logical level does not need to be aware of this complexity. This is referred to as [[physical data independence]]. [[Database administrator]]s, who must decide what information to keep in a database, use the logical level of abstraction.

''View level'' – The highest level of abstraction describes only part of the entire database. Even though the logical level uses simpler structures, complexity remains because of the variety of information stored in a large database. Many users of a database system do not need all this information; instead, they need to access only a part of the database. The view level of abstraction exists to simplify their interaction with the system. The system may provide many [[view (database)|view]]s for the same database.

===Layered architecture===
{{Further|Abstraction layer}}
The ability to provide a [[design]] of different levels of abstraction can

* simplify the design considerably
* enable different role players to effectively work at various levels of abstraction
* support the portability of [[software artifact]]s (model-based ideally)

[[Systems design]] and [[Business process modeling|business process design]] can both use this. Some [[Software modeling|design processes]] specifically generate designs that contain various levels of abstraction.

Layered architecture partitions the concerns of the application into stacked groups (layers).
It is a technique used in designing computer software, hardware, and communications in which system or network components are isolated in layers so that changes can be made in one layer without affecting the others.

==See also==
* [[Abstraction principle (computer programming)]]
* [[Abstraction inversion]] for an anti-pattern of one danger in abstraction
* [[Abstract data type]] for an abstract description of a set of data
* [[Algorithm]] for an abstract description of a computational procedure
* [[Data modeling]] for structuring data independent of the processes that use it
* [[Decomposition (computer science)]]
* [[Encapsulation (object-oriented programming)|Encapsulation]] for abstractions that hide implementation details
* [[Greenspun's Tenth Rule]] for an aphorism about an (the?) optimum point in the space of abstractions
* [[Higher-order function]] for abstraction where functions produce or consume other functions
* [[Lambda abstraction]] for making a term into a function of some variable
* [[List of abstractions (computer science)]]
* [[Program refinement|Refinement]] for the opposite of abstraction in computing
* [[Integer (computer science)]]
* [[Heuristic (computer science)]]

==References==
{{Reflist}}

==Further reading==
{{Refbegin}}
* {{cite book |last1=Abelson |first1=Harold |author1-link=Hal Abelson |last2=Sussman |first2=Gerald Jay |author2-link=Gerald Jay Sussman |last3=Sussman |first3=Julie |author3-link=Julie Sussman |date=25 July 1996 |title=Structure and Interpretation of Computer Programs |url=http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html |access-date=22 June 2012 |edition=2 |publisher=MIT Press |isbn=978-0-262-01153-2 |url-status=dead |archive-url=https://web.archive.org/web/20090226050622/http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html |archive-date=26 February 2009}}
* {{cite web |last1=Spolsky |first1=Joel |author1-link=Joel Spolsky |date=11 November 2002 |title=The Law of Leaky Abstractions |url=http://www.joelonsoftware.com/articles/LeakyAbstractions.html |work=Joel on Software}}
* [https://www.cs.cornell.edu/courses/cs211/2006sp/Lectures/L08-abstraction/08_abstraction.html Abstraction/information hiding] – CS211 course, Cornell University.
* {{cite book |last1=Roberts |first1=Eric S. |date=1997 |title=Programming Abstractions in C A Second Course in Computer Science}}
* {{cite web |last1=Palermo |first1=Jeffrey |date=29 July 2008 |title=The Onion Architecture |url=http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ |work=Jeffrey Palermo}} 
*{{Cite journal
| last1=Vishkin |first1=Uzi
| date=January 2011 
| journal=Communications of the ACM
| volume=54
| issue=1
| title=Using simple abstraction to reinvent computing for parallelism
| pages=75–85
| doi=10.1145/1866739.1866757
| doi-access=free
}}
{{Refend}}

==External links==
* [https://sites.google.com/site/simulationarchitecture/ SimArch] example of layered architecture for distributed simulation systems.
{{Software engineering}}

{{DEFAULTSORT:Abstraction (computer science)}}
[[Category:Data management]]
[[Category:Abstraction]]
[[Category:Software engineering]]
[[Category:Object-oriented programming]]
<!-- Hidden categories below -->
[[Category:Articles with example Java code]]
[[Category:Articles with example Pascal code]]