画面のテストから考えると、画面のボタンは？

まえの
画面定義書が２つのパートにわかれるとすると、画面のテストは・・・
http://blog.goo.ne.jp/xmldtp/e/ecef5a27c6cd9b9dd10f9d6832272aef

に書いたけど、画面は、画面入出力項目と、画面のボタンなどのイベントにわけられる。

で、前回の話の続きなんだけど、画面項目が１つ増えるのと、イベントが１つ増えるのでは、テストにおいては、話が違うっていうことだ。

---

具体的な例で示そう。

いま、取引先一覧（チェック項目つき）の下に、住所、電話番号、取引先名、〆日などがあり、〆日に関しては、取引先一覧を複数項目チェックし、〆日を翌月３０日払いにして、「編集」ボタンをクリックすると、すべての取引先が翌月３０日払いに更新されるものとする。

　この画面に、「担当者」項目を追加したとする。その場合、「担当者」に関するチェックをすればよい。

　その一方、ここに削除ボタンを追加する。そうすると、削除に関する項目である、取引先一覧にチェックが入っている／いないときの処理のテストのほかに、住所、電話番号、取引先名、〆日に値が入っている時でも、入ってる内容がエラーでも、入っていなくても無視されて削除されるかどうかなどをチェックしないといけない。

---

　つまり、ボタンが増えれば増えるほど、入出力項目に絡むテストが増える。
　一方、入出力項目は独立であれば、その項目Xイベント数のテストですむ（ここでもイベントが影響）

　ということで、ボタン満載の画面を作ってしまうと、テストが大変になる
　（使いやすいかどうかは・・・微妙）

　って考えると、画面割には、適切な画面割方針（テストでも困らない＆操作的にも妥協できる）があるっていうことだと思う。

（このはなし、つづく！）

UML等各種ダイアグラムのエラーチェック体系化（その１４：ダイアグラムをＲＤＢに）

シリーズ「UML等各種ダイアグラムのエラーチェック体系化」です。

　現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、
　前回までで、ダイアグラムの構成要素を、ノード、リレーション（エッジとか、アークというのが普通）、属性、属性値に分けようとしています。
　なお、ここで書いたとおり、いままでのまとめは

こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm
（ちと、更新サボってて古い）

　今回は、ＲＤＢに入れる場合の原則について書きます。

---

■ＲＤＢにいれる原則のまえに・・・

ＲＤＢに入れる原則の前に、ちょっと、構成要素のまとめ

ノードは、複数の属性を持っていて、１つの属性は、（多くは１つだけど、場合によっては複数の）属性値をもつ。

リレーション（エッジ、アークというのが普通）は、
２つのノードを結びつけ、
その結びつけに対して、複数の属性を持っていて、１つの属性は、（多くは１つだけど、場合によっては複数の）属性値をもつ。
（３つ以上結びつく場合は、２つの結びつけにわける＝ＡＢＣが結びつく場合ＡＢとＢＣにわける）

---

■原則

●ノードの種類ごとに１テーブルとする。
　ノードがもつ属性をテーブル項目とし、属性値を、テーブル項目の値とする
　ただし、属性値が複数ある属性に対しては、第一正規形をおこない、その属性で１テーブルとする。
　ノードには、ＩＤをふる。

●リレーション（エッジ、アークというのが普通）も１テーブルとし、
　テーブル中の項目に、始点のノードＩＤ，終点のノードＩＤをもつ
　　　有向グラフの場合。どちらが始点でも終点でもかまわない無向グラフの場合は、ＩＤの値が小さいほうを始点とする。
　このほか、リレーションがもつ属性をテーブル項目とし、属性値を、テーブル項目の値とする
　ただし、属性値が複数ある属性に対しては、第一正規形をおこない、その属性で１テーブルとする。
　リレーションには、ＩＤをふる。

---

■結果として・・・

ダイアグラムの凡例に描かれる要素は、１テーブルになり、
その要素の周りに書かれる説明などが、テーブルの構成要素になる。
そのほかに、２つ以上の関係を示すリレーションがある場合には、
　　テーブル中に、結びついている要素のＩＤがはいる。

---

次回は、例外とかについて