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

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

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

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

　っていうことになる。

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

---

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

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

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

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

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

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

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

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

---

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

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

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

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

「ITパスポート試験サンプル問題」って、やった？意外と難しくない？？

いや、ＩＴパスポートって、意外と難しいんじゃないか？
という話になり、やってみましたよ・・・

「ITパスポート試験サンプル問題」
http://www.jitec.jp/1_13download/ip_sample_all.pdf
（リンク先、ＰＤＦです）

うん、たしかに意外とレベル高いかも・・・
コンピューター関係はそうでもないんだけど、
ＯＲの問題が出たり、
コンピューター以外は、ちょっと・・・

新人だと、コンピューター関係も、難しいかも・・・

Strutsのように、アクティビティ（プロセス）もクラスで表現したほうが、拡張性ある？

　一般に、

　　　名詞である、モノ・エンティティをあらわすには、クラスを
　　　動詞である、アクティビティ（プロセス）をあらわすにはメソッドを

　使います。

　で、ここで困る問題が起こるわけです。
　サ変名詞（一般的用語ではない）といわれる、「～する」という名詞というか、動詞です。
　「受注する」というのは、名詞にも、動詞にもなります。

　どうするか・・・

　実際には、クラスになることが多いです。
　理由は、永続性（パソコンの電気を切っても、受注データがないと困る）があり、ＩＤが振れるから、抽象的にモノとしてあつかえるので。
　そこで、こういうものは、「出来事」とし、出来事＋モノ＝事象として、事象は、クラスにできるとします。

　でも、そーすると、「アサヒる」（古くは「エガワる」とかは、どーなるんでしょうねえ・・・

---

　一方、Strutsとか、サーブレットの世界では、動詞のプロセスもクラスです。
　Actionクラスとなります。

　この場合、実行するには、executeメソッドを実行します。
　すべてのプロセスにはexecuteメソッドがあり、必要なら、データチェックのバリデーションをやるメソッドもあるわけです。

　もちろん、モノもクラスとなりますので、動詞、名詞、すべてクラスになります。
　（ただしくは、基本データ形の値しか持たない名詞は、属性となる）

---

　従来の考え方だと、クラスとメソッドは違うので、動詞と名詞は明確に区別しなきゃなりません。
　でも、実際の言語はそうなっていません。こまります。

　ここで、Strutsのように、すべて、クラスと考えると・・・
　名詞と動詞の差は、持っているメソッドの違いということになります。

　名詞のクラスは、CRUD、つまり、
　　　C=Create、実際にはnew,DBだと、insertでしょうかね
　　　R=Read、読み込みないしは検索、DBだと、select
　　　W=Write、編集、DBだとUpdate
　　　D=Delete、削除、ＤＢでもdelete
　のメソッドがあり、

　動詞のクラスでは、
　　　実行:execute
　　　入力データチェック
　　あと、結果をＸＭＬで返すシリアライズなんかもいるかも

とすれば、受注するという、動詞と名詞の両方に属する場合も簡単です。名詞のメソッドと、動詞のメソッド両方をもっているだけです。「アサヒる」「エガワる」は、アサヒクラス、エガワクラスに、動詞のメソッドが追加されただけということになります。

　名詞の場合は、構成要素などが属性となりますが、動詞の場合は、引数及び結果を属性とします。

---

　こうすると、Strutsから、JSPにかえたり、Swingに変えたりするのも、かんたんです。

　Strutsであれば、executeのところで、動詞のクラスを生成し、実行して、結果を受け取って、それを適切な形にして返せばいいし、JSPも、動詞のクラスを生成し、実行して、結果はＸＭＬのシリアライズでＸＭＬを返してもいいし、変換してもいい。
　それをＳｗｉｎｇで扱いたいなら、イベントごとにリスナーで登録したものを起動すると思いますが、そのリスナークラスの所定のメソッドで、動詞のクラスを生成し、実行して、結果を受け取って、それをもとに画面設定すればいい。

　ということで、表示方法が変わっても、動詞のクラスを生成し、実行する部分は、不変にできる。

　ということは、テストはドライバ作ってコンソールからでもＯＫだし、表示方法が変わっても、糊付け部分だけを作成すればいい。このへんは、自動化できるかも・・

　この柔軟性は魅力だと思うけど・・・