開発プロセス自動化のためのアーキテクチャーの提案モデル ... ·...

開発プロセス自動化のためのアーキテクチャーの提案モデル駆動適合型開発MDAD:Model-Driven Adaptive Development

　実装に至るまでの不十分な設計品質や下流工程での要求、仕様の変更などによって多発するテストフェーズでの手戻

り作業によってプロジェクトの性能は大きく低下する。モデル駆動適合型開発MDADは、こうしたリスクを最小限に抑

える自動化開発プロセスのためのアーキテクチャーである。本論文では、現在国内SI'erの間で注目されているオフショ

ア開発に続く開発モデルとしてMDADについて述べる。MDADのコンセプトをより明確に述べるために、MDADのバッ

クボーンとなるMDA[1]（Model Driven Architecture、モデル駆動型アーキテクチャー）アプローチや、今回ソフトウェ

ア開発プロセスの一例として採用したRUP[2]（Rational Unified Process）についても合わせて述べる。

※本論分は、2001年IBMソフトウェア協力企業SE論文で発表したものである。1 exa review　No.4（2005）

技術部　開発技術チーム

チームマネージャー

松山圭一

Keiichi Matsuyama

exa review　No.4（2005） 2

開発プロセス自動化のためのアーキテクチャーの提案　モデル駆動適合型開発MDAD:Model-Driven Adaptive Development

1. 導入

　「高品質、短納期、低価格」という顧客からのプレッ

シャーが強まる中で、国内SI'erは開発プロセス、開発手

法に関する大胆な変革を迫られている。即効性が期待でき

る施策としてCMMレベル５を達成した低単価のオフショ

アSI'erへの委託開発という取り組みがある。プロジェク

トのうちの可能な限り多くの開発フェーズをオフショアの

CMMレベル５SI'erに肩代わりさせることで、低コストで

品質が保証されたシステムを構築し、同時に圧倒的多数の

開発リソースを開発活動に投入できるということで短納期

をも実現しようとするものである。しかしながら、オフ

ショア開発への需要の高まりと共にオフショアSI'erの単

価が上昇し、低コストという利点が徐々に失われていくこ

とが容易に想像できる。

　一方で、UML[３]（Unified Modeling Language）な

どの統一モデリング言語で記述したクラス図などの詳細設

計仕様から最終成果物であるソースコードを自動生成する

ことで開発生産性を向上しようというMDAアプローチが

「短納期、低価格」を実現する開発手法として期待されて

いる。しかしながら、MDAのスコープはあくまでも"シス

テム"であるため、それを開発するプロセスに大きく依存

する「高品質」という課題を解決することができない。ま

た、ソースコード自動生成はプロジェクトのうちの実装・

単体テストという比較的短いフェーズを更に短縮化するも

ので、削減された工数は低品質の設計活動によって起きる

結合テスト以降の手戻りによって容易に打ち消されてしま

う。

　モデル駆動適合型開発MDADは、MDAのスコープを"シ

ステム"からそれを開発する活動である"プロジェクト"に拡

大し、「高品質、短納期、低価格」というすべての課題を

解決し、SI'erとしての競争力を確保するための開発基盤

を実現しようとするアーキテクチャーである。

　国内SI'erによって当面行われるであろうオフショア

CMMレベル５SI'erへの委託開発を通して、プロジェクト

の品質を均一化するためのプロセスをMDAD内に取り込

むと共に、これまで培ってきたオブジェクト指向要素技術、

要求開発技術をMDAD内に自動化された開発プロセスと

して統合する。同時に、対象となる案件、顧客ニーズ、プ

ロジェクトを取り巻く納期や開発リソースなどの制約に合

わせて開発プロセスを柔軟に変更することで個々の案件に

適合しやすく（Adaptive）、プロセス改善活動を容易な

ものとする。

　本論文は、オフショア委託開発という開発モデルの後に

やってくるであろう自動化開発プロセスという新たな開発

モデルをMDADというアーキテクチャーによって説明す

るものである。また、本論文は、MDAアプローチを適用

することによるコード自動生成等の生産性向上手法につい

て述べるものではないが、MDADのアーキテクチャー導

出過程やMDAD実現手法においてMDAアプローチに共通

するところが多いため、MDAを引用して説明している。

第２章ではRM-ODP[４]（Reference Model for Open

Distributed Processing、オープン分散処理のための参照

モデル）とのマッピングによってMDADのアーキテク

チャーを説明する。第３章ではMDADが導入するMDAア

プローチについて説明する。第４章ではMDADが注目す

る３つのドメインについて、RUP (Rational Unified

Process) を例にとって説明する。第５章ではMDADの稼

動イメージについて説明する。第６章ではMDADを適用

することによって期待される効果について説明する。第７

章で今後の課題を述べる。

2. モデル駆動適合型開発（MDAD）のアー

　　キテクチャー

　最近、MDAは、RM-ODPとマッピングすることで説明

されている。RM-ODPは、ODP（オープン分散処理）シ

ステムに対して異なる５つの"Viewpoint（視点）"を定義

したシステム抽象化のためのフレームワークである。

　それぞれのViewpointは、それぞれのViewpoint固有の

モデリングコンセプトを持っている。つまり、それぞれに

メタモデルを供給することで、Viewpoint内でのモデリン

グを容易にするとともに、Viewpointのスコープを規定し、

他のViewpointのアスペクトが入り混じることを防ぐこと

でシステムに対する関心の分離を容易にする。RM-ODP

が定義している５つのViewpointは、以下の通りである。

Computational Viewpoint

　分散している機能を通信インタフェースとともに定義す

　ることに注目し、分散アプリケーション設計者（ソフト

　ウェアアーキテクト）によって作成される仕様である。

　例としては、オブジェクトモデル、オブジェクト相互作

　用モデルなどである。

Engineering Viewpoint

　Computational Viewpointで定義された機能を実現す

MDA

CIM：コンピュテーション非依存モデル

Computation Independent Business Model

PIM：プラットフォーム非依存モデル

Platform Independent Model

PSM：プラットフォーム固有モデル

Platform Specific Model

RM-ODP

Enterprise Viewpoint

Computational Viewpoint

Information Viewpoint

Engineering Viewpoint

Technology Viewpoint

表１　MDAとRM-ODPのViewpointの対応

図１．MDADアーキテクチャー

exa review　No.4（2005）3


　るためのプラットフォームについて注目し、システム設

　計者（システムアーキテクト）によって作成される仕様

