酒問屋の在庫問題 - 抽出した名詞を選別する。

モデ本

抽出した名詞を選別してみる。


①同じようなものをまとめてみる。
酒と商品は同じものを言っているので、より一般的な言葉の商品を残す。
『酒類だけだが、1000品目に上る』と書いてあるので、酒類＝品目とみて問題なさそうなので、酒類を消して、品目を残す。

納期と納品希望日も同じようなきガするので、納期を採用。
と思ったけど、入荷希望日と対比させると言葉が分かりやすいので、納品希望日を採用。


②アクター（モデルの所有者）を抜き出す。
卸売業者（A社）は、モデルの所有者であるのではずす。
あと、注文受付係、倉庫係、配送係もアクターだろう。


③システム範囲外の概念を外す。
コンテナに酒を入れるのは酒メーカーなので、卸売業者（A社）の管理の範疇ではないような気がする。（勘なので理由も適当）
なので、コンテナも消す。


④概念のビューを消す。
まず、〜票とか〜書とかを抜き出す。


受注票、出荷指示書、発注書、納品書

  • 受注票 ⇒ 受注のビュー
  • 出荷指示書 ⇒ 出荷のビュー
  • 発注書 ⇒ 発注のビュー
と、ここまではきたんだけど、出荷指示書は『受注票のコピー』とあるので、受注のビューだろうと考えて、
  • 受注票、出荷指示書 ⇒ 受注のビュー
  • 発注書 ⇒ 発注のビュー
  • 納品書 ⇒ 出荷のビュー
とする。
と思ったら、入荷のビューってないのかと気づいた。


よく文章を読むと納品書には、A社作成の納品書と酒メーカー作成の納品書があるらしい。酒メーカーからの納品は、入荷ってことなので。。
つまり。

  • 受注票、出荷指示書 ⇒ 受注のビュー
  • 発注書 ⇒ 発注のビュー
  • A社の納品書 ⇒ 出荷のビュー
  • 酒メーカーの納品書 ⇒ 入荷のビュー

⑤あとは、勘
倉庫ってどうなんだろぅ。
根拠ないけど、勘で不要と判断。


とりあえず、こんな感じか。。
残った名詞は以下のとおり。

酒     卸売業者   商品       酒類       コンテナ
倉庫   発注       酒メーカー 品目       小売店
出荷   受注       注文受付係 納期       納品希望日
受注票 出荷指示書 倉庫係     在庫数量   入荷希望日
発注書 入荷       納品書     配送係


次は、初期のクラス図の中心部分を書く。

酒問屋の在庫問題 - 名詞抽出する。

モデ本

モデリングの本質ISBN:4822221180 第6章の酒問屋の在庫問題を本を読み進める前に自分でやってみる。


まずは問題文から名詞抽出してみる。

酒     卸売業者   商品       酒類       コンテナ 
倉庫   発注       酒メーカー 品目       小売店
出荷   受注       注文受付係 納期       納品希望日
受注票 出荷指示票 倉庫係     在庫数量   入荷希望日
発注書 入荷       納品書     出荷指示書 配送係

名詞抽出したので、次は選別を行う。

そもそもエラーハンドリングってどうするのが一般的なのだろう。

疑問

そもそも、JavaでServletの場合、エラーハンドリングってどうするのが一般的なのだろう。


ServletでWebフレームワーク*1作るときいつも悩むのが、以下のケース。

  • JSP呼び出し中の例外のハンドリング
  • JSP呼出し後の例外のハンドリング

とりあえず、JSP呼出し中の例外ハンドリングに関しては、errorPage属性を使えばよさそう。
けど、サイズの大きい画面をJSPで作ってるときに、レスポンスが途中でflushしちゃっても、エラーページは表示されるのだろうか？


レスポンスがすぐにflushされないように設定するとかはできるけど、それは根本的な解決ではないような。


あと、errorPageに指定する画面てJSP?それともHTML?
もし、JSPにしたときは、さらにそのJSPでエラーが起きたらどうする？


