Методология IDEF0. На данный момент приложение ИС прокат автомобилей предоставляет ограниченный функционал и в дальнейшем может совершенствоваться, в качестве совершенствования можно добавить базы данных "Автомобили" и "Клиенты", а также добавить возможно

Федеральное агентство по образованию
Государственное образовательное учреждение высшего профессионального образования
«ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СЕРВИСА»

Кафедра «Прикладная информатика в экономике»

КУРСОВОЙ ПРОЕКТ

по дисциплине «Бизнесреинжиниринг»

на тему: «Проектирование бизнес-процессов предприятия сферы обслуживания (предприятие по оказанию услуг в сфере проката автомобилей)»

Выполнил студент

Группы И-402

Юзманов Р.М.

Проверила

Филиппова О.А.

Тольятти, 2010
СОДЕРЖАНИЕ

ВВЕДЕНИЕ...………………………………………………… ……………………………...…..3
1. АНАЛИТИЧЕСКИЙ РАЗДЕЛ……………………………………………….…………… ….4
1.1. Основные направления деятельности предприятия………………………………………4
1.2 Структурно-функциональное моделирование бизнес-процессов предприятия…………5
1.3 Недостатки существующей структурно-функциональной модели бизнес-процессов предприятия………………………………………………… …………………………………..14
2. ПРОЕКТНЫЙ РАЗДЕЛ……………………………………………………………… ...……16
2.1 Автоматизация структурно-функциональных моделей бизнес-процессов предприятия…… ……………………………………………………………………………… ..16
3. ПРОЕКТ ИНФОРМАЦИОННОЙ СИСТЕМЫ…………………………………………….31
3.1 Модель данных ИС………………………………………………………………………… 31
3.2 Интерфейс пользователя……………………………………………… …………………...33
4. ЭКОНОМИЧЕСКИЙ РАЗДЕЛ……………………………………………………………. ..38
4.1 Анализ затрат по проекту…………………………………………………………… ……..38
4.2 Расчет основных экономических показателей…………… ……………………………... 41
ЗАКЛЮЧЕНИЕ.………………………………………………… ………..…………………….44
БИБЛИОГРАФИЧЕСКИЙ СПИСОК…...………………………………….……………… …45

ВВЕДЕНИЕ

Современный этап развития общества характеризуется внедрением автоматизированных информационных систем во все сферы деятельности, в том числе и сфере обслуживания.
Прокат автомобилей вот уже много лет остается очень востребованным на территории России. Залог устойчивого положения на российском рынке как ООО «VolgaRent», так и отдельных его филиалов, - удовлетворение всех потребностей клиентов.
Целью данного курсового проекта является разработка информационной системы, автоматизирующей бизнес-процесс предприятия сферы обслуживания, занимающегося прокатом автомобилей.
Задачами данного курсового проекта является:

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

1. АНАЛИТИЧЕСКИЙ РАЗДЕЛ

1.1 Основные направления деятельности предприятия

Предприятие ООО «VolgaRent», деятельность которого планируется автоматизировать, занимается прокатом авто. Важнейшим звеном в данной деятельности является спецоборудование. В зависимости от того, насколько работа персонала автоматизирована, можно судить об эффективности его работы. Каждый день организация осуществляет прием и выдачу автомобилей разных марок, окрасов, и съёмной стоимости.
Персонал заполняет БД клиентов (ФИО, адрес, тел), если его еще там нет. После этого персонал осуществляет поиск интересующего автомобиля в БД. После того как клиент получает интересующий его авто, редактируется информация о выданных автомобилях. После возвращения клиентом взятого авто, вновь редактируется БД выданных авто и данные о взятых клиентом автомобиле.
Ниже (см. рис. 1.1) представлена схема организационной структуры нашей предметной области.

Рис. 1.1 Организационная структура

Рис. 1.2 Организационная структура автоматизируемого подразделения

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

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

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

1.2 Структурно-функциональное моделирование бизнес-процессов предприятия

Для проведения анализа и реорганизации бизнес-процессов воспользуемся CASE-средством. Bpwin поддерживает методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram).
Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель ТО-ВЕ). Для начала построим функциональные диаграммы бизнес-процессов, которые предстоит улучшить, т.е. модели AS-IS:
На рисунках 1.3 и 1.4 представлены контекстная диаграмма и диаграмма декомпозиции процесса «Выбор авто». На вход поступает информация о финансовых возможностях клиента, и текущий модельный ряд автомобилей. С помощью любезного персонала клиенту предоставляется возможность выбрать понравившийся автомобиль, и тем самым на выходе вы получаем выбранный авто. За управление процессами отвечают государственные стандарты. Механизмами служат клиент, который выбирает авто, и персонал, который обслуживает клиента.

Рис. 1.3 Контекстная диаграмма функциональной модели процесса «Выбор авто»

Рис. 1.4 Диаграмма декомпозиции процесса «Выбор авто»

Рис. 1.5 Контекстная диаграмма функциональной модели процесса «Выдача авто»

Рис. 1.6 Диаграмма декомпозиции процесса «Выдача авто»

Рис. 1.7 Контекстная диаграмма функциональной модели процесса «Оформление квитанции»

Рис. 1.8 Диаграмма декомпозиции процесса «Оформление квитанции»

Рис. 1.9 Контекстная диаграмма функциональной модели процесса «Оплата за ренту»

