このドキュメントでは、NaturalX インターフェイスおよび専用の Natural ステートメントセットを使用するコンポーネントベースのプログラミングについて簡単に紹介します。
次のトピックについて説明します。
コンポーネントアーキテクチャに基づくソフトウェアアプリケーションには、従来の設計よりも多くの利点があります。 例えば、次のような利点があります。
迅速な開発。 プログラマは、事前に構築されたコンポーネントからソフトウェアをアセンブルすることによって、アプリケーションをより速く構築できます。
開発費の削減。 プログラムのインターフェイスの共通のセットを用意することによって、コンポーネントを完全なソリューションに統合するための労力が少なくなります。
柔軟性の向上。 アプリケーションを構成しているコンポーネントの一部を交換するだけで、社内の各部門に合わせたソフトウェアのカスタマイズが容易になります。
メンテナンスコストの削減。 アップグレードの際は、多くの場合、アプリケーション全体を修正するのではなく、コンポーネントの一部を交換するだけで済みます。
容易な配布。 各コンポーネントには、データ構造と機能が配布可能なユニットにカプセル化されています。
NaturalX を使用すると、コンポーネントベースのアプリケーションを作成できます。
NaturalX は DCOM と連携して使用できます。 これにより、次のことが可能になります。
使用するコンポーネントに他のコンポーネントからアクセスします。
ローカルまたはリモートのサーバーでこれらのコンポーネントを実行します。
Natural プログラム内からプロセスおよびマシン境界を経由して、さまざまなプログラミング言語で書かれたコンポーネントにアクセスします。
既存の Natural アプリケーションに（準）標準化インターフェイスを提供します。
企業がこれらの利点をどのように利用できるかをシナリオで説明すると、次のようになります。 ある企業が、コンポーネントを使用するアプリケーション設計に基づく新しい販売管理システムを導入します。 アプリケーションには多数のデータエントリコンポーネントがあり、各セールスポイントに 1 つずつ割り当てられています。 ただし、これらすべてのセールスポイントでは、サーバー上で実行する共通の税金計算コンポーネントが使用されています。 税法が変更された場合は、各サイトでデータエントリコンポーネントを変更するのではなく、税金コンポーネントを更新するだけで済みます。 また、ネットワークプログラミングや、異なる言語で記述されているコンポーネントの統合について悩む必要がないため、プログラマの作業は容易になります。
このセクションでは、次のトピックについて説明します。
NaturalX はオブジェクトベースのプログラミングのアプローチに従っています。 このアプローチの特徴は、対応する機能を持つデータ構造を複数のクラスにカプセル化することです。 カプセル化は、配布を容易にするための基礎となります。 オブジェクトモデルに基づくソフトウェアコンポーネントの相互運用に関する（準）標準があることから、オブジェクトベースのアプローチは、プログラム、マシン、およびプログラミング言語の境界を越えてソフトウェアコンポーネントを相互運用可能にするための優れた方法でもあります。
オブジェクトベースのアプリケーションでは、各機能はオブジェクトから提供されるサービスであるとみなされます。 各オブジェクトは特定のクラスに属します。 クライアントは、サービスを使用して、ビジネスタスクを実行したり、さらに複雑なサービスを構築して他のクライアントに提供したりすることができます。 したがって、NaturalX でアプリケーションを作成する基本手順は、アプリケーションを形成するクラスを定義することです。 多くの場合、各クラスは例えば、銀行口座、航空機、出荷など、当該アプリケーションが処理する実際の物事に単純に一致します。オブジェクト指向の設計については広範な優れた文献があります。また、十分に実証された多くのメソッドを使用して、特定のビジネスのクラスを識別することができます。
クラスを定義するプロセスは、大まかに次の手順に分けることができます。
クラスタイプの Natural モジュールを作成します。
DEFINE CLASS ステートメントを使用して、クラスの名前を指定します。 この名前は、このクラスのオブジェクトを作成するためにクライアントが使用します。
DEFINE DATA ステートメントの OBJECT 節を使用して、クラスのオブジェクトが内部的にどのように表示されるかを定義します。 データエリアエディタを使用して、オブジェクトのレイアウトを記述するローカルデータエリアを作成し、このデータエリアを OBJECT 節に割り当てます。
これらの手順の詳細は、「オブジェクトベースの Natural アプリケーションの開発」に記載されています。
クラスは、クライアントに役立つサービスを提供する必要があり、このサービスはインターフェイスを使用して行われます。 インターフェイスは、メソッドとプロパティのコレクションです。 メソッドは、クライアントによって要求されたときにクラスのオブジェクトが実行できる機能です。 プロパティは、クライアントが検索したり変更したりできるオブジェクトの属性です。 クライアントは、クラスのオブジェクトを作成し、そのインターフェイスのメソッドとプロパティを使用することによってサービスにアクセスします。
インターフェイスを定義するプロセスは、大まかに次の手順に分けることができます。
INTERFACE 節を使用して、インターフェイス名を指定します。
インターフェイスのプロパティを PROPERTY 定義で定義します。
インターフェイスのメソッドを METHOD 定義で定義します。
これらの手順の詳細は、「オブジェクトベースの Natural アプリケーションの開発」に記載されています。
単純なクラスにはインターフェイスが 1 つしかありませんが、1 つのクラスに複数のインターフェイスがある場合もあります。 この機能によって、クラスの同じ機能面に属しているメソッドとプロパティを 1 つのインターフェイスにまとめ、別の機能面を処理するために異なるインターフェイスを定義できます。
例えば、Employee（従業員）クラスには、従業員の管理面に関するすべてのメソッドとプロパティが含まれる Administration（管理）インターフェイスを定義することができます。 このインターフェイスには、Salary（給与）、Department（部門）の各プロパティと、TransferToDepartment メソッドを含めることができます。 もう 1 つのインターフェイスである Qualifications（資格）には、従業員の資格に関する面を含めることができます。
1 つのクラスに複数のインターフェイスを定義することは、クラスとインターフェイスのより高度な設計方法であるインターフェイス継承を使用するための最初の手順です。 これにより、異なるクラスで同じインターフェイス定義を再利用できるようになります。 Manager（経営者）クラスがあると仮定してください。このクラスは、資格については Employee クラスと同様に処理されますが、管理に関しては違う方法で処理される必要があります。 このことは、両方のクラス内に Qualification インターフェイスを定義することによって実現できます。 このような処理には、特定のオブジェクト上で Qualification インターフェイスを使用するクライアントが、オブジェクトが Employee と Manager のどちらを表しているのかを明示的にチェックする必要がないという利点があります。 オブジェクトのクラスを知らなくても、同じメソッドとプロパティを単純に使用することができます。 また、プロパティまたはメソッドが同じインターフェイス定義で提示される場合は、2
つのクラス内で異なる方法で実装することもできます。
インターフェイス継承を使用するプロセスは、大まかに次の手順に分けることができます。
INTERFACE ステートメントを使用して、1 つ以上のインターフェイスをクラスに直接定義するのではなく、コピーコードに定義します。
INTERFACE ステートメントの METHOD と PROPERTY の定義に IS 節を含める必要はありません。 この時点では、メソッドとプロパティに実装を割り当てずに、インターフェイスの外部的な外観だけを定義します。
INTERFACE 節を使用して、インターフェイスを定義したコピーコードを、インターフェイスを実装する各クラスにインクルードします。
METHOD ステートメントと PROPERTY ステートメントを使用して、インターフェイスを実装する各クラス内のインターフェイスのメソッドとプロパティに実装を割り当てます。
