Р 50.1.028-2001

Информационные технологии поддержки жизненного цикла продукции

МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ

Continuous acquisition and life-cycle support.

Methodology of functional modelling

ОКС 25.040.40

Дата введения 2002-07-01

Предисловие

1 РАЗРАБОТАНЫ Научно-исследовательским Центром CALS-технологий "Прикладная Логистика" при участии Всероссийского научно-исследовательского института стандартизации (ВНИИстандарт)

ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 431 "CALS-технологии"

3 ВВЕДЕНЫ ВПЕРВЫЕ

Введение

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

В США в конце 70-х годов была предложена и реализована Программа интегрированной компьютеризации производства ICAM (Integrated Computer Aided Manufacturing), направленная на увеличение эффективности промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий.

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

IDEF0 используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, преобразуемые этими функциями;

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

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

К настоящему времени наибольшее распространение и применение имеют методологии IDEF0 и IDEF1 (IDEF1X).

Методология IDEF0, особенности и приемы применения которой описываются в настоящих рекомендациях, основана на подходе, получившем название SADT (Structured Analysis & Design Technique - метод структурного анализа и проектирования). Основу этого подхода и методологии IDEF0 составляет графический язык описания (моделирования) систем.

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

1 Область применения

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

2.1 блок: Прямоугольник, содержащий имя и номер и используемый для описания функции.

2.2 ветвление: Разделение стрелки на два или большее число сегментов. Может означать "развязывание пучка" (см. 2.27).

2.3 внутренняя стрелка: Входная, управляющая или выходная стрелка, концы которой связывают источник и потребителя, являющиеся блоками одной диаграммы. Отличается от граничной стрелки.

2.4 входная стрелка: Класс стрелок, отображающих вход IDEF0-блока, то есть данные или материальные объекты, которые преобразуются функцией в выход. Входные стрелки связываются с левой стороной блока IDEF0.

2.5 выходная стрелка: Класс стрелок, отображающих выход IDEF0-блока, то есть данные или материальные объекты, произведенные функцией. Выходные стрелки связываются с правой стороной блока IDEF0.

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

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

2.9 дерево узлов: Представление отношений между родительскими и дочерними узлами модели IDEF0 в форме древовидного графа. Имеет то же значение и содержание, что и перечень узлов (см. 2.23).

2.10 диаграмма А-0 (А минус ноль): Специальный вид (контекстной) диаграммы IDEF0, состоящей из одного блока, описывающего функцию верхнего уровня, ее входы, выходы, управление, и механизмы, вместе с формулировками цели модели и точки зрения, с которой строится модель.

2.11 диаграмма: Часть модели, описывающая декомпозицию блока.

2.12 диаграмма-иллюстрация (FEO): Графическое описание, используемое для сообщения специфических фактов о диаграмме IDEF0. При построении диаграмм FEO можно не придерживаться правил IDEF0.

2.13 дочерний блок: Блок на дочерней (порожденной) диаграмме.

2.14 дочерняя диаграмма: Диаграмма, детализирующая родительский (порождающий) блок.

2.15 имя блока: Глагол или глагольный оборот, помещенный внутри блока и описывающий моделируемую функцию.

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

2.17 код ICOM (аббревиатура Input - вход, Control - управление, Output - выход, Mechanism - механизм): Код, обеспечивающий соответствие граничных стрелок дочерней диаграммы со стрелками родительского блока; используется для ссылок.

2.18 контекст: Окружающая среда, в которой действует функция (или комплект функций на диаграмме).

2.19 контекстная диаграмма: Диаграмма, имеющая узловой номер А- (А минус ) (), которая представляет контекст модели. Диаграмма А-0, состоящая из одного блока, является необходимой (обязательной) контекстной диаграммой; диаграммы с узловыми номерами А-1, А-2, (А минус 1, А минус 2)+, - дополнительные контекстные диаграммы.

2.20 метка стрелки: Существительное или оборот существительного, связанные со стрелкой или сегментом стрелки и определяющие их значение.

2.21 модель IDEF0: Графическое описание системы, разработанное с определенной целью (см. 2.46) и с выбранной точки зрения (см. 2.39). Комплект документов IDEF0, которые изображают функции системы с помощью графики (диаграмм), текста и глоссария.

2.22 номер блока: Число (0-6), помещаемое в правом нижнем углу блока и однозначно идентифицирующее блок на диаграмме.

2.23 перечень узлов: Список, часто ступенчатый, показывающий узлы модели IDEF0 в упорядоченном виде. Имеет то же значение и содержание, что и дерево узлов (см. 2.9).

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

2.25 родительская диаграмма: Диаграмма, которая содержит родительский блок.

2.26 родительский блок: Блок, который подробно описывается дочерней диаграммой.

2.27 связывание/развязывание: Объединение значений стрелок в составное значение (связывание в "пучок"), или разделение значений стрелок (развязывание "пучка"), выраженные синтаксисом слияния или ветвления стрелок.

2.28 сегмент стрелки: Сегмент линии, который начинается или заканчивается на стороне блока, в точке ветвления или слияния, или на границе (несвязанный конец стрелки).

2.29 семантика: Значение синтаксических компонентов языка.

2.30 синтаксис: Структурные компоненты или характеристики языка и правила, которые определяют отношения между ними.

2.31 слияние: Объединение двух или большего числа сегментов стрелок в один сегмент. Может означать "связывание пучка" (см. 2.27).

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

2.33 стрелка: Направленная линия, состоящая из одного или нескольких сегментов, которая моделирует открытый канал или канал, передающий данные или материальные объекты от источника (начальная точка стрелки), к потребителю (конечная точка с "наконечником"). Имеется четыре класса стрелок: входная, выходная, управляющая стрелка механизма (включает стрелку вызова). (См. сегмент стрелки, граничная стрелка, внутренняя стрелка).

2.34 стрелка вызова: Вид стрелки механизма, который обозначает обращение из блока данной модели (или части модели) к блоку другой модели (или другой части той же модели) и обеспечивает связь между моделями или между разными частями одной модели.

2.35 стрелка механизма: Класс стрелок, которые отображают механизмы IDEF0, то есть средства, используемые для выполнения функции; включает специальный случай стрелки вызова. Стрелки механизмов связываются с нижней стороной блока IDEF0.

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

2.37 текст: Любой текстовый (не графический) комментарий к графической диаграмме IDEF0.

