ＤＴＰの構造を考える－その１１：アルゴリズムとメモリ構造 その２メモリ構造

土日シリーズ「ＤＴＰの構造を考える」です。

　このシリーズ、第９回までで、本の構造、さらにＤＴＰソフト全体でもつ、フォント、色、ライブラリの構造を概念的に説明してきました。
　前回、その内容を、プログラムに落とし込んでいくための、アルゴリズムとメモリ構造について説明していくということを書きました。
　今回はまず、メモリ構造からです。

---

■一般的なメモリ構造の話

　といっても、一般的なメモリ構造の話は、ちょうど、

一般的な編集ソフトの作り方　その１０：メモリ上への要素展開（共通要素の例）
http://blog.goo.ne.jp/xmldtp/e/84fb2a6adcdabd978b48422a9bff14d7

に書いて、サンプルソースを張ったところです。

つまり、

・子供と、
・属性（座標位置、文字、色など）と
・メソッド
　　・insertChild（子供の挿入）
　　・deleteChild（子供の削除）
　　・読み(readData)
　　・書き(saveData)
なんかをもっていて、実際の各要素は、さらに、

・表示
・位置決め

ロジックを必要とするというものです。

---

■各要素について

　そこで、ＤＴＰソフトをもし作ろうとする場合、

１．構成要素を考える
　　　本、ページ、枠、行、文字、写真、四角形、まる・・・・などなどです。
　　　枠にも、いろんな種類がありますし、文字にもいろんな種類があります。

２．その構成要素の親子関係を考える

　　本
　　｜
　ページ
　　｜－－－－－－－
　　｜　　　｜
　　枠　　写　真
　　｜
　　行
　　｜
　　文字

みたいな親子関係です。ＤＴＰの場合はツリーになることが多いです。

３．それぞれの属性を考える
　たとえば、写真には文字はないですし、文字には斜体はありますが、ページに斜体は普通ありません（いや、そーいう製本をすれば作れるでしょうけど、ふつうそんなことはしない）。
　つまり、各要素に応じて、属性があります。それを考えます。

４．それぞれの表示、位置決めのアルゴリズムを考える
　ここが中心になります。行に関しては、前回書いたとおり、ＪＩＳ規格があると。。
　それに従ってもいいし、さらに付け加えるなどなど。。ソフトによって、ここが大きく違ってきます。

５．そのクラスを作ります。
　たとえば、枠なら

　public class Waku extends Item

みたいなかんじで、要素の共通部分（ここではItem）をextendsして、さらに、各要素固有の４で決めた内容である、表示、位置決めなどを入れていきます。

---

■調査する場合

　ＤＴＰソフトを比較・調査する場合でも、上記の手順はつまえます

１．要素はどうなっているのか？
　　→自分がやりたい操作の要素があるほうが便利

２．その要素の親子関係など
　　→枠の連結も重要

３．各要素における属性
　　自分が表現したいものが、その属性を使って出来るだけ簡単に表せたほうがいい。
　　例：文字に縁取りがなくても、文字を２文字おいて、上の字を中央あわせすれば、
　　　　たしかにそれっぽく見えるかもしれないが、縁取り属性があったほうが便利

４．表示、位置決めアルゴリズム
　　→どこまでがんばるかを見る

　あとは、実際のものを作ってみてとか、操作性という話になる。

---

■困る点

　でも、これで、困る点が１箇所あります。
　検索のとき、１文字１クラスで入っているので、クラスを１文字１文字とってきて、比較する形になります。文字列検索の便利なものは使えません。

　この場合・・・

　枠の属性として、”枠の中に入る文字”を持ってしまい、文字クラスでは、その枠が持っている文字の何文字目に相当するかの配列番号とかを持っていれば、枠の属性を調べることで、文字列検索が出来ます。めでたしめでたし。。だけど、いまはそんなことしないで、１文字づつ調べたほうが早いかも？？

---

ということで、きょうのメモリ構造のところはおしまいです。

基礎年金番号を導入したことがそんなに悪いのか？ＣＩＯ補佐官がコメントを出したほうが。。

せっかくコメントをはずしているので、もしコメントを受け付けたら、非難ごうごうになるようなことを書こう。

