TRIZ 研究ノート

『ソフトウェア工学とTRIZ』 (2)
  段階的詳細化をTRIZの観点か ら見直す

  中川 徹 (大阪学院大学)
  研究ノート, 2005年 1月 5日

    [掲載: 2005. 2. 7]

For going back to English pages, press  buttons.


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

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

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

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

1編では「構造化プログ ラミング」をテーマとして検討しました。新しい観点からいろいろ大きな成果が得られたと考え、本ホームページに掲載した後、三菱総研の知識創造研究会創造 手法分科会で発表し、さらに4月のTRIZCON2005でも発表するべく英文論文を仕上げて昨日送ったところです。

この第2編は、「構造化プログラミング」のバックになっている精神であり技法でもある 「段階的詳細化」をテーマにして、引き続き考察を進めています。いままで、ソフトウェア 工学としても (そしてTRIZとしても) さらっと話していたことを、じっくりじっくり考えて書きました。それでも、うれしいことに、この『ソフトウェア工学とTRIZ』という研究のアプローチ は、非常に豊かなもので、このアプローチの観点で少しずつ書き始めると、どんどん書き進む感じがしています。もちろん苦心しながら書いていますが、書くこ とによって自然に新しい地平が開けていくという、研究者冥利の体験をしています。どうぞ、お読み下さってコメントをいただければ幸いです。

 

目次:

『ソフトウェア工学とTRIZ』
  (2)  段階的詳細化をTRIZの観点から見直す

1.  段階的詳細化とは (ソフトウェア工学の立場での説明)

    [紫合]  2.3  段階的詳細化

2.  段階的詳細化の補足 (ソフトウェア工学の立場での補足説明)

    2.1  ソフトウェア開発の工程における段階的詳細化の位置づけ
    2.2  段階的詳細化におけるフローチャートの利用の再検討
    2.3  構造化図式のもう一つの方法:  HCP チャート
    2.4  「良い段階的詳細化の条件」と「詳細化の手戻り」の事例の検討

3.  TRIZから見たソフトウェア開発の段階的詳細化について

    3.1  概要の設計から詳細の設計へ
    3.2  「疑似言語」の役割
    3.3  「段階的詳細化の手戻りの事例」に対するTRIZの見方: もう一つの次元での分割
    3.4  段階的詳細化のための指針について

4.  段階的詳細化に関連して、情報科学がTRIZに示唆すること

    4.1  段階的詳細化の概念と指針のTRIZへの導入
    4.2  処理の制御構造の概念のTRIZへの導入

 

参考文献

 

 

本ページの先頭

1. 段階的詳細化とは

2. 補足説明

3. TRIZから見る

4. TRIZへのフィードバック

参考文献

シリーズ(1) 構造化プログラミング

 

 


 

 

研究ノート:

「ソフトウェア工学とTRIZ(2)
   段階的詳細化 をTRIZの観点から見直す」

 

2005 1 5   大阪学院大学  中川 徹

 

  本 稿では、ソフトウェア工学 (あるいはソフトウェア開発や情報科学) 分野でのトピックについてTRIZの観点を加えて考察する。この研究ノートシリーズの第2回として、紫合治著『プログラミング工学』を素材に用い、その 2.3節の「段階的詳細化」をテーマとする。このテーマは、ここではソフトウェア開発における「詳細設計段階」でのプログラムの設計法/記述法として論じ られている。ソフトウェア工学における重要なテーマである。

 

1.  段階的詳細化とは (ソフトウェア工学の立場での説明)

 

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

---------

資料:  紫合 治 『プログラム工学』(サイエンス社, 2002年) 2.3節 (22-25頁)

2.3  段階的詳細化

構造化プログラミングの2つ目の原理である段階的詳細化では、プログラムの概要から詳細へと記述のレベルを徐々に 詳細化していく。プログラムの概要記述といっても、制御構造文は最終的なプログラムとほぼ同じものを使う。従って、概要と詳細の差は、条件や命令文の記述 (日本語や英語が使われる) の表現の差になる。このように、制御構造文はプログラム言語で、命令や条件表現は自然言語で記述する方法を、疑似言語と呼ぶ。図2.9に疑似言語の規則の例を示す。また、図2.10に疑似言語を使ったプログラムの論理表現の例を示 す。

