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

Автор работы: Пользователь скрыл имя, 16 Марта 2011 в 13:13, дипломная работа

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

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

Содержание работы

ВВЕДЕНИЕ 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
ПРИЛОЖЕНИЕ

Содержимое работы - 1 файл

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

— 738.00 Кб (Скачать файл)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Ярлычки, которые всплывают, когда пользователь задержит курсор мыши над каким-то элементом окна приложения. В частности, такими ярлычками обязательно должны снабжаться быстрые кнопки инструментальных панелей, поскольку нанесенные на них пиктограммы часто не настолько выразительны, чтобы пользователь без дополнительной подсказки мог понять их назначение.
  • Более развернутые подсказки в панели состояния или в другом отведенном под это месте экрана, которые появляются при перемещении курсора мыши в ту или иную область окна приложения.
  • Встроенную систему контекстно-зависимой оперативной справки, вызываемую по клавише F1.
  • Раздел меню Справка, позволяющий пользователю открыть стандартный файл справки Windows.hlp, содержащий в виде гипертекста развернутую информацию по интересующим пользователя вопросам.

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

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

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

     2.1 Описание информационной базы

 

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

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

Наименование  поля Тип Размер Назначение
*  Kod_vlad Number 5 Код владельца
Fam Character 20 Фамилия
Name Character 20 Имя
Oth Character 20 Отчество
Adres Character 20 Адрес
Mail Character 30 Адрес электронной  почты
Tel Number 20 Номер телефон
Sot Number 20 Номер мобильного телефона
 

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

Наименование  поля Тип Размер Назначение
* Kod_sot Number 3 Код сотрудника
Fam Character 20 Фамилия
Name Character 20 Имя
Oth Character 20 Отчество
 

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

Наименование  поля Тип Размер Назначение
* Kod_avto Number 6 Код автомобиля
Kod_vlad Number 5 Код владельца
Kod_Marka Number 6 Код марки
Model Character 20 Модель автомобиля
V Character 5 Объем двигателя
Gos_nom Character 8 Государственный номер
Cvet Character 20 Цвет
Tip_kuz Character 20 Тип кузова
Foto_1 Character 20 Фотография 1
Foto_2 Character 20 Фотография 2
Cena Number 10 Цена

Информация о работе АРМ менеджера в автосалоне "A-Motors"