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

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

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

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

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

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

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

альтернативный текст

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

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

Спасибо


diagram dataflow-diagram uml
person devoured elysium    schedule 16.10.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

чт.

person sfinnie    schedule 16.10.2010

arrow_upward
0
arrow_downward

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

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

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

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

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

person Martin Drautzburg    schedule 03.05.2013