2.38 тильда: Небольшая ломаная (волнистая) линия, используемая для соединения метки с конкретным сегментом стрелки или примечания модели с компонентом диаграммы.

2.39 точка зрения: Указание на должностное лицо или подразделение организации, с позиции которого разрабатывается модель. Для каждой модели точка зрения единственная.

2.40 узел: Блок, порождающий дочерние блоки; родительский блок. (См. перечень узлов, дерево узлов, узловой номер, узловая ссылка, номер узла диаграммы).

2.42 узловой номер диаграммы: Часть узловой ссылки диаграммы, которая соответствует номеру родительского блока.

2.43 узловой номер: Код, присвоенный блоку и определяющий его положение в иерархии модели; может быть использован в качестве подробного ссылочного выражения.

2.44 управляющая стрелка: Класс стрелок, которые в IDEF0 отображают управления, то есть условия, при выполнении которых выход блока будет правильным. Данные или объекты, моделируемые как управления, могут преобразовываться функцией, создающей соответствующий выход. Управляющие стрелки связываются с верхней стороной блока IDEF0.

2.45 функция: Деятельность, процесс или преобразование (моделируемые блоком IDEF0), идентифицируемое глаголом или глагольной формой, которая описывает, что должно быть выполнено.

2.46 цель: Краткая формулировка причины создания модели.

3 Сокращения

ICAM - интегрированная компьютеризация производства.

ICOM - вход (Input), управление (Control), выход (Output), механизм (Mechanism).

IDEF0 - методология, используемая для создания функциональной модели.

IDEF1 - методология, используемая для создания информационной модели.

IDEF2 - методология, используемая для создания динамической модели.

FEO - диаграмма-иллюстрация.

4 Концепция IDEF0

Методология IDEF0 основана на следующих концептуальных положениях.

4.1 Модель - искусственный объект, представляющий собой отображение (образ) системы и ее компонентов. Считается, что

М моделирует А, если М отвечает на вопросы относительно А.

Здесь М - модель, А - моделируемый объект (оригинал). Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или замене существующей, либо проектировании новой системы. Система представляет собой совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу. Частями (элементами) системы могут быть любые комбинации разнообразных сущностей, включающие людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергию (энергоносители). Модель описывает, что происходит в системе, как ею управляют, что она преобразует, какие средства использует для выполнения своих функций и что производит.

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

4.3 Лаконичность и точность. Документация, описывающая систему, должна быть точной и лаконичной. Сведения о свойствах и характеристиках системы в форме традиционных текстов в этом смысле неудовлетворительны, поскольку зачастую содержат избыточную информацию, допускают неоднозначное толкование и т.д. Графический язык позволяет лаконично, однозначно и точно показать все элементы (блоки) системы и все отношения и связи между ними, выявить ошибочные, лишние или дублирующие связи и т.д.

4.4 Передача информации. Средства IDEF0 облегчают передачу информации от одного участника разработки модели (отдельного разработчика или рабочей группы) к другому. К числу таких средств относятся:

Диаграммы, основанные на простой графике блоков и стрелок, легко читаемые и понимаемые;

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

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

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

4.5 Строгость и формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. Эти правила описываются ниже. Здесь отмечается только основное из них: на всех стадиях и этапах разработки и корректировки модели должны строго, формально соблюдаться синтаксические и семантические правила графического языка, а результаты - тщательно документироваться с тем, чтобы при ее эксплуатации не возникало вопросов, связанных с неполнотой или некорректностью документации. Программный продукт Design/IDEF 3.7 (и более поздние версии) фирмы Meta Software Corporation поддерживает автоматическое соблюдение большинства из перечисленных правил.

4.6 Итеративное моделирование. Разработка модели в IDEF0 представляет собой пошаговую, итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов - экспертов в предметной области, к которой относится объект моделирования.

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

5 Синтаксис графического языка IDEF0

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

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

Рисунок 1

5.2 Стрелка

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

Рисунок 2

5.3 Синтаксические правила

5.3.1 Блоки

Для блоков установлены следующие синтаксические правила:

Размеры блоков должны быть достаточными для того, чтобы включить имя и номер блока;

Блоки должны быть прямоугольными, с прямыми углами;

Блоки должны быть нарисованы сплошными линиями.

5.3.2 Стрелки

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

Ломаные стрелки изменяют направление только под углом 90°;

Стрелки должны быть нарисованы сплошными линиями. Можно использовать линии различной толщины;

Стрелки могут состоять только из вертикальных или горизонтальных отрезков; отрезки, направленные по диагонали, не допускаются;

Концы стрелок должны касаться внешней границы функционального блока, но не должны пересекать ее;

Стрелки должны присоединяться к блоку на его сторонах. Присоединение в углах не допускается.

6 Семантика языка IDEF0

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

6.1 Семантика блоков и стрелок

Поскольку IDEF0 есть методология функционального моделирования, имя блока, описывающее функцию, должно быть глаголом или глагольным оборотом. Например, имя блока "Выполнить проверку" означает, что блок с таким именем превращает непроверенные детали в проверенные. После присваивания блоку имени, к соответствующим его сторонам присоединяются входные, выходные и управляющие стрелки, а также стрелки механизма, что и определяет наглядность и выразительность изображения блока IDEF0 (см. рисунок 3).

Рисунок 3

Чтобы гарантировать точность модели, следует использовать стандартную терминологию. Блоки именуются глаголами или глагольными оборотами, и эти имена сохраняются при декомпозиции. Стрелки и их сегменты, как отдельные, так и связанные в "пучок", помечаются существительными или оборотами существительного. Метки сегментов позволяют конкретизировать данные или материальные объекты, передаваемые этими сегментами, с соблюдением синтаксиса ветвлений и слияний.

Каждая сторона функционального блока имеет стандартное назначение с точки зрения связи блок/стрелки. В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Стрелка (и), входящая (ие) в левую сторону блока, - вход (ы). Входы преобразуются или расходуются функцией, чтобы создать то, что появится на ее выходе. Стрелка (и), входящая (ие) в блок сверху, - управление (я). Управление (я) определяет (ют) условия, необходимые функции, чтобы произвести правильный выход. Стрелка (и), покидающая (ие) блок справа, - выход (ы), то есть данные или материальные объекты, произведенные функцией.

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

Стандартное расположение стрелок показано на рисунке 3.

