「Winny特別調査員」だって。。。

あ、ソフトの名前です。

ここのニュース

ファイル交換ソフトの利用履歴を調査するソフト「Winny特別調査員」
http://internet.watch.impress.co.jp/cda/news/2007/01/17/14478.html
によると（以下斜体は上記ニュースより引用）


ネットエージェントは17日、Winnyをはじめとするファイル交換ソフトの利用履歴やウイルス感染歴を調査するソフト「Winny特別調査員」を発売した。100ライセンス以上から販売し、ISOイメージもしくはCD-ROMで提供する。1ライセンスあたりの価格は、ISOイメージが200円、CD-ROMが700円。Windows Vista/XP/2000に対応する。

１００ライセンスから販売で、１ライセンス２００円ってことは、２万円からってことなのかな？

ま、それはさておき、その調査員の働きぶりは（＾－＾）

　Winny特別調査員は、フォレンジック技術を応用した検査により、Winnyなどのファイル交換ソフトを利用した最終日時を調査するソフト。情報漏洩の原因となっているAntinnyなどのウイルスに感染した履歴も検知可能だ。これにより、ファイル交換ソフトを使用しないという誓約書を交わした利用者が、その後ファイル交換ソフトを利用していないかを確認できるという。

だそうです。。

報告終わり！！

お祈りパンダに気をつけろ！そいつあーウィルスだ！

ここのニュース
お祈りパンダに要注意――McAfeeがウイルス警告
http://www.itmedia.co.jp/enterprise/articles/0701/18/news023.html
によると（以下斜体は上記ニュースより引用）

　お線香を捧げ持って両手を合わせるパンダのアイコンが自分のマシンに現れたら要注意――。セキュリティソフトメーカーのMcAfeeが、ウイルス関連でこんな注意を呼び掛けている。

　McAfeeによると、パンダが祈る姿のこのアイコンは、「W32/Fujacks」というウイルスのファイル。2006年11月以降、複数の亜種が出回っているという。


そこに、実際のアイコンのイメージがでてるけど。。

うーん。。。パンダといっても、かわいいものではなく、

「越後屋、お前も悪よのお。。。」

といいそうな、悪代官様みたいな、パンダ？です。
（って、どーいうたとえだ　＾＾；）

災害時のケータイ利用は、つながるの？衛星電話や衛星利用のCS波によるIPのほうが？

昨日のNHKスペシャル、
情報テクノロジーは命を救えるか
阪神・淡路大震災の教訓は、いま
http://www.nhk.or.jp/special/onair/070117.html
で、みてて、？？？と思ったことその２

---

ケータイを使って、災害の状況を集めたり、ネットを使ったりしているのですが、
そもそも、基地局のアンテナが壊れて使えないとか、
そーいうことは、ないんでしょうか（＾＾；）

それに、ケータイでみんながアクセスしたら、（＞＿＜！）
メールであっても、つながらなくなりそうな。。。
特に、写真をばんばん送ってしまうと。。

なんで、ケータイでどーのこーのというソリューションは、危険だと思うんですよ。

---

そーなってくると、やっぱ、電波かな。。
（あかり通信もありえるけど、今のところは電波かなと。。）

ひとつは、その番組でも取り上げられていた、広域無線LAN。
　ただ、建物が壊れた状態っていうと、平地から、壊れたビルを超えて。。なんていうと、まだまだ実験不足の気もするし。。そもそも、大丈夫？？っていうことになる。
　この辺の実験も必要ですよね。。

　もっとも、広域無線LANは、うまくいけば、災害時だけでなく、平時のときもつかえるので、移動図書館みたいに、移動してなんかしたいものにはいいかもお（＾＾）！
　それと、学校に張り巡らせば、電線がいらない。。とか。。

---

　そうなってくると、衛星電話？

　でも、それだと、今インターネットベースで作っているシステムはむだになっちゃいますよね。。

　っていうことは。。。

