非機能特性の特定によるアーキテクチャの構造決定に関する研究
M2011MM015 平崎唯善
指導教員：野呂昌満

1

はじめに

2

アーキテクチャ構築における課題

アスペクト指向技術によって，従来のソフトウェア開ソフトウェア開発において，アーキテクチャは重要な発技術では難しかった横断的関心事の問題に対処するこ 役割を果たす．アーキテクチャはソフトウェアの基本的とが可能となった [5] ．横断的関心事とは，システムをモ な構造を示すが，ソフトウェアの変更性や再利用性と密ジュール分割した際に，複数のモジュールに散在する関 接に関わっている．この節ではアーキテクチャ構築にお心事である．横断的関心事は分散問題やもつれ問題 [5] を ける問題点と課題について述べ，課題解決に向けたアプ引き起こすので，ソフトウェアに対する理解や保守を困 ローチを提案する．
難にする要因となっている [1] ．横断的関心事の問題に対
2.1 アーキテクチャ構築における問題点処するために，アスペクトを明示的に捉えたアーキテク
保守性や再利用性が高いソフトウェアを開発するためチャを構築する必要がある．アスペクト指向技術を用いに，アーキテクチャ構築の段階で横断的関心事をモジュて，横断的関心事をアスペクトとしてモジュール化することで，ソフトウェアの複雑さの軽減が見込める．この ール化することが求められる．横断的関心事はソフトウ利点を活かすために，横断的関心事を特定してモジュー ェアの保守性や再利用性を低下させる原因となる．横断的関心事をモジュール化することで関心事ごとの変更やル化することが求められる．
非機能特性は横断的関心事になりうる [1] ．横断的関心 修正が可能となり，保守にかかる労力の削減が見込める．
事は保守性や再利用性の低下の原因となるので，非機能 横断的関心事のモジュール化のための技術としてアスペ特性をアスペクトと認識した上でアーキテクチャを構築 クト指向技術がある．アスペクト指向技術は支配的分割しなければならない．仕様モデルに記述された製品の特 に対して横断する関心事をアスペクトとして分離し，モ徴や機能をもとにアーキテクチャは構築されるが，アス ジュール化するための考え方や技術を提供する．アーキ
ペクトを考慮したアーキテクチャと仕様モデルに記述さ テクチャ構築の際にアスペクト指向技術を適用し，横断れる特性との関連は明確にされていない．これにより，仕 的関心事を明示的に捉えたアーキテクチャを構築する必様モデルをもとにした系統的なアーキテクチャ構築が困 要がある．
ソフトウェアの品質を保証するための非機能特性は支難になっている．
本研究の目的は，仕様モデルに記述される特性とアーキ 配的分割に対して横断しうるので，アスペクトとしてモテクチャのアスペクトとの関連を明確化し，アスペクト ジュール化する必要があるが，非機能特性に対応するア指向アーキテクチャの構築を支援することである．仕様 スペクトの構造は明確にされていない．これにより，仕モデルに記述された特性を満たすための構造を，GoF デ 様モデルをもとにした，非機能特性を保証可能なアーキザインパターン [2] をもとに整理して類型化する．本研究 テクチャの系統的な構築が困難になっている．このためでは非機能特性を対象にアーキテクチャのアスペクトと にアーキテクチャの構築には労力がかかり，また，構築の対応付けをおこなう．関連を明確にすることで仕様モ したアーキテクチャの再利用性や保守性が低くくなる可デルとアーキテクチャの一貫性を保つことができ，アス 能性がある．
ペクト指向アーキテクチャの構築支援に繋がると考える． 2.2 問題解決に向けての課題とアプローチ
本研究では，非機能特性を型付きのフィーチャとして定2.1 節で提示した問題は，非機能特性と対応するアスペ義し，非機能特性を満たすための構造と対応付けた．ア
クトを関連付け，仕様モデルから直接的にアーキテクチーキテクチャは機能特性と非機能特性に対応するアスペャを構築可能とすることで解決できる．このための技術
クトの集合およびアスペクト間記述で構成されると仮定的課題として，非機能特性に対応するアスペクトの定義する．この仮定をもとに非機能特性とアスペクトの関連方法と，非機能特性とアスペクトとの対応関係が与えらを整理した．仕様モデルには Cardinality-Based Feature
れたときに仕様モデルからアーキテクチャを構築する方Model(以下，CBFM)[4] を採用し，型付き要素を表現す法の 2 点が挙げられる．
るためにメタモデルを拡張した．アスペクトは GoF デザ
非機能特性に対応するアスペクトの定義には GoF デザ
インパターンをもとに抽象化し，仕様モデルの型付き要インパターンを利用する．各パターンはオブジェクト指素と対応するものとして位置付けた．型付きフィーチャ
向設計における特定の問題や課題に焦点を絞った解法でに対応するアスペクトをアーキテクチャに配置することあり，非機能特性を満たすための構造と関連があると考によって，非機能特性を満たすためのアーキテクチャをえた．デザインパターンをもとに抽象化し，パターン化す構築できる．本研究では組込みシステムを対象に研究をることで，非機能特性に対応するアスペクトを定義する．
進めた．プリンタシステムを事例に仕様モデルを作成し，仕様モデルをもとにしたアーキテクチャの構築には型提案手法を用いてアーキテクチャを構築した．この結果対応を用いる．型対応とは，仕様モデルに記述される非をもとに，型対応以外の手法と比較して考察する．

