JP2007265418A - 自動詳細化システム - Google Patents

Abstract

【課題】意図達成又は設計の知識を自動生成する方法、システム及びプログラムの実現。
【解決手段】動詞を含む子概念のスケルトン及び該スケルトンに作用する処理論理から構成される単位情報群を、親概念のデータフロー図に含まれる動詞、及び、親概念を特定するための入力、出力、前状態、後状態、先行する親概念等の情報を索引として検索し、検索された単位情報に含まれるスケルトンに、検索された処理論理と索引として用いた情報とを適用して子概念のデータフロー図を生成することにより、親概念のデータフロー図を子概念のデータフロー図に階層展開することを特徴とする。また、データフロー図用ＣＡＳＥツールとフローチャート又は構造化チャート用ＣＡＳＥツール部を有するＣＡＳＥツール群と、設計知識を自動生成する自動生成エンジンと知識ベース部を有するエンジン群との間で相互に情報の送受信を行う手段を有し、自動設計を行うことを特徴とする。
【選択図】図１３

Description

本発明は、人の意図的行動、システムあるいはプログラムの自動設計の為の知識の自動生成方式およびそのための自動設計システムに関し、更にはこれらに用いられる知識の自動生成プログラム、該プログラムを記録した記録媒体に関するものである。

自動設計は色々な分野で行われている。現在では、最も遅れているソフトウエアの分野でも設計過程の作業を自動化することが行なわれ始め、自動設計には設計過程の知識を使えば良いことが一般的理解を得るようになった。この為には、システムあるいはプログラムの設計知識（以下単に設計知識という）の系統的な獲得とエキスパートシステムの系統的な構築が必要であり、この技術も確立されてきている。更に既存設計から設計知識を自動的に獲得し、再利用して自動設計する技術も確立された。なお、設計知識自動獲得方式およびそれを用いた自動設計システムとしては、特開平１０−３２０１８８号公報において知られている。後に定量評価で示すように、この方式は繰り返しの多い保守設計領域で大変有効である。但し、ここでは単純な再利用に留まるから、第１の欠点として適用できる設計知識に複数の候補が存在する時には、人が候補を調べて選択する必要があり、更に、零から作り出すと云う意味で、自動的に設計知識を生成する事ができないことが第２の欠点であった。また、ソフトウエア技術の進展に伴い、経営問題などの上流のソフトウエア設計やその自動化の技術が問題とされるに至っている。

特開平１０−３２０１８８号公報

従って、本発明の基本的な課題は、設計知識の基本的な構造を明らかにして、高い度合いで自動設計できる優れた設計者のエキスパートシステムを構築すること、すなわち、少数の基礎知識から設計知識を自動生成する技術、自動生成された設計知識を利用した後、あるいは既設計図面からの設計知識を獲得し、蓄積して効率的な自動設計を行わせる技術を明らかにし、さらにシステムの上流更にその上においても可能にすることである。

本発明の第１の目的は、設計知識を自動的に生成することができるようにした設計知識の自動生成方法およびそのプログラム並びにそのシステムを提供することにある。
また、本発明の第２の目的は、設計知識を自動的に生成し、高い自動化率で動作する自動設計を実現できる方式を提供することにある。

また、本発明の第３の目的は、自動生成された設計知識、あるいは既設計図面から獲得した設計知識とを蓄積しておき、必要な設計の展開方向を判断して、既に蓄積された設計知識の中から最適な設計知識を自動決定することにより、高い効率で自動設計できる方式を提供することにある。
また、本発明の第４の目的は、上記した設計知識の自動生成と蓄積した設計知識の再利用を、使用者との効果的なインタフェイスである図面の作図と表示とを効果的に統合制御する手段を提供することにある。
また、本発明の第５の目的は、上記各項をプログラムのレベルから経営トップの意思決定過程まで、一貫した方式とすることである。
また、本発明の第６の目的は、設計の省力化と生産性の向上および生産性の向上手段を提供することにある。

本発明においては、目的あるいはこれを具体化した機能を概念展開して実現手段を定めることを中心とする人の全ての意図を達成する行動を設計またその達成するための知識を設計知識と定義する。

上記目的を達成するために、本発明は、親概念と子概念（群）の対を単位的な知識として用いて意図達成又は設計の知識を自動生成する方法およびそのプログラムであって、前記親概念から展開された子概念（群）の動詞を中心とするスケルトンおよび該スケルトンに作用する処理論理から構成される単位情報群を得るステップと、該ステップで得た結果から意図的行動又は親概念を詳細化した子概念である知識を得るステップとを有することを特徴とする。

また、本発明は、親概念と子概念（群）の対を単位的な知識として用いて意図達成又は設計の知識を自動生成する方法およびそのプログラムであって、前記親概念から展開される子概念（群）である意図達成又は設計の知識から、前記親概念を構成する入力（以降において前状態も含むものとする）、出力（以降において後状態も含むものとする）および先行する親概念（群）等の情報により親概念の動詞についての意味を特定する論理に基いて適切な選択をするステップを有することを特徴とする。

また、本発明は、親概念と子概念（群）の対を単位的な知識として用いて意図達成又は設計の知識を自動生成する方法およびそのプログラムであって、子概念（群）の動詞を中心とするスケルトンおよび該スケルトンに作用する処理論理から構成される単位情報群を、親概念を構成する機能の動詞部分で索引する索引ステップと、親概念を構成する入力データ、出力データおよび先行する親概念（群）等の情報により親概念の動詞についての意味を特定する論理に基いて、前記索引ステップで索引された単位情報群から適切な単位情報を選択する選択ステップとを有することを特徴とする設計知識の自動生成方法およびそのプログラムである。

また、本発明は、親概念と子概念（群）の対を単位的な知識として用いて意図達成又は設計の知識を自動生成する方法であって、入力される親概念とした単位的なデータフロー図を基に、親概念中のデータを階層展開して子概念であるデータフロー図のスケルトンを形成するステップと、前記親概念中の動詞又は前記親概念から展開した子概念の動詞を継承して子概念であるデータフロー図を形成するステップとを有し、親概念から階層展開された子概念としてのデータフロー図からなる意図達成又は設計の知識を得ることを特徴とする。

また、本発明は、親概念と子概念（群）の対を単位的な知識として用いて意図達成又は設計の知識を自動生成する方法およびプログラムであって、入力される親概念とした単位的なデータフロー図を基に、親概念であるデータフロー図あるいは機能に対応する単位的な階層展開関係にあるデータフロー図のスケルトンに対して、該スケルトンに作用する処理論理あるいはこれと協調動作する専用論理によって少なくとも入力データあるいは出力データを挿入することにより階層展開される子概念のデータフロー図を形成するステップを有し、親概念から階層展開された子概念としてのデータフロー図からなる設計知識を得ることを特徴とする。

また、本発明は、親概念と子概念（群）の対を単位的な知識として用いて意図達成又は設計の知識を自動生成する方法およびプログラムであって、入力される親概念とした単位的なデータフロー図を基に、親概念であるデータフロー図又は機能に対応する階層展開関係にある少なくともデータフロー図のスケルトンを得るステップと、該ステップで得られたデータフロー図のスケルトンに対して該スケルトンに作用する処理論理、又はこれと協調動作する専用論理、又は別に設けた専用論理によって少なくとも入力データまたは出力データを挿入することにより少なくとも子概念のデータフロー図を形成するステップとを有し、親概念から階層展開された子概念としてのデータフロー図からなる意図達成又は設計の知識を得ることを特徴とする。

また、本発明は、親概念と子概念（群）の対を単位的な知識として用いて意図達成又は設計の知識を自動生成する方法およびプログラムであって、入力される親概念とした単位的なデータフロー図を基に、親概念であるデータフロー図あるいは機能に対応する複数の単位的な階層展開関係のスケルトンから適切な単位的な階層展開関係のスケルトンを選択するステップと、前記親概念とした単位的なデータフロー図を基に、前記ステップで選択された適当な単位的な階層展開関係のスケルトンに対して該スケルトンに作用する処理論理あるいはこれと協調動作する専用論理によって少なくとも入力データまたは出力データを挿入することにより階層展開された子概念のデータフロー図を形成して出力するステップとを有し、親概念から階層展開された子概念としてのデータフロー図からなる知識を得ることを特徴とする。

また、本発明は、データフロー図とフローチャートあるいは構造化チャートを使う。データフロー図では、単位的設計情報は入力データ、その入力データの変換機構である機能、および出力データであって、各々がデータフロー図の基本構造であり、例えば種別毎の図形記号とそれに伴う記述とからなる。データフロー図は、全体としてある機能の実現のアルゴリズムを表すが、図中の機能の実行順序は示さない。フローチャートや構造化チャートでは、この単位的設計情報は機能であって、各々がフローチャートや構造化チャートの基本構造であり、例えば種別毎の図形記号とそれに伴う記述とからなる。フローチャートや構造化チャートは、機能の実行の順序は示すが、アルゴリズムは必ずしも読取れない（分からない）。

また、本発明は、データフロー図およびこれに対応するフローチャートあるいは構造化チャートがあり、両図面上の対応する機能には各々始点が設定され、両始点を同期的に各図面上を移動させて自動設計する自動設計方法であって、前記始点の機能と入力データおよび出力データからなる親概念であるデータフロー図をエンジン部に照会するステップと、該ステップで照会されたエンジン部において、前記の設計知識の自動生成方法により生成された設計知識から、親概念から階層展開される子概念としてのデータフロー図およびフローチャートあるいは構造化チャートを得て、前記親概念の機能について、データフロー図では子データフロー図を貼付し、フローチャートあるいは構造化チャートでは子フローチャートあるいは子構造化チャートを貼付することにより前記親についての設計を終え、次の親に始点を移動するステップとを有し、前記サイクルを繰返すことによってデータフロー図および対応するフローチャートあるいは構造化チャートの設計を行なうことを特徴とする自動設計方法である。

また、本発明は、親概念と子概念（群）の対を、意図達成又は設計の単位的知識として自動生成するシステムであって、前記意図達成又は設計の単位的知識を蓄積する知識ベース部と、前記親概念から得た子概念（群）の動詞を中心とするスケルトンおよび該スケルトンに作用する処理論理から構成される単位情報群から、前記親概念を構成する入力データ若しくは前状態、出力データ若しくは後状態および先行する親概念（群）等の情報により親概念の動詞についての意味を特定する論理および前記親概念を構成する機能の動詞部分に基いて、適切な単位情報を選択する選択部を備えて意図達成又は設計の単位的知識を自動生成する自動生成部と、前記自動生成部および前記知識ベース部を切替えて、使用する意図達成又は設計の単位的知識を選択する選択手段とを備えたことを特徴とする。ここで、知識ベース部には、作業に用いられる全ての設計ルールが与えられ、記憶される。

また、本発明は、前記意図達成又は設計の単位的知識を蓄積する知識ベース部と、前記親概念から得た子概念（群）の動詞を中心とするスケルトンおよび該スケルトンに作用する処理論理から構成される単位情報群を、前記親概念を構成する機能の動詞部分で索引する索引部、および親概念を構成する入力若しくは前状態、出力若しくは後状態および先行する親概念（群）等の情報により親概念の動詞についての意味を特定する論理に基いて、前記索引部で索引された単位情報群から適切な単位情報を選択する選択部を備えて意図達成又は設計の単位的知識を自動生成する自動生成部と、前記自動生成部および前記知識ベース部を切替えて、使用する意図達成又は設計の単位的知識を選択する選択手段とを備えたことを特徴とする知識の自動生成システムである。

また、本発明は、親概念と子概念（群）の対を、単位的な知識として蓄積する知識ベース部と、前記親概念から展開された子概念（群）の動詞を中心とするスケルトンおよび該スケルトンに作用する処理論理から構成される単位情報群を蓄積するルールベースと、該ルールベースに蓄積された単位情報群から、前記親概念を構成する入力若しくは前状態、出力若しくは後状態および先行する親概念（群）等の情報により親概念の動詞についての意味を特定して選択して意図達成又は設計の知識を自動生成する自動生成部とを備え、該自動生成部は、更に、作業に用いられる度に、前記知識ベース部に蓄積された知識の中で動詞を同じくする既出の知識（群）と比較・照合され、重複部分はスケルトンを抽出し、同一意味に共通なパターンは処理論理として抽出し、それらの抽出結果を前記ルールベースに蓄積することを特徴とする知識の自動生成システムである。

また、本発明は、用語、データ、構成に関する基礎知識辞書および該辞書を正あるいは逆に索引して関係付けをする単位機能論理と、前記親概念から展開された子概念（群）の動詞を中心とするスケルトンおよび該スケルトンに作用する処理論理から構成される単位情報群を蓄積するルールベースと、該ルールベースから読出された単位情報群と専用論理と前記単位機能論理が協調動作して意図達成又は設計の知識を自動生成する自動生成部とを備えたことを特徴とする知識の自動生成システムである。
また、本発明は、更に、前記単位機能論理には、作業に用いられる知識から動詞を抽出する論理部分があって、その出力を前記基礎知識辞書に蓄積することを特徴とする。

また、本発明は、データフロー図用ＣＡＳＥツール部およびフローチャートあるいは構造化チャート用ＣＡＳＥツール部を有するＣＡＳＥツール群と、少なくとも設計知識を自動生成する自動生成エンジン部、および該自動生成エンジン部で自動生成された設計知識を蓄積する知識ベース部を有するエンジン群と、前記ＣＡＳＥツール群と前記エンジン群との間で相互に情報の送受信を行う手段とを備えたことを特徴とする自動設計システムである。

また、本発明は、前記ＣＡＳＥツール群と、前記エンジン部とを備え、前記両種のＣＡＳＥツールには、設計知識毎の自動設計および知識抽出を行うために親を識別する識別手段を備え、更に、両種のＣＡＳＥツールの出力の合致を親についての動作の度に照合確認する論理手段を備えたことを特徴とする自動設計システムである。
また、本発明は、前記ＣＡＳＥツール群と、前記エンジン部とを備え、前記両種のＣＡＳＥツールには、作業対象となる機能を識別する識別手段を備え、親について動作の度に、データフロー図を先行して設計することによって得られる親についての子データフロー図を変換してフローチャートあるいは構造化チャート上に作画させる機能、および、フローチャートあるいは構造化チャートを先行して分岐あるいは繰返しを設計する場合にはデータフロー図側の追随を禁止する機能を備えたことを特徴とする自動設計システムである。

また、本発明は、親概念と子概念（群）の対を設計知識として設計に用いる方法において、親概念である図形記号による単位設計情報の図形から出発して前記親概念である図形記号につながる親概念である図形記号群をなぞり親概念を得て、エンジンに送出するステップと、第１のエンジンは親概念の中心概念の意味を抽出する論理に基づき索引された知識ベースの該当部分を自動的に決定する選択ステップの出力を有し、第２のエンジンは前記設計知識の自動生成ユニットの出力を有し、前記第１のエンジンの出力あるいは前記第２のエンジンの出力を選択して出力するステップと、前記エンジンから送られた階層展開される子概念である図形記号群を親概念である図形記号群の下位に接続して図面を作成するステップとを有することを特徴とする自動設計方式である。

また、本発明は、親の概念と、これを階層展開した子の概念（群）の対を単位的な設計知識とする。すなわち、データフロー図の場合では、入力であるデータ、機能および出力であるデータとからなりたつ単位的データフロー図が親の概念に、子の概念は、親の入力であるデータあるいはその構成の一部を入力データ、親の出力であるデータあるいはその構成の一部を出力データとし、親の機能概念を階層展開した子の機能〔群〕とからなるデータフロー図（群）である。そこで、最も具体的で正確な親の概念は、親単位データフロー図であり、子の概念は、子データフロー図（群）とその中の機能の実行順序を記したフローチャートあるいは構造化チャートであり、この対が設計知識である。但し、データフロー図のみの場合は親概念の単位的データフロー図と子概念（群）のデータフロー図（群）である。また、フローチャートあるいは構造化チャートのみの場合は、親機能と子機能のフローチャートあるいは構造化チャートである。

また、本発明における設計図面は、親に相当する最も抽象的な単位的設計情報から枝が出て、子に相当する、より具体化された単位的設計情報群につながり、その子の各々は自分の子につながることを繰返す構造的な設計図面である。この設計図面の上で階層展開の親である図形記号による単位設計情報の図形から出発して一筆書きの経路により、親である図形記号（群）を順次なぞる全体的動作の機能がある。更に、全体的動作で親を順次なぞりながら、親である図形記号（群）につながる、子である図形記号（群）をなぞり、出発点に戻る第１の局部的動作機能があり、得た情報を処理して設計知識を自動獲得する。更に、親概念を指定して親概念と子概念の対である設計知識を与えられて、設計図面上の親に接続して、子概念を図形記号（群）に展開する形で貼付ける第２の局部的動作機能があり、自動的に設計（展開動作）する。

また、本発明は、ある図形を全体的動作でなぞりながら、なぞる相手の図形から親の単位的設計情報を取出し、そこで局部的動作により子の単位的設計情報を取出し、これらの単位的設計情報群から親と子の階層関係の設計知識を再現して、設計知識を得る為のエンジン群中の知識ベースに蓄えることにより設計知識を自動的に獲得できるようにしてある。
また、本発明は、ある図形を全体的動作でなぞりながら、なぞる相手の図形から親の単位的設計情報を取出し、この単位的設計情報群から親の情報を取出して、設計知識を得る為のエンジン群に送る。エンジンは、知識ベースからの検索結果あるいは各種の自動生成部からの、この親と子の階層関係の設計知識を送出する。この子の図面をなぞりながら、設計図面上のこの親の下位に子である図形記号（群）を貼付けることにより、設計知識による図面の自動展開、すなわち自動設計ができるようにしてある。

また、本発明に係る基本的な自動設計について説明する。データフロー図上で知識抽出を開始する親概念の機能に始点を設定し、フローチャートあるいは構造化チャートも対応する機能に始点を設定する。以後両ＣＡＳＥツールは同期して動作する。始点は図面についての全体的動作を行うにつれ順次次ぎの機能に移動し、局部的動作を行う。局部動作の度に、まず親が統合部に送出され、（親の合致を確認して）知識ベースとCreator CASEツールに伝達される。エンジン（知識ベースとCreator CASEツール）から設計知識が送出されると、統合部はこれをCASEツール群に伝え、各CASEツールは、自分に対する設計知識を受けて、１サイクルの局部動作を完結させ、全体的動作は始点を次ぎに移動させ、次のサイクルに入る。これを繰返して最後の最も詳細化されたレベルまで、作図を行なう。

