ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
前々から言っていますが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コンポーネントとすれば実用的なシステムができると思うのですけど、どうでしょうか？
まあ素人の考えなので、詳しい人は教えてください。
今日はこのぐらいにしておきます。
明日はステートマシン図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
それにしてもあれから全くコメント付かないなあ。
まあ他の作品もそうなので気にするほどの事でもないのですが。
締め切り早かった意味があまりないように思います。
それはさておき今回はシーケンス図の話をします。
astah* communityを起動して図→シーケンス図を選択してください。
とりあえずライフラインを2つ追加してください。
ライフラインは使用するオブジェクトを表現するとからしいです。
次にメッセージボタンを選択後ライフラインを選択してメッセージを作成してください。
この際表示される四角形は実行指定という名前らしいです。
生成したメッセージを選択すれば、左下のウィジェットから引数等を設定できます。
戻り値変数 = 名前(引数)：戻り値
と表記されるみたいです。
ちなみに破線の矢印は同期メッセージで呼び出された処理が終了した事を表現しています。
上のメッセージとの違いが分かりづらいですが、以下の矢印の場合非同期メッセージになります。
ちなみに以下の矢印は同期メッセージです。
同期メッセージはライフライン2(送信先のライフライン)の処理が完了するまでライフライン1(送信元のライフライン)の処理は待機します。
一方、非同期メッセージはライフライン2の処理の完了を待つことはありません。
さらに生成メッセージは以下のように表現します。
生成メッセージを送信することにより、新たにオブジェクトを生成します。
破棄メッセージは以下のように表現します。
これにより送信先のオブジェクトを破棄します。
自分自身の内部処理等を呼び出す場合は以下のように表現します。
非同期メッセージ、生成メッセージ、破棄メッセージ、同期メッセージの戻りを生成する場合は以下のボタンから選択後、ライフラインを選択してください。
別のダイアグラムの相互作用を参照する場合は以下のように表現するらしいです。
ちなみにシーケンス図3は以下のようになっています。
追加する場合は相互作用の利用ボタンを選択後、適当な大きさを設定してください。
さらに作成した要素を選択して、左下のウィジェットから設定してください。
複合フラグメントボタンを選択後、適当な大きさを設定することで複合フラグメントを作成できます。
上の図のopt(オプト)はガード条件を満たす場合に相互作用を実行します。
設定は複合フラグメントを選択して左下のウィジェットから設定してください。
以下のようにalt(オルタナティブ)に設定するとガード条件によって分岐します。
ガード条件は左下のウィジェットのオペランドタブで追加してください。
以下のようにloop(ループ)を設定することで繰り返し処理を表現できます。
以下のようにpar(パラレル)とすることで複数のメッセージの並行した送受信を表現できます。
以下のようにcritical(クリティカル領域)とすることで、他の処理からの割り込みを許可しない事を表現できます。
以下のようにseq(弱シーケンス)とするとメッセージを送信する順番に関する制約が弱く、strict(強シーケンス)とすると制約が強くなるらしいですが、具体的にどういう違いが生じるのかあまり理解できていません。
以下のようにbreak(ブレイク)と設定することでbreakの複合フラグメントを含む複合フラグメントを中断できます。
以下のようにneg(否定)とした場合は正常に動作できないかもしれない事を表現しているらしいです。
つまり、negに設定しても動作自体には何の影響もないということでしょうかね？
以下のようにignore(無効)とすると、あるメッセージの送受信を一時的に行わないことを表現できます。
この場合、メッセージ11の送受信を行わないという事でしょうかね？
consider(有効)とする事で、あるメッセージの送受信のみ行うという事を表現できるとからしいです。
この場合、メッセージ11以外のメッセージは送受信しないということになるとかならないとからしいです。
assert(アサーション)に設定すると、処理の流れをテストすると言う事を表現できるとからしいです。
今日はこのぐらいにしておきます。
明日はコンポーネント図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
まあ他の作品もそうなので気にするほどの事でもないのですが。
締め切り早かった意味があまりないように思います。
それはさておき今回はシーケンス図の話をします。
astah* communityを起動して図→シーケンス図を選択してください。
とりあえずライフラインを2つ追加してください。
ライフラインは使用するオブジェクトを表現するとからしいです。
次にメッセージボタンを選択後ライフラインを選択してメッセージを作成してください。
この際表示される四角形は実行指定という名前らしいです。
生成したメッセージを選択すれば、左下のウィジェットから引数等を設定できます。
戻り値変数 = 名前(引数)：戻り値
と表記されるみたいです。
ちなみに破線の矢印は同期メッセージで呼び出された処理が終了した事を表現しています。
上のメッセージとの違いが分かりづらいですが、以下の矢印の場合非同期メッセージになります。
ちなみに以下の矢印は同期メッセージです。
同期メッセージはライフライン2(送信先のライフライン)の処理が完了するまでライフライン1(送信元のライフライン)の処理は待機します。
一方、非同期メッセージはライフライン2の処理の完了を待つことはありません。
さらに生成メッセージは以下のように表現します。
生成メッセージを送信することにより、新たにオブジェクトを生成します。
破棄メッセージは以下のように表現します。
これにより送信先のオブジェクトを破棄します。
自分自身の内部処理等を呼び出す場合は以下のように表現します。
非同期メッセージ、生成メッセージ、破棄メッセージ、同期メッセージの戻りを生成する場合は以下のボタンから選択後、ライフラインを選択してください。
別のダイアグラムの相互作用を参照する場合は以下のように表現するらしいです。
ちなみにシーケンス図3は以下のようになっています。
追加する場合は相互作用の利用ボタンを選択後、適当な大きさを設定してください。
さらに作成した要素を選択して、左下のウィジェットから設定してください。
複合フラグメントボタンを選択後、適当な大きさを設定することで複合フラグメントを作成できます。
上の図のopt(オプト)はガード条件を満たす場合に相互作用を実行します。
設定は複合フラグメントを選択して左下のウィジェットから設定してください。
以下のようにalt(オルタナティブ)に設定するとガード条件によって分岐します。
ガード条件は左下のウィジェットのオペランドタブで追加してください。
以下のようにloop(ループ)を設定することで繰り返し処理を表現できます。
以下のようにpar(パラレル)とすることで複数のメッセージの並行した送受信を表現できます。
以下のようにcritical(クリティカル領域)とすることで、他の処理からの割り込みを許可しない事を表現できます。
以下のようにseq(弱シーケンス)とするとメッセージを送信する順番に関する制約が弱く、strict(強シーケンス)とすると制約が強くなるらしいですが、具体的にどういう違いが生じるのかあまり理解できていません。
以下のようにbreak(ブレイク)と設定することでbreakの複合フラグメントを含む複合フラグメントを中断できます。
以下のようにneg(否定)とした場合は正常に動作できないかもしれない事を表現しているらしいです。
つまり、negに設定しても動作自体には何の影響もないということでしょうかね？
以下のようにignore(無効)とすると、あるメッセージの送受信を一時的に行わないことを表現できます。
この場合、メッセージ11の送受信を行わないという事でしょうかね？
consider(有効)とする事で、あるメッセージの送受信のみ行うという事を表現できるとからしいです。
この場合、メッセージ11以外のメッセージは送受信しないということになるとかならないとからしいです。
assert(アサーション)に設定すると、処理の流れをテストすると言う事を表現できるとからしいです。
今日はこのぐらいにしておきます。
明日はコンポーネント図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
今回はパッケージ図の話をします。
astah* communityを起動して図→クラス図を選択してください。
適当にパッケージを追加してください。
まずは入れ子構造を定義してみます。
以下のようにネスト接続するかパッケージを含んで表現する方法があります。
入れ子構造にすることでパッケージをグループ化できるとからしいです。
依存ボタンを選択後、パッケージを選択することで依存を定義できます。
この場合はパッケージ0がパッケージ2に依存しており、パッケージ2を利用していると言う事らしいです。
なんだかあまり書くこともないようなので構造設計時のダイアグラムについて書いておきます。
以下のダイアグラムがあるらしいです。
コンポジット構造図はクラス等の内部構造を表現するとからしいです。
正直なところ、パッケージ図、コンポーネント図、クラス図の明確な違いがよくわからないのですが、粒度としてはパッケージ＞コンポーネント＞クラスとなるらしいです。
Javaとかでもクラスをパッケージにまとめる事ができますが、そういう事をするという解釈でいいのでしょうかね？
となるとコンポーネントは一体何を表現しているのでしょうね？
wikipediaでコンポーネント図を調べてみると、「ファイル、ヘッダ、ライブラリ、モジュール、実行可能ファイルやパッケージなど」とからしいです。
クラスやパッケージと明確な区別があるようには思えないのですが、どういう違いなのか詳しい人がいれば教えてください。
今日はこのぐらいにしておきます。
明日はシーケンス図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
astah* communityを起動して図→クラス図を選択してください。
適当にパッケージを追加してください。
まずは入れ子構造を定義してみます。
以下のようにネスト接続するかパッケージを含んで表現する方法があります。
入れ子構造にすることでパッケージをグループ化できるとからしいです。
依存ボタンを選択後、パッケージを選択することで依存を定義できます。
この場合はパッケージ0がパッケージ2に依存しており、パッケージ2を利用していると言う事らしいです。
なんだかあまり書くこともないようなので構造設計時のダイアグラムについて書いておきます。
以下のダイアグラムがあるらしいです。
- パッケージ図
- コンポーネント図
- コンポジット構造図
- クラス図
- オブジェクト図
コンポジット構造図はクラス等の内部構造を表現するとからしいです。
正直なところ、パッケージ図、コンポーネント図、クラス図の明確な違いがよくわからないのですが、粒度としてはパッケージ＞コンポーネント＞クラスとなるらしいです。
Javaとかでもクラスをパッケージにまとめる事ができますが、そういう事をするという解釈でいいのでしょうかね？
となるとコンポーネントは一体何を表現しているのでしょうね？
wikipediaでコンポーネント図を調べてみると、「ファイル、ヘッダ、ライブラリ、モジュール、実行可能ファイルやパッケージなど」とからしいです。
クラスやパッケージと明確な区別があるようには思えないのですが、どういう違いなのか詳しい人がいれば教えてください。
今日はこのぐらいにしておきます。
明日はシーケンス図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
今回はクラス図の話をします。
astah* communityを起動して図→クラス図を選択してください。
とりあえず適当にクラスを追加してみます。
次に黄色のひし形のマークをクリックすると属性が追加されます。
また、クラスを選択して左下の操作ウィジェットからも追加できます。
追加した属性をクリックすると以下のウィジェットから設定できるようになると思うので、適当に設定してみます。
可視性は上の設定ウインドウではわかりやすいですが、クラス図では以下のように+がpublic、-がprivate、#がproctected、~がpackageとなるので覚えておきましょう。
正直よくわからないのですけど、以下のように接続することで関連を定義できるらしいです。
他のクラスの属性として保持するなり何らかのつながりさえあれば関連を定義できるということでしょうかね？
さらに以下のように多重度を設定すると、クラス0がクラス1を属性として保持する場合にクラス1のオブジェクトをいくつ保持できるかを表現しているとかそうではないとからしいです。
つまりこの場合、1..*は1以上のオブジェクトを保持しているということを表しているという解釈で合っているのでしょうか？
C++等で実装する場合はvectorとかlistとかを使うという事だとは思いますが、よくわかりません。
汎化ボタンを選択後、クラスを選択することで汎化を定義できます。
この場合、クラス0は抽象的なスーパークラス、クラス2は具体的なサブクラスになるらしいです。
C++等で実装する場合はクラス2がクラス0を継承するという解釈でいいのですかね？
集約ボタンを選択後クラスを選択することで集約を定義できます。
この場合、クラス1はクラス4の一部になるとかならないとからしいです。
コンポジションボタンを選択後クラスを選択することでコンポジションを定義できます。
この場合もクラス1はクラス4の一部になるとからしいですけど、コンポジションの場合はクラス4(全体側)が終了するとクラス1(部分側)も終了します。
集約の場合はクラス4が終了してもクラス1は存在し続けるとからしいです。
依存ボタンを選択後、クラスを選択することで依存を定義できます。
この場合、クラス0がクラス1に依存しているということだとは思います。
関連との違いが今一わからないのですが、他のクラスの操作を呼び出す場合等に使うらしいです。
今日はこのぐらいにしておきます。
明日はパッケージ図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
astah* communityを起動して図→クラス図を選択してください。
とりあえず適当にクラスを追加してみます。
次に黄色のひし形のマークをクリックすると属性が追加されます。
また、クラスを選択して左下の操作ウィジェットからも追加できます。
追加した属性をクリックすると以下のウィジェットから設定できるようになると思うので、適当に設定してみます。
可視性は上の設定ウインドウではわかりやすいですが、クラス図では以下のように+がpublic、-がprivate、#がproctected、~がpackageとなるので覚えておきましょう。
正直よくわからないのですけど、以下のように接続することで関連を定義できるらしいです。
他のクラスの属性として保持するなり何らかのつながりさえあれば関連を定義できるということでしょうかね？
さらに以下のように多重度を設定すると、クラス0がクラス1を属性として保持する場合にクラス1のオブジェクトをいくつ保持できるかを表現しているとかそうではないとからしいです。
つまりこの場合、1..*は1以上のオブジェクトを保持しているということを表しているという解釈で合っているのでしょうか？
C++等で実装する場合はvectorとかlistとかを使うという事だとは思いますが、よくわかりません。
汎化ボタンを選択後、クラスを選択することで汎化を定義できます。
この場合、クラス0は抽象的なスーパークラス、クラス2は具体的なサブクラスになるらしいです。
C++等で実装する場合はクラス2がクラス0を継承するという解釈でいいのですかね？
集約ボタンを選択後クラスを選択することで集約を定義できます。
この場合、クラス1はクラス4の一部になるとかならないとからしいです。
コンポジションボタンを選択後クラスを選択することでコンポジションを定義できます。
この場合もクラス1はクラス4の一部になるとからしいですけど、コンポジションの場合はクラス4(全体側)が終了するとクラス1(部分側)も終了します。
集約の場合はクラス4が終了してもクラス1は存在し続けるとからしいです。
依存ボタンを選択後、クラスを選択することで依存を定義できます。
この場合、クラス0がクラス1に依存しているということだとは思います。
関連との違いが今一わからないのですが、他のクラスの操作を呼び出す場合等に使うらしいです。
今日はこのぐらいにしておきます。
明日はパッケージ図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
書くことないなあ。
仕方ないのでUMLの話でもします。
僕もよくわからないのでUMLとRTミドルウェアによるモデルベースロボットシステム開発を読みながら書きます。
まずは、このページからastah* communityをダウンロードしてください。
最初はアクティビティ図から作ってみます。
図→アクティビティ図を選択してください。
とりあえず使いそうな要素を並べてみました。
とりあえず、簡単なアクティビティ図を作ってみました。
開始後アクション1の処理を実行して終了します。
正直矢印の見ためが同じなので区別しづらいのですが、上の図のように矢印が処理の流れを表現する場合はコントロールフロー、以下のようにオブジェクトノードによりデータやオブジェクトをやり取りする場合はオブジェクトフローと呼ぶようです。
さらにピンを使用した場合もデータ等をやりとりするオブジェクトフローになります。
フォークノード、ジョインノードにより複数の処理への分岐、統合を記述できます。
この場合、アクション1の実行後、並列にアクション2、アクション3を実行、その後アクション4を実行します。
アクティビティ終了ノードとフロー終了ノードの違いが分かりづらいのですが、分岐した全てのフローが終了する場合はアクティビティ終了ノード、到達したフローのみが終了する場合はフロー終了ノードを使用するらしいです。
以下のようにまずフォークノードによりアクション3とアクション2にフローが分岐、アクション2を実行後デシジョンノードによりデシジョンノードによりアクティビティ終了ノードとフロー終了ノードに条件分岐する場合を考えてみます。
アクティビティ終了ノードに分岐した場合、アクション3に分岐したフローも含めて全てのフローが終了します。
一方フロー終了ノードに分岐した場合、アクション3に分岐したノードはそのまま処理が継続されます。
今日はこのぐらいにしておきます。
明日はクラス図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
仕方ないのでUMLの話でもします。
僕もよくわからないのでUMLとRTミドルウェアによるモデルベースロボットシステム開発を読みながら書きます。
まずは、このページからastah* communityをダウンロードしてください。
最初はアクティビティ図から作ってみます。
図→アクティビティ図を選択してください。
とりあえず使いそうな要素を並べてみました。
とりあえず、簡単なアクティビティ図を作ってみました。
開始後アクション1の処理を実行して終了します。
正直矢印の見ためが同じなので区別しづらいのですが、上の図のように矢印が処理の流れを表現する場合はコントロールフロー、以下のようにオブジェクトノードによりデータやオブジェクトをやり取りする場合はオブジェクトフローと呼ぶようです。
さらにピンを使用した場合もデータ等をやりとりするオブジェクトフローになります。
フォークノード、ジョインノードにより複数の処理への分岐、統合を記述できます。
この場合、アクション1の実行後、並列にアクション2、アクション3を実行、その後アクション4を実行します。
アクティビティ終了ノードとフロー終了ノードの違いが分かりづらいのですが、分岐した全てのフローが終了する場合はアクティビティ終了ノード、到達したフローのみが終了する場合はフロー終了ノードを使用するらしいです。
以下のようにまずフォークノードによりアクション3とアクション2にフローが分岐、アクション2を実行後デシジョンノードによりデシジョンノードによりアクティビティ終了ノードとフロー終了ノードに条件分岐する場合を考えてみます。
アクティビティ終了ノードに分岐した場合、アクション3に分岐したフローも含めて全てのフローが終了します。
一方フロー終了ノードに分岐した場合、アクション3に分岐したノードはそのまま処理が継続されます。
今日はこのぐらいにしておきます。
明日はクラス図をやります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
