Некоторые вопросы относительно диаграмм контекста и дата

Question

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

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

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

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

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

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

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

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

Спасибо

Answer 1

Вы уверены, что нет ничего, с которым система взаимодействует? например, вход диагностики и т. Д.?

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

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

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

хет

Answer 2

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

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

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

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

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