Webシステム授業資料

Transcription

1 Web システムプログラミング b 第 11 講目 Web システムプログラミング講義資料

2 到達目標 到達目標 Web システムを設計し 開発できること 最終成果物 : 学生生活で利用できる Web システム 授業計画 第 10 講 :Webシステムの基本設計 (1) 第 11 講 :Webシステムの基本設計 (2) 第 12 講 :WebシステムのDB 設計 第 13 講 :WebシステムのUI 設計 第 14 講 :Webシステムの処理 第 15 講 : まとめ 平常試験 (2) 2

3 第 10 講 :Web システムの基本設計 (1) 講義内容 Web システムの設計工程 業務分析 要件定義 基本設計 論理設計 詳細設計 Web システムの構成 各種 Webアプリケーションフレームワーク紹介 Model-View-Controller(MVC) に基づく設計 レポート課題 学生生活で利用できる Web システムの要件定義書 システムのタイトルと最終成果物の洗い出し 要件定義書 レポートに最低限書く内容 業務分析 要件定義を行うこと 最終成果物の確認 (DB 定義書 画面遷移図 フローチャートなど ) 3

4 第 10 回レポート課題の解答例 (1) タイトル : ゼミ室の蔵書管理システム 業務分析 ゼミ室には教員の専門分野に関する書籍が豊富にある 研究を進める際に ゼミ生はゼミ室で書籍を読んだり 必要に応じて教員から許可を得て書籍を借りたりする 教員は誰に何の書籍を貸しているかは管理できていない 要件定義 ゼミ室の蔵書と貸し出し記録を管理したい 教員はゼミ生の名簿と蔵書を管理したい 教員 またはゼミ生は貸し出し記録を付けた 書籍の貸し出し冊数は 5 冊まで 期限は 2 週間とする 4

5 第 10 回レポート課題の解答例 (2) 最終成果物一覧 第 10 回分 (12/6 提出 ): 要件定義書 第 11 回分 (12/13 提出 ): 基本設計書 機能 データ構造 画面設計図 第 12 回分 (12/20 提出 ):ER 図 テーブル定義書 第 13 回分 (1/10 提出 ): 画面遷移図 第 14 回分 (1/17 提出 ): 設計書一式 これまでの設計書の修正分 実行結果と考察 5

6 業務分析 前回レポートのポイント 現状の仕組みがどうなっているかを書く 作業の内容 流れ 問題点などを書く よくない例 ( 主観的な感想になっている ) ゲームをただ遊ぶだけではもったいない 就活でそういった企業に行く時の強みになる 要件定義 業務がどう改善されればよいかを書く システムの機能はここでは書かない 6

7 システム設計の流れ DB 設計はシステム設計の一部 業務分析 今の業務はどうなっているのか 要件定義 何をしたいのか 今回はこの部分が中心 基本設計 どんなシステムにすべきか DB 設計はこの段階に含まれる 論理設計 どのように実現するか DB 設計 =DB の構造を設計 詳細設計 方法を明確にする TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES 7

8 各工程での成果物 成果物 業務分析 要件定義書 要件定義 基本設計 基本設計書 論理設計 ER 図 テーブル定義書画面遷移図 詳細設計 詳細設計書 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES 8

9 第 11 講 :Web システムの基本設計 (2) 講義内容 スピーディーな開発手法 Web API ライブラリの活用 ソーシャル連携サービス Web システムの基本設計 機能 データ構造 画面設計図 レポート課題 学生生活で利用できる Web システムの基本設計書 システムの機能とデータ構造 データの登録 表示 更新 削除ができること (CRUD) ログイン機能があると尚良 ( 要セッション管理 ) 画面設計図 9

10 Web システムの開発最前線 スピーディーな開発 クラウドの活用 Amazon Web Services Microsoft Azure Heroku マッシュアップ ( プログラムのパーツの組み合わせ ) Web API ソーシャルログイン ライブラリ(git) CMS(Content Management System) の活用 WordPress Movable Type NetCommons Joomla! Moodle Mahara 10 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES

11 クラウドの必要性 クラウドの活用 Webシステムの開発 公開にはサーバが必要 サーバ以外にもネットワーク 電源や空調などが必要 コストや効率性を考慮したVPS( 仮想サーバ ) という選択肢 代表的なクラウドサービス (IaaS or PaaS) AWS(Amazon Web Services) Apache CloudStack Heroku 11

12 AWS(Amazon Web Services) Amazon が提供する仮想サーバやデータベースサーバ 独自 Web サイト EC サイトの構築が可能 インスタンス = 仮想サーバの実体 インスタンスの情報 公開用 IP アドレス 12

13 AWS で動作中の Web システム 公開用 IP アドレス ターミナル画面 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES 13

14 Apache CouldStack 情報大卒業生に学内 VPS を研究した学生がいた ゼミ プロジェクトの Web サーバに利用可能 実行中のインスタンス 14

15 Heroku Ruby on Rails 用の PaaS(Platform as a Service) 現在は Java, Node.js, Scala, Python, PHP などもサポート 15

16 マッシュアップとは マッシュアップ 複数のWeb APIやWeb 上のデータを組み合わせること メリット 既存 Webシステムの機能やデータ活用による新サービス提供 システム開発効率の向上 課題 Web APIのインタフェースやフォーマットの統一 Web APIの学習コストの削減 マッシュアップの分類 presentation マッシュアップ data マッシュアップ logic マッシュアップ 16

17 presentation マッシュアップ 概要 Web ページ内に 1 つ以上の Web システムのコンテンツをまとめて表示すること 実現方法 各サービスが提供するスクリプトの埋め込み 具体例 Twitter ウィジェット Facebook ソーシャルプラグイン ブログパーツ 17

18 data マッシュアップ 概要 複数のWebシステムからデータを取得し結合すること 実現方法 Web API( 多くが地図 API) を使ってデータを重ねあわせて表示 多くが地図ベースのマッシュアップとして実現 具体例 気象情報サービス 災害情報マップ お祭りの山車位置共有サービス お祭りの出店マップ 18

19 logic マッシュアップ 概要 複数のWeb APIの入出力処理を連結させること 実現方法 あるAPIの出力結果を別のAPIの入力に与えて処理する 高度なプログラミング知識が必要となる 具体例 到着地の住所から経路探索 実際は開発者しか知らない 19

20 ソーシャル連携サービス Web API の活用 Twitter FacebookのIDによる認証機能 Twitter Facebookでのつながり情報 登録情報の活用 Web API の利用 プログラムから外部 Web システムの機能を利用する関数群 インターネット プログラム例 : ブログ D 1 問い合わせ 3 返信 A P I Web システム 2 データ処理 D DB 図. Web API の仕組み TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES 20

21 ソーシャルアカウントでのログイン 21 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES

22 スピーディーな開発の事例 Tripline: 旅の軌跡を記録するサービス 旅の軌跡 認証 地図 シェア マッシュアップによる開発速度 & 利便性向上 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES 22

23 CMS(Content Management System) CMS とは Web の専門知識がなくても Web サイト管理ができる 一般利用者でも Web サイト運用が可能 コンテンツとレイアウトの分離 ライターとデザイナーの分業が容易 代表的な CMS WordPress: ブログ Webサイトとして広く利用 Movable Type: 企業のWebサイトとして利用 OpenPNE:mixi 同様のSNSを構築可 NetCommons:eラーニングサイトに利用 Joomla!: 高機能な CMS サイト全体のデザイン統一 23

24 WordPress のインストール画面 24 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES

25 WordPress で作成したサイト 25 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES

26 Joomla! による Web サイト作成例 26 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES

27 Joomla! の管理画面 コンテンツとテンプレートを分けて管理可能 記事やメニュー 画像の登録 編集が可能 記事の一覧 27

28 Web 開発での必須スキル Web 開発技術の基本 HTML/CSSは基本中の基本 Webの仕組み :HTTP GET/POST クライアントサイド : ブラウザ JavaScript jquery サーバサイド :PHP Ruby Servlet DB サーバ運用 :Linux Apache ネットワーク 学び方は実践あるのみ! まずは Web 開発の全体的な知識を得る 実際に開発をしながら 自分の得意分野を見つける 28

29 基本設計 Web システムの基本設計 機能設計 データ構造は前回の講義を参照 機能設計 : 要件定義を満たす機能の洗い出し データ構造 : 機能を実現するために記録すべきデータの整理 画面設計図 機能毎に必要な画面とその構成を図示する 各画面の入力フォームの内容 ボタンの配置など ボタン操作時の処理や画面遷移はまだやらなくてよい 29

30 レポート課題 学生生活で利用できる Web システムの基本設計書 システムの機能とデータ構造 データの登録 表示 更新 削除ができること (CRUD) ログイン機能があると尚良 ( 要セッション管理 ) 画面設計図 データの登録 表示 更新 削除に対応した画面設計を行うこと データの種類毎の一覧表示 新規登録 編集画面があるはず 削除はボタン操作のみでOK( 入力情報がないため ) 30

31 機能 レポート作成例 : 基本設計 (1) ログイン機能 ユーザの ID パスワードでログイン ユーザ管理機能 ユーザの追加 更新 削除が可能 ユーザ毎に権限を付与し 利用できる機能を制限 蔵書登録機能 書籍の追加 更新 削除が可能 書籍のタイトル カテゴリ 出版社 発行年などを管理 条件を指定した蔵書検索が可能 貸し出し機能 ユーザへの書籍貸し出しを台帳に記録 ユーザへの貸し出し冊数の上限と期限を設ける 31

32 レポート作成例 : 基本設計 (2) データ構造 ユーザ情報 ユーザID パスワード 名前 権限( 管理者 or 利用者 ) ユーザ情報を変更できるのは管理者のみ 蔵書情報 書籍のタイトル カテゴリ 出版社 発行年 貸出台帳 書籍と貸し出したユーザの紐付け 貸出日 返却予定日 貸出状態 ( 貸出 OK or 貸出中 ) 32

