Web サービスプラットフォームに関する研究
2008MI215 関 浩徳

2009SE097 金田幸大 2009SE209 丹羽裕樹 2009SE220 小倉尚起
指導教員：野呂昌満

12

アプリケーションプラットフォームのプロダ
クトライン化2.1

ATM 監視システムのアーキテクチャ

はじめに多くのエンタープライズ系システムにおいて，ビジネス環境の変化に対応する柔軟性とソフトウェア開発期間の短期化が求められる．ビジネス環境の変化に対応する柔軟性やアプリケーションの生産性を向上させる技術として
サービス指向アーキテクチャ (以下，SOA) が挙げられる．

SOA は Web サービスを連携して構築するシステムのアーキテクチャであり，SOA に基づくシステムはビジネスプロセスの変更に対して柔軟である．多くの場合，SOA に基づくシステムの開発者はミドルウェアを用いてシステムを開発する．本研究室では On the Job Learning(以下，OJL)

一般的な S3 のアーキテクチャだけでなく，SOA styleに基づきアーキテクチャを記述する．S3 では実行効率に関係するコンポーネントの配置が表現されないので，Deployment style で表現する．
ATM 監視システムは SOA に基づいたシステムである
ので，Component & Connector view type の SOA styleでアーキテクチャを記述した．SOA style で識別されたコンポーネントの責務から，S3 の各層と対応づけたアーキテ
クチャを図 1 に示す．

として SOA に基づくシステムである ATM 監視システムを開発した．ATM 監視システムは SOA に基づくシステ
ムの構築ソリューションのひとつである Service-Oriented

Reference Architecture(以下，S3)[1] をもとに開発した．
Web サービスを連携する機能をアプリケーションプラッ
トフォーム (以下，App.PF) が提供する．システムを開発中，実行効率の向上が求められた．実行効率は，単位時間と単位時間で処理可能なトランザクション数の比で，トランザクションは，ブラウザからのリクエストに対するレスポンスを返す処理単位である．

App.PF において，実行効率を向上させるために改善するべき点が不明確であった．システムの実行効率を向上させるために App.PF の改善が考えられたが，App.PF におけるアスペクトと実行効率の関係が不明確であるので，改図 1 S3 と SOA style で表現した ATM 監視システムのアーキテクチャ善すべき点が不明確であった．
本研究の目的は，ATM 監視システムの App.PF におけ実行効率に影響を与える要因の一つであるコンポーネンるアスペクトと実行効率の関係を明確にし，App.PF をプトの配置を表現する Deployment style に基づいて ATMロダクトライン化する．App.PF におけるアスペクトと実監視システムのアーキテクチャを記述した．記述したアー

行効率の関係を明確にすることで，実行効率に着目してプキテクチャを図 2 に示す．

ロダクトを構築することが可能となる．
本研究では，ふたつのアイデアをもとに App.PF におけるアスペクトと実行効率の関係を明確にし，App.PF のプロダクトライン化を目指す．ひとつ目は，プロダクトラインの可変性を分析するために Views and Beyond[2] の各視点における Style と S3 の各層の関係を整理する．Views

and Beyond の記述方法に基づいてアーキテクチャを記述し，S3 アーキテクチャと比較することで可変性を分析する．ふたつ目は，クオリティモデル [3] と App.PF におけるアスペクトの関係を整理する．S3 の各層と Views andBeyond の各視点における Style で実現される非機能特性を整理することで，非機能特性に着目してプロダクトを構築することが可能と考える．

図 2 Deployment style で表現した ATM 監視システムのアーキテクチャ

2.2

表 1 Views and Beyond とクオリティモデル

プロダクトラインの可変点の導出

プロダクトラインの可変点を特定するために，ATM 監視システムを事例として，S3 の各層と Views and Beyond の各スタイルとの関係を整理する．S3 に基づくアーキテク
チャ，SOA style で表現したアーキテクチャ，Deployment

style で表現したアーキテクチャを比較することでプロダクトラインの可変点を導出する．

S3 のひとつの層内とスタイルの関係，S3 の複数の層とスタイルの関係を整理する．整理した関係を表 3 と表 4 に示す．表内の○は S3 における層と Views and Beyond におけるスタイルが横断関係にあることを表す．

図 3 Views and Beyond と 図 4 Views and Beyond とS3 の関係 (層内)S3 の関係 (層間)表 2 S3 とクオリティモデル

表 3 と表 4 から，アプリケーションと App.PF のインタ
フェースに可変性が存在することが明確となった．具体的に，ミドルウェアの Application Programming Interfaceが挙げられる．

2.3

非機能特性とアスペクトの関係の整理

