Построение бизнес-модели в BPwin

     В отличие от IDEF0, где система рассматривается  как взаимосвязанные работы, DFD рассматривает  систему как совокупность предметов. Контекстная диаграмма часто  включает работы и внешние ссылки. Работы обычно именуются по названию системы, например "Система обработки информации". Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

      В DFD работы представляют собой функции  системы, преобразующие входы в  выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же как работы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.

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

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

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

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

      Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому как строятся диаграммы IDEF0. Сначала строится физическая модель, отображающая текущее состояние дел. Затем эта модель преобразуется в логическую модель, которая отображает требования к существующей системе. После этого строится модель, отображающая требования к будущей системе. И, наконец, строится физическая модель, на основе которой должна быть построена новая система.

      Альтернативным  подходом является подход, популярный при создании программного обеспечения, называемый событийным разделением (event partitioning), в котором различные диаграммы DFD выстраивают модель системы. Во-первых, логическая модель строится как совокупность работ и документирования того, что они (эти работы) должны делать.

      Затем модель окружения (environment model) описывает систему как объект, взаимодействующий с событиями из внешних сущностей. Модель, окружения обычно содержит описание цели системы, одну контекстную диаграмму и список событий. Контекстная диаграмма содержит один прямоугольник работы, изображающий систему в целом, и внешние сущности, с которыми система взаимодействует.

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

     Построение  информационной модели – «Деятельность  оптовой компании»

Рисунок 6 -  

Рисунок 7 -

Рисунок 8 -

Рисунок 9 -  
 

Рисунок 10 -

     Заключение

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

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

      В результате курсовой работы была спроектирована и реализована автоматизированная информационная модель «Деятельность оптовой компании».

      Данная модель удовлетворяет всем требованиям, предъявленным в задании, и реализует большинство необходимых для работы оптовой компании функций.

     Список  использованных источников

1. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. – М.: ДИАЛОГ – МИФИ, 2002. – 224с.;

2. Маклаков С.В. BPWin и ERWin. CASE – средства разработки информационных систем. – М.: ДИАЛОГ – МИФИ, 1992. – 256с.;

3.  Сайт case-web «Информационные системы»;

4.  Кириллов В.В. Структурированный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.;

5. Цикритизис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика, 1985. – 344 с;

6. Рубцов С. В. Какой CASE-инструмент нанесет наименьший вред организации?. ДИС, 2002;  .

7.  Рубцов С. В. Взаимодействие открытых систем - старая концепция для новых идей, Новые рынки,  2001, 4, 17-19.

8. Рубцов С. В. Уточнение понятия <бизнес- процесс>.  Менеджмент в России и за рубежом, 2001, 377 c.;

9. Материалы семинара в рамках Программы ИСО для развивающихся стран. Минск, Июль 2001 г. 79 с.