Рис. 1.10 Диаграмма декомпозиции процесса «Оплата за ренту»

Рисунки 1.5 и 1.6 отображают процесс «Выдача авто». Входом является модельный ряд и сведения о клиенте. На выходе клиенту выдаётся автомобиль. Ресурсной стрелкой является обслуживающий персонал, который и выдаёт клиенту авто. Управляют процессами внутренние правила предприятия «VolgaRent».
На рисунках 1.7 и 1.8 представлены диаграммы процесса «Оформление квитанции». Входным материалом является заявка клиента, которая передаётся обслуживающему персоналу, который в свою очередь обрабатывает заявку при помощи ИС, и на выходе клиент получает чек, который обязан оплатить и квитанцию об оплате.
Завершающим процессом является «Оплата за ренту». Контекстная диаграмма и диаграмма декомпозиции этого процесса отображены на рисунках 1.9 и 1.10. Входная стрелка – это заявка и непосредственно деньги от клиента, которые передаются обслуживающему персоналу. Персонал, обрабатывает полученную информацию, производит пересчёт средств, и на выходе клиент получает чек об оплате за авто. За управление в данном процессе отвечает законодательство РФ.

1.3 Недостатки существующей структурно-функциональной модели бизнес-процессов предприятия

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

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

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

Список клиентов. В данном документе хранится самая основная информация: ФИО, адрес и телефон.
Список предоставляемых услуг. Этот документ представляет собой прайс-лист. Такие сведения постоянно обновляются. В этом документе хранится марка автомобиля и его цена.
Регистр. Этот документ представляет собой список, в котором хранится информация о клиенте, его пожеланиях об аренде того или иного автомобиля, и в итоге какой автомобиль был арендован клиентом.

Как видно из описания структуры, все документы-списки необходимы для подсчета выручки. Таким образом, уже на данном этапе видно, насколько рационально использовать базу данных и приложение по работе с ней. Во-первых, сокращается объем информации, а данные для подсчета прибыли можно получить путем запросов, во-вторых, заметно сократится время на формирование отчета.
До создания этой информационной системы учёт арендуемых автомобилей в компании «VolgaRent» велся в письменном виде в регистре заявок. А также данные заполнялись в электронные таблицы Excel. Все данные о клиентах, услугах, мастерах хранились в табличном виде.
Таким образом, учет арендуемых авто в фирме «VolgaRent» не был автоматизирован. Как таковой БД не имелось и это существенный недостаток. Данные необходимо было связать и систематизировать. Разработанное программное приложение призвано решить эту проблему. Так же появилась возможность печати отчетов. Созданная ИС существенно сокращает бумажную работу нашей организации и минимизирует физический труд людей занимающихся ведением данной документации
Далее же запишем всю информацию в систематизированной форме. При создании базы данных, эту информацию можно будет разделить на конкретные таблицы.

ФИО.
Адрес.
Телефон.
Марка автомобиля
Цена аренды.
Дата аренды.
Срок аренды.

2. ПРОЕКТНЫЙ РАЗДЕЛ

2.1 Автоматизация структурно- функциональных моделей бизнес-процессов предприятия

Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов. Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС.
Как правило, данная модель создается на основе AS-IS, с устранением недостатков в существующей организации бизнес-процессов, а так же с их совершенствованием и оптимизацией. Это достигается за счет устранения выявленных на базе анализа AS-IS узких мест.
В традиционном реинжиниринге именно на основе модели TO-BE рекомендуется производить автоматизацию бизнес-процессов и проектировать КИС. Подразумевается, что это позволяет существенно снизить риск проявления автоматизации как исключительно источника затрат из-за автоматизации несовершенных процессов.
Построим функциональные диаграммы ТО-ВЕ бизнес-процессов, которые мы изменили.
На рисунках 2.1 и 2.2 представлены контекстная диаграмма и диаграмма декомпозиции процесса «Выбор авто». На вход поступает информация о финансовых возможностях клиента, и текущий модельный ряд автомобилей. С помощью любезного персонала клиенту предоставляется возможность выбрать понравившийся автомобиль, и тем самым на выходе вы получаем выбранный авто. За управление процессами отвечают государственные стандарты. Механизмами служат клиент, который выбирает авто, и персонал, который обслуживает клиента. В результате автоматизации предприятия произошло внедрение ИС в данный процесс. ИС позволила выбрать авто из каталога БД.
Рисунки 2.3 и 2.4 отображают процесс «Выдача авто». Входом является модельный ряд и сведения о клиенте. На выходе клиенту выдаётся автомобиль. Ресурсной стрелкой является обслуживающий персонал, который и выдаёт клиенту авто. Управляют процессами внутренние правила предприятия «VolgaRent». В результате процесса «Выдача авто» выдаётся доверенность клиенту на управление выбранным транспортным средством.

Рис. 2.1 Контекстная диаграмма функциональной модели процесса «Выбор авто» после автоматизации

Рис 2.2 Диаграмма декомпозиции процесса «Выбор авто» после автоматизации

Рис. 2.3 Контекстная диаграмма функциональной модели процесса «Выдача авто» после автоматизации

Рис 2.4 Диаграмма декомпозиции процесса «Выдача авто» после автоматизации

Рис. 2.5 Контекстная диаграмма функциональной модели процесса «Оформление квитанции» после автоматизации

