1.3 Формулировка задач проектирования

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

Для построения информационной подсистемы была использована система моделирования Rational Rose 2000.

Выводы

1. Задача разработки информационной подсистемы для учета заказов заключается в описании стандартными средствами языка UML всех происходящих в отделе процессов, связанных с занесением данных в БД и получением отчетности в информационной подсистеме "Автосервис".

2. Для разработки объектно-ориентированной модели требуемой подсистемы необходимо создать все базовые диаграммы языка UML и выполнить генерацию программного кода каркаса приложения на языке С++.

2. Создание диаграммы прецедентов

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

Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой [1, 2]. Действующее лицо – это роль, которую пользователь играет по отношению к системе [1, 2]. Действующие лица представляют собой роли, а не конкретных людей или наименования работ.

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

Используя методы Rational Rose 2000, согласно заданию курсового проектирования, была создана диаграмма прецедентов (рисунок 2.1).

Рисунок 2.1 – Диаграмма прецедентов "Автосервис"

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

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

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

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

Опишем более подробно диаграммe прецедентов (рисунок 2.1).

Действующие лица:

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

2. Менеджер – занимается оформлением заказа, вносит его в базу данных. Также менеджер, на основании заказа клиента, выдаёт задание мастеру-ремонтнику на техническое обслуживание транспортного средства.

3. Мастер-ремонтник – специалист, который занимается ремонтом и техническим обслуживание транспортного средства.

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

Базовый вариант использования "Заказ"– этот вариант использования дает возможность зафиксировать в базе данных (БД) информационной подсистемы "Автосервис" все заявки клиентов.

Выводы

1. Изучена предметная область и создана диаграмма прецедентов.

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

3. Базовым вариантом использования, наиболее важным для реализации системы, является вариант использования "Заказ".

4. С прецедентом "Заказ" взаимодействуют актеры "Клиент" и "Менеджер". Данные базового варианта использование используются актером "Мастер-ремонтник".

3. Создание диаграммы последовательности

Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования [1 – 4]. Для варианта использования "Заказ клиента" создана диаграмма последовательности (рисунок 3.1).

Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами. Sequence diagram – это диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений [1, 2]. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени – вдоль оси Y.

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

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

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

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

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

Рисунок 3.1 – Диаграмма последовательности для варианта использования "Заказ"

Выводы

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

2. Создана диаграмма последовательности. Созданы классы и методы.

На диаграмме последовательностей представлено действующее лицо "Менеджер" и восемь объектов: три формы, для создания удобного пользовательского интерфейса, а также пять классов и методы:

1. Form_Zakaz {Open_form(), Input_data(), Input_worker(), Input_kind_work() } – класс формы.

2. Form_klient {open_form()} – класс формы.

3. Form_Ysluga {Open_form()} – класс формы.

4. Work_BD{Save()} – класс записи введенной в БД информации.

5. Print_data {Print()} – класс печати.