Аис1

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

входы процесса - спецификации заказа на партию редукторов и исходные материалы со склада;

выходы процесса - готовая редукторы, предназначенная для отправки на склад, и техническая документация, создаваемая на различных стадиях процесса;

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

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

иего соответствие требованиям заказчика;

точка зрения – генеральный директор.

Цель модели

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

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

сзаданной степенью точности. Четко определенная цель становится критерием окончания моделирования. Таким образом, цель модели – это: набор вопросов, на которые должна ответить модель и критерий окончания моделирования.

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

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

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

Цель должна отвечать на следующие вопросы:

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

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

какую информацию может получить читатель модели?

Список вопросов сохраняется как детализация цели модели. Только поняв, насколько

31

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

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

Точка зрения

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

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

Точка зрения:

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

определяет, что будет рассматриваться и под каким углом зрения;

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

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

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

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

32

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

Описание процесса производственной системы

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

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

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

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

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

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

33

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

Блоки

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

Блок отображает преобразования входов в выходы при наличии необходимых ресурсов (механизмов) в управляемых условиях, происходящие в течение определенного времени и имеющие распознаваемые результаты. Цель и результат работы любого блока на диаграмме любого уровня декомпозиции осуществление преобразования входов в выходы под действием «управлений» при помощи «механизмов». Функциональный блок, как отображающий модели-руемую систему в целом (блок АО), так и блоки на любом уровне декомпозиции, являются преобразующими блоками.

Преобразование объектов в блоке

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

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

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

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

в рамках функционирования конкретного блока.

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

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

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

35

процессов и внешней среды.

3.ОПЕРАЦИЯ - совокупность последовательно или/и параллельно выполняемых действий, преобразующих объекты, входящие в состав материального или/и информационного потока, в соответствующие объекты с другими свойствами.

Операция выполняется:

-в соответствии с директивами, вырабатываемыми на основе директив, определяющих протекание процесса, в состав которого входит операция;

-с потреблением всех видов потребных ресурсов;

-с соблюдением ограничений со стороны других операций и внешней среды.

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

на осуществление операции. Дополнительные виды функций:

1.Субдеятельность - совокупность нескольких процессов в составе деятельности, объ-единенная некоторой частной целью (являющейся «подцелью» деятельности).

2.Подпроцесс - группа операций в составе процесса, объединенная технологически

или организационно.

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

Идентификация блоков

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

глагола, отвечающего на вопрос: «Что делать?»;

объекта действия, отвечающего на вопрос: «Что?»;

дополнения (необязательно), служащего для уточнения функции.

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

В отличие от других графических методов структурного анализа в IDEF0 каждая из четырех сторон блока имеет особое, вполне определенное назначение: левая - для входов; верхняя - для управления; правая - для выходов; нижняя - для механизмов.

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

ICOM (Input-Control-Output-Mechanism)

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

Номер функции представляет собой сочетание числа и префикса и показывается в правом нижнем углу. Все блоки на диаграмме декомпозиции нумеруются слева направо. Префикс может быть любой длины, но обычно используют префикс А.. На контекстной диаграмме A-0 единственному блоку присваивается номер 0 (ноль). Число (от 1 до 6) указывает порядок

37

доминиро-вания: 1 будет указывать на наибольшее доминирование, 2 - на следующее после наибольшего, и т.д.

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

При дальнейшей декомпозиции функции меньшего доминирования будут нумероваться по узлу, т.е. иметь номера родительского блока и очередного порядкового номера (Al, A2, A3 и т.д.). Поэтому согласно принятой нотации все декомпозиции нижнего уровня должны также содержать номер родительской функции и очередной порядковый номер, например функции декомпозиции A6 будут иметь номера А61, А62, А6З, А64 и т.д. Т.о. функции образуют иерархию, где каждая функция может иметь одну родительскую и несколько дочерних функций, образуя дерево, которое называется деревом узлов, а вышеописанная нумерация - нумерацией по узлам.

Топология блоков

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

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

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

необходимо избегать «нависания» блоков друг над другом, т.к. это затрудняет чтение диа-грамм при изображении на них связей по входу;

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

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

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

38

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

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

расстояние между блоками должно быть максимальным.

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

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

Стрелки

Для адекватного объяснения работы системы, как на уровне деталей, так и на уровне ее окружающей среды, ее описание должно содержать многообразие объектов. Взаимосвязи и взаимодействия функций с внешним миром и между собой в IDEF0 представляются стрелками, соединяющими выходы одних функциональных блоков с механизмом, входом и/или управлением других, и отражающих информационные и материальные потоки между блоками, которые необходимы для выполнения функции или появляются в результате ее выполнения (объекты, обрабатываемые в процессе). Стрелка - направленная линия, состоящая из одного или нескольких сегментов, которая моделирует открытый канал или канал, передающий данные или материальные объекты от источника (начальная точка стрелки), к потребителю (конечная точка с «наконечником»). СЕГМЕНТ СТРЕЛКИ - сегмент линии, который начинается или заканчивается на стороне блока, в точке ветвления или слияния, или на границе (несвязанный конец стрелки).

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

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

В реальных диаграммах к каждой функции может подходить и от каждой может отхо-дить около десятка стрелок. Если диаграмма содержит 6 функций, то она может содержать 30-40 стрелок, причем они могут сливаться, разветвляться и пресекаться. Такие диаграммы могут стать очень плохо читаемыми. В IDEFO существуют соглашения по рисованию диаграмм, которые призваны облегчить чтение и экспертизу модели. Синтаксические правила для стрелок:

стрелка формируется из одного или более сегментов (отрезков) и наконечника на одном конце;

39

сегменты стрелки могут быть прямыми и ломанными. Горизонтальные и вертикальные от-резки ломаной стрелки сопрягаются под углом 900;

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

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

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

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

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

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

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

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

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

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

Отдельные сегменты стрелок после их ветвления могут иметь собственное имя, называемое меткой. Метки сегментов позволяют конкретизировать информационные или материальные объекты, передаваемые этими сегментами, с соблюдением синтаксиса ветвлений и слияний.

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

Для того чтобы выделить в IDEF0-модели элементы определенного типа, при

40