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

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

 

Моделирование сложных систем (какими являются современные промышленные системы) было начато в программе  интегрированной автоматизации  производства (ICAM - (Integrated Computer Aided Manufacturing) Министерства обороны США в которой была признана полезность методологии SADT (Structured Analysis and Design Technique - Технология структурного анализа и проектирования) введенной в 1973 году Россом, что привело к стандартизации и публикации ее части, называемой IDEF0 (IDEF=ICAM DEFinition или Integration Definition for Function Modeling). C 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). В 2000 году – IDEF0 был принят в качестве стандарта в Российской Федерации.

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

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

 

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

 

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

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

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

Нижняя сторона имеет  значение “Ресурсы” (Mechanism).

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

 

 

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

 

Интерфейсная стрелка  «вход» (Input).

 

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

 

Интерфейсная стрелка  «управление» (Control).

 

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

 

Интерфейсная стрелка  «ресурс» (Mechanism)

 

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

 

Интерфейсная стрелка  «выход» (Output)

 

Выход – это материалы  или информация, производимая функциональным блоком из входа. Каждое действие должно иметь, по крайней мере одну интерфейсную стрелку «выход». 

 

Интерфейсные стрелки  ссылки (Call Arrow).

 

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

 

Обязательное наличие  управляющих интерфейсных стрелок  является одним из главных отличий  стандарта IDEF0 от других методологий  классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

 

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

 

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

 

Цель

 

Ни одна модель не может  быть создана без конкретного  объекта или цели. Формулировка цели должна ответить на следующие вопросы:

 

почему был смоделирован представленный процесс;

что эта модель собирается показать;

что с ней могут сделать  читающие ее.

Формулировка цели позволяет  команде экспертов придерживаться ее на протяжении всего процесса моделирования. Без формулировки цели моделирование  может зайти в тупик.

 

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

 

каковы основные задачи сотрудника;

кто отвечает за произведенную  продукцию;

кто управляет начальной  стадией производства;

какой требуется инструмент для каждого этапа.

Точка зрения (Viewpoint). 

 

Особенно важно включать в процесс разработки модели представителей различных мнений, однако сама модель должна базироваться на единой точке  зрения. Чаще всего разнообразные точки зрения кратко фиксируют на диаграмме ФЕО (англ. FEO, For Exposition Only. Русс. --- только для комментариев).

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Туннели (Tunnels).

 

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

 

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

 

 

 

 

 

 

 

ЖИЗНЕННЫЙ ЦИКЛ ИС

В основе деятельности по созданию и использованию ИТ лежит понятие ЖЦ, которое является одним из базовых понятий методологии проектирования САПР и многих других ИС. В настоящее время существует ряд общих методологий разработки ИС. Главное в них - единая дисциплина работы на всех этапах жизненного цикла системы, учет критических задач и контроль их решения, применение развитых инструментальных средств поддержки процессов анализа, проектирования и реализации ИС.

 

В общем случае под термином жизненный цикл системы ( System Life Cycle ) понимается определенная эволюция, период времени и совокупность работ, меняющих состояние системы от появления замысла и начала ее разработки до окончания эксплуатации. Обычно разбивается на отдельные стадии — анализ требований, проектирование, реализация (конструирование), верификация и эксплуатация. Стадии ЖЦ системы могут повторяться итерационным образом в связи с постепенным уточнением требований к системе и/или с необходимостью ее адаптации к тем изменениям, которые возникают в предметной области системы.

 

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

 

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

 

По стандарту ISO/IEC 12207 ЖЦ ИС базируется на трех группах процессов:

 

основные процессы ЖЦ ИС: приобретение, поставка, разработка, эксплуатация, сопровождение. Разработка ИС состоит  из трех этапов: анализ, проектирование и реализацию (программирование)

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

организационные процессы: управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение  самого ЖЦ, обучение.

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

 

Опыт создания и использования  стандартных моделей ИС позволяет  условно выделить следующие основные этапы жизненного цикла: