Функциональный блок
Функциональный блок изображается прямоугольником, стороны которого имеют следующие значения:
-
Верхняя сторона – управление.
-
Нижняя сторона – механизм.
-
Правая сторона – выход
-
Левая сторона – вход.
Функциональный блок имеет имя, которое задается в глагольном наклонении. В общем виде функциональный блок показан на рис.8.1.
Вход (материал
или информация)
Имя действия
(Контекстная функция)
Управление
(правила, регламенты, стратегии,
процедуры, стандарты)
Выход (материал
или информация)
Механизм (ресурсы:
персонал, подразделения станки,
устройства,)
Рис.8.1. Функциональный блок
Взаимодействие между действием и окружающим его миром, в том числе и с другими действиями, отображается с помощью интерфейсных дуг (стрелок).
Интерфейсная дуга – это стрелка с именем, которая указывает
-
Вход функционального блока.
-
Выход функционального блока.
-
Управление.
-
Механизм.
На рис.8.1, показаны все интерфейсные дуги в виде поименованных стрелок. По требованиям стандарта каждый функциональный блок должен иметь по крайней мере один выход и одно управление, так как каждая задача (процесс) должны иметь хотя бы один выход и хотя бы одно правило ее решения.
Функциональная модель
Из нескольких функциональных блоков, соединенных интерфейсными дугами (стрелками) требуемым образом, строится функциональная модель (Рис.8.2).
Следует обратить внимание на то, что стрелки могут разветвляться, осуществляя требуемые соединения функциональных блоков. Входом функционального блока может быть не только выход другого функционального блока, но и его управление или даже механизм. В результате в функциональной модели могут быть различные, достаточно сложные и необычные процессы решения задач в информационной системе.
Рис. 8.2 Функциональная модель
IDEF0 использует принцип функциональной декомпозиции систем (разбиение системы на фрагменты). Принцип декомпозиции означает, что функциональную модель следует строить по правилу «сверху вниз», от общего модели вида к частным моделям.
Этапы составления модели:
-
Определение контекста.
Контекст – наиболее абстрактный уровень описания системы в целом, в который входит определение области моделирования (Scope). Определение области моделирования подразумевает описание:
-
субъекта моделирования (субъект – сама система), в процессе описания которого устанавливается:
-
что входит в систему (является ее компонентами),
-
что лежит за ее пределами (является внешним воздействием).
-
цели моделирования (Purpose – закладка Purpose меню Edit/Model Properties), которая должна отвечать на следующие вопросы:
-
почему этот процесс должен быть замоделирован?
-
Что должна показывать модель?
-
Что может получить читатель?
Примеры: а) «Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений»,
б) Идентифицировать роли и ответственность служащих для написания должностных инструкций,
в) описать функциональность предприятия с целью написания спецификаций ИС и т.д.
-
точки зрения (Viewpoint - закладка Purpose меню Edit/Model Properties) на модель.
Точка зрения – перспектива, с которой наблюдалась система при построении модели (Черемных) или иначе – это взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно точки зрения, например, финансиста и технолога различны и поэтому выбирается точка зрения человека, ответственного за систему в целом, например руководителя предприятия.
-
Источников информации для построения модели (Source)
Пример: «Опрос экспертов предметной области и анализ документации».
-
Статуса модели: черновой вариант, рабочий, окончательный и т.д.
-
Временных рамок (AS-IS или TO-BE)
Вначале создается модель, на которой можно определить слабые места предприятия, например бесполезные, дублирующие и неуправляемые работы, неэффективный документооборот (нет нужных документов на нужном месте в нужное время), отсутствие обратной связи по управлению (нет результата) или по входу (информация используется нерационально).
AS-IS - «что мы делаем сегодня», перед тем как перепрыгнуть на то, «что мы будем делать завтра». Неверно, если создается идеализированная модель (например, на основе знаний руководителя, а не конкретного исполнителя), такая модель называется SHOULD BE (как должно бы быть).
После анализа модели AS-IS и улучшения бизнес-процессов, создается модель TO-BE, и только на основе модели TO-BE строится впоследствии модель данных, прототип, а затем окончательный вариант ИС