■ はじめに
2000年8月に情報処理学会の主催で「オブジェクト指向2000シンポジウム」が開催されました．その中に，｢組込みオブジェクト指向ワーキンググループ｣（以降，｢組込みオブジェクトWG｣）による「組込みシステムのモデリングテクニック」というパネルセッションがありました．
1999年6月に発足したばかりのこの組込みオブジェクトWGは，情報処理学会ソフトウェア工学研究会のWGの一つで，メンバ間で適用経験を相互に紹介，議論しながら，共通の問題意識を洗い出し，共通化すべき考え方や概念などを発見することを目的として，共通問題に基づくモデリングと議論を行っているそうです．
今回のセッションは，組込みオブジェクトWGの成果発表ともいえるもので，製品検査装置という共通問題に対して各メンバが作成したそれぞれの分析モデルを比較検討するというものでした．
組み込み分野でのオブジェクト指向の適用は最近増えているものの，ほかのビジネス系ソフトウェア開発における適用に比べると，まだまだ勘と経験によるところが大きく，成熟しているとはいいがたいところがあります．
一言で組み込み（あるいはリアルタイム）システムといっても，その開発規模やターゲットとなるハードウェアの構成，求められるパフォーマンス（実行効率）や使用可能なリソース（ROM/RAMなど）の制約は，それぞれ大きく異なるので，それぞれの開発対象となるシステムに応じて分析や設計のやり方を最適化しなければなりません．つまり，唯一の正攻法はないのです．
このセッションは，組み込み分野でオブジェクト指向による開発を行ってきた先人達が「共通の問題」，つまり同じ土俵でモデリングした，しかもそれらの違いを見ることのできる，数少ない，貴重な機会だったと思います．
一般に，モデルはその成熟度（あるいは工程）や目的の違いから概念モデル，分析モデル，設計モデルに分類されます．概念モデルは，おもにステークホルダ（利害関係者）間で問題領域の重要な概念について意識を統一することを目的にしたクラス図で，どのような概念があるのかということに絞り，システムの構造やふるまいについてはそれほど重要視されません（組み込みシステムでは，ステークホルダにはメカ屋などのハードウェア技術者が含まれることになる）．
分析モデルは，要求を整理し，システムの構造やふるまいをとらえたものです．設計モデルは，実装に的を絞り，実行環境に合わせたり，QoS（パフォーマンス制約やリソース制約といった品質の要求）に対する戦略を反映させたものです．
セッションでは分析モデルを取り上げています．概念モデルではシステムとしての考察が甘く，設計モデルでは技術的な要素が強くなってしまうので，同様の問題領域に対してベースラインとなる，共通化が可能なモデルとして選択されたのだと思います．また，複雑さを増してきている組み込みシステムで，従来はおざなりだったことの多い分析の重要性を示したかったのでしょう．
筆者はおもに組み込みシステムの開発やコンサルタントを業務としています．組込みオブジェクトWGのメンバではありませんが，本稿ではセッションのレポートとして，独自の解釈で，六つのモデル（A～F）についてそれぞれの特徴を簡単に述べてから，モデリングのテクニックについて検証していき，分析モデルの重要性について再確認したいと思います．
なお，誌面の都合上，セッション資料（モデル）の一部のみを抜粋しました．本稿はセッションに参加されてない方が読まれることを想定していますが，わかりにくい部分もあるかもしれません．ご容赦ください．
共通課題（製品検査装置）
共通の課題は，製品検査装置です（図1）．前工程装置から製品を受け取り（搬入），キズの検査を行い，後工程に引き渡します（搬出）．搬入にはロードアームを用い，バーコードリーダで製品ごとのシリアル番号を読み取ります．検査方法（レシピ）は，オペレータがタッチパネルで設定しておきます．製品はいくつかの区画に分けられて，CCDカメラでキズの有無が判定されます（図2）．搬出にはアンロードアームを用います．なお検査は，ロットと呼ばれる単位で出荷判定が行われます．
以降，各モデルの特徴を解説していきます．
図 1 製品検査装置(※セッション資料より抜粋)
図 2 区画(※セッション資料より抜粋)
モデルA：オブジェクト抽出の敷居を下げ，並行性まで大まかに検証した分析モデル（図3）
このモデルでは，サービス，マテリアル，仕様，抽象部品といったクラスカテゴリに注目してオブジェクトの抽出を行っています．これらのカテゴリに沿ってオブジェクトを見つけていくと，機械的にオブジェクトを発見することが可能になります．また，各カテゴリに注目することで，クラスの抽出のもれを防ぎます．
図3のようにカテゴリごとに抽出されたオブジェクトは，それぞれステレロタイプをともなったクラスとして表現されています（たとえば，マテリアルから抽出したロット，製品，区画）．
このモデルではその後，検査，搬入，搬出，HMI（ヒューマンインターフェース）といったサービスカテゴリのオブジェクトを並行動作の単位として，アクティビティ図を用い，システムの並行性について大まかに検討しています．そして，シーケンス図を用いて抽出したオブジェクトの相互作用を検証しています．
アクティブクラスとなる各サービス間では，非同期メッセージをやり取りします（搬入から検査への「搬入完了を通知する」メッセージや検査から搬出への「検査完了を通知する」メッセージなど）．
図3 モデルA：クラス図(※セッション資料より抜粋)
モデルB：シュレイアー・メラー法によるシミュレーション可能な分析モデル（図4）
このモデルは，シュレイアー・メラー法〔組み込み用のオブジェクト指向方法論の一つ．詳しくは参考文献2）を参照のこと〕に基づいて分析が行われたものです．このモデルではシステムを，製品検査ドメイン，オペレータが操作するOperation UIドメイン，アームを制御するArm Controlドメイン，CCDカメラによる画像検査を行うCCD Examinationドメインといった小さなドメインに分割しています．
イベント分析は，システムの起動要因となるアクタからのトリガ（これをイベントと呼ぶ）ごとにシステムの応答や事後条件などを列挙したものです．組み込みシステムでは，アクタからのトリガにより起動されるユースケースの実行の間にハードウェアとのやり取りがあることや，ハードウェアからの応答を含むイベントにリアクティブに動作することが多いことなどから，より詳細にイベントを識別しておくことが重要です．このモデルでは，ユースケースの詳細化によってイベントを抽出し，状態図上のイベントとして利用しています．
次に，分割されたドメインごとに，ユースケースを詳細化していきます．これは，イベント分析に近いものです．ドメインごとのクラス図では並行動作するアクティブクラス（タスク）を識別しています．図4は，製品検査ドメインのクラス図です．アクティブクラスとして検査工程，製品搬送，製品検査クラスが並行処理の候補として識別されています．
図 4 モデルB：製品検査ドメインのクラス図(※セッション資料より抜粋)
ドメインごとにアクティブクラス（のインスタンス）間の非同期通信のみを記述したコラボレーション図を作成し，並行性および動作の検証を行います．ほかのドメインとの通信も非同期通信になります．アクティブクラスとして識別された各クラスは，それぞれ状態図を使って分析されます．ドメインごとに詳細化されたユースケースは，状態図中のイベントとして状態遷移を引き起こすトリガになります．
このモデルは，CASEツールのモデルシミュレーション機能を使うことを前提にしているため，イベントごとのアクションをアクション記述言語によって動作を記述しています．アクション記述言語は，今後の改訂でUMLに統合される予定のものです．
これはメソッドの処理を記述するための（実装言語に依存しない）マクロのようなものです．現在のUML1.3ではOCL（Object Constraint Language）を用いて制約事項を仕様として記述することはできますが，オブジェクトのふるまいの仕様については記述する手段がありません．通常，アクティビティ図やノートで示しますが，オブジェクトのメソッドは十分小さいため，この曖昧さは許容範囲にあるといえます．とくにシミュレーション機能を実現する場合にはこの記述が必要になります．
このシミュレーション機能により，ソースコードを実装することなしに，モデルの検証を行うことができるのが強みになります．このアプローチは，シミュレーション機能が利用できなくても有効ですが，分析で検討したイベントのアクションは，実際にコードを実装して検証することになります．
モデルC：再利用性，拡張性を意識した分析モデル（図5）
このモデルは，目的，手段，ハードウェアといったレイヤに階層化し，さらに各階層をパッケージに分割しています．各階層をパッケージに分割することよってパッケージの独立性を高め，変更をその中に局所化することがねらいとなっています．
図5は，業務パッケージのクラス図です．ここでは「検査方法（レシピ）」，「検査対象」，「検査結果」という概念の関係を，ロット，製品，区画といった三つのレベルで表現しています．「検査方法（レシピ）」はロット検査方法，製品検査方法，区画検査方法として識別されており，それぞれロット，製品，区画といった「検査対象」との間に，ロット検査結果，製品検査結果，区画検査結果といった「検査結果」が関連クラスとして関係づけられています．
図 5 モデルC：業務パッケージのクラス図(※セッション資料より抜粋)
このモデルでは，すでに問題領域に対する知識があることを前提として，再利用性に重点をおいたモデルになっています．作成した分析モデルを別プロジェクトの分析でも再利用できるようにパターンを適用し，変更が予想される箇所の拡張性を向上させています．
モデルD：静的構造を徹底的に分析したモデル（図6）
このモデルは，問題領域をきちんと理解するために，静的な構造を徹底的に分析したものです．とくに，オブジェクトの属性や関連の有効性をきちんとモデル化しています．たとえば，製品については検査前，検査中，検査後に分類し，それぞれ有効な属性や関連を区別しています．
とくに，問題領域を理解する際にオブジェクトの時間的変化にともなう特性の変化をきちんと把握する必要がある場合には有効です．また，クラス図にソフトウェアの複雑さが反映されるといったメリットがあります．複雑さが隠れてしまうと，クラス図はシンプルなのにメソッドが複雑になってしまうことがあります．
図 6 モデルD：クラス図(※セッション資料より抜粋)
モデルE：ROOM手法によるコンポーネントの再利用を意識したモデル（図7）
このモデルは，組み込みオブジェクト指向方法論のROOM（Real-Time Object Oriented Modeling）手法をベースに分析されたものです．ROOM手法は，ベル研究所で開発が進められてきた組み込み用のオブジェクト指向モデリング手法です．
ROOM手法は，クラス，カプセル，ポート，プロトコルといったオブジェクトカテゴリによって構成されています．カプセルは並行動作するアクティブクラスの候補になり，カプセルはポートを介してほかのカプセルと通信します．カプセル間の通信方法はプロトコルが実現します．
これによって，タスク構成とタスク間通信が表現できます〔ROOM手法については参考文献9）で簡単に紹介されている〕．ここでは，コンポーネントの再利用が可能になるようにモデル化されています．
図7では，並行動作するカプセルとして，システムを管理するInspectionMachine（検査装置），各サービスを行うInspecter（検査），Setup（レシピ設定），Reporter（結果報告），ハードウェア制御を行うBarcodeReader（バーコードリーダ），Image
Scanner（CCDカメラ），ArmController（アーム制御）が識別されています．
これらカプセル間の通信手段はすべてプロトコルに実装されるので，タスク間通信を局所化し，プラットホームに対して移植性を高めているのが特徴です．
図 7 モデルE：クラス図(※セッション資料より抜粋)
モデルF：独自の開発手順のパターンを適用した分析モデル（図8）
このモデルは，システムの目的を果たす「目的」，システムの入出力を行う「物理」といった二つのカテゴリからオブジェクトを抽出し，システム構成を整理したものになっています．このカテゴリはユースケース，アクタとほぼ等価の関係にあり，抽出はきわめて機械的になっています．
また，フレームワークに抽出したオブジェクトを配置すればよく，開発手順のパターン化により属人性を排し，生産性と品質確保をめざしたものです．フレームワークの適用により，設計への変換が単純化されるとともに，より設計に近いモデルで分析を行えるのが特徴です〔この開発手順は，考案者により自律オブジェクト指向として紹介されている．詳細については参考文献8）を参照のこと〕．
図 8 モデルF：クラス図(※セッション資料より抜粋)
モデリングテクニックを検証する
各モデルの特徴について簡単に述べてきましたが，ここからは，以下のテクニックについて検証していきます．
-
カテゴリによるオブジェクトの抽出
-
レイヤ化，パッケージ分割
-
問題領域の概念のモデル化
-
相互作用による抽出したオブジェクトの検証
-
シミュレーションによるモデルの検証
-
並行性の検討
-
再利用性，拡張性（パターンの適用）
ここであげたテクニックの最初の1.～3.は，おもにオブジェクトをどうやって抽出し，どのように静的な構造を整理するかという話題で，続く相互作用やシミュレーションによるオブジェクトの検証は，クラスを使ってシステムのふるまいの実現性を検証するものです．
前者はおもに概念モデルで注力する部分で，後者は分析モデルでなくてはならない部分になります．これによって，クラスモデルを洗練させます．また，組み込みシステムでは並行性は避けて通れません．これについては設計まで検討しないこともありますが，求められる応答性が厳しいものであれば早い段階で検討しておく必要があります．そして，最後は再利用性，拡張性についてです．
そのほか，組み込みシステムではパフォーマンス制約やリソース制約などに対処しなければなりませんが，設計の範ちゅうなので本稿ではふれません．
テクニック ：カテゴリによるオブジェクトの抽出
はじめて概念モデルあるいは分析モデルを作成する際に，どんなクラスを抽出すればよいか迷ってしまうことがあります．初めから完全にオブジェクトを抽出できなくても問題はないのですが，何らかの指針があれば，オブジェクトの抽出も少しは楽になります．カテゴリによるオブジェクトの抽出を用いることで，モデリング上級者でなくても適切なオブジェクトを抽出できるようになるのがねらいです．
モデルAでは，システムで加工，操作する対象となる「材料」（<<material>>），オブジェクトの共通属性を集めた「仕様，ルール」（<<spec>>，<<rule>>），システムの機能を実現する責務をもつ「サービス，プロセス」（<<service>>，<<process>>），装置の構造や制御の単位を抽象化した「抽象部品」（<<component>>），ハードウェアを抽象化した「ハードウェア」（<<HW Wrapper>>）のカテゴリから，順にオブジェクトを抽出していきます．以下に，モデルAのクラスカテゴリの依存関係を図示します（図9）．
図 9 モデルAのクラスカテゴリと依存関係
モデルFでは，「目的」と「物理」というたった二つのカテゴリからオブジェクトを抽出します（図10）．目的オブジェクトはシステムの目的を表すもので，ユースケースのコーディネータ（controlオブジェクト）です．
物理オブジェクトは，おもにハードウェアなどの実際のものを抽出します．物理オブジェクトは入力系（Input）と出力系（Output）に分類されます．このモデルでは，ユースケース図とクラス導出は等価の関係が成立します．ユースケースは目的オブジェクトに，アクタは物理オブジェクトに変換されます．
つまり，システムの目的として導出したユースケースとデバイスをアクタとしたユースケース図から分析モデルのクラス図がほぼ自動的に作成できます．さらに，目的オブジェクトを監視し，システムのふるまいをコントロールする「制御マネージャ」を配置することで，システムが組み立てられます．
図 10 モデルFのクラスカテゴリと依存関係
このテクニックは，おもにハードウェアの制御が中心でデータ要素の少ないシステムの開発に限定した，とても魅力的なアプローチといえます．このアプローチの弱点は，重要な概念あるいはシステムで用いるデータ構造についての検討が甘くなってしまうことです．
実際に，システムをハードウェアとその制御シーケンスにマッピングしている構造のため，データ要素が軽視されてしまいます．データ要素が複雑になってくるとどこかにしわ寄せが来て，モデル上にない複雑さをどこかのオブジェクトのメソッドに埋め込ませてしまう危険性があると思います．
モデルAでは，データ要素を「マテリアル」というカテゴリに分類しています．このほうが，より柔軟に適切な責務をもったクラスを抽出することが可能になります．適用できる問題領域も，より広範囲になっている点で優れています．システムを構成するオブジェクトをいかに漏れなく見つけるかという点に関しては，必要かつ最小限のカテゴリに着目し，該当するクラスを見つけていくのがよいでしょう．
テクニック：レイヤ化，パッケージ分割
組み込みシステムでは，目的に合わせたハードウェアの制御手順が中心になることが多いため，これらシステムのふるまいを局所化することが重要です．ビジネス系とは異なり，次のように機能だけでなくハードウェアが変更される場合もあります．
-
システムの機能が変更される
-
システムを構成するハードウェアが変更される
システムを階層化（レイヤに分割）し，責務単位でパッケージ（サブシステム）に分割することで，システムを適切な単位に分割し，問題を局所化します．
図 11 モデルC：パッケージ図(※セッション資料より抜粋)
モデルBでは，はじめにドメインチャート（パッケージ図）でシステムをいくつかのドメインに分割しています．個々のハードウェアの制御もそれぞれドメインとして分割します．ドメインチャートはシュレイアー・メラー法で用いられるダイヤグラムの名称です．
モデルCでは，はじめに「目的（検査業務）」，「手段（機構）」，「ハードウェア」に階層化し，各パッケージの独立性を高めて，変更による影響をパッケージ内部で収まるようにしています（図11）．
モデルDでは，「検査」，「製品（製品対象）」，「検査の結果」，「検査の装置」，「GUI」，「RTOS」といったパッケージに分割されています．
モデルAやモデルFでは，明示的ではありませんが，クラスカテゴリによってゆるやかに階層化あるいはパッケージ分けされているといってよいでしょう．カテゴリごとに抽出されたクラスは，関連の強いクラスと同じパッケージに分割されていきます．
レイヤ化，パッケージ分割において注意しなければならないのは，たんに分割するだけではなく，それぞれの依存関係をできるだけ小さくする（疎結合度）ということです．また，問題をパッケージ内に局所化し，パッケージ単位で独立性を高める（高凝集度）ことで，パッケージをコンポーネント（部品）として再利用することを可能にします．
そのほか，システムの開発においても，パッケージ単位に作業担当を割り振ると，開発者はそのパッケージの責務に集中することができます〔レイヤ化の詳細については参考文献7）のLayerパターンを参照のこと〕．
テクニック：問題領域の概念のモデル化
製品検査装置システムでは，「レシピ」，「ロット」，「製品」，「区画」といった問題領域に特有の概念が出てきました．問題文に記述されていましたが，これらは分析モデル（概念モデル）に当然含まれるべきです．モデルAでは材料<<material>>カテゴリに分類されるクラスとして識別されています．
モデルBでは製品検査ドメインのクラスとして識別されています．「区画」については，おそらくCCD Examinationドメインに含まれているものと思われます．モデルCでは，製品パッケージのクラスとして識別されています（業務パッケージのクラス図で確認できる）．モデルDも同様に製品パッケージのクラスとして識別されています．とくに，モデルDは前述のとおり「製品」や「区画」について詳細な分析情報をモデルに反映しています〔このようなモデル化の詳細については参考文献1）を参照のこと〕．
ここまできちんとモデル化できると，問題領域の理解も深まりますが，通常は限られた時間とのトレードオフで，どこまでモデル化するかは経験による慣れにも依存します．システムの全体像をきちんと把握することが先決なので，細かい部分にあまり時間を費やしてしまって全体がわからないのでは意味がなくなってしまうので注意が必要です．
一方，モデルE，モデルFではロット，製品，区画といったクラスが識別されていません．これらはおもに制御中心のモデルといえます．
これらの概念がモデルに表現されていないと，システムの複雑さが隠れてしまいます．問題点としては，（少なくともモデル作成者以外の開発者に）問題領域が正しく理解されなくなってしまうこと，それらを制御するオブジェクトのメソッドが必要以上に複雑になってしまうこと，それらの操作が局所化されずにあちこちに点在してしまう危険性が高いことなどがあげられます．
これら問題領域に特有の概念は，専門用語の名称のまま，きちんとモデル化しておくことが大事だと思います．
テクニック：相互作用による抽出したオブジェクトの検証
当然ですが，クラス図は静的な構造しか表現できません．分析では，機能の実現可能性についても検討しなければなりません．通常，シーケンス図またはコラボレーション図を使って抽出したオブジェクトの協調関係で重要なユースケースのシナリオが実現できることを大まかに確認します．クラスの責務が妥当かどうか，クラスが不足してないかどうかを確認し，必要に応じてクラス図を修正します．
モデルAでは，シーケンス図を用いて検査のシナリオを検証しています．モデルFも同様です．モデルCでは，コラボレーション図を用いて搬入，検査，搬出のシナリオを検証しています（図12）．
図 12 モデルC：検査のコラボレーション図(※セッション資料より抜粋)
またモデルB，モデルEでは，アクティブクラス（モデルEではカプセル）の状態図とアクション記述によって，オブジェクトのふるまいを中心に，ほかのオブジェクトとの相互作用についても検証しています．
概念モデルと分析モデルの大きな違いは，抽出したオブジェクトの相互作用によってシステムが成立することを検証するかどうかにあります．分析において，すべてのシナリオについて細かく検証する必要はないと思いますが，ユーザーにとって重要な機能のシナリオや，技術的にリスクの高い機能のシナリオについては大まかに実現性を確認しておく必要があります．
分析モデルでは，完全性，網羅性よりも開発者にとって理解しやすい量と質のバランスをとることが何より重要だと考えます．
テクニック：シミュレーションによるモデルの検証
このテクニックには，CASEツールのサポートが必要になります．モデルBではBridgePoint（https://www.projtech.com/home.html），モデルEではRoseRT（https://www.rational.com/products/rosert/index.jsp）といったシミュレーション可能なオブジェクト指向CASEツールを使用して，モデル上でシステムの動作を検証することができます．
たんに問題領域のオブジェクトの構造をモデル化するのではなく，モデル上でシステムのふるまいを検証可能な動的な部分に注目してモデルを作成します．
モデルシミュレーションのサポートがない場合，前述した相互作用のモデルを使って机上で確認することになります．CRCカード（注1）のようにセッション形式で検証を行ってもよいでしょう．また，繰り返し型の開発では，早い段階で重要な部分の発展的プロトタイプを作成して，実際のコードで検証することになります．
テクニック：並行性の検討
組み込みおよびリアルタイムシステムの多くはマルチタスクで動作させるものが多いので，どのように並行性を実現するのか，検討が必要になります．並行性の検討を行うタイミングについては主張が分かれるところで，分析でやるべきという人もいますし，設計時点でよいという人もいます．
並行性の実現手段も，オブジェクトあるいはパッケージ単位にスレッドを割り当てる場合もありますし，コマンドやイベント処理単位にスレッドを割り当てる場合もあります．このため，
並行性の検討については，対象となるシステムの特徴によって異なります．
図 13 モデルA：アクティビティ図(※セッション資料より抜粋)
モデルAでは，アクティビティ図を使って並行性を大まかに検討しています（図13）．モデルBではアクティブクラス，モデルEではカプセルとして並行動作する単位を識別しています．
ハードリアルタイムなど，とくに時間制約の強いシステムでは早い段階で並行性を検討する必要がありますが，まずは問題領域を理解し，きちんと静的な構造をモデル化することが先決です．
テクニック：再利用性，拡張性（パターンの適用）
問題領域について理解が進んだら，いよいよ再利用性や拡張性について検討します．再利用性については，どんな単位で再利用したいのかをはっきりさせることが重要です．
たとえば，ハードウェア制御のような小さなコンポーネントの単位で再利用するとか，フレームワークとして実装を再利用するとか，デザインパターンを適用して設計ポリシを再利用するなどです．それぞれの目標に合わせてモデルを作成し，洗練させていきます．
拡張性については，まず変更されやすい問題を局所化することに注目します．その後，予想される変更に対応しやすい構造に洗練させます．
モデルCでは，パターンを適用して拡張性を高めています（図14）．検査の工程が変更，追加されやすいことに着目し，工程の変更に柔軟に対応できるようにPipes & Filterパターンを適用しています．このパターンは，システムをデータフローのようにシーケンシャルな処理のステップに分割するものです．
製品というデータを，搬入位置，検査位置，搬出位置といったパイプを経由して，それぞれ搬入手段，検査手段，搬出手段といったフィルタが処理する流れを示しています〔Pipes & Filtersパターンの詳細については参考文献7）を参照のこと〕．
また，検査の工程が複数になることを想定し，線形パターンを適用しています．前位置，後位置という概念でモデル化しているものです．検査位置は，（後続の検査位置に対して）前位置にも（直前の検査位置に対して）後位置にもなるので，連続した検査を行えます〔線形パターンの詳細については参考文献1）を参照のこと〕．
しかしながら，まずは問題領域の理解が先決です．きちんとドメインを理解せず，再利用性や拡張性を追求しても，複雑さを軽減できずにかえって保守性の悪いシステムになってしまうので注意が必要です．
図 14 モデルC：検査パッケージのクラス図(※セッション資料より抜粋)
各モデルの比較
以上，各モデルとテクニックを表1にまとめてみました．
|
|
モデルA
|
モデルB
|
モデルC
|
モデルD
|
モデルE
|
モデルF
|
|
属人性の排除
|
|
|
|
|
|
◎
|
|
カテゴリによるクラス抽出
|
◎
|
|
|
|
|
○
|
|
レイヤ化、パッケージ分割
|
|
◎
|
◎
|
◎
|
|
|
|
問題領域(静的構造)
|
○
|
○
|
○
|
◎
|
|
|
|
相互作用
|
○
|
|
○
|
(対象外)
|
|
○
|
|
モデルの検証
(シミュレーション)
|
×
|
○BridgePoint
|
×
|
×
|
○
RoseRT
|
×
|
|
並行性
|
○
|
◎
|
(対象外)
|
(対象外)
|
○
|
○
|
|
再利用性・拡張性
|
|
|
◎
|
|
◎
|
|
|
方法論の依存性
|
低
|
S/M法
|
低
|
低
|
ROOM
|
※独自
|
ここでは，前述したモデリングのテクニックについて簡単におさらいします．なお，各モデルは完全な分析モデルのセットではなく，セッション用に特徴的な部分だけを抽出したものです．上記の表にある比較は，セッションで示された各モデルのみを対象にしているため，実際の開発で行われる分析モデルの優劣を示すものではありません．
「属人性の排除」という点では，モデルFが優れています．これは，ユースケースおよびクラスカテゴリによるクラス抽出から設計までをスムーズに進める手順やフレームワークがあり，難しいモデリングの作業を極端に単純化しているためです．この単純化により，属人性は排除されますが，適用可能な問題領域が狭くなってしまうといったトレードオフがあります．
「クラスの抽出」では，クラスカテゴリに着目してクラス抽出を行うことで，クラスを見つけやすく，モレなく発見できます．セッションではモデルA，モデルFでクラスカテゴリが明示されていましたが，ほかのモデルでもクラスカテゴリに着目したクラスの導出が行われているものと思われます．一般に，カテゴリに着目したクラス導出については，参考文献1）や参考文献2）など，たくさんの書籍で紹介されています．
「問題領域の概念のモデル化」については，分析モデルにおいて問題領域に特有の概念がクラスとして導出されているかがポイントになります．モデルAからモデルDまでは導出されていますが，モデルE，モデルFについては，より設計寄りであることと制御が中心であるため，概念が素直に表現されていませんでした．
「レイヤ化，パッケージ分割」は，システムをレイヤに階層化し，責務単位にパッケージに分割することで，システムを適切な単位に分割し，問題を局所化するものです．セッションでは，モデルBはドメインチャート，モデルC，モデルDで明示されていました．
「相互作用による抽出したオブジェクトの検証」と「シミュレーションによるモデルの検証」は，ともにシステムのふるまいを定義し検証するものです．
「並行性の検討」は，マルチタスクで動作させることが多い組み込みシステムでは重要です．ビジネス系など，一般的には並行性の検討は設計作業で行うものとされていますが，早い段階で検討すべきです．
「再利用，拡張性（パターンの適用）」は，オブジェクト指向のメリットといえますが，オブジェクト指向で開発すればよいというほど，実現はやさしくありません．再利用する単位や変更箇所を特定することで，はじめてこれらに対処できます．モデルCでは変更されやすい箇所を特定し，変更に対応しやすい構造を得るためにパターンを適用しています．
「方法論への依存性」という点では，モデルBがシュレイアー・メラー法に，モデルEがROOM手法に依存したアプローチをとっています．また，モデルFも独自のアプローチをとっています．特定の方法論およびそれをサポートするCASEツールを採用することで，モデルに特徴が出てきます．
■ まとめ
最後に，組み込みシステム開発の特徴，難しさをあげ，筆者の考える分析モデルの重要性についてまとめます．
● 組み込みシステム開発の特徴
組み込みシステムの特徴として，製品のシリーズ化や開発サイクルの短さがあげられます．
1）製品のシリーズ化（廉価モデル，一般向けモデル，高級モデルなど）
2）（一般消費者向けの場合はとくに）製品サイクルが短い
これらについては，分析モデルの再利用をすることで開発を効率化できます．むしろ，同じ問題領域に関する分析モデルは再利用して開発しなければ短期間に製品化することが難しくなってきているといえます．
● 組み込みシステムの難しさ
組み込みシステムの開発の難しさは，特徴的なものとして次の要因があげられます．
-
理想的にはソフト，ハードを含めたシステム（製品）レベルでの検討が必要
-
現実は，ハードウェアの仕様（並行開発のため変更されやすい）に応じてソフトウェアを開発しなければならない
-
同じドメインでの開発でも，毎回メカの要求する制御手順に合わせて変更が生じる
-
同じメカでも異なる部品では制御特性が異なってしまう
例）セカンドソースとの特性の違い（許容範囲内に収めなければならない）
-
ハードウェアの不具合に対応しなければならない
-
厳しい制約への対応（制約を満たすために特殊な方法が求められる）
-
ドメインの本質的な構造がゆがみ，理解性が落ちてしまう
-
特殊な設計のため，次の開発で使えなくなってしまう（再利用性の低下）
これらの要因で，システム開発およびモデルの再利用が難しくなってしまいます．
分析モデルを再利用するには，これらの変更されやすい要因に対して柔軟なモデルにしておく必要があります．分析モデルでは，問題領域の本質的な部分に注力することが大事です．ハードウェアに関しては変更されやすいので抽象化したり，依存する箇所を限定するなどの工夫が必要になります．
分析段階で調査したハードウェアの詳細や，制約への対応については別途ドキュメントにまとめ，分析モデルに含めるべきではないと思います．これらは，システムの本質的な部分ではないし，変更による影響が大きいからです．
● 分析モデルの重要性
分析においてモデリングを行う際にもっとも注目すべきは，問題領域を理解することです．何より本質的な構造を理解し，きちんとモデルに反映させておくことが，再利用性や拡張性の高いシステムを構築するうえでの出発点となるからです．
実装を意識した設計モデルももちろん重要ですが，本質を整理した分析モデルの作成にも十分に注力する価値があります．もちろん，実装に向けて技術的な制約に対する分析も必要になってきますが，これらの技術的な調査事項はここでのモデルとは分けておくことが，ドメインモデル（分析モデル）を再利用する際のポイントになります．
組み込みシステムでは，ハードウェアの制御，非機能的要求（パフォーマンス要求，リソース制約），並行性といった特徴に関心がいきますが，より複雑化する要求に対処するためには，まず問題領域のきちんとした理解とシステムの組織化をはかり，そのうえで組み込み特有の制約に対処することが肝心だと思います．
もちろん，これら特徴の中には分析モデルで取り上げるべき（共通化すべき）ものも含まれているでしょうが，それは今後の検討事項としておきたいと思います．今後，組込みオブジェクトWGの議論が進む中で取り上げられるものと期待しています．
最後に，貴重なセッションを開催していただき，さらに当日のセッション資料の引用を快諾していただいた，組込みオブジェクトWGの皆様に感謝いたします．
参考文献
1）レオン・スター著，Shlaer-Mellor研究会 訳，『シュレイアー・メラー法によるオブジェクト・モデリング：リアルタイムシステムの静的解析法』，プレンティスホール出版，ISBN4-89471-036-6
2）S・シュレイアー，S・J・メラー共著，本位田真一 監訳，『続・オブジェクト指向システム分析：オブジェクト・ライフサイクル』，近代科学社，ISBN4-7649-0238-9
3）C・ラーマン著，今野睦，依田智夫 監訳，『実践UML：パターンによるオブジェクト指向開発ガイド』，プレンティスホール出版，ISBN4-89471-077-3
4）B.P.Douglass，Real-Time UML Second Edition: Developing Efficient Objects for Embedded Systems，Addison-Wesley，ISBN0-201-65784-8〔2001年翻訳本出版予定（翔泳社）〕
5）H. Gomma, Designing Concurrent, Distributed, and Real-Time Applications With UML，Addison-Wesley，ISBN0-201-65793-7
6）I・ヤコブソン著，西岡敏博，渡邊克宏，梶原清彦 監訳，『オブジェクト指向ソフトウェア工学OOSE：use-caseによるアプローチ』，トッパン，ISBN4-8101-8066-2
7）F・ブッシュマンほか著，金沢典子，水野貴之，桜井麻里，関 富登志，千葉寛之 訳，『ソフトウェアアーキテクチャ：ソフトウェア開発のためのパターン体系』，近代科学社，ISBN4-7649-0283-4
8）岩橋正実，｢オブジェクト指向で制御システムを実現する方法｣，『Interface』，1998年7月号
9）藤倉俊幸，｢もうコーディングを終わりにしたい人のためのROOMの紹介｣，『Interface』，2000年12月号
注1：CRCはClass Responsiblity Collaboratorの略．オブジェクトの責務の割り当てと，オブジェクト間の協調関係を示すもの．CRCカードは，紙（カード）にクラス名，責務，協調するクラスを記述するもの．
※
赤坂英彦、「組み込みシステムのモデリングテクニックを検証する」、『インターフェース』 2001年3月号
に掲載された記事に一部加筆・追加したものを転載しています。
