平鍋さん、こんにちは。(返信お待ちしておりましたf(^o^;;)
赤坂です。
On Fri, 24 May 2002 09:56:02 +0900
Kenji Hiranabe <********@***.**.**> wrote:
> > # 平鍋さんの秘密と違ってませんか?
>
> えと，だいたいそんなところです．
ほっ、良かった(^o^)。
> が，機能切りだしのスタートポイントとしてのユースケースとの関
> 連について，とかいろいろあります．今，簡単な論考を書いていま
> すので，そのうち公開します．
それは楽しみです。
> ちなみに，コンテキスト図はコラボレーション図の一種です．シス
> テムを中心に，interface, sensor/actuator, perseption/action
> という3層オニオンスキンになります．
>
> system ... コンピュータシステム
> interface ... システムとの I/F．RS232C とか．
> sensor/actuator ... センサ・アクチュエータ．光センサーとか．
> action/perseption ... 人間が認識可能な物体．動作など．
>
> こんな感じです．(スライド1の右側)
なるほど。
> ppt
> http://with.esm.co.jp/UML-Model/TeamWithUMLRobotModel.files/frame.htm
>
> PDF
> http://with.esm.co.jp/UML-Model/TeamWithUMLRobotModel.pdf
何故か私のPCから拝見できませんでした(T_T)
「Cマガジン」(2002.6)の梅田さんが書かれた"「UMLロボットコンテスト」参戦
記"にある Context Diagram(fig.5 モデル p126)と同じものと考えてよいでしょ
うか?
ちなみに、弊社の水野さんが書いた"UML ロボットコンテスト参加レポート"にも
オニオンスキン(記事ではオニオンスライス)について簡単に触れています。
# (主ににレイヤ構造について)分析中に、議論になったものです。
http://www.ogis-ri.co.jp/otc/hiroba/Report/UML_Forum2002/robot/index.html
> 平鍋としては，組み込みではユースケースがうまく機能しない部分
> をこれで補おうとしています．
>
> 業務系のユースケースでは，action/perseption レベルのアクター
> しか出て来ないのに，組み込み系では，sensor/action レベルのア
> クターが出て来てしまうことに違和感を感じたことはありません
> か? これは，明らかにレベルが違うアクターなのですが，組み込み
> の特性として，OSやライブラリやハードの制約から，マルチレベル
> の実装が要求されることが多いので，自然とレベルを横断したオブ
> ジェクト抽出がされてしまうのです．コンテキスト図だと，これを
> うまく層で分離できます．
アクターの違和感は感じますね。
何をアクターにすべきかということは、よく議論されますしね。
コンテキスト図において、システム境界を内側(システムそのもの)と外側だけに
縛るだけでなく、外側にいくつか層を設けることで分かりやすくなる訳ですね。
私達がよく使う方法としては、
最初は(外部仕様的には)action/perseptionレベルのアクターだけにしておき、
必要であれば、分析で内部アクターとしてsensor/actuatorレベルのアクターを
出したりしていますね。
前者は一般的なユースケース、後者は開発者用の詳細ユースケースといった
ところでしょうか。
> 今考えているのは，System と Interface の境界を鏡にして，シス
> テムの外部が，System の内部に「映り込む」という構造です．
> Context Diagram でうまく外界とシステムのおかれた状況を把握
> できれば，それを System の内部に鏡像としてオブジェクト化して
> いくことで分析が可能です．
これはとても良いアイディアですね。
私達が使う方法では、平鍋さんのような分かりやすいアイディアではありません
が、結果的に、アーキテクチャのレイヤ(ラッパ(=interface)、ハードウェア
(=sensor/actuator))として映りこんでいるという感じなのでしょうかね。
# でも、やっぱり始めにこれを意識していることが重要だと思います。
P.S.
平鍋さんの"玉ねぎの皮"の名称はなかなか良いですね。
特にsensor/actuatorの響きはとても直感的で好きです!!
ですが、重箱の隅を突付くようで申し訳ないのですが…、
組込みではメカ制御の他にもメモリデバイスだとかも扱いますよね。
例えばEEPROMに設定情報を保持しておくだとか…。
この場合、EEPROMクラス(デバイスドライバ)は、
広義にはsensor and acutuator と云って構わないのでしょうが、
deviceといった方がEEPROMクラスには居心地良さそうです。
# 私的には、device(sensor/actuator) に一票! (^o^;;
# hardwareでも良いですが、ぼやけますね(^^;;
--
赤坂 英彦 (Hidehiko AKASAKA)
*******@***.*******.**.**