本発明の設計知識の自動生成部の構成を順に説明する。Creator CASEツール（や知識ベース等のエンジン）の入力には、親概念が各順次蓄積する機構が設けられ、ある程度の過去の状態が遡れる機構が付いている。入力は更に親概念の入出力データと機能中の中心的な動詞を抽出する論理を経て、前者はファンクションデコーダにつながり一連の開始動作を制御し、後者はCreator’00プログラム中の動詞辞書の検索につながれる。一般にある動詞には、幾つかの意味があるので、検索結果は単数または複数のページが対応する。ファンクションデコーダは、親概念の入出力データおよび過去の親群を用い、ＤＤＦＴを参照して検索された動詞辞書の確からしさの高い意味に対応するページを選択する論理がある。

動詞辞書は、フレーム形知識に倣ったもので、フレーム形知識のデータに対応してデータフロー図とフローチャートあるいは構造化チャート表記の子概念のスケルトンが、またメソッドには、このスケルトンを用いて子概念を形成する処理論理が記述されている。最も簡単な論理の例は、「○○を△△に、××する」と云った子概念の構造的な機能表記の模範形を作る為に、親概念の入出力データをスケルトンに組合せることであり、その結果として子概念であるデータフロー図が形成される。

ある親情報の入力データと出力データが共に階層的な構造である時、ジャクソンプログラム設計法が適している。ファンクションデコーダは、構造辞書CASEツール経由で登録された構造辞書を参照して入力側と出力側のデータを展開する専用論理がある。ＪＳＰユニットは、ジャクソンプログラム法に従って入力側と出力側の対応する対を形成し、親概念の動詞あるいは動詞辞書のスケルトンから中心的な動詞を継承し、対応する入力データ、子機能、出力データの単数または複数の子データフローを形成する論理を持っている。
データフロー図から子概念であるフローチャートあるいは構造化チャートに変換する論理部分を設けて共通に使用する、あるいは、データフロー図の場合と同様にスケルトンから子概念を形成する論理をメッソッドとして設けてフローチャートあるいは構造化チャートの子概念を形成する。

本発明に係る実施の形態について図面を用いて説明する。
初めに人の設計の定義について説明する。
人の創造あるいは設計については、各種の考え方がある。用語の定義として、本発明では設計とは人の意図的な行動と広く捕えることとする。工学的な取扱の為には、最も系統的であり、更に具体的な把握が可能なことが必要である。この観点から、人の個々の思考結果である概念に着目する。この時に、人の創造ないし設計の過程は、人の概念の階層的な展開の連鎖で定義できる。展開を繰返す度に目的は、より明確に、より具体的に、より詳細に、なって行く。

すなわち、最も始原的なものは、意図された効果や効用であり、これを目的として階層展開してそれの実現手段（群）である細分化されたより明確な効果や機能に至る。現在では、企業における情報システムへの投資は巨大なもので、この節減の為に、企業を合併することすらあることはよく知られている。同時にこれらのシステムの提案を行い、具体的なシステムへの展開を図るエンジニアのレベル、ＳＥでは、企業の最高運営方針のレベルを問題とするに至っていることは以外に知られていない。

このレベルでは軍事科学での「目的の階層的な展開」が最もよく説明できる。これは組織の長が戦略的な最終目的を設定する。組織の長はこの目的を実現する手段（群）に階層展開し、夫々の組織の長の命令を与える。例えば、私企業であれば「利益を増大させる」が最終目的の一例である。これには、売上増加、新製品、開発原価低減、在庫圧縮などの各方法がある。今、戦略として在庫圧縮を選択すると、この実現手段は、
資材購入部門には、「発注の精選と購入総額の圧縮」
営業部門には、流通「在庫の値下げ販売などの在庫の吐出し」、
生産部門には、「見通しある注文のみへの対応と在庫管理の強化」である。これは、
親概念「利益を増大させる」が
子概念群「発注の精選と購入総額の圧縮」、「在庫の値下げ販売などの在庫の吐出し」、「在庫管理の強化」に展開されることになる。これは目的の階層性に従った階層展開といえよう。

私企業の情報部門トップに与えられる期待は、今トップは何をすべきかが如実に示されるシステムであり、これらの経営知識と実務がＳＥの必須知識であり、作業中心になっている。生産部門でも同じことが起こる。「在庫管理の強化」は、「その為に何をすれば良いのか？」を議論すれば、「長期滞留物品のリストアップ」、「在庫金額の全体合計」、「滞留期間毎の金額推移、製品種別毎の金額」などが決まる。これは与えられた命題を目的の階層性に従い展開することであり、親とする子概念の展開でもある。システム設計の上位では、ソフトウエアで何をすべきかと云う具体的な展開ではなくて、このような目的の展開が中心になる。そこで、ソフトウエア工学ではこの親子の展開で構成される展開網を目的樹と呼んでいる。現在では、このような事務作業の過程もビジネスプロセスとしてＳＥ作業する所である。現在のソフトウエア産業の開発では、このようなＳＥ作業に従事する人数の方が具体的なプログラム作りをする人の数より多い時代になっている。後続部分で具体的なプログラム作りが階層展開の連鎖であることを説明するが、その前段階で既に階層展開の連鎖を構成する作業が存在し、しかも、それは現在では大きな比率を占めているのである。

即ち、最も原始的なものは、意図された効果や効用であり、これを目的として階層展開してそれの実現手段（群）に展開することを繰り返す。その上位では行動やサービスの場合があり、これを展開すると単位的な行動や外部的な機能に至る。これらは更に展開されてある細分化されたより明確な効果や機能に至る。更にこれらの各々のひとつ毎を目的として階層展開して、より具体的な（例えば、入力から出力への情報変換を指すソフトウエア的な）機能（群）やその構成を得る。この階層展開は、対象が具体的な設計作業に展開できるレベルに至るまで、繰返される。

設計対象程度に具体化された機能を、更に階層展開してこれらを実現する（例えばソフトウエア的な）機能（群）とその構成を得る。この機能について、更に階層的な機能展開を繰返す。機能について階層的な展開を繰返すにつれ、各機能は明確化し、具体化し、詳細化し、例えばソースコードレベルに達する。そこで、本発明では他とは異なるが、トップレベルの経営判断から始まり、ソースコード化で終わる最終段階までの全過程は人の概念展開として統一的に扱う。これらは端的に表現すれば「人の意図達成の行動」といい得る。

次に、具体的な例で説明する。第１図は、Joint Conference on Knowledge-Based Software Engineering,JCKBSE’９６（１９９６年9月）の193頁ないし197頁に発表した論文’Expert’s Knowledge Structure explains software engineering’の図１を日本語に改めたもので、各図面は時計プログラムの設計過程の各図面を示したものである。左はデータフロー図群、中央はフローチャートの一部、右端はソースコードのリストの一部を示す。
ここではデータは上下が半円形である長方形で、機能は長方形で示してある。データ、機能、データと処理の流れの順番に並べて、矢印で流れを示す図をデータフロー図と呼ぶ。フローチャートは、機能（処理）を実行の順に縦に上から下に並べ、各機能間を線分で結んだ図である。

第１図のデータフロー図において、最初の機能は「時計」であり、これを階層展開すると「時刻をえる」「時刻表示を求める」「表示する」になり、より明確になっている。第２番目の機能「時刻表示を求める」は、更に階層展開すると、「時針を求める」「分針を求める」「秒針を求める」に具体化されている。この第２番目の機能「分針を求める」は、更に階層展開すると、「分針の角度を求める」「分針の幅を求める」「分針の長さを求める」に詳細化されている。また、中央のフローチャートの下には、機能「分針を求める」のフローチャートが示されている。ここでデータフロー図の各機能と対応するフローチャートの各機能は、同じである。これは、設計の進行を小さな段階毎にすることにより、容易に実現できる。
この繰返しを行ううちに、実現手段（例えばソフトウエアにおいては、データについての演算など）に近づいた時に、概念の階層展開は、最終実現手段（群）での操作や構成（通常のソフトウエアでは計算機言語での処理の宣言）に置換する。これを繰返すことにより、当初の意図である効用、効果、機能を実現する階層的な手段群（例えばソフトウエアではプログラム）に至る。この設計の定義は、ソフトウエアに限らず、人の意図的な行動を実現に移す全てに通じる定義である。

先に説明した、第１図左のデータフロー図の最下段、および、第１図中央の下のフローチャートで、例えば「分針の角度を求める」は、「６０進制の時刻を６倍すれば、３６０進制の角度が得られる」ことが直ちに判る。そこで、第１図の右端のソースコードは、計算機言語で「｛分針の角度｝は｛時刻の分の値｝×６」を表記している。このようなソースコードの群を、階層展開したのとは反対に積上げて行けば、全体のプログラムが構成できる。
ここで当初の機能概念の階層展開の場合と異なることは、「機能の概念」が「対応する情報の演算処理」に変わることであり、これを「実現する階層的な手段」と説明した。

これとは異なる表記法もある。すなわち、「分針の角度を求める」を「｛分針の角度｝は｛時刻の分の値｝×６である」とデータフロー図やフローチャートに表記して、フローチャートからソースコードへの変化は、自然言語表記から計算機言語表記にする方法もある。ここで、通常のようなプログラム中心の視点でなく、自然言語を中心にするのは、全ての人の意図的な行動を捕えることを意図するからである。
このように、機能を表記する時に、機能を「○○を△△する」と表記する模範的な自然言語表記でなくて、数学的に「○○は△と□である」とか「○○＝△と□」のような表記をする場合もあり、簡単な場合によく用いられる。例えば、「四角形の面積（Ｓ）は底辺の長さ（Ｌ）×高さ（Ｈ）である」という自然言語での表記もあれば、更に数学的に、「Ｓ＝Ｌ×Ｈ」、あるいは「Ｓ←Ｌ×Ｈ」のように表記する場合もある。これらの場合には、「Ｓである」と置き直すことにより、全く等価な取扱ができる。ここでは、これら全てを「△△する」といった動詞形に統一して説明する。

本発明は、設計図面を対象にし、設計は小さな進行段階毎に設計図面を残させることにより、設計作業は、ある単位的設計情報を設計入力とし、これを階層展開した単位的設計情報（群）が設計出力であるようにする。すなわち、知識の立場からは、設計入力は親の概念に、設計出力は子の概念にあたり、設計の知識とは親から子への概念の階層展開であるようにする。
ソフトウエアの設計では、言語と組合せて図面を使い、（一般文書の効用を果たさせる他）言語と共に、関係、構成や構造を、人によく理解させ、記憶させる。最も普及しているのは、流れ図（フローチャート）、構造化チャートおよびデータフロー図である。これまで簡単な説明で、これらを説明に使ったが、以下にこれらをより詳細に説明する。

データフロー図は、第２図のごとく、（入力側）データ、機能、データ、機能、…〔出力側〕データの順に（通常水平方向に）並べ、相互に流れ線で接続したものである。但し、データの記号としては、第１図以外はＪＩＳ規格に従い、菱形に上辺をずらせた長方形記号で表す。データフロー図は、プログラムの実現するアルゴリズムを最も明解に表す。データフロー図の図形記号の中には、データ名称や機能を示す記述が記入される。

フローチャートではデータを表記せず、機能のみを表記し、機能実行の順序を表す。フローチャートは、機能を実行の順に（通常垂直方向に）並べ、初めから終りに向けて、相互に流れ線で接続したものである。フローチャートの図形記号の中には、各機能を示す記述が記入される。この各機能は、対応するデータフロー図の各機能と同じである。
データフロー図では、親概念も子概念もそれぞれの機能に対応する入力側データと出力側データを持っているが、フローチャート（構造化チャート）では、これらの入出力データが無く、いわば、縮退した概念になる。これを避ける為に、第９図および第１０図の例のように、機能の記述の中に、入力データおよび出力データに関する情報を記入して、データ情報を補う方法、あるいは、第２３図および第２４図の（ ）無しの部分のように、このような配慮をしない方法などの幾つかの方法がある。

フローチャートは、機能の実行順序、分岐や繰返しを示すことができる。しかし、データフロー図は、機能実行の順序、および判断／分岐を示すことが出来ないが、アルゴリズムを最も明解に表現できる。
これらから、設計の小さな進行段階毎にデータフロー図とフローチャートの両者を用いて設計結果を表記すると、機能実現の詳細とその実行を正確に示すことができる。

データフロー図表記の親概念の一般形は、第１図の左端のデータフロー図で上から第２段の「実時間クロック」→「時計」→「時計盤面」の例のようなもので、（入力側）データ、機能、（出力側）データからなる単位的データフロー図であり、これは最も広汎な条件を持つ。（より正確にいえば、出力側データは当該機能が果たされた後の状態であり、入力側データとは当該機能が影響する前の状態である。このデータフロー図の場合には、実時間の順に、実時間クロックが与えられ、時計が作用して盤面ができる。このように入力側データとしては入力側状態、出力側データとしては出力側状態と定義して、設計の上流段階の思考を容易化する。）ここでは、実行すべき機能は「時刻を得る」の１機能であるから、特にフローチャートを持つ必要は無い。この子概念を表記したデータフロー図は、第１図の左端のデータフロー図の第３段、「１秒クロック」「時刻をえる」「時刻」「時刻表示を求める」「時刻表示」「表示する」「時計盤面」である。データフロー図では、実行の順序など制御を表すことが出来ない。一方、これに対応するフローチャートは第１図の中央上の「時計」のフローチャートであり、データを持たないものの、制御の条件を持っている。すなわち、始めに「時刻をえる」、次ぎに「時刻表示を求める」最後に「表示する」のごとくである。

そこで、小さな段階毎の設計知識は、親概念は親単位データフロー図で、また、子概念は、子データフロー図と子を表すフローチャート（あるいは構造化チャート）の両者を使えば最も完全な表記ができる。

実務上、データフロー図あるいはフローチャートのみを用いて、設計する場合もある。データフロー図のみを用いる設計では、親概念は親単位データフロー図であり、子概念はその子データフロー図であり、第２図はその１例である。フローチャートのみを用いる設計では、親概念は単一の親機能であり、子概念はこの親機能を実現するフローチャートである。先の例に対応させると、親機能は「時計」であり、その子であるフローチャートは第１図中央上のフローチャートであり、これは第２図の子データフロー図の機能群を抜出して実行順に並べた「時刻をえる」「時刻表示を求める」「表示する」からなるフローチャートである。
ここでは、最も一般的にする為に、データフロー図とフローチャート（構造化チャート）を用いるが、制御もデータフロー図に併記する種のデータフロー図を使えば、２種類でなく、１種の図で済ませる。この場合でも、本発明は、適用可能である。
ここで用いる単位的な設計知識は、これらの親概念と子概念の対であり、以下階層展開の為のこれらの設計知識を「設計ルール」と名付ける。このような、人の概念間の関係を知識と定義することは、所謂人工知能の常識とは異なるが、広く人間の諸般の意図的行動を対象とし、最下流では、ソフトウエア設計をとって統一的な方式を実現するためには不可欠な定義である。

初めに説明した、経営に近いシステムの上位の段階では、入力や出力のデータとしてもっと広い概念でのデータ、例えば情報や処理の前後の状態などを捉える。人の意図的行動と明確に言えるところから純粋にプログラムに至るまでの過程は緩やかに、切れ目なしに推移する。そこでこれら階層展開の過程は、人の創造的な知的処理の過程とみれば全てを統一的に扱える。これから前述したように、用語の定義として、設計とは人の意図を達成する行動と広く捕らえることとすると宣言した。

上記のように設計を階層展開の連鎖で構成する時、設計過程を示す設計図面を論理的に辿ると、最初の親に相当する最も抽象的な単位的設計情報から枝が出て、その子に相当する、より具体化された単位的設計情報群に繋がり、その子の各各は自分の子（最初の親から見れば孫）の群につながることを繰返す構造的な設計図面になる。
第１図を見ると、左上の「時計」から下方に３展開して「時刻をえる」「時刻表示を求める」「表示する」に至り、そのおのおのが更に下方に展開して、例えば「時刻表示を求める」から下方に３展開して「時針を求める」「分針を求める」「秒針を求める」に至り、更にそのおのおのが更に下方に展開している。これは先に設計は階層展開の連鎖として説明した所である。これらの連鎖的な動作を再現すれば、設計が自動化できる。

以下に人の設計動作を定型化して機械化する方法について、巨視的な動作を第１図を参照しながら説明する。
与えられた仕様は、時計であり、最初のデータフロー図は、機能「時計」のみである。これを正規形式にする為に、入力データ「実時間クロック」と出力データ「時計盤面」を付加して第２段に示す単位データフロー図にする。これを設計知識により階層展開すると、第３段のデータフロー図になる。ここでの設計動作は、第１図の図面を設計の進行を記録する図面として、親単位データフロー図「実時間クロック」「時計」「時計盤面」を知的動作の為のエンジンに与え、第２図に示すこの設計の為の設計ルールを得て、設計ルール中の子概念「１秒クロック」「時刻をえる」「時刻」「時刻表示を求める」「時刻表示」「表示する」「時計盤面」を第３段のデータフロー図として図面に貼付ける。
この場合の設計知識「設計ルール」には、子概念としてフローチャート「時計」のフローチャート、「時刻をえる」「時刻表示を求める」「表示する」があるからこれを設計図面に登録する。これが第１図中央のフローチャートの最上部になる。

第２段のデータフロー図では、これ以外の親概念は無い。そこで、第３段のデータフロー図に降り、第１の機能「時刻をえる」の単位データフロー図「１秒クロック」「時刻をえる」「時刻」をエンジンに送り、該当する設計ルール（図示されていない）を得て、その子データフロー図を第４段に貼付ける。次ぎに第２の機能「時刻表示を求める」について、エンジンに親単位データフロー図を送り、これに対応する設計ルールを得る。ここで親単位データフロー図の入力データ「時刻」は第１の機能と共通であるから、第１の機能の子の出力データと第２の機能の子の入力データは共通であり、第１図に示すように第１の機能の子として貼付けた出力データを入力データに用いる形で第２の機能の子を貼付ける。続いて子の機能群と出力データ群を貼付ける。次の第３の機能「表示する」についても同様な処理を行い、以後第３段には親機能は無くなるので、下に降って第４段に至り、「時刻を得る」の子について処理を行い、次ぎに「時針を求める」「分針を求める」「秒針を求める」について処理を行う。

