ソフトウェア工学とTRIZ(3) ジャクソン法をTRIZの観点から見直す (中川徹, 2005. 9)

TRIZ 研究ノート
『ソフトウェア工学とTRIZ』 (3) ジャクソン法をTRIZの観点から見直す
中川　徹 (大阪学院大学) 研究ノート, 2005年 1月16日
[掲載: 2005.10.12]

For going back to English pages, press buttons.

まえがき研究ノート『ソフトウェア工学とTRIZ』について (中川徹, 2005年 9月 5日)

ここに掲載しますのは、昨年 8月にスタートさせた研究ノート『ソフトウェア工学とTRIZ』の第3編です。大阪学院大学の卒業研究ゼミで議論したことをベースに発展させて記述しています。

この『ソフトウェア工学とＴＲＩＺ』のシリーズのねらいは、第1編で書きましたようにつぎの3点です。

(1) TRIZの適用分野を、特にソフトウェア関連分野に発展させ、拡張する。
(2) ソフトウェア工学にTRIZの観点を導入して、ソフトウェア工学自身をより明確にする。
(3) ソフトウェア工学/情報科学の知見を、TRIZの考え方にフィードバックする。

この第3編は2005年1月16日に仕上げていたのですが、その後多忙であったことと、いろいろな記事を優先させたために8ヶ月遅れで掲載することになりました [なお、本文中の [ ] 内の記述は、今回の掲載にあたって補足した部分です]。TRIZをソフトウェア開発関連に適用したいという要望が高まっているときであり、やはりもっと早くに掲載するとよかったと思っています。

なお、本シリーズの第1編は「構造化プログラミング」についての議論で、2004年8月に研究ノートとして掲載し、10月に三菱総研で発表、さらに英語の論文にしてTRIZCON2005 で発表し、本ホームページの他にTRIZ Journal にも掲載しています。第2編は、「段階的詳細化」に関する議論で、2005年2月に研究ノートとして本ホームページに掲載しました。この第2編と今回の第3編とをまとめて英文論文とし、この11月にオーストリアで開かれるETRIA主催のTRIZ Future Conference 2005で発表します。

この第3編はかなり苦労しながら書いています。ソフトウェアの基本的なことを記述しつつ、それをTRIZの言葉で説明するまではきちんとできるのですが、ソフトウェアの原理をTRIZに持ち込むことが大変です。また、TRIZをソフトウェア関連に導入することにより、ソフトウェア分野に新しい考え方を導入しようと試みていますが、なかなか適当な切り口が見つかりません。(ソフトウェアという計算機科学の土俵において、TRIZが新しい (計算機科学が見落としていた) 寄与をしようというのですから、一筋縄でいかないのはしかたがありません。)

目次:

『ソフトウェア工学とTRIZ』
  (3) ジャクソン法をTRIZの観点から見直す

1. ジャクソン法とは (ソフトウェア工学の立場での説明)

    [紫合] 2.4 ジャクソン法

2. ソフトウェア工学の立場での補足説明

    2.1 ジャクソン法におけるデータ構造の表現法について
    2.2 ジャクソン法でのプログラムの構造 (ツリー表現)
    2.3 通常の (ジャクソン法を使わない) プログラム例の構造
    2.4 「先読み手法」とは何か、その有効性の条件
        2.4.1 先読み手法を使わないプログラムのフローチャート
        2.4.2 先読み手法を使ったプログラムのフローチャート
        2.4.3 入れ子構造を持たない場合の先読み手法の無効性

3. TRIZの観点から見た「ジャクソン法」によるソフトウェアの構造化

    3.1 「処理すべき対象」の構造を考えるべきこと
    3.2 処理の対象に対応した処理システム
    3.3 処理の順序とリズム
    3.4 先を読んだ処理の方法 (「未来」の「先取り」)

4. 情報科学 (特にジャクソン法) の観点からTRIZを見直す

参考文献

まず、紫合のテキストの記述を以下に採録させていただく。