Рис 2.6 Диаграмма декомпозиции процесса «Оформление квитанции» после автоматизации

Рис. 2.7 Контекстная диаграмма функциональной модели процесса «Оплата за ренту» после автоматизации

Рис 2.8 Диаграмма декомпозиции процесса «Оплата за ренту» после автоматизации

На рисунках 2.5 и 2.6 представлены диаграммы процесса «Оформление квитанции». Входным материалом является заявка клиента, которая передаётся обслуживающему персоналу, который в свою очередь обрабатывает заявку при помощи ИС, и на выходе клиент получает чек, который обязан оплатить и квитанцию об оплате. В результате поправок в законодательстве РФ в процессе «Оформление квитанции», формируется квитанция и выдаётся чек клиенту, благодаря ИС.
Завершающим процессом является «Оплата за ренту». Контекстная диаграмма и диаграмма декомпозиции этого процесса отображены на рисунках 2.7 и 2.8
Входная стрелка – это заявка и непосредственно деньги от клиента, которые передаются обслуживающему персоналу. Персонал, обрабатывает полученную информацию, производит пересчёт средств, и на выходе клиент получает чек об оплате за авто. За управление в данном процессе отвечает законодательство РФ. Вследствие автоматизации данного процесса появилась возможность выдачи гарантии на арендуемое авто.

3. ПРОЕКТ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Модель данных ИС

Процесс моделирования в Erwin базируется на методологии проектирования реляционных баз данных IDEF1X.
Для проектирования базы данных проектов использовалась модель «сущность – связь» (Entity – Relationship model, или ER – модель). ER – модель представляет собой высокоуровневую концептуальную модель данных, цель которой - упрощение задачи проектирования баз данных. Данная модель данных включает в себя набор концепций, которые описывают структуру базы данных и связанные с ней транзакции обновления и выборки данных. Следует подчеркнуть, что концептуальная модель данных не зависит от конкретной СУБД или аппаратной платформы, которая используется для физической реализации базы данных.
Основными элементами IDEF1X являются сущности, атрибуты и связи.
Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. Атрибут или группа атрибутов, которые идентифицируют сущность, называется первичным ключом. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибуту - колонка таблицы.
Сущности изображаются в виде прямоугольников. Имя сущности показывается над прямоугольником, изображающим сущность, список атрибутов сущности - внутри прямоугольника. Список разделен горизонтальной чертой, выше которой расположены атрибуты первичного ключа, ниже – не ключевые атрибуты.
В IDEF1X также различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Зависимая сущность изображается прямоугольником со скругленными углами.
Результатом нормализации является модель данных, которую легко поддерживать, не содержащая неопределенностей в данных и повторений данных.
После выделения информационных объектов необходимо объединить их в одну систему, то есть установить связи между ними.
Объект «Марки» связан с полем «Автомобили» связью «один ко многим». Этот тип связи применяется, когда одному значению вспомогательного объекта соответствует много значений главного. По аналогии с этим устанавливаются связи «один ко многим» у остальных информационных объектов «Персонал», «Клиенты», «Выдача авто», с соответствующими полями связанных между собой таблиц. Схема логической модели данных представлена на рисунке 3.1.

Рис. 3.1 Логическая модель базы данных.

3.2 Интерфейс пользователя

Рис. 3.2 Форма «Прокат автомобилей»

Форма «Прокат автомобилей» - это начальная форма приложения, с помощью неё осуществляется возможность доступа к формам: «Автомобили», «Комплектация», «Клиенты», «Персонал», «Выдача автомобилей».

Рис. 3.3 Форма «Автомобили»

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

Рис. 3.4 Форма «Комплектация»
Через форму «Комплектация» осуществляется редактирование данных об имеющихся данных. Редактирование данных осуществляется при помощи кнопок: «Добавить», «Удалить», «Переместить», «Откат действия». На данной форме предусмотрена возможность сортировки, поиска и фильтрации данных по выбранным параметрам.

Рис. 3.5 Форма «Клиенты»

Через форму «Клиенты» осуществляется редактирование данных о клиентах. Редактирование данных осуществляется при помощи кнопок: «Добавить», «Удалить», «Переместить», «Откат действия». На данной форме предусмотрена возможность сортировки, поиска и фильтрации данных по выбранным параметрам.

Рис. 3.7 Форма «Персонал»
Через форму «Персонал» осуществляется редактирование данных о обслуживающем персонале. Редактирование данных осуществляется при помощи кнопок: «Добавить», «Удалить», «Переместить», «Откат действия». На данной форме предусмотрена возможность сортировки, поиска и фильтрации данных по выбранным параметрам.

Рис. 3.8 Форма «Выдача»

Форма «Выдача автомобилей» - это главная форма приложения, в которую заносятся данные о менеджере, отдавшем автомобиль в ренту, клиенте, который этот автомобиль взял в прокат, об арендуемом автомобиле, и о дате аренды.
Редактирование данных осуществляется при помощи кнопок: «Добавить», «Удалить», «Переместить», «Откат действия», «Отчёт». На данной форме предусмотрена возможность сортировки, поиска и фильтрации данных по выбранным параметрам.
При нажатии кнопки «запрос по дате», отбираются сведения о клиенте, менеджере и рентуемом автомобиле, который был взят в прокат в этот день.
При нажатии на кнопку «Отчет» формируется отчет по данным о клиентах, представленный на рис. 3.9
.

