設計段階でよく利用されるDFD、CRUD、ER図。それぞれ「何のために作成するのか？」「どのように作成するのか？」について紹介します。
そもそも設計書は必要か？
小規模なソフトウェアの作成であれば簡単なメモ程度の内容で設計を済まし、すぐにテストコード、実処理のコードを書いても良いと思います。設計書よりもきちんと動くソフトウェアのほうが価値があるからです。要求を聞いて、すぐできそうだな(1日でコーディング、テストができそう)と思ったらソフトウェアを作成しユーザに早く評価をもらうことが大事だと思います。設計書を作成すると仕様が変わるたびに書き直す手間もかかるので、要求が頻繁に変わりそうな場合も詳細に作成しないです。
それに対し、規模が大きくてコーディングやテストに何日もかかりそうな場合、時間を確保して設計書を作成します。設計書がないと、一度に複数のことを考えながらコーディングすることになり、バグを作ってしまったり、機能やデータの漏れ・重複が生じやすくなります。
どの程度の設計書が必要なのかというのはシステムによりますが、ここで紹介する一般的な設計書の目的、書き方などを抑え、必要に応じて作成できるようにしておくことをおすすめします。
DFD
DFDは、「システムの機能」と「システムで扱うデータ」の流れを表現する図です。私はあまり作成したことがないですが、よく作成されたものを見ることがあります。
次のような図になります。パソコンで作成するのが面倒なので、A4用紙に記述してます。
DFDは、4つの図記号で構成されてます。
| 記号 | 概要 |
|---|---|
| 四角 | データの発生源と吸収先 |
| 矢印 | データの流れ |
| 丸 | プロセス 最低１つずつ入力と出力のデータフローを結びます。 入力を受け付けて何らかの変更を加え出力します。 |
| 2本の平行線 | ファイル(データの滞留場所) |
DFDを作成する目的としては、
- 他のメンバーとシステムイメージを共有
- 既存システムの全体像を説明するのに活用
- 機能の漏れ、重複がないように分割
- プロセスの詳細化
などが考えられます。
プロセスの詳細化を行うと、一度に検討するプログラム量が最小限になり、コーディング時に部分ごと集中して取り組むことができます。また、プロセスごとに人員、時間を割り当てて作業の段取りを組むことができます。
DFDからは、次のことを読み取ることができません。
- 処理タイミング(いつ、どのような条件でデータを処理するのか？)
- 処理の順序(逐次的に実行なのか？並行的に実行するのか？)
CRUD
CRUDとは、Create（生成）、Read（読み取り）、Update（更新）、Delete（削除）の頭文字を並べた用語です。「DFDのプロセス」と「DFDのファイル」関係を表形式で表現した図を作成します。下記の図はExcelで作成してみました。
処理とデータの関係が明らかになるので、テーブルの仕様が変更されたとき、どの処理に影響がでるのか判断することができます。
私自身はCRUDを作る機会があまりないです。処理とデータの関係は他のところからも判断できるためです。例えば、Webアプリであれば、URL設計書などから、リソースに対するHTTPメソッド(GET,POST,PUT,DELETE)で処理とデータの関係がわかります(複数テーブル更新する処理とかもありますが)。
やはり、システムに応じて作るかどうか決めます。
ER図
データベースを設計する際に利用します。ER図を作成することで、複数個所でマスタとなるデータをばらばらに持ってないか確認できたり、データの関連性を説明するのに活用することができます。マスタとなるデータをばらばらに持つと、ある業務で入力したデータを別の業務で重複して入力することになり、データの整合性が保てない、入力の手間が増えるなどの問題が生じます。個人的にER図は必須だと思っています。
下記のER図はCacooで作成してみました。IDEF1X (Integration Definition)記法で書いてます。(ER図は、IE記法(後述)で作成することをおすすめします)
ER図はデータを3つの構成要素で表します。
| 要素 | 概要 |
|---|---|
| エンティティ | データのまとまり。実体のあるもの(人、物、場所、金)だけでなく、概念(やりとり、分類)も対象となります。 ※エンティティの区分け イベント系エンティティ ⇒「受注情報」 リソース系エンティティ ⇒「ユーザ情報」「商品情報」 |
| アトリビュート | エンティティに関する情報です。 |
| リレーション | 「1対多」など数の関係を表します。 |
多重度(カーディナリティ)
リレーションには多重度(カーディナリティ)を記述できます。以下、IE (Information Engineering)記法で書いてます。
Aに対してBは、0または1つ存在(下限が0で上限が1)
Aに対してBは、1つ存在(下限が1で上限が1)
Aに対してBは、0以上存在(下限が0で上限が多)
Aに対してBは、1つ以上存在(下限が1で上限が多)
例
ER図上では以下のように使われます。
AとBは、「1対0以上」の関係であることがわかります。同じ関係を以下のように書かれることもあります。
例えば、「Bテーブルのレコード一覧」に「Aテーブルの情報」を付随して表示したい場合、以下のようにクエリを書きます。
SELECT *
FROM B
LEFT JOIN A
ON B.xxx = A.xxxエンティティの抽出方法
ER図の作成は、トップダウンアプローチとボトムアップアプローチがあります。トップダウンアプローチでは、業務ルールなどから全体的に必要なエンティティを抽出して、徐々に詳細化していきます。ボトムアップアプローチでは、既存の帳票などから属性を抽出して、それを徐々に統合していきます。
