Oracle Designer Reviewer's Guide

(1)

Oracle Designer

Reviewer’s Guide

日本オラクル株式会社第 1 版 2004 年 3 月

(2)

1. はじめに...3 2. 製品コンセプト ...4 2.1. システム開発の現状 ...4 2.2. モデル･ベース開発 ...4 2.3. コード vs モデル...5 2.4. 設計だけでなく、システム管理へ ...5 3. 製品の特徴...7 3.1. Oracle に最適なデータベース設計... 7 3.2. モデルによるアプリケーション設計...10 3.3. ラウンドトリップ･エンジニアリング ...12 3.4. データベース設計とアプリケーション設計の統合...13 3.5. 使いやすい設計環境 ...15 3.6. 設計アプローチの自由な選択 ...19 4. 製品コンポーネント...20 4.1. Oracle Designer ... 20 4.2. システム分析ツール...20 4.3. システム設計ツール...24 4.4. ジェネレータ ...29 4.5. リポジトリ･ツール ...32

4.6. Repository Object Browser NEW!... 34

4.7. Oracle Software Configuration Manager...36

5. 開発手法 ...37 6. 稼動環境 ...38 7. 最後に...39 8. Appendix...40 8.1. FAQ（よくある質問）... 40 8.2. その他の情報...43

(3)

1. はじめに

はじめに

今日の社会において、データベース･システムは非常に重要な役割を担っています。あらゆる業務に関わりを持ち、それが機能するか否かが、企業全体の業績にも大きく影響します。ここで重要なポイントは 2 つあります。一つはスケーラブルかつハイ･パフォーマンスを実現できるデータベースが必須であること、もう一つはその機能を十分に活用したシステムを構築することです。最初の要件に対して、Oracle データベースがその役割を果たします。では、2 つ目の要件を満たすためには、どうしたらよいのでしょうか? 「システム開発をより迅速に、より正確に構築できる」ことと同時に、「時代の変革に対応すべくシステム仕様を柔軟に変更できる」ことが必要です。こういった要件を満たすべく、Oracle Designer というモデリング･ツールを提供しています。 Oracle データベースをダイアグラムを使ってグラフィカルに設計する機能と、Web およびクライアント/サーバー･アプリケーションをモデルから自動生成する機能を持っており、他のコーディング中心の開発ツールに比べて高い生産性とメンテナンス性をもっています。Oracle Designer がサポートする範囲は、ビジネス･モデリングからアプリケーション生成 /メンテナンスまでのすべてのシステム･ライフサイクルにまたがります。

Oracle Designer は 1995 年 6 月に Oracle Designer/2000 として日本での出荷を開始して以来、 Oracle データベースの標準設計ツールとして数多くのユーザーにご利用いただいております。また、海外ではその前身である Oracle*CASE からの長い歴史があり、そこで培われてきたリポジトリ技術は高く評価されています。このドキュメントでは、Oracle Designer のベースにあるコンセプトやそれを実現するための技術、機能に関する概要を紹介した、製品の評価を目的とするユーザー向けのガイドです。このガイドでは、以下の内容について記述しています。 • 製品のコンセプト/特徴 • コンポーネント別の概要 • システム構成

(4)

2. 製品コンセプト

製品コンセプト

2.1.

2.1. システム開発の現状

システム開発の現状

システム開発では、様々な立場の開発者が議論しあった末で決定された仕様を元にして、データベース設計やアプリケーション開発が行われます。通常、このような仕様決定者と開発者は異なり、そこでの理解の食い違いを避けるために、詳細な仕様書を作成する必要があります。また、このような過程を経たにもかかわらず、開発の途中での仕様変更は頻繁に発生し、開発者は余分な工数をかけて修正をしなければなりません。この場合、開発しているコードの修正とともに、仕様書の方も同期をとっていかなくてはなりません。現実は、さらにひどいものです。システム稼動の締め切りが近づくと、仕様書の修正はほったらかしにされて、コードの修正だけが行われがちです。結果として、システムは稼動するものの、仕様書とは異なるものとなり、メンテナンス困難に陥ってしまいます。「仕様書とシステムの同期化」 - 開発者は、この作業に悩まされます。しかし、せっかく詳細な設計仕様を作るのなら、そこから自動コーディングできないか? そうすれば、途中で設計仕様に変更が発生した場合でも、修正された仕様からの自動コーディングで容易に対応できるのではないか? こういった要求を満たすために、Oracle Designer は、統合された開発環境と、設計された情報からの強力な自動コーディング機能を提供します。

2.2.

2.2. モデル･ベース開発

モデル･ベース開発

Oracle Designer は、モデル･ベース開発というアプローチをとります。図：モデル･ベース開発システム開発において要求される要件は様々です。それぞれの設計工程に応じたスキルが要求される場合があります。このため複数の設計者で同時にシステムを開発するための仕組みを整え

(5)

データが生き物であるように、システムもまた生き物です。一度作り上げたシステムはそれで終わりというわけではありません。短期間の使い捨て的なシステムとならないようにするためにはしっかりとした設計を行い、かつその後のメンテナンスのことまでを考えておかねばなりません。このようなシステムの設計だけでなく、メンテナンスといったトータルのシステム管理を目指し、かつシステムを資産化するためのオラクルのソリューションがモデル･ベース開発環境とリポジトリです。

2.3.

2.3. コード

コード

vs

vs モデル

モデル

急速な時代の流れは、システムに対しても迅速な対応を要求します。エンタープライズ規模のデータベース設計、アプリケーション開発を的確に、かつ、わかりやすい形で開発し、さまざまな要因から発生する仕様変更にも柔軟に対応できるような管理方法をとることが必要です。図：コードからモデルへ Oracle Designer による開発の中心はモデル(絵、ダイアグラム)です。モデルはコードより汎用的で、様々な情報をわかりやすく表現できます。データ分析、プロセス分析、データ設計、モジュール設計を支援するダイアグラマを使うことによって、システム構築に必要な様々な情報をモデル化していくことができます。これは複雑なシステムをシンプルに表現することを可能にするため、複数ユーザー間でのシステム設計に対する認識の誤差をなくし、情報伝達をスムーズにします。設計情報を、スペシャリストにしか理解できないコードで管理するのではなく、モデルによって管理することで、人的資源に依存しない企業資産となり得ます。

2.4.

2.4. 設計だけでなく、システム管理へ

設計だけでなく、システム管理へ

Oracle Designer ではリポジトリと呼ばれる情報格納庫にすべてのシステム設計情報を格納します。このリポジトリでは、複数のユーザーによる同時アクセスが可能な環境を提供し、これによって、平行してシステム設計を行うことを可能にしています。システム情報の管理の役割はリポジトリが担います。さらに、設計のメインとなるモデリングにより、マルチ･ユーザーでの情報の共有を容易にします。システム設計に携わる様々な立場(データベース設計者、アプリケーション開発者、プロセス分析者、エンド･ユーザー)にとって、モデリングによるシステム設計は、システムに対する意見交換をスムーズにします。モデリングをベースとした設計はシステムのメンテナンスの際にも大きなアドバンテージをもたらします。システムに仕様の変更が必要となった場合、その修正個所が他の設

