UML等各種ダイアグラムのエラーチェック体系化（その９：どんなダイアグラムもＲＤＢに！概略）

　シリーズ、 「UML等各種ダイアグラムのエラーチェック体系化」です。
　前回開発における一貫性チェックをするには、

・あるダイアグラムを書く工程において、必要なデータがそれまでの工程でダイアグラム等で明記されているか

　を調べるってことで、それをするには、

・すべてのダイアグラムをRDBに入れます。
・必要なデータがそろっているかSQLで検索をかけます。

　っていう形で調べようという話を書きました。

今回はその、「すべてのダイアグラムをRDBに入れ」る方法です。

---

■すべてのダイアグラムをRDBに入れる方法概要

その方法は、こんなかんじ。

・すべてのダイアグラムの構成要素を
　　ノード
　　リレーション
　　属性値
　にわけ、属性値の種別を属性とします。

・ノード、リレーションをある法則に従い、ＲＤＢのテーブルにいれます。

もうちょっと詳しく書きます。

---

■すべてのダイアグラムの構成要素をわける。

　ダイアグラム中、単独で存在しても意味をなす、ダイアグラムの構成要素を「ノード」とします。

　たとえば、
　　　・ＤＦＤのプロセス
　　　・ＥＲ図のエンティティ
　　　・アクティビティ図のスイムレーン、アクティビティ
　　　・ユースケース図のユースケースとアクター
　　　・クラス図のクラス
　　　　　：
　などです。

　一方、たとえば、ＥＲ図において、エンティティとエンティティの間に引かれる線（リレーション）は、エンティティ＝ノードが存在しないと意味を成さないです（記述することが出来ないです）。
　このように、２つ以上のノードとノードを結び付けているものを、リレーションと呼びます。
　ＤＦＤのデータフローなども、そうです。

　一方、流れ図における、注釈のような、あるノードに対して、説明するために、線を引っ張って書かれるものがあります。
　これは、属性値です。
　また、属性値は、ノードやリレーション上、あるいは、上や横などにかかれます。
　全部属性値です。

　だから、
　　　・ＤＦＤのプロセス名（プロセスのところに書かれているもの）
　　　・ＤＦＤのデータフローの上に書かれるデータについて
　　　・アクティビティ図のアクティビティにかかれる言葉（アクティビティ名？）
　　　・ユースケース図のユースケース名、アクター名
　　　・クラス図のクラス名、属性名、メソッド名
　ぜーんぶ、属性値です。

　で、属性値は、意味があります。たとえば、ＤＦＤのプロセスに「受注」とかかれていれば、プロセス名、
　クラス図で、
　getGas();
setGas();
run();
　などと書かれていれば、メソッド名など。。。

　このような、属性値の意味を、属性とよびます。
　上記（属性：）メソッド名のようにある属性がいくつかの属性値を持つこともあります。

　ここまでをまとめると、こんなかんじ。

・ダイアグラムの構成要素において
　　　単独で意味をなす存在＝ノード
　　　単独では意味はないが、２つ以上のノードを結びつける＝リレーション
　　　　　　　　　　あるノード等に結びついている（説明など）＝属性値→（性質、種別）属性
　　　　　　　　　　どこにも結びつかない、意味はない：飾り（保存しない）

※飾りは、位置関係などを示します（例：楽譜の５線）

---

■ノード、リレーションをある法則に従い、ＲＤＢのテーブルにいれます

原則
・ノードをテーブルとし、そのノードの属性がカラムになります。
・リレーションをテーブルとし、リレーションの属性がカラムになるほか、
　　　リレーションに結びついている、２つのノードもカラムにします
　　　→３つ以上結びついている場合、２つに分解します。

このほか、細則、例外があります。

---

ってなかんじで、ＲＤＢに入れていきます。
次回は、「すべてのダイアグラムの構成要素をわける」をもう少し細かく。

モデルのJavabeanを、こう書いたら、完全独立、モデル処理以外自動化できる気が・・・

