比較プログラム言語論 平成１７年７月６日 森田　彦

レポート（6/29）総括 詳細はHP参照 ＜ テーマ ＞ 　＜　テーマ　＞　 本日の講義で、あなたが最も興味を持った点はどのような点ですか？講義の全体的な感想と共に、できる限り具体的に、200字～400字程度で記述して下さい。 ＜論点のピックアップ＞ 詳細はHP参照 　GO TO文の魔力 　ダイクストラの主張・構造化定理 　モジュール化 　ソフトウェア危機 　（構造化プログラミング）その後の展開 　その他（ドリトル・質問・レポートへのコメント）

GO TO文の魔力① 今回の講義で感じたことは、GOTO文の魅力は物凄いということです。一行ずつしか編集できないというのは、今の環境からすると、考えられないくらい大変だったと思います。 しかし、プログラムの間に入れるだけで、処理したい場所に飛ぶ事が出来るGOTO文は、簡単に理解する事が出来るほどわかりやすいものなので、プログラムを記述する段階では非常に有効な物であったと思います。 しかしその反面、バグの修正が大変になる事も想像出来るので、正に先生が、おっしゃっていたように魔力という言葉が当てはまると思いました。 ・・・（略）ＧＯＴＯを用いれば作成時の順番を維持することができ、なおかつ開発効率が上がると知り、当時としては画期的だと思った。・・・（略）しかしとても読みにくいことが分かった。・・・（略） やはり処理は順序通りにするのが、一番見やすい方法だと感じた。 書きやすさ vs 読みやすさ のバランスが問題！

補足：読みやすさ ／ 書きやすさの視点から構造化プログラミングを見ると・・・ 「IF+GO TO」文の世界→思いつくままに記述できる。→書きやすい（特別な訓練なしでも書ける）。 しかし、後から見ると読みにくい。→開発効率に限界 一方、構造化プログラミングの世界では・・・ 基本構造さらにはモジュールの組み合わせで（処理順に）記述する。→記述する際にプログラムの全体構造を把握しておく必要がある。→慣れるまで訓練（教育）が必要。 出来上がったプログラムは読みやすい。→開発効率は上がる。 構造化プログラミングの普及→教育の必要性増大 元々PASCAL言語は構造化プログラミングを教育するために開発されたもの 書きやすさから読みやすさへ

GO TO文の魔力② その効用!? プログラム開発用の思考ツールは現在も開発中！ 今日の授業では、GO TO文はとても魅力があるものだと思いました。GOTO文を使うとどんなプログラムも記述できて、便利だけれども後からは読みにくいということでした。ですがこの文の良さを生かすとすれば、プログラムを書く人のメモのようなものになるのではと思いました。短いプログラムを思うままGOTOで書いておいてプログラムとして使うときには構造化する。GOTO文でも実行してみることはできるから、とりあえずやってみるといった時には便利なのではないか。さほど学習しなくても書けることが自分には適していると思いました。 プログラム開発用の思考ツールは現在も開発中！

ダイクストラの主張・構造化定理① 今回興味を持ったのはダイグストラの主張と構造化プログラミングです。一つの入り口と一つの出口しか持たないアルゴリズムは、「連接」、「分岐」、「繰り返し」の基本構造をつなげることで記述できるが、このように定理化できたダイグストラはすごい。 GOTO文と違い、作る分にも見る分にもわかりやすく、またその利点があるが故に「プログラムが読みやすい」、フローチャートによる設計が可能」「ミスが少なくなる」等の新たな利点を生み出したことからも、構造化プログラミングはそれからの主流となるのには十分だったと思う。 構造化定理　→　分かりやすさ（読みやすさ）をもたらした。

ダイクストラの主張・構造化定理② ダイクストラの業績に共感！ 今回の講義を受け、もっとも興味が持てたのは、構造化プログラミングです。・・・（略）構造化定理をダイクストラが主張したことで、プログラミングがより理解しやすくなったのだから、以前学んだプログラミングを少しだけだが理解できたのは、ダイクストラのおかげであると思いました。時代とともに物事が発展していくのは当然であるという発想があるが、起源は当然あり、（誰かが）始めなければ始まらないが、ダイクストラの主張が以前までのプログラミングに変化を起こした。変化をつけることができる人物は偉大であると改めて思い知らされました。 GOTO文は必要ないという主張により構造化プログラミング運動が始まり無駄な処理が少なくなってプログラミング開発の効率が上がったことに対しダイクストラはプログラミング開発の「救世主」といえると思いました。 ダイクストラの業績に共感！

モジュール化① 今回の講義で最も興味を持ったのは、プログラムの構造化です。特にその構造化プログラミングの最終的な主張であるプログラムのモジュール化に興味を持ちました。プログラムの基本構造はメインルーチンで記述し、ひとまとまりの処理の内容はモジュール（サブルーチン）で記述することによって、プログラムの基本構造がわかりやすくなります。基本構造と処理の詳細を分けて記述するということでプログラム全体の見通しがよくなり、バグや改変の時にわかりやすくなると思います。モジュール化しておくことは開発効率の向上につながるのでとても重要なことだと感じました。 モジュール化のポイント：基本構造の設計→処理の詳細へ

モジュール化② 今回興味を持ったのは、構造化プログラミングとモジュールについてです。連接・分岐・繰り返しを処理の順どおりに繋げて表現することは、プログラミングの見通しを良くするだけでなく、プログラミングの初心者にとっても処理を論理的に理解しやすいという点で非常に重要なことだと思いました。またモジュールは、たくさんあるファイルを一つのフォルダにまとめた形で（メインルーチンに）表示したようで、とてもわかりやすい仕組みだと思いました。 モジュール化はトップダウン的思考が必要：「処理をモジュールへ分割」→「モジュールの命名」→「モジュールを適切な順に配置」→「モジュールの処理内容の記述」

ソフトウェア危機① 今回興味を持ったのは、ソフトウェアの危機についてである。構造化プログラミングが進み、ソフトウェアの生産が伸びたのは良いことだが、既存のソフトウェアの再利用性については著しく伸び悩んだ。それに伴い、需要がグングン伸び、生産が追いつかないということもあり、ソフトウェアの危機とも言われた。一時期は、かなりの製作者を必要とするくらいのものだという。ここでは、使う方は天国・作る方は地獄といわれていたというのが、内容を聞くことにより理解できた。・・・（略） 大学に入り、作るということをやってきたからこそ、その大変さも身にしみるくらいに感じる。 ・・・（略）プログラミングを習いましたが、ちょっとしたプログラムを作るだけでそれなりの時間と労力を必要とするのに、大掛かりなプログラミングを行うとすればとんでもない時間と労力を必要とするのがよくわかります。 一つのプログラムを作るのにどれだけの人数が必要なのかは知りませんが、きっと非常に過酷な状況で作っているのではないかと思いました。 ソフトウェア開発現場の過酷さを理解！

ソフトウェア危機② 今回の講義で私が最も興味を持ったのは、ソフトウェア危機についてです。この言葉は聞いたことがありましたが、実際にどのような状況のことをいうのかよく理解していませんでした。ソフトウェアの需要が増えそれにソフトウェアの生産が追いつかないということでしたが、言い換えると、生産が追いつかないほどにどんどん普及し、コンピュータ社会が確実に拡がっているということの現れではないのでしょうか。このような状況は確かにソフトウェアを生産する側にとっては大変な状況でしょうが、注目されることによって、より効率の良い開発形態はどういうものか？ということに目をつけ、さらに技術が発展していくのであれば、それは結果的に良いことになるのではないでしょうか。 ・・・（略）ソフトウェアの生産がおいつかないということも、生産側にしてもこれはいいことだと感じました。今のやり方よりもっと効率の良い（生産の早い）方法を考える、という事を思いました。これはソフトウェアの向上になると思います。 ソフトウェア危機はソフトウェア発展の原動力!?

補足 ソフトウェア開発におけるユーザの要求と開発者の技術力の連鎖 補足　ソフトウェア開発におけるユーザの要求と開発者の技術力の連鎖 ユーザ 開発者 要求 技術力 この連鎖を止めることは困難 この連鎖が技術革新を生んできた。 現代は、需要と技術のあやういバランスの上に成り立っている。 ソフトウェアシステムの開発技術レベルを把握しておかなければトラブルが生ずる。 例：みずほ銀行のシステム障害 技術者の力不足？ 管理者の無理解（過酷な要求）？ 皆はどう思いますか？

その後の展開に関心 キーワードは「再利用性」、「差分プログラム」 「使う方は天国、作る方は地獄」という言葉に感心し、（その状況が）オブジェクト指向によってどのように解決していったのか、気になり来週の講義が楽しみです。 構造化プログラミングにより、ソフトウェアの生産性が向上したのに、実際のソフトウェアの需要増には追いつけない欠陥が出てきてしまった。この点を、オブジェクト指向言語はどのように改善しているのか、とても興味があります。 ・・・（略）その後のオブジェクト指向プログラミングのどのような点がモジュール化に比べて効率的なのかも興味を持った。 キーワードは「再利用性」、「差分プログラム」