疑似言語:  C言語等、利用するプログラミング言語に自然言語を混ぜた表現

·        通常のプログラミン グ言語の繰返しや分岐文を使う。
    if (  )
xxxx  else  xxxx
    while (  ) 
xxxx
    do 
xxxx  while (  )
    for (  ;  ;  )
xxxx 
    break;
    continue;

·        集合要素に対する繰 返し記述を追加する。
    
forall  要素  in  集合  [ suchthat  条件 (要素) ]  {  - - -  }

·        実行文は問 題領域の 自然言語表現を自由に導入する。

·        その他、適宜便利な 表現を利用する。
    例:  except 文   (ただし書き) 

紫合 図2.9  疑似言語の規則の例


単語の 出現頻度表の出力 :  {

    単 語テーブルをクリア ;
    ファ イルをオープン ;    (†1)
    while ( 単語wをファイルから入力し、結果がEOFでない )  {
        if ( 単語wが単語テーブルに存在する )
            単 語テーブルのwの出現度を 1増やす ;
        else
            単 語テーブルに w を出現度1として追加する ;   (†2)
    }
    ファ イルをクローズ ;
    単 語テーブルを出現頻度の降順でソートする ;
    forall  単語w  in  単語テーブル  {
        単 語wを出力する ;
        '*' をwの出現頻度数だけ出力する ;
        改 行出力 ;
    }
}
  ただし
    †1 : ファイルがオープンできない場合は、メッセージ出力後終 了する。
    †2 : 単語の種類が上限を越えた場合は、メッセージ出力後、 ファイル読み込
           み処理を中断し、先 (ファイルクローズ以下) に進む。

紫合 図2.10  疑似言語による論理表現の例

これらの論理表現としては昔からフローチャートが使われ てきたが、選択や繰り返しの制御構造をより明示的にするにはフローチャートはあまり適切ではない。このため、フローチャートに代わるいくつかの表現が提案 された (日立製作所のPAD: Problem Analysis Diagram、NECのSPD: Structured Programming Diagramなど)。図2.11 に、これらの構造化図式の例を示す。

紫合 図2.11  構造化図式の例 (PADとSPD)

ここでは書きやすさ等から、以降の説明では疑似言語を使 う。疑似言語も、制御構造ができるだけ明示的になるように、制御文のキーワード (if、while等) を太字や下線付きにするなど、できるだけ目立たせるようにするとよい。

段階的詳細化では、上位段階で用いた自然言語による命令 や条件を、徐々に詳細化するのにも疑似言語を使う。すなわち、上位命令の詳細化として、基本制御構造と自然言語による疑似言語表現を使う。このように、段 階的詳細化によって、疑似言語表現の階層ができる。これを理解しやすくするには、

(1) 1つの階層の論理表現で命令のレベルが合っていること
(2) その階層レベルだけで (詳細を見に行かずに) 理解できること

などが必要である。 <例示の説明を約5行省略 [中川]>  図2.12に、良い段階的詳細化の条件を示す。

(a)  各命令記述ごとに独立に詳細化できること。

(b)  それぞれの段階で詳細を見ずに理解できること。

(c)  不必要な詳細まで表現されていないこと。

(d)  それぞれの段階で記述の詳細さのレベルが統一されている こと。

紫合 図2.12  良い段階的詳細化の条件

段階的詳細化で、概要から詳細へ段階的に進めるときに、概要での決定が詳細で覆されることもある。例えば、次の例はいかにもトップレベルの概要説明の論理表現のように見える。

前処理;
入力処理;
計算処理;
出力処理;
後処理;

こ の表現は、入力と計算と出力を分離するという設計であり、入力データはいったんメモリに取り込むという方式になっている。詳細に検討する中で、あるまと まったデータを入力した時点で計算し出力するというのを入力がなくなるまで繰り返す方式に決まったとする。その場合は、上の論理表現は適切ではなく、例え ば、つぎのような表現になる。