ソフトウェアに関して非専門家の読者のために、まず説明しておくべきは、紫合の図2.14に用いているデータとそのデータ構造の表現法についてであろう。この例で扱っているのは、比較的簡単な構造の命令 (コマンド) がつぎつぎとコンピュータに与えられ、コンピュータはそれを処理して、その処理したことを逐一記録しておく問題である。一つの命令は [1行または複数行からなり]、コマンド名とそれに続くいくつかの (0から数個で、不定数の) パラメータからなる。パラメータにもいくつかの種類 (ここではA, B, Cの3種) がある。これらの命令とそのパラメータがどのような順序で入ってくるかは不定である (すなわち、そのときそのときの具体的なデータで異なり、予測できない)。

紫合の図2.14 (b) でデータ構造を表現するために使っている図式の表記法をここに説明する。まず、一つずつの長方形でデータを表現しているが、それは個別のデータだけでなく、一群の (一セットの) データをまとめて表現する場合にも使う。図の全体は、上下に階層的な関係を示しており、最上位にあるのがここで問題にするデータの全体を表現する。この全体データの構造 (構成のしかた) をつぎつぎに下位に詳細化して記述するのがこの表記法である。データ構造の一段の詳細化は、処理の制御構造を「構造化プログラミング」(本研究ノート (1)

を参照) で詳細化したのと同様に、「順次」、「選択」、「繰返し」の3種だけを使って行い、下記の図1のような表現法を用いる。

すなわち、下位で横に並べてあると、それらの下位データ構造が順次に (その順で) 現れることを示す。どちらかが選択されるときには、長方形内の右上に○印を書く。また、繰り返し現れる下位のデータ構造の場合は、長方形内の右上に＊印を書く。このルールを知って紫合の説明を読めば、この例のデータの構造が明確になろう。

ジャクソン法でプログラムの詳細設計を行うには、紫合が図2.15を用いて説明しているようにつぎの手順に従う。

紫合の例で、図2.15 (c) で得た入力データ構造と出力データ構造とをつき合わせたツリー表現から、図2.16の疑似言語で表現した詳細設計プログラム (すなわち上記 (e)) を得るための中間過程を明示するために、上記 (d) にいうプログラムの制御構造のツリー表現を作ろう。それは図2に示したようになる。

図2. ジャクソン法で作ったプログラムの制御構造
[注意: 下から2段目の入力命令は中川が補った。]

この図2を紫合の図2.15 (c) と比較すると、まず、ほぼすべてのレベルで、実質的な処理本体の前に「前処理」を置き、後ろに「後処理」を置いているのが分かる。これは、プログラム開発の経験によって蓄積された一つの知恵であり、(ここではその細部まで明示されていないが) いろいろ細部の処理が必要になるものである。また、「入力」の命令が明示されている。なお、紫合が後述しているように「先読み入力」の方法によりすっきりとした制御構造になっている。ただし、紫合のプログラム (図2.16) で、コマンドを読んでパラメータの処理を始めようとする段階で、入力命令が欠如している。これはバグであり、中川が図2.16に補足した。この補足した入力命令は上図2の下から2段目の入力命令に対応する。これがないと、コマンドを読んでパラメータの処理を始めようとしたときに、まだパラメータを読んでいないことになる。

ところで、「データ構造を無視したプログラムの例」として、紫合が図2.17に掲げたプログラムの考え方を見ておくことも参考になるだろう。大事なことは、紫合がここに示したプログラム例は「わざと悪い例を作って見せている」のではなく、ある点で最も素直にこのコマンドデータ列を処理しようとしている、典型的な、その意味で正しく作成されたプログラム例だということである。このプログラムももちろん自分の制御構造を持っているのだから、それを図2と同様の表記法で記述しよう。その結果、図3を得た。

要するにこのプログラムは、コマンドデータ列からデータを一つ一つ読み、その時点でやれること/やらねばならないことをすべて実行しようとしているのである。[プログラム全体として見ると、「一つのデータの入力とその処理」を繰り返すという構造をとっていることが分かる。] 入力されるデータは、コマンド名またはパラメータである。第1コマンド名を読んだ段階では、コマンドの前処理とパラメータ部の前処理までしかできない。つぎに新しいデータとしてパラメータを読むと、それを一つ一つ処理する。さらに、(第2以降の) コマンド名を読むと、その直前までのコマンドに関して、パラメータ部後処理をし、レポート本体を作り、コマンドの後処理をして、その後でいま読んだコマンド名に関するコマンド前処理、コマンド名処理、パラメータ部前処理を行う。このようにしてデータを読み進み、最後にEOFを読んだ時点で、直前のコマンドに関する処理を完了して、全体の後処理をしている。

紫合がここで論じているのは、ジャクソン法で作ったプログラムの構造 (具体的には、図2の制御構造のツリー図) が、入力データの構造および出力データの構造とすなおな対応づけができていて、その制御の論理がすっきりしていることである。これに引き換え、図3で表されているプログラムの制御構造は、処理の構造が [入力データに順次対応する形になっていて] 入出力のデータ構造とうまく対応せず、[類似の処理が] あちこちに分散していて、論理的にすっきりしていないことである。このような構造の論理性の違いは、上記の図2と図3とを見比べることで、(両者の疑似言語によるプログラム (紫合の図2.16と図2.17) を比べるよりも一層) 明瞭に分かるであろう。

そこで、「データを一つ読んでは、その段階で実行できる最大限の処理をする」という方針で作成した「通常の」プログラム (図3 = 紫合図2.17) に対して、ジャクソン法によるプログラム (図2 = 紫合図2.16) の特徴、特に制御構造の構成のしかたの特徴は何か? ということを考える必要がある。望ましい制御構造は問題の構造 (あるいは入出力データの構造) を素直に表したものであるべきだが、それを支えている具体的な方法として、紫合はここで「ジャクソン法が先読み手法を使う」ことだと述べているのである。

ところで、「先読み手法」というのを、「データを先に読んでから、処理を実行すること」と理解すると正しくない。上に説明したように、図3のプログラムこそ、「データを一つ読んで、そこでできる最大限の処理を実行する」ことをやっているのである。「先読み手法」とは正しくは、「データを一つ読んで、すぐに処理できることは処理するが、「さらにもう一つ次のデータを先に読んで」、後に来る状況を簡単に判断した上で、次のデータのための処理は留保して、その前に現在しておくべきことをしてしまう」方法である。[(2005. 9. 7 中川補足) ここの記述はあまり適当でない。後の2.4.3節の最後の補足を参照。]

この違いを理解するために、あるいは、「先読み手法」の本当の有用性を理解するために、両方法の処理のフローの違いをもっと明確に図にして見よう。これには簡略化したフローチャートを使おう。(ここで疑似言語での表現を避けた理由は、紫合の図2.16においては重要な入力命令が欠けていたバグがあったこと、また、紫合の図2.17では入力命令が明示されていず、while文の条件記述の中に入力文が隠れてしまっているからである。)

まず、図3のプログラム (すなわち、紫合の図2.17のプログラム) をフローチャートにしたものが図4である。細部を省略して骨格を描いているので、その処理内容がずっと分かりやすく表現できている。このプログラムでは、入力命令は1箇所だけであり、データを入力しては、それが (第1あるいは後続の) コマンドであるか、パラメータであるか、EOFであるかに応じて、その時点でできる/するべき最大限の処理を実行しているのである。

図4. 図3のプログラム (すなわち、紫合の図2.17のプログラム) の概略フローチャート表現

これに対して、ジャクソン法で作成したプログラム (紫合の図2.16) の制御構造 (図2) を改めてフローチャートに描き直したものが図5である。データ入力命令がこの場合3箇所に現れている。全体の構造が随分すっきり表現できていることが分かるであろう。その処理の骨格は、紫合のテキストに説明するように、「最初に1回データを読んで、以降はデータ処理をしたあとデータ入力をすることを繰り返す」ことをしている。ただし、このプログラムではそれが2重の入れ子構造になっていて、複雑になっていることが分かる。ここで大事なことは、図5で繰り返しの条件を書き直して明示しているように、それぞれの繰り返しにおいてどんな入力データを期待/予想しているかである。外側のループの入り口の条件文では、直前で読んだ入力データがコマンドであるかEOF (すなわちデータの終わり) であるかを区別しようとしている。すなわち、このループ内では「コマンド部の処理」を行っているのである。一方、内側のループの入り口の条件文は、直前の入力データがパラメータであるか、それとも次のコマンドまたはEOFであるかを区別している。すなわち、この内側ループの内部では個々のパラメータの処理をしており、内側ループを完了して後に、「コマンド部の処理」の最終段としてこれらのパラメータを使ったコマンドの処理をしている。

