病院の患者情報システムのデータフロー図
ある病院で実装されている患者情報システムのDFDの例があります。以下の図は、概要図を表しています（レベル0の図、最初のレベルがコンテキスト図であると考えると、2番目のレベルはレベル0の図など）。
このシステムでは、患者は検索して予約を取ることができます。 patient nameというラベルが付けられ、プロセスMake appointmentからデータベースPatientsに送られるデータフローを理解しようとしています（図の黄色のハイライトを参照）。
システムにこのフローがある理由がわかりません。どのシナリオでプロセスがMake appointmentをデータベースに送信するのですかpatients患者名？プロセスによって患者名がすでに送信されている必要はありませんか？
プロセスMaintain patient infoの名前は、患者の記録がそこに作成されていることを示唆しているため、誤解を招くようです。
仮定を忘れて、Patientsdata storeを含むフローを見ると、次のことがわかります。
Patient InfoはMake AppointementおよびPrepare Reportsに流出しますPatient InfoはMaintain Patient Infoから流入します。ただし、フローはUpdate to ...というラベルが付いています。これは、患者データの単なる流入よりも制限的です。データがすでに存在していることを前提としています。Patient nameはMake appointmentから流入します。
DFD semantics を使用し、DFDがルールに従って描かれていると仮定すると、次のことが理解できます。
- 患者が予約すると、患者名がデータストアに保存される場合があります。つまり、予約が作成されたときにのみ新しい患者が作成され、他の情報なしで作成されます。
- 患者情報はメンテナンスプロセスで管理されます（ただし、予約時は管理されません）
- 新しい患者は名前で一意に識別されます。
- おそらく
patient nameはpatient infoの一部です（明示的に抽出されることはないため）
備考：
- DFDデータストアは「パッシブ」です：流入するデータが格納され、データはストアから抽出されます。保管以外の流入に対する反応には、プロセスが必要です。したがって、この名前の流れは、今のところ、クエリと誤解されています。
- 現実の世界では、患者名は同音異義語の可能性を考慮して患者を確実に特定するには不十分です。
Perform billingがpatient infoを必要としないことも奇妙です。