これらと並行してフローチャートの設計がある。このフローチャートの子概念は、親概念を与えられてエンジンから供給し、次々とフローチャートの場所に貼付ける。既に説明したように、分岐や繰返しが無い場合には、子概念のデータフロー図に現れる機能群を実行順に並べたもので、データフロー図に現れる順番と実行順が同一なら、エンジンはデータフロー図から変換して子フローチャートを得ることができる。但し、分岐や繰返しのある場合には、データフロー図とは必ずしも対応せず、データフロー図の設計は一拍足ぶみする。
以上の動作を行わせる為に、単位的な設計を行う機能を指定する始点を設けて、この機能を親概念とする単位的な動作と、始点を順次横方向に移動させては、更に下段に降る動作とに分け、データフロー図とフローチャートの上の始点を同期的に動かしながら設計動作を行わせる。

次に、これらの過程での単位的な設計知識、設計ルールを説明する。第２図は、第１図の左のデータフロー図の第２段と第３段を抜きだして示したもので、データフロー図での親概念が上の単位データフロー図に、子概念が下のデータフロー図に示されている。データフロー図のみの設計ルールは第２図のとおりであり、設計全体の設計ルールは、子概念のフローチヤートをも伴う。
これに対応するフローチャートのみの設計ルールは、親概念の機能に子概念のフローチャートを対応させたもので、第１図の左端のデータフロー図を右に９０度回転して機能のみを残したものである。フローチャートの場合には、先行図面に親概念、後続図面に子概念を示すから、この展開関係は、第１の図面は機能「時計」のみがあり、第２の図面に、「時針を求める」「分針を求める」「秒針を求める」のプログラムとしての実行順序が表記される。フローチャートでは設計の階層展開関係が図面間をまたぐことになり、見にくい。そこで、実用上の観点からフローチャートではなくて構造化チャートを用いる。

構造化チャートは、プログラムの構造的な３要素である「連接」「分岐」および「繰返し」に、それぞれ各図形シンボルを用い、図式的にプログラムの構造を書く。

第３図は、同じ展開関係を構造化チャートＰＡＤ(Problem Analysis Diagram)で示した。ＰＡＤでは、階層展開の子を示すには親概念の機能の右方向に線を伸ばし、子概念は、各機能を実行に垂直方向に順に並べて（連接）左端に垂直な流れ線を引き、親概念から右方に伸ばした線と結合する。図にはないが、繰返しの場合には、第１の機能（箱）で条件を表し、この箱の右方向に線を伸ばして第２の機能（箱）に到り、この箱に繰返す機能を表す。第１の機能（箱）には、垂直線を引き、繰り返しを示す。図にはないが、分岐の場合には、右方向に切込みのある図形記号を用い、箱の左端に分岐条件を表す。箱の内部には分岐条件を示す。楔形の上方から右方向から伸ばした線に、条件成立の場合の処理を続け、また、楔形の下方から右方向から伸ばした線に、条件不成立の場合の処理を続ける。

第３図は、第２図に対応する構造化チャートでの設計ルールを示す。左端の機能は親概念である機能を示し、垂直線およびその右部分が子概念である制御の流れを示す。第３図に見られるように、親概念と子概念（群）の対は、同一図面内で相隣り合わせる関係で書かれ、かつ、更に子概念毎にこれを親概念としてその子概念群が書かれることを繰返すから、同一図面内に幾つもの親から子への展開関係が図示される。構造化チャートを用いると、これは同一図面に親概念である機能と子概念（群）の機能（群）の両方が同一図面に書かれ、階層展開関係は右に伸びる樹枝状になり、階層展開関係が最も見やすい。

データフロー図として、ここに使用している図と異なるＤｃＭａｒｃｏのデータフロー図がある。これは、事務計算系向きに簡略化したもので、データの記号を用いないで、着目するデータ名称をデータの流れ線に添記し、データ構造の詳細を隠蔽して、データ辞書で詳細を示す。ここに説明している技術は、基本であるから殆どそのまま利用でき、更にデータ辞書部分に対する処理を追加すれば可能になる。

この他に、所謂データフロー言語向きに開発されたデータフロー図もある。これには、各種の提案があり、標準化されていない。骨子は、データフロー図に（フローチャートの）制御を加味したものである。従って、ここに説明する技術に基づき、データフロー図に関する技術はそのまま、更に当該データフロー図での制御の表記に関係する部分について、フローチャートの場合の技術を当該データフロー図に盛り込めば良い。

次に、既設計図面から設計知識、設計ルールを自動獲得する方法の概要動作を説明する。
特開平１０−３２０１８８号公報は構造化チャートでの設計知識の自動獲得の最も基本的な方法を示している。ここでは、これに基づきデータフロー図にも適用できるように拡張した方式での概要動作を説明する。
自動獲得動作の全体を第１図の左端のデータフロー図群を使って説明する。先に設計動作の定式化で説明したように、図面についての全体的動作と、ある親に着目した具体的な設計ルールを獲得する局部的な動作とに分ける。設計ルールの親機能に始点表示を立てて、全体的動作は、この始点の移動を行うこととする。この時、局部的動作は始点を親に固定させて行う。簡単のために、全体的動作は特定点から始めて降りながら一筆書きにする方法を説明する。

第１図の左端のデータフロー図の最上位である第２段のデータフロー図の中央の機能「時計」に始点を表示させる。
動作を開始すると、設計ルールを自動獲得する局部動作を始める。これは、まず、第２段のデータフロー図「実時間クロック」「時計」「時計盤面」をなぞって親概念の情報を獲得する。次ぎに、第３段のデータフロー図「１秒クロック」「時刻をえる」「時刻」「時刻表示を求める」「時刻表示」「表示する」をなぞって、子概念の情報を獲得する。

局部的動作を終えて全体的動作に戻る。第２段のレベルには、対象となる機能は最早存在しないから、第３段に降り、最左端の機能「時刻をえる」に始点を移して、局部動作を始めさせる。これが終わると、次ぎに始点を機能「時刻表示を求める」に始点を移して、局部動作を始めさせる。これが終わると、次ぎに始点を機能「表示する」に始点を移して、局部動作を始めさせる。これが終わると、この段には最早存在しないから、次の第４段に降る。以降、全体的動作は、このように行う。
すなわち、ある親のレベルの全ての親機能の次ぎには、各親を展開した子のレベルに至り、第１の親の第１の子、第２の子、・・・、第２の親の第１の子、第２の子、・・・、のように、レベル毎に始点を移動させながら、局部動作を行わせる。これは設計知識の自動獲得でも自動設計でも同じである。

これを実現するには、始点を、ツリーウオークプログラムで次ぎ次ぎと各機能上に移動させる。第３図の例について云えば、当初の親概念側の機能記号「時計」から出発して、その子概念側の機能記号「時刻をえる」、「時刻表示を求める」および「表示する」を辿り、再び「時計」に戻る。次ぎに、第１の子概念「時刻をえる」について同じ動作を行わせる。
局部的動作の内、親概念の自動獲得は以下のように行う。始点表示のある親機能（例えば、第２図の「時計」）から、その記号内の記述を取出す。次ぎに親機能から左へ一つたどって入力側データ（第２図の上左の「実時間クロック」）に至る。これら入力データ記号（群）の中の各記述を取出す。再び、始点のある親機能に戻り、右へ一つたどり、出力データ（第２図の上右の「時計盤面」）に至る。これら出力データ記号（群）の中の各記述を取出す。これらを処理して、親概念である、単位データフロー図の情報を作る。

親から子へ移る為には、予め、両者の間に関係を設定しておく。例えば、子概念であるデータフロー図（群）中の各機能（群）は、親概念である機能と破線で示す階層線で結ぶ。子概念である各データフロー図（群）中の先頭データは、親概念である単位データフローの入力データとの間に一点鎖線で示す関係線を設ける。同じく、子概念である各データフロー図（群）中の末尾データは、親概念である単位データフローの出力データとの間に関係線を設ける。

親単位データフローをなぞった後、上記の各種の接続を利用して、子データフロー図（群）をなぞり、途中で各記号の中のそれぞれの記述を取出す。これらを処理して、子概念であるデータフロー図（群）を再現する。以下はその一方法例である。すなわち、始点表示のある機能「時計」から出発して、左へ辿り、入力側データ「実時間クロック」から下り、子データフロー図の先頭入力データ「１秒クロック」に至る。一方、「時計」から出発して、右へ辿り、出力側データ「時計盤面」から下り、子データフロー図の末尾出力データ「時計盤面」に至る。入力側先頭と出力側末尾の両側から、交互にそれぞれ右向きと左向きに子データフロー図を辿る。辿りながら両方からの辿りが衝突した時に（そのデータフロー図に関する）辿りを止める。全て、辿りながら各記号をなぞり、各記号のそれぞれの記述を取りだす。これらを処理すれば子概念であるデータフロー図を再現できる。

以上の説明は、データフロー図の場合であり、構造化チャートの場合の局部動作を簡単に説明する。第３図は、第２図のデータフロー図に対応する構造化チャート、ＰＡＤである。親概念は図の左端の、始点表示のある機能「時計」の記号内の記述を取り出して処理して得る。子概念は図の中央の垂直線から右の部分である。親記号から出発してツリーウオークを行う。すなわち、「時計」から出発して上右に辿り、第１の子機能「時刻をえる」の周囲を右に回り、記号内の記述を取り出し、続いて垂直線を降って「時刻表示を求める」に至って、同操作を行い、再度垂直線を降って「表示する」に至って、同操作を行なう。ここで垂直線を右に辿ると最下部で折返し、今度は垂直線の左側を上昇し、親機能「時計」に到着して、局部動作を終える。
これらの動作は、基本としてデータフロー図と構造化チャートの両者について同期的に行なう。これらの動作を行えば、両図面の一致確認、ある図面の全ての設計知識を一斉に取出すなどが行える。また、動作の順次に、親概念のみを取出すことも行える。

先に人の設計を定式化した自動設計を説明したが、以上説明したことを用い、データフロー図の自動設計について、更に詳細な説明を行う。設計知識の自動獲得と同様に、全体的動作と設計知識を貼付ける局部的動作に分けて構成し、作業対象となる親データフロー図中の親機能に始点を立てて、全体的動作と局部的動作を機能的に統合する。

そこで、差が出る、自動設計を行う局部的動作と全体的動作のシーケンスについて説明する。
説明する自動設計の場面は、第１図の左端のデータフロー図群中の第２段の機能「時計」について、第３段のデータフロー図が付加される所を説明する。

第４図は、作業対象の親単位データフロー図について自動設計開始時の状態を示し、点線の図形は子データフロー図が貼付けられた後の様子を示す。始点が図面上の、親機能「時計」にあり、自動設計の動作を行う時、局部動作では、まず初めに親概念の単位データフロー図をなぞり親概念を得る。

このように、得た親概念をエンジン側に送出すると、エンジン側ではこの親概念に対応する設計ルールを返送する。（後述するようにエンジンとしては、知識ベースと自動生成とがある。）この場合の設計ルールを第２図に示す。自動設計を行うには、第２図の設計ルールの子概念に対応する下のデータフロー図を準備し、第４図の上の親単位データフロー図の下部に貼付ける。
貼付けるには、各種の方法があるが、最も簡単な例で説明すると、第４図の親データフロー図で、始点のある親機能から左に辿って入力側データ「実時間クロック」に至り、一方、第２図の設計ルールの親機能から左に辿った入力側データ「実時間クロック」に至る。

次に、貼付けを行う。簡単の為に、一方向から進める場合を説明する。まず、第２図の設計ルール側から入力データ「実時間クロック」の下方への接続を調べ、あれば第４図の入力データ「実時間クロック」に下方への接続をコピーする。次ぎに設計ルール側では、先の下方への線を辿って子の入力データ「１秒クロック」を読出し、一方設計作業対象側では、同じく下方への線を見て、線の他端にデータ「１秒クロック」への接続とこのデータ自体「１秒クロック」を記入する。次ぎに設計ルール側では子の入力データ「１秒クロック」の右方向の出力接続を調べ、貼付けた「１秒クロック」の右方向の出力接続を作成させる。これを繰返して、子の出力データが、親の出力データとつながると記号コピーを停止し、各種の親子間の接続をコピーして局部的動作を終え、全体的動作を司る始点を次の機能に移動させる。

これらの方法は、高い成熟度のソフトウエア開発組織に見られる高い能力の技術者の設計能力をモデルとしている。かようなエキスパートは、正確で明解であり的確な自然言語を用い、小さな段階毎に階層展開を行う能力がある。かような設計を行う時、階層展開数は平均３弱の小さな値に留まる。例えば第１図の中の機能やデータの階層展開の展開数は、全て３である。また、階層展開自体も簡単であり、不整なデータフロー図も生じない。この発明は、かような前提の上に立っている。

次に、人間工学の分野でのＺipfの発見した「労力最小化の原則」を説明する。これによれば、「人は問題に直面すると、最初に最も簡単な解法を試み、これが不成功なら更に高度な解法を試み、かような高度化を繰返す」とされる。人工知能の分野ではRasmussenは、人の知識には「技能レベル」、「ルールレベル」、そして「知識レベル」があると指摘したが、これらは何れも同様である。

人の設計では、親概念から子概念を作りだすエンジンとして、最も簡単な解法に相当するものは、「技能レベル」であり、記憶の単純な再利用である。例えば特開平１０−３２０１８８号公報に記載されている方式がそれであり、先に説明した設計知識を自動獲得して知識ベースに蓄えておき、要求に応えて設計知識である設計ルールを返送して先に説明した自動設計を行うものである。これより高度なものは多数の変形が有りえる。最も単純な自動生成は、親概念を与えられると、より基礎的な設計知識を参照して設計知識である設計ルールの自動生成を行うものである。ここでの説明では、これらは全てエンジンとして抽象化して説明してあり、任意の自動生成方式のエンジンを組合せることが可能である。

これらの各エンジンは相互に関連を持つ。すなわち、人は一度難しい問題を長時間掛けて解くと、同種問題の２度目では先行経験を活かして、より短時間で問題を解く。設計ルールの場合も同様であり、一度生成を経験すると、これを記憶していれば、後続する同種設計ルールを作るには、先行経験の設計ルールを再利用する。これが繰返しによる効率向上の原因である。人は、何度かの経験で覚えることが多いが、機械は１回の経験で記憶させられる。例えば、自動生成した設計ルールを知識ベースに蓄えさせれば、容易にこれが実現できる。このようにエンジンの内部では、各エンジンユニット相互が協調して動作させることが肝要であり、これが速度向上を産み出す。

ある親概念についての子概念は幾つか存在する。それは辞書を見れば、ある概念について幾つかの意味の説明があることを考えれば納得できる。この為、特開平１０−３２０１８８号公報に記載した再利用方式では、親概念で知識ベースを検索し、得られた子概念につき設計者が適当なものを選択指定した。自動生成に於ても、幾つかの子概念の何れを取るのか、が判らないと自動生成できない。これらは設計の方向の自動決定の問題である。以下この問題について、初めに人の設計の構造を説明し、その解決原理を説明する。

既に説明したように、ソフトウエアの設計は、最終的に実現すべき効果、効用から出発して、これの実現手段（群）に階層展開するが、この過程で、より具体化される。展開し具体化した１実現手段について、前同様に今度は、これを目的として、これを実現する手段（群）に階層展開する。この操作を順次繰返す。繰返す内に、各目的／手段は次第に明確化し、具体化し、詳細化される。これらの目的群は、階層的な樹枝状を呈し、目的樹と呼ばれる。
具体化が進むと、展開されたある目的は、目的の色彩も持つが同時に外部的な機能を示すようになる。これは段階的に行なわれるものの、出発点の目的と、展開を重ねた後の機能とでは、概念レベルが異なっている。そこで、目的樹の置かれた目的平面の下位に、機能の平面があると考える。上位の目的平面の目的樹は階層的に枝分かれするが、そのうちのある枝は、下位の外部機能平面での機能につながるから、目的樹は枝を拡げると同時に下位の機能平面に移行して行く。

ある外部的な効用と外部機能が定まると、その機能の出力が規定される。その出力を得るに必要な、入力が規定される。出力と入力が定まると、入力から期待する出力を得る為のアルゴリズムも規定される。階層展開を繰り返す間に、これらの具体化が行なわれるから、外部機能は次第に内部（ソフトウエア工学でいう入力から出力への間の変換過程としての）機能に移行していく。
すなわち、外部的な機能は、出力データ、入力データ、およびアルゴリズムという枠が定められたのち、ソフトウエアで周知のように、機能が階層展開されて行く。この結果として、機能は階層的な樹枝状の展開を呈する。同時に、入力と出力の両データも、階層的に展開され、樹枝状を呈する。この機能およびデータの階層展開した様相は既に説明した。かような機能とデータは、双対の関係にあり、「データ構造とアルゴリズム」として、教科書に取上げられているところである。

上記のように、いわば上位の目的平面に目的樹があり、下位の機能平面に機能およびデータの階層的な展開樹（群）がある。そこで、上位平面の目的樹の一部が、下位の機能とデータの階層樹に影響を及ぼしており、これが設計の進路を反映している。
これらから、出力データ、出力データと入力データ、あるいは、これらに加えて更に目的樹の一部から、設計の進路を正しく知ることができる。そこで、出力、出力と入力、あるいは、出力と入力に加えて、周辺の機能とデータの様相を知れば、かなり正確に設計の進路を予測することができ、設計の進路の自動選択ができる。かような原理に基づき、設計の進路を自動選択する機能をＤＤＦ（Design Direction Finder）と名付ける。

一般に、人の行動は、ある目的を達成する為に目的を展開することを繰り返すが、この実行上のポイントは「５Ｗ１Ｈ」に尽きるとされる。ここで、５Ｗとは、what、where、who、when、whyなどの、また、１Ｈとは、howの、各頭文字である。すなわち、高度な人の行動には５Ｗ１Ｈの高度な識別や指定が必要であり、この場合の文章は複雑なものになる。「５Ｗ１Ｈ」の観点で厳しく枠を定めると、その分で決まる動詞の意味は、ほとんど曖昧さが無いように限定されてしまう。

小さな段階毎に階層展開をおこなうから、展開に課せられた概念展開は、（最大限度では５Ｗ１Ｈを要するものでも、）実際はこれらの幾つかに過ぎず、従って、プログラムに展開されたレベルでは、これほど高度なことは必要でなく、展開の中心部分である動詞について有りえる変形は、ごく僅かの種類しかない。（仮に５Ｗ１Ｈを詳細に表記する時は、複数の階層展開にわたって表記することになる。）また、辞書のある用語の定義を考えれば、理解できるように、動詞・名詞を問わず、高々数種の意味しかない。以上から、目的の観点から分析し、それを反映するデータ等を見れば、その相様から目的に応じた用語を決定できる。

