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

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

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

画面定義をHTMLで行い、呼び出しをWebAPIでやる設計手順の試案 その3分離用ダミーCGI

2007-04-09 17:11:34 | Weblog

 なぜか、シリーズ化してしまった、「画面定義をHTMLで行い、呼び出しをWebAPIでやる設計手順の試案」です。

 やろうとしてるのは、
・HTMLで画面を作成し、

・AJAXでサーバ呼び出し、結果はXMLで受け取ったものを利用して
  →Javascriptでその画面に結果を出力したり
  →次画面をだして出力したり。。

・そーすると、画面とサーバーが完全に分離する

という話と同時に、画面から、逆にさかのぼって要求仕様にまでもっていける。そうすると、COBOLのシステムをWebに置き換えたいけど、ドキュメントもソースも無いときなんかに、利用できるっていう話




■いままできたところ

 で、今までの話で、
(1)画面をHTMLで作成する(ここがスタート)
(2)アクションなど、イベントを拾うところで、
    onイベント=ファンクション
   として、とにかく、ファンクションをfunctionでつくってしまう
(3)作った関数について
   サーバーアクセスするものは、関数の中に
     sv_access(呼び出し元、呼び出したいサーバーアプリ,"")
   みたいなかんじで、ダミー関数を書く
(4)grepで、(3)のダミー関数(sv_access)を、一覧で取得
(5)検索した内容をファイルに保存し、Excelで読み込み、
   WebAPIのサービス一覧を取得する
(6)でてきた呼び出したいサーバーアプリ=サービスを、
   1サービス1シートで、Excelシートにまとめる

ところまできました。




■今日の内容

 今日は、

(7)クライアント側の画面と、サーバー側を完全に分離するためのダミーCGIを入れます。
  ・まず、返すXMLを作成します
  ・ダミーCGIを作成します

 という作業をします。

 これを入れると、クライアントはクライアントで、サーバーはサーバーで、完全に分離して勝手に作業ができます。(さっきの、「逆にさかのぼって要求仕様にまでもっていける」という話は、このあとの作業になります。それは、次回の範囲です。)





■分離用CGIのつくりかた(1:返すXMLを作成)
 前のところで、こんなWebAPI定義をかきました。

で、その結果、返る値は、
<?xml version="1.0" encoding="UTF-8"?>
<result>
  <code>0</code>
</result>

(上記< > は本当は半角)
のようなかんじになると書きました。

そこで、上記の内容を、ファイルに保存して、次に書く文利用CGIからみえる、適当なところに保存します。



■分離用CGIのつくりかた(2:ダミーCGI)

で、アクセスする関数は、サーバーのCGIのURLがhttp://127.0.0.1/cgi-bin/とすると、
 http://127.0.0.1/cgi-bin/alltest.cgi?user=user1
のようになるとかきました。

ここで、そのCGI置き場(CGI-BIN)にある、WebAPI名のCGI(例だとalltest.cgi)を、以下の、上記XMLを返すだけのダミー関数にします。
#!C:/Perl/bin/perl
use CGI;

#################################
#	宣言			#
#################################

#
# 以下のalltest.xmlを、毎回、送り返したいファイルに
# かきかえること
#
$sendfname = "alltest.xml";	#	送り返す内容のファイル


				#################################
				#	必要な変数の取得	#
				#################################
##引数を取得
if ( $ENV{'REQUEST_METHOD'} eq "POST" )
{
	read (STDIN, $qs, $ENV{'CONTENT_LENGTH'});
}
else
{
	$qs = $ENV{'QUERY_STRING'};
}
@qs = split(/&/,$qs);
foreach $i (0 .. $#qs) 
{
	($name, $value) = split(/=/,$qs[$i],2);
	$value =~ tr/+/ /;    #“+”を空白
        $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;   # %XX変換
	$qs{$name} = $value;
}


				#################################
				#	ファイル読み込み	#
				#################################
if ( -e $sendfname )
{
	$flen = -s $sendfname;	#	ファイルサイズ取得
	open (IN, $sendfname);
	read (IN, $send, $flen);
	close(IN);
}
else
{
	$send	=	"";
}


				#################################
				#	出力			#
				#################################
#見出しの表示
print "Content-Type: text/xml¥n¥n";
print $send;

(上記< > ¥ は本当は半角)




 こうすると、上記のURLでクライアントから呼び出すと、上で書いた返すXMLが返ってくるので、これをもとに、画面部分のプログラムを書いて、単体テストすることができます。
 というところで、今日はおしまい。



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

開発の初めから順番に書いていってみる その24:外部設計(1)外部設計とは

2007-04-09 14:32:31 | 開発ネタ

シリーズ「開発の初めから順番に書いていってみる」の続きです。
 前回までで、要求分析が終わったので、今回はその後、かつ、内部詳細設計の前の工程です。

 まず、その工程が、いろんな呼ばれ方をしているけど、ここでは、外部設計と呼ぶことにするというお話と、その外部設計で、やることについてです。




■要求分析と内部詳細設計の間

 ここの呼び方は、いろいろあります。
 まず、外部設計と呼ぶ呼び方。
 次に、基本設計と呼ぶ呼び方。
 さらに、それと、概要設計っていうのが関係し、結果として、

   外部設計≒概要設計(+α-β)
   外部設計≒基本設計(+α-β)
   外部設計≒概要設計+基本設計
   要求分析+外部設計≒概要設計+基本設計(+α-β)

 と、人により、さまざまな言い方になってしまっているのですが、
 ここでは、内部詳細設計=>内部設計に対応して、それら一連の作業を外部設計ということにします。

 つまり、ここでの定義は、

 要求分析の後、内部詳細設計の前までに行う設計作業を、すべて、外部設計と呼ぶことにする。

 とします。




■富士通の公開されている開発標準では?

 ここで、いつもどおり、富士通の公開されている開発標準
ComponentAA開発標準
http://segroup.fujitsu.com/sdas/technology/develop-guide/1-caa.html

で、この外部設計に対応するところをみてみると、
UI工程と、SS工程がそれにあたります。
以下、その内容を引用すると(以下斜体は上記サイトより引用)

2.2 UI工程ドキュメントでは、システムの外部仕様の定義を行うためのドキュメントを定めます。 ユースケース(利用者にとって業務的に意味のある目的を完了するまでのプロセス)を単位に外部仕様を定義します。

2.3 SS工程ドキュメントでは、システムの構造設計を行うためのドキュメントを定めます。 ユースケースの持つ機能を主要な実装構成要素(コンポーネント、プログラム、クラス、メソッドなど)に分割し、それらの間のインターフェースを定義します。

ということになります。




■ここでやる作業

では、ここでやる作業は何かというと、
要求仕様で、何をやるかを決めたので(それをまとめたのが、要求仕様書)、
ここでは、それをどうやって実現するかを設計します。

つまり、何をするか=>どうやってするか?の変換過程ということになります。

 どうやっての部分に関してですが、情報処理というのは、入力があって、それを処理して、出力にだすわけです。なので、入力部分と出力部分を、どうするか、これが、ユーザーインターフェース(UI定義)になります。
 これは、入出力の種類ごと(画面、DB、ネットワークに流れるデータなどなど)に、定義の仕方が違います。

 そして、もうひとつの、処理する部分、これが、SS工程になるのですが、これは、要求仕様の「何を」から、実際にコンピューターで、どのようなプログラムで機能を実現するかにまで、落とし込んでいきます。




■「どうやって」の雛形としてのフレームワーク

 で、今まで書いてきたように、要求仕様の「何を」の部分に関しては雛形はないのですが、「どうやって」の部分には、雛形はあります。この雛形となっているのが、フレームワークと呼ばれるものです。

 DB部分のフレームワーク(O/Rマッピングなど=それ以外にもフレームワークはある)とか、画面部分のフレームワークとか、いろいろあります。

 ただ、要求仕様のところに書いたように、雛形は、実際にはカスタマイズしないといけません。っていうことで、これらフレームワークでも、実際のシステムを書くときには、一部、つなぎ部分を作ったりします。




 では、フレームワークのつなぎ部分というのはどこで、なにをするのかということになるのですが、それを説明するには、まず、要求仕様書にあるDFDを、フレームワークをつかって、どうやって、プログラムに落ちるのかのしくみを説明しないといけません(そこの説明の中で、つなぎの部分が出てきます)。

 ということで、このシリーズの次回は、”要求仕様書にあるDFDを、フレームワークをつかって、どうやって、プログラムに落ちるのかのしくみを説明”します。


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

人工筋肉で介護補助・障害者補助をするのにパソコンじゃなくて、ケータイで制御したら?

2007-04-09 11:09:34 | Weblog

 昨日、TBSの「夢の扉」で、人工筋肉というのをやっていて、そこで、介護補助で支えるときや、障害者の歩行に、その人工筋肉を使うというお話をやってました。

 これがあると、らくらく持ち上げられたり、歩けるようになるという話です。
 で、今、人工筋肉の動きをパソコンで制御しているんですけど、番組では「将来は、それをチップ化して」って話でしたけど。。

 人によって、背の高さ、肩幅、いろんな違いがあるわけで、それを一律にチップにしてしまうと。。たいへんなような気が。。老人や子供というのは日々変化していきますし(老人の場合は、できたものができなくなってくる)。。。

 それにチップにしてしまうと、新しい動作をさせるとき、また新しいチップをつくんないといけません。




 ここは、ケータイで制御して、赤外線なり、ケータイからケーブル出すなり(充電器のところか、USBか)して、ケータイで制御したほうが。。。
 ケータイなら、画面から設定できるので、それこそ、毎日でも変数を変えられるし、プログラムをダウンロードすれば、新しい動きにも対応できるし、なんか特定の動きをさせる場合、選ぶことも可能。。

 とくに、いまはパソコンなので先生しか使えないけど、ケータイにして、分かりやすくすれば、その介護の人や障害者の人自身が、自分に合ったように変えられるし。。




 さらに、ケータイでダウンロードする形なら、たとえば、新しいダンスを覚えるときに、その人工筋肉を付けると勝手に踊ってくれるので、それにあわせれば覚えられるとか、体育の逆上がりとかも、どのタイミングで蹴り上げるか、人工筋肉にあわせるとわかるとか。。。

 そういう教育的な利用方法もあるかも。。




 でも、そうしたら、一番メリットをうけるのは、人工筋肉の開発者でも利用者でもなく、ケータイキャリアだよね。。
 この人工筋肉を使う人は、かならず、ケータイをもたないといけない。
 これが、老人向けにやったら、いままで開拓できなかったシルバー市場に、一気にケータイが入るわけで。。
 まあ、ケータイを持っちゃったら、使うだろうから。。
 って、考えると莫大な市場だよね。。老人だけでも何千万でしょ。。そのうちの何割かでも。。いや、これを開発するキャリアによっては、いまのケータイの勢力図が変わるかもお。。(って、そこまで行かないか ^^;)




 で、この番組、提供がDocomoだし、スポンサー的にもいいんじゃあ。。とおもったけど、これをやるとしたら、プログラム的に大きな容量が使えるBREW優位。。ってことで、逆にスポンサー的にまずいのか(^^;)

P.S その番組で、歩けない子がでてきて、その子に人工筋肉を使ってたけど、たしか、以前の夢の扉で、そういう子を手術で直すという話をやってた気が。。。
 気のせいかな(^^;)(やってないかも、他番組かも 。。 ^^;)


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