機能特性を型付きのフィーチャとして定義し，非機能特 である．ContainableByTFG は型付きフィーチャと関連性に対応するアスペクトと関連付けることであるとする． を持つフィーチャの種類を表している．FeatureRelation
本研究では仕様モデルとしてフィーチャモデルを採用し， は CBFM では定義されていないフィーチャ間の関係の種
非機能特性を型付きのフィーチャ(以下，型付きフィーチ 類を表現するために追加した．GuaranteeRelation は，どャ) として表現する．これにより，仕様モデルからの直接 の機能特性や部品を対象として非機能特性を保証するか的なアーキテクチャ構築を実現する．
を表現するために追加した関係である．保証関係はアス
本研究では，アーキテクチャは機能特性と非機能特性 ペクトの織込み先を明示するために必要となる．これらに対応するアスペクトおよびアスペクト間記述で構成さ の表現を用いてフィーチャモデルを作成する．
れると仮定する．機能特性に対応するアスペクトは，シ3.2 型付きフィーチャとアスペクトの関係
ステムの主要な機能を実現するためのコンポーネント群
非機能特性をアスペクトとして捉え，仕様モデルからである．非機能特性に対応するアスペクトは，障害許容アーキテクチャを構築するために型付きフィーチャを定性や効率性といったシステムの品質や満たすべき特性を実現するためのコンポーネント群である．アスペクト間 義した．型付きフィーチャとして表現される非機能特性
記述はアスペクト間の織込みの規則を記述したコンポー は，非機能特性に対応するアスペクトと対応する．図 2
ネントである．これらの組み合わせでアーキテクチャは に型付きフィーチャと非機能特性に対応するアスペクトの関係を示す．
構成される．

3

型付きフィーチャを用いた対応付け

45678NOP!

