추상화(컴퓨터 과학)

Abstraction (computer science)

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

– John V. Guttag[1]

소프트웨어 엔지니어링 및 컴퓨터 과학에서 추상화는 다음과 같습니다.

  • 더 [3]중요한 세부 사항에 주의를 집중시키기 위해 물체 또는 시스템을 연구할 때 물리적, 공간적, 시간적 세부사항[2] 또는 속성을 제거하는 과정. 이는 본질적으로 일반화 과정과 유사하다.
  • 추상 개념의 창조는 추상화 과정의 결과로서 다양한 비표준 객체 또는 연구 시스템의[3] 공통 특징 또는 속성을 미러링하여 구현됩니다.

일반적으로 추상화는 컴퓨터 과학 및 소프트웨어 [4]개발의 기본 개념입니다.추상화 과정은 모델링이라고도 하며 이론과 [5]디자인의 개념과 밀접하게 관련되어 있습니다.모델은 또한 현실의 측면의 일반화에 따라 추상화의 유형으로 간주될 수 있습니다.

컴퓨터 공학에서의 추상화는 추상화를 [2]객체로서 구축하는 것에 공통적으로 초점을 맞추고 있기 때문에 수학에서의 추상화와 밀접하게 관련되어 있지만,[3] 예술과 같은 다른 분야에서 사용되는 추상화의 다른 개념과도 관련이 있다.

추상화란 다음과 같은 추상화 자체의 특징을 전달하거나 이용하는 실제 객체 및 시스템, 계산 시스템의 규칙 또는 프로그래밍 언어의 규칙을 나타낼 수도 있습니다.

근거

컴퓨팅은 대부분 구체적인 세계와는 독립적으로 작동합니다.하드웨어는 다른 [10]것과 교환 가능한 계산 모델을 구현합니다.이 소프트웨어는 한 번에 몇 가지 문제에 집중함으로써 인간이 거대한 시스템을 만들 수 있도록 아키텍처로 구성되어 있습니다.이러한 아키텍처는 특정 추상화 선택으로 구성됩니다.그린스푼의 제10규칙은 그러한 건축이 어떻게 불가피하고 복잡한지에 대한 격언이다.

컴퓨팅에서 추상화의 중심 형태는 언어 추상화입니다. 새로운 인공 언어는 시스템의 특정 측면을 표현하기 위해 개발됩니다.모델링 언어는 계획에 도움이 됩니다.컴퓨터 언어는 컴퓨터로 처리할 수 있습니다.이 추상화 프로세스의 예로는 기계어에서 어셈블리 언어 및 고급 언어로 프로그래밍 언어를 발전시키는 것이 있습니다.각 스테이지가 다음 스테이지의 디딤돌이 될 수 있습니다.언어 추상화는 스크립트 언어 및 도메인별 프로그래밍 언어 등에서 계속됩니다.

프로그래밍 언어 내에서, 일부 기능은 프로그래머가 새로운 추상화를 만들 수 있도록 합니다.여기에는 서브루틴, 모듈, 다형성 및 소프트웨어 컴포넌트가 포함됩니다.소프트웨어 설계 패턴이나 아키텍처 스타일 등 기타 추상적인 개념들은 번역자가 볼 수 없는 상태로 시스템 설계에서만 작동합니다.

어떤 추상화들은 프로그래머가 알아야 할 개념의 범위를 제한하려고 하는데, 그 기초가 되는 추상화들을 완전히 숨김으로써 말이다.소프트웨어 엔지니어이자 작가인 Joel Spolsky는 모든 추상화가 유출되고 있으며,[11] 이는 결코 아래 세부사항을 완전히 숨길 수 없다고 주장하면서 이러한 노력을 비판했습니다. 그러나 이것이 추상화의 유용성을 부정하지는 않습니다.

