ノート:構造化プログラミング

話題1

私としましては、

• GOTO文が構造化プログラミングにおいて避けられる理由（ホーア論理をもとにした）
• 構造化プログラミングの欠点とその欠点の改善手法としてのデータ抽象、抽象データ型

の２点を記述したいと思うのですが、良い文案がありません。どなたか良い文を記述できるのであればよろしくお願いします。

加えて、goto文の論争についてはバッサリ削除してしまっていいと思います。--I.hidekazu（会話） 2012年11月23日 (金) 12:07 (UTC) Structured Programming を読みます。--I.hidekazu（会話） 2012年12月1日 (土) 12:51 (UTC)

一応、それなりの理解に到達したと思いましたので自分で編集を行いました。--I.hidekazu（会話） 2018年8月25日 (土) 13:55 (UTC)

話題2

構造化とはサブルーチンに分けること、と読める解説ですが、むしろそれはモジュール化では？　後半に説明されている３要素を階層化してアルゴリズムを記述することこそ構造化だと理解していましたが、それでいいんですよね？Sampo 03:21 2003年12月1日 (UTC)

ささいな疑問点

• 「goto文」という表現。多くの場合、statementの訳語で文を使っていると思うけれど、幅広い言語を見据えても「文」という表現が正しいのか？
• 「goto」は「go to」に由来する、という意味の解説。間違っているわけではないけれど、一部のBASICなど、文法上「go to」のようにスペースをあけて記述するプログラミング言語はないわけではないので、やや誤解をはらんでいる気がしなくもない。

Kozawa 04:42 2003年12月1日 (UTC)

1.goto命令の方がベターですよね。

2.goto命令、goto文は一般名詞的に扱っていいと思うので、個々のプログラミング言語でなんと呼んでいるかはこの際関係ないんじゃないでしょうか。Sampo 04:46 2003年12月1日 (UTC)

話題3

Mi-neko 05:10 2004年1月21日 (UTC)

構造化プログラミングって

• トップダウン式開発はボトムアップ式開発に勝る

という前提の元、それに拠ってシステム設計を行う際の

• 段階的詳細化

という概念(設計手法?)の提唱、それらを実装として落とし込むときに、

• "順接" "反復" "分岐" の3要素による階層化で全ての手続きを表現する(=表現できる)
• サブルーチンを「再利用」ではなく「抽象化」目的でも利用する(=段階的詳細化の実装法)

という具体的な実装手法

の三身一体かと思っていました。 私も理解が深くはないので、自信は持てません。ホントのところはどうなんでしょう?

それと goto文なのですが、 構造化プログラミングは手続き型言語でのプログラム手法を論じていると 思いますので、言語の構成要素として

• 式
• 文

がある、という前提にたってしまってよいのではないでしょうか? 私には"命令"は、意味が広すぎて曖昧に感じられます。

識者の見解を望む。--Mi-neco氏ここまで

>しかし最新設計であるD言語では意図的にgoto文を引き継いでいる。これはいかにgoto文支持の声が根強いかを如実に示している。

D言語の設計がどのような議論の元で行われたか知りませんが、 最近の一言語に取り入れられたからといってgoto文支持の声が根強いということは出来ないのではないでしょうか？ この部分を太字で表記することはやや主観的に感じられます。----以上の署名の無いコメントは、133.249.52.2（会話・投稿記録）さんによるものです。 12:11 2006年8月16日(UTC)

関係しますが、「意図的に」が意味不明ですね。言語仕様の決定が意図的なのは当然で、どのような意図かを言わないと無意味でしょう。--U3002 2006年8月16日 (水) 04:58 (UTC)

＞構造化とはサブルーチンに分けること、と～～むしろそれはモジュール化では？

モジュール化するにはサブルーチンに分けることが必要ですが、サブルーチンに分けることがイコールモジュール化なわけではありません。

＞３要素を階層化してアルゴリズムを記述することこそ構造化

違います。構造化を行なうにあたって、強力な構造破壊兵器であるgoto文を使わずに済ませる方法を模索した結果、構造化定理によってgoto文無しに書けることが証明されたので、「該三要素を用いましょう、goto文は使わないようにしましょう。そうすれば、構造を破壊することは困難になり、自然な流れで構造化出来るようになります」という主張です。その後も、goto文は名前を変え姿を変え或いは隠されて、役割を制限されてプログラミング言語に残り続けています。そしてその気があるのなら、それらを使って構造化による利益を投げ捨てることは今でもなお不可能ではありません。構造化しないことによる不利益が何かを知っていれば、ですが。

＞トップダウン式開発はボトムアップ式開発に勝るという前提の元

違います。構造化した結果「トップ」と「ボトム」を分離出来るようになったのです。なので「段階的詳細化」とか何とかは、単にトップダウン信者の主張であって構造化そのものとは無関係です。ボトムアップ信者にはまた逆の主張があり、それもまた構造化そのものとは無関係なのです。

構造化というのは、それまでは一本の木から削り出しで作らなければならなかった「机」を、脚や天板や側板を別々の木から別々に削り出して作った「部品」を組み立てて「机」を作れるようにしようぜ、ということです。そしてモジュール化とは、その脚や天板の接合規格を設けることで様々な組み合わせを可能にする、ということです。モジュール化の為には構造化が必要なので、構造化することで（可能性として）モジュール化による利益（＝抽象化による再利用）だって可能になりますよ、というセールストークでもあります。

構造化とは、プログラムの各部分を構造と看做すことで分解し、それぞれの独立性を高めることで、理解し易くバグの発生を抑制し大規模な開発に耐えられるようにする為の手法であり設計思想です。おかげさまで、当時の悪夢のようなスパゲティーボールから比べると、筆舌に尽くし難い改善がなされました。今でもスパゲティーだという意見もあるかも知れませんが、それでも、筆舌に尽くし難い改善がなされているのです。再利用だの段階的詳細化だの、それに比べれば些細なこと、只の派生的利益です。それが不可能な状況を改善し、いずれ其処へ到達せしめる基礎を立脚するものが構造化なのです。それは既に果たされ、今では当然以前の当たり前どころかそうでないものが想像出来ないほどに常識だと認識しているから、「構造化」が指し示しているものが何かわかり難くなっているだけです。

＞「文」という表現が正しいのか？

少なくとも「式」よりは適切です。また「命令」の場合、全てが（CPUに対する）命令であるか、「大前提としてプログラムにより制御しようとしているCPU」以外の被命令対象があるはずです。例えばコンパイラー制御命令とか、プリプロセッサー制御命令とか。また、幅広い言語にまたがる表現としてgoto文は制御文の一つであることから、制御文が文と呼ばれるのは妥当だと思います。世の中の流れとして、制御文が制御命令と呼ばれるようになればgoto命令と呼ぶのが適切だろうと思いますし、制御式と呼ばれるようになればgoto式が適切になるでしょう。逆に、アセンブリ言語では全て「命令」なので、goto文に相当するものは「JMP命令」と呼ばれています。それは制御文ではなく（CPUに対する）命令なので、それが適切だと思います。

＞意図的にgoto文を引き継いでいる～～どのような意図か

D言語が構造化プログラミング言語の系譜であり、その多くがgoto文を否定し廃止代替する流れの中で、新たにデザインされた言語仕様の制御文にわざわざgoto文が採択されているというのは、流れに逆らってgoto文の有意性を認める根強い意見があった為だと考えるのは自然だと思われます。確かに、深く考えず気軽に採択しただけの可能性もあるでしょうが、前述した通り多くがgoto文を否定し廃止代替する流れの中で「気軽に採択した」と主張するのは、その方が不自然でしょう。

世界最狂の魔法使いＣray-Ｇ 2009年12月7日 (月) 20:34 (UTC)

I.hidekazuさんの修正が酷すぎる件

I.hidekazuさんが 平成30年8月23日 (木) 14:05(UTC) から 平成30年8月20日 (月) 13:32(UTC) の間に編集した内容が酷過ぎます。

I.hidekazuさんは本当に 7.4 Structured Programming を読まれたのでしょうか？ それを読んでいれば、このような酷い記事の修正にはならないはずです。 完全に構造化プログラミングを誤解しまくっている典型例です。 これでは goto-lessプログラミングを少し発展させただけではないですか。

ダイクストラ博士はその 7.4 Structured Programming でgoto文や「連接・選択・繰り返し」については以下のことしか書いていません。

"In particular: when programs for a sequential computer are expressed as a linear sequence of basic symbols of a programming language, sequencing should be controlled by alternative, conditional and repetitive clauses and procedure calls, rather than by statements transferring control to labelled points."

本当にこれだけです。ダイクストラ博士が「Go to 文有害説」を発表したのは事実ですが、構造化プログラミングにおいてダイクストラ博士はそのようなレベルの低い話からはすでに卒業しているのです。

構造化プログラミングとは以下のことを指しています（本文の歴史的発展の項目にも一部書かれています）。

