본문으로 이동

추상화 (컴퓨터 과학)

위키백과, 우리 모두의 백과사전.

소프트웨어에서 추상화(abstraction)는 접근을 어렵게 만들 수 있는 세부 사항을 숨기면서도 접근 권한을 제공하는 것을 말한다.[1] 이는 더 중요한 세부 사항에 주의를 집중시킨다.[2][3] 예시로는 데이터의 표현과 사용을 분리하는 추상 자료형[4]이나, 기부(base)는 일반적이고 잎(leaves)으로 갈수록 구체화되는 호출 트리를 형성하는 함수 등이 있다.

근거

[편집]

추상화의 본질은 주어진 맥락에서 관련 있는 정보는 보존하고, 관련 없는 정보는 잊어버리는 것이다.

컴퓨팅은 대부분 구체적인 세계와 독립적으로 작동한다. 하드웨어는 다른 것과 교체 가능한 계산 모델을 구현한다.[6] 소프트웨어는 인간이 한 번에 몇 가지 문제에 집중하여 거대한 시스템을 만들 수 있도록 구조화된다. 이러한 아키텍처는 추상화에 대한 구체적인 선택들로 만들어진다. 그린스펀의 열번째 법칙은 이러한 아키텍처가 왜 필연적이며 복잡한지에 대한 명언이다.

언어 추상화는 컴퓨팅에서 추상화의 핵심적인 형태이다. 시스템의 특정 측면을 표현하기 위해 새로운 인공 언어가 개발된다. 모델링 언어는 계획을 세우는 데 도움을 준다. 컴퓨터 언어는 컴퓨터로 처리될 수 있다. 이러한 추상화 과정의 예는 기계어(1세대 프로그래밍 언어)에서 어셈블리어(2세대 프로그래밍 언어), 그리고 고급 프로그래밍 언어(3세대 프로그래밍 언어)로 이어지는 프로그래밍 언어의 세대별 발전이다. 각 단계는 다음 단계를 위한 디딤돌로 사용될 수 있다. 언어 추상화는 스크립트 언어와 도메인 특화 언어 등에서도 계속된다.

프로그래밍 언어 내에서 일부 기능은 프로그래머가 새로운 추상화를 만들 수 있게 해준다. 여기에는 서브루틴, 모듈, 다형성, 그리고 소프트웨어 컴포넌트가 포함된다. 소프트웨어 디자인 패턴이나 아키텍처 스타일과 같은 다른 추상화들은 트랜슬레이터에게는 보이지 않으며 오직 시스템 설계 단계에서만 작동한다.

일부 추상화는 프로그래머가 알아야 할 개념의 범위를 제한하기 위해, 그것들이 구축된 기반 추상화를 완전히 숨기려고 시도한다. 소프트웨어 엔지니어이자 작가인 조엘 스포스키는 모든 추상화에는 구멍이 있으며(누수된 추상화), 아래의 세부 사항을 결코 완전히 숨길 수 없다고 주장하며 이러한 노력을 비판했다.[7] 그러나 이것이 추상화의 유용성을 부정하는 것은 아니다.

일부 추상화는 다른 추상화와 상호 운용되도록 설계된다. 예를 들어, 프로그래밍 언어는 하위 수준 언어를 호출하기 위해 외부 함수 인터페이스를 포함할 수 있다.

추상화 기능

[편집]

프로그래밍 언어

[편집]

서로 다른 프로그래밍 언어는 언어의 용도에 따라 서로 다른 유형의 추상화를 제공한다. 예를 들면 다음과 같다.

정형 명세 방법

[편집]

분석가들은 소프트웨어 시스템을 정형적으로 명세하기 위해 다양한 방법을 개발했다. 알려진 방법은 다음과 같다.

  • 추상 모델 기반 방법 (VDM, Z)
  • 대수적 기법 (Larch, CLEAR, OBJ, ACT ONE, CASL)
  • 프로세스 기반 기법 (LOTOS, SDL, Estelle)
  • 트레이스 기반 기법 (SPECIAL, TAM)
  • 지식 기반 기법 (Refine, Gist)

