ホワイトペーパーとアナリストレポート

新規アプリケーションの迅速な開発に向けての戦略

Terry Ragon
Chief Executive Officer
InterSystems Corporation

InterSystemsは、アプリケーション開発に対して、一般的な1つの開発理論に厳密に固執するのではなく、柔軟で現実的なアプローチを取ることを強く推奨しています。このホワイト・ペーパーで提唱する助言は、当社のこれまでの経験に基づいたものです。しかし、企業のニーズや意向、方針はそれぞれ異なるため、InterSystemsは、各プログラマが自分に最適な開発手法を採用することを提案します。Cachéがサポートする開発手法は幅広く、ここで推奨するものだけに限られません。

新規アプリケーションでのオブジェクトの使用

InterSystemsが新しいデータベース・アプリケーションの構築にオブジェクトの使用を推奨するのは、以下のような理由によります。

オブジェクトではよりリッチなデータ構造がサポートされるため、現実世界のデータをより自然に記述できます。
クラスをカスタマイズすることにより標準クラスを簡単に置換できるため、アプリケーションのカスタマイズと、新規リリースのアプリケーション・サポートが容易です。この機能は、様々なカスタマイズ版のサポートが必要となるVAR(不可価値再販業者)では特に重要です。
カプセル化によるブラック・ボックス・アプローチは、アプリケーションの他の部分に影響することなく、開発者がオブジェクトの内部動作を拡張できることを意味します。
オブジェクトでは、異なるテクノロジや異なるアプリケーションに接続する方法が簡略化されます。
オブジェクト・テクノロジは、Web開発を効率化するJavaや、GUIベースのユーザ・インタフェースとの高い親和性を持ちます。
新しいツールの多くが、オブジェクト・テクノロジを前提に構築されています。
オブジェクトでは、ユーザ・インタフェースとアプリケーションの残りの部分が適切に分離されます。そのため、新しいユーザ・インタフェース・テクノロジ(Webや現時点では予測できない未来のテクノロジ)の導入が必要になっても、開発者は大半のコードを再利用できます。
オブジェクトは、データベース・オブジェクトやごく短期的な("一時")オブジェクトに向いています。サイズの小さい一時的なストレージには、1つまたは少数の変数や配列を単純に使用するほうが簡単な場合も多くありますが、そうしたケースでは最も実用的と思われるものを使用します。
通常の場合は、ほとんどのデータ・ストレージにオブジェクトが使用されますが、"グローバル参照"を使用してCaché多次元データ・サーバから直接的にデータを読み書きするほうが適切な場合もあります。このケースが該当するのは、構造体の要件が非常に専門的かつ特殊でオブジェクトやSQLによるアクセスが不要な場合や、最高レベルのパフォーマンスが求められる場合などです。

開発プロセスの全容 - 反復アプローチ

通常、開発は、以下のことを行う反復プロセスとなります。

プロパティとメソッドの仕様を含む、データベース・クラスの設計
コードの記述
ユーザ・インタフェースの構築

理論的には、アプリケーションのすべての局面を完全に設計してからコードの記述に進むことが効率的と思われますが、実践的には、アプリケーションがユーザの真のニーズと一致しなかったり、いつまでたってもアプリケーションが完了しなかったりという設計停滞に陥ることになります。InterSystemsは、反復プロセスを強く推奨しています。

設計段階の綿密さが重要であるという確信に変わりはありませんが、アプリケーションが複雑な場合は、開発が進むにつれて実際の設計要件がより明確になるということと、有効なアプリケーションの構築にはユーザからのフィードバックに基づいた変更が必要になるということも確信しています。Caché の持つ利点の1つは、コード開発の迅速さとコード変更の容易さによって、フィードバックに基づいた設計変更の実装とコード断片の書き直しを簡単に実行できることです。開発プロセスはより少ないプログラマでより迅速に進行し(Cachéの開発生産性の高さによって)、ユーザのニーズにより的確に対応したアプリケーションが構築されます。