Рис. 3.9 Отчет по выдачам автомобилей

4. ЭКОНОМИЧЕСКИЙ РАЗДЕЛ

4.1 Анализ затрат по проекту

Затраты на ресурсы процесса «Выбор авто»:
Затраты на рекламу – 5000 р.
Оплата персоналу – 26000 р.
Создание каталога – 2000 р

Рис. 4.1 Диаграмма дерево узлов процесса «Выбор авто»

Затраты на ресурсы процесса «Выдача авто»:
Зар.плата персоналу – 17500 р
Электроэнергия – 700 р

Рис. 4.2 Диаграмма дерево узлов процесса «Выдача авто»

Затраты на ресурсы процесса «Оформление квитанции»:
Зар.плата персоналу – 14700 р
Канцтовары – 500 р
Электроэнергия – 300 р

Рис. 4.3 Диаграмма дерево узлов процесса «Оформление квитанции»
и т.д.................

Дата

08 Авг 2013

Тема: Знакомство с CASE-средством разработки информационных систем BPwin

Цель работы : познакомиться с CASE-средством BPwin фирмы Computer Associates, научиться строить модель в методологии IDEF0 .

Порядок работы:
1. Ознакомиться с принципами построения модели в BPwin.
2. Ознакомиться с основной панелью инструментов.
3. Ознакомиться с палитрой инструментов IDEF0.
4. Научиться строить контекстную диаграмму, определять цель, точку зрения, границы модели. Освоить работу с закладками General, Purpose, Definition, Status, Numbering, Display.
5. Научиться строить декомпозирующие диаграммы.
6. Выполнить практическое задание.
7. Ответить на контрольные вопросы.

1. Краткая информация об CASE-средстве BPwin

