ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
CORBAについて調べていたのですが、この資料がとても参考になりました。
皆さんもCORBAを実装する際は参考にしてみてはいかがでしょうか？
どうにもCORBAが僕みたいな素人には理解しづらい原因として、仕組み以前に用語の意味がよくわからないということがあると思います。
例えば以下の用語です。
まあでも自分でRTミドルウェアを実装するにしても既存のCORBA実装を使えば十分な事も多いと思うので、このブログを見てる人でCORBAから実装しようとか考えている人はいないかもしれないですけど。
それはさておき、今回はユースケース図の話をします。
astah* communityを起動して図→ユースケース図を選択してください。
とりあえず適当にアクターとユースケースを追加してみます。
アクターはシステムを利用するユーザー等の外部に存在するもの、ユースケースはアクターがシステムを使ってできる事を表現しているとかそうではないとからしいです。
通常は以下のように作成したシステムはサブジェクトという四角形で囲むらしいのですが、作成するボタンが見つからなかったため長方形とテキストで形だけ作っています。
拡張ボタンを選択後、ユースケースを選択すると拡張を表現できます。
以下の場合ユースケース0がユースケース1に機能を追加するという意味になるとからしいです。
包含ボタンを選択後ユースケースを選択すると包含を表現できます。
ユースケース0はユースケース1が含まれているという意味とからしいです
汎化ボタンを選択後、ユースケースもしくはアクターを選択すると汎化を表現できます。
以下の場合、ユースケース0はユースケース1をより具体化したものになるとかならないとからしいです。
さらに拡張するタイミングを定義した拡張点を追加できるとからしいです。
拡張点はユースケースを選択後、左下のウィジェットから拡張点タブを選択して追加できるみたいです。
このサイトを読んでると、拡張点は以下のように表現できるらしいですが上の図と意味は同じと考えていいのでしょうかね？
UMLの話は今日でとりあえず終わりにします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
皆さんもCORBAを実装する際は参考にしてみてはいかがでしょうか？
どうにもCORBAが僕みたいな素人には理解しづらい原因として、仕組み以前に用語の意味がよくわからないということがあると思います。
例えば以下の用語です。
- GIOP
- IIOP
- IDL
- スタブ
- スケルトン
- orb
- ネーミングサービス
- POA
- CDR
まあでも自分でRTミドルウェアを実装するにしても既存のCORBA実装を使えば十分な事も多いと思うので、このブログを見てる人でCORBAから実装しようとか考えている人はいないかもしれないですけど。
それはさておき、今回はユースケース図の話をします。
astah* communityを起動して図→ユースケース図を選択してください。
とりあえず適当にアクターとユースケースを追加してみます。
アクターはシステムを利用するユーザー等の外部に存在するもの、ユースケースはアクターがシステムを使ってできる事を表現しているとかそうではないとからしいです。
通常は以下のように作成したシステムはサブジェクトという四角形で囲むらしいのですが、作成するボタンが見つからなかったため長方形とテキストで形だけ作っています。
拡張ボタンを選択後、ユースケースを選択すると拡張を表現できます。
以下の場合ユースケース0がユースケース1に機能を追加するという意味になるとからしいです。
包含ボタンを選択後ユースケースを選択すると包含を表現できます。
ユースケース0はユースケース1が含まれているという意味とからしいです
汎化ボタンを選択後、ユースケースもしくはアクターを選択すると汎化を表現できます。
以下の場合、ユースケース0はユースケース1をより具体化したものになるとかならないとからしいです。
さらに拡張するタイミングを定義した拡張点を追加できるとからしいです。
拡張点はユースケースを選択後、左下のウィジェットから拡張点タブを選択して追加できるみたいです。
このサイトを読んでると、拡張点は以下のように表現できるらしいですが上の図と意味は同じと考えていいのでしょうかね？
UMLの話は今日でとりあえず終わりにします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
自分で面白かもしれないと思った事を調べてみたところ、既に誰かがやっていたと分かるとがっかりしますね。常識の斜め上を行ったつもりだったのですが、さらに上をいく変態がいたとは思いませんでした。恥ずかしいので何をやろうとしていたかは言いませんけど。
それはさておき、今回は配置図の話をします。
astah* communityを起動して図→配置図を選択してください。
まずは適当にノードを追加してみます。
ステレオタイプがdeviceの場合はハードウェアデバイス、executionEnvironmentの場合は実行環境を表現しているとからしいです。
以下のように階層構造にすることもできるとからしいです。
成果物という要素を追加できるとからしいですが、astah* communityで追加する方法がわかりません。
関連ボタンを選択後、ノードを選択するとコミュニケーションパスが追加できます。
方向が決まっている場合は以下のように矢印を表記しても良いとからしいです。
矢印は左下のウィジェットから関連端AかBのタブを開いて誘導可能をnavigateに設定すれば付加されます。
今日もあまり書くことがなさそうなのでコメントの付け方も書いておきます。
まずノートボタンを選択後、ノートを適当なところに配置してください。
それからノートから図要素へのアンカーボタンを選択してノートと注釈を記述したいオブジェクトを選択してください。
あとはノートに注釈を書くだけです。
今日はこのぐらいにしておきます。
明日はユースケース図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
それはさておき、今回は配置図の話をします。
astah* communityを起動して図→配置図を選択してください。
まずは適当にノードを追加してみます。
ステレオタイプがdeviceの場合はハードウェアデバイス、executionEnvironmentの場合は実行環境を表現しているとからしいです。
以下のように階層構造にすることもできるとからしいです。
成果物という要素を追加できるとからしいですが、astah* communityで追加する方法がわかりません。
関連ボタンを選択後、ノードを選択するとコミュニケーションパスが追加できます。
方向が決まっている場合は以下のように矢印を表記しても良いとからしいです。
矢印は左下のウィジェットから関連端AかBのタブを開いて誘導可能をnavigateに設定すれば付加されます。
今日もあまり書くことがなさそうなのでコメントの付け方も書いておきます。
まずノートボタンを選択後、ノートを適当なところに配置してください。
それからノートから図要素へのアンカーボタンを選択してノートと注釈を記述したいオブジェクトを選択してください。
あとはノートに注釈を書くだけです。
今日はこのぐらいにしておきます。
明日はユースケース図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
この作品やこの作品のソースコードを読んでいると、内容が同じ関数を別のファイルで使う際に直接関数のコードをコピーしているように見えます。その関数を変更する場合を考えると他のファイルに分離して使い回した方が良いかもしれないです。
それはさておき、今回はコミュニケーション図の話をします。
astah* communityを起動して図→コミュニケーション図を選択してください。
コミュニケーション図で設置可能なオブジェクトを並べてみました。
アクターはシステムの利用者、または外部システム等を表現しているとからしいです。
Entityはデータベース等を表しているとかそうではないとからしいです。
Boundaryはユーザーインターフェース等アクターからイベントを受け取る役割があるらしいです。
Controlは正直よくわからないのですが、実際に処理を行うオブジェクトという解釈で良いのでしょうかね？
Business～はビジネスモデリングで使うとからしいです。
まずリンクボタンを選択してオブジェクトを選択するとリンクが作成されます。
メッセージボタンを選択した後リンクを選択して矢印の方向を選択するとメッセージが作成されます。
引数、返り値等はメッセージを選択後左下のウィジェットから設定できます。
同期メッセージの場合は以下の矢印になります。
非同期メッセージの場合は以下のようになります。
シーケンス図と共通する事が多いのであまり書くこともないですね。
今日はこれぐらいにしておきます。
明日は配置図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
それはさておき、今回はコミュニケーション図の話をします。
astah* communityを起動して図→コミュニケーション図を選択してください。
コミュニケーション図で設置可能なオブジェクトを並べてみました。
アクターはシステムの利用者、または外部システム等を表現しているとからしいです。
Entityはデータベース等を表しているとかそうではないとからしいです。
Boundaryはユーザーインターフェース等アクターからイベントを受け取る役割があるらしいです。
Controlは正直よくわからないのですが、実際に処理を行うオブジェクトという解釈で良いのでしょうかね？
Business～はビジネスモデリングで使うとからしいです。
まずリンクボタンを選択してオブジェクトを選択するとリンクが作成されます。
メッセージボタンを選択した後リンクを選択して矢印の方向を選択するとメッセージが作成されます。
引数、返り値等はメッセージを選択後左下のウィジェットから設定できます。
同期メッセージの場合は以下の矢印になります。
非同期メッセージの場合は以下のようになります。
シーケンス図と共通する事が多いのであまり書くこともないですね。
今日はこれぐらいにしておきます。
明日は配置図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
この作品のコメントでrtcdで起動したRTCの通信よりも共有メモリの通信の方が速いとか書いてましたけど、どうやらもう一度実験しても共有メモリの方が速いみたいな事を書いてありますね。どんなプログラムで実験をしたのかは知りませんけど、結果としてそうなったのならそうなのかもしれません。ただ同一プロセス上で起動したRTCの場合は単なる関数呼び出しでデータを受け渡せるはずなので、共有メモリより遅い理由を説明してほしいです。わかっているならもったいぶらずに教えてくれてもいいと思いますけどね。
それはさておき今回はステートマシン図の話をします。
astah* communityを起動して図→ステートマシン図を選択してください。
とりあえず使いそうな要素を並べてみました。
簡単に図を作ってみました。
この図の場合は開始後、状態0に遷移してact0を実行→状態0に留まっている間はact1を実行→状態から出るときにact2を実行して終了状態に遷移するとかしないとからしいです。
entry、do、exitは状態を選択して左下の設定ウィジェットから設定できます。
上の図の場合はトリガー、ガード条件、エフェクトを設定していないため、entry、doアクティビティが終了すると状態が遷移するとからしいです。
以下のようにトリガー、ガード条件、エフェクトを表現できます。
矢印を選択して左下の設定ウィジェットから設定できます。
状態0でトリガーで設定したイベントが発生すると遷移します。
ただし、ガードが設定してある場合はトリガーが発生してもガード条件が成立していないと遷移しないらしいです。
さらにアクションを設定している場合は遷移発生時に設定したアクションを実行します。
さらに状態の中に開始状態等を入れることで内部に状態遷移を持つコンポジット状態を表現できます。
通常は内部の開始状態から始まり、終了状態に遷移すると次の状態に遷移するらしいです。
トリガを設定している場合は、終了状態に遷移してなくても次の状態に遷移するという解釈で合っているのでしょうかね？
入場点、退場点を追加することで任意の状態からの開始、任意の状態に遷移出来るらしいですが、astah* communityで追加する方法がわかりません。詳しい人は教えてください。何だか最近こればっかり言っているような気がします。
複数処理を並行して実行したい場合は以下のようにを表現できます。
これを直交状態と呼ぶらしいです。
この場合、全ての直交状態が終了後に遷移します。
状態0を右クリックして領域の追加→横領域の追加を選択後、追加した領域に状態を設定することで直交状態を作成できます。
フォーク、ジョインを使用することでも上の図と同じことを表現できるとかできないとからしいです。
以下のように浅い履歴擬似状態ボタンを押すことで浅い履歴擬似状態を追加できます。
この場合、状態6の時にトリガー1を満たすと状態10に遷移しますが、再び状態6に遷移しようとすると通常は状態6の開始状態に遷移するはずですが、浅い履歴擬似状態に遷移した場合は状態6から抜けるときに記憶した状態に遷移するらしいです。例えば、状態7の時に状態10に遷移した場合、浅い履歴擬似状態に遷移したときに状態7に遷移するとかそうではないとかということでしょうかね？
深い履歴擬似状態という要素を追加してみます。
状態9の状態11の時に状態6から遷移した場合、浅い履歴擬似状態の場合は状態9の開始状態に遷移しますが、深い履歴擬似状態の場合は状態11から開始するとからしいです。
ジャンクション擬似状態ボタンを選択すると、ジャンクション擬似状態を追加できます。
選択擬似状態ボタンを選択すると、選択擬似状態を追加できます。
正直違いがわからなかったので、このサイトを読みながらどういう遷移をするのかを考えてみます。むしろリンク先のサイトが分かりやすかったのでそちらを読んだ方が良いと思います。
どちらも遷移後にガード14とガード15の条件を満たす状態に遷移すると言う事は変わらないのですが、ジャンクション擬似状態の場合は遷移する前後のガード条件を同時に評価するらしいです。
つまりジャンクション擬似状態の場合、ガード13とガード14、ガード15を同時に評価するため、ガード14、ガード15をどちらも満たさない場合は状態13に留まることになります。
さらにアクション13が実行されるのもガード13とガード14、ガード15の評価後と言う事になります。
選択擬似状態の場合はガード13を評価後、アクション13を実行して選択擬似状態に遷移、その後ガード14とガード15を評価します。この時ガード14とガード15のどちらも満たさない場合は状態が不確定になります。
そのため以下のようにどの条件も満たさない場合の遷移も設定しておく必要があります。
今日はこのぐらいにしておきます。
明日はコミュニケーション図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
それはさておき今回はステートマシン図の話をします。
astah* communityを起動して図→ステートマシン図を選択してください。
とりあえず使いそうな要素を並べてみました。
簡単に図を作ってみました。
この図の場合は開始後、状態0に遷移してact0を実行→状態0に留まっている間はact1を実行→状態から出るときにact2を実行して終了状態に遷移するとかしないとからしいです。
entry、do、exitは状態を選択して左下の設定ウィジェットから設定できます。
上の図の場合はトリガー、ガード条件、エフェクトを設定していないため、entry、doアクティビティが終了すると状態が遷移するとからしいです。
以下のようにトリガー、ガード条件、エフェクトを表現できます。
矢印を選択して左下の設定ウィジェットから設定できます。
状態0でトリガーで設定したイベントが発生すると遷移します。
ただし、ガードが設定してある場合はトリガーが発生してもガード条件が成立していないと遷移しないらしいです。
さらにアクションを設定している場合は遷移発生時に設定したアクションを実行します。
さらに状態の中に開始状態等を入れることで内部に状態遷移を持つコンポジット状態を表現できます。
通常は内部の開始状態から始まり、終了状態に遷移すると次の状態に遷移するらしいです。
トリガを設定している場合は、終了状態に遷移してなくても次の状態に遷移するという解釈で合っているのでしょうかね？
入場点、退場点を追加することで任意の状態からの開始、任意の状態に遷移出来るらしいですが、astah* communityで追加する方法がわかりません。詳しい人は教えてください。何だか最近こればっかり言っているような気がします。
複数処理を並行して実行したい場合は以下のようにを表現できます。
これを直交状態と呼ぶらしいです。
この場合、全ての直交状態が終了後に遷移します。
状態0を右クリックして領域の追加→横領域の追加を選択後、追加した領域に状態を設定することで直交状態を作成できます。
フォーク、ジョインを使用することでも上の図と同じことを表現できるとかできないとからしいです。
以下のように浅い履歴擬似状態ボタンを押すことで浅い履歴擬似状態を追加できます。
この場合、状態6の時にトリガー1を満たすと状態10に遷移しますが、再び状態6に遷移しようとすると通常は状態6の開始状態に遷移するはずですが、浅い履歴擬似状態に遷移した場合は状態6から抜けるときに記憶した状態に遷移するらしいです。例えば、状態7の時に状態10に遷移した場合、浅い履歴擬似状態に遷移したときに状態7に遷移するとかそうではないとかということでしょうかね？
深い履歴擬似状態という要素を追加してみます。
状態9の状態11の時に状態6から遷移した場合、浅い履歴擬似状態の場合は状態9の開始状態に遷移しますが、深い履歴擬似状態の場合は状態11から開始するとからしいです。
ジャンクション擬似状態ボタンを選択すると、ジャンクション擬似状態を追加できます。
選択擬似状態ボタンを選択すると、選択擬似状態を追加できます。
正直違いがわからなかったので、このサイトを読みながらどういう遷移をするのかを考えてみます。むしろリンク先のサイトが分かりやすかったのでそちらを読んだ方が良いと思います。
どちらも遷移後にガード14とガード15の条件を満たす状態に遷移すると言う事は変わらないのですが、ジャンクション擬似状態の場合は遷移する前後のガード条件を同時に評価するらしいです。
つまりジャンクション擬似状態の場合、ガード13とガード14、ガード15を同時に評価するため、ガード14、ガード15をどちらも満たさない場合は状態13に留まることになります。
さらにアクション13が実行されるのもガード13とガード14、ガード15の評価後と言う事になります。
選択擬似状態の場合はガード13を評価後、アクション13を実行して選択擬似状態に遷移、その後ガード14とガード15を評価します。この時ガード14とガード15のどちらも満たさない場合は状態が不確定になります。
そのため以下のようにどの条件も満たさない場合の遷移も設定しておく必要があります。
今日はこのぐらいにしておきます。
明日はコミュニケーション図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
前々から言っていますがCMakeとビルドが必要なのであれば、マニュアルとかに手順を書いていないと不親切だと思います。
誰に使ってほしいのでしょうか？作品を見に来る人が上級者ばかりとは限りません。僕みたいな初心者が見る事もあります。
実行ファイルを配布するのであれば必要なdllを同梱するか、入手方法をマニュアルに記載してください。ただ実行ファイルを配布する場合、既にインストールしているdllと違うバージョンのdllに依存していると非常に面倒ですね。
それはさておき、今回はコンポーネント図の話をします。
astah* communityを起動して図→コンポーネント図を選択してください。
とりあえず適当にコンポーネントを追加して、提供インターフェース、要求インターフェースを追加してください。
左が提供インターフェース、右が要求インターフェースを表しています。
提供インターフェースは機能を外部に提供、要求インターフェースは外部の機能を要求しているようです。
次にパートを追加します。
パートはコンポーネントの内部要素を表現するとかそうではないとからしいです。
以下のようにポートボタンを選択後、コンポーネントを選択するとポートを追加できます。
ポートは内部と外部の境界を表現しているとからしいです。
提供インターフェースと要求インターフェースを接続する方法がよくわらなかったのですが、使用依存ボタンを選択後コンポーネントと提供インターフェースを選択すると接続されたので、そうしてください。
依存を表現したい場合は以下のようにしてください。
提供インターフェースに依存を設定することもできるようです。
ここからは僕の個人的な考えを書きます。
SysMLとOpenRTM-aistを連携させるツール等が最近開発されているようです。
このページのソフトウェアもそうなのでしょうかね？
コンポーネント図の表現方法は確かにRTシステムの設計には相性はよさそうに見えます。
ただ、慎重に設計しないと粒度を細かくしすぎるのではないかと思います。
そもそもコンポーネント図のコンポーネントは「ファイル、ヘッダ、ライブラリ、モジュール、実行可能ファイルやパッケージなど」という定義らしいのですが、コンポーネント図のコンポーネントを全てRTコンポーネント、もしくは複合コンポーネントに当てはめてしまっても良いのかがよくわかりません。
ファイル等に分割する場合に比べて、RTコンポーネントを細かく分割するのはデメリットが大きいのはこのブログで何度も言っていることです。
再利用性の低いコンポーネントをRTコンポーネントとして分割する事は、複数人で開発している場合は分担できるメリットがあるかもしれないですけど、実装が完了してしまえばオーバーヘッドが大きい等デメリットしか残りません。
なのでコンポーネント図を作成した際、再利用性の低いコンポーネントはファイル、ライブラリとして、再利用性の高いコンポーネントはRTコンポーネントとすれば実用的なシステムができると思うのですけど、どうでしょうか？
まあ素人の考えなので、詳しい人は教えてください。
今日はこのぐらいにしておきます。
明日はステートマシン図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
誰に使ってほしいのでしょうか？作品を見に来る人が上級者ばかりとは限りません。僕みたいな初心者が見る事もあります。
実行ファイルを配布するのであれば必要なdllを同梱するか、入手方法をマニュアルに記載してください。ただ実行ファイルを配布する場合、既にインストールしているdllと違うバージョンのdllに依存していると非常に面倒ですね。
それはさておき、今回はコンポーネント図の話をします。
astah* communityを起動して図→コンポーネント図を選択してください。
とりあえず適当にコンポーネントを追加して、提供インターフェース、要求インターフェースを追加してください。
左が提供インターフェース、右が要求インターフェースを表しています。
提供インターフェースは機能を外部に提供、要求インターフェースは外部の機能を要求しているようです。
次にパートを追加します。
パートはコンポーネントの内部要素を表現するとかそうではないとからしいです。
以下のようにポートボタンを選択後、コンポーネントを選択するとポートを追加できます。
ポートは内部と外部の境界を表現しているとからしいです。
提供インターフェースと要求インターフェースを接続する方法がよくわらなかったのですが、使用依存ボタンを選択後コンポーネントと提供インターフェースを選択すると接続されたので、そうしてください。
依存を表現したい場合は以下のようにしてください。
提供インターフェースに依存を設定することもできるようです。
ここからは僕の個人的な考えを書きます。
SysMLとOpenRTM-aistを連携させるツール等が最近開発されているようです。
このページのソフトウェアもそうなのでしょうかね？
コンポーネント図の表現方法は確かにRTシステムの設計には相性はよさそうに見えます。
ただ、慎重に設計しないと粒度を細かくしすぎるのではないかと思います。
そもそもコンポーネント図のコンポーネントは「ファイル、ヘッダ、ライブラリ、モジュール、実行可能ファイルやパッケージなど」という定義らしいのですが、コンポーネント図のコンポーネントを全てRTコンポーネント、もしくは複合コンポーネントに当てはめてしまっても良いのかがよくわかりません。
ファイル等に分割する場合に比べて、RTコンポーネントを細かく分割するのはデメリットが大きいのはこのブログで何度も言っていることです。
再利用性の低いコンポーネントをRTコンポーネントとして分割する事は、複数人で開発している場合は分担できるメリットがあるかもしれないですけど、実装が完了してしまえばオーバーヘッドが大きい等デメリットしか残りません。
なのでコンポーネント図を作成した際、再利用性の低いコンポーネントはファイル、ライブラリとして、再利用性の高いコンポーネントはRTコンポーネントとすれば実用的なシステムができると思うのですけど、どうでしょうか？
まあ素人の考えなので、詳しい人は教えてください。
今日はこのぐらいにしておきます。
明日はステートマシン図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
