Eiffel: 一歩進んだ入門

8章:

分析と設計に対する Eiffel の役割、Eiffel の未来に関わる最後の言葉

  
8 - 分析と設計に対する Eiffel の役割、Eiffel の未来に関わる最後の言葉
    8.0 導入
    8.1 クラスと特徴の実装を延期すること
    8.2 明示的な生成
    8.3 私のクライアントに何を告げるか?  
    8.4 Eiffel の未来 

8.0 導入

　ソフトウェアを書くことは、ますます、椅子に長く座り込み、私たちの問題を長時間思案するという動作になってきており、実際にソフトウェアを書くことに費やされている時間は短くなってきています。分析と設計に関するこの強調は、根本的に異なる尺度による見積もりに反映されるように、オブジェクト指向パラダイムによって促進されています。Bertrand Meyer による「Object-oriented Software Construction」と題した本において、ソフトウェア費用の 70% までがメンテナンスに由来しうる、ということが見積もられています。つまり、生産物は、ひとたび実際に「完成」すると、綺麗に片付けられ、更新や維持といったことを継続しればならない、ということです。もし根底にあるシステムが正確かつ綿密に文書化されたり、分析されたり、拡張的に設計されていなかったならば、最終リリースの納期は、批判的かつ費用的になりえます。

　いま、強調は、重点的に、もっともっと初期の努力に置かれています。この新しい姿勢は、二重の利益を持っています。

1. プロジェクト i で作成したオブジェクトは、プロジェクト i+1 で、より容易に再利用でき、そのため、将来のプロジェクトの費用を減少させます。
2. そして、維持のための潜在的に 70% の費用は、劇的に減少しており、設計に関してより少ないリスクとより柔軟な、ソフトウェア サイクルの初期の段階に置かれています。

　Eiffel は、PDL(Program Design Language,プログラム設計言語)として適しています。PDL は、特定の実装に関係することの無しに、ソフトウェアを記述するために使用する言語です。Eiffel がこれに適しているということは、ほとんど神の恩恵であり、災いです。それが神の恩恵である理由は、実装することを必要とするソフトウェアを Eiffel を用いてモデル化するか、あるいは記述するときにその実装を必要とさえしない、ということです。それは、すでに、モデリングで行なっているのです！　 一方、PDL として Eiffel を用いることは、Eiffel によって提供された機構、特にその拡張的な特徴の適応機構に関係するもの、が大部分の他の言語で現れないという状況にある、何人かの設計者にとって、とても魅力的であったかもしれません。私たちは、言語が私たちの表記法をサポートしないとき、どのようにモデルを実装するでしょう？

8.1 クラスと特徴の実装を延期すること

　Eiffel が適した PDL になることに向かってとる最初のステップは、オブジェクトあるいはオブジェクトのグループに関する既存の知識を、実際にそれを完全に実装すること無しに、取り込むための能力です。私たちは、システムに対する私たちの既存の知識を反映し、部分的に完全なクラスを作成でき、私たちの情報をよりよく反映する、一層特殊化したクラス群を継承できます。これは、次のように行うこともできます。

   deferred class FILE_PROCESSOR  

   feature {NONE}  
      file_to_be_processed : FILE;

   feature {ANY}  
      process is  
         deferred  
      end; -- process  
   end -- FILE_PROCESSOR

　このクラスは、私たちが、自分でファイルを処理しようとしていることを知っているが、どのように行われることになるのか、正確にどんな種類のファイルであるのかをまったく分かっていない、という事実を反映しているかもしれません。後の分析の最中に、私たちは、行がファイルに何行あるかを判定するために、ベクターグラフィックのファイルを処理していることになるということを決定する、と言ってみましょう。この新しい知識の存在は、選ばれた数名の分析担当者の心の中に残しておいてはいけません。それは、文書化すべきです。

   class VECTOR_PROCESSOR

   inherit  
      FILE_PROCESSOR  
         rename file_to_be_processed as vector_file;  
      end;  

   feature  
      process is  
      do  
         ...  
         -- class text left out  
      end; -- process  
   end -- VECTOR_PROCESSOR  

　この新しいクラスは、私たちに、新しい情報は FILE_PROCESSOR という分類に関して集められた、と言うことを許します。本質において、私たちは、書式と同様に機能を、FILE_PROCESSOR で明白にする私たちの祖先<predecessor>へ与えています。

　どうして私たちが私たちの process ルーチンを再定義しなければならなかったのか、と質問したかもしれません。それは前に FILE_PROCESSOR に存在したが、私たちはまた VECTOR_PROCESSOR でそれを宣言しました。これは、合法的でしょうか？　それは実際に FILE_PROCESSOR で宣言したが定義せずに実装したから、私たちは、定義を持っていないものを再定義できなかったのです。私たちは、それ自体実装を延期<deferred>されたクラスから延期される特徴を継承するとき、それに効果を与えているのであって、それを再定義しているのではありません。前のクラスで部分的に定義されることだけができるルーチンへ意味付けを与えることは、Eiffel が提供する魅力的な能力です。

　defered されたクラスとして適格にするために、そのクラスの少なくとも一つの特徴が defered されなくてはなりません。この場合に、クラスヘッダーは、defered キーワードで始まらなければなりません。実装を延期したクラスは、インスタンスを作成できません。つまり、このタイプで生成されるオブジェクトは一つもありません。それらは、延期したクラスとして宣言できますが、実例を生成できません。

8.2 明示的な生成

