要件を出すところから運用まで、一気に書いてみる

いままで、
・要件から、クラス図までに落とし込む流れ
・MVCで要件→モデルのクラス図から、コントローラーに落とし込む
・MVCで要件→画面に落とし込むまで
とまとめてきたので、それから先のプログラミングやテストまでも含めて、全部

一気に開発の最初から最後まで、書いてみました。

---

■要件から要求仕様まで
（１）要件の動詞部分に着目し、抜き出す
（２）動詞の主語、目的語を取り出し、
　　　「何々が、何々を、なんとかする」という単文の形にする
　　　→もし～ならば、「何々が、何々を、なんとかする」と、
　　　　条件がつく場合もある

（３）データ分析（クラス図の属性部分）
　　　・（２）の名詞、目的語は、「モノ」なので、これをエンティティとする
　　　・使っている帳票などを、
　　　　　　・第一正規形
　　　　　　・第二正規形（トップダウン方式、エンティティは上記クラス）
　　　　　　・第三正規形
　　　　まで行い、ER関係を明確にする（ER図、クラス図の属性作成など）

（４）機能要件の抽出（クラス図のメソッド部分）
　　　・（２）の動詞部分に着目し、現状のアクティビティ図を作成する
　　　・アクティビティをコンピューター化するとどうなるか考える
　　　・開発システムのアクティビティ図に書き換える
　　　・アクティビティ図のアクティビティをユースケースとして
　　　　ユースケース図に書き換える（やらなくても可）
　　　・（２）の名詞、つまり、主語か、目的語のクラスのメソッドに、
　　　　開発システムのアクティビティ図のアクティビティを埋める

（５）アクティビティの引数を（２）の要件から確認し、
　　　（動詞＝アクティビティ、名詞等は引数、返り値は目的とする結果）
　　　アクティビティと引数から、ユースケースシナリオを作成する
　　　（必要があれば）

（６）性能などの非機能要件をまとめる。

---

■外部設計－機能要件分析

（７）モデル部分のクラス図を作成する
　　・（３）でER図を作成していた場合、エンティティをクラスとすると、
　　　　クラスと属性が埋まる
　　　（クラス図を作っている場合も、ここまで埋まっている）　
　　・そのクラスに対して、（４）、（５）の操作で抽出したメソッドを
　　　適当に割り振って入れる
　　　割り振り方は、メソッドに対応する（２）の要件の、主語または目的語
　　　に対応するクラスに、入れる。

（８）フレームワークに何を採用するか決定する
　　　・サーブレット、struts等

（９）（７）のモデルのメソッドを以下のように用途別に分類する
　　　　・ユーザーが能動的に動かすもの
　　　　　　　画面を使ってアクションを起こす
　　　　　　　画面以外を使ってアクションを起こす
　　　　・ユーザーが意識しないけど動くもの
　　　　　　　自動的に条件がそろうと動く
　　　　　　　他アクションから呼び出し、直後に自動的に実行

（１０）フレームワークを元に、（９）のモデルに対応する（呼び出す）
　　　　コントローラーを決める
　　　・画面の場合、サーブレットを利用するなら、モデルの１メソッド
　　　　１サーブレットクラスになる
　　　　（strutsでも１メソッド１アクションクラス）

---

■外部設計－外部入出力（画面）

