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

Такой вид деятельности в г. Самаре широко развивается. Услуги автопроката востребованы, как частными, так и корпоративными клиентами. Это прекрасная возможность сэкономить финансовые средства и большое количество времени.

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

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

1. Анализ предметной области

1. Юридический адрес

443022, Самара, Заводское шоссе, 11, офис 109 ООО «БУМЕРАНГ-АВТО»

– ИНН 6312143781; КПП 631801001;

– Р/с 0702810129180001170 в Филиал «Самарский» АО «АЛЬФА-БАНК»;

– К/с 30101810200000000824 в ВОЛГО-ВЯТСКОЕ ГУ БАНКА РОССИИ;

Телефоны:+7 (846) 989-04-24;+7 (937) 989-04-34;8-927-260-54-51 спец. техника; 8-937-99-80-60 технический специалист;

2. Деятельность компании

Компания «БУМЕРАНГ-АВТО» оказывает услуги в области аренды и проката автомобилей в Самаре.

3. Структура предприятия

4. Ограничение предметной области

На сновании бланка договора, паспорта автомобиля, страхового полиса автомобиля выявлены следующие ограничения:

– Паспортные данные (серия номер)- 11 знаков;

2. Техническое задание

1.1. Наименование программы: база данных «БУМЕРАНГ АВТО».

1.2. Краткая характеристика области применения: База данных предназначена для ввода, вывода, хранения, удаление, редактирования информации о клиентах, сотрудниках, автомобилях «БУМЕРАНГ АВТО».

1.3. Условные обозначения и сокращения:

1.4. Основания для разработки: задание на курсовую работу.

2. Назначение разработки

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

3. Требования к программе или программному изделию

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

1. Осуществлять ввод, вывод, редактирование информации о сотрудниках, клиентах, автомобилях.

2. Осуществлять поиск сотрудников, клиентов, автомобилей.

3.2. Ввод и редактирование информации

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

– Категория прав на автомобиль

– Дата начала аренды

– Дата окончания аренды

Поиск и просмотр информации

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

1) Поиск по марке авто

2) Поиск по ФИО клиента

3) Поиск по гос. номеру

4) Поиск по ФИО сотрудника

3.3. Требования к организации входных данных

Буквы английского алфавита и цифры

Категория водительских прав

Год изготовления ТС

Кузов (кабина, прицеп)

Цвет кузова (кабины, прицепа)

Мощность двигателя, л/с (кВт)

Масса без нагрузки, кг

Разрешенная максимальная масса, кг

Дата выдачи паспорта

Паспортные данные клиента

Категория прав на автомобиль

Дата начала аренды

Дата окончания аренды

Стоимость аренды за сутки

Дата поступления на ремонт

Дата окончания ремонта

Фамилия Имя Отчество

Дата приема на работу

3.4. Требования к выходным данным

Выходные данные соответствуют входным данным. Просмотр выходных данных осуществляется на мониторе и отображается в виде таблицы.

Категория водительских прав

Год изготовления ТС

Кузов (кабина, прицеп)

Цвет кузова (кабины, прицепа)

Мощность двигателя, л/с (кВт)

Масса без нагрузки, кг

Разрешенная максимальная масса, кг

Дата выдачи паспорта

4. Требования к надежности

4.1. Требования к обеспечению надежного (устойчивого) функционирования программы

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

1) своевременное пополнение базы данных

2) организацией бесперебойного питания серверного и коммуникационного оборудования

3) использованием лицензионного программного обеспечения

4) регулярным выполнением рекомендаций Министерства здравоохранения и социального развития РФ, изложенных в Приказе от 14 октября 2011 г. «Об утверждении Межотраслевых типовых норм времени на работы по сервисному обслуживанию оборудования телемеханики, сопровождению и доработке программного обеспечения»

5) регулярным выполнением требований ГОСТ 51188-98. «Защита информации. Испытания программных средств на наличие компьютерных вирусов» (переиздание от 01.08.2003 г.)

4.2. Отказы из-за некорректных действий оператора

Возможными считаются отказы Базы вследствие некорректных действий персонала, обслуживающего СУБД, операционную систему, под управлением которой работает База, в том числе использование нелицензионного ПО. Защита от подобных действий настоящим Техническим заданием не предусматривается. Меры безопасности по недопущению некорректных действий персонала должны определяться соответствующими руководствами пользователя и системного программиста.

5. Условия эксплуатации

5.1. Требования к видам обслуживания

Обслуживание Базы включает в себя:

2) системное администрирование БД

5.2. Требования к численности и квалификации персонала

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

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

Системный администратор должен иметь специальное или высшее профильное образование и обладать необходимыми знаниями в области администрирования операционных систем и используемой СУБД. В перечень выполняемых им задач должны входить:

1) поддержание работоспособности технических средств

3) установка (инсталляция) и настройка программного изделия

5.3. Требования к составу и параметрам технических средств

Минимальные аппаратные требования:

– Процессор: тактовая частота 1GHz;

– Оперативная память: 512Mb оперативной памяти;

– Видеокарта: Встроенный графический адаптер с 512 Мб видеопамяти;

– Свободное место на жёстком диске: 2000Kb;

– Прочие средства: мышь, клавиатура, монитор;

5.4. Требования к информационной и программной совместимости

БД работает при наличии ОС типа Windows и установленного пакета MSOffice, включая MSAccess.

Требования к защите информации и программ

Требования к защите информации и программ не предъявляются.

6. Требования к программной документации

6.1. Предварительный состав программной документации

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

– ГОСТ 19.503-79. ЕСПД. Руководство системного программиста.

– ГОСТ 19.505-79. ЕСПД. Руководство оператора.

3. Выбор средств методологии проектирования

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

Общепринятая методология проектирования БД разделяется на 3 основные фазы:

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

Тип разрабатываемой модели

SADT (StructuredAnalysisandDesignTechnique, методология структурного анализа и проектирования)

DFD (DataFlowDiagrams,диаграммы потоков данных)

Функциональная или компонентная

ERD (Entity-Relationship Diagrams,диаграммы «сущность-связь»)

EPC (Event-driven Process Chain, событийнаяцепочкапроцессов)

Функциональная или поведенческая

BPMN (Business Process Model and Notation, модельинотациябизнес-процессов)

Функциональная или поведенческая

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

– графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих «ограничения», которые в свою очередь определяют, когда и каким образом функции выполняются и управляются (модели IDEF0,IDEF1,IDEF2, IDEF3, IDEF3X);

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

Правила SADT включают:

– ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

– связность диаграмм (номера блоков);

– уникальность меток и наименований (отсутствие повторяющихся имен);

– синтаксические правила для графики (блоков и дуг);

– разделение входов и управлений (правило определения роли данных).

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

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

При построении функциональной модели системы альтернативой методологии SADT(IDEF0,IDEF1,IDEF2, IDEF3, IDEF3X) является методология диаграмм потоков данных(DataFlowDiagrams, DFD). В отличие отIDEF0, предназначенной для проектирования систем вообще, DFD предназначена для проектирования потоков информационных систем. Ориентированность этой методологии на проектирование автоматизированных систем делает ее удобным и более выгодным инструментом при построении функциональной модели TO-BE.

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

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

Для проектирования концептуальной модели БД «прокат автомобилей» будем использовать методологию SADT (IDF0) и DFD (диаграмму потоков).

Моделирование информационных систем и БД, как правило, выполняется с помощью case-средств. К таким средствам относятся:

4. RationalRose представляет собой CASE средство проектирования и разработки информационных систем и программного обеспечения для управления предприятиями. Как и другие CASE средства (ARIS, BPwin, ERwin) его можно применять для анализа и моделирования бизнес процессов.

Для проектирования концептуальной модели воспользуемся CASE-средством СА ErwinProcessModeler, а для проектирования физико-логической модели воспользуемся CA ErwinProcessModeler,так как они изучались на дисциплине инструментальные средства разработки программного обеспечения.

4. Разработка концептуальной модели