図5. ジャクソン法で作成したプログラム (紫合図2.16 および中川図3) のフローチャート

2.4.3 入れ子構造を持たない場合の先読み手法の無効性 (非有用性)

この図5で示したジャクソン法のプログラムの「先読み手法」の説明において、上記のように2重の入れ子になっているのを見たけれども、実はこのように「入れ子」になっているのが「先読み手法」が本当に有効な場合の特徴であることが分かる。処理すべきデータの構造に階層性 (すなわち、「入れ子」の性質) があるために、ジャクソン法を利用することに意義があり、この「先読み手法」が特別の意味を持つのだということである。もっと限定していうと、入力データが複数階層で構成されている場合に、「先読み手法」が意味を持つと言える。例えば、ここで扱った例題の問題設定を少し修正して、「入力のコマンド列において、データはコマンドごとに1行になっていて、各行にはコマンド名といくつかのパラメータが記述されており、入力は1行ごとに行う (1行を分割して入力できない)」としよう。すると、「通常入力手法」のプログラム (図4に対応) と「先読み手法」のプログラム (図5に対応) とは、それぞれ図6 (b) と (c) のようになり、実効的な違いはなくなってしまう。

図6. 入力データが1階層である場合の「先読み手法」の無効性 (非有用性)

このように、入力データの構造が1階層である場合には、「先読み手法」は煩雑なだけで実質のメリットがない。この点では紫合のテキストの最後部の記述の意味をここで一層明確にできたといえる。

3. TRIZの観点から見た「ジャクソン法」によるソフトウェアの構造化

さて、以下には、TRIZの立場、観点から、上記の「ジャクソン法」によるソフトウェアの構造化について検討しよう。いままでの本研究ノートのシリーズ「(1) 構造化プログラミング」、および「(2) 段階的詳細化」での議論とはできるだけ重複しないように記述していきたいと考えている。

[(2005. 9. 7 補足) 今回のテーマとして考えるべきことは、「問題の構造」に関連して、「入出力データの構造」(すなわち、「処理すべき対象の構造」) という概念、そしてそれらを処理するための「処理プログラムの構造」 (すなわち、「処理システムの構造」) との関連についてであろう。]

まず最初に考察するべきことは、「問題の構造」、特に「入出力データの構造」という概念についてであろう。ここでは、「問題の構造」といっても、「とりあげるべき問題の体系」という意味ではない。それよりも「処理するべき対象がもつ構造」、あるいは「扱おうとしている対象の構成法」といったものである。ソフトウェアでいう「入出力のデータ」とは、ハード分野をベースにしているTRIZにおいては、「扱うべき対象物」、「いま開発/設計しようとしている技術システムで処理しようとする対象」、あるいは「この技術システムがつくり出す生産物」などを意味するであろう。

このような意味で、ソフトウェア工学 (特にジャクソン法) が、「入出力データの構造を明確にせよ」と言っていることに対して、TRIZの40の発明原理の中にはあまり直接的に示唆を与えるものはない。しかし、TRIZがそのような考え方を持っていないというよりも、ある意味でTRIZにとって「当たり前のこと」であるという方が正しいかも知れない。TRIZでは、「問題で扱おうとする技術システムを分析せよ」、「対象システムの上位システムおよび下位システムを分析・考察せよ」、「システムのまわりの環境を分析せよ」という。[そして、技術システムというときには、常に、作用するものと作用を受けるもの (作用の対象) を含めていっているのである。] 対象技術システムの「機能分析」あるいはTRIZ独自の「物質-場分析」をした上で、その分析パターンに基づき「76の発明標準解」を推奨している。また、対象とするものの「構造物」としての「構造」を考えることは、ハード分野においてまったく当然にするべきことである。-- ただ、ソフトウェア工学/情報科学における「データの構造」の概念には、より深い/抽象的な面があるから、その点は改めて第4節で考えよう。

また、「入出力データの構造」という場合に、「構造の階層性」が重要な要素になっている。この点に関しても、TRIZはその考え方のすべての面に「システムの概念」を持っており、その中核に「システムの階層性」の概念がある。この意味で、ジャクソン法 (あるいはもっと広く、ソフトウェア工学/情報科学) で重要視する「データ構造の中の階層性」の概念は、TRIZの観点から積極的に支持されるものである。