（１１）画面割りをきめる
　・比較的自由に決められるが、こういう決め方もある
　　（２）の要件は、
　　　主語（＝人）、目的語（＝対象物）、動詞（アクティビティ）
　　　の形なので、
　　　・まず、主語を確定する
　　　　　　＝＞ログイン画面で、操作している人を決定
　　　　　　＝＞この人が主語
　　　・目的語の画面を作成する
　　　　このとき、目的語が、複数あり、検索が必要な場合は、
　　　　　　　（検索）一覧画面（検索は画面をわけることもある）
　　　　　　　詳細画面
　　　　検索が必要ない場合は、
　　　　　　　詳細画面
　　　・１クラスに対し、CRUD(作成、（一覧）検索、更新、削除）は、
　　　　かならず必要なので、もし、メソッドがなければ補う

（１２）画面に、（１０）で決めたコントローラーを割り振る。
　　画面でイベントが起きたら、そのイベントが（１０）のコントローラー
　　を呼び出すことになるので、何らかの画面イベントにより、（１０）の
　　コントローラーがすべて呼び出されないとまずい。
　　　多くは、画面にボタンをつけて、そこから呼び出されるようにする
　　　たいていの場合、以下のようにボタン割をするとうまくいく。
　　　　・検索入力箇所（独立の画面または一覧画面と共有）：検索実行
　　　　・一覧画面：新規入力（追加）、編集、削除
　　　　・詳細画面：新規入力や編集の登録、キャンセル
　　　承認、承認拒否などの場合、一覧画面につけることも、詳細につける
　　　ことも考えられる。
　　　編集は、一覧の該当レコードのダブルクリックというケースもある。

（１３）画面遷移図をまとめる
　　　呼び出されたコントローラーが、どの画面を表示するかを確認し、
　　　画面を遷移させる。遷移しない画面が出たら、ボタンを付けて遷移
　　　させる

（１４）画面詳細をきめる
　　　モデルの引数は、すべて呼び出しコントロールあるいは、それ以前の
　　　画面において入力されていないといけない。
　　　それらをみたすように、画面項目をおいていき、値の範囲を決めて、
　　　画面詳細設計書にまとめる。

（１５）画面定義書の作成
　　（１３）、（１４）をまとめると、画面定義が出来る

---

■外部設計－外部入出力（DB）

（１６）DB定義書をまとめる
　　（３）のER図を書き換えると、DB定義書が出来る

---

■外部設計－機能要件分析　PART2（まとめ）

（１７）MVCにしたがい、各クラスを定義する
　Mについては、（７）、
　Vについては、（１５）で画面が決まっている
　　　→画面から必要なクラスはフレームワークで決まる
　Cについては、（１０）でクラスが決まっている
ので、その各クラスについて、内容を定義する。
　内容は、以下のとおりになる

・M（モデル部分）
　　コントローラーからの値をうけとり、基本的な処理をする
　　DBアクセスを行う
　　帳票、ファイル等外部入出力の操作もある。

・V（ビュー：画面部分）
　　イベントにおけるチェックなどの処理と、
　　コントローラーの呼び出し

・C（コントローラー部分）
　　引数を受け取り（処理することあり）、
　　モデルを呼び出し、
　　モデルから受け取った値を次の画面用に編集、セットする
　　次の画面を呼び出したり、書き出したりする

---

■内部詳細設計・プログラミング

（１８）（１７）できめたMVCの定義をもとに、
　　プログラム化していく
　　DBアクセスはJDBC
　　サーブレットにおける値の操作は、session操作、getParam,getWriter等
　　など、大体決まっているので（もしくはプロジェクトで決めているので）
　　それにしたがって、プログラムに落とし込む

---

■単体テスト
（１９）テスト仕様書の作成
　仕様上にでている条件を、
　IF文ならば、その条件を満たす場合と満たさない場合で
　switch文なら挙げられているケースで
　組み合わせを考え、同値条件を決める
　→ある条件が成立すると、自動的に他のじょうけんが成立する場合ははずす
　それと、境界値も考え、テストケースを仕様書に記入する

（２０）テストデータの作成
　テスト仕様書にそって、テストデータが必要なら作成する

（２１）テストに必要なプログラムを用意する
　テストプログラムは単体で動かない場合、
　　　テストプログラムを呼び出すプログラムがドライバ、
　　　テストプログラムから呼び出されるプログラムがスタブ、
　これら、スタブ、ドライバを必要なら作成する
　→ドライバとしてJUnitを使うと、きれいにテストできる

（２２）テスト実施
　テストを実施する。
　テスト仕様書にそって行い、エビデンスをとる。
　このとき、OKなら報告書にOKとする

（２３）（NGの場合）バグ票の記入
　もし、テストがNGだったら、バグ票に記入して、
　プロジェクトで決まっている人に渡す

（２４）（NGの場合）修正
　バグの担当者がバグ票を受け取り、修正

（２５）（NGの場合）修正確認
バグ票を発行した人が、（２４）の修正した旨のバグ票をもらったら、
バグが直っているかどうか確認し、確認したら、テストOKとして、
（２６）へ、NGなら、再度修正（２４）へ、

（２６）リグレッションテスト（回帰テスト）
　修正の際、新たなバグを入れている（デグレード）可能性もあるので、
もう一度、バグの箇所以外もテストしなおすことがある。
　これをリグレッションテストという。

---

■結合テスト

（２７）テスト仕様書の作成
　・画面設計書などにでてくる入力（入出力）項目に対し、
　　指定された範囲の境界値のテスト、
　　字種等のテスト、
　　SQLインジェクション、エスケープ文字、0、スペース、
　　入力しないケースなどの項目を挙げる
　・入力項目の組み合わせを行なう
　・要件を満たす場合についてのチェックを行う

それ以降は、（２０）～（２６）と同様である

---

■総合テスト

（２８）テスト仕様書の作成
　・要件仕様に書かれた、機能要件（業務）（１）にそって
　　その条件を満たしているかテスト項目をあげ、仕様書に記述する
　・要件仕様に書かれた、非機能要件（性能など）（６）に関して、
　　その条件を満たしているかテスト項目をあげ、仕様書に記述する

それ以降は、（２０）～（２６）と同様である

---

■運用

（２９）オペレーションマニュアルの作成
・要件仕様書の業務内容（１）にそって、業務手順を記述する

（３０）データ作成
・運用するためのデータを作成する
　既存のシステムからの移行の場合、データクレンジングを行ってから、
　新規システムへのデータ移行をする場合もある

（３１）移行手順・導入手順等の作成
　移行の場合、どのように移行をおこなうかの手順を作成する
　新規システムの場合、いつ、どのマシンを搬入し、どのソフトを入れるか計画

する。

（３２）納品（搬入）
　納品書を作成し、納品する。あるいはシステムを搬入する

（３３）運用
　（３１）の導入手順、移行手順に従い、実行し、
（２９）のオペレーションマニュアルに従い運用する。

---

以上っす。

JDBCのプログラムとその動作の関連、これで合ってるのかな？

JDBCのプログラム、たとえばここにあるように、ふつう

	// ドライバクラスをロード
      	Class.forName("org.gjt.mm.mysql.Driver");

	// データベースへ接続
	String url = "jdbc:mysql:///dbname?useUnicode=true";
	Connection con = DriverManager.getConnection(url);

	// ステートメントを作成して
	Statement stmt = con.createStatement();
	String sql = "SELECT * FROM TBL_A";

	// クエリーを実行して結果セットを取得
	ResultSet rs = stmt.executeQuery(sql);

という順番だと思います。このしくみ、とくに、Class.forNameで何の値もとっていないのに、DriverManagerが呼び出されるのか？について、あんまり書いていないので、多分こうなんだろうな？という勝手な妄想を書いてみたいと思います。

---

■（１）ドライバクラスをロード
　Javaのリフレクションという機能により、Class.forName("org.gjt.mm.mysql.Driver");とやるとorg.gjt.mm.mysql.Driverというクラスが、ロードされます。

　JDBCは、いろんなデータベース用で用意されているので、自分が使うデータベース用のものを、forNameの引数にします（こうすることで、引数が変われば、違うJDBCドライバが使えるようになります）

　クラスがロードされる際、staticの領域は（クラスで１つ用意する形なので）この時点で用意され、以降、staticのメソッドや値は利用できるようになります。
（new Integerとやってなくても、Integer.parseInt()というメソッドは利用できるます。これは、Integer.parseInt()がstaticだから）

---

■データベースへ接続

　上記の理由により、org.gjt.mm.mysql.DriverのクラスDriverManagerが提供する、staticなメソッドは使えるわけです。そのため、ここで、staticなメソッド、getConnectionを使って、データベースのURLに接続します。

　このgetConnectionでは、引数にもとづき、データベースのデーモンに対して、接続をこころみます。（つまり、そのデーモンのソケットに対して、書き出して、データベースにログインします）。

---

■ステートメントを作成して、実行

　接続したら、その後SQL文をつくって、executeQuery（検索）または、executeUpdate(それ以外）で、そのSQLを接続したデータベースに対して発行して、結果を受け取ります。

---

たぶん、こんなかんじかな。。

まちがってたら、ごめんなさい。

一般的な編集ソフトの作り方 その２２：画面の構成（共有メモリ）。

ワープロやドローイングソフトなどの編集ソフトを作る上での一般的な考え方を考える「一般的な編集ソフトの作り方」です。
　ここでは、主に、

　　・メモリ上に、要素をもつ
　　・イベント発生時の動き
　　・画面の構成

ということで、前回から、「画面の構成」をやっています。

　そして前回、たいてい、編集をするメインウィンドウと、属性値などをいれるサブウインドウをもっていて、サブウインドウの内容をメインウィンドウに反映させないといけないので、問題と書きました。それについて考えます。

---

■メインとサブのウィンドウ問題

　メインウィンドウとサブウインドウの問題は、これだけではなくて、メインウィンドウを２つ以上立ち上げられてしまったときのフォーカスの問題があります。
　サブウインドウで属性値を変更されたとき、どっちのメインウィンドウに対する操作なのか（フォーカスをしらべても、サブウインドウにあるだけで、どちらのメインウィンドウにもない）わからないという問題です。

---

■ウィンドウとドキュメントの問題

　また、メインウィンドウをいくつも作ったとき、同じドキュメントを編集したら、どうなるのか？という問題もあります。

---

■解決策１－メイン、サブ、ドキュメントでリンクを持つ＝問題あり

　単純に考えると、属性値変更用のサブウインドウと、メインウィンドウで相互リンクをもってしまうことです。
　こうすれば、サブウインドウで変更が起きたら、それとリンクしているメインウィンドウに変更通知を与えればできそうです。

　がしかし、２つのメインウィンドウで１つの属性値変更のサブウインドウを共有している場合、どっちのメインウィンドウ用か、良く分かりません。

---

■解決策２－共有メモリ（カオル姫方式）

　そこで、ここでいままで書いてきたカオル姫方式、つまり、

１．起動時に、共有メモリ（連想配列ないし、ハッシュマップ）を生成する
２．各画面は、その共有メモリにいれる。
　　　たとえば、メイン画面の１番目だったら、キーをmain1にして、
　　　データをその連想配列にいれる。
　　　サブウィンドウも同じく。
３．各画面では、生成時、その共有メモリをもつ
４．メイン画面のフォーカスも、その共有メモリの中に入れておく
　　　　　キー＝"currentWindow"
　　　　　値＝２でキーにした、画面名
　　メイン画面のフォーカスが変わるごとに入れ替える。
５．サブウインドウで変化が起こったら、共有メモリの"currentWindow"で
　　メイン画面名を取得、そのメイン画面名で、共有メモリを検索して、
　　メイン画面のクラスを取得する。
　　そしたら、変更処理をする

というふうにすればOKです。

---

■ドキュメントとメイン画面の関係

　で、ドキュメントも共有メモリにもてば、ドキュメントが変化したら、
そのドキュメントを利用しているメイン画面をすべて調べ、変更をかける
ということも可能です。

　可能ですが、しません。

　同名のドキュメントを開いても、別々に処理し、一方の操作が、他方に影響させないようにするのが普通です。

　そこで、共有メモリに名前を付けて入れてもいいのですが、
　メイン画面に直接ドキュメントを持たせてしまい、画面ごとに管理するという方法でも問題ないようです。