各制御対象となるオブジェクトを抽出した。このオブジェクトを<<entity>>ステレオタイプとした。
次に、制御対象を取り扱うアルゴリズム（仕様）を<<spec>>ステレオタイプとして抽出した。
エンティティ分析を行ううえで、ドメイン間で重複するエンティティや新たに追加したエンティティが、機能要求とどのような関係を持っているか理解するため、エンティティと機能要求との関係表を作成した。

手順：エンティティ分析

　エンティティ分析で得られたものは、

エンティティを中心としたクラス図
エンティティとクラス（ドメイン）との関係表

となります。

　ドメイン定義のところで触れたように、ドメイン定義でプリエンティティ分析を行いましたので、このエンティティ分析ではその結果をレビューするような意味合いも持ちました。ドメイン定義で洗い出した必要な知識や、ドメイン同士で互いに利用するエンティティを確認し、ドメイン構造図の線引きが正しいかを確認することなどが、ここでのエンティティ分析では重要となりました。

図6　エンティティ分析のイメージサンプル（属性、メソッドなどは省略）
掲載している図は分析対象の異なる例をサンプルとしているため、ほかの図との関連性は持たせていません

オブジェクト構造分析

　オブジェクト構造分析では、エンティティ分析で得られたクラス図に、ユースケースを実現するのに必要なクラスを追加します。追加するのは、ステレオタイプが<<control>>のクラス、<<interface>>のクラスなどです。そして、クラス間の関連を多重度も含めて整理します。

　オブジェクト構造分析で、実際にした作業は次のとおりです。まずは、サブシステムごとに1、2を実施します。

ユースケースごとにクラス図を作成し、そこにユースケースを実現するために必要と思われる<<control>>や<<interface>>などをクラスとして追加した。
クラス間の関連を図に追加した。この際、下記のように線種を変えて関連の種類を明示した。
　→ドメイン外部インターフェイス<<interface>>との情報のやりとりは、依存関係ととらえ、点線矢印で表す。
　→ドメイン内部の制御<<control>>同士やエンティティ<<entity>>との情報のやりとり、および仕様<<spec>>参照は、関連ととらえ、実線で表す。
サブシステムごとに得られたクラスの整合性を検証した。

手順：オブジェクト構造分析

　2の時点で、外部からの要求や命令などのトリガを表す<<interface>>クラスについては、この時点でどこから来るのか未決定のものが登場しました。これらについてはサブシステム内だけで名称を決定できないので、ここでの分析作業の際には「unknown」クラスとしておき、3で名称や役割を明確化することにしました。

　ところが、いくつかの「unknown」クラスはこの時点ではトリガの方向性などを決定できないことが判明しました。その主な原因は、制御の方向性やインターフェイスで伝達される内容が、後のアーキテクチャ設計やアーキテクチャメカニズム設計を待たないと決定できないためでした。このようなケースについては、ここの段階では「unknown」クラスのまま残しておくことにしました。

　さて、ここで得られた結果を1枚のクラス図にまとめた方がよいでしょうか。分科会のグループメンバー間で、得られたクラス図を並べて1枚にまとめることを検討した結果、

<<control>>クラス同士が結び付いてしまい、混乱を来すことがある
クラス図を統合する際に、どうクラスをまとめるかはハードウェア／ソフトウェア分割などと独立には決められない
ユースケースと<<control>>クラスや<<interface>>クラスなどとの関連が把握しにくくなる

などの課題があると判断し、ここでは無理にまとめる必要はないとの結論に達しています。

　こうしてオブジェクト構造分析で得られたものは、

<<control>>／<<interface>>クラスが明記された、サブシステムごと／ユースケースごとのクラス図

となります。

　このオブジェクト構造分析によって、ユースケース分析では出てこなかった、ほかのドメイン（あるいは外部）とのインターフェイスが洗い出されます。また、そのインターフェイスの分析、例えばどことのどのようなインターフェイスなのかの定義の明確化が進み、UMLを使用したことの有効性を実感できるはずです。

　作業の進め方やダイヤグラムの描き方については通常のeUMLとの差異は特にありませんが、唯一異なるのが先ほど説明した「unknown」クラスを導入したこととその扱いです。通常eUMLで提示されているサンプルシステムではハードウェア／ソフトウェア間インターフェイスが決定済みのものですが、未確定のシステムを扱おうとした場合には同じようなクラスを導入せざるを得ないのではないかと思われます。

図7　オブジェクト構造分析のイメージサンプル（属性、メソッドなどは省略）

システムビヘイビア分析

　システムビヘイビア分析は、SoC内部の複雑さを把握するために（ユースケースでは主に外部から見た機能要求に着目しているのに対し）並列性と順序性を確認することが目的となります。ここでの作業は、SoC内部のビヘイビアを状態図、もしくはアクティビティ図やシーケンス図を使用して記述します。いずれの図を用いるかは、システムの特性や必要性により判断することになります。イベント駆動を表現するならば状態図、シーケンスを表現したいのであれば、アクティビティ図やシーケンス図を採用するなどとなります。