実際、Cachéがもたらす迅速な開発能力は、プロジェクトがより少ないリソースでより迅速に完了するだけにとどまらず、他の方法では完了できないようなアプリケーションの開発支援にまで及びます。ソフトウェア・プロジェクトにプログラマを増員すると、より多くの問題に対して、より多くのプログラマの共通理解と同意事項が必要になると同時に、それぞれの全体把握がより困難になることによって、大幅に複雑度が増すことはよく知られています。その結果、より多くのリソースを利用できるにもかかわらず、少ない人数で開発する場合よりも、市場投入に時間がかかったり、信頼度が低下したりする場合があります。ときには、プロジェクトが完了しなくなることさえあります。

InterSystemsは、基本的なデータベース設計から始めることを推奨します。データベース設計が完了したら、通常は、ビジネス・ロジックとデータベース・ロジックをユーザ・インタフェース・コードと並行して記述します。一部のケースでは、対応するユーザ・インタフェース・コードよりも前に主要なビジネス・ロジック・コードを記述することにより、送信請求が必要な情報を最初に決定すると効率的な場合もあります。また、プログラマの中には、ユーザ・インタフェース・コードから記述することにより、最初にアプリケーションの性質とルック・アンド・フィールを決定する方法に慣れている人もいます。この代替策は、データベースのプロパティが比較的少ない場合やアプリケーションが単純な場合には適用できますが、より複雑なアプリケーションでは、データベース定義から開始する方法を推奨します。実際、これらはすべて反復プロセス内で実行され、クラスとコードは徐々に洗練化されます。大切なことは開始することです。

アルゴリズムのロジック・フローとコードが持つその他の複雑な局面を簡略的に図式化したアウトライン図は、非常に有用です。アウトライン図は、設計段階でのアプリケーションの信頼度と全体的な把握度を高めると同時に、コード記述を容易にします。また、プライベート・プロパティやメソッド・シグニチャの仕様設計が促進されます。一般的に、図式化後直後、つまり開発者がアルゴリズムを理解しているうちに、アルゴリズムをコード化すると効果的です。これが、開発に反復アプローチを取り入れることを推奨するもう1つの理由です。

モデリング・ツールの使用について

Cachéでは、Rational SoftwareのRoseを始めとする多数のモデリング・ツールがサポートされており、これらのモデリング・ツールは、広範囲に及ぶ設計フェーズを好む多くの組織によって数多く利用されています。これらのツールは、データベース・プロパティなどの構造体の静的な設計に専念するときに有用で、使用方法も容易です。

しかし、モデリング・ツールがより効果的なのは、リレーショナル・データベースに対して使用するときであり、本質的にリッチな現実世界のデータをフラットなリレーショナル・テーブルに分解することにより生じる、テーブル間の過剰なリンク関係をモデル化する場合に役立ちます。この分解は、Cachéでは必要ありません。

InterSystemsは、Cachéでのモデリング・ツールの使用を一般的に推奨していません。その代わり、以下のことを推奨しています。

Caché Objectアーキテクトを直接使用して、最初に、一部の主要クラス、特に主要なデータベース・クラスのデータ構造(さらには、必要に応じて最も重要なメソッドのシグニチャ)を定義します。
次に、コードの記述を開始します。
反復プロセスによって、設計を段階的に拡張していきます。

このアプローチを取る理由は、以下の通りです。

オブジェクトの性質とその構造についての理論的な議論に時間をかけるのを防止できます。抽象的なモデリングに時間をかけすぎたことが原因で、プロジェクトが失敗することもあります。
メソッド・コードの性質と機能、また必要なメソッドとプライベート・プロパティは、コードの記述が進むにつれてより明確になります。開発サイクルの初期の段階には、それに応じて具体化すべきものがあります。
このアプローチでは、設計とコード記述の両方で単一のツールを使用します。開発者は、設計の進行に伴って必然化する、開発作業と特定の設計ツール間の絶え間ない調整のオーバーヘッドから解放されます。

Cachéの使用経験がない場合は、できるだけ早くコード(メソッド)の記述を開始して製品に慣れることを強く推奨します。