　ちょっとメモメモ
　たとえば、Strutsで（いや、JSPでもいいんだけどね）、こうやって書いたら、

・Javabeanのビジネス記述以外を自動化できて（＝追加仕様でも自動化できる）
・ビジネス内容が明確に出来る

んじゃね？というのを思いついたので、かいてみる。

---

■JavaBeanの構造
　画面自体が１ビジネスロジックを示し、そこで、１画面、１モデル（１Ｂｅａｎ）を作成すると考える。

　そこで、Javabeanを以下のように作る

class 画面名bean{

	/*
	 *　フィールド
	 */
	//入力項目を列挙する＝ActionFormのフィールド全部書く
	private String para1;

	//その画面の出力項目をすべて書く
	private String outpara1;
	//ただし、表形式になっているところは、レコードを別beanにする
	private Rec1[] data1;    //  Recが別bean


	//　次画面のBeanを列挙する
	private 次画面１名bean outbean1;
	private 次画面２名bean outbean2;


	//　遷移する次画面
	private String next;

	/*
	 *　メソッド
	 */

	//　上記フィールドのsetter,getter
	public String getPara1()
	{
       		return para1;
	}

	public void setParam(String para1)
	{
        	this.para1 = para1;
	}

	//     :
	//    以下省略
	//  　  ：

	//   実行部分
	public void execute()	
	{
	　　　//ここに処理を書く
	}

}

---

■こうすると

