Разработка информационной модели автосервиса с использованием языка моделирования UML

Размещено на http://www.allbest.ru

СОДЕРЖАНИЕ

Введение

1. Первоначальная постановка задачи

1.1 Спецификация требований к системе

1.2 Проектирование прецедентов

1.3 Определение классов приложения

1.3.1 Определение свойств классов

1.3.2 Определение ассоциаций классов

1.3.3 Моделирование поведения классов

2. Развитие постановки задачи

2.1 Спецификация требований к системе

2.2 Определение классов приложения

Заключение

Список использованных источников

ВВЕДЕНИЕ

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

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

На сегодняшний день в качестве средства, реализующего методологию объектно-ориентированного программирования, чаще всего применяется язык моделирования UML[2, 3].

1. ПЕРВОНАЧАЛЬНАЯ ПОСТАНОВКА ЗАДАЧИ

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

1.1 Спецификация требований к системе

В качестве языка программирования системы будем использовать VBScript.

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

Объекты, взаимодействующие с системой:

Клиент - имеет право узнавать данные о стоимости работ;

Механик - получает информацию о заказах по своей специальности;

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

Мастер-приемщик - принимает заказы от клиентов, оформляет прием денежных средств.

Функции системы:

При входе в систему механик, начальник смены и мастер-приемщик вводят свое имя и пароль;

Клиент имеет возможность получать прайс-лист о стоимости услуг либо на отдельном терминале либо в виде печатного бланка;

Механик имеет возможность получать информацию о текущих заказах с помощью отдельного запроса;

Начальник смены может вносить изменения, как в каталог услуг, так и в каталог цен;

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

Мастер-приемщик может вносить информацию о клиенте в базу, а также вносить в базу информацию о заказах и новых механиках;

Начальник смены с помощью запросов имеет право получать информацию о количестве свободных механиков и их специализации;

Начальник смены с помощью запросов имеет право получать информацию о количестве заказов на определенную дату и их общую сумму;

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

1.2 Проектирование прецедентов

Привести список актеров:

Актер 1 - Клиент;

Актер 2- Механик;

Актер 3- Начальник смены;

Актер 4- Мастер - приемщик;

Прецеденты проектируемой информационной системы сведены в таблицу 1.1.

Таблица 1.1 - Прецеденты информационной системы

Название	Актеры	Описание
Вход в систему	Клиент; Механик; Начальник смены; Мастер - приемщик;	Всем актерам доступно окно входа в систему, где они вводят имя и пароль, а затем щелкает на кнопке OK или Отмена. Получив доступ к приложению, актер может получать необходимую информацию.
Просмотр справочника неисправностей	Начальник смены; Мастер - приемщик;	Просмотр справочника неисправностей, добавление новых неисправностей в справочник, смена категории неисправности в справочнике
Просмотр справочника цен	Начальник смены; Мастер - приемщик;	Просмотр справочника цен, изменение цен в справочнике в зависимости от изменения ценовой политики автосервиса, добавление новых цен в справочник
Запрос на наличие свободных механиков	Начальник смены; Мастер - приемщик;	Актеры нажатием кнопки находят свободных механиков, задавая дополнительные характеристики в отдельных полях, актеры выбирает механиков нужной специализации.
Запрос на поиск заказов	Механик; Начальник смены; Мастер - приемщик;	Актеры нажатием кнопки могут найти свободные заказы нужной специализации, которые еще не взяли в обслуживание.
Запрос на период получения заказов	Начальник смены; Мастер - приемщик;	Актеры нажатием кнопки получают информацию о свободных механиках, заказах, ценах и обслуживаемых неисправностях за определенный период времени.
Регистрация заказов	Мастер - приемщик;	Пользователь заполняет данные о заказах и клиентах в специальных диалоговых окнах.
Размещение заказов	Мастер - приемщик;	Пользователь устанавливает соответствие между номером заказа и механиком, его выполняющим.

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

После подготовки спецификации требований можно приступать к созданию диаграмм прецедентов. На рисунке 1.1 приведен проект такой диаграммы разработанный с помощью MicrosoftVisio 2010.

Рисунок 1.1 - Проект диаграммы прецедентов

1.3 Определение классов приложения

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

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

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

Таблица 1.2 - Предполагаемы классы системы

Прецедент	Возможные классы
Вход в систему	Пользователь (Клиент; Механик; Начальник смены; Мастер - приемщик;) имя пользователя, пароль, вход в систему, отказ в регистрации
Просмотр справочника неисправностей	Справочник неисправностей, категория неисправности, цена
Просмотр справочника цен	Справочник цен, тип автомобиля, цена
Запрос на наличие свободных механиков	Механик, специализация, разряд
Запрос на поиск заказов	Заказ, количество, категория заказа, цена
Запрос на период получения заказов	Дата заказа, период выполнения, дата окончания
Регистрация неисправностей	Неисправность, цена, тип автомобиля
Размещение заказов	Заказ, цена, исполнитель, срок выполнения, клиент

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

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

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