6.2 Имена и метки

Как указывалось, имена функций - глаголы или глагольные обороты.

Примеры таких имен:

производить детали

наблюдать за выполнением

разработать детальные чертежи

планировать ресурсы

проектировать систему

изготовить компонент

наблюдать

эксплуатировать

проверять деталь

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

спецификации

конструкторские требования

инженер-конструктор

отчет об испытаниях

конструкция детали

плата в сборе

директива

требования

Пример размещения меток стрелок и имени блока показан на рисунке 4.

Рисунок 4

6.3 Сводка семантических правил для блоков и стрелок

а) Имя блока должно быть глаголом или глагольным оборотом.

б) Каждая сторона функционального блока имеет стандартное отношение блок/стрелки:

Входные стрелки должны связываться с левой стороной блока;

Управляющие стрелки должны связываться с верхней стороной блока;

Выходные стрелки должны связываться с правой стороной блока;

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

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

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

г) Чтобы связать стрелку с меткой, следует использовать ломаную молниеобразную выносную линию ().

д) В метках стрелок не должны использоваться следующие термины: функция, вход, управление, выход, механизм, вызов.

6.4 Диаграммы IDEF0

IDEF0-модели состоят из документов трех типов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг на друга. Графическая диаграмма - главный компонент IDEF0-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть разбиты (декомпозированы) на составные части и представлены в виде более подробных диаграмм; процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта.

Диаграмма верхнего уровня обеспечивает наиболее общее описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте.

6.5 Контекстная диаграмма верхнего уровня

Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется А-0 (А минус ноль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя - общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представляют полный комплект внешних интерфейсов объекта. Диаграмма А-0 устанавливает область моделирования и ее границу. Пример диаграммы А-0 показан на рисунке 5.

Рисунок 5

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

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

Методология SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы.

Начало разработки данной методологии было положено Дугласом Россом (США) в середине 60-х гг. ХХ в. С тех пор системные аналитики компании SofTech, Inc. улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, управление финансами и материально-техническим снабжением – вот некоторые из областей эффективного применения SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе «Интеграции компьютерных и промышленных технологий» (Integrated Computer Aided Manufacturing, ICAM) Министерства обороны США была признана полезность SADT. Это привело к публикации ее части в 1981 г., называемой IDEF0 (Icam DEFinition), в качестве федерального стандарта на разработку программного обеспечения. Под этим названием SADT стала применяться тысячами специалистов в военных и промышленных организациях . Последняя редакция стандарта IDEF0 была выпущена в декабре 1993г. Национальным институтом по стандартам и технологиям США (National Institute Standards and Technology, NIST).

Данная методология при описании функционального аспекта информационной системы конкурирует с методами, ориентированными на потоки данных (DFD). В отличие от них IDEF0 позволяет:

Описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);

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

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

Основу методологии IDEF0 составляет графический язык описания процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.

Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм [ , ]:

Контекстную диаграмму;

Диаграммы декомпозиции;

Диаграммы дерева узлов;

Диаграммы только для экспозиции (for exposition only, FEO).

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

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

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

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

6.3. Элементы графической нотации IDEF0

Методология IDEF0 нашла широкое признание и применение, в первую очередь, благодаря простой графической нотации, используемой для построения модели. Главными компонентами модели являются диаграммы. На них отображаются функции системы в виде прямоугольников, а также связи между ними и внешней средой посредством стрелок. Использование всего лишь двух графических примитивов (прямоугольник и стрелка) позволяют быстро объяснить правила и принципы построения диаграмм IDEF0 людям, незнакомым с данной методологией. Это достоинство позволяет подключить и активизировать деятельность заказчика по описанию бизнес-процессов с использованием формального и наглядного графического языка.

На следующем рисунке показаны основные элементы графической нотации IDEF0 .

Рис. 6.1. Элементы графической нотации IDEF0

Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу) , которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).

Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок :

- вход (англ. input) – материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы;

- управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т.е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);

- выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;

- механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;

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

6.4. Типы связей между работами

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

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

1. Иерархическая связь (связь «часть» – «целое») имеет место между функцией и подфункциями, из которых она состоит.

Рис. 6.2. Иерархическая связь

2. Регламентирующая (управляющая, подчиненная) связь отражает зависимость одной функции от другой, когда выход одной работы направляется на управление другой. Функцию, из которой выходит управление, следует считать регламентирующей или управляющей, а в которую входит – подчиненной. Различают прямую связь по управлению , когда управление передается с вышестоящей работы на нижестоящую (рис. 6.3), и обратную связь по управлению , когда управление передается от нижестоящей к вышестоящей (рис. 6.4).

3. Функциональная (технологическая) связь имеет место, когда выход одной функции служит входными данными для следующей функции. С точки зрения потока материальных объектов данная связь показывает технологию (последовательность работ) обработки этих объектов. Различают прямую связь по входу , когда выход передается с вышестоящей работы на нижестоящую (рис. 6.5), и обратную связь по входу , когда выход передается с нижестоящей к вышестоящей (рис.6.6).

Рис. 6.5. Прямая связь по входу	Рис. 6.6. Обратная связь по входу

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

Рис. 6.7. Потребительская связь

5. Логическая связь наблюдается между логически однородными функциями. Такие функции, как правило, выполняют одну и ту же работу, но разными (альтернативными) способами или, используя разные исходные данные (материалы).

Рис. 6.8. Логическая связь

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

Рис. 6.9. Методическая связь

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

Рис. 6.10. Ресурсная связь

8. Информационная связь имеет место между функциями, использующими в качестве входных данных одну и ту же информацию.

Рис. 6.11. Информационная связь

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

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

Рис. 6.12. Временная связь

10. Случайная связь возникает, когда конкретная связь между функциями мала или полностью отсутствует.

Рис. 6.13. Случайная связь

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

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

В IDEF0 существуют соглашения (правила и рекомендации) по созданию диаграмм, которые призваны облегчить чтение и экспертизу модели [ , ]. Некоторые из этих правил CASE-средства поддерживают автоматически, выполнение других следует обеспечить вручную.

