Методология IDEF

1.

Тема 1.1.2
Методология IDEF

2.

Обзор методов IDEF
Структурный анализ – метод исследования системы, начинающий с ее общего
обзора, который затем детализируется, приобретая иерархическую структуру со
всем больше числом уровней.
К методологии структурного анализа относятся IDEF к семейству которых
относятся следующие стандарты:
IDEF0 – методология многофункционального моделирования
IDEF1 – методология моделирования информационных потоков внутри
системы, позволяющая отображать и анализировать их структуру и взаимосвязи
(методология DFD)
IDEF1x – методология построения реляционных структур (сущночть-связь,
IR-диаграмма )
IDEF2 – методология динамического моделирования, развития системы,
описание динамики изменений модели
IDEF3 – методология документирования процессов, происходящих в
системе

3.

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

4.

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

5.

Методология функционального моделирования SADT
Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная
методология IDEF0 (Icam DEFinition). Методология SADT представляет собой совокупность методов, правил и
процедур, предназначенных для построения функциональной модели объекта какой-либо предметной
области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им
действия и связи между этими действиями.
Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов
текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции
ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип
интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая
подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны.
Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой,
входящей в блок снизу.
Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших
уровней детализации по мере создания диаграмм, отображающих модель.

6.

На методологии SADT основана группа методологий IDEF. Она состоит из трех базовых методологий
графического описания систем: IDEF0, IDEF1, IDEF2.
IDEF0 позволяет создать модель функций процесса. На диаграмме IDEF0 отображаются основные функции
процесса, входы, выходы, управляющие воздействия и устройства, взаимосвязанные с основными функциями.
Процесс может быть декомпозирован на более низкий уровень.
IDEF0 методология функционального моделирования (англ. function modeling) и графическая нотация,
предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0
является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между
работами, а не их временна́я последовательность (поток работ)

7.

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

8.

Методология IDEF0 – это методология построения процессов верхнего уровня, самый
укрупненный взгляд на все бизнес-процессы. Контекстная диаграмма, особенно диаграмма самого
верхнего уровня А-0 не дает полного представления о процессе (функции). Построение контекстной
диаграммы А-0 показывает: какую бизнес-цель мы преследуем, какие ресурсы используются при
этом, что будет получено на выходе исполнения процесса, кто будет задействован при исполнении
процесса, чем будет регламентироваться процесс. Диаграмма A-0 устанавливает область
моделирования и ее границу. Стрелки на этой диаграмме отображают связи объекта
моделирования с окружающей средой.
При декомпозиции большая задача разбивается на более детальные подзадачи. Которые могут
проходить как параллельно, так и последовательно. Количество декомпозиций зависит от
необходимого уровня детализаций.

9.

Диаграмма декомпозиции первого уровня
На схеме видно, что для того, чтобы получить требуемое блюдо, нужно выполнить определенную
последовательность операций:
1) Подготовить ингредиенты;
2) Сформировать котлеты;
3) Обжарить котлеты;
4) Подать блюдо на стол.
Однако функциональный блок А1 пока представляется в виде «четного ящика», так как не понятно, что
значит «Подготовить ингредиенты». А это означает, что можно провести его декомпозицию.

10.

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

11.

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

12.

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

13.

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

14.

Для изображения диаграмм потоков данных традиционно используют два вида
нотаций: нотации Йордана и Гейна-Сарсона

15.

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

16.

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

17.

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

18.

•Каждый процесс должен сопровождаться как минимум одним входным и одним
выходным потоком;
•В каждое хранилище должен впадать как минимум один поток данных и как
минимум один — вытекать;
•Данные, хранимые в системе, должны проходить через процесс;
•Каждый процесс диаграммы DFD должен вести либо к другому процессу, либо к
хранилищу данных.
•размещать на каждой диаграмме от 3 до 6—7 процессов (аналогично IDEF0);
• не загромождать диаграммы несущественными на данном уровне деталями;
• декомпозицию потоков данных осуществлять параллельно с декомпозицией
процессов;
•выбирать ясные, отражающие суть дела, имена процессов и потоков, при этом
стараться не использовать аббревиатуры.

19.

Для облегчения восприятия процессы детализируемой подсистемы нумеруют, соблюдая
иерархию номеров: так процессы, полученные при детализации процесса или подсистемы
«1», должны нумероваться «1.1», «1.2» и т. д. Кроме этого желательно размещать на каждой
диаграмме от 3-х до 6-7-ми процессов и не загромождать диаграммы деталями, не
существенными на данном уровне.
Декомпозицию потоков данных необходимо осуществлять параллельно с декомпозицией
процессов.

20.

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

21.

ИС Ювелирная мастерская. Клиент заказывает изделие.
0 уровень
Контекстная диаграмма

22.

1-ый уровень

23.

3-ий уровень

24.

Пример 2

25.

26.

27.

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

28.

29.

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

30.

Пример 3