JSP呼出し後の例外のハンドリングに関しては、っーか、『そもそもJSP呼出し後に例外が発生するようなことするなよ』ってことか？


でも、どうしても、JSP呼出し後に例外が発生するような処理をしなきゃならない場合、
レスポンスは既にコミットしてたりするから、エラーページを呼ぼうとするとIllegalStateExceptionが起きたりする。


いろいろめんどくさいので、現状、とりあえずcatchして、ログをはいて、ServletExceptionに包んで、さらに上にポイするで落ち着いている。
あとは、web.xmlのerror-pageが表示されればいいでしょう。と。


いろいろ書いたけど、細かいケースまで動かして検証したことがないから、頭の中がまとまらなくなってきた。
Strutsとかはこの辺りをどう実装しているのだろう？

*1:簡単なもの

web.xmlのerror-pageがちゃんと表示されない？

仕事

月曜日のこと

前々から気になっていたけど、調べるのをサボっていたことを調査してみた。


それは、『web.xmlで指定しているerror-pageが画面に表示されない。』という件。


別のプロジェクトでは出来ていたはずなんだけど、今のプロジェクトでは、ブラウザにerror-pageで指定した画面が表示されない。

とりあえず、現状以下のように設定している。

  〜省略〜
  <error-page>
    <error-code>500</error-code>
      <location>/view/FatalError.jsp</location>
  </error-page>
  〜省略〜

設定自体に間違いはないと思う。


とりあえず、最初にJSPの実行のタイミングによって、表示されたりされなかったりするんじゃないか。
と考え実験してみた。

以下のパターンで実験してみることに。

  1. JSP実行前にエラーが発生する。
  2. JSP実行中にエラーが発生する。（JSPは、errorPage有とerrorPage無の2パターン用意。）
  3. JSP実行後にエラーが発生する。

そんで、実験したみた結果。*1


errorPageを指定したJSP実行中にエラーのときのみ、エラー画面がちゃんと表示された。

他のケースでは表示されない。


なんか納得いかないので、レスポンスの中身を覗いてみる。

すると、errorPageを指定したJSP実行中にエラー以外のケースでもレスポンスボディにちゃんとエラー画面のHTMLが入っている。


何故、表示されないのだろう？


違いといえば、errorPageを指定したJSP実行中にエラーのときは、ステータスコードが200でそれ以外は500だってこと。


分からないので適当にググッてみたら、

http://members.jcom.home.ne.jp/newtype-shira/home/java/tomcaterror.html

に

ステートが"200"から"400"、"500"番台に変わったことからIEではエラーページが表示されなくなる現象が起きます。これはIEの設定(使用)がそうなっているからです。

と、さらに、

そこでIEの性質上、
256(512)バイト以上のエラーページは"HTTP エラーメッセージを簡易表示する"設定であっても表示される
事を利用し、自分で作成したエラーページを256(512)バイト以上にします

とあった。

早速、error-pageとして使用しているHTMLに半角スペースを500バイト追加してみる。


成功。
どのケースでもエラーページが表示されるようになった。


けど、これってIEだけなんだろうなぁ。。
他のブラウザ入ってないから今試すのはめんどくさい。

あと、携帯端末だとどうなるんだろう。
少なくとも、手元にある携帯エミュレータでは表示できない。*2

もし、携帯端末が、ステータスコード200以外の画面を表示できないということであれば、どうしたらいいだろう？


あと、どのステータスコードを返すかって、APサーバ別に実装が違うみたい。
これも、使うAPサーバによって調査が必要かもしれない。


とりあえず、

  • 対応ブラウザにIEがある場合は、エラーページは512バイト以上にした方がよい。
  • JSPにerrorPage属性はつけた方がいい。

ってことは分かった。

*1:環境は、JDK1.4.2_04、Tomcat5.0.24

*2:J-Skey Viewer http://www.dp.j-phone.com/dp/tool_dl/web/tool.php