Webシステム授業資料

Webシステムプログラミングb

第11講目

到達目標



到達目標

Webシステムを設計し、開発できること

最終成果物：学生生活で利用できるWebシステム



授業計画

第10講：Webシステムの基本設計 (1)

第11講：Webシステムの基本設計 (2)

第12講：WebシステムのDB設計

第13講：WebシステムのUI設計

第14講：Webシステムの処理

第15講：まとめ、平常試験 (2)

T

J

U

T

U

I

S

T

U

I

S

第10講：Webシステムの基本設計 (1)



講義内容

Webシステムの設計工程

業務分析、要件定義、基本設計、論理設計、詳細設計

Webシステムの構成

各種Webアプリケーションフレームワーク紹介

Model-View-Controller（MVC）に基づく設計



レポート課題

学生生活で利用できるWebシステムの要件定義書

システムのタイトルと最終成果物の洗い出し、要件定義書

レポートに最低限書く内容

業務分析・要件定義を行うこと

最終成果物の確認（DB定義書、画面遷移図、フローチャートなど）

第10回レポート課題の解答例（1）



タイトル：ゼミ室の蔵書管理システム



業務分析

ゼミ室には教員の専門分野に関する書籍が豊富にある

研究を進める際に、ゼミ生はゼミ室で書籍を読んだり、

必要に応じて教員から許可を得て書籍を借りたりする

教員は誰に何の書籍を貸しているかは管理できていない



要件定義

ゼミ室の蔵書と貸し出し記録を管理したい

教員はゼミ生の名簿と蔵書を管理したい

教員、またはゼミ生は貸し出し記録を付けた

書籍の貸し出し冊数は5冊まで、期限は2週間とする

T

J

U

T

U

I

S

T

U

I

S

第10回レポート課題の解答例（2）



最終成果物一覧

第10回分（12/6提出）：要件定義書

第11回分（12/13提出）：基本設計書

機能、データ構造、画面設計図

第12回分（12/20提出）：ER図、テーブル定義書

第13回分（1/10提出）：画面遷移図

第14回分（1/17提出）：設計書一式

これまでの設計書の修正分

実行結果と考察

前回レポートのポイント



業務分析

現状の仕組みがどうなっているかを書く

作業の内容、流れ、問題点などを書く

よくない例（主観的な感想になっている）

ゲームをただ遊ぶだけではもったいない

就活でそういった企業に行く時の強みになる



要件定義

業務がどう改善されればよいかを書く

システムの機能はここでは書かない

T

J

U

T

U

I

S

T

U

I

S

システム設計の流れ



DB設計はシステム設計の一部

業務分析

要件定義

基本設計

論理設計

詳細設計

今の業務はどうなっているのか

何をしたいのか

どんなシステムにすべきか

どのように実現するか

方法を明確にする

DB設計は

この段階に含まれる

DB設計＝DBの構造を設計

今回はこの部分が中心

各工程での成果物



成果物

業務分析

要件定義

基本設計

論理設計

詳細設計

要件定義書

基本設計書

ER図、テーブル定義書

画面遷移図

詳細設計書

T

J

U

T

U

I

S

T

U

I

S

第11講：Webシステムの基本設計 (2)



講義内容

スピーディーな開発手法

Web API、ライブラリの活用

ソーシャル連携サービス

Webシステムの基本設計

機能、データ構造、画面設計図



レポート課題

学生生活で利用できるWebシステムの基本設計書

システムの機能とデータ構造

データの登録・表示・更新・削除ができること（CRUD）

ログイン機能があると尚良（要セッション管理）

画面設計図

Webシステムの開発最前線

• クラウドの活用

• Amazon Web Services、Microsoft Azure、Heroku

• マッシュアップ（プログラムのパーツの組み合わせ）

• Web API、ソーシャルログイン、ライブラリ（git）

• CMS（Content Management System）の活用

• WordPress、Movable Type、NetCommons、Joomla!

