WordNet

of or relating to an organization; "organizational structure" (同)organisational

PrepTutorEJDIC

組織上の,構成上の

Wikipedia preview

出典(authority):フリー百科事典『ウィキペディア（Wikipedia）』「2013/03/17 22:20:30」(JST)

wiki ja

構造化プログラミング（こうぞうかプログラミング、structured programming）とは、1960年代後半にエドガー・ダイクストラらによって提唱された仮想機械モデルに基づく段階的詳細化法を用いたプログラミングのことを言う。歴史的経緯から、構造化プログラミングはIBMのMillsの提案に由来するgoto-lessプログラミングとして一部分を切り取られた形で広く知られている^[1]^[2]^[3]。

1 概要
2 歴史
3 構造化プログラミングの構成要素
- 3.1 三つの構造化文
- 3.2 プログラムの正しさの証明
4 goto論争
- 4.1 ダイクストラの主張
- 4.2 goto擁護派
- 4.3 中立派
- 4.4 その他の話題
5 注釈
6 参照元
7 参考文献
8 関連項目
- 8.1 関連人物

概要

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

歴史

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

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

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

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

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

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

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

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

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

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

三つの構造化文

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

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

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

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

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

プログラムの正しさの証明

1960年代後半、科学の領域にプログラミング方法論が現れると、初期の計算機でもてはやされたプログラムの効率を良くする技巧^[32]だけでなく、品質やプログラムの正しさという問題にも関心が集まった^[15]。

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

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

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

goto論争

ダイクストラの主張

構造化プログラミングを提唱するダイクストラは、理論の帰結から、goto文を使うべきでないとする。

ダイクストラによる“Go To Statement Considered Harmful”^[8]の趣旨は次の通りである。

人間が時間によって変化するプロセスを把握する能力は、プログラムの静的な関係を把握する能力に比べて劣っているため、静的なプログラムテキストの構造と時間によって変化するプロセスの構造をなるべく近づけるのが重要である。

そのためにはプロセスの進捗を表す簡潔な指標が必要がある。指標とは例えば実行中の行番号・その時点でのスタックトレース・行番号とループを回った回数のペアなどである。

例えば、1人が部屋に入るごとにカウンタを増やしていくプログラムにおいて、カウンタが室内の人数-1である瞬間はどこにあるのかという問いに答える際に、簡潔な指標があればすぐ答えられるが、簡潔な指標がなければ正確な答えは難しくなる。

goto文を無条件に許してしまうと簡潔な指標は得られなくなってしまうため、高水準プログラミング言語においてはgoto文は廃止するべきである。

以上が“Go To Statement Considered Harmful”の趣旨である。

その一方で、ダイクストラは“Structured Programming”^[4]においてはgoto文には触れていないとクヌースは指摘している^[6]。実際に“Structured Programming”においては“sequencing should be controlled by alternative, condtional and repetitive clauses and procedure calls, rather than by statements transferring control to labelled points.”との1文があるのみでそれ以外では触れていない。

また、3つの基本構造についても、“Go To Statement Considered Harmful”においては“I do not claim that the clauses mentioned (引用者註: 順次・分岐・手続き呼び出し・反復) are exhaustive in the sense that they will satisfy all needs”とし、プロセスの進捗を表す簡潔な指標が存在する限りは3つの基本構造には固執していない。

goto擁護派

一方、goto文を使わずに3つの基本構造による代替を行うと、理論上は同値であっても実際にはプログラムの実行速度や記憶容量の点で性能が劣化する場合があることを示し、goto文を擁護する意見もあった^[48]。

ACMの年次大会(1972)の討論会では、トップダウンでプログラムを分割するよりgoto文を使う方が適した事例があり、証明には関心がないという意見(William Wait)や、goto文を残せば選択の余地があるが、無くしてしまうと必要になったとき困るだろうという意見(Guy Steel)などが出された^[12]。

条件文とgoto文を正しく使うことで、FORTRANでもALGOLの基本機能を実現できることを例に挙げ、プログラマは必要な機能がプログラミング言語で直接表現できないとき、どのようにに実装するか工夫できるべきであるという主張もあった(S.W.スリア)^[33]。

中立派

特殊な場合にはgotoを使った方がプログラムの正当性を証明しやすくなると考える人もいる。例えばドナルド・クヌースは、著書「文芸的プログラミング」の中でそのような例をいくつかあげている^[6]。

こうした理由から、goto文を撲滅するのではなく上手に使い分けるべきだと考える人もいる^[誰?]。

goto文論争が不毛なのは、「構造化プログラミングの観点からgoto文を使うのは望ましくない」という結論は真だが、「goto文を使わなければ構造化プログラミングになる」というわけではない点である。構造化プログラミングの本質の一つは、状態遷移の適切な表現方法とタイミングを見極めることである^[49]。これはプログラムの良し悪しを決める永遠の命題であるといっていい^[要出典]。

現在C言語を除く主流派の言語では、そのままのgoto文はほとんど見られなくなった。替わりにbreak文、continue文、もしくは例外処理のような特殊脱出(去勢されたgotoとも呼ばれる^[要出典])をサポートし、単純な構造化制御だけでは弱いと考えられる部分を補っている。また、Scheme等でサポートされている継続は「引数付きgoto」と呼ばれることもある^{[誰によって?]}。またクロージャやコードブロック、継続のような強力な制御機構を持つ言語ではそもそも抽象度の低いgoto文を使う必要性は低い。例えばHaskellにおいてはモナドを利用して例外や非決定性計算などの様々な制御構造を表現できる^[要出典]。またSmalltalkやIoにおいても制御構造はブロックを扱うメソッドとして表現している^[要出典]。

一方で、例えば1999年から設計されたD言語はgoto文を含んでいる^[50]。また、PHPも2009年にリリースされた5.3において制限された形ではあるがgoto文が追加された^[51]。これはgoto文を支持する者^[誰?]が少なからず存在する事実を示す例である。

その他の話題

それまでの職人芸的なプログラミングの時代から、構造化プログラミングというパラダイムの提唱によって、プログラミング技法の体系化を試みるプログラミング工学という学問が芽生えたと言っても過言では無いだろう^{[要検証 – ノート]}。

なお、論文“Go To Statement Considered Harmful”は、その半ば挑戦的な題名がプログラミング以外の様々な分野に及んで評判となり、それをもじった様々な “～ Considered Harmful”といった論説やジョークが生まれたen:Considered harmful 。極めつきは、何かが有害であることだけが強調される題名の有害性を指摘した“‘Considered Harmful’ Essays Considered Harmful”であろう。

ダイクストラは What led to “Notes on Structured Programming” (『「構造化プログラミングに関する覚え書き」へと導いたもの』)で、“A case against goto statement” (『Goto 文が不利な場合』)と題した論文を投稿したが、出版を早めるために編集者により “letter to the Editor” (『編集者への手紙』)と改題され、その過程でその編集者独自の考案で新たなタイトル("The goto statement considered harmful")を付けられた。その編集者とはニクラウス・ヴィルトであった、と述べている。

同じくWhat led to "Notes on Structured Programming" においてダイクストラは、Millsによって矮小化されたgoto文廃止という概念のもと、IBMが用語としての「構造化プログラミング」を盗用したと語っている。

ダイクストラの著書は、分かりにくいことと誤解を招きやすいことで定評がある^[13]^[44]^[52]。それを憂いたグリースは、ダイクストラ流のプログラミングについて体系化した書籍「プログラミングの科学」(The Science of Programming)を書いた^[44]。

注釈

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

参照元

