以前書いた「オブジェクト指向分析（開発）の存在理由」という話のつづき。
今までの話をまとめると、
DFDは入出力とプロセスの関係が明記してあるので、ここから、プログラム可能なものに落としてくることはこんなかんじでできる。
しかし、これは逆に言うと、入出力されるデータ構造が決まらないと、落とし込めないという欠点を持っている。
それに対して、オブジェクト指向は、入出力データがはっきりきまらなくとも、そこに出てくる登場人物と、交換されるモノ程度がわかれば、とりあえず、それをエンティティとして。。。プログラムできるといえるのか？っていうところでした。
今回は、プログラムできる（UMLのユースケース図からクラスに落とし込める）という根拠を示すとともに、その結果、
オブジェクト指向分析
↓
アジャイル
↓
テストファースト
という流れになってしまうことを示したいと思います。
■UMLで落とし込む場合の考え方の根拠
ユースケース図の場合、プロセスは、ユースケースにあたります。これは分かっています。
データは、外部入出力と、プロセス内部での入出力です。
外部入出力部分は、アクターがいるところです。
ここでアクターは、どういう情報を入力するか、出力して欲しいかがわかっているとします（これは仮定です。なんとなくアクターをかかれると、アウトですが。。）
ということで、外部入出力は、エンティティレベルでは、仮にOKとします。
そこで、このエンティティに対応するクラスを作りましょう。
内部入出力を、永続性という観点から考えると、永続性のあるものと、ないものに分けられます。
永続性のないものは、プロセス間で利用するだけですので、これは、セッションのように、一時的な共有置き場に、エンティティごと入れてしまうとします。
永続性のあるモノは、DBの中に入れておき、必要なときに取り出したり、作成・削除・変更したりするとします。
これらの操作はエンティティ１つにDBのテーブル１つを割り当て、さらにクラスも１つ割り当て、そのクラスが取り出したり、作成・削除・変更のメソッドを持つとすると、クラス呼び出しで、OKとなります。
そして、DBアクセス情報は、上記の「永続性のないもの」で受け渡した共有置き場にいれておきます。
そうすると、
クラス
{
メソッド１（共有置き場データ）
｛
DBアクセス
｝
メソッド２（共有置き場データ）
｛
DBアクセス
｝
：
：
｝
|
という形に帰着するということになります。
ただ、これはやりすぎなので、実際には、
クラス
{
メソッド１（このメソッドで使うエンティティ１，２・・・）
｛
共有置き場データアクセス
DBアクセス
｝
メソッド２（このメソッドで使うエンティティ１，２・・・）
｛
共有置き場データアクセス
DBアクセス
｝
：
：
｝
|
というところで落ち着かせるということになるでしょうが。。
■こういう手法がないとWebAPIとかは成立しない
この手法の応用がWebで利用されるAPIになると思います。
メソッド１（共有置き場データ）
の「メソッド１」の部分が、CGIなど呼び出されるサーバー側サービス、
共有置き場データのところには、引数が入るのですが、これが、URLエンコードされた文字列という、だれでも利用可能な型（文字列）で表現されてます（＝入れ物に入れられている）。
もし、WebAPIが、利用者すべての入出力を決めてからつくるとか言い出したら、永遠に決まりませんが、とりあえず、URLで、メソッドをきめて、どんな引数でも文字列で表現して、文字列のなかに入れ込んでしまうことで、
あとで引数が拡張されても、受け取った引数の入れ物（文字列）自体は変わらないので、前の引数をいじらなければ、現状動いているものには、問題ない。
なので、とりあえず、今必要なものだけ定義して、動かすということを可能にしています。
■オブジェクト指向はアジャイル、テストファーストに続く
で、なんでオブジェクト指向を採用したかというと、はじめ、仕様がはっきり分かってないからでした。もし、入出力と変換方法が確定しているのであれば、DFDから落としていったほうが、一回できまるので、こっちのほうがいいです。
仕様がわかんない上、たいていこういうのは、作ってみないと分からないというケースです。ということで、何度も作り直す、アジャイル的な開発が好まれることになります。
でも、作り直す間、ずーっとテストしなかったら、品質は保てません。
ということで、作り直しがあるケースでは、作った部分をテストして、その部分は品質を保つということをしないといけません。なので、テストファーストってことになります。
次回のこのシリーズって（シリーズなのか？）では、「オブジェクト指向、アジャイル、テストファースト」に流れる、一つの信念について考えます。