• Moodle、Mahara

スピーディーな開発

スピーディーな開発

T

J

U

T

U

I

S

T

U

I

S

クラウドの活用



クラウドの必要性

Webシステムの開発・公開にはサーバが必要

サーバ以外にもネットワーク、電源や空調などが必要

コストや効率性を考慮したVPS（仮想サーバ）という選択肢



代表的なクラウドサービス（IaaS or PaaS）



AWS（Amazon Web Services）

Apache CloudStack



Heroku

AWS（Amazon Web Services）



Amazonが提供する仮想サーバやデータベースサーバ

独自Webサイト、ECサイトの構築が可能

インスタンス＝仮想サーバの実体

インスタンスの情報

_{公開用IPアドレス}

T

J

U

T

U

I

S

T

U

I

S

AWSで動作中のWebシステム

13

公開用IPアドレス

Apache CouldStack



情報大卒業生に学内VPSを研究した学生がいた



ゼミ・プロジェクトのWebサーバに利用可能

14

実行中のインスタンス

T

J

U

T

U

I

S

T

U

I

S

Heroku



Ruby on Rails用のPaaS（Platform as a Service）



現在はJava, Node.js, Scala, Python, PHPなどもサポート

マッシュアップ



マッシュアップとは

複数のWeb APIやWeb上のデータを組み合わせること

メリット

既存Webシステムの機能やデータ活用による新サービス提供

システム開発効率の向上

課題

Web APIのインタフェースやフォーマットの統一

Web APIの学習コストの削減



マッシュアップの分類

presentation マッシュアップ

data マッシュアップ

logic マッシュアップ

T

J

U

T

U

I

S

T

U

I

S

presentation マッシュアップ



概要

Webページ内に1つ以上のWebシステムのコンテンツ

をまとめて表示すること

実現方法

各サービスが提供するスクリプトの埋め込み

具体例

Twitterウィジェット

Facebookソーシャルプラグイン

ブログパーツ

data マッシュアップ



概要

複数のWebシステムからデータを取得し結合すること

実現方法

Web API（多くが地図API）を使ってデータを重ねあわせて表示

多くが地図ベースのマッシュアップとして実現

具体例

気象情報サービス

災害情報マップ

お祭りの山車位置共有サービス

お祭りの出店マップ

T

J

U

T

U

I

S

T

U

I

S

logic マッシュアップ



概要

複数のWeb APIの入出力処理を連結させること

実現方法

あるAPIの出力結果を別のAPIの入力に与えて処理する

高度なプログラミング知識が必要となる

具体例

到着地の住所から経路探索

※実際は開発者しか知らない

Web APIの活用



ソーシャル連携サービス

Twitter、FacebookのIDによる認証機能

Twitter、Facebookでのつながり情報、登録情報の活用



Web APIの利用

プログラムから外部Webシステムの機能を利用する

関数群

プログラム

例：ブログ

DB

A

P

I

① 問い合わせ

② データ処理

③ 返信

インターネット

図. Web APIの仕組み

D

D

Webシステム

T

J

U

T

U

I

S

T

U

I

S

ソーシャルアカウントでのログイン



Tripline：旅の軌跡を記録するサービス

スピーディーな開発の事例

地図

認証

旅の軌跡

シェア

マッシュアップ

による開発速度＆利便性向上

T

J

U

T

U

I

S

T

U

I

S

CMS（Content Management System）



CMSとは

Webの専門知識がなくても、Webサイト管理ができる

一般利用者でもWebサイト運用が可能

コンテンツとレイアウトの分離

ライターとデザイナーの分業が容易



代表的なCMS

WordPress：ブログ、Webサイトとして広く利用

Movable Type：企業のWebサイトとして利用

OpenPNE：mixi同様のSNSを構築可

NetCommons：eラーニングサイトに利用

Joomla!：高機能なCMS、サイト全体のデザイン統一

WordPressのインストール画面

T

J

U

T

U

I

S

T

U

I

S

WordPressで作成したサイト

Joomla!によるWebサイト作成例

T

J

U

T

U

I

S

T

U

I

S

Joomla!の管理画面



コンテンツとテンプレートを分けて管理可能



記事やメニュー、画像の登録・編集が可能

27

記事の一覧

Web開発技術の基本



Web開発での必須スキル

HTML/CSSは基本中の基本

Webの仕組み：HTTP、GET/POST

クライアントサイド：ブラウザ、JavaScript、jQuery

サーバサイド：PHP、Ruby、Servlet、DB

サーバ運用：Linux、Apache、ネットワーク



学び方は実践あるのみ！

まずはWeb開発の全体的な知識を得る

実際に開発をしながら、自分の得意分野を見つける

T

J

U

T

U

I

S

T

U

I

S

Webシステムの基本設計



基本設計

機能設計、データ構造は前回の講義を参照

機能設計：要件定義を満たす機能の洗い出し

データ構造：機能を実現するために記録すべきデータの整理

画面設計図

機能毎に必要な画面とその構成を図示する

各画面の入力フォームの内容、ボタンの配置など

ボタン操作時の処理や画面遷移はまだやらなくてよい

レポート課題



学生生活で利用できるWebシステムの基本設計書

システムの機能とデータ構造

データの登録・表示・更新・削除ができること（CRUD）

ログイン機能があると尚良（要セッション管理）

画面設計図

データの登録・表示・更新・削除に対応した画面設計を行うこと

データの種類毎の一覧表示、新規登録、編集画面があるはず

削除はボタン操作のみでOK（入力情報がないため）

T

J

U

T

U

I

S

T

U

I

S

レポート作成例：基本設計（1）



機能

ログイン機能

ユーザのID、パスワードでログイン

ユーザ管理機能

ユーザの追加・更新・削除が可能

ユーザ毎に権限を付与し、利用できる機能を制限

蔵書登録機能

書籍の追加・更新・削除が可能

書籍のタイトル、カテゴリ、出版社、発行年などを管理

条件を指定した蔵書検索が可能

貸し出し機能

ユーザへの書籍貸し出しを台帳に記録

ユーザへの貸し出し冊数の上限と期限を設ける

レポート作成例：基本設計（2）



データ構造

ユーザ情報

ユーザID、パスワード、名前、権限（管理者 or 利用者）

ユーザ情報を変更できるのは管理者のみ

蔵書情報

書籍のタイトル、カテゴリ、出版社、発行年

貸出台帳

書籍と貸し出したユーザの紐付け

貸出日、返却予定日、貸出状態（貸出OK or 貸出中）

T

J

U

T

U

I

S

T

U

I

S

レポート作成例：基本設計（3）



画面設計図：蔵書リスト画面

書籍の新規登録

各レコードの操作が可能

書籍リストを表形式で表示

※図作成には、リアルタイムコラボレーションツール「

Cacoo

」を利用

レポート作成例：基本設計（4）



画面設計図：蔵書 新規登録画面

すべての項目を入力し、「登録」ボタンで登録可

タイトル、出版社：テキストボックス

カテゴリ、発行年：選択ボックス

T

J

U

T

U

I

S

T

U

I

S

レポート作成例：基本設計（5）



画面設計図：蔵書貸出画面

「貸出可」より蔵書の貸出が可能

「貸出書籍」より自分の書籍貸出状況を確認可

貸出操作が可能

リレーショナルデータベースの復習



用語

スキーマ（schema）：DBの構造を定義したもの

表（テーブル、table）：リレーションともよぶ

行（レコード、row）：1件のデータのこと

列（フィールド、column）：各項目のこと

T

J

U

T

U

I

S

T

U

I

S

関係モデルと関係データベース



関係モデル



例：「商品」を「輸出先」に”売る”という関係



関係モデルの考え方を使って関係データベースを設計