最近、年金問題で、「基礎年金番号制度」を導入したことが、さも悪いような感じで非難しているが、本当にそうなのか？
　この件に関して、情報処理の権威からのコメントがでていないような気がするが。。

　ウィリアムのいたずら的に考えると、「基礎年金番号制度」を導入したことはむしろいいことで、今問題になっている５０００万件は、基礎年金番号制度を導入してもしなくても、いずれ問題になったことだと思う。

---

　なぜ、そのような主張をするかというと、一般的に、データベースを作成するとき、正規化を行うが、第二正規形において、１エンティティに１ＩＤを振るのが普通だからだ。

　だから、具体的に言うと、１人の人に１つの番号をふるのは、あたりまえで、
　そうしないと、名寄せ（複数のＩＤが振られているものを、１人のものにあつめる）をしないといけなくなる。

　このとき、すべての情報がそろっていればいいけど、データの入力ミスや、そもそも一部情報でも入力されてないと、名寄せできない。
　たとえば、名寄せを行うのに、名前と生年月日と男女別でやっていたとき、名前を間違えて入力したら一致しないし、生年月日を入力し忘れてしまったら、山田太郎などというありふれた名前だったら、いっぱい出てきてしまう（いや、生年月日と名前がわかっても、同姓同名で同じ日生まれって、全国的に見るとありえるけどね）。

　そういう意味で、年金を一元管理するために、基礎年金番号をいれることは、問題というより、ここ
基礎年金番号の基礎知識
http://www1.mhlw.go.jp/topics/kiso/
に書かれているとおりに、メリットが多いことだと、ウィリアムのいたずらには感じる。

　基礎年金番号を導入したから、５０００万件の問題が発覚したわけで、もし導入しなかったら、結局は名寄せのときに（いつかは名寄せしないといけないから）できなくて。。。でも、毎日少しずつおかしい感じだから、なんとなーく、それで流れてしまい、問題が明るみに出なかったんじゃないかと思う。

---

　では、基礎年金番号を導入した仕方がわるかったか？っていうと、それも、どーなのかなあ？？

　つまり、データがちゃんとしていれば、名寄せというのは、難しい作業にはかんじられないのですよ。多くの部分は、コンピューターがやることですからねえ。。所詮。

　つまり、そこに時間がかかっている５０００万件というのは、むしろ、基礎年金番号導入以前に、払い込んだところの入力でぼろぼろになったか、コンピューター化した時点でぼろぼろになったか、っていうのが多いんじゃないかという気がするんですよ・・・

　いや、ウィリアムのいたずらが、その年金データを見たわけではないので、わかんないんですけど、結構データ移行とか名寄せとかでは、そーいうケースが多いと思うのですよ。

　で、データがぼろぼろだとすると、これも基礎年金番号をいれなくても、名寄せしたときにぼろぼろになると思うんですよ。。

---

　それと、最近話題になっている、原簿の破棄の問題。
　一見すると、これ、悪そうに見えますけど、でも、当事者の地方自治体にとっては、莫大な量の紙なわけで、これを保管しているのもねえ。。

　で、本来、マイクロフィルム化してると思うんですけど、マイクロフィルム化しているのは、当然捨てていい。当時は時効があったので、それ以前のも捨ててしまっても。。。正直しょうがないかなと。。

　ただ、マイクロフィルム化してなくて、捨てちゃったとしたら、それはずさんなわけで、非難されるべきなわけです。

　つまり、ここで問題なのは、書類管理の業務手順が、ちゃんと明確化され、妥当なものであったか？ということです。マイクロフィルム化されていれば、原本はすてていいし、マイクロフィルム化したものも、将来的には電子化して、デジタルに正副のこして、捨てるというカタチにすべきでしょう。そして、そのイメージデータから、現在のデータとの突合せができるようにすべきです。

---

　つまり、本来、問題にすべきは、社会保険庁のデータ入力から支払いまでの書類管理、データ管理に甘さがあったんじゃないか？というところです。そこを追求しないといけません。
　そーいうことをやるのがＥＡであり、そのための電子政府です。

　電子化を促進する気があるのなら、今回、
・マイクロフィルムで入っている資料をいったん電子化し、
・それをＯＣＲで読み込んで、
・ＯＣＲ結果とマイクロフィルムのデータを人が目視でチェックして、漏れや問題を確認
　して、ちゃんとしたデータを作成し、
・それと現状のデータと全部付き合わせて、おかしな点を確認する