명세 언어

[편집]

명세 언어는 일반적으로 어떤 종류든 추상화에 의존한다. 명세는 일반적으로 최종 구현보다 프로젝트의 더 이른 단계에서(그리고 더 추상적인 수준에서) 정의되기 때문이다. 예를 들어 통합 모델링 언어(UML) 명세 언어는 추상 클래스의 정의를 허용하며, 폭포수 프로젝트에서 이러한 클래스는 프로젝트의 아키텍처 및 명세 단계 동안 추상적인 상태로 유지된다.

제어 추상화

[편집]

프로그래밍 언어는 사용의 주요 목적 중 하나로 제어 추상화를 제공한다. 컴퓨터 기계는 메모리의 한 위치에서 다른 위치로 비트를 이동시키거나 두 비트 시퀀스의 합을 구하는 것과 같은 매우 낮은 수준의 연산을 이해한다. 프로그래밍 언어는 이를 더 높은 수준에서 수행할 수 있게 해준다. 예를 들어, 파스칼 스타일로 작성된 다음 문장을 고려해 보자.

a := (1 + 2) * 5

인간에게 이것은 상당히 간단하고 명백한 계산("1 더하기 2는 3이고, 거기에 5를 곱하면 15")으로 보인다. 그러나 이 평가를 수행하고 "15"라는 값을 반환한 다음 그 값을 변수 "a"에 할당하는 데 필요한 저수준 단계는 실제로는 상당히 미묘하고 복잡하다. 값은 이진 표현으로 변환되어야 하며(종종 생각보다 훨씬 복잡한 작업임), 계산은 (컴파일러나 인터프리터에 의해) 어셈블리 명령어로 분해되어야 한다. 이진 레지스터를 왼쪽으로 시프트하거나 한 레지스터 내용의 이진 보수를 다른 레지스터에 더하는 것과 같은 연산은 인간이 덧셈이나 곱셈이라는 추상적인 산술 연산을 생각하는 방식이 아니다. 마지막으로, 결과값 "15"를 "a"라는 레이블이 붙은 변수에 할당하여 나중에 사용할 수 있도록 하는 과정에는 변수의 레이블과 물리적 또는 가상 메모리의 결과 위치를 조회하고, "15"의 이진 표현을 해당 메모리 위치에 저장하는 등의 추가적인 '막후' 단계가 포함된다.

제어 추상화가 없다면 프로그래머는 단순히 숫자 두 개를 더하거나 곱하고 결과를 변수에 할당하고 싶을 때마다 모든 레지스터/이진 수준의 단계를 지정해야 할 것이다. 이러한 노력의 중복은 두 가지 심각한 부정적 결과를 초래한다.

  1. 프로그래머가 유사한 작업이 필요할 때마다 상당히 일반적인 작업을 끊임없이 반복하게 만든다.
  2. 프로그래머가 특정 하드웨어 및 명령어 집합에 맞춰 프로그래밍하게 만든다.

구조적 프로그래밍

[편집]

구조적 프로그래밍은 복잡한 프로그램 작업을 명확한 흐름 제어 및 컴포넌트 간 인터페이스를 갖춘 작은 조각으로 나누어 부작용의 복잡성 가능성을 줄이는 것을 포함한다.

단순한 프로그램에서 이는 루프가 단일하거나 명확한 종료 지점을 갖도록 하고, (가능한 경우) 함수와 프로시저에서 단일 종료 지점을 갖도록 하는 것을 목표로 할 수 있다.

더 큰 시스템에서는 복잡한 작업을 여러 가지 모듈로 나누는 것을 포함할 수 있다. 선박과 육상 사무소의 급여를 처리하는 시스템을 고려해 보자.

  • 최상위 수준에는 일반적인 최종 사용자 작업 메뉴가 있을 수 있다.
  • 그 안에는 직원 등록 및 해지 또는 수표 인쇄와 같은 작업을 위한 독립 실행형 실행 파일이나 라이브러리가 있을 수 있다.
  • 각 독립 실행형 컴포넌트 안에는 문제의 일부를 처리하는 프로그램 코드를 포함하는 여러 소스 파일이 있을 수 있으며, 프로그램의 다른 부분에서는 선택된 인터페이스만 사용할 수 있다. 등록 프로그램에는 각 데이터 입력 화면과 데이터베이스 인터페이스(그 자체로 독립적인 제3자 라이브러리이거나 정적으로 링크된 라이브러리 루틴 세트일 수 있음)를 위한 소스 파일이 있을 수 있다.
  • 데이터베이스 또는 급여 애플리케이션은 또한 선박과 육상 간의 데이터 교환 프로세스를 시작해야 하며, 그 데이터 전송 작업은 종종 다른 많은 컴포넌트를 포함하게 된다.

이러한 레이어들은 한 컴포넌트의 구현 세부 사항과 내부 메서드들을 다른 컴포넌트로부터 격리하는 효과를 낸다. 객체 지향 프로그래밍은 이 개념을 수용하고 확장한다.

데이터 추상화

[편집]

데이터 추상화는 자료형의 추상적인 속성과 구현의 구체적인 세부 사항 사이를 명확하게 분리한다. 추상적인 속성은 자료형을 사용하는 클라이언트 코드에 보이는 것(자료형에 대한 인터페이스)이며, 구체적인 구현은 완전히 비공개로 유지된다. 구현은 효율성 향상 등을 위해 시간이 지남에 따라 변경될 수 있다. 이러한 변경은 추상적인 동작에 차이가 없으므로 클라이언트 코드에 아무런 영향을 미치지 않아야 한다.

예를 들어, 키와 값을 고유하게 연관시키고 해당 키를 지정하여 값을 찾을 수 있는 '조회 테이블'이라는 추상 자료형을 정의할 수 있다. 이러한 조회 테이블은 해시 테이블, 이진 탐색 트리, 또는 단순히 (키:값) 쌍의 선형 리스트 등 다양한 방식으로 구현될 수 있다. 클라이언트 코드 입장에서 자료형의 추상적 속성은 각 경우에 모두 동일하다.

물론 이 모든 것은 처음에 인터페이스의 세부 사항을 올바르게 설정하는 데 달려 있다. 인터페이스의 변경은 클라이언트 코드에 큰 영향을 미칠 수 있기 때문이다. 이를 바라보는 한 가지 방법은 인터페이스가 자료형과 클라이언트 코드 간의 합의된 동작에 대한 계약을 형성한다는 것이다. 계약에 명시되지 않은 것은 무엇이든 예고 없이 변경될 수 있다.

수동 데이터 추상화

[편집]

데이터 추상화의 상당 부분은 컴퓨터 과학과 자동화를 통해 이루어지지만, 이러한 과정이 프로그래밍의 개입 없이 수동으로 수행되는 경우도 있다. 문헌에 대한 체계적 고찰을 수행하는 과정에서의 데이터 추출(data abstraction)이 그 예이다. 이 방법론에서는 메타분석을 수행할 때 한 명 또는 여러 명의 추출자에 의해 데이터가 추출되며, 이중 데이터 추출 후 독립적 확인(adjudication)을 거쳐 오류를 줄인다.[11]

객체 지향 프로그래밍에서의 추상화

[편집]

객체 지향 프로그래밍 이론에서 추상화는 작업을 수행하고, 상태를 보고하거나 변경하며, 시스템의 다른 객체와 "통신"할 수 있는 추상적인 "행위자"를 나타내는 객체를 정의하는 기능을 포함한다. 캡슐화라는 용어는 상태 세부 사항을 숨기는 것을 의미하지만, 이전 프로그래밍 언어의 자료형 개념을 확장하여 데이터와 동작을 강력하게 결합하고 서로 다른 자료형이 상호 작용하는 방식을 표준화하는 것이 추상화의 시작이다. 추상화가 정의된 연산으로 진행되어 서로 다른 유형의 객체가 상호 대체될 수 있게 되면 이를 다형성이라고 한다. 그것이 유형이나 클래스 내부에서 반대 방향으로 진행되어 복잡한 관계를 단순화하도록 구조화되면 이를 위임 또는 상속이라고 한다.