　である。例としては、分散モデル（Distribution model）

　がある。

Enterprise Viewpoint

　ODPシステムの機能に関して記述することに注目する

　が、各機能が環境内でどのような役割を持っているか、

　どのような相互作用をもっているか、このシステムを規

　定しているビジネスルール、管理・利用ルールはどのよ

　うなものかについての仕様で、ビジネス所有者、計画者、

　管理者、ユーザなどのシステム機能の決定者によって作

　成される。例としては、ビジネスモデル、ソフトウェア

　要求などである。

Information Viewpoint

　ODPシステム内で扱われるデータの定義に注目するが、

　状態や遷移も含み、情報システム設計者（システムアナ

　リスト）によって作成される。例としては、情報モデル、

　情報処理モデルである。

Technology Viewpoint

　OS、DBMS、実装言語、通信プロトコルといったよう

　な実際に使われるコンポーネントの定義に注目して、開

　発者（プログラマやコンポーネントベンダ）によって作

　成される。例としては、コードやAPI仕様である。

ＭＤＡは、これに対してCIM、PIM、PSMという３つの

Viewpointを定義しているがこれらのViewpointは、RM-

ODPに表1のように対応している。

　MDADでは、さらに3つのViewpointを定義する。それ

ぞれの詳細については第４章で説明する。

WSM: WorkProduct Structural Model（成果物構成モデル）

　プロジェクト成果物（WorkProduct）に関して仕様記

　述の集約や引用といった関連、即ちドキュメントの構造

　を定義することに注目し、アナリスト、アーキテクトに

　よって定義され、開発者（アナリスト、アーキテクト、

　設計者、実装者）によって利用される。

RTM: Requirements Traceability Model（追跡可能性モデル）

　仕様記述間の抽象化に関する依存関係である追跡可能性

　を定義することに注目し、アナリスト、アーキテクトに

　よって定義され、開発者（アナリスト、アーキテクト、

　設計者、実装者）によって利用される。

PLM: Project Lifecycle Model（プロジェクトライフサイ

クルモデル）

　プロジェクトという開発プロセスを定義することに注目

　し、プロセスエンジニアによって定義され、プロジェク

　トマネージャーによって利用される。

すなわち、RM-ODPやMDAがシステムをスコープとして

いるのに対して、MDADではシステムとシステムを開発

する活動、すなわちプロジェクトをスコープとする。

MDADアーキテクチャーを図１に示す。

図２　マーク付きモデル変換

exa review　No.4（2005）


4

成果物管理の視点、追跡可能性管理の視点、プロセス管理

の視点からプロジェクトを表現するメタモデルを提供し、

これに基づいてそれぞれ、成果物構成モデル、追跡可能性

モデル、プロジェクトライフサイクルモデルをUMLおよ

びその拡張機能によって統一的にモデル化する。これらの

３つのモデルが、プロジェクトの品質を均一に保つための

ドメインとなる。

　プロジェクトの品質を均一に保つことを保証することに

より、モデル→モデル変換、モデル→コード変換などのシ

ステムをスコープとした生産性向上アプローチである

MDAをより効果的かつプロジェクト開発活動に導入しや

すいものとし、品質、生産性といったプロジェクトの性能

を確実に向上する。

3. MDADを実現するためのMDAアプローチ

　MDADは、MDAにさらに３つのViewpointを追加する

ことによるアーキテクチャーのスコープ拡張であるが、

MDADの実現に際しては依然としてMDAアプローチがバッ

クボーンとなっている。本章ではMDADが実現の手法と

してMDAアプローチをどのように取り込んで行くかにつ

いて説明する。MDAに関する記述は、OMG（Object

Management Group）の「MDA Guide V1.0.1」[5]から

の引用の要約である。

3.1. モデル変換アプローチ

　MDAでは、PIMからPSMへのモデル変換をする際のマッ

ピングの方法としてモデルタイプマッピングとモデルイン

スタンスマッピングが提示されている。

　■ モデルタイプマッピング（Model Type Mapping）

　　　モデルタイプマッピングは、PIMを表現する言語で

　　定義されているタイプを使って作成されたモデルから、

　　PSMを表現する言語で定義されているタイプで表さ

　　れたモデルへと変換することを言う。代表的な例とし

　　てメタモデルマッピング（Meta-model Mapping）

　　があげられるが、これはPIM、PSM両者がMOF

　（Meta-Object Facility）[6]レベルのメタモデルを持ち、

　　これらのメタモデル要素の対応付け（Mapping）を

　　することで、モデル変換時のルールを定義しようと言

　　うものである。

　■ モデルインスタンスマッピング（Model Instance Mapping）

　　　モデルインスタンスマッピングは、選択した特定の

　　プラットフォームに合わせて、PIMのモデル要素を変

　　換しPSMを生成する。PIMの個々のモデル要素は、プ

　　ラットフォームのコンセプトを表した"マーク（Marks）"

　　を書き込むことによって、どのようにPSMに変換さ

　　れるべきかを示す。

　MDADにおいては、後者のモデルインスタンスマッピ

ングを採用し、そのうちの"モデルにマークを付ける

（Marking a Model）"という変換アプローチ（以下、マー

ク付きモデル変換と呼ぶ）を使用する。モデルインスタン

スマッピングを採用する大きな理由は、現状のモデリング

ツールでは新たなMOF要素のリポジトリーへの登録が困

難であり、メタモデルマッピングを行うにはツールの進化

を待たなければならないというデメリットがあるからであ

る。図２にマーク付きモデル変換の概念図を示す。MDAD

では、このマーク付きモデル変換を以下の手順で行う。

3.2. メタモデリング

　プラットフォームのメタモデルを定義し、定義したメタ

モデルをUMLプロファイルにマッピングする。Viewpoint

を表現するのに必要なモデル要素を定義しメタモデルを作

成するが、前述したように、新たに定義したMOF要素は、

モデリングツールの制約から後の工程の"モデル化"につな

ぐことができない。そこで、UMLがサポートしている拡

張機能（Extension Package）を使用して、ステレオタ

イプに置き換えていく。こうした拡張定義がUMLプロフ

ァイルであり、マーク付きモデル変換の際の"マーク"とな

る。

図３．MDADのドメイン

cd MDAD Domain

追跡可能性成果物プロセス

<<UMLモデル>>プロジェクトライフサイクル

<<UMLモデル>>追跡可能性グラフ

<<UMLモデル>>成果物構成

*

+to

*

+from

*

+output*

+input