(6)

きます。モデル･ベース開発環境、リポジトリの利点は以下のとおりです。 • 仕様変更に対応しやすい • フロントの技術変化に左右されない • 実ビジネスのルールをモデル化できる • 人的資源に依存しないまた、モデル･ベースの開発は高い生産性を提供します。コーディングのいらないアプリケーション設計によって、データベース･アプリケーションに必要な一通りの機能はもちろん、その裏に潜む、多くのエラー処理コードが自動生成されます。アプリケーション設計者は、アプリケーションに本質的に必要とされる機能の設計に集中でき、その他のエラー例外処理から開放されます。このコンセプトに加えて、ラウンドトリップ･エンジニアリングによりフロントの開発ツールの利点を利用できます。モデリングでのアプリケーション設計だけでは困難な、きめ細かなロジックの記述やデバッグいった点はこれでカバーされます。追加されたロジック･コードはデザイン･キャプチャ機能によってリポジトリに反映させて管理することができます。

(7)

3. 製品の特徴

製品の特徴

Oracle Designer は、統合開発を支援します。つまり、システム開発に必要な、データベース設計とアプリケーション設計を一つの環境で開発できます。この章では、Oracle Designer と特徴となる点についてご紹介しています。

3.1.

3.1. 3.1. Oracle

Oracle

Oracle に最適なデータベース設計

に最適なデータベース設計

Oracle データベースは、基本的な RDBMS としての機能に加えて、業務の用途に応じた広範囲の要件に対応すべく、豊富な機能を有しています。しかし、いかに有効な機能であっても、箱が置いてあるだけでは意味がありません。箱の中身を埋めるためには、当然、それらの機能に対応した開発が必要です。Oracle Designer は、Oracle データベースに最適な唯一のデータ･モデリング･ツールとして、Oracle データベースでサポートされる固有の機能やデータ型を十分に利用した設計が可能です。 • データベース設計機能 - ダイアグラムによるテーブル設計 - Oracle 固有機能の設計 - サーバーサイドの業務ロジック設計 - データベースへの実装 • データベースとの連携機能 - データベースへのオブジェクトの自動作成 - データベースからの情報の取り込みパーティショニングやオブジェクト、LOB データ型はもちろん、データベース･リンクやロールバック･セグメント、表領域、ユーザーなどの管理オブジェクトの設計/生成までもサポートします。オラクルが提供する標準設計ツールだからこそできる、Oracle 対応です。 3.1.1. データベース･モデリングデータベースのテーブル構成を設計する、もしくは既存のテーブル構成を再構築するといった場合、全体像を把握するために図式化することが必要です。Oracle Designer のサーバー･モデリング機能は、以下の点での優位性があります。システムの完全な情報を一元管理できる。システムを管理するという意味で、できる限りの情報を一元管理しておくことは重要です。システムの仕様変更が生じた場合、一つの変更が様々な個所に影響をもたらします。システム情報が一元管理されることによって、この影響範囲を検知することが可能になります。また、システムに何らかの障害が発生した場合、システムの状況を判断する上での材料となります。既存のシステム情報をロスすることなくスムーズにリバースできる。既存システムの再構築や、アプリケーション追加など、既存のデータベース構造を利用したシステム開発の場合、再利用性を高めるためには、どれだけの情報を抽出できるか、が鍵となります。Oracle Designer のもつ Oracle データベース対応によって、高いレベルでのシステム情

(8)

設計可能なデータベース･オブジェクト

高いレベルのデータベース設計機能を提供します。以下にリストされるデータベース・オブジェクトの設計が可能です。一般オブジェクト Oracle 固有オブジェクト管理オブジェクト・表・クラスタ・データベース・制約・順序・表領域主キー・マテリアライズド･ビュー・ロールバック･セグメント一意キー・トリガー・オブジェクト権限外部キー・PL/SQL プログラム・システム権限検査制約プロシージャ・ユーザー・索引ファンクション・ロール・ビューパッケージ・シノニム・Java ストアド･プロシージャ・パーティション表/索引・オブジェクト型/表/ビュー・コレクション型・ネストされた表・索引構成表・キュー表

オープンな

DB サポート

Oracle 以外の様々な DB を対象にしたデータベース設計もサポートしています。設計されたテーブル構造を元に、ODBC 経由での接続によって、直接テーブルを作成できます。また、逆に、デザイン･キャプチャ機能によって、DB のテーブル構造を解析してダイアグラム表示することも可能です。Oracle データベースを中心に、それに関連する他 DB のシステムをあわせて一元管理できるようになります。図：ODBC 経由での接続の指定

(9)

3.1.2. サーバーサイドの業務ロジック統合されたシステムでは、一つの表に対して、さまざまな業務アプリケーションがアクセスすることがあります。この場合、データベース・サーバーでデータだけを管理するのではなく、共通で利用される業務ロジックも管理しておくことにより、アプリケーションによって微妙に異なる処理を統一化させることができ、またメンテナンスも集中化できます。たとえば、消費税に関する計算ロジックをアプリケーションごとに行っていると、消費税率の変更にあわせて、あらゆるアプリケーションのメンテナンスが発生しますが、このようなロジックをサーバーに持たせることによって、ロジックの変更を一元化できます。このようなサーバーサイドの業務ロジックの作成支援機能を Oracle Designer は提供しています。 • 列の自動導出（順序の自動割り当て、作成日/更新日/作成者/更新者の記録） • 非正規化列の設定 • データの挿入/更新/削除/ロックの前後のタイミングで実行させるロジックの作成 3.1.3. システム管理どのデータベース・ユーザーにどの表を実装させるか、どのデータベース･ユーザーにどのような権限を与えるのか、どのような表領域の構成にするのか、といったこともシステム設計の要因になります。Oracle Designer ではこのようなシステム管理要因もリポジトリで管理でき、かつこれらは簡単に SQL DDL として生成可能です。図：ユーザーに対する権限の管理このユーザーに対する権限は、オブジェクト権限、システム権限およびロールを設定可能です。

(10)

3.2.

3.2. モデルによるアプリケーション設計

モデルによるアプリケーション設計

