Создание dfd модели бизнес процесса

Федеральное государственное бюджетное образовательное учреждение высшего образования «Омский государственный технический университет» Кафедра математических методов и информационных технологий в экономике Домашнее задание по дисциплине «Проектирование информационных систем» Автоматизация процессов торговой фирмы по продаже запчастей Выполнил студент гр. «____» ______________ 2017 г. Проверилa ______________ «____» ______________ 2017 г. Омск 2017 Оглавление Введение. 3 Предварительный анализ работы предприятия.

4 Модель AS-IS. 4 1.Функциональная диаграмма (IDEF0 или SADT) 4 2. Диаграмма потоков данных (DFD) 14 3. Диаграмма IDEF3. 17 Модель TO-BE. 20 4. Диаграмма Swim Lane. 24 Заключение.

25 Список литературы.. 26

Введение

Компании, деятельность которых связана с торговлей или производством, имеют дело с временным хранением товара или продукции на складах до момента их реализации.

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

Пример построения диаграммы потоков данных (Data Flow Diagram)

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

В качестве средства достижения поставленной цели будет использоваться моделирование бизнес-процессов и разработка порядка их автоматизации.

Задачи работы:

· получение представлений о методах и средствах проектирования современных ИС;

· приобретение навыков использования CASE-систем проектирования ИС.

Работа состоит из следующих частей:

Предварительный анализ работы предприятия

Перечень проектных мероприятий составляется путем рассмотрения недостатков работы «Торговой фирмы по продаже запчастей», выявленных в процессе комплексного анализа.

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

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

Модель AS-IS

Функциональная диаграмма (IDEF0 или SADT)

Анна Вичугова — Практическое использование DFD: как описать движение данных в бизнес-процессах?

Для проведения анализа и реорганизации бизнес – процессов предназначено CASE-средство верхнего уровня AllFusion Process Modeler (BPwin), поддерживающее методологии:

IDEF0 (функциональная модель);

Создание модели в стандарте IDEF0

BPwin — программный продукт, который причисляется к категории CASE — средств верхнего уровня. Разработчиком является компания 1td.

Информационная модель определена для изображения существующих бизнес – процессов в компании (так называемая модель AS-IS «как есть») и безупречного их выполнения – то, к чему нужно стремиться (модель ТО-ВЕ «как должно быть»). Методология IDEF0 описывает построение иерархической системы диаграмм – единичных описаний фрагментов разрабатываемой системы.

Построение модели системы начнем с описания функционирования компании (системы) или отдельной ее части в целом в виде контекстной диаграммы.

Ход выполнения работы:

1. Запускаем программу.

2. Создаем новый бизнес процесс:

Рисунок 1 – Присвоение модели имени и выбор типа модели

Рисунок 2 — Ввод имени автора модели и его инициалов

Рисунок 3 – Окно задания свойств модели

Рисунок 4 – Внесение данных о цели моделирования и точке зрения на модель

Рисунок 5 – Внесение дополнительных данных определяющих модель

Рисунок 6 — Контекстная диаграмма функционирования складского учета

Основные составляющие контекстной диаграммы:

1. Функциональный блок: Складской учет компании;

2. Стрелка входных данных: Заявка на товар;

3. Стрелки управления называются: Законодательство РФ, Нормативные документы;

4. Стрелки выходных данных: Документы на товар, Товар на складе;

5. Стрелки механизма: Сотрудники.

Рисунок 7 – Задание опций генерирования отчета ModelReport

Рисунок 8– Предварительный просмотр отчета ModelReport

Следующий уровень — функциональная декомпозиция, представляет собой способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. На рисунке 9 представлена декомпозиция основного бизнес-процесса Компании и выделены основные функции, связанные с деятельностью работы складов организации:

1. Принимать товар на склад:

• Стрелки входа называются: Заявка на товар.

• Стрелки выхода называются: Данные о товаре, Принятый на склад товар.

Комплектовать товар

• Стрелки входа называются: Данные о товаре, Принятый на склад товар.

• Стрелки выхода называются: Информация о поступлениях.

Перемещать товар на склад

• Стрелки входа называются: Информация о поступлениях.

