福岡寿和／吉野未亜 FUKUOKA,Toshikazu/YOSHINO,Mia


Designer/2000は何をデザインするのか

　企業の情報システムがホストコンピュータからクライアントに，すなわちWindowsパソコンを使ったクライアントサーバーシステムに移行すると，それにあわせて今までのウォーターフォール型の開発スタイルのマイナス面である「設計書ばかりで一向に動くものができてこない」という点が問題になり始め，スパイラルフロー型の開発スタイルに移行してきています．
　このことは，Windowsパソコンのプログラム言語の主流が，Visual BasicなどのRADツール（作りながら設計していく）であることも関係していると思います．現在のRADツールの多くは，Windows標準UI（ユーザーインターフェイス）以外を実装しようとすれば，たちまち多大なコーディングが必要になり，市場の動向や顧客の好みの変化のスピードにあわせた開発スピードが確保できなくなります．そのため，従来のようなお客様にあわせた独自UIの実装に時間を割くのではなく，いかに標準UIで使いやすくものを短期間で開発できるかが受託開発時の指針になりつつあります．また，毎年，OS自体が更新され，それにあわせて標準UI規約や開発言語仕様が拡張され，なおかつ上位互換性が十分でない現状では，プログラムは資産ではなく，ある一定期間しか価値を持たない「情報消費財」になってしまったのかもしれません．開発期間中にその価値ある期間が終わらない（OSが変わったり，開発言語がバージョンアップしたりしない）ように，また，少しでも長く情報システムを活用して貰うために，大規模システムでもサブシステムごとにスパイラルフロー型の開発スタイルで部分提供していくような開発スケジュールが求められています．
　このとき，各サブシステムを結びつけるのがRDBMSであり，その上に構築したデータ構造こそが，情報システムの中核，つまり，そこに蓄積されるデータと共に，その企業の「情報資産」となるのです．そして，データ構造は，「システムで管理されるべき理想的なあるべき姿」に基づいて設計されて，初めてその資産価値を十二分に発揮することができます．ですから，クライアントのUI設計以外の局面，たとえば，3階層モデルのデータベース層やビジネス層の開発には，スパイラルフロー型の開発スタイルではなく，データ中心の開発アプローチ（DOA，Data Oriented Approach）への転換が求められているのです．
　Oracle Designer/2000は，DOAの各局面で発生する情報を蓄積し，業務担当者とシステム設計者の間の情報共有のしくみを備えています（画面1）．

画面1：Designer/2000


DOA ―― プロセスモデリング

　DOAでは，まず，これからシステム化しようとする（あるいは現状を分析する）業務の中でどんな手続きが行われ，その手続きでどんな情報が受け渡されるのかを整理していく必要があります．この作業を行うときに活用されるのが画面2のBP図（ビジネスプロセスダイアグラム）です．BP図を作成するときに重要なのは，コンピュータで処理する手続きと人間系で処理する手続き（コピーをするとか，書類を郵送するなど）の両方を記述し，それに伴う物の流れや情報の流れも記述して，BP図上でこれらを明確に区別していくことです．このBP図の作成をサポートするのがDesigner/2000のプロセスモデラ（PM）です．

画面2：プロセスモデラによるBP図

BP図を作成して，現行のビジネスプロセスから重複している手続きを統合したり，情報の流れのボトルネックを改善することができます．


DOA ―― システムモデリング

　プロセスモデリングがある程度固まってきたら，現実の業務を踏まえた上で

の2つの作業を行います．

１，プロセス分析

　プロセス分析に必要な作業は，情報の流れがどこで発生し，どこで処理され，どこで利用されるかをモデリングすることです．この作業を行うときに活用されるのが画面3のDFD（データフローダイアグラム：昔から使われているためかBP図と異なり，DF図とは呼ばないようです）です．DFDを作成するときに重要なのは，手続きの主体（組織）と手続きを切り離して，情報がどこから発生して，どこに出て行くのか図式化することで，処理の効率化，省力化を検討することです．このDFDの作成をサポートするのがDesigner/2000のデータフローダイアグラマです．

画面3：データフローダイアグラマによるDFD

２，データ分析

　BP図やDFDが帳票などの現実に存在している物理的な形で情報を記述していました．データ分析では，BP図やDFDでモデル化した情報について，データ構造と内容，他の情報との関連を明確にしていきます．この作業を行うときに活用されるのが画面4のER図（エンティティリレーションシップダイアグラム）です．そしてER図の作成をサポートするのがDesigner/2000のエンティティリレーションシップダイアグラマ（ERD）です．

画面4：エンティティリレーションシップダイアグラマによるER図