Oracle Designer はモデルを使ってアプリケーション設計を行うことを可能にします。コーディング中心ではない、このアプリケーション設計アプローチは、効率のよい開発と高いメンテナンス性をもたらします。 3.2.1. ユニバーサル・デザイン Oracle Designer でのアプリケーション･モジュール設計は、ユニバーサル･デザインユニバーサル･デザインユニバーサル･デザインと呼ばれユニバーサル･デザインる、開発言語に依存しないモデリングを中心としたアプリケーション構造設計と、各開発言語を使ったアプリケーション･ロジック設計とで構成されます。例えば、以下のようなアプリケーションを開発しようとしているとします。「従業員管理アプリケーション」要件・人事異動に対する部門/従業員の管理・従業員の検索機能・検索にヒットした従業員の部門情報の更新・入社した従業員情報の新規登録・退社した従業員情報の削除このアプリケーションは、画面アプリケーションとして開発されるかもしれませんし、HTML ベースのアプリケーションとなるかもしれません。いずれにしても、以下の共通点があります。 • 「部門」表、「従業員」表へアクセスする。 • 「部門」表は参照するだけ。 • 「従業員」表に対して、問合せ/挿入/更新/削除の操作を行う。 - 「従業員」表のすべての列を対象に、問合せ/挿入を行う。 - 「従業員」表の「部門番号」列にのみ、更新操作を許可する。 Oracle Designer では、この共通する部分を、最終的な開発言語に依存しないモデルモデルモデルとして作モデル成します。図：「従業員管理アプリケーション」のモデル

(11)

例に挙げた以外にも、アプリケーションの元となるモジュール定義によって、モジュール内で取り扱うデータ構造やモジュール間の呼び出しなどの情報をモデル化します。 • モジュールで取り扱うデータの構造 • 表および列それぞれに許可する操作(選択/挿入/更新/削除) • 画面上での表示タイプおよびその表示幅、高さ • 他モジュールの呼び出しこのようなフロントの開発言語に依存しないモジュールの中心となる情報はユニバーサル･デザインとしてリポジトリに格納されます。データ表示画面表示モジュールのデータ構造を中心に、その項目に対して許可する操作を設計します。生成後の項目の配置順や項目のグループ化、プロンプトなどを設計します。このユニバーサル･デザインをベースとして、そこに各開発言語ごとのイベント･コードや、アプリケーションのレイアウトに関するスタイル･ガイドなどを指定できます。これらを基に、Oracle Designer が提供するコード･ジェネレータが、対応するアプリケーション･コードを自動生成しますので、コーディング･ミスは極力なくなります。 3.2.2. アプリケーション･ソースの自動コーディング設計されたアプリケーション･モジュール定義をベースとして、Oracle Forms/Reports のソース･ファイル、Oracle Application Server で利用可能な PL/SQL プログラム、OracleAS Portal 用のポートレット・アプリケーション、Microsoft Visual Basic のソース･コードを生成できます。

(12)

図：ユニバーサル･デザインからのアプリケーション生成いろいろなタイプのアプリケーションを要求される設計者にとって、同様のアプリケーション･モデルからジェネレータの選択如何で対応するソース･コードを得られることは大きなメリットです。これはアプリケーションを開発する各開発ツールの使い勝手、開発言語の仕様の違いを吸収してくれることを意味します。

3.3.

3.3. ラウンドトリップ･エンジニアリング

ラウンドトリップ･エンジニアリング

定義情報からのコード生成と、既存システムからのキャプチャ（リバース）を組み合わせる開発をラウンドトリップ･エンジニアリングと呼びます。Oracle Designer ではデータベースおよびアプリケーションのラウンドトリップ･エンジニアリングを支援しています。＿＿＿＿□□□□x ← ← ← ← →→→→ ○○○○ △△△△×× ◇××◇◇◇ ＿＿＿＿□□□□x

8/8i

Dim strSql As String

Dim dysDelete As OraDynaset On Error GoTo ldDeleteRow_Err ' Assume that the row could not be deleted ldDeleteRow = False

' Initialise the output parameters pstrMsgStack = "" pstrSql = "" pintErrPos = 0 Dim strSql As String Dim dysDelete As OraDynaset On Error GoTo ldDeleteRow_Err ' Assume that the row could not be deleted ldDeleteRow = False

' Initialise the output parameters pstrMsgStack = "" pstrSql = "" pintErrPos = 0 図：ラウンドトリップ・エンジニアリング 3.3.1. データベースのラウンドトリップ設計されたデータベース構造から必要な SQL DDL 文を生成したり、既存のデータベースの状況を解析してわかりやすくモデル（ダイアグラム）に戻すことができます。コードモデル

(13)

3.3.2. アプリケーションのラウンドトリップ

Oracle Forms、Reports および Microsoft Visual Basic によるデータベース･アプリケーションをラウンドトリップ･エンジニアリングによって開発できる環境を提供します。これによって Design Editor がもつモジュール･モデリング能力と生成機能、フロントの各開発ツールがもつデバッグ機能を組み合わせた非常に高い生産性が実現できます。

3.4.

3.4. データベース設計とアプリケーション設計の統合

データベース設計とアプリケーション設計の統合

Oracle Designer ツールセットは、データベース設計とアプリケーション設計を同時進行的に行うことを可能にします。これにより、統合されたシステム設計を支援します。図：データベースとアプリケーションの統合設計環境 3.4.1. 統合ゆえの利点格納するデータの整合性チェックをどのように行うか、を決定することは重要です。多くの場合、データベースの整合性制約（主キー/一意キー/外部キー/検査）等を使って実装させたりしますが、状況によっては、そのような制約をあえてサーバー側に持たせずに、クライアント･アプリケーションで管理するというケースもあります。こういった場合、システムの仕様を正確に残しておかないと、後にシステムに何らかの修正をかけたり、アプリケーションを追加したりした場合に、追加・修正を加えたアプリケーションに整合性検査のロジックを実装し忘れてしまい、その結果、大切なデータをおかしくしてしまうことになりかねません。

(14)

Oracle Designer では、サーバー･モデルで設計された整合性制約を実装させるタイミングを設定することができます（妥当性検査をサーバーで行う、クライアントで行う、両方で行う、両方で行わない、を選択できます）。この設定をベースとして、各種コード･ジェネレータが適当なコードを生成します。これはデータベース設計とクライアント･アプリケーション設計を統合的に管理する環境だからこそ可能なことです。 3.4.2. 依存性の識別データベース設計とアプリケーション設計を統合して管理できることにより、システムをスムーズに設計できることはもちろん、システムの仕様変更時に必要なオブジェクト間の依存性分析が可能です。図：選択されたオブジェクトに依存している他オブジェクトのリストまた、様々な定義情報は内部的にリンクされていますので、仕様変更に必要な手間は最小限におさえられます。

(15)

3.5.

3.5. 使いやすい設計環境

使いやすい設計環境

Oracle Designer のツール群のほとんどは、ダイアグラム画面と、それらのプロパティを表示するダイアログ(またはウィンドウ)で構成され、設計される各オブジェクトのプロパティとダイアグラム画面 は連動して管理されています。特にシステム設計の下流工程を支援する統合設計環境 Design Editor では、多くの設計インターフェイスが提供されており、あまりツールを知らない設計者に対 するわかりやすい入力形式とともに、使い慣れた設計者により高い生産性を提供するための入力形式を用意しています。 3.5.1. ドラッグ&ドロップ

