UMLロボコンとMDA C2 - 会場の広さ(席数などでもOK) C会場 - 参加者の数 60 人くらい - 内容 ---- 前半 UMLロボットコンテストについて ---- UMLロボットコンテストを教育に使いたくなったら連絡してください。 - 今までの教育の問題点構造化、リアルタイムOOの組込み教材あれこれ作ったおふろのコントローラホームセキュリティしりとりゲーム (データフローモデル) 電子レンジミニ四駆電子ボット (richo->SESSAME) ししおどし (SESSAME) 受講者の様子クラスと関数の区別がつかない (よくある)。自然を記述するよりも、制御するクラスを作る。関連がモデルに存在しない。 (1つの？)状態モデルですべての動作をくみあげる。新人よりもベテランにとって敷居がたかい。ネーミングスキル (ドメイン、オントロジィ問題)。ぶどまりが非常にわるかった。教材の問題教材規模では教えたいモデルの価値がでない (解決できそう)。講習で仕様から最終コードまで学ぶ時間はない (投資の問題で解決可能)。教育成果はある範囲に留まり波及が難しい (教材の問題ではなく教育レシピの問題らしい)。教育レシピの改革教えることよりも育むことに重心移動 (ピンポイントの講習＋自習検証) 理解が熟成するまでの期間をとる (特に上流は、期間が適度に長いほうが生産性があがる)。学ぶこと = チャレンジならば気合いがはいる (合理的な競技規約とチャレンジを奨励)。本人のやるきはやはり大切スボーツと同じ意味で競技者と同時に観衆も学べるレシピがほしい (モデルの公開と議論)。観衆から競技者にかわったりするので => UMLロボコンをやろう！挑戦学習 (かつためのモデリング技術を使う。かつための学習は苦にならない) 作業要求 (プランなしでは開発期間と要求 (性能モデル審査)をみたせない) 知的ゲーム性 (基礎開発とみなせつライントレース方式の考案) 情報獲得のスキルアップ (GNU環境の実利用) オープンソースからの情報獲得メカニカルチューニング工程をこなす充実感 UML実用先行者からの見本提示による実践学習育成計画のポイント 2001年12月より企画開始机上演習から20チーム80名をターゲットに 2ヶ月でどこまでやれるかロボコン自身もUMLで考える ShowTime 20チーム参加 80名小学生が見学横にモデルが展示 1000万くらいかかる(従来なら) 結果1 追跡調査がむつかしい？が、うまくいっている感蝕を得ている。従来の方法よりも効果があるようである。試走の日からみんなファイアー勝つために、みんなががんばって、つくってためして、つくりなおす。 10%程度の脱落者が出たが、2003年にまた参加してもらえた。おわってなみだする人までいた。結果2 単純な要求でも多くの工夫とモデルが出現審査委員は、みんな「えーっ」というような審査委員が思いもよらなかったモデルが出たりしていた。単純なものだと50行くらいでできるが、それではぜったい勝てない。育成問題を真剣に考える。 UML使いにはアナリスト適正とモデリング能力の両方が求められる。興味とくみあげる熱意のバランスが重要いくつかの問題へのアプローチをみながら重点育成をポイントを考慮する。 isosceles triangle試験、モノポリー試験日本語記述や意思疎通のスキルモノポリー試験モノポリーをUMLでモデリングせよ、という試験 (どなたかに対してモノポリー試験をさせてみる) その人は結局「きっかけがつかめない」「知識領域として知らないところがある」　と描かなかった。講師「こういう人はまだ見込みがある」すぐに「よし！」と言って描いてしまう人がいる => 交感神経が働きすぎどのようなスペックかをじっくりしらべてから… => 副交感神経が働きすぎこのバランスが良い人が良い技術者である。バランスをテストするのがモノポリー試験の意味。みんながバランス能力がつくようにしてあげたい。メモ UMLの記法についてはOMGが試験問題を作成中実務的なモデリング技術試験はUMTPが開発中 RTOSを利用したMDAモデルはTOPPERS教育分科会でこれから開発　(来年くらいには格好になるかな…？) ---- 後半 MDAチュートリアル ---- モデル中心の開発 (Model driven architecture) 有効なことはわかっているがみんなで使うのが難しい。艱難辛苦 (16) 全体をモデルで構築することは逐次型の開発よりも難しい。成功している工学は図法と文言のくみあわせを最適化するが.... ソフトウエア開発の現状は図法を使わないほうが常識的 (フローチャートを多用した 2昔前とは異なる) 無理な図法偏重教育が問題記法問題 UMLは変化が激しくて、なかなか使いにくい。プロセス問題どう提供していくか OOA モデルセントリックにするためには、まだまだやることがある。スケッチ派人と人のコミュニケーションのためだけにUMLを使用する MDA派人とコンピュータ, 人と人の両方にUMLを使用する共通にしたい IEEEのソフトウエアマガジンで特集されている。適用規模小規模ならだいたいうまくいく大規模はぜんぜんだめ -> どうやってモデルセントリックにもっていくかが問題。方法論的問題シームレス開発 vs. ドメイン分離シームレス -> 結局スパゲッティ (モデルセントリックでは解決できてない) ドメイン分離 -> パフォーマンス低下 (いまのMDA技術では) 階層モデルと平面モデルアメリカの人は、(開発モデルを?)ひとつにすることはできないからあきらめてる。 DoDは開発方法論を規格化したりしてるが、コストがかかりすぎる。 build486(?) オブジェクト指向的だけど… 日本でなにがたりないか (20) モデルセントリックでラブラブに日本にも良い技術があるのに、海外にでていっていない。組込みではシステム工学がたいへん重要組込み工学 (組込みスキルの工学が必要) これが日本が勝てる要素では？ MDAへの道モデルセントリックはまだまだこれから。ケーススタディ演習課題の紹介封入問題仕様からクラスモデルわからない人に、わかってもらうことが大切経過か最終かシングル缶はサンプル缶の特殊例？組込み技術からの視点なぜクラスが必要なのかわからない => 制御中心に書いてしいまう人が多い。動的なメモリ生成消滅モデルは危険だ (malloc禁止) デバッグができない MDAの一般的な理解 ASM, C, Java -> MDA モデルとコードの相互変換が必要 (ドキュメントが無くてコードセットリックになってしまう) MDAのねらいモデルの表現にはドメイン固有の表現やルールが必要飛行機やさんは制御工学のドメインでソフトウエアを書いてるどのようなモデルもメタレベルで定式化できれば、自動生成が可能だあなたのラダー図をUMLに変換できるようなMDAツールを提供できるよ！例：データフローモデルでCDをモデル化とか.... 例：ワインをえらぶ (データフローモデル) ある種のドメインだとうまくはまるモデルというのがわりとある。 DFDのメタな構造を考えるて、抽象モデルが作れる。=> MDAのひとたちの考えこれは意外と大変。リアルタイム組込の常識 ... 問題がけっこう複雑。これらをMDAすることが課題。組込にとってのMDAとUML PIM, PSMの勉強が必要なのではこれからのMDA プロファイルの嵐をメタ定式化する作業が必要まだ、みなさんは静観しているくらいで良いだろう。ただ、ぼちぼち情報をおっかける必要はある。 MDAは色々なモデルセットリックな手法が存在。統一するのはむり。メタ、メタメタモデル等をつかって、モデル間を変換できる方法を提供していきたい。みなさん勉強してください！ [質疑応答] ヤマハ渡辺さんロボコンについて：とくにさいきんの若い人は、経験をつむまえに初めからスマートなやり方に拘ってしまう。どういうふうに対処したらいいのか？耳年増という言葉がある。ドメインごとに、適切なモデルが違うのに、勉強するのが大変なのでどれか一本にならない？と聞く人が多かったりする。適当に採用するモデルを選んんじゃうこともある。そういう人につける薬はない…。ある程度勝手にやらせることは必要。(失敗させることは必要？) MDAについて：安全性 = 信頼性ではないというのは？飛行機の例で右に操縦桿をおおきく倒したとき、左に飛行機が行くようであれば信頼性が無いということ。ストール等の危険な状況をひきおこしそうな時に、右に操縦桿をおおきく倒したとき、落ちてしまうのは安全性がないということ。作る側からみると、全然違う問題である。安全性と信頼性をごっちゃにしてモデリングしてしまうことが多い。トヨタ ?さん仕様からモデルを作る話があったが、システムをハードから作ることが多いので、仕様がなかなか決まらないことが多いがどうすべきか：シミュレーションで仕様検証するとよい。最初は、仕様がある部分だけモデルをつくる。ある程度仕様ができてきたら、実際にコードを書くとよい。モデルの変更があるとコードも変更しなければならないので、手動でコードを書くときは初めからコードを書くのは無駄が多いが、MDAならコードを生成を最初のイテレーションからやれる。 MDAの実例は？：なかなか少ない。ハードも含めてモデリングする必要があるのではないか？：同感システムモデルをクラスモデルをつくって FPGAで実装するとか。 MDAでコード生成の段階でハードかソフトかを決定したりするものがある。 + 記録者自身の感想後輩を教える立場として、UMLロボコンの構想が非常に興味深く感じた。まったく同じ手法はどこでもは使えないが、挑戦学習、作業要求、知的ゲーム性、情報獲得のスキルアップなどは汎用性の高い考え方なので非常に参考になった。また、MDAの分野はまったく知らなかったので興味深く聞けた。