抽象化（コンピュータサイエンス）

ソフトウェア工学とコンピュータサイエンスにおいて、抽象化とは、属性などの具体的な詳細を一般化し 、^[1]オブジェクトやシステムの研究から切り離して、より重要な詳細に注意を向けるプロセスです。 ^[2]抽象化は、コンピュータサイエンスとソフトウェア工学、特にオブジェクト指向プログラミングパラダイムにおける基本的な概念です。^[3]これには次の例が含まれます。

• プログラム内でのデータの実際の表現から使用を分離するための抽象データ型の使用; ^[4]
• 制御フローを実装する特定の方法を表す関数またはサブルーチンの概念。
• オブジェクト指向プログラミング言語で見られるように、継承とサブクラスを使用して、非抽象クラスのグループから抽象クラスに共通の動作を再編成するプロセス。

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

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

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

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

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

プログラミング言語によって、その言語の用途に応じて異なるタイプの抽象化が提供されます。例:

• C++、Object Pascal、Javaなどのオブジェクト指向プログラミング言語では、抽象化の概念自体が宣言文になっています。これは、構文（C++）またはキーワード^[8]と^[9]（Java ）を使用して行われます。このような宣言の後、宣言のオブジェクトをインスタンス化するクラスを実装するのはプログラマの責任です。 function(parameters) = 0; abstractinterface
• 関数型プログラミング言語では、ラムダ抽象化（項を何らかの変数の関数にする）や高階関数（パラメータが関数である）など、関数に関連する抽象化が一般的に見られます。 ^[10]
• Clojure、Scheme、Common Lispなどの Lisp プログラミング言語ファミリーの最新メンバーは、構文の抽象化を可能にするマクロ システムをサポートしています。Scala などの他のプログラミング言語にも、マクロ、つまり非常によく似たメタプログラミング機能があります (たとえば、Haskell にはTemplate Haskellがあり、OCaml にはMetaOCamlがあります)。これらにより、プログラマーは定型コードを排除し、退屈な関数呼び出しシーケンスを抽象化し、新しい制御フロー構造を実装し、ドメイン固有の概念を簡潔かつエレガントな方法で表現できるドメイン固有言語 (DSL)を実装できます。これらすべてを正しく使用すると、意図した目的がより明確になることで、プログラマーの効率とコードの明瞭性の両方が向上します。構文の抽象化の結果、あらゆる Lisp 方言、そして実際にはほぼあらゆるプログラミング言語は、 Python 、 C 、 Java などの「より伝統的な」プログラミング言語と比較すると、原理的には大幅に削減された (しかし、ほとんどの場合、それでも簡単ではない) 労力で、あらゆる最新のLispで実装できます。

アナリストは、ソフトウェア システムを正式に指定するためのさまざまな方法を開発してきました。既知の方法には次のようなものがあります。

• 抽象モデルベースの方法（VDM、Z）
• 代数的技法（Larch、CLEAR、OBJ、ACT ONE、CASL）
• プロセスベースの技術（LOTOS、SDL、Estelle）
• トレースベースの技術（SPECIAL、TAM）
• 知識ベースの技術 (Refine、Gist)。

仕様言語は、一般的に何らかの抽象化に依存します。これは、仕様が最終的な実装よりもプロジェクトの早い段階で (より抽象的なレベルで) 定義されるのが一般的だからです。たとえば、 UML仕様言語では抽象クラスの定義が可能です。ウォーターフォール プロジェクトでは、抽象クラスはプロジェクトのアーキテクチャと仕様のフェーズでは抽象のままです。

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

a := (1 + 2) * 5

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

制御の抽象化がなければ、プログラマーは、単にいくつかの数値を加算または乗算してその結果を変数に割り当てるたびに、レジスタ/バイナリ レベルのすべての手順を指定する必要があります。このような作業の重複には、次の 2 つの重大な悪影響があります。

1. プログラマーは、同様の操作が必要になるたびに、かなり一般的なタスクを常に繰り返す必要がある。
2. プログラマーは特定のハードウェアと命令セットに合わせてプログラムする必要がある。

構造化プログラミングでは、複雑なプログラム タスクを、明確なフロー制御とコンポーネント間のインターフェイスを備えた小さな部分に分割し、副作用の複雑さの可能性を軽減します。

