［ObjectDay2001特集］

人類が「オブジェクト指向」を採用した日、オブジェクトデイ。
そのオブジェクトデイで行われた組込み関連のセッションに参加できたので、僕なりに報告したいと思います。

セッションは、200人程収容できるホールで行われました。内容は超入門ということで、ＵＭＬの紹介と組込みシステムのモデリングのノウハウ、そして組込みシステムへのＯＯ導入の留意点という形で話が進められました。いくつか印象に残った点を報告します。

■　組込みシステム開発とオブジェクト指向

●　組込みシステムの特徴

・高機能性の要求が高まり、制御中心からデータ処理中心へ。

[所感]
携帯を筆頭に、その高機能化の流れは目を見張るものがありますよね。少し前では当たり前だったのに、メールの出来ない携帯を使っていたりすると、今ではちょっぴり恥ずかしいです。そして、この加速度的に進む高機能化を実現するために、ソフトが頑張ってるんですね。そのため、ソフト屋さんの労働時間は機能の増加と共に増え続けて、従来の手法に限界を感じるのも無理はありませんよね。

●　なぜオブジェクト指向？

・分かりやすく変更に強いアーキテクチャを構築できる。
・組込みシステムでのデータ処理が増加して複雑化したため、従来の手法では限界を迎えている。

[所感]
人間は周囲(世界)をオブジェクトとして抽象化して認識します。その考え方を導入して、扱うシステムの複雑さを解消したいという欲望がＯＯを生み出したとすると、個人的には、組込みシステムでも、データ処理が増えてシステムが複雑化してきたため、ＯＯを採用するというのはむしろ自然な流れなのかなという気がします。

●　オブジェクト指向で全てが解決するわけではない

・リアルタイム性、メモリ効率などを解決するわけではない。

[所感]
ＯＯの守備範囲を明確にしておかないと、ＯＯが全ての問題点を解決するという「デンジャラスな幻想」に巻き込まれ、半泣きの目に会ってしまいます。それはまるで、「お〜れ〜は〜ジャイアーーン」と超ノリノリで突っ走るジャイアンと、それに引きずられるのび太の図。ふと、世の中の厳しさを感じる瞬間です。

■　組込みモデリング

●　要求分析

・ユースケースは、あくまでユーザにとって意味のある完結した機能を記述するものであって、性能や制約などは、非機能要求として補足仕様書(アーキテクチャ要求)を作成する。（エラー処理の扱いについての質問がありましたが、エラー処理についても非機能要求としてまとめておく必要があるそうです。）

●　並行性の設計

・時間制約は、シーケンス図で表現。同期・非同期を表現する。

[所感]
最近では、ツールでシーケンス図からタイミング解析できるものもありますね。

■　組込み開発の留意点

●　アーキテクチャ設計で制約に対処する。

・組込み特有の制約(実行速度、メモリ制限)に合わせて、理想的なＯＯＤを「適切に」歪めて、現実解としての適用を心がける。

[所感]
どんなにきれいな設計でも、メモリに収まらなければ駄目なんですね。悲しいですけど。

セッションは、組込みシステム開発が抱える問題と、ＯＯを実際のプロジェクトに適用したケーススタディという形で話が進められました。ＯＯを導入するための課題や、実際に導入した結果どうだったかがまとめられていて、個人的にはとても面白く聞くことが出来ました。印象に残った点を報告します。

■　組込みシステムとＯＯ開発

●　巨大化するソフトウェア

・携帯では、バージョンアップ毎にコードサイズ30%増。

●　組込みソフトへの要求

・従来、組込み特有の自律性、高信頼性、ハードとの協調性は「匠」の技に支えられた職人芸的開発で行われており、限界を迎えている。

[所感]
でも、何故このような高い要求がソフトにばかりされるのでしょうか？これについては、上司が「ソフトは腰が軽い」と言われたことを思い出します。ソフトは変更にもお金がかかりにくいし修正も早い。その「腰の軽さ」という長所ゆえに、ソフトがユーザからの高度な要求の実現やコスト的な問題の解消などの様々な方向からの圧力の「緩衝材」として利用されているからなんでしょうね。（ちょっと脱線。）

■　ＯＯ導入の課題

●　上司の主張

・不具合ゼロは当たり前、コードの再利用は元々高い、お客様はオブジェクト指向を望んでいるわけではない。

[所感]
上司の言い分はもっともで、今まで作り込んできた品質を崩して新規に品質を作り込むのはリスキーですし、既にある程度の再利用はしているわけですよね。それと、ＯＯで開発したいのは自己満足ではないのかという問いかけにも、考えさせられるものがあります。でも、「いいもの作りたいけど、もう限界。これ以上は死んじゃうぴょーん」ってなったら、なんとか上司を説得しないといけませんよね。古山さんはそのことについても、指針を示してくれました。

●　上司の説得−狙いの明確化

・開発プロセスを変更する狙いを明確にして説得する。ＯＯはあくまで手段。

[所感]
重要なのは、とにかく「オブジェクト指向という言葉、ＯＯ用語は使わない」ことだそうです。

●　"オブジェクト指向"アレルギー

・ＯＯは遅い？ＯＯは大きい？ＯＯは難しい？

[所感]
これについては良く聞きますね。「遅い、大きい」は性能の問題で、「難しい」は開発手段に内包された問題です。性能については、そもそもＯＯは性能を解決する技術ではないと言い切ることもできると思うのですが、組込みシステム特有の制限がこれを許してくれません。でも本当に遅くて、大きいのかについては、検証の余地があると思いますね。また、「難しい」については僕も同感です。完了の判断基準が特に難しいと思います。

■　ケーススタディ

今回紹介して頂いた適用事例は、再生専用ポータブルMDでした。パイロットプロジェクトとして選択したそうなんですが、最初から大きなシステムに適用しなかったというのは、非常に適切な判断だったと思います。物事は、小さくて簡単なものから、徐々に大きくて複雑なものというのが順序ですからね。

●　「松下（渡守武「ともたけ」）手法」の紹介

・アクティブオブジェクト指向
・フレームワーク「ＥＳＣモデル」
・５階層アーキテクチャ

[所感]
ＥＳＣとは、Event、Service、Controlの略なのですが、バウンダリ層などを入力（Event）、出力（Service）に分けて捉えます。この方法だと、イベントのシーケンスも捉えやすくアーキテクチャ設計も分かりやすくなると思いました。

●　階層化

・部品クラスはスレーブに徹する(部品クラスをインテリジェントにすると逆に使いづらくなる)

[所感]
一つのクラスに責務を集中させずに、個々のオブジェクトに責務を分散させるのが良いと思っていたので、「あれっ？」と思いました。頭を使うクラスと使わないクラスを協調させると思うのですが、頭を使うクラスの責務が多くなりすぎないかなという疑問が残りました。程度の問題かもしれませんが。

●　勘と経験による開発からの脱却

・完了判断ルールを明確にしておく。完了チェックポイントの設定、評価ポイントの設定。

[所感]
ＯＯを適用する目的が職人芸的開発からの脱却なので、勘と経験に頼らない評価ポイントは重要だと感じました。

●　導入効果

・不具合の質の向上(バグの総数に大差はなかった)
・要求仕様不良やI/Fバグに効果があった
・初回でもトータル期間は従来と同等

[所感]
パイロットプロジェクトとしては十分な気がしました。

以上で、報告を終わります。
午後は、XPに浮気してしまいました。

(べ)

© 2001 OGIS-RI Co., Ltd.

Index