다양한 객체 지향 프로그래밍 언어들은 동일하거나 유사한 역할에서 하나의 자료형을 다른 자료형으로 대체하는 것을 포함하여, 객체 지향 프로그래밍의 일반적인 다형성 전략을 지원하기 위해 유사한 추상화 기능을 제공한다. 일반적으로 지원되지는 않지만, 설정이나 이미지 또는 패키지는 컴파일 타임, 링크 타임 또는 로드 타임에 이러한 네임 바인딩의 상당 부분을 미리 결정할 수 있다. 이렇게 하면 런타임에 변경할 바인딩을 최소화할 수 있다.

예를 들어 커먼 리스프 오브젝트 시스템이나 셀프는 클래스-인스턴스 구분이 덜하며 다형성을 위해 위임을 더 많이 사용한다. 개별 객체와 함수는 리스프의 공유된 함수형 유산에 더 잘 맞도록 더 유연하게 추상화된다.

C++는 또 다른 극단을 보여준다. 컴파일 타임에 템플릿과 오버로딩 및 기타 정적 바인딩에 크게 의존하며, 이는 결과적으로 특정한 유연성 문제를 야기한다.

이러한 예시들이 동일한 추상화를 달성하기 위해 서로 다른 전략을 제공하더라도, 코드에서 추상 명사를 지원해야 할 필요성 자체를 근본적으로 바꾸지는 않는다. 모든 프로그래밍은 동사를 함수로, 명사를 데이터 구조로, 그리고 둘 중 하나를 프로세스로 추상화하는 능력에 의존한다.

예를 들어 배고픔과 먹이 공급의 단순한 측면을 모델링하기에 적합한 추상화 수준에서 일반적인 농장 "동물"을 나타내는 자바 코드 조각을 고려해 보자. 동물의 상태와 기능을 모두 나타내기 위해 Animal 클래스를 정의한다.

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

     public boolean isHungry() {
         return energyReserves < 2.5;
     }
     public void eat(Food food) {
         // 먹이 섭취
         energyReserves += food.getCalories();
     }
     public void moveTo(Location location) {
         // 새로운 위치로 이동
         this.loc = location;
     }
}

위의 정의를 사용하면 Animal 유형의 객체를 생성하고 다음과 같이 메서드를 호출할 수 있다.

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

위의 예에서 Animal 클래스는 실제 동물을 대신하여 사용된 추상화이며, LivingThing은 Animal을 더 추상화(이 경우 일반화)한 것이다.

만약 더 차별화된 동물 계층 구조가 필요하다면(예를 들어 우유를 제공하는 동물과 고기만 제공하는 동물을 구분해야 한다면), 그것은 중간 수준의 추상화가 된다. 아마도 좋은 우유를 내기에 적합한 음식을 먹는 DairyAnimal(소, 염소)과 최상의 고기 품질을 내기 위한 음식을 먹는 MeatAnimal(돼지, 거세우)이 될 것이다.

이러한 추상화는 애플리케이션 코더가 음식의 종류를 지정해야 할 필요성을 없애주어, 대신 급여 일정에 집중할 수 있게 해준다. 두 클래스는 상속을 사용하여 연결되거나 독립적일 수 있으며, 프로그래머는 두 유형 사이에 다양한 정도의 다형성을 정의할 수 있다. 이러한 기능은 언어마다 크게 다른 경향이 있지만, 일반적으로 각각은 다른 언어로 가능한 모든 것을 달성할 수 있다. 자료형별 수많은 연산 오버로드는 컴파일 타임에 다형성을 달성하기 위한 상속이나 다른 수단과 동일한 효과를 낼 수 있다. 클래스 표기법은 단순히 코더의 편의를 위한 것이다.

