会社が個人PCを調査することに同意しますか?

というスラッシュドットの記事があります。
会社が個人PCを調査することに同意しますか?
http://slashdot.jp/askslashdot/07/04/16/2313241.shtml

それによると（以下斜体は上記サイトより引用）


　情報漏洩問題を受けて、勤め先の会社が、個人が所有しているパソコンを第三者の立会いで調査することになりました。詳細は伏せますが、大体の経緯は次の通りです。
情報漏洩が発生(ニュースにもなりました)。原因は、業務ファイルを持ち帰ってウィルス感染した自宅PC上で仕事したため。流出させた方は懲戒免職。第二の情報漏洩を起こさないため、社員の自宅PCを第三者の立会いで調査するとの指示。調査内容は、業務ファイルが無いことと、会社で禁止しているソフトが使われていないかを確認するとのことでした。


（注意：引用文そのままなので、勤め先＝この記事を投稿した人の勤め先のことで、ウィリアムのいたずらのお仕事もらっている先ではない。
　っていうか、ウィリアムのいたずら、そもそも勤め人じゃないし　（＾＾；）


これの是非、法的にどうかはともかく。。
ウィリアムのいたずらがこの記事を見て思ったのは、以下の３点

■（１）あまり意味のない調査では？
　だって、いますぐに！じゃなかったら、
　バックアップして、フォーマットしなおしたあとに、テキトーに安全そうな
　ファイルをもどしておいたら。。。

　それに、パソコン何台も持っている人は隠しちゃうだろうし。。
　危ない人は、会社やめちゃったり、
　派遣の人とかは、もうやめてるかもしれない。
　派遣でやめた人まで調べるのは、たいへんなんじゃあ。。

■（２）ところで、会社の「調査する人の情報漏えい」は？

　えー、社員が情報漏えいするような会社では、調査をする人自体も情報漏えいさせちゃうかもしれません。そーすると、

　●●さんは、こーんなファイルをもってたんですよおー（＾＾）ｖ

　と、会社中にメールしたりするかもしれない。

　このとき、「こーんなファイル」に該当するファイルは、
　・会社にとっては、どーでもいいファイル
　・でも、そのファイルを持っていることを知られるのは、●●さんにとっては
　　まずいファイル
　だったら。。

■（３）PCじゃなく、人で漏洩した場合は。。
　パソコンから漏洩したのなら、パソコンを調査すればいいから簡単ですが
　これが、愛人から漏洩したとか言うことになったら、この会社はどーするのでしょうか？
　えー、まず女性関係を調べて。。
　そのあと、どのように調査するんだ（＾＾；）

開発の初めから順番に書いていってみる その３０：外部設計（７）画面・帳票設計

シリーズ「開発の初めから順番に書いていってみる」の続きです。
　今、外部設計の段階で、要求仕様から、詳細設計までの間（ここを外部設計と、ここでは読んでいるわけですが）の手順は、以下の手順で行うと、流れに飛躍がなく説明がつくということを書きました。

（１）入出力の媒体をきめる。
（２）その媒体ごとにフレームワークを決定する。
　　　なければ、入出力方法を決定する。
（３）そのプロセスの起動方法を考える
　　　なければ、起動モジュールを考える。
（４）起動モジュールから、（２）の呼出し手順を考える
（５）その処理部分をどうするか、考える。
（６）そうすると、細分化された入出力、処理部分ができる。
　　　ここで、あわせたいものは、あわせる
（７）処理部分を、ワーカーさんに渡せるまで落とし込む。

だけど、実際にやられるのは、こんなかんじだと書きました。

（あ）フレームワークの確認から、全体的なプログラムの書き方を決める
（い）画面の設計をする
（う）ＤＢの設計をする、（その他外部の設計をする）
（え）プログラムを適当に詳細化し、詳細設計に持っていく

　で、昨日、（あ）を書いたので、今日は「（い）画面の設計をする」です。

---

■画面と帳票の設計について

　フレームワークが決まったら、システム入出力ということで、まずは、画面と帳票の設計になります。

　設計しなくてはいけないことは、以下のことです

・画面遷移
　　→どの画面をはじめにだして、そのあと何が起こったら、どの画面を出すか

・各画面／帳票の設計
　　・画面レイアウト
　　・画面項目の内容、入力範囲や型について
　　・画面の場合、カーソルの飛ぶ順序
　　・帳票の場合、コントロールブレーク（書き出す内容が変わるところ、合計行など）