データベース設計の手順

1.

データとその関連（ER）を分析する

2.

表を作る

3.

表を正規化する



第一正規形



第二正規形



第三正規形

T

J

U

T

U

I

S

T

U

I

S

データとその関連（ER）の分析



ERモデル

現実世界を

Entity（実体）

と

Relationship（関連）

に概念化

現状の世界からにEntity（実体）をとらえる

例：商品（商品コード、商品名、単価）

例：輸出先（輸出先コード、輸出先名）

実体同士のRelationship（関連）について考える

例：売上

ERモデル



Entity

（実体）と

Relationship

（関連）

・多数の商品が多数の輸出先

に売られる

・多数の輸出先は多数の商品

を買っている

多対多

の関係

※商品がひとつの場合、

1対多

の関係となる

※商品ひとつ輸出先ひとつの場合、

1対1

の関係となる

T

J

U

T

U

I

S

T

U

I

S

ER図



ERモデルをよりデータベース設計に近い形で図式化



様々な書き方がある

データベース設計の手順

1.

データとその関連（ER）を分析する

2.

表を作る

3.

表を正規化する



第一正規形



第二正規形



第三正規形

T

J

U

T

U

I

S

T

U

I

S

表の作成



売上報告書から表を作成してみる

非正規形



繰り返し項目が排除されていない表



リレーショナルデータベースでは、

非正規形の表はうまく処理できない

T

J

U

T

U

I

S

T

U

I

S

データベース設計の手順

1.

データとその関連（ER）を分析する

2.

表を作る

3.

表を正規化する



第一正規形



第二正規形



第三正規形

正規化



現実世界のデータをリレーショナルデータベース

の表に落とし込む作業



1行に1つの値が入る表の形にする



非正規形の表をデータの矛盾が発生しないよう

複数の表に分割する

T

J

U

T

U

I

S

T

U

I

S

第一正規形を作る



1行に1つの値が入るように表を分割する

第一正規形の表まとめ



第一正規形

表を2次元の単純な表としたもの

1行に１つの値が入るようにした表



「売上明細」（第一正規形②）の問題点

商品に関するデータと売上に関するデータが混在

新しい商品でまだ売っていない商品は追加できない

T

J

U

T

U

I

S

T

U

I

S

第二正規形を作る（2）



「売上明細」（第一正規形②）を分割する

第二正規形を作る（3）



主キー

によって他の列の値がきまる

「商品」表は、「商品コード」列の値が決まると

「商品名」と「単価」の値が決まる

「売上明細」表は、「報告書コード」列と

「商品コード」列の値が決まると「個数」の値が決まる

T

J

U

T

U

I

S

T

U

I

S

第二正規形



主キーによって他の列の値が決まるようにした表



関数従属

「ある列の値によって他の列の値が決まる」こと



主キーに他の列が関数従属するように表を分割する

第二正規形の表まとめ



「売上」（第一正規形①）はそのままで第二正規形



主キーの「報告書コード」が決まると他の値が決まる

T

J

U

T

U

I

S

T

U

I

S

第三正規形を作る（1）



「売上」（第二正規形③）の問題点

「売上」表には、輸出先に関するデータと売上に関する

データが混在

一度も輸出していないが輸出先には存在するイタリア

を管理できない！

第三正規形を作る（2）



「売上」表（第二正規形③）を分割する

T

J

U

T

U

I

S

T

U

I

S

第三正規形



各項目の値が、主キーのみで決まる表



推移従属している

「ある列の値によって間接的に他の列の値が決まる」こと



第三正規形では、推移従属を除くように表を分割

第三正規形（補足）



「売上」表（第二正規形③）では



「報告書コード」が決まれば、「輸出先コード」が決まり、

それにより間接的に「輸出先名」が決まっていた

T

J

U

T

U

I

S

T

U

I

S

第三正規形にまでにした表



リレーショナルデータベースではこの表を使う