ETみたいに指からケータイの番号が送れる？

すごいです。すごいです！松丸アナのトレンドたまご
（って、いつも言ってるけど、松丸アナがすごいわけではないが）
月曜日、松丸アナがやっていたトレンドたまご
レッドタクトン
http://www.tv-tokyo.co.jp/wbs/toretama/070514.html

なんですけど（以下斜体は上記サイトより引用）

ＩＤカード自体が電界を発していて、カードを身につけた人は身体全体にその電界を帯びる仕組み。電界にはパスワード情報がのせられていて、身体が受信機にふれるだけでロックを解除できる。


じゃあ、パスワード情報のかわりにケータイの電話番号にすると、
体、つまり、指が受信機に触っただけで、ケータイの電話番号がつたわるってことですよね。

　つーことは、相手が指の先に受信機を付けていれば指先が触れただけで、情報が伝わる。。

　もしこれ、相手の人にも、触れば電界が伝わるのであれば、
　ETみたいに、指と指が触れただけで、ケータイの電話番号が送れる・・

　そーだとしたら、すごいです。

　もしそうなら、合コン用として、NTTドコモが目を付けそうだ。。
　なんか、合コンがしやすくなるケータイとかなかったでしたっけ？
　もっと進んで、体を触る口実を作るケータイとかして。。

プチ障害者向けのユビキタス市場

　本家に書いた動けない人のための。。。音声入力？ 続きでもあるんですけど。。

　ユビキタスというと、ネット家電なんかが中心となっている。

　これは、健常者の、金持ちが増えていけば、儲かっていく市場かもしれないけど、高齢者が増えて行ったりすると。。利用者は少ないよね。。

　「外出先から。。」

　とか、

　「外出から帰ってきたら。。」

　とかいっても、そもそもお年寄りで外出しないような人が増えてしまったら、あまり意味がない。

---

　そうやって考えると、身体障害者まではいかないけど、体が不自由な高齢者とか、一時的に怪我しているので、からだが不自由な人のための入力装置やロボットなどの市場っていうのがあるんじゃないかと。。

　身体障害者までいってしまえば、バリアフリー用に家を改築とかなるんだけど、

・そこまで障害が行ってない、
・バリアフリーのお金がない
・そもそも、怪我なので、工事中に直ってしまう。。

などという人（これらの人を仮に「プチ障害者」と呼ぼう）のために、物を取ってくるロボット（ラジコン？）とか、キーボードをたたかなくてもいいための音声入力とか、階段の段差を一時的に埋める機械とか。。。

　もちろん、障害者の方が使っても役に立つし、
　障害がない人が使っても、便利とか、楽しいっていう

そういった、「プチ障害者向け」グッズの市場って、あると思う。

プログラムやテストデータを自動生成する方法 その６ DBの例 その１－仕様

　雛形ソースを作成し、Excelの仕様書を用意すると、プログラムのソースやテストデータを生成する方法について説明するシリーズ、「プログラムやテストデータを自動生成する方法」です。

　第二回目でインストールをしました。
　それから５回目までで、概要を説明しました

　今回から、それを使った例について説明します。

---

■なにをやるのか？

　これから、データベースの仕様書をもとに、
　　　　・テーブルを作成し
　　　　・入出プログラムを自動生成し
　テストデータも入れてもらったら
　　　　・テストドライバも作成し
　　　　・試験項目書も作成し
　　　　・データをいれるSQLを作成する
　なので、あとは、テストを実行して、結果を入れればいいだけ。。
（ちなみに、結果も技術的には自動生成で書き込めますが、それはいけないみたいです。人はそれを捏造と呼びます。はい）

　ということのさわりの部分、「テーブルを作成し」のところをやります

　なお、それ以外の部分や全体像に関しては、開発の初めから順番に書いていってみるの「自動生成」関連（もうちょっと先です）で、書くと思います（忘れていなければ）

---

■仕様

　で、その仕様書から、テーブルを作成、具体的にはテーブルを作成するSQLを書き出すという話なのですが。。

以下のような、仕様書

（上記の例の場合、シート名は「ユーザーテーブル」にしてあります）
をもとに、
以下のようなSQL

CREATE TABLE userTBL (
  name VARCHAR(50) NOT NULL,
  pass VARCHAR(50) ,
  auth INTEGER ,

  PRIMARY KEY(name)
); 

を作成します（今回はusertblsql.txtというファイルだとします）。

こうすれば、たとえばmySQLであれば、データベース名がtestdbだとすると
mySQL testdb -u root -p ＜ usertblsql.txt
（＜は、本当は半角です。半角で入力してください）
とすると、rootのパスワードを聞いてくるから、それをいれると、
テーブルが作成できます。

---

　次回から、実際に、なにを作成して、どうするかについて書きます。

開発の初めから順番に書いていってみる その４４：プログラミング（６）条件分岐２ 問題点。

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　設計手順には、要求分析、外部設計、内部詳細設計・プログラミング、単体テスト、結合テスト、総合テスト、運用テスト及び運用とあります。
　現在プログラミングで、条件分岐のお話です。

　昨日、条件分岐の位置づけと、その体系をこんなふうにまとめました

＜＜プログラム＞＞
・次の文を実行するか、
　・どこかにジャンプするか、
　・そこで終了するか
　・条件によって分かれるか、
　　　　・条件（IF文）が１個
　　　　・複数の条件がある
　　　　　　　・条件が１つしか成立しない(select case)
　　　　　　　・条件が複数成立してしまう
　　　　　　　　　　　・条件が成立したら、実行（マルチアンサー）
　　　　　　　　　　　・条件から状態を決めて実行（シングルアンサー）

で、「条件が複数成立してしまう」場合、「条件が成立したら、実行」する場合は、スイッチを使ってはじめ、スイッチオフにしておいて、条件が成立したらスイッチONにすれば、いいので、これはいいんですけど、「条件から状態を決めて実行」の場合、条件を決めるのに、

・１つは、elseifを並べる場合
・もう１つは、ifを並べる場合

の２つを示しました。この場合、条件の厳しいものを、elseifだと前に、ifの場合は後ろに並べないとおかしくなる（条件の甘いものに先に引っかかってしまい、条件の厳しいものが、正しく判定できなくなる）ということを書きました。

　今日は、その問題点です。

---

■問題点　その１：条件が厳しいかどうか分かりにくい

　条件の厳しさというのは、複数条件が多くかぶさっているほうが厳しそうに見えますが、必ずしも双とはいえません。

　たとえば、
　３の倍数でかつ５の倍数
　　　は条件２つですが、
　３０の倍数
　　　は条件１つです。
　でも、実質は３０の倍数のほうが条件きついです

　これは、３０の倍数＝３の倍数でかつ５の倍数でかつ２の倍数

　だから、実質条件は３つだからなのですが、
　上記の例のように簡単に判る場合はいいのですが、ちょっと分かりにくくされてしまうと、どの条件が厳しいのか分からず、結局、どう並べたら。。って言うことになってしまいます。。。

---

■問題点その２　仕様書と合わなくなるケースがある

　仕様書を書く人が、上記の件を意識して書いてくれればいいのですが、そうでないと、適当に並べます。ふつう、おおくあるのは、

　条件の甘いもの　→　きびしく　　→で、それらに合わなかったら。。

　っていう風に書きます。なので、elseifを使う場合は

　きびしく　→　甘いもの　→　で、それらに合わなかったら。。
　
ってひっくり返して考えます

　また、if文の場合は

　　合わないケースを初期値→条件の甘いもの　→　きびしく

　っていうふうにします。

　でも、これ、どっちにしても、順番がかわってしまい、とくに、elseifのほうは、ひっくり返すので大きく順番が変わってしまいます。
　その上、上に書いたとおり、条件の甘さ、厳しさは、わかんないときもあるのにです。。（つまり、ひっくり返したつもりが、甘い条件が前に来てしまうこともありえる）

●ちなみに。。。

　この前FizzBuzz問題のときたぶん、意図的にこの順番にしていると書いた理由は、はじめに「数字をプリントし」と、デフォルトの条件を書いてきているから。。ふつう、このように「それらに合わなかったら」というのは、最後に書く。それをあえて前に用に書いているのは、これを知っていてやっているように見える。SEは、これを知らないと、仕様書とプログラムが合わなくなるので、知っている人も多いと思います。

---

■問題点その３　順番を勝手にひっくり返すといけないケース等ある

　順番をひっくり返したりちゃいけなかったり、
　elseifにしちゃいけなかったり
　if文で最後まで条件をチェックしちゃいけないケースがあります。
　（if文でも、条件が成立したらreturn,breakさせて、
　　最後まで条件をチェックしない方法もあります）

例：
売り上げ１００００円で、ブロンズ会員＝１０％引き
ブロンズ会員が売り上げ２００００円でシルバー会員＝２０％引き
シルバー会員が売り上げ３００００円でゴールド会員＝３０％引き

で、３０１００円の売り上げを上げたとします。

この人は、
if (シルバー会員で売り上げ３００００）

elseif（ブロンズ会員が売り上げ２００００円）

elseif（会員でない人が１００００円）

と聞くと、この人は、今会員でないので、ブロンズ会員になります。

でも、

if (売り上げ１００００円で)
ブロンズ会員

if (ブロンズ会員が売り上げ２００００円)
　　シルバー会員

if (シルバー会員が売り上げ３００００円)
　　ゴールド会員

ってやると、この人、このつきでゴールド会員になってしまいます。
これ、どちらのケースもありえます。

また、マルチアンサー方のものと絡んで、たとえば、人を紹介すると１人当たりブロンズは５００円引き、シルバーは１０００円引き、ゴールドは１５００円引きで、それを売り上げから引いた値で会員を決定する。。とかとかになってくると、仕様書どおりに組まないとわけわかんなくなります。

---

■問題点その４　処理がかかわってくると、条件を聞く順番が重要になる

　で、上記のケースと関係して、処理がかかわってくると、条件をチェックする順番が大切になります。さっきの場合も、

if (売り上げ１００００円で)
ブロンズ会員

　のとき、ブロンズ会員の昇格処理をここでしないと、その人はブロンズ会員にならないので、３０１００円買っても、シルバー会員にはなれません。

　また、値引き処理を先にしてしまうと、シルバー会員になった時点で２０％引き、なので、３０１００円－２０％（６０２０円）＝２３９８０円として、この値引き金額で判定すると、ゴールド会員になれません。

　どちらのケースもありえますので、できるだけ仕様書に合わせた書き方のほうがいいわけです。

　なお、このような計算順番で、大きく変わってくるのに、税金の計算があります。四捨五入が入るので、かけてから割るか、割ってからかけるかで大きく違います（例：所得税の中間納付）

---

■条件を全部出す－決定表

　処理が絡んでいる場合はだめなのですが、これを避ける方法として、

　あらかじめ、すべての条件を、ダブりなくだしてしまい、
　それれに対応する処理を決定してしまえば

　すべての条件をダブりなく網羅している、つまり、１つの状態しか選べないのですから、これは、「条件が１つしか成立しない」状態と同じになります。

　この方法で記述されたのが、決定表です。

　決定表は、
・全部の条件を複合していない１つの条件に分けて
・それのYNを、樹形図みたいに書いていって
・最後にそれをまとめてYN・・・の列にすることで、
　すべての条件をダブりなく網羅しているようにします。

　しかし、決定表は、条件N個に対して２のN乗の選択肢ができます。
　だから、条件が５個あれば、２の５乗＝３２個、まあ、ここならOKですが
　条件が１０個あれば、２の１０乗＝１０２４個、これは、無理っす（＾＾；）

　また、途中に処理が入ってしまうと。。ってことがあります。

---

■で、どうするか

　ということで、仕様書の書き手が、この条件分岐の方法を意識し、プログラマのほうと一緒に、仕様書をできるだけ崩さない書き方にして、合意をとるお客さんとも、意識の差がないような手段を講じないといけない（その場でとっていかないといけない）ということになります。

　その１つとして決定表を使って網羅してみるとか、
　具体的な値をいれて、シナリオをつくってみるとか。。

　ま、いろいろあるわけです。

---

　で、これで、条件分岐の話はおわりです。
　（決定表の自動生成に関しては、あとでまとめてします）