=============================================================================== 分科会１ セッションB2： SWEST4 議事録 「組込みシステム向けオブジェクト指向開発手法」 〜セッションA1延長戦〜 2002/07/23 =============================================================================== 【会場／参加者】 　日　時　： 2002/07/23 20:30-22:30 　会　場　： 会場 C会場（席数 脚程度用意） 参加者人数： 40人程度 【分科会全体】 会場の雰囲気： 　オブジェクト指向開発を利用するにあたり，実際に問題になっている事柄などを交 えつつ，質疑応答の形式で進んだ．厳しい意見もでたが，開発者やツールベンダは， 徐々に困難になりつつある組込みシステムの開発に対してブレイクスルーを求め様々 な意見が出ていた． 全体の方向性や結論： 　組込みシステムにたいしてオブジェクト指向開発を導入することの障害を洗い出す 方向で議論が進んだ．模索中の技術や手法の話題のため，明確な結論は出なかったが， ツールベンダと開発者の間の意見の中から，今後解決すべき問題点が見えてくるかも しれない． =============================================================================== 【ポジショントーク】 　A1セッション参照 【分科会】 南角： A1では組込みシステム向けオブジェクト指向ということで，東陽テクニカさん， 伊藤忠テクノサイエンスさん，豆蔵さん，日本ラショナルソフトウェアさん，キ ャッツさんにいいたいことをさらっと話していただきました．こんどは，まずオ ブジェクト指向は組込みシステムに使えるかどうかということで，これに対して 使えないという強い意見をもっているNECアクセステクニカの石山さんにまず意 見をお願いします． NEC（石山）： 3つ気がかりな点があります． >>第一点 シームレスな開発 オブジェクト指向でやるとシームレスに要求分析から実装までできるという， 私の考えでは要求の分析と実装は全然軸が違うはず，シームレスにできない． >>第二点 時間の抽象化 先週ソフトウェア技術者協会というところでやっているソフトウェアシンポジウ ムで和歌山大学の鯵坂先生が「オブジェクト指向というのは確かに良いんですが， それは機能をうまく抽象化する話になっている．組込みだと非常に大事な要素に 時間があるが，その時間を抽象化していない今のオブジェクト指向が組込みに使 えるとは思えない．組込みに使うには時間をどうを抽象化するかモデリングする かということが絶対必要なはずである．」といっていたんですが，それに対して， 少なくとも今のツールは答えていない． >>第三点 職人芸，実装の自動化 オブジェクト指向分析には意味があると思う．しかし，オブジェクト指向実装 というものに意味を感じられない．オブジェクト指向実装というのは別にして， ツールで実装までやられたら，職人として生きる道がない，ぜひやめてほしい． ほんとに使えるならいいが，使えると思えないので，（反論含めて）実現でき るかどうか教えてほしい． 以上です． 南角： これに対して松岡さんお願いします． ラショナル（松岡）： >>シームレスな開発 要求分析が実装と結びつかないという問題点はその通りだと思います． ラショナルはユニバーシティというコースを持っていますが，オブジェクト指 向で設計するため，ツールに依存しないUMLを使って分析設計を行うコースを 持っています．（そのコースでは）要求分析と分析設計と実装を分けています． そのなかで話していることは，要求分析と最初の分析設計とそっから先の実装 は基本的に分けています．これはたぶん，ずっとこうで，UMLのスペックが劇 的に変わらない以上は今のスペックでやる限りはちょっと無理であると思いま す．そのスペックがどう変わるかについてはツールベンダとしては保証できか ねますので，コメントを差し引かせていただきたいと思います．で，要求分析 と実装が違う話であるというのは実際の話だというのは我々は認識しています． >>時間の抽象化 我々のツールは時間を扱っていないのでコメントはしません． ただし，我々のツール上で時間を扱うことのできるツールを売られている会社 があります．そういったツールもニーズに応じて出てくると思う ラショナルがやるか？ といえば，UMLのスタンダードに入ったらやらざるを えないでしょうね． >>職人芸，実装の自動化 rose realtimeを使ってアプリケーション……実際にはミドルウェアなんです がファーム系やドライバのレイヤーをのぞいたコードの8割くらいを自動生成 しているという事例はあります．これは，MAXこれくらいまではいけるという 実例です． 南角： キャッツ（渡辺）さんお願いします． CATS： >>シームレスな開発 一つ目は同じ．要求モデルと設計モデルはトレーサビリティは無い．モデル自 体がそもそも違う．だからこそシステムレベルのテストが重要ですよといえて くると思います．分析モデルでのテストの抽出を設計レベルのモデルで試験す るということがつながりを持たせてくれるものではないかと思います. >>時間制約の抽象化 時間制約は無理．それを求める人はオブジェクトをやらない方が良いね． そもそも私がオブジェクト指向に入るときに言われたことは，リアルタイムOS とデータベースについてマスターしないとダメだと言われた．その意味は，イ ベントドリブンという考え方とDBのデータを活性化するという考え方だと思う． そして，そこには時間軸はない． 複写機一つをとってみても，一秒間に何枚だそうとか性能勝負なわけです． 一秒間に何枚出すぞ！ などと性能追求をやっている人はUMLなんてやってな い．タイミングチャートの嵐になっているはず． 聴いている人：（やってます） あ，やってんの？ 失礼しました．反論があるようなので次お願いします． >> 職人芸，実装の自動化 実装はラショナルさんと一緒でこれはもうどんどん移行されると思う． 職人芸の部分は残ると思うのですが，やっぱりここは自動化して生産性を高め て20分の1のコストだといわれている中国ですとかそういうところときちっと戦 わないとまずいと思います.だからここはツールとしてきちっとして行かなけれ ばならないと思います． 南角： 前田さん反論あるみたいですが，まず先にＣＴＣさんお願いします． CTC（徳江）： すいません，一番目についてもう一度お願いします． 石山： 要求と実装の違いって言うのは，要求がなんなのか分析して，仕様定義をUML のようなオブジェクト指向で書いて抜けをなくそうねという議論がいっぱい ありますよね．で，そのまま実装していいかといういと実時間制御であるとか もろもろの制約の中で要求をそのまま実装して，これは極端な言い方するとそ のまま自動生成ツールが出せたら，例えば，時間の関係で月に一回やるような 計算を３，４日かかってもいいんでしたらこれをツールで実装できるが，ある 時間の中でやらなければならないけない，いろんな時間制約があるところだと， 実装方法は単に要求からは出てこないなと思います．ところが，どうもツール ベンダさんは違うよとおっしゃったんですが要求のところから同じUMLで実装 まで全部シームレスにサポートできますよとおっしゃるんで大丈夫ですかと いう意味です． CTC: UMLは，各分析レベル等が，共通のUMLという言語を使ってモデリングできると いうコンセプトだと思います．時間制約に関してUMLで記述するのは難しいと 思う． 職人芸という点では，ラプソディは，毎回〃同じコードをかかなければなら ないという労力を軽減する事を目的としています．職人の技は，もっと高度 なところに集中できるとおもいます． 会場から： 私はツールベンダじゃないので，うまく答えられないかもしれませんが，複写 機ですけれども，実際本当に時間制約が必要なところ，クリティカルなところ は一部分だけなんですよね．それ意外の部分はUMLでがんがん書いて，ほんと うにクリティカルなところを抽出してそこは別の考え方，やり方で実装すれば， ほとんどの部分，９０パーセントの部分はUMLできちっと書けるので，そこら へんはきちっと分析とか設計すればうまくいくと思います．あと，職人芸と言 う話ですが，わたしはツールを結構使わせていただいてるんですが，結構ツー ルの制約を受けてしまう．多分まだツールの方が完全じゃないと思うんですが， どうしても書いていると私の持っているモデルが多分に表現しきれてなくて， 逆にツールに使われているような感じがします．とくに，オブジェクト指向の 初心者が，ツールを使い出すと，オブジェクト指向をやっているんだか，なん だかわかんないようなモデルになってしまうんで，最初は手でモデルを書く方 がいいと思います． 南角＞ 次は東陽テクニカ（二上さん）さんお願いします． 東陽テクニカ： 私はオブジェクト指向歴史学者じゃないですが，90年ぐらいの頃に構造化が破 綻して次はオブジェクトか？ といわれて，世界ではオブジェクト指向マーケテ ィングがクラス図さえじゃんじゃん書いていけば，シームレスにできるといっ ていました．現状は，どうかといえば，そうはなららなくてユースケースやク ラス図をちゃんと書きましょうとなっている．状態モデルとかいろいろあって， 結局シームレスになってないと思う． >>時間の抽象化 あと時間について．時間とはなんぞや？ と考えたことはありますか？今，高密 度化とか大規模化とかなってきたときにクロックをあわせるのが難しくなってき ています．10年もたてば，数センチはなれた場所でギガとかテラとかのオーダで データを転送を実現できるか？ そのときには，みんなめでたく相対性理論学者 になるわけですよ． 例えば，航空会社の予約システムの同期を考えてみると，ロンドンと東京のお 客様が同時にエントリーしたとしたらどうか？物理的には同着であったとして も「満席です」と両方に言えばすんでしまいます．いま通信の分野は，もうこ うなっている．じゃあこんな時間に関する問題にオブジェクト指向を導入した からって解決します？物理学で解決できない相対性理論の問題をオブジェクト 指向で解決できるとは思えない，時間制約はこういうレベルの問題だと思いま す． >>職人芸 次，実装（職人芸）について．これは，手放してはいけないと思う． 緻密な作り込みをやらなくなったら日本は終わりです．ただ作り込みを何でや るかは別問題です．私はCとアセンブラが好きです．あまり状態モデルでたく さんかくと分けが分からなくなるんです．正直言って苦手ですね．特にリレー ションが増えすぎると．（苦笑 だからCあたりが好きですね．でも規模が大きくなってくるとやっぱり勝てない． 展示場にあるレゴのおもちゃですけれど，一つはキャッツの人が作ってもう一 つはゼロックスの人が作った．夜なべして作ってたんですが，UMLでモデルを 作って４日ぐらいで作って，Cのコードで８千行ぐらいです．これをまともにCで つくったら40日でもできるかどうか． 南角： いろいろ意見があるんですが，ちょっと時間制約については問題のすり替え があったような？ 会場の方に伺いましょう．高田さんお願いします。 高田： 「問題のすり替え」というのは私もそう思います． 組込みでメカニカルな物を制御している間は，そんなことにはならない．メカが 動く速度には限界がありますから，LSIを相手に通信するような場合と違って， そんなにスピードが上がらないでしょう．そして，メカの制御にはやはり 時間制約はある．（相対論があるから時間制約がいらないんじゃなくて） みなさん——CATSの渡辺さんとか「無理ですよ」とおっしゃる．それはそれで 豪快で良いんですけれど，それでお客さん半分くらい捨ててんじゃないかなと． やっぱり，力強く「今は出来ませんけれど，そのうち何とかします」ぐらい 言ってほしいんですけれど，どうでしょう？ 渡辺： えっとね，そう．出来ます！（笑） 要は，時間はスタティックに——静的ににモデリングしちゃダメということ． ツールを使ってシミュレーションしないとダメ．ケースツール上で時間を検証 することは出来る． 今のUMLではメッセージシークエンスチャートに時間をいれて云々あるけれど 基本的には時間のモデル化は難しい．けれど「作った物を動かす」ということ で時間をクリアできているかどうか検証することは，今できていますから， それが良いと思います． 高田： それは，リアルタイム屋から言わせてもらうとそれはやっぱりだめで，リアル タイム屋もそう完璧にできているわけじゃないけど， 出来てないことは，あるプログラムの……あるルーティンのまっすぐ走ったと きの最大実行時間はいくらか？ という問題が出来ていないのです． そのプログラムを混ぜてごちゃごちゃとやってく部分は出来ている． 専門的にはRate Monotonic Analysisとか． そう考えるとオブジェクト指向屋さんは逃げているような気もしなくもない． 渡辺： そこは，コメットとかハッサンゴマとかのタスクのところ？？ あれが良いと思いますよ． オブジェクト指向といっても，結局「オブジェクト」は「タスク」として 実行しないといけないから，それをツールが実装してやればいいのかなと． でもそれは，もうオブジェクトじゃなくてタスクになっちゃっている． 二上： えーっと問題をすり替えるのうまい二上です．（笑 今のお二人の議論の中で，やっぱり時間を絶対時間で扱っているような気が します．一つの話というのはまさに私が話した相対論と絶対時間なんですが， さっき私が言ったことは相対論にシフトしたんですが．絶対時間の中でさっ きの二人の議論したとしても，要求分析の中での時間，それから実装ために 必要な時間に間に合わせるという時間，この二つの議論が一緒になっていま すよね，高田先生としてはどちらを議論したいんでしょうか，高田先生とし ては実装の時間を実装の時間をお話されているようですが． 渡辺：僕も実装の方に近い． 高田： さっきのトレーサビリティじゃないですけれど．要求の中で出てきた時間が 実装でも満たされていると言うことが大事なんです． 二上： そうすると要求の中で拘束条件として，例えば100ミリ秒以内にレスポンスを 返しなさいというのが，要求ですよね．中でごちょごちょというのが実装です よね．だから，要求で示されている時間の中で応答がでているのが知りたいと いうわけですよね？ 高田：そうです． 二上： 要求の中でAさんがBさんに，BさんがCさんとDさんにこう言いました． この要求の伝搬が矛盾があるか無いかというのを解けるかというツールへの 要求じゃ無いですよね． 石上： オブジェクト指向みたいなアプローチで分析しながらやっていこうとすると その中に機能なり仕様なりがまとまって入ってくる． まず，ある制約があって，その制約が最終的に満たせるかどうかが問題だと思う． 実際にやっている側から見ると， ・できあがった物がどうなのか？ ・モデルとしての時間をいれるのか？ ・実装として最悪条件の見積もりが出来てシミュレーションとして確認ができるのか？ で，ずいぶん違いがあるとおもう． 南角： 直感的に思ったことですが， 二上さんがおっしゃっているのは，オブジェクトが通信して，それぞれが時間制約 を満たせるか議論していて，我々が議論しているのは，あるオブジェクトが時間制 約を満たせるかを議論しているように聞こえます．なにか問題が違う気がする． 通信が入るとやはり不確定要素が入ると思います． 指名しますね．会場の方何かありますか？ シャープ（音川）： 時間制約の話をされていましたが，私は時間制約が厳しい組込みシステムの開発 をやっていなくて，そのことについてはコメントできません． 私は（ちょっと）組込みらしくない携帯端末の開発に関わっていまして，いろいろ 制約の少ないところでパソコンみたいな物をパソコンでないところで作っている のですが……実装に関わる部分でツールベンダさんに質問したいと思います． ラショナルさんのプレゼン——Rose RealTimeの中で言語サポートに確かJavaという 文字を見た気がするのですが，Javaというの組込み使えないというのは定説にな っています．でも，RealTimeと名乗ったケースツールの中で実装言語の中にJava というのが出てきたので，非常に興味を持ちました． じつはJavaは組込みでも使えたりするのかな？ とかすかな期待を持ったのですが， みなさん，その事については，どのようにお考えですか？ ラショナル： 名前を出されてしまったのでラショナルが最初に答えたいと思います． Rose RealTimeなんですが，なぜこの名前を付けたのかと，SODEC/ESECの時に， 製品の担当マネージャ（アンドリュー）が来たときに問い質したのです． そうしたら「俺も失敗した，この名前を付けたためにみんなに誤解される」と 言ってました．（笑） 製品名を決めたのは３年ちょっと前の話なのですが，当時，RealTimeとつけたのは 深く考えていなかった……Roseと違いが解れば良いという感覚でつけたそうです． では，RoseとRoseRealTimeとは，何が違うのか？ RealTimeとついているために本社の他のマーケティングスタッフも実際に製品を 理解せずに組込み向けときめつけてしまったりと言うこともあるようですが， 実際にはGUIの無いアプリのコードをある程度自動生成しましょうという目的で 作られています． 具体的には，チケッティングシステムとかハイスピードコピーとか大判のインク ジェットプリンタなどに使われてきたものです．最近，本社が組込み向けといって 売っているので我々もすいませんね……と良いながら売ってるというか…… ——えっと，何の話でしたっけ？ （Javaです） ああ，Javaでしたね，ここから本題に入ります．まずなぜJavaをサポートしているかと いえば，Sun Microsystemsからの強烈なプレッシャーがあります．（実は！） RoseでForteサポートしている関係がありまして，Rose RealTimeを何とかしろと． じゃあ，J2SEとMEはサポートするという事になったんですけれど， 「Roseでソレをやっちゃいかん」という事になりまして， じゃあRose RealTimeにさせようということになりました． Java2のJ2SEとJ2MEのフレームワークをサポートしているという仕組みになっています． じゃあ，これがリアルタイムシステムに使えるかといえば，それはまた別の議論なので くれぐれもご注意下さい．（笑 渡辺： Rose RealTimeがそういうネーミングだと思わなかった……．イージーに Rose RealTimeというから（きっと）リアルタイムなんだろうと思ってました．（笑 javaでしたっけ．例えば，今日NECさんが携帯の話をしていましたね． ベースバンド部とアプリケーションプロセッサ部になっていてという話です． きっとアプリケーションプロセッサ部は，Javaチップが入るんじゃないかなと． そうするとjavaは有力な言語の一つになるのではないかと私は思っています． CTC： CATSの渡辺さんと同じようなところにアプローチしています．組込みで実際に 使われているのはほとんどCだと思います． 豆蔵： Javaは，既に携帯とかナビとかで使われているので既に使われていると言って 良いでしょう．javaは，javaの特徴があるのでそれを生かせるところで使えば いいと思う．リアルタイム性の問題はあると思うのでC/C++などと使い分けて いけば，良いじゃないかと思います． 二上： 今日，MDAの話でていましたが，後何年かするとJavaの構造を作りたいなと思 ったらセマンティクスの構造を定義して使えるようになると思う． ただ，ツールベンダーとして直面している問題は，ツールの枠組みがあっても， それをうまく使える人が少ないということです． 例えば，携帯電話の電話というクラスを作って通話というクラスを作りました． そのクラスを定義するメタなUMLモデルを作ると言うことをやる方向へ 現状は，向かっている． じゃあ，これでjavaのコードを生成するためのxmlなりのスキーマを自分でかけるか？ と聞かれるとしんどい訳です． 理論は，あるんですけれど，やっぱり実務には距離がある． 使う人がいないとツールベンダーは作らないのが現実だと思う．そういう意味では， ベンダーさんたちに万札をどーんと見せて，これで「俺のjavaを作れ！」といえば きっとすぐ作っていますよ．お金には弱いですから（笑 ただそこで，ちょっとみなさんと意見が違うのですが，javaはちょっと問題が あってリアルタイムにはちょっとね，というが普通なんですけれど，私は，java みたいな物こそ，リアルタイム性について「javaで作ってすいすい動くのかな？」 という風に，量産する前に検証できないとまずいと思いますよ． そのときこそ，さっき言っていた実装上の問題をツールベンダーがサポートする 部分を用意しなければならないと思う．でもそこまで到達していないのは， とても残念だと思う． Javaは，リアルタイムの要求分析とか設計の分析が必要なマーケットだと思う． 会場から： 個人的にツールベンダーさんに期待することなんですが，コードの自動生成は 必須だと言っていました，今後それは重要になるとおっしゃっていましたが， ことjavaになるとこれはかなり難しい問題だと思います． 携帯電話でJavaが使われるようになったのですが——どのくらいの方が実際に ゲームを試されたか分からないのですが——非常に品質にばらつきがあります． それこそ驚くほどすごい物からやっぱりjavaだなというものまで． Javaで作られたものには書く人によって非常に品質にばらつきがある．本当に Javaで作ったのかと思うものがあれがやっぱりJavaだなというものもあります． Javaで非常に簡単にソフトが書けてしまいますが，本当に組込みソフトとして成 立つようなソフトを書くのは非常に難しく，ある意味アセンブラよりも難しいと 思います．そうすると，そういった言語を本当に自動化できるのかというのは非 常に疑問があります．そういったところで石山さんのおっしゃる職人気質という ものは必要なのでは無いかと思っています． おおかれ少なかれ言語によって，Javaだからという問題ではなくていいコード悪 いコードは当然ながら存在します．コードの自動生成が悪いかというのは，同じ ような繰り返しの手間を省くために，自動化すれば言いと思います．自動化でき ないところは必ず残るわけで，そういうおいしくないところはどんどん自動化す ればよい．あと話は戻りますが，時間の問題を本気で考えてほしいなと思います． 携帯のように制御部とアプリケーションのように分かれてくると，本来組込みで やってきた制御の問題ではなくていわゆるビジネス系の従来のソフトウェアが扱 ってきた部分は，従来の手法が追いついておらず，この部分はオブジェクト指向 でやると割り切ったほうがいいと思います． オブジェクト指向の思想が無い人にこれをなつかせようとすると，バージョンア ップの思想がない，ハードウェアが変わればソフトウェアがころころ変わってい しまうような下のほうのレイヤーの部分で，なまじ継承のようなものを使うと， それに束縛されて次のものがかえって作りにくくなる．これは，大域変数を撒き 散らしたソースコードのようなものだという意見が出てくるんですが，これにつ いて専門家の方に意見を求めたいんですが． オブジェクト指向に関して聞かれる意見なのですが，継承はグローバル変数と 同じだという意見があります．バージョンアップの思想があまり無い……組込 みのシステムの下の方のレイヤーでは，なまじ継承みたいな物を使ってしまう とそれに縛られてしまい，次の物がかえって作りにくくなってしまう……グロ ーバル変数をまき散らしたプログラムと同じだという意見を言う人がいるので すが，オブジェクト指向の専門家の方はどのようにお考えか，聞かせていただ きたいです． ラショナル： 二上さんに逃げられたので私が． 我々が通常お客様にたいしてどう答えているかというと，我々が提供するツール で実装できるところと出来ないところの切り分けをまずしましょう，そのための アセスメントをさせて下さい……というスタンスです． 複数のツールを評価しているケースもあると思うのですが，ある分析モデルが このツールだとマッチして，別のツールだとマッチしないケースがあります． よくそれで「ラショナルさんパフォーマンスわるいじゃん」って言われてしまう 事もあります．当然，その逆もあります． もし，そのへんでお困りの方がいたら相談してもらえれば，何かしら サジェスチョンはできると思います． 渡辺： えっと，継承という話が出たのですが，いわゆるスーパクラスでしょ． スーパクラス作るのってすごく難しいんですよね． マイクロソフトの MFC ひとつとってみてもね……むちゃくちゃです． マイクロソフト"ですら"っていって良いのか，"だから"だと言って良いのか よく分からないですが．（笑） 基本的に初心者に継承なんてやらせるなんて，とんでもない話だし，組込みは インスタンスベースでクラスを単体でぽこぽこ作ってればいいと思う． そのくらい割り切らないと，教科書にいっぱい出ているからと言って関連を 引きまくったらハマっちゃうだけだと思う． まあ良いスーパクラスを作るとというのはいい話題で，そういうのは豆蔵さんとか プロフェッショナルのコンサルを受けて良いライブラリを作るのが良いのではないか と思います． 青山（北陸先端）： 継承．その目的というのは，共通部分と個別部分を分けたいからで、グローバル変 数と基本的な目的は同じなんです．でもグローバル変数は間違いが起こりやすいか ら継承を使うという話です．よくオブジェクト指向の本では継承を強調するんです が，継承と同じようなことが集約でもできる．継承は親子関係が強く面倒なことが 出てくるので，あまりやっちゃいけない．方針としては集約できることは集約して， できない場合は継承を使うというのがガイドラインです． 大事なことは何かというと，オブジェクト指向で問題なのは，勉強したから出来る ワケじゃなくてデザイン・設計力をつけないとダメなんです． 例えば交換機でいえば，10万件の同時接続を考えると最悪ケースは出来ない． これを単純に作ると10万件同時につなげる必要がある． 言いたいことは何かというとオブジェクト指向を使ってどう設計するかという 部分とオブジェクト指向を使ってもどうしようもないところがある． そういう意味で，ちゃんとコンサルティングとサポートが必要なんだと思う． 南角： ちょっと経験の話なのですが，組込みとしてはもっとも高度というか……． たまたま完全なオブジェクト指向で作ったシステムとC等の従来の方法で作った システムがあったっんですよ．で，オブジェクト指向の方は，キャッシュの ミスヒットがCで作った物に比べて500倍あったんです． こういう点は，オブジェクト指向の専門家の人は，あまり問題にされないと 思うんですが，組込みやっている方からするとキャッシュミスヒットが500倍は 許容できる値ではないです．一例なんですが，実際そういう例もあるのです． もうすこし，CPUの方も考えて話をしていただきたいなというのが個人的な意見 です． 会場から： どうしてオブジェクト指向だと500倍になっちゃうんですか？ 南角： 継承とかやると関数コールに…シーケンシャルじゃなくなってしまう． たぶんそのあたりが原因だと思います． 会場から： それはメモリマネージメントの問題で……．OSの方でも〜 南角： 組込みのアプリをやっている人はMMUも考えないので，メモリマネージメント というのはナンセンスなんです． えと前の方だけで議論するのはまずいですね．どうぞ． 会場から： 私も組込み系でオブジェクト指向を使うんですが，普通に業務用のアプリと同じ ような感覚でオブジェクト指向を使ってしまうと，サイズが非常に大きくなって いまいすが，ノウハウを駆使すると結構楽に作れたりします．また，フレームワ ークを作っておくと，人が変わっても，I/O変わったからちょっと直してよとま ったく知らない人に渡しても，ちょこちょこっと直してやってくれるというメリ ットがあります． 会場から： 私は組込み屋さんこそオブジェクト指向を使うべきだと思います．組込み屋さん とこのソフトウェアさんは，自分の書いたソースコードがどういうバイナリに落 ちるか理解していると思うんですよ．コンパイラが何をして，どんなコードを吐 いてくれるか知っているんですよ．C++でバーチャルを使うとメモリ効率が悪く なって，メソッドコールでも時間がかかるようになるんですが，ここを理解して いるとなるべくバーチャルを使わずに，メモリ，実行効率を上げようとする． Javaでも同じことでバーチャルマシンでなにをやっているかを理解していれば自 然に効率のいいコードを書くようになると思うんですよ．だから，組込み屋さん はオブジェクト指向の実装言語をどんどん使っていくべきだと思うんです． 要は，業務用のアプリと同じ感覚で使ってはいけないと言うのがあって， どうやって書くのかにかなりノウハウがあると思います． 賛同できることがあって，私は組込み屋さんほどオブジェクト指向を使うべきだと おもうのです．ソフト屋さんは，どんなバイナリの落ちるのか理解しているので， なるべくVirtual使わずに効率を上げようとか，工夫をします． そういう理解をした上で，どんどんオブジェクト指向を使うべきだと思いますが． 南角： じゃあ，人をかえて大山さんお願いします． 会場から： いろいろ思うところはあるのですが，さっきの問題は，スパゲティの問題かと思 いました．ジャンプが発生しまくるというか粒度の問題かなと．粒度の小さなメ ソッドがいっぱいあるとパフォーマンスが落ちるのではと思いました．粒度の細 かいところまでやるとあまり意味がないのかと思います． ところで，ベンダさんに訪ねたいのですが，とことんオブジェクト指向でやると あまり有り難みがないと思うのですが，実際やられるときにどこまでやれている のですか？ （「とことん」て，一体どこまでですか？） インテジャーまでオブジェクトと見なしてしまうような所までいくことは 無いと思っているんですが． ある程度の粒度のところまでオブジェクト指向で出来ていればあとは， 何で出来ていても良いのではないかとおもっているのです． 分析的には，もっと荒いところで止めちゃって，そっから先は，設計者に 最良で任せてしまっても良いのではないかと思いますが． ラショナル： どうコメントした物やらと，良い言葉が見つからないのですが……． 分析設計の粒度のどこで止めるかというのは必ずしも組込みの世界だけの話では 無いと思っています．どこのレイヤまで落としていくのかというのは経験と勘に 依存している部分です． 例えば，ラショナルはコンサルタント20人くらい抱えていますが，実際に粒度を 最適に答えられる人間は数人しかいないと思っています．個人的に．非常に デリケートな問題なのではないかと思っています． 渡辺： うちではオブジェクト指向というよりUMLなんですよね．結局，共通言語がほしい ということなんですよね．結局UMLだとクラスとか出てきちゃうんでオブジェクト 指向なんだけれど……実装はCとかアセンブラでやっているし． じゃあ，要求仕様を外注さんとかインターナショナルで見ようとしたときに， 今みんなが読めるノーティションはUMLなんじゃないの？ という感じ． 「オブジェクト指向でやっているか？」 と．訪ねられるとそうでもないようなお客さんが多いです． CTCさん： 質問を確認させて下さい． 「オブジェクト指向でどのレベルでツールやUMLを使っていくのが良いか？」 という質問ですか？ rhapsodyでは，実装コードまでいけるのでそこまで使っていただきたいという のが本音ですけれど，実際にお客様のUMLの経験度が少ないと実装のコードを 吐いてもあまり意味がないと思います． その前の段階ですが，コードの生成をしないで，モデリングだけするツールも リリースしています．お客様によってケースバイケースなんですが，rhapsody の本来の目的としては，実装コードまで含めています．ですが，実際に日本の ユーザさんでシステム全部をrhapsodyを使って実装した例は無いです． コードを生成するという以外にも，検証の精度を上げるツールなど各社さん リリースされていますのでそういった所とあわせてツールを使うという所 でしょうか． 福富： どこまでオブジェクト指向でやるかということですが，オブジェクト指向でなぜ やるかという目的をはっきりさせればその辺は見えてくると思います．例えばシ ステムに，再利用性を求めるとか，リアルタイム性が必要だとかメモリが厳しい とか拡張性を求めるとか，その辺の要件トレードオフ，どの辺をクラスで作るか など，そいうことを明確にすれば大体決まってくるのではないかと思います． 二上： 私は，最後の一ビットまでツールでやりたいと思う．smalltalkはintegerで終わ ってる．bitまでいってない． 中島(早稲田大学)： 質問ですが，今までオブジェクト指向，例えばJavaとか組込みではリアルタイム 性とかいろいろ問題があるという話ですが，世界的に見るとUMLでは，リアルタ イムUMLとかありますし，リアルタイムJavaとかありますし，それではなにが組 込みでは問題なのでしょうか．リアルタイムUMLでオブジェクト指向をやるとい う話や，リアルタイムJavaがあって，Javaでリアルタイムを書くリソース制約が あるようなシステム上でやるような話があるんですが，それがなにがいけないの か，こういった新しい提案があってパフォーマンスアナリシスとかできているに もかかわらず，それがいけないのは組込みではやはり問題があるんでしょうか． 二上： 今，ツールベンダとしてなかなか皆さんの要求を答えられない部分は，モデルか らリアルタイム制限を皆さんが望むような形で満足するコードを一発で生成でき ない．自動生成では，時間がかかるとか，メモリをたくさん消費してしまい，人 間の知恵を絞りながらハンドコーディングで書くのと比べると，ツールで生成し たコードではどうしても荒削りになってしまう．昔，8ビットプロセッサである システムを制御するオブジェクト指向をやったんですが，コンストレインを全部 満足し，製品にもなったんですが，問題はそこまでところへ持っていくとなると 相当にモデルを書いたり，アーキテクチャ考える人間にスキルがないと製品化は むずかしかった． 福富： オブジェクト指向によってリアルタイムが出ないという問題が実際にあります． これはポリモフィズムやバーチャル関数にどうしても時間やROM，RAM食ってしま います．こういうところは仕方ないので従来のやり方，そのまま適用していく． 例えば，割込み処理の中にオブジェクト指向を適用したりすることで現状は逃げ て設計しています． 中島： リアルタイムUMLとかだとスケジューラビリティアナリシスとかパフォーマンス アナリシスとかきっちり出来ているのに．なぜ（ツールベンダが）古い方法論を 使い続けるのかよく分からない．どうしてでしょうか？ 松岡： 学術的なレベル……UMLのこうあるべき姿というのをUMGなどでは検討していて， 制約条件なんかをどういう風に盛り込もうとか，ノーティションだとか現場レベル では無い，上から見たところのレイヤでは出来ます．例えばリアルタイムUMLとか ですね． つまり，いわゆる設計図は，確かに出来てます． しかし，ツールで実際に実現する部分．それをどうやってコードに反映するか というパーサのようなアルゴリズムが実現できていないのが実現です． これがツールベンダーでリアルタイムUML等が実現できていない最大の理由だと 思います． 図面上でインプットした物がちゃんとコードとして出てくるようなブラックボッ クスを我々が用意できれば実現すると思います． 似たような話ですが，コンパイラで考えると，Cでコードを書くと吐き出された アセンブラは，アセンブラを書いている人から見るとなんだろう？ というような物になります．これがUMLとアセンブラになるとさらに乖離がでる． このギャップをどれだけ埋められるかがツールベンダの腕の見せ所です． 渡辺： 古くから言われる「銀の弾はない」というやつだと思う． ステートチャートとってみてもアクションの記述の粒度がめちゃめちゃですから それを何とかしようとすると，それ向けの方法論が出てくると思う． それをちゃんとしようとするとポートとかルームとかいろんな概念ができて， いろいろ言われることになる．結局，札束積んでくれれば何でもやるんだけどね． CTC： UMLの記述方法については，ケースツール使ったときにその制約条件がコードの 反映されないという問題があると思います．そういったところはツールの特性を 考慮してお客様の方が選択して注意して使っていくことが必要なのかなと思います． 豆蔵： 組込みだから特別なんだというのではなくて，共通点の方が多いと思う． ソフトウェアや開発組織が抱えている問題というのは組込み系以外も似たものが あると思う．そういうのを出していった方が進歩があると思う． 悪い言葉でいけば，局所化進化しているのではないか？ 恐竜になっている気がする そうじゃなくてもっと一般化進化しようというような印象はある． 組込み向けであろうがそうじゃなかろうが，ソフトウェアエンジニアリングの基礎 あるいは何を目指すべきなのか？ という所をきちんと押さえて議論しないと無意味 でしょう． 南角： 問題点は何かというのを絞れ，それ解決してやるをというのは困る． 石山： 今の話を聞きながら私が疑問の思っていることがあって出来れば挙手して頂きたい のですが． オブジェクト指向で再利用が非常に楽になると言われいますが，オブジェクト指向 で再利用がうまくいくと感じている方挙手願います． （1/4くらい挙手） オブジェクト指向で再利用がうまくいかないと感じている方？ （ごく少数挙手） ああ，少ないですね． 私は，オブジェクト指向は再利用が出来ないアプローチだと思っています． 一見，再利用出来るアプローチに見えるのですが，もともとオブジェクト指向 というのはある物をしっかり分析しましょう！ というスタンスですよね． その点をふまえると前に作った物（分析）を再利用するというアプローチは おかしく感じるのです． 今見ると再利用できると感じている方が多いようなのですが，どのレベルの オブジェクトを再利用しているのでしょうか？ コード，分析，設計なのでしょうか？ 再利用の観点から見て，ツールがどうサポートしているのか等の話が聞ける と参考になりそうです． ラショナル： 今のお話を聞いてラショナルの一般的な回答は， 「コンポーネントで再利用できる部分」と「フレームワークの再利用ができる部分」 またシステムによって両方が適用できる部分があると答えています． ラショナルはコードという言い方をしないんですね，RoseにしてもRose RealTimeに してもあくまでもモデルで設計をするツールです．RoseRealTimeは確かにコードを 出しますが，我々はこれをインターミディエイトランゲージだと考えています． 最終的にオブジェクトを必要としているコンパイラがコードを必要としているから 出すというとらえ方をしています． ですので，我々が再利用といった場合は，コンポーネントとして分析設計の中で 出てきたくくりか，もしくは全体のフレームワークのいずれかを再利用しようと 言っています． 実際に再利用について金融系システムで事例があります．そして，効率が確実に 上がっているという結果が数字で出ています． フレームワークをそのまま持ってきているのですが，バグがコンポーネントによって 1/100〜1/1000くらいに減っています．工期も今までと比べて1/2〜1/3まで短縮でき ているという数字がでている． これは組込みでも同じで，適合できる部分は，このくらいの数字がでると思います． もちろん不適合な部分もあるのでそこは，切り分けをして行かなければならないと 思っています． 会場から： コードの再利用にしても分析段階や設計段階でうまくいっていない物を再利用する のは難しいと思う． 再利用は現実に高い生産性が認められています．10倍くらい生産性が違います． もう一つ言いたいことは，再利用というのは人でやる物ではなくてやはり仕組みが 必要だという事．あと，勉強しないとやっぱり出来ない． ツールベンダの人はノウハウをためてコンサルティングなどやって頂くともっと 良くなると思う． 青山： UMLをどう使うかというノウハウ，例えばタイミング問題とか，ステートチャー トのアクションをどう記述するかというものツールベンダさんはいろいろためて， ユーザにアドバイスして，コンサルタントの部分をやっていいただければいいな と思います． 南角： そろそろ時間です．そろそろ閉めたいと思います． 最後に何か？ 東陽テクニカ： コンサルティングを開示せよと言われちゃったので一個だけチャレンジ問題を． （三角形の証明問題をオブジェクト指向で解く問題の紹介） 南角： 時間が過ぎているのでそろそろ終わらせて頂きます． 結論が出すのが目的ではないのですが，問題点を明らかにすることから始めたい と思っていますのでこれで良かったと思います．どうもありがとうございました． =============================================================================== 【記録者自身の感想】 ツールベンダ側と使う側での間やまたお互いにオブジェクト指向開発についての 見解の違いにより，議論の論点が食い違ったり，話がなかなかまとまらなかった ような感じを受けた．