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

u-Texture構造記述 ソフトウェア構成