このJavaBeanは、画面定義書と画面遷移がわかれば、自動的に作れる。(executeの中身以外）

　　・画面名は画面定義書にかいてあるはず
　　・はじめの入力項目のフィールド名は画面定義書にかいてあるはず
　　・出力項目のフィールド名は画面定義書にかいてあるはず
　　・テーブル形式になっているところは、Rec1とかテキトーに名前をつけておいてbeanにする
　　　→そのレコードの項目内容は、画面定義書にかいてあるはず
　　・次画面名は画面遷移図にどの画面に遷移する可能性があるか書いてあり、
　　　遷移先画面の画面名は、画面定義書にかいてあるはず
　　・最後に次画面遷移　private String next;　（固定）

　　・上記のフィールド部分をもとに、getter,setterは自動的に作れるでしょ。
　　・最後に、public void execute()メソッド（固定）

（っていうか、こーいう自動化が出来るような画面定義書、画面遷移図を書くのかな？）

で、このあと、Strutsで考えると、ActionとactionFormが必要だけど・・・

---

■そうすると、Actionは
そうすると、仮にＳｔｒｕｔｓだとしたら、Ａｃｔｉｏｎで、こんな感じで書く

（１）画面のActionFormをformとかの変数に入れる
（２）セッションから、画面のJavabeanを取ってくる（後述※するが、画面名beanで取ってくると、取ってこれるはず）
　なかったらnewで作成する
（３）画面の入力項目に関して

　　　画面のjavabean.set項目名(form.get項目名());

　をずらーっと書いていく

（４）そしたら、画面のjavabean.execute
　　→ここで、次画面に何を出すかのnextと、次画面のjababeanの値をセットする

（５）セッションに次画面のJavabeanセット
　　　　session.setAttribute("次画面名bean",画面のjavabean.get次画面bean名());

（６）次画面nextをセーブ
　　　　String next = 画面のjavabean.getNext();

（７）セッションから、画面のjavabeanをリムーブする（消す）

（８）return(（６）のnextで、次画面を指定する）


これも、画面定義書があれば自動化できる。つまり、人の手を入れることがないので、
項目追加、削除修正の際は、全部作り直しでＯＫ

※（５）で、次画面の内容をセッションに入れている。
　　そこで、次画面に遷移し、ボタンがクリックされ、次画面のアクションが走ったとき、
　（２）の内容は、セッションに（次）画面名beanで入っている。。はず！

---

■他のものに関して

・ActionFormは、画面定義書の入力項目でＯＫ

・画面JSPは、bean:writeで書くけど、この内容は、前画面の（５）で、次画面名bean
　でセットされているので、セッションからこのbeanを取ってきて出力する。
　→この辺の項目名などは、画面定義書に書いてあるはず
　→もし、入出力項目があれば、セッションの内容から、ActionFormのresetでセットするのかな？

・struts-config.xmlは、いつもどおり、form-beanとactionを定義すればよい。
　actionのforwardが、nextで設定する次画面の値になる。

　ってことで、自動化できる。

---

■あとは・・・

　画面のjavabeanのexecute部分を記述すればいい。

　このとき、書くべき内容は、入力項目、出力項目をもとに、
　　・次画面（next）に、どの画面に行くかセットして
　　・次画面のbeanの出力項目に値をセットする
　と、明確にできる。また、javabeanは、項目追加、削除されたとしても、execute以外に手を入れないので、
　追加、削除された場合は、新規にjavabeanを作り直し、その後、execute部分を前のものに書き換え（＝上書き）すればＯＫ
　また、executeを完成させる前に、ダミーで値を入れてダミーモジュールとして画面周りのチェックもできるし、
　逆に、このＢｅａｎだけを取り出してＪＵＮＩＴにかけることも出来る。
　さらに、適当にドライバを書けば、Ｂｅａｎだけ使って（画面ナシで）、前画面、次画面、その次と、結合チェックしていくこともできる。
　（Ｂｅａｎに入出力画面項目のデータをすべて持つので）

　セッションに入れるところは、カオル姫方式なのであって、カオル姫方式の変形かな？

動画見放題が増えると、クラウド的発想で、違法コピーが減る？

■動画見放題という枠組み

　従来、動画などのコンテンツというのは、コンテンツごとに買って所有する
というモデルが中心だったわけです。
　そのため、違法コピー（＝お金を払っていないで所有してしまう）という問題
が出てきたわけです。

　でも、最近、ＢｅｅＴＶのように、一定金額を支払うと、そこにあるコンテンツ
は見放題というものが出てきました。この場合、この一定金額のお金を支払って
しまえば、いつでもどこでも何回でもそのコンテンツを見ることが出来ます。
　何度見ても、定額です。

　そうなってくると、所有している意味って、なくなってきます。
　見たいときには、いつでも見れるし、何度見ても、定額料金なので。
　そして、そこまでくると、わざわざ、違法コピーをする必要がなくなってくる
わけです。

---

■クラウド的発想をすると、所有の意味はない

　さらに、自分が所有する必要ないなら、いつでも見えさえすれば、だれが、どこに
持っていても関係ないわけです。どこの誰かは知らないけれど、誰もがみんな知っている
サイトにアクセスすれば、好きなコンテンツがいくらでも見れる・・・
　まさに、クラウドです。

　このようなクラウド的発想でコンテンツを提供すると、所有する意義がなくなってきます。
　違法コピーの意義もなくなります。

　そして、Bee TVなどは、この流れといえます。

---

■ビジネスモデルの変化で、違法コピーの問題は変わってくるかも？

　このような、一定料金支払い、見放題という枠組みが定着してくると、違法コピーなどの
意味がなくなってくるので、問題は、なくなってくるかもしれません。

　つまり、ビジネスモデルの変化で、違法コピーの問題は変わってくるかも？ということです。

どのような指示なら動けるのか？

　ダイアグラムの一貫性の検証の応用。
　ことばと業務流れ図、ＵＭＬ、ユースケースシナリオの関係で５Ｗ１Ｈがそろうことが、業務を表現するには必要ということを書いた。

　では、一般論として（つまり、コンピューターの命令とかではなく、一般社会において）、 どのような指示なら、部下とか、生徒とかが動けるのか？（上司を動かすとなると、話が違ってくるので・・・）

---

　ここで、検証方法の話を持ってくると、ここで示したとおり、

入力時：入力時矛盾チェック
　　　　　＝入力データが前工程で作成されていて、利用可能になっているか

　　↓

処理　：検証
　　　　　＝入力データと出力データの変換の妥当性、正当性

　　↓

出力時：成果物矛盾チェック
　　　　　＝作成した成果物が、他の成果物の記述と矛盾してないかどうか

ということになる。これを、一般社会に直すと

その業務をする前に・・・
　　その前提となる事柄がすべて完了して、必要な材料・情報が入手できること

その業務をするにあたって、
　　その材料・情報を、どのように処理・加工すれば、成果物が得られるかわかっている

業務完遂後
　　その成果物の品質が妥当か判断でき、他の成果物間と矛盾がないこと

ということになる。

---

まとめると、ある業務を指示したら、完遂できるためには、

・業務内容の５Ｗ１Ｈをはっきりさせる
・業務の前提となる事柄がすべて完了して、必要な材料・情報が入手できること
・業務をするにあたって、どのように処理・加工すれば、成果物が得られるかわかっている
・成果物が明確で、品質が妥当か判断でき、他の成果物間と矛盾がないこと

といったことが必要であるといえる。

コンピューター言語の教え方

　ちょっと、きょう、おもしろい話になったので、メモメモ。

　Javaでも、Cでも、なんでもいいんだけど・・・

　言語の教え方っていうのは、２とおりある。

　今、市販されている言語本の主流のおしえかた（たとえば、高橋麻奈さんのやさしいシリーズなど）は、言語を、

どんな言語でも共通な部分
　・書式（基本的な言語の書き方）
　・定数
　・変数
　・処理
　　　順次処理
　　　　　演算子
　　　　　代表的命令
　　　制御文
　　　　　条件分（IF,SWITCH)
　　　　　繰り返し（For、While）

共通でない部分
　Cならポインタ
　Javaならオブジェクト指向

ってなかんじで教えていく。

---

　で、ある人いわく、「この教え方、ひとつもおもしろくないんじゃないか？」と・・・

　その人の教え方。

　処理をブロックで捉えると・・・

　そして、簡単なブロックをまず、プログラムにして、練習

　つぎに、ブロックを連結させて、それをプログラムにして、練習

　そのあと、条件ブロックを連結させて、それをプログラムにして、練習

　最後に、繰り返しブロックを連結させて、それをプログラムにして、練習

こうすると、毎回いろんなことができて、楽しいし、なんで、こーいうことをやるかがわかって、いいんじゃないかと・・・

　いきなり、定数、変数じゃ、なんのためにやるか、わかんないので、おもしろくないので、勉強する意欲も出ないし、応用利かないよと・・・

　うーん、たしかにそうかもしれん。。。

　ちなみに、そーなってくると、まず、処理ブロックということを意識させないといけないので、流れ図から入るのかな・・っていうような話にもなった。

---

　教育的にも、「たしかに」と思う話なんだけど、実はこの話、あとで、とんでもないところにつながるかもしれないので、ちょっと書いてみた。

人間＋ロボットのシステムは、バイオフィードバックが必要なんじゃない？

　このまえの夢の扉の話のつづき

　先天的に手がない子がピアノが両手で弾けるようにと、ハイテク義手（ロボットの義手）をつくる話だったんだけど、それを作り上げて、子供が動かしたら、筋電位が低くて、動かない。

　で、先生がいきなり、「失敗です」って言いだっしゃうんだけど・・・

　おーい、先生、そりゃ、むちゃでしょ・・・

　いままで、手がなかった子に、「はいやってみましょう！」って、
　それは、ウィリアムのいたずらに、
　「はい、楽譜アリます。音楽の時間に読み方ならいましたよね、
　　ピアノのドの位置わかりますよね。さあ、弾いてみましょう　＾＾；）」

　って言うようなもんで、むちゃっすう・・・

---

　あーいうのは、パソコンかなんかで、筋電位をよみとって、それに応じて、ディスプレイ上の手が動くようなソフトで、事前にかなり練習しないといけないんじゃないでしょうか？
　そーいう意味では、この手の人間＋ロボットのシステムは、それにあわせたバイオフィードバック的なシミュレーターで練習して、その上でやるもんじゃないでしょうか？

　その際、人間の学習能力はすごいので、そーいうシミュレーターで練習していると、筋電位も上がって、操作できるようになると・・・

---

　でも、この話、東大の人たちがやってるくらいなので、ウィリアムのいたずらが気が付きそうなことは、すでに気づいているはずで・・・

・・・って、ことは、TBSは、続編を作るために、ここで話をとめて、
次回、その練習のスポ根ものをつくろうと・・・

　「発想の転換が必要」って番組にあったけど、それは、きっと機械が人に合わせるのでなく、機械と人と一体となってやる必要があるとか、そーいうところに落とし所を持ってくるのでしょうか・・・

　・・また、続きもの狙いですね、TBS
　（そもそも、これも続きものだし、それ以外でも、この前のドライミストも、
　　2007年8月12日の続きもの（同じ人）だし・・・あたらしいことやんないと、長い目でみると、視聴率下がるよね)

「Google Voice」って、なに？音声電話サービス？？

ここのニュース
グーグル、音声電話サービス「Google Voice」の一般提供を開始
http://headlines.yahoo.co.jp/hl?a=20090626-00000000-cwj-inet
によると（以下斜体は上記サイトより引用）


　米国Googleは6月25日、同社サイトで3月以降に音声電話サービス「Google Voice」に登録したユーザーを対象に、同サービスの提供を開始した。


ほお・・・で、「Google Voice」って、なに？


　Google Voiceは、Googleが2007年3月に買収したGrandCentralのサービスをベースにした無料の音声電話ソフト。


って、ここまできくと、無料のIP電話？？ってかんじだけど・・・

ユーザーはGoogleから招待状を受け取ると、Google Voiceの電話番号を選択することができる。この番号に電話がかかってくると、所有するすべての電話に着信するようになる。

うん、なんか違う・・・？？・・・よくわからん・・・

ことばと業務流れ図、ＵＭＬ、ユースケースシナリオの関係

　前の話に関連して。
　業務流れ図を書く場合、結局ヒアリングして、図を描くことになる。
　この場合、どのようなことをヒアリングすれば、業務流れ図を書くことが出来、また、プログラミングまで落とし込めるのか？

　よく、５Ｗ１Ｈが大事といわれる。

