歯科レセプト処理システムの開発—SOA に基づくシステムのアーキテクチャ設計支援—
M2010MM042 玉木佑一
指導教員：野呂昌満

1

はじめにセプト提出業務の軽減と迅速化を目的として，レセプト電算処理システムが提案されている．我々は歯科レセプ
ト提出業務に必要な診療事務処理 (レセプトチェック，患者負担医療費精算，レセプト作成) を支援するツールをWeb サービスとして開発してきた．歯科レセプト処理システムは，社会保険診療報酬支払基金が公布する診療報
酬請求の標準仕様 [9] に準拠している．

Service-Oriented Architecture(以下，SOA) はビジネス環境の変化に対して柔軟に変更可能なシステムの開発技術である．Georgakopoulos らは，SOA システムのリファレンスアーキテクチャを示している [1]．一般に非機能要求等も考慮して，リファレンスアーキテクチャからシステムアーキテクチャを設計することは容易ではない [8]．
アーキテクチャが存在する事を前提とする Product Line 3 ガイドラインの定義
Software Engineering(以下，PLSE)[6] においても，ドメ
3.1 ガイドラインの概要
イン分析においてアーキテクチャ設計が必要な場合は少非機能要求を考慮した仕様モデルとプロダクトラインなくないと我々は認識している．仕様とアーキテクチャアーキテクチャを定義し，追跡性を確保することでそれとの追跡性を確保しておくことで，アーキテクチャ設計らをプロダクトアーキテクチャ設計のためのガイドライを支援することができる．
本研究の目的は，非機能要求を満たすシステムアーキテ ンとして定義する．図 1 にガイドラインの概要を示す．シクチャ設計のためのガイドラインを定義することである．
SOA に基づくシステムにおける非機能要求と，非機能要求の実現に必要となるアーキテクチャのコンポーネントを整理する．PLSE の考えに基づき，非機能要求を考慮した仕様モデルと，プロダクトラインアーキテクチャを定義する．定義した仕様モデルとプロダクトラインアーキテクチャとの追跡性を確保することで，それらをプロダクトアーキテクチャ設計のためのガイドラインとして定義する．これにより，非機能要求を考慮したアーキテクチャのコンポーネントの配置を追跡することができる．
仕様モデルとアーキテクチャとで，扱う関心事や表すコ
図 1 ガイドラインの概要
ンポーネントの粒度が異なることから，追跡性を確保することは一般に困難である．互いの本質を損なうことなく， ステム開発の流れとして，要求に応じて仕様モデルから対応付け可能な仕様モデルとアーキテクチャを定義する 仕様を作成し，仕様を基にプロダクトアーキテクチャをことが，追跡性確保の鍵となる．アーキテクチャ設計にア 設計する．仕様とプロダクトアーキテクチャを基に，アスペクト指向技術を適用することで解決を図る．アスペ プリケーションを作成する．
クト指向技術を用いることで，支配的分割に横断する仕仕様モデルとプロダクトラインアーキテクチャを定義
様モデルで扱う関心事をアスペクトとして分離すること し，対応関係を明確にし，追跡性を確保しておく．これができ，追跡性の確保が容易になる．我々は，FORM[5] により，仕様モデルから仕様を作成する際に，必要となで提案されているフィーチャモデルを，広く一般に用いら るアーキテクチャのコンポーネントを追跡することが可れているとの認識から，仕様モデル記述に用いる．アー 能となり，プロダクトアーキテクチャ設計が支援できる．
キテクチャの記法には Oldevik が提案するアスペクト指本研究では，仕様モデルの非機能要求を表すコンポー向アーキテクチャの記法 [4] を用いる．
ネントと，非機能要求の実現に必要となるプロダクトラ事例として，OJL(On the Job Learning) として開発に インアーキテクチャのコンポーネントを対応付け，追跡取り組んでいる歯科レセプト処理システムを取り上げる． 性を確保する．SOA システムに求められる位置透過性や歯科レセプト処理システムとは，歯科診療所における診 スケーラビリティ等の，システムアーキテクチャでの実療報酬請求業務を支援するシステムである．定義したガ 現が求められる非機能要求を対象とする．
イドラインを利用し，SOA に基づく歯科レセプト処理シ
3.2 アスペクト指向技術の適用ステムのアーキテクチャを設計する．
仕様モデルとアーキテクチャとの追跡性の確保を目的
2 歯科レセプト処理システム概要
として，アーキテクチャ設計に対しアスペクト指向技術
歯科レセプト処理システムとは，歯科診療所の歯科診 を適用する．仕様モデルとアーキテクチャとで扱う関心療報酬請求事務をサポートするシステムである．歯科レ 事を揃えることで，対応付けが容易になり，追跡性を確保することができると考える．関心事を揃える方法として，仕様モデルで扱う関心事を考慮したアーキテクチャ設計を行なうことが挙げられる．仕様モデルで扱う関心事がアーキテクチャの支配的分割に対し横断することが，この方法の問題となる．この問題に対し，アーキテクチャ設計にアスペクト指向技術を適用することで解決を図る．
システムの支配的分割から，仕様モデルで扱う関心事をアスペクトとして分離し定義することで，仕様モデルとの対応付けが容易なアーキテクチャを設計する．
SOA システムのアーキテクチャにおいて，非機能要求は横断的関心事となりうることから，非機能要求を考慮したモジュール化，および追跡性の確保は困難である．プ
図 3 非機能要求を考慮したフィーチャモデル
ロダクトラインアーキテクチャ設計にアスペクト指向技術を適用し，非機能要求毎に実現に必要となるアーキテクチャのコンポーネント群をアスペクトとして定義する． 3.4 プロダクトラインアーキテクチャの定義
これにより，図 2 に示すように，非機能要求を表す仕様整理した非機能要求と，非機能要求の実現に必要となるモデルのコンポーネントとアスペクトを 1 対 1 で対応付アーキテクチャのコンポーネントとその配置を基に，プけることができ，追跡性の確保が容易になる．
ロダクトラインアーキテクチャを定義する．フィーチャモ
デルとの追跡性を確保するために，非機能要求の実現に必要となるコンポーネントをアスペクトとして設計する．
耐故障性を実現するアスペクトの設計を例として挙げる．サービスを冗長化することで，耐故障性を実現することが可能である．耐故障性の実現に必要となるコンポーネントとして，Fault であるかの判定とサービスへの通信の制御を担う Decider が挙げられる．サービスを実現す
る Web Service，および Web Application が Decider を
図 2 アスペクト指向技術の適用による追跡性の確保介して通信を行なうことで，耐故障性を実現する．耐故障性の実現に必要となるコンポーネントをアスペクトと3.3 非機能要求を考慮した仕様モデルの定義して分離する．Web Service と Web Application 間の通SOA に基づくシステムに求められる非機能要求の整理 信を仲介する形でアスペクトを織り込むことで，耐故障を行なう．SOA に基づくシステムに求められる特性を実 性を実現する．
図 4 に設計したプロダクトラインアーキテクチャを示す．
現するためのシステムアーキテクチャに関する研究が行なわれている [1, 3, 7]．提案されているシステムアーキテ
クチャから，SOA に基づくシステムに求められる非機能要求と，実現に必要となるアーキテクチャのコンポーネント，実現に用いる技術を整理した．本研究では次に示
す非機能要求を取り扱う．

