-------------------------------------------------------------------------------- セッションD2：「アプリケーション指向設計」セッションD2では、アプリケーション指向設計と題して、3つの一般発表が行われた。会場は3人掛けの席が3x10程度用意され、大体半数くらいの席が聴衆で埋まっていた。アプリケーションということで、聴衆はソフトウェア開発に携わる方ばかりになると思っていたが、数は少ないもののハードウェア開発者もおられる様子であった。一つ目の発表では、九大の森若さんより、アプリケーションで使用していないOS のAPIを削除することにより、汎用OSを軽量化する手法についてご紹介頂いた。手法はAPIの依存関係を示した有向グラフを生成し、使用いるAPIを追跡することで不要となるAPIのみを抽出するというもので、APIレベルでアプリケーションにとって最小セットのOSを生成することが可能となる。MINIXを利用した評価では、最大で20%程度のコードを減少できるという結果を得ていることが示された。二つ目の発表では、沖電気の坂野さんより、Linuxを利用したVoIPルータ開発の事例についてご報告いただいた。Linuxという汎用OSを組込みシステムで利用する際に起る問題の明確化と、具体的な対処方法に関してご紹介いただいた。特にリソース(容量)不足の問題に対し、ライブラリの軽量化やファイルシステムの圧縮などの例が示された。三つ目の発表では武蔵工大の島田さんより、システムレベル言語であるSpecCのソフトウェアアーキテクチャに関する記述性の低さをどのようにして打破すべきかについてご紹介頂いた。ソフトウェアアーキテクチャ記述の際には、再利用性や保守性の面から、コンポーネント間を流れる情報が持つ意味などを明確にする必要があるが、現行のSpecCではこの点が欠如している。この問題に対し、接続関係と意味付けを明確にするソフトウェアアーキテクチャ図の導入と、詳細記述に必要な4つの要素を言語に導入することで対処が可能であることが示された。それぞれの発表とも、質疑応答では検証面など具体的に適用する最問題となる点が多く指摘されていた。これは、SWESTが他の学会とは異なり、多くの現場経験者が参加されていることを反映したものと考えている。 -------------------------------------------------------------------------------- セッションD2：「アプリケーション指向設計」約50名程度の開場に30名程度の参加者があった。 -------------------------------------------------------------------------------- D2-1.「汎用OSの特定ソフトウエア向け最適化」発表者：森若和雄（九州大学）、中西恒夫（奈良先端科学技術大）背景組込みシステムでも汎用OSを利用する機会は多い -> 開発工期の短縮ソフトウェア資産等の流用組込みに汎用OSを利用する際の問題点・OSのリソース消費量が多い・リアルタイム性、割込み応答時間に対する考慮がされていない・構成可能性(Configurability)がない研究の目的アプリケーションに特化したOSの自動構成 -> アプリケーションが利用していないAPIを削除し、 OSの軽量化を行なう API削除のアルゴリズム 1. 関数呼出の依存関係を有向グラフで表現 2. 実行時に呼び出されるOSのAPI情報を抽出 3. 2から到達不可となるOS内関数を探査する 4. 3で抽出された関数をソース単位で削除する検証条件・OSにはMINIXを利用・デバイスドライバは対象外・メッセージパッシングに関する機構の部分の検証は簡略化する結果・最小構成(APIなし) : 約7割のコードが削減可能・initの動作に必要なAPI : 約1〜3割が削減可能・小規模モジュール (wc) : 約3割が削減可能 (73.3%) ・大規模モジュール (kermit) : 約1〜2割が削減可能 (84.1%) #POSIX系OSではファイルシステムがOSの基幹であるため #ファイルシステム部には余り効果が出ないまとめ・関数の呼出依存関係を元にした汎用OSの軽量化手法を示した・上記手法をMINIXに適用し、具体的に効果を示した今後の課題・手法の自動化・ソースレベルからバイナリレベルの検証へ・他のOSでの評価質疑応答 Q:実際に動かしてみているのか。現実に動くかどうかはわからないと言うことか A:動くはずだが、実際にはしていない。 Q:絶対に動くかどうかはフロー解析が完全かどうかにかかっていると思うが、その辺の確信は？ A:かなり安全側に倒しているので、自信はある。 Q:こういうのを使った場合、テストが問題になると思うが、同じOSでテストがなされているからと言って、削った後ではテストをしなければならないと思うが、それについてはどうか。 A:まだ考えていない。 Q:呼び出しグラフを作る過程はどうなっているのか。 A:Cで書かれているものを解析し、関数の中で他の関数を明示的に読んでいる場合と、関数ポインタがあった場合にはとりうる値を追跡する。メッセージを受けて分岐したり、いろいろな値をとりうる部分は手でやっている。 Q:ある程度自動化していくのは今後の課題か A:ある程度はやっている。自動化は今後の課題である。 Q:グラフは目に見える形でやっているのか、データ構造か。 A:データ構造 Q:汎用OSでこのアプローチをとった場合、MINIXに比べどのくらいの作業量がかかるのか A:ライブラリ解析だけで何倍もかかっている。カーネル部分に手を出しているが、手こずっている。コメント:逆にこういう解析を進めた場合、例えばLinuxなどでモジュール化を進めれば動的にできるだろうし、この他にも削れる所は出てくるのではないか。今のままでは、他の汎用OSに適用するにも作業量が多くて破綻するのではないか。 Q:ここでいうコードサイズと言うのはソースのライン数だが、オブジェクトサイズでの削減度合いはどのくらい？ A:まだやっていないコメント:必要なコード量の評価で、kermitはシリアル通信アプリで多くのAPIがあり複雑。単純によく使うAPIだけを抽出して、それだけコードサイズを抜き出した場合にどのくらいになるのかという情報が欲しい。その上でコード量がどのくらいになるのか現実的アプローチが欲しい。 Q:現実的に利用する場合を考えると、ソースを減らすよりはオブジェクト間の依存関係を出し、必要なオブジェクトのみがインストールされる方がいい（例 : Microsoft Windows NT Embedded）。 FreeUNIXを利用する場合にもそのようなアプローチがあれば便利である。１人でやるよりFreeUNIXとかのメンバに訴えて、ツール作りに行ったほうがよいのではないか。（依存関係のデータベースを作る等） A:そうした場合であれば，どの部分を使えばシステムを構築できるか、といった今までの成果部分に関しては情報を提供出来る。コメント:ソース自体をいじるので無く、オブジェクトモジュール単位でいいのではないか（そのほうが楽、かつ自動的にできる） -------------------------------------------------------------------------------- D2-2.「MPC860マイクロプロセッサ用Linuxを用いたVoIP向けRouter装置の開発」発表者：坂野恒之、福地敏裕（沖電気）背景・インターネット環境の爆発的な普及・現行のVoIP機能付きルータは高価である -> 安価な一般家庭用VoIP機能付きルータの需要要求項目・QoS保証型の低価格ルータ機能・ローカルアドレスに対応すたVoIP装置ハードウェア構成プロセッサ : モトローラ MPC860 (50MHz) #複数のシリアルコントローラを持つ RAM : 16MB Flash : 4MB Linux導入の経緯・TCP/IP, ルータ機能を有す・利用するハードウェアの対応状況・IPv4 -> IPv6への対応を考慮ソフトウェア実装時の問題 1. ブートプログラムローダ Linuxカーネル自体はローダ機能を提供しない -> GPLのローダを改造して利用 2. OSのサポート機種選択現在のカーネルでは汎用MPC860には非対応 -> MBX評価ボード用コードから移植 3. LANドライバ現在のカーネルでは1ポートのみ -> ルータ機能実現のため、2ポートへ拡張 4. メモリ使用量ルータ機能を実現するにはプログラムが大きすぎる (カーネル, shell, gated, rootd など約7MB (Flashは4MB)) →メモリディスク(以下MDK)を使用して立ち上げる. a.Linuxにもともと備わるMDKローダ・圧縮イメージをロード可能. ・ファイルシステム(FS)イメージの圧縮においてFS全体を元にイメージを作成するため、効果のある圧縮にならない b.LRP(Linux Rooter Project)の使用する方式・FS全体でなくファイル実体のみを結合して圧縮するため、圧縮後サイズが比較的小さくなる. ・装置ファイルの扱いが今回のシステムに有利。・RAMの半分(8MB)をディスクに割当て、圧縮イメージの展開に使用・後者の方式を採用 -> gatedが使用可能な環境へ 5. 処理能力現在は1Mbps程度 LANドライバ等の改良により1.5〜2Mbps程度のスループットを確保できると予測 -> 今後評価を続けていく予定まとめ・VoIP機能付きルータにLinuxを利用した事例を紹介 - 組込みシステムでは容量による制約が厳しい -> ランタイムライブラリが巨大用途に特化したライブラリがあれば組込みでも有用今後の課題 gatedの機能をカーネル内に組み込む質疑応答 Q:デバッグ環境は？ A:今回はカーネル部分なのでGDBは使わず、ほとんどprintfで行った。負荷をかけ、パケットがどう流れるかを確認することで行った。 Q:ドライバーポート上にprintkをかけて、その出力をPC側のコンソールに出力してという形か。 A:その通り。そのため本当にクリティカルな所はとれない。 Q:GDBのリモートデバッグ機能等を使う予定はないのか A:使ってみたいと思ってはいるが，今回は時間がなかったので使用していない。 Q:コーディング作業はどの辺で入ったのか。またその時間はどのくらいか？ A:ハードウエアを新たに作ったので、その辺のコーディング時間が一番長かったはず。実際のコーディング時間はブートローダを探して作る部分が一番長かった。その完成以後は1〜2ヶ月でコーディングは終了。（※NFSを利用し、ファイルシステムを外においた形で行った部分） Q:カーネルのversionは？ A:2.2.18。枯れてそうだったものを使用している。（ルータとの兼ね合いということではない） Q:立ちあがり時間が遅いという話があったが、どのくらいか。 A:ファイルの展開に20〜30秒かかる。 Q:Linuxということで、ソースは公開するのか A:現状では試作段階。まだ不完全でかつ納得できていないのでしないが、出来たら公開する。 Q:GPLによればソース公開の要望に応じる義務があるが、もし要望がでた場合にはにはどういう形で公開するのか。 A:企業の立場としてGPLは覚悟して使用しており、要求があればそうせざるを得ない。できるだけ公開する。ただしハードウエア依存がかなりあるので、汎用に公開する確率は低いと考えている。 Q:ドライバの部分とかを仕様を公開してしまうことになるが A:主なものは2ポート化であり、大した部分ではない。またドライバ部分はそんなにいじっていないので、大きな差し支えはないと考えている。 Q:今回は試作で製品ではないのか A:その通り。 Q:ブロードバンド化、IPv6等の話があったが、現実化した場合にはソフトウエア可変でそれに対応していくのか。またそれがいつ頃になるのか、普及するのかの予測はしているのか？ A:ソフトウエア可変で対応する。普及時期の予測については，まだ手が回っていない。とりあえずIPv4のルータをちゃんと動かすのが一番の課題。IPv6に関してはIntelのi386で動くことはわかっているので、そちらで検証を行ってからこちらに持ってくるように考えている。 Q:IPv6の話であれば、BSDのほうが向いていないか？ A:今回のLinuxはMPC860用に特化して作られていたことによるもの。ハードウエア依存の部分でBSDのほうも良くなればそちらに移行することも考えている。 -------------------------------------------------------------------------------- D2-3「SpecCとGUIコンポーネント間のインタラクション」発表者：島田耕吉、松本吉弘（武蔵工業大学）背景オブジェクト機構記述の問題点・オブジェクト間の接続が暗黙・オブジェクトのインタフェース仕様の変更が、システム全体に波及する -> 保守性, 再利用性の低下 -> アーキテクチャ記述を行なうことで回避可能 SpecCの問題点・ビヘイビア間の接続が暗黙・送受される情報の意味付けが行なわれていない (セマンティクスの欠如) -> 同様の問題が生じる -> SpecCのソフトウェアアーキテクチャの記述性に疑問視 #ソフトウェアにとっては抽象度が低すぎる -> 情報の欠如目的 SpecCでソフトウェアアーキテクチャを記述するために不足している部分を指摘・入出力端子, 接続の意味を明確化すべき・送受される情報の意味付けを行なうべきソフトウェアとしてGUIコンポーネントを例に採り、 Poll-Selection, CallBackの2つの実装手法について評価・検証を行なうソフトウェアアーキテクチャ記述コンポーネントの依存関係の明確化 (アーキテクチャ図) 関数の依存関係を明示するためのアーキテクチャ図を導入すべき (今回はLackmanの図を利用しているが、この図にこだわってはいない) -> 入出力端子/入出力接続間の明示を行なうことが可能今回のGUIコンポーネント部を図示 (SWEST3 予稿集 pp.103 - 図2 SpecC-GUI間のインタラクションを参照) ソフトウェアアーキテクチャ記述に必要な要素 Components : システムを構成する各部分要素 Connector : 交信路 Communication : 交信の持つ意味 Attachments : コンポーネント間の接続関係の明示化 (ポート間接続) -> これらの導入により、送受される情報の意味付けを行なうことが可能 Poll-SelectionによるGUIコンポーネントの記述前節で示したアーキテクチャのシーケンス図を作成する (SWEST3 予稿集 pp.104 - 図3 Poll-Selectionシーケンスダイアグラム1 を参照) (SWEST3 予稿集 pp.104 - 図4 Poll-Selectionシーケンスダイアグラム2 を参照) シーケンス図から、詳細情報を含むアーキテクチャ記述を作成する (SWEST3 予稿集 pp.105 - 図5 Poll-Selectionのアーキテクチャ記述を参照) CallBackによるGUIコンポーネントの記述前々節で示したアーキテクチャのシーケンス図を作成する (SWEST3 予稿集 pp.106 - 図6 CallBackシーケンスダイアグラム1 を参照) (SWEST3 予稿集 pp.106 - 図7 CallBackシーケンスダイアグラム2 を参照) シーケンス図から、詳細情報を含むアーキテクチャ記述を作成する (SWEST3 予稿集 pp.106 - 図8 CallBackのアーキテクチャ記述を参照) まとめ・現在のSpecCでソフトウェアアーキテクチャ記述を行なう際に不足している部分の明確化・不足部を補う手法の提案・GUIコンポーネントを例にした検証今後の課題・SpecCにアーキテクチャ記述向けの拡張を行なう・拡張したSpecCを用いてシーケンス図の自動生成を行なう質疑応答 Q: SpecCの図において、入力や出力は関数呼び出しを意味するものか A: SpecC内でのIN、OUTに対応（データの流れ） Q: アーキテクチャ図は何を表すのか A: ここで表すものが関数呼び出しである。 (今回はデータの受け渡しがなかったので示した図中には入っていないが)データ受け渡しもここに入る。図中で入出力として表現しているものが関数呼び出しである。接続関係の明示がこの図になる Q: その図だけだと呼び出すだけで、GUIもSpecC側も出力するのみに見えるが。 A: 実際のデータの流れはあくまで関数を呼び出しているだけであり、データを持ってくる場合には矢印の向きは逆向きに表現されることになる。 Q: 実際のアーキテクチャ記述を接続関係までいれこんだ形で表現出来るものが有ったする。「それを先に作り，変更があった場合には必ずアーキテクチャに戻ろう」という話なのか？それとも、「これがあれば自動的に解決する」という話なのか？アプローチ方法は？ A: 設計段階でアーキテクチャ記述をすることにより、全体を見なおさなくて良いというところから入っている。オブジェクト指向であれ，仕様記述言語であるSpecCによるソフトウエア記述であれ，ソフトウエアアーキテクチャの記述には不足となる点がある。仕様を書く時点で、アーキテクチャ記述をここまでやる必要があるのではないか，という点に主眼がある。 Q: 本件はSpecCのアーキテクチャ記述を補足するものということか。 A: その通り。 Q: アーキテクチャ記述がC++の様な具体的な言語にはないというのは理解できるが、オブジェクト指向という"指向"に無いというには違和感がある。 UMLの様な方法を用いて関係を表現するものがあるが，本件はそういった他の方法論との比較がテーマにあるのではなく、SpecCを使ってやることが前提なのか。 A: その通り。 Q: アーキテクチャの図はどこからか引用したものか。 A: 文献から引用したものである。実際には3Dの図である必要は無いと考えられるが。コメント: この図が書きにくいので，書きやすくなることを期待する Q: シーケンス図上で名前の無い線は何を表すのか。 A: アーキテクチャ記述自体には関係のないデータの流れを表している。 Q: SpecCを組み込んだ実例はあるのか。 A: 発表者らのところにはGUIとの関連で作ったものが存在するが，どこかのメーカが使った実例(コードを生成し組込みに使った例)があるのかどうかは知らない。 Q: SpecCの部分とGUIの部分が同じように書いてあるが、GUIもSpecCで書けるのか？ A: そういう意味ではない。現実には難しいと考えられる。 Q: それはSpecCのスペックが足りないという意味ではなく、コード生成に問題があるということなのか。 A: GUIもSpecCも状態遷移的に動いているのではないかということでこの図になっているだけ。 GUIが書けるかどうかということではない。 Q: ポーリングしているところがあるが、これは限定しているのか。 A: 限定しているわけではない。今回の例としてポーリングを用いたものである。 Q: より複雑なシステムにもできるのか。 A: そうなることも可能であると考えている。