画面定義をHTMLで行い、呼び出しをWebAPIでやる設計手順の試案 その５ CRUD図

　なぜか、シリーズ化してしまった、「画面定義をHTMLで行い、呼び出しをWebAPIでやる設計手順の試案」です。

　やろうとしてるのは、
・HTMLで画面を作成し、

・AJAXでサーバ呼び出し、結果はXMLで受け取ったものを利用すると

・画面とサーバーが完全に分離する上に
　画面から、逆にさかのぼって要求仕様にまでもっていける
　→COBOLのシステムをＷｅｂに置き換えたいけど、ドキュメントもソースも無いときなんかに、利用できる

　で、いままで、以下の手順で、画面からWebAPIを割り出し、ER図まできました。

●HTMLからサービスを抽出する
（１）画面をHTMLで作成する（ここがスタート）
（２）アクションなど、イベントを拾うところで、
　　　　onイベント=ファンクション
　　　として、とにかく、ファンクションをfunctionでつくってしまう
（３）作った関数について
　　　サーバーアクセスするものは、関数の中に
　　　　　sv_access(呼び出し元、呼び出したいサーバーアプリ,""）
　　　みたいなかんじで、ダミー関数を書く
（４）grepで、（３）のダミー関数（sv_access)を、一覧で取得
（５）検索した内容をファイルに保存し、Excelで読み込み、
　　　WebAPIのサービス一覧を取得する
（６）でてきた呼び出したいサーバーアプリ＝サービスを、
　　　１サービス１シートで、Excelシートにまとめる

●クライアント－サーバー分離
（７）クライアント側の画面と、サーバー側を完全に分離するためのダミーCGIを入れます。

●第二正規形の手法を使って、ER図にもっていく
（８）引数を入力データ項目、返り値を出力データ項目とし、
　　　それらが、一時的なものか、永続的データかを決める。

（９）永続的データをエンティティと属性部分に切り分けます。

（１０）エンティティごとに、属性を書き足していきます

（１１）一意にできるものがあったら、そいつを主キー、
　　　　なければ番号をつけて主キーにして

（１２）エンティティは完成

（１３）この場合、繰り返しがあったら、別エンティティにして第一正規形
　　　　エンティティ内で、ある値がきまったら、必ず他の値も決まった値になる
　　　　という第三正規形があったら、分けたかったら分ける。

（１４）外部のエンティティの主キーを参照キーとして持てば、
　　　　他の値は持つ必要がなければいいやつは、参照キーだけをもちます。

（１５）参照キーと主キーから関係は出ます。
　　　　カーディナリティは、主キーのほうが１、参照キーのほうは、０～N,
　　　　エンティティは（１２）で完成したので、

（１６）ER図がかけます。

　今回は、前回の（１０）でサービスに番号を振っておいて、属性を書き足したとき、そのサービス番号も書いておくと、後述する、検算のとき便利です。と書いた、検算についてです。

---

■CRUD図を作成し、矛盾を確認する

で、次の作業は、エンティティの属性の生成、書き出し、読み込み、削除が、WebAPIで矛盾なく行われているかを確認するため、CRUD図を描きます（っていっても、属性までやるのはめんどっちかったら、エンティティレベルでもOKだし、これ自体省略しちゃうことも多いと思うけど。。）なので、（１８）は、

（１８）CRUD図を描いて、検算する

　で、CRUDとは、イラクの。。って、今日２度もしょーもないギャグを書いてもなんなので、まじめにかくと、
ここ　http://www.ne.jp/asahi/ikeda/home/PCword/word/CRUD_Diagram.html
にあるような図です。

　横のテーブルのところにエンティティ（ないしはエンティティの属性）、
　縦の機能のところがWebAPIになります。

　ここで、R＝読み込みときている場合、C＝生成の機能が、順番的に前に呼び出されないとへんです。また、C＝生成がない場合は、DBにあらかじめ、データが登録されているマスター項目の内容のはずです。

　マスターで初めからデータがはいってもないし、かつ、だれも作らないのに、読み出したり、更新したら、それはへんです。

　削除は、ないってこともあります。
　１つは、手作業で削除するケース、
　他には、絶対件数が増えない（たとえば、各テーブルの件数を持っているなど）ので削除する必要はないケースです。
　なので、削除がなくてもOKなのですが、あったほうがいいかどうかを考えます。なお、Cする前にDしたらおかしいですし、Cして、Dするだけも変です（つまり、まったく読むことがないのに削除する）Cだけもへんです（つくるだけ、だれもよまない。。いらないジャン＞＿＜！）

---

　てなことで、矛盾を考えます。
　矛盾してたら、たいてい、WebAPIで引数がたりないか、サービスが足りないか、エンティティが間違っているので、なにが悪いか考えて直しましょう。

---

で、このシリーズの次回は、DFD（相当）を作ります。

開発の初めから順番に書いていってみる その３３：外部設計（１０）作成ドキュメント。

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　今、外部設計の段階で、前回までで、やることについては、一通り書きました（１個だけ書いていないことがあり、それは今回書きます）。
　なので、今回は、その成果物として作成するドキュメントの話題を中心に書きます。

---

■外部設計の成果物
　外部設計が、入出力＋詳細までの落とし込みである以上、ドキュメントも入出力の部分と詳細までの落としこみの両方があります（それ＋αがあります）

●入出力のドキュメント
　入出力については、入出力の種類ごとに、定義書があります。

　　画面があれば、画面定義書
　　帳票があれば、帳票定義書
　　DBがあれば、テーブル定義書（データベース定義書でもいいけど）
　　ファイルがあれば、ファイル定義書
　　　　：
　　　　：

　などなど。。
　で、これらの定義書の形式は、だいたいおなじ。
　

　・目次代わりに、画面／帳票。。。などの一覧があります。

　・どの手順でそれらの入出力を行うかを書いたものがあります
　　　　画面だと画面遷移図
　　　　通信だと、シーケンス図などなど。。
　　ただし、帳票やDBでは、順番もないので、ここが省略されます。
　　　　でも、テーブルの場合、代わりにCRUDやER図をいれることもあります。
　　　　CRUDとは、イランなどに住む民族（クルド人）のことです
　　　　。。っていうのはうそで、生成（C)、参照（R),編集（U),削除（D)
　　　　されるタイミングをしめすため、
　　　　　　　行か桁のどちらかにテーブル、
　　　　　　　どちらかにモジュール名（クラスでも、プログラムでもOK)
　　　　を書いて、直行するセルに、上記C,R,U,Dを記入した図です。
　　　　（後述の「UI08ユースケーステーブルマトリクス」がそれにあたります）

　・各画面、帳票などの説明です
　　　　はじめに、レイアウトやフォーマットなどの図がきます
　　　　次に項目説明です
　　　　アクションがある場合、アクションの説明があるときもあります
　　　　（項目の一種として説明し、ないときもあります）
　　　　DBの場合、インデックスについて書かれるなど、その入出力固有の情報
　　　　が付け足されることもあります。

　と、こんなかんじです。

---

■詳細までの機能について

　機能関係のドキュメントとしては、機能定義書（機能設計書）として、
　　　DOAの場合、DFD、最終的にはミニスペックまで
　　　オブジェクト指向の場合、クラス図＋シーケンス図など
　までかかれます。

　あと他に、プログラム間のデータのやり取りを示すため、
　　　データ定義（インターフェース定義）
　　　データタイプ定義
　などが必要になる場合があります（とくにDOAの場合。オブジェクト指向は、受け渡しデータもクラスなので、クラス図になってしまう）。

　ただし、前回、共通部分ということで、ライブラリのほか、メッセージやコード定義などがあるという話を書きました。
　これらの定義書もまとめます。

---