前処理;
while (データがつきるまで) {
    データのまとまりの入力;
    計算して結果を求める;
    結果の出力;
}
後処理;

このように、概要から詳細へ段階的に進めていくといって も、ある程度詳細な方式のイメージができていないと概要も表現できないことがあるので、注意が必要である。

 

2.  段階的詳細化の補足 (ソフトウェア工学の立場での補足説明)

2.1  ソフトウェア開発の工程における段階的詳細化の位置づけ 

  紫 合の『プログラム工学』は、プログラミングの学習から順次より大きなスケールでのソフトウェア開発の学習に発展することを意図して記述されており、通常の 「ソフトウェア工学」の教科書の記述とは逆の順序になっている。通常のソフトウェア開発における工程からいうと、ここで扱っているテーマは、「ソフトウェ ア設計」の段階が終了して各モジュールの仕様と処理内容の概要の記述がすでにできており、いまから「ソフトウェアの詳細設計」の段階で、各モジュール内の 処理内容を詳細化して記述していく段階である。

  各 モジュール (すなわち、主プログラムや副プログラムなど) の仕様は、(ここの前工程である「ソフトウェア設計の段階」の成果物として) その概要が通常主として自然言語で記述されている。一方、ここで問題にしている「詳細設計段階」の次には、「プログラミング段階」があり、そこでは実際の プログラミング言語 (例えば C言語) を用いて、実際にコンピュータで動くプログラムを作成し、そのプログラムのテストを行うことが求められている。そこで、この詳細設計の段階では、自然言語 で記述された処理の概要をベースにして、その処理を詳細に考察・設計して、プログラム言語で記述する直前の段階にまで明確化することが求められる。この段 階の作業の中心が「段階的詳細化」であり、そこで使われる記述法が「疑似言語」や「構造化図式」である。

  「段 階的詳細化」で行うべきことは、自然言語で書かれている処理概要を、逐次明確化して、プログラミングしやすい形式に構成・記述することである。そのため に、「処理」を「処理の構造 (すなわち、制御構造)」と「細部の処理内容」とに分離して、この制御構造の記述に、(後続のプログラミング段階で用いる) プログラミング言語の制御構造に準じたものを使用するのである。これが、疑似言語および (プログラミングの) 構造化図式の方式である。疑似言語では、適当な構文を用い、基本的に (改行や字下げを活用した) 文章の形式を使う。それに対して、構造化図式では、制御構造のの部分に図的表現を導入して一層明示的にする。

 

2.2  段階的詳細化におけるフローチャートの利用の再検討  

  と ころで、この段階での記述法として、フローチャートがどんな点で不便なのか、十分でないのかは、よく考察しておく必要がある。そのための具体例として、紫 合の図2.10をフローチャートで表現してみよう。以下の図1のように書ける。

1.  フローチャートによる論理表現の例 (紫合 図2.10に対応するもの)

  こ のフローチャートの表現において、つぎの点が原則的なフローチャートの記述法からの拡張になっている。

·        while文による繰り返しの構文を、分岐と戻りパスで表現し、繰り返しであることを注記した。

·        forall 構文による繰り返しを、やや例外的な表現法で繰り返しとして記述している。
   ただし、この表現法は Fortran言語でのプログラミングにおいて普通に見られるものである。

·        「ただし書き」は、(疑 似言語の場合と同様に) フローチャートの欄外での注記にしている。

·        全体の処理概要「単語の出現頻度表の出力」は、フロー チャートのタイトルとして扱った。

  このフローチャートでの記述例と、疑似言語および PADやSPDなどの構造化図式での記述例とを比べてみると、つぎのようなことが言える。

·        ·疑似言語および構造化図式 でいくつかの「制御のための構文」を導入しており、それが記述を分かりやすくする大きな要因である。フローチャートにおいても、対応するものを違和感なく 導入して拡張することは可能である。

·        フローチャートでは、全体の処理の流れを分かりやすく表現 できているが、「階層的な詳細化」といった表現よりも、「全体的に細部まで示す」といった表現になっている。フローチャートで階層的なブロックを (例えば点線で囲むなどの方法で) 示すようにすることは可能であるが、やや煩雑な感じになると考えられる。

