Файл: Моделирование предметной области «Управление взаимоотношениями с клиентами» с помощью UML (Унифицированный язык моделирования UML).pdf

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

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

2.2 Построение диаграмм

Целью данного этапа является проведение анализа бизнес-процессов заказчика и на основе данного анализа построение модели автоматизированной системы управления (АСУ). Для этого необходимо произвести анализ объектов капитального строительства, графика и объема их финансирования, условия заключаемых договоров и этапы их оплаты. Также необходимо провести анализ роли ответственных лиц (Actors) и т.д. Задача это не простая и требует значительных аналитических усилий и опыта. Результатом этой работы должен быть список ролей в компании заказчика, четкое понимание процесса и список объектов (сущностей), участвующих в этом процессе. Все это и должно найти отражение в диаграммах Rational Rose. Кроме того, необходимо вместе с заказчиком составить список требований к ИС.

Используем следующий подход: используем Use case diagram для отображения списка операций, которые должна выполнять наша система; иначе говоря, это требования к системе. Каждый Use case – это некоторый процесс (последовательность действий), поэтому мы должны использовать Sequence diagram для его детализации. На этой диаграмме мы отображаем объекты из предметной области (объекты, участвующие в бизнес-процессе); таким образом, мы получаем экземпляры некоторых классов и их взаимодействие. Sequence diagram отображает сам процесс, статическая картина взаимодействия объектов отображается с помощью Class diagram.

Начнем создавать диаграмму прецедентов – Use case diagram (диаграммы прецедентов). На Use case diagram отображаем взаимодействие между ролями (актерами) и прецедентами (т.е. это случаи использования ИС)^[6].

Прецедент – это некоторый процесс, в котором обычно участвуют несколько объектов.

Диаграмма прецедентов

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

Актер – это роль, которую пользователь играет по отношению к системе.

Актерами являются: Клиент, Пользователь, Администратор.

Рис. 1. Диаграмма прецедентов

Прецедент- "Запись клиента на мойку"

Краткое описание

Вариант использования " Запись клиента на мойку " позволяет клиенту заполнить форму для заявки на мойку своего автомобиля.

Основной поток

1. Прецедент начинается, когда пользователь заходит на сайт.
2. Пользователь заходит под своим зарегистрированным именем и паролем.
3. На экран выводится сообщение об успешном входе на сайт.
4. Далее клиент переходит по вкладке оформить заявку.
5. На экран выводится форма для оформления заявки, предоставляется возможность заполнить такие поля как: Автомобиль, Услуга, Терминал и дата записи.
6. На экран выводится сообщение об успешно добавленной записи “Запись добавлена”
7. В базу данных добавляется новая запись.
8. Прецедент завершается.

Альтернативный поток А1. Не все данные были введены.

1. Система информирует пользователя, какие данные не были введены и просит ввести эти данные.

2. Пользователь вводит необходимые данные и нажимает кнопку "Отправить".

3. Система определяет все ли запрашиваемые данные введены. Если не все, то выполняется альтернативный поток А1. Если во время отправки возникли ошибки, то выполняется поток ошибок Е1.

4. Система выводит сообщение о том, что данные успешно отправлены.

5. Прецедент завершается.

Поток ошибок Е1. Ошибка при отправке данных.

1. В браузере отображается сообщение о ошибке при отправке данных и приглашение ввести данные еще раз.

2. Пользователь вводит необходимые данные и нажимает кнопку "Отправить".

3. Система определяет все ли запрашиваемые данные введены. Если не все, то выполняется альтернативный поток А1. Если во время отправки возникли ошибки, то выполняется поток ошибок Е1.

4. Система выводит сообщение о том, что данные успешно отправлены.

5. Прецедент завершается.

Диаграммы взаимодействия (interaction diagrams)

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

Как правило, описывает поведение только одного варианта использования.

Существует два вида диаграмм взаимодействия: диаграммы последовательности (Sequence diagrams) и диаграммы кооперации (collaboration diagrams)

Диаграммы последовательности (Sequence diagrams)

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

Рис.2 Диаграмма последовательности для прецедента “Запись клиента на мойку”

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

2.3 Проектирование базы данных

Процесс проектирования базы данных состоит из следующих отдельных шагов: концептуального проектирования, проектирования логической структуры базы данных, которая поддерживается СУБД и описывает представление пользователя о данных, и выбора физической структуры, которая включает представление данных, методы доступа и физическое группирование данных^[7].

Построим ER-модель системы.

Основными понятиями ER-модели являются сущность, связь и атрибут.

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

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

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

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

Определим атрибуты сущностей:

1. НКлиента-ключ
2. Фамилия, Имя, Отчество, Телефон, Адрес
3. НТипа – ключ
4. Описание, Категории
5. НАвто – ключ
6. Тип авто, Владелец, Марка, Гос. Номер.
7. Нуслуги - ключ
8. Описание, Базовое время выполнения, Базовая стоимость, Наименование.
9. НЗаказа – ключ
10. Время, Подтверждение, Длительность
11. НТерминала – ключ
12. Категория, Описание
13. НСотрудника – ключ
14. Должность, Фамилия, Имя, Отчество, Телефон, Адрес, Дата приема на работу
15. НЗаписи - ключ
16. Тип записи, Логин, Пароль, Дата регистрации

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

Рис. 4 Схема данных

Заключение

Главной целью работы было моделирование взаимоотношений с клиентами автомоечного комплекса . Для разработки данной системы я использовал унифицированный язык моделирования UML и Rational Rose - case– средство, помогающее строить модели UML.

Разработанная и реализованная мной информационная система представляет из себя первый этап проекта по автоматизации развивающейся фирмы и отвечает всем основным требованиям.

Разработанная ИС позволяет приложению:

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

Реализованная ИС в дальнейшем будет внедрена в автомоечный комплекс.

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