1. Перед построением модели необходимо определиться, какая модель (модели) системы будет построена. Это подразумевает определение ее типа AS-IS, TO-BE или SHOULD-BE, а также определения позиции, с точки зрения которой строится модель. «Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. Например, при построении модели работы продуктового магазина можно среди возможных претендентов, с точки зрения которых рассматривается система, выбрать продавца, кассира, бухгалтера или директора. Обычно выбирается одна точка зрения, наиболее полно охватывающая все нюансы работы системы, и при необходимости для некоторых диаграмм декомпозиции строятся диаграммы FEO, отображающие альтернативную точку зрения.

2. На контекстной диаграмме отображается один блок, показывающий назначение системы. Для него рекомендуется отображать по 2–4 стрелки, входящие и выходящие с каждой стороны.

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

4. Блоки на диаграмме декомпозиции следует располагать слева направо и сверху вниз. Такое расположение позволяет более четко отразить логику и последовательность выполнения работ. Кроме этого маршруты стрелок будут менее запутанными и иметь минимальное количество пересечений.

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

Рис. 6.14. Функция без управления и входа

Блок с наличием только управления можно рассматривать как вызов в программе функции (процедуры) без параметров. Если у блока имеется вход, то он эквивалентен вызову в программе функции с параметрами. Таким образом, блок без управления и входа эквивалентен функции, которая в программе ни разу не вызывается на исполнение.

На рис. 6.7–6.12, отображающих фрагменты диаграмм IDEF0, встречаются блоки без входа и управления. Это не стоит рассматривать как ошибку, так как подразумевается, что одна из этих стрелок должна быть.

6. У каждого блока должен быть как минимум один выход.

Рис. 6.15. Функция без выхода

Работы без результата не имеют смысла и не должны моделироваться. Исключение составляют работы, отображаемые в модели AS-IS. Их наличие свидетельствует о неэффективности и несовершенстве технологических процессов. В модели TO-BE эти работы должны отсутствовать.

7. При построении диаграмм следует минимизировать число пересечений, петель и поворотов стрелок.

8. Обратные связи и итерации (циклические действия) могут быть изображены с помощью обратных дуг. Обратные связи по входу рисуются «нижней» петлей, обратная связь по управлению – «верхней» (см. рис. 6.4 и 6.6).

9. Каждый блок и каждая стрелка на диаграммах должны обязательно иметь имя. Допускается использовать ветвление (декомпозицию) или слияние (композицию) стрелок. Это связано с тем, что одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. И наоборот, одинаковые или однородные данные и объекты, порожденные разными работами, могут использоваться в одном месте.

Рис. 6.16. Ветвление стрелок

При этом допускается задание различным ветвям стрелки уточняющих имен после разветвления (до слияния). Если какая-либо ветвь после ветвления не именована, то считается, что ее имя соответствует имени стрелки, записанному до ветвления.

Так, на рис. 6.16 управления, входящие в блоки «Изготовление деталей» и «Сборка изделия», имеют уточняющие значения и являются составной частью более общего управления «Чертежи». Для работы блока «Контроль качества» используются все чертежи.

На диаграмме не допускается рисовать стрелки, когда до и после ветвления они не именованы. На рис. 6.17 стрелка, входящая в блок «Формирование типовых ведомостей», не имеет имени до и после ветвления, что является ошибкой.

Рис. 6.17. Неправильное именование стрелок

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

Рис. 6.18. Туннелирование стрелок

В данном примере при построении модели проведения новогоднего утренника механизм «два топора» не будет отображаться на диаграммах верхних уровней, при чтении которых может возникнуть справедливый вопрос: «А зачем нужны два топора на новогоднем утреннике?».

Аналогичным образом можно выполнять туннелирование с обратной целью – недопущения отображения стрелки на диаграммах низших уровней. В этом случае круглые скобки ставятся на конце стрелки. На контекстной диаграмме (см. рис. 6.21) затуннелирован механизм «Инженер службы пути», входящий в блок «Определение допускаемых скоростей». Такое решение принято, так как инженер непосредственно участвует во всех работах, отображенных на диаграмме декомпозиции этого блока (см. рис. 6.22). Чтобы не показывать эту связь и не загромождать диаграмму декомпозиции, стрелка была затуннелирована.

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

12. Если две стрелки проходят параллельно (начинаются из одной и той же грани одной работы и заканчиваются на одной и той же грани другой работы), то по возможности следует их объединить и называть единым термином.

Рис. 6.19. Объединение связей

13. Каждый блок на диаграммах должен иметь свой номер. Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Блок на диаграмме верхнего уровня обозначается 0, блоки на диаграммах второго уровня – цифрами от 1 до 9 (1, 2, …, 9), блоки на третьем уровне – двумя цифрами, первая из которых указывает на номер детализируемого блока с родительской диаграммы, а вторая номер блока по порядку на текущей диаграмме (11, 12, 25, 63) и т. д. Контекстная диаграмма имеет обозначение «А – 0», диаграмма декомпозиции первого уровня – «А0», диаграммы декомпозиции следующих уровней – состоят из буквы «А», за которой следует номер декомпозируемого блока (например, «А11», «А12», «А25», «А63»). На рисунке показано типичное дерево диаграмм (диаграмма дерева узлов) с нумерацией.

Рис. 6.20. Иерархия диаграмм

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

6.6. Пример построения модели IDEF0 для системы определения допускаемых скоростей

Расчет допускаемых скоростей движения поездов является трудоемкой инженерной задачей. При проходе поездом какого-либо участка фактическая скорость движения поезда не должна превышать предельно допускаемую. Эта предельно допускаемая скорость устанавливается исходя из опыта эксплуатации и специально проводимых испытаний по динамике движения и воздействию на путь подвижного состава. Непревышение этой скорости гарантирует безопасность движения поездов, комфортабельные условия езды пассажиров и т. п. Они определяются в зависимости от типа подвижного состава (марки локомотива и типа вагонов), параметров верхнего строения пути (типа рельсов, балласта, эпюры шпал) и плана (радиуса кривых, переходных кривых, возвышения наружного рельса и т. д.). Как правило, для установления допускаемых скоростей необходимо определить не менее двух (на прямых) и пяти (в кривых) скоростей, из которых и выбирается окончательная допускаемая скорость, как наименьшая из всех рассчитанных. Расчет этих скоростей регламентируются Приказом МПС России № 41 от 12 ноября 2001 г. «Нормы допускаемых скоростей движения подвижного состава по железнодорожным путям колеи 1520 (1524) мм Федерального железнодорожного транспорта».

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

