構造化オブジェクト指向設計手法の提案

奈良先端科学技術大学院大学
鳥居研究室
臼井義美

１．概要

１．１　提案する設計方法の考え方

　現在、ビジネス・アプリケーションの分析、設計方法としてよく利用されているのは構造化設計とオブジェクト指向設計である。構造化設計技法は、1970年代にソフトウェアの設計に工学的な手法を取り入れ、標準的なルールに基づいて仕様を記述するという重要な役割を果たし、既に長い間開発現場で利用されてきた。一方、オブジェクトの概念が導入されたのは、1980年代の後半からである。当初は、AdaやSmalltalkによるオブジェクト指向言語による設計のために利用され、純粋にオブジェクトを中心に設計する手法が提案された。この方法は、現実世界に存在するモノがコンピュータの中で構築したオブジェクトの写像と捉えることによって、両者が自然に対応づけられ、GUI(Graphic User Interface)などを用いたシステムでは非常に有効な設計方法として利用された。

　ところが、オブジェクト指向は、その後Code/YourdonやRumbaugh、Shlaer/Mellor等によって、従来構造化分析、設計技法で用いられたデータフロー図、状態遷移図、ER図などを用いてオブジェクト指向分析、設計を進めることを提唱するようになった。筆者も、従来から純粋なオブジェクト指向設計によるだけではビジネス・アプリケーションの開発に利用しずらいという主張をしてきた。

　そこで、オブジェクト指向設計と構造化設計をどのように組み合わせるかが問題になるが、筆者はオブジェクト指向で作成したソフトウェア部品を構造化設計による手法で組み立てる方法を考案し、その手法による設計を支援するためのツールを開発した。

　その設計支援ツールでは、仕様書の断片をソフトウェア部品として扱い、それらを合成することによって目的のアプリケーションの仕様を完成し、ターゲットマシンで稼働するプログラム言語を生成する方法を採用した。

　 また、インターネットの普及にしたがって、ビジネス・アプリケーションも分散ソフトウェアへの対応は不可避となってきた。本設計支援ツールは、分散ソフトウェアの設計に適しているだけでなく、分散開発環境におけるアプリケーションの分析、設計においても効果的に利用できるものと考えている。

　本稿では、提案する開発技法について説明し、それを支援するためのツールとそれを利用した場合の設計の進め方について述べる。さらに、分散ソフトウェア開発への適用について説明し、分散オブジェクト指向の開発方法として提案する仕様エージェントへの橋渡しとする。

　ここで、以下の説明で用いる用語について、確認しておく。

　オブジェクトという言葉は、一般に言われているオブジェクト指向でいうオブジェクトとほぼ同様の概念であるが、クラスの考え方などにいくつかの違いがある。また、データの仕様記述とプロセスの仕様記述をそれぞれ部品として扱い、それぞれをデータ・オブジェクト、プロセス・オブジェクトと呼ぶことに注意されたい。

　したがって、通常のオブジェクトはデータとメソッドが一体となったプログラム・モジュールを指し、本稿でもそのような使い方をするが、データ・オブジェクト、プロセス・オブジェクトと呼ぶときは、データ仕様部品をオブジェクトとして扱ったもの、プロセス仕様部品をオブジェクトとして扱ったものと考えていただきたい。

１．２　オブジェクト指向設計と構造化設計の融合

　まず、オブジェクト指向設計技法と構造化設計技法について、それぞれの長所と問題点を整理してみる。

　一般にオブジェクト指向設計の利点として、

などがあげられるが、他方

というような問題点がある。

　一方、構造化設計手法では、

という特徴があるが、

などの欠点がある。

　現在、オブジェクト指向によるシステム分析／設計手法が各種提案されているが、ビジネス・アプリケーションの開発にはまだ十分活用されているとは言えない。それはオブジェクト指向による開発経験の不足によるという理由だけでなく、目的のアプリケーションの仕様がエンドユーザに容易に理解できるような形式で記述するのが難しいことや、処理の内容やその手順が仕様書レベルで明確に記述できないことも要因の１つであると考えられる。

　また、これまで提唱されているオブジェクト指向分析／設計では、ビジネス・アプリケーションの問題領域を表現できる実用的な記述法が提示されておらず、構造化分析／設計を取り入れた分析／設計手法でもERモデルを発展させたオブジェクト図に、データフロー図、状態遷移図などの既存の図式を併用しているのみで、それらの図式に一貫した関係が読み取りにくく良質の設計仕様書として利用するには十分でないと考えている。

　そこで、筆者はビジネス・アプリケーションの分野を対象とした分析／設計にあたって、オブジェクト指向分析で仕様部品を作成し、構造化設計に基づいて合成するという方法を採用し、エンドユーザにも理解しやすい図式を用いた設計法を提案する。

１．３　オブジェクト指向設計技法からの採用

　一般に、オブジェクト指向による設計を行うに当たってその仕様の中心となるオブジェクト間の主な関係は、次の３つで表現される。

　本稿で提案する設計支援技法では、この３つのオブジェクト同士の関係を次のように表すことにしている。

　また、この３つの関係を本設計技法では、クラス図、データ構造図、プロセス図の３種類の図式で表示することにする。

図１　オブジェクト指向を表現する図式

１．４　構造化設計手法からの採用

　本設計支援技法では、上記のオブジェクトの関係をもとに、次に示す構造化設計の手法を取り入れる。

すなわち、

　ところで、本設計支援技法は、仕様書を紙と鉛筆で描くことができるような仕様をエディタで電子的に記述するというのではなく、専用のツールがなければ設計ができないような手段と方法を採用している。すなわち、

などである。