* {ordered} * {ordered}* {ordered}

図４．MDADによる自動化の例



5

3.3. モデル化

　3.2.で定義した"マーク"を付けながら、マーク付きPIM

のモデリングを行う。現状のモデリングツールでもUML

プロファイルをインポートすることで、MOF要素の拡張

を行わずにUMLメタモデルの拡張を行うことができる。

　UMLプロファイルのもう一方の利点は、メタモデルで

あるUMLプロファイルに定義された表記法だけを使うこ

とにより、作成されるモデルがプラットフォームのアーキ

テクチャーに従っていることが保証されるという点にある。

また、UMLプロファイルは、Viewpoint内に他の

Viewpointのアスペクトを持ち込ませないためのモデリン

グフレームワークとしての役割も果たしている。�

3.4. インスタンス化

　メタモデリングとモデル化は、開発者によって手動

で行われる作業であるが、インスタンス化は、変換機

（Transformer）によって自動または半自動で行われる

PSM生成作業である。ここで言う"インスタンス"は、ター

ゲットとするプラットフォームが解釈できる表現に変換さ

れたPSMという意味であり、例えば、EJBプラットフォー

ムにとってはEntityBeanであったり、MS-Wordにとって

はアクセス可能なMS-Word仕様のXML文書、JavaVMに

とっては実行可能なJavaオブジェクトであったりする。

4. MDADが管理する３つのドメイン

　MDADによって追加された３つのViewpointは、それぞ

れに独立したモデリングコンセプト（メタモデル）を持っ

ているが、それぞれが集約しているモデル要素は、ソフト

ウェア開発というテーマに関して相互に関連を持っている。

成果物を入出力のパラメータとするプロセス（アクティビ

ティー）は、成果物間の抽象化依存関係を表す追跡可能性

と成果物を経由して関連を持っている（図３）。

　このことによって、例えば、要求の変更から追跡可能性

をたどっての影響範囲分析、影響範囲分析の結果によって

判明した修正対象成果物、これらの成果物をパラメータと

するアクティビティーの特定、特定されたアクティビティー

のロールへの通知という一連の成果物修正のための活動を

自動化することができる（図４）。

　本章ではMDADが管理する３つのドメインについて、

IBM Rationalが提唱するRUPを例にとって説明する。こ

こでRUPを挙げるのは、オブジェクト指向開発プロセスと

して既に定義されているRUPを例とすることでMDADの

理解をより容易にするためである。MDADは他の開発プロ

セスの導入や独自の開発プロセスを構築することも想定し

ており、RUP専用の開発基盤ではないことを強調しておく。�

4.1. 成果物構成モデル

　ここで言う「成果物」とは、納品物であるかないかにか

かわらず、

　■ 文章で仕様を記述したドキュメント

　　・RUPの記述における利害関係者の要望、開発構想書、

　　ソフトウェア要求仕様書、ソフトウェアアーキテクチ

　　ャー説明書などの自然言語で書かれた仕様書。

　　・仕様や仕様変更の検討、決定などにかかわる議事録。

　■ 文章で記述した仕様の正当性を確認するためのUML

　　モデル

　　・RUPの記述におけるビジネス分析モデル、ユースケー

　　スモデル、分析モデル、設計モデルなどのUMLモデル。

　■ 仕様書に基づいて作成されたソースコード

　■ 仕様が過不足なくソースコードに実現されているこ

cd 成果物

成果物

<<interface>>成果物構成要素

<<interface>>追跡可能仕様記述

<<interface>>アクティビティー・パラメータ

<<realize>> <<realize>><<realize>>

図５．MDADにおける成果物の役割

図６．成果物構造のモデル化とMDAアプローチ



6

とを評価するテストケースやテストデータ

　といったソフトウェア開発プロジェクトにおいてシステ

ム実現のために作成した全ての仕様記述を指す。成果物は、

上記のようなプロジェクトの成果物を構成する要素である

とともに、プロセス管理においてはプロセスを構成するア

クティビティーの入出力パラメータであり、追跡可能性管

理にとっては抽象化の依存関係を確立するための追跡可能

な仕様記述である（図５）。すなわち、構成管理、プロジ

ェクトの計画・遂行、品質管理にとって成果物の定義は、

もっとも重要であり、全てに優先する。

　成果物は、仕様の抽象度（要求、設計、実装など）にか

かわらず、様々な種類の仕様記述で構成されている。ここ

で言う「成果物の定義」は、成果物の分類とそれぞれの成

果物がどのような種類の仕様記述によって構成されている

かを示し、これを"文書（ドキュメント）"の単位でUMLモ

デル化したものが「成果物構成モデル」である。

　よく定義された開発プロセスにおいては、成果物の定義

はガイドラインやテンプレートというような文章やフォー

ムによって行われている。RUPにおいても同様で、成果物

（Artifacts）はテーマ（Discipline）毎に成果物のセット

として分類され、それぞれの成果物にガイドラインやテン

プレートが用意されている。

　例えば、RUPでは要求成果物セットとして、

　■ 利害関係者の要望（Stakeholder needs）

　■ 開発構想書（Vision）

　■ ソフトウェア要求仕様書（Software Requirements

　　Specification）

　■ 補足仕様書（Supplementary Specification）

　■ ユースケースモデル（Use-Case Model）

　■ ストーリーボード（Storyboard）

　■ 用語集（Glossary）

　などの成果物が定義されており、それぞれにガイドライ

ン、チェックリスト、テンプレート、サンプルが提供され

ている。

　開発プロセスを構成しているアクティビティーの入出力

cd 成果物構造メタモデル

成果物構成要素WorkProduct

ソースコードImplementationModel

UMLモデルUML_Model

ドキュメントDocument

引用する（quotes）

構成される（composedOf）

図７　成果物構成を表すメタモデル

図８　成果物構成を表すステレオタイプ



7

パラメータとしては、RUPで示されているような文書の単

位でよいが、追跡可能性を管理するためには、文書を構成

する仕様記述の単位までUMLモデル化する必要がある。

　MDADにおいては、仕様書をどのようなコンセプトで

書くかという従来のガイドラインはメタモデルへと置き換

わり、仕様書をガイドラインに従ってどのような構成で書

くかというテンプレートはモデルへと置き換わる。さらに、

これらをUMLとその拡張機能によってUMLモデル化する

ことで、後述する追跡可能性モデルやプロジェクトライフ

サイクルモデルと連携することができる。

　図６に成果物構成のモデル化とモデル変換アプローチに