　作業もやるべきです。そして、その結果を、納付した人みんなに送って、チェックしてもらうことです。名寄せできない５０００万件ですませるのは、甘いです（－＿－）
　もちろん、５０００万件もやってくださいね（＾＾；）

　で、その上で、社会保険庁の業務をすべてみなおし、データの入力漏れにつながるようなところがないかどうかを、業務監査すべきです。

---

　なのになのに、。政府はただ、基本年金番号の導入のときに問題になったから、そこがわるいと、責めているだけです。これは、ウィリアムのいたずらから見ると、大学病院で死ぬ人が多い。だから大学病院は悪いというようなものです。もともと死にそうな人が大学病院にいくから死人が多いだけで、もし大学病院がなかったら、もっと死人が出ます。

　同じように基本年金番号を導入する以前も、以降も業務的に問題があって、基本年金番号を導入したから、それが明るみになっただけで、導入しなかったら、もっと名寄せできない状況になったかもしれません。

　廃棄の問題も、コレ自体問題かもしれないけど、廃棄以前にちゃんと入力していれば問題ないわけで、入力がちゃんとしていないことと、ちゃんとしていることを確認できるしくみがないのが、いちばんいけないと思います。

　でも、そこには触れないで、与党野党で、たんに表面的にあらそっている。。。
　ウィリアムのいたずらは、この態度が、一番悪い元凶だと思います。

---

　で、このような危険性は、電子政府にもあるわけで、
　ある日、突如として、風向きがわるくなることっていうのも考えられるわけです。

　特に名寄せの問題は、これ以外でも、電子政府のいろんなところで出てくると思います。

　そーいう意味でも、データベースにおいて、日本を代表するようなＣＩＯ補佐官がいれば、そーいう人が、この基本年金問題に関して、学会誌あたりで、コメントを出しておいたほうが無難なんじゃないかなあ・・・

　じゃないと、世論的に、あとで電子政府でも同じような場面（個人を特定する番号関係、住基ネットとか）でも、あとあと政府に責められ、一生懸命やっても、国民の理解が得られない気がするなあ。。

---

　つーか、電子政府とか進めてても、そもそも、日本で情報処理や通信において権威のような人が、良識の府である、参議院議員になってない。。。つーのもね　（＾＾；）

　

一般的な編集ソフトの作り方 その１０：メモリ上への要素展開（共通要素の例）

　ワープロやドローイングソフトなどの編集ソフトを作る上での一般的な考え方を考える「一般的な編集ソフトの作り方」です。
　今日は、今までのまとめと、共通要素のサンプルです。

---

■全体のまとめ

　いままでで、メモリ上に、要素を展開する方法について、ひととおり書きました。
　つまり、編集ソフトによって、枠や文字、絵、写真、四角形、（フローチャートの場合）プロセス、条件・・・いろいろあるけど、それぞれは、１要素として１クラスでまあ、表現しましょうと。。

そのとき、各要素（すなわち各クラス）は、以下のメソッド
・insert（子供をinsert）
・delete（子供をDelete）
・read
・write
・print（表示）
・位置決め
があるんだけど、このうち、表示と、位置決めは、各要素によって違う。
でも、他は、システムにおいて、だいたい似たり寄ったりであるので、共通要素クラスとすることもできる。

　で、その場合の表現方法として、
　　　・Ｖｅｃｔｏｒや配列で表現する方法
　　　・連結リストで表現する方法
　があり、read,writeの手法は、完全な木構造（ＸＭＬで表現できるような）か、網目状かでちょっと変えたほうがよく、木構造ならＸＭＬで親から順に保存、読み込みしたほうがいいし、網目状だと、配列をバッファにして、ＩＤを利用して、親子や兄弟の連結を埋めていったほうが楽かもしれない。

　というのが、全体のまとめになります。

---

■共通部分サンプル

ということで、共通要素クラスのサンプルを出してみたいと思います。
共通部分なので、
・insertChild（子供の挿入）
・deleteChild（子供の削除）
・読み(readData)
・書き(saveData)
となります。printは、デバッグ用にコンソールに出すものです。
画面表示用printと位置決めは、各自の要素で作成することになりますので、ここではつくりません。