Design Editor でのあらゆる操作はドラッグ&ドロップに対応しています。

オブジェクトのコピーや列の順序変更といった基本的な操作はもちろんのこと、ダイアグラムやエディタの表示もドラッグ&ドロップでおこないます。

ナビゲータ･ツリー

(16)

Design Editor のナビゲータ･ツリーからブランクなクライアント領域へ、以下をドラッグ&ドロップすることにより、ダイアグラムが表示されます。ドラッグ&ドロップするオブジェクト表示されるダイアグラム表/ビュー/ スナップショットサーバー･ダイアグラム一目で表構造、列名、データ型を把握できます。 PL/SQLプログラム (ファンクションプロシージャなど) アプリケーションロジック PL/SQL、Java、JavaScript、Visual Basic の基本構文をドラッグ&ドロップで記述できます。モジュール定義モジュール･ダイアグラムデータ表示と画面表示の 2 通りの表示法を使って、モジュールをモデル化できます。構文ツリーテキスト･エディタデータ表示画面表示表定義ロジック･エディタ

(17)

また、既存のデータベース情報をリポジトリへリバース(デザイン･キャプチャ)する場合もドラッグ&ドロップで実行できます。 3.5.2. 編集用途に応じたユーザー･インターフェイス Design Editor では豊富なユーザー･インターフェイスによって、用途に応じた設計を可能にします。対話的に必要な情報を入力するためのウィザードや、プロパティを一覧表示できるプロパティ･シート、複数オブジェクトのプロパティを比較するスプレッド･シートなどが用意され、ユーザーは必要に応じてこれらを自由に選択できます。また、設計をサポートするためのガイドも用意されています。

作成ガイド

データベース･オブジェクトの設計のために... サーバー･モデル･ガイドアプリケーション設計のために... モジュール･アプリケーションガイドシステムの管理情報のために... データベース管理ガイドこのガイドは Design Editor の使い方に慣れていないユーザーに、オブジェクトの作成/編集のデータベース･ナビゲータデータベース上のオブジェクト情報を一覧できるツール。データベース･ナビゲータから Design Editor のナビゲータ･ツリーへオブジェクトをドラッグ &ドロップすることにより、その設計情報がリポジトリへ格納されます。

(18)

ウィザードとプロパティ･ダイアログ

Design Editor をつかってオブジェクト定義をするとき、ウィザードを利用できます。これによって対話的なデータベース/アプリケーション設計が可能になります。また、オブジェクト作成時に利用したウィザード画面はそのままそのオブジェクトの編集ダイアログで利用されます(リエントラント･ウィザードリエントラント･ウィザードリエントラント･ウィザードリエントラント･ウィザード)。ユーザーは作成と編集をまったく同じインターフェイスで行うことができます。

シート形式とスプレッド表形式でのプロパティ編集

オブジェクトのプロパティはダイアログ以外にプロパティ･シート形式でも表示できます。選択されたオブジェクトが持つすべてのプロパティが一覧表示され、ここにはプロパティ･ダイアログではカバーされないような詳細なプロパティが含まれます。プロパティ･シート表示を使うと、複数のオブジェクトのプロパティを一度に変更することが可能です。また、この選択された複数のオブジェクトのプロパティをスプレッド表形式で表示することもできます。この表示形式ではプロパティを比較しながら編集することが可能になります。モジュール定義を作成するときに利用可能なウィザードモジュール定義のプロパティ編集のためのダイアログ

(19)

3.6.

3.6. 設計アプローチの自由な選択

設計アプローチの自由な選択

CASE ツールとして分類されるような製品の場合、「きちんとした方法論に基づいた開発手法が必須」であると思われがちです。特に、上流工程からしっかりと設計の工程をこなしていかなくてはならないというように誤解されることがあります。確かにそれを強いる他製品も存在します。しかし、Oracle Designer が提供するいくつかの設計アプローチを選択することによって、方法論にあまり通じていない設計者でも Oracle Designer のもつ機能を享受できます。 • 下流からの RAD 開発 - システム設計ツールによる設計 • 既存システムの再構築 - システム設計ツールでのキャプチャ • 上流工程からのアプローチ - システム分析ツールによるモデリング Oracle Designer を利用し始めたばかりであったり、開発手法にあまり詳しくないといった場合は、まずは、「下流からの RAD 開発」もしくは「既存システムの再構築」によるアプローチをお勧めします。これらのアプローチがカバーするシステム設計の下流工程は、あらゆる開発手法において必要な工程であり、Oracle Designer のもっとも本質的な部分でもあります。また、システム分析を重視した設計や、伝統的な方法論に基づいた利用のために上流工程を支援する多くのツールを提供しています。これらを使うことによって、統合 CASE ツールとしての利用も可能です。 (方法論･開発手法と Oracle Designer との関係については「5 開発手法」も参照ください)

(20)

4. 製品コンポーネント

製品コンポーネント

4.1.

4.1. Oracle Designer

Oracle Designer

Oracle Designer は複数のコンポーネントにより構成されています。これらはシステム設計における様々な工程を支援します。システム設計の工程 Oracle Designer のコンポーネントプロセス･モデリングデータ分析/論理設計データベースアプリケーション設計データベースアプリケーション生成リポジトリ管理各コンポーネントはモデル･ベースの設計を支援します。これらによって得られる設計情報はすべてリポジトリで一元管理されます。設計者は開発方法論に応じて利用するコンポーネントを選択し、利用できます。

4.2.

4.2. システム分析ツール

システム分析ツール

4.2.1. Process Modeler

Process Modeler は、業務フローを作成するためのツールです。左側に組織を定義し、その右側にその組織で行うプロセス(業務)と使用するデータ・ストアを定義し、矢印でそのプロセスとデータ・ストアの流れを定義することで、業務の流れを表わすことができます。プロセスは階層的に定義できますので、業務プロセスを大枠からモデル化し、徐々に細かい部分に落としていけます。また、各プロセスには、音声、イメージ、ビデオ情報といったマルチメディア情報を付加情報として定義することができます。この Process Modeler はビジネス・プロセス・リエンジニアリングなど、システム開発とは直接関係ない場合にも使用できるようになっています。今までの業務フロー作成ツールというのは、個々の PC 上での稼動のみで、複数人によるチームでの分析が難しかったのですが、 Process Modeler はリポジトリを介して、複数の人間が一つの業務フローにアクセスし、更新しても、整合性を失わない機能を提供しています。過去の例では、官庁の大規模開発の計画/分析工程において、複数人での計画/分析作業に威力を発揮しました。

(21)