• Стрелки выхода называются: Товар, Данные по загруженности склада.

• Стрелки управления называются: Законодательство, нормативные документы, должностные инструкции.

• Стрелки механизма называются: Сотрудники.

Рисунок 9 Схема основных бизнес процессов

Диаграмма дерева узловиDFD

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

Ход выполнения работы.

Рисунок 10 – Первое диалоговое окно гида NodeTreeWizard

Рисунок 11 – Второе диалоговое окно гида NodeTreeWizard

Рисунок 12 — Диаграмма дерева узлов

BPwin предоставляет аналитику инструмент для оценки модели – стоимостный анализ, основанный на работах (Activity BasedCosting, ABC),с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Reengineering, BPR).

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

Стоимостныйанализ (Activity Based Costing)

Ход выполнения работы.

Рисунок13- ВкладкаABC UnitsдиалогаModel Properties

Рисунок14– Незаполненное окноCostCenterDictionary

Диаграмма потоков данных (DFD)

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

Для создания диаграммы действия рассмотрим ведение учета:

На складе исследуемой фирмы производится учёт движения товаров, а именно:

— фиксируем поступление на склад товаров и ценностей от поставщика;

— оформляем возврат от покупателей бракованных товаров;

— оформляем оплата зачислившихся на склад ТМЦ;

— осуществляем списание товаров подлежащих уничтожению;

— фиксируем передвижение товаров от одного материально ответственного лица к другому.

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

Поступление ТМЦ на предприятие сопровождается документом «Приходная накладная».

При выдаче ТМЦ со склада формируется документ «Расходная накладная».

При возвращении бракованного товара от покупателя производим поиск документа, на основании которого был совершён отпуск продукции соответствующему продавцу, а потом формируем производный документ «Возвратая накладная».

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

Списание товаров испорченных или просроченных осуществляется на основании акта о списании.

При перемещении ТМЦ формируется накладная на внутреннее перемещение товаров.

Создание диаграммы DFD

Ход выполнения работы.

Рисунок 16 Выбор нотации DFD в диалоге ActivityBoxCount

Сформируем диаграммы действия:

Рисунок 17диаграмма потоков данных

Рисунок 18 декомпозиция диаграммы потоков данных

Рисунок19Модель DFD Поступление товара

Диаграмма IDEF3

IDEF3 — методология моделирования и стандарт документирования процессов, происходящих в системе. Метод документирования технологических процессов представляет собой механизм документирования и сбора информации о процессах.

Основой методики служит сценарий процесса, выделяющим из модели последовательность происходящих в системе действий.

Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:

· Документировать имеющиеся данные о технологии процесса.

· Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов.

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

· Содействовать принятию оптимальных решений при реорганизации технологических процессов.

· Разрабатывать имитационные модели технологических процессов, по принципу «КАК БУДЕТ, ЕСЛИ. «

В ходе выполнения работы была создана диаграмма декомпозиции работы «Оформление заявки на ремонт» в стандарте IDEF3 (Рисунок 20-22).

Рисунок 20 начальная форма создания модели

Рисунок 21IDEF3 модель

Рисунок 22 — IDEF3 модель«Складской учет»

Данная диаграмма описывает процесс продвижения документации при обслуживании заявки по ремонту.

Модель TO-BE

Модель ТО-ВЕ создается на основе анализа модели AS-IS. Анализ может проводиться как по формальным признакам, так и по неформальным — на основе знаний предметной области. Модель TO-BE описывает возможное будущее состояние предметной области, в которое она перейдет в результате оптимизации существующей системы и внедрения новых технологий.

На основе модели As-Is были выявлены следующие ключевые процессы, подлежащие автоматизации.

1. Построение модели ИС начинается с описания функционирования предприятия (системы) или отдельной ее части (в нашем случае это деятельность складского хозяйства) в целом в виде контекстной диаграммы. На Рисунке 23 представлена контекстная диаграмма ИС «Управление складским учетом» ТО-ВЕ «как должно быть».

Рисунок 23- Контекстная диаграмма функционирования склада

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

Model Name: Управлять складскими операциями