·        全体として、フローチャートによる表現が (もし適切に構成された論理を表現するのなら) 疑似言語や構造化図式に比べて「分かりにくい」ということはない (「分かりやすさ」に関しては顕著な違いはない)。ただ、フローチャートでは、一層自由な記述ができるから、段階的詳細化における構文のブロックを跨がっ たようなフローを容易に/安易に記述できることが問題である。すなわち、本稿で論じているような「適切な段階的詳細化」を必ずしもスムーズにガイドしない (横道にずれても許容する) ことが、「適当でない」理由であると考える。


2.3  構造化図 式のもう一つの方法: HCPチャート

  なお、構造化図式には、紫合が記述しているPADやSPDの他に、NTTで開発されたHCP (Hierarchical and Compact description chart) があり、注目する価値がある。紫合の図2.10の例題をHCPチャートで記述すると以下 の図2の ように書ける。「段階的詳細化」のプロセスに従って、概要の記述から順次詳細の記述を追加していくことができ、その詳細化の過程が記録として図式に残り、 またそのままプログラム内の注釈としてプログラム中に残ることが特色である。図式の記号そのものは、それぞれの方法に特徴があるが、必ずしも本質の違いで はない。

2.  HCPチャートによる論理表現の例 (紫合 図2.10に対応するもの)

 

2.4  「良い段階的詳細化の条件」と「詳細化 の手戻り」の事例の検討   

  紫合の記述において、「良い段階的詳細化の条 件」として記述している内容は実際のソフトウェア開発に対する指針としては非常に大事なことである。ただ、これらは開発者に対する「指針」として記述され ているだけであり、それをどのようにして実現していくのかの方法があるわけではなく、疑似言語や構造化図式、あるいはそれらを実装したソフトウェアツール で具体的に保証されるわけではない。

  なお、紫合の本節の最後部の記述は検討を要す る。ここで扱っている、「入力→計算処理→出力」という段階分けは、プログラミングにおいては原則的なものである。もし入力データの全体を同時に記憶でき るなら、そして (このプログラムの出力を使う人あるいはソフトウェアが) こ のプログラムの全体の処理の完了を待つことができるなら、何の問題もなく、大抵は最も簡単で、最適の処理法である。しかし、紫合が記述するように、「入力 データの一部を読んでは計算処理と出力までしてしまう」という方式を選択することも多い。それを積極的に要請する理由には次の2つがある。

·        記憶容量の制限のために、 データ全体を同時に記憶することができない。しかし、データ全体を同時に記憶することが必須ではなく、一部のデータだけの読み込みで、その部分に対応する 処理ができる。

·        この処理の出力をより迅速に得たいという要求がある。一部 のデータを読み込んではその処理を行い、できるだけ早くに (部分部分であっても) 出力結果を得たい。(もちろん、このような内部における逐次処理が可能である場合を想定している。)

  このような方式への変更は、紫合の記述のよう に、最初の概要段階でのプログラムの処理の骨子が書き換えになっていることは確かである。しかし、これを、概要段階での検討が不十分であったための一種の 「手戻り」であると考えることは、必ずしも必要でない (あるいは適当でない) と筆者は考える。この処理方式の変更は、確かに、「段階的詳細化」のプロセスに従って考 察する過程で明確になってきたことだと考えるからである。この点は次節でより詳しく検討しよう。

 

3.  TRIZから見たソフトウェア開発の段階的詳細化について   

  TRIZは技術システムの概念的設計および問題 解決における概念的アイデアの生成の段階を主体としているので、本件のような詳細設計に関する方法論についてはあまり大きな寄与をしないように見える。ま た、個別の技術分野に依らないで、技術システム一般における設計の方法を論ずることは一般に簡単でないし、TRIZもそこまでは踏み込んで いない。 このような状況を踏まえた上で、TRIZから見た「ソフトウェア 開発の段階的詳細化」について以下に考察する。

 

