goo blog サービス終了のお知らせ 

ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

他画面遷移抑止、トランザクショントークンより、Javascriptのほうが、早くね?

2009-06-25 15:21:49 | Weblog

 Webで2度押しとか、他のページに行かないようにする方法として

 Strutsの場合
   (1)トランザクショントークンを使う
   (2)(Strutsに限らないが)javascriptで対応する
       ・2度押し:ボタンをdisableにする
       ・他のページにいかないようにする:unloadで自分の画面以外に行かなくさせる

 の2種類の対応が考えられる。




■(1)の場合、
・actionクラスのexecuteメソッドにおいて、
  はじめに
saveToken(request);
  をしておくと、その後のJSPのhtml:formタグ内に、トランザクショントークンが
  書き込まれる。

  次の画面で、isTokenValid(request,true)すると、
     セッションにはいっている、トークンと、画面からきた(JSPで書き出した)
     トランザクショントークンと比較する。
   前の画面から直接来たのなら、セッションのものと一致するのでOK
   他の画面からくると、一致しないのでエラーになるというもの。




■(2)の場合、

 2度押し防止は、ボタンの.disabled = trueにして、ボタン自体を押せなくする。

 でも、これだと、ブラウザの「戻る」で戻すとき、前の画面に戻れてしまうので、
 それを抑止するため、

 Javascriptで、

<script type="text/javascript">
<!--
var i = 1;
function nextModoru()
{
	if ( i == 1)
	{
		alert("ほかの画面にはいけません");
		window.open("いまのページ","_top");
	}
}
function nextJump()
{
	i = 0;
	window.open("つぎに遷移するページ","_top");
}
//-->
</script>
</HEAD>
<BODY onunload="nextModoru()">
<INPUT TYPE="BUTTON" onClick="nextJump()" value="つぎへ">
 
(<>は、本当は半角)

 などとする。こうすると、読み込み時、i=1にセットされているため、
ボタンをクリックされて、nextJumpを使わないかぎり、i=0にならない。
つまり、ボタンを押さないで他の画面に行こうとすると、i=1のままで、
nextModoruが、遷移しようとしたときに実行され、
結果、今のページが再描画される。

 これ以外にも、locationをいじって、ダミー画面を入れるとか、
いろいろあるみたいだけど・・・




■問題は・・・

 Javascriptの場合、画面遷移しない。だから、問題ない。

 しかし、トランザクショントークンでやった場合、

 「ほかの画面からきました」
 「2度押しされました」

 というメッセージを出すのはいいんだけど、このあと、どこに遷移したら、いいんでしょうねえ・・

 2度押しされました。。。ってメッセージだして、
 前の画面にもどっても、いや、その画面押されてるわけで・・・

 みたいな・・・

 そんなこんなかんがえると、他画面遷移抑止、
 トランザクショントークンより、Javascriptのほうが、早くね?
(はやいかどうかっていう問題じゃないか・・・?)


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

UML等各種ダイアグラムのエラーチェック体系化(その7:UMLより最強のダイアグラム)

2009-06-25 12:19:08 | Weblog

シリーズ、 「UML等各種ダイアグラムのエラーチェック体系化」です。
 前回はダイアグラムを、

・後工程の入力になるために、前工程としては、どこまで記述しないといけないか?

 という基準で見た場合、UMLだと、データの部分で、この条件をみたしていないため、クラス図に行くところなどで、
 悪く言えば恣意性、よく言えば技術者の経験的勘がはいってしまうということを書きました。

 そして、こうならないための、史上最強ダイアグラムが存在すると・・・
 さらに、そのダイアグラムから、UMLの各ダイアグラム等は変形できると描きました。

 で、そのお話です。




■史上最強ダイアグラム=業務流れ図

 そのダイアグラムは、業務流れ図になります。

 業務流れ図の正確な書き方というのは、はっきりしない(基準がない)のですが、

 EAにおける、

業務流れ図(WFA)
http://www.meti.go.jp/policy/it_policy/ea/gainen/product/wfa/index.html


 や、

財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の設定について(意見書)」
http://www.fsa.go.jp/singi/singi_kigyou/tosin/20070215.pdf
(PDF)のPDFのページで100/129ページ
(下の真ん中ページ59、下右端ページ92)

などが、例としてあげられる。アクティビティ図にデータ部分、つまり
  入力画面+出力帳票・画面+入出力ファイル・DB
がかかれている。(なので、アクティビティ図に不足していた、データ部分が補強される)

 さらに、EAの場合、手作業部分も明示されているので、ユースケース図にも展開できる(手作業でないところ)




■ダイアグラムと開発の流れ

では、業務流れ図を中心とした開発の流れを書いてみよう。これが、前段階→後段階のようにつながればOK!

まず、業務流れ図には、担当者(アクティビティ図でいうスイムレーン、役割というべき?)に分けて書く。
この担当者は、その前の入力・・・というと組織図になってしまうが、組織にいない人(顧客)なども出てくるので、
まあ、用語定義というのを考え、

●用語定義に出てくる人が、担当者としよう。

●業務範囲を明確にするため、機能構成図(DMM)を書いているのであれば、業務流れ図の範囲は
 DMMとなってくる。

●で、業務流れ図に記載される業務に対して、画面入力、帳票出力するものが入出力となり、
 ここででてくる、画面、帳票に対して、画面定義書、帳票定義書ができないといけない。

●この画面定義書、帳票定義書の項目から、どの項目が保存する必要があるかを選び出し、
 それを正規化することにより、テーブル構造が出てくる=ER図が描ける

●このテーブル、ファイルと業務流れ図のテーブル出力などを矛盾がないか確認するわけだが、
 それは、「後工程の入力になるために、前工程としては、どこまで記述しないといけないか?」
 ではなく、矛盾チェックのほうになる。

●画面、帳票が出来たことにより、画面出力フレームワーク、帳票出力フレームワークによって
 クラスが決定する。

 画面出力をStrutsで行う場合、
  画面分、ActionFormができ、そのフィールドとメソッドは画面項目と、そのsetter,getter,resetとなる

  業務流れ図の各業務において、どこかの画面のボタンをクリック等して、イベントを発生させ、処理を
  開始する。この場合、Actionごとにクラスが発生する

  モデル部分は、この業務ごとにクラスにしてもいいし、テーブルごとにクラスをもち、そこに
  業務(メソッド)をはめ込むというというのでもいい。
  →これを、フレームワーク段階できめる。

 ということは、これらフレームワークの方針が決まると、クラスが決定するので、クラス図がかける。

●クラス図、テーブル、画面、帳票の定義が出来ると、javaのプログラムに落とせる。

と、こんな流れになる。




■ダイアグラムの関係

では、この業務流れ図から、ダイアグラムがどう抽出できるか。

●アクティビティ図
  データ部分を書かないと、アクティビティ図になる。

●ユースケース図
  アクティビティ図を基に作れる

●ER図
  上記で作っている

●クラス図
  上記で作っている

●DFD
  業務をプロセス、DB,ファイルをデータストア、
  画面入出力、帳票出力を外部として書き換える。
  (条件などは無視:条件のような順番をDFDでは記述しない)

なんてかんじで、抽出できてくる。




今日はここまで。




  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする