携帯端末プラットフォームにおけるアプリケーションアーキテクチャ設計に関する研究
M2012MM047 山本幸法
指導教員：野呂昌満

1

はじめにを，プラットフォームの技術に依存することなく構築可能となる．

携帯端末プラットフォームに関する技術は多様化・複雑化している．それぞれのプラットフォームで提供されてい 2 研究の概要
る API や，アーキテクチャは異なっており，アップデー
本研究では，携帯端末プラットフォームの技術に依存しトによる追加・変更の可能性がある．開発者はプラットない開発を可能にするアプリケーションアーキテクチャ
フォームで提供される API やアーキテクチャを理解し，の設計を行なう．アプリケーションアーキテクチャを設
プラットフォームごとにアプリケーションの開発を行な計するためには，以下の 2 点を達成する必要がある．
う必要がある．
• プラットフォームの技術に依存しない開発プロセス
携帯アプリケーション開発の問題として，アプリケーの構築
ションの開発がプラットフォームに依存しており，統一的• プラットフォームの差異を吸収し，コンポーネントな開発を行なうことができない点がある．多様化・複雑ベースの開発を可能にする共通アーキテクチャの設計化するプラットフォームに関する技術を，プラットフォー共通アーキテクチャの設計と，共通アーキテクチャにムごとにすべて習得することは困難である．開発者は技術を習得した上で，同じ機能を持つアプリケーションで 基づいた技術に依存しない開発を実現するために，PLSEあっても，プラットフォームに応じて個別に開発を行な を適用した App.PF の開発を行なう．プラットフォームの差異を吸収する App.PF を製品系列として定義し，共わなければならない．
本研究の目的は，プラットフォームに依存しない統一的 通部分と変動部分を明確化することで，コンポーネントな開発を可能にするアプリケーションアーキテクチャの の再利用による開発を支援できる．App.PF が対応する設計である．コンポーネントの再利用とプラットフォー 携帯端末プラットフォームの対象は，Android OS と iOSムに依存しないモデル (以下，PIM ) を入力とした自動生 とする．本研究では，App.PF を製品系列としたフレーム成により，プラットフォームに関する技術に依存しない ワークをプラットフォームフレームワーク (以下，PFW) と定義する．
開発を目指す．
プラットフォームに関する技術に依存しない開発を実
本研究では，携帯端末プラットフォームの差異を吸収するアプリケーションプラットフォーム (以下，App.PF 現するために，伴らの研究 [7] を参考にして，仕様の変) のアーキテクチャを設計し開発プロセスを明確にする． 動部分とアーキテクチャの変動部分の対応付けを行なう．
App.PF では，統一的な開発を行なうための携帯アプリ Bachmann ら [2] の定義した変動性の分類から製品系列のケーションの共通構造を提供し，特定のアプリケーショ 変動部分を分析し，FORM[4] の記法に基づいて仕様モデルを構築する．
ンに依存しない機能と非機能を実現する．
各プラットフォームに対応した App.PF の共通アーキ
App.PF の開発は，PLSE ( Product-Line Software Engineering )[5] を適用したフレームワークを用いて行なう． テクチャ( PLA ) として，MVC に基づいたアスペクト指PLSE を適用する理由として，共通部分と変動部分を明 向アーキテクチャの設計を行なう．MVC に基づいたアス確化することで，コンポーネントの再利用による開発が ペクト指向設計を行なう利点として，特定のアプリケーションに依存する機能と非機能に関係する関心事をアス可能になる点がある．
App.PF のプロダクトラインアーキテクチャ(以下，PLA ペクトとして分離できる．これにより，コンポーネント) は，MVC に基づいたアスペクト指向アーキテクチャと ベースの開発を支援できる．本研究では，PLA を以下のして設計する．MVC に基づく理由として，アプリケー 視点で記述する．
ションに依存した機能を提供するコンポーネントを Model• アスペクト間の関係要素として分離できる点がある．アスペクト指向設計を• アスペクトを構成するコンポーネント間の関係と標行なう理由として，非機能に関係する横断的関心事をア準インターフェイススペクトとして分離し，疎結合を実現できる点がある．こ• アスペクトを構成するコンポーネントの変動性れにより，コンポーネントを独立にすることができ，コアスペクト間の関係の記述は，App.PF に存在する関ンポーネントの再利用による開発を支援できる，心事を分析し，プリミティブな関心事をアスペクトとしプラットフォームの技術に依存しない系統的な App.PFて定義することで行なう．対象とする携帯端末プラット開発のために，伴らの研究 [7] に基づき仕様モデルとアーフォームのフレームワークと，ISO9126 [3] をから関心事
キテクチャの変動部分の対応関係を明確にする．これにを分析する．分析した関心事を MVC の関心事においてより，PLA からプロダクトアーキテクチャ(以下，PA )識別することでプリミティブな関心事を特定し，アスペクト間の関係を記述した．
アスペクト間の関係の記述から，アスペクトを構成するコンポーネントの関係を明確化し，共通の構造を記述する．それぞれのコンポーネントの標準インターフェイ
スを定義することで，プラットフォームに依存した実現技術を隠蔽する Wrapper コンポーネントを生成できる．
PLA の変動性の記述として，仕様の変動部分を実現する候補値と，アーキテクチャ上の変動部分を実現するコンポーネントの対応関係を明確にする．対応関係の記述についても，伴らの研究を参考にして行なった．仕様とアーキテクチャの対応関係を明確にすることで，仕様の変動に対して一意に PA を構築可能となり，プラットフォームに依存しない開発が可能となる．
App.PF の実装は PFW では行なわず，App.PF を利用するアプリケーションを製品系列とするアプリケーショ
ンフレームワーク (以下，AFW ) で行なう．App.PF の実装は特定のアプリケーションに依存していることから，特定のアプリケーションの PIM を入力として App.PFのコンポーネントを生成する．PLA のアスペクトを構成するコンポーネントの標準インターフェイスを定義することで，PIM の設計を支援できる．

3

表 2 整理した App.PF の変動部分

App.PF に存在する関心事の分析

各プラットフォームのフレームワークと ISO9126 で定義されている非機能特性から，App.PF に存在する関心事の分析を行なった．フレームワークと ISO9126 から識別した App.PF に存在する関心事を表 1 に示す．
表 1 App.PF に存在する関心事

図 1 App.PF のフィーチャモデル

PLA 設計6

整理した関心事と，仕様モデルから PLA の設計を行なった．App.PF の PLA は，MVC のアーキテクチャスタイルに基づいて構築した．PLA は以下の視点でそれぞれ記述した．

• アスペクト間の関係
フレームワークから関心事の分析を行なう際には，それぞれのプラットフォームで提供されている API から行なった．ViewManagement の関心事を例に挙げると，この関心事は Android OS と iOS ではそれぞれ，Activityクラスと UIViewController クラスに存在する．ISO9126
から分析する際には，定義されているすべての非機能特性に対して，App.PF の製品系列に必要な関心事を整理することで行なった．

4

製品系列の変動部分の分析

伴らの研究を参考にして，App.PF の変動部分の分析を行なった．Bachmann[2] らの定義した変動性の分類に基づいて，変動部分と実現候補を表 2 に示す．

5仕様モデルの構築整理した関心事と変動部分から，仕様モデルの構築を行なった．仕様モデルの記述には，FORM[4] の記法を用いた．特定した変動部分を，伴らの研究で整理した変動性の分類と FORM のレイヤの対応付けにしたがって記述することで，仕様モデルを構築した．構築した仕様モデルを図 1 に示す．

• アスペクトを構成するコンポーネント間の関係と標準インターフェイス• アスペクトを構成するコンポーネントの変動性
6.1

アスペクト間の関係

アスペクト間の関係について記述した PLA の設計を行なった．アスペクト間の関係を記述するために，MVCの関心事から整理した関心事を分類し，プリミティブな関心事を特定する．特定したプリミティブな関心事をアスペクト指向アーキテクチャにおけるアスペクトとして定義し，アスペクト間の関係を記述する．
MVC の関心事から整理した関心事を分類し，包含関係を明確化した．MVC と整理した関心事の関係を図 2 に示す．MVC の関心事は，Model・View・Controller・Modelと View 間の EventHandling が存在する．
特定したプリミティブな関心事をアスペクト指向アーキテクチャにおけるアスペクトとして定義し，アスペクト間の関係を記述した．アスペクト間の関係記述は，Clements
ら [6] が定義したアーキテクチャ記述法の Component &Connector View Type のスタイルに基づいて記述した．
記述したアスペクト間の関係を図 3 に示す．

図 2 MVC と整理した関心事の関係

応付けることで，変動性を記述した．変動性を記述した一例として，ApplicationDataComponent の変動性を表3 に示す．
App.PF の製品系列においては，それぞれのコンポーネントを実現するプラットフォームに依存した技術もアーキテクチャ上の変動点であると考える．仕様の変動部分である OS の候補の値に応じて，アーキテクチャ上の各コンポーネントの実現技術を赤いノートで記述した．
表 3 ApplicationDataComponent の変動性

図 3 アスペクト間の関係
それぞれのアスペクトは複数のコンポーネントで構成されており，仕様の変動点を実現する候補によってアスペクトを構成するコンポーネントは変化する．App.PF の共通の構造を定義する上で，アスペクトを構成する共通のコンポーネントの関係と，共通のコンポーネント単位の変動性を記述する必要があると考える．

6.2

アスペクトを構成するコンポーネント間の関係

ApplicationDataComponent は仕様において選択される画面部品によって変動することを示している．各プラットフォームの画面部品を抽象化したコンポーネントが変動の候補値となっており，仕様において選択される画面部品に応じて変動する．選択された OS に応じて，抽象化したコンポーネントの実現技術を対応付けた．

7PA 構築仕様において iOS 選択し，選択フィーチャをすべて選App.PF の製品系列における共通構造として，アスペク択したと仮定した場合の PA の例を示す．PLA の変動性
トを構成する共通コンポーネントの関係を記述した．記の記述に基づいて構築した PA を図 5 に示す．
述は，Component & Connector View Type のスタイルに基づき UML の記法で行なった．アスペクト間記述 (以下，IAD ) が横断するコンポーネントの記述には，AspectStyle を組み合わせることで記述した．
記述したアスペクトを構成するコンポーネント間の関係を図 4 に示す．図 4 に示したコンポーネントに対して，標準インターフェイスを定義することで，実現技術を意識しない開発が可能となる．

図 5 iOS 選択時の PA

図 4 アスペクトを構成するコンポーネント間の関係

6.3

アスペクトを構成するコンポーネントの変動性構築した仕様モデルの変動部分の候補と，アーキテクチャ上の変動部分となるコンポーネントの実現候補を対仕様上で OS の候補値として iOS が選択された場合，アスペクト指向言語を使用できないことから，デザインパターンを用いることで IAD を実現する．デザインパターン [1] である Hook Operation Pattern と Visitor Patternを組み合わせ，混成スタイルとして定義する．
混成スタイルには，Element と Hook のコンポーネントが存在し，アーキテクチャ上ではステレオタイプで表現す
る．Element コンポーネントは，Hook Operation Patternにおける Hook へのメッセージ送信を行なうコンポーネントであり，Visitor Pattern における Element である．
Hook コンポーネントは，Hook Operation Pattern における Hook であり，Visitor Pattern における Visitor で ムに依存しないアプリケーションの設計が可能になるとある．Element コンポーネントに Template Method とし 考える．て，Element 自身を引数に持つ Hook へのメッセージ送携帯アプリケーションのための App.PF のドメインで信を定義する．Hook コンポーネントは，Visitor Pattern は，共通構造におけるコンポーネントの実現技術もアーおける Visitor と同様に Element に応じた処理を行なう． キテクチャ上の変動部分として記述した．共通の構造にこれにより，Element の記述を変更することなく，アス 対して，プラットフォームに依存した実現技術を対応付
ペクト指向に基づいて IAD を実現できる．
けることで，実現技術を隠蔽する Wrapper コンポーネン
Android OS が選択された場合には，アスペクト指向 トの生成を支援できる．よって，実現技術を変動部分と言語を使用できることから，AspectJ における Aspect で して扱う事は妥当であると考える．
IAD を実現できる．Aspect 指向言語によって疎結合通信
9 おわりにが実現されることから，構造の変更は行われず PLA と本研究では，プラットフォームに依存しない統一的な開同じ構造となる．
発を可能にするアプリケーションアーキテクチャの設計
8 考察を行なった．プラットフォームの差異を吸収する App.PF
8.1 PLSE を適用した App.PF の開発の共通アーキテクチャと，仕様とアーキテクチャの対応携帯端末プラットフォームの差異を吸収する App.PF 関係から，プラットフォームの技術に依存せず，PA を構を製品系列として定義し，PLSE を適用した開発を行なっ 築できる．
今後の課題として，次のことを行なう必要がある．
た．伴らの研究に基づいて，仕様モデルとアーキテクチャ• AFW において App.PF の Wrapper コンポーネンの対応関係を明確化することで，プラットフォームの技トを生成する際に入力となる PIM の明確化術に依存しない PA の構築が可能となった．これにより，携帯端末アプリケーションのための App.PF のドメイン• Wrapper コンポーネントの生成規則においても，仕様とアーキテクチャの対応付けによる PA• 再利用コンポーネント開発の支援構築が可能であることを確認できた．構築した PA に対して，再利用コンポーネントや，ジェネレータを実装す 参考文献
ることで，App.PF の実現技術を隠蔽する Wrapper コン [1] E. Gamma, R. Helm, R. Johnson, and J. M.
ポーネントを生成できると考える．
Vlissides, Design Patterns: Elements of Reusable
8.2

