netail.net

_ The Darwin Award ▲

リアルタイム UML 第２版 p.270 に記載されている「自動車が時速300参る（時速480km程度）で走行することはありません．[注６]」のネタの出所をつい調べてしまった．

http://www.darwinawards.com/darwin/index_darwin1994.html

_ 読書 ▲

研究室に置いてあった「リアルタイムUML第２版」（翔泳社）を読んでみた．ちなみに原著は：Real-Time UML, Second EditionDeveloping Efficient Objects for Embedded Systems.

リアルタイムシステムだから，何か特別なことでも入るかと思ったら，意外とそうでもなかった．（実時間に関する情報が UML 上に埋め込まれているくらいか）

とりあえず，何となく忘れそうになってたことをいくつか再確認．

• オブジェクトのクラスがオブジェクトの債務を規定できるのは，それらのオブジェクトがすべて同じコンテキストで同じように使われる場合のみ
• ひとつのオブジェクトが複数のインタフェースを備えることもある（ソースコード上では区別は付かない場合もあるかもしれないが）……実は自動で分割できると嬉しいかな．嬉しくないかな．
• アクティブオブジェクトとパッシブオブジェクトアクティブなほうは，自律的でイベントを発生させたり，システムの全体を構成する役割を持つパッシブのほうは，クライアントにサービスを提供する
• オブジェクトは債務を果たさなくてはならない．そのために必要な情報を持たなくてはならない．
• 継承による拡張と特化 拡張 = 新しい振る舞いを追加する 特化 = 親クラスの振る舞いを置き換える（ただし Liskov の置換原理は守る）
• アーキテクチャ設計とは，システムを構成するための戦略の決定．たとえばオブジェクトをレイヤ形式で配置するとか，オブジェクト間の接続をオブジェクトブローカーに任せるとか．
• メカニズム設計：コラボレーション（一連の協調動作を行うオブジェクト群）の設計．ただし，同じロールを担当する交換可能なクラスが複数存在するとき，それはパターンとなる．少数のスコープに限定されたパターンをメカニズムと呼ぶ．メカニズム設計として，オブジェクトがどのように協調するかを決定する．
• 詳細設計：データ構造の決定，精度や値域の確定，アルゴリズムの決定．関連，操作，可視性の決定，例外の決定（誰が送出し，誰が捕捉するか）．

_ Calendar ▲

hyCalendar の次の改造をそろそろ開始する．

くらいか．どうしようかな？

_ 日記CGI ▲

ヘッダコメントが無駄に長いので削った．もうちょいレイアウトは気を使ったほうがいいかもしれないが．