以下、実例についてこれを説明する。簡単な事務計算プログラムの例として、在庫管理プログラムの場合を考え、幾つもの意味を持つ動詞として、「入力する」を用い、データが必要であるので、データフロー図で説明する。

第１の意味は、入力の確認を必要とする場合である。この設計ルールの例を第２２図に示す。（この例では「○○を△△する」と書く原則に従う詳細部分は括弧で示した。）外部的な入力データについては、その情報の正当性が確認されていない時には、必ず正当性を確認してから、指定された処理を行う。この場合の親概念は、入力データ９１ｃが「未確認ｘｘｘｘ」、機能９２ｃが「入力する」、また出力データ９３ｃが「ｙｙｙｙ」である。入力データ９１ｃは、接頭詞により「未確認」であるので、他の処理に先立ち、情報の正当性を確認する。そこで、子概念は、入力データ９４ｃが「未確認ｘｘｘｘ」、第１の機能９５ｃは「確認する」、中間データ９６ｃは確認済であるから接頭詞「未確認」を取去り「ｘｘｘｘ」、第２の機能９７ｃが「入力する」、そして出力データ９８ｃが「ＸＤＢ」、例えば「入金ＤＢ」である。

第２の意味は、入力を加算する場合である。この設計ルールの例を第２３図に示す。（この例では「○○を△△する」と書く原則に従う詳細部分は括弧で示した。）この場合の親概念は、入力データ９１ｄが、例えば「入金伝票」、機能９２ｄが「入力する」、また出力データ９３ｄが「入金ＤＢ」である。ここでは、入金ＤＢに新しい入金伝票分が加算される。そこで、子概念は、入力データ９４ｄが「入金伝票」であり同時に参照入力９９ｄとして「入金ＤＢ」を伴う。機能９５ｄは「入力を加える」、出力データ９８ｄが「入金ＤＢ」である。

第３の意味は、入力を差引く場合である。この設計ルールの例を第２４図に示す。（この例では「○○を△△する」と書く原則に従う詳細部分は括弧で示した。）この場合の親概念は、入力データ９１ｅが、例えば前と同様な「入金伝票」、機能９２ｅが「入力する」、但し、出力データ９３ｅは「売掛ＤＢ」である。この場合には、入金分だけ帳消にするから、売掛ＤＢから新しい入金伝票分が差引かれる。

子概念は、入力データ９４ｅが「入金伝票」であり同時に参照入力９９ｅとして「売掛ＤＢ」を伴う。機能９５ｅは「入力を差引く」、出力データ９８ｅが「売掛ＤＢ」である。
前記の３例での狭義の親概念は、いずれも「入金する」である。
一方、狭義の子概念は、
第１の場合は、第１機能９５ｃは「確認する」、第２機能９７ｃは「入力する」であり、
第２の場合は、機能９５ｄは「入力を加える」であり、最後に、
第３の場合は、機能９５ｅは「入力を差引く」である。
小さな進行段階毎の階層展開は、通常この例に見られるような簡単なものである。

特開平１０−３２０１８８号公報のような構造化チャートのみを用いる自動設計方式では、ある親概念について、設計知識を検索するが、知識ベースからこのような複数の意味の何れかを人が選択し指定した。
ここでは、実態の分析から選択を自動化する。各場合を列挙すると、
第１の意味であることは、親概念の入力データ９１ｃの接頭詞「未確認」から判定でき、
第２の意味であることは、親概念の入力データ９１ｄが「入金伝票」であり、かつ親概念の出力データ９３ｄが「入金ＤＢ」であることから判定でき、
第３の意味であることは、親概念の入力データ９１ｅが「入金伝票」であり、かつ親概念の出力データ９３ｅが「売掛ＤＢ」から判定でき、
自動選択が可能になる。基本的には、第１、２、３の場合の識別条件と意味との対応を示すテーブルＤＤＦＴ（Design Direction Finder Table）１９６を作り、これを参照して決定する。これは、すでに説明したように、目的の順に出力データ、次にこれを得るための入力データが指定され、次にその処理の仕方であるアルゴリズムが決まる。即ち、親概念の動詞の意味が決まることに対応したものである。

この諸例から、親概念への入力データ９１や出力データ９３から設計の進路が自動決定できることが理解されよう。実用上、親概念の入力および出力データ９１、９３を確保すれば充分であり、特殊な少数の場合には、更に先行する入力あるいは出力などのデータを必要とする。

以上から、設計知識、設計ルールを蓄積して再利用する場合、あるいは親概念から子概念を自動生成する場合の、設計進路を自動選択する機構を作ることができる。ここで、これらの決定には親概念の入力と出力が不可欠であるので、構造化チャートのみを用いる方式では、実現が著しく困難であり、データフロー図と構造化チャートを併用した方式、あるいは両者の機能を併合した図を使う特殊なデータフロー言語向きの図面を使う方式が必要である。

次に、本発明のシステム的な側面を説明する。かような自動設計システムでは、自動化機能が完全でない場合があるから、必ず人手で修正が行えることが不可欠である。例えば、自動化機能が不完全でも期限迄には設計を終えねばならないから、自動化機能が全く無い場合でも使用可能なシステムでなければならない。この条件にかなうシステムはＣＡＳＥ（Computer Aided Software Engineering）ツールとして知られている。

次に、データフロー図と構造化チャートを併用することが必要である。通常の設計では、設計の上流ではデータフロー図を使う構造化分析により、これにつづく下流では構造化チャートを用いて構造的にプログラムを設計する。これを踏襲してデータフロー図ＣＡＳＥツール２０ｂと構造化チャートＣＡＳＥツール２０ｃを備えたとすると、今迄よりも大きな手間を要するから実務上不具合である。

すでに説明したように、小さな段階毎に設計図面を残す方式では、データフロー図で表記できない分岐と繰返しの場合を除き、データフロー図中の機能〔群〕はフローチャート（あるいは構造化チャート）の機能（群）と通常一致するから自動的に変換することができる。もし不具合なら機能の実行の順序を人手修正することにして、データフロー図からフローチャートや構造化チャートの対応部分を自動生成することができる。そこで、通常はデータフロー図を作画して構造化チャートは自動追随させる。特に、分岐や判断の場合のみ、構造化チャートを第１に設計してデータフロー図側は同期させることとすれば、実質上１図面の作成負担で済み、効率が良い。但し、これは設計を小さな段階毎におこなう場合に限る。

これらの人手作業では誤りが混入することがあるから、両種の図面を併用するシステムでは図面相互のチェックを行い、相互矛盾を防止するガード機能などを設けてある。これらから、幾つかの図面のＣＡＳＥツール機能を備えると共に、各種のシステムレベルの機能で統合されたシステムにしている。

設計知識、設計ルールを自動生成する技術は、設計の進路の自動決定により子概念の概要を決め、更に詳細を周囲条件で決定することにより、達成できる。
以下にその概要を説明する。
既に第９図、第１０図、第２２図、第２３図、および第２４図により、動詞「入力する」の諸形態を見た。ここでは、データフロー図の情報との重複があるが、機能の記述として「○○を△△する」流の模範的な形式に倣っている。

第２２図、第２３図、第２４図および第９図、第１０図を通して見ると、これらの設計ルールの共通部分、スケルトンが見える。第１１図はそれを示したものである。
逆に、このスケルトンを基準として各設計ルールを見ると、この骨組みに対する若干の付加をしていることが見え、特に入力データ９１や出力データ９３の名称を幾つかの規則で組込んでいることが判る。これはスケルトンについて行う処理が少数のパターンであることを示している。

次に、これらを例として設計知識である設計ルールの自動生成方式を説明する。
ここでは、親概念は単位的なデータフロー図を入力とし、これを階層展開したデータフロー図、および、このデータフロー図と整合して機能実行の順序を示す構造化チャートの両者を子概念として自動生成する方式を説明する。

自動生成の入力は、親概念となる親単位データフロー図であり、その出力は、子概念であるデータフロー図および同じく子概念である構造化チャートである。
階層展開を示す設計知識、設計ルールを、自動生成する為に、より基礎的な設計知識を使う。中心的な構造は、ＤＤＦＴ１９６を使うDesign Direction Finder、および動詞辞書１３０である。
第１３図を参照して、動詞辞書は、親概念から抽出した動詞で索引される、動詞毎の幾つかのページから成立つ。（数式や数式的な処理をする為に、親概念が名詞で与えられる時には、「○○である」「○○は以下のとおりである」のように動詞化する。）このページは、動詞の意味ごとに設けられる。

各ページは、子概念の原形であるスケルトン１３１、および、スケルトンに施す処理を示すメソッド１３２とから成立っている。スケルトンはデータフロー図に対するものと、構造化チャートに対するものが、準備されている。各ページのスケルトンはデータであるので、メソッドと併せると、あるページは知識工学用語では「フレーム形の知識」表示である。

第２５図を参照して、ＤＤＦＴ１９６は、親概念である親機能の入力データ等、出力データ等、およびその他のデータ等の項目から成立つ中央部分があり、各項目にはデータの名称、無関係であること（nil）、あるいは無視すること（Don’t care）マークなどが記される。これらの中央部分に対して別に設けられた意味番号欄があり、これはある動詞辞書の使用するべきページ番号が記載される。第１４図のＤＤＦＴ１９６は、その簡単な例を示す。

第２２図〜第２４図を用いて、動詞「入力する」について、動詞辞書中心に説明する。ここでは簡単の為、目的語などを省略した記述情報を使う。
第１の確認を要する場合は、親概念として第２２図上に記された親単位データフロー図が与えられる。但し、データをｄ、機能をｆとし、追番を付ける。
「ｄｉ未確認入金伝票」、「ｆｐ入力する」、「ｄｏ入金ＤＢ」。
この場合に選ばれた動詞辞書のページには、下記のデータフロー図のスケルトンがある。ここで（）は変数化されている。
「ｄ１（入力）」、「ｆ１確認する」、「ｄ２（中間出力）」、「ｆ２入力する」、「ｄ３（出力）」。
この場合のメソッドは、次のとおりである。
１．親入力データｄｉを、スケルトンのｄ１（入力）に転記する。
２．親入力データｄｉから接頭詞「未確認」を取去り、スケルトンのｄ２（中間出力）に転記する。
３．親出力データｄｏを、スケルトンのｄ３（出力）に転記する。
以上の処理により、第２２図の下に示された子概念のデータフロー図の簡略形が完成する。「△△を○○する」風の模範形にするには、子の動詞部分に目的語と助詞を入れればよい。
「ｄ１未確認入金伝票」、「ｆ１未確認入金伝票を確認する」、「ｄ２入金伝票」、「ｆ２入金伝票を入力する」、「ｄ３入金ＤＢ」。
構造化チャートは、スケルトンを上記のように処理しても良く、あるいは、完成したデータフロー図を変換しても良い。

第２３図に示される第２の場合、および、第２４図に示される第３の場合は、子は確認機能部分がなく、参照ファイルがある点で上記と異なる。例として第２の場合を説明する。与えられた親概念は以下のとおりとする。
「ｄｉ入金伝票」、「ｆｐ入力する」、「ｄｏ入金ＤＢ」。
この場合に選ばれた動詞辞書１３０のページには、下記のデータフロー図のスケルトンがある。但し、参照ファイル（表記ｄｒ）は、入力ｄ１と共に機能ｆに入力する。
「ｄ１（入力）」、「ｄｒ（参照ファイル）」、「ｆ１（入力）を（参照ファイル）に加える」、「ｄ２（出力）」
この場合のメソッドは、次のとおりである。
１．親入力データｄｉを、スケルトンのｄ１（入力）に転記する。
２．親出力データｄｏを、スケルトンの参照ファイルｄｒ、出力ｄ２に転記する。
以上の処理により、必要な下記の子概念のデータフロー図が完成する。
「ｄ１入金伝票」、「ｄｒ入金ＤＢ」、「ｆ１入金伝票を入金ＤＢに加える」、「ｄ２入金ＤＢ」
構造化チャートは、これと同様に処理してもよく、あるいは、前項同様にデータフロー図を変換して得ても良い。

この場合のＤＤＦＴ１９６は第２５図のとおりである。ここで、ｄｃは無関係であること、ｎｉｌは何もないことを示す。第２５図に示す表は、親機能への入力データに接頭詞「未確認」があれば、動詞「入力する」の第１ページを使うこと、
親機能への入力データが「入金伝票」、同じく出力データが「入金ＤＢ」なら、動詞「入力する」の第２ページを使うこと、
親機能への入力データが「入金伝票」、同じく出力データが「売掛ＤＢ」なら、動詞「入力する」の第３ページを使うこと、
を意味しており、先に進路方向の自動選択で示したところと同一である。
これらの構成を先の各ページ毎のスケルトンの処理と組合せて子概念を自動生成できる。

更に、本発明に係る自動設計システムにおける基本とする設計知識の獲得および再現の原理を第１図を用いて説明する。ただし、仕様として、「時計」（１０１）の場合について示したものである。図の左端には入力される仕様である「時計」（１０１）を示し、次にはデータフロー図設計１１０の結果を段階的にかつ階層的に示し、次に対応するフローチャート設計１２０の結果が示されている。通常はデータフロー図設計の後にフローチャート設計を行うが、本発明のプログラム設計１００では、データフロー図設計１１０とフローチャートの設計１２０を並行して同時に行なう。

小さな段階毎に、階層的に詳細化すると、図の例に示すように、データフロー図のデータ、機能、データの流れの中の機能を取出したものは、フローチャートの記述と同じになる。親の「時計」は、データフロー図により、子において「時刻を得る」、「時刻表示を求める」、「表示する」と階層的に展開され、詳細化される。
データをｄ、機能をｆとして前置すると、第１図のデータフロー図の第２段（第２図にも示す）ではデータフロー図は、ｄ「一秒クロック」、ｆ「時刻を得る」、ｄ「時刻」、ｆ「時刻表示を求める」、ｄ「時刻表示」、ｆ「表示する」、ｄ「時計盤面」であり、これに対応する「時計」を詳細化したフローチャートは第１図の最上段（第３図にも構造化チャートで示す）に示す如く、ｆ「時刻を得る」、ｆ「時刻表示を得る」、ｆ「表示する」である。

分かり易く云うと、小さな段階毎に、まず、データフロー図の設計１１０を行ない、次いでデータフロー図からフローチャートに自動変換して、フローチャート設計１２０が行なわれる。判断・分岐や繰り返しはデータフロー図には表れないから、まず、フローチャートの設計を行なう。簡単な判断や繰り返しのみならデータ処理はなく、したがってデータフロー図には何の追加も必要がない。ある場合には、判断に伴うデータ処理のある場合がある。この時には自動変換された機能のみ現われるから、必要なデータは人が追加する。

フローチャート設計１２０の次にはコーデイング、ソースコード化設計１２５がある。これは最も詳細に展開されたフローチャートの自然言語表記に対応したコンピュータ言語への変換であることは、図を見られると明瞭に理解される。すなわち、最終的な実現手段であるコンピュータ言語の表記に変換することがソースコード化であり、自然言語を用いる階層展開の一変形である。
従って、ここでの設計は、親子の関係を用いた階層展開の連鎖（例えば、親「時計」は、子｛「時刻を得る」、「時刻表示を求める」、「表示する」｝となり、更に親「時刻表示を求める」は、子｛「時針を求める」、「分針を求める」、「秒針を求める」｝となり、更に親「分針を求める」は、子｛「分針の角度を求める」、「分針の幅を求める」、「分針の長さを求める」｝となる。）であるから、後述するように、知識ベース１０ａへの設計知識の蓄積、再利用による自動設計が行なえる。
以上フローチャートの場合について説明したが、これらは構造化チャートでも同じであり、構造化チャートの場合には、相隣る図面２枚に跨る親子の両図面部分が１枚の図面の左右の図面部分に対応し、設計知識の自動獲得と自動設計が容易になる。

まず、本発明において、前提とする設計知識の自動獲得について説明する。第２図は第１図の中央左のデータフロー図の１詳細化過程を拡大した図である。データフロー図は、菱形記号のデータｄの記号、四角記号の機能ｆの記号、および矢印により、データｄ、矢印、機能ｆ、矢印、データｄの順にデータの流れを示したものである。第２図で、上部のデータフロー図は親概念を表し、下部のデータフロー図は子概念を表す。参照の為に、両データフロー図の入力データ同士と出力データ同士が１点鎖線で結んであり、また機能ｆの親子関係が破線で結んである。

第３図は、第１図の中央右の前記に対応するフローチャートの詳細化過程を構造化チャートで表示したものである。

第２図に示すデータフロー図での、設計知識の自動獲得は以下のように行なう。まず、親単位データフロー図の中の機能記号に、始点表示を行ない、処理の便宜に使う。模式的に説明すると、始点から始めて左に辿り、再度右へ辿ることにより、親単位データフロー図の記述情報を得る。次に、子データフロー図に、例えば始点から左に回りながら辿り、子データフロー図の先頭である入力データに至り、以下右に辿りながら子データフロー図の記述情報を得て、左に回りながら始点に帰着する。（始点は次へ移動させる。）これらを整理して、親単位データフロー図と子データフロー図との関係が得られ、これがデータフロー図における設計知識となる。

第３図に示すＰＡＤでの、設計知識の自動獲得は以下のように行なう。まず、機能記号に始点表示を行ない、処理の便宜に使う。模式的に説明すると、始点から始めて右に辿って第１の子概念に至り、以後は垂直に下方に辿って各子概念を経て始点に帰着する。（始点は次へ移動させる。）これらの間に親概念および子概念（群）に対応する記述を得て、これらを整理して、親機能と子機能（群）の関係が得られ、これがＰＡＤにおける設計知識となる。
設計知識の自動獲得は、上記のように、両者（データフロー図およびＰＡＤ）を同期させて行う。設計知識は、それぞれ、対応するデータフロー図用およびＰＡＤ用の知識ベース１０ａに格納する。