App.PF に存在する関心事の分析

App.PF に存在する関心事を，携帯端末プラットフォー
ムのフレームワークで使用される API と ISO9126 で定義される非機能特性から分析した．フレームワークで使用される API から分析することで，携帯アプリケーションに共通の基本的な非機能を分析した．しかし，それぞれの携帯端末プラットフォームで提供されている API を網羅的に調査することはできておらず，他の関心事が存在する可能性があると考える．ISO9126 で定義される非機能特性については，網羅的に分析を行なう事ができたと考える．
8.3

設計した PLA

Object-Oriented Software, Addison-Wesley, 1995.
[2] F. Bachmann, L. Bass, Managing Variability in
Software Architectures, Proceedings of the 2001
symposium on Software reusability, pp. 126-132,
2001.
[3] ISO/IEC, Software engineering Product quality Part 1: Quality model, 2001.
[4] K. C. Kang, S. Kim, J. Lee, K. Kim, G. J. Kim, andE. Shin, FORM: A Feature-Oriented Reuse Methodwith Domain-Speciﬁc Reference Architectures, Annals of Software Engineering, vol. 5, no. 1, pp. 143168, 1998.

[5] K. Pohl, G. Bockle, and F. Linden, Software Prod各携帯端末プラットフォームに対応する App.PF を製
uct Line Engineering Foundations, Principles, and品系列として定義し，MVC に基づいた PLA のアスペク
Techniques, Springer-Verlag, 2005.
ト指向設計を行なった．MVC に基づいたアスペクト指向設計を行なうことで，関心事をアスペクトとして分離し， [6] P. Clements, F. Bachmann, L. Bass, D. Garkan, J.
Ivers, R. Little, P. Merson, R. Nord, and J.Staﬀord,コンポーネントの再利用による開発が容易になった．まDocumenting Software Architectures Views and Beた，Model 要素として機能を実現するコンポーネントを
yond Second Edition, Addison-Wesley, 2010.
分離することで，App.PF を変更することなく，機能を実現するコンポーネントを再利用することができる．こ [7] 伴昌樹，吉川翔平， SOA アプリケーションプラット
フォームのプロダクトライン化に関する研究 –アスのことから，MVC に基づいたアスペクト指向設計を行
ペクト指向に基づくプロダクトアーキテクチャの自動なったことは妥当であると考える．
生成–， 南山大学情報理工学部ソフトウェア工学科，アスペクトを構成するコンポーネント間の関係を明確2014．
化することで，差異を吸収する App.PF の共通構造を記述することができた．共通構造におけるコンポーネントの標準インターフェイスを定義することで，プラットフォー