　現実には分析、設計、実装、評価などすべてのプロセスを実行する時間はないので、過去にJPEGのHW／SW分割の評価を行ったグループメンバーから評価データを提供してもらいました。これによりUMLで分析モデルを作成し、いくつかの分割パターンを抽出して分割を決定しさえすれば、設計、実装を行わずに評価（パフォーマンス）解析結果を得られます。当然、最初から評価結果を知らされて分析を行ったのでは意味がないので、分析が完了するまで評価結果はメンバーには伏せて進めました。

　今回の題材であるJPEGの仕様は一般に公開されており、仕様を決定するというより仕様を把握する作業になります。例えば、デジタルカメラの開発を行うと仮定した場合、デジタルカメラの仕様を決定する際に圧縮／拡大に何を使用するかを決定する必要があり、JPEG部分の開発を行うフェイズでは、仕様書が渡されることになります。つまりここでは、仕様の把握を行うことが目的となります。仕様フェイズについては「システム要求分析グループ」が活動を行っています。詳しくは第4回の「システム要求分析グループ」の活動報告を参照してください。

分析モデルの作成

　次に分析モデルの作成ですが、ここではHW／SW分割を目的として作成しています。単に分析モデルといっても、何を目的にするかなど指針が定まっていないと、見当違いのモデルになってしまう危険性があります。今回は、次のフェイズでHW／SW分割を行うという目的のためのモデルになります。

　分割のためには並行性分析、パイプライン分析を行います。そのためのモデルを作成することを意識してモデリングします。ここで1つ注目してほしいのは「エンティティ分析」です。UMLの手法書ではオブジェクト分析としてエンティティ（属性）と振る舞い（操作）を一緒に分析する手法も紹介されていますが、ここではあえてエンティティ分析として1つの分析としました。題材がJPEGだから有効だったのかもしれませんが、ハード化のための分析を考えた場合でも有効であるといえます。ドメイン分析を行い、直交変換や色変換などとJPEGとのかかわりを明確にし、そのJPEG部分の分析においては、

エンティティ分析
オブジェクト構造分析
ドメインユースケース分析
システムビヘイビア分析
オブジェクトコラボレーション分析
オブジェクトビヘイビア分析

を行いました。分割した結果を洗練するために再度分析作業を繰り返し、スパイラル型の開発を行いました。開発においては、メンバー各自が宿題を持ち帰り、1カ月に1度のレビューを行いながら進めていくという作業を繰り返しましたが、通常業務に追われて作業が行えない期間もあり、最終的な現段階モデルを作成するまでに膨大な時間を費やしました。ただ、UMLを使用するメリットとして、UMLという認識を共有できるモデルを使用してレビューできるため、認識のずれは少なくて済みました。

　以下にドメイン図、クラス図、シーケンス図、コラボレーション図、状態図として、作成されたモデルを記します。1つ1つのモデルは、1つの目的を持って表現しているものなので、それらを合わせて参照すれば何を表現したものなのか、理解できると思います。

図2　完成した分析モデル

HW／SW分割に着手

　前述までの工程で分析モデルを作成しましたが、モデルを作成することは目的ではなく、あくまでHW／SW分割が目的です。つまり、この工程が重要になります。まずは、分割の種類（パターン）について議論しました。以下にクラス図を基に何を単位に分割を行うか、その単位を記します。

ドメイン単位
サブシステム単位
クラス単位
インスタンス単位
状態単位
ステートとアクション間

　UMLを使用して分析モデルを作成したことにより、分割パターンが無限に存在することが分かりました。これは1つの成果といえるかもしれませんが、UMLが勝手に最適な分割を示してくれるわけではありません。つまりUMLを使用しても、やはりユーザー自身で分割を行わなくてはならず、分割する人の指針／方針を明確にすることが重要です。そしてこれは最終的な評価結果につながる重要なポイントです。

　また、ここでは分割を行うための分析を行いました。機能を実現するための分析ではなく、あくまで分割を行うために必要な分析を行います。ここで行った分析を以下に記します。

並行性分析
　並行処理可能な機能の分析
パイプライン分析
　パイプライン処理可能な分析
パフォーマンス分析
　時間、面積など非機能要求を達成するための分析

　並行性分析、パイプライン分析などについては、シーケンス図などの動的モデルを参照し、ループ（loop）表現の部分に着目するなど、UMLのモデルを参照することで着目ポイントの絞り込みが可能となり、UMLが有効であるといえます。

　JPEGはあまり大きいモデルではありませんが、大きいモデルの分析を行う場合、並行性分析、パイプライン分析を行うための候補として、UMLは有効であると思われます。ただあくまでも候補であり、それが有効か無効かの判断はユーザー自身が行う必要があることは忘れないでください。

　そして、分析モデルを作成する際にも、並行性分析、パイプライン分析を意識してモデリングすることが重要です。何を目的としたモデルかでモデルは大きく違ってきます。今回は責務を分けて詳しく理解するために、分析モデルとHW／SW分割の2つのフェイズにあえて分けて考えていますが、本来1つのフェイズとしてもよいでしょう。

　そしていよいよ、アクティビティ図、シーケンス図などを使用して分析を試みました。並行性を表現するため、アクティビティ図、パイプラインアクティビティ図などの表現を検討しました。しかしながら今回は、UMLよりも従来使用されている表記法の方が分かりやすい表現であるという結論になりました。UMLの表記を無理やり使用するのではなく、有効な個所のみに使用するのが当初の方針に照らして、従来の表現が有効であると判断したわけです。将来的に、UML表現を使用した有効な表現方法が見つかったら、それを少しずつ取り入れていきたいと思います。

　パフォーマンス分析については、現状のUMLモデルからのみで、パフォーマンスの予測を行うことは不可能でした。過去の経験やパフォーマンスのデータがないものに関して、モデルからだけで予測性能を見いだすのは、現状は不可能とであるという結論となりました。

　最終的なHW／SW分割ポイントの結果は、基本的に「ハフマン符号復号部分」と「iDCT部分」になりました。以下に分割パターンを記しますが、これは性能評価とイテレーションを何度か繰り返し決定した分割パターンであり、初期の分割パターンで決定したものではありません。