比較プログラム言語論 平成１７年７月６日 森田 彦 レポート（6/29）総括 ＜ テーマ ＞ 本日の講義で、あなたが最も興味を持った点はどのような点で すか？講義の全体的な感想と共に、できる限り具体的に、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の日本語化について －論争 レポートを読み、私も思ったことですが、「アメリカや英語 圏の子供たちなら良いですが、日本の子供には小さい 頃から英語を使ってやるというのは少し厳しい。LOGO を日本語で打てるようになればいい。」という意見に共 感をもてました。 言語が日本語になればもっとよくなると主張しています が、私はそうは思いません。確かに、言語が日本語なら ば日本人にとってはわかりやすいし、理解も今の数倍以 上になるかもしれません。しかし、英語はローマ字であり、 日本語はひらがなやカタカナ、漢字といったたくさんの 表記方法があります。これによって、ソフトが重くなって しまったりして、CPUの負担が大きくなってしまうので、 私は彼とは逆の考え方をしました。 皆はどちらの意見ですか？ 質問 ソフトウエアの需要が生産を超えていると言うことは、も しかしたら色々な人が新しいソフトウエアを開発していく 時代になるのではないでしょうか？ 現在学んでいるJava言語は、構造化プログラミングの 再利用性の悪さという欠点を踏まえて作られているのだ と知った。普段何気なくクラスを作ってプログラムの拡張 をしていたりするが、その当時は見通しのよさという点に 焦点を当てて改善をしていたが、同時に差分プログラム でプログラムを拡張するという考え方がなかったのだろ うか。 ＜本日のテーマ＞ オブジェクト指向の考え方 オブジェクト指向の考えのエッセンスを学習し、それをプログ ラム開発に応用した場合にどのようなメリットがあるかを理 解する。 ＜内容＞ １ オブジェクトとは何か？ ２ オブジェクトの基本概念 ３ オブジェクトの拡張 １．オブジェクトとは何か？ オブジェクトの例 カプセル化（プロパティとメソッド） オブジェクト指向的考え オブジェクトの例 人、車、黒板、机などのモノのこと。 オブジェクト指向の世界では→（自身の）状態に 関する情報と、（自身に対する）操作を有するモ ノ。 例） 車 状態：型式、色、排気量、マニュアルかＡＴか、 等々。 操作：走る、停止する、等々。 カプセル化（プロパティとメソッド） オブジェクト→自身の状態を表すデータ＋（自身 に対する）操作を有するモノ データと操作の（オブジェクトへの）カプセル化 １セットにするという意味 車オブジェクト 色 走る 停止する 排気量 データ ・・・ 操作 ・・・ プロパティ メソッド 補足 カプセル化の意味 関連のあるメソッドとプロパティを組み合わせて１セット にする。 そのオブジェクトの（メソッドの）使い方以外は、情報を見 せない→情報の隠蔽（データの保護という意味もある） 利用者は、オブジェクトの内部の詳細を知ることなく、オブ ジェクトに備わった機能（メソッド）を利用できる。 オブジェクト指向的考え ある用途のためのオブジェクトがあれば･･･ そのオブジェクトのメソッドを操作することで、処理を実現 例） ゼミでコンパを企画する。 オブジェクト→コンパ係 メソッド→企画 オブジェクト指向的記述→コンパ係．企画 （ドット記法） （意味：コンパ係に企画を依頼する。→コンパ係オブジェクトに 企画せよというメッセージを送る。） プロパティとメソッドがカプセル化されたオブジェクト を用いれば、手続き型（指向）プログラミングよりも 効率が上がる!? 操作（メソッド）の詳細を知る必要がない。 ２．オブジェクトの基本概念 長方形オブジェクト クラスとインスタンス メソッドの継承 スーパクラスとサブクラス 長方形オブジェクト 長方形：高さと幅をプロパティとして持っている。 （ここでは）面積を求めるメソッド（操作）考える。 長方形オブジェクト 長方形Ａ 高さ：７ 面積は？ プロパティ（幅、高さ）の値によって、 様々なオブジェクトがある。 幅：１０ 幅と高さというプロパティは共通 高さ×幅 一まとめに定義した方が便利 クラスの概念の登場 クラスとインスタンス クラス→共通の性質を持ったものの集まり 長方形 高さ： 長方形クラス 幅： 抽象化 （プロパティとメソッドの定義を持つ） 面積は？ 高さ×幅 長方形Ａ 長方形Ｂ 高さ：７ 幅：１０ 高さ：９ 幅：５ 長方形オブジェクト 実例 （インスタンス） （ 個々に異なるプロパティの 値（のみ）を持つ ） メソッドはクラスから引き継ぐ メソッドの継承 インスタンス（オブジェクト）がメッセージを受け 取った時→自分が属するクラスのメソッドを起動 する→メソッドの継承 長方形オブジェクト （インスタンス） 長方形クラス 長方形Ａ メッセージ 面積は？ ７０ 高さ：７ 幅：１０ 面積は？ 高さ×幅 長方形 高さ： 面積は？ 高さ×幅 幅： スーパクラスとサブクラス（クラスの継 承） 長方形と正方形の関係 正方形は長方形の一部→「高さ＝幅」が成り立 つ特別な長方形 長方形：広い範囲のインスタンスをカバーするク ラス→スーパクラス 正方形：スーパクラスの一部のインスタンスのみ をカバーするクラス→サブクラス サブクラスを利用した正方形の定義 長方形 高さ： 幅： 面積は？ 高さ×幅 長方形クラス スーパクラス 継承 ＯＭＴ(Object Modeling Technique)の記法 正方形 高さ＝幅 正方形Ａ 幅：１０ 正方形クラス サブクラス 正方形オブジェクト （インスタンス） クラスの階層図（図形クラスの例） 図形 四角形 長方形 正方形 三角形 台形 スーパクラスとサブクラスと いう概念は相対的なもの サブクラス（下位のクラス）はスーパクラス（上 位のクラス）の性質を全て引き継ぐ。 ＋ 新たなプロパティあるいはメソッドを持つ。 ３．オブジェクトの拡張性 単純なクラスに機能を付加→複雑なクラスを定 義可能 既存のクラスに機能を付加→目的に応じたクラ スを容易に定義できる ソフトウェアの生産性向上 オブジェクト指向プログラミングはソフトウェア危機の 救世主!? 三角形クラスの定義 （多態性） 長方形．面積は？ 図形 高さ： 長方形 面積は？ 高さ×幅 三角形．面積は？ 幅： 三角形 面積は？ 高さ×幅／2 長方形クラスと三角形クラス、それぞれ に異なる「面積は？」メソッドを定義 同じ「面積は？」メッセージを受 け取っても、長方形と三角形オ ブジェクト（インスタンス）では、 振る舞いが違う。 ポリモフィズム （polymorphism:多態性） プログラムの拡張が 容易に！ デフォルトメソッドと上書き （定義の改良） 図形 高さ： デフォルトメソッド 幅： 多くの（しかし全てではない）イン スタンスに適用できるメソッド 面積は？ 高さ×幅 メソッドの上書き 長方形 三角形 面積は？ 高さ×幅／2 ＜三角形クラスの異なる定義＞ サブクラスでメソッドを定義し 直すこと プログラムの拡張が容易に！ スーパ疑似変数と差分プログラム 「高さ×幅」の重複をなくす。 図形 高さ： 幅： super：スーパ擬似変数 面積は？ 高さ×幅 一つ上のクラスを表す。 拡張時にプログラムの重複 を排除する上で有効 長方形 三角形 面積は？ super．面積は？／2 スーパクラスに何かを追加することでサブクラスのメソッドを定義する。 継承を利用した差分プログラム プログラムの拡張が効率的に！ 再利用性の向上！ 本日のレポートのテーマ 講義中に指示します。 プログラムのモジュール化 例 問題 学生のテスト成績を読み込み成績順に表示する。 ＜プログラムの構造＞ データの読み込み データのソート データの表示 ＜メインルーチン＞ Integer Tokuten(200) CALL ReadData(Tokuten) CALL SORT(Tokuten) CALL Display(Tokuten) ＜ポイント＞ プログラムの基本構造はメインルーチンで記述 処理の詳細はモジュール（サブルーチン）で記述 プログラムの基本構造が分かりやすくなる。 →見通しが良くなる。
© Copyright 2024 ExpyDoc
