 目次 |
 索引 |
|
|
|
|
アプリケーション開発の最も重要な局面の1つは、アプリケーションを構成するモジュールの管理です。大規模なアプリケーションは、文字どおり何千ものモジュール、何万行ものコードで構成されることがあります。さらに、プロジェクト全体に重要なコンパイルされてアプリケーションとしては組み込まれないモジュール（設計の仕様、テスト・スクリプトおよびドキュメントなど）についても、その進捗状況を追跡し、管理する必要があります。
この章では、Forms DeveloperおよびReports Developerを使用してアプリケーション開発プロセスの管理を支援する方法を説明します。
アプリケーション開発には、通常、次の4つのフェーズがあります。
アプリケーションのサイズが増え、複雑になるにつれ、この4フェーズが繰り返し行われ、生成される情報（実際のコード、バグ・レポート、改善要求など）の量が増えます。それでもなお、最終成果物（顧客がインストールするアプリケーション）の、完全性を保証できるように、すべてのフェーズのすべての入力や成果物を追跡および更新できることが必要です。
この章では、作成したアプリケーションのコード・ベースをForms DeveloperまたはReports Developerを使用して管理し、バージョンの整合を維持する方法を説明します。
開発プロジェクトは、管理作業を次の2つのカテゴリに分割できます。
Forms DeveloperおよびReports DeveloperのコンポーネントであるProject Builderを使用すると、ソフトウェア構成の管理作業が容易になり、ユーザーおよびユーザーのチームは、アプリケーションの設計、コーディング、テスティングなどの本来の目的に集中することができます。
ソフトウェア管理作業を簡素化するため、Project Builderには次の方法があります。
これらの機能の詳細は、1.1.3項「Project Builderの利点の理解」で説明します。ただし、Project Builderの用語によくわからないものがある場合は、次に進む前に1.1.2.1項「Project Builderの用語について」を読んでください。この項では、Project Builderの機能説明に関するコンテキストを記述した基本用語の一部が定義されています。
Project Builderは、次に示す、プロジェクトおよびサブプロジェクトの概念に基づいています。
Project Builderを十分に理解するには、プロジェクトやサブプロジェクトの他に、次の用語も重要です。
.TXTはテキスト・ファイルです。Project Builderでは、Form Builderモジュール、テキスト・ファイル、Cソース・ファイルなどの、一般的に使用される多数のファイルのタイプが事前定義されています。また、タイプ・ウィザードを使用して他のアプリケーションのタイプを定義することもできます。
項目はファイルそのものではなく、ファイルの説明であることを覚えておいてください。プロジェクトから項目を削除すると、そのファイルがプロジェクトの一部ではなくなったことのみがProject Builderに通知されます。ファイル自体は削除されていません。
ORACONNECTマクロに挿入されます。その後、自動的にログオンできるようにマクロ内の情報がアクションに挿入されます。
スクリプト自体を編集せずに、スクリプトまたはバッチ・ファイル内の環境変数を使用して、スクリプトのアクションを簡単に変更することがあるように、アクション自体を変更しなくてもマクロを使用してアクションをカスタマイズできます。たとえば、作成したアプリケーションのコンパイルをデバッグ・モードで行うか、または最適化モードで行うかを決めるためにマクロを定義する場合があります。アプリケーションの配布用バージョンの作成段階では、デバッグ・フラグを使った生成（Build）コマンドのタイプをすべて検索して変更するのではなく、単に1つのマクロの定義を変更してデバッグをオフにするのみで済みます。
Project Builderインタフェースには、プロジェクトを構成する項目の操作に使用する、次の3つのツールがあります。
図1-2には、これら3つのツールがすべて示されています。
アプリケーション開発の作業が円滑に進むように役割が必要です。プロジェクト・マネージャ、開発マネージャおよびチーム・リーダーなどは開発グループで共通の役割分担であり、定義は不要です。ただしProject Builderには、プロジェクト管理者という新しい役割分担があります。
プロジェクト管理者はプロジェクトを作成しプロジェクトを開発者が利用できるようにします。プロジェクト管理者はグローバル・レジストリをメンテナンスし、必要に応じてそれを変更しチームの開発者にその変更をエクスポートします。また、テスト環境などの異なる環境、または異種プラットフォーム間の開発の場合はその他のプラットフォームにプロジェクト情報をエクスポートすることもあります。
プロジェクトの管理時にプロジェクト管理者が行う作業は、次のチーム・メンバーの役割分担に影響することがあります。
もちろん、各チーム・メンバーの正確な役割分担は開発グループによって異なります。また、チームの1メンバーが複数の役割分担を果たす場合があります。たとえば、チーム・リーダーがプロジェクト管理者、または開発者がソース制御の担当者ということもあります。
Project Builderの基本用語を理解したら、Project Builderがもたらす利点について調べます（不明な用語がある場合は、1.1.2.1項「Project Builderの用語について」を参照してください）。
モジュールを同じプロジェクトに追加するだけで、アプリケーション内のすべてのモジュールをそのアプリケーションに関連付けることができます。これによって、大規模なアプリケーションを1つのエンティティとして追跡したり、モジュール間の依存関係を判別することなどができます。
Project Builderには、デフォルト・アクション（オープン、編集または印刷など）がすでに割り当てられた、拡張子のタイプ・リストがあります。モジュールを選択して、マウスの右ボタンをクリックすると、そのタイプに関連付けられたアクションがポップアップ・メニューに表示されます。デフォルトでは、タイプ定義に含まれているアクションは、プロジェクト内のそのタイプのモジュールすべてに適用されます。また、これらのアクションを修正したり、これらに追加することもできます。
アクションは、単なるコマンド文字列です。実際のコマンド文字列を使用してアクションを定義する利点（もちろん、簡単なだけでなく）の1つは、概念上アクションが数種類のタイプと関連付けられることです。たとえば、Word文書の編集とテキスト文書の編集は、概念上非常に似ていますが、異なるツールが必要です。Project Builderでは、2種類のタイプの同じ編集（Edit)コマンドを関連付けられますが、各タイプのコマンド文字列が異なるため、混乱することはありません。このように、処理しているモジュールのタイプにかかわらず、1つのコマンドによって該当するアクションが実行されます。
どのモジュールが他のどのモジュールに依存するかを知ることは、変更があった場合に、再コンパイルしなければならないモジュールを決定するのに必要です。また、変更の影響を管理するのにも重要です。たとえば、あるライブラリを変更するとどのフォームが古くなるか、などです。
Project Builderでは、タイプ定義にモジュール・タイプの依存関係が含まれています。このようにして、プロジェクト内の既存のモジュール間の依存関係が認識されます。モジュールへの変更も追跡できるので、変更されたモジュールおよびそれに依存したモジュールが自動的に再コンパイルされます。
実際には、Project Builderによりプロジェクト内にまだ存在しない依存関係が認識され、それらのマーカーが作成されます。これらのマーカーは、暗黙的項目と呼ばれています。たとえばプロジェクトに、Project Builderの「Form Builderドキュメント」で定義した.FMBファイルが含まれているとします。「Form Builder実行モジュール」（.FMXファイル）は存在しない、つまり、まだ生成されていない可能性があります。しかし、Project Builderでは.FMBファイルの存在によってこの.FMXファイルの存在を暗黙的に認識できるため、それをマークするための暗黙的項目が作成されます。
暗黙的項目の存在を判別するために、Project Builderでは、各定義済みタイプの「配布可能タイプ」プロパティの値と、「<タイプ>からビルド」アクションに必要な入力項目、つまりソースとが相互に関連付けられます。前述の例では、「Form Builderモジュール」タイプの「配布可能タイプ」プロパティは「Form Builder実行モジュール」、つまり.FMXとして定義されています。Form Builder実行モジュール用に定義された「<タイプ>からビルド」アクションは、「FMBからビルド」になります。これは、.FMBファイルが.FMX ファイル作成用の入力項目で、逆に.FMXファイルは.FMBソースのターゲットであることを意味しています。
暗黙的項目の連鎖は複数のファイルから構成されます。たとえば、ライブラリ・ファイルにCソース・ファイルを追加するとします。この場合、Project Builderによってあるファイル形式から別のファイル形式（オブジェクト・ファイルなど）への「<タイプ>からビルド」アクションの完全パスを取得するために、その他のすべてのタイプのモジュールが追加されます。
Project Builderによって、コンパイル可能なモジュールとその結果作成された実行プログラムの間にのみ存在する依存関係が検出されますが、モジュールに依存する項目の下にあるプロジェクトへモジュールを追加すると、手動で依存関係を設定できます。たとえば、.FMBファイルがPL/SQLライブラリに依存している場合、.FMBの下にあるプロジェクトに.PLLを追加することで、その依存関係がProject Builderで認識されます。
Project Builderを使用すると、最も頻繁に使用される接続文字列をすべて定義し、自分のユーザー・レジストリ内の接続ノードの下にそれらの定義を格納できます。さらに、接続ノードから接続をドラッグしてモジュールにドロップすると、接続をモジュールに割り当てられます。そのモジュールを編集する必要がある場合、たとえばフォームであれば、プロジェクト・ナビゲータからそのフォームを選択し、ポップアップ・メニューから「編集」を選択できます。Project Builderでは、Form Builderのオープンとデータベースへの接続が自動的に行われます。
Project Builderでは、最終的なインストールパッケージに含めるモジュール（たとえば、.EXEファイル、.DLL ファイル、.HLPファイルなど）を容易に判断および追跡できます。配布用のファイルにマークを付けるには、「配布ファイル」プロパティを「はい」に設定します。インストール・パッケージの作成準備が整うと、配布ウィザード・アクションによって、「配布ファイル」プロパティを「はい」に設定したすべてのモジュールが1つの単位にパッケージされます。
注意: タイプまたは個別のプロジェクト項目について、「配布ファイル」プロパティを設定できます。
Project Builderによって、プロジェクトに関する情報を他のチーム・メンバーまたは他のプラットフォームにエクスポートできます。タイプ、アクション、マクロ、およびプロジェクト・レジストリ・ファイルについての情報は、カスタマイズしたすべての情報を含め、他の環境およびプラットフォームにインポートできるテキスト・ベースのエクスポート・ファイルに書き込まれます。これによって、異種プラットフォーム間の開発とテストが可能になります。
次の数種類の方法で、Project Builderユーザー・インタフェースからその他のツールにアクセスできます。
Forms DeveloperおよびReports Developerでは、次のソース制御パッケージへのインタフェースを提供しています。
また、他のソース制御ツールを指し示すように、Project Builderで提供されているこのソース制御アクションを変更すれば、他のソース制御ツールも使用できます。
さまざまなソース制御パッケージが使用可能であり、Forms DeveloperおよびReports Developerと併用できるため、プロジェクトのソース制御を行う様々な方法について、この章ですべて扱うことはできません。ただし、総合的なガイドラインは、該当箇所に記述されています。
よいアプリケーションを作成するには、設計が重要であると繰り返し述べられてきました。設計フェーズにおける成果物には、設計書、仕様書、会議の議事録、ユーザー・インタフェース・プロトタイプ、顧客の調査結果（新規アプリケーションの場合）、ユーザー・テスト、および改善に関する要求のリスト（アプリケーションの改訂の場合）など、プロジェクトに追加され、追跡されるすべての文書が含まれます。
これは、開発作業に向いているプロジェクト管理者を設計プロセスの初期に決め、ただちにプロジェクトの作成を開始する必要があることを示します(プロジェクト管理者の役割分担に関する詳細は、1.1.2.2項「Project Builderが既存の開発の役割分担に与える影響」を参照してください)。この項では、設計及び開発フェーズでプロジェクトを管理するためにProject Builderを設定する場合のプロジェクト管理者および開発チームのメンバーの役割分担を説明します。特に、この項では、次のことを説明します。
注意: Project Builderによる簡単な作業の実行に関する手順は、Project Builderのオンライン・ヘルプに書かれているため、この章では説明しません。
Project Builderは、自動的にORACLE_HOME\PJ10にインストールされます。このディレクトリにある重要なファイルは、次のとおりです。
Project Builderのインストール中に処理する最も重要な問題は、どのようにしてチーム・メンバーもこれらのさまざまなファイルを使用できるようにするかということです。1.2.1.1項「プロジェクトおよびユーザー・レジストリのインストール」 に、オプションを説明します。
Project Builderは、セキュリティ用のプロトコルを共有するネイティブ・ファイルに依存します。したがって、プロジェクト・ファイルは不慮の変更に対処できないことがあります。これは、グローバル・レジストリおよびユーザー・レジストリの構成方法を決める際に考慮に入れる必要があります。表1-1に、使用可能なオプションをリストします。
次の項では、開発者チームへ配布する1つのプロジェクトの作成について説明します。ただし、これはグループにとって最適なオプションではない可能性があります。開発中のアプリケーションが非常に大きい場合、またはコンポーネントがチーム・メンバー間で分割されている場合は、複数に分割したより小さなプロジェクト、つまり各開発者あるいは開発グループが責任を負う各プロジェクトの内容を作成するように選択しても構いません。
1つのプロジェクトを分配するように決めた場合、Project Builderのプロジェクトでは、指定位置に存在しないモジュールへのポインタが受け入れられることに注意してください（プロパティ・パレット内の情報を調べると、モジュールの存在を判別できます。存在しない場合は、「作成/修正時刻」および「ファイル・サイズ（バイト）」がブランクになっています）。これは、チーム・メンバー全員ですべてのモジュールを使用可能にしなくても、1つの大きなプロジェクトを分配できることを意味しています。
プロジェクトの作成は、各開発チーム・メンバーと同様にプロジェクト管理者も参加する必要がある、継続した作業です。この項では、各役割分担での責任の特徴を説明します。
プロジェクト管理者としてプロジェクト・レジストリ・ファイルを作成し、プロジェクトに何を含めるかを決定します。Project Builderに付属のプロジェクト・ウィザードを使用してプロジェクトを作成する場合、プロジェクト・レジストリ・ファイルを作成してさまざまなプロパティを手動で編集する場合でも、必ず次の作業を完了する前に事前計画を立ててください。
次のトピックでは、これらの各作業を完了するための推奨事項を説明します。
プロジェクト・ウィザードには、プロジェクトの作成用に使いやすいインタフェースがあります。また、プロジェクト・ウィザードを使用せずに（ツールバーの「新規プロジェクト」ツールを使用して）新規プロジェクトを作成し、プロパティ・パレットでプロジェクトのプロパティを設定することもできます。
最も簡単な方法は、新規プロジェクトがグローバル・レジストリの情報をそのまま継承するプロジェクト・レジストリ・ファイルを持つデフォルトの設定の場合です。その他の場合はまずありません。Project Builderでは次のトピックで説明しているように、作成したプロジェクトを追跡し記録する前により詳しい情報が必要です。
ステップ1a: プロジェクトのディレクトリ構造の設定
プロジェクトのディレクトリ構造は、非常に重要です。たとえばプロジェクト・ディレクトリの子ではない、あるディレクトリに置かれたモジュールをプロジェクトが持つとします。そこで、検索のアクションを作成し、プロジェクト・モジュールを変更するとします。どのようにして“親なし”のモジュールを検索すればよいでしょうか。ハードコードされたパスを用いて代理のアクションを作成しますか。それでは移植性がありません。ルートから検索しますか。それも効率的ではありません。
推奨事項:
モジュールをプロジェクトに追加する標準的な方法は、「プロジェクトにファイルを追加」ダイアログです。追加するモジュールがプロジェクト項目のデフォルト・ディレクトリにない場合、ダイアログには必ずフルパスが挿入されることに注意してください。その場合は、相対パス名が使用されます。
ステップ1b: モジュールの追加
ディレクトリ構造の計画を立てたら、プロジェクトにモジュールを追加できます。
推奨事項: 可能であれば、プロジェクトの編成に役立つサブプロジェクトを常に使用してください。ただし、すべてのフォームまたはすべてのレポートを単純にグループ化しないでください。モジュールをコンポーネントごとにグループ化します。たとえば、.FMBファイル、.FMXファイル、PL/SQLライブラリ、メニュー、ビットマップ、アイコンなどを含む大きなフォーム内のすべてのモジュールのサブプロジェクトを作成する場合があります。この結果、Project Builderでは検出されない一部の必要な依存関係をより簡単に作成できます。
ステップ1c: デフォルト・アクション、マクロおよび接続文字列の設定
このステップでは、アクションおよびマクロをサイト別に編集する必要があります。たとえば、サイトで標準的なコンパイラおよびコンパイラ・オプションを使用するビルド・アクションの変更などです。まだ行っていない場合は、テスト・データまたは必要な表が含まれた、最も頻繁に使用されるデータベースの接続文字列を作成することもできます。
ステップ1d: 手動による必要な依存関係の設定
Project Builderでは、モジュール間の一部の依存関係（.FMXファイルが、FMTファイルによってビルドされる.FMBファイルからビルドされること)が認識されていますが、「配布可能タイプ」および「<タイプ>からビルド」アクションのクロス・リファレンスによってわかる依存関係のみです。
その他にも、PL/SQLライブラリ、メニュー、アイコンなどの依存関係が存在する可能性があります。図1-3「手動で追加された依存関係」に示すとおり、依存モジュールのエントリのモジュールに依存したモジュールのエントリを作成すれば、Project Builderにこれらの依存関係を通知できます。
この図は、WIZARD.PLL、NAVIGATE.PLL、およびNAVWIZ.MMBへのNAVWIZ.FMBの依存の関係を示しています。
プロジェクトを作成すると、ソース制御パッケージを導入できます。通常、サード・パーティ製のソース制御パッケージでも、プロジェクトの概念をインプリメントできます。
推奨事項: ソース制御管理者とともに、Project Builderの開発プロジェクトをミラーリングするソース制御プロジェクトを設定してください。
複雑なアプリケーションをソース制御するためにプロジェクトを設定する場合は、隠しモジュールも必ず含めるようにしてください。たとえば、フォームをチェックインする場合、使用するメニュー、PL/SQLライブラリ、ユーザー・イグジット、アイコンまたは特殊フォントを必ず組み込んでください。Windowsで実行されるアプリケーションでは、ソース制御されるOCXまたはActiveXコントロールが使用されていることもあります。
プロジェクトの作成およびソース制御の設定を行う準備作業が終了したら、すべてのプロジェクト情報をプロジェクト・エクスポート・ファイルにエクスポートし、チーム・メンバーに場所を通知します。これで、メンバーはプロジェクトをインポートできます。
チーム・メンバーに実際のプロジェクト・レジストリ・ファイルの場所を通知することもできますが、Project Builderでは、使用しているオペレーティング・システムのセキュリティ機能によってプロジェクト・モジュールの削除または上書きが禁止されていることを覚えておいてください。単なる削除および上書きは可能です。プロジェクトの統合性を維持するには、Project Builderのプロジェクト更新プロセスに従って、変更されたレジストリ・ファイルを分配するのではなく、プロジェクトへの変更を常にインポートおよびエクスポートしてください。
チーム・メンバーにプロジェクト・エクスポート・ファイルの場所を通知する場合は、設定したディレクトリ構造も通知して開発用のマシンでその構造がミラーリングされるようにする必要があります。異なるプロジェクト位置へのマッピングには、Q:\myprojやR:\などのプロジェクト位置用に異なる値を指定したプロジェクト・レジストリ・ファイルのコピーがそれぞれ必要なので、プロジェクトの最も簡単な設定方法は、チーム・メンバー全員がそれぞれのマシン上の同じプロジェクト項目のデフォルト・ディレクトリにプロジェクト位置をマッピングすることです。
チーム・メンバーは、割り当てられたモジュールをチェックアウトできます。
プロジェクト管理者が、1.2.2.1項「プロジェクトの作成: プロジェクト管理者」に記述された作業を完了すると、プロジェクトのチーム・メンバーは作業をうまく調整できるようになります。プロジェクトのチーム・メンバーは、次の作業を行うことになります。
プロジェクトが使用可能であることを管理者から通知されたら、プロジェクト情報をインポートして、割り当てられたモジュールで作業ディレクトリを設定できます。
推奨事項: プロジェクト管理者がプロジェクト用にすでに作成したものをミラーリングするようにディレクトリ構造を設定する場合、ファイル管理は簡単になります。
プロジェクトの設定で最初に行う必要があることの1つは、ユーザー・レジストリをカスタマイズすることです。
ステップ2a: 新規のタイプの定義、および既存のタイプの編集
グローバル・レジストリに表示されないタイプのプロジェクトにモジュールを追加する場合は、ユーザー・レジストリに新しいタイプを定義して、それにアクションやマクロなどを割り当てることができます。
加えて、グローバル・レジストリの特定のタイプのデフォルトのコマンドまたはマクロを書き替える必要があるかもしれません。これは、グローバル・レジストリ内のタイプをコピーして、ユーザー・レジストリにペーストして編集すると簡単です。これで、プロジェクト内のそのタイプのすべてのモジュールには、ユーザー・レジストリ内のタイプの変更が継承されます。
推奨事項: ユーザー・レジストリにコピーしてから編集する方法でグローバル・タイプを変更する場合は、プロジェクト管理者に通知してください。このような変更は、チーム全体に役立つ可能性があります。
ステップ2b: アクションおよびマクロのカスタマイズ
ユーザー・レジストリに追加するタイプに関連付けられたアクションおよびマクロもカスタマイズできますが、Project Builderの階層内のその他の位置でもアクションとマクロを変更できることを必ず覚えておいてください。項目を編集する位置によって、変更の影響範囲が変わります。
次の表に、アクションまたはマクロが存在する可能性がある位置、そのアクションまたはマクロの有効範囲、およびそれを上書きできるものをすべてリストします。
ステップ2c: 再使用可能な接続の作成
テスト用に作成したデータを含む一連の表がある場合は、プロジェクト管理者から与えられたリストに作成した接続を追加できます。接続を作成したらプロジェクト・ナビゲータ内の接続のエントリを選択して、プロジェクト・ファイル・エントリにドラッグし、選択したモジュールのエントリにドロップすれば、モジュールに接続を割り当てることができます。これで、データベース接続が必要なツールをオープンするアクションを選択するとProject Builderがログオンします。
ディレクトリ構造の設定を完了し、プロジェクトをインポートすると割り当てたモジュールを作業領域に移入できます。メイン・メニューの「ファイル」->「管理」からアクセスできるソース制御コマンドの「チェックイン」、「チェックアウト」、および「ソース制御オプション」は、各タイプに定義されたアクションに関連付けられています。これは、必要であれば、コマンドの結果に影響を及ぼすように、アクションを変更できることを意味します。 ただし、これはソース制御にはお薦めできません。
プロジェクトが開発フェーズに入るとプロジェクトの統合性を維持することがさらに重要になります。
推奨事項: 複数のチーム・メンバーに影響するプロジェクトへの変更（グローバル・レジストリの変更や新規モジュールが含まれたサブプロジェクトの追加など）は、プロジェクト管理者のみが行うようにしてください。
アプリケーションの開発段階でプロジェクト管理者の役割はプロジェクトのメンテナンスおよびサポートです。さらに、開発での成果物の管理を担当するか、またはそれを開発マネージャとともに担当する場合もあります。その場合は、次のことを行う必要があります。
先にプロジェクトを作成してから新規モジュールをプロジェクトに追加し、依存関係を手動で追加しなければならない場合もあります。これを行うプロセスは、初めてプロジェクトを作成する場合と同様です。詳細は、1.2.2.1.1項「ステップ1: プロジェクトの作成」を参照してください。
新規モジュールを追加して必要な変更を行ったら、その変更をエクスポートして、チーム・メンバーがモジュールを使用できるようにします。これを行うプロセスは、初めてプロジェクトをエクスポートする場合と同様です。詳細は、1.2.2.1.1項「ステップ1: プロジェクトの作成」を参照してください。
互いにさまざまな改訂バージョンを同期化しようとしても（たとえば、毎晩チェックインすることによって）、あるモジュールは完成しようとしているのに、別のモジュールはまだバグの吸収やヘッダーの変更が必要だったりすることはよくあることです。改訂バージョンの同期をとるのは、通常実用的ではありません。
もっとよい方法は、重要なマイルストーンに達したことを改訂バージョンのグループにマークするために、シンボリック・バージョン・ラベルを用いることでバージョンを同期化することです。たいていの主要なソース制御ツールでは、ソース制御プロジェクトにシンボリック・ラベルを付けることができます。
プロジェクトが設定され、モジュールが割り当てられると、Project Builderを次のことに使用できます。
推奨事項: Project Builderを使用してモジュールを編集する最も効率的な方法は、必要なオプションを使用してツールが起動されるように編集対象のモジュールのタイプに関連付けられたアクションをカスタマイズすることです。さらに、必ず個別のモジュールまたはプロジェクトのいずれかに接続文字列を関連付けるようにしてください。そこで、ユーザー・レジストリ内のその位置から接続をドラッグし、モジュールまたはプロジェクト・エントリにドロップできます。このようにモジュールを準備しておけば、ポップアップ・メニュー項目を選択するか、またはプロジェクト・エントリをダブルクリックすることによって該当するアプリケーションでモジュールがオープンします。必要なときに、すでにログオンされています。
また、ランチャを使用して開発ツールにアクセスすることもできます。ランチャは、Forms DeveloperおよびReports Developerツールのツールバー・ボタンにすでに設定されていますが、ボタンを作成してサード・パーティ製ツールの実行プログラムに割り当てることもできます。
注意: ランチャを介してツールを起動後モジュールをオープンする場合、そのツールは、関連付けられたすべての接続文字列が認識されていません。データベースに手動でログオンする必要があります。
1.2.2.1.1項「ステップ1: プロジェクトの作成」を参照するか、またはプロジェクト管理者に連絡してください。
「ビルド」コマンド −「選択項目をビルド」、「変更分をビルド」および「すべてビルド」− は、メイン・メニュー（「プロジェクト」の下）から使用できます。これらもまた、アクションに関連付けられています。 この場合は、「<タイプ>からビルド」アクションです。
これは、異なるモジュール・タイプに1つのコマンドを選択でき、そのモジュールが「<タイプ>からビルド」アクションの定義に応じてコンパイルされることを意味します。 つまり、その特定のタイプではなく、実際に作成したいターゲットを選択できるということです。
たとえば、.FMXファイルのための「<タイプ>からビルド」アクションによって、Form Compilerが起動され、対応する.FMBから .FMXファイルが作成されます。「ビルド」コマンドによってコンパイルされるのは.FMBですが、どのように.FMBがコンパイルされるかを決めるのは作成された.FMXファイルに関連付けられているアクションです。
対応するターゲットの「<タイプ>からビルド」アクションの定義を変更すると、「ビルド」コマンドの結果を変更できます。
「選択項目をビルド」を選択して、選択したモジュールをコンパイルするか、または「すべてビルド」を選択して強制的にすべてのモジュールをコンパイルします。Project Builderではモジュールが古くなって再コンパイルが必要なことを検出できるため、古いモジュールが含まれるプロジェクトのエントリを選択後、「変更分をビルド」を選択すれば、その古いモジュールのみをコンパイルできます。
注意: 「ビルド」コマンドは、ポップアップ・メニューからも使用できます。
モジュールがソース制御のために変換を必要としている場合（たとえば、ソース制御がテキストにのみ動作し、モジュールがバイナリの場合）、チェックインの前に「ファイルをRCSにチェックイン」アクションを編集して、テキストへの変換を自動化できます。
また、「ファイルをRCSからチェックアウト」アクションは、バイナリに戻ったモジュールをテキスト・ベースでソース制御されたバージョンに変更するために、同じような方法で編集できます。
今日では、多数のアプリケーションが複数のプラットフォーム上で実行され、さまざまなプラットフォーム上で開発が行われます。第5章「移植性のあるアプリケーションの設計」では、プロジェクトの基礎となるアプリケーションに移植性を持たせることに役立ちます。
プロジェクトに移植性を持たせるためにも、Project Builderでは数種類の主要なプラットフォーム上での開発もサポートされています。そのためには、プラットフォームを反映したグローバル・レジストリを装備している必要があります。つまり、定義されたタイプがそのプラットフォームに存在し、アクションおよびマクロがプラットフォームの構文ルールに従って書かれている必要があります。これは、グローバル・レジストリと、拡張子別のすべてのユーザー・レジストリおよびプロジェクト・レジストリ・ファイルには移植性がないことを示します。
ただし、1.1.3.6項「プロジェクトおよびサブプロジェクト・レジストリ・ファイルの共有および移植」にあるように、プロジェクトに関する情報をテキスト・ファイルにエクスポートし、そのファイルを別のプラットフォームへインポートできます。
複数のプラットフォームで開発中のプロジェクトを担当する管理者の場合は、次の作業を行います。
ソース制御管理者とともに、チーム・メンバーが新規プラットフォームのコードを分離できるようにする分岐ソース制御プロジェクトを作成してください。
別のプラットフォームにプロジェクトを分配するためにエクスポート・ファイルを作成するのは、同じプラットフォームでチーム・メンバーに分配するエクスポート・ファイルを作成する場合と同じです。Project Builderで作成されるエクスポート・ファイルはテキスト・ファイルなので、別のプラットフォームに簡単に移行できます。
別のまたは二次的なプラットフォームで開発作業中のチーム・メンバーの役割分担は、実際には基盤となるプラットフォームで開発中のチーム・メンバーの役割分担とほとんど同じです。ただし、大きな違いが1つあります。別のプラットフォームであらかじめ作成されたプロジェクトを受け取ったら、次の作業を行います。
サポートされているすべてのプラットフォーム用に、管理者がProject Builderでは、事前定義済みのアクションおよびマクロの等価バージョンが、それらと同じ場所に提供されています。ただし、一部のアクションがカスタマイズされているか、または新規アクションが追加されている場合、新しいプラットフォーム上で動作するようにアクションを編集するか、または等価の新規アクションを作成する必要があります。
テスト・フェーズは開発作業とは分かれた異なるもの、つまりテストは開発した後に行うものと考えられることがよくあります。しかし実際には、開発チームに有益な情報を与える、同時進行で行うプロセスです。
Project Builderをテスト・フェーズに統合するためのオプションには、少なくとも次の3つがあります。
推奨事項: 2番目と3番目のオプションを組み合せるのが最適な方法です。作成したアプリケーションとプロジェクトを対応付ける方法も、テスト・フェーズでは役立ちます。テスト・スクリプトを自動的に実行するアクションを作成するか、またはスクリプト・タイプを追加してテストするモジュールに依存させることができます。
単体テストの段階では、プロジェクトが機能単位で編成されているか、または分けられたプロジェクトが機能単位ごとに作成されている場合、テスト担当者は開発者と同じプロジェクトを使用できます。プロジェクトはエクスポートすることもできるので、単体テストはさまざまな環境およびプラットフォームで実行できます。
システム・テストでは、特に、より小規模な複数のプロジェクトを連結する必要がある場合はテストするモジュールのみを含む、開発プロジェクトの縮小された新しいバージョンが必要な場合があります。
このフェーズにおける開発グループの目標は、できる限り円滑にテストするモジュールをテスト・グループに渡すことです。
テスト用プロジェクトの作成およびエクスポートに関連する作業は、プロジェクトを作成して開発チームにエクスポートする場合に必要な作業と同じです。
テスト・チームのメンバーは、通常、アプリケーションのモジュールへの変更について責任を負いませんが、入力（テストするモジュール）と成果物（完全にテストされたモジュールおよびテスト・フェーズでは解決できなかったバグのリスト）があります。
Project Builderは、開発チーム・メンバーの場合と同様に、テスト・チームでも入力および成果物を追跡し記録するのに役立ちます。テスト担当者は、スクリプトやログのプロジェクトへの追加、デバッグ・オプションを含めるようなアクションの変更、およびテスト情報を含むサブプロジェクトの追加などの処理が可能です。
Project Builderを使用して、作成したアプリケーションをテストすることに決まったら、開発者が最初にプロジェクトを設定した際に行ったのとほぼ同じ準備作業を行う必要があります。その場合は、次のことを行う必要があります。
テスト・プロジェクトのインポートとテスト環境の設定を行うプロセスは、開発でのプロジェクトのインポートとテスト環境の設定を行うプロセスと同じです。詳細は、1.2.2項「プロジェクトの作成」を参照してください。
テスト・スクリプトなどの項目をプロジェクトに追加することが必要な場合があります。また、テスト・データが含まれたデータベース・アカウントに接続文字列を追加することが必要な場合もあります。
作成したアプリケーション内のモジュールに対応付けられたアクションを自動化できるように、テスト・スクリプトの実行も自動化できます。
「デバッガ付きで実行」を指定したアクションがまだない場合は、既存のアクションを変更してデバッグ・フラグを挿入するか、または新規アクションを作成できます。
作成したアプリケーションを徹底的にテストしリリースできる段階になったら、Project Builderで顧客にアプリケーションを配布するプロセスを簡素化できます。
リリース・フェーズでは、インストールに必要なすべてのモジュールのテストと検証が完了したバージョンが開発側からリリース担当者に渡されます。Project Builderでは、最終的なアプリケーションに含まれたすべてのモジュールにマークが付けられ、それらに特別なコマンドが対応付けられるため、プロジェクトのコンパイルやソース制御などの他のプロセスと同じ方法でこの受渡しを自動化できます。
作成したアプリケーションを徹底的にテストし、リリースできる段階になったら、残りの作業はプロジェクトのパッケージだけです。プロジェクトのパッケージ
Project Builderは配布ウィザードを提供します。配布ウィザードは、アプリケーションをインストール可能なコンポーネントとしてパッケージするのみでなく、次のような機能も提供します。
配布ウィザードが実際にパッケージするモジュールは、各項目に関連付けられた「配布ファイル」プロパティの値によって判定されます（「はい」の場合はパッケージにモジュールを追加し、「いいえ」の場合はそのままにします）。
作成したアプリケーションをパッケージしたら、顧客にアプリケーションを使用してもらうことができます。顧客は、アプリケーションのインストールだけでなく、アプリケーションが依存するランタイム環境をインストールするためにもOracle Installerを使用する必要があります。顧客のインストール・プロセスを簡素化するため、Forms DeveloperおよびReports DeveloperにはOracle File Packagerが付属しています。これによって、Windows NTおよびWindows 95上にOracle Installerでアプリケーションをインストールできるようになります。この項のステップが終了したら、顧客は1つの機能を使って、アプリケーションと必須のランタイム環境という必要な要素をすべてインストールできます。
作成されたアプリケーションのパッケージ方法を説明する前に、次に示す、インストールやパッケージ・プロセスに関連する用語および背景知識をよく理解しておく方がよいでしょう。
この表には、インストールおよびパッケージ・プロセスで重要な用語が定義されています。
Oracle Installerファイルによって、ユーザーのマシンでアプリケーションをインストール（または削除）する方法および場所が制御されます。Oracle File PackagerでOracle Installerファイルが作成されますが、その一部を手動で変更することが必要な場合があります。Installerファイルのサンプルをご覧になる場合は、次の位置を参照してください。
\TEMPLATES\RELEASE\YOURAPP\FORMSAPPFORMSAPP.MAP FORMSAPP.VRF FORMSAPP.INS FORMSAPP.DEI\DEV2KAPPDEV2KAPP.MAP DEV2KAPP.VRF DEV2KAPP.INS DEV2KAPP.DEI
これらのファイルはすべてテキスト・ファイルで、テキスト・エディタでの参照および編集が可能です。
PRDファイルには、任意の作業用領域でインストールできるコンポーネントがすべてリストされています。また、これにはベースのファイル名と各コンポーネントのOracle Installerファイルの場所が指定されています。つまり、PRDにはOracle Installerの「使用可能な製品」ペインに表示されるファイルがすべてリストされます。そのPRDの名前は、WIN95.PRDおよびNT.PRDなど、それが記述されるプラットフォームを示しています。作業用領域ごと、プラットフォームごとに1つのPRDファイルがあります。
MAPファイルは、作成したアプリケーションを構成するすべてのファイルがリストされた表です。
注意: 「Group」、「Item」および「Command」は、「スタート」メニューに表示されるアプリケーションの場合のみ必要になります。
VRFファイルでは、正しい依存関係がすべて識別およびインストールされていることが検証されます。たとえば、Forms Runtimeに依存するアプリケーションを指定すると、アプリケーションのインストール・プロセスで、ユーザーのマシンにForms Runtimeがすでに存在するかどうかが自動的に検出されます。まだ存在しない場合は、Forms Runtimeがインストールされます。
また、ユーザーはVRFファイルから製品のインストール位置などの情報を入力するように要求されます。さらに、VRFファイルにはユーザーの環境が設定され、Windowsレジストリに環境変数などの情報が定義されます。
INSファイルによって、インストール可能なコンポーネントの構成および必須の環境変数の設定、Oracle Installerへの製品登録を行うファイルがインストールされます。これは、MAPファイルおよびVRFファイルとともに機能します。
DEIファイルによって、インストール可能なコンポーネントを構成するファイルが削除されます。また、削除が完了すると環境変数が削除され、コンポーネントの登録が取り消されます。これは、MAPファイルとともに機能します。
TEMPLATESディレクトリには、作業用領域の設定およびカスタマイズに必要なものがすべて含まれています。Oracle配布媒体のTEMPLATESディレクトリには、次のものが含まれています。
RELEASEサブディレクトリ: 作業用領域の作成の出発点として機能します。
RELEASE\INSTALLR\INSTALL\WIN95.PRD: 次に示す、Windows 95上のForms、ReportsおよびGraphics Runtime環境のインストール可能なコンポーネントがリストされたPRDファイルです。
この項には、顧客が1ステップまたは複数ステップのインストール・プロセスを作成する方法が含まれています。
どちらのプロセスを選択しても、Oracle Installerによってアプリケーションをインストールできるようにするには、次のいずれかを行います。
TEMPLATES\RELEASEディレクトリを自分のマシンにコピーします。
この章では、この後、これらの作業を完了するための特定の方法を説明します。
作成したアプリケーションをWindows 95およびNT上にインストールできる場合は、Oracle File Packagerを使用して、Oracle Installerファイルを作成し、開発領域から作業用領域にファイルをコピーできます。次のステップでは、1ステップおよび複数ステップのインストール方法を説明します。
ステップ1: Oracle File Packagerのインストール
ステップ2: 作業用領域の準備
ステップ3: 作業用領域へのファイルの移動、およびOracle Installerファイルの作成
ステップ2で設定した各作業用領域について、このステップを繰り返します。
注意:
ステップ4: PRDファイルのNT.PRDおよびWIN95.PRDのマージ
ステップ5: Oracle Installerファイルの変更
たとえば、アプリケーションがForms Runtimeに依存するように設定する場合、インストール・プロセスで、ユーザー・マシンにForms Runtimeがすでに存在するかどうかが自動的に検出されます。まだ存在しない場合は、Forms Runtimeがインストールされます。
SETUP.EXEをクリックして、Oracle Installerを起動します。「使用可能な製品」ペインにリストされたファイルを調べます。このペインにファイルを表示したくない（たとえば、VRFファイル内でファイルの依存関係がすでに設定され、明示的にインストール対象にする必要がない）場合、作業用領域のPRDファイルを編集して、ファイルの「Visible?」を参照不可に変更します。
ステップ6: インストール内容のテスト
予想されるエンド・ユーザー環境の典型である“クリーンな”マシン（まだ何もインストールされていないマシン）でインストール内容をテストします。開発者のマシンで行ったテストは信用しないでください。そのマシンには、MAPファイルから不注意に削除されたアイコンやライブラリなどのファイル、またはINSファイルに含まれていないレジストリ設定がすでに存在している可能性があるためです。これは、インストールで問題を起こす、最も共通した原因の1つです。
ステップ7: 作業用領域への配布媒体のコピー
|
 Copyright © 2000 Oracle Corporation. All Rights Reserved. |
|