 |
Пример создания DFD-диаграммы
|
|
|
|
В качестве предметной области выбрана сфера продаж некоторой продукции.
1. После запуска CA ERwin Process Modeler необходимо создать новую модель, которая будет представлять моделируемую систему. Для этого можно воспользоваться пунктом «New model» панели быстрого доступа или File/New основного меню. Диалоговое окно создания новой модели показано на рисунке 10.
Рисунок 10 - Создание новой модели
2. Учитывая заданную предметную область и методику моделирования, в качестве названия для диаграммы следует указать «Продажа продукции», а в качестве типа – Data Flow (DFD).
3. Следующим шагом является настройка базовых параметров, которые будут использоваться для всех создаваемых в дальнейшем моделей. Соответствующее окно (рисунок 11) появляется автоматически после подтверждения введённого названия и типа модели в пункте 2 или доступно в пункте основном меню «New Model Properties» во вкладке Model.
Примечание 1: Последовательное указание параметров во всех вкладках позволит выполнить первичную настройку рабочего окружения и визуального оформления диаграмм.
Примечание 2: При использовании стандартного оформления рамок и заголовков документа достаточно настроить параметры вкладок General, Numbering, Display и Layout.
Рисунок 11 - Окно указания параметров для новых моделей
Вкладка General (рисунок 11) служит для указания автора диаграммы и его инициалов.
Примечание 3: Указанный автор также будет считаться автором всех будущих моделей. Для изменения этого параметра необходимо отредактировать содержимое данного поля у требуемой модели.
Вкладка Numbering (рисунок 12) содержит в себе параметры нумерации блоков модели.
Примечание 4: Для обеспечения лучшей наглядности, в данном примере используются настройки, указанные на рисунке 12. В данном случае каждый блок Activity будет иметь номер с префиксом в виде литеры «A» и форматом, указанным в параметрах поля Diagram.
|
|
|
Рисунок 12 - Вкладка Numbering
Вкладка Display (Рисунок 13) определяет элементы, которые могут быть визуально отображены в проектируемой модели.
Примечание 5: В связи с отсутствием необходимости производить анализ частотных, временных и ценовых аспектов функционирования рассматриваемой системы, следует отключить отображение соответствующих элементов.
Примечание 6: Для облегчения процесса чтения диаграмм следует отключить отображение пунктов Shadows и ICOM Codes, а также выбрать «Node Number» в области «Off-page Reference Label». Shadows отвечает за отображение теней блоков Activities, ICOM Codes – идентификаторов связей Activities, Off-page Reference Label определяет обозначение внешних ссылок на диаграммах в пределах модели.
Рисунок 13 - Вкладка Display
Вкладка Layout позволяет настраивать поведение объектов и стрелок на диаграммах. В рамках данного примера используются параметры, указанные на рисунке 14.
Рисунок 14 - Вкладка Layout
Вкладка ABC Units используется для определения базовых параметров при ABC-анализе.
Вкладки Page Setup и Header/Footer позволяют настраивать формат листа, на котором будут отображаться диаграммы, а также состав и формат рамок и заголовков.
4. После завершения начального этапа настроек будет отображён шаблон созданной контекстной диаграммы (рисунок 15).
5. Используя параметры из пункта 3 необходимо настроить созданные диаграмму и модель. Для этого следует использовать пункты основного меню Diagram/Diagram Properties и Model/Model Properties или одноимённые пункты контекстного меню свободной от элементов рабочей области диаграммы.
Примечание 1: В качестве обязательных параметров созданной диаграммы должны быть указаны: её автор (вкладка Name), организация или подразделение, в котором эта диаграмма будет использоваться (вкладка Kit), а также её статус (вкладка Status). В качестве необязательного параметра можно указать описание содержания диаграммы (вкладка Diagram Text).
|
|
|
Примечание 2: В качестве обязательных параметров созданной модели должны быть указаны: название модели, название проекта, в котором эта модель используется, автор и тип модели (вкладка General), назначение модели и точка зрения, с которой эта модель разрабатывалась (вкладка Purpose), разъяснение цели моделирования и область моделирования (вкладка Definition), описание источников информации, используемой для моделирования (вкладка Source). Окно параметров модели показано на рисунке 16.
Рисунок 16 - Окно параметров модели
6. CA ERwin Process Modeler требует дополнительной настройки отображения кириллических шрифтов. Для этого необходимо воспользовать пунктом Default Fonts в меню Model и указать шрифты и язык для всех параметров.
Примечание: Обязательным условием является активация параметра «Change all occurrences», иначе изменения коснутсья не всех текстовых полей диаграммы.
Рисунок 17 - Изменение шрифтов
7. Для контекстной диаграммы необходимо определить и создать связи, которые имеет рассматриваемая система или процесс.
Для создания связей в инструментальном наборе программы существует инструмент Precedence Arrow Tool, с помощью которого можно создать все 4 вида связей ICOM. Вид создаваемой связи определяется границей рабочей области, от которой она создаётся (для диаграмм IDEF0):
· от верхней границы создаются связи типа «управление»;
· от левой границы создаются связи типа «материальный или информационный вход»;
· от нижней границы создаются связи типа «Механизм»;
· связь типа «материальный или информационный выход» создаётся от правого края основного блока к правому краю рабочей области.
Процесс создания связи можно разбить на два этапа:
· активация инструмента Precedence Arrow Tool (
) и выбор границы или выходной части основного блока, определяющей тип создаваемой связи (рисунок 18);
· указание конца связи в основном блоке или на правой границе рабочей области (рисунок 19).
Рисунок 18 - Первый этап создания связи
Рисунок 19 - Второй этап создания связи
Используя описанную последовательность действий можно создавать связи анализируемой системы.
|
|
|
8. Согласно общей структуре процесса продаж, в качестве выходных данных блока должны быть сформированы сведения о заказе и счета на оплату, а в качестве входной информации поступают заказы, продукция со склада, платежные документ заказчика.
Процесс управления продажами продукции можно отнести с составной части информационной подсистемы предприятия, а значит применение методики DFD оправдано.
В качестве внешних сущностей процесса продаж выделены сущности Клиент и Склад.
Полученная DFD-диаграмма (А-0) представлена на рисунке 20.
Рисунок 20 – DFD-диаграмма (А-0) «Продавать продукцию»
Руководствуясь заданной тематикой, возможно декомпозировать в методике DFD главный блок «Продавать продукцию».
Структуру декомпозируемого процесса можно представить в виде 3 блоков:
· блок «обработать заказы»;
· блок «доставить продукцию»;
· блок «проконтролировать оплату».
Поскольку информационная система подразумевает хранение и дальнейшее использование различной информации, следует добавить хранилища данных, обеспечивающие процессы и каждый значимый информационный поток между процессами.
К таким потокам можно отнести:
· данные клиента;
· данные счетов;
· данные заказа;
· информация о доставке.
Описание связей блоков диаграммы представлено в таблице
Таблица 3 – Описание связей блоков DFD-диаграммы
| Название блока | Входные потоки | Выходные потоки |
| Обработать заказы | Заказы Данные клиента | Данные заказа Данные счетов |
| Сформировать учётную карточку заказа | Описание заказа Менеджер Информационная система Регламент Реквизиты партнёров Реквизиты поставщиков Контракты | Учётная карточка заказа |
| Сформировать запрос сырья для заказа | Карточка заказа Информационная система Технолог | Запрос сырья |
| Сформировать сведения о заказе | Карточка заказа Информационная система Технолог | Сведения |
Полученная DFD-диаграмма представлена на рисунке 21.
Рисунок 21 – Детализированная DFD-диаграмма (А0) «Продавать продукцию»
Построение модели
|
|
|
Главная цель построения иерархического множества DFD заключается в том, чтобы сделать требования ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями:
· DFD-диаграмма должна быть полезной;
· цель построения DFD-диаграмм – общение с заказчиком и пользователями, уточнение требований к системе, передача знаний о предметной области от системных аналитиков к разработчикам автоматизированной системы;
· правило от 2 до 6. На DFD-диаграмме должно быть не меньше двух и не больше шести процессов/подсистем. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса;
· принцип абстракции (отвлечения от деталей). Для подсистем и процессов строится иерархия DFD-диаграмм. На каждой диаграмме должны быть представлены только основные процессы, важные на данном уровне рассмотрения. На диаграммах нужно абстрагироваться от несущественных пока деталей, нюансов работы и т.д.;
· материальные процессы, потоки и хранилища на диаграммах DFD не отображаются (только процессы обработки информации, потоки данных и хранилища данных);
· однократно определять функционально идентичные процессы на самом верхнем уровне, где такой процесс необходим, и ссылаться к нему на нижних уровнях;
· сначала должны быть рассмотрены функции (процессы), затем данные (хранилища), необходимые для выполнения этих функций. Подход «от данных к функциям» запрещен. Декомпозицию потоков данных лучше осуществлять параллельно с декомпозицией процессов; эти две работы должны выполняться одновременно, а не одна после завершения другой;
· не должно быть связей между внешними сущностями. Во внешних сущностях не должно быть обработки информации;
· имена процессов должны быть глаголами. Имена подсистем должны быть существительными (названия отделов, должностей). Имена потоков должны быть названиями документов (или групп документов) или отражать передаваемую информацию (данные). Следует выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения понимаемости диаграмм, при этом стараться не использовать аббревиатуры;
· для хранилища данных должен быть вход и выход. Должен соблюдаться закон сохранения информации: нельзя использовать того, чего нет в хранилище. Все что хранится, нужно использовать. Запросы к хранилищу данных на диаграммах не отображаются;
|
|
|
· нужно избегать пересечений стрелок, можно создавать копии хранилищ данных. Множественные однородные потоки данных можно объединять в один;
· элементарные процессы на диаграммах DFD не детализируются;
· на диаграммах DFD не должно быть изолированных (несвязанных) объектов (внешних сущностей, подсистем, процессов, хранилищ данных);
· пользоваться простейшими диаграммными техниками: если что-либо возможно описать с помощью DFD, то это и необходимо делать, а не использовать для описания более сложные объекты;
· отделять управляющие структуры от обрабатывающих структур (т.е. процессов), локализовать управляющие структуры.
В соответствии с этими рекомендациями процесс построения модели разбивается на следующие этапы:
1. Расчленение множества требований и организация их в основные функциональные группы.
2. Идентификация внешних объектов, с которыми система должна быть связана.
3. Идентификация основных видов информации, циркулирующей между системой и внешними объектами.
4. Предварительная разработка контекстной диаграммы, на которой основные функциональные группы представляются процессами, внешние объекты - внешними сущностями, основные виды информации - потоками данных между процессами и внешними сущностями.
5. Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при этом изучении вопросы по всем ее частям.
6. Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.
7. Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы.
8. Проверка основных требований по DFD первого уровня.
9. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.
10. Проверка основных требований по DFD соответствующего уровня.
11. Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.
12. Параллельное (с процессом декомпозиции) изучение требований (в том числе и вновь поступающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям.
13. После построения двух-трех уровней проведение ревизии с целью проверки корректности и улучшения понимаемости модели.
14. Построение спецификации процесса (а не простейшей диаграммы) в случае, если некоторую функцию сложно или невозможно выразить комбинацией процессов.
|
|
|
