オブジェクト指向で開発の最初から最後までの手順例－その８：エンティティを再度まとめ

　オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、今回は、ここの順番から言うと「（５－１－１）データの項目をだしてくる」を行う前に、ちょっと、やることを書いておきます。

---

■再度、エンティティをまとめる。

「（５－１－１）データの項目をだしてくる」の前またはあとにやる作業なのですが、ここまでのエンティティを再度まとめておきます。

　エンティティに関しては、「（１）エンティティの抽出」でやりました。
　しかし、その後、「（２）機能要求をまとめる」で、実際にはヒアリングしていたり、「（５－１－１）データの項目をだしてくる」でデータについて詳しく調べたりして、より深い情報があつまっています。

　正規化を行う前に、それらのエンティティをまとめておくのがいいとおもいます。

---

■今回の場合

　今回の場合は、オブジェクト指向で開発の最初から最後までの手順例－その３：エンティティ抽出で、以下のエンティティがでています。

　・発注
　・小売（発注者）
　・卸（受注者）
　・商品

で、その後、オブジェクト指向で開発の最初から最後までの手順例－その４：業務要件。で、小売には、（最終的に運ばれる）店舗と、納品場所（物流センター）があるという話になりました。

ってことで、

　・発注
　・小売（発注者）
　　　・店舗
　　　・納品場所
　・卸（受注者）
　・商品

っていうことになるとおもいます。

---

ということで、エンティティの再度まとめは、ここまで

エンティティと属性を決めてから画面チェックしないと、修正大変だよ（－＿－；）

　ある日、森の中、熊さんに出会った・・

　じゃなくって、ある日、システムを開発するのに、画面から決めている人たちに出会ったんだけど、先に、エンティティとその属性項目をきめて、値の範囲とかを決めないとだめっすよ。

（エンティティと項目は、要求仕様できまるし、そうでない場合は、画面の詳細設計の前に、DB定義をする）。

　だって、たとえば、ログイン名が何文字までなのか、日本語OKかわかんないのに、エラーチェックするって書いてもねえ（＾＾；）
　ERで、ユーザーエンティティ（テーブル）のログイン名は、英数字何文字とかきまって、はじめてエラーチェックできるわけで・・・・

---

　で、その場合なんだけど、エラーチェックはまとめたほうがいい。
（全部をまとめるか、属性ごとにメソッドをつくるかなんていうのは、些細な問題で、とにかく、まとめたほうがいい）。

　理由は、画面それぞれで、たとえば、さっきのログイン名チェックをしていたら、「いやー、ログイン名、いままで１５文字以下だったのが、６文字以上、１５文字以下にします」って言う具合に仕様変更になったら、画面の担当者みんなが直さなきゃなんなくなるよ（＾＾；）
　当然もれとか、矛盾も出るよね。

　で、画面によってテストケースが変わるような場合は、エラーチェックメソッドのほうで、きりわける。
　

---

　たとえば、全部まとめるエラーチェックの場合、

　int[] err_cheks(HashMap data,int[] chkList)

　みたいなかんじで、HashMapのほうに、キー（項目名）と入力値、chkListに、やるべきエラーチェック番号を設定する（小さいシステムの場合、chkListはいらない。ハッシュマップのキーからチェックすべきものがわかるから）。

　で、このとき、たとえば、種別が１０以下の数字で表す項目に、文字が入っていたら、範囲チェック（１０以下か？）は、する必要がない（できない）。
　なので、チェックリストに入っているものでも、あるエラーが起きたら、このチェックは飛ばすというのもある（内部的にフラグで制御する）

　結果がint[]なのは、ワーニングとかの場合は、いくつかエラーが立つ。
　致命的なエラーなら、そこでエラーチェックは終わり、１個だけ返ってくる。
　nullか、配列要素０ならOKってことですね。

　で、String getErrMsg(int errno);でエラーメッセージを拾うと。。。
（この場合、intの配列にいっぱい要素があったら、１番上からみて、致命的なものを選ぶ）

---

　で、そんなことはいいんだけど、そのエラーチェックメソッドerr_cheksって、自動生成できないかなあ。。今考え中（＾＾；）ｖ