Контекстная диаграмма для задачи определения допускаемых скоростей показана на рис.6.21. Для построения модели использовался продукт BPwin 4.0 фирмы Computer Associates.

Рис. 6.21. Контекстная диаграмма системы определения допускаемых скоростей (методология IDEF0)

В качестве исходной информации , на основе которой выполняется определение допускаемых скоростей, используются:

Данные проекта новой линии или проекта реконструкции (содержат всю необходимую информацию для реализации проекта, а именно километраж, оси раздельных пунктов, план линии и др.);

Подробный продольный профиль (содержит информацию, аналогичную рассмотренной выше);

Паспорт дистанции пути (содержит информацию, аналогичную рассмотренной выше, а также сведения о верхнем строении пути (ВСП));

Данные о результатах съемки плана пути вагоном-путеизмерителем;

Ведомость возвышений наружного рельса в кривых (содержит информацию о плане пути).

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

Управляющими данными являются:

Указание начальника службы пути дороги или Департамента пути и сооружений ОАО «РЖД» на расчет;

Приказ № 41, содержащий нормативно-справочную информацию, порядок и формулы определения допускаемых скоростей;

Сведения о текущем или планируемом поездопотоке (данные о марках обращающихся локомотивов и типах используемых вагонов);

Сведения о планируемых ремонтах пути, реконструкции и переустройстве сооружений и устройств.

Результатом работы системы должны быть:

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

Ведомости Приказа начальника дороги об установлении допускаемых скоростей на перегонах и раздельных пунктах (Приказ «Н») согласно принятой на дороге форме. Утвержденный Приказ «Н» официально закрепляет допускаемые скорости движения поездов;

Типовые формы № 1, 1а и 2, содержащие планируемые допускаемые скорости для разработки графика движения поездов.

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

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

Диаграмма декомпозиции первого уровня для рассматриваемой задачи приведена на рис.6.22. Как правило, при построении диаграммы декомпозиции исходная функция (декомпозируемая) разбивается на 3–8 подфункций (блоков). При этом блоки на диаграмме декомпозиции рекомендуется располагать слева направо сверху вниз, чтобы лучше была видна последовательность и логика взаимодействия подфункций.

Рис. 6.22. Диаграмма декомпозиции первого уровня (методология IDEF0)

Очередность выполнения функций для решения рассматриваемой задачи следующая:

Ввод и корректировка нормативно-справочной информации и данных по участкам дороги (блоки 1 и 2);

Подготовка задания на расчет (блок 3). В нем указывается, для какого участка и пути, а также марки локомотива и типа вагонов следует выполнить расчет;

Расчет допускаемых скоростей в соответствии с порядком и формулами, указанными в Приказе № 41 (блок 4). В качестве исходной информации выступают данные по пути участка (план, верхнее строение пути и т. д.) и нормативы, выбираемые на основании задания на расчет;

Формирование ведомостей допускаемых скоростей (блок 5). На базе результатов расчета создаются несколько видов выходных документов, которые, с одной стороны, позволяют выявить причину ограничений скорости, с другой стороны, выступают в качестве основы для подготовки регламентированных документов;

Формирование и подготовка проекта Приказа «Н» и типовых ведомостей (блоки 6 и 7).

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

6.7. ICOM-коды

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

ICOM-коды (аббревиатура от Input, Control, Output и Mechanism) предназначены для идентификации граничных стрелок. ICOM-код содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (см. рис.).

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Design Technique. (В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0. Подробные спецификации на стандарты IDEF можно найти на сайте http://www.idef.com .

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

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. Другими словами, первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени - трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области").

Цель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:

Почему этот процесс должен быть замоделирован?

Что должна показывать модель?

Что может получить читатель?

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

Точка зрения (Viewpoint) . Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only).

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Edit/Model Properties , вызывающий диалог Model Properties (рис. 4). В закладкеPurpose следует внести цель и точку зрения, а в закладкуDefinition - определение модели и описание области.

В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладкеSource описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). ЗакладкаGeneral служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели -AS-IS иТО-ВЕ .

Рис. 4. Диалог задания свойств модели