単純なプログラムでは、ループに単一または明確な終了ポイントがあること、および (可能な場合) 関数とプロシージャから単一の終了ポイントがあることを保証することが目的となる場合があります。

より大規模なシステムでは、複雑なタスクを多くの異なるモジュールに分割することが必要になる場合があります。船上および陸上のオフィスでの給与計算を処理するシステムを考えてみましょう。

• 最上位レベルには、一般的なエンドユーザー操作のメニューが表示される場合があります。
• その中には、従業員のサインオンとサインオフ、小切手の印刷などのタスク用のスタンドアロン実行可能ファイルまたはライブラリが含まれる場合があります。
• これらのスタンドアロン コンポーネントのそれぞれには、問題の一部を処理するプログラム コードを含む多数の異なるソース ファイルが存在する可能性があり、プログラムの他の部分では、選択されたインターフェイスのみが使用可能になります。サインオン プログラムには、各データ入力画面とデータベース インターフェイス (それ自体がスタンドアロンのサード パーティ ライブラリまたは静的にリンクされたライブラリ ルーチンのセットである可能性があります) のソース ファイルが含まれる可能性があります。
• データベースまたは給与計算アプリケーションのいずれかが船と陸の間でデータを交換するプロセスを開始する必要があり、そのデータ転送タスクには他の多くのコンポーネントが含まれることがよくあります。

これらのレイヤーは、1 つのコンポーネントの実装の詳細とそのさまざまな内部メソッドを他のコンポーネントから分離する効果を生み出します。オブジェクト指向プログラミングでは、この概念を採用し、拡張しています。

データ抽象化は、データ型の抽象プロパティとその実装の具体的な詳細を明確に分離します。抽象プロパティは、データ型 (データ型へのインターフェイス)を使用するクライアント コードから見えるプロパティですが、具体的な実装は完全に非公開に保たれ、時間の経過とともに効率性の向上を組み込むなど、変更される可能性があります。このような変更は、抽象的な動作に違いを伴わないため、クライアント コードに影響を及ぼすことはないというのが考え方です。

たとえば、キーと値を一意に関連付け、対応するキーを指定して値を取得できる、ルックアップ テーブルと呼ばれる抽象データ型を定義できます。このようなルックアップ テーブルは、ハッシュ テーブル、バイナリ検索ツリー、または (キー:値) ペアの単純な線形リストなど、さまざまな方法で実装できます。クライアント コードに関する限り、型の抽象プロパティはいずれの場合も同じです。

もちろん、これはすべて、インターフェイスの詳細を正しく理解することに依存しています。インターフェイスを変更すると、クライアント コードに大きな影響を与える可能性があるためです。これを考察する 1 つの方法として、インターフェイスは、データ型とクライアント コードの間で合意された動作に関する契約を形成します。契約に明記されていない内容は、予告なしに変更される可能性があります。

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

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

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

たとえば、Common Lisp Object SystemやSelf では、クラスとインスタンスの区別が少なく、ポリモーフィズムのために委任が多く使用されています。個々のオブジェクトと関数は、 Lispからの共有された機能的遺産に適合するように、より柔軟に抽象化されています。

C++ は別の極端な例です。コンパイル時に テンプレートやオーバーロード、その他の静的バインディングに大きく依存しており、その結果、柔軟性に問題が生じます。

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

たとえば、一般的な農場の「動物」を、その空腹と給餌の単純な側面をモデル化するのに適した抽象レベルで表すサンプルJavaAnimalフラグメントを考えてみましょう。動物の状態とその機能の両方を表すクラスを定義します。

