セッションB1：設計と実装のギャップ　−シームレスな開発を阻むもの− 司会 −設計の時点でクラスが4つだったのが実装するときにコーディングしていくと 　クラス数が200に増えた。 −設計をしていて実装するところでやり直し。 −核のところだけをやっている。 −設計から実装までの間にいくつかのギャップがある。 −要求仕様、-> 抽象化　-> 具体化 −抽象化したものを変えなければならない。 −要求仕様書を細分化したときに前と同じことしか書いていない −隙間がある。 −メンテナンスが困る。 ネットジーンの村山さん −JAVAはプログラムするうえでオブジェクト指向が関係ない −そもそも(オブジェクト指向を？)使わなければよい。 −プログラムするうえでオブジェクト指向はよく使う 司会の方 −底が見えない ネットジーンの村山さん −コーディングしてから判断する。 −変数の数が増えるなど書いて見ないとわからないことがある。 藤倉さん −一人で作れるものならばそれでもよい。 −それ以上だとコードを書きながら作ることは出来ない。 −デザインパターン？ 司会 ーいつの段階でデザインパターンを使うのか？ 川口さん −難しい問題。 −成熟度の高い組織でないと使えない。 −要求仕様をモデルかしてないと場当たり的なものになる。 −設計をちゃんと定義しないとだめ。要求と設計は別。 ーいくつかある設計モデルに対し実装が1対1でないとだめ。 Aさん −要求と設計のギャップがある。 川口さん −ひとによって要求と設計が違う。 −設計モデルは実装を何でやるかまで考える。 −最終形の設計モデルににたいする実装は1つ −最終設計と第1次設計のギャップがある。 Bさん −一人か二人で設計、実装までやるのがほとんど。 −抽象化の中に具体化がある。 −実装を考えながらやらなければならない 西山さん −規模によって違う。 Cさん −二人でやると分担が発生する。 −決めたとおりにやらなければだめ。 ーインターフェースどおりに動けばいい。 −経験すればクラスが４から200に増えるようなことはない。 司会 −保守性が重要。 Dさん −ドキュメントとインプリメントを一体化させる。 Eさん −モデル化を組み込みの人はするのか？ −ギャップがあるのは当然で要求から実装にいきなり落とすのは難しい。 −現実からモデルへ実装するとシステムが出来る。 −マッピングするときにいらないものをそぎ落とす。 −組み込み屋さんはオブジェクト指向で隠蔽されなければならないところ 　が気になるのでモデル化が苦手なのではないか？ −現実に近いハードウェアモデルに拘束されてしまう。 −抽象的にモデルを考えるのが苦手。 −アスペクト指向 −自販機の紙コップの話。(設計の段階でタイマが早くでてくる。） Fさん −組み込みソフト屋はハードという制約がある。 −人工世界をベースにしなければならない ー苦手意識がある。 Gさん(=Eさん？) −組み込み屋さんはスペックが頭の中にあり最終的なスペックに引きず 　られてしまう。 −ある時間までに作らなければならない Hさん −何かを書いているときそれを実現できる方法がないとかけない。 −なぜそう考えてしまうのか？ さとうさん −設計と実装は一対一 −設計は実装を意識しておかないと実現できない −要求からモデルへのノウハウが必要。 ？ −メソッドは複雑ではない ー実装するための設計が必要 藤倉さん −要求仕様に時間の制約が入っているのが組み込み。 −タイマをいれるといけないとおもうことがギャップを生んでいる。 ？ −抽象化している時点タイマのようなもの出てくるのはなぜか？ ？ −プロダクトライン永久に同じモデル使わなければならないことが制約 　を生んでいる。 −抽象的に書かなければならないと思うことがギャップを生んでいる。 鈴木さん −抽象度の高いものだけをおいておくと..... −モデルの世界では省略されているがそれは悪いことではない。 ？ −詳細化されていくことで気付くことがある。 ？ −組み込みの世界は理想ではない。 −故障などを考えると自然と増えてく。 ？ −要求の中に明文化されていない要求が多くある。 −要求仕様を拡張しなければならない。 Iさん ー要求仕様をどうとでも書けるというのは間違い。 ？ −実際すべての要求を考えてから設計することはできない。 Iさん −要求仕様は完璧を目指すべき。 ？ −暗黙のうちに理解していることが多い。 −エラー処理などすべての要求を書けるのか ？ −書けないことも考慮すべき ？ −お客さんはエラー処理のことについて知らない。 ？ −書かなくても明白な要求がありうる。 ？ −多目的な視点で漏れがないようにする。 −それが出来ないを設計でカバーするのはちがう。 ？ −要求仕様はハードウェアに関することが含まれていない ？ −要求モデルと設計モデルは別物。要求は普遍的、要求と設計をごっちゃに 　してはだめ ？ ー要求仕様ありきだが設計者が詳細化する時点でフィードバックする。 NECのまつうらさん −上流設計フィードバックのためのモデル化 ？ −コーディングしたあとで調整する。 −アジャイルにやったとしても全員がどのような影響があるのか... ？ - 最終的に信じられるのはソースコード ーソースを書き換えたときにコメントを書きかえないことがある。 −コメントを読みながら理解していく。 −ソースを変えたらコメントすることを徹底する。 ？ −ソースコードに対する比重が大きくなる。 −要求仕様を書く時点ではUMLは重要 −最終設計をUMLで書くことは全く意味のないものになる。 ？ −思考経過を残せない。 ？ −ウォータフォールモデルでもプロトタイピングする？ −きっちりと規定することがいいのか疑問 高田先生 −実行可能なモデルではなく検証可能なモデルが重要 −UMLで書くのはよいが最後のシステムと途中のシステムが合致しているか 　検証できることが重要。 −合うか合わないかを判定するツールが必要 ？ −JAVAで書いている場合低レベルなモデルはコードに入っている。 松本さん −プログラム検証は人間の知識を入れないと出来ない 西山さん −要求とはなにか？ −ソフトウェア屋と組み込み屋では定義が違う？ −組み込みの世界では制約があるうえでの要求がある。 すぎやまさん −要求仕様を固めることが出来ないのが問題 −情報があれば要求からプログラミングまでスムーズになる。 ？ −現実の世界をモデル化できれば組み込みのモデルが固まる。 −現実の世界を物理モデルにできるかによって.... ？ −要求仕様は書かれていない −粒度を大から小へ −オブジェクトが要求仕様になっていく −何とかマネージャというのが増えていく −昔は要求仕様をきっちり書く。