• 位置透過性（Location Transparency）• スケーラビリティ（Scalability）• 並行性（Concurrency）• 拡張性（Expandability）• セキュリティ（Security）• 耐故障性（Fault Tolerance）• 信頼性（Reliability）• 相互運用性（Interoperability）• 正確性（Accuracy）
整理した結果を基に，フィーチャモデルを作成した．非機能要求を Capability Layer に配置する．非機能要求の実現に用いる技術を Implementation Technique Layer に配置し，非機能要求と関係付ける．図 3 にフィーチャモ
デルを示す．

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

図 5 にセキュリティと並行性を例に挙げて仕様モデルと非機能要求を実現するアスペクトの対応関係の概要を示
す．非機能フィーチャと，非機能要求を実現するアスペクトとが対応付く．各アスペクトは，サービスを実現する Web Service，および Web Application に対して織り込むことで，非機能要求を実現する．

を実現する Web Service，および Web Application に対し織り込むことで，求められる非機能要求を満たす SOAに基づく歯科レセプト処理システムアーキテクチャを設計することができた．図 7 に設計した SOA に基づく歯科レセプト処理システムアーキテクチャを示す．

図 5 対応関係の概要

ガイドラインを用いた歯科レセプト処理システムのアーキテクチャ設計

44.1

歯科レセプト処理システムの仕様の作成

