Практикум по применению IDEF0 для функционального описания программного обеспечения
Практикум по применению IDEF0 для функционального описания программного обеспечения 
Часть 2.
Средства автоматизации построения IDEF0-диаграмм. Специализированным средством создания IDEF0-диаграмм является BPWin (www.logicworks.com). Это лучшее средство в своем классе. Особенностью BPWin является возможность установки на диаграмме до 8 блоков. Существует возможность создания депозитария (словаря) как блоков, так и стрелок.
Аналогичную операцию может осуществлять Visio. В попытке создания универсального продукта, осуществляющего построение документации, его создатели не позаботились о специфических для IDEF0-диаграмм вспомогательных функциях.
Построение IDEF0-диаграмм можно осуществлять в Word при помощи графических примитивов или в любом графическом редакторе, например, Paint, входящем в состав Windows. Насколько это удобно?
Описание программного обеспечения (ПО) с применением стандарта IDEF0. Важность проблемы. Стандарт IDEF0 создан для возможности описания проектов любой сложности и ориентации. При помощи его можно описать проекты по созданию ПО. Это частное применение стандарта IDEF0.
Индустрия разработки ПО до сих пор не имеет универсального стандарта на разработку документации, способного описывать все более быстро появляющиеся технологии программирования. На данный момент существуют только блок-схема алгоритма и структурная схема программы (ПО), которые воспринимаются как общепринятый стандарт. Блок-схема алгоритма очень эффективна при описании процесса вычисления с применением множества условных конструкций, но крайне неэффективна при последовательно выполняющихся действиях (сводится к детализированной структурной схеме программы).
Многие проекты создаются большими коллективами программистов на протяжении многих лет, присутствует текучесть кадров. Поэтому наличие качественного описания наиболее актуально. Многие проекты забрасываются из-за отсутствия качественной документации на созданное ПО. Без документации доработка ПО не возможна. Без доработки ПО морально стареет и заменяется более новым.
Вторая не менее серьезная проблема заключается в эффективном управлении отдельными частями проектов. Без него каждая рабочая группа создает свою часть работы без учета частей проектов, разрабатываемых остальными рабочими группами. Документация, созданная в стандарте IDEF0, позволяет взглянуть на проект в целом и детально определить взаимосвязи между его отдельными частями.
Применение IDEF0 на практике позволяет уйти от словесного описания структуры и принципов функционирования ПО. Словесное описание в основном применяется для функционирования программных проектов.
Определение диаграммы-контекста (ДК). На первых этапах практического применения IDEF0 наибольшую сложность представляет определение именно этой диаграммы (при проектировании от общего к частному - выбор ДК и последовательная ее декомпозиция).
Разработчики IDEF0-диаграмм часто оказываются заложниками слова "функции" в контексте его применения. Необходимо четко понимать: описывается само действие (функция) или описываются действия, которые необходимо совершить пользователю для достижения цели (функции пользователя).
Важно правильно определить начальный уровень моделирования функций. От правильности выбора начального уровня описания зависит степень абстракции и детализации источников и приемников данных.
Часто программу или группу программ (пакет) можно рассматривать как глобальную функцию. В зависимости от типа проекта можно выделить следующие начальные уровни моделирования:
1. Уровень пакета. ДК - пакет, декомпозируется на программы. Источники данных - базы данных, серверы, файлы, сетевые ресурсы, сканеры. Приемники - базы данных, серверы, файлы, сетевые ресурсы, принтеры. Механизмы - форматы, технологии. Управление - датчики, пользователи, компьютеры и ПО.
2. Уровень программы. ДК - программа, декомпозируется на модули, классы и формы. Источники и приемники данных, механизмы и управление те же, что и у пакета.
3. Уровень класса или формы. ДК - пакет, декомпозируется на функции. Здесь четко конкретизируются источники данных - таблицы баз данных, элементы интерфейса (компоненты). Приемники - таблицы баз данных, элементы интерфейса. Добавляется структура глобальных данных - глобальные декларации переменных. Механизмы - триггеры баз данных, алгоритмы. Управление - события операционной системы.
4. Уровень функции. ДК - пакет, декомпозируется на подфункции (группы операторов). Добавляется структура локальных данных функции - локальные декларации данных.
Процесс построения ДК и подход к дальнейшей декомпозиции очень похожи для первых трех уровней. Меняется лишь степень детализации потоков данных.
Не менее важно корректно сформулировать название этой диаграммы. При выборе названия диаграммы необходимо помнить, что описывается функция. Название любого блока диаграммы содержит ключевой глагол, определяющий характер действия, выполняемого функцией (вычислить, удалить, открыть, сохранить...). Если в названиях блоков появятся существительные, вы придете к структурной схеме программы, а не к описанию функции (действия). Эта ошибка при проектировании приводит к неправильному пониманию назначения самих IDEF0-диаграмм.
Из ДК должны быть четко видны источники данных, приемники, механизмы реализации обработки данных и задействованные элементы управления.
Нет нужды в чрезмерной детализации потоков. Это может быть сделано на диаграммах нижнего уровня.
Нет нужды приводить в качестве источника данных клавиатуру и мышь, а в качестве приемника данных - монитор.
Декомпозиция. Декомпозиция делит диаграмму на логически законченные действия (функции). Действия (функции) оформляются в виде блоков.
По стандарту IDEF0 любая диаграмма может быть декомпозирована на 2...6 блоков. Если желаемое количество блоков больше шести? Эта проблема появляется при описании пунктов меню. Обычно в меню содержатся десятки пунктов (в очень небольшой программе). Имеет смысл выделить описания таких функций в отдельные диаграммы. В принципе, допустимо в ряде случаев увеличение количества блоков на диаграмме, но не рекомендуется. Происходит нарушение одного из положений стандарта. Как только пропадает чистота линии, все описание сводится к самопальному формату. Разве стандарт IDEF0 не был создан, чтобы устранить такие описания?
Возникает правомерный вопрос: до какой степени необходимо осуществлять декомпозицию? - Пока выполняется принцип достаточности. Описываются только основные функции проекта. Необходимо четко понимать, что описать все функции в проекте невозможно или нецелесообразно. Это особенно сложно при использовании нескольких обработчиков событий у визуальных компонент. Каждое событие обрабатывается отдельной функцией...
При проектировании от частного к общему лучше всего начать процесс декомпозиции с создания депозитария. Перед началом проектирования заранее известны некоторые основные (промежуточные) функции, которые необходимо описать. С них надо начинать процесс формирования депозитария. Названия функций не должны повторяться.
При попытке детального описания последовательности действий и условий их выполнения задайтесь вопросом: может, вы пытаетесь описать алгоритм? Стандарт IDEF0 для описания алгоритма не предназначен. IDEF0-диаграммы описывают действия, его структуру и связи между его отдельными элементами.
При декомпозиции на нижних уровнях декомпозиции можно дойти до конкретных функций, применяемых в описываемых программах. К этому необходимо стремиться. При дальнейшей декомпозиции будет осуществляться описание "содержимого" функций.
Роль и место IDEF0-диаграммы в описании программного обеспечения. Функциональное описание приходится плотно увязывать с описанием интерфейса ПО и структурной схемой ПО.
Большинство функций ПО для Windows связано напрямую с элементами интерфейса, т.к. вызываются обработчиками событий визуальных компонент. Описание таких функций невозможно без описания интерфейса.
Структурная схема программы позволяет осуществлять описание структуры форм и модулей ПО, что невозможно сделать при помощи IDEF0-диаграмм.
Рано или поздно возникает момент, когда очередной блок диаграммы не удается декомпозировать, но его непременно необходимо описать. В этот момент стоит задуматься о существовании блок-схемы алгоритма. В блоки на диаграмме выделяются более значительные элементы, чем оператор. Блок-схема алгоритма предназначена для последовательного описания выполняемых операторов.
Блок-схема алгоритма оказывается более эффективной, чем IDEF0-диаграмм, т.к. позволяет более детально описать взаимодействие блоков (функций) по совершению действий. Блок-схема позволяет более четко описать правила выбора действия, цикличность действий, принципы разделения данных и их объединение. Это именно та ниша в практическом применении блок-схемы алгоритма при описании ПО. В данном случае блок-схема оказывается более эффективной, чем словесное описание алгоритма.
IDEF0 выступает мостом между визуальным описанием ПО, структурной схемой программы и блок-схемой алгоритма. Внешне упрощенная диаграмма связей изображена на рис.3. Сергей Соколов (Минск, БГУИР) E-Mail: sokol@belcaf.minsk.by (c) компьютерная газета
Средства автоматизации построения IDEF0-диаграмм. Специализированным средством создания IDEF0-диаграмм является BPWin (www.logicworks.com). Это лучшее средство в своем классе. Особенностью BPWin является возможность установки на диаграмме до 8 блоков. Существует возможность создания депозитария (словаря) как блоков, так и стрелок.
Аналогичную операцию может осуществлять Visio. В попытке создания универсального продукта, осуществляющего построение документации, его создатели не позаботились о специфических для IDEF0-диаграмм вспомогательных функциях.
Построение IDEF0-диаграмм можно осуществлять в Word при помощи графических примитивов или в любом графическом редакторе, например, Paint, входящем в состав Windows. Насколько это удобно?
Описание программного обеспечения (ПО) с применением стандарта IDEF0. Важность проблемы. Стандарт IDEF0 создан для возможности описания проектов любой сложности и ориентации. При помощи его можно описать проекты по созданию ПО. Это частное применение стандарта IDEF0.
Индустрия разработки ПО до сих пор не имеет универсального стандарта на разработку документации, способного описывать все более быстро появляющиеся технологии программирования. На данный момент существуют только блок-схема алгоритма и структурная схема программы (ПО), которые воспринимаются как общепринятый стандарт. Блок-схема алгоритма очень эффективна при описании процесса вычисления с применением множества условных конструкций, но крайне неэффективна при последовательно выполняющихся действиях (сводится к детализированной структурной схеме программы).
Многие проекты создаются большими коллективами программистов на протяжении многих лет, присутствует текучесть кадров. Поэтому наличие качественного описания наиболее актуально. Многие проекты забрасываются из-за отсутствия качественной документации на созданное ПО. Без документации доработка ПО не возможна. Без доработки ПО морально стареет и заменяется более новым.
Вторая не менее серьезная проблема заключается в эффективном управлении отдельными частями проектов. Без него каждая рабочая группа создает свою часть работы без учета частей проектов, разрабатываемых остальными рабочими группами. Документация, созданная в стандарте IDEF0, позволяет взглянуть на проект в целом и детально определить взаимосвязи между его отдельными частями.
Применение IDEF0 на практике позволяет уйти от словесного описания структуры и принципов функционирования ПО. Словесное описание в основном применяется для функционирования программных проектов.
Определение диаграммы-контекста (ДК). На первых этапах практического применения IDEF0 наибольшую сложность представляет определение именно этой диаграммы (при проектировании от общего к частному - выбор ДК и последовательная ее декомпозиция).
Разработчики IDEF0-диаграмм часто оказываются заложниками слова "функции" в контексте его применения. Необходимо четко понимать: описывается само действие (функция) или описываются действия, которые необходимо совершить пользователю для достижения цели (функции пользователя).
Важно правильно определить начальный уровень моделирования функций. От правильности выбора начального уровня описания зависит степень абстракции и детализации источников и приемников данных.
Часто программу или группу программ (пакет) можно рассматривать как глобальную функцию. В зависимости от типа проекта можно выделить следующие начальные уровни моделирования:
1. Уровень пакета. ДК - пакет, декомпозируется на программы. Источники данных - базы данных, серверы, файлы, сетевые ресурсы, сканеры. Приемники - базы данных, серверы, файлы, сетевые ресурсы, принтеры. Механизмы - форматы, технологии. Управление - датчики, пользователи, компьютеры и ПО.
2. Уровень программы. ДК - программа, декомпозируется на модули, классы и формы. Источники и приемники данных, механизмы и управление те же, что и у пакета.
3. Уровень класса или формы. ДК - пакет, декомпозируется на функции. Здесь четко конкретизируются источники данных - таблицы баз данных, элементы интерфейса (компоненты). Приемники - таблицы баз данных, элементы интерфейса. Добавляется структура глобальных данных - глобальные декларации переменных. Механизмы - триггеры баз данных, алгоритмы. Управление - события операционной системы.
4. Уровень функции. ДК - пакет, декомпозируется на подфункции (группы операторов). Добавляется структура локальных данных функции - локальные декларации данных.
Процесс построения ДК и подход к дальнейшей декомпозиции очень похожи для первых трех уровней. Меняется лишь степень детализации потоков данных.
Не менее важно корректно сформулировать название этой диаграммы. При выборе названия диаграммы необходимо помнить, что описывается функция. Название любого блока диаграммы содержит ключевой глагол, определяющий характер действия, выполняемого функцией (вычислить, удалить, открыть, сохранить...). Если в названиях блоков появятся существительные, вы придете к структурной схеме программы, а не к описанию функции (действия). Эта ошибка при проектировании приводит к неправильному пониманию назначения самих IDEF0-диаграмм.
Из ДК должны быть четко видны источники данных, приемники, механизмы реализации обработки данных и задействованные элементы управления.
Нет нужды в чрезмерной детализации потоков. Это может быть сделано на диаграммах нижнего уровня.
Нет нужды приводить в качестве источника данных клавиатуру и мышь, а в качестве приемника данных - монитор.
Декомпозиция. Декомпозиция делит диаграмму на логически законченные действия (функции). Действия (функции) оформляются в виде блоков.
По стандарту IDEF0 любая диаграмма может быть декомпозирована на 2...6 блоков. Если желаемое количество блоков больше шести? Эта проблема появляется при описании пунктов меню. Обычно в меню содержатся десятки пунктов (в очень небольшой программе). Имеет смысл выделить описания таких функций в отдельные диаграммы. В принципе, допустимо в ряде случаев увеличение количества блоков на диаграмме, но не рекомендуется. Происходит нарушение одного из положений стандарта. Как только пропадает чистота линии, все описание сводится к самопальному формату. Разве стандарт IDEF0 не был создан, чтобы устранить такие описания?
Возникает правомерный вопрос: до какой степени необходимо осуществлять декомпозицию? - Пока выполняется принцип достаточности. Описываются только основные функции проекта. Необходимо четко понимать, что описать все функции в проекте невозможно или нецелесообразно. Это особенно сложно при использовании нескольких обработчиков событий у визуальных компонент. Каждое событие обрабатывается отдельной функцией...
При проектировании от частного к общему лучше всего начать процесс декомпозиции с создания депозитария. Перед началом проектирования заранее известны некоторые основные (промежуточные) функции, которые необходимо описать. С них надо начинать процесс формирования депозитария. Названия функций не должны повторяться.
При попытке детального описания последовательности действий и условий их выполнения задайтесь вопросом: может, вы пытаетесь описать алгоритм? Стандарт IDEF0 для описания алгоритма не предназначен. IDEF0-диаграммы описывают действия, его структуру и связи между его отдельными элементами.
При декомпозиции на нижних уровнях декомпозиции можно дойти до конкретных функций, применяемых в описываемых программах. К этому необходимо стремиться. При дальнейшей декомпозиции будет осуществляться описание "содержимого" функций.
Роль и место IDEF0-диаграммы в описании программного обеспечения. Функциональное описание приходится плотно увязывать с описанием интерфейса ПО и структурной схемой ПО.
Большинство функций ПО для Windows связано напрямую с элементами интерфейса, т.к. вызываются обработчиками событий визуальных компонент. Описание таких функций невозможно без описания интерфейса.
Структурная схема программы позволяет осуществлять описание структуры форм и модулей ПО, что невозможно сделать при помощи IDEF0-диаграмм.
Рано или поздно возникает момент, когда очередной блок диаграммы не удается декомпозировать, но его непременно необходимо описать. В этот момент стоит задуматься о существовании блок-схемы алгоритма. В блоки на диаграмме выделяются более значительные элементы, чем оператор. Блок-схема алгоритма предназначена для последовательного описания выполняемых операторов.
Блок-схема алгоритма оказывается более эффективной, чем IDEF0-диаграмм, т.к. позволяет более детально описать взаимодействие блоков (функций) по совершению действий. Блок-схема позволяет более четко описать правила выбора действия, цикличность действий, принципы разделения данных и их объединение. Это именно та ниша в практическом применении блок-схемы алгоритма при описании ПО. В данном случае блок-схема оказывается более эффективной, чем словесное описание алгоритма.
IDEF0 выступает мостом между визуальным описанием ПО, структурной схемой программы и блок-схемой алгоритма. Внешне упрощенная диаграмма связей изображена на рис.3. Сергей Соколов (Минск, БГУИР) E-Mail: sokol@belcaf.minsk.by (c) компьютерная газета
Компьютерная газета. Статья была опубликована в номере 41 за 2000 год в рубрике разное :: страна советов