U:VOWXYZ[6Y\]^E_`Z[6Y!

&'()!

J6T(L78!
%!"#$EFGHIJ'KLM!

本研究では型付きフィーチャを用いてアーキテクチャを!
FG構築する手法を提案する．型付きフィーチャを表現するた
...!
...!
12345678!
めには，仕様モデルの表現を拡張する必要がある．拡張
した表現を用いてアスペクトとの対応を定義する．これらを用いて，仕様モデルからアーキテクチャを構築する． 図 2 型付きフィーチャと非機能特性に対応するアスペク
トの関係
3.1 フィーチャモデルのメタモデルの拡張
!"#$!

!"/!

!"0!

9:;<:=>=?@A!

9:;<:=>=?@B!

9:;<:=>=?@C!

9:;<:=>=?@D!

%!"#$!

*+$!

,-$!

J'KLMQRS!

!"#$EFGHIJ'KLM!

本研究で対象とする仕様モデルはフィーチャモデルであ
非機能特性に対応するアスペクトは，非機能特性を満る．フィーチャは製品の機能特性や非機能特性を表現する たすための構造を GoF デザインパターンをもとに定義しことができるので，仕様モデルとして適していると考える． たパターンで表現される．各非機能特性に適するパター
フィーチャモデルについて調査をおこない，Czarnecki らが ンを特定し，その構造をもとに実現技術に依存しない形提案した CBFM[4] を仕様モデルとして採用した．FORM に抽象化する．このパターンを用いることで，実現技術に基づくフィーチャモデル [3] では層の記述を追加するこ に依存することなく非機能特性を満たすための構造を決とでフィーチャの役割を明示的に示すことができるが，仕 定することができる．型付きフィーチャと他のフィーチ様モデルの段階で実現技術は現れないと考えたことから ャの関連として，どの機能特性を対象として非機能特性CBFM を選択した．仕様モデルとアーキテクチャのアス を保証するかを明確にするために，保証関係を記述する
ペクトとの型対応を実現するために CBFM のメタモデル ことができる．機能と非機能特性の関連を明示的に表現を拡張し，型の表現を追加する．拡張した CBFM のメタ することで，アスペクトの織込み先を明示的に示すこと
モデルを図 1 に示す．
ができる．
=$$&.:%$"!
$03"!

CDEF!

ABB8!

4903")?#*%"!

!"#$%&"+"*#$.(/!

!"#$%&"!
/#4"!

1$&./<?#*%"!
>#*%"!

@/$?#*%"!
>#*%"!
!"#$%&"'()"*!

7!

2&(%3")!"#$%&"!

解析性に対応するアスペクト

ABB8!

2%#&#/$""+"*#$.(/!

1(*.$#&0!"#$%&"!
,"#$%&"-#&)./#*.$0!

903")!"#$%&"!
,"#$%&"903"!

+(($!"#$%&"!
8!

7!

対応付けの枠組みにもとづき，前章で示した非機能特性とアスペクトとの対応関係を整理し，類型化する．組込みシステムでは故障原因を特定できることが重要であるので，解析性に対応するアスペクトをとり上げて整理する．他の非機能特性についても同様にアスペクトとの対応付けが可能である．

7!

-(/$#./#:*";0!!

-(/$#./#:*";09!2!

-(/$#./#:*";0!2!

7!

7!

903")!"#$%&"2&(%3!
<&(%3903"!

!5+","&"/6"!

!"#$%&"2&(%3!
<&(%3-#&)./#*.$0!

図 1 拡張した CBFM のメタモデル
追加要素のうち，TypedFeature は型付きフィーチャを表現する．TypedFeatureGroup は TypedFeature の集合

4.1

解析性に対応するアスペクトの定義

解析性に対応するアスペクトは，Observer パターンをもとに抽象化した．図 3 に解析性に対応するアスペクトを示す．Observer パターンはあるオブジェクトの状態が変化した際に，そのオブジェクトに依存するオブジェクトに変化を通知するためのパターンである．解析性を満たす手法として，監視対象の状態の変化に応じたログ取得や監視モニタへの問題通知といった方法が考えられる．

これらの実装はログ取得や監視の対象となるコンポーネントに依存する．さらに，変化に応じたログ取得などは各コンポーネントに横断する可能性があるので，アスペクトとして分離する必要がある．Observer パターンをもとに抽象化することで，監視対象のコンポーネントとの依存を小さくすることができ，アスペクトとして分離することができると考える．

キャン，進捗とエラーの表示である．プリンタシステムには故障原因の特定と故障の回避が必要と考え，解析性，追跡性，障害許容性が要求される可能性があると考えた．
このプリンタシステムのフィーチャモデルを作成し，アーキテクチャを構築する．

5.1

プリンタシステムのフィーチャモデル

プリンタシステムの仕様をもとに，プリンタシステムのフィーチャモデルを作成した．図 5 に作成したフィーチャモデルを示す．
!"#$!

%&!

XYZ!

()!

'%&!

*+,#!

LM0!

JK()!

-.!

BCA!

^_A!

=>?@A!

=>BC!

=>`a!