^ 金藤栄孝, 二木厚吉, “多重ループからの脱出でのgoto文の是非：Hoare理論の観点から”, 情報処理学会論文誌, Vol. 45, Issue 3, 2004, pp. 770-784.
^ 金藤栄孝, 二木厚吉, “有限状態機械に基づくプログラミングでのgoto文使用の是非 : Hoare論理の観点から”, 情報処理学会論文誌, Vol. 45, Issue 9, 2004, pp. 2124-2137.
^ H.D.Mills, R.C.Linger, a.R.Hevner, “ボックス構造化情報システム”, ソフトウェアエンジニアリング論文集80's, Tom DeMarco, Timothy Lister編著, 児玉公信監訳, 翔泳社, 2006, pp.187-219.
^ ^a ^b ^c ^d ^e ^f ^g ^h 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.
^ ^a ^b ^c D.グリース, プログラミングの科学, 筧捷彦訳, 培風館, 1991.
^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ D. E. Knuth, “Structured Programming with go to Statements”, In Computing Surveys, Vol. 6, No. 4, ACM, New York, NY, USA, 1974, pp. 261-301.
^ 山崎利治, "流れ図", プログラムの設計, 共立出版, 1990, pp.110-113.
^ ^a ^b ^c ^d E. Dijkstra. “Go To Statement Considered Harmful”, In Communications of the ACM, Vol. 11, Issue 3, ACM, New York, NY, USA, 1968, pp. 147-148.
^ C. Böhm and G Jacopini. “Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules” In Communications of the ACM, Vol. 9, Issue 5, ACM, New York, NY, USA, 1966, pp. 366-371
^ Linger,R.C., Mills, H.D., Witt, B.I., Structured Programming: Theory and Practice, Addison-Wesly, 1979.
^ E.W.ダイクストラ, "GO TO 論争：第1部 go to 文有害説", 木村泉訳, bit, Vol.7, Issue 5, 1975, pp.6-9, 共立出版.
^ ^a ^b B.リーヴェンワス編, "GO TO 論争：第2部 GO TO 論争", 木村泉訳, bit, Vol.7, Issue 5, 1975, pp.10-26, 共立出版.
^ ^a ^b 木村泉, "GO TO 論争：第3部解説", bit, Vol.7, Issue 5, 1975, pp.27-39, 共立出版.
^ B. Randell and J.N. Buxton, (Eds.), Software Engineering, NATO Scientific Affairs Division, Brussels, Belgium, 1969.
^ ^a ^b ^c ^d ^e ^f E.W.ダイクストラ, "プログラミング−工芸から科学へ", 情報処理, Vol.18, No.12, 1977, pp.1248-1256, 情報処理学会.
^ ^a ^b 和田英一, "ダイクストラかく語りき", bit, Vol.9, Issue 1, 1977, pp.4-6, 共立出版.
^ ^a ^b 山崎利治, "構造的プログラミング", プログラムの設計, 共立出版, 1990, pp.113-142.
^ ^a ^b 玉井哲雄, "ソフトウェア工学の40年"， 情報処理， Vol.49, No.7, 2008， pp.777-784.
^ Edward Nash Yourdon ed., "Introduction (Chief Programmer Team Management of Production Programming)", Classics in Software Engineering, YOURDON inc., 1979, pp.63-64.
^ 木村泉, 米澤明憲, 算法表現論, 岩波書店, 1982.
^ ^a ^b 木村泉, "プログラミング方法論の問題点：超職業的プログラミングについて", 情報処理, Vol.16, No.10, 1975, pp.841-847, 情報処理学会.
^ D.シャシャ, C.ラゼール, "エズガー・W・ダイクストラ", コンピュータの時代を開いた天才たち, 鈴木良尚訳, 竹内郁雄監訳, 日経BP社, 1998, pp.61-74.
^ 玉井哲雄, "ソフトウェア産業とソフトウェア研究の沈滞状況について"， SEAMAIL, Vol.11, No.3, 1997, pp.2-5.
^ 玉井哲雄, "9th ICSEに参加して"， SEAMAIL, Vol.2, No.7, 1987, pp.22-25.
^ ^a ^b 中山晴康, "ダイクストラ教授との3日間", bit, Vol.9, Issue 1, 1977, pp.7-9, 共立出版.
^ Edward Nash Yourdon, 構造化手法によるソフトウェア開発, 黒田純一郎, 渡部研一訳, 日経BP社, 1987.
^ 筧捷彦, "ストラクチャード・プログラミング用言語", 情報処理, Vol.16, No.10, 1975, pp.856-863, 情報処理学会.
^ ^a ^b ^c N.ヴィルト, 系統的プログラミング/入門, 野下浩平, 筧捷彦, 武市正人訳, 近代科学社, 1978.
^ C.A.R.Hoare, "Structured programming in introductory programming courses", Structured Programming, Infotech state of the art report, 1976, pp.257-263, Infotech International.
^ ^a ^b O.-J. Dahl and E. W. Dijkstra and C. A. R. Hoare, Structured Programming, Academic Press, London, 1972
^ 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
^ E.W.ダイクストラ, "マイクロコンピュータのインパクト", 川合慧訳, bit, Vol.7, Issue 6, 1975, pp.4-6, 共立出版.
^ ^a ^b 金山裕編, "構造的プログラミング −批判と支持−", bit, Vol.7, Issue 7, 1975, pp.6-13, 共立出版.
^ ^a ^b R.Geoff Dromey, How to Solve it by Computer, Prentice Hall, 1982.
^ E.W.ダイクストラ, “謙虚なプログラマ”, ACMチューリング賞講演集, 木村泉訳, 共立出版, 1989, pp.23-43.
^ E.W.Dijkstra, "The Programming Task Considered as an Intellectual Challenge", 1969.
^ E.W.Dijkstra, "Concern for Correctness as a Guiding Principle for Program Composition", 1970.
^ E.W.Dijkstra, "Programming as a discipline of mathematical nature", 1973.
^ John C. Reynolds, The Craft of Programming, Prentice-Hall, 1981.
^ ^a ^b ロバート B.アンダーソン, 演習プログラムの証明, 有沢誠訳, 近代科学社, 1980.
^ 小野寛晰, プログラムの基礎理論, サイエンス社, 1975.
^ E.W.Dijkstra, "Programming methodologies, their objectives and their nature", Structured Programming, Infotech state of the art report, 1976, pp.205-212, Infotech International.
^ ^a ^b ^c E.W.ダイクストラ, プログラミング原論 ― いかにしてプログラムをつくるか, 浦昭治訳, サイエンス社, 1983.
^ ^a ^b ^c 二木厚吉監修, ソフトウェアクリーンルーム手法, 日科技連, 1997.
^ ^a ^b 淵一博, 新世代プログラミング, 共立出版, 1986.
^ 和田英一, "「構造的...」と「いかにして...」", 情報処理, Vol.16, No.3, 1975, pp.169, 情報処理学会.
^ マイケル・ジャクソン, 吉村鉄太郎, 山崎利治, 大野徇郎, "ソフトウェア設計哲学", bit, Vol.11, Issue 2, 1979, pp.4-12, 共立出版.
^ Frank Rubin, "GOTO Considered Harmful" Considered Harmful, Communications of the ACM, Vol.30, Issue 3, 1987, pp.195-196.
^ E.W.ダイクストラ, W.H.J.フェイエン, プログラミングの方法, 玉井浩訳, サイエンス社, 1991.
^ Language Reference Goto Statement
^ PHP マニュアル goto
^ 木村泉, "ダイクストラ教授とふた付き命令", bit, Vol.8, Issue 9, 1976, pp.29-34, 共立出版.