図：Process Modeler によるモデリング

4.2.2. Entity Relationship Diagrammer

Entity Relationship Diagrammer はデータの論理分析を行うためのツールであり、ここで行う ER-モデリングは、多くのシステム開発アプローチにおいて利用される重要なテクニックです。もう既にデータベースの構想が出来上がっている場合は使用する必要はありません。Entity Relationship Diagrammer は、データのあるべき姿を求めるために使用します。データのあるべき姿とは、その組織の目標や目的に則したデータのことです。そのデータについて、データ間の関係を中心に分析します。例えば、営業組織の目的が、「自社製品を顧客に販売し、利益をあげる」という場合に Entity Relationship Diagrammer では、顧客、注文、在庫、製品、営業員等をデータとして定義し、さらにそれらのデータ間の関係を「顧客は任意に一つ以上の注文を出す」や、「営業員は必ず一人以上の顧客を管理する」という形で定義します。データ間の線の状態により、任意( )、必須( )、一つ( )、一つ以上( )を表わします。組織を表すプロセスやストア、フローによるモデリングスーパー･タイプとサブ･タイプを用いた表現エンティティ

(22)

ここで設計されたデータは、DataFlow Diagrammer によるデータの流れのモデリングに利用されます。また、Database Design Transformer ユーティリティによって初期のデータベース設計に変換されます。

4.2.3. Function Hierarchy Diagrammer

Function Hierarchy Diagrammer は、別名、機能階層図と呼ばれます。ファンクション(機能)やプロセスをトップダウンで分析するために使用します。つまり、大雑把なファンクションの定義から徐々にブレークダウンして、詳細なプロセスの定義を導きだすのが、Function Hierarchy Diagrammer の使用目的です。例えば、営業というファンクションには、営業管理、顧客管理、在庫管理、売上管理という子ファンクションがあり、その中の顧客管理は、さらに顧客登録、顧客情報修正、顧客抹消、顧客予審調査等のプロセスがあり、その中の顧客登録は、顧客の氏名、住所、生年月日、電話番号を登録して、顧客番号を付与するという処理を行うといった感じで、ファンクションからプロセスへの分解を行います。

図：Function Hierarchy Diagrammer

4.2.4. DataFlow Diagrammer

DataFlow Diagrammer は、プロセス間のデータの流れを分析するためのツールです。 Function Hierarchy Diagrammer では、定義が難しいプロセスの実行順序やプロセス実行のきっかけ(トリガーやイベントという)を把握するのに適しています。また、メインフレームからダウンサイジングを行うためのツールとして使用される率が高いツールです。このツールでは、さらに機能やストア間でのデータ(エンティティおよび属性)のやりとりを定義できます。

(23)

図：DataFlow Diagrammer

Process Modeler で取り扱うプロセス･ステップと、Function Hierarchy Diagrammer、DataFlow Diagrammer で取り扱う業務機能はリポジトリ上では同じ分類です。つまり、それぞれのツールで定義されたものを別のツールからお互いに利用し、編集することが可能です。 DataFlow Diagrammer を使用して定義された業務機能におけるデータの流れをベースとして、 Application Design Transformer ユーティリティは初期のモジュール定義に変換します。

論理モデル物理モデルエンティティ Database Design Transformer 表定義業務機能 Application Design Transformer モジュール定義この論理モデルから物理モデルへの変換で生じた表定義、モジュール定義の初期設計は、下流工程を支援する Design Editor を使って、実装レベルの設計へと洗練させることができます。

(24)

4.3.

4.3. システム設計ツール

システム設計ツール

4.3.1. Design Editor

Design Editor はデータおよびアプリケーションの実装工程で利用する統合設計ツールです。ナビゲータ･ツリーと、ダイアグラムやエディタを表示する領域で構成されています。ナビゲータ･ツリーは、設計目的に応じて 4 つのタブ･キャンバスに情報が整理されています。【サーバー・モデル】データベース･オブジェクトを設計します。表や列、ビューなどの構造や、PL/SQL プログラムを設計します。【モジュール】アプリケーション設計を行います。関連する必要な情報が一覧できます。【DB 管理】設計されたデータベース･オブジェクトの配置や、権限管理などを行います。【分散】分散データベース環境の設計/管理を行います。このツールによって以下の設計が可能です。 4.3.2. データベース設計表やビュー、索引をはじめとして、スナップショットやファンクション、プロシージャなど、あらゆるデータベース･オブジェクトを設計できます。表、ビュー、スナップショット、オブジェクト型といったオブジェクトはダイアグラムでその構造を確認しながら設計できます。ダイアグラムでは列のデータ型を示すアイコンや、表に関連した制約/索引/トリガー/シノニムの情報の表示など、様々な情報を一目で確認できるようにデザインされています。表定義に関連するオブジェクト（索引/ トリガー/シノニム/制約）がある場合ボタンが押せる状態になり、これが押された状態のとき下部分に名前がリストされます。 _メソッド列のデータ型と任意性（*：必須、o：任意）を表します。オブジェクト型表定義オブジェクト型の連結形式。この例は参照リンク（REF）を表します。

(25)

データベース上のストアド･プログラム(PL/SQL 定義)やトリガーのコードは、ロジック･エディタで作成します。ロジック･エディタはテキスト･エディタと構文ツリーの 2 つのウィンドウからなります。構文ツリーには基本構文が用意されていて、それらをテキスト･エディタ上にドラッグ&ドロップできます。テキスト･エディタではキーワードを色分けして表示します。また、作成されたロジックは簡単な構文チェックをすることができます。 4.3.3. アプリケーション設計

Oracle Forms/Reports、Visual Basic のアプリケーション、および Oracle Application Server による動的 HTML アプリケーションを設計できます。このアプリケーション･モジュール設計は、ユユユユニバーサル･デザインニバーサル･デザインニバーサル･デザインニバーサル･デザインと呼ばれる、開発言語に依存しないモデリングを中心としたアプリケーション構造設計と、各開発言語を使ったアプリケーション･ロジック設計とで構成されます(ユニバーサル･デザインについては「ユニバーサル・デザイン - 10ページ」を参照ください)。図：ユニバーサル･デザインによるアプリケーションのデータ構造と画面構成モデルテキスト･エディタ構文ツリー

(26)

ション･ロジック(PL/SQL、JavaScript、HTML、Visual Basic)を追加できます。アプリケーション設計者は、アプリケーションに特化したロジックのみの開発に集中でき、他の一般的なロジックはジェネレータによる標準的でエラーのないコーディングを得ることができます。図：ナビゲータ･ツリー内で管理されているロジックアプリケーション設計の基本情報は、このユニバーサル･デザインと、それに追加されたアプリケーション･ロジックです。さらに、設計者はコード･ジェネレータに対して以下のようないくつかのガイドラインを指定することができます。 • レイアウト･スタイル • コーディング･スタイル • 妥当性検査のタイミングやナビゲーション規定などこのガイドラインを指定する要素として、ジェネレータ作業環境とアプリケーション･テンプレートがあります。ジェネレータによる自動追加ロジックユーザー定義ロジックモジュール定義（ユニバーサル･デザイン）アプリケーションロジックスタイル･ガイド・ジェネレータ作業環境・テンプレートアプリケーションのソース･コードモジュール定義

