基礎情報技術ー第 2 日目ー

基礎情報技術ー第2日目ー 平成20年5月9日（金）担当：亀田

確認 • 授業で使用した資料は授業終了後にWebにて公開します。 • ノートにメモを取ってください。（キーワードや図だけでも結構です。） • 毎回レポート課題がでます。（前回のレポートは授業終了時に回収します。）

それでは始めましょう

前回のポイントの確認 • ITのプロになるためには何が必要か？これを考えるための素材をお話しました。

前回のポイントの確認 • SEの仕事はプログラミングだけではない • ソフトウェアのライフサイクル • オブジェクト指向 • モデリング言語 UML　など

授業概要 • ITエンジニアのプロフェッショナルになるためには、プロとしての嗜み（たしなみ）と作法を身につけることも大切である。本授業では、今後プロとしてソフトウェアかかわる人たちにとって避けて通ることのできない嗜み・作法を簡単な演習を通じて紹介するとともに、学生の皆さんにそれらの必要性・重要性を身を持って理解してもらうことを目指す。 • 具体的には、ソフトウェア開発を上流工程から下流工程へ向けて実際に体験してもらいながら、UML(Unified Modeling Language)やプロジェクト管理等の紹介を行う。 • ITシステム ≠ プログラミングであることや、ソフトウェア開発におけるコミュニケーションの意義、プロジェクト管理の重要性についてなど、多くのことを学生の皆さん自らが気づくことを期待する。

今日の内容 • 要求仕様を作ってみよう • ソフトウェア開発過程の概要 • UMLの概説 • Javaプログラミング　など • 今日の課題（課題番号No2）

ソフトウェア開発過程の概要 • 「ソフトウェアは実際にどのような作業工程を経て作れば良いのか？」　ということ。

ソフトウェア開発過程の確立 これは未解決問題の１つです！

よいプログラムはどうやって作れば良いのか？よいプログラムはどうやって作れば良いのか？ • バグのない • 動作効率のよい • 開発コストがかからない • メンテナンスがしやすい • 急な修正・変更にも対応できる • 拡張性のある • 汎用性のある　などなどこんなプログラムってどうやって作るのだろうか？

例えば、プログラミング言語 これにもいろいろな工夫がなされてきた • 事務処理計算向き言語 • 科学技術計算向き言語 • 人工知能研究向き言語　など（こんな分類のもと、さまざまな言語が考案されてきた。）疑問：プログラミング言語の分類は今後もこれでいいのだろうか？

要求仕様としては… • 対象としている処理（機能・サービス）を記述・実現することができなければならない。 • 人間にとって使いやすく、分かりやすいものであって欲しい。 • Fortran：計算式をそのまま書ける • Cobol:自然言語に近い表現が可能 • Pascal: ____________________ • C： ________________________ • Java: ______________________ 考えてみてください。

よりよいプログラムをもとめて… • 機能の整理 • モジュール化/階層化 • 構造化プログラミング • モジュールの独立性（関数型言語、データ抽象化、　＝＞オブジェクト指向） • ソフトウェア開発法プログラミング言語側から開発法側から

具体的に見てみよう • プログラミングの側面から • 開発手法の側面から

プログラム工学Ⅲ（ダイジェスト版） 工学部情報工学科での講義資料より担当：亀田弘之（東京工科大学）

C言語の歴史 • 1972年　誕生（Dennis M. Ritchie） • UNIX開発用言語として使用 • ハードウェアの発達により新しい機能追加 • 方言の発生 • 1989年　ANSI規格制定 • 1990年　ISO規格制定 • 1993年　JISC制定

問題 • C言語は今後どのような発展の道をたどるか論じなさい。 • BASIC、PASCAL、FORTRAN、COBOL、LISP、PROLOGなどの他の言語の歴史を調べ、各言語がどのような背景・目的で誕生し、どのような道をたどっているか論ぜよ。

C言語の特徴 • 構造化プログラミング向き • ハードウェアが透けて見える高水準言語 • 豊富なデータタイプ • コンパクトな言語仕様 • 関数形式によるモジュール化 • 移植性が比較的高い

構造化プログラミングとは • 処理手続きをいくつかの単位に分割し、主となる処理は大まかに記述とし、細部はサブルーチンとして記述していく方法。エドガー・ダイクストラらによって提唱された。ダイクストラは、大規模化したプログラムを効率よく記述しプログラム設計上のミスが起きにくいようにするための方法論を検討した。その結果1960年代後半に、構造化定理を証明し、構造化プログラミングを提唱した。

構造化定理 • 1つの入り口と1つの出口を持つようなプログラムは、「順次・反復・分岐」の3つの基本的な論理構造によって記述できる(Dijikstra)。順次反復分岐

分岐反復順次 S = S + 1 X = f(S, 5) S = g(X) + S

問題 • C言語の特徴を、Javaなどの他の言語と比較して述べよ。

3.プログラムの基本的なパターン #include <stdio.h> main( ) { } 本体

3.プログラムの基本的なパターン #include <stdio.h> main( ) { double fahrenheit; /* 華氏 */ double celsius; /* 摂氏 */ scanf(“%f”, &fahrenheit); celsius = ( fahrenheit – 32 )*5.0/9.0; printf(“%f”, celsius); }

