Цель лабораторной работы: дать представление студентам об применении ППП Design/IDEF 3.7, предназначенного для разработки структурно-функциональной модели информационной совокупности.
Задания.
1. Ознакомиться с функциями ППП Design/IDEF 3.7 для построения информационных моделей в стандарте IDEF1Х.
2. Выстроить модель информационных потоков в совокупности в стандарте IDEF1Х.
Результаты представить в отчете.
Главные компоненты IDEF1X- модели
Главными компонентами IDEF1X- модели являются:
1. Сущности, воображающие множество настоящих либо абстрактных предметов (людей, объектов, мест, событий, состояний, идей, пар предметов и т.д). Они изображаются блоками.
Выделяют два вида сущностей:
O свободные от идентификатора сущности;
O зависимые от идентификатора сущности.
2. Отношения (связи) между сущностями, изображаемые соединяющими блоки линиями. Выделяют следующие виды взаимоотношений:
O отношения, идентифицирующие связи;
O отношения, не идентифицирующие связи;
O отношения категоризации; неспецифические отношения.
3. Атрибуты – чёрта сущностей, изображаемые именами в блоков. Атрибуты смогут быть:
- неключевыми;
- первичными ключами;
- другими ключами;
- внешними ключами.
Разглядим построение вышеуказанных главных компонентов IDEF1X- модели в среде ППП Design/IDEF 3.7.
Порядок исполнения работы.
1. Запуск IDEF1X моделирования в Design/IDEF
Первый ход в применении Design/IDEF для IDEF1X моделирования –открытие новой IDEF1X -страницы в новой либо существующей IDEF1X-модели.
2. Создание новой IDEF1X-модели в Design/IDEF
Дабы начать создание новой IDEF1X-модели:
а) запустите Design/IDEF;
б) выберите New в меню File;
в) в показавшемся диалоговом окне «Select New Page Type» (рис. 3.1) для информационной модели в перечне Methodology выберите IDEF1Х и подтвердите выбор клавишей OK;
Рис. 3.1. Диалоговое окно «Select New Page Type»
г) появляется чистая IDEF1X-страница для информационной модели.
Создание объектов IDEF1X-класса происходит методом вызова пункта Entity меню Create либо нажатием соответствующей кнопки на панели инструментов (рис. 3.2).
Рис. 3.2. Инструменты для IDEF1X-модели
Создание объектов – сущностей.
Дабы создать любую новую сущность в IDEF1X –модели:
а) выберите Entity в меню Create либо надавите кнопку на функциональной панели инструментов на странице диаграммы покажется безлюдной прямоугольный блок;
б) обозначьте посредством мыши (кликните мышью) прямоугольный блок на странице диаграммы;
в) заполните поля в показавшемся окне «Define Entity»:
Name – это неповторимое имя, благодаря которому сущность будет распознаваться в модели;
Aliases – псевдоним под которым сущность возможно известна;
Definition – определение сущности, которое в большинстве случаев употребляется в предметной области; Attributes – перечень атрибутов данной сущности.
Дабы ввести перечень атрибутов необходимо надавить на клавишу Add и покажется всплывающее окно «Define Attributes» для ввода черт Attributes.
В этом окне для заполнения доступны следующие поля:
O Name — имя атрибута;
O Aliases — псевдоним атрибута;
O Datatype — тип значения атрибута;
O Length — протяженность значения атрибута;
O Precision — количество чисел по окончании точки, для атрибутов числового типа;
O Primary Key — первичный ключ;
O Alternate Key – другой ключ;
O Definition — определение атрибута, которое в большинстве случаев употребляется в предметной области;
O Discriminator — дискриминатор.
Пускай свободная сущность СОТРУДНИК характеризуется следующими атрибутами: Таб. номер, № паспорта, № полиса, Имя, Фамилия, Отчество, Дата рождения.
Примем, что атрибут «Таб. номер» есть первичным ключом (Primary Key — РК) сущности СОТРУДНИК. Не смотря на то, что любой из атрибутов «Таб. номер», «№-полиса» и «№-паспорта» может конкретно идентифицировать экземпляр сущности СОТРУДНИК, исходя из этого они смогут быть атрибутами первичного ключа.
Такие атрибуты размещаются наверху перечня и отделяются от вторых атрибутов горизонтальной чертой. Другие атрибуты сущности являются неключевыми (Фамилия, Имя, Отчество, Дата рождения).
При существовании нескольких вероятных ключей один из них обозначается в качестве первичного ключа (атрибут «Таб. номер» для сущности СОТРУДНИК), а остальные – как другие ключи.
Другой ключ (Alternate key — АК)- это ключ, не являющийся первичным ключом сущности.
Каждому другому ключу присваивается неповторимый целый номер. Данный ключ указывается посредством размещения справа от каждого атрибута ключа заключенных в скобки букв АК с номером другого ключа.
Атрибуты изображаются в виде перечня имен в блока сущности.
Атрибуты, определяющие первичный ключ, размещаются наверху перечня и отделяются от вторых атрибутов горизонтальной чертой.
Введем данную данные в окне «Define Entity» (рис. 3.3 – 3.5) и возьмём на странице модели IDEF1X отображение, представленное на рис. 3.6.
Для назначения других ключей сущностей следует в окне «Define Attributes» поставить флажок рядом с опцией Alternate key и в окне расположенном левее указать порядковый номер (целое положительное число) этого другого ключа (рис. 3.7).
Обозначение «АК-1» (и следующие по порядку) другого ключа присваивается программой самостоятельно по окончании закрытия окна «Define Attributes» для соответствующего атрибута.
На рис. 3.8 приведено изображение свободной сущности СОТРУДНИК на странице диаграммы с двумя другими ключами.
Рис. 3.3. Окно «Define Attributes» для атрибута Таб. номер, принятого в качестве первичного ключа (Primary Key — РК).
Рис. 3.4. Окно «Define Entity» для атрибута Таб. номер, принятого в качестве первичного ключа (Primary Key — РК).
Рис. 3.5. Окно «Define Entity» для атрибутов сущности СОТРУДНИК.
Рис. 3.6. Изображение свободной сущности СОТРУДНИК на странице диаграммы по окончании закрытия окна «Define Entity».
Рис. 3.7. Окно «Define Attributes» для атрибута №-паспорта, принятого в качестве другого ключа (Alternate key — АК).
Рис. 3.8. Изображение свободной сущности СОТРУДНИК на странице диаграммы по окончании закрытия окна «Define Entity» с другими ключами.
Зависимая сущность характеризуется наличием отношением между ней и свободной сущностью, от которой она зависит – реализуется отношение «родитель (свободная сущность) – потомок (зависимая сущность)»
Атрибуты, появляющиеся в зависимой сущности и являющиеся кроме этого первичным ключом второй сущности (сущности-родителя либо неспециализированной сущности) именуются внешними ключами.
Сущность может владеть любым числом внешних (наследуемых) атрибутов.
В диаграммах модели внешние ключи (Foreign Key) изображаются посредством помещения вовнутрь блока сущности имен наследуемых атрибутов, по окончании которых в скобках следуют буквы FK.
В случае, если наследуемый атрибут в собственности первичному ключу сущности-потомка, то он помещается выше горизонтальной линии (а сущность изображается с закругленными углами), а вдруг нет, то – ниже (рис. 3.9).
Рис. 3.9. Атрибуты зависимой сущности Коммисия
Процесс перемещения первичного ключа родительской либо неспециализированной сущности в сущность-потомок либо сущность-категорию из соответствующего отношения именуется миграцией ключа.
Для получения на странице модели фрагмента, представленного на рис. 3.9 нужно выполнить следующие действия:
1. Выстроить сущность Коммисия кроме этого, как формировали сущность СОТРУДНИК.
2. Заполнить для него окно «Define Attributes», как продемонстрировано на рис. 3.10.
3. Заполнить для каждого элемента Attributes их характеристики, использую кнопку Add. Примеры заполненных всплывающих окон для Attributes – «№ — коммисии», «Начальник. Таб. номер (FK)», «Исполнитель. Таб. номер (FK)», «Процент вознаграждения» приведены на рис. 3.11 — 3.14.
4. Выстроить отношения между сущностью сущностью и родительской СОТРУДНИК-потомком Коммисия, надавив кнопку либо выбрав Relationship в меню Create, и соединив сущности СОТРУДНИК Коммисия.
5. Осуществить заполнение полей в показавшихся окнах «Define Relationship» для каждой связи, как продемонстрировано на рис. 3.15 – 3.16.
В появляющихся окнах «Define Relationship» для каждой связи для заполнения доступны следующие поля:
O Relationship – имя отношения;
O Inverse – имя сущности-потомка, с которым устанавливается сообщение отношения (указывается в неспецифических отношениях);
O Definition – определение связи, которое в большинстве случаев употребляется в предметной области;
Рис. 3.10. Окно «Define Attributes» для объекта Коммисия.
Рис. 3.11. Окно «Define Attributes» для атрибута № — коммисии.
Рис. 3.12. Окно «Define Attributes» для атрибута Начальник. Таб. номер
Рис. 3.13. Окно «Define Attributes» для атрибута Исполнитель. Таб. номер
Рис. 3.14. Окно «Define Attributes» для атрибута Процент вознаграждения
Рис. 3.15. Окно «Define Relationship» для связи «Входит», связывающей сущность СОТРУДНИК с сущностью Коммисия
Рис. 3.16. Окно «Define Relationship» для связи «Командует», связывающей сущность СОТРУДНИК с сущностью Коммисия
и метки
O Relationship Type – тип связи (идентифицирующая, неидентифицирующая либо неспецифическая);
O Relationship Cardinality – мощность устанавливаемой связи.
По окончании создания отношенй/связей при наличии атрибутов в информационных блоках происходит обмен атрибутами, т. е. основной ключ блока из которого выходит отношение преобразовывается во внешний ключ (Foreign key) в блоке куда входит отношение. Поменять тип отношения (с идентифицирующего на неидентифицирующее) возможно посредством команды Toggle меню Create либо кнопкой на панели инструментов.
Отношению дается имя, высказываемое грамматическим оборотом глагола.
Имя отношения постоянно формируется с позиций родителя, так что возможно образовано предложение, в случае, если соединить имя сущности-родителя, имя отношения, имя сущности и выражение мощности-потомка.
Мощность определяет какое количество экземпляров сущности-потомка существует для каждого экземпляра сущности-родителя.
В IDEF1X смогут быть выражены следующие мощности взаимоотношений:
– любой экземпляр сущности-родителя может иметь ноль, один либо более связанных с ним экземпляров сущности-потомка (эта мощность устанавливается по умолчанию);
– любой экземпляр сущности-родителя должен иметь не меньше одного связанного с ним экземпляра сущности-потомка (буква Р (positive), помещенная рядом с точкой);
– любой экземпляр сущности-родителя может иметь не более одного связанного с ним экземпляра сущности-потомка (буква Z (zero), помещенная рядом с точкой);
– любой экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка. В случае, если мощность в точности равна некоему числу N, это число (целое, хорошее) помещается около точки.
Идентифицирующая связь между сущностью-сущностью потомком и — родителем изображается целой линией (рис. 3.17).
Рис. 3.17. Фрагмент IDEF1X-модели.
Сущности ЗАКАЗЧИК и КОНТАКТ формируются подобно рассмотренным ранее сущностям.
Сущность-потомок в идентифицирующей связи есть зависимой от идентификатора сущностью.
Сущность-родитель в идентифицирующей связи возможно как свободной, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).
Пунктирная линия изображает неидентифицирующую сообщение (рис. 3.17).
Сущность-потомок в неидентифицирующей связи будет свободной от идентификатора, если она не есть кроме этого сущностью-потомком в какой-либо идентифицирующей связи.
Отношения полной категоризации – это отношение между двумя либо более сущностями, в котором любой экземпляр одной сущности, именующейся неспециализированной сущностью, связан в точности с одним экземпляром одной и лишь одной из вторых сущностей, именуемых сущностями-категориями (рис. 5.18).
Любой экземпляр неспециализированной сущности и связанный с ним экземпляр одной из категоризированных сущностей изображают одинаковый предмет настоящего мира и исходя из этого владеют одним и тем же неповторимым идентификатором.
Для сущности-категории мощность не указывается, потому, что она в любой момент равна нулю либо единице.
К примеру, КЛИЕНТ есть неспециализированной сущностью, а ЗАРУБЕЖНОЕ и ОТЕЧЕСТВЕННОЕ Предприятие являются сущностями-категориями.
Значение некоего атрибута в экземпляре неспециализированной сущности определяет, с каким из вероятных сущностей-категорий он связан.
Данный атрибут именуется дискриминатором отношения категоризации.
В данном примере дискриминатором есть атрибут «Национальная принадлежность».
Рис. 3.18. Модель IDEF1X с дискриминатором полной категоризации
Для получения IDEF1X-модели, представленной на рис. 3.18, направляться выполнить следующие действия:
1. Организовать неспециализированную/свободную сущность КЛИЕНТ со следующими атрибутами: «Имя-клиента (РК)», «Адрес», «Национальная принадлежность» (D – Discriminator).
2. Организовать сущности ОТЕЧЕСТВЕННОЕ ПРЕДПРИЯТИЕ с атрибутом «ЗАРУБЕЖНОЕ Предприятие» и Форма собственности с атрибутами «язык» и «Валюта».
3. Надавив кнопку либо выбрав Relationship в меню Create соединить сущности ОТЕЧЕСТВЕННОЕ Предприятие и ЗАКАЗЧИК.
4. Надавив кнопку либо выбрав Relationship в меню Create соединить сущности ЗАРУБЕЖНОЕ Предприятие и ЗАКАЗЧИК.
В случае, если существует экземпляр неспециализированной сущности, не связанный ни с каким экземпляром из сущностей-категорий, то такое отношение именуется отношением неполной категоризации. На неполноту множества категорий на диаграмме показывает
круг, выделенный один раз.
Неспецифическое отношение, именуемое кроме этого отношением многого ко многому, — это связь между двумя сущностями, при которой любой экземпляр первой сущности связан с произвольным (а также нулевым) числом экземпляров второй сущности, а любой экземпляр второй сущности связан с произвольным (а также нулевым) числом экземпляров первой сущности.
К примеру, в случае, если служащий возможно занят во многих проектах, а в проекте возможно занято довольно много служащих, то отношение между сущностями ПРОЕКТ и СОТРУДНИК есть неспецифическим отношением.
На более поздних стадиях построения модели все неспецифические отношения должны быть детализированы в своеобразные.
На рис. 3.19 приведен пример концептуальной схемы базы данных в нотации IDEF1X, элементы которой употреблялись в качестве примеров для иллюстрации построения главных элементов IDEF1X-модели.
Рис. 3.19.
3. Личные задания лабораторной работы
1. В соответствии с варианту задания, выделите нужный комплект сущностей, отражающих информационные потребности и предметную область пользователей.
2. Выясните нужный комплект атрибутов каждой сущности, выделив идентифицирующие атрибуты.
3. Классифицируйте атрибуты каждой сущности (описательные, показывающие, вспомогательные).
4. Выясните сущности вида подтип/супертип, где это нужно.
5. Выясните связи между сущностями.
6. Проанализировав структуру связей, исключите избыточные.
7. Выясните условность и множественность связей.
8. Дайте формулировку связей с позиций каждой участвующей сущности.
9. Формализуйте связи вида 1:1, 1:M, M:N.
10. Выстройте ER-диаграммы модели базы данных: в нотации Чена; в нотации Мартина; в нотации IDEF1X, в нотации Баркера.
11. Изучите методику построения информационной модели предметной области посредством пакета Design/IDEF.
12. Реализуйте ER-диаграмму модели базы данных в нотации IDEF1X посредством пакета Design/IDEF, предварительно установив атрибуты страницы IDEF1X-модели, воспользовавшись пунктом меню Edit?Set Page Attributes.
Установите значения следующих атрибутов страницы: name – наименование предметной области (варианта задания); user – выполнил (Ф.И.О. студента); project – наименование лабораторной работы; status – Publication; revision – проверил (Ф.И.О учителя).
13. Экспортируйте IDEF1X-модель в формат Windows MetaFile (*.wmf) и сгенерировать sql-скрипт для базы данных, воспользовавшись пунктом меню File?Export.
14. Организуйте IDEF1X отчет, воспользовавшись пунктом меню File?Report.
15. Оформите отчет по лабораторной работе.
Личные задания к лабораторной работе
1. Компания предоставляет своим клиентам услуги в соответствии с заключаемым соглашениям. Вид услуги регламентирован уставом и законодательством компании. В составлении контракта участвует юрист компании.
Цель: выяснить действия, нужные для заключения и привлечения клиента с ним договора на оказание услуг.
Точка зрения: Отдел рекламы.
2. Отдел регистратуры поликлиники в конце каждого рабочего дня предоставляет бухгалтерии сводный отчет по приему больных докторами. Запись на прием больных осуществляется в соответствии с расписанию каждого доктора.
Цель: выяснить действия, нужные для учёта и ведения записи принятых больных в поликлинике.
Точка зрения: Регистратура.
3. Отдел продаж большой компьютерной компании осуществляет продажу компакт-дисков с учебными направлениями как по безналу, так и при оплате наличными клиентам. Существует совокупность скидок по типу клиента. Существует отчетная документация. Клиент обращается в отдел как лично, так и через Internet.
Цель: выяснить действия, нужные для составления отчета по выполненным продажам за отчетный период.
Точка зрения: Отдел продаж.
4. Летный завод производит летательные аппараты разной конфигурации по национальным заказам и для компаний и частных лиц. Завод осуществляет гарантийное сопровождение и техническое обслуживание.
Цель: выяснить действия отдела связи с общественностью, нужные для привлечения клиентов.
Точка зрения: Отдел связи с общественностью.
5. Научно-исследовательский отдел пищекомбината отчитывается по расходным материалам. По созданным рецептурам технолог отчитывается каждую семь дней с демонстрацией продукции перед дирекцией.
Цель: выяснить действия, нужные для составления отчета по расходу материалов при разработке новой рецептуры.
Точка зрения: Научно-исследовательский отдел.
6. Книжный магазин принимает заказы от населения на издания с условием частичной предоплаты (от 10% до 50%). На формирование количества заказа в издательстве учитывается спрос издания среди населения по категории.
Цель: выяснить действия, нужные для составления отчета по оформлению заказов за отчетный период.
Точка зрения: Отдел заказов.
7. Библиотека института включат издания разных лет. Каждые два года выполняется списание и ревизия пособий с учетом потребности в учебном ходе. Для учителей кафедр публикуются сводки и отчеты.
Цель: выяснить действия, нужные для отчётов и составления сводок по наличию пособий и их востребованности среди студентов.
Точка зрения: Отдел комплектования.
8. Компьютерная компания предоставляет населению кроме Интернет–одолжений сопровождение ПО и обслуживание ВТ. Для привлечения клиентов употребляется совокупность скидок. За отчетный период клиентам выставляется счет с описанием сделанных одолжений.
Цель: выяснить действия, нужные для выставления счета клиенту.
Точка зрения: Бухгалтерия.
9. галерея исскуства иногда проводит распродажи и выставки персоналий художественных произведений. Информация как публикуется, так и рассылается постоянным клиентам галереи.
Цель: выяснить действия, нужные для оповещения потенциальных визитёров выставки.
Точка зрения: Организатор выставки.
10. Редколлегия газеты для оплаты собственных обозревателей применяет совокупность рейтинга статей и учёта публикаций среди критиков и читателей. Раз в тридцать дней подводятся итоги и выплачиваются премии.
Цель: выяснить действия, нужные для назначения премий и ведения рейтинга.
Точка зрения: Редколлегия.
11. Представьте в виде ER-диаграммы структуру «футбольной» базы данных, охватывающей данные о командах, об игроках и о болельщиках, включая следующие атрибуты:
1) для каждой команды — наименование, список Ф.И.О. игроков, Ф.И.О. капитана (из игроков), цвета формы, количество сезонов, сыгранных в чемпионате, количество сыгранных матчей, количество забитых и пропущенных мячей;
2) для каждого игрока — Ф.И.О, номер, число сыгранных матчей, количество забитых мячей;
3) для каждого болельщика — Ф.И.О., наименование команды, Ф.И.О. любимого игрока и предпочитаемый цвет.
12. Разглядите проект базы данных банка, содержащей данные о состоянии и клиентах их квитанций. Информацию о клиенте включают его имя, адрес, идентификационный номер и номер телефона плательщика налогов (ИНН). Счет описывается атрибутами номера, типа (к примеру, «накопительный», «чековый» и т.п.) и остатка. Нужно кроме этого отразить в базе данных факт принадлежности счета определенному клиенту.
Цель: выяснить действия, нужные для ведения мониторинга количества открытых клиентом квитанций.
Точка зрения: Отдел по работе с частными лицами.
Выполните предстоящую модификацию диаграммы, предусматривая, что клиент может иметь пара адресов, а за каждым адресом закреплено множество номеров телефонов.
13. Разглядите проект базы данных банка, содержащей данные о состоянии и клиентах их квитанций. Информацию о клиенте включают его имя, адрес, идентификационный номер и номер телефона плательщика налогов (ИНН). Счет описывается атрибутами номера, типа (к примеру, «накопительный», «чековый» и т.п.) и остатка. Нужно кроме этого отразить в базе данных факт принадлежности счета определенному клиенту.
Цель: выяснить действия, нужные для ведения мониторинга количества операций на открытых клиентом квитанциях.
Точка зрения: Отдел по работе с частными лицами.
Выполните предстоящую модификацию диаграммы, добавив к схеме данные об операциях со счетом: дата операции, период (окончание и начало) транзакции, тип операции (снятие, зачисление), сумму, кассир, совершивший эту операцию. Для каждого кассира учитывается следующие сведения: ФИО, домашний адрес, телефон, пол, образование, дата приемки на работу в данный банк.
14. Разглядите проект базы данных банка, содержащей данные о состоянии и клиентах их квитанций. Информацию о клиенте включают его имя, адрес, идентификационный номер и номер телефона плательщика налогов (ИНН). Счет описывается атрибутами номера, типа (к примеру, «накопительный», «чековый», «карт-счет» и т.п.) и остатка. Нужно кроме этого отразить в базе данных факт принадлежности счета определенному клиенту.
Цель: выяснить действия, нужные для ведения мониторинга количества операций на открытых клиентом карт-квитанциях.
Точка зрения: Отдел по работе с карточными квитанциями частных лиц.
Выполните предстоящую модификацию диаграммы предположив, что для каждого счета существует пара карт-квитанций (пластиковых карточек). Для каждой карточки существует собственный номер, срок действия, размер годового процента за пользование картой, и указаны большой и минимальный ограничения. По каждому карт-счету существуют операции (дата операции, тип операции, сумма).
15. Разглядите проект базы данных банка, содержащей данные о состоянии и клиентах их квитанций. Информацию о клиенте включают его имя, адрес, идентификационный номер и номер телефона плательщика налогов (ИНН). Счет описывается атрибутами номера, типа (к примеру, «накопительный», «чековый», «карт-счет» и т.п.) и остатка. Нужно кроме этого отразить в базе данных факт принадлежности счета определенному клиенту. Банк имеет список одолжений, каковые он может предоставлять населению. Любая услуга характеризуется наименованием и уникальным кодом. У банка имеется пара филиалов, каковые имеют следующие характеристики: наименование филиала, ФИО управляющего, телефон, адрес. Любой филиал может предоставлять лишь одну услугу из того списка, что имеет головной банк.
Цель: выяснить действия, нужные для ведения мониторинга эффективности предоставления клиентам банка имеющихся у него одолжений.
Точка зрения: Отдел по работе с частными лицами.
Контрольные вопросы к защите отчета по лабораторной работе.
1. Каковы задачи, решаемые на этапе концептуального проектирования?
2. Дайте чёрта модели типа «сущность – сообщение».
3. Обрисуйте узнаваемые формы представления данных.
4. Какое назначение имеет информационная (концептуальная) модель в ходе проектирования автоматизированной системы обработки данных?
5. Перечислите главные составляющие информационной (концептуальной) модели.
6. В чем состоит отличие элемента типа сущности и понятия сущности?
7. Каковы методы представления сущности?
8. Обрисуйте правила формирования сущностей (типы, элементы, нумерация, обозначение).
9. Каковы правила атрибутов?
10. Как классифицируются атрибуты?
11. Каковы фундаментальные виды связей?
12. Как формализуется сообщение 1:1?
13. Как формализуется сообщение 1:M?
14. Как формализуется сообщение M:N?
15. Обрисуйте правила создания взаимоотношений (направление, тип, обозначение).
16. Что такое подтип и супертип?
17. Объясните порядок и принцип работы создание дискриминатора.
Перечень литературы
1. Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. CASE-технологии. Практикум. – М.: Горячая линия – Телеком, 2003. – 160 с.
2. Черемных С.В., Семенов И.О., Ручкин В.С. анализ и Моделирование совокупностей. IDEF-технологии: практикум. – М.: статистика и Финансы, 2002. – 192 с.
3. Черемных С.В., Семенов И.О., Ручкин В.С. Структурный анализ совокупностей: IDEF-разработка. – М.: статистика и Финансы, 2001. – 208 с.
Приложение