+

コード生成

(27)

ジェネレータ作業環境とは、コードジェネレータに対して指定するさまざまなパラメータ群のことです。これによってアプリケーションに対する標準化規定を定めます。図：ジェネレータの作業環境パラメータ一方のアプリケーション･テンプレートはアプリケーション上に配置されるオブジェクトの部品群です。たとえば、画面アプリケーションであれば、その上に配置されるテキスト項目やチェックボックス、ラジオボタンなどの基本部品が含まれます。ジェネレータは、指定されたテンプレート内の適当なオブジェクトをベースとしてアプリケーションを構成していきます。つまり、アプリケーション上の文字のフォントや色はテンプレート上のオブジェクトがもつプロパティで管理され、その他のレイアウト規定や自動生成されるロジックなどはジェネレータ作業環境で指定されます。項目プロパティに応じたフォントおよびサイズ、色 → テンプレートレイアウト規定(項目の配置方法や項目間の距離など) → ジェネレータ作業環境妥当性検査の実行タイミングなど _→ _{ジェネレータ作業環境} このテンプレートおよび作業環境は、モジュールごとに作る必要はありません。いくつかのパターンを作っておき、それを再利用することで、生成されるアプリケーションを標準化することが可能になります。

(28)

4.3.4. データベース実装ダイアグラムを用いて、表やビューなどの構造を視覚的に定義できますが、実際にシステムとしてこれらを実装させる場合、より多くの情報が要求されます。例えば、 • 設計された表をどのユーザーに所有させるか？ • ユーザーに対する権限の付与をどうするのか？ • データベース･オブジェクトをどう格納するのか？ • 分散データベース環境を行う場合、どのように実装させるのか？単なる表構造の決定だけの場合、後からこういった部分の設計を別途行わねばなりません。このような情報をすべて保持できてこそ、システムの一元管理といえます。この Design Editor では、データベース･リンクやロールバック･セグメント、表領域、ユーザー設定といった管理オブジェクトの設計/生成が可能です。また、システムの構成によって、複数のデータベースによる分散環境を設計するケースもあります。この場合にスナップショットの実装情報等を管理します。複数のデータベースに対する分散設計情報の管理データベース内の格納領域に関する情報サーバー･モデルで設計されたオブジェクトをユーザーに実装させたり、それらへの権限付与を行います。

(29)

4.4.

4.4. ジェネレータ

ジェネレータ

Oracle Designer が提供するジェネレータによって、データベース/アプリケーション設計者はコーディング作業から開放されます。Design Editor で設計されたサーバー･モデルから Server ジェネレータにより選択したターゲット･データベースに応じた SQL DDL スクリプトが、ユニバーサル･モジュール･デザインから各アプリケーション･ジェネレータによりエラー処理を含む品質の保証されたアプリケーション･コードが生成されます。このモデル･ベース開発とジェネレータによるコード生成は高い生産性をもたらすだけではなく、メンテナンス時にも大きな威力を発揮します。

4.4.1. Server ジェネレータ

Design Editor で設計されたサーバー･モデルおよびデータベース管理オブジェクトは Server ジェネレータによって生成することにより、SQL DDL となります。この DDL は設計情報として割り当てられたデータベースの種類に応じた構文で生成されますので、データベース設計者はサーバー･モデルの設計に注力できます。

生成される SQL DDL は、Oracle Net および ODBC 経由で直接データベースに実行することができます。このとき、選択された設計情報が既にデータベース上に存在していると、Server ジェネレータはリポジトリ上の設計情報と、データベース上のオブジェクト情報を自動的に比較し、そのレポートと、Alter DDL を作成します。また、Server ジェネレータは、設計されたデータベース･オブジェクトだけでなく、アプリケーション設計から利用される API パッケージ･ファイルの生成も行います。この API パッケージは以下の用途で用いられます。 • (Oracle Forms での)ブロックのベースとなるプロシージャ(検索/挿入/更新/削除/ロック) • 更新処理を行う Web アプリケーションで利用するパッケージ • サーバー側で自動的に列値を導出させるためのトリガーこの API パッケージを、様々なアプリケーションから呼び出す共通のサーバー･サイド･ロジックとすることが可能です。実行得られる結果 → SQL DDL の生成接続先データベースに指定した名前のデータベース･オブジェクトがない場合 → CREATE 文ある場合 → ALTER 文および比較レポート ※ 上記の判定は自動的に行われます。サーバー･モデル → API の生成パッケージ(プロシージャ、ファンクションを含む)+トリガー

(30)

4.4.2. Form ジェネレータ

Design Editor で設計されたモジュール定義(ユニバーサル・デザイン)は Form ジェネレータによって Oracle Forms アプリケーションのバイナリ･ファイル(.fmb)として生成されます。

図：生成された Forms アプリケーションの例

この Forms モジュール定義ではこれまでどおりの表取扱をベースとするブロックに加えて、 Oracle Forms の機能であるプロシージャをベースとするブロックを設計できます。更に Server ジェネレータの API 生成機能を利用することにより、このベースとするプロシージャの作成さえも自動化できます。このブロックのベースとする対象を変更することは、Oracle Forms のアプリケーション構成としては大きな変更ですが、その設計情報として Oracle Designer で管理しているモデルとしてはひとつのプロパティの変更にすぎません。設計されたモデルからの自動コーディングによってアプリケーションが得られますので、機能やレイアウトは同じで実装形態の異なるアプリケーションを容易に作成できます。 4.4.3. Web PL/SQL ジェネレータ

Oracle Application Server で利用可能なコードを生成します。生成されたコードは Oracle Application Server の mod_plsql を通した動的 HTML になります。JavaScript をつかったクライアント側の妥当性チェックが可能な更新系アプリケーションを生成可能です。

(31)

図：生成された動的 HTML による Web アプリケーションの例

4.4.4. Report ジェネレータ

ユニバーサル･デザインから Oracle Reports アプリケーション(.rdf)を生成します。モデリングによって Forms モジュールから Reports モジュールの呼び出し(またはその逆)を簡単に設計でき、そのまま生成することが可能です。

(32)

4.4.5. Visual Basic ジェネレータ

ユニバーサル･デザインによるモジュール設計は、Visual Basic ジェネレータにより、Microsoft Visual Basic 5.0 以上で利用可能な.vbp、.frm、.bas ファイルを生成します。生成されたファイルは Microsoft Visual Basic 5.0 以上でコンパイルすることによって、Oracle データベースとアクセス可能なアプリケーションとなります。

図：生成された Visual Basic アプリケーション

4.4.6. MS ヘルプジェネレータ

モジュール設計の過程で各モジュール項目にユーザー･テキストを定義できます。このテキスト情報を使って、Form アプリケーション、Visual Basic アプリケーションで利用可能な MS ヘルプのための.hpj、.hm および.rtf ファイルを生成します。これらは MS ヘルプ･コンパイラでコンパイルすることにより、利用可能な.hlp ファイルとなります。

4.5.

4.5. リポジトリ･ツール

リポジトリ･ツール

4.5.1. Matrix Diagrammer

Matrix Diagrammer は、３つのカテゴリの情報を縦軸、横軸、交差点に分けてその関係を分析するためのツールです。例えば、データとプロセスのライフサイクルを Matrix Diagrammer で分析する場合には、縦軸にデータ、横軸にプロセス、交差点にライフサイクルの登録、修正、削除、照会をおくことで分析が行えます。

(33)

図：Matrix Diagrammer

4.5.2. Repository Reports

リポジトリに貯えられた様々な設計情報を組み合わせたレポーティングを行います。このレポートは Oracle Reports を使って作成されており、その 1 コンポーネントである Report Builder を使ってカスタマイズすることが可能です。この Repository Reports に含まれるレポートは以下の種類のものです。 • 設計情報のリストリポジトリ上の情報を使ってシステムの設計仕様をレポートします。レポートの元となる Reports ファイルをカスタマイズすることにより、そのまま仕様書として利用することも可能です。 • 設計情報の品質検査設計されたパラメータ等に不当な数値が設定されていないかどうか、設定不足のデータがないか、をチェックしてレポートします。 • 影響分析設計仕様の変更が一個所であっても、それがもたらす影響は一個所ではありません。このレポートでは、どこに影響を及ぼすのかを把握するために、依存する設計情報をリストできます。選択された 2 つのオブジェクト･タイプの相互参照マトリックス内で選択された個所の詳細な定義情報を表示

(34)

4.6.

4.6. Repository Object Browser

Repository Object Browser

NEW!

SCM リポジトリへ格納された情報を Web ブラウザから参照するための機能が用意されています。これを Repository Object Browser と呼びます。

Repository Object Browser には以下のような機能があります。

Navigator NavigatorNavigator Navigator

SCM ツールである Repository Object Navigator と同じようなインターフェースが Web ブラウザ上に表現され、ブラウザの左側に表示されるツリーからオブジェクトを選択すると、その情報が右側に表示されます。

Search SearchSearch Search

(35)

また、詳細検索モードを使用して、自由に Where 句を追加した検索を実行することも可能です。 Report ReportReport Report 選択された設計情報の情報がレポートとして表示されます。この機能により、これまで設計仕様書を印刷して開発チームに配布していた作業は簡略化され、開発チームに所定の URL を通知するだけですむようになります。リポジトリに格納され、チェックインされた情報はすぐさまこのレポート機能で参照可能になるため、時間差なしの最新情報を常に提供できます。レポート内に表示されるほかの関連する設計情報はすべてリンクされており、クリック一つでその情報のレポートを即座に表示できます。ファイルのアップロードファイルのアップロードファイルのアップロードファイルのアップロード////ダウンロードダウンロードダウンロードダウンロード

権限を与えられたユーザーは、リポジトリに対して、Repository Object Browser 経由で Web ブラウザからファイルをアップロード/ダウンロードできます。この機能は、ドキュメントなどのファイルをリポジトリで集中管理する場合に有効です。仕様書を担当するユーザーは、特別なツールを用意することなく、リポジトリにファイルをチェックインして公開できます。

(36)

4.7.

4.7. 4.7. Oracle

Oracle

Oracle Software Configura

Software Configura

Software Configuration Manager

tion Manager

Oracle Designer の各コンポーネントは、 Oracle Software Configuration Manager と完全に統合されています。常に Oracle Software Configuration Manager のリポジトリへアクセスして、そこに設計情報を格納します。ここでは複数ユーザーが同時にシステム設計できる環境が提供されています。アプリケーション・システムという単位でプロジェクトのようにシステム情報を管理し、プロジェクト間での共有の制御や設計情報の再利用を可能にします。また、各リポジトリ･ユーザーに対して、アプリケーション・システム単位で、選択/挿入/更新/削除/共有/管理というレベルの権限を付与でき、マルチ･ユーザーでの設計情報の調整や仕事の分割に対する支援を行います。リポジトリに対して設計情報の入力/修正が行われると、その実行日、ユーザー名が自動的に記録されます。設計情報のそれぞれに、記述/注記/コメントといった多くのテキスト情報を付加できるため、本質的な設計情報以外のさまざまな情報を一元管理できます。また、最初に用意されている各オブジェクトのプロパティで不足な部分はユーザー拡張性という形で追加できます。すべての設計情報はリポジトリから自由に引き出すことが可能であり、これは、リポジトリによる設計が、仕様書作成を兼ねることを意味します。必要なレポート(仕様書)のテンプレートさえ作っておけば、あとは設計段階で入力されたデータで仕様書が簡単に作成可能になります。システム開発は様々な立場の人々が携わる作業です。エンド・ユーザーとの会議を元にした不確定要素の多い仕様書を作成し、それを基に開発チーム内でミーティングを行うといった方法では、開発チーム間での意思統一に限界がある上、最終的なシステムがエンド･ユーザーの要求満たしていないということになりかねません。開発チーム全員が共有するリポジトリに仕様を格納することで、スムーズな情報伝達や意思の統一を計ることができ、その都度、エンド・ユーザーへの確認を取ることでシステムの完成度は高まります。

Repository Administration Utility

リポジトリのインストール、移行やユーザー管理を行います。

Repository Object Navigator

のすべてのオブジェクトを管理するツールです。

Dependency Manager

オブジェクト間の依存性を抽出して、参照できます。

Command Line Utility

バッチ･インターフェイス用に用意されています。

(37)

5. 開発手法

開発手法

Oracle Designer の各コンポーネントは、リポジトリを通して、双方向に連携します。代表的な開発手法への適用例を以下にあげます。

・ RAD(Rapid Application Development)

下流工程を支援するツールを中心に使って、すばやくデータベース/アプリケーション開発を行います。モデリングを中心としたコーディング･レスな設計から、ジェネレータによってアプリケーションのプロトタイプを生成します。生成されたアプリケーションは、エンド開発ツール(Oracle Forms など)を使ってより洗練させ、再びデザイン･キャプチャ機能によってその追加された設計情報をリポジトリに戻すことができます。・ IE(Information Engineering) 伝統的な開発手法です。上流工程からじっくりと分析を行い、システム要求に対する情報を集約しながら開発するトップダウン･アプローチです。大規模システム開発に使われ、様々な成功を収めています。