BPwin - CASE-средство верхнего уровня, помогающее проводить анализ и реорганизацию бизнес-процессов. Поддерживается методология IDEF0 (функциональная модель), IDEF3 (Work Flow Diagram), DFD (Data Flow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей – того, к чему надо стремиться (модель TO-BE).
Процесс построения информационной модели в BPwin состоит из следующих шагов:
построение контекстной диаграммы;
проводится функциональная декомпозиция;
после каждого сеанса декомпозиции проводится сеанс экспертизы.
На основе модели BPwin можно построить модель данных. В программе поддерживается связь с ERwin.

2. Инструментальная среда BPwin

При запуске BPwin по умолчанию появляется основная панель инструментов (рис.1), палитра инструментов и навигатор модели Model Explorer (рис.2).

Рис.1 Внешний вид панели управления BPwin4.0

Панель инструментов представлена следующими кнопками (слева направо):
создать модель (пункт меню File/New);
открыть модель (пункт меню File/Open);
сохранить модель (пункт меню File/Save);
напечатать модель (пункт меню File/Print);
выбор масштаба (View/Zoom);
уменьшить модель (View/Zoom);
увеличить модель (View/Zoom);
проверить правописание (Tools/Spelling);
включение и выключение навигатора модели (View/Model Explorer);
включение и выключение дополнительной панели инструментов работы с Model Mart (Model Mart).

Рис.2 Внешний вид окна навигатора модели Model Explorer

При создании новой модели возникает диалог, в котором следует указать, будет ли модель создаваться заново, или она будет открыта из файла либо из репозитария Model Mart. Также необходимо внести имя модели и выбрать методологию, в которой будет построена модель (рис.3).

Рис.3 Диалог создания модели.

BPwin поддерживает три методологии моделирования:
функциональное моделирование (IDEFO);
описание бизнес-процес¬сов (IDEF3);
диаграммы потоков дан¬ных (DFD).
В зависимости от выбранной методологии программой автомати¬чески подбирается нужная панель инструментов BPwin Toolbox. В BPwin существует три разных панели инструментов - по числу поддерживаемых програм¬мой методологий. На рис.4 представлена палитра для IDEF0.

Рис.4 Палитра инструментов IDEF0.

Вы можете показывать или скрывать панель инструментов, используя функцию «View» на панели меню.

3. Построение модели IDEF0. Контекстная диаграмма
Функциональное моделирование является технологией анализа системы в целом как набора связанных между собой действий или функций. Действия системы анализируются независимо от объектов, которые обеспечивают их исполнение. Моделировать деловой про¬цесс можно исходя из различных перспектив и временных рамок. На¬пример, вы можете моделировать процесс заказа услуг клиентом так, как вы видите его в идеале, а не так, как это происходит в настоящее время. Также можно абстрагироваться от проблем физической реализации модели.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения КОНТЕКСТА, т.е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить ГРАНИЦЫ СИСТЕМЫ, определить, что входит в систему, а что лежит за ее пределами. То есть необходимо решить, что будет рассматриваться как компоненты системы, а что как внешнее воздействие. Другими словами, первоначально необходимо определить область (Scope) моделирования.
Наименование функции самого высокого уровня опи¬сывает систему непосредственно и, как правило, состоит из одного активного глагола в сочетании с обобщающим существительным, ко¬торое разъясняет цель деятельности с точки зрения самого общего взгляда на систему. Например «Изготовить изделие».
Формулировка цели моделирования (Purpose) позволяет команде аналитиков сфокусировать усилия в нужном направлении. Модель не может быть построена без четко сформулированной цели.
Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения.
Для определения контекста модели в BPwin следует выбрать пункт меню Model/Model Properties. В закладке General указывается наименование и сведения об авторе модели, в закладку Purpose следует внести цель и точку зрения, а в закладку Definition – определение модели и описание области (рис.5).
Для создания контекстной диаграммы необходимо сначала соз¬дать новую модель, выбрав пункт «New» в меню «File». В появившем¬ся диалоге необходимо набрать имя модели и выбрать ее тип. Этот диалог также отображается при запуске BPwin.
После создания модели можно задать ее параметры. Кроме вышеперечисленных свойств модели (Model Properties) можно задать состоя¬ние, в котором находится модель, например «в работе» или «для публикации» (закладка Status).

Рис.5 Диалог задания свойств модели.

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

Рис.6 Пример контекстной диаграммы.

4. Декомпозиция
Декомпозиционное разложение модели используется в моделиро¬вании бизнес-процессов, для того чтобы дать более подробное описа¬ние блоков. Каждый из них может в свою очередь быть де¬композированным. При каждой декомпозиции блока создается новая диаграмма. Число декомпозиций не ограничено и полностью зависит от уровня сложности, который необходимо показать в модели.
Чтобы выполнить декомпозицию функции, необходимо щелкнуть по кнопке . Возникает диалог Activity Box Count (рис.7), в котором следует указать нотацию новой диаграммы и количество блоков на ней. Для IDEF0 рекомендуется 3-6 блоков.

Рис.7 Диалог Activity Box Count.

BPwin создает новую диаграмму, которая является диаграммой разложения родительской диаграммы. Заметьте, что новые действия не связаны между собой и не поименованы - это следующая задача. Необходимо задать взаимодействие между блоками и «привязать» к но¬вым блокам стрелки, которые автоматически унаследованы от роди¬тельской диаграммы (рис.8).

Рис.8 Пример несвязанных стрелок.

Имя блока и другие его свойства вводятся в закладке «Name» спи¬ска свойств блока. Для вывода свойств блока на экран достаточно два¬жды щелкнуть мышью на блоке.
Следующим шагом при создании диаграммы должно быть соеди¬нение всех использованных на диаграмме блоков с помощью стрелок, представляющих входы, результаты работы, средства управления и механизмы. Для этого достаточно соединить исходящую точку стрел¬ки с точкой ее окончания. Окончанием стрелки может быть как одна из сторон функциональных блоков, так и граница диаграммы. BPwin автоматически выделяет допустимые окончания для создаваемых стрелок. Для рисования стрелки пользуются инструментом из комплекта инструментов. Задание имени стрелки производится в закладке «Name» диалога свойств стрелок. Для вызова этого диалога достаточно дважды щелк¬нуть мышью на нужной стрелке.
Если количества блоков на диаграмме окажется недостаточным, существует возможность добавления на нее новых блоков с использованием кнопки панели инструментов. Для добавления блока сле¬дует щелкнуть на этом инструменте, а затем - на диаграмме в том месте, где необходимо расположить новый блок. После того как до¬полнительный блок создан, вы можете связать его стрелками с други¬ми блоками и задать его название и другие свойства.
Обра¬тите внимание на рис.9. Если действие не было декомпозирова¬но, в верхнем левом углу блока будет по¬являться символ «листа». После деком-позиции данного блока символ «листа» исчезнет.

Рис.9 Пример недекомпозированного блока.

Нумерация блоков производится автоматически при их создании. Номера могут быть относительными или постоянными, они отражают иерархическое положение блока в пределах модели. Вы можете управлять нумерацией блоков на диаграмме, используя закладку «Numbering» диалога ввода свойств модели (рис.5).
Перемещение любых объектов на диаграмме осуществляется с по¬мощью их «захвата» мышью и перемещения в новое место. При пере¬мещении блоков одновременно перемещаются и связанные с ними стрелки. Функциональные блоки могут также быть перемещены меж¬ду диаграммами с использованием команд «Cut/Paste» из меню «Edit». При изменении взаимного расположения блоков могут меняться и их но¬мера.
Для идентификации граничных стрелок предназначены ICOM-коды. Код содержит префикс, соответствующий типу стрелки (Input, Control, Output, Mechanism) и порядковый номер. BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на закладке Display диалога свойств.
Практическое задание:
1. Согласно варианту, создайте контекстную диаграмму. Определите цель, точку зрения модели. Опишите свойства в соответствующих закладках диалога Model Properties.
2. Задайте входы, выходы, механизмы и управление.
3. Создайте декомпозицию контекстной диаграммы, состоящую из 2-3 блоков. Задайте автоматическую нумерацию блоков и ICOM-кодов.
4. Установите связи между блоками. Задайте имена дуг.
5. Сохраните проект в отдельный файл.

Контрольные вопросы:
1. Для чего используется методология IDEF0.
2. Объясните необходимость задания цели и точки зрения модели?
3. Перечислите и расскажите назначения кнопок на панели инструментов.
4. Перечислите этапы декомпозиции блока.
5. Расскажите, каким образом на диаграмму добавить блок, дугу.
6. Дайте определение ICOM-кодов.
7. Для чего используются закладки General, Purpose, Definition, Status, Numbering, Display в диалоге Model Properties.
Варианты к практическим работам
Вариант 1
Система должна описывать порядок подготовки к экзамену, предполагающий получение отличной оценки.
Вариант 2
Система должна описывать порядок выполнения практической работы по дисциплине «Проектирование ИС».
Вариант 3
Система должна описывать порядок получения водительских прав.
Вариант 4
Система должна описывать порядок организации городского спортивного соревнования.
Вариант 5
Система должна описывать порядок организации общеинститутского студенческого мероприятия.
Вариант 6
Система составления учебного графика дисциплин, изучаемых на факультете
Вариант 7
Система должна описывать порядок поставок товара в систему розничных киосков.
Вариант 8
Система должна описывать порядок обработки заказов в службе быта.
Вариант 9
Система должна описывать работу одного из участков автосалона.
Вариант 10
Система должна описывать работу приемного покоя в больнице.
Вариант 11
Система должна описывать порядок приема заявки на поставку продукции на хлебокомбинате.
Вариант 12
Система должна описывать процесс поставки сезонных товаров в оптовой фирме.
Вариант 13
Система должна описывать процесс работы торгового отдела.
Вариант 15
Система учета в видеопрокате.
Вариант 16
Система учета проката на лыжной базе

6.2. Назначение и состав методологии SADT (IDEF0)

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

Начало разработки данной методологии было положено Дугласом Россом (США) в середине 60-х гг. ХХ в. С тех пор системные аналитики компании SofTech, Inc. улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, управление финансами и материально-техническим снабжением – вот некоторые из областей эффективного применения SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе «Интеграции компьютерных и промышленных технологий» (Integrated Computer Aided Manufacturing, ICAM) Министерства обороны США была признана полезность SADT. Это привело к публикации ее части в 1981 г., называемой IDEF0 (Icam DEFinition), в качестве федерального стандарта на разработку программного обеспечения. Под этим названием SADT стала применяться тысячами специалистов в военных и промышленных организациях . Последняя редакция стандарта IDEF0 была выпущена в декабре 1993г. Национальным институтом по стандартам и технологиям США (National Institute Standards and Technology, NIST).

Данная методология при описании функционального аспекта информационной системы конкурирует с методами, ориентированными на потоки данных (DFD). В отличие от них IDEF0 позволяет:

Описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);

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

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

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

Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм [ , ]:

Контекстную диаграмму;

Диаграммы декомпозиции;

Диаграммы дерева узлов;

Диаграммы только для экспозиции (for exposition only, FEO).

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

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

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

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

6.3. Элементы графической нотации IDEF0

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

На следующем рисунке показаны основные элементы графической нотации IDEF0 .

Рис. 6.1. Элементы графической нотации IDEF0

Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу) , которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).

Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок :

- вход (англ. input) – материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы;

- управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т.е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);

- выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;

- механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;

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

6.4. Типы связей между работами

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

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

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

Рис. 6.2. Иерархическая связь

2. Регламентирующая (управляющая, подчиненная) связь отражает зависимость одной функции от другой, когда выход одной работы направляется на управление другой. Функцию, из которой выходит управление, следует считать регламентирующей или управляющей, а в которую входит – подчиненной. Различают прямую связь по управлению , когда управление передается с вышестоящей работы на нижестоящую (рис. 6.3), и обратную связь по управлению , когда управление передается от нижестоящей к вышестоящей (рис. 6.4).

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

Рис. 6.5. Прямая связь по входу	Рис. 6.6. Обратная связь по входу

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

Рис. 6.7. Потребительская связь

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

Рис. 6.8. Логическая связь

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

Рис. 6.9. Методическая связь

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

Рис. 6.10. Ресурсная связь

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

Рис. 6.11. Информационная связь

9. Временная связь возникает между функциями, которые должны выполняться одновременно до или одновременно после другой функции.

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

Рис. 6.12. Временная связь

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

Рис. 6.13. Случайная связь

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

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

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

1. Перед построением модели необходимо определиться, какая модель (модели) системы будет построена. Это подразумевает определение ее типа AS-IS, TO-BE или SHOULD-BE, а также определения позиции, с точки зрения которой строится модель. «Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. Например, при построении модели работы продуктового магазина можно среди возможных претендентов, с точки зрения которых рассматривается система, выбрать продавца, кассира, бухгалтера или директора. Обычно выбирается одна точка зрения, наиболее полно охватывающая все нюансы работы системы, и при необходимости для некоторых диаграмм декомпозиции строятся диаграммы FEO, отображающие альтернативную точку зрения.

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

3. Количество блоков на диаграммах декомпозиции рекомендуется в пределах 3–6. Если на диаграмме декомпозиции два блока, то она, как правило, не имеет смысла. При наличии большого количества блоков диаграмма становится перенасыщенной и трудно читаемой.

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

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

Рис. 6.14. Функция без управления и входа

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

На рис. 6.7–6.12, отображающих фрагменты диаграмм IDEF0, встречаются блоки без входа и управления. Это не стоит рассматривать как ошибку, так как подразумевается, что одна из этих стрелок должна быть.

6. У каждого блока должен быть как минимум один выход.

Рис. 6.15. Функция без выхода

Работы без результата не имеют смысла и не должны моделироваться. Исключение составляют работы, отображаемые в модели AS-IS. Их наличие свидетельствует о неэффективности и несовершенстве технологических процессов. В модели TO-BE эти работы должны отсутствовать.

7. При построении диаграмм следует минимизировать число пересечений, петель и поворотов стрелок.

8. Обратные связи и итерации (циклические действия) могут быть изображены с помощью обратных дуг. Обратные связи по входу рисуются «нижней» петлей, обратная связь по управлению – «верхней» (см. рис. 6.4 и 6.6).

9. Каждый блок и каждая стрелка на диаграммах должны обязательно иметь имя. Допускается использовать ветвление (декомпозицию) или слияние (композицию) стрелок. Это связано с тем, что одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. И наоборот, одинаковые или однородные данные и объекты, порожденные разными работами, могут использоваться в одном месте.

Рис. 6.16. Ветвление стрелок

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

Так, на рис. 6.16 управления, входящие в блоки «Изготовление деталей» и «Сборка изделия», имеют уточняющие значения и являются составной частью более общего управления «Чертежи». Для работы блока «Контроль качества» используются все чертежи.

На диаграмме не допускается рисовать стрелки, когда до и после ветвления они не именованы. На рис. 6.17 стрелка, входящая в блок «Формирование типовых ведомостей», не имеет имени до и после ветвления, что является ошибкой.

Рис. 6.17. Неправильное именование стрелок

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

Рис. 6.18. Туннелирование стрелок

В данном примере при построении модели проведения новогоднего утренника механизм «два топора» не будет отображаться на диаграммах верхних уровней, при чтении которых может возникнуть справедливый вопрос: «А зачем нужны два топора на новогоднем утреннике?».

Аналогичным образом можно выполнять туннелирование с обратной целью – недопущения отображения стрелки на диаграммах низших уровней. В этом случае круглые скобки ставятся на конце стрелки. На контекстной диаграмме (см. рис. 6.21) затуннелирован механизм «Инженер службы пути», входящий в блок «Определение допускаемых скоростей». Такое решение принято, так как инженер непосредственно участвует во всех работах, отображенных на диаграмме декомпозиции этого блока (см. рис. 6.22). Чтобы не показывать эту связь и не загромождать диаграмму декомпозиции, стрелка была затуннелирована.

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

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

Рис. 6.19. Объединение связей

13. Каждый блок на диаграммах должен иметь свой номер. Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Блок на диаграмме верхнего уровня обозначается 0, блоки на диаграммах второго уровня – цифрами от 1 до 9 (1, 2, …, 9), блоки на третьем уровне – двумя цифрами, первая из которых указывает на номер детализируемого блока с родительской диаграммы, а вторая номер блока по порядку на текущей диаграмме (11, 12, 25, 63) и т. д. Контекстная диаграмма имеет обозначение «А – 0», диаграмма декомпозиции первого уровня – «А0», диаграммы декомпозиции следующих уровней – состоят из буквы «А», за которой следует номер декомпозируемого блока (например, «А11», «А12», «А25», «А63»). На рисунке показано типичное дерево диаграмм (диаграмма дерева узлов) с нумерацией.

Рис. 6.20. Иерархия диаграмм

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

6.6. Пример построения модели IDEF0 для системы определения допускаемых скоростей

Расчет допускаемых скоростей движения поездов является трудоемкой инженерной задачей. При проходе поездом какого-либо участка фактическая скорость движения поезда не должна превышать предельно допускаемую. Эта предельно допускаемая скорость устанавливается исходя из опыта эксплуатации и специально проводимых испытаний по динамике движения и воздействию на путь подвижного состава. Непревышение этой скорости гарантирует безопасность движения поездов, комфортабельные условия езды пассажиров и т. п. Они определяются в зависимости от типа подвижного состава (марки локомотива и типа вагонов), параметров верхнего строения пути (типа рельсов, балласта, эпюры шпал) и плана (радиуса кривых, переходных кривых, возвышения наружного рельса и т. д.). Как правило, для установления допускаемых скоростей необходимо определить не менее двух (на прямых) и пяти (в кривых) скоростей, из которых и выбирается окончательная допускаемая скорость, как наименьшая из всех рассчитанных. Расчет этих скоростей регламентируются Приказом МПС России № 41 от 12 ноября 2001 г. «Нормы допускаемых скоростей движения подвижного состава по железнодорожным путям колеи 1520 (1524) мм Федерального железнодорожного транспорта».

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

Контекстная диаграмма для задачи определения допускаемых скоростей показана на рис.6.21. Для построения модели использовался продукт BPwin 4.0 фирмы Computer Associates.

Рис. 6.21. Контекстная диаграмма системы определения допускаемых скоростей (методология IDEF0)

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

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

Подробный продольный профиль (содержит информацию, аналогичную рассмотренной выше);

Паспорт дистанции пути (содержит информацию, аналогичную рассмотренной выше, а также сведения о верхнем строении пути (ВСП));

Данные о результатах съемки плана пути вагоном-путеизмерителем;

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

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

Управляющими данными являются:

Указание начальника службы пути дороги или Департамента пути и сооружений ОАО «РЖД» на расчет;

Приказ № 41, содержащий нормативно-справочную информацию, порядок и формулы определения допускаемых скоростей;

Сведения о текущем или планируемом поездопотоке (данные о марках обращающихся локомотивов и типах используемых вагонов);

Сведения о планируемых ремонтах пути, реконструкции и переустройстве сооружений и устройств.

Результатом работы системы должны быть:

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

