セッション4A：「オブジェクト指向分析・設計」会場規模：約100人参加人数：約35人開催時間： 14:00〜16:00 チェア　：高田氏(豊橋技科大　講師) ＊全体の流れ：　ポジショントークのあと、いくつかの事例が述べられた。前半は、オブジェクト指向は体系的に扱え有用であるといわれるが、その有用性について具体的な部分に焦点をあてて議論が交わされた。特にオブジェクト指向における再利用性、拡張性についてはかなりの議論が交わされた。また構造化プログラミングの拡張といった意見も出た。後半は、他人に設計やシステム概要を説明する際にオブジェクト指向が使えるかといった類の内容が主として議論され、新人に対するものや、ソフトウェア技術者でないハードウェア技術者などに対する場合などについて振れた。また、オブジェクト指向を用いた設計を行う際には、優秀な技術者が設計を担当することにより、再利用性、拡張性に優れたシステムを構築可能であるという意見に基づいて、オブジェクト指向は優秀な技術者の数を減らすことができる方法であるという見解が出た。しかし、組み込みに対するオブジェクト指向の有用性はまだ未知数であり議論の分かれるところがあるが、実例が少ないという理由も含んで、オブジェクト指向における設計の妥当性が不明という意見もあった。特に拡張性などの評価においては何年間かのスパンで製品を扱う必要がある。最後にまとめとして各企業などにおける組み込みシステムでのオブジェクト指向導入の失敗、成功事例についてもう少しオープンにしてもらえると対象事例の比較が可能であるという意見で締めくくられた。＊セッション内容ポジショントーク：　デザインパターンを使えばいいのはわかっているが、組み込みに使用するとどうなるのか、会社で使用するのはどうか、いろいろ話している中で、リソースが少ないなかでどうか、リアルタイム性の問題など岸さんの話を加味したらどうか、本当に使用できるのか、世の中の組み込み系で適応してできたものはあるのか、時折は学会誌などに掲載されているが、実際あまりない。開発の苦労などをききたい。　組み込みに適応するのは、教育の面でパラダイムシフトが必要なので、問題になるのではないか、実際にコードにどうおちるかイメージがつかめないのでどうなるのか、JAVAの組み込みのシステム、C++で適用した例はあるのか、オブジェクト指向を分析設計して Cに落ちることをされているならば、その実例、世の中のその動きに対する疑問点を聞きたい　コード生成やインプリは大したことでない、組み込みは、インバータや自動車の制御などに適応例がある。それより大変なのは設計である。組み込みの分野では、何をオブジェクトとするか、その次に、分析することが楽しくなり、こだわりの暴走をいかにくい止め、その先に進むのかといった問題がある。　お客さんの要求仕様を取りまとめる段階にソフトウェア技術者がいない。スパイラルモデル的にやっていこうとなる。我々はウォータフォール型でやってしまいがちで、お客さんの要望になかなかなじみにくい。このあたりをどうしたらよいか、ということを聞きたい。製品をつくるというところにオブジェクト分析設計をどう取り入れるのかを聞きたい。　オブジェクト指向は十何年か前に、使えないという自覚を得た。この時は SmallTalkを勉強した。業務上必要でないのでそれ以来やってない。20何年か前に作成されたソフトウェア資産が今も使われている。これは今から見ても良い粒度でオブジェクト指向分析となっており良く出来ている。今からあえてやったとして、オブジェクト指向をやろうと言っても、OAよりOBにすすんでしまいそう。　開発効率向上のためオブジェクト指向を適用した。制御ソフトの開発にはシステムの振舞いに重点を置き状態遷移図ベースで分析している。オブジェクト指向の良さは、プログラミングで知っているので、その点に興味がある。それを考えた時に、制御系は振る舞いを示すのが大事なので、オブジェクト指向でどの辺まで機器制御系を示すことが可能なのかといったところがよく解らないので、そのような事例を伺いたい。また、オブジェクト指向がどのあたりまで有用であるかの見極めのラインが知りたい。ソフトの要求を出すところが、その要求仕様のレビューでオブジェクト指向がハードの人にわかってもらえるかといった、ソフトの世界に閉じてしまうところが難しいと考えているため、そのあたりについて議論して欲しい。　オブジェクト指向ってなに？人によってどうもイメージが違うんじゃないか？みなさんがどう考えているのか？体系的な枠組みをオブジェクト指向っていう人もいれば、カプセル化、情報隠蔽、インヘリタンス、ポリモーフィズムなどどこが本質なのか設計手法など不透明な部分が多い議論：・オブジェクト指向の本質とは？　オブジェクト指向の本質は実際のところよくわからないが、最近のコンポーネント技術は昔の人から言えばそんなものはオブジェクト指向ではないと思うかもしれないが、今ではすべてをひっくるめて言っている。分析の手法がとりあえず大事、機能をどう分析していくか、オブジェクト指向では、機能と情報といった複数の視点で見ていく。そこで書かれている、オブジェクト、つまりモジュール化の単位、疎結合で独立性の高い単位でモデル化していくモデリングの技術ではないかと考えている。その運用上の問題の性質をとらえて、反映していくかといった部分が大事だと思ってる。ただ、この議論に深入りしたくない、設計の本質はそんなに変わらない。設計の目指している目標は昔から同じ。定義論は意味が無い。　オブジェクト指向の大きなポイントは、分析の視点が多面的であること。手続きだと、機能がメインの視点となる。オブジェクト指向は、機能だけでなく情報をも視点にしている。　分析設計の結果が、オブジェクトという、モジュールのようなものとして形としてあらわれる点も評価すべき。　構造化は制御・論理を入れて、今のモジュール化とはあまり関係ない。次に来たのが人間の抽象的な捉え方。メソッド、バーチャル関数などがそうである。抽象化されている。抽象化することで広く認識できる。　モデル化する場合には、擬人化して考えた方がよい。　メソッドが動詞になる。擬人化したモデルに対して命令することが、オブジェクト指向。Cでもこれをできなくないし、人によってはやってる人はいるだろう。　オブジェクト指向は擬人化であり抽象化である。　体系的に設計すること。システム設計オブジェクト指向でやることが大事なのではないか。カプセル化してできるということが、システム設計が見通し良くできるという点がうれしい。　最初に出てきた時のオブジェクト設計のときは、モジュール化を強く意識したていたが、そのときは、オブジェクト指向はカプセル化、情報隠蔽がキーになるのではないか。　オブジェクト指向をやる前には、構造化設計がはやっていた、92年だったと思うが、当時高価な構造化プログラミング設計ツールを購入したが作画ツールで終わってしまった。オブジェクト指向でやってもわかりにくいという話があったが、その話を聞いてみたい。　今のオブジェクト指向設計ツールと言えば、状態遷移を書くツールと勘違いしている方もいらっしゃると思うのですが、その辺はどうなっているのでしょう？　状態遷移というテクニックはオブジェクト指向の前からある。オブジェクト指向にとりいれられてきた。状態遷移をつかってればオブジェクト指向ということではない。オブジェクト指向は色々なものを取り込みながら発展してきた。構造化設計は古いけど、そのいいところをオブジェクト指向は取り込んでいる。　UMLのようなものもあるが、動的なものとしてとらえればいい。　インターフェイスと実装を分離した点がいい、実装だけ取り替えることができるという魅力がある。動的モデルによって、ステップパータンによって、詳細なモデルの手段が、時系列の振る舞いが明確になる。振る舞いのモデル、シミュレータによる動作チェック、コードジェネレータもできる。　構造化設計というのは、要求と実装のギャップがあるが、オブジェクト設計をすれば、要求と実装のギャップが少ない。あとは、現場の問題。　実際は設計・実装の順序などで、作り方が難しい。だけど、期待できるのでうまくやりたい。・オブジェクト指向のメリットは何か？　メリットとしては、再利用性、拡張性、体系的に設計できること。　では、何故、オブジェクト指向だと、再利用性、拡張性があがるか？　オブジェクト指向だと再利用性が上がるのかは疑問。コレクションクラスはSTL が出てきてやっと使われるようになった。　またMFCなど体系が大きすぎるのでその文化に入り込まざるを得ない。それ以外のところに逃げようとするときに再利用性はどうなるのか。　テンプレートだとMFCみたいに入り込まざるを得ないということはない。テンプレートはこういった独立性という点でよい。つまり浅いインヘリタンスがよい。 (インヘリタンスよりテンプレートなのか。) 　インヘリタンスは2、3段なら良いが、10段、20段だと人間の理解をこえる。 (他から与えられたものに取り込まれるという言い方はデメリットに聞こえるが自分のとこでつくって枠にはめるという効果はあるのでは。) 　でもMFCを与えられ取り込まれるのはデメリット。固定する方向に行っている。　オブジェクト指向の利点は、枠にはめるというとこめが大事なのではないか。　ソフトウェアプロセスについての話でもあったが、枠組みを決めるスーパー設計者がいれば、あとはその枠の中でやればいい。優秀な人の割合が減らせるといったことができるのではないか？　枠を作る人が優秀でないとどうしようもない。ここが大事　インヘリタンスが数段しかない方がいいと言ったが、逆だと思う。小さなシステムなら、全部知らないといけないけど、今は全てを知ると言うことをあきらめる時代。作ってるシステムの全てをひとりが全て理解するあきらめる。　こいつはこう動くよねという常識があれば使えてしまう。というところが重要ではないか。つまり、フレームワークの文化。　再利用性とか拡張性はシリーズオーダーに関しては固めて作れば次バージョンアップするとき使い回せていいというのはあるが、単品モノに関してはどっちでもいい。　お客さんの考えていることすらつかめないし、20年前にGUIは想像できないだろうけど、インタフェイスと内部処理を分離しようとかそういったことは想定できる。　拡張性は書かないのか記述しないのかという問題は、気の利いた設計者がいればいいという問題で、優秀な設計者は、将来の拡張を考慮できるか、そうでない人のためには、拡張性をきっちりと記述する枠組みがいるのか？　拡張性の高いものを作れるのはきっと世の中の一部の人であろう。文化を理解するには、時間がかかるし、教育もかかる。でも、みんな使っているのは、それが必要だから。　優秀な技術者は10人に1人はいないというと話は良く聞くが、その歩留まりを上げるという方法はないのか？　やるべきことは地道に積み上げていく必要があるが、それが当たるかというと別問題で、世の中でいいものほを選んでいくことが必要。いいメカニズムがあったって、いい部品がそろわないとだめ。いろんなことを考えないと、再利用はうまくいかないのではないか。　フレームワークをつくるときに優秀な人がいないとできないというのは、優秀な人は拡張性を考えて作れるから。拡張性を明示的に記述できるものがあれば、それは特別な技能ではなくなる。　地道なやり方としては、モデルを最初にしっかりつくるというのがある　再利用というのは再利用する集団の大きさが重要になる。それが文化。拡張性の話だが、エンジニア的には、市場のニーズである。ユーザーはこうしうものをつくりたいから、そういうものをつくりたいという、　拡張性云々というのは市場の要求。ユーザーさんがこういうのが欲しいという。そのニーズを読まなくてはいけない。市場、世の中が見えないとできない。将来、ユーザーがどのようなのを要求するかというのがわからないと、拡張性がないのではないか。 (コンシューマー用のフレームワークを開発するときは、世の中の動向を読めなければならないということか?) 　そう。エンジニアというのはそういうとこも敏感に感じられないといけない。　難しいのは当然でわかってはいるが、携帯電話のi-modeが数年前では、そんなもの誰が使うかといっていたのがいい例。エンジニアは、技術だけではだめ　オブジェクト指向とは、センスがある人が少なくても大きいシステムがつくれるという方法ではないかと思う。最初に枠を作る人が優秀でありさえすればよい。センスのある人が各セクションに最低一人いれば、いいシステムができるのが今のオブジェクト指向ではないか。 (それだと、部署に最低１人、必ずセンスのある人が必要ということになるが?) そうですね、厳しい。　抽象度を持って設計できなくてはならない。その教育はどうしたらいいのか。それを文化という言葉で片づければ簡単だけど、文化とは何か。センスが要ると言うけど、それは教えられるか。プログラミングはぜんぶセンスという話になってしまわないか。　文化を標準化するということは、同じ制約条件で別の人が設計して文化が同じになる必要があると思うが、そうでないと思う。それが文化ではないか。　ある人の文化を継承していけば、なんとかなると思う。　文化の標準化は難しい。エンジニア自己主張したい人種で、兎に角自分の技術を誇示したくなる。先人が良いものを残してもそれを覆そうとする。次の世代で劇的に変えられてしまうと標準化は無理。その人らにとれば、オブジェクト指向は人によっとみんな違うという。・組み込みシステムにオブジェクト指向設計を用いる場合何が問題か、何が違う　のか。リソース制約、リアルタイム性などはうまく取り込めるのか。　組み込みに向いていないと言うのではなくて、ドメインによって向いてる、向いてないということがある。でも、その差は判らない。向いてないとか、やっても意味がない。コンパイラをオブジェクト指向でやろうと思う人はいないだろうし、意味がない。　制御系そこそやっても、どれだけの意味があるのか。　ビジネスアプリの世界だと規模が大きいので、再利用性の価値がある。　組み込みシステムの場合、オブジェクト指向は対象物に依存する。結局オブジェクト自体をつくり直していかないといけない。　でも、それは抽象化が足りないのでは、　効率を考えると、オブジェクト依存は仕方ない。　ハードウェア依存でオブジェクトをつくらないといけないので、新しいハードに対して作っているとベースのクラスを常に作っていかなければならない。組み込みではデバイスドライバを常に開発していることと同様。・RTOSに関しては？　タスクに分けるということ自体がオブジェクト指向だと言っても間違いではないのでは。既に抽象化されたものを使ってるのでそれがオブジェクト指向だと思う。　組み込みではむかしからオブジェクト指向をやってるということ。・システムが理解できていても、分析は必要か？　枯れた製品を分析する必要があるのか？　新入社員にどう説明するか。やはり、ある程度抽象化した説明図は必要。　人に見せるためのものというものでもなくて、部分を直すためにも全体の把握は必要。大雑把な最低限のユニットの仕様書が必要ではないか。　分析する過程を残すというのが必要です。　このあたりは、分析記述は必要で大事だが、コストの範囲で収まるようにしている。本来であれは、このシステムはどうあるべきかというものなどを分析することが必要。品質の観点などで、理解しているということがどこまでなのかという問題はつきまとう。・スパイラル開発する時に、どのようなユースケースから始めるべきか？　ビジネス系のシステムであれば、正常処理から始めればいいが、組み込みの場合は異常ケースについても実時間内に応答しなければならないといったことも考えないといけなが、そのあたりについてどうか？　制御系、監視系などは、異常ケースがほとんどで、それ以外は、リソースを考えた組み立ての問題。そうすると、ユースケースというのは、たくさんあるなかで、どれからやるかといった選択が必要。解るケースは容易だが、解らないケースは分析を丁寧にやれば、いい選択が可能なるだろう。・スパイラル開発というのはどうか？組み込みシステムにはなじむか？　納期の問題などがあるので何とも言えない。3ヶ月で納期といわれると、1サイクルしかできない。時間が許すなら、スパイラルしたほうが良い。　無理矢理スパイラルでやってみて、1ヶ月でできるところまでやって、そこで抜けた部分は後でやるという手段を試したが結構成功した。　テスト工程でクリティカルなバグがあった場合もそこで切るということでしょうか？　すべてのテストケースでは、すべて完璧というのではなくて、大まかなパスで値が正常だと1ヶ月の段階ではOKと考えた。全てのテストケースを一回目で通すのが目的ではない。品質でやろうとすると回らない。　組み込みだと、ハードがそろわないというケースがよくあるが、ハードがそろっている状態で試されたのか？　すべてではないが、ハードは９割程度そろっていたので、幸いでした。　早い段階で制約を明らかにしておく必要があるが、作り込みは実装のときでよい。分析で考えないと解決策は出てこない。そこは、アーキテクチャを考えないとだめ。論理的にどういうクラスがあるのというだけでは、リソースは見えない。具体的にタスクなどが見えてこないと時間制約が後で出てきて手詰まりになる。　スパイラル開発の中で、1周目と2周目で構成などが劇的に変わるということがあり得るか？　あり得ると思います。実際は、制約は、時間、リソース、機能をすべて満たすのは難しいので、優先度をつける。時間制約は絶対必要なので、スパイラルの最初の段階でしっかりと押さえることが必要。・RTOSタスクとオブジェクトの関係は？　タスクをオブジェクトとして設計する。粒度は認識の仕方、人間がどう設計するか、並列性の問題もある。　一般的には１対多だとおもうが、１対１の対応もあり。もう少し論理的な部分。・リアルタイム性を上げるためにタスク分割をするという視点はどうか？　ひとつのオブジェクトの中に急ぐ処理と急がない処理があるとタスクを分割するといいのでは。　その場合何故一つのオブジェクトになってるの？という疑問が生じる。論理上の意味合いと実現上との齟齬があるってのは本当にそれでいいのか？　RTOSのタスク設計では、周期が違うタスクは違うタスク。一つのセンサーを扱うにはオブジェクトはひとつだけどタスクはちがう。それはありでは？　機能とタスクが全く直交するシステムもあった。機能モジュールはオブジェクトに分割。タスクは時間で分割。・オブジェクト指向で分析、設計したが、それは本当に正しいという判断は　できるのか？その設計の妥当性は検証できるのか？　設計時に妥当かどうかが評価できないとオブジェクト指向に合致しているかということは、今後の議論である。　必要条件をみたしているか目標は満たせているかといったこと。十分条件としては、どういう目的で評価しているか。どういう再利用性が欲しいという場合、それを満たしているか。といった視点。 (何年でわかるか。) 　レビューをして判る事はあるが、実際はそれは判りようがない。・締め：　必要とされていることがオブジェクト指向の専門家に見えてないという面もある。これが必要だというのをみせて議論を喚起するべき。　うまくいった事例とうまくいかなかった事例というのが機能や性質によって違う。このケースは成功する。このケースは失敗するというのもオブジェクト指向の専門家に情報を渡すべき。　全体を見渡してる人がいない。分類ができるように、情報の風通しを良くししよう。オープンに。 5A以上