АРМ мененджер автосалона "А-моторс"

АРМ мененджер автосалона "А-моторс"

5

ДЕПАРТАМЕНТ ОБРАЗОВАНИЯ ГОРОДА АСТАНА

Политехнический колледж города Астана

010000 3706002

ДИПЛОМНЫЙ ПРОЕКТ

АРМ менеджера в автосалоне "A-Motors"

ДИПЛОМНЫЙ ПРОЕКТ

(Пояснительная записка)

ДП.3706.П401.31.06.07.ПЗ

Дипломник Хикимов Н.Б.

Руководитель проекта Лапенко С.А.

Консультант по технологическому разделу Лапенко С.А.

Консультант по экономическому разделу Приходько Л.И.

Консультант по разделу «ТБ и охрана труда» Старунов В.И.

Нормоконтролер Вотчал Г.К.

Рецензент

Дата защиты ___________ Оценка ____________

Протокол №____________

2007

СОДЕРЖАНИЕ

• ВВЕДЕНИЕ 6
• 1. Постановочная часть 8
• 1.1 Формулировка задачи 8
• 1.2 Описание входной и выходной документации 8
• 1.3 Требования к интерфейсу Windows-приложения 8
• 2. Проектная часть 16
• 2.1 Описание информационной базы 16
• 2.2 Спецификации набора данных 18
• 2.3 Спецификации набора данных 18
• 2.4 Проект базы данных, используемой в задаче 19
• 2.5 Разработка алгоритмов обработки данных 20
• 2.6 Разработка SQL-запросов к базе данных 22
• 2.7 Разработка форм приложения, меню, отчетов 23
• 3. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА РЕАЛИЗАЦИИ ДИПЛОМНОГО ПРОЕКТА 26
• 3.1 Краткая характеристика операционных систем 26
• 3.2 Краткая характеристика языка программирования Object Pascal и среды Delphi 26
• 3.3 Краткая характеристика используемой СУБД 28
• 4. ЭКСПЛУАТАЦИЯ 31
• 4.1.Требования к аппаратному обеспечению 31
• 4.2.Инструкция пользователю 31
• 4.3 Инструкция программисту 39
• 5. ЭКОНОМИЧЕСКАЯ ЧАСТЬ 40
• 5.1. Определение затрат на создание программного продукта 40
• 5.2 Расчет себестоимости и цены программного продукта 42
• 5.3 Расчет экономической эффективности проекта 44
• 5.4 Технико-экономические показатели проекта 46
• 6. Мероприятия по технике безопасности и окружающей среды. 47
• 6.1. Охрана труда 47
• 6.2. Техника безопасности 49
• 6.3 Охрана окружающей среды 56
• 7. заключение 59
• 8. Список использованных источников 60
• Приложение а. основные модули приложения 61
• А.1 Модуль формы окна «О программе» 61
• А.2 Модуль формы окна «Зарегистрировать автомобиль» 61
• А.3 Модуль формы «Удалить автомобиль» 69
• А.4 Модуль данных 71
• А.5 Модуль формы «Редактирование данных» 74
• А.6 Модуль заставки 78
• А.7 Модуль главной формы 79
• А.8 Модуль формы поиска 85
• А.9 Модуль формы менеджеров 89
• А.10 Модуль формы о владельцах 93

ВВЕДЕНИЕ

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

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

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

Актуальность и цель дпломного проекта

Данный программный продукт разработан для менеджеров по продажам в автосалоне «A-Motors». Программа предназначена для регистрации и ведения учета продаж автомобилей.

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

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

1. Постановочная часть

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

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

1.2 Описание входной и выходной документации

Входные документы

1. Технический паспорт автомобиля - содержит основные паспортные данные автомобиля - выдается при регистрации автомобиля в РЭО УДП УВД РК.

2. Графическое изображение автобусов (рисунки, фотографии)

3. Анкета владельца транспортного средства

4. Акт о приеме автомобиля на реализацию

Выходные документы

1. Карточка автомобиля

2. Список автомобилей удовлетворяющих критериям поиска

3. Список проданных автомобилей за заданный период

4. Перечень зарегистрированных марок автомобилей

1.3 Требования к интерфейсу Windows-приложения

Под графическим интерфейсом пользователя (Graphical User Interface -- GUI) подразумевается тип экранного представления, при котором пользователь может выбирать команды, запускать задачи и просматривать списки файлов, указывая на пиктограм-мы или пункты в списках меню, показанных на экране. Дейст-вия могут, как правило, выполняться с помощью мыши, либо на-жатием клавиш на клавиатуре. Типичным примером графиче-ского интерфейса пользователя является Windows 95/98.

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

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

Чаще всего сколько-нибудь сложное приложение не может ограничиться одним окном. Поэтому прежде всего вам нужно ре-шить вопрос управления окнами. Есть две различные модели приложений: с интерфейсом одного документа (SDI) и с интер-фейсом множества документов (MDI).