　いつ
　どこで
　だれが
　なにを
　なぜ
　どのように

このうち、業務流れ図では、

　いつ
　だれが
　なにを
　どのように

を担当する。これについて、ちょっと説明する。

---

■業務流れ図で、表現するもの

●いつ
　これは、何時何分何曜日、地球が何回、回ったとき！
　っていうのではなく、この作業が終わったら、とか、
　こういった場合というような、状態（ステータス）や、
　手順として、表現される

●だれが
　スイムレーンになる

●なにを
　入力になる

●どのように
　出力になる。普遍的には、「入力を出力に変換する」＝どのように
　ということになるが、文脈に応じて「入力を出力に変換する」が、
　受注するとか、生産するとかに変わる。
　しかし、出力がないと、これが定義できない。

これらのものを業務流れ図を書くときに使う。

---

■業務流れ図で、表現しないもの

●いつのうち、「何時何分何曜日、地球が何回、回ったとき！」
　これは、非機能要件になってくる。毎日起動するとか・・・

●どこで
　これが決まっちゃうと、クラウドとかは、できませんな（＾＾；）
　クラウドなんか、どこで処理しているかわかりませんから・・・

　・・・ただ、非機能要件で指定があるときもある。

●なぜ

　なぜ、この業務を行うのか・・・

　・・・うーん、奥が深い・・・

　首が切れないから。。。とか・・・