2.4
App.PF におけるアスペクトと非機能特性の関係を整理するために，次のふたつの関係を整理する．

• Views and Beyond の各視点における Style とクオリ
ティモデルの関係• S3 の各層とクオリティモデルの関係

プロダクトラインの可変性の分析

実行効率に着目して，プロダクトラインの可変性を分析する．可変点の導出，非機能特性とアスペクトのふたつの節から，プロダクトラインの可変性を分析した．
可変要因をアーキテクチャ，実現技術，動作環境の 3 つの視点から分類する．アーキテクチャの視点から，コンこれらの関係を ATM 監視システムの事例をもとに整理

ポーネントの配置，コンポーネントの実現方法，データのし，S3 の各層と Views and Beyond の各スタイルで実現

管理方法が可変要因となる．コンポーネントの配置は，コされる非機能特性を明確にする．

ンポーネントを同一サーバ上もしくは別サーバ上に配置す

ATM 監視システムの事例をもとに，Views and Beyondるかである．コンポーネントの実現方法は，コンポーネンのスタイルとクオリティモデルの関係を整理する．図 1 とトを Web サービス化もしくはメモリ上で扱うかである．

図 2 をもとに，各スタイルに基づくコンポーネントが実現

データの管理方法は，データをデータベースやファイル，する非機能特性を整理することで，Views and Beyond のメモリといった管理の仕方である．．実現技術の視点から，スタイルとクオリティモデルの関係を整理した (表 1).

メッセージングでは送り先の Web サービスに応じて複数S3 の各層とクオリティモデルの関係を整理する．図 1をもとに，S3 の各層における役割のコンポーネントが実現する非機能特性を整理した．整理した S3 の各層と品質特性の関係を表 2 に示す．のメッセージ形式を扱う．SOAP，REST，JSON，Binaryといったメッセージ形式が挙げられる．動作環境の視点から，Web サービスフレームワークである Axis2 や CXF な
どのミドルウェアは可変要因となる．

アーキテクチャ，実現技術，動作環境の視点から，それぞれの可変要因が実行効率に関わる．各視点による可変要
因とその選択肢を整理し，表 3 に示す．

Concurrency，System Conﬁguration，Routing，Message
Transform が挙げられる．これらのアスペクトと整理した可変要因から，App.PF のプロダクトラインアーキテク
チャを図 6 に示す．

表 3 可変要因の整理

図 6 プロダクトラインアーキテクチャ

2.5

プロダクトラインの仕様の定義

可変点として Message Service Provider(以下，MSP) のプロダクトラインの仕様を表現するフィーチャ図を定義コンポーネントの実現方法が挙げられる．MSP の実現方する．フィーチャを階層的に分割して選択要因を表現する

法としては WS 化するか，メモリ上で扱うかの選択肢があことで，プロダクトラインの共通性と可変性の識別が可能る．実行効率を考慮した場合，メモリ上に MSP を配置すとなる．FORM[4] を参考に階層を分ける．

ることによって，App.PF のプロダクトアーキテクチャを実行効率に影響を及ぼすプロダクトラインの可変点には構築できる．

コンポーネントの配置が存在する．コンポーネントの配置を表すフィーチャは FORM の 4 階層では表現されないの

3

事例検証

で Deployment Layer を定義する．Deployment Layer でATM 監視システムを事例として，本研究で提案するプはコンポーネントの配置についてのフィーチャを表す．実

ロダクトラインから実行効率を重視するプロダクトの構築

行効率に着目してプロダクトを構築することを可能とするが可能か検証する．実行効率を重視する前のプロダクトのために，実行効率に対する優劣を＋と−で表現する．＋は

実行効率は 15tps(transaction par seconds) であり，その他の選択肢と比較して実行効率に優れることを示し，−はプロダクトの仕様を図 7 に示す．

他の選択肢と比較して実行効率に劣ることを示す．定義したフィーチャ図を図 5 に示す．

図 7 実行効率を重視する前のプロダクトの仕様
実行効率を向上させるために，コンポーネントの配置，ミドルウェアとメッセージ形式の変更を行ない，実行効率
図 5 プロダクトラインの仕様モデルを重視したプロダクトを構築した．WS フレームワークをプロダクトラインアーキテクチャの定義

プロダクトラインアーキテクチャはプロダクトにおいてAxis2 から CXF に変更した．Axis2 のメッセージング形
式は SOAP だが，CXF で REST を選択することで実行効率を向上させた．MSP，Web Registry, PubSub Registry
を WS 化するとプロトコル変換に時間を要するので，メモ共通して存在するアスペクトの集合として定義する．共通リ上で扱うことで実行効率を向上させた．実行効率を重視

2.6

して存在するアスペクトとして，Location Transparency， したプロダクトの仕様を図 8 に示す．

中心にソフトウェアを開発する方法論である．モデルの変換は CASE ツールで自動化され，CASE ツールはモデル間の関係を規定した変換規則に基づきモデルを変換する．
自動化することによってモデル間の一貫性を保ち，保守性や生産性の向上が期待される．モデルとして，プラットフォーム非依存モデルとプラットフォーム依存モデルが挙げられる．実行効率はミドルウェアにより変化するので，実行効率を向上させる際にプラットフォームが変化する場合が存在する．プラットフォームが変化することで変換規則を再定義する必要があり，アプリケーションの実行効率
図 8 実行効率を重視したプロダクトの仕様に対する要求に柔軟に対応することができない．
アプリケーションの実行効率に対する要求に柔軟な対応が可能であるので，App.PF のプロダクトライン化は妥当

実行効率を重視する前のプロダクトの実行効率は 15tpsであると考える．モデル駆動型開発はモデルの変換を自動で，実行効率を重視したプロダクトの実行効率は 50tps で化することで生産性が向上するが，プラットフォームの変あった．実行効率に優れるプロダクトを構築できたことか化に柔軟な対応ができない．PLSE では核資産を用いて開ら，本研究で提案するプロダクトラインでは実行効率に着発することでアプリケーションに対する要求に柔軟に対応目したプロダクトの構築が可能であると確認した．

し，生産性が向上する．このことから，本研究において，

4

考察

4.1

可変性の分析方法の妥当性App.PF に PLSE を適用し，プロダクトライン化したことは妥当であると考える．

5

おわりにプロダクトラインにおける可変点を特定するためのアプ本研究では App.PF をプロダクトライン化した．プロローチが妥当であるか考察する．本研究では，SOA Style

ダクトラインの仕様と実行効率の関係を整理することで，と Deployment Style に基づき ATM 監視システムのアー実行効率に着目してプロダクトの構築が可能となった．

キテクチャを記述し，S3 と比較することでプロダクトラインにおける可変点を特定した．
本研究における事例検証では，実行効率が異なるシステ
ムを構築することが可能であったが，ひとつの事例検証のみでは信頼性に欠ける，可変性の分析方法が妥当かどうかを確認するためには，さらに事例検証を重ねて信頼性を向上させる必要があると考える．

4.2

プロダクトライン化の妥当性

今後の課題として，可変性の分析方法が妥当であるか確認するために事例検証を重ねることが挙げられる．

参考文献[1] A. Aranjani, L. Zhang, M. Ellis, A. Allam, and K.
Channabasavaiah, S3: Service-Oriented Reference
Architecture,” IEEE Computer Society, vol. 9, no.
3, pp. 10-17, 2007.

[2] F. Bachmann, L. Bass, P. C. Clements, D. Garlan,J. Ivers, R. Little, P. Merson, R. Nord, and J. A.
する．本研究では，アプリケーションの実行効率に対するStaﬀord, Documenting Software Architectures Views
要求に柔軟に対応し，アプリケーションの生産性を向上さ
and Beyond Second Edition, Addison-Wesley Profesせるために App.PF に PLSE を適用した．PLSE の他に，sional, 2010.
App.PF をプロダクトライン化する妥当性について考察

アプリケーションの生産性を向上させる開発方法論としてモデル駆動型開発 [6] が挙げられる．PLSE とモデル駆動開発を比較することで App.PF のプロダクトライン化す[3] ISO/IEC, Software engineering Product quality Part 1: Quality model, 2001.

[4] K. C. Kang, S. Kim, J. Lee, K. Kim, E. Shin, andM. Huh, FORM: A Feature-Oriented Reuse Method
PLSE は，製品系列において再利用可能な核資産を定義
with Domain-Speciﬁc Reference Architectures,” Anし，核資産を用いてソフトウェアを開発する方法論である．
nals of Software Engineering, vol. 5, pp. 143-168,
核資産を利用してプロダクトを構築することでアプリケー
1998.
る妥当性について考察する．

ションの生産性の向上が期待される．核資産は，新たに構築されたシステムや既存のシステムをもとに製品系列における共通性と可変性を定義することで定義される．核資産の組み合わせによって，アプリケーションに対する要求に柔軟に対応するプロダクトの構築が可能である．
モデル駆動型開発はモデルの変換を自動化し，モデルを[5] K. Pohl, G. Bockle, and F. Linden, Software Product Line Engineering Foundations, Principles, andTechniques, Springer-Verlag, 2005.
[6] 高田広章，枝廣正人，沢田篤史，清水徹，中島達夫，平山雅之，組込みシステム概論，CQ 出版社，2008．