よる成果物管理自動化の概念図を示す。�

4.1.1. メタモデリング

　成果物構造を表すためのメタモデルは、文書の内部の編

成を表すことができればよく、例えば成果物間の親子関係

と引用関係を定義した図７のようなメタモデルになる。

　これらのメタモデル要素をステレオタイプにマッピング

したものを図８に示す。このマッピング情報が成果物構成

をUMLモデル化してマーク付きPIMを作成する際のUML

プロファイルとなる。

4.1.2. モデル化

　MDADにとってもっとも重要な工程が、この成果物構

成のUMLモデル化、即ち成果物の定義である。よく定義

された成果物無しには、プロセスの遂行も追跡可能性の確

立も困難となり、品質、生産性とも低下することになる。

　図９にRUPで定義されているソフトウェア要求仕様書

（SRS）の構造をモデル化した例を示す。RUPのSRSは、

FURPS+モデルに従った構成をとっている。

　FURPS+モデルは、

　■ Functionality（機能）

　■ Usability（使いやすさ）

　■ Reliability（信頼性）

　■ Performance（性能）

　■ Supportability（保守性）

　　および、"+"として、以下のような設計上の制約があ

　　げられている。

　■ Implementation Requirements（実装言語や実装

　　標準などの実装要求）

　■ Interface Requirements（外部システムとのインタ

　　フェース要求）

　■ Physical Requirements（H/W、ネットワークなど

　　の物理的要求）

　ここでは、RUPの成果物を例としてあげているが、次章

で述べる追跡可能性モデルの視点から見ると、RUPで定義

されている成果物は十分なものとはいえない。図９のSRS

は"FURPS+"というモデルに従って構成されているが、他

の文書に関しては、統一されたモデリングコンセプト（メ

タモデル）があるわけではなく、特に、成果物セットをま

たいだ成果物間の追跡可能性（例えば、SRSとアーキテク

チャー説明書など）に関しては、まったく考慮されていな

いといえる。この点に関しては、次章で再度述べることに

する。�

図９　RUP/SRSの成果物構成モデル



8

4.1.3. インスタンス化

　上記のようにUMLモデル化された成果物構成モデルか

らMS-Wordのフォームを自動生成することによって成果

物構造をインスタンス化する。たとえば、SRS（ソフトウェ

ア要求仕様書）が図８に示すようにステレオタイプによっ

てUMLモデルとして定義されていれば、これらのステレ

オタイプを"マーク"として、所定のMS-Wordフォームに

変換（マーク付きモデル変換）する。変換先のPSMは、

MS-Wordが読み込み、生成できるXML文法に従ったもの

図10　要求の追加修正作業

図11　モデルの追加修正作業



9

となる。

　開発者は、自動生成されたMS-Wordフォームに仕様記

述を追加し、再度MS-Wordによって生成したXMLを登録

する（図10）。

　MDADは、追加された仕様記述を成果物構成インスタン

スと追跡可能性インスタンスに反映した後にバージョン管

理サブシステム（例えば、CVS）にコンテンツの登録を行う。

　MS-Wordを開発環境ツールとして使用する利点として

は、以下のことがあげられる。

　■ ほとんどのWindowsPCの環境には備わっている。

　■ 開発者に、モデリング、プログラミングのスキルを

　　要求しない。

　■ XML形式で文書の出力が可能。

　UMLモデルからMS-Word文書への変換は、現状でも

Rationalの"SoDA"というテキスト形式文書生成ユーティ

リティーによって可能であるが、SoDAはテキスト文書か

らUMLモデルへの変換ができないため、入力ツールとし

てMS-Wordを使うことができない。したがって、MDAD

の機能としてUMLモデル⇔MS-Word/XMLの順方向、逆

方向の変換を行う機能を開発しなければならない。

　上記の場合は、MS-Wordによって作成された文書の

MDADへの登録とその後の変更に関するものであるが、

UMLモデル図として作成された成果物に関しては、モ

デリングツールからXMI形式でコンテンツを出力し、

MDADに登録することになる。この場合は、MDADは

UMLモデル⇔MS-Word/XMLといった変換は必要としな

いが、変更分の差分の抽出を行い、成果物構成インスタン

スと追跡可能性インスタンスへの差分反映を、MS-Word

文書の場合と同様に行わなければならない（図11）。

4.2. 追跡可能性モデル

　要件定義、基本設計、詳細設計、実装というような一連

の開発フェーズは、上流工程の仕様記述を下流工程に向

かって具象化していく過程であると言える。追跡可能性

（Traceability）はこうした仕様記述間の具象化（開発

フェーズを逆に成果物をたどる場合は抽象化）という依存

関係を表す。

　RUPでは、追跡可能性を確立する目的として以下の項目

を挙げている。

　■ 要求の起源を理解する。

　■ プロジェクトのスコープを管理する。

　■ 要求に対する変更を管理する。

　■ 要求の変更によって起きるプロジェクトへの影響を

　　評価する。

　■ 要求に関するテストをしたことで発生した障害によ

　　って起きる影響を評価する。

　■ システムに対する要求がすべて実装されていること

　　を確認する。

　■ アプリケーションが意図した振る舞いだけをしてい

　　ることを確認する。

　追跡可能性の確立は、開発者が仕様書に仕様記述を追加

するごとに、この仕様記述と上位の仕様記述との間に追跡

可能という依存関係を生成することで行われている。つま

り、新たな仕様を開発者が仕様書に記載した時点で、この

図12　追跡可能性のモデル化とMDAアプローチ



10

新たな仕様記述が上流工程のどの仕様書の中のどの仕様記

述をより具象化したものであるかを開発者が登録している。

具体的には追跡可能性マトリクスを逐次メンテナンスする

ことになる。

　この作業は、管理しようとする仕様記述の粒度を細かく

して、よりきめ細かい追跡可能性管理をしようとする場合、

非常に煩雑な作業となる。

　しかしながら、よく定義された（すなわちモデル化され

た）成果物に対して、事前に仕様記述間の追跡可能性依存

関係を追跡可能性モデルとしてモデル化しておくことによ

り、開発者は追跡可能性モデルに従って、仕様記述を追跡

可能性と共にインスタンス化することができるため、追跡

可能性の確立という作業を簡素化することができる。

　さらにプロアクティブなアプローチとして、成果物を

定義する段階で追跡可能性を意識し、追跡容易な構造を定

義するということで開発時の追跡可能性確立の作業をより

簡素化することも考えられる。