SOA に基づく歯科レセプト処理システムに対する要求を分析し，フィーチャモデルを作成した．作成したフィーチャモデルを図 6 に示す．SOA に基づくシステムアーキ

図 6 歯科レセプト処理システムのフィーチャモデル
テクチャで実現すべき非機能要求として，位置透過性，スケーラビリティ，並行性，拡張性，セキュリティ，信頼性が挙げられる．

4.2

図 7 歯科レセプト処理システムアーキテクチャ

システムアーキテクチャの設計定義したガイドラインを用い，SOA に基づく歯科レセプト処理システムアーキテクチャを設計した．ガイドラインを用い，位置透過性，スケーラビリティ，並行性，セキュリティ，信頼性の実現に必要となるコンポーネントを追跡することができた．求められる非機能要求を実現するアスペクトを，歯科レセプト処理システムのサービ
ス (レセプトチェック，保険点数算定，電子レセプト作成)

5

考察

5.1

ガイドラインに関する考察

SOA に基づくシステムにおける非機能要求を整理し，フィーチャモデルと非機能要求を実現に必要となるアーキテクチャのコンポーネントを定義した．定義したフィーチャモデルとプロダクトラインアーキテクチャとの追跡性を確保することで，システムアーキテクチャ設計のためのガイドラインとしてそれらを定義した．技術者は，ガイドラインを利用することで，非機能要求の実現に必要となるアーキテクチャのコンポーネントを追跡することができる．よって，アーキテクチャの一定の品質の保証と，アーキテクチャ設計に要する工数の削減が見込める．
このことから，定義したガイドラインが，非機能要求を満たす SOA に基づくシステムアーキテクチャ設計の支援に寄与していると考える．
提案したガイドラインを用いて歯科レセプト処理システムのアーキテクチャを設計した．歯科レセプト処理システムの仕様モデルを作成し，必要となるアーキテクチャのコンポーネントの配置を追跡する事で，非機能要求を満たすシステムアーキテクチャの設計ができることを確認した．よって，非機能要求を表すフィーチャとアスペクトとの対応付けが妥当であること考える．
5.2

追跡性確保の方法の妥当性

仕様モデルとアーキテクチャとが扱う関心事の違いを，アスペクト指向技術を用いてアーキテクチャ設計をおこない関心事を揃えることで，追跡性を確保した．関心事を揃える代替方法として，アーキテクチャで扱う関心事を考慮し，仕様モデルの意味や構文を拡張する方法が考えられる．この方法の問題点として，記法を拡張することで仕様モデルの本質を損なうことや，仕様モデルの作成がアーキテクチャ設計と同意義になってしまうことが挙げられる．本研究のアプローチでは，仕様モデルの意味や構文の拡張をおこなわないことから，仕様モデルの本質を損なうことはない．仕様モデルにおける関心事をアスペクトとしてアーキテクチャを設計することから，システムの支配的分割に影響を与えることはない．仕様モデルとアーキテクチャ，それぞれの本質を損なうことなく追跡性を確保することができた．よって，本研究の追跡性確保の方法は妥当であると考える．

5.3

追跡性確保の方法の一般性