■ユースケースシナリオを書く場合もある
　で、今日の初めに、ひとつ説明してなかった話というのが、これになります。
　ユースケースシナリオは要求分析段階でもできているかもしれませんが、画面をちゃんと定義した形っていうのは、ここになります。

　このとき、ユーザーに画面定義をみてもらっても？？？になるかもしれません。
　そこで、ここで、ユースケースシナリオを作成し、文章で、どういう手順でなにを入力すると、どーなるかを書くことがあります。

---

■まとめると、外部設計の成果物はこんなかんじ

　ここで、画面と帳票とDBがある場合、結局外部設計でできる成果物は、こんなかんじです。

●入出力関係
　　　・画面定義書（画面遷移図、項目、アクション、一覧）
　　　・帳票定義書（帳票レイアウト、項目、一覧）
　　　・テーブル定義（テーブル定義、一覧、ER、CRUD等の関連図）

●機能関係
　　　・機能定義（DFD＋ミニスペックまたはクラス図+シーケンス図、データ定義）
　　　・コード定義
　　　・共通メッセージ定義

●ユースケースシナリオ－作りたければ。。

---

■富士通の公開されている作業標準との比較

　で、ここでいつも、富士通の公開されている作業標準、
1.ComponentAA開発標準
http://segroup.fujitsu.com/sdas/technology/develop-guide/1-caa.html
と比較しているので、今回も比較しましょう。

SSドキュメントとUIドキュメントが、これにあたります。
うち、SSドキュメントは機能関係の「機能定義」にあたるのですが、さっぱり意味不明になるとおもうので、まあ、そーいうことで、UI定義書とのこりの上記ドキュメントとの関係を見てみます。

　実は、「富士通の公開されている作業標準」の場合、「UI02 ユースケース機能記述」に、多くのドキュメントがまとまってしまっています（UI02のなかに、いくつものドキュメントがある）。そのため、これを崩さないと対応関係が見れません。以下、くずして、その対応関係を書きます。

●入出力関係
　　　・画面定義書
		UI02-01	画面遷移図
		UI02-02	画面レイアウト定義
		UI02-03	画面項目定義
		UI02-04	アクション総括記述
		UI02-05	アクション定義　遷移元
		UI02-06	アクション定義　遷移先
		UI03	画面一覧
　　　　　　（UI02-04～06は、機能関係のほうがいいかも？？）

　　　・帳票定義書
		UI02-09	帳票レイアウト定義
		UI02-10	帳票項目定義
		UI04	帳票一覧

　　　・テーブル定義
		UI05	テーブル関連図
		UI06	テーブル一覧
		UI07	テーブル／ファイル定義
		UI08	ユースケーステーブルマトリクス
	　　　（UI05はER図、UI08はCRUD図です。UI08は、機能関係のほうがいい？）

●機能関係
　　　・機能定義
		UI01	ユースケース一覧
		UI02-07	バッチ機能概要
		UI02-08	バッチ統括記述
		UI02-11	出力データ処理定義
		UI02-12	入力データ処理定義
		UI10	システム間インターフェース一覧
		UI11	システム間インターフェース定義
		UI14	データタイプ定義
		SSxx	各種SSドキュメント
	　　（画面の場合は、UI02-04～06の内容がここにも入ります）

　　　・コード定義
		U13	コード定義

　　　・共通メッセージ定義
		U14	業務メッセージ定義

●ユースケースシナリオ－作りたければ。。
		U15	シナリオ記述
		U16	業務サービス仕様

　となっています。ウィリアムのいたずらとは、ちがった観点から、ドキュメントをまとめているみたいですね（もちろん、どちらが正解ということはないので、こういうまとめ方でもOK)
　詳しい内容や書き方に関しては、ダウンロードしてくると、書いてあるので、興味がある人は、そっちをみてください。

---

　ということで、外部仕様に関しては、おしまいで、
　次回のこのシリーズでは、内部詳細設計について入ります。