　次に、前節のシーケンス図をコラボレーション図として表現しました（図10、図11）。シーケンス図と同様にモジュール間のメッセージの流れを一目で見ることができます。また、コラボレーション図はハードウェア構成を表現するブロック図に近いため、ハードウェアのイメージを得ることができます。加えて、モジュール間の関係を分析することもできました。ただし、シーケンス図と同様、パイプライン的な並列動作の表現は困難でした。

図10　ライトアクセスのコラボレーション図

図11　リードアクセスのコラボレーション図

　また、グループ内で複数のマスタ／スレーブ動作を表現したい、という意見があったため、コラボレーション図で記述を試みました。図12のようにスレーブやマスタを個別に書いた場合、かなり煩雑になり表現が難しい結果となりました。しかし「このような、よりブロック図に近いデザインは、実物に近いものとして書かないと詳細な分析（検証項目などの分析など）ができないのでは」という議論がありました。

図12　複数のマスタ／スレーブ動作の表現を試みて失敗した例
このように複数マスタ／スレーブになると、メッセージの順番は表現できない

コラボレーション図利用のまとめ

【利点】

メッセージ（データ）の流れが見やすい
モジュール間の関係が見えてくる

【注意すべき点】

パイプライン（並列）動作が表現しにくい
波形で書くようなクロックサイクルベースの詳細なタイミングは見えない

状態図

　シーケンス図で示した動作の流れを状態遷移として表現する状態図を作成しました。UMLにおいても、基本的に状態の遷移を表現するための表記法を使用するだけで、ハードウェア設計において書かれる状態遷移図と大きな差はありません。よって、UMLの状態図を仕様書上で使う利点は、統一した表記法であると感じます。

　ここでは状態図を書くに当たり、イベント／条件と状態を明確にすることと、バースト転送は“転送”状態の繰り返しであることにポイントを絞り、図を作成しました（図13）。

図13　状態図1（マスタの状態遷移）
・バス権待ちはアービタからバス権を獲得するまでの状態
・転送はアドレスフェイズとデータフェイズからなる
・バースト転送の場合、転送状態を繰り返す
・バースト転送が完了した場合、バス権がはく奪された場合、エラー応答を受けた場合に転送を終了する

　図13では、バースト転送時に次の転送のアドレスフェイズと現在のデータフェイズが同じクロックサイクルで重なるため、若干、違和感のある状態図となりました。そこで、この問題点を考慮して状態図を修正しました（図14）。

図14　状態図2
アドレスフェイズとデータフェイズが同時に成立している状態を“転送”状態に追加した

　アドレスとデータフェイズが同時に成立している状態を加え、“転送”状態の中にバースト転送を考慮した表現にしました。これで図1の問題点はクリアされましたが、複数段のパイプライン動作が必要な場合、このような書き方をすると、状態の数が爆発的に増える可能性があります。ここでもやはり、パイプライン動作の記述が問題になり、記述方法に注意が必要であることが分かりました。

状態図利用のまとめ

【利点】

統一した表記で状態図を書くことができる
状態を定義して明確化するため動作が把握しやすい

【注意すべき点】

パイプラインであることを状態遷移図で明示しにくい
パイプラインが複数段あった場合、状態の数が爆発的に増える

遷移表

　ここでは、UMLから作成したモデルから検証項目の抽出の可能性を検討するため、前節で作成した2つの状態図から遷移表の作成を行いました。遷移表はUML表記ではありませんが、状態図から派生させたものから検証項目の抽出の可能性を検討してみました（表1）。

表1　状態図1の遷移表

　状態図1から起こした遷移表では、アドレスフェイズとデータフェイズの遷移先が2つあるため、表が明確になりません。これは、アドレスフェイズとデータフェイズのパイプラインがうまく表現できなかったためです。

　状態図2から起こした遷移表（表2）では、アドレスフェイズとデータフェイズが同じクロックサイクルで成立する状態を追加したため、表1のような1つの条件に対して複数の遷移先が存在することはありません。

表2　状態図2の遷移表

　このようにUMLで分析／定義した状態に対して、入力／出力の組み合わせを検討すれば、それなりの検証項目を抽出することが可能であるというところまでは見えてきました。

　しかし、動作の競合やコーナーケースに対する検証項目の抽出を考えた場合、遷移表から検討することは困難です。加えて、UML記述でパイプラインや複数マスタの動作をうまく分析する手段が見つからないため（当グループのスキル不足かもしれませんが……）、現状としては、UMLから動作の競合やコーナーケースに対する検証項目を抽出することは困難であると考えています。

　また、グループ内では「UMLから検証項目を拾うというよりも、予想されるコーナーケースをUMLで分析するというやり方の方が正しいかもしれない」という意見がありました。ただし、予想されるコーナーケースが数多くあった場合、手に負えなくなるため、UMLを利用した検証項目の抽出という課題に対しては、まだまだ検討が必要です。

まとめ（今後の課題）

　今回の活動では、実際のモデルをUMLで記述することによって、整理した表現ができることを確認し、実際の仕様書への適用の可能性を模索しました。そしてこの活動をとおして、UMLをハードウェア設計に適用することで、要求仕様や機能仕様、検証仕様の可読性を上げるための糸口が見えてきました。

　ハードウェア設計におけるUMLの利点としては、統一された表記で表現された図を多用することで複雑な動作を視覚的に表現できることです。視覚的に表現することは、文書の理解を早め、早期に問題点を洗い出すことにつながっていくはずです。また、統一された表記を用いることで、表現のバラつきを抑えることにつながるでしょう。また、仕様書だけにUMLを利用するのではなく、さらにモデルを分析／詳細化していくことで、RTLレベルの設計へ援用も可能です。さらに、今回の活動の中で、UML図を書きながら議論したため、議論が活発にできたという実感もありました。これは実業務において、レビュー効果の促進にもつながると思います。

ハードウェア設計における仕様書へのUML適用の利点

図を多用することで、複雑なハードウェア動作を視覚的に表現できる
各種UML表記を利用することで、統一した表現ができる
RTLレベルの分析／設計への援用も可能
議論が活発になり、レビュー効率の促進につながる

　また、今回実際に使われているモデルを検討することで、ハードウェア設計に対するUML利用法の課題が見えてきました。ハードウェア設計では、パイプライン処理が多用されるため、この表現を克服することは大きな課題であると考えます。次に、分析段階において、複数のモジュールが一斉に動作した場合の表現方法の解決策が見えてくると、ハードウェア設計にUML適用のメリットが大きくなると思われます。

ハードウェア設計における仕様書へのUML適用の課題

パイプラインの表現に対する解決策が必要
複数マスタ・スレーブが一斉に動作したケースなどの表現方法の検討が必要
UMLと非UML表現を明確化

　今回の活動ではUMLと非UML表現を明確化するまでには至りませんでした。ハードウェアのどのような部分にUMLを適用するのがよいのか、UMLで表現が困難な部分をどのように表現するのかを含め、まだまだ検討と議論が必要であると感じています。今後はこれらの課題の解決に加えて、UMLを使った設計フローの構築について検討を行っていきたいと考えています。（次回に続く）