こうぞうか‐プログラミング〔コウザウクワ‐〕【構造化プログラミング】
構造化プログラミング
別名：ストラクチャードプログラミング
【英】structured programming
構造化プログラミングとは、1967年にエドガー・ダイクストラ（エヅガー・ウィーブ・ダイクストラ）らによって提唱されたプログラミングの手法である。
構造化プログラミングでは、プログラムを作成する際に階層的な構造となるように、処理を小さな単位に分割する方法がとられている。構造化プログラミングでプログラムの構造を明確にすることにより、アルゴリズムによって生じる間違いを少なくすることができる。
構造化プログラミングは、ソフトウェアの生産性向上に寄与したが、1980年代に入ると構造化を大きく発展させたオブジェクト指向プログラミングが登場し、2011年1月現在に至るまでプログラミングの主流となっている。
| 開発手法： | 開発モデル 下降型プログラミング 継続的インテグレーション 構造化プログラミング クロス開発 モバイルファースト ソフトフォーク |
構造化プログラミング
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2023/05/29 14:26 UTC 版)
- ^ ソフトウェア危機の始まりと構造化プログラミングの歴史について[4]の第23章に詳しい。
- ^ "statements transferring control to labelled points" という言葉で一応 goto 文に触れている[3]
- ^ Harel,David (1980)."On Folk Theorems"(PDF)のP381の左列の中央にハーラン・ミルズ（Harlan Mills）が未公表の講義資料の中で "The Structure Theorem" と名付けたことが書かれている。この資料の出典[67]が1972年のため構造化定理が発明されたのは1970年代初頭と推測される。
- ^ 直接は無関係だが、ダイクストラはBASIC批判の急先鋒でもあった。マイコン普及以前の1970年代に既に、BASICでプログラミング教育をすべきでない、と強く主張している（wikiquote:Edsger W. Dijkstra#How do we tell truths that might hurt? (1975)）。
- ^ すなわち、プログラム検証と構造化プログラミングとは不可分の関係にある。
- ^ D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが[36]、ここでは厳密な区別はしない。
- ^ ダイクストラはプログラミングと証明を並行するのに適した、最弱事前条件をによる検証方法を考案した。ホーア論理は作り終わったものは証明できるが、これから作るプログラムについては指標を与えてくれない[47]。
- ^ 形式化にとらわれない点では（当時のダイクストラの）構造化プログラミングは形式手法と趣きが異なる。なおプログラムの正しさの証明とはウォークスルーやインスペクションによるレビューではなく、帰納法や最弱事前条件による検証を指す。 形式的でない証明の方法については、ロバートの「プログラムの証明」[43]が良い入門書の一つである。
- ^ “構造化プログラミングとは - IT用語辞典”. IT用語辞典 e-Words. 2020年6月1日閲覧。
- ^ “構造化プログラミング - 意味・説明・解説 : ASCII.jpデジタル用語辞典”. yougo.ascii.jp. 2020年6月1日閲覧。
- ^ 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.
- ^ a b c グリース, D. 筧捷彦訳 (1991). プログラミングの科学. 培風館. ISBN 4563007943
- ^ 山崎利治, "流れ図", プログラムの設計, 共立出版, 1990, pp.110-113. ISBN 4320023781
- ^ a b c d 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.
- ^ a b c N.ヴィルト, 系統的プログラミング/入門, 野下浩平, 筧捷彦, 武市正人 訳, 近代科学社, 1978.
- ^ Böhm, C.; Jacopini, G (1966). “Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules”. Communications of the ACM (ACM, New York, NY, USA) 9 (5): 366-371. CiteSeerx: 10.1.1.119.9119.
- ^ a b E. Dijkstra (1968). “Go To Statement Considered Harmful”. Communications of the ACM 11 (3): 147-148. CiteSeerx: 10.1.1.132.875.
- ^ E.W.ダイクストラ 木村泉訳 (1975), GO TO 論争：第1部 go to 文有害説, 7, 共立出版, pp. 6-9
- ^ B.リーヴェンワス編, ed. (1975), “GO TO 論争：第2部 GO TO 論争”, bit (共立出版) 7 (5): 10-26
- ^ 木村泉, "GO TO 論争：第3部 解説", bit, Vol.7, Issue 5, 1975, pp.27-39, 共立出版.
- ^ 有澤誠訳『文芸的プログラミング』p.45
- ^ B. Randell and J.N. Buxton, (Eds.), Software Engineering, NATO Scientific Affairs Division, Brussels, Belgium, 1969.
- ^ a b c E.W.ダイクストラ (1977), “プログラミング−工芸から科学へ”, 情報処理 (情報処理学会) 18 (12): 1248-1256, NAID 110002753409
- ^ a b 和田英一, "ダイクストラかく語りき", bit, Vol.9, Issue 1, 1977, pp.4-6, 共立出版.
- ^ a b 山崎利治, "構造的プログラミング", プログラムの設計, 共立出版, 1990, pp.113-142.
- ^ 玉井哲雄 (2008), “ソフトウェア工学の40年” (PDF), 情報処理 49 (7): 777-784, NAID 110006830060
- ^ Linger,R.C., Mills, H.D., Witt, B.I., Structured Programming: Theory and Practice, Addison-Wesly, 1979.
- ^ a b c Harel, David (1980-07-01). “On folk theorems”. Communications of the ACM 23 (7): 379–389.
- ^ Edward Nash Yourdon ed., "Introduction (Chief Programmer Team Management of Production Programming)", Classics in Software Engineering, YOURDON inc., 1979, pp.63-64.
- ^ a b 木村泉 (1975). “プログラミング方法論の問題点：超職業的プログラミングについて”. 情報処理 (情報処理学会) 16 (10): 841-847. NAID 110002720277.
- ^ 木村泉, 米澤明憲, 算法表現論, 岩波書店, 1982.
- ^ D.シャシャ, C.ラゼール, "エズガー・W・ダイクストラ", コンピュータの時代を開いた天才たち, 鈴木良尚 訳, 竹内郁雄 監訳, 日経BP社, 1998, pp.61-74. ISBN 4822280462
- ^ a b 中山晴康, "ダイクストラ教授との3日間", bit, Vol.9, Issue 1, 1977, pp.7-9, 共立出版.
- ^ Edward Nash Yourdon, 構造化手法によるソフトウェア開発, 黒田純一郎, 渡部研一 訳, 日経BP社, 1987.
- ^ “What led to “Notes on Structured Programming””. 2020年1月閲覧。
- ^ 筧, 捷彦 (1975). “ストラクチャード・プログラミング用言語”. 情報処理 (情報処理学会) 16 (10): 856-863. NAID 110002720279.
- ^ “E.W. Dijkstra Archive: What led to "Notes on Structured Programming" (EWD1308)”. www.cs.utexas.edu. 2021年8月16日閲覧。
- ^ E.W.ダイクストラ, W.H.J.フェイエン, プログラミングの方法, 玉井浩 訳, サイエンス社, 1991.
- ^ 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
- ^ 構造化プログラミング(1975) p.6
- ^ D.グリースはプログラムの正しさの証明を、抽象的なレベルでは正当性証明、具体的なレベルではプログラムの検証と言葉を使い分けているが、ここでは厳密な区別はしない。
- 金山裕 編, "構造的プログラミング −批判と支持−", bit, Vol.7, Issue 7, 1975, pp.6-13, 共立出版.
- ^ 所与のプログラムの正しさを後付けで証明することは、はじめから証明を意識して作られたプログラムの場合より難しいことが経験的に知られている、と言われる。
- E.W.Dijkstra, "Programming methodologies, their objectives and their nature", Structured Programming, Infotech state of the art report, 1976, pp.205-212, Infotech International.
- ^ 金山裕 編, "構造的プログラミング −批判と支持−", 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.
- ^ 二木厚吉 監修, ソフトウェアクリーンルーム手法, 日科技連, 1997.
構造化プログラミング
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/09/09 14:25 UTC 版)
「抽象化 (計算機科学)」の記事における「構造化プログラミング」の解説
詳細は「構造化プログラミング」を参照 構造化プログラミングでは、複雑なプログラム作業を小さい部分に分割し、コンポーネント間に明確なインタフェースと制御フローを導入し、副作用的に複雑さを低減させる。 単純なプログラムでは、ループからの脱出点を明示的に1つにするようコーディングするとか、関数や手続きからの脱出点を1つにするといった工夫である。 大きなシステムでは、複雑なタスクを多数のモジュールに分割することになるだろう。例えば、港湾事務所での船員への給与支払い業務システムを考えてみよう。 最も高いレベルには、典型的なエンドユーザー操作のメニューがある。 その下に、船員の新規採用や退職、小切手の印刷といった作業のための独立した実行ファイルやライブラリがある。 各独立コンポーネントは多数のソースファイルから構成され、それぞれのファイルには問題の一部に対応するプログラムコードが含まれ、他のプログラムとある決まったインタフェースを持つよう設計される。新規採用プログラムには、データを画面表示するプログラムやデータベースとのインタフェースが含まれるだろう（それらは独立したサードパーティーライブラリや静的にリンクされたライブラリルーチン群かもしれない）。 また、港湾と船の間でデータを交換する処理が必要とされる場合も考えられ、その場合はさらに様々なコンポーネントを必要とする。 このような階層によってコンポーネント毎に実装の詳細を隔離する効果が生まれる。そして、その考え方を重視し、拡張して生まれたのがオブジェクト指向プログラミングである。
※この「構造化プログラミング」の解説は、「抽象化 (計算機科学)」の解説の一部です。
「構造化プログラミング」を含む「抽象化 (計算機科学)」の記事については、「抽象化 (計算機科学)」の概要を参照ください。
構造化プログラミング
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/05/22 03:45 UTC 版)
「コンピュータ分野における対立」の記事における「構造化プログラミング」の解説
手続き型プログラミングの生産性・可読性・保守性の向上のために構造化プログラミングが提唱された。特にgoto文を全面禁止すべきか否かで論争が発生した（プログラミング言語#改良も参照）。
※この「構造化プログラミング」の解説は、「コンピュータ分野における対立」の解説の一部です。
「構造化プログラミング」を含む「コンピュータ分野における対立」の記事については、「コンピュータ分野における対立」の概要を参照ください。
構造化プログラミングと同じ種類の言葉
- 構造化プログラミングのページへのリンク