3.1  概要の設計から詳細な設計へ

  技術開発の段階として、概要の設計から詳細な設 計に段階的に進むという考え方自体は、ソフトウェア開発に限らず、さまざまな技術分野で共通に見られる戦略であり、指針である。(ただし、ソフトウェア開発にお ける段階的詳細化の方法論は、他の技術分野に比較してもよく発達していると思われる。) この戦略はTRIZでは、つぎのような発明原理で表現されていると考える。

·        発 明原理 1. 「分割」
  A. システムを分離した部分あるいは区分に分割する。
  C. 分割の度合いを増加させる。

·        発明原理 3. 「局所的性質」
  C. システムの各部分を局所的に最適化された状態で機能できるようにする。

  D. システムや物体の各部分が、それぞれ異なる (まったく反対のものでもよい) 有用な機
       能を実行できるようにする。  

  今回まず議論しておきたいことは、段階的詳細化 のための「疑似言語」や「構造化図式」の考え方と基本方針についてである。

 

3.2  「疑似言語」の役割

  「疑似言語」の役割は、自然言語で書かれた概要 記述を、プログラミング言語での詳細記述 (すなわち、プログラム) に変換するために、その中間段階としての記述を行うための手段を提供することである。そ の手段として、一部は自然言語であり、一部はプログラミング言語であるものを導入し、それを標準化・規則化して「疑似言語」としているのである。これは、TRIZの考え方でいうと、つぎ のような原理を適用したと言える。

·        発 明原理 24. 「仲介」
  A.  二つの物質、 システムあるいは作用の間に仲介を導入する。

·        発明原理 10. 「先取り作用」
  A.  物体またはシ ステムに有用な作用を、それが必要になる前に (十分に、あるいは部分
        的 に) 導入する。
  B.  いろいろな物 体またはシステムをあらかじめ配置しておき、最も便利な時と所で動作で
        きる ようにする。

·        発 明原理 16. 「部分的な作用または過剰な作用」
  A.  正確に正しい 量の作用を達成するのが困難な場合は、「少し少ない」または「少し多
        い」 作用を施して、その問題を減少あるいは除去する。

·        発明原理 25. 「セルフサービス」
  A.  物体またはシ ステムが、それ自体で機能を実行したり、自己組織化できるようにする。

·        発明原理 33. 「均質性」
  A.  相互作用する 物体を同じ材料 (または対応する特性を持つ材料) で作る。

  このようなTRIZのさまざまな発明原理を 参照している中で次第に明確になってくることは、(紫合も簡単に述べていることであるが) つぎの点である。

·        「疑似言語」の導入のポイントは、自然言語での記述からプ ログラミング言語での記述への橋渡しをすることであり、一度に (あるいは急速に) 変換した記述をしようとするのでなく、処理の (制御) 構造が明確になった部分から徐々に (段階的に) 記述する (詳細化する) のがよい。

·        この橋渡しのために「疑似言語」は、最終的なプログラミン グ言語に馴染むもの (そのままで/容易に/自動的に当該のプログラミング言語にできるもの) であることが大事である。

·        よって、プログラミングで使用予定のプログラミング言語 (またはそれを簡略化/高度化したもの) (の一部) を、「疑似言語」として導入するのがよい。

·        そこで、使用予定のプログラミング言語が変われば、それに 対応した (少し変化した) 「疑似言語」を用いるのがよい。これは、疑似言語の構文の種類、構文の文法や表記法などを、プログラミング言語に合わせて調整するとよい/するべきことを 意味する。

·        「疑 似言語」は中間的な橋渡し役であるから、使用するプログラミング言語に強く束縛される必要はない。より自由で、より高度であってもよい。(例えば、プログラミング言語に集合論的な表現が直接には備わっていなくても、それを使ってもかまわない。)

  本稿で扱っている「段階的詳細化」について、よ り深い所にある問題は、詳細化の記述において「どのような側面を中心にして分析・記述するのか?」ということである。すなわち、当初の概要レベルでの自然言語による記述に対して、どの ようなことを自然言語のまま記述し、どのようなことをより明確な (形式的な) 言語 (すなわち、疑似言語での標準化部分) で記述していくべきなのかという問題である。

  「疑似言語」においては、「制御構造」を (自然言語でなく) 形式化した言語/言語構文で記述するのだと、紫 合は述べている (また一般に理解されている)。この部分にプログラミング言語の「制御構造文」を導入したものが「疑似言語」であると 理解されている。

  この問題に対してTRIZはあまり適切な示唆を与 えていないが、関連するTRIZの観点は以下のようである。

