Методология функционального моделирования SADT

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

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип ин­терфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (чело­век или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рисунок 1).

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

На рисунке 2, где приведены четыре диаграммы и их взаимосвязи, показана структура SADT-модели. Каж­дый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует «внутреннее строение» блока на родительской диаграмме.

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

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

Рисунок 1 - Функциональный блок и интерфейсные дуги

Эта диаграмма является «родителем» этой диаграммы

Более детальное представление

		А4

Рисунок 2 - Структура SADT-модели. Декомпозиция диаграмм

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

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

На рисунках 3 - 5 представлены различные варианты выполнения функций и соединения дуг с блоками.

Функции блоков 2 и 3 могут выполняться параллельно

Только эти данные передаются

Рисунок 3 - Одновременное выполнение

А12

Рисунок 4 - Пример детализации

Рисунок 5 - Пример обратной связи

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

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

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

		Контракт

Рисунок 6 - Пример механизма

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

Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диа­грамм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 7 пока­зано типичное дерево диаграмм.

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

Ниже каждый тип связи кратко определен и проиллюстрирован с помощью типичного примера из SADT.

(0) Тип случайной связности: наименее желательный.

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

Рисунок 7 - Иерархия диаграмм

Рисунок 8 - Случайная связность

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

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

(3)Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. Пример процедур­но-связанной диаграммы приведен на рисунке 9

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

Рисунок 9 - Процедурная связность

Рисунок 10 - Коммуникационная связность

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

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

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

Рисунок 11 - Последовательная связность

Рисунок 12 - Функциональная связность

Таблица 1. Типы связей

Стандарт IDEF0

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

C 1981 г. стандарт IDEF0 претерпел несколько незначительных изменений, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 г. Национальным Институтом по Стандар­там и Технологиям США (NIST).

В основе методологии лежат четыре основных понятия. Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (рисунок 13) и оли­цетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стан­дарта название каждого функционального блока должно быть сформулировано в глагольной форме (например, «производить услуги», а не «производство услуг»).

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

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

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

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

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

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

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейс­ная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

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

Рисунок 14 - Функциональный блок «Обработать заготовку»

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

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

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

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

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

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

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

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

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

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

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую «деталь» на входе в функциональный блок «Обработать на токарном станке» не имеет смысла отражать на диаграммах более высоких уровней - это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги означает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока-приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежу­точных уровнях иерархии - в таком случае они сначала «погружаются в туннель», а затем при необходимости «возвращаются из туннеля».

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

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

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

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

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

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

1. Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является ди­намическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных про­цессов. На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

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

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

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

В последние годы интерес в России к методологиям семейства IDEF неуклонно растет. При этом интерес к таким стандартам, как IDEF3-5 можно назвать теоретическим, а к IDEF0 вполне практически обоснованным. Собственно говоря, первые Case-средства, позволяющие строить DFD- и IDEF0-диаграммы, появились на рос­сийском рынке еще в 1996 г.

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

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

Стандарт IDEF1

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

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

· выяснить структуру и содержание существующих потоков информации на предприятии;

· определить, какие проблемы, выявленные в результате функционального анализа и анализа потребно­стей, вызваны недостатком управления соответствующей информацией;

· выявить информационные потоки, требующие дополнительного управления для эффективной реализа­ции модели.

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

· определение самой информации и структуры ее потоков, имеющей отношение к деятельности пред­приятия;

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

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

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

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

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

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

1) устойчивость (информация, имеющая отношение к той или иной сущности, постоянно накапливается);

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

Каждая сущность имеет свое имя и атрибуты. Атрибуты представляют собой характерные свойства и при­знаки объектов реального мира, относящихся к определенной сущности. Класс атрибутов представляет собой набор пар, состоящих из имени атрибута и его значения для определенной сущности. Атрибуты, по которым можно однозначно отличить одну сущность от другой, называются ключевыми атрибутами. Каждая сущность может характеризоваться несколькими ключевыми атрибутами. Класс взаимосвязей в IDEF1 представляет со­бой совокупность взаимосвязей между сущностями. Взаимосвязь между двумя отдельными сущностями счита­ется существующей в том случае, если класс атрибутов одной сущности содержит ключевые атрибуты другой сущности. Каждый из вышеописанных классов имеет свое условное графическое отображение согласно мето­дологии IDEF1.

На рисунке 16 приведен пример IDEF1-диаграммы. На ней представлены две сущности с именами «Отдел» и «Сотрудник» и взаимосвязь между ними с именем «работает в». Имя взаимосвязи всегда выражается в глаголь­ной форме. Если же между двумя или несколькими объектами реального мира не существует установленной зависимости, то, с точки зрения IDEF1, между соответствующими им сущностями взаимосвязь также отсутст­вует.

Рисунок 16 - IDEF1-диаграмма

В заключение стоит еще раз отметить, что стандарт IDEF1 является методом изучения и анализа в отличие от очень сходного по терминологии и семантике стандарта IDEF1X, предназначенного для разработки структу­ры реляционных баз данных и оперирующего с конкретными объектами физического мира.

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