일부 추상화는 다른 추상화와 상호 운용하도록 설계되어 있습니다.예를 들어 프로그래밍 언어에는 하위 수준의 언어로 호출하기 위한 외부 함수 인터페이스가 포함되어 있을 수 있습니다.

추상화 기능

프로그래밍 언어

주요 기사: 프로그래밍 언어

프로그래밍 언어에 따라 언어의 용도에 따라 추상화 유형이 달라집니다.예를 들어 다음과 같습니다.

  • C++, Object Pascal, Java와 같은 객체 지향 프로그래밍 언어에서는 추상화 개념 자체가 선언적인 스테이트먼트가 되었습니다.구문을 사용합니다. function(parameters) = 0; (C++) 또는 키워드abstract[12] 및 (Java)를 지정합니다.이러한 선언 후에 선언의 대상을 인스턴스화하는 클래스를 구현하는 것은 프로그래머의 책임이다.
  • 함수 프로그래밍 언어는 일반적으로 람다 추상화(항이 일부 변수의 함수로 만들어짐) 및 고차 함수(파라미터는 함수)와 같은 함수와 관련된 추상화를 나타냅니다.
  • Clojure, Scheme 및 Common Lisp와 같은 Lisp 프로그래밍 언어 패밀리의 최신 구성원은 구문 추상화를 허용하는 매크로 시스템을 지원합니다.Scala와 같은 다른 프로그래밍 언어에도 매크로 또는 매우 유사한 메타프로그래밍 기능이 있습니다(예를 들어 Haskell에는 Template Haskell, OCaml에는 MetaOCaml).이를 통해 프로그래머는 보일러 플레이트코드를 삭제하고 지루한 함수 호출시퀀스를 추상화하고 새로운 제어 플로우 구조를 구현하며 도메인 고유의 개념을 간결하고 우아한 방법으로 표현할 수 있습니다.Specific Languages(DSL; 도메인 고유 언어)를 구현할 수 있습니다.이 모든 것을 올바르게 사용했을 경우, 목적의 명확화를 도모함으로써 프로그래머의 효율성과 코드의 명확성을 향상시킬 수 있습니다.구문 추상화의 결과로서 파이썬, C, 자바와 같은 "전통적인" 프로그래밍 언어에 비해 리스프 방언과 거의 모든 프로그래밍 언어가 원칙적으로 상당히 적은 노력으로 구현될 수 있습니다(그러나 경우에 따라서는 여전히 단순하지 않습니다).

사양 방식

주요 기사:형식 사양

분석가들은 소프트웨어 시스템을 공식적으로 지정하는 다양한 방법을 개발했습니다.알려진 방법에는 다음과 같은 것이 있습니다.

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

사양 언어

주요 기사:사양 언어

사양은 일반적으로 프로젝트에서 최종 구현보다 초기에(그리고 더 추상적인 수준에서) 정의되기 때문에 사양 언어는 일반적으로 여러 종류의 추상화에 의존합니다.예를 들어 UML 사양 언어를 사용하면 워터폴 프로젝트에서 프로젝트의 아키텍처 및 사양 단계 동안 추상적인 상태로 유지되는 추상 클래스를 정의할 수 있습니다.

추상화 제어

주요 기사:흐름 제어

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

a := (1 + 2) * 5

