グーグルって、ニシキヘビ持ち込みOKなの？？

Tokyo Headlineという、東京のフリーペーパーがあるんだけど、
そこに載っていたニュース

ヘビ持ち込みOKだったのか…
http://www.tokyoheadline.com/vol301/news09.html
によると（以下斜体は上記サイトより引用）、

米グーグルがマンハッタンに構えるオフィスで体長約1メートルのニシキヘビが行方不明となり、2日夜に無事発見されていたことが分かった。同社の広報担当エレン・ウエスト氏が明らかにした。


逃げる以前に、グーグルって、ニシキヘビ、持込OKなの。。？？
すくなくとも、アメーバニュースの同じ内容を扱った記事によると、犬はOKで、他のは許可がいるそうな。。
　無許可とも考えられるが。。許可が出ていたとも。。（＾＾；）
　どっちなんだろう。。

---

　うーん、でも、さすが、創造力のたくましいグーグルですな。。

　日本では、
・デスクにアニメキャラ（セクシー系）やグラビアアイドルの写真などを置いている男性社員がいて、女性にとっては不愉快。
（上記リンクは、リンク先より引用）
とかいう、話があけど、アニメキャラとか、グラビアアイドル程度なら、想定内だもんねえ。。。ニシキヘビって、さすがに、想定外だよねえ。。

　そーいう女性SEは、ニシキヘビならOKなのかなあ？？

　ちなみに、ニシキヘビの飼い主の従業員は

仕事中も一緒に居たいと考えビル内に持ち込んでいたという。

　ことだから、仕事中もニシキヘビが、きっと見えるところにいたわけで。。
　うーん、どっちかというと、ニシキヘビより、アニメキャラのほうが、不快感は少ないと思うけどなあ。。ちがうのかなあ。。

　あ、ちなみにその、ニシキヘビ、アメーバニュースによると、毒はないみたい
（でも、もう、持ってこないみたいよ。。）

画面定義をHTMLで行い、呼び出しをWebAPIでやる設計手順の試案 その４ APIからER図へ

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

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

・AJAXでサーバ呼び出し、結果はXMLで受け取ったものを利用すると

・画面とサーバーが完全に分離する上に
　画面から、逆にさかのぼって要求仕様にまでもっていける
　→COBOLのシステムをＷｅｂに置き換えたいけど、ドキュメントもソースも無いときなんかに、利用できる

　で、前回、クライアントとサーバー部分を分離しました。
　今回は、そのさかのぼる話。CGIのインターフェースから、ER図を作ります。

---

■WebAPIのシートから、入出力のデータ項目をだす

　まず、いままでの作業で、

（６）でてきた呼び出したいサーバーアプリ＝サービスを、
　　　１サービス１シートで、Excelシートにまとめる。

ってことで、シートに、サービスをまとめました。
こんなかんじ


そこで（７は、前回書いたので、今回は８からです）

（８）引数を入力データ項目、返り値を出力データ項目とし、それらが、一時的なものか、それともDBなどに残しておきたい、あるいはDBからとってくるような永続的データかを決める。
→この場合、引数や返り値そのものでなくても、それらを加工した値の場合、
　そちらのほうをかんがえる。

で、永続的データだった場合、永続的なデータ項目から、ER図を作成する方法は。。
そう、第二正規形の手順でできます。

ってことで、あとは、Hello World程度のデータベース（その９：概念スキーマ（７）第二正規形の方法）
に書いてあるとおりです。
以下、まとめると。。

---

■第二正規形の手法を使って、ER図にもっていく

（９）永続的データをエンティティと属性部分に切り分けます。

　まず、データは、実際のモノや出来事（イベント）をさす、エンティティ部分と、それの属性部分にわかれます。そのエンティティと属性に分けます（エンティティは２重３重になってることもあります。受注-商品-番号など

（１０）エンティティごとに、属性を書き足していきます
　新しいエンティティは、エンティティを作ります。
　なお、あらかじめ、サービスに番号を振っておいて、属性を書き足したとき、そのサービス番号も書いておくと、後述する、検算のとき便利です。この場合、すでに属性が書いてあっても、サービス番号のみ、追加して書きます。

（１１）一意にできるものがあったら、そいつを主キー、なければ番号をつけて主キーにして

（１２）エンティティは完成

（１３）この場合、繰り返しがあったら、別エンティティにして第一正規形を行い、エンティティ内で、ある値がきまったら、必ず他の値も決まった値になるという第三正規形があったら、分けたかったら分ける。

（１４）そして今回は、参照キーの処理をしていないので、
　　　ここで、外部のエンティティを含んでいて
　　　その外部のエンティティの主キーを参照キーとして持てば、
　　　他の値は持つ必要がなければいいやつは、参照キーだけをもちます。

