抽象化（コンピュータ科学）

ソフトウェアにおいて、抽象化は、アクセスをより困難にする可能性のある詳細を隠蔽しながらアクセスを提供します。^{[ 1 ]}より重要な詳細に注意を集中させます。^{[ 2 ] [ 3 ]}例としては、使用とデータの表現を分離する抽象データ型^{[ 4 ]}や、基部ではより一般的で葉に向かうにつれてより具体的になる呼び出しツリーを形成する関数などがあります。

コンピューティングは、ほとんどの場合、具体的な世界とは独立して動作します。ハードウェアは、他のものと交換可能な計算モデルを実装します。^{[ 6 ]}ソフトウェアは、人間が一度に少数の問題に集中することで巨大なシステムを作成できるように、アーキテクチャで構造化されています。これらのアーキテクチャは、特定の抽象化の選択によって構成されています。グリーンスパンの第 10 のルールは、このようなアーキテクチャがいかに必然的かつ複雑であるかについての格言です。

言語の抽象化は、コンピューティングにおける抽象化の中心的な形態です。システムの特定の側面を表現するために、新しい人工言語が開発されます。モデリング言語は計画に役立ちます。コンピュータ言語はコンピュータで処理できます。この抽象化プロセスの例として、プログラミング言語の世代的な発展が挙げられます。第一世代プログラミング言語（機械語）から第二世代プログラミング言語（アセンブリ言語）、そして第三世代プログラミング言語（高級プログラミング言語）へと発展してきました。各段階は次の段階への足がかりとして利用できます。言語の抽象化は、例えばスクリプト言語やドメイン固有言語などでも継続されています。

プログラミング言語には、プログラマが新しい抽象概念を作成できる機能がいくつかあります。これには、サブルーチン、モジュール、ポリモーフィズム、ソフトウェアコンポーネントなどが含まれます。ソフトウェア設計パターンやアーキテクチャスタイルなどの他の抽象概念は、翻訳者には見えず、システムの設計においてのみ機能します。

抽象化の中には、プログラマーが認識する必要のある概念の範囲を制限しようとするものがあり、それは抽象化の基盤となる抽象化を完全に隠蔽することによって行われます。ソフトウェアエンジニアであり作家でもあるジョエル・スポルスキーは、すべての抽象化は漏れがあり、その下の詳細を完全に隠蔽することは決してできないと主張して、これらの取り組みを批判しています。 ^{[ 7 ]}しかし、これは抽象化の有用性を否定するものではありません。

一部の抽象化は、他の抽象化と相互運用するように設計されています。たとえば、プログラミング言語には、下位レベルの言語を呼び出すための外部関数インターフェースが含まれている場合があります。

プログラミング言語は、その主な目的の一つとして制御の抽象化を提供します。コンピュータは、メモリのある場所から別の場所にビットを移動したり、2つのビット列の合計を生成したりといった、非常に低レベルの操作を理解します。プログラミング言語は、これをより高レベルで実行できるようにします。例えば、Pascalのような形式で記述された次のステートメントを考えてみましょう。

a := (1 + 2) * 5

人間にとって、これはかなり単純で明白な計算（「1 + 2 は 3、5 倍は 15」）のように思えます。しかし、この評価を実行して値「15」を返し、その値を変数「a」に代入するために必要な低レベルの手順は、実際には非常に微妙で複雑です。値をバイナリ表現に変換する必要があり（これは多くの場合、想像以上に複雑な作業です）、計算は（コンパイラまたはインタプリタによって）アセンブリ命令に分解されます（これもプログラマにとってははるかに直感的ではありません。バイナリレジスタを左にシフトしたり、あるレジスタの内容のバイナリ補数を別のレジスタに加えたりといった操作は、人間が加算や乗算といった抽象的な算術演算について考える方法とは全く異なります）。最後に、結果として得られた値「15」を「a」というラベルの付いた変数に代入して、「a」を後で使用できるようにするには、変数のラベルと物理メモリまたは仮想メモリ内の結果の場所を検索し、「15」のバイナリ表現をそのメモリ位置に格納するなど、追加の「舞台裏」の手順が必要です。

制御抽象化がなければ、プログラマーは単に2つの数値を加算または乗算して結果を変数に代入したい場合でも、レジスタ/バイナリレベルのすべての手順を毎回指定する必要がある。このような作業の重複は、2つの深刻な悪影響をもたらす。

1. これにより、プログラマーは同様の操作が必要になるたびに、比較的よくあるタスクを繰り返し実行せざるを得なくなる。
2. これにより、プログラマーは特定のハードウェアと命令セットに合わせてプログラミングすることを強いられる。

データ抽象化は、データ型の抽象的な特性と、その実装の具体的な詳細との間に明確な分離をもたらします。抽象的な特性は、データ型を利用するクライアントコードから見えるものであり、データ型へのインターフェースにあたります。一方、具体的な実装は完全に非公開であり、例えば時間の経過に伴う効率改善のために変更される可能性があります。こうした変更は抽象的な動作に違いをもたらさないため、クライアントコードには影響を与えないというのが基本的な考え方です。

例えば、キーと値を一意に関連付けるルックアップテーブルと呼ばれる抽象データ型を定義することができます。このルックアップテーブルでは、対応するキーを指定することで値を取得できます。このようなルックアップテーブルは、ハッシュテーブル、二分探索木、あるいは（キー：値）ペアの単純な線形リストなど、さまざまな方法で実装できます。クライアントコードから見ると、いずれの場合も型の抽象プロパティは同じです。

もちろん、これはすべて、まずインターフェースの詳細を正しく定義することが前提となります。なぜなら、インターフェースの変更はクライアントコードに大きな影響を与える可能性があるからです。別の見方をすれば、インターフェースはデータ型とクライアントコード間の合意された動作に関する契約を形成するものであり、契約に明記されていない事項は予告なく変更される可能性があるということです。

データ抽象化の多くはコンピュータサイエンスと自動化によって行われますが、プログラミングの介入なしに手動でこのプロセスが行われる場合もあります。これを理解する一つの方法は、文献の系統的レビューを実施するプロセスにおけるデータ抽象化です。この方法論では、メタ分析を実施する際に、1人または複数のアブストラクターによってデータが抽象化され、二重のデータ抽象化とそれに続く独立したチェック（裁定として知られる）によってエラーが削減されます。^{[ 11 ]}

オブジェクト指向プログラミング理論において、抽象化とは、作業を実行したり、状態を報告・変更したり、システム内の他のオブジェクトと「通信」したりできる抽象的な「アクター」を表すオブジェクトを定義する機能を指します。カプセル化という用語は状態の詳細を隠すことを指しますが、以前のプログラミング言語からデータ型の概念を拡張して、振る舞いをデータに最も強く関連付け、異なるデータ型が相互作用する方法を標準化することが、抽象化の始まりです。抽象化が定義された操作にまで及び、異なる型のオブジェクトを置き換えることができるようになると、それはポリモーフィズムと呼ばれます。逆に、型やクラスの内部で、複雑な関係を単純化するために構造化される場合は、委譲または継承と呼ばれます。

オブジェクト指向プログラミング言語は、抽象化のための同様の機能を提供しており、いずれもオブジェクト指向プログラミングにおけるポリモーフィズムという一般的な戦略をサポートしています。ポリモーフィズムとは、同じまたは類似の役割を持つデータ型を別のデータ型に置き換えることを含みます。一般的にはサポートされていませんが、構成、イメージ、またはパッケージによって、コンパイル時、リンク時、またはロード時にこれらのバインディングの大部分が事前に決定される場合があります。これにより、実行時に変更する必要のあるバインディングは最小限に抑えられます。

例えば、 Common Lisp Object SystemやSelfでは、クラスとインスタンスの区別が少なく、ポリモーフィズムのために委譲がより多く用いられています。個々のオブジェクトや関数は、 Lispから受け継がれた共通の関数型プログラミングの伝統によく適合するように、より柔軟に抽象化されています。

C++はもう一つの極端な例を示している。コンパイル時にテンプレートやオーバーロード、その他の静的バインディングに大きく依存しているが、それが柔軟性の問題を引き起こしている。

これらの例は、同じ抽象化を実現するための代替戦略を示していますが、コード内で抽象名詞をサポートする必要性を根本的に変えるものではありません。すべてのプログラミングは、動詞を関数として、名詞をデータ構造として、そしてその両方をプロセスとして抽象化する能力に依存しているからです。

例えば、一般的な家畜を、その空腹や摂食といった単純な側面をモデル化するのに適した抽象度で表現するJavaの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 ; } }

上記の定義により、次のようなオブジェクトを作成できます。動物そして、彼らのメソッドを次のように呼びます。

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

上記の例では、クラスはAnimal実際の動物の代わりに使われる抽象化であり、LivingThingはのさらなる抽象化（この場合は一般化）ですAnimal。

もし、より細分化された動物の階層構造が必要な場合、例えば、牛乳を提供する動物と、生涯の終わりに肉以外何も提供しない動物を区別する場合、それは中間レベルの抽象化であり、おそらく良質な牛乳を出すのに適した餌を食べる乳用動物（牛、ヤギ）と、最高の肉質を得るのに適した餌を食べる肉用動物（豚、去勢牛）という区分になるでしょう。

このような抽象化によって、アプリケーション開発者は餌の種類を指定する必要がなくなり、給餌スケジュールに集中できるようになります。2 つのクラスは継承を使用して関連付けることも、独立して扱うこともでき、プログラマーは 2 つの型の間でさまざまなレベルの多態性を定義できます。これらの機能は言語によって大きく異なりますが、一般的には、どの言語でも他の言語で可能なことは何でも実現できます。データ型ごとに多数の操作オーバーロードを使用することで、コンパイル時に、継承やその他の多態性を実現する手段と同じ効果を得ることができます。クラス表記は、単にプログラマーの便宜のためのものです。