객체 지향 설계

[편집]

무엇을 추상화하고 무엇을 코더의 제어 하에 둘 것인지에 대한 결정은 객체 지향 설계와 도메인 분석의 주요 관심사가 된다. 실제 세계의 관련 관계를 실제로 결정하는 것은 객체 지향 분석 또는 레거시 분석의 영역이다.

일반적으로 적절한 추상화를 결정하려면 범위에 대한 많은 작은 결정(도메인 분석)을 내려야 하고, 협력해야 할 다른 시스템을 결정(레거시 분석)한 다음, 프로젝트 시간과 예산 제약 내에서 객체 지향 설계로 표현되는 상세한 객체 지향 분석을 수행해야 한다. 우리의 단순한 예에서 도메인은 농장 마당이고, 살아있는 돼지와 소 및 그들의 식습관은 레거시 제약 조건이며, 상세 분석은 코더가 이용 가능한 먹이를 동물에게 줄 수 있는 유연성을 가져야 하므로 클래스 자체에 먹이 유형을 코딩할 이유가 없다는 것이고, 설계는 돼지와 소가 동일한 기능을 가진 인스턴스인 하나의 단순한 Animal 클래스가 된다. DairyAnimal을 차별화하기로 한 결정은 상세 분석을 바꾸겠지만 도메인 및 레거시 분석은 바뀌지 않을 것이다. 따라서 이는 전적으로 프로그래머의 제어 하에 있으며, 도메인이나 레거시 분석에서의 추상화와 구별되는 객체 지향 프로그래밍에서의 추상화라고 불린다.

고려 사항

[편집]

프로그래밍 언어의 정형 의미론, 정형 기법 또는 추상 해석을 논의할 때, 추상화는 관찰된 프로그램 동작에 대해 덜 상세하지만 안전한 정의를 고려하는 행위를 의미한다. 예를 들어, 실행의 모든 중간 단계를 고려하는 대신 프로그램 실행의 최종 결과만을 관찰할 수 있다. 추상화는 실행의 구체적(더 정밀한) 모델에 대해 정의된다.

구체적 모델이나 추상적 모델에서 속성에 대한 질문에 똑같이 잘 대답할 수 있다면, 추상화는 그 속성에 대해 정확하거나 충실할 수 있다. 예를 들어, 정수 +, -, ×만 포함된 수학식의 평가 결과가 모듈로 n으로 얼마인지 알고 싶다면, 모든 연산을 모듈로 n으로 수행하기만 하면 된다(이러한 추상화의 익숙한 형태는 구거법이다).

그러나 추상화가 반드시 정확할 필요는 없더라도 견실(sound)해야 한다. 즉, 추상화가 단순히 결정 불가능성이라는 결과를 낼지라도 그로부터 견실한 답을 얻을 수 있어야 한다. 예를 들어, 학급의 학생들을 최소 연령과 최대 연령으로 추상화할 수 있다. 어떤 사람이 그 학급에 속하는지 묻는다면 그 사람의 나이를 최소 및 최대 연령과 비교하면 된다. 나이가 범위 밖에 있다면 그 사람이 학급에 속하지 않는다고 안전하게 대답할 수 있다. 만약 범위 안에 있다면 "모름"이라고 대답할 수밖에 없다.

프로그래밍 언어에 포함된 추상화 수준은 전반적인 사용성에 영향을 줄 수 있다. 인지적 차원(Cognitive dimensions) 프레임워크는 형식주의에 추상화 경사(abstraction gradient)라는 개념을 포함한다. 이 프레임워크는 프로그래밍 언어 설계자가 추상화와 설계의 다른 특성 사이의 절충점을 연구하고, 추상화의 변화가 언어 사용성에 어떤 영향을 미치는지 연구할 수 있게 해준다.