このアドバイスは一般的ではありませんが、より優れたアプリケーションをより迅速に開発することに役立つと確信しています。反復プロセスによって、経験の浅い開発者でも、開発が進行するにつれて古くなり適合しなくなる事前定義構造にとらわれることなく、継続的に設計を精密化できます。また、実践的な経験が少ない場合に生じる傾向がある作業停滞や分析過多を防止できます。

Cachéでのモデリングとデータ設計

オブジェクトの設計段階では、オブジェクトの性質やその実装メソッドについての抽象的な議論に陥ることがよくあります。これは時間の消費につながるだけでなく、結果として作成されるメソッドはアプリケーションの実際的なニーズに合わない傾向があります。InterSystemsは、大半のメソッドが持つ要件と性質は、コーディング・プロセスを通してより明確になるということを確信しています。

もちろん、コーディングの前に、基本的な設計が必要であることは言うまでもありません。Caché Objectアーキテクトによって、以下の項目を指定することを推奨します。

主要なデータベース・クラス(Invoices、Suppliers、Patientsなど)
それらが持つパブリック・プロパティ(つまり、他のオブジェクトからアクセス可能なプロパティ。これとは逆に、プライベート・プロパティは他のオブジェクトから隠蔽され、同一クラス内のメソッドのみがアクセスできる。)
クラス間の参照および関係(PatientのPrimaryPhysicianプロパティはDoctorを参照する、Invoice はLineItemオブジェクトと一対多の関係を持つなど。)

一般的には、プロパティの指定と同時に、そのプロパティの特性を指定しておくと効率的です(そのプロパティ値を必須とするかどうか、値を一意とするかどうか、インデックスを付けるかどうかなど)。また、計算が必要なプロパティのコード記述もこの段階が適しています (Ageプロパティの値はDateOfBirthプロパティから計算するなど)。

メソッドの名前とシグニチャの指定は、設計の初期段階で行うべきでしょうか(シグニチャには、必要な戻り値の型と入力パラメータの数と型が定義されます)。既に明確になっている重要メソッドのシグニチャは、設計の初期段階でも定義可能かもしれませんが、ほとんどのメソッドは、その要件がコーディング段階で決定されてから定義したほうが効率的です。また、メソッド・コードの記述に伴って、シグニチャが変更されることはよくあります。通常、メソッドのコード化が最も容易なのは、シグニチャの定義と同時です。

3つの3層アーキテクチャ

3層アーキテクチャについて語られるときによく見られる混乱は、以下に示す根本的に異なる3つの3層アーキテクチャが混同して語られていることに起因します。

ハードウェア配置の3層アーキテクチャ - データベース・サーバ、アプリケーション・サーバ、およびユーザ・インタフェース用の各コンピュータに、物理的に異なるコンピュータを使用することを意味します。
システム・ソフトウェアの3層アーキテクチャ - データベース・サーバ、アプリケーション・サーバ、およびユーザ・インタフェースに対応する3つのソフトウェア・レイヤを意味し、物理的に異なるコンピュータが使用されるとはかぎりません。
アプリケーション・ソフトウェア開発の3層アーキテクチャ - データベース・ロジック、ビジネス・ロジック、およびユーザ・インタフェース・ロジックの各コードを3つのレイヤに厳格に分離することを意味します。この場合も、物理的に異なるコンピュータが使用されるとはかぎりません。

Cachéでは、システム・ソフトウェアの3層アーキテクチャと、様々なハードウェア配置オプションがサポートされます。

Caché開発者は、ハードウェアの配置アーキテクチャを把握する必要がありません。単一コンピュータ上にすべてがある状態から、2層、3層、またはピアツーピアのハードウェア・アーキテクチャに移行する場合でも、ソフトウェア・モジュールの再コンパイルや再リンク付けは必要ありません。

アプリケーション・ソフトウェア開発の3層アーキテクチャ

概念的に言うと、大半のデータベース・アプリケーションには、以下の3種類の異なる機能を実現するコードが含まれます。