Definition: Модель описывает деятельность склада, а конкретно, выполняемые им функции:

1) Приемка товара

2) Отгрузка и возврат товара

После описания контекстной диаграммы проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема, при необходимости, разбивается на более мелкие и так далее до достижения нужной степени подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции,и представлена на рисунке 24.

Рисунок 24-Диаграмма декомпозиции IDEF0

В результате дальнейшего разбиения функции Хранение получаем диаграмму декомпозиции (см. Рисунок 25):

Рисунок 25 — Диаграмма декомпозиции функции «Хранить товар»

Также была построена новая диаграмма для описания процесса «оформление заявки на ремонт» в стандарте IDEF3.

Рисунок 26 — » Диаграмма декомпозиции в стандарте IDEF3″

Данная диаграмма описывает процесс движение документов в электронном виде в компании. Работы на диаграмме соединяются связями «Старшая стрелка», поскольку они только показывают последовательность действий над одними и теми же объектами. Итоги внедрения компьютерной информационной системы:

· Время выполнения операций значительно сократилось. Теперь сотруднику для добавления и поиска данных, достаточно отрыть программу и внести в нее данные или найти необходимые;

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

Диаграмма SwimLane

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

В ходе выполнения работы была создана SwimLane диаграмма (Рисунок 27).

Рисунок 27 — «Диаграмма SwimLane»

Заключение

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

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

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

После изучения принципов использования среды BPwin, была построена функциональная модель информационной системы.

Были спроектированы две модели «AS-IS» (как есть) и «TO-BE» (как будет).

Были построены и описаны следующие диаграммы:

· диаграмма потоков данных;

В ходе выполнения работы были решены все поставленные задачи, а именно:

· Были изучены методы и средства проектирования ИС;

· Разработана и описана функциональная модель информационной системы учета заявок

Список литературы

1. ГОСТ 2.105-95 ЕСКД. Общие требования к текстовым документам (с Изменением N 1).

2. ГОСТ 7.32- 2001 Структура и правила оформления 22с.

3. ГОСТ Р 50922-2006 Защита информации. Основные термины и определения.

4. ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.

5. Криницкий Н.А., Миронов Г.Д., Фролов Г.Д. Автоматизированные информационные системы — М.: Наука, 1982.- 384 с.

6. Алешин Л.И., Максимов Н.В.-М.: ММИЭИФП, 2004.- 561 с. Информационные технологии.

7. Баранов В.В. и др. / Автоматизация управления предприятием / ИФРА – М,. – Петров В. Н. / Информационные системы, учебник ПИТЕР, 2011.

Дата добавления: 2018-04-15 ; просмотров: 1711 ; Мы поможем в написании вашей работы!

Поделиться с друзьями:

Источник: studopedia.net

DFD методология. Нотация, принципы моделирования Методология моделирования DFD.

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

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

Графический язык моделирования DFD диаграмм

Существуют две нотации DFD:

Требования к оформлению функций:

1. Каждая функция должна иметь идентификатор;
2. Названия работы нужно формулировать согласно следующее формуле: Название работы = Действие + Объект, над которым действие осуществляется [note]Например, если эта работа связана с действием по продаже продукции, то ее нужно назвать [/note]
3. Название работы должно быть по возможности кратким (не более 50 символов) и состоять из 2-3 слов . Об этом говорит сайт https://intellect.icu . В сложных случаях также рекомендуется для каждого краткого названия работы сделать ее подробное описание, которое поместить в глоссарий.

Требования к оформлению потока данных:

1. Название потока нужно формулировать согласно следующей формуле:

Название потока = Объект, представляющий поток + Статус объекта

[note]Если речь идет о продукции, которую отгрузили клиенту, то поток можно назвать или . В данном случае это объект, представляющий поток, а — статус объекта.[/note]

2. Название должно быть по возможности кратким и состоять из 2-3 слов.

Построение DFD-модели

Построение DFD-модели базируется на принципе декомпозиции. DFD-модель включает в себя три документа, которые ссылаются друг на друга: Графические диаграммы, Миниспецификация, Словарь данных.

1. Контекстная диаграмма или иерархия контекстных диаграмм

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

