動詞をクラスにすることで、サービス指向とユーザー中心指向が融合する

　さっきの動詞をクラスにする話。

　もし、こうなれば、アクティビティ図のアクティビティも、１つ１つがクラスになる。

　で、
　　１．newまたはsetterで値を設定して
　　２．バリデーションチェックをして
　　３．executeメソッドを実行すると、
　　４．getterで、結果が取得、あるいはXMLserializeでXMLで結果取得

　っていうことになる。

　そうすると、これらアクティビティをサービスとして、公開できることになる。
　このとき、ネットで公開するか、ライブラリで公開するかは、各自自由。
　ネットで公開するとすると、上記のクラスを呼び出す、「のり」のプログラムが必要
　（だけど、自動生成できる）

---

　そーすると、ユーザーは、どうなるか？

　ユーザーの立場（＝アクティビティ図のスイムレーンがアクター＝ユーザー）から
画面を設計して、必要な情報を取ってくればいい。

　とすると、完全分業可能な上、アクティビティ図を書いた時点で、ダミーモジュールは造れることになる

　っていうか、文章が存在すれば、ダミーモジュールは造れる

　サーバー側サービス
　　　　文章＝名詞クラス
　　　　存在する＝動詞クラス
　　　　ダミーモジュール＝名詞クラス
　　　　造る＝動詞クラス

　クライアント側
　　　if (　文章.select().count() > 0 )
　　　{
　　　　　　ダミーモジュール dm = new ダミーモジュール（文章）;
　　　　　　new 造る（dm）;
　　　}

　　ただし、存在するとか、作るというのは、わざわざ、動詞クラスにいらないかもしれない。
　　selectしなくても、個数を数えるクラスとかは、いるかも。。。

　　クライアントの処理は、場合によっては、サーバーにもっていってもいい
　（新たな動詞：ダミー作成＝＞ダミる？という意味で）

---

　こうなってくると、いろんな図はいらない、アクティビティ図というか、業務の流れ図さえあれば、一気にプログラムにいけるということになる。

　そして、サーバー側は、アクティビティのサービスを提供する、ＳＯＡで、
　ユーザーは、ユーザーの作業を中心に分析して、サービスを取り出す、ユーザー中心指向で

システムが開発できることになる。

　てなかんじで、すべてクラスにしてしまうのは、意義が大きかったりする。