つぎに、ジャクソン法で、「良いプログラムの構造は、入出力データの構造を反映すべきである」と主張している点を考察しよう。これをハード分野の技術 (あるいは、技術一般) に対して翻訳すれば、「技術システムの構造は、それが処理/操作しようとする対象の構造を反映するようにせよ」ということである。これはある意味で当然の考え方であり、TRIZだけでなく、技術的な考え方一般 (あるいはビジネス世界の考え方一般) でも広く知られており、ある程度よく実践されている。この考え方に対応するTRIZの一般的な概念、および発明原理や発明標準解に表現されているより特定的な戦略を挙げてみるとつぎのようなものがあろう。

適切に構造化したプログラムが持つ特徴として、紫合は「データ構造を反映したプログラムだと、意味のあるまとまりをもったデータの処理 (例えばコマンドの処理) がプログラム中でもまとまった部分でなされる」と記述している。これを表現しているTRIZの指針にはつぎのものがある。

また紫合は、「処理の順序がプログラムの構造にもそのまま反映される」ことを望ましい特徴であるとしている。これはTRIZにおいては、「技術システムの完全性の法則」の中のサブ原理として含まれる「リズムの調整の法則」として知られている。SalamatovのTRIZ教科書ではこれをつぎのように表現している。

この「リズム調整の法則」をさらに具体的に示している指針として、つぎのような発明原理および発明標準解がある。

「先読み」という言葉で連想されることは、「すぐ次のデータ」すなわち「将来の状況」を知った上で、現在必要な処理をすることである。このような考え方はTRIZの根本思想の中に含まれており、TRIZは豊富な指針を持っている。

本節では、前節から立場を逆転させて、ジャクソン法においてソフトウェア工学/情報科学が主張していることで、TRIZに導入するとよいだろうことを考察していこう。

まず最初に、「入出力データの構造」という概念をTRIZに持ち込むことを考える。それを、TRIZで扱うような一般的な技術の問題において考えると、「処理するための装置/システムについて検討する前に、それで扱おうとしている問題の対象の構造、そしてそれで生成/生産しようとするアウトプットの構造を明確にするのがよい」ということを述べている。この観点は、3節で述べたように、ハード分野の技術においても考えられてはいるが、必ずしも十分に活用されていないように思われる。

(ハード分野を含めて) 一般的な技術分野においてしばしば混乱することは、「いま扱おうとしている問題の対象」という言葉が、上記に述べた「処理するための装置/システムが扱おうとしている対象」ではなく、単に「処理するための装置/システム」そのものを指すことが多いことである。だから、「問題とする対象」をシステムとして分析しているのだとして、「その問題を処理するシステム」の構造、機能、特性 (属性)、性能、メカニズム (機構)、問題点、欠陥などを分析する方法はさまざまに開発され、使われている。しかし、そうではなくて、「処理するための装置/システムが扱おう (処理しよう) としている対象」(の構造) を分析する方法となると、多くの場合に全く違った話になり、意識されている場合もあればあまり意識されていない場合もある。

例えば、土木の掘削装置を対象技術システムとして扱っているのであれば、そのシステムが扱う対象とは、掘削したい岩盤や地層などのことであり、その構造とは地質構造や鉱物の構造に関するものである。金属加工の旋盤機を扱っているのなら、その処理の対象は金属加工物や金属素材であり、その処理対象の構造とは、加工の形状の他に素材の特性をも含むであろう。これらの場合に、処理を行う技術システム (掘削装置や旋盤機械) の分野と、処理の対象物 (岩盤や金属素材) を扱う (解明する) 分野とが、大きく隔たっていることが分かる。(あるいは、旋盤機械でいうと、加工物の設計段階と加工処理の工作段階との違いになっている。)これらの隔たりのために、多くの技術分野で、いわば「責任の分担」が行われ、ある技術システム (装置) の開発/改良において、そのシステムの処理対象についての解明 (特に処理対象の構造の解明) は別途すでに (誰かが) やっているものだと、仮定していることが多い。

