Е.Б. Степанова, М.Ю. Балтрушевич

Факультет инноваций и высоких технологий

 

 

Серия: Моделирование и проектирование

      информационных комплексов

 

Е.Б. Степанова, М.Ю. Балтрушевич

 

ПРОЦЕССНО-ОРИЕНТИРОВАННЫЕ МЕТОДЫ

ПРОЕКТИРОВАНИЯ

ИНФОРМАЦИОННЫХ КОМПЛЕКСОВ

 

Лабораторный практикум

 

 

москва  2007

 

УДК 004.4

     С79

Степанова Е.Б., Балтрушевич М.Ю. Процессно-ориентированные методы проектирования информационных комплексов. — М.: МФТИ, 2007. — 85 с. — (Серия: Моделирование и проектирование информационных комплексов).

 

 

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

Способствует формированию навыков работы со средствами системного проектирования Design IDEF. Рассмотрены примеры построения функциональной модели IDEF0 и информационной модели IDEF1Х.

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

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

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

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

 

Рецензент

 Доктор физико-математических наук,

 

 

                                              © Московский физико-технический институт

                                                           (государственный университет), 2007

 

 

СОДЕРЖАНИЕ

ВВЕДЕНИЕ………………………………………………………………...4

ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

1. Методология SADT и концепция технологии

функционального моделирования Integrated definition - IDEF0……......8

1.1. Синтаксис IDEF0 диаграмм и модели...............................................10

1.2. Процесс моделирования; координация коллективной работы.......17

1.3. Выбор контекста, точки зрения и цели модели................................20

1.4. Создание IDEF0-диаграмм..................................................................21

1.5. Критерий окончания декомпозиции диаграмм и меры по

управлению проектом; цикл папки............................................................25

КОНТРОЛЬНЫЕ ВОПРОСЫ.....................................................................28

 

2. Информационное моделирование в нотации IDEF1X..........................29

2.1. Инфологическое моделирование предметной области.....................31

2.2. Сущность, атрибут, связь. Графическое представление

характеристик связи....................................................................................33

2.3. Уровни представления данных. Этапы

проектирования............................................................................................41

2.4.. Особенности применения нотации IDEF1X.....................................48

КОНТРОЛЬНЫЕ ВОПРОСЫ.....................................................................48

 

ПРАКТИЧЕСКАЯ ЧАСТЬ

Работа 1. Ознакомление с инструментальной средой системного

проектирования DESIGN IDEF и изучение приемов разработки

функциональной модели.............................................................................49

Работа 2. Разработка функциональной модели информационной

системы в среде DESIGN IDEF по индивидуальному заданию.............64

Работа 3. Изучение приемов разработки информационной модели

в нотации IDEF1X........................................................................................70

Работа 4. Разработка информационной модели нотации IDEF1Х

в среде DESIGN IDEF по индивидуальному заданию.............................76

ВАРИАНТЫ ЗАДАНИЙ ПО РАЗРАБОТКЕ МОДЕЛЕЙ........................80

СПИСОК ЛИТЕРАТУРЫ……..…………..................................................84

Введение

 

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

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

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

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

Как для объектных, так и для реляционных систем устранение ошибок, допущенных на стадиях анализа и проектирования, требует вложения времени и средств.

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

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

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

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

В данном лабораторном практикуме акцент сделан на обзоре основных положений методологии SADT (Structured Analysis and Design Technique) и технологии IDEF.

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

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

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

Примером такой среды является ARIS (Architecture of Integrated Information Systems). ARIS – это методология системного проектирования и базирующееся на ней семейство программных продуктов для структурированного описания и анализа процессов предприятия, т.е. для задач проектирования и создания интегрированных информационных систем поддержки процессов.

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

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

В данном лабораторном практикуме в теоретическом разделе представлены основные сведения о методологии SADT, технологиях функционального моделирования Integrated definition – IDEF0 и информационного моделирования IDEF1Х; а практический раздел включает четыре лабораторные работы, направленные на формирование следующих навыков:

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

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

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

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

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

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

Основная часть материала серии «Моделирование и проектирование информационных комплексов» была отработана и опробована в электронном виде в поставленном впервые в практике государственных университетов России цикле учебных курсов для студентов различных форм обучения – дневной, экстернат-формы, а также для групп иностранных студентов.

Авторы благодарны: заведующему кафедрой информатики и процессов управления МИФИ Л.Д Модяеву. и заместителю заведующего Н.М.Леоновой за поддержку работы в ходе ее выполнения; профессору Ю.А.Чернышеву за поддержку и консультации по развитию работы; заведующему кафедрой системного анализа МИФИ В.П.Румянцеву за поддержку и неоценимую помощь в задаче сближения учебного материала с ситуацией реального проектирования; сотрудникам кафедры управляющих интеллектуальных систем МИФИ под руководством И.О. Атовмяна - Ю.Г.Древсу, В.В.Золотареву, М.Н. Петухову за стимулирующие дискуссии в ходе подготовки рукописей серии; декану факультета ФИВТ МФТИ В.Е.Кривцову и заместителю декана М.Н.Михееву за помощь в ориентации серии на обучение студентов в области инноваций.