１．無線LANで、ローカルサーバーにデータを収集する。
　　→いま、ケータイ電話でやっているメールやネットでの情報収集は、
　　　このローカルサーバーで集めるようにする。　

２．１．のサーバーは、その内容をCS波をつかって、衛星に打ち上げる。。

３．人工衛星は、どっか被害のないサーバーにCS波で内容を落とす

４．３の波を受けたサーバーは、中継局になって、TCP／IPの線にながす。

たとえば、東京で被害が起こったら、人工衛星経由で、その内容を大阪大学あたりにおくって、大阪大学はその波を受信してインターネットに流すと。。そーいった、ローカル無線LAN＋CS波を使って、人工衛星を利用した中継が、必要と思うのであります！

---

　そのためには、人工衛星をじゃんじゃんあげる必要があります。
　大学でも最近は人工衛星が作れるみたいなので、じゃんじゃん、通信用衛星を挙げていただきましょう。

　そして、CS波の利用を普及するため、アマチュア無線家にどんどんCS波＋人工衛星とかEMEとかを利用させる必要があると思うのです。

　そのためには、ICOMで、CS波用トランシーバーを補助金を出して利用させ、アマチュア無線の人はCS波を使えば、電話代ただ！みたいな。。企業でもCS波を使って、人工衛星を使えば、ネット代ただ！とか。。そーいう施策が、必要だと思うのであります。

・・・って、必要かあ（＾＾；）
（軍事用にはいいかも、ローカルLAN+CS波で飛ばすサーバーって。。）

モデル部分のクラス作成について

　ＤＯＡやオブジェクト指向の図を業務をまとめたシートと、入出力についてまとめたシートをつかってつくるというシリーズの話の続きです。

---

現在
　ＤＯＡの
　　　・ＤＦＤ
　　　・ＥＲ図

　オブジェクト指向の
　　　・アクティビティ図
　　　・ユースケース図
　　　・ユースケースシナリオ

　については書いて、クラス図に関して、まず、フレームワークから作るという話を書きました。
　クラス図
　　　・フレームワークを決めないとかけないということで、はじめに、フレームワークのうち、入出力のフレームワークを決めるという話を書きました。

　今回は、そのつづきです。

---

■業務のシート中、入出力のクラスに目印つける

　フレームワークで、すでにクラスになってしまったところについて、子アクティビティのところに目印を付ける等して、どれが、子アクティビティになったかについて分かるようにします。

---

■シート中、残りの部分のクラス化
　で、そうすると、残りの計算部分、純粋なモデル部分だけが残ります。
　この部分を、どのようにクラスにするかは、アーキテクトの人の考え方次第になります。

　具体的に言うと、ここのシートの作業手順の場合、

１．郵便振替表示
２．入金待ち一覧表示

は、画面があります。

３．のチェックするのは、人間がチェックするので、プログラムは要りません。

そうすると、４の作業依頼書印刷待ちにするところだけがプログラムになりますが、

このとき、

（あ）．入金確認というクラスを発生させて、作業依頼書印刷待ちをメソッドにするか

（い）．入金確認というクラスは作らず、作業依頼書印刷待ちをクラスにするか

（う）．入金確認というクラスをつくり、画面のメソッドも作って
　　　　郵便振替表示
　　　　入金待ち一覧表示
　　　　作業依頼書印刷待ち
　　というメソッドにするか

（え）．入金確認というクラスをつくり、手作業部分のメソッドもつくって
　　　　郵便振替表示
　　　　入金待ち一覧表示
　　　　入金チェック
　　　　作業依頼書印刷待ち
　　というメソッドにするか

というのは、アーキテクトの判断、ないしは、決まりによることになります。
どれでも、可能です。

　ちなみに、（う）の画面表示の場合は、画面の値をクラス内部に保存するようなメソッドが入ります（メソッドに対するセッターになります）。

　で、（え）の入金チェックも、画面内容（チェックしたもの）を保存することになると思います。