次に、第４図を用いて、データフロー図での自動設計について説明する。自動設計は、着目した親データフロー図について、その中の機能記号を中心とする単位データフロー図毎に行なう。第４図は、その一実施例を示す。まず、親単位データフロー図の中の機能記号に、始点表示を行ない、処理の便宜に使う。模式的に説明すると、始点から始めて左に辿り、再度右へ辿ることにより、親単位データフロー図の記述情報を得て、親概念である親単位データフロー図をエンジン群１０に送り、対応する設計知識（知識ベースの出力あるいは設計知識を自動生成した結果の出力）を照会する。照会の結果得られた設計知識は、第２図のようであり、この中の子データフロー図を得て、第４図に示すように当初の親単位データフロー図の下方に点線で示したように貼付ける。（始点は次へ移動する。）横に伸びる１段階の親データフロー図についての自動設計を終えると、下に下り、子データフロー図〔群〕について、親である１単位データフロー図について、同様な動作を繰返す。これを続けると、第１図の左に示す段階的な、データフロー図群を作成することができる。

次に、第５図を用いて、ＰＡＤでの自動設計について説明する。自動設計は、着目した親機能（群）について、その中の機能毎に行なう。第５図は、その一例を示す。まず、左端の親機能記号に、始点表示を行ない、処理の便宜に使う。親機能記号から記述情報を取出し、エンジン部１０に照会する。その結果得られた設計知識は、第３図のようであり、この中の子概念（群）の部分を、第５図の当初の親機能の右方に点線で示したように貼付ける。（始点は次へ移動する。）以後、親のレベルについて自動設計を繰返し、それらが終わると、子のレベルについて同様な自動設計を行う。一連の動作を終えると、右方向に伸
びる樹枝状のＰＡＤを完成することができる。

これらの自動設計動作は、データフロー図およびＰＡＤについて同期的に行う。この時、両者の設計情報の一致を確認することを行ない、信頼性を向上させている。
システム設計の上位では、構造化チャートで表す制御は殆ど無用になり、また、システム設計から進んでプログラム設計の最終段階ではデータフロー図は殆ど無用になる。これらの片肺的な使用に耐え、また、一時的な情報の欠損に備えて、一方から他方の情報を生成して補う。

次に、本発明に係る自動設計システムの一実施例について第６図を用いて説明する。第６図は、自動設計システムとしての構成例を示す模式図である。
本発明の自動設計システムは、ＣＡＳＥツール群２０、親を与えられると親と子の対である設計知識を返送するエンジン群１０、両群間の情報授受などを行う統合部３０、および各種の制御を行う制御系３１および制御パネル３２から成立つ。

ＣＡＳＥツールとは、Computer Aided Software Engineeringツールの略称であり、一般のＣＡＳＥツールは設計者からの指示により、ソフトウエア工学的な規約に従い、設計図面などを作成し、チェックし、ファイルに登録する機能、および、ファイルから設計図面を読出して、表示する機能、これらを混合して使用できる編集機能など、図面や図形を中心とするマンマシンインタフェイスとなる。本発明では、各ＣＡＳＥツールに、前記の図形を用いる自動設計と設計知識の自動展開の機能を付加して用い、設計図面の詳細化を設計者あるいは自動展開機能により設計図面を作成させることにより行い、また、設計知識の自動獲得を行う。

左方はＣＡＳＥツール（Computer Aided Software Engineering tool）群２０であり、下にデータフロー図ＣＡＳＥツール部２０ｂ、および、ＰＡＤ ＣＡＳＥツール部２０ｃが示されている。その上の機能階層図（ＦＳＤ）ＣＡＳＥツール部２０ａは、上記の両図面を管理する為のものであり、本発明の範囲外なので、説明を省略する。即ち、ＣＡＳＥツール群２０には、データフロー図ＣＡＳＥツール部２０ｂと、ＰＡＤ ＣＡＳＥツール部２０ｃとがある。

右の上部にはエンジン群１０がある。これは設計知識の親概念情報を与えられて、設計知識を応答するものであり、上部は知識ベース部１０ａであり、その下には設計知識を自動生成するクリエータ（Creator）ＣＡＳＥツール部１０ｂ、および、自動生成する機能の中心であるクリエータ（Creator）’00プログラム１０ｂａが示されている。これは下の構造辞書ＣＡＳＥツール部１０ｃと共に動作する本発明の中心部分であり、後に詳細に説明する。即ち、エンジン群１０は、設計知識を蓄積する知識ベース部１０ａと、クリエータ（Creator）’00プログラム１０ｂａを有して設計知識を自動生成するクリエータ（Creator）ＣＡＳＥツール部１０ｂと、入出力帳票およびファイルなどの構造を規定する構造辞書ＣＡＳＥツール部１０ｃとで構成される。

中央の統合部３０は、ＣＡＳＥツール（群）２０とエンジン（群）１０との間の相互の情報の中継を行い、各種のＣＡＳＥツールと各種のエンジンを組合せて各種の協調動作を行わせる為の統合的な動作を管理するものである。この他に、統合部３０はＣＡＳＥツール群２０に対する機能、エンジン群１０に対する機能がある。なお、この左右のインタフェイス３５は標準化されており、各種のＣＡＳＥツールおよび各種のエンジンをオープンエンドに組合せることができる。
最上部の制御パネル３２は、キーボードやマウスなどの入力手段および表示手段等で構成される対人インタフェイスとなる部分である。さらに、制御部３１は、全体系を制御するものである。

次に、設計知識の自動獲得と自動設計について第６図を用いて説明する。まず、知識ベースを用いる場合を説明する。知識ベース部１０ａは、機能的には内部でデータフロー図用とＰＡＤ用に分れている。ＣＡＳＥツール群（ＦＳＤ ＣＡＳＥツール２０ａ、ＤＦＤ ＣＡＳＥツール２０ｂおよびＰＡＤ ＣＡＳＥツール２０ｃ）２０が設計知識の自動獲得を行なうと、図の右向き矢印に沿って情報が対応する知識ベース部１０ａに送られ、知識ベース部１０ａは既存設計知識と照合して、新規なものであれば蓄積していく。自動設計では、ＣＡＳＥツール群２０の側から親概念情報が右向き矢印に沿って流れて知識ベース部１０ａに至り、知識ベース部１０ａは照会された親概念に対応する設計知識があれば、これを送出する。今度は、情報が知識ベース部１０ａから左向き矢印に沿ってＣＡＳＥツール群２０に至り、自動設計が行われる。

ここで、統合部３０の右方のインタフェイスは、エンジン群１０に共通であり、Ｃｒｅａｔｏｒ ＣＡＳＥツール１０ｂは、親概念情報を与えられると、子概念情報を作り出して設計知識を返送する。各ＣＡＳＥツール２０ｂ、２０ｃは、知識ベースの場合と同じく自動設計するようになっている。統合部３０は、ＣＡＳＥツール群２０内で各ＣＡＳＥツールの動作の照合を行ない、各ＣＡＳＥツール相互間の図面情報変換の機能を有する他、エンジン群１０を切替え、並行動作させ、また、Creator ＣＡＳＥツール部１０ｂで自動生成された設計知識を知識ベース１０ａに送る等の送信機能（送信手段）を持っている。

次に、第６図に示した構造辞書ＣＡＳＥツール部１０ｃの機能について第７図を用いて説明する。構造辞書ＣＡＳＥツール部１０ｃは、Creator ＣＡＳＥツール部１０ｂが設計知識を自動生成する為に用いる入出力帳票およびファイルなどの構造を規定する為のものである。第７図の上部には入力帳票の実施例として当社売上伝票７１を簡略化して示し、下部にはこれに対応するデータの構造図７２を示したものである。当社売上伝票７１は、フレームとして捕らえ、階層展網で表記する。すなわち、当社売上伝票７１は、先方社名、年月日、当社売上伝票番号、および表形式で示す情報群を代表する各項目として階層的に展開する。下部のデータ７２は階層的にこれらを構成している様子を示す。各項目は更にこれを構成する、商品名、数量、単価、および、小計に階層的に展開されて、各項目の下部に接続される。

第８図は、Creator ＣＡＳＥツール部１０ｂ内で、各種の入力と出力等が纏めて使用される為の構成を示す図である。第７図に示したような、各入出力帳票及び各ファイルに対応する各データは、１本のRootに統合される。各帳票名やファイル名を指定すると、Root（全知識の共通原点）から出発して、所望のデータにアクセスでき、更にその下位のデータを読出すことができる。これを繰返せば如何なるデータにもアクセス可能であり、レベルを指定して読出す、例えば、当社売上伝票・各項目・小計などのようにアクセスすることも出来る。

第６図に示すCreator ＣＡＳＥツール部１０ｂは、自動生成対象プログラムの領域毎の基礎的な設計知識の中核部分であるCreatorプログラム１０ｂａ、自動生成対象プログラム毎の性質の強い上記構造辞書１０ｃにより、設計知識を自動生成する為のプラットホームである。

Creatorプログラム１０ｂａの主要な構成部分（Creator’00の中心部分）は、第１３図に示すように、動詞辞書（Verb Dictionary’00）１３０、および、動詞辞書１３０の選択の為のＤＤＦテーブル１９６（第１４図に示す）である。動詞辞書１３０は、自動生成に用いる基礎設計知識を、この例では動詞の使われる意味に対応して設けられたフレーム形記憶の形式（フレーム形式の知識表現）で、第８図の場合と同様に、Rootに接続されており、ある動詞を指定することにより１フレーム１３０ａが選択されて、使用される。１動詞は、一般に幾つかの意味を持つから、この選択を行なうＤＤＦと組み合わせて使用される。１フレーム１３０ａは、第１３図に示すように、データ領域１３１ａ、１３１ｂとメソッド領域１３２から成立ち、前者のデータ領域１３１ａ、１３１ｂは動詞の意味毎のデータ、さらに詳細には骨組みであるスケルトンから成立ち、スケルトン１３１には、データフロー図用（ＤＦＤスケルトン）１３１ａおよび構造化チャート用（ＰＡＤスケルトン）１３１ｂの２種を備えている。メソッド領域１３２は、この動詞のこのケースでの処理の詳細手続を記述したものである。この処理の詳細手続としては、例えば、親概念の入力データ９１を子概念の「入力」９４に転記する、あるいは親概念の出力データ９３を子概念の「出力」９８に転記するなどである。

次に、スケルトン１３１について、第９図、第１０図および第１１図を用いて説明する。第９図（売掛の場合）と第１０図（買掛の場合）は、共に同じ動詞「入力する」の異なる場合につき、２つの例の設計ルールを示す。図で上部には、親単位データフロー図を示し、下部にはその子概念であるデータフロー図を示す。第９図と第１０図の両場合を比較検討すると、親子の階層展開関係の中心は、「入力する」９２ａ、９２ｂを「確認する」９５ａ、９５ｂと「入力する」９７ａ、９７ｂであり、第１１図はこれを示している。即ち、第１１図は、上記両場合の、抽象化された骨組み（スケルトン：「入力する」９２を「確認する」９５と「入力する」９７である。）となっている。

更に、第９図と第１０図を比較すると、子データフロー図の親概念の入力９１ａ、９１ｂは、それぞれ対応する子データフロー図の最初の入力９４ａ、９４ｂに受け継がれている。中間データ９６ａ、９６ｂは、この入力９４ａ、９４ｂから、「未確認」が削除されている。最後に、出力９８ａ、９８ｂは、親概念の出力データ９３ａ、９３ｂが受け継がれている。
共通する骨組み（スケルトン）は、第１１図に示すものであるから、これを用いて第９図および第１０図の両者を再現することができる。即ち、第１１図に示す共通するスケルトンを用いることによって例えば設計知識（設計ルール）を再現することができることになる。

次に、設計知識（設計ルール）の再現について具体的に説明をする。複数のフレーム形式の知識表現から、ある動詞が選択され指定されることにより１フレーム１３０ａが選択され、例えば、第９図に示す親単位データフロー図が与えられた時、メソッド（スケルトン１３１に作用する処理論理）１３２で親概念入力９１ａを取出し、スケルトン１３１ａの子データフロー図の先頭入力データ９４に記入する。次ぎに、メソッド１３２で、前記入力データ９４ａから取出した情報の接頭詞（「未確認」）を取り去り、子データフロー図の中間データ９６に記入する。さらに、メソッド１３２で親概念である単位データフロー図の出力データ９３ａの情報を取出し、子データフロー図の最終の出力データ９８に転記する。このようにすると、第９図に示す設計ルールを再現することができる。第１０図の場合でも、同じ手順で設計ルールを再現することができる。（第９図、第１０図では子の機能に付いても目的語の追加を行っている。この目的語の追加は、必ずしも必要でないので、省略した。必要なら同様な処理で記入できる。）
子概念は、二つの機能９５、９７を含むから、実行の順序を指定する必要がある。これは、第１２図に示す構造化チャート（フローチャート）により行なえる。第１２図は、ＰＡＤによるスケルトン１３１ｂの表示であり、親概念「入力する」９２は、子概念の初めには「確認する」９５、次いで「入力する」９７を実行することが指定される。ここで、データフロー図と同様にメソッド１３２でスケルトン１３１を加工すれば、子概念（群）について、指定とおりの操作を行なわせ得る。但しこの例では、作られたデータフロー図を変換規則に従って変換して得ることもできる。

このように、親概念の入力９１、機能９２、および、出力９３を与えられた時、より下位の基礎的な設計知識、すなわち、スケルトン１３１およびメソッド（スケルトン１３１に作用する処理論理）１３２を用いて当該親概念に対応する子概念９４〜９８を生成したから、親概念と子概念（群）の対である設計知識、設計ルールが自動生成されたことになる。

第９図を参照すると、これは売掛データベースの新規入力による更新が目的であり、第１０図の場合には、買掛データベースの新規入力による更新が目的である。この目的の達成の為に、第９図では親概念の入力は売上伝票が、また、第１０図では同じく仕入伝票が選ばれる。
そこで、これらの設計ルールの起源を考慮すると、
上位の目的を決めると、１．親概念の出力、２．親概念の入力、３．処理方法が決ってくることが判る。

第９図、第１０図の場合には、入力９１の記述から、入力チェックが未済みであることが判るので、本質的な処理９７を行なう前に、「確認する」段階９５が追加されている。繰返しの説明になるから、省略するが、次の段階の設計ルールでは、それぞれ目的に応じて、「入力する」９２を展開することができる。

ソフトウエア工学では、目的樹の概念がある。これは最終の目的から出発して、これを実現する手段（群）に階層展開し、次ぎに手段の一つを取上げて、新しい目的として階層展開することを繰返して得られる、樹枝状の図である。

この目的樹の平面の下位には、プログラムを代表するデータフロー図と構造化チャートなどの機能の平面がある。人の設計では、脳裏にこの目的樹を描きながら、選ばれたある目的が、親概念から子概念（群）を決める。これをモデル化すれば、前記の場合には、まず、親概念の出力、ついで親概念の入力、最後に以後の処理方式を制御するような自動設計方式になる。
これは理想的であっても、脳裏に描かれる目的樹を図面化することを要するから、必ずしも、実用的ではない。実用上はプログラムの平面のみで処理できることが望まれる。そこで、近似的で実用的な方法としては、上記の場合には、親概念の出力９３および入力９１で判断することができる。

第９図と第１０図の場合には、説明した設計ルールの次の設計ルールを自動生成する時に、このことが使われる。それは、たまたま入力が「未確認」であったことによる。「未確認」でなければ、直ちに処理に入り売掛、あるいは、買掛を共に増加させることになる。
第９図で、親概念の入力９１ａが、「入金伝票」であったなら、売掛を帳消するから売掛データベースの売掛金額から入金金額だけ減少させる処理アルゴリズムになる。すなわち、親概念の中心である動詞「入力する」には、親概念への入出力データ９１、９３から
ア：入力により出力を増加させる場合、
イ：出力から入力を減少させる場合、
ウ：入力を確認する場合、
などの各種の意味の場合がある。

近似的な方法としては、
ａ：第９図および第１０図の入出力であれば、上記アの場合、
ｂ：例えば入力が入金伝票で、出力が売上データベースの場合なら、上記イの場合、
のように、ある動詞の幾つかの意味のうちの一つを自動的に選択することができる。この場合には、親概念の入力と出力を用いて、自動選択の論理を構成できる。

特に、
ｃ：入力が「未確認」であるならば、上記ウの場合、
但し、他の意味の場合より先に、実行する、
こととすればよく、この場合には、上記ａは、当該設計ルールの先の設計ルールに着目すれば、自動選択の論理を構成できる。

多くの他の場合も調査した結果、
親概念の入力、出力、あるいは両者、
先行する設計ルールの入力、出力、あるいは両者、
入力の情報の一部、出力の情報の一部、あるいは両者、
などを入力として自動選択の論理を構成することができる。これは、設計の進路（設計の展開方向）を決めると考えられる。特に、多くの情報群と進路（設計の展開方向）が対応することから、テーブル論理の形式で実現することが適している。この実施例では、この為のテーブルを、ＤＤＦテーブル１９６と名付けている。即ち、ＤＤＦテーブル１９６には、親概念を構成する入力、出力、先行する親概念（群）等の情報から、親概念の動詞についての意味を抽出する論理が格納されている。

ある親概念を展開して子概念を得るにあたり、当該親概念は幾つかの意味の場合があり、選択が必要である。既に説明した設計ルールの再利用による自動設計の当初は、人が選択を行なう必要があった。これに上記を組み合せることにより、自動選択が可能となった。
以上説明したように、これは、本発明の第１の目的の内、「設計知識の展開方向を自動決定」する機構が明らかになった。

次に、本発明において特徴とする「設計知識を自動生成」する機構の具体的な構成について第１３図を用いて説明する。第１３図の上部は、動詞に対応する動詞辞書１３０の各項目が示されている。動詞辞書１３０の１項目は、ある動詞のある意味に対応し、論理的にはフレーム形式の情報である。フレーム１３０ａのデータ１３１は、この場合には、データフロー図のスケルトン１３１ａおよび構造化チャートＰＡＤのスケルトン１３１ｂである。フレーム１３０のメソッド１３２は図の右端に示してある。

第１３図の中央に、更に詳細を示した。スケルトン１３１は、子概念に対応するので、設計ルールの子に対応する部分のみであり、各処理の便宜上、対応する親概念を代表する仮親（ＦＰ）で表している。これが親機能と対応することを示すために、仮親（ＦＰ）の上に親機能に対応するハッチした記号に９２を、又親機能への入力及び出力データに対応するハッチした記号９１および９２を示してある。子概念群は、機能ｆ１およびｆ２をもつ９４から９８までのデータフロー図で表した。右端のメソッド１３２の例を、第１３図の最下部に示した。