ユーザ・インタフェース(UI)ロジック - クライアントとサーバの各ウィンドウに適用するコードやブラウザに送信するコードなどの、入力出力操作を行うコード。これらのコードには、情報の送信請求方法や表示方法、各種I/Oイベントに対して呼び出されるビジネス・ロジック、および視覚的に応答する方法などが記述されます。
ビジネス・ロジック - 通常、アプリケーション・コードの大半を占めます。"ビジネス・ルールとビジネス・プロセス"を実装するアルゴリズム・コードが記述され、アプリケーションで実行する機能の実体となります。(ビジネス・ルールとは、例えば10万ドルを超える請求書には2人のマネージャの承認が必要となる、といったルールです。ビジネス・プロセスとは、請求書の支払いには、最初にその請求書を承認済みの発注書と照合し、次に商品と必要な管理承認が受け取り済みであることを確認し、最後に小切手の振出日を決めるなどの処理を指します。)
データベース・ロジック - ディスクとのデータの出し入れや、データベースへのクエリの実行、データベースの参照整合性の維持などを行うコード。例えば、リレーショナル・データベースに請求書をファイリングするには、多数のレコードの更新(オブジェクト・アクセスの場合はより簡単になります)と各種統計処理が必要となります。

ここ数年の間は、この3層アーキテクチャを厳守してデータベース・アプリケーションを開発するという理念が強力に推進されてきました。このモデルでは、3つのレイヤの中のどのレイヤが、他のどのレイヤにあるコードを呼び出せるかについて厳格なルールが定められています。また、特定のレイヤにある一連のクラスは、他のレイヤにある同種の名前(機能ではなく)を持つクラスと関連付けられるのが一般的です。例えば、ビジネス・ロジック・クラスのInvoice_blにSaveという名前のメソッドがある場合、そのメソッドがデータベース・ロジック・クラスのInvoice_dbにある同じ名前のSaveメソッドを呼び出すことにより、実際のファイリング操作が行われます。

3層開発に賛同する議論の要点は、3層に分割することにより、大規模なプログラマ・チームの編成が可能になることと、データベースの独立性の実現がより容易になることです。

アプリケーション・ソフトウェア開発の3層アーキテクチャの有効性について

Cachéはアプリケーションの3層開発に対応できますが、InterSystemsはこのアーキテクチャを推奨していません。その代わり、以下のアプローチを推奨しています。

ビジネス・ロジック・レイヤとデータベース･ロジック・レイヤを統合する。
UIレイヤはこれらの両レイヤから厳格に分離する。
UIレイヤはできるかぎり薄くし、コードは極力、ビジネス/データベース･ロジック・レイヤに配置する。

このアプローチを推奨するのは、以下のような合理性によります。

アプリケーションの3層開発を支持する議論の核心は、データベース・ロジック層には、データベース・プログラミングの専門知識を必要とする大量のコードが記述されるという前提に基づいています。これは、大半のデータベース機能が自動化されているCachéには当てはまりません。Cachéには、情報の入出力を自動処理する"スマート・データベース・オブジェクト"と、プログラムに埋め込む大部分のデータベース・クエリの構築を支援する"クエリ・ウィザード"が組み込まれています。また、Cachéの多次元データ・モデルでは、リッチなオブジェクトを多数のリレーショナル・テーブルに分解する必要がないため、Cachéコードは非常にシンプルです。

このように、Cachéでは、プログラマによる記述が必要なデータベース・ロジックが相対的に少なく、データベースの専門知識を持つプログラマ・グループを別に編成する必要がなくなります。また、Cachéのデータベース・オブジェクトは、強力なオブジェクト・モデルをより正確に反映できます。例えば、2つの請求書クラス(ビジネス・ロジックの請求書クラスとデータベース・ロジックの請求書クラス)を作成するのではなく、1つの請求書クラスにすべての請求書ロジックをカプセル化できます。このモデルは非常に単純化されているため、プログラミングがより迅速で、コード記述がはるかに少なくなります。また、将来的な変更がより容易になります。

