Файл: PRIS.doc

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

Дуги позволяют отражать взаимосвязи между блоками. По типу этой связи выделяют 5 видов взаимодействия (Error: Reference source not found). Примеры данных взаимодействий и их отражения на модели показаны на схемах

Модель в IDEF0

Модель в IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма располагается на отдельном листе (Error: Reference source not found).

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

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

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

Точка зрения (Viewpoint). Особенно важно включать в процесс разработки модели представителей различных мнений, однако сама модель должна базироваться на единой точке зрения. Чаще всего разнообразные точки зрения кратко фиксируют на диаграмме ФЕО (FEO – For Exposition Only – только для комментариев). Эти диаграммы используются только в качестве материалов для презентаций.

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

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

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

Диаграммы IDEF0 второго уровня называются дочерней (Child diagram) по отношению к первому (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок – предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram).

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

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

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

Принципы IDEF0

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

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

Суть принципа функциональной декомпозиции очень прост (Error: Reference source not found):

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

Принцип ограничения сложности

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

Принцип контекста (целеполагания)

Как было указано выше любая модель должна отвечать на вопросы о системе («М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А»). Это означает, что не может быть модели вообще. Любая модель – это лишь инструмент и чтобы правильно ее создать надо иметь однозначное представление о цели моделирования (Purpose), точке зрения (Viewpoint) и границах моделирования (Scope). Принцип целеполагания как раз и означает, что любая модель в SADT – должна быть определена прежде всего по перечисленным трем позициям.

Правила построения IDEF0 диаграмм

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

Правило контекста

В составе модели должна присутствовать контекстная диаграмма number prefix-0 (например, А-0), которая содержит только один блок. Номер единственного блока на контекстной диаграмме А-0 должен быть 0 (Error: Reference source not found). Это правило обеспечивает выполнение принципа контекста.

Правило «доминирования»

Блоки на диаграмме должны располагаться по диагонали - от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров (Error: Reference source not found). Блоки на диаграмме, расположенные вверху слева «доминируют» над блоками, расположенными внизу справа. «Доминирование» понимается как влияние, которое блок оказывает на другие блоки диаграммы.

Правило ограничения сложности

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

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

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

Правило выбора управления

Часто возникает проблема, когда автор модели не может однозначно определить, к какому из типов дуг отнести ту или иную интерфейсную стрелку. Прежде всего такая ситуация возникает, когда речь идет об отображении на диаграмме информационных потоков. Для преодоления этой проблемы и существует правило выбора управления. В соответствии с этим правилом если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления. Этим подчеркивается управляющий характер данных и уменьшается сложность диаграммы (Error: Reference source not found).

Правила нумерации и именования диаграмм, блоков и дуг

Правило нумерации блоков

Каждый блок диаграммы декомпозиции получает номер, помещаемый в правом нижнем углу (Error: Reference source not found); порядок нумерации - от верхнего левого к нижнему правому блоку (в соответствии с доминированием блоков).

Правило нумерации диаграмм

Каждая диаграмма имеет свой уникальный код, который формируется следующим образом (Error: Reference source not found):

Правило именования

Имена блоков (выполняемых функций) и метки дуг должны быть уникальными (Error: Reference source not found). Если метки интерфейсных стрелок совпадают, это значит, что стрелки отображают тождественные данные.

Правила компоновки объектов диаграмм

Правило компоновки блоков

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

Правило рисования стрелок

Надо пытаться максимально увеличивать расстояние между параллельными стрелками (Error: Reference source not found), что облегчает размещение меток, их чтение и позволяет проследить пути стрелок.

Правило минимизации пересечений

При соединении большого числа блоков необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки (Error: Reference source not found

Правило связывания дуг

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

Дуги объединяются, если они имеют общий источник или приемник, или они представляют связанные данные. Общее название лучше описывает суть данных. Следует минимизировать число дуг, касающихся каждой стороны блока, если, конечно, природа данных не слишком разнородна (Error: Reference source not found).

Правило присоединения дуг к блокам

Если возможно, дуги присоединяются к блокам в одной и той же позиции. Тогда соединение дуг конкретного типа с блоками будет согласованным и чтение диаграммы упростится (Error: Reference source not found).

Процесс моделирования

В одной из лучших книг по SADT-моделированию дается следующая характеристика этой методологии: «В значительной мере успех методологии SADT объясняется ее графическим языком, хотя не менее ценным является сам процесс моделирования. Процесс моделирования в SADT включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели и уточнение модели посредством итеративного рецензирования. Кроме того, этот процесс подсказывает вполне определенный путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе системы. SADT уникальна в своей способности обеспечить как графический язык, так и процесс создания непротиворечивой и полезной системы описаний». Если процесс моделирования описанный в РД IDEF0-2000 представить в нотации IDEF0, то получится следующее видение (Error: Reference source not found

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

Нотация DFD. Виды нотаций DFD. Синтаксис DFD. [8]

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

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

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

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

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

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

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

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