• 良く構造化されたプログラム (well-structured programs) → 制御フローのことではない
• 大きなプログラムの理解を助ける段階的抽象化 (step-wise abstraction) → これの反語が段階的詳細化
• 抽象データとその操作の抽象文の共同詳細化 (joint refinement) → オブジェクト指向のクラスに似た考え
• プログラムの階層化（真珠のネックレスとしてのプログラム） (Programs as necklaces strung from pearls) → 段階的抽象化よりも大きな単位の階層化

「連接・選択・繰り返し」については、段階的抽象化の一要素に過ぎないのです。

I.hidekazuさんは平成30年8月23日 (木) 14:05(UTC)に以下のように書かれています。

「ソフトウェアの複雑な制御フローを連接・選択・繰り返しおよびネスティング（nesting）の多層化によって整理しながらプログラミングを行うダイクストラ流段階的詳細化法を言う。」

この時点で何も理解されていないのかなと思います。 段階的詳細化とは、抽象的な設計をトップダウンで詳細化していくことです。 I.hidekazuさんが言っていることはボトムアップの段階的抽象化です。 こんな基本的なことも理解されていないのに本記事を編集するべきではありません。 もっと勉強し直すべきではないでしょうか？--Monadaisuki（会話） 2018年8月25日 (土) 08:30 (UTC)

ご意見いただき誠にありがとうございます。書きながら自分の考えを整理する癖があるため、記述にブレがあることは認識しております。ご指摘されたわけではなく今私が改めて読んで気づいた点としましては、

• 「goto文を一文でも入れてしまうと正しさの確認ができない」という趣旨の内容になっていますが、原理的にはif文やwhile文でgoto文は使用されている。→特定のケースを除いてgoto文を使用するとプログラムの正しさを確認できなくなる、に改めようと思います。
• ミルズ氏発と言われるgoto-lessプログラミングとの関係の記載が薄い。→冒頭の説明書きは、実はMills,Linger,Hevnerの1987年論文『ボックス構造化情報システム』（ソフトウェアエンジニアリング論文集80's 収録）の構造化プログラミングの説明書きをほぼそっくりそのまま持ってきたものでした。引用を入れていなかったのはミスで自分も驚きました。確かにおかしいので記述を段階的詳細化に沿うようなものにしたいと思います。
• 良い構造化というのは、元をたどると大規模ソフトウェア開発に必須の共同開発をしやすい構造のことで、最終的に真珠の首飾りとできるようなもののことだと理解しています。制御フローは首飾りの糸で、多数の真珠が入った宝石箱から真珠を選んで首飾りにできるようにできるようにすることが構造化プログラミングの目標だと理解しています。品質の高い首飾りを作るために、首飾りの卸業者（ダイクストラ氏）は、真珠の養殖方法について生産者に尋ねるので、まともな製法の養殖真珠であることを論理的な納得いく方法で卸業者に説明してくださいね、一応卸を納得させるためのガイドラインはこうです、ということだと思います。→真珠の首飾りについて記載しようと思います。なお、現代的なプログラミング言語のように、すべての連接構造を（次項の）類としてまとめると真珠の首飾りにはならないように見えるということだと思います。
• ダイクストラ氏の論文だけだと上から下へ落とし込む開発しか想定されていないように読めますが、ダール氏とホーア氏の論文における類の構文は、逆に下から上への開発を可能にするもの（原著まえがきにそう書いてあります）で、フローチャートの連接構造を抜き出す操作にあたります。特定の連接構造だけを先に開発してしまってから、後でフローチャートに当てはめるという使い方を想定されていたのだと思います。類の当初の設計はフローチャートだったわけです。現代的な設計になった際に商業戦略上の要請もあってオブジェクトが強調されたということだと思います。→整理して記述できる箇所だけでも記述したいと思います。

です。読んでみまして、近いうちに図表の追加も含めて修正したいと思いますので、しばしの間ご容赦願います。またご意見ありましたらよろしくお願いいたします。

--I.hidekazu（会話） 2018年8月25日 (土) 13:55 (UTC)

申し訳ないのですが、「ご指摘されたわけではなく今私が改めて読んで気づいた点」だとしても会話があまりにも成立していない気がします。

構造化プログラミングは goto-lessプログラミングや「連接・選択・繰り返し」よりも次元の高い問題です。しかしながら、I.hidekazuさんの文章だと goto-lessプログラミングや「連接・選択・繰り返し」のことばかり書かれていて、構造化プログラミングの説明になっていないのではないでしょうか。

個人的には修正前の状態に戻したいくらいです。--Monadaisuki（会話） 2018年8月25日 (土) 14:21 (UTC)

I.hidekazuさんの文章は、構造化定理に書くべきものがあまりにも多いのではないでしょうか。--Monadaisuki（会話） 2018年8月25日 (土) 14:27 (UTC)