　図12に追跡可能性のモデル化とモデル変換アプローチに

よる追跡可能性管理自動化の概念図を示す。


　RUPでは、要求型（Requirement Type）として、追跡

可能性を確立する対象のエンティティーの抽象度や目的に

合わせて仕様の型を定義している。例えば、利害関係者

の要望（Stakeholder needs）、基本要求（Features）、

ソフトウェア要求（Software Requirements）などであ

る。その一方で、追跡可能性を表す依存関係としては、

<<trace>>という依存関係のみが定義されている。

　しかしながら、追跡可能性にも様々な種類が考えられ、

これらを明示的に表すことで追跡可能性のモデル化や影響

範囲分析を容易なものとすることができる。

　すなわち、

　■ 追跡可能性という依存関係の意味を明確にできる。

　■ 追跡可能性の種類による多角的な分析ができる

　　（Multi-View）。

　こうした追跡可能性の分類を行った一例を以下に示す。

以下に、Patricio Letel ierの「A Framework for

Requirements Traceability in UML-based Projects」

[7]に記載されている内容を引用する。

　『大きく分けて、TraceableSpecificationと

Stakeholderの２つのエンティティーを考える。

Stakeholderは、仕様の作成と変更に関して責任を持つ。

TraceableSpecificationは、ドキュメント、モデル、図、

ドキュメント内の章、非機能要件を示すテキスト、ユース

ケース、クラス、属性等と言ったある粒度のソフトウェア�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

　『大きく分けて、TraceableSpecificationとStakeholder

の２つのエンティティーを考える。Stakeholderは、仕様の

作成と変更に関して責任を持つ。TraceableSpecification

は、ドキュメント、モデル、図、ドキュメント内の章、

非機能要件を示すテキスト、ユースケース、クラス、

属性等と言ったある粒度のソフトウェア仕様である。

図13　要求追跡可能性を表現するためのメタモデル



11

仕様である。 TraceableSpecificationの粒度は、partOf

というロール名を持つ集約関係によって定義される。

　TraceableSpecificationエンティティーの型は、

RationaleSpecification、RequirementSpecification、

TestSpecification、OtherUML_Specificationの汎化であ

る。TraceableSpecificationは、これらのうちの少なくと

も１つのサブタイプに従属することができる。たとえば、

ひとつのドキュメントがいくつかの仕様の型を含む場合な

どである（この場合、partOfを使う）。

RequirementSpecificationは、ひとつの要求または要求

群である。要求がどのように表現されるかによって、要求

はTextualRequirement（テキストの断片を使って表現す

る要求）か、またはUML_UseCase（機能要求を表現する

ためのUMLのモデル要素）のどちらかになる。

RationaleSpecificationは、たとえば、

TraceableSpecificationに関連する原理、代案、仮説を定

義するものである。TestSpecificationは、要求の正当性

を判定したり、UMLモデル要素の真偽を確�

認する（たとえば、クラスやコンポーネントの実装である

ソースコードの評価）ためのテストを定義する。親クラス

がTraceableSpecification、RequirementSpecification

となる汎化関係は、「incomplete」として定義され、追

跡可能性の対象となり得る他の型の仕様をも定義する余地

を残している。例としては、ビデオ、画像、音声と言った

類のテキスト形式でもなく標準のＵＭＬでもない仕様であ

る。これらの仕様は通常、原理・原則に対応し、分析・設

計モデルの改訂、評価に有効である。しかしながら、こう

した類の仕様であれば、RequirementSpecificationを表

現するために、たとえばビデオ記録などのような特定の媒

体が使われるであろう。

　もっとも基本的な追跡可能性リンクの型は、traceToと

いうロール名の関連であり、 TraceableSpecification間

に追跡可能性リンクを張ることができる。その他の追跡可

能性リンクの型（modifies、responsibleOf、

rationaleOf、validatedBy、verifiedBy、assignedTo）

は、

traceToリンク型をより特化したものである。modifiesと

いう名前のリンク型は、 TraceableSpecificationと

それに変更を加えるStakeholderの関係を示すことができ

る。同様に、responsibleOfリンク型である

TraceableSpecificationにその定義と保守に責任を持つ

Stakeholderを関連付けることができる。 validatedByリ

ンク型は、RequirementSpecificationとそれを評価する

TestSpecificationを関連付ける。 verifiedByリンク型は、

ＵＭＬで書かれた仕様を評価するTestSpecificationを決

定する。 assignedToリンク型は、たとえば、ユースケー

スを実現するクラスというように特定の要求を実現するＵ

ＭＬのモデル要素を決定する。』

　　　　　　　　　　　　　　　　　　　（以上、『』内

全文引用）

　図13に示したメタモデルをステレオタイプへとマップす

TraceableSpecificationの粒度は、partOfというロール

名を持つ集約関係によって定義される。

　TraceableSpecificationエンティティーの型は、

RationaleSpecification、RequirementSpecification、

TestSpecification、OtherUML_Specificationの汎化で

ある。TraceableSpecificationは、これらのうちの少なく

とも１つのサブタイプに従属することができる。たとえば、

ひとつのドキュメントがいくつかの仕様の型を含む場合など

である（この場合、partOfを使う）。RequirementSpecification

は、ひとつの要求または要求群である。要求がどのよう

に表現されるかによって、要求はTextualRequirement

（テキストの断片を使って表現する要求）か、または

UML_UseCase（機能要求を表現するためのUMLのモデ

ル要素）のどちらかになる。RationaleSpecificationは、

たとえば、TraceableSpecificationに関連する原理、代

案、仮説を定義するものである。TestSpecificationは、

要求の正当性を判定したり、UMLモデル要素の真偽を確�

認する（たとえば、クラスやコンポーネントの実装であ

るソースコードの評価）ためのテストを定義する。親クラ

スがTraceableSpecification、RequirementSpecification

となる汎化関係は、「incomplete」として定義され、追

跡可能性の対象となり得る他の型の仕様をも定義する余

地を残している。例としては、ビデオ、画像、音声と言っ

た類のテキスト形式でもなく標準のＵＭＬでもない仕様

である。これらの仕様は通常、原理・原則に対応し、分析

・設計モデルの改訂、評価に有効である。しかしながら、

こうした類の仕様であれば、RequirementSpecification

を表現するために、たとえばビデオ記録などのような特

定の媒体が使われるであろう。

　もっとも基本的な追跡可能性リンクの型は、traceTo

というロール名の関連であり、 TraceableSpecification

