抽象化とは何ですか？
プログラマが使用するprogramming abstractionの定義について、一般的に合意された定義はありますか？ [注意：プログラミングの抽象化は、単語「抽象化」の辞書定義と混同しないでください。]明確な、または数学的な定義さえありますか？抽象化の明確な例は何ですか？
「プログラミングの抽象概念を多かれ少なかれ数学的に定義できますか」に対する答え。 「いいえ」です。抽象化は数学的な概念ではありません。レモンの色を数学的に説明してもらうようなものです。
ただし、適切な定義が必要な場合：抽象化とは、特定のアイデアからより一般的なアイデアに移行するプロセスです。たとえば、マウスを見てみましょう。ワイヤレスですか？どんなセンサーがありますか？ボタンの数は？人間工学的ですか？それはどれくらい大きいですか？これらすべての質問への回答はマウスを正確に説明できますが、回答が何であれ、ボタン付きのポインティングデバイスであるため、マウスのままです。それがマウスになるために必要なすべてです。 「Silver Logitech MX518」は具体的な特定のアイテムであり、「マウス」はそれを抽象化したものです。考えるべき重要なことは、「マウス」のような具体的なオブジェクトは存在しないということです。それは単なるアイデアです。机の上のマウスは常により具体的なものです。これはAppleマジックマウスまたはDellオプティカルマウスまたはMicrosoft IntelliMouseです-「マウス」は単なる抽象的な概念です。
抽象化は層状にすることができ、好きなように細かくまたは粗くすることができます（MX518はポインティングオブジェクトであるマウスであり、コンピューター周辺機器であり、電気で動くオブジェクトです）、好きなところまで行くことができます。 、そして実質的にどの方向にも（マウスにはワイヤーがあり、ワイヤーのあるオブジェクトとして分類できることを意味します。また、底面が平らであるため、回転しないオブジェクトの一種として分類できます）傾斜面に直立させます）。
オブジェクト指向プログラミングは、抽象化とそれらのファミリーまたはグループの概念に基づいて構築されています。良いOOPは、プログラムのドメインで意味があり、「リーク」しない適切な詳細レベルで適切な抽象化を選択することを意味します。前者は、マウスを勝ったオブジェクトとして分類することを意味します傾斜面で転がらないことは、コンピューター機器をインベントリするアプリケーションには意味がありませんが、物理シミュレーターには意味があるかもしれません。後者は、そうでない階層への「ボックス化」を回避しようとする必要があることを意味します。 tある種のオブジェクトには意味があります。たとえば、上の階層では、allコンピュータ周辺機器が電気によって電力供給されていることは確かですか？スタイラス？スタイラスを「周辺機器」カテゴリにグループ化する場合、電気を使用しないため問題が発生し、コンピュータの周辺機器を電気を使用するオブジェクトとして定義しました。 円楕円問題 は、この難問の最もよく知られている例です。
私は断固としてほとんどの回答に同意しません。
これは私の答えです：
2つのセットGとHが与えられると、ガロア接続（alpha、beta）をそれらの間に定義でき、一方は他方の具体化であると言えます。接続を逆にします。一方は他方の抽象化です。関数は、具体化関数と抽象化関数です。
これは、コンピュータプログラムの抽象的な解釈の理論によるものです。これは、通常、これまでの静的分析アプローチです。
抽象化はWhatに重点を置いており、Howには重点を置いていません。または、必要なことだけを知って、他のすべてのサービスのプロバイダーを信頼する、と言うこともできます。サービスプロバイダーの身元を隠すことさえあります。
たとえば、このサイトでは、質問をして回答するためのシステムを提供しています。ここにいるほとんどの人は、このサイトの質問、回答、投票、その他の手順について知っています。しかし、その基盤となるテクノロジーを知っている人はほとんどいません。サイトがASP.net mvcとPythonのどちらで開発されたかと同様に、これがWindowsサーバーで実行されているか、Linuxサーバーで実行されているかなどです。そのため、このサイトは、サービスを提供する私たちの基礎となるメカニズムの上に抽象化レイヤーを保持しています。
その他の例：
車はすべてのメカニズムを隠しますが、運転者に燃料を補給し、維持する方法を提供します。
APIは、他のプログラマにサービスを提供するすべての実装の詳細を隠します。
OOP=のクラスは、プライベートメンバーと、パブリックメンバーを呼び出すサービスを提供するパブリックメンバーの実装を非表示にします。
JavaまたはC++で
Interfaceまたはabstract classのタイプのオブジェクトを使用している場合、実際の実装は非表示になります。非表示ではなく、Interfaceで宣言されたメソッドは、さまざまな実装/継承クラスでも異なる可能性があります。ただし、同じサービスを取得しているので、Howは実装されていて、正確にWho/Whatがサービスを提供しています。ID非表示：「サムはコンピュータプログラムを作成できることを知っています」という文に対して。 「サムはプログラマーです。プログラマーはコンピュータープログラムの書き方を知っています。」 2番目のステートメントでは、人は重要ではありません。しかし、プログラミングを行う彼の能力は重要です。
プログラミングの抽象化は、問題の簡略モデルです。
たとえば、TCP/IP接続は、データの送信を抽象化したものです。 IPアドレスとポート番号を含めて、APIに送信するだけです。ワイヤ、信号、メッセージ形式、および障害のすべての詳細に関心があるわけではありません。
抽象化は、定理のプログラミングバージョンにすぎません。
正式なシステムがあり、そのシステムについての考えを提案します。あなたはそれを証明します、そしてそれがうまくいくなら、あなたは定理を持っています。あなたの定理が成り立つことを知っていれば、それをシステムに関するさらなる証明に使用できます。システムによって提供されるプリミティブ（ifステートメントやint値タイプなど）は、通常、公理と見なされますが、マシンコードで記述されたCPU命令ではないものは一種の抽象化であるため、厳密には当てはまりません。
関数型プログラミングでは、プログラムを数学的ステートメントとして考えるという考え方は非常に強く、多くの場合、型システム（Haskell、F＃、OCAMLなどの静的で型付けされた強力な言語）は、証明による定理のテストに使用できます。
たとえば、プリミティブ演算として加算と等価のチェックがあり、プリミティブデータ型として整数とブール値があるとします。これらは私たちの公理です。つまり、1 + 3 == 2 + 2は定理です。次に、加算と整数と等価の規則を使用して、それが真のステートメントかどうかを確認します。
次に、乗算が必要で、プリミティブ（簡略化のため）にループ構成とシンボリック参照を割り当てる手段が含まれていると仮定します。私たちはそれを提案することができます
ref x (*) y := loop y times {x +}) 0
私はそれを証明したふりをして、乗算が成立することを示します。これで、乗算を使用して、システム（プログラミング言語）でより多くのことを実行できます。
タイプシステムをチェックすることもできます。 （*）のタイプはint-> int-> intです。 2つの整数を取り、整数を出力します。加算にはint-> int-> intのタイプがあるため、（rest）がintになる限り0 +（rest）が保持されます。私のループはあらゆる種類のことを実行する可能性がありますが、（x +（x +（x ... + 0）））が結果となるようなカリー化された関数のチェーンを出力すると言っています。その追加チェーンの形式は（int->（int->（int ...-> int）））なので、最終出力はintになります。したがって、私のタイプシステムは、他の証明の結果を保留しました。
この種のアイデアを長年にわたって、多くのプログラマーや多くのコード行を組み合わせて作成すると、最新のプログラミング言語：プリミティブの豊富なセットと、「証明された」コード抽象化の巨大なライブラリーができます。
ここで良い答えを得ています。私は注意するだけです-抽象化はどういうわけか台座に置く必要があるこの素晴らしいものであり、あなたは十分に得ることができないと人々は考えています。そうではない。常識です。物事の類似点を認識するだけなので、問題の解決策をさまざまな問題に適用できます。
許してくれ...
私の不満のリストの上位は、人々が「抽象化の層」についてそれが良いことであるかのように話すときです。彼らは、好きではないクラスやルーチンの周りに「ラッパー」を作成し、「より抽象的な」と呼んでいます。 「プリンセスとエンドウ」の寓話を覚えていますか？プリンセスはとても繊細だったので、マットレスの下にエンドウ豆があったら、彼女は眠ることができず、マットレスの層をさらに追加しても役に立ちませんでした。 「抽象化」の層をさらに追加すると役立つという考えは、まさにその通りです-通常はそうではありません。これは、基本エンティティへの変更を複数のコード層に波及させる必要があることを意味します。
リークのある抽象化について 私のブログ投稿 が役立つかもしれません。関連する背景は次のとおりです。
Abstractionは、関連するプログラムフラグメントのセットに共通するものを取り、それらの違いを取り除き、プログラマーがその抽象的な概念。この新しい構成体には、（実質的に）常にパラメータ化があります。これは、特定のニーズに合わせて構成体の使用をカスタマイズする手段です。
たとえば、Listクラスは、リンクリスト実装の詳細を抽象化できます。nextおよびpreviousポインターの操作に関して考える代わりに、シーケンスに値を追加または削除するレベル。 抽象化は、より原始的な概念のはるかに小さなセットから、便利で豊富な、時には複雑な機能を作成するための不可欠なツールです。
抽象化はカプセル化とモジュール性に関連しており、これらの概念はしばしば誤解されています。
Listの例では、encapsulationを使用してリンクリストの実装の詳細を非表示にできます。たとえば、オブジェクト指向言語では、nextおよびpreviousポインターをプライベートにできます。これらのフィールドへのアクセスが許可されるのは、List実装のみです。
カプセル化は抽象化には十分ではありません。構成の新しい概念や異なる概念があることを必ずしも意味しないからです。 Listクラスがすべて 'getNext'/'setNext'スタイルのアクセサメソッドを提供した場合、実装の詳細からカプセル化されます（たとえば、フィールド 'prev'または 'previous'？静的型は何でしたか？）、しかしそれは非常に低い程度の抽象化を持っているでしょう。
モジュール性は情報の隠蔽に関係しています：安定したプロパティがインターフェースで指定されています、モジュールはそのインターフェースを実装し、モジュール内のすべての実装の詳細を保持します。他のモジュールは安定したインターフェースのみに依存しているため、モジュール性はプログラマーが変更に対処するのに役立ちます。
情報の隠蔽はカプセル化によって支援されます（コードが不安定な実装の詳細に依存しないようにするため）が、モジュール化のためにカプセル化は必要ありません。たとえば、CにList構造体を実装して、 'next'および 'prev'ポインターを世界に公開するだけでなく、initList()、addToList()、およびremoveFromList()関数。インターフェースのルールが守られている場合、データ構造が常に有効な状態であることを保証するなど、特定のプロパティが常に保持されることを保証できます。 [たとえば、モジュール性に関するパルナスの古典的な論文は、アセンブリの例を使用して書かれました。インターフェースは契約であり、設計に関するコミュニケーションの形式であり、それは私たちが今日依存しているものですが、必ずしも機械的にチェックする必要はありません。]
抽象、モジュラー、カプセル化などの用語は、肯定的な設計の説明として使用されますが、これらの品質のいずれかが存在しても、優れた設計が自動的に提供されるわけではないことを認識することが重要です。
N ^ 3アルゴリズムが「うまくカプセル化」されている場合でも、改善されたn log nアルゴリズムよりもパフォーマンスが低下します。
インターフェイスが特定のオペレーティングシステムにコミットする場合、たとえば、ビデオゲームをWindowsからiPadに移植する必要がある場合、モジュール式設計の利点は実現されません。
作成された抽象化があまりにも多くの本質的でない詳細を公開する場合、それは独自の操作で新しい構成を作成することに失敗します：それは単に同じものの別の名前になります。
ウィキペディアの答えは十分でしょうか？ http://en.wikipedia.org/wiki/Abstraction_%28programming%29
コンピュータサイエンスでは、抽象化のメカニズムと実践により詳細が削減され、除外されるため、一度にいくつかの概念に集中できます。
まあ、数学的には、「整数」は抽象概念です。そして、すべての整数に対してそのようなx + y = y + xのような正式な証明を行う場合、3または4のような特定の数値ではなく、抽象化「整数」で作業しています。ソフトウェア開発でも、レジスタとメモリ位置より上のレベルのマシン。ほとんどの場合、より強力な考えをより抽象的なレベルで考えることができます。
別の人にそれを説明する方法として、私は結果から戻って、逆に行きます：
コンピュータプログラミングの抽象化とは、何かを一般化して、複数の同様のものを一般的に同じものとして扱い、同じように処理できるようにすることです。
さらに拡張したい場合は、以下を追加できます。
これは、反復的なコードを削減するために多態的な動作（インターフェースと継承）を達成するために行われる場合もあれば、何かを変更せずに将来的に同様のソリューションで何かの内部動作を置き換えることができるように行われる場合もあります。抽象化されたコンテナまたはラッパーの反対側のコード。将来的にはやり直しを削減できると期待しています。
それを超えて、私はあなたが例から始める必要があると思います...
抽象化とは、関連がないと思われる詳細を無視して、関連があると思われる詳細を優先することです。
抽象化には、カプセル化、情報の隠蔽、および一般化が含まれます。類推、比喩、またはヒューリスティックスは含まれません。
抽象化の概念の数学的形式は、それ自体が抽象化である必要があります。 morphism のカテゴリー理論の概念は、おそらくあなたが探しているものに最も近いでしょう。
抽象化はあなたが宣言したものではなく、あなたがしたことです。
わかりました、私はあなたが何を求めているのか理解したと思います：「数学的に厳密な「抽象化」の定義とは何ですか」
それが事実である場合、あなたは運が悪いと思います-「抽象化」はソフトウェアアーキテクチャ/設計用語であり、私が知っている限りそれに対する数学的な裏付けはありません（多分理論的なCSに精通している誰かが私を修正するでしょう）ここで）、「カップリング」または「情報の隠蔽」以上のものには、数学的な定義があります。
私は常にプログラミングの抽象化を、詳細を隠して簡略化されたインターフェースを提供することと考えています。これは、プログラマーが記念碑的なタスクを管理可能な部分に分割できる主な理由です。抽象化を使用すると、問題の一部（完全な詳細を含む）のソリューションを作成し、そのソリューションを使用するためのシンプルなインターフェースを提供できます。その後、実質的に詳細を「忘れる」ことができます。非常に複雑なシステムのすべての詳細を一度に頭に浮かび上がらせることはできないため、これは重要です。これは、抽象化の下にある詳細を再検討する必要がないことを意味しているわけではありませんが、当面は、インターフェースのみを記憶する必要があります。
プログラミングでは、この簡略化されたインターフェイスは、変数（ビットのグループを抽象化し、より単純な数学的インターフェイスを提供します）から関数（クラスを超えて任意の量の処理を単一の行呼び出しに抽象化します）に至るまで、何でもかまいません。
結局のところ、プログラマーの主な仕事は、通常、すべての計算の詳細を抽象化し、コンピューターの動作について1つのことを知らない人が利用できるGUIのような単純なインターフェースを提供することです。
抽象化には次のような利点があります。
大きな問題を扱いやすい部分に分割できるようにします。人のレコードをデータベースに追加するとき、データベースへのインデックスツリーの挿入とバランスをいじる必要はありません。この作業はある時点で行われた可能性がありますが、現在は抽象化されており、心配する必要はありません。
複数の人がプロジェクトで一緒にうまく作業できるようにします。同僚のコードのすべての詳細を知りたくありません。私はそれをどのように使用するか、それが何をするか、そしてそれを私の仕事（インターフェース）とどのように合わせるかを知りたいだけです。
必要な知識がない人でも、複雑なタスクを実行できます。私のお母さんはFacebookを更新でき、全国で知っている人はそれを見ることができます。めちゃくちゃ複雑なシステムを単純なWebインターフェースに抽象化しないと、彼女が同様のことを始めることができません（私もそうです）。
ただし、抽象化は、過度に使用すると、管理がしにくくなるという逆の効果をもたらす可能性があります。問題を細かく分割すると、覚えなければならないインターフェースの数が増え、実際に何が起こっているのかを理解することが難しくなります。ほとんどの場合と同様に、バランスを見つける必要があります。
私がそれを人々に説明しようとする一つの方法は、最善の方法ではないかもしれません
2 + 2を追加して4を出力するプログラムを考えてみましょう
ユーザーが入力した2つの数値x + y = zを加算するプログラムを考えます。
より便利で一般的なものはどれですか？
抽象化は不必要な詳細を隠すものだと私は主張します。抽象化の最も基本的な単位の1つは手順です。たとえば、ファイルからデータを読み取るときに、データベースにデータを保存する方法について心配したくありません。そこで、save_to_database関数を作成します。
抽象化を結合して、より大きな抽象化を形成することもできます。たとえば、関数をクラスにまとめたり、クラスをまとめてプログラムを作成したり、プログラムをまとめて分散システムを作成したりできます。
これは私が実際にもっと長い間ブログを書きたかったものですが、私はそれに到達したことがありません。幸いにも、私は担当ゾンビであり、賞金さえあります。 私の投稿はかなり長くなりました 、しかしここに本質があります：
プログラミングの抽象化は、特定のコンテキスト内のオブジェクトの本質を理解することです。
[...]
抽象化は、一般化だけでなく、カプセル化とも誤解されますが、これらは情報隠蔽の2つの直交部分です。サービスモジュールは、表示しようとするものを決定し、クライアントモジュールは、表示しようとするものを決定します。カプセル化は最初の部分であり、抽象化は後者です。両方のみが完全な情報隠蔽を構成します。
お役に立てば幸いです。
間接レベルの追加。
使用しているオブジェクトがCatであるかDogであるかを気にしたくないので、仮想関数テーブルを調べて正しいmakeNoise()を見つけます関数。
これは「より低い」および「より高い」レベルにも適用できると確信しています-特定のプロセッサに使用する適切な命令を探しているコンパイラ、またはすべてを呼び出すことによる計算効果に対するHaskellのMonadsの抽象化を考えてくださいreturnおよび>>=。
Bob Martinのメトリックのいくつかをチェックすることをお勧めします
http://en.wikipedia.org/wiki/Software_package_metrics
とはいえ、彼の「抽象性」はあなたのものと同じではないと思います。彼は、「クラスでの実装の欠如」のより多くの尺度であり、インターフェース/抽象クラスの使用を意味します。不安定性とメインシーケンスからの距離は、おそらくあなたが探しているものにより深く影響します。
抽象化とは、何か（概念、データ構造、関数など）を別のもので表現することです。たとえば、言葉でコミュニケーションします。 Wordは、音（スピーチ）またはグラフィックシンボル（ライティング）の観点から表現できる抽象的なエンティティです。抽象化の重要なアイデアは、問題のエンティティは、それを発するために使用される音やそれを書くために使用される文字ではないのと同じように、基になる表現とは異なるということです。
したがって、少なくとも理論上は、抽象化の基礎となる表現を別の表現に置き換えることができます。ただし、実際には、抽象化が基礎となる表現と完全に区別されることはまれであり、「 リーク を通じて表現されることもあります。たとえば、スピーチは書面で伝えるのが非常に難しい感情的な低調をもたらします。このため、同じ言葉の音声録音と文字起こしは聴衆に非常に異なる影響を与える可能性があります。言い換えれば、言葉の抽象化はしばしば漏れます。
抽象化は通常、レイヤーで行われます。単語は、文字で表すことができる抽象であり、それ自体が音の抽象であり、音声のコードによって作成され、鼓膜によって検出される空気の粒子の動きのパターンを抽象化したものです。 。
コンピュータサイエンスでは、ビットは通常、最低レベルの表現です。バイト、メモリ位置、アセンブリ命令、およびCPUレジスタは、次のレベルの抽象化です。次に、プリミティブデータ型と上位レベル言語の命令があり、バイト、メモリロケーション、およびアセンブリ命令の観点から実装されています。次に、関数とクラス（OO言語を想定）であり、プリミティブデータ型の観点から実装され、組み込みの言語命令を使用します。次に、より複雑な関数とクラスが、単純なものの観点から実装されます。これらの関数とクラスのリストには、リスト、スタック、キューなどのデータ構造が実装されています。これらは、プロセスのキュー、従業員のリスト、本のタイトルのハッシュテーブルなど、より具体的なエンティティを表すために使用されます。この体系では、各レベルはその前任者に対する抽象化です。
Merriam-websterは抽象を形容詞的存在として定義します：特定のインスタンスから切り離されています。
抽象化は、いくつかのシステムのモデルです。それらは、実際のシステムを抽象化によってモデル化できるようにするために満たす必要がある一連の仮定をリストしていることが多く、ますます複雑になるシステムを概念化するために使用されます。実際のシステムから抽象化に移行するには、そのための正式な数学的な方法はありません。それは抽象化を定義している人の判断次第であり、抽象化の目的は何ですか。
ただし、抽象化は数学的な構成要素によって定義されることがよくあります。科学や工学でよく使われているからでしょう。
例はニュートン力学です。それはすべてが非常に小さいと仮定し、すべてのエネルギーが節約されます。オブジェクト間の相互作用は、数式によって明確に定義されます。さて、私たちが知っているように、宇宙はそのようにうまく機能せず、多くの状況で抽象化が漏れています。しかし、多くの状況で、それは非常にうまく機能します。
別の抽象的なモデルは、典型的な線形回路要素、抵抗器、コンデンサー、インダクターです。ここでも、相互作用は数式によって明確に定義されます。低周波回路、または単純なリレードライバーなどの場合、RLC分析は適切に機能し、非常に優れた結果を提供します。しかし、マイクロ波無線回路などの他の状況では、要素が大きすぎ、相互作用が細かくなり、単純なRLC抽象化が維持されません。その時何をするかはエンジニアの判断次第です。一部のエンジニアは、他のものの上に別の抽象概念を作成しました。一部は、理想的なオペアンプをそれらがどのように機能するかについての新しい数式で置き換え、他の人は理想的なオペアンプをシミュレートされた実際のオペアンプで置き換え、さらに、より小さな複雑なネットワークでシミュレートします理想的な要素。
他の人が言ったように、それは単純化されたモデルです。これは、複雑なシステムをよりよく理解するために使用されるツールです。
プログラミングの抽象化は、誰かがプログラムの要素に対して行った抽象化です。アイテムやものでメニューを作成する方法を知っているとしましょう。次に、誰かがそのコードを見て、他の種類のひどい構造に役立つ可能性があると考え、コンポーネントデザインパターンを最初のコードの抽象化で定義しました。
オブジェクト指向のデザインパターンは、抽象化とは何かの非常に良い例であり、実際の実装を意味するのではなく、ソリューションに取り組む方法を示しています。
つまり、要約すると、プログラミングの抽象化は問題を理解するためのアプローチであり、何かを得るための手段ですが、本物ではありません
私にとって抽象とは、「文字通り」存在しないものであり、アイデアのようなものです。数学でそれを表現すると、数学は脳で何が起こっているかを表現する言語であり、他の誰かの脳が理解できるようになるので、それはもはや抽象的なものではありません。もはや：アイデアモデルを表現するために脳がどのように機能するかを理解する必要があります。
抽象化は、現実をそれから独立できる何かに解釈することを可能にするものです。ビーチと夢を抽象化できますが、ビーチは存在しますが、夢は存在しません。しかし、両方が存在することはわかるでしょうが、それは真実ではありません。
抽象化で最も難しいのは、他の人がそれを理解して現実に変えることができるようにそれを表現する方法を見つけることです。これは最も困難な仕事であり、実際に単独で行うことはできません。自分のアイデアに基づいて機能し、他の誰かが理解できる相対モデルを発明する必要があります。
コンピュータ言語での抽象化は、モデルを「数学化」する名前である必要があります。それは、伝達できるアイデアを再利用することに関するものであり、抽象的に達成できるものと比較して、それは非常に大きな制約です。
簡単に言えば、原子は互いに隣にありますが、それらは関係ありません。人間に組織化された大きな分子の集合は、彼が誰かの隣にいることは理解できますが、どのようにして原子がそれらを特定のパターンに配置したかは理解できません。
概念に支配されている1つのオブジェクトは、一般に、それ自体を「理解」することはできません。だから私たちは神を信じようとし、私たちの脳を理解するのに苦労しています。
メダルを貰えますか？
ここで、数学的な答え：
引き離すプログラミングでは、詳細については今は気にしないふりをしていますが、実際には気にしていて、常に気にする必要があります。それは基本的にふりをしています。
興味深い質問です。プログラミングに関しては、信頼できると見なされる抽象化の単一の定義を知りません。他の人々はCS理論または数学のさまざまな分野からのいくつかの定義へのリンクを提供していますが、私はそれを「supervenience」と同じように考えるのが好きです http://en.wikipedia.org/wiki/Supervenience を参照してください
プログラミングにおける抽象化について話すとき、本質的にはシステムの2つの記述を比較しています。コードはプログラムの説明です。コードの抽象化は、そのプログラムの記述でもありますが、「より高い」レベルです。もちろん、元の抽象化をさらに高いレベルで抽象化することもできます（たとえば、高レベルのシステムアーキテクチャでのプログラムの記述と、詳細設計におけるプログラムの記述）。
ここで、ある記述を別の記述よりも「高レベル」にします。重要なのは「複数の実現可能性」です。プログラムの抽象化は、多くの方法で多くの言語で実現できます。これで、1つのプログラムに対して複数のデザインを作成することもできます。2人で、プログラムを正確に表す2つの異なる高レベルデザインを作成できます。実現の同等性が違いを生みます。
プログラムまたは設計を比較するときは、そのレベルで説明の主要なプロパティを識別できる方法で比較する必要があります。設計が別の設計と同等であると言う複雑な方法に入ることができますが、それを考える最も簡単な方法はこれです-単一のバイナリプログラムが両方の記述の制約を満たすことができますか？
では、あるレベルの説明が他のレベルよりも高くなるのは何ですか？たとえば、あるレベルの記述A（設計ドキュメントなど）と別のレベルの記述B（ソースコードなど）があるとします。 AはBよりも高いレベルです。A1とA2がレベルAで2つの同等ではない記述である場合、それらの記述の実現、B1とB2mustも必要ですレベルBでは同等ではありません。ただし、その逆は必ずしも成り立ちません。
したがって、2つの異なる設計ドキュメントを満たす単一のバイナリプログラムを作成できない場合（つまり、これらの設計の制約が互いに矛盾する場合）、それらの設計を実装するソースコードは異なる必要があります。しかし、その一方で、同じバイナリプログラムにコンパイルできない可能性のある2セットのソースコードを取得した場合でも、これらの2セットのソースコードをコンパイルした結果のバイナリが両方とも同じ設計を満たす場合があります。資料。したがって、設計ドキュメントはソースコードの「抽象化」です。