·        システムの完全性の法則:  システムはその構成要素として、エネルギ源、エンジン、伝達部、ツール (作用部)、作用対象、制御部のすべてが揃っていなければ、適切に機能しない。特に、これらを通してエネルギのフローがあり、また制御の情報が行き渡って いることが必要である。

   TRIZは基本的にハード的な技術分野で成長し てきているので、情報科学固有の処理の内部の記述に関してはほとんど言及していないと言える。また同様に、「疑似言語」の形式と「構造化図式」とを比較し たときの、長所・短所について論ずる観点をTRIZはあまり持っていない。

 

3.3  「段階的 詳細化の手戻りの事例」に対するTRIZの見方:  もう一つの次元での分割

  なお、TRIZは、システムの「分割」 の考え方に関して極めて敏感である。紫合が最後に言及している「段階的詳細化で前段階の決定が覆される例」については、TRIZ的観点からはもっと異な る結論になる。すなわち、この例は「下手な段階的詳細化」の例ではなく、「素直で適切な詳細化」の例であると、TRIZでは解釈できる。この論 理を以下に説明する。

  この例で論じているのは、ある (大規模な) データに対して、コン ピュータで処理をするにあたり、「入力し、処理をし、出力する」という一般的・典型的なプロセスについてである。その概要記述は、まずデータ全体に対する 処理全体を、「3段階の処理プロセス」という形に「分割」したのである。そして次の段階で、(前述のような要請に応じて) 「データをその部分に分割 する」ことが適当 (または必要) であると判断したのである。そしてまた、「データの部分部分に応じて (3段階の) 処理をすることができる」 ことを見出し、「データの部分部分ごとに (3段階の) 処理を完結することが得策である」と判断したのである。これらの判断 (設計) の過程を模式的に示すと、 下図のように表せる。

3.  詳細化において注意すべきケース。処理の分割とデータの分割。

  このように考えると、これは「適切な詳細化」の 例であり、「適切な処理の分割と統合」の例であると言える。この思考過程のベースになったTRIZの考え方は以下のものであると言えるだろう。

·        発明原理 1. 「分割」
  C.  分割の度合い を増加させる。

·        発明原理 17. 「もう一つの次元」
  A.  物体が直線形 状を含むかまたは直線上を移動する場合には、その直線外の次元を利
        用す るまたは直線外の動きを考慮する。

·        発明原理 19. 「周期的作用」
  A.  連続的な作用 を周期的あるいはパルス的な作用で置き替える。

·        発明原理 34. 「排除と再生」
  A.  機能を完了し た物体またはシステムの部分を、無くさせるまたは無くなったように見せ
        る。

  これらの中で特に「もう一つの次元」という観点 が大事である。それまで「処理プロセス」(という時間的な流れの次元) の詳細化に注目していたのを、「データ (の量)」という別の次元に注目して 「分割」あるいは「詳細化」を行ったのである。このようにいろいろな観点から考えることが、TRIZの考え方で重要視されていることである。

  なお、この例のような設計をする目的/メリットをTRIZの観点から説明すると、 以下のようであろう。

·        リ ソースの活用:  最少限の資源で目的の機能を実現す る。

·        発明原理 5. 「併合」
  A.  複数の物体、 操作あるいは機能を、時間的に一緒に動作するよう、連結あるいは併合
        す る。
    [これは、出力を他の処理の入力にして、「パイプライ ン」的に使う場合を想定している。]


  なお、この例のように、「段階的詳細化」が一見 後戻りをしているように見える状況で、いままでのソフトウェア工学 (あるいは情報科学) では必ずしも適切に説明されていなかったことを、(TRIZなどでの別の見方を導 入して) 新しい観点からきちんと説明することは大事なことである。

 

