RhapsodyはUMLのバージョン2.0に対応しており、以下のダイヤグラムを作成することができる。

　Rhapsodyは上記のダイヤグラムに加えて、フローチャートにも対応する。また上述の製品一覧で“for Systems Engineers”と付いている「システムエンジニアリング版」では、システムエンジニアリング用の標準モデリング言語「SysML」にも対応している。さらに、UMLモデルの標準ファイルフォーマット「XMI」にも対応し、ほかのモデリングツールとのモデル交換も可能である。

　Rhapsodyには画面や製品の操作パネルに相当する「GUI（パネル）」を作成するエディタも付いており、作成したパネルをモデルとリンクさせて利用することも可能だ。ただ、Rhapsodyには「ダイヤグラムを記述するための制約」が幾つかあり、UMLモデルを作成するためのUMLエディタとして使用する際には注意が必要である。この点については後ほどあらためて詳述する。

RhapsodyのPanel Diagramを使用して作成したGUI

　RhapsodyにはUML仕様以外にも、モデル要素の色やフォントの変更、直線や長方形を使って自由に図形を描くことができる「ダイヤグラム作成機能」が備えられている。なお、一部のダイヤグラムでは日本語入力可能だが、基本的には英語のみとなる。メニュー表示やツール自体が使用する表記も英語なので、その点は導入時に考慮する必要があるだろう。

　Rhapsodyで作成したモデルの持つ情報を利用する機能としては「ドキュメント（RTF形式）の生成」「チェックリスト形式によるモデルチェック」「モデルを利用したシミュレーション」などが可能だ。

モデルを利用したソースコードの生成が可能

　Rhapsodyがほかのツールと一線を画す特徴として「モデルを利用したソースコードの生成も可能」なことが挙げられる。

　RhapsodyはJava、C／C++、Ada（※）などのプログラミング言語に対応しており、特にC言語のためのソフトウェア開発標準規格「MISRA-C」のコーディング規約に対応する形でコード生成が可能である。

（※）　Ada：1980年に考案された手続き型のプログラミング言語。米国防総省が同省に納入するソフトウェアの開発をAdaで行うことを指定したため、政府部門や関連産業で利用されていた。

　C言語やMISRA-Cに対応している点は組み込みシステムをメインターゲットとしているこのツールならではだといえる。また、車載システム向け共通ソフトウェアプラットフォーム「AUTOSAR」に対応したコードの生成も可能だ。

差別化ポイントは「MDD」「モデルシミュレーション」

　次に、Rhapsodyのほかのツールとの差別化ポイントを紹介していこう。

MDD（Model Driven Development：モデル駆動型開発）

　これが前述したコード生成に関する、Rhapsodyの大きな特徴の1つだ。Rhapsodyではコード生成だけではなく、ターゲットとなるリアルタイムOS（以下、RTOS）とコンパイラを指定しておけば、クロスコンパイルとビルドまで行える。つまり、モデルの記述から「実行可能な」バイナリの生成までが可能だ。

　また、後述するモデルシミュレーションと合わせることで「モデルを作成し、その動きをシミュレーション機能で確認した後、問題がなければバイナリを生成してターゲットとなる実機上でその動作確認を行う」ことが可能となる。こうした「モデルを中心として開発を行う形態」であるモデル駆動型開発（MDD）は、組み込みシステム開発で主に使われる開発手法だ。

　Rhapsodyでは、コンパイラとターゲットOSの組み合わせを「コンフィギュレーション」として複数登録できる。複数登録しておくと、開発環境用と実機用のそれぞれの実行バイナリを同じモデルから作成したり、デバッグ用とリリース用のビルドを分けたりすることも可能だ。

シーケンス図の比較機能

　実際にMDDを行う場合、「どのような手順と考え方でモデルを作成するか」が重要な問題になる。この点については、I-Logixでオブジェクト指向開発方法論を策定していたブルース・ダグラス氏がRhapsodyの開発にもかかわっていたため、その考え方がRhapsodyには反映されており、かつ書籍としてしてもまとめられている（※）。同氏の著書を参考にしながらモデル作成を進めると自社におけるMDDの導入もしやすいだろう。

（※）『リアルタイムUML』（発行：翔泳社、著：Bruce Douglass、訳：オージス総研、監訳：渡辺博之、2001年）