　今回は、子供にVectorを使う形にしました。
　ってことで、完全に木構造になるものとして、XMLで読み書きする場合について、考えてみました。

---

■ソース
そうすると、以下のサンプルになります。

/*
 * 
 *　要素共通クラス
 *　これを、extendsして、各要素を作る 
 * 
 * TODO extendsしたあと、位置決めメソッドと、画面用の表示を作成
 * してください。そこに書かれているprintは、コンソールデバッグ用です
 * 
 */
import java.util.*;
import org.w3c.dom.*;
import java.io.*;

public class Item {
	/*
	 * 	自分の名前
	 */
	public	String	itemKind = "";

	/*
	 * 	子供のデータ
	 */
	public	Vector	child = new Vector();

	/*
	 * 	属性
	 */
	public	HashMap	attr = new HashMap();
	
	/*
	 * 子供の挿入
	 */
	public	int	insertChild(Item rec,int pos)
	{
		child.insertElementAt(rec,pos);
		return	0;
	}
	
	/*
	 *　子供の削除 
	 */
	public	int	deleteChild(int pos)
	{
		child.removeElementAt(pos);
		return	0;
	}

	/*
	 *　子供の取得 
	 */
	public	Item	getChild(int pos)
	{
		return	(Item)child.elementAt(pos);
	}

	/*
	 * 	データ読み込み
	 */
	public	int	readData(Node data)
	{
		if ( data	==	null)
			return	-1;
		
		//	自分の名前を設定する
		itemKind	=	data.getNodeName();
		
		//	自分の属性値を設定する
		NamedNodeMap attrList = data.getAttributes();
		if ( attrList	!=	null)
		{
			for(int i = 0 ; i ＜ attrList.getLength(); i ++)
			{
				Node node = attrList.item(i);
				attr.put(node.getNodeName(),node.getNodeValue());
			}
		}

		//	子供の設定
		child.removeAllElements();
		Node node = data.getFirstChild();
		while ( node != null)
		{
			if ( node.getNodeType()	!=	Node.ELEMENT_NODE)
			{
				node = node.getNextSibling();
				continue;
			}
			Item childItem = new Item();
			childItem.readData(node);
			child.add(childItem);
			node = node.getNextSibling();
		}
		return	0;
	}

	/*
	 * 	データ書き出し
	 */
	public	Node saveData(Document xtree)
	{
        Element kekkaNode = xtree.createElement(itemKind);
		
        //	属性の設定
        String[] attrKey = (String[])attr.keySet().toArray(new String[0]);
        for(int i = 0 ; i ＜ attrKey.length ; i ++)
        {
        	kekkaNode.setAttribute(attrKey[i],(String)attr.get(attrKey[i]));
        }
        
        //	子供のセット
        for(int i = 0 ; i ＜ child.size() ; i ++)
        {
        	Item	childItem =	(Item)child.elementAt(i);
        	Node cn = childItem.saveData(xtree);
        	kekkaNode.appendChild(cn);
        }
		return	kekkaNode;
	}

	/*
	 * コンソール出力用の表示
	 */
	public	int	print(PrintStream out)
	{
		out.println(itemKind + ":");
		
		out.println("属性："+attr.toString());
		for(int i = 0 ; i ＜ child.size(); i++)
		{
			out.println(i+"番目：");
			Item childItem = (Item)child.elementAt(i);
			childItem.print(out);
		}
		return	0;
	}
}

（上記　＜　＞　￥は、本当は半角）

これについて説明するには、まず、呼び出し側を仮に作って説明しないと説明しにくいのですが、この後続けて書くと、すごい量になるので、今回は、ここできります。

Winnyで自殺者がでたそうな

ここの痛いニュース
Winnyで児童の個人情報流出、男性教諭が自殺
http://blog.livedoor.jp/dqnplus/archives/986041.html
によると（以下斜体は上記サイトより引用）


千葉県市原市教委は８日、市立小学校の男性教諭（３４）所有パソコンから同市内の２小学校の児童計２６９人分の個人情報が、ファイル交換ソフト「ウィニー」を通じてインターネットに流出したと発表した。市教委によると、この男性教諭は５日に自殺したという。


うーん。。。情報が漏れて自殺する人まで出てきましたか。。。
とはいえ、自殺までしなくても（＾＾；）