2.1. Сущность структурного подхода
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции. Система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и т.д. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны. При разработке системы «снизу-вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов [1,68].
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются принцип решения сложных проблем путем их разбиения на множество меньших независимыхзадач, легких для понимания и решения и принцип иерархического упорядочивания  организации составных частей проблемы в иерархические древовидные структуры с добавлением на каждом уровне новых деталей.

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

1. принцип абстрагирования  выделение существенных аспектов системы и отвлечение от несущественных;
2. принцип формализации  необходимость строгого методического подхода к решению проблемы;
3. принцип непротиворечивости  обоснование и согласование элементов;
4. принцип структурирования и иерархической организации данных.

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

1. SADT (StructuredAnalysisandDesignTechnique)  модели и соответствующие функциональные диаграммы [6];
2. DFD (DataFlowDiagrams)  диаграммы потоков данных [91;
3. ERD (Entity-Relationship Diagrams) диаграммы «сущность связь»[10].

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

2.2. Методология функционального моделирования SADT
Методология SADT была разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий)
[1113].
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения модели объекта какой-либо предметной области, и включает в себя следующие методики:

1. IDEF0  методология функционального моделирования. С мощью наглядного графического языка IDEF0 изучаемая системапредстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (в терминах IDEF0 функциональных блоков). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы;
2. IDEF1  методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать структуру и взаимосвязи;
3. IDEF1X (IDEF1 Extended)  методология построения реляционных структур. IDEF1X относится к типу методологий «сущность-связь» (EREntity-Relationship) и как правило используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;
4. IDEF2  методология динамического моделирования разных систем. В связи со сложностью анализа динамических систем от этого стандарта практически отказались и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CRNColorPetriNets);
5. IDEF3  методология документирования процессов, происходящих в системе, используемой, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0  каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;
6. IDEF4      методология   построения   объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействии,  тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;
7. IDEF5  методология онтологического исследования сложных систем, при помощи которой онтология системы может быть описана с использованием определенного словаря терминов  и правил, и на этом основании могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в не который момент времени. Эти утверждения становятся основой для формирования выводов о дальнейшем развитии системы и проведения ее оптимизации.

Основные элементы методологии  SADT основываются  на следующих концепциях:

1. графического представления блочного моделирования. Графика блоков и дуг SADTдиаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются;
2. строгости и точности выполнения правил SADT без чрез мерных ограничений действий аналитика.
3. Правила SADT включают:
4. ограничение количества блоков на каждом уровне деком позиции (36 блоков);
5. связность диаграмм (номеров блоков);
6. уникальность  меток  и  наименований  (отсутствие повторяющихся имен);
7. синтаксические правила для графики (блоков и дуг);
8. разделение входов и управлений (правило определения роли данных);
9. отделение организации от функции, т.е. исключение влияния анизационной структуры на функциональную модель.

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

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

1. с дугами связаны надписи (или метки) на естественном описывающие данные, которые они представляют;
2. дуги показывают, как взаимосвязаны между собой функции, как они обмениваются данными и осуществляют управление друг с другом;
3. выходы одной функции могут быть входами, управлением механизмом для другой;
4. дуги могут разветвляться и соединяться;
5. функциональный блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных между собой интерфейсными дугами;
6. эти блоки представляют основные подфункции (подмодули) единого исходного модуля;
7. данная декомпозиция выявляет полный набор подмодулей, каждый из которых представлен как блок, границы которого определены интерфейсными дугами;
8. каждый из этих подмодулей может быть декомпозирован подобным же образом для более детального представления.

2.3.1. Основные концепции IDEF0
1. Графическое представление моделируемой деятельности. Графика «блоков и дуг» в IDEFOдиаграммах показывает производственные операции как блок и взаимосвязи с операциями, как дуги, входящие/выходящие в блок. Для того чтобы представить реальные производственные операции, блоки могут быть интерпретированы как деятельность, связанная с другими блоками, с интерфейсными дугами, определяющими когда и как переключаются или управляются операции (рис. 2.1).

Рис. 2.1. Графическое представление моделируемой деятельности

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

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

4. Точность и однозначность. Правила IDEF0 включают:

• подробное описание на каждом уровне (36 блоков);
• ограниченный контекст (только относящееся к делу без упущений);
• синтаксические правила построения диаграмм (блоки и дуги);
• неповторяющиеся названия блоков и дуг;
• переходы между диаграммами (дерево диаграмм);
• переход между объектами/данными (коды ICOM и туннельные переходы);
• разделение входа и управления (правила для определения роли данных или объекта);
• обязательное наличие управления (все блоки требуют как минимум одного управляющего входа);
• сегменты стрелок (разделение или соединение), метки для дуг;
• требования к наименованию дуг;
• наличие назначения и точки зрения для всех моделей.

