200721

特論-2 ワーニエ・メソッド (その 1、反復構造)

>> 目次に もどる

201211日 補遺

 



 ワーニエ・メソッド に関して、構造的 プログラミング の考えかたは、以下の書物に記述されているので、その書物を読めば、私が下手な再体系化をして、改悪しないほうがいいでしょう。

  「ワーニエ・プログラミング 法則集」、J.D. ワーニエ 著、鈴木君子 訳、昭和 50年、日本能率協会.

 ちなみに、鈴木君子さんの翻訳は、名訳だと思います。

 構造的 プログラミング の技術のほかに、ワーニエ・メソッドに関して、構造化システム設計の考えかたを学習するのであれば、以下の書物を読んで下さい。

  「ワーニエ・構造化システム設計」、J. D. ワーニエ 著、鈴木君子 訳、日本能率協会.

 ただし、この書物を読むには、数学の集合論について知識がなければならない。

 さて、ワーニエ・プログラミング 法では、「プログラム は、インプット・データ 構造に基づいて作成される」 ことが大前提とされています。すなわち、データ 構造が 「細分規則」 に従って作られていなければならない (構造化されていなければならない)。たとえば、「黒本」 113ページに示した 「ロジカル・シーケンス の フローチャート」 を例にして、従業員の給与計算を考えてみれば、以下の データ 構造 (レコード、および レコード を 1つの集合とした ファイル) が前提になるでしょう。

  {営業所 コード、部門 コード、従業員番号、従業員名称、... 給与、....

 そして、プログラム は、この データ 構造を前提にして、以下のような反復構造として作成されるでしょう。

    start
     営業所 start
       部門 start
         従業員の プロセス
       部門 end
     営業所 end
    end

 そして、この反復構造は、レコード を 1件ずつ対象にする レコード・アット・ア・タイム (record-at-a-time) 法です。そして、この反復構造のなかで、レコード ごとに、「営業所 コード、部門 コード、従業員番号」 を index-key として、以下のように、「分岐」 を判断するでしょう。

  if
    wk-(営業所コード、部門 コード、従業員番号) = in-(営業所コード、部門 コード、従業員番号)
    perform same-process
  else
    perform exit process

 wk- として読み込まれた レコード (initial read) は 「照合基準」 として使われ、in- として読み込まれた レコード が 「識別基準」 とされて、マッチング されます。そして、同じ index-key の値が継続するなら、プロセス は反復されます--言い換えれば、key-break するまで、プロセス は反復されます。すなわち、ワーニエ 風に言えば、「インプット・データ 構造が反復構造であれば、プログラム 構造も反復構造になる」 ということです。

 「情報 (たとえば、帳票とか画面とか)」 を起点にして データ 構造を作る際に--「プログラムは、インプット・データ 構造に基づいて作成される」 のなら--、データ 構造を いかにして作成するか という点を考えなければならないでしょう。ワーニエ・メソッドでは、データ 集合間の包摂関係が 「細分法則」 とされています。すなわち、営業所と部門と従業員という データ 集合が前提にされていて、それらのあいだで包摂関係を考えて、データ 構造を作るという考えかたです。

 2つの集合論のあいだには、以下の包摂関係を考えることができます。

 (1A B をふくんで、さらに、ひろがっている。
 (2B A をふくんで、さらに、ひろがっている。
 (3A B は、たがいに、一部、まじわっている。
 (4A B には、まじわりがない。

 包摂関係を前提にした 「細分法則」 では、(3) が論点になるでしょう。
 たとえば、部門と従業員との包摂関係で、部門に配属されていない従業員に関して、給与を計算するのであれば、「場合分け」 を考慮した 「選択構造」 を組まなければならない。ワーニエ・メソッド の選択構造については、次回、述べます。

 私が プログラマ でいた頃 (30年前)、事業過程を対象にした システム作りでは、ワーニエ・メソッド が規範でした。だから、私も ワーニエ・メソッド を学習しました。そして、集合論を使った べつの データ 設計法 (コッド 関係 モデル) を学習するまで、ワーニエ・メソッド は、私の規範でした。



[ 補遺 ] 201211日)

 取り立てて補遺はいらないでしょう。

 今の私は抽象 データ 型 モデル を信奉しているので、ソリューション を構造化する構造的 プログラミング を信奉していない。







 

<< もどる

HOME

すすむ >>

 

「T字形ER データベース設計技法」を読む