关于上下文和数据流图的一些问题
我必须开发一个 CRUD 应用程序，它将用 php 编码。
我有 3 个主要参与者（用户、管理员和医生——这是一个假设的 医院），每一个都已经定义了不同的用例。
尽管我认为用例足以成功地对类图进行建模，但我被特别要求将数据流图也包含到项目的文档中。
我一直在阅读有关数据流图的内容，似乎您通常首先有一个 0 级数据流图，他们称之为上下文图。
由于这基本上是一个具有 3 个不同参与者的 3 层应用程序，我应该如何对上下文图进行建模？
由于上下文图应该只是告诉我们系统输入什么和输出什么，所以我无法想象有什么比下图更有趣/更具描述性：
这应该是这样的，还是我完全没有抓住要点？这个 php 页面将连接到 Oracle 数据库，但我想如果想法是在上下文图中将系统视为一个整体，我应该在上图中“隐藏”该事实。
我应该从这里继续哪里？我知道我应该将系统流程“缩放”为更详细的内容。也许下一步是在数据流图中描述每个用户案例？我已经包含数据存储库了吗？例如，一个用于用户，另一个用于医生，还有一个用于管理员？
谢谢
I have to develop a CRUD application, that will be coded in php.
I have 3 main actors (Users, Administrators and Doctors -- this is for an hypothetical
hospital), each one with different Use Cases already defined.
Although I feel the Use Cases are more than enough to successfuly model the Class Diagram, I am being specifically asked to also include DataFlow Diagrams into the project's documentation.
I've been reading about DataFlow diagrams, and it seems you usually have first of all a Level 0 DataFlow Diagram, to which they call Context Diagram.
Being that this is basically a 3-tier application with 3 different Actors, how should I model the Context Diagram?
Being that a Context Diagram is supposed to just tell us what comes in and what comes out of our System, I can't imagine anything more interesting/descriptive than the following diagram:
Is this supposed to be something like this, or am I totally missing the point? This php page will connect to an Oracle database, but I guess that if the idea is to consider the System as a whole in the Context Diagram, I should "hide" that fact in the above diagram.
Where should I go on from here? I know I should "zoom" the System process to something more detailed. Maybe the next step would be to depict each one of the User Cases in a DataFlow diagram? Do I include repositories of data, already? For example, one for Users, other for Doctors and yet another for Administrators?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您确定系统没有与其他任何东西交互吗？例如诊断输入等？
如果没有，那么您的上下文诊断基本上没问题 - 尽管我可能会显示每个实体一次并使用双头箭头。我同意你对数据库的推理 - 它是系统的一部分，而不是外部的 - 所以不要在 CD 上显示它。
至于接下来的步骤，您再次走对了路。尝试将每个用例的流程建模为 DFD。 DFD 对于说明处理密集型应用程序非常有用。很难知道这是否适合您的问题。
您会发现 DFD 对于驱动和验证类图也很有用。事实上，这是它们的优势之一：DFD 上的数据存储应该与类图的内容相关联（但不一定是一个数据存储对应一个类）。因此，在完成流程时一定要包括数据存储。你会发现它驱逐的不仅仅是演员。
嗯。
Are you sure there's nothing else the system interacts with? e.g. diagnostics input, etc.?
If not then your context diag is basically ok - although I'd probably show each entity once and use double headed arrows. I'd agree with your reasoning for the db - it's part of the system, not external to it - so don't show it on the CD.
As for next steps, again you're on the right lines. Try modelling the flow for each Use Case as a DFD. DFDs are very useful for illustrating processing-intensive apps. Difficult to know if that's a good match to your problem or not.
You'll find DFDs are also useful for driving out and validating your Class Diagram. In fact, that's one of their strengths: datastores on the DFD should correlate with the contents of your class diagram (not necessarily one datastore to one class though). So do include datastores as you work through the processes. You'll find it drives out more than just the Actors.
hth.
一些评论：
除了用户、管理员和医生使用它之外，您 DFD 并没有告诉我太多信息，但它没有让我知道他们从系统中得到什么（“输出数据”除外）。 IOW，上下文图并没有让我知道系统是做什么的。
诚然，如果系统很大，那么很难用几句话来描述数据流，但任何事情都比“数据”更好。
系统是 3 层架构这一事实与 DFD 无关。这是一个实现细节。 DFD 是一种分析工具。您描述您希望系统做什么，而不是如何实现这一点。
我发现关注流出流量特别有用。虽然用户、管理员和医生向系统提供输入，但这很可能不是他们想要做的。为了获得所需的输出，他们必须这样做。
Some remarks:
You DFD does not tell me much, except that Users, Administrators and Doctors use it, but it gives me no clue what they get from the system (except "Output Data"). IOW the context diagram does not give me the slightest idea, what the system does.
Admittedly, if the system is large, then it can be difficult to describe the dataflows in few words, but just about anything is better than "data".
The fact that the system is a 3tier architecture is irrelevant for the DFD. This is an implementation detail. DFDs are an analysis tool. You describe what you want the system to do, not how this is achieved.
I find it particularly useful to focus on the outgoing flows. While Users, Administrators and Doctors provide input to the system, this is most likely nothing they want to do. It is something they have to do in order to get the desired output.