Ken-ichi HASHIMOTO
ken****@po*****
2002年 5月 24日 (金) 03:27:54 JST
橋本です。 On Fri, 24 May 2002 01:15:29 +0900 Takuro Ashie <ashie****@homa*****> さんは書きました: >足永です． >> 例: >> この特番、どうしてもとっておきたい。でもあと 1分で始まっちゃう >> じゃん。しかも、何でこんなときに限って、何か録画中だし。うがー。 >これに対応する為に、ビデオデッキで言う「クイック録画」みたいな概念があ >れば、全てが丸く収まるかな、と思っています．さらに「クイック録画」には >「強制録画」という概念があって、ユーザーがこれを指定した場合は、矛盾す >る「予約」はDBSによって順次削除(あるいは修正)されていく、という具合で >す．単純な「録画停止」や「録画修正」は「予約」を修正すればあとはDBSが >勝手に判断する、と． 僕も、「クイック録画」のようなユースケースを考えていました。 >「クイック録画」をユースケースにするとこんな感じ?(ド素人なので変な事やっ >てたらごめんなさい) そんなに変なことをやってることはないと思います。 Ruby で オブジェクト指向プログラムを書いている方でしたら、 そんな変なことはないと思いますが。 > ><追加ユースケース> > > ユーザ ---> クイック録画登録 --> DBS > > >また、ユーザーは緊急の録画を要する番組を一つだけ登録する事ができます． ><クイック録画登録> > >クイック録画登録には通常の番組登録に対する独自の概念として「強制録画」 >があります． > >ユーザーによって「強制録画」が指定された場合、DBSによって矛盾すると見 >なされた番組に対しては、DBSが自動的に「予約修正」あるいは「予約削除」 >を行います．「強制録画」が指定されなかった場合、DBSは通常の「番組」を >優先します． > >クイック録画登録において、ユーザーは最低限「チャンネル」と「録画開始時 >刻」と「強制録画を有効/無効」だけをを指定すれば、DBSによって自動的に >「番組」が生成されます． >「クイック録画登録」において、放送スケジュールは「一回」のみが許可され >ます． > ></追加ユースケース> 「クイック録画は最優先録画予約である」 「最優先予約は、どのような予約(既に録画が開始されている予約)よりも 最も優先される予約である」 といっているのですよね？ > >この場合、録画終了時刻はDBSによって適当に仮の値が与えられて、後で普通 >に予約修正を行う事によって変更できるという感じでしょうか． > >そして(今の段階で実装を云々しない方が良いかもしれませんが)実際に「矛盾 >する番組」が修正されるタイミングは、その番組の開始1分前とかそんな感じ >でしょうかね(クイック録画の終了時刻は仮の値なので、登録された段階では >まだ予約修正を行うべきではない) <実装の妄想> なんだかんだいって、予約DBSや録画部分など「システム」として 存在する部分があり、しかも各々のシステムはコミュニケーションを 行う状況になるような気がします。 この時、各システムは各々プロセスとして扱われる様に思えます。 こうなると、IPCやITC(プロセス間通信やスレッド間通信)の実装が大変に なってくるでしょう。 妄想なのですが、分散オブジェクト(ここでは druby)を導入してしまうと 以上のユースケースが、すんなり実装できるかもしれません。 分析段階で実装の話をするのはナンセンスなのですが、かといって全く しないと、机上の空論としかなってしまいません。 開発方法論の一つであるUP（統一プロセス）などでも分析段階で設計や 実装を含めても良い(コアテクノロジに関する実装など、キーテクノロジ) と言っているような気がするので、あまり殻に拘らず議論しましょう。 (でも、本題は分析段階です(^^;) </実装の妄想> >これをユースケースに含めるべきなのかどうかわかっていないので、とりあえ >ず別にしておきます． ユースケースが爆発的に増大すると、大変なのでこれを現在のユースケースに 入れるかどうかは、また議論しないといけませんね。 いれる事に越したことはない。積極的に反対する理由がないユースケースだと おもわれますので、却下とかいうわけではありません。 --- Ken-ichi HASHIMOTO E-Mail ken****@po*****