参考文献

落水浩一郎『ソフトウェア工学実践の基礎－分析・設計・プログラミング』。
飯泉純子, 大槻繁『ずっと受けたかったソフトウェア設計の授業』。
D.L.Parnas (1975), Use of the concept of transparency in the design of hierarchically structured systems
D.L.Parnas (1971), Information Distribution Aspects of Design Methodology
B.H.Liskov, S.N.Zilles (1974), Programming with Abstract Data Type
金藤栄孝,二木厚吉 (2004), 多重ループからの脱出でのgoto文の是非 : Hoare理論の観点から, http://ci.nii.ac.jp/naid/110002712129
金藤栄孝,二木厚吉 (2004), 有限状態機械に基づくプログラミングでのgoto文使用の是非 : Hoare論理の観点から, http://ci.nii.ac.jp/naid/110002712260
林達也, システム設計言語DEAPLANについて, http://ci.nii.ac.jp/naid/110002719409
D.グリース; 筧捷彦訳『プログラミングの科学』培風館、1991年。
Donald E. Knuth; 有澤誠訳、「第2章 go to文を用いた構造化プログラミング」『文芸的プログラミング』アスキー、1994年。
E.W.ダイクストラ; 浦昭治訳『プログラミング原論 ― いかにしてプログラムをつくるか』サイエンス社、1983年。
E.W.ダイクストラ; W.H.J.フェイエン; 玉井浩訳『プログラミングの方法』サイエンス社、1991年。
E.W.ダイクストラ; C.A.R.ホーア; O.-J.ダール; 野下浩平訳『構造化プログラミング』サイエンス社、1975年。