Однако в некоторых случаях целесообразнее и нагляднее построить несколько контекстных диаграмм с иерархией:

• наличие большого количества внешних сущностей (десять и более);
• распределенная природа системы;
• многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.

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

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

2. Детализация контекстной диаграммы

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

При детализации должны выполняться следующие правила:

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

[note]Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.[/note]

3. Миниспецификация

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

Миниспецификация является конечной вершиной иерархии модели DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:

• у процесса небольшое количество входных и выходных потоков данных (2-3 потока);
• процесс можно описать в виде последовательного алгоритма;
• процесс выполняет единственную логическую функцию преобразования входной информации в выходную;
• описать логику процесса можно в виде миниспецификации небольшого объема (не более 20-30 строк).

4. Словарь данных

Для каждого потока в словаре хранятся: имя потока, тип, атрибуты.

1. Простой / групповой (объединяющий несколько потоков)
2. Внутренний/ внешний;
3. Поток данных/ поток управления;
4. Непрерывный (принимающий любые значения в рамках диапазона)/дискретный (принимающий конкретные значения)

1. Имена-синонимы потока;
2. В случае группового потока, все потоки которые поток объединяет;
3. Единицы измерения потока;
4. Диапазон значения и типичное значение с информацией по обработке экстремальных ситуаций;
5. Список значений и их смысл для дискретного потока;
6. Список номеров диаграмм, в которых поток встречается;
7. Список потоков, в которые поток входит (если в свою очередь входит в другой групповой поток);
8. комментарии.

Проверка DFD модели

После построения законченной модели системы ее необходимо проверить на полноту и согласованность.

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

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

К сожалению, в одной статье не просто дать все знания про dfd . Но я — старался. Если ты проявишь интерес к раскрытию подробностей,я обязательно напишу продолжение! Надеюсь, что теперь ты понял что такое dfd , принципы моделирования, методология моделирования dfd и для чего все это нужно, а если не понял, или есть замечания, то нестесняся пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Проектирование веб сайта или программного обеспечения

Источник: intellect.icu

DFD и WorkFlow (IDEF3)

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

1. функции-обработки информации (работы);
2. документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации;
3. внешние ссылки (external reference), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
4. таблицы для хранения документов (хранилища данных, data store).

Для построения диаграмм DFD в BPWin используется нотация Гейна -Сарсона.

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

Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.

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

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

Рис. 3.1. Внешняя сущность

Для дополнения модели ID ЕГО диаграммой DFD нужно в процессе декомпозиции в диалоге Activity Box Count указать тип диаграммы DFD.

Диаграммы IDEF3

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

Цель IDEF3 — дать аналитикам описание последовательности выполнения процессов, а также объектов, участвующих совместно в одном процессе.

IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEFO и содержит все необходимое для построения моделей, которые могут быть использованы для имитационного моделирования.

Диаграммы

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

Единицы работы — Unit of Work (UOW), также называемые работами, являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками и имеют имя, обозначающее процесс действия и номер (идентификатор). В имя обычно включается основной результат работы (например, приготовление обеда).

Связи

Показывают взаимоотношения работ. Все связи в IDEF3 являются однонаправленными.

Старшая (Precedence) линия — сплошная линия, связывающая единица работ. Рисуется слева направо или сверху вниз. Показывает., что работа-источник должна закончиться прежде, чем работа-цель начнется.

Линия отношения (Relation Link) — пунктирная линия, использующаяся для изображения связей между единицами работ, а также между единицами работ и объектами ссылок.

Потоки объектов (Object Flow) — стрелка с двумя наконечниками, применяется для описания использования объекта в двух или более единицах работы, например когда объект порождается в одной работе и используется в другой.

Перекрестки (Junction) — используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы.

Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fanout Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления.

Типы перекрестков

Объекты-ссылки — являются специальными символами, которые ссылаются на внешние части описания процесса. Они добавляются на диаграмму для того, чтобы обратить внимание редактора на что-либо важное, что невозможно связать со стрелкой, работой или перекрестком.

Для внесения объекта-ссылки служит кнопка Объект-ссылки отображается в виде прямоугольника. Объекты-ссылка должны быть связаны с единицами работ или перекрестками пунктирными линиями.

