「日産とドコモが携帯GPSを用いた交通事故低減技術を開発」って、画像処理のほうが？？

ここのニュース
日産とドコモが携帯GPSを用いた交通事故低減技術を開発
http://slashdot.jp/mobile/07/04/18/1445245.shtml

うん？ＧＰＳって、そんなに反応早かったっけ（宇宙の衛星からの電波利用するんだよね）？
飛び出したら？（飛び出すのが危ないんだよねえ。。）
まあ、そもそも、ケータイ持ってない人は？とか、いろいろ問題ありそうだけど。。

そもそも、人だけじゃなく、電信柱だろうが、建物だろうが、なんでも、ぶつけちゃいけないわけだから、車からレーダーを発射して帰ってくるのを見たほうが（＝魚群探知機の原理）。。。はやくない？？

っていうか、たしか、無人走行の車のレースっていうのをアメリカでやってたような。。
あれはたしか、先のほうの写真をとって、画像処理していた気がする。。
技術的にいまや、画像から人の抽出とかできるわけだから。。。
っていうか、それ、レースでやっているくらいだから、
そっちのほうが実用性高いんじゃないかなあ。。
暗視カメラとか使えば、夜中でも大丈夫そう。。。

---

それよりも、ＧＰＳ情報を集めるって、プライバシー的にどーなんだろう。。
もし、ＯＫなら、ドコモやauって、探偵さんができるとおもうんですけど。。
こっそりと、ご主人や恋人のいどこを追跡して教えます。。。

芸能レポーターとか、欲しそうですよね。
追いかけているタレントが、どこにいるか。。。とか。。。

。。。そんなもん、あつめて、いいんだろうか（＾＾；）

やっぱ、個人を特定しちゃまずいのかな（＾＾；）

外部設計の「見える化」が、大事かも？

前に書いた、「生物の構造と、要求から、プログラムまでの階層を比較すると、わかりやすいかも！」というところで、ソフトの場合は、基本操作からアクティビティまで、ソースコードとしてかきます。この問題や発展の可能性は、今後、別の回で書きます。ってかいていたので、その話についてかきます。

---

■なんでもソースに落としてしまうところに問題がある

　結局、ソフトの場合、入出力もライブラリも、足し算引き算も、ソートやマージといったある程度まとまった話も、さらには受注票作成といった業務も、全部、ソースコード上に落とされる。

　っていうことは、「ソースを見れば分かる。JavaDocに入出力はすべてかかれるから便利」って主張する人もいるだろうけど、現実問題、なんでもごちゃごちゃ、恣意的にかけてしまって、何がなんだか分からなくしてしまう危険がある。

　たとえば、ある人は、StrutsのActionの中で、JDBCのドライバから呼び出して、ユーザー名、パスワードをリテラルで設定して、SQLを発行することができる。
　その一方で、ある人はDBアクセスライブラリを作成し、それは、モデルからのアクセスに限定し、Actionでは、モデルをアクセスするという形にもできる。
　このとき、モデルをPOJOにしておけば、モデル単体でのテストや再利用ができる。

　このどっちも書くことが可能というか、混在させることすら可能である。
　実際には、ここまでひどくはないにしろ、やはり、恣意的に分けられる部分があって、そのことが、バグを招いたりしてしまっている。

---

■いっそのこと、外部仕様は、全部見える化＝＞自動生成にしてしまえば。。

なんで、外部仕様は、
・全部見える化してしまい、
・ドキュメントから自動生成したコードをリンクする、
・修正時は仕様書を直して再度リンク、
・個別プログラミングは、外部仕様書から呼ばれる関数部分のみ

ってできると、楽になってくると思う。

入出力部分に関して、ドキュメントから関数自動生成という話は、まあいいとおもう（というか、いつか、自動生成については、まとめて書くので、そのときに）

　問題となるのは、ライブラリや入出力、詳細設計で書かれる関数をよびだすところを書く部分。

　１つの考えとしては、Accessのマクロ画面のように、かけるというもの。
　他には、詳細のドキュメントのように書く方法。。
　フローチャートを書いてしまう方法。。。

　いろいろありそうだが、このへん、つまり、図でもってプログラミングできるという分野が、今後発展する可能性がありそうな気がする。

　そうして、外部設計が見える化してくると、あとは詳細部分のコーディングになるので、ある程度はなしが見やすくなるし、図式化することによって、（図の制限があるから）恣意的にやれる部分が減り、品質の安定にも役立つと思う。

---

　っていうのが、問題の発展と可能性。

　で、この話は、その前の要求から、プログラムまでの階層を考えないことが、開発の混乱を招いているを受けた話で、さらにその話の中で、アスペクト指向における横断的関心事の切り出しの問題や、デザインパターンの活用の話なんかは、月曜日からはなすこととして、と書いておきながら、書いてないので、このシリーズ？の次回は、その辺の話を書きます（って、いつ書くか分からないけど。。）

開発の初めから順番に書いていってみる その３２：外部設計（９）詳細までの落とし込み

シリーズ「開発の初めから順番に書いていってみる」の続きです。
　今、外部設計の段階で、要求仕様から、詳細設計までの間（ここを外部設計と、ここでは読んでいるわけですが）の手順は、以下の手順で行うと、流れに飛躍がなく説明がつくということを書きました。

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

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

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

　で、前回までで（う）をやりましたので、今回は「（え）プログラムを適当に詳細化し、詳細設計に持っていく」です。

---

■外部設計の機能分化でやること

　要求仕様から詳細まで、機能を落としていくという作業をやるのですが、これについて、月曜日に「生物の構造と、要求から、プログラムまでの階層を比較すると、わかりやすいかも！」っていう題で書いた内容と照らし合わせて考えます。

そこの例だと、

　　　　　　　　　　細胞 ＝＝＝ アクティビティ 
（細胞小器官・細胞骨格） 　｜ （ライブラリと入出力） 
　　　　　　　たんぱく質 ＝＝＝ 基本操作群 

っていう部分がそれにあたります。
アクティビティが、
要求仕様で出ているアクティビティ（ユースケース、プロセス）
　　　　→同じアクティビティ名（たとえば受注）でも、顧客ごとに微妙に異なる
　　　　　個別性がある

で、

基本操作群が、詳細設計ででているところ
　　　　→ソート、マージなど、あんまり個別性がない言葉で表すべき
　　　　　つまり、明日急遽プログラマ増員で他社の人が来て、その仕様書を
　　　　　渡したとしても、理解できるくらい普遍的なレベル

そして、ライブラリと入出力といった、個別性ではないが、普遍的でもない
まとまり（プロジェクトレベルでは共通）とかをつかって、アクティビティを
基本操作＋ライブラリと入出力にまで落とすのが、外部設計でした。

　で、このとき、細胞の骨格を作る細胞骨格のように、プログラムの骨格をつくるのがフレームワークということでした。

　なので、フレームワークをもとに、ライブラリと入出力をつかって、基本操作にまで、アクティビティを落とし込めばいいわけです。

---

■機能分化の手順

ということで、こういう手順できめます。

１．プロセスの骨格を決める、フレームワークを決定します。
　おおもとになるフレームワークです。
　　　画面を使うフレームワークと、
　　　バッチのフレームワーク、
　とかになるのかな。。
　でも、この作成基準がないので、実際には帳票出力用、DBアクセス用。。などなど、いっぱいできちゃったりします（－＿－；）

２．フレームワークをカスタマイズします。
　プロジェクトごとに、以下の観点について考えないといけません
　　・DBを使うとき、トランザクション処理はどのように行うの？
　　・ログはどうするか→デバッグ情報もふくむ

３．入出力のフレームワークを決めます
　プロセスの骨格ではないが、共通な入出力処理（DBアクセス、ファイルアクセスなどなど）をフレームワーク化、ライブラリ化し、できれば仕様書からの自動化をします。

４．共通部分を決定します
　システムで、共通に使うモジュール、つまりライブラリを切り出し、作成します。
　ただこれ、恣意的にやられることが多いです。
　それと、他の共通部分も、抜き出します。他の共通部分には
　　　　　共通で使うコード
　　　　　共通で使うメッセージ
　　　　　共通で使うデータタイプ（クラス・構造体）
　などがあります。

５．１アクティビティに対し、
　　　２のどのフレームワークを使い（これは１プロセス１つ）
　　　３のどの入出力を、どのタイミングで使い（これは複数）
　　　４のどの共通部分モジュールなどを使う（これも複数）かを
　　決定した上で、
　　アクティビティを、基本操作＋３＋４で表現します。

---

■バグや仕様変更、設計不可能になる余地

ここでバグがはいったり、仕様変更が頻発になったり、設計不可能になるのは、
（あ）そもそも、どんなことをしても、アクティビティが基本操作には落ちない
（い）要求が間違えている（要求分析者が、間違ったことを書いている）
（う）要求の解釈を、設計者が間違えている
（え）要求から基本操作までの落とし込みを設計者が間違えた
（お）共通部分、入出力の作り方を勘違いあるいは見落としている
（か）詳細設計を書いたら、設計者とプログラマで意図が違った。

　つまり、「はじめっからできない」、「想定外」、「勘違い・誤解」です。

---

■バグや仕様変更、設計不可能を減らすには

　想定外をへらすには、想定をふやす、つまり、似たような経験があったら、それと比較するということで、これは、ナレッジベースの問題になるので、話はおおきくなってしまいます。

　しかし、「はじめっからできない」と「勘違い・誤解」を防ぐ方法は、もすこしかんたんです。

　中ぬきにすればいいのです。
　つまり、プログラマが分かる基本操作＋入出力＋ライブラリで、要求（具体的には名詞と動詞）を定義してしまう。

　たとえば、「ピッキングリストを作成する」という場合、

・リストを作成するとは、帳票を、指定された帳票形式（リスト形式という形式がある）でプリンタから紙で出力することである。

・ピッキングリストとは、ピッキングしやすい無用心な家のリストである

　。。。っていうのはうそで、

　ある出荷する箱にいれるべき商品の名前、数量、コードを書いたリスト形式で書かれた紙である（これは、会社によって、定義は違います）

　のように、特に動詞について、入出力とか、基本操作とかでぜーんぶ説明して、その用語集を作っておけば、誤解はすくなくなります。

　けど、現実的にはそんなのをやるのはたいへんなので、
　実際には、「おいおい、それって、どーやってやるんだよ（＾＾；）」とか、
（３日前の在庫数量を出力する＝持っているのは入出庫テーブルのみ。。
　おいおい、会社創業時からの入出庫をたしこむのかあ？？）

　方法があいまいで誤解や漏れを招く（キャンセル処理をする＝いろんな状況のキャンセルがあり、時と場合でやるべきことが違うため、詳しく考えないと漏れが出る）っていうことになったりします。

---

　ってことで、次回は、外部設計で作成する成果物についてです。