=========================================================================== セッションA1: 組み込みシステム向けオブジェクト指向開発手法 [開催日時] 7/23 14:50-16:10 [開催会場] E会場 (120席程度) [参加人数] 80人程度 =========================================================================== ============================================================================ 概要 ============================================================================ 企業からの講師5名による，各社がサポートする手法の紹介．質問はB2セッショ ン(分科会)でまとめて行う．このセッションでは質疑応答の時間が取られていない． 司会 ツールを使う側の要求を一言 近年の組込みシステムの開発量が多くなり、扱うシステムの規模が多くなった。 そこで従来の手法と異なり、UMLなどからソフトやハードの自動生成してくれる 便利なものはないのだろうか。 講師一覧（敬称略) 　・鈴木俊安(東陽テクニカ) 　・福富三雄(豆蔵) 　・松岡正人(日本ラショナルソフトウェア) 　・渡辺政彦(キャッツ) 　・米田史夫(伊藤忠テクノサイエンス) ============================================================================ 講師：鈴木俊安(東陽テクニカ) 演題：ソフトウエア開発とハードウエア開発の融合におけるXTUMLの活用 ============================================================================ ○MDAを実装したUMLツール，BridgePoint/DesignPointの紹介．　 　 ○BridgePoint/DesingPointとは． 　Project Technology社が提唱する 　eXecutable and Translatable UML(XTUML)ツール． 　アクション記述言語によるアクション・セマンティクスをサポートし， 　システムの振る舞いを完全に記述できる． 　・BridgePoint Model Builder 　チャートの作成，アクションの作成，文法や一貫性のチェック 　　他のUMLのモデリングツールと異なりクラス図、ステートチャートを中心 　にモデルを構築している。アクションと呼ばれる振る舞いの記述ができる。 　これはCやJavaと異なるアクション言語で記述する。 　・BridgePoint Model Verifier 　ドメイン内のモデルの検証 　　検証にソースコードを必要としない 　　要求分析モデルの検証 　・BridgePoint Generator 　　それらのモデルをModel Compilerというツールを使いソースコードや他の 　コードを生成する。 　・BridgePoint Model Debugger - 新製品 　ターゲット上でテストする前にホスト上で簡単なシステムテストを行うよう にすることを目標にしている。 　通常、自動生成されたコードも手書きのコードと同様にラインデバッグを行 わなければならない。モデルベースで自動生成されたソースコードでも、モデ ルの要素をまったく感じさせないデバッグ作業となる。Model Debuggerでは自 動コード生成をホスト上で行う際に、モデル中の要素、クラス、イベントなど をトレースできるようなコードを埋め込む。このコードの含まれたソースコー ドを実行することで、システムが今どのような状態にあるのか、どのイベント がどれくらい発生したか、などのモデルの状態を検査することができる様にな る。 　将来的にはターゲットサポートを予定している。実際に動作しているターゲ ット上からシリアルやイーサネットを使用して、ターゲットの動作をホスト上 で表示させようとしている。(秋のリリースには搭載予定無し) システムレベルのモデルの検証(2002年秋リリース予定) 　　ターゲットシステムでテストする前に，ホストでシステムテストが可能 　ソースデバッガではできなかった，クラス，イベント，状態，属性に 　 ブレークポイントを設定可能 　　システムの状態を検査できる 　　・インスタンスが何個できているのか，インスタンスがいつ消えるのかど 　　　んなイベントが発生中か，何個出ているか…等 　・DesignPoint Model Compiler MC-3020 ANSI C言語用モデルコンパイラ 　　MC-2020 VC++ VxWorks用C++モデルコンパイラ 　　アーキテクチャがオープンである． 　　自分で新しいモデルコンパイラを作成できる⇒VHDL，HTML用など 　　自分の環境に合わせてカスタマイズ可能 　・Model Compiler 　　　ModelGeneratorと併用。Cのソースコード、C++のソースコードを生成 　　できる。 　　特徴： 　　　アクション記述言語を実装していて、振る舞いを完全な形で記述できる。 　　　アクション記述言語で完全に振る舞いの記述されたモデルはソースコー 　　ド無しにモデルだけで検証できる。要求分析モデルの検証、非ソースコー 　　ドを生成するようなモデルの検証に便利。現在テキストベースのログしか 　　扱えないが、後々、モデルの動作を表すアニメーションなどを付加。 ○ソフトウェア開発とハードウェア開発の融合 　・システム全体を分析 　　従来のシステムはハードウェアありきで、そこからをソフトで実装してきた。 　　ソフトウェアとハードウェアを最初に切り分けることなくシステム全体を 　　モデリング．ソフトウェアとハードウェアの境界は後で決定する． 　　Model Verifierを使って両方のモデルを同時に検証が可能． 　　CやC++のソースコードを持たないようなハードウェアの場合、モデルが記 　述できるツールが非常に有効ではないかと考えている。 　・自動コード生成の利用 　　モデルコンパイラを使用して，別々にコードを生成．自動コード生成によ 　　り境界変更時の工数を軽減できる． 　　ハードウェアに対応したモデルコンパイラの開発が必要．ハードウェアと 　　ソフトウェアのインターフェースをどのように実装するかが課題． 　　今後の開発方法の方向性はこのようなところにあるのではないだろうかと 　考え、UMLが今後のソフトウェアとハードウェアの切り分け問題を解決する 　何らかの手法になるではないかと考える。 　・BridgePoint/DesignPointを使用したCo-Designのシステム構築 　　プレゼンテーション資料が以下のURLからダウンロード可能 　　http://www.projtech.com/pubs/confs/2002.html ==========================================================================　 講師：福富三雄(豆蔵) 演題：組み込みソフトウェアのオブジェクト指向導入について ========================================================================== ○はじめに 　ツールメーカーではないので，コンサルティングの実績からの組込みソフト ウェアにオブジェクト指向がうまく導入できるかという点についてである。 ○組み込みソフトウェアの現状 　規模が飛躍的に増大する中での，短期開発要求や新機能追加要求がある． 　付加価値のある製品を競合他社より先に販売し，売り上げ利益を確保するに 　は，組み込みソフトウェアエンジニアリング改善が急務である． ○オブジェクト指向への期待 　何を期待しているのか？ 　・再利用性・拡張性・変更容易性 ○オブジェクト指向への取り組み状況 　導入してどうなっているか？ 　・効果が上がっているもの 　　OA機器(複写機，プリンタ)，携帯電話，カーナビなど， 　　開発規模が大きくて再利用拡張性が望まれる製品 　・なぜうまく導入できたか？ 　　OA機器の場合…90年ごろからデジタル化が進み 　　組織の中にソフトウェアを開発する(オブジェクト指向を受け入れる)土台 　　があった． ○課題 　・効果があがらなかったものもある． 　　・原因…組織に(ソフトウエア開発の)土台がない．一般的にプロジェクト 　　　の失敗の原因の８０%は人、組織、プロセスの問題であることがいえる。 　　　このような土台のないところへオブジェクト指向を導入しても、今まで 　　　以上の混乱をきたすのみである。 ○解決法 　・プロセス・技術・マネージメント，３つの視点からバランスよく改善 　・まず，アセスメントを実施して現状を正しく把握．改善施策を立案 　・最初に管理プロセスを定義．ＣＭＭなどの有名なものや，豆蔵プロセス， 　　などを使う 　・基本的な部分(ＣＭＭレベル2ぐらいから)からやっていく． 　・今まで個人に依存していた部分を組織的に行うにはプロセスの体系化 　　が必要．リファレンスプロセスはいろいろあるが，企業文化にあった 　　プロセスを定義していく ○最後に 　・豆像は組み込みソフトウェアの抱えている課題の支援をしていきたい． 　　オブジェクト指向だけではなくトータルソリューションを提案． 　・開発者自身にソフトウェア改善の意識を持たせ， 　　彼らが自ら率先して改善していける組織作りを目指したい． 　 ============================================================================ 講師：松岡正人(日本ラショナルソフトウェア) 演題：Rational Rose Realtime & UML2.0 ============================================================================ 　これからの製品がどのような機能を組み込んでいくかということについて少 し先の話をする。UMLを策定している団体OMGのあるワーキンググループがMDAと いうアーキテクチャを考え、それを実装しようと奮闘している。 ○OMGの主導するModelDrivenArchitecture UMLが成功したことにより，OMGはモデルの使用に基づくソフトウェア 　開発メソッドのビジョンを公にした．それがMDAである． ○UMLのためのMDAの要求 ・最終的に，以下を可能とする 　 １・モデルの実行 　　 コードが実行できるのはあたりまえ．モデルも実行できるように． 　 ２・実装へ自動的に変換できる仕組みを標準化 　 　異なるプラットホームにも適用させよう 　・モデリング言語の要求 　　・人によって解釈が異なるようなモデルではまずい． 　　・新しい言語を容易に定義できなくてはならない． 　　　（これから，独自にある特定のドメインに対応するようなＵＭＬに変換 　　　しよう，というような話も含む．） 　　・個々のドメインのためのモデリング言語を専門的に扱えなければならな 　　　い．　 　…ここまで達成されるのは遠い将来の話だと予想している． ○MDAの実現 　…ここからは直近の将来の話． ・モデルから実行コードを生成 ・ツールへの実装 　 - Rational Rose Realtime ROOMの実装をRationalが買収してRose Realtimeに． 　 Structured ClassがUML2.0に採用される ・以下ツールの動向 　Rose RealTime 　将来のUMLの拡張に必須とされている項目のいくつかを現時点でのテクノロジ ーで実装したツール。Native LanguageによるAction Codeの実装がBridgePoint との違いとなる。UMLではAction CodeはBridgePointで使用されているようなア クション記述言語になることは間違いないと思われるが、Rose RealTimeでは、 その記述にCやC++などの現在ある言語をそのまま使用するツール構成になって いる。 　UML2.0 　来年に出ると予想されている。先ほど示した要求を盛り込む予定。Rational の提示するROOMがStructured Classとして採択される予定。 　Structured Classの構造 　クラス本体と外部のクラスと通信して処理を行うPortという窓から構成され ている。メッセージや情報のやり取りはPortを介して行われる。Portに流すメ ッセージの形式をあらかじめ決めておけば、分離した形でオブジェクトの設計 ができる。メッセージの応答はPortから来てPortへ返すやり方と、直接ローレ ベルのメッセージとして返すトリック的な返し方もある。Portは通信の窓であ り、どのようにデータのやり取りをするかなどをプロトコルという別のクラス で定義する。 　 　UML2.0が今後のリアルタイムシステム開発者向けの一つの鍵となる。 Structured Classやアクションランゲージの導入。さらに、MDAではモデルベー スでの実行、トレース、テストができ、Native Languageの自動コード生成を行 えるようになるはずである。 　Rational XDE 　UML2.0を最初にフルサポートする予定の最初のツールになる予定。組込みエ ンジニア向けのツールにはなっていない。Webサービス、Webアプリケーション 向けの環境。 ○まとめ 　RationalのツールはUML2.0を先取りしているが，ツールにインプリメントし 　ていない部分もUML2.0に加わるはずである． 　MDAを実現するための一つ目のステップがUML2.0． 　Rational Rose Realtime は，MDAのベースとして最適である． ============================================================================ 講師：渡辺政彦(キャッツ) 演題：eUMLについてのポジショントーク ============================================================================ ○はじめに 　eUMLのeはembeddedのeである．4人で作成した組み込みシステム開発プロセス． ○開発動機 　・UMLを使って組み込みシステムを開発しなくてはいけない，という時に， 　　もう少し簡単にできないか． 　・もう少し実践的に言い切ってくれるような開発法が欲しい． 　・UMLの表記法だけではうまくいかないので，拡張しよう． 　・大規模向けの管理もきちんとできるようにしよう． 　第一歩を踏み出せるベストプラクティス集ということで発売したのが，eUML． 　・組み込みUML:eUMLによるオブジェクト指向組み込みシステム開発(翔泳社) 　　…本日10%引きで販売 ○特徴 　・ユースケース分析で状態図を使用する 　　・ユースケースはシナリオをどんどん書いていく 　　・シナリオは無限なので，どこかで有限化⇒ステートチャートを採用 　・ドメインとオブジェクトのカテゴリを明示．次の４つだけ． 　　・アプリケーション 　　・メカニズム 　　・外部インターフェース 　　・デバイス 　・エンティティ分析ではきちんとデータモデリングする 　　・データの変更があったときに強い形に 　・再利用性を重視 　 　　組み込みはもともとタスク中心で組まれるが， 　　タスクの中に入っているオブジェクトを先に明らかにする 　　 　・システムレベルテスト 　　分析モデルと設計モデルは全く違う．分析モデルと設計モデルの間の等価 　　性が保証できない以上，検証・テストは必須である． 　　・アクター特性表，外部環境モデルを利用した利用モデル分析． 　　・状態遷移表を利用したテストケース設計 　　・テストケースカバレッジ 　　 ○適用事例 　オムロンが実践。シーケンサ、メカの制御に試してみた。並行処理、リアル タイム性などのFA特有の課題があるが、eUMLを使うとオブジェクト開発手法の 敷居を低くしてくれそうであるし、様々な実戦経験が記されているのでこれに 沿って実践してみようということから、オムロンで実践した結果、部品化の概 念、遷移ベースのモデリングが非常にFA向きであると痛感した。自動生成した コードの比率が非常に良かった。 ============================================================================ 講師：米田史夫(伊藤忠テクノサイエンス) 演題：Rhapsody TestConductor ============================================================================ I-Logix社の説明 　組込みシステム向けツールの製造。UMLの主要メンバー、Enbedded Linux コンソーシアムメンバー ○Rapsodyの反復的な開発環境 　・Test Conducorのベースとなるツール 　・UMLベースにした分析・設計手法を使用 　・メソッドをモデル中に統合 　・振る舞いをステートチャート図を含めて、スケルトンでなくプロダクショ 　　ンレベルのコードを生成 　・ラウンドとリップ機能。実際に修正があった場合、それをフィードバック 　　して設計・実装に移動していく。デザインの整合性を保ちながら詳細に落 　　としていく。（実装とモデルの同期化を保証） ○Rhapsody開発環境　 　・デザインレベルのデバッグ 　　パソコンの中でデザインを閉じて検証を行う。シーケンス図、ステートチ 　ャート図を用いながらパソコンの中でデザインしたものを検証していく。ア 　ニメーションを用いてシステムがどの状態にあってどのように遷移していく 　かを表示してくれる。 　・実装レベルのデバッグ 　　実際に吐き出されたコードがターゲットで正常に動くかどうかの検証。タ 　ーゲットにリアルタイムフレームワークとアニメーションインターフェース 　を搭載させ、そこから、ターゲット上でどのように動作しているかという情 　報をホスト側に送り、ホスト側で状態図をアニメーション表示させる。 　Rhapsodyのキーワード 　・UML準拠 　・オブジェクト指向 　・リアルタイム 　・エンベデッドシステム 　・開発ソリューション 　・ビジュアルモデルとコードとの蜜連結 　・設計レベルとソースレベルから同時にデバッグ 　・リアルタイムフレームワーク 　・プロダクションレベルの自動コード生成 　・ラウンドトリップ エンジニアリング ○TestConductor ・Rhapsodyプロダクトのオプションとして今年発売 　・Rhapsodyの開発プロセスにテストプロセスを追加 　　（※検証とテストは異なる。検証は与えらた入力に対し、正しい出力が出 　　　　ているのか試すことで、テストは予期せぬ入力があったときでも正し 　　　　く動作するかどうかも試すこと。） 　・UMLを採用：テスト用に新しい言語を覚えなくても良い 　・シナリオデータを元にテストを実行 　・Rhapsodyアニメーションと連動して，モデルの実行をアシスト 　・モデルの実行をドライブするためのシナリオを自動生成 　・システムの振る舞いのモニタ・検証 ○TestConductorを使ったデバッグ・テスト 　Test ConductorはRhapsodyのアニメーションと連動することができる。 　テストドライバとして、テストを実行させるためのシナリオを自動生成する。 　・デザインレベルのデバッグ 　　デザインをしている最中にテストを考える 　・単体テスト 　　スタブなどを使いながら検証の程度を上げていく 　・回帰テスト（Regression Test） 　　自動的に吐き出されたシナリオを，またデータとして利用 　　複雑なテストデータをより簡単に作れるように 　・設計進行中のデバッグ 　　仕様に基づくシナリオを作ってテスト 　　システムが自動的に作るシーケンス、テスト用に作られたシナリオ図を基 　にTest Conductorの中でテストを動かす。分析フェーズでキャプチャされた 　シナリオをモニタとして再利用する。自分自身で正しく動作しているかとい 　うテストデータを自分自身で生成する。通常通りに開発・分析している中で 　デバッグを行う。 　・ユニットテストのためのテストドライバ 　　設計進行中のデバッグで作られたシナリオや単体テストの中で自動的に出 　てくるシナリオを基にテストドライバとしてテストを行う。出てくるシナリ 　オと基準となるシナリオと比較し、正しく動いているか、どこで誤った動作 　をしているかといった結果を表示してくれる。 　　シナリオとテスト結果を比較 　　Rapsodyが生成したシーケンスダイアグラムを再度，TestConductorに投入 　テストのコスト 　　時間的には全体の70%費やされる。 　　遅延があると50%の費用が費やされる。 　といわれる。 　如何に早期にエラーを発見して、問題を潰していかなければならないか。 　開発とテストを切り離すのではなく、開発の段階からテストということを 　考えて進めなければならない。 ============================================================================ 司会 　淡々と終わり、当初の目論見とは異なるが、A1では各社が好きなことをいっ てもらうということで、各社が違う土俵で発表されているので、ツールの発表 を行った会社あり、方法論の説明をされた会社ありということになったのだろ う。例えば、どのような言語が自動生成される課などを各社に回答してもらう など、B2では同じ土俵で論争してほしい。A1は前振りということでB2ではしっ かり論争してほしい。 ============================================================================ 記録者の感想： 各社のツール・手法の概要が簡潔に紹介され，分かりやすいセッションだった． ５社の製品紹介を一度に聞けるチャンスはなかなかない事ではないだろうか． ただ，講師一人あたりの持ち時間が短く，また，途中の質疑応答時間も無かっ たため，かなり急ぎ足で発表が進められた感があった．時間の都合上仕方がな い事ではあるが，５分程度は質疑応答に当てる余裕があった方がよかったと感 じた． 　淡々とツールの説明を聞いていたような気がする。特に質問もなく平穏無事 に終わったが、B2では熱く議論が交わされたに違いない。