Модели AS-IS и ТО-ВЕ . Обычно сначала строится модель существующей организации работы - AS-IS (как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, "кто что сделал" и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, "что мы делаем сегодня" перед тем, как перепрыгнуть на то, "что мы будем делать завтра". Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных/лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.

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

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу "все оставить как есть, только чтобы компьютеры стояли", т. е. ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.

Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состояния системы, поскольку такой переход - это тоже бизнес-процесс.

Результат описания модели можно получить в отчете Model Report . Диалог настройки отчета по модели вызывается из пункта менюReport/Model Report . В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет (рис. 5).

Рис. 5. Отчет по модели

Диаграммы IDEF0. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.

Модель может содержать четыре типа диаграмм:

контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

диаграммы декомпозиции;

диаграммы дерева узлов;

диаграммы только для экспозиции (FEO).

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

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

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

Пример создания функционально модели.

В качестве примера рассматривается деятельность вымышленной компании «Computer Word». Компания занимается в основном сборкой и продажей настольных компьютеров и ноутбуков. Компания не производит компоненты самостоятельно, а только собирает и тестирует компьютеры.

Основные виды работ в компании таковы:

продавцы принимают заказы клиентов;

операторы группируют заказы по типам компьютеров;

операторы собирают и тестируют компьютеры;

операторы упаковывают компьютеры согласно заказам;

кладовщик отгружает клиентам заказы.

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

Методика выполнения работы

1. Запустите BPwin ().

2. Если появляется диалог ModelMart Connection Manager , нажмите на кнопкуCancel (Отмена).

3. Щелкните по кнопке . Появляется диалоговое окноI would like to (рис. 6). Внесите в текстовое полеName имя модели "Деятельность компании" и выберите Туре –Business Process (IDEF0) . Нажмите кнопкуОК .

Рис. 6. Присвоение модели имени и выбор типа модели

4. Откроется диалоговое окно Properties for New Models (Свойства новой модели) (рис. 7). Введите в текстовое полеAuthor (Автор) имя автора модели и в текстовое полеAuthor initials его инициалы. Нажмите последовательно кнопкиApply иОК .

5. Автоматически создается незаполненная контекстная диаграмма (рис. 8).

6. Обратите внимание на кнопку на панели инструментов. Эта кнопка включает и выключает инструмент просмотра и навигации -Model Explorer (Браузер модели).Model Explorer имеет три вкладки –Activities (), Diagrams () и Objects (). Во вкладкеActivities щелчок правой кнопкой по объекту в браузере модели позволяет выбрать опции редактирования его свойств (рис. 9).

Рис. 8. Незаполненная контекстная диаграмма

Рис. 9. Щелчок правой кнопкой по объекту во вкладке Activities позволяет воспользоваться контекстным меню для редактирования его свойств

7. Перейдите в меню Model/Model Properties . Во вкладкеGeneral диалогового окнаModel Properties в текстовое полеModel name следует внести имя модели "Деятельность компании", а в текстовое полеProject имя проекта "Модель деятельности компании", и, наконец, в текстовоеTime Frame (Временной охват) -AS-IS (Как есть) (рис. 10).

Рис. 10. Окно задания свойств модели

8. Во вкладке Purpose диалогового окнаModel Properties в текстовое полеPurpose (цель) внесите данные о цели разработки модели - "Моделировать текущие (AS-IS) бизнес-процессы компании", а в текстовое полеViewpoint (точка зрения) - "Директор" (рис. 11).

Рис. 11. Внесение данных о цели моделирования и точке зрения

9. Во вкладке Definition диалогового окнаModel Properties в текстовое полеDefinition (Определение) внесите "Это учебная модель, описывающая деятельность компании" и в текстовое полеScope (охват) - "Общее управление бизнесом компании: исследование рынка, закупка компонентов, сборка, тестирование и продажа продуктов" (рис. 12).

10. Перейдите на контекстную диаграмму и правой кнопкой мыши щелкните по прямоугольнику представляющему, в нотации IDEF0 , условное графическое обозначение работы. В контекстном меню выберите опциюName (рис. 13). Во вкладкеName внесите имя "Деятельность компании" (рис. 14).

11. Во вкладке Definition диалогового окнаActivity Properties в текстовое полеDefinition (Определение) внесите "Текущие бизнес-процессы компании" (рис. 15). Текстовое полеNote (Примечания) оставьте незаполненным.

Рис. 12. Внесение дополнительных данных определяющих модель

Рис. 13. Контекстное меню для работы с выбранной опцией Name

Рис. 14. Присвоение работе названия

Рис. 15. Внесение дополнительных данных о работе

12. Создайте ICOM -стрелки на контекстной диаграмме (таблица 1).

Таблица 1 - Стрелки контекстной диаграммы

13. С помощью кнопки внесите текст в поле диаграммы - точку зрения и цель (рис. 16).

Рис. 16. Внесение текста в поле диаграммы с помощью редактора Text Block Editor

14. Создайте отчет по модели. В меню Tools/Reports/Model Report (рис. 17) задайте опции генерирования отчета (установите галочки) и нажмите кнопкуPreview (Предварительный просмотр) (рис. 18).

Рис. 17. Задание опций генерирования отчета Model Report

Рис. 18. Предварительный просмотр отчета Model Report

Декомпозиция производственных процессов по методологии IDEF 0

Работы (Activity)

Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, "Изготовление детали", "Прием заказа" и т.д.). Работа "Изготовление детали" может иметь, например, следующее определение: "Работа относится к полному циклу изготовления изделия от контроля качества сырья до отгрузки готового упакованного изделия". При создании новой модели (меню File/New ) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом (рис. 1).

Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалогActivity Properties (рис. 2).

Рис. 1. Пример контекстной диаграммы

Рис. 2. Редактор задания свойств работы

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

Возникает диалог Activity Box Count (рис. 3), в котором следует указать нотацию новой диаграммы и количество работ на ней. Выберем нотациюIDEF0 и щелкнем наОК . Появляется диаграмма декомпозиции (рис. 4). Допустимый интервал числа работ 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.

Рис . 3. Диалог Activity Box Count

Рис. 4. Пример диаграммы декомпозиции

Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, щелкнув сначала по кнопке на палитре инструментов, а затем по свободному месту на диаграмме.

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

Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу располагается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое расположение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ.

Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, например, работа "Сборка изделия" имеет номер 3 и не была еще декомпозирована. Работа "Контроль качества" (номер 4) имеет нижний уровень декомпозиции

Стрелки (Arrow)

Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, "Заготовка", "Изделие", "Заказ").

В IDEF0 различают пять типов стрелок:

Вход (Input) - материал или информация, которые используются или преобразуется работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рис. 1. - это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в этом примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то скорее всего это вход, если нет - управление.

Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 1 стрелки "Задание"и "Чертеж" - управление для работы "Изготовление изделия". Управление влияет на работу, но не преобразуется работой. Если цель работы - изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 1 стрелка "Готовое изделие" является выходом для работы "Изготовление изделия".

Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. 1 стрелка "Персонал предприятия" является механизмом для работы "Изготовление изделия". По усмотрению аналитика стрелки механизма могут не изображаться в модели.

Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы. На рис. 1 стрелка "Другая модель работы" является вызовом для работы "Изготовление изделия". Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.

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

Для внесения граничной стрелки входа следует:

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

Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary ).

ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 - это не элемент управления нижестоящими работами. Работы нижнего уровня - это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня - это то же самое, что границы диаграммы декомпозиции.ICOM (аббревиатура отInput, Control, Output и Mechanism ) - коды, предназначенные для идентификации граничных стрелок. КодICOM содержит префикс, соответствующий типу стрелки (I ,С ,О илиМ ), и порядковый номер. BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опциюShow ICOM codes на закладке Presentation диалога Model Properties .

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

Содержимое словаря стрелок можно распечатать в виде отчета (меню Report/Arrow Report... ) и получить тем самым толковый словарь терминов предметной области, использующихся в модели.

Рис . 5. Диалог Arrow Properties

Рис. 6. Словарь стрелок

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

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

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

Связь по входу (output-input) , когда стрелка выхода вышестоящей работы (далее - просто выход) направляется на вход нижестоящей.

Связь по управлению (output-control) , когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей.

Обратная связь по входу (output-input feedback) , когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов.

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

Связь выход-механизм (output-mechanism) , когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы.

Явные стрелки . Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.

Разветвляющиеся и сливающиеся стрелки . Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. С другой стороны, стрелки, порожденные в разных работах, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по соответствующему сегменту работы. Для слияния двух стрелок выхода нужно в режиме редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки.

Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления.

Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей не именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления.

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку.

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

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