（１５）参照キーと主キーから関係は出ます。
　　　　カーディナリティは、主キーのほうが１、参照キーのほうは、０～N,
　　　　エンティティは（１２）で完成したので、

（１６）ER図がかけます。

---

　ってことで、ER図はでたので、これでDBなり、ファイルなりの構造は、つくれます。
　次回は、さっき書いた、これの検算になります。
　

開発の初めから順番に書いていってみる その２５：外部設計（２）要件定義から設計に落とす方法。

シリーズ「開発の初めから順番に書いていってみる」の続きです。
前回、外部設計にはいったわけですけど、そこで、

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

と書いたので、今回は、まず、説明します。

---

■要件定義から外部設計に落とす方法

手順の概要は以下のとおりです。

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


今日は、（１）から（５）まで、説明します。

---

■そのまえに

　上記の手順のところ、つまり、要件仕様から、外部設計まで落とし込む手順というのは、方法化されていませんでした。単に、分割しろ！というだけで、各種フレームワークがあって、それをつかうのですが、そのフレームワークの決定を、どの手順で、どうやって考えればいいか、考えるためにはどんな条件が必要かというのは、ウィリアムのいたずらが読んだ本や、現在の学会の主義主張のなかにも、ないと思います。
（UMLなどで、クラス図に落とし込むとかいう説明はあります。でも、なぜ、クラス図におとしこめるのか、そのための情報が足りているの説明がありません。公開されている富士通の手順も、手順はあるんですけど、情報的に、それで足りている論理的根拠がよくわかりません）。

　むしろ、ここは、佐藤氏などは、SDLCの断層といって、論理がないという考え（つまり、経験と勘でやっている）というものです。

　なので、このやり方は、今、だれかが、認めているというものではないです。
　（とくに、今回、構造化手法のDFDでできるけど、オブジェクト指向だと、論理ギャップが出るので問題！ということを書いちゃうのは。。ひょっとすると、本邦初公開かも！？）

---

■入出力の媒体をきめる

　DFDで書いた場合、１つのプロセスに着目すると、以下のようになっています。

ここで、入力の元、出力の先が、データストアであるか、プロセスであるか、などは問いません。とにかく、あるプロセスに対し、入力があり、出力があります。

　これは、DFDの前の情報関連図においても同じです（UMLでは、ユースケースもアクティビティ図も、入出力があいまいになる－あいまいにする理由がある：別の機会に書く）。

　そこで、入力の媒体、出力の媒体を決めてください。

　入力はたいてい、
　　　ファイル
　　　データベース
　　　画面
　　　他のプロセス（というか、上位プロセスがセット）
　　　　→引数や、上位のクラスの属性などがそれに当たる
　　　セッション
　などです。

　一方出力は
　　　帳票
　　　画面
　　　ファイル
　　　他のプロセス（というか、上位プロセスがセット）

　などです。これを、全入出力について、決めてください。
　（上記以外にも、HTTPで、とかメールとか、いろいろあります）

---

■その媒体ごとにフレームワークを決定する。

　（１）で、でてきた媒体をすべてまとめてください
　　（入出力、べつべつにまとめてください）。

　それぞれの媒体ごとに、入力、ないしは出力の方法を考えます。

　入力は、その媒体から（たとえば、DBから）そのプロセスにデータを渡す方法、
　出力は、そのプロセスからその媒体（たとえば、帳票）にデータを渡す方法、

　を考えます。

　ただ、たいていはフレームワークがあるので、そのフレームワークを使うことになります。

たとえば、DBの場合、
　　富士通でInterstageの場合CBS、CBM、
　　O/Rマッピングを利用する場合は、HibernateなどのORマッピングツール

画面の場合
　　Strutsやサーブレット（JSPを利用）
　　HTMLでCGI（って、フレームワークじゃないけど　＾＾；）

帳票の場合
　　どっかの帳票ツール

とかです。

　で、入出力の媒体で方法が決まっていないものがあります。
　その場合は、決めます。たとえば、ファイルなんかだったら、ファイル入出力プログラムを作成するとか、DBでフレームワークを使わない場合、JDBCで、あるクラスをアクセスとか。。

　ここで、品質を一定にさせるためには、入出力の媒体で方法が決まっていないものがある場合、そのやり方を決めてしまう、できれば、今回のプロジェクトでは、その媒体に対しては、共通の方法でやることに決めてしまう（＝フレームワーク化する）のがよいです（なお、これが、前回書いた、のりしろ分の１つになります）

---

■そのプロセスの起動方法を考える

　そのプロセスの起動方法を考えます。
　上記フレームワークにおいて、ある媒体から、入力がある場合には、起動方法が決定してしまう場合があります。

　たとえば、Strutsでやるという場合は、プロセスの起動は、画面から、ボタンをクリックされるなどで、アクションが起きたときです。このとき、Actionクラスを継承したクラスに入ります。この場合は、これでいいです。

　でも、起動方法がない場合があります。具体的には、バッチが、たいていそうです。

　その場合、起動方法部分を設計します（＝決めます）。

　この起動方法も、できれば、今回のプロジェクトでは、共通の方法でやることに決めてしまう（＝フレームワーク化する）のがよいです（なお、この「決まっていない起動方法の共通化」も、前回書いた、のりしろ分の１つになります）

---

■起動モジュールから、（２）の呼出し手順を考える

　で、起動モジュールが決まりました。
　Strutsなら、Actionクラスです。

　で、その起動モジュールから、（２）で決めた各入出力にアクセスできるか（つまり、クラスを呼び出せるか？）ということを考えます。
　たとえば、クライアント側で動くJavaScriptが、サーバーで動くセッションの値を使ってる。。。ってなったら、こりゃ、無理です。サーバーのセッションの値を、どっかにいれて(hiddenで隠すなりなんでもいいけど）JavaScriptに渡さないといけません。

　また、わたってくるけど、使いにくいという場合もあります。たとえば、コードが違ってるとか、圧縮された画像データのままとか。。
　そういう場合も、使いやすい形にすることを考えます。

　これら、無理なのを、利用できるようにしたり、使いやすくしたりして、とにかく、入出力媒体が、データの形で、起動モジュール内で呼び出し、利用可能なようにします。この手順、方法は、個別に考えるのではなく、できれば、今回のプロジェクトでは、共通の方法でやることに決めてしまう（＝フレームワーク化する）のがよいです（なお、この「起動からの呼び出しの共通化」も、前回書いた、のりしろ分の１つになります）

---

■その処理部分をどうするか、考える

　そうすると、入出力は、プロセス内で、データとして読み込み、書き込みできるようになりました。あとは、それらを使って、どう処理するかなのですが、ここで、

・処理内容を、そのまま起動モジュール（StrutsならAction継承クラスのexecuteメソッド内）に書くことも、理論上は可能です。

・そうでなくて、MVCの観点から、起動モジュールはコントロール、モデル内で処理するため、別のモジュールで動かすというのが、まあ、普通っぽいです。

・ただ、バッチプログラムは、ふつう、起動モジュール（main内）に書いちゃいますけど、それでも、mainの書き方に、いろんなとりきめがあるかも。。

っていうことで、その処理部分を、どうするか（そのまま書いちゃうか、別モジュールにするか、さらには、処理プロセスのコーディング規約とか）を考えます。

　なお、別モジュールにした場合、そのモジュールで、上記で検討した入出力テータが利用できるかどうか、検討しないといけません（たとえば、セッション情報を、モデルに渡さないと、モデルでセッションに入っている情報が使えない。そこで、セッションを渡すのか、それとも、Action側で、その情報を取り出して渡すのか、取り出すにしても、入っている情報全部取り出すのか、必要な情報だけかなどなど。。）

　処理部分に関しては、できれば、今回のプロジェクトでは、共通の方法でやることに決めてしまう（＝フレームワーク化する）のがよいです（なお、この「処理部分の共通化」も、前回書いた、のりしろ分の１つになります）

---

■ここまでで、論理的に説明でき照るか振り返る。

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

　これで、
　　入出力とプロセスを、フレームワークなどつかって
　　　（ない部分は共通化してつくって）
　　　全部詳細化、展開することができ、

　　さらに展開されたものは、
　　　　入出力部分に関しては、フレームワーク
　　　　　　　（ないしは共通化して作ったもの）なので、
　　　　　そのフレームワーク（ないしは共通化部分）が
　　　　　　　ちゃんと動くなら、動く
　ということになります。

　つまり、動くか動かないか分からない部分は、
　　・固有化された処理部分
　　・共通化して作った部分
　　・フレームワークの利用方法の勘違い
　となります。このうち、「固有化された処理部分」は、”（７）処理部分を、ワーカーさんに渡せるまで落とし込む。”で説明します（次々回になります）。
　「共通化して作った部分」と「フレームワークの利用方法の勘違い」の動作保障に関しては、プロトタイプの問題になります。これは、要求分析でも書いたのですが、外部設計でもまたかきます（ただし、ずっと後になる予定です）

---

　ということで、このシリーズの次回は、「そうすると、細分化された入出力、処理部分ができる。ここで、あわせたいものは、あわせる」について書きます。

ケータイによる介護、障害者の補助機器の制御が”BREWだと”できそうといった理由

　昨日、人工筋肉で介護補助・障害者補助をするのにパソコンじゃなくて、ケータイで制御したら？ってのを書いてから、なんか、介護機器メーカーや医療機器メーカーの開発関係者と思われる人が見ている件数が、明らかに多いので、具体的に問題になりそうな話しとか、ちょっと、付け足して置きます。

---

■赤外線通信とかはあるんだけど。。

　ケータイで、そのような介護機器など（人工筋肉もその１つ）を制御しようという場合、

　いや、介護機器にかかわらず、
　　　　ロボットやリモコン玩具？の制御、
　　　　忘れっぽい人のメモを出すとか
　　　　（あ、それは自動的にケータイにメールすればいいだけか　^^;)
　いろいろなもので、


