基礎情報技術 ー第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年　JIS　C制定

問題 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.プログラムの基本的なパターン #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文

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ちょっと雑談(4) Syntax v.s. Semantics (統語論 v.s. 意味論) 表現形式 v.s. 意味内容 今日はこちらに 重点を置く こちらの理解が本質

参考情報 思考と言語について 意味への取り組みについて ヴィゴツキー：“思考と言語,” 柴田義松（訳）, 新読書社(2001). 柴田義松：“ヴィゴツキー入門,”寺小屋新書（2006）. 思考と言語研究会(電子情報通信学会) ( http://www.ieice.org/~tl/what.html ) 12月に工科大で開催 (参加料無料) 意味への取り組みについて Semantic Web（http://www.w3.org/2001/sw/） Semantic Computing(http://www.instsec.org/) Web2.0

さて、…

UMLとは これから作ろうとしているシステム（ソフトウェア）の概念をさまざまな側面から切り出し、表現する図（ダイアグラム）群のこと。 作りたいと思っているもの 　 →　概念 　 →　仕様 　 →　実装 完成したシステム（ソフトウェア）

UMLで使用する図（新） ユースケース図 クラス図 オブジェクト図 シーケンス図 ステートマシン図 （ステートチャート図） アクティビティ図 コンポーネント図 コミュニケーション図（コラボレーション図） 配置図 コンポジット図 タイミング図 相互作用概念図 順序と内容を確認すること！

ユースケース図 定義： システムの機能・要件（ユースケース）を ユーザ等（アクター ）の視点で示した図 システムの使われ方（要求・機能）を記述するための図 要件（ユースケース）やアクターを具体例で示す。

(参考)ユースケース ユースケースを図示する方法が ユースケース図である。 ユースケース（システム要求機能）の 記述方法は、場合によってはテキストでも 良い。 講義では飛ばしました。By KAMEDA

ユースケースの参考図書 ・Alistair Cockburn: Writing Effective Use Cases, Addison-Wesley, ISBN 0201702258 (2000) ・ユースケース実践ガイドー効果的なユースケースの書き方：アリスターコーバーン，翔泳社, ISBN 4798101273(2001) 講義では飛ばしました。By KAMEDA

システムの具体例 例： 講習会予約システム 缶ジュースの自動販売機 トランプゲーム(BlackJack) お風呂温度・水量設定システム スケジュール閲覧システム チャットシステム

講習会予約システム

タンジブルソフトウェア入門と人工知能特論コースを取ろうかなぁ… 講習会予約システム タンジブルソフトウェア入門と人工知能特論コースを取ろうかなぁ… 申込みをしている風景　　 講習受講希望者 Model: Chiaki KUBOMURA 協力：山野美容芸術短期大学

タンジブルソフトウェアは空いているけど、人工知能特論はどうかなぁ… 講習会予約システム 事務処理をしている風景 タンジブルソフトウェアは空いているけど、人工知能特論はどうかなぁ… 受講登録事務員 Model: Chiaki KUBOMURA 協力：山野美容芸術短期大学

講習会予約システム 要件（要求される機能）： 申込み キャンセル 領収書発行　など アクター： 受講者 経理担当 顧客管理システム

缶ジュースの自動販売機 要件： コイン投入待ち 金額計算 販売可能商品の表示 購入希望商品の選定 商品の出力 釣銭の出力 アクター： 購入者

トランプゲーム(BlackJack) 要件： カードシャッフル カード要求 持ち札の把握 勝敗の判定 勝敗結果の表示 アクター： プレイヤ

講習会予約システム（再） 要件（要求される機能）： 申込み キャンセル 領収書発行　など アクター： 受講者 経理担当 顧客管理システム

講習会予約システム ー ユースケース図 ー

講習会予約システム ユースケース アクター 関連 システム境界

ユースケース図の用語(1) アクター： システムと相互作用する 利用者や外部システムの役割 ユースケースを駆動する。 人間（利用者）、外部システム、ハードウェア Stickman とも言う

ユースケース図の用語(2) ユースケース： システムが提供する機能（振る舞い） アクターとシステムとの対話をモデル化 ユースケースにより、システムの用途が網羅 ユースケース名

ユースケース図の用語(3) 関連： システム境界： アクターとユースケースとの関係 関係があれば線で結ぶ システムの外部と内部とを区別する。 関連名 内部 外部

トランプゲーム ー ユースケース図 ー （練習：各自で描いてみよう！） アクター：＿＿＿ ユースケース：＿＿＿

プログラマにとっては、ソースコードの方がもっと大切です。 クラス図 とても重要な図です。 特に、programmerにとっては。 プログラマにとっては、ソースコードの方がもっと大切です。

クラス図 定義： システムの静的な構造を表したもの 問題領域やシステムの構造を、論理的・静的に捉えるためのもの

クラス図の例 学生と学部 0..* 1 学生 学部 学生番号 氏名 - 学部名 住所 所在地 電話番号 ＋学生情報取得() + 入学手続き 0..* 1 学生 学部 学生番号 氏名 住所 - 学部名 所在地 電話番号 ＋学生情報取得() + 入学手続き + 休学手続き + 転学部手続き

クラス図の例 学生と学部 クラス名 関係 0..* 1 学生 学部 学生番号 氏名 - 氏名 住所 住所 電話番号 属性 ＋学生情報取得() 0..* 1 学生 学部 学生番号 氏名 住所 - 氏名 住所 電話番号 属性 ＋学生情報取得() + 入学手続き + 休学手続き + 転学部手続き 操作

クラス図の例 学生と学部 クラス名 多重度 0..* 1 学生 学部 学生番号 氏名 - 氏名 住所 住所 電話番号 属性 0..* 1 学生 学部 学生番号 氏名 住所 - 氏名 住所 電話番号 属性 ＋学生情報取得() + 入学手続き + 休学手続き + 転学部手続き 操作

クラス図の用語(1) クラス： 具体物(インスタンス)を抽象化したもの 属性の操作（関数）をもつ インスタンスの設計図に相当 クラス名 属　性 操　作

クラス図の用語(1) クラス： 具体物(インスタンス)を抽象化したもの 属性と属性の操作（関数）をもつ インスタンスの設計図に相当 後で参照するためのもの クラス名 属性のみ（属性値なし） 属　性 操　作 （属性に対する）関数

クラス図の用語(2) 関係：クラス間の相互関係 クラスA クラスB 関連 集約 合成 汎化 依存

クラス図の用語(3-1) 多重度： クラスから生成されるインスタンス（オブジェクト）の個数などを表す。 Ｎ Ｍ

クラス図の用語(3-2) 多重度の記述法： ｎ ｎのみ 通常は０や１が使われる 1.. １以上 1..＊ １以上 ｎ ｎのみ 通常は０や１が使われる 1.. １以上 1..＊ １以上 ＊ 任意の数 他の数字と組合わせて使用 1,3,7 １か３か７ 離散値を扱う場合に使用 例：　3..＊　　３以上

クラス図の例（再） 学生と学部 多重度１ 多重度０以上 クラス名 多重度 0..* 1 学生 学部 学生番号 氏名 - 氏名 住所 住所 0..* 1 学生 学部 学生番号 氏名 住所 - 氏名 住所 電話番号 属性 ＋学生情報取得() + 入学手続き + 休学手続き + 転学部手続き 操作

練習問題 （クラス図の作成）

クラスの例１ 自動車クラス is-a関係 Racing car is a car. レーシング カークラス バスクラス タクシークラス

自動車のクラス階層(1) 自動車 レーシングカー バス タクシー

自動車のクラス階層(2) 自動車 レーシングカー バス タクシー

例：自動車とその部品(1) 車　台 ボディ エンジン 窓ガラス タイヤ ハンドル

例：自動車とその部品(2) 車　台 ボディイ エンジン 窓ガラス タイヤ ハンドル

例：自動車とその部品(3) 自動車 車　台 ボディ エンジン

例：自動車とその部品(4) 自動車のクラス階層 自動車とその部品 これらを区別する方法は… 形式が同じになっている！！

例：自動車のクラス階層 自動車 レーシングカー バス タクシー 汎化 特化

例：自動車とその部品(3) 自動車 　　　車　台 ボディ エンジン

合成の関係の場合 自動車 　　　車　台 ボディ エンジン

集約の関係の場合 家　族 　　お父さん お母さん 子供

オブジェクト図 定義： クラス図に出てくるオブジェクトの相互関係を示したもの 静的構造を把握

オブジェクト図の例 クラス図 学部 学生 オブジェクト図 ：学部 ：学生 鈴木 CS ：学生 佐藤 ：学生 田中

オブジェクト図の例 クラス図 学部 学生 オブジェクト図 ：学部 ：学生 オブジェクト名 鈴木 CS ：学生 佐藤 リンク 値 ：学生 田中

シーケンス図 定義： オブジェクト相互の協調またはメッセージを、時間軸に着目して表示する図

シーケンス図の例 ：obj1 ：obj2

コミュニケーション図 定義： オブジェクト間のメッセージのやり取りを、接続関係に着目して記す図 シーケンス図とほぼ同じ内容となる。 着目点が異なる。

コミュニケーション図の例 １：番号入力 ３：実行 ２：確認ランプ :obj01 ：検索コントローラ ４：結果画面表示 ５：結果表示 検索結果画面

ステートマシン図 定義： オブジェクトの状態の変化や、その変化が起きるための条件を表す図

ステートマシン図の例 ジュースの自動販売機 待機中 コイン投入 キャンセル [120円以上] 商品選択 ジュース販売 コイン投入中 購入可 [１２０円未満] コイン投入

アクティビティ図 定義： システムの動的側面をフローチャートの要領で表現する図。 （並行処理を表現することができる。）

アクティビティ図の例 アクター１ アクター２

その他の図 コンポーネント図： 配置図： ソースファイルなど、システム開発に必要なコンポーネントとそれらの依存関係を表現する図 システムを実行するハードウェアの配置やそれらの相互接続関係を表現する図

UMLで使う図（再） ユースケース図 クラス図 オブジェクト図 シーケンス図 ステートマシン図（ステートチャート） アクティビティ図 コミュニケーション図 配置図 etc.

UMLでの５つのビュー（１） システム開発を成功させるためには、開発するシステムを多様な視点（ビュー）から眺めることが大切。

UMLでの５つのビュー（２） ユースケースビュー 論理ビュー 並行性ビュー コンポーネントビュー 配置ビュー

UMLでの各種ビュー(3) 論理ビュー ユースケースビュー クラス図 オブジェクト図 シーケンス図 アクティビティ図 ユースケース図 ステートマシン図 （ステートチャート） コミュニケーション図 （コラボレーション図） コンポーネント図 配置図 コンポーネントビュー 並行性ビュー 配置ビュー

UMLでの５つのビュー（４） ユースケースビュー： アクタの視点からシステムの機能を見る視点 ユースケースビュー：　アクタの視点からシステムの機能を見る視点 論理ビュー：　システムの論理的構造をみる視点（ビジネスロジックなど） 並行性ビュー：　処理の同期・非同期に着目する視点 コンポーネントビュー：開発者のビュー。ソフトウェアコンポーネントの依存関係を見るビュー。 配置ビュー：　物理的配置を見るためのビュー

UMLでの各種ビュー(3) 論理ビュー ユースケースビュー クラス図 オブジェクト図 シーケンス図 アクティビティ図 ユースケース図 状態図 コラボレーション図 コンポーネント図 配置図 コンポーネントビュー 並行性ビュー 配置ビュー

ここまでのまとめ ソフトウェア開発は大変だ。いいプログラムなんかなかなかできない。でも、仕様をしっかり決めたり、きちんとした設計をすることは大切だよね。その一助としてモデリング言語（UML）を用いてモデル化をしっかりやろう。 　　　　　　　　　（上流工程は重要だ！）

UMLの各ダイアグラムの使い方は、システム開発を実践しながら覚えていきましょう。 （UMLの話はまずはここまで。）

次は、… ちょっと話を変えて…

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

最後にはシステム（プログラム）を作らなければ面白くないので、 少しJavaの話をします。

Javaプログラムの例 import javax.swing.JFrame; public class SimpleFrame extends JFrame{ public SimpleFrame(){ super(“Frame Title”); setSize(300,100); setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); setVisible(true); } public static void main(String[] arguments){ SimpleFrame sf = new SimpleFrame();

練習問題 前述のプログラムを実際に実行してみなさい。

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

次回までの課題

レポートではない課題１ 先ほどのJavaのプログラムを実際に実行させて見なさい。必要ならば、Javaの開発環境を整備しておくこと。 （JavacコマンドやJavaコマンドが使えればOK。エディターも必要ならばそろえておいてください。）

レポートではない課題２ 教科書の の４つの図が読めるように、練習してください。 （図に描かれていることを口頭で説明できればOKです。） 図1-1-3 図1-1-10 図1-1-18 図1-1-21 の４つの図が読めるように、練習してください。 （図に描かれていることを口頭で説明できればOKです。）

レポート課題No.2 大学の掲示版として、「個人専用の掲示板」を作るとしたらどんなものがいいのかを考え、以下の３点に関して文書化しなさい。 表示画面のデザイン（外見のデザイン） 提供する情報・サービス（情報デザイン） サービスの利用形態（誰がいつ何をどのように等） 仲間と相談してもいいよ。 これは次回提出してもらいます。

次回の予告 次回からソフトウェア開発に取り掛かります。 UML関連のツール（JudeとEclipse）の話を します。　「弘法は筆を選ばず」といいますが、IT技術者とりわけプロフェッショナルIT技術者にとっては、ツール(tool,道具）は重要です。具体的なツールの話をしますので、欠席をすると損をしますよ… PCとネットワークケーブルを持参してください。 それではまた次週！

All is over.

レポート課題No1 教科書の８ページから４０ページまでを読んで、専門用語と思われる用語を抽出し以下のように分類しなさい。 提出してください レポート課題No1 教科書の８ページから４０ページまでを読んで、専門用語と思われる用語を抽出し以下のように分類しなさい。 [手順０] A4の紙を３枚用意し、各用紙の右上に○、△、×の印を大きめに書く。 [手順１] 教科書の８～４０ページを順に読む。 [手順２] 専門用語を見つけ、もし知っている用語ならば○の紙に、知らない用語ならば×の紙に、それ以外は△の紙に、それぞれ順次書き込む。 [手順３] 集まったらコピーをとり、表紙を付けて次回授業時に提出する。原本は手元に保存しておくこと。