33 レポート作成例 : 基本設計 (3) 画面設計図 : 蔵書リスト画面 書籍リストを表形式で表示 各レコードの操作が可能 書籍の新規登録 図作成には リアルタイムコラボレーションツール Cacoo を利用 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES 33

34 レポート作成例 : 基本設計 (4) 画面設計図 : 蔵書新規登録画面 すべての項目を入力し 登録 ボタンで登録可 タイトル 出版社 : テキストボックス カテゴリ 発行年 : 選択ボックス 34

35 レポート作成例 : 基本設計 (5) 画面設計図 : 蔵書貸出画面 貸出可 より蔵書の貸出が可能 貸出書籍 より自分の書籍貸出状況を確認可 貸出操作が可能 35

36 リレーショナルデータベースの復習 用語 スキーマ (schema):dbの構造を定義したもの 表 ( テーブル table): リレーションともよぶ 行 ( レコード row):1 件のデータのこと 列 ( フィールド column): 各項目のこと 36

37 関係モデルと関係データベース 関係モデル 例 : 商品 を 輸出先 に 売る という関係 関係モデルの考え方を使って関係データベースを設計 37

38 データベース設計の手順 1. データとその関連 (ER) を分析する 2. 表を作る 3. 表を正規化する 第一正規形 第二正規形 第三正規形 38

39 ER モデル データとその関連 (ER) の分析 現実世界をEntity( 実体 ) とRelationship( 関連 ) に概念化 現状の世界からにEntity( 実体 ) をとらえる 例 : 商品 ( 商品コード 商品名 単価 ) 例 : 輸出先 ( 輸出先コード 輸出先名 ) 実体同士の Relationship( 関連 ) について考える 例 : 売上 39

40 ER モデル Entity( 実体 ) と Relationship( 関連 ) 多数の商品が多数の輸出先に売られる 多数の輸出先は多数の商品を買っている 多対多の関係 商品がひとつの場合 1 対多の関係となる 商品ひとつ輸出先ひとつの場合 1 対 1 の関係となる TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES 40

41 ER 図 ER モデルをよりデータベース設計に近い形で図式化 様々な書き方がある 41

42 データベース設計の手順 1. データとその関連 (ER) を分析する 2. 表を作る 3. 表を正規化する 第一正規形 第二正規形 第三正規形 42

43 表の作成 売上報告書から表を作成してみる 43 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES

44 非正規形 繰り返し項目が排除されていない表 リレーショナルデータベースでは 非正規形の表はうまく処理できない 44 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES

45 データベース設計の手順 1. データとその関連 (ER) を分析する 2. 表を作る 3. 表を正規化する 第一正規形 第二正規形 第三正規形 45

46 正規化 現実世界のデータをリレーショナルデータベースの表に落とし込む作業 1 行に 1 つの値が入る表の形にする 非正規形の表をデータの矛盾が発生しないよう複数の表に分割する 46

47 第一正規形を作る 1 行に 1 つの値が入るように表を分割する 47 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES

48 第一正規形 第一正規形の表まとめ 表を2 次元の単純な表としたもの 1 行に1つの値が入るようにした表 売上明細 ( 第一正規形 2) の問題点 商品に関するデータと売上に関するデータが混在 新しい商品でまだ売っていない商品は追加できない 48

49 第二正規形を作る (2) 売上明細 ( 第一正規形 2) を分割する 49 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES

50 第二正規形を作る (3) 主キーによって他の列の値がきまる 商品 表は 商品コード 列の値が決まると 商品名 と 単価 の値が決まる 売上明細 表は 報告書コード 列と 商品コード 列の値が決まると 個数 の値が決まる 50

51 第二正規形 主キーによって他の列の値が決まるようにした表 関数従属 ある列の値によって他の列の値が決まる こと 主キーに他の列が関数従属するように表を分割する 51

52 第二正規形の表まとめ 売上 ( 第一正規形 1) はそのままで第二正規形 主キーの 報告書コード が決まると他の値が決まる 52

53 第三正規形を作る (1) 売上 ( 第二正規形 3) の問題点 売上 表には 輸出先に関するデータと売上に関するデータが混在 一度も輸出していないが輸出先には存在するイタリアを管理できない! 53

54 第三正規形を作る (2) 売上 表 ( 第二正規形 3) を分割する 54 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES

55 第三正規形 各項目の値が 主キーのみで決まる表 推移従属している ある列の値によって間接的に他の列の値が決まる こと 第三正規形では 推移従属を除くように表を分割 55

56 第三正規形 ( 補足 ) 売上 表 ( 第二正規形 3) では 報告書コード が決まれば 輸出先コード が決まり それにより間接的に 輸出先名 が決まっていた 56

57 第三正規形にまでにした表 リレーショナルデータベースではこの表を使う 57 TOKYO UNIVERSITY OF INFORMATION TOKYO JOHO UNIVERSITY SCIENCES