　ここで述べたクラス、オブジェクト構成、データフローエリア、処理ユニットの関係を模式的に表示したのが次の図である。

図２　提案する設計技法の模式図

　以上のように、宣言的な設計に関してはオブジェクト指向を中心として行い、手続き的な設計に関する部分を構造化手法によって行うこととし、宣言的な記述をデータ・オブジェクトに集約し、手続き的な記述をプロセス・オブジェクトに集約し、それらの関係をエディタで常に視覚的に把握できるのが特徴である。

１．５　他のオブジェクト指向設計技法との比較

　ここで、オブジェクト指向による設計法の１つであるOMT法と本技法を比較してみる。[4]

　まず、OMT法ではオブジェクトの抽出を実世界のインスタンスをある視点に基づいて分類し、共通な性質を持つものをクラスとして定義している。本技法では、問題領域で使用される業務用語の名詞をデータ要素として論理クラスに体系化し、コンピュータ上に実装するときに用いるシステム用語を物理的クラスに体系化する。その後、両方のデータ要素を組み合わせて得られたデータ項目を、物理的クラスに関連づけて保存する。従って、OMT法では、分析／設計者が問題領域から何をオブジェクトとするかの決定を委ねられているが、本技法では問題領域に用いる用語について要求者と設計者の共通認識を定義することによって確定していくため、オブジェクトの決定が容易である。

　次に、OMT法ではオブジェクト間の関係をオブジェクト図として表現するが、本手法では先に述べたようにオブジェクト間の関係をis-a、has-a、関連の３つに区別して、それぞれクラス階層図、データ構造図、プロセス図で表現しており、これらの図の間の関係は支援ツールにより常に関連づけて管理し表示されるようになっている。

　また、OMT法によれば動的モデルを事象トレース図や状態遷移図で表し、機能モデルをデータフロー図で表しているが、本手法ではこれらを一括してプロセス図で表現することができる。従って、本技法の方がオブジェクト間のメッセージ交換のタイミングやメソッドの実行内容、状態の遷移の様子が理解しやすく、システムの全体の挙動を鳥瞰的に見ることができると考える。

　

　

以下にオブジェクト指向の代表的な技法と、本技法を比較してみた。

　

設計手法

意味の表現

構造の表現

機能の表現

Cord/Yordon 

オブジェクト図
汎化・特化

部分・全体 

状態遷移図
フローチャート

Shlaer/Mellor 

オブジェクト図

- 

状態遷移図
アクションデータフロー

Booch 

クラス図
オブジェクト図

包含 

状態遷移図
タイミング図
プロセス図

Martin/Odell 

オブジェクト図

構成 

イベント図
オブジェクトフロー図
Rumbaugh
(OMT)
 
オブジェクト図

集約 

状態遷移図
イベントトレース図
データフロー図

本技法

クラス図

データ構造図

オブジェクトフロー図

表１　各技法によるオブジェクトの表現方法

２　設計支援ツールについて

２．１　設計支援ツールの構成

　本設計技法は、専用の設計支援ツールのもとで有効に機能する方法であり、以下の説明ではこのツールの利用を前提として説明する。この設計支援ツールはMacintoshで開発しており、そのシステム構成を図３に示す。

（１）リポジトリ
データ部品、プロセス部品、設計済の仕様書、ソースコードの他設計ルールやソースコードを生成するための言語辞書などを保管する。
　
（２）データ定義エディタ
データ部品の作成、登録、再利用を行うためのエディタである。リポジトリからデータ部品を呼び出し、データ構造などを設計する。
　
（３）プロセス設計エディタ
プロセス部品の作成、登録、再利用を行い、アプリケーションのプロセス設計を行うためのエディタである。
　
（４）コード・ジェネレータ
完成した仕様書から、ターゲットとなる言語のプログラムコードを生成する。
　
（５）デバッガ
仕様書の作成時に静的、動的なデバッグを行う。

図３　設計支援ツールの構成

３．本技法による設計方法

３．１　ドメイン・モデルの設計方法

（１）データ・オブジェクト

　本設計支援ツールを用いたドメイン・モデル設計は、まず対象となる業務の目的を達成するための業務フローを作成する。設計者はリポジトリに登録されたオブジェクトのうち、業務フローに必要なものをアイコン、メニュー、ブラウザなどで取り出し、プロセス設計エディタ上に配置する。このとき取り出す要員、伝票、帳票、ファイルなどの資源を、データ・オブジェクトとみなす。既にリポジトリに登録されているオブジェクトについてはリポジトリから取り出して組込むが、初めて使用するオブジェクトは、既存のクラスライブラリを利用して最も継承する項目の多い位置に組み入れて作成する。既存の具体的なオブジェクトが利用できれば、下流工程で詳細設計に要する手間が省けることになる。

　

（２）データフロー

設計者は業務フローにおけるオブジェクトとデータの流れを、アイコンとそれらを結ぶアークで記述するが、詳細化の過程を経てデータ構造とデータフローの形で表現することになる。

図４　ドメインモデルの仕様記述イメージ

　次にプロセス設計エディタ上に配置したファイルなどのデータ・オブジェクトについて、もし未定義であったり再定義が必要な場合は、データ構造エディタを開いてデータ構造とその属性などを記述する。要求が曖昧な場合は、想定されるおおよそのデータ構造をメモ書き、もしくはリポジトリからの抽象的なデータ要素によって記録する。

　

（３）プロセスフロー

　一方、当該業務で行うべき処理の内容を、プロセス設計エディタ上にできるだけ時間的な順序に沿ってプロセスフローとして書き込んでいく。この工程におけるプロセスフローは、自然語で自由に処理の内容を記述してもよいが、当然リポジトリから利用できる部品があれば取り出して仕様書に組込む。エディタは未確定な処理内容は概要ユニットと呼ぶ入力枠に記述させ、詳細な記述が必要であることを適宜設計者に要求する。

　

図５　リポジトリと、データ・オブジェクト、プロセス・オブジェクトの関係

３．２　システム・モデルの設計方法

　本設計支援ツールを利用したシステム・モデルの設計では、ドメイン・モデルを詳細化し、ターゲットマシンで実行可能な仕様書にまとめる。この段階は主として構造化設計手法によって行うことにしており、エディタの支援のもとにデータ構造、データフロー、制御構造、処理フローを確定していく。

（１）データ構造

まず、システムで使用する入出力ファイル等についてデータ構造を確定する。リポジトリにクラス階層として体系化したデータ部品をクラスに対応したカスケードメニューで取り出し、属性を調整した後データ構造図に組み込んでいく。当該データ部品が未登録であれば、適切なクラスにインスタンスとして追加登録する。下流では人的資源等をさらに具体化する必要はないものと思われる。

開発中のシステムで使用しているデータ部品を削除したり、データ構造や、データ名、属性、制約などを変更した場合、本設計支援ツールエディタは影響を受けるプロセス部品やプロセス要素を検索し、調整を要求する。

（２）データフロー

データ構造図を確定すると、プロセス設計エディタはデータフロー・エリアを自動的に設定する。このエリアはデータ部品の時間経過を伴う状態遷移の表現である。通常はファイル単位等の大きなデータ部品ごとにデータエリアを表示しているが、ユーザの指示により随時リソースエリアを展開し、詳細なデータフローを見ることができる。また、マウスで注目したいデータフロー・エリアをクリックすると、当該データ部品に登録された内容を一覧できるデータ構造図が表示される。

本設計支援ツールでは、データフロー・エリアにデータの更新を伴う処理を記述したとき、当該データ部品に登録された属性、制約条件を検査する処理部品（検査部品と呼ぶ）が自動的に生成され、仕様書に組み込まれる。

データフローは、利用者が処理フローを記述する度に処理の内容を解析して自動的に描画してくれる。また、前後のプロセス部品相互のデータ構造や属性などが異なれば、エディタで調整できる。

本設計支援ツールでは、今後データ構造図よりテストデータを入力することを可能とし、実行時にデータフロー・エリアをモニターすれば、データの加工状況を調査できるような動的チェック機能を付加することができる。

（３）制御構造

本設計支援ツールは利用者が処理手順を記述するとき、ワーニエ法に基づいて処理に伴う制御構造の記述を支援する[8]。現在は物理的なデータ構造に基づいてのみ制御構造を支援しているが、将来はデータリンクを利用して論理的なデータ構造による制御構造の支援も行う予定である。

エンドユーザにとっては、プログラム仕様が構造化されて記述できるため、制御構造がシンプルとなり理解しやすい。また、制御構造は図式で表されるため、文書で記述した処理内容と明確に区別して表現できる。一般に、利用者は制御構造を繰り返しの重複、条件の組み合わせを少なくし、できるだけシンプルになるように仕様を設計して行くことによって、信頼性の高いシステムを構築できる。

（４）プロセスフロー

下流工程における処理内容の記述は、エディタが提供している「データ名＋基本動詞」もしくは「データ名＋プロセス部品名」の形式に制限された自然言語風に記述していく。すなわち、利用者はマウスでデータ・オブジェクトの名称をクリックすることによって、そのデータに付随する基本動詞、及びそのデータを使用しているプロセス部品のメニューが表示されるため、再利用できるプロセス部品があれば選択する。いずれの場合も選択したプロセス要素を設計中のプロセス設計エディタの処理フローとして組み込み、プロセスの内容を表示する。プロセス部品を取り込んだ場合は、そのプロセス要素をマウスでクリックすることにより、部品の内容を展開して詳細表示を行うことができる。

　

図６　データ・オブジェクトとプロセス・オブジェクトの利用

４．　分散ソフトウェアの設計への対応

　近年、分散ソフトウェアが広くビジネス分野で利用されるようになったが、その大きな要因は次のような環境の変化によるものである。

　しかしながら、分散ソフトウェアは一般に多くの拠点にまたがる大規模なシステムになることが多く、データの送受信により複雑な処理のタイミングを安全にこなさなければならないため、ソフトウェアの設計は非常に難しい。このような分散ソフトウェアにおけるアプリケーションの設計は、プロセスを複数のコンピュータに割り当てて処理を行い、プロセス間通信によってそれぞれのコンピュータの間をデータが飛び交う状況を正確にモデル化しななければならない。したがって、分散ソフトウェアは単体ソフトウェアに比較して関連する要素が多く、システム全体の再現性が得られにくいことから、テストによる動作確認や問題点の発見が難しくなる。

　こうした困難を回避し開発を容易にするために、分散ソフトウェアの設計ツールや検証ツール、あるいは簡易な仕様記述などが強く求められている。また、将来に渡って組織の変更や処理の拡張に対処しなければならないので、できるだけ各サブシステムの自律性を高めたシステム設計が望まれる。

　本設計支援ツールをこのような分散システムの設計に対応するために、１つのプロセスに限って記述していたプロセス設計ダイアグラムを、ネットワーク上に分散したプロセスが互いにデータを送受信しながら実行する様子を視覚的に表示しながら記述できるように拡張した。すなわち、分散して配置された複数のプロセス・オブジェクト間をネットワークを介したデータが行き来する様子を図８に示すような仕様のイメージで記述するのである。

　

　

　

