今週は、GUIアプリの解析をおこないました。なにぶん手を付けたばっかりなので、これという成果もありません。そこで、こんなやり方をしているよ、という所をご紹介します。「他人の書いたプログラムを読む」方法について、少しは参考になるでしょうか。

GUIアプリは、だいたい７０００行ちょいの、かなり小さなものです。しかし、このGUIは EFLTK という未知のツールキットに依存しています。そして、RTAIという未知のAPIにも依存しています。解析するのは簡単ではありません。

設計書もないソフトウェアを読みながら解析するのって、けっこうウンザリしますね。みなさん、どうやっているのでしょうか。良い方法をご存じの方は、教えていただけると嬉しいです。

解析のやり方

まずはGUIアプリの全体を把握しようと、ソースコードをじーっと眺めているのですが、さっぱり頭に入って来ません。それどころか、「こんなのやってられるかぁ！！！」とイライラしてくるしまつです。

何が悪いんだろう？という話なんですが、きっと脳みそが小さいんですね。いや、物理的な大きさとかじゃなくてですね、こう、一度に覚えておける量が少ないんです。人の顔とかよく忘れますしね。（悪意はないんですよ！）

きっと頭のいい人であれば、ソースコードをざざざーっと呼んで、７ｋくらいの量であれば簡単に把握しちゃうんですよね。そんな人、いっぱい知ってます。でも私には無理です。年のせいじゃありません。むかしからこうでしたから。

とまぁこんな感じですから、ふつうのやり方じゃあどうにもなりません。しかたが無いので、「情報」というものの持つ有り難い性質を活用することにします。

実は、「情報」って折りたためるんですよね。いくらでも小さく。だから、いっぱい情報があっても大丈夫。私の小さな脳みそに入る程度に、折りたたんでしまえばいいんです。

たとえば、こうです。GUIアプリのソースコードの一部に、こんなものがありました。

static long try_to_connect(const char *IP)
{
	int counter = 0;
	int counter_max = 5;
	char buf[100];
	long port;
	struct sockaddr_in addr;

	sprintf(buf, "Trying to connect to %s", IP);
	RLG_Main_Status->label(buf);
	RLG_Connect_Button->deactivate();
	RLG_Main_Window->redraw();
	if (Verbose) {
		printf("%s...", buf);
		fflush(stdout);
	}
	inet_aton(IP, &addr.sin_addr);
	Target_Node = addr.sin_addr.s_addr;
	while ((port = rt_request_port(Target_Node)) <= 0 && counter++ <= counter_max) {
		msleep(100);
	}

	return port;
}

まずは頑張って処理を追ってみます。

ふむふむ。

RLG_Main_Status->label( buf ) か。良く分からんが、なんか表示してるんだろう。

RLG_Connect_Button->deactivate(); か。接続ボタンをディセーブルしてるのかな？

・・・

inet_aton, rt_request_portか・・・知らない関数だ。でもなんか、ポートってやつを取ろうとしてるんだな。IPってシンボルはグローバル変数かな？まぁIPアドレスの事だろう

はい。もう私の頭は try_to_connect の事でいっぱいです。他の関数の処理みたら、 try_to_connect の事は忘れます。

そこで、try_to_connectの処理を、こう言ってしまいます。

「指定されたIPをもつマシンにアクセスし、何かポート番号ちっくなものを取ってくる」

これだけ。枝葉を切り落として、本質だけ抜き出します。これだけでもすぐに忘れちゃいますから、Excelシートに書き込んでおきましょう。

こんな感じで、関数名一覧をExcelに書き出しておいて、そこに１行、処理内容を書きこんでおきます。

これで安心。次の関数に行きましょう。そうして次の関数を追っているとき、 try_to_connect が出てくるかも分かりません。でも大丈夫。Excelシートをひょいとみれば、あぁそうだった！と思いだせます。

こうやって解析をすすめていくうちに、「何かポート番号ちっくなもの」って正確には何の事なのか？も分かってくる事でしょう。今はこれで十分です。

まぁこんな感じでやっています。「情報が多すぎて頭に入らない」→「頭に入る大きさまで、情報を折りたたむ」→「構造化して格納する」。これをやっていれば、だいたいの事は頭に入ってしまいます。（もちろん枝葉は大量に切り落としているので、あとから必要に応じて再調査します。）

次回

RTAIの使い方が、なんとなく見えてきました。来週は頑張って、このあたりを整理したいと思います。