Проектирование информационных систем средствами BPwin




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

AllFusion Process Modeler 7 (ранее BPwin) – инструмент для моделирования, анализа, документирования и оптимизации бизнес-процессов. AllFusion Process Modeler 7 можно использовать для графического представления бизнес-процессов. Графически представленная схема выполнения работ, обмена информацией, документооборота визуализирует модель бизнес-процесса. Графическое изложение этой информации позволяет перевести задачи управления организацией из области сложного ремесла в сферу инженерных технологий.

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

Процесс построения информационной модели в BPwin состоит из следующих шагов:

· построить контекстную диаграмму;

· провести функциональную декомпозицию;

· после каждого сеанса декомпозиции провести сеанс экспертизы.

В методологии IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной, т.е. функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Под моделью в методологии IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы. Описание системы с помощью методологии IDEF0 называется функциональной моделью. Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма).

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

Рисунок 2 – Контекстная диаграмма склад

 

Декомпозиционное разложение модели используется в моделировании бизнес-процессов, для того чтобы дать более подробное описание блоков. Каждое из этих действий может в свою очередь быть декомпозировано. При каждой декомпозиции блока создается новая диаграмма. Число декомпозиций не ограничено и полностью зависит от уровня сложности, который необходимо показать в модели. Декомпозируем контекстную диаграмму на 3 функциональных блока: Приемка товара на склад; Хранение и переучет продукции; Отгрузка продукции.

Рисунок 3 - Диаграмма IDEF0

Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.

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

Любая DFD-диаграмма может содержать работы, внешние сущности, стрелки (потоки данных) и хранилища данных.

Далее моделировать систему будем, используя диаграммы потоков данных (DFD).

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

· Проверка товарно-транспортной накладной;

· Проверка поставленной продукции;

· Занесение данных о продукции в БД;

· Передача продукции на хранение.

Рисунок 4 - Диаграмма DFD «Приемка товара на склад»

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

· Размещение товара на складе;

· Анализ наличия необходимого количества на складе (на этом этапе лицу, принимающему решение, передается оперативная информация).

Рисунок 5 - Диаграмма DFD «Хранение и переучет продукции»

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

· Проверка наличия товара на складе;

· Занесение информации об отгружаемой продукции в БД;

· Отгрузка продукции по требованию.


Рисунок 6 - Диаграмма DFD «Отгрузка»


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

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет точно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии – IDEF3, также называемой workflow diagramming. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.

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

Декомпозируем функциональный блок «Проверка товарно-транспортной накладной» который, в свою очередь, является элементом декомпозиции блока «Приемка товара на склад» на четыре действия:

· Принятие товарно-транспортной накладной;

· Проверка поставщика;

· Проверка реквизитов документа;

· Проверка количества продукции.


Рисунок 7 - Диаграмма IDEF3 «Проверки товарно-транспортной накладной»


Декомпозируем функциональный блок «Проверка поставленной продукции» который, в свою очередь, является элементом декомпозиции блока «Приемка товара на склад» на три действия:

· Проверка продукции на годность;

· Принять продукцию;

· Вернуть поставщику.

Рисунок 8 - Диаграмма IDEF3 «Проверки поставленной продукции»




Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2019-04-04 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: