このページでは、DFDの記号と作る順番、データディクショナリとミニスペック、データ中心設計とCRUDマトリクス、状態遷移図とペトリネット図がわかります。
- 一言で言うと：
- システムに求められることを、何に注目して図や表にし、仕様や設計に落とすかの話
- 「データの流れ」に注目する構造化分析（DFD）、「データそのもの」と「処理」のどちらを先に設計するか、「事象と時間」に注目する事象応答分析（状態遷移図、ペトリネット図）が出てくる
データの流れを図にする（構造化分析・DFD）→ データと処理、どちらを先に作るか（プロセス中心／データ中心）→ 事象と時間の関係を図にする（事象応答分析）
覚え方の軸
- 3つの項は「何に注目するか」で分かれる
- 構造化分析はデータの流れ（DFD）
- プロセス中心／データ中心設計はデータか処理か（どちらを先に設計するか）
- 事象応答分析は事象と時間（状態遷移図、ペトリネット図）
- DFDは「4つの記号＋1つのルール」
- ○プロセス、□源泉・吸収、＝データストア、→データフロー
- データストアや外部（□）どうしは、必ずプロセス（○）をはさむ
- モデル化の順番は「物理 → 論理 → 論理 → 物理」のサンドイッチ
- 現物理 → 現論理 →（新しい要件を足す）→ 新論理 → 新物理
- 今の姿をありのまま書き、物理的な仕組みを抜き、新しい要件を足し、最後に物理的な仕組みを戻す
- データは変わりにくく、処理は変わりやすい
- だから、安定したデータを先に設計するデータ中心設計のほうが、変更に強い
- 事象応答分析の図は「1つずつ順番か、並行か」で使い分ける
- 状態が1つずつ順に変わるなら状態遷移図・状態遷移表
- 並行して動くものの同期を表すならペトリネット図
構造化分析法：データの流れを図にして、仕様をまとめる（★）
- 構造化分析法（SA：Structured Analysis）：
- デマルコ（De Marco）が提唱した
- システムの機能間のデータの流れに注目して、システムの要求を仕様にまとめる技法
- DFDでデータとプロセスを図にするだけでなく、データディクショナリやミニスペックも使って、構造化仕様書を作る
- 構造化設計（SD：Structured Design）：
- 構造化分析で得たDFDの各プロセスを、トップダウンでモジュールに分割していく手法（モジュール分割は後述）
- リアルタイム構造化分析：
- DFDに「コントロール変換とコントロールフロー」を加えた変換図（制御フロー図）を使い、制御とタイミングを表す
① DFD（データフローダイアグラム）
- DFD（Data Flow Diagram）：
- 業務の処理と、その間で受け渡されるデータの流れを図にしたもの
- 3つの要素（プロセス、源泉と吸収、データストア）と、データフローで表す
- 例えば、宅配便なら、荷物（データ）が、お客さん（源泉）→ 受付（プロセス）→ 倉庫（データストア）→ 配達（プロセス）→ 届け先（吸収）と流れる様子を図にする
| 記号 | 名前 | 意味 |
|---|---|---|
| ○ | プロセス（処理） | データの加工や変換 |
| □ | 源泉（データの発生源）、吸収（データの行き先） | データの発生源、または最終的な行き先（システムの外の人や組織） |
| ＝（2本線） | データストア | ファイルやデータベースなど、データの蓄積 |
| → | データフロー | データの流れ |
- DFDのルール（参考、ひっかけ注意）：
- データストアどうしや、データストアと外部（源泉・吸収）は、データフローで直接つながらない。必ずプロセスをはさむ
- 例えば、倉庫から倉庫へ荷物が勝手に動くことはない。必ず誰か（処理）が運ぶ
- DFDに書くこと・書かないこと（参考、★）：
- 正常処理を中心に書く
- 異常処理や例外処理は書かない。制御手順も書かない
- 異常処理や例外処理は、ミニスペックに書く
② システムのモデル化：DFDを作る順番（★試験に出る）
- モデル化の順番：
- 現物理モデル → 現論理モデル → 新論理モデル → 新物理モデルの順にDFDを作る
- 試験では、この作成順が問われることがある
| 順番 | モデル | 中身 |
|---|---|---|
| 1 | 現物理モデル | 今の業務の流れを、組織名・媒体・処理サイクルといった物理的な仕組みも含めて、ありのまま書く |
| 2 | 現論理モデル | 現物理モデルから物理的な仕組みを取り除き、データと処理を中心に書いて、必要な業務機能と情報をはっきりさせる |
| 3 | 新論理モデル | 現論理モデルに、新システムへの論理的要件を加え、新システムの機能と情報を書く。この段階で、DFDのほかデータディクショナリやミニスペックも作る |
| 4 | 新物理モデル | 新論理モデルに、新システムへの物理的要件を加え、新システムで業務をどう行うかの仕組みを書く |
- モデル化の例え：
- 部屋の模様替えなら、1は「今の部屋の写真を撮る」
- 2は「家具のブランドや色は気にせず、『寝る・食べる・仕事する』場所がどこにあるかだけ書き出す」
- 3は「新しく『勉強する』場所を足して、配置を考える」
- 4は「実際に買う家具や置き場所を決める」
- 物理的な仕組み：
- 「誰が（組織名）」「何で（紙、FAXなどの媒体）」「いつ（毎日、月末などの処理サイクル）」のような、具体的なやり方
- 論理：
- 具体的なやり方を抜いた、「どんなデータを、どう処理するか」という本質
③ DFDの作成：トップダウンで細かくしていく
- DFDの作り方：
- 上から順に階層化していくトップダウンアプローチで作る
- コンテキストダイアグラム → レベル0ダイアグラム → レベル1ダイアグラム →…と、下のレベルへ順に作る
- コンテキストダイアグラム：
- プロセスが1つだけ書かれた、最上位のDFD
- 対象システムの最終的な源泉と吸収を表したもの
- 例えば、「システム全体」を1つの丸にして、外の誰とデータをやりとりするかだけを書く
- レベル0ダイアグラム：
- コンテキストダイアグラムの1つのプロセスを、いくつかのプロセス（1、2、3…）に分けたもの
- レベル1ダイアグラム：
- レベル0の中のプロセス（例えばプロセス2）を、さらに細かく分けたもの（2.1、2.2、2.3…）
- そのため、プロセス2に出入りするデータフローは、レベル1の中のどれかのプロセスに引き継がれる（上下で出入りがそろう）
- 例えば、地図の拡大。日本地図の「九州」を拡大すると県が見えるが、九州に出入りする道は、拡大した地図でもどこかの県につながっている
④ データディクショナリとミニスペック
- データディクショナリ（データ辞書）：
- 階層化したすべてのDFDにある、データフローのデータと、データストアを構成するデータの内容を定義したもの
- 例えば、「注文データ＝注文番号＋顧客ID＋商品コード＋数量」のように、データの中身を書く
- ミニスペック（ミニ仕様書）：
- 最終的に詳細化された基本的なプロセス、つまり最下位のDFDの機能仕様書
- 機能仕様書といっても文章ではなく、構造化された自然言語やデシジョンテーブルなどを使う
- DFDに書かない異常処理・例外処理もここに書く
- 見分け方：
- データディクショナリはデータの中身、ミニスペックは処理の中身
システム開発プロジェクトのライフサイクル
- デマルコの構造化技法をもとにしたライフサイクル：
- 1 調査 → 2 構造化分析 → 3 ハードウェアの調査、4 構造化設計 → 5 開発
- 各工程の入力と出力：
- 1 調査は、ユーザの要求からフィージビリティ資料（実現可能性の検討結果）を出す
- 2 構造化分析は、フィージビリティ資料とユーザの要求から、予算・スケジュール、物理的要求、構造化仕様書を出す
- 3 ハードウェアの調査は、物理的要求から、ハードウェアとシステム構成データを出す
- 4 構造化設計は、構造化仕様書とシステム構成データから、パッケージ化した設計とテスト計画を出す
- 5 開発は、それらをもとにシステムを作る
- 構造化分析の入出力のまとめ：
- 入力（情報源）は、現状調査の結果（実現可能性の検討結果）とユーザ要求
- 主な出力は、物理的要求、構造化仕様、予算とスケジュール
プロセス中心／データ中心設計技法：データと処理、どちらを先に作るか（★）
- ソフトウェア設計で分析・設計するもの：
- 「操作対象であるデータ」と、「操作内容であるプロセス（機能）」の2つ
| データ | プロセス | |
|---|---|---|
| 正体 | 業務で生成・参照・変更・削除される値の集まり | 業務を行うための処理・手順 |
| 何で決まるか | 対象業務の特性で、内容や構造が決まる | 業務機能をどう分けて階層化するかで決まる。同じ業務でも構造はいろいろ |
| 影響を受けるか | 生成・参照などのやり方・順序・タイミングに影響されない | − |
| 業務要件が変わると | 影響が少ない（静的、安定） | 影響を受ける（動的） |
- データのライフサイクル：
- データが生成されてから削除されるまでの流れ
- データとプロセスの例え：
- 料理なら、データは食材、プロセスはレシピ
- 献立（業務）が変わってもレシピはすぐ変わるが、冷蔵庫の食材の種類はあまり変わらない
① プロセス中心設計
- プロセス中心設計：
- ソフトが果たす機能に注目し、データより先にプロセスを設計し、プロセスに合わせて必要なデータを設計する手法
- プロセス中心アプローチ（POA：Process Oriented Approach）：
- プロセス中心に開発するという考え方
- プロセス中心設計の短所①：
- データがプロセスに依存する
- データを共有資源と考えずに設計するので、データ構造がプロセスに依存したものになる
- 業務要件が変わって機能を変えると、プロセスだけでなく、関係するデータも変更が必要になる
- プロセス中心設計の短所②：
- プロセスが重複する
- 機能を分解して定義する「機能構造化」の考え方をもつ設計法
- 複数の要件をもとに機能を展開すると、プロセスの重複が起きることがある
- 重複するとソフトが肥大化・複雑化し、機能変更が多いシステムでは変更容易性が低く、すばやく対応しにくい
- プロセス中心設計の例え：
- 料理ごとに専用の食材を買ってくる。献立が変わるたびに買い直しになり、同じ食材があちこちにだぶる
② データ中心設計
- データ中心設計：
- 安定した情報資源であるデータ構造に注目し、データの設計を先に行う手法
- 業務プロセスと切り離して、先にデータを共有資源として設計し、それをもとにプロセスを設計する
- プロセスに依存しない、データ本来の構造を設計する
- データ中心アプローチ（DOA：Data Oriented Approach）：
- データ中心に開発するという考え方
- データ中心設計の長所：
- 機能変更で業務プロセスが変わっても、データへの影響は少ない
- 変更容易性の高いシステムを作れる
- データ中心設計の例え：
- 先に冷蔵庫の食材をそろえて整理しておき、献立はそれを使って決める。献立が変わっても食材はそのまま使える
データ中心設計による開発手順
- データモデリング：
- 対象領域のすべての業務のデータモデリングをする
- E-R図やUMLなどを使う
- データの標準化：
- 共有資源となるデータを標準化（正規化）し、データの重複をなくす
- 標準プロセスの設計：
- 標準データに固有の操作、つまりデータのライフサイクルを扱うプロセス（標準プロセス）を設計する
- 一体化：
- 標準データと標準プロセスの1対1の関係を作る
- ソフトウェア設計：
- 一体化した標準データと標準プロセスを、共有資源（標準部品）として使い、個々のソフト（プログラムA、プログラムBなど）を設計する
- 各プログラムは、標準プロセスを呼び出して使う
- 手順でなくせる重複：
- ②で、データ資源の重複をなくせる
- ③と④で、データを更新するプロセスの重複もなくせる
- 一体化の考え方：
- データとそれを扱う処理をセットにするので、オブジェクト指向（後述）の考え方に近い
③ CRUDマトリクス：どの処理が、どのデータを、どう扱うか
- CRUDマトリクス（CRUD図、エンティティ機能関連マトリクスともいう）：
- どのデータ（エンティティ）が、どのプロセス（機能）によって、生成（Create）・参照（Read）・更新（Update）・削除（Delete）されるかを、マトリクス（表）にした図
- データごとに4つのイベントを整理することで、データモデルが適切か、データとプロセスの整合性を検証できる
- CRUDマトリクスの書き方：
- 標準の書き方はない
- 「データ」の下にC・R・U・Dの列を作り、プロセスごとに○を付ける書き方もある
- 試験での扱い（試験）：
- 過去の午後試験ではCRUDマトリクスを完成させる問題が出たが、近年は詳しく問う問題は出ていない。概要を覚えておけばよい
| 着眼点 | 見つかったら、どうする？ |
|---|---|
| ①プロセスとの関連がまったくないデータ | プロセスが足りないか、不要なデータがないか見直す |
| ②C・R・U・Dのどれかが欠けているデータ | 4つ全部が対象業務の中で処理されるのが望ましい。一部が他の業務で行われるなら、取り込めるか検討する。取り込めなければ、他の業務とのインタフェースをはっきりさせる |
| ③C・R・U・Dが1つの機能に集中しているデータ | 別々のプロセスで処理できないか検討する |
| ④あるデータの発生（C）に関わるプロセスが複数ある | 発生に関わるプロセスを1つにまとめる |
| ⑤複数のデータの発生（C）や消滅（D）に関わるプロセス | プロセスを分割し、複数のデータの発生や消滅をしないようにする。ただし、データどうしが関連していれば分割しなくてよい |
- CRUDマトリクスの例え：
- 会員カードなら、入会受付が「作る（C）」、レジが「見る（R）」、住所変更窓口が「書き換える（U）」、退会受付が「捨てる（D）」
- 作る窓口が2つあると、二重に作られるおそれがある（④）
事象応答分析：事象と時間の関係を図にする（★）
- 事象応答分析：
- 外からの事象（例えば、マウスのクリック）と、それに対する応答（システムやソフトの動作）のタイミングなど、時間的な関係をすべて取り出して、制御の流れを分析すること
- 使う図は、状態遷移図・状態遷移表と、ペトリネット図
① 状態遷移図と状態遷移表
- 状態遷移図：
- 時間の経過や状況の変化に応じて状態が変わるシステムの動作を書く図
- プロセス制御などの、イベントドリブン（事象駆動）の処理の仕様を表すのに向いている
- 状態遷移表：
- 状態遷移図を表の形で表したもの
- 向いている場面：
- 「システムの取り得る状態が有限個で、次の状態は、今の状態と起きた事象だけで決まる」場合
- 例えば、信号機。「青のときに時間が来たら黄色になる」のように、今の色と出来事で次の色が決まる
例：200円のチケットの券売機（使える硬貨は50円と100円、1枚ずつ入れる）
- 状態：
- S1は「初期・終了」、S2は「投入合計50円」、S3は「投入合計100円」、S4は「投入合計150円」
- 状態遷移図の読み方：
- 矢印に「入力／出力」を書く
- 「＊」は、何も出力しないという意味
- 例えば、S4からS1への「100／チケット＋50」は、「S4で100円が入ると、チケットとお釣り50円を出してS1に戻る」
| 条件 ＼ 状態 | S1（初期・終了） | S2（投入合計50円） | S3（投入合計100円） | S4（投入合計150円） |
|---|---|---|---|---|
| 50円硬貨投入 | → S2 | → S3 | → S4 | チケットを出す → S1 |
| 100円硬貨投入 | → S3 | → S4 | チケットを出す → S1 | チケットとお釣り50円を出す → S1 |
- 状態遷移表の読み方：
- 「状態S2のとき100円が入ると、状態S4に移る（出力はなし）」
- 「状態S4のとき100円が入ると、チケットとお釣り50円を出して、状態S1に移る」
- 例題（状態遷移）：
- S1から、50円 → 100円 → 100円 → 50円の順に入れると、何が出て、最後はどの状態か
- 例題の答え：
- 50円で、S1 → S2（出力なし）
- 100円で、S2 → S4（合計150円。出力なし）
- 100円で、S4 → S1（合計250円なので、チケットとお釣り50円が出る）
- 50円で、S1 → S2（出力なし）
- チケットが1枚とお釣り50円が出て、最後はS2（投入合計50円）
② ペトリネット図（★発火のルールがよく出る）
- ペトリネット図：
- 並行して動く機能どうしの同期を表せる図
- 非同期に起きる情報の流れと、その制御と同期のタイミングを表すのに使う
- システムをトランジション（事象）とプレース（状態）で表し、トークン（印）の移り変わりとトランジションの発火で、並行動作を書く
- ペトリネット図の構造：
- 2種類の節点（○と−）をもつ有向2部グラフで表される
| 図形 | 名前 | 意味 |
|---|---|---|
| ○ | プレース | 状態 |
| −（太い横棒） | トランジション | 事象 |
| ●（プレースの中の黒丸） | トークン | 印。システムの状態は、プレースに置かれたトークンで表す |
- 発火の条件：
- トランジションのすべての入力プレースが、それぞれトランジションへ向かう矢印の本数以上のトークンを持ったとき、発火する
- 発火したとき：
- 各入力プレースから、矢印の本数分のトークンがなくなる
- 各出力プレースに、入る矢印の本数分のトークンが加わる
- 矢印の書き方：
- 必要な数だけ矢印を描くのではなく、1本の矢印に必要な数を書き添える書き方もある
- ペトリネット図の例え：
- 二人三脚のスタート。「Aさんの準備OK」と「Bさんの準備OK」の両方に印がそろったら、「スタート」（発火）できる
発火の例
- 発火前：
- P1にトークン3個、P2にトークン1個、P3にトークン0個
- P1 → tの矢印は2本、P2 → tの矢印は1本、t → P3の矢印は2本
- P1は3個 ≧ 2本、P2は1個 ≧ 1本で、どちらも条件を満たすので、tは発火する
- 発火後：
- P1は 3 − 2 ＝ 1個、P2は 1 − 1 ＝ 0個、P3は 0 ＋ 2 ＝ 2個
システム的な解釈
- 解釈1（データの見方）：
- P1、P2は入力データ、P3は出力データ、tは処理
- 「入力データP1とP2がそろったら、処理tが実行される」
- 解釈2（条件の見方）：
- P1、P2は前提条件、P3は後提条件、tは事象
- 「前提条件P1とP2が成り立ったら、事象tが起きる」
- 例題（ペトリネット）：
- P1にトークン1個、P2にトークン1個。P1 → tの矢印は1本、P2 → tの矢印は2本。tは発火するか
- 例題の答え：
- P2は1個しかなく、矢印の本数（2本）に足りないので、発火しない
- あと1個P2にトークンが来れば発火する（P1は0個、P2は0個になる）
混同しやすいペア
- 構造化分析（SA） ／ 構造化設計（SD）
- 構造化分析は、データの流れに注目して要求を仕様にまとめる（DFDなど）
- 構造化設計は、DFDのプロセスをトップダウンでモジュールに分割する
- 源泉 ／ 吸収
- 源泉は、データの発生源
- 吸収は、データの最終的な行き先
- データストア ／ データフロー
- データストアは、データがたまる場所（ファイル、DB）
- データフローは、データの流れ（矢印）
- 現物理モデル ／ 現論理モデル
- 現物理モデルは、組織名や媒体なども含めて、今の業務をありのまま書く
- 現論理モデルは、物理的な仕組みを抜いて、データと処理だけを書く
- 新論理モデル ／ 新物理モデル
- 新論理モデルは、論理的要件を加える。データディクショナリやミニスペックもここで作る
- 新物理モデルは、物理的要件を加える
- コンテキストダイアグラム ／ レベル0ダイアグラム
- コンテキストダイアグラムは、プロセスが1つだけの最上位のDFD（外との出入りだけ）
- レベル0ダイアグラムは、それをいくつかのプロセスに分けたもの
- データディクショナリ ／ ミニスペック
- データディクショナリは、データフローとデータストアのデータの中身を定義する
- ミニスペックは、最下位のDFDのプロセスの機能仕様書（異常処理・例外処理もここ）
- DFD ／ ミニスペック（何を書くか）
- DFDは、正常処理を中心に書く。異常処理・例外処理・制御手順は書かない
- ミニスペックは、異常処理・例外処理も書く
- リアルタイム構造化分析の変換図 ／ DFD
- 変換図は、コントロール変換とコントロールフローを加えて、制御とタイミングを表す
- DFDは、制御手順を書かない
- プロセス中心設計（POA） ／ データ中心設計（DOA）
- プロセス中心設計は、機能を先に設計し、データはプロセスに依存する。変更に弱く、プロセスが重複しやすい
- データ中心設計は、データを共有資源として先に設計する。変更に強い
- データ ／ プロセス（変更への強さ）
- データは、業務要件が変わっても影響が少ない（静的、安定）
- プロセスは、業務要件の変更の影響を受ける（動的）
- データの標準化 ／ 一体化
- データの標準化は、正規化してデータの重複をなくす
- 一体化は、標準データと標準プロセスを1対1で結びつける
- CRUDの着眼点④ ／ ⑤
- ④は、1つのデータの発生に複数のプロセスが関わる → プロセスを1つにまとめる
- ⑤は、1つのプロセスが複数のデータの発生・消滅に関わる → プロセスを分割する（関連するデータなら分割しなくてよい）
- 状態遷移図 ／ 状態遷移表
- 状態遷移図は、丸と矢印の図
- 状態遷移表は、同じ内容を表にしたもの
- 状態遷移図 ／ ペトリネット図
- 状態遷移図は、状態が1つずつ順に変わる動作（イベントドリブン）
- ペトリネット図は、並行して動くものの同期
- プレース ／ トランジション ／ トークン
- プレースは、状態（○）
- トランジションは、事象（−）
- トークンは、印（●）。プレースに置かれ、システムの状態を表す
- ペトリネット図の解釈1 ／ 解釈2
- 解釈1は、入力データがそろったら処理が実行される
- 解釈2は、前提条件が成り立ったら事象が起きる