この章の見出しの一覧
上流工程支援ツールと下流工程支援ツール／大げさなツールの宣伝／上流工程と下流工程をめぐる見方／エンドユーザ開発とスパイラルモデル
記述作業の支援／上流工程 CASEツール／インタビュー支援／疑似体験支援／上流工程か下流工程か
下流工程支援ツールの動向
嵌め込みシステムの第一の罠／嵌め込みシステムの第二の罠／部品の単位を決める指導原理とその効果
イベント駆動方式／4GL と嵌め込みシステム／4GL が生産性向上効果のあるわけ／4GL
が主流にならないわけ／スーパルーチン
SSS/Win における改善点
ここでは、第四世代言語 (4GL) や CASE ツールなどの一般のソフトウェア開発支援ツールを概観しながら､“ソフトウェア部品のテクノロジー”を用いたツールの特徴を見ることにします。
SSS ツールの開発は、世の中の動向をあまり見ずに進めたようですが、ここで振り返ってみると、一般のツールの一部とほぼ同じ道をたどって、部分的に先行していたことが分かりました。つまり SSS ツールは他と比較できないほど特殊なものではなかったのです。そこで、そのリファイン版である SSS/Win の開発は、世の中のツールの調査結果に基づき、他のツールの方が進んでいる点は取り入れて、部品化再利用システムとして最高のツールにすることを目指しました。
[上流工程支援ツールと下流工程支援ツール]
ソフトウェアの開発を支援するツールは、上流工程支援ツールと下流工程支援ツールの二つに分類することができます。この他に、中流工程支援ツールを含めて三つに分類することもあれば、もっと細かにすることもあります。ただし、こういったものの多くは、ツールベンダにとっての都合のよい分類であり、いわばゲリーマンダ (Gerrymander) の山椒魚のような形に無理やりした選挙区区割のようなものです。残念ながら、大多数の人が共通に認める分類は未だありません。
これを曖昧のままにしておくと、誤解だけでなく幻想を生む温床になりますから、ここでは、単純に上流工程と下流工程の二つに分類して、それぞれを次のように明快に定義することから始めます。
｢上流工程とは、人間がコンピュータ処理の対象となる現実世界 (とその周辺) を理解し、システムのイメージ (即ち要求仕様) をまとめ上げる工程であり、下流工程とは、そのイメージどおりのシステムを構築するためにソフトウェアを作成する工程である｡｣ と、本書では定義することにします。そして、上流工程支援ツールおよび下流工程支援ツールは、それぞれの工程の作業を支援するツールだとするわけです。
この定義では、あくまでも人間が中心にいて仕事を進めていくことを前提にしています。もしも人間の介在が一切不要な全てを自動化するツールがあれば、それは、ここで定義した支援ツールよりもはるかに高いレベルにある別物だと考えることにします。そんなものは、当分は開発される見通しもないので、気にする必要もないのですが、そんな幻想は存在しています。まだ、コンピュータが神の座にある名残かもしれませんし、ツールベンダの宣伝が巧みすぎるのかもしれません。
[大げさなツールの宣伝]
因みに、一時期は明らかに行き過ぎと思われる数値をあげて、｢ツールを使うことで生産性が n 倍になった｣ という宣伝がなされていました。こういう倍率を追求してみると、条件のよい特定の事例だけを取り上げたいわゆる瞬間風速であり、統計的に意味をもつ平均値ではないことがほとんどです。しかも、次のような御都合主義の比較だといわざるをえないものもあります。つまり、ある開発工程が省けたために生産性が上がった事例や特別にスキルのある人が開発したので生産性が上がった事例などと、通常の開発 (こちらは低く見積もりがち) との比較であったりします。生産性の倍率のコンパクトな測定方法がないために、確かめられないのをよいことに言いたい放題です。ただし、行き過ぎはすぐに分かるもので、大袈裟な倍率は宣伝文句だとみなされるようになりました。生産性の倍率の測定方法について納得できる説明がないものは、客観的な評価ではなく、宣伝文句とみなすのが常識になっています。なお、生産性の倍率をできるだけ客観的に測定する方法については ｢付録３．ソフトウェア開発の生産性の計り方いろいろ｣ を参照してください。
[上流工程と下流工程をめぐる見方]
上流工程と下流工程をめぐって、次の二つの見方があります。
その一つは、ウォータフォールモデル (滝モデル) です。これは、滝を落ちて上流から下流に下った水のように、次の工程へと進んで行き、逆戻りすることはないという見方です。現実の開発には下流から上流に逆戻りがあることが普通ですが、それが無視できるほど少なければ、こう捕らえてよいでしょう。
この開発の捕らえ方から一歩踏み出して、ウォータフォールモデルに基づく開発を理想として、手戻りを発生させるべきでないという考え方もあります。これを理想に掲げるのは、主に大勢の人間による大規模開発を行う場合です。仕様変更に対処するための作業量は、開発者の数の二乗に比例して増えるといわれていますから、大勢の人間による開発では、特に変更を出さないように気を使います。こうして、手戻りの撲滅を追求していくと、上流工程の作業を完璧にすることが重要課題になります。ですから、上流工程支援ツールが注目されるわけです。なお、これについては後で詳しく説明します。
もう一つの見方は、スパイラルモデルです。これは、上流工程と下流工程をぐるぐる回りながら螺旋階段を昇るように、開発が進んで行くという見方です。見直して反省することが進歩につながるという考え方なのですが、実際の開発にはミスによる手戻りとしか捕らえようがない無駄もあるものです。
ところが、スパイラルモデルに基づく開発を理想に掲げる考え方もあります。これに対しては、｢手戻りを理想にするとは何事ぞ｣ と、ウォータフォールモデルを理想にしている人々から反発があることでしょう。手戻りを容認するのは仕方ないとしても、それを理想に掲げるのは誤りだというわけです。しかし、これは、人間の特性に合わせることを理想とする人間工学的な発想があってのことですから、この考え方も十分に成り立ちます。そもそも、人間が立派な作品を作るとき、そこには作っては見直すという繰り返しがあるものです。ですから、ソフトウェアの開発においても見直しがあってこそ、立派な作品を開発できるというわけです。
スパイラルモデルを理想とする開発では、先ず上流工程である程度イメージがまとまったら、下流工程に移り取り合えずプロトタイプシステムを作ります。これには、プロトタイピング支援ツール (後述) が大きな役割を果たします。この作業を、ラピッドプロトタイピングまたはラピッドプロトタイピング方式による開発と呼ぶことがあります。なお、プロトタイプは、作り捨てにする場合と作った後に改版を繰り返すことで本番システムにもっていく場合がありますが、どちらにしても構いません。
初版のプロトタイプシステムがある段階にきたら、次にそれをもってまた上流工程に移ります。今度は最初の場合と異なりプロトタイプシステムがあるので、それを活用して現実世界との不整合を見つけ、要求仕様をリファインします。そして、また下流工程に移り、最新の要求仕様に基づいてシステムに修正を加えて最新版にします。
このように上流工程と下流工程の作業を繰り返すことで、システムを改版していき、例えば第 100 版ぐらいになると実運用に供するシステムが完成するというわけです。
このような表現だと、あたかも上流工程と下流工程が離れている印象を与えますが、画家が一筆入れては見直すような短いサイクルでこれらの工程を繰り返す場合もありますから、上流工程と下流工程が渾然一体にみえることもあります。
[エンドユーザ開発とスパイラルモデル]
少し話が飛びますが、エンドユーザ開発とは、開発の専門家 (特注アプリケーション開発業者や企業の情報部門の人) ではなく、システムの利用者であるエンドユーザ (実際の業務に携わっている人) が開発作業をすることです。エンドユーザは、コンピュータ処理の対象となる現実世界とその周辺を既によく理解していることが普通ですから、エンドユーザが開発すれば上流工程の大部分を省くことができます。ですから、ウォータフォールモデル的な開発になってよさそうですが、むしろスパイラルモデル的な開発になることが普通です。なぜなら、システムが未だ何もない段階でそのイメージを固めることは非常に難しいためです。一般に、システムができ上がってくると、いろいろと注文がわいてくるものです。
あるエンドユーザ開発を経験された方から伺ったのですが、システムが一応完成した後、使い込んでいく中で、真にコンピュータを活用した効果が実感できたとのことです。それは、顧客から電話で注文を受ける際の支援システムなのですが、以下のような支援をすることで、顧客の印象をよくして売上を大いに伸ばすことができたとのことです。
そのシステムは、 ｢前回のアレは良かったから、この前の倍の数をもってきてくれ｡｣ というような ｢アレ｣ とか ｢コレ｣ とかいう注文に即座に ｢ハイ、xxxx を nnnn 個ですね｡｣ と応答できるように支援したり、｢ところで、yyyy の評判はいかがですか。 御社の在庫もそろそろなくなるころかとお察しいたします。ご注文をいただけませんか｡｣ などと、顧客との会話をするための支援をするものです。このシステムをチューニングして、誰が顧客の電話を受けても常に全員がその顧客のことばかり考えていると思わせるようにしたとのことです。
こうするまでには、電話を受けてシステムを操作するエンドユーザ側の意識の持ち方や使い込みも重要ですが、システムの方も改版につぐ改版が必要だったとのことです。電話を受ける要員とシステムとを一体化させるためには、スパイラルモデル的な開発方法を採用することが必須だといえそうです。
話を戻して、上流工程支援ツール、即ち人間がコンピュータ処理の対象となる現実世界 (とその周辺) を理解して、システムのイメージ (即ち要求仕様) をまとめ上げる工程を支援するツールを詳しく見てみましょう。
先ずは、上流工程がなぜ重要だとみなされているのか振り返ってみましょう。
アプリケーションシステムの開発を終える少し前にデモンストレーションをしたところ、顧客の求めていたものとはだいぶ違うということになり、修正しなければならない事態を考えてみましょう。少量の修正で済む場合は不幸中の幸いといって済むかもしれませんが、最悪の場合にはアプリケーションの大幅な作り直しになり、納期に間に合わなくなってしまうこともあります。このような経験をすると、ウォータフォールモデルを理想に掲げる人々は、上流工程で完璧にシステムのイメージ固めをすることが益々重要であると考えるようになるものです。なお、スパイラルモデル的な開発を推奨する人々のように、開発の始まりの段階で完璧にシステムのイメージ固めをすることは無理だとする考え方もあります。
上流工程の重要性の話に戻って、これを特注アプリケーション開発業者の立場から取り上げてみましょう。特注アプリケーションの開発を請け負う場合は、その作業量を見積もる際にシステムのイメージを固めておかないと、見積もりの後に次から次へと出されがちな要求までも当初の請け負い範囲だとみなされて、オーバワークになり、損をする危険があります。ですから、システムのイメージ固めは重要です。
ところが、システムのイメージ固めを完璧にすることは、経験を積んだスキルの高い人にとっても、なかなか難しい作業です。ですから、これをソフトウェアのツールが代行するなどということは不可能に近いといえそうです。次のような状況を見ればそれがよく分かります。
そもそも顧客の要求そのものが必ずしも明快とは限らない上に、開発途中で気が変わって変更されることもよくあります。また、顧客企業の各部門ごとに (価値感に相違があり) 要求が異なっていたりして、要求仕様の取りまとめは一筋縄ではいきません。ですから、コンピュータの前に座っているよりも、エンドユーザとの話し合いの方がずっと重要だといわれています。そして、本当に役に立つアプリケーションを開発するには、通常では聞き出せない本音 (インフォーマルシステム) を知ることが重要だともいわれています。そのためには、インタビューをするぐらいでは得られる情報に限界があるから、仕事の内容を覚える気になって OJT (on the job training) を受けるべきだとの意見もあるほどです。要求仕様をまとめ上げる作業は、コンピュータサイエンスよりもむしろ社会科学の色彩が濃いようです。
この種の非機械的な作業をツールで支援するには、どうすればよいでしょうか。支援といえども一般には非常に難しそうです。しかし、上流工程の作業の一部であれば、次のような支援が考えられます。
・ システムのイメージをまとめる要求仕様書の記述作業の支援 (ワープロ)
・ 各種のダイアグラムの記述作業の支援 (上流工程 CASE ツール)
・ インタビュー支援 (同種のシステム開発のノウハウに基づく質問票)
・ 疑似体験支援 (画面や帳票のプロトタイピング支援ツール)
この他にも、コミュニケーションの手段としての電子メールやグループウェアなどがあり、少なくとも間接的な支援効果が確実にあるものと思われますが、これらに言及すると話が発散してしまいそうなので、ここでは省略します。
[記述作業の支援]
人間がコンピュータ処理の対象となる現実世界を理解したり、システムのイメージをまとめる工程の一部には、文章や図表を記述する作業があります。ものを書くことは、記録を残すために必要ですし、冷静に考えをまとめるためにも有効です。記述した文章や図表は、正式なアウトプットとして残すものもあれば、作業の過程で一時的に書いてみるだけのものもあるでしょう。いずれにしても、上流工程の何割かは、こういった記述作業です。
文章を記述するときにワープロを用いることは、文の追加･変更･削除などの修正作業が簡単になるので、大きな支援になります。また、ダイアグラム (設計図の一種) を記述するときに CASE ツール (ケースツール) のダイアグラムエディタを用いることは、うんざりするようなダイアグラムの書き直し作業の負荷を軽減するので、同様です。
このようなツールのもつ明確な機能による恩恵だけでなく、作業を楽しくすることで得られる副次的な効果もあります。悪筆の手書きに沢山の修正が入った文章は読む気がしませんが、ワープロの綺麗なアウトプットであれば、推敲が楽しくなりますし、不揃いのところを見つけると形式を統一しようという意欲もわくものです。例えば、本書は、ワープロなしには完成しなかったと確信をもって言えます。悪筆で文章の下手な人間にとって、自分の文章を読み直すのは気の重い仕事ですが、ワープロにはそれを楽しい仕事に変える魔力があります。
このように副次的な効果は確実にあるのですが、それをどの程度だと評価するかは、意見の分かれるところです。この後で話題にする上流工程 CASE ツールのような行き過ぎもあり得るので、冷静な評価が肝要です。
なお、ここでは上流工程における記述作業の支援について述べましたが、下流工程においても同様の記述支援があり得ることは、言うまでもありません。
[上流工程 CASEツール]
CASE とは computer aided software engineering の略語であり、CASE ツールとはソフトウェア開発を支援するツールの一般名称です。したがって、広義のCASE ツールには第四世代言語 (4GL) も含まれます。ただし、4GL という言葉が土着的な印象を与えるのとは対照的に、CASE という言葉には学問的な裏付けの香りがただよっています。こういう言葉のニュアンスの差から 4GL は CASE に含まれないと思っている人も多いようです。
言葉には色が付くもので、普通に CASE ツールと言った場合は、1980年代の後半にツールビジネスとして欧米で成功をおさめた upper CASE ツール、即ち開発の上流工程を支援する上流工程 CASE ツールを意味することが普通です。
ここでは、上流工程 CASE ツールに的を絞って、その総括的な評価をしてみます。CASE ツールの理想像は、ソフトウェア開発の自動化であり、プログラミングの自動化です。こういう理想を目指して、開発の上流工程を支援し始めた上流工程 CASE ツールは、一躍ブームを巻き起こしました。
しかし、それは 5 年ともちませんでした。理想像と現実のツールのギャップが大き過ぎたからです。このような否定的な評価は、ブームの最中であれば、その勢いに押し流されてしまうでしょうが、既にブームは去り、評価の下った古戦場の話ですから、何をいっても銃弾が飛んでくることはなさそうです。
先ずは、実際の上流工程 CASE ツールとはどんなものかを見てみましょう。
米国では、1970年代からソフトウェア工学者たちが構造化分析法などに基づくそれぞれの流儀のダイアグラムを提案していました。これは、データ･フロー･ダイアグラム (DFD) とかエンティティ･リレーションシップ･ダイアグラム (ERD) とかを基本とするもので、事務処理の実態を分析するのに有効でした。
ところがこれを書き出すと、完成させるまでに何回もダイアグラムの書き直しが必要になります。綺麗に書き上げて完成したと喜んだのも束の間、考え落ちに気づいて全面的に書き直さなければならない悲劇がしばしば発生します。これを鉛筆と消しゴムで行うのは面倒ですし、綺麗に仕上がりません。また、何といってもスマートではありません。
上流工程 CASE ツールは、このダイアグラムを記述する作業および書き直し作業をパソコンのグラフィカルな表現やマウスを使うスマートなものに変えたのです。上流工程 CASE ツールとは、ダイアグラム用のワープロというか、ダイアグラム記述の CAD (computer aided design) システムというべきか、そういう種類のツールです。いや、これだけは狭い見方だとの抗議がありそうですから、整合性のチェックの一部を自動的に行うものもあることを付け加えておきます。ただし、それは、目次と本文の対応の有無をチェックする機能をもったワープロがありますが、そういうレベルのチェックでした。
要求仕様をまとめ上げるという観点で上流工程 CASE ツールを評価すると、その中で使われるダイアグラムは、仕様の十分性を判定する側のエンドユーザにとって決して分かりやすいものではありません。しかし、欧米では、要求分析を専門に行うアナリストという職種があり、そういう人々は、構造化分析法などに基づきダイアグラムを書いていました。このダイアグラムは、専門家が業務の実態を分析するときに有効なものなのです。ですから、この種のツールの需要がないわけではありません。でも、ブームになるとは考えにくいのです。
ブームの背景や要因を探ると、アプリケーション開発の生産性向上への潜在的な強いニーズ、グラフィカルな表現を駆使したツールの見栄えの良さ、CASE という先端テクノロジーの響きのよい言葉、ツールベンダの巧みな宣伝、コンピュータジャーナリストやコンサルタント業者の同調などをあげることができます。
コンピュータジャーナリストなどが見栄えの良さに引かれて CASE ツールを話題にすると、情報部門の関係者は一応の知識を得ることが必要になります。企業のトップから ｢他社は CASE ツールを導入して効果をあげているようだか、当社は何をしているのか｡｣ と問いただされるからです。そこで CASE ツールを買って調べることになります。しかし、上流工程 CASE なるものは、なかなか理解しにくいものです。したがって、コンサルタント業者の活躍の場を提供することになります。こうして、いろいろな人々がかかわりをもつ市場が形成されていきました。
また、各企業の中で CASE ツールを調査するのは、開発の実務担当者ではなく長期ビジョンの策定にあたる計画部門の要員であることが普通です。こういう人々は、CASE ツールは理想を追及しているのだと好意的に受け入れるのはよいのですが、その後で現実を無視して過度な期待を膨らませる傾向がありました。
一度、大げさに取り扱ってしまうと、その後で ｢実はこの程度のものですよ｣ とは言いにくい雰囲気が作られますし、そのビジネスに大勢の人々が参加してくると、おいそれと後に引けなくなるものです。前進するしかなくなり、上流工程 CASE ツールはブームにまでなったのではないでしょうか。
やがて、期待したようなものではないことが多くの人々に分かって、｢上流工程 CASE ツールは software でも hardware でもなく shelfware (棚に飾っておくもの) である｡｣ という冗談を言い合うようになりました。そして、1980年代の終わりごろ、欧米では上流工程 CASE ツールのブームは下火になりました。
上流工程 CASE ツールは、ソフトウェア開発の自動化やプログラミングの自動化という理想とは大きな隔たりのある、要求分析のプロ向けの記述支援ツールだったのです。しかも、それを使えば誰もがその道のエキスパートになれるという代物ではなく、構造化分析法などの訓練を積んだ人だけが使いこなせるものでした。更に言えば、上流工程の中でこの種のツールが支援するのは一部の作業だけなのですから、大袈裟な言い方は慎むべきだったのではないでしょうか。もっとも、こういうどさくさに紛れて、一儲けしようと企むのなら話は別ですが、...
[インタビュー支援]
システムを開発する際に、顧客から注文されたり気づいたことを基にアンケート形式にまとめた資料をここでは質問票と呼ぶことにします。以前に別の客から注文されたことなどを参考にして作成した質問票に基づいて ｢一般には (つまり別のお客様ではという意味)、･･･ という形がありますが、この点に関して、こちら様ではどのようにいたしますか｡｣ と顧客にインタビューすることは、なかなか有効です。顧客が未だ気づいていなかった点にも気が回るようになるからです。そして、このような質問によって、顧客に後になってからいわれそうな要求のかなりを事前に捕捉することができます。
ところで、前述したパッケージのパラメタカスタマイズでは、顧客にインタビューをして、その回答に基づいてパラメタの設定するわけですから、パラメタは、システムのイメージを固めるための質問票のようなものだといえます。分かりやすく言うと、パッケージにおけるパラメタに相当するのが、特注アプリケーションにおいては質問票だというわけです。
ただし、パッケージでは、パラメタを設けるのに作り込み作業が伴いますから、おいそれとパラメタを増やすわけにはいきません。また、カスタマイズを避けようとする販売政策もあるでしょうから、厳選したものだけをパラメタにすることでしょう。
これとは対照的に、特注アプリケーションの質問票は、要求仕様をできるだけ完璧に把握することを目指すものであり、その数はパッケージのパラメタよりもずっと多くなり、広い範囲をカバーするはずです。なお、ここで ｢･･･ はずです｣ という言い方をしたのは、質問票が有効だと考えられるにもかかわらず、個人的な経験という形で蓄積されているだけで、これを組織的に適用している例が少ないためです。
[疑似体験支援]
アプリケーションプログラムとそのエンドユーザとの接点は、次の二つがほぼ全てだといえます。これ以外の繋がりはほどんどありません。
・ ディスプレイ画面の表示情報や出力帳票を見ること
・ 表示情報を見ながらデータ入力操作をすること
開発の始まった早い段階で、エンドユーザに画面の形式および帳票の形式を示してデータ入力の操作法を疑似体験してもらうことは有効です。字で書かれただけでは曖昧になりがちな要求仕様を現物で確認してもらえます。また、あたかも完成したかのようなシステムを前にするわけですから、その時点で多くの追加注文が出てくるので早めに手を打てます。したがって、後工程での仕様変更の発生を少なくできます。しかも、これはコンピュータシステムに不慣れな人々にも分かりやすい確認手段です。たとえをあげると、レストランで料理を注文するときに、字で書かれたメニューよりも料理の見本や写真の方が、そのイメージが間違いなく伝わるのと同様です。
この疑似体験のためには、それを見たり操作したりできるプロトタイプを作成することが必要です。このために、画面や帳票の設計などを支援するプロトタイピング支援ツールが販売されています。
[上流工程か下流工程か]
プロトタイピング支援ツールには、上流工程支援ツールだとして販売されるものと、下流工程支援ツールだとされるものがありますが、その内容には本質的な違いはありません。ただし、どちらなのかを曖昧にしておくと、ツールベンダの説明にだまされるので注意が必要です。そして、上流工程を終えると下流工程のソフトウェア資産が自動生成されるという錯覚に陥ることがあります。
これを解明するため、先ずはトリックのない本書の定義に従った見方をしてみます。プロトタイピング支援ツールは、明らかに下流工程支援ツールです。なぜなら、これはプロトタイプを作成し始めるときから用いるもので、システムの作成のための支援ツールに他ならないからです。プロトタイプは、作り捨てにする場合と、作った後に改版を繰り返すことで本番システムにする場合とがありますが、いずれにしてもシステムの作成が始まっているわけですから、下流工程の作業とみなすべきです。しかし、疑似体験によって要求仕様を抽出する作業は、正真正銘の上流工程の作業です。これは何なのかというと、下流工程の後に上流工程を繰り返しているわけです。そもそもプロトタイプなるものが登場するときは、スパイラルモデルに照らし合わせるのが良いようです。これに照らすと、プロトタイプシステムを作ったら、そのシステムをもって上流工程に移り、そのシステムを活用して現実世界との不整合を見つけたり、システムへの要求仕様をリファインしたりする姿が見えてきます。こうした作業の流れとしてプロトタイプの開発を捕らえるのが素直です。
次にツールベンダのトリックを公開しましょう。なお、括弧の中に種明かしをしておきます。このトリックは、先ずウォータフォールモデルに基づく開発をしているように思わせるところから始まります (ウォータフォールモデルは一種の理想形であって実際の開発はこれにあてはまるわけでない)。そして、疑似体験で要求仕様を抽出するのは上流工程の作業だから、それに必要な確認用のシステム、即ちプロトタイプを作るのも上流工程の作業だと暗黙のうちに認めてもらいます (これは、下流工程の作業を前倒しにしているだけなので、下流工程の作業だとみるべき)。更に、下流工程に移れるのは疑似体験によって要求仕様をまとめた後だと、これもウォータフォールモデルを楯にして認めてもらいます (実際には、それ以前に下流工程の作業をしている)。ここまでのお膳立てが整うと、画面や帳票が自動生成できたと誇らしげに見せることになります (既に作られたプロトタイプを基にして、それを単に自動的に変換しただけのことで、とても自動生成とはいえない)。
このような巧妙な手口にだまされて、この種の自動生成をありがたがる人々も結構みうけられます。もしも何らかの変換処理が必要ならば、それを遂行するツールだと明言してもらった方がずっとありがたいことですし、できれば変換処理などは不要にしてもらいたいところです。例えば、下流工程支援ツールだとして販売されるプロトタイピング支援ツールを疑似体験のために用いれば、変換処理は不要になります。
なお、これと同様の詐欺まがいの言動として、疑似コード (シュードコード) からプログラムコードに変換することで自動生成したという手口もよく使われています。
そもそも上流工程と下流工程の間には大きなギャップが存在します。そして、上流工程の情報から下流工程のソフトウェア資産を真の意味で自動生成するようなツールは未だありません。しかし、その幻想は存在しているです。
上流工程はこれくらいで切り上げて、下流工程支援ツール、即ち上流工程でまとめたイメージ (要求仕様) に従って、システム構築のためにプログラムの開発を支援するツールを詳しく見てみましょう。
[下流工程支援ツールの動向]
古い話になりますが、アセンブラやコンパイラによる生産性の向上は、目覚ましいばかりでした。インターラクティブ (会話的) なコンピュータ利用も大変に効果的でした。紙テープやカードの時代から、ラインエディタを用い、やがてフルスクリーンエディタへという進歩も生産性の向上に大いに寄与しました。この後に、画面や帳票のレイアウトを書くための専用エディタ、文章のためのワープロなどが続きます。
アセンブラやコンパイラは空気のようにあって当たり前になっていますから、これらのツールは除外することにすると、主な下流工程支援ツールとして、次のものをあげることができます。
・ 設計文書作成支援 (ワープロ)
・ データ項目の設計支援 (専用エディタ)
・ 画面や帳票のレイアウト設計支援 (専用エディタ)
・ 画面や帳票のレイアウトを中心にしたプロトタイプの開発支援
・ ファイルやデータベースの設計支援 (専用エディタ)
・ プログラム記述量の削減 (第四世代言語)
・ プログラムの読解性の向上 (チャート図エディタ)
・ 部品化再利用の支援 (オブジェクト指向、嵌め込みシステム)
・ インタープリティブな即実行とデバッグ (インタープリタ)
・ デバッグ／テスト作業の支援 (デバッガ)
・ 統合的なツール操作環境
・ 開発資産の管理支援
なお、ツールとはいえませんが、次のような部品として位置づけられるソフトウェア資産も生産性の向上には重要です。
・ 様々な機能ルーチンの品揃え (サブルーチンライブラリの充実)
上のリストには設計支援と書かれたところがありますが、下流工程支援ツールのほとんどは、設計らしい作業ではなく、設計作業の中の機械的に処理できる部分を人間に代わって遂行することが中心です。例えば、アセンブラは、面倒なアドレス計算や、機械命令の名前から命令コードへの変換を人間に代わって遂行してくれます。こういった計算や変換の作業は、決して設計の根幹に関わる部分ではありませんが、普通の人には過酷で面倒な作業であることも事実です。そして、うまいことに簡単にコンピュータに処理させることのできるものでした。したがって、真先に注目されツールの機能に組み込まれましたから、生産性の向上に大いに貢献しました。
コンピュータが開発された初期の頃には、コンピュータに処理させやすく、かつ効果の大きなネタ (施策、仕掛け、仕組み) が幾つもあったので、そういうネタをツールに組み込むことで、大いに生産性を向上させることができました。しかし、効果の大きなネタはすぐに刈り尽くされてしまい、この延長線上では、ほんの少ししか生産性を向上させることができなくなってしまいました。初期の頃の目ざましい進歩に比べて、その後のツールによる生産性の伸びが停滞しているのはこのためです。更に踏み込んだ議論は ｢付録２．ソフトウェア開発の生産性とは｣ を参照してください。
本来であれば、設計の根幹をなす知的作業の生産性向上に真正面から取り組むべきでしょう。つまり、人間ではなくコンピュータが設計作業の中心部分を実施するようなツールを開発すべきです。しかし、残念なことに、これを実現する目処は全く立っていません。
そこで、下流工程支援ツール、即ちシステム構築のためにプログラムの開発を支援するツールとしては、生産性に寄与するよりも、入門者にも参加しやすく、熟練者にも求められる「快適なソフトウェア開発環境の提供」を目指しました。これは、車の基本機能が成熟した後には快適な居住空間の提供が重要課題になったのと同様です。
ここでは、そんな中でも生産性にこだわっている次の二つを取り上げて詳しく見ることにします。
・ 部品化再利用の支援 (オブジェクト指向、嵌め込みシステム)
・ プログラム記述量の削減 (第四世代言語)
オブジェクト指向については話が済んでいますから、ソフトウェアの部品化を目指した嵌め込みシステムについて見てみます。
嵌め込みシステムでは、図２のような骨組みとなる骨格ルーチン
(スケルトン) とそれに肉付けをする補填ルーチンユニットからプログラムを構成します。つまり、骨格ルーチンの中にスロットという挿入口を設けておき、そこに適当な補填ルーチンユニットを嵌め込むことによってアプリケーションプログラムを完成させます。そして、これは、骨格ルーチンや補填ルーチンユニットを部品と見立てて再利用することを目指していますから、ソフトウェアの部品化再利用システムだとみることもできます。
図２: 骨格ルーチンと補填ルーチンユニット群
このシステムは、シンプルで分かりやすいために、日本では同種のものがいろいろなところで発案され、それぞれに名前が付けられました。テンプレート方式とか、部品合成システムとか、穴埋め方式とか、プログラムパラダイムとか、･･･ です。そして、SSS もこの種のものの一つだと見ることができます。
ところが、嵌め込みシステムは、大抵は失敗に終わっています。というのは、嵌め込みシステムには、いわば二つの罠が待ち受けているために、大抵の人はどちらかの罠にかかってしまうのです。
[嵌め込みシステムの第一の罠]
第一の罠をすり抜けるには、骨格ルーチンと補填ルーチンユニットのどちらを共通部品と見るのか正しい判断が求められます。補填ルーチンユニットの方が粒々していますから、こちらを共通部品だと思う人が多いようです。こうした人達は、第一の罠にかかって失敗しています。
もしも、補填ルーチンユニットを共通部品と見るのならば、それは共通サブルーチンとほとんど同じですから、何の進歩もありません。骨格ルーチンに補填ルーチンユニットを嵌め込むということは、骨格ルーチンが補填ルーチンユニットを呼び出すことを意味します。逆方向から見ると、補填ルーチンユニットは骨格ルーチンから呼び出されて何らかの仕事をするわけです。したがって、サブルーチンと等価です。
｢サブルーチンとは違うのだ｣ と細かいことを言う人もいますが、それならば、アセンブラやＣ言語のマクロ命令の展開に相当するといった方が更にぴったりと対応します。要するに既存の技術であり、何の新規性もありません。
広い意味での部品の呼び出しには、サブルーチン呼び出しやマクロ命令の展開やシステムコール (スーパバイザコール)やメッセージパッシングなどいろいろな手段がありますが、この種のものの一つに嵌め込みという原始的な手段が追加されただけのことです。
なお、欧米人はこのような見方をするためか、嵌め込みシステムを追求したという話を聞いたことがありません。
ところで、骨格ルーチンの方を共通部品だとみると、話が違ってきます。それは、サブルーチンを呼び出すメインルーチンの方が実は共通ルーチンだということに相当します。これは、常識的な使い方ではありませんから、ここを追求すると何か得られる可能性があります。これについては ｢付録４．ものを認識する際の図と地の分離について｣ を参照してください。
[嵌め込みシステムの第二の罠]
第二の罠をすり抜けるには、嵌め込んで合成する機構に重点をおくのか、部品の内容に重点をおくのかという正しい判断が求められます。部品の内容の重要性を薄々感じている人も、一旦ツールの開発を始めてしまうと、それにのめり込んでしまうものです。こうして、第二の罠にかかって失敗しています。
実際に、嵌め込んで合成する機構は多くのところで開発されましたが、それを上手に使いこなしているところは少ないようです。その原因は、骨格ルーチンや補填ルーチンユニットという部品の単位をいか様にもでき、その意味が不明確になってしまう点にあります。様々なレベルのプログラムの断片の山ができるだけで、それらを整理することに失敗してしまうのです。整理されていないものはゴミと同じですから、ほとんど役に立ちません。部品と呼んでみてもむなしいだけです。
そこで、機構にこだわった人達の一部は、嵌め込みシステムの上に部品検索システムを開発することで、この問題を解決しようとしました。しかし、それはゴミを検索するシステムになるわけで、たまにはゴミも役立つでしょうが、それだけのことです。本質的な整理にはなっていません。
このような失敗をした人々やそれを知っている人々は、嵌め込みシステムと聞いただけで敬遠します。ウッドランド社は、SSS の嵌め込みシステムとしての面を強調していましたが、こうすることで敬遠されたためにだいぶ損をしたのではないでしょうか。
[部品の単位を決める指導原理とその効果]
嵌め込みシステムがこれらの二つの罠をすり抜けたとすれば、あと一歩で成功することでしょう。
最後の一歩は、部品の単位を決める強力な指導原理です。何の考えもなく勝手に部品を決めていったのでは、部品というものをどう捕らえてよいのか分からなくなり、嵌め込みシステムを役立てることができなくなってしまいます。混乱に陥いらないように、部品の単位を決める強力な指導原理を打ち立てる必要があります。
SSS 部品群を見てみると、二つの指導原理の下にモジュール分割されています。その一つは ｢第１章 特注アプリケーションとパッケージの間に｣ の中で述べたデータ項目対応の分割です。つまり、業務仕様に関係する補填ルーチンユニットをデータ項目に対応づけて分割するという指導原理です。もう一つはこれから説明する業務と操作の分離です。これは、第１章の中の次のパラグラフに続けるのがよさそうです。
もしも、共通仕様に関係するプログラム部分は共通にして、各社各様の仕様に関係するプログラム部分だけを各社各様に作成することができれば、特注アプリケーションの開発を合理化することになります。しかし、これは言うはやすく行うは難しであります。共通部分と各社各様の部分の間に明確な線引きがなされているわけではありませんし、この線引きが簡単にできるわけでもありません。ですから、どこが各社各様の部分だといわれても対処できるような備えが必要であり、プログラムと仕様との対応関係を根本から見直さなければなりませんでした。
この見直しの中で、ある線引きのアイデアが浮かびました。それは、業務仕様に関係するプログラムと操作仕様に関係するプログラムの間に線引きをしたいという希望のようなものです。もしも、これが実現できれば、だいぶ見通しがよくなります。
操作仕様とは、アプリケーションの操作性に関係する仕様ですから、A 社向けも B 社向けも基本的に同じにしてよさそうです。したがって、操作仕様に関係するプログラムは共通になるわけです。これに対して、業務仕様の方は、共通部分もあれば各社各様の部分もあります。したがって、業務仕様に関係するプログラムは、カスタマイズの必要性がある部分だといえます。
これらを総合すると、この線引きによって、カスタマイズの可能性が高いプログラムをある範囲に絞り込めるはずだと確信できます。
ところが実際のプログラムを見ると、業務と操作はごちゃ混ぜになっています。ですから、これを分離するには大手術が必要でした。
この手術の中身は細かくなりすぎるので省略することにして手術後の状態をみると、操作仕様に関係するプログラムが骨格ルーチンになり、業務仕様に関係するプログラムが補填ルーチンユニットになりました。
骨格ルーチンの方が操作ですから、共通部品なのです。これで、図らずも第一の罠をすりぬけることができました。
そして、操作仕様に関係するプログラムという骨格ルーチンの実物を先に開発した後で、それに必要な嵌め込み機構を開発したわけですから、第二の罠もすりぬけています。
いよいよ佳境に入ってきたので、部品の単位を決める指導原理が適切かどうかという本質的な問題をその効果によって判定することにします。
まず、骨格ルーチンと補填ルーチンユニットという部品の単位が明確になり、その意味が捕らえやすくなりました。部品の単位に関する野放図な自由度をなくすことで、あるパターンに合致する規格化されたものにできました。
そして、カスタマイズの可能性が高いプログラム部分をある範囲に絞り込むことができました。また、操作仕様に関係するプログラムを共通化できました。
この他、ビジネス分野ではデータ項目名によって仕様変更要求が表現されるという特徴を利用して、プログラムと仕様との対応関係を非熟練者にも分かりやすいものにできました。これについては、｢第１章 特注アプリケーションとパッケージの間に｣ の中で述べた通りです。
このような効果があるので、ウッドランド社が採用した部品の単位を決める指導原理は大変に有効に働き、これによって実用的な部品化再利用システムが構築できたのだといえます。
因みに、再利用のしやすいことで定評のある Smalltalk
システムでは、階層をなすオブジェクト群の構成を決めるために、MVC
(model view controller) という三つに分割するのだという指導原理を用いています。そして、この指導原理の重要性が指摘されていますが、正にその通りだと思います。
第四世代言語 (以後 4GL と略記する) は、第一世代の機械語、第二世代のアセンブラ言語、第三世代のコンパイラ言語に続くものですが、汎用性を追求するよりも、むしろビジネス分野をターゲットに絞っていることが普通です。その数は、4GL ベンダの数だけあるので、優に 100 を越えます。4GL かどうかの判定基準として、エンドユーザにも使えることとか、何日以内に習得できることなどをあげる文献もありますが、世間一般が認める判断基準にはなっていません。4GL には、いろいろな分類法がありますが、ここでは、ビジネス分野の特注アプリケーションやパッケージの開発に使えるような基幹業務向けの 4GL を対象にして、詳しく見ることにします。
CASE は最先端だが、4GL は時代遅れだという印象があるかもしれませんが、そんなことはありません。4GL は名目的にもちゃんと広義の CASE に含まれますし、実質的にもその効果は相当のものです。なぜなら、4GL はビジネス分野のアプリケーション開発の経験を踏まえて設計されたものが多いからです。ただし、理論的な裏付けが希薄であったり、なぜ効果があるのかを曖昧のままにしているものが多いようです。
初期の 4GL は、それまでの COBOL などの第三世代言語に改良を加えて、リレーショナルデータベースを上手く使いこなすための言語として生まれました。この仕様は各社各様でしたが、どれも１〜２行で目的のデータを検索できるという意味で同じようなものでした。COBOL ではどうかというと、データ検索をするには 10 行 〜 20 行のプログラムが必要でしたから、4GL は効果的でした。
また、4GL はデータベースへのアクセスだけでなく、データベースの定義にもメスを入れました。COBOL を使う場合には、プログラム中のデータ宣言とデータベースの各データ項目の定義の両方を行うことか必要でしたが、4GL はこの重複定義をなくしました。なお、リレーショナルデータベースのアクセス法は、その後 SQL として標準化されて COBOL からも使うことができるようになっていますし、データベース管理システムは第三世代言語に対してもデータ宣言の重複定義を不要にしています。
更に、4GL はデータベース定義の延長線上に、画面や帳票を簡単に定義できるようにする機能を付け加えていきました。これは、プロトタイプの作成に有効なものです。
[イベント駆動方式]
ところが、このような初期の 4GL の成果は、徐々に第三世代言語にも取り込まれることになり、4GL は新境地を開くためにイベント駆動方式を採用することになりました。
初期の 4GL は、COBOL 言語などと同様にメインプログラムの先頭の文から順に (時にはループしたり文を飛び越したりしながら) 実行されるもので、何の変哲もない普通のプログラムの動作スタイルを採用していました。
これに対して、後期の 4GL はイベント駆動と呼ばれるモダンな動作スタイルを採用してきました。これを採用すると、プログラムが数多くの断片から構成されることになります。ここで各断片とは、正式にはイベントプロシージャと呼ばれるものであり、イベントを契機として起動されるプロシージャのことです。それではイベントとは何かというと、事象という意味であり、例えば操作員がキーボード上のファンクションキーを押したとか、画面上のある項目にデータの入力があったというタイミングのことです。こういうイベントを契機としてそれぞれのイベントプロシージャが起動されるわけです。これらを総合すると、例えば画面上のある項目にデータの入力があると、それを処理するイベントプロシージャが起動されてチョロッと動作するということができます。
一般にイベントプロシージャは、画面や帳票またはそれらの中のデータ項目というオブジェクトとイベント種別との組み合わせに対応して作られます。そして、イベント駆動方式とは、あるオブジェクトに関するあるイベントが発生すると、そのオブジェクトのそのイベント種別に対応するイベントプロシージャを動作させる仕組みのことです。
イベント駆動方式を採用するとプログラムの組み方が伝統的な COBOL のプログラミングスタイルとは異なってしまいます。それぞれのオブジェクトのそれぞれのイベント種別に対応する数多くのプロシージャに分割しなければなりません。したがって、伝統的な COBOL が上から下に流れるダラダラプログラムだとすれば、イベント駆動方式を採用すると数多くのツブツブのイベントプロシージャになります。
[4GL と嵌め込みシステム]
ところで、イベントプロシージャが呼び出されるということは、何かがそれを呼び出しているはずです。この何かを 4GL の制御プログラムと名付けることにします。こう命名すると、4GL の制御プログラムがイベントプロシージャを呼び出すという言い方ができます。
ここで、嵌め込みシステムを思い出してください。よく見ると、イベント駆動方式と嵌め込みシステムとは、似ているではありませんか。4GL の制御プログラムが骨格ルーチンに対応して、イベントプロシージャが補填ルーチンユニットに対応します。この対応関係は、単に呼び出し関係だけでなく、その機能についても成り立ちます。SSS 部品群の構成要素の一つである骨格ルーチン (SSS 部品群の中のデータ項目に対応しない構成要素) が操作に関するプログラムであったのと同様に、4GL の制御プログラムも正に同じ機能を果しています。
結論として、イベント駆動方式は、いわば共通メインルーチンを共用する仕組みだといえることが分かりました。 これは、嵌め込みシステムが、共通サブルーチンではなく共通メインルーチンを共用する仕組みであったのと全く同じです。そして、双方の共通メインルーチンを見ると、どちらも操作仕様に関する処理を果しています。つまり、SSS 部品群の構成要素の一つである操作仕様に関係するプログラム (骨格ルーチン) と 4GL の制御プログラムの役割は同じだったのです。
[4GL が生産性向上効果のあるわけ]
以前から疑問に思っていたのですが、後期の 4GL (第四世代言語) はその名前に似合わず、その言語仕様にさしたる特徴がありません。市販の 4GL の言語仕様を詳しく調べてみると、COBOL などの第三世代の言語仕様と比べて本質的な違いがないことが分かります。例えば、COBOL の CORRESPONDING MOVE 文で記述できないようなデータの移動処理のためには、4GL でも MOVE に相当する文を一つずつ記述しなければなりません。また、COBOL の IF 文に相当する文も記述が簡略化されるわけでもありません。このような比較検討をすると、市販の 4GL の言語仕様は第三世代言語と肩を並べている事実が確認できます。
それにもかかわらず、4GL を使うと確かに生産性が向上するのです。これが不思議でなりませんでしたが､“部品化アプリ” の検討をしていく中でその理由がやっと分かりました。それは、操作仕様に関係するプログラムを書かなくて済むために得られる生産性の向上効果だったのです。つまり、4GL の制御プログラムが操作に関係する処理を代行してくれるおかげだったのです。ただし、この結果 4GL で開発したアプリケーションは、その操作性を少し変えたいと思っても簡単には変えられないという問題点をはらむことになりました。
[4GL が主流にならないわけ]
市販の 4GL の利用者がしばしば問題にするのは、ほんのちょっとしたところなのですが「自由がきかない歯がゆさ」です。4GL のサポート範囲をちょっとでも逸脱した使い方をしようとすると、完全に拒否されてしまいます。このために ｢4GL は懲り懲りだ｣ と嫌われることがよくあります。ある開発者が次のように言っていました。
｢4GL を用いて開発したアプリケーションプログラムをテスト中に、操作性を少し変更せよと要求された。それは、4GL では実現できないものだったので、無理だとお客様に説明した。しかし、分かって貰えず、結局は要求を満たさざるを得なくなった。このために、急遽 4000行ほどのプログラムを休日返上で開発しなければならない羽目になった。最初から COBOL で組んでおけば、こんな目にあわずに済んだのに｡｣
この 4GL の典型的な問題点は、｢画面スタイルがその 4GL 固有のものになってしまう｣ と表現されることもあります。画面スタイルとは、画面の図柄やそのレイアウトや操作性のことですが、特に操作性が固定されてしまいます。これは操作性を統一することになるので良いともいえますが、一般に欧米で開発された 4GL の操作性には違和感を持つ人が多いのも事実です。
なぜ 4GL では操作性を簡単には変えられないのかというと、操作性に関するプログラム (即ち 4GL の制御プログラム) は、4GL の内部のインタープリタまたはプログラムコード生成部にいわばワイヤードロジックのように固く組み込まれているからです。これを変更するには、通常は 4GL 自体をプログラムカスタマイズすることが必要であり、ベンダがこの変更要求にタイムリーに応えてくれることは稀です。
もう一つの大きなの問題点は、4GL の仕様は各社まちまちで、標準化されていない点です。少なくとも言語仕様は標準化されるべきだと思うのですが、この常識が通用しません。4GL を使用するには、どれか一つを選んで、その新たな言語仕様を覚えなければなりません。ですから、市販の 4GL を採用したいと考えても、非標準の言語仕様に躊躇してしまう人も多いようです。バベルの塔の罰を自ら進んで受けることになるのですから、変な話です。
前述の考察で分かったように、4GL の真骨頂は、操作性に関する処理を行う 4GL の制御プログラムだといえます。ですから、それをより良いものにするベンダ間の競争のために仕様に違いが出てくるのは、必要悪ですから仕方がないとしても、IF 文の書き方のような言語仕様までも各社各様にする必要はないはずです。疑いの目でみると、4GL ベンダは、ユーザを囲い込み逃げられないようにするために独自の言語仕様を制定しているのだと思えてきます。こういう狭い考え方は問題だとして、コンピュータの世界ではオープン化の波が起こったわけですから、プロプライアトリな言語仕様にこだわり標準になり損ねた 4GL は使われなくなることでしょう。
この流れに従うと、オープンな 4GL が求められるわけであり、これを追求していくと、標準化された言語仕様の上に操作性に関する処理を行う共通メインルーチンを作ればよいという結論になります。こうなると、4GL という名前も相応しくなくなりますから (現状でも相応しくないのですから)、4GL は発展的に解消して共通メインルーチンへと変身するのがよいのではないでしょうか。なお、こうなったとしても 4GL の名はビジネス分野のアプリケーション開発の経験を踏まえて実質的な効果を上げたフロンティアとして歴史に残ることでしょう。フロンティアスピリットは尊重されるべきです。
[スーパルーチン]
ところで、GUI アプリケーション向けのビジュアル開発支援ツールは、イベント駆動方式を採用しているのが普通です。こうしたものを調査してみると、GUI 操作の制御プログラムも 4GL の制御プログラムと同じ役割を果してることが分かります。
下記の三つのプログラムの役割は、操作に関係する処理という点でほとんど同じですし、これらはいわば“共通メインルーチン”だという点も同じですから、これらを一括して取り扱い、スーパルーチンと呼ぶことにします。
・ SSS 部品群や“部品化アプリ”の内の操作仕様に関係する制御プログラム
・ 4GL の制御プログラム
・ GUI 操作の制御プログラム
ところで“共通メインルーチン”と共通サブルーチンとを比較すると、いろいろなプログラムで共通に利用されるルーチンという点では全く同じですが、次の点が異なります。即ち、共通サブルーチンは、呼び出される部分の共通性に着目して括り出したルーチンですが、共通メインルーチンは、呼び出す方の共通性に着目して括り出したルーチンです。
なお、後述の“ソフトウェア部品”の性質を備えるためには、単なる共通性だけでは不十分であり汎用性
(体系的に網羅すること) が必要なことを付け加えておきます。
SSS/Win の開発の前に行った“部品化アプリ”の検討の中で、SSS の嵌め込みシステムと 4GL やビジュアル開発支援ツールのイベント駆動方式とを比較しました。そして、双方の良いとこどりをすることにしました。
[SSS/Win における改善点]
呼び出し機構については、イベント駆動方式の方が嵌め込みシステムよりも優れていました。
嵌め込みシステムでは、補填ルーチンユニットの個数によって、骨格ルーチンの一部を修正することが必要です。即ち、骨格ルーチンのスロットに嵌め込むユニットがない場合には、ダミーのスロットに置き換えたり、画面の項目数に応じてスロットを増設することが必要になります。ところが、イベント駆動方式の方は、こういったことが一切不要です。ですから、近代的なイベント駆動方式を採用したことは言うまでもありません。なお、イベントプロシージャの呼び出しの際のパラメタの取扱いに改良を加えて、更に良いものにしたことを付け加えておきます。
部品の単位を決める指導原理を見ると、双方とも次の二つを採用しています。その一つは業務と操作の分離であり、もう一つはデータ項目対応 (オブジェクト対応) の分割です。ところが、SSS 部品群の方は、より忠実に指導原理に従って分割されていることが分かりました。
業務と操作の分離について詳しく言うと、4GL やビジュアル開発支援ツールでは、ハードウェアの動作に近いところで線引きをしています。例えば、画面上のある項目にデータが入力されたことをイベントにしています。指導原理により忠実に従うと、SSS 部品群の分割方法のように、画面上のある項目のデータをチェックすべきタイミングをイベントにすべきです。即ち、データが入力されたとき以外にもカーソルの移動時などにデータのチェックが必要な場合があるので、そういう括りをイベントにした方が業務に関するプログラムが組みやすくなります。ハードウェアの動作を依存するイベントよりも業務処理に依存するイベント体系にすべきなのです。こうすれば、業務に関係しない部分は極力操作の側に押し込めることができます。
データ項目対応 (オブジェクト対応) の分割について詳しく言うと、4GL やビジュアル開発支援ツールでは、データ項目部品を形成するための重要なイベントが欠落していました。それは、一般的な言い方をするとアップデートプロパゲーションのためのイベントです。つまり、他のデータ項目の値の変化を契機としてイベントプロシージャを起動する機構がないのです。この欠落のために、イベントプロシージャのデータ項目ごとの区切りがぼやけていました。これを具体的に説明すると、例えば商品コードというデータ項目にデータが入力されたときに動作する商品コードのイベントプロシージャの中では、商品コードのチェック処理の他に、商品名称の表示処理のような他のデータ項目の処理までも必要になってしまい、データ項目部品といえないということです。
そこで、SSS 部品群のようにより忠実に指導原理に従うために、一般のイベント駆動方式を改良した方式 (これをスーパイベント駆動方式と呼ぶ) を設計しました。そして、この方式を SSS/Win の中核ツール eee MANDALA (ﾄﾘﾌﾟﾙｲｰ･ﾏﾝﾀﾞﾗ) の中に組み込みました。このインプリメントに当たっては、開発負荷を軽くするために、マイクロソフト社の Visual Basic というビジュアル開発支援ツールにアドオンするツールとして開発しました。
なお、この開発においては次の四点に注意をしました。
・ ビジュアル開発支援ツールに含まれていない 4GL の機能を全て取り込む
・ 操作性の変更要求 (カスタマイズ要求) に対応しやすい構造にする
・ GUI の見栄えの良い操作だけでなく従来通りのキーボード操作も可能にする
・ 標準となった言語仕様を用いる (ローカルな言語仕様はつくらない)
こうすることで、eee MANDALA
に 4GL の有用な機能を盛り込み最高のツールにすることを目指しました。また、4GL
が嫌われる問題点を解消するためには、eee
MANDALA 自体をタイムリにプログラムカスタマイズすることが必要ですから、実際にこのサービスを有償で行うことにしました
(行っています)。なお、一般のベンダがツールのカスタマイズサービスに積極的でないのは、第１章で述べたパッケージ開発業者と同様に手離れのよいビジネスを好むためです。