DE=FG!

PQ0-.!

NO-.!

図 3 解析性に対応するアスペクト()#*+$,!

AnalysisComponent と AnalysisPoint は抽象化されたコンポーネントである．AnalysisComponent にはデータロガーや監視用モニタがあてはまる．AnalysisComponentは実現手段によって変化する．解析性を満たすための手法は複数考えられるが，AnalysisComponent を変更することで各手法による解析性の実現が可能となる．AnalysisPoint は非機能特性を保証する対象を表現するコンポーネントである．監視やログ取得をおこなうコンポーネントがあてはまる．
4.2

解析性に対応するアスペクトのアーキテクチャ記述

ア ー キ テ ク チャ記 述 と し て ，E-AoSAS++(AspectOriented Software Architecture Style for Embeddedsystem)[6] の記述方法に従ったコンポーネント図を用いる．アスペクト指向アーキテクチャのための記述方法がE-AoSAS++では確立されているので，この記法を用いた．E-AoSAS++の記述に従った解析性に対応するアスペクトの記述を図 4 に示す．図 4 は図 3 をもとに記述したコンポーネント図である．この記法を用いることで，アスペクトごとにその構成を明示的に表現することができる．

-+.&#$'!
()#*+$,!

"#$%&#$'!
()#*+$,!

RSTU!
/01
"23!

1<4!

4#5!
678!
de!

bc!

:;*!<4!

*+,9!

HI0!

+W0!

V$#!

/01!

hi!

j;0k,!

fg!

[\%]!

lmnj;0k,!

図 5 プリンタシステムのフィーチャモデル
機能特性のうちスキャン機能とコピー機能はスキャナの有無によって変化するので，任意のフィーチャとして定義した．型付きフィーチャは点線の四角で表現している．解析性，追跡性，障害許容性は型付きフィーチャのグループであり，障害解析，障害回避，耐故障処理は型付きフィーチャである．図 6 は非機能特性の保証関係を記述している．このフィーチャモデルをもとに，型対応によって非機能特性に対応するアスペクトを分離したアーキテクチャを構築する．
+,-.!
)*!

123!

+,-.!
/0!

)*!

123!

!"#!

45#!

$%!"!

$%!"!

&'(!

&'(!

+,-.!
/0!

)*!

123!

/0!

$%67#!
$%@A!

89$:;!

<=>?!

図 6 非機能特性の保証対象の記述

5.2

図 4 解析性に対応するアスペクトのアーキテクチャ記述

5

事例検証

本研究では事例としてプリンタシステムを用いる．満
たすべき機能特性は，印刷，コピー，印刷の取消し，ス

プリンタシステムのアーキテクチャ記述

前節のフィーチャモデルをもとに，型対応によってアーキテクチャを構築した．構築したアーキテクチャの一部を抜粋したものを図 7 に示す．解析性に対応するアス
ペクトは，4.2 節で示したアーキテクチャ記述と仕様モデ
ル上のソフトウェアプラットフォームの記述を考慮して作成した．支配的分割はオブジェクト指向にもとづいた分割であり，それに対して解析性が横断していることを示している．Subject には保証する機能に関連するコンポーネントを，Observer には解析性を満たすために用いるコンポーネントを配置している．

図 7 プリンタシステムのアーキテクチャ記述 (一部抜粋)

6

考察

6.1

型対応を用いた対応付けに関する考察

6.2

Observer パターンの利用に関する考察

析性を満たすための処理ごとにカプセル化することが可能になり，処理の組み合わせが可能になる．しかしながら，Command パターンを用いた場合では，状態遷移が起きるたびに Command を実行する必要がある．支配的分割にもとづいて分割されたモジュールにこの処理を記述しなければならないので，横断的関心事として分離できていないといえる．
前述の比較から Observer パターンが適していると判断した．解析性を満たすためのパターンはこの他にも考えられるので，他のパターンとも比較する必要がある．また，パターンを組み合わせて実現することも考えられる．
これらの比較をおこない，Observer パターンの利用が妥当であったことを確認しなければならない．