1. 成人における単極性うつ病：支持的心理療法 unipolar depression in adults supportive psychotherapy
2. 緩和ケア：ナーシングホーム palliative care nursing home
3. 成人における双極性障害：心理教育およびその他の維持的心理療法 bipolar disorder in adults psychoeducation and other adjunctive maintenance psychotherapies
4. 成人における神経性無食欲症：認知行動療法（CBT） anorexia nervosa in adults cognitive behavioral therapy cbt
5. 決定分析 decision analysis

Japanese Journal

双極Ⅱ型障害は過剰診断されているか (特集双極Ⅱ型障害をどう診るか)

臨床精神医学 = Japanese journal of clinical psychiatry 46(3), 325-329, 2017-03
NAID 40021121003

水素結合と分子ジッパーで構造化した二次元分子薄膜による鉄表面の防錆の試み

防錆管理 61(3), 109-113, 2017-03
NAID 40021119991

何ができるようになるか社会科・地理歴史科・公民科で育成を目指す資質・能力 : 知識の構造化の視点からの指導のポイント知識の構造化につながる「問い」を導き出す「視点」となる「概念」 (特集改訂キーワードで読み解く「新しい社会科」) -- (改訂の基本軸とこれからの社会科 : 指導計画のたて方)

社会科教育 54(3), 28-31, 2017-03
NAID 40021119363

Related Pictures

★リンクテーブル★

リンク元	「組織化」「組織過程」
関連記事	「構造」

「組織化」

　　[★]

英: organization、(英)organisation、organize、(英)organise、orchestrate、organizational
関: オーガナイズ、機構、器質化、構築、組織、組成、編成、構造化、組織過程

「組織過程」

　　[★]

英: organizational
関: 組織化、構造化

「構造」

　　[★]

英: structure、formation、architecture、conformation、constitution、makeup
関: 気質、組立、形成、高次構造、構成、構築、コンフォメーション、コンホメーション、組成、体質、配座、編成、立体構造、立体配座、仕組み、体格、建築物、構造物、構造体、成立

[6] ソフトウェア危機の始まりと構造化プログラミングの歴史について^[5]の第23章に詳しい。

[17] このカンファレンスの発表が「構造化プログラミング」という語の元であるという主張の出典は^[6]

[36] D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが^[33]、ここでは厳密な区別はしない。

[48] ダイクストラはプログラミングと証明を並行するのに適した、最弱事前条件をによる検証方法を考案した。ホーア論理は作り終わったものは証明できるが、これから作るプログラムについては指標を与えてくれない^[44]。

[51] 形式化にとらわれない点では（当時のダイクストラの）構造化プログラミングは形式手法と趣きが異なる。なおプログラムの正しさの証明とはウォークスルーやインスペクションによるレビューではなく、帰納法や最弱事前条件による検証を指す。形式的でない証明の方法については、ロバートの「プログラムの証明」^[40]が良い入門書の一つである。

[53] ジャクソンは構造化プログラミング手法の一つであるジャクソン法で有名なコンピュータ・コンサルタント。

[goto_nested_loop-1] 金藤栄孝, 二木厚吉, “多重ループからの脱出でのgoto文の是非：Hoare理論の観点から”, 情報処理学会論文誌, Vol. 45, Issue 3, 2004, pp. 770-784.

[goto_finite_state_machines-2] 金藤栄孝, 二木厚吉, “有限状態機械に基づくプログラミングでのgoto文使用の是非 : Hoare論理の観点から”, 情報処理学会論文誌, Vol. 45, Issue 9, 2004, pp. 2124-2137.