3.4  段階的詳細化のための指針について

  「段階的詳細化」のための指針、特に紫合の図2.12は、よくまとまってお り、重要である。ここには情報科学が蓄積してきた多くの考え方が濃縮されている。この紫合の図2.12について、TRIZの観点から検討しておこう。これらの指針を再掲する。

(a)  各命令記述ごとに独立に詳細化できること。
(b)  それぞれの段階で詳細を見ずに理解できること。
(c)  不必要な詳細まで表現されていないこと。
(d)  それぞれの段階 で記述の詳細さのレベルが統一されていること。

  まず、議論の前提として理解しておくべきこと は、ここでソフトウェア開発のために記述しようとしている対象が、何らかの「処理プロセス」であり、それは記述 (開発) を進めていくと最終的に、 プログラムあるいはソフトウェアとして実体化されるものだということである。一方、ハード分野の技術を対象として考察してきたTRIZの観点から考えると、こ こでの記述対象に対応するものは「なんらかの機能を持つ技術システム」であり、TRIZでそれを「記述」することに対応するのは、対象の技術システムを「理解」、「分析」、あ るいは「設計」することであるといえる。このような対応でいうと、ソフトウェアシステムを「段階的に詳細化する」ことをTRIZで考えると、(ハード的な) 技術システムを「階層的に 理解・分析する」こと、また「段階的に詳細に設計する」ことである。

  上記の紫合の指針をまとめて考えると、第一に 言っているのは、「任意の段階の記述において、その段階の記述だけを見て (より詳細の段階を見ずに) 理解でき、不必要な詳細が記述されていず、その記述の詳細さがある統一されたレベルにあ ること」である。これに関連したTRIZでの指針にはつぎのものがある。

·        シ ステムの完全性の法則  (前述)

·        発明原理 1. 「分割」
  B.  組み立てと分 解が容易になるようにシステムを作る。

これは要するに一 つの「システム」の捉え方 (あるレベルでのシステムの捉え方) である。この他に考えられるのは、TRIZの観点からシステムを分 析するときの指針であり、それはTRIZでの原理ではなくTRIZの使い方の問題になってしまう。その意味でTRIZ自身が提供している原理/観点ではない。

  紫合がいう指針の第二は、「ある段階から、つぎ の段階に詳細化するに際して、その記述レベルを統一的に詳しくすることができ、また、もとの記述の各要素ごとに独立して (相互依存/相互干渉せずに) 詳細化できること」であ る。これに関連するTRIZの指針にはつぎのものがある。

·        システムの階層の理解

·        発明原理 7. 「入れ子」
  A.  一つの物体あ るいはシステムを別のものの内部に入れる。
  B.  複数の物体あ るいはシステムを他のものの内部に置く。

·        発明原理 3. 「局所的性質」
  D.  システムや物 体の各部分が、それぞれ異なる有用な機能を実行できるようにする。

·        発 明原理15. 「ダイナミックス」
  B.  一つの物体あ るいはシステムを分割して、相互に相対的に運動可能にする。


   ただしここで注意を要するのは、上記の第二の指 針 (あるいは紫合の指針の(a)) において、「各要素 ごとに独立して詳細化できる」という項目である。この項目は、システムの階層的な構造でいえば、「完全な入れ子構造」になっているという条件である。これ は、本研究シリーズ(1) でも問題になった点であり、大抵の場合には正しい指針であるが、ときどき例外があり、こ の指針を破っているがよりよいケースが存在することである。その例は、本節ですでに論じた図3のケースである。どのような場合に「完全な入れ子構造」に対する例外が適切になるのか は、今後もっと事例を集めて検証しなければならない。ただ、図3のケースが示唆しているのは、上位階層で使った分割の観点とは異なる次元で下位階層での 分割が行われ、その結果をまとめて表現する際に上位階層のものとは異なるグループ分けが適切であると判断される場合である。この点の解明はさらに今後の課 題 として持ち越す。

 