3.プログラムの基本的なパターン Cのプリプロセッサ用 #include <stdio.h> main( ) { double fahrenheit; /* 華氏 */ double celsius; /* 摂氏 */ scanf(“%f”, & fahrenheit); celsius = ( fahrenheit – 32 )*5.0/9.0; printf(“%f”, celsius); } Cのプログラム

3.プログラムの基本的なパターン #include <stdio.h> main( ) { double fahrenheit; /* 華氏 */ double celsius; /* 摂氏 */ scanf(“%f”, &fahrenheit); celsius = ( fahrenheit – 32 )*5.0/9.0; printf(“%f”, celsius); }

5.構造化プログラミングと制御構造

分岐反復順次 S = S + 1 X = f(S, 5) S = g(X) + S 構造化プログラミング

5.構造化プログラミングと制御構造 • 順次 • 反復 • for文 • while文 • do-while文 • 分岐 • goto文 • break文 • continue文 • switch文 & case文

i=1 i<=100 s=s+i i++ For文 • Syntax: for(式１; 式２; 式３) 文 • 例： for( i=1; i <= 100; i++) s = s + i; Flow Chart

今度は、… • プログラミングの側面から • 開発手法の側面から

ソフトウェアのライフサイクル（１） • 要求分析 • 設計 • プログラミング • デバッグ • 評価 • 運用 ⇒再び１へ戻る

ソフトウェアのライフサイクル（２） • 何（どんなもの）を作ればいいの？ • どう作ればいの？ • 作成作業そのもの（デバッグもやりながら） • 本当にちゃんとできたのかな？ • 実際に使おう！ • ちょっと変更したいな。

ソフトウェア開発モデル • ウォーターフォール(water fall)モデル • プロトタイピングによるソフトウェア開発 • インクリメンタルモデルとイテラティブモデル • スパイラルモデル • データフローモデル • アジャイルモデル • モデル駆動型＝＞一長一短あり自主問題：ウォーターフォールモデル，スパイラルモデルおよび　モデル駆動型アーキテクチャ(MDA)について調べよ。

ソフトウェア開発過程の確立 現時点では、経験的・体験的にtry！銀の弾丸はあるのだろうか？

問題 • 「銀の弾丸」とはソフトウェア工学の分野では何を意味しているのでしょうか？調べてみてください。

銀の弾丸とは • ソフトウェア開発の現場における諸問題に対して、あまねく通用する万能解決策のこと。 • このような「万能な解決策（銀の弾丸）は存在しない」という表現で、ソフトウェア開発の難しさを表現することがある。

銀の弾丸はなくても… • あきらめてはいけない！ • １つの提案が「モデリング」とそれを記述・表現するための「モデル記述言語」である。　（以下、その話をしましょう）

今日の内容（再） • 要求仕様を作ってみよう • ソフトウェア開発過程の概要 • UMLの概説 • Javaプログラミング　など • 今日の課題（課題番号No2）

UMLの歴史 • （前回資料参照） • とにかく、いいプログラムはいい設計が大切、という観点から、さまざまな開発手法が考えられてきた。

それでわかったこと • 要求仕様の明確化 • それにもとづくきちっとした設計 • プラットフォームに依存しない「機能やサービス」のレベル • プラットフォームに依存する「実装」レベル • 設計にきちんと基づく「実装」 • 要求仕様に対応した検証　　が大切

これらのレベルごとに、当該システムをモデル化することが大切。これらのレベルごとに、当該システムをモデル化することが大切。 • その際、モデルを記述する表現（言語）が必要。　＝＞　UML の登場！ UMLはモデル記述のための言語（図で標記）

UML各種ダイアグラムの紹介 • ユースケース図 • クラス図 • その他のUML図

UMLとは（ソフトウェア工学的観点から） • UML（UnifiedModelingLanguage） • システム開発の分野で現在最も注目されているツール（仕様等の記述言語）の１つ。 • システムの構想をビジュアルに表現できる。(visual language) • 誰とでも誤解なく意思疎通できる。（communication tool）何を作るのかは、明確にしておかなければ…

UMLとは（言語論的観点から） • UMLは言語の１つ • 言語 • 音声言語 (Spoken Language): • 所謂話し言葉 • 若者語 etc. • 文字言語 (Written Language) ： • 書き言葉 • 法律文 etc. • 視覚言語 (Visual Language)： • 手話(sign language) • ダイヤグラム（Flowchart, UML etc.） etc.

ちょっと雑談(1) • 言語とは • 思考のための道具 • 知識を記述し蓄えるための道具 • 意思疎通のための道具上記のことを意識しておくことが大切！

ちょっと雑談(2) UMLも１つの言語 • UMLとは • 思考のための道具 • 知識を記述し蓄えるための道具 • 意思疎通のための道具通常はこの点のみが強調されている

ちょっと雑談(3) • Syntax v.s. Semantics (統語論 v.s. 意味論) • 表現形式　v.s.　意味内容

基礎情報技術ー第 2 日目ー