　　「ケータイから、赤外線ないしは、なにかの信号をだして、それを機械につなぐ」

　ということは、考えられる。
　で、この操作をできるインターフェースは、Docomoにも、auのBREWにもある。

---

■でも、これを保持しておく領域が問題

　でも、この制御データを保存しておくところが問題。
　Docomoのiアプリでは、メガアプリを使っても数メガなんです。

　ところが、BREWだと、（以下、守秘義務に触れるとまずいので、公知の事実以外、想像の形式で書きます。実際にやる人は、確かめてください。誰に確認するかは、最後に書きます）

　こんなこともできる。。のかもしれません。想像ですけど。。

・BREWは、miniSDなどのメモリカードにも、アクセスできるかもしれません。
・さらに、プログラムエリアも、１つのアプリで使える領域も、ずっとずーっと
　数十メガぐらい大きい。。かもしれません。。（想像ですよ　＾＾；）

　ってことで、まあ、想像が正しければ（＾＾；）いったん、データをとってきて、それをプログラム領域や、miniSDに保存してしまうということが、可能になってきます。
　これなら、かなり大きなデータ容量も保存できるし、miniSD経由でのデータ交換もできるかもしれません。

---

■ただし、BREWには、アプリダウンロードの制限がある。。けど。。

　でも、BREWのアプリをダウンロードするためには、特定のサーバーから、ダウンロードしないといけません。特定のサーバーにアクセスするには、BREWのアプリをau(KDDI）に承認してもらわないといけない（ここまでは、公知の事実）。

（ただし、開発用には、サーバーをアクセスしないで、直接書き込める方法がある。。かもしれない、想像ですよ　＾＾；）

　なので、勝手にアプリをつくることができないのです。
　じゃあ、動きごとに、アプリを作って。。承認。。？たいへんです。

---

■データをあるサーバーから、ダウンロードしてくる形にすればいい。

　でも、（もしやる場合にはメッセージとか出さないといけないかもしれないけど。。想像です。。はい）HTTPアクセスはアプリから可能です。
　ということは、

・制御したい機器に、赤外線とか、USBとかで、信号を送り出す基本的な部分をBREWアプリとして、これを承認してもらい、

・制御するための、基本的なデータ（なにを、どのくらい動かす）っていうものは、どこかのサーバーにテキストデータみたいなかんじで置いておいて、

・そのBREWアプリからHTTPサーバーにアクセス、ダウンロードしたら、

・アプリ領域、場合によってはminiSDに書き出せばいい

・動きをかえる、人によってカスタマイズとかは、そのHTTPサーバーに置く、基本的なデータのほうをかえればよい。

・で、アクセスするHTTPサーバーのURLだが、アプリ固定埋め込みでももちろん結構だが、miniSDに書き込み、それを読み込む形にすれば、パソコンからminiSDはアクセスできるので、人によって変えられる（そもそもminiSDに基本的な動きのデータを入れておいてもいいけど）・・・

ってことで、BREWなら、領域的に、できそうだし、
　データに動きを記述し、それは、HTTPないしはminiSD経由で送って、
　BREWアプリはそれを読んで制御するようにすれば、アプリ自身の書き換えは、
　あんまりないのでOK。

---

■ってことで、じゃあ、どうするかなのだが。。
　で、その、想像の部分ができるかどうかについてなのだが、これ以外にも、赤外線や外部インターフェースアクセス、などについては、資料をもらわないとわからない。

　この資料をうけとるには、まずBREWのアプリの企画をエントリしないともらえない。
　で、エントリは（たぶん、今でも）個人はダメ。会社はOK、学校は、わかんない？？

　とにかく、ここにアクセス！

BREWアプリ
http://www.au.kddi.com/ezfactory/service/brew.html
の、「公式コンテンツプロバイダとなってEZアプリ（BREW）を提供したい！」

　ってことになる。

なお、その上にある、BREWバージョンですが、上記のことができるのは
じゃなかった、できると、想像されるのは、
BREWバージョン３．１以降（今出ている、W5XシリーズはみんなOK）。
それ以前のは、ファイル容量の問題とか、miniSDのアクセスは？？
とかの、制限が、あるかもしれない（想像ですよ　＾＾；）

P.S　誰に確認するか－エントリ後、分かる仕組みになっている。