5. Методология. Пошаговые процедуры, предназначенные для моделирования, обзора и сбора данных.

6. Организация  Функция. Разделение организации от функции системы включено в назначение модели и определяется выбором функций и меток дуг в процессе создания модели. Непрерывный пересмотр в процессе создания модели гарантирует, что отсутствует взгляд с точки зрения оргструктуры.

2.3.2. Принципы моделирования в IDEF0
В IDEF0 реализованы три базовых принципа моделирования процессов: функциональной декомпозиции, ограничения сложности и принцип контекста.
Принцип функциональной декомпозиции представляет из себя такой способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. Другими словами, сложная функция может быть представлена в виде совокупности элементарных функций.
Принцип ограничения сложности. При работе с IDEF0-диаграммами существенным является условие их разборчивости и удобочитаемости. Суть принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее трех, но не более шести. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEFO-модели, хорошо структурированы, понятны и легко поддаются анализу.
Принцип контекстной диаграммы. Моделирование делового процесса начинается с построения контекстной диаграммы, на которой отображается только один блок  главная функция моделируемой системы. Если речь идет о моделировании целого предприятия или даже крупного подразделения, главная функция не может быть сформулирована как, например, «продавать продукцию». Главная функция системы  это «миссия» системы, ее значение в окружающем мире. Нельзя правильно сформулировать главную функцию предприятия, не имея представления о его стратегии. При определении главной функции необходимо всегда иметь в виду цель моделирования и точку зрения на модель. Одно и то же предприятие может быть описано по-разному в зависимости от того, с какой точки зрения его рассматривают: директор предприятия и налоговой инспектор видят организацию совершенно по-разному. Контекстная диаграмма играет еще одну роль в функциональной модели. Она «фиксирует» границы моделируемой системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается за счет описания дуг, соединенных с блоком, представляющим главную функцию.

2.3.3. Основные элементы и понятия IDEF0
Модель IDEF0 состоит из диаграмм, фрагментов текстов и  глоссария, имеющих ссылки друг на друга. Диаграммы  главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса.
Одной из наиболее важных особенностей методологии IDEF0 является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия, первым из которых является понятие функционального блока (ActivityBox), графически изображаемого в виде прямоугольника (рис. 2.2) и олицетворяющего собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано глаголом в изъявительном наклонении (например, «производить услуги», а не «производство услуг»).
Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:
1. верхняя сторона имеет значение «Управление» (Control) (стрелки сверху, означающие то, на основании чего выполняется данный процесс,  законы, стандарты, приказы и т.д.);

2. левая сторона имеет значение «Вход» (Input) (стрелки слева
данные или объекты, потребляемые или изменяемые процессом);

3. правая сторона имеет значение «Выход» (Output) (стрелки справа  основные результаты деятельности процесса, конечные продукты);

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

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

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

Вторым «китом» методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком, или оказывает иное влияние на функцию, отображенную данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (ArrowLabel). По требованию стандарта, наименование должно быть оборотом существительного.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей». Кроме того, «источником» (началом) и «приемником» (концом) каждой функциональной дуги могут
Выть только функциональные блоки, при этом «источником» может быть только выходная сторона блока, а «приемником» любая из трех оставшихся.
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь по крайней мере одну направляющую интерфейсную дугу и одну исходящую. Это и понятно  каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет смысла.
Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (DataFlowDiagram) и WFD (WorkFlowpiegram).
Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Модель IDEF0 всегда начинается с представления системы как единого целого  одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентифи­катором «А0».

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

2.3.4. Декомпозиция модели IDEF0
Построение IDEFO-модели начинается с представления всей системы в виде простейшей компоненты  одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг  они также представляют полный набор внешних интерфейсов системы в целом.
Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью не­скольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, причем каждая из них представлена как блок, границы которого определены интерфейсными дугами. В свою очередь каждая из этих подфункций также может быть декомпозирована подобным образом для более детального представления.
Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е., как уже отмечалось выше, родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено.
Модель IDEF0 представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, представленные в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы (рис. 2.3).
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы.
На рис. 2.4, 2.5 представлены различные варианты выполне­ния функций и соединения дуг с блоками.

Рис. 2.3. Декомпозиция функциональных блоков

Рис. 2.4. Одновременное выполнение

Рис. 2.5 Соответствие должно быть полным и непротиворечивым

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

Рис. 2.6. Пример обратной связи

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

Рис. 2.7. Пример механизма

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

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

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

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

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