ソフトウェア開発においてもこのような隔たりがないわけではない。例えば、銀行業務に対するソフトウェアの開発であれば、業務ソフトウェアの開発者 (いわゆるシステムエンジニアやプログラマ) は、そのソフトウェアが対象とする銀行業務そのものに最初から精通しているわけではない。しかし、ソフトウェア開発での特徴は、処理対象の銀行業務そのものを情報/データとして表現し、それを処理するためのシステムのプログラムとほぼ同一の技術の枠組みで操作できることである。この特徴のために、「処理対象の構造」、「処理対象の入力と出力の構造」といったことを、特に明確に意識でき、またそれを具体的に分析/構成/再構成できる。このような特徴は得難いものであり、だからこそその知見をTRIZにも導入すると良い。

さて、具体的に「処理する対象の構造」というときに、どのような種類の構造を考えるとよいだろうか? 通常考えられているのは、つぎのようなものであろう。

情報科学においてはこれらの構造のすべてを対象にできるが、さまざまな技術分野に比べて最もよく発達しているのが、上記のうちの「論理的構造」であろう。処理対象を「情報」という形で一般的にとらえ、その「論理的構造」を表現する方法を多様に持っている。それらの構造は、情報に対する「データ構造」(および処理に対する「制御構造」) という概念で括られている。

「データ構造」の概念を一般の (ハード分野の) 技術の言葉で表現することは、ある意味で難しい。しかし、その概念は広範な技術分野にすでに浸透している。それは実際には、広範な技術分野 (おそらくすべての技術分野) での、固有技術とソフトウェア技術の協力・協調・一体化として、あるいはもっと具体的には、固有技術に対するコンピュータとソフトウェア技術の進出、自動化、知能化、情報システム化などとして現れている。これらに際して、各固有技術の分野の対象に関する知識が情報化され、そのデータ構造が捉えられているからである。

そこで、ソフトウェア工学/情報科学でいう「データの構造」をTRIZに持ち込むことを具体的に考えると、まず、つぎのような原理/推奨を導入するとよいであろう。

しかし、この記述はいかにも蛇足であり、TRIZでいう技術を「システムとして考察せよ」というときの当然のことしか述べていないと感じる。このレベルではすでに、TRIZにも、技術開発一般にも、よく知られた原理というべきであろう。

さらに、より限定的に「データ構造の導入」の原理/推奨を記述してみるとつぎのようになろう。

この原理/推奨は、前述の「技術システムの完全性の法則」の中の一つのサブ原理として考えるべきものであろう。この原理/推奨はソフトウェア工学/情報科学/ソフトウェア開発がTRIZに対していつも投げかけていることであると言える。処理の対象に関する構造の記述について、情報科学は (今回とりあげたジャクソン法だけでなく) 非常に豊富で精密な方法をもっている。

[1] 紫合治著: 『プログラム工学 -- 実装, 設計, 分析, テスト』, サイエンス社 (2002年10月)

[2] Darrell Mann: "Hands-On Systematic Innovation", CREAX Press, Ieper, Belgium, (2002); 中川　徹監訳, 知識創造研究グループ訳, 『TRIZ 実践と効用 (1) 体系的技術革新』, 創造開発イニシアチブ刊 (2004年6月)。[同出版案内と資料: 『ＴＲＩＺホームページ』, 2004年6月 (和

・英

)]

[3] 中川徹: 「ソフトウェア工学とTRIZ (1) 構造化プログラミングをTRIZの観点から見直す」, 『TRIZホームページ』, 2004年 8月

。

[4] 中川徹: 「ソフトウェア工学とTRIZ (2) 段階的詳細化をTRIZの観点から見直す」, 『TRIZホームページ』, 2005年 2月

。

[5] Toru Nakagawa: "Software Engineering and TRIZ (1) Structured Programming Reviewed with TRIZ", TRIZCON2005, The 7th Altshuller Institute TRIZ Conference, held at Detroit on Apr. 17-19, 2005.

総合目次	新着情報	ＴＲＩＺ紹介	参考文献・関連文献	リンク集	ニュース・活動	ソフトツール	論文・技術報告集	教材・講義ノート	フォーラム	Generla Index
ホームページ	新着情報	ＴＲＩＺ紹介	参考文献・関連文献	リンク集	ニュース・活動	ソフトツール	論文・技術報告集	教材・講義ノート	フォーラム	Home Page