　クラスが実装を延期していることを私たちは知っているが、その型の実体はどこにも宣言する必要が無い、ということが起こります。実例として、もし私たちがファイル管理システムを開発しているならば、そのクラス群の一つは、さまざまなファイル -- グラフィック、テキスト、カンマ区切りなど -- を処理する、ある特定の特殊なサービスであったかもしれません。次を良く考えてください。

   class FILE_UTILITIES  
   feature  
      process : FILE_PROCESSOR:  
      ...  
   end --FILE_UTILITIES  

　私たちは、自分の利用においてファイル処理クラスを必要とすることを分かっているから、このタイプの（あるいは類似した）宣言が開発プロセスの何らかの段階で現れることになる、ということを分かっています。私たちはこれを行えますか？　はい。Eiffel は、実体に、延期されたクラスとして宣言されることを認めています。実例を作成することは認めていません。では、私たちは、どのようにして、宣言したものと異なる他のタイプのクラスの実例を作成できるのでしょうか？　その答えは、明示的な生成です。次のことを良く考えてください。もし私たちの FILE_UTILITIES のどこかで、私たちが、私たちは VECTOR_PROCESSOR クラスからのサービスを必要とすることになっている、と気付くならば、私たちは、次のように、VECTOR_PROCESSOR クラスの process という実体を実例化することもできます。

   ! VECTOR_PROCESSOR ! process_file  

　このことは、たとえ process を FILE_PROCESSOR であると宣言したとしても、それは、VECTOR_PROCESSOR として生成（実例化）してもよい、ということを意味します。この機構は、たとえその記述が延期されたかもしれないとしても、初期の分析をサポートし、クラスを実際に使用することを可能とすることに関しては、素晴らしい柔軟性を提供します。明示的な生成は、実体を、その実際の延期された型の子孫である型として、実例化だけができます。上記で、VECTOR_PROCESSOR が FILE_PROCESSOR の子孫であるから、コンパイラによって生成されることになるエラーは一つもありません。

8.3 私のクライアントに何を告げますか?

　これを読むコースの間、最初に混乱しているように思えたかもしれない、Eiffel の特性を観察できたかもしれません。大部分の伝統的な言語では、クラスを実装するときに、二つの別のファイルを書くことが慣例になっています。定義（ヘッダー）モジュールと、実装モジュールです。定義モジュールは、誰かが実装モジュールで実装したかもしれないソフトウェアを使用したいと思っているクライアントへ与えられるものです。Eiffel は、クライアントに対してどんな機能を利用できるのかを記述する能力を、プログラマーにどのように提供しますか？　提供しません。

　言語自体は、これを達成することに対する機構を何も提供していません。そして、私たちがお見せするように、合法的にそうです。Bertrand Meyer による Eiffel の公式な記述 "Eiffel: The Language" (略して ETL)では、言語処理ツールがこれを達成するために提供される、と提案しています。このツールは、完全なクラスのテキストを与えられるべきであり、その仕事は、そのクラスの平坦な書式<flat form>を出力することです。この平坦な書式では、クラスの要点だけを提供します。その要点とは、クラス名、それが延期されているか拡張されているか、すべての特徴と誰へ利用可能なのか、すべてのルーチンの事前条件と事後条件、そして、存在することもあるどのクラスの不変条件もです。この平坦なファイルは、そのクラスによって導入された特徴に加えて、そのクラスの継承された特徴のすべてを含みます。

　平坦な簡潔<flat-short>書式と呼ばれる第二の形式は、平坦な書式と類似した結果を出力することになりますが、継承した特徴を排除して、そのクラス自体が導入する特徴のために結果を出力するだけでしょう。

　これらの書式は、その形式は ETL で完全に文書化されており、プログラマーが、構築すべきシステムの実装の詳細を用いて自分を関係させることを容易にさせる一方で、クラスについての本質的に冗長な情報を省くための奮闘を取り除きます。

8.4 Eiffel の未来

　この章で、私たちは、分析と設計の最中に、どのように Eiffel を使用することになるか、どのようにスムーズに実装へ移行するための機構を提供するか、をお見せしました。この最後の章は、いま、この文書としての終わりに来ています。私たちは、私たちがソフトウェア工学に関する Eiffel の重要性と利点を成功裏に示せた、ということを願っています。Eiffel を現在サポートしている人々によって以前行われた努力を言及せずに終わるべきではないでしょう。私たちは、このグループのための場所を、ここに用意しました。

　Eiffel の未来のために責任のある人々のグループは、正確には NICE として知られています（私は、彼らは本当にナイスでもある、と思っています！）。NICE とは、Eiffel のための非営利の国際的コンソーシアム（Non-profit International Consortium for Eiffel）のことです。NICE は、Eiffel の商用的な面に対して、技術的な面へ捧げられた、単独のグループです。まさに今、Eiffel の誠実な従者（著者も含む）は、次のように願っています。このコンソーシアムは、今もそうであるように、Eiffel を簡潔で、単純で、そして強力なものとして維持していくために、そのパワーであらゆることを行っていくでしょう。そのため、このコンソーシアムは、より最新の言語に腐食した組織と組織に類するものによる冗長な追加の氾濫への犠牲を出さないでしょう。

　Eiffel の未来は、明るく開かれています。もし正当な人々が言語に関係する重要な決定を聡明かつ賢明に為し得る位置に置くならば、Eiffel は、ソフトウェア産業の問題を一つの素早い急降下で解くことになります（そう私たちは願っています）。

　その無限の可能性は、それにも関わらず、近い将来と遠い将来に著者らの企てになるでしょう。私たちは、この刺激的な努力において、読者が私たち、そしてその多くの従者に関与することになることを願っています。