4.  段階的詳細化に関連して、情報科学がTRIZに示唆す ること

  本節では前節と立場を逆転させて、ソフトウェア 工学/情 報科学の観点から見たときに、TRIZに対して示唆できること、TRIZを改良するとよいことについて考えよう。ここでの考え方は主として、3.4 節で述べた「ソフト ウェアの記述」と「技術システムの分析/設計」との対応関係をベースにしている。

4.1  段階的詳 細化の概念と指針のTRIZへの導入

  第一に、ソフトウェアの記述における「段階的詳 細化」の概念と指針とを、TRIZ (あるいはハード面の技術分野) での「技術システムの分析」および「技術システムの設計」のた めの考え方と指針として導入するとよい、ということである。このことが意味する内容は多岐に渡るが、例えばつぎのような事項がある。

  ある一つのレベルで「技術システム」を (分析あるいは設計を目的とし て) 「記 述する」場合に、つぎのような指針を明確にする。

·        システムの構成要素の選択 (捉え方) を適切な詳細化のレベルで一貫させる。

·        その詳細化のレベルの記述によって、記述されたシステムの 機能や働きを (そのレベルで) 理解できるようにする。

·        不必要な詳細を記述しない。

·        そのレベルにおいてシステムを理解するのに必要な構成要素 が記述されている。

「技術システム」を階層的に (その階層ごとに) 記述し、複数の階層の記述 によって段階的に詳細化して、分析・理解・設計などができるようにする。

·        シ ステムの階層性を意識して、階層的に、階層ごとに適格に記述する。

·        シ ステムの一部 (特にシステムの構成要素/下位システム) を下位の詳細の階層として、記述する。(その下位システムの記述に関しても、上記の記述の指針を守る。)

·        システムの記述を次々に下位のレベルで記述することによ り、システムの分析およひシステムの設計を実施する。

  なお、これらの概念および指針がTRIZ (あるいはハード面の 技術分野) に存在しないわけではない。しかし、情報科学の方がより明確で、より論理的に概念と指針 を示しており、参考にするべき点は多いと考える。

  この点に関しては、例えば、TRIZ自身の方法論の記述において、論理の階層性がよく保たれていない場合があることには気をつけておかなければならない。 特に、「40の発明原理」に階層的な統一性がないことは多くの初心者たちが感じることである。なお、この点に関しては、TRIZのさまざまな解決策生成法 を整理しなおしてUSITの解決策生成法の体系を作ったときに、注意して構成しなおしたつもりである。

 

4.2  処理の制 御構造の概念のTRIZへの導入

  第二に、「処理の制御構造」という概念、特に疑 似言語における「制御構造文」の概念を、TRIZ (およびハード面での技術分野) に取り入れるとよい。ただし、このことが実際に何を意味するの かは、まだ必ずしも明確でない。つぎのような点が考えられる。

·        システムの機能の表現において、何らかの標準的な構造を導 入する。
  例えば、(TRIZ方法論の中の一つの技法である) USITでは、機能分析の図の表現に明確
    なルール/指針を導入している。

·        システムの処理実行の記述において、何らかの標準的な記述 の方法/構造を導入する。

  これらの点で考 察すべき課題は多いと思われるが、まだ抽象的で茫漠としており、今後の検討課題として残す。

 

参考文献:

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

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

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

 

本ページの先頭

1. 段階的詳細化とは

2. 補足説明

3. TRIZから見る

4. TRIZへのフィードバック

参考文献

シリーズ(1) 構造化プログラミング

 

 

総合目次 

新着情報

TRIZ紹介

参 考文献・関連文献

リンク集

ニュー ス・活動

ソ フトツール

論 文・技術報告集

教材・講義ノート

フォー ラム

Generla Index 

ホー ムページ

新 着情報

TRIZ 紹介

参 考文献・関連文献

リ ンク集

ニュー ス・活動

ソ フトツール

論文・技 術報告集

教材・講義 ノート

フォー ラム

Home Page

最終更新日 : 2005. 2. 7.     連絡先: 中川 徹  nakagawa@utc.osaka-gu.ac.jp