Ведомости Приказа начальника дороги об установлении допускаемых скоростей на перегонах и раздельных пунктах (Приказ «Н») согласно принятой на дороге форме. Утвержденный Приказ «Н» официально закрепляет допускаемые скорости движения поездов;

Типовые формы № 1, 1а и 2, содержащие планируемые допускаемые скорости для разработки графика движения поездов.

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

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

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

Рис. 6.22. Диаграмма декомпозиции первого уровня (методология IDEF0)

Очередность выполнения функций для решения рассматриваемой задачи следующая:

Ввод и корректировка нормативно-справочной информации и данных по участкам дороги (блоки 1 и 2);

Подготовка задания на расчет (блок 3). В нем указывается, для какого участка и пути, а также марки локомотива и типа вагонов следует выполнить расчет;

Расчет допускаемых скоростей в соответствии с порядком и формулами, указанными в Приказе № 41 (блок 4). В качестве исходной информации выступают данные по пути участка (план, верхнее строение пути и т. д.) и нормативы, выбираемые на основании задания на расчет;

Формирование ведомостей допускаемых скоростей (блок 5). На базе результатов расчета создаются несколько видов выходных документов, которые, с одной стороны, позволяют выявить причину ограничений скорости, с другой стороны, выступают в качестве основы для подготовки регламентированных документов;

Формирование и подготовка проекта Приказа «Н» и типовых ведомостей (блоки 6 и 7).

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

6.7. ICOM-коды

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

ICOM-коды (аббревиатура от Input, Control, Output и Mechanism) предназначены для идентификации граничных стрелок. ICOM-код содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (см. рис.).

3. Постановка задачи разработки информационной системы

4. Функциональная модель бизнес-процесса

4.1 Моделирование в IDEF0

4.2 Диаграммы информационной системы “Видеопрокат” в нотации IDEF0

4.3 Моделирование в DFD

4.4 Диаграммы информационной системы “Видеопрокат” в нотации DFD

5. Модели данных информационной системы

5.2 Концептуальная модель данных

5.3 Логическая модель данных

5.4 Физическая модель данных

6. Проектирование с использованием UML

6.1. Диаграмма последовательности действий

7. Заключение

8. Список литературы

1. Введение

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

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

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

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

Задачами курсового проекта являются:

Разработка видеопроката в нотации IDEF0 инотации DFD

Моделирование данных видеопроката в IDEF1X

Проектирования с использованием UML

2. Инструменты разработки информационной системы

Для проведения анализа и реорганизации бизнес-процессов Logic Works предлагает CASE–средство верхнего уровня – BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей – того, к чему нужно стремиться (модель TO-BE). Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы, каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы. Bpwin основан на методологии IDEF.

Для BPwin 4.0 нужно отметить существенно улучшенный интерфейс, если сравнивать с предыдущими версиями. Нет проблем со шрифтами, с изменением размеров объектов на диаграмме, что раньше в некоторых случаях могло привести к тому, что диаграмма “плыла”. Кроме проводника модели, улучшены также и словари объектов. Теперь все словарные объекты располагаются в радующих глаз аккуратных таблицах. Вид этих таблиц можно настраивать так, как удобно разработчику, содержание словарей можно печатать, экспортировать, импортировать, также можно генерировать отчеты по содержанию словарей. Можно поддерживать словари для следующих объектов: работы, стрелки, хранилища данных, внешние ссылки, перекрестки, объекты ссылок, атрибуты, центры затрат, сущности, ресурсы, роли, группы ролей, свойства, определяемые пользователем (UDP).

Данный продукт тесно интегрирован с инструментальным средством для моделирования БД – ERWin.

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

BPwin имеет мощный инструмент отчетов Report Template Builder, с помощью которого можно легко и быстро создавать различные отчеты о разработанной модели.

Официальная версия программы относительно недешева

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

Например, ограничение количества моделей на диаграмме, присущее BPWin, с одной стороны способствует наглядности модели, с другой – налагает неудобства при описании сложных процессов.

Пакет ERWin - средство, используемое при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность – связь». Продукт компании Computer Associates. ERWin это средство концептуального моделирования БД. Используется при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность − связь». В настоящее время ERWin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых различных классов.

Возможности ERWin:

поддерживает методологию структурного моделирования SADT и следующие нотации: стандартную нотацию IDEF1x для ER-диаграмм моделей данных, нотацию IE и специальную нотацию, предназначенную для проектирования хранилищ данных - Dimensional;

поддерживается прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД: настольные, реляционные и специализированные СУБД, предназначенные для создания хранилищ данных;

интегрирован линейкой продуктов Computer Associates для поддержки всех стадий разработки ИС, CASE-средствами Oracle Designer, Rational Rose, средствами разработки и др.;

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

возможна совместная работа группы проектировщиков с одними и теми же моделями (с помощью AllFusion Model Manager);

позволяет переносить структуру БД (не сами данные!) из СУБД одного типа СУБД в другой;

позволяет документировать структуру БД.

Достоинства:

распространенность;

техподдержка;

ошибки программы известны и описаны.

Недостатки:

нельзя создавать стандартные операции;

репрезентативные свойства низки;

отсутствие стандартных объектов для описания бизнес процессов;

довольно узкие возможности для проведения экономического анализа;

жесткая методология;

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

не очень удачные генераторы проектной документации;

официальная версия программы относительно недешева.