　ER図を作成するときに重要なのは，業務上必要とされる情報の単位としてのエンティティとその属性であるデータ項目を定義し，エンティティ相互の関係を図式化して，「システムで管理される理想的なあるべき姿」を追求することです．この「理想的なあるべき姿」は，ER図で表記した時に冗長データがない姿になりますが，冗長データの抽出と除去には，正規化手法と業務知識を駆使する必要があります．あるデータが冗長性を持っているかどうかは，ビジネスロジック（業務知識）に大きく依存しているので，DOAのなかで最も業務担当者と開発者の連携が必要な部分です．そして，業務担当者からいかにして客観的なビジネスロジックを聞き出せるかが開発担当者に求められる資質になります．


DOA ―― システムデザイン

プロセス構造の定義

従来のクライアントサーバーシステムでは，RDBMS上にロジックをのせることがなかったので，プロセス分析の結果を反映すると言っても，Visual Basicなどのプログラムの構造の問題であってRDBMSとは切り離して考えられるものでした．しかし，Thinクライアントや効率よいシステムを構築するためにRDBMSのトリガーやストアドプロシージャを駆使するには，プロセス構造の中から，サーバー側に構築する部分を切り分ける必要があります．
　Designer/2000では，モジュールロジックナビゲータ（MLN）を使って，サーバー側に格納するロジックを管理します．

データ構造の定義

　データ分析の最後は，ER図上で「理想的なデータのあるべき姿」として定義された概念をデータスキーマ（Oracleの表定義など）という現実に変換して，RDBMSにあわせて，表をどの表領域に割り当てるか，列の制約やキー制約などを決定していきます．このとき，業務知識だけではなくOracle7の索引領域と表領域の物理位置によるパフォーマンスの違いやクラスタ化やパーティションビューなどのデータ構造に結びついた最適化機能を選択する知識などが必要です．この作業は，Designer/2000のトップメニューで「データスキーマ」と表示されているデータダイアグラマ（DSD）で行います．複数人でDesigner/2000を使って設計するときは，このDSDの作業担当者には，一番Oracleに精通しているメンバを割り当てることが重要です．


Designer/2000の導入時の注意点

　それでは，DOAにそって，FAQシステムを設計しながら，Designer/2000の具体的な使用方法を説明したいと思いますが，Designer/2000を導入するときに何点か注意点があります．
　Designer/2000は，Oracle7およびOralce8をデータベースサーバーとしたクライアントサーバーシステムです．ですから，最初にDesigner/2000を導入するには，クライアント側のインストールと共にデータベースサーバー側のインストールが必要です．必ず，「Oracle Designer/2000 for Windows 95/NT インストレーション・ガイド」を一読し，それから，そのガイドを手元に置いて内容を確認しながらDesigner/2000の導入をしてください．GUIインターフェイスが中心になってから，利用者だけではなく開発者すらもマニュアルを見ない傾向がありますが，斜め読みでもよいので，マニュアルを一読して，どんな情報が含まれているかくらいは覚えておきましょう．そして，Designer/2000の利用者とは，まさにこれから情報システムを構築する開発者なのですから，まず，マニュアルを一読して，下準備を整えてから導入を始めましょう．
　ただし，Windows95/NT版を導入したときは，「インストレーション・ガイド」に記載されているORACLE.INIは作成されません．「インストレーション・ガイド」にもよく読むと「Windows 3.1対応の」と記載されていますが，ORACLE.INIが存在することを前提として書かれている部分もあるので注意してください．


Designer/2000の適用 ―― プロセスモデリング

プロセスモデラ（PM）

　今，FAQシステムの業務手続きが

１，PCDNスタッフは，NewsGroup上から有益な情報をFAQとして登録する
２，PCDNスタッフは，FAQとして登録した回答に誤りを発見したときは，回答内容を変更する
３，PCDN会員は，Webブラウザー上で検索キーを指定してFAQを検索する
４，FAQの検索結果は，検索を依頼したPCDN会員のWebブラウザー上に表示する

の4つだとします．PMを起動すると，左端が「未指定」と表示されただけの画面が表示されます．最初の作業は，この左端に組織として「PCDNスタッフ」と「PCDN会員」を登録します．そして，業務要件の組織が明確になったら，その組織に含まれるプロセス（業務手続き）を配置して，その間の流れを記入していきます．FAQシステムでは，「PCDNスタッフ」組織に業務手続き１〜２を，「PCDN会員」組織に業務手続き３〜４を配置します（画面2）．このとき，プロセスごとに必要な時間やコスト，頻度を設定することにより，PMが現在のビジネスプロセスのクリティカルパス（一番時間がかかる流れ）を自動的に検出してくれます．この検出結果は，特に人間系の処理のどこを改善すれば業務の効率化が行えるかなどの指針になると思います．


Designer/2000の適用 ―― システムモデリング

データフローダイアグラマ（DFD）

　DFDでは，PMで定義した手続き（画面5）やフローなどもインクルードできます．なお，インクルードしたデータフローを削除するとPM上でも対応するフローが削除されるので注意してください．

画面5：手続きのインクルード

　また，DFDからERDを参照することはできますが，DFDのデータストアをエンティティに反映することはできません．それは，データストアが中間ファイルなどの記述などにも活用できるため，それをERDに反映できてしまうと，ER図を記述していく上での注目点である「理想的なあるべき姿」を崩すことになるからです．

エンティティリレーションシップダイアグラマ（ERD）

　ERDは，データ分析のスタート地点です．そのため，DFDのようにPMやERDの情報をリポジトリから参照して，情報を定義する必要はありません．正規化を意識しながら，エンティティとリレーションシップを定義していきます．
　ERDはDesigner/2000で作業するときの中心的機能ですが，使い勝手が良くありません．ERD上で正規化を行おうとすると，ダイアログ画面とメイン画面の間を何度も行き来しなければいけません．作業効率を上げるためには，事前にある程度の正規化を行っておく必要があります．
　FAQシステムでは，

の3つのエンティティを定義します．また，業務手続き２からの分析結果として，「同一回答が複数のFAQで使われる可能性があり，その変更履歴をそれぞれのFAQごとに保管する」ことが発生したので， も定義します．そして，エンティティの配置が終わったら，その間のリレーションシップを定義します（画面4）．リレーションシップを定義するときに，その名称を指定する必要がありますが，この名称はきちんとつけようとすると難しいものですが，ERD以外ではほとんど使われることがないので，単純に相手側のエンティティ名などを指定するのがよいでしょう．リレーションシップの定義が終わったらｌ氓"fータ項目を定義します．Designer/2000は，外部キーをデータ項目として表記しない方法をとっていますので，リレーションシップを定義する前にデータ項目の定義を始めると，つい外部キーまで定義してしまって，あとでその項目を削除する無駄手間が発生します．なお，外部キーを連結主キーとして登録したいときは，画面6のように[エンティティの編集]ダイアログボックスの[UID]タグで[候補リレーションシップ]から[一意識別子の内容]に外部キーを移動してください（主キーは自動的に[一意識別子の内容]に格納されています）．

画面6：[エンティティ編集]ダイアログ


Designer/2000の適用 ―― 設計ウィザード

アプリケーション設計ウィザード（ADW）

　ADWは，業務機能をモジュールに変換します．この過程で初めて，どの言語で業務機能を実現するかを決定します（画面7）．ADWを使うときの注意点としては，ADWのモジュールの変換ルールが

のようになっている点です．もちろん，モジュール変換後にもモジュールのタイプを変更できます．

画面7：アプリケーション設計ウィザード（ADW）

　なお，いったん変換したモジュールを再度変換するときは，リポジトリオブジェクトナビゲータ（RON）でモジュールを削除してください．
　また，モジュールに変換後に修正した内容をDFDへ反映する方法はありません．そういった意味では，DFDがプロセス分析の終点と言えるかもしれません．

データベース設計ウィザード（DDW）

　DDWは，ERD上で「理想的なデータのあるべき姿」として定義された概念をデータスキーマ（Oracleの表定義）という現実に変換します．（画面8）．DDWが完了すると，Designer/2000のリポジトリにエンティティから生成された表が定義されます．（画面9）．

画面8：データベース設計ウィザード（DDW）

画面9：リポジトリ

　DDWを使う上で注意しなければいけないのが，ERDで定義する複数名と短縮名です．この複数名が表の名前になり，短縮名が外部キー項目名の一部になります．また，[実行オプション]タグで，DDWが表や列の修正できるように設定できます（デフォルトは作成のみ）が，いったんエンティティを表に変換したあとに，エンティティを削除したり，データ項目を削除しても，それに対応する表や列の削除は行われません．表や列の削除を行いたいときは，DDWを使う前に，RONを使って，リポジトリ上から表を削除してください．


Designer/2000の適用 ―― システムデザイン

データダイアグラマ（DSD）

　DSDでの最初の作業は，DDWで変換した表をインクルードすることです．インクルードは，小規模なシステムでは，すべての表を一度にインクルードしてもよいでしょうし，大規模なシステムでは，検討項目ごとに表のグループを複数作成して別々に作業したほうがよいでしょう．表をグループ化して，その単位で作業すれば，画面サイズやクライアントのリソースの問題を回避できます．
　なお，プロセス分析と異なり，DSDでの変更をERDに反映するには，DSDとERDの[ユーティリティ]-[表からエンティティへのレトロフィット]により可能です．

モジュールストラクチャダイアグラマ（MSD）