Для их "перетаскивания" наверх нужно сначала выбрать кнопку на палитре инструментов и щелкнуть по квадратным скобкам граничной стрелки. Появляется диалог Border Arrow Editor (рис. 7).

Рис . 7. Диалог Border Arrow Editor

Если щелкнуть по кнопке Resolve Border Arrow , стрелка мигрирует на диаграмму верхнего уровня, если по кнопкеChangeToTunnel- стрелка будет затоннелирована и не попадет на другую диаграмму.

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

Пример создания диаграммы декомпозиции

1. Выберите кнопку перехода на нижний уровень в палитре инструментов и в диалоговом окнеActivity Box Count (рис. 8) установите число работ на диаграмме нижнего уровня - 3 - и нажмите кнопкуОК .

Рис. 8. Диалоговое окно Activity Box Count

2. Автоматически будет создана диаграмма декомпозиции (рис. 9).

Рис. 9. Диаграмма декомпозиции

Правой кнопкой мыши щелкните по работе расположенной в левом верхнем углу области редактирования модели, выберите в контекстном меню опцию Name и внесите имя работы. Повторите операцию для оставшихся двух работ. Затем внесите определение, статус и источник для каждой работы согласно данным таблицы 1.

Таблица 1. Работы диаграммы декомпозиции А0

Диаграмма декомпозиции примет вид представленный на рис. 10.

Рис.10 Диаграмма декомпозиции после присвоения работам наименований

3. Для изменения свойств работ после их внесения в диаграмму можно воспользоваться словарем работ (рис. 11). Вызов словаря производится при помощи пункта главного меню Dictionary /Activity .

Рис . 11. Словарь Activity Dictionary

Если описать имя и свойства работы в словаре, ее можно будет внести в диаграмму позже с помощью кнопки в палитре инструментов. Невозможно удалить работу из словаря, если она используется на какой-либо диаграмме. Если работа удаляется из диаграммы, из словаря она не удаляется. Имя и описание такой работы может быть использовано в дальнейшем. Для добавления работы в словарь необходимо перейти в конец списка и щелкнуть правой кнопкой по последней строке. Возникает новая строка, в которой нужно внести имя и свойства работы. Для удаления всех имен работ, не использующихся в модели, щелкните по кнопке(Purge (Чистить)).

4. Перейдите в режим рисования стрелок и свяжите граничные стрелки, воспользовавшись кнопкой на палитре инструментов так, как это показано на рис. 12.

Рис. 12. Связанные граничные стрелки на диаграмме А0

5. Правой кнопкой мыши щелкните по ветви стрелки управления работы "Сборка и тестирование компьютеров" и переименуйте ее в "Правила сборки и тестирования" (рис. 13). Внесите определение для новой ветви: "Инструкции по сборке, процедуры тестирования, критерии производительности и т. д.". Правой кнопкой мыши щелкните по ветви стрелки механизма работы "Продажи и маркетинг" и переименуйте ее как "Система оформления заказов" (рис. 14).

Рис. 13. Стрелка "Правила сборки и тестирования"

Рис. 14. Стрелка "Система оформления заказов"

6. Альтернативный метод внесения имен и свойств стрелок - использование словаря стрелок (вызов словаря - меню Dictionary/ Arrow ). Если внести имя и свойства стрелки в словарь (рис. 15), ее можно будет внести в диаграмму позже.

Рис. 15. Словарь стрелок

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

7. Создайте новые внутренние стрелки так, как показано на рис. 16.

Рис. 16. Внутренние стрелки диаграммы А0

8. Создайте стрелку обратной связи (по управлению) "Результаты сборки и тестирования", идущую от работы "Сборка и тестирование компьютеров" к работе "Продажи и маркетинг". Измените, при необходимости, стиль стрелки (толщина линий) и установите опцию Extra Arrowhead (Дополнительный Наконечник стрелы) (из контекстного меню). Методомdrag&drop перенесите имена стрелок так, чтобы их было удобнее читать. Если необходимо, установите из контекстного менюSquiggle (Загогулину). Результат возможных изменений показан на рис. 17.

Рис. 17. Результат редактирования стрелок на диаграмме А0

9. Создайте новую граничную стрелку выхода "Маркетинговые материалы", выходящую из работы "Продажи и маркетинг". Эта стрелка автоматически не попадает на диаграмму верхнего уровня и имеет квадратные скобки на наконечнике (рис. 18).

Рис. 18. Стрелка Маркетинговые материалы

10. Щелкните правой кнопкой мыши по квадратным скобкам и выберите пункт меню Arrow Tunnel (рис. 19).

В диалоговом окне Border Arrow Editor (Редактор Граничных Стрелок) выберите опциюResolve it to Border Arrow (Разрешить как Граничную Стрелку) (рис. 20).

Рис . 19. Пункт меню Arrow Tunnel

Рис . 20. Диалоговое окно Border Arrow Editor

Для стрелки "Маркетинговые материалы" выберите опцию Trim (Упорядочить) из контекстного меню. Результат выполнения лабораторной работы показан на рис. 21.

Рис. 21. Результат выполнения декомпозиции

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

Определение

IDEF 0 (Integration Definition for Function Modeling) – методология функционального моделирования для описания функций предприятия, предлагающая язык функционального моделирования для анализа, разработки, реинжиниринга и интеграции информационных систем бизнес процессов; или анализа инженерии разработки ПО (or software engineering analysis).

Методология IDEF0 является развитием метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique).

IDEF0 как стандарт был разработан в 1981 году в рамках программы ICAM (Integrated Computer Aided Manufacturing – интегрированная компьютерная поддержка производства).

IDEF 0 – Integration DEFinition language 0 – основан на SADT и в своей исходной форме включает одновременно: определение языка графического моделирования (синтаксис и семантику) и описание полной (comprehensive) методологии разработки моделей.

Последняя редакция IDEF0 была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

В 1993 году IDEF0 была принята в качестве федерального стандарта в США, а в 2000 году – в качестве стандарта в Российской Федерации.

Применение IDEF0

IDEF0 используется для создания функциональной модели , то есть результатом применения методологии IDEF0 к системе есть функциональная модель IDEF0.

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

Методология IDEF0 может быть использована для моделирования широкого спектра как автоматизированных, так и неавтоматизированных систем.

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

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