ご意見いただき誠にありがとうございます。私も最初はgoto-lessプログラミングというのは一種の誤解だと思っていましたが、よく考えれば、本当にはっきり間違いであれば提唱者のダイクストラがなにか言っていないとおかしいわけですし、そういう論文等が自分は見つけられなかったので、それほど大きく間違っていると判断することはできないと思いました。「構造化プログラミング」という著書が既にあって内容も確認できる中、ちゃんと本で確認するプログラマーもいらっしゃるわけですし、そんな全くの間違いが一般に流布するというのは考えにくいとも思いました。ご批判になるべく対応したいはと思いますが、構造化定理に分割してしまうと主題がわからなくなってしまう感じになると思いますし、検討事項としたいなと考えます。できれば申し訳ございませんがご容赦くださいませ。--I.hidekazu（会話） 2018年8月26日 (日) 14:15 (UTC)

インデントを戻します。

この記事の歴史に「ダイクストラは、構造化プログラミングという言葉を作ったとき2つの失敗をしたと述べた。商標登録しなかったことと定義しなかったことである」と書かれています。

ダイクストラは IBM のミルズが、ダイクストラの構造化プログラミングの名前を借りて、構造化定理を広めてしまったことを後悔しているのです。

しかし、ダイクストラが「構造化プログラミング」を商標登録せず、定義も不明確という状況において、ミルズが構造化プログラミングを広めたことを責めることはできないでしょう。

「構造化プログラミング」という著書が既にあって内容も確認できる中、ちゃんと本で確認するプログラマーもいらっしゃるわけですし、そんな全くの間違いが一般に流布するというのは考えにくいとも思いました。

これはさすがに飛躍しすぎです。ほとんどのプログラマーはアカデミックなことに関心はありません。

実際にミルズの単純な構造化定理の方が流行ったことからしても明らかです。

何が根拠で「全くの間違いが一般に流布するというのは考えにくい」のでしょうか？--Monadaisuki（会話） 2018年8月27日 (月) 12:58 (UTC)

回答が遅れまして申し訳ありません。1969年の構造化プログラミングについてのダイクストラ博士の報告書の方読みました。私の真珠の首飾りの理解について誤解していることがわかりました。メインルーチンのループにおける連接文のことだと思っていたのですが、階層的構造をもった洗練化された文のことだったのですね。訂正する機会をいただきました。

「全くの間違いが一般に流布するというのは考えにくい」理由ですが、間違いを述べていればこのように訂正されるわけです。提唱されてから４０年経過する技法であるので、もし本当に全くの間違いであれば訂正される事態が１度か２度あっても良さそうですが、そういう話を私を見つけることができませんでした。したがって、大きく訂正されるほど間違っている訳ではないと判断したのです。これが私の思う根拠です。

それに例えば、1969年の論文であれば、展開されたプログラム

S1 ; S2 ; ... ; Sn;

というものが出てきますが、ここで何気なくプログラムを「展開」とありますが、あるプログラムがこのように連接されて記述可能であることの理由は、全然書いていないわけです。普通に考えれば、この根拠はこの１０年後に出てくる構造化定理に求めるよりありません。これは時系列的におかしいので、ダイクストラ博士の主張の中に含まれていると考えるよりないですし、goto文有害説の論文を読むと趣旨としてはそういうプログラムの展開が可能な順序的プログラムにプログラムを限定しようという話でした。したがって、ダイクストラ自身は構造化プログラミングの中では強調もせずはっきりも書かなかったけれども、構成からすると構造化定理が構造化プログラミングの基礎であると見抜いたミルズが基礎づけを行った行為を指してミルズが異なった構造化プログラミングを広めたという話が出てきたのかなと類推されるわけです。または、ミルズが所属していた会社の当時の商業戦略上、対立するところから出てきた話なのかもしれません。

　

構造化プログラミングの骨子は、プログラムの正当性を証明するために、あるプログラムの正当性はフレーゲの原理（意味に関する合成原理）に従ってその部分プログラムがすべて正しくかつその組み合わせ方も正しい場合に限り正しいというこの要素還元的な「すべてのプログラムについて成り立つ全く疑いようのない原理」に基づいて、プログラムを順序的（sequential）なものに限定するというところにあると理解しています。仮に、いきなり段階的詳細化から記述するのは私の理解では非常にあやふやなものになってしまい記述が難しいと思います。説明の座りのよさとしてもはじめにフローチャートの説明を持ってくる必要はあるのではないかなぁと思います。私もまだまだ正しく理解していないところが多々あります。なにかご意見をいただければ今後のためになりありがたいです。--I.hidekazu（会話） 2018年9月11日 (火) 12:40 (UTC)