一般的な編集ソフトの作り方 その２１：画面の構成（概要）

　ワープロやドローイングソフトなどの編集ソフトを作る上での一般的な考え方を考える「一般的な編集ソフトの作り方」です。
　ここでは、主に、

　　・メモリ上に、要素をもつ
　　・イベント発生時の動き
　　・画面の構成

ということで、前回、やっと「イベント発生時の動き」が終わりました。

　今回から、「画面の構成」に入りますが、今日は概要です。

---

■一般的な編集ソフトの画面構成

　編集ソフトは、一般的に画面構成は、似ています。

・メインとなるウィンドウがあり、ここに編集内容が表示されます。
・そのウィンドウにメニューがついていることが多いです。
・それ以外のウィンドウもあり、選択したものの属性値の設定や
　次に作成するものを選択できたりします。

　で、さらに、そのメインのウィンドウについているメニューの並び順、
内容も決まっています。

　左から、
　　・ファイル：保存、読み込み、印刷など、ファイル全体の操作
　　・編集：コピー、ペースト、カットなど、オブジェクトの操作
　　・属性設定など、選択オブジェクトに対する操作
　　・ツール：その他のソフトを使ったり・・などなど
　　・ヘルプ：ヘルプとバージョン情報
（ヘルプが一番右）

　です。まあ、違う編集ソフトを作っちゃいけないということではないと思うので、それ以外のものもあるかもしれませんが。。。

　なお、メニューの横に「...」とある場合は、サブメニューがあるようです。

---

■そこで問題点

　そこで問題点があるのは、

・別ウィンドウにある、属性値のウィンドウの値が変化したら、
・今まで書いてきた、「イベント発生時の動き」のような手順で、
・メインウィンドウを書き換えないといけないことがある

というように、ウィンドウ間の操作が起こることです。

---

　これを、行うための共有メモリの話（昔良く書いた、「カオル姫方式」）について、次回は書きたいと思います。

ワークフローの実装方法

　上司が、申請書類等（企画書類なども）を眺めて、良ければ承認、悪ければ承認を拒否して、全員承認されたら、次の作業に入るという、承認のワークフローについてのお話。

　このワークフローの実装方法というのは、一般的（汎用的）に作成することが可能で、以下のように行います。

---

（１）ワークフローの流れを定義した、「承認フローテーブル」を作成します

　ある人が、ある申請書を作成したら、何番目に誰が承認するということを記述した、「承認フローテーブル」を作成します。項目は、以下のとおり

	申請者ID
	承認者ID
	申請書種別
	順位
	承認種別

　承認種別とは、同順位の人が、１人でも承認すればOKなのか、全員承認しないといけないのか（ただし、承認順は、同順位内だったら、だれから承認してもOK)をしめします。

（２）申請書を作成したら、「承認フローテーブル」を検索し、
　　　必要な承認者を、「申請承認者テーブル」にセットします

　申請書が作成されたら、その申請書の申請書種別と、申請者を元に「承認フローテーブル」を検索し、承認が必要な人を割り出し、その結果を、「申請承認者テーブル」にセットします。「申請承認者テーブル」の項目は、以下のとおり。

	申請者ID
	承認者ID
	申請書種別
	申請書ID
	順位
	承認種別
	承認状況　0：未承認、1:承認 2:拒否

このとき、順位-1で、承認者を申請者にしたレコードを追加しておくと、
承認拒否された場合、次の承認順位－１にすることで、申請者に戻ります。

（３）申請書にステータスという項目を追加、次の承認順位を入れます。
　申請時は、次に承認してもらう人の承認順位は１なので、ステータスに１を入れます。


（４）承認・拒否したら、「申請承認者テーブル」を更新します。
　　　その内容に応じて、ステータスに次の承認順位をセットします。
　まず、承認したら、「申請承認者テーブル」の承認状況を１に、
　　　　拒否したら、承認状況を２にセットします。

　次に、申請書のステータスについて、
　拒否の場合は、申請者に戻るように、ステータスをー１にします。

　承認の場合、承認種別をみて、
　　　全員承認なのに、自分が承認してもまだ未承認の人がいれば
　　　　　　ステータスは、そのままで、抜けます

　　　全員承認で、全員承認した場合、
　　　あるいは、１人でも承認すればいい場合　　　
　　　　　　ステータスを１上げます。
　　　　　　その１上げた状態で「申請承認者テーブル」を検索して、
　　　　　　該当者がいなければ、すべての承認が終わったことになるので、
　　　　　　ステータスを、承認終了のステータスにします。