図８　分散オブジェクトシステムに対する仕様の記述イメージ

　

本設計支援ツールでは、利用者が向かっている画面の中に複数のプロセスを表示したいので、１つのプロセスについての仕様を本の１ページに対応させ、複数のオブジェクト間のデータの授受とタイミングを図９のような形式で表現する。

この方法によると、通信中の複数の分散オブジェクト間で実行される処理の流れをデータ授受のタイミングとともに表示することができる。

　

　

　

　

　

３．３　設計の手順について

　３．３．１　クラス

　

（１）データ要素

本システムでは、ビジネス・アプリケーションにおけるドメイン特有の業務世界をモデル化するために、業務で利用されるモノの名称をデータ要素として扱うこととする。これをデータ要素と呼ぶのは、できるだけ単純なモノを抽出してクラス階層に体系化しておき、実際にシステムで利用するときにそれらの名前を合成することによって、特定のモノに関連する属性やメソッドを自動的に規定したいと考えているからである。

ビジネス・アプリケーションで使用するデータ項目を、その意味を表す論理的要素とデータと、型を表す物理的要素との名称の組合せとして表現することとし、以下に説明するようにそれぞれの要素を物理的クラス階層と論理的クラス階層に分離してis-aの形式で体系化した。実際の開発では、論理的クラス階層は、主にアプリケーションの設計者が登録し、物理的クラス階層は、システムの設計者が登録することになる。

　

（２）論理的クラス

論理的クラスは、対象となるドメインに特有のデータ要素を体系化するもので、開発の対象の業務分野ごとに定義されるものである。従って、ここでいう論理的クラスは現実世界をベースにアプリケーションが果たすべき処理の要求をモデル化するためのクラス定義である。

論理的クラスの定義では、まずドメインを構成するモノをオブジェクトとし、その性質を属性として記述するものとし、has-aやpart-ofにあたる構成要素は記述しない。ここで記述する属性は、論理的クラスに記述された別のオブジェクトとして記述されているものでも良く、複数の同一オブジェクトと関係しているものは●を付加して示すことにしている。

図３に示す例は銀行のATMに関するデータ要素の一部を論理的クラス階層として表したものである。

ここで論理的クラスは、そのドメイン特有の業務用語で表現されるモノであり、そのクラスメソッドは業務を遂行するための作業の名称で抽象的な表現で記述されている。つまりこのクラスでは、システムを意識した記述をしてはならないのであって、このメソッドは要求定義フェーズにおける抽象ユニットによる仕様記述に用いる。

　

!C

　

図３　論理的クラス

　

（３）物理的クラス

物理的クラスは、データ要素をデータの物理的な属性、すなわちデータの型をもとに体系化したものである。従って、システムの開発で利用されるデータの型は、ドメインによって変化せず、ターゲットマシンや言語などのシステム環境によって規定されるものである。

このように、物理的な属性やメソッドの体系化を先の論理的クラスと完全に分離したことによって、それぞれのクラス定義が複雑になるのを防いでいる。

図４は、図３で示した論理的クラスのオブジェクトを物理的クラスにマッピングしたものである。本システムでは、データ項目を定義するとき、その名称に物理的データ要素名を付加することによって、自動的に物理的クラス階層にマッピングされる。

なお、物理的クラスにおけるクラスメソッドは、システム記述に直接関係する用語、すなわち入力する、転記する、初期化するなどのシステム用語で記述されており、システムの設計フェーズにおける基本ユニットとして仕様記述に用いる。

　

　

図４　物理的クラス

　

（４）データ項目オブジェクトの定義

利用者が実際のアプリケーションの設計にあたって用いるデータ項目は、複数の論理的クラスのデータ要素の名称と、ただ１つの物理的クラスの名称を組み合わせたデータ項目名を作成することにより確定する。

このとき、作成したデータ項目オブジェクトは、論理的クラスと物理的クラスの双方から多重継承することによって、複数のデータ要素の属性やクラスメソッドを関係づける。

　

　

図５　データ項目名の決定

　

論理的クラスには、ドメインに特有なデータ要素の他に、「前年」とか「当月」などの時間的概念を表すクラスや、「都道府県」や部課などの空間的概念を表すクラスなどのように、多くのドメインで共通に利用できるデータ要素もある。

データ項目の定義は、これらの論理的クラスに記述されたデータ要素から、エンドユーザが理解しやすいように、できるだけ自然な呼び名でデータ項目の名称を組み立てることによって、仕様の確定に必要なデータ項目や処理ユニットを関係づけるものである。

例えば、「前年末顧客別預金残高一覧表」というデータ項目は「前年末」＋「顧客別」＋「預金残高」＋「一覧表」と言う各データ要素の組合せによって定義する。すなわち、論理的クラスに含まれる業務処理用語と、物理的クラスに属するシステム処理用語をマッピングし、それぞれのデータ要素に含まれるクラス・メソッドを用いて仕様を記述することができる。

　

図６　データ項目とクラスメソッド

　

３．３．２　データ構造

さて、対象のビジネス世界のモデルを論理的クラスとして定義し、システム世界で扱うデータの型を物理的クラスとして整理したが、実際にコンピュータシステムで実現するための仕様を記述するために、開発するアプリケーションで取り扱うファイルや帳票などのデータの集合を定義する必要がある。これらのデータ項目の集合関係は、データ構造エディタを用いてデータ構造図を作成することにより定義する。この場合、論理的クラスに定義した特定のクラスの属性群を、そのまま１つのファイルなどを表すデータ構造図の中に構成要素として組み入れることが多いが、その属性の一部を全く別のデータ構造図として作成する場合や、１つのデータ構造図に他の論理的クラスの属性を組み入れることもある。図７は、図３で示した論理的クラスの各オブジェクトついて、それぞれファイル形式でデータ構造図を記述したものである。前述のように、論理的クラスに含まれるすべての属性を組み入れる必要はなく、開発するシステムで利用する予定のものを対象とするだけでよい。この例では、銀行クラスに含まれる口座やATMは別ファイルとし、出納係端末機や従業員は無視している。

　

　

　

