Файл: Построение объектной модели информационной системы Автосервис Построение объектной модели информационной системы Автосервис.docx

Методология UML было разработана в конце прошлого века и включает в себя нотацию UML (правила разработки и записи схем и построения диаграмм).

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

Структурные диаграммы:

Диаграмма классов
Диаграмма компонентов
Диаграмма композитной/составной структуры
Диаграмма кооперации (UML2.0)
Диаграмма развёртывания
Диаграмма объектов
Диаграмма пакетов
Диаграмма профилей (UML2.2)
Диаграммы поведения:
Диаграмма деятельности
Диаграмма состояний
Диаграмма вариантов использования
Диаграммы взаимодействия:
Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
Диаграмма обзора взаимодействия (UML2.0)
Диаграмма последовательности
Диаграмма синхронизации (UML2.0)

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

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

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

2.4.1. Диаграмма вариантов использования

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

Вариант использования (use case)

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

Рассмотрим типичный бизнес-процесс обработки заявки на сервисное обслуживание автомобиля.

Рис.2.8. Варианты обслуживания клиента

Клиент:

Обращается в центр (Подает заявку мастеру-приемщику, Подает документы, описывает неисправность)

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

Мастер- приемщик:

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

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

Начальник смены:

Получает заявку

Согласовывает наличие деталей на складе,

Создает наряд (Согласовывает время выполнения ремонтных работ и назначает механика)

Механик

Получает наряд,

Получает детали со склада,

Выполняет наряд

Закрывает наряд (проводит списание деталей, выполняет калькуляцию расходов, проводит оценку выполненых работ)

2.4.2. Диаграммы классов

Диаграммы классов обычно заполняются параллельно с диаграммами последовательностей в процессе моделирования работы вариантов использования.

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

Таблица 2.1.

Категории концептуальных классов

Категория концептуальных классов	Примеры
Физические и материальные объекты	Клиент Мастер-приемщик Начальник смены Механик Система Наряд Заявка Документы
Роли людей	Сотрудник Новый покупатель Оптовый покупатель Система
События	Обращение Указание проблемы, Предоставление документов Составление заявки Составление наряда Согласование: Склад Цех Выбор механика Ремонт: Получение деталей Списывание Выполнение работ Калькуляция Оплата
Процессы	Регистрация/авторизация Ремонтные работы Доставка деталей Оплата Прием изделия

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

Рис.2.9. Диаграмма классов

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

Рассмотрим подробно диаграмму последовательности для процесса составления наряда (рис. 2.10).

Рис.2.10. Диаграмма последовательности «Создание наряда».

2.4.4. Диаграмма кооперации

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

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

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

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

Рис.2.11. Диаграмма кооперации варианта Согласования наряда

2.4.5.Диаграмма состояний

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

Рис.2.12. Диаграмма состояний интерфейса АРМ начальника смены

2.4.6. Диаграмма деятельности

Алгоритм работы по ремонту авто (диаграмма деятельности) представлен на рис. 2.13.

Рис.2.12. Диаграмма деятельностей «Выполнение ремонта автомобиля»

Для описания деятельности использовался пул и три дорожки Мастер приемщик Начальник смены и Механик. Работу начинает мастер приемщик после поступления заявки клиента.

ЗАКЛЮЧЕНИЕ

В результате выполнения курсового проекта была выполнена объектная модель информационной системы формирования организационно-распорядительной документации отдела кадров ООО «АВТОСЕРВИС», позволяющая решать следующие задачи:

Авторизация в системе
Работа с заявками
Просмотр заявки
Редактирование заявки
Составление наряда
Просмотр наряда,
Редактирование наряда
Модуль склад
Модуль цех
Информация по ремонту автомобиля
Списание запчастей
Внесение данных о покупателе в систему
Расчет стоимости ремонта

Внедрение данной информационной системы на ООО «АВТОСЕРВИС» позволит:

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

Таким образом, цель курсового проекта можно считать достигнутой, а поставленные задачи – решенными.

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

Баззел Р., Кокс Д., Браун Р. Информация и риск в маркетинге — М.:Финстатинформ, 1993
Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. - М.: ДМК Пресс, 2001.
Вендров А.М. Проектирование программного обеспечения экономических информационных систем. / А.М. Вендеров. – М.: Финансы и статистика, 2000.
Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. М. : Финансы и статистика, 1998. 176 с.
Голубков Е.П. Маркетинговые исследования: теория, методология и практика: Учебник. — 3-е изд., перераб. и доп. — М.: Издательство «Финпресс», 2003. — 496 с.
Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. Интернет-университет информационных технологий. / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина // ИНТУИТ.ру. − 2008.
Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). М. : Лори, 1996. – 457с.
Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование. - М.: ДМК Пресс, 2001.
Котлер Ф. Основы маркетинга. Краткий курс.: Издательство «Вильямс», 2007. — 656 с.
Ларман К. Применение UML и шаблонов проектирования. - М.: Издательский дом «Вильяме», 2001.
Леоненков А.В. Самоучитель UML. - СПб.: БХВ-Петербург, 2001.
Петров В.И. Информационные системы. СПб. : Питер, 2002. 688 с.
Федоров Н.В. Проектирование информационных систем на основе современных CASE-технологий. – М.: МГИУ, 2008. − 287 с.
Черемных С.В., Ручкин В.С., Семенов И.О. Структурный анализ систем IDEF-технологии. / С.В. Черемных, В.С. Ручкин, И.О. Семенов – М.: Финансы и статистика, 2001.