　このアクティビティ図とシーケンス図は補完し合う意味もあります。アクティビティ図を用いて並列性を見つけだし、シーケンス図でどのように並列処理を実現するかを洗い出すことができます。

　システムビヘイビア分析での、アクティビティ図を作成する場合の実際の作業は、次のとおりです。

あるユースケースに着目して、この内部のビヘイビアをアクティビティ図を用いて表現した。アクティビティ図のレーンは、SoC全体を中心に置き、ユースケースに関係するサブシステムまたはクラスとした。
各レーンにおける処理順序を仮定して、内部の処理の並列、順序列を表現した。各レーン中での処理の記述単位は、オブジェクト構造分析の結果などを用いた。
最後に、各レーンをまたいだ処理順序を表現した。

手順：システムビヘイビア分析

　システムビヘイビア分析で得られたものは、

状態図
シーケンス図
アクティビティ図

となります。

　ここでは、必ずしもすべてのユースケースを分析する必要はありません。中身の明白なユースケースではなく、詳細が分かりにくいユースケースを取り上げて分析を進めるのがよいと考えます。ただし、できる限りユースケース間の並列性、順序性の分析はここで行っておいた方がよいというのが、分科会で得られた見解です。

　また、デジタルカメラの連写時の画像複数枚処理については、システムビヘイビア分析での検討項目ではないということになりました。画像が1枚の場合と複数枚の場合の処理や単位の区切りの検討は、後の工程、具体的にはアーキテクチャの検討（アーキテクチャメカニズム設計）でする方が適していると判断したためです。

　このほか、システムビヘイビア分析では、並列性や順序性を表現するため、処理の記述単位を抽出することだけより、通常のeUMLと比べても知識を必要とする作業ではないかとの意見が挙がりました。

図8　システムビヘイビア分析でのアクティビティ図のイメージサンプル

オブジェクトコラボレーション分析

　オブジェクトコラボレーション分析では、エンティティ分析、およびオブジェクト構造分析で得られた静的な構造を表すクラスに動的な責務を割り当てることが目的となります。ただし、オブジェクトコラボレーション分析だけですべての動的な振る舞いを表現することは難しいと思われます。ここでの分析の結果は、コラボレーション図またはシーケンス図で表します。

　オブジェクトコラボレーション分析で、実際にした作業は次のとおりです。

オブジェクト構造分析におけるあるシナリオ（例えば“信号処理をする”というシナリオ）に着目して、コラボレーション図またはシーケンス図を用いて表現した。主な作業は、メッセージの順番と内容を記述することとなった。

手順：オブジェクトコラボレーション分析

　このコラボレーション図またはシーケンス図には、オブジェクト構造分析のサブシステムに登場したすべてのクラスを配置して考えました。そして、クラス間と、クラスとサブシステム間のメッセージの順番、およびメッセージの内容を記述して、クラスに動的な責務を割り当てています。

　また、クラスの中で、これまでのステレオタイプを見直し、SoC用に適したものにできないかどうかの検討を行いました。UMLにはステレオタイプ名に厳密な決まりがありませんが、慣例として用いられているものがあります。分科会の結論として、ここでは、例えば<<control>>のステレオタイプを用いずに<<process>>というステレオタイプを導入しました。

　オブジェクトコラボレーション分析では、どこからどこにメッセージを送るのかの、流れを決定する作業です。この分析は、アーキテクチャ分析と同時に分析を進めるか、たたき台としての仮アーキテクチャを決めないことには分析が難しくなります。もし、この段階で、まったくアーキテクチャが決まっていない状態であれば、ここでオブジェクトコラボレーション分析の作業に時間を費やし過ぎない方がよいという見解が得られました。

図9　オブジェクトコラボレーション分析のイメージサンプル

おわりに

　UMLによるシステム要求分析での作業は、これまで紹介したものにとどまることなく、アーキテクチャ設計工程、アーキテクチャメカニズム設計工程、設計工程、実装工程、理想的には検証工程へとつながることが最終的な目標となってきます。しかし、第1回で塚田氏が紹介したようにUMLを初期の工程から導入し、要求分析をしておくことだけでも可読性の向上や開発者間のコミュニケーションの向上など、多くの利点が期待できます。

　つまり、UMLの適用度合いにかかわらずUMLをSoC開発に利用していくことには大いに意味があると考えています。そのためには、解決すべき課題がまだありますし、適用を進めていくためのノウハウが重要となります。本記事では紹介できませんでしたが、現在の分科会では、本記事の始めに紹介した目標設定に対する議論を続けており、1つの結論を得られる段階になってきています。UMTP SoC分科会では、引き続きSoC開発にUMLの適用を推進するための活動を行っています。

　ここで、UMLにこだわる必要があるのだろうかという疑問をお持ちの方も多いと思いますが、それは分科会でも認識しています。それは先にも述べたように、UMLだけで完結しようなどとは思わず、UMLは必要に応じて利用しながら、ガイドラインやテンプレートといったUMLを補完するような技術が必要であるという認識を持って活動をしています。（連載完）