Инструменты для графического представления функциональных блоков

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

Сравнительно недавно разработан комплексный метод функционального моделирования (Integration DEFinition - IDEF). На самом деле этот метод выходит за рамки моделирования лишь функционирования системы, но охватывает целый спектр описаний возможностей системы. Метод функционального моделирования IDEF0 - это основная техника, применяемая для описания функционирования системы. Базовой конструкцией является функциональный блок, изображаемый в виде прямоугольника, нарисованного сплошными линиями (рис. 8.3). Существуют строгие правила обозначения интерфейсов, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой. Иногда внутри прямоугольника помещаются детали, например список функций, выполняемых данным объектом, а иногда прямоугольник оставляют пустым. Входы всегда рисуются слева от прямоугольника, выходы - справа. Управляющие сигналы (помимо входов) рисуются сверху от функционального блока, а вход механизмов (или реализации) - снизу[1].

Один из простейших методов построения графических схем - это функциональная блок-схема (Functional Block Diagram - FBD). Она похожа, с одной стороны, на FFBD, но без структуры потоков, а с другой - на IDEF0, но без правил изображения схем. По существу, каждая функция отображается прямоугольником. Интерфейсы между функциями обозначаются направленными стрелками с метками, в которых описывается, что передается от одной функции другой. Если имеется интерфейс между функцией и внешним объектом, то этот объект тоже как-то представляется (например, прямоугольник и окружность) и наносится интерфейсная стрелка.

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

Функции ввода

  • 1. Принять команду пользователя (вкл/выкл).
  • 2. Получить материалы для приготовления кофе.
  • 3. Подать электричество.
  • 4. Подать воду.

Функции трансформации

  • 5. Нагреть воду.
  • 6. Смешать горячую воду с молотым кофе.
  • 7. Отфильтровать кофейную гущу.
  • 8. Сохранить горячим сваренный кофе.

Функции вывода

  • 9. Показать состояние.
  • 10. Обеспечить удаление материалов.
  • 11. Отвести тепло.

На рис. 8.4 представлена FBD для всех 11 функций. Показаны также внешние объекты: пользователь, источник энергии (предполагается электрическая розетка) и окружение. Отметим, что ни в списке функций, ни на схеме техническое обслуживание не рассматривается. Объясняется это природой бытовых приборов вообще и кофеварок в частности. В их конструкции ремонт не предусмотрен, они «одноразовые».

Поскольку трудно избежать пересечения линий, существует несколько способов отличить разные интерфейсные стрелки. Самым распространенным, пожалуй, является цвет, но применяются и другие, например пунктирные линии. В случае энергии мы просто перечислили нуждающиеся в ней функции (к примеру, «F5»). Мы старались рисовать достаточно тщательно, чтобы читателю было

273

,3Структура функциональной модели IDEF0

Рис., 8,3Структура функциональной модели IDEF0

Анализ функционирования и определение функциональных требований легче осмыслить процесс идентификации функций и разработки функциональной структуры системы. Было бы нетрудно упростить эту схему, поскольку на данной стадии несколько функций можно опустить, при условии, что впоследствии мы о них не забудем. Например, функцию 10 «обеспечить удаление материалов» вполне можно пока убрать, лишь бы в окончательном проекте возможность удаления отходов присутствовала. Отметим также, что функции можно разбить на категории по признаку работы с пятью базовыми элементами:

Материалы

Получить материалы для приготовления кофе Смешать горячую воду с молотым кофе Отфильтровать кофейную гущу Обеспечить удаление материалов

Данные

Показать состояние

Сигналы

Принять команду пользователя

Энергия

Подать электричество Нагреть воду

Сохранить горячим сваренный кофе Отвести тепло

Сила

Распределить вес

Это не «чистое» разбиение, потому что некоторые функции принимают на входе элемент одного типа и преобразуют его в элемент другого типа. Например, функция 2 «принять команду пользователя» получает на входе данные и преобразует их в сигналы. Приходится принимать субъективное решение.

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

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

,4. Функциональная блок-схема стандартной кофеварки

Рис. 8,4. Функциональная блок-схема стандартной кофеварки

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

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

  • [1] Описание комплекса средств для наглядного представления широкого спектра деловых, производственных идругих процессов и операций на любом уровне детализации, а также организационные и методические приемыприменения этих средств можно найти в Рекомендациях по стандартизации Р 50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования». -Прим. реп.
 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ ОРИГИНАЛ   След >