その他① ドリトルについて（HPを調べた人から） 今回の講義でドリトルに最も興味を持ったので調べてみました。ドリトルとは、やることが少ない(簡単にプログラムを書ける)という意味で付けられた名前でした。そのとおりで記述方法は簡単で、初心者でも簡単に使いこなせるものでした。グラフィックスの作成や音楽演奏などもできます。一番の魅力は日本語でソースを作れるというところだと思います。これならミス入力も見つけやすいのではないかと思いました。変数・関数を使う数式は小学生は習っていないはずなので使えないと思ったけど、それ以外なら小学生からでも楽しんで学べるものだと思いました。

その他② LOGOの日本語化について－論争 言語が日本語になればもっとよくなると主張していますが、私はそうは思いません。確かに、言語が日本語ならば日本人にとってはわかりやすいし、理解も今の数倍以上になるかもしれません。しかし、英語はローマ字であり、日本語はひらがなやカタカナ、漢字といったたくさんの表記方法があります。これによって、ソフトが重くなってしまったりして、CPUの負担が大きくなってしまうので、私は彼とは逆の考え方をしました。 皆はどちらの意見ですか？

質問 ソフトウエアの需要が生産を超えていると言うことは、もしかしたら色々な人が新しいソフトウエアを開発していく時代になるのではないでしょうか？ 現在学んでいるJava言語は、構造化プログラミングの再利用性の悪さという欠点を踏まえて作られているのだと知った。普段何気なくクラスを作ってプログラムの拡張をしていたりするが、その当時は見通しのよさという点に焦点を当てて改善をしていたが、同時に差分プログラムでプログラムを拡張するという考え方がなかったのだろうか。

１ オブジェクトとは何か？ ２ オブジェクトの基本概念 ３ オブジェクトの拡張 オブジェクト指向の考え方 ＜本日のテーマ＞ ＜内容＞ オブジェクト指向の考えのエッセンスを学習し、それをプログラム開発に応用した場合にどのようなメリットがあるかを理解する。 ＜内容＞ １　オブジェクトとは何か？ ２　オブジェクトの基本概念 ３　オブジェクトの拡張

１．オブジェクトとは何か？ オブジェクトの例 カプセル化（プロパティとメソッド） オブジェクト指向的考え

オブジェクトの例 人、車、黒板、机などのモノのこと。 オブジェクト指向の世界では→（自身の）状態に関する情報と、（自身に対する）操作を有するモノ。 例）　車 　状態：型式、色、排気量、マニュアルかＡＴか、等々。 　操作：走る、停止する、等々。

カプセル化（プロパティとメソッド） オブジェクト→自身の状態を表すデータ＋（自身に対する）操作を有するモノ データと操作の（オブジェクトへの）カプセル化　 １セットにするという意味 車オブジェクト 色 排気量 走る 停止する データ プロパティ 操作 メソッド ・・・

補足 カプセル化の意味 関連のあるメソッドとプロパティを組み合わせて１セットにする。 補足　カプセル化の意味 関連のあるメソッドとプロパティを組み合わせて１セットにする。 そのオブジェクトの（メソッドの）使い方以外は、情報を見せない→情報の隠蔽（データの保護という意味もある） 利用者は、オブジェクトの内部の詳細を知ることなく、オブジェクトに備わった機能（メソッド）を利用できる。

オブジェクト指向的考え ある用途のためのオブジェクトがあれば･･･ そのオブジェクトのメソッドを操作することで、処理を実現 　　そのオブジェクトのメソッドを操作することで、処理を実現 例）　ゼミでコンパを企画する。 　オブジェクト→コンパ係　　メソッド→企画 　オブジェクト指向的記述→コンパ係．企画　（ドット記法） 　（意味：コンパ係に企画を依頼する。→コンパ係オブジェクトに企画せよというメッセージを送る。）　　　 プロパティとメソッドがカプセル化されたオブジェクトを用いれば、手続き型（指向）プログラミングよりも効率が上がる!? 操作（メソッド）の詳細を知る必要がない。

２．オブジェクトの基本概念 長方形オブジェクト クラスとインスタンス メソッドの継承 スーパクラスとサブクラス

長方形オブジェクト 長方形：高さと幅をプロパティとして持っている。 （ここでは）面積を求めるメソッド（操作）考える。 クラスの概念の登場 長方形Ａ 高さ：７ 幅：１０ 面積は？ 　　　高さ×幅 プロパティ（幅、高さ）の値によって、様々なオブジェクトがある。 幅と高さというプロパティは共通 一まとめに定義した方が便利 クラスの概念の登場

クラスとインスタンス クラス→共通の性質を持ったものの集まり 抽象化 実例 長方形クラス 長方形オブジェクト（インスタンス） 高さ：　　幅： 面積は？ 　　高さ×幅 抽象化 長方形クラス （プロパティとメソッドの定義を持つ） 長方形オブジェクト（インスタンス） 実例 長方形Ａ 高さ：７　幅：１０ 長方形Ｂ 高さ：９　幅：５ （　個々に異なるプロパティの値（のみ）を持つ　） メソッドはクラスから引き継ぐ

メソッドの継承 インスタンス（オブジェクト）がメッセージを受け取った時→自分が属するクラスのメソッドを起動する→メソッドの継承 長方形クラス 高さ：　　幅： 面積は？ 　　高さ×幅 長方形クラス 長方形オブジェクト（インスタンス） 長方形Ａ メッセージ 　面積は？ 高さ：７　幅：１０ 面積は？ 　　高さ×幅 ７０

スーパクラスとサブクラス（クラスの継承） 長方形と正方形の関係 　正方形は長方形の一部→「高さ＝幅」が成り立つ特別な長方形 長方形：広い範囲のインスタンスをカバーするクラス→スーパクラス 正方形：スーパクラスの一部のインスタンスのみをカバーするクラス→サブクラス

サブクラスを利用した正方形の定義 継承 長方形クラス スーパクラス 正方形クラス サブクラス 正方形オブジェクト（インスタンス） 長方形 高さ：　　幅： 面積は？ 　　高さ×幅 長方形クラス スーパクラス 継承 ＯＭＴ(Object Modeling Technique)の記法 正方形 高さ＝幅 正方形クラス サブクラス 正方形Ａ 幅：１０ 正方形オブジェクト（インスタンス）

クラスの階層図（図形クラスの例） スーパクラスとサブクラスという概念は相対的なもの 図形 四角形 三角形 長方形 台形 正方形 サブクラス（下位のクラス）はスーパクラス（上位のクラス）の性質を全て引き継ぐ。　　＋　新たなプロパティあるいはメソッドを持つ。　

３．オブジェクトの拡張性 ソフトウェアの生産性向上 単純なクラスに機能を付加→複雑なクラスを定義可能 既存のクラスに機能を付加→目的に応じたクラスを容易に定義できる ソフトウェアの生産性向上 オブジェクト指向プログラミングはソフトウェア危機の救世主!?

三角形クラスの定義 （多態性） 長方形クラスと三角形クラス、それぞれに異なる「面積は？」メソッドを定義 プログラムの拡張が容易に！ 三角形クラスの定義　（多態性） 長方形．面積は？ 図形 高さ：　　幅： 長方形 面積は？ 　　高さ×幅 三角形 　　高さ×幅／2 三角形．面積は？ 同じ「面積は？」メッセージを受け取っても、長方形と三角形オブジェクト（インスタンス）では、振る舞いが違う。 ポリモフィズム（polymorphism:多態性） 長方形クラスと三角形クラス、それぞれに異なる「面積は？」メソッドを定義 プログラムの拡張が容易に！

デフォルトメソッドと上書き （定義の改良） デフォルトメソッドと上書き　（定義の改良） 図形 高さ：　　幅： 長方形 面積は？ 　　高さ×幅 三角形 　　高さ×幅／2 デフォルトメソッド 多くの（しかし全てではない）インスタンスに適用できるメソッド メソッドの上書き サブクラスでメソッドを定義し直すこと ＜三角形クラスの異なる定義＞ プログラムの拡張が容易に！

スーパ疑似変数と差分プログラム 「高さ×幅」の重複をなくす。 super：スーパ擬似変数 プログラムの拡張が効率的に！ 図形 高さ：　　幅： 長方形 面積は？ 　　高さ×幅 三角形 　　super．面積は？／2 super：スーパ擬似変数 　　一つ上のクラスを表す。 拡張時にプログラムの重複を排除する上で有効 スーパクラスに何かを追加することでサブクラスのメソッドを定義する。 プログラムの拡張が効率的に！ 継承を利用した差分プログラム 再利用性の向上！

本日のレポートのテーマ 講義中に指示します。

プログラムのモジュール化 例 問題 学生のテスト成績を読み込み成績順に表示する。 ＜プログラムの構造＞ データの読み込み データのソート プログラムのモジュール化　例 問題　学生のテスト成績を読み込み成績順に表示する。 ＜プログラムの構造＞ データの読み込み データのソート データの表示 Integer Tokuten(200) CALL ReadData(Tokuten) CALL SORT(Tokuten) CALL Display(Tokuten) ＜メインルーチン＞ プログラムの基本構造はメインルーチンで記述 処理の詳細はモジュール（サブルーチン）で記述 ＜ポイント＞ プログラムの基本構造が分かりやすくなる。→見通しが良くなる。