第8章 情報システムの役割 Copyright © the University of Tokyo この章で学ぶこと 実社会で使われている情報システムがどのように して作られているか そもそも情報システムとは何か 表からは見えない構成 作る場合に問題になること <2> Copyright © the University of Tokyo 情報システムとは 定義 情報を処理する機器（コンピュータなど） + 情報を伝達するネットワーク ⇒ さまざまなサービスや機能を提供する 例 オンラインチケット予約システム 電子掲示板 電子決済システム（銀行ATMなど） POS (Point of Sales) システム <3> Copyright © the University of Tokyo 情報システムの範囲 狭義：いわゆるビジネス・アプリケーション 企業，政府機関，サービス機関などが利用 • 外部に情報サービスを提供する • 内部の情報管理，意思決定支援に用いる 広義の例 計測や制御系のシステム 組込みシステム ゲーム機 インターネット <4> Copyright © the University of Tokyo 昔の情報システム 計算機本体 磁気テープ装置 一般の人が触る事は稀 http://ar.aichi-u.ac.jp/photo/1980/より。東大の大型計算機センターの写真 <5> 8.1 Copyright © the University of Tokyo 昔の情報システム 磁気ディスク装置 カードパンチャー http://ar.aichi-u.ac.jp/photo/1980/より。東大の大型計算機センターの写真 <6> 8.1 Copyright © the University of Tokyo 現在の情報システム ウェブサービス イベント情報提供，チケット予約 文献検索 地図検索，路線案内 商品販売，オークション 組込みシステム 携帯電話，ディジタルカメラ，カーナビ，冷蔵庫，炊飯 器など いろいろな場所に，いろいろな形態で存在する <7> Copyright © the University of Tokyo 見えにくい情報システム ソフトウェアは抽象的記述で，物理的実体がない コンピュータも見えなくなっている 組み込まれたコンピュータ • 自動車には数十のプロセッサ • 携帯電話から炊飯器まで • あまりに日常的で，情報システムであることが意識さ れない PCは端末であり，ネットワークの向こうで見えないコ ンピュータが多数稼動している <8> Copyright © the University of Tokyo 端末 ファイルサーバ proxyサーバ 認証サーバ ブートサーバ 目に見えないところでいろいろなサーバが動いている 8.1 <9> Copyright © the University of Tokyo 情報システムの仕組み ソフトウェア どんな機能か 作るときの難しさは何か ハードウェア どのような構成か ネットワークの向こうには何があるか ⇒ チケット予約システムを例に解説する <10> Copyright © the University of Tokyo チケット予約システムの概観 利用者が欲しいチケットを探す 空きがあれば 予約情報を書き込む 利用者 システム 日時 名称 価格 空き 予約者 6/20 阪神-巨人戦 4000 × 東大太郎 6/20 阪神-巨人戦 4000 ○ × 本郷三四郎 6/20 阪神-巨人戦 4000 ○ 7/1 ライオンキング 8300 × 駒場花子 7/1 ライオンキング 8300 × 駒場花子 7/1 ライオンキング 6700 ○ データベース <11> Copyright © the University of Tokyo 実際のチケット予約システム ソフトウェアの持つ機能: 沢山 公演情報の管理 ・ 公演情報の提供 ・ チケットの予約決済 ・ その他会員管理など システムの構成 利用者側: Webブラウザ・携帯電話・専用端末 サービス提供者側: 複数のコンピュータ • 利用者からの要求を受け付けるwebサーバ • 要求を処理するプログラム • 種々の情報を管理するデータベース <12> Copyright © the University of Tokyo チケット予約システムの機能 情報照会 ジャンル別，地域別の公演照会 チケット販売スケジュール照会 公演詳細情報提供 公演内容（日時，演目） 公演者（名前，プロファイル） 公演会場（会場名称，住所） チケット情報（座席別料金，座席表） 予約関連情報（予約受付先，予約受付期間，予約状況） 主催，協賛（名前，住所） 予約機能 公演の指定，チケット受け取り方法指定，予約確定，決済 付随機能 誤入力の処理，キャンセルの処理 <13> Copyright © the University of Tokyo チケット予約システムが提供する機能 細かく見てゆくと沢山ある → 作るためには列挙する必要 情報照会: ジャンル別・地域別・チケット販売スケジュール 予約機能: 公演・受け取り方法を指定 → 席の提示 → 予約確定 → 決済 付随機能: 誤入力の処理 / キャンセルの処理 公演詳細情報提供 → データベースの設計 例: 公演内容（日時，演目） / 公演者（名前，プロファイ ル） / 公演会場（会場名称，住所） / チケット情報（座席 別料金，座席表） / 予約関連情報（予約受付先，予約受 付期間，予約状況） / 主催，協賛（名前，住所） <14> Copyright © the University of Tokyo チケット予約システムの仕組み <15> Copyright © the University of Tokyo システムを作る際に大事なこと 多くはクライアント・サーバ型の構成をとる 通信規約(プロトコル) データベースの存在 安全性に配慮 一貫性の配慮 予約中に電源を 切ったら? 2人が同時に 予約したら? <16> Copyright © the University of Tokyo ウェブサービスの構造 サーバ上で動的にページを作成する仕組み： CGI, Servlet, JSPなど <17> Copyright © the University of Tokyo クライアント/サーバ型 ネットワーク上の分散システム構成 クライアント： サービスを要求 サーバ： サービスを提供 例 ウェブ • ウェブブラウザとウェブサーバ データベース メール ファイル保管 <18> Copyright © the University of Tokyo 防火壁（ファイアウォール） 不正アクセスの排除のために備えられる データベースサーバへのアクセスを制御 利用者は直接アクセスできない ウェブブラウザを使ってのアクセスのみ許可 <19> Copyright © the University of Tokyo 通信規約HTTP (HyperText Transfer Protocol) WWWクライアントとサーバの間の通信に関する 約束事 基本は情報の取得 クライ アント 欲しいページのURL (GET) ページの内容 サーバ 処理を依頼するためにも使われる サーバでプログラムが動く クライ アント 情報の提供(POST) 処理結果 <20> サーバ Copyright © the University of Tokyo 通信規約HTTP HTTP (HyperText Transfer Protocol) クライアントとサーバの間のやりとりに関する通信規 約（プロトコル）の一種 通信要求のコマンド例 • GET: クライアントがサーバから情報の資源(ページ)を 取得するために出す要求 • POST: クライアントがサーバに情報を与えるために出 す要求 <21> Copyright © the University of Tokyo ウェブに関する用語 HyperText 参照されているテキストに自動的に参照する仕組み を備えたテキスト (Vannevar Bush, As We May Think, 1945) Web ハイパーリンク（HyperTextからHyperTextへのリン ク）で相互結合された文書群 WWW World Wide Web, インターネット上に構成された(普通 の)Web, the Web <22> Copyright © the University of Tokyo データの入力 (1) GETコマンドを用いた検索 例：Googleで”ticket”を検索した場合 http://www.google.co.jp/search?sourceid=navclient &ie=UTF8&rls=GGLC,GGLC:197001,GGLC:en& q=ticket <23> Copyright © the University of Tokyo データの入力 (2) FORMタグでデータの入力欄を作る <form method=post action="/servlet/test-servlet"> 氏名： <input type="text" name="name"><br> 住所： <input type="text" name="address" size="80"><br> メール： <input type="text" name="email" size="50"><br> パスワード： <input type="password" name="password"><br> <input type="submit" value="注文"> </form> <24> Copyright © the University of Tokyo 動的なページの作成 動的なページ作成の要因 利用者からの入力データの解釈 データベースの検索 ウェブサーバ上で動的ページ作成プログラムを動 かすための仕組み CGI (Common Gateway Interface) • PerlやPHPなどのスクリプト言語で作成 Servlet • Javaで作成，CFIVEはこの仕組み JSP (JavaServer Pages) <25> Copyright © the University of Tokyo システム開発上の考慮点 利用者の使いやすさ データの機密保護 処理の一貫性 並行処理 悪意を持った攻撃への対処 <26> Copyright © the University of Tokyo 利用者の使いやすさ 使いやすくなければ利用者は離れる 使いやすさの要素 見やすいページ・デザイン 少ない入力の手間 誤入力の訂正や防止 応答の速さ <27> Copyright © the University of Tokyo データの機密保護 チケット予約は個人情報入力を求める 問題点と対策 情報の送信中の漏洩防止 ⇒ 暗号化 • SSL (Secure Socket Layer): https なりすましの防止 ⇒ 個人認証 • 利用者コードとパスワード • 生体認証（指紋，虹彩など） 収集された個人情報の外部流出防止 • • 利用の範囲：プライバシーポリシー 流出防止策：個人情報保護法 <28> Copyright © the University of Tokyo ウェブブラウザ ウェブサーバ HTTP 暗号 化 HTTP SSL 復号 暗号 →3.4.2参照 <29> Copyright © the University of Tokyo 公開鍵 秘密鍵 共通鍵 暗号化 暗号化 復号 暗号 共通鍵 復号 →3.2.3参照 <30> Copyright © the University of Tokyo 悪人の鍵をつかまされると... 公開鍵 秘密鍵 復号 共通鍵 暗号化 共通鍵 復号 <31> 秘密鍵 ? Copyright © the University of Tokyo 公開鍵の確認 ディジタル署名 確認する方 復号 公開鍵 公開鍵 秘密鍵 暗号化 確認される方 一致=OK 共通鍵 暗号化 公開鍵 秘密鍵 復号 <32> 共通鍵 Copyright © the University of Tokyo 処理の一貫性 処理の中断の可能性 ネットワーク切断，パソコンの故障，利用者の操作ミ スなど データベースの内容の一貫性の保持 予約が未完了なのに席が予約状態になったり，予約 されずに請求だけされるなどといったことを防ぐ 一連の処理をトランザクションとしてまとめる → トラ ンザクションが中断された場合はロールバックして初 期状態に戻す <33> Copyright © the University of Tokyo 並行処理 システムには同時に多数の利用者がアクセスする 重複予約の防止 排他制御 最新予約状況の表示 表示と予約実行間の状態変化への対応 <34> Copyright © the University of Tokyo 並行処理がうまくいっていない例 23Dが空いている 23Dが空いている Aさん 23Dを予約 Cさん 23Dを予約 重複登録 23Dが空いている 23Dが空いている 23Dはお待ちください 23Dが空いている Cさん Cさん Aさん Aさん 23Dを予約 もういいよ！ 23Dを予約 やっぱりやめた 予約できません! 売れ残り さっき空いているっていったじゃない？ <35> Copyright © the University of Tokyo 悪意を持った攻撃への対処 サービス拒否攻撃 (Denial of Service Attack) 不正な大量アクセスによるサーバのダウン 対策 • トラフィック量などのデータ監視による攻撃検出 → 特 定された攻撃サイトからのアクセス拒否 – DDoS (分散DoS, Distributed DoS)で対抗される可能性も • ログデータの収集と分析 <36> Copyright © the University of Tokyo さまざまな情報システム 組込みシステム コンビニの商品管理システム オンライン金融取引システム ディジタルアーカイブ・システム <37> Copyright © the University of Tokyo 組込みシステム 装置や機器に組み込まれ，それを制御するコン ピュータシステム 構成要素 入力： センサーなどから流入する連続的/間歇的 信号 出力： アクチュエータ（動作装置）への制御信号 表示装置へのデータ出力 <38> Copyright © the University of Tokyo 組込みシステムの特性 実時間 (realtime) 性 厳しい資源制約 CPU能力，記憶容量，電源容量，発熱量，コスト 高い信頼性の要求 不具合の社会的影響 リコールのコスト • 信頼性を向上させるためのコストとのトレードオフ 優れた操作性による誤操作の防止 <39> Copyright © the University of Tokyo Therac-25事件 Therac-25: 放射線治療機 電子ビーム治療, 低エネルギー, 短時間 X線治療, 高エネルギー電子ビームをターゲットに当 ててX線を放射 事件の概要 誤動作により，ターゲットがセットされないまま高エネ ルギー電子ビームを照射 過被爆で６人死亡 <40> Copyright © the University of Tokyo Therac-25事件の問題点 古いプログラムをそのまま使用した エラー警告はあったが説明が無かった 病院が患者の訴えを信じなかった 安全装置をコストダウンのために削った 高価な機器なので事故発生後も使用した インタフェースのタイミング問題があった オペレータが操作に慣れ操作が早くなると発生した アセンブリ言語で記述されていた デバッグがしにくい <41> Copyright © the University of Tokyo USS Yorktown dead in water after divide by zero "Peter G. Neumann" <[email protected]> Tue, 21 Jul 1998 13:07:45 -0700 The Navy's Smart Ship technology is being considered a success, because it has resulted in reduced manpower, workloads, maintenance and costs for sailors aboard the Aegis missile cruiser USS Yorktown. However, in September 1997, the Yorktown suffered a systems failure during maneuvers off the coast of Cape Charles, VA., apparently as a result of the failure to prevent a divide by zero in a Windows NT application. The zero seems to have been an erroneous data item that was manually entered. Atlantic Fleet officials said the ship was dead in the water for about 2 hours and 45 minutes. A previous loss of propulsion occurred on 2 May 1997, also due to software. Other system collapses are also indicated. [Source: Gregory Slabodkin, Software glitches leave Navy Smart Ship dead in the water, Government Computer News, 13 Jul 1998, PGN Stark Abstracting from http://www.gcn.com/gcn/1998/July13/cov2.htm] <42> Copyright © the University of Tokyo US Navy’s Harvard Mark II 初めてbugと いう用語が使 われたという 話 もっとも，bug という用語は それ以前から 使われていた らしい http://www.history.navy.mil/photos/pers-us/uspers-h/g-hoppr.htm 1947.9.9 <43> Copyright © the University of Tokyo Mr. Edison, I was informed, had been up the two pervious nighs divcovering ``a bug’’ in his photograph - an experssion for aolving a difficulty, and implying that some imaginary insect has secreted itself inside and is causing all the trouble --- Pall mall Gazette, 1889 I ranged from the pre-design development of essential components, through the stage of type test and flight test and ``debugging’’ right through to later development of the engine. --- Journal of the Royal Aeronautical Society, 1945 <44> 8.3.1 Copyright © the University of Tokyo 組込みシステム例: ディジタルカメラ <45> Copyright © the University of Tokyo 組込みシステム例: ディジタルカメラ シャッター ボタン 画像記録装置 オートフォーカス レンズ駆動 <46> 自動露出 コントラスト検出 CCD 画像生成 Copyright © the University of Tokyo ディジタルカメラの基本機能 撮影機能 静止画撮影，動画撮影の切り替え，撮影，オートフォーカス設定 セルフタイマーの設定，ズーム設定，フラッシュのモード切り替え 画像サイズと画質の設定，ホワイトバランス設定 出力編集機能 外部インターフェースへの画像出力 撮影した画像の通常再生，拡大再生 画像編集機能 削除，消去禁止設定 付加機能 撮影日時などの表示設定，時計設定，操作音の切り替え 記録媒体のフォーマット <47> Copyright © the University of Tokyo ディジタルカメラのシステム構成 制御系 センサー: 撮像素子（CCDやCMOS) アクチュエータ： 自動焦点用のレンズ移動装置等 情報系 画像データのメモリーカードなどへの記録，管理 画像データの画面表示 データの外部転送 インターフェース シャッターボタン，入力用ボタン，レバー，液晶画面などによる インターフェース <48> Copyright © the University of Tokyo カメラ特有の制御機構 自動焦点機構 撮像素子からの画像信号を解析 コントラスト最大位置の探索 アクチュエータによるレンズ位置移動 自動露出機構 光量を測定 絞りとシャッター速度を決定 <49> Copyright © the University of Tokyo 商品管理システム POS (Point of Sales) = 販売時点管理 売れ筋の把握 緻密な在庫・受発注管理 レシート記述情報の詳細化 バーコードからICタグへ 無線による自動認識： RFID (Radio Frequency Identification) 情報量が多い 書き換えができる 複数を同時に読むことができる <50> Copyright © the University of Tokyo バーコード <51> Copyright © the University of Tokyo ICタグ <52> Copyright © the University of Tokyo ICカードのシステム TypeA TypeB 住民基本台帳カード 学生証 TypeC Felica • Suica • Edy <53> Copyright © the University of Tokyo ICカードのシステム 偽造が困難 秘密鍵が入っている ICカードのなかで暗号化する 失効管理が可能 鍵をなくすと大変 多機能 カードにいろいろなアプリケーションを載せることができる • 共通ID • ポストペイ • SafetyPass <54> Copyright © the University of Tokyo オンライン金融取引システム インターネット上での株式売買 ホームトレード 市場規模の増大 プロと素人の混在 外国為替取引 シミュレーション・システム例 <55> Copyright © the University of Tokyo <56> Copyright © the University of Tokyo ディジタルアーカイブ・システム 歴史資料や芸能をディジタル情報に変換して保存 タグ付けによる検索支援と情報管理 対象となる文化資産 静的：絵画，彫刻，仏像，歴史的建築物など 動的：舞踊，歌舞伎，能など <57> Copyright © the University of Tokyo
© Copyright 2025 ExpyDoc
