Стандарт IDEF0 и его применение

Из года в год сложность и объем программных средств растет. Вместе с этим возникает необходимость в создании специальной аналитической документации для возможности функционального анализа структуры и управления проектом. Для функционального моделирования на Западе разработан стандарт IDEF0 (Integrated Definition Function Modeling), который принят в качестве федерального стандарта США. Данный стандарт позволяет описывать любые бизнес-процессы. Цель данной статьи - применение данного стандарта для моделирования программных средств. Для полного понимания необходимости создания такого типа документации попробуем разобраться, какие типы документации существуют и для кого они предназначены.

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

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

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

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

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

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

На практике выделяются следующие условные уровни документирования:

1. Уровень пользователя - общее представление структуры программы (структурная схема программы), описание интерфейса (руководство пользователя), интерактивная подсказка (Help).
2. Уровень аналитика (куратора проекта) - укрупненная схема программы (функциональная модель) с четкими пояснениями взаимодействия блоков программы, назначение модулей, иерархия классов, основные функции, описание основных используемых форматов.
3. Уровень программиста - подробное описание модулей и функций программы (блок-схема алгоритма, описание используемых классов, структура используемой базы данных и т.д.).

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

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

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

В последние годы на Западе появилась солидная должность - архитектор программного обеспечения (soft architect). Это классный программист, определяющий направление развития программного проекта. На практике в роли архитектора программного обеспечения часто выступает ведущий программист. Он тоже аналитик.

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

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

Рис. 1

Механизм

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

В основе IDEF0 лежат три базовых принципа:

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

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

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

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

Рис. 2

Рис. 3

Обратимся исключительно к моделированию программных средств. Здесь описываются функции, применяемые в реализациях алгоритмических языков программирования. Входные данные - это параметры, передаваемые в функцию. Выходные данные - возвращаемый параметр. Применение глобальных данных - это либо решение проблемы ограничения количества выходных параметров, либо плохой стиль программирования. Управление - показания датчиков, средства, генерирующие прерывания и т.д. Значения параметров, считываемых из "регистра" и *.ini-файлов, являются тоже управляющими (управление). При работе с базами данных под механизмом можно понимать интерпретатор SQL СУБД.

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

При использовании стандарта IDEF0 для моделирования программных средств рано или поздно возникает следующий вопрос: чем являются управляющие данные - данными или управляющими воздействиями? Этот вопрос открыт. Возможно, необходимо левый верхний угол срезать и образовать новое направление!

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

Сергей СОКОЛОВ (БГУИР),
sokol@belcaf.minsk.by