図７　データ構造図と項目の関係

　

このように、アプリケーションの設計者は、開発すべきシステムで使用するデータ項目をクラス階層から取り出し、データ構造図を作成することによってオブジェクトのhas-a形式の集約関係を定義する。なお、本システムでは異なるデータ構造図に含まれる共通オブジェクト間の関係は、図７に波線で示すように同一データ項目名称でリンクを張ることによってシステムが自動的に把握している。

　

３．３．３　データフロー

（１）データフローエリア

さて、このようにアプリケーションで利用するデータ構造が確定すると、そこに含まれるデータ項目オブジェクトの内部変数の時間的変化を示すために、データフロー・エリアをダイアグラム上に設ける。これは、データ項目オブジェクトの時間軸に沿ったビューであり、実際のシステムでは、データ構造の最上位のデータ項目オブジェクトが、内包する各オブジェクトのデータフローを集約して表示している。

このデータフローエリアは、オブジェクト指向の観点から見ると、データ項目オブジェクト間で交信されるメッセージのタイミングチャートであると共に、各々のデータ項目オブジェクトの状態遷移を示している。また、構造化設計の観点から見ると、処理ユニットという機能モジュールで扱われるデータの入出力と、当該モジュール内でのデータの加工状況を表している。

　

　

　

図８　データ構造図とデータフローエリア

（２）データフロー

データフローエリアに対応するデータ項目オブジェクトに対して、参照や更新を行う処理のタイミングを示すために、本システムではデータのアクセスのタイミングとアクセスの種類を図９に示す記号で表現している。

図９　アクセス記号

　

　

（３）オブジェクト指向による捉え方

さて、データフローエリアにおける縦のデータフローすなわち垂直フローは、各々のデータ項目オブジェクトの内部変数の状態遷移を示している。従って、データ項目をオブジェクトとして捉えると、当該オブジェクトの生成から消滅までを、対応するデータフローエリア上に垂直フローとして描かれることになる。このとき、データフローが描かれていない部分はオブジェクトの未生成区間もしくは内部変数の参照が不能である区間を示し、逆にデータフローの描かれている部分は、参照、更新などのメソッドの実行が可能な区間を示している。よって、設計者はこの区間に限って、処理ユニットの選択が許されることになる。

一方、横方向のデータフローすなわち水平フローは、オブジェクト間のメッセージ交信のタイミングを時間の経過に沿って表示したもので、それには集合データ項目オブジェクトに包含された内部変数同士のデータ交換であるの内部水平フローと、他のデータ項目オブジェクトとの間のメッセージ交信である外部水平フローがある。また、外部ファイルからのデータ入出力を表すデータフローも、水平フローで表される。

　

　

　

　

図１０　オブジェクト指向で捉えたデータフロー

　

（４）構造化設計による捉え方

このダイアグラムを構造化設計の観点からとらえると、データフローエリアを横断して表示される処理ユニットが、機能モジュールに当たる。従って、垂直フローは各処理ユニット間におけるデータの授受を表すことになる。この処理ユニットは、後述のように複数の基本ユニットに展開できる抽象ユニットを使用できるので、抽象ユニットに包含される基本ユニット同士のデータ授受を示す内部垂直フローと、他の処理ユニットとのデータ授受を示す外部垂直フローが存在する。

また、水平フローは、１つの機能モジュール内で行われるデータの加工工程を表している。

　

　

　

図１１　構造化設計で捉えたデータフロー

　

（５）データフローにおける検証

本システムでは、データフローをもとに設計者が仕様を記述している間、次のような整合性の検証を行っている。

まず、垂直フローの検証は、新しく処理ユニットを作成したり、類似の処理ユニットを再利用したときに、データを授受しているデータ項目の属性を検証できる。また、それぞれのデータフローエリア上におけるデータの状態と、各処理ユニットにおけるデータ項目のアクセスタイプをもとに、状態の遷移ルールを設定することによって処理の妥当性をチェックし、矛盾があればデータフローにエラー表示をする。

一方、水平フローは、データ項目オブジェクト間のメッセージ交信に用いる引数の検証に利用している。すなわち、目的のデータ項目を指定すると、その属性を参照して使用可能なメソッドが表示されるが、新しくメソッドを記述するときは、記述可能な構文テンプレートが表示される。そこでテンプレート中に埋め込むべきデータ項目をデータ構造図から指定するが、このとき、データ項目の属性を考慮して、使用可能なデータ項目以外は選択できないようにプロテクトがかけられる。

　

３．３．４　プロセスユニット

　

本システムでは、各データ項目のメソッドにあたる処理ユニットそのものをオブジェクトとして扱い、それには基本ユニットとその集合である抽象ユニット、データ項目間の宣言的な関係を示す関係ユニットの３種類を用いている。

　

（１）基本ユニット

基本ユニットは、あるデータ項目オブジェクトに定義されたメソッドに対応するもので、日本語仕様を解釈して実行できるようなオブジェクトである。ただし、内部水平フローで表されるような特定のオブジェクト内部で行われる処理を表すいわゆるメソッドと、外部水平フローで示される他のオブジェクトとのメッセージ交信を含んだ処理が存在する。

さて、基本ユニットは設計フェーズの仕様記述に用いるシステム処理用語で表現された処理ユニットであり、物理的クラスのクラスメソッドとして登録されたものである。

図１２に示すダイアグラムは、仕様を表示した処理ユニット群が、プロセスフローに沿って処理の手順どおりに配置された様子を示している。

　

　

　

図１２　基本ユニットの配列

　

（２）抽象ユニット

複数の基本ユニットが集団で１つの機能を表すように作成すると、抽象ユニットとして部品感覚で再利用することができる。この抽象ユニットは、いくつかのオブジェクトの特定のメソッドを組み合わせて部品化し、ある機能を実現する機能モジュールである。

抽象ユニットは、機能を論理的クラスにおける業務用語によるクラスメソッドで表現しており、その内部を展開すると複数の基本メソッドの組合せによって記述されている。従って、抽象ユニットのみを表示したダイアグラムは要求定義書としてのドキュメントであり、抽象ユニットを展開表示するとシステム用語で記述されたシステム設計書としてのドキュメントとなる。

本設計支援ツールを利用して、抽象ユニットすなわち機能部品を再利用する方法は、図１３に示すように論理的クラスから希望するデータ項目の処理メニューを開き登録された抽象ユニットを選択することによって取り出すことができ、抽出した抽象ユニットをダイアグラム上の適当なタイミングに配置することで行う。

図１３において、抽象ユニットをそのままの形でダイアグラムに配置すると、「クレジットカード口座から引き出す」という要求仕様レベルの表現で記述されており、その抽象ユニットをマウスでクリックすることによって、図１３に示すよりシステム的な表現で処理の内容が表示される。

また、プロセス・エディタで設計中に、ある抽象ユニットの内部を展開すると、図１３の網掛けで示すように基本ユニットで記述された日本語の仕様書として表示される。

　

　

　

図１３　抽象ユニットの抽出

　

なお、複数の基本ユニットから構成される抽象ユニットは、包含される基本ユニットのデータフロー端子を集約したもので、抽象ユニットと外部の処理ユニット間のデータフロー端子は基本ユニットのそれの論理積となる。

　

（３）関係ユニット

処理ユニットの中には、事前にどのタイミングで実行するかを指定しないで、ある条件が満たされると起動されるような処理ユニットを準備しておけば便利である。

例えば、データ項目オブジェクトの値の許容範囲を指定するような処理ユニットを、データ項目オブジェクトの制約として登録することによって、当該データ項目オブジェクトに対する値の更新が行われた時に、自動的に実行されるようにしている。また、複数のデータ項目オブジェクト間に、「売上金額」＝「売上げ数量」＊「単価」などのような、処理のタイミングに依存せず常に成立する関係があれば、処理ユニットをデータ項目間の宣言的な関係を表す関係ユニットとしてリポジトリに登録しておく。そうすることによって、これらのデータ項目オブジェクト間に、常にその関係に応じた値を維持しておくことが、可能になる。

このような宣言的に記述できる処理ユニットを、プロセスフロー上に手続き的に配置する必要がなくなると、システム設計者にとって非常に便利であり、わずらわしさを解消できるものと考えている。これらの処理ユニットはプロセスフロー上に仕様として表示することなく実行可能であるが、データフローを完結させるために、関係するデータ項目の更新が行われた直後にシステムによって自動的に挿入することとしている。

　

３．３．５　プロセスフロー

　

（１）逐次処理

データ項目オブジェクトに登録されたメソッドの１つに対応する処理ユニットオブジェクトを、プロセスフロー上に一列に並べることによって逐次的な処理手順を表す。なお、処理ユニットを配置するためのプロセスフローは、構造化設計における構造化チャートの一種であり、順次、反復、条件の３基本構造を組み合わせて描かれる。

　

（２）並列処理

一方、処理ユニットオブジェクトを並列プロセスにおけるエントリー呼び出しの形で実現する場合には、並列処理の数に応じたプロセスフロー上に処理ユニットを配置することによって表現する。本設計支援ツールでは、図14のように並列処理が可能なタイミングで複数のプロセスフローを描き、エディタ上で注目したいプロセス毎にページ表示を行うことにより、逐次処理と並列処理が混在する仕様も容易に表現することができる。

　

　

　

図14　並列処理の表現イメージ

　

　

（３）随時処理

このような手続き的なプロセスだけでなく、データ項目に付随させて、データ項目間の関係を表すプロセスや、プレ条件を満たした時に実行されるプロセスなどの関係ユニットを、宣言的に記述することも可能である。

　

３．３．６　プロセス構造

（１）抽象−具象

抽象ユニットは、論理的クラスに記述されたオブジェクトのメソッド名であり、ある機能を業務用語で表現したものである。

例えば「銀行口座」という論理クラスには「〜を開設する」、「〜に入金する」、「〜から払い出す」のような業務用後で抽象的に表現した抽象ユニットが登録されている。設計者は原則として、要求仕様を記述する段階でこれらの抽象ユニットを取り出してプロセスフロー上に配置する。これらの抽象ユニットは部品として登録されておれば、複数の基本ユニットで仕様が記述されている。新しく処理ユニットを登録するときは、物理クラスのメソッドに当たる基本ユニットをプロセスフロー上に配置することによってその機能を詳細化するのである。

　

（２）集合−内包

実際のシステム記述には、ファイルや帳票を表すデータ構造図に記述されたデータ項目オブジェクトのメソッドに対応する処理ユニットを使って設計する。データ構造図には集合データ項目と基本データ項目があり、それぞれに関連する処理ユニットがリンクされている。従って、集合データ項目内ではそれらを構成する基本データ項目同士でメッセージ交換が行われ、それらを集約したものが集合データ項目の処理ユニットとなる。