間に追跡可能性リンクを張ることができる。その他の追

跡可能性リンクの型（modifies、responsibleOf、

rationaleOf、validatedBy、verifiedBy、assignedTo）は、

traceToリンク型をより特化したものである。modifiesと

いう名前のリンク型は、 TraceableSpecificationと

それに変更を加えるStakeholderの関係を示すこと

ができる。同様に、responsibleOfリンク型である

TraceableSpecificationにその定義と保守に責任を持つ�

Stakeholderを関連付けることができる。 validatedBy

リンク型は、RequirementSpecificationとそれを評価す

るTestSpecificationを関連付ける。 verifiedByリンク型

は、ＵＭＬで書かれた仕様を評価するTestSpecification

を決定する。 assignedToリンク型は、たとえば、ユー

スケースを実現するクラスというように特定の要求を実

現するＵＭＬのモデル要素を決定する。』

図15　依存関係を表すステレオタイプ

図14　エンティティーを表すステレオタイプ



12

ることで、追跡可能性モデル化のためのUMLプロファイ

ルを作成することができる。図14および図15に、依存関係

とエンティティーに関するマッピングを示す。

4.2.2. モデル化

　RUPが定義する成果物（Artifacts）は、とくに成果物

セットをまたぐ仕様記述間の追跡可能性をあまり考慮して

いない。たとえば、要求成果物セットの開発構想（Vision）

とソフトウェア要求仕様書（Software Requirement

Specification）では、双方の成果物が追跡可能性を考慮

して作成されているため、追跡可能性モデルは図15に示す�

図16　追跡可能性モデルの例



13

ように簡易なものであるが、異なる成果物セット内の仕様

記述（たとえば、ソフトウェア要求仕様とソフトウェアア

ーキテクチャー説明書など）と追跡可能性をモデル化しよ

うとすると、下流工程の成果物定義を上流工程の成果物定

義に合わせて再度定義しなおす必要がある。

　「追跡容易な成果物定義」は、CMMレベル5等を取得

し、実際のプロジェクト運営に適用しているSI'erの成果

物を参考にしながら、RUPで定義されている各成果物を再

度定義しなおさなければならない。

　ここでは、前章で示したRUPの成果物（図９）に関して、�

追跡可能性モデルの例を図16に示す。

　開発者は仕様記述を追加する際に、追跡可能性モデルに

従って仕様と追跡可能性依存関係をインスタンス化するこ�

とで仕様記述の追加を行っていく。追跡可能性モデルのイ

ンスタンス化は、成果物構成モデルのインスタンス化と同

様にMS-WordやUMLモデリングツールによって行う。�

4.3. プロセスライフサイクルモデル

　プロジェクトライフサイクルモデルは、ソフトウェア開

発活動を構成するアクティビティーを時間軸に沿って並べ

たものである。MS-Projectで言うところの"ガントチャー

ト"であり、RUPで言うところの"ライフサイクル"である。

プロジェクトをライフサイクルという視点でモデリングし、

これをマーク付きモデル変換によってワークフローエンジ

ンの入力に変換することで、開発プロセスの自動化を実現

図17　プロジェクトライフサイクルのモデル化とMDAアプローチ

図18　SPEM依存関係メタモデル



14

しようと言うものである。ここでは、RUPを例にとって

MDADが管理するプロジェクトライフサイクルモデルと

その構築方法について述べる。

　図17にプロジェクトライフサイクルのモデル化とモデル

変換アプローチによるプロジェクトライフサイクル管理自

動化の概念図を示す。

　ここでは、要求開発、設計、実装、テストといったいわ

ばプロジェクトのメインストリームを例としてあげている

が、実際には変更要求管理、リスク管理といったプロセス

と並行かつ相互に協調しながらプロジェクトは進められて

いく。MDADの実現に際しては、こうしたプロセスもモ

デル化され自動化のスコープとしなければならない。�


　MDADでは、ソフトウェア開発プロセスを表現するた

めのコンセプト、すなわちメタモデルとしてOMGが開示

しているSPEM[8]（Software Process Engineering �

Meta-model）を使用する。

　SPEMは、基本要素、依存関係、プロセス構造、プロセス

コンポーネント、プロセスライフサイクルの５つのビュー�

に関してメタモデルを規定しているモデリングコンセプト

である。あわせてメタモデルをUMLの拡張機能にマップ

したSPEM用のプロファイルも供給されており、UMLモ

デリングツール上でのプロセスモデリングを可能にしてい

る。参考までにプロセス構造と依存関係に関するメタモデ

ルを記載しておく。（図18、19）

図19　SPEMプロセス構造メタモデル

図20　RUP：Requirementsのワークフロー



15

�

4.3.2. モデル化

　本来、MDADがプロセスエンジニアに対して用意する

ものはメタモデルをUML拡張機能にマップしたプロファ

イルまでで、これを使って行う開発プロセスのモデリング

は、プロセスエンジニアに任される。しかしながら、フル

スクラッチで開発プロセスモデルを組み立てることは、多�

大な労力と経験を要するため、RUPなどの既に定義されて

いる開発プロセスをSPEMに従ってモデル化しておく。プ

ロセスエンジニアは、あらかじめモデル化されたRUPモデ

ルを利用しながら、各プロジェクトタイプに適合させたラ

イフサイクルモデルを構築することになる。

　RUP:Discipline のモデル化

　RUPでは、ビジネスモデリング、要求、分析設計、実装、

テスト、配置、環境、構成･変更管理、プロジェクト管理

という９テーマに関してそれぞれにワークフローと成果物

セットをDisciplineとして定義している。SPEMに従って

これらのDisciplineをモデル化する。例としてRUP:Discipline

のひとつである要求（Requirements）をSPEMで記述し

たモデルを図20に示す。

ワークフロー中の個々のワークは、さらにサブワークへと

ブレークダウンされる。例えば、"Define the system（シ

ステムを定義する）"は、図21に示すサブワークで構成さ

れる。�

個々のサブワークは、更にいくつかのステップ（Step）

にブレークダウンされる。例えば、"Find Actors and �

Use Cases（アクターとユースケースを抽出する）"は、

図21　サブワーク"Define the system（システムを定義する）"



16

図23　RUPライフサイクル

図22　"Find Actors and Use Cases　　　（アクターとユースケースを抽出する）"

ad Rational Unified Process

Constraction

開始

Inception Elaboration Transition

終了

<<precedes>>

<<precedes>><<precedes>>

<<precedes>>