第１３図の最下部の、右の例は、親概念の入力データ（前状態のデータも含む）９１を、子概念の入力データ（前状態のデータも含む）９４に転記することを、四角の入力に転記する、と表記した。出力９３も同様である。この実施例では、構造化チャートＰＡＤでは、最大限の表記である「○○を△△に××する」を簡略化して「××する」のみで表記する為、構造化チャートの中は、変化させない。

次に、設計の進路を決める機能（ファンクションデコーダー）の構成概念について第１４図を用いて説明する。最上部は、自動生成系に入力として与えられた親概念のデータフロー図である。この機能部分９２から動詞を取出して動詞辞書１３０を検索する。

一方、親概念の入力９１と出力９３で、ＤＤＦテーブル（親概念を構成する入力、出力、先行する親概念（群）等の情報から、親概念の動詞についての意味を抽出する論理が格納された。）１９６（第１４図の右端では概念を、より詳細な例を第２５図に示す。）を検索する。この検索結果として、動詞辞書１３０に基づいて親概念の動詞部分で検索された子概念（群）の単位情報群（動詞を中心とするスケルトン１３１およびメソッド１３２から構成される。）の内から適切な、（所望の意味の場合の）単位情報を選択することが可能となる。例えば、矢印の例のように、入力９１が「売上伝票」と出力９３が「売掛ＤＢ」とで使うべき意味が決定できて、目的は「売上の更新」と推定する。これは、先に選んだ動詞の何れの意味を使うかの情報に変換され、当該動詞のもつ、例えば５つ場合の内の、指定の意味（場合）が選定される。このようにして、選ばれた辞書項目は、前記したように、メソッド１３２によりスケルトン１３１に加工を施して子概念（群）を生成することになる。メソッドの処理のパターンは、スケルトンの入出力データについて、親の入出力データあるいは親の入出力データを階層展開した細分化データを挿入すること、スケルトンの中間データを準備すること、各子機能中の記述について目的語と助詞を追加すること、などであり、その設計量は少なく、作業は容易である。更に、設計情報は、図式化されており、また記号中の記述として顕在化されていて、子の概念は全ての人に理解し易いことが上記の容易な軽度の作業を可能にしている。

設計には多様な場合が存在する。これまで、最も基本的な場合を説明した。他に各種のパターンがあるが、最も代表的な他の場合として、事務系の処理によく用いられるジャクソンプログラム法（Jackson Structured Programming）の場合を説明する。これを第１図に示す「時計」の設計例について、説明する。第１図に示すデータフロー図における第２段のデータフロー図の「時刻」および「時刻表示」は、それぞれ階層展開して、「時」、「分」および「秒」、また「時針」、「分針」および「秒針」になっている。更に、これらの入出力に対応して、機能は「時針を求める」、「分針を求める」および「秒針を求める」である。これは、上位の機能「時刻表示を求める」を階層展開したもので、データフロー図では並列的になっている。この形式の設計ルールをＪＳＰ形設計ルールと名付ける。

このように、入力データ（前状態のデータも含む）が階層展開し、出力データ（後状態のデータも含む）もまた階層展開し、両者の対応するデータを結んだ機能（群）で、上位の親概念が並列的に展開するパターンは、ジャクソンプログラム設計法の特徴である。

第１５図には、この場合の為の子概念の形成過程を示す。親概念の入出力データ９１、９３は、夫々構造辞書１０ｃを使って階層展開される。具体的には、「時刻」は「時」、「
分」および「秒」に、一方、「時刻表示」は、「秒針」、「時針」、および「分針」に展開される。このように、入出力が共に階層展開されることは、ＪＳＰ形設計ルールの場合であるので、これを検出するとＪＳＰユニットが以下のように働く。

第１６図は、第１の探索過程を示す。ここでは、出力を展開したうちの手始めとして「秒針」が選ばれ、入力側の展開結果の、「時」、「分」および「秒」を順次選んで、共通する意味の「秒」を選択した場合を示している。対応する入力データ（前状態のデータも含む）、機能、出力データ（後状態のデータも含む）を結んだデータフロー図を構成するが、機能名称は決らないから、空欄であり、これを仮機能と呼ぶ。

第１７図には、同様な探索を繰返して、階層展開結果の全ての入出力のデータフロー図ができた様子を示す。
第１８図（ａ）は、第１７図のように出来た仮機能について、たとえば、
動詞として親概念を継承して、「○○を求める」
出力側のデータを目的語として、○○に「秒針」
の２過程を経て、「秒針を求める」のように、機能の記述を完成することを、全ての仮機能について行った最終結果を示し、データフロー図の子概念ができている。子概念が複数の動詞を含む場合などには親概念でなく、スケルトンから子概念の動詞を抽出している。このデータフロー図を更に構造化チャートＰＡＤに変換すれば、ＰＡＤでの子概念が形成でき、ＪＳＰ形設計ルールを自動生成することができる。

このＪＳＰ形の処理には、幾つかの変形が用いられる。一つのパターンは、ファンクションデコーダを、動詞辞書を読み出す以前に行う。他のパターンは動詞辞書を読み出して行う。小さな特殊な処理は各メソッドに含まれ、あるいはサブルーチンである、より複雑で典型的な処理はＪＳＰユニットの名の通り、独立のプロセスとして、本体側のメソッドと協調動作させる。
以上代表的な２典型例について説明したが、これらから他の場合も相応した変形を行なうことにより、親概念から子概念を自動生成することができて、第２の目的の、「設計知識を自動生成する」ことができる。

次に、この自動生成を中心としたシステムの内部構成について第１９図を用いて説明する。直接的な入力は、親概念である親単位データフロー図１９２であり、図の中央の上部に示した。先行する祖先の親単位データフロー図は、処理中に参照される為、必要分をまとめて先祖親ＤＦＤ１９１と略記した。特に、ＪＳＰ形では、最初の親が重要であり、ＪＳＰ形の動作が始まるとＪＳＰ作業中表示１９３を付けて、識別に使用する。

図の左のＪＳＰユニット１９４は、ＪＳＰ形設計の場合の機能ユニットで、親概念の入出力データ９１、９３が構造辞書１０ｃを経由して展開され、それぞれのデータ作業領域１９４１、１９４２に記録される。親概念が設定されると、ファンクションデコードが行われ、その動作の一環として、この動作が行なわれる。

一方、親概念の動詞が抽出され、動詞辞書１３０がアクセスされ、動詞辞書の内の一群の頁が使用する候補となる。親概念の入力出力などを纏めて、ＤＤＦテーブル１９６を参照して、使用すべき動詞辞書の当該頁１３０ａが決る。次に、決った動詞辞書１３０ａからスケルトン１３１ａ、１３１ｂが読出され、スケルトン作業領域１９５ａ、１９５ｂに設定される。

ＪＳＰ形でない場合には、このスケルトン１３１に基づき、メソッド１３２が処理して子設計結果領域１９７ａ、１９７ｂに出力する。
ＪＳＰ形の場合には、ＪＳＰユニット１９４内で、夫々の入力と出力を参照して、第１７図に示す如く、仮機能を使った、原形を構成してＤＦＤ原形スケルトン作業領域１９４３に格納する。次に、これを、第１８図（ａ）に示すように、正規の機能の記述（例えば「時針を求める」、「分針を求める」、「秒針を求める」）を挿入して、ＤＦＤ子設計結果領域１９７ａに入れ、構造化チャートＰＡＤに変換して、対応するＰＡＤ子設計結果領域１９７ｂに記録する。
第６図を参照すると、以上でCreator用（自動生成エンジン）ＣＡＳＥツール部１０ｂと動詞辞書１３０を中心とするCreatorプログラム部分１０ｂａの目的、構成、および、機能を説明したことになる。これのプラットフォームであるCreator用ＣＡＳＥツールは外部的には知識ベース部１０ａと同じインタフェイスを持って動作する。

次に、単純な再利用による自動設計の為のエンジンである知識ベース１０ａにつき説明する。この中心部分である純粋の知識ベースについては、既に確立された技術であるので、本発明での特殊点である設計知識の自動選択を説明する。
本発明における知識ベース１０ａの内部は、データフロー図と構造化チャートＰＡＤに対する二つの知識ベースを持っている。データフロー図の知識ベースを検索する親情報には、親単位データフロー図の場合と親単位データフロー図中の機能の場合の２種がある。

一般にある親機能に対しては、幾つかの意味がある、すなわち幾つかの設計知識、設計ルールが対応する場合があるので、従来技術では人が選択し、指定していた。一方、既に説明したように、親機能の他に入力データと出力データを指定すると親概念の意味は確定するから、使うべき設計知識、設計ルールは確定する。そこで、設計知識の自動選択が必要なのは、次ぎの２種の場合である。

構造化チャートＰＡＤの知識ベースを索引する時
データフロー図の知識ベースを親機能で索引する時
ここで前者は、設計過程でソースコードに近づきデータフロー図を使わず構造化チャートＰＡＤのみで設計する場合などである。後者は、親単位データフロー図で索引したが該当する答えが無い場合に起こる。

本発明では、Creatorと同技術でこの選択を自動化する。その構成は第１４図で動詞辞書（Verb dictionary）１３０を知識ベースと置換えたものになる。索引する親情報は親単位データフロー図であり、親機能で知識ベースを索引する一方、親の入出力データ９１、９３はＤＤＦテーブル１９６を索引して、使用すべき意味を知り、知識ベースから得られる候補の内の対応する候補を選択してＣＡＳＥツール側に返送する。以上のようにして、実用上の問題が無い程度に「従来方式では人の選択」に依存していた作業を自動化できる。
以上で、本発明の中心課題であるソフトウエア設計の自動化について、基礎となる人の設計の特性の分析、それに基づく解決の原理、手段、および作用について説明した。以下は、これらに関係する本発明の特徴の幾つかを説明する。

自動設計に関係するその他の機能として、自動生成機能と単純な再利用の為の知識ベースの連携機能がある。これは、処理ステップが長く、従って処理時間をより多く要する自動生成の結果の設計知識を、ＣＡＳＥツール２０が自動設計すると同時に知識ベース１０ａに蓄積させることにより、２度目以降の使用に対してより高速に設計知識を得ようとするものである。この目的の為、統合部３０では自動生成された設計知識を自動設計の指示と共にＣＡＳＥツール２０に与えると同時に、その設計知識を蓄積指令と共に知識ベース１０ａにも与える。統合部３０には、この情報をCreator ＣＡＳＥツール１０ｂから知識ベースに伝える経路を設けてある。

統合部３０は、複数のＣＡＳＥツール２０と複数のエンジン群１０を作動させる為の手段が各種設けられている。複数のＣＡＳＥツール２０を正しく同期して動作させる為、統合部３０ではＣＡＳＥツール２０からの情報の照合を行う。

また、人がデータフロー図ＣＡＳＥツール２０ｂで作画すると、その結果は知識抽出指令により統合部３０に送られ、これを構造化チャートに変換されて自動設計指令と共に構造化チャートＣＡＳＥツール２０ｃに与えられ、追随作画される。逆に、構造化チャートで先に作画する時には逆の変換を行って、データフロー図に機能（群）を自動作画させ、手間を減らしている。

以上説明したように、本発明の実施の形態によれば、次に説明する各種の運用ができる。

本発明に係るシステムとしては、設計者がＣＡＳＥツール群１０を用いて、図面を作画することから始まり、ＣＡＳＥツール群１０上に設計結果を表示する。この間に、例えば、作画結果をファイルに蓄え、これを読出して動作させる、あるいは、自動設計結果をファイルに蓄積して、後刻に図面を表示させる、等の通常のＣＡＳＥツールと同様な各種の運用が可能である。

しかし、本発明の方式では、設計の上流から下流まで一本化した方式であり、小さな進行段階毎にデータフロー図と構造化チャート（フローチャート）を記録するから、人手作業時の誤りが大幅に減少する。

更に、知識ベースを用いる再利用による自動設計（具体的には、特開平１０−３２０１８８号公報）と併用可能なシステムになっているから、本発明の設計進路を自動決定する機構を組合せて、繰返し設計が中心である保守設計フェーズの業務に適用して、小さな準備労力により大きな設計自動化効果を享受でき、上記発明では人手作業であった同一動詞の複数の意味の選択を自動化できる。

また、本発明の方式によれば、少数のスケルトン１３１と簡単なメソッド１３２を基礎的な設計知識として用い、親概念が与えられる度に、更に上位の設計知識である設計ルールを自動生成でき、予め基礎的な設計知識を準備した範囲で、再利用の場合と異なり、最初から高い自動化率で自動設計を享受することも可能である。すなわち、本発明の方式は、各種の使用状態に応じて最適な運用方式がとれる高い適合性を持っている。

これまで説明した実施の形態は、自動生成方式の原理的な基本の構成であり、各種多様な拡張が可能である。

上記のＪＳＰユニットは、スケルトン中のメソッドと協調動作する構成であったが、簡単な場合の適用に限定すれば、ＪＳＰユニットの中心機能を各メソッドに持たせる簡略版が可能である。

また、上記の実施の形態では、機能の記述として模範形と簡略形とを説明したが、更に高度な表現も可能である。

また、本発明の実施の形態として、第１５図ないし第１８図（ａ）で、「時」と「時針」のように単純な対応関係がある場合を説明したが、現実の設計では、必ずしもこのような単純な関係でない場合があり、全てをメソッドで対処しがたい場合がある。この場合には、認識ユニットを別に設けて単位的な項目を定義した辞書を介在させ、処理論理を設けることによって、入力側データ（例えば時）と出力側データ（例えば太い針）の両データの対応を認知できる用語の拡大を可能にすることができる。これは知識ベースによる技能レベルの方式、スケルトンを用いる「ルールのレベル」の方式に対し、このような単位的な知識を用いる方式は「知識レベル」の方式と考えられる。このことにより、本発明は、上記のような辞書的な知識を併用して簡単に効用を大幅に増すことができる。

また、本発明の実施の形態として、第７図および第８図では、入力帳票、出力帳票、およびファイルが固定しており、また、これがフレーム形記憶と考えてＲｏｏｔに統合した場合を示し、階層的なデータのみについて構造辞書として持つ場合を説明した。帳票類の処理は、当該帳票の構造の記憶とともに含めた方がよい場合が多い。この場合にはフレーム形記憶のデータ部分にはデータ構造を、またメソッド部分では上記の処理（例えば小計など）を受け持たせる。

例えば、実施例として、帳票の中に、品名、単価、数量と小計、およびこれらの合計の記載がある場合について動詞辞書のメソッドで処理する方式を説明したが、入力帳票は、処理に先立ち確認をする必要があり、例えばマスターファイル中に登録されている項目との一致を調べる。この場合には、スケルトンとして親概念から引き継いだ入力の他に、参照ファイルもスケルトンのデータフロー図も入れる。（同様にして、処理履歴を蓄えるジャーナルファイルなども、スケルトンの出力部分に付加することができる。）
小計は、単価と数量を乗じて求めた結果と、記載事項とを照合する。合計は、１帳票内に閉じて、小計項目を累算し、合計として記載した事項と照合する。簡単な場合には、動詞辞書１３０から得たメソッドで処理でき、また、それが有利である。

出力帳票は、１帳票に閉じず、各種の参照情報を多様に使う。この場合には、出力帳票（ファイル）の記載項目から必要な参照情報と処理の方式が決まる。親概念の入出力から得た概念がこれらを規定すると考えてメソッドで処理することは、メソッドが大きくなる。これらの出力処理の詳細は、本質的に出力帳票に依存するので、当該データに対応するメソッドを設ければ、これに、各項目の定義、あるいは出力を得るための処理を定義できる。あるいは、このような独立の部分的なエンジンを本体側メソッドと協調動作させることも可能である。これにより、動詞辞書中のメソッドも簡単であり、帳票毎のメソッドも簡単になる。

また、本発明の実施の形態として、構造辞書ＣＡＳＥツールを用いる。入出力情報が固定した場合を説明した。固定していない場合については次のように対応できる。

スケルトンについて、設計経験を重ねる過程で、抽象化して得られるのと同様に入力および出力の構造も成長させて最終的に固まるようにすることができる。現在の事務処理系プログラムの入出力では、永年の経験の蓄積から、基本形はほぼ標準化されている。また、熟練者は、各処理のプログラムを設計するに先立ち、必要な入出力の帳票やファイルを決める。

初心者あるいは未経験領域で設計する時には、帳票やファイルの基本構成から設計を始め、必要が判明した場合に、帳票やファイルに新規項目を追加する。これと同様に、設計を進めることと並行して入出力のデータ構造を追加修正する機構を組合せることもできる。

また、本発明の実施の形態では、人の知的処理の中の概念の象徴として、最も汎用的な自然言語を用いて説明したが、設計情報が階層展開を重ね、最も単位的になった時、自然言語表記を親とし、子がプログラム言語によるソースコードである設計ルールを使えば、最終結果としてプログラムを得ることができる。また、それ以前の段階でも、自然言語以外を用いることができる。例えば、「斜辺の長さの二乗は、垂辺の長さの二乗と底辺の長さの二乗の和である」ことは、Ｓ^２（斜辺の長さの二乗）＝Ｙ^２（垂辺の長さの二乗）＋Ｘ^２（底辺の長さの二乗）と同じに扱える。これは、本発明が、単にプログラムといった視点でなく、人の意図的行動全体を視野に入れ、人の概念そのものを扱う立場を採ることによる。

本発明は、このような各種多様な拡張と高度化が行なうことができる。これは、ＺipfやRasmussenの指摘している人の各レベル毎の多種類の設計エンジンに対応するものである。

Ｚipfの法則によれば、作業の多くを占める簡単な作業は、簡単な方式であり、高速に処理され、一方頻度の低い高度な作業は、高度な方式で時間を掛けて処理する。単純な再利用は前者に、本発明にかかる設計ルールを自動生成する方式は、後者にあたる。これは、人の設計を極力忠実に、ボトムアップに研究する方策の結果として、最も簡単な方式がまず取出され、次いで、高度な方式の原形が得られた。

先の実施の形態では、単純な再利用と最も単純な自動生成を説明したが、統合部３０に標準化したインタフェイスで接続するエンジン群１０として更に多種のエンジンを設けることが可能である。

次に、複類種のエンジンを設けるとき、エンジン相互間の協調動作により更に効率化をはかることが可能になる。自動生成された設計ルールを、再利用のための記憶、知識ベースに格納していけば、同一の親概念に対して、２度目からは再利用になり、高速に処理される。