---

■手順

　まず、この前の「（あ）フレームワークの確認」によって、画面／帳票のプログラムの作り方と、ルックアンドフィール（みてくれ）は決まっていることになります。

　要求分析などから、画面と帳票の出力項目は決まっているはずです。
　ということで、

（１）画面入力項目の確認
　　DFDにまとめている場合、入力項目は決まっていると思うけど、そうでない場合
　　まあ、確認しておく

（２）複数プロセスを１画面にまとめる
　画面は、１画面で何個ものアクション（＝ボタン）をいれることができます。
　たとえば、削除、更新、追加は、３つの別々のアクション（プロセス）ですが、１つのアクションにまとめられます。そこで、これら別々のアクションを１つにまとめます。
　まとめる基準は。。。クラスを基準に考える（受注クラスに属するイベントツーかメソッドをまとめて受注画面にするとか）っていうのもありですけど。。
　操作しやすい順とか、恣意的に決めてると思います。

（３）各画面の遷移を考える
　１画面の内容がきまったら、じゃあ、どの画面の次に、どの画面がきて。。という画面遷移を決めます。メニュー画面が必要になってくることがあるので、その場合は作ります。

　遷移手順は。。かりに（２）でクラスごとにまとめたのなら、親クラスから子クラスへ遷移するようにするという手はあります。
　ただ、たぶん、（２）は、恣意的に決めたと思うので、その場合は、ここも恣意的に決めるしかないですね。

（４）画面レイアウトと項目をまじめにきめる
　で、（２）で大まかに項目とか決めているとおもうので、ここでまじめに、各画面の項目を決めたりします。値の範囲も決めたりします。
（３）のまえに、これをやる（つまり、画面を項目まできっちりきめてから遷移にかかる）でももちろんOKです。


てなかんじで、画面とその遷移が決まると思います。

---

■画面定義書にまとめる

　で、この内容は画面定義書にまとめます。画面定義書は、画面遷移図と各画面の内容からなり、各画面の内容は、画面のようす（レイアウト）と各項目の説明からなります。

　各項目の説明には、項目名と内容のほか、型というか、何を使って実現するかというのもかきます。カーソルの飛ぶ順序も、デフォルト設定でないものなら、分かるようにしないといけません（デフォルトの飛び方ならわざわざ書かなくてもOK)。

　そして、ボタンの場合、どのようなアクションが起きるかまで書くと思います。

---

■画面は変更が多い

　ただ、画面は一生懸命きめて、さあ、取り掛かろうってとりかかって、早く終わらせても、変更が結構あります。仕様変更になると、入出力が動くことが多いので、そうすると、画面に影響が。。出やすいってことです。

---

■ここに力点を置きすぎないこと

　なもんで、画面は軽くながして設計するべきです。

　画面はユーザーも口出ししやすいので、ここに力を入れすぎてしまう場合がありますが、そうすると、なかなか画面は決まらないで、先進んでないのに、仕事した気になってしまいます。

　こーなってくると、フレームワークでできないようなユーザーインターフェースを考え出したりします。

　しかし、ものすごいユーザーインターフェースを作るって事は、開発工数とリスクを上げるだけです（開発の本質ではないことが多いです）。

　なので、ここに力点を置きすぎるのは考え物だと思います。

---

■「もう画面を決めてしまって、ユーザーを納得させる」
　とSEが言ったら、そのSE自体を信用しないこと

　あと、大事なこと”「もう画面を決めてしまって、ユーザーを納得させる」”
　といったら、そのSEは、システムの作り方がわかっていないので、そのSE自体を信用しないほうが身のためです。信用したら殺されます。

　画面は、プロセスが決まらない限り、動きます。なぜなら、プロセスが決まらないということは入出力が決まらないということであり、入出力が決まらないなら、画面も決まりっこありません。
　画面を決めるためには、プロセスを決めないといけません。なので、画面だけ先に決めるということはありえません。
　この場合、普通は、画面を自動生成する装置を作って、画面が変更されても、簡単に（できれば自動的に）生成できるようにしておくのが、まあ、危なくない対応です。

　ってことがわかってないSEは、プロセスを決めなきゃ！ってことをわかってないので、まず、決めようとしても、結局決まりません。なので、はなから、そんなことを言う人を信用しないで、自動生成プログラムを作っておいたほうが、身のためです。でないと、「やっぱきまんない」で、どんどん先にいき、あとで忙殺されますよ。

