ケータイをＤＳみたいにタッチパネルにしたら、ゲームだけでなく教育にも？

ニンテンドーＤＳのタッチパネルを日本写真印刷が作っているっていう話、
日経ビジネス２００７年４月１６日号（特集が「新聞に載らない、アナリストも見ない　隠れた実力派１６０社」の号）の３４ページの記事をみていて思ったんだけど、

タッチパネルって、ケータイについたら、面白そうですよね。

たしか、iPhoneの場合、タッチパネルで、通話するときが問題だったっていうのが
なにかで読んだ気がするけど。。。
ただ、ＢＲＥＷで使うとしたら、そもそも、通話の割り込み（イベント）が来た時点で、
通話側に制御をわたすので、耳がタッチパネルに触れても、アプリには関係ないだろうし。。
（ごめん、マジメにロジック追ってないから、問題になるケースがあるかも？？）

ケータイがタッチパネルになると、文字を書いて入力が出来たり、お絵かきができたり。。
っていうことで、ゲームだけでなく、教育などにも使えるかも。。

そーすると、ＣＡＩのＯＳ部分をＢＲＥＷアプリにして、実際のコンテンツは、それこそ前に書いたようにＳＤカードにいれるか、ＨＴＴＰでサーバーから落としてくるってなるのかなあ。。

ニンテンドーＤＳのＯＳをＢＲＥＷ移植、
カートリッジをＳＤカードには
。。。さすがに無理か（＾＾；）

オブジェクト指向分析とアジャイルとテストファースト

　以前書いた「オブジェクト指向分析（開発）の存在理由」という話のつづき。

　今までの話をまとめると、

　DFDは入出力とプロセスの関係が明記してあるので、ここから、プログラム可能なものに落としてくることはこんなかんじでできる。
　しかし、これは逆に言うと、入出力されるデータ構造が決まらないと、落とし込めないという欠点を持っている。

　それに対して、オブジェクト指向は、入出力データがはっきりきまらなくとも、そこに出てくる登場人物と、交換されるモノ程度がわかれば、とりあえず、それをエンティティとして。。。プログラムできるといえるのか？っていうところでした。
　今回は、プログラムできる（UMLのユースケース図からクラスに落とし込める）という根拠を示すとともに、その結果、

　オブジェクト指向分析
　　　↓
　アジャイル
　　　↓
　テストファースト

という流れになってしまうことを示したいと思います。

---

■UMLで落とし込む場合の考え方の根拠

　ユースケース図の場合、プロセスは、ユースケースにあたります。これは分かっています。
　データは、外部入出力と、プロセス内部での入出力です。
　外部入出力部分は、アクターがいるところです。
　ここでアクターは、どういう情報を入力するか、出力して欲しいかがわかっているとします（これは仮定です。なんとなくアクターをかかれると、アウトですが。。）
　ということで、外部入出力は、エンティティレベルでは、仮にOKとします。
　そこで、このエンティティに対応するクラスを作りましょう。

　内部入出力を、永続性という観点から考えると、永続性のあるものと、ないものに分けられます。
　永続性のないものは、プロセス間で利用するだけですので、これは、セッションのように、一時的な共有置き場に、エンティティごと入れてしまうとします。
　永続性のあるモノは、DBの中に入れておき、必要なときに取り出したり、作成・削除・変更したりするとします。

　これらの操作はエンティティ１つにDBのテーブル１つを割り当て、さらにクラスも１つ割り当て、そのクラスが取り出したり、作成・削除・変更のメソッドを持つとすると、クラス呼び出しで、OKとなります。
　そして、DBアクセス情報は、上記の「永続性のないもの」で受け渡した共有置き場にいれておきます。

　そうすると、

　　クラス
　　{
         メソッド１（共有置き場データ）
　　　　　｛
　　　　　　　　　　DBアクセス
　　　　　｝

         メソッド２（共有置き場データ）
　　　　　｛
　　　　　　　　　　DBアクセス
　　　　　｝
　　　　　　　：
　　　　　　　：
　　｝

　
　という形に帰着するということになります。

　ただ、これはやりすぎなので、実際には、

　　クラス
　　{
         メソッド１（このメソッドで使うエンティティ１，２・・・）
　　　　　｛
　　　　　　　　　　共有置き場データアクセス
　　　　　　　　　　DBアクセス
　　　　　｝

         メソッド２（このメソッドで使うエンティティ１，２・・・）
　　　　　｛
　　　　　　　　　　共有置き場データアクセス
　　　　　　　　　　DBアクセス
　　　　　｝
　　　　　　　：
　　　　　　　：
　　｝

　

　というところで落ち着かせるということになるでしょうが。。

---

■こういう手法がないとWebAPIとかは成立しない

　この手法の応用がWebで利用されるAPIになると思います。

　メソッド１（共有置き場データ）

　の「メソッド１」の部分が、CGIなど呼び出されるサーバー側サービス、
　共有置き場データのところには、引数が入るのですが、これが、URLエンコードされた文字列という、だれでも利用可能な型（文字列）で表現されてます（＝入れ物に入れられている）。

　もし、WebAPIが、利用者すべての入出力を決めてからつくるとか言い出したら、永遠に決まりませんが、とりあえず、URLで、メソッドをきめて、どんな引数でも文字列で表現して、文字列のなかに入れ込んでしまうことで、
　あとで引数が拡張されても、受け取った引数の入れ物（文字列）自体は変わらないので、前の引数をいじらなければ、現状動いているものには、問題ない。

　なので、とりあえず、今必要なものだけ定義して、動かすということを可能にしています。

---

■オブジェクト指向はアジャイル、テストファーストに続く

　で、なんでオブジェクト指向を採用したかというと、はじめ、仕様がはっきり分かってないからでした。もし、入出力と変換方法が確定しているのであれば、DFDから落としていったほうが、一回できまるので、こっちのほうがいいです。

　仕様がわかんない上、たいていこういうのは、作ってみないと分からないというケースです。ということで、何度も作り直す、アジャイル的な開発が好まれることになります。

　でも、作り直す間、ずーっとテストしなかったら、品質は保てません。
　ということで、作り直しがあるケースでは、作った部分をテストして、その部分は品質を保つということをしないといけません。なので、テストファーストってことになります。

---

次回のこのシリーズって（シリーズなのか？）では、「オブジェクト指向、アジャイル、テストファースト」に流れる、一つの信念について考えます。

開発の初めから順番に書いていってみる その２９：外部設計（６）フレームワークで速度が決まる

シリーズ「開発の初めから順番に書いていってみる」の続きです。
（なんか、最近シリーズ化している話がやたら多いですね！一番最後にまとめときました）

今、外部設計の段階で、要求仕様から、詳細設計までの間（ここを外部設計と、ここでは読んでいるわけですが）の手順は、以下の手順で行うと、流れに飛躍がなく説明がつくということを書きました。

（１）入出力の媒体をきめる。
（２）その媒体ごとにフレームワークを決定する。
　　　なければ、入出力方法を決定する。
（３）そのプロセスの起動方法を考える
　　　なければ、起動モジュールを考える。
（４）起動モジュールから、（２）の呼出し手順を考える
（５）その処理部分をどうするか、考える。
（６）そうすると、細分化された入出力、処理部分ができる。
　　　ここで、あわせたいものは、あわせる
（７）処理部分を、ワーカーさんに渡せるまで落とし込む。

だけど、実際にやられるのは、こんなかんじだと書きました。

（あ）フレームワークの確認から、全体的なプログラムの書き方を決める
（い）画面の設計をする
（う）ＤＢの設計をする、（その他外部の設計をする）
（え）プログラムを適当に詳細化し、詳細設計に持っていく

今日は、「（あ）」の部分のフレームワークについて、書きたいと思います。

---

■はじめに、フレームワークを決定するのですが。。
　外部設計に入る一番初めの作業は、フレームワークの決定。。と書きたいところなのですが、実は、外部設計に入る前に、何をハードで使うかとか、フレームワークは何をつかうかっていうのは、たいてい決まっています。

　要求仕様の段階っていうか、そもそも、こー言うハードを使ってっていうかんじで、見積もりをかいてしまい、さらに、この会社で受注すると、開発標準がこれなので、フレームワークはこれ！って決まってしまいます。

　ってことで、その内容を確認する程度の話になります。

　そして、プロジェクトごとにフレームワークをカスタマイズするところがあればカスタマイズ、入出力に関して共通処理をする部分があれば、そこの部分の内容を決定するという作業をおこないます。

　その結果、全体的なプログラムの書き方がきまります（というか、決めます）。

　そして、その「全体的なプログラムの書き方」を、
　　　コーディング規約か
　　　雛形作成
　で示します。

---

■でも、フレームワークや、ハードなどで、処理スピードは、きまってしまう

　フレームワークを決定するということは、この段階で、ハード、ミドルウエアそしてフレームワークが決まってしまうことになります。
　実は、これがそろってしまうと、大まかな処理スピードやユーザーインターフェースはきまります。

　ブラウザをつかって行う場合、なんとなくユーザーインターフェースはきまりますし、
　J2EEで開発する場合、ハードが決まると、ある程度の処理スピードの限界って言うものが決まってしまいます。ハードを変えない限り。。

　ということで、ここで、選択を誤ると、あとあと、たいへんなことになります。
　というのは、前に開発マシンの話をかきましたけど、
　開発環境≒実行環境のときはいいんです。

　開発環境の性能がいいと、実行環境で起動したら遅いのに、開発環境では問題なしだと。。

　ずーっと開発が進んできてしまい、最後STで、

　　　だめじゃん、おそいじゃん（＞＿＜！）

　ってなったら。。。

　フレームワークで骨格が決まってしまいますので、この外部設計のフレーム決定までもどってきてしまうことになります。開発のかなり多くの部分がむだになります（実際には、それはできないので、この場合、ハードの性能を上げる。その費用負担は。。）。

　ってことで、フレームワークのこの作業は重要。。。といいたいのですが

　さっきも書いたように、ここに来る前に、もう、フレームワーク、ハード、ミドルウエアはきまっているので、この時点ですら、もうおそいのかもしれません。

---

■つまり、副詞的環境の一部と、非機能要件は、ここできまる

　つまり、非機能要件のルック＆フィールとか、副詞的世界の「どのくらい」などは、ここできまります。（いつ、どこでというのは、ここでなく、もちょっとすすんだところになりますが。。）

---

　ということで、フレームワークが決まり、だいたいのやり方が決まったところで、次回は「（い）画面の設計をする」になります。




P.S　初めに書いた、つづきもののまとめ（一番最新のエントリ）

開発の初めから順番に書いていってみる
＝このエントリが最新

オブジェクト指向分析（開発）の存在理由
http://blog.goo.ne.jp/xmldtp/e/cc66277f9476fa272f0ff63b032be9d1

画面定義をHTMLで行い、呼び出しをWebAPIでやる設計手順の試案　その４　APIからER図へ
http://blog.goo.ne.jp/xmldtp/e/42e53e86aa37cca498930fc9461d0e63

生物の構造と、要求から、プログラムまでの階層を比較すると、わかりやすいかも！
http://blog.goo.ne.jp/xmldtp/e/f7861ca7db024bb6a2994d56c1f42812

＜＜土日シリーズ＞＞
土曜日
ＤＴＰの構造を考える－その３：組版規則など。
http://blog.goo.ne.jp/xmldtp/e/8f5d0e3f454ff68e110c3da2a26cbc88

日曜日
Hello World程度のデータベース（その１５：内部スキーマ（３）データ置き場）
http://blog.goo.ne.jp/xmldtp/e/04e95852ec320210abd56720c84ba2b4

生物の構造と、要求から、プログラムまでの階層を比較すると、わかりやすいかも！

　 土曜日に、要求から、プログラムまでの階層を考えないことが、開発の混乱を招いているというのを書いたのですが、それと、生物の構造を比較すると、分かりやすいと思うので、今回かいてみました。

　ただ、ウィリアムのいたずらは、高校講座地学は、平野麻樹子さんの、軽快な娯楽番組？としてみているのですが、高校講座生物は、ちゃんとみていないで、生物、あんまり詳しいとは言い切れないので、まちがってたら、ごめんなさい。。。（＾＾；）

---

■要求から、プログラムまでの階層

　で、今回の話の前に、その土曜日の書いた内容。
　要求からプログラムまでの落とし込みは、下記のとおり。

業務
　｜＊１
アクティビティ層（＝アクティビティ等）
　｜＊２
基本操作群
　｜＊３
ＯＳ／言語提供モジュール

で、 ＊１、＊２、＊３の部分が、階層間の変換作業＝開発の作業になります。

具体的には、

＊１：　要求分析
＊２：　外部設計
＊３：　内部設計＆プログラミング

っていうことです。

まあ、実際には、こういうレベルわけをちゃんとしてないので、開発上で問題が生じるんですけどね。。

---

■生物の構造

　一方生物を考えると、生物は、胃、肺、肝臓などの臓器（器官）からできています。
　で、肝臓は、肝細胞、皮膚は皮膚細胞など、器官に応じた細胞からできています。
　細胞はたんぱく質からできています。
　たんぱく質は、アミノ酸からできていて、
　このアミノ酸をつかって、たんぱく質を作る作り方が書いてあるのが、DNAでした。

　そして、細胞は、たんぱく質からできているのですが、真核細胞（核をもつ細胞）においては、葉緑体、ミトコンドリア、ゴルジ体など、細胞の中に（たんぱく質よりずっとまとまった構成要素として）、細胞小器官とよばれる、さまざまな器官があります。

　また、細胞内の形をきめたり、物質を送るレールとして、細胞骨格というのがあります。

まとめるとこんなかんじ。。

臓器
　｜
細胞
　｜
　｜　細胞小器官・細胞骨格
　｜
たんぱく質
　｜　　＜＝＝ここの変換方法を書いたのがDNA
アミノ酸

っていうことになります。

---

■これを、要求分析からプログラムまでの階層と比べると

で、さっきのプログラムとの階層とくらべると、

臓器	＝＝＝	業務
	｜
細胞	＝＝＝	アクティビティ
	｜
たんぱく質	＝＝＝	基本操作群
	｜
アミノ酸	＝＝＝	ＯＳ／言語提供モジュール

というように対応付けられます。
たんぱく質をアミノ酸で作るつくりかたがDNAに書かれているように、
言語の関数から、基本操作の記述は、ソースコードで行われます。
ただし、たんぱく質から細胞の構造がDNAに書かれているわけでは”ない”のに対し、
ソフトの場合は、基本操作からアクティビティまで、ソースコードとしてかきます。
この問題や発展の可能性は、今後、別の回で書きます。

---

■細胞小器官・細胞骨格に相当するのは？

では、「要求分析からプログラムまでの階層」において、生物の「細胞小器官・細胞骨格」にあたるものは？というと。。

　ライブラリと、入出力（プロジェクト用にカスタマイズした状態）のもの

が、それに対応するといえます。
＊ここでいう、ライブラリとは、プロジェクト共通で使う、共通部分のクラス、関数などであり、一般に言う、各言語のライブラリとはちがいます。各言語のライブラリは「言語提供モジュール」そのものです。

---

■個別性と普遍性の間

　まず、たんぱく質は、他の生物で作ったたんぱく質でも、同じ名前のものなら、まあ、大体同じような化学的性質をもっていると考えられます。
　つまり、生物間共通、普遍性があるといえます。

　一方、細胞の場合、人の皮膚細胞と、馬の皮膚細胞では、おなじかというと。。？？疑問です。つまり、生物間で共通とは言えず、個別性があります。

　まとめると、
　　　たんぱく質＝＞普遍性
　　　細胞＝＞個別性（ただし、生物が違っても同じ目的（皮膚など）というのはある）
　っていうことになります。

　で、細胞小器官・細胞骨格っていうのは、この中間になるかと思います。

　ライブラリと、入出力っていうのは、プロジェクト内では、まず共通のやり方をしますが、プロジェクト外では違うかもしれません。プロジェクトごとにやり方が違うことが考えられます。ということで、

　個別的なアクティビティ（細胞）と、普遍的な基本操作（たんぱく質）の間、ってことで、”ライブラリと、入出力”は、細胞小器官に該当すると思います。

　で、とくに、ライブラリの一種、あるいは入出力に結びついているフレームワークは、そのアクティビティのプログラムの骨格を担っていたり、データの流れを担っているので、細胞骨格に相当するということになります。

---

　ってことで、一通りの対応ができました。こんなかんじ

臓器	＝＝＝	業務
	｜
細胞	＝＝＝	アクティビティ
（細胞小器官・細胞骨格）	｜	（ライブラリと入出力）
たんぱく質	＝＝＝	基本操作群
	｜
アミノ酸	＝＝＝	ＯＳ／言語提供モジュール

　なお、土曜日までは細かく分けてなかったので「入出力と基本操作」というように書いてましたが、今回のように、基本操作より上、アクティビティの下、ライブラリと同じ程度がいいとおもいます。

　ということで、今回の話題は、ここまで。