データフローダイアグラム（DFD）は、情報がシステム内でどのように移動するかを理解するための設計図です。これらの図の中心には、重要な要素である「外部エンティティ」があります。これらの要素は、モデル化されているシステムと外部世界との境界を定義します。これらのエンティティが明確に定義されていないと、データの流れに文脈がなくなり、システムアーキテクチャが曖昧になります。このガイドでは、外部エンティティのメカニズム、定義、モデリング戦略について探求し、正確なシステム文書作成を確保します。
外部エンティティとは何か？ 🎯
外部エンティティは、アクター、ソース、またはシンクと呼ばれることが多く、分析対象のシステムとやり取りする人物、組織、またはシステムを表します。これらはシステムの境界の外に存在しますが、システムが機能するために不可欠です。DFDの文脈では、システム境界が内部プロセスと外部の影響を分離します。入力データを提供するか、出力データを受け取るものは、このカテゴリに含まれます。
外部エンティティを、現在のモデルの特定の範囲内でデータを処理しない参加者と考えてください。たとえば、図書館管理システムでは、司書は外部エンティティです。司書は本の詳細を入力し、貸出記録を受け取りますが、罰金の計算や本の予約といった内部ロジックはシステム内部で行われるため、司書自身の内部では行われません。エンティティはやり取りを開始するか、結果を受け取る役割を果たします。
- ソース：システムに流入するデータの発信元となるエンティティ。
- シンク：システムから流出するデータを受け取るエンティティ。
- 両方：エンティティは、ソースとしてもシンクとしても機能でき、複数の方法で相互作用することができる。
これらを正しく識別することは基盤です。エンティティが誤って配置されると、データフローの矢印が誤った場所を指し、開発や実装フェーズで混乱を招くことになります。
境界の役割 🚧
システム境界という概念は、外部エンティティを定義する上で中心的な役割を果たします。DFDは、宇宙全体を描いたものではなく、特定のシステムに焦点を当てた視点です。境界とは、データを変換するプロセスの周囲に引かれる線です。この線の内側にあるものはすべてシステムの一部であり、外側にあるものは外部です。
モデリングする際には、何が内側に、何が外側に属するかを決定しなければなりません。この決定はプロジェクトの範囲に依存します。たとえば、銀行アプリケーションでは顧客は外部エンティティです。しかし、範囲が銀行インフラ全体を含むように拡大すると、顧客はより広範なシステムの内部に位置する可能性がありますが、通常はユーザーはソフトウェアシステム自体の外部に留まります。
境界は、モデルが管理可能であることを保証します。図が無限に続く外部依存関係の連鎖にならないようにします。境界を明確にマークすることで、開発者は内部プロセスと外部から照会すべきデータソースを正確に把握できます。
外部アクターの種類 👥
外部エンティティは人間ユーザーに限定されるわけではありません。さまざまな形のやり取りポイントを含みます。エンティティの種類を認識することで、データ交換の性質を理解するのに役立ちます。
| エンティティの種類 | 説明 | 例 |
|---|---|---|
| 人間ユーザー | システムと直接やり取りする人物。 | 管理者、顧客、従業員 |
| 外部システム | 別のソフトウェアアプリケーションまたはハードウェアデバイス。 | 決済ゲートウェイ、CRMツール |
| 組織 | データを送信または受信する会社または部門。 | ベンダー、規制機関 |
| 物理的オブジェクト | データ入力をトリガーするか、出力を受ける実体。 | スキャナ、プリンタ、センサ |
これらの違いを理解することは、統合計画において不可欠です。人間のユーザーはグラフィカルインターフェースを必要とする場合がありますが、外部システムはAPIやファイル転送プロトコルを必要とする場合があります。DFDは論理的な流れを捉えますが、エンティティの種類を把握することで、技術的な実装が明確になります。
視覚的記法基準 📐
DFDに使用される主な記法は2つあります。それぞれが外部エンティティを表すために異なる形状を使用します。1つの標準を選択し、文書全体で一貫して使用することが重要です。これにより混乱を避けることができます。
GaneとSarsonの記法
このスタイルでは、外部エンティティは長方形で表されます。エンティティの名前はボックス内に記載されます。この記法は企業環境で広く使用されています。長方形はコンテナまたは明確な組織単位を示唆しています。
YourdonとDeMarcoの記法
このスタイルでは、外部エンティティに正方形を使用します。視覚的には似ていますが、強調点がわずかに異なります。一部のチームは、プロセスに使用される丸い長方形と対照的に、正方形の特徴的な外観を好むことがあります。形状に関わらず、機能は同じです：システムの境界を示すことです。
一貫性が鍵です。1つの図で複数の記法を混在させると、誤解を招く可能性があります。チームがGaneとSarsonの記法を標準化した場合、すべての図でエンティティに長方形を使用する必要があります。プロジェクト途中で記法を変更する場合は、すべての文書を包括的に見直す必要があります。
エンティティとプロセスを接続する 🔗
データフローはエンティティとプロセスを接続します。これらのフローは物理的な物体の移動ではなく、データの移動を表します。外部エンティティからプロセスへと引かれた矢印は、そのエンティティがそのプロセスに必要な情報を提供していることを示します。
逆に、プロセスから外部エンティティへの矢印は、システムが情報の元へ戻すことを示しています。データは、少なくとも1つのプロセスを経由せずに、1つの外部エンティティから別の外部エンティティへ直接流れることはないことを覚えておくことが重要です。これにより、システムがデータに対して何らかの変換または検証を実施していることが保証されます。
- 入力フロー： エンティティからシステムに入力されるデータ。
- 出力フロー： システムからエンティティへ出力されるデータ。
- 検証： プロセスは、データを保存するか、さらに処理する前に、受信データを確認することが多いです。
すべての矢印にはラベルが必要です。このラベルは移動中のデータを説明します。たとえば、「注文詳細」や「支払い確認」などとラベルを付けることができます。「データ」や「情報」のような曖昧なラベルは、図の明確性を低下させ、監査やレビュー時の理解を妨げます。
命名規則と明確性 🏷️
外部エンティティに正しい名前を付けることは、長期的な保守性を高めるベストプラクティスです。名前は動詞ではなく名詞であるべきです。エンティティは行動ではなく、物や人です。たとえば、「カスタマーサービス」ではなく「カスタマー」を使用してください。
また、DFDの階層の異なるレベル間で名前を一貫性を持って使用する必要があります。レベル0の図で「サプライヤー」と表示されている場合、レベル1の分解図で「ベンダー」に変更してはいけません。ただし、その違いが重要である場合を除きます。名前の変更は、データの流れを追跡しにくくする断絶を生じさせます。
組織内で普遍的に理解されている場合を除き、略語は避けるべきです。「HR」と「Human Resources」を混同すると、新入メンバーを混乱させる可能性があります。フルネームは文脈を提供し、曖昧さを減らします。
実践的なモデリングシナリオ 🏢
これらの概念を説明するために、オンラインショッピングプラットフォームを例に挙げます。システムは注文処理、在庫管理、配送処理を行います。
シナリオ1：顧客
顧客は外部エンティティです。注文リクエストを送信し、配送の更新を受け取ります。注文の処理は内部的に行わず、システムが行います。
シナリオ2：決済ゲートウェイ
これは外部システムです。チェックアウトプロセスから支払い詳細を受け取り、成功または失敗のトークンを返します。これは第三者が管理しているため、プラットフォーム開発者とは別であるため外部です。
シナリオ3：倉庫
範囲によっては、倉庫は外部エンティティとなる可能性があります。システムが注文のみを追跡し、倉庫が在庫を物理的に管理している場合、倉庫は在庫更新の外部ソースとなります。
これらのシナリオをマッピングすることで、チームはすべての必要な統合を特定できます。DFDは、技術的知識のないステークホルダー間のコミュニケーションツールとなります。
エンティティと他の要素の区別 ⚖️
モデリングにおける一般的な課題は、外部エンティティとデータストアの区別です。データストアは、データベーステーブルなど、システム内にデータを保持します。外部エンティティは、システム外にデータを保持するか、データを生成します。
データがシステムが後で使用するために永続的に保存される場合、それはデータストアに属します。データが単に通過するか、外部から起源する場合、それはエンティティに属します。エンティティとプロセスの違いも重要です。プロセスはデータを変換します。エンティティはデータを変換しません。単に提供または受信するだけです。エンティティが重要な論理処理を行う場合、それは別個のシステムまたはプロセスとしてモデル化すべきです。
データストアとの統合 🗄️
エンティティは内部的にデータを保存しませんが、しばしばデータストアと間接的にやり取りします。たとえば、外部エンティティがデータストアを更新するプロセスをトリガーする場合があります。エンティティはトリガーであり、データストアは記憶装置です。
この関係を理解することで、データベース設計が容易になります。外部エンティティが特定の種類のデータを頻繁に送信する場合、対応するデータストアはその入力を処理できるように最適化されるべきです。DFDはデータベーススキーマを示しませんが、それらの論理的な必要性を示しています。
外部エンティティが図から削除されると、それに接続されたプロセスが孤立する可能性があります。これは、システムが不完全であるか、範囲の調整が必要であることを示唆します。エンティティを削除すると、隠れた依存関係や未使用の機能が明らかになることがあります。
時間の経過とともにモデルを精 refinement する 🔄
DFDは動的な文書です。要件が変化すると、外部エンティティが追加されたり削除されたりする可能性があります。新しいサードパーティAPIが要件になる場合、新たな外部システムエンティティが導入されます。レガシーなユーザーインターフェースが廃止されると、図から人間エンティティが削除されます。
定期的なレビューにより、図が現在の現実と一致していることを確認できます。ステークホルダーは、重要な相互作用ポイントが見逃されていないかを検証する必要があります。この検証フェーズは、スコープクリープを防ぎ、最終製品がユーザーのニーズを満たしていることを保証するために不可欠です。
ドキュメントはバージョン管理するべきです。エンティティの変更は追跡され、システムの進化を理解するのに役立ちます。この歴史的記録は、新しくチームに加わるメンバーが、特定の統合がなぜ存在するのかを理解するのに役立ちます。
デザイナーのための最終的な考慮事項 🛠️
外部エンティティを意識して設計する際は、システム境界を常に意識してください。あまりにも多くのエンティティを含めることで図が複雑になりすぎないようにしましょう。エンティティの数は、コア機能に不可欠なもののみに制限してください。図に外部アクターが多すぎると、サブシステムに分割するほうが良い場合があります。
明確さが完全性を上回ります。単純で正確な図は、複雑で混乱した図よりも優れています。すべての矢印にラベルを付け、すべてのエンティティに明確な目的があることを確認してください。この徹底的な姿勢は、開発やテストフェーズで問題の原因を追跡する際に大きな効果を発揮します。
外部エンティティを慎重に扱うことで、チームはシステムアーキテクチャの堅固な基盤を築くことができます。図は、開発、統合、保守作業を効果的に導く地図となるのです。