kazminaviktoriya1
В профиль
Выход
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Спринт 7/17: Моделирование процессов → Тема 3/5: Моделирование потоков данных → Урок 4/4
Переход от логической модели потоков данных к физической
В предыдущих уроках вы узнали, что такое модель потоков данных и какие уровни детализации бывают, познакомились с элементами модели и изучили нотацию для её построения. В этом уроке вы больше узнаете о физической модели и о том, как перейти к ней от логической модели потоков данных.
Что такое физическая модель потоков данных
Модель любого уровня отображает поток информации для определённого процесса. В чём разница между логической моделью потоков данных и физической? Логическая модель отвечает на вопрос, что включает в себя поток, а физическая модель — на вопрос, как будет реализован поток.
Логическая модель — основа для физической. Физическая модель потоков данных содержит те же компоненты, что и логическая, а именно: внешние сущности, хранилища данных, процессы, потоки данных.
Основное различие между двумя моделями заключается в том, что физическая модель более конкретна, близка к реализации и содержит дополнительные сведения, описывающие, как была или будет построена система: какое аппаратное обеспечение, программное обеспечение, какие файлы будут использоваться и какие участники будут задействованы в процессе.
Кто и зачем составляет физическую модель
Как вы уже знаете, целевая аудитория физической модели — архитекторы баз данных и разработчики. Как правило, именно они составляют физическую модель. А системные аналитики могут только помогать и консультировать архитекторов и разработчиков в этом процессе.
Физическая модель может пригодиться СА, так как она:
- Отражает детали реализации и показывает, как работает текущая система.
- Отражает детали реализации будущей системы.
- Помогает оценить программные решения. Иногда создают несколько физических моделей с использованием различных технологий, чтобы выявить наилучшее решение.
Как перейти от логической модели к физической
Логическую модель потоков данных можно привести к физической за три шага:
Шаг 1. Добавить описание реализации.
Шаг 2. Добавить границу между человеком и ПО.
Шаг 3. Добавить технически важные хранилища данных, потоки данных и процессы.
Покажем, как это работает, на примере поиска и просмотра товаров на сайте магазина. Перед вами логическая DFD процесса 1 «Найти и посмотреть товар».
Шаг 1. Добавить описание реализации
Сначала нужно добавить ссылки на способы реализации хранилищ, потоков данных и процессов.
Внешние сущности находятся за областью действия системы и поэтому остаются неизменными на физической модели.
Определим для логической модели на картинке, как именно будут реализованы потоки данных, хранилища данных и процессы:
- Добавим язык, на котором будет реализован процесс в будущей системе. Скажем, HTML, CSS и JavaScript.
- Добавим ссылки на реализацию хранилищ в формате таблиц БД. Допустим, БД будет реализована на PostgreSQL.
- Потоки данных преобразуем следующим образом:
- Информацию о рекламных акциях, существующих избранных товарах, новых избранных товарах — в запись в базе данных PostgreSQL.
- Поток данных для поиска и выбора товара — в форму ввода информации. К примеру, пользователю будет дано поле, куда он сможет ввести названия товаров для поиска.
- Поток данных для отображения соответствующих товаров и информации о выбранном товаре — в форму вывода информации.
Посмотрите, как изменилась модель, — обновления отмечены другим цветом:
Шаг 2. Добавить границу между человеком и ПО
На физической модели действия человека и ПО разделяют границей — пунктирной линией.
Команде разработки нужно определить, где провести эту границу, — стоит взвесить критерии стоимости, эффективности и целостности:
- Если затраты на автоматизацию меньше, чем на выполнение работы вручную, то часть системы должна быть автоматизирована.
- Система должна выполнять переданные ей действия эффективно.
- Если планируется автоматизировать только часть действий сотрудника и останутся ручные действия, то для соблюдения целостности процесса лучше перенести в физическую модель и то и другое: уже работающую часть системы и оставшиеся ручные действия.
Рассмотрим пример. Для владельца интернет-магазина, скорее всего, выйдет дешевле, если сотрудник будет оформлять заказы по телефону и самостоятельно доставлять бланки заказов на склад. Но при обработке заказов вручную велик риск допустить ошибку.
Вместо этого проще и удобнее использовать автоматизированный процесс оформления заказа. Команде разработки предстоит реализовать такую функциональность. Тогда на модели граница между человеком и ПО будет проходить сразу за пользователем магазина, а дальнейшие действия будут автоматизированы в системе.
Так и в случае с моделью на картинке: все процессы будут автоматизированы, но для их выполнения нужны действия пользователя в системе. Следовательно, граница будет проходить сразу за внешней сущностью «Пользователь».
Изменения в модели отмечены другим цветом:
Шаг 3. Добавить технически важные хранилища данных, потоки и процессы
На этом шаге нужно добавить дополнительные процессы, хранилища или потоки, которые важны для реализации системы, то есть для разработчиков, и мало или никак не влияют на бизнес-процесс.
Эти дополнения вызваны техническими ограничениями, необходимостью обработки каких-либо исключений или реализации средств контроля:
- Технические ограничения встречаются редко и зависят от используемых в системе технологий.
Например, ограничения может накладывать выбранный язык программирования. Или размер памяти на сервере может ограничивать объём данных, который вы можете хранить. Следовательно, команде разработки нужно учитывать механизмы для очистки данных, которые хранятся дольше определённого срока (этот вопрос вы можете обсудить со стейкхолдерами). - Обработка исключений нужна для того, чтобы решить, как будет работать система в необычных для неё ситуациях — при альтернативном сценарии в работе бизнес-процесса.
Например, в случае, когда клиент звонит и отменяет размещённый им заказ, это не обычное действие пользователя, а альтернативный сценарий. - Средства контроля необходимы для отслеживания изменений в работе бизнес-процесса и для хранения информации, которая может меняться.
Например, при отмене заказа, вместо того чтобы просто заставить систему избавиться от информации о нём, в целях контроля эти данные записываются в БД вместе с причинами отмены, а не удаляются безвозвратно.
Вернёмся к модели и добавим для отслеживания статуса поиска отдельную таблицу — «Аудит работы процесса». Она может пригодиться в случае ошибки: используя данные этой таблицы, можно быстрее найти проблему и решить её.
Изменения в модели отмечены другим цветом:
Подведём итоги
Физическая модель потоков данных, в отличие от контекстной и логической моделей, отражает детали реализации системы. Она содержит сведения о том, как была или будет построена система: аппаратное обеспечение, программное обеспечение, файлы и задействованные в процессе участники.
Составлением физической модели занимаются разработчики и архитекторы хранилищ данных. Модель отражает детали реализации и объяснения, как работает текущая система или как будет работать будущая система. Иногда физическая модель помогает выбрать наиболее подходящее ПО.
Привести логическую модель потоков данных к физической можно за три шага:
- Шаг 1. Добавить описание реализации.
- Шаг 2. Добавить границу между человеком и ПО.
- Шаг 3. Добавить технически важные хранилища данных, потоки и процессы.
