プログラム自動生成は、入出力部分が、しやすい

　ちょっとメモ＆明日の話のまえおき

　最近書いている開発の初めから順番に書いていってみるの「外部設計」にあるように、フレームワークからみると、プログラムは大きく２つの部分に分かれる

１つは、外部入出力の操作（入力データを、プログラムのメモリ内に展開する。プログラム内のメモリにあるデータを出力する）

もう１つは、メモリに展開されたデータを変換処理するもの

　このとき、前者の「外部入出力の操作」にフレームワークを適用し。。。っていう話をかいているわけなんだけど、つまり、このことは言い換えると、「外部入出力の操作」は、フレームワーク化しやすい、自動生成なり、ライブラリ化しやすいっていうことになります。

　なぜ、フレームワーク化、自動化しやすいかというと、入出力デバイスからの読み書きの方法というのは、決まっているからです（きまってないと、読み書きできません。はい）。
　なので、ここの部分を自動化しておくことが、品質をあげて、よけいなことを考えなくてすむようになります。

　一方、「メモリに展開されたデータを変換処理する」部分はどうか？決まっているのかどうか？

　これについては、明日の話題になると思います。

ミラーボール？のマウス、「ちょいかわデコマウス」。。。

ここ
エッシャーマウスにスワロフスキぎっしりの「ちょいかわ」バージョン
http://japanese.engadget.com/2007/04/09/escher-mouse-choikawa-edition/

に写真が載っているのですが、マウスというより、ミラーボール？？
なんか、すごいバブルかも・・（＾＾；）

ちなみに、そこに紹介されている、だるまうす（だるまのマウス）とかは、

ここ　http://www.darumouse.com/index.html
にあるみたい。
ダルマウス極太とかのってます。

ちなみに、そのミラーボールのサイトは、
ここ　http://www.decokichi.com/
みたいですけど、仕事中見るのにはちょっと。。。のセンスかも。。

もっとも、仕事中、そのマウスを使ってるのも、ちょっと。。だけど。。

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

シリーズ「開発の初めから順番に書いていってみる」の続きです。
前回、要求分析の結果（ここではDFDを扱います）から、外部設計、最終的に詳細設計へ落とし込むのは、以下の手順で行うと、説明がつくということを書きました。

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

　前回はは、（１）から（５）までです、
　今回は（６）を説明します。

---

■細分化された入出力をあわせる：画面以外

　さて、（５）までで、１プロセスにたいして、入出力部分と、プロセス処理部分に分離しました。

　でも、入出力にはフレームワークがあるか、それ相応のものをつくるとなると、１プロセスに対してあるのではなく、たいていは、DBなら１テーブル、帳票なら１つの画面に１つのプロセスがあって、そのプロセスを、プロセス処理部分が呼び出すっていう形になると思いますので、そうやって、書き換えましょう。

つまり、要求仕様段階で、



っていうことです。この（６）までの工程で。。
（５のとき、プロセスごとにいったんなるので、もっと細かくなるが、まとめると、結局こうなる。。まあ、面倒なので、ふつう（５）の時点の図を描くことはない）

---

■細分化された入出力をあわせる：画面

　画面は、Action１個に対して、いろいろ操作しましたが、１アクションは１画面ではない、つまり、ボタン１個が１アクションに相当するのですが、１画面でいくつものボタンになることがあります。なので、まとめます。

　たいてい、エンティティ１個に対し、それが複数あるなら、
　一覧（エンティティのリスト）と、詳細画面（１エンティティ分）があって、そのエンティティに関連するアクションを１ボタンとしてまとめると、うまくいきます。

　まあ、こんなかんじで、まとめた画面と、その画面の流れを、画面定義書としてまとめます。

　そーすると、最終的に、こんな図に変換されると思います。。。



　なお、黄色の部分が画面のプロセスになります。
　Strutsだと、ActionFormとJSP、Javascriptなんかで記述するプロセスっていうことになります。

---

■つまり

　つまり、入出力フレームワークに沿ってまとめるということです。

　こうなると、結果として、入出力のものは、全部プロセスに対する値渡しになるので、

　入力からプロセスをへてわたってきた値を、
　　なんらかの処理をして
　値を渡すとプロセスを経て出力する

---

　そうすると、処理部分の話だけになります。
　で、次回は

（７）処理部分を、ワーカーさんに渡せるまで落とし込む。

　の話になります。

オブジェクト指向分析（開発）の存在理由

　この前、DFDから、機能仕様を落としてくる方法を書きましたけど（っていうか、書いている最中ですけど）、ここで問題なのは、そーすると、DFDのように入出力のないユースケース図、アクティビティ図を利用して書く、UMLを使った、オブジェクト指向分析、オブジェクト指向開発って、意味あるのか？ってことになります。

　意味あります。それは、DFDなどを使う構造化分析や、データ中心指向（DOA)には、問題があるケースがあるからです。まずは、それを説明します。

---

■DOAなどの問題：データが全部解析できないとプログラムに入れない

　DOAの場合、データを解析してから、プログラム開発に入ります。
　構造化分析もDFDをかくとき、データがわかんないとかけません。

　そうすると、データ構造が分からない新規事業や、データ構造を全部解析しおわったとおもったら、もう、次の時代にはいっていて、その開発は時代遅れとなるような、ビジネスの速度が早いシステムは。。。

　。。。データが決まらないので作れない（＞＿＜！）

　ってことになってしまいます。

---

■DOAなどの問題：データは本当にプロセスに依存しないか？

　プロセスより、データ構造のほうが、動きにくい（決まっている）よね、だから、データ構造に着目して。。っていうのがDOAの考え方でした。
　でももし、データ構造とプロセスが、密接に関係していたら。。？

　プロセスを決めない限りデータが決まらず、かつ、そのプロセスは動きやすい？？

　うん？？

---

■つまり、データをきめなくても、システムが組めるっていうものが必要になった。

　DOAや構造化分析は、データを解析します。でも、その解析をするより、もっと早く、システムをくみたいとなってくると。。どーするか？って問題です。。

　それに対応したのがオブジェクト指向といえます。

---

■データが動かないのでなく、実在するエンティティが動かない。

　で、ここで、よーくかんがえてくださいね。
　データって、エンティティをある側面（属性）でみたものってかきましたよねえ。
　ものの見方っていうのは、良く変わります。

　でも、そこに、モノが存在するという事実、学校があるとか、人がいるとか、

　それって、かわりますう？？

　分身の術とか、瞬間移動とか身に付けないと、いなくなったり、何箇所にもいたりすることはできませんよねえ。。つまり、実在化するエンティティ（＝エンティティの実体＝インスタンス）は、そんなにかわらない。。

　っていうところから出発すれば、じつは、オブジェクト指向でも、DFDでこのまえやったような、いっきつうかんができるんですけど。。。

---

そのまえに、いっぱいかかないといけないことがあるけど、今時間がないので、
またこんど。。