分科会セッションB1 設計と実装のギャップ −シームレスな開発を阻むもの− 人数: 30人くらい。 会場: C会場 --------------------------------------------------------------------------- 以下敬称略 石山; 設計のときに純粋に核のところだけやっている。 ある抽象度でOKならまた環境条件を追加する。 それを最初から考えられるのか。 要求→設計→実装→評価→商品 のステップの中にいくつかのギャップがありそう。 現実世界に対する要求。 ある抽象化→OK ぐたいかする時、ハード化など。作り方。 抽象化したものを変換する必要がある。 ある経験をした人はなにげなくやっている。 思考の飛躍が必要。 埋められてない隙間があるだろう。 宿口; まだ問題の分析もちゃんとできていません。 少しは目鼻がつけばいいかなと思っています。 仕様書から思っていないようなコードが出てくることがあります。 センス問題と一言で片付けたくない。 いろんなスキルとか経験とかある。そこはなんだろうか。 村山;これは言語は特定してないですか? 宿口;してないです。 村山; javaをやってきた。オブジェクト指向設計は特に関係ないなと。 使わないでプログラムを書くことのほうが多い。 異なるものだから無理につかっているから問題がでるのではないか。 宿口; 例題としてオブジェクト指向といいましたが、 モデル化の話は進んでいると おもう。 プログラムというのは最終的にはバイナリなので関係ないですがあまりに かけ離れているのではないかと。 村山; OOPはないと生産性があがらない。 カプセル化とかがありがたい。 宿口; 別のいいかたをすると、自分がどの上に立つかという プラットフォームが見えてくるとそこにあった設計になってくる。 上に行った時に、行きついたらこんな風になっていた。 逆にいうと自分のところがレベルが低いのかも。 村山; ここはinherit ここは抽象クラスのほうがいいんじゃないかとかは当然、 共通部分が多いとかがわかった時点でまとめる。 宿口; それはどうやってわかりますか 村山; かいてみないとわからない。 ======================== 宿口; オブジェクトの心ということで発表いただいた藤倉さんご意見いただけますか。 藤倉; 要求仕様書がどこまでできてるかという前提がないのが。。。 宿口; 本人たちは十分やったという仮定で。 藤倉; 一人で開発するならそれでもOK。人数が増えてくるとそれではだめ。 特殊なシステムにしか適用できない。 デザインパターンやフレームワークは設計の成果物としてあるんではないかと。 下から見てこういうクラスがあるから、たまたま適用できましたではだめ。 設計というプロセスは存在している。ある限られた人数で行われる。 何十人かで作る時には上からちゃんと作っていく必要がある。 宿口; デザインパターン というキーワードだけでいうと、 デザインパターンを使うにしてもそれがあるということを知らないと使えない。 どういう段階で使おうと思うのか? 川口; デザインパターンをいつつかうか。非常にむずかしい問題。 あるプロセスとか手順が確率されていないとパターンは意味がない。 使えるのは成熟度の高い組織だけ。 宿口; ある程度、成熟してそういう手法を。。。 川口; 要求仕様をモデル化できてないとパターンを使っても場当たり的なだけ。 たまたまうまくいくことはあるかもしれないが、エンジニアリングではない。 プロセスなりノウハウなりが確立された上で使うのは意味がある。 宿口; その成熟に至る過程。そこまでいくためには何があるだろうか。 川口; 設計とはなんぞや、をちゃんと定義しないとだめ。 要求と設計は全然別のもの、要求モデル==設計モデルは嘘。 ハード、ソフトの有象無象の制約によって設計は影響される。 設計モデルと実装がかけ離れるというのはモデルの定義ができてないということ。 石山; 設計モデルというのは実装と非常に近いもので、 要求モデルとは遠いということですね? 川口;そうです 石山;要求と設計のギャッップかもしれない。 川口;人によって要求は何、設計は何という定義が違っている。 要求:設計は 1:n。設計→実装はただ書き下すだけ。 石山;ハードにもあてはまるはなしですか。 川口; ハードは設計モデルに対していろいろ実装があるような気がする。 川口;ソフトの設計では実装をC,C++ 、Javaのどれでやるかまで考えて行なう。 宿口; いきなり設計モデルがあるとは考えにくい。 川口; 徐々におとしこんでいく、というのはあるとおもう。 そこの第1ページの設計と第nページの設計はかなり違うかも。 第1次設計と最終設計のギャップといったほうがいいかも。 石山; かなり成熟した組織の話かなと。 おおまかな設計、、詳細化された設計のギャップの話。。 成熟してない組織の代表としては規模の小さい話をしたい。 1-3人でやるのがほどんど。 設計、抽象化の段階でコードのイメージを持って抽象化できるレベルと、 とにかく抽象化しなくちゃ、というレベルがある。 前者では、各レベル間でトラックバックがたくさんあって いきなりできたように見えても、その裏でたくさんの 選択肢を捨ててる時にはうまくいく。 抽象化できました、満足。さあ実装。では失敗する。 抽象化の中に具体がある。 規模によっても違いそう。 要求のほうでどうするか? 宮川; 設計と詳細のimplementのどこに線をひくかという問題はある。 たとえば一人でやってる時は全てが自分の頭の中にあるので どこまで戻ってもそんなに苦労を感じない。2人になった途端に分担が発生します。 決めた通りにしないとうまく動かない。 10、20、100人になると設計した通りに書けとなる。 そうしないと全体をまとめた人の考え方通りに作らないと、下の人が工夫しても インターフェースを乱したらうまくうごかない。 モジュールごとのインターフェースを先みられるのがスキル。 そういう人がいればうまく分割ができて、インターフェースをうまくつくれば 下の人がなか をどう作ってもインターフェースをちゃんとすればOK そういう世界ではインターフェースを乱すものが悪。 4個のクラスが200個のクラスに化けてしまうのは論外。 もともと設計した人がスキルない。という話になってしまう。 宿口; 単純にスキルがないわけではない。 最初から具体的なものは見えない。。 宮川; その人が経験がないものを作るときの話です。 知ってたらそんなことはない。 やりながら考えてるということ。 やりながら何かを作るという世界なら フィードバックをかけながらブラッシュアップしていく。 宿口; フィードバックをかけながらやってる。 単純にスキルが低いわけではない。 製品はずっと作っている。 設計手法をかえるという意味でははじめて。 フィードバックかけた時になんでそうなったか。 指向をトレースできないと。 品質の重要なところは保守性。 あとからきた人がトレースできないとだめ。 定型化とはいわないがなにかヒントはないか 宮川; self documentが一つの方法。 フィードバックをかけてやる時はそふとうぇあノナカニドキュメントを。 宿口; 解決方法の一つはそうですね。 鈴木; モデル化を組み込みの人はするのかという話をパネルで。 実はクミコみやさんは抽象化が非常に難しい職業じゃないかと。 実装との間にはギャップがあります。当然。 玄関にあるライトを明るくなったら消えるようにしてくださいといわれた。 タイマー、新聞配達のあんちゃん。 設計から実装をおとすのはたいへん。 昔の組み込みやさんはできてた。規模がでかくなるとだめ。 なんかモデルがないとだめ。。 はっきり2つにわかれる モデルは設計とはきりはなして。 組み込みer モデル→変換変換変換でコードがでてきてほしい。 シームレスさにこだわる。 (絵) 現実 抽象化、本質的なものをだそうとしている。 モデル。 形がかわってしまう。 卑近なとこだと浮動小数点の誤差とか。コンパイラの実装に依存とか。 実装 現実→実装のギャップ == 破綻 組み込み屋さんはどう実装するかが非常に気になっている。 OOPでモデル化していて隠蔽していないといけない実装が非常に気になる。 ボードにのらない、RT性とか。 抽象的なモデルで吟味することが苦手 ぶつりげんしょうの上に載せる。 ビジネスモデルとかなら表現できない、とかの問題なんだけど かみに綺麗に印字できない、という問題だといきなり現実に縛られる。 昔、 下のハードウェアのブロック図とかもわかってる、、、 人工的な世界が見えている。それを通してモデル化してシステム化している のではないか。 抽象的にモデルを考えるのは苦手なのだろう。 いつまでたっても実装のことがあたまに残っている。。 aspect指向をオブジェクト指向に取りこみました。という話。 aspect指向の中でやられたのはかみこっぷ送り。 RTに動かないといけない。という別の観点が必要。→aspect指向 タイマーというクラスが非常に速い段階ででてくる。 カミコップがちゃんと送られてるかチェックするしくみはタイマー+センサで出す、 というのがでてくるのは。 抽象化してるのになぜタイマーがでてくるのか? タイマーが20秒どうしたというのは実装レベルの話ではないのか。組み込みの世界だと そういう世界でいきつもどりつやっているのではないかと。。 ======================== 宿口; ソフトウェアシンポジウムにはいきたかったが行けなかった。 同じようなことをいっている。 人工世界の話。 私の思うoopは現実世界とのかかわりを含めたモデル化がある 組み込み屋はいきなり制約をはめられる。ハードウェアの面で。 私の会社でやっている範囲ではある日いきなり「このハードでやるから」といわれる。 その人工世界をベースに。 モデル化というより「このデバイスどう動かすねん」というような問題がでてくる というのもあるのかな。 制約があるにしても苦手意識、しんどいところがあるかなと。 ??氏 今のタイマーという概念が最初に頭にでてくる、というのに対して あまのじゃくに考えてみた。 仕様書はこういうことをしてくれ、ということ。 実装の上でそれがちゃんと動いていると確認する証明が裏に隠れている。 仕様書の表にでていない、その仕様を確認することは既に暗黙の仮定になっている。 タイマー、センサーなどは最初にその暗黙の仕様によって与えられているの ではないか。仕様書の表現の問題ではないか。 宮内; 組み込みやさんは抽象化がにがてではないか。 ステップは頭の中にある。まずスペックがある。 そうするとタイマーの話がでていますが、 最終的にでてくる仕様に対して責任をもつ。 ついついひきずられる。 ある処理を10ms以内にとかの制約が頭のすみにひっかかってる それを実現するのが自分たちの設計。 納期というものがあってある時間までにそれを作らねばならない。 そういう中でやるので、保証の条件を入れたい、という気持ちがあって タイマーというクラスを作りだしてしまう。 綺麗にやればメッセージを送られた、だけでいいんだけど。 このような心理が組み込みやさんがついついタイマーを 先に考えてしまう要因ではないでしょうか。 石山; 何かを書いているときにそれを実現する裏付けをとろう、 裏付けがないと書けないという意識がある。 落ちなかったことを検出する仕掛けを考えたときについ載せてしまう。 なぜそう考えてしまうのか不思議 要求と同時にハード(制約条件)もあたえられてしまうからかもしれない。 藤倉; 設計と実装は一対一で対応しているものだと考えている。 ここでいうモデルは要求にちかい。 要求から設計に行きつくまでのどこかが非常に重要 要求から設計に落としこむノウハウがないのが問題。 鈴木; いい例題をくださいといったのはそのことで。 メソッドはちっとも複雑じゃない。 たしざん、代入、表示するだけ。その程度のこと。 そういうモデルを組み込み屋にしめされても 制約がたくさんあるので。 実装にするための設計がしっかりなければいけない。 プロセスがしっかりしてないと。。。 200,300人体制だとそういうメタファが通じない。。。。。 藤倉; タイマーの話なんですけれど、何秒以内という要求が入っていればタイマーが 入ってくるのは当然。速い段階ででてくるのは当然ではないか。 タイマーを取り込むのは問題と考えるほうが問題だろうと。。 自分で壁を作っている。 宮川; 入れてはいけないのではなくて、モデルの早い段階で 「タイマー」がでてくるのが問題。 制約がつくのはわかります。タイマーで直接表現するのは問題ない。 藤倉; タイマーはC++のタイマークラスみたいなのがはいってるのはx。 もっと抽象化したものが入っている。 鈴木; 設計レベルの早い段階ででてくるのはだめ。 藤倉; 紙コップを検出する、、、要求である時間以内でできなかったら→ 鈴木; モデルの流用性がなくなります。 藤倉; 落ちたか落ちないかが 鈴木; 何のためにモデルをかくの? 藤倉; 途中経過を書くのがモデル。。 抽象度がかわるかもしれない。。 あれやっちゃいけないこれやっちゃいけない とか入るのはむしろ逆じゃないか。。 宿口; モデルにこだわりすぎて身動きできない というのが 中西; 鈴木さんの描いた図をみていたんですけれど、ハードの環境にひっぱられるんじゃないか 4→200がそれで説明できる? クラスに分割しないで密結合にしたほうが実装的に有利だと思う。 鈴木; 説明つきません。 モデルの世界では省略されてる。 省略されてるから悪いわけではない。高いレベルの話。 高い抽象度の時にそれから直接作れないのは悪くない。。 宿口; n段階のフィードバックがかかっている。 電光石火的に、smalltalkのひとやjavaの人はばばばとつなげている。 あっというまに自分の引き出しからパターンを出してやっていく。 周りがついていけない。こまったな。なんとかしたいね。 その場の結論では中間はない。人にはある。。??? 宮川; 思考のパターンを設計段階である程度やる。 石橋(?); 仕様書の仕様。 組み込みの世界は理想ではない。故障、不具合がある 仕様書では最初からそれを全ていれてやってるならそのままかなあと思うのですが コップがなくなったら、いれ間違えたら、、、 作り直す。 今言われてることは組み込みの世界は どんどんいろいろ考えていかないといけない→クラスが増えている そういうことはあるんであないか 宿口; 要求仕様を詳細化する必要があって 設計とかからフィードバックをうける必要がある。 佐藤(?); 仕様書はやりたいことだけ書いてあるので、 やっちゃいけない、あってはいけないことは明示されないことがある。 類推、推測しないといけない。 石橋; 要求仕様はどうとでもかける どこがぬけてるかもわからない。 そういう問題もあるのかなあ。 川口; 要求仕様はどうとでもかける 自体が間違いだと思う。 どうとでもかけるのではなくてちゃんと書けてない。 石橋; ちゃんとかけることがない。 できることを議論しないと。 綺麗な理論で考えるのは大事と思うが 完璧な要求を見たことはない。 要求を完璧にしてから設計をすることなどできない。 川口; できないのはその通り。 要求仕様は要求仕様で完璧を目指すべき。 宮川; そこが経験、ある会社があるプロジェクトでやってるために暗黙のうちに理解している ここにたのめば完璧にやってくれる。 エラー処理は丁寧にやればエラー処理8割。 暗黙の仕様書で定義されている。 川口; そのスタイルでいくならOK。 はじめからかけないと言ってしまえば進歩がない。 エンジニアリング 石橋; 書けない前提でどうするか、というのもえんじにありんぐ 宮川; 経験を持ったところがノウハウをオープンにできるか、というはなし 客は実際のエラー処理を知らない。 石橋; 要求の中にどこまで書けるか、書くべきか、 書かなくてもほとんど明確な要求がありうる あることはどうしなきゃいけない、そうじゃないのはどうしなきゃいけない。というの が明示されるか。 やってほしいことは書ける。 例外的な時にどうするかを書けるか、というのが難しい。 川口; いろんな手法を使ってやりましょう。 どうせ書けないんだから設計でなんとかしよう、というのは違う 石橋; 一つずつの世界でいいんだろうか、 もうすこしマクロな世界でなんとかならないか。 宮川; 要求仕様を作る時点ではハードがない、 要求仕様の中にはハードに依存するトラブルとかは入ってない。 川口; それは要求仕様ではない。 宿口; 「要求仕様」の定義が違うことはわかる。 川口; 要求モデル、設計モデルは別。 ハード依存のは設計。 要求はひとつ。要求に従ってどう設計するか。 要求としてどうでもいいところ→設計では必要→そこでは設計で決まる。 要求決定者と設計者のネゴで決まる。 宮川; 要求者も設計者が踏みこむ? 川口; 契約次第 よのなかによくある要求仕様書 詳細は後日会議にて決定 そういうとき はネゴしないと決められない。 そういうのを決めるのはまた別の 技術。 宿口; 疑問点が生じれば要求者に。。 川口; ハードはA案、ソフトはA案、というように決まったところで要求では表現できないもの がでてくる 松浦; 実際に今仕事やっていてほとんどの案件でモデル化を一からできることはなかった。 そういう場合。。(流用設計)の場合は? モデル化によってふぃーどばっくがあって完璧な要求仕様を作る話だと思いますが 流用設計の場合はどうフィードバックなどするか?? 宿口; 私は解がないです。 松浦; プロトタイプまで作りあげてフィードバックかけるしかないかなと考えている。 何かアイデアがあったら教えてほしい。 宿口; やってる内に見えてくる それを延々くりかえしてるだけではないか 松浦; 10数年やってるけどモデル化とか抽象化とかやったことがない、 勉強してるけど使う機会がない。 鈴木; 実際に頼りになるのはコードかな。 私は普段プロセスは論じない 大きなループ、小さなループ デバッグじゃなくて調整すること(パラメータをかえてやってみる ロジックの変更までいかなっくても パラメータをいじることがある。 最終的に残ったものがコードであるというのが問題? リファクタリングとか構成管理を技術の一つとしてもっていないと混乱。 いきなりあきらめてアジャイルに走ってもうまくいかない。 大きなマップみたいなものがあってどこに影響があったとか。 宮川; 最終的に信じられるのはソースコードだけ。結論 スタイルとしてソースコードをかえたときにコメントを修正する。 実際にはコメントを変更しないことが頻繁に行われる。 実際にはそのマナーが一番の助けになる。 最終的にはJavaでもソースにコメントを書いてるのを読んで理解する。 コメントを徹底させるだけでソースのよみやすさは向上 きよはら; コメントを替えわすれるのはある。 テストファースト。書き替え忘れはほとんどおこらない。。。 音川; 4→200がでてきた。やってしまいそう。 なんでやるのかずっと考えている。ソースが一番大事になってしまう その比重が大きくなってしまう。 その開発の時間。。??? UMLとかそういったものが提案されてるけど?組み込み屋さんにとっては? 一覧性とかでは優れているかも、 設計も下流にいくに従ってどんどん使うことに意味がなくなる。 最終段階では UMLは何の価値もない。 成果物が生成される 別の道具 UMLと違うような道具が求められているのではないかという印象。 自分もいきなり4つから200のクラスは作らないかなあ。 宿口; 途中の思考過程を残せないのが問題。 UMLではたりない? 平山; 「設計モデル」がどこにあたるかの定義の問題になっている。 本質的な興味ではない。 宮川; ウォーターフォールの呪縛? フィードバックが必要。 高田; さっきの宮川さんの信じられるのはコードだけ。 コメントも信じられないのは不一致。。 実行可能でないものは信じてない。 検証可能なものは必要。 テストファーストも並列して検証しあっているから整合性がとれてる UMLで書くのはいいけど書いたあと検証できるか。検証できることを重視するべき。 宿口; コードを替えたら仕様書を替えろ。 という原則がでました。 高田; その原則をenforceする仕組みが必要。テストファーストはそういうもの。 宮川; ISO 9001にちゃんと書いてしまう 高田; ちゃんと検証 村山; それがJUnit Javaで書いててもJavaらしくないコードはいっぱい 宮川; それはJavaのスタイルを守って書きなさいということですね 村山; モデルの話です。 モデルの持っている機能がコードに含まれている。 高田; そう。 村山; 結局動かない。 高田; 全部検証可能であることは大事、 実行可能より検証可能なほうが簡単なはず。。。? formal methodとかやりますがpre状態 post状態 を書いても実行はできないけど 検証できる。。 違ってたらなんか設計がかわったはず。 松本; プログラム検証は難しい。 どれだけループを回した、とかは人間の知識を入れないと難しい。 チェックは大変。 高田;動いたものがモデルと乖離してるか はわかる。 松本;どれだけのクラスが扱えるかは難しい 宮川; RT条件が入ったばあいにサンプリング自体が影響を与えることに。 高田;影響を与えない手法を考えるか、観測がはいった状態で動くように。 宿口;ドメインがずれてきたので。。 石山; ちょっと前にもどりますけどれ、 要求というものがなんなのか、 組み込みの世界のことば「要求」川口さん、鈴木さんは対局 どんなふうにつくろうかというときの要求 制約の上でどう作ろうかという要求 ハードからくる制約とか、制約があとからくるという意識が強かった。。 組み込みの世界ではもともと横やりが入った状態で設計される。 要求のでてくるところ、要求がなんなのかがちょっと違う世界かなと思った。 ギャップのありか。 違うところにギャップがありそう。 杉山;ヤマハ まとめに入っているのにぶちこわして申し訳ないですが、 やっぱり実際に要求仕様をかためるというところが なかなかできない、、というところが問題。 はっきりとした要求がほんとうにわかればモデル化なりプログラムなりで なんとかできる。 要求はこんなのをつくれ、というのはほんとうにやりたいことからいろいろなフィルタ がかかってしまう。フィルタがなければもっと素直になるんじゃないか。 さの; 鈴木さんの図でいいますと現実の世界をもし完全に高校物理くらいの知識でモデル化 できれば、組み込みの制御のロジックで簡単になる。 シミュレーションの上で作ってこれでいいか? とかできる。 車の世界では衝突実験は車をぶつけなくてもどれくらいの衝撃があるかなど ある程度計算だけで求めることができる。 ギャップ 物理世界とかをモデル化する CAEとかの世界を知るともっとなにかあるかも。 ??氏; 2、3年前に構造化→オブジェクト指向に。 要求仕様はかかれてないに等しい。粒度の大きいクラスから作っておとしていった。 oopで作ったことによって、これだけの要求で作りましょう→一応動く。 こういう時はこう→さらに作り込んで そうすると要求仕様自体書かれなくなっていって、オブジェクトそのものが 仕様でいいじゃないと。 それで問題なかった。 クラスが4→200 うちは1桁は増えた。 どういうクラスができたかというと、 I/Oを叩く、マスクして使いなさい、それを強制するためのクラスとかができた。 いいクラス作ったので使ってください なんとかマネージャークラスが増えていった。 昔ウォーターフォール→oopインクリメンタルにできていい。 宿口; ギャップはありそうだ。原因はさまざまなものがありそう。 この話は続けると細分化できてよさそうですね。