　こんな場合は、非機能要件をみてもわかんないこともあるが・・・
　ま、普通、非機能要件？

---

■このほかに・・・

　たとえば、５Ｗ２Ｈとか言う場合、How much,How manyというのがある。
　How Muchである、金額およびそれに伴う納期は、非機能要件、
　How manyである、１時間に何件、何秒以内に返ってくるっていうのも、非機能要件になる。

---

■ＵＭＬ、ユースケースシナリオの関係

　ＵＭＬのアクティビティ図、ユースケース図は、おもに、「だれが、どのように」を、
とくにデータの裏づけがなく、「どのように」を議論する。
そこで、議論はしやすいけど、実現性の矛盾チェックをしにくくなり、
実装できないようなものが出来てしまうことがある。

　その暴走をおさえるために、ユースケースシナリオで具体化するが、
このとき、５Ｗ１Ｈを抑えれば、業務流れ図と同じレベルの精密さになり、
プログラム化可能


・・・だが、ユースケースシナリオは、ＵＭＬの「図」じゃないし、

業務流れ図と同じレベルの精密さになることより、業務流れ図を書いてしまったほうが
早い気がする・・・

UML等各種ダイアグラムのエラーチェック体系化（その８：ドキュメントの一貫性チェック）

シリーズ、 「UML等各種ダイアグラムのエラーチェック体系化」です。
　前回は業務流れ図をとりあげ、
　用語定義→業務流れ図→画面定義書、帳票定義書→ER図→ファイル、DB定義→（クラス図）→プログラム
　という形で、プロセスおよびデータの一貫性チェックができるということ、また、業務流れ図を変形させて、多様なダイアグラムを書き直せることを示しました。

　今回は、業務流れ図の粒度という話と、粒度間・前後工程間の一貫性、そして、一貫性チェックのために何が必要かという話を書きます。

---

■業務流れ図の粒度

　業務流れ図は、大雑把にもかけますし、細かくもかけます。
　スイムレーン＝会社のところに、業務＝システム全体として、書こうと思えばかけちゃうわけです。
　（DFDのコンテキストダイアグラムと同じ。おもに、外部データ、登場人物を明らかにするのに使う）
　もちろん、これらを細かく書くことも可能なわけです。

　では、どこまで細かく書けばいいか？

　基本的に、

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

　と考えると、後工程は、画面定義書、帳票定義書となりますので、

　　どの画面定義書をそろえればいいかわかる＝画面名記述
　　どの帳票定義書をそろえればいいかわかる＝帳票名記述

　が記述されていればいいことになります。つまり、入力時における画面名、出力における画面名、帳票名が特定できるレベルにまで業務が細かくなっていること、つまり、
　「●●画面を入力とし、XXさんが、■■すると、◎◎（帳票・画面）を出力する」
というレベルにまで細かくなっていればいいことになります。

---

■一貫性

　そうすると、大雑把に書いたものから、細かく書いたものまで、業務流れ図が出来ることになります。

　これらの間で矛盾がないかどうか（大雑把に書いたところの入力画面が、詳細化したところで、まったく現れないなど）を確認しないといけません。

　また、前から書いているように、工程の前後間のチェックもしないといけません。

　たとえば、「業務流れ図で出てきた画面は、後工程の画面定義で、画面内容が、定義されていないといけない」とか、そんな話です。

　これらのチェックを一貫性というとすると、一貫性には、

・同じダイアグラムにおける、粒度間での一貫性
・異なるダイアグラムにおける、前後工程間の一貫性

の２つの側面があり、どちらも、ここで書いた

・ダイアグラムの入力に関するチェック
　　　→入力時矛盾チェック
　　　　　＝入力データが前工程で作成されていて、利用可能になっているか

のチェックが必要となります。これを、ここでは、一貫性チェックと呼びます。

---

■一貫性チェックのために何が必要か

　一貫性チェックは、したがって、