2.3.7. Практика применения функционального моделирования средствами IDEF0
В последние годы в России интерес к методологиям семейства IDEF неуклонно растет. Собственно говоря, первые CASE-средства, позволяющие строить DFD и IDEFOдиаграммы, появились на российском рынке еще в 1996 г. одновременно с выходом популярной книги по принципам моделирования в стандартах SADT.
Тем не менее, большинство руководителей до сих пор расценивают практическое применение моделирования в стандартах IDEF скорее как дань моде, нежели чем эффективный путь оптимизации существующей системы управления бизнесом. Вероятнее всего, это связано с ярко выраженным недостатком информации по практическому применению этих методологий.
Не секрет, что сейчас в России практически все проекты обследования и анализа финансовой и хозяйственной деятельности предприятий так или иначе связаны с построением автоматизированных систем управления. Благодаря этому стандарты IDEF в понимании большинства стали условно неотделимы от внедрения информационных технологий, хотя с их помощью порой можно эффективно решать даже небольшие локальные задачи, буквально при помощи карандаша и бумаги.
При проведении сложных проектов обследования предприятий разработка моделей в стандарте IDEF0 позволяет наглядно и эффективно отобразить весь механизм деятельности предприятия. Однако самое главное  это возможность коллективной работы, которую предоставляет IDEF0.
Консультант за достаточно короткое время объясняет сотрудникам основные принципы IDEF0 и обучает работе с соответствующим прикладным программным обеспечением. В результате сотрудники различных отделов создавали IDEFдиаграммы деятельности своего подразделения, в которых должно было быть отражено:

1. что поступает в подразделение «на входе»?
2. какие функции и в какой последовательности выполняются в рамках подразделения?
3. кто  является  ответственным   за  выполнение   каждой   из функций?
4. чем руководствуется исполнитель при выполнении каждой из функций?
5. что является результатом работы подразделения (на выходе)?

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

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

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

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

Рис. 2.9. Случайная связность

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

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

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

Рис. 2.10. Процедурная связность

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

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

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

Рис. 2.12. Последовательная связность

(6) Тип функциональной связности

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

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

В математических терминах необходимое условие для простейшего типа функциональной связности, показанной на рис. 2.13, имеет следующий вид:
C = g{B) = gi/{A))
В таблице представлены все типы связей,  рассмотренные выше.  Важно  отметить,  что уровни  46 устанавливают типы связностей, которые разработчики считают важнейшими дли но лучения диаграмм хорошего качества.

2.4. Методология IDEF1X
Метод IDEF1, разработанный Т. Рэмей, основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. И настоящее время на основе совершенствования методологии IDEFI создана ее новая версия  методология IDEF1X, разработанная с учетом таких требований, как простота изучения и возможность автоматизации.  IDEFlX диаграммы   используются  рядом  распространенных CASE-средств (в частности, ERwin, Design/IDEF).
Сущность в методологии IDEF1X является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (рис. 2.14).

Рис. 2.14. Сущности

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

1. каждый экземпляр сущности родителя может иметь ноль, один или более связанных с ним экземпляров сущности потомка;
2. каждый экземпляр сущности родителя должен иметь не менее одного связанного с ним экземпляра сущности потомка;
3. каждый экземпляр сущности родителя должен иметь не более одного связанного с ним экземпляра сущности потомка;
4. каждый экземпляр сущности родителя связан с некоторым фиксированным числом экземпляров сущности потомка.

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

Рис. 2.15. Мощность связи

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

Рис. 2.16. Идентифицирующая связь

Пунктирная линия изображает не идентифицирующую связь (рис. 2.17). Сущность потомок в не идентифицирующей связи будет независимой от идентификатора, если она не является также сущностью потомком в какой-либо идентифицирующей связи.

Рис. 2.17. Неидентифицирующая связь

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

Рис. 2.18. Атрибуты и первичные ключи

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

Рис. 2.19. Примеры внешних ключей

Ссылки

http://do.bti.secna.ru

http://baks.gaz.ru | http://baks.gaz.ru

http://www.interface.ru

http://kisa01.narod.ru

http://eup.ru

http://www.info-system.ru

http://www.cfin.ru

http://laborant-work.info

Контрольные вопросы

1. В чем заключается сущность структурного подхода?
2. Назовите базовые принципы методологии структурного подхода.
3. Какие методики содержит методология SADT?
4. Перечислите основные правила методологии IDEF0.
5. В чем заключаются основные концепции IDEF0?
6. Опишите принцип функциональной декомпозиции.
7. Охарактеризуйте принцип ограничения сложности.
8. Опишите принцип контекстной диаграммы.
9. Определите понятие функционального блока.
10. Определите понятие интерфейсной дуги.
11. Что такое декомпозиция модели IDEF0?
12. Как обеспечивается групповая работа в 1DEF0?
13. Назовите типы связей между функциями и объясните их сущность.
14. Объясните модель «сущность-связь».
15. Как определяется мощность связей?
16. Объясните понятие идентифицирующей и не идентифицирующей связи.

Начало | Глава 1 | Глава 3