Цели стандарта IDEF0

Основные цели (objectives) стандарта:

задокументировать и разъяснить технику моделирования IDEF0 и правила ее использования;

обеспечить средства для полного и единообразного (consistently) моделирования функций системы или предметной области, а также данных и объектов, которые связывают эти функции;

обеспечить язык моделирования, который независим от CASE методов или средств, но может быть использован при помощи этих методов и средств;

обеспечить язык моделирования, который имеет следующие характеристики:

общий (generic) – для анализа систем и предметных областей;

строгий и точный (rigorous and precise) – для создания корректных, пригодных к использованию моделей);

краткий (concise) – для облегчения понимания, коммуникации, согласия между заинтересованными лицами и проверки. (to facilitate understanding, communication, consensus and validation);

абстрактный (conceptual) ­– для представления функциональных требований, независимых от физических или организационных реализаций;

гибкий ­– для поддержки различных фаз жизненного цикла проекта.

Строгость и точность (Rigor and Precision)

Правила IDEFØ требуют достаточной строгости и точности для удовлетвроения нужд без чрезмерных ограничений аналитика (to satisfy needs without overly constraining the analyst). IDEFØ правила включают следующее:

управление детализацией (control of the details communicated at each level) – от трех до шести функциональных блоков на каждом уровне декомпозиции;

связанный контекст (Bounded Context) – не должно быть недостающийх или лишних, выходящих за установленные рамки деталей;

связанность интерфейса диаграмм (Diagram Interface Connectivity) – номера узлов, функциональных блоков, C-numbers и Detail Reference Expression);

связанность структуры данных. (Data Structure Connectivity) – ICOM codes and the use of parentheses;

уникальные метки и заголовки (Unique Labels and Titles) – отсутствие повторяющихся названий;

синтаксические правила для графики (Syntax Rules for Graphics) – функциональные блоки и стрелки;

ограничения на разветвления стрелок данных (Data Arrow Branch Constraint) – метки для ограничений потоков данных на разветвлениях;

разделение данных на Вход и Управление (Input versus Control Separation) – правило для определения роли данных);

маркировка стрелок данных. Data Arrow Label Requirements (minimum labeling rules);

наличие Управления (Minimum Control of Function) – все функции должны иметь минимум одно Управление;

цель и точка зрения (Purpose and Viewpoint) – все модели имеют формулировку цели и точки зрения.

Основные понятия IDEF0

В основе методологии лежат четыре основных понятия:

функциональный блок;

интерфейсная дуга;

декомпозиция;

глоссарий.

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы.

По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги»).

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

верхняя сторона имеет значение «Управление» (Control);

левая сторона имеет значение «Вход» (Input);

правая сторона имеет значение «Выход» (Output);

нижняя сторона имеет значение «Механизм» (Mechanism).

Рис. Функциональный блок

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

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

В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей».

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

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

Последним из понятий IDEF0 является глоссарий (Glossary).

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

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

Моделирование. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой .

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

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

1. В составе модели должна присутствовать контекстная диаграмма A-0, которая содержит только один блок. Номер единственного блока на контекстной диаграмме A-0 должен быть 0.
2. Блоки на диаграмме должны располагаться по диагонали – от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров. Блоки на диаграмме, расположенные вверху слева «доминируют» над блоками, расположенными внизу справа. «Доминирование» понимается как влияние, которое блок оказывает на другие блоки диаграммы. Расположение блоков на листе диаграммы отражает авторское понимание доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные.
3. Неконтекстные диаграммы должны содержать не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм на уровне, доступном для чтения, понимания и использования. Диаграммы с количеством блоков менее трех вызывают серьезные сомнения в необходимости декомпозиции родительской функции. Диаграммы с количеством блоков более шести сложны для восприятия читателями и вызывают у автора трудности при внесении в нее всех необходимых графических объектов и меток.
4. Каждый блок неконтекстной диаграммы получает номер, помещаемый в правом нижнем углу; порядок нумерации — от верхнего левого к нижнему правому блоку (номера от 1 до 6).
5. Каждый блок, подвергнутый декомпозиции, должен иметь ссылку на дочернюю диаграмму; ссылка (например, узловой номер, C-номер или номер страницы) помещается под правым нижним углом блока.
6. Имена блоков (выполняемых функций) и метки стрелок должны быть уникальными. Если метки стрелок совпадают, это значит, что стрелки отображают тождественные данные.
7. При наличии стрелок со сложной топологией целесообразно повторить метку для удобства ее идентификации.
8. Следует обеспечить максимальное расстояние между блоками и поворотами стрелок, а также между блоками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки.
9. Блоки всегда должны иметь хотя бы одну управляющую и одну выходную стрелку, но могут не иметь входных стрелок.
10. Если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления. Этим подчеркивается управляющий характер данных и уменьшается сложность диаграммы.
11. Максимально увеличенное расстояние между параллельными стрелками облегчает размещения меток, их чтение и позволяет проследить пути стрелок
12. Стрелки связываются (сливаются), если они представляют сходные
    данные и их источник не указан на диаграмме (рис. 2)

    Рисунок 2 — Стрелки связываются

13. Обратные связи по управлению должны быть показаны как «вверх и над»
    (рис.3, а):
    Рисунок 3 — Обратные связи

    Обратные связи по входу должны быть показаны как «вниз и под» (рис. 3, б). Так же показываются обратные связи посредством механизма. Таким образом обеспечивается показ обратной связи при минимальном числе линий и пересечений.

14. Циклические обратные связи для одного и того же блока изображаются только для того, чтобы их выделить. Обычно обратную связь изображают на диаграмме, декомпозирующей блок. Однако иногда требуется выделить повторно используемые объекты (рис. 4)

    Рисунок 4 — Циклические обратные связи

15. Стрелки объединяются, если они имеют общий источник или приемник, или они представляют связанные данные. Общее название лучше описывает суть данных. Следует минимизировать число стрелок, касающихся каждой стороны блока, если, конечно, природа данных не слишком разнородна (рис. 5)

    Рисунок 5 — Стрелки объединяются

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

    Рисунок 6 — стрелки присоединяются к блокам в одной и той же позиции

17. При соединении большого числа блоков необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки
    

    

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

    

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

    

20. Необходимо использовать (где это целесообразно) выразительные возможности ветвящихся стрелок