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

基礎情報技術
ー第4日目ー
平成23年5月18日（金）
担当：亀田
確認
• 授業で使用した資料は授業終了後にWebに
て公開します。
• 授業中はノートなどにメモを取ってください。
（キーワードや図だけでも結構です。）
• 本日出される(?)レポート課題No.1は来週
（明日ではない）の授業終了時に集めます。
宿題（再掲）
•
大学の掲示版として、「個人専用の掲示板」
を作るとしたらどんなものがいいのかを考え、
以下の３点に関して文書化しなさい。
1. 表示画面のデザイン（外見のデザイン）
2. 提供する情報・サービス（情報デザイン）
3. サービスの利用形態（誰がいつ何をどのように等）
最終回までの
課題でしたよね！
これは授業最終回の時に提出してもらいます。
参考文献
• 情報デザイン原論「ものごと」を形にするテンプレート,
ロバート・ヤコブソン(編), 食野雅子(訳),
電機大出版局(2004).
それでは始めましょう
• 一呼吸して、気持ちをこちらに集中させて
ください。
集中力を高め、それを維持し
続けることは成功のための
秘訣です。訓練してください。
前回までのポイントの確認
• ITのプロになるためには何が必要か？
これを考えるための素材をお話しました。
– SEの仕事はプログラミングだけではない
– ソフトウェアのライフサイクル
– オブジェクト指向
– モデリング言語 UML など
• ソフトウェア開発過程の概要
• UMLの概説
ITのプロとは
• 技術に関して深い理解がある
– 哲学・思想（個別技術から技術史等に対する）
• 技術を身につけている
– オブジェクト指向、UML、デザインパターンなど
• 仕事の進め方を知っている
– ソフトウェアとは
– ソフトウェア開発とは
– プロジェクトとはなど
• コスト計算ができる
– 実社会の在り方・仕組みを理解している。
大学ではまず基礎・基本をしっかり身につけよう！
ソフトウェアのライフサイクル
1. 要求分析
2. 設計
3. プログラミング
4. デバッグ
5. 評価
6. 運用
⇒再び１へ戻る
1. 何を作るの？
2. どうるの？
3. 作成作業
（デバッグも）
4. 本当にできた？
5. 実際に使おう！
6. ちょっと変更
ソフトウェアの開発工程でもある
UMLでの各種ビュー(3)
論理ビュー
ユースケースビュー
クラス図
オブジェクト図
シーケンス図
ユースケース図
アクティビティ図
ステートマシン図
（ステートチャート）
コミュニケーション図
（コラボレーション図）
コンポーネント図
配置図
コンポーネントビュー
並行性ビュー
配置ビュー
今日の話し
•
•
•
•
•
要求分析
ユースケースとユースケース図
よい設計とは
Javaプログラミング（おまけ）
その他
要求分析
• まずはここから始まる。
（「必要は発明の母」）
要求分析
•
•
•
•
•
電子掲示板システム（東京工科大向け）
コーヒーメーカ
カードゲーム(BlackJack)
図書館システム
小売店販売管理システムなど
コーヒーメーカ
WikiPediaより引用(2008/05/16)
要求される仕様
• 商品名：Mark IV Special
• 用途：コーヒーを入れるための装置
• 具体的な仕様は配布資料参照のこと。
• これを元に要求を分析してみよう
（深く理解してみよう）
分析メモ
• ハードウェア構成ではなく
• 処理（振る舞い）の側面から分析
– 誰が，どんな振る舞いをするのか？
– 誰が誰にどんな時に呼び出されるのか。
（注）
• 誰＝インスタンス
• 振る舞い＝メソッド
• どんな時に＝ロジックなど
ユースケース
• ユースケースとは、システムが提供する
サービスや機能をユーザの視点から記述す
るもの。
• ユースケースを表現する方法は２つある。
– ユースケース記述（シナリオ記述）
• 文章で記述
– ユースケース図
• ダイアグラムで記述
ユースケース記述
• ユースケース記述は大きく２つに大別される
– 基本ユースケース
• 標準的なあるいは本来の処理を記述
– 代替ユースケース
• 例外的なケース（場合）を記述
例：ログイン失敗など
販売システムのユースケース記述例
•
販売システムの流れ（基本ユースケース記述）
1.
2.
3. …
販売システムのユースケース記述例
•
販売システムの流れ（基本ユースケース記述）
1. レジ係りがスキャナで
商品のバーコードを読み取る。
2. 商品の値段・商品名、現在までの合計金額を
お客にディスプレイ表示。
値段・説明はレジ係りにも表示。
3. 値段と商品名が書かれたレシートを印刷。
4. バーコードが認識されたことを
音でレジ係りに知らせる。
販売システムのユースケース記述例
•
販売システムの流れ（代替ユースケース記述）