Теоретическая часть

Создание IDEF0-диаграмм

При создании диаграммы не существует жестко определенной последовательности действий, однако можно рекомендовать примерный план действий при создании IDEF0-диаграмм:

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

1. Дайте имена процессам, которые обрабатывают перечисленные данные.

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

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

4. Выберите такое расположение блоков и дуг, которое максимально проявляет их взаимосвязи. Объединяйте дуги вместе, если структура слишком детализирована. Оставьте только существенные элементы и преобразуйте диаграмму.

При необходимости внесите изменения в родительскую диаграмму.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все функции системы содержатся в единственном блоке, показанном на диаграмме А-0. Диаграмма очерчивает границы контекста системы. Диаграмма А0 декомпозирует диаграмму А-0 на подфункции.

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

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

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

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

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

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

При создании любой IDEFO-диаграммы должны быть удовлетворены следующие требования:

· цель и точка зрения диаграммы должны соответствовать установленной цели и точки зрения всей модели;

· граничные дуги должны соответствовать дугам на родительской диаграмме;

· содержание диаграммы должно точно соответствовать содержанию родительского блока.

Исходя из законченной родительской диаграммы, хорошо проработайте верхние уровни, прежде чем приступить к детализации. Получив диаграмму А0, сосредоточьтесь на построении диаграмм А1, А2, A3. Декомпозиция А1 в A11, A111 должна быть выполнена позже. Это исключит потенциальную повторную работу при возможных изменениях в диаграммах верхних уровней.

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

Не откладывайте построение диаграммы более низкого уровня, например, A111. Сделайте набросок по свежим следам. Важно относиться к этим наброскам, как к эскизам, пока горизонтальный уровень не согласован полностью.

Будьте готовы вернуться к разработке нижнего уровня, если он противоречит верхнему, например А1, А2, A3 и т.д.

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

 

Практическая часть

 

Работа 1. Ознакомление с инструментальной средой системного

проектирования DESIGN IDEF и изучение приемов разработки функциональной модели

 

Цель работы: формирование равыков работы в среде DESIGN IDEF, а именно:

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

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

Лабораторная работа рассчитана на два академических часа.

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

Пакет Design IDEF работает как стандартное приложение, интегрированное в оболочку Windows. Для его запуска необходимо выбрать пункт Design_IDEF в меню “программы”, либо дважды щелкнуть кнопкой мыши на иконке с названием пакета. Открывшееся основное окно программы по функциональному назначению можно разделить на пять следующих областей:

· В верхней части экрана расположено функциональное меню, типичное для Windows приложений, которое позволяет выполнить все операции пакета IDEF Design.

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

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

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

· Область в центре экрана предназначена для вывода страниц с диаграммами, составляющими IDEF модель. Каждая страница располагается в отдельном окне, которое называется окном страницы. Заголовок окна состоит из названия страницы и ее номера, например А0: Р.2.

Создание новой модели

Для создания новой модели выберите команду New в меню File. В открывшемся диалоговом окне щелкните мышью на стрелке под разделом Methodology (методология) и выберите из выпадающего списка тип используемой методологии или вида работы: “IDEF0”, “IDEF1X”, “FEO”, “Text”.

Методологии моделирования основаны на графическом представлении проектируемой системы. Для создания функциональной модели, которая является структурированным изображением функций производственной системы или информационной среды, а также объектов, связывающих эти функции, применяется подход, развитый в “IDEF0”. В разделе Startup Master Page Selection необходимо выбрать имя файла, содержащего мастерскую страницу, которая служит в качестве шаблона для всех вновь создаваемых страниц модели. В большинстве случаев можно использовать мастерскую страницу, предлагаемую по умолчанию.

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

Сохранение модели

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

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

Для сохранения модели под другим именем воспользуйтесь командой Save As в меню File.

Открытие существующей модели

Для открытия ранее сохраненной модели выберите команду Open в меню File. На экране появится диалоговое окно открытия файла, в котором отображается текущий каталог, подкаталоги и файлы с IDEF моделями. Выберите каталог, в котором хранится ваша модель, и дважды щелкните мышью на его имени. Затем надо выбрать имя файла, который содержит вашу модель. Страницы открываются в том виде и в том порядке, который они имели при последнем сохранении модели.

При создании новой модели открывается мастерская страница и создается первая страница модели – A-0, на которой расположен один IDEF0-блок с номером А0.

Для формирования полноценной страницы A-0 необходимо добавить текст в функциональный блок А0, нарисовать входящие, выходящие, управляющие и дуги механизма.

Создание дуг

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

· Выберите команду Label (Метка) в меню Create или щелкните мышью на кнопке Label, расположенной на палитре инструментов.

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

