数据流图建模疑点

Question

我对DFDs中最正确的建模方法有一些疑问。我对医院的系统有以下要求：

1. “所有的医生议程将在网站上提供给病人，病人可以选择任何医生。”

我对这个要求的问题是：

1.1：“获得议程”和“选择医生”是不同的过程吗？我想应该的，但我不能百分之百肯定。

1.2能否将“获取议程”建模为一个简单地从“议程”数据存储中读取并生成输出流的过程，该流程流向“病人”外部实体？或者，是否需要输入流来代表病人必须首先要求议程？我更倾向于将其表示为一个输出流，因为我看到，请求议程更多地是一个控制流而不是数据流。我说的对吗？如果还包括输入流更好，我假设在这种情况下，我可以使用上下文图中的对话流，而不是单独的输入/输出流来询问议程和获得议程，对吗？我上传了以下图片，以图形化的方式显示我所指的上下文图的两个版本是什么：https://imgur.com/a/ipGAHhb

1. “病人可以更换它指定的专科医生，费用为10美元。医生可以为病人免费更换指定的专科医生”

2.1我能用一个单一的“变革专家”过程来建模吗？在这种情况下，我如何表示，只有在病人而非专科医生更改收费时，才须缴付费用？

除了这些关于需求的问题之外，有人能推荐我一个使用METRICA语法绘制DFDs的好的免费软件吗？这个语法就是在这个链接中可以看到的：

https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/diagrama-de-flujo-de-datos/

https://administracionelectronica.gob.es/pae_Home/dam/jcr:da7d91fa-d6bd-467c-be32-a72e27c603b3/METRICA_V3_Tecnicas.pdf

耽误您时间，实在对不起。

Answer 1

1.1。除非您想要制作一个非常详细的图表，否则不打算将需求与DFD过程一对一地映射：

• --这个过程似乎是Book appointment --选择医生和查看医生议程上的自由插槽--这些都是这个过程的细节。当然，您可以想象一个流程Select doctor，一个process Obtain agenda，然后是process Book an agenda slot。但是，您已经开始定义用户界面了。此外，还需要向前一步添加大量箭头，但不需要任何数据。这太过分了。--

1.2。结论：Obtain agenda不应是一个过程。顺便说一句，用户什么也得不到:议程仍然保存在数据存储中。我怀疑病人能否完全进入议程，并以自己的名字来看待其他病人的预约。事实上，流程Book appointment将从数据存储Agenda中读取空闲插槽，并在数据存储区中写入新的约会。其余部分是此过程的功能需求。

1. 再次显示数据处理进程之间的数据流。与系统交互的外部参与者可以显示为实体。但是DFDs并不是业务流程分析符号。因此，有一个进程Change specialist和两个可以提供输入的实体似乎是合理的。适用的规则(谁可以做什么、在什么条件下、在什么价格下)是此过程的功能规范。

工具:你问题的这一部分超出了范围。我们不推荐工具。顺便说一句，看看您的文档，Metrica似乎对进程使用了自己的语法。它似乎灵感来自IDEF3盒，但自上而下，这不同于通常的DFD表示法。恐怕您将找不到免费的建模工具，您将不得不使用一个简单的绘图工具与适当的模板。