Заказ;

Неисправность;

Категория неисправности;

Цены.

Эскиз диаграммы классов изображен на рисунке 1.2:

Рисунок 1.2 - Эскиз диаграммы классов

1.3.1 Определение свойств классов

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

Свойства классов проектируемой информационной системы перечислены в таблице 1.

Таблица 1. Свойства классов проектируемой информационной системы

Класс	Свойства	Тип значения
Мастер-приемщик	ID	Число
	Зарегистрированное имя	Строка
	Пароль	Строка
	Имя	Строка
	Фамилия	Строка
Начальник смены	ID	Число
	Зарегистрированное имя	Строка
	Пароль	Строка
	Имя	Строка
	Фамилия	Строка
Заказ	ID	Число
	Неисправность	Строка
	Механик	Строка
	Стоимость	Число
	Клиент	Строка
Неисправность	ID	Число
	Вид	Строка
	Категория	Строка
	Цена	Число
Категория неисправности	ID	Число
	Тип	Число
	Категория	Строка
Цены	ID	Число
	Категория	Строка
	Период	Дата

1.3.2 Определение ассоциаций классов

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

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

Для всех классов приложения определены следующие ассоциации:

Экземпляр класса «Мастер-приемщик» - несколько экземпляров класса «Заказ»

Экземпляр класса «Заказ» - один экземпляр класса «Мастер-приемщик»

Экземпляр класса «Заказ» - несколько экземпляров класса «Цены»

Экземпляр класса «Цены» - несколько экземпляров класса «Заказ»

Экземпляр класса «Начальник участка» - несколько экземпляров класса «Заказ»

Экземпляр класса «Неисправность» - несколько экземпляров класса «Заказ»

Экземпляр класса «Цены» - один экземпляр класса «Неисправность»

Экземпляр класса «Категория неисправности» - несколько экземпляров класса «Цены»

Экземпляр класса «Заказ» - один экземпляр класса «Начальник участка»

Экземпляр класса «Заказ» - один экземпляр класса «Мастер-приемщик»

1.3.3 Моделирование поведения классов

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

Рассмотрим сценарий выполнения прецедента «Вход в систему»:

На экране появляется диалоговое окно входа в систему;

Пользователь вводит свое имя и пароль;

Пользователь подтверждает введенную информацию;

Выполняется проверка имени и пароля, проверяется их подлинность;

Появляется окно для выполнения запроса.

Следующим сценарием будет выполнение прецедента «Просмотр справочника неисправностей».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает каталог «Справочник неисправностей»;

3. Пользователь просматривает каталог «Справочник неисправностей»;

4. Пользователь обновляет информацию в справочнике.

Рассмотрим сценарий прецедента «Просмотр справочника цен».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает каталог «Справочник цен»;

3. Пользователь просматривает каталог «Справочник цен»;

4. Пользователь обновляет информацию в справочнике.

Рассмотрим сценарий прецедента «Запрос на наличие свободных механиков».

Пользователь подтверждает данные, введенные при входе в систему;

Пользователь открывает форму запроса «Наличие свободных механиков»;

Пользователь нажимает на кнопку «Выполнить запрос»;

Пользователь просматривает информацию в форме;

Пользователь формирует отчет по запросу, нажав на кнопку «Отчет»;

Пользователь выводит информацию на печать;

Пользователь закрывает диалоговое окно.

Рассмотрим сценарий прецедента «Запрос на поиск заказов».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает форму запроса «Количество заказов»;

3. Пользователь нажимает на кнопку «Выполнить запрос»;

4. Пользователь просматривает информацию в форме, показывающую количество заказов в диалоговом окне;

5. Пользователь закрывает диалоговое окно.

Рассмотрим сценарий прецедента «Запрос на период получения заказов».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает форму запроса «Дата заказа»;

3. Пользователь вводит в форму данные о заказе;

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

5. Пользователь закрывает диалоговое окно.

Рассмотрим сценарий прецедента «Регистрация приезжающих».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает форму «Регистрация неисправностей»;

3. Пользователь вносит данные в соответствующие поля формы;

4. Пользователь сохраняет данные формы с помощью кнопки «Сохранить»;

5. После нажатия на кнопку данные автоматически фиксируются в соответствующем справочнике.

