業務フローと出力結果が決まらないと、プロジェクトは炎上する？

　今まで書いてきたオブジェクト指向で、修正による影響をうけにくくする方策から、派生して考えられることとして、

システムとは、情報を処理することであり、

情報（リソース＋過去のイベント結果）は、
　エンティティで、
　これは、正規化からもとまり、
　正規化の出発点が、出力内容であり、

処理するとは、業務プロセスであるとすると、

　業務プロセスと出力結果が決まらないと、システムはいつまでたってもできないので、適当に作ってやりなおしとなり、そのうち、クラスの中をぐじゃぐじゃにして、炎上する？？

　ってなるけど、これは、たしかに、そのような気がする。

---

　オブジェクト指向だと、業務フローは、アクティビティ図だけど、アクティビティ図が書けないとかいうプロジェクトって、たいていあとで、「あ、これも・・」とかいう修正が入るような気が・・・

　ちなみに、逆に言うと、出力結果と業務フローが決まれば、その業務で、出力結果が作れるのかというのを、シナリオを作成して確認できるので、修正は入りにくくなるし、追加修正がある程度、簡単に出来る・・

「ウルシステムズとケアブレインズ、NECとSaaS分野で協業」って、

SugarCRMも、セールスフォースみたいに、SaaS化しようとしている
っていう解釈でOK？ちゃうの？？
たしかに、SugarCRM 5.0だと、カスタムモジュールが作れるので、
SaaS化できるんだろうけど、

それなら、セールスフォースでいいような気が（＾＾；）

あ、ソースは、ここ
http://www.ulsystems.co.jp/press_release/archive/20080403.html

オブジェクト指向で、修正による影響をうけにくくする方策その２ － 一貫性。

　前回書いた、オブジェクト指向で、修正による影響をうけにくくする方策の続き。

　オブジェクト指向はもともと局所差異があるから、修正しやすいはずなんだけど、局所性ゆえに、周りが見えにくくなる。そこで、適切な局所性をするには、
　　・業務プロセスとエンティティを明確に分けて、
　　・エンティティは１事実１箇所で
という話になってくると・・で、「エンティティは１事実１箇所」っていうのは、ER図を作るときのDBとおなじで、これを実現するには、独立性と一貫性を持つ必要があると・・

　で、前回は、独立性の話で、これは
・正規化によりエンティティを分離し、
・業務プロセスで利用するときには、DBのビューのように、使いやすいクラスをつくれば、
　業務プロセス部分の修正に影響を受けない
　という話でした。

　今回は、おかしくなるのを防ぐというより、おかしくなったら、すぐ気づくようにする話
　つまり、おかしなデータが入らないようにチェックする話。

　DBだと、一貫性の話です。

---

■一貫性を担保する－チェック

　DBで、一貫性は、参照制約とかつけているけど、オブジェクト指向のクラスの場合
・参照制約同様、複数のクラス間に関するもの（親が存在しないといけないとか）
・属性値の問題（受注金額＝負の数は不可など）
の大きく２通りが考えられる気がする（もっとある？）

　で、この場合、Javaなら、setterでチェックすれば良いように思うかもしれないけど、
setterは、ふつうvoidで返すので、チェック結果を返せない（まあ、クラス内の属性にerrno
ってとっておいて、それでチェックしてもいいけど・・ま、それはめんどっちい）

---

■どこで何をチェックするか

　そこで、普通は、追加、削除、編集する際にチェックするということになる。
　なお、検索するときには、エンティティを書き換えていないので、検索できないだけで問題はない・・・はずだが、SQLインジェクションされてしまえば終わりなので、SQLインジェクション対策は必要になる。

　追加、編集は、値チェックと、関連性チェック、削除は関連性チェックになります。

　値チェックは、範囲内か？とか、それこそ、ある１つの値を、正規表現使ってチェックみたいなかんじ。

　関連性チェックは、親が存在するかとか、この値だと、他のオブジェクトがある値のはずだけど
（受注キャンセルできるのは、出荷前のはずで、それ以降は返品処理のはずだけど・・とか）・・
とか、２つ以上（場合によってはそのオブジェクトだけでは、チェックできないことも）のもの
に関してのチェック。

　ってことになる。

---

■インターフェース部分でチェックするのが、効率的かも・・

　じゃあ、なんでもチェックすればいいか？っていうと、
チェックだらけになってしまう。

　一方、チェックしないと、そのメソッドやクラスの中身を知らないと、
変な値を入れてしまって、おかしな動作させてしまうかもしれない。

　どこでちぇっくするのがいいか・・・

　というと、インターフェースとして、公開しているところ
ということになる。

人とコンピューターのインターフェースは、
　ビューであり、これは、JavaScriptで、画面チェックということになる

サーバーとクライアントというか、業務プロセス（サービス）提供部分は、
　コントローラーのサーブレットでチェック。

業務プロセスとエンティティの関係は、
　エンティティのクラスのところの追加、編集、削除関連メソッド（上記）

って感じになると思う。

---

とりあえず、ここまで。