[box_structured-3] H.D.Mills, R.C.Linger, a.R.Hevner, “ボックス構造化情報システム”, ソフトウェアエンジニアリング論文集80's, Tom DeMarco, Timothy Lister編著, 児玉公信監訳, 翔泳社, 2006, pp.187-219.

[structured_programming-4] ^ ^a ^b ^c ^d ^e ^f ^g ^h 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.

[the_science_of_programming-5] D.グリース, プログラミングの科学, 筧捷彦訳, 培風館, 1991.

[structured_programming_with_go_to_statements-7] ^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ D. E. Knuth, “Structured Programming with go to Statements”, In Computing Surveys, Vol. 6, No. 4, ACM, New York, NY, USA, 1974, pp. 261-301.

[program_design_chap6sec1-8] 山崎利治, "流れ図", プログラムの設計, 共立出版, 1990, pp.110-113.

[go_to_statement_considered_harmful-9] E. Dijkstra. “Go To Statement Considered Harmful”, In Communications of the ACM, Vol. 11, Issue 3, ACM, New York, NY, USA, 1968, pp. 147-148.

[flow_diagrams_turing_machines_and_languages_with_only_two_formation_rules-10] C. Böhm and G Jacopini. “Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules” In Communications of the ACM, Vol. 9, Issue 5, ACM, New York, NY, USA, 1966, pp. 366-371

[sp_theory_and_practice-11] Linger,R.C., Mills, H.D., Witt, B.I., Structured Programming: Theory and Practice, Addison-Wesly, 1979.

[bit1975_go_to_statement_considered_harmful-12] E.W.ダイクストラ, "GO TO 論争：第1部 go to 文有害説", 木村泉訳, bit, Vol.7, Issue 5, 1975, pp.6-9, 共立出版.

[bit1975_goto_controversy-13] B.リーヴェンワス編, "GO TO 論争：第2部 GO TO 論争", 木村泉訳, bit, Vol.7, Issue 5, 1975, pp.10-26, 共立出版.

[bit1975_explanation-14] 木村泉, "GO TO 論争：第3部解説", bit, Vol.7, Issue 5, 1975, pp.27-39, 共立出版.

[software_engineering_conferences1968-15] B. Randell and J.N. Buxton, (Eds.), Software Engineering, NATO Scientific Affairs Division, Brussels, Belgium, 1969.

[from_craft_to_scientific_discipline-16] ^ ^a ^b ^c ^d ^e ^f E.W.ダイクストラ, "プログラミング−工芸から科学へ", 情報処理, Vol.18, No.12, 1977, pp.1248-1256, 情報処理学会.

[also_speech_dijkstra-18] 和田英一, "ダイクストラかく語りき", bit, Vol.9, Issue 1, 1977, pp.4-6, 共立出版.

[program_design_chap6sec2-19] 山崎利治, "構造的プログラミング", プログラムの設計, 共立出版, 1990, pp.113-142.

[tamai_40years_se-20] 玉井哲雄, "ソフトウェア工学の40年"， 情報処理， Vol.49, No.7, 2008， pp.777-784.

[classics_in_software_engineering-21] Edward Nash Yourdon ed., "Introduction (Chief Programmer Team Management of Production Programming)", Classics in Software Engineering, YOURDON inc., 1979, pp.63-64.

[algorithm_representation_theory-22] 木村泉, 米澤明憲, 算法表現論, 岩波書店, 1982.

[problems_of_programming_methodology-23] 木村泉, "プログラミング方法論の問題点：超職業的プログラミングについて", 情報処理, Vol.16, No.10, 1975, pp.841-847, 情報処理学会.

[out_of_thier_minds-24] D.シャシャ, C.ラゼール, "エズガー・W・ダイクストラ", コンピュータの時代を開いた天才たち, 鈴木良尚訳, 竹内郁雄監訳, 日経BP社, 1998, pp.61-74.

[tamai_inactive_se-25] 玉井哲雄, "ソフトウェア産業とソフトウェア研究の沈滞状況について"， SEAMAIL, Vol.11, No.3, 1997, pp.2-5.