Последним сценарием приложения будет сценарий «Размещение приезжающих».

1. Пользователь подтверждает данные, введенные при входе в систему;

2. Пользователь открывает форму «Размещение заказов»;

3. Пользователь вносит данные о заказах в соответствующие поля формы и ставит им в соответствие механика или нескольких механиков подходящей специализации;

4. Пользователь сохраняет данные формы с помощью кнопки «Сохранить»;

5. После нажатия на кнопку данные автоматически фиксируются в соответствующем справочнике.

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

2. РАЗВИТИЕ ПОСТАНОВКИ ЗАДАЧИ

В развитии постановки задачи перед проектированием информационного приложения рассмотрим схему бизнес процесса обработки заказов в автосервисе.

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

Схема бизнес процесса показана на рисунке.

2.1 Спецификация требований к системе

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

словесные спецификации на естественном языке;

модельные спецификации;

формальные спецификации.

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

Поэтому рассмотрим в развитии постановки задачи модельную спецификацию системы.

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

2.2 Определение классов приложения

Определение свойств классов

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

Прецедент «Вход в систему»:

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

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

Постусловие. Пользователь имеет возможность сохранить свои учетные данные или выйти из системы без сохранения.

Прецедент «Просмотр справочника неисправностей»:

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

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

Постусловие. Пользователь имеет возможность оформить запрос или заполнить форму на заселение или выйти из системы.

Прецедент «Просмотр справочника цен»:

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

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

Постусловие. Пользователь имеет возможность оформить запрос или заполнить форму на изменение цены или выйти из системы.

Прецедент «Запрос на наличие свободных механиков»:

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

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

Постусловие. Пользователь имеет возможность перейти в форму оформления заказа или распечатать полученные из запроса данные.

Прецедент «Запрос на поиск заказов»:

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

Описание. На экране отображается форма запроса, куда пользователь вводит номер заказа.

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

Прецедент «Запрос на период получения заказов»:

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

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

* Постусловие. Пользователь имеет возможность распечатать полученные из запроса данные.

Прецедент «Регистрация неисправностей»:

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

Описание. На экране отображается форма регистрации. Пользователь вносит в форму информацию по новой неисправности.

Постусловие. Пользователь имеет возможность оформить запрос или заполнить форму на заселение или выйти из системы.

Прецедент «Размещение заказов»:

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

Описание. На экране отображается форма размещения. Пользователь вносит в форму данные по неисправности, ставит им в соответствие механика и определяет период выполнения заказа.

Постусловие. Пользователь после нажатия на кнопку «Сохранить» и «Печать» выводит квитанцию для оплаты.

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

Определение ассоциаций классов

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

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

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

Инкапсуляция, наследование и полиморфизм - три кита, на которых держится ООП.

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

Отношение зависимости означает, что реализация одного класса зависит от спецификации операций другого класса.

Ассоциация выражает отношение между несколькими равноправными объектами и может иметь направление, роли и кратность, а также изображаться в виде класса ассоциации.

Композиция и агрегация используются, если между объектами существуют отношения типа "часть-целое", причем композиция предполагает, что части не могут существовать отдельно от целого.

Теперь рассмотрим схему состояний системы перед последним формированием сценария работы системы и формирования ее интерфейса.

Схема состояний системы показана на рисунке ниже.

Моделирование поведения классов

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

Диаграмма развертывания представлена ниже.

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

Форма входа в систему представлена ниже.

информационный приложение автосервис класс

ЗАКЛЮЧЕНИЕ

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Григорьев, В. Н. Высокоуровневые методы информатики и программирования / В. Н. Григорьев. -- Саратовский госуниверситет.

Кларк, Д. Объектно ориентированное программирование в VisualBasic .NET. Библиотека программиста / Д. Кларк. -- СПб.: Питер; 2003. -- 352 с.: ил.

Буч, Г. Язык UML. Руководство пользователя. 2-е изд. / Г. Буч, Д. Рамбо, И. Якобсон ; пер. с англ. Н. Мухин -- М.: ДМК Пресс, 2006. -- 496с.: ил.

Горин С.В., Тандоев А.Ю. Применение CASE-средства ERWin 2.0 для информационного моделирования в системах обработки данных // СУБД. - 1995. - № 3.

Кондратьев А.М. Объектные базы данных в CASE-средстве Real // см. наст. сб.

Вендров А.М. Case-технологии. Современные методы и средства проектирования информационных систем. - М. Финансы и статистика, 1998. - 176 с.: ил.

Патрик Нотон Java. Справочное руководство: Пер. С англ.- М.: Восточная Книжная Компания, 1996. - 448 с.: ил.

Размещено на Allbest.ru