<<precedes>>



17

図22のようなステップで構成される。

RUP:LifeCycleのモデル化

　プロセスエンジニアは、モデリングツールによって事前

にモデル化されたDisciplineからワークを選択し、プロ�

ジェクトの各開発フェーズをモデリングしていくことで、

RUP:Disciplineに定義されたワークを使いながら各々の

プロジェクトに適合した開発プロセスを組み立てることが

できる。

　RUPでは、ライフサイクルに関しては、Inception、

Elaboration、Construction、Transitionの４つのフェー

ズを定義しているが（図23）、各フェーズでのワークの配

置に関しては、いくつかの例が示されているだけであり、

フェーズ内のワークは、プロセスエンジニアによって各プ

ロジェクトやシステムのタイプに合わせて定義することに

なる。図24に"Inception"の例を示す。個々のワークは、

前後の依存関係を示す<<precedes>>、MS-Projectで言う

ところの"タスク間のリンク"によって接続される（図25）。

�

4.3.3. インスタンス化

　プロジェクトマネージャーは、プロセスエンジニアによっ

て作成されたプロジェクトライフサイクルモデルを使用し

てプロジェクトのインスタンス化を行う。即ちプロジェク

トライフサイクルモデルの各アクティビティーに対して開

始日、終了日、リソースなどのプロジェクト属性値の設定

を行う。たとえば、UMLで記述されたプロジェクトライ

フサイクルモデルをMS-Projectで読込み、プロジェクト

属性値を書き込んだ後に再度MDADに登録することで個

々のプロジェクトインスタンスを生成する。

生成されたプロジェクトインスタンスは、MDADのプロ

セス管理モジュールであるワークフローエンジンの入力と

なる。�

図24　RUP:Inspectionフェーズ

図25　MS-Projectで見たInceptionフェーズ



18

図26　MADAの稼動イメージ

図28　モデルの確認・変更図27　仕様の確認・変更



19

5. プロジェクトにおけるMDADの稼動イメージ

　これまで、MDADのアーキテクチャーや実現方法に関

して個別に述べてきたが、MDADによるソフトウェア開

発への理解をより明確にするため、プロジェクトにおける

MDADの稼動イメージを簡単に説明する。

　一例として、『実装フェーズで、要求の変更が起きた場

合のMDADと開発者のインタラクション』を示す。

　MDADのユースケース、すなわちMDADと開発者のイ

ンタラクションは、プロジェクトプランの作成から要求開

発、設計、実装、テストに至るまでの全域をスコープにし

ているが、ここでは一例として『実装フェーズで要求レベ

ルの変更が発生した場合』のMDADと開発者のインタラ

クションを簡単に説明する（図26）。

　①　変更要求管理によって決定された変更要求にしたがっ

　　　て開発者Aは、ソフトウェア要求仕様書を変更する。

図29　ソースコードの確認・変更



20

　②　MDADは、MS-Word経由で入力されてきたXML

　　　ファイルをUMLモデルに変換する。�

　③　MDADは、変換されたUMLモデルと変更前のUML

　　　を比較し、変更部分によって影響を受ける下流工

　　　程の仕様記述を追跡可能性インスタンスから探し

　　　だす。

　④　MDADは、検出された仕様記述が属する文書を成

　　　果物構成インスタンスから探し出す。

　⑤　MDADは、検出された文書を入力パラメータとす

　　　るアクティビティーをプロジェクトライフサイクル

　　　インスタンスから探し出す。

　⑥　MDADは、検出されたアクティビティーの遂行者

　　　である開発者を探し出し、文書内容を確認する旨の

　　　通知を行う。通知は抽象度の高いものから順次開発

　　　者に通知する。例えば、文書、モデル、ソースコー

　　　ドといった順に行われる。

　⑦　それぞれの開発者（D、C、B）は、MDADが用意

　　　する追跡可能性ビューアーによって追跡可能性を確

　　　認しながら、通知を受けた仕様記述に修正の必要が

　　　ると判断した場合は、変更を行って再度登録する（図

　　　27、図28、図29）。

　②～⑦までの工程は、影響を受ける仕様記述がなくなっ

　たとMDADが判断するまでループすることになる。

　MDADから通知を受けた仕様記述が、上流工程の要求

変更によって実際に影響を受けているかどうかの判断は、

依然として開発者に任されるが、影響分析の省力化、要求

の反映漏れによる品質の低下防止をより効果的に実現する

ことができる。�

6. MDADの適用と期待される効果

　MDADは未だコンセプトの状態であるため、その効果

を定量的に表すことはできないが、効果が期待できる局面

を以下に示す。

プロセスの再利用：

　　開発プロセスや成果物をモデル化することによって再

　利用可能な資産とすることができる。たとえば、ある組

　織・プロジェクトで有効性が確認できた開発プロセスを

　モデル化することで、他の組織・プロジェクトにその開

　発プロセスを導入することが容易になる。

プロセスのカスタマイズ：

　　再利用した開発プロセスを個々のプロジェクト実施環

　境（規模、開発期間、リソース等）、ソフトウェア開発

　手法、CMMレベルなどに合わせて随時カスタマイズし

　ていくことができる。すなわち、開発プロセス自動化の

　段階的な適用を可能にする。

プロセスの連携：

　　変更管理プロセス、リスク管理プロセス等も同様にモ

　デル化することで、本流の開発プロセスと連携させるこ

　とができ、品質管理のためのプロジェクト情報の蓄積、

　再利用へと自動化のスコープを拡大していくことがで

　きる。

要求の実現：

　　これまで各プロジェクトフェーズの開発者によって行

　われてきた要求実現のための文書、モデル、ソースコー

　ドの作成において、過不足なく要求が実現されているこ

　とを保証することができる。

要求の変更：

　　要求や仕様の変更による下流工程の成果物やアクティ

　ビティーへの影響分析を自動化することで、変更発生時

　の手戻り作業（コード修正、仕様書修正）を過不足なく、

　迅速に行うことができる。

オブジェクト指向技術、MDAアプローチの導入：

　　MDADが、UMLモデルによって成果物を管理し、実

　現手法としてMDAアプローチを採用していることによ

　り、UMLモデルを変換の対象とするMDAトランスフォー

　マやその他のオブジェクト指向技術との親和性が良くな

　り、UMLモデル主導の要素技術をプロジェクトに導入

　しやすくなる。

生産性向上施策の導入：

　　コード自動生成、テスト自動化といった生産性向上の



21