・あるダイアグラムを書く工程において、必要なデータがそれまでの工程でダイアグラム等で明記されているか

ということを調べればよさそうです。

明記されているか＝存在しているかのチェック

ということになります。

　それには、いろいろなチェック方法がありますが、ここでは、こんな戦略をとります。

・すべてのダイアグラムをRDBに入れます。
・必要なデータがそろっているか＝そのRDB内に必要なデータが存在するか？
　　ということになるので、
・必要なデータをSQLで検索をかけます。
　　selectで、存在するかどうか確かめる。

　そうすると、問題は、

「すべてのダイアグラムをRDBに入れることは可能なのか？」

ということになります。

その方法について示そう！というのが、このシリーズの１つのテーマです。
次回から、それについて説明します。

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

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

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

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

---

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

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

---

■（２）の場合、

　２度押し防止は、ボタンの.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の場合、画面遷移しない。だから、問題ない。

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

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

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

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

　みたいな・・・

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

UML等各種ダイアグラムのエラーチェック体系化（その７：UMLより最強のダイアグラム）

シリーズ、 「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ページ
（下の真ん中ページ５９、下右端ページ９２）

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

と、こんな流れになる。

---

■ダイアグラムの関係

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

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

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

●ER図
　　上記で作っている

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

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

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

---

今日はここまで。

StrutsのLookupDispatchActionの場所なんだけど・・・・

　Strutsて、ボタンが複数あるとき、DispatchActionというのを使い、とくに、ボタンのラベルを日本語にしたい場合は、メッセージファイルにボタンの名前を書いて、それを表示させる、LookupDispatchActionっていうのを使う。

　このLookupDispatchAction、Strutsの1.2と1.3でちがってる。

そのため、struts-blankを解凍して、このlibをもとに、プログラムを作ろうとすると、

たとえば、struts-blank-1.3.10のWEB-INFのlibの中には、

　struts-core-1.3.10.jar、struts-taglib-1.3.10.jar、struts-tiles-1.3.10.jar

その他もろもろ・・・しかなく、これらのjarには、LookupDispatchActionが所属する、

　　org.apache.struts.actions.LookupDispatchAction

がないので、1.2まではOKでも、1.3では、エラーとなる。

---

この、org.apache.struts.actions.LookupDispatchActionは、

struts-extras-1.3.10.jar

の中にいるので、こいつをリンクする。

なお、こいつを入手するには、strutsのDownloadから、落としてくればいい。

Linux”サーバー構築”標準教科書

まえに、Linux標準教科書ってあったけど、
Linuxサーバー構築標準教科書
ってのも、できたらしい。

ここ　http://www.lpi.or.jp/linuxservertext/

まだ落としてきてないけど、
落としてきて、みよっと！

UML等各種ダイアグラムのエラーチェック体系化（その６：UMLだと、行き詰まる）

　シリーズ、 「UML等各種ダイアグラムのエラーチェック体系化」です。
　前回は、ドキュメントの記述する基準として、

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

を基準に考えると書きましたが、じつは、そーやって考えると、UMLの図は、
みごとに行き詰まります。

---

　たしかに、アクティビティ図とユースケース図の間には、関連があります。
　しかし、これらにおいては、プロセス記述が中心で、データが記述されません。

　データが記述されるのは、クラス図なのですが、このクラスが出てくる根拠が、前工程であるアクティビティ図、ユースケース図から、かならずしも、導き出せないのです。これは、矛盾チェックとして、ユースケースは、どこかのクラスに存在するはずであるという（成果物からの）チェックはできるのですが、前工程とはつながっていないため、ここに悪く言えば恣意性、よく言えば技術者の経験的勘が入ってくることになります。

　クラス図まで持っていけば、Javaなどのクラスに落とし込めることはたしかです。