추상화는 컴퓨터 프로그램을 다룰 때 유용할 수 있다. 컴퓨터 프로그램의 사소하지 않은 속성들은 본질적으로 결정 불가능하기 때문이다. 결과적으로 컴퓨터 프로그램의 동작에 대한 정보를 도출하는 자동화된 방법은 종료(어떤 경우에는 실패하거나 충돌하거나 결과를 내지 못할 수 있음), 견실성(틀린 정보를 제공할 수 있음), 또는 정밀도(일부 질문에 "모름"이라고 답할 수 있음) 중 하나를 포기해야 한다.

추상화는 추상 해석의 핵심 개념이다. 모델 검사는 일반적으로 연구 대상 시스템의 추상화된 버전에서 이루어진다.

추상화 계층

[편집]

컴퓨터 과학은 일반적으로 추상화의 수준(또는 드물게 레이어)을 제시하는데, 각 수준은 동일한 정보와 프로세스의 서로 다른 모델을 나타내지만 세부 사항의 정도가 다르다. 각 수준은 특정 도메인에만 적용되는 고유한 객체 및 구성 세트를 포함하는 표현 체계를 사용한다.[12] 상대적으로 추상적인 "상위" 수준은 상대적으로 구체적인 "하위" 수준을 기반으로 구축되며, 하위 수준으로 갈수록 점점 더 "미세한" 표현을 제공하는 경향이 있다. 예를 들어, 게이트는 전자 회로를 기반으로, 이진법은 게이트를 기반으로, 기계어는 이진법을 기반으로, 프로그래밍 언어는 기계어를 기반으로, 애플리케이션과 운영 체제는 프로그래밍 언어를 기반으로 구축된다. 각 수준은 그 아래 수준에 의해 구현되지만 그것에 의해 결정되지는 않으며, 어느 정도 자기 완비적인 설명 언어가 된다.

데이터베이스 시스템

[편집]

데이터베이스 시스템의 많은 사용자가 컴퓨터 데이터 구조에 대한 깊은 지식이 부족하기 때문에, 데이터베이스 개발자는 종종 다음과 같은 수준을 통해 복잡성을 숨긴다.

데이터베이스 시스템의 데이터 추상화 수준

물리적 수준(Physical level) – 가장 낮은 수준의 추상화로, 시스템이 실제로 데이터를 저장하는 방법을 설명한다. 물리적 수준은 복잡한 저수준 데이터 구조를 상세히 설명한다.

논리적 수준(Logical level) – 그다지 높지 않은 다음 수준의 추상화로, 데이터베이스가 어떤 데이터를 저장하는지, 그리고 그 데이터들 사이에 어떤 관계가 존재하는지를 설명한다. 따라서 논리적 수준은 비교적 간단한 구조의 적은 수로 전체 데이터베이스를 설명한다. 논리적 수준의 단순한 구조를 구현하는 데 복잡한 물리적 수준의 구조가 포함될 수 있지만, 논리적 수준의 사용자는 이러한 복잡성을 알 필요가 없다. 이를 물리적 데이터 독립성이라고 한다. 데이터베이스에 어떤 정보를 유지할지 결정해야 하는 데이터베이스 관리자는 이 논리적 수준의 추상화를 사용한다.

뷰 수준(View level) – 가장 높은 수준의 추상화로, 전체 데이터베이스의 일부만을 설명한다. 논리적 수준이 더 단순한 구조를 사용하더라도 대규모 데이터베이스에 저장된 다양한 정보 때문에 복잡성은 여전히 남는다. 데이터베이스 시스템의 많은 사용자는 이 모든 정보를 필요로 하지 않으며, 데이터베이스의 일부에만 접근하면 된다. 뷰 수준의 추상화는 시스템과의 상호 작용을 단순화하기 위해 존재한다. 시스템은 동일한 데이터베이스에 대해 많은 뷰를 제공할 수 있다.

계층화된 아키텍처

[편집]

서로 다른 추상화 수준의 디자인을 제공하는 능력은 다음과 같은 장점이 있다.

  • 설계를 상당히 단순화할 수 있음
  • 서로 다른 역할을 가진 사람들이 다양한 추상화 수준에서 효과적으로 작업할 수 있게 함
  • 소프트웨어 산출물의 이식성을 지원함(이상적으로 모델 기반)

시스템 설계와 비즈니스 프로세스 설계 모두 이를 사용할 수 있다. 일부 설계 프로세스는 구체적으로 다양한 추상화 수준을 포함하는 설계를 생성한다.

계층화된 아키텍처는 애플리케이션의 관심사를 쌓인 그룹(레이어)으로 분할한다. 이는 시스템 또는 네트워크 구성 요소를 계층으로 분리하여 한 계층의 변경이 다른 계층에 영향을 주지 않고 이루어질 수 있도록 하는 컴퓨터 소프트웨어, 하드웨어 및 통신 설계 기법이다.

같이 보기

[편집]

추가 문헌

[편집]

각주

[편집]
  1. ↑ Colburn, Timothy; Shute, Gary (2007년 6월 5일). 《Abstraction in Computer Science》 (영어). 《Minds and Machines》 17. 169–184쪽. doi:10.1007/s11023-007-9061-7. ISSN 0924-6495. S2CID 5927969.
  2. ↑ Kramer, Jeff (2007년 4월 1일). 《Is abstraction the key to computing?》. 《Communications of the ACM》 50. 36–42쪽. doi:10.1145/1232743.1232745. ISSN 0001-0782. S2CID 12481509.
  3. ↑ Ben-Ari, Mordechai (1998년 3월 1일). 《Constructivism in computer science education》. 《ACM SIGCSE Bulletin》 30. 257, 257–261쪽. doi:10.1145/274790.274308. ISSN 0097-8418.
  4. ↑ Liskov, Barbara (1988년 5월 1일). 〈Keynote address - data abstraction and hierarchy〉. 《Addendum to the proceedings on Object-oriented programming systems, languages and applications (Addendum) - OOPSLA '87》. 《ACM SIGPLAN Notices》 23 (ACM). 17–34쪽. doi:10.1145/62138.62141. ISBN 0897912667. S2CID 14219043.
  5. ↑ Guttag, John V. (2013년 1월 18일). 《Introduction to Computation and Programming Using Python》 Spring 2013판. Cambridge, Massachusetts: The MIT Press. ISBN 978-0262519632.
  6. ↑ Floridi, Luciano (September 2008). 《The Method of Levels of Abstraction》 (영어). 《Minds and Machines》 18. 303–329쪽. doi:10.1007/s11023-008-9113-7. hdl:2299/2998. ISSN 0924-6495. S2CID 7522925.
  7. ↑ Spolsky, Joel (2002년 11월 11일). “The Law of Leaky Abstractions”.
  8. ↑ “Abstract Methods and Classes”. 《The Java Tutorials》. Oracle. 2014년 9월 4일에 확인함.
  9. ↑ “Using an Interface as a Type”. 《The Java Tutorials》. Oracle. 2014년 9월 4일에 확인함.
  10. ↑
    이 문서에는 GFDL 라이선스로 배포된 자유 온라인 컴퓨팅 사전(FOLDOC)의 내용을 기초로 작성된 내용이 포함되어 있습니다.
  11. ↑ E, Jian-Yu; Saldanha, Ian J.; Canner, Joseph; Schmid, Christopher H.; Le, Jimmy T.; Li, Tianjing (2020). 《Adjudication rather than experience of data abstraction matters more in reducing errors in abstracting data in systematic reviews》 (영어). 《Research Synthesis Methods》 11. 354–362쪽. doi:10.1002/jrsm.1396. ISSN 1759-2879. PMID 31955502. S2CID 210829764.
  12. ↑ 루치아노 플로리디, Levellism and the Method of Abstraction IEG – Research Report 22.11.04
원본 주소 "https://ko.wikipedia.org/w/index.php?title=추상화_(컴퓨터_과학)&oldid=41726745"