인간에게는, 이것은 꽤 간단하고 명백한 계산으로 보인다.그러나 이 평가를 수행하고 값 "15"를 반환한 다음 변수 "a"에 해당 값을 할당하는 데 필요한 낮은 수준의 단계는 실제로 매우 미묘하고 복잡하다.값은 바이너리 표현(종종 생각보다 훨씬 복잡한 작업)으로 변환되어야 하며 계산은 (컴파일러나 인터프리터에 의해) 어셈블리 명령으로 분해되어야 합니다(이 명령어는 프로그래머에게 훨씬 덜 직관적입니다). 바이너리 레지스터를 왼쪽으로 이동하거나 바이너리 보완을 추가하는 것과 같은 연산입니다.f 한 레지스터의 다른 레지스터에 대한 내용은 단순히 덧셈 또는 곱셈의 추상적인 산술 연산에 대해 인간이 생각하는 방식이 아니다.)마지막으로 "a"라는 라벨이 붙은 변수에 "15"라는 결과값을 할당하면 나중에 "a"를 사용할 수 있게 됩니다.이는 변수의 라벨과 물리 메모리 또는 가상 메모리 내의 결과 위치를 조회하는 추가적인 "뒷면" 단계를 수반하며, "15"의 이진 표현을 해당 메모리 위치에 저장하는 등입니다.

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

  1. 그것은 프로그래머가 비슷한 연산이 필요할 때마다 꽤 흔한 작업을 끊임없이 반복하도록 강요한다.
  2. 프로그래머가 특정 하드웨어와 명령 집합을 프로그래밍하도록 강제합니다.

구조화된 프로그래밍

주요 기사:구조화된 프로그래밍

구조화된 프로그래밍은 복잡한 프로그램 태스크를 명확한 흐름 제어와 구성요소 간의 인터페이스를 통해 더 작은 조각으로 분할하는 것을 포함하며, 부작용의 복잡성 잠재성을 감소시킨다.

단순한 프로그램에서는 루프가 단일 또는 명백한 출구점을 가지도록 하고 (가능한 경우) 기능 및 절차에서 단일 출구점을 가지도록 하는 것을 목표로 할 수 있습니다.

대규모 시스템에서는 복잡한 작업을 여러 모듈로 분할해야 할 수 있습니다.선박 및 해안 사무소에서 급여를 처리하는 시스템을 고려하십시오.

  • 최상위 레벨에는 일반적인 최종 사용자 조작 메뉴가 포함될 수 있습니다.
  • 여기에는 직원 로그온/오프 또는 수표 인쇄와 같은 작업을 위한 독립 실행형 실행 파일 또는 라이브러리가 포함될 수 있습니다.
  • 각 스탠드아론 컴포넌트에는 많은 소스 파일이 있을 수 있습니다.각 컴포넌트에는 문제의 일부를 처리하기 위한 프로그램 코드가 포함되어 있으며, 프로그램의 다른 부분에서는 선택된 인터페이스만 사용할 수 있습니다.사인온 프로그램에는 각 데이터 입력 화면 및 데이터베이스 인터페이스(독립형 서드파티 라이브러리 또는 정적으로 링크된 라이브러리 루틴 세트일 수 있음)의 소스 파일이 포함될 수 있습니다.
  • 데이터베이스 또는 급여 애플리케이션은 선박과 해안 간 데이터 교환 프로세스를 시작해야 하며, 데이터 전송 태스크에는 다른 많은 구성 요소가 포함되어 있는 경우가 많습니다.

이러한 계층은 한 구성요소 및 구성요소의 다양한 내부 방법의 구현 세부사항을 다른 요소로부터 분리하는 효과를 낳습니다.객체 지향 프로그래밍은 이 개념을 수용하고 확장합니다.

data 추상화

주요 기사: 추상 데이터 유형

데이터 추상화는 데이터 유형의 추상 속성과 구현의 구체적인 세부 정보를 명확하게 구분합니다.추상적인 속성은 데이터 유형(데이터 유형에 대한 인터페이스)을 사용하는 클라이언트 코드에 표시되는 속성이며, 구체적인 구현은 완전히 비공개로 유지되며, 시간이 지남에 따라 효율성 향상을 통합하기 위해 실제로 변경될 수 있습니다.이러한 변경은 추상적인 동작에 차이가 없기 때문에 클라이언트 코드에 영향을 미치지 않아야 한다는 것입니다.

