close

Вход

Забыли?

вход по аккаунту

?

Grishanova

код для вставкиСкачать
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное
образовательное учреждение высшего образования
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ
ПРОЕКТИРОВАНИЕ ТРАНСПОРТНЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ
Методические указания
к выполнению лабораторных работ
Санкт-Петербург
2017
Составители – Л. И. Гришанова
Рецензент – А. Н. Гардюк
Рассмотрен процесс проектирования информационных систем предприятия с применением средств автоматизации моделирования бизнес-процессов и проектирования информационных систем.
Могут быть рекомендованы к использованию в учебном процессе по направлениям подготовки бакалавров: 23.03.01 – Технология транспортных
процессов, 27.03.03 – Системный анализ и управление, и по направлениям
магистратуры 23.04.01 – Технология транспортных процессов, 27.04.04 –
Управление в технических системах, а также для смежных направлений и
специальностей.
Публикуется в авторской редакции.
Компьютерная верстка С. Б. Мацапуры
Сдано в набор 8.12.17. Подписано к печати 21.12.17.
Формат 60×84 1/16. Усл. печ. л. 2,3.
Уч.-изд. л. 2,5. Тираж 50 экз. Заказ № 547.
Редакционно-издательский центр ГУАП
190000, Санкт-Петербург, Б. Морская ул., 67
© Санкт-Петербургский государственный
университет аэрокосмического
приборостроения, 2017
Введение
Сегодня менеджерам транспортных предприятий приходится
решать разные, требующие соответствующего информационного
обеспечения, оперативно-тактические и стратегические задачи – от
правовых и учетных, до аналитических и проектных.
Информационные системы (ИС) на транспортных предприятиях выполняют функции управления перевозками грузов и пассажиров, техническим обслуживанием и ремонтом транспортных
средств, прокатом техники, формированием и оптимизацией маршрутов.
Под информационными системами [1] понимают совокупность
данных, программного обеспечения, систем управления базами
данных и операционных платформ. Основу ИС транспортных компаний составляет программное обеспечение, используемое для комплексного учета, сбалансированного планирования и управления
бизнес-процессами, а также сервисное программное обеспечение,
расширяющее возможности ИС. Наряду с универсальными ИС [2],
которые имеют высокую цену и выполняют только стандартные
функции, транспортным предприятиям часто необходима разработка своей ИС, предназначенной для решения узкого круга задач.
На начальных этапах процесса проектирования ИС выполняется
анализ и описание бизнес-процессов предметной области. Обычно,
исправление ошибок, допущенных на предыдущей стадии, обходится примерно в 10 раз дороже, чем на текущей, откуда следует,
что наиболее критическими являются первые стадии проекта [3].
Основное назначение средств моделирования бизнес-процессов – обеспечение понимания функционирования предприятия на
всех уровнях организации. Бизнес-модель даёт целостную картину жизнедеятельности организации, согласовывает разные точки
зрения на постоянно развивающуюся деятельность компании. Для
наглядной демонстрации бизнес-процессов организации, анализа
её архитектуры в целом и принятия решений об оптимизации её
деятельности имеются специальные методики и языки моделиро3
вания, применение которых становится особенно актуальным при
создании информационной системы (ИС) предприятия.
Цель лабораторных работ – проектирование информационной
системы предприятия с применением средств автоматизации моделирования бизнес-процессов и проектирования информационных
систем.
Процесс проектирования информационных систем
Проект ИС – проектно-конструкторская и технологическая документация, в которой представлено описание проектных решений
по созданию и эксплуатации ИС в конкретной программно-технической среде.
Процесс проектирования в жизненном цикле ИС в соответствии с
применяемым в нашей стране ГОСТ 34601-90 «Автоматизированные
системы стадии создания» [3], делится на следующие семь стадий:
– исследование и обоснование создания системы;
– разработка технического задания;
– создание эскизного проекта;
– техническое проектирование;
– рабочее проектирование;
– ввод в действие;
– функционирование, сопровождение, модернизация.
На указанных стадиях выполняются следующие этапы проектирования ИС:
1 – Этап «Предпроектной стадии»: сбор материалов обследования; анализ материалов обследования и разработка технико-экономического обоснования (ТЭО) и технического задания (ТЗ).
2 – «Техническое и рабочее проектирование» выполняется в два
этапа:
– техническое проектирование – выполняются работы по логической разработке и выбору наилучших вариантов проектных решений, в результате чего создается «Технический проект»;
– рабочее проектирование – физическая реализация выбранного
варианта проекта и получение документации «Рабочего проекта».
3 – «Внедрение проекта» включает в себя три этапа:
– подготовка объекта к внедрению проекта – осуществляются
работы по подготовке предприятия к внедрению разработанного
проекта ИС;
– опытное внедрение проекта – осуществляют проверку правильности работы составных частей проекта и получают исправ4
ленную проектную документацию и «Акт о проведении опытного
внедрения»;
– сдача проекта в промышленную эксплуатацию – осуществляется комплексная системная проверка всех частей проекта, в результате которой получают доработанный «Рабочий проект» и «Акт
приемки проекта в промышленную эксплуатацию».
4 – «Эксплуатация и сопровождение проекта» включает этапы:
– эксплуатация проекта – получают информацию о работе всей
системы в целом и отдельных ее компонентов и собирают статистику о сбоях системы в виде рекламаций и замечаний, которые накапливаются для выполнения следующего этапа;
– сопровождение и модернизация проекта – ликвидируются последствия сбоев в работе системы и исправляются ошибки, не выявленные при внедрении проекта. В процессе модернизации проект
либо дорабатывается, т. е. расширяется по составу подсистем и задач, либо производится перенос системы на другую программную
или техническую платформу с целью адаптации ее к изменяющимся
внешним и внутренним условиям функционирования, в результате
чего получают документы модернизированного «Рабочего проекта».
Целью начальных этапов создания ИС, выполняемых на стадии
анализа деятельности организации, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать процесс создания ИС,
отвечающей потребностям организации, нужно выяснить и четко
сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования заказчиков к ИС и отобразить их
на языке моделей в требованиях к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации.
Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и
тяжелых для исправления в случае ошибки.
На этапе проектирования ИС, прежде всего, формируются модели
данных. Проектировщики в качестве исходной информации получают результаты анализа. Построение логической и физической моделей данных является основной частью проектирования базы данных.
Полученная в процессе анализа информационная модель сначала
преобразуется в логическую, а затем в физическую модель данных.
Для моделирования бизнес-процессов на предприятии используется несколько различных методов [4-6], основой которых являются как структурный, так и объектно-ориентированный подходы к
моделированию. Однако деление самих методов на структурные и
5
объектные является достаточно условным, поскольку наиболее развитые методы используют элементы обоих подходов. К числу наиболее распространенных методов относятся:
– метод функционального моделирования IDEF0;
– метод моделирования процессов IDEF3;
– моделирование потоков данных DFD;
– метод ARIS.
В основе указанных методов лежит методология SADT разработанная Дугласом Россом [5].
Моделирование бизнес-процессов
Семейство стандартов IDEF
IDEF – методологии семейства ICAM (Integrated Computer-Aided
Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности
широкого спектра сложных систем в различных разрезах [4]. При
этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.
В настоящий момент к семейству IDEF можно отнести следующие стандарты:
– IDEF0 – методология функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора
взаимосвязанных функций (функциональных блоков – в терминах
IDEF0). Как правило, моделирование средствами IDEF0 является
первым этапом изучения любой системы;
– IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их
структуру и взаимосвязи;
– IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущностьвзаимосвязь” (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;
– IDEF3 – методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью
IDEF3 описываются сценарий и последовательность операций для
каждого процесса. IDEF3 имеет прямую взаимосвязь с методологи6
ей IDEF0 – каждая функция (функциональный блок) может быть
представлена в виде отдельного процесса средствами IDEF3;
– IDEF5 – методология онтологического исследования сложных
систем. С помощью методологии IDEF5 онтология системы может
быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные
утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о
дальнейшем развитии системы и производится её оптимизация.
– DFD – Data Flow Diagram – диаграмма потоков данных и используется для описания процессов верхнего уровня и для описания реально существующих в организации потоков данных.
При выполнении лабораторных работ для анализа бизнес-процессов предприятия применяются методы IDEF0, IDEF3 и DFD, а
также IDEF1X для моделирования структуры данных информационной системы.
7
ЛАБОРАТОРНЫЕ РАБОТЫ
Цель лабораторных работ – проектирование информационной
системы предприятия. На начальных этапах процесса проектирования ИС выполняется анализ и описание бизнес-процессов предметной области с использованием средств моделирования.
Весь цикл лабораторных работ выполняется для одного предприятия, выбранного в соответствии с заданием.
Лабораторная работа № 1
Цель работы – изучить структуру функционирования предприятия, сформулировать требования к проектируемой информационной системе.
Порядок выполнения работы
1. Изучить деятельность предприятия.
2. Рассмотреть его организационную структуру.
3. Собрать, проанализировать и определить потребности и возможности проектируемой информационной системы.
4. Изучить предпосылки возникновения этих потребностей.
5. Привести краткий обзор возможностей, которые должна предоставлять пользователям проектируемая ИС.
Содержание отчета
Отчет по лабораторной работе должен содержать:
– краткое описание деятельности предприятия;
– схему организационной структуры предприятия;
– описание задач, решаемых с помощью ИС;
Пример выполнения
Рассмотрим автотранспортное предприятие (АТП), которое является акционерным обществом открытого типа.
Функции АТП:
– организация и осуществление перевозок в соответствии с утвержденным планом и договорными обязательствами;
– хранение и техническое обслуживание подвижного состава;
– внедрение новой техники, совершенствование технологии производства и обеспечение высокопроизводительной работы подвижного состава;
8
– организация труда и заработной платы;
– подбор, расстановка и учеба кадров;
– материально-техническое снабжение АТП эксплуатационными и ремонтными материалами;
– рациональное использование основных и оборотных средств.
Рассмотрим схему организационной структуры (рис. 1.1).
Предприятие возглавляет генеральный директор, который организует всю работу предприятия и несет полную ответственность за
его состояния и деятельность перед государством и трудовым коллективом. Главный инженер руководит работой технических служб
предприятия, несет ответственность за выполнением плана, качеством автомобильных перевозок, использованием новейшей техники и технологии.
Начальник
АТП
Главный
инженер
Зам. начальника
по эксплуатации
Зам. начальника
по экономике
РММ
Отдел
эксплуатации
ПЭО
Бухгалтерия
ПТО
Подвижной
состав
ОТиЗ
Отдел
кадров
ОТК
Служба БД
АХО
ОГМ
ОМТС
Гаражная
служба
Рис. 1.1. Организационная структура автотранспортного предприятия:
РММ – ремонтно-монтажные мастерские, ПТО – плановотехнический отдел, ОТК – отдел технического контроля,
ОГМ – отдел главного механика, ОМТС – отдел материальнотехнического снабжения, ПЭО – планово-экономический отдел,
ОТиЗ – отдел труда и зарплаты
9
Отдел начальника по эксплуатации вместе с подчиненными ему
подразделениями обеспечивает контроль за работой и наладку технологического оборудования, проводит все виды ремонта технологического оборудования, а также монтаж нового и демонтаж устаревшего оборудования также обеспечивает бесперебойное снабжение
предприятия электроэнергией, теплотой, сжатым воздухом, водой,
кислородом и другим. Проводит планирование и осуществляет ремонт энергетического оборудования, разрабатывает и осуществляет
мероприятия по реконструкции, техническому перевооружению и
перспективному развитию энергетического хозяйства предприятия, проводит нормирование расходов электроэнергии, теплоты, топлива, сжатого воздуха и др., а также мероприятия по их экономии.
Отдел технического контроля осуществляет контроль качества перевозок, разрабатывает предложение по предупреждению
и уменьшению простоев автомобильного транспорта, организует
контроль качества поступающих на предприятие автотранспортных средств и запасных частей к ним. Качество перевозок является
определяющим фактором в общей оценке результатов деятельности
трудового коллектива.
Главный экономист, являющийся заместителем директора по
экономике, руководит работой по планированию и экономическому стимулированию на предприятии, повышению производительности труда, выявлению и использованию производственных резервов улучшению организации производства, труда и заработной
платы, организации внутризаводского хозрасчета и др. Ему могут
подчиняться планово-экономический отдел, отдел труда и заработной платы.
Бухгалтерия осуществляет учет средств предприятия и хозяйственных операций с материальными и денежными ресурсами,
устанавливает результаты финансово-хозяйственной деятельности
предприятия и др.
Отдел кадров разрабатывает штатное расписание, составляет
годовые, квартальные, и месячные планы по труду и заработной
плате и осуществляет контроль за их выполнением, разрабатывает
мероприятия по повышению производительности труда, внедрению
прогрессивных систем заработной платы, разрабатывает положение об образовании и расходовании фонда материального поощрения, разрабатывает технически обоснованные нормы выработки и
проводит анализ их выполнения, организует и участвует в разработке вопросов научной организации труда, содействует движению
за коллективную гарантию трудовой и общественной дисциплины.
10
Для данного предприятия проектируется информационная система, в процессе разработки которой поставлены следующие задачи: построить модели бизнес-процессов в нотациях IDEF0, IDEF3
и DFD, разработать модель структуры данных в стандарте IDEF1X
(ER – диаграмму), реализовать физическое проектирование базы
данных.
Лабораторная работа № 2
Цель работы – моделирование бизнес-процессов предприятия в
стандарте IDEF0.
Для выполнения лабораторной работы (так же, как и лабораторных работ 3 и 4) может быть использован пакет прикладных программ BPWIN или любой другой пакет, содержащий средства моделирования бизнес-процессов по согласованию с преподавателем.
Порядок выполнения работы
1. Исследовать бизнес-процессы на предприятии.
2. Построить модель бизнес-процессов в нотации IDEF0.
3. Проанализировать полученный результат.
Методические рекомендации
Метод функционального моделирования IDEF0
В основе методологии IDEF0 (Integration Definition for Function
Modeling) лежит методология SADT разработанная Дугласом Россом. Методология IDEF0 представляет собой совокупность методов,
правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF0 отображает функциональную структуру
объекта, т. е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на
следующих концепциях:
1. Графическое представление блочного моделирования. Графика блоков и дуг IDEF0-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие
блоков друг с другом описываются посредством интерфейсных дуг,
выражающих «ограничения», которые в свою очередь определяют,
когда и каким образом функции выполняются и управляются.
11
2. Строгость и точность. Выполнение правил IDEF0 требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика.
Правила IDEF0 включают:
– ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
– связность диаграмм (номера блоков);
– уникальность меток и наименований (отсутствие повторяющихся имен);
– синтаксические правила для графики (блоков и дуг);
– разделение входов и управлений (правило определения роли
данных);
– отделение организации от функции, т. е. исключение влияния
организационной структуры на функциональную модель.
Результатом применения методологии IDEF0 является модель,
которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки
и дуги (рис. 2.1). Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны.
Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.
Одной из наиболее важных особенностей IDEF0 является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель
Построение IDEF0-модели начинается с представления всей системы в виде простейшей компоненты – одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единУправление
Входы
Функция
Выходы
Рис. 2.1. Функциональный блок и интерфейсные дуги
в диаграмме IDEF0
12
ственный блок представляет всю систему как единое целое, имя,
указанное в блоке, является общим. Это верно и для интерфейсных
дуг – они также представляют полный набор внешних интерфейсов
системы в целом.
Затем блок, который представляет систему в качестве единого
модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых
представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления.
Модель IDEF0 представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные
части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая
детальная диаграмма является декомпозицией блока из более общей
диаграммы. На каждом шаге декомпозиции более общая диаграмма
называется родительской для более детальной диаграммы.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что
блок и диаграмма представляют одну и ту же часть системы.
На IDEF0 – диаграммах не указаны ни последовательность, ни
время. Обратные связи, итерации, продолжающиеся процессы и
перекрывающиеся (по времени) функции могут быть изображены с
помощью дуг. Обратные связи (рис. 2.2–2.3) могут выступать в виде
комментариев, замечаний, исправлений и т. д.
Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы – AS-IS (как есть). Модель AS-IS
позволяет выяснить, какие процессы функционируют на предприятии сегодня. Анализ функциональной модели позволяет понять,
где находятся наиболее слабые места, в чем будут состоять преимущества новых автоматизированных процессов и насколько глубоким изменениям подвергнется существующая структура организации работы предприятия. Детализация бизнес-процессов позволяет
выявить недостатки организации даже там, где функциональность
на первый взгляд кажется очевидной. Признаками неэффективной
деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный, отсутствие обратных связей по
управлению (на проведение работы не оказывает влияния ее резуль13
Системные
требования
Комментарии
Проект
с предварительной
спецификацией
Разработка
проекта
1
Слабо
структурированный
проект
Улучшенный
проект
Экспертиза
2
Системный
аналитик
САПР
Рис. 2.2. Фрагмент IDEF0 – диаграммы с обратной связью по управлению
Системные
требования
Проект
с предварительной
спецификацией
Разработка
проекта
Слабо
структурированный
проект
1
Улучшенный
проект
Опытный
образец
Прототипирование
2
САПР
Системный
аналитик
Рис. 2.3. Фрагмент IDEF0-диаграммы с обратной связью по механизму
тат) и т. д. Найденные в модели AS-IS недостатки можно исправить
при создании модели ТО-ВЕ (как будет) – модели новой организации
бизнес-процессов. Модель ТО-ВЕ нужна для анализа альтернативных путей выполнения работы и документирования того, как компания будет делать бизнес в будущем. На рис. 2.4. представлен при14
15
Конструкторы
3
Техническое
проектирование
Проектировщики
Системные
аналитики
Техническое
задание
Подготовка
эскизного
проекта
2
Требования
к аппаратнопрограммным
средствами САПР
Испытатели
4
Комплексирование
изделия
Рабочий проект
изделия
Рабочее
проектирование
Технический
проект
изделия
5
Опытный
образец
Рис. 2.4. Пример IDEF0 диаграммы. «Этапы процесса проектирования авиационного прибора управления»
Исходные
данные
проектируемого
изделия
Подготовка
технического
задания
1
Требования ГОСТа
мер IDEF0 – диаграммы, представляющей процесс проектирования
прибора или системы управления (ПСУ).
Методика выполнения работы
Рассмотрим методику выполнения работы с применением пакета
прикладных программ BPWIN:
Создать новую IDEF0 – диаграмму. Дать файлу краткое название по моделируемому процессу, например «Доставка груза».
Переименовать текущую страницу, дав ей название «А0 контекст».
Разместить на странице блок заголовка. Задать для него параметры: узел – А0; Заголовок – Название моделируемого процесса;
Разместить блок действия (рамку). Задать для него параметры:
Имя процесса – Краткое название основной (профильной) деятельности предприятия, например: «Перевозка грузов»; Идентификатор процесса – А0; Идентификатор подчиненной схемы можно не
задавать. Если необходимо изменить параметры функционального
блока, нужно щелкнуть по нему правой кнопкой мыши и выбрать
команду меню «Задать сведения о процессе».
Разместить стрелки («Односторонний соединитель» из набора
элементов IDEF0), так как показано на рис. 2.5. Задать для стрелок
подпись, один или два раза щелкнув по ним и набрав соответствующий текст.
Добавить новую страницу, переименовать ее в «А0 декомпозиция» и установить для нее ориентацию «Альбомная». Поместить
Управление
Вход
Перевозка
грузов
Выход
A0
Механизм
Рис. 2.5. Схематичное представление
контекстной диаграммы
16
блок заголовка, задав для него параметры: Узел – А0; Заголовок –
Название декомпозируемого функционального блока.
Разместить элементы «Блок действия» в направлении от верхнего левого угла к нижнему правому, как показано на рис. 2.6. Для
каждого из этих элементов задать идентификатор, соответствующий номеру блока (например: А1, А2 и т. д.), а в качестве заголовка блока дать название соответствующей функции. Разместить на
странице элементы «Односторонний соединитель» в необходимом
количестве. Направить их на вход первого блока, на управления,
механизмы и выходы.
Стрелки сверху (Управление) должны соответствовать региональному и федеральному законодательству, а также нормативным
документам предприятия в рассматриваемой предметной области.
Стрелки снизу должны обозначать исполнителей конкретной функции, а также используемое для этого программное и аппаратное
обеспечение.
Для соединения функциональных блоков между собой на диаграмме декомпозиции нужно использовать элемент «Соединительная
линия IDEF0». Например, выход некоторого функционального блока
является входом для последующего, и соответствующим образом они
должны быть соединены. Для создания разветвляющегося потока (например, механизма) необходимо поместить элемент «Односторонний
соединитель», добавить на него точку соединения, поместить элемент
«Соединительная линия IDEF0», конец которого (стрелку) соединить
с соответствующей стороной соединяемого блока, а начало направить
на созданную точку соединения для одностороннего соединителя.
Для подписи стрелок на диаграмме декомпозиции можно использовать элемент «Подпись» из набора элементов IDEF0.
Важно помнить, что в стандарте IDEF0 допускается разветвление потоков, но не альтернатива. Например, в обобщенной схеме,
представленной на рис. 2.6, выходной поток «Выход 3» разветвляется на два: «Выход 4» и «Выход 5». Но в любом случае существует выходной поток «Выход 5», являющийся входом для «Функции 4», которая обязательно должна быть выполнена. Аналогично выходной
поток «Выход 7» формируется из трех потоков: «Выход 2», «Выход
4» и «Выход 6». Например, на выходе каждой функции формируются определенные документы, которые в совокупности образуют
некоторый набор документов соответствующий «Выходу 7».
Если предприятие большое, и рассматриваемый процесс сложен
и многообразен, то можно произвести еще одну декомпозицию до
третьего уровня, выполнив аналогичные действия.
17
18
Вход
Механизм 1
Управление 3
Механизм 2
Выход 5
Механизм 3
A3
Вход 2 Функция 3 Выход 3
A2
Функция 2 Выход 2
Выход 1
Управление 2
A4
Выход 6
Выход 7
Управление 4
Функция 4
Выход 4
Рис. 2.6. IDEF0-диаграмма первого уровня
A1
Функция 1
Механизм
Вход 1
Управление 1
Управление
19
Груз на
перевозку
0р
Персонал
0р
Груз
Транспортные
средства
3
Комплект
Отправка груза документов
Грузополучателю
Рис. 2.7. Пример диаграммы IDEFO «Организация грузоперевозки»
Бухгалтера
2
Водительэкспедитор
Составление комплекта
документов на
грузоперевозку
Путевой лист
0р
Направление на
оформление
дополнительных
документов
1
Планирование
Перевозки
Логистыаналитики
Заказ на
грузоперевозку
12. Произвести предварительный анализ всех диаграмм на согласованность с помощью команд меню «Процесс» (для MS Visio
2010). Данная группа команд меню появляется, если выбрать категорию элементов «Схема IDEF0». По возможности устранить найденные программой недостатки
Произвести анализ недостатков существующей модели (наличие
лишних блоков и отсутствие необходимых; наличие лишних стрелок и отсутствие необходимых; дублирование функций, нерациональность связей и т. п.)
Содержание отчета
Отчет по лабораторной работе должен содержать:
– краткую характеристику выбранного бизнес-процесса;
– контекстную IDEF0 – диаграмму бизнес-процессов;
– IDEF0 – диаграммы декомпозиции;
– выводы о полученных результатах.
На рис. 2.7 приведен пример IDEFO-диаграммы «Организация
грузоперевозки»
Лабораторная работа № 3
Цель работы – моделирование бизнес-процессов предприятия в
стандарте IDEF3.
Диаграмма в стандарте IDEF3 позволяет учитывать в модели параллельные процессы, например, оформление документа по результатам процесса.
Методические рекомендации
Метод моделирования процессов IDEF3
IDEF3 (Integration Definition for Function Modeling) является
технологией, хорошо приспособленной для сбора данных, требующихся для проведения структурного анализа системы.
В отличие от большинства технологий моделирования бизнеспроцессов, IDEF3 не имеет жестких синтаксических или семантических ограничений, делающих неудобным описание неполных
или нецелостных систем. Кроме того, автор модели избавлен от необходимости смешивать свои собственные предположения о функционировании системы с экспертными утверждениями в целях заполнения пробелов в описании предметной области.
20
IDEF3-моделирование органично дополняет традиционное моделирование с использованием методологии IDEF0. В настоящее
время оно получает все большее распространение как вполне жизнеспособный путь построения моделей проектируемых систем для
дальнейшего анализа имитационными методами.
Основой модели IDEF3 служит так называемый сценарий бизнес-процесса, который выделяет последовательность действий или
подпроцессов анализируемой системы. Поскольку сценарий определяет назначение и границы модели, довольно важным является
подбор подходящего наименования для обозначения действий. Для
подбора необходимого имени применяются стандартные рекомендации по предпочтительному использованию глаголов и отглагольных существительных, например «обработать заказ клиента» или
«применить новый дизайн».
Сценарий для большинства моделей должен быть документирован. Обычно это название набора должностных обязанностей человека, являющегося источником информации о моделируемом процессе.
Главной организационной единицей модели IDEF3 является диаграмма. Взаимная организация диаграмм внутри модели IDEF3
особенно важна в случае, когда модель заведомо создается для последующего опубликования или рецензирования, что является
вполне обычной практикой при проектировании новых систем.
В этом случае системный аналитик должен позаботиться о таком
информационном наполнении диаграмм, чтобы каждая из них
была самодостаточной и в то же время понятной пользователю.
Диаграммы IDEF3 отображают действие в виде прямоугольника.
Каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если
в процессе построения модели действие удаляется. В диаграммах
IDEF3 номер действия обычно предваряется номером его родителя.
Связи выделяют существенные взаимоотношения между действиями. Все связи в IDEF3 являются однонаправленными, и хотя
стрелка может начинаться или заканчиваться на любой стороне
блока, обозначающего действие, диаграммы IDEF3 обычно организуются слева направо таким образом, что стрелки начинаются на
правой и заканчиваются на левой стороне блоков.
Связь типа «временное предшествование». Связи этого типа показывают, что исходное действие должно полностью завершиться,
прежде чем начнется выполнение конечного.
Связь типа «объектный поток». Одна из наиболее часто встречающихся причин использования связи типа «объектный поток» за21
ключается в том, что некоторый объект, являющийся результатом
выполнения исходного действия, необходим для выполнения конечного действия.
Связь типа «нечеткое отношение». Связи этого типа используются для выделения отношений между действиями, которые невозможно описать с использованием предшествующих или объектных
связей. Значение каждой такой связи должно быть определено, поскольку связи типа «нечеткое отношение» сами по себе не предполагают никаких ограничений. Одно из применений нечетких отношений – отображение взаимоотношений между параллельно выполняющимися действиями.
В табл. 3.1. приведены основные «строительные блоки» для диаграмм IDEF3.
Таблица 3.1
Объекты диаграммы IDEF3
№
Наименование
1
Единица
работы
(Unit of Work)
Описание
Графическое
представление
Объект служит для описания
функций (процедур, работ), выполняемых
подразделениями/
сотрудниками предприятия
2 Объект ссылки Объект, используемый для описа(Referents)
ния ссылок на другие диаграммы
модели, циклические переходы в
рамках одной модели, различные
комментарии к функциям
Связи (Links) – Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей
Связь предПоказывает, что прежде чем начшествования
нется работа-приемник, должна
(Precedence)
завершиться работа-источник.
Обозначается сплошной линией
Связь
Показывает связь между двумя
отношения
работами или между работой и
(Relational)
объектом ссылки. Обозначается
пунктирной линией
Поток
Показывает участие некоторого
объектов
объекта в двух или более рабо(Object Flow)
тах, как, например, если объект
производится в ходе выполнения одной работы и потребляется другой работой. Обозначается
стрелкой с двумя наконечниками
22
Окончание табл. 3.1
№
Наименование
Описание
Графическое
представление
Перекрестки (Junctions) – перекрестки используются в диаграммах
IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса могущие возникнуть во
время его выполнения
Перекресток
Узел, собирающий множество
слияния (Fan- стрелок в одну, указывая на неin Junction)
обходимость условия завершенности работ-источников стрелок
для продолжения процесса
Перекресток
Узел, в котором единственная
ветвления
входящая в него стрелка вет(Fan-out
вится, показывая, что работы,
Junction)
следующие за перекрестком, выполняются параллельно или альтернативно
3 Логическое
Логический оператор, определя«И»
ющий связи между функциями в
рамках процесса. Позволяет описать ветвление процесса
4 Логическое
Логический оператор, определя«ИЛИ»
ющий связи между функциями в
рамках процесса. Позволяет описать ветвление процесса
5 Логическое
Логический оператор, определяисключающее ющий связи функциями в рам«ИЛИ»
ках процесса. Позволяет описать
ветвление процесса
В отличии от диаграмм IDEF0, в диаграммах IDEF3 завершение
одного действия может инициировать начало выполнения сразу нескольких других действий или, наоборот, определенное действие
может требовать завершения нескольких других действий до начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса.
Действия в IDEF3 могут быть разложены на составляющие для
более детального анализа. Метод IDEF3 позволяет декомпозировать
действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели. Примеры IDEF3 –
диаграммы представлены на рис. 3.1 и 3.2.
23
24
J3
Необходимо
Х
&
O
J5
J4
Не требуется
Утверждать
у главного
металлурга
5
4
J1
Утверждать
у главного
технолога
Х
О
J6
Обязанность
главного
металлурга
Обязанности
главного
технолога
O
J2
Рис. 3.1. Пример описания процесса «Утвердить технологическую документацию» в нотации IDEF3
3
2
1
Необходимо ли
утверждать
у главного
металлурга
Установить
необходимость
доработки
Зарегистрировать
в журнале отдела
главного технолога
Доработка документации
не требуется
25
Х
7
J12
Х
Необходима
доработка
J13
O
J11
Необходима доработка
Успешно
выполнено
Успешно выполнено
Успешно выполнено
Доработка
документации
не требуется
Рис. 3.2. Пример описания подпроцесса «Установить необходимость доработки» (при декомпозиции процесса
«Утвердить технологическую документацию») в нотации IDEF3.
8
Х
Сверить
расцеховку
Необходима
доработка
J10
Сверить
материалы
и нормы и расхода
Главный технолог выполняет
доработку в рамках своих
полномочий
6
Проверить
в отделе
главного технолога
Проверяемая документация
Порядок выполнения работы
1. Используя IDEF0 – диаграмму, полученную в процессе лабораторной работы № 2, построить модель бизнес-процессов в стандарте IDEF3.
2. Проанализировать полученный результат.
Содержание отчета
Отчет по лабораторной работе должен содержать:
– IDEF3 – диаграммы;
– выводы о полученных результатах.
Лабораторная работа № 4
Цель работы – моделирование бизнес-процессов предприятия в
стандарте DFD.
Методические рекомендации
Моделирование потоков данных DFD
Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы
потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Чаще всего диаграммы DFD используют в
качестве дополнения модели бизнес-процессов, выполненной в IDEF0.
Объекты DFD диаграмм показаны в табл. 4.1.
На рис. 4.1. представлена DFD диаграмма «Отгрузка и снабжение комплектующих и скомпонованных изделий»
В диаграммах потоков данных все используемые символы складываются в общую картину, которая дает четкое представление о
том, какие данные используются, и какие функции выполняются
системой документооборота. Хранилища данных соответствуют
тем хранилищам, которые либо уже существуют, либо которые
нужно создать.
Порядок выполнения работы
1. Используя IDEF0 и IDEF3 – диаграммы, полученные в процессе лабораторных работ № 2 и № 3, построить модель бизнес-процессов в стандарте DFD.
26
27
2
Специалисты
отдела
снабжения
3
Руководитель
отдела
снабжения
9
5
Заказчики
3
Готовая
продукция
Данные
об отгрузке
Список
заказов
Отгрузка готовой
продукции
Изделия
и комплектующие
по накладной
4
Специалисты
по работе
с клиентами
2
Снабжение
необходимыми
комплектующими
Изделия
и комплектующие
со склада
Список
2 комплектующих
7
Рис. 4.1. Пример DFD-диаграммы «Отгрузка и снабжение комплектующих и скомпонованных изделий»
1
Поставщики
Комплектующие
от поставщиков
1
Хранение
комплектующих
и скомпонованных
изделий
Скомпонованные
изделия
Список
1 скомпонованных изделий
Таблица 4.1
Объекты диаграммы IDEF3
№
Наименование
Описание
1
Работа
(Activity)
Объект обозначает функции или
процессы, которые обрабатывают
и изменяют информацию
2
Информационный поток
(Precedence)
Внешняя
ссылка
(External
reference)
Объект обозначает информационный поток от объекта-источника к объекту-приемнику
Указывают на место, организацию или человека, которые
участвуют в процессе обмена информацией с системой, но располагаются за рамками этой диаграммы
Хранилища данных представляют собой собственно данные, к
которым осуществляется доступ,
эти данные также могут быть созданы или изменены работами. На
одной диаграмме может присутствовать несколько копий одного
и того же хранилища данных
3
4
Хранилище
данных (Data
store)
Графическое
представление
2. Проанализировать полученный результат.
Содержание отчета
Отчет по лабораторной работе должен содержать:
– DFD – диаграмму;
– выводы о полученных результатах.
Лабораторная работа № 5
Цель работы – моделирование структуры данных информационной системы предприятия в стандарте IDEF1X.
Модель структуры данных в стандарте IDEF1X называют ER –
диаграммой, «Сущность – Связь». Она демонстрирует таблицы базы
данных информационной системы и связи между ними.
28
Построение модели данных информационной системы
«Сущность-связь»
По результатам моделирования бизнес-процессов и исследования документооборота предприятия должна быть построена модель
предметной области, не привязанная к конкретной СУБД, понятная не только разработчикам информационной системы, но и экономистам, менеджерам и другим специалистам. В то же время модель
предметной области должна максимально точно отражать семантику предметной области [7], выявлять бизнес-правила и позволять
легко перейти к модели данных конкретной СУБД.
Такими моделями являются модели «сущность-связь». Известно несколько методологий построения моделей «сущность-связь».
Наибольшее распространение получила методология IDEF1X.
Модель «сущность-связь» строится в виде диаграммы «сущностьсвязь», основными компонентами которой являются сущности
(Entity) и связи (Relationship). Отсюда происходят часто используемые названия модели (ER-модель) и диаграммы (ER-диаграмма).
Сущность – это абстракция множества предметов или явлений
реального мира, информацию о которых надо сохранить. Все экземпляры сущности имеют одинаковые характеристики и подчиняются одним и тем же правилам поведения. Например, можно выделить
сущность Транспортное средство. Экземплярами сущности Транспортное средство будут данные о конкретных машинах. Сущность
должна иметь имя – существительное в единственном числе. Сущности обладают определенными свойствами – атрибутами. Атрибут – это абстракция одной характеристики объекта или явления
реального мира. Каждый атрибут должен иметь имя – существительное в единственном числе, и получать значение из некоторого
множества допустимых значений – домена.
У каждой сущности должен быть выделен идентификатор, или
первичный ключ. Первичный ключ – это один или несколько атрибутов, однозначно определяющих каждый экземпляр сущности.
Если первичный ключ состоит из нескольких атрибутов, то он называется составным. Первичный ключ не должен изменяться и
принимать неопределенное значение (NULL). Ключ должен быть
компактным, т. е. не содержать слишком много атрибутов. Сущность может иметь несколько потенциальных ключей, из которых
должен быть выбран первичный ключ. Иногда приходится использовать искусственный первичный ключ (некоторый номер или код),
когда ключ содержит слишком много атрибутов (в пределе каждый
29
экземпляр сущности может определяться всем множеством атрибутов). Используется также понятие внешнего ключа. Внешний
ключ – это первичный ключ другой сущности, который мигрирует
(копируется) в сущность и служит для связи сущностей. Пример
сущности показан на рис. 5.1.
Каждая сущность должна сопровождаться описанием. Описание
сущности должно объяснять ее смысл, а не то, как будет использоваться информация данной сущности. Описание должно быть ясным, полным и непротиворечивым, понятным специалистам предметной области.
Сущности и атрибуты выделяются в результате анализа требований к системе.
Связи между объектами реального мира отражаются в виде связей (отношений, ассоциаций) между сущностями. Отношение –
это ассоциация или «связь» между двумя сущностями. Отношение
представляется в модели линией, соединяющей две сущности, и
именем отношения – глагольной конструкцией, которая описывает, как две сущности зависят друг от друга. Имена сущностей, соединенные именем отношения, должны образовывать осмысленную
фразу, описывающую бизнес-правило отношения. Например, ВОДИТЕЛЬ <Работает на> Транспортное средство. В примере имя отношения показано в угловых скобках. Отношения двунаправлены,
поэтому должны иметь имена в каждом направлении. Отношение
обладает следующими свойствами:
– степень,
– направленность,
– тип,
– мощность,
– обязательность.
Транспортное
средство
Номер по порядку
Госномер
Марка
Грузоподъемность (Т)
Износ (%)
Рис. 5.1. Пример сущности
«Транспортное средство»
30
Степень отношения представляет собой число сущностей, ассоциированных с отношением. Чаще всего используются бинарные
отношения, связывающие две сущности. Унарные, или рекурсивные отношения представляют случаи, когда экземпляр сущности
связан с другим экземпляром той же самой сущности. Часто унарные или рекурсивные отношения рассматриваются как бинарные
рекурсивные отношения, связывающие экземпляр сущности с другим ее экземпляром.
Направленность отношения указывает на исходную сущность
в отношении. Сущность, из которой отношение исходит, называется родительской сущностью. Сущность, в которой отношение заканчивается, называется подчиненной (дочерней) сущностью. Направленность отношения определяется взаимосвязью между сущностями и зависит от типа и мощности отношения. В отношении
между независимой и зависимой сущностями, отношение исходит
из независимой сущности и заканчивается в зависимой сущности.
Если обе сущности независимые, отношение симметрично. В отношении один-ко-многим родительской является сущность, входящая
в отношение однократно. Отношения многие-ко-многим симметричны. Ключ родительской сущности мигрирует (повторяется) в дочерней сущности. Такой мигрировавший ключ в дочерней сущности
называется внешним ключом. Так же, внешний ключ в зависимости от типа связи может стать частью составного ключа дочерней
сущности или неключевым атрибутом дочерней сущности. С помощью внешнего ключа экземпляр дочерней сущности ссылается на
соответствующий экземпляр родительской сущности.
Отношение между двумя сущностями, или сущности самой с собой, может принадлежать к одному из следующих типов:
– идентифицирующее отношение,
– неидентифицирующее отношение,
– типизирующее отношение,
– отношение многие-ко-многим,
– рекурсивное отношение.
Каждый тип отношений определяет поведение атрибутов первичного ключа, когда они мигрируют из родительской сущности
в подчиненную.
Идентифицирующим является отношение между двумя сущностями, в котором каждый экземпляр подчиненной сущности
идентифицируется значениями атрибутов родительской сущности. Это означает, что экземпляр подчиненной сущности зависит от
родительской сущности и не может существовать без экземпляра
31
родительской сущности. В идентифицирующем отношении единственный экземпляр родительской сущности связан с множеством
экземпляров подчиненной. Атрибуты первичного ключа родительской сущности мигрируют в атрибуты подчиненной, чтобы стать
там атрибутами первичного ключа. На рис. 5.2 представлено идентифицирующее отношение между сущностями Заказ на перевозку
и Состав заказа. В сущности Заказ на перевозку использован искусственный первичный ключ ID заказа (Идентификатор заказа),
который мигрировал в дочернюю сущность Состав заказа и стал
там первичным ключом. В реальной диаграмме атрибут Заказчик,
скорее всего, будет являться мигрировавшим ключом сущности,
описывающей заказчиков. Пример рис. 5.2 показывает, что дочерняя сущность не может существовать без родительской. Этот пример также демонстрирует, как показать переменный состав заказа:
в заказ может входить произвольное количество товаров.
Неидентифицирующим называется отношение между двумя
сущностями, в котором каждый экземпляр подчиненной сущности
не зависит от значений атрибутов родительской сущности. Это означает, что экземпляр подчиненной сущности не зависит от родительской сущности и может существовать без экземпляра родительской
сущности. В неидентифицирующем отношении единственный экЗаказ на перевозку
ID Заказа
Дата Заказа
Заказчик
Состоит из / входит в
Состав заказа на перевозку
Порядковый Номер
ID заказа (FK)
Наименование груза
Вес груза
Рис. 5.2. Пример идентифицирующего отношения
«Заказ на перевозку» – «Состав заказа»
32
земпляр родительской сущности связан с множеством экземпляров
подчиненной. Атрибуты первичного ключа родительской сущности
мигрируют в подчиненную, чтобы стать там неключевыми атрибутами. На рис. 5.3 показано неидентифицирующее отношение между
сущностями Группа и Студент. Каждое из этих отношений имеет
собственный первичный ключ. Первичного ключа родительской
сущности Группа мигрировал в подчиненную сущность Студент и
стал там неключевым атрибутом.
На примере рис. 5.3 рассмотрим также понятие обязательности
отношения. Неидентифицирующее отношение называется обязательным (No Nulls), если все экземпляры дочерней сущности должны участвовать в отношении. Неидентифицирующее отношение называется необязательным (Nulls Allowed), если некоторые экземпляры дочерней сущности могут не участвовать в отношении. Очевидно, что студент должен принадлежать одной из учебных групп.
На рис. 5.4 показан пример необязательно отношения: допускается,
что сотрудник может не принадлежать ни одному из отделов.
Типизирующими называются отношения между родительской и
одной или более подчиненными сущностями, когда сущности разделяют общие характеристики. Такие отношения называются еще
Группа
Шифр группы
Шифр специальности
Состоит из / входит в
Студент
Номер зачетки
Шифр группы
Фамилия
Имя
Отчество
Пол
Рис. 5.3. Пример обязательного
неидентифицирующего отношения
33
Отдел
Номер отдела
Название
Состоит из / входит в
Сотрудник
Табельный номер
Номер отдела (FK)
Фамилия
Рис. 5.4. Пример необязательного
неидентифицирующего отношения
иерархией наследования или иерархией категорий. Типизирующие
отношения используются в том случае, когда экземпляр родительской сущности определяет различные наборы атрибутов в подчиненных сущностях. Например, имеются различные категории сотрудников, отличающиеся только небольшим количеством атрибутов (рис. 5.5). Для каждой категории необходимо указать дискриСотрудник
Табельный номер
Фамилия
Имя
Отчество
Дата рождения
Тип
Сотрудник. Тип
Постоянный
Табельный номер
Консультант
Совместитель
Табельный номер
Табельный номер
Организация
Организация
Рис. 5.5. Пример полной категории
иерархии наследования
34
Врач
Пациент
Лечит/
ID Врача
ID Пациента
лечится
Рис. 5.6. Пример связи «многие-ко-многим»
минатор – атрибут родительской сущности, показывающий, как
отличить одну категориальную сущность от другой. На рис. 5.5
дискриминатором является атрибут Тип. На рис. 5.5 показана полная категория, т. е. каждый экземпляр сущности сотрудник относится к одной из перечисленных категорий. Возможна неполная
категория, когда существуют экземпляры родительской сущности,
не имеющие соответствующих экземпляров в дочерних сущностях
(значок категории содержит одну горизонтальную линию).
Отношения многие-ко-многим возникают тогда, где один экземпляр одной сущности связан с несколькими экземплярами другой,
и один экземпляр этой другой сущности также связан с несколькими экземплярами первой сущности. Эти отношения также называют неспецифическими. Отношения многие-ко-многим используются только на логическом уровне. На физическом уровне эти отношения реализуются за счет использования ассоциативной сущности,
содержащей ключи родительских сущностей и, возможно, дополнительные атрибуты. Для большей наглядности диаграммы желательно ввести ассоциативные сущности на логическом уровне. На
рис. 5.6 показан пример связи «многие-ко-многим», а на рис. 5.7 –
пример использования ассоциативной сущности.
Врач
Пациент
ID Пациента
ID Врача
Прием у врача
ID Врача (FK)
ID Пациента
(FK)
Назначение
Рис. 5.7. Пример использования ассоциативной сущности
35
Сотрудник
Табельный номер
Сотрудник
Табельный номер
Табельный номер руководителя
(FK)
Рис. 5.8. Примеры реализации рекурсивных отношений
с использованием имени роли и без него в сущности Сотрудник
Рекурсивное отношение – это неидентифицирующее отношение между двумя сущностями, которое указывает, что экземпляр
сущности может быть связан с другим экземпляром той же самой
сущности. При рекурсивном отношении родительская и подчиненная сущности совпадают. На рис. 5.8 показаны примеры двух реализаций рекурсивного отношения для сущности Сотрудник, с использованием имени роли и без него. Имя роли показывает, какую
роль играет внешний ключ в сущности. В данном примере внешний
ключ задает табельный номер.
Мощность отношения задает максимальное число экземпляров
одной сущности, которые могут быть связаны с экземплярами другой сущности. Мощность отношения определяется для обеих сторон
отношения – для исходной и завершающей сущностей. Количество
элементов определяет максимальное количество экземпляров сущностей, участвующих в отношении, в то время как обязательность
определяет минимальное число экземпляров. Количество элементов часто выражается как один или много. Один и много могут появляться в трех различных комбинациях:
Один-к-одному (1:1) – один и только один экземпляр сущности
связан с одним и только одним экземпляром другой сущности.
Один-ко-многим (1:N) – один и только один экземпляр родительской
сущности связан со многими экземплярами подчиненной сущности.
Многие-ко-многим (M:N) – много экземпляров одной сущности
связаны со многими экземплярами другой сущности (также называется неспецифическим отношением).
В отношении один-к-одному один и только один экземпляр сущности связан с одним и только одним экземпляром другой сущности.
Это редкий случай отношения, следует рассмотреть возможность
объединения двух отношений в одно. Но, например, в отношении
сущностей Факультет и Сотрудник целесообразнее установить связь
один-к-одному, чем заносить данные о декане в сущность Факультет.
36
37
Номер накладной
Дата
Код получателя
Наименование организация
Код материально ответственного
лица
Код материала
Наименование материала
Цена за единицу
Количество
Сумма
Наименование группы материалов
Код материала
Наименование
Единица измерения
Цена за единицу
Сумма
Справочник материалов
Код материально ответственного
лица
ФИО
Номер склада
Материально ответственные лица
Рис. 5.9. ER – диаграмма информационной системы «Поставка товара»
Код получателя
Наименование организация
Юридический адрес
Телефон/факс
Расчетный счет
Получатели
Код материала
Дата
Номер приходного ордера
Количество прихода
Номер расходного документа
Количество расхода
Остаток
Товарно-транспортная накладная
Номер ордера
Дата
Код поставщика
Наименование организация
Код материально ответственного
лица
Код материала
Цена за единицу
Количество
Сумма
Код поставщика
Наименование организация
Юридический адрес
Телефон/факс
Расчетный счет
Карточки складского учёта
Приходный ордер
Поставщики
В отношении один-ко-многим один и только один экземпляр родительской сущности связан со многими экземплярами дочерней
сущности. Это наиболее распространенное отношение.
Отношение многие-ко-многим уже было рассмотрено.
Построение ER – диаграммы (схемы данных) выполняется с помощью пакета прикладных программ ERWIN [7].
Порядок выполнения работы
1. Используя DFD – диаграмму, полученную в процессе лабораторной работы № 4, построить ER – диаграмму базы данных информационной системы. Таблицы ER – диаграммы должны соответствовать объектам DFD – диаграммы «Хранилище данных» и
«Внешняя ссылка».
2. Проанализировать полученный результат.
Содержание отчета
Отчет по лабораторной работе должен содержать:
– ER – диаграмму базы данных информационной системы предприятия;
– выводы о полученных результатах.
На рис. 5.9 приведен пример ER – диаграммы, работа № 5.
Лабораторная работа № 6
Цель работы – проектирование базы данных информационной
системы предприятия.
Методические рекомендации
Проектирование базы данных информационной системы
Проектирование базы данных информационной системы выполняется на основа ER – диаграммы (работа № 5) и состоит из двух
этапов:
– проектирование структуры базы данных,
– формирование запросов к базе данных.
На первом этапе выполняется построение таблиц информационной системы и связей между ними. На втором этапе формируются
SQL запросы, предназначенные для формирования документов, необходимых для функционирования организации.
38
Проектирование базы данных может быть выполнено разными
способами по выбору преподавателя. Например:
– непосредственно на языке запросов SQL [9] под управлением
системы управления базами данных (СУЬД) MY SQL;
– с использованием phpMyAdmin [10,11], приложения написанного на PHP и обеспечивающего полноценную, в том числе удаленную, работу с базами данных MySQL через браузер;
– в среде СУБД Oracle Database 11g Express Edition, которая является свободно распространяемым программным продуктом [12];
– с помощью СУБД MS Access, которая входит в состав Microsoft
Office и достаточно популярна в небольших организаций.
Порядок выполнения работы
1. Используя ER – диаграмму, полученную в процессе лабораторной работы № 5, спроектировать таблицы базы данных.
2. Сформировать связи между таблицами, обеспечивающие целостность данных.
3. Написать запросы к базе данных, предназначенные для формирования документов, обеспечивающих функционирование предприятия.
4. Проанализировать полученный результат.
Содержание отчета
Отчет по лабораторной работе должен содержать:
Процесс создания таблиц базы данных и формирование связей
между ними.
Таблицы базы данных, а именно, название таблицы и наименования и типы данных полей таблицы.
Процесс проектирования запросов к базе данных.
Пример работы с базой данных.
Выводы о полученных результатах.
39
Литература
1. ИТ в транспортной отрасли 2015. Александр Гольцов: транспортной
отрасли требуется автоматизация буквально каждого процесса. URL: http://
www.cnews.ru/reviews/transport_2015/interviews/aleksandr_goltsov_7/
(дата обращения: 10.08.2017).
2. ГОСТ 34.601­90 Информационная технология. Комплекс стандартов
на автоматизированные системы.
3. Маклаков С. В. Создание информационных систем с AllFusion Modeling
Suite. 2­е изд., доп. М.: Диалог-МИФИ, 2007. 400 с.
4. Марка Дэвид А., МакГоуэн Клемент Л. Методология структурного
анализа и проектирования SADT. М.: МетаТехнология, 1993. 240 с.
5. Верников Г. Г. Основные методологии обследования организаций. URL:
http://www.cfin.ru/vernikov/idef/idef0.shtml (дата обращения: 15.09.2017).
6. Горбаченко В. И., Убиенных Г. Ф., Бобрышева Г. В. Проектирование информационных систем с CA ERwin Modeling Suite 7.3. Пенза: ПГУ, 2012. 154 с.
7. Гришанова Л. И., Бессонова О. Н. Проектирование баз данных. Введение в CASE­технологии. № ОФАП­2759. № госрегистрации – 50200300629.
8. Гришанова Л. И., Соболева Е. Ю. Проектирование баз данных. Введение в SQL. № ОФАП­2756. № госрегистрации – 50200300626.
9. Delisle М. Mastering phpMyAdmin 2.8 for Effective MySQL Management,
Packt Publishing 2006. URL: http://go.mail.ru/redir?via_page=1&type=sr&r
edir=eJzLKCkpsNLXLy8v1yspzywqqNBLzs_VT8vMSdU3tzQ3srTUZ2AwN
DU0M7A0NrawZLh2xTT98Su5cItMy98p619PAAChfxZ3 (дата обращения:
15.09.2017).
10. URL: https://php­myadmin.ru/ – документация по phpMyAdmin и
MySQL. (дата обращения: 15.09.2017).
11. URL:http://www.oracle.com/technetwork/ru/database/express­edition/
overview/ – документация по Oracle Database 11g Express Edition (дата обращения: 15.09.2017).
СОДЕРЖАНИЕ
Введение.................................................................................... Процесс проектирования информационных систем.......................... Моделирование бизнес-процессов.................................................. Лабораторные работы.................................................................. Лабораторная работа № 1............................................................. Лабораторная работа № 2............................................................. Лабораторная работа № 3............................................................. Лабораторная работа № 4............................................................. Лабораторная работа № 5............................................................. Лабораторная работа № 6............................................................. Библиографический список.......................................................... 40
3
4
6
8
8
11
20
26
28
38
40
Документ
Категория
Без категории
Просмотров
1
Размер файла
1 484 Кб
Теги
grishanova
1/--страниц
Пожаловаться на содержимое документа