　こういったクラスも作ることは可能で、とくに画面が分かれているような場合は、このようなクラスを発生させ、セッションに入れて管理するといったことがあります。（画面を書き換えられても、セッションを使ってデータ保持するため、データを保存するメソッドが必要になる）

---

　ということで、このシートだけでは、どのアクティビティがクラスやメソッドになるかは決められません。逆に言えば、その決まりを決めてしまえば、自動的にクラスやメソッドが生成できることに（理論上は）なります。

「情報システム・モデル取引・契約書」の中間のまとめが、経済産業省のHPで公開されてる

　経済産業省の「情報システムの信頼性向上のための取引慣行・契約に関する研究会」が現在、「情報システム・モデル取引・契約書」っていう、受託開発、保守・運用に関するモデル契約書を策定しようとしてますが、そこの中間報告のまとめが、経済産業省のホームページで公開されています。

ここ
「情報システムの信頼性向上のための取引慣行・契約に関する研究会」中間のまとめの公表について
http://www.meti.go.jp/press/20070116001/20070116001.html

そこに、発表資料名として、２つのPDFが出てますが、下のPDFが、具体的な中間のまとめの内容、すなわち、「情報システム・モデル取引・契約書」について書いたものです。

　ちなみに、上は、そういうのを作ったよって言うことと、文句あるやつは、意見をくれえ！っていうことが書いてあります。
　ちなみに、その意見の言い方にかんしては、パブリックコメントの以下のページ
「情報システムの信頼性向上のための取引慣行・契約に関する研究会」中間のまとめに関する意見募集
http://search.e-gov.go.jp/servlet/Public?CLASSNAME=Pcm1010&BID=595207004&OBJCD=&GROUP=
　にも載っているようです。

ほうこくおわり。

災害時、ケータイから情報集めても、不正確って。。個人画面用意して写真で送れば。。。

　昨日のNHKスペシャル、
情報テクノロジーは命を救えるか
阪神・淡路大震災の教訓は、いま
http://www.nhk.or.jp/special/onair/070117.html

みてて、？？？と思ったことがあったので、ちょっと書いて見ます。

---

その１つ。

住民からケータイをつかって、被害状況をあつめ、それを分析するっていう
話をやってました。

・初めに（災害に会う前に）個人で登録して、

・災害時、ケータイから、被害状況をメールで送る
　→メールなら回線が、電話より、まだ混まない

・で、そうすると、情報を全部送ってくれない人がいて。。云々。。

ってやってた。。

---

けど、メールだったら、メールアドレスがあるし、

もし、Webでやるなら
（サブスクライバIDをとるという手もあるけど、それだと、
非通知にされたら終わりだから）、
　・はじめに、メールで登録して、
　・そしたら、個人用のWebページを開くようにして
　　　　→http://abc.jp/top.cgi?id=12345　みたいなかんじ
　　　　　idは、１人1人、登録時に発行される
　・そのWebページから、情報を送るようにしてもらえば
　　　　→IDから、誰が送ったか特定できる

っていうことで、メールなら、メールアドレス、WebならIDなどで
個人は特定できるから、そこから、必要があれば、
メールで聞き返せるようにすれば（＾＾；）？？

　というか、個人レベルで聞き返したり、個人レベルで注意喚起とか
できたほうが、いいっすよね。

---

　あと、場所とか状況については、GPSつきで写真を撮ったほうがいいよね。
　ただ、これって、回線が混んでると、無駄なデータをつかう。。

　そーなってくると、エラーチェックなどもあわせて、ケータイのアプリで、
ある程度情報をチェックし、回線の混み具合などに応じて、テキストデータ
だけ送るか、写真つきにするか。。なんていう判断をした上で、送信する。。

　そんなアプリを作ったほうがいいってことになるかもしれないですね。

　って、そこまで、大掛かりにやるこたーない？？

---

　ただ、もともと、ケータイでやるって、問題あると思うんだけど、
そのことは、また、気が向いたとき書きます。