17.Структурное моделирование информационных систем средствами bPwin.

BPwin - мощный инструмент моделирования, который используется для анализа, документирования и реорганизации сложных бизнес-процессов. Модель, созданная средствами BPwin, позволяет четко документировать различные аспекты деятельности - действия, которые необходимо предпринять, способы их осуществления, требующиеся для этого ресурсы и др. Таким образом, формируется целостная картина деятельности предприятия - от моделей организации работы в маленьких отделах до сложных иерархических структур. При разработке или закупке программного обеспечения модели бизнес-процессов служат прекрасным средством документирования потребностей, помогая обеспечить высокую эффективность инвестиций в сферу IT. В руках же системных аналитиков и разработчиков BPwin - еще и мощное средство моделирования процессов при создании корпоративных информационных систем (КИС).

BPwin совмещает в одном инструменте средства моделирования функций (IDEF0), потоков данных (DFD) и потоков работ (IDEF3), координируя эти три основных аспекта бизнеса для соответствия потребностям бизнес-аналитиков и системных аналитиков. BPwin позволяет повторно использовать ключевую информацию моделирования с точки зрения базовых аспектов, чтобы определить точки конфликтов и, в конечном счете, достичь их согласования.

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

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

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

18. Диаграмма потока данных (dfd). Этапы построения. Основные символы диаграммы в нотации Иодана и Гейна - Сарсона.

DFD – основное средство моделирования функциональных требований проектирования системы. С их помощью все требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных.

Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня. Когда дальнейшая детализация перестаёт быть полезной, переходим к выраженной логике функций при помощи СП (миниспецификаций). Содержание каждого хранилища также сохраняется в словаре данных, а модель хранилища данных раскрывается с помощью ERD. В случае наличия реального времени DFD дополняется средствами описания, зависящие от времени поведения системы, раскрывающиеся с помощью STD.

Компоненты логической модели

Для изображения DFD используются две различные нотации:

Потоки данных – механизмы, используемые для моделирования передачи информации из одной части ИС в другую. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации. Информация может двигаться в одном направлении, обратном и возвращаться в источник. Такая ситуация моделируется либо 2 разными потоками, либо одним двунаправленным.

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

Хранилище (накопитель) данных – позволяет на определённых участках определить данные, которые будут сохранены в памяти между процессами. Фактически хранилище представляет срезы потоков данных во времени информации, которое оно содержит, может использоваться в любое время после её определения, а данные могут определяться в любом порядке. Имя хранилища должно идентифицировать его содержание и быть существительным. В случае, когда поток данных входит (выходит) «из хранилища» и его структура соответствует структуре хранилища, он должен иметь то же самое имя.

Внешняя сущность (терминатор) представляет собой сущность вне контекста системы. Является источником или приемником систем данных.

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

Контекстная диаграмма отражает интерфейс системы с внешним миром (между системой и внешними существующими потоками данных). Данная диаграмма идентифицирует внешние сущности, а также как правило, единый процесс, отражающий главную цель. Она устанавливает границы анализируемой системы. Каждый проект ИС должен иметь только одну контекстную диаграмму, при этом нет необходимости в нумерации ее единственного процесса.

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

Построение иерархии DFD осуществляется так, что каждый процесс более низкого уровня необходимо соотносить с процессом верхнего уровня. Обычно для этой цели используются структурные номера процессов. Если мы детализируем процесс №1 на диаграмме первого уровня, раскрываем его с помощью DFD, содержащей 4 процесса, то их номера имеют вид: 1.1, 1.2 и т.д. При необходимости можно перейти на следующий уровень (1.2.1, 1.2.2 и т.д.)