Некоторые вопросы, касающиеся контекста и диаграмм потока данных

Question

Мне нужно разработать приложение CRUD, которое будет закодировано в php.

У меня есть 3 основных участника (пользователи, администраторы и врачи - это для гипотетического больница), каждый из которых уже определен с различными вариантами использования.

Хотя я считаю, что вариантов использования более чем достаточно для успешного моделирования диаграммы классов, меня специально просят включить диаграммы DataFlow в документацию проекта.

Я читал о диаграммах DataFlow, и, кажется, у вас обычно есть прежде всего диаграмма DataFlow уровня 0, для которой они называют Context Diagram.

Поскольку это в основном трехуровневое приложение с 3 различными субъектами, как мне моделировать контекстную диаграмму?

Учитывая, что контекстная диаграмма должна просто сообщать нам, что входит и что выходит из нашей системы, я не могу представить ничего более интересного / описательного, чем следующая диаграмма:

Это должно быть что-то вроде этого, или я полностью упускаю суть? Эта php-страница будет подключаться к базе данных Oracle, но я думаю, что если идея состоит в том, чтобы рассмотреть Систему в целом на контекстной диаграмме, я должен «скрыть» этот факт на приведенной выше диаграмме.

Куда мне идти дальше? Я знаю, что должен «увеличить» системный процесс до чего-то более подробного. Может быть, следующим шагом было бы изобразить каждый из пользовательских случаев на диаграмме DataFlow? Я уже включил хранилища данных? Например, один для пользователей, другой для врачей и еще один для администраторов?

Спасибо

Answer 1

Вы уверены, что больше ничего нет, с чем система взаимодействует? например вход диагностики и т. д.? 1001 *

Если нет, тогда ваш контекстный диагон в целом в порядке - хотя я, вероятно, покажу каждую сущность один раз и использую стрелки с двумя головками. Я бы согласился с вашими аргументами в пользу БД - это часть системы, а не внешняя для нее - поэтому не показывайте ее на компакт-диске.

Что касается следующих шагов, снова вы на правильных линиях. Попробуйте смоделировать поток для каждого варианта использования в качестве DFD. DFD очень полезны для иллюстрации приложений с интенсивной обработкой. Трудно понять, подходит ли это к вашей проблеме или нет.

Вы найдете, что DFD также полезны для выведения и проверки вашей диаграммы классов. Фактически, это одна из их сильных сторон: хранилища данных в DFD должны коррелировать с содержанием вашей диаграммы классов (хотя не обязательно одно хранилище данных на один класс). Так что включайте хранилища данных, когда вы работаете через процессы. Вы найдете, что это вытесняет не только актеров.

НТН.

Answer 2

Некоторые замечания:

Вы, DFD, ничего мне не говорите, за исключением того, что пользователи, администраторы и доктора используют его, но это не дает мне понятия, что они получают от системы (кроме «Выходных данных»).IOW контекстная диаграмма не дает мне ни малейшего представления о том, что делает система .

По общему признанию, если система большая, то может быть трудно описать потоки данных в нескольких словах,но все, что угодно, лучше, чем «данные».

Тот факт, что система является 3-х уровневой архитектурой, не имеет значения для DFD.Это деталь реализации.DFDs являются инструментом анализа.Вы описываете, что вы хотите, чтобы система делала, а не как это достигается.

Я считаю особенно полезным сосредоточиться на исходящих потоках.В то время как пользователи, администраторы и врачи предоставляют данные для системы, скорее всего, они не хотят делать.Это то, что они должны сделать, чтобы получить желаемый результат.