　ための施策の導入において、実装までに至る上流工程

　（要求開発、設計）での"要求の実現漏れ"という品質の

　低下がなくなるため、実装、テストでの手戻り作業が大

　幅に減少し、仕様からコードへの自動変換、仕様実現の

　エビデンス取得作業の省力化というコード自動生成やテ

　スト自動化本来の目的に集中でき、期待する生産性向上

　の効果を得ることができる。

7. 今後の課題

　本論文では、品質と生産性向上のための開発環境基盤と

してMDAD：モデル駆動適合型開発と銘打って、そのアー

キテクチャーと実現方法を述べてきた。しかしながら、

MDADを自動化されたソフトウェア開発基盤として稼動

させるためには、今後多くの課題をクリアしていかなけれ

ばならない。

　また、以下にあげる課題の多くは、開発プロセスの自動

化に不可欠な条件であると同時に、自動化以前にSI'erが

方法論、再利用可能な資産として整備して行かなければな

らない必須の知識ベースでもある。

成果物の定義：

　　現状の多くの開発組織では、それぞれの部署、プロジェ

　クト、顧客ごとに成果物の定義はまちまちであり、また

　追跡可能性に関してよく考慮された成果物となっていな

　い場合が多い。自動化を検討する以前に成果物と追跡容

　易な成果物構成を統一的に定義しなければならない。

既存開発プロセスの再利用とカスタマイズ：

　　まずはRUPやCMMレベル5 SI'erの確立された開発プ

　ロセスを導入し、自社のソフトウェア開発活動に合わせ

　て最適な開発プロセスを作成しなければならない。例え

　ば、CMMレベル５で稼動しているSI'erの開発プロセス

　を一部再利用し、自社に合ったCMMレベルまでカスタ

　マイズ（小規模化）することで、より迅速にプロセス改

　善を行うことが必要である。

管理対象のUMLモデル化と蓄積：

　　統一的な成果物定義、プロセス定義を行った上で実プ

　ロジェクトへと適用していき、プロセス自動化の起点と

　なる成果物構成、追跡可能性、プロジェクトライフサイ

　クルのモデル化、蓄積を行うことが必要である。

要求開発技術のレベルアップ：

　　いかにMDADが自動化開発環境としてうまく稼動で

　きたとしても、ソフトウェア開発の起点である要求開発

　の不備を救うことはできない。開発者の比重は、上流工

　程へとシフトし、自社全体の要求開発技術の成熟度を高

　めていく必要がある。

　　とくにステークホルダーの関心事であるユースケース

　記述に関して十分なスキルを身につけておくことが必要

　である。

コンポーネント化、パターン化の推進：

　　実績のある信頼性の高いアーキテクチャー、フレーム

　ワーク、コンポーネントを再利用することで、非機能要

　件の追跡可能性管理は大幅に省力化される。さらに、プ

　ロアクティブなアプローチとして、システムアーキテ

　クチャーのパターン化を行い、これらをターゲットのシ

　ステムにあわせて選択していくことで、追跡可能性管理

　は、業務の実現に集中することができる。

MDADのエンジンの開発：

　　成果物構成、追跡可能性、プロセスを管理するエンジ

　ンを、可能な限り既存のオープンソース、市販パッケー

　ジを使って開発することが望ましい。例えば、プロセス

　エンジンに関しては、カナダOcellus社からMDADのプ

　ロセス管理コンセプトを実現できると思われる製品が既

　に登場している。

また、今日の「高品質、短納期、低価格」というプレッ

シャーに迅速に対応するためには、以上のような品質向上

のための課題と取り組む一方で、生産性向上のための要素

技術をブレークスルーしていかなければならない。

MDAトランスフォーマの開発：

　　本論文でも述べてきたような、UMLモデルto MS-Word

　/XMLのマーク付きモデル変換のように、UMLモデルか

　らプラットフォームのアーキテクチャーに合わせてソー

　スコードを自動生成する各種の変換機（トランスフォー

　マ）を開発することが必要である。

テストの自動化：

　　ソフトウェア開発プロセスのうちもっとも大きなボ

　リュームを占めているテストフェーズを自動化すること

　で、プロジェクト全体の生産性は大幅に向上する。

ソフトウェア開発のための自動化生産ラインとも言える

MDADの実現は、多くの課題を持っているが、今後、オ

フショア開発の実践や先端要素技術の試作・検証をしてい

くにあたって、MDADというコンセプトを共有し、開発

プロセス自動化という共通のゴールを持つことが重要であ

ると考える。


22exa review　No.4（2005）

参考文献

（Web公開資料）

1) OMG、"OMG Model Driven Architecture"、http://www.

　　 omg.org/mda/

2) IBM、"Rational Unified Process"、http://www-306.ibm.

　　 com/software/awdtools/rup/support/

3) OMG、"OMG Unified Modeling Language Specification"、

　　 Version 1.5、2003/03/01.

4) J-M. Comily, M.Belaunde、"Specifying distributed object

　　 applications Using the Reference Model for Open Distributed

　　 Processing And the Unified Modeling Language"、

　　 http://universalis.elibel.tm.fr/publications/edoc99.pdf.

5) Joaquin Miller and Jishnu Mukerji、"MDA Guide

　　 Version 1.0.1"、

　　 http://www.omg.org/docs/omg/03-06-01.pdf、2003/6/12.

6) OMG、"Meta Object Facility(MOF) Specification"、Version 1.4、

　　 http://www.omg.org/docs/formal/02-04-03.pdf、2002/4.

7) Patricio Letelier、"A Framework for Requirements

　　 Traceability in UML-based Projects".

8) OMG、"Software Process Engineering Metamodel

　　 Specification"、Version1.0、

　　 http://www.omg.org/technology/documents/formal/

　　　　　spem.htm、2002/11.

＜問い合わせ先＞

　技術部

　開発技術チーム

　　Tel 044-540-2374　松山圭一

　　E-mail: [email protected]

開発プロセス自動化のためのアーキテクチャーの提案モデル ... ·...

Documents

Transcript of 開発プロセス自動化のためのアーキテクチャーの提案モデル ... ·...

開発プロセス自動化のためのアーキテクチャーの提案 モデル ... ·...

Documents

Transcript of 開発プロセス自動化のためのアーキテクチャーの提案 モデル ... ·...

開発プロセス自動化のためのアーキテクチャーの提案モデル ... ·...

Transcript of 開発プロセス自動化のためのアーキテクチャーの提案モデル ... ·...