これらの動作をおこなう為の不可欠な機能は自動生成した設計知識を知識ベースに記憶させることであり、例えば本実施例では、統合部３０で、Creator用ＣＡＳＥツール１０ｂで自動生成した設計知識、設計ルールを知識ベース１０ａに与え蓄積させる。機能的な入出力インタフェイス３５も同一にしてあるから、各種の組合せが可能である。人の分散的な処理に倣えば、親概念を同時に与え、先に子概念を回答した方を採用する方式が可能である。単一のプロセッサーで処理するなら、まず、再利用を試み、不可の場合に自動生成を行う方式になる。

ところで、再利用のための記憶量が多いため、磁気記憶装置を用いる場合には、再利用によると処理時間は却って大きくなる。そこで、これに依存する度合いを減じる方が有利である。

これを最も簡単に実現するには、再利用のための記憶を複数階層に構成して、頻繁に使われる設計知識、設計ルールを高速な主記憶に、頻度の少ない設計知識、設計ルールを低速ではあるが、大容量化に向いた磁気記憶装置などに収容させれば良い。これはプロセッサーに付属した機構を使って実現することができる。

本発明に係るスケルトン１３１やメソッド１３２は、実際的な配慮から既存設計の技術を活かして、事前準備する場合を説明したが、設計ルールの例を与えることを繰返し、共通する情報スケルトンを生成し、また、如何なる場合にどのように処理するのかを示すメソッドを生成する、抽象化機構を形成することができる。

そこで、これを組合せれば、設計ルールを経験する度に、再利用のための記憶と並行して抽象化機構に与えて行けば、各種の変形の経験の蓄積とともに、スケルトンやメソッドが生成され、蓄積されていき、自動生成能力が自動的に向上していく。

この機構が働けば、低頻度の設計ルールの全てを再利用のために記憶する必要はなく、より少ないスケルトンとメソッドを記憶して、再度の利用に備える方が有利である。

第２６図はその詳細を示すもので、電子通信情報学会論文誌８５．Ｄ巻１号２２１．２３２ページの論文 Software Creation: Clich. as intermediate knowledge in software designの図９を日本語化したもので、スケルトンとメソッドを作り出す機構を示す図である。第２６図の左上は設計の度に加えられる人あるいは各種のエンジンが設計した設計ルール２５０が入力される。この動詞部分で設計ルール記憶２５１に参照する。これは本発明のシステムでは設計ルールを蓄える知識ベース１０ａで良い。動詞を同じくする蓄積済み設計ルールを読み出した結果２５２が中間に示されている。これらは新たに到来した設計ルール２５０とともに「抽象化してスケルトンをえる原形に戻す設計ルールをえる」機能において、各個に照合比較される。設計ルールのスケルトン対応部分を見れば、入出力などのデータを抽象化して最下部に示す新しいスケルトン２５４が簡単に得られる。また、同様にメソッド２５５も得られる。これらはごく簡単な数種しかないから抽象化やルール作成は簡単である。作られたスケルトンとメソッドの対は動詞辞書２５６に記憶させる。

図２７は、簡単な在庫管理システムを設計して効果を調べた結果を示す図である。横軸は設計作業中に行う階層展開数を、また縦軸はこの時に新しく作った設計ルール数などを示す。図の下の破線のグラフは、上記のように作られた辞書ページ数の総数を示し、実線のグラフはこのように新たに作られた動詞辞書を参照して設計ルールを作ったのべ回数を示す図であり、直線的に伸びている。このように、ごく簡単な機構で学習し、また効果がある様子が明白である。

このように、設計を経験する度に、その全情報を知識ベースに蓄えて以降必要に応じて高速に応答できるほか、経験を抽象化して新しい、より上のレベルの能力と知識を作り上げていく。これを組合せた統合知的ＣＡＳＥツールは、人に使われる内に設計の低次の知識から行動の能力を付けていく。これは本発明のシステムが人の知と同じ基礎を持つことによるものである。

これは、第６図のシステムで云えば、全てのエンジン群１０で生成された設計ルールはＣＡＳＥツール群２０に返送するが、この情報を利用する統合部３０の標準インタフェイス３５に接続して、この情報を第２６図に示す抽象化機構に加え、図に示す動詞辞書を自動生成用エンジンと共用させる。

このように、本発明の方式は、人間の設計に関する学習のメカニズムを含むものである。

これらの機構単位の最適化は、再利用の機構、自動生成の機構、抽象化の機構について、人の設計を考慮すれば、各種各様な方式で構成することができる。

このような、概念の階層展開は、人の最も基本的な知的処理である。ここでは、ソフトウエアの設計の場合を説明したが、一般の設計のみ拡張することができることは明白である。実用レベルにある例は、ハードウエア論理設計には、プログラム言語の記述を生かした高級言語が使われ、これを駆使するスーパーコンピュータの設計は殆どプログラムの設計と差のないレベルに達しており、もっと身近な例を挙げると、第１図の「時計」の設計はそのままハードウエアでも実現できる。ソフトウエアの例を中心に説明したが、ビジネスプロセスも１種のソフトウエアとして取組む研究を進展している。そこで云われるビジネスフローはデータフローと基本的に同じであり、上位では情報や状態などのような抽象性が強く、下位に下るにつれて具体性を増し、中間には明確な切れ目はない。本発明で扱ったデータはこのような抽象度が高い場合にも適用できる。勿論量的には下位のプログラム段階の工数が大きい比重を占めるが、本発明のように、全体を通じて変わらない階層展開の観点から見ると、トップの決断からソースコード化までの全過程を一本化して統一的なシステムで扱うことができる。

以上のように、本発明の設計知識の自動生成は、実は人の意図的行動の全てに適用できる。

更に、本発明の実施の形態についての効果の定量的評価について説明する。即ち、設計ルールには、習熟効果がある。これを習熟性工学により評価すると、自動化の進化や自動化による設計工数の低減などを定量的に評価できる。

第２０図は、構造化チャートを用いる設計について、人の設計から設計知識を自動獲得し、これを知識ベースに蓄えて、再利用して、詳細な研究を行った結果を示す図であり、これは、IEICE Trans.,Vol.E81-D,No.12,pp.1439-1449,1998年12月に発表した論文’Software Creation: An Intelligent CASE Tool Featuring Automatic Design for Structured Programming’の図７ｂを日本語化したものである。本発明の方式は、蓄積し再利用することにより自動化されるから、同種の設計を繰返す保守段階での設計で評価した。図の横軸は、新設計から保守設計の繰返しの回数を示し、縦軸はその回数の設計で、全体の階層展開の内で自動的に行えた比率を示す。

カーブは、初めに急速に立上り、１０回目では８０％以上が自動展開されることを示している。これは習熟効果によるもので、比較的少数の設計知識が繰返し使われることを示している。しかし、回数を重ねてもなかなか１００％に近づかない。これは、単純な再利用では知的な度合いが低いことの反映である。
本発明は、同領域を構造化チャートのみでなくデータフロー図も併用する方式で、所謂プログラミング段階以前にも適用を拡大するものであり、本質的に、この図と同等以上の効果を出す。すなわち、繰返しの多い保守設計の上流から下流を通じて大きな効果を挙げることができる。

第２１図は、Ｃｒｅａｔｏｒのみ、即ち設計知識の自動生成のみの場合の評価を示す。図の横軸は設計を行った場合の階層展開数であり、縦軸は動詞辞書の累計ページ数を両対数尺度で評価したものである。この図では、習熟効果は直線状の傾向線として現れる。第２の直線傾向線により実績を評価した所、約５００行、約１０プログラム、１００階層展開を設計するに要した動詞辞書の累計ページ数は約２０であった。このシステムで、約５０００行、すなわち１１０プログラム、新たに１０００の階層展開を経験する設計を行った場合には動詞辞書の累計ページ数は第２１図の第２の傾向線から読取ることができて、約４０と見込まれるから、約２０ページの追加が必要と予測される。これは自動化率にすると、１０００展開の内、２０回の階層展開について動詞辞書１３０のページの追加が必要であることを示し、この値から自動化率は９８％と評価できる。すなわち、本発明方式の自動生成機能は自動化率が高く効率向上の効果が大きい。

自動化システムでは、効果の他に自動化する為の準備等のコストを評価する考え方がある。このシステムではCreator ＣＡＳＥツールなどの固定分と動詞辞書のページ当りのコスト×必要ページ数が、自動化の準備のコストになる。本文で説明したように、固定分はCreator ＣＡＳＥツール１０ｂで動詞辞書１３０やＤＤＦＴ１９６を作動させる機能部分のみであるから、従来の自動化方式に比べて格段に小さく、更に動詞辞書１３０は基本的な部品であるので、必要なページ数は小さく、従来の自動生成方式で適用対象毎に準備する知識数に比べて大幅に少数であるのみならず、各ページ当りの準備作業は少数のスケルトンとメソッドで小さなものである。以上から、本発明は自動化の為の準備コストが極めて少なくて済む。

本願の初めに説明した知識ベースを用いる方式はRasmussenの定義によれば「技能レベル」、次に説明したスケルトンによる方式は「ルールレベル」に属する。彼の定義する最後は「知識レベル」である。これを組合せるとこれまでの方式では不可能であったより高度な問題の解決ができる。この要素技術は、電子通信情報学会論文誌８３．Ｄ巻４号６４８．６５８ページの論文’Software Creation: A study on the inside of human design knowledge’で詳細に報告している。本願に関わる要点は次の通りである。

「知識レベル」の中心は，基礎知識辞書と名付けられた辞書的な知識の体系であり、辞書には、概念、データ構造、書式などの構造、動詞などの辞書がある。更に、これを駆使する単位的な知的処理マイクロデザインルール（単位機能論理）がある。

以下簡単にこれらを説明する。先に第１５図〜第１８図（ａ）でＪＳＰ形の設計を説明した。図のように定型的な処理では、動詞辞書から読み出したメソッドおよびこれと協調する専用論理が処理する。これでは処理できない場合には、マイクロデザインルール（単位機能論理）はこれらの辞書を駆使して主として各種の関係の確立を行う。

すなわち、親の入力と出力データを展開した子データの組合せを作る場合、第１８図（ｂ）のように時刻表示が「太針」「長針」「細針」に展開されると、「時」を展開した子データと「時刻表示」を展開した子データの同一性は認識できない。しかし、概念辞書に「太針」と「時」、「長針」と「分」、「細針」と「秒」との関係付けがなされておれば、基礎知識辞書を用いて対応関係を知るマイクロデザインルールChain Concept Definition（ＣＤＣ）の助けを借りて子データ同士の関係を設定できる。

このようにメソッドでは処理できない場合に、知識レベルに移行し、マイクロデザインルールが処理する。先の第１５図の説明では、時刻と時刻表示は構造辞書を参照して子に展開した。これができない時、マイクロデザインルールではEXtend Concept（ＥＸＣ）マイクロデザインルールが、基礎知識用の辞書を用いて行う。次の第１７図のように子概念の為の子データフロー図群を作ることが出来ない時は、Upwarding Correspondance（ＵＣＳ）マイクロデザインルールが基礎知識辞書のデータ構造定義を参照して行う。更に第１８図（ｂ）のように、空き機能箱に子概念の動詞部分の表記を挿入することはCreate Function Name（ＣＦＮ）マイクロデザインルールでバックアップされる。他にマイクロデザインルールには、Concept Abstraction（ＣＡＢ），Select I-map and O-map（ＳＩＯ），Create Control Structure（ＣＣＳ）などがあり、何れも通常の処理が出来ない時には、基礎知識辞書を参照して、全ての可能性を調べる。

このように、基礎知識辞書を辞書を使うマイクロデザインルールは設計可能な範囲を飛躍的に増大させる効果をもつ。

具体的な実施例は以下のとおりである。第１９図に示すエンジンの構成において、上記の基礎知識用の辞書を設けて、上記の専用論理を作り、ここでマイクロデザインルールの機能を実行させる。動詞辞書のメソッドにより、あるいは専用論理の第１６図から第１７図の過程に於て、入出力データ間の対応が簡単に確立できなかった場合にマイクロデザインルールの機能を果たす専用論理と協調動作させる。

第２８図は、第２７図で説明した在庫管理プログラムの７プログラムの初期設計でのプログラム数を横軸にとり、縦軸に累計定義数を示す図で、各種のグラフは７プログラムの作業順番を変えたものである。図に見られるように、対数習熟特性が明確である。すなわち、プログラム数を増しても定義数は緩やかにしか伸びない。言換えると、少数でも辞書知識を増せば設計可能なプログラム数は大幅に大きくなり、その増加は対数的である。

スケルトンと組合せる動詞辞書の場合にはスケルトンは動詞に具体的な場所などの記号を追加したものであり、メソッドは５Ｗ１Ｈを示すために動詞に加える変形のパターンである。ある動詞について定型的な文法知識を与えれば動詞辞書の意味毎のページを作れる。また、スケルトンと組合せ用いる構造辞書は、同様にしてデータ構造、書式などの構造データから発生できる。

すなわち、ここに説明した辞書からスケルトン方式での必要知識を作れる。逆に構造辞書や動詞辞書から、マイクロデザインルールに併せ用いる基礎知識辞書類を準備できる。それは設計ルールから抽象化してスケルトンとメソッドが作りえることと同様である。

実施例では次のようになっている。各種の方法の内、第２６図の「抽象化してスケルトンをえる」２５３では、各設計ルールからスケルトンが作られる。ここでは親概念から子概念が作られるので、これを取出して基礎知識用辞書に蓄えさせる。

これは、歴史的、遺伝的に最適化された人の頭脳の機能構成を模式化して取出していることによるものである。本発明の方式は、単に設計に留まらず、人の意図的な行動、例えばソフトウエアシステムの前段階にあたる所謂ビジネスプロセスの自動化方式、ハードウエア設計の自動化方式などの適用に拡大できる。人間のような高度の知能を備えたロボットをヒューマノイドと云うが、この方式はそれに用いる中核的な知のセンターとなる。従来のプログラムでロボットを駆動する場合には、ロボットから離れてプログラムを設計してロボットに供給して動作制御させる。このシステムでは、当初の意図例えば「右を向く」から出発して、その意図を詳細化して最後は（実現手段である）各種のアクチュエータを駆動する所に至ることができる。

第６図を用いて説明する。ソフトウエア設計でこのシステムを用いる時、図の左端には設計者がおり、ＣＡＳＥツール２０と自働化機能を用いながら設計する。そして、設計してソースコードになったファイルはＣＡＳＥツールから取出され、コンパイラーを経由してコンピュータでのプログラムの実行に移る。
ロボットでは以下のようになる。外界からの入力は各種のセンサーにより検出され、処理され、判断される。ここまでは前記の設計者の働きにあたり、本システムの外である。例えばロボットが「右を向く」意図を持った時点以降が、このシステムの受け持ちになる。「右を向く」意図は、設計者がＣＡＳＥツールに図面で指示するように、ＣＡＳＥツールに書き込まれる。これは「時計」の例で説明したように、階層的に展開されながら、実現手段であるところの体の動きの詳細指令に変換される。この場合には、コンパイラを経由あるいは経由せずに、ロボットの体の各部のアクチュエータに指示が与えられる。そこで、ロボットの動作が行われる。

これらの間でのＣＡＳＥツールの機能は、仮想的に動作すれば良い。ロボットあるいはその機能の追加の為の開発では、ＣＡＳＥツール機能を活かせば、オンラインで詳細化される様子を可視化でき、また直接に展開を修正し変更できる。これは従来のロボット制御技術ではできなかったことである。

本発明では、最も簡単で具体的な例として、ソフトウエア設計の例を詳細に説明し、意図達成の最も判り易い例として、ロボット制御への実施例を簡単に説明した。これらの両極端の中間には多くの適用がありえるが、その何れに於ても「意図の達成」の概念で、本発明を利用することができる。

これらから、従来方式での意図の達成あるいは設計に比べてコスト／パーフォーマンスが格段に良く、更に人の意図的な行動全般に適用できる特徴がある。更に、人の設計作業を行うにあたり、本システムを併用すれば、「技能レベル」の知識はそのまま蓄え、「ルールレベル」の知識は自ら抽象化して動詞辞書に蓄え、更に「知識レベル」の知識は基礎知識用辞書に蓄え、初心者が熟練者に教育されるように知識を蓄え技術を向上させることができる。

以上のように、本発明に係る設計知識の自動生成方法およびそのプログラム並びに自動設計方法およびそのシステムは、具体的なプログラム、ソフトウエア、ソフトウエアシステム、ビジネスシステム、更には例えばロボットなどの如く人と同様な動作をするシステムなどの与えられた目的を展開して詳細化する上流の段階から与えれた機能をソースコード化する下流の段階までの自動的な展開あるいは設計および人による設計の支援として用いるのに適している。

また、本発明によれば、作業を自動化することにより人の設計作業を軽減させる、言換えれば、生産性を向上させることができる。すなわち、人の設計では１階層展開あたり少なくとも分の桁の時間が掛かるが、自動設計では多くとも秒の桁の時間しか掛からない。そこで、上記効果は自動化によりもたらされる。
また、本発明によれば、設計知識を自動的に生成し、生成した設計知識ベースと既に蓄積された設計知識ベースを再構成して高い自動化率で動作する自動設計を実現することができる。
また、本発明によれば、各種の設計知識エンジンの利用と、人間とのインタフェイスとなる図面作成と表示のシステムを統合的に実現することができる。