・ BPR(Business Process Re-engineering)

現状のビジネス･モデルを分析し、どの業務プロセスに問題があるのかを把握します。これによってさらなるシステム要件を導き出します。・ Design Capture 既存のデータベース/アプリケーション･モデルをリポジトリへリバースして、それを再利用する手法です。戻された情報を利用して、他の開発手法にうまく適用させていくことにより、既存情報を用いた効率の良いシステム開発を可能にします。

(38)

6. 稼動環境

稼動環境

Oracle Designer は開発環境にのみ利用されるツールです。この開発環境には Oracle Software Configuration Manager のリポジトリが必須になります。

その他、開発の目的や最終的な実行環境に応じて以下のソフトウェアが必要になります。 Web PL/SQL アプリケーション

を設計する場合

実行環境に Oracle Application Server R1.0.2 以上が必要です。

Visual Basic アプリケーションを設計する場合

生成される.vbp ファイルをコンパイルする際に、Microsoft Visual Basic 5.0 Professional Edition 以上が

必要です。

MS ヘルプを生成したい場合開発環境に MS ヘルプ･コンパイラが必要です。 Oracle 以外のデータベースへ

接続する場合

(39)

7. 最後に

最後に

Oracle Designer は、Web 環境とクライアント/サーバー環境との両方のシステムを構築可能な開発環境を提供します。このシステム設計工程をモデル･ベースで行うことにより、単に設計を支援する、開発の生産性を向上させる、というだけでなく、設計されたシステムの情報を共有でき、今後のシステム設計のベースとすることができます。これまでのように、システムを使い捨て的に扱うのではなく、その中心にあるシステム･モデル･データを企業の資産として貯えていくことを可能にします。さらに、ラウンドトリップ･エンジニアリングによって、Oracle Designer のもつ利点と、フロントの開発ツールの利点を融合させた開発および管理手法を実現できます。フロントの技術はすさまじい速度で進化していきます。Java、PL/SQL、Visual Basic、C++、HTML、 JavaScript など、環境に見合ったシステムを構築しようとすればそれだけ多くの言語を取得し、それらをメンテナンスし、かつそれらの言語の進化についていかねばなりません。こういった最終的なフロントの技術に惑わされない、システムのコアとなる部分(データおよびアプリケーション)をモデル化し、それを資産として無駄にしないことが重要です。モデル･ベース開発環境とラウンドトリップ･エンジニアリング、この 2 つのキーワードによって開発コストの低減や市場への速やかな適応というメリットを実現できます。

(40)

8. Appendix

8.1.

8.1. 8.1. FAQ

FAQ

FAQ（よくある質問）

（よくある質問）

問い合わせの多い質問と、それに対する回答を用意しました。 Q1. Oracle Designer はどこから使えばよいのですか? Oracle Designer にはいくつものコンポーネントが用意されているため、逆に「どこから使ったらよいのかわからない」といわれることがあります。「最上流の工程から使わないといけないのではないか」と誤解されることがありますが、決してそうではありません。「5 開発手法」でも紹介しているように、様々なアプローチを適用できます。例えば、Oracle データベースに完全対応したデータベース設計を目的として Oracle Designer を利用してもいいし、既存システムへのアプリケーションの追加のためだけに利用することも可能です。Oracle Designer の主な利用用途は、 • Oracle 完全対応のデータベース設計 • アプリケーション設計の統合管理 • システム設計情報の一元管理です。もちろん、すべてに利用してもかまいませんし、この一部のために Oracle Designer を使用するというのでもかまいません。 Q2. リポジトリにはどのくらいまでデータを貯えられますか? 特にリポジトリ側での制限はありません。リポジトリが格納されるデータベースや表領域に依存します。これは企業レベルのシステムの設計情報でもリポジトリで管理可能なことを意味します。実際、企業向け ERP パッケージである Oracle E-Business Suite の一部の設計情報はすでにリポジトリで管理されています。

Q3. Oracle Designer と Oracle Forms/Reports はどう使い分けるのですか?

Oracle Designer と Oracle Forms/Reports では、システム開発のなかで、受け持つ領域が分かれます。アプリケーションの設計工程として、アプリケーションにどういう機能を持たせるのか、どのようなデータ操作を行うのか、アプリケーション間をどのように連結させるのか、といった仕様に近い部分を決める作業があります。この段階を Oracle Designer を使って行うことにより、その情報から自動的にコーディングできることは大きな魅力です。 Oracle Forms/Reports は、このコーディングの対象となる、フロント･エンド層を受け持ちます。アプリケーションの仕様決定工程を担当する設計者が Oracle Designer を利用し、その仕様に基づいたアプリケーションを、データベースへの優れた親和性を持つ Oracle Forms/Reports へ向けて自動生成し、開発者が追加コーディングを行って実際にシステムとして完成させるのが理想の開発方法です。このようなアプリケーションの仕様決定工程を担当する設計者が Oracle Designer を利用し、そこから生成されたアプリケーションをベースとして、開発者が追加コーディングを行うのがひとつの方法です。 Oracle Forms/Reports は、システムの仕様を実装する部分を受け持つため、単独でデータベースアプリケーションを開発できますが、上流行程のシステム仕様を定義する機能は持っていません。Oracle Designer は非常に高いアプリケーション生成とロジック管理能力を有し

Oracle Designer Reviewer's Guide

Oracle Designer

Reviewer’s Guide

目次

目次

目次

目次

1. はじめに

はじめに

はじめに

はじめに

2. 製品コンセプト

製品コンセプト

製品コンセプト

製品コンセプト

2.1.

2.1.

2.1.

2.1.

システム開発の現状

システム開発の現状

システム開発の現状

システム開発の現状

2.2.

2.2.

2.2.

2.2.

モデル･ベース開発

モデル･ベース開発

モデル･ベース開発

モデル･ベース開発

2.3.

2.3.

2.3.

2.3.

コード

コード

コード

コード

vs

vs

vs

vs モデル

モデル

モデル

モデル

2.4.

2.4.

2.4.

2.4.

設計だけでなく、システム管理へ

設計だけでなく、システム管理へ

設計だけでなく、システム管理へ

設計だけでなく、システム管理へ

3. 製品の特徴

製品の特徴

製品の特徴

製品の特徴

3.1.

3.1.

3.1.

3.1. Oracle

Oracle

Oracle

Oracle に最適なデータベース設計

に最適なデータベース設計

に最適なデータベース設計

に最適なデータベース設計

設計可能なデータベース･オブジェクト

オープンな

DB サポート

3.2.

3.2.

3.2.

3.2.

モデルによるアプリケーション設計

モデルによるアプリケーション設計

モデルによるアプリケーション設計

モデルによるアプリケーション設計

3.3.