u-Texture構造記述ソフトウェア構成 ide 全体構成構造記述構築データ解析（加速度，接続検知，近接検知）チャネルを介した通信シリアルからデータを取得するモジュール次スライドからここの設計に関しての詳細 Boardが来る前加速度モジュール接続検知モジュールそれぞれのCOMポート近接検知モジュール当初の設計方針 • 既存の設計 – 各モジュールの要求に対して，それぞれのモジュールにSerialPortオブジェクトが用意される（SerialPortオブジェクトはCOMに対してただ１つ生成可能） • 既存の設計を再利用 – 複数の同一SerialPortオブジェクトの要求に対して，一番最初の要求時にキャッシュした SerialPortオブジェクトを返す Boardでの当初の設計加速度モジュール接続検知モジュール近接検知モジュール仮想的COMポートここで問題が起きていた ORF前の設計と問題１ • javacommにて取得したSerialPortオブジェクトをキャッシュして要求に応じて各モジュール（加速度，接続，近接）に渡していた． – キャッシュをstaticフィールドに置いてSerialPort オブジェクトを生成する（キャッシュを扱う）メソッドをsynchronizedにしても，キャッシュが使われない問題（再現性無し） • キャッシュしても再度取得に行き，エラーが出力される • エラーが出る場合と出ない場合がある • ミドルウェア内で異なるVMで起動されている？？問題点の分析と解決法 • 分析結果 – ミドルウェア内部のコンポーネント起動手順まで調べなければならず，特定が困難 • 解決法 – 既存の設計に捉われず，問題がおきない設計に変更変更後の設計加速度モジュール接続検知モジュール近接検知モジュール Channel 変更後の設計 • 動作の流れ – SerialPortオブジェクトを扱うモジュールは１つ – Channelを介してStringデータを流す – 加速度，接続，近接の各モジュールが必要なデータを利用 • 利点 – それぞれのモジュールが独立して動いているため，コンポーネントとして単純になる進捗状況構造記述構築仮想データにて動作確認実機で要動作確認データ解析（加速度，接続検知，近接検知）加速度，接続は要動作確認近接は動作確認済シリアルからデータを取得するモジュール動作確認済（ORFでも利用）チャネルを介した通信