我必须开发一个 CRUD 应用程序，它将用 php 编码。
我有 3 个主要参与者（用户、管理员和医生——这是针对一家假设的医院），每个参与者都已经定义了不同的用例。
虽然我觉得用例足以成功地为类图建模，但我被特别要求在项目文档中也包含数据流图。
我一直在阅读有关数据流图的信息，看来您通常首先拥有一个 0 级数据流图，他们称之为上下文图。
由于这基本上是一个具有 3 个不同 Actors 的 3 层应用程序，我应该如何为上下文图建模？
由于上下文图应该只是告诉我们系统的输入和输出，我无法想象比下图更有趣/更具描述性的东西：
这应该是这样的，还是我完全错过了重点？这个 php 页面将连接到一个 Oracle 数据库，但我想如果这个想法是在上下文图中将系统作为一个整体来考虑，我应该在上图中“隐藏”这个事实。
我应该从这里往哪里走？我知道我应该将系统进程“缩放”到更详细的内容。也许下一步是在数据流图中描述每个用户案例？我是否已经包含数据存储库？例如，一个用于用户，另一个用于医生，另一个用于管理员？
谢谢
你确定系统没有与之交互吗？例如诊断输入等？
如果不是，那么您的上下文诊断基本上没问题 - 尽管我可能会显示每个实体一次并使用双头箭头。我同意你对 db 的推理——它是系统的一部分，而不是它的外部——所以不要在 CD 上显示它。
至于接下来的步骤，你又是在正确的路线上。尝试将每个用例的流程建模为 DFD。DFD 对于说明处理密集型应用程序非常有用。很难知道这是否适合您的问题。
您会发现 DFD 也可用于驱动和验证您的类图。事实上，这是他们的优势之一：DFD 上的数据存储应该与您的类图的内容相关联（虽然不一定是一个数据存储到一个类）。因此，在您完成这些流程时，请务必包含数据存储。你会发现它不仅仅是演员。
hth。
一些备注：
除了用户、管理员和医生使用它之外，您的 DFD 并没有告诉我太多，但它让我不知道他们从系统中得到了什么（“输出数据”除外）。IOW上下文图没有给我丝毫的想法，系统做什么。
诚然，如果系统很大，那么很难用几句话来描述数据流，但几乎任何东西都比“数据”好。
系统是 3 层架构这一事实与 DFD 无关。这是一个实现细节。DFD 是一种分析工具。您描述的是您希望系统做什么，而不是如何实现。
我发现关注流出的流量特别有用。虽然用户、管理员和医生向系统提供输入，但这很可能不是他们想做的事情。这是他们必须做的事情才能获得所需的输出。