Loading article…
実行可能 UML ( xtUMLまたはxUML ) は、ソフトウェア開発手法であると同時に、高度に抽象的なソフトウェア言語でもあります。これは、2002 年に「Executable UML: A Foundation for Model-Driven Architecture」という書籍で初めて説明されました。[ 1 ]この言語は、「UML ( Unified Modeling Language )のグラフィカル表記法のサブセットと、実行可能な意味論およびタイミング規則を組み合わせたもの」です。[ 2 ]実行可能 UML 手法は、 Shlaer–Mellor 手法の後継です。[ 3 ]
実行可能な UML モデルは「実行、テスト、デバッグ、およびパフォーマンスの測定が可能」であり、[ 4 ]特定の実装を対象とする、より抽象度の低いプログラミング言語にコンパイルできます。[ 5 ] 実行可能な UML は、プラットフォームに依存しないモデルの仕様と、プラットフォームに依存しないモデルをプラットフォーム固有のモデルにコンパイルすることによって、モデル駆動型アーキテクチャ(MDA) をサポートします。[ 6 ] [ 7 ]
実行可能な UML は、第 3 世代のプログラミング言語よりも高いレベルの抽象化です。これにより、開発者はアプリケーションの抽象化レベルで開発できます。[ 8 ]実行可能な UML は関心の分離を目指しています。これにより、再利用性が向上し、ソフトウェア開発のコストが削減されるはずです。また、これにより、実行可能な UML ドメインはクロス プラットフォームになります。つまり、特定のプログラミング言語、プラットフォーム、またはテクノロジーに縛られません。
実行可能なUMLは、プラットフォーム非依存モデル（PIM）をプラットフォーム固有モデル（PSM）に変換することも可能にします。実行可能なUML手法を用いることで、モデルを知的財産として評価することが可能になります。なぜなら、そのモデルは問題領域に対する完全に実行可能なソリューションだからです。
アクションはアクション言語で指定されます。つまり、実行可能なUMLモデルから実装コードを自動生成し、最適化された形式で出力することができます。
実行可能なUMLは、ドキュメントとしてだけでなく、実行可能なコードとしても機能するように設計されています。モデルは、問題領域のグラフィカルな実行可能な仕様であり、ターゲット実装にコンパイルされます。また、人間が読みやすいように設計されている点も重要です。
システムは、実行可能UMLの用語でドメインと呼ばれる複数の対象物から構成されます。実行可能UMLは、実装上の懸念事項とは無関係に、対象物の抽象化レベルでドメインをモデル化するために使用されます。結果として得られるドメインモデルは、次の要素で表されます。
実行可能な UML では、システムのドメイン (アスペクト[ 9 ]または関心事とも呼ばれる) を識別する必要があります。「各ドメインは、概念的な実体が存在する自律的な世界です」 [ 10 ]。各ドメインは、システム内の他のドメインとは独立してモデル化できるため、関心事の分離が可能になります。例として、自動預け払い機システムのドメインには、次のものが含まれる場合があります。
関心の分離により、各ドメインは、それぞれのドメインの専門家によって、システム内の他のドメインとは独立して開発および検証することが可能になります。
ドメイン間の接続はブリッジと呼ばれます。「ブリッジとは、ドメイン間の階層的な依存関係です」[ 11 ] 。これは、ドメインが他のドメインに要件を課すことができることを意味します。ブリッジは、異なるドメインの専門家によって合意されることが推奨されます。
ドメインは、既に存在し、モデル化する必要がないことを示すために、 「実現済み」としてマークすることができます。たとえば、MySQLデータベースを使用するデータアクセスドメインは、「実現済み」としてマークされます。
モデル化対象のドメインに固有の、具体的な物、役割、出来事、相互作用、仕様などの概念的な実体は、クラスに抽象化されます。クラスは属性と操作を持つことができます。
これらのクラス間の関係は、関連付けと一般化によって示されます。関連付けは、関連付けクラスとしてさらに抽象化する必要がある場合があります。
クラス図に対する制約は、アクション言語とオブジェクト制約言語（OCL）の両方で記述できます。
実行可能UMLメソッドは、実行可能UMLクラス図で使用できるUML要素を制限します。
実行可能なUMLクラス図は、ドメインに関する情報を明らかにするためのものです。ステートチャート図が過度に複雑になっている場合は、クラス図を修正する必要があることを示す良い指標となります。
クラスにはライフサイクルがあり、実行可能なUMLではステートチャート図を用いてモデル化されます。ステートチャート図は、クラスの振る舞いを定義する状態、遷移、イベント、および手順を定義します。
各状態には、その状態への移行時に実行される手続きが1つだけ存在する。手続きは、アクション言語で指定されたアクションで構成される。
クラスモデルと状態モデルだけでは、ドメインの静的なビューしか提供できません。実行可能なモデルを実現するには、クラスインスタンスの作成、関連付けの確立、属性に対する操作の実行、状態イベントの呼び出しなどを行う方法が必要です。実行可能なUMLでは、UMLアクションセマンティクスに準拠したアクション言語を使用してこれを実現します。
アクションセマンティクスは 2001 年に UML 仕様に追加されました。アクションセマンティクス RFP は、Shlaer–Mellor メソッドをサポートするアクション言語に関する以前の作業に基づいています。既存のアクション言語には、Object Action Language (OAL)、Shlaer–Mellor Action Language (SMALL)、Action Specification Language (ASL)、Model Action Specification Language (MASL)、[ 12 ] That Action Language (TALL)、Starr's Concise Relational Action Language (SCRALL)、Platform-independent Action Language (PAL)、および PathMATE Action Language (PAL) があります。SCRALL は、グラフィカルなアクション言語である唯一のものです。
ドメインがモデル化されると、そのモデルを実行することで、ターゲット実装とは独立してテストできます。各ドメインは、他のドメインとは独立して検証および妥当性確認を行うことができます。これにより、検出されたエラーをドメインに関連付け、他のシステム上の問題とは切り離すことができます。
検証には、関連分野の専門家によるモデルの人的レビューや、実行可能UMLセマンティクスの自動チェックなどが含まれます。つまり、実行可能UMLモデルが実行可能UMLメタモデルに準拠しているかどうかをチェックします。
検証では通常、実行可能なUMLツールを使用してモデルを実行します。実行は、モデルのコンパイル前またはコンパイル後に行うことができます。
ターゲット実装上で実行できるようにするためには、ドメインモデルをより抽象度の低い形式に変換する必要があります。この変換プロセスはモデルコンパイルと呼ばれます。ほとんどのモデルコンパイラは既知のプログラミング言語を対象としています。これは、既存のコンパイラ技術を再利用できるためです。
ターゲット実装の理由からドメインモデルを最適化すると、抽象化レベルが低下し、ドメイン独立性が損なわれ、再利用コストが増加します。実行可能なUMLでは、最適化はモデルコンパイラによって自動的に、またはマーキングによって行われます。マーキングにより、特定のモデル要素を特定の低レベル実装の対象とすることができ、オブジェクトのコレクションを二重リンクリストとして実装するなど、より広範なアーキテクチャ上の決定が可能になります。
MDA の用語では、モデルコンパイラがPSMを作成します。実行可能な UML における PIM とPSMの分離により、モデルの往復エンジニアリングが不可能になり、PSMの変更が抑制されます。[ 13 ]
実行可能UMLは、UMLのサブセットに対する実行セマンティクスを定義します。実行可能UMLサブセットの主な側面は以下のとおりです。
オブジェクト管理グループは、実行可能UMLの影響を強く受けた基礎UML（fUML）を標準化しました。
基礎UML用アクション言語（ALF）[ 15 ]は、オブジェクト管理グループによる標準アクション言語仕様です。