Методология IDEF0 и её применение для функционального описания программного обеспечения

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

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

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

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

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

В-третьих, это улучшенная передача информации. В IDEF существует ряд средств, разработанных специально для улучшения передачи информации:

v · диаграммы, основанные на очень простой графике блоков и дуг;

v · метки на естественном языке для описания блоков и дуг, а также глоссарий и сопроводительный текст для определения точного значения элементов диаграммы;

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

v · схема узлов в иерархии диаграмм, обеспечивающая возможность легко составить перечень (индекс) размещенных на них деталей;

v · ограничение каждой диаграммы шестью подфункциями для облегчения чтения.

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

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

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

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

Основу методологии IDEF0 составляет графический язык описания бизнес- процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной структуры, представляющая собой самое общее описание системы и ее взаимодействия с внешней средой, называется контекстной диаграммой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области указывают на соответствие реальных бизнес - процессов созданным диаграммам. Найденные несоответствия исправляются и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Таким образом достигается соответствие модели реальным бизнес - процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели. Работы (Activity), которые означают некие поименованные процессы, функции или задачи, изображаются в виде прямоугольников. Именем работы должен быть глагол или глагольная форма (например "Изготовление детали", "Прием заказа" и т.д.). Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, "Заготовка", "Изделие", "Заказ"). В IDEF0 различают пять типов стрелок:

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

· Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления.

· Выход (Output) - материал или информация, которая производится работой. Каждая работа должна иметь хотя бы одну стрелку выхода.

· Механизм (Mechanism)- ресурсы, которые выполняют работу, например, персонал предприятия станки, механизмы и т.д.

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

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

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

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