コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

「構造化プログラミング」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
編集の要約なし
編集の要約なし
14行目: 14行目:
#'''選択'''（''selection''） 条件式が導出した状態に従い、次に実行する部分プログラムを選択して分岐する。
#'''選択'''（''selection''） 条件式が導出した状態に従い、次に実行する部分プログラムを選択して分岐する。
#'''反復'''（''repetition''）条件式が導出した特定の状態の間、部分プログラムを繰り返し実行する。
#'''反復'''（''repetition''）条件式が導出した特定の状態の間、部分プログラムを繰り返し実行する。


[[ファイル:Structured_program_patterns.png|中央|サムネイル|700x700ピクセル|順次、選択、反復の描写図（青はNSダイアグラム、緑はフローチャート）]]
[[ファイル:Structured_program_patterns.png|中央|サムネイル|700x700ピクセル|順次、選択、反復の描写図（青はNSダイアグラム、緑はフローチャート）]]
<br />制御構造の登場は1960年公開のプログラミング言語「[[ALGOL|ALGOL60]]」まで遡る事ができる。1966年に[[コラド・ベーム]]らが順次・選択・反復のフロー万能性を数学的に証明したが、それはあくまで論理的研究だった。1968年の[[エドガー・ダイクストラ|ダイクストラ]]の投書によって制御構造に対する関心は大きく高まった。ただしその物議を醸すタイトル（goto文は有害）を付けたのは[[ニクラウス・ヴィルト]]であった。1970年代、制御構造の普及を重視していたIBM社の[[ハーラン・ミルズ]]は、1969年にダイクストラが発表してこれも反響を得ていた論文タイトル（構造化プログラミング）を自社の技術セミナーマーケティングに活用するために、上述のベームの数学的証明を独自のタイトル（[[構造化定理]]）で復刻させて信憑性を高めるための技術的裏付けにした。その後、構造化プログラミングは制御構造を中心にした解釈で世間に定着した。
制御構造の登場は1960年公開のプログラミング言語「[[ALGOL|ALGOL60]]」まで遡る事ができる。1966年に[[コラド・ベーム]]らが順次・選択・反復のフロー万能性を数学的に証明したが、それはあくまで論理的研究だった。1968年の[[エドガー・ダイクストラ|ダイクストラ]]の投書によって制御構造に対する関心は大きく高まった。ただしその物議を醸すタイトル（goto文は有害）を付けたのは[[ニクラウス・ヴィルト]]であった。1970年代、制御構造の普及を重視していたIBM社の[[ハーラン・ミルズ]]は、1969年にダイクストラが発表してこれも反響を得ていた論文タイトル（構造化プログラミング）を自社の技術セミナーマーケティングに活用するために、上述のベームの数学的証明を独自のタイトル（[[構造化定理]]）で復刻させて信憑性を高めるための技術的裏付けにした。その後、構造化プログラミングは制御構造を中心にした解釈で世間に定着した。


== 構造化設計 ==
== 構造化設計 ==
79行目: 77行目:


なお、ベームとヤコピーニの証明は、フローチャートやそれによって表現されるプログラム・関数・チューリングマシンなどの理論的側面に注目している。これは任意の論理回路が[[否定論理積|NAND]]素子の組み合わせによって表現できるとか、[[ラムダ計算|λ式]]がSおよびKという名の2つの[[SKIコンビネータ計算|コンビネータ]]によって表現できるとかいった研究に近い。回路設計者が直接NANDを組み合わせて電子回路を設計しないのと同じように、構造化定理は良いプログラムの作成を（少なくとも直接的には）意図していない。ハレルも構造化定理は実際の内容以上に引用されて民間伝承定理（''folk theorem''）化していると指摘していた<ref name=":0" />。
なお、ベームとヤコピーニの証明は、フローチャートやそれによって表現されるプログラム・関数・チューリングマシンなどの理論的側面に注目している。これは任意の論理回路が[[否定論理積|NAND]]素子の組み合わせによって表現できるとか、[[ラムダ計算|λ式]]がSおよびKという名の2つの[[SKIコンビネータ計算|コンビネータ]]によって表現できるとかいった研究に近い。回路設計者が直接NANDを組み合わせて電子回路を設計しないのと同じように、構造化定理は良いプログラムの作成を（少なくとも直接的には）意図していない。ハレルも構造化定理は実際の内容以上に引用されて民間伝承定理（''folk theorem''）化していると指摘していた<ref name=":0" />。

=== プログラム正当性検証のための構造化 ===
ダイクストラは、プログラマは正しいプログラムを作り出すばかりでなく納得のいくやり方で正しさを証明（検証）することも仕事の一つであるという立場を取っていた<ref>[[構造化プログラミング#構造化プログラミング(1975)|構造化プログラミング(1975)]] p.6</ref>。ただしその検証<ref>D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが、ここでは厳密な区別はしない。

* 金山裕 編, "構造的プログラミング −批判と支持−", ''bit'', Vol.7, Issue 7, 1975, pp.6-13, 共立出版.</ref>をするためのプログラムはよく構造化（''well-structured''）されていなくてはならず、そのために提唱された技法が構造化プログラミングであった{{#tag:ref|すなわち、プログラム検証と構造化プログラミングとは不可分の関係にある。|group="注釈"}}<ref>所与のプログラムの正しさを後付けで証明することは、はじめから証明を意識して作られたプログラムの場合より難しいことが経験的に知られている、と言われる。

* E.W.Dijkstra, "Programming methodologies, their objectives and their nature", ''Structured Programming'', Infotech state of the art report, 1976, pp.205-212, Infotech International.</ref>。1967年のノート「Towards Correct Programs」でダイクストラはよく構造化するための三つのメンタルツール（''mental tool''）をこのように提示している。

# 列挙（enumeration）： 一人の人間の能力でできる範囲でプログラムの命令の妥当性を一つ一つ確認していく作業
# 数学的帰納（mathematical induction）： while文など計算機特有の多数の繰り返し文についてのみ数学的帰納法を用いて確認する作業
# 抽象（abstraction）： プログラムのブロックなどに名前をつけ、さらに中身を見ないで正しいと仮定することで検証作業を後回しにする操作

プログラムが正しいことを確認するには、それを証明しなければならない<ref name="structured_programming" />{{#tag:ref|D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが<ref name="bit1975_structured_programming">金山裕 編, "構造的プログラミング −批判と支持−", ''bit'', Vol.7, Issue 7, 1975, pp.6-13, 共立出版.</ref>、ここでは厳密な区別はしない。|group="注釈"}}。テストはプログラムに対する疑いを全て取り除くには不十分であるという意見が上がった<ref name="systematic_programming">N.ヴィルト, ''系統的プログラミング/入門'', 野下浩平, 筧捷彦, 武市正人 訳, 近代科学社, 1978. </ref><ref name="how_to_solve_it_by_computer">R.Geoff Dromey, ''How to Solve it by Computer'', Prentice Hall, 1982. </ref>。これについてダイクストラは「テストはバグの存在を示すには有効だが、バグが存在しないことは証明できない」という表現を好んで用いた<ref name="structured_programming" /><ref name="the_humble_programmer">E.W.ダイクストラ, “謙虚なプログラマ”, ''ACMチューリング賞講演集'', 木村泉 訳, 共立出版, 1989, pp.23-43. </ref><ref name="ewd273">[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD273.html E.W.Dijkstra, "The Programming Task Considered as an Intellectual Challenge", 1969.]</ref><ref name="ewd288">[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD288.html E.W.Dijkstra, "Concern for Correctness as a Guiding Principle for Program Composition", 1970.]</ref><ref name="ewd361">[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD361.html E.W.Dijkstra, "Programming as a discipline of mathematical nature", 1973.]</ref>。構造化プログラミングの支持者らは、プログラムの正しさの重要性と証明の方法や表明(assertion)の使い方について熱心に説いた<ref name="the_science_of_programming" /><ref name="structured_programming_72" /><ref name="systematic_programming" /><ref name="how_to_solve_it_by_computer" /><ref name="the_craft_of_programming">[http://www.cs.cmu.edu/~jcr/craftprog.html John C. Reynolds, ''The Craft of Programming'', Prentice-Hall, 1981.]</ref>。理想的にはテストだけに依存せず、プログラムの正しさの証明も与えるべきだと言われている<ref name="proving_programs_correct">ロバート B.アンダーソン, ''演習プログラムの証明'', 有沢誠 訳, 近代科学社, 1980. </ref><ref name="basic_theorem_of_programs">小野寛晰, ''プログラムの基礎理論'', サイエンス社, 1975. </ref>。所与のプログラムの正しさを後付けで証明することは、はじめから証明を意識して作られたプログラムの場合より難しいことが経験的に知られている<ref name="programming_methodologies">E.W.Dijkstra, "Programming methodologies, their objectives and their nature", ''Structured Programming'', Infotech state of the art report, 1976, pp.205-212, Infotech International.</ref>。ダイクストラは、プログラミングと同時にプログラムの証明を（わずかに証明を先行して）進めることを推奨している<ref name="a_discipline_of_programming">E.W.ダイクストラ, ''プログラミング原論 ― いかにしてプログラムをつくるか'', 浦昭治訳, サイエンス社, 1983. </ref>。そのようなアプローチでプログラムの正当性の問題にあたれば、複雑な問題であっても知的管理が可能であると述べた{{#tag:ref|ダイクストラはプログラミングと証明を並行するのに適した、最弱事前条件をによる検証方法を考案した。ホーア論理は作り終わったものは証明できるが、これから作るプログラムについては指標を与えてくれない<ref name="software_cleanroom">二木厚吉 監修, ''ソフトウェアクリーンルーム手法'', 日科技連, 1997. </ref>。|group="注釈"}}。しかし形式的な証明は、時として非人間的な長さの記述になることもダイクストラは認めている<ref name="a_discipline_of_programming" /><ref name="from_craft_to_scientific_discipline" />。同氏は、プログラムの証明が形式的であることにはこだわらないという意見を明らかにした<ref name="a_discipline_of_programming" /><ref name="structured_programming_with_go_to_statements" />{{#tag:ref|形式化にとらわれない点では（当時のダイクストラの）構造化プログラミングは[[形式手法]]と趣きが異なる。なおプログラムの正しさの証明とはウォークスルーやインスペクションによるレビューではなく、帰納法や最弱事前条件による検証を指す。
形式的でない証明の方法については、ロバートの「プログラムの証明」<ref name="proving_programs_correct"/>が良い入門書の一つである。|group="注釈"}}。


=== ダイクストラの後述 ===
=== ダイクストラの後述 ===

2021年4月6日 (火) 14:45時点における版

プログラミング・パラダイム

命令型プログラミング

宣言型プログラミング

マルチパラダイム

構造化プログラミング（こうぞうかプログラミング、英: structured programming）とは、コンピュータプログラム上での処理の流れを明瞭化かつ平易化するための手法である。一般的には順接、分岐、反復の三つの制御構造（control structures）によって処理の流れを記述することであると認識されている[1][2]。コードブロックとサブルーチンの仕組みも加えられることがある。制御構造は制御構文、構造化文（structured statement）または制御フロー文（control flow statement）とも呼ばれる。

このプログラミング手法の普及に貢献したのは、計算機科学者エドガー・ダイクストラによる1968年のACM機関紙への投書「Go To Statement Considered Harmful」と言われている。しかし同じくダイクストラが、1969年のNATOソフトウェア工学会議で発表した論文「Structured Programming」との混同を招いてこちら側の名称で知られるようになった。国内外の多くの書籍において構造化プログラミングは、制御構文に関する説明に結び付けられているのが現状である。なお、1969年の論文の内容はプログラムの構造設計に関するものであり、トップダウン設計、段階的な抽象化、階層的なモジュール化、抽象データ構造と抽象ステートメントをまとめた共同詳細化といった考え方が提唱されていた[3]。

制御構文

→詳細は「ミルズの構造化プログラミング」を参照

制御構文（control structures）とは、goto文によるフロー分岐やループ表現を、if文による選択構文やwhile文による反復構文に置き換えるためのプログラム記法を意味している。ラベル先にジャンプするというgoto文の機能を、if文やwhile文は「特定のコード群だけを実行する」という概念に置き換えている。goto文を用いた制御フローは、データの照合/比較結果に従って次のコード群を選択するというパターンと、データの照合/比較結果が任意条件を満たしてる間だけコード群を反復するというパターンの二つに集約されることが経験則で知られていたので、これを専用の記号で形式化したのが制御構文であった。

コード群とは命令コード（instruction code）のまとまりであり、構造化定理では部分プログラム（subprogram）と定義されている。部分プログラムはステートメント（statement）コードブロック（code block）サブルーチン（subroutine）の総称である。ステートメントは命令コードの一行を意味する。コードブロックは一行以上のステートメントをまとめたものである。サブルーチンは一行以上のステートメントまたは一個以上のコードブロックを内包している。部分プログラムは直列状または入れ子状に配置される。その実行順序を決定するものが制御構造であり、以下の三つがある。

  1. 順次（sequence）部分プログラムを順々に実行する。
  2. 選択（selection） 条件式が導出した状態に従い、次に実行する部分プログラムを選択して分岐する。
  3. 反復（repetition）条件式が導出した特定の状態の間、部分プログラムを繰り返し実行する。
順次、選択、反復の描写図（青はNSダイアグラム、緑はフローチャート）

制御構造の登場は1960年公開のプログラミング言語「ALGOL60」まで遡る事ができる。1966年にコラド・ベームらが順次・選択・反復のフロー万能性を数学的に証明したが、それはあくまで論理的研究だった。1968年のダイクストラの投書によって制御構造に対する関心は大きく高まった。ただしその物議を醸すタイトル（goto文は有害）を付けたのはニクラウス・ヴィルトであった。1970年代、制御構造の普及を重視していたIBM社のハーラン・ミルズは、1969年にダイクストラが発表してこれも反響を得ていた論文タイトル（構造化プログラミング）を自社の技術セミナーマーケティングに活用するために、上述のベームの数学的証明を独自のタイトル（構造化定理）で復刻させて信憑性を高めるための技術的裏付けにした。その後、構造化プログラミングは制御構造を中心にした解釈で世間に定着した。

構造化設計

→詳細は「段階的詳細化法」を参照
構造化設計の一例

上述の制御構文をコーディング視点の下流工程テクニックとすると、構造化設計（structured design）はプログラムデザイン視点の上流工程テクニックであり、こちらも構造化プログラミングと呼ばれるものである。構造化設計では概して、サブルーチン（subroutine）とモジュール（module）が主要な役割を果たす事になる。モジュールはプログラム規模の拡大で増え続けるサブルーチンとデータをグループ化して管理しやすくするために、1960年代に考案された機能である。モジュールは任意のサブルーチン群とデータ群の双方をひとまとめにするプログラム要素であり、サブルーチン階層とモジュールの組み合わせでプログラム全体を構造化するのが構造化設計である。凝集度や結合度といった考え方もここから生まれている。

構造化設計は総称用語である。モジュールを重視したプログラム開発は1960年代後半から研究が始まっており、いずれも構造化（structured）が接頭辞につく数々のテクニックが発表されている。1975年発表「ジャクソンの構造化プログラミング -Jackson structured programming(JSP)」、1975年発表「構造化設計 -structured design(SD)」、1978年発表「構造化分析 -structured analysis(SA)」、1981年発表「構造化分析設計技法 -structured analysis and design technique(SADT)」、1980年代発表「構造化体系分析設計手法 -structured systems analysis and design method(SSADM)」、1989年発表「モダン構造化分析 -modern structured analysis」などが広く普及している。著名な専門家としては、グレンフォード・マイヤーズ、ラリー・コンスタンティン、マイケル・ジャクソン、エドワード・ヨードン、トム・デマルコなどがいる。

この構造化設計とダイクストラの構造化プログラミングの違いは、前者がモジュールを普通にサブルーチンとデータの構成体として扱っているのに対して、後者はモジュールを抽象体として扱おうとしている点である。後者では、段階的に抽象化した各モジュールの階層的な連結と、抽象データ構造と抽象ステートメントを連携させる共同詳細化といった考え方が提示されており、この詳細については後節で述べられる。ダイクストラが提唱した抽象（abstraction）指向の構造化は、その思想の前衛性から1970年代を通して理解を得られることはなく、発案者本来の構造化プログラミングは上流工程視点からも普及することはなかった。

歴史

第一幕

構造化プログラミングの誕生は、1960年代から浮上したソフトウェア危機問題と密接に結びついている。ソフトウェア危機とはコンピュータ性能の進化に伴うソフトウェア要求度の高まりが、プログラムサイズの際限無い肥大化と複雑化を招き、近いうちに現実的な期間内でのプログラム開発が不可能になるだろうとする悲観的予測である[注釈 1]。実際に1960年代のソフトウェア開発現場では仕様不一致、納期遅れ、予算超過といった事態が頻発していた[4]。当時のプログラムはgoto文を多用するタコ足フローチャートによるものが大半だったので[5]、すぐにスパゲティコード化することが多く、複雑怪奇なジャングルフロー図と化しているものも珍しくなかった[6]。1959年に計算機科学者ハインツ・ツェマネクは、goto文の多用に警鐘を鳴らす論文を発表している。1960年に公開されたプログラミング言語「ALGOL60」は、BEGINとENDで区切られたコードブロックを制御するIF選択文とFOR反復文を初めて提供していた。計算機科学者ニクラウス・ヴィルトはこれらを構造化文（structured statement）と呼んだ[7]。1966年に計算機科学者コラド・ベームとジュゼッペ・ヤコピーニは、あらゆるフローチャートは順次・選択・反復の組み合わせで表現できることの数学的証明をし、これはベームとヤコピーニの証明と呼ばれた[8]。計算機科学者ドナルド・クヌースは、これらの潮流を構造化文の第一幕と定義した[6]。

第二幕

1968年、計算機科学者エドガー・ダイクストラのACM機関紙への投書「Go To Statement Considered Harmful[9]」は、その物議を醸す題名でソフトウェア界隈にいわゆるgoto文論争を巻き起こすことになった[10][11]。goto文論争は当時のプログラマたちに構造化文をより強く意識させることにも貢献している[12]。これを構造化文の第二幕と定義したクヌースは「第二幕はそのムーブメントの大きさによって多くの人にとっての第一幕になった」と自著で述べた[13]。1968年度開催のNATOソフトウェア工学会議でソフトウェア危機は正式な用語になり[14]計算機科学分野共通の懸案事項になった[15]。翌1969年度開催のNATOソフトウェア工学会議においてダイクストラは「Structured Programming[3]」と名付けた論文を寄稿した。これが「構造化プログラミング」の正式な初出である。その内容はソフトウェア危機解決策としてのソフトウェア正当性検証技術の確立に焦点を当てたものであり、トップダウン設計、抽象化、モジュール化、共同詳細化（抽象データ型の原型）といったプログラム全体の設計＆分析技法が提唱されていた。goto文回避など構造化文に関する事柄は数行に留まっていたが[注釈 2]、goto文論争に熱心なプログラマたちの間ではこの論文を昨年の投書の延長と見る向きも少なからず存在していた。後年のダイクストラは構造化プログラミングという言葉を作った際に二つの失敗をしたと述べている。商標登録しなかった事と、厳密な定義化を避けた事である[16][15]。

第三幕

1960年代からの構造化文第一幕の潮流は、産業プログラム界隈にも影響を及ぼしており、こちらでは制御構造（control structures）などの名義でフローチャートに導入されていた。産業コンピュータ市場の最大手であるIBM社の上席研究員ハーラン・ミルズは制御構造を重視し、ニューヨーク・タイムズ社のニュースアーカイブシステム構築プロジェクトで大きな成功を収めた。順次・選択・反復の制御構造は、IBM社のプログラミング規範をまとめたImproved Programming Technologies通称「IPT」に採用され、後に同社の技術セミナーなどを通して広く流布されるようになった[17][18]。1970年ないし71年頃から計算機科学者デビッド・ハレルは、前述のベームとヤコピーニの証明に「Structure theorem」という全く新しい題名を付けてACM機関紙上などで紹介した[19][注釈 3]。ハレルはこの命名が実はハーラン・ミルズの提案であったことを後年に明かしている[20]。構造化定理はIPTの合理性を裏付ける根拠として盛んに引用されたので、構造化（Structured）プログラミングと言えばIBM社の発明品だと信じるプログラマたちも続出した[21]。IBM社は1974年から所属研究員たちによるプログラム全体の構造化分析設計技法（structured analysis/design technique）も発表しているが、抽象化を重視するダイクストラのそれとは異なり、具象的なモジュール構造に重点を置いていた。その違いを指摘して本来のダイクストラ流を改めて紹介する動きもあったが、抽象化指向のダイクストラ理論は産業界ではむしろ不人気でさえあった[22][23][24]。クヌースの言葉を借りれば、構造化文の第三幕はIBM社とハーラン・ミルズがプロモートした制御構造の舞台になり、構造化プログラミングに対する世間一般の認識はこちらの方で定着するようになった。

終幕

後年、ダイクストラは自身が作った構造化プログラミングという言葉に不快感を示して避けるようになった[25]。この言葉を作った時、彼はプログラミングが手工芸から科学へ発展することを期待していた[16]。しかし構造化プログラミングという言葉は実利を求めるために使われるようになった[25]。次のような逸話がある。構造化分析設計技法の第一人者エドワード・ヨードンの事務所にセミナー依頼の電話がかかってきた。プロジェクトメンバー全員に構造化プログラミングを1日で叩きこんで欲しいという内容である。それが終わったらプロジェクト期間を半分にするという。その理由は「構造化プログラミングは生産性を2倍にするという話ですから」であった[26]。

ダイクストラの構造化プログラミング

「Structured Programming」という用語自体を生み出したのは計算機科学者エドガー・ダイクストラであり、1969年のNATOソフトウェア工学会議で発表された論文が初出とされている。彼は2001年のノートで自分が作り出した「構造化プログラミング」という用語は結局異なる解釈で持ち去られてしまったと述べている[27]。

ダイクストラが提唱した構造化プログラミングは、プログラム正当性検証技術の確立を発端にして構想された数々のプログラム設計理論の複合体である。遅くとも1967年からその構想は始められていた。1968年のgoto文に依存しないシーケンスの制御、1969年のトップダウン設計、抽象化、モジュール化、共同詳細化から始まり、1972年には抽象データ構造、情報隠蔽、階層的プログラム構造といった考えも取り上げられていた[28][22][17]。1972年の共著は、ダイクストラの第一章・構造化プログラミングから始まり、オルヨハン・ダールの第三章・階層型プログラム構造で締め括られている。ダールはオブジェクト指向プログラミング言語の草創Simula67の開発者である。

1968年の投書「goto文は有害」

→詳細は「goto文 § goto文論争」を参照

1968年のCommunications of the ACMに投書されたこの「Go To Statement Considered Harmful[9]」は、そのセンセーショナルなタイトルでプロアマを問わずプログラマたちの間に大きな論争を巻き起こした。それは同時にプログラミング言語ALGOLから実装されていた順接・分岐・反復の制御構造への関心を高めることにも貢献した。その論旨は次の通りである。

  • 人間が時間によって変化するプロセスを把握する能力は、プログラムの静的な関係を把握する能力に比べて劣っているため、静的なプログラムテキストの構造と時間によって変化するプロセスの構造をなるべく近づけるのが重要である。
  • そのためにはプロセスの進捗を表す簡潔な指標が必要がある。指標とは例えば実行中の行番号・その時点でのスタックトレース・行番号とループを回った回数のペアなどである。
  • 例えば、1人が部屋に入るごとにカウンタを増やしていくプログラムにおいて、カウンタが室内の人数-1である瞬間はどこにあるのかという問いに答える際に、簡潔な指標があればすぐ答えられるが、簡潔な指標がなければ正確な答えは難しくなる。
  • goto文を無条件に許してしまうと簡潔な指標は得られなくなってしまうため、高水準プログラミング言語においてはgoto文は廃止するべきである。

なお、”I do not claim that the clauses mentioned are exhaustive in the sense that they will satisfy all needs”（前述の制御構造で全てが事足りるという訳ではない）ともしており、プロセスの進捗を表す簡潔な指標が存在する限りは3つの基本構造に固執してはいない。「構造化プログラミングの観点からgoto文を使うのは望ましくない」ものの「単にgoto文を使わなければ見通しが良くなる」という考えは否定されており、goto文の有無のみに固執するのは不毛である。構造化プログラミングの本質の一つは、状態遷移の適切な表現方法とタイミングを見極めることである[29]。ダイクストラも最後の段落で、goto文の(論理的な)余分さを証明したようだと軽く触れたのみであり、作られるフローチャートは元のものより正しさの証明が簡単になるとは思えないためジャンプを含まないフローチャートの機械的な作成は推奨しないとしていた。この投書の題名と内容の齟齬については後節「ダイクストラの後述」で説明されている。

1969年の論文「構造化プログラミング」

1969年度NATOソフトウェア工学会議に寄稿されたこの「Structured Programming[3]」は、プログラム正当性の効率的な検証技術に重点を置き、当時問題視されていたコードサイズの際限なき肥大化によるソフトウェア危機の解決策として従来のボトムアップ設計からトップダウン設計への移行を推奨していた。

論文の前半では、プログラムサイズの肥大化に伴い、各プログラム部品およびそれらを組み合わせた際のプログラムの正当性（program correctness）の立証（demonstration）に必要な労力が指数的に増加して完遂が不可能になるというソフトウェア危機の問題について述べている。ダイクストラはプログラムの正しさに対して証明を与える従来の研究を分析して、証明の手続きを考えずに書かれたプログラムは証明に必要な労力がプログラムのサイズに対して爆発するとし、「与えられたプログラムに対してどうやって証明をするか」ではなく「証明がしやすいプログラムの構造とは何か」についてフォーカスするとした。

後半ではそのための方法について説明している。まず推論しやすい構造として、ステートメントが順に並んだだけのものを挙げている。また、if文1つだけも推論しやすいとしている。しかし、if文がN個並んだ場合、そのままでは2のN乗ステップの推論が必要であるとしている。そこでif文を抽象ステートメントで1つずつ置き換える段階的抽象化（step-wise abstraction）により、Nに比例する推論で正しさを示せるとした。また、そのためには制御のジャンプを制限し、制御構造は順次の他に、選択、反復、および手続き呼び出しに限るべきとしている（順次、選択、反復のいわゆる制御構造（control structures）に触れているのはこの文節だけであり、ドナルド・クヌースも1974年の著書で指摘している[6]）。この例のように詳細なプログラムを抽象化（abstraction）していくのではなく、逆に抽象的なプログラムから始めて詳細化（refinement）していくというやり方を示している。

詳細化の際には共同詳細化（joint-refinement）という考え方が示されている。これは抽象データ構造の詳細化と共にそれを扱う抽象ステートメントを同時に詳細化し、それを1つのプログラムテキストのユニットに分離するというものである。このユニットをダイクストラは真珠(pearl)と呼んだ。また、抽象的な真珠が1段階具体的な真珠に依存し、その真珠がさらに具体的な真珠に依存していったものをネックレスに例えた。そしてネックレスの上部は下部に関わらず正しさを証明することができ、また下部を取り替えることでプログラムのバリエーションを労力をかけずに作れるとした。

1972年の共著「構造化プログラミング」

1972年の共著「Structured Programming[30]」は計算機科学界の錚々たる三名による三章構成で、第一章はエドガー・ダイクストラの「structured programming」、第二章はアントニー・ホーアの「data structuring」、第三章はオルヨハン・ダールの「hierarchical program structures」となっていた。結びの章の「階層型プログラム構造」を著したダールはSimula67の開発者である。Simula67はオブジェクト指向プログラミングの草分けであり、この章名からクラスの継承による階層構造を重視していたことが伺える。ダイクストラの構造化プログラミングは、制御構文と構造化定理と構造化設計の影に隠れながらも、Simula67をモデルにしたオブジェクト指向プログラミング発展の歴史に組み込まれて受け継がれていったと言える。1983年にC++を開発したビャーネ・ストロヴストルップは「What Is Object-Oriented Programming?[31]」において、オブジェクト指向を抽象データ構造と階層型プログラム構造の発展形として解説し、同時にSimula67の言語仕様を紹介している。

ダイクストラ提唱の構造化プログラミングを支持するドナルド・クヌースは、1974年に自著「Structured Programming with go to Statements[6]」を上梓し、その中でgoto-lessの本質に関する補足と解説を加えた。これは当時のgoto文論争に一つの区切りを付けるものであったが、幅広い認知を得るには到らず同様の論争はその後も泥炭の火災のように燻ぶり続けた。1970年代後半からマイコンが普及してBASICなどを扱うパーソナルユーザーが増えると、goto命令を使わないのが構造化プログラミングといった見解が取り上げられて再び議論が始まるなど、この論争の影響は後年まで残った[注釈 4]。

構造化定理との関係

→詳細は「構造化定理」を参照

1970年代初頭にデビッド・ハレル（英語版）は、1966年に発表されていたベームとヤコピーニの証明に、構造化定理（Structure theorem）という全く新しいタイトルを付けてACM機関紙上などで紹介した。ハレルが後に明かしたところによると「構造化定理」という名称は、当時IBM社の上席プログラマーであったハーラン・ミルズの提案だったという[20]。ダイクストラの提唱内容とは異なる、順次・選択・反復の制御構造による構造化プログラミングは、IBM社のIPT（Improved Programming Technologies）に採用されており、同社主催の技術セミナーなどを通して当時のプログラマに広く流布されていた。その中で恐らく意図的に名称を似せた「構造化定理」は、彼らが勧める制御構造の合理性を数学的にも証明した根拠として盛んに引用されていた。

なお、ベームとヤコピーニの証明は、フローチャートやそれによって表現されるプログラム・関数・チューリングマシンなどの理論的側面に注目している。これは任意の論理回路がNAND素子の組み合わせによって表現できるとか、λ式がSおよびKという名の2つのコンビネータによって表現できるとかいった研究に近い。回路設計者が直接NANDを組み合わせて電子回路を設計しないのと同じように、構造化定理は良いプログラムの作成を（少なくとも直接的には）意図していない。ハレルも構造化定理は実際の内容以上に引用されて民間伝承定理（folk theorem）化していると指摘していた[20]。

プログラム正当性検証のための構造化

ダイクストラは、プログラマは正しいプログラムを作り出すばかりでなく納得のいくやり方で正しさを証明（検証）することも仕事の一つであるという立場を取っていた[32]。ただしその検証[33]をするためのプログラムはよく構造化（well-structured）されていなくてはならず、そのために提唱された技法が構造化プログラミングであった[注釈 5][34]。1967年のノート「Towards Correct Programs」でダイクストラはよく構造化するための三つのメンタルツール（mental tool）をこのように提示している。

  1. 列挙（enumeration）： 一人の人間の能力でできる範囲でプログラムの命令の妥当性を一つ一つ確認していく作業
  2. 数学的帰納（mathematical induction）： while文など計算機特有の多数の繰り返し文についてのみ数学的帰納法を用いて確認する作業
  3. 抽象（abstraction）： プログラムのブロックなどに名前をつけ、さらに中身を見ないで正しいと仮定することで検証作業を後回しにする操作

プログラムが正しいことを確認するには、それを証明しなければならない[3][注釈 6]。テストはプログラムに対する疑いを全て取り除くには不十分であるという意見が上がった[7][36]。これについてダイクストラは「テストはバグの存在を示すには有効だが、バグが存在しないことは証明できない」という表現を好んで用いた[3][37][38][39][40]。構造化プログラミングの支持者らは、プログラムの正しさの重要性と証明の方法や表明(assertion)の使い方について熱心に説いた[4][30][7][36][41]。理想的にはテストだけに依存せず、プログラムの正しさの証明も与えるべきだと言われている[42][43]。所与のプログラムの正しさを後付けで証明することは、はじめから証明を意識して作られたプログラムの場合より難しいことが経験的に知られている[44]。ダイクストラは、プログラミングと同時にプログラムの証明を（わずかに証明を先行して）進めることを推奨している[45]。そのようなアプローチでプログラムの正当性の問題にあたれば、複雑な問題であっても知的管理が可能であると述べた[注釈 7]。しかし形式的な証明は、時として非人間的な長さの記述になることもダイクストラは認めている[45][15]。同氏は、プログラムの証明が形式的であることにはこだわらないという意見を明らかにした[45][6][注釈 8]。

ダイクストラの後述

ダイクストラは2001年のノート「What led to “Notes on Structured Programming”」(構造化プログラミング表記の由来）でこのように述べている。

1968年の自分は「A case against goto statement」(goto文が不利な事例）と題した記事（article）をCommunications of the ACM（ACMの機関紙）に投稿したが、当期の刊行を急ぐ編集担当者の意向で投書（letter to the Editor）にされる事になり、更にその担当者独自の考えで「The goto statement considered harmful」(goto文は有害）という全く新しい題名を付けられた。その担当者とはニクラウス・ヴィルトであった。また、自分が提唱した構造化プログラミングの本質的内容の普及を好まない某社がハーラン・ミルズの主導で、まるでgoto文を廃止するかのようなプログラミング手法へと矮小化し、構造化プログラミングという用語まで持ち去ってしまった。

脚注

注釈

  1. ^ ソフトウェア危機の始まりと構造化プログラミングの歴史について[4]の第23章に詳しい。
  2. ^ "statements transferring control to labelled points" という言葉で一応 goto 文に触れている[3]
  3. ^ Harel,David (1980)."On Folk Theorems"(PDF)のP381の左列の中央にハーラン・ミルズ（Harlan Mills）が未公表の講義資料の中で "The Structure Theorem" と名付けたことが書かれている。この資料の出典[67]が1972年のため構造化定理が発明されたのは1970年代初頭と推測される。
  4. ^ 直接は無関係だが、ダイクストラはBASIC批判の急先鋒でもあった。マイコン普及以前の1970年代に既に、BASICでプログラミング教育をすべきでない、と強く主張している（wikiquote:Edsger W. Dijkstra#How do we tell truths that might hurt? (1975)）。
  5. ^ すなわち、プログラム検証と構造化プログラミングとは不可分の関係にある。
  6. ^ D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが[35]、ここでは厳密な区別はしない。
  7. ^ ダイクストラはプログラミングと証明を並行するのに適した、最弱事前条件をによる検証方法を考案した。ホーア論理は作り終わったものは証明できるが、これから作るプログラムについては指標を与えてくれない[46]。
  8. ^ 形式化にとらわれない点では（当時のダイクストラの）構造化プログラミングは形式手法と趣きが異なる。なおプログラムの正しさの証明とはウォークスルーやインスペクションによるレビューではなく、帰納法や最弱事前条件による検証を指す。 形式的でない証明の方法については、ロバートの「プログラムの証明」[42]が良い入門書の一つである。

出典

  1. ^ “構造化プログラミングとは - IT用語辞典”. IT用語辞典 e-Words. 2020年6月1日閲覧。
  2. ^ “構造化プログラミング - 意味・説明・解説 : ASCII.jpデジタル用語辞典”. yougo.ascii.jp. 2020年6月1日閲覧。
  3. ^ a b c d e f E. W. Dijkstra, “Structured Programming”, In Software Engineering Techniques, B. Randell and J.N. Buxton, (Eds.), NATO Scientific Affairs Division, Brussels, Belgium, 1970, pp. 84–88.
  4. ^ a b c グリース, D. 筧捷彦訳 (1991). プログラミングの科学. 培風館. ISBN 4563007943 
  5. ^ 山崎利治, "流れ図", プログラムの設計, 共立出版, 1990, pp.110-113. ISBN 4320023781
  6. ^ a b c d e Knuth, D. E. (1974). “Structured Programming with go to Statements Computing Surveys”. ACM, New York, NY, USA 6 (4): 261-301. CiteSeerx: 10.1.1.103.6084. 
  7. ^ a b c N.ヴィルト, 系統的プログラミング/入門, 野下浩平, 筧捷彦, 武市正人 訳, 近代科学社, 1978.
  8. ^ Böhm, C.; Jacopini, G (1966). “Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules”. Communications of the ACM 9 (5): 366-371. CiteSeerx: 10.1.1.119.9119. 
  9. ^ a b E. Dijkstra (1968). “Go To Statement Considered Harmful”. Communications of the ACM 11 (3): 147-148. CiteSeerx: 10.1.1.132.875. 
  10. ^ E.W.ダイクストラ 木村泉訳 (1975), GO TO 論争：第1部 go to 文有害説, 7, 共立出版, pp. 6-9 
  11. ^ B.リーヴェンワス編, ed. (1975), “GO TO 論争：第2部 GO TO 論争”, bit (共立出版) 7 (5): 10-26 
  12. ^ 木村泉, "GO TO 論争：第3部 解説", bit, Vol.7, Issue 5, 1975, pp.27-39, 共立出版.
  13. ^ 有澤誠訳『文芸的プログラミング』p.45
  14. ^ B. Randell and J.N. Buxton, (Eds.), Software Engineering, NATO Scientific Affairs Division, Brussels, Belgium, 1969.
  15. ^ a b c “プログラミング−工芸から科学へ”, 情報処理 (情報処理学会) 18 (12): 1248-1256, (1977), NAID 110002753409 
  16. ^ a b 和田英一, "ダイクストラかく語りき", bit, Vol.9, Issue 1, 1977, pp.4-6, 共立出版.
  17. ^ a b 山崎利治, "構造的プログラミング", プログラムの設計, 共立出版, 1990, pp.113-142.
  18. ^ 玉井哲雄 (2008), “ソフトウェア工学の40年” (PDF), 情報処理 49 (7): 777-784, NAID 110006830060, http://www.graco.c.u-tokyo.ac.jp/~tamai/pub/40yearsSE.pdf 
  19. ^ Linger,R.C., Mills, H.D., Witt, B.I., Structured Programming: Theory and Practice, Addison-Wesly, 1979.
  20. ^ a b c Harel, David (1980-07-01). “On folk theorems”. Communications of the ACM 23 (7): 379–389. http://portal.acm.org/citation.cfm?doid=358886.358892. 
  21. ^ Edward Nash Yourdon ed., "Introduction (Chief Programmer Team Management of Production Programming)", Classics in Software Engineering, YOURDON inc., 1979, pp.63-64.
  22. ^ a b 木村泉 (1975). “プログラミング方法論の問題点：超職業的プログラミングについて”. 情報処理 (情報処理学会) 16 (10): 841-847. NAID 110002720277. 
  23. ^ 木村泉, 米澤明憲, 算法表現論, 岩波書店, 1982.
  24. ^ D.シャシャ, C.ラゼール, "エズガー・W・ダイクストラ", コンピュータの時代を開いた天才たち, 鈴木良尚 訳, 竹内郁雄 監訳, 日経BP社, 1998, pp.61-74. ISBN 4822280462
  25. ^ a b 中山晴康, "ダイクストラ教授との3日間", bit, Vol.9, Issue 1, 1977, pp.7-9, 共立出版.
  26. ^ Edward Nash Yourdon, 構造化手法によるソフトウェア開発, 黒田純一郎, 渡部研一 訳, 日経BP社, 1987.
  27. ^ “What led to “Notes on Structured Programming””. 2020年1月閲覧。
  28. ^ 筧, 捷彦 (1975). “ストラクチャード・プログラミング用言語”. 情報処理 (情報処理学会) 16 (10): 856-863. NAID 110002720279. 
  29. ^ E.W.ダイクストラ, W.H.J.フェイエン, プログラミングの方法, 玉井浩 訳, サイエンス社, 1991.
  30. ^ a b O.-J. Dahl and E. W. Dijkstra and C. A. R. Hoare, Structured Programming, Academic Press, London, 1972
  31. ^ Bjarne Stroustrup, “What Is Object-Oriented Programming?”, In IEEE Software, Vol. 5, Issue. 3, IEEE Computer Society Press, Los Alamitos, CA, USA, 1988, pp. 10-20
  32. ^ 構造化プログラミング(1975) p.6
  33. ^ D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが、ここでは厳密な区別はしない。
    • 金山裕 編, "構造的プログラミング −批判と支持−", bit, Vol.7, Issue 7, 1975, pp.6-13, 共立出版.
  34. ^ 所与のプログラムの正しさを後付けで証明することは、はじめから証明を意識して作られたプログラムの場合より難しいことが経験的に知られている、と言われる。
    • E.W.Dijkstra, "Programming methodologies, their objectives and their nature", Structured Programming, Infotech state of the art report, 1976, pp.205-212, Infotech International.
  35. ^ 金山裕 編, "構造的プログラミング −批判と支持−", bit, Vol.7, Issue 7, 1975, pp.6-13, 共立出版.
  36. ^ a b R.Geoff Dromey, How to Solve it by Computer, Prentice Hall, 1982.
  37. ^ E.W.ダイクストラ, “謙虚なプログラマ”, ACMチューリング賞講演集, 木村泉 訳, 共立出版, 1989, pp.23-43.
  38. ^ E.W.Dijkstra, "The Programming Task Considered as an Intellectual Challenge", 1969.
  39. ^ E.W.Dijkstra, "Concern for Correctness as a Guiding Principle for Program Composition", 1970.
  40. ^ E.W.Dijkstra, "Programming as a discipline of mathematical nature", 1973.
  41. ^ John C. Reynolds, The Craft of Programming, Prentice-Hall, 1981.
  42. ^ a b ロバート B.アンダーソン, 演習プログラムの証明, 有沢誠 訳, 近代科学社, 1980.
  43. ^ 小野寛晰, プログラムの基礎理論, サイエンス社, 1975.
  44. ^ E.W.Dijkstra, "Programming methodologies, their objectives and their nature", Structured Programming, Infotech state of the art report, 1976, pp.205-212, Infotech International.
  45. ^ a b c E.W.ダイクストラ, プログラミング原論 ― いかにしてプログラムをつくるか, 浦昭治訳, サイエンス社, 1983.
  46. ^ 二木厚吉 監修, ソフトウェアクリーンルーム手法, 日科技連, 1997.

参考文献

関連項目

関連人物

外部リンク

コンピュータ・プログラミング言語の関連項目
言語水準
言語処理系
言語分類
その他
関連項目
「https://ja-two.iwiki.icu/w/index.php?title=構造化プログラミング&oldid=82861265」から取得