昨日のブログで、ＵＭＬを使ってヒアリングからＪａｖａプログラムまでの作成の流れについて書きました（ここ）。で、その手順では問題があることも、このブログの後半の「夕食支援システム」で説明しました。
そして、そのため、要求分析は、帳票定義からはじめたほうが良いということも、すでにブログに書いています（ここ）。
きょうは、そのブログに書いてある、「いろんな帳票やドキュメントをもらってきて、それをてきとーに整理して。。。といろいろな作業がある。これは、別の機会に取り上げよう。」についての話。
まず、プロジェクトが始まると、（提案後はもちろん、提案前から）いろんな資料を、ユーザーからいただきます。
問題は、この資料の何から見て、どう整理するかについて。
整理の仕方については、帳票や画面のドキュメントから、最終的にはＥＲ図を作っていくわけですが、これについては、佐藤正美先生がやり方を示しているっていうことは、さっきのブログに書いてある。
具体的な方法は、佐藤先生の著書、
データ設計の方法：数学の基礎とT字形ER手法 論理データベース論考
佐藤 正美著 SRC ISBN 4-88373-134-0
の１７６ページから１７９ページあたりから書いてある。
命題論理方式、コード体系方式から、エンティティを切り出せばよい
（なお、この本は、このページの、右側の図から、通してみたほうがいい。
この前のページの数学の部分は、良くわかんない割に、わかんなくっても、作業は可能です）
しかし、この本を読んでも、どの帳票、あるいは画面から分析すればよいのかは、書いていない。
ここまでを、整理しよう。
ＵＭＬの手法は確立されているが、業務分析から入る場合、業務分析できないものがある。
それらは、帳票分析によって、業務分析を推測したり、補足することでシステム化可能だ。
帳票分析についての手法は、佐藤氏の手法を参考にすれば出来る。
問題は、ただ一点、その際、どの帳票から手をつければよいかだ。
これが決まれば、一挙に手法は自動化できる。
実は、どの帳票から手をつけたらいいかということは、９０年代には分かっていた。が、その後、ＵＭＬの到来により、葬り去られてしまった。
９０年代まで、分析の主流はＤＦＤで行っていた。このＤＦＤの提唱者デマルゴによってかかれて本の和訳が、以下の本である。
構造化分析とシステム仕様
トム・デマルコ 著／高梨智弘、黒田純一郎 訳
ISBN 4-8227-1004-1 日経BP社
この本の９５ページをみてほしい。
ＤＦＤの場合、分析のスタート、つまり最上層のダイヤグラム（図）は、コンテキストダイヤグラムと呼ばれる。コンテキストダイアグラムは、システム全体をあらわす真中の楕円、その楕円に矢印で、システム外部からの（外部への）入出力が書かれる。
つまり、はじめの分析対象は、システム外部に対する入出力ということになり、とくに、ＰＭＢＯＫの関係で言えば、成果物となるシステム（スコープ計画で、成果物は定義されているはず）の出力から分析することになる。
簡単に言うと、出力から分析しましょう！！
で、出力をどう整理するのか、佐藤氏の本を読んでいただければいい。
ここでは、それを理解してエンティティが切り出せたとしよう
（っていうか、ＵＭＬの本なんかだと、そこの操作、なにもかいてないで、エンティティが切り出せることになってるけど ^^;)。
そうすると、
２つ以上のエンティティが結びついている場合、
その対応表（または対照表かな）が必要となり、
その対応関係が永続的でなければ、
時間が関係する、
すなわちイベントということになる。
イベントを行うって言うことは、
業務として行っているということなわけで、
ここで、ヒアリングからでてきた、業務と照らし合わせることで、
成果物を作成するのに必要な業務が分析できているかどうかわかる
これが出来ていれば、あとはＵＭＬの手順でプログラムまで落とせる。
つまり、出力内容からエンティティとその関係を切り出し、そのエンティティの関係が永続的かどうかで、イベント（とリソース）に分けることが出来、イベントがあるということは、そこに業務があるということが推測できる。
その業務が存在するかどうかを、ヒアリングで確かめることになる。
そして、ヒアリングのほうで、業務がでてくれば、
あとはこのまえのＵＭＬの手順に従い、クラスに分けられる。
そのクラスのうち、データソースになるものは、エンティティのリソースになっているはず。
そのことにより、ヒアリング内容がただしいか、十分かの判断が出来るってわけ。
おー、話がおそろしく抽象論になったぞ！
具体的な例をあげよう
「夕食支援システム」において、出力は、
ゆうごはん または、 ゆうごはんの出前をする発注表である
（どっちにするかは、システムの発注者との話し合いになる）
仮に、発注表だとすると、その発注表には
社員ＮＯ
出前を頼む先のお店（のＩＤ？）
頼むもの（商品）とその数
が記入されているはずである。
ここから、エンティティは、社員、お店、商品があることがわかる。
そして、これらが結びついて、発注になっている。
ここで具体的に
商品＝月見照り焼きバーガー
社員＝ウィリアムのいたずら
と考えると、ウィリアムのいたずらは、つねに「月見照り焼きバーガー」ではないので、（あれは期間限定って、そういう意味ではなく、ある日の夕食がたまたま月見照り焼きバーガーなだけという意味）ここに、日時が介在するはずである、つまり、発注という行為は、イベントである。
そう考えると、発注という業務があるはずと考えられる。ヒアリングでは、発注をどうしようか？ということを考えることになる。
もちろん、発注データ自体には、ＣＲＵＤ（クルド人ではないよ！）が存在するはずなので、発注という生成行為（＝業務）だけでなく、発注訂正（キャンセルとか数量変え）、発注削除（は、自動的だね。出前しちゃえば、もういらない）、発注検索（社員が検索するのと、この場合、お店に電話するための検索、つまり発注表作成が考えられるね）という業務も存在することが予想できる。
一方、商品、社員、お店というデータは、業務では作成されないので、これらは、マスタとして、アプリオリに存在しなければならない。
したがって、これらのマスタのＣＲＵＤも、考えなくてはならないが、「業務として意識されていないので」ヒアリングからでは、出てこないだろう（こういう、マスタ作成業務って、ヒアリングで出てこないので、作業から抜けやすいんだよね！）
と、こういうふうに分析できる。
だから、出力から分析したほうがいいんだよね。
なお、これを、入力から分析してしまうと、大変なことになる。
それは、また、別の機会に
そして、そのため、要求分析は、帳票定義からはじめたほうが良いということも、すでにブログに書いています（ここ）。
きょうは、そのブログに書いてある、「いろんな帳票やドキュメントをもらってきて、それをてきとーに整理して。。。といろいろな作業がある。これは、別の機会に取り上げよう。」についての話。
まず、プロジェクトが始まると、（提案後はもちろん、提案前から）いろんな資料を、ユーザーからいただきます。
問題は、この資料の何から見て、どう整理するかについて。
整理の仕方については、帳票や画面のドキュメントから、最終的にはＥＲ図を作っていくわけですが、これについては、佐藤正美先生がやり方を示しているっていうことは、さっきのブログに書いてある。
具体的な方法は、佐藤先生の著書、
データ設計の方法：数学の基礎とT字形ER手法 論理データベース論考
佐藤 正美著 SRC ISBN 4-88373-134-0
の１７６ページから１７９ページあたりから書いてある。
命題論理方式、コード体系方式から、エンティティを切り出せばよい
（なお、この本は、このページの、右側の図から、通してみたほうがいい。
この前のページの数学の部分は、良くわかんない割に、わかんなくっても、作業は可能です）
しかし、この本を読んでも、どの帳票、あるいは画面から分析すればよいのかは、書いていない。
ここまでを、整理しよう。
ＵＭＬの手法は確立されているが、業務分析から入る場合、業務分析できないものがある。
それらは、帳票分析によって、業務分析を推測したり、補足することでシステム化可能だ。
帳票分析についての手法は、佐藤氏の手法を参考にすれば出来る。
問題は、ただ一点、その際、どの帳票から手をつければよいかだ。
これが決まれば、一挙に手法は自動化できる。
実は、どの帳票から手をつけたらいいかということは、９０年代には分かっていた。が、その後、ＵＭＬの到来により、葬り去られてしまった。
９０年代まで、分析の主流はＤＦＤで行っていた。このＤＦＤの提唱者デマルゴによってかかれて本の和訳が、以下の本である。
構造化分析とシステム仕様
トム・デマルコ 著／高梨智弘、黒田純一郎 訳
ISBN 4-8227-1004-1 日経BP社
この本の９５ページをみてほしい。
ＤＦＤの場合、分析のスタート、つまり最上層のダイヤグラム（図）は、コンテキストダイヤグラムと呼ばれる。コンテキストダイアグラムは、システム全体をあらわす真中の楕円、その楕円に矢印で、システム外部からの（外部への）入出力が書かれる。
つまり、はじめの分析対象は、システム外部に対する入出力ということになり、とくに、ＰＭＢＯＫの関係で言えば、成果物となるシステム（スコープ計画で、成果物は定義されているはず）の出力から分析することになる。
簡単に言うと、出力から分析しましょう！！
で、出力をどう整理するのか、佐藤氏の本を読んでいただければいい。
ここでは、それを理解してエンティティが切り出せたとしよう
（っていうか、ＵＭＬの本なんかだと、そこの操作、なにもかいてないで、エンティティが切り出せることになってるけど ^^;)。
そうすると、
２つ以上のエンティティが結びついている場合、
その対応表（または対照表かな）が必要となり、
その対応関係が永続的でなければ、
時間が関係する、
すなわちイベントということになる。
イベントを行うって言うことは、
業務として行っているということなわけで、
ここで、ヒアリングからでてきた、業務と照らし合わせることで、
成果物を作成するのに必要な業務が分析できているかどうかわかる
これが出来ていれば、あとはＵＭＬの手順でプログラムまで落とせる。
つまり、出力内容からエンティティとその関係を切り出し、そのエンティティの関係が永続的かどうかで、イベント（とリソース）に分けることが出来、イベントがあるということは、そこに業務があるということが推測できる。
その業務が存在するかどうかを、ヒアリングで確かめることになる。
そして、ヒアリングのほうで、業務がでてくれば、
あとはこのまえのＵＭＬの手順に従い、クラスに分けられる。
そのクラスのうち、データソースになるものは、エンティティのリソースになっているはず。
そのことにより、ヒアリング内容がただしいか、十分かの判断が出来るってわけ。
おー、話がおそろしく抽象論になったぞ！
具体的な例をあげよう
「夕食支援システム」において、出力は、
ゆうごはん または、 ゆうごはんの出前をする発注表である
（どっちにするかは、システムの発注者との話し合いになる）
仮に、発注表だとすると、その発注表には
社員ＮＯ
出前を頼む先のお店（のＩＤ？）
頼むもの（商品）とその数
が記入されているはずである。
ここから、エンティティは、社員、お店、商品があることがわかる。
そして、これらが結びついて、発注になっている。
ここで具体的に
商品＝月見照り焼きバーガー
社員＝ウィリアムのいたずら
と考えると、ウィリアムのいたずらは、つねに「月見照り焼きバーガー」ではないので、（あれは期間限定って、そういう意味ではなく、ある日の夕食がたまたま月見照り焼きバーガーなだけという意味）ここに、日時が介在するはずである、つまり、発注という行為は、イベントである。
そう考えると、発注という業務があるはずと考えられる。ヒアリングでは、発注をどうしようか？ということを考えることになる。
もちろん、発注データ自体には、ＣＲＵＤ（クルド人ではないよ！）が存在するはずなので、発注という生成行為（＝業務）だけでなく、発注訂正（キャンセルとか数量変え）、発注削除（は、自動的だね。出前しちゃえば、もういらない）、発注検索（社員が検索するのと、この場合、お店に電話するための検索、つまり発注表作成が考えられるね）という業務も存在することが予想できる。
一方、商品、社員、お店というデータは、業務では作成されないので、これらは、マスタとして、アプリオリに存在しなければならない。
したがって、これらのマスタのＣＲＵＤも、考えなくてはならないが、「業務として意識されていないので」ヒアリングからでは、出てこないだろう（こういう、マスタ作成業務って、ヒアリングで出てこないので、作業から抜けやすいんだよね！）
と、こういうふうに分析できる。
だから、出力から分析したほうがいいんだよね。
なお、これを、入力から分析してしまうと、大変なことになる。
それは、また、別の機会に
アクセス
トータル
ランキング