その様子を、データ項目オブジェクト間のデータフローとして図１５に示す。

　

　

　

　

図１５　データ項目間のデータフロー

　

本手法では処理ユニットもブジェクトとして扱っているので、当然処理ユニット間のデータフローとしても同様に図示できる。例えば「預金を引き出す」という抽象ユニットは、内部に抽象ユニットや基本ユニットを含んでおり、これらの間でもメッセージ交換が行われる。これは、１つの抽象ユニット内で行われる内部メッセージ交信であり、他のオブジェクトとのメッセージ交信は必ず包含するオブジェクトを通して行われる。

本設計支援ツールは、このような集団データ項目の振る舞いの記述についての外部処理ユニットとのやりとり、および包含される基本ユニット間のやりとりなどを、図１３に示すようなダイアグラムを用いることで視覚的に表現できる。

　

　

図16 プロセスの構造化

　

３．４　部品化／再利用の方法

ビジネス・アプリケーションの開発においても、ソフトウェアの信頼性、生産性、保守性を向上させる方法の１つとして、部品化／再利用は有効な方法である。ところで事務処理分野における業務の特徴として、

などがあげられる。このことから、ビジネス・アプリケーションの開発におけるCASEツールには、

などが求められる。

　

　

図１．本設計支援ツールの概念

　

　

３．４．１　仕様部品の考え方

我々は、ビジネス分野において使用される業務用語をベースにして、関連する知識を仕様書レベルで部品化し、アプリケーションの開発時に仕様部品を再利用しながら設計を進めて行くための支援システムを開発している。本システムでは、上記の要求を達成するために次のような解決方法を採用した。

（１）従来、開発工程に応じて複数の図式を利用した開発支援システムが提供されているが、図式間の関係が直感的に分かりにくいという問題があったので、本システムでは上流から下流までを一貫した図式表現を用いることとした。

（２）業務知識をエンドユーザが理解し易いデータ名などを基に仕様部品として体系化し、自然語に近い文書による仕様書の記述段階で違和感がなく部品の再利用ができるようにした。こうして完成した仕様書はシステムに関係する全ての人達（エンドユーザ、開発担当者、運用、保守担当者、監査人）にとって理解し易いものである。

（３）部品に記録された内容の変更に伴って、影響する処理の内容や波及する他のデータを追跡し易い方法を組み込んだ。

（４）システム間や部品間のインターフェースを明確にし、調整し易いデータ構造のエディタを提供すると供に、部品自体にそれが利用される場合のカスタマイズを可能とするための知識を組み込んだ。

　

一般に主なシステムの分析、開発の手法として

(1)プロセス中心の設計

(2)データ中心の設計

(3)オブジェクト指向による設計

などが利用されているが、本システムでは、オブジェクト指向の概念に基づいて仕様部品を整理し、データを中心とした技法によって設計を進め、プロセス中心の仕様にまとめる方法を採用した。その理由は、仕様の部品化はデータとプロセスをカプセル化したオブジェクト指向が便利であること、トップダウンで業務モデルを構築していく工程ではデータ構造やその流れに基づいて仕様を記述したいこと、プログラムのコードを導出するための具体的な仕様を作成する工程ではプロセスを中心とした記述が便利であるためである。

　

３．４．２　部品の抽出

再利用可能な部品としては、

（１）ソフトウェア開発の作業手順、

（２）アプリケーションを構成する仕様部品、コード部品、

（３）業務知識の部品、

（４）管理や監査のための部品

などが考えられる。

ここでは、（２）と（３）の業務知識を取り込んだ仕様部品を用いることとし、（１）の開発の手順や（４）の部品の管理、監査の方法をそれぞれの部品に再利用のための知識として組み込んだエージェントとして実現することとしている。

以下、（２）、（３）の部品化について述べる。

　

部品化を行うに当ってまず問題になるのは何を部品とするかであるが、本技法では対象業務をモデル化するのに最も便利なアイテムとしてデータ要素を取り上げ、これをデータ部品として扱うことにした。データ要素は業務上で扱うデータ名、帳票、ファイルなどを指すが、他に組織、要員、ネットワークなどをも包含して記述することにしている。すなわち、データ要素はデータを取り込んで保管できる対象であるとも言え、加工はこれらのデータ要素間で行われるプロセスによって行われる。一方、これらのプロセスはプロセス部品として仕様化し、出力データ要素に関係つけて整理することとしている。

!h

　

　

３．４．３　部品の体系化

ビジネス業務で使われるデータ要素をその属性に基づいてクラス階層に分類する。すなわち、複数のデータ要素に共通の属性をスーパークラスとして定義し、クラスから固有の属性を持ったデータ要素を所定のクラスに組み入れると共に、固有の属性や制約などをエディタで編集した後リポジトリに登録する。

ユーザは各々のデータ要素を利用する場合は、業務上のデータ用語によって自由に関係する知識を取り出したいので、これらの用語を整理して検索に利用する。実際のビジネスで利用される用語をいくつかの部分用語に分解し、概ね「名称＋分類＋処理＋形式的属性＋物理的属性」という形に組み合わせて用いると便利なことが解った。利用者はデータ用語を用いて仕様書を作成する訳であるが、それぞれの部分用語でリポジトリを検索することによって、関連する情報をさらに広範囲に収集することができる。

例えば「銀行別回収一覧表」であれば、「銀行」の文字を含むデータ要素である「銀行名」、「銀行コード」などを捜し出し、そこに関係付けられた「銀行マスターを入力する」、「銀行コードを追加する」などのプロセス部品を取り出すことができる。

　

　　!j

　

　

３．４．４　カプセル化

一般に、オブジェクトはその独立性を確保するためオブジェクトと操作と制約を内包したカプセルであり、メソッドは、当該カプセル内のオブジェクト実現値を操作するアクションと制約から構成されている。

本技法で扱う仕様部品はデータ部品とプロセス部品から成り、相互に関係するプロセス部品やデータ部品を検索できるようにしている。すなわちデータ部品においては、その部品に関係するプロセス部品を登録しておき、処理部品のメニューから随時プロセス部品を検索することができる。一方、プロセス部品には、当該プロセスで使用するデータ要素を登録しておき、必要に応じて関係するデータ部品の情報を参照できることとしている。このように関係付けすることによって、設計中に利用可能なデータ部品やプロセス部品を効率良く取り出し、組み込むことができるような環境を構築している。

　

３．４．５　データ部品

属性

データ部品に記録する属性は、ターゲットになる言語によって多少異なるが、COBOLであれば媒体、タイプ、桁数、アクセス方法などを登録する。

状態

状態部品は、当該データ要素のとり得る実現値のうち、業務用語として頻繁に利用される用語とその実現値を登録する。この内容の記述はプロセスShowエディタで行う。

制約

データ部品に記録する制約は、データの一貫性や完全性を保証するための検査ルーチンである。アプリケーションの開発時に、ここに記録した制約をもとに当該データ要素のソースエリアをアクセスする都度、制約の検証を行うモジュールを生成する。ここではデータ要素の実現値の生成、削除を検査する存在制約、値を規定する値制約、他のデータ要素との関係を規定する関係制約などを目的としている。

処理

当該データ要素に関係する処理用語を記録する。この処理用語は原則として「データ要素名＋動詞」で現し、プロセス部品の名称とする。エンドユーザ、設計者は業務用語で手続きを記述するが、エディタはプロセス部品を検索し仕様書に組込んでいることになる。

資料

この部品の作成者や変更日、世代などの管理項目の他、この部品を作成するための根拠や、メモなどを記録する。

　

３．４．６　プロセス部品

プロセス部品はデータ部品の処理メニューを選択することで、取り出すことができる。部品名は前述のように「データ要素名＋動詞」であるが、同じ名称の部品が必要なときはサブメニューで「Ａ社用」とか「和暦仕様」などの区分を設定することができるようにしている。

データ構造図

プロセス部品には、その部品で使用するデータ要素の集合であるデータ構造を記録している。エディタはデータ部品にリンクを張ることによって、データ部品として登録された内容を自由にとり出すことができる。

リソースエリアとデータフロー図

プロセスShowエディタで、リソースエリアはデータ構造から、データフローは処理フローから自動的に作図されるので、特に情報は記録していない。

　

!l

　

制御構造図、処理フロー図

プロセスShowエディタで記述された制御構造、処理フローは、プロセス部品として記録される。

　

３．５　本設計技法のまとめ

ビジネス分野の業務では、会計処理などのように法的に定められた手続きに従って処理することを義務づけられており、システムの開発時にその手順を確定しておかなければならない業務が多い。言い替えれば、あらかじめ承認された処理は必ず実行され、それ以外の処理は行っていないことを厳重にチェックできるとともに、決められた処理の手続きを遵守しているかどうかが仕様書から正確に読み取れることが重要となる。

このような業務のシステム開発を行うに当たって、従来のオブジェクト指向では部品化を指向するのに有効ではあるが、その特徴ゆえに事前にシステム全体の処理手順を把握できるような記述が不得手であること、構造化分析／設計で培われた技術を利用することによってダイアグラムや仕様における矛盾の発見や設計手順のガイダンス機能を提供し易いと考えている。

また、実用的な支援システムを提供するためには、エンドユーザや開発担当者に何を部品として取り扱うのかの明確な指針が必要であるため、本支援ツールではビジネス分野で最も共通の認識が得易いデータ要素に注目し、各データ要素の名称をキーとしてデータ部品とプロセス部品を関係付けることとした。ここでデータ要素とは、要員、媒体、メモりなど、データを取り込んで処理できる利用可能な資源を包括している。

　

ところで、ビジネス・アプリケーションをオブジェクト指向の概念を取り入れて開発する場合、現場のエンドユーザができるだけソフトウェア開発に関する知識を必要とせずに、ツールの支援を受けながら自然に設計を進めることができるような開発支援ツールの一例を提案した。

それを実現するため、業務で使われるモノの名称をベースにデータ要素の論理的クラスと物理的クラスを用意し、それらの名称を組み合わせて定義したデータ項目オブジェクトを使ってデータ構造図を作成する方法について述べた。ついで、データ項目オブジェクトに関連する処理ユニットを構造化チャート上に配置することにより処理の手順を容易に記述でき、データフローの検証によって矛盾を早期に発見できることを説明した。

ここで紹介した方法は、設計段階で、オブジェクトの中に隠されたメソッドの実行手順や、メッセージの交信によって飛び交うデータの流れを明示しようとしている。これは、多くのビジネス・アプリケーションには、コンピュータで処理されるべき内容を明らかにするとともに、要求されていない処理が行われないことを保障するような、可監査性が求められるからである。

また、従来のオブジェクト指向の多くがオブジェクトとしてのプログラムレベルの再利用を狙っていたのに対して、この設計方法は、仕様をオブジェクトとして部品化し再利用するのが目的である。従って、ソースコードは仕様を変更するたびに新たに生成され、生成されたソースコードはオブジェクト指向の形式である必要はない。仕様のレベルで利用されなかったメソッドなどのソースコードは生成しないからである。