　ただ、プログラムのほうには持って行けるのですが、データベースのテーブル作成根拠がないのです。ふつうはこの根拠はER図の導出方法（つまり正規化）になりますが、そもそもUMLにER図はないので、（＝エンティティはオブジェクトではない）クラス図で代用することになりますが、そうなると、そのクラスは、永続性をもたせるべきなのかどうか？ということが、これまた、悪く言えば恣意性、よく言えば技術者の経験的勘になってしまうのです。

---

　つまりですね、UMLの図はぶつ切りで、これを結び付けようとすると、えいや！っていうところが出てきてしまい、関連性もなにも、なくなってきてしまうのです（＞＿＜！）

　ところが、ところがですね、ここで、すごいことが起こるのです！！！

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

　を基準に考えた場合、ある図とある図を組み合わせると・・・・

・・・あーれー不思議なことに、ぜーんぶつながって、さらにUMLの多くの図、DFDなどが、自動的に導き出せるのです。

　そして、その図は、UMLや、DFDではないんだけど、よーくみんなかく図なのです。

　この、全部をつなげることができ、多くの図が導出できるという、
　史上最強ダイアグラムについては、またこんど。。

日本のWebはGoogleとかじゃなく、「スナッコまこ」を目指しているってことよ！（その４）

　前回のこの話では、日本における、一般の人たちの情報交換の変化について書きました。
　昭和３０年代～５０年代くらいまでの、大量生産・大量消費時代は、放送というソリューションが有効だったけど、その後、経済が満たされるようになってくると、個性の時代になり、個別の、多様なグループ（コミュニティ）間の情報伝達が必要になった。
　この点、画一的な放送は不向きで、インターネットは、とてもあっていた。そのために、一般の人の情報伝達手段として、急激に利用されるようになったという話でした。

　このように、個別の多様なグループに対する情報伝達となると、一般大衆向け放送とは、ちがってきます。
　一般大衆向けであれば、みんなにウケるような情報を流さねばなりません。
　強烈な個性を出してしまうと、一部の人にしか受けません。なので、あたりさわりのない情報を流します。

　それに対し、個別の多様なグループに対する情報伝達となると、逆に、強烈な個性を出し、「はまる」人を集めます。
　このはまったコアメンバーを中心に、（必要ならば）ここから運営費用を吸い上げ、情報伝達していくことになります。
　逆に言えば、それに反対する人も多くいるわけです。そういう、「反対」、「賛成」が先鋭化すればするほど、
　コアメンバーの結束は強くなります。

　その流れでみると、
　民放テレビ・ラジオ（キー局）→民放テレビ・ラジオ（地方局,BS,CS）→コミュニティFM→インターネットTV
　というようなかんじで、多様化、先鋭化してくるわけで、

　その究極のかたちが、インターネットTVのSolive２４の、なっちゃんが休んだときの、
　「スナッコまこ」なわけです。
　ありっぺが、スナックのママのまこに扮して、１時間番組をやったのですが、
　内容＝ピスタチオを食べて、お酒をついだだけ？
　で１時間もたせるという、ある意味、画期的な番組だったわけです。
　（たぶん、ノープランだったのでしょう・・・）

　こんな超、まったり化した放送を、民放テレビでやったら、非難ごうごう、っていうか、
　実際、「スナッコまこ」放送中も
　「なっちゃん、返ってきて！」という意見があったのですが、ウィリアムのいたずらを含めた、
　一部には受けました（ま、そのあと、なっちゃんが返ってきて、よかったよかったなのですが）

　インターネット放送だと、一部の人に受けて、それで運営が出来れば、十分なわけです。
　他の人が、どう思おうと・・・

　日本のWebは、こーいった、一般の人の小さなコミュニティで受ける、先鋭化、まったり化した方向、つまり「スナッコまこ」の方向に向かっているのであって、中央にだれか１人の王様（これがGoogle）がいて、その人が何でも知っている、っていう方向には向かわないと思います。

　というか、インターネットは、「スナッコまこ」のためにあるのかもしれません・・・

・・・それは別の機会に・・・