...

処理単位 “CELL” を導入した コンテンツ管理システム

by user

on
Category: Documents
6

views

Report

Comments

Transcript

処理単位 “CELL” を導入した コンテンツ管理システム
平成 16 年度
フロンティアプロジェクト
処理単位 “CELL” を導入した
コンテンツ管理システム openGATE
openGATE: A Proposal of Content Management
System which Introduced a Processing Unit “CELL”
050297
石井
勇太
指導教員
清水
明宏
2005 年 3 月 16 日
高知工科大学 フロンティア工学コース
要 旨
処理単位 “CELL” を導入した
コンテンツ管理システム openGATE
石井
勇太
要旨インターネット上で流通する文書や画像, Web サービス等, コンテンツの情報量は急
激に増加してきており, それらを効率的に制作, 管理及び流通させるコンテンツ管理システ
ムの重要性が, 企業や組織を中心に高まってきている. 従来システムには, プロバイダ毎に変
化するコンテンツ形態に柔軟に対応できず, またその操作が情報リテラシのみでは難しい等
の問題があった. そこで本研究では, 小規模なコンテンツを “CELL” と呼ぶ処理単位で管理
し, それらを複数組み合わせることで, プロバイダ, ユーザ双方が持つ様々なニーズに対応し
たコンテンツを創り出す手法を導入した CMS, openGATE を提案する.
キーワード
コンテンツ管理, ウェブ, ユーザビリティ, ウェブアクセシビリティ
–i–
Abstract
openGATE: A Proposal of Content Management System
which Introduced a Processing Unit “CELL”
Yuta ISHII
In recent years, it follows on advance of computerization in society; web content is
increasing explosively, which has been gaining in the importance of the content management on the Internet. Conventional systems have problems which can’t deal with
various contents to change every content provider flexibility and operation method is
difficult only in their computer literacy. In this paper, CMS “openGATE”, which aims
at solution of the above problems by introducing a processing unit “CELL”, is proposed.
key words
Content Management, Web, Usability, Web Accessibility
– ii –
目次
第1章
はじめに
1
1.1
研究の背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
本論文の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
コンテンツ管理システム
4
2.1
CMS の定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
従来システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
第2章
2.3
第3章
3.1
3.2
2.2.1
blog (Weblog) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.2
Wiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.3
xoops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
CMS が解決すべき課題 . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
システム概要
10
概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.1
開発言語と動作環境 . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.2
コンテンツの定義 . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.3
プレイヤの定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
アナライザ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
データ交換ユニット . . . . . . . . . . . . . . . . . . . . . . . . . .
15
同期ユニット
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
統合ユニット
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
シンセサイザ
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
コントローラ
– iii –
目次
3.2.2
第4章
4.1
第5章
CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
CELL の組み合わせ機能 . . . . . . . . . . . . . . . . . . . . . . .
22
導入事例
23
概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.1.1
Web サイト構築での CELL の活用 . . . . . . . . . . . . . . . . .
23
4.1.2
Web サイト運営での CELL の活用 . . . . . . . . . . . . . . . . .
25
評価実験
28
5.1
評価概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.2
実験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.3
考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
おわりに
31
第6章
6.1
評価に関する課題
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
6.2
ウェブアクセシビリティに関する取り組み . . . . . . . . . . . . . . . . .
32
6.3
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
謝辞
33
参考文献
34
– iv –
図目次
1.1
日本におけるインターネット上に流通するコンテンツ量の推移 . . . . . . .
2
2.1
blog (Weblog) の外観 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2
Wiki の外観 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
xoops の外観 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1
openGATE 内部構造の概略図 . . . . . . . . . . . . . . . . . . . . . . . .
10
3.2
openGATE のアーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . .
13
3.3
openGATE における URI パラメータ表記規則 . . . . . . . . . . . . . . .
14
3.4
Trigger CELL の役割 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.5
データ交換ユニットとデータベース構造 . . . . . . . . . . . . . . . . . . .
16
3.6
openGATE 内での同期ユニットの動作 . . . . . . . . . . . . . . . . . . . .
17
3.7
openGATE 内での統合ユニットの動作 . . . . . . . . . . . . . . . . . . . .
18
3.8
CELL スケジューリングの概略図 . . . . . . . . . . . . . . . . . . . . . . .
19
3.9
シンセサイザの概略図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.10 CELL におけるレセプタのコーディング例 . . . . . . . . . . . . . . . . . .
21
4.1
四万十農業協同組合・地域振興班の Web サイト概観 . . . . . . . . . . . . .
24
4.2
CELL の組み合わせ関係と制作した Web ページの外観 . . . . . . . . . . .
25
4.3
DataScope の外観 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.4
EzScope の外観 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
–v–
表目次
5.1
ソフトウェア評価尺度による従来方式との比較 . . . . . . . . . . . . . . . .
– vi –
29
第1章
はじめに
1.1
研究の背景
World Wide Web (以下, Web) は, 1989 年 4 月に Tim Berners-Lee 氏により, 研究者
間の知識共有スペースとして提案されたものである [2]. この Web により, Theodor Holm
Nelson 氏により提唱されたハイパーテキストの概念が実装されることで, 世界中のあらゆ
る知識や情報をリンクし, 共有することのできる技術的基盤が実現した.
この文書システムは, 当初の目的であった研究機関のような組織における知識や情報の共
有手段としてだけでなく, 不特定多数に向けた情報配信手段としても効果的であるために,
その利用層は研究者等の限られた人々から, 官公庁や企業, 組織, そして一般市民へと拡がり
をみせ, 電子メールとともにインターネットの代名詞的な存在となった.
現在では, インターネットはその利用者が, 我が国では約 6,284 万人, 世界においては約
80,140 万人に達するほど普及し [5], 人々の社会活動に欠かせないものとなっている. そし
て, その増加に比例して, インターネット上の Web コンテンツの流通量も増加し続けており
(図 1.1), インターネット上には Web コンテンツが蓄積され続けている.
このように, インターネットの重要性が増していく一方で, Web の根幹であるハイパーテ
キストの “索引が存在しない” という特徴が, Web を利用するユーザ側には, 莫大な Web
サイト/ページの中から, どのように必要なコンテンツに辿りつくのかという課題を与えた.
そして Web コンテンツを配信するプロバイダ側にも, 蓄積され続けるコンテンツをいかに
効率的に管理し, ユーザ側に対して配信していくのかという課題を生じさせてきた.
前者は, Web サイトを扱っているコンテンツの種類により分類し, Web 全体を対象にした
–1–
1.1 研究の背景
図 1.1
日本におけるインターネット上に流通するコンテンツ量の推移
ハイパーテキストによる索引を提供するディレクトリサービスと, Web サイトを定期的に巡
回し, 収集したデータと, ユーザの入力したキーワードとの統計的比較を行い, その適合度順
に複数の Web サイトを提示するロボット型検索エンジンが登場により, 一定の問題解決を
図ることができた.
一方で後者は現在, 蓄積された Web コンテンツを効率的に管理, 配信することがで
き, またその前段階である制作までも担えるような コンテンツ管理システム (Content
Management System, 以下 CMS) を構築, 利用することによって, 問題解決が図れようと
している.
しかし, CMS は利用する企業や組織, ユーザによって管理する Web コンテンツが異なる
ため, 内情に合わせて独自のシステムを構築, 運用するケースが多く, 多額の構築及び管理コ
ストが生じてしまう問題がある. CMS の中には無償で公開されているものも存在するが, 利
用用途が限られている等, 改善すべき課題を持っている.
そこで我々は CMS について, 本来の目的であるコンテンツの制作, 管理, 及び配信の効率
化を達成しつつ, 従来の CMS を用いた情報配信における課題を解決することを目標に, そ
の研究を進めてきた.
本論文では, 我々が提案する独自の CMS, openGATE の技術的解説を処理単位 CELL を
–2–
1.2 本論文の概要
中心に行っていく. また, その有益性を実証するための評価実験についても併せて解説し, 最
後に今後の課題を述べる.
1.2
本論文の概要
第 2 章では, CMS について, 従来のシステムの概要とその特徴について解説し, そこから
openGATE で解決すべき課題を挙げる.
第 3 章では, openGATE の中核となるコントローラと処理単位 CELL の構造と処理を中
心に技術的解説を行っていく.
第 4 章では, 四万十農業協同組合 (JA しまんと)・地域振興班で openGATE を導入し, 実
際に Web サイトを構築した事例を紹介し, そこで行われた CMS の持つ課題に対する解決
アプローチを解説する.
第 5 章では, ソフトウェア評価尺度を用いた定量的評価の結果を示し, その考察を行う.
そして最後, 第 6 章では, 研究の過程で生じてきた今後の課題について述べる.
–3–
第2章
コンテンツ管理システム
2.1
CMS の定義
CMS とは本来, Web コンテンツを効率よく管理するための構築されたシステムを指す.
しかし近年では, コンテンツ自体の制作から管理, そしてユーザへの配信までの操作を一貫
して行うことのできるシステムを指す事が多い.
しかし, CMS がどのようなソフトウェアを指すのかについては, その管理対象であるコ
ンテンツをどう定義するかによって異なってくる. 例えば CMS として, 第 2.2.1 節 で解
説する blog (Weblog) のように記事という単一のコンテンツを扱うものが分類される一方,
Yahoo!∗1 のような Web サイトの検索サービスと各種情報が提供されている Web ポータ
ルサイトも同じように分類される場合がある. その他に運用形態でも, オンラインで Web
サービスとして動作するものの他に, オフラインでサーバアプリケーションとして動作する
ものも含まれることがある.
2.2
従来システム
前節で示したように, CMS の定義には曖昧な部分も多く, 特定の用途や業種などにしか利
用できないものも含めると数多く存在する. 本節では, 誰もが自由に無償で入手でき, 認知度
が高い 3 種類の CMS について, その機能や用途等を解説していく.
∗1
ヤフー株式会社, URI: http://www.yahoo.co.jp/
–4–
2.2 従来システム
2.2.1
blog (Weblog)
blog (Weblog) とは, 一般的に見出しと記事で構成されたコンテンツを Web ブラウザ上
で編集し, それらを時系列で管理, ユーザに配信するシステムである. 代表的な blog シス
テムとしては Movable Type∗2 や Blogger∗3 が存在するが, blog 自体の定義に明確なもの
はなく, Web 上に存在する興味深いコンテンツに対しハイパーリンクを設定し, それに評論
を付けた記事扱うサイトの総称とされている. また近年では, それら blog システムの中で
も Trackback と呼ばれる参照先/参照元表示機能や, RSS (RDF Site Summary) によるサ
イト更新情報の配信機能等の外部との連係機能を有したものが主流となっている. これは,
blog が誕生した米国において, インターネットを新たな情報配信 (Publishing) メディアと
して活用するための試みの中で生まれたことに起因する [3][6][7] .
一方我が国において, blog の認知度が高まったのは 2003 年末, 国内大手のインターネッ
トプロバイダが顧客ユーザ向けの blog サービスを開始してからである. その後, 他のイン
ターネットプロバイダや Web ポータルサイトなども追随し, 利用者の増加が続いている. そ
れらのサービスは, XML-RPC∗4 技術を用いて使いやすいものにし, また CSS (Cascading
Style Sheets) を用いたデザインテンプレートも, 独自のものを提供した. これにより blog
は, 米国のような積極的な情報配信ツールとしてよりも, HTML 等のマークアップ言語の
知識が無い一般ユーザにも, 手軽に更新できるデザイン性の高い日記やホームページの制作
ツールとしてユーザから評価を受けることになった.
現在 blog は, 個人用途だけでなく, 自治体や非営利組織, グループ等による情報発信, 企
業内での情報共有, Web サイトの管理コスト軽減等を目的に, 幅広い組織や分野で blog の
採用が増加している. しかし, 扱うことができるコンテンツが見出しと記事で構成されたも
のに限られるため, プロバイダ毎に異なる CMS に求めるニーズを満たすのは難しいという
問題点がある.
∗2
シックスアパート株式会社, URI: http://www.movabletype.jp/
∗3
グーグル株式会社, URI: http://www.blogger.com/
∗4
UserLand Software 社, URI: http://www.xmlrpc.com/
–5–
2.2 従来システム
図 2.1 blog (Weblog) の外観
2.2.2
Wiki
Wiki とは, 誰もが自由に文書コンテンツを作成, 編集ができるシステムである. 一般に,
本論文で用いた CMS の他, コラボレーションツールやコンテンツサーバ等と称されている.
1994 年に Ward Cunninham 氏がサーバサイドスクリプト言語 Perl で制作した約 350 行
のプログラム “Wiki Wiki Web∗5 ” から始まり, その後は機能の改良・拡張や Perl 以外の各
言語に対応したものが Wiki clone (以下, Wiki に Wiki clone を含める) として公開されて
きた.
この Wiki の大規模な活用例として, Wikipedia∗6 (ウィキペディア) を紹介する (図 2.2).
Wikipedia は, 有志の手により編纂されている Web 百科事典であり, その日本語版には
2005 年 2 月現在, 約 10 万件も項目が投稿されている.
この Wikipedia の例のように, 有志による作業が必要な活動や, コンテンツが章や節等の
文書構造を持つ場合, そしてコンテンツ同士の参照が必要な場合に Wiki 採用の効果は高い.
しかし, 閲覧するだけであれば, 通常の Web サイトと操作は変わらないものの, Wiki の特
徴である自由な編集機能を利用し, コンテンツ制作を行うためには, Wiki 独自のタグ等の理
∗5
URI: http://www.c2.com/cgi/wiki?WikiWikiWeb
∗6
ウィキメディア財団, URI: http://ja.wikipedia.org/
–6–
2.2 従来システム
解等, 情報リテラシ以上の技術的知識が必要となってくる.
また, Wiki がコンテンツを自由に編集できることに起因する, 悪意あるユーザによる記事
の破壊的行為も度々発生している. この場合, Wiki では IP アドレスによるアクセス制限,
履歴機能による復旧, 編集機能の凍結などの対策が講じられるが, ユーザ認証が基本となる
システムと比較すると, 高い管理コストが必要となる. そうした問題の対策のために, Wiki
の中にはユーザ認証機能を付加したものが登場してきている.
図 2.2 Wiki の外観
2.2.3
xoops
xoops (eXtendible Object Oriented Portal System) とは, 様々な機能をモジュールとし
て独立して提供, 追加が可能な, 拡張性の高い CMS である. 一般には CMS の他, 略称にあ
るようにポータルシステムや, コミュニティサイト構築ツールと称されることもある.
また, システム自体は柔軟な言語仕様とデータベースとの高い親和性を持つ, サーバサイ
ドスクリプト言語 PHP によって開発されており, PHP による Web サービス開発のための
フレームワークという側面も持ち合わせている. 実際, 先に挙げた blog や wiki で提供され
る機能も, xoops のモジュールとして実装されている例がある.
このように xoops は, プログラム可能なモジュールによる拡張機能により, 幅広いユーザ
–7–
2.3 CMS が解決すべき課題
ニーズに対応できるため, CMS としてとても高い性能を持っている. それを裏付けるよう
に, 図 2.3 左部の高知県庁 Web サイトのように, 地方自治体や非営利団体等での採用の例も
数多くある.
しかし, それら高い拡張性の反動として, 操作や管理が複雑になりやすい. そのため, 管理
者には情報リテラシ以上の知識が求められることもあり, 一般ユーザには扱いにくい部分も
多い.
図 2.3 xoops の外観
2.3
CMS が解決すべき課題
本章では, 誰もが自由に無償で入手でき, 認知度が高いと思われる 3 種類の CMS につい
て解説してきた. その中で幾つかの利点と問題点を挙げてきたが, それらを集約すると以下
のように今後必要とされる CMS の要件を導き出す事ができる.
• プロバイダ毎に変化する Web コンテンツの種類に対応できるシステム (汎用性の実現)
• 公開性を確保しながら, 適切なアクセス制御の行うことのできるシステム (セキュリティ
の確保)
• 情報リテラシのみで簡単に管理操作できるシステム (ユーザビリティの向上)
–8–
2.3 CMS が解決すべき課題
今後も蓄積され続ける Web コンテンツと, それらを必要とするユーザに対応するために,
CMS にはそれぞれの持つ利点は維持しつつ, 上記のような課題を解決されることが要求さ
れる.
そこで, 我々はそれらの要件を満たすため, 新たな処理単位 CELL によるコンテンツ管理
手法を提案し, 実装した CMS である openGATE を提案した [1]. 次章以降では, 処理単位
CELL の導入によって, 先に挙げた課題をどのように解決していけるのかを技術面から解説
する.
–9–
第3章
システム概要
3.1
概要
openGATE は, 内部は全体を制御するコントローラと, システム内で取り扱う機能や,
データを管理する処理単位 CELL とで構成され, コントローラが CELL を操作することで,
Web ブラウザから要求されたコンテンツを提供する CMS である. コントローラは 図 3.1
のように, Web ブラウザからコンテンツ配信の要求を受けて, 必要な CELL を順次呼び出
していく.
2. Call
1. Request
Web
CELL
Controller
Browser
3. Return
4. Reply
図 3.1
openGATE 内部構造の概略図
第 ?? 節で示した通り, CMS はコンテンツ管理を効率的に行うためのシステムである.
openGATE では, コンテンツの拡張性と再利用性に実現することによる, 効率化を目指して
いる. そのためのアプローチが, 処理単位 CELL によるコンテンツの提供である.
この CELL と似た機構に, 第 2.2.3 節 で解説した xoops で採用されているモジュールを
挙げることができる. モジュールでは多くの場合, それ一つで, 一つの Web サービスを提供
する. 一方 CELL は, Web サービスをさらに細かく分け, 単一機能やデータ単位で管理する
– 10 –
3.1 概要
ことで, 拡張性と再利用性を高めている.
CELL を制御するコントローラ側も, CELL の拡張性と再利用性を活かすため, CELL の
制御と, 開発及び運用支援のため機能以外は, 最低限しか実装されていない. 標準のコンテン
ツ管理ツールも CELL で構築し提供することで, その仕様変更も可能にし, ユーザの実情に
合わせた CMS を基礎レベルで支援している.
このような Web コンテンツの実装手法は, 同じサーバサイドスクリプト言語 PHP を用
いている xoops においても再現できるが, openGATE はシステムとして, それを支援する
ための機構をコントローラと CELL に内蔵している点で大きく異なっている.
3.1.1
開発言語と動作環境
プログラム自体は, 先に説明したサーバサイドスクリプト言語 PHP で開発されてい
る. またデータベース処理の実装には, PEAR∗1 ::DB ライブラリを用いており, mySQL や
PostgreSQL 等の幅広いデータベース環境に対応する.
このような動作環境は, 安価なホスティングサービスでも標準サービスとして提供されて
おり, 初期投資が必要な独自サーバを整備しなくても, 低コストで運用を始めることができ
るため, 情報システムに十分投資ができない中小企業や非営利団体等でも導入しやすい.
3.1.2
コンテンツの定義
本システムにおけるコンテンツとは, 文書や画像, Web サービス等を指す. それら小規模
なコンテンツを CELL 内で管理し, 複数 CELL を組み合わせることで, 様々なニーズや規
模に対応したコンテンツの提供を実現するという手法を取っている.
従来の CMS は, プロバイダ側が利用する管理機能等もシステムとして内含し, ユーザ側
に提供するものをコンテンツとする場合が多かった. しかし, 本システムでは双方とも同じ
ように, Web ブラウザを通して殆どの機能やデータをコンテンツとして, つまり CELL で
∗1
PHP 標準のオープンソースクラスライブラリ, URI: http://pear.php.net/manual/ja/
– 11 –
3.2 構成
提供している. プロバイダ側とユーザ側を分けるのは, CELL 毎, データ毎に設定可能なア
クセス権限である.
プレイヤの定義
3.1.3
本論文では, 前節で示したコンテンツの定義に沿って, 提案するシステムに関わる組織及
び人物 (以下, プレイヤ) を, 以下のように定義している.
■システムプロバイダ
インターネットに接続されたサーバマシンに, HTTP や FTP など
の各種サービスや PHP, データベース等の openGATE が動作するために必要な環境の構
築及び設定を行い, コンテンツプロバイダに対して, コンテンツ管理が可能な環境を提供す
るプレイヤ.
■コンテンツプロバイダ
Web ブラウザを通して, openGATE で主にコンテンツの制作と
管理を行い, ユーザに対して配信するプレイヤ. CELL やデータの管理や, そのアクセス制
御, データ権限を持ち, openGATE を全体を管理する立場にある. システムプロバイダとは
役割は異なるが, 状況によっては兼ねる場合もある.
■ユーザ
Web ブラウザを通して, openGATE から主にコンテンツの配信を受けるプレイ
ヤ. 簡単なコンテンツ制作, 管理を行う場合もあるが, その権限がコンテンツプロバイダから
与えられることが前提となる.
3.2
構成
本システム, 図 3.1 で示す通り, コントローラと CELL により構成されている. それらは,
図 3.2 のように, さらに機能別のユニットにより構成されており, それらが密接に連携する
ことで効率的なコンテンツ管理を可能にしている. 本節では, コントローラ及び CELL にそ
れぞれ搭載されている機能ユニットについて解説していく.
– 12 –
3.2 構成
openGATE
Browser
(user side)
Controller
CELL
Database
Analyzer
Logic
Synthesizer
(internal)
Exchange
Unit
Synchronous
Synchronous
Unit
Unit
(master)
(slave)
Combining
Unit
Combining
Unit
Receptor
(master)
(slave)
data flow
図 3.2 openGATE のアーキテクチャ
3.2.1
コントローラ
コントローラは, コンテンツプロバイダやユーザが利用する Web ブラウザからの要求を
解析し, その要求に応じるために必要な CELL の呼び出し, 最後に CELL の処理結果を統
合するという役割を持つ. これらの機能を実現させるために, コントローラには以下に示す
5 種類の部品が内蔵されている.
• アナライザ (Analyzer)
• シンセサイザ (Synthesizer)
• データ交換ユニット (Exchange Unit)
• 同期ユニット (Synchronous Unit)
• 統合ユニット (Combining Unit)
これらのユニットについては次節以降でそれぞれ解説する. その他にコントローラには,
接続 IP アドレス制御, アクセスログ設定, セッション構築, ユーザ認証といったシステム運
営を円滑にし, CELL の開発負担を軽減させる機能も内蔵している.
– 13 –
3.2 構成
アナライザ
アナライザは, Web ブラウザからの要求及び閲覧環境を解析し, 応答するコンテンツを得
るために必要な CELL を呼び出す役割を持つ.
図 3.3 に, openGATE における URI パラメータ表記規則を示す. アナライザは, この規
則に従って URI を解析し, コンテンツプロバイダやユーザが Web ブラウザを介して, どの
ようなコンテンツを要求しているのかを解析し, 必要な CELL の呼び出しを行う.
http://www.example.com/? TriggerCELL & action=test & id=test & name=param
openGATE Installed URI
図 3.3
Trigger CELL
Action's parameter
ID's parameter
Free Area
openGATE における URI パラメータ表記規則
この URI パラメータからは, 分解によって, さらに Trigger CELL, アクション, データ
ID という定義されたパラメータ, そして自由領域に定義されたその他のパラメータを得る
ことができる.
Trigger CELL は, Web ブラウザから指定される CELL である. このパラメータには, シ
ステム内に存在する CELL 全てに対し, 重複しないよう割り当てられた文字列 CELL コー
ド が指定される. Web ブラウザが URI パラメータを介して, 呼び出すことの可能な CELL
は Trigger CELL だけである. よって 図 3.4 ように, Trigger CELL は, コンテンツの構築
のために必要な他の CELL の呼び出しを定義する必要がある.
この Trigger CELL 内でどのような機能やデータを持つ CELL を呼び出す必要がある
のかを判断する材料が, アクションとデータ ID の両パラメータである. アクションには,
Trigger CELL が示すコンテンツに対して, どのような操作を行う必要があるのかが指定さ
れる. データ ID には, コンテンツを構築するために, どのデータが必要なのかを明確に表現
する数値が指定される. アナライザから呼び出された Trigger CELL は, これらのパラメー
タに加えて, 自由領域に定義された独自のパラメータを用い, 内部で必要な CELL の呼び出
しを行っていく.
– 14 –
3.2 構成
このように, Trigger CELL がコンテンツを構築するために呼び出される複数の CELL を
抽象化する役割を担うことにより, 複雑になりがちな CELL の機構を隠蔽し, コンテンツプ
ロバイダやユーザが意識せずとも, 管理や利用をすることが可能になる. また, 隠蔽により外
部への露呈部を最小限に留めることは, セキュリティ性を確保するためにも有益であると言
える.
required content
C.3
C.2
C.4
C.1
Call
Trigger
Controller
C.5
CELL
C.6
Return
C.9
C.7
C.8
C.10
C.X
This CELL is called "X"thly.
図 3.4 Trigger CELL の役割
データ交換ユニット
データ交換ユニットは, システム内のコントローラや CELL 等が使用するデータを格納
するデータベースの操作を担当しており, その中には, データを特定ユーザにのみアクセス
可能な状態にすることができるアクセス権限機能等のデータ管理のための操作も含まれて
いる.
各 CELL の保持するコンテンツデータは, データベース内では図 3.5 で示すように, デー
タの索引を担当する index, データへのアクセス権限を担当する permission, データの構造
を担当する structure, データ本体を担当する data の計 4 テーブルで構成されている.
データ交換ユニットは, コントローラや各 CELL からデータ操作のための呼び出しを受
– 15 –
3.2 構成
CELL
returns
calls
Data_Handler
generates
Exchange
Unit
control
CELL_index
CELL_permission
CELL_structure
id
id
field
name
target_id
name
note
target_type
type
owner
p_read
note
time_create
p_write
time_access
p_execute
CELL_data
(defined by
CELL_structure)
Database
図 3.5
データ交換ユニットとデータベース構造
けると, 以下のような手順でデータベース操作を行う.
1. index テーブルの情報により, 指定されたデータの存在を確認しする
2. permission テーブルの情報により, 指定されたデータに対するアクセス権限が存在する
かを確認する
3. structure テーブルの情報から, データ構造を抽出する
4. data テーブルから, 指定条件に従い, データ抽出を行う
4 の操作までが完了すると, データ交換ユニットはデータ操作用クラス Data Handler を
インスタンス化し, それを CELL に対して返す. CELL 内のデータ処理は, そのインスタン
スに格納されたデータに対して操作を加えていく. データ交換ユニットは, そのインスタン
スが戻ってきた場合に, 操作によるデータの差分をデータベースへと反映させる.
CELL が様々なコンテンツを取り扱うためには, その元になるデータも柔軟に定義, 運用
できる環境が必要になる. 本システムでは, 上記のような 4 テーブルによるデータベース構
成を採用することで, CELL のデータ定義の自由性を維持しつつ, セキュリティ性を高める
ためのアクセス権限機能を提供している.
しかし, このようなデータベース構成では, 操作が複雑になり, 効率化の妨げになってしま
– 16 –
3.2 構成
う場合がある. そこで, Data Handler によりデータ操作機能を提供することで, データベー
ス構造を抽象化し, コーディングに関する作業負担軽減の役割を果たしている.
同期ユニット
同期ユニットは, 複数の Web サービスが openGATE 内で提供する上で, 重要度の高い
データを, システム全体で効率的に共有, 管理するための機構を有したユニットである. ま
た, 共有されるデータを 同期パラメータ と呼ぶ.
図 3.6 に, openGATE 内での同期ユニットの動作の概略を示す. 本ユニットは, openGATE
を構成するコントローラと CELL の双方に存在するが, その役割は異なる. コントローラ側
は, 同期パラメータの管理を担当し, 内部で区別するために Master と呼ぶ. 一方, CELL 側
は Master 経由で同期パラメータを取得, 設定する等の利用側で, Slave と呼ぶ.
Controller
CELL:A
Analyzer
Web
Browser
Synthesizer
CELL:C
Exchange
Unit
CELL:B
Synchronous Unit
Combining Unit
Database
図 3.6 openGATE 内での同期ユニットの動作
本ユニットを利用するためには, コントローラが提供するセッション構築機能を用いる.
セッションを確立すれば, その有効期限内はユニット内で同期パラメータを保持し続けるこ
とができる.
また, 併せてユーザ認証が完了している場合には, 同期パラメータをセッションの有効期
限が切れても, 保持し続けることのできる機能が付与される. この場合, 一度セッションを破
棄しても, 再度セッションを確立した時に, データベースに保存している同期パラメータが
– 17 –
3.2 構成
復元される. 復元が必要ない場合, 同期パラメータ毎にそのような設定も可能である.
また, シンセサイザにおいて, CELL の統合作業時に利用しているプロファイルも本ユ
ニットを通して提供される. プロファイルは, ユーザ認証時に Web ブラウザ固有のレタリン
グ特性に関する調整データと, データベースからユーザ独自の設定データが読み込まれ, そ
れらは同期パラメータとして提供される.
統合ユニット
統合ユニットは, シンセサイザで行う統合作業のために, Web ブラウザからの要求に沿っ
て呼び出した複数の CELL の行う 組み合わせ により生じる親子関係を登録し, それを管理
する役割を持ったユニットである. 図 3.7 に, openGATE 内での統合ユニットの動作の概略
を示す.
Controller
CELL:A
Analyzer
Web
Browser
Synthesizer
CELL:C
Exchange
Unit
CELL:B
Synchronous Unit
Combining Unit
Database
図 3.7 openGATE 内での統合ユニットの動作
アナライザから呼び出された Trigger CELL は, Web ブラウザが要求するコンテンツを
構築するために, 必要なコンテンツを管理する CELL を呼び出していく. また, 呼び出され
た CELL も, 必要に応じてさらに CELL を呼び出すことができる. このように, Web ブラ
ウザから要求に沿ってコンテンツを構築する際, 数多くの CELL が必要となる.
統合ユニットは, どの CELL が呼び出され, どのような順番で組み合わせていけばよいの
かという情報を, 内蔵されたタスクスケジューラ (Tack Scheduling Queue, 以下 TSQ) に
登録しておく. そしてシンセサイザは, その情報を基に統合作業を行っていく. 図 3.8 に,
– 18 –
3.2 構成
TSQ の概略を示す.
required content
C.3
Combining Unit
Combining Scheduler (Queue)
C.2
sequentially enqueue from CELL
C.4
which processing is complated
C.1
Trigger
C.5
CELL
C.6
C.6
C.9
C.7
C.8
C.2
C.10
C.4
C.3
図 3.8 CELL スケジューリングの概略図
TSQ に登録される情報とは, 呼び出した CELL そのものである. 呼び出されて, 完全に
処理が終了した CELL から順番に登録していく必要がある. また同期ユニットと同様, コ
ントローラ側が Master, CELL 側が Slave の関係を持っている. コントローラ側には TSQ
が搭載され CELL の管理を, CELL 側には TSQ に登録するための機能が実装されている.
シンセサイザ
シンセサイザは, アナライザが呼び出した複数の CELL を統合し, それらの処理結果を基
に, コンテンツを Web ページの形で生成し, Web ブラウザへの応答を行う役割を持つ.
図 3.9 にシンセサイザの内部処理の流れを示す. シンセサイザは, アナライザの処理終了
後にコントローラから自動的に呼び出される. そして, 統合ユニットの Master 側に内蔵さ
れた TSQ から, 以下のアルゴリズムに従い, 登録されている CELL を取り出し, 統合処理
を行う.
1. TSQ から CELL を取り出し, バッファに登録する
2. TSQ に CELL がまだ登録されているかを確認する
– 19 –
3.2 構成
(a)登録されている場合, 新たに TSQ から CELL を取り出す
(b)登録されていない場合, Web ブラウザに統合結果を返し, 終了する
3. バッファに登録されている一つ前の CELL と比較する
(a)階層が対等もしくは下位の場合, 新たにバッファに登録する
(b)階層が上位の場合, バッファから下位階層にある CELL を全て取り出して統合し,
結果をバッファに登録する
4. 2 へ戻る
この際, シンセサイザは単に CELL の持つ処理結果を組み合わせによる親子関係を反映
しながら統合してが, その過程において プロファイル (Profile) と呼ぶ Web ブラウザのレ
タリング特性や, ユーザ毎に設定されたカスタマイズ情報を, 同期ユニットから取得し, 統合
結果として生成する Web ページに反映させる.
Combining Unit
Synthesizer
Buffer Zone
waiting for
C.2
parent-CELL
Trigger CELL
C.3
C.4
to be generated
C.7
C.8
C.10
Generator
C.9
"Profile"
dequeue
C.5
C.1
C.6
is reflected
finally, Reply to
Web browser
in the output
Combining Scheduler
Profile
(Queue)
図 3.9
3.2.2
シンセサイザの概略図
CELL
CELL は, 小規模なコンテンツを管理するための処理単位であり, 複数の CELL を組み合
わせることで, 大規模なコンテンツを実現させていく. CELL は, 以下に示す 2 種類の部品
と, データ定義部で構成されている.
– 20 –
3.2 構成
• 同期ユニット (Synchronous Unit)
• 統合ユニット (Combining Unit)
• データ定義部 (Data Definition Part)
統合ユニットとは, 他の CELL との組み合わせを実現させるための機能を内蔵したもの
である. また, 同期ユニットは, コントローラや他の CELL とで重要な情報を共有するた
めの機能を内蔵している. データ定義部は, 要求されるコンテンツを構成するために必要な
CELL の呼び出しやデータ処理などを行うための PHP プログラムを記述する部分である.
CELL は基底クラス CELL を継承したクラスとして表現され, 内部ユニットへのアクセ
スするためのメソッド等, CELL の役割を担うために必要な機能を付与することができる.
また, 外部からのアクセスを許可するメソッドには, レセプタ (Receptor) を付ける必要が
ある. このレセプタの実装は, アクセスを許可するメソッド名の頭に “gate ” を付加するこ
とで行う. 図 3.10 に, レセプタのコーディング例を示す.
URI: http://www.example.com/? Example & action=Test &...
// example for CELL coding in openGATE
class Example extends CELL {
function gate_index ($box) {
// Receptor (when "action" was not set)
}
function gate_Test ($box) {
// Receptor
}
function b () {
// public method which defined by PHP
}
}
図 3.10
function _c () {
// private method which defined by PHP
}
CELL におけるレセプタのコーディング例
– 21 –
3.2 構成
これにより, アナライザから Trigger CELL (第 3.2.1 節), もしくは CELL 内部から他の
CELL のアクセスはレセプタに制限される. また, 外部からのアクセスをレセプタのみに限
定することで, 機能の隠蔽によるセキュリティ性も高めることができる.
また, 内蔵される 2 つのユニットについては, 第 ?? 節で解説したとおり, 同期ユニット
は Slave であり, 同期パラメータの管理等はコントローラ側で行われる. 統合ユニットも
CELL スケジューリングは, コントローラ側で制御されるため, 登録作業のみを担当すれば
よい.
データ定義部とは, 要求されるコンテンツを構成するために必要な CELL の呼び出しや
データ処理などを行うためにプログラム, また文書データや画像等のコンテンツの格納処理
を, サーバサイドスクリプト言語 PHP で記述する部分である.
CELL の組み合わせ機能
CELL の特徴である組み合わせ機能に似たものに, 先に解説した xoops で採用されてい
るモジュールを挙げることができる. モジュールでは多くの場合, それ一つで, 一つの Web
サービスを提供する. 一方 CELL は, 単一機能やデータ単位でコンテンツを管理し, 複数の
CELL の組み合わせによって, 必要な Web サービスを提供する. そこで使用した CELL は,
別の Web サービスでも活用することが可能になり, モジュールと比較して, 拡張性と再利用
性を高めることができる. このような CELL の特性を活かすため, CELL を制御するコン
トローラ側も, その制御と, 開発及び運用支援のため機能以外は, 最低限しか実装されていな
い. 標準のコンテンツ管理ツールも CELL で構築し提供することで, その仕様変更も可能に
し, ユーザの実情に合わせた CMS の実現を基盤レベルで支援している.
– 22 –
第4章
導入事例
概要
4.1
本章では, openGATE の導入事例として, 四万十農業協同組合 (JA しまんと)・地域振興
班
∗1
におけるサイト構築・運用を紹介する.
当事例では, 同班に情報技術者が在籍していないことを考慮した運用システムを, open-
GATE の CELL により実装し, 2004 年 11 月から実際に 図 4.2 に示すような Web サイト
を公開している. また現在も, 実際にシステムを利用してコンテンツの制作, 管理, 及び配
信を行う職員の要望を受けながら, openGATE の調整及び CELL による機能拡充を行って
いる.
4.1.1
Web サイト構築での CELL の活用
同班の Web サイトを構築するにあたり, 以下の 3 種類の CELL を制作し, 使用した. な
お, ここにはサイト構造を規定する CELL に関しては含まれていない.
■Topics Topics は, 新聞の見出し記事のような, 見出し部分と記事部分とで構成されたコ
ンテンツの管理と, それらを表示させる機能を有する CELL である.
■Diary Diary は, 先に挙げた Topics の機能に, 写真などの画像コンテンツの取り扱い機
能を追加した CELL である.
∗1
URI: http://www.kochistyle.com/40010/
– 23 –
4.1 概要
図 4.1
■MailBox
四万十農業協同組合・地域振興班の Web サイト概観
MailBox は, メールサーバにアクセスし, メールを送受信する機能を有する
CELL である.
これらの CELL の組み合わせによって完成した Web ページを 図 4.2 に示す. このよう
に, 機能ごとに制作された CELL を組み合わせることで, フッダとヘッダの固定部分を除き,
Web ページの全てコンテンツを形成していることが分かる.
この例では, Topics が項目毎の記事レイアウトを規定し, その内部コンテンツに画像が必
要な場合には Diary を呼び出し, その機能を利用している. また Topics や Diary の内部で,
MailBox を呼び出すことにより, 文書や画像を含んだメールデータを, コンテンツとして提
供することが可能になる. この仕組みを用いれば, 身近に普及し, 簡単な操作で利用すること
ができる携帯電話等のメール機能を用いたコンテンツ制作も可能になり, ユーザビリティの
向上も簡単に実現することができる.
– 24 –
4.1 概要
図 4.2 CELL の組み合わせ関係と制作した Web ページの外観
4.1.2
Web サイト運営での CELL の活用
さらに CELL の特性を活かすことで, ロジックを制作するエンジニアの負担は最小限に
しながらも, 高い性能やユーザビリティを持つ Web サービスも実現することが可能になる.
この例では, 以下に示す 2 種類の CELL の関係性とその機能実装について解説する.
■DataScope
DataScope は, 図 4.3 のような外観を持ち, データベースに保存されたコ
ンテンツデータを表形式で表示し, 管理することができる CELL である. その管理範囲に
はアクセス権限等の高度な設定項目も含まれているため, 利用者には情報リテラシに加え,
データベースに関する知識が求められる.
■EzScope
EzScope は, 図 4.4 のような外観を持ち, DataScope の機能に加えて, ユー
ザビリティ向上を目的としたウィザード (対話) 形式, 説明文の表示, 用語ヘルプの 3 種類の
– 25 –
4.1 概要
図 4.3
DataScope の外観
機能が実装されている CELL である.
外観を見て分かる通り, 双方の CELL は異なるレイアウトと機能を持っている. しかし,
EzScope 内のデータ処理には, CELL として実装されている DataScope のデータ定義部
を呼び出し利用されている. これにより, 新たに必要になるコーディング作業を, 新たに追
加した機能とレイアウトに絞ることができ, 作業を行うエンジニアに掛かる負担を大幅に軽
減することを可能になる. さらに, DataScope の持つアクセス権限等の高度な設定項目は
EzScope では隠蔽するといった, ユーザビリティ向上のための工夫も簡単に実現することが
できる.
このような CELL の運用を行うことで, 異なる情報リテラシレベルを持ったコンテンツ
プロバイダ, ユーザに対して, 最適なコンテンツを提供することが出来る.
– 26 –
4.1 概要
図 4.4 EzScope の外観
– 27 –
第5章
評価実験
提案システムの有益性を実証するため, 従来方式と比較し, 効率的にコンテンツを制作で
きるかを定量的に評価する必要がある. そこで, CELL と従来通りのプログラミング手法の
双方で, 同様の仕様を持つ Web サービスを制作した場合のプログラムコードを対象に, どち
らが効率的かの評価を行った.
5.1
評価概要
定量的評価には, 1995 年に白田氏によって, ソフトウェアの制御構造等のプログラム設計
上の特性を測定, 評価するための方法として, 提案された評価尺度 [8] を用いた. この評価尺
度は, プログラムを語彙的複雑さ, 構造的複雑さ, そして論理的複雑さの三つの異なる観点か
ら評価している. これを適用するにあたり, 一般的にその取り扱いや処理の難易度を考慮し
難い関数を, 特殊関数に指定する必要がある. 今回は, 以下の関数を特殊関数としてカウント
した.
1. 提案システムが提供するシステム及び
CELL 制御に関する関数
2. ファイル/データベース操作等の資源の利用及び
排他制御に関する関数
3. エラー及び例外処理に関する関数
– 28 –
5.2 実験結果
表 5.1 ソフトウェア評価尺度による従来方式との比較
統計値 従来方式 :
提案システム
増減率 プログラム規模
746
:
590
0.7909
プログラム語彙数
1373
:
1081
0.7873
構造難易度
0.1837
:
0.1567
0.8531
処理難易度
2.6441
:
6.2129
2.3498
演算度
0.4438
:
0.3840
0.8654
データ処理度
2.1156
:
2.0551
0.9714
また, この評価尺度で計測する際には, 使用したクラスやメソッド等のプログラムコード
も, 予めプリプロセッサによって展開するとしているが, 今回は PHP や提案システムが提
供しているクラスやメソッドを用いた上でのプログラム効率の測定が必要になるため, 行っ
ていない.
5.2
実験結果
この条件下で, 双方の手法により, 一般的な機能を有する掲示板型 Web サービスを作成
し, 評価尺度を適用した. その結果を 表 5.1 に示す.
5.3
考察
提案システムは従来方式と比較して, 全体的にプログラムの効率化が図られている. 特に,
プログラム規模と語彙数を示す値は, その傾向が顕著に表れている. しかし, 処理難易度だけ
は大幅に増加している. これは, CMS が管理するコンテンツとして提供するにあたり, 実装
の際にアクセスが必要になるクラスライブラリ及び関数群を, 特殊関数としてカウントした
ためと考えられる.
この処理難易度の数値には課題が残るが, 評価実験によって, 提案システムによって従来
– 29 –
5.3 考察
のプログラミングと比較し, プログラム段階での効率化が図られていることを確認できたと
いえる.
– 30 –
第6章
おわりに
6.1
評価に関する課題
前節で示した評価実験により, 提案システムは語彙的複雑さ及び構造的複雑さでは従来方
式と比較して効率的だとする結果を示すことが出来た. だが論理的複雑さについては, それ
を示すに至らなかった. 単純な Web サービスとしてではなく, CMS の管理するコンテンツ
として提供するため, 限界があるものの, この値の改善に関する検討を続けていきたい.
また, この評価実験は本研究室で行ったものであるので, より信頼度の高いデータを得る
ためにも, その規模を広げ, 第三者の利用による評価実験を進めていく. 現在, 計画中の評価
項目については, 以下の通りである.
1. CELL 制作段階での効率化測定
2. コンテンツ制作面での効率化測定
3. コンテンツ管理面での効率化測定
このうち, コンテンツ制作及び管理面での効率化測定は, 2004 年 11 月から四万十農業協
同組合 (JA しまんと)・地域振興班に導入した openGATE を対象にして行われている∗1 .
この事例では, 同班職員がコンテンツ制作及び管理を行っており, ここ得られたログを統計
処理し, 効率化測定を行う計画である.
∗1
URI: http://www.kochistyle.com/40010/
– 31 –
6.2 ウェブアクセシビリティに関する取り組み
6.2
ウェブアクセシビリティに関する取り組み
ウェブアクセシビリティ (Web Accessibility) とは, Web サイトが高齢者や子ども, 障害
を持つ人等, コンテンツ配信に配慮が必要な状態にあるユーザに対しても, 提供コンテンツ
へのアクセスを保障していることを指す. 我が国では, 2004 年 6 月に日本工業規格 (JIS)
において JIS X 8341-3 が制定され [9], 国や地方自治体, そして大企業を中心にこの規定に
則った Web サイトの改訂作業が進んでいる.
本格的な情報社会の到来を迎える今後, ユーザに情報リテラシ取得等による情報格差の是
正を強いるだけでなく, コンテンツプロバイダにも, CMS のような誰もが簡単に利用できる
情報システムを構築し, コンテンツを提供していくことが要求されてくる. openGATE にお
いても, CELL の組み合わせ機能や, ユーザ毎に設定可能なプロファイル等を活用した, ウェ
ブアクセシビリティの実現手法を提案する予定である.
6.3
まとめ
本稿では openGATE の構成と, 処理単位 CELL を活用した処理の流れについて解説し
てきた. 今後は, 課題に挙げた定量的評価やウェブアクセシビリティへの対応を進めると同
時に, ドキュメントの整備, 及び web サイトで頻繁に利用される機能の CELL 化を行い, 外
部提供を目指していきたい.
– 32 –
謝辞
本研究を進めるにあたり, 研究室の中で何事にも一番迷惑を掛けている私に対しても, 寛
大な態度で接して下さり, いつも進むべき道を指し示して下さった清水明宏先生には, 心よ
り感謝を申し上げます. またお忙しい中, 副査として論文のご指導下さった酒居敬一先生に
も深く感謝いたします.
そしてこの 2 年間, 私を様々な面から支えて下さった先輩方, 及び同期, 後輩の皆様にも
感謝を申し上げます. 特にその中でも, 研究が行き詰った際に的確なアドバイスを下さった
博士課程の辻貴介氏, 稚拙な論文構成をいつも厳しくご指導して下さった修士課程の福冨英
次氏, 本研究の最大の理解者であり, いつも研究室全体を支えながら論文や発表に関しての
アドバイスをして下さった同期の有瀬和徳氏, そして電子情報通信学会・オフィスインフォ
メーションシステム研究会の原稿提出にあたり, 文書校正を行ってくれた同期の中原知也氏
には特に感謝申し上げます.
最後に, 四万十農業協同組合・地域振興班の皆様には, 提案システムの実験を行う環境と,
多くのヒントを頂きました. 本研究を始めるきっかけとなった高知県各地でこれまで出会っ
た心温かい方々と併せて心より感謝を表します.
– 33 –
参考文献
[1] Yuta ISHII, Akihiro SHIMIZU: “openGATE: A Proposal of Contents Management
System which Introduced a Processing Unit “CELL””, NEINE’04 International
Conference Next Era Information Networking, pp.394-397, 2004
[2] Tim Berners-Lee, Information Management: A Proposal, CERN, 1989
[3] HotWired Japan, 日本における blog の過去・現在・未来,
http://hotwired.goo.ne.jp/matrix/0305/004/, 2003
[4] 総務省, 情報通信白書 平成 16 年版, 2004
[5] 財団法人インターネット協会, インターネット白書 2004, 2004
[6] Dave Winer, Weblogs.Com News, http://newhome.weblogs.com/historyOfWeblogs,
2002
[7] BlockSTAR, PIC Web Services Inc., http://www.blockstar.com/blog/blog timeline.html
[8] 白田 光有: “ソフトウェア評価尺度と生産性評価に関する考察”, 電子情報通信学会論文
誌 Vol.J78-D-1, No.12, pp.936-944, 1995
[9] 日本規格協会, JISX8341-3: 高齢者・障害者等配慮設計指針−情報通信における機器,
ソフトウェア及びサービス−第 3 部: ウェブコンテンツ, 2004
[10] 森住 俊美, 松浦 宣彦, 茨城 久: “web を用いたコミュニティコミュニケーション活性化
のための汎用システムの開発”, 情報処理学会研究報告 2004-DD-45, pp.1-5, 2004
[11] 土田 正士, 芦田 仁史, 谷口 尚子, 高橋 信雄: “Web フォーム基盤アーキテクチャの提
案及びその応用事例”, 情報処理学会研究報告 2004-DBS-133, 2004-FI-75, pp.51-58,
2004
– 34 –
Fly UP