プログラミング言語の形式意味論、形式手法、または抽象解釈について議論する際、抽象化とは、観察されるプログラムの動作について、詳細度は低いものの安全な定義を考慮する行為を指します。例えば、実行の中間段階をすべて考慮する代わりに、プログラム実行の最終結果のみを観察することができます。抽象化は、より具体的な（より正確な）実行モデルに基づいて定義されます。

抽象化は、具体的なモデルと抽象的なモデルの両方で、その性質に関する質問に同じように答えることができる場合、その性質に関して正確または忠実であると言える。例えば、整数+、-、×のみを含む数式の評価結果がnを法としてどのような値になるかを知りたい場合、 nを法とするすべての演算を実行するだけでよい（この抽象化のよく知られた形式は、9を捨てることである）。

しかし、抽象化は必ずしも厳密である必要はないものの、健全であるべきである。つまり、抽象化の結果が単に決定不能となる場合であっても、そこから健全な答えが得られるべきである。例えば、クラスの生徒は、最小年齢と最大年齢によって抽象化できる。ある人がそのクラスに属しているかどうかを尋ねる場合、その人の年齢を最小年齢と最大年齢と比較すればよい。年齢がその範囲外であれば、その人はそのクラスに属していないと安全に答えることができる。そうでない場合は、「わからない」と答えるしかない。

プログラミング言語に含まれる抽象化のレベルは、その言語の全体的な使いやすさに影響を与える可能性があります。認知次元フレームワークは、抽象化勾配の概念を形式的に取り入れています。このフレームワークにより、プログラミング言語の設計者は、抽象化と設計の他の特性との間のトレードオフ、および抽象化の変化が言語の使いやすさにどのように影響するかを研究することができます。

コンピュータプログラムを扱う際には、抽象化が役立つことがあります。なぜなら、コンピュータプログラムの非自明な特性は本質的に決定不可能だからです（ライスの定理を参照）。その結果、コンピュータプログラムの動作に関する情報を自動的に取得する方法は、終了性（場合によっては失敗したり、クラッシュしたり、結果を出力しないこともあります）、健全性（誤った情報を提供する可能性があります）、または精度（一部の質問に対して「わかりません」と答える場合があります）のいずれかを犠牲にしなければなりません。

抽象化は抽象解釈の中核概念である。モデル検査は一般的に、研究対象システムの抽象化されたバージョンに対して行われる。

コンピュータ科学では、一般的に抽象化のレベル（またはあまり一般的ではないが、レイヤー）が提示され、各レベルは同じ情報とプロセスの異なるモデルを表しますが、詳細の度合いが異なります。各レベルは、特定のドメインにのみ適用される独自のオブジェクトと構成のセットを含む表現システムを使用します。^{[ 12 ]} 比較的抽象的な「高」レベルは、比較的具体的な「低」レベルの上に構築され、ますます「きめ細かい」表現を提供する傾向があります。たとえば、ゲートは電子回路の上に構築され、バイナリはゲートの上に構築され、機械語はバイナリの上に構築され、プログラミング言語は機械語の上に構築され、アプリケーションとオペレーティングシステムはプログラミング言語の上に構築されます。各レベルは、その下のレベルによって具現化されますが、決定されるわけではないため、ある程度自己完結した記述言語になります。

データベースシステム

データベースシステムの多くのユーザーはコンピュータのデータ構造について深い知識を持っていないため、データベース開発者はしばしば以下のレベルで複雑さを隠蔽します。

物理レベル– 最も低い抽象化レベルでは、システムが実際にどのようにデータを格納するかを記述します。物理レベルでは、複雑な低レベルのデータ構造を詳細に記述します。

論理レベル– 次のより高い抽象化レベルでは、データベースに格納されるデータと、それらのデータ間の関係が記述されます。したがって、論理レベルでは、データベース全体が少数の比較的単純な構造によって記述されます。論理レベルでの単純な構造の実装には、複雑な物理レベルの構造が伴う場合がありますが、論理レベルのユーザーはこの複雑さを意識する必要はありません。これは、物理データの独立性と呼ばれます。データベースに保持する情報を決定しなければならないデータベース管理者は、論理レベルの抽象化を使用します。

ビューレベル– 最も抽象度の高いレベルでは、データベース全体のごく一部のみを記述します。論理レベルではより単純な構造が用いられますが、大規模データベースに格納される情報の多様性ゆえに、複雑さは依然として残ります。データベースシステムの多くのユーザーは、このすべての情報を必要とするわけではなく、データベースの一部のみにアクセスする必要があります。ビューレベルの抽象化は、システムとのやり取りを簡素化するために存在します。システムは、同じデータベースに対して複数のビューを提供する場合があります。

• SimArchは、分散シミュレーションシステムのための階層型アーキテクチャの例です。