7

おわりに

本研究では，仕様モデルをもとにした系統的なアーキテ
本研究では，型付きフィーチャを用いてアスペクトとクチャ構築を支援するために，非機能特性を型付きフィーの関連付けをおこなった．型対応以外の方法としてタグチャとして扱い，GoF デザインパターンをもとに一般化を用いた対応付けと比較し，妥当性について議論する．
したアスペクトと対応付けた．仕様モデルとして CBFM型対応では，フィーチャモデル上で非機能特性の下層を採用し，型の表現を追加するためにメタモデルの拡張に配置されるフィーチャも同じ型に属することができる．
をおこなった．型付きフィーチャに対応するアスペクト
解析性の下層に配置される障害解析は，解析性に対応すを配置することでアーキテクチャを構築した．解析性にるアスペクトの構造にロギングのような実現技術を加味対応するアスペクトを示し，事例検証の結果からアプロすることでコンポーネントを構築することができる．解ーチの妥当性について議論した．今後の課題として，他
析性を満たす手法には障害解析だけでなく障害監視も考の非機能特性に関しても同様に型対応を考え，カタログえられる．抽象化した構造との型対応により，実現技術化することが挙げられる．に依存することなくパターン化することができた．一方
で，タグ対応が別の手段として挙げられる．タグ対応を 参考文献
用いた対応付けでは，タグの示す内容に特化した関連付 [1] A. Rashid, P. Sawyer, A. Moreira and J. Araujo,
けが必要となる．型対応に比べて抽象度が低く，限定的
Early Aspects: a Model for Aspect-Oriented Reと考える．さらに，非機能特性とその下層に配置される
quirements Engineering,” Proceedings of the IEEE
フィーチャごとにタグを付与しなければならない可能がJoint International Conference on Requirements Enある．上記より，型対応による対応付けが妥当であった．
gineering (RE’ 02), 2002.

Observer パターンをもとに解析性を満たすためのアスペクトを定義した．State パターンと Command パターンを用いた場合と比較し，Observer パターンの利用の妥当性について議論する．
State パターンは状態が変化した際にオブジェクトの振舞いを切り替えることを可能にするパターンである．解析性を満たすためには，エラーの発生や処理の開始と終了のような状態が遷移する場合に状態に応じたログ取得や監視モニタへの通知をおこなう必要がある．State パターンを用いることで状態に応じたログ取得といった方法を実現することができる．しかしながら，State パターンを用いた場合では，支配的分割にもとづいて分割されたモジュールに解析性に関する振舞いが含まれるので，横断的関心事として分離できていないといえる．Observer パターンを用いた場合では，解析性に関する振舞いは AnalysisComponent
内に収まる．
Command パターンはあるオブジェクトに対する要求自体をオブジェクトとして扱い，カプセル化するためのパターンである．Command パターンを用いることで解[2] E. Gamma, J. Vlissides, R. Helm and R. Johnson, Design Patterns: Elements of Reusable ObjectOriented Software, Addison-Wesley, 1995.
[3] K. C. Kang, S. Kim, J. Lee, K. Kim, G. J. Kim andE. Shin, FORM: A Feature-Oriented Reuse Methodwith Domain-Specific Reference Architectures,” Annals of Software Engineering, vol. 5, no. 1, pp. 143168, 1998.
[4] K. Czarnecki, S. Helsen and U. Eisenecker, Staged
Configuration Using Feature Models,” Proceedingsof Software Product Lines: Third International Conference(SPLC 2004), vol. 3154, pp. 266-283, 2004.
[5] L. Rosenhainer, Identifying Crosscutting Concerns
in Requirements Specifications,” Proceedings ofOOPSLA Early Aspects 2004, 2004.
[6] M. Noro, A. Sawada, Y. Hachisu, M. Banno, EAoSAS++ and its Software Development Environment, Proceedings of the 14th Asia-Pacific Software
Engineering Conference(APSEC2007), pp. 206-213,2007.