パブリッククラスAnimal はLivingThingを拡張します{プライベートLocation loc ;プライベート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 つのタイプ間でさまざまなレベルのポリモーフィズムを定義できます。これらの機能は言語によって大幅に異なる傾向がありますが、一般的には、各言語で他の言語で可能なことはすべて実現できます。データ型ごとに多数の操作オーバーロードを行うと、コンパイル時に継承のレベルやポリモーフィズムを実現する他の手段と同じ効果が得られます。クラス表記は、コーダーの利便性のためだけのものです。

何を抽象化し、何をコーダーの制御下に置くかに関する決定は、オブジェクト指向設計とドメイン分析の主な関心事になります。実際の現実世界における関連する関係を決定することは、オブジェクト指向分析またはレガシー分析の関心事です。

一般に、適切な抽象化を決定するには、スコープに関する多くの小さな決定 (ドメイン分析) を行い、他のどのシステムと連携する必要があるかを決定し (レガシー分析)、プロジェクトの時間と予算の制約内でオブジェクト指向設計として表現される詳細なオブジェクト指向分析を実行する必要があります。この簡単な例では、ドメインは納屋、生きた豚と牛、およびその食習慣がレガシー制約、詳細な分析は、コーダーが動物に利用可能なものを与える柔軟性を持つ必要があるため、クラス自体に餌の種類をコーディングする理由はないこと、設計は豚と牛が同じ機能を持つインスタンスである単一の単純な Animal クラスです。DairyAnimal を差別化する決定は詳細な分析を変更しますが、ドメインとレガシー分析は変更されません。したがって、これは完全にプログラマーの制御下にあり、ドメインまたはレガシー分析の抽象化とは区別して、オブジェクト指向プログラミングの抽象化と呼ばれます。

プログラミング言語、形式手法、抽象解釈の形式意味論について議論する場合、抽象化とは、観察されるプログラムの動作について、詳細ではないが安全な定義を検討する行為を指します。たとえば、実行の中間ステップをすべて考慮するのではなく、プログラム実行の最終結果のみを観察する場合があります。抽象化は、実行の具体的な（より正確な）モデルに対して定義されます。

抽象化は、プロパティに関する質問に具体的なモデルでも抽象的なモデルでも同じように答えられる場合、プロパティに関して正確または忠実であると言えます。たとえば、整数 +、-、× のみを含む数式の評価結果がn を法として何の価値があるかを知りたい場合は、すべての演算を n を法として実行するだけで済みます(この抽象化のよく知られた形式は、9 を除外することです)。

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

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

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

抽象化は抽象解釈の中核となる概念です。モデル検査は通常、研究対象のシステムの抽象バージョンで行われます。

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

データベース システムのユーザーの多くはコンピューターのデータ構造を深く理解していないため、データベース開発者は多くの場合、次のレベルを通じて複雑さを隠します。

物理レベル:最も低い抽象化レベルでは、システムが実際にデータを保存する 方法を説明します。物理レベルでは、複雑な低レベルのデータ構造を詳細に説明します。

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

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

異なるレベルの抽象化の 設計を提供できる能力は

• デザインを大幅に簡素化する
• さまざまな役割のプレーヤーがさまざまな抽象レベルで効果的に作業できるようにする
• ソフトウェア成果物の移植性をサポートする（理想的にはモデルベース）

システム設計とビジネス プロセス設計の両方でこれを使用できます。一部の設計プロセスでは、さまざまなレベルの抽象化を含む設計が特に生成されます。

階層化アーキテクチャは、アプリケーションの問題を積み重ねられたグループ (レイヤー) に分割します。これは、コンピューター ソフトウェア、ハードウェア、通信の設計に使用される手法で、システムまたはネットワーク コンポーネントがレイヤーに分離されるため、1 つのレイヤーに変更を加えても他のレイヤーには影響しません。

• 抽象化の原理（コンピュータプログラミング）
• 抽象化における一つの危険のアンチパターンに対する抽象化反転
• データセットの抽象的記述のための抽象データ型
• 計算手順を抽象的に記述するアルゴリズム
• 項を変数の関数にするための括弧抽象化
• プロセスに依存しないデータの構造化のためのデータモデリング
• 実装の詳細を隠す抽象化のためのカプセル化
• グリーンスパンの第10の法則は、抽象空間における（？）最適点についての格言である。
• 関数が他の関数を生成したり消費したりする抽象化のための高階関数
• 項を何らかの変数の関数にするためのラムダ抽象化
• 抽象化の一覧（コンピュータサイエンス）
• コンピューティングにおける抽象化の反対の洗練
• 整数（コンピュータサイエンス）
• ヒューリスティック（コンピュータサイエンス）

• 分散シミュレーション システム用の階層化アーキテクチャの SimArch の例。