一方、ユーザ・インタフェース・コードを厳格に分離することと、ユーザ・インタフェース・レイヤのコードをできるかぎり少なくすることが推奨されるのは、以下のような理由によります。

将来的なユーザ・インタフェースの追加プログラミングが容易になります。
視覚的な設計の専門家とコア・アプリケーションのプログラマ間で、プログラミングの担当分野が効果的に分離されます。
UIレイヤのクラスとビジネス・ロジック・クラス間には、密接な相関関係がありません。

UIレイヤを薄くするもう1つの理由は、Cachéアプリケーション・サーバで管理可能なビジネス・ロジックの変更に比べると、ユーザ・インタフェース・コードのインストールと将来的な置換は、システム管理にとって大きな負担となるためです。

Cachéでのデータベースの独立性

Cachéでのデータベースの独立性は、Cachéストレージ・クラスの使用によって実現されます。データベース・クラスの定義時に、プログラマは、使用するストレージ・クラスを指定する必要があります。このストレージ・クラスによって、Caché多次元データベースへの直接ファイリングと、リレーショナル・データベースへのファイリングのどちらを使用するかが決まります。リレーショナル・データベースを使用するようアプリケーションを切り替えるには、使用するストレージ・クラスを変更し(アプリケーション全体に適用される1つの論理名を再定義するだけで実行できます)、アプリケーションを再コンパイルするだけです。

ビジネス・ロジックおよびデータベース・ロジックの記述

Cachéオブジェクト・クラスは、Caché Objectアーキテクトを使用して構築、編集、およびコンパイルできます。

Cachéには"スマート・データベース・オブジェクト"が備わっているため、開発者はオブジェクトをロード、保存、または削除するメソッドを記述する必要がありません。これらの各メソッドは、クラスのコンパイル時にCachéによって自動生成されます(カスタムなデータベース・メソッドが必要な場合は、開発者が独自に記述できます)。

Caché ObjectScriptはデータベース・アプリケーションのビジネス・ロジックとデータベース・ロジックのコーディングに優れた言語で、InterSystemsはその使用を強く推奨しています。Caché ObjectScriptによるアプリケーション開発の迅速さは、他の言語をはるかに上回ります。また、Caché ObjectScriptはCaché多次元データ・サーバと密接に統合されているため、ほとんどのデータベース・アプリケーションで非常に高いパフォーマンスが実現されます。さらに、そのCachéアプリケーション・サーバとの密接な統合によって、システム管理、構成変更、実行中のシステムへのコード変更の適用などもより容易になります。

ただし、これが唯一のオプションではありません。Cachéオブジェクト・サーバはCachéオブジェクトをActiveX、Java、C++、またはCORBAオブジェクトとしてレンダリングでき、Visual Basic、Java、またはC++でのプログラミングを希望する開発者にも便宜が図られています。

また、CachéはODBC/JDBC使用のSQL経由でデータベースを公開できるため、SQLベースのプログラミング・ツールを使用することもできます。

ユーザ・インタフェースの構築

通常、ユーザ・インタフェースは、Visual Basic、Delphi、C++、Java、またはHTMLによって記述されます。これらのオプションの中では、WebベースのHTMLユーザ・インタフェース開発が最速であり、C++ベースのユーザ・インタフェース開発は他のオプションよりもかなり時間がかかることが、多くのプログラマによって報告されています。

Cachéは、そのオブジェクト・サーバを通じて多数の開発ツールと互換性があり、HTMLスクリプトは直接Caché ObjectScriptに埋め込むことができます。

Webインタフェースの開発者にとって特に魅力的なのはCaché Server Pagesであり、これによって既製のWebページ作成ツールでCachéスクリプトが使用可能になります。

開発者がユーザ・インタフェースに使用するテクノロジを決定する際に最も重要なのは、使用経験が豊富な、または習得が容易なテクノロジを選択することと、そのテクノロジがシンプルなことです。ユーザ・インタフェースのテクノロジ選択に当たっては、複雑なテクノロジを多層化することにより、複雑になりすぎないように注意する必要があります。