（考えてみよう！）
販売システムのユースケース記述例
•
販売システムの流れ（代替ユースケース記述）




バーコードが読み取れない
バーコードが書かれていない
会計処理途中で停電になった
お客さんがいなくなった
スキャナの紹介（雑談）
• バーコード（例：JANコード、ISBN）
• QRコード（２次元コード）
（自由課題）：興味のあるひとは、一度じっくり
調べてみてください。
ユースケース図を描いてみよう
• （販売システムのユースケース）
ユースケースの参考書
• ユースケース実践ガイド―効果的なユース
ケースの書き方,アリスターコーバーン,翔泳
社(2001).
• “Writing Effective Use Cases,” Alistair
Cockburn, Addison-Wesley(2001).
さて、…
Mark IV Special Coffee Maker
(配布資料参照のこと)
Mark IV Special Coffee Maker
1. 煮沸器(boiler)の電熱線(heater)、on/off可
2. 保温プレート(warmer plate)の電熱線も。
3. 保温プレートのセンサ。
 状態：warmerEmpty, potEmpty, potNotEmpty
4. 煮沸器のセンサ。水の有無判定。
 状態：boilerEmpty, boilerNotEmpty
5. ドリップボタン。ドリップ開始ボタン。インジケ
ータ（light）付き。ドリップ完了時に点灯。
6. 蒸気圧抑制バルブ。開くと蒸気圧降下。
APIの説明
この関数は、保温プレートセンサの状態を返す。こ
のセンサにより、ポットが置かれているかどうか、
ポットの中にコーヒーがあるかを検出する。
public int getWarmerPlateStatus();
public static final int WARMER_EMPTY = 0;
public static final int POT_EMPTY = 1;
public static final int POT_NOT_EMPTY = 2;
APIの説明（２）
この関数は、煮沸器のスイッチの状態を返す。
煮沸器のスイッチは、煮沸器に水が半分以上あ
るかどうかを検出するフロート式スイッチ。
public int getBoilerStatus();
public static final int BOILER_EMPTY = 0;
public static final int BOILER_NOT_EMPTY = 1;
APIの説明（３）
この関数は、[ドリップ]ボタンの状態を返す。 [ドリップ]ボタ
ンは、その状態を記憶する一時的なスイッチ。この関数は
呼び出されるたびに、記憶された状態が返され、状態は
BREW_BUTTON_NOT_PUSHUED にリセットされる。従
って、この関数が非常に遅いレートでポールされても、[ドリ
ップ]ボタンが押されたことを検出できる。
public int getBrewButtonStatus();
public static final int BREW_BUTTON_PUSHED = 0;
public static final int BREW_BUTTON_NOT_PUSHED = 1;
APIの説明（４）
この関数は、煮沸器内の電熱線のオン/オフを
切り替える。
public void setBoilerState(int boilerStatus);
public static final int BOILER_ON = 0;
public static final int BOILER_OFF = 1;
APIの説明（５）
この関数は、保温プレート内の電熱線のオン/
オフを切り替える。
*/
public void setWarmerState(int
warmerState);
public static final int WARMER_ON = 0;
public static final int WARMER_OFF = 1;
APIの説明（６）
この関数は、インジケータのオン/オフを切り替える。
インジケータは、ドリップが完了すると点灯し、[ドリップ]
ボタンが押されると消える。
public void setIndicatorState(int indicatorState);
public static final int INDICATOR_ON = 0;
public static final int INDICATOR_OFF = 1;
APIの説明（７）
この関数は、蒸気圧調整バルブを開閉する。バルブが
閉まっていると、煮沸器内の蒸気圧によって熱湯がコ
ーヒーフィルタ状に噴き出す。バルブが開いていると、
煮沸器内の蒸気が外に排出され、中の水はフィルタ上
に噴き出なくなる。
public void setReleifValveState(int releifValveState);
public static final int VALVE_OPEN = 0;
public static final int VALVE_OFF = 1;
コーヒーメーカの
ユースケース記述とユースケース図
シナリオ
フィルタをフィルタホルダーに入れる。
便利なUMLツール(astah)の紹介
• 各自ダウンロードしてください。
• 中村太一先生の講義用ホームページ
（学内専用サイト）から正規版が
コピーできます。(CS学部生限定!!!)
• 簡単な説明を次回授業中にします。
• フリー版(Community版)でもかまいません。
• 他のUMLツールでもOKです。
自由課題
• UMLツールとしてどのようなものがあるのか、
調べなさい。
– ソフトウェア名
– 製造・販売会社名
– 価格
– 機能
– 動作環境
– その他
よい設計とは
• 分かりやすい
• 変更しやすい
• 再利用しやすい
などの特徴を持った設計のこと
設計を悪くする要因
•
•
•
•
•
•
•
硬直性
脆弱性
低移植性
粘着性
不要な複雑さ
不要な繰り返し
不透明さ
• 硬直性：システムの変更しにくさ。
• 脆弱性：１つの変更が他の多くの変更を
引き起こしてしまう。
• 低移植性：システムのコンポーネント化が
不十分なため、再利用しにくい。
• 粘着性：エディットーコンパイルーテストが
終わらない。
• 不要な複雑さ：いつか役立つであろう
コードであふれている。
• 不要な繰り返し：カット＆ペーストの
オンパレード。
• 不透明さ：内容が込み入っていて作成者の
意図が見えない。
では「良い設計」はどうすれば
いいのか？
• （次回以降、順次説明します。）
ここから重要なお知らせ
自由課題：Javaプログラミング
•
•
•
•
スライドに関するプログラム例
実際に実行してみてください。
プログラムの詳細を理解してください。
パラメータを変えて実行してみてください。
• ソースコードはWebページにおいておきます。
必ず提出してください
•
宿題（確認）
大学の掲示版として、「個人専用の掲示板」
を作るとしたらどんなものがいいのかを考え、
以下の３点に関して文書化しなさい。仲間と相
1. 表示画面のデザイン（外見のデザイン）
談しても
2. 提供する情報・サービス（情報デザイン）
いいよ。
3. サービスの利用形態（誰がいつ何をどのように等）
最終回までの
課題でしたよね！
これは授業最終回の時に提出してもらいます。
この宿題のための予備として次の
ページのレポート課題No.1を次回
までにやってください。
（単位取得希望者全員）
レポート課題No.1
•
大学の掲示版として、「新しいスマホアプリの
掲示板システム」を東京工科大学に提案した
い。そのために、システム提案書（第１版）を
作成してください。提案書の内容構成（目次）
は、以下のようにしてください。（まずは、書け
る範囲で結構ですが、目次の１，２，４の青枠
の部分は最低限書いてください。）
これは次回提出してもらいます。
仲間と相談
してもいい
よ。
レポート課題No.1（続き）
•
•
表紙（学籍番号・氏名を大きくはっきりと書く）
目次
1.
2.
3.
4.
5.
6.
7.
8.
9.
東京工科大学の抱えている課題・利用学生の不満
問題解決のための方法
システム化の範囲
機能概要・前提条件・制約条件
情報やデータの流れ
想定する利用者
システムのハードウェア構成・ソフトウェア構成
システム化にかかる費用とそれによる効果
このシステム提案のアピールポイント
おわりに
• 次回は…
– グループに分かれてPBLを実施します。
(Project Based Learning)
– PBL自体については次回説明をします。
– グループごとにソフトウェア開発を実践してもらい
ます。
– 従って、たくさんのドキュメントを書きます。
– PCとともに、筆記用具を必ず持参してください。

Download Report