　ADWで業務機能をモジュールに変換しても，それはあくまでも「モジュールの候補」として変換されているだけで，システム生成の対象になりません．そこでMSDでモジュールのインルードを行い候補の受託を行います．インクルードするときは，画面10で[候補のみ]チェックボックスをチェックした後，[ファイルの適用]ボタンをクリックして，インクルードすべきモジュール一覧を表示させてください．また，最初，インクルードされたモジュールには，「候補アイコン」が付いていますので，[ユーティリティ]-[候補の受託]で候補の受託をしてください（画面11）．なぜこのような仕様になっているかといえば，MSDで「マニュアル」モジュールを除去するためです．

画面10：MSDでのインクルード時の設定

画面11：MSDでの受託後のモジュール

　Visual Basicのモジュールを生成するときには，MSDで必ず作業しておく事項があります．それは，プロパティの[定義]-[モジュール]タグで，短縮名に6文字以内の名称を設定することです．システム生成では，この短縮名に2桁の通番を付加してMDIの子フォームを生成するので，ここで6文字以内の名称を設定しておかないと生成に失敗します．

モジュールデータダイアグラマ（MDD）

　MDDは，MSDで定義されたスクリーンとレポートのそれぞれのモジュールが，DSDで定義された表のどの列を表示，検索，更新するかなどを定義します（画面12）．

画面12：モジュールデータダイアグラマ（MDD）

　Designer/2000では，このMDDの定義情報を基にして画面構成が決定されます．つまり，異なる言語であっても，同一のMDDから生成すれば，同じ機能を持った画面が生成できることを意味します．たとえば，画面12の二重線で囲まれた範囲が，MDIの1子画面に相当します．また，表取扱細目の表示位置が子画面の中での各テーブルの表示位置になります．この表示位置は表をMDDに記入してからは変更できないので，画面での位置関係を考慮しながら，記入していってください．今回の例では

の順で記入しました．

モジュールロジックナビゲータ（MLN）

　MLNは，PL/SQLをドラッグ＆ドロップを使って記述していく，PL/SQLエディタです（画面13）．さらに，構文チェックも行えるので，Oracle7への登録前に構文エラーを除去できるので，PL/SQLを使った開発での作業効率が向上するでしょう．

画面13：モジュールロジックナビゲータ（MLN）

システム生成（サーバー）

　Serverジェネレータは，DSDとMLNで作成されたリポジトリ情報から

を行います．

システム生成（Visual Basic）

　MDDで画面12のようにモジュールと表の関係を定義すると，画面14のような画面を表示するVisual Basicのモジュールが生成されます（画面15）．ちなみに先頭がPCFQ10で始まるモジュール以外は，共通モジュールとして，

にあらかじめ登録されているモジュールです（サンプルのDDJ\DES2K\PCFQ10ディレクトリに，共通モジュール以外のファイルを収録しています）．

画面14：VB実行画面1

画面15：VBプロジェクト
 　今回生成したのは，いわゆるデータエントリ系なので，実用的にはDSDやMDDでもう少し画面スタイルを規定するような記述が必要なようです．しかし，今回のようなプロセスでも，マスタメンテナンスのような簡単なものならば十分実用に耐えるモジュールを生成してくれます（画面16）．たとえば，
    １，DSDでOracle7の表定義をリバースエンジニアリング
    ２，MSDでモジュールを定義
    ３，MDDでモジュールと表を関連付け
    ４，Visual Basicのモジュール生成
という手順でマスタメンテナンス系の画面ならば作成可能です（サンプルのDDJ\DES2K\PCFQ20ディレクトリに，共通モジュール以外のファイルを収録しています）．

画面16：VB実行画面2

　また，Oracle7との接続には，ODBCではなく，Oracle Objects for OLE（oo4o）V2.0を使っているので，パフォーマンス的にも必要十分だといえるでしょう．そして，oo4oの解説情報が少ない現状では，Designer/2000の生成するモジュールは，貴重な情報元になると思います．


最後に

　このようにDesigner/2000は，大変良くできたCASEツールですが，実際にシステム構築に適用すると何点か使いづらい点があります．代表的なところでは，データ項目の整理統合や分類を行う機能やネーミングルールのチェック機能が欠落している点です．これは，ERDで正規化を行おうと思うとエンティティの統廃合やデータ項目の移動などの作業が非常に使いづらいということです．ドラッグ＆ドロップでエンティティ間のデータ項目の移動が行えたり，範囲指定してエンティティの分割ができるような操作性が必要だと思います．Designer/2000のリポジトリの構造が公開されているといっても，公開情報は，テーブル定義レベルのみで，そのリポジトリに設定する情報の詳細やリポジトリの使用例などの情報がないので，足りない機能をVisual Basicなどで自作するのも現実的ではないと思います．ERDの分析ツールとしての使い勝手が向上することを期待します．

サンプルのダウンロード

VB Magazine ライブラリ | Visual Basicコースホームページ
int21 ホームページ | PCDN ホームページ