本研究で行なった仕様モデルとアーキテクチャとの追跡性確保の方法を一般化し，手順を次に示す．

1. 仕様モデルで扱う関心事を整理
2. アーキテクチャで扱う関心事と同粒度の仕様モデルで扱う関心事を特定
3. アーキテクチャの支配的分割に対し横断する仕様モ
デルの関心事をアスペクトとして分離アスペクトとして設計することで，仕様に応じたアーキテクチャの構成要素の入れ替えが可能となる．
本研究は，プロダクトライン構築におけるアスペクト指向技術の適用に関するケーススタディとなる．我々は，エンタープライズ系システムにおける非機能要求をアスペクトとして扱い，プロダクトラインアーキテクチャを設計した．これにより，エンタープライズ系システムを対象とした場合において有効であることが確認できた．

7

おわりに

本研究では，非機能要求を満たす SOA に基づくシステムアーキテクチャ設計のためのガイドラインを定義した．
PLSE の考えに基づき，非機能要求を考慮し，仕様モデルとアーキテクチャを定義した．アスペクト指向技術をアーキテクチャ設計に適用することで，仕様モデルとアーキテクチャとの追跡性の確保を容易にした．定義した仕様モデルとアーキテクチャとの追跡性を確保することで，それらをガイドラインとして定義し，システムアーキテクチャ設計の支援を実現した．

4. 仕様モデルとアーキテクチャを対応付け
組込みシステムを対象とし，仕様モデルに FORM で提 参考文献
案されてるフィーチャモデルを用いた場合に，追跡性を [1] D. Georgakopoulos, and M. Papazoglou, Overview
確保することを考える．組込みシステムのアーキテクチャ
of Service-Oriented Computing,” Service-Oriented
で扱う関心事と同粒度の関心事は，機能，非機能，およComputing, pp. 1-28, 2008.
びオブジェクト (ハードウェアプラットフォーム) である．
[2] G. Kiczales, J. Lamping, A. Mendhekar, C. maeda,
一般に組込みシステムの支配的分割はオブジェクト指向
C. Lopes, J. Loingtier, and J. Irwin, Aspect-oriented
であり，機能と非機能が横断的関心事となりうる．オブprogramming, Lecture Notes in Computer Science,
ジェクト指向で設計したアーキテクチャを基に，機能，お1997.
よび非機能の視点からシステムを分割し，アスペクトと[3] J. Webber, and S. Parastatidis, Realizing Serviceして分離する．これにより組込みシステムにおいても，アOriented Architectures with Web Services,” Serviceスペクト指向技術を適用することで，仕様モデルとアー
Oriented Computing, pp. 51-81, 2008.
キテクチャとの追跡性の確保が可能となると考える．組込みシステムにおけるフィーチャモデルとアーキテクチャ [4] J. Oldevik, Can Aspects Model Product Lines?,
Internal Conference on Aspect-Oriented Softwareの対応関係の概要を図 8 に示す．
Development, vol. 2, pp. 1-8, 2008.

[5] 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.
[6] K. Pohl, G. Bockle, and F. Linden, Software Product Line Engineering Foundations, Principles, andTechniques, Springer-Verlag, 2005.
図 8 組込みシステムにおける対応関係の概要

6

関連研究

プロダクトラインの構築にアスペクト指向技術を適用する研究が行われている．Oldevik は，ドメインや何をアスペクトとするかには言及せず，アスペクト指向技術がプロダクトラインの構築に有効であることを論じている[4]．プロダクトラインアーキテクチャにおける変動体を[7] L. Bahler, F. Caruso, C. Chung, B. Falchuk, andJ. Micallef Toward Configurable QoS-Aware Web
Services Infrastructure,” Service-Oriented Computing, pp. 151-181, 2008.
[8] M. Shaw, D. Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall,
1996.
[9] 社会保険診療報酬支払基金， レセプト電算処理シス
テム.” http://www.ssk.or.jp/index.html/, 2010.