예를 들어 키와 값을 일의로 관련짓는 룩업 테이블이라는 추상 데이터 유형을 정의하고 대응하는 키를 지정함으로써 값을 검색할 수 있습니다.이러한 룩업 테이블은 해시 테이블, 바이너리 검색 트리 또는 (key:value) 쌍의 단순한 선형 목록과 같은 다양한 방법으로 구현될 수 있습니다.클라이언트 코드에 관한 한, 타입의 추상적인 속성은 각 케이스에서 동일합니다.

물론 이 모든 것은 처음부터 인터페이스의 세부사항을 올바르게 파악하는 데 달려 있습니다.이러한 변경은 클라이언트코드에 큰 영향을 미칠 수 있기 때문입니다.이를 보면 인터페이스는 데이터 유형과 클라이언트 코드 간에 합의된 동작에 따라 계약을 형성합니다.계약에 명기되어 있지 않은 것은 예고 없이 변경될 수 있습니다.

수동 데이터 추상화

대부분의 데이터 추상화는 컴퓨터 과학 및 자동화를 통해 이루어지지만, 이 프로세스는 프로그래밍 개입 없이 수동으로 수행될 수 있습니다.이를 이해할 수 있는 한 가지 방법은 문헌을 체계적으로 검토하는 과정에서 데이터를 추상화하는 것이다.이 방법론에서 데이터는 메타 분석을 수행할 때 하나 이상의 추상화자에 의해 추상화되며, 이중 데이터 추상화를 통해 오류를 줄이고,[14] 그 후 판단으로 알려진 독립적 검사를 통해 오류를 줄입니다.

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

주요 기사:오브젝트(컴퓨터 사이언스)

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

다양한 객체 지향 프로그래밍 언어는 추상화를 위한 유사한 기능을 제공하며, 모두 객체 지향 프로그래밍에서 다형성의 일반적인 전략을 지원하기 위해 제공되며, 여기에는 동일하거나 유사한 역할의 다른 유형의 대체가 포함됩니다.일반적으로는 지원되지 않지만 구성, 이미지 또는 패키지에 의해 컴파일 시간, 링크 시간 또는 로드 시간에 이러한 바인딩의 대부분이 미리 결정될 수 있습니다.이로 인해 런타임에 변경되는 바인딩은 최소한만 남게 됩니다.

예를 들어 일반적인 Lisp 오브젝트 시스템 또는 Self는 클래스 인스턴스 구분이 적고 다형성에 위임을 더 많이 사용하는 특징이 있습니다.개별 객체 및 기능은 Lisp의 공유된 기능 유산에 더 잘 적합하도록 더욱 유연하게 추상화됩니다.

C++는 또 다른 극단적인 예로서 컴파일 시 템플릿, 오버로드 및 기타 정적 바인딩에 크게 의존하며, 이는 다시 특정 유연성 문제를 일으킵니다.

이러한 예는 동일한 추상화를 달성하기 위한 대체 전략을 제공하지만, 코드에서 추상 명사를 지원할 필요성을 근본적으로 바꾸지는 않습니다. 모든 프로그래밍은 함수로서, 데이터 구조로서, 그리고 프로세스로서 명사를 추상화하는 능력에 의존합니다.

예를 들어 샘플 Java fragment를 몇 가지 일반적인 팜의 "동물"을 배고픔과 먹이의 단순한 측면을 모델링하기에 적합한 추상화 수준으로 표현해 보십시오.이 명령어는,Animal동물의 상태와 기능을 모두 나타내는 등급:

일반의 학급 동물 확장 리빙싱 {      사적인 위치 위치;      사적인 이중으로 하다 에너지 절약;       일반의 부울 굶주림() {          돌아가다 에너지 절약 < > 2.5;      }      일반의 무효 먹는다(음식. 음식.) {          //음식을 섭취하다          에너지 절약 += 음식..get Calories(칼로리)();      }      일반의 무효 이동처(위치 위치) {          // 새 위치로 이동          이것..위치 = 위치;      } }

위의 정의를 사용하면 다음과 같은 유형의 개체를 생성하여 메서드를 호출할 수 있습니다.

돼지 = 신규 동물(); 소 = 신규 동물(); 한다면 (돼지.굶주림()) {     돼지.먹는다(테이블 스크랩); } 한다면 (소.굶주림()) {     소.먹는다(잔디); } 소.이동처(바른);

위의 예에서 클래스는 실제 동물 대신 사용되는 추상화이며, 의 추가 추상화(이 경우 일반화)입니다.

만약 어떤 사람이 더 차별화된 동물 계층을 필요로 한다면 – 예를 들어, 그들의 삶의 마지막에 고기 외에는 아무것도 제공하지 않는 사람들과 구별하기 위해 – 그것은 아마도 좋은 우유를 주는 데 적합한 음식을 먹을 수 있는 중간 수준의 추상화이다.최고의 육질을 제공하는 음식에서요.

이러한 추상화를 통해 애플리케이션 코더가 식품의 종류를 지정할 필요가 없어지고, 대신 공급 일정에 집중할 수 있게 된다.두 클래스는 상속을 사용하여 관련될 수도 있고 독립적일 수도 있으며 프로그래머는 두 유형 간에 다양한 수준의 다형성을 정의할 수도 있습니다.이러한 기능은 언어에 따라 크게 달라지는 경향이 있지만, 일반적으로 각각의 기능은 다른 모든 언어에서 가능한 모든 것을 달성할 수 있습니다.데이터 유형별로 많은 작업 오버로드가 컴파일 시 상속이나 다형성을 달성하기 위한 다른 수단과 동일한 효과를 가져올 수 있습니다.클래스 표기법은 단순히 코더의 편리함입니다.

객체 지향 설계

주요 기사:객체 지향 설계

코더의 제어 하에 무엇을 추상화하고 무엇을 유지할 것인지에 대한 결정은 객체 지향 설계 및 도메인 분석의 주요 관심사가 됩니다.실제로는 객체 지향 분석 또는 레거시 분석의 관련 관계를 결정하는 것이 중요합니다.

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

고려 사항.

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

구체적인 모형이나 추상적 모형에서 자산에 대한 질문에 똑같이 잘 대답할 수 있다면, 추상화는 자산에 관해 정확하거나 충실할 수 있다.예를 들어 정수 +, -, ×만을 포함하는 수학식의 평가 결과가 모듈로n의 가치가 있는지 알고 싶다면 모든 연산 모듈로n(이 추상화의 친숙한 형태는 nines를 추출하는 것이다)만 수행하면 된다.

그러나 추상화는 반드시 정확한 것은 아니지만 건전해야 한다.즉, 추상화가 단순히 판별할 수 없는 결과를 낳는다고 해도, 그들에게서 건전한 답을 얻는 것이 가능해야 한다.예를 들어, 한 반의 학생들은 그들의 최소 나이와 최대 나이에 의해 추상화될 수 있다; 만약 어떤 사람이 그 반에 속하는지 묻는다면, 그 사람의 나이를 단지 최소 나이와 최대 나이와 비교할 수 있다; 만약 그의 나이가 그 반에 속하지 않는다면, 그 사람은 그 반에 속하지 않는다고 안전하게 대답할 수 있다.'모르겠다'고만 대답해요.

프로그래밍 언어에 포함된 추상화 수준은 전체적인 사용성에 영향을 미칠 수 있습니다.인지 차원 프레임워크는 형식주의의 추상화 구배 개념을 포함합니다.이 프레임워크를 통해 프로그래밍 언어 설계자는 추상화와 설계의 다른 특성 간의 균형과 추상화의 변화가 언어 사용성에 어떻게 영향을 미치는지 연구할 수 있다.

컴퓨터 프로그램의 사소한 특성은 본질적으로 결정할 수 없기 때문에 추상화는 컴퓨터 프로그램을 다룰 때 유용할 수 있다.그 결과, 컴퓨터 프로그램의 동작에 관한 정보를 도출하는 자동적인 방법은 종료(경우에 따라서는 실패, 크래시 또는 결과물이 나오지 않을 수 있음), 건전성(허위 정보를 제공할 수 있음), 또는 정밀도('모르겠다'고 대답할 수 있음) 중 하나를 폐기해야 한다.

추상화는 추상 해석의 핵심 개념이다.모델 확인은 일반적으로 연구된 시스템의 추상 버전에서 이루어집니다.

추상화 수준

주요 기사: 추상화 레이어

컴퓨터 과학은 일반적으로 추상화 수준(또는 덜 일반적으로 계층)을 제시하며, 각 수준은 동일한 정보와 프로세스의 다른 모델을 나타내지만 상세한 내용은 다양합니다.각 레벨은 특정 도메인에만 적용되는 고유한 개체 및 구성 집합을 포함하는 표현 체계를 사용합니다.[15] 각각의 비교적 추상적인 "높은" 수준은 상대적으로 구체적인 "낮은" 수준에 구축되며, 이는 점점 더 "입체적인" 표현을 제공하는 경향이 있습니다.예를 들어, 게이트는 전자 회로, 바이너리 온 게이트, 바이너리 온 게이트, 머신 언어, 머신 언어 프로그래밍 언어, 애플리케이션 및 프로그래밍 언어 운영 체제를 기반으로 구축됩니다.각 레벨은 그 아래의 레벨에 의해 구체화되지만 결정되지는 않습니다.따라서 어느 정도 자급자족적인 기술 언어가 됩니다.

데이터베이스 시스템

주요 기사: 데이터베이스 관리 시스템

데이터베이스 시스템의 많은 사용자는 컴퓨터 데이터 구조에 대한 깊은 지식이 없기 때문에 데이터베이스 개발자는 종종 다음과 같은 수준으로 복잡성을 숨깁니다.

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

물리 레벨:가장 낮은 추상화 수준은 시스템이 실제로 데이터를 저장하는 방법을 설명합니다.물리적 레벨은 복잡한 하위 레벨 데이터 구조를 자세히 설명합니다.

논리 레벨:다음으로 높은 수준의 추상화에서는 데이터베이스가 저장하는 데이터와 이러한 데이터 간에 어떤 관계가 존재하는지 설명합니다.따라서 논리 레벨은 비교적 단순한 소수의 구조로 전체 데이터베이스를 기술합니다.논리 레벨에서의 심플한 구조의 실장은 복잡한 물리 레벨의 구조를 수반하는 경우가 있습니다만, 논리 레벨의 유저는 이 복잡함을 의식할 필요는 없습니다.이를 물리적 데이터 독립이라고 합니다.데이터베이스에 보관할 정보를 결정해야 하는 데이터베이스 관리자는 논리적 추상화 수준을 사용합니다.

표시 수준:가장 높은 수준의 추상화는 전체 데이터베이스의 일부만 설명합니다.논리 수준에서는 단순한 구조를 사용하지만, 대규모 데이터베이스에 저장된 정보의 다양성 때문에 복잡성은 여전합니다.데이터베이스 시스템의 많은 사용자가 이 모든 정보를 필요로 하는 것은 아닙니다.대신 데이터베이스의 일부에만 액세스하면 됩니다.추상화 뷰 레벨은 시스템과의 상호작용을 단순화하기 위해 존재합니다.시스템은 동일한 데이터베이스에 대해 많은 보기를 제공할 수 있습니다.

계층형 아키텍처

주요 기사: 추상화 레이어

다양한 수준의 추상화 설계를 제공하는 기능은 다음과 같습니다.

  • 설계를 대폭 간소화하다
  • 다양한 역할 참가자들이 다양한 추상화 수준에서 효과적으로 작업할 수 있도록 한다.
  • 소프트웨어 아티팩트의 이식성 지원(모델 기반 이상적)

시스템 설계와 비즈니스 프로세스 설계 모두 이를 사용할 수 있습니다.일부 설계 프로세스에서는 특히 다양한 수준의 추상화를 포함하는 설계를 생성합니다.

계층형 아키텍처는 애플리케이션의 문제를 스택형 그룹(계층)으로 분할합니다.시스템 또는 네트워크 컴포넌트가 다른 계층에 영향을 주지 않고 한 계층에서 변경이 이루어질 수 있도록 계층으로 분리된 컴퓨터 소프트웨어, 하드웨어 및 통신을 설계할 때 사용되는 기술입니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Guttag, John V. (18 January 2013). Introduction to Computation and Programming Using Python (Spring 2013 ed.). Cambridge, Massachusetts: The MIT Press. ISBN 9780262519632.
  2. ^ a b Colburn, Timothy; Shute, Gary (5 June 2007). "Abstraction in Computer Science". Minds and Machines. 17 (2): 169–184. doi:10.1007/s11023-007-9061-7. ISSN 0924-6495. S2CID 5927969.
  3. ^ a b c Kramer, Jeff (1 April 2007). "Is abstraction the key to computing?". Communications of the ACM. 50 (4): 36–42. doi:10.1145/1232743.1232745. ISSN 0001-0782. S2CID 12481509.
  4. ^ Ben-Ari, Mordechai (1 March 1998). "Constructivism in computer science education". ACM SIGCSE Bulletin. 30 (1): 257, 257–261. doi:10.1145/274790.274308. ISSN 0097-8418.
  5. ^ Comer, D. E.; Gries, David; Mulder, Michael C.; Tucker, Allen; Turner, A. Joe; Young, Paul R. /Denning (1 January 1989). "Computing as a discipline". Communications of the ACM. 32 (1): 9–23. doi:10.1145/63238.63239. ISSN 0001-0782. S2CID 723103.
  6. ^ Liskov, Barbara (1 May 1988). "Keynote address – data abstraction and hierarchy". ACM SIGPLAN Notices. ACM. 23: 17–34. doi:10.1145/62138.62141. ISBN 0897912667. S2CID 14219043.
  7. ^ Barendregt, Hendrik Pieter (1984). The lambda calculus : its syntax and semantics (Revised ed.). Amsterdam: North-Holland. ISBN 0444867481. OCLC 10559084.
  8. ^ Barendregt, Hendrik Pieter (2013). Lambda calculus with types. Dekkers, Wil., Statman, Richard., Alessi, Fabio., Association for Symbolic Logic. Cambridge, UK: Cambridge University Press. ISBN 9780521766142. OCLC 852197712.
  9. ^ Newell, Allen; Simon, Herbert A. (1 January 2007). Computer science as empirical inquiry: symbols and search. ACM. p. 1975. doi:10.1145/1283920.1283930. ISBN 9781450310499.
  10. ^ Floridi, Luciano (September 2008). "The Method of Levels of Abstraction". Minds and Machines. 18 (3): 303–329. doi:10.1007/s11023-008-9113-7. ISSN 0924-6495.
  11. ^ Spolsky, Joel. "The Law of Leaky Abstractions".
  12. ^ "Abstract Methods and Classes". The Java™ Tutorials. Oracle. Retrieved 4 September 2014.
  13. ^ "Using an Interface as a Type". The Java™ Tutorials. Oracle. Retrieved 4 September 2014.
  14. ^ 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 (3): 354–362. doi:10.1002/jrsm.1396. ISSN 1759-2879. PMID 31955502.
  15. ^ Luciano Floridi, Levellism and the Method of Abstraction IEG – 연구 보고서 22.11.04

추가 정보

외부 링크

  • 분산 시뮬레이션 시스템을 위한 계층형 아키텍처의 SimArch 예.