　承認終了のステータスは、０にしたり、９９とか、ある特定の数字にしたり、イロイロあると思います。


（５）こうすると、今承認しなければいけない人は、
　　　申請書のステータス＝申請承認者テーブルの順位
　　　でわかります。

　終了していれば、承認終了のステータスになりますし、
　承認拒否の場合、－１です。
　なお、承認が拒否され、再登録する場合、「申請承認者テーブル」も、過去のものをクリアし、（２）からやり直すのが普通だと思います。

開発の初めから順番に書いていってみる その６６：プログラミング（２８）入出力の自動生成１６

シリーズ「開発の初めから順番に書いていってみる」の続きです。
　設計手順には、要求分析、外部設計、内部詳細設計・プログラミング、単体テスト、結合テスト、総合テスト、運用テスト及び運用とあります。
　現在プログラミングです。
（プログラミング以前は、ここ http://www.geocities.jp/xmldtp/index_kaihatsu.htm）

　プログラミングでは決定表と自動生成のお話をします。
　今、画面の自動生成で、特にBREWの自動生成版とJavaの画面自動生成を共存させる形でのアプローチをしています。

　前回は、ソースと仕様書の関係で
　　・アプリ起動
　　・各画面
　　・各画面のイベントリスナーのクラス
の仕様書とソースがあることを示しました。

今回は、各画面のイベントリスナーのクラスに関して、その方向性についてです。

---

■画面イベント処理の方法

　いま、サンプルにしているソースは

ここのgamen1.javaで、イベントは、gamen1クラスのインナークラス、
gamen1_HandleEventクラスです。
　これを、今回は、インナークラスではなく、外に出して１つのクラスとして扱うことにします。
　１画面に対し、１イベントクラスとします。

　そのとき、
・クラスのextendsは、画面で利用している部品(TextとかButtonとか）
　によって決まります
　→仕様書の型からマクロを使って、抽出すれば、求まります。

・イベントクラス内のメソッドも画面で利用している部品によって決まります

・どこで、イベントが起きたかに関しては、イベントeを受け取り、
　Object o = e.getSource();
　として、そのoに対し、

　　　　if ( o.equals(b1)== true)

（ここで、b1は、画面の部品オブジェクト）と聞けばOKです。

・で、イベントと、そのイベントが起きた部品が分かったので、
　それに基づいて、処理を行えばいいです。

---

■方向性

で、どうやって、イベント処理をするかということなのですが、
・まず、仕様書に、どの部品が、どのイベントが起きたとき、
　イベント処理するかを書いてもらいます。

・各部品で、起きるイベントは、きまっています。そこで、たとえば、

	//	共通領域
	public HashMap	map = null;

	/*
 	 * 	ボタンが押されたときの処理
 	 */
	public void widgetSelected(SelectionEvent e) 
	{
		Object o = e.getSource();
		shoriPro("WS",o);
	}

		:
	（ほかのイベント処理が続く）
		：
		：
	/*
 	 * 	全部のイベント処理
 	 */
	public void shoriPro(String eventCode,Object o) 
	{
		Gamen1 g = (Gamen1)map.get("gamen1");

		if ( ( eventCode.equals("WS") == true) &&
                     ( o.equals(g.b1)	==	true ) )
		{
			//	呼び出し
			//	mapを引数に渡せば、
			//	map.get("gamen1")で、画面の値が取れる
		}
			:
		（ほかの呼び出し処理が続く）
			：
			：
	}

のように、

　　＊まず、コントロールから、必要なイベントを並べ、すべて、
　　　shoriProにとばします。

　　＊そこで、仕様書に書かれた、イベントと部品があったら、
　　　処理を呼び出すようにします。

こうすると、生成しやすいし、あとでイベント内の処理を書きやすいです

---

■で、このときに

で、このときに、shoriProの中に、処理内容を書いてしまうと、画面の修正があったとき、再度自動生成すると、書きつぶしてしまいます。
そこで、

	public void shoriPro(String eventCode,Object o) 
	{
		Gamen1 g = (Gamen1)map.get("gamen1");
		Shori  shori = new Shori();

		if ( ( eventCode.equals("WS") == true) &&
                     ( o.equals(g.b1)	==	true ) )
		{
			shori.b1_ws(map);
		}
	

のようなかんじで、一回、別のクラスの別のメソッドを呼び出し、そこで、処理をさせるようにすれば、イベントクラスを上書きされても、大丈夫です（shori.b1_ws(map)の呼び出し部分が消えてしまいますが、そこも自動生成すればいいようにします）。

---

　ということで、イベント部分も自動生成できそうです。