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

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

1.1. Обзор методов IDEF.

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

Методологии структурного анализа относятся IDEF к семейству которых относятся следующие стандарты:

            IDEF0 – методология многофункционального моделирования

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

            IDEF1x – методология построения реляционных структур (сущночть-связь, IR-диаграмма )

            IDEF2 – методология динамического моделирования, развития системы, описание динамики изменений модели

            IDEF3 – методология документирования процессов, происходящих в системе

Рекомендуемые материалы

            IDEF4 – методология построения объектно-ориентированных систем

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

1.2. Метод IDEF0.

Метод SADT (Structured Analysis and Design Technique) разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. для моделирования искусственных систем средней сложности, который в последствии вошел в основу стандарта IDEF0.

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

Основные элементы этого метода основываются на следующих концепциях:

• графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограниче­ния», которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются;

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

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

1. Функциональный блок (Activity Box)

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

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

• Верхняя сторона имеет значение “Управление” (Control);

• Левая сторона имеет значение “Вход” (Input);

• Правая сторона имеет значение “Выход” (Output);

• Нижняя сторона имеет значение “Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

2. интерфейсной дуги (Arrow)

Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

При построении IDEF0 – диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих:

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

1. материальные потоки (детали, товары, сырье и т.д.),
2. финансовые потоки (наличные и безналичные, инвестиции и т.д.),
3. потоки документов (коммерческие, финансовые и организационные документы),
4. потоки информации (информация, данные о намерениях, устные распоряжения и т.д.),
5. ресурсы (сотрудники, станки, машины и т.д.).

• Для входящих/исходящих потоков: 1, 2, 3, 4, 5.

• Для управляющих потоков: 3, 4

• Для механизмов: 5.

3. Декомпозиция (Decomposition)

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

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

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

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

Функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram).

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

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

4. Глоссарий (Glossary)

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

Этот набор называется глоссарием и является описанием сущности данного элемента.

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

Принципы ограничения сложности
IDEF0-диаграмм

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

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

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

Дисциплина групповой работы над разработкой IDEF0-модели

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

• Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

• Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким спектром компетентных лиц (в терминах IDEF0- читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает её с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.

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

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

• Что поступает в подразделение “на входе”?

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

• Кто является ответственным за выполнение каждой из функций?

• Чем руководствуется исполнитель при выполнении каждой из функций?

• Что является результатом работы подразделения (на выходе)?

В результате, за достаточно короткое время и при привлечении минимума человеческих ресурсов со стороны консультационной компании, получается IDEF0-модель предприятия по принципу “Как есть”, причем, что немаловажно, она представляет предприятие с позиции сотрудников, которые в нем работают и досконально знают все нюансы, в том числе неформальные. В дальнейшем, эта модель будет передана на анализ и обработку к бизнес-аналитикам, которые будут заниматься поиском “узких мест” в управлении компанией и оптимизацией основных процессов, трансформируя модель “Как есть” в соответствующее представление “Как должно быть”. На основании этих изменений и выносится итоговое заключение, которое содержит в себе рекомендации по реорганизации системы управления.

1.3. Метод IDEF3.

Методология моделирования процесса.

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

Единица работы (действие)

Основной компонент модели — действие, или в терминах IDEF3 «единица работы» (Unit of Work — HOW).

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

Связи

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

Соединения разбивают или соединяют внутренние потоки и используются для изображения ветвления процесса:

• разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других;

• сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения другого действия.

Типы соединений

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

Пример СОЕДИНЕНИЯ И – описание последовательности действий при обнаружении пожара

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

Соединения разбива­ют или соединяют внутренние потоки и используются для изоб­ражения ветвления процесса:

• разворачивающие соединения используются для разбиения
потока. Завершение одного действия вызывает начало вы­
полнения нескольких других;

• сворачивающие соединения объединяют потоки. Завершение
. одного или нескольких действий вызывает начало выполне­
ния другого действия.

В табл. 2.4 описаны три типа соединений.

Таблица 2.4

Типы соединений

Соединения «и» инициируют выполнение конечных действий. Все действия, присоединенные к сворачивающему соединению «и», должны завершиться, прежде чем начнется выполнение сле­дующего действия. На рис. 2.14 после обнаружения пожара иници­ируются включение пожарной сигнализации, вызов пожарной ох­раны, и начинается тушение пожара. Запись в журнал производит­ся только тогда, когда все три перечисленных действия завершены.

1.4. Метод IDEF1.

Моделирования информационных потоков

DFD – диаграмма потоков данных.

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

общий вид диаграммы потоков данных называется – контекстная диаграмма и состоит из одной системы и внешних сущностей.

Лекция "5.1. Краткая характеристика источников воды" также может быть Вам полезна.

Система и подсистема:

Процесс:

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

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