[tamai_9thicse-26] 玉井哲雄, "9th ICSEに参加して"， SEAMAIL, Vol.2, No.7, 1987, pp.22-25.

[three_days_with_dijkstra-27] 中山晴康, "ダイクストラ教授との3日間", bit, Vol.9, Issue 1, 1977, pp.7-9, 共立出版.

[managing_the_structured_techniques-28] Edward Nash Yourdon, 構造化手法によるソフトウェア開発, 黒田純一郎, 渡部研一訳, 日経BP社, 1987.

[languages_for_structured_programming-29] 筧捷彦, "ストラクチャード・プログラミング用言語", 情報処理, Vol.16, No.10, 1975, pp.856-863, 情報処理学会.

[systematic_programming-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.

[structured_programming_72-32] O.-J. Dahl and E. W. Dijkstra and C. A. R. Hoare, Structured Programming, Academic Press, London, 1972

[what_is_object-oriented_programming-33] 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

[bit1975_microcomputer-34] E.W.ダイクストラ, "マイクロコンピュータのインパクト", 川合慧訳, bit, Vol.7, Issue 6, 1975, pp.4-6, 共立出版.

[bit1975_structured_programming-35] 金山裕編, "構造的プログラミング −批判と支持−", bit, Vol.7, Issue 7, 1975, pp.6-13, 共立出版.

[how_to_solve_it_by_computer-37] R.Geoff Dromey, How to Solve it by Computer, Prentice Hall, 1982.

[the_humble_programmer-38] E.W.ダイクストラ, “謙虚なプログラマ”, ACMチューリング賞講演集, 木村泉訳, 共立出版, 1989, pp.23-43.

[ewd273-39] E.W.Dijkstra, "The Programming Task Considered as an Intellectual Challenge", 1969.

[ewd288-40] E.W.Dijkstra, "Concern for Correctness as a Guiding Principle for Program Composition", 1970.

[ewd361-41] E.W.Dijkstra, "Programming as a discipline of mathematical nature", 1973.

[the_craft_of_programming-42] John C. Reynolds, The Craft of Programming, Prentice-Hall, 1981.

[proving_programs_correct-43] ロバート B.アンダーソン, 演習プログラムの証明, 有沢誠訳, 近代科学社, 1980.

[basic_theorem_of_programs-44] 小野寛晰, プログラムの基礎理論, サイエンス社, 1975.

[programming_methodologies-45] E.W.Dijkstra, "Programming methodologies, their objectives and their nature", Structured Programming, Infotech state of the art report, 1976, pp.205-212, Infotech International.

[a_discipline_of_programming-46] E.W.ダイクストラ, プログラミング原論 ― いかにしてプログラムをつくるか, 浦昭治訳, サイエンス社, 1983.

[software_cleanroom-47] 二木厚吉監修, ソフトウェアクリーンルーム手法, 日科技連, 1997.

[new_generation_programming-49] 淵一博, 新世代プログラミング, 共立出版, 1986.

[structured_and_how_to-50] 和田英一, "「構造的...」と「いかにして...」", 情報処理, Vol.16, No.3, 1975, pp.169, 情報処理学会.

[bit1979_software_design-52] マイケル・ジャクソン, 吉村鉄太郎, 山崎利治, 大野徇郎, "ソフトウェア設計哲学", bit, Vol.11, Issue 2, 1979, pp.4-12, 共立出版.

[rubin87goto-54] Frank Rubin, "GOTO Considered Harmful" Considered Harmful, Communications of the ACM, Vol.30, Issue 3, 1987, pp.195-196.

[a_method_of_programming-55] E.W.ダイクストラ, W.H.J.フェイエン, プログラミングの方法, 玉井浩訳, サイエンス社, 1991.

[d_goto-56] Language Reference Goto Statement

[php_goto-57] PHP マニュアル goto

[bit1976_guarded_command-58] 木村泉, "ダイクストラ教授とふた付き命令", bit, Vol.8, Issue 9, 1976, pp.29-34, 共立出版.

匿名

検索

案内

案内

構造化