· Щелкните мышью, чтобы установить точку вставки, и напечатайте текст метки.

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

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

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

· Закончив построение дуги, отпустите кнопку мыши.

· Аналогично постройте все входящие, выходящие, управляющие и дуги механизма для IDEF0 блока с номером А0.

Функциональные блоки могут быть передвинуты, изменены в размерах, помещены в буфер Windows, скопированы, вставлены из буфера и удалены.

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

Для декомпозиции функционального блока следует:

· выделить блок

· выбрать команду Decompose (Декомпозировать) в меню Create или щелкнуть мышью на кнопке Decompose, расположенной на палитре инструментов.

Выделенный функциональный блок становится декомпозированным блоком. На этом блоке замерцают выделяющие метки, и в строку состояния будет выведено сообщение: Type: Decomposet Activity (Тип: Декомпозированная Функция).

Перейти на вновь созданную страницу можно одним из трех способов:

· дважды щелкнуть мышью на декомпозированном блоке;

· выделить декомпозированный блок и щелкнуть мышью на кнопке Child (Потомок), или выбрать команду Child (Потомок) в меню Select;

· выделить декомпозированный блок и нажать одновременно клавиши Shift и стрелка_вниз.

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

· щелкнуть мышью на кнопке Parent (Родитель);

· выбрать команду Parent (Родитель) в меню Select;

· нажать одновременно клавиши Shift и стрелка_вверх.

Перемещение между диаграммой-потомком и диаграммой-родителем может также осуществляться с помощью стандартного метода перехода со страницы на страницу документа:

· выберите команду Page (Страница) в меню Select.

· щелкните мышью на подстранице или родительской странице, на которую хотите перейти.

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

Для создания отдельного IDEF блока необходимо:

· Выбрать команду IDEF Box (IDEF-блок) в меню Create или щелкнуть мышью на кнопке IDEF Box, которая расположена на палитре инструментов.

· Поместить указатель блока на то место, где вы хотите расположить левый верхний угол блока.

· Каждый щелчок мыши будет создавать очередной блок.

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

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

· Выбрать команду Place Boxes в меню Create или щелкнуть мышью на кнопке Place Boxes, которая расположена на палитре инструментов.

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

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

· Выделить дугу, от которой вы хотите отвести ветвь.

· Выбрать команду Branch в меню Create или щелкнуть мышью на кнопке Branch, расположенной на палитре инструментов. В строке состояния появится сообщение: Select the IDEF box or label for branch (Укажите блок или метку для разветвления).

· Поместить указатель на метку или блок, к которому должна идти ветвь.

· Когда границы объекта замерцают, щелкнуть мышью на той стороне объекта, к которой должна идти ветвь.

Для создания дуги, объединенной по адресату с уже существующей дугой, необходимо:

· Выделить дугу, с которой вы хотите объединить вновь создаваемую дугу.

· Выбрать команду Join в меню Create или щелкнуть мышью на кнопке Join, расположенной на палитре инструментов. В строке состояния появится сообщение: Select the IDEF box or label for the join (Укажите блок или метку для объединения).

· Поместить указатель на метку или блок, который вы хотите соединить с выделенной дугой.

Когда границы объекта замерцают, щелкнуть мышью на той стороне объекта, из которой должна идти ветвь.

Пример построения иерархии диаграмм

Рассмотрим процесс создания модели на примере разработки WEB-сайта “Электронная Доска Объявлений”. “Электронная Доска Объявлений”, или сокращенно ЭДО, является информационной системой, которая предназначена для оперативной связи преподавателей, деканатов и ректората со студентами и сотрудниками института. Моделирование процесса ее создания позволит выявить зависимость работ друг от друга, составить план работ и распределить ресурсы с целью оптимального распараллеливания работ.

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

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

 

Таблица 1

Пример списка объектов и функций для модели ЭДО.

Список объектов	Список функций
1. Техническое задание 2. Объявление 3. Запросы пользователей 4. Ресурсы сети 5. Информационное наполнение 6. Аппаратные средства 7. Программные средства 8. База данных 9. WEB-сервер 10. Документация 11. Разработчики 12. Категории пользователей 13. Категории авторов 14. Правила работы авторов и пользователей 15. Функции администратора 16. Структура “Электронной    Доски Объявлений”	1. Разработать WEB-сайт 2. Создать базу данных 3. Разработать программные средства 4. Настроить аппаратные средства 5. Создать страницы HTML 6. Создать графические рисунки 7. Разработать дизайн сервера 8.  Сконфигурировать системные средства ОС 9. Выработать требования к серверам 10. Выделить ресурсы сети 11. Разработать структуру “Электронной Доски Объявлений”

 

 

 

Рис.13. Контекстная диаграмма

 

 

Рис. 14.Процесс моделирования в IDEF0. Диаграмма A0.

 

Рис.15.Процесс моделирования в IDEF0. Диаграмма А1.

 

Рис. 16. Процесс моделирования в IDEF0. Декомпозиция