При внесении объектов-ссылок необходимо указать их тип.

Типы объектов-ссылок

Тип объекта-ссылки

Цель описания

Описывает участие важного объекта в работе

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

UQB (Unit of behavior)

Применяется, когда необходимо подчеркнуть множественное использование какой-либо работы, но без цикла. Например, работа «Контроль качества» может быть использована в процессе «Изготовления изделия» несколько раз, после каждой единичной операции. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работ

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

Используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках

Пример

Диаграммы DFD

Диаграммы DFD можно использовать как дополнение к диаграммам IDEFO для описания документооборота и обработки информации.

Диаграммы IDEF3

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

Перед началом моделирования необходимо создать иерархическую структуру работ, описывающую процесс разработки системы.

1. Разработка технического задания.

• Составление технического задания.
• Утверждение технического задания.

• Определение объектов системы и их атрибутов.
• Определение категорий пользователей.
• Создание запросов к системе.

3. Разработка модульной структуры.

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

4. Проектирование БД.

• Проектирование логической структуры БД.
• Проектирование физической структуры БД.
• Определение взаимосвязей между БД.
• Выбор СУБД.

Согласно созданной структуре работ определим диаграммы, добавив на них взаимосвязи между работами.

Рис. 3.2. Диаграмма «Разработка системы службы занятости»

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

Проведем декомпозицию работ по созданию службы занятости, ориентируясь на созданную структуру работ.

Рис. 3.3. Декомпозиция работы «Разработка технического задания»

Полученные диаграммы описывают процесс создания системы службы занятости на основе структуры работ по процессам. Обычно для более точного описания проекта создают несколько структур. В данном случае полезно создать структуру «по подсистемам», описав работы, необходимые для создания конкретных подсистем службы занятости.

Рис. 3.4. Декомпозиция работы «Анализ»

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

Структура работ по подсистемам

1. Разработка технического задания.

• Составление технического задания.
• Подписание технического задания.

2. Разработка подсистемы профессиональных и психологических тестов.

• Определение межсистемных соглашений.
• Определение объектов и их атрибутов.
• Определение категорий пользователей.
• Создание запросов к системе.
• Проектирование структуры БД.

Рис. 3.6. Декомпозиция работы «Проектирование БД»

3. Разработка подсистемы обработки запросов. Определение межсистемных соглашений.

• Определение межсистемных соглашений.
• Определение объектов и их атрибутов.
• Определение категорий пользователей,
• Создание запросов к системе.
• Проектирование структуры БД.

4. Разработка подсистемы экспертных оценок.

• Определение межсистемных соглашений.
• Определение объектов и их атрибутов.
• Определение категорий пользователей.
• Создание запросов к системе.
• Проектирование структуры БД.

5. Разработка подсистемы контроля успеваемости студентов.

• Определение межсистемных соглашений.
• Определение объектов и их атрибутов.
• Определение категорий пользователей.
• Создание запросов к системе.
• Проектирование структуры БД.

6. Разработка архитектуры всей системы.

7. Объединение подсистем.

• Проверка соблюдения межсистемных соглашений.
• Определение взаимосвязей между БД.

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

Создадим пакет диаграмм, соответствующий структуре работ «по подсистемам».

Контрольные вопросы

1. Что описывает диаграмма DFD?
2. Какая нотация используется в BPWin для построения диаграмм DFD?
3. Что описывает диаграмма IDEF3?
4. Перечислите составные части диаграммы DFD.
5. В чем состоит назначение процесса?
6. Что называется внешней сущностью?
7. Что описывают хранилища?
8. Объясните механизм дополнения диаграммы IDEFO диаграммой DFD.
9. Перечислите составные элементы диаграмм IDEF3.
10. Что показывают связи в диаграммах IDEF3?
11. Перечислите типы стрелок в диаграммах IDEF3.
12. Что называется перекрестком?
13. Назовите типы перекрестков.
14. Что называется объектом-ссылкой?
15. Какие бывают типы объектов-ссылок?
16. Как добавить объект-ссылку?

Источник: itteach.ru