第１図は本発明に係る自動設計システムにおける基本とする人の設計作業結果の図であり、設計知識の獲得および再現の原理を説明する図。 第２図は本発明に係る設計知識、設計ルール、すなわち親から子への概念の階層展開を示すデータフロー図。 第３図は本発明に係る構造化チャート（フローチャート）を示す図。 第４図は本発明に係る親データフロー図、およびこれを貼付けた子データフロー図。 第５図は親機能およびこれに貼付けた子機能を示す構造化チャート、ＰＡＤの図。 第６図は本発明に係る自動設計システムの一実施例を示す模式図。 第７図は本発明に係る構造辞書ＣＡＳＥツール部の機能を説明するための図。 第８図は本発明に係るCreator ＣＡＳＥツール部の知識の基本構成を示す図。 第９図は本発明に係るスケルトンを売掛の場合について説明するための図。 第１０図は本発明に係るスケルトンを買掛の場合について説明するための図。 第１１図は本発明に係る抽象化された共通するスケルトンを説明するための図。 第１２図は本発明に係る構造化チャート（フローチャート）を示す図。 第１３図は本発明に係る設計の為の基本知識を説明するための図。 第１４図は本発明に係る「設計の進路を決める機能」の構成概念を説明するための図。 第１５図は本発明に係るジャクソンプログラム設計法におけるファンクションデコードの一部を示す図。 第１６図は第１５図において、第１の検索過程を示す図。 第１７図は第１６図に示す検索を繰返して、階層展開結果の全ての入出力間を結ぶデータフロー図ができた様子を示す図。 第１８図（ａ）は機能の記述を完成することを第１７図に示す全ての仮機能について行った最終結果を示す図および第１８（ｂ）はマイクロデザインルールを適用して設計した実施例を示す図。 第１９図は本発明に係る自動生成を中心としたシステムの内部構成を示す図。 第２０図は本発明に係る再利用による自動設計の評価結果である、全体の階層展開の内で自動的に行えた比率を示す図で、横軸は、新設計後に同一領域で設計の繰返し（保守設計）の回数を示し、縦軸はその回数のうち再利用による自動展開が行なわれた比率を示す。 第２１図は本発明に係る設計知識の自動生成のみの場合の評価を示す図で、横軸は設計を行った場合の階層展開数の累計を対数尺度で示し、縦軸はある点までの自動生成をするのに必要とした動詞辞書の累計ページ数を対数尺度で示す。 第２２図は本発明に係る入力の確認を必要とする場合の設計ルールの例を示す図。 第２３図は本発明に係る入力を加算する場合の設計ルールの例を示す図。 第２４図は本発明に係る入力を差引く場合の設計ルールの例を示す図。 第２５図は本発明に係るＤＤＦＴの一実施例を示す図。 第２６図は本発明に係るスケルトンとメソッドを作り出す機構を示す図。 第２７図は本発明に係る簡単な在庫管理システムを設計して効果を調べた結果を示す図。 第２８図は第２７図で説明した在庫管理プログラムの７プログラムの初期設計でのプログラム数と累計定義数との関係を示す図。

Claims (20)

1. 親概念と該親概念から展開される子概念（群）との対を単位的知識とし、該単位的知識を順次展開することを繰返して詳細化された意図達成又は設計の知識を得る自動生成方法であって、
   親概念から展開された子概念（群）の動詞を中心とするスケルトンおよび該スケルトンに作用して子概念の宣言を完成する処理論理とから構成される単位情報の群を記録したルールベースである動詞辞書を用意するステップと、
   親概念を構成する出力若しくは後状態、入力若しくは前状態および先行する親概念（群）の情報を元に親概念の動詞についての意味を選択する論理が格納されたＤＤＦテーブルを用意するステップと、
   入力して与えられた親概念のデータフロー図における機能部分から取り出された動詞で前記動詞辞書を検索して前記親概念から展開された子概念（群）の単位情報の群を取得し、該取得された単位情報の群から前記ＤＤＦテーブルに格納された論理によって対応する単位情報を選択し、該選択して得られる単位情報から前記処理論理を得て親概念と対になる子概念（群）を展開して完成する処理を有し、該展開される子概念（群）中の各機能（群）を新たな親概念の入力として順次展開して前記詳細化した意図達成又は設計の知識を得る知識生成ステップとを有することを特徴とする知識の自動生成方法。
2. 親概念と該親概念から展開される子概念（群）との対を単位的知識とし、該単位的知識を順次展開することを繰返して詳細化された意図達成又は設計の知識を得る自動生成方法であって、
   親概念から展開された子概念（群）の動詞を中心とするスケルトンおよび該スケルトンに作用して子概念の宣言を完成する処理論理とから構成される単位情報の群を記録したルールベースである動詞辞書を用意するステップと、
   親概念を構成する出力若しくは後状態、入力若しくは前状態および先行する親概念（群）の情報を元に親概念の動詞についての意味を選択する論理が格納されたＤＤＦテーブルを用意するステップと、
   入力して与えられた親概念のデータフロー図における機能部分から取り出された動詞で前記動詞辞書を検索して前記親概念から展開された子概念（群）の単位情報の群を取得する検索ステップと、該検索ステップで取得された単位情報の群から前記ＤＤＦテーブルに格納された論理によって対応する単位情報を選択する選択ステップと、該選択ステップで選択して得られる単位情報から前記処理論理を得て親概念と対になる子概念（群）を展開して完成する処理ステップとを有する処理を有し、該展開される子概念（群）中の各機能（群）を新たな親概念の入力として順次展開して前記詳細化した意図達成又は設計の知識を得る知識生成ステップとを有することを特徴とする知識の自動生成方法。
3. 請求項２記載の知識の自動生成方法において、更に、前記知識生成ステップで得られた詳細化した意図達成又は設計の知識を知識ベースに蓄積する蓄積ステップを有することを特徴とする知識の自動生成方法。
4. 請求項１記載の知識の自動生成方法において、更に、入力帳票、出力帳票及びファイルなどの情報の階層的な構造を定義する構造辞書を用意するステップを有し、
   前記知識生成ステップにおける前記処理において、専用論理に基づいて、前記構造辞書を参照して、入力して与えられた親概念のデータフロー図における出力あるいは後状態を階層的に展開した子出力情報を出力側データ作業領域に作り、前記親概念のデータフロー図における入力あるいは前状態を階層的に展開した子入力情報を入力側データ作業領域に作り、前記作られた子出力情報と該子出力情報に対応する前記作られた子入力情報との組合せをＤＦＤ原形スケルトン作業領域に作り、前記親概念のデータフロー図における機能部分から取り出された動詞又は前記親概念から展開した子概念の動詞を継承して、前記作られた組合せの機能部分に挿入して子データフロー図を形成し、該形成された子データフロー図から子フローチャートまたは子構造化チャートを得て、親概念と対になる子概念（群）を展開して完成する処理を含むことを特徴とする知識の自動生成方法。
5. 請求項２記載の知識の自動生成方法において、更に、前記知識生成ステップで得られた詳細化した意図達成又は設計の知識を知識ベースに蓄積する蓄積ステップと、前記知識生成ステップで得られた詳細化した意図達成又は設計の知識と前記蓄積ステップで蓄積された詳細化した意図達成又は設計の知識とを選択する選択ステップとを有することを有することを特徴とする知識の自動生成方法。
6. 請求項２記載の知識の自動生成方法において、更に入力帳票、出力帳票及びファイルなどの情報の階層的な構造を定義する構造辞書を用意するステップを有し、
   前記知識生成ステップにおける前記処理において、専用論理に基づいて、前記構造辞書を参照して、入力して与えられた親概念のデータフロー図における出力あるいは後状態を階層的に展開した子出力情報を出力側データ作業領域に作り、前記親概念のデータフロー図における入力あるいは前状態を階層的に展開した子入力情報を入力側データ作業領域に作り、前記作られた子出力情報と該子出力情報に対応する前記作られた子入力情報との組合せをＤＦＤ原形スケルトン作業領域に作るＤＦＤ原形スケルトン作成ステップと、前記親概念のデータフロー図における機能部分から取り出された動詞又は前記親概念から展開した子概念の動詞を継承して、前記作られた組合せの機能部分に挿入して子データフロー図を形成するＤＦＤ形成ステップと、該ＤＦＤ形成ステップで形成された子データフロー図から子フローチャートまたは子構造化チャートを得て、親概念と対になる子概念（群）を展開して完成する処理ステップとを含むことを特徴とする知識の自動生成方法。
7. 親概念と該親概念から展開される子概念（群）との対を単位的知識とし、該単位的知識を順次展開することを繰返して詳細化された意図達成又は設計の知識を得る自動生成方法であって、
   親概念および該親概念を展開した子概念（群）との対を単位情報として知識ベースに蓄積し、親概念を構成する出力若しくは後状態、入力若しくは前状態および先行する親概念（群）の情報を元に親概念の動詞についての意味を選択する論理をＤＤＦテーブルに格納して用意するステップと、
   入力して与えられた親概念のデータフロー図における機能部分から取り出された動詞で前記知識ベースを検索する検索ステップと、該検索ステップの検索で取出される前記親概念から展開された子概念（群）の単位情報の群を取得し、該取得された単位情報の群から前記ＤＤＦテーブルに格納された論理によって対応する単位情報を選択することによって親概念から展開された子概念を得る選択ステップとを有する処理を有し、前記得られた親概念と親概念から展開された子概念との対からなる単位的知識を順次展開することを繰返して前記詳細化された意図達成又は設計の知識を得る知識生成ステップとを有することを特徴とする知識の自動生成方法。
8. コンピュータによって、親概念と該親概念から展開される子概念（群）との対を単位的知識とし、該単位的知識を順次展開することを繰返すことにより、詳細化された意図達成又は設計の知識を得るための自動生成プログラムであって、
   親概念から展開された子概念（群）の動詞を中心とするスケルトンおよび該スケルトンに作用して子概念の宣言を完成する処理論理とから構成される単位情報の群を記録したルールベースである動詞辞書と、親概念を構成する出力若しくは後状態、入力若しくは前状態および先行する親概念（群）の情報を元に親概念の動詞についての意味を選択する論理が格納されたＤＤＦテーブルとを用いて、
   入力して与えられた親概念のデータフロー図における機能部分から取り出された動詞で前記動詞辞書を検索して前記親概念から展開された子概念（群）の単位情報の群を取得する検索ステップと、該検索ステップで取得された単位情報の群から前記ＤＤＦテーブルに格納された論理によって対応する単位情報を選択する選択ステップと、該選択ステップで選択して得られる単位情報から前記処理論理を得て親概念と対になる子概念（群）を展開して完成する処理ステップとを有する処理を施すことにより、該展開される子概念（群）中の各機能（群）を新たな親概念の入力として順次展開して前記詳細化した意図達成又は設計の知識を得るための知識の自動生成プログラム。
9. 請求項８記載の知識の自動生成プログラムにおいて、更に入力帳票、出力帳票及びファイルなどの情報の階層的な構造を定義する構造辞書を用いて、
   前記施す処理において、専用論理に基づいて、前記構造辞書を参照して、入力して与えられた親概念のデータフロー図における出力あるいは後状態を階層的に展開した子出力情報を出力側データ作業領域に作り、前記親概念のデータフロー図における入力あるいは前状態を階層的に展開した子入力情報を入力側データ作業領域に作り、前記作られた子出力情報と該子出力情報に対応する前記作られた子入力情報との組合せをＤＦＤ原形スケルトン作業領域に作るＤＦＤ原形スケルトン作成ステップと、前記親概念のデータフロー図における機能部分から取り出された動詞又は前記親概念から展開した子概念の動詞を継承して、前記作られた組合せの機能部分に挿入して子データフロー図を形成するＤＦＤ形成ステップと、該ＤＦＤ形成ステップで形成された子データフロー図から子フローチャートまたは子構造化チャートを得て、親概念と対になる子概念（群）を展開して完成する処理ステップとを含む知識の自動生成プログラム。
10. 親概念と該親概念から展開される子概念（群）との対を単位的知識とし、該単位的知識を順次展開することを繰返して詳細化された意図達成又は設計の知識を得る自動生成システムであって、
    親概念から展開された子概念（群）の動詞を中心とするスケルトンおよび該スケルトンに作用して子概念の宣言を完成する処理論理とから構成される単位情報の群を記録したルールベースである動詞辞書と、
    親概念を構成する出力若しくは後状態、入力若しくは前状態および先行する親概念（群）の情報を元に親概念の動詞についての意味を選択する論理が格納されたＤＤＦテーブルと、
    入力して与えられた親概念のデータフロー図における機能部分から取り出された動詞で前記動詞辞書を検索して前記親概念から展開された子概念（群）の単位情報の群を取得する検索部と、該検索部で取得された単位情報の群から前記ＤＤＦテーブルに格納された論理によって対応する単位情報を選択する選択部と、該選択部で選択して得られる単位情報から前記処理論理を得て親概念と対になる子概念（群）を展開して完成する処理部とを有し、前記展開される子概念（群）中の各機能（群）を新たな親概念の入力として順次展開して前記詳細化した意図達成又は設計の知識を得る知識生成手段とを備えたことを特徴とする知識の自動生成システム。
11. 請求項１０記載の知識の自動生成システムにおいて、更に、前記知識生成手段で得られた前記詳細化した意図達成又は設計の知識を知識ベース部に送信して蓄積させる送信手段を備えたことを特徴とする知識の自動生成システム。
12. 請求項１０記載の知識の自動生成システムにおいて、更に、前記知識生成手段で得られた前記詳細化した意図達成又は設計の知識を知識ベース部に送信して蓄積させる送信手段と、前記知識生成手段から得られる詳細化した意図達成又は設計の知識と前記知識ベース部に蓄積された詳細化した意図達成又は設計の知識とを選択する選択手段とを備えたことを特徴とする知識の自動生成システム。
13. 請求項１２記載の知識の自動生成システムにおいて、前記知識ベース部に送信された詳細化した意図達成又は設計の知識について、前記知識ベース部に蓄積された智識の中で動詞を同じくする既出の知識（群）と比較・照合して、重複部分はスケルトンとして抽出し、同一意味に共通なパターンは処理論理として抽出し、それらの抽出結果を前記ルールベースである動詞辞書に蓄積する抽象化機構を備えたことを特徴とする知識の自動生成システム。
14. 請求項１０記載の知識の自動生成システムにおいて、更に入力帳票、出力帳票及びファイルなどの情報の階層的な構造を定義する構造辞書を備え、
    前記知識生成手段において、専用論理に基づいて、前記構造辞書を参照して、入力して与えられた親概念のデータフロー図における出力あるいは後状態を階層的に展開した子出力情報を出力側データ作業領域に作り、前記親概念のデータフロー図における入力あるいは前状態を階層的に展開した子入力情報を入力側データ作業領域に作り、前記作られた子出力情報と該子出力情報に対応する前記作られた子入力情報との組合せをＤＦＤ原形スケルトン作業領域に作るＤＦＤ原形スケルトン作成部と、前記親概念のデータフロー図における機能部分から取り出された動詞又は前記親概念から展開した子概念の動詞を継承して、前記ＤＦＤ原形スケルトン作成部で作られた組合せの機能部分に挿入して子データフロー図を形成するＤＦＤ形成部と、該ＤＦＤ形成部で形成された子データフロー図から子フローチャートまたは子構造化チャートを得て、親概念と対になる子概念（群）を展開して完成する処理部とを有することを特徴とする知識の自動生成システム。
15. 請求項１４記載の知識の自動生成システムにおいて、更に、前記知識生成手段で得られた前記詳細化した意図達成又は設計の知識を知識ベース部に送信して蓄積させる送信手段を備えたことを特徴とする知識の自動生成システム。
16. 親概念から展開された子概念（群）の動詞を中心とするスケルトンおよび該スケルトンに作用して子概念の宣言を完成する処理論理とから構成される単位情報の群を記録したルールベースである動詞辞書と、親概念を構成する出力若しくは後状態、入力若しくは前状態および先行する親概念（群）の情報を元に親概念の動詞についての意味を選択する論理が格納されたＤＤＦテーブルと、照会された親概念のデータフロー図における機能部分から取り出された動詞で前記動詞辞書を検索して前記親概念から展開された子概念（群）の単位情報の群を取得する検索部と該検索部で取得された単位情報の群から前記ＤＤＦテーブルに格納された論理によって対応する単位情報を選択する選択部と該選択部で選択して得られる単位情報から前記処理論理を得て親概念と対になる子概念（群）を展開して返送する処理部とを有する処理手段とを備え、前記親概念と対になる子概念（群）を展開することを繰返して詳細化された意図達成又は設計の知識を得るように構成した自動生成エンジン部を設けたことを特徴とする自動生成システム。
17. 請求項１６記載の自動生成エンジン部と該自動生成エンジン部で得られた詳細化された意図達成又は設計の知識を蓄積する知識ベース部とを有するエンジン部を設け、
    少なくともデータフロー図用ＣＡＳＥツール部を有するＣＡＳＥツール群を設け、
    前記ＣＡＳＥツール群と前記エンジン部との間で相互に情報の照会および返送を行う手段を設けたことを特徴とする自動生成システム。
18. 請求項１６記載の自動生成エンジン部を設け、
    更に、システムの入力および出力として、データフロー図があり、両図面上の対応する機能には各々始点が設定され、始点がある機能から親概念のデータフロー図を取出して前記自動生成エンジン部に前記照会する照会機能と、前記自動生成エンジン部から前記返送された親概念を展開した子概念（群）情報を受けて、前記図において始点のある前記機能の延長位置に子概念群情報を貼付け、図面上の始点は同期的に次の同レベル機能に移行あるいは子のレベルの機能に下降する貼付け機能とを有する実在あるいは仮想的なＣＡＳＥツールを設け、
    前記ＣＡＳＥツールの照会機能と貼付け機能が順次階層的に繰返し動作することにより詳細化した意図達成又は設計の知識を得るように構成したことを特徴とする自動生成システム。
19. 請求項１８記載の自動生成システムにおいて、前記ＣＡＳＥツールには、システムの入力および出力として、フローチャートあるいは構造化チャートがあり、前記自動生成エンジン部には、更に入力帳票、出力帳票及びファイルなどの情報の階層的な構造を定義する構造辞書を備え、前記処理手段において、専用論理に基づいて、前記構造辞書を参照して、前記照会された親概念のデータフロー図における出力あるいは後状態を階層的に展開した子出力情報を出力側データ作業領域に作り、前記親概念のデータフロー図における入力あるいは前状態を階層的に展開した子入力情報を入力側データ作業領域に作り、前記作られた子出力情報と該子出力情報に対応する前記作られた子入力情報との組合せをＤＦＤ原形スケルトン作業領域に作るＤＦＤ原形スケルトン作成部と前記親概念のデータフロー図における機能部分から取り出された動詞又は前記親概念から展開した子概念の動詞を継承して、前記ＤＦＤ原形スケルトン作成部で作られた組合せの機能部分に挿入して子データフロー図を形成するＤＦＤ形成部と該ＤＦＤ形成部で形成された子データフロー図から子フローチャートまたは子構造化チャートを得て、親概念と対になる子概念（群）を展開して送信する処理部とを有することを特徴とする自動生成システム。
20. 請求項１９記載の自動生成システムにおいて、更に設計作業に用いられた出力データあるいは後状態と該情報を階層展開した子データとの対および入力データあるいは前状態と該情報を階層的に展開した子データとの対を基礎知識辞書に蓄積する手段を備え、該基礎知識辞書は前記構造辞書の延長として参照されることを特徴とする自動生成システム。

Images