---

　ってなことが、画面と帳票の話題ですかね。。
　じゃ、次回はDBの話です。

Perlでセッションを使う その１：クッキーを利用（セッションIDを入れる）。

　Perlでセッションを使うのにCGI::Sessionを使うって、えらい昔に書いておいて、そのまんまだった気がするので、今日は、実際に、CGI::Sessionを使って、Perlでセッションを使ってみたいと思います。

　っていっても、２とおりあって、セッションIDをCookieに入れてしまうのと、そうでない方法（POSTやGetで引数として渡すなどなど）があるのですが、今回は、CookieにセッションIDを入れる方法をやって、次回、その２で、そうでない方法のほうをやりたいと思います。

---

■１：CGI::Sessionを入手する

CPANのここ
http://search.cpan.org/~markstos/CGI-Session-4.20/lib/CGI/Session.pm
にいくと、CGI-Session-4.20があって、右よこに、
Download: CGI-Session-4.20.tar.gz
ってかいてあるので、そこをクリック。

　適当な解凍ソフトを使って解凍すると、libのなかにCGIがあって、その中にSession.pmというファイルとSessionフォルダがある。
　そこでそれを、perlの入っているフォルダのlibがあるフォルダに入れるんだけど、
　すでにCGIっていうフォルダがあれば(CGIをperlで組んでいれば、たいていある）、そのCGIの下に解凍したSession.pmというファイルとSessionフォルダを入れる。
（なきゃ作る。。。より、CGIを入れたほうがいいと思う　＾＾；）


　本当は、もっとかんかんにインストールする方法があるんだろうけど、ま、これでできるからいいか（＾＾；）
　もっと、ちゃんとした方法を知ってる人は、その方法でやって、とにかく、CGI::Sessionを落としてきてくださいませ。。

---

■今回の課題

　で、こんなものをつくります。
　ブラウザからアクセスすると。。

　１行目に、セッションIDを表示し、

　２行目に、アクセスするたびごとに１あがる
　しかし、１０になるとセッション自体を削除する
　　　＝＞セッションIDがかわり、また１から。。
　となる。

　３行目は、とびとびに１が出たり出なかったりする
　（１をセッションにセット、次クリックされると、
　　セッションのその項目をクリアするので、飛び飛びに出る）

　というものをつくります

---

■ソース

　今回、

　１行目のセッションIDは$sidに、
　２行目の１０までの数字は、$kaisu_valに、
　３行目のとびとびの数字は、$tobitobiに

　入れています。

　で、以下ソースです。

#!C:/Perl/bin/perl
#################################################
#					  #
#	セッションのテスト			  #
#	Cookieを利用する場合		  #
#					  #
#################################################

use CGI;
use CGI::Session;

				#################################
				#	セッション開始	     #
				#################################
$cgi = new CGI;
$session = new CGI::Session("driver:File", $cgi, {Directory=＞'./session'});

#Cookieを使うため、ヘッダーをここで受け取っておく、
#（操作中にsessionを削除するのでここで受け取る）
$header	= $session-＞header();

				#################################
				#	セッションの操作	    #
				#################################
#セッションIDを受け取ってみる
$sid =  $session-＞id();

#kaisuから値を取得、１足して
$kaisu_val = $session-＞param("kaisu");
$kaisu_val++;

#１０まできたら、このセッションを消す。１０未満なら追加
if ( $kaisu_val	==	10 )
{
	$session-＞delete();
}
else
{
	$session-＞param("kaisu",$kaisu_val);
}

#偶数ならtobitobiセット、奇数なら、この項目（のみ）削除
$tobitobi = $session-＞param("tobitobi");
if ( $kaisu_val %2	==	0 )
{
	$tobitobi = $session-＞param("tobitobi",1);
}
else
{
	$tobitobi = $session-＞clear("tobitobi");
}


				#################################
				#	出力		    #
				#################################
#うけとったヘッダーを書き出す。
#普通、print "Content-Type: text/html￥n￥n";と書くが、その代わり。
#Cookie部分に、セッションIDが入ってるところが違う

print $header;

#　あとは、内容を好き勝手に書く
print "$sid￥n";
print "$kaisu_val￥n";
print "$tobitobi￥n";

（上記　＜　＞　￥　は、本当は半角です
　Windows上で、ActivePerlを使ってCGIをやってます）