UMLによるSoCシステム要求分析の可能性：SoC設計にモデリング手法を導入する（4）（2/4 ページ）

[余宮尚志（東芝），＠IT MONOist]

試行フロー（トライアルフロー）

　システム要求分析に利用できるUMLダイヤグラムとして、一番に何を想像されるでしょうか。最初に挙げられるのが、ユースケース図であり、ユースケースシナリオ（これはUMLの正式な表記法としては定義されていないものですが、広く用いられているもの）です。分科会での実際のモデリングでも、このユースケース図、ユースケースシナリオの作成から分析を開始しました。

　成果物の流れを意識した試行フローを図2で紹介します。このフローは、eUMLをベースにシステム要求分析にかかわる部分だけを抽出したもので、成果物の流れを矢印で示しています。モデリングも、一部の例外はあるものの、ほぼこの成果物の流れの順序で進みます。このフローは、eUMLの書籍・雑誌などでも紹介され、組み込みUMLの要求分析において比較的標準的に用いられているものといえます。

図2　試行フロー（トライアルフロー）図
これはeUMLベースの試行フローで、分科会で提案するフローとは別です

　システム概要の記述、アーキテクチャ要求分析はこれまでにも触れましたので、ここではひとまず省略します。

　要求分析工程に入る前の方向付け工程の中に、モデリング方向性の決定があります。ここでは、システム概要の記述の後に、問題領域の把握をしています。この問題領域の把握は、モデリングする対象範囲を発散させないために必要で、モデリングに携わる開発者間の意識合わせができます。そのため、モデリング方向性の決定では、モデリングの結果そのものが成果物というわけではありません。

　ここでは、実際には以下の作業を行いました。

1. 「デジタルカメラ」のステートチャート図を作成し、処理の一連の流れをつかんだ。
2. システムビヘイビア分析：1で作成したステートチャート図の、おのおのの状態での処理工程をアクティビティ図で記述した。
3. ドメインチャート分析：ある程度決定している「デジタルカメラに使用される画像処理用SoC」のドメインを洗い出し、クラス図（ドメインチャート図）で相互関係を明確にした（2と3は同時に進めてもよい）。
4. ユースケースドメインマッピング：要求仕様からユースケースおよびアクタを洗い出し、3で洗い出したドメインにマッピングした（3のドメインチャート図を詳細化する）。
5. ドメインコラボレーション分析：「撮影する」という処理のコラボレーション図を作成、おのおののドメインの役割と処理の流れを明確にした。ドメインマッピングの「言葉」で記述し、おかしな個所は4と5の図を互いに修正した。
6. ドメインマッピングとコラボレーションを相互分析した。
7. 4 ⇔ 5を繰り返し、文言の修正や処理の過不足の確認をした。

　手順：問題領域の把握

　この問題領域の把握は、その目的からあまり時間をかけずに進みました。ドメインは、撮影ドメイン、ユーザーインターフェイスドメイン、撮影メカニズムドメイン、デバイスドメインに分けるなど、eUMLの慣例に従っています。

　問題領域の把握のための作業結果と、これ以上の詳細は省略しますが、トライアル的な意味合いの強い作業であることが分かっていただけると思います。

図3　4. の結果（ユースケースドメインマッピング）のサンプル

モデリング（要求分析工程）

ユースケース分析

　モデリングの方向性が決定されたと仮定して、次に実際に要求分析〜分析の工程へと進みます。先ほど述べたように、まずはユースケース図、ユースケースシナリオを作成しました。

　図4は、ユースケース図のサンプルです。また、ユースケースシナリオはここでは省略します。

図4　ユースケース図のサンプル
この図は3つの異なるユースケース図をまとめています。図中の3色は、3つの異なるユースケース図のどこのユースケースだったのかを分かりやすく色分けしたものです

　このユースケース図の目的は、アクタを定義し、アクタから見えるシステムの機能を漏れなく抽出し、定義することです。この図を見ていただいて気付かれたと思いますが、通常のeUMLのユースケース図と異なるのは、次の2点です。

• アクタとユースケースの関連を方向付けることで、データの流れを明確にしていること
• ユースケースにナンバリングしていること

　ユースケースでは、やはり表現する粒度を統一することが問題となりました。ここでは、アクタやデータの流れを明確にすることで、そのアクタが利用すべきユースケース、機能も明確となり、粒度をそろえたユースケースの分割が可能となりました。

　ユースケースにナンバリングしたのは、実はサブシステム分割の際に得られたノウハウです。ユースケースにナンバリングしていないと、後のドメインとユースケースの対応付けの認識が、モデリングをする開発者間でずれるケースがありました。ユースケースにナンバリングすれば、それを使ってドメインとの対応を明示することが容易になります。

アーキテクチャ要求分析

　ユースケース分析と並行してアーキテクチャ要求分析を行いました。アーキテクチャ要求分析は、非機能要求をまとめる作業といえます。先にも紹介した非機能要求ですが、分科会でも、SoC開発におけるモデリングにおいて非機能要求をどのように扱えばよいのかは議論となりました。

　その結果、結論は先送りして後に再度議論することにし、ここでは非機能要求をまとめるためのドキュメント・フォーマットを用意して、それに非機能要求を漏れなく、できるだけ正確に残すことにしました。

　テンプレート化した非機能要求をまとめるためのドキュメント・フォーマットを用意することだけでも、リストアップする項目に漏れが生じにくく、正確に文書を残すことができますし、可読性や再利用性も高まると考えました。

　実際の開発では、アーキテクチャ要求分析の段階で判明していない機能、抽出されにくい機能もあります。ドキュメント・フォーマットがあることで、ボトムアップ的な補充や見直しもしやすくなると考えたのです。

　さて、この後はドメイン定義などの分析工程に入ります。先に紹介した試行フローの各分析の中身は、書籍・雑誌などで通常紹介されているeUMLとは異なる工夫をしているところが多々あります。また、試行フローでのeUMLとは異なるプロセスの検討も行っています。これはSoC開発にUMLを適用するうえでのノウハウとなるところですが、この場では現段階で明らかにできない事情があるものや、まだ十分に議論が尽くされておらず検討・検証できていないところもありますので、ここではほんの一部を紹介するにとどめさせていただきます。