モデルシミュレーション機能

　Rhapsodyのシミュレーション機能には、Rhapsody上にモデルとして表現されたシステムに対して、イベント入力やその動作をステートマシンのアニメーションやシーケンス図などのログで確認できる。特にシーケンス図については、2つのシーケンス図を比較して、その違いをグラフィカルに表現することも可能だ。

　例えば、「想定される動作を表すシーケンス図」と「実際の動作結果のシーケンス図」を比較して、モデルの誤りを検出できる。また、仕様変更前後のシーケンス図を比較することで、その変更がモデル全体にどのような影響を及ぼすかを確認するという使い方も可能だ。

　さらに、シミュレーションに用いるイベントのリストは記録できるため、モデルに対する回帰テスト環境を構築することも容易である。

　もう1つの特徴として「GUIとの連携」が挙げられる。

　通常の組み込みシステムの開発では、操作パネルを使用した動作シミュレーションを行う場合には「操作パネルのハードウェアを用意する」または「シミュレータ上に仮のGUIを構築し、さらにそれらと接続するためのプログラムを記述する」のどちらかが必要である。それらの環境を用意するにはそれなりの手間が掛かる。

　これがRhapsodyのパネル用エディタでGUIを作成すると、そのGUIとモデルの対応関係を定義するだけで動作確認が行える。GUIを使用してステートマシン図やシーケンス図による動作確認ができるため、実機がなくてもモデル上でかなりの部分の動作確認が可能だ。これは開発早期からの検証を可能にするため、通常の開発と比較してその部分の工数を削減することができる。

　モデリングツールの中にはモデルの作成やコード生成はできるが、「実際にモデルを動かして動作を確認できる」というツールは少ない。さらに、シーケンス図の比較などといった「モデルの動作結果を確認するための機能を備えている」ものはさらに少なくなる。この点はRhapsodyとほかのモデリングツールとの大きな差別化ポイントだといえる。

Rhapsody使用時に気を付けること

　次にRhapsodyの課題ともいえる点を考える。

表記法の混在

　まずは挙げられるのは「Rhapsody内でUMLの表記法が混在している」ことである。前述のUMLのダイヤグラムの対応状況の表にも記載しているが、Rhapsodyでは、コラボレーション図に代表されるようにUML1.5時代のダイヤグラム名が残っている。また、ダイヤグラムの中には、ステートマシンを持っているクラスを表すアイコンなど、Rhapsody独自の表記も登場する。そのため、UML初心者から見た場合に「UML2.0で定義されている」ものがどれか分かりづらいこともある。

　さらに「インスタンス間に継承関係が引けてしまう」といったUMLの表記ルールとしては許されていない記述もできてしまう。そのため、UML資格試験対策のように「UMLを正確に覚える必要がある」際は、Rhapsodyを使用していると混乱を招きやすい。また、Rhapsodyからそれ以外のツールに移行したときに用語や表記の違いが影響することも考えられるので、その点を注意する必要がある。

ダイヤグラム作成時の制約

　これは実行可能なソフトウェアを生成できることの裏返しとなっている部分であるが、Rhapsodyではダイヤグラムの役割やその間の対応関係をある程度限定することで、実行可能なレベルのソースコードの生成を行っている。そのため、ユーザーがダイヤグラムを自由に作れないことがある。

　例えば「ステートマシン図は何らかのクラスに対応していなければならないし、アクティビティ図は何らかのオペレーション（クラスの持つ操作）に対応していなければならない」といったことが挙げられる。つまり、ステートマシン図やアクティビティ図を単独で書くことはできないのである。

　この制約は、ソースコードの生成にこだわらずにUMLのダイヤグラムを作るような「UMLエディタ」として使用したときに発生しやすい問題だ。特に、分析モデリングのように自由にモデルを作成したいときには、ダミーのクラスを作るといった回避策を取る必要が出てくる。

MDDの推進を支援する有効なツール

　実際、Rhapsodyを使用したプロジェクトのコンサルティングを幾つか経験しているが、その生産性の高さに驚かされることも多く、MDDの推進を支援する有効なツールである。日本語対応の問題やコード生成ルールの理解などの点もあるが「UMLからのコード自動生成を検討しているのであれば、Rhapsodyはその現実的な選択肢の1つとなる」といえるだろう。