После этапа моделирования исследуемого объекта наступает этап физической реализации этой модели в виде ИС. И тут возникает вопрос об адекватности отображения, т.е. как представить в ИС управляющие потоки и др. Хотя понятно, что, например, потоки данных в ИС будут реализованы как хранилища данных, т.е. файлы. Тот факт, что IDEF0-модель не разделяет потоки данных на материальные, информационные и управляющие приводит разработчиков к необходимости использовать диаграммы потоков данных. Это можно делать после этапа составления IDEF0-модели, либо вместо него в зависимости от сложности моделируемого объекта или предпочтений исполнителя.
ДИАГРАММЫ ПОТОКОВ ДАННЫХ
При построении DFD –диаграмм используют следующие элементы:
· Поток данных – некая информация, которая требует обработки;
· Процесс – преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом;
· Внешняя сущность – источник или приемник данных, который является внешним по отношению к предметной области;
· Хранилище данных (data storage)
Внешняя сущность – это объект, который не принадлежит моделируемому объекту и обменивается с ним потоками данных. Это, как правило, потребитель услуг моделируемого объекта. На концептуальной схеме его именуют существительным.
В общем случае, сущность – это объект или концепция, которая в рамках конкретной предметной области существует самостоятельно.
Процесс описывают глаголом, который обозначает некое действие, связанное с обработкой потока.
Построим, используя DFD-методологию, концептуальную модель некоторой риэлтерской конторы, которая специализируется на заключении договоров аренды жилых помещений. При этом будем считать, что круг клиентов конторы относительно стабилен.
На рис. 2 внешня сущность обозначена прямоугольником, потоки данных стрелками, процессы – кругами, а хранилища данных – параллельными линиями.
Рис. 2. Концептуальная модель работы риэлтерской конторы
Как видно из концептуальной модели заключения договора, внешние сущности – это потенциальные Арендатор и Владелец. Поскольку элементами концептуальной модели являются одноименные хранилища: Арендатор и Владелец, то можно усомниться в правильности определения внешних сущностей. Но, так как потенциальные Арендатор и Владелец могут быть таковыми лишь после заключения договора, то конфликтов с определением здесь нет. Другими словами, это разные сущности.
Для составления договора используют данные хранилищ Арендатор и Владелец. Эти хранилища необходимы по причине того, что круг клиентов риэлтерской конторы относительно стабилен. Не подвержен значительным изменениями и перечень арендуемых объектов недвижимости, что отражает на концептуальной схеме хранилище Недвижимость.
Наличие на диаграмме процесса «Подготовить договор аренды» - это следствие того, что черновик договора аренды готовит клерк, а менеджер принимает решение о заключении договора. Это повышает эффективность работы фирмы в целом.
РОЛЬ МЕТОДОЛОГИЙ В АНАЛИЗЕ МОДЕЛИРУЕМОГО ОБЪЕКТА
В результате анализа моделируемого ИС объекта на основе построения IDEF0 и DFD- диаграмм:
Определяют главную функцию проектируемой системы: например, сопровождать аренду недвижимости;
Описывают происходящие в моделируемом объекте бизнес-процессы.
Например:
Заключать договора аренды
Сопровождать хранение информации об объектах недвижимости
Определяют обрабатываемые бизнес процессами информационные потоки. Например, отправка договора менеджеру.
Разрабатывают концептуальную модель системы, которая представляет собой описание моделируемого объекта, присущих ему бизнес-правил, потоков и хранилищ данных
Примечание: Потоки данных – это прообразы процедур приложения, а хранилища данных – таблиц БД.
Подводя итог, можно отметить, что построение концептуальной модели системы в соответствии с IDEF0 и DFD-методологией позволяет прийти к общему с заказчиком представлению о проектируемой ИС.
ОПРЕДЕЛЕНИЕ МОДУЛЕЙ И ПРОЕКТИРОВАНИЕ БД.
На данном этапе проектирования ИС:
· На основе анализа назначения потоков концептуальной модели определяют модули приложений, которые позволяют реализовать функции системы
· Проектируют концептуальную схему БД. Эта схема не зависит от конечной реализации БД и аппаратной платформы.
При разработке ИС немаловажную роль играет выбор среды. Объектно-ориентированная методология позволяет рассматривать разработку прикладных систем, как процесс их конструирования из готовых классов.
Модули проектируемого приложения можно определить на основе назначения потоков концептуальной модели.