В большинстве случаев следует отдавать предпочтение интер-фейсу SDI. Этот интерфейс не обязательно предполагает наличие действительно только одного окна, как в приложениях Windows, типа «Калькулятор». Такое приложение, как «Проводник» Win-dows, также является SDI приложением, но в нужные моменты оно создает вторичные окна для поиска файлов или папок, зада-ния параметров, просмотра свойств файлов и других целей.

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

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

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

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

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

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

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

Статические цвета вы выбираете сами и они будут оставаться неизменными при работе приложения на любом компьютере. Это не очень хорошо, поскольку пользователь не сможет адаптиро-вать вид вашего приложения к своим потребностям. При выборе желательной ему цветовой схемы пользователь может руководст-воваться самыми разными соображениями: начиняя с практиче-ских (например, он может хотеть установить черный фон, чтобы экономить энергию батареи), и кончая эстетическими (он может предпочитать, например, шкалу оттенков серого, потому что не различает цвета). Все это он не может делать, если вы задали в приложении статические цвета. Но уж если по каким-то сообра-жениям вам надо их задать, старайтесь использовать базовый на-бор из 16 цветов. Если вы попытаетесь использовать 256 (или, что еще хуже, 16 миллионов) цветов, это может замедлить работу вашего приложения, или оно будет выглядеть плохо на машине пользователя с 16 цветами. К тому же подумайте (а, как прави-ло, это надо проверить и экспериментально), как будет выгля-деть ваше приложение на монохромном дисплее.

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

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

Использование шрифтов по умолчанию: System или MS Sans Serif, чаще всего позволяет избежать неприятностей. Впрочем, увы, не всегда. Если вы используете для надписей рус-ские тексты, то при запуске приложения на компьютере с неру-сифицированным Windows иногда возможны неприятности. Для подобных случаев все-таки полезно приложить файлы использо-ванных шрифтов к вашей программе.

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

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

Основное требование к меню -- их стандартизация. Это требо-вание относится ко многим аспектам меню: месту размещения заголовков меню и их разделов, форме самих заголовков, клави-шам быстрого доступа, организации каскадных меню. Цель стан-дартизации -- облегчить пользователю работу с приложением. Надо, чтобы пользователю не приходилось думать, в каком меню и как ему надо открыть или сохранить файл, как ему получить справку, как работать с буфером обмена Clipboard и т.д. Для осу-ществления всех этих операций у пользователя, поработавшего хотя бы с несколькими приложениями Windows, вырабатывает-ся стойкий автоматизм действий и недопустимо этот автоматизм ломать.

Начнем рассмотрение требований с размещения заголовков меню. Ко-нечно, состав меню зависит от конкретного приложения. Но раз-мещение общепринятых разделов должно быть стандартизиро-ванным. Все пользователи уже привыкли, что меню Файл разме-щается слева в полосе главного меню, раздел справки -- справа, перед ним в приложениях MDI размещается меню Окно и т.д. Главное меню должно также снабжаться инструментальной па-нелью (см. рис. 1.5), быстрые кнопки которой дублируют наибо-лее часто используемые команды меню. На этих кнопках надо использовать, по возможности, привычные картинки.

По возможности стандартным должно быть и расположение разделов в выпадающих меню.

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

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

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

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

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

Многим разделам могут быть поставлены в соответствие «го-рячие» клавиши, позволяющие обратиться к команде данного раздела, даже не заходя в меню. Комбинации таких «горячих» клавиш должны быть традиционными. Например, команды вы-резания, копирования и вставки фрагментов текста практически всегда имеют «горячие» клавиши Ctrl-X, Ctrl-C и Ctrl-V соответст-венно. Заданные сочетания клавиш отображаются в заголовках соответствующих разделов.

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

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

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

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

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

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

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

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

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

· Встроенную систему контекстно-зависимой оперативной справки, вызываемую по клавише F1.

· Раздел меню Справка, позволяющий пользователю открыть стандартный файл справки Windows.hlp, содержащий в виде гипертекста развернутую информацию по интересующим по-льзователя вопросам.

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

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

2. Проектная часть

Данный программный продукт имеет шесть таблиц БД.

Таблица 2.1 Владельцы - vladelec.dbf

Таблица 2.2 Менеджеры - sotrud.dbf

Таблица 2.3 Автомобили - avto.dbf

Таблица 2.4 Регистрация - avto_in.dbf

Таблица 2.5 Комплектность - komplect.dbf

Таблица 2.6 Продажа - avto_out.dbf

Таблица 2.7 Марки автомобилей - marka.dbf

2.2 Спецификации набора данных

Таблица 2.8

Страницы: 1, 2, 3, 4, 5