プログラムの部品化・再利用によって
Visual Basic 上での開発を大幅に効率化
---「日経ソフトウエア」の広告記事 ---
詳しくは、MANDALAとは という紹介記事もご覧ください。
ソフトウェアの部品化・再利用は、アプリケーション開発の生産性を高める最も有力な手法である。しかしオブジェクト指向開発や OCX などは、注目されている割に実際の業務アプリケーションの開発生産性向上にはそれほど寄与していないのではないだろうか？ このような状況に一石を投じるのがアプリテック社の
「MANDALA」 である。これは業務仕様と操作仕様を完全に分離可能にする、Visual Basic のアドオンツールだ。業務仕様を画面から切り離すことで、業務仕様の部品化を強力に支援するのである。
ソフトウェアを部品化し、それらを再利用することで開発生産性を高める。これは古くから言われていることではあるが、実は新しい問題でもある。
ソフトウェアの部品化・再利用に関しては、すでに 30 年も前からオブジェクト指向というコンセプトが提示されており、最近では OCX のようなものも実用化されている。しかしオブジェクト指向や OCX は、本当にソフトウェアの部品化・再利用を実現し得るものになっているのだろうか？ イメージだけが先行し、本来の “部品化” とはまだかなりのギャップがあるのではないだろうか？
ここでまず、理想的なソフトウェア部品が満たすべき要件を考えてみよう。理想像が明確になっていなければ、それを実現することなど不可能だからだ。
理想的なソフトウェア部品が満たすべき要件は３つあると考えられる。
まず第１に、部品を組み合わせるだけでソフトウェア製品ができあがるものであること。これまで多くの開発現場で“汎用サブルーチン”によるソフトウェアの再利用が行われていたが、これではこの要件を満たすことはできない。汎用機能を抽出してライブラリ化しても、それらを組み合わせるだけでは思い通りの業務アプリケーションを作ることはできないものだ。汎用サブルーチンでは、業務アプリケーション全体の４割をカバーすることすら困難だといわれている。
第２にどのような業務要求にも対応できること。業務要求に対応するためのカスタマイズには大きく分けて、パッケージソフトのカスタマイズのように、あらかじめ決められた“パラメタ”を変更することで対応するものと、プログラム自体を修正するものの２種類がある。パラメタだけでカスタマイズできればコストはかからないが、ユーザーニーズにきめ細かく対応することが難しい。かといってカスタマイズのためにプログラムの修正を行うと、パラメタカスタマイズに比べて膨大なコストがかかるようになる。このトレードオフを乗り越えることができなければソフトウェア部品の意味はない。
そして第３が、大勢の開発者が組織的に部品化・再利用の恩恵にあずかれることだ。個人的なレベルでの部品化・再利用は、実は自然発生的に行われているものだ。しかしそれを組織的に行うのは非常に難しい。他人が作成したプログラムに手を入れるくらいなら、最初から自分で作った方が早いとどの開発者も主張するものだが、これではマズイ。
これら３つの要件が満たされることではじめて、ソフトウェア部品を“開発する人”とそれを“再利用する人”とを分けることができるようになる。そしてそれこそが、ソフトウェア部品が目指すべき姿なのである。
◆ 部品を組み合わせるだけでソフトウェア製品ができあがるものであること
◆ どのような業務要求にも対応できること
◆ 大勢の開発者が組織的に部品化・再利用の恩恵にあずかれること
図１: 理想的な部品化・再利用に求められる三つの要件
Visual Basic 上でこのような理想的な要件を満たす “ソフトウェア部品” を実現するために登場したのが、アプリテック社の 「MANDALA」 である。これは Visual Basic のアドオンとして利用できるツールであり、ふたつの大きな特長を備えている。
まずひとつは、プログラム全体を “業務仕様を実現する部分” と “操作等の仕様を実現する部分” に明確に分離できることだ。
一般に Visual Basic で業務アプリケーションを作成する場合には、操作のためのコントロールオブジェクトと処理内容が密接につながっているため、操作仕様と業務仕様が混在する傾向がある。そして、大きなアプリケーションを構築する場合には、画面単位にプログラムを分割して複数の開発者に振り分けることになる。しかしこのような方法は、各開発者の専門領域でのスキルを活かすことができないため、生産性を上げるのは意外と困難だ。また各画面の操作性がばらばらになってしまうという問題もある。たとえ最初に規約を作ってから開発をスタートしたとしても、細部では必ず差が出てくるものだ。さらに操作仕様と業務仕様が混在しているためプログラムが複雑化し、他の開発者が作成した画面プログラムのメンテナンスがきわめて難しくなるという問題もある。
MANDALA は後述するように、操作仕様の部分と業務仕様の部分を後で“糊付け”することで、これらを完全に分離できるようにしている。また業務仕様に関するプログラムは、データ項目対応に完全に細分化され要素化された“データ項目部品”となり、すでに必要な部品がそろっていれば、これらを組み合わせるだけで業務アプリケーションを構築できる。さらに
MANDALA で作られたプログラム部品は“ブラックボックス”ではなく、ソースコードに手を入れて修正可能な“ホワイトボックス”部品なので、細かいカスタマイズにも対応可能なのである。
図２: MANDALA による開発の流れ
画面と業務仕様をそれぞれ別に作成し、それらを MANDALA で“糊付け”することで Visual Basic のソースコードを生成する。操作性に関する部分は、MANDALA が“機械生成”する。
MANDALAのもうひとつの特長は“ ポスト生成ツール” として作成されていることである。
Visual Basic のアプリケーション・ウィザードのように、基本的な操作仕様等を“雛型”として生成し、それに対して手を加えるようなツールを“プレ生成ツール”と呼ぶ。この方法も開発生産性の向上に寄与するが、操作仕様等の変更があった場合には雛型に手を加える作業をすべてやり直さなければならない。これに対して MANDALA では、まず最初に画面の設計と業務仕様を実現するプログラムの作成をしてから、これらを MANDALA の“糊付け機能”によってつなぎ合わせてソースコードを生成する。このため変更が生じた場合でも関係する特定の部分だけを修正し再生成すればよく、驚くほどメンテナンスがしやすくなる。
また文字列の表示方法や入力文字のフィルタリングなどの操作仕様に関する部分は
MANDALA が自動的に生成するようになっており、操作性に関する設定はパラメタで変更できるようになっている。MANDALA では業務アプリケーションのかなりの部分を機械的に生成するようになっており、およそ７割をこの機械生成でカバーする。
図３: MANDALA での操作性設定画面
アプリ画面上での文字列の表示方法や入力文字のフィルタリング、カーソルの移動方法などがパラメタで設定できる。
■利用実績 (すでに
1000 人以上の開発者に使われています)
MANDALA はすでに、大手生命保険会社や大手信販会社、大手自動車メーカーなどの大規模な業務アプリケーション開発のメインツールとして利用されており、1000 人以上の開発者に使われ、ランタイムで約５万クライアントの実績を持っている。またウッドランド(株) の 「RRR」 や (株)内田洋行の
「スーパーカクテル」、富士通（株） の 「FM MAX」 などのように、MANDALA で構築された ERP やプログラム部品群も販売されている。このことからもわかるように、その実用性は極めて高く評価されているのである。
MANDALA の動作環境:
Visual Basic 6.0 または Visual Basic 5.0 が動作するパソコンと 10MB のディスク容量が必要です。
Windows XP、 Windows 2000、 Windows NT 4.0、 Windows NT 3.51、 Windows98、 Windows95 (ただし、Visual Basic 6.0 と Windows NT 3.51 の組み合わせは不可) のいずれでも動作します。そして、これらの上で動作するアプリの開発を支援します。
参考文献： MANDALA の基礎となる理論などを説明した ｢ビジネスロジック部品｣ という参考図書も、合わせてご参照ください。
まだご覧になっていなければ、MANDALAとは という紹介記事にお進みください。
AppliTech および MANDALA は、アプリテック株式会社の登録商標です。
Visual Basic および Windows、 Windows NT は、米国マイクロソフト社の商標です。
AppliTech Inc. (アプリテック株式会社)
電話: 055-973-6823
Fax: 055-973-6824