Webまたはクライアント/サーバ・ウィンドウのどちらを使用するか

多くの開発者にとって最も困難な選択の1つは、ユーザ・インタフェースのコードにWebまたはクライアント/サーバ・ウィンドウのどちらを使用するかを決定することです。

当社の顧客におけるこれまでの開発事例から明らかなのは、既存の端末ベース・システムがCaché上で動作可能な場合は、そのシステムを修正してCaché Server Pages と埋め込みHTMLでWebサポートにすることが、最も速くかつ最も簡単に洗練されたユーザ・インタフェースを追加する方法であることです。この方法では、多くの場合、既存コードのかなりの部分がそのまま保持されます。この方法は、ダム端末を非常にスマートで視覚的に洗練された端末で置換することに似ています。通常、このアプローチは、手続き型のアプリケーションがブラウザ・ベースになることを意味します。ただし、視覚的な洗練さとユーザによる制御能力の点では、完全にイベント・ドリブンなクライアント/サーバ・ウィンドウ・ベース・アプリケーションよりも劣るのが一般的です。

アプリケーションをまったく新規に記述する場合は、UIレイヤとビジネス/データベース・レイヤを厳格に分離し、UIレイヤをできるかぎり薄くすることが重要です。多くの場合、最終的にはクライアント/サーバ・ウィンドウとWebの両方のサポートが求められるようになることもありえます。一般的に、WebベースのUIレイヤには、多くの場合に開発がより速く、ブラウザ・ベースであるためより幅広くアクセスできるという利点があります。また、WebベースのUIレイヤは、Webを重視した広範なマーケット・ニーズと合致しますが、クライアント/サーバ・ウィンドウの方が視覚的には洗練されています。

アプリケーションの配置と保守

ハードウェア・プラットフォームおよびオペレーティング・システム

通常、Cachéアプリケーションは、Windows 95/98、Windows NT、すべての主要なUNIXプラットフォーム、OpenVMS、Linuxなどの、各種ハードウェア・プラットフォームおよびオペレーティング・システム上で同様に動作します。

ハードウェア構成

Cachéアプリケーションは、再プログラミングまたは再コンパイルしなくても、1層、2層、3層、またはピアツーピアの各ハードウェア構成に配置できます。非常に大規模なシステムの場合は、複数のCachéアプリケーション・サーバと複数のCaché多次元データ・サーバを構成できます。

通常、クライアントは1つのCachéアプリケーション・サーバにのみ接続し、そのアプリケーション・サーバが適切なデータ・サーバからのデータの取得に責任を持ちます。

一般的に、アプリケーション・サーバが同一コンピュータ上にあるデータにアクセスする場合は、オーバーヘッドがはるかに少なくてすむため、データ・サーバとアプリケーション・サーバに別々のコンピュータを割り当てる必要が本当にないかぎり、両サーバは同一コンピュータ上に配置することを推奨します。

実行中のシステムへのアプリケーションのインストールと変更の適用

アプリケーションの記述が完了したら、そのインストールと将来的な変更が必要になります。何千ものPCと複数のサーバがある環境では、どのテクノロジにとっても、これは大きな問題です。

Cachéでは、アプリケーション・ソフトウェアのインストールが簡略化されています。Caché ObjectScriptコードのインストールが必要となるのは、1つのデータ・サーバのみです。他のコンピュータは、DCPを使用してコピーを取得し、それをキャッシュします。

Caché ObjectScriptルーチンの変更を実行中のシステムに適用するには、そのコードを持つ1つのデータ・サーバに変更したソース・コード・ルーチンをロードするだけです。ソース・コードは自動的にコンパイルされ、改訂ルーチンの再ロードが必要なことがアプリケーション・サーバに通知されます。もちろん、これらの変更の適用には注意が必要です